ECS: xDoctor: RAP081: Symptom Code: 2048: Alle NTP-Server sind NICHT für die Synchronisierung geeignet.

Auf allen Nodes in einem ECS-Rack sollte der NTP-Daemon ausgeführt werden und die konfigurierten NTP-Server sollten in der Lage sein, die Zeit zu synchronisieren. Andernfalls kann dies zu Problemen bei der Front-end-Datenaufnahme führen.

Die oben genannten Symptome bleiben als WARNUNG bestehen, wenn sie nicht innerhalb von 24 Stunden auftreten.
Wenn dies nach 24 Stunden weiterhin auftritt, wird der Schweregrad auf ERROR erhöht und RAP081 wird gemeldet.

Das bedeutet, dass auf jedem Node, der im Feld "Extra" aufgeführt ist, keine Synchronisierung mit dem NTP-Server durchgeführt werden kann.

Überprüfung:
1. Rufen Sie die Liste der NTP-Server auf jedem der aufgelisteten Nodes ab:

Befehl:

# getrackinfo -r | grep-NTP

Beispiel:

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

2. Testen Sie für jeden in Schritt 1 aufgeführten NTP-Server, ob er in der Lage ist, die Zeit zu synchronisieren.

Befehl:

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

Oder

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

Beispiel (in der Lage, die Zeit zu synchronisieren):

admin@node1:~> sudo ntpdate -p 2 -d xxx.xxx.xxx.xxx
22 Feb 13:47:48 ntpdate[110901]: ntpdate 4.2.8p11@1.3728-o Do Jun 14 09:26:52 UTC 2018 (1)
Suche nach Host-NTP-IP-Adresse <> und Dienst NTP-NTP-IP-Adresse
>< wurde auf NTP-Hostnamen-Host
>umgekehrt:< <NTP-Hostname übertragen(<NTP-IP-Adresse>)
empfangen(<NTP-IP-Adresse)übertragen(NTP-IP-Adresse>>)
empfangen(<<NTP-IP-Adresse>)

Server <NTP-IP-Adresse>, Port 123
Stratum 2, Präzision -24, Sprung 00, Vertrauen 000
refid [<NTP-IP-Adresse>], Verzögerung 0,02615, Dispersion 0,00003
übertragen 2, in Filter 2
Referenzzeit:>
    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
ursprünglicher Zeitstempel: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Zeitstempel übertragen:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Filterverzögerung:  0.02635 0.02615 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
Filter-Offset: 0,000043 -0,00002 0,000000 0,000000
0,000000 0,000000 0,000000 0,000000
Verzögerung 0,02615, Streuung 0,00003
Offset -0,000022

22 Feb 13:47:50 ntpdate[110901]: Zeitserver <anpassen NTP IP-Adressen-Offset> -0.000022 sec

Beispiel: (Wenn er nicht in der Lage ist, die Zeit zu synchronisieren, wird es ausgegeben)

admin@node1:~> sudo ntpdate -p 2 -d xxx.xxx.xxx.xxx
22 Feb 13:47:48 ntpdate[110901]: ntpdate 4.2.8p11@1.3728-o Do Jun 14 09:26:52 UTC 2018 (1)
Suche nach Host-NTP-IP-Adresse <> und Dienst NTP-NTP-IP-Adresse
>< wurde auf NTP-Hostnamen-Host
>umgekehrt:< <NTP-Hostname>
transmit(<NTP-IP-Adresse>)
transmit(<NTP-IP-Adresse)transmit(<NTP-IP-Adresse>>)

server <NTP-IP-Adresse>, Port 123
Stratum 2, Genauigkeit -24, leap 00, trust 000
refid [<NTP-IP-Adresse>], Verzögerung 0,02615, Dispersion 0,00003
übertragen 2, in Filter 2
Referenzzeit:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
ursprünglicher Zeitstempel: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Zeitstempel übertragen:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Filterverzögerung:  0.02635 0.02615 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
Filter-Offset: 0,000043 -0,00002 0,000000 0,000000
0,000000 0,000000 0,000000 0,000000
Verzögerung 0,02615, Streuung 0,00003
Offset -0,000022

22. Feb. 13:47:50 ntpdate[112232]: kein für die Synchronisation geeigneter Server gefunden

3. Fügen Sie den FQDN im Ergebnis getrackinfo -r zum NTP-Abschnitt hinzu.

Befehl:

# sudo setrackinfo -a NTPServer < NTP FQDN >

4. Überprüfen Sie die Netzwerktrennung und statische Routen, da NTP, das von der Managementschnittstelle über Policy-basiertes Routing gesendet wird, das Problem verursachen kann.

Befehl:

Beispiel:

Befehl:

# sudo ntpq -c as

Beispiel: (Unten sehen wir einen NTP-Server, der nicht erreichbar ist und der andere blockiert wahrscheinlich aufgrund einer ACL)

admin@node1:~> sudo ntpq -c as
ind assid status conf Erreichen der Authentifizierungsbedingung last_event CNT
===========================================================
1 56633 8011 Ja Nein Keine Ablehnen Mobilisieren 1

6. Prüfen Sie, ob es eine Datumsabweichung im NTP gibt. 

Befehl:

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

Beispiel:

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

7. Überprüfen Sie den Status des ntpd-Dienstes und starten Sie den Dienst neu. (Auch wenn der Status "Up" lautet, fahren Sie mit dem Neustart fort.) 
Hinweis: Der ntpd.service ist ein Dienst ohne Auswirkung.

Befehl:

# viprexec systemctl status ntpd.service | grep Active:

Beispiel:

admin@node1:~> viprexec systemctl status ntpd.service | grep Aktiv:
   Aktiv: aktiv (läuft) seit Di 06.08.2019 02:49:06 UTC; vor 1 Tag 18 Std
. Aktiv: aktiv (laufend) seit Di 06.08.2019 02:49:07 UTC; vor 1 Tag 18 Std
. Aktiv: aktiv (laufend) seit Mi 07.08.2019 20:13:27 UTC; vor 58min
Aktiv: aktiv (laufend) seit Di 06.08.2019 02:49:06 UTC; vor 1 Tag 18h Aktiv
: aktiv (laufend) seit Di 06.08.2019 02:49:07 UTC; vor 1 Tag 18Std
. Aktiv: aktiv (laufend) seit Di 06.08.2019 02:49:07 UTC; vor 1 Tag 18 Std
. Aktiv: aktiv (läuft) seit Di 06.08.2019 02:49:07 UTC; vor 1 Tag 18 Std
. Aktiv: aktiv (laufend) seit Di 06.08.2019 02:49:07 UTC; vor 1 Tag 18 Std.

Befehl: 

# viprexec systemctl neu starten ntpd.service

Beispiel:

admin@node1:~> viprexec systemctl neu starten ntpd.service
Ausgabe vom Host: 192.168.219.8
Ausgabe von Host: 192.168.219.7
Ausgabe von Host: 192.168.219.6
Ausgabe von Host : 192.168.219.4
Ausgabe von Host : 192.168.219.3
Ausgabe von Host : 192.168.219.2
Ausgabe von Host: 192.168.219.5
Ausgabe vom Host : 192.168.219.1

8. Überprüfen Sie die md5sum ntp.conf-Datei auf allen Nodes.

Befehl:

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

Beispiel:

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

Ausgabe vom Host: 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Ausgabe vom Host: 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Ausgabe vom Host: 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Hinweis: Dies kann darauf zurückzuführen sein, dass öffentliche und Managementschnittstellen vorhanden sind und die Nodes gemäß der zuletzt bereitgestellten Konfiguration alle so konfiguriert sind, dass sie nicht mehr öffentlich sind. Bei älteren Versionen von ECS kann PBR hängen bleiben, wenn ein Node gültig ist und der Rest der Nodes hinter einer Firewall zu sein scheint.

9. Fügen Sie 123 zu ns_mgmt im Ergebnis von getrackinfo -r hinzu und prüfen Sie dann, ob das NTP mit dem Senden und Empfangen begonnen hat.

Befehl:

# sudo setrackinfo -a ns_mgmt 123

Beispiel:

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

Sollte der Fehler weiterhin bestehen, platzieren Sie Port 123 wieder an der öffentlichen Schnittstelle und überprüfen Sie erneut die Synchronisation.

Befehl:

# sudo setrackinfo -d ns_mgmt 123

Beispiel:

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

Überprüfen Sie den Status der NTP-Synchronisierung, nachdem Sie jeden der oben genannten Schritte ausgeführt haben.

Auflösung:
Das bedeutet, dass der Server in der konfigurierten Form kein NTP-Server ist oder nicht wie erwartet funktioniert. Das Netzwerkteam des Kunden muss einbezogen werden, um das NTP-Problem zu lösen.