Forbered miljøet ditt

Broadworks XSP-er kan distribueres direkte på Internett, eller de kan ligge i en DMZ frontet av et belastningsfordeling , for eksempel F5 BIG-IP. For å gi geografisk redundans kan XSP-ene distribueres i to (eller flere) datasentre, som hver kan frontes av en lastbalanserer, som hver har en offentlig IP-adresse. Hvis XSP-ene er bak en lastbalanserer, ser Webex-mikrotjenestene og appen bare IP-adresse til lastbalanseren, og Broadworks ser ut til å bare ha én XSP, selv om det er flere XSP-er bak.

I eksemplet nedenfor er XSP-ene distribuert på to steder, nettsted A og nettsted B. Det finnes to XSP-er frontet av en belastningsbalanserer på hvert nettsted. Nettsted A har XSP1 og XSP2 frontet av LB1, og nettsted B har XSP3 og XSP4 frontet av LB2. Bare belastningsbalanserne er eksponert på det offentlige nettverket, og XSP-ene er i de private DMZ-nettverkene.

DNS-konfigurasjon

Webex Cloud mikrotjenestene må kunne finne Broadworks XSP-serveren(e) for tilkobling til Xsi-grensesnittene, autentiseringstjenesten og CTI.

Webex Cloud mikrotjenester vil utføre DNS A/AAAA-oppslag av det konfigurerte XSP-vertsnavnet og koble til den returnerte IP-adressen. Dette kan være et kantelement for belastningsfordeling , eller det kan være selve XSP-serveren. Hvis det returneres flere IP-adresser, velges den første IP-adressen på listen. SRV-oppslag støttes for øyeblikket ikke.

Eksempel: Partnerens DNS En oppføring for oppdagelse av Round-Robin balansert internettvendt XSP-server/belastningsbalansere.

Failover

Når Webex-mikrotjenestene sender en forespørsel til XSP/Load Balancer og forespørselen mislykkes, kan flere ting skje:

• Hvis feilen skyldes en nettverksfeil (f.eks.: TCP, SSL), merker Webex-mikrotjenestene IP-en som blokkert og utfører umiddelbart en ruteforflytning til neste IP-adresse.

• Hvis en feilkode (HTTP5xx ) returneres, merker Webex-mikrotjenestene IP-en som blokkert og utfører umiddelbart en videreføring av ruten til neste IP-adresse.

• Hvis det ikke mottas noe HTTP-svar i løpet av to sekunder, vil forespørselen bli tidsavbrutt, og Webex-mikrotjenestene markerer IP-en som blokkert og utfører en ruteforflytning til neste IP-adresse.

Hver forespørsel prøves 3 ganger før en feil rapporteres tilbake til mikrotjenesten.

Når en IP-adresse er i blokkeringslisten, blir den ikke inkludert i listen over adresser som skal prøves når du sender en forespørsel til en XSP. Etter en forhåndsbestemt tidsperiode utløper en blokkert IP-adresse og går tilbake i listen for å prøve når en annen forespørsel sendes.

Hvis alle IP-adresser er blokkert, vil mikrotjenesten likevel prøve å sende forespørselen ved å tilfeldig velge en IP-adresse fra blokkeringslisten. Hvis det lykkes, fjernes denne IP-adresse fra blokkeringslisten.

Status

Statusen for tilkoblingen til Webex Cloud tjenestene til XSP-ene eller belastningsbalanserne kan ses i Control Hub. Under en BroadWorks-samtaleklynge vises en tilkoblingsstatus for hvert av disse grensesnittene:

• XSI Actions

• XSI Events

• Autentiseringstjeneste

tilkoblingsstatus oppdateres når siden lastes inn eller under inndataoppdateringer. Tilkoblingsstatusene kan være:

• Grønn: Når grensesnittet kan nås på en av IP-ene i A-oppslagsoppslag.

• Rød: Når alle IP-adressene i A-oppslagsoppslaget ikke er tilgjengelige og grensesnittet ikke er tilgjengelig.

Følgende tjenester bruker mikrotjenestene til å koble til XSP-ene og påvirkes av XSP-grensesnittets tilgjengelighet:

• Innlogging for Webex-app

• Oppdatering av Webex-apptoken

• Uklarert e-post/egenaktivering

• Helsesjekk av Broadworks-tjenesten

DNS-konfigurasjon

Webex-appen får tilgang til Xtended Services Interface (XSI-Actions & XSI-Events) og Device Management Service (DMS) på XSP.

For å finne XSI-tjenesten utfører Webex-appen DNS SRV-oppslag etter _xsi-client._tcp.<webex app xsi domain>. SRV-en peker til den konfigurerte URL-adressen for XSP-vertene eller lastbalanserne for XSI-tjenesten. Hvis SRV-oppslag ikke er tilgjengelig, faller Webex-appen tilbake til A/AAAA-oppslag.

SRV-en kan løse til flere A/AAAA-mål. Hver A/AAAA-oppføring må imidlertid bare tilordnes én enkelt IP-adresse . Hvis det er flere XSP-er i en DMZ bak lastbalanseren/edge-enheten, kreves det at lastbalanseren konfigureres til å opprettholde øktvarighet for å rute alle forespørsler fra den samme økten til den samme XSP. Vi gir fullmakt til denne konfigurasjonen fordi klientens XSI-event-hjerteslag må gå til den samme XSP-en som brukes til å etablere hendelseskanalen.

I eksempel 1 finnes ikke og trenger ikke A/AAAA-oppføringen for webex-app-xsp.example.com. Hvis DNS-en krever at én A/AAAA-oppføring må defineres, skal bare én IP-adresse returneres. Uansett må SRV-en fortsatt være definert for Webex-appen. Hvis Webex-appen bruker A/AAAA-navnet som løses til mer enn én IP-adresse, eller hvis lastbalanseren/edge-elementet ikke opprettholder øktvarighet, sender klienten til slutt hjerteslag til en XSP der den ikke opprettet en hendelseskanal. Dette resulterer i at kanalen blir revet ned, og også i betydelig mer intern trafikk som svekker XSP-klyngeytelsen din. Siden Webex Cloud og Webex-appen har forskjellige krav i A/AAAA-oppslagsoppslag, må du bruke et eget FQDN for Webex Cloud og Webex-appen for å få tilgang til XSP-ene. Som vist i eksemplene, bruker Webex Cloud en A-oppføring webex-cloud-xsp.example.com, og Webex-appen bruker SRV _xsi-client._tcp.webex-app-xsp.example.com.

Eksempel 1 – Flere XSP-er, hver bak separate lastbalansere

I dette eksemplet peker SRV-en til flere A-oppføringer, der hver A-oppføring peker til en annen lastbalanserer på et annet sted. Webex-appen bruker alltid den første IP-adresse i listen og flyttes bare til neste oppføring hvis den første er nede.

Eksempel 2 – Flere XSP-er bak én enkelt lastbalanserer (med TLS Bridge)

For den første forespørselen velger lastbalanseren en tilfeldig XSP. At XSP returnerer en informasjonskapsel som Webex-appen inkluderer i fremtidige forespørsler. For fremtidige forespørsler bruker lastbalanseren informasjonskapselen til å rute tilkoblingen til riktig XSP, og sikrer at hendelseskanalen ikke brytes.

DMS-URL

Under påloggingsprosessen vil Webex-appen også hente DMS-URL-en for å laste ned konfigurasjonsfilen. Verten i URL-adressen blir analysert, og Webex-appen vil utføre DNS A/AAAA-oppslag av verten for å koble til XSP-en som er vert for DMS-tjenesten.

Eksempel: DNS En oppføring for oppdagelse av Round-Robin balansert internettvendt XSP-server/lastbalansere fra Webex-appen for å laste ned konfigurasjonsfiler via DMS:

Hvordan Webex-appen finner XSP-adresser

Klienten prøver å finne XSP-nodene ved hjelp av følgende DNS-flyt:

1. Klienten henter først Xsi-Actions/Xsi-Events-URL-er fra Webex Cloud (du anga dem da du opprettet den tilknyttede BroadWorks-anropsklyngen). Xsi-vertsnavnet/-domenet analyseres fra URL-adressen, og klienten utfører SRV-oppslag på følgende måte:

   1. Klienten utfører et SRV-oppslag for_xsi -klient._tcp .<xsi domain="">

   2. Hvis SRV-oppslaget returnerer ett eller flere A/AAAA-mål:

      1. Klienten gjør A/AAAA-oppslag for disse målene og hurtigbufrer de returnerte IP-adressene.

      2. Klienten kobler seg til et av målene (og dermed A/AAAA-oppføringen med én enkelt IP-adresse) basert på SRV-prioriteten og deretter vekten (eller tilfeldig hvis de alle er like).

   3. Hvis SRV-oppslaget ikke returnerer noen mål:

      Klienten foretar A/AAAA-oppslag av Xsi-rotparameteren og prøver deretter å koble til den returnerte IP-adresse. Dette kan være et kantelement for belastningsfordeling , eller det kan være selve XSP-serveren.

      Som nevnt, A/AAAA-oppføringen må løses til én IP-adresse av de samme grunnene.

2. (Valgfritt) Du kan deretter oppgi egendefinerte XSI-Actions/XSI-Events-detaljer i enhetskonfigurasjon for Webex-app, ved hjelp av følgende koder:

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

   1. Disse konfigurasjonsparametrene har forrang over alle konfigurasjoner i BroadWorks-klyngen i Control Hub.

   2. Hvis de finnes, vil klienten sammenligne med den opprinnelige XSI-adressen den mottok via BroadWorks-klyngekonfigurasjonen.

   3. Hvis det oppdages en forskjell, vil klienten initialisere XSI Actions/XSI Events-tilkoblingen på nytt. Det første trinnet i dette er å utføre den samme DNS-oppslagsprosessen som er oppført under trinn 1 – denne gangen ved å be om et oppslag for verdien i%XSI_ROOT_WXT% parameter fra konfigurasjonsfil.

      Sørg for å opprette de tilsvarende SRV-registreringer hvis du bruker denne taggen til å endre Xsi-grensesnittene.

Failover

Under pålogging utfører Webex-appen et DNS SRV-oppslag etter_xsi -klient._tcp .<xsi domain=""> , bygger en liste over verter og kobler til en av vertene basert på SRV-prioriteten, og deretter vekt. Denne tilkoblede verten blir valgt for alle fremtidige forespørsler. En hendelseskanal åpnes deretter for den valgte verten, og et hjerteslag sendes regelmessig for å bekrefte kanalen. Alle forespørsler som sendes etter den første, inkluderer en informasjonskapsel som returneres i HTTP-svaret, og derfor er det viktig at lastbalanseren beholder øktpersistens (tilhørighet) og alltid sender forespørsler til den samme XSP-serveren.

Hvis en forespørsel eller en hjerteslagforespørsel til en vert mislykkes, kan flere ting skje:

• Hvis feilen skyldes nettverksfeil (f.eks.: TCP, SSL), går Webex-appruten umiddelbart videre til neste vert på listen.

• Hvis en feilkode (HTTP5xx ) returneres, merker Webex-appen denne IP-adresse som blokkert, og ruten går videre til neste vert på listen.

• Hvis det ikke mottas svar innen en viss tid, anses forespørselen som mislykket på grunn av tidsavbrudd, og de neste forespørslene sendes til neste vert. Forespørselen med tidsavbrudd anses imidlertid som mislykket. Noen forespørsler prøves på nytt etter feil (med økende forsøkstid). Forespørslene om at de antatte ikke-vitale ikke prøves på nytt.

Når en ny vert er forsøkt vellykket, blir den den nye valgte verten hvis verten er til stede i listen. Når den siste verten på listen er prøvd, overføres Webex-appen til den første.

Når det gjelder hjerteslag, hvis det er to etterfølgende forespørselsfeil, initialiserer Webex-appen hendelseskanalen på nytt.

Merk at Webex-appen ikke utfører fail-back, og at DNS-tjenesteoppdaging kun utføres én gang ved pålogging.

Under pålogging prøver Webex-appen å laste ned konfigurasjonsfilen via XSP/Dms-grensesnittet. Den utfører et A/AAAA-oppslagsoppslag av verten i den hentede DMS-URL-en og kobler til den første IP-adressen. Den vil først prøve å sende forespørselen om å laste ned konfigurasjonsfilen ved hjelp av et SSO-token. Hvis dette mislykkes av en eller annen grunn, vil det prøve på nytt, men med enhetens brukernavn og passord.