Umgebung vorbereiten

Die Broadworks XSPs können direkt im Internet bereitgestellt werden oder sich in einer DMZ befinden, die von einem Lastausgleichselement wie der F5 BIG-IP angesteuert wird. Zur Bereitstellung von Geo-Redundanz können die XSPs in zwei (oder mehr) Rechenzentren bereitgestellt werden, wobei jeder von einem Lastenausgleichsmodul mit jeweils einer öffentlichen IP-Adresse angesteuert werden kann. Wenn sich die XSPs hinter einem Lastenausgleich befinden, sehen die Webex-Mikrodienste und die App nur die IP-Adresse des Lastenausgleichs und Broadworks scheint nur einen XSP zu haben, selbst wenn mehrere XSPs zurückliegen.

Im folgenden Beispiel werden die XSPs an zwei Standorten, Standort A und Standort B, eingesetzt. Es gibt zwei XSPs, die von einem Lastenausgleichs an jedem Standort vorgegeben werden. Standort A hat XSP1- und XSP2-Fronten von LB1 und Standort B hat XSP3- und XSP4-Fronten von LB2. Lediglich die Lastenausgleichsträger werden im öffentlichen Netz exponiert, die XSPs in den privaten Netzwerken der DMZ.

DNS-Konfiguration

Die Webex Cloud-Mikrodienste müssen den/die Broadworks XSP-Server(s) für die Verbindung mit den Xsi-Schnittstellen, dem Authentifizierungsdienst und CTI finden können.

Die Webex Cloud-Mikrodienste führen eine DNS A/AAAA-Suche des konfigurierten XSP-Hostnamens durch und stellen eine Verbindung mit der zurückgegebenen IP-Adresse her. Dies kann ein Edge-Element für den Lastausgleich sein oder der XSP-Server selbst. Wenn mehrere IP-Adressen zurückgegeben werden, wird die erste IP in der Liste ausgewählt. SRV-Suche wird derzeit nicht unterstützt.

Beispiel: Der DNS A-Datensatz des Partners zur Entdeckung von Round-Robin ausgewogenen internetbasierten XSP-Server-/Lastenausgleich.

Failover

Wenn die Webex-Microservices eine Anforderung an den XSP/Load Balancer senden und die Anforderung fehlschlägt, können verschiedene Dinge passieren:

• Wenn der Fehler auf einem Netzwerkfehler beruht (z. B.: TCP, SSL) markieren die Webex-Mikrodienste die IP als blockiert und führen sofort eine Weiterleitung zur nächsten IP durch.

• Wenn ein Fehlercode (HTTP5xx) zurückgegeben wird, markieren die Webex-Mikrodienste die IP als blockiert und führen sofort eine Weiterleitung zur nächsten IP durch.

• Wenn innerhalb von 2 Sekunden keine HTTP-Antwort empfangen wird, wird bei der Anforderung eine Zeitüberschreitung durchgeführt, und die Webex-Mikrodienste markieren die IP als blockiert und führen einen Routenvorgriff zur nächsten IP durch.

Jede Anforderung wird 3 Mal versucht, bevor ein Fehler an den Microservice zurückgemeldet wird.

Wenn sich eine IP in der Sperrliste befindet, wird sie nicht in die Liste der Adressen aufgenommen, die Sie beim Senden einer Anforderung an ein XSP versuchen sollten. Nach einem vorgegebenen Zeitraum läuft eine blockierte IP ab und kehrt in die Liste zurück, um zu versuchen, wenn eine andere Anforderung gestellt wird.

Wenn alle IP-Adressen blockiert sind, versucht der Microservice weiterhin, die Anforderung durch zufällige Auswahl einer IP-Adresse aus der Sperrliste zu senden. Bei erfolgreicher Ausführung wird diese IP-Adresse aus der Sperrliste entfernt.

Status

Der Status der Konnektivität der Webex Cloud-Dienste mit den XSPs oder Load Balancern kann in Control Hub angezeigt werden. Unter einem BroadWorks Calling-Cluster wird für jede der folgenden Schnittstellen ein Verbindungsstatus angezeigt:

• XSI-Aktionen

• XSI-Ereignisse

• Authentifizierungsdienst

Der Verbindungsstatus wird aktualisiert, wenn die Seite geladen wird oder während der Eingabeaktualisierungen. Der Verbindungsstatus kann Folgendes sein:

• Grün: Wenn die Schnittstelle auf einem der IPs in der A-Datensatzsuche erreicht werden kann.

• Rot: Wenn alle IPs in der A-Datensatzsuche nicht erreichbar sind und die Schnittstelle nicht verfügbar ist.

Die folgenden Dienste nutzen die Microservices, um sich mit den XSPs zu verbinden und sind von der Verfügbarkeit der XSP-Schnittstelle betroffen:

• Webex-App-Anmeldung

• Aktualisierung des Webex-App-Tokens

• Nicht vertrauenswürdige E-Mail/Selbstaktivierung

• BroadWorks-Dienstzustandsprüfung

DNS-Konfiguration

Die Webex-App greift auf die Dienste Xtended Services Interface (XSI-Actions & XSI-Events) und Device Management Service (DMS) auf dem XSP zu.

Um den XSI-Dienst zu finden, führt die Webex-App eine DNS SRV-Suche durch für _xsi-client._tcp.<webex app xsi domain>. Der SRV verweist auf die konfigurierte URL für die XSP-Hosts oder Load Balancer für den XSI-Dienst. Wenn die SRV-Suche nicht verfügbar ist, greift die Webex-App auf die A/AAAA-Suche zurück.

Der SRV kann auf mehrere A/AAAA-Ziele aufgelöst werden. Jeder A/AAAA-Datensatz muss jedoch nur einer einzigen IP-Adresse zugeordnet werden. Wenn mehrere XSPs in einer DMZ hinter dem Lastenausgleichs-/Edge-Gerät vorhanden sind, muss der Lastenausgleichs so konfiguriert werden, dass die Sitzungspersistenz aufrechterhalten bleibt, um alle Anfragen derselben Sitzung an denselben XSP weiterzuleiten. Wir leiten diese Konfiguration ein, da die XSI-Event-Heartbeats des Clients zu demselben XSP gehen müssen, der zum Einrichten des Event-Kanals verwendet wird.

In Beispiel 1 ist der A/AAAA-Datensatz für webex-app-xsp.example.com nicht vorhanden und muss es nicht. Wenn Ihr DNS vorschreibt, dass ein A/AAAA-Datensatz definiert werden muss, dann sollte nur 1 IP-Adresse zurückgegeben werden. Unabhängig davon muss der SRV weiterhin für die Webex-App definiert sein. Wenn die Webex-App den A/AAAA-Namen verwendet, der zu mehr als einer IP-Adresse aufgelöst wird, oder wenn das Lastenausgleichs-/Edge-Element die Sitzungspersistenz nicht aufrechterhält, sendet der Client schließlich Heartbeats an einen XSP, bei dem kein Ereigniskanal eingerichtet wurde. Dies führt dazu, dass der Kanal abgerissen wird, und auch zu einem deutlich größeren internen Datenverkehr, der die Leistung Ihres XSP-Clusters beeinträchtigt. Da die Webex Cloud und die Webex App unterschiedliche Anforderungen in der A/AAAA-Datensatzsuche haben, müssen Sie für den Zugriff auf Ihre XSPs einen separaten FQDN für die Webex Cloud und die Webex App verwenden. Wie in den Beispielen gezeigt, verwendet Webex Cloud Einen Datensatz webex-cloud-xsp.example.com und die Webex-App verwendet SRV _xsi-client._tcp.webex-app-xsp.example.com.

Beispiel 1 – Mehrere XSPs, jeweils hinter separaten Lastenausgleichern

In diesem Beispiel weist der SRV darauf hin, A-Datensätze zu mutillen, wobei jeder A-Datensatz auf einen anderen Lastenausgleichsträger an einer anderen Stelle verweist. Die Webex-App verwendet immer die erste IP-Adresse in der Liste und wird nur zum nächsten Datensatz verschoben, wenn die erste nicht verfügbar ist.

Beispiel 2 – Mehrere XSPs hinter einem einzelnen Lastenausgleichs (mit TLS-Brücke)

Für die anfängliche Anforderung wählt der Lastenausgleichsmotor einen zufälligen XSP aus. XSP gibt einen Cookie zurück, den die Webex-App in zukünftigen Anforderungen enthält. Für zukünftige Anfragen verwendet der Load Balancer das Cookie, um die Verbindung zum richtigen XSP weiterzuleiten, um sicherzustellen, dass der Event-Kanal nicht bricht.

DMS-URL

Während des Anmeldevorgangs ruft die Webex-App auch die DMS-URL ab, um die Konfigurationsdatei herunterzuladen. Der Host in der URL wird geparst, und die Webex-App führt eine DNS A/AAAA-Suche des Hosts durch, um eine Verbindung mit dem XSP herzustellen, der den DMS-Dienst hostet.

Beispiel: DNS A-Datensatz für die Entdeckung von Round-Robin ausgewogenen internetbasierten XSP-Server/Load Balancers durch die Webex-App zum Herunterladen von Konfigurationsdateien über DMS:

So findet die Webex-App XSP-Adressen

Der Client versucht, die XSP-Knoten mit dem folgenden DNS-Flow zu lokalisieren:

1. Der Client ruft anfänglich Xsi-Actions/Xsi-Events-URLs aus der Webex Cloud ab (Sie haben sie beim Erstellen des zugehörigen BroadWorks-Anrufclusters eingegeben). Der Xsi-Hostname/die Domäne wird über die URL analysiert, und der Client führt eine SRV-Suche wie folgt durch:

   1. Client führt eine SRV-Suche für _xsi-client durch._tcp.<xsi domain="">

   2. Wenn die SRV-Suche ein oder mehrere A/AAAA-Ziele zurückgibt:

      1. Der Client führt eine A/AAAA-Suche nach diesen Zielen durch und speichert die zurückgegebenen IP-Adressen im Zwischenspeicher.

      2. Der Client verbindet sich mit einem der Ziele (und somit seinem A/AAAA-Datensatz mit einer einzigen IP-Adresse) basierend auf der SRV-Priorität, dann der Gewichtung (oder zufällig, wenn alle gleich sind).

   3. Wenn die SRV-Suche keine Ziele zurückgibt:

      Der Client führt eine A/AAAA-Suche des Xsi-Root-Parameters durch und versucht dann, eine Verbindung mit der zurückgegebenen IP-Adresse herzustellen. Dies kann ein Edge-Element für den Lastausgleich sein oder der XSP-Server selbst.

      Wie bereits erwähnt, muss der A/AAAA-Datensatz aus den gleichen Gründen zu einer IP-Adresse aufgelöst werden.

2. (Optional) Anschließend können Sie mithilfe der folgenden Tags benutzerdefinierte XSI-Aktionen/XSI-Ereignisse in der Gerätekonfiguration für die Webex-App angeben:

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

   1. Diese Konfigurationsparameter haben Vorrang vor allen Konfigurationen in Ihrem BroadWorks-Cluster im Control Hub.

   2. Wenn sie vorhanden sind, wird der Client mit der ursprünglichen XSI-Adresse verglichen, die er über die BroadWorks-Cluster-Konfiguration erhalten hat.

   3. Wenn ein Unterschied erkannt wird, initialisiert der Client seine XSI-Aktionen/XSI-Ereignisse-Konnektivität neu. Der erste Schritt besteht darin, denselben DNS-Lookup-Prozess durchzuführen, der unter Schritt 1 aufgeführt ist – diesmal wird eine Suche nach dem Wert im %XSI_ROOT_WXT% Parameter aus seiner Konfigurationsdatei angefordert.

      Stellen Sie sicher, dass Sie die entsprechenden SRV-Datensätze erstellen, wenn Sie dieses Tag verwenden, um die Xsi-Schnittstellen zu ändern.

Failover

Während der Anmeldung führt die Webex-App eine DNS SRV-Suche nach _xsi-client._tcp.<xsi domain=""> durch, erstellt eine Liste der Hosts und stellt basierend auf der SRV-Priorität und der Gewichtung eine Verbindung zu einem der Hosts her. Dieser verbundene Host wird für alle zukünftigen Anforderungen ausgewählt. Ein Event-Kanal wird dann für den ausgewählten Gastgeber geöffnet und ein Heartbeat wird regelmäßig gesendet, um den Kanal zu überprüfen. Alle Anfragen, die nach dem ersten gesendet werden, enthalten ein Cookie, das in der HTTP-Antwort zurückgegeben wird. Daher ist es wichtig, dass der Lastenausgleichsmodule die Sitzungspersistenz (Affinität) aufrechterhält und immer Anfragen an denselben XSP-Backend-Server sendet.

Wenn eine Anforderung oder eine Heartbeat-Anforderung an einen Gastgeber fehlschlägt, können verschiedene Dinge passieren:

• Wenn der Fehler auf einem Netzwerkfehler beruht (z. B.: TCP, SSL) wechselt die Webex-App-Route sofort zum nächsten Gastgeber in der Liste.

• Wenn ein Fehlercode (HTTP5xx) zurückgegeben wird, markiert die Webex-App diese IP-Adresse als blockiert und leitet die Fortschritte an den nächsten Host in der Liste weiter.

• Wenn eine Antwort nicht innerhalb eines Zeitraums empfangen wird, wird die Anforderung aufgrund einer Zeitüberschreitung als fehlgeschlagen betrachtet und die nächsten Anforderungen werden an den nächsten Gastgeber gesendet. Die Anfrage mit Zeitüberschreitung wird jedoch als fehlgeschlagen betrachtet. Einige Anfragen werden nach einem Fehler erneut versucht (mit zunehmender Wiederholungszeit). Die Anfragen, dass das angenommene Nicht-Vital nicht erneut versucht wird.

Wenn ein neuer Gastgeber erfolgreich versucht wird, wird er zum neu ausgewählten Gastgeber, wenn der Gastgeber in der Liste vorhanden ist. Nachdem der letzte Gastgeber in der Liste versucht wurde, wird die Webex-App auf den ersten verschoben.

Wenn bei einem Heartbeat zwei aufeinanderfolgende Anforderungsfehler auftreten, initialisiert die Webex-App den Event-Kanal neu.

Beachten Sie, dass die Webex-App kein Failback durchführt und die DNS-Diensterkennung nur einmal bei der Anmeldung durchgeführt wird.

Während der Anmeldung versucht die Webex-App, die Konfigurationsdatei über die XSP/Dms-Schnittstelle herunterzuladen. Es führt eine A/AAAA-Datensatzsuche des Hosts in der abgerufenen DMS-URL durch und stellt eine Verbindung zur ersten IP her. Es wird zuerst versuchen, die Anforderung zum Herunterladen der Konfigurationsdatei mit einem SSO-Token zu senden. Wenn dies aus irgendeinem Grund fehlschlägt, wird es erneut versuchen, jedoch mit dem Benutzernamen und dem Kennwort des Geräts.