ECS: xDoctor: RAP081: Symptomkode: 2048: Alle NTP-servere er IKKE egnede til synkronisering

Alle noder i et ECS-rack skal have NTP-dæmonen kørende, og de konfigurerede NTP-servere skal være i stand til at synkronisere tiden. Hvis ikke, kan dette medføre problemer med frontend-dataindtagelse.

Ovenstående symptomer forbliver som en ADVARSEL, hvis det ikke forekommer inden for 24 timer.
Hvis dette fortsætter efter 24 timer, øges alvorligheden til en FEJL, og der rapporteres en RAP081.

Det betyder, at hver node, der er angivet i feltet 'Ekstra', ikke kan synkroniseres med NTP-serveren.

Kontrol:
1. Hent en liste over NTP-servere på hver af de viste noder:

Kommando:

# getrackinfo -r | grep NTP

Eksempel:

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

2. For hver NTP-server, der er angivet i trin 1, skal du teste, om den er i stand til at synkronisere tiden.

Kommando:

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

Eller

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

Eksempel (i stand til at synkronisere tid):

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 Thu Jun 14 09:26:52 UTC 2018 (1)
Leder du efter vært <NTP IP-adresse> og service ntp NTP
<IP-adresse> vendt til <NTP værtsnavn>
vært fundet: <NTP-værtsnavn>
transmission (<NTP IP-adresse>)
modtag (<NTP IP-adresse>)
transmission (<NTP IP-adresse>)
modtag (<NTP IP-adresse>)
server <NTP IP-adresse>, port 123
lag 2, præcision -24, spring 00, tillid 000
refid [<NTP IP-adresse>], forsinkelse 0.02615, spredning 0.00003
transmitteret 2, i filter 2
referencetid:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Originate tidsstempel: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Sendetidsstempel:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Filter forsinkelse:  0,02635 0,02615 0,00000 0,00000
0,00000 0,00000 0,00000 0,00000
Filter forskydning: 0,000043 -0,00002 0,0000000 0,0000000
0,000000 0,0000000 0,000000 0,000000
forsinkelse 0,02615, spredning 0,00003
forskydning -0,000022

22 Feb 13:47:50 ntpdate[110901]: juster tidsserverens <NTP IP-adresseforskydning> -0,000022 sek

Eksempel: (Hvis den ikke kan synkronisere tid, giver den outputtet)

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 Thu Jun 14 09:26:52 UTC 2018 (1)
Leder du efter vært <NTP IP-adresse> og service ntp NTP
<IP-adresse> vendt til <NTP værtsnavn>
vært fundet: <NTP-værtsnavn>
transmission (<NTP IP-adresse>)
transmission (<NTP IP-adresse>)
transmission (<NTP IP-adresse>)
server <NTP IP-adresse>, port 123
lag 2, præcision -24, spring 00, tillid 000
refid [<NTP IP-adresse>], forsinkelse 0.02615, spredning 0.00003
transmitteret 2, i filter 2
referencetid:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Originate tidsstempel: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Sendetidsstempel:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Filter forsinkelse:  0,02635 0,02615 0,00000 0,00000
0,00000 0,00000 0,00000 0,00000
Filter forskydning: 0,000043 -0,00002 0,0000000 0,0000000
0,000000 0,0000000 0,000000 0,000000
forsinkelse 0,02615, spredning 0,00003
forskydning -0,000022

22 Feb 13:47:50 ntpdate[112232]: ingen server egnet til synkronisering fundet

3. Føj FQDN til NTP-sektionen i getrackinfo -r-resultatet.

Kommando:

# sudo setrackinfo -en NTPServer < NTP FQDN >

4. Kontroller, om der er netværksadskillelse og statiske ruter, da NTP, der sendes fra administrationsgrænsefladen via politikbaseret routing, kan forårsage problemet.

Kommando:

Eksempel:

Kommando:

# sudo ntpq -c som

Eksempel: (Nedenfor ser vi en NTP-server, der ikke kan nås, og den anden blokerer sandsynligvis på grund af en ACL)

admin@node1:~> sudo ntpq -c as
ind assid status conf reach auth condition last_event CNT
===========================================================
1 56633 8011 ja nej ingen afvise mobilisere 1

6. Kontrollér, om der er nogen datoafvigelse i NTP. 

Kommando:

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

Eksempel:

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

7. Se efter status for ntpd-tjenesten, og genstart så tjenesten. (Selvom status kører, skal du fortsætte med genstarten.) 
Bemærk: ntpd.service er en non-impact-tjeneste.

Kommando:

# viprexec systemctl status ntpd.service | grep Active:

Eksempel:

admin@node1:~> viprexec systemctl status ntpd.service | grep Aktiv:
   Aktiv: aktiv (løb) siden tirs 2019-08-06 02:49:06 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden tirs 2019-08-06 02:49:07 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden ons 2019-08-07 20:13:27 UTC; 58min siden
Aktiv: aktiv (løb) siden Tir 2019-08-06 02:49:06 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden Tir 2019-08-06 02:49:07 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden Tir 2019-08-06 02:49:07 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden tirs 2019-08-06 02:49:07 UTC; 1 dag 18 timer siden
Aktiv: aktiv (løb) siden tirs 2019-08-06 02:49:07 UTC; 1 dag 18 timer siden

Kommando: 

# viprexec systemctl genstart ntpd.service

Eksempel:

admin@node1:~> viprexec systemctl genstart ntpd.service
Output fra vært: 192.168.219.8
Output fra værten: 192.168.219.7
Output fra værten: 192.168.219.6
Output fra værten: 192.168.219.4
Output fra værten: 192.168.219.3
Output fra værten: 192.168.219.2
Output fra vært: 192.168.219.5
Output fra værten: 192.168.219.1

8. Verificer md5sum ntp.conf-filen på alle noderne.

Kommando:

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

Eksempel:

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

Output fra vært: 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Output fra vært: 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output fra vært: 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Bemærk: Dette kan skyldes at have en offentlig og administrationsgrænseflade, og noderne er alle konfigureret til at gå ud af offentligheden i henhold til den sidst leverede konfiguration. På ældre versioner af ECS kan PBR sidde fast, hvor en node er gyldig, og resten af noderne syntes at være bag en firewall.

9. Tilføj 123 til "ns_mgmt i getrackinfo-r"-resultatet, og kontroller derefter, om NTP er begyndt at sende og modtage.

Kommando:

# sudo setrackinfo -en ns_mgmt 123

Eksempel:

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

Hvis fejlen stadig vedvarer, skal du placere port 123 tilbage til den offentlige grænseflade og igen kontrollere synkroniseringen.

Kommando:

# sudo setrackinfo -d ns_mgmt 123

Eksempel:

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

Kontroller status for NTP-synkroniseringen efter udførelse af hvert af ovenstående trin.

Opløsning:
Det betyder, at serveren, som den er konfigureret, ikke er en NTP-server, eller at den ikke fungerer som forventet. Kundens netværksteam skal være engageret for at løse NTP-problemet.