Determinare se in un sistema Avamar si verifica un problema di sincronizzazione dell'ora (NTP).

Se i nodi all'interno di un sistema Avamar non sono sincronizzati nel tempo, è possibile che vengano visualizzati i seguenti tipi di comportamento:

• Impossibile avviare il server Avamar
• I nodi passano offline
• HFScheck ha esito negativo con MSG_ERR_CGSAN_FAILED
• Il controllo HFS ha esito negativo con MSG_ERR_HFSCHECKERRORS
• Checkpoint non superato
• Garbage collection non riuscita
• Problemi di coerenza dei dati (se il tempo cambia durante la garbage collection)

Esempi di messaggi di errore comunemente segnalati a causa della perdita di sincronizzazione del tempo:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• ERRORE IRREVERSIBILE: <0001 dpn time mismatch: synchronize clocks and retry (0001> dpn time mismatch: sincronizzare clock e riprovare)
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan si è oscurato in modo imprevisto.  
• risposte non sufficientemente valide ricevute in tempo

Questo articolo aiuta il lettore a determinare se il sistema Avamar sta riscontrando un problema di sincronizzazione dell'ora. La risoluzione del problema non rientra nell'ambito di questo articolo.

Ci sono molti siti web che riguardano la risoluzione dei problemi NTP e il lettore è invitato a analizzarli. Gli URL web utili disponibili al momento della scrittura sono elencati nella sezione "link esterni".

Per procedere:
1. Accedere ad Avamar Server come amministratore in base all'articolo della KB Avamar: Come accedere a un Avamar Server e caricare varie chiavi.

2. Per determinare se i nodi Avamar sono sincronizzati con l'ora, controllare l'ora e la data correnti di ciascun nodo sul sistema Avamar. Per un esempio di output, vedere l'APPENDICE A .

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

Quando tutti i nodi riportano la stessa data e ora, significa che l'ora è completamente sincronizzata tra tutti i nodi di questo sistema.

3. Per mantenere il tempo sincronizzato sui nodi, Avamar utilizza il protocollo NTP (Network Time Protocol). Il comando Linux "ntpq -pn" restituisce lo stato della sincronizzazione dell'ora. Per l'output di esempio, vedere l'APPENDICE B .

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

4. Osservazioni generali su Avamar Server:

• Tutti i nodi sono impostati in modo da preferire 128.xxx.xxx.xx come origine ora primaria.
• L'origine ora secondaria per tutti i nodi è il clock del BIOS locale su "avmtest1" (nodo 0.s).
• L'origine ora terziaria è impostata su avmtest2 (nodo 0.0) che si riferisce a avmtest1.
• Tutti i nodi sono sincronizzati con avmtest1. Il server di riferimento ora contrassegnato con un asterisco (*) è quello con cui il nodo è attualmente in sincronizzazione.
• In questo caso, 128.xxx.xxx.xx si trova in remoto. Ha un valore "reach" pari a 0 (attualmente irraggiungibile). È inutile come fonte di tempo.
• avmtest1 e avmtest2 dispongono entrambi di un registro di raggiungibilità di ottobre 377. Questa è la cifra più alta raggiungibile. Pertanto, i nodi sono tutti in sincronizzazione con l'origine secondaria.

5. Osservando l'output ntpq per il nodo 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

• Il nodo 0.2 esegue il polling di avmtest1 ogni 256 secondi
• Il nodo 0.2 è attualmente in sincronizzazione con avmtest1
• avmtest1 si trova nello strato 9, implicando che il nodo 0.2 si trova nello strato 10.
• Il nodo 0.2 esegue il polling di avmtest1 ogni 256 secondi.
• Il registro di raggiungibilità per avmtest1 è ottale 376.
• Il clock su avmtest1 è di 0,116 millisecondi (o 116 microsecondi) dietro il tempo su avmtest1.
• Il ritardo di roundtrip per avmtest1 è di 85 millisecondi.
• La misurazione della varianza nella latenza sulla rete (jitter) tra il nodo 0.2 e avmtest1 è di 2 millisecondi.

Configurazione NTP (/etc/ntp.conf):
se si esamina il file /etc/ntp.conf nel nodo 0.2, corrisponde all'output ntpq precedente.

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

Registrazione:
La registrazione NTP viene indirizzata al file /var/log/messages .
Per visualizzare il logging correlato a NTP, grep il contenuto di /var/log/messages* per 'ntp'

Se un server di riferimento ora esterno è inaffidabile, come nell'esempio sopra indicato, è accettabile utilizzare un server di riferimento orario interno. L'ora interna potrebbe essere lenta rispetto all'ora UTC, ma la considerazione più importante è che i nodi di dati sono sincronizzati l'ora l'uno con l'altro.

Lo strumento asktime dell'utilità Avamar può essere utilizzato per selezionare nuove origini orarie preferite per NTP.
Vedere Avamar: Come configurare NTP su un Avamar Server utilizzando asktime 

Informazioni aggiuntive:
http://support.microsoft.com/kb/939322 - I controller di dominio Windows non devono essere utilizzati per un periodo di tempo prolungato.