ECS: xDoctor: RAP081: Código del síntoma: 2048: Todos los servidores NTP NO son aptos para la sincronización

Todos los nodos de un rack de ECS deben tener el demonio NTP en ejecución y los servidores NTP configurados deben poder sincronizar la hora. De lo contrario, esto puede provocar problemas con la ingesta de datos de front-end.

Los síntomas anteriores permanecen como una ADVERTENCIA si no ocurren dentro de las 24 horas.
Después de 24 horas, si esto persiste, la gravedad aumentará a ERROR y se informará un RAP081.

Esto significa que en cada nodo enumerado en el campo "Extra" no se puede sincronizar con el servidor NTP.

Verificación:
1. Obtenga la lista de servidores NTP en cada uno de los nodos enumerados:

Comando:

# getrackinfo -r | grep NTP

Ejemplo:

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

2. Para cada servidor NTP enumerado en el paso 1, pruebe si es capaz de sincronizar la hora.

Comando:

# sudo ntpdate -p 2 -d <Dirección IP de NTP/FQDN de NTP>

O bien,

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

Ejemplo (capaz de sincronizar la hora):

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 Jue Jun 14 09:26:52 UTC 2018 (1)
Buscando la dirección> IP NTP del host <y la dirección> IP NTP del servicio ntp<
invertida al <host del nombre>
de host NTP NTP encontrado: <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
transmitted 2, in filter 2
reference time:    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
marca de tiempo de origen: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
marca de tiempo de transmisión:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
retraso del filtro:  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
retardo 0,02615, dispersión 0,00003
desplazamiento -0,000022

22 Feb 13:47:50 ntpdate[110901]: ajustar el servidor <de hora NTP IP> address offset -0.000022 seg

Ejemplo: (Si no es capaz de sincronizar la hora, emite)

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 Jue Jun 14 09:26:52 UTC 2018 (1)
Buscando la dirección> IP NTP del host <y la dirección> IP NTP del servicio ntp<
invertida al <host del nombre>
de host NTP NTP encontrado: <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, dispersión 0.00003
transmitted 2, in filter 2
reference time:>
    e01a7b0d.af9e6616 Fri, Feb 22 2019 13:43:41.686
marca de tiempo de origen: e01a7c06.748e0c65 Fri, Feb 22 2019 13:47:50.455
marca de tiempo de transmisión:  e01a7c06.7478b000 Fri, Feb 22 2019 13:47:50.454
retraso del filtro:  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
retardo 0,02615, dispersión 0,00003
desplazamiento -0,000022

22 Feb 13:47:50 ntpdate[112232]: no se encontró ningún servidor adecuado para la sincronización

3. Agregue el FQDN a la sección NTP en getrackinfo -r result.

Comando:

# sudo setrackinfo -a NTPServer < NTP FQDN >

4. Compruebe la separación de la red y las rutas estáticas, ya que el NTP enviado desde la interfaz de administración a través del enrutamiento basado en políticas podría causar el problema.

Comando:

Ejemplo:

Comando:

# sudo ntpq -c as

Ejemplo: (A continuación, vemos un servidor NTP que no se puede acceder y el otro está bloqueando, probablemente debido a una ACL)

admin@node1:~> sudo ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 56633 8011 Sí No Ninguno Rechazar Movilizar 1

6. Compruebe si hay algún cambio de fecha en NTP. 

Comando:

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

Ejemplo:

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

1554470109
1554470124
1554470140

7. Compruebe el estado del servicio ntpd y, a continuación, reinicie el servicio. (Incluso si el estado es activo y en ejecución, continúe con el reinicio). 
Nota: El servicio ntpd.service es un servicio sin impacto.

Comando:

# viprexec systemctl status ntpd.service | grep Activo:

Ejemplo:

admin@node1:~> viprexec systemctl status ntpd.service | grep Active:
   Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:06 UTC; Hace
1 día 18h Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:07 UTC; hace
1 día 18h Activo: activo (en ejecución) desde Mié 2019-08-07 20:13:27 UTC; hace
58min Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:06 UTC; hace
1 día 18h Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:07 UTC; hace
1 día 18h Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:07 UTC; hace 1 día 18h
Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:07 UTC; hace
1 día 18h Activo: activo (en ejecución) desde Mar 2019-08-06 02:49:07 UTC; hace 1 día 18h

Comando: 

# viprexec systemctl restart ntpd.service

Ejemplo:

admin@node1:~> viprexec systemctl restart ntpd.service
Salida del host: 192.168.219.8
Salida desde el host: 192.168.219.7
Salida desde el host: 192.168.219.6
Salida desde el host: 192.168.219.4
Salida desde el host: 192.168.219.3
Salida desde el host: 192.168.219.2
Salida del host: 192.168.219.5
Salida desde el host: 192.168.219.1

8. Verifique el archivo md5sum ntp.conf en todos los nodos.

Comando:

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

Ejemplo:

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

Salida desde el host: 192.168.219.2
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.5
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.4
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.1
7da6eb8009abc18ed1875f1f15ade72a /etc/ntp.conf

Salida desde el host: 192.168.219.3
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.8
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.6
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Salida desde el host: 192.168.219.7
741f0abb12ac82a21f150004bd407334 /etc/ntp.conf

Nota: Esto puede deberse a que tiene interfaces públicas y de administración, y todos los nodos están configurados para dejar de ser públicos según la última configuración proporcionada. En versiones anteriores de ECS, PBR se puede bloquear cuando un nodo es válido y el resto de los nodos parecen estar detrás de un firewall.

9. Agregue 123 a ns_mgmt en getrackinfo -r result y, a continuación, compruebe si el NTP ha comenzado a transmitir y recibir.

Comando:

# sudo setrackinfo -a ns_mgmt 123

Ejemplo:

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

Si el error persiste, vuelva a colocar el puerto 123 en la interfaz pública y vuelva a comprobar la sincronización.

Comando:

# sudo setrackinfo -d ns_mgmt 123

Ejemplo:

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

Compruebe el estado de la sincronización de NTP después de realizar cada uno de los pasos anteriores.

Resolución:
Esto significa que el servidor configurado no es un servidor NTP o que no funciona según lo esperado. El equipo de red del cliente debe estar comprometido para resolver el problema de NTP.