Forbered dit miljø

Broadworks XSP'erne kan installeres direkte på internettet, eller kan være placeret i en DMZ-front med et belastningsbalanceringselement såsom F5 BIG-IP. For at give georedundans kan XSP'erne udrulles i to (eller flere) datacentre, hver kan være fronteret af en belastningsbalance, hver med en offentlig IP-adresse. Hvis XSP'erne er bag en belastningsbalance, ser Webex-mikrotjenesterne og -appen kun IP-adressen på belastningsbalancen, og Broadworks ser ud til at have kun én XSP, selvom der er flere XSP'er bag.

I eksemplet nedenfor installeres XSP'erne på to steder, Site A og Site B. Der er to XSP'er, der er fronteret af en belastningsbalancer på hvert websted. Site A har XSP1 og XSP2 fronteret af LB1, og site B har XSP3 og XSP4 fronteret af LB2. Det er kun belastningsbalancerne, der vises på det offentlige netværk, og XSP'erne er i DMZ'ernes private netværk.

DNS-konfiguration

Webex Cloud-mikrotjenesterne skal kunne finde Broadworks XSP-serveren(e) til at oprette forbindelse til Xsi-grænsefladerne, godkendelsestjenesten og CTI.

Webex Cloud-mikrotjenester udfører DNS A/AAAA-opslag af det konfigurerede XSP-værtsnavn og opretter forbindelse til den returnerede IP-adresse. Dette kan være et belastningsbalancerende kantelement, eller det kan være selve XSP-serveren. Hvis flere IP-adresser returneres, vælges den første IP-adresse på listen. SRV-opslag understøttes i øjeblikket ikke.

Eksempel: Partnerens DNS A-post til registrering af Round-Robin-afbalancerede internetbaserede XSP-server/belastningsbalancer.

Failover

Når Webex-mikrotjenesterne sender en anmodning til XSP/belastningsbalancen, og anmodningen mislykkes, kan der ske flere ting:

• Hvis fejlen skyldes en netværksfejl (f.eks.: TCP, SSL), markerer Webex-mikrotjenesterne IP'en som blokeret, og udfør øjeblikkeligt en ruteavancering til den næste IP.

• Hvis en fejlkode (HTTP 5xx) returneres, markerer Webex-mikrotjenesterne IP'en som blokeret og udfører øjeblikkeligt en ruteavancering til den næste IP.

• Hvis der ikke modtages et HTTP-svar inden for 2 sekunder, markerer anmodningstiderne og Webex-mikrotjenesteydelserne IP'en som blokeret og udfører en videresendelse til den næste IP.

Hver anmodning afprøves 3 gange, før en fejl rapporteres tilbage til mikrotjenesten.

Når en IP er på den blokerede liste, vil den ikke blive inkluderet på listen over adresser, der skal forsøges, når en anmodning sendes til en XSP. Efter en forudbestemt periode udløber en blokeret IP og går tilbage på listen for at prøve, når der foretages en anden anmodning.

Hvis alle IP-adresser er blokeret, vil mikrotjenesten stadig forsøge at sende anmodningen ved tilfældigt at vælge en IP-adresse fra den blokerede liste. Hvis det lykkes, fjernes denne IP-adresse fra den blokerede liste.

Status

Statussen for forbindelsen mellem Webex Cloud-tjenester til XSP'erne eller belastningsbalancerne kan ses i Control Hub. Under en Broad Works-opkaldsklynge vises en forbindelsesstatus for hver af disse grænseflader:

• XSI Actions

• XSI Events

• Godkendelsestjeneste

Forbindelsesstatussen opdateres, når siden indlæses eller under inputopdateringer. Forbindelsesstatusserne kan være:

• Grøn: Når grænsefladen kan nås på en af IP'erne i A-opslaget.

• Rød: Når alle IP'er i A-opslaget ikke kan nås, og grænsefladen er ikke tilgængelig.

Følgende tjenester bruger mikrotjenesterne til at oprette forbindelse til XSP'erne og påvirkes af tilgængeligheden af XSP-grænsefladen:

• Login til Webex-appen

• Opdatering af Webex-appens token

• Ikke-betroet e-mail/selvaktivering

• Sundhedstjek af Broadworks-tjenester

DNS-konfiguration

Webex-appen har adgang til Xtended Services Interface (XSI-Actions & XSI-Events) og Device Management Service (DMS)-tjenester på XSP.

For at finde XSI-tjenesten udfører Webex-appen DNS SRV-opslag for _xsi-client._tcp.<webex app xsi domain>. SRV peger på den konfigurerede URL-adresse for XSP-værter eller belastningsbalancer for XSI-tjenesten. Hvis SRV-opslag ikke er tilgængeligt, falder Webex-appen tilbage til A/AAAA-opslag.

SRV kan løse flere A/AAAA-mål. Hver A/AAAA-post skal dog kun knyttes til en enkelt IP-adresse. Hvis der er flere XSP'er i en DMZ bag belastningsbalancer/edge-enheden, er det nødvendigt, at belastningsbalancen konfigureres til at opretholde sessionsvedholdenhed for at dirigere alle anmodninger fra den samme session til den samme XSP. Vi har mandat til denne konfiguration, fordi klientens XSI-begivenheds hjerteslag skal gå til den samme XSP, der bruges til at oprette begivenhedskanalen.

I eksempel 1 findes A/AAAA-posten for webex-app-xsp.example.com ikke, og det behøver det ikke. Hvis din DNS kræver, at én A/AAAA-post skal defineres, skal kun 1 IP-adresse returneres. Uanset hvad skal SRV stadig være defineret for Webex-appen. Hvis Webex-appen bruger A/AAAA-navnet, der løses til mere end én IP-adresse, eller hvis belastningsbalance/edge-elementet ikke opretholder sessionens vedholdenhed, sender klienten til sidst hjerteslag til en XSP, hvor den ikke oprettede en begivenhedskanal. Dette resulterer i, at kanalen bliver revet ned, og også i betydeligt mere intern trafik, hvilket påvirker din XSP-klyngepræstation. Da Webex Cloud og Webex-appen har forskellige krav i A/AAAA-opslag, skal du bruge en separat FQDN til Webex Cloud og Webex-appen for at få adgang til dine XSP'er. Som vist i eksemplerne bruger Webex Cloud En post webex-cloud-xsp.example.com, og Webex-appen bruger SRV _xsi-client._tcp.webex-app-xsp.example.com.

Eksempel 1 – Flere XSP'er, hver bag separate belastningsbalancer

I dette eksempel peger SRV på flere A-poster, hvor hver A-post peger på en anden belastningsbalance på et andet sted. Webex-appen bruger altid den første IP-adresse på listen og flyttes kun til den næste post, hvis den første er nede.

Eksempel 2 – flere XSP'er bag en enkelt belastningsbalance (med TLS-bro)

For den indledende anmodning vælger belastningsbalancen en tilfældig XSP. At XSP returnerer en cookie, som Webex-appen indeholder i fremtidige anmodninger. For fremtidige anmodninger bruger belastningsbalancen cookien til at dirigere forbindelsen til den korrekte XSP, hvilket sikrer, at begivenhedskanalen ikke bryder.

DMS URL-ADRESSE

Under login-processen henter Webex-appen også DMS URL-adressen for at downloade konfigurationsfilen. Værten i URL-adressen parseres, og Webex-appen udfører DNS A/AAAA-opslag af værten for at oprette forbindelse til den XSP, der er vært for DMS-tjenesten.

Eksempel: DNS A-post til registrering af Round-Robin-afbalancerede internetbaserede XSP-server/belastningsbalancer af Webex-appen til at downloade konfigurationsfiler via DMS:

Sådan finder Webex-appen XSP-adresser

Klienten forsøger at finde XSP-noderne ved hjælp af følgende DNS-flow:

1. Klienten henter oprindeligt Xsi-Actions/Xsi-Events-URL-adresser fra Webex Cloud (du indtastede dem, da du oprettede den tilknyttede opkaldsklynge for brede værker). Xsi-værtsnavnet/domænet parseres fra URL-adressen, og klienten udfører SRV-opslag på følgende måde:

   1. Klienten udfører et SRV-opslag for _xsiklient._tcp.<xsi domain="">

   2. Hvis SRV-opslaget returnerer et eller flere A/AAAA-mål:

      1. Klienten foretager A/AAAA-opslag for disse mål og gemmer de returnerede IP-adresser.

      2. Klienten opretter forbindelse til et af målene (og dermed dens A/AAAA-post med en enkelt IP-adresse) baseret på SRV-prioriteten og derefter vægt (eller tilfældigt, hvis de alle er lige).

   3. Hvis SRV-opslaget ikke returnerer nogen mål:

      Klienten foretager A/AAAA-opslag af Xsi-rodparameteren og forsøger derefter at oprette forbindelse til den returnerede IP-adresse. Dette kan være et belastningsbalancerende kantelement, eller det kan være selve XSP-serveren.

      Som bemærket skal A/AAAA-posten løses til én IP-adresse af de samme årsager.

2. (Valgfri) Du kan efterfølgende angive brugerdefinerede XSI-handlinger/XSI-begivenheder i enhedskonfigurationen for Webex-appen ved hjælp af følgende 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. Disse konfigurationsparametre har forrang for enhver konfiguration i din Broad Works-klynge i Control Hub.

   2. Hvis de findes, vil klienten sammenligne med den oprindelige XSI-adresse, den modtog via konfigurationen af Broad Works-klynger.

   3. Hvis der registreres en forskel, vil klienten geninitialisere sin forbindelse til XSI-handlinger/XSI Events. Det første trin i dette er at udføre den samme DNS-opslagsproces, der er angivet under trin 1 – denne gang anmoder du om et opslag for værdien i %XSI_ROOT_WXT% parameteren fra dens konfigurationsfil.

      Sørg for at oprette de tilsvarende SRV-poster, hvis du bruger dette mærke til at ændre Xsi-grænsefladerne.

Failover

Under login udfører Webex-appen et DNS SRV-opslag for _xsi-klient._tcp.<xsi domain="">, opretter en liste over værter og opretter forbindelse til en af værterne baseret på SRV-prioriteten og derefter vægt. Denne tilsluttede vært bliver den valgte til alle fremtidige anmodninger. En begivenhedskanal åbnes derefter for den valgte vært, og der sendes regelmæssigt et hjerteslag for at bekræfte kanalen. Alle anmodninger, der sendes efter den første, omfatter en cookie, der returneres i HTTP-svaret. Det er derfor vigtigt, at belastningsbalancen holder sessionen vedvarende (affinitet) og altid sender anmodninger til den samme backend XSP-server.

Hvis en anmodning eller en anmodning om hjerteslag til en vært mislykkes, kan der ske flere ting:

• Hvis fejlen skyldes netværksfejl (f.eks.: TCP, SSL), viderestilles Webex-appens rute med det samme til den næste vært på listen.

• Hvis en fejlkode (HTTP 5xx) returneres, markerer Webex-appen, at IP-adressen er blokeret, og dirigerer videre til den næste vært på listen.

• Hvis et svar ikke modtages inden for et tidsrum, betragtes anmodningen som mislykket på grund af timeout, og de næste anmodninger sendes til den næste vært. Anmodningen om timeout anses dog for mislykket. Nogle anmodninger forsøges igen efter en fejl (med stigende forsøgstid). Anmodningerne om, at de formodede ikke-vitale bliver ikke taget op igen.

Når en ny vært forsøges, bliver den den nye valgte vært, hvis værten er til stede på listen. Når den sidste vært på listen er prøvet, ruller Webex-appen til den første.

I tilfælde af hjerteslag, hvis der er to på hinanden følgende anmodningsfejl, vil Webex-appen geninitialisere begivenhedskanalen.

Bemærk, at Webex-appen ikke udfører fejlmeddelelse, og at registrering af DNS-tjeneste kun udføres én gang ved login.

Under login forsøger Webex-appen at downloade konfigurationsfilen via XSP/Dms-grænsefladen. Den udfører et A/AAAA-opslag af værten i den hentet DMS URL-adresse og opretter forbindelse til den første IP. Den vil først forsøge at sende anmodningen om at downloade konfigurationsfilen ved hjælp af et SSO-token. Hvis dette mislykkes af en eller anden grund, vil den prøve igen, men med enhedens brugernavn og adgangskode.