Bestimmen, ob bei einem Avamar -System ein NTP-Problem (Time Synchronization) auftritt.

Wenn Nodes in einem Avamar -System nicht zeitsynchronisiert sind, können die folgenden Verhaltenarten erwartet werden:

• Der Avamar -Server kann nicht gestartet werden.
• Nodes werden offline geschaltet
• HFScheck schlägt mit MSG_ERR_CGSAN_FAILED fehl
• HFScheck schlägt mit MSG_ERR_HFSCHECKERRORS fehl
• Prüfpunkte schlagen fehl
• Automatische Speicherbereinigung schlägt fehl
• Probleme mit der Datenkonsistenz (wenn sich die Zeit während der automatischen Speicherbereinigung ändert)

Beispiele für Fehlermeldungen, die häufig als Folge des Verlusts der Zeitsynchronisation gemeldet werden:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• SCHWERWIEGENDER FEHLER: <0001> dpn time mismatch: Uhren synchronisieren und erneut versuchen
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan ist unerwartet ausgefallen. beenden  
• nicht genügend rechtzeitig empfangene gültige Antworten

In diesem Artikel kann der Leser feststellen, ob auf dem Avamar -System ein Zeitsynchronisationsproblem vorliegt. Die Behebung des Problems geht über den Umfang dieses Artikels hinaus.

Es gibt viele Websites, die das NTP-Troubleshooting abdecken, und der Leser wird empfohlen, diese zu untersuchen. Hilfreiche Web-URLs, die zum Zeitpunkt des Schreibens verfügbar sind, sind im Abschnitt "externe Links" aufgeführt.

So fahren Sie fort:
1. Melden Sie sich beim Avamar -Server als Admin gemäß KB Avamar an: So melden Sie sich bei einem Avamar -Server an und laden verschiedene Schlüssel.

2. Um festzustellen, ob die Zeit der Avamar -Nodes synchronisiert ist, überprüfen Sie die aktuelle Uhrzeit und das Datum jedes Node auf dem Avamar -System. Eine Beispielausgabe finden Sie in ANHANG A .

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

Wenn alle Nodes das gleiche Datum und die gleiche Uhrzeit melden, bedeutet dies, dass die Uhrzeit zwischen allen Nodes auf diesem System vollständig synchronisiert ist.

3. Um die Zeit auf den Nodes zu synchronisieren, verwendet Avamar Network Time Protocol (NTP). Der Linux-Befehl "ntpq -pn" gibt den Status der Zeitsynchronisation zurück. Beispielausgabe finden Sie in ANHANG B .

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

4. Allgemeine Avamar-Server-Beobachtungen:

• Alle Nodes sind so eingestellt, dass sie 128.xxx.xxx.xx als primäre Zeitquelle bevorzugen.
• Die sekundäre Zeitquelle für alle Nodes ist die lokale BIOS-Uhr auf "avmtest1" (Node 0.s).
• Die tertiäre Zeitquelle ist auf avmtest2 (Node 0.0) festgelegt, der sich selbst auf avmtest1 bezieht.
• Alle Nodes werden mit avmtest1 synchronisiert. Der mit einem Sternchen (*) gekennzeichnete Zeitserver ist der, mit dem der Node derzeit synchronisiert.
• In diesem Fall befindet sich 128.xxx.xxx.xx remote. Er hat einen "Reach"-Wert von 0 (derzeit nicht erreichbar). Es ist als Zeitquelle unnötig.
• avmtest1 und avmtest2 verfügen beide über ein Erreichbarkeitsregister von oktal 377. Dies ist die höchste erreichbare Zahl. Aus diesem Grund synchronisieren alle Nodes mit der sekundären Quelle.

5. Sehen Sie sich die ntpq-Ausgabe für Node 0.2 an.

(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

• Node 0.2 fragt avmtest1 alle 256 Sekunden ab.
• Node 0.2 wird derzeit mit avmtest1 synchronisiert.
• avmtest1 befindet sich bei Schicht 9, was bedeutet, dass Node 0.2 an Schicht 10 liegt.
• Node 0.2 fragt avmtest1 alle 256 Sekunden ab.
• Das Erreichbarkeitsregister für avmtest1 ist octal 376.
• Die Uhr auf avmtest1 beträgt 0,116 Millisekunden (oder 116 Mikrosekunden) hinter der Uhr auf avmtest1.
• Die Roundtrip-Verzögerung auf avmtest1 beträgt 85 Millisekunden.
• Die Messung der Latenzabweichung im Netzwerk (Jitter) zwischen Node 0.2 und avmtest1 beträgt 2 Millisekunden.

NTP-Konfiguration (/etc/ntp.conf):
Bei der Überprüfung der Datei /etc/ntp.conf auf Node 0.2 entspricht sie der oben genannten ntpq-Ausgabe .

#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)

Protokollierung:
Die NTP-Protokollierung wird an die Datei /var/log/messages weitergeleitet.
Um NTP-bezogene Protokollierung anzuzeigen, geben Sie den Inhalt von /var/log/messages* für "ntp" ein.

Wenn ein externer Zeitserver unzuverlässig ist, wie im obigen Beispiel gezeigt, ist es akzeptabel, einen internen Zeitserver zu verwenden. Die interne Zeit kann langsam von UTC abweichen, aber die wichtigste Überlegung ist, dass die Daten-Nodes mit der Zeit synchronisiert werden.

Das Asktime-Tool des Avamar-Dienstprogramms kann verwendet werden, um neue, bevorzugte Zeitquellen für NTP auszuwählen.
Siehe Avamar: Konfigurieren von NTP auf einem Avamar-Server mit asktime 

Zusätzliche Informationen:
http://support.microsoft.com/kb/939322 : Windows-Domain-Controller sollten nicht für eine gute Zeit verwendet werden.