Перейти к основному контенту

Архитектура и состав платформы wiSLA

Общее описание архитектуры

ПАК wiSLA относится к разряду крупных корпоративных приложений, архитектура которого построена по многослойной модели и полностью соответствует ставшей стандартом модели Java Platform, Enterprise Edition (Java EE). Программное обеспечение ПАК wiSLA представляет собой систему распределенных компонентов, взаимодействующих через внутренние интерфейсы.
Все составляющие ПО ПАК wiSLA поддерживают спецификацию Java EE. Это позволяет легче обеспечивать высокое качество и надежность взаимодействия компонентов, полную согласованность с применяемыми технологиями, такими как Hibernate, Spring, AngularJS, OpenJDK 11 и др.
Это означает, что элементами архитектуры ПАК wiSLA являются компоненты, каждый из которых предоставляет необходимые сервисы, т.е. наборы выполняемых функций. Каждый компонент инкапсулирован, а его интерфейсы обеспечивают доступ к бизнес-правилам, данным и операциям. Все компоненты имеют спецификации, интерфейсы, описания реализации и внедрения. Компоненты, как и сервисы, разделены на три типа: служебные, бизнес-компоненты/сервисы и управляющие.
Взаимодействие между компонентами осуществляется с помощью общей коммуникационной среды — обобщенной шины для обмена информацией (Common Communication Vehicle, CCV).

wiSLA_level_visual.jpg

Подсистема медиации (Mediation)

Подсистема медиации (Mediation) обеспечивает двустороннее взаимодействие системы с аппаратными и программными измерительными зондами, базами данных.

Рис. 1 Подсистема медиации (Mediation)

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

Ключевые особенности подсистемы:

  • Распределенная структура коллекторов. В целях повышения отказоустойчивости и производительности функций сбора данных с многотысячного парка устройств на различных сегментах сети по географическому или функциональному признаку могут быть выделены специальные коллекторы, выполняющие функции агрегации операций по сбору данных и оптимизации нагрузки на центральные компоненты подсистемы;
  • Независимые адаптеры. Сбор данных с каждого конкретного типа устройств осуществляется единым внутренним интерфейсом с помощью специально разработанных адаптеров, выполняющих набор устройство-специфичных действий. Это позволяет разработчикам в «горячем режиме» вносить изменения в каждый адаптер по отдельности и легче поддерживать новые версии прошивок устройств;
  • Поддержка устройств за NAT. Подсистема сбора данных может работать не только в классическом активном режиме (SNMP-запросы, выполнение CLI-команд в Telnet/SSH), но и принимать SNMP Trap, HTTP Get/Post запросы от измерительных средств и внешних систем.

Подсистема управления SLA (SLM)

Центром платформы wiSLA является подсистема управления SLA (Service Level Management), которая обеспечивает выполнение набора ключевых функций в рамках процесса управления качеством услуг: формирование периодических отчётов SLA, расчет компенсаций за нарушение уровня обслуживания и учет времени согласованных перерывов работы (отключение электропитания в офисе клиента, планово- профилактические работы, форс-мажоры и т.д.).

Рис. 2 Подсистема управления SLA (SLM)

Ключевые особенности подсистемы:

  • Гибкий конструктор параметров SLA. Заложенная в систему модель вложенности шаблонов SLA (набор показателей качества услуги и их пороговые значения) и классов обслуживания, описывающая уровень реагирования на проблемы клиента (время на устранение аварий, уровни эскалации SLA), позволяет отвечать любым запросам различных групп клиентов, сохраняя при этом индивидуальный подход;
  • Настраиваемые правила расчета. Анализ и оценка уровня обслуживания основана на гибко настраиваемом механизме расчета ключевых показателей качества: готовность услуги, суммарное время необслуживания, среднее время между авариями и др. Т.е., например, для расчета суммарного времени неготовности услуги могут браться только интервалы, которые не обслуживались более 15 минут, игнорируя при этом более короткие.

Подсистема мониторинга качества сервиса (SQM)

Подсистема мониторинга качества сервиса (SQM) обеспечивает непрерывный мониторинг и оперативную оценку качества услуг с точки зрения потребителя в любой момент времени.

Рис. 3 Подсистема мониторинга качества сервиса (SQM)

Важной составной частью SQM является SQM-монитор, который реализован на базе Java Message Service. В каждом цикле сбора данных SQM-монитор сравнивает значения показателей качества услуги со значениями в настройках мониторинга и определяет статус сервиса. Значения, указанные в настройках мониторинга, по умолчанию соответствуют значениям указанным в SLA и могут быть изменены оператором.

К функциям, реализуемым подсистемой, относятся:

  • анализ поступающей от подсистемы сбора данных информации:
    • сравнение значений показателей качества с установленными SLA порогами,
    • частота обновления информации от 10 секунд до 5 минут;
  • инициация нагрузочного тестирования контролируемых услуг;
  • формирование оперативных отчётов показателей производительности услуг (KPI);
  • мониторинг группы каналов в момент проведения видеоконференции.

Ключевые особенности подсистемы:

  • Обработка BigData. Для повышения производительности и обработки массивного потока данных, поступающих от измерительных зондов, используется нереляционная распределённая база данных HBase, которая обеспечивает отказоустойчивый способ хранения больших объёмов разреженных данных;
  • Многогранный мониторинг. Архитектура и объектная модель подсистемы SQM обеспечивает возможность мониторинга одной услуги в различных срезах, например, оценить качество канала связи между Москвой и Новосибирском в разрезе прохождения различных типов трафика (данные, голос, видео и др.).

Подсистема учета неисправностей (Service Desk)

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

Рис. 4 Подсистема учета неисправностей (Service Desk)

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

Ключевые особенности подсистемы:

  • Встроенный FM-engine. В подсистему учета неисправностей заложены все базовые функции управления жизненным циклом аварии (открытие, обработка, приостановка, закрытие), а также корреляция аварийных событий по времени открытия, точкам доступа и классам трафика;
  • Гибкая настройка времени реакции. Подсистема учета неисправностей позволяет гибко настраивать время реакции системы на аварийные сигналы. Паспорт неисправности может быть открыт с минимально возможной задержкой или через заданное время, в течение которого услуга находится в аварийном состоянии. Это позволяет избегать шквалов уведомлений о кратковременных проблемах.

Подсистема учета (SMDB)

Подсистема учета (SMDB) обеспечивает учет и управление инфраструктурой контролируемых услуг и измерительного оборудования. Подсистема обеспечивает управление взаимосвязями между такими сущностями, как контрагент, контракт, сервисы, измерения, точки доступа, зонды (измерительное оборудование или устройства) и тесты в соответствии в SID (Shared Information and Data Model). Согласно TAM (Telecom Operations Map), подсистема учета выполняет функции Resource Inventory, Service Inventory, Customer Inventory (CRM). В подсистеме учета также хранятся цепочки показателей качества и производительности KPI/KQI в привязке к сервисам.

Рис. 5 Подсистема учета (SMBD)

Интеграционная платформа (Integration Framework)

Интеграция wiSLA с внешними системами OSS/BSS выполняется посредством интеграционной платформы (Integration Framework). В основу платформы заложены сервисно-ориентированная архитектура (SOA) и открытые интерфейсы (WSDL/SOAP/XML). wiSLA содержит предынтегрированные модули к существующим системам Trouble Ticketing, Fault Management, Order Management, а также модули к внешним Web-порталам Заказчика. Дополнительно в рамках интеграционной платформы может поставляться модуль управления бизнес-процессами (BPM).

Рис. 6 Интеграционная платформа (Integration Framework)

Портал оператора (Operator Portal)

Портал оператора ПАК wiSLA предназначен для управления системой: постановки услуг (сервисов) на мониторинг, настройки параметров SLA, управления правами доступа пользователей, журналирования системных событий.

image.png