Table des matières

Introduction

Étapes pour diagnostiquer la duplication de la base de données

Étape 1. Vérifier si la duplication de la base de données est défectueuse

Étape 2. Vérifier l’état de la base de données CM sur la page Cisco Unified Reporting du CUCM

Étape 3. Chercher dans le rapport de la base de données Unified CM tout composant marqué comme étant une erreur

Étape 4. Vérifiez les composants individuels qui utilisent la commande utils diagnose test

Étape 5. Vérifier l’état de la connectivité et l’authentification de tous les nœuds

Étape 6. La commande utils dbreplication runtimestate affiche les éléments non synchronisés ou non demandés.

Étape 7. Réparer toutes les tables/tables sélectives pour la réplication de base de données

Étape 8. Réinitialiser entièrement la réplication de base de données

Introduction

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.

Étapes pour diagnostiquer la duplication de la base de données

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 centre d'assistance technique pour diagnostiquer et isoler le problème.

Étape 1. Vérifier si la duplication de la base de données est défectueuse

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.

Les connexions logiques sont établies, mais il n’est pas certain que les tableaux concordent.

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 duplication de la base de données, exécutez la commande utils dbreplication runtimestate à partir de la CLI du nœud de publication, comme l’illustre 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.

Étape 2. Vérifier l’état de la base de données CM sur la page Cisco Unified Reporting du CUCM

1. Une fois l'étape 1 terminée, choisissez l'option Cisco Unified Reporting dans la liste déroulante Navigation de l'éditeur Cisco Unified Communications Manager (CUCM), comme illustré dans cette image.

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 qui utilise 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 TAC au cas où une demande de service (SR) devrait être ouverte.

Étape 3. Chercher dans le rapport de la base de données Unified CM tout composant marqué comme étant une erreur

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.

- En cas d’erreur, vérifiez la connectivité du réseau entre les nœuds. Vérifiez si le service A Cisco DB s'exécute à partir de l'interface de ligne de commande du noeud et utilise la commande utils service list.

- Si le service A de base de données Cisco est défectueux, exécutez la commande utils service start A Cisco DB pour démarrer le service. En cas d'échec, contactez le TAC Cisco.

- Vérifiez que la liste des serveurs de duplication (cdr list serv) est remplie pour tous les nœuds.

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.

- Vérifiez que les hôtes, les Rhosts et les Sqlhosts Unified CM sont équivalents sur tous les nœuds.

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 :

- Vérifiez la connectivité du réseau entre le nœud visé et l’éditeur.

- Vérifiez que le numéro de port 1515 est autorisé sur le réseau.

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

- Vérifiez la bonne connectivité du réseau entre les nœuds, comme l’illustre cette image :

Si la connectivité réseau échoue pour les noeuds :

- Vérifiez l’accessibilité au réseau entre les nœuds.

- Vérifiez que les numéros de ports TCP/UDP appropriés sont autorisés sur le réseau.

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.

Étape 4. Vérifiez les composants individuels qui utilisent la commande utils diagnose test

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 le montre cette image.

- Motif

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.

- Effet

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é.

- Motif

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

- Effet

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 :

1. Utilisez la commande utils diagnose test pour vérifier le résultat, comme l’illustre cette image.

2.  En outre, vous pouvez exécuter cette commande :

utils ntp status

Étape 5. Vérifier l’état de la connectivité et l’authentification de tous les nœuds

1. Une fois l’étape 4 terminée, si aucun problème n’est signalé, exécutez la commande utils network connectivity sur tous les nœuds pour vérifier la connectivité aux bases de données, comme l’illustre cette image.

2. Si vous recevez Cannot send TCP/UDP packets as an error message, vérifiez sur votre réseau si des retransmissions ont été effectuées 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

Étape 6. La commande utils dbreplication runtimestate affiche les éléments non synchronisés ou non demandés.

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 :

- Tous les nœuds sont connectés les uns aux autres. Reportez-vous à l’étape 5.

- L’appel RPC est accessible. Reportez-vous à l’étape 3.

- Consultez le TAC Cisco avant de passer aux étapes 7 et 8 dans le cas de noeuds supérieurs à 8.

- Effectuez la procédure en dehors des heures d’ouverture.

Étape 7. Réparer toutes les tables/tables sélectives pour la réplication de base de données

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.

Étape 8. Réinitialiser entièrement la réplication de base de données

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 :

- Rapport sur la base de données CM Cisco Unified Reporting (reportez-vous à l’étape 2).

- La commande utils create report database de la CLI.  Téléchargez le fichier .tar et utilisez un serveur SFTP.

Pour plus d'informations, consultez les liens suivants :

Présentation du résultat de la commande utils dbreplication runtimestate pour CUCM

Dépannage de la duplication de la base de données CUCM pour appareils Linux