Подготовка среды

Серверы XSP BroadWorks могут быть развернуты непосредственно в Интернете или находиться в DMZ за элементом балансировки нагрузки (например, F5 BIG-IP). Для обеспечения геоизбыточности серверы XSP можно развернуть в двух (или более) центрах обработки данных; каждый сервер может находиться за балансировщиком нагрузки и иметь общедоступный IP-адрес. Если XSP находятся за балансировщиком нагрузки, для микрослужб и приложений Webex будет отображаться только IP-адрес балансировщика нагрузки. Для BroadWorks будет доступен только один сервер XSP, даже если за балансировщиком находятся несколько XSP.

В примере ниже XSP развернуты на двух объектах: объект A и объект B. На каждом объекте находятся два сервера XSP, размещенные за балансировщиком нагрузки. На объекте A размещается XSP1 и XSP2 за балансировщиком LB1, а на объекте B – XSP3 и XSP4 за балансировщиком LB2. В общедоступной сети открыты только балансировщики нагрузки, а XSP находятся в частных сетях DMZ.

Конфигурация DNS

У облачных микрослужб Webex должна быть способность находить серверы XSP BroadWorks для подключения к интерфейсам Xsi, службе аутентификации и CTI.

Облачные микрослужбы Webex будут выполнять поиск записи A/AAAA DNS настроенного имени узла XSP и подключаться к IP-адресу, который будет возвращен. Это может быть граничный элемент балансировки нагрузки или сервер XSP. Если будет возвращено несколько IP-адресов, из списка будет выбран первый IP-адрес. Поиск SRV в настоящий момент не поддерживается.

Пример. A-запись DNS партнера для обнаружения сбалансированных серверов XSP/балансировщиков нагрузки, обращенных к Интернету, Round-Robin.

Failover

Если при отправке микрослужбами Webex запроса XSP / балансировщику нагрузки возникнет сбой запроса, может быть реализовано несколько сценариев.

• Если сбой вызван ошибкой сети (например, TCP, SSL), микрослужбы Webex помечают IP-адрес как заблокированный и немедленно выполняют переход к следующему IP-адресу.

• Если возвращен код ошибки (HTTP 5xx), микрослужбы Webex помечают IP-адрес как заблокированный и немедленно выполняют переход к следующему IP-адресу.

• Если ответ HTTP не получен в течение 2 секунд, время ожидания запроса истекает. Микрослужбы Webex помечают IP-адрес как заблокированный и выполняют переход к следующему IP-адресу.

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

Если IP-адрес находится в списке заблокированных, он не будет включен в список адресов для совершения попытки отправки запроса в XSP. По истечении предварительно заданного периода времени срок действия блокировки IP-адреса истекает и он возвращается в список для совершения попытки отправки другого запроса.

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

Состояние

Состояние соединения облачных служб Webex с XSP или балансировщиками нагрузки можно просмотреть в Control Hub. В кластере вызовов BroadWorks состояние соединения отображается для каждого из указанных ниже интерфейсов.

• XSI Actions

• XSI Events

• Служба аутентификации

Состояние соединения обновляется после загрузки страницы или во время обновлений данных ввода. Далее приведены варианты состояний.

• Зеленый: если к интерфейсу можно получить доступ с помощью одного из IP-адресов во время поиска A-записи.

• Красный: Если все IP-адреса во время поиска A-записи недоступны, а также недоступен интерфейс.

Перечисленные ниже службы используют микрослужбы для соединения с XSP и зависят от доступности интерфейса XSP.

• Вход в приложение Webex

• Обновление маркера приложения Webex

• Ненадежные адреса электронной почты / самостоятельная активация

• Проверка работоспособности службы BroadWorks

Конфигурация DNS

Приложение Webex взаимодействует с интерфейсами Xtended Services Interface [XSI-Action (действия XSI) и XSI-Event (события XSI)] и службами Device Management Service [DMS (служба управления устройствами)] в XSP.

Чтобы найти службу XSI, приложение Webex выполняет поиск SRV DNS для _xsi-client._tcp.<webex app xsi domain>. SRV указывает на настроенный URL-адрес для узлов XSP или балансировщиков нагрузки для службы XSI. Если поиск SRV недоступен, приложение Webex возвращается к поиску A/AAAA.

SRV может разрешать несколько целей A/AAAA. Однако каждая запись A/AAAA должна сопоставляться только с одним IP-адресом. Если существует несколько XSP в DMZ за балансировщиком нагрузки / пограничным устройством, балансировщик нагрузки должен быть настроен для обеспечения сохранения сеанса с целью маршрутизации всех запросов одного сеанса на один и тот же сервер XSP. Эта конфигурация требуется, поскольку пакеты пульса XSI-event (событие XSI) клиента должны отправляться на тот же сервер XSP, который используется для установления канала события.

В примере 1 запись A/AAAA для webex-app-xsp.example.com не существует и не требуется. Если ваш DNS требует, чтобы была определена одна запись A/AAAA, необходимо вернуть только 1 IP-адрес. Независимо от этого, SRV должен быть определен для приложения Webex. Если в приложении Webex используется имя A/AAAA, которое связано с несколькими IP-адресами, или если балансировщик нагрузки/пограничный элемент не поддерживает устойчивость сеанса, клиент в конечном итоге отправляет тактовые сигналы на XSP, где не был установлен канал event-совещания. В результате канал разрывается и значительно снижается внутренний трафик, что ухудшает производительность кластера XSP. Поскольку требования к облаку Webex и приложению Webex различаются в поиске записей A/AAAA, для доступа к XSP необходимо использовать отдельное полное доменное имя для облака Webex и приложения Webex. Как показано в примерах, в облаке Webex используется запись A webex-cloud-xsp.example.com, и приложение Webex использует SRV _xsi-client._tcp.webex-app-xsp.example.com.

Пример 1. Несколько XSP, каждый за отдельными балансировщиками нагрузки

В этом примере SRV указывает на искажение записей A, при этом каждая запись A указывает на другой балансировщик нагрузки на другом объекте. Приложение Webex всегда будет использовать первый IP-адрес в списке и переместится к следующей записи только в том случае, если первая не работает.

Пример 2. Несколько XSP за одним балансировщиком нагрузки (с мостом TLS)

Для первоначального запроса балансировщик нагрузки выбирает случайный XSP. Этот XSP возвращает файлы cookie, которые приложение Webex будет добавлять в будущих запросах. В будущих запросах балансировщик нагрузки использует файл cookie для маршрутизации подключения к правильному XSP, гарантируя, что канал event-совещания не прерывается.

URL-АДРЕС DMX

Во время процесса входа приложение Webex также будет извлекать URL-адрес DMS для скачивания его файла конфигурации. Будет проанализирован узел в URL-адресе, и приложение Webex выполнит поиск записи A/AAAA DNS узла для подключения к XSP, где размещена служба DMS.

Пример. A-запись DNS, используемая с целью обнаружения приложением Webex циклически сбалансированных серверов или балансировщиков нагрузки XSP с выходом в Интернет для скачивания файлов конфигурации через DMS.

Способ поиска приложением Webex адресов XSP

Клиент пытается найти узлы XSP, используя следующий поток DNS:

1. Клиент первоначально извлекает URL-адреса Xsi-Actions/Xsi-Events из облака Webex (они были введены при создании связанного кластера вызовов BroadWorks). Имя хоста/домен Xsi извлекается из URL-адреса, и клиент выполняет поиск SRV следующим образом:

   1. Клиент выполняет поиск параметра _xsi-client._tcp в SRV.<xsi domain="">

   2. Если поиск SRV возвращает одну или несколько целей A/AAAA:

      1. Клиент выполняет A/AAAA для этих целей и кэширует возвращенные IP-адреса.

      2. Клиент подключается к одной из целей (то есть его запись A/AAAA с одним IP-адресом) на основании приоритета SRV, а затем взвешивается (или в произвольном порядке, если они равны).

   3. Если поиск SRV не дает результатов:

      Клиент просматривает A/AAAA для корневого параметра Xsi, после чего пытается подключиться к возвращенному IP-адресу. Это может быть граничный элемент балансировки нагрузки или сервер XSP.

      Как было описано, запись A/AAAA должна указывать на один IP-адрес по тем же причинам.

2. (Необязательно) В дальнейшем в настройках устройства для приложения Webex можно указать пользовательские сведения о XSI-Actions/XSI-Events с помощью следующих тегов:

   <protocols>
   	<xsi>
   		<paths>
   			<root>%XSI_ROOT_WXT%</root>
   			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
   			<events>%XSI_EVENTS_PATH_WXT%</events>
   		</paths>
   	</xsi>
   </protocols>

   1. Эти параметры имеют приоритет перед любой конфигурацией кластера BroadWorks в Control Hub.

   2. Если они существуют, клиент будет сравнивать оригинальный адрес XSI, полученный с помощью конфигурации кластера BroadWorks.

   3. При обнаружении каких-либо отличий клиент инициирует соединение XSI Actions/ XSI Events. Первым шагом является выполнение того же процесса поиска DNS, указанного в шаге 1. На этот раз запрос поиска значения в %XSI_ROOT_WXT% параметре из файла конфигурации.

      При использовании этого тега для изменения интерфейсов Xsi создайте соответствующие записи SRV.

Failover

В процессе входа приложение Webex выполняет поиск параметра _xsi-client._tcp.<xsi domain=""> записи SRV DNS, создает список узлов и подключается к одному из узлов сначала на основе приоритета, а затем веса записи SRV. Этот подключенный узел становится выбранным узлом для всех будущих запросов. После этого для выбранного узла будет открыт канал события и регулярно будет происходить отправка пакетов пульса для проверки канала. Все запросы, отправленные после первого, включают файл cookie, возвращаемый в ответе HTTP, поэтому важно, чтобы балансировщик нагрузки обеспечивал сохранение (сходство) сеанса и всегда отправлял запросы на один и тот же сервер XSP.

Если произойдет сбой запроса или запроса пакета пульса в узел, может быть реализовано несколько сценариев.

• Если сбой вызван ошибкой сети (например, TCP, SSL), приложение Webex немедленно выполнит переход к следующему узлу в списке.

• Если возвращен код ошибки (HTTP 5xx), приложение Webex помечает этот IP-адрес как заблокированный и перенаправляет следующему узлу в списке.

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

После успешной попытки выбора нового узла он становится новым выбранным узлом, если таковой присутствует в списке. После попытки отправки запроса последнему узлу в списке приложение Webex перейдет к первому узлу.

Если происходит отправка пакетов пульса, то при двух последовательных сбоях запросов приложение Webex повторно инициализирует канал события.

Обратите внимание, что приложение Webex не осуществляет восстановление после сбоя. Обнаружение службы DNS выполняется только один раз при входе.

В процессе входа приложение Webex пытается скачать файл конфигурации с помощью интерфейса XSP или DMS. Выполняется поиск записи A/AAAA узла в извлеченном URL-адресе DMS и подключение к первому IP-адресу. Сначала будет предпринята попытка отправки запроса на скачивание файла конфигурации с помощью токена SSO. Если это по какой-либо причине не удастся, будет выполнена повторная попытка, однако с использованием имени пользователя устройства и пароля.