Determinar se um sistema Avamar está enfrentando um problema de sincronização de horário (NTP).

Se os nós de um sistema Avamar não estiverem sincronizados com o tempo, podemos esperar os seguintes tipos de comportamento:

• O servidor Avamar não consegue iniciar
• Os nós estão off-line
• A verificação de HFS falhacom MSG_ERR_CGSAN_FAILED
• A verificação de HFS falha com MSG_ERR_HFSCHECKERRORS
• Pontos de verificação falham
• Falha na coleta de lixo
• Problemas de consistência de dados (se o tempo mudar durante a coleta de lixo)

Exemplos de mensagens de erro normalmente relatadas como resultado da perda de sincronização de horário:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• ERRO FATAL: <0001> disparidade de tempo dpn: sincronizar relógios e repetir
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan died unexpectedly. terminando  
• não há respostas válidas suficientes recebidas no tempo

Este artigo ajuda o leitor a determinar se o sistema Avamar está enfrentando um problema de sincronização de horário. A solução do problema está além do escopo deste artigo.

Há muitos sites que abrangem a solução de problemas de NTP, e o leitor é incentivado a investigue-los. URLs úteis da Web disponíveis no momento da gravação são listadas na seção "links externos".

Para prosseguir:
1. Faça log-in no servidor Avamar como administrador por KB Avamar: Como fazer log-in em um servidor Avamar e carregar várias chaves..

2. Para determinar se os nós do Avamar estão sincronizados, verifique a hora e a data atuais de cada nó no sistema Avamar. Consulte o APÊNDICE A para obter um exemplo de resultado.

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

Quando todos os nós relatam a mesma data e hora, isso significa que a hora está totalmente sincronizada entre todos os nós nesse sistema.

3. Para manter o tempo sincronizado nos nós, o Avamar usa o NTP (Network Time Protocol). O comando "ntpq -pn" do Linux retorna o estado da sincronização de horário. Consulte o APÊNDICE B para obter exemplos de resultado.

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

4. Observações gerais do servidor Avamar:

• Todos os nós são definidos para preferir 128.xxx.xxx.xx como a fonte de tempo principal.
• A origem de tempo secundária para todos os nós é o relógio local do BIOS em "avmtest1" (nó 0.s).
• A origem de tempo terciária é definida como avmtest2 (nó 0.0), que se refere ao avmtest1.
• Todos os nós estão sincronizando com avmtest1. O servidor de horário marcado com um asterisco (*) é aquele com o qual o nó está sincronizando no momento.
• Nesse caso, 128.xxx.xxx.xx está localizado remotamente. Ele tem um valor de "alcance" de 0 (atualmente inacessível). É inútil como uma fonte de tempo.
• avmtest1 e avmtest2 têm um registro de acessibilidade de octal 377. Este é o número mais alto que pode ser alcançado. Portanto, todos os nós estão sincronizando com a origem secundária.

5. Analisando a saída ntpq do nó 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

• O nó 0.2 está consultando avmtest1 a cada 256 segundos
• No momento, o nó 0.2 está sendo sincronizado com o avmtest1
• avmtest1 está no nível 9, o que significa que o nó 0.2 está no nível 10.
• O nó 0.2 está consultando avmtest1 uma vez a cada 256 segundos.
• O registro de acessibilidade para avmtest1 é octal 376.
• O relógio no avmtest1 é de 0,116 milissegundos (ou 116 microssegundos) atrás do relógio no avmtest1.
• O atraso de roundtrip para avmtest1 é de 85 milissegundos.
• A medição da variação na latência na rede (tremulação) entre o nó 0,2 e o avmtest1 é de 2 milissegundos.

Configuração de NTP (/etc/ntp.conf):
se estiver analisando o arquivo /etc/ntp.conf no nó 0.2, ele corresponde à saída ntpq acima.

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

Log:
O registro de NTP é direcionado para o arquivo /var/log/messages .
Para visualizar o registro relacionado ao NTP, grep o conteúdo de /var/log/messages* para 'ntp'

Se um servidor de horário externo não for confiável, como no exemplo fornecido acima, é aceitável usar um servidor de horário interno. O tempo interno pode se afastar lentamente do UTC, mas a consideração mais importante é que os nós de dados são sincronizados entre si.

A ferramenta asktime do utilitário Avamar pode ser usada para selecionar novas fontes de tempo preferenciais para NTP.
Consulte o Avamar: Como configurar o NTP em um servidor Avamar usando asktime 

Informações adicionais:
http://support.microsoft.com/kb/939322 - Os controladores de domínio do Windows não devem ser usados para manter o tempo.