Förbered din miljö

Broadworks XSP:er kan distribueras direkt på Internet, eller kan finnas i en DMZ som fronteras av en belastningsutjämning som F5 BIG-IP. För att tillhandahålla geo-redundans kan XSP:erna distribueras i två (eller flera) datacenter, var och en kan fronteras av en belastningsutjämning, var och en har en offentlig IP-adress. Om XSP:erna ligger bakom en belastningsutjämning ser Webex mikrotjänster och appen endast IP-adressen för belastningsutjänaren och Broadworks verkar ha bara en XSP, även om det finns flera XSP:er bakom.

I exemplet nedan distribueras XSP:erna på två webbplatser, Webbplats A och Webbplats B. Det finns två XSP:er som fronteras av en belastningsutjämning på varje plats. Plats A har XSP1 och XSP2 fronteras av LB1, och plats B har XSP3 och XSP4 fronteras av LB2. Endast belastningsutjämnarna exponeras i det offentliga nätverket och XSP:erna finns i DMZ privata nätverk.

DNS-konfiguration

Webex Cloud-mikrotjänsterna måste kunna hitta Broadworks XSP-servrar för anslutning till Xsi-gränssnitten, autentiseringstjänsten och CTI.

Webex Cloud-mikrotjänster utför DNS A/AAAA-sökning av det konfigurerade XSP-värdnamnet och ansluter till den returnerade IP-adressen. Detta kan vara en belastningsutjämning, eller så kan det vara själva XSP-servern. Om flera IP-adresser returneras väljs den första IP-adressen i listan. SRV-sökning stöds för närvarande inte.

Exempel: Partnerns DNS A-post för upptäckt av Round-Robin-balanserade XSP-server/Load Balancers.

Redogörelse

När Webex-mikrotjänsterna skickar en begäran till XSP/Load Balancer och begäran misslyckas kan flera saker hända:

• Om felet beror på ett nätverksfel (t.ex.: TCP, SSL) markerar Webex-mikrotjänsterna IP som blockerad och utför omedelbart en dirigeringsförskjutning till nästa IP.

• Om en felkod (HTTP 5xx) returneras markerar Webex-mikrotjänsterna IP-adressen som blockerad och utför omedelbart en dirigering till nästa IP-adress.

• Om inget HTTP-svar tas emot inom 2 sekunder går begäran ut och Webex-mikrotjänsterna markerar IP-adressen som blockerad och utför en dirigering till nästa IP.

Varje begäran prövas 3 gånger innan ett fel rapporteras till mikrotjänsten.

När en IP finns i den blockerade listan kommer den inte att finnas med i listan över adresser som ska prövas när en begäran skickas till en XSP. Efter en förutbestämd tidsperiod upphör en blockerad IP-adress och går tillbaka i listan för att försöka när en annan begäran görs.

Om alla IP-adresser är blockerade kommer mikrotjänsten fortfarande att försöka skicka begäran genom att slumpmässigt välja en IP-adress från den blockerade listan. Om detta lyckas tas IP-adressen bort från den blockerade listan.

Status

Statusen för anslutningen av Webex Cloud-tjänsterna till XSP:er eller belastningsutjämnare kan visas i Control Hub. Under ett BroadWorks Calling Cluster visas en anslutningsstatus för vart och ett av dessa gränssnitt:

• XSI Actions

• XSI Events

• Verifieringstjänst

Anslutningsstatusen uppdateras när sidan läses in eller under inmatningsuppdateringar. Anslutningsstatusen kan vara:

• Grön: När gränssnittet kan nås på en av IP:erna i A-inspelningen.

• Rött: När alla IP-adresser i en inspelningssökning inte kan nås och gränssnittet inte är tillgängligt.

Följande tjänster använder mikrotjänsterna för att ansluta till XSP:er och påverkas av XSP-gränssnittets tillgänglighet:

• Inloggning för Webex-appen

• Uppdatering av token för Webex-appen

• Obetrodd e-post/självaktivering

• Hälsokontroll för Broadworks-tjänsten

DNS-konfiguration

Webex-appen får åtkomst till tjänsterna Xtended Services Interface (XSI-Actions och XSI-Events) och Device Management Service (DMS) på XSP.

För att hitta XSI-tjänsten utför Webex-appen DNS SRV-sökning efter _xsi-client._tcp.<webex app xsi domain>. SRV pekar på den konfigurerade URL:en för XSP-värdar eller belastningsutjämnare för XSI-tjänsten. Om SRV-sökning inte är tillgänglig faller Webex-appen tillbaka till A/AAAA-sökning.

SRV kan lösa sig till flera A/AAAA-mål. Varje A/AAAA-post måste dock endast mappas till en enda IP-adress. Om det finns flera XSP:er i en DMZ bakom lastbalansaren/kanten-enheten måste belastningsbalansaren konfigureras för att upprätthålla sessionens varaktighet för att dirigera alla förfrågningar från samma session till samma XSP. Vi skickar den här konfigurationen eftersom klientens XSI-händelsehjärtslag måste gå till samma XSP som används för att etablera händelsekanalen.

I exempel 1 finns inte A/AAAA-posten för webex-app-xsp.example.com och behöver inte det. Om ditt DNS kräver att en A/AAAA-post måste definieras ska endast 1 IP-adress returneras. Trots detta måste SRV fortfarande definieras för Webex-appen. Om Webex-appen använder A/AAAA-namnet som löser sig till mer än en IP-adress, eller om belastningsbalansaren/kanten-elementet inte upprätthåller sessionens varaktighet, skickar klienten så småningom hjärtslag till en XSP där den inte upprättade en händelsekanal. Detta resulterar i att kanalen rivs ner och även i betydligt mer intern trafik som försämrar din XSP-klusterprestanda. Eftersom Webex Cloud och Webex-appen har olika krav i A/AAAA-inspelningssökning måste du använda en separat FQDN för Webex Cloud och Webex-appen för att komma åt dina XSP:er. Som visas i exemplen använder Webex Cloud A-post webex-cloud-xsp.example.com, och Webex-appen använder SRV _xsi-client._tcp.webex-app-xsp.example.com.

Exempel 1 – Flera XSP:er, var och en bakom separata belastningsbalanser

I det här exemplet pekar SRV på att multiplicera A-poster med varje A-post som pekar på en annan laddningsbalanserare på en annan plats. Webex-appen kommer alltid att använda den första IP-adressen i listan och flyttas bara till nästa post om den första är nere.

Exempel 2 – Flera XSP:er bakom en enda laddningsbalk (med TLS-brygga)

För den första begäran väljer lastbalansaren en slumpmässig XSP. Att XSP returnerar en cookie som Webex-appen inkluderar i framtida förfrågningar. För framtida förfrågningar använder lastbalansaren kakan för att dirigera anslutningen till rätt XSP, vilket säkerställer att händelsekanalen inte bryts.

DMS-URL

Under inloggningsprocessen hämtar Webex-appen även DMS-URL:en för att hämta konfigurationsfilen. Värden i URL:en blockeras och Webex-appen utför DNS A/AAAA-sökning av värden för att ansluta till XSP som är värd för DMS-tjänsten.

Exempel: DNS A-post för upptäckt av Round-Robin-balanserade XSP-server/laddningsbalanserare med Webex-appen för att hämta konfigurationsfiler via DMS:

Så här hittar Webex-appen XSP-adresser

Klienten försöker hitta XSP-noderna med hjälp av följande DNS-flöde:

1. Klienten hämtar ursprungligen URL:er för Xsi-Actions/Xsi-Events från Webex Cloud (du angav dem när du skapade det associerade BroadWorks Calling Cluster). Xsi-värdnamnet/domänen pariseras från URL:en och klienten utför SRV-sökning enligt följande:

   1. Klienten utför en SRV-sökning efter _xsi-klient._tcp.<xsi domain="">

   2. Om SRV-sökningen returnerar ett eller flera A/AAAA-mål:

      1. Klienten söker A/AAAA efter dessa mål och cachelagring av de returnerade IP-adresserna.

      2. Klienten ansluter till ett av målen (och därmed dess A/AAAA-post med en enda IP-adress) baserat på SRV-prioritet och sedan vikt (eller slumpmässigt om alla är lika).

   3. Om SRV-sökningen inte returnerar några mål:

      Klienten söker A/AAAA upp Xsi-rotparametern och försöker sedan ansluta till den returnerade IP-adressen. Detta kan vara en belastningsutjämning, eller så kan det vara själva XSP-servern.

      Som noterat måste A/AAAA-posten lösas till en IP-adress av samma skäl.

2. (Valfritt) Du kan därefter ange anpassade uppgifter om XSI-åtgärder/XSI-Events i enhetskonfigurationen för Webex-appen med följande taggar:

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

   1. Dessa konfigurationsparametrar har företräde framför alla konfigurationer i ditt BroadWorks-kluster i Control Hub.

   2. Om de finns kommer klienten att jämföra med den ursprungliga XSI-adressen som den fick via konfigurationen av BroadWorks Cluster.

   3. Om det upptäcks någon skillnad kommer klienten att initiera anslutningen för XSI-åtgärder/XSI Events. Det första steget i detta är att utföra samma DNS-sökprocess som anges i steg 1 – den här gången begär du en sökning efter värdet i %XSI_ROOT_WXT% parametern från dess konfigurationsfil.

      Se till att skapa motsvarande SRV-poster om du använder den här taggen för att ändra Xsi-gränssnitten.

Redogörelse

Under inloggning utför Webex-appen en DNS SRV-sökning efter _xsi-klient._tcp.<xsi domain="">, bygger en lista över värdar och ansluter till en av värdarna baserat på SRV-prioriteten och sedan vikt. Den här anslutna värden blir den valda för alla framtida förfrågningar. En händelsekanal öppnas sedan för den valda värden och ett hjärtslag skickas regelbundet för att verifiera kanalen. Alla förfrågningar som skickas efter den första innehåller en cookie som returneras i HTTP-svaret, därför är det viktigt att belastningsbalansaren behåller sessionens varaktighet (affinitet) och alltid skickar förfrågningar till samma backend-XSP-server.

Om en begäran eller en begäran om hjärtslag till en värd misslyckas kan flera saker hända:

• Om felet beror på nätverksfel (t.ex.: TCP, SSL) går Webex-appens dirigering direkt vidare till nästa värd i listan.

• Om en felkod (HTTP 5xx) returneras markerar Webex-appen IP-adressen som blockerad och dirigerar vidare till nästa värd i listan.

• Om ett svar inte tas emot inom en tidsperiod anses begäran misslyckad på grund av timeout och nästa begäran skickas till nästa värd. Begäran om tidsgräns anses dock misslyckad. Vissa förfrågningar prövas på nytt efter misslyckande (med ökande återprovningstid). Begäran om att det som antas inte är vitala prövas inte på nytt.

När en ny värd har testats blir den den nya valda värden om värden finns i listan. När den sista värden i listan har testats kommer Webex-appen att rullas över till den första.

Vid hjärtslag initierar Webex-appen händelsekanalen om det finns två på varandra följande misslyckanden.

Observera att Webex-appen inte utför återställning och DNS-tjänstens identifiering utförs endast en gång vid inloggningen.

Under inloggningen försöker Webex-appen hämta konfigurationsfilen via XSP/Dms-gränssnittet. Den utför en A/AAAA-inspektion av värden i den hämtade DMS-URL:en och ansluter till den första IP-adressen. Den försöker först skicka begäran om att hämta konfigurationsfilen med en SSO-token. Om detta misslyckas av någon anledning kommer det att försöka igen, men med enhetens användarnamn och lösenord.