BC/NW 2011; №2 (19):7.1

 

АВТОМАТИЧЕСКОЕ ОБНАРУЖЕНИЕ "ALIVE" ХОСТОВ В СИСТЕМЕ МОНИТОРИНГА СЕТЕВЫХ КОМПОНЕНТ

 

Городничев С.В., Артюхов О.И.

(Москва, НИУ Московский энергетический институт, Россия)

 

 

         Любая корпоративная компьютерная сеть, даже небольшая, требует постоянного внимания к себе. Поскольку полностью исключить возможность отказа или некорректной работы техники невозможно, решение заключается в том, чтобы обнаруживать проблемы на наиболее ранних стадиях, и получать о них наиболее подробную информацию. Для этого, как правило, применяется различное ПО мониторинга и контроля сети, которое способно, как своевременно оповещать технических специалистов об обнаруженной проблеме, так и накапливать статистические данные о стабильности и других параметрах работы серверов, сервисов и служб, доступные для подробного анализа. В [1] рассмотрены основные аспекты разработки информационно-логической структуры разрабатываемой авторами системы мониторинга, предназначенной для решения поставленных проблем. В данной статье рассматривается уже более узкое направление, а именно, модуль системы, позволяющий автоматически обнаруживать т.н. "alive" (иначе "живые") хосты и добавлять их в базу данных наблюдаемых объектов сети.

Для средних и крупных предприятий весьма актуальной является проблема администрирования большого количества серверов. Ввиду того, что одной из главных целей IT-инфраструктуры является обеспечение бесперебойной работы бизнес-процесса, архитектура предприятия разделяется на несколько (чаще всего независимых) сред: DEV (среда разработки), TEST (среда тестирования) и PROD (продуктивная среда). В каждой из этих сред задействовано большое число серверов, физических или виртуальных. И если продуктивная среда меняется достаточно редко, то среды разработки и тестирования находятся в постоянном движении, серверы модифицируются, сливаются и разделяются, извлекаются неактуальные и добавляются новые. Технические сопровождение всех компонентов этой фермы серверов является основной задачей системных администраторов, поэтому вопрос мониторинга становится ещё более важным, в частности наличие в системе мониторинга инструмента для быстрого поиска и добавления новых серверов.

         Для удобного и наглядного представления изменяющейся структуры сети предприятия разработан модуль автоматического обнаружения "alive" хостов для указанного диапазона подсети, определения его базовых параметров (ip-адреса, hostname), сопоставления его по доменному имени с уже имеющимися в базе данных мониторинга и, в случае отсутствия, добавления в неё.

         Графический интерфейс данного модуля интегрирован в web-интерфейс системы мониторинга и представлен на рис. 1:

Рис.1. Интерфейс модуля автоматического обнаружения хостов.

 

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

Модуль находит "alive" хосты и заносит соответствующие им ip-адреса в массив. После этого каждый элемент массива сопоставляется с записью на DNS-сервере локальной сети: если для ip-адреса находится сопоставимое доменное имя, то элемент массива заменяется этим именем, в противном случае элемент не модифицируется. Далее массив (всего его элементы в идеальном случае - это hostname) сравнивается с записями в БД системы мониторинга из таблицы ref_servers: те хосты, для которых уже имеется запись в БД, удаляются из финальной выборки. После окончания работы, на web-интрефейсе системы мониторинга выводятся все новые "alive" серверы, которые в дальнейшем можно поставить на постоянный мониторинг. Обобщенная схема работы модуля показана на рис. 2:

Рис.2. Обобщенная схема работы модуля автоматического обнаружения хостов.

 

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

         Для удобства администратора в разработанном модуле, кроме определения базовых параметров (ip-адреса и hostname), реализовано автоматическое определение операционной системы удалённого сервера. Это продиктовано тем, что при добавлении новых серверов обязательным является указание типа ОС, так как в зависимости от него выполняются различные алгоритмы и сценарии проверки. Для определения ОС удаленного хоста, версия которой неизвестна, необходимо иметь определенную информацию о том, как ОС известных версий реагируют на определенные виды запросов, иначе говоря - составить "отпечаток" стека TCP/IP операционной системы. Алгоритм его получения состоит в следующем: сначала проводится сканирование портов удаленного хоста с целью определения какие из них открыты, а также какие службы функционируют на исследуемом хосте; далее проводится несколько тестов, поэтапно выполняющих опрос стека TCP/IP удаленного хоста с целью выявления рассмотренных выше признаков. На основе полученных от хоста ответов составляется отпечаток, который затем сравнивается с уже имеющейся базой отпечатков, и принимается решение о типе и версии ОС исследуемого хоста [2].

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

 

Рис.3. Архитектура тестируемой сети.

 

Рис.4. Пример работы скрипта обнаружения хостов.

 

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

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

 

ЛИТЕРАТУРА

1.  Артюхов О.И., Городничев С.В.   Система дистанционного мониторинга сетевых компонент.   //Труды XIX межд. научно-техн. конф. “Информационные средства и технологии”. 18-20 октября 2011г. Москва. В 3-х томах. Т.1. М.:Издательский дом МЭИ, 312с. –с.11-15

2.  Nmap Security Scanner. Обнаружение хостов. http://nmap.org/man/ru/man-host-discovery.html