Потоковые технологии отслеживают, кто и с кем обменивался данными, по какому протоколу, сколько байтов и пакетов было передано каждой стороной и так далее. Итоговый отчет, содержащий всю эту информацию, отправляется на потоковый приемник, причем в сравнении с файлом, который генерирует анализатор протоколов при захвате пакетов, объем информации меньше на несколько порядков, так как в отчете содержится лишь сводная статистика.
На сегодняшний день используется множество потоковых технологий, в частности NetFlow, IPFIX, J-Flow, cflowd и sFlow.
Плюсы. В сравнении с протоколом SNMP потоковые технологии обладают целым рядом полезных особенностей. Во-первых, коммутатору не нужно сохранять отчеты о поведении сети за относительно продолжительное время. Как правило, потоковые отчеты охватывают небольшие периоды и экспортируются каждые 30 мин или даже чаще, тогда как при использовании SNMP приходится хранить данные за целый день или несколько дней.
Во-вторых, аппаратные или программные зонды теперь не нужны, поскольку потоковые данные поступают от самой инфраструктуры сети. В большинстве случаев с созданием потоковых отчетов справляется имеющаяся инфраструктура. Возможно, коммутаторы младшего класса, расположенные в непосредственной близости от пользователей, на это не способны, но те, что находятся в ядре сети и обслуживают соединения с глобальной сетью, наверняка такими возможностями обладают — они-то и представляют наибольший интерес. Надо лишь выполнить некоторые настройки, и все заработает (см. Рисунок 1).
Потоковый приемник может располагаться в любой точке распределенной сети, вот только некоторые каналы глобальной сети могут оказаться слишком дорогими. Поэтому потоковые приемники стоит размещать в стратегических точках сети с учетом географии. Размеры потоковых отчетов, направляемых приемнику, составляют не более 3-5% от объема трафика. В зависимости от типа трафика эта цифра может снизиться до 1% или оказаться еще меньше.
Потоковые данные постоянно отправляются потоковому приемнику, между тем как в случае протокола SNMP предполагается, что станция мониторинга регулярно опрашивает агента SNMP, после чего данные передаются получателю.
Минусы. На момент написания данного руководства наибольшее распространение среди потоковых технологий получил метод NetFlow, разработанный компанией Cisco. Для инфраструктуры, построенной на оборудовании другого производителя, имеются альтернативные технологии. Документ RFC 3917 стандартизирует версию технологии NetFlow под названием IPFIX, что должно способствовать ее распространению.
Технология sFlow — это пример потоковой технологии, определенной в документе RFC 3176, где используются выборки (sample). Она позволяет получить статистику по объему трафика и участникам диалога (обмена информацией). Метод sFlow можно настроить на проверку каждого n-ого пакета или на выбор пакетов случайным образом. Поскольку трафик всегда просматривается выборочно, этот метод полезен при планировании расширений, анализе общих тенденций и диагностировании по принципу «годен/не годен».
Выборка пакетов делает невозможным получение отчетов по последовательностям пакетов в отдельно взятой транзакции. По этой же причине данная технология не всегда пригодна к использованию для задач. В отличие от технологий NetFlow и IPFIX, метод sFlow работает на втором уровне модели OSI и выдает статистику по отличному от IP трафику. Однако это довольно сомнительное преимущество, поскольку протокол IP фактически стал доминирующим. Выборку для NetFlow или IPFIX поддерживают и некоторые платформы, но тоже с ограничением по применимости.
Потоковый отчет формируется, когда заканчивается поток или истекает соответствующий таймер, однако обычно он отправляется не чаще чем один раз за период от 1 до 30 мин. Таким образом, мониторинг ведется с некоторой задержкой, хотя тот факт, что отчеты отправляются регулярно, способствует созданию впечатления, что работа ведется в реальном времени.
Как правило, потоковые отчеты отправляются без шифрования, поэтому теоретически их можно подделать.
Если сравнивать потоковые отчеты с SNMP, то в них выдается информация о несколько меньшем трафике. Например, сводки NetFlow могут содержать данные о трафике IP, но не о других видах трафика третьего уровня или ниже. Если в сочетании с SNMP используется правильная база MIB, то этот метод позволит получить информацию обо всем трафике через данный интерфейс.
НАСТРОЙКА СЕРВЕРА SYSLOG
Большинство устройств в сетевой инфраструктуре поддерживает отправку информации для регистрации событий сервером syslog. Syslog чаще всего используется для управления серверами и приложениями, а также для проведения аудитов по безопасности.
Степень подробности отчетов задается в настройках и может варьироваться от регистрации только критически важных («катастрофических») инцидентов до записи всех, даже незначительных, событий. В документе RFC 3164 перечислены все типы сообщений. Отправляемые сообщения содержат, помимо прочего, информацию об ошибках и событиях (регистрация в системе, отказ в регистрации, запуск и остановка процессов и так далее), а также о регулярно повторяющихся операциях.
Плюсы. Cервер syslog будет сам выдавать отчеты об ошибках, событиях и обычных операциях, если сетевой администратор правильно настроит коммутатор, указав ему IP-адрес получателя — сервера syslog (см. Рисунок 2).
После конфигурации сообщения syslog отправляются непрерывно (как и требуется), поэтому всегда имеется актуальная запись активности в сети, которая доступна для ознакомления с текущей ситуацией или ретроспективой событий.
Syslog, вероятно, один из лучших методов диагностики при проблемах с процедурами аутентификации.
Минусы. Сервер Syslog может генерировать огромные объемы бесполезных данных. Иногда очень сложно обнаружить в огромном количестве сообщений причину возникшей проблемы или в профилактических целях отыскать источники потенциальных проблем или «дыры» в системе безопасности. Колоссальные количества несущественных сообщений и разыскивание среди них нужного, словно иголки в стоге сена, привели к появлению специальных утилит анализа syslog и даже платных приложений, которые могут сортировать и группировать сообщения, а также обладают расширенными возможностями поиска.
Если параметры протоколирования слишком широки, то за короткое время сервер syslog порождает большие объемы бесполезной информации. Если же они чересчур узки, то важные события могут не найти отражения в отчетах.
ИСПОЛЬЗОВАНИЕ РЕСУРСОВ ХОСТА
Практически все компьютеры и сетевые карты обладают некоторыми встроенными средствами диагностики, которые, как правило, выдают сообщения о большинстве событий, способных повлиять на ежедневное использование устройства и его работоспособность.
Компьютерная диагностика. Каждый производитель компьютерной техники располагает теми или иными приложениями для диагностики оборудования. Они либо поставляются вместе с компьютером, либо загружаются с сайта производителя. В большинстве случаев такие средства рассчитаны исключительно на диагностику отдельно взятого устройства, но последствия аппаратных сбоев могут сказываться и на сети в целом.
Кроме того, производитель сетевых карт часто предоставляет загружаемые диагностические утилиты, облегчающие конфигурацию и диагностирование сетевых карт. Эти утилиты можно использовать для проверки скорости и настроек дуплексного режима, а также выявления любых ошибок, о которых предоставляются отчеты. Программный драйвер сетевой карты, установленный на компьютере, предоставляет такую информацию не всегда, а если и предоставляет, то найти ее порой очень трудно.
Диагностика операционной системы. Операционные системы — например, Microsoft Windows, UNIX или Linux — обладают разнообразными диагностическими возможностями.
Самые простые средства диагностики Windows — утилиты msconfig и окно статистики сетевой карты. Утилита msconfig позволяет просмотреть конфигурацию системы, включая информацию по драйверу сетевой карты, а статистика работы сетевой карты показывает, какой объем трафика система получила из сети и сколько, по ее мнению, отправила в сеть. (Как правило, получаемые значения коррелируют с результатами, которые выдает запрос к базе MIB II. На сетевую карту может поступать гораздо больше трафика, чем она принимает, и обнаружить это можно с помощью запросов RMON — см. Рисунок 1)
Указать на лучший пример диагностики для ОС UNIX или Linux не так-то просто, поскольку выбор средств для операционных систем с открытым кодом чрезвычайно широк: от самых простых до очень развитых и многофункциональных, которые по своим возможностям приближаются к описанной ниже категории продуктов от сторонних поставщиков.
Средства диагностики от сторонних поставщиков. Эти средства диагностики (например, программные анализаторы протоколов) применяются на станциях для определения проблем с использованием протоколов. Простые продукты, предназначенные для анализа протоколов, можно загрузить из Internet, а сложные, включающие большое количество встроенных библиотек с симптомами сбоев и инструментов для составления отчетов (такие решения чаще всего называют экспертами), предлагают для продажи различные поставщики.
Помимо того, существует масса других видов диагностических средств, в том числе системы управления сетями на основе SNMP и специальные инструменты для отдельных видов сетевой диагностики, проведения анализа и оценки закономерностей в работе сетей.
ИСПОЛЬЗОВАНИЕ КОМБИНАЦИИ МЕТОДОВ
Некоторые сетевые проблемы вполне надежно обнаруживаются с помощью какого-то одного метода диагностирования, другие требуют применения двух и более методов, иначе сбой не удается правильно распознать и устранить.
Одним из таких примеров может быть использование сначала аппаратного анализатора протоколов для отслеживания исходящих и входящих маршрутов передачи данных от сетевого устройства, например, к коммутатору и от него, а затем моделирование канала передачи с определенным типом трафика с помощью другого метода. Результаты теста покажут, вносит ли коммутатор или другое устройство изменения в трафик при передаче, отфильтровывает ли система безопасности какие-то данные, соблюдается ли приоритет в маршрутизации трафика (что очень важно для таких приложений, как передача голоса по IP), а также какова задержка в работе самого коммутатора.
ЗАКЛЮЧЕНИЕ
Самый распространенный подход к диагностике — не предпринимать каких бы то ни было действий, пока пользователь ни на что не жалуется. Этот метод на самом деле прост и эффективен, и недооценивать его не стоит. Пользователи очень тонко чувствуют отклонения в работе сети, даже если эти ощущения основаны на подсознательной оценке. Как только сеть начинает вести себя «не как обычно», они тут же обращаются в отдел ИТ. Получив такой сигнал, вы можете начать диагностику именно с «подозрительной» рабочей станции. Единственный недостаток этого метода состоит в том, что он реактивный — вы реагируете на сбой, который уже произошел.
В идеале отдел ИТ должен работать так, чтобы не допускать возникновения сбоев, то есть подход должен быть проактивным. Профилактические меры могут включать в себя регулярный опрос каждого коммутатора, мониторинг трафика и проверку его качества на каждом порту коммутатора, а также мониторинг любого сегмента в сети с той или иной частотой. Перейти от борьбы с последствиями сбоев к предотвращению их появления помогут средства мониторинга портов коммутатора, выявление закономерностей на основании накопленной статистики, а также инструменты для отслеживания поведения коммутаторов. Впрочем, следует отдавать себе отчет в том, что полностью исключить возникновение сбоев невозможно.
Очень важно проводить регулярный инструктаж и обучение персонала, работающего в отделе ИТ. К сожалению, в последние годы наблюдается очень тревожная тенденция: сетевые специалисты недооценивают и даже игнорируют теоретические аспекты построения сети, ее структуру, исследование поведения сети и другие составляющие модели OSI, располагающиеся ниже сетевого уровня. Возможно, это связано с тем, что в сетях совершился переход от использования устройств с разделяемой пропускной способностью и совместным использованием ресурсов к коммутируемым решениям, когда к каждому порту подключается единственный пользователь. Поскольку проблема затрагивает только одного сотрудника, все списывается на неудачное стечение обстоятельств или устаревание конкретного сетевого устройства (устаревание в данном случае означает всего двух- или трехлетний период эксплуатации). Если симп-томы или результаты тестов оцениваются как противоречивые, их просто игнорируют, хотя на самом деле в проблеме следовало бы разобраться досконально. Небольшой дополнительный курс обучения или тренинг позволил бы специалистам ИТ правильно интерпретировать симптомы и результаты тестирования, безошибочно идентифицировать проблему и устранить ее.
Недостаток понимания в области нижележащих технологий — под сетевым уровнем модели OSI — приводит к тому, что целое поколение специалистов в подобных ситуациях оказы-вается абсолютно беспомощным. Превращение беспроводных технологий из любопытной игрушки в широко внедряемое решение заставляет вспомнить о сетях с разделяемой пропускной способностью и задуматься о том, что же может происходить в проводных сетях на этом уровне. Для тех, кто оказывает услуги по поддержке сети, обучение и тренинги никогда не бывают лишними, особенно если они касаются функционирования каждого элемента сети в нормальном режиме. Это позволяет распознать отклонение от нормального поведения, оценить нетипичные симптомы и предпринять необходимые действия.
Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.