Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Le présent document explique comment diagnostiquer les problèmes de duplication de la base de données et indique les étapes nécessaires pour procéder au dépannage et résoudre ces problèmes.
Cette section décrit les scénarios dans lesquels la réplication de la base de données est interrompue et fournit la méthodologie de dépannage suivie par un ingénieur du TAC afin de diagnostiquer et d'isoler le problème.
Afin de déterminer si la duplication de votre base de données est défectueuse, vous devez connaître les différents états de l’outil de surveillance en temps réel (RTMT) de la duplication.
Valeur | Signification | Description |
---|---|---|
0 |
État d’initialisation |
La duplication est en cours de configuration. Un échec de configuration peut se produire si la réplication est dans cet état pendant plus d'une heure. |
1 |
Le nombre de duplications est incorrect. |
La configuration est toujours en cours. Cet état est rarement vu dans les versions 6.x et 7.x ; dans la version 5.x, il indique que la configuration est toujours en cours. |
2 |
La duplication fonctionne bien. |
Les connexions logiques sont établies et les tableaux sont mis en correspondance avec les autres serveurs de la grappe. |
3 |
Les tableaux ne concordent pas. |
Des connexions logiques sont établies, mais il existe une incertitude quant à la correspondance des tables. Dans les versions 6.x et 7.x, tous les serveurs pourraient afficher l’état 3 même si un des serveurs de la grappe est en panne. Ce problème pourrait se produire parce que les autres serveurs ne savent pas s’il s’agit d’une mise à jour de la fonctionnalité à l’intention des utilisateurs (UFF) qui n’a pas été transmise de l’abonné aux autres périphériques de la grappe. |
4 |
Échec/abandon de la configuration |
Le serveur n’a plus de connexion logique active qui lui permet de recevoir des tableaux de base de données sur le réseau. Aucune duplication ne se produit dans cet état. |
Pour vérifier la réplication de la base de données, exécutez la commande utils dbreplication runtimestat à partir de l'interface de ligne de commande du noeud éditeur, comme illustré dans cette image.
Dans le résultat, vérifiez que l’état de la duplication de la grappe ne contient pas les anciens renseignements de synchronisation. Cochez la même case et utilisez l'horodatage.
Si la synchronisation de diffusion n’est pas mise à jour avec une date récente, exécutez la commande utils dbreplication status pour vérifier tous les tableaux et la duplication. Si des erreurs ou des discordances sont découvertes, elles s’afficheront dans le résultat et l’état de l’outil RTMT changera en conséquence, comme l’illustre cette image.
Une fois la commande exécutée, l’uniformité de tous les tableaux est vérifiée et l’état exact de la duplication s’affiche.
Remarque : autorisez la vérification de toutes les tables, puis poursuivez le dépannage.
Dès que l’état exact de la duplication s’affiche, vérifiez la configuration de la duplication (outil RTMT) et les détails dans le premier résultat. Vous devez vérifier l’état de chaque nœud. Si un nœud a un état autre que 2, continuez le dépannage.
2. Accédez à Rapports système et cliquez sur État de la base de données Unified CM, comme illustré dans cette image.
3. Générez un nouvel état à l'aide de l'option Générer un nouvel état ou cliquez sur l'icône Générer un nouvel état comme illustré dans cette image.
4. Une fois le rapport généré et téléchargé, enregistrez-le afin qu'il puisse être fourni à un ingénieur du centre d'assistance technique au cas où une demande de service (SR) aurait besoin d'être ouverte.
Si les composants contiennent des erreurs, celles-ci sont signalées par une icône X rouge, comme illustré dans cette image.
Vérifiez que les bases de données locale et de publication sont accessibles.
Cette image illustre un résultat idéal.
Si la liste CDR (réplicateurs de bases de données Cisco) est vide pour certains nœuds, reportez-vous à l’étape 8.
Il s’agit d’une étape importante. Comme le montre l’image ci-dessous, les hôtes, les Rhosts et les Sqlhosts Unified CM sont équivalents sur tous les nœuds.
Les fichiers hôtes (Hosts) ne concordent pas :
Ce pourrait être le signe d’une activité incorrecte lorsqu’une adresse IP change pour le nom d’hôte sur le serveur.
Consultez le lien ci-dessous afin de changer l’adresse IP pour le nom d’hôte pour le CUCM.
Modifications de l’adresse IP et du nom d’hôte
Redémarrez ces services à partir de l'interface de ligne de commande du serveur de publication et vérifiez si la non-correspondance est résolue. Si oui, passez à l’étape 8. Dans la négative, contactez le TAC Cisco. Générez un nouveau rapport chaque fois que vous apportez une modification à l’interface graphique (GUI) ou à la CLI pour vérifier si les changements sont inclus.
Cluster Manager ( utils service restart Cluster Manager)
A Cisco DB ( utils service restart A Cisco DB)
Les fichiers Rhosts ne concordent pas :
Si les fichiers Rhosts et les fichiers hôtes ne concordent pas, suivez les étapes dans la section Les fichiers hôtes (Hosts) ne concordent pas. Si seuls les fichiers Rhosts ne concordent pas, exécutez les commandes à partir de la CLI :
A Cisco DB ( utils service restart A Cisco DB ) Cluster Manager ( utils service restart Cluster Manager)
Générez un nouveau rapport et vérifiez si les fichiers Rhost sont équivalents sur tous les serveurs. Si oui, passez à l’étape 8. Dans la négative, contactez le TAC Cisco.
Les fichiers Sqlhosts ne concordent pas :
Si les fichiers Sqlhosts et les fichiers hôtes ne concordent pas, suivez les étapes dans la section Les fichiers hôtes (Hosts) ne concordent pas. Si seuls les fichiers Sqlhosts ne concordent pas, exécutez la commande à partir de la CLI :
utils service restart A Cisco DB
Générez un nouveau rapport et vérifiez si les fichiers Sqlhost sont équivalents sur tous les serveurs. Si oui, passez à l’étape 8. Dans la négative, contactez le TAC Cisco
Vérifiez que l’appel de procédure distant de la couche de base de données (DBL RPC) hello réussit, comme l’illustre cette image.
Si l’appel RPC hello ne fonctionne pas pour un nœud en particulier :
Consultez le lien suivant pour en savoir plus sur l’utilisation des ports TCP/UDP :
Cisco Unified Communications Manager – Utilisation des ports TCP et UDP
Si la connectivité réseau échoue pour les noeuds :
Générez un nouveau rapport et vérifiez si la connexion a réussi. En cas d’échec de la connexion, passez à l’étape 8.
La commande utils diagnose test vérifie tous les composants et renvoie une valeur de réussite ou d’échec. Les composants essentiels au bon fonctionnement de la duplication de la base de données sont les suivants :
Connectivité du réseau :
La commande validate_network vérifie tous les aspects de la connectivité du réseau pour tous les nœuds de la grappe. S’il y a un problème de connectivité, une erreur s’affiche souvent sur le serveur de noms de domaine (DNS) ou le serveur de noms de domaine inversé (RDNS). La commande validate_network effectue l’opération en 300 secondes. Voici les messages d’erreur courants pour les tests de connectivité du réseau :
1. Erreur « La communication intra-cluster est interrompue », comme illustré dans cette image.
Cette erreur se produit lorsqu’un ou plusieurs nœuds de la grappe ont un problème de connectivité au réseau. Vérifiez que tous les nœuds sont accessibles par ping.
Une communication intra-grappe défectueuse entraîne des problèmes de duplication de la base de données.
2. La recherche DNS inverse a échoué.
Cette erreur se produit en cas d’échec de la recherche DNS inversée sur un nœud. Cependant, vous pouvez vérifier si le DNS est configuré et fonctionne correctement lorsque vous utilisez ces commandes :
utils network eth0 all - Shows the DNS configuration (if present) utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname
Si le DNS ne fonctionne pas correctement, il peut provoquer des problèmes de réplication de base de données lorsque les serveurs sont définis et utilisent les noms d'hôte.
Accessibilité du protocole NTP (Network Time Protocol) :
Le NTP est chargé de synchroniser l'heure du serveur avec l'horloge de référence. L'éditeur synchronise toujours l'heure avec le périphérique dont l'adresse IP est répertoriée en tant que serveurs NTP, tandis que les abonnés synchronisent l'heure avec l'éditeur.
Il est extrêmement important que le NTP soit entièrement fonctionnel afin d’éviter tout problème de duplication de la base de données.
Il est essentiel que la strate NTP (nombre de sauts vers l'horloge de référence parente) soit inférieure à 5, sinon elle est jugée non fiable.
Effectuez ces étapes dans l’ordre ci-dessous afin de vérifier l’état NTP :
2. En outre, vous pouvez exécuter cette commande :
utils ntp status
2. Si vous recevez le message d’erreur « Cannot send TCP/UDP packets » (Impossible d’envoyer des paquets TCP/UDP), vérifiez si votre réseau a effectué des retransmissions ou bloquez les ports TCP/UDP. La commande show network cluster vérifie l’authentification de tous les nœuds.
3. Si l’état du noeud n’est pas authentifié, assurez-vous que la connectivité réseau et le mot de passe de sécurité sont identiques sur tous les noeuds, comme illustré dans cette image.
Consultez les liens sur la modification ou la récupération des mots de passe de sécurité :
Comment réinitialiser les mots de passe sur CUCM
Récupération du mot de passe de l’administrateur du système d’exploitation CUCM
Il est important de comprendre que la duplication de base de données est une tâche exigeante pour le réseau, car elle pousse les tableaux vers tous les nœuds de la grappe. Vérifiez les points suivants :
Les noeuds se trouvent dans le même centre de données/site : tous les noeuds sont accessibles avec un temps de parcours aller-retour (RTT) inférieur. Si le RTT est anormalement élevé, vérifiez les performances du réseau.
Les noeuds sont dispersés sur le réseau étendu (WAN) : assurez-vous que les noeuds ont une connectivité réseau bien inférieure à 80 ms. Si certains nœuds ne sont pas en mesure de se joindre au processus de duplication, augmentez le paramètre à une valeur plus élevée, comme il est indiqué ci-dessous.
utils dbreplication setprocess <1-40>
Remarque : lorsque vous modifiez ce paramètre, il améliore les performances de configuration de la réplication, mais consomme des ressources système supplémentaires.
Le délai de réplication est basé sur le nombre de noeuds dans le cluster : le délai de réplication (par défaut : 300 secondes) est le délai pendant lequel l'éditeur attend que tous les abonnés envoient leurs messages définis. Calculez l’expiration du délai de duplication en fonction du nombre de nœuds dans la grappe.
Server 1-5 = 1 Minute Per Server Servers 6-10 = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.
Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min, Repltimeout should be set to 21 Minutes.
Commandes pour vérifier/définir l’expiration du délai de réplication :
show tech repltimeout ( To check the current replication timeout value ) utils dbreplication setrepltimeout ( To set the replication timeout )
Les étapes 7 et 8 doivent être effectuées une fois la liste de contrôle remplie :
Liste de vérification :
Si la commande utils dbreplication runtimestate indique qu’il existe des erreurs ou que certains tableaux ne concordent pas, exécutez la commande :
Utils dbreplication repair all
Exécutez la commande utils dbreplication runtimestate pour vérifier de nouveau l’état.
Si l’état ne change pas, passez à l’étape 8.
Reportez-vous à la séquence pour réinitialiser la réplication de base de données et démarrer le processus à partir de zéro.
utils dbreplication stop all (Only on the publisher) utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher) utils dbreplication reset all ( Only on the publisher )
Pour surveiller le processus, exécutez la commande RTMT/utils dbreplication runtimestate.
Reportez-vous à la séquence ci-dessous pour réinitialiser la duplication de la base de données pour un nœud particulier :
utils dbreplication stop <sub name/IP> (Only on the publisher) utils dbreplcation dropadmindb (Only on the affected subscriber) utils dbreplication reset <sub name/IP> (Only on the publisher )
Si vous contactez le TAC Cisco pour obtenir de l'aide, assurez-vous que les résultats et les rapports suivants sont fournis :
utils dbreplication runtimestate utils diagnose test utils network connectivity
Rapports :
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
29-Nov-2023 |
Mise à jour du texte de remplacement, de la traduction automatique et du formatage. |
1.0 |
13-Aug-2021 |
Première publication |