Uw omgeving voorbereiden

De Broadworks XSP's kunnen rechtstreeks op het internet worden geïmplementeerd, of kunnen zich in een DMZ bevinden met een load balancing-element zoals de F5 BIG-IP. Om geo-redundantie te bieden, kunnen de XSP's worden geïmplementeerd in twee (of meer) datacenters, elk met een load balancer, elk met een openbaar IP-adres. Als de XSP's zich achter een load balancer bevinden, zien de Webex-microservices en -app alleen het IP-adres van de load balancer en lijkt Broadworks slechts één XSP te hebben, zelfs als er meerdere XSP's achter zitten.

In het onderstaande voorbeeld worden de XSP's geïmplementeerd op twee sites, Site A en Site B. Er zijn twee XSP's fronted by a Load Balancer op elke site. Site A heeft XSP1 en XSP2 fronted by LB1, en Site B heeft XSP3 en XSP4 fronted by LB2. Alleen de lastbalancers worden op het openbare netwerk weergegeven en de XSP's bevinden zich in de privénetwerken van DMZ.

DNS-configuratie

De microservices van de Webex-cloud moeten de Broadworks XSP-server(s) kunnen vinden om verbinding te maken met de Xsi-interfaces, de verificatieservice en CTI.

Webex Cloud-microservices voeren DNS A/AAAA-zoekopdrachten uit voor de geconfigureerde XSP-hostnaam en maken verbinding met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn, of de XSP-server zelf. Als er meerdere IP-adressen worden geretourneerd, wordt het eerste IP in de lijst geselecteerd. SRV-zoekopdrachten worden momenteel niet ondersteund.

Voorbeeld: De partner DNS A Record voor ontdekking van Round-Robin gebalanceerde internet-gerichte XSP server / Load Balancers.

Failover

Wanneer de Webex-microservices een verzoek naar de XSP/Load Balancer verzenden en het verzoek mislukt, kunnen er verschillende dingen gebeuren:

• Als de fout te wijten is aan een netwerkfout (bv.: TCP, SSL) markeren de Webex-microservices het IP als geblokkeerd en voeren ze onmiddellijk een route door naar het volgende IP.

• Als er een foutcode (HTTP 5xx) wordt geretourneerd, markeren de Webex-microservices het IP als geblokkeerd en voeren ze onmiddellijk een route door naar het volgende IP.

• Als er binnen 2 seconden geen HTTP-reactie wordt ontvangen, time-out van het verzoek en de Webex-microservices markeren het IP als geblokkeerd en voeren een route door naar het volgende IP.

Elk verzoek wordt 3 keer geprobeerd voordat een storing wordt teruggekoppeld naar de microservice.

Wanneer een IP in de geblokkeerde lijst staat, wordt het niet opgenomen in de lijst met adressen die moet worden geprobeerd bij het verzenden van een verzoek naar een XSP. Na een vooraf bepaalde tijdsperiode verloopt een geblokkeerd IP en gaat het terug naar de lijst om te proberen wanneer een ander verzoek wordt gedaan.

Als alle IP-adressen zijn geblokkeerd, probeert de microservice de aanvraag nog steeds te verzenden door willekeurig een IP-adres te selecteren in de geblokkeerde lijst. Als dit is gelukt, wordt dat IP-adres verwijderd uit de geblokkeerde lijst.

Status

De status van de verbinding van de Webex-cloudservices met de XSP's of load balancers is te zien in Control Hub. Onder een BroadWorks-gesprekscluster wordt een verbindingsstatus weergegeven voor elk van deze interfaces:

• XSI-acties

• XSI-gebeurtenissen

• Verificatieservice

De verbindingsstatus wordt bijgewerkt wanneer de pagina wordt geladen of tijdens invoerupdates. De verbindingsstatussen kunnen zijn:

• Groen: Wanneer de interface kan worden bereikt op een van de IP's in Een recordzoekopdracht.

• Rood: Wanneer alle IP's in de A-recordzoekopdracht niet bereikbaar zijn en de interface niet beschikbaar is.

De volgende services gebruiken de microservices om verbinding te maken met de XSP's en worden beïnvloed door de beschikbaarheid van de XSP-interface:

• Aanmelden bij Webex-app

• Token voor Webex-app vernieuwen

• Niet-vertrouwde e-mail/zelfactivering

• Gezondheidscontrole van Broadworks-service

DNS-configuratie

De Webex-app heeft toegang tot de services Xtended Services Interface (XSI-acties en XSI-gebeurtenissen) en Device Management Service (DMS) op de XSP.

Om de XSI-service te vinden, voert de Webex-app DNS SRV-zoekopdrachten uit voor _xsi-client._tcp.<webex app xsi domain>. De SRV verwijst naar de geconfigureerde URL voor de XSP-hosts of load balancers voor de XSI-service. Als SRV-zoekopdrachten niet beschikbaar zijn, keert de Webex-app terug naar A/AAAA-zoekopdrachten.

De SRV kan overschakelen op meerdere A/AAAA-doelen. Elke A/AAAA-record moet echter alleen naar één IP-adres worden toegewezen. Als er meerdere XSP's in een DMZ achter het load balancer/edge-apparaat zitten, moet de load balancer worden geconfigureerd om de sessiepersistentie te behouden en alle verzoeken van dezelfde sessie naar dezelfde XSP te routeren. We machtigen deze configuratie omdat de XSI-event heartbeats van de client naar dezelfde XSP moeten gaan die wordt gebruikt om het gebeurteniskanaal tot stand te brengen.

In voorbeeld 1 bestaat de A/AAAA-record voor webex-app-xsp.example.com niet en hoeft deze niet te worden gebruikt. Als uw DNS vereist dat één A/AAAA-record moet worden gedefinieerd, mag slechts 1 IP-adres worden geretourneerd. De SRV moet echter nog steeds worden gedefinieerd voor de Webex-app. Als de Webex-app de A/AAAA-naam gebruikt die wordt omgezet naar meer dan één IP-adres, of als het load balancer/edge-element geen sessiepersistentie handhaaft, verzendt de client uiteindelijk heartbeats naar een XSP waar het geen gebeurteniskanaal heeft ingesteld. Dit resulteert in het kanaal wordt afgebroken, en ook in aanzienlijk meer intern verkeer dat uw XSP cluster prestaties belemmert. Omdat de Webex-cloud en de Webex-app verschillende vereisten hebben voor het opzoeken van A/AAAA-opnamen, moet u een afzonderlijke FQDN gebruiken voor toegang tot uw XSP's voor de Webex-cloud en de Webex-app. Zoals in de voorbeelden wordt weergegeven, gebruikt Webex Cloud Een record webex-cloud-xsp.example.com en de Webex-app gebruikt SRV _xsi-client._tcp.webex-app-xsp.example.com.

Voorbeeld 1: meerdere XSP's, elk achter afzonderlijke lastbalancers

In dit voorbeeld wijst de SRV naar A-records met elk Een record die naar een andere lastbalancer op een andere locatie wijzen. De Webex-app gebruikt altijd het eerste IP-adres in de lijst en gaat alleen naar de volgende record als de eerste is uitgeschakeld.

Voorbeeld 2: meerdere XSP's achter één lastbalancer (met TLS-brug)

Voor het eerste verzoek selecteert de load balancer een willekeurige XSP. Dat XSP een cookie retourneert dat de Webex-app in toekomstige verzoeken bevat. Voor toekomstige verzoeken gebruikt de load balancer de cookie om de verbinding naar de juiste XSP te routeren, zodat het gebeurteniskanaal niet wordt verbroken.

URL DMS

Tijdens het aanmeldproces haalt de Webex-app ook de DMS-URL op om het configuratiebestand te downloaden. De host in de URL wordt geparseerd en de Webex-app voert DNS A/AAAA-zoekopdrachten uit van de host om verbinding te maken met de XSP die de DMS-service host.

Voorbeeld: DNS Een record voor het ontdekken van Round-Robin gebalanceerde internet-gerichte XSP-server/load balancers door de Webex-app om configuratiebestanden te downloaden via DMS:

Hoe de Webex-app XSP-adressen vindt

De client probeert de XSP-knooppunten te vinden met de volgende DNS-flow:

1. De client haalt aanvankelijk URL's voor Xsi-acties/Xsi-Events op uit de Webex-cloud (u hebt deze ingevoerd bij het maken van het gekoppelde BroadWorks-gesprekscluster). De Xsi-hostnaam/het Xsi-domein wordt geparseerd vanaf de URL en de client voert de SRV-zoekopdracht als volgt uit:

   1. De client voert een SRV-zoekopdracht uit voor _xsi-client._tcp.<xsi domain="">

   2. Als de SRV-zoekopdracht een of meer A/AAAA-doelen retourneert:

      1. De client zoekt A/AAAA op voor deze doelen en slaat de geretourneerde IP-adressen in de cache.

      2. De client maakt verbinding met een van de doelen (en dus de A/AAAA-record met één IP-adres) op basis van de SRV-prioriteit, vervolgens het gewicht (of willekeurig als ze allemaal gelijk zijn).

   3. Als de SRV-zoekopdracht geen doelen retourneert:

      De client zoekt A/AAAA op van de Xsi-hoofdparameter en probeert vervolgens verbinding te maken met het geretourneerde IP-adres. Dit kan een load balancing edge-element zijn, of de XSP-server zelf.

      Zoals vermeld, moet de A/AAAA-record om dezelfde redenen worden omgezet naar één IP-adres.

2. (Optioneel) U kunt vervolgens aangepaste XSI-acties/XSI-gebeurtenissen opgeven in de apparaatconfiguratie voor de Webex-app, met behulp van de volgende tags:

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

   1. Deze configuratieparameters hebben voorrang op elke configuratie in uw BroadWorks-cluster in Control Hub.

   2. Als deze bestaan, vergelijkt de client met het oorspronkelijke XSI-adres dat hij heeft ontvangen via de BroadWorks-clusterconfiguratie.

   3. Als er een verschil wordt gedetecteerd, initialiseert de client de XSI-acties/ XSI Events-verbinding opnieuw. De eerste stap hierin is om hetzelfde DNS-opzoekproces uit te voeren dat wordt vermeld onder stap 1. Dit keer wordt een zoekopdracht aangevraagd voor de waarde in de parameter %XSI_ROOT_WXT% vanuit het configuratiebestand.

      Zorg ervoor dat u de bijbehorende SRV-records maakt als u deze tag gebruikt om de Xsi-interfaces te wijzigen.

Failover

Tijdens het aanmelden voert de Webex-app een DNS SRV-zoekopdracht uit voor _xsi-client._tcp.<xsi domain="">, stelt een lijst met hosts op en maakt verbinding met een van de hosts op basis van de SRV-prioriteit en vervolgens het gewicht. Deze verbonden host wordt de geselecteerde host voor alle toekomstige aanvragen. Er wordt vervolgens een gebeurteniskanaal geopend voor de geselecteerde host en er wordt regelmatig een hartslag verzonden om het kanaal te verifiëren. Alle aanvragen die na de eerste worden verzonden, bevatten een cookie dat wordt geretourneerd in de HTTP-respons. Daarom is het belangrijk dat de load balancer de sessiepersistentie (affiniteit) behoudt en altijd aanvragen naar dezelfde backend XSP-server verzendt.

Als een verzoek of een heartbeat-verzoek aan een host mislukt, kunnen er verschillende dingen gebeuren:

• Als de fout het gevolg is van een netwerkfout (bijv. TCP, SSL) gaat de route van de Webex-app onmiddellijk door naar de volgende host in de lijst.

• Als er een foutcode (HTTP 5xx) wordt geretourneerd, markeert de Webex-app dat IP-adres als geblokkeerd en leidt deze door naar de volgende host in de lijst.

• Als er niet binnen een bepaalde periode een reactie wordt ontvangen, wordt het verzoek als mislukt beschouwd vanwege een time-out en worden de volgende verzoeken naar de volgende host verzonden. Het time-outverzoek wordt echter als mislukt beschouwd. Sommige verzoeken worden opnieuw geprobeerd na een fout (met toenemende tijd voor opnieuw proberen). De verzoeken om het veronderstelde niet-vitale niet opnieuw te proberen.

Wanneer een nieuwe host is geprobeerd, wordt deze de nieuwe geselecteerde host als de host aanwezig is in de lijst. Nadat de laatste host in de lijst is geprobeerd, rolt de Webex-app over naar de eerste.

In het geval van heartbeat, als er twee opeenvolgende mislukte verzoeken zijn, initialiseert de Webex-app het gebeurteniskanaal opnieuw.

Houd er rekening mee dat de Webex-app geen fail-back uitvoert en dat DNS-servicedetectie slechts één keer wordt uitgevoerd bij het aanmelden.

Tijdens het aanmelden probeert de Webex-app het configuratiebestand te downloaden via de XSP/Dms-interface. Het voert een A/AAAA-recordzoekopdracht uit van de host in de opgehaalde DMS-URL en maakt verbinding met het eerste IP. Eerst wordt geprobeerd het verzoek om het configuratiebestand te downloaden te verzenden met een SSO-token. Als dit om welke reden dan ook mislukt, wordt het opnieuw geprobeerd, maar wel met de gebruikersnaam en het wachtwoord van het apparaat.