Określanie, czy w systemie Avamar występuje problem z synchronizacją czasu (NTP).

Jeśli węzły w systemie Avamar nie są zsynchronizowane czasem, możemy oczekiwać następujących typów zachowań:

• Nie można uruchomić serwera Avamar
• Węzły przechodzą w tryb offline
• HfScheck kończy się niepowodzeniem z MSG_ERR_CGSAN_FAILED
• HfScheck kończy się niepowodzeniem z MSG_ERR_HFSCHECKERRORS
• Punkty kontrolne nie powiodła się
• Zbieranie śmieci kończy się niepowodzeniem
• Problemy ze spójnością danych (jeśli czas zmienia się podczas zbierania śmieci)

Przykłady komunikatów o błędach powszechnie zgłaszanych w wyniku utraty synchronizacji czasu:

• samconn::checkallsucceed request failed DPNTIMECHECK=230 
• BŁĄD KRYTYCZNY: <Niezgodność czasu 0001> dpn: synchronizacja zegarów i ponawienie próby
• ERROR: <0001> dpncheckmanager::verifyStartup cgsan died unexpectedly. terminating  
• brak wystarczającej liczby prawidłowych odpowiedzi otrzymanych w odpowiednim czasie

Ten artykuł pomaga czytnikowi ustalić, czy w systemie Avamar występuje problem z synchronizacją czasu. Rozwiązanie problemu wykracza poza zakres niniejszego artykułu.

Istnieje wiele witryn poświęconych rozwiązywaniu problemów z NTP, a czytnik jest zachęcamy do ich zbadania. Przydatne adresy URL dostępne w momencie pisania znajdują się w sekcji "łącza zewnętrzne".

Aby kontynuować:
1. Zaloguj się do serwera Avamar jako administrator na kb Avamar: Jak zalogować się do serwera Avamar i załadować różne klucze.

2. Aby ustalić, czy węzły Avamar są zsynchronizowane, sprawdź bieżącą godzinę i datę każdego węzła w systemie Avamar. Przykładowe dane wyjściowe można znaleźć w ZAŁĄCZNIKU A .

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

Jeśli wszystkie węzły zgłaszają tę samą datę i godzinę, oznacza to, że czas jest w pełni zsynchronizowany między wszystkimi węzłami w tym systemie.

3. Aby utrzymać synchronizację czasu w węzłach, Avamar używa protokołu Network Time Protocol (NTP). Polecenie "ntpq -pn" systemu Linux przywraca stan synchronizacji czasu. Przykładowy wynik można znaleźć w ZAŁĄCZNIKU B .

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

4. Ogólne spostrzeżenia dotyczące serwerów Avamar:

• Wszystkie węzły preferują 128.xxx.xxx.xx jako główne źródło czasu.
• Dodatkowe źródło czasu dla wszystkich węzłów to lokalny zegar BIOS w sekcji "avmtest1" (węzeł 0.s).
• Tertiary time source is set to be avmtest2 (węzeł 0.0), który samo w sobie odnosi się do avmtest1.
• Wszystkie węzły są synchronizowane z avmtest1. Serwer czasu oznaczony gwiazdką (*) to serwer, z którą węzeł jest aktualnie synchronizowany.
• W takim przypadku plik 128.xxx.xxx.xx znajduje się zdalnie. Ma wartość "reach" 0 (obecnie nieosiągalna). Jest on niepotrzebny jako źródło czasu.
• Avmtest1 i avmtest2 mają rejestr dostępności ok. 377. Jest to najwyższa osiągalna wartość. W związku z tym wszystkie węzły synchronizują się z dodatkowym źródłem.

5. Patrząc na dane wyjściowe ntpq dla węzła 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

• Węzeł 0.2 sonduje avmtest1 co 256 sekund
• Węzeł 0.2 jest obecnie synchronizowany z avmtest1
• avmtest1 jest w warstwie 9, co oznacza, że węzeł 0.2 jest w warstwie 10.
• Węzeł 0.2 sonduje avmtest1 raz na 256 sekund.
• Rejestr dostępności dla avmtest1 to ok. 376.
• Zegar w avmtest1 wynosi 0,116 milisekund (lub 116 mikrosekund) za zegarem w avmtest1.
• Opóźnienie w obiegzie do avmtest1 wynosi 85 milisekund.
• Pomiar różnicy opóźnień w sieci (zakłócenia) między węzłem 0.2 i avmtest1 wynosi 2 milisekundy.

Konfiguracja NTP (/etc/ntp.conf):
w przypadku przeglądania pliku /etc/ntp.conf w węźle 0.2 odpowiada powyższemu wyjściu ntpq .

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

Rejestrowania:
Rejestrowanie NTP jest kierowana do pliku /var/log/messages .
Aby wyświetlić rejestrowanie związane z NTP, grep zawartość /var/log/messages* dla "ntp"

Jeśli zewnętrzny serwer czasu jest nierzetelny, jak w powyższym przykładzie, można użyć wewnętrznego serwera czasu. Czas wewnętrzny może powoli oddalać się od UTC, ale najważniejsze jest to, że węzły danych są synchronizowane ze sobą czasem.

Za pomocą narzędzia Avamar asktime można wybrać nowe, preferowane źródła czasu ntp.
Patrz Avamar: Konfigurowanie protokołu NTP na serwerze Avamar za pomocą asktime 

Informacje dodatkowe:
http://support.microsoft.com/kb/939322 — kontrolery domeny systemu Windows nie powinny być używane do dobrego przechowywania czasu.