Qu’est-ce qu’Expressway Cluster et comment fonctionne-t-il ?

Introduction

Ce document décrit comment les clusters Expressway sont conçus pour étendre la résilience et la capacité d’une installation Expressway.  

Informations générales

Capacité. Le cluster Expressway peut augmenter la capacité d’un déploiement Expressway d’un facteur maximum de quatre, par rapport à un seul Expressway. Les homologues Expressway d’un cluster partagent l’utilisation de la bande passante, ainsi que le routage, la zone, FindMe et d’autres configurations.

Résilience. Le cluster Expressway peut fournir une redondance lorsqu’un Expressway est en mode maintenance, ou lorsqu’il devient inaccessible en raison d’une panne de réseau ou d’alimentation, ou pour toute autre raison. Les points de terminaison peuvent s'enregistrer auprès de n'importe quel homologue d'un cluster. Si les points de terminaison perdent la connexion à leur homologue initial, ils peuvent s'enregistrer à nouveau sur un autre dans le cluster.

Spécifications

Un Expressway peut faire partie d’un groupe de six Expressways au maximum. Lorsque vous créez un cluster, vous nommez un homologue en tant que principal, à partir duquel sa configuration est répliquée aux autres homologues. Chaque homologue Expressway du cluster doit avoir les mêmes fonctionnalités de routage. Si un Expressway peut acheminer un appel vers une destination, il est supposé que tous les homologues Expressway de ce cluster peuvent acheminer un appel vers cette destination.

Capacité

Il n'y a pas de gain de capacité après quatre homologues. Ainsi, dans un cluster à six homologues par exemple, les cinquième et sixième Expressways n’ajoutent pas de capacité d’appel supplémentaire au cluster. La résilience est améliorée avec les homologues supplémentaires, mais pas la capacité.

• Pour les petites machines virtuelles (VM), le cluster est uniquement destiné à la redondance et non à l'évolutivité, et il n'y a aucun gain de capacité provenant du cluster.
• La capacité basée sur la configuration de cluster de 4 homologues est présentée dans l'image suivante :

Éléments de page importants

Conditions requises

• Connaissances de base de Secure Shell (SSH)
• Un cluster doit contenir uniquement un noeud Expressway-C ou uniquement des noeuds Expressway-E.
• Tous les homologues doivent utiliser la même version logicielle.
• Tous les homologues utilisent une plate-forme matérielle, un appareil ou une machine virtuelle (VM), avec des fonctionnalités équivalentes.
• Expressway prend en charge un délai aller-retour pouvant atteindre 80 ms.
• Le mode H323 est activé sur chaque homologue.
• Tous les homologues ont le même jeu de clés d'option installé, à l'exception des suivantes :

• Pour Video Control Server (VCS) : Licences d'appel transverses et non transverses
• Pour Expressway : Sessions multimédias
• Pour Expressway : Licences d'enregistrement du système de salle et du système de bureau

Toutes les autres clés de licence doivent être identiques sur chaque homologue.

• Il ne doit pas y avoir de traduction d'adresses de réseau (NAT) entre les homologues de cluster.

Note: Si Expressway-E utilise un contrôleur d’interface réseau unique (NIC), il doit utiliser une adresse IP publique. Si Expressway-E utilise une double carte réseau, l’interface interne doit être utilisée pour créer le cluster.

• L'adresse IP, le DNS (Domain Name Server) et le protocole NTP (Network Time Protocol) doivent être configurés. 

Connexions et ports de cluster

Configurations

Créer un nouveau cluster

1. Ouvrez l’interface Web d’Expressway.
2. Accédez à System > Clustering.
3. Saisissez les valeurs suivantes :

Note: Vous devez d'abord créer un cluster d'un homologue (principal), puis redémarrer le principal avant d'ajouter d'autres homologues. Vous pouvez ajouter d'autres homologues après avoir établi un cluster d'un.

Configuration principale : 1

Version IP du cluster : Choisissez IPv4 ou IPv6 pour qu'il corresponde au modèle d'adresse réseau.

Options du mode de vérification TLS : Permissive (par défaut) ou Enforce.

       Permissive signifie que les homologues ne valident pas les certificats les uns des autres lorsque les connexions TLS (Transport Layer Security) intra-cluster sont établies.

       L'application est plus sécurisée, mais nécessite que chaque homologue possède un certificat valide et que l'autorité de certification (AC) soit approuvée par tous les autres homologues.

Adresse de l'homologue 1 : Entrez l’adresse de cet Expressway (homologue principal). Si le mode de vérification TLS est défini sur Appliquer, vous devez entrer un nom de domaine complet (FQDN) qui correspond au nom commun (CN) ou à un autre nom de domaine (SAN) de l'objet sur le certificat de cet homologue.

4. Sélectionnez Enregistrer.
5. Redémarrez le serveur.
6. Accédez à Maintenance > Restart options, puis sélectionnez Restart et confirmez OK.
7. Validez la validité du certificat, comme indiqué dans l'image suivante :

Ajouter des homologues supplémentaires au cluster

 

Pour ajouter un homologue supplémentaire, procédez comme suit :

1. Accédez à System > Clustering sur l’Expressway principal.
2. Dans le premier champ vide, saisissez l’adresse du nouvel homologue Expressway.
3. Sélectionnez Enregistrer.
4. L'homologue 1 doit indiquer ce système. Le nouvel homologue doit indiquer Inconnu, puis avec une actualisation doit indiquer Échec parce qu'il n'a pas encore complètement rejoint le cluster.
5. Accédez à System > Clustering sur l'un des homologues subordonnés déjà dans le cluster, puis modifiez les champs suivants :
   
   
   
   
6. Répétez l'étape précédente pour chacun des homologues subordonnés déjà dans le cluster.
7. Sélectionnez Enregistrer.
8. L’Expressway déclenche une alarme de défaillance de communication de cluster. L'alarme s'efface après le redémarrage requis.
9. Redémarrez l’Expressway.
10. Après le redémarrage, patientez environ 2 minutes : il s'agit de la fréquence à laquelle la configuration est copiée à partir du serveur principal.
11. Validez l'état de la base de données de cluster.
    
    
12. Assurez-vous que la configuration est répliquée sur un homologue subordonné.

Appliquer la vérification TLS

Attention : Avant de continuer, vérifiez que vos SAN de certificat contiennent les noms de domaine complet (FQDN) qui se trouvent dans les champs d'adresse d'homologue N. Avant de continuer, vous devez afficher les messages d'état vert pour le clustering et le certificat en regard de chaque champ d'adresse.  

1. Sur l'homologue principal, définissez le mode de vérification TLS sur Appliquer.

Attention : Un avertissement s'affiche si des certificats ne sont pas valides et empêche le cluster de fonctionner correctement en mode de vérification TLS appliqué.

2. Le nouveau mode de vérification TLS se répliquera dans tout le cluster.
3. Vérifiez que le mode de vérification TLS est maintenant Appliquer l'un sur l'autre homologue.
4. Sélectionnez Enregistrer et redémarrez l'homologue principal.
5. Une fois que le pair principal est de nouveau en ligne, redémarrez chaque homologue un par un.
6. Attendez que le cluster se stabilise et vérifiez que le statut Clustering et Certificate est vert pour tous les homologues.

Modifier l'homologue principal

Note: Vous pouvez effectuer ce processus même si l'homologue principal actuel n'est pas accessible.

1. Sur le nouveau Expressway principal, accédez à System > Clustering.
2. Dans le menu déroulant Configuration primary, sélectionnez le numéro d'ID de l'entrée homologue qui indique This system.
3. Sélectionnez Enregistrer.

Note: Pendant ce processus, ignorez toutes les alarmes sur Expressway qui signalent une incompatibilité principale de cluster ou une erreur de réplication de cluster.

4. Sur tous les autres homologues Expressway, commencez par l’ancien homologue principal (s’il est encore accessible).
5. Accédez à System > Clustering.
6. Dans le menu déroulant Configuration primary, sélectionnez le numéro d’ID du nouveau Expressway principal.
7. Sélectionnez Enregistrer.
8. Vérifiez que la modification apportée à la configuration primaire a été acceptée, accédez à System > Clustering et actualisez la page.
9. Si des Expressways n’ont pas accepté la modification, répétez la même procédure.
10. Validez que l'état de la base de données de cluster est Actif.

Modifier le cluster pour utiliser des noms de domaine complet

Note: Pendant que cette procédure est exécutée, les communications entre homologues sont temporairement affectées, ce qui signifie que les alarmes persistent jusqu'à ce que les modifications soient terminées et que le cluster accepte les nouvelles adresses.

1. Connectez-vous à tous les homologues de cluster et accédez à System > Clustering.
2. Choisissez l'adresse de l'homologue qui est modifiée. il est recommandé de commencer par l'adresse de l'homologue 1.
3. Sur chaque homologue du cluster, suivez la procédure suivante :
4. Modifiez le champ d'adresse d'homologue choisi de l'adresse IP à son nom de domaine complet (FQDN).
5. Sélectionnez Enregistrer.
6. Basculez vers l'homologue identifié par l'adresse d'homologue modifiée que vous utilisez et redémarrez le serveur.
7. Attendez la résolution des alarmes de cluster transitoires.
8. Choisissez l’adresse homologue suivante à modifier, puis répétez les étapes 3 à 7.
9. Répétez cette procédure jusqu'à ce que vous ayez modifié toutes les adresses des homologues et redémarré tous les homologues.

Mappage d’adresses de cluster pour Expressway-E

Pour les déploiements sécurisés tels que Mobile and Remote Access (MRA), chaque homologue Expressway-E doit avoir un certificat avec un SAN qui contient son nom de domaine complet public. Le nom de domaine complet est mappé dans le DNS public à l’adresse IP publique de l’Expressway-E.

Note: Si vous voulez simplement regrouper des homologues Cisco Expressway-E et que vous n'avez pas besoin de vérification TLS entre eux, vous pouvez former le cluster avec les adresses IP privées des noeuds. Vous n'avez pas besoin du mappage d'adresses de cluster.

Les mappages d'adresses de cluster sont des paires FQDN : IP qui sont partagées autour du cluster, une paire pour chaque homologue. Les homologues consultent la table de mappage avant d'interroger DNS et, s'ils trouvent une correspondance, ils n'interrogent pas DNS.

Si vous choisissez d'appliquer TLS, les homologues doivent également lire les noms du champ SAN des certificats de l'autre et vérifier chaque nom par rapport au côté FQDN du mappage.

Il est fortement recommandé d'entrer les mappages sur l'homologue principal. Les mappages d'adresses se répliquent dynamiquement via le cluster. Afin de configurer le mappage d'adresses, procédez comme suit :

1. Activez System > Clustering sur l'homologue principal et modifiez le mappage d'adresse de cluster activé dans la liste déroulante On (la valeur par défaut est Off). Les champs de mappage d'adresse de cluster s'affichent.
2. Modifiez les mappages de sorte que les FQDN publics des homologues Expressway-E correspondent aux adresses IP de leurs cartes réseau internes.
3. Sélectionnez Enregistrer.

Attention : N'essayez pas d'utiliser le DNS public pour mapper les FQDN publics des homologues à leurs adresses IP privées, cette action peut rompre la connectivité externe.  

Cluster avec une carte réseau unique

Si vous souhaitez que les homologues Expressway-E d’un cluster vérifient leurs identités respectives avec des certificats, vous pouvez leur permettre d’utiliser DNS pour résoudre les noms de domaine complets des homologues de cluster à leurs adresses IP publiques. Il s’agit d’une façon parfaitement acceptable de former un cluster si les noeuds Expressway-E ont :

• Une seule carte réseau
• Aucune NAT statique configurée
• Adresses IP routables

Dépannage

Qu'est-ce qui déclenche une réinitialisation d'usine ?

Si vous effacez tous les champs d’adresse d’homologue de la page de mise en grappe et enregistrez la configuration, Expressway effectue par défaut une réinitialisation d’usine elle-même lors du prochain redémarrage. Cela signifie que toute configuration est supprimée, à l'exception de la configuration de base du réseau pour l'interface LAN1 (Local Area Network 1), qui inclut toute configuration effectuée après avoir effacé les champs et redémarré suivant.

Astuce : Si vous devez éviter la réinitialisation en usine, restaurez les champs d'adresse de l'homologue de cluster. Remplacez les adresses homologues d'origine dans le même ordre, puis enregistrez la configuration pour effacer la bannière.

La réinitialisation en usine est automatiquement déclenchée lorsque l'homologue redémarre, pour supprimer les données sensibles et la configuration du cluster. La réinitialisation efface toutes les configurations sauf les informations de base suivantes sur le réseau :

Note: Si vous utilisez l'option double carte réseau, sachez que toute configuration LAN2 est complètement supprimée par la réinitialisation.

• Les adresses IP · les comptes et mots de passe administrateur et racine
• Touches SSH
• Touches d'option
• Accès HTTPS (Hypertext Transfer Protocol Secure) activé
• Accès SSH activé

Note: À partir de la version X12.6, la réinitialisation en usine supprime du pair les paramètres du certificat du serveur, de la clé privée associée et du magasin d'approbation de l'autorité de certification. Dans les versions antérieures du logiciel Expressway, ces paramètres sont conservés.

Échec de la réinitialisation en usine

La réinitialisation d’usine peut échouer, ce qui peut se produire si l’Expressway est une nouvelle installation de l’Open Virtualization Appliance (OVA) et n’a pas été mise à niveau. 

Pour résoudre ce problème, suivez l'une des options suivantes :

• Mettez à niveau tous les noeuds vers la même version logicielle avec le fichier tar.gz. À la fin du processus de mise à niveau, redémarrez le serveur, qui déclenche ensuite la réinitialisation d'usine.
• Téléchargez le fichier tar.gz directement dans le dossier de réinitialisation d'usine avec WinSCP (/mnt/harddisk/factory-reset/). Redémarrez ensuite pour initialiser la réinitialisation d'usine ou émettez une réinitialisation d'usine à partir de l'interface de ligne de commande.

Note: Veillez à effectuer les sauvegardes appropriées avant une mise à niveau, une modification de certificat ou un avertissement de réinitialisation d'usine.

Séquence de redémarrage

Si un redémarrage du cluster ou d'un homologue est nécessaire, procédez comme suit :

1. Redémarrez l'homologue principal et attendez qu'il soit accessible via l'interface Web.
2. Validez l'état de réplication de cluster sur le principal et l'état de tous les homologues. Patientez quelques minutes, actualisez occasionnellement les interfaces Web de l'homologue.
3. Redémarrez les autres homologues, si nécessaire, un par un. À chaque fois, attendez quelques minutes après qu'il soit accessible et validez son état de réplication.

Note: Vous devrez peut-être attendre environ 5 minutes après avoir effectué des modifications de cluster avant que les homologues d’Expressway ne signalent l’état réussi.

Alarmes et avertissements

Les alarmes des erreurs de cluster sont affichées au format suivant : Erreur de réplication de cluster : (détails) la synchronisation manuelle de la configuration est requise, comme par exemple :

• Erreur de réplication de cluster : la synchronisation manuelle de la configuration est requise.
• Erreur de réplication de cluster : impossible de trouver le fichier principal ou le fichier de configuration homologue de ce subordonné, une synchronisation manuelle de la configuration est requise.
• Erreur de réplication de cluster : l'ID principal de configuration est incohérent, la synchronisation manuelle de la configuration est requise.
• Erreur de réplication de cluster : la configuration de cet homologue est en conflit avec la configuration du principal. la synchronisation manuelle de la configuration est requise.

Si un Expressway subordonné signale l’alarme mentionnée, procédez comme suit :

1. Connectez-vous en tant qu'administrateur sur une interface SSH ou une autre interface CLI.
2. Exécutez la commande suivante : xcommand ForceConfigUpdate

Note: Veillez à effectuer les sauvegardes appropriées avant une mise à niveau, une modification de certificat ou un avertissement de réinitialisation d'usine.

3. Cette commande supprime la configuration d’Expressway subordonnée, puis force celle-ci à mettre à jour sa configuration à partir de l’Expressway principal.

Si le problème persiste, il peut être lié à la clé de chiffrement par homologue de cluster. Généralement, lorsque les homologues sont mis à niveau dans le mauvais ordre, les homologues subordonnés ne sont pas synchronisés avec le principal. Donc si xcommand forceconfigupdate ne fonctionne pas, suivez la procédure suivante :

1. Connectez-vous à l'homologue principal et vérifiez qu'il est en bon état.
2. Assurez-vous que la configuration du cluster indique que cet homologue est le principal.
3. Rémettez à niveau le principal, utilisez le même paquet que celui que vous avez utilisé à l'origine pour la mise à niveau.

L'alarme de réplication s'efface après la mise à niveau et le redémarrage de l'homologue principal. Cela se produit normalement dans les dix minutes suivant le redémarrage, mais peut être jusqu'à vingt minutes après le redémarrage.

Alarmes courantes

Configuration de cluster non valide : Le mode H.323 doit être activé - le clustering utilise les communications H.323 entre homologues.

Pour effacer cette alarme, assurez-vous que le mode H.323 est activé, accédez à Configuration > Protocols > H.323.

Échec de la base de données Expressway : Contactez votre représentant de l'assistance Cisco.

Afin de dépanner ce type d'alarme, procédez comme suit :

1. Prenez un instantané du système et fournissez-le à votre représentant du support technique.
2. Supprimez l’Expressway du cluster.
3. Restaurez la base de données de cet Expressway à partir d’une sauvegarde effectuée sur cet Expressway précédemment.
4. Ajoutez l’Expressway au cluster.

Une deuxième méthode est possible si la base de données ne se rétablit pas :

1. Prenez un instantané du système et fournissez-le au centre d'assistance technique (TAC).
2. Supprimez l’Expressway du cluster.
3. Connectez-vous en tant que root et exécutez la commande suivante clusterdb_delete_and_purge_data.sh.
4. Restaurez la base de données de cet Expressway à partir d’une sauvegarde effectuée sur cet Expressway précédemment.
5. Ajoutez l’Expressway au cluster. 

Note: Veillez à effectuer les sauvegardes appropriées avant une mise à niveau, une modification de certificat ou un avertissement de réinitialisation d'usine.

Attention : clusterdb_delete_and_purge_data.sh est aussi dangereux qu'il y paraît — utilisez cette option en dernier recours.

Problèmes liés aux clés système

Note: Les informations suivantes s'appliquent à la version X14 et ultérieures.

Échec de la mise à jour des alarmes de fichier clé déclenchées sur Expressways sur un scénario de noeud unique.

Suivez la procédure suivante pour dépanner ce type d'alarme :

1. Connectez-vous en tant qu'administrateur via l'interface CLI (disponible par défaut sur SSH et via le port série sur les versions matérielles).
2. Exécutez la commande suivante : xCommand ForceSystemKeyUpdate.

Échec de la mise à jour des alarmes de fichier clé déclenchées sur Expressways dans un scénario de cluster.

Suivez la procédure suivante pour dépanner ce type d'alarme :

1. Connectez-vous au noeud en tant qu'administrateur via l'interface CLI (disponible par défaut sur SSH et via le port série sur les versions matérielles) où cette alarme n'est pas déclenchée.
2. Exécutez la commande suivante : xCommand ForceSystemKeyUpdate.

Détails des journaux

Comme toute autre connexion sur Expressway, vous pouvez activer les journaux de diagnostic, avec les dumps TCP.

Dans un état normal, la synchronisation de la base de données sur le noeud maître est affichée dans les journaux comme sortie suivante :

2020-07-21T15:16:50.321-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,321" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:50.330-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,330" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="0" 
2020-07-21T15:16:50.433-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,433" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(257)" Detail="This peer is the cluster master, local configuration has already been replicated to the other peers"
2020-07-21T15:16:50.437-05:00 expc01 replication: UTCTime="2020-07-21 20:16:50,437" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Du point de vue du noeud homologue, il s'agit de la sortie suivante :

2020-07-21T15:16:46.900-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,899" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(270)" Detail="Starting synchronisation"
2020-07-21T15:16:46.908-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,908" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationutils(750)" AlternateIPAddresses="[u'(10.15.13.15 expc01)', u'(10.15.13.16 expc02)']" ConfigurationMasterIndex="0" LocalPeerIndex="1" 
2020-07-21T15:16:46.947-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,946" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(254)" Detail="This peer is not the cluster master, local configuration is already up to date"
2020-07-21T15:16:46.950-05:00 expc02 replication: UTCTime="2020-07-21 20:16:46,950" Module="developer.replication" Level="INFO" CodeLocation="clusterconfigurationsynchroniser(336)" Detail="Synchronisation completed successfully"

Une déconnexion d'homologue est présentée dans le résultat suivant :

2020-08-12T14:57:43.353-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Processed mnesia_down event from accessible node" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,353" Module="developer.clusterdb.cdb" Level="ERROR" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Inconsistent Database" Context="from mnesia system - mnesia down" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.159.0>" Detail="Connecting database on mnesia running_partitioned_network event" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Ready to perform node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.cdb" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Running node connection transaction" Node="clusterdb@expc02.apolo.local"
2020-08-12T14:57:43.354-05:00 expc01 UTCTime="2020-08-12 19:57:43,354" Module="developer.clusterdb.synchronise" Level="WARN" Node="clusterdb@expc01.apolo.local" PID="<0.14215.425>" Detail="Failed connecting to node" Node="clusterdb@expc02.apolo.local" Reason="{ badrpc, { EXIT, { aborted, { noproc, { gen_server, call, [ kernel_safe_sup, { start_child, { dets_sup, { dets_sup, start_link,  }, permanent, 1000, supervisor, [ dets_sup ] } }, infinity ] } } } } }"
2020-08-12T14:57:43.524-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20006" UUID="0f96695e-d954-4f6f-85c1-2ef1eae6f764" Severity="warning" Detail="Cluster database communication failure: The database is unable to replicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,524"
2020-08-12T14:57:43.771-05:00 expc01 alarm: Level="WARN" Event="Alarm Raised" Id="20004" UUID="3bca6888-f622-11df-93be-07cc953d7b99" Severity="warning" Detail="Cluster communication failure: The system is unable to communicate with one or more of the cluster peers" UTCTime="2020-08-12 19:57:43,771"

2020-08-12T14:57:53.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:53,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:54.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:54,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:56.872-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:56,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Retransmit=True"
2020-08-12T14:57:57.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:57,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Retransmit=True"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: Event="External Server Communications Failure" Reason="gatekeeper timed out" Service="NeighbourGatekeeper" Detail="name:10.15.13.16:1719" Level="1" UTCTime="2020-08-12 19:57:58,871"
2020-08-12T14:57:58.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:57:58,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS LRQ  SeqNum=52320 Timeout=True"
2020-08-12T14:57:59.601-05:00 expc01 UTCTime="2020-08-12 19:57:59,601" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Triggering forced peer update of peers which failed DNS and queueing next run" Queue-Time-ms="300000"
2020-08-12T14:58:01.871-05:00 expc01 tvcs: UTCTime="2020-08-12 19:58:01,871" Module="network.h323" Level="INFO":  Action="Sent" Dst-ip="10.15.13.16" Dst-port="1719" Detail="Sending RAS SCI  SeqNum=52319 Timeout=True"

La modification de l'application TLS sur le noeud maître est présentée dans la sortie suivante :

2020-08-12T15:13:24.970-05:00 expc01 UTCTime="2020-08-12 20:13:24,969" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.976-05:00 expc01 UTCTime="2020-08-12 20:13:24,975" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.976-05:00 expc01 httpd[15060]: web: Event="System Configuration Changed" Detail="configuration/cluster/tls_verify - changed from: 'Permissive' to: 'Enforcing'" Src-ip="10.15.13.30" Src-port="53155" User="admin" Level="1" UTCTime="2020-08-12 20:13:24" 
2020-08-12T15:13:24.979-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.980-05:00 expc01 UTCTime="2020-08-12 20:13:24,980" Module="developer.cdbtable.cdb.clusterConfiguration" Level="DEBUG" Node="clusterdb@expc01.apolo.local" PID="<0.345.0>" Detail="Inserting into table" TableName="clusterConfiguration"
2020-08-12T15:13:24.986-05:00 expc01 management: UTCTime="2020-08-12 20:13:24,986" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.145.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.022-05:00 expc01 UTCTime="2020-08-12 20:13:25,022" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc01.apolo.local" PID="<0.142.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.031-05:00 expc01 UTCTime="2020-08-12 20:13:25,031" Event="System Configuration Changed" Node="clusterdb@expc01.apolo.local" PID="<0.557.0>" Detail="xconfiguration alternatesConfiguration - Changed" 
2020-08-12T15:13:25.192-05:00 expc01 management: UTCTime="2020-08-12 20:13:25,192" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.195-05:00 expc01 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,194"

Du point de vue du noeud homologue, il est présenté dans la sortie suivante :

2020-08-12T15:13:24.976-05:00 expc02 UTCTime="2020-08-12 20:13:24,976" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.390.0>" Detail="xconfiguration clusterConfiguration tls_verify - changed from: Permissive to: Enforcing"
2020-08-12T15:13:24.979-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,978" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(312)" Detail="Cluster configuration change detected"
2020-08-12T15:13:24.982-05:00 expc02 management: UTCTime="2020-08-12 20:13:24,982" Module="developer.management.databasemanager" Level="INFO" CodeLocation="databasemanager(405)" Detail="TLS Verify change status" Startup="False" New="True"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.040-05:00 expc02 UTCTime="2020-08-12 20:13:25,040" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.041-05:00 expc02 UTCTime="2020-08-12 20:13:25,041" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.042-05:00 expc02 UTCTime="2020-08-12 20:13:25,042" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.046-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.alternatesmanager" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.143.0>" Detail="alternate peer changed info recieved"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,046" Module="developer.clusterdb.peernameresolver" Level="INFO" Node="clusterdb@expc02.apolo.local" PID="<0.136.0>" Detail="Notifying databasemanager (Management Framework)"
2020-08-12T15:13:25.047-05:00 expc02 UTCTime="2020-08-12 20:13:25,047" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
2020-08-12T15:13:25.049-05:00 expc02 UTCTime="2020-08-12 20:13:25,049" Event="System Configuration Changed" Node="clusterdb@expc02.apolo.local" PID="<0.543.0>" Detail="xconfiguration alternatesConfiguration - Changed"
 2020-08-12T15:13:25.136-05:00 expc02 management: UTCTime="2020-08-12 20:13:25,136" Module="developer.diagnostics.alarmmanager" Level="INFO" CodeLocation="alarmmanager(173)" Detail="Raising alarm" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Parameters="null"
2020-08-12T15:13:25.139-05:00 expc02 management: Level="WARN" Event="Alarm Raised" Id="20007" UUID="e2b8e3d1-b731-4d7d-b606-4682a8f0c2e6" Severity="warning" Detail="Restart required: Cluster configuration has been changed, however a restart is required for this to take effect" UTCTime="2020-08-12 20:13:25,139"

Vidéos

Les vidéos suivantes pourraient être utiles :

Comment créer et ajouter un homologue à un cluster Expressway

Suppression d’un homologue d’un cluster Expressway

Résolution de l’erreur de réplication Expressway « Conflits de configuration entre homologues et principal »

Procédure de redémarrage du cluster Expressway

Comment mettre à niveau un cluster ExpresswayGénération de CSR pour MRA/Clustering Expressways