Система ECSS-10 поддерживает следующие способы обмена информацией (помимо VoIP):

  • Внутрисистемный обмен через интеграционную шину (BUS) по протоколу AMQP (обработка вызовов, конфигурация, СОРМ, аварийные сообщения и т.д.).
  • Внутрисистемный обмен контроля состояния доступности интерфейсов по протоколу VRRP.
  • Взаимодействие с Автоматизированной системой расчетов по протоколу FTP.
  • Взаимодействие с системой резервного копирования конфигураций по протоколу rsync.
  • Взаимодействие с системой мониторинга и управления EMS либо другой системой OAM по протоколу SNMP.
  • Взаимодействие с внешним почтовым сервером по протоколу SMTP (отправка нотификаций об авариях и пропущенных вызовах).
  • Взаимодействие с внешним сервером обмена сообщениями по протоколу XMPP (отправка нотификаций о пропущенных вызовах).
  • Взаимодействие с Web-конфигуратором посредством Web-сервисов и Web-сокетов.
  • Взаимодействие с внешним Radius-сервером по протоколу Radius (аутентификация и аккаунтинг).
  • Взаимодействие с внешним LDAP-сервером по протоколу LDAP (централизованная аутентификация пользователей CoCon и SIP-абонентов).
  • Взаимодействие с OSS посредством Web-сервисов.
  • Взаимодействие с порталом абонента посредством Web-сервисов.

Интеграционная шина

Для унификации обмена сообщениями между кластерами системы ECSS-10 применяется обмен через интеграционную шину, которую обеспечивает кластер Bus.
Обмен сообщениями осуществляется по протоколу AMQP версии 0-10. Со спецификациями протокола AMQP версии 0-10 можно ознакомиться по ссылке: http://www.amqp.org/sites/amqp.org/files/amqp0-10.zip.

Далее будут рассмотрены механизмы, которые используются в ECSS-10 при взаимодействии через Bus.

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

я (Consumer) сообщения.
Точка обмена (Exchange) выполняет функции маршрутизации сообщения при получении его брокером от отправителя. Целью "exchange" является определение того, в какую очередь должно быть доставлено каждое сообщение на основании транспортных параметров сообщения.

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

Типовой процесс доставки сообщения по протоколу AMQP можно отобразить следующим образом:

Отправитель == отправка ==> Точка обмена == маршрутизация ==> Очередь == доставка ==> Получатель
(Publisher)    (publish)    (Exchange)      (route)           (Queue)    (consumes)   (Consumer)

В процессе отправки сообщения отправитель устанавливает для сообщения различные параметры, которые влияют на процесс обработки и доставки сообщения.
Ключевыми параметрами, которые используются в ECSS-10, являются:

  • exchange - точка обмена, которая должна использоваться для маршрутизации сообщения на брокере;
  • routing.key - метка маршрутизации, которая используется при маршрутизации;
  • reply_to.exchange - точка обмена, которая должна использоваться при отправке ответного сообщения;
  • reply_to.routing_key - метка маршрутизации, которая должна использоваться при отправке ответного сообщения;
  • time_to_live - время жизни сообщения.

Точка обмена (Exchange)

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

  • Direct exchange
  • Fanout exchange
  • Topic exchange
  • Headers exchange

В системе ECSS-10 используется Direct Exchange.

В Direct Exchange маршрутизация входящих сообщений осуществляется в очереди на основании значения параметра "routing key" сообщения. Этот тип точки обмена идеален для организации unicast-потоков обмена сообщениями (можно организовать и multicast обмен).Direct Exchange работает следующим образом:

  • очередь Q связывается с точкой обмена с меткой маршрутизации routing.key=K;
  • когда новое сообщение поступает с меткой маршрутизации routing.key=R, то точка обмена маршрутизирует это сообщение в очередь Q, если R=K.

Direct exhange часто используется в ситуациях, когда нужно распределять задачи между несколькими однотипными обработчиками в режиме распределения нагрузки (round robin).

Схематически работа Direct exhcnage:

                                               |==Msg1 → Consumer1
== Msgs → Direct exhcnage == Msgs.rk1 → Queue1 |==Msg2 → Consumer2 
                                               |==Msg3 → Consumer3

Очередь (Queue)

Очереди в AMQP очень похожи на очереди в других системах доставки сообщений или обработки задач и представляют собой накопитель сообщений, работающий по принципу FIFO (First In First Out).Часть параметров очередь наследует от точки обмена, а также обладает следующими индивидуальными параметрами:

  • Name - имя;
  • Durable - определяет, сохраняются ли сообщения в очереди при рестарте брокера;
  • Exclusive - используется только одной коннекцией (получателем) и очередь удаляется, если коннекция закрывается;
  • Auto-delete - очередь удаляется, когда последний получатель отписывается от очереди.

Для того чтобы очередь можно было использовать её необходимо задекларировать (declare). Декларация очереди ведет к её созданию, если очереди с таким именем и тем же набором атрибутов не существует. Декларация очереди не происходит, если уже существует очередь с именно таким именем и набором атрибутов (очередь уже существует, декларация считается успешно выполненной). Если же происходит декларация очереди и определяется, что очередь с таким именем, но отличающимся набором параметров, уже существует - возвращается ошибка "PRECONDITIONS_FAILED".

AMQP 0-10 определяет следующие общие правила именования очередей:

  • имя очереди может содержать от 1 до 255 символов;
  • первый символ имеет следующие ограничения: буквы a-z или A-Z, цифры 0-9 и символ подчеркивания '_';
  • второй и последующие символы могут быть любыми UTF-8 символами.

В системе ECSS-10 применяются следующие дополнительные правила именования очередей:

  • имя очереди состоит из набора смысловых частей;
  • смысловые части разделяются символом точка ('.');
  • имя заканчивается суффиксом 'q' (допускается использовать суффикс 'qe').

В настоящий момент используются следующие общие правила формирования имен очередей:

  • core.cp.'core_cluster_name'.'number_of_call_process_group'.'number_of_call_process'.qe - очередь используется для отправки сообщений из кластера Adapter в кластер Core;
  • ecss.pa.sip-t.'pa_sip_cluster_name'.init.q - очередь для приема инициирующих сообщений, поступающих в кластер адаптера SIP из кластера Core;
  • ecss.pa.sip-t.'pa_sip_cluster_name'.'session_identifier'.q - очередь для приема сообщений кластером адаптера SIP из кластера Core в рамках вызова;
  • ecss.pa.megaco.'pa_megaco_cluster_name'::'gateway_name'.init.q - очередь для приема инициирующих сообщений, поступающих в кластер адаптера Megaco из кластера Core;
  • ecss.pa.megaco.'pa_megaco_cluster_name'::'gateway_name'.'session_identifier'.q - очередь для приема сообщений, поступающих в кластер адаптера Megaco из кластера Core в рамках вызова;
  • tring_client'client_version'....q - очереди подсистемы контроля целостности tring системы ECSS-10;
  • ccn....q - очереди подсистемы распределенной командной консоли CoCon системы ECSS-10;
  • ecss.cm.... - очереди подсистемы синхронизации конфигурации Configuration Manager системы ECSS-10;
  • ecss.rps....q - очереди подсистемы обмена событиями, нотификациями, авариями RPS системы ECSS-10;
  • dds.bus....q - очереди распределенной подсистемы доступа к хранилищу конфигурационной информации DDS кластера DS системы ECSS-10;
  • mycelium.mgmt.... - очереди, используемые брокером для синхронизации в кластере Bus.

Правила связывания (Bindings)

Bindings - это правила связывания/маршрутизации, которые используются в точке обмена для маршрутизации сообщений в очереди.
Для того чтобы точка обмена E могла направлять сообщения в очередь Q необходимо, чтобы Q была связана с E.
Правило связывания может иметь дополнительный "routing key" атрибут, который используется в некоторых типах точек обмена.
Назначение "routing key" в том, чтобы выбрать определенные сообщения, размещенные в "exchange", и направить их в соответствующую очередь. Таким образом, "routing key" работает как фильтр.

Если сообщение не может быть смаршрутизировано в точке обмена (например, нет соответствующего правила связывания), то оно отбрасывается либо возвращается отправителю (зависит от настроек атрибутов сообщения).

Получатели (Consumers)

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

Процесс доставки сообщения получателю

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

Спецификации протокола AMQP определяют 2 возможных алгоритма доставки сообщения:

  • basic.delivery/basic.get - в данном режиме сообщение удаляется из очереди сразу после отправки получателю;
  • использование механизма basic.ack - в данном режиме функционирует надежная доставка. Сообщение удаляется, когда брокер получил подтверждение об успешной обработке сообщения получателем.

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

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

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

Механизм управления потоком сообщений к получателю

В AMQP введен очень полезный механизм ограничения количества сообщений, которые брокер отправляет одному получателю. Обычно такие механизмы называются "flow control" (механизм управления потоком сообщений).

Механизм управления потоком AMQP позволяет ограничивать поток информации, отправляемой брокером получателю по:

  • количеству переданной информации (потолок в байтах);
  • количеству переданных сообщений.

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

Внутрисистемный обмен

С точки зрения транспорта взаимодействие компонент системы можно схематично изобразить следующим образом:

Рисунок 1 - Взаимодействие компонент системы

На рисунке 2 приведена схема путей обмена сообщениями между кластерами через информационную шину.

Рисунок 2 - Схема путей обмена сообщениями между кластерами через информационную шину

Для упрощения схемы взаимодействия далее в описании будет опущен кластер Bus. Но будет подразумеваться, что при обмене через AMQP все сообщения передаются через кластер Bus.

В процессе работы системы существуют следующие виды связей между кластерами:

Рисунок 3 - Обмен сообщениями в системе ECSS-10 в рамках обслуживания вызова

На рисунке 3 приведена схема обмена сообщениями в системе ECSS-10 в рамках обслуживания вызова, где

  • ACP - adapter core protocol - внутренний сигнальный протокол, используемый системой ECSS-10 для обслуживания вызовов;
  • Tollticket - детальная информация о вызове для последующего формирования CDR.

Рисунок 4 - Пути отправки сообщения об аварии системе ECSS-10

Информационные потоки сообщений распределенной консоли CoCon.
CoCon представляет собой распределенную облачную среду, к которой подключены все компоненты системы ECSS-10. Каждый подключенный компонент несет в себе функционал SSH-сервера, обеспечивающий возможность подключения клиентских терминалов по протоколу SSH. Каждый функциональный компонент содержит реализацию базовых команд CoCon (переходы по каталогам, команды управления нодой) и реализацию команд управления специфичных для этого компонента. При запуске компонента CoCon обеспечивает автоматическое связывание всех компонент в единую среду, за счет чего предоставляется возможность подключения к любому хосту системы ECSS-10 по протоколу SSH с возможностью выполнения любой команды вне зависимости от того где физически расположен компонент её реализующий. При выходе из строя какого-то компонента системы ECSS-10 он автоматически пропадает из CoCon (пропадает нода), а также пропадают команды, которые реализованы в этом компоненте. Когда компонент восстанавливает свою работу, он автоматически появляется в CoCon.

Информационные потоки механизма мониторинга компонентов системы tring.

Рисунок 5 - Информационные потоки механизма мониторинга компонентов системы tring

Внутрисистемный обмен контроля состояния доступности интерфейсов

Система ECSS-10 при работе с подключаемыми к ней абонентами и шлюзами выглядит как единая система с одним IP-адресом для подключения, например, по протоколу SIP, несмотря на то, что в схеме с резервированием система разворачивается минимум на двух хостах.
Такое функционирование системы обеспечивается организацией виртуального "расшаренного" между хостами интерфейса, который в каждый момент времени присутствует только на одном хосте. Этот функционал предоставляется службой keepalived и используется в протокольных адаптерах, которые непосредственно взаимодействуют с абонентами и шлюзами по VoIP-протоколам.

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

Рисунок 6 - Работа службы Keepalived