Przygotuj swoje środowisko

Broadworks XSPs może być wdrożony bezpośrednio w Internecie lub może przebywać w DMZ fronted przez element równoważenia obciążenia, takich jak F5 BIG-IP. Aby zapewnić geo-redundancji, XSPs mogą być rozmieszczone w dwóch (lub więcej) datacenters, każdy może być fronted przez równoważnika obciążenia, każdy z publicznym adresem IP. Jeśli XSPs znajdują się za równoważnikiem obciążenia, mikrousługi Webex i aplikacja widzą tylko adres IP równoważnika obciążenia i Broadworks wydaje się mieć tylko jeden XSP, nawet jeśli istnieje wiele XSPs za.

W poniższym przykładzie, XSPs są rozmieszczone w dwóch witrynach: Witrynie A i Witrynie B. W każdym zakładzie znajdują się dwa XSPs skierowane przez równoważnik obciążenia. Witryna A ma XSP1 i XSP2 fronted przez LB1, a strona B ma XSP3 i XSP4 fronted przez LB2. Tylko równoważniki obciążenia są narażone na sieci publiczne, a XSPs są w prywatnych sieciach DMZ.

Konfiguracja DNS

Mikrousługi Webex Cloud muszą być w stanie znaleźć serwer(y) Broadworks XSP do łączenia się z interfejsami Xsi, usługą uwierzytelniania i CTI.

Mikrousługi Webex Cloud wykonają wyszukiwanie DNS A/AAAA skonfigurowanej nazwy hosta XSP i połączą się ze zwróconym adresem IP. Może to być element krawędzi równoważenia obciążenia, albo może to być sam serwer XSP. Jeśli zostanie zwróconych wiele adresów IP, zostanie wybrany pierwszy adres IP na liście. Wyszukiwanie SRV nie jest obecnie obsługiwane.

Przykład: Rejestr DNS partnera do wykrycia Round-Robin wyważonego internetowego serwera XSP / Balancers obciążenia.

Niepowodzenie

Gdy mikrousługi Webex wysyłają żądanie do XSP/Load Balancer, a żądanie nie powiedzie się, może się zdarzyć kilka rzeczy:

• Jeśli awaria jest spowodowana błędem sieci (np.: TCP, SSL), mikrousługi Webex oznaczają adres IP jako zablokowany i natychmiast wykonują trasę do następnego adresu IP.

• Jeśli zostanie zwrócony kod błędu (HTTP 5xx), mikrousługi Webex oznaczą adres IP jako zablokowany i natychmiast wykonają przejście do następnego adresu IP.

• Jeśli w ciągu 2 sekund nie zostanie odebrana odpowiedź HTTP, czas żądania jest wyświetlany, a mikrousługi Webex oznaczają adres IP jako zablokowany i wykonują trasę do następnego adresu IP.

Każde żądanie jest wypróbowane 3 razy, zanim awaria zostanie zgłoszona z powrotem do mikrousługi.

Gdy adres IP znajduje się na liście zablokowanych, nie zostanie on umieszczony na liście adresów, aby spróbować podczas wysyłania żądania do XSP. Po określonym z góry okresie zablokowany adres IP wygasa i wraca na listę, aby spróbować po złożeniu innego żądania.

Jeśli wszystkie adresy IP są zablokowane, mikrousługa nadal będzie próbowała wysłać żądanie, wybierając losowo adres IP z zablokowanej listy. Jeśli się powiedzie, ten adres IP zostanie usunięty z listy zablokowanych.

Stan

Stan łączności usług Webex Cloud z systemami XSPs lub równoważnikami obciążenia można zobaczyć w Control Hub. W klastrze połączeń BroadWorks wyświetlany jest stan połączenia dla każdego z tych interfejsów:

• Czynności XSI

• Zdarzenia XSI

• Usługa uwierzytelniania

Stan połączenia jest aktualizowany po załadowaniu strony lub podczas aktualizacji danych wejściowych. Statusy połączeń mogą być następujące:

• Kolor zielony: Gdy interfejs można uzyskać na jednym z adresów IP w wyszukiwaniu rekordu A.

• Czerwony: Gdy wszystkie adresy IP w wyszukiwaniu rekordów A są nieosiągalne, a interfejs jest niedostępny.

Następujące usługi korzystają z mikrousług, aby nawiązać połączenie z systemami XSP i mają na nie wpływ dostępność interfejsu XSP:

• Logowanie do aplikacji Webex

• Odświeżanie tokenu aplikacji Webex

• Niezaufana wiadomość e-mail/aktywacja własna

• Sprawdzenie stanu usług Broadworks

Konfiguracja DNS

Aplikacja Webex uzyskuje dostęp do usług Xtended Services Interface (XSI-Actions & XSI-Events) oraz Device Management Service (DMS) w XSP.

Aby znaleźć usługę XSI, aplikacja Webex wykonuje wyszukiwanie DNS SRV dla _xsi-client._tcp.<webex app xsi domain>. SRV wskazuje skonfigurowany adres URL hostów XSP lub równoważników obciążenia dla usługi XSI. Jeśli wyszukiwanie SRV nie jest dostępne, aplikacja Webex powraca do wyszukiwania A/AAAA.

SRV może rozwiązać wiele celów A/AAAA. Jednak każdy rekord A/AAAA musi być mapowany tylko na jeden adres IP. Jeśli w DMZ znajduje się wiele XSPs za urządzeniem równoważącym/krańcowym obciążenie, wymagane jest skonfigurowanie równoważnika obciążenia tak, aby utrzymywał trwałość sesji i przesyłał wszystkie żądania tej samej sesji do tego samego XSP. Polecamy tę konfigurację, ponieważ bicie serca XSI-event klienta musi przejść do tego samego XSP, który jest używany do utworzenia kanału wydarzenia.

W przykładzie 1 rekord A/AAAA dla webex-app-xsp.example.com nie istnieje i nie musi. Jeśli system DNS wymaga zdefiniowania jednego rekordu A/AAAA, należy zwrócić tylko 1 adres IP. Niezależnie od tego SRV musi być nadal zdefiniowane dla aplikacji Webex. Jeśli aplikacja Webex używa nazwy A/AAAA, która ustala więcej niż jeden adres IP, lub jeśli element równoważący obciążenie/krawędź nie utrzymuje ciągłości sesji, klient w końcu wysyła bicie serca do XSP, gdzie nie ustanowił kanału wydarzenia. Powoduje to rozerwanie kanału, a także znacznie większy ruch wewnętrzny, który zakłóca wydajność klastra XSP. Ponieważ aplikacja Webex Cloud i Webex mają różne wymagania w wyszukiwaniu rekordów A/AAAA, aby uzyskać dostęp do XSPs, należy użyć osobnej nazwy FQDN dla aplikacji Webex Cloud i Webex. Jak pokazano w przykładach, Webex Cloud używa rekordu webex-cloud-xsp.example.com, a aplikacja Webex korzysta z SRV _xsi-client._tcp.webex-app-xsp.example.com.

Przykład 1— wiele równoważników XSPs, z których każda znajduje się za oddzielnymi równoważnikami obciążenia

W tym przykładzie SRV wskazuje, że należy zestawić rekordy A z każdym rekordem wskazującym na inny równoważnik obciążenia w innym miejscu. Aplikacja Webex zawsze używa pierwszego adresu IP na liście i przenosi się do następnego rekordu tylko wtedy, gdy pierwszy jest w dół.

Przykład 2— wiele procesorów XSPs za jednym bagażnikiem (z mostkiem TLS)

Dla początkowego żądania, równoważnik obciążenia wybiera losowy XSP. Ten plik XSP zwraca plik cookie, który aplikacja Webex zawiera w przyszłych żądaniach. W przypadku przyszłych wniosków równoważnik obciążenia wykorzystuje plik cookie do kierowania połączenia do prawidłowego XSP, zapewniając, że kanał wydarzenia nie zostanie przerwany.

DMS URL

W trakcie procesu logowania aplikacja Webex pobierze również adres URL DMS w celu pobrania pliku konfiguracyjnego. Prowadzący w adresie URL zostanie sparalizowany, a aplikacja Webex wykona wyszukiwanie DNS A/AAAA prowadzącego, aby połączyć się z XSP, który obsługuje usługę DMS.

Przykład: DNS Rekord do odkrycia wyważonego internetowego serwera XSP z okrągłym Robinem/równoważenia obciążenia przez aplikację Webex do pobierania plików konfiguracyjnych za pośrednictwem DMS:

Jak aplikacja Webex odnajduje adresy XSP

Klient próbuje zlokalizować węzły XSP przy użyciu następującego przepływu DNS:

1. Klient początkowo pobiera adresy URL Xsi-Actions/Xsi-Events z usługi Webex Cloud (wprowadzono je podczas tworzenia skojarzonego klastra połączeń BroadWorks). Nazwa hosta/domena Xsi jest parsowana z adresu URL, a klient wykonuje wyszukiwanie SRV w następujący sposób:

   1. Klient wykonuje wyszukiwanie SRV dla _xsi-klienta._tcp.<xsi domain="">

   2. Jeśli wyszukiwanie SRV zwraca co najmniej jeden cel A/AAAA:

      1. Klient wykonuje wyszukiwanie A/AAAA dla tych celów i przywołuje zwrócone adresy IP.

      2. Klient łączy się z jednym z celów (i dlatego jego rekord A/AAAA z jednym adresem IP) na podstawie priorytetu SRV, następnie waga (lub przypadkowo, jeśli wszystkie są równe).

   3. Jeśli wyszukiwanie SRV nie zwraca żadnych celów:

      Klient wykonuje wyszukiwanie A/AAAA parametru głównego Xsi, a następnie próbuje połączyć się ze zwróconym adresem IP. Może to być element krawędzi równoważenia obciążenia, albo może to być sam serwer XSP.

      Jak wspomniano, rekord A/AAAA musi ustąpić na jeden adres IP z tych samych powodów.

2. (Opcjonalnie) Możesz następnie podać niestandardowe szczegóły XSI-Actions/XSI-Events w konfiguracji urządzenia aplikacji Webex, używając następujących znaczników:

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

   1. Te parametry konfiguracji mają pierwszeństwo przed dowolną konfiguracją w klastrze BroadWorks w Control Hub.

   2. Jeśli istnieją, klient będzie porównywał oryginalny adres XSI otrzymany za pośrednictwem konfiguracji klastra BroadWorks.

   3. Jeśli wykryta zostanie jakaś różnica, klient ponownie zainicjuje połączenie XSI Actions/XSI Events. Pierwszym krokiem w tym celu jest wykonanie tego samego procesu wyszukiwania DNS wymienionego w kroku 1 – tym razem wymagającego wyszukiwania dla wartości w %XSI_ROOT_WXT% parametrze z pliku konfiguracyjnego.

      Jeśli używasz tego znacznika do zmiany interfejsów Xsi, utwórz odpowiednie rekordy SRV.

Niepowodzenie

Podczas logowania aplikacja Webex wykonuje wyszukiwanie DNS SRV dla _xsi-klienta._tcp.<xsi domain="">, buduje listę prowadzących i łączy się z jednym z prowadzących na podstawie priorytetu SRV, a następnie wagi. Ten połączony host staje się wybranym hostem dla wszystkich przyszłych żądań. Kanał wydarzenia zostanie następnie otwarty dla wybranego prowadzącego, a bicie serca będzie wysyłane regularnie w celu weryfikacji kanału. Wszystkie żądania wysłane po pierwszym zawierają plik cookie, który jest zwracany w odpowiedzi HTTP, dlatego ważne jest, aby równoważnik obciążenia utrzymywał trwałość sesji (powinowactwo) i zawsze wysyłał żądania do tego samego serwera XSP backend.

Jeśli żądanie lub żądanie bicia serca dla prowadzącego nie powiedzie się, może się zdarzyć kilka rzeczy:

• Jeśli awaria jest spowodowana błędem sieci (np.: TCP, SSL), trasa aplikacji Webex przechodzi natychmiast do następnego prowadzącego na liście.

• Jeśli zostanie zwrócony kod błędu (HTTP 5xx), aplikacja Webex oznaczy, że adres IP jest zablokowany i przekierowuje go do następnego prowadzącego na liście.

• Jeśli odpowiedź nie zostanie odebrana w określonym czasie, żądanie zostanie uznane za nieudane z powodu przekroczenia limitu czasu, a następne żądania zostaną wysłane do następnego prowadzącego. Jednak wniosek o przekroczenie limitu czasu jest uważany za nieudany. Niektóre żądania są ponawiane po niepowodzeniu (ze zwiększonym czasem ponawiania prób). Żądania, które nie są istotne, nie są ponownie rozpatrywane.

Gdy nowy prowadzący zostanie pomyślnie wypróbowany, stanie się nowym wybranym prowadzącym, jeśli jest obecny na liście. Po wypróbowaniu ostatniego prowadzącego na liście aplikacja Webex przejdzie do pierwszego.

W przypadku bicia serca, jeśli wystąpią dwie kolejne awarie żądania, aplikacja Webex ponownie zainicjuje kanał wydarzenia.

Należy pamiętać, że aplikacja Webex nie wykonuje funkcji zwrotu awaryjnego, a wykrywanie usług DNS jest wykonywane tylko raz podczas logowania.

Podczas logowania aplikacja Webex próbuje pobrać plik konfiguracyjny za pośrednictwem interfejsu XSP/Dms. Wykonuje wyszukiwanie rekordów A/AAAA hosta w pobranym adresie URL DMS i łączy się z pierwszym adresem IP. Najpierw spróbuje wysłać żądanie pobrania pliku konfiguracyjnego za pomocą tokena SSO. Jeśli to się nie powiedzie z jakiegokolwiek powodu, spróbuje ponownie, ale z nazwą użytkownika urządzenia i hasłem.