Отказоустойчивость омниканальной платформы для контакт-центра

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

Итак, представим разговор двух абонентов, подключенных по протоколу SIP к платформе Эра. В качестве оконечных устройств могут использоваться IP-телефоны, классические софтфоны и вебфоны, подключенные по технологии WebRTC и WebSocket.

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

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

Рассмотрим четырехсерверную конфигурацию, в которой сигнализация и медиа разведены, не пересекаются и продублированы. В каждом разговоре могут быть задействованы все четыре сервера. Фасадом на данной схеме выступает роль SipGate, размещенная на первом сервере, маршрутизацией занимается бэк-ту-бэк-юзерагент на втором, медиашлюз, позволяющий обмениваться голосом, находится на третьем, а контроллер, связывающий б2б и медиашлюз — на четвертом. Телефонные аппараты взаимодействуют по сети с первым сервером по протоколу SIP и третьим по протоколу RTP.

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

Первый кейс — недоступность SIP GATE. Несмотря на то, что б2б остался на втором сервере, фактически мы полностью потеряли сигнализацию. Абоненты могут продолжать разговор благодаря живому медиашлюзу, однако попытки поставить звонок на удержание или выполнить перевод потерпят неудачу, так как сип-пакеты принять уже некому.

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

Третий кейс — недоступность MEDIA GATE (медиа-шлюза). Казалось бы, неприятно, но на самом деле не столь критично. Почему? Потому что при обнаружении недоступности медиа-шлюза медиагейт-контроллер подключает к работе резервный медиа-шлюз. Примерно в течение 100 миллисекунд б2б инциирует отправку сипгейтом реинвайтов на оба телефона с новой информацией в сдп. Это приводит к переключению ртп-трафика на четвертый сервер. В этом случае негативных последствий и ограничений для абонентов не возникает.

Четвертый кейс — недоступность MEDIA GATE CONTROLLER. Без какого-либо взаимодействия с телефонными аппаратами выполняется его переезд на третий сервер, разговор продолжается без потерь.

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

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

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

Вернемся к четырехсерверной конфигурации, Мы зафиксировали как наиболее неприятные кейсы потерю сигнализации (б2б или сипгейт).

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

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

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

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

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

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

Ну и напоследок несколько слов про Virtual IP. При необходимости сип-гейт, выступающий фасадом для телефонов, может переезжать вместе с виртуальным адресом ноды. Это может быть актуальным, если устройства не поддерживают инвайты с реплейсом с других адресов или множественную регистрацию.

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

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