CC BY
63
УДК 004
DOI: 10.24412/2071-6168-2023-5-112-113
АНАЛИЗ СУЩЕСТВУЮЩИХ СИСТЕМ МОНИТОРИНГА ТЕХНИЧЕСКОГО СОСТОЯНИЯ ТЕЛЕКОММУНИКАЦИОННОГО ОБОРУДОВАНИЯ СЕТЕЙ СВЯЗИ
А.В. Боговик, Д.М. Сафиулов
В статье рассматриваются системы мониторинга телекоммуникационных сетей известных производителей, представлен их сравнительный анализ, сформулированы общие требования и общая архитектура. Предлагаемые решения не предполагают возможность прогнозирования состояния телекоммуникационной сети, что определяет целесообразность включения дополнительных модулей обработки статистической информации в системе подобного класса.
Ключевые слова: диагностика состояния телекоммуникационных сетей, информационно-телекоммуникационные сети, мониторинг состояния, требования к системе мониторинга.
Современная телекоммуникационная инфраструктура представляет собой сложную гетерогенную сеть, включающую телекоммуникационное, серверное и программное обеспечение, работающее в различных стандартах. Сложность и масштабность сетевой инфраструктуры предопределяют высокий уровень автоматизированных средств мониторинга и управления, которые должны использоваться для обеспечения надежной работы сети.
Целью создания системы мониторинга телекоммуникационной инфраструктуры является [12]:
создание эффективной службы диагностики и своевременного оповещения для предупреждения аварийных ситуаций и повышения отказоустойчивости телекоммуникационных систем;
выполнение сбора, обработки, хранения и отображения полной информации о состоянии всех компонентов телекоммуникационной и информационной инфраструктуры сети в реальном времени независимо от архитектуры сети, типа коммутационного оборудования и поставщика;
обеспечение высокой скорости обработки запросов пользователей на предоставление требуемых информационных ресурсов и сервисов;
разработка программно-аппаратных средств для управления информационными и телекоммуникационными ресурсами.
При этом должны обеспечиваться:
невмешательство в работу сетевого оборудования благодаря оверлейной архитектуре сбора
данных;
повышенная безопасность, поскольку зонды не зависят от коммутаторов и потери информации в результате отказов или перегрузок в сети отсутствуют;
постоянный сбор статистической информации, который позволяет создавать крупномасштабные базы данных, необходимые для проведения псевдооперативного и статистического анализа сети, трафика и технических параметров обслуживания;
управление сетью и обеспечение обслуживания в режиме реального времени - управление параметрами качества обслуживания;
интеграция с усовершенствованными инструментальными средствами анализа данных; создание единого информационного центра обработки данных о состоянии систем и сети. На практике к платформам системы мониторинга телекоммуникационной инфраструктуры предъявляются следующие основные требования [3-4]: масштабируемость;
поддержка распределенной архитектуры клиент - сервер;
открытость, позволяющая управлять оборудованием различных производителей; разграничение функции персонала поддержки.
В рамках решения задачи анализа систем мониторинга телекоммуникационных сетей, формирования общих требований и обобщения архитектуры подобных систем, рассмотрим некоторые из существующих систем сетевого мониторинга.
System Center Operations Manager (SCOM) [5] - система сквозного мониторинга (от Microsoft) и активного наблюдения за любыми сетевыми устройствами, поддерживающими протокол обмена информацией SNMP (до уровня порта), обнаружения виртуальных локальных вычислительных сетей (VLAN) и коммутаторов в них, слежения за их техническим состоянием.
SCOM предназначен в основном для организаций с числом сетевых устройств более 500 и числом серверов более 30. Для организаций меньшей структуры существует продукт System Center Essentials, включающий в себя часть функций SCOM и System Center Configuration Manager, но предназначенный для информационно-телекоммуникационных сетей (ИТКС) малых и средних предприятий. В последнее десятилетие SCOM относят к сервису высокой доступности, благодаря отсутствию серверов управления. При сопряжении с несколькими серверами нагрузка балансируется, обеспечивая доступность. При этом на каждом из серверов работает служба конфигурации, а хранение данных реализовано
не в памяти или XML-файлах, а в базе данных (БД). Microsoft также предоставляет возможность интеграции SCOM с System Center Service Manager, благодаря чему у пользователя есть возможность автоматического создания инцидентов на основе оповещений SCOM. Для слежения за виртуальными средами SCOM интегрируется с пакетом System Center Virtual Machine Manager, откуда получает информацию о частных облаках, виртуальных машинах и службах.
К основным преимуществам SCOM можно отнести:
высокую производительность и работоспособность в среде Microsoft;
обеспечение сквозного управления службами для сервисов центра обработки данных (ЦОД); унифицированный контроль частных и общедоступных облачных сервисов; существенное повышение эффекта в управлении средой ЦОДа.
Но одним из главных достоинств SCOM является продвинутая визуализация всего собранного набора метрик и представление их в виде графиков и диаграмм, что доступно как в специальной консоли программы, так и через web-интерфейс.
Однако SCOM имеет и ряд недостатков с точки зрения решения своего функционала [5] : она охватывает множество общих показателей системы, но непригодна для слежения за специфическими параметрами;
до сих пор работа с операционными системами (ОС) вне семейства Windows нестабильна; требует установки сервиса агента;
существенная громоздкость и трудоёмкость настройки «под себя» - система больше подходит для мониторинга общего состояния и сбора основных сведений о глобальной структуре (числе клиентских и серверных машин в домене и пр.).
Сюда же можно отнести высокую стоимость данного программного обеспечения (ПО). Zabbix [6] - свободно распространяемая система для проведения комплексного мониторинга сетевого оборудования, серверов и сервисов, состоящая из элементов: сервер мониторинга (ядро), прок-си, агент и Web-интерфейс.
С помощью Zabbix обычно осуществляют распределённый мониторинг до 1000 узлов, где конфигурация младших узлов в иерархии контролируется старшими. Также продукт включает централизованный мониторинг логфайлов. При этом имеется возможность создавать вручную по шаблону карты сетей, выполнять запросы в различные БД, генерировать отчёты и выявлять тенденции изменения метрик, выполнять сценарии на основе результатов мониторинга, поддерживать интеллектуальный интерфейс управления платформами (IPMI).
В качестве преимуществ Zabbix можно выделить то, что она позволяет осуществлять: автоматическое обнаружение IP-адресов по диапазону; доступные сервисы; проведение SNMP проверок;
автоматическое удаление отсутствующих хостов и автоматический мониторинг обнаруженных сетевых устройств с распределением их по шаблонам, группам и др. В качестве недостатков Zabbix стоит отметить: громоздкость сервиса;
отсутствие полной документированности возможностей;
необходимость установки Zabbix-агентов на все машины, сложность делегирования прав. Так, машина с сервисом зачастую управляется ОС семейства *nix, что делает трудоёмким взаимодействие с доменными пользователями и правами из Active Directory (Windows).
Nagios [7] - свободно распространяемое ПО для мониторинга ИТКС и изначально разработанное для ОС на базе Linux, однако эффективно работает под Sun Solaris, HPUX, FreeBSD, AIX. С помощью Nagios доступны: комплексный мониторинг за ИТ-инфраструктурой, мониторинг безопасности ИТКС, возможность оповещать администратора сети о получаемых данных в ходе наблюдения, выявление проблем сразу после их возникновения, что сокращает время простоя и коммерческие потери. Также к достоинствам Nagios относят:
мониторинг сетевых служб (SMTP, HTTP, SNMP, POP3, NNTP, ICMP);
мониторинг состояния хостов в большинстве сетевых ОС (загрузка процессора, системные ло-ги, использование диска);
поддержка удаленного мониторинга через шифрованные туннели SSH, SSL; возможность построения карт сетей;
простая архитектура плагинов (модулей расширений) позволяет разрабатывать свои собственные способы проверки служб, используя любойязык программирования по выбору; параллельный мониторинг служб;
возможность определения иерархии хостов сети с помощью «родительских» хостов, что позволяет обнаруживать и различать хосты, вышедшие из строя, или которые недоступны;
отправка оповещений при возникновении проблем со службой или хостом через модуль системы с помощью почты, sms, или иным способом, определяемым пользователем; осуществление автоматической ротации лог-файлов;
определение обработчика событий, возникающих с хостом, для разрешения проблем;
возможность создания распределенной системы мониторинга путем организации совместной работы нескольких систем мониторинга с целью повышения эффективности. К недостаткам использования Nagios можно отнести:
достаточно скудную функциональность «из коробки», влекущую за собой «общий» характер мониторинга и его «сетевую» направленность;
необходимость поиска и установки расширений для создания полнофункциональной системы мониторинга (например, автоматическое раскрытие топологии сети, сбор, визуализация и обработка данных временных рядов (rrdtool));
отсутствие функционала интеграции со средствами мониторинга каналов (точка-точка) как на уровне модели данных, так и на уровне отображения;
ориентация с точки зрения визуализации на устройства и сервисы, средств абстрагирования при переходе от детального отображения сети к высокоуровневому;
проблемы взаимодействия с серверами под ОС Windows.
Cacti [8] - бесплатное приложение мониторинга, которое позволяет собирать статистику по метрикам за определённые временные интервалы с отображением их в графическом виде при использовании утилиты RRDtool, предназначенной для функционирования с круговыми базами данных (типа Round Robin Database) и использующейся для хранения информации об изменении одного или нескольких параметров за определенный промежуток времени. Стандартно шаблон сбора включает статистику по загрузке процессора, количеству запущенных процессов, использованию входящего/исходящего трафика, выделению оперативной памяти.
Cacti написан в инфраструктуре Apache-PHP-MySql с возможностью дописывания собственных агентов сбора данных и настройкой сбора и отображение данных мониторинга. При этом интерфейс отображения статистики метрик, собранной с сетевых устройств, представлен деревом, структура которого может задаваться самим пользователем. Как правило, статистика группируется по заданным критериям, причем один и тот же график может присутствовать в разных ветвях дерева или рассматриваться отдельно, с представлением горизонта времени: последний день, неделя, месяц и год (или иной временной промежуток). Имеется режим предпросмотра (просмотр заранее составленного набора графиков). Достоинства Cacti:
высокая скорость развертывания при минимальном кодировании; простота и удобство интерфейса настройки просмотра отчетов. Недостатки Cacti: быстрый рост числа типовых настроек при большом количестве сред и серверов; ограниченная производительность «неродных» JMX решений; невозможность инвентаризации при перераспределении ресурсов сети.
Cacti позволяет для нескольких пользователей разграничить их права, как на просмотр статистики, так и на управление системой. В тоже время Cacti позволяет строить графики только основных показателей производительности, поскольку мониторинг нестандартных метрик значительно снижают производительность ПО.
Prometheus - свободно распространяемое ПО в интересах мониторинга сетевых устройств, серверов и сервисов с встроенным базовым интерфейсом, но чаще используется в связке с сервером визуализации данных Grafana.
В состав Prometheus входят:
- сервер мониторинга - выполняет периодический опрос и сбор данных с элементов сети, а также их обработку и анализ. При обнаружении аномалии осуществляет обращение к интерфейсу оповещения оператора. С помощью сервера мониторинга также удаленно контролируются сетевые сервисы. Фактически сервер мониторинга является хранилищем, в котором собраны конфигурационные, статистические и оперативные данные по структуре сети и функциональному состоянию сетевых элементов. Имеет удобный интерфейс для доступа к данным в случае интеграции с другими сервисами (интерфейс оповещения, интерфейс отображения). Как недостаток отметим, что он не предназначен к размещению на сервере под управлением операционной системы (ОС) семейства Windows;
экспортер (exporter) - элемент сервера мониторинга, осуществляющий сбор данных о доступности и производительности объектов мониторинга. Существует множество экспортеров предназначенных для сбора метрик из всех видов ОС и для сбора метрик из конкретных программных продуктов. При необходимости кастомизации может быть дописан самостоятельно для реализации отправки метрик элементу Pushgateway. Предоставляет web-интерфейс для доступа к метрикам объекта мониторинга, который опрашивается сервером мониторинга;
Pushgateway - специальное ПО, предназначенное для приема метрик от объекта мониторинга (агента), и представляющее их для сбора сервером мониторинга;
Alert manager - элемент сервера мониторинга, принимающий сигналы об аномалиях, и принимающий решение об использовании той или иной схемы оповещения ответственных лиц.
Operation Support Systems (OSS) - системы поддержки операций, построенные на базе протокола SNMP (версий 1 и 2). Используются ведущими телекоммуникационными компаниями.
В рассматриваемой высокоуровневой архитектуре OSS Hewlett-Packard (HP) OpenView-NNM [9], OpenNMS, а также Huawei U2000LCT, центральным компонентом OSS является компонент диспетчеризации событий, совмещенный с настраиваемым классификатором событий, отказов и предупреждений (рекомендация M.3703 [10]).
Еще одной из технологий все более настойчиво завоевывающей рынок IT-услуг для телеком-операторов и направленной на поддержание эксплуатационной надежности ИТКС и систем, является технология SRE (Site/System Reliability Engineering), рассматриваемая в виде набора инженерных практик, поддерживающих надежную и безотказную работу приложений в настоящем и будущем. Данная технология ориентирована на способность обнаруживать аномальные ситуации и проблемы в работе ИТКС до того, как о них сообщат абоненты. Концепция SRE-технологии ориентирована на решение внутренних задач ИТКС с измерением времени безотказной работы ее сетевых элементов и сервисов, а также точного определения их доступности с учетом требований по масштабируемости и внезапным форс-мажорам. Технология SRE предполагает устранение организационных барьеров между функциями специалистов по разработке специального ПО и по информационно-технологическому обслуживанию ИТКС с учетом взаимной интеграции их рабочих процессов друг в друга, как при использовании единых индикаторов оценки функциональной безопасности, так и общей ответственности всех участников предоставления информационно-телекоммуникационных услуг на этапах ЖЦ ИТКС.
Сетевой мониторинг в SRE-метриках на сегодня является единственным объективным и надежным методом (технологией) оценки параметров эффективного функционирования ИТКС, что требует разработки и совершенствования SRE-инструментария.
Место систем мониторинга в обобщенной модели управления ИТКС ОП
Системы мониторинга Функции модели управления информационно-телекоммуникационными сетями (F-C-A-P-S) Функции системы мониторинга
(F) Fault Management / Управление отказами (C) Configuration Management / Управление конфигурацией (A) Accounting Management / Учёт (P) Performance Management / Управление производительностью (S) Security Management / Управление безопасностью Мониторинг устройств Мониторинг соединений Мониторинг сетей Мониторинг сервисов
System Center Operations Manager (SCOM) +/-(мониторинг сервисов) + (унравление конфигурацией сервисов) + (учет сервисов) + + - - - +
Zabbix + +/-(только устройства и сервисы) + + - + +/- (отсутствует понятие канала) +/-(RMON) +
Nagios (Linux) + - +/- + - + +/- (отсутствует понятие канала) +/-(RMON) +
Cacti (только сбор данных) - + (без обработки) + - + +/- +/-(RMON) +
Prometheus + - + + - + - - +
OpenNMS + + + + - + +/- +/-(RMON) -
Amazon CloudWatch + - + + - - - - +
GMonE + - + + - - - - +
PCMONS + - + + - - - - +
IBM Tivoli Monitoring, HP Open View + + + + - + +/- + +
MonPaaS + + + + - - - - +
Существует множество и других решений, работающих поверх общедоступных и частных облаков, которые отслеживают использование облачных ресурсов. Среди них можно отметить следующие:
Amazon CloudWatch [11] - это служба мониторинга и управления, отслеживающая виртуальные ресурсы пользователей, такие как экземпляры виртуальных машин Amazon EC2;
GMonE [12] - универсальный инструмент облачного мониторинга, предлагающий унифицированную таксономию, на основе чего определяется его многоуровневая архитектура;
PCMONS [13] - система мониторинга частного облака, которую можно адаптировать для использования поставщиками облачной телефонии для сбора и централизации информации;
IBM Tivoli Monitoring [14] наряду с OSS и другими системами мониторинга также направлена на оптимизацию производительности и доступности ИТ-инфраструктур за счет сосредоточения внимания на физических ресурсах;
MonPaaS [15] - платформа адаптивного мониторинга с открытым исходным кодом как услуги. Она объединяет Nagios и OpenStack. MonPaas отслеживает физические и виртуальные ресурсы, а также обновляет любые изменения в физической или виртуальной инфраструктуре. Недостаток - потребляет дополнительные физические ресурсы.
Место систем мониторинга в обобщенной архитектуре управления ИТКС приведено в таблице 1 с представлением вышерассмотренных систем относительно реализации модели функциональной безопасности сети (FCAPS):
(F) Fault Management / Управление отказами;
(C) Configuration Management / Управление конфигурацией;
(A) Accounting Management / Учёт;
(P) Performance Management / Управление производительностью;
(S) Security Management / Управление безопасностью.
Таким образом, в соответствие с анализом функций управления ИТКС (таблица 1) можно сделать следующие выводы:
на мониторинг устройств ориентированы такие из рассмотренных систем как Zabbix, Nagios, Cacti, Prometheus, OpenNMs и HP Open View;
для мониторинга соединений и мониторинга сетей предназначены Zabbix, Nagios, Cacti, OpenNMS и HP Open View;
осуществлять мониторинг сервисов могут практически все из перечисленных систем мониторинга.
Рассмотренные системы мониторинга схожи по выполняемым функциям. Все они предоставляют почти одинаковый минимальный набор возможностей, однако каждая из них обладает определенными недостатками: в большинстве систем вообще не реализованы возможности прогнозирования состояния элементов сети, а в системах, где они реализованы, построение происходит на основе устаревшей статистической информации. Подобное прогнозирование не учитывает фрактальность трафика, нелинейность характеристик и нестационарность процессов.
Таким образом анализ задач, стоящих перед телекоммуникационными сетями в настоящее время, позволил сформировать набор требований, предъявляемых к современным системам мониторинга. Рассмотрены наиболее популярные системы мониторинга, представленные на мировом рынке.
Проведенный анализ показал, что все рассмотренные системы мониторинга или не способны прогнозировать состояние сети, или выполняют прогнозирование достаточно приближенно. Для более эффективного управления качеством обслуживания предоставляемых услуг (сервисов) в телекоммуникационной сети подобные системы должны поддерживать функции не только формирования трендов на основе полученной статистики, но и выполнять прогнозирование состояния сети, в том числе предотказ-ное состояние её элементов.
Список литературы
1. Боговик А.В., Губская О.А., Фатьянова Е.В. О перспективных технологиях построения распределенных автоматизированных информационно-измерительных систем мониторинга и управления транспортных сетей связи // Проблемы технического обеспечения войск в современных условиях. Труды IV межвузовской научно-практической конференции. Том 1. 2019. С. 104-107.
2. Боговик А.В., Сафиулов Д.М. Модель оценки качества системы мониторинга технического состояния техники связи и автоматизированных систем управления телекоммуникационных сетей специального назначения // Техника средств связи. 2022. № 4. С. 59-65.
3. Аллакин В.В., Будко Н.П., Васильев Н.В. Общий подход к построению перспективных систем мониторинга распределенных информационно-телекоммуникационных сетей // Системы управления, связи и безопасности. 2021. №4. С. 125-227.
4. Боговик А.В., Сафиулов Д.М. Системный анализ реализации работы автоматизированной системы мониторинга технического состояния техники связи узлов связи пунктов управления оперативного объединения // Известия Тульского государственного университета. Технические науки. 2023. Вып. 2. С. 248-251.
5. TechNet Magazine: System Center Operations Manager 2012: Простота расширения возможностей мониторинга. [Электронный ресурс] URL: http://technet.microsoft.com (дата обращения: 03.06.2023).
6. Vacche A.D., Lee S.K. Zabbix Mastering. Packt Publ., 2013. 358 р.
7. Nagios: отраслевой стандарт мониторинга ИТ-инфраструктуры. [Электронный ресурс] URL: URL: https://www.nagios.org (дата обращения: 03.06.2023).
8. XGU: Cacti. [Электронный ресурс] URL: http://xgu.ru (дата обращения: 03.06.2023).
9. Бломмерс Дж. OpenView Network Node Manager: Разработка и реализация корпоративного решения. М.: Интернет Университет Информационных Технологий, 2005. 264 с.
10. Recommendation ITU-T M.3703 Common management services. Alarm management. Protocol neutral requirements and analysis [Электронный ресурс] URL: http://www.itu/int/rec/T-REC (дата обращения: 03.06.2023).
11. Amazon, «Amazon CloudWatch». [Электронный ресурс] URL: https://aws.amazon.com/cloudwatch (дата обращения: 03.06.2023).
12. Montes H., Sanchez A., Memishi B., Perez M. S., António G. Gmone: an integrated approach to cloud monitoring. Future Generation Computer Systems, 2013, vol. 29, no. 8. P. 2026-2040.
13. De Chavez S. A., Uriarte R. B., Westfall K. B. Towards an architecture for Monitoring Private Clouds. IEEE Communications Magazine. 2011, vol. 49, no. 12. P. 130-137.
14. IBM, «IBM Tivoli Monitoring». [Электронный ресурс] URL: https://www.ibm.com/support/knowledgecenter/en/SS3JRN 7.2.0/com.ibm.itm.doc/itm install06.htm (дата обращения: 03.06.2023).
15. Alcaraz Calero J.M., Aguado J.G. Monpaas: Adaptive Monitoring Platform as a Service for Cloud Computing Infrastructures and Services. IEEE Transactions on Services Computing, 2015, vol. 8, no 1. P. 65-78.
Боговик Александр Владимирович, канд. воен. наук, профессор, bogovikav@mail.ru, Россия, Санкт-Петербург, Военная академия связи им. Маршала Советского Союза С.М. Буденного,
Сафиулов Давлет Муратович, адъюнкт, davletzas@mail.ru, Россия, Санкт-Петербург, Военная академия связи им. Маршала Советского Союза С. М. Буденного
ANALYSIS OF EXISTING SYSTEMS FOR MONITORING THE TECHNICAL CONDITION OF TELECOMMUNICATION EQ UIPMENT OF COMMUNICATION NETWORKS
A.V. Bogovik, D.M. Safiulov
The article discusses the monitoring systems of telecommunication networks of well-known manufacturers, presents their comparative analysis, formulated general requirements and general architecture. The proposed solutions do not imply the possibility of predicting the state of the telecommunications network, which determines the feasibility of including additional modules for processing statistical information in a system of this class.
Key words: diagnostics of the state of telecommunication networks, information and telecommunication networks, state monitoring, requirements for the monitoring system.
Bogovik Alexander Vladimirovich, candidate of military sciences, professor, bogovikav@mail.ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny,
Safiulov Davlet Muratovich, adjunct, davletzas@mail.ru, Russia, St. Petersburg, Military Academy of Communications named after Marshal of the Soviet Union S.M. Budyonny.
УДК 623.55.025
DOI: 10.24412/2071-6168-2023-5-117-118
ЗАДАЧА ВСТРЕЧИ АРТИЛЛЕРИЙСКОГО СНАРЯДА С ЦЕЛЬЮ (ТАБЛИЧНЫЙ АЛГОРИТМ)
П.Н. Мельников
Предлагается алгоритм решения задачи встречи неуправляемого артиллерийского снаряда с подвижной целью. Алгоритм реализуется в цифровой вычислительной системе корабельного зенитного комплекса.
Ключевые слова: задача встречи.
Задача встречи снаряда с целью решается в земной инерциальной системе с началом координат в точке стояния зенитного орудия. Расчет задачи встречи с обновленными входными данными повторяется с определенным заданным интервалом по времени. Для текущего дискретного момента времени
определяется положение осей прямоугольной земной инерциальной системы: ось Y направлена по
местной вертикали, ось X направлена на север и лежит в плоскости местного горизонта, ось Z дополнятся до получения правой системы координат и направлена на восток. В этой системе координат реализуется прогнозирование траектории полета цели. Входные данные о положении цели, ориентации корабля и выходные данные для наведения артиллерийского орудия представлены в сферической системе координат. Для прямых и обратных преобразований координат используются тригонометрические элементарные функции.
Алгоритм задачи встречи строится на базе известных для данного орудия баллистических и поправочных таблиц стрельбы. Табличные значения сохраняются в цифровой вычислительной системе зенитного корабельного комплекса в виде двумерного массива. Выборка баллистической или поправочной величины из массива осуществляется по известным значениям дальности до цели (DЦ) и значениям угла места цели (EЦ). Для промежуточных значений аргументов расчет выборки производится
117
