Pregătiți-vă mediul

Broadworks XSPs poate fi implementat direct pe Internet sau poate locui într-un DMZ frontal cu un element de echilibrare a sarcinii, cum ar fi F5 BIG-IP. Pentru a oferi geo-redundanță, XSPs-urile pot fi implementate în două (sau mai multe) centre de date, fiecare poate fi frontată de un echilibrator de sarcină, fiecare având o adresă IP publică. Dacă XSPs se află în spatele unui echilibrator de sarcină, microservicele Webex și Aplicația văd doar adresa IP a echilibratorului de sarcină, iar Broadworks pare să aibă doar un XSP, chiar dacă există mai multe XSPs în spatele acestuia.

În exemplul de mai jos, XSPs sunt implementate la două site-uri, Site A și Site B. Există două XSPs frontate de un Balancer de încărcare la fiecare site. Site-ul A are XSP1 și XSP2 față de LB1, iar Site-ul B are XSP3 și XSP4 față de LB2. Doar Balancerii de Încărcare sunt expuși pe rețeaua publică, iar XSPs sunt în rețelele private DMZ.

configurare DNS

Microservicele Webex Cloud trebuie să poată găsi serverul (serverele) Broadworks XSP pentru conectarea la interfețele Xsi, serviciul de autentificare și CTI.

Microservicele Webex Cloud vor efectua căutarea DNS A/AAAA a numelui de gazdă XSP configurat și se vor conecta la adresa IP returnată. Acest lucru ar putea fi un element de margine de echilibrare a sarcinii, sau ar putea fi serverul XSP în sine. Dacă sunt returnate mai multe adrese IP, va fi selectat primul IP din listă. Căutarea SRV nu este acceptată în prezent.

Exemplu: Partenerul DNS A Record pentru descoperirea serverului XSP Round-Robin echilibrat cu fața la internet / Balancers de încărcare.

Eşec

Când microservicele Webex trimit o solicitare către XSP/Load Balancer și cererea eșuează, se pot întâmpla mai multe lucruri:

• Dacă defecțiunea se datorează unei erori de rețea (de exemplu: TCP, SSL), microservicele Webex marchează IP-ul ca blocat și efectuează imediat un progres de rută către următorul IP.

• Dacă este returnat un cod de eroare (HTTP 5xx), microservicele Webex marchează IP-ul ca blocat și efectuează imediat un progres de rută către următorul IP.

• Dacă nu se primește niciun răspuns HTTP în termen de 2 secunde, timpii de solicitare și microservicele Webex marchează IP-ul ca blocat și efectuează un progres de rută către următorul IP.

Fiecare solicitare este încercată de 3 ori înainte ca un eșec să fie raportat înapoi la microservice.

Atunci când un IP este în lista blocată, acesta nu va fi inclus în lista de adrese pentru a încerca atunci când trimiteți o solicitare către un XSP. După o perioadă predeterminată de timp, un IP blocat expiră și revine în listă pentru a încerca atunci când se face o altă solicitare.

Dacă toate adresele IP sunt blocate, microservicul va încerca în continuare să trimită cererea selectând aleatoriu o adresă IP din lista blocată. Dacă s-a reușit, acea adresă IP este eliminată din lista blocată.

Stare

Starea conectivității serviciilor Webex Cloud la XSPs sau Load Balancers poate fi văzută în Control Hub. În cadrul unui cluster de apelare BroadWorks, este afișată o stare de conexiune pentru fiecare dintre aceste interfețe:

• Acțiuni XSI

• Evenimente XSI

• Serviciu de autentificare

Starea conexiunii este actualizată atunci când pagina este încărcată sau în timpul actualizărilor de intrare. Stările conexiunilor pot fi:

• Verde: Când interfața poate fi atinsă pe unul dintre IP-uri în căutarea O înregistrare.

• Roşu: Atunci când toate IPs-urile din căutarea unei înregistrări sunt inaccesibile, iar interfața nu este disponibilă.

Următoarele servicii utilizează microservices pentru a se conecta la XSPs și sunt afectate de disponibilitatea interfeței XSP:

• Conectare la aplicația Webex

• Reîmprospătare token aplicație Webex

• E-mail/auto-activare de neîncredere

• Verificarea stării de sănătate a serviciului Broadworks

configurare DNS

Aplicația Webex accesează serviciile Xtended Services Interface (XSI-Actions & XSI-Events) și Device Management Service (DMS) de pe XSP.

Pentru a găsi serviciul XSI, aplicația Webex efectuează căutări DNS SRV pentru _xsi-client._tcp.<webex app xsi domain>. SRV indică URL-ul configurat pentru gazdele XSP sau balansoare de sarcină pentru serviciul XSI. Dacă căutarea SRV nu este disponibilă, aplicația Webex revine la căutarea A/AAAA.

SRV se poate rezolva la mai multe obiective A/AAAA. Cu toate acestea, fiecare înregistrare A/AAAA trebuie să mapeze doar la o singură adresă IP. Dacă există mai multe XSPs într-un DMZ în spatele dispozitivului de echilibrare a sarcinii/de margine, este necesar ca echilibratorul de sarcină să fie configurat pentru a menține persistența sesiunii pentru a direcționa toate solicitările aceleiași sesiuni către același XSP. Mandatăm această configurație deoarece bătăile de inimă ale evenimentului XSI ale clientului trebuie să meargă la același XSP care este utilizat pentru a stabili canalul evenimentului.

În Exemplul 1, înregistrarea A/AAAA pentru webex-app-xsp.example.com nu există și nu este necesar. Dacă DNS-ul dvs. necesită definirea unei înregistrări A/AAAA, atunci trebuie returnată numai 1 adresă IP. Indiferent, SRV trebuie să fie încă definit pentru Aplicația Webex. Dacă aplicația Webex utilizează numele A/AAAA care se rezolvă la mai mult de o adresă IP sau dacă elementul de echilibrare/margine a sarcinii nu menține persistența sesiunii, clientul trimite în cele din urmă bătăi de inimă unui XSP în cazul în care nu a stabilit un canal de eveniment. Acest lucru duce la faptul că canalul este rupt în jos, și, de asemenea, în trafic intern semnificativ mai mult, care afectează performanța clusterului XSP. Deoarece Aplicația Webex Cloud și Webex au cerințe diferite în căutarea înregistrărilor A/AAAA, trebuie să utilizați un FQDN separat pentru Webex Cloud și Aplicația Webex pentru a accesa XSPs-urile dvs. După cum se arată în exemple, Webex Cloud utilizează O înregistrare webex-cloud-xsp.example.com, iar Aplicația Webex utilizează SRV _xsi-client._tcp.webex-app-xsp.example.com.

Exemplul 1—Mai multe XSPs, fiecare din spatele echilibratorilor de sarcină separați

În acest exemplu, SRV indică mutarea înregistrărilor A cu fiecare înregistrare A, indicând un balansor de sarcină diferit la un site diferit. Aplicația Webex va utiliza întotdeauna prima adresă IP din listă și se va muta la următoarea înregistrare numai dacă prima este în jos.

Exemplul 2—XSPs multiple în spatele unui singur echilibrator de sarcină (cu Podul TLS)

Pentru cererea inițială, balansorul de sarcină selectează un XSP aleatoriu. Faptul că XSP returnează un cookie pe care Aplicația Webex îl include în cererile viitoare. Pentru solicitările viitoare, balansorul de sarcină utilizează modulul cookie pentru a direcționa conexiunea la XSP corect, asigurându-se că canalul evenimentului nu se rupe.

URL DMS

În timpul procesului de conectare, Aplicația Webex va prelua, de asemenea, URL-ul DMS pentru a descărca fișierul de configurare. Gazda din URL va parsa, iar aplicația Webex va efectua căutarea DNS A/AAAA a gazdei pentru a se conecta la XSP care găzduiește serviciul DMS.

Exemplu: DNS A Record pentru descoperirea serverului XSP cu fața la internet echilibrată Round-Robin / Balancers de încărcare de către aplicația Webex pentru a descărca fișiere de configurare prin DMS:

Cum găsește aplicația Webex adresele XSP

Clientul încearcă să localizeze nodurile XSP utilizând următorul flux DNS:

1. Clientul preia inițial URL-urile Xsi-Actions/Xsi-Events din Webex Cloud (le-ați introdus la crearea clusterului BroadWorks Calling asociat). Numele/domeniul gazdei Xsi este parsat din URL, iar clientul efectueaza cautarea SRV dupa cum urmeaza:

   1. Clientul efectuează o căutare SRV pentru _xsi-client._tcp.<xsi domain="">

   2. În cazul în care căutarea SRV returnează unul sau mai multe obiective A/AAAA:

      1. Clientul caută A/AAAA pentru aceste ținte și cache adresele IP returnate.

      2. Clientul se conectează la una dintre ținte (și, prin urmare, înregistrarea A / AAAA cu o singură adresă IP) pe baza priorității SRV, apoi greutatea (sau la întâmplare, dacă toate sunt egale).

   3. Dacă căutarea SRV nu returnează niciun obiectiv:

      Clientul caută A/AAAA parametrul rădăcină Xsi și apoi încearcă să se conecteze la adresa IP returnată. Acest lucru ar putea fi un element de margine de echilibrare a sarcinii, sau ar putea fi serverul XSP în sine.

      După cum s-a menționat, înregistrarea A/AAAA trebuie să se rezolve la o adresă IP din aceleași motive.

2. (Opțional) Puteți furniza ulterior detalii XSI-Actions/XSI-Events personalizate în configurația dispozitivului pentru aplicația Webex, utilizând următoarele etichete:

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

   1. Acești parametri de configurare au prioritate față de orice configurație din clusterul BroadWorks din Control Hub.

   2. Dacă există, clientul va compara adresa XSI originală primită prin configurația BroadWorks Cluster.

   3. Dacă există vreo diferență detectată, clientul își va reinițializa conectivitatea XSI Actions/ XSI Events. Primul pas în acest sens este de a efectua același proces de căutare DNS enumerate la pasul 1 – de data aceasta solicitând o căutare pentru valoarea din %XSI_ROOT_WXT% parametrul din fișierul de configurare.

      Asigurați-vă că creați înregistrările SRV corespunzătoare dacă utilizați această etichetă pentru a modifica interfețele Xsi.

Eşec

În timpul conectării, Aplicația Webex efectuează o căutare DNS SRV pentru _xsi-client._tcp.<xsi domain="">, construiește o listă de gazde și se conectează la unul dintre gazde pe baza priorității SRV, apoi la greutate. Această gazdă conectată devine cea selectată pentru toate cererile viitoare. Un canal de eveniment este apoi deschis gazdei selectate și o bătaie de inimă este trimisă în mod regulat pentru a verifica canalul. Toate solicitările trimise după prima includ un cookie care este returnat în răspunsul HTTP, prin urmare, este important ca balansorul de sarcină să mențină persistența sesiunii (afinitate) și să trimită întotdeauna solicitări către același server XSP backend.

Dacă o solicitare sau o solicitare de bătăi de inimă către o gazdă eșuează, se pot întâmpla mai multe lucruri:

• Dacă defecțiunea se datorează unei erori de rețea (de exemplu: TCP, SSL), ruta Aplicației Webex avansează imediat către următoarea gazdă din listă.

• Dacă este returnat un cod de eroare (HTTP 5xx), Aplicația Webex marchează acea adresă IP ca fiind blocată și se îndreaptă către următoarea gazdă din listă.

• Dacă un răspuns nu este primit într-o perioadă de timp, atunci cererea este considerată nereușită din cauza expirării termenului și următoarele cereri sunt trimise către următoarea gazdă. Cu toate acestea, solicitarea expirată este considerată nereușită. Unele cereri sunt reîncercate după eșec (cu timpul de reîncercare în creștere). Cererile ca presupusul non-vital nu sunt rejudecate.

Când o nouă gazdă este încercată cu succes, aceasta devine noua gazdă selectată dacă gazda este prezentă în listă. După ce ultima gazdă din listă este încercată, Aplicația Webex se va roti la prima.

În cazul bătăilor inimii, dacă există două eșecuri consecutive ale solicitării, Aplicația Webex va reiniția canalul evenimentului.

Rețineți că Aplicația Webex nu efectuează o copie de rezervă, iar descoperirea serviciului DNS se efectuează o singură dată la conectare.

În timpul conectării, Aplicația Webex încearcă să descarce fișierul de configurare prin interfața XSP/Dms. Acesta efectuează o căutare de înregistrare A/AAAA a gazdei în URL-ul DMS prelevat și se conectează la primul IP. Acesta va încerca mai întâi să trimită cererea pentru a descărca fișierul de configurare folosind un token SSO. Dacă acest lucru eșuează din orice motiv, va încerca din nou, dar cu numele de utilizator al dispozitivului și parola.