Déterminer si un système Avamar rencontre un problème de synchronisation horaire (NTP).

Si les nœuds d’un système Avamar ne sont pas synchronisés à l’heure, nous pouvons nous attendre aux types de comportement suivants :

• Le serveur Avamar ne parvient pas à démarrer
• Les nœuds passent hors ligne
• Échec de la vérification HFS avec MSG_ERR_CGSAN_FAILED
• Échec de la vérification HFS avec MSG_ERR_HFSCHECKERRORS
• Échec des points de contrôle
• Échec de la récupération d’espace
• Problèmes de cohérence des données (si l’heure change lors de la récupération d’espace)

Exemples de messages d’erreur couramment signalés suite à une perte de synchronisation de l’heure :

• samconn ::checkallsucceed request failed DPNTIMECHECK=230 
• ERREUR FATALE : <0001> dpn time mismatch : synchroniser les horloges et réessayer
• ERROR: <0001> dpncheckmanager ::verifyStartup cgsan s’éteint de manière inattendue. arrêt  
• pas assez de réponses valides reçues dans le temps

Cet article aide le lecteur à déterminer si le système Avamar rencontre un problème de synchronisation de l’heure. La résolution du problème dépasse le champ d’application de cet article.

Il existe de nombreux sites Web qui couvrent le dépannage NTP et le lecteur est invité à les examiner. Les URL Web utiles disponibles au moment de l’écriture sont répertoriées dans la section « Liens externes ».

Pour continuer :
1. Connectez-vous au serveur Avamar en tant qu’administrateur selon Avamar de la base de connaissances : Comment se connecter à un serveur Avamar et charger différentes clés.

2. Pour déterminer si l’heure des nœuds Avamar est synchronisée, vérifiez l’heure et la date actuelles de chaque nœud du système Avamar. Reportez-vous à l’ANNEXE A pour obtenir un exemple de sortie.

mapall --all --parallel '/bin/date'

Lorsque tous les nœuds signalent la même date et heure, cela signifie que l’heure est entièrement synchronisée entre tous les nœuds de ce système.

3. Pour que l’heure reste synchronisée sur les nœuds, Avamar utilise le protocole NTP (Network Time Protocol). La commande Linux «ntpq -pn» renvoie l’état de synchronisation de l’heure. Reportez-vous à l’ANNEXE B pour obtenir un exemple de sortie.

mapall --all --noerror '/usr/sbin/ntpq -p'

4. Observations générales du serveur Avamar :

• Tous les nœuds sont définis sur 128.xxx.xxx.xx comme source de temps principale.
• La source de temps secondaire pour tous les nœuds est l’horloge du BIOS local sur « avmtest1 » (nœud 0.s).
• La source de temps tertiaire est définie sur avmtest2 (nœud 0.0) qui fait lui-même référence à avmtest1.
• Tous les nœuds se synchronisent avec avmtest1. Le serveur de temps marqué d’un astérisque (*) est celui avec lequel le nœud est en cours de synchronisation.
• Dans ce cas, 128.xxx.xxx.xx se trouve à distance. Il a une valeur de portée de 0 (actuellement inaccessible). Il est inutile en tant que source de temps.
• avmtest1 et avmtest2 ont tous deux un registre d’accessibilité octal 377. Il s’agit du chiffre le plus élevé possible. Par conséquent, les nœuds sont tous synchronisées avec la source secondaire.

5. En examinant la sortie ntpq du nœud 0.2 ;

(0.2) ssh  -x  admin@10.64.18.164 '/usr/sbin/ntpq -p'

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================
 128.xxx.xxx.xx  .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
*avmtest1.emcvmw LOCAL(0)         9 u   54  256  377    0.085   -0.116   0.002
+avmtest2.emcvmw xx.xx.xx.xxx    10 u   56  256  377    0.090    0.073   0.012

• Le nœud 0.2 interrogation avmtest1 toutes les 256 secondes
• Le nœud 0.2 est en cours de synchronisation avec avmtest1
• avmtest1 est à la stratum 9, ce qui signifie que le nœud 0.2 est à la stratum 10.
• Le nœud 0.2 interrogation avmtest1 une fois toutes les 256 secondes.
• Le registre d’accessibilité pour avmtest1 est octal 376.
• L’horloge sur avmtest1 est de 0,116 milliseconde (ou 116 microsecondes) derrière l’horloge sur avmtest1.
• Le délai d’aller-retour vers avmtest1 est de 85 millisecondes.
• La mesure de l’écart de latence sur le réseau (gigue) entre le nœud 0.2 et avmtest1 est de 2 millisecondes.

Configuration NTP (/etc/ntp.conf) :
si vous examinez le fichier /etc/ntp.conf sur le nœud 0.2, il correspond à la sortie ntpq ci-dessus.

#Customer premises / external time servers.

#
server xxx.xxx.xxx.xx     <--  Primary time source (this is an external server located remote to the Avamar grid)
# - - - - -
# DPN time servers here and in the other module(s).
#
server xx.xx.xx.xxx   <--  Secondary time source (this is the utility node)
server xx.xx.xx.xxx   <--  Tertiary time source (this is node 0.0)

Enregistrement:
La consignation NTP est dirigée vers le fichier /var/log/messages .
Pour afficher la consignation liée au protocole NTP, grep le contenu de /var/log/messages* pour « ntp »

Si un serveur de temps externe n’est pas fiable, comme dans l’exemple ci-dessus, il est acceptable d’utiliser un serveur de temps interne. L’heure interne peut dériver lentement de l’UTC, mais le plus important est que les nœuds de données sont synchronisés l’un avec l’autre.

L’outil de demande de l’utilitaire Avamar peut être utilisé pour sélectionner de nouvelles sources de temps préférées pour NTP.
Voir Avamar : Configuration du protocole NTP sur un serveur Avamar à l’aide de asktime 

Informations supplémentaires :
http://support.microsoft.com/kb/939322 : les contrôleurs de domaine Windows ne doivent pas être utilisés pour une bonne conservation.