ECS : xDoctor : RAP081 : Code symptôme : 2048 : Tous les serveurs NTP ne sont PAS adaptés à la synchronisation

Le processus NTP doit être en cours d’exécution sur tous les nœuds d’un rack ECS, et les serveurs NTP configurés doivent pouvoir synchroniser l’heure. Si ce n’est pas le cas, cela peut entraîner des problèmes d’ingestion des données front-end.

Les symptômes ci-dessus restent comme un AVERTISSEMENT s’ils ne se produisent pas dans les 24 heures.
Au bout de 24 heures, si le problème persiste, la gravité passe à l’état ERROR, et un RAP081 est signalé.

Cela signifie que chaque nœud répertorié dans le champ « Extra » ne peut pas être synchronisé avec le serveur NTP.

Vérification :
1. Obtenez la liste des serveurs NTP sur chacun des nœuds répertoriés :

Commande :

# getrackinfo -r | grep NTP

Exemple :

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

2. Pour chaque serveur NTP répertorié à l’étape 1, testez s’il est capable de synchroniser l’heure.

Commande :

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

ou

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

Exemple (capable de synchroniser l’heure) :

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)
Looking for host <NTP IP Address> and service ntp<
NTP IP Address> reversed to <NTP hostname>
host found : <NTP hostname>
transmit(<NTP IP Address>)
receive(<NTP IP Address>)
transmit(<NTP IP Address>)
receive(<NTP IP Address>)
server <NTP IP Address>, port 123
stratum 2, precision -24, leap 00, trust 000
refid [<NTP IP Address>], delay 0.02615, dispersion 0.00003
transmit 2, in filter 2
reference time :    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
originate timestamp : e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
transmit timestamp :  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
filter delay :  0.02635 0.02615 0.00000 0.000000
0.00000 0.000000 0.000000 0.00000
filter offset : 0.000043 -0.000002 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000 0.000000
retard 0.02615, dispersion 0.00003
décalage -0.000022

22 Feb 13:47:50 ntpdate[110901] : adjust time server <NTP IP address> offset -0.000022 sec

Exemple : (Sortie obtenue s’il n’est pas capable de synchroniser la date)

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)
Looking for host <NTP IP Address> and service ntp<
NTP IP Address> reversed to <NTP hostname>
host found : <NTP hostnametransmit(<NTP IP Address>)
transmit(<NTP IP Address>)
transmit(<NTP IP Address>)
server <NTP IP Address>, port 123
stratum 2, precision -24, leap 00, trust 000
refid [<NTP IP Address>], delay 0.02615, dispersion 0.00003
transmit 2, in filter 2
reference time :>
    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
originate timestamp : e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
transmit timestamp :  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
filter delay :  0.02635 0.02615 0.00000 0.000000
0.00000 0.000000 0.000000 0.00000
filter offset : 0.000043 -0.000002 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000 0.000000
retard 0.02615, dispersion 0.00003
décalage -0.000022

22 Feb 13:47:50 ntpdate[112232] : aucun serveur adapté à la synchronisation trouvé

3. Ajoutez le FQDN à la section NTP dans le résultat getrackinfo -r.

Commande :

# sudo setrackinfo -a NTPServer < NTP FQDN >

4. Vérifiez la séparation du réseau et les routes statiques, car le NTP envoyé depuis l’interface de gestion via un routage basé sur des règles peut être à l’origine du problème.

Commande :

Exemple :

Commande :

# sudo ntpq -c as

Exemple : (Ci-dessous, nous voyons un serveur NTP qui n’est pas accessible et l’autre bloque probablement en raison d’une ACL)

admin@node1 :~> sudo ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 56633 8011 yes no none reject mobilize 1

6. Vérifiez qu’il n’y a aucun décalage de date dans le NTP. 

Commande :

# viprexec « date +%s » 2>&1 | grep « ^15 »

Exemple :

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

7. Vérifiez l’état du service ntpd, puis redémarrez le service. (Même si l’état est en cours d’exécution, procédez au redémarrage.) 
Remarque : le service ntpd est un service sans impact.

Commande :

# viprexec systemctl status ntpd.service | grep Active:

Exemple :

admin@node1 :~> viprexec systemctl status ntpd.service | grep Active :
   Actif : actif (en cours d’exécution) depuis le mardi 2019-08-06 02:49:06 UTC ; il y a
1 jour 18h Active : active (running) since Tue 2019-08-06 02:49:07 UTC ; 1 day 18h ago
Active : active (running) since Wed 2019-08-07 20:13:27 UTC ; 58min ago
Active : active (running) since Tue 2019-08-06 02:49:06 UTC ; 1 day 18h
ago Active : active (running) since Tue 2019-08-06 02:49:07 UTC ; 1 day 18h ago
Active : active (running) since Tue 2019-08-06 02:49:07 UTC ; 1 day 18h ago
Active : actif (en cours d’exécution) depuis le mardi 2019-08-06 02:49:07 UTC ; il y a
1 jour 18h Actif : actif (en cours d’exécution) depuis le mardi 2019-08-06 02:49:07 UTC ; il y a 1 jour 18h

Commande : 

# viprexec systemctl restart ntpd.service

Exemple :

admin@node1 :~> viprexec systemctl restart ntpd.service
Sortie de l’hôte : 192.168.219.8
Sortie de l’hôte : 192.168.219.7
Sortie de l’hôte : 192.168.219.6
Sortie de l’hôte : 192.168.219.4
Sortie de l’hôte : 192.168.219.3
Sortie de l’hôte : 192.168.219.2
Sortie de l’hôte : 192.168.219.5
Sortie de l’hôte : 192.168.219.1

8. Vérifiez le fichier md5sum ntp.conf sur tous les nœuds.

Commande :

# viprexec « sudo md5sum /etc/ntp.conf »

Exemple :

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

Sortie de l’hôte : 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Sortie de l’hôte : 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Sortie de l’hôte : 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Remarque : Cela peut être dû à la présence d’une interface publique et d’une interface de gestion, et les nœuds sont tous configurés pour devenir non publics conformément à la dernière configuration fournie. Sur les anciennes versions d’ECS, PBR peut être bloqué lorsqu’un nœud est valide et que les autres nœuds semblent être derrière un pare-feu.

9. Ajoutez 123 à ns_mgmt dans le résultat getrackinfo-r, puis vérifiez si le NTP a commencé à transmettre et recevoir.

Commande :

# sudo setrackinfo -a ns_mgmt 123

Exemple :

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

Si l’erreur persiste, replacez le port 123 sur l’interface publique et vérifiez à nouveau la synchronisation.

Commande :

# sudo setrackinfo -d ns_mgmt 123

Exemple :

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

Vérifiez l’état de la synchronisation NTP après avoir effectué chacune des étapes ci-dessus.

Résolution:
Cela signifie que le serveur tel que configuré n’est pas un serveur NTP ou qu’il ne fonctionne pas comme prévu. L’équipe réseau du client doit être impliquée pour résoudre le problème NTP.