Растущая зависимость корпоративных и частных пользователей от телекоммуникационных услуг обусловливает их повышенный интерес к проблемам надежности сетей связи и соответствующих сервисов. С точки зрения пользователя, надежность услуг означает высокий уровень их доступности (пресловутые «пять девяток») в случае традиционной телефонии и, к сожалению, меньшее их число в отношении телематических сервисов.

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

Именно о последней составляющей — управлении сбоями (fault management) — и пойдет дальше речь. Действительно, правильно организовав его, оператор имеет все шансы уменьшить уязвимость сети и тем самым минимизировать последствия нештатных ситуаций.

К вершине пирамиды

Как известно, еще в первой половине 90-х годов принципы управления сетями связи оформились в концепцию Telecommunications Management Network (TMN). Суть ее — в формировании управляющей инфраструктуры, отделенной (хотя бы логически) от транспортной сети и обеспечивающей развертывание услуг связи и их администрирование.

Стандарты и спецификации в области TMN, а также связанных с этой концепцией технологий разрабатываются десятками организаций, а счет выпущенным документам давно пошел на тысячи. Тем не менее, если не вдаваться в детали, с архитектурной и функциональной точек зрения инфраструктуру TMN можно представить в виде небольшого числа компонентов (подробнее см. Сети, 1999, № 8-9, с. 118 и № 11, с. 26).

Логическая иерархическая архитектура TMN (Logical Layered Architecture, LLA), окончательно стандартизованная в 1996 году и нередко именуемая TMN-пирамидой, включает в себя пять уровней управления.

Самый нижний уровень сетевых элементов (Network Element Layer, NEL), выполняет функции интерфейса между базами данных с управляющей информацией (MIB), которые размещены на отдельных сетевых устройствах, и инфраструктурой TMN. Расположенный над ним уровень управления элементами (Element Management Layer, EML) соответствует системам поддержки операций (OSS), которые контролируют работу сразу нескольких сетевых ресурсов, объединенных в логическую группу. Как правило, именно здесь реализуются управляющие функции, специфические для оборудования конкретного производителя, и эта специфика маскируется от вышележащих уровней.

Следующий за ним уровень управления сетью (Network Management Layer, NML) формирует представление сети как целого на основе данных об отдельных сетевых элементах. Еще выше находится уровень управления услугами (Service Management Layer, SML). На него возложены контроль за качеством сервиса (QoS) и выполнением условий контрактов SLA, управление регистрационными записями и данными о клиентах, добавление или удаление пользователей и биллинговые процедуры, т. е. те аспекты функционирования сети, с которыми непосредственно соприкасаются пользователи.

Венчает TMN-пирамиду уровень бизнес-управления (Business Management Layer, BML). Он позволяет интегрировать управление сетью в бизнес-процессы оператора.

В плане функциональности все услуги управления, реализуемые инфраструктурой TMN, можно разбить на пять основных классов (FCAPS-модель, обозначаемая так по первым буквам английских названий этих групп): управление сбоями (fault management), конфигурацией (configuration management), данными о пользователях и ресурсах (accounting management), производительностью (performance management) и безопасностью (security management). Управление сбоями, стоящее в этом списке на первом месте, само распадается на ряд административных задач:

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

На первый взгляд, процедуры управления сбоями имеют дело с отдельными сетевыми элементами или их группами, а потому должны быть реализованы на уровне управления элементами EML. В действительности же они затрагивают сферу «компетенции» сразу нескольких этажей TMN-пирамиды. Именно по этой причине в стандартах и спецификациях TMN логическая архитектура отделена от функциональной.

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

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

Некоторые логические соотношения между различными процедурами, связанными с управлением сбоями, схематично представлены на рисунке.

Варианты решений

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

Поскольку фундаментом любой сети являются отдельные сетевые элементы, основными поставщиками средств управления ими традиционно являются производители оборудования, будь то Siemens или Alcatel, Cisco или Lucent. Как правило, вместе с сетевыми устройствами поставляются программные агенты и программы-менеджеры, оптимизированные для работы с соответствующими устройствами.

Нередко производители идут еще дальше, предлагая системы управления, которые позволяют реализовать значительную часть функций TMN. Этот подход оказывается вполне работоспособным, если сеть оператора базируется на продуктах одной компании, но «оставляет желать», когда речь заходит об администрировании гетерогенной сети.

В результате крупные операторы порой создают и внедряют системы управления сетью связи собственными силами. Потому-то в отчетах о состоянии TMN-рынка, публикуемых зарубежными аналитическими компаниями, среди разработчиков решений иногда указываются фирмы вроде NTT.

Как бы то ни было, такая задача по плечу только титанам мирового телекоммуникационного рынка. Операторы размером поменьше предпочитают иной сценарий: присмотреться к решениям независимых разработчиков ПО, которые не заинтересованы в продвижении какой-либо одной аппаратной платформы и, как правило, поддерживают оборудование сразу нескольких производителей. Некоторые из них будут кратко охарактеризованы ниже.

Как и в сфере традиционного сетевого администрирования, средства управления сетями связи можно разбить на две категории: интегрированные платформы и точечные решения. Первые претендуют на «покрытие» всех базовых функциональных областей TMN-архитектуры, тогда как вторые нацелены на решение более узких задач.

Еще пару лет назад двумя наиболее известными TMN-платформами независимых производителей были OpenView Element Management Framework (OEMF) корпорации Hewlett-Packard и Telecom Management Information Platform (TeMIP) компании Compaq. В составе первой присутствовал специальный модуль OpenView Fault Management Platform, охватывавший весь спектр процедур управления сбоями. В решении от Compaq схожая функциональность была реализована в семействе управляющих приложений TeMIP Solution Sets.

Завершившееся в прошлом году слияние этих компаний привело к интеграции функционально схожих продуктов. В ассортименте объединенной корпорации HP/Compaq появилось приложение HP OpenView TeMIP Fault Management and Real-Time Operations.

Его первый компонент отвечает за фильтрацию сетевых событий, выявление корреляций между различными событиями и их регистрацию, доставку сообщений о нештатных ситуациях операторам, работающим в среде Windows, UNIX или через Web-интерфейс. Второй компонент обеспечивает визуализацию процессов управления сбоями и их интеграцию через общий графический интерфейс с процедурами конфигурирования сети, анализа сетевой топологии, запуска приложений и автоматического обнаружения ресурсов.

Данное ПО поддерживает центры управления сетью (Network Operation Center, NOC) любого размера и способно работать с самыми разными коммуникационными инфраструктурами. Более того, интеграционная среда HP OpenView TeMIP позволяет операторам расширять функциональность приложения Fault Management, добавляя в него процедуры выявления причин тех или иных сетевых событий, анализа их воздействия на предоставляемые услуги, мониторинга производительности и управления качеством сервисов.

Среди систем управления сетями связи, относящихся к классу законченных решений, заслуживает упоминания и разработка OpenMaster for Telecom фирмы Evidian (бывшая BullSoft), входящей в группу Bull. В составе этого пакета имеется приложение Telecom Infrastructure Assurance, поддерживающее динамический мониторинг телекоммуникационной инфраструктуры мультисервисной сети (которая может включать в себя оборудование Alcatel, Ericsson, Matra, Nortel и других компаний), корреляционный анализ сетевых событий (прежде всего, отражающихся на качестве услуг), выявление причин нештатных ситуаций, генерацию уведомлений на основе правил. Кроме того, предусмотрена возможность организации на его основе автоматически выполняемых наборов действий, нацеленных на предотвращение потенциальных проблем функционирования сети.

В классе точечных решений к числу наиболее популярных продуктов относятся разработки компании Spirent Communications, более известной под прежним названием Hekimian Laboratoires. Собственно, точечным ее решение можно назвать с определенной натяжкой: система CenterOp for CPN обеспечивает функции управления сбоями и производительностью, тестирования сети и интеллектуального администрирования, которые интегрированы на одной платформе. Преимуществами такой интеграции являются возможность одновременной работы с несколькими функциональными модулями и визуализация результатов анализа сетевой активности (благодаря использованию единого интуитивного графического интерфейса).

Входящий в состав CenterOp for CPN программный компонент Sentry отвечает за интеллектуальный анализ сообщений, которые в огромных количествах ежедневно генерируются сетевыми элементами. Он позволяет отделить сетевые события, требующие немедленного вмешательства, от тех, которые предстоит проанализировать в дальнейшем для выявления трендов. При этом удается выявить истинные причины неполадок в работе сети, частенько вызывающих поток всевозможных «вторичных» сетевых сообщений.

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

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

Приведенные краткие описания, возможно, помогут читателю составить общее представление о типичной функциональности продуктов, реализующих функции управления сбоями в сетях связи в рамках концепции TMN. Несмотря на малочисленность участников данного рыночного сегмента, за кадром все равно остались несколько компаний, решения которых призваны прямо или косвенно повышать уровень доступности услуг. Список этих поставщиков, а также ссылки на другие полезные ресурсы по тематике TMN можно найти в Internet по адресу www.loria.fr/~festor/links.html.

Естественно задаться вопросом: какие системы управления сетями связи используются российскими операторами? И в какой мере функциональность этих систем соответствует возлагаемым на них задачам? Оказывается, составить достоверную картину не так-то просто.

На наше предложение поделиться своим мнением по этому поводу, адресованное нескольким игрокам российского телекоммуникационного рынка, откликнулась только фирма «ТрансТелеКом». Как сообщили представители этого оператора, он применяет управляющее ПО, поставляемое разработчиками сетевых аппаратных средств. Так, для управления SDH-оборудованием Siemens служит система Siemens EMHS, а устройствами Lucent Technologies — приложения ITM-CIP, ITM-SC и ITM-NM того же производителя.

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

Что ж, возможно, все это означает, что рано или поздно отечественные операторы связи обратят свои взоры в сторону TMN-решений независимых компаний.