ECS: xDoctor: RAP081: Symptom Code: 2048: Wszystkie serwery NTP NIE nadają się do synchronizacji

Wszystkie węzły w szafie serwerowej ECS powinny mieć uruchomionego demona NTP, a skonfigurowane serwery NTP powinny mieć możliwość synchronizacji czasu. Jeśli nie, może to prowadzić do problemów z pozyskiwaniem danych frontonu.

Powyższe objawy pozostają OSTRZEŻENIEM, jeśli nie wystąpią w ciągu 24 godzin.
Jeśli po 24 godzinach ten problem nie ustąpi, poziom ważności zostanie zwiększony do BŁĘDU i zostanie zgłoszony błąd RAP081.

Oznacza to, że na każdym węźle wymienionym w polu "Extra" nie można przeprowadzić synchronizacji z serwerem NTP.

Weryfikacja:
1. Pobierz listę serwerów NTP na każdym z wymienionych węzłów:

Polecenie:

# getrackinfo -r | grep NTP

Przykład:

admin@node1:~> getrackinfo -r | grep NTP
NTP NTPServer = xxx.xxx.xxx.xxx

2. Dla każdego serwera NTP wymienionego w kroku 1 sprawdź, czy jest on w stanie synchronizować czas.

Polecenie:

# sudo ntpdate -p 2 -d <Adres IP NTP / nazwa FQDN NTP>

Lub

# sudo ntpdate -p 2 -d 'getrackinfo -r | grep NTP |grep -oP "(?:[0-9]{1,3}\.) {3} [0-9] {1,3}"'

Przykład (możliwość synchronizacji czasu):

admin@node1:~> sudo ntpdate -p 2 -d xxx.xxx.xxx.xxx
22 lut 13:47:48 ntpdate[110901]: ntpdate 4.2.8p11@1.3728-o czw cze 14 09:26:52 UTC 2018 (1)
Szukam adresu> IP hosta <NTP i usługi ntp
<Znaleziono adres> IP NTP odwrócony do <hosta NTP hosta hosta>
: <Nazwa hosta>
NTP transmit(<Adres> IP NTP)
receive(<Adres> IP NTP)
transmit(<Adres> IP NTP)
receive(<Adres> IP NTP)
serwer <Adres> IP NTP, port 123
warstwa 2, precyzja -24, leap 00, zaufanie 000
refid [<Adres> IP NTP], opóźnienie 0.02615, dyspersja 0.00003
przesłana 2, w filtrze 2
czas odniesienia:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Originate Timestamp: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
transmituj znacznik czasu:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
opóźnienie filtra:  0.02635 0.02615 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
Przesunięcie filtra: 0,000043 -0,00002 0,000000 0,000000
0,000000 0,000000 0,000000 0,000000
opóźnienie 0,02615, dyspersja 0,00003
offset -0,000022

22 lut 13:47:50 ntpdate[110901]: dostosuj przesunięcie adresu> IP NTP serwera <czasu -0.000022 sec

Przykład: (Jeśli nie jest w stanie synchronizować czasu danych wyjściowych)

admin@node1:~> sudo ntpdate -p 2 -d xxx.xxx.xxx.xxx
22 lut 13:47:48 ntpdate[110901]: ntpdate 4.2.8p11@1.3728-o czw cze 14 09:26:52 UTC 2018 (1)
Szukam adresu> IP hosta <NTP i usługi ntp
<Znaleziono adres> IP NTP odwrócony do <hosta NTP hosta hosta>
: <Transmisja nazwy hostaNTP (<Adres> IP NTP)
transmisja (<Adres> IP NTP)
transmit (<Adres> IP NTP)
serwer <Adres> IP NTP, port 123
warstwa 2, precyzja -24, skok 00, zaufanie 000
refid [<Adres> IP NTP], opóźnienie 0,02615, dyspersja 0,00003
przesłana 2, czas odniesienia w filtrze 2
:>
    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Originate Timestamp: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
transmituj znacznik czasu:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
opóźnienie filtra:  0.02635 0.02615 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
Przesunięcie filtra: 0,000043 -0,00002 0,000000 0,000000
0,000000 0,000000 0,000000 0,000000
opóźnienie 0,02615, dyspersja 0,00003
offset -0,000022

22 lut 13:47:50 ntpdate[112232]: nie znaleziono serwera odpowiedniego do synchronizacji

3. Dodaj nazwę FQDN do sekcji NTP w getrackinfo -r wyniku.

Polecenie:

# sudo setrackinfo -a NTPServer < NTP FQDN >

4. Sprawdź separację sieci i trasy statyczne, ponieważ problem może powodować NTP wysyłane z interfejsu zarządzania za pośrednictwem routingu opartego na zasadach.

Polecenie:

Przykład:

Polecenie:

# sudo ntpq -c as

Przykład: (Poniżej widzimy jeden serwer NTP, który jest nieosiągalny, a drugi blokuje prawdopodobnie z powodu listy ACL)

admin@node1:~> sudo ntpq -c as
ind assid status conf osiągnąć warunek uwierzytelniania last_event cnt
===========================================================
1 56633 8011 tak nie brak odrzucić mobilizować 1

6. Sprawdź, czy w NTP są jakiekolwiek odchylenia w dacie. 

Polecenie:

# viprexec "data +%s" 2>&1 | grep "^15"

Przykład:

admin@node1:~>viprexec "data +%s" 2>&1 | grep "^15"
1554470147
1554470111
1554470096
1554470142
1554470144 1554470109

1554470124
1554470140

7. Sprawdź stan usługi ntpd, a następnie uruchom ponownie usługę. (Nawet jeśli stan jest włączony, uruchom ponownie komputer). 
Uwaga: Usługa ntpd jest usługą niemającą wpływu.

Polecenie:

# viprexec systemctl status ntpd.service | grep Active:

Przykład:

admin@node1:~> viprexec systemctl status ntpd.service | grep Aktywny:
   Aktywna: aktywna (uruchomiona) od wt 2019-08-06 02:49:06 UTC; 1 dzień 18h temu
Aktywny: aktywny (uruchomiony) od wt 2019-08-06 02:49:07 UTC; 1 dzień 18h temu
Aktywny: aktywny (biega) od śr 2019-08-07 20:13:27 UTC; 58min temu
Aktywny: aktywny (uruchomiony) od wt 2019-08-06 02:49:06 UTC; 1 dzień 18h temu
Aktywny: aktywny (działa) od wt 2019-08-06 02:49:07 UTC; 1 dzień 18h temu
Aktywny: aktywny (uruchomiony) od wt 2019-08-06 02:49:07 UTC; 1 dzień 18h temu
Aktywny: aktywna (uruchomiona) od Tue 2019-08-06 02:49:07 UTC; 1 dzień 18h temu
Aktywny: aktywny (uruchomiony) od wt 2019-08-06 02:49:07 UTC; 1 dzień 18h temu

Polecenie: 

# viprexec systemctl restart ntpd.service

Przykład:

admin@node1:~> viprexec systemctl restart ntpd.service
Dane wyjściowe z hosta: 192.168.219.8
Dane wyjściowe z hosta: 192.168.219.7
Dane wyjściowe z hosta: 192.168.219.6
Dane wyjściowe z hosta: 192.168.219.4
Dane wyjściowe z hosta: 192.168.219.3
Dane wyjściowe z hosta: 192.168.219.2
Dane wyjściowe z hosta: 192.168.219.5
Dane wyjściowe z hosta: 192.168.219.1

8. Sprawdź plik md5sum ntp.conf na wszystkich węzłach.

Polecenie:

# viprexec "sudo md5sum /etc/ntp.conf"

Przykład:

admin@node1:~> viprexec "sudo md5sum /etc/ntp.conf"

Dane wyjściowe z hosta: 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Dane wyjściowe z hosta: 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Uwaga: Może to być spowodowane posiadaniem interfejsów publicznych i zarządzania, a wszystkie węzły są skonfigurowane tak, aby były niepubliczne zgodnie z ostatnią podaną konfiguracją. W starszych wersjach ECS PBR może utknąć w miejscu, w którym jeden węzeł jest prawidłowy, a pozostałe wydają się znajdować za zaporą sieciową.

9. Dodaj 123 do ns_mgmt w wyniku getrackinfo -r, a następnie sprawdź, czy NTP rozpoczął transmisję i odbieranie.

Polecenie:

# sudo setrackinfo -a ns_mgmt 123

Przykład:

admin@node1:~>sudo setrackinfo -a ns_mgmt 123

Jeśli błąd nadal występuje, umieść port 123 z powrotem w interfejsie publicznym i ponownie sprawdź synchronizację.

Polecenie:

# sudo setrackinfo -d ns_mgmt 123

Przykład:

admin@node1:~> sudo setrackinfo -d ns_mgmt 123

Sprawdź stan synchronizacji NTP po wykonaniu każdego z powyższych kroków.

Rezolucja:
Oznacza to, że skonfigurowany serwer nie jest serwerem NTP lub nie działa zgodnie z oczekiwaniami. Aby rozwiązać problem NTP, należy zaangażować zespół sieciowy klienta.