Лекция: Протоколы для программирования систем администрирования и мониторинга
Основной акцент — не на проблемах безопасности, а на проблемах управления. Хороший пример реализации таких систем можно найти в компании SpaceX, где используются современные подходы к мониторингу и администрированию.
Исторически системы мониторинга строились на основе протокола SNMP (Simple Network Management Protocol). Этот протокол появился как упрощённая альтернатива более сложным системам, таким как CMIP (Common Management Information Protocol), разработанным в рамках модели OSI в 60-е годы.
CMIP — разработан организацией OSI (Open Systems Interconnection) и основан на модели OSI с её 7 уровнями. Идея заключалась в том, что на каждом уровне работают менеджеры и агенты, обменивающиеся данными через CMIP. Всё описывалось с помощью нотации ASN.1 (Abstract Syntax Notation One) — стандарта ISO для описания структур данных.
Однако на практике выяснилось, что первые два уровня OSI (физический и канальный) управляются оборудованием (hardware), а не программным обеспечением, что усложняло реализацию.
В результате разработчики Интернета (IETF — Internet Engineering Task Force) создали SNMP — протокол, работающий только на 7-м уровне модели OSI (прикладной уровень). Он позволяет агентам и менеджерам обмениваться информацией.
Рисунок 1
SNMP — это стандарт IETF, который работает поверх протокола UDP (User Datagram Protocol) для передачи сообщений. В системе есть два ключевых элемента:
Агенты — программное обеспечение, встроенное в устройства (роутеры, коммутаторы и т.д.), которое имеет доступ к базе данных MIB (Management Information Base).
Менеджеры — системы, которые запрашивают данные у агентов.
MIB — это небольшая база данных на каждом устройстве, где описаны объекты (например, роутеры, коммутаторы) и их параметры. Примеры объектов: кол-во ошибочных UDP-датаграмм или общие данные об устройстве (системное имя, время работы и т.д.).
Объекты в MIB организованы в виде дерева имён, определённого ISO. Менеджеры запрашивают агентов, чтобы получить информацию о состоянии системы.
Команды SNMP:
Get Request — запрос конкретного значения.
Get Next Request — запрос следующего значения в дереве.
Get Response — ответ агента на запрос.
Set Request — установка значения (редко используется).
Trap — сообщение от агента к менеджеру о событии (например, сбой оборудования).
Trap — это своего рода "ловушка", установленная агентом на устройстве для передачи статистики или уведомлений. Частота опросов менеджерами обычно не превышает 1 раз в 5 минут, чтобы не перегружать систему.
Проблемы SNMP: Если агенты встроены в ОС роутеров или коммутаторов, они работают корректно. Но если используются внешние (резидентные) агенты, совместимость с ОС устройства может быть нарушена.
Для решения некоторых проблем SNMP был разработан протокол RMON (Remote Monitoring) — аппаратная реализация мониторинга. RMON встраивается в сетевые устройства (например, в сетевой адаптер роутера или порт коммутатора) через адаптеры Probe. Эти устройства собирают статистику по объектам SNMP, копируют данные и отправляют их менеджеру, когда буфер заполняется. Это снижает объём опросов.
Группы объектов RMON:
Statistics — статистика по трафику.
Alarms — сигналы тревоги.
Filters — условия фильтрации пакетов.
Events — регистрация событий и т.д.
Проблемы RMON:
Нет гарантии точной работы, так как отсутствуют средства проверки.
Зависимость от качества кабельной системы и оборудования.
Для полноценного контроля систем управления используется модель FCAPS (Fault, Configuration, Accounting, Performance, Security). Она требует поддержки производительности, что привело к появлению новых протоколов, таких как NetFlow (разработан Cisco, также известен как IPFIX).
NetFlow — это протокол управления, ориентированный на задачи производительности в FCAPS. Он основан на понятии «потока»: Поток — данные, передаваемые от одного IP-адреса и порта к другому IP-адресу и порту. (Но точного определения термина нет). Это позволяет оценивать скорость и объём трафика.
Как работает NetFlow:
Сенсор (программное обеспечение на роутере) собирает данные о потоках.
Анализ потоков требует «stateful»-протоколов (например, RTP, RTSP), которые фиксируют начало и конец потока. Однако большинство протоколов — «stateless» (без состояния), что усложняет анализ.
Проблемы NetFlow:
Устанавливается чаще всего на центральном маршрутизаторе, но его использование остаётся задачей администратора.
Замедляет работу системы до 5%.
Для анализа потоков нужны специальные адаптеры и оборудование.
Рисунок 2
Нет единого стандарта, какие модули должны быть в системе управления. Это открытый вопрос, и разные разработчики реализуют свои подходы. Однако два модуля обязательны:
MAP (Network Map) — карта сети.
Inventory — данные об устройствах и их работе.
Проблемы операторов связи:
Существуют специализированные системы OSS (Operations Support Systems) для операторов связи. Это сложные системы с модулями:
Performance Management — управление производительностью.
Workforce Management — управление бригадами.
Controller Management — управление контроллерами связи.
Configuration Management — конфигурация устройств.
Модель eTOM описывает функции OSS-систем.
Бизнес-метрики:
Технические метрики (скорость, ошибки) измеряются легко, но для информационных систем нужны бизнес-метрики (например, время ответа). Для этого используются продукты вроде NetQoS — коммерческого решения для анализа трафика и времени ответа. Оно дорогое, но эффективное.
SPI, MPI, DPI:
Современный мониторинг использует технологии SPI (Shallow Packet Inspection), MPI (Medium Packet Inspection) и DPI (Deep Packet Inspection), охватывающие уровни с 1 по 7 модели OSI. Это требует:
Специального оборудования (устанавливается до роутера, с режимом bypass).
Базы сигнатур для быстрого анализа.
Системы администрирования и мониторинга эволюционировали от SNMP к более сложным решениям, таким как RMON, NetFlow и DPI. Однако каждая технология имеет свои ограничения, и выбор зависит от задач администратора. Важно учитывать, как технические, так и бизнес-метрики для эффективного управления.