Preparazione dell'ambiente

Gli XSP Broadworks possono essere distribuiti direttamente su Internet o risiedere in un DMZ frontale da un elemento di bilanciamento del carico come F5 BIG-IP. Per fornire ridondanza geografica, gli XSP possono essere distribuiti in due (o più) centri dati, ognuno può essere preceduto da un bilanciatore di carico, ognuno con un indirizzo IP pubblico. Se gli XSP sono dietro a un servizio di bilanciamento del carico, i microservizi e l'app Webex visualizzano solo l'indirizzo IP del servizio di bilanciamento del carico e Broadworks sembra avere solo un XSP, anche se sono presenti più XSP dietro.

Nell'esempio seguente, gli XSP vengono distribuiti in due siti, il sito A e il sito B. In ogni sito sono presenti due XSP frontali di un bilanciatore di carico. Il sito A ha XSP1 e XSP2 frontali di LB1 e il sito B ha XSP3 e XSP4 frontali di LB2. Solo i bilanciatori di carico sono esposti sulla rete pubblica e gli XSP sono nelle reti private DMZ.

Configurazione DNS

I microservizi cloud Webex devono essere in grado di trovare i server XSP Broadworks per la connessione alle interfacce Xsi, al servizio di autenticazione e al CTI.

I microservizi cloud Webex eseguiranno la ricerca DNS A/AAAA del nome host XSP configurato e si connetteranno all'indirizzo IP restituito. Potrebbe essere un elemento bordo di bilanciamento del carico oppure il server XSP stesso. Se vengono restituiti più indirizzi IP, viene selezionato il primo IP nell'elenco. La ricerca SRV non è attualmente supportata.

Esempio: Il DNS A Record del partner per la scoperta del server XSP/Load Balancers bilanciato Round-Robin.

Failover

Quando i microservizi Webex inviano una richiesta al servizio di bilanciamento del carico/XSP e la richiesta non riesce, possono verificarsi diverse cose:

• Se l'errore è dovuto a un errore di rete (es., TCP, SSL), i microservizi Webex contrassegnano l'IP come bloccato ed eseguono immediatamente un inoltro all'IP successivo.

• Se viene restituito un codice di errore (HTTP 5xx), i microservizi Webex contrassegnano l'IP come bloccato ed eseguono immediatamente un inoltro all'IP successivo.

• Se non viene ricevuta alcuna risposta HTTP entro 2 secondi, la richiesta viene timeout e i microservizi Webex contrassegnano l'IP come bloccato ed eseguono un avanzamento dell'indirizzamento all'IP successivo.

Ciascuna richiesta viene provata 3 volte prima di segnalare un errore al microservizio.

Quando un IP è nell'elenco bloccato, non verrà incluso nell'elenco di indirizzi da provare quando si invia una richiesta a un XSP. Dopo un periodo di tempo predeterminato, un IP bloccato scade e torna nell'elenco per provare quando viene effettuata un'altra richiesta.

Se tutti gli indirizzi IP sono bloccati, il microservizio tenterà comunque di inviare la richiesta selezionando casualmente un indirizzo IP dall'elenco bloccato. Se l'operazione va a buon fine, tale indirizzo IP viene rimosso dall'elenco bloccato.

Stato

Lo stato della connettività dei servizi Webex Cloud agli XSP o ai servizi di bilanciamento del carico è visibile in Control Hub. In un cluster BroadWorks Calling, viene visualizzato uno stato di connessione per ciascuna di queste interfacce:

• Azioni XSI

• Eventi XSI

• Servizio di autenticazione

Lo stato della connessione viene aggiornato quando viene caricata la pagina o durante gli aggiornamenti di input. Gli stati delle connessioni possono essere:

• Verde: Quando è possibile raggiungere l'interfaccia su uno degli IP nella ricerca di record A.

• Rosso: Quando tutti gli IP nella ricerca di record sono irraggiungibili e l'interfaccia non è disponibile.

I seguenti servizi utilizzano i microservizi per connettersi agli XSP e sono influenzati dalla disponibilità dell'interfaccia XSP:

• Accesso all'app Webex

• Aggiornamento token app Webex

• E-mail/autoattivazione non attendibile

• Controllo stato servizio Broadworks

Configurazione DNS

L'app Webex accede ai servizi Xtended Services Interface (XSI-Actions & XSI-Events) e Device Management Service (DMS) su XSP.

Per trovare il servizio XSI, l'app Webex esegue la ricerca DNS SRV per _xsi-client._tcp.<webex app xsi domain>. L'SRV punta all'URL configurato per gli host XSP o i bilanciatori di carico per il servizio XSI. Se la ricerca SRV non è disponibile, l'app Webex torna alla ricerca A/AAAA.

L'SRV può risolversi in più target A/AAAA. Tuttavia, ogni record A/AAAA deve mappare solo a un singolo indirizzo IP. Se sono presenti più XSP in un DMZ dietro il dispositivo di bilanciamento del carico/bordo, è necessario che il bilanciatore di carico sia configurato per mantenere la persistenza della sessione in modo da indirizzare tutte le richieste della stessa sessione allo stesso XSP. Questa configurazione viene avviata perché i heartbeat evento XSI del client devono passare allo stesso XSP utilizzato per stabilire il canale dell'evento.

Nell'Esempio 1, il record A/AAAA per webex-app-xsp.example.com non esiste e non deve esistere. Se il DNS richiede che un record A/AAAA deve essere definito, allora deve essere restituito solo 1 indirizzo IP. Indipendentemente da ciò, l'SRV deve essere ancora definito per l'app Webex. Se l'app Webex utilizza il nome A/AAAA che si risolve in più di un indirizzo IP o se l'elemento di bilanciamento del carico/bordo non mantiene la persistenza della sessione, il client alla fine invia heartbeat a un XSP in cui non ha stabilito un canale evento. Di conseguenza, il canale viene strappato e il traffico interno significativamente più intenso che compromette le prestazioni del cluster XSP. Poiché Webex Cloud e l'app Webex presentano requisiti diversi nella ricerca di record A/AAAA, è necessario utilizzare un nome di dominio completo separato per Webex Cloud e l'app Webex per accedere agli XSP. Come mostrato negli esempi, Webex Cloud utilizza Un record webex-cloud-xsp.example.com, e l'app Webex utilizza SRV _xsi-client._tcp.webex-app-xsp.example.com.

Esempio 1: più XSP, ciascuno dietro bilanciatori di carico separati

In questo esempio, SRV punta a disattivare l'audio dei record A con ogni record A che punta a un bilanciatore di carico diverso su un sito diverso. L'app Webex utilizzerà sempre il primo indirizzo IP nell'elenco e passerà al record successivo solo se il primo è inattivo.

Esempio 2: più XSP dietro un singolo bilanciatore di carico (con bridge TLS)

Per la richiesta iniziale, il bilanciatore di carico seleziona un XSP casuale. Tale XSP restituisce un cookie incluso nell'app Webex nelle richieste future. Per richieste future, il bilanciatore di carico utilizza il cookie per indirizzare la connessione all'XSP corretto, assicurandosi che il canale dell'evento non si interrompa.

URL DMS

Durante il processo di accesso, l'app Webex recupera anche l'URL DMS per scaricare il file di configurazione. Viene eseguita l'analisi dell'organizzatore nell'URL e l'app Webex esegue la ricerca DNS A/AAAA dell'organizzatore per connettersi all'XSP in cui è ospitato il servizio DMS.

Esempio: DNS Un record per la scoperta di server XSP/Bilanciamento del carico Internet bilanciato round-robin da parte dell'app Webex per scaricare i file di configurazione tramite DMS:

Come l'app Webex trova gli indirizzi XSP

Il client tenta di individuare i nodi XSP utilizzando il seguente flusso DNS:

1. Il client recupera inizialmente gli URL Xsi-Actions/Xsi-Events dal cloud Webex (sono stati inseriti quando si crea il cluster di chiamata BroadWorks associato). Il nome host/dominio Xsi viene analizzato dall'URL e il client esegue la ricerca SRV nel modo seguente:

   1. Il cliente esegue una ricerca SRV per _xsi-cliente._tcp.<xsi domain="">

   2. Se la ricerca SRV restituisce uno o più obiettivi A/AAAA:

      1. Il cliente cerca gli obiettivi A/AAAA e memorizza nella cache gli indirizzi IP restituiti.

      2. Il client si connette a uno dei target (e quindi al suo record A/AAAA con un singolo indirizzo IP) in base alla priorità SRV, quindi al peso (o a caso se sono tutti uguali).

   3. Se la ricerca SRV non restituisce alcun obiettivo:

      Il client esegue una ricerca A/AAAA del parametro principale Xsi e quindi tenta di connettersi all'indirizzo IP restituito. Potrebbe essere un elemento bordo di bilanciamento del carico oppure il server XSP stesso.

      Come indicato, il record A/AAAA deve risolversi in un indirizzo IP per le stesse ragioni.

2. (Opzionale) Successivamente, è possibile fornire dettagli XSI-Actions/XSI-Events personalizzati nella configurazione del dispositivo per l'app Webex, utilizzando i seguenti tag:

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

   1. Questi parametri di configurazione hanno la precedenza su qualsiasi configurazione nel cluster BroadWorks in Control Hub.

   2. Se esistono, il client confronterà l'indirizzo XSI originale ricevuto tramite la configurazione del cluster BroadWorks.

   3. Se viene rilevata una differenza, il client re-inizializzerà la connettività XSI Actions/XSI Events. La prima fase consiste nell'eseguire lo stesso processo di ricerca DNS elencato nella fase 1, richiedendo questa volta una ricerca del valore nel %XSI_ROOT_WXT% parametro dal file di configurazione.

      Assicurarsi di creare i record SRV corrispondenti se si utilizza questo tag per modificare le interfacce Xsi.

Failover

Durante l'accesso, l'app Webex esegue una ricerca DNS SRV per _xsi-client._tcp.<xsi domain="">, crea un elenco di organizzatori e si connette a uno degli organizzatori in base alla priorità SRV, quindi al peso. Questo organizzatore connesso diventa quello selezionato per tutte le richieste future. Viene quindi aperto un canale evento all'organizzatore selezionato e viene inviato regolarmente un heartbeat per verificare il canale. Tutte le richieste inviate dopo la prima includono un cookie che viene restituito nella risposta HTTP, pertanto è importante che il bilanciatore di carico mantenga la persistenza della sessione (affinità) e invii sempre le richieste allo stesso server XSP di backend.

Se una richiesta o una richiesta heartbeat a un organizzatore non riesce, possono verificarsi diverse cose:

• Se l'errore è dovuto a un errore di rete (es., TCP, SSL), l'indirizzamento dell'app Webex viene eseguito immediatamente all'organizzatore successivo nell'elenco.

• Se viene restituito un codice di errore (HTTP 5xx), l'app Webex contrassegna l'indirizzo IP come bloccato e l'indirizzamento passa all'organizzatore successivo nell'elenco.

• Se una risposta non viene ricevuta entro un periodo di tempo, la richiesta viene considerata non riuscita a causa del timeout e le richieste successive vengono inviate al successivo organizzatore. Tuttavia, la richiesta scaduta viene considerata come non riuscita. Alcune richieste vengono riprovate dopo l'errore (con un tempo di riprova crescente). Le richieste che il presunto non vitale non sono riprovate.

Quando un nuovo organizzatore viene provato correttamente, diventa il nuovo organizzatore selezionato se l'organizzatore è presente nell'elenco. Una volta provato l'ultimo organizzatore nell'elenco, l'app Webex passa al primo.

In caso di heartbeat, se si verificano due errori di richiesta consecutivi, l'app Webex re-inizializzerà il canale eventi.

Tenere presente che l'app Webex non esegue il failback e che il rilevamento del servizio DNS viene eseguito solo una volta all'accesso.

Durante l'accesso, l'app Webex tenta di scaricare il file di configurazione attraverso l'interfaccia XSP/Dms. Esegue una ricerca di record A/AAAA dell'host nell'URL DMS recuperato e si connette al primo IP. Innanzitutto, tenterà di inviare la richiesta per scaricare il file di configurazione utilizzando un token SSO. Se ciò non riesce per qualsiasi motivo, verrà riprovato ma con il nome utente e la password del dispositivo.