Реализация систем управления

Производители телекоммуникационного оборудования зачастую помимо задачи производства своего оборудования занимаются разработкой системы управления этим оборудованием. Эта система управления посредством опросов сетевых элементов и промежуточных звеньев сети должна предоставлять информацию системам поддержки текущих операций для технических и нетехнических подразделений, а также системам поддержки бизнеса. Таким образом, можно выделить две основные группы, отвечающие за управление (в широком смысле, относительно английского термина management): системы управления сетью и системы поддержки операций и бизнеса.

Системы NMS

Системы управления сетью - Network Management System (NMS) являются системами, реализующими уровень NML модели TMN. Физически NMS представляет собой комбинацию программного обеспечения с аппаратной частью, на которой это программное обеспечение имеет серверную часть. Обычно данные системы построены по принципу “агент-менеджер”. такое взаимодействие аналогично общепринятому взаимодействие типа “клиент-серевер” и условно проиллюстрировано на рисунке 8.

Рисунок 8. Условная схема взаимодействия “агент-менеджер”

Стандартом де-факто (который фактически является «рабочей» и «упрощенной» альтернативой отраслевому CMIP), поддерживаемым в той или иной версии любым производителем телекоммуникационного оборудования, на сегодняшний день является простой протокол управления сетями (Simple Network Management Protocol, SNMP), разработанный сообществом проектирования Интернета (Internet Engineering Task Force, IETF) специально для стека TCP/IP^[4].

Архитектура SNMP предполагает построение системы управления по схеме «менеджер-агент», т. е. использование архитектурного стиля «клиент-сервер», о чем было сказано выше. Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточно простой сервер - агент SNMP, а также, по крайней мере, один узел, содержащий сложного клиента - менеджера SNMP.

Менеджер взаимодействует с агентами при помощи протокола SNMP с целью обмена управляющей информацией. В основном, это взаимодействие реализуется в виде периодического опроса менеджером множества агентов, т. к. агенты всего лишь предоставляют доступ к информации. Общая схема взаимодействия показана на рисунке 9.

Для повышения масштабируемости и административной управляемости вводится понятие прокси-агента, который может переправлять операции протокола SNMP, а также понятие менеджера промежуточного уровня, который скрывает несущественные подробности управляющей информации от систем управления сетями верхнего уровня, интегрируя получаемые от агентов данные. Это позволяет создавать многоуровневые системы управления, соответствующие архитектурному стилю «многоуровневый клиент-сервер»^[4].

Данные системы используют для обмена между клиентом и сервером транспортный уровень модели OSI с его протоколами. Это могут быть TCP, UDP, SCTP. Обычно используется TCP, как наиболее распространённый; SCTP является на сегодняшний день менее используемым, но более перспективным с точки зрения предоставляемых возможностей сетевой настройки.

Помимо SNMP в качестве протокола управления можно использовать другие протоколы, такие как NetFlow.

Протокол NetFlow является запатентованным протоколом компании Cisco Systems. Он оперирует понятием «поток», который определяется как последовательность пакетов между источником и пунктом назначения, идентифицируемая IP-адресом сетевого уровня и портами источника и пункта назначения транспортного уровня модели OSI.

Рисунок 9. Процедура взаимодействия агента SNMP и менеджера SNMP

На сегодняшний день доступна версия 9 протокола NetFlow, так называемый протокол IPFIX. После первичного анализа можно сделать вывод о том, что эти два протокола на этапе рассмотрения без объекта приложения мало различимы; дифференциация может проявится только на этапе «тонкой настройки сети.

Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Netflow имеет три основных компонента:

1. Сенсор;

2. Коллектор;

3. Система обработки и представления данных.

Сенсор — демон (англ. daemon), который “слушает” сеть и фиксирует данные сеанса.Сенсор должен иметь возможность подключиться к сетевому элементу, "зеркалированному" порту коммутатора или любому другому устройству, для просмотра сетевого трафика. Сенсор будет собирать информацию о сеансах и сбрасывать ее в коллектор.

Коллектор — второй демон, который слушает на UDP порту, указанному при настройке и осуществляет сбор информации от сенсора. Полученные данные он сбрасывает в файл для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.

Наконец, система обработки читает эти файлы и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором^[4].

В целом, сбор данных с использованием NetFlow может быть сведён к единому виду, изображённому на рисунке 10.

Рисунок 10. Типовая топология при использовании NetFlow

Другим, наиболее перспективным на сегодняшний день, по мнению автора, протоколом такого типа является протокол SFlow. Агент для протокола SFlow - программный модуль, осуществляющий учет и тарификацию услуг доступа в сеть Internet (IP услуг), предоставляемых абонентам по выделенному каналу, средствами аппаратуры, поддерживающей экспорт статистических данных по протоколу SFlow. Протокол SFlow (RFC 3176) сравнительно новый и, как следствие, обладает рядом преимуществ по сравнению с NetFlow (Cisco Systems) так же как, впрочем, и рядом недостатков. Среди основных преимуществ протокола явным образом можно выделить меньшую по сравнению с NetFlow потребность в процессорных ресурсах аппаратуры и большее количество экспортируемых параметров о трафике.

Несомненным недостатком является то, что протокол поддерживается еще не слишком широким кругом производителей, среди которых основным является Hewlett Packard, осуществляющий поддержку SFlow второй версии в верхней линейке коммутаторов третьего уровня HP ProCurve 53хх и HP ProCurve 93xx. Особенностью является то, что в отличие от NetFlow в SFlow экспортируется как входящий на интерфейс трафик так и исходящий, что в ряде случав может быть преимуществом, а в ряде случаев недостатком.
Основные задачи, решаемые агентом, аналогичны задачам, решаемым агентами NetFlow, а именно: регистрация, тарификация и первый уровень агрегирования данных об IP трафике, прошедшем через маршрутизатор или коммутатор.

Данный модуль получает статистические данные о прошедшем трафике в виде SFlow потока аналогично агенту для протокола NetFlow, посылаемого маршрутизатором по протоколу UDP, что предъявляет соответствующие требования к каналу передачи данных между маршрутизатором и сервером, на котором функционирует агент SFlow. В большинстве случаев агент SFlow рекомендуется размещать в той же Ethernet сети, что и маршрутизатор. В зависимости от интенсивности информационного потока, проходящего через маршрутизатор, SFlow поток может также иметь разную интенсивность, однако параметры экспорта потока настраиваются в отличие от NetFlow что является преимуществом. Дэйтаграммы протокола могут отсылаться агенту периодически с задаваемым интервалом, вне зависимости от того имеет место трафик или нет. Так же имеется режим отправки дэйтаграмм по мере накопления статистических данных устройством.

Помимо функций регистрации данных, агрегирования и тарификации, агент для SFlow протокола может осуществлять контроль доступа абонентов в IP сеть. В частности возможно прекращение обслуживания абонентов по истечению балансных средств на расчетном счете абонента. Функции включения/отключения доступа реализованы внешними процедурами, управляемыми системой контроля доступа SFlow агента для обеспечения максимальной гибкости при интеграции агента с существующими системами управления доступом.

Агент для протокола SFlow способен работать в режиме SAFE, когда канал между сервером и агентом ненадежен, или обладает недостаточной пропускной способностью. В этом случае регистрация и хранение первичных данных осуществляется на локальном сервере (доступа) на котором установлен агент. Такой подход минимизирует объем передаваемых данных между сервером и агентом, и позволяет осуществить перехват управления доступом абонентов в сеть в случае отсутствия связи с центральным хранилищем, обеспечивая блокировку и разблокировку абонентов по локальным данным известным на момент пропадания связи с центральной БД. При восстановлении связи происходит автоматическая репликация баз данных агента и сервера.

Рассмотренные протоколы нашли широкое применение в различных системах управления сетями передачи данных. Каждый их них имеет свои достоинства и недостатки.

Для SNMP недостатком является то, что агенты создают довольно высокую нагрузку на оборудование и не обладают достаточной гибкостью. Для доступа к информации по протоколу SNMP необходимо каждый раз опрашивать сетевое устройство

Протокол NetFlow накапливает в памяти статистику и затем отправляет эти данные NetFlow-коллектору, который в свою очередь заносит полученные данные в базу данных для дальнейшего анализа. Данный способ получения данных удобен, так как в этом протоколе не используются агенты, собирающие информацию у системы. Информация, получаемая по протоколу NetFlow, идеально подходит для целей мониторинга производительности и биллинга.

Протокол sFlow еще не нашёл широкого применения, но уже используется в некоторых новых линейках оборудования HP. Специфичный интерфейс ASIC также позволяет выделять этот протокол как очень перспективный (данный интерфейс потенциально может участвовать в мониторинге сети при отсутствии 3го уровня модели OSI; также любопытно, что в него может быть встроен собственный процессор для работы интерфейса как анализатора трафика)

NMS зачастую работает над системой управления элементами сети Element Management System (EMS). EMS можно условно расположить на EML модели LLA TMN. Так одна EMS может отвечать за определённый тип оборудования одного производителя. EMS должны выполнять все функции модели FCAPS рекомендации МСЭ-Т М.3400. Можно сказать (по аналогии с компьютерной системой, т.к. EMS являются совокупностью аппаратных и программных средств), что EMS имеет “северный” и “южный” интерфейс. “Северный” интерфейс обычно направлен в сторону NMS (или OSS при определённом сценарии развёртывания сети), а “южный”-в сторону устройств для взаимодействия с ними. Если говорить в терминах TMN рекомендации M.3010, то можно сказать о следующем факте расположении относительно друг друга NMS и EMS, проиллюстрированном на рисунке 11.

Таким образом, можно сказать, что NMS и/или EMS, согласно рекомендации М.3010, должны взаимодействовать с другими функциональными элементами своей TMN посредством интерфейсов типа Q, а с одноименными элементами других TMN - посредством интерфейсов X. Как было сказано выше, обычно NMS и EMS поставляются производителем оборудования в рамках заказа оборудования и развёртывания серверов под NMS и EMS данного производителя. Поэтому технологических сложностей во взаимодействии оборудования, EMS и NMS обычно не происходит. Так, к примеру, для управления продуктовыми линейками BroadGate, XDM и Apollo, компании ECI Telecom, для каждой из которых в системе должна быть своя EMS, используется программный продукт LightSoft ( в качестве единой NMS), разработанный этой же компанией, что позволяет максимально обеспечить взаимодействие оборудования различных EMS используется Для взаимодействия NMS двух разных производителей или EMS одного и NMS обычно требуется доработка соответствующего интерфейса. Так было в случае с оборудованием линейки Syncom, которую компания ECI Telecom в своё время выкупила себе и также установила под управление LightSoft. Фактически, тогда для этой NMS EMS Syncom представлял собой EMS стороннего производителя и полный функционал управления оборудованием данной линейки через LightSoft был осуществлён относительно не сразу. Подробнее продукт LightSoft будет рассмотрен далее в рамках данной работы.

Можно подытожить, что NMS является общей системой обмена информацией через управляющие приложения, автоматизацию задач управления устройствами, обзор состояния и производительности сети, а также выявление и определение сетевых неисправностей. При помощи единой централизованной системы и базы данных об инвентаризации сети, NMS обеспечивает платформу межфункциональных возможности управления и мониторинга, что снижает накладные расходы сетевого администрирования.

EMS может применять на сетях операторов связи, где стоит задача управлением большим количеством однородных устройств или даже моногенных доменов, образованных таким оборудованием. EMS обладает важным для оператора связи свойством масштабируемости и предоставляет возможность упрощенной интеграции с системами сторонних производителей. Это соответствует ожиданиям поставщиков услуг по системам OSS.

Системы OSS/BSS

Ещё порядка тридцати лет назад все операции в телекоммуникационных компаниях выполнялись вручную и телефонные компании в то время были довольно крупными работодателями. Первые компьютеры, которые появились в области электросвязи, изначально использовались для повторяющихся операций, связанных с пакетной обработкой данных, например для проведения расчетов. Компьютеры применялись для поддержки и упрощения ручных операций. Отсюда и появилось понятие – «система операционной поддержки» - OSS. Несущественное процессное отличие от неё по тем временам представляли «системы поддержки бизнеса» - BSS, которые использовались для начисления заработной платы и других подобных операций.

По мере роста ассортимента и объемов услуг оборудование становилось всё боле сложным и число компьютеров увеличивалось. В некоторых системах поддержки число компьютеров могло исчисляться тысячами, причем в одной и той же сети могли размещаться буквально все типы существующих операционных систем, баз данных, структур данных и методов связи. Многие системы представляли собой разработки различных ИТ-отделов, лабораторий и подразделений компаний. Как правило, они предназначались для конкретного процесса или оператора, оказывающего вполне определенную услугу. Изменение этой системы под соответствующие нужды требовало значительных временных и ресурсных затрат, что негативно сказывалось на качестве конечного сервиса.

По мере роста количества и усложнения архитектуры систем среди специалистов в данной области появилось мнение, что часть процессов может быть автоматизирована. На том историческом этапе развития телекоммуникаций топ-менеджмент не видел необходимости унификации и развития систем поддержки операций и бизнеса ввиду узкой специализации компаний^[1].

Таким образом, к концу 90х на рынке телекоммуникаций появилось большое количество различных систем OSS/BSS, для которых всё чаще выдвигались требования взаимодействия друг с другом. На сегодняшний день можно наблюдать определённые сложности отрасли связи, которые возникают при интеграции систем поддержки операторской деятельности. Как было отмечено выше, это, прежде всего, связано с тем, что изначально системы поддержки бизнеса и операций разрабатывались для выполнения вполне определённой функции, иногда – специально под определённые низкоуровневые элементы в качестве источника информации (элементы NML и EML-в зависимости от реализации OSS; применительно к BSS данное замечание неверно). Таким образом, при необходимости обмена данными между двумя OSS (такая необходимость возникает при запуске параллельной OSS относительно существующей – для новой функции или при замене устаревшей OSS обновлённой) могут возникнуть определённые проблемы. Более сложно вопрос обстоит с BSS – сложными комплексными системами, отвечающими за поддержку управления жизненным циклом продукта, инфраструктуру, стратегию предприятия, комплексный менеджмент предприятия – в зависимости от реализации BSS (различные процессы первого уровня декомпозиции eTOM, относящиеся к стратегии бизнеса, отношениям с клиентами и поставщиками и другими глобальными вопросами в деятельности предприятия). Внедрение BSS на существующую инфраструктуру, как верхнеуровневой системы, всегда является крайне сложной задачей и требует длительного анализа по внедрению данной системы.

Описанные выше замечания могут быть минимизированы в будущем при использовании открытых систем и стандартизованных интерфейсов. В частности, решению данной задачи на эталонной сети может помочь использование интерфейсов типа Q и X согласно рекомендации М.3010 МСЭ-Т для взаимодействия разных функциональных блоков. Так же, как упоминалось выше, в качестве Q-интерфейсов между NMS и OSS могут использоваться MTOSI или CORBA – интерфейсы. Рассмотрение интерфейсов типа MTOSI или CORBA для упрощения взаимодействия гетерогенных и разных технологических систем в рамках данной работы не производится. Пример такого эталонного взаимодействия гетерогенных систем приведён на рисунке 12.

Таким образом, при использовании открытых моделей и технологий, обеспечивающих универсальность доступа, возможно построение относительно оптимальных систем с точки зрения прозрачности и рациональности сквозных процессов ввиду минимизации пути их прохождения.

На сегодняшний день можно наблюдать отсутствие международных рекомендаций и стандартов для построения систем NMS, OSS и BSS. Но в то же самое время существуют международные стандартизующие документы относительно построения эффективных и прозрачных систем управления сетями с точки зрения процессов. Таким образом, становится вполне решаемой задачей вопрос организации процессно-ориентированных систем с иерархической структурой, построенной с минимальным воздействием на структуру в плане её изменения. При этом в структуре должны быть использованы принципы, обеспечивающие максимальную непривязанность и абстрактность относительно решений, используемых на соседних уровнях TMN (или функциях/процессах eTOM). Это позволит реализовать оптимальное взаимодействие современных гетерогенных сетей, отвечая различным задачам компании-оператора и клиента.

Не нашли, что искали? Воспользуйтесь поиском по сайту: