Préparer votre environnement

Les XSP Broadworks peuvent être déployés directement sur Internet, ou peuvent résider dans une zone démilitarisée (DMZ) traversée par un élément de répartition 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 pouvant être précédé par un répartiteur de charge, chacun ayant une adresse IP publique. Si les XSP sont derrière un répartiteur de charge, les microservices et l’application Webex ne voient que l’adresse IP du répartiteur de charge et Broadworks semble n’avoir qu’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 frontés par un répartiteur de charge sur chaque site. Le site A a XSP1 et XSP2 fronté par LB1, et le site B a XSP3 et XSP4 fronté par LB2. Seuls les répartiteurs de charge sont exposés sur le réseau public et les XSP sont dans les réseaux privés DMZ.

Configuration DNS

Les microservices du Cloud Webex doivent être en mesure de trouver le(s) serveur(s) XSP Broadworks pour la connexion aux interfaces Xsi, au service d'authentification et au CTI.

Les microservices du Cloud Webex effectueront la recherche DNS A/AAAA du nom d'hôte XSP configuré et se connecteront à l'adresse IP renvoyée. Il peut s'agir d'un élément d'équilibrage de charge ou du serveur XSP lui-même. Si plusieurs adresses IP sont renvoyées, la première adresse IP de la liste sera sélectionnée. La recherche SRV n'est actuellement pas prise en charge.

Exemple : Le DNS du partenaire est Un Record pour la découverte de serveurs XSP équilibrés orientés Internet Round-Robin.

Basculement

Lorsque les microservices Webex envoient une demande au répartiteur de charge/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'adresse IP comme étant bloquée et effectuent immédiatement une avance de routage vers l'adresse IP suivante.

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

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

Chaque demande est testée 3 fois avant qu'une panne ne soit signalée au microservice.

Lorsqu'une adresse IP figure dans la liste bloquée, 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 de temps prédéterminée, une adresse IP bloquée expire et revient dans la liste pour essayer lorsqu'une autre demande est effectuée.

Si toutes les adresses IP sont bloquées, le microservice tentera toujours d’envoyer la demande en sélectionnant une adresse IP de manière aléatoire dans la liste bloquée. En cas de succès, cette adresse IP est supprimée de la liste bloquée.

Statut

L’état de la connectivité des services Webex Cloud aux XSP ou aux répartiteurs de charge peut être affiché dans le Control Hub. Sous un cluster d’appel BroadWorks, un état de connexion est affiché pour chacune de ces interfaces :

• Actions XSI

• Événements XSI

• Service d’authentification

L'état de la connexion est mis à jour lorsque la page est chargée ou lors des mises à jour de saisie. Les états des connexions peuvent être :

• Vert : Lorsque l'interface peut être atteinte sur l'une des adresses IP de la recherche d'enregistrement A.

• Rouge : Lorsque toutes les adresses IP de la recherche d'enregistrement A 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

• E-mail/auto-activation non fiable

• Contrôle de santé du service Broadworks

Configuration DNS

L'application Webex accède aux services Xtended Services Interface (XSI-Actions & XSI-Events) et Device Management Service (DMS) sur XSP.

Pour trouver le service XSI, l’application Webex effectue la recherche DNS SRV pour _xsi-client._tcp.<webex app xsi domain>. Le SRV pointe vers l'URL configurée pour les hôtes XSP ou les répartiteurs de charge pour le service XSI. Si la recherche SRV n’est pas disponible, l’application Webex repasse à la recherche A/AAAA.

Le SRV peut se résoudre à plusieurs cibles A/AAAA. Cependant, chaque enregistrement A/AAAA ne doit correspondre qu'à une seule adresse IP. S'il y a plusieurs XSP dans une DMZ derrière le répartiteur de charge/périphérique, il est nécessaire que le répartiteur de charge soit configuré pour maintenir la persistance de session pour acheminer toutes les demandes de la même session vers le même XSP. Nous mandatons cette configuration car les battements de cœur d'événement XSI du client doivent aller au même XSP qui est utilisé pour établir le canal d'événement.

Dans l'exemple 1, l'enregistrement A/AAAA pour webex-app-xsp.example.com n'existe pas et n'a pas besoin de le faire. Si votre DNS exige qu'un enregistrement A/AAAA soit défini, alors seulement 1 adresse IP doit être renvoyée. Quoi qu’il en soit, le SRV doit toujours être défini pour l’application Webex. Si l’application Webex utilise le nom A/AAAA qui résout plus d’une adresse IP, ou si l’élément de répartition de charge/bordure ne maintient pas la persistance de la session, le client finit par envoyer des battements à un XSP où il n’a pas établi de canal d’événement. Il en résulte un déchirement du canal et un trafic interne beaucoup plus important, ce qui nuit aux performances de votre cluster XSP. Étant donné que le Cloud Webex et l’application Webex ont des exigences différentes dans la recherche d’enregistrement A/AAAA, vous devez utiliser un FQDN distinct pour le Cloud Webex et l’application Webex pour accéder à vos XSP. Comme le montrent les exemples, le Cloud Webex utilise Un enregistrement webex-cloud-xsp.example.com, et l’application Webex utilise SRV _xsi-client._tcp.webex-app-xsp.example.com.

Exemple 1–Plusieurs XSP, chacun derrière des équilibreurs de charge distincts

Dans cet exemple, le SRV pointe vers des enregistrements A mutilés, chaque enregistrement A pointant vers un équilibreur de charge différent sur un site différent. L’application Webex utilisera toujours la première adresse IP de la liste et ne passera à l’enregistrement suivant que si le premier est en panne.

Exemple 2—Plusieurs XSP derrière un seul répartiteur de charge (avec pont TLS)

Pour la demande initiale, le répartiteur de charge sélectionne un XSP aléatoire. Ce XSP renvoie un cookie que l’application Webex inclut dans les futures demandes. Pour les demandes futures, le répartiteur de charge utilise le cookie pour acheminer la connexion vers le bon XSP, en veillant à ce que le canal de l’événement ne se rompe pas.

URL DMS

Au cours du processus de connexion, l’application Webex récupérera également l’URL DMS pour télécharger son fichier de configuration. L’hôte dans l’URL sera analysé et l’application Webex effectuera une recherche DNS A/AAAA de l’hôte pour se connecter au XSP qui héberge le service DMS.

Exemple : DNS Un enregistrement pour la découverte de Round-Robin équilibré serveur XSP orienté Internet/équilibreurs de charge par l’application Webex pour télécharger des fichiers de configuration via DMS :

Comment l’application Webex trouve les adresses XSP

Le client tente de localiser les nœuds XSP en utilisant le flux DNS suivant :

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

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

   2. Si la recherche SRV renvoie une ou plusieurs cibles A/AAAA :

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

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

   3. Si la recherche SRV ne renvoie pas de cibles :

      Le client effectue une recherche A/AAAA du paramètre racine Xsi et tente ensuite de se connecter à l'adresse IP renvoyée. Il peut s'agir d'un élément d'équilibrage de charge ou du serveur XSP lui-même.

      Comme indiqué, l'enregistrement A/AAAA doit être résolu à une adresse IP pour les mêmes raisons.

2. (Facultatif) Vous pouvez ensuite fournir des détails personnalisés 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 ont la priorité sur toute configuration dans votre cluster BroadWorks dans Control Hub.

   2. S'ils existent, le client comparera avec l'adresse XSI d'origine qu'il a reçue via la configuration du cluster BroadWorks.

   3. Si une différence est détectée, le client réinitialisera sa connectivité XSI Actions/XSI Events. La première étape consiste à effectuer le même processus de recherche DNS répertorié à l'étape 1 – cette fois-ci en demandant une recherche pour la valeur du paramètre %XSI_ROOT_WXT% à partir de son fichier de configuration.

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

Basculement

Pendant la connexion, l’application Webex effectue une recherche DNS SRV pour _xsi-client._tcp.<xsi domain="">, crée une liste d’hôtes et se connecte à l’un des hôtes en fonction de la priorité SRV, puis du poids. Cet hôte connecté devient l'hôte sélectionné pour toutes les futures demandes. Un canal d'événement est ensuite ouvert à l'organisateur sélectionné et un battement est envoyé régulièrement pour vérifier le canal. Toutes les demandes envoyées après la première incluent un cookie qui est retourné dans la réponse HTTP, par conséquent, il est important que le répartiteur de charge garde la persistance de la session (affinité) et envoie toujours les demandes au même serveur XSP backend.

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

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

• Si un code d’erreur (HTTP 5xx) est renvoyé, l’application Webex marque cette adresse IP comme étant bloquée et la route passe à l’organisateur suivant de la liste.

• Si une réponse n'est pas reçue dans un délai donné, la demande est considérée comme ayant échoué en raison d'un délai d'expiration et les demandes suivantes sont envoyées à l'organisateur suivant. Cependant, la demande expirée est considérée comme ayant échoué. Certaines demandes sont retentées après échec (avec un temps de nouvelle tentative croissant). Les demandes que les non-vitaux supposés ne sont pas retentées.

Lorsqu'un nouvel organisateur est essayé 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é essayé, l’application Webex passe au premier.

Dans le cas des battements de cœur, 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 en arrière et que la détection du service DNS est effectuée une seule fois lors de la connexion.

Pendant la connexion, l’application Webex tente de télécharger le fichier de configuration 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 d'abord d'envoyer la demande de téléchargement du fichier de configuration à l'aide d'un jeton SSO. Si cela échoue pour une raison quelconque, il réessaiera, mais avec le nom d'utilisateur et le mot de passe du périphérique.