Сравнительный анализ возможностей различных систем
Произведен анализ существующих систем мониторинга. Основные выявленные функции, которыми обладают системы — это возможность опроса устройств, получение уведомлений, составление отчетности и мониторинг.
Исходя из результатов анализа, можно сделать вывод о том, что системы не подходят заказчику по следующим критериям:
Ø AggreGate Network Manager и PRTG (Paessler Router Traffic Grapher) является платным ПО и для бесплатного использования лицензия дается только на 10 устройств, данное ограничение не приемлемо для эксплуатации заказчиком;
Ø Одно из требований, выдвинутых заказчиком,- система должна отслеживать все сетевые устройства, доступные по протоколу SNMP. Данное требование не может выполнить ни одна из бесплатных систем;
Ø Одно из пожеланий заказчика заключается в наличии русского языка интерфейса. Это пожелание может выполнить только AggreGate Network Manager.
Таким образом, произведя анализ и сравнение аналогов, можно сделать вывод о том, что ни одна из рассмотренных систем не выполняет полный перечень требований заказчика. Поэтому было принято решение о разработке собственного программного обеспечения (RN-Monitoring). В полученной системе были учтены все требования заказчика. Система Web-ориентирована, для её использования на рабочих станциях не нужно использование дополнительных программ и библиотек [8].
В таблице 2.1 показан сравнительный анализ возможностей различных программных продуктов.
Таблица 2.1. Сравнительный анализ аналогов ПО.
| Название системы/ Функции | The Dube | Zabbix | Nagios | PRTG | AggreGate Network Manager | RN-Monitoring | |
| Интерфейсы | En | Ru | En | En | Ru | Ru | |
| Кроссплатформенность | Да | Да | Да | Нет | Да | Да | |
| Графическое отображение устройств | Да | Да | Да | Да | Да | Да | |
| Просмотр MIB | Да | Нет | Да | Нет | Нет | Да | |
| Изменяемый набор параметров | Да | Нет | Нет | Да | Да | Да | |
| Мониторинг агентов | ∞ | ∞ | ∞ | ∞ | ∞ | ∞ | |
| Наличие личного кабинета | Да | Да | Да | Да | Нет | Да | |
| Оповещения о сбоях (SMS, Email) | Да | Да | Да | Да | Да | Да | |
| Отчеты | Нет | Да | Да | Да | Да | Да | |
| Мониторинг | Сетевого оборудования | Да | Да | Да | Да | Да | Да |
| Периферийных устройств | Нет | Нет | Да | Нет | Нет | Да | |
| Оборудования электропитания | Нет | Нет | Нет | Нет | Нет | Да | |
| Freeware | Да | Да | Да | Нет | Нет | Да | |
| Возможность удаленного администрирования | Да | Да | Да | Да | Да | Да | |
| Ведение статистики | Да | Да | Нет | Да | Да | Да |
ОПИСАНИЕ РАЗРАБОТАННОГО ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Описание протокола SNMP
Протокол SNMP (Simple Network Management Protocol) - предназначен для проверки функционирования сетевых маршрутизаторов и мостов. Со временем сфера действия протокола стала распространяться и на другие сетевые устройства, такие как: хабы, шлюзы, терминальные сервера, многофункциональные устройства, принтеры и т.д. Существуют различные версии протокола, основным направлением развития которых было совершенствование вопросов безопасности. Существуют следующие версии SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u, SNMPv3.
Протокол был создан для решения следующих задач:
Ø Обработка ошибок (выявление, определение и устранение после сбоев и отказов в работе сети);
Ø Анализ производительности и надежности (оценка на основе статистической информации таких параметров, как время реакции системы, пропускная способность каналов связи и т.д.).
При разработке стандартов SNMP основной идеей было сделать управление протоколом простым, пренебрегая при этом такими характеристиками как мощность, масштабируемость и защищенность [9].
Архитектура
Составные элементы системы управления SNMP:
o Компоненты:
· Агент;
· Менеджер;
o Соединители:
· Транспортный протокол;
o Данные:
· Управляющая информация MIB (Management Information Base).
Компоненты.
Архитектура системы SNMP построена по схеме «клиент-сервер». Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточной простой сервер - агент SNMP, а также, по крайней мере, один узел, содержащий сложного клиента-менеджера SNMP.
Связь между агентом и менеджером осуществляется при помощи протокола SNMP с целью обмена управляющей информацией. Менеджер периодически опрашивает множество агентов. Агенты, работающие на хостах, собирают информацию об устройствах и записывают собранные счетчики в значения переменных в базу управляемой информации MIB. Тем самым делая ее доступной для менеджеров. Данная реализация системы теряет в масштабируемости, поскольку есть выделенный клиент, занимающийся опросом всех серверов. Такая схема построения обеспечивает простоту реализации систем под управлением SNMP [10].
Соединители
SNMP работает на 7 уровне модели OSI, являясь службой прикладного уровня. Взаимодействие агента и менеджера на уровне протокола SNMP организуется посредством объектов PDU (Protocol Data Unit), которые инкапсулируются в транспортный протокол. Структура объекта PDU отображена на рисунке 3.1.
Рис.3.1. Структура PDU
Поля и значения:
Ø Версия (содержит версию SNMP);
Ø Пароль (содержит последовательность символов, описывающую принадлежность к группе);
Ø Тип PDU (цифровой идентификатор запроса);
Ø Идентификатор запроса, это тот самый набор символов, который связывает в единое целое запрос\ответ.
Ø Статус ошибки – это число, характеризующее характер ошибки:
Ø 0(NoError) – нет ошибки;
Ø 1(TooBig) - объект не вмещается в одно Response сообщение,
Ø 2(NoSuchName) – несуществующая переменная;
Ø 3(BadValue) – недопустимое значение или совершена синтаксическая ошибка,
Ø 4(ReadOnly)- при Set запросе была попытка изменить read-only переменную;
Ø 5(GenErr) – другие ошибки.
Ø Индекс ошибки;
Ø Связанные переменные может содержать одну и более переменную (для запросов Get – только имя переменной, Set – имя и устанавливаемое значение, для Response – имя и запрошенное значение).
SNMP PDU (или сообщения SNMP протокола)
Для обмена между агентом и менеджером используется определенный набор команд:
Ø Trap-одностороннее уведомление от SNMP агента менеджеру о каком-либо событии;
Ø GetReponse – ответ от агента к менеджеру, возвращающий запрошенные значения переменных;
Ø GetRequest – запрос к агенту от менеджера, используемый для получения значения одной или нескольких переменных;
Ø GetNextRequest – запрос к агенту от менеджера, используемый для получения следующего в иерархии значения переменной;
Ø SetRequest – запрос к агенту на установку значения одной или нескольких переменных ;
Ø GetBulkRequest – запрос к агенту на получения массива данных;
Ø InformRequest – односторонее уведомление между менеджерами. Может использоваться для обмена информацией о MIB [11].
Данные
Вся управляющая информация для контроля сетевых устройств и маршрутами Интернет находится в базе данных MIB (Management Information Base).
Согласно нормативам MIB, управляющая информация делится на восемь категорий. MIB категории включают в себя информацию представленную в таблице 3.1.
Таблица 3.1 Описание категорий MIB
| MIB-категория | Описание |
| System | Операционная система ЭВМ или маршрутизатора |
| Interfaces | Сетевой интерфейс |
| Addr.trans | Преобразование адреса |
| IP | Программная поддержка протокола Интернет |
| ICMP | Программное обеспечение ICMP - протокола |
| TCP | Программное обеспечение TCP - протокола |
| UDP | Программное обеспечение UDP – протокола |
| EGP | Программное обеспечение EGP – протокола |
| SNMP | Программное обеспечение SNMP – протокола |