Estos contenidos se han traducido de forma automática para su comodidad, pero Huawei Cloud no garantiza la exactitud de estos. Para consultar los contenidos originales, acceda a la versión en inglés.

En esta página

Mostrar todo

Centro de ayuda/ MapReduce Service/ Guía del usuario/ Referencia de alarma (aplicable a MRS 3.x)/ ALM-12012 El servicio NTP es anormal

ALM-12012 El servicio NTP es anormal

Actualización más reciente 2023-11-20 GMT+08:00

Ver PDF

Descripción

El sistema comprueba si el servicio NTP en un nodo sincroniza el tiempo con el servicio NTP en el nodo OMS activo cada 60 segundos. Esta alarma se genera cuando el servicio NTP no sincroniza el tiempo durante dos veces consecutivas.

Esta alarma se genera cuando la diferencia de tiempo entre el servicio NTP en un nodo y el servicio NTP en el nodo OMS activo es mayor o igual a 20s durante dos veces consecutivas. Esta alarma se borra cuando la diferencia de tiempo es inferior a 20s.

Atributo

ID de alarma	Gravedad de la alarma	Borrar automáticamente
12012	Importante	Sí

Parámetros

Nombre	Significado
Source	Especifica el clúster o sistema para el que se genera la alarma.
ServiceName	Especifica el servicio para el que se genera la alarma.
RoleName	Especifica el rol para el que se genera la alarma.
HostName	Especifica el host para el que se genera la alarma.

Impacto en el sistema

El tiempo en el nodo es inconsistente con el de otros nodos del clúster. Por lo tanto, es posible que algunas aplicaciones de FusionInsight en el nodo no se ejecuten correctamente.

Causas posibles

El servicio NTP en el nodo actual no puede iniciarse correctamente.
El nodo actual no puede sincronizar la hora con el servicio NTP en el nodo OMS activo.
El valor de clave autenticado por el servicio NTP en el nodo actual es incompatible con el del nodo OMS activo.
El desplazamiento de tiempo entre el nodo y el servicio NTP en el nodo OMS activo es grande.

Procedimiento

Compruebe el modo de servicio NTP del nodo.

Inicie sesión en el nodo de gestión activo como usuario root, ejecute el comando su - omm para cambiar a usuario omm y ejecute el siguiente comando para comprobar el estado de los recursos en los nodos activo y en espera:

sh ${BIGDATA_HOME}/om-server/om/sbin/status-oms.sh
- Si aparece "chrony" en la columna ResName de la salida del comando, vaya a 2.
- Si aparece "ntp" en la columna ResName, vaya a 20.
NOTA:

Si tanto "chrony" como "ntp" se muestran en la columna ResName de la salida del comando, el modo de servicio NTP se está conmutando. Espere 10 minutos y vaya de nuevo a 1. Si tanto la "chrony" como la "ntp" persisten, comuníquese con el personal de.

Verifique si el servicio chrony en el nodo se inició correctamente.

En FusionInsight Manager, seleccione O&M > Alarm > Alarms. En la página que se muestra, haga clic en en la fila que contiene la alarma y vea el nombre del host para el que se genera la alarma en Location.
Compruebe si el proceso chronyd se está ejecutando en el nodo donde se genera la alarma. Inicie sesión en el nodo para el que se genera la alarma como usuario root y ejecute el comando ps -ef | grep chronyd | grep -v grep para comprobar si la salida del comando contiene el proceso chronyd.
- En caso afirmativo, vaya a 6.
- Si no, vaya a 4.
Ejecute el comando systemctl chronyd start para iniciar el servicio NTP. (Actualmente, solo se admiten CentOS y Red Hat Enterprise Linux 7.0 o posterior.)
Compruebe si la alarma se borra 10 minutos después.
- En caso afirmativo, no es necesario hacer nada más.
- Si no, vaya a 6.

Compruebe si el nodo actual puede sincronizar la hora correctamente con el servicio chrony en el nodo OMS activo.

Compruebe si el nodo puede sincronizar la hora con el servicio NTP en el nodo OMS activo basado en información adicional de la alarma.
- En caso afirmativo, vaya a 7.
- Si no, vaya a 17.
Compruebe si la sincronización con el servicio chrony en el nodo OMS activo es defectuosa.

Inicie sesión en el nodo para el que se genera la alarma como usuario root y ejecute el comando chronyc sources.

En la salida del comando, si hay un asterisco (*) antes de la dirección IP del servicio chrony en el nodo OMS activo, la sincronización es normal. La salida del comando es la siguiente:
```
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 10.10.10.162             10  10   377   626    +16us[  +15us] +/-  308us
```
En la salida del comando, si no hay un asterisco (*) antes de la dirección IP del servicio NTP en el nodo OMS activo y el valor de Reach es de 0, la sincronización es anormal.
```
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^? 10.1.1.1                      0  10     0     -     +0ns[   +0ns] +/-    0ns
```
- En caso afirmativo, vaya a 8.
- Si no, vaya a 38.
La falla de sincronización de la chrony suele ser causado por el firewall del sistema. Si el firewall se puede desactivar, desactívelo. Si el firewall no se puede deshabilitar, compruebe la política de configuración del firewall y asegúrese de que los puertos UDP 123 y 323 no estén deshabilitados. (Para obtener más información, consulte la política de configuración del firewall de cada sistema.)
Compruebe si la alarma se borra 10 minutos después.
- En caso afirmativo, no es necesario hacer nada más.
- Si no, vaya a 10.
Inicie sesión en el nodo OMS activo como usuario root y ejecute el siguiente comando para ver el código de autenticación cuyo índice de valor de clave sea 1M:

En Red Hat Enterprise Linux, ejecute el comando cat ${BIGDATA_HOME}/om-server/OMS/workspace/conf/chrony.keys.
Ejecute el siguiente comando para comprobar si el valor de clave es el mismo que el consultado en 10:

En Red Hat Enterprise Linux, ejecute el comando diff ${BIGDATA_HOME}/om-server/OMS/workspace/conf/chrony.keys /etc/chrony.keys.
NOTA:
Si los valores de clave son los mismos, no se devuelve ningún resultado después de ejecutar el comando. Por ejemplo:
```
host01:~ # cat ${BIGDATA_HOME}/om-server/OMS/workspace/conf/chrony.keys       
1 M sdYbq;o^CzEAWo<U=Tw5
host01:~ # diff ${BIGDATA_HOME}/om-server/OMS/workspace/conf/chrony.keys /etc/chrony.keys
host01:~ #
```
- En caso afirmativo, vaya a 12.
- Si no, vaya a 38.
Ejecute el comando cat ${BIGDATA_HOME}/om-server/om/packaged-distributables/ntpKeyFile para comprobar si el valor de la clave es el mismo que el consultado en 10. (Compare el valor de clave con el del campo de índice de clave de autenticación 1M consultado en 10.)
- En caso afirmativo, vaya a 13.
- Si no, vaya a 15.
Inicie sesión en el nodo defectuoso como usuario root y ejecute el comando cat /etc/chrony.keys en Red Hat Enterprise Linux para comprobar si el valor de la clave es el mismo que el valor consultado en 12 (utiliza el valor de clave del campo de índice de clave de autenticación 1M para comparar).
- En caso afirmativo, vaya a 38.
- Si no, vaya a 14.
Ejecute el comando su - omm para cambiar al usuario omm, cambie el valor de clave del campo de índice de clave de autenticación 1M en ${NODE_AGENT_HOME}/chrony.keys al valor de clave de ntpKeyFile en 12, y vaya a 16.
Ejecute los siguientes comandos como usuario root o omm para cambiar el valor de clave NTP del nodo OMS activo (cambie ntp.keys a ntpkeys en Red Hat Enterprise Linux):

cd ${BIGDATA_HOME}/om-server/OMS/workspace/conf

sed -i "`cat chrony.keys | grep -n '1 M'|awk -F ':' '{print $1}'`d" chrony.keys

echo "1 M `cat ${BIGDATA_HOME}/om-server/om/packaged-distributables/ntpKeyFile`" >> chrony.keys

Compruebe si el valor de clave del campo de índice de clave de autenticación 1M en chrony.keys es el mismo que el de ntpKeyFile.
- En caso afirmativo, vaya a 16.
- Si no, cambie el valor de clave del campo de índice de clave de autenticación 1M en chrony.keys al valor de clave de ntpKeyFile y vaya a 16.
Después de 5 minutos, ejecute el comando systemctl chronyd restart para reiniciar el servicio chrony en el nodo OMS activo. Después de 15 minutos, compruebe si la alarma está desactivada.
- En caso afirmativo, no es necesario hacer nada más.
- Si no, vaya a 38.

Compruebe si la desviación de tiempo entre el nodo y el servicio chrony en el nodo OMS activo es grande.

Compruebe si la desviación de tiempo es grande en la información adicional de la alarma.
- En caso afirmativo, vaya a 18.
- Si no, vaya a 38.
En la página de pestaña Hosts, seleccione el host para el que se genera la alarma y elija More > Stop All Instances para detener todos los servicios en el nodo.

Si el tiempo en el nodo de alarma es posterior al del servicio de chrony del nodo OMS activo, ajuste el tiempo del nodo de alarma. Después de ajustar el tiempo, elija More > Start All Instances para iniciar los servicios en el nodo.

Si el tiempo en el nodo de alarma es anterior al del servicio de chrony del nodo OMS activo, espere hasta que se deba la desviación de tiempo y ajuste el tiempo del nodo de alarma. Después de ajustar el tiempo, elija More > Start All Instances para iniciar los servicios en el nodo.

NOTA:

Si no espera, puede ocurrir la pérdida de datos.
Después de 10 minutos, compruebe si la alarma está borrada.
- De ser así, no se requiere ninguna acción adicional.
- Si no, vaya a 38.

Compruebe si el servicio NTP en el nodo se inicia correctamente.

En FusionInsight Manager, seleccione O&M > Alarm > Alarms. En la página que se muestra, haga clic en en la fila que contiene la alarma y vea el nombre del host para el que se genera la alarma en Location.
Compruebe si el proceso ntpd se está ejecutando en el nodo mediante el siguiente método. Inicie sesión en el nodo de alarma como usuario root y ejecute el comando ps -ef | grep ntpd | grep -v grep para comprobar si la salida del comando contiene el proceso ntpd.
- En caso afirmativo, vaya a 24.
- Si no, vaya a 22.
Ejecute el comando service ntp start (o el comando service ntpd start en Red Hat Enterprise Linux) para iniciar el servicio NTP.
Después de 10 minutos, compruebe si la alarma está borrada.
- De ser así, no se requiere ninguna acción adicional.
- Si no, vaya a 24.

Compruebe si el nodo puede sincronizar la hora correctamente con el servicio NTP en el nodo OMS activo.

Compruebe si el nodo puede sincronizar la hora con el servicio NTP en el nodo OMS activo basado en información adicional de la alarma.
- En caso afirmativo, vaya a 25.
- Si no, vaya a 35.
Compruebe si la sincronización con el servicio NTP en el nodo OMS activo es defectuosa.

Inicie sesión en el nodo de alarma como usuario root y ejecute el comando ntpq -np.

Si existe un asterisco (*) antes de la dirección IP del servicio NTP en el nodo OMS activo en la salida del comando, la sincronización está en estado normal. La salida del comando es la siguiente:
```
remote refid st t when poll reach delay offset jitter 
============================================================================== 
*10.10.10.162 .LOCL. 1 u 1 16 377 0.270 -1.562 0.014
```
Si no hay un asterisco (*) antes de la dirección IP del servicio NTP en el nodo OMS activo, como se muestra en la siguiente salida del comando, y el valor de refid es de .INIT., la sincronización es anormal.
```
remote refid st t when poll reach delay offset jitter 
============================================================================== 
10.10.10.162 .INIT. 1 u 1 16 377 0.270 -1.562 0.014
```
- En caso afirmativo, vaya a 26.
- Si no, vaya a 38.
La falla de sincronización NTP es causado típicamente por el firewall del sistema. Si el firewall se puede deshabilitar, ejecute el comando iptables -F para deshabilitarlo. Si el firewall no se puede deshabilitar, ejecute el comando iptables -L para comprobar la política de configuración del firewall y asegurarse de que el puerto UDP 123 no esté deshabilitado. (Para obtener más información, consulte la política de configuración del firewall de cada sistema.)
Después de 10 minutos, compruebe si la alarma está borrada.
- De ser así, no se requiere ninguna acción adicional.
- Si no, vaya a 28.

Inicie sesión en el nodo OMS activo como usuario root y ejecute el siguiente comando para ver el campo de índice de clave de autenticación 1M:

En SUSE Linux, ejecute el comando cat ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntp.keys.

En Red Hat Enterprise Linux o EulerOS, ejecute el comando cat ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntpkeys.
Ejecute el siguiente comando para comprobar si el valor de clave es el mismo que el consultado en 28:

En SUSE Linux, ejecute el comando diff ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntp.keys /etc/ntp.keys.

En Red Hat Enterprise Linux o EulerOS, ejecute el comando diff ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntpkeys /etc/ntp/ntpkeys.
NOTA:
Si los valores de clave son los mismos, no se devuelve ningún resultado después de ejecutar el comando. Por ejemplo:
```
host01:~ # cat ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntp.keys       
1 M sdYbq;o^CzEAWo<U=Tw5
host01:~ # diff ${BIGDATA_HOME}/om-server/OMS/workspace/conf/ntp.keys /etc/ntp.keys
host01:~ #
```
- En caso afirmativo, vaya a 30.
- Si no, vaya a 38.
Ejecute el comando cat ${BIGDATA_HOME}/om-server/om/packaged-distributables/ntpKeyFile para comprobar si el valor de la clave es el mismo que el consultado en 28. (Compare el valor de clave con el del campo de índice de clave de autenticación 1M consultado en 28.)
- En caso afirmativo, vaya a 31.
- Si no, vaya a 33.
Inicie sesión en el nodo defectuoso como usuario root y ejecute el comando cat /etc/ntp.keys en SUSE Linux (o el comando cat /etc/ntp/ntpkeys en Red Hat Enterprise Linux) para comprobar si el valor de la clave es el mismo que el valor consultado en el 30 (utiliza el valor de clave del campo índice de clave de autenticación 1M para comparar).
- En caso afirmativo, vaya a 38.
- Si no, vaya a 32.
Ejecute el comando su - omm para cambiar al usuario omm, cambie el valor de clave del campo de índice de clave de autenticación 1M en ${NODE_AGENT_HOME}/ntp.keys (${NODE_AGENT_HOME}/ntpkeys en Red Hat Enterprise Linux) al valor clave de ntpKeyFile en 30, y vaya a 34.
Ejecute los siguientes comandos como usuario root o omm para cambiar el valor de clave NTP del nodo OMS activo (cambie ntp.keys a ntpkeys en Red Hat Enterprise Linux):

cd ${BIGDATA_HOME}/om-server/OMS/workspace/conf

sed -i "`cat ntp.keys | grep -n '1 M'|awk -F ':' '{print $1}'`d" ntp.keys

echo "1 M `cat ${BIGDATA_HOME}/om-server/om/packaged-distributables/ntpKeyFile`" >>ntp.keys

Compruebe si el valor de clave del campo índice de clave de autenticación 1M de ntp.keys es el mismo que el de ntpKeyFile.
- En caso afirmativo, vaya a 34.
- Si no, cambie el valor de clave del campo de índice de clave de autenticación 1M en ntp.keys al valor de clave de ntpKeyFile y vaya a 34.
Después de 5 minutos, ejecute el comando service ntp restart para reiniciar el servicio NTP en el nodo OMS activo. Después de 15 minutos, compruebe si la alarma está desactivada.
- De ser así, no se requiere ninguna acción adicional.
- Si no, vaya a 38.

Compruebe si la desviación de tiempo entre el nodo y el servicio NTP en el nodo OMS activo es grande.

Compruebe si la desviación de tiempo es grande en la información adicional de la alarma.
- En caso afirmativo, vaya a 36.
- Si no, vaya a 38.
En la página de pestaña Hosts, seleccione el host para el que se genera la alarma y elija More > Stop All Instances para detener todos los servicios en el nodo.

Si el tiempo en el nodo de alarma es posterior al del servicio NTP del nodo OMS activo, ajuste el tiempo del nodo de alarma. Después de ajustar el tiempo, elija More > Start All Instances para iniciar los servicios en el nodo.

Si el tiempo en el nodo de alarma es anterior al del servicio NTP del nodo OMS activo, espere hasta que venza la desviación de tiempo y ajuste el tiempo del nodo de alarma. Después de ajustar el tiempo, elija More > Start All Instances para iniciar los servicios en el nodo.

NOTA:

Si no espera, puede ocurrir la pérdida de datos.
Después de 10 minutos, compruebe si la alarma está borrada.
- De ser así, no se requiere ninguna acción adicional.
- Si no, vaya a 38.

Recopilar información de fallas.

En FusionInsight Manager, seleccione O&M. En el panel de navegación de la izquierda, elija Log > Download.
En el área Services, seleccione NodeAgent y OmmServer y haga clic en OK. Expanda el cuadro de diálogo Hosts y seleccione el nodo de alarma y el nodo OMS activo.
Haga clic en en la esquina superior derecha y establezca Start Date y End Date para la recopilación de registros en 30 minutos antes y después del tiempo de generación de alarmas respectivamente. A continuación, haga clic en Download.
Póngase en contacto con y proporcione los registros recopilados.

Eliminación de alarmas

Esta alarma se borra automáticamente después de rectificar la falla.

Información relacionada

Ninguna

Tema principal: Referencia de alarma (aplicable a MRS 3.x)

Tema anterior: ALM-12011 Excepción de sincronización de datos de Manager entre los nodos activo y en espera

Tema siguiente: ALM-12014 Partición perdida

Comentarios

¿Le pareció útil esta página?

Sí No

Deje algún comentario

Muchas gracias por sus comentarios. Seguiremos trabajando para mejorar la documentación.

El sistema está ocupado. Vuelva a intentarlo más tarde.

¿Cuáles de los siguientes problemas se presentaron?

Contenido diferente a la de la IU del producto

Descripciones poco claras

Falta de ejemplos o código

Pasos incorrectos

No puedo encontrar lo que necesito

Falta de prácticas recomendadas

Comentarios (opcional)

0/500

Seleccione al menos un tipo de problema e ingrese sus comentarios o sugerencias.

Ingrese 500 caracteres como máximo.

Enviar Cancelar