Determinación de si un sistema Avamar está experimentando un problema de sincronización de hora (NTP).

Si los nodos dentro de un sistema Avamar no tienen hora sincronizada, podemos esperar los siguientes tipos de comportamiento:

• El servidor Avamar no se puede iniciar
• Los nodos se desconectan
• HFScheck falla con MSG_ERR_CGSAN_FAILED
• HFScheck falla con MSG_ERR_HFSCHECKERRORS
• Los puntos de control fallan
• La recolección de elementos no utilizados falla
• Problemas de coherencia de datos (si la hora cambia durante la recolección de elementos no utilizados)

Ejemplos de mensajes de error que comúnmente se informan como resultado de la pérdida de sincronización de tiempo:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• ERROR IRRECUPERABLE: <0001> dpn time mismatch: sincronice los relojes y vuelva a intentarlo
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan se perdió inesperadamente. Finalizando  
• no se recibieron suficientes respuestas válidas a tiempo

En este artículo, se ayuda al lector a determinar si el sistema Avamar está experimentando un problema de sincronización de hora. La resolución del problema está fuera del alcance de este artículo.

Hay muchos sitios web que cubren la solución de problemas de NTP y se recomienda que el lector los investigue. Las URL web útiles disponibles en el momento de la escritura se enumeran en la sección "enlaces externos".

Para continuar:
1. Inicie sesión en el servidor Avamar como administrador según el artículo de la base de conocimientos Avamar: Cómo iniciar sesión en un servidor Avamar y cargar varias claves.

2. Para determinar si los nodos de Avamar están sincronizados con la hora, compruebe la hora y la fecha actuales de cada nodo en el sistema Avamar. Consulte el APÉNDICE A para ver ejemplos de salida.

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

Cuando todos los nodos informan la misma fecha y hora, esto significa que la hora está completamente sincronizada entre todos los nodos de este sistema.

3. Para mantener la hora sincronizada en los nodos, Avamar utiliza el protocolo de tiempo de red (NTP). El comando de Linux "ntpq -pn" devuelve el estado de sincronización de hora. Consulte el APÉNDICE B para ver la salida de muestra.

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

4. Observaciones generales del servidor Avamar:

• Todos los nodos están configurados para preferir 128.xxx.xxx.xx como el origen de hora principal.
• El origen de hora secundario para todos los nodos es el reloj local del BIOS en "avmtest1" (nodo 0.s).
• El origen de hora terciario se configura en avmtest2 (nodo 0.0), que se refiere a avmtest1.
• Todos los nodos se sincronizan con avmtest1. El servidor de hora marcado con un asterisco (*) es el que el nodo está sincronizando actualmente.
• En este caso, 128.xxx.xxx.xx se encuentra de forma remota. Tiene un valor de "alcance" de 0 (actualmente inaccesible). Es inutilizable como fuente de tiempo.
• avmtest1 y avmtest2 tienen un registro de accesibilidad de octal 377. Esta es la cifra más alta alcanzable. Por lo tanto, todos los nodos se sincronizan con el origen secundario.

5. Observando la salida de ntpq para el 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

• El nodo 0.2 sondea avmtest1 cada 256 segundos
• El nodo 0.2 se sincroniza actualmente con avmtest1
• avmtest1 se encuentra en el stratum 9, lo que implica que el nodo 0.2 está en el stratum 10.
• El nodo 0.2 sondea avmtest1 una vez cada 256 segundos.
• El registro de accesibilidad para avmtest1 es octal 376.
• El reloj en avmtest1 es de 0,116 milisegundos (o 116 microsegundos) detrás del reloj en avmtest1.
• La demora de ida y vuelta a avmtest1 es de 85 milisegundos.
• La medición de la varianza de latencia en la red (vibración) entre el nodo 0.2 y avmtest1 es de 2 milisegundos.

Configuración de NTP (/etc/ntp.conf):
si revisa el archivo /etc/ntp.conf en el nodo 0.2, corresponde a la salida de ntpq anterior.

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

Registro:
El registro de NTP se dirige al archivo /var/log/messages .
Para ver el registro relacionado con NTP, grep el contenido de /var/log/messages* para "ntp"

Si un servidor de hora externo no es confiable, como en el ejemplo anterior, es aceptable utilizar un servidor de hora interno. El tiempo interno puede desviarse lentamente de UTC, pero la consideración más importante es que los nodos de datos tienen una hora sincronizada entre sí.

La herramienta Asktime de la utilidad Avamar se puede utilizar para seleccionar nuevos orígenes de hora preferidos para NTP.
Consulte Avamar: Cómo configurar NTP en un servidor Avamar mediante asktime 

Información adicional:
http://support.microsoft.com/kb/939322: las controladoras de dominio de Windows no se deben utilizar para mantener el tiempo.