Подгответе вашата среда

XSP на Broadworks могат да бъдат разгърнати директно в Интернет или могат да се намират в DMZ, преден от елемент за балансиране на товара като F5 BIG- IP. За да осигурят резервиране на географски данни, XSP могат да бъдат разгърнати в два (или повече) центъра за данни, всеки от които може да бъде изправен от балансьор на натоварване, всеки от които има публичен IP адрес. Ако XSP са зад балансира на натоварването, микроуслугите и приложението Webex виждат само IP адрес на балансиращото устройство и изглежда, че Broadworks има само един XSP, дори ако зад него има множество XSP.

В примера по-долу XSP са разгърнати на два обекта, сайт A и сайт B. Има два XSP, предствани от Load Balancer на всеки сайт. Сайт A има XSP1 и XSP2, предствани от LB1, а сайт B има XSP3 и XSP4, предствани от LB2. Само Load Balancers са изложени в публичната мрежа, а XSP са в частните мрежи на DMZ.

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

Webex Cloud трябва да могат да намират сървъра(ите) на Broadworks XSP за свързване към Xsi интерфейсите, услугата за удостоверяване и CTI.

Webex Cloud ще извършат DNS A/AAAA търсене на конфигурираното XSP име на хост и ще се свържат с върнатия IP адрес. Това може да е крайен елемент за балансиране на товара или може да е самият XSP сървър. Ако бъдат върнати няколко IP адреса, първият IP в списъка ще бъде избран. Търсенето на SRV в момента не се поддържа.

Пример: DNS A Record на партньора за откриване на Round-Robin балансиран XSP сървър/балансиране на натоварването, ориентиран към интернет.

При отказ

Когато микроуслугите на Webex изпратят заявка до XSP/Load Balancer и заявката не успее, могат да се случат няколко неща:

• Ако повредата се дължи на мрежова грешка (напр. TCP, SSL), микроуслугите на Webex маркират IP като блокиран и незабавно извършват преминаване към следващия IP.

• Ако има код на грешката (HTTP5xx ) се връща, микроуслугите на Webex маркират IP като блокиран и незабавно извършват преминаване към следващия IP.

• Ако не се получи HTTP отговор в рамките на 2 секунди, заявката изтече и микроуслугите на Webex маркират IP като блокиран и изпълняват маршрут напред към следващия IP.

Всяка заявка се изпробва 3 пъти, преди грешката да бъде докладвана обратно на микроуслугата.

Когато IP е в блокирания списък, той няма да бъде включен в списъка с адреси, които да опитате при изпращане на заявка до XSP. След предварително определен период от време блокираният IP изтича и се връща в списъка, за да опита, когато бъде направена друга заявка.

Ако всички IP адреси са блокирани, микроуслугата все пак ще се опита да изпрати заявката, като избере на случаен принцип IP адрес от списъка с блокирани. Ако е успешен, този IP адрес се премахва от списъка с блокирани.

Статус

Състоянието на свързаността на услугите Webex Cloud към XSP или Load Balancers може да се види в Control Hub. Под клъстер за повиквания на BroadWorks се показва състояние на свързването за всеки от тези интерфейси:

• XSI Actions

• XSI Events

• Услуга на удостоверяване

Състоянието на състояние на свързването се актуализира, когато страницата се зареди или по време на актуализации на въвеждане. Състоянията на връзките могат да бъдат:

• зелено: Когато интерфейсът може да бъде достигнат на един от IP адресите в търсенето на A запис.

• червено: Когато всички IP адреси в търсенето на запис A са недостъпни и интерфейсът е недостъпен.

Следните услуги използват микроуслугите за свързване към XSP и са повлияни от наличността на XSP интерфейса:

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

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

• Недоверен имейл/самоактивиране

• Проверка на състоянието на Broadworks Service

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

Приложението Webex осъществява достъп до услугите Xtended Services Interface (XSI-Actions & XSI-Events) и Device Management Service (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 адрес . Ако има множество XSP в DMZ зад балансиращото устройство/крайното устройство, се изисква балансиращото устройство да бъде конфигурирано да поддържа устойчивост на сесията, за да насочва всички заявки от една и съща сесия към същия 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 Cloud и Webex App имат различни изисквания при търсене на A/AAAA записи, трябва да използвате отделно FQDN за Webex Cloud и Webex App за достъп до вашите XSP. Както е показано в примерите, 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 Bridge)

За първоначалната заявка балансьорът на натоварване избира произволен XSP. Този XSP връща бисквитка, която приложението Webex включва в бъдещи заявки. За бъдещи заявки балансьорът на натоварване използва бисквитката, за да насочи връзката към правилния XSP, като гарантира, че каналът за събития няма да се счупи.

DMS URL

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

Пример: DNS A Запис за откриване на Round-Robin балансиран XSP сървър/балансери на натоварването от Webex App за изтегляне на конфигурационни файлове чрез DMS:

Как приложението Webex намира XSP адреси

Клиентът се опитва да намери XSP възлите, използвайки следния DNS поток:

1. Първоначално клиентът извлича URL адреси на Xsi-Actions/Xsi-Events от Webex Cloud (вие ги въведохте, когато създавате свързания BroadWorks Calling Cluster). Името на хост 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-Actions/XSI-Events в конфигурация на устройството за 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 Cluster в Control Hub.

   2. Ако съществуват, клиентът ще сравни с оригиналния XSI адрес, който е получил чрез конфигурацията на BroadWorks Cluster.

   3. Ако има някаква разлика, клиентът ще инициализира отново своята връзка XSI Actions/XSI Events. Първата стъпка в това е да извършите същия процес на търсене на DNS , посочен в стъпка 1 – този път да поискате търсене за стойността в%XSI_ROOT_WXT% параметър от неговия конфигурационен файл.

      Уверете се, че сте създали съответните SRV записи, ако използвате този маркер за промяна на Xsi интерфейсите.

При отказ

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

Ако заявка или заявка за сърдечен ритъм към хост не успее, могат да се случат няколко неща:

• Ако повредата се дължи на мрежова грешка (напр. TCP, SSL), маршрутът на приложението Webex преминава незабавно към следващия хост в списъка.

• Ако има код на грешката (HTTP5xx ) се връща, приложението Webex маркира този IP адрес като блокиран и маршрутът преминава към следващия хост в списъка.

• Ако отговорът не бъде получен в рамките на определен период от време, тогава заявката се счита за неуспешна поради изчакване и следващите заявки се изпращат до следващия хост. Въпреки това, заявката за изтекло време се счита за неуспешна. Някои заявки се изпробват повторно след неуспех (с увеличаване на времето за повторен опит). Заявките, за които се предполага, че не са жизненоважни, не се изпълняват повторно.

Когато нов хост бъде изпробван успешно, той става новият избран хост, ако хостът присъства в списъка. След като бъде изпробван последният хост в списъка, приложението Webex ще се прехвърли към първия.

В случай на сърдечен ритъм, ако има две последователни неуспешни заявки, приложението Webex ще инициализира повторно канала за събитие.

Имайте предвид, че приложението Webex не извършва възстановяване при отказ и откриването на DNS услуга се извършва само веднъж при влизане.

По време на влизане приложението Webex се опитва да изтегли конфигурационния файл през интерфейса XSP/Dms. Той извършва търсене на A/AAAA запис на хоста в извлечения DMS URL и се свързва с първия IP. Първо ще се опита да изпрати заявката за изтегляне на конфигурационния файл с помощта на SSO маркер. Ако това не успее по някаква причина, ще опита отново, но с потребителското име и паролата на устройството.