ECS: xDoctor: RAP081: Symptom Code: 2048: Tutti i server NTP NON sono adatti per la sincronizzazione

Tutti i nodi in un rack ECS devono avere il daemon NTP in esecuzione e i server NTP configurati devono essere in grado di sincronizzare l'ora. In caso contrario, potrebbero verificarsi problemi con l'acquisizione dei dati front-end.

I sintomi di cui sopra rimangono come AVVERTENZA se non si verificano entro 24 ore.
Dopo 24 ore, se il problema persiste, la gravità viene aumentata a ERROR, e viene segnalato un RAP081.

Ciò significa che ogni nodo elencato nel campo "Extra" non può essere sincronizzato con il server NTP.

Verifica:
1. Ottenere l'elenco dei server NTP in tutti i nodi elencati:

Comando:

# getrackinfo -r | grep NTP

Esempio:

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

2. Per ogni server NTP elencato nel passaggio 1, verificare se è in grado di sincronizzare l'ora.

Comando:

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

Oppure

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

Esempio (in grado di sincronizzare l'ora):

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 gio giu 14 09:26:52 UTC 2018 (1)
Ricerca dell'indirizzo><IP NTP host e dell'indirizzo> IP ntp NTP<
del servizio invertiti in <host NTP hostname>
trovati: <Nome host>
NTP trasmissione (<indirizzo> IP NTP)
ricezione (<indirizzo> IP NTP)
trasmissione (<indirizzo> IP NTP)
ricezione (<indirizzo> IP NTP)
indirizzo IP> NTP del server<, porta 123
strato 2, precisione -24, salto 00, attendibilità 000
refid [<indirizzo> IP NTP], ritardo 0,02615, dispersione 0,00003
trasmesso 2, nel filtro 2
tempo di riferimento:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Timestamp di origine: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Timestamp di trasmissione:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Ritardo filtro:  0,02635 0,02615 0,00000 0,00000
0,00000 0,00000 0,00000 0,00000
Offset filtro: 0.000043 -0.00002 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000 0.000000
ritardo 0.02615, dispersione 0.00003
offset -0.000022

22 feb 13:47:50 ntpdate[110901]: regola l'offset dell'indirizzo> IP NTP del server <dell'ora -0,000022 sec

Esempio: (se la sincronizzazione dell'orario rilevato non riesce)

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 gio giu 14 09:26:52 UTC 2018 (1)
Ricerca dell'indirizzo><IP NTP host e dell'indirizzo> IP ntp NTP<
del servizio invertiti in <host NTP hostname>
trovati: <Nome host>
NTPtrasmissione (<indirizzo> IP NTP)
trasmissione (<indirizzo> IP NTP)
trasmissione (<indirizzo> IP NTP)
indirizzo> IP NTP del server<, porta 123
strato 2, precisione -24, salto 00, attendibilità 000
refid [<indirizzo> IP NTP], ritardo 0,02615, dispersione 0,00003
trasmesso 2, nel filtro 2
tempo di riferimento:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
Timestamp di origine: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
Timestamp di trasmissione:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
Ritardo filtro:  0,02635 0,02615 0,00000 0,00000
0,00000 0,00000 0,00000 0,00000
Offset filtro: 0.000043 -0.00002 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000 0.000000
ritardo 0.02615, dispersione 0.00003
offset -0.000022

22 Feb 13:47:50 ntpdate[112232]: Nessun server adatto alla sincronizzazione trovato

3. Aggiungere l'FQDN alla sezione NTP nel risultato getrackinfo -r.

Comando:

# sudo setrackinfo -a FQDN NTPServer < NTP >

4. Verificare la separazione della rete e le route statiche, in quanto il protocollo NTP inviato dall'interfaccia di gestione tramite Policy-Based Routing potrebbe causare il problema.

Comando:

Esempio:

Comando:

# sudo ntpq -c come

Esempio: (Di seguito vediamo un server NTP che non è raggiungibile e l'altro si sta bloccando probabilmente a causa di un ACL)

admin@node1:~> sudo ntpq -c as
ind assid status conf reach condizione di autenticazione last_event cnt
===========================================================
1 56633 8011 sì no nessuno rifiuta mobilitazione 1

6. Verificare se ci sono differenze nella data in NTP. 

Comando:

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

Esempio:

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

7. Check for the ntpd service status and then restart the service. (anche se lo stato è attivo, procedere con il riavvio). 
Nota: ntpd.service è un servizio privo di impatto.

Comando:

# viprexec systemctl status ntpd.service | grep Active:

Esempio:

admin@node1:~> viprexec systemctl status ntpd.service | grep Active:
   Attivo: attivo (in esecuzione) dal Mar 06/08/2019 02:49:06 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal Mar 2019-08-06 02:49:07 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal mer 2019-08-07 20:13:27 UTC; 58min fa
Attivo: attivo (in esecuzione) dal mar 2019-08-06 02:49:06 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal mar 2019-08-06 02:49:07 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal mar 2019-08-06 02:49:07 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal Mar 06/08/2019 02:49:07 UTC; 1 giorno 18h fa
Attivo: attivo (in esecuzione) dal Mar 2019-08-06 02:49:07 UTC; 1 giorno 18h fa

Comando: 

# viprexec systemctl riavviare ntpd.service

Esempio:

admin@node1:~> viprexec systemctl restart ntpd.service
Output from host: 192.168.219.8
Uscita dall'host : 192.168.219.7
Uscita dall'host : 192.168.219.6
Uscita dall'host : 192.168.219.4
Output dall'host : 192.168.219.3
Uscita dall'host : 192.168.219.2
Uscita dall'host : 192.168.219.5
Uscita dall'host : 192.168.219.1

8. Controllare il file md5sum ntp.conf in tutti i nodi.

Comando:

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

Esempio:

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

Output dall host: 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Output dall host: 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Output dall host: 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Nota: Ciò potrebbe essere dovuto alla presenza di interfacce pubbliche e di gestione e i nodi sono tutti configurati per uscire dal pubblico in base all'ultima configurazione fornita. Nelle versioni precedenti di ECS, PBR può bloccarsi nei casi in cui un nodo è valido e il resto dei nodi sembra essere protetto da un firewall.

9. Aggiungere 123 a ns_mgmt nel risultato di getrackinfo -r, quindi controllare se NTP ha iniziato le operazioni di trasmissione e ricezione.

Comando:

# sudo setrackinfo -a ns_mgmt 123

Esempio:

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

Se l'errore persiste, riposizionare la porta 123 nell'interfaccia pubblica e verificare nuovamente la sincronizzazione.

Comando:

# sudo setrackinfo -d ns_mgmt 123

Esempio:

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

Controllare lo stato della sincronizzazione NTP dopo aver eseguito ciascuno dei passaggi precedenti.

Risoluzione:
Ciò significa che il server configurato non è un server NTP o che non funziona come previsto. Il team di rete del cliente deve essere coinvolto per risolvere il problema NTP.