Les XSP Broadworks peuvent être déployés directement sur Internet, ou résider dans une DMZ face à un élément de équilibrage de charge tel que le F5 BIG-IP. Pour fournir une redondance géographique, les XSP peuvent être déployés dans deux centres de données (ou plus), chacun d’eux peut être face à un chargeur de charge, chacun ayant une adresse IP publique. Si les XSP sont derrière un chargeur de charge, les microservices et l’application Webex ne voient que l’adresse IP du solde de charge et Broadworks semble avoir un seul XSP, même s’il y a plusieurs XSP derrière.

Dans l’exemple ci-dessous, les XSP sont déployés sur deux sites, le site A et le site B. Il y a deux XSP face à un chargeur de chaque site. Le site A a XSP1 et XSP2 face à LB1 et le site B a XSP3 et XSP4 face à LB2. Seuls les équilibreurs de charge sont exposé sur le réseau public et les XSP se sont dans les réseaux privés DMZ.

Configuration DNS

Les microservices du Cloud Webex doivent pouvoir trouver le(s) serveur(s) Broadworks XSP pour se connecter aux interfaces Xsi, au service d’authentification et à CTI.

Cisco Webex microservices Cloud effectueront la recherche DNS A/AAAA du nom d’hôte XSP configuré et se connectera à l’adresse IP renvoyée. Il peut s’agit d’un élément de l’edge de équilibrage de charge, ou il peut s’agit du serveur XSP lui-même. Si plusieurs adresses IP sont renvoyées, la première IP de la liste sera sélectionnée. SRV recherche ne sont actuellement pas pris en charge.

Exemple : Enregistrement DNS A du partenaire pour la découverte de serveurs XSP avec un serveur/balance de charges arrondis à l’autre

Basculement

Lorsque les microservices Webex envoient une demande au serveur de balance des charges XSP et que la demande échoue, plusieurs choses peuvent se produire :

• Si la panne est due à une erreur réseau (ex. : TCP, SSL), les microservices Webex marquent l’IP comme bloquée et effectuent immédiatement une avance de route vers l’IP suivante.

• Si un code d’erreur (HTTP 5xx) est renvoyé, les microservices Webex marquent l’IP comme bloqué et effectuent une avance immédiate de route vers l’IP suivante.

• Si aucune réponse HTTP n’est reçue dans les 2 secondes, la demande s’exécute et les microservices Webex marquent l’IP comme bloquée et effectuent une avance de route vers l’IP suivante.

Chaque demande est tentée trois fois avant qu’une défaillance ne soit à nouveau signalée au microservice.

Lorsqu’une IP se trouve dans la liste des adresses bloquées, elle ne sera pas incluse dans la liste des adresses à essayer lors de l’envoi d’une demande à un XSP. Après une période prédéterminée, une IP bloquée expire et revient dans la liste pour essayer lorsqu’une autre demande est fait.

Si toutes les adresses IP sont bloquées, le microservice tentera quand même d’envoyer la demande en sélectionnant aléatoirement une adresse IP dans la liste bloquée. Si la réussite est, cette adresse IP est supprimée de la liste bloquée.

Statut

Le statut de la connectivité des services Webex du Cloud aux XSP ou aux chargeurs de charge peut être vu dans Control Hub. Sous un cluster d’appel BroadWorks, un statut de connexion est affiché pour chacune de ces interfaces :

• XSI Actions

• XSI Events

• Service d’authentification

Le statut de la connexion est mis à jour lorsque la page est chargée ou pendant les mises à jour de saisie. Les statuts des connexions peuvent être :

• Vert: Lorsque l’interface peut être atteinte sur l’un des IP dans la recherche d’enregistrement A.

• Rouge: Lorsque toutes les IP de la recherche d’enregistrement sont inaccessibles et que l’interface est indisponible.

Les services suivants utilisent les microservices pour se connecter aux XSP et sont impactés par la disponibilité de l’interface XSP :

• Connexion à l’application Webex

• Actualisation du jeton de l’application Webex

• Adresse électronique/activation automatique non confiance

• Vérification de l’état du service Broadworks

Configuration DNS

L’application Webex accède aux services Xtended Services Interface (XSI-Actions & XSI-Events) et les services de l’Service de gestion de périphérique (DMS) sur le XSP.

Il effectuera la recherche SRV DNS pour _xsi-client._tcp.<xsi domain> de l’URL configurée pour trouver les hôtes XSP ou les serveurs de charge pour le service XSI.

Vous trouverez ci-dessous un exemple d’enregistrements SRV’enregistrement.

Chaque enregistrement A/AAAA doit être mapé sur une adresse IP. S’il y a plusieurs XSP dans une DMZ derrière le périphérique de solde de charge/edge, il est obligatoire que le soldeur de charge soit configuré pour maintenir la sollicitation de la session pour que toutes les demandes de la même session soient acheminées vers le même XSP. Nous mandateons cette configuration car les pulsations XSI de l’événement du client doivent aller sur le même XSP que celui utilisé pour établir la chaine de l’événement. Si vous mappés le nom A/AAAA à plus d’une adresse IP, ou si l’élément de balanceur/edge de la charge ne maintient pas la lourdeur de la session, le client envoie éventuellement des pulsations à un XSP où il n’a pas établi de chaine d’événements. Ceci entraîne la panne du canal, mais aussi un trafic beaucoup plus interne qui affecte la performance de votre cluster XSP.

Pendant le processus de connexion, l’application Webex va également récupérer l’URL DMS pour télécharger le fichier de sa config. L’hôte dans l’URL effectuera une parsage et l’application Webex effectuera la recherche DNS A/AAAA de l’hôte pour se connecter au XSP qui héberge le service DMS.

Exemple : Enregistrement DNS A pour la découverte de serveurs XSP internet/balanceurs de charge arrondis par l’application Webex pour télécharger les fichiers de config via DMS :

Comment l’application Webex trouve les adresses XSP

Le client tente de localiser les nodes XSP en utilisant le flux DNS suivant :

1. Le client récupère initialement les URL Xsi-Actions/Xsi-Events de Cisco Webex cloud (que vous avez saisies lors de la création du cluster d’appel BroadWorks associé). Le nom d’hôte/domaine Xsi est parsé à partir de l’URL et le client effectue SRV recherche comme suit :

   1. Le client effectue une recherche SRV des _xsi-client._tcp.<xsi domain="">

   2. Si la recherche SRV l’équipe renvoie une ou plusieurs cible :

      1. Le client fait une recherche A/AAAA pour ces cible et met en cache les adresses IP renvoyées.

      2. Le client se connecte à l’une des cible (et donc son enregistrement A/AAAA avec une seule adresse IP) en fonction de la priorité du SRV, puis du poids (ou aléatoire si elles sont toutes égales).

   3. Si la recherche SRV de l’équipe ne retourne aucune cible :

      Le client fait une recherche A/AAAA du paramètre racine Xsi et essaie ensuite de se connecter à l’adresse IP renvoyée. Il peut s’agit d’un élément de l’edge de équilibrage de charge, ou il peut s’agit du serveur XSP lui-même.

      Comme indiqué, l’enregistrement A/AAAA doit résoudre une adresse IP pour les mêmes raisons.

2. (Facultatif) Vous pouvez ensuite fournir des détails personnalisés sur XSI-Actions/XSI-Events dans la configuration du périphérique pour l’application Webex, en utilisant les balises suivantes :

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

   1. Ces paramètres de configuration précédentent sur toute configuration dans votre cluster BroadWorks dans Control Hub.

   2. S’ils existent, le client sera comparé à l’adresse XSI d’origine qu’elle a reçue via la configuration du groupe BroadWorks.

   3. S’il y a une différence détectée, le client va ré initialiser sa connectivité XSI Actions/XSI Events. La première étape dans ceci est d’effectuer le même processus de recherche DNS répertorié à l’étape 1 – cette fois en demandant une recherche de la valeur du paramètre %XSI_ROOT_WXT% à partir de son fichier de configuration.

      Assurez-vous de créer les enregistrements SRV graphiques si vous utilisez cette balise pour modifier les interfaces Xsi.

Basculement

Au cours de la connexion, l’application Webex effectue une recherche DNS SRV pour _xsi-client._tcp. , crée une liste d’organisateurs et se connecte à l’un des hôtes en fonction de la priorité SRV, puis par<xsi domain="">poids. Cet hôte connecté devient celui qui est sélectionné pour toutes les futures demandes. Une chaine d’événements est ensuite ouverte à l’organisateur sélectionné et une pulsation est envoyée régulièrement pour vérifier la chaine. Toutes les demandes envoyées après le premier incluent un cookie renvoyé dans la réponse HTTP. Il est donc important que le serveur de balance de charge garde la session en permanence (affinité) et envoie toujours des demandes au même serveur backend XSP.

Si une demande ou une pulsation à un organisateur échoue, plusieurs choses peuvent se produire :

• Si la panne est due à une erreur réseau (ex. : TCP, SSL), l’application Webex avance immédiatement vers l’organisateur suivant sur la liste.

• Si un code d’erreur (HTTP 5xx) est renvoyé, la demande échoue immédiatement.

• Si une réponse n’est pas reçue dans un délai donné, alors la demande est considérée comme un échec en raison du délai d’attente et les prochaines demandes sont envoyées au prochain organisateur. Cependant, la demande qui a échoué est considérée comme ina échec. Certaines demandes sont retenées après l’échec (avec l’augmentation du temps de nouvelle tentative). Les demandes que le non essentiel a pris en charge ne sont pas retriées.

Lorsqu’un nouvel organisateur a été tenté avec succès, il devient le nouvel organisateur sélectionné si l’organisateur est présent dans la liste. Lorsque le dernier organisateur de la liste a été tenté, l’application Webex est mise à jour vers le premier.

Dans le cas de pulsations, s’il y a deux échecs de demande consécutifs, l’application Webex ré initialise le canal de l’événement.

Notez que l’application Webex n’effectue pas de retour d’échec et la détection des services DNS est effectuée une seule fois au moment de la inscription.

Pendant la inscription, l’application Webex essaie de télécharger le fichier de config via l’interface XSP/Dms. Il effectue une recherche d’enregistrement A/AAAA de l’hôte dans l’URL DMS récupérée et se connecte à la première IP. Il tentera tout d’abord d’envoyer la demande de téléchargement du fichier de config en utilisant SSO de base. Si cela échoue pour une raison quelconque, il va essayer à nouveau mais avec le nom d’utilisateur et le mot de passe du périphérique.