CC BY
21H. В. Васильев
Кандидат технических наук начальник сектора ПАО «Интелтех»
И. В. Раков
Кандидат технических наук, доцент, заместитель директора НТЦ ПАО «Интелтех»
О. В. Забродин
Инженер-программист ПАО «Интелтех»
Д. В. Куликов
Инженер-программист ПАО «Интелтех»
АНАЛИТИЧЕСКИЕ И СИНТЕТИЧЕСКИЕ OSS: АНАЛИЗ ПОДХОДОВ И МЕТОДОВ
АННОТАЦИЯ. В работе производится попытка анализа архитектуры некоторых современных систем поддержки операций OSS («синтетические») с выделением нового класса «аналитических» систем OSS, обладающего рядом особенностей, позволяющих использовать их в случае, когда применение протокола SNMP затруднено.
КЛЮЧЕВЫЕ СЛОВА: управление, сети, топология, моделирование, томография, расстояние редактирования.
Введение
Представленные в настоящее время телекоммуникационные системы поддержки операций {Operation Support Systems OSS) [1] построены на основе протокола SNMP первой и второй версий. Требования к безопасности проектируемых решений часто запрещают использование специализированных протоколов управления. В таком случае мониторинг сводится к простому анализу доступности устройств и каналов, что совершенно недостаточно для принятия решения о качестве обслуживания в сети. Открытым остается также вопрос разработки надежных методов идентификации состояния сети «в целом», как объекта управления. В работе производится попытка анализа архитектуры некоторых современных OSS («синтетические») с выделением нового класса «аналитических» систем OSS, обладающего рядом особенностей, позволяющих использовать их в случае, когда применение SNMP затруднено.
1. Обзор современных OSS
Информационная архитектура современных систем поддержки операций исходит из реализации процесса мониторинга, включающего следующие этапы:
определение {discovery) структуры сети (анализ топологии);
измерение {collect) параметров сетевых элементов и групп элементов;
оценка состояния сети с точки зрения возможностей исполнения требуемых функций, а также определение рекомендаций к устранению возникших нарушений в работе.
После первоначального развертывания OSS производится анализ структуры сети, т. е. запись в базу данных системы требуемой информации о топологических отношениях между сетевыми элементами — устройствами, каналами, интерфейсами. На последующих этапах решаются непосредственно задачи управления на основе получаемых в результате измерений первичных данных.
Проанализируем высокоуровневую архитектуру OSS HP OpenView-NNM [2], OpenNMS [3], а также Huawei U2000LCT. Во всех рассматриваемых на рис. 1 архитектурах OSS, центральным компонентом является компонент диспетчеризации событий, совмещенный с настраиваемым классификатором
событий, отказов и предупреждений [4]. В случае OpenNMS таким компонентом является процесс-диспетчер событий EventD, OpenView - процесс PMD, U2000LCT — MRB. Сервисы OSS, подключаемые к диспетчеру событий, строятся [5] по проекциям управления: отказами, конфигурацией, учетом, про-
b)
Рис. 1. Высокоуровневые архитектуры (a) HP NNM, (b) OpenNMS и (с) U2000LCT Huawei. Интеграция за счет компонента-диспетчера классифицированных событий
изводительностью, безопасностью. Можно также выделить: компонент анализа структуры сети (ovtopmd в HPOpenView, discovery в OpenNMS, Discovery Service в U2000LCT), компоненты сбора данных и SNMP-трапов {OpenNMS — collectd и trapd, HPOView — snmp-collect и ovtrapd, U2000LCT — NEDataCollector), компоненты тестирования высокоуровневых сервисов (HP OpenView — ovcapsd, OpenNMS — capsd и poller), компонент работы с отказами (HP OpenView — ovalarm, OpenNMS — outaged).
В рассматриваемых OSS четко выделяется 3-уровневая схема обработки:
данные, получаемые посредством измерений;
события (events), получаемые после обработки процессами сбора первичных данных при сравнении измерения с пороговым значением;
отказы {faults) и предупреждения (alarms), получаемые в результате логического вывода на множестве событий (events).
В процессе обработки наблюдается уменьшение объема данных при переходе от данных к событиям и от событий к отказам. Данная процедура перехода регламентируется классификатором событий, который строится на основе рекомендаций М.3703 [4]. Формат передаваемых диспетчером событий в упрощенном виде показан на рис. 2.
класс время идентификатор /р-адрес идентификатор
устроиства-источника устройства компонента-источника
объект
\
субъект
Рис. 2. Упрощенный формат события OpenNMS. Поля, относящиеся клогике коммутации событий
Помимо класса, события характеризуются временем генерации, идентификатором устройства-источника (диагностируемого), адресом, при обращении к которому было сгенерировано событие, а также идентификатором программного компонента, сгенерировавшего событие. Поля условно можно разделить на две части. Первая часть относится к объекту управления — устройству. Вторая часть к субъекту управления — агенту или компоненте, которая в системе управления производит операции над сетевым элементом. В процессе обработки событие может передаваться по цепочке (рис. 3) субъектов «устройство» — «агент» — «компонент сбора данных» — «компонент диагностики», т. е. в процессе обработки событий субъекты выстраиваются в цепочки.
Рассмотрим более подробно работу компонента диспетчеризации [6]. Каждый из компонентов, входящих в OSS может быть «подписан» на получение событий определенного класса. При возникновении в сети событий, подписчики-обработчики извещаются компонентом диспетчеризации. Механизм подписки процессов реализуется посредством таблицы «ключ» — «значение», в которой в
качестве ключа выступает класс событий, а в качестве значений список компонентов-подписчиков.
При поступлении в компонент диспетчеризации событие обрабатывается цепочкой процессоров:
процессор классификации и расширения описания события за счет подгрузки дополнительных данных из классификаторов;
процессор, осуществляющий запись события в базу данных;
процессор рассылки, осуществляющий на основе таблицы «класс события» — «подписчик» широковещательную рассылку события процессам-подписчикам.
Формат события имеет ориентацию на модель протокола управления SNMP. Для выполнения таких измерений достаточно лишь одного ¿^-адреса устройства и пароля доступа к устройству. Измерение на канале-маршруте, характеризуемом парой адресов, или сети, характеризуемой группой адресов, в подобный формат не укладывается и требует расширения.
В качестве процессов-подписчиков событий выступают компоненты ситуационного анализа, формирующие на основе множеств событий
Субъекты управления Vуровня
Компонент отображения
Субъекты управления IVуровня
Компонент корреляции событий и предупреждений
Субъекты управления III уровня
Среда событий Классификатор события
события
Компонент генерации предупреждений
события
события
\L
ïz.
Диспетчер событий
Классификация события
Журнализация события
Рассылка события
события
Ту
события
Компонент приёма извещений
Компонент сбора данных
Субъекты управления IIуровня
Извещения
~Данные
Субъекты управления I уровня
Агент Агент Агент Агент
управления управления управления управления
Объекты управления
Сетевой Сетевой Сетевой Сетевой 1— элемент__> I— элемент___1 I— элемент___1 1— элемент _—1
Рис. 3. Обобщенная архитектура OSSHPNNM, OpenNMSrn U2000LCTHuawei
Рис. 4. Интерфейс пользователя на основе карт и символов
отказы (faults) и предупреждения (alarms), компоненты визуализации и компонент корреляции событий (correlated).
Механизмы корреляции событий [7] определяют первопричины сетевых проблем, отсеивая мощный поток вторичных сообщений об ошибках, что существенно уменьшает сроки поиска и устранения неисправностей. Он также автоматически обрабатывает сотни второстепенных сообщений, сводя их к нескольким действительно полезным сообщениям о работе сети.
Другим компонентом — получателем событий является компонент визуализации. В настоящее время используется [8], [9], отображающие информацию о состоянии сети при помощи карт и символов (рис. 4). Карты и суб-карты системы управления относятся между собой как атлас и его страницы. Аналогично атласу, карты, отображаемые системой управления, обеспечивают представление как сети связи целиком, так и отдельных частей данной сети. Карта представляет собой совокупность взаимосвязанных объектов, символов и субкарт, обеспечивающих графическое и иерархическое представление сети связи в целом и отдельных частей данной сети. Карты обеспечивают отображение территориальных сетей связи, а также различных видов представления одной сети связи, необходимых оператору при решении данных задач. Например, некоторая сеть, характеризуемая своей картой (например, с топологией «шина»), отображается в виде
знака-символа на карте более высокого уровня. При этом цвет знака характеризует совокупное состояние символов на соответствующей символу суб-карте. Схема вычисления состояния задается оператором при помощи правил агрегации и фильтрации событий.
2. Объектное моделирование сети
Рассмотрим подходы, используемые в OSS для моделирования устройств и сетей:
Common Information Model (CIM) — общая информационная модель [10], представляет собой объектно-ориентированную информационную модель (рис. 5), описываемую при помощи языка UML. Протокольные точки в модели CIM представляют собой интерфейсы доступа к некоторому сервису (например, сервису передачи (Forwarding) на физическом (Interface), канальном (LAN), сетевом (IP)) или сервису маршрутизации (Routing) — точка BGP. Протокольные точки образуют вертикальную иерархию при помощи отношения BindsTo (отношение использования).
Протокольные точки могут объединяться в коллекции.
Существует два основных типа коллекций: сегменты (коллекции) взаимодействия (ConnectivivtySegment) —моделирование подсетей (на сетевом уровне), сегментов (на канальном), линков (на физическом);
Рис. 5. С/М-модельдвухвзаимодействующих /Р-устройств
коллекции точек устройств (DeviceCollec-tion) — моделирование структуры устройства на некотором уровне модели OSI (физическом, канальном, сетевом, транспортном и т. д.).
Топология сети в модели CIM представляет собой совокупность коллекций определенного уровня OSI.
Текущая UML схема (версия 2.48.0) сетевой модели состоит из 40 страниц, общий же объем CIM более 200 страниц. Высокая выразительность в сочетании с активным развитие CIM является отрицательным свойством данного подхода. Версии моделей очень сильно различаются и, фактически, совместимы только на уровне базовых классов. А за последние годы в инфраструктурную часть CIM было внесено много существенных изменений, несовместимых с предыдущими версиями.
Generalized MultiProtocol Label Switching (GMPLS) [11] представляет собой протокол и модели, разработанные комитетом IETF для обеспечения функционирования технологии MPLS через гетерогенные сети. Данный протокол предлагает единый подход для управления многослойными сетями связи. GMPLS представляет собой развитие архитектуры MPLS, предусматривающее полное разделение плоскостей сигнализации и данных разных уровней.
Он обеспечивает бесшовное взаимное соединение и конвергенцию существующих и новых сетей, даже если исходящий и входящий узлы принадлежат к разнородным сетям. GMPLS опирается на модели адресации и маршрутизации протокола IP. Таким образом, для идентификации интерфейсов используется не только адресация IPv4 и/или IPv6, но и традиционные (распределенные) протоколы маршрутизации стека TCP/IP. Предусмотренная в GMPLS плоскость сигнализации позволяет управлять сетью за счет автоматизации установления, поддержания и разрыва соединений, управления сетевыми ресурсами и обеспечения качества услуг QoSв соответствии с требованиями новых приложений. Если на плоскости сигнализации в GMPLS применяется технология IP, то плоскость данных, или трафика, включает целый набор его типов, в том числе TDM, пакетный и др. Протокол GMPLS — открытый протокол, объединяющий все модификации MPLS и соответствующие протоколы. В силу своей открытости он способен вобрать в себя и те модификации MPLS, которые находятся в стадии стандартизации или могут появиться в будущем. По идеологии GMPLS сетевые устройства используют протокол OSPF-TE для обмена данными со своими соседями об изменении топологии.
Устройства, получившие пакет OSPF-TE в свою очередь ретранслируют его прочим участникам, и, таким образом, в конце процесса все устройства в сети обладают актуальной информацией о топологии сети. IETFb настоящее время пытается расширить GMPLS применительно к междоменной среде. Топологические данные в OS-PF-TE рассылаются посредством Х54-пакетов. Данные, содержащихся в пакете закодированы в компактном байт-формате, с использованием специально определенных (TLV) контейнеров. Этот формат прост в обработке, легко обрабатываем в сетевых устройствах, но трудно экспортируем во внешние приложения.
G.805 модель, предложенная комитетом ITU-T для описания сетей, построенных на основе нескольких технологий [6]. Эта модель служит для теоретических целей и используется комитетом в документах (TMN)\
Network Markup Language — Working Group (NML — WG). Рабочей группой по сетевым
измерениям (Network Measurement Work Group) был разработан способ представления топологии сети с ориентацией на измерения. Модель оперирует двумя основными сущностями: канал и узел. Это позволяет легко обмениваться данными топологии с внешними приложениями. Дальнейшим развитием модели NMWG служит модель cNIS, которая служит для описания многослойных гетерогенных сетей.
Несмотря на выявленные отличия в подходах и протоколах, можно выделить некоторые общие черты. Методологически — наличие в процессе сбора данных и актуализации модели двух основных участников: собственно объекта управления (канала, интерфейса, сети) и субъекта управления (рис. 6). Субъект управления — программный агент, связанный с актуализируемой моделью протоколом управления. Иными словами, OSS «видит» сетевой элемент сквозь «призму» субъекта управления.
Рис. 6. Субъект-объектная модель в виде «Сущность-связь»
Конфигурация агента управления для разных типов объектов управления может быть различной. Для получения сведений о интерфейсе устройства достаточно сообщить агенту номер интерфейса, а для получения сведений о канале надо указать пару идентификаторов интерфейсов, характеризующих начало и конец. Таким образом, при конфигурировании системы сбора данных мы должны в свою очередь учитывать конфигурацию объекта управления.
Подсистемы сбора данных взаимодействует с сетевыми устройствами агентов, предоставляющих данные о состоянии отдельных компонентов (интерфейсов, каналов, подсетей). Каждый агент в IP-сети, как программный процесс, характеризуется парой (TP-адрес, номер порта). Поэтому, с точки зрения подсистемы сбора данных, сеть управления может быть представлена множеством /Р-интерфейсов, которые могут принадлежать различным узлам и сетям. На узлах размещаются агенты управления. На одном /Р-интерфейсе может размещаться несколько агентов, предоставляющих информацию о состоянии разных элементов устройства и формируемых каналов.
Анализ описанных выше моделей позволяет заключить, что средства управления OSS оперируют двумя основными типами сущностей: интерфейс (точечный объект) и соединение (точка-точка), характеризуемый последовательностью точек. Характеристики указанных объектов получают при помощи внешних измерительных средств (тестеров каналов и соединений), а также встроенных агентов тестирования маршрутов и соединений (представленных, например, SNMP или NetConf-агентами).
Можно также выделить производные групповые сущности:
«Путь» — последовательность соединений;
«Сеть» (сегмент) — совокупность интерфейсов, соединений, путей;
«Узел» — совокупность интерфейсов.
Таким образом, основными объектами измерения выступают: «Сетевой Элемент», «Интерфейс», «Соединение» («Линк»), «Путь», «Сеть», «Узел». На основании этого можно использовать следующую модель объекта управления:
«Объект управления» — базовая сущность, служащая для моделирования отношений между объектом и субъектом управления;
«Узел» — предназначен для моделирования сетевого элемента. Для данного типа сущностей характерны измерения, классифицируемые как «точечные»;
«Интерфейс» — абстракция интерфейсов различных уровней модели OSI {IP, Ethernet, El, SDH— оконечная точка и пр.). Для данного типа сущностей характерны точечный измерения;
«Простое соединение» («Линк») — абстракция канального и сетевого соединений. Для данного типа сущностей характерны измерения, классифицируемые как «точка-точка»;
«Путь» — абстракция сложного соединения, состоящего из последовательности отдельных «Линков». Служит для моделирования /Р-маршрутов, MPZ^-туннелей, 5Д#-трактов;
«Сеть» — метаобъект — совокупность интерфейсов, соединений, путей, узлов.
3. Аналитические и синтетические OSS
В условиях измерения количества тактов процессора, маршрутизатора, числа принятых интерфейсом пакетов непосредственно на устройстве для принятия решения о состоянии сетей и подсетей необходимо знать не только состояние отдельных сетевых элементов, но и групп элементов в виде маршрутов и сетей различного уровня. Рассмотренные выше системы предполагают, что состояние сетевых элементов первично, в то время как состояние сетей и маршрутов может быть вычислено на основе математических моделей, описывающих поведения сетей и маршрутов. Таким образом, мы осуществляем синтез состояния групп элементов. Но первичные данные могут быть получены не только от отдельных коммутаторов и маршрутизаторов, но и от маршрутов, соединений, подсетей. В этом случае для определения состояния устройств мы должны произвести обратное разложение, анализ, от маршрутов и подсетей до сетевых элементов.
В соответствии с этим OSS можно разделить на два типа: синтетические системы (рис. 7 о) и аналитические системы (рис. 7 b).
Класс аналитических систем представлен пока не так широко. Здесь следует указать проект PerfSONAR и инициативу CNIS, направленные на развертывание сервис-ориентированной инфраструктуры мониторинга каналов, маршрутов и направлений.
Станция управления SNMp
IP телефон
Коммутатор Маршрутизатор
N
ATM
«оммутагтор
Маршрутизатор
Многоуровневый коммутатор с NetFlow
АТС
b)
Агент IXIA
NMWG
Станция управления
IP телефон
Коммутатор Маршрутизатор
Многоуровневый коммутатор с NetFlow
АТС
Рис. 7. Сбор данных в синтетических (а) и аналитических (b) OSS
Обобщенно, схема обработки данных в аналитических OSSимеет следующий вид:
1) Этап сбора и предобработки;
2) Этап обработки. Предварительное определение состояния, генерация событий о состоянии связанного с измеренными первичными данными маршрута или канала;
3) Этап предварительной диагностики. Уточнение события, определение значений незаполненных полей события при помощи классификаторов;
4) Логический вывод на множестве событий. Выявление первопричины возникшего отказа на основе упрощенной топологии сети, удаление избыточных событий, диагностика на основе организационной иерархии.
Различия с синтетическими системами возникают в методах сбора, а также в реализации высокоуровневых методов обработки событий. При этом для аналитических систем логического вывода заключается в обратном поиске — от совокупности следствий-событий к событиям-причинам, для синтетических систем — прямой поиск, заключающийся в вычисление состояния групп сетевых элементов по состоянию отдельных сетевых элементов.
Однако, если для выполнения прямого логического вывода необходимо привлечение продукционных моделей, весьма сложных для квалификации администратора сети, то для обратного вывода эти модели достаточно просты и могут быть созданы автоматически.
4. Информационная архитектура аналитических OSS
Имеющийся в настоящее время практический опыт реализации и внедрения систем [12, 13] позволяет обрисовать контуры промышленной аналитической OSS.
Если в синтетических OSS интегрированное представление о сети формируется через совокупность измеряемых состояний и параметров сетевых элементов, то для создания представления о сети в аналитических OSS объектами мониторинга являются каналы и маршруты переда-чиданных.
Такие измерения в аналитических OSS всегда выполняются в паре агентов «отправитель» — «получатель». Следовательно, необходимо покрыть сеть множеством агентов измерения, которые всегда смогут оценить состояние маршрута от узла, на котором находится агент до любого другого узла с агентом. С агентом узла взаимодействует узловая OSS, которая выполняет анализ состояния связанных с узлом каналов и маршрутов. Взаимодействие узловых OSS и сетевой OSS осуществляется при помощи событий-предупреждений (alarms по терминологии Х.373), содержащих код (класс) проблемы, возникшей в маршруте, проходящем через узел канала, а также идентификатор объекта модели, описанной выше.
Пример схемы измерения приведен на рисунке 8.
Для реализации такого подхода при проектировании и разработке аналитических OSS предлагается 3-х уровневая программная архитектура, элементами которой являются: агенты измерения, узловые системы управления (СУ) и сетевая СУ.
Узловые СУ осуществляют сбор данных, их предобработку и диагностику неисправностей каналов и маршрутов, связывающих узел с соседними узлами. В составе узловой системы (рис. 9) можно выделить следующие компоненты:
1) Агенты контроля. Для обеспечения функционирования, необходим следующий базовый набор агентов анализа соединений:
агент контроля структуры соединений, определяющий при каждом обращении к нему компонента сбора данных последовательность промежуточных узлов между двумя оконечными узлами соединения, передаваемыми в качестве параметров;
агент контроля ширины полосы пропускания соединений, обеспечивающий измерение ширины полосы пропускания (Мбит/с);
агент контроля односторонней задержки соединения.
2) Компонент сбора данных, ответственный за обработку измерений характеристик каналов и маршрутов. Главным элементом этого модуля является планировщик проверок каналов и маршрутов. Компонент должен осуществлять выявление ошибочных измерений, связанных с технологической перекоммутацией соединений (ошибки маршрутизации), а также за классификацию состояния канала и генерацию событий, соответствующих этому состоянию. Состояние сети и канала не может быть определено по единственному измеренному вектору параметров. Невозможно рассматривать канал изолированно, без учета влияния других компонентов системы. Если в канале наблюдается тенденция к деградации, то она будет заметна при проведении серии измерений с небольшим интервалом. Простое сравнение с порогом, используемое в синтетических системах для анализа состояния элементов устройств (процессоров, памяти, интерфейсов) здесь не применимо, поскольку не ясно по какому измерению (по счету) осуществлять принятие решения. Применение функций агрегации среднего может «скрыть» важные для принятия решения измерения в серии. В то же время не ясно как агрегация
АРМ управления сетью
J^sJ Видеоконференцсвязь Электронная почта Телефон
Электронная почта
Рис. 8. Схема измерений в аналитической OSS
Видеоконференцсвязь
К сетевой OSS
A
Субъекты управления IVуровня
Компонент корреляции событий и предупреждений
--Ä-
Компонент генерации предупреждений
Субъекты управления III уровня
события
11
события
Среда событий
Классификатор события
Диспетчер событий
Классификация события
Журнализация Рассылка события
события
7\
события
Модель динамики маршрута Компонент сбора данных
Субъекты управления II уровня
Субъекты управления I уровня Объекты управления
Узловой агент управления
1Г
Л
1С
11
Маршрут 1
Маршрут 2
Маршрут 3
Рис. 9. Структура узловой OSS
по максимуму в серии измерений приводит к изменениям чувствительности процесса принятия решений к выбросам.
В работе [14] показано, что в процессе принятия решения о состоянии канала используется вектор измеренных односторонних задержек. При этом принятие решения основано на статистическом моделировании характера поведения односторонних задержек в каждом из состояний. Определение текущего состояния маршрута осуществляется на основе байесовской классификации измеренного вектора односторонних задержек по классификатору, в котором каждый класс представлен своим распределением вероятностей с устанавливаемым набором параметров.
В случае, когда произошла смена состояния, происходит генерация события смены состояния с последующей его записью в базу данных.
Формируемые на узловых СУ предупреждения и отказы поступают по трактам управления к сетевой СУ.
В составе сетевой СУ помимо компоненты — «Сетевой диспетчер событий», обеспечивающий обработку и пересылку предупреж-
дений от диспетчеров событий узловых СУ к средствам обработки должны входить компоненты томографической реконструкции и анализа состояния сети.
На основе проведенного обзора предлагается включить в OSS дополнительно следующие компоненты:
компонент томографической реконструкции сети, реализующий известные алгоритмы сетевой томографии [12, 15]. Компонент осуществляет определение состояния базовых элементов (устройств и каналов) на основе событий о состоянии составных объектов (маршрутов передачи данных). Основную идею сетевой томографии продемонстрируем на примере. Допустим, что проводится измерение на сети (рис. 10 а). В составе сети 4 узла: А, В, С, D. Для того, чтобы установить состояние каждого из соединений А-В, В-Сж C-D достаточно выполнить 2 измерения А-С и A-D. В случае, если выйдет из строя А-В оба маршрута А-С и A-D будут недоступны для передачи. Если выйдет из строя В-С, то А-С будет недоступен, а A-D будет функционировать, и наоборот, при выходе из строя B-D будет функционировать лишь маршрут А-С.
А
В -D
C F
Рис. 10. Пример структур сетей, состояние каналов которых может быть реконструировано средствами сетевой томографии
Аналогично, выполнив 4 измерения А-Е, A-F, D-Еж D-Fна структуре (рис. 10 b), можно охарактеризовать каждый из пяти каналов. Таким образом, для установления факта выхода из строя соединения необходимо, чтобы через данное соединение проходило 2 маршрута, по которым проводится измерение, и чтобы эти 2 измерения были отрицательны (т. е. передача по данному маршруту была в данный момент невозможна).
Компонент томографической реконструкции функционирует по временным тактам. Анализируются только события, полученные за время между предыдущим тактом и новым. Для уменьшения объема передаваемых данных между узловыми OSSh сетевой OSS должны передаваться только события об отказах и восстановлениях. В случае, если на момент принятия решения (между двумя тактами) событие для некоторого маршрута отсутствует, то считается, что маршрут не изменил состояние с момента предыдущего такта.
Компонент анализа состояния сети осуществляет оценку динамики сети как единого целого. Результатом работы также являются события-предупреждения, передаваемые диспетчеру события и отображаемые графическим интерфейсом пользователя. В основе логики работы компонента может быть использован подход, который был впервые рассмотрен в работе Хорста Бунке [16]. Данный подход вводит понятие графа измерений, представляющего собой граф сети, раскрашенный состояниями каналов и сетевых элементов. Для диагностики аномального поведения сети предложен базовый перечень метрик-сверток (расстояний
между графами) d ^g, g¡ j, которые являются
обобщением расстояния редактирования строк
(расстояние Левенштейна). Для каждого «отличия» одного графа от другого (смена состояния сетевого элемента, канала, вставка узла, вставка дуги, удаление узла, удаление дуги) вводится стоимость. После каждого измерения вычисляется суммарная стоимость изменений графа топологии. В случае, если вычисленное превышает установленный порог, генерируется событие-предупреждение о изменениях в сети.
Другая группа методов использует понятие «среднего» графа (графа-медианы) по множеству топологий сети. В этом случае после каждого измерений производится анализ «степени близости» вычисленного графа определенному ранее среднему.
Согласно определению [15], граф-медиана g последовательности G = {g1,g2,...,gn} называется такой граф, суммарное расстояние редактирования которого до каждого члена последовательности минимально:
n
g = argnùn ^d (g, gi ) (1)
gGU i=i
Если изобразить графы топологии сети в виде точек пространства, средние графы будут центрами тяжести. Усреднение последовательности графов позволяет исключить влияние случайных флуктуаций, что подобно действию суммирующего фильтра (размытия) сигнала. Поэтому данный метод более предпочтителен для выявления долговременных тенденций в поведении сети. В приведенной работе [14] подход был использован для оценки динамики взаимодействий между элементами корпоративной информационной системы. В качестве источника измерений выступал сенсор NetFlow, установленный на граничном маршрутизаторе. Полученные результаты позволяют определять «стандартный» режим функционирования сети и «нестандартный», вызванный необходимостью решения непредусмотренных проектом сети задач. Подход позволяет также спрогнозировать в какой момент сеть в результате увеличения числа абонентов перестанет обеспечивать обслуживание.
Заключение
Существующие в настоящее время синтетические системы наряду с перечисленными преимуществами, обусловленными широким распространением протокола SNMP обладают рядом недостатков. При это нередки случаи, ког-
да сеть полностью выполняет требуемые функции по связи пользователей и сервисов, но диагностируемое OSS состояние из-за отсутствия адекватных моделей агрегации состояния «элемент» — «авария» и наоборот.
В предложенных аналитических системах такая ситуация невозможна. Измерение происходит от конечного потребителя-абонента. Ошибка будет генерироваться только в случае если сеть не выполняет свою главную функцию — связь между абонентами.
Помимо этого, аналитические системы обладают следующими свойствами:
изначально меньший объем первичной информации сетевых измерений (полоса пропускания, задержка, вариация задержки). При этом первые ширина полосы пропускания и задержка являются параметрами, определяемыми на стадии планирования сети;
отсутствие необходимости разработки заказных SNMP агентов. Однако при этом необходимо покрыть сеть множеством агентов сетевых измерений (генераторов/приемников тестового трафика). В промежутке между генератором и приемником могут находиться любые устройства, в том числе неуправляемые. Их состояние может быть реконструировано при помощи методов сетевой томографии при условии, что устройство входит в несколько маршрутов;
отсутствие необходимости использования искусственных внешних моделей, создание которых требует достаточно высокой квалификации от персонала. В случае аналитических систем можно воспользоваться сетевой томографией, основанной на классических методах линейной алгебры и граф-аналитическими методами.
ЛИТЕРАТУРЫ
1. Бакланов И. Г. Оправдание OSS / И. Г. Бакланов. — Екатеринбург: Издательские решения, 2016. — 134 с.
2. Kenneth R., Sheers HP OpenView Event Correlation Services // Hewlett-Packard Journal. 1996. Article 4. C. 1—10. [Электронный ресурс]. — Режим доступа: http://www.hpl.hp.com/hpjournal/96oct/oct96a4.pdf, свободный. — Загл. с экрана.
3. HacheyG. InstantOpenNMS Starter/G. Hachey. — Birmingham: Packt Publishing, 2013.— 60 p.
4. M.3703: Common management services — Alarm management — Protocol neutral requirements and analysis [Электронный ресурс]. — Режим доступа: https://www.itu.int/rec/T-REC-M.3703-201006-I, свободный. — Загл. с экрана.
5. Гребешков А. Ю. Стандарты и технологии управления сетями связи / А. Ю. Гребешков. — М.: «Эко-Трендз», 2003,- 288 с.
6. Зителло Т. HP OpenView — настольная книга системного администратора / Т. Зителло, Д. Вильяме, П. Вебер. - М.: ЭКОМ, 2006,- 616 с.
7. Hasan M. A conceptual framework for network management event correlation and filtering systems / M. Hasan, B. Sugla, R. Viswanathan. // Integrated Network Management VI.Distributed Management for the Networked Millennium. Proceedings of the Sixth IFIP/IEEE International Symposium on Integrated Network Management.— 1999. - Cat. NO.99EX302. - Pp. 233-246.
8. Бломмерс Дж. OpenView Network Node Manager. Разработка и реализация корпоративного решения / Дж. Бломмерс. — М.: Интернет-Университет Инфор-мационныхТехнологий (ИНТУИТ), 2005.— 264 с.
9. Ghetie I. Networks and Systems Management: Platforms Analysis and Evaluation / I. Ghetie. — Berlin: Springer Science & Business Media, 1997.— 512 p.
10. Hobbs C. A Practical Approach to WBEM/CIM Management / C. Hobbs. — Boca Raton: CRC Press, 2004.— 344 p.
11. Nadeau T., Farrel A. Generalized Multiprotocol Label Switching [Электронный ресурс]. — Режим доступа: https://tools.ietf.org/html/rfc4802, свободный. — Загл. с экрана.
12. Castro R. Network Tomography: Recent Developments / R. Castro, и др. // Statistical Science.— 2004. - Vol. 19, No. 3. - Pp. 499-517.
13. Kanuparthy P. Pythia: Diagnosing Performance Problems in Wide Area Providers / P. Kanuparthy, C. Dov-rolis. II The Proceedings of USENIX АТС '14: 2014 USE-NIX Annual Technical Conference.— 2014. — Vol. 12, No. 5. - Pp. 371-382.
14. Плотников В. С. Автоматизированный программный комплекс оценки качества в телекоммуникационной сети / В. С. Плотников, Н. В. Васильев, А. И. Яшин. II Вопросы радиоэлектроники. — 2014. — № 1, Т. 3. - С. 35-45.
15. Vardi Y. Network Tomography: Estimating Source-Destination Traffic Intensities from Link Data / Y. Vardi. II Journal of the American Statistical Association.- 1996. — Vol. 91, No. 433. - P. 365-377.
16. Bunke H. A Graph-Theoretic Approach to Enterprise Network Dynamics / H. Bunke. и др. — Basel: Birkhäuser, 2007,- 226 p.
