CC BY
78АНАЛИЗ НОВЫХ ТЕХНОЛОГИЙ И ПЕРСПЕКТИВ РАЗВИТИЯ ТЕХНИКИ СРЕДСТВ СВЯЗИ
УДК 621.39
Общие принципы функционирования и требования к построению структур перспективных систем мониторинга распределенных информационно-телекоммуникационных сетей
Будко Н.П.
Аннотация. Постановка задачи: на основе анализа действующих технологий и существующих систем мониторинга информационно-телекоммуникационных сетей общего пользования выработать общие требования и подходы к построению перспективных систем сетевого мониторинга. Цель работы: обзор действующих систем мониторинга и выработка общих принципов, а также требований к построению систем сетевого мониторинга нового поколения. Используемые методы: методы системного анализа, структурного синтеза, технологии сетевого мониторинга Site/System Reliability Engineering, Operation Support Systems. Новизна работы: для повышения устойчивости и надежности подконтрольной сети ключевым архитектурным принципом проектирования современных подсистем мониторинга гетерогенных информационно-телекоммуникационных сетей выбран принцип распределенности и децентрализации. Результат: в работе определены функции подсистемы сетевого мониторинга и сервера мониторинга, как ключевого ее элемента. Предложен вариант структуры сервера мониторинга. Рассмотрены назначаемые объекты мониторинга, а также перечень собираемых с них метрических данных с точки зрения функциональной производительности сети. Сформулированы общие требования к перспективным системам сетевого мониторинга, а также общие принципы организации и функционирования подсистем мониторинга информационно-телекоммуникационной сети.
Ключевые слова: информационно-телекоммуникационная сеть, сервер мониторинга, техническое состояние, подсистема сетевого мониторинга, децентрализация мониторинга.
Введение
Развитие информационных технологий (ИТ) в последние десятилетия привело к существенным изменениям в общих подходах к построению и совершенствованию информационно-телекоммуникационных сетей (ИТКС). Ключевыми тенденциями при этом остаются процессы интеграции сетей связи с компьютерными сетями и появление распределенных гетерогенных ИТКС различного масштаба [1], характеризуемых широким внедрением и применением ИТ на базе концепции «Индустрия 4.0» (интернет вещей, «умный город», «умный дом» и пр.), обеспечивающих пользователям предоставление различных инфокоммуникационных услуг на основе стека протоколов TCP/IP/MPLS, с использованием сетей нового поколения NGN (Next Generation Networks), ядро которых составляют пакетные сети [2]. При этом техническая платформа ИТКС представляется структурированной совокупностью скоростных каналов связи, узлов коммутации, серверов услуг и сервисов связи, действующих в интересах пользователей ИТКС, а также иерархической автоматизированной системы управления связью (АСУС). Фундаментальным же требованием для любой АСУС гетерогенной ИТКС является эффективный мониторинг ее ресурсов [3], при котором необходимы точные и актуальные обновления в интересах поддержки своевременной реконфигурации сети (управления сетевыми ресурсами [4]) с целью устранения предотказного ее состояния и недопущения аварии.
Поддержание на высоком уровне эффективности функционирования ИТКС общего пользования (ОП) на протяжении своих этапов жизненного цикла (ЖЦ) напрямую зависят от значений показателей текущей функциональной надежности ее сетевых элементов и сегментов [5]. Последствия возникновения отказов или дефектов в ИТКС, обслуживающих отрасли с критически важными инфраструктурами (КВИ) могут привести к глобальным катастрофам и трагедиям с большими человеческими жертвами или значительным экологическим и финансовым ущербом. В связи с чем, на сегодня в телекоммуникационной отрасли активно ведется разработка новых технологий поддержания функциональной безопасности ИТКС и
систем, направленных на обеспечение их эксплуатационной надежности, а вопросам проведения мероприятий по диагностике и мониторингу технического состояния (контролю) уделяется первостепенное значение. Например, на внедрение методов неразрушающего контроля на эксплуатационных этапах ЖЦ атомной электростанции затраты могут составлять до 50 % всех эксплуатационных затрат [6]. Категоричность современных экологических нормативов и требований общественности о необходимости исключения техногенных аварий и катастроф с человеческими жертвами и огромным ущербом для окружающей среды делает проблему поддержания надежности и функциональной безопасности ИТКС актуальной, а разработку систем мониторинга функционального состояния их элементов - приоритетной.
Согласно [7] под мониторингом технического состояния (ТС) понимается составная часть технического обслуживания, заключающегося в наблюдении за объектом с целью получения информации о его ТС и рабочих параметрах. На основе данных мониторинга осуществляется контроль технического состояния или остаточного ресурса объекта контроля.
Мониторинг в информационно-телекоммуникационной отрасли, будь то небольшая компания или огромный центр обработки данных (ЦОД), необходим для того, чтобы системные администраторы ИТКС были оповещены раньше или хотя бы одновременно с пользователями об отказах и проблемах в сетевой инфраструктуре. Необходимость прогноза, а тем самым и предотвращения отказов, своевременное оповещение о них и хранение информации о ТС ИТКС и ее сетевых элементов обеспечивает актуальность данной работы. По своей сути мониторинг -это комплекс быстрого нахождения проблемы, оповещения о ней администраторов сети, а также диагностики, дающий полную и точную информацию об отказе объектов контроля (ОК) ИТКС.
Цель статьи: обзор действующих систем сетевого мониторинга и выработка на его основе общих принципов и требований к построению систем мониторинга нового поколения.
1. Учет особенностей современных ИТКС при построении их подсистем мониторинга
Одной из мало исследованных и еще нерешенных задач является построение подсистемы мониторинга процессов функционирования территориально-распределенных систем различной сложности. При этом, современные ИТКС как общего пользования (ОП), так и специального назначения (СН) [8] можно всецело отнести к гетерогенным сетям, что также накладывает определенные трудности и особенности построения их подсистем мониторинга (под гетерогенными называют, как правило сетевые структуры, образующиеся посредством объединения различных ведомственных сетей, имеющих разные принципы построения, сетевые технологии доставки и/или защиты информации, и /или программно-аппаратные средства [1]). Действительно, гетерогенность (неоднородность) сети предполагает несовместимость узлов, принадлежащих одной сети, либо к смежным сегментам сети по одному или нескольким логическим признакам: по типу применяемых операционных систем, форматам кадров сети, моделям безопасности, способам защиты информации и пр. Из чего следует, что в гетерогенных ИТКС подсистема мониторинга должна строиться на основе принципов децентрализации и многоуровневости. При том, что ИТКС, как правило, имеет строго иерархическую структуру, ее подсистема мониторинга должна позволять осуществлению перераспределения функций центра управления функционированием и периферией в зависимости от текущего состояния системы.
В последние годы объективные процессы государственного управления и динамика принятия решений являются таковыми, что ведомственная обособленность ИТКС становится тормозом развития страны и поэтому нуждается в коренном изменении. Одной из специфики таких гетерогенных сетевых инфраструктур отмечается то, что на сегодня они носят, как правило, межведомственный характер. При этом создание межведомственных ИТКС сопряжено с рядом особенностей, отличающих их от традиционных сетей связи. Это прежде всего [9-11]:
географическая рассредоточенность ресурсов сети и источников/получателей информации;
пульсирующий характер сетевого трафика;
разнородность элементов и применяемых сетевых технологий;
невозможность полного математического описания (построения полноценной математической модели) как мультисервисной ИТКС в целом, так и отдельных телекоммуникационных сетей в ее составе, при несомненной необходимости в этом;
необъяснимая «нетерпимости» к управлению, под которой понимается то, что гетерогенная сеть связи предназначена для сопряжения и передачи информации, а не для управления ею, т. е. функционирует независимо от системы управления;
случайность функционирования ИТКС, влекущая за собой трудности при проведении анализа ее состояния (мониторинга) и организации управления;
существенная нестационарность (дрейф основных характеристик), что вызывает разную реакцию сети на одну и туже ситуацию или управление в различные моменты времени.
Сложность и актуальность создания подсистем мониторинга для таких гетерогенных ИТКС сопряжено наряду с их особенностей еще и рядом ограничений, среди которых можно выделить следующие: наличие разнородных протоколов взаимодействия между узлами и периферийными сетевыми устройствами, постоянные трансформации сетевых топологий и структур сети, сопряжение сегментов маломощных и высокопроизводительных элементов сети, широкое применение носимых (мобильных) станций и устройств с низким энергопотреблением, слабой вычислительной мощностью, малым объемом памяти). Указанные особенности ИТКС позволяют вести речь о несовершенстве существующих систем контроля, ориентированных на применение в гомогенных сетевых структурах и необходимости поиска новых технологий и подходов к построению систем распределенного мониторинга функционального состояния современных гетерогенных сетей связи, включая методы интеллектуального мониторинга.
2. Обзор действующих систем сетевого мониторинга
Рассмотрим некоторые из существующих подсистем сетевого мониторинга. System Center Operations Manager (SCOM) [12] - система сквозного мониторинга (от Microsoft) и активного наблюдения за любыми сетевыми устройствами, поддерживающими протокол обмена информацией SNMP (до уровня порта), обнаружения виртуальных локальных вычислительных сетей (VLAN) и коммутаторов в них, слежения за их ТС. В последних версиях Microsoft SCOM появилась возможность наблюдения не только за устройствами под управлением операционных систем (ОС) семейства Windows, но и за гетерогенными средами, включая UNIX и Linux. SCOM предназначен в основном для организаций с числом сетевых устройств более 500 и числом серверов более 30. Для организаций меньшей структуры существует продукт System Center Essentials, включающий в себя часть функций SCOM и System Center Configuration Manager, но предназначенный для ИТКС малых и средних предприятий. В последнее десятилетие SCOM относят к сервису высокой доступности, благодаря отсутствию серверов управления. При сопряжении с несколькими серверами нагрузка балансируется, обеспечивая доступность. При этом на каждом из серверов работает служба конфигурации, а хранение данных реализовано не в памяти или ^ML-файлах, а в базе данных (БД). Microsoft также предоставляет возможность интеграции SCOM с System Center Service Manager, благодаря чему у пользователя есть возможность автоматического создания инцидентов на основе оповещений SCOM. Для слежения за виртуальными средами SCOM интегрируется с пакетом System Center Virtual Machine Manager, откуда получает информацию о частных облаках, виртуальных машинах и службах. К основным преимуществам SCOM можно отнести: высокую производительность и работоспособность приложений в среде Microsoft; обеспечение сквозного управления службами для сервисов центров обработки данных; унифицированный контроль для частных и общедоступных облачных сервисов; существенное повышение эффекта в управлении средой центра обработки данных; поддержку Windows PowerShell 2.0 с набором новых командлетов [12]. Но одним из главных достоинств SCOM является продвинутая визуализация всего собранного набора метрик и представление их в виде графиков и диаграмм. При этом визуализация доступна как в специальной консоли программы, так и через веб-интерфейс.
Однако SCOM имеет и ряд недостатков с точки зрения решения своего функционала [12]: она охватывает множество общих показателей системы, но непригодна для слежения за специфическими параметрами; до сих пор работа с ОС вне семейства Windows нестабильна; требует установки сервиса агента; существенная громоздкость и трудоёмкость настройки «под себя»: система больше подходит для мониторинга общего состояния и сбора основных сведений о глобальной структуре (множестве клиентских и серверных машин в домене). Также к недостатку системы можно отнести высокую стоимость данного программного продукта.
Zabbix [13] - свободно распространяемая система для проведения комплексного мониторинга сетевого оборудования, серверов и сервисов, состоящая из следующих частей:
Сервер мониторинга (ядро), выполняющий периодический опрос и сбор данных, их обработку и анализ, а также осуществляющий запуск скриптов для отправки оповещений. С его помощью можно удаленно контролировать сетевые сервисы. Он является хранилищем, в котором собраны конфигурационные, статистические и оперативные данные. Однако он не предназначен к размещению на сервере под управлением ОС семейства Windows и OpenBSD.
Прокси - осуществляет сбор данных о доступности и производительности от имени Zabbix-сервера. Полученные данные заносятся в буфер на локальном уровне и передаются Zabbix-серверу, которому принадлежит прокси-сервер. Zabbix прокси является эффективным решением для централизованного удаленного мониторинга филиалов и сетей, не имеющих локальных администраторов. Он может быть также применен для распределения нагрузки одного Zabbix-сервера. Причем прокси лишь собирает данные, т. е. на сервер ложится меньшая нагрузка (на его устройства ввода/вывода диска и на центральный процессор устройства - ЦПУ).
Агент - специальная программа, запускаемая на объектах мониторинга и представляющая данные серверу по локальным ресурсам и приложениям (статистика процессора, жесткие диски, память, и т. д.) на сетевых системах. Данные системы должны работать с запущенным Zabbix-агентом, однако мониторинг можно осуществляться не только с помощью него, но и по SNMP версий 1-3, путем запуска внешних скриптов, выдающих данные, и некоторые виды предопределенных встроенных проверок, таких как ping, запрос по протоколам http, ssh, ftp и пр., а так же измерение времени ответа этих сервисов. Zabbix-агенты являются достаточно эффективными из-за применения встроенных системных вызовов для сбора информации о статистике. Zabbix-агенты поддерживаются не только на *nix ОС, но и на AIX и Windows.
Web-iiHmepcpeùc, как средство визуального представления Zabbix, показано на рис. 1.
Zabbix Global View И"—€И к
< loa пол The mek so 1э> о
Humidity < »
Humidity 10 »
■ ^шт
^тш
4>
* JL—■
-LmJU ЬЛлНл
Рис. 1. Вариант карты сетей в Zabbix
С помощью Zabbix обычно осуществляют распределённый мониторинг до 1000 узлов, где конфигурация младших узлов в иерархии контролируется старшими. Также продукт включает централизованный мониторинг лог-файлов. При этом имеется возможность создавать вручную по шаблону карты сетей (рис. 1), выполнять запросы в различные БД, генерировать отчёты и выявлять тенденции изменения метрик, выполнять сценарии на основе результатов мониторинга, поддерживать интеллектуальный интерфейс управления платформами (IPMI).
Zabbix позволяет осуществлять: автоматическое обнаружение IP-адресов по диапазону, доступные сервисы и производить SNMP проверку; автоматический мониторинг обнаруженных сетевых устройств, а также автоматическое удаление отсутствующих хостов; распределение по шаблонам и группам в зависимости от возвращаемого результата и др.
Однако, в качестве недостатков стоит отметить: громоздкость сервиса, отсутствие полной документированности возможностей и необходимость установки агантов на все машины, а также сложность делегирования прав. Так, машина с сервисом зачастую управляется ОС семейства *nix, что делает трудоёмким взаимодействие с доменными пользователями и правами из Active Directory (Windows).
Nagios [14] - свободно распространяемое программное обеспечение (ПО) под мониторинг ИТКС, изначально разработанное для ОС на базе Linux, но эффективно работает под Sun Solaris, HPUX, FreeBSD, AIX. С помощью Nagios доступны: мониторинг безопасности ИТКС, комплексный мониторинг за ИТ-инфраструктурой, возможность оповещать администратора сети о получаемых данных при наблюдения, выявление проблем сразу после их возникновения, что сокращает время простоя и коммерческие потери. Также к достоинствам Nagios относят: мониторинг сетевых служб (SMTP, HTTP, SNMP, POP3, NNTP, ICMP); мониторинг состояния хостов в большинстве сетевых ОС (загрузка процессора, системные логи, использование диска);
поддержка удаленного мониторинга через шифрованные туннели SSH или SSL; возможность построения карт сетей, рис. 2;
Рис. 2. Вариант карты сетей в Nagios
простая архитектура плагинов (модулей расширений) позволяет разрабатывать свои собственные способы проверки служб, используя любой язык программирования по выбору; параллельный мониторинг служб;
возможность определения иерархии хостов сети с помощью «родительских» хостов, что позволяет обнаруживать и различать хосты, вышедшие из строя, или которые недоступны;
отправка оповещений при возникновении проблем со службой или хостом через модуль системы с помощью почты, sms, или иным способом, определяемым пользователем; осуществление автоматической ротации лог-файлов;
определение обработчика событий, возникающих с хостом, для разрешения проблем;
возможность создания распределенной системы мониторинга путем организации совместной работы нескольких систем мониторинга с целью повышения эффективности.
К недостаткам использования Nagios относят «общий» характер мониторинга и его «сетевая» направленность, а также проблемы взаимодействия с серверами под ОС Windows.
Cacti [15] - бесплатное приложение мониторинга, которое позволяет собирать статистику по метрикам за определённые временные интервалы с отображением их в графическом виде при использовании утилиты RRDtool, предназначенной для функционирования с круговыми базами данных (типа Round Robin Database) и использующейся для хранения информации об изменении одного или нескольких параметров за определенный промежуток времени. Стандартно шаблон сбора включает статистику по загрузке процессора, количеству запущенных процессов, использованию входящего/исходящего трафика, выделению оперативной памяти.
Cacti написан в инфраструктуре Apache-PHP-MySql с возможностью дописывания собственных агентов сбора данных и настройкой сбора и отображение данных мониторинга. При этом интерфейс отображения статистики метрик, собранной с сетевых устройств, представлен деревом, структура которого может задаваться самим пользователем. Как правило, статистика группируется по определенным критериям, причем один и тот же график может присутствовать в разных ветвях дерева или рассматриваться отдельно, с представлением временного горизонта: последний день, неделя, месяц и год (или иной временной промежуток). Имеется режим предпросмотра (просмотр заранее составленного набора графиков), рис. 3.
К достоинствам Cacti относят: высокую скорость развертывания при минимальном дополнительном кодировании, простоту и удобство интерфейса настройки просмотра отчетов.
Недостатками Cacti можно выделить: быстрое нарастание числа однотипных настроек при большом количестве сред и серверов; ограниченная производительность «неродных» JMX решений; невозможность инвентаризации при перераспределении ресурсов и модернизации.
Cacti позволяет для нескольких пользователей разграничить их права как на просмотр статистики, так и на управление системой. В тоже время Cacti позволяет строить графики только основных показателей производительности, в то время как попытки мониторинга нестандартных метрик значительно снижают производительность программного продукта.
Prometheus - свободно распространяемое ПО в интересах мониторинга сетевых устройств, серверов и сервисов, имеет встроенный базовый сетевой интерфейс (рис. 4), но чаще используется в связке с сервером визуализации данных Grafana (рис. 5) В ее состав входят:
Сервер мониторинга, который выполняет периодический опрос и сбор данных, а также их обработку и анализ. В случае обнаружения аномалии осуществляется обращение к интерфейсу оповещения оператора. С помощью сервера мониторинга также удаленно контролируются сетевые сервисы. Фактически сервер мониторинга является хранилищем, в котором собраны конфигурационные, статистические и оперативные данные по структуре сети и функциональному состоянию сетевых элементов. Имеет удобный интерфейс для доступа к данным в случае интеграции с другими сервисами (интерфейс оповещения, интерфейс отображения). В качестве недостатка стоит отметить, что он не предназначен к размещению на сервере под управлением операционной системы (ОС) семейства Windows.
Экспортер (exporter) - элемент сервера мониторинга, осуществляющий сбор данных о доступности и производительности объектов мониторинга. Существует большое множество экспортеров предназначенных как для сбора метрик из всех видов ОС, так и для сбора метрик из конкретных программных продуктов. При необходимости кастомизации может быть дописан самостоятельно или переписан для реализации отправки метрик элементу Pushgateway. Предоставляет web-интерфейс для доступа к метрикам объекта мониторинга, который опрашивается сервером мониторинга.
Pushgateway - специальное программное обеспечение, предназначенное для приема метрик от объекта мониторинга (агента), и представляющее их для сбора сервером мониторинга.
Alert manager - элемент сервера мониторинга, принимающий сигналы об аномалиях, и принимающий решение об использовании той или иной схемы оповещения ответственных лиц.
Рис. 4. Web-интерфейс системы мониторинга Prometheus
I Zimbra Collaboration: System Dashboard Relay2 -
ÎT P Б ft 0 QLastlhoLr Q С
1.4 week
Thrwds CPU weg; RAA« usage Swap uwtge
209 491
f \ 1.0% J
48% J 0%
egaöyws Total Emuls/R«... Total Emails/Sent Total Recipients Total Senders Forwarded Deferred
15 26 2 14 0
Рис. 5. Web-интерфейс сервера визуализации данных Grafana
Operation Support Systems (OSS) [16] - системы поддержки операций, построенные на базе протокола SNMP v. 1 и 2. Используются ведущими телекоммуникационными компаниями.
В рассматриваемой высокоуровневой архитектуре OSS Hewlett-Packard (HP) OpenView-NNM, OpenNMS, а также Huawei U2000LCT (рис. 6), центральным компонентом OSS является компонент диспетчеризации событий, совмещенный с настраиваемым классификатором событий, отказов и предупреждений (рекомендация M.3703 [17]). В случае OpenNMS таким компонентом является процесс-диспетчер событий EventD, OpenView - процесс PMD, U2000LCT - MRB. Сервисы OSS, подключаемые к диспетчеру событий, строятся по проекциям управления: отказами, конфигурацией, учетом, производительностью, безопасностью. Можно также выделить: компонент анализа структуры сети (ovtopmd в HP OpenView, discovery в OpenNMS, Discovery Service в U2000LCT), компоненты сбора данных и SNMP-трапов (OpenNMS - collectd и trapd, HPOView - snmpcollect и ovtrapd, U2000LCT - NEDataCollector), компоненты тестирования высокоуровневых сервисов (HP OpenView - ovcapsd, OpenNMS - capsd и poller), компонент работы с отказами (HP OpenView - ovalarm, OpenNMS - outaged).
В рассматриваемых OSS можно выделить 3-уровневую схему обработки [17]: данные (date), получаемые посредством измерений; события (events), получаемые после обработки процессами сбора первичных данных при сравнении метрики с пороговым значением; отказы (faults) и предупреждения (alarms), получаемые в результате логического вывода на множестве событий (events). В процессе обработки наблюдается сокращение объема данных при переходе от данных к событиям и от событий к отказам. Данная процедура перехода регламентируется классификатором событий, который строится на основе рекомендаций M.3703 [17].
NE Network
c)
Рис. 6. Высокоуровневые архитектуры (a) Hewlett-PackardNNM [16], (b) OpenNMS и (с) U2000LCT Huawei [16]. Интеграция за счет компонента-диспетчера классифицированных событий
События характеризуются помимо класса, временем генерации, идентификатором устройства-источника (диагностируемого), адресом, при обращении к которому было
сгенерировано событие, а также идентификатором программного компонента, его сгенерировавшего. Поля условно делят на часть, относящуюся к объекту управления -(устройству) и субъекту управления (агенту или компоненту), производящему операции над сетевым элементом в системе управления (СУ). В ходе обработки событие может передаваться по цепочке субъектов «устройство» - «агент» - «компонент сбора данных» - «компонент диагностики» [17], т. е. в процессе обработки событий субъекты выстраиваются в цепочки.
Еще одной из технологий все более настойчиво завоевывающей рынок IT-услуг для телеком-операторов и направленной на поддержание эксплуатационной надежности ИТКС и систем, является технология SRE (Site/System Reliability Engineering), рассматриваемая в виде набора инженерных практик, поддерживающих надежную и безотказную работу приложений в настоящем и будущем [20]. Данная технология ориентирована на способность обнаруживать аномальные ситуации и проблемы в работе ИТКС до того, как о них сообщат абоненты. Концепция SRE-технологии ориентирована на решение внутренних задач ИТКС с измерением времени безотказной работы ее сетевых элементов и сервисов, а также точного определения их доступности с учетом требований по масштабируемости и внезапным форс-мажорам. Технология SRE предполагает устранение организационных барьеров между функциями специалистов по разработке специального ПО и по информационно-технологическому обслуживанию ИТКС с учетом взаимной интеграции их рабочих процессов друг в друга, как при использовании единых индикаторов оценки (метрик) функциональной безопасности, так и общей ответственности всех участников предоставления информационно-телекоммуникационных услуг на этапах ЖЦ ИТКС.
К примеру, индикаторами доступности SRE являются следующие метрики времени: SLI (Service Level Indicator) - пропускные способности, задержки запросов, количество запросов в секунду, число сбоев на запрос. Данные метрики сначала агрегируются во времени и переводятся в среднее (или в %) по сравнению с порогом;
SLO (Service Level Objective) - целевые показатели метрик времени SLI за отчетный период времени: сутки, неделя, месяц, квартал, год и пр.
При этом важно отметить, что всякие простои сети грозят телеком-оператору убытками, в связи с чем необходимо предоставлять текущие значения метрик SRE в режиме on-line [20]:
RPO (Recovery Point Objective) - максимальный период времени, за который могут быть потеряны данные в результате инцидента (целевая временная точка восстановления ИТКС). Для телеком-оператора данный показатель необходимо минимизировать, и, в идеале, свести к нулю, RPO ^ 0. Такие инструменты, например, как автоматическая репликация данных в файловой системе снижает RPO, но для высокой доступности всего сервиса только этого недостаточно. Вычисление значения RPO относится к задачам DevOps- и SRE-инженеров;
RTO (Recovery Time Objective) - интервал времени, в течение которого ИТКС может быть недоступной в случае отказа или аварии (целевое время восстановления системы). Данное время необходимо для восстановления полного функционирования системы (сервиса) после возникновения аварии. SRE-инженеры должны организовать систему так, чтобы с использованием различных технологий отказоустойчивости и восстановления данных из резервных копий восстановить работоспособность системы на резервном сервере (оборудовании), площадке. Задачей оптимизации является минимизация значений RPO и RTO.
Внедрение систем мониторинга в корпоративных ИТКС особо важно при использовании в деятельности ИТ-подразделений сервисного подхода [19], когда все процессы поддержания функциональной надежности просматриваются с точки зрения предоставляемых подразделением ИТ-сервисов. Каждый бизнес-сервис корпоративной ИТКС по возможности интерпретируют как ИТ-сервис и описывают в системе мониторинга набором взаимосвязанных компонент ИТ-инфраструктуры, с определением уровня качества предоставления пользователю. Таким образом формируют Соглашение об уровне качества сервисов (SLA - Service Level Agreement), согласно которому система осуществляет сбор и хранение информации о качестве предоставления ИТ-сервисов. На базе накопленных метрик формируются отчеты за заданный
период времени, анализ которых помогает осуществлять: пересмотр уровня предоставления ИТ-сервисов, реорганизацию деятельности ИТ-подразделения, модернизацию ИТ-инфраструктуры.
Одной из задач технологии SRE является вычисление и поддержание заданного уровня доступа к сетевым элементам ИТКС с уточнением, какие именно ее показатели надежности должны быть под постоянным мониторингом, измерением и оценкой. Обычно в SLA-договоре между поставщиком телекоммуникационной услуги и ее получателем [20] при описании процесса управления доступом указывают следующие контрольные метрики оценки качества /T-сервиса: доступность (<availability); производительность (performance); надежность (reliability); сопровождаемое^ (maintainability); обслуживаемость (serviceability); безопасность (security) [21]. При этом в SLA-договоре устанавливается регламент взаимоотношений с потребителями услуг, в то время как SRE-технология необходима в первую очередь для внутреннего пользования и взаимодействия служб технической поддержки ИТКС. Поэтому требования, предписанные к качеству сервиса SRE-стандартом, как правило, выше указанных в SLA--договоре [22].
Для обеспечения эффективного взаимодействия между двумя ИТКС или двумя ее сегментами, как правило используют встроенные средства контроля и управления внутри ореола их действия (мониторинг OSS), а в точках демаркации - независимые измерительные средства контроля (мониторинг SLA). Таким образом, область применения систем мониторинга SLA и контроля качества сводится к совокупности точек демаркации. В иных точках нет потребности контролировать показатели сети независимыми средствами, поскольку встроенные системы управления и самодиагностики (фактически уровня NMS) решают эту задачу в полной мере. Это позволяет сформировать идею практического минимума системы управления: вместо развития глобальной системы по пути NMS-TMN-OSS и далее можно остановиться на ее первом шаге NMS - системе управления сетью (Network Management Systems); связь NMS друг с другом можно оформить в виде отдельных соглашений в SLA-договоре; дополнить полученную систему мониторинга системой мониторинга SLA и создать «лоскутное одеяло» в виде NMS, соединенных каналами информационного взаимодействия.
Такая конструкция существенно уступит информационным системам разного уровня управления, рассмотренным выше, но ее преимущество состоит в стоимости решения и времени развертывания. Предложенную систему управления можно развернуть в течение 2-3 недель без привлечения ресурсов внешних специалистов или системных интеграторов. При этом она будет достаточно разнообразной по составу сетевого оборудования и охвату географии ее размещения.
Территориальное ограничение применения систем мониторинга SLA в ИТКС не должно рассматриваться как уменьшение их значимости. Эти средства контроля применяются только в точках демаркации на границах подсетей, но в настоящее время количество таких точек растет с увеличением номенклатуры систем, сервисов, различного оборудования и др. При этом область квалиметрии и метрологии в точках демаркации, наоборот, расширяется по мере развития ИТ. Причем географическое ограничение сферы применения мониторинга SLA в системе позволит направить решение задач контроля качества, не вторгаясь в область систем управления OSS.
Выделяют три варианта точек демаркации [23] (рис. 7): оператор-оператор - точка при взаимодействии операторов; оператор-пользователь - точка подключения клиента; внутренние точки демаркации (между производителями, между структурными или регламентными подразделениями ИТКС). В этом случае для определения внутренних точек демаркации действует соглашение операционного уровня - OLA (Operational Level Agreement).
Для разрешения противоречий в точке демаркации, целесообразно использовать измерительные приборы (метрологические средства), т. к. встроенные средства диагностики в этих точках просто не работают. Для разрешения любых конфликтных ситуаций кроме технических средств необходимо еще нормирование этих параметров в рамках конвенции SLA.
SLA позволяет операторам, вне зависимости от действующих стандартов, договориться о параметрах взаимодействия. Один оператор может предложить транзит своего трафика через сеть другого, гарантируя при этом, что параметры передаваемого трафика не изменятся в границах пределов допуска. Например, транзитная сеть не имеет права увеличить количество
потерянных вызовов более чем на 5 % из-за своей деятельности и т. д. В том случае, если речь идет о новой технологии, для которой еще нет разработанных норм национальных стандартов, и присутствует правовой вакуум, SLA - единственный способ урегулирования взаимоотношений.
Точки демаркации
Рис. 7. Варианты точек демаркации [23]
При переходе от схемы работы «соответствие/несоответствие национальным стандартам» к SLA качество работы ИТКС в целом не ухудшается, а наоборот, повышается за счет более жестких требований. Гибкость в коммерческой и маркетинговой работе оператора становится необходимым слагаемым успеха. При этом современные системы мониторинга SLA отличаются своей нацеленностью на процессы. В отличие от большинства систем OSS/BSS, они всегда привязаны к особенностям информационного обмена. В основе работы системы мониторинга SLA лежит процесс разрешения конфликтов между поставщиком и потребителем услуг связи на основе управления сквозными процессами жизненного цикла услуги (PLM), рис. 8.
ЖЦ услуги
ЖЦ SLA
Рис. 8. Сквозной цикл предоставления услуги в соответствие со SLA-контрактом
Система осуществляет управление не отдельными услугами и метриками, а непосредственно контрактами SLA, что позволяет полностью учитывать в ней организационно-технические процедуры, связанные с управлением SLA (согласование SLA-договора, управление его изменениями и версиями, стандартами и политикой качества компании-оператора [24]). Все это делает системы мониторинга SLA весьма актуальными и значимыми, относя их к классу самых современных. Ориентированность на обеспечение процесса делает эти системы мониторинга результативными, что в сочетании с оперативностью развёртывания и технологичностью, усиливает эффективность данного класса систем на рынке ИТ России.
В отличии от систем OSS, системы мониторинга SLA позволяют быстро установить полный контроль состояния отдельного сегмента или всей сети в целом, поскольку они вообще не вмешиваются в оборудование (не позволяют управлять), а только контролируют состояние. При этом SLA позволяет учесть особенности и измерить любую сеть или ее отдельные сегменты.
Также важно отметить, что только режим реального времени для сетевого мониторинга поможет иметь телеком-оператору объективную картину метрик SRE для различных потребителей и их доступа к приложениям ИТКС. При этом, если в SLA-договоре оговариваются лишь отношения с внешним потребителем услуг, то SRE-метрики необходимы в большей степени самому оператору для выработки общей ответственности его технического персонала и SRE-инженеров за доступ к приложению (сервису) при функционировании ИТКС. Только постоянный мониторинг качественных параметров ИТКС в совокупности с общей системой управления, сбора и обработки измерительной информации (ИИ) реального времени дают объективную картину поддержания функциональной безопасности ИТКС в плане обеспечения доступа к их приложениям. Причем, все приложения условно могут быть разделены на две
основные группы: приложения, при неудовлетворительной работе которых может наступить уголовная ответственность пользователя (критически важные приложения); приложения, использование которых при низком качестве сетевых услуг несет финансовые и репутационные потери пользователя [25]. В этих случаях SKE-метрики могут лечь в основу судебных претензий к телеком-оператору, как поставщику услуг при включении в SLA--договор их качества.
Таким образом, сетевой мониторинг в SKE-метриках на сегодня является единственным объективным и надежным методом (технологией) оценки параметров эффективного функционирования ИТКС, что требует разработки и совершенствования SKE-инструментария.
Существует множество и других решений, работающих поверх общедоступных и частных облаков, которые отслеживают использование облачных ресурсов. Рассмотрим их:
Amazon CloudWatch [26] - это служба мониторинга и управления, отслеживающая виртуальные ресурсы пользователей, такие как экземпляры виртуальных машин Amazon EC2;
GMonE [27] - универсальный инструмент облачного мониторинга, предлагающий унифицированную таксономию, на основе чего определяется его многоуровневая архитектура.
PCMONS [28] - система мониторинга частного облака, которую можно адаптировать для использования поставщиками облачной телефонии для сбора и централизации информации.
IBM Tivoli Monitoring [29] и HP Open View [30] - другие системы мониторинга, направленные на оптимизацию производительности и доступности ИТ-инфраструктур за счет сосредоточения внимания на физических ресурсах;
MonPaaS [31] - платформа адаптивного мониторинга с открытым исходным кодом как услуги. Она объединяет Nagios [14] и OpenStack. MonPaas отслеживает физические и виртуальные ресурсы, а также обновляет любые изменения в физической или виртуальной инфраструктуре. Недостаток - потребляет дополнительные физические ресурсы.
3. Функции подсистемы мониторинга информационно-телекоммуникационной сети
Изначально на ИТКС функции мониторинга осуществляли администраторы, а информация о ТС систем в лучшем случае собиралась ими же в каких-либо неспециализированных программах (по причине их отсутствия), в худшем же вообще никак не накапливалась и не агрегировалась. Сведения об эксплуатируемом ОК были привязаны к практическому опыту работы конкретного специалиста с сетевой инфраструктурой и полностью терялись при его увольнении. В настоящее время появилось множество полу- и полностью автоматизированных систем мониторинга, анализирующих ТС сетевых элементов и отдельных сетей ИТКС, осуществляющих сбор ИИ по контролируемым параметрам и вероятностно-временным характеристикам во временные ряды, удобные для визуализации диаграммы, таблицы и графики, которые при необходимости (в случае аномалии) можно анализировать.
Для хранения получаемой в ходе мониторинга ИИ об ОК обычно используется конфигурационная БД под различными системами управления (СУБД), где информация об объекте контроля представлена, как набор конфигурационных единиц. Каждый сервер и каждое сетевое устройство, подвергаемое мониторингу, представляет собой некую единицу, ИИ о которой хранится в централизованной БД. Такое представление позволяет впоследствии интегрировать подсистему мониторинга с подсистемой визуализации в интересах системы поддержки принятия решений (СППР) на управление ИТКС (АСУС) и др. Ключевым элементом подсистемы сетевого мониторинга является сервер мониторинга, который с позиции области применения и наблюдаемого пространства может формироваться различно. Для мониторинга функционального состояния ИТКС предложен следующий вариант его построения, рис. 9.
Структурно сервер мониторинга [20] состоит из сборщика сырых данных, базы данных временных рядов и HTTP или SNMP сервера, функционирующих во взаимодействии с объектами мониторинга, подсистемой оповещения и подсистемой отображения. Сборщик сырых данных опрашивает объекты мониторинга по протоколу HTTP или SNMP и помещает собранные метрики в базу данных временных рядов. В базе данных хранятся метрики мониторинга за одним и тем же объектом на протяжении заданного времени наблюдений. Таким образом, возможно определение изменений значений параметров объекта во времени.
Рис. 9. Структурная схема сервера мониторинга ИТКС ОП и зависимых элементов (вариант)
Сервер мониторинга функционально предназначен для решения следующих задач: сбор ИИ о ТС элементов ИТКС (сетевых устройствах, функционирующем на них ПО и пр.); обработки, обобщения, хранения и отображения информации о состоянии элементов; изменения числа объектов мониторинга через графический интерфейс пользователя; графического и табличного отображения данных (в т. ч. отображения динамики изменения контролируемых параметров в течение установленного временного интервала);
оповещения должностных лиц (ДЛ) о возникновении критических событий в системе; автоматического или автоматизированного реагирования на возникновение критических событий (в соответствии с заранее настроенной логикой);
ведения системных журналов: изменения состояния сетевых элементов и их отдельных параметров, действий системы и действий пользователя, изменения параметров системы.
При выборе, разработке (построении) и внедрении систем мониторинга сначала необходимо определиться с объектами, которые будут подвергаться контролю, а также выбрать показатели качества и критерии эффективности (наступления критических событий), которые и определят количество оповещений при отказе (сбое), частоту сканирования и другие параметры, а также последствия для ИТКС. Обычно на больших сетевых инфраструктурах перед финальным внедрением подсистем мониторинга разворачивают тестовый сегмент сети в виде стенда, на котором возможно оценить целесообразность принятых решений при определении пороговых значений на контролируемые параметры, проанализировать «узкие места» в ИТКС.
К объектам мониторинга локальной вычислительной сети (ЛВС) можно отнести следующие программные и технические средства: автоматизированные рабочие места (АРМ) ДЛ; серверное оборудование; специализированное оборудование; сервер печати; систему единого времени; комплекс средств защиты информации. Для региональных и глобальных ИТКС перечень оборудования, соответственно будет значительно шире.
С точки зрения функциональной производительности ИТКС подсистема мониторинга должна осуществлять сбор следующих данных о вычислительных ресурсах объекта мониторинга: тактовая частота процессора; объем свободной оперативной памяти; свободный и использованный объем жесткого диска;
количество переданных, потерянных пакетов и коллизий сетевых интерфейсов; сбор сведений из системных журналов стороннего программного обеспечения; сбор сведений о запущенных процессах;
отправка данных в инициативном порядке и по запросу в активном и пассивном режимах; интерфейс управления встроенными командами и оборудованием по протоколу SSH. Посредством использования протокола SNMP сервер мониторинга через сборщик сырых данных осуществляет сбор следующих метрических данных сетевого устройства, обеспеченного поддержкой протокола обмена информацией SNMP:
статус порта: есть физическое подключение или нет, включен/выключен - программно; время последнего изменения настроек порта;
размер наибольшего пакета, который может быть отправлен с устройства; скорость порта;
список VLAN (для коммутаторов ЛВС); время работы устройства; описание устройства;
средняя загрузка процессора за 5 с, за 1 мин, за 5 мин; причина перезагрузки;
описание и состояние датчиков температуры; объем свободной оперативной памяти; список /P-адресов интерфейсов; таблица маршрутов для маршрутизаторов; входящий и исходящий трафик;
счетчик принятых и счетчик отправленных Unicast пакетов; счетчик принятых и счетчик отправленных Broadcast пакетов; счетчик принятых и счетчик отправленных Multicast пакетов;
счетчик принятых пакетов с ошибками и счетчик отправленных пакетов с ошибками; счетчик отброшенных пакетов, которые не содержали ошибок, но были отброшены, например, для освобождения буферного пространства.
Перечень собираемых метрических данных по различным ОК может отличаться. Собранные сборщиком сырых метрических данных направляются в сервер мониторинга для обработки информации и предоставления отчетов в виде таблиц и графиков с возможностью экспорта в форматы CSV, PDF, XML, PNG в интересах ДЛ. Характер метрических данных, необходимых к сбору, уточняется и устанавливается функциональным ДЛ (администратором). Среди основных функций подсистемы мониторинга ИТКС выделим следующие: слежение - основная функция, включающая в себя периодический сбор показателей с узлов оборудования, сервисов и т. п.;
хранение информации (дополнение к слежению). Осуществляется сбор информации по основным показателям каждого объекта мониторинга, для хранения обычно используются БД;
построение отчётов - осуществляется как на основе текущих данных слежения, так и по долговременно хранимой информации. Например, долговременный мониторинг нагрузки на сервер может предупредить, что потребляемые ресурсы всё время увеличиваются, значит необходимо увеличить доступные средства или перенести часть задач на другой сервер, выбор которого тоже можно осуществить на основе долговременного отчёта;
визуализация - отчёты в визуальном представлении в виде графиков, диаграмм и подсказок способствуют восприятию ИИ ДЛ, при этом возможен выбор для визуализации нескольких важных метрик, тогда как в отчётах будут представлены все показатели;
поиск «узких мест» - на основе анализа данных мониторинга возможно узнать, в каком месте инфраструктуры сети наиболее сильно снижаются общие показатели производительности; автоматизация сценариев - функция освобождает администратора от рутинных задач. Исходя из проведенного анализа функций существующих систем сетевого мониторинга определим основные функции сервера мониторинга перспективной подсистемы мониторинга ИТКС, к основным из которых можно отнести функции выборки, назначения, ping и SNMP:
1) Функция выборки. Цель функции выборки на сервере мониторинга состоит в получении последнего (актуального) описания сети и представления его в распределенную базу данных. Программное приложение компонента выборки необходимо запускать во время начальной загрузки подсистемы мониторинга. Его функция - записывать необходимые данные сетевой инфраструктуры в распределенную БД. Впоследствии его можно запускать периодически (например, ежечасно) или по запросу, когда сетевая инфраструктура претерпевает изменения (добавляются новые устройства или оборудование выводится из эксплуатации и т. д.).
2) Функция назначения. Целью данной функции является автоматическое назначение серверу мониторинга сетевых устройств для наблюдения. Программное приложение компонента назначения запускается на каждом сервере мониторинга и в его функционал входит поддержание актуальности сопоставления сетевых устройств серверам мониторинга по мере
локального обновления сетевой инфраструктуры. К примеру, если сетевое устройство не контролируется требуемым минимальным количеством серверов, один или несколько из них в итоге начинают наблюдать за доступными (обеспечивающие связность) сетевыми устройствами (динамически берут их на мониторинг), пока требование обеспечения минимальным числом серверов мониторинга каждого из них не будет выполнено. Это новое назначение немедленно обновляется для совместно используемого объекта распределенных данных и распространяется по всей сети, достигая остальных серверов мониторинга. Назначение между серверами мониторинга и сетевыми устройствами является динамическим и со временем меняется, поскольку новые сетевые устройства добавляются в сеть или удаляются из нее по мере того, как балансировка рабочей нагрузки на серверах мониторинга требует переназначения сетевых устройств с одного сервера на другой. При этом важно отметить, что компоненты назначения могут обнаруживать сбой сервера мониторинга, удаляя его из системы и принимая на себя его обязанности по мониторингу. Задача состоит в том, чтобы назначить каждое отдельное сетевое устройство, по крайней мере, как минимум 2 серверам мониторинга. Для этого серверы знают список узлов, за которыми нужно следить, и косвенно координируют друг с другом изменяемый объект данных, заданный соотношением сетевое устройство ^ сервер мониторинга, чтобы выполнить фактический мониторинг всех узлов. К примеру, каждый сервер мониторинга может начать случайный выбор узлов, за которыми еще не ведется наблюдение, и назначить их себе.
3) Функция проверки связи (ping). Целью функции проверки связи является выполнение проверки связи с сетевыми устройствами, назначенными серверу мониторинга, и записать результаты измерений в БД. Программное приложение, реализующее его, находится на каждом сервере мониторинга и заботится о фактическом зондировании сетевых устройств. ПО периодически проверяет назначенный список сетевых устройств для оценки их быстродействия, времени безотказной работы и расстояния до сети (с помощью времени приема-передачи пакетов ping). Собранные данные хранят в одном экземпляре распределенной БД. Их репликация между всеми экземплярами гарантирует, что новые данные автоматически реплицируются и распределяются по всем экземплярам БД, обеспечивая избыточность хранения.
4) Функция SNMP. Назначение данной функции состоит в выполнении SNMP запросов к сетевым устройствам, которым назначен сервер мониторинга, и запись собранных SNMP значений в БД. Программное приложение, реализующее его, запускается на каждом сервере мониторинга и заботится о фактических SNMP запросах к сетевым устройствам. Агрегированные данные хранятся в экземпляре распределенной БД. Репликация данных между всеми экземплярами гарантирует, что новые данные автоматически реплицируются и распределяются по всем экземплярам БД, обеспечивая выполнение технологии CRDT*.
Благодаря наличию средств для реализации всех этих функций администратору ИТКС нет необходимости проверять вручную состояние каждой составляющей системы. При этом возникающие проблемы решаются и отказы устраняются более оперативно, диагностика осуществляется многомерно и точно, возможно планирование расширения инфраструктуры.
4. Требования к перспективным системам сетевого мониторинга
Современные системы мониторинга, чтобы оставаться востребованными на рынке телекоммуникационных услуг проходят наряду с сетевыми устройствами и технологиями постоянный процесс совершенствования и модернизации. Это в свою очередь влияет на изменение требований к системам мониторинга в сторону их ужесточения. В настоящее время выделяют следующие требования к новым системам мониторинга, внедряемым на ИТКС [33]:
резервирование: каждое сетевое устройство должно контролироваться произвольным минимальным количеством серверов, например, превышающим один. Это означает, что серверы мониторинга должны проверять, какие сетевые устройства имеют назначенные серверы мониторинга, и, если их количество ниже минимального (менее двух), самостоятельно принимать решение стать сервером мониторинга для любого из этих устройств;
*CRDT (Conflict-Free Replicated Data Type) - типы данных, которые можно реплицировать на много узлов и обновлять параллельно без координации между узлами.
автоматическое распределение: система автоматически выполняет распределение между сетевыми устройствами и серверами мониторинга. При постоянной работе служба должна работать автономно без ручного вмешательства;
автоматическая реконфигурация: система должна иметь возможность автоматически обнаруживать неисправные серверы мониторинга (например, из-за сбоев сети или оборудования) и переназначать сетевые устройства функциональным серверам мониторинга. Этот процесс должен выполняться без ручного вмешательства;
репликация данных: собранные данные должны быть реплицированы и распределены по разным частям системы. В случае разделения сети или деградации БД данные по-прежнему должны быть доступны для извлечения службой мониторинга из других сегментов сети;
балансировка нагрузки: рабочая нагрузка мониторинга должна быть распределена по сети и активным серверам мониторинга, а не концентрироваться на нескольких устройствах.
Сравнение перспективных и существующих систем мониторинга приведено в табл. 1.
Таблица 1 - Сравнение перспективных и существующих систем сетевого мониторинга
Перспективные системы мониторинга Существующие системы мониторинга
Автоматическое назначение: на сервере мониторинга программный ком- Контролируемые сетевые устройства
понент назначения запускается без предварительного закрепления за сете- назначаются серверам мониторинга в
вым устройством. Он определяет себе ряд сетевых устройств для монито- автоматизированном режиме статически,
ринга в соответствии с настроенной мощностью сервера мониторинга не динамически - в процессе работы сети
Автоматическая реконфигурация: проверка назначенного компонента с Автоматическое обновление начального
настраиваемой определенной периодичностью, текущее сопоставление сопоставления сетевых устройств серве-
сервера мониторинга и сетевого устройства, а также реконфигурация назначения в соответствии с текущей ситуацией (например, удалить ру мониторинга отсутствует
неотвечающие серверы, увеличить количество серверов мониторинга для
сетевых устройств, которые не отслеживаются и пр.)
Избыточность: каждый программный компонент назначения пери- Каждое сетевое устройство контролиру-
одически проверяет, что каждое из сетевых устройств контролируется ется, как правило, только одним
несколькими серверами (т. е. серверы мониторинга проверяют, какие сервером мониторинга
сетевые устройства имеют меньше мониторов, и самостоятельно решают
стать монитором для любого из этих сетевых устройств)
Балансировка нагрузки между серверами: решения о самостоятельном Нет специального механизма для дости-
назначении учитывают мощность сервера мониторинга в зависимости от жения балансировки нагрузки между
конфигурации серверами мониторинга
Репликация данных: собранные данные реплицируются на распределенные экземпляры баз данных. В случае разделения сети или оттока Хранение данных мониторинга осуществляется на локальном сервере и теряется в
серверов мониторинга данные по-прежнему доступны на репликах случае сбоя сетевого раздела или сервера
5. Общие принципы организации и функционирования подсистем мониторинга ИТКС
На основе системного анализа процессов мониторинга ИТКС, проведенного выше, сформулируем общие принципы построения и функционирования систем сетевого мониторинга.
Для решения задач поддержания в постоянной готовности к применению и обеспечения эффективной технической эксплуатации сетевых элементов и ИТКС в целом, необходимо применение современной организационно-технической идеологии и подходов к построению систем сетевого мониторинга, основанной на использовании перспективных интеллектуальных, информационных, сетевых и измерительных технологий. При этом функционал подсистемы мониторинга территориально распределенной ИТКС должен включать комплекс мероприятий, проводимых, с целью информационного обеспечения СППР (по управлению связью - АСУС) и поддержания сетевых элементов в исправном (работоспособном) состоянии. Исходя из этого, основными принципами построения подсистемы мониторинга ИТКС являются:
принцип эволюционного развития, предоставляющий возможность подсистеме мониторинга соответствовать постоянно совершенствующимся (эволюционирующим) ИТКС, с учетом их топологической и пространственно-временной неоднородности;
единства организационно-технических, алгоритмических и программно-технических решений, направленных на разработку высокоэффективных программных приложений по
поддержанию и восстановлению качества функционирования ИТКС и ее сетевых элементов на основе данных мониторинга;
интеллектуализации процессов мониторинга ИТКС, базирующийся на применении перспективных ИТ, развивающихся на стыке искусственного интеллекта и распределенной обработки больших данных (измерительной информации сетевых элементов);
гибкости архитектуры подсистемы мониторинга на основе методологии открытых систем, обеспечивающей возможность реконфигурации системы контроля в условиях деградации и восстановления сетевой инфраструктуры, а также наращивания функций мониторинга ИТКС и ее сетевых элементов - многоуровневость, иерархическое построение.
Но основными архитектурными принципами проектирования современных подсистем мониторинга распределенных гетерогенных ИТКС являются распределение и децентрализация для повышения устойчивости и надежности подконтрольной сети. Остановимся на них подробно.
Механизм децентрализованного распределения успешно обеспечивает установку минимального количества серверов мониторинга на одно контролируемое сетевое устройство, что удовлетворяет заданным системным требованиям. Учитывая, что на распределенной ИТКС обстановка по связи постоянно изменяется из-за динамичной смены состояния каналов связи и надежности сетевых элементов для повышения отказоустойчивости подсистемы мониторинга предлагается каждому сетевому элементу сопоставлять несколько серверов мониторинга, находящихся на границах подсетей (сегментов сети). При этом принцип распределенности и децентрализации предполагает размещение на сети нескольких реплик серверов мониторинга.
Проведенный выше анализ особенностей развития современных ИТКС и этапов их совершенствования показал экспоненциальный рост структур [32], порождаемый увеличением географической распределенности, а также возрастанием уровня разнородности сегментов сети, что в свою очередь накладывает особенности на подходы и методы построения структур их подсистем мониторинга. Причем, большая степень размерности контролируемого пространства, с учетом многоуровневой структуры и гетерогенности ИТКС, совокупности наблюдаемых метрик на сетевых элементах, представляющих из себя большие данные (Big Datа), предполагает разработку модели системы, способной учесть вышеизложенные требования, предъявляемые к перспективным системам мониторинга. Основным из них является децентрализация инфраструктуры мониторинга функционального состояния распределенных сетевых ресурсов .
6. Структура перспективной подсистемы мониторинга ИТКС общего пользования
Структуру подсистемы мониторинга такой распределенной гетерогенной ИТКС можно смоделировать как неполным двунаправленным графом G = (N, E), где N - это набор узлов, составляющих сеть, а E - набор связей (беспроводных или оптоволоконных), соединяющих корреспондирующие пары узлов. Изолированные узлы сети (т. е. без связей с другими узлами) отбрасываются. При этом для построения подсистемы мониторинга рассмотрим два типа узлов: серверы мониторинга M (M G N) и сетевые устройства, подлежащие мониторингу D (D с N). Связи характеризуются заданной пропускной способностью Vj, V (i, j) G E и задержкой Ту, V (i, j) G E, в то время как каждый i-й узел имеет конкретное качество мониторинга (при рассмотрении мониторинга как услуги) QoSi, V i G N, полученное из реальных измерений на сети. Для развертывания подсистемы мониторинга на сети можно разместить не более Mmax = к реплик сервера мониторинга. Сервер мониторинга может быть развернут в сетевом узле, только если этот узел имеет QoSi выше минимального порога, QoSi > QoSmin [23]. Ссылка узла будет использоваться, если его полоса пропускания выше или равна заданному порогу. При сопоставлении сетевых устройств и серверов мониторинга учтем следующее ограничения (оно м. б. установлено и иным, в зависимости от важности выполняемых функций, включения вКВИ):
SS" mi ^ 2■ (!)
Поскольку основными принципами проектирования подсистемы мониторинга являются распределение и децентрализация для повышения устойчивости и надежности, то необходимо использовать распределенные структуры БД для поддержки децентрализованной координации
серверов мониторинга. С этой целью серверы должны хранить распределенное сопоставление серверов мониторинга и сетевых устройств, используемое для динамического взятия (и снятия) устройств на мониторинг. Такое динамическое распределение должно модифицироваться одновременно любым из участвующих серверов для поддержки выполнения условия (1). Чтобы обеспечить это, используем технологию СЕПТ и делегируем синхронизацию данных, а также их согласованность, на базовый уровень хранения (БД), который обеспечивает определенные свойства (например, гарантированную конечную согласованность при репликации данных).
Распределенное сопоставление на ИТКС серверов мониторинга и сетевых устройств приведено на рис. 10 и в табл. 2. В данной сетевой инфраструктуре группа маршрутизаторов П1 - П12 представляют фактические сетевые устройства, соединенные между собой оптоволоконными либо радиоканалами и образующие ячеистую сеть. Вокруг них показаны сервера мониторинга М1 - М6, взаимодействующие друг с другом для обмена информацией (репликации мониторинговой информации) и координации своих действий.
Децентрализованное управление серверами мониторинга и распределенной базой данных
Рис. 10. Децентрализованная система сетевого мониторинга (вариант на примере Минтранса России)
Таблица 2 - Распределенное сопоставление серверов мониторинга и сетевых устройств (по рис. 10)
Сетевое устройство Сервер мониторинга Сетевое устройство Сервер мониторинга Сетевое устройство Сервер мониторинга
D1 М1, М2 D5 М1, М33 D9 М4, М6
D2 М1, М2 D6 М2, М33 D10 М5, М6
D3 М1, М2 D7 М3, М4 D11 М4, М6
D4 М1, М3 D8 М3, М4 D12 М5, М6
Структура, приведенная на рис. 10 может соответствовать межведомственной ИТКС, осуществляющей мониторинг состояния единого дифференциального сервиса Глобальной навигационной спутниковой системы (ГНСС) ГЛОНАС/GPS/GALILEO при его использовании в Министерстве транспорта РФ в интересах сегментов ИТКС Федеральных Агентств Росавтодора, Росжелдора, Росавиации, Росморречфлота и Ространснадзора для управления движением поездов (ДП), автомобильным транспортом (АПК «Умный город»), систем связи и радиотехнического обеспечения при организации системы управления воздушным движением (ВД), систем автоматизированного управления (АСУ) движением судов (ДС) на внутренних водных путях (ВВП) и в морских акваториях. При этом сервера мониторинга размещаются как на телекоммуникационных структурах автомобильных и железных дорог, районов воздушного движения и районных администраций бассейнов рек (озер), до единых центров управления (ЕЦУ) ДП, ЕЦУ ВД, ЕЦУ ДС, так и в ситуационном центре (СЦ) Минтранса РФ.
Заключение
В статье представлен обзор действующих технологий и систем сетевого мониторинга ИТКС ОП. Дана характеристика таким из них как SCOM, Zabbix, Nagios, Cacti, OSS, SRE, SLA, Amazon CloudWatch, IBM Tivoli Monitoring, GMonE, PCMONS и др. Их обзор показал, что в межведомственных распределенных ИТКС вычислительные мощности на границах сети растут, а облачные вычисления, традиционно обеспечиваемые предоставлением инфраструктурных услуг в крупных ЦОД, перемещаются на границу сети. Причем рост доступности периферийных инфраструктур также подталкивает приложения, которые обычно работают в удаленных ЦОДах, к работе на распределенных периферийных устройствах. В этих условиях значительно меняются общие подходы и методы построения перспективных подсистем мониторинга сети.
В работе определены функции подсистемы сетевого мониторинга ИТКС и сервера мониторинга, как ключевого ее элемента. Предложен вариант структуры сервера мониторинга ИТКС и зависимых подсистем. Рассмотрены назначаемые объекты мониторинга, а также перечень собираемых с них метрических данных с точки зрения функциональной производительности ИТКС. Сформулированы общие требования к перспективным системам сетевого мониторинга, а также общие принципы организации и функционирования подсистем мониторинга ИТКС. При этом для повышения устойчивости и надежности подконтрольной сети ключевым архитектурным принципом проектирования современных подсистем мониторинга распределенных гетерогенных ИТКС определен принцип распределенности и децентрализации.
На основе предложенных принципов построена структура перспективной подсистемы мониторинга ИТКС ОП на примере Минтранса РФ. В ней в соответствии с требованиями, изложенными в статье, каждому сетевому элементу назначают два и более сервера мониторинга, каждый из которых географически разнесен, имеет разную емкость и доступные ресурсы, некоторые из них отвечают за мониторинг большего количества сетевых устройств, чем другие.
Важным элементом заявленной структуры подсистемы мониторинга является предлагаемое сопоставление сетевых элементов серверам мониторинга, разработанное как совместно используемый объект распределенных данных, который не управляется централизованно, а динамически обновляется децентрализованно и автономно самими серверами мониторинга с делегированием синхронизации и согласованности данных на базовый уровень хранения данных, который обеспечивает определенные свойства (например, гарантированную конечную согласованность при репликации данных). В конструкции системы мониторинга применяется децентрализованная координация между серверами мониторинга. Каждый из них считывает мгновенное состояние корреспондирующих серверов мониторинга для управления своими индивидуальными действиями (настройками) по отношению к сетевым элементам (какие устройства контролировать). Это решение затем запускает фактическую операцию мониторинга, которая проводится, как и в традиционной централизованной системе.
Алгоритм децентрализованного распределения успешно обеспечивает установку минимального количества серверов мониторинга (М > 2) на одно сетевое устройство, что удовлетворяет установленным системным требованиям. Такая устойчивая и децентрализованная архитектура может заложить основу для других приложений в области облачных пограничных вычислений, которым важно координировать распределенные и согласованные общие данные. При этом БД используется CRDT-технология, реализующая структуры распределенных данных.
Литература
1. Инфокоммуникационные сети: энциклопедия. Кн. 4. Гетерогенные сети связи: принципы построения, методы синтеза, эффективность, цена, качество / П. А. Будко, И. А. Кулешов, В. И. Курносов, В. И. Мирошников; под ред. проф. В. И. Мирошникова. - М.: Наука, 2020. - 683 с.
2. ITU-T: General principles and general reference model for Next Generation Networks. Recommendation Y.2011 - Geneva, 2004. - URL: https://www.itu.int/rec/T-REC-Y.2011-200410-I/en (дата обращения: 30.04.2021).
3. Tangari G., Tuncer D., Charalambides M., Pavlou G. Decentralized Monitoring for Large-Scale Software-Defined Networks. IFIP/IEEE Symposium on Integrated Network and Service Management (IM).
Department of Electronic and Electrical Engineering, University College London, 2017, UK (дата обращения: 30.04.2021).
4. Будко П. А. Управление ресурсами информационно-телекоммуникационных систем. Методы оптимизации: Монография. - СПб.: ВАС, 2012. - 512 с.
5. Винограденко А. М., Меженов А. В., Будко Н. П. К вопросу обоснования понятийного аппарата неразрушающего экспресс-контроля технического состояния оборудования системы связи и радиотехнического обеспечения аэродрома // Наукоемкие технологии в космических исследованиях Земли. 2019. Т. 11. № 6. С. 30-44. doi: 10.24411/2409-5419-2018-10293.
6. Клюев В. В., Соснин Ф. Р., Ковалев А. В. Неразрушающий контроль и диагностика: справочник / Под общ. ред. В. В. Клюева. М.: Машиностроение, 2005. 656 с.
7. ГОСТ 27.002-2015 Надежность в технике. Термины и определения. М.: Издательство стандартов. 2016. 23 с.
8. Федеральный закон от 07.07.2003 № 126-ФЗ (ред. От 09.03.2021) «О связи».
9. Будко П. А., Рисман О. В. Многоуровневый синтез информационно-телекоммуникационных систем. Математические модели и методы оптимизации: Монография. - СПб.: ВАС, 2011. - 476 с.
10. Легков К. Е., Бабошин В. А., Нестеренко О. Е. Модели и методы управления современными мультисервисными сетями связи // Техника средств связи. 2018. № 2 (142). С. 181-182.
11. Легков К. Е. Процедуры и временные характеристики оперативного управления трафиком в транспортной сети специального назначения пакетной коммутации // T-Comm: Телекоммуникации и транспорт. 2012. Т. 6. С. 42-46.
12. TechNet Magazine: System Center Operations Manager 2012: Простота расширения возможностей мониторинга. - URL: http://technet.microsoft.com (дата обращения 03.05.2021).
13. Vacche A. D., Lee S. K. Zabbix Mastering. Packt Publ., 2013. 358 р. (дата обращения 24.04.2021).
14. Nagios: отраслевой стандарт мониторинга ИТ-инфраструктуры. - URL: https://www.nagios.org/, 2019. (дата обращения 03.05.2021).
15. XGU [Электронный ресурс]: Cacti. - URL: http://xgu.ru (дата обращения 03.05.2021).
16. Васильев Н. В., Раков И. В., Забродин О. В., Куликов Д. В. Аналитические и синтетические OSS: анализ подходов и методов // Техника средств связи. 2019. № 1 (145). С. 82-94.
17. Recommendation ITU-T M.3703 Common management services. Alarm management. Protocol neutral requirements and analysis - URL: http://www.itu/int/rec/T-REC - M.3703 - 201006-1 (дата обращения 03.05.2021).
18. Бломмерс Дж. OpenView Network Node Manager: Разработка и реализация корпоративного решения. - М.: Интернет Ун-т Информационных Технологий, 2005. - 264 с.
19. https://www.osp.ru/itsm/2012/09/13017362.html (дата обращения 21.03.2021).
20. Аллакин В. В. Формирование сервера мониторинга функциональной безопасности информационно-телекоммуникационной сети общего пользования на основе оценки SRE-метрик // Техника средств связи. 2021. № 1 (153). С. 77-85.
21. https://olontsev.ru/2016/04/rpo and rto/ (дата обращения 21.03.2021).
22. https://ru.wikipedia.org/wiki/Соглашение_об_уровне_услуг (дата обращения 21.03.2021).
23. Бакланов И. Г. Оправдание OSS. - М.: Издательские решения, 2016. 131 с.
24. Будко П. А., Линец Г. И., Мухин А. В., Фомин Л. А. Эффективность, цена и качество информационно-телекоммуникационных систем. Методы оптимизации: Монография. - СПб.: ВАС, 2011. - 420 с.
25. Сторожук М. Использование систем мониторинга сетей для обеспечения работы критически важных приложений // Первая миля. 2021. № 1. С. 40-44.
26. Amazon, «Amazon CloudWatch». - URL: https: //aws.amazon.com/cloudwatch (дата обращения 03.05.2021).
27. Montes H., Sanchez A., Memishi B., Perez M. S., Antonio G. Gmone: an integrated approach to cloud monitoring. Future Generation Computer Systems, 2013, vol. 29, no. 8, pp. 2026-2040 (дата обращения 03.05.2021).
28. 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.
29. IBM, «IBM Tivoli Monitoring». - URL: https://www.ibm.com/support/knowledgecenter/en/ SS3JRN_7.2.0/com.ibm.itm.doc/itm_install06.htm (дата обращения 03.05.2021).
30. HP BTO OpenView. - URL: http://www.hp.com/hpinfo/newsroom/press_kits/2010/HPSoftware UniverseBarcelona2010/HP_Applications_ Portfolio_brochure.pdf, 2019 (дата обращения 03.05.2021).
31. 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, pp. 65-78.
32. Каретников В. В., Будко Н. П., Аллакин В. В. Синтез подсистемы интеллектуального мониторинга информационно-телекоммуникационной сети в интересах информационного обеспечения ситуационного центра Минтранса России // Вестник Астраханского государственного технического университета. Серия: управление, вычислительная техника и информатика. 2021. № 2. С. 64-81.
33. Centelles R., Selimi M., Freitag F., Navarro L. REDEMON: Resilient Decentralized Monitoring System for Edge Infrastructures. Conference proceedings. 2020 20th IEEE/ACM International Symposium on Cluster. Cloud and Internet Computing (CCGRID), Melbourne, Australia, 2020, рp. 91-100.
References
1. Budko P. A., Kuleshov I. A., Kurnosov V. I., Miroshnikov V. I. Infokommunikatsionnyye setm Entsiklopediya. Kniga 4. Geterogennyye seti svyazi. Printsipy postroyeniya. Metody sinteza. Effektivnost. Tsena. Kachestvo. Monografija [Infocommunication networks: an encyclopedia. Book 4. Heterogeneous communication networks. Principles of construction. Methods of synthesis. Efficiency. Price. Quality. Monography]. Moscow, Nauka Publ., 2020. 683 p. (in Russian).
2. ITU-T: General principles and general reference model for Next Generation Networks. Recommendation Y.2011 - Geneva, 2004. -URL: https://www.itu.int/rec/T-REC-Y.2011-200410-I/en (accessed 30 April 2021).
3. Tangari G., Tuncer D., Charalambides M., Pavlou G. Decentralized Monitoring for Large-Scale Software-Defined Networks. IFIP/IEEE Symposium on Integrated Network and Service Management (IM). Department of Electronic and Electrical Engineering, University College London, UK. 2017 (accessed 30.04.2021).
4. Budko P. A. Upravleniye resursami informatsionno-telekommunikatsionnykh sistem. Metody optimizatsii [Resource management of information and telecommunications systems. Optimization methods] St. Petersburg, Military Academy of Communications Publ., 2012. 512 p. (in Russian).
5. Vinogradenko A. M., Mezhenov A. V., Budko N. P. K voprosu obosnovaniya ponyatiynogo apparata nerazrushayushchego ekspress-kontrolya tekhnicheskogo sostoyaniya oborudovaniya sistemy svyazi i radiotekhnicheskogo obespecheniya aerodrome [To the question of substantiation of the conceptual apparatus nondestructive express control of the technical condition equipment of the communication system and aerodrome radio engineering support]. H&ES Research, 2019, v. 11, no. 6, pp. 30-44. doi: 10.24411/2409-5419-2018-10293 (in Russian).
6. Klyuev V. V., Sosnin F. R., Kovalev A.V. Nerazrushayuschiy kontrol i diagnostika: spravochnik [Non-destructive testing and diagnostics: reference]. Under the general editorship of V. V. Klyuev. Moscow, Mechanical Engineering, 2003. 656 p. (in Russian).
7. State Standard 27.002-2015. Reliability in technology. Terms and definitions. Moscow, Standartov Publ., 2016. 23 p. (in Russian).
8. The Federal Law of the Russian Federation of July 07, 2003 no. 126-FZ "About communication". (in Russian).
9. Budko P. A., Risman O. V. Mnogourovnevyy sintez informatsionno-telekommunikatsionnykh sistem. Matematicheskiye modeli i metody optimizatsii: Monografiya [Multilevel synthesis of information and telecommunications systems. Mathematical models and optimization methods: A monograph]. Saint-Petersburg. Military Academy of Communications, 2011, 476 p. (in Russian).
10. Legkov K. E., Baboshin V. A., Nesterenko O. E. Modeli i metody upravleniya sovremennymi multiservisnymi setyami svyazi [Models and methods of management of the modern multiservice networks]. Means of Communication Equipment. 2018, no. 2 (142), pp. 181-182. (in Russian).
11. Legkov K. E. Protsedury i vremennyye kharakteristiki operativnogo upravleniya trafikom v transportnoy seti spetsialnogo naznacheniya paketnoy kommutatsii [Procedures and temporal characteristics of the operational management of traffic in the transport network of the special purpose packet switching]. T-Comm - Telecommunications and Transport. 2012, vol. 6, pp. 42-46. (in Russian).
12. TechNet Magazine: System Center Operations Manager 2012: Ease of expanding monitoring capabilities. - URL: http://technet.microsoft.com (accessed 03 May 2021).
13. Vacche A. D., Lee S. K. Zabbix Mastering. Packt Publ. Ltd, 2013. 358 р. (accessed 24 April 2021).
14. Nagios: Industry Standard for Monitoring IT Infrastructure. URL: https://www.nagios.org/2019. (accessed 03 May 2021).
15. XGU: Cacti. URL: http://xgu.ru (accessed 03 May 2021).
16. Vasiliev N. V., Rakov I. V., Zabrodin O. V., Kulikov D. V. Analytical and synthetic OSS: analysis of approaches and methods [Analytical and synthetic OSS: analysis of approaches and methods] Means of Communication Equipment. 2019, no. 1 (145), pp. 82-94. (in Russian).
17. Recommendation ITU-T M.3703 Common management services. Alarm management. Protocol neutral requirements and analysis. - URL: http://www.itu/int/rec/T-REC-M.3703-201006-1 (accessed 03 May 2021).
18. Blommers J. OpenView Network Node Manager: Designing and Implementing an Enterprise Solution. Мoscow, "INTUIT.RU", 2005. 264 p. (in Russian).
19. https://www.osp.ru/itsm/2012/09/13017362.html (accessed 21 Mart 2021).
20. Allakin V. V. Formation of a server for monitoring the functional security of a public information and telecommunications network based on the evaluation of SRE metrics. Means of Communication Equipment. 2021, no. 1 (151), pp. 77-85. (in Russian).
21. https://olontsev.ru/2016/04/rpo and rto (accessed 21 Mart 2021).
22. https://ru.wikipedia.org/wiki/ Service Level Convention (accessed 21 Mart 2021).
23. Baklanov I. G. Justification of OSS. Moscow. Publishing solutions Publ., 2016. 131 p. (in Russian).
24. Budko P. A., Linets G. I., Mukhin A.V., Fomin L. A. Effektivnost', tsena i kachestvo informatsionno-telekommunikatsionnykh sistem. Metody optimizatsii: Monografiya [Efficiency, price and quality of information and telecommunications systems. Optimization methods: Monograph]. Saint-Petersburg, Military Academy of Communications Publ., 2011, 420 p.
25. Storozhuk M. Ispol'zovaniye sistem monitoringa setey dlya obespecheniya raboty kriticheski vazhnykh prilozheniy [Using Network Monitoring Systems to Keep the Critical Applications Running]. Last Mile, 2021, no 1, pp. 40-44. (in Russian).
26. Amazon, «Amazon CloudWatch», https: //aws.amazon.com/cloudwatch (accessed 03 May 2021).
27. Montes H., Sanchez A., Memishi B., Perez M. S., Antonio G. Gmone: an integrated approach to cloud monitoring. Future Generation Computer Systems, 2013, vol. 29, no. 8, pp. 2026-2040. (accessed 03.05.2021).
28. 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, pp. 130-137.
98. IBM, «IBM Tivoli Monitoring», https://www.ibm.com/support/knowledgecenter/en/SS3JRN7.2.0 /com.ibm.itm.doc/itminstall06.htm (accessed 03 May 2021).
30. HP, «HP BTO OpenView», http://www.hp.com/hpinfo/newsroom/ press_kits / 2010 / HPSoftware UniverseBarcelona2010 / HP_Applications_ Portfolio_brochure.pdf, 2019 (accessed 03 May 2021).
31. 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, pp. 65-78.
32. Karetnikov V. V., Budko N. P., Allakin V. V. Synthesis of subsystem of intelligent monitoring of information and telecommunication network of departmental situational center. Vestnik of Astrakhan State Technical University. Series: Management, Computer Science and Informatics. 2021;3:64-81. (In Russian.) DOI: 10.24143/2072-9502-2021-3-64-81.
33. Centelles R., Selimi M., Freitag F., Navarro L. REDEMON: Resilient Decentralized Monitoring System for Edge Infrastructures. Conference proceedings. 2020 20th IEEE/ACM International Symposium on Cluster, Cloud and Internet Computing (CCGRID), Melbourne, Australia 2020, p. 91-100.
Статья поступила 22 апреля 2021 г.
Информация об авторе
Будко Никита Павлович - Соискатель ученой степени кандидата технических наук. Независимый специалист. E-mail: budko62@mail.ru. Адрес: 194064, г. Санкт-Петербург, ул. Бутлерова, 9, корп. 1, кв. 252.
General principles of functioning and requirements for the construction of structures of promising monitoring systems for distributed information and telecommunications networks
N.P. Budko
Annotation. Task statement: based on the analysis of existing technologies and existing monitoring systems of public information and telecommunications networks, to develop general requirements and approaches to the construction ofpromising network monitoring systems. The purpose of the work: to review the existing monitoring systems and develop general principles and requirements for the construction of a new generation of network monitoring systems. Methods used: methods of system analysis, structural synthesis, network monitoring technologies Site/System Reliability Engineering, Operation Support Systems. The novelty of the work: to increase the stability and reliability of the controlled network, the key architectural principle of
