Підготуйте своє середовище

Broadworks XSP можна розгорнути безпосередньо в інтернеті або розташувати в 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 повинні мати можливість знаходити сервери Broadworks XSP для підключення до інтерфейсів Xsi, служби автентифікації та CTI.

Хмарні мікрослужби Webex виконають пошук A/AAAA DNS для налаштованого імені хоста XSP і підключаться до поверненої IP-адреси. Це може бути граничний елемент балансування навантаження або сам сервер XSP. Якщо повернуто кілька IP-адрес, буде вибрано першу IP-адресу в списку. Пошук SRV наразі не підтримується.

Приклад: Запис DNS A партнера для виявлення збалансованого збалансованого сервера XSP з підключенням до інтернету з системою Round-Robin/балансувальників навантаження.

Перехід після відмови

Коли мікрослужби Webex надсилають запит до XSP/Load Balancer і запит не виконується, може статися кілька речей:

• Якщо помилка сталася через помилку мережі (наприклад: TCP, SSL), мікрослужби Webex позначають IP-адресу як заблоковану й негайно виконують перехід до наступної IP-адреси.

• Якщо код помилки (HTTP5xx ), мікрослужби Webex позначають IP-адресу як заблоковану та негайно виконують перехід до наступної IP-адреси.

• Якщо протягом 2 секунд не отримано відповіді HTTP, закінчується час очікування запиту, і мікрослужби Webex позначають IP-адресу як заблоковану й виконують перехід до наступної IP-адреси.

Кожен запит виконується 3 рази, перш ніж мікрослужбі повідомляється про помилку.

Якщо IP-адреса знаходиться в списку заблокованих, її не буде включено до списку адрес, які можна спробувати під час надсилання запиту до XSP. Через попередньо визначений період часу заблокована IP-адреса спливає, і вона повертається в список, щоб спробувати, коли надходить інший запит.

Якщо всі IP-адреси заблоковано, мікрослужба все одно намагатиметься надіслати запит, вибравши випадковим чином IP-адресу зі списку заблокованих. У разі успіху цю IP-адресу буде видалено зі списку заблокованих.

Стан

Стан підключення служб Webex Cloud до XSP або Load Balancers можна побачити в Control Hub. У кластері викликів BroadWorks відображається стан підключення для кожного з цих інтерфейсів:

• XSI дії

• XSI дії

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

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

• Зелений: Коли інтерфейс можна отримати на одній з IP-адрес у пошуку запису A.

• Червоний: Коли всі IP-адреси в пошуку запису A недоступні, а інтерфейс недоступний.

Такі служби використовують мікрослужби для підключення до XSP і на них впливає доступність інтерфейсу XSP:

• Вхід у програму Webex

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

• Ненадійна електронна пошта/самостійна активація

• Перевірка працездатності служби Broadworks

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

Програма Webex отримує доступ до інтерфейсу служб Xtended Services Interface (XSI-Actions & XSI-Events) і служб керування пристроями (DMS) на XSP.

Щоб знайти службу XSI, програма Webex виконує пошук DNS SRV _xsi-client._tcp.<webex app xsi domain>. SRV вказує на налаштовану URL-адресу для хостів XSP або балансувальників навантаження для служби XSI. Якщо пошук SRV недоступний, програма Webex переходить до пошуку A/AAAA.

SRV може підключатися до кількох цілей A/AAAA. Однак кожен запис A/AAAA має зіставлятися лише з однією IP-адресою. Якщо за балансувальником навантаження/пограничним пристроєм у DMZ розташовано кілька XSP, потрібно, щоб балансувальник навантаження був налаштований на підтримку стабільності сеансу, щоб маршрутизувати всі запити одного сеансу до того самого XSP. Ми вимагаємо цю конфігурацію, оскільки запити подій XSI клієнта мають надходити до того самого XSP, який використовується для встановлення каналу події.

У прикладі 1 запису A/AAAA для webex-app-xsp.example.com не існує, і він не потрібен. Якщо ваш DNS вимагає визначення одного запису A/AAAA, потрібно повернути лише 1 IP-адресу. Незважаючи на це, SRV має бути визначено для програми Webex. Якщо в програмі Webex використовується ім’я A/AAAA, яке дозволяє отримати більше однієї IP-адреси, або якщо балансувальник навантаження/пограничний елемент не підтримує стабільність сеансу, клієнт зрештою надсилає сигнали до XSP, де він не встановив канал подій. Це призводить до розриву каналу, а також до значного збільшення внутрішнього трафіку, що погіршує продуктивність кластера XSP. Оскільки до хмари Webex і програми Webex пред’являються різні вимоги до пошуку записів A/AAAA, для доступу до XSP необхідно використовувати окреме повне доменне ім’я для хмари Webex і програми Webex. Як показано в прикладах, Webex Cloud використовує запис 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, гарантуючи, що канал подій не порушується.

URL-адреса DMS

Під час процесу входу програма Webex також отримає URL-адресу DMS для завантаження файлу конфігурації. Хост в URL-адресі буде проаналізовано, і програма Webex виконає пошук DNS A/AAAA хоста, щоб підключитися до XSP, на якому розміщено службу DMS.

Приклад: Запис DNS для виявлення Round-Robin збалансованого XSP-сервера/балансувальників навантаження за допомогою програми Webex для завантаження файлів конфігурації через DMS:

Як програма Webex знаходить адреси XSP

Клієнт намагається знайти вузли XSP, використовуючи такий потік DNS:

1. Клієнт спочатку отримує URL-адреси Xsi-Actions/Xsi-Events із хмари Webex (ви ввели їх під час створення пов’язаного кластера викликів BroadWorks). Ім’я хоста/домен Xsi аналізується з URL, і клієнт виконує пошук SRV таким чином:

   1. Клієнт виконує пошук SRV для_xsi -клієнт._tcp .<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. (Необов’язково) Згодом ви можете надати користувацькі відомості про дії XSI/XSI-події в конфігурації пристрою для програми Webex за допомогою таких тегів:

   <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/Події XSI. Перший крок у цьому полягає в тому, щоб виконати той самий процес пошуку DNS, зазначений у кроці 1, цього разу запитуючи пошук значення в%XSI_ROOT_WXT% з його файлу конфігурації.

      Обов’язково створіть відповідні записи SRV, якщо ви використовуєте цей тег для зміни інтерфейсів Xsi.

Перехід після відмови

Під час входу програма Webex виконує пошук DNS SRV_xsi -клієнт._tcp .<xsi domain=""> , створює список хостів і підключається до одного з хостів на основі пріоритету SRV, а потім ваги. Цей підключений хост стає вибраним для всіх майбутніх запитів. Після цього вибраному організатору відкривається канал подій, і регулярно надсилаються сповіщення про підтвердження каналу. Усі запити, надіслані після першого, містять файл cookie, який повертається у відповіді HTTP, тому важливо, щоб балансувальник навантаження зберігав стабільність сеансу (спорідненість) і завжди надсилав запити на той самий серверний XSP-сервер.

Якщо запит або контрольний запит організатору не виконано, може статися кілька речей:

• Якщо помилка сталася через помилку мережі (наприклад: TCP, SSL), маршрут програми Webex негайно переходить до наступного хоста в списку.

• Якщо код помилки (HTTP5xx ), програма Webex позначає цю IP-адресу як заблоковану та переходить до наступного хоста в списку.

• Якщо відповідь не отримана протягом певного періоду часу, запит вважається не виконаним через тайм-аут, і наступні запити надсилаються наступному організатору. Однак запит на час очікування вважається не виконаним. Деякі запити повторюються після помилки (із збільшенням часу повторення). Запити, які вважаються не життєво важливими, не повторюються.

Після успішної спроби нового організатора він стає новим вибраним організатором, якщо організатор присутній у списку. Після спроби останнього організатора в списку програма Webex перейде до першого.

У разі серцебиття, якщо є дві послідовні помилки запиту, програма Webex повторно ініціалізує канал події.

Зверніть увагу, що програма Webex не виконує відновлення, а виявлення служби DNS виконується лише один раз під час входу.

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