Мониторинг в корпоративных сетях. § Полное описание всех этапов проектирования, разработки и внедрения системы. Продукты для мониторинга и анализа

27.06.2011 Нейт Мак-Алмонд

Я остановил свой выбор на трех кандидатах: WhatsUp Gold Premium компании Ipswitch, OpManager Professional компании ManageEngine и ipMonitor компании SolarWinds. Стоимость каждого из этих сетевых сканеров не превышает 3000 долл. (за 100 устройств), и при этом у каждого из них есть пробный период эксплуатации, в течение которого вы можете бесплатно протестировать выбранный продукт

Я работаю в компании среднего размера, и мы уже около семи лет используем одну и ту же систему мониторинга сети. Она предоставляет нашим администраторам базовую информацию о доступности серверов и служб, а также отправляет текстовые сообщения SMS на наши мобильные телефоны в случае возникновения проблем. Я пришел к выводу, что необходимо обновить систему или по крайней мере добавить эффективное средство, способное обеспечить более высокую производительность и предоставлять подробную информацию о состоянии серверов терминалов, систем Exchange и SQL, размещенных в вашей сети. . Давайте сравним наших кандидатов.

Процесс обнаружения

Для подготовки к тестированию в первую очередь необходимо было включить службу SNMP на всех устройствах, включая серверы Windows. Изменив настройки службы SNMP, я установил доступ с привилегией «только чтение» на всех устройствах, которые должен охватывать процесс мониторинга. В системах Windows Server 2003/2000 служба SNMP устанавливается с помощью мастера Windows Components, размещенного в панели Add/Remove Programs, а в системе Windows Server 2008 компоненты SNMP добавляются с помощью мастера Server Manager. После завершения работы мастера необходимо запустить оснастку Services, расположенную в папке Control Panel, и настроить службу SNMP - это несложно. Управляемые сетевые устройства, такие как межсетевые экраны, коммутаторы, маршрутизаторы и принтеры, также имеют средства управления службой SNMP, и обычно процесс настройки представляет собой достаточно простую операцию. Дополнительную информацию о службе SNMP можно получить из документа «Simple Network Managment Protocol» (technet.microsoft.com/en-us/library/bb726987.aspx).

Далее я установил все три системы мониторинга на одну из двух своих рабочих систем с Windows XP SP3. После установки каждая система состояла из двух частей: базы данных и веб-сервера. Управление каждой из выбранных систем через веб-интерфейс может выполняться несколькими администраторами, и у вас есть возможность настроить учетные записи с различными уровнями доступа. Общим для трех систем является и то, что каждый пользователь имеет возможность добавлять, удалять и перемещать панели в своей рабочей области. Панели отображают однотипные данные, такие как загрузка процессора или использование памяти для различных устройств в сети.

Перед тем как начать сканирование сети (так называемый процесс обнаружения), я задал параметры учетной записи, которую каждая система должна использовать для получения доступа к устройствам, обнаруженным в сети. Как показано в сравнительной таблице, система Ipswitch WhatsUp Gold Premium позволяет настроить учетную запись для работы со службами SNMP, WMI, Telnet, SSH, ADO и VMware. Система ManageEngine OpManager Professional позволяет работать по протоколам SNMP, WMI, Telnet, SSH и URL, а система SolarWinds ipMonitor - по протоколам SNMP, WMI и URL.

После настройки службы SNMP на сетевых устройствах и учетных записей (Windows и SNMP) для каждой из систем сетевого мониторинга я запустил процесс обнаружения для диапазона IP-адресов в своей локальной сети. Все системы обнаружили около 70 устройств. Используя настройки сканирования, заданные по умолчанию, тестируемые системы хорошо показали себя при идентификации типов устройств, а также представили подробную информацию о состоянии устройств. Все три системы содержат сенсоры для основных рабочих характеристик устройств и серверов, таких как: загрузка процессора, использование памяти, использование/наполненность диска, потери/задержки пакетов, состояние служб Exchange, Lotus, Active Directory и всех служб Windows. Каждая из систем имела возможность добавлять сенсоры как для отдельных устройств, так и для больших групп устройств.

Пакеты OpManager и WhatsUp Gold имеют интерфейс для идентификации и сбора событий службы VMware с серверов и гостевых систем. Кроме того, оба продукта располагают функцией опроса диспетчера портов коммутатора, которая показывает, какие устройства подсоединены к различным портам управляемых коммутаторов. Полученная информация поможет определить, через какой порт коммутатора осуществляется соединение с определенным бизнес-приложением, при этом нет необходимости вручную выполнять трассировку кабелей в серверных комнатах. В дальнейшем вы можете настроить оповещения для определенных портов коммутатора. При работе с пакетом OpManager для получения результатов опроса портов достаточно выбрать коммутатор и запустить инструмент Switch Port Mapper - система вернет результаты за несколько секунд. Аналогичное средство, входящее в состав WhatsUp Gold, называется MAC Address, его необходимо запускать с отмеченным параметром Get Connectivity. На получение результата в системе WhatsUp Gold уходит больше времени, так как она пытается просканировать устройства и собрать информацию о подключениях по всей сети.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
ЗА: обеспечивает наиболее точные результаты среди трех конкурентов, позволяет создавать собственные сенсоры, предоставляет комплексные средства мониторинга систем VMware, интегрируется с AD.
ПРОТИВ: меньшее количество встроенных сенсоров и более высокая стоимость по сравнению с конкурентами (если приобретать лицензию менее чем на 500 устройств).
ОЦЕНКА: 4,5 из 5.
ЦЕНА: 7495 долл. за 500 устройств, 2695 долл. за 100 устройств, 2195 долл. за 25 устройств.
РЕКОМЕНДАЦИИ : я рекомендую WhatsUp Gold IT подразделениям, обслуживающим крупные среды VMware, или желающим создавать собственные сенсоры.
КОНТАКТНАЯ ИНФОРМАЦИЯ: Ipswitch, www.ipswitch.com

При работе с системами IpMonitor и OpManager я время от времени сталкивался с непонятными показаниями, которые ставили меня в тупик. В системе IpMonitor в рабочих панелях могли отображаться отрицательные значения, когда уровень загрузки процессора значительно снижался. В другом случае при загруженности процессора близкой к нулю система IpMonitor прислала мне уведомление, что процессор задействован на 11,490%! Система OpManager, отслеживая и присылая мне корректную информацию об использовании дисков контроллеров домена, при этом в некоторых случаях не включала ни один из контроллеров в список 10 серверов с максимальным использованием дискового пространства. При этом соседняя панель извещала о том, что один из моих контроллеров домена должен быть даже не в десятке, а в тройке. При использовании WhatsUp Gold я не сталкивался с подобными ситуациями. Система WhatsUp Gold отслеживает загруженность ядер процессоров в своих панелях, и, когда я сравнил результаты из панелей WhatsUp Gold с показаниями средства Windows Performance Monitor, они в точности совпали по каждому из ядер. Аналогично, информация об использовании жестких дисков корректно передавалась на все соответствующие приложения рабочей области.

Система WhatsUp Gold имеет встроенную библиотеку сенсоров, которая позволяет создавать новые сенсоры на основе существующих. Крупные организации могут найти эту возможность полезной, так как она позволяет создавать единые наборы сенсоров для мониторинга различных типов устройств - это наиболее эффективной способ настраивать сенсоры для группы устройств.

Система WhatsUp Gold не имеет сенсоров для устройств отдельных производителей (за исключением сенсора для источников питания APC UPS), в отличие от пакета OpManager, использующего собственные сенсоры для устройств Dell, HP и IBM, но зато позволяет создавать сенсоры типа Active Script. Данный тип позволяет разрабатывать собственные процессы мониторинга с помощью языков программирования VBScript и JScript. Сенсорам Active Script посвящен центр онлайн-поддержки, в котором пользователи системы WhatsUp Gold могут получать и загружать готовые сценарии.

Единственное улучшение, которое мне бы хотелось добавить в систему WhatsUp Gold, касается интерфейса (экран 1), в основном из-за того, что он слишком линейный. Например, понадобится до 5 щелчков на кнопках Cancel и Close, чтобы вернуться из окна Active Monitor Library обратно к рабочей области. Также в системе WhatsUp Gold отсутствует сенсор (если, конечно, не написать его вручную), проверяющий состояние сайта, а он может быть необходим, особенно в случаях, когда сайт размещен на стороннем сервере и другие пути доступа к нему отсутствуют.

Экран 1. Интерфейс WhatsUp Gold Premium

Для обработки ситуаций, когда устройства находятся в нерабочем состоянии в течение некоторого времени, можно настроить отправку уведомлений каждые 2, 5 и 20 минут. Таким образом можно привлечь внимание администратора к отсутствию откликов от важнейших узлов в течение определенного времени.

WhatsUp Gold является единственной из рассматриваемых систем, которая обладает возможностью интеграции в окружение LDAP, - данный момент может быть принципиальным при выборе решения для крупных сетей.

ManageEngine OpManager

ManageEngine OpManager
ЗА: лучший пользовательский интерфейс среди трех продуктов; больше встроенных сенсоров, чем в двух других системах; самая низкая цена при покупке лицензии на 50 и менее устройств.
ПРОТИВ: в ходе тестов не все показатели устройств отображались корректно; возможно, потребуется потратить время на отладку, чтобы сделать систему полностью функциональной.
ОЦЕНКА: 4,5 из 5.
ЦЕНА: 1995 долл. за 100 устройств, 995 долл. за 50 устройств, 595 долл. за 25 устройств.
РЕКОМЕНДАЦИИ: ИТ-подразделения, желающие получить максимальное количество встроенных возможностей (за исключением интеграции в AD), оценят систему OpManager Professional. При покупке лицензий в диапазоне 26–50 устройств ее стоимость почти вдвое ниже стоимости двух других продуктов.
КОНТАКТНАЯ ИНФОРМАЦИЯ: ManageEngine, www.manageengine.com

После установки системы OpManager я обнаружил, что она отличается простотой настройки огромного числа функций и удобством перемещения между ними. В OpManager предусмотрена возможность отправки (наряду с электронными письмами и SMS) сообщений типа Direct Message для учетной записи в системе Twitter - приятная альтернатива электронной почте. Подобное использование учетных записей Twitter позволяет мне быть в курсе происходящего в сети, но, так как мой телефон не звонит при доставке сообщений из системы Twitter, я параллельно хочу получать текстовые уведомления о наиболее важных событиях. Я могу просматривать информацию о достижении пороговых значений на любом сервере с помощью сообщений Twitter и, таким образом, иметь журнал текущих событий в сети, но не обязательно использовать данную схему для передачи предупреждений о критических ситуациях.

В дополнение к стандартным сенсорам, система OpManager предлагает технологии мониторинга производительности по протоколу SNMP, разработанные поставщиками для таких устройств, как Dell Power-Edge, HP Proliant и IBM Blade Center. OpManager также может быть интегрирован с Google Maps API, благодаря чему вы сможете добавлять свои устройства на карту Google. Однако для этого придется приобрести учетную запись Google Maps API Premium (если вы не планируете сделать свою карту сети общедоступной) в соответствии с условиями лицензирования бесплатной версии системы Google Maps API.

Для обработки ситуаций, когда администратор получает предупреждение, но никак не реагирует на него в течение определенного времени, в системе OpManager можно настроить отправку дополнительного предупреждения другому администратору. Например, сотрудник, обычно отвечающий за обработку критических событий для определенной группы серверов, может оказаться занят или болен. На такой случай имеет смысл настроить дополнительное предупреждение, которое привлечет внимание другого администратора, если первое предупреждение не было просмотрено или сброшено в течение заданного количества часов/минут.

Среди трех рассматриваемых продуктов только система OpManager имела раздел, предназначенный для мониторинга качества обменов VoIP в глобальной сети. Для использования инструментов мониторинга VoIP необходимо, чтобы устройства, как в сети источника, так и в сети назначения, поддерживали технологию Cisco IP SLA. Кроме того, система OpManager, интерфейс которой показан на экране 2, включает в себя больше сенсоров и рабочих панелей, чем любой из конкурирующих продуктов.

Экран 2. Интерфейс OpManager Professional

SolarWinds ipMonitor

SolarWinds ipMonitor
ЗА: неограниченное количество устройств по очень низкой цене; простота в использовании.
ПРОТИВ: отсутствует механизм согласования действий администраторов.
ОЦЕНКА: 4 из 5.
ЦЕНА: 1995 долл. - количество устройств не ограничено (25 сенсоров бесплатно).
РЕКОМЕНДАЦИИ: если бюджет ограничен, а вам необходимо организовать мониторинг большого числа устройств, если процесс мониторинга не требует сложных решений и вам подходит внесистемный подход к согласованию действий администраторов, система компании SolarWinds - ваш выбор.
КОНТАКТНАЯ ИНФОРМАЦИЯ: SolarWinds, www.solarwinds.com

После первого знакомства с системой ipMonitor ее интерфейс, изображенный на экране 3, показался мне весьма запутанным. Я чуть не вечность потратил на то, чтобы найти место, где настраивается частота проверки системой отдельных системных сенсоров (по умолчанию опрос выполнялся каждые 300 секунд). Однако после использования ipMonitor в течение нескольких недель я обнаружил, что эта система чрезвычайно проста в применении и обладает достаточными возможностями для качественного мониторинга сети. С помощью ipMonitor можно настроить сканирование «по умолчанию» таким образом, что любая служба или параметр производительности будут всегда включены в будущие процессы сканирования. Вдобавок к стандартным (и названным выше) сенсорам, система ipMonitor предлагает сенсор журнала событий Windows, который можно использовать для отправки предупреждений при обнаружении критических событий.

Экран 3. Интерфейс SolarWinds ipMonitor

С другой стороны, система ipMonitor не имеет механизмов отслеживания/назначения адресатов предупреждений. Это не имеет значения, если в компании один администратор сети, но более крупные ИТ-подразделения, скорее всего, сочтут существенным недостатком неспособность системы подтверждать получение предупреждений, назначать адресатов и сбрасывать предупреждения. Если администраторы забывают координировать свои действия вне системы, возможны ситуации, когда несколько администраторов получают одно и то же предупреждение и начинают работать над одной и той же проблемой. Впрочем, для разрешения подобных конфликтов достаточно разработать согласованный алгоритм реагирования на предупреждения - например, если разделить ответственность за сетевые устройства между администраторами, то не будет возникать вопросов о том, кто должен заняться решением той или иной проблемы.

Время принимать решение

Я уже решил для себя, какой из трех продуктов больше подойдет к моему окружению. Я остановился на системе ManageEngine OpManager с лицензией на 50 устройств по нескольким причинам.

Прежде всего, мне нужна возможность отслеживать максимальное количество параметров своего окружения, так как это лучший способ избежать неожиданных отказов. В данном вопросе система OpManager, безусловно, впереди конкурентов. Вторая причина - бюджет. Я могу продолжать использовать наши старые средства мониторинга, работающие по принципу «включено/выключено», для рабочих станций и принтеров, и таким образом избежать затрат на дополнительные лицензии. Наконец, мне действительно понравился подход, использованный сотрудниками ManageEngine при разработке OpManager, позволяющий задействовать преимущества новых технологий, и я считаю полностью оправданными затраты на приобретение годового пакета обслуживания и поддержки, позволяющего загружать обновления, появляющиеся по мере развития продукта.

Нейт Мак-Алмонд ([email protected]) - директор по ИТ в агентстве по оказанию социальных услуг, имеет сертификаты MCSE, Security и Network+, специализируется на решениях с тонкими клиентами и медицинских базах данных

Управление и мониторинг ИТ-инфраструктуры – одна из главных задач ИТ-департамента любой компании. Решения HP Software позволят упростить задачу системных администраторов и организовать эффективный контроль сети организации

Современная ИТ-инфраструктура представляет собой сложную гетерогенную сеть, включающую в себя телекоммуникационные, серверные и программные решения разных производителей, работающие на базе различных стандартов. Ее сложность и масштабность определяют высокий уровень автоматизированных средств мониторинга и управления, которые должны использоваться для обеспечения надежной работы сети. Программные продукты HP Software помогут решить задачи мониторинга на всех уровнях, от инфраструктуры (сетевого оборудования, серверов и систем хранения) до контроля качества работы бизнес-сервисов и бизнес-процессов.

Системы мониторинга: какими они бывают?

В современных платформах для мониторинга ИТ существует 3 направления для развития и вывода мониторинга на новый уровень. Первую называют «Мост» («Зонтичная система», «Менеджер менеджеров). Ее концепция заключается в утилизации инвестиций в уже имеющиеся системы, которые выполняют задачи мониторинга отдельных частей инфраструктуры, и превращении самих систем в информационные агенты. Такой подход является логичным развитием обычного мониторинга ИТ инфраструктуры. В качестве предпосылок внедрения системы типа «Мост» может служить принятие ИТ-отделом решения консолидировать разрозненные системы мониторинга для перехода к мониторингу ИТ услуг/систем как чего то целого, разрозненные системы не способные показать всю картину, случай не диагностирования серьезного сбоя приложений, а также большое количество предупреждений и аварийных сигналов, отсутствие единого охвата, приоритезации и выявления причинно-следственной связи.

Результатом внедрения станет автоматизированный сбор всех доступных событий и метрик ИТ-инфраструктуры, сопоставление их состояния и влияния на «здоровье» сервиса. В случае сбоя оператор получит доступ к панели, отображающей корневую причину сбоя с рекомендациями по ее устранению. В случае типового сбоя есть возможность назначить скрипт, автоматизирующей необходимые действия оператора.

Следующая тенденция называется «Аналитика аномалий». Здесь, как и в первом случае, метрики и события собираются из ряда систем инфраструктурного мониторинга, а кроме того, настроен сбор логов ИТ и безопасности. Таким образом, ежеминутно накапливается огромное количество информации, и компания хочет получить преимущества от ее утилизации. Для внедрения «Аналитики аномалий» существует целый ряд причин: сложность своевременного сбора, хранения и анализа всех данных, потребность реактивно устранять неизвестные проблемы, невозможность быстрого определения важной для устранения сбоев информации, сложность выполнения вручную операций поиска отдельных журналов, а также необходимость определения отклонений и повторяющихся сбоев.

Внедрение системы позволит реализовать автоматизированный сбор событий, метрик и логов, хранение этой информации необходимый период времени, а также анализ любой информации, включая журналы, сведения о производительности и данные систем. Помимо этого, станет возможным прогнозирование и разрешение любых типов проблем и предотвращение известных сбоев.

И наконец – «Управление производительностью приложений», или выявление и устранение сбоев в транзакциях конечных пользователей. Такое решение может быть полезным дополнением, работающим в плотном контакте с предыдущими двумя. При этом такая система сама по себе тоже может давать быстрый результат от внедрения. В данном случае в компании есть приложения, важные для бизнеса. При этом важны доступность и качество услуги, одним из ключевых элементов которой является приложение (интернет-банкинг, CRM, биллинг и т. д.). При падении доступности или качества предоставления этого сервиса, как правило, заходит речь о проактивности и быстром восстановлении. Такая система обычно внедряется, когда необходимо повысить доступность сервисов приложений и производительность, а также сократить среднее время восстановления работоспособности. Кроме того, такой подход хорош для устранения лишних затрат и снижения рисков, связанных с соглашением об уровне обслуживания (SLA), и для предотвращения ухода заказчиков (защита бизнеса).

Результаты внедрения в зависимости от главной задачи могут отличаться. В общем случае это позволяет реализовать выполнение типичных действий пользователя «роботом» из разных регионов\сегментов сети, разбор «зеркалированного» трафика, проверку доступности и качества работы сервисов с выявлением узких мест, информирование оператора о необходимости восстановить работоспособность с указанием места деградации. При необходимости становится возможна глубокая диагностика работы приложения для поиска причин систематического ухудшения работы сервисов.

Указанные выше подходы могут быть реализованы с помощью продуктов HP Software, о которых и пойдет речь далее.

«Мост» от HP

HP Operations Bridge представляет новейшее поколение «зонтичных систем мониторинга». Решение объединяет данные мониторинга от собственных агентов, различных модулей мониторинга HP Software и средств мониторинга других разработчиков. Поток событий от всех источников информации накладывается на ресурсно-сервисную модель, к нему применяются корреляционные механизмы для определения того, какие события являются причинами, симптомами и следствиями.

Отдельно следует остановиться на ресурсно-сервисной модели, а точенне моделях, так как таких моделей может не ограниченное количество для анализа информации в разных ракурсах. От ее полноты и актуальности зависит возможность решения выполнять корреляцию потока событий. Для поддержания актуальности моделей используются средства разведки на базе агентов и безагентных технологий, позволяющих получать детальную информацию о компонентах сервиса, взаимосвязях между ними и взаимном влиянии друг на друга. Также есть возможность импорта данных о топологии сервиса из внешних источников – систем мониторинга.

Еще один важный аспект – удобство управления. В сложных и динамично меняющихся средах важно обеспечить подстройку системы мониторинга при изменении структуры систем и добавлении новых сервисов. В Operations Bridge входит компонент Monitoring Automation, который позволяет в автоматическом режиме настраивать системы, вводимые в периметр мониторинга, для чего используются данные о сервисно-ресурсных моделях. Одновременно поддерживается конфигурирование и изменение уже выполненных ранее настроек мониторинга.

Если раньше администраторы могли выполнять одинаковые настройки однотипных компонентов инфраструктуры (например, метрик на Windows, Linux или UNIX-серверах), что требовало немалого времени и усилий, то теперь можно динамично и централизованно настраивать пороговые значения для метрики в разрезе услуги или сервиса.

Аналитика приложений

Использование традиционного подхода к мониторингу подразумевает, что изначально известно, какие параметры контролировать и какие события отслеживать. Растущая сложность и динамика развития ИТ-инфраструктур заставляет искать другие подходы, так как становится все сложнее контролировать все аспекты работы системы.

HP Operations Analytics позволяет собрать и сохранить все данные о работе приложения: лог-файлы, телеметрию, бизнес-метрики и метрики производительности, системные события и т.д., и использовать аналитические механизмы для выявления тенденций и прогнозирования. Решение приводит собранные данные к единому формату и затем, осуществляя контекстный выбор, на основании данных лог-файлов отображает на временной шкале, что, в какой момент и на какой системе происходило. Продукт предоставляет несколько форм визуализации данных (например, интерактивная «тепловая карта» и топология взаимосвязей лог-файлов) и использует функцию помощника для того, чтобы в контексте события или по введенному в строке поиска запросу найти всю совокупность данных, собранных за конкретный период. Это помогает оператору понять, что привело к сбою (или, при использовании данных HP SHA вместе с данными HP OA, сделать соответствующий прогноз), а также выявить как виновника, так и корневую причину случившегося сбоя. HP Operations Analytics дает возможность воспроизвести картину работы сервиса и окружения в момент возникновения сбоя и изолировать его в контексте и времени.

Еще один аналитический инструмент – HP Service Health Analyzer. HP SHA выявляет аномальное поведение контролируемых элементов инфраструктуры с целью предупреждения возможного отказа в предоставлении сервисов или нарушения заданных параметров их предоставления. В продукте применяются специальные алгоритмы статистического анализа данных на основе топологической сервисно-ресурсной модели HP BSM. С их помощью обеспечивается возможность построения профиля нормальных значений параметров производительности, собираемых как с программно-аппаратных платформ, так и с других модулей BSM (например, HP RUM, HP BPM), характеризующих состояние сервисов. В подобные профили вводятся типовые значения параметров с учетом дней недели и времени суток. SHA выполняет исторический и статистический анализ накопленных данных (для понимания сути выявленных данных), а также осуществляет сопоставление с имеющимся динамическим профилем (baselining).

Контроль производительности приложений

Когда речь заходит контроле производительности приложений, следует выделить следующие компоненты решения HP:

• HP Real User Monitoring (HP RUM) – контроль прохождения транзакций реальных пользователей;
• HP Business Process Monitoring (HP BPM) – контроль доступности приложения методом эмуляции действий пользователей;
• HP Diagnostics – контроль прохождения запросов внутри приложения.

HP RUM и HP BPM позволяют оценить доступность приложения с точки зрения конечного пользователя.

HP RUM разбирает сетевой трафик, выявляя в нем транзакции реальных пользователей. При этом можно контролировать обмен данными между компонентами приложения: клиентской частью, сервером приложений и базой данных. Это дает возможность отследить активность пользователей, время обработки различных транзакций, а также определить взаимосвязи между действиями пользователей и бизнес-метриками. Используя HP RUM, операторы службы мониторинга смогут мгновенно получать оперативные уведомления о проблемах в доступности сервисов и информацию об ошибках, с которыми столкнулись пользователи.

HP BPM представляет собой средство активного мониторинга, которое выполняет синтетические пользовательские транзакции, для контролируемых систем неотличимые от реальных. Данные мониторинга HP BPM удобно использовать для расчета реального SLA, так как «робот» выполняет идентичные проверки в одинаковые промежутки времени, обеспечивая постоянный контроль качества обработки типовых (или наиболее критичных) запросов. Настроив пробы для выполнения синтетических транзакций из нескольких точек (например, из разных офисов компании), можно также оценить доступность сервиса для различных пользователей с учетом их расположения и каналов связи. Для эмуляции активности HP BPM использует инструмент Virtual User Generator (VuGen), который также применяется в популярном продукте нагрузочного тестирования HP LoadRunner. VuGen поддерживает огромный спектр различных протоколов и технологий, благодаря чему можно контролировать доступность практически любых сервисов, а также использовать единый набор скриптов для тестирования и мониторинга.
Если же причина сбоев или замедления работы сервиса находится внутри таких технологий, как Java, .NET и т. д., поможет HP Diagnostics.

Решение обеспечивает глубокий контроль Java, .NET, Python на платформах Windows, Linux и Unix. Продукт поддерживает разнообразные сервера приложений (Tomcat, Jboss, WebLogic, Oracle и др.), MiddleWare и базы данных. Специализированные агенты HP Diagnostics устанавливаются на серверах приложений и собирают данные, специфичные для конкретной технологии. Например, для Java-приложения можно увидеть, какие запросы выполняются, какие методы используются и сколько времени тратится на их отработку. Автоматически отрисовывается структура приложения, становится понятно, как задействованы его компоненты. HP Diagnostics позволяет отследить прохождение бизнес-транзакций внутри комплексных приложений, определить узкие места и обеспечить экспертов необходимой информацией для принятия решений.

Дистрибуция решений НР в

РЕФЕРАТ

Настоящий документ является техническим проектом разработки и внедрения системы сетевого мониторинга верхнепышминской городской сети передачи данных общего доступа ООО Геркон. В проекте проведено исследование существующих систем сетевого мониторинга, анализ текущей ситуации на предприятии и обоснован выбор конкретных компонентов системы сетевого мониторинга.

Документ содержит описание проектных решений и спецификации оборудования.

Результатом проектирования являются разработанные решения по внедрению и использованию системы:

§Полное описание всех этапов проектирования, разработки и внедрения системы;

§Руководство системного администратора, включающее описание пользовательского интерфейса системы.

Настоящий документ представляет законченные проектные решения и может быть использован для внедрения системы.

ПЕРЕЧЕНЬ ЛИСТОВ ГРАФИЧЕСКИХ ДОКУМЕНТОВ

Таблица 1 - Перечень листов графических документов

1Системы сетевого мониторинга220100 4010002Логическая структура сети220100 4010003Алгоритм работы ядра сетевого мониторинга и оповещений220100 4010004Структура анализатора загрузки сетевых интерфейсов220100 4010005Структура сборщика системных журналов событий220100 4010006Интерфейс Nagios220100 4010007Обобщенная структура системы сетевого мониторинга220100 401000

ПЕРЕЧЕНЬ УСЛОВНЫХ ОБОЗНАЧЕНИЙ, СИМВОЛОВ И ТЕРМИНОВ

Ethernet - стандарт передачи данных, выпущенный IEEE. Определяет как передавать или получать данные из общей среды передачи данных. Формирует нижний транспортный уровень и используется различными высокоуровневыми протоколами. Обеспечивает скорость передачи данных 10Мбит/сек.

Fast Ethernet - технология передачи данных со скоростью 100Мбит/сек, использующая CSMA/CD метод, как и 10Base-T.

FDDI - Fiber Distributed Data Interface - волоконно-оптический интерфейс распределенной передачи данных - технология передачи данных со скоростью 100Мбит/сек, использующая метод маркерного кольца.

IEEE - Institute of Electrical and Electronic Engineers (Институт инженеров по электротехнике и электронике) - организация, разрабатывающая и публикующая стандарты.

LAN - Local Area Network - локальная сеть, ЛВС. адрес - Media Access Control - идентификационный номер сетевого устройства, определяемый, как правило, производителем.

RFC - Request for Comments - свод документов, выпускаемых организацией IEEE, и включающих в себя описание стандартов, спецификаций и др.

TCP/IP - Transmission Control Protocol/ Internet Protocol - протокол управления передачей/протокол Internet.

ЛВС - Локальная вычислительная сеть.

ОС - Операционная система.

ПО - Программное обеспечение.

СКС - Структурированная кабельная система.

СУБД - Система управления базами данных.

Тренд - Долговременная статистика, которая позволяет построить так называемую тенденцию.

ЭВМ - Электронно-вычислительная машина.

ВВЕДЕНИЕ

Информационная инфраструктура современного предприятия представляет собой сложнейший конгломерат разномасштабных и разнородных сетей и систем. Чтобы обеспечить их слаженную и эффективную работу, необходима управляющая платформа корпоративного масштаба с интегрированными инструментальными средствами. Однако до недавнего времени сама структура индустрии сетевого управления препятствовала созданию таких систем - «игроки» этого рынка стремились к лидерству, выпуская продукты ограниченной области действия, использующие средства и технологии, не совместимые с системами других поставщиков.

Сегодня ситуация меняется к лучшему - появляются продукты, претендующие на универсальность управления всем разнообразием корпоративных информационных ресурсов, от настольных систем до мэйнфреймов и от локальных сетей до ресурсов Сети. Одновременно приходит осознание того, что управляющие приложения должны быть открыты для решений всех поставщиков .

Актуальность данной работы обусловлена тем, что в связи с распространением персональных компьютеров и созданием на их основе автоматизированных рабочих мест (АРМ) возросло значение локальных вычислительных сетей (ЛВС), диагностика которых, является объектом нашего исследования. Предметом исследования являются основные методы организации и проведения диагностики современных компьютерных сетей.

"Диагностика локальной сети" - процесс (непрерывного) анализа состояния информационной сети. При возникновении неисправности сетевых устройств фиксируется факт неисправности, определяется ее место и вид. Сообщение о неисправности передается, устройство отключается и заменяется резервным .

Сетевой администратор, на которого чаще всего ложатся функции по проведению диагностики, должен начинать изучать особенности своей сети уже на фазе ее формирования т.е. знать схему сети и подробное описание конфигурации программного обеспечения с указанием всех параметров и интерфейсов. Для оформления и хранения этой информации подойдут специальные системы документирования сети. Используя их, системный администратор, будет заранее знать все возможные «скрытые дефекты» и «узкие места» своей системы, для того, чтобы в случае возникновения нештатной ситуации знать, с чем связана проблема с оборудованием или программным обеспечением, повреждена программа или к ошибке привели действия оператора.

Сетевому администратору следует помнить, что с точки зрения пользователей качество работы прикладного программного обеспечения в сети оказывается определяющим. Все прочие критерии, такие как число ошибок передачи данных, степень загруженности сетевых ресурсов, производительность оборудования и т. п., являются вторичными. "Хорошая сеть" - это такая сеть, пользователи которой не замечают, как она работает.

Предприятие

Преддипломная практика проходила на предприятии ООО «Геркон» в отделе сопровождения в должности системного администратора. Предприятие предлагает услуги доступа в Интернет в городах Верхняя Пышма и Среднеуральск по технологии Ethernet и коммутируемым (dial-up) каналам с 1993 года и является одним из первых поставщиков услуг Интернет в этих городах. Правила предоставления услуг урегулированы публичной офертой и регламентом.

Научные и производственные задачи подразделения

Отдел сопровождения решает следующий спектр задач в пределах данного предприятия:

§техническая и технологическая организация предоставления доступа в Интернет по коммутируемым и выделенным каналам;

§техническая и технологическая организация беспроводного доступа в Интернет;

§выделение дискового пространства для хранения и обеспечения работы сайтов (хостинг);

§поддержка работы почтовых ящиков или виртуального почтового сервера;

§размещение оборудования клиента на площадке провайдера (колокация);

§аренда выделенных и виртуальных серверов;

§резервирование данных;

§развертывание и поддержка корпоративных сетей частных предприятий.

1. СИСТЕМЫ СЕТЕВОГО МОНИТОРИНГА

Несмотря на множество приемов и инструментов обнаружения и устранения неполадок в компьютерных сетях, «почва под ногами» сетевых администраторов все еще остается достаточно зыбкой. Компьютерные сети все чаще включают волоконно-оптические и беспроводные компоненты, наличие которых делает бессмысленным применение традиционных технологий и инструментов, предназначенных для обычных медных кабелей. Вдобавок к нему при скоростях свыше 100 Мбит/с традиционные подходы к диагностике зачастую перестают работать, даже если средой передачи является обычный медный кабель. Однако, возможно, наиболее серьезным изменением в компьютерных сетевых технологиях, с которым пришлось столкнуться администраторам, стал неизбежный переход от сетей Ethernet с разделяемой средой передачи к коммутируемым сетям, в которых в качестве коммутируемых сегментов часто выступают отдельные серверы или рабочие станции.

Правда, по мере осуществления технологических преобразований некоторые старые проблемы решились сами собой. Коаксиальный кабель, в котором выявить электротехнические неисправности всегда было труднее, чем в случае витой пары, становится редкостью в корпоративных средах. Сети Token Ring, главной проблемой которых была их несхожесть с Ethernet (а вовсе не слабость в техническом отношении), постепенно заменяются коммутируемыми сетями Ethernet. Порождающие многочисленные сообщения об ошибках протоколов сетевого уровня протоколы, такие, как SNA, DECnet и AppleTalk, замещаются протоколом IP. Сам же стек протоколов IP стал более стабильным и простым для поддержки, что доказывают миллионы клиентов и миллиарды страниц Web в Internet. Даже закоренелым противникам Microsoft приходится признать, что подключение нового клиента Windows к Internet существенно проще и надежнее установки применявшихся ранее стеков TCP/IP сторонних поставщиков и отдельного программного обеспечения коммутируемого доступа.

Как бы многочисленные современные технологии ни затрудняли выявление неполадок и управление производительностью сетей, ситуация могла бы оказаться еще тяжелее, если бы технология АТМ получила широкое распространение на уровне ПК. Свою положительную роль сыграло и то, что в конце 90-х, не успев получить признание, были отвергнуты и некоторые другие высокоскоростные технологии обмена данными, включая Token Ring с пропускной способностью 100 Мбит/с, 100VG-AnyLAN и усовершенствованные сети ARCnet. Наконец, в США был отклонен очень сложный стек протоколов OSI (который, правда, узаконен рядом правительств европейских стран) .

Рассмотрим некоторые актуальные проблемы, возникающие у сетевых администраторов предприятий.

Иерархическая топология компьютерных сетей с магистральными каналами Gigabit Ethernet и выделенными портами коммутаторов на 10 или даже 100 Мбит/с для отдельных клиентских систем, позволила увеличить максимальную пропускную способность, потенциально доступную пользователям, как минимум в 10-20 раз. Конечно, в большинстве компьютерных сетей существуют узкие места на уровне серверов или маршрутизаторов доступа, поскольку приходящаяся на отдельного пользователя пропускная способность существенно меньше 10 Мбит/с. В связи с этим замена порта концентратора с пропускной способностью 10 Мбит/с на выделенный порт коммутатора на 100 Мбит/с для конечного узла отнюдь не всегда приводит к значительному увеличению скорости. Однако если учесть, что стоимость коммутаторов в последнее время снизилась, а на большинстве предприятий проложен кабель Категории 5, поддерживающий технологию Ethernet на 100 Мбит/с, и установлены сетевые карты, способные работать на скорости 100 Мбит/с сразу после перезагрузки системы, то становится ясно, почему так нелегко сопротивляться искушению модернизации. В традиционной локальной сети с разделяемой средой передачи анализатор протоколов или монитор может исследовать весь трафик данного сегмента сети.

Рис. 1.1 - Традиционная локальная сеть с разделяемой средой передачи и анализатором протоколов

Хотя преимущество коммутируемой сети в производительности иногда почти не заметно, распространение коммутируемых архитектур имело катастрофические последствия для традиционных средств диагностики. В сильно сегментированной сети анализаторы протоколов способны видеть только одноадресный трафик на отдельном порту коммутатора, в отличие от сети прежней топологии, где они могли тщательно исследовать любой пакет в домене коллизий. В таких условиях традиционные инструменты мониторинга не могут собрать статистику по всем «диалогам», потому что каждая «переговаривающаяся» пара оконечных точек пользуется, в сущности, своей собственной сетью.

Рис. 1.2 - Коммутируемая сеть

В коммутируемой сети анализатор протоколов в одной точке может «видеть» только единственный сегмент, если коммутатор не способен зеркально отображать несколько портов одновременно.

Для сохранения контроля над сильно сегментированными сетями производители коммутаторов предлагают разнообразные средства для восстановления полной «видимости» сети, однако на этом пути остается немало трудностей. В поставляемых сейчас коммутаторах обычно поддерживается «зеркальное отображение» портов, когда трафик одного из них дублируется на ранее незадействованный порт, к которому подключается монитор или анализатор.

Однако «зеркальное отображение» обладает рядом недостатков. Во-первых, в каждый момент времени виден только один порт, поэтому выявить неполадки, затрагивающие сразу несколько портов, очень непросто. Во-вторых, зеркальное отражение может привести к снижению производительности коммутатора. В-третьих, на зеркальном порту обычно не воспроизводятся сбои физического уровня, а иногда даже теряются обозначения виртуальных локальных сетей. Наконец, во многих случаях не могут в полной мере зеркально отображаться полнодуплексные каналы Ethernet.

Частичным решением при анализе агрегированных параметров трафика является использование возможностей мониторинга агентов mini-RMON, тем более что они встроены в каждый порт большинства коммутаторов Ethernet. Хотя агенты mini-RMON не поддерживают группу объектов Capture из спецификации RMON II, обеспечивающих полнофункциональный анализ протоколов, они тем не менее позволяют оценить уровень использования ресурсов, количество ошибок и объем многоадресной рассылки.

Некоторые недостатки технологии зеркального отображения портов могут быть преодолены установкой «пассивных ответвителей», производимых, например, компанией Shomiti. Эти устройства представляют собой заранее устанавливаемые Y-коннекторы и позволяют отслеживать с помощью анализаторов протокола или другого устройства не регенерированный, а реальный сигнал .

Следующей актуально проблемой, является проблема с особенностями оптики. Администраторы компьютерных сетей обычно используют специализированное оборудование диагностики оптических сетей только для решения проблем с оптическими кабелями. Обычное стандартное программное обеспечение управления устройствами на базе SNMP или интерфейса командной строки способно выявить проблемы на коммутаторах и маршрутизаторах с оптическими интерфейсами. И только немногие сетевые администраторы сталкиваются с необходимостью проводить диагностику устройств SONET.

Что касается волоконно-оптических кабелей, то причин для возникновения возможных неисправностей в них существенно меньше, чем в случае медного кабеля. Оптические сигналы не вызывают перекрестных помех, появляющихся от того, что сигнал одного проводника индуцирует сигнал на другом - этот фактор наиболее усложняет диагностическое оборудование для медного кабеля. Оптические кабели невосприимчивы к электромагнитным шумам и индуцированным сигналам, поэтому их не требуется располагать подальше от электромоторов лифтов и ламп дневного света, т. е. из сценария диагностики все эти переменные можно исключить.

Сила сигнала, или оптическая мощность, в данной точке на самом деле является единственной переменной, которую требуется измерить при поиске неисправностей в оптических сетях. Если же можно определить потери сигнала на всем протяжении оптического канала, то можно будет идентифицировать практически любую проблему. Недорогие дополнительные модули для тестеров медного кабеля позволяют проводить оптические измерения.

Предприятиям, развернувшим крупную оптическую инфраструктуру и самостоятельно ее обслуживающим, может понадобиться приобрести оптический временный рефлектометр (Optical Time Domain Reflecto-meter, OTDR), выполняющего те же функции для оптического волокна, что и рефлектометр для медного кабеля (Time Domain Reflectometer, TDR). Прибор действует подобно радару: он посылает импульсные сигналы по кабелю и анализирует их отражения, на основании которых он выявляет повреждения в проводнике или какую-либо другую аномалию, и затем сообщает експерту, в каком месте кабеля следует искать источник проблемы.

Хотя различные поставщики кабельных соединителей и разъемов упростили процессы терминирования и разветвления оптического волокна, для этого по-прежнему требуется некоторый уровень специальных навыков, и при разумной политике предприятие с развитой оптической инфраструктурой вынуждено будет обучать своих сотрудников. Как бы хорошо ни была проложена кабельная сеть, всегда существует возможность физического повреждения кабеля в результате какого-либо неожиданного происшествия .

При диагностике беспроводных локальных сетей стандарта 802.11b также могут возникнуть проблемы. Сама по себе диагностика, столь же проста, как и в случае сетей Ethernet на базе концентраторов, так как беспроводная среда передачи информации разделяется между всеми обладателями клиентских радиоустройств. Компания Sniffer TechНlogies первой предложила решение для анализа протоколов таких сетей с пропускной способностью до 11 Мбит/с, и впоследствии большинство лидирующих поставщиков анализаторов представили аналогичные системы.

В отличие от концентратора Ethernet с проводными соединениями, качество беспроводных клиентских соединений далеко от стабильного. Микроволновые радиосигналы, используемые во всех вариантах локальной передачи, слабы и порой непредсказуемы. Даже небольшие изменения положения антенны могут серьезно сказаться на качестве соединений. Точки доступа беспроводной локальной сети снабжаются консолью управления устройствами, и это часто более действенный метод диагностики, чем посещение клиентов беспроводной сети и наблюдение за пропускной способностью и условиями возникновения ошибок с помощью портативного анализатора.

Хотя проблемы синхронизации данных и установки устройств, возникающие у пользователей персональных цифровых секретарей (PDA), более естественно соответствуют задачам группы технической поддержки, а не обязанностям сетевого администратора, нетрудно предвидеть, что в недалеком будущем многие такие устройства превратятся из отдельных вспомогательных средств, дополняющих ПК, в полноправных сетевых клиентов.

Как правило, операторы корпоративных беспроводных сетей будут (или должны) препятствовать развертыванию чрезмерно открытых систем, в которых любой пользователь, находящийся в зоне действия сети и обладающий совместимой интерфейсной картой, получает доступ к каждому информационному кадру системы. Протокол безопасности беспроводных сетей WEP (Wired Equivalent Privacy) обеспечивает аутентификацию пользователей, гарантию целостности и шифрование данных, однако, как это обычно случается, совершенная система безопасности осложняет анализ причин сетевых неполадок. В защищенных сетях с поддержкой WEP специалисты по диагностике должны знать ключи или пароли, защищающие информационные ресурсы и контролирующие доступ в систему. При доступе в режиме приема всех пакетов анализатор протоколов сможет видеть все заголовки кадров, но содержащаяся в них информация без наличия ключей будет бессмысленной .

При диагностировании туннелированных каналов, которые многие производители называют виртуальными частными сетями с удаленным доступом, возникающие проблемы аналогичны имеющим место при анализе беспроводных сетей с шифрованием. Если трафик не проходит через туннелированный канал, то причину неисправности определить нелегко. Это может быть ошибка аутентификации, поломка на одной из оконечных точек или затор в общедоступной зоне Internet. Попытка использования анализатора протоколов для выявления высокоуровневых ошибок в туннелированном трафике будет пустой тратой сил, потому что содержание данных, а также заголовки прикладного, транспортного и сетевого уровней зашифрованы. Вообще, меры, принимаемые в целях повышения уровня безопасности корпоративных сетей, обычно затрудняют выявление неисправностей и проблем производительности. Межсетевые экраны, proxy-серверы и системы выявления вторжений могут дополнительно осложнить локализацию неполадок .

Таким образом, проблема диагностики компьютерных сетей является актуальной и в конечном счете, диагностирование неисправностей является задачей управления. Для большинства критически важных корпоративных систем, проведение продолжительных восстановительных работ не допустимо, поэтому единственным решением будет использование резервных устройств и процессов, способных взять на себя необходимые функции немедленно после возникновения сбоев. На некоторых предприятиях сети всегда имеют дополнительный резервный компонент на случай сбоя основного, т. е. n х 2 компонентов, где n - количество основных компонентов, необходимое для обеспечения приемлемой производительности. Если среднее время восстановления (Mean Time To Repair, MTTR) достаточно велико, то может понадобиться еще большая избыточность. Дело в том, что время устранения неисправности предсказать нелегко, а значительные затраты в течение непредсказуемого периода восстановления являются признаком плохого управления.

Для менее важных систем резервирование может оказаться экономически неоправданным, и в этом случае будет целесообразно вкладывать средства в наиболее эффективные инструменты (и в обучение персонала), чтобы максимально ускорить процесс диагностики и устранения неисправностей на предприятии. Кроме того, поддержку определенных систем можно доверить сторонним специалистам, либо привлекая их на предприятие по контракту, либо пользуясь возможностями внешних центров обработки данных, либо обращаясь к провайдерам услуг по сопровождению приложений (Application Service Providers, ASP) или провайдерам услуг управления. Помимо затрат наиболее значительным фактором, влияющим на решение об обращении к услугам сторонних организаций, можно считать уровень компетентности собственного персонала. Сетевые администраторы должны решить, не является ли некоторая конкретная функция настолько тесно связанной со специфическими задачами предприятия, что от стороннего специалиста нельзя будет ожидать более качественного выполнения работы, чем это будет сделано силами служащих компании.

Почти сразу после того, как были развернуты первые корпоративные сети, надежность которых оставляла желать лучшего, производители и разработчики выдвинули концепцию «самовосстанавливающихся сетей». Современные сети, безусловно, надежнее, чем они были в 90-х гг., но не потому, что неполадки стали самоустраняться. Ликвидация сбоев программного обеспечения и аппаратных средств современных сетей все еще требуют вмешательства человека, и в ближайшей перспективе в таком положении дел не предвидится никаких принципиальных изменений. Методы и инструменты диагностики вполне соответствуют современной практике и технологиям, но они еще не достигли такого уровня, который позволил бы значительно сэкономить время сетевых администраторов в их борьбе с неполадками сетей и дефицитом производительности .

1.1 Программные средства диагностики

Среди программных средств диагностики компьютерных сетей, можно выделить специальные системы управления сетью (Network Management Systems) - централизованные программные системы, которые собирают данные о состоянии узлов и коммуникационных устройств сети, а также данные о трафике, циркулирующем в сети. Эти системы не только осуществляют мониторинг и анализ сети, но и выполняют в автоматическом или полуавтоматическом режиме действия по управлению сетью - включение и отключение портов устройств, изменение параметров мостов адресных таблиц мостов, коммутаторов и маршрутизаторов и т.п. Примерами систем управления могут служить популярные системы HPOpenView, SunNetManager, IBMNetView.

Средства управления системой (System Management) выполняют функции, аналогичные функциям систем управления, но по отношению к коммуникационному оборудованию. Вместе с тем, некоторые функции этих двух видов систем управления могут дублироваться, например, средства управления системой могут выполнять простейший анализ сетевого трафика.

Экспертные системы. Этот вид систем аккумулирует человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние. Экспертные системы часто реализуются в виде отдельных подсистем различных средств мониторинга и анализа сетей: систем управления сетями, анализаторов протоколов, сетевых анализаторов. Простейшим вариантом экспертной системы является контекстно-зависимая help-система. Более сложные экспертные системы представляют собой так называемые базы знаний, обладающие элементами искусственного интеллекта. Примером такой системы является экспертная система, встроенная в систему управления Spectrum компании Cabletron.

1.1.1 Анализаторы протоколов

В ходе проектирования новой или модернизации старой сети часто возникает необходимость в количественном измерении некоторых характеристик сети таких, например, как интенсивности потоков данных по сетевым линиям связи, задержки, возникающие на различных этапах обработки пакетов, времена реакции на запросы того или иного вида, частота возникновения определенных событий и других характеристик.

Для этих целей могут быть использованы разные средства и прежде всего - средства мониторинга в системах управления сетью, которые уже обсуждались ранее. Некоторые измерения на сети могут быть выполнены и встроенными в операционную систему программными измерителями, примером тому служит компонента ОС Windows Performance Monitor. Даже кабельные тестеры в их современном исполнении способны вести захват пакетов и анализ их содержимого .

Но наиболее совершенным средством исследования сети является анализатор протоколов. Процесс анализа протоколов включает захват циркулирующих в сети пакетов, реализующих тот или иной сетевой протокол, и изучение содержимого этих пакетов. Основываясь на результатах анализа, можно осуществлять обоснованное и взвешенное изменение каких-либо компонент сети, оптимизацию ее производительности, поиск и устранение неполадок. Очевидно, что для того, чтобы можно было сделать какие-либо выводы о влиянии некоторого изменения на сеть, необходимо выполнить анализ протоколов и до, и после внесения изменения.

Анализатор протоколов представляет собой либо самостоятельное специализированное устройство, либо персональный компьютер, обычно переносной, класса Нtebook, оснащенный специальной сетевой картой и соответствующим программным обеспечением. Применяемые сетевая карта и программное обеспечение должны соответствовать топологии сети (кольцо, шина, звезда). Анализатор подключается к сети точно также, как и обычный узел. Отличие состоит в том, что анализатор может принимать все пакеты данных, передаваемые по сети, в то время как обычная станция - только адресованные ей. Программное обеспечение анализатора состоит из ядра, поддерживающего работу сетевого адаптера и декодирующего получаемые данные, и дополнительного программного кода, зависящего от типа топологии исследуемой сети. Кроме того, поставляется ряд процедур декодирования, ориентированных на определенный протокол, например, IPX. В состав некоторых анализаторов может входить также экспертная система, которая может выдавать пользователю рекомендации о том, какие эксперименты следует проводить в данной ситуации, что могут означать те или иные результаты измерений, как устранить некоторые виды неисправности сети.

Несмотря на относительное многообразие анализаторов протоколов, представленных на рынке, можно назвать некоторые черты, в той или иной мере присущие всем им:

Пользовательский интерфейс. Большинство анализаторов имеют развитый дружественный интерфейс, базирующийся, как правило, на Windows или Motif. Этот интерфейс позволяет пользователю: выводить результаты анализа интенсивности трафика; получать мгновенную и усредненную статистическую оценку производительности сети; задавать определенные события и критические ситуации для отслеживания их возникновения; производить декодирование протоколов разного уровня и представлять в понятной форме содержимое пакетов.

Буфер захвата. Буферы различных анализаторов отличаются по объему. Буфер может располагаться на устанавливаемой сетевой карте, либо для него может быть отведено место в оперативной памяти одного из компьютеров сети. Если буфер расположен на сетевой карте, то управление им осуществляется аппаратно, и за счет этого скорость ввода повышается. Однако это приводит к удорожанию анализатора. В случае недостаточной производительности процедуры захвата, часть информации будет теряться, и анализ будет невозможен. Размер буфера определяет возможности анализа по более или менее представительным выборкам захватываемых данных. Но каким бы большим ни был буфер захвата, рано или поздно он заполнится. В этом случае либо прекращается захват, либо заполнение начинается с начала буфера .

Фильтры. Фильтры позволяют управлять процессом захвата данных, и, тем самым, позволяют экономить пространство буфера. В зависимости от значения определенных полей пакета, заданных в виде условия фильтрации, пакет либо игнорируется, либо записывается в буфер захвата. Использование фильтров значительно ускоряет и упрощает анализ, так как исключает просмотр ненужных в данный момент пакетов .

Переключатели - это задаваемые оператором некоторые условия начала и прекращения процесса захвата данных из сети. Такими условиями могут быть выполнение ручных команд запуска и остановки процесса захвата, время суток, продолжительность процесса захвата, появление определенных значений в кадрах данных. Переключатели могут использоваться совместно с фильтрами, позволяя более детально и тонко проводить анализ, а также продуктивнее использовать ограниченный объем буфера захвата .

Поиск. Некоторые анализаторы протоколов позволяют автоматизировать просмотр информации, находящейся в буфере, и находить в ней данные по заданным критериям. В то время, как фильтры проверяют входной поток на предмет соответствия условиям фильтрации, функции поиска применяются к уже накопленным в буфере данным.

Методология проведения анализа может быть представлена в виде следующих шести этапов:

Захват данных.

Просмотр захваченных данных.

Анализ данных.

Поиск ошибок. (Большинство анализаторов облегчают эту работу, определяя типы ошибок и идентифицируя станцию, от которой пришел пакет с ошибкой.)

Исследование производительности. Рассчитывается коэффициент использования пропускной способности сети или среднее время реакции на запрос.

Подробное исследование отдельных участков сети. Содержание этого этапа конкретизируется по мере того, как проводится анализ.

Обычно процесс анализа протоколов занимает относительно немного времени - 1-2 рабочих дня.

Большинство современных анализаторов позволяют анализировать сразу несколько протоколов глобальных сетей, таких, как X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, протоколы мостов/маршрутизаторов (3Com, Cisco, Bay Networks и другие). Такие анализаторы позволяют измерять различные параметры протоколов, анализировать трафик в сети, преобразование между протоколами локальных и глобальных сетей, задержку на маршрутизаторах при этих преобразованиях и т. п. Более совершенные приборы предусматривают возможность моделирования и декодирования протоколов глобальных сетей, "стрессового" тестирования, измерения максимальной пропускной способности, тестирования качества предоставляемых услуг. В целях универсальности почти все анализаторы протоколов глобальных сетей реализуют функции тестирования ЛВС и всех основных интерфейсов. Некоторые приборы способны осуществлять анализ протоколов телефонии. А самые современные модели могут декодировать и представлять в удобном варианте все семь уровней OSI. Появление ATM привело к тому, что производители стали снабжать свои анализаторы средствами тестирования этих сетей. Такие приборы могут проводить полное тестирование сетей АТМ уровня E-1/E-3 с поддержкой мониторинга и моделирования. Очень важное значение имеет набор сервисных функций анализатора. Некоторые из них, например возможность удаленного управления прибором, просто незаменимы .

Таким образом, современные анализаторы протоколов WAN/LAН/ДTM позволяют обнаружить ошибки в конфигурации маршрутизаторов и мостов; установить тип трафика, пересылаемого по глобальной сети; определить используемый диапазон скоростей, оптимизировать соотношение между пропускной способностью и количеством каналов; локализовать источник неправильного трафика; выполнить тестирование последовательных интерфейсов и полное тестирование АТМ; осуществить полный мониторинг и декодирование основных протоколов по любому каналу; анализировать статистику в реальном времени, включая анализ трафика локальных сетей через глобальные сети.

1.1.2 Протоколы мониторинга

Протокол SNMP(англ. Simple Network Management Protocol - простой прото-кол управления сетью) - это протокол управления сетями связи на основе архитектуры TCP/IP.

На основе концепции TMN в 1980-1990 гг. различными органами стандартизации был выработан ряд протоколов управления сетями передачи данных с различным спектром реализации функций TMN. К одному из типов таких протоколов управления относится SNMP. Протокол SNMP был разработан с целью проверки функционирования сетевых маршрутизаторов и мостов. Впоследствии сфера действия протокола охватила и другие сетевые устройства, такие как хабы, шлюзы, терминальные сервера, LAN Manager сервера, машины под управлением Windows NT и т.д. Кроме того, протокол допускает возможность внесения изменений в функционирование указанных устройств.

Эта технология, призвана обеспечить управление и контроль за устройствами и приложениями в сети связи путём обмена управляющей информацией между агентами, располагающимися на сетевых устройствах, и менеджерами, расположенными на станциях управления. SNMP определяет сеть как совокупность сетевых управляющих станций и элементов сети (главные машины, шлюзы и маршрутизаторы, терминальные серверы), которые совместно обеспечивают административные связи между сетевыми управляющими станциями и сетевыми агентами.

При использовании SNMP присутствуют управляемые и управляющие системы. В состав управляемой системы входит компонент, называемый агентом, который отправляет отчёты управляющей системе. По существу SNMP агенты передают управленческую информацию на управляющие системы как переменные (такие как «свободная память», «имя системы», «количество работающих процессов»).

Агент в протоколе SNMP - это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB, и тем самым дает им возможность реализовывать функции по управлению и наблюдению за устройством.

Программный агент - резидентная программа, выполняющая функции управления, а также собирающая статистику для передачу ее в информационную базу сетевого устройства.

Аппаратный агент - встроенная аппаратура (с процессором и памятью), в которой хранятся программные агенты.

Переменные, доступные через SNMP, организованы в иерархии. Эти иерархии и другие метаданные (такие, как тип и описание переменной) описываются Базами Управляющей Информации (Management Information Bases (MIBs)).

На сегодня существует несколько стандартов на базы данных управляющей информации . Основными являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного управления RMON MIB. Кроме этого, существуют стандарты для специальных MIB устройств конкретного типа (например, MIB для концентраторов или MIB для модемов), а также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация MIB-I определяла только операции чтения значений переменных. Операции изменения или установки значений объекта являются частью спецификаций MIB-II.

Версия MIB-I (RFC 1156) определяет до 114 объектов, которые подразделяются на 8 групп:

System - общие данные об устройстве (например, идентификатор поставщика, время последней инициализации системы).

Interfaces - описываются параметры сетевых интерфейсов устройства (например, их количество, типы, скорости обмена, максимальный размер пакета).

AddressTranslationTable - описывается соответствие между сетевыми и физическими адресами (например, по протоколу ARP).

InternetProtocol - данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика об IP-пакетах).

ICMP - данные, относящиеся к протоколу обмена управляющими сообщениями ICMP.

TCP - данные, относящиеся к протоколу TCP (например, о TCP-соединениях).

UDP - данные, относящиеся к протоколу UDP (число переданных, принятых и ошибочных UPD-дейтаграмм).

EGP - данные, относящиеся к протоколу обмена маршрутной информацией ExteriorGatewayProtocol, используемому в сети Internet (число принятых с ошибками и без ошибок сообщений).

Из этого перечня групп переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

В версии MIB-II (RFC 1213), принятой в 1992 году, был существенно (до 185) расширен набор стандартных объектов, а число групп увеличилось до 10 .

Агенты RMON

Новейшим добавлением к функциональным возможностям SNMP яв-ляется спецификация RMON, которая обеспечивает удаленное взаимодействие с базой MIB.

Стандарт на RMON появился в ноябре 1991 года, когда Internet Engineering Task Force выпустил документ RFC 1271 под названием "Remote Network Monitoring Management Information Base" ("Информационная база дистанционного мониторинга сетей"). Данный документ содержал описание RMON для сетей Ethernet.- протокол мониторинга компьютерных сетей, расширение SNMP, в основе которого, как и в основе SNMP, лежит сбор и анализ информации о характере информации, передаваемой по сети. Как и в SNMP, сбор информации осуществляется аппаратно-программными агентами, данные от которых поступают на компьютер, где установлено приложение управления сетью. Отличие RMON от своего предшественника состоит, в первую очередь, в характере собираемой информации - если в SNMP эта информация характеризует только события, происходящие на том устройстве, где установлен агент, то RMON требует, чтобы получаемые данные характеризовали трафик между сетевыми устройствами.

До появления RMON протокол SNMP не мог использоваться удален-ным образом, он допускал только локальное управление устройствами. База RMON MIB обладает улучшенным набором свойств для удаленного управления, так как содержит агрегированную информацию об устрой-стве, что не требует передачи по сети больших объемов информации. Объекты RMON MIB включают дополнительные счетчики ошибок в пакетах, более гибкие средства анализа графических трендов и статистики, более мощные средства фильтрации для захвата и анализа отдельных пакетов, а также более сложные условия установления сигналов предупреждения. Агенты RMON MIB более интеллектуальны по сравнению с агентами MIB-I или MIB-II и выполняют значительную часть работы по обработке информации об устройстве, которую раньше выполняли менеджеры. Эти агенты могут располагаться внутри различных коммуникационных устройств, а также быть выполнены в виде отдельных программных модулей, работающих на универсальных ПК и ноутбуках (примером может служить LANalyzerНvell).

Интеллект агентов RMON позволяет им выполнять простые дей-ствия по диагностике неисправностей и предупреждению о возможных отказах - например, в рамках технологии RMON можно собрать данные о нормальном функционировании сети (т. е. выполнить так называемый baselining), а потом выставлять предупреждающие сигналы, когда режим работы сети отклонится от baseline - это может свидетельствовать, в частности, о неполной исправности оборудования. Собрав воедино информацию, получаемую от агентов RMON, приложение управления может помочь администратору сети (находящемуся, например, за тысячи километров от анализируемого сегмента сети) локализовать неисправность и выработать оптимальный план действий для ее устранения.

Сбор информации RMON осуществляется аппаратно-программными зондами, подключаемыми непосредственно к сети. Чтобы выполнить задачу сбора и первичного анализа данных, зонд должен обладать достаточными вычислительными ресурсами и объемом оперативной памяти. В настоящее время на рынке имеются зонды трех типов: встроенные, зонды на базе компьютера, и автономные. Продукт считается поддерживающим RMON, если в нем реализована хотя бы одна группа RMON. Разумеется, чем больше групп данных RMON реализовано в данном продукте, тем он, с одной стороны, дороже, а с другой - тем более полную информацию о работе сети он предоставляет.

Встроенные зонды представляют собой модули расширения для сетевых устройств. Такие модули выпускаются многими производителями, в частности, такими крупными компаниями, как 3Com, Cabletron, Bay Networks и Cisco. (Кстати, 3Com и Bay Networks недавно приобрели компании Axon и ARMON, признанных лидеров в области разработки и производства средств управления RMON. Такой интерес к этой технологии со стороны крупнейших производителей сетевого оборудования лишний раз показывает, насколько нужным для пользователей является дистанционный мониторинг.) Наиболее естественным выглядит решение встраивать модули RMON в концентраторы, ведь именно из наблюдения за этими устройствами можно со-ставить себе представление о работе сегмента. Достоинство таких зондов очевидно: они позволяют получать информацию по всем основным группам данных RMON при относительно невысокой цене. Недостатком в первую очередь является не слишком высокая производительность, что проявляется, в частности, в том, что встроенные зонды часто поддерживают далеко не все группы данных RMON. Не так давно 3Com объявила о намерении выпустить поддерживающие RMON драйверы для сетевых адаптеров Etherlink III и Fast Ethernet. В результате окажется возможным собирать и анализировать данные RMON непосредственно на рабочих станциях в сети.

Зонды на базе компьютера - это просто подключенные к сети компьютеры с установленным на них программным агентом RMON. Такие зонды (к числу которых относится, например, продукт Cornerstone Agent 2.5 компании Network General) обладают более высокой производительностью, чем встроенные зонды, и поддерживают, как правило, все группы данных RMON. Они более дороги, чем встроенные зонды, но гораздо дешевле автономных зондов. Помимо этого, зонды на базе компьютера имеют довольно большой размер, что может иногда ограничивать возможности их применения.

Автономные зонды обладают наивысшей производительностью; как легко понять, это одновременно и наиболее дорогие продукты из всех описанных. Как правило, автономный зонд - это процессор (класса i486 или RISC-процессор), оснащенный достаточным объемом оперативной памяти и сетевым адаптером. Лидерами в этом секторе рынка являются компании Frontier и Hewlett-Packard. Зонды этого типа невелики по размеру и весьма мобильны - их очень легко подключать к сети и отключать от нее. При решении задачи управления сетью глобального масштаба это, конечно, не слишком важное свойство, однако если средства RMON применяются для анализа работы корпоративной сети средних размеров, то (учитывая высокую стоимость устройств) мобильность зондов может сыграть весьма положительную роль.

Объекту RMON присвоен номер 16 в наборе объектов MIB, а сам объект RMON объединяет в соответствии с документом RFC 1271, состоит из десяти групп данных.

Statistics - текущие накопленные статистические данные о характеристиках пакетов, количестве коллизий и т.п.

History - статистические данные, сохраненные через определенные промежутки времени для последующего анализа тенденций их изменений.

Alarms - пороговые значения статистических показателей, при превышении которых агент RMON посылает сообщение менеджеру. Позволяет пользователю определить ряд пороговых уровней (эти пороги могут относиться к самым разным вещам - любому параметру из группы статистики, амплитуде или скорости его изменения и многому другому), по превышении которых генерируется аварийный сигнал. Пользователь может также определить, при каких условиях превышение порогового значения должно сопровождаться аварийным сигналом - это позволит избежать генерации сигнала "по пустякам", что плохо, во-первых, потому, что на постоянно горящую красную лампочку никто не обращает внимания, а во-вторых, потому, что передача ненужных аварийных сигналов по сети приводит к излишней загрузке линий связи. Аварийный сигнал, как правило, передается в группу событий, где и определяется, что с ним делать дальше.

Host - данных о хостах сети, в том числе и об их MAC-адресах..

HostTopN - таблица наиболее загруженных хостов сети. Таблица N главных хостов (HostTopN) содержит список N первых хостов, характеризующихся максимальным значением заданного статистического параметра для заданного интервала. Например, можно затребовать список 10 хостов, для которых наблюдалось максимальное количество ошибок в течение последних 24 часов. Список этот будет составлен самим агентом, а приложение управления получит только адреса этих хостов и значения соответствующих статистических параметров. Видно, до какой степени такой подход экономит сетевые ресурсы

TrafficMatrix - статистика об интенсивности трафика между каждой парой хостов сети, упорядоченная в виде матрицы. Строки этой матрицы пронумерованы в соответствии с MAC-адресами станций - источников сообщений, а столбцы - в соответствии с адресами станций-получателей. Матричные элементы характеризуют интенсивность трафика между соответствующими станциями и количество ошибок. Проанализировав такую матрицу, пользователь легко может выяснить, какие пары станций генерируют наиболее интенсивный трафик. Эта матрица, опять-таки, формируется самим агентом, поэтому отпадает необходимость в передаче больших объемов данных на центральный компьютер, отвечающий за управление сетью.

Filter - условия фильтрации пакетов. Признаки, по которым фильтруются пакеты, могут быть самыми разнообразными - например, можно потребовать отфильтровывать как ошибочные все пакеты, длина которых оказывается меньше некоторого заданного значения. Можно сказать, что установка фильтра соответствует как бы организации канала для передачи пакета. Куда ведет этот канал - определяет пользователь. Например, все ошибочные пакеты могут перехватываться и направляться в соответсвующий буфер. Кроме того, появление пакета, соответствующего установленному фильтру, может рассматриваться как событие (event), на которое система должна реагировать заранее оговоренным образом.

PacketCapture - условия захвата пакетов. В состав группы перехвата пакетов (packet capture) входят буфера для захвата, куда направляются пакеты, чьи признаки удовлетворяют условиям, сформулированным в группе фильтров. При этом захватываться может не пакет целиком, а, скажем, только первые несколько десятков байт пакета. Содержимое буферов перехвата можно впоследствии анализировать при помощи различных программных средств, выясняя целый ряд весьма полезных характеристик работы сети. Перестраивая фильтры на те или иные признаки, можно характеризовать разные параметры работы сети.

Event - условия регистрации и генерации событий. В группе событий (events) определяется, когда следует отправлять аварийный сигнал приложению управления, когда - перехватывать пакеты, и вообще - как реагировать на те или иные события, происходящие в сети, например, на превышение заданных в группе alarms пороговых значений: следует ли ставить в известность приложение управления, или надо просто запротоколировать данное событие и продолжать работать. События могут и не быть связаны с предачей аварийных сигналов - например, направление пакета в буфер перехвата тоже представляет собой событие.

Данные группы пронумерованы в указанном порядке, поэтому, например, группа Hosts имеет числовое имя 1.3.6.1.2.1.16.4.

Десятую группу составляют специальные объекты протокола TokenRing.

Всего стандарт RMON MIB определяет около 200 объектов в 10 группах, зафиксированных в двух документах - RFC 1271 для сетей Ethernet и RFC 1513 для сетей TokenRing .

Отличительной чертой стандарта RMON MIB является его независимость от протокола сетевого уровня (в отличие от стандартов MIB-I и MIB-II, ориентированных на протоколы TCP/IP). Поэтому, его удобно использовать в гетерогенных средах, использующих различные протоколы сетевого уровня.

1.2 Популярные системы управления сетями

Система управления сетью (Network management system) - аппаратные и/или программные средства для мониторинга и управления узлами сети. Программное обеспечение системы управления сетью состоит из агентов, локализующихся на сетевых устройствах и передающих информацию сетевой управляющей платформе. Метод информационного обмена между управляющими приложениями и агентами на устройствах определяется протоколами.

Системы управления сетями должны обладать целым рядом качеств:

истинной распределенностью в соответствии с концепцией кли-ент/сервер,

масштабируемостью,

открытостью, позволяющей справиться с разнородным - от настольных компьютеров до мейнфреймов - оборудованием.

Первые два свойства тесно связаны. Хорошая масштабируемость достигается за счет распределенности системы управления. Распределенность означает, что система может включать несколько серверов и клиентов. Серверы (менеджерами) собирают данные о текущем состоянии сети от агентов (SNMP, CMIP или RMON), встроенных в оборудование сети, и накапливают их в своей базе данных. Клиенты представляют собой графические консоли, за которыми работают администраторы сети. Программное обеспечение клиента системы управления принимает запросы на выполнение каких-либо действий от администратора (например, построение подробной карты части сети) и обращается за необходимой информацией к серверу. Если сервер обладает нужной информацией, то он сразу же передает ее клиенту, если нет - то пытается собрать ее от агентов.

Ранние версии систем управления совмещали все функции в одном компьютере, за которым работал администратор. Для небольших сетей или сетей с небольшим количеством управляемого оборудования такая структура оказывается вполне удовлетворительной, но при большом количестве управляемого оборудования единственный компьютер, к которому стекается информация от всех устройств сети, становится узким местом. И сеть не справляется с большим потоком данных, и сам компьютер не успевает их обрабатывать. Кроме того, большой сетью управляет обычно не один администратор, поэтому, кроме нескольких серверов в большой сети должно быть несколько консолей, за которыми работают администраторы сети, причем на каждой консоли должна быть представлена специфическая информация, соответствующая текущим потребностям конкретного администратора.

Поддержка разнородного оборудования - скорее желаемое, чем реально существующее свойство сегодняшних систем управления. К числу наиболее популярных продуктов сетевого управления относятся четыре системы: Spectrum компании CabletronSystems, OpenView фирмы Hewlett-Packard, NetView корпорации IBM и Solstice производства SunSoft - подразделения SunMicrosystems. Три компании из четырех сами выпускают коммуникационное оборудование. Естественно, что система Spectrum лучше всего управляет оборудованием компании Cabletron, OpenView - оборудованием компании Hewlett-Packard, а NetView- оборудованием компании IBM.

При построении карты сети, которая состоит из оборудования других производителей, эти системы начинают ошибаться и принимать одни устройства за другие, а при управлении этими устройствами поддерживают только их основные функции, а многие полезные дополнительные функции, которые отличают данное устройство от остальных, система управления просто не понимает и, поэтому, не может ими воспользоваться.

Для исправления этого недостатка разработчики систем управления включают поддержку не только стандартных баз MIB I, MIB II и RMON MIB, но и многочисленных частных MIB фирм-производителей. Лидер в этой области - система Spectrum, поддерживающая около 1000 баз MIB различных производителей.

Другим способом более качественной поддержки конкретной аппаратуры является использование на основе какой-либо платформы управления приложения той фирмы, которая выпускает это оборудование. Ведущие компании - производители коммуникационного оборудования - разработали и поставляют весьма сложные и многофункциональные системы управления для своего оборудования. К наиболее известным системам этого класса относятся Optivity компании BayNetworks, CiscoWorks компании CiscoSystems, Transcend компании 3Com. Система Optivity, например, позволяет производить мониторинг и управлять сетями, состоящими из маршрутизаторов, коммутаторов и концентраторов компании BayNetwork, полностью используя все их возможности и свойства. Оборудование других производителей под-держивается на уровне базовых функций управления. Система Optivity работает на платформах OpenView компании Hewlett-Packard и SunNetManager (предшественник Solstice) компании SunSoft. Однако, работа на основе какой-либо платформы управления с несколькими системами, такими как Optivity, слишком сложна и требует, чтобы компьютеры, на которых все это будет работать, обладали очень мощными процессорами и большой оперативной памятью .

Тем не менее, если в сети преобладает оборудование от какого-либо одного производителя, то наличие приложений управления этого производителя для какой-либо популярной платформы управления позволяет администраторам сети успешно решать многие задачи. Поэтому разработчики платформ управления поставляют вместе с ними инструментальные средства, упрощающие разработку приложений, а наличие таких приложений и их количество считаются очень важным фактором при выборе платформы управления.

Открытость платформы управления зависит также от формы хранения собранных данных о состоянии сети. Большинство платформ-лидеров позволяют хранить данные в коммерческих базах данных, таких как Oracle, Ingres или Informix. Использование универсальных СУБД снижает скорость работы системы управления по сравнению с хранением данных в файлах операционной системы, но зато позволяет обрабатывать эти данные любыми приложениями, умеющими работать с этими СУБД.

2. ПОСТАНОВКА ЗАДАЧИ

В соответствии со сложившейся ситуацией, было решено разработать и внедрить систему сетевого мониторинга, которая решала бы все вышеизложенные проблемы.

2.1 Техническое задание

Разработать и внедрить систему мониторинга, позволяющую проводить слежение как за коммутаторами, маршрутизаторами разных производителей, так и серверов различных платформ. Ориентироваться на использование открытых протоколов и систем, с максимальным использованием готовых наработок из фонда свободного программного обеспечения.

2.2 Уточненное техническое задание

В ходе дальнейшей формулировки проблемы и исследования предметной области, с учетом экономических и временных вложений было проведено уточнение технического задания:

Система должна удовлетворять следующим требованиям:

§минимальные требования к аппаратным ресурсам;

§открытые исходные коды всех составляющих комплекса;

§расширяемость и масштабируемость системы;

§стандартные средства предоставления диагностической информации;

§наличие подробной документации на все используемые программные продукты;

§способность работать с оборудованием различных производителей.

3. ПРЕДЛАГАЕМАЯ СИСТЕМА

1 Выбор системы сетевого мониторинга

В соответствии с уточненным техническим заданием, лучше всего в качестве ядра системы сетевого мониторинга подходит система Nagios, так как она обладает следующими качествами:

§имеются средства генерирования диаграмм;

§имеются средства генерирования отчетностей;

§есть возможность логического группирования;

§существует встроенная система записи трендов и их прогнозирования;

§имеется возможность автоматического добавления новых устройств (Autodiscovery) при помощи официального плагина;

§имеется возможность расширенного мониторинга хоста с использованием агента;

§поддержка протокола SNMP через плагин;

§поддержка протокола Syslog через плагин;

§поддержка внешних скриптов;

§поддержка самописных плагинов и возможность их быстрого и простого создания;

§встроенные триггеры и события;

§полнофункциональный веб-интерфейс;

§возможность распределенного мониторинга;

§инвентаризация через плагин;

§возможность хранения данных как в файлах, так и в базах данных SQL, что очень важно при увеличении объемов;

§лицензия GPL, а следовательно бесплатная базовая поставка, поддержка и открытые исходные коды ядра системы и сопровождающих компонентов;

§динамические и настраиваемые карты;

§управление доступом;

§встроенный язык описания хостов, сервисов и проверок;

§возможность отслеживания пользователей.

Система сетевого мониторинга Zabbix обладает схожим набором параметров, но на момент внедрения обладала гораздо более меньшим функционалом, чем Nagios и имела статус beta-версии. Кроме того, исследование тематических форумов и новостных лент показало наибольшую распространенность среди пользователей именно Nagios, что означает наличие написанной пользователями документации и максимально подробно описанных сложных моментов в настройке.

Nagios позволяет производить мониторинг таких сетевых сервисов как SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и многих других. Кроме этого, можно следить за использованием ресурсов серверов, таких как расход дискового пространства, свободная память и загруженность процессора. Существует возможность создавать свои собственные обработчики событий. Эти обработчики будут выполняться при возникновении тех или иных событий, инициированных проверками сервисов или серверов. Такой подход позволит активно реагировать на происходящие события и пытаться автоматически решать возникшие проблемы. К примеру, можно создать обработчик событий, который будет самостоятельно перезапускать повисший сервис. Еще одним достоинством системы мониторинга Nagios является возможность управлять ею удаленно с помощью wap интерфейса мобильного телефона. Используя концепцию "родительских" хостов, легко описать иерархию и зависимости между всеми хостами. Такой подход чрезвычайно полезен для больших сетей, потому что позволяет производить сложную диагностику. А это качество, в свою очередь, помогает отличить не работающие хосты, от тех, что недоступны в данный момент из-за неполадок в работе промежуточных звеньев. Nagios умеет строить графики работы наблюдаемых систем и карты контролируемой сетевой инфраструктуры.

Из своей практики работы с Nagios автор может привести пример, показывающий, насколько полезен он оказался для в его личной практике. На внешнем сетевом интерфейсе брандмауэра с периодичностью в несколько часов начиналась потеря пакетов. Из-за неисправности терялось до 20 процентов проходящего трафика. По истечении минуты - другой интерфейс снова начинал работать как положено. По причине плавающего характера этой неполадки несколько недель не удавалось выяснить, почему при работе с Интернет периодически происходят кратковременные сбои. Без Nagios поиск неисправности затянулся бы надолго.

Многим из администраторов хорошо знаком предок Nagios по имени NetSaint. Несмотря на то, что сайт проекта NetSaint все еще исправно функционирует, новые разработки базируются уже на исходном коде Nagios. Поэтому всем рекомендуется потихоньку перебираться на Nagios.

В документации, поставляемой с Nagios, говорится, что он будет стабильно работать и со многими другими Unix подобными системами. Для отображения web-интерфейса Nagios нам понадобится сервер Apache. Вы вольны, использовать любой другой, но в данной работе будет рассматриваться именно Apache, как наиболее распространенный на Unix платформах web-сервер. Можно установить систему мониторинга вообще без web-интерфейса, но мы так делать не станем, потому что это существенно уменьшает удобство пользования .

4. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

В качестве аппаратной части внедряемой системы можно использовать обычный IBM-совместимый компьютер, однако с учетом возможности дальнейшего повышения нагрузки и требований надежности и наработки на отказ, а также ГосСвязьНадзора, было приобретено сертифицированное серверное оборудование фирмы Aquarius.

В существующей сети активно используется операционная система Debian на базе ядра Linux, имеется обширный опыт использования этой системы, отлажено большинство операций по управлению, настройке и обеспечению стабильности её работы. Кроме того, данная ОС распространяется по лицензии GPL, что говорит о её бесплатности и открытости исходных кодов, что соответствует уточненному техническому заданию на проектирование системы сетевого мониторинга.(полное название GNU/Linux, произносится «гну слэш ли́нукс», также в некоторых языках «GNU+Linux», «GNU-Linux» и др.) - общее название UNIX-подобных операционных систем на основе одноимённого ядра и собранных для него библиотек и системных программ, разработанных в рамках проекта GNU./Linux работает на PC-совместимых системах семейства Intel x86, а также на IA-64, AMD64, PowerPC, ARM и многих других.

К операционной системе GNU/Linux также часто относят программы, дополняющие эту операционную систему, и прикладные программы, делающие её полноценной многофункциональной операционной средой.

В отличие от большинства других операционных систем, GNU/Linux не имеет единой «официальной» комплектации. Вместо этого GNU/Linux поставляется в большом количестве так называемых дистрибутивов, в которых программы GNU соединяются с ядром Linux и другими программами. Наиболее известными дистрибутивами GNU/Linux являются Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Российские дистрибутивы - ALT Linux и ASPLinux.

В отличие от Microsoft Windows (Windows NT), Mac OS (Mac OS X) и коммерческих UNIX-подобных систем, GNU/Linux не имеет географического центра разработки. Нет и организации, которая владела бы этой системой; нет даже единого координационного центра. Программы для Linux - результат работы тысяч проектов. Некоторые из этих проектов централизованы, некоторые сосредоточены в фирмах. Многие проекты объединяют хакеров со всего света, которые знакомы только по переписке. Создать свой проект или присоединиться к уже существующему может любой и, в случае успеха, результаты работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую, что позволяет быстро находить и исправлять ошибки и реализовывать новые возможности.

История развития UNIX-систем. GNU/Linux является UNIX-совместимой, однако основывается на собственном исходном коде

Именно такая гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность[источник не указан 199 дней] GNU/Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение людей из разных стран, обладающих разным видением проблем, защита кода лицензией GPL - всё это стало причиной успеха свободных программ.

Конечно, такая высокая эффективность разработки не могла не заинтересовать крупные фирмы, которые стали открывать свои проекты. Так появились Mozilla (Netscape, AOL), OpenOffice.org (Sun), свободный клон Interbase (Borland) - Firebird, SAP DB (SAP). IBM способствовала переносу GNU/Linux на свои мейнфреймы.

С другой стороны, открытый код значительно снижает себестоимость разработки закрытых систем для GNU/Linux и позволяет снизить цену решения для пользователя. Вот почему GNU/Linux стала платформой, часто рекомендуемой для таких продуктов, как СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Сообщество GNU/Linux поддерживает связь посредством групп пользователей Linux.

Большинство пользователей для установки GNU/Linux используют дистрибутивы. Дистрибутив - это не просто набор программ, а ряд решений для разных задач пользователей, объединённых едиными системами установки, управления и обновления пакетов, настройки и поддержки.

Самые распространённые в мире дистрибутивы:- быстро завоевавший популярность дистрибутив, ориентированный на лёгкость в освоении и использовании.- бесплатно распространяемая версия дистрибутива SuSE, принадлежащая компании Novell. Отличается удобством в настройке и обслуживании благодаря использованию утилиты YaST.- поддерживается сообществом и корпорацией RedHat, предшествует выпускам коммерческой версии RHEL.GNU/Linux - международный дистрибутив, разрабатываемый обширным сообществом разработчиков в некоммерческих целях. Послужил основой для создания множества других дистрибутивов. Отличается строгим подходом к включению несвободного ПО.- французско-бразильский дистрибутив, объединение бывших Mandrake и Conectiva (англ.).- один из старейших дистрибутивов, отличается консервативным подходом в разработке и использовании.- дистрибутив, собираемый из исходных кодов. Позволяет очень гибко настраивать конечную систему и оптимизировать производительность, поэтому часто называет себя мета-дистрибутивом. Ориентирован на экспертов и опытных пользователей.- ориентированный на применение самых последних версий программ и постоянно обновляемый, поддерживающий одинаково как бинарную, так и установку из исходных кодов и построенный на философии простоты KISS, этот дистрибутив ориентирован на компетентных пользователей, которые хотят иметь всю силу и модифицируемость Linux, но не в жертву времени обслуживания.

Помимо перечисленных, существует множество других дистрибутивов, как базирующихся на перечисленных, так и созданных с нуля и зачастую предназначенных для выполнения ограниченного количества задач.

Каждый из них имеет свою концепцию, свой набор пакетов, свои достоинства и недостатки. Ни один не может удовлетворить всех пользователей, а потому рядом с лидерами благополучно существуют другие фирмы и объединения программистов, предлагающие свои решения, свои дистрибутивы, свои услуги. Существует множество LiveCD, построенных на основе GNU/Linux, например, Knoppix. LiveCD позволяет запускать GNU/Linux непосредственно с компакт-диска, без установки на жёсткий диск.

Для желающих досконально разобраться с GNU/Linux подойдёт любой из дистрибутивов, однако довольно часто для этой цели используются так называемые source-based дистрибутивы, то есть предполагающие самостоятельную сборку всех (или части) компонентов из исходных кодов, такие как LFS, Gentoo, ArchLinux или CRUX .

4.1 Установка ядра системы

Nagios можно устанавливать двумя способами - из исходных кодов и из собранных пакетов. У обоих способов есть преимущества и недостатки, рассмотрим их.

Плюсы установки пакета их исходных кодов:

§возможность детального конфигурирования системы;

§высокая степень оптимизации приложения;

§наиболее полное представление работы программы.

Минусы установки пакета их исходных кодов:

§требуется дополнительное время на сборку пакета, часто превышающее время на его настройку и наладку;

§невозможность удалить пакет вместе с конфигурационными файлами;

§невозможность обновить пакет вместе с конфигурационными файлами;

§невозможность централизованного контроля за установленными приложениями.

При установке Nagios из предварительно собранного пакета, достоинства «сырого» метода установки становятся недостатками, и наоборот. Однако, как показала практика, собранный заранее пакет удовлетворяет всем требованиям, предъявляемым к системе и нет смысла тратить время на ручную сборку пакета .

Так как изначально были опробованы оба метода установки, то рассмотрим более детально каждый из них.

4.1.1 Описание установки ядра системы их исходных кодов

Требуемые пакеты.

Необходимо удостовериться, что следующие пакеты установлены до начала развертывания Nagios. Детальное рассмотрение процесса их установки выходит за рамки данной работы.

·Apache 2

·PHP

·GCC компилятор и библиотеки разработчика

·GD библиотеки разработчика

Можно использовать утилиту apt-get (лучше aptitude) для их установки следующим образом:

% sudo apt-get install apache2

% sudo apt-get install libapache2-mod-php5

% sudo apt-get install build-essential

% sudo apt-get install libgd2-dev

1) Создание нового пользовательского непривилигированного аккаунта

Новый аккаунт создается для запуска службы Nagios. Можно это делать и из-под учетной записи суперпользователя, что создаст серьезную угрозу для безопасности системы.

Станем суперпользователем:

Создадим новую учетную запись пользователя nagios и дадим ей пароль:

# /usr/sbin/useradd -m -s /bin/bash nagios

# passwd nagios

Создадим группу nagios и добавим в неё пользователя nagios:

# /usr/sbin/groupadd nagios

# /usr/sbin/usermod -G nagios nagios

Создадим группу nagcmd для разрешения выполнения внешних команд, переданных через веб-интерфейс. Добавим в эту группу пользователей nagios и apache:

# /usr/sbin/groupadd nagcmd

# /usr/sbin/usermod -a -G nagcmd nagios

# /usr/sbin/usermod -a -G nagcmd www-data

2) Скачаем Nagios и плагины к нему

Создадим директорию для хранение скаченных файлов:

# mkdir ~/downloads

# cd ~/downloads

Качаем сжатые исходные коды Nagios и его плагинов (#"justify"># wget #"justify"># wget #"justify">3) Компилируем и устанавливаем Nagios

Распакуем сжатые исходные коды Nagios:

# cd ~/downloads

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Запускаем конфигурационный скрипт Nagios, передав ему имя группы, которую мы создали ранее:

# ./configure --with-command-group=nagcmd

Полный список параметров конфигурационного скрипта:

#./configure --help

`configure" configures this package to adapt to many kinds of systems.: ./configure ... ...assign environment variables (e.g., CC, CFLAGS...), specify them as=VALUE. See below for descriptions of some of the useful variables.for the options are specified in brackets.:

h, --help display this help and exit

Help=short display options specific to this package

Help=recursive display the short help of all the included packages

V, --version display version information and exit

q, --quiet, --silent do not print `checking..." messages

Cache-file=FILE cache test results in FILE

C, --config-cache alias for `--cache-file=config.cache"

n, --no-create do not create output files

Srcdir=DIR find the sources in DIR directories:

Prefix=PREFIX install architecture-independent files in PREFIX

Exec-prefix=EPREFIX install architecture-dependent files in EPREFIXdefault, `make install" will install all the files in `/usr/local/nagios/bin", `/usr/local/nagios/lib" etc. You can specify an installation prefix other than `/usr/local/nagios" using `--prefix", for instance `--prefix=$HOME".better control, use the options below.tuning of the installation directories:

Bindir=DIR user executables

Sbindir=DIR system admin executables

Libexecdir=DIR program executables

Datadir=DIR read-only architecture-independent data

Sysconfdir=DIR read-only single-machine data

Sharedstatedir=DIR modifiable architecture-independent data

Localstatedir=DIR modifiable single-machine data

Libdir=DIR object code libraries

Includedir=DIR C header files

Oldincludedir=DIR C header files for non-gcc

Infodir=DIR info documentation

Mandir=DIR man documentation types:

Build=BUILD configure for building on BUILD

Host=HOST cross-compile to build programs to run on HOST Features:

Disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)

Enable-FEATURE[=ARG] include FEATURE

Disable-statusmap=disables compilation of statusmap CGI

Disable-statuswrl=disables compilation of statuswrl (VRML) CGI

Enable-DEBUG0 shows function entry and exit

Enable-DEBUG1 shows general info messages

Enable-DEBUG2 shows warning messages

Enable-DEBUG3 shows scheduled events (service and host checks... etc)

Enable-DEBUG4 shows service and host notifications

Enable-DEBUG5 shows SQL queries

Enable-DEBUGALL shows all debugging messages

Enable-nanosleep enables use of nanosleep (instead sleep) in event timing

Enable-event-broker enables integration of event broker routines

Enable-embedded-perl will enable embedded Perl interpreter

Enable-cygwin enables building under the CYGWIN environmentPackages:

With-PACKAGE[=ARG] use PACKAGE

Without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)

With-nagios-user= sets user name to run nagios

With-nagios-group= sets group name to run nagios

With-command-user= sets user name for command access

With-command-group= sets group name for command access

With-mail=Sets path to equivalent program to mail

With-init-dir=Sets directory to place init script into

With-lockfile=Sets path and file name for lock file

With-gd-lib=DIR sets location of the gd library

With-gd-inc=DIR sets location of the gd include files

With-cgiurl= sets URL for cgi programs (do not use a trailing slash)

With-htmurl= sets URL for public html

With-perlcache turns on cacheing of internally compiled Perl scriptsinfluential environment variables:C compiler commandC compiler flagslinker flags, e.g. -L if you have libraries in adirectory C/C++ preprocessor flags, e.g. -I if you havein a nonstandard directory C preprocessorthese variables to override the choices made by `configure" or to helpto find libraries and programs with nonstandard names/locations.

Компилируем исходный код Nagios.

Установим бинарные файлы, скрипт инициализации, примеры конфигурационных файлов и установим разрешения на директорию внешних команд:

# make install-init

# make install-config

# make install-commandmode

) Изменим конфигурацию

Примеры конфигурационных файлов установлены в директорию /usr/local/nagios/etc. Они должны сразу быть рабочими. Нужно сделать лишь одно изменение перед тем, как продолжить.

Отредактируем конфигурационный файл /usr/local/nagios/etc/objects/contacts.cfg любым текстовым редактором и изменим email адрес привязанный к определению контакта nagiosadmin на адрес, на который мы собираемся принимать сообщения о неполадках.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Настройка веб-интерфейса

Установим конфигурационный файл веб-интерфейса Nagios в директорию Apache conf.d.

# make install-webconf

Создадим учетную запись nagiosadmin для входа в веб-интерфейс Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Перезапустим Apache, чтобы изменения вступили в силу.

# /etc/init.d/apache2 reload

Необходимо принять меры по усилению безопасности CGI, чтобы предотвратить кражу этой учетной записи, так как информация о мониторинге является достаточно чувствительной.

) Компилируем и устанавливаем плагины Nagios

Распакуем сжатые исходные коды плагинов Nagios:

# cd ~/downloads

# tar xzf nagios-plugins-1.4.11.tar.gz

Компилируем и устанавливаем плагины:

# ./configure --with-nagios-user=nagios --with-nagios-group=nagios

#make install

) Запускаем службу Nagios

Настроим Nagios на автоматическую загрузку при включении операционной системы:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Проверим синтаксическую правильность примерных конфигурационных файлов:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Если ошибок нет, то запускаем Nagios:

# /etc/init.d/nagios start

) Входим на веб-интерфейс

Теперь можно войти в веб-интерфейс Nagios, используя следующий URL. Будет выдан запрос на ввод имени пользователя (nagiosadmin) и пароля, которые мы задали ранее.

#"justify">) Прочие настройки

Для получения напоминаний по email о событиях Nagios, необходимо установить пакет mailx (Postfix):

% sudo apt-get install mailx

% sudo apt-get install postfix

Необходимо отредактировать команды напоминаний Nagios файле /usr/local/nagios/etc/objects/commands.cfg и изменить все ссылки с "/bin/mail" на "/usr/bin/mail". После этого необходимо перезапустить службу Nagios:

# sudo /etc/init.d/nagios restart

Подробная конфигурация почтового модуля описана в Приложении Г.

4.1.2 Описание установки ядра системы из репозитария

Как было показано выше, установка Nagios из исходных текстов занимает значительное время и имеет смысл только при требовании тщательной оптимизации приложения или желании досконально разобраться с механизмом работы системы. В рабочих условиях большинство программного обеспечения устанавливается из репозитариев в виде предкомпилированных пакетов. В этом случае установка сводится к вводу одной команды:

% sudo aptitude install nagios

Менеджер пакетов самостоятельно удовлетворит все зависимости и установит необходимые пакеты.

4.2 Конфигурирование ядра системы

Перед детальной настройкой следует понимать то, как работает ядро Nagios. Его графическое описание приведено ниже в иллюстрации 6.2.

4.2.1 Описание работы ядра системы

На следующем рисунке показана упрощенная схема работы службы Nagios.

Рис. 4.1 - Ядро системы

Служба Nagios читает основной конфигурационный файл, в котором помимо основных параметров работы службы имеются ссылки на файлы ресурсов, файлы описания объектов и конфигурационные файлы CGI.

Алгоритм и логика работы ядра сетевого мониторинга показаны ниже.

Рис. 4.2 - Алгоритм оповещений Nagios

2.2 Описание взаимодействия конфигурационных файлов

В директории /etc/apache2/conf.d/ находится файл nagios3.conf, из которого веб-сервер apache берет настройки для nagios.

Конфигурационные файлы nagios находятся в директории /etc/nagios3.

Файл /etc/nagios3/htpasswd.users содержит пароли для пользователей nagios. Команда для создания файла и установки пароля для пользователя nagios по умолчанию приведена выше. В дальнейшем, необходимо будет опустить аргумент "-c" при задании пароля для нового пользователя, иначе новый файл затрет старый.

Файл /etc/nagios3/nagios.cfg содержит основную конфигурацию самого nagios. Например, файлы журналов событий или путь к остальным конфигурационным файлам, которые nagios зачитывает при старте.

В директории /etc/nagios/objects задаются новые хосты и сервисы.

4.2.3 Заполнение описаний хостов и служб

Как было показано выше, настраивать ядро системы можно используя один файл описания для хостов и служб, однако этот способ не будет удобен с ростом количества отслеживаемого оборудования, поэтому необходимо создать некую структуру каталогов и файлов с описаниями хостов и служб.

Созданная структура показана в Приложении З.

Файл hosts.cfg

Сначала нужно описать хосты, за которыми будет выполняться наблюдение. Можно описать сколь угодно много хостов, но в этом файле мы ограничимся общими параметрами для всех хостов.

Здесь описанный хост это не настоящий хост, а шаблон, на котором основываются описания всех остальных хостов. Такой же механизм можно встретить и в других конфигурационных файлах, когда конфигурация основывается на предварительно определенном множестве значений по умолчанию.

Файл hostgroups.cfg

Здесь добавляются хосты в группу хостов (hostgroup). Даже в простой конфигурации, когда хост один, все равно нужно добавлять его в группу, чтобы Nagios знал какую контактную группу (contact group) нужно использовать для отправки оповещений. О контактной группе подробнее ниже.

Файл contactgroups.cfg

Мы определили контактную группу и добавили пользователей в эту группу. Такая конфигурация гарантирует, что все пользователи получат предупреждение в том случае, если что-то не так с серверами за которые отвечает группа. Правда, нужно иметь в виду, что индивидуальные настройки по каждому из пользователей могут перекрыть эти настройки.

Следующим шагом нужно указать контактную информацию и настройки оповещений.

Файл contacts.cfg

Помимо того, что в этом файле приводится дополнительная контактная информация пользователей, одно из полей, contact_name, имеет ещё одно назначение. CGI-cкрипты используют имена, заданные в этих полях для того чтобы определить, имеет пользователь право доступа к какому-то ресурсу или нет. Вы должны настроить аутентификацию, основывающуюся на.htaccess, но кроме этого нужно использовать те же имена, которые использованы выше, для того чтобы пользователи могли работать через Web-интерфейс.

Теперь, когда хосты и контакты настроены, можно переходить к настройке мониторинга отдельных сервисов, за которыми должно проводиться наблюдение.

Файл services.cfg

Здесь мы как и в файле hosts.cfg для хостов, задали лишь общие параметры для всех служб.

Доступно огромное количество дополнительных модулей Nagios, но если какой-то проверки всё же нет, её можно всегда написать самостоятельно. Например, нет модуля, проверяющего работает или нет Tomcat. Можно написать скрипт, который загружает jsp страницу с удалённого Tomcat-сервера и возвращает результат в зависимости от того, если в загруженной странице какой-то текст на странице или нет. (При добавлении новой команды нужно обязательно упомянуть её в файле checkcommand.cfg, который мы не трогали).

Далее по каждому отдельному хосту мы создаем свой файл-описание, в этом же файле мы будем хранить описания служб, по которым мы будем проводить мониторинг для этого хоста. Сделано это для удобства и логической организации.

Стоит отметить, что Windows хосты проходят мониторинг посредством протокола SNMP и NSClienta, поставляемого с Nagios. Ниже представлена схема его работы

Рис. 4.3 - Схема мониторинга Windows хостов

В тоже время *nix хосты проходят мониторинг также посредством SNMP, а также NRPE плагина. Схема его работы показана на рисунке

Рис. 4.4 - Схема мониторинга *nix хостов

2.4 Написание плагинов

Помимо написания скриптов инициализации, определения хостов и служб, были использованы следующие плагины:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

Большая часть их них поставляется вместе с пакетом Nagios. Исходные тексты плагинов, не входящих в комплект поставки и использованных в системе, представлены в Приложении И.

4.2.5 Настройка SNMP на удаленных хостах

Чтобы иметь возможность проводить мониторинг по протоколу SNMP, на сетевом оборудовании необходимо предварительно настроить агентов этого протокола. Схема работы SNMP в связке с ядром системы сетевого мониторинга показана на рисунке ниже.

Рис. 4.5 - Схема мониторинга посредством протокола SNMP

Конфигурационные параметры хостов представлены в Приложении З. Безопасность осуществляется путем индивидуальной настройки пакетного фильтра на каждом из хостов в отдельности и посредством организации защищенных системных подсетей, в которые имеет доступ только авторизованный персонал предприятия. Кроме того настройка произведена таким образом, что посредством SNMP протокола можно производить только чтение параметров, а не их запись .

4.2.6 Настройка агента на удаленных хостах

Для получения возможностей расширенного мониторинга хостов и служб, необходимо установить на них агента Nagios, который называется nagios-nrpe-server:

# aptitude install nagios-nrpe-server

Конфигурация агента представлена в Приложении Л. Схема работы агента показана на Рисунке 4.5 выше.

4.4 Установка и настройка модуля отслеживания загрузки

MRTG (Multi Router Traffic Grapher) - сервис, позволяющий посредством протокола SNMP получать из нескольких устройств информацию и отображать в окне вашего браузера графики загруженности канала (входящий трафик, исходящий, максимальный, средний) с шагом в минуты, часы, дни и за год.

Требования к установке

Для работы MRTG требуются следующие библиотеки:

§gd - graph drawing library. Библиотека, ответственная за формирование графики (#"justify">§libpng - требуется gd для создания графики в формате png (#"justify">В нашем случае установка сводится к выполнению одной команды, т.к. выбран способ установки предкомпиленного пакета из репозитория:

# aptitude install mrtg

Создавать конфигурационные файлы можно вручную, а можно воспользоваться идущими в составе пакета генераторами конфигураций:

# cfgmaker @ >

После генерации конфигурационного файла рекомендуется проверить его, т.к. в нем могут находится описания интерфейсов, которые нам не нужно анализировать на загруженность. В таком случае определенные строки в файле комментируются или удаляются. Пример конфигурационного файла MRTG приведен в Приложении М. Из-за большого объема этих файлов приведен лишь пример одного файла.

# indexmaker >

Индексные страницы представляют собой обычные html файлы и их содержимое особого интереса не представляет, поэтому приводить их примеры не имеет смысл. В Приложении Н показан пример отображения графиков загрузки интерфейсов.

В завершение необходимо организовать проверку загруженности интерфейсов по расписанию. Достигнуть этого проще всего средствами операционной системы, а именно параметрами crontab.

4.5 Установка и настройка модуля сбора системных журналов событий

В качестве модуля сбора системных журналов событий был выбран пакет syslog-ng.ng (syslog next generation) - это многофункциональная служба протоколирования системных сообщений. По сравнению со стандартной службой syslogd, он имеет ряд отличий:

§усовершенствованная схема конфигурации

§фильтрация сообщений не только по приоритетам, но и по их содержанию

§поддержка regexps (regular expressions)

§более гибкое манипулирование и организация логов

§возможность шифрования канала передачи данных с помощью IPSec/Stunnel

В следующей таблице представлены поддерживаемые аппаратные платформы.

Таблица 4.1 - Поддерживаемые аппаратные платформы

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 & 5.3НетНетНетДаПо запросуНетDebian etchДаДаНетНетНетНетFreeBSD 6.1 *ДаПо запросуПо запросуНетНетНетHP-UНет 11iНетНетНетНетНетДаIBM System iНетНетНетДаНетНетRed Hat ES 4 / CentOS 4ДаДаНетНетНетНетRed Hat ES 5 / CentOS 5ДаДаНетНетНетНетSLES 10 / openSUSE 10.0ДаПо запросуНетНетНетНетSLES 10 SP1 / openSUSE 10.1ДаДаНетНетНетНетSolaris 8НетНетДаНетНетНетSolaris 9По запросуНетДаНетНетНетSolaris 10По запросуДаДаНетНетНетWindowsДаДаНетНетНетНетПримечение: * Доступ к базе данных Oracle не поддерживается

Подробное сравнение технических особенностей приведено в Приложении П.

Файлы описания правил и фильтров, а также конфигурация удаленных хостов приведены в Приложении Р.

Существует документ RFC, детально описывающий протокол syslog, в общем виде работу модуля сборщика системных журналов можно представить следующей схемой

Рис. 4.6 - Схема работы модуля сбора системных журналов

На клиентском хосте каждое отдельное приложение пишет свой журнал событий, образуя тем самым источник. Далее поток сообщений для журналов проходит через определение места для хранения, далее через фильтры определяется его сетевое направление, после чего, попадая на сервер логирования, для каждого сообщения вновь определяется место хранения. Выбранный модуль имеет большие возможности масштабирования и усложненной конфигурации, например фильтры могут разветвляться, таким образом, что сообщения о системных событиях будут отправляться в несколько направлений в зависимости от нескольких условий, как показано на рисунке ниже.

Рис. 4.7 - Ветвление фильтров

Возможность масштабирования подразумевает, что в целях распределения нагрузки, администратор будет развертывать сеть из вспомогательных фильтрующих серверов, так называемых релеев.

Рис. 4.8 - Масштабирование и распределение нагрузки

В конечном итоге, максимально упрощенно, описать работу модуля можно так - клиентские хосты передают сообщения журналов событий разных приложений разгружающим серверам, те, в свою очередь могут передавать их по цепочке релеев, и так до центральных серверов сбора.

Рис. 4.9 - Обобщенная схема работы модуля

В нашем случае поток данных не столь велик чтобы развертывать систему разгружающих серверов, поэтому было решено использовать упрощенную схему работы клиент - сервер .

Рис. 4.10 - Принятая схема работы

5. РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА

В целом системному администратору рекомендуется придерживаться существующей иерархии расположения конфигурационных файлов и каталогов. Добавление в систему мониторинга новых хостов и служб сводится к созданию новых конфигурационных файлов и инициализационных скриптов, как было показано в разделе 5 - Разработка программного обеспечения, поэтому повторно описывать параметры и принципы конфигурирования системы в этой работе смысла нет, однако стоит более подробно остановиться на описании интерфейсов отдельных модулей системы.

5.1 Описание веб-интерфейса системы

Для того чтобы выполнять интерактивное наблюдение за службами было удобнее в систему интегрирован web-интерфейс. Web-интерфейс ещё хорош тем, что даёт полную картину системы благодаря умелому применению графических средств и предоставления дополнительной статистической информации.

При входе на веб-страницу Nagios будет запрошен ввод имени пользователя и пароля, которые мы установили в процессе настройки. Стартовая страница веб-интерфейса показана на рисунке ниже.

Рис. 5.1 - Стартовая страница веб-интерфейса системы

Слева находится навигационная панель, справа результаты различного представления данных о состоянии сети, хостов и служб. Нас будет интересовать в первую очередь раздел Monitoring. Посмотрим на страницу Tactical Overview.

Рис. 5.2 - Стартовая страница веб-интерфейса системы

На этой странице располагается суммирующая информация по всем параметрам мониторинга и состоянию хостов и служб, при этом никаких подробностей не приводится, однако, если возникают какие-либо проблемы, то они выделяются особым цветом и становятся гиперссылкой, ведущей к подробному описанию возникшей проблемы. В нашем случае на текущий момент среди всех хостов и служб имеется одна неразрешенная проблема, перейдем по этой ссылке (1 Unhandled Problems).

Рис. 5.3 - Обнаруженная проблема службы

Здесь мы в таблично виде наблюдаем на каком именно хосте возникла проблема, что за служба её вызвала (в нашем случае это большая загрузка процессора на маршрутизаторе), статус ошибки (может быть нормальный, пороговый и критичный), время последней проверки, продолжительность присутствия проблемы, номер проверки по счету в цикле и подробная информация с конкретными значениями, возвращаемыми используемым плагином.

Рис. 5.4 - Подробное описание состояния службы

Здесь мы видим полное описание проблемы, эта страница полезна при глубоком анализе проблемы, когда не совсем ясна причина её возникновения, например она может быть в слишком жестко заданных пороговых значениях критичности состояния или неправильно заданных параметрах запуска плагина, что также будет оцениваться системой как критичное состояние. Кроме описания, с этой страницы возможно выполнение команд над службой, например отключить проверки, назначить другое время следующей проверки, принять данные пассивно, принять проблему на рассмотрение, отключить оповещения, отправить оповещение вручную, запланировать отключение службы, отключить обнаружение нестабильного состояния и написать комментарий.

Перейдем на страницу Service Detail.

Рис. 5.5 - Детальное представление всех служб

Здесь мы видим список всех хостов и служб, вне зависимости от их текущего состояния. Эта возможность может быть и полезна, но просматривать длинный список хостов и служб не совсем удобно и нужна она скорее чтобы время от времени визуально представить объем работы, выполняемой системой. Здесь каждый хост и служба, как и на рисунке 6.3 является ссылкой, ведущей к более подробному описанию параметра.

Рис. 5.6 - Полный подробный список хостов

В данной таблице представлен полный подробный список хостов, их статусы, время последней проверки, продолжительность текущего статуса и дополнительная информация. В нашей системе принято, что статус хоста проверяется при помощи проверки доступности хоста по протоколу ICMP (8), то есть командой ping, однако в общем случае проверка можно быть какой угодно. Значки в колонке справа от имени хоста говорят о группе, к которой он принадлежит, сделано это для удобства восприятия информации. Значек светофора это ссылка, ведущая к подробному списку служб данного хоста, описывать эту таблицу отдельно не имеет смысла, она точно такая же, как и на рисунке 10.4, только информация представлена о единственном хосте.

Следующие по списку ссылки являются различными модификациями предыдущих таблиц и разобраться с их содержанием не составит труда. Наиболее интересной возможностью веб-интерфейса является возможность построения карты сети в полуавтоматическом режиме.

Рис. 5.7 - Полная круговая карта сети

Посредством параметра parent каждого хоста и службы мы можем создавать структуру или иерархию нашей сети, что определит логику работы ядра сетевого мониторинга и представление хостов и служб на карте сети. Есть несколько режимов отображения, помимо кругового, наиболее удобным является режим сбалансированного дерева и шарообразный.

Рис. 5.8 - Карта сети - режим сбалансированного дерева

Рис. 5.9 - Карта сети - шарообразный режим

Во всех режимах изображение каждого хоста является ссылкой на его таблицу служб и их состояний.

Следующей важной частью интерфейса ядра мониторинга является построитель трендов. С его помощью можно планировать замену оборудования на более производительно, приведем пример. Щелкаем по ссылке Trends. Выбираем тип отчета - службу.

Step 1: Select Report Type: Service

Третьим шагом выбираем период подсчета и генерируем отчет.

Рис. 5.10 - Тренд

Мы сгенерировали тренд загруженности процессора на маршрутизации. Из него можно сделать вывод, что в течение месяца этот параметр постоянно ухудшается и необходимо уже сейчас принимать меры либо по оптимизации работы хоста или готовиться к его замене на более производительный.

5.2 Описание веб-интерфейса модуля отслеживания загрузки интерфейсов

Веб-интерфейс модуля отслеживания загрузки интерфейсов представляет собой список каталогов, в которых расположены индексные страницы отслеживаемых хостов с графиками загрузки каждого интерфейса.

Рис. 5.11 - Стартовая страница модуля отслеживания загрузки интерфейсов

Перейдя по любой из ссылок, получим графики загрузки. Каждый график является ссылкой, ведущей к статистике за неделю, месяц и год.

5.3 Описание модуля сбора системных журналов событий

В данный момент не требуется улучшенная фильтрация системных журналов и возможность поиска по ним через единый веб-интерфейс, т.к. проблемы, требующие просмотра этих журналов возникают достаточно редко. Поэтому разработка базы данных под эти журналы и веб-интерфейса отложена. В настоящее время доступ к ним осуществляется посредством ssh и просмотра директорий в файловом менеджере mc .

В результате работы этого модуля получили следующую структуру каталогов:

├── apache2

├── asterix

├── bgp_router

├── dbconfig-common

├── installer

│ └── cdebconf

├── len58a_3lvl

├── monitoring

├── nagios3

│ └── archives

├── ocsinventory-client

├── ocsinventory-server

├── quagga

├── router_krivous36b

├── router_lenina58a

├── router_su

├── router_ur39a

├── shaper

├── ub13_router

├── univer11_router

└── voip

Каждый каталог является хранилищем журналов событий для каждого отдельного хоста.

Рис. 5.13 - Просмотр данных, собранных модулем сбора системных журналов событий

6. ТЕСТИРОВАНИЕ РАБОТЫ

При внедрении системы проводилось постепенное тестирование работы каждого компонента, начиная с ядра системы. Расширение функционала проводилось только после окончательной наладки нижележащих по иерархии уровней модулей системы сетевого мониторинга ввиду многих зависимостей различных подсистем. Пошагово, в общем и целом можно описать процесс внедрения и тестирования следующим образом:

) Установка и наладка ядра на базе Nagios;

) Наладка мониторинга удаленных хостов базовым функционалом Nagios;

) Наладка модуля отслеживания загрузки сетевых интерфейсов посредством MRTG;

) Расширение функционала ядра системы и интеграция её с модулем MRTG;

) Наладка модуля сбора системных журналов;

) Написание скрипта инициализации пакетного фильтра системы мониторинга в целях обеспечения безопасности системы.

7. Информационная безопасность

1 Характеристика рабочего места

К вредным факторам, влияющим на работу при использовании ПЭВМ относятся:

·повышенное значение напряжения электрического тока;

·шум;

·электромагнитное излучение;

·электростатическое поле.

Для обеспечения наилучших условий для эффективной и безопасной работы нужно создать такие условия труда, которые будут комфортными и максимально уменьшающими воздействие данных вредных факторов. Необходимо, чтобы перечисленные вредные факторы согласовывались с установленными правилами и нормами.

7.2 Безопасность труда

2.1 Электробезопасность

Проектируемое программное средство создается в расчете на работу на имеющемся сервере, расположенном в специально оборудованном техническом помещении. Оно оборудовано кабельными коробами для прокладки кабелей. К каждому серверу подведено электропитание ~220В, частотой 50Гц, с рабочим заземлением. Перед вводом электропитания в помещение установлены автоматы, отключающие электропитание в случае короткого замыкания. Отдельно проведено защитное заземление.

При подключении ЭВМ необходимо соединить корпус аппаратуры с жилой защитного заземления для того, чтобы в случае выхода из строя изоляции или по каким-либо другим причинам опасное напряжение электропитания, при прикосновении человеком корпуса аппаратуры, не смогло создать ток опасной величины через тело человека.

Для этого используется третий контакт в электрических розетках, который подключен к жиле защитного заземления. Корпуса аппаратуры заземляются через кабель электропитания по специально выделенному проводнику.

Применяются технические меры, обеспечивающие защиту от поражения электрическим током при прикосновении к корпусу электроустановки в случае пробоя изоляции токоведущих частей, к которым относятся:

·защитное заземление;

·защитное зануление;

·защитное отключение.

7.2.2 Защита от шума

Исследования показывают, что в условиях шума, прежде всего, страдают слуховые функции. Но действие шума не ограничивается влиянием только на слух. Он вызывает заметные сдвиги ряда физиологических психических функций. Шум вредно влияет на нервную систему и снижает скорость и точность сенсомоторных процессов, возрастает число ошибок при решении интеллектуальных задач. Шум оказывает заметное влияние на внимание человека и вызывает негативные эмоции.

Основным источником шума в помещениях, где находятся ЭВМ, является оборудование для кондиционирования воздуха, печатная и копировальная техника, а в самих ЭВМ вентиляторы систем охлаждения.

В производственном помещении активно используются следующие меры борьбы с шумом:

·применение бесшумных охлаждающих механизмов;

·изоляция источников шума от окружающей среды средствами звукоизоляции и звукопоглощения;

·использование звукопоглощающих материалов для облицовки помещений.

В помещении на рабочем месте присутствуют следующие источники шума:

·системный блок (кулер (25дБ), жесткий диск (29дБ), блок питания (20дБ));

·принтер (49дБ) .

Общий шум L, испускаемый этими устройствами, вычисляется по формуле:

где Li - уровень шума одного устройства, дБ= 10*lg(316,23+794,33+100+79432,82) = 10*4,91 = 49,1дБ

По СН 2.2.4/2.1.8.562-96 уровень шума на рабочем месте математиков-программистов и операторов видеоматериалов не должен превышать 50 дБ.

7.2.3 Защита от электромагнитного излучения

Защита от электромагнитного воздействия обеспечивается экранами с электропроводящей поверхностью и использованием мониторов, снабженных системой Low Radiation, которая сводит к минимуму уровень вредных излучений, а также жидкокристаллических мониторов, в которых электромагнитное излучение полностью отсутствует.

7.2.4 Защита от электростатического поля

Для защиты от воздействия электростатического заряда применяется заземленный защитный фильтр, увлажнители воздуха, а полы покрыты антистатическим покрытием. Для поддержания нормированных значений концентрации положительных и отрицательных ионов в помещениях с ЭВМ установлены кондиционеры, устройства ионизации воздуха и проводится естественное проветривание длительностью не менее 10 минут после каждых 2 часов работы.

В целях предотвращения вредного влияния на организм работающих людей пылинок с аэроиноами ежедневно проводится влажная уборка помещений и не реже 1 раза в смену удаляется пыль с экранов при выключенном мониторе.

7.3 Условия труда

3.1 Микроклимат производственного помещения

Рассматриваемое в данном дипломном проекте оборудование в процессе работы не вырабатывает никаких вредных веществ. Таким образом, воздушная среда в помещении, где они используются, вредных воздействий на организм человека не оказывает и удовлетворяет требованиям I категории работ, согласно ГОСТ 12.1.005-88 .

Оптимальные нормы температуры, относительной влажности и скорости движения воздуха в рабочей зоне производственных помещений нормируются ГОСТ 12.1.005-88 и приведены в таблице 7.1.

Таблица 7.1 -Параметры микроклимата

Нормируемый параметрЗначениеОптимальноеДопустимоеФактическоеТемпература воздуха, С20 - 2218 - 2020Влажность, %40 - 60Не более 8045Скорость движения воздуха, м/с0,20,30..0,3

Микроклимат соответствует оптимальным условиям.

3.2 Производственное освещение

Для расчета выбираем отдел сопровождения в ООО Геркон в городе Верхняя Пышма, где происходила разработка данного проекта:

·площадь помещения равна 60м2;

·площадь световых проемов 10 м2;

·установлено 4 автоматизированных рабочих мест.

Расчет естественной освещенности производится по формуле СНиП 23.05-95 :

S0 = Sп * eн * Кз * N0 * КЗД / 100% * Т0 * Т1(7.2)

Где S0 - площадь световых проемов, м2;

Sп - площадь пола помещения, м2, 60;

eн - коэффициент естественной освещенности, 1,6;

Кз - коэффициент запаса, 1,5;

N0 - световая характеристика окон, 1;

КЗД - коэффициент, учитывающий затемнение окон противостоящими зданиями, 1,2;

Т0 - общий коэффициент светопропускания, 0,48;

Т1 - коэффициент отражения от поверхности помещения, 1,2.

Значения всех коэффициентов взяты в СНиП 23.05.-95 .

В результате расчета получаем: требуемая площадь световых проемов окон S0 = 3,4м2. Реальная площадь проемов равна 10м2, что превышает минимальную допустимую площадь световых проемов для помещений такого типа и является достаточным в светлое время суток.

Расчет искусственного освещения для комнаты, освещаемой 15 люминесцентными лампами типа ЛДЦ-60 мощностью по 60Вт каждая.

Согласно СНиП 23.05-95 , величина освещенности люминесцентными лампами должна быть в горизонтальной плоскости не ниже 300лм - для системы общего освещения. С учетом зрительной работы высокой точности величина освещенности может быть увеличена до 1000лм.

Световой поток люминесцентной лампы рассчитывается по формуле из СНиП 23.05.-95 :

Фи = Ен * S * Z * K / N * η(7.3)

гдеЕн - нормированная освещенность помещения, лк, 200;

S - площадь пола помещения, м2, 60;

Z - коэффициент, учитывающий отношение средней освещенности к минимальной, 1,1;

К - коэффициент запаса с учетом загрязнения воздуха, 1,3;

N - количество светильников, 15;

η - коэффициент использования светового потока, 0,8.

В результате получаем Фи = 1340лм, суммарный световой поток всех ламп равен 3740лм , следовательно, освещенность лаборатории выше минимально допустимой.

7.4 Эргономика рабочего места

4.1 Организация рабочего места

В соответствии с СанПиН 2.2.2/4.2.1340-03 , ВДТ (видеодисплейный терминал) должен отвечать следующим техническим требованиям:

·яркость освещения не менее 100кд/м2;

·минимальный размер световой точки не более 0,1 мм для цветного дисплея;

·контрастность изображения знака не менее 0,8;

·частота кадровой развертки не менее 7кГц

·количество точек не менее 640;

·антибликовое покрытие экрана;

·размер экрана не менее 31см по диагонали;

·высота символов на экране не менее 3,8мм;

·расстояние от глаз оператора до экрана должно быть порядка 40-80см;

ВДТ должен оборудован поворотной площадкой, позволяющей перемещать его в горизонтальной и вертикальной плоскостях в пределах 130-220мм и изменять угол наклона экрана на 10-15градусов.

Дипломный проект выполнялся на компьютере с ВДТ ViewSonic диагональю 39см. Данный монитор выполнен в соответствии с мировыми стандартами и отвечаем всем вышеперечисленным техническим требованиям.

К клавиатуре предъявляются следующие требования:

·окраска корпуса в спокойные мягкие тона с диффузным рассеиванием света;

·матовая поверхность с коэффициентом отражения 0,4 - 0,6 и не имеющая блестящих деталей, способных создавать блики;

Проект выполнялся на клавиатуре марки Logitech, которая соответствует всем вышеперечисленным требованиям.

Системные блоки устанавливаются на рабочем месте с учетом легкой досягаемости к накопителям на гибких магнитных дисках и удобного доступа к разъемам и органам управления на тыльной стороне. Часто используемые дискеты хранятся вблизи системного блока в пыле- и электромагнитозащищенной ячейке. Принтер, размещен справа от пользователя. Печатаемый текст виден оператору при нахождении его в основной рабочей позе. Вблизи от принтера в специальных отсеках хранится чистая бумага и другие необходимые принадлежности.

Соединительные кабели прокладываются в специальных каналах. Устройство каналов должно такое, что соединительные разъемы не препятствуют извлечению кабелей.

Для манипулятора типа «мышь» справа от пользователя на столешнице предусмотрена свободная площадка, которая по форме и размеру должна идентична поверхности экрана.

Рабочее место оператора соответствует требованиям ГОСТ 12.2.032-78 ССБТ .

Пространственная организация рабочего места обеспечивает оптимальную рабочую позу:

·голова наклонена вперед на 10 - 20 градусов;

·спина имеет упор, соотношение между плечом и предплечьем, а также между бедром и голенью - прямой угол.

Основные параметры рабочего места должны регулируемые. Этим обеспечивается возможность создания благоприятных условий труда отдельному человеку с учетом геоантропометрических характеристик.

Основные параметры рабочего места и мебели, оснащенного персональным компьютером (рис. 7.1)

Рис. 7.1 - Рабочее место оператора ЭВМ

·высота сидения 42 - 45 см;

·высота клавиатуры от пола 70 - 85см;

·угол наклона клавиатуры от горизонтали 7 - 15градусов;

·удаленность клавиатуры от края стола 10 - 26см;

·расстояние от центра экрана до пола 90 - 115см;

·угол наклона экрана от вертикали 0 - 30градусов (оптимальный 15);

·удаленность экрана от края стола 50 - 75см;

·высота рабочей поверхности для записей 74 - 78см;

На рабочем месте предусмотрена подставка для ног, рекомендуемую для всех видов работ, связанных с длительным сохранением в положении сидя

По СанПиН 2.2.2.542-96 характер труда оператора ЭВМ считается легким и относится к категории 1А.

Установлены перерывы через 2 часа от начала рабочей смены и через 2 часа после обеденного перерыва продолжительностью 15 минут каждый. Во время регламентированных перерывов с целью снижения нервно-эмоционального напряжения, утомления, устранения влияния гиподинамии выполняются комплексы упражнений.

7.5 Пожарная безопасность

Помещение, где производилась работа над данным проектом, установлена категория пожарной опасности В НПБ 105-03 - горючие и негорючие жидкости, твердые горючие и негорючие вещества и материалы, в том числе пыли и волокна, вещества и материалы, способные при взаимодействии с водой, кислородом воздуха или друг с другом только гореть при условии, что помещения, в которых они имеются в наличии или образуются, не относятся к категориям А или Б. Здание для помещения I степени огнестойкости по СНиП 21-01-97 .

В производственном помещении соблюдены следующие правила безопасности:

·проходы, выходы из помещения, доступы к средствам пожаротушения свободны;

·оборудование, находящееся в эксплуатации, исправно и проверяется каждый раз перед началом работы;

·по окончании работ помещение осматривается, обесточивается электросеть, закрывается помещение.

Число эвакуационных выходов из зданий из помещения два. Ширина эвакуационного выхода (двери) составляет 2м. На путях эвакуации используются обычные лестницы и распашные двери. На лестничных клетках отсутствуют какие-либо помещения, технологические коммуникации, выходы подъемников и грузовых лифтов. На эвакуационных путях устроено как естественное, так и искусственное аварийное освещение.

В качестве первичных средств пожаротушения в помещении находятся ручные углекислотные огнетушители в количестве двух в помещении.

Для обнаружения начальной стадии загорания и оповещения службы пожарной охраны используется система автоматической и пожарной сигнализации (АПС). Она самостоятельно приводит в действие установки пожаротушения, пока пожар не достиг больших размеров и оповещает городскую службу пожарной охраны.

Объекты ВЦ кроме АПС необходимо оборудовано установками стационарного автопожаротушения. Примены установки газового тушения пожаров, действие которых основано на быстром заполнении помещения огнетушащим газовым веществом, в результате чего снижается содержание кислорода в воздухе.

7.6 Чрезвычайные ситуации

В условиях данного помещения наиболее вероятной чрезвычайной ситуацией может быть пожар. При возникновении пожара необходимо эвакуировать персонал и сообщить о случившемся в службу пожарной охраны. План эвакуации представлен на рисунке 7.2.

Рис. 7.2 - План эвакуации при пожаре

8. ЭКОНОМИЧЕСКАЯ ЧАСТЬ

В этом разделе рассматриваются затраты на разработку системы сетевого мониторинга, её внедрение и сопровождение, а также сопутствующие материалы и оборудование.

В стоимости проекта находят сове отражение стоимость потребляемых в процессе разработки и производства средств и предметов труда (амортизация, стоимость оборудования, материалов, топлива, энергии и т.д.), часть стоимости живого труда (оплата труда), стоимость покупных модулей системы.

В процессе деятельности и увеличения объемов поставок услуг возникла проблема упреждающего обнаружения неисправных и слабых мест в организации сети, то есть ставилась задача внедрения решения, позволяющего прогнозировать необходимость замены или модернизации участков сети до того, как неисправности отразятся на работе абонентских узлов.

С ростом клиентской базы, а как следствие и числа активного оборудования, возникла необходимость оперативного отслеживания состояния сети в целом и отдельных её элементов в подробности. До внедрения системы сетевого мониторинга сетевому администратору приходилось подключаться посредствам протоколов telnet, http, snmp, ssh и т.п. к каждому интересующему узлу сети и пользоваться встроенными средствами мониторинга и диагностики. На данный момент емкость сети составляет 5000 портов, 300 коммутаторов 2-го уровня, 15 маршрутизаторов и 20 серверов внутреннего пользования.

Кроме этого перегрузки сети и плавающие неисправности обнаруживались только при возникновении серьезных проблем у пользователей, что не позволяло составлять планы по модернизации сети.

Всё это вело в первую очередь к постоянному ухудшению качества предлагаемых услуг и повышению нагрузки на системных администраторов и службу технической поддержки пользователей, что влекло за собой колоссальные убытки.

В соответствии со сложившейся ситуацией, было решено разработать и внедрить систему сетевого мониторинга, которая решала бы все вышеизложенные проблемы, которые, обобщив можно выразить следующим образом:

Необходимо разработать и внедрить систему мониторинга, позволяющую проводить слежение как за коммутаторами, маршрутизаторами разных производителей, так и серверов различных платформ. Ориентироваться на использование открытых протоколов и систем, с максимальным использованием готовых наработок из фонда свободного программного обеспечения, что с экономической точки зрения снижает затраты на лицензирование конечной системы к нулю.

Система должна удовлетворять следующим требованиям в экономическом плане:

·минимальные требования к аппаратным ресурсам (ведет к снижению затрат на аппаратную часть проекта);

·открытые исходные коды всех составляющих комплекса (позволяет самостоятельно изменять принцип работы системы, не прибегая к помощи сторонних проприетарных разработок и снижает стоимость лицензирования продукта);

·расширяемость и масштабируемость системы (позволяет расширить сферу применения приложения, не прибегая к помощи сторонных и проприетарных разработок и снижает стоимость лицензирования продукта);

·стандартные средства предоставления диагностической информации (позволяет снизить расходы на сопровождение системы);

·наличие подробной документации на все используемые программные продукты (дает возможность быстро обучить нового сотрудника);

·способность работать с оборудованием различных производителей (дает возможность использовать один программный продукт). (Полный список оборудования приведен в Приложении В).

В целом разработка проекта заняла 112 часов (2 недели). На внедрение этого проекта потребуется 56 часов (1 неделя).

1 Расчет затрат на разработку проекта

Затраты на разработку проекта складываются из:

·затрат на заработную плату;

·затрат на амортизацию оборудования и программных продуктов;

·затрат на оплату электроэнергии;

·накладных расходов.

Расходы на заработную плату.

При расчете затрат на заработную плату учитываем, что данный проект разрабатывал один человек: системный инженер.

Среднерыночная заработная плата системного инженера требуемого уровня по региону составляет 30000 руб.

Рассчитаем стоимость 1 часа работы инженера, опираясь на следующие данные:

·премия 25%;

·районный коэффициент 15%;

·фонд рабочего времени в 2010 году, в соответствии с производственным календарем, составляет 1988 час;

Таким образом, расценка с учетом районного коэффициента составит:

РЧ = 30000*1,25*1,15*12/1988 = 260 руб

В расчете затрат на заработную плату учитываются отчисления, выплачиваемые с начисленной заработной платы, то есть общая величина тарифа страховых взносов будет равна максимальной ставке ЕСН - 26%, в том числе:

·ПФР - 20%;

·ФССР - 2,9%

·ФФОМС - 1,1%;

·ГФОМС - 2%;

·Обязательное социальное страхование от несчастных случаев - 0,2%.

В сумме отчисления составят:

СО = РЧ * 0,262 = 260 * 0,262 = 68 руб

С учетом времени работы инженера (112 часов на разработку и 56 часов на внедрение), рассчитаем расходы на заработную плату:

ЗП = (112 + 56) * (РЧ + СО) = 168 * 328 = 55104 руб

Расходы на амортизацию оборудования и программных продуктов.

В качестве основного оборудования на этапе разработки проекта сети использовались персональный компьютер и сервер AQUARIUS SERVER T40 S41. Стоимость компьютера на данный момент составляет примерно 17000 руб, тогда как сервера 30000 руб .

Таким образом стоимость разовых вложений в аппаратуру составит:

РВА = 47000 руб

В течение срока эксплуатации компьютера и сервера допускается их модернизация, данный вид затрат также учитывается при расчете. Закладываем 50% от РВ на модернизацию:

РМА = РВ * 0,5 = 23500 руб

Компьютер использовался на следующих этапах:

·поиск литературы;

·поиск решений проектирования системы сетевого мониторинга;

·разработка структур и подсистем;

·проектирование системы сетевого мониторинга;

·оформление документа.

Сервер использовался во время внедрения системы и непосредственной работы с системой.

Используемые в разработке программные продукты получены по свободным лицензиям, что говорит о нулевой их стоимости и отсутствии необходимости их амортизации.

Таким образом общие затраты на аппаратуру с учетом амортизации составят:

ОЗА = РВА + РМА = 47000 + 23500 = 70500 руб

Срок полезного использования принимаем 2 года. Стоимость одного часа работы составляет (приняв число рабочих дней в месяце 22 и при 8-часовом рабочем дне):

СОЧР = ОЗА / ВР = 70500 / 4224 = 16,69 руб

На время разработки и внедрения стоимость амортизационных отчислений соответственно составит:

САЧРВ = СОЧР * ТРВ = 16,69 * 168 = 2803,92 руб

Расходы на электроэнергию.

Расходы на электроэнергию складываются из потребляемой компьютером и затрачиваемой на освещение. Стоимость электроэнергии:

СЭН = 0,80 руб/кВт * ч (По договору с собственником помещения)

Рк,с = 200 Вт - мощность, потребляемая компьютером или сервером.

Трк = 168 ч - время работы компьютера на этапе разработки и внедрения системы.

Трс = 52 ч - время работы сервера на этапе разработки и внедрения системы.

Таким образом стоимость электроэнергии на этапе разработки и внедрения проекта составит:

СЭНП = Рк * Трк * СЭН + Рк * Трс * СЭН = (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 = (26880 + 8320) / 1000 = 35,2 руб

Рабочее место, на котором производилась данная работа, оснащено светильником мощностью 100 Вт. Рассчитаем стоимость электроэнергии, затраченной осветительным прибором на время разработки и внедрения системы:

СЭНО = 100 * Трк * СЭН = (100 * 168 * 0,80) / 1000 = 13,44 руб

Общие затраты на электроэнергию составили:

ОЗЭН = СЭНП + СЭНО = 35,2 + 13,44 = 48,64 руб

8.2 Расчет накладных расходов

Данный пункт затрат охватывает затраты на прочее оборудование и расходные материалы, также непредвиденные расходы.

Накладные расходы в бюджете предприятия составляют 400% от начисленной заработной платы:

НР = ЗП * 4 = 55104 * 4 = 220416 руб.

Таким образом затраты на разработку и внедрение проекта составили:

СРВ = ЗП + САЧРВ + ОЗЭН + НР = 55104 + 2803,92 + 48,64 + 220416 = 278372,56 руб

3 Эффективность

В результате выполнения экономических расчетов была назначена минимальная цена разработки и внедрения системы сетевого мониторинга 278372,56 руб.

Как видно из расчетов, подавляющая часть стоимости расходов приходится на материалы и оборудование. Это объясняется тем, что производители основного оборудования это зарубежные компании и соответственно цены на данную продукцию приводятся в американских долларах по курсу ЦБРФ + 3%. А повышение таможенных пошлин на ввозимую продукцию также негативно сказывается на цене для конечных заказчиков.

Для обоснования самостоятельной разработки системы сравним ее стоимость с готовыми решениями, присутствующими на рынке :

·D-Link D-View - 360 000 руб

Введение

В последние годы информационные технологии претерпевают значительные и постоянные изменения. По некоторым оценкам, за последние пять лет объем сетевого трафика локальных сетей вырос в десять раз. Таким образом, локальные сети должны обеспечивать все большую пропускную способность и необходимый уровень качества обслуживания. Однако какие бы ресурсы ни имела сеть, они все-таки конечны, поэтому для сети необходима возможность управления трафиком.

А для того чтобы управление было максимально эффективным, требуется возможность контроля над пакетами, передающимися между устройствами вашей сети. Также у администратора существует великое множество обязательных для исполнения ежедневных операций. Это, например, проверка правильности функционирования электронной почты, просмотр регистрационных файлов на предмет выявления ранних признаков неисправностей, контроль за подключением локальных сетей и за наличием системных ресурсов. И здесь на помощь могут прийти средства, применяемые для мониторинга и анализа вычислительных сетей.

Чтобы не запутаться в многообразии методик, средств и продуктов, созданных для мониторинга, начнем с краткого описания нескольких крупных классов этих продуктов.

Системы управления сетью (Network Management Systems). Это централизованные программные системы, которые собирают данные о состоянии узлов и коммуникационных устройств сети, а также о трафике, циркулирующем в сети. Эти системы не только осуществляют мониторинг и анализ сети, но и выполняют в автоматическом или полуавтоматическом режиме действия по управлению сетью - включение и отключение портов устройств, изменение параметров мостов адресных таблиц мостов, коммутаторов и маршрутизаторов и т.п. Примерами систем управления могут служить популярные системы HPOpenView, SunNetManager, IBMNetView.

Средства управления системой (System Management). Средства управления системой часто выполняют функции, аналогичные функциям систем управления, но по отношению к другим объектам. В первом случае объектом управления является программное и аппаратное обеспечение компьютеров сети, а во втором - коммуникационное оборудование. Вместе с тем некоторые функции этих двух видов систем управления могут дублироваться, например средства управления системой могут выполнять простейший анализ сетевого трафика.

Встроенные системы диагностики и управления (Embedded systems). Эти системы выполняются в виде программно-аппаратных модулей, устанавливаемых в коммуникационное оборудование, а также в виде программных модулей, встроенных в операционные системы. Они выполняют функции диагностики и управления только одним устройством, и в этом их основное отличие от централизованных систем управления. Примером средств этого класса может служить модуль управления концентратором Distrebuted 5000, реализующий функции автосегментации портов при обнаружении неисправностей, приписывания портов внутренним сегментам концентратора и некоторые другие. Как правило, встроенные модули управления «по совместительству» выполняют роль SNMP-агентов, поставляющих данные о состоянии устройства для систем управления.

Анализаторы протоколов (Protocol analyzers). Представляют собой программные или аппаратно-программные системы, которые ограничиваются, в отличие от систем управления, лишь функциями мониторинга и анализа трафика в сетях. Хороший анализатор протоколов может захватывать и декодировать пакеты большого количества применяемых в сетях протоколов - обычно несколько десятков. Анализаторы протоколов позволяют установить некоторые логические условия для захвата отдельных пакетов и выполняют полное декодирование захваченных пакетов, то есть показывают в удобной для специалиста форме вложенность пакетов протоколов разных уровней друг в друга с расшифровкой содержания отдельных полей каждого пакета.

Экспертные системы. Системы этого вида аккумулируют человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние. Экспертные системы часто реализуются в виде отдельных подсистем различных средств мониторинга и анализа сетей: систем управления сетями, анализаторов протоколов, сетевых анализаторов. Простейшим вариантом экспертной системы является контекстно-зависимая help-система. Более сложные экспертные системы представляют собой так называемые базы знаний, обладающие элементами искусственного интеллекта. Примером такой системы является экспертная система, встроенная в систему управления Spectrum компании Cabletron.

Многофункциональные устройства анализа и диагностики. В последние годы в связи с повсеместным распространением локальных сетей возникла необходимость разработки недорогих портативных приборов, совмещающих функции нескольких устройств: анализаторов протоколов, кабельных сканеров и даже некоторых возможностей ПО сетевого управления. В качестве примера такого рода устройств можно привести Compas компании Microtest, Inc. или 675 LANMeter компании FlukeCorp.

Системы управления

В последнее время в области систем управления наблюдаются две достаточно четко выраженные тенденции:

1. Интеграция в одном продукте функций управления сетями и системами. (Несомненное достоинство этого подхода - единая точка управления системой. Недостаток заключается в том, что при большой нагрузке на сеть сервер с установленной программой мониторинга может не справляться с обработкой всех пакетов и, в зависимости от продукта, либо игнорировать часть пакетов, либо становиться «узким местом» системы.).
2. распределенность системы управления, при которой в системе существует несколько консолей, собирающих информацию о состоянии устройств и систем и выдающих управляющие действия. (Здесь все наоборот: задачи мониторинга распределены между несколькими устройствами, но возможны дублирование одних и тех же функций и несогласованность между управляющими воздействиями разных консолей.)

Зачастую системы управления выполняют не только функции мониторинга и анализа работы сети, но и включают функции активного воздействия на сеть - управления конфигурацией и безопасностью (см. врезку).

Протокол управления сетями SNMP

Большинству специалистов, занимающихся построением сетей и их управлением, нравится концепция стандартов. Это вполне объяснимо, ведь стандарты позволяют им выбирать поставщика сетевой продукции на основании таких критериев, как уровень сервиса, цена и эксплуатационные характеристики продукции, вместо того чтобы быть «прикованными» к фирменному решению одного производителя. Самая большая на сегодня сеть - Интернет - основана на стандартах. С целью координации усилий по их разработке для этой и других использующих протоколы TCP/IP сетей была создана Инженерная проблемная группа Интернет (IETF).

Наиболее распространенным протоколом управления сетями является протокол SNMP (SimpleNetworkManagementProtocol), который поддерживают сотни производителей. Главные достоинства протокола SNMP - простота, доступность, независимость от производителей. Протокол SNMP разработан для управления маршрутизаторами в сети Интернет и является частью стека TCP/IP.

What is MIB - Man In Black?

Если речь идет об инструментах мониторинга корпоративной сети, то за этой аббревиатурой скрывается термин Management Information Base. Для чего нужна эта база данных?

SNMP - это протокол, используемый для получения от сетевых устройств информации об их статусе, производительности и характеристиках, которые хранятся в специальной базе данных сетевых устройств, называемой MIB. Существуют стандарты, определяющие структуру MIB, в том числе набор типов ее переменных (объектов в терминологии ISO), их имена и допустимые операции с этими переменными (например, читать). Наряду с другой информацией в MIB могут храниться сетевой и/или MAC-адреса устройств, значения счетчиков обработанных пакетов и ошибок, номера, приоритеты и информация о состоянии портов. Древовидная структура MIB содержит обязательные (стандартные) поддеревья; кроме того, в ней могут находиться частные (private) поддеревья, позволяющие изготовителю интеллектуальных устройств реализовать какие-либо специфические функции на основе его специфических переменных.

Агент в протоколе SNMP - это обрабатывающий элемент, который обеспечивает менеджерам, размещенным на управляющих станциях сети, доступ к значениям переменных MIB и таким образом предоставляет им возможность реализовать функции по управлению и наблюдению за устройством.

Полезным добавлением к функциональным возможностям SNMP является спецификация RMON, обеспечивающая удаленное взаимодействие с базой MIB. До появления RMON протокол SNMP не мог использоваться удаленным образом, он допускал только локальное управление устройствами. Однако RMON лучше всего действует в разделяемых сетях, где он способен контролировать весь трафик. Но если в сети присутствует коммутатор, фильтрующий трафик таким образом, что он становится невидим для порта, если не предназначен для устройства, связанного с этим портом, или не исходит из этого устройства, то данные вашего зонда пострадают.

Во избежание этого производители снабдили некоторыми функциями RMON каждый порт коммутатора. Это более масштабируемая система, чем система постоянного опроса всех портов коммутатора.

Анализаторы протоколов

В ходе проектирования новой или модернизации старой сети часто возникает необходимость в количественном измерении некоторых характеристик сети, таких, например, как интенсивность потоков данных по сетевым линиям связи, задержки, возникающие на различных этапах обработки пакетов, времяреакции на запросы того или иного вида, частота возникновения определенных событий и др.

В этой непростой ситуации вы можете использовать разные средства и прежде всего - средства мониторинга в системах управления сетью, которые уже обсуждались в предыдущих разделах статьи. Некоторые измерения на сети могут быть выполнены и встроенными в операционную систему программными измерителями, примером тому служит компонент ОС WindowsNTPerformanceMonitor. Эта утилита была разработана для фиксации активности компьютера в реальном масштабе времени. С ее помощью можно определить большую часть «узких мест», снижающих производительность.

В основе PerformanceMonitor - ряд счетчиков, фиксирующих такие характеристики, как число процессов, ожидающих завершения операции с диском, число сетевых пакетов, передаваемых в единицу времени, процент использования процессора и др.

Но наиболее совершенным средством исследования сети является анализатор протоколов. Процесс анализа протоколов включает захват циркулирующих в сети пакетов, реализующих тот или иной сетевой протокол, и изучение содержимого этих пакетов. Основываясь на результатах анализа, можно осуществлять обоснованное и взвешенное изменение каких-либо компонентов сети, оптимизацию ее производительности, поиск и устранение неполадок. Очевидно, что для того, чтобы можно было сделать какие-либо выводы о влиянии некоторого изменения на сеть, необходимо выполнить анализ протоколов до и после внесения изменения.

Обычно процесс анализа протоколов занимает довольно много времени (до нескольких рабочих дней) и включает в себя следующие этапы:

1. Захват данных.
2. Просмотр захваченных данных.
3. Анализ данных.
4. Поиск ошибок.
5. Исследование производительности. Рассчет коэффициента использования пропускной способности сети или среднего времени реакции на запрос.
6. Подробное исследование отдельных участков сети. Содержание работ на этом этапе зависит от результатов, полученных при анализе сети.

На этом можно закончить рассмотрение теоретических моментов, которые необходимо учитывать при построении системы мониторинга вашей сети, и перейти к рассмотрению программных продуктов, созданных для анализа работы корпоративной сети и контроля за ней.

Продукты для мониторинга и анализа

Сравнительный обзор систем управления HPOpenView и CabletronSpectrum

Каждый комплект рассмотренных в этом разделе приложений разбивает управление сетью примерно на четыре области. Первая - это интеграция комплекта в общую инфраструктуру управления сетью, что подразумевает поддержку различных типов устройств того же производителя.

Следующая функциональная область - это средства конфигурирования и управления отдельными сетевыми устройствами, такими как концентратор, коммутатор или зонд.

Третья область - это средства глобального управления, которые отвечают уже за группирование устройств и организацию связей между ними, например приложения генерации схемы сетевой топологии.

Темой этой статьи является четвертая функциональная область - мониторинг трафика. И хотя средства конфигурирования ВЛВС и глобальное управление являются довольно важными аспектами сетевого администрирования, в отдельной сети Ethernet формальные процедуры управления сетью внедрять, как правило, нецелесообразно. Достаточно провести тщательное тестирование сети после инсталляции и время от времени проверять уровень нагрузки.

Хорошая платформа для систем управления корпоративными сетями должна обладать следующими качествами:

• масштабируемостью;
• истинной распределенностью в соответствии с концепцией «клиент/сервер»;
• открытостью, позволяющей справиться с разнородным - от настольных компьютеров до мэйнфреймов - оборудованием.

Первые два свойства тесно связаны. Хорошая масштабируемость достигается за счет распределенности системы управления. Распределенность здесь означает, что система может включать несколько серверов и клиентов.

Поддержка разнородного оборудования - скорее желаемое, чем реально существующее свойство сегодняшних систем управления. Мы рассмотрим два популярных продукта сетевого управления: Spectrum компании CabletronSystems и OpenView фирмы Hewlett-Packard. Обе эти компании сами выпускают коммуникационное оборудование. Естественно, система Spectrum лучше всего управляет оборудованием компании Cabletron, а OpenView - оборудованием компании Hewlett-Packard.

Если карта сети построена из оборудования других производителей, эти системы начинают ошибаться и принимать одни устройства за другие, а при управлении этими устройствами поддерживают только их основные функции, а многие полезные дополнительные функции, которые отличают данное устройство от остальных, система управления просто не понимает и поэтому не может ими воспользоваться.

Во избежание такой ситуации разработчики систем управления включают поддержку не только стандартных баз MIBI, MIBII и RMONMIB, но и многочисленных частных фирм - производителей MIB. Лидер в этой области - система Spectrum, поддерживающая более 1000 баз MIB различных производителей.

Однако несомненным преимуществом OpenView является ее способность распознавать сетевые технологии любых сетей, работающих по TCP/IP. У Spectrum эта способность ограничивается сетями Ethernet, TokenRing, FDDI, ATM, распределенными сетями, сетями с коммутацией. При увеличении устройств в сети более масштабируемой оказывается Spectrum, где количество обслуживаемых узлов ничем не ограничено.

Очевидно, что, несмотря на наличие слабых и сильных мест у той и другой системы, если в сети преобладает оборудование от какого-либо одного производителя, наличие приложений управления этого производителя для какой-либо популярной платформы управления позволяет администраторам сети успешно решать многие задачи. Поэтому разработчики платформ управления поставляют вместе с ними инструментальные средства, упрощающие разработку приложений, а наличие таких приложений и их количество считаются очень важным фактором при выборе платформы управления.

Системы для сетей широкого класса

Это сектор недорогих систем для не очень критичных к сбоям сетей, в него входят FoundationAgentMulti-Port, Foundation Probe, Foundation Manager производства NetworkGeneral. Они представляют собой законченную систему сетевого мониторинга на базе RMON и включают два типа агентов-мониторов - FoundationAgent и FoundationProbe, а также консоль оператора FoundationManager.

FoundationAgentMulti-Port поддерживает все возможности стандартного SNMP-агента и развитую систему сбора и фильтрации данных, а также позволяет с помощью одного компьютера собирать информацию с сегментов Ethernet или TokenRing.

FoundationProbe - сертифицированный компьютер с сертифицированной сетевой платой и предустановленным программным обеспечением FoundationAgent соответствующего типа. FoundationAgent и FoundationProbe обычно функционируют в безмониторном и бесклавиатурном режиме, поскольку управляются программным обеспечением FoundationManager.

Программное обеспечение консоли FoundationManager поставляется в двух вариантах - для Windows-систем и для UNIX.

Консоль FoundationManager позволяет отображать в графическом виде статистику по всем контролируемым сегментам сети, автоматически определять усредненные параметры сети и реагировать на превышение допустимых пределов параметров (например, запускать программу-обработчик, инициировать SNMP-trap и SNA-alarm), строить по собранным данным RMON графическую динамическую карту трафика между станциями.

Системы для распределенных сетей

Это сектор дорогих систем высшего класса, предназначенных для анализа и мониторинга сетей, предъявляющих максимально возможные требования по обеспечению надежности и производительности. В него входит продукт DistributedSnifferSystem (DSS), который представляет собой систему, состоящую из нескольких распределенных по сети аппаратных компонентов и программного обеспечения, необходимого для непрерывного анализа всех, включая удаленные, сегментов сети.

Система DSS строится из компонентов двух типов - SnifferServer (SS) и SniffMasterConsole (SM). В качестве интерфейсов для взаимодействия с консолью могут быть использованы карты Ethernet, TokenRing или последовательный порт. Таким образом, есть возможность контролировать сегмент практически любой сетевой топологии и использовать различные среды взаимодействия с консолью, включая соединения по модему.

Программное обеспечение SnifferServer состоит из трех подсистем - мониторинга, интерпретации протоколов и экспертного анализа. Подсистема мониторинга представляет собой систему отображения текущего состояния сети, позволяющую получать статистику по каждой из станций и сегментов сетей по каждому из используемых протоколов. Две остальные подсистемы заслуживают отдельного обсуждения.

В функции подсистемы интерпретации протоколов входит анализ захваченных пакетов и как можно более полная интерпретация каждого из полей заголовков пакетов и его содержимого. Компания NetworkGeneral создала самую мощную подсистему подобного типа - ProtocolInterpreter способен полностью декодировать более 200 протоколов всех семи уровней модели ISO/OSI (TCP/IP, IPX/SPX, NCP, DECnetSunNFS, X-Windows, семейство протоколов SNAIBM, AppleTalk, BanyanVINES, OSI, XNS, Х.25, различные протоколы межсетевого взаимодействия). При этом отображение информации возможно в одном из трех режимов - общем, детализированном и шестнадцатеричном.

Основное назначение системы экспертного анализа (ExpertAnalysis) - сокращение времени простоя сети и ликвидация «узких мест» сети посредством автоматической идентификации аномальных явлений и автоматической генерации методов их разрешения.

Система ExpertAnalysis обеспечивает то, что компания NetworkGeneral называет активным анализом. Для понимания этой концепции рассмотрим обработку одного и того же ошибочного события в сети системами традиционного пассивного анализа и системой активного анализа.

Допустим, в сети в 3:00 ночи произошел широковещательный шторм, вызвавший в 3:05 сбой системы создания архивных копий баз данных. К 4:00 шторм прекращается и параметры системы входят в норму. В случае работы в сети системы пассивного анализа трафика пришедшие на работу к 8:00 администраторы не имеют для анализа ничего, кроме информации о втором сбое и, в лучшем случае, общей статистики по трафику за ночь - размер любого буфера захвата не позволит хранить весь трафик, прошедший за ночь по сети. Вероятность ликвидации причины, приведшей к широковещательному шторму, в такой ситуации крайне мала.

А теперь рассмотрим реакцию на те же события системы активного анализа. В 3:00, сразу после начала широковещательного шторма, система активного анализа фиксирует наступление нестандартной ситуации, активирует соответствующий эксперт и фиксирует выданную им информацию о событии и его причинах в базе данных. В 3:05 фиксируется новая нестандартная ситуация, связанная со сбоем системы архивирования, и фиксируется соответствующая информация. В результате в 8:00 администраторы получают полное описание возникших проблем, их причин и рекомендации по устранению этих причин.

Переносные системы анализа и мониторинга

Портативный вариант анализатора, почти аналогичный по своим возможностям DSS, реализован в продуктах серии ExpertSnifferAnalyzer (ESA), известный также как TurboSnifferAnalyzer. При значительно меньшей, чем продукты серии DSS, стоимости ESA предоставляют администратору те же возможности, что и полномасштабная DSS, но только для того сегмента сети, к которой ESA подключен в данный момент. Существующие версии обеспечивают полный анализ, интерпретацию протоколов, а также мониторинг подключенного сегмента сети или линии межсегментной связи. При этом поддерживаются те же сетевые топологии, что и для систем DSS. Как правило, ESA используются для периодической проверки некритичных сегментов сети, на которых нецелесообразно постоянно использовать агент-анализатор.

Анализатор протоколов LANalyser компании Novell

LANalyser поставляется в виде сетевой платы и программного обеспечения, которые необходимо устанавливать на персональном компьютере, либо в виде ПК - с уже установленными платой и программным обеспечением.

LANalyser имеет развитый удобный пользовательский интерфейс, с помощью которого устанавливается выбранный режим работы. Меню ApplicationLANalyser является основным средством настройки режима перехвата и предлагает на выбор варианты набора протоколов, фильтров, инициаторов, аварийных сигналов и т.д. Данный анализатор может работать с протоколами NetBIOS, SMB, NCP, NCPBurst, TCP/IP, DECnet, BanyanVINES, AppleTalk, XNS, SunNFS, ISO, EGP, NIS, SNA и некоторыми другими.

Помимо этого в LANalyser включена экспертная система, оказывающая пользователю помощь в поиске неисправностей.

Заключение

Все вышеперечисленные системы, безусловно, необходимы в сети крупной корпорации, однако слишком громоздки для организаций, в которых число пользователей сети не превышает 200-300 человек. Половина функций системы останутся невостребованными, а счет за дистрибутив испугает главного бухгалтера и руководителя компании. Тем более что контроль за аппаратными неисправностями и «узкими местами» системы в небольшой сети в большинстве случаев вполне по силам одному-двум администраторам и не нуждается в автоматизации.

Тем не менее в сети любого масштаба, на наш взгляд, должна в том или ином виде присутствовать система сетевого анализа, благодаря которой администратору будет гораздо проще управлять своим хозяйством.

КомпьютерПресс 7"2001

Оригинальное название: A Summary of Network Traffic Monitoring and Analysis Techniques

Ссылка на оригинальный текст: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

Рекомендации: представленный перевод не является профессиональным. Возможны отступления от текста, неправильная трактовка тех или иных терминов и понятий, субъективное мнение переводчика. Все иллюстрации внесены в перевод без изменения.

Алиша Сессил

Обзор методов анализа и мониторинга сетевого трафика

Так как продолжают расти частные внутренние сети компаний, чрезвычайно важно, чтобы сетевые администраторы знали и умели управлять вручную различными типами трафика, который путешествует по их сети. Мониторинг и анализ трафика необходимы для того, чтобы более эффективно диагностировать и решать проблемы, когда они происходят, таким образом не доводя сетевые сервисы до простоя в течении длительного времени. Доступно много различных инструментов, которые позволяют помочь администраторам с мониторингом и анализом сетевого трафика. Данная статья обсуждает методы мониторинга ориентированные на маршрутизаторы и методы мониторинга не ориентированные на маршрутизаторы (активные и пассивные методы). Статья даёт обзор трёх доступных и наиболее широко используемых методов мониторинга сети, встроенных в маршрутизаторы (SNMP, RMON и Cisco Netflow) и предоставляет информацию о двух новых методах мониторинга, которые используют сочетание пассивного и активного методов мониторинга (WREN и SCNM).

1. Важность мониторинга и анализа сети

Сетевой мониторинг (мониторинг сети) - это сложная задача, требующая больших затрат сил, которая является жизненно важной частью работы сетевых администраторов. Администраторы постоянно стремятся поддержать бесперебойную работу своей сети. Если сеть «упадёт» хотя бы на небольшой период времени, производительность в компании сократится и (в случае организаций предоставляющих государственные услуги) сама возможность предоставления основных услуг будет поставлена под угрозу. В связи с этим администраторам необходимо следить за движением сетевого трафика и производительностью на всей сети и проверять, появились ли в ней бреши в безопасности.

2. Способы мониторинга и анализа

«Анализ сети - это процесс захвата сетевого трафика и его быстрого просмотра для определения того, что произошло с сетью» - Анжелла Оребаух. В следующих разделах обсуждаются два способа мониторинга сети: первый - маршрутизаторо-ориентированный, второй - не ориентированный на маршрутизаторы. Функциональность мониторинга, который встроен в сами маршрутизаторы и не требует дополнительной установки программного или аппаратного обеспечения, называют методами, основанными на маршрутизаторе. Не основанные на маршрутизаторах методы требуют установки аппаратного и программного обеспечения и предоставляют большую гибкость. Обе техники обсуждаются ниже в соответствующих разделах.

2.1. Методы мониторинга основанные на маршрутизаторе

Методы мониторинга основанные на маршрутизаторе - жёстко заданы (вшиты) в маршрутизаторах и, следовательно, имеют низкую гибкость. Краткое описание наиболее часто используемых методов такого мониторинга приведены ниже. Каждый метод развивался много лет прежде чем стать стандартизованным способом мониторинга.

2.1.1. Протокол простого сетевого мониторинга (SNMP), RFC 1157

SNMP - протокол прикладного уровня, который является частью протокола TCP/IP. Он позволяет администраторам руководить производительностью сети, находить и устранять сетевые проблемы, планировать рост сети. Он собирает статистику по трафику до конечного хоста через пассивные датчики, которые реализуются вместе с маршрутизатором. В то время, как существуют две версии (SNMPv1 и SNMPv2), данный раздел описывает только SNMPv1. SNMPv2 построен на SNMPv1 и предлагает ряд усовершенствований, таких как добавление операций с протоколами. Стандартизируется ещё один вариант версии SNMP. Версия 3 (SNMPv3) находится на стадии рассмотрения.

Для протокола SNMP присущи три ключевых компонента: управляемые устройства (Managed Devices), агенты (Agents) и системы управления сетью (Network Management Systems - NMSs). Они показаны на рис. 1.

Рис. 1. Компоненты SNMP

Управляемые устройства включают в себя SNMP-агента и могут состоять из маршрутизаторов, переключателей, коммутаторов, концентраторов, персональных компьютеров, принтеров и других элементов, подобных этим. Они несут ответственность за сбор информации и делают её доступной для системы управления сетью (NMS).

Агенты включают в себя программное обеспечение, которое владеет информацией по управлению, и переводят эту информацию в форму, совместимую с SNMP. Они закрыты для устройства управления.

Системы управления сетью (NMS) выполняют приложения, которые занимаются мониторингом и контролем устройств управления. Ресурсы процессора и памяти, которые необходимы для управления сетью, предоставляются NMS. Для любой управляемой сети должна быть создана хотя бы одна система управления. SNMP может действовать исключительно как NMS, или агент, или может исполнять свои обязанности или др.

Существует 4 основных команды, использующиеся SNMP NMS для мониторинга и контроля управляемых устройств: чтение, запись, прерывание и операции пересечения. Операция чтения рассматривает переменные, которые хранятся управляемыми устройствами. Команда записи меняет значения переменных, которые хранятся управляемыми устройствами. Операции пересечения владеют информацией о том, какие переменные управляемых устройств поддерживают, и собирают информацию из поддерживаемых таблиц переменных. Операция прерывания используется управляемыми устройствами для того, чтобы сообщить NMS о наступлении определённых событий.

SNMP использует 4 протокольные операции в порядке действия: Get, GetNext, Set и Trap. Команда Get используется, когда NMS выдаёт запрос на информацию для управляемых устройств. SNMPv1-запрос состоит из заголовка сообщения и единицы данных протокола (PDU). PDU-сообщения содержит информацию, которая необходима для удачного выполнения запроса, который будет либо получать информацию от агента, либо задавать значение в агенте. Управляемое устройство использует SNMP агентов, расположенных в нём, для получения необходимой информации и затем посылает сообщение NMS"у, с ответом на запрос. Если агент не владеет какой либо информацией по отношению к запросу, он ничего не возвращает. Команда GetNext будет получать значение следующего экземпляра объекта. Для NMS также возможно посылать запрос (операция Set), когда устанавливается значение элементов без агентов. Когда агент должен сообщить NMS-события, он будет использовать операцию Trap.

Как говорилось ранее, SNMP - протокол уровня приложений, который использует пассивные сенсоры, чтобы помочь администратору проследить за сетевым трафиком и производительностью сети. Хотя, SNMP может быть полезным инструментом для сетевого администратора, он создаёт возможность для угрозы безопасности, потому что он лишён возможности аутентификации. Он отличается от удалённого мониторинга (RMON), который обсуждается в следующем разделе, тем, что RMON работает на сетевом уровне и ниже, а не на прикладном.

2.1.2. Удалённый мониторинг (RMON), RFS 1757

RMON включает в себя различные сетевые мониторы и консольные системы для изменения данных, полученных в ходе мониторинга сети. Это расширение для SNMP информационной базы данных по управлению (MIB). В отличии от SNMP , который должен посылать запросы о предоставлении информации, RMON может настраивать сигналы, которые будут «мониторить» сеть, основанную на определённом критерии. RMON предоставляет администраторам возможности управлять локальными сетями также хорошо, как удалёнными от одной определённой локации/точки. Его мониторы для сетевого уровня приведены ниже. RMON имеет две версии RMON и RMON2. Однако в данной статье говорится только о RMON. RMON2 позволяет проводить мониторинг на всех сетевых уровнях. Он фокусируется на IP-трафике и трафике прикладного уровня.

Хотя существует 3 ключевых компонента мониторинговой среды RMON, здесь приводятся только два из них. Они показаны на рис. 2 ниже.

Рис. 2. Компоненты RMON

Два компонента RMON это датчик, также известный как агент или монитор, и клиент, также известный как управляющая станция (станция управления). В отличии от SNMP датчик или агент RMON собирает и хранит сетевую информацию. Датчик - это встроенное в сетевое устройство (например маршрутизатор или переключатель) программное обеспечение. Датчик может запускаться также и на персональном компьютере. Датчик должен помещаться для каждого различного сегмента локальной или глобальной сети, так как они способны видеть трафик, который проходит только через их каналы, но они не знают о трафике за их приделами. Клиент - это обычно управляющая станция, которая связана с датчиком, использующим SNMP для получения и коррекции RMON-данных.

RMON использует 9 различных групп мониторинга для получения информации о сети.

• Statistics - статистика измеренная датчиком для каждого интерфейса мониторинга для данного устройства.
• History - учёт периодических статистических выборок из сети и хранение их для поиска.
• Alarm - периодически берёт статистические образцы и сравнивает их с набором пороговых значений для генерации события.
• Host - содержит статистические данные, связанные с каждым хостом, обнаруженным в сети.
• HostTopN - готовит таблицы, которые описывают вершину хостов (главный хост).
• Filters - включает фильтрацию пакетов, основываясь на фильтровом уравнении для захвата событий.
• Packet capture - захват пакетов после их прохождения через канал.
• Events - контроль генерации и регистрация событий от устройства.
• Token ring - поддержка кольцевых лексем.

Как установлено выше, RMON, строится на протоколе SNMP. Хотя мониторинг трафика может быть выполнен при помощи этого метода, аналитические данные об информации, полученные SNMP и RMON имеют низкую производительность. Утилита Netflow, которая обсуждается в следующем разделе, работает успешно со многими пакетами аналитического программного обеспечения, чтобы сделать работу администратора намного проще.

2.1.3. Netflow, RFS 3954

Netflow - это расширение, которое было представлено в маршрутизаторах Cisco, которые предоставляют возможность собирать IP сетевой трафик, если это задано в интерфейсе. Анализируя данные, которые предоставляются Netflow, сетевой администратор может определить такие вещи как: источник и приёмник трафика, класс сервиса, причины переполненности. Netflow включает в себя 3 компонента: FlowCaching (кеширующий поток), FlowCollector (собиратель информации о потоках) и Data Analyzer (анализатор данных). Рис. 3 показывает инфраструктуру Netflow. Каждый компонент, показанный на рисунке, объясняется ниже.

Рис. 3. Инфраструктура NetFlow

FlowCaching анализирует и собирает данные о IP потоках, которые входят в интерфейс, и преобразует данные для экспорта.

Из Netflow-пакетов может быть получена следующая информация:

• Адрес источника и получателя.
• Номер входящего и выходящего устройства.
• Номер порта источника и приёмника.
• Протокол 4 уровня.
• Количество пакетов в потоке.
• Количество байтов в потоке.
• Временной штамп в потоке.
• Номер автономной системы (AS) источника и приёмника.
• Тип сервиса (ToS) и флаг TCP.

Первый пакет потока, проходящий через стандартный путь переключения, обрабатывается для создания кэша. Пакеты с подобными характеристиками потока используются для создания записи о потоке, которая помещается в кэш для всех активных потоков. Эта запись отмечает количество пакетов и количество байт в каждом потоке. Кэшируемая информация затем периодически экспортируется в Flow Collector (сборщик потоков).

Flow Collector - ответственен за сбор, фильтрование и хранение данных. Он включает в себя историю об информации о потоках, которые были подключены при помощи интерфейса. Снижение объёма данных также происходит при помощи Flow Collector"а при помощи выбранных фильтров и агрегации.

Data Analyzer (анализатор данных) необходим, когда нужно представить данные. Как показано на рисунке, собранные данные могут использоваться для различных целей, даже отличных от мониторинга сети, таких как планирование, учёт и построение сети.

Преимущество Netflow над остальными способами мониторинга, такими как SNMP и RMON, в том, что в ней существует программные пакеты, предназначенные для различного анализа трафика, которые существуют для получения данных от Netflow-пакетов и представления их в более дружелюбном для пользователя виде.

При использовании инструментов, таких как Netflow Analyzer (это только один инструмент, который доступен для анализирования Netflow-пакетов), информация, приведённая выше, может быть получена от Netflow-пакетов для создания диаграмм и обычных графиков, которые администратор может изучить для большего понимания о его сети. Наибольшее преимущество использования Netflow в отличии от доступных аналитических пакетов в том, что в данном случае могут быть построены многочисленные графики, описывающие активность сети в любой момент времени.

2.2. Технологии не основанные на маршрутизаторах

Хотя технологии, не встроенные в маршрутизатор всё же ограничены в своих возможностях, они предлагают большую гибкость, чем технологии встроенные в маршрутизаторы. Эти методы классифицируются как активные и пассивные.

2.2.1. Активный мониторинг

Активный мониторинг сообщает проблемы в сети, собирая измерения между двумя конечными точками. Система активного измерения имеет дело с такими метриками, как: полезность, маршрутизаторы/маршруты, задержка пакетов, повтор пакетов, потери пакетов, неустойчивая синхронизация между прибытием, измерение пропускной способности.

Главным образом использование инструментов, такие как команда ping, которая измеряет задержку и потери пакетов, и traceroute, которая помогает определить топологию сети, является примером основных активных инструментов измерения. Оба эти инструмента посылают пробные ICMP-пакеты до точки назначения и ждут, когда эта точка ответит отправителю. Рис. 4 - пример команды ping, которая использует активный способ измерения, посылая Echo-запрос от источника через сеть в установленную точку. Затем получатель посылает Echo-запрос обратно источнику от которого пришёл запрос.

Рис. 4. Команда ping (Акстивное измерение)

Данный метод может не только собирать единичные метрики об активном измерении, но и может определять топологию сети. Ещё один важный пример активного измерения - утилита iperf. Iperf - это утилита, которая измеряет качество пропускной способности TCP и UDP протоколов. Она сообщает пропускную способность канала, существующую задержку и потери пакетов.

Проблема, которая существует с активным мониторингом, - это то, что представленные пробы в сети могут вмешиваться в нормальный трафик. Часто время активных проб обрабатывается иначе, чем нормальный трафик, что ставит под вопрос значимость предоставленной информации от этих проб.

Согласно общей информации, описанной выше, активный мониторинг - это чрезвычайно редкий метод мониторинга, взятый в отдельности. Пассивный мониторинг напротив не требует больших сетевых расходов.

2.2.2. Пассивный мониторинг

Пассивный мониторинг в отличии от активного не добавляет трафик в сеть и не изменяет трафик, который уже существует в сети. Также в отличии от активного мониторинга, пассивный собирает информацию только об одной точке в сети. Измерения происходят гораздо лучше, чем между двумя точками, при активном мониторинге. Рис. 5 показывает установку системы пассивного мониторинга, где монитор размещён на единичном канале между двумя конечными точками и наблюдает трафик когда тот проходит по каналу.

Рис. 5. Установка пассивного мониторинга

Пассивные измерения имеют дело с такой информацией, как: трафик и смесь протоколов, количество битов (битрейт), синхронизация пакетов и время между прибытием. Пассивный мониторинг может быть осуществлён, при помощи любой программы, вытягивающей пакеты.

Хотя пассивный мониторинг не имеет затрат, которые имеет активный мониторинг, он имеет свои недостатки. С пассивным мониторингом, измерения могут быть проанализированы только оф-лайн и они не представляют коллекцию. Это создаёт проблему, связанную с обработкой больших наборов данных, которые собраны во время измерения.

Пассивный мониторинг может быть лучше активного в том, что данные служебных сигналов не добавляются в сеть, но пост-обработка может вызвать большое количество временных затрат. Вот почему существует комбинация этих двух методов мониторинга.

2.2.3. Комбинированный мониторинг

После прочтения разделов выше, можно благополучно переходить к заключению о том, что комбинирование активного и пассивного мониторинга - лучший способ, чем использование первого или второго по отдельности. Комбинированные технологии используют лучшие стороны и пассивного, и активного мониторинга сред. Две новые технологии, представляющие комбинированные технологии мониторинга, описываются ниже. Это «Просмотр ресурсов на концах сети» (WREN) и «Монитор сети с собственной конфигурацией» (SCNM).

2.2.3.1. Просмотр ресурсов на концах сети (WREN)

WREN использует комбинацию техник активного и пассивного мониторинга, активно обрабатывая данные, когда трафик мал, и пассивно обрабатывая данные на протяжении времени большого трафика. Он смотрит трафик и от источника, и от получателя, что делает возможным более аккуратные измерения. WREN использует трассировку пакетов от созданного приложением трафика для измерения полезной пропускной способности. WREN разбит на два уровня: основной уровень быстрой обработки пакетов и анализатор трассировок пользовательского уровня.

Основной уровень быстрой обработки пакетов отвечает за получение информации, связанной с входящими и исходящими пакетами. Рис. 6 показывает список информации, которая собирается для каждого пакета. К Web100 добавляется буфер для сбора этих характеристик. Доступ к буферу осуществляется при помощи двух системных вызовов. Один вызов начинает трассировку и предоставляет необходимую информацию для её сбора, пока второй вызов возвращает трассировку из ядра.

Рис. 6. Информация, собранная на главном уровне трассировок пакетов

Объект трассировки пакетов - способен координировать вычисления между различными машинами. Одна машина будет активировать работу другой машины, задавая флаг в заголовке уходящего пакета для начала обработки некоторого диапазона пакетов, которые она трассирует. Другая машина будет в свою очередь трассировать все пакеты, для которых она видит, что в заголовке установлен похожий флаг. Такая координация обеспечивает то, что информация об похожих пакетах хранится в каждой конечной точке независимо от связи и того, что происходит между ними.

Анализатор трассировок пользовательского уровня - другой уровень в среде WREN. Это компонент, который начинает трассировку любого пакета, собирает и обрабатывает возвращённые данные на уровне ядра оператора. Согласно проектированию, компоненты пользовательского уровня не нуждаются в чтении информации от объекта трассировки пакетоввсё время. Они могут быть проанализированы незамедлительно после того, как трассировка будет завершена, чтобы сделать заключение в реальном времени, или данные могут быть сохранены для дальнейшего анализа.

Когда трафик мал, WREN будет активно вводить трафик в сеть сохраняя порядок следования потоков измерения. После многочисленных исследований, найдено, что WREN представляет похожие измерения в перенасыщенных и в не-перенасыщенных средах.

В текущей реализации WREN, пользователи не принуждаются только к захвату трассировок, которые были инициированы ими. Хотя любой пользователь может следить за трафиком приложений других пользователей, они ограничены в информации, которая может быть получена от трассировок других пользователей. Они могут только получить последовательность и подтверждение чисел, но не могут получить актуальные сегменты данных из пакетов.

В общем, WREN - это очень полезная установка, которая использует преимущества и активного, и пассивного мониторинга. Хотя эта технология находится на раннем этапе развития, WREN может предоставить администраторам полезные ресурсы в мониторинге и анализе их сетей. Монитор Собственного конфигурирования сети (SCNM) - другой инструментарий, который использует технологии и активного, и пассивного мониторинга.

2.2.3.2. Сетевой монитор с собственной конфигурацией (SCNM)

SCNM - это инструмент мониторинга, который использует связь пассивных и активных измерений для сбора информации на 3 уровне проникновения, выходящих маршрутизаторов, и других важных точек мониторинга сети. Среда SCNM включает и аппаратный, и программный компонент.

Аппаратное средство устанавливается в критических точках сети. Оно отвечает за пассивный сбор заголовков пакетов. Программное обеспечение запускается на конечной точке сети. Рис. 7, приведённый ниже, показывает программный компонент SCNM среды.

Рис. 7. Программный компонент SCNM

Программное обеспечение отвечает за создание и посылку активированных пакетов, которые используются для старта мониторинга сети. Пользователи будут посылать в сеть пакеты активации, содержащие детали о пакетах, которые они хотят получить для мониторинга и сбора. Пользователи не нуждаются в знании местоположения SCNM-хоста, принимая за истину то, что все хосты открыты для «прослушки» пакетов. На основе информации, которая существует в рамках активационного пакета, фильтр помещается в поток сбора данных, который также работает в конечной точке . Собираются заголовки пакетов сетевого и транспортного уровня, которые соответствуют фильтру. Фильтр будет автоматически введён в тайм аут, после точно заданного времени, если он получает другие пакеты приложения. Служба выборки пакетов, которая запускается на SCNM-хосте, использует команду tcpdump (подобно программе выборки пакетов) в порядке полученных запросов и записи трафика, который соответствует запросу.

Когда инструментами пассивного мониторинга определяется проблема, трафик может быть сгенерирование при помощи инструментов активного мониторинга, позволяя собирать добавляемые данные для более детального изучения проблемы. При развёртывании этого монитора в сети на каждом маршрутизаторе на протяжении пути, мы может изучать только секции сети, которые имеют проблемы.

SCNM предназначен для установки и использования, главным образом, администраторами. Тем не менее обычные пользователи могут использовать некоторую часть этой функциональности. Хотя обычные пользователи способны использовать части среды SCNM мониторинга, им позволено смотреть только свои собственные данные.

В заключение скажем, что SCNM - это ещё один способ комбинированного мониторинга, который использует и активный, и пассивный методы, чтобы помочь администраторам мониторить и анализировать их сети.

3. Заключение

Подбирая частные инструменты для использования их в мониторинге сети, администратор должен сначала решить, хочет ли он использовать хорошо зарекомендовавшие себя системы, которые уже использовались много лет, или новые. Если существующие системы более подходящее решение, тогда NetFlow - наиболее полезный инструмент для использования, так как в связки с этой утилитой могут использоваться анализирующиеся пакеты данных для представления данных в более дружелюбном пользователю виде. Тем не менее, если администратор готов попробовать новую систему, решения комбинированного мониторинга, такие как WREN или SCNM, - лучшее направление для дальнейшей работы.

Слежение и анализ сети - жизненно необходимы в работе системного администратора. Администраторы должны стараться содержать свою сеть в порядке, как для не разрозненной производительности внутри компании, так и для связи с любыми существующими публичными сервисами. Согласно вышеописанной информации, некоторое число маршрутизаторо-ориентированных технологий и не основанные на маршрутизаторах, пригодны для помощи сетевым администраторам в ежедневном мониторинге и анализе их сетей. Здесь коротко описываются SNMP, RMON, и Cisco"s NetFlow - пример нескольких технологий, основанных на маршрутизаторах. Примеры не основанных на маршрутизаторах технологий, которые обсуждались в статье, - это активный, пассивный мониторинг и их сочетание.