Descripción

El complemento de comprobación de estado Nutanix NCC check_ntp verifica la configuración NTP de las CVM (Controller VM) y los hosts del hipervisor. También verifica si hay desviaciones de tiempo en el clúster.

El complemento check_ntp contiene varias comprobaciones individuales que se centran en escenarios específicos relacionados con NTP:

• Sincronización de tiempo CVM/PCVM NTP: determina si el CVM/PCVM puede sincronizar el tiempo con cualquiera de los servidores NTP configurados
• Hypervisor NTP time synchronization (AHV + ESXi only): determina si el host puede sincronizar la hora con cualquiera de los servidores NTP configurados

Nota: Verificación de configuración de NTP, el ID de verificación 103076 se retiró en la versión 4.0.0 de NCC.

Este complemento también se ejecuta en Prism Central (PC), a excepción de la verificación del hipervisor.

Este complemento de verificación de estado se introdujo en la versión 3.1 de NCC y reúne todas las verificaciones de NTP de versiones anteriores de NCC. En Prism Central, esta verificación se introdujo en la versión 3.5.3 de NCC. La función de alerta de estos controles se introdujo en NCC 3.6.2.

Posibles Causas

Si esta verificación de estado devuelve un resultado de NO APROBADO, las siguientes son posibles causas:

• No hay servidores NTP configurados en el clúster.
• No hay servidores NTP configurados en el hipervisor.
• Todos o algunos servidores NTP configurados en el hipervisor no son los mismos que los configurados en las CVM o PC VM.
• No se puede acceder a un servidor NTP configurado o no responde a las consultas de NTP.
• Un servidor NTP configurado no es confiable ni estable.
• El servidor NTP está configurado con un nombre de host, pero no se puede resolver debido a problemas de resolución de nombres/DNS.
• El puerto NTP (UDP/123) no está abierto.
• La hora en el clúster no está sincronizada y se encuentra en el futuro por al menos 5 segundos en comparación con la hora real en los servidores NTP.
• El servidor NTP pasa un parámetro que el cliente NTP de CVM o PC VM considera inadecuado para la sincronización NTP, como un alto valor de dispersión, compensación, fluctuación, alcance o estrato.
• Un servidor NTP basado en Windows (AD PDC) que usa su reloj local como su fuente de tiempo, de manera predeterminada, se anunciará como una fuente NTP menos adecuada al incluir un valor de dispersión de 10 segundos en el parámetro NTP de ese servidor. W32time no está diseñado con la precisión requerida para NTP y no garantiza una tolerancia superior a +/- 5 minutos.
• El servicio de génesis se reinició recientemente y la sincronización de NTP aún está pendiente, o si se cambió la configuración de NTP, el efecto puede tardar algún tiempo. Según el protocolo NTP, se tarda unos 5 minutos (cinco muestras buenas) hasta que se acepta un servidor NTP como fuente de sincronización. Esperar y volver a ejecutar la verificación después de 10 a 15 minutos puede producir un resultado diferente si esto ha proporcionado suficiente tiempo para que el cambio surta efecto y se sincronice.

  Por ejemplo, después de reiniciar genesis, el comando ntpq muestra que la hora aún se está sincronizando con .LOCL.

Luego, después de esperar 10-15 minutos, el comando ntpq ahora muestra:

Por lo tanto, volver a ejecutar la verificación de inmediato fallará, pero volver a ejecutarla después de un tiempo, digamos 10-15 minutos, debería PASAR.

Los síntomas y el impacto.

Si esta verificación de estado devuelve un resultado de NO PASA, la operación del clúster puede estar en riesgo de varios síntomas o impactos, como:

• Los usuarios no pueden iniciar sesión en la consola web de Prism mediante LDAP u otros servicios integrados de directorio.
• El clúster no puede iniciarse o funcionar correctamente debido a un desfase de tiempo importante después de una interrupción o mantenimiento.
• Registro y recopilación de registros inexactos.
• Los resultados inexactos de las comprobaciones de estado se basan en marcos de tiempo precisos y en la correlación de eventos.
• Gráficos incorrectos y sesgados en Prism.
• Máquinas virtuales de usuario que se inician en hosts de hipervisor con RTC (relojes en tiempo real) inexactos que provocan un sesgo de tiempo del sistema operativo invitado.
• Los productos de software de respaldo de terceros como Veeam o Commvault tienen problemas para interactuar con el clúster.
• Instantáneas que caducan demasiado pronto o demasiado tarde cuando el tiempo entre un clúster y un sitio remoto no está sincronizado

Ejecución de la comprobación de NCC

Ejecute esta verificación como parte de las Verificaciones de estado completas de NCC:

O ejecute esta verificación individualmente:

También puede ejecutar las comprobaciones desde la página Salud de la consola web de Prism: seleccione Acciones > Ejecutar comprobaciones. Seleccione Todas las comprobaciones y haga clic en Ejecutar.

Salida de muestra

Para Estado: INFO

Para estado: FALLO

Para estado: ERR

Desde NCC-4.0.0 en adelante para estado: WARN

Mensajes de salida

Nota : el ID de verificación 103076 se retiró en la versión 4.0.0 de NCC.

Solución

Para los clústeres que ejecutan ESXi 7.0.3 compilación 19193900, la verificación arrojará un falso positivo incluso después de que los servidores NTP configurados en el host y la interfaz de usuario de Prism sean los mismos.

Actualice a NCC-4.5.0.1 para mitigar el falso positivo.

Pasos generales para la solución de problemas

Si esta verificación devuelve un resultado de NO APROBADO, verifique lo siguiente:

• Al menos uno, pero preferiblemente tres o más servidores NTP confiables fuera del clúster están configurados en el clúster (CVM/PCVM) Y en los hosts (hipervisores: AHV, ESXi, Hyper-V, XenServer).
  • Para configurar servidores NTP en los CVM y AHV, consulte Configuración de servidores NTP en la Guía de la consola web de Prism . (La configuración de servidores NTP a través de Prism actualizará tanto los CVM como los hosts AHV).
  • Para configurar servidores NTP en hosts ESXi, consulte Configuración del protocolo de tiempo de red (NTP) en hosts ESX/ESXi mediante vSphere Client (2012069) .
  • Para configurar servidores NTP en hosts Hyper-V, consulte Configuración de NTP en Hyper-V a continuación.
  • Para obtener recomendaciones sobre qué servidores NTP usar, consulte Recomendaciones para la sincronización de tiempo .
• La lista de servidores NTP configurados en los hipervisores debe ser preferiblemente la misma que la configurada en los CVM.
• Si el servidor NTP se configura mediante el FQDN o el nombre de host, asegúrese de que el clúster pueda resolver la dirección IP para el FQDN NTP en todos los servidores de nombres DNS configurados. Una configuración de servidor de nombres no válida en Prism puede impedir que se utilicen los servidores NTP y provocar problemas de sincronización de tiempo.
• El puerto de destino del protocolo NTP (UDP 123) está abierto a los servidores NTP de destino a través de cualquier ACL/cortafuegos en la ruta de red entre todos los CVM/hosts y los servidores NTP.
• Pruebe y haga ping a los servidores NTP utilizando FQDN y direcciones IP para establecer una conectividad de red básica. Tenga en cuenta que algunos ACL/cortafuegos pueden bloquear intencionalmente el tráfico de ping (eco ICMP) pero aún así permitir UDP/123, por lo tanto, considere que un resultado inalcanzable no es necesariamente una causa raíz, sino una posible comprensión de los problemas de conectividad de la red. Use el siguiente paso para validar más.
• Independientemente de la accesibilidad del servidor NTP haciendo ping en la red, asegúrese de que esté en buen estado y responda en la capa de la aplicación con consultas NTP válidas y utilizables y que devuelva información de tiempo precisa. Puede verificar si las consultas NTP devuelven información de tiempo ejecutando el siguiente comando:
  nutanix@cvm$ /usr/sbin/ntpdate -t 10 -q
• Verifique el estado de la sincronización NTP en todos los CVM y hosts mediante el procedimiento Revisar el resultado del comando "ntpq -pn" a continuación.
• Verifique la configuración NTP en todos los hosts utilizando el procedimiento Revisión del contenido del archivo ntp.conf a continuación.
• Esta verificación puede producir un resultado de NO APROBADO después de configurar NTP si la hora aún no se ha sincronizado con la configuración de NTP nueva/actualizada. Si el servidor NTP se agregó recientemente y la hora de CVM no se considera en el futuro (compensación negativa del servidor NTP), esta verificación puede activarse hasta que el protocolo NTP haya encontrado una fuente NTP estable y adecuada y CVM haya sincronizado correctamente (~10 minutos).
• Si los servidores NTP configurados no son fuentes confiables de estrato 0 (GPS/reloj atómico), deben tener una fuente de hora externa de estrato adecuado (0-3 es bueno) configurada y no deben sincronizarse con el reloj local de ese servidor o una fuente de tiempo interna.

Notas:

• Se sabe que la sincronización de un clúster Nutanix AOS/PC con una fuente de tiempo basada en Windows causa problemas durante un período de tiempo. Consulte KB 3851 Solución de problemas de sincronización NTP con servidores de tiempo de Windows .
  Nutanix recomienda que no sincronice la hora de un clúster con las fuentes de tiempo de Windows . En su lugar, utilice fuentes horarias fiables que no sean de Windows . Consulte Recomendaciones para la sincronización horaria en la Guía de la consola web de Prism .
• ¡No utilice un servidor NTP como fuente para un clúster y/o hipervisor de Nutanix si el servidor NTP real es una máquina virtual de usuario que se ejecuta como invitado en el mismo clúster! Esto no es confiable, es impredecible en las interrupciones y reinicios de la máquina virtual del usuario y del clúster, y no se recomienda.
• No necesita configurar manualmente los servidores NTP en los hosts AHV. La configuración de servidores NTP a través de Prism/ncli actualizará los hosts CVM y AHV.
• Cuando se usa la consola web de Prism o ncli para agregar los servidores NTP en un clúster AOS basado en ESXi, los servidores NTP no se agregan automáticamente al archivo /etc/ntp.conf del host. Después de agregar los servidores NTP en Prism, también debe configurar manualmente esos servidores NTP en los hosts ESXi. Para obtener más información sobre la configuración de servidores NTP en los hosts ESXi, consulte Configuración del protocolo de tiempo de red (NTP) en hosts ESX/ESXi mediante vSphere Client (2012069) .
• En un clúster de hipervisor mixto (AHV + ESXi), como se mencionó anteriormente, los hosts AHV se configurarán a través de Prism, pero debe configurar manualmente los servidores NTP en los hosts ESXi del clúster de hipervisor mixto.
• En un clúster de Hyper-V, el complemento check_ntp valida solo la configuración de CVM NTP. No verifica el NTP o la configuración de tiempo de los hosts de Windows Hyper-V, por lo que la verificación no da como resultado un estado FALLO si el hipervisor está mal configurado o no está sincronizado con las fuentes NTP o AD PDC. Confirme manualmente que los hosts de Hyper-V y los controladores de dominio tengan una jerarquía de tiempo de Windows saludable. Los AD PDC deben usar fuentes de tiempo NTP ascendentes confiables en paralelo a los CVM, potencialmente los mismos servidores NTP (consulte el siguiente punto).
• Idealmente, para simplificar la comparación de registros y evitar la clasificación compleja de problemas de sincronización de tiempo, los hipervisores y las máquinas virtuales del controlador deberían usar los mismos servidores NTP. Si los hipervisores y las máquinas virtuales del controlador usan servidores NTP diferentes, esta verificación de estado puede producir una salida de INFORMACIÓN para generar conciencia y garantizar que se trata de una configuración consciente y razonable en lugar de una configuración incorrecta accidental y para resaltar rápidamente este hecho durante cualquier otra solución de problemas no relacionada. evento en caso de que surja en cualquier momento durante la producción de clústeres.

Para obtener más información y mejores prácticas sobre la sincronización de tiempo de clúster de Nutanix, consulte Sincronización de tiempo de clúster en la Guía de la consola web de Prism en el Portal de soporte de Nutanix .

Pasos específicos para la solución de problemas

• Si la verificación informa "INFORMACIÓN: Los servidores NTP configurados en el hipervisor xxxx difieren de los configurados en Zeus config xxxx", configure los mismos servidores NTP en el clúster y en los hipervisores.
• Si la verificación informa "FALLA: el líder NTP no se está sincronizando con ningún servidor NTP externo porque la hora del clúster está en el futuro en relación con los servidores NTP externos: xxxx", es posible que el clúster se haya iniciado sin un estado de sincronización NTP válido y extrayendo el tiempo de CVM hacia atrás puede afectar las operaciones de metadatos de almacenamiento en tránsito. Para resolver este problema particular de la hora futura de CVM, registre un caso con el Soporte de Nutanix para obtener más ayuda y no cambie manualmente ninguna fecha/hora de CVM.
• Si la verificación informa "FALLA: el líder NTP no se está sincronizando con ningún servidor NTP externo", siga los pasos generales de solución de problemas anteriores. En caso de que los pasos mencionados anteriormente no resuelvan el problema, registre un caso con el Soporte de Nutanix , proporcionando los resultados y cualquier resultado de la resolución de problemas generales y la configuración NTP del clúster actual.
• Si la verificación informa "FALLA: el hipervisor no se está sincronizando con ningún servidor NTP", siga los pasos generales de solución de problemas anteriores. En caso de que los pasos mencionados anteriormente no resuelvan el problema, siga los pasos a continuación:
  1. En el host, reinicie el servicio ntpd mediante el procedimiento Reinicio del servicio ntpd que se describe a continuación.
  2. Compruebe si el host ahora está sincronizando la hora con NTP utilizando el procedimiento Revisar el resultado del comando "ntpq -pn" a continuación. Asegúrese de esperar ~10 minutos para la sincronización.
  3. Si no todos los hosts se sincronizan correctamente, siga el procedimiento Revisar el contenido del archivo ntp.conf a continuación.
  4. Si el problema aún no se resuelve, considere comunicarse con el Soporte de Nutanix , proporcionar los resultados y cualquier resultado de la resolución de problemas generales y la configuración NTP del clúster actual.
• Si la verificación informa "FALLO: este CVM es el líder NTP pero no está sincronizando la hora con ningún servidor NTP externo" y ha verificado que se ha configurado el servidor NTP:
  1. Los servidores NTP configurados pueden verse abrumados y/o limitar deliberadamente la cantidad de solicitudes de clientes NTP para responder para protegerse de DDoS (accidental o de otro tipo), por lo tanto, no responder a las solicitudes NTP válidas del líder CVM NTP. Puede investigar si su servidor NTP está limitando la velocidad de las solicitudes al inspeccionar el archivo de registro del servicio CVM genesis en busca de una entrada de línea de error que contenga " respuesta de límite de velocidad del servidor ":
     nutanix@cvm$ allssh "grep -A 1 -i 'límite de velocidad' ~/data/logs/genesis.out | tail"
     ...
     2018-12-12 11:03:14 ERROR node_manager.py:3941 La actualización de Systime con ntpdate falló con el error: 1: 12 de diciembre 11:03:14 ntpdate[26695]: respuesta de límite de velocidad nnn101 del servidor.
     2018-12-12 11:03:14 ntpdate[26695]: no se encontró ningún servidor adecuado para la sincronización
     1. Si no controla el servidor NTP afectado, elimínelo de la configuración NTP de Prism y agregue un servidor NTP diferente y más confiable.
     2. Si controla la configuración del servidor NTP de origen, considere agregar excepciones de restricción para las direcciones IP de host/CVM. Consulte la propia documentación de su servidor NTP para obtener más detalles. Por ejemplo, en un servicio ntpd basado en Linux, sería necesario agregar la siguiente línea al archivo /etc/ntp.conf del servidor NTP y luego recargarla:
        restringir máscara
  2. La hora de CVM puede adelantarse a la hora del servidor NTP y el servicio de génesis de CVM evitará intencionalmente la sincronización de NTP. Esto se puede evidenciar aún más en los registros de Génesis del CVM afectado al ejecutar el siguiente comando y buscar un desplazamiento negativo entre el origen de CVM y NTP:
     nutanix@cvm$ allssh "grep -i ntp /home/nutanix/data/logs/genesis.out | cola"
     Salida de ejemplo:
     2019-02-03 22:42:11 INFO node_manager.py:2314 Consultando servidores NTP ascendentes: 10.xx11
     2019-02-03 22:42:12 INFO node_manager.py:2334 Compensación NTP: -89.328 segundos
     2019-02-03 22:42:12 INFO node_manager.py:2354 El tiempo está por delante del servidor NTP externo por 89.328 segundos, no sincronizando el tiempo mientras se ejecutan los servicios de clúster
     2019-02-03 22:42:12 INFO node_manager.py:2230 Reiniciando el servidor NTP.
     2019-02-03 23:02:13 ERROR node_manager.py:2450 NTP externo aún inutilizable (0)
     2019-02-03 23:02:13 ADVERTENCIA node_manager.py:2456 Deshabilitar servidores NTP ascendentes
     2019-02-03 23:02:13 INFO node_manager.py:2202 Deteniendo el servidor NTP.
     2019-02-03 23:02:13 INFO node_manager.py:2230 Reiniciando el servidor NTP.
     2019-02-03 23:12:13 INFO node_manager.py:2314 Consultando servidores NTP ascendentes: 10.xx11
     2019-02-03 23:12:13 INFO node_manager.py:2334 Compensación NTP: -89.297 segundos
     
     En el resultado del ejemplo anterior, el clúster no se sincroniza con un servidor NTP recién agregado. En esta situación, el servidor NTP se ejecuta 89 segundos por detrás del CVM y, por lo tanto, se considera inutilizable como fuente NTP.
     Importante: Si la hora CVM es en el futuro, ¡NO ajuste manualmente el reloj hacia atrás ! Póngase en contacto con el soporte de Nutanix para obtener ayuda y proporcione el resultado anterior.
• Si la verificación informa "ERR: No se pudo ejecutar ntpq en el host": Ejecute el siguiente comando en cada CVM y asegúrese de que el comando se ejecute correctamente.
  nutanix@cvm$ ntpq -pn

  Si el comando no se ejecuta o la verificación de NCC informa un estado de ERR nuevamente, investigue los CVM para obtener memoria libre. Registre un caso con Nutanix Support para obtener más ayuda.

Revisando la salida del comando " ntpq -pn "

El comando ' ntpq -pn ' es el comando principal utilizado por esta verificación para identificar el estado de sincronización NTP del CVM o del host.

Cada línea de los resultados tendrá el formato: (Solo salida de ejemplo. Las IP reales, las filas de servidores NTP y los valores relacionados diferirán según las configuraciones individuales)

Donde remoto es el par o servidor remoto con el que se está sincronizando. “127.127.1.0 LOCL” es este host local (incluido en caso de que no haya pares o servidores remotos disponibles).

El primer carácter que se muestra en la tabla es una bandera de estado. Se espera un estado sincronizado, representado por el '*' como el primer carácter de una entrada del servidor NTP remoto.

Nota: este estado sincronizado tarda entre 10 y 15 minutos en producirse si el servicio de génesis con la función de líder NTP ha cambiado recientemente o si se ha modificado la configuración del servidor NTP.

1. Para verificar el estado de NTP en todos los CVM, ejecute el siguiente comando desde un CVM:
   nutanix@cvm$ allssh ntpq -pn
   El siguiente ejemplo es un buen resultado: muestra que el líder NTP de CVM está sincronizado con un servidor NTP externo y los otros CVM están sincronizados con el líder NTP de CVM.
   ================== 10.xx.xx.61 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   +10.xxx.xxx.21 10.xx.xx.15 4 u 654 1024 377 0,812 -1,026 0,429
   +10.xxx.xxx.22 10.xx.xx.15 4 u 997 1024 377 0,830 -0,998 0,533
   +10.xxx.xxx.10 10.xx.xx.15 4 u 409 1024 377 1.365 -1.159 5.158
   *10.xxx.xxx.11 10.xx.xx.15 4 u 579 1024 377 1.626 -1.055 0.326 <--- Sincronizado con un servidor NTP configurado 10.xx.xx.11
   127.127.1.0 .LOCL. 10 l 27h 64 0 0.000 0.000 0.000
   ================== 10.xx.xx.62 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Sincronizado con el líder CVM NTP 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Sincronizado con el líder CVM NTP 10.xx.xx.61
   
   A continuación se muestra un ejemplo de un resultado problemático. El líder CVM NTP se sincroniza solo con su reloj local:
   ================== 10.xx.xx.61 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   127.127.1.0 .LOCL. 10 l 27h 64 0 0.000 0.000 0.000 <--- CVM NTP líder sincronizado solo con su reloj local
   ================== 10.xx.xx.62 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 1065 1024 377 0.353 2.584 1.355 <--- Sincronizado con el líder CVM NTP 10.xx.xx.61
   ================== 10.xx.xx.63 =================
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.61 10.xx.xx.11 5 u 722 1024 377 0.192 1.775 1.682 <--- Sincronizado con el líder CVM NTP 10.xx.xx.61
   
   Si se está utilizando la IP '127.127.1.0', significa que los CVM se están sincronizando solo con el líder NTP ('127.127.1.0' es una IP de host local) y NO se está sincronizando con ningún servidor NTP externo en el momento en que se realizó la verificación. realizado.
2. Para verificar el estado de NTP en todos los hosts/hipervisores, ejecute el siguiente comando desde un CVM:
   nutanix@cvm$ hostssh ntpq -pn
   
   El siguiente ejemplo es un buen resultado. Todos los hosts se sincronizan con los mismos servidores NTP.
   ============= 192.xx.xx.1 ============
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.15 218.1xx.xx.70 2 u 822 1024 377 96.679 12.968 3.105
   10.xx.xx.16 .INIC. 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 27 1024 377 0.609 -23.479 4.167
   ============= 192.xx.xx2 ============
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 8 1024 157 2.513 3.510 2.980
   10.xx.xx.16 .INIC. 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 253 1024 377 0,665 -8,794 5,203
   ============= 192.xx.xx.3 ============
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   *10.xx.xx.15 218.xx.xx.70 2 u 184 1024 377 96.566 17.003 4.010
   10.xx.xx.16 .INIC. 16 u - 1024 0 0.000 0.000 0.000
   +10.xx.xx.21 203.xx.xx.251 3 u 394 1024 377 0.659 -18.181 5.601
   Si las direcciones IP de NTP no son consistentemente las mismas en todos los hosts, verifique /etc/ntp.conf para ver si están usando un nombre de host/FQDN que representa un grupo de servidores NTP. Los grupos de NTP están formados por muchas entradas de DNS rotativas, por lo que en el momento de la inicialización, la respuesta de DNS dada a cada host cuando inicia el servicio NTP puede devolver una dirección IP diferente para usar como servidor NTP.
3. Si ve el siguiente mensaje en un host AHV cuando ejecuta ntpq :
   No se ha devuelto ningún ID de asociación
   
   Confirme si está ejecutando un kernel AHV el6 ejecutando los siguientes comandos:
   nutanix@cvm$ ssh root@192.168.5.1
   [root@ahv]# cat /etc/nutanix-release
   
   Si está ejecutando en un kernel el6, verá un resultado similar al siguiente:
   el6.nutanix.20170830.151
   Para solucionar este problema temporalmente (solución alternativa), en el host, reinicie el servicio ntpd usando el procedimiento Reiniciar el servicio ntpd a continuación, luego vuelva a ejecutar esta verificación de NCC para confirmar.

   Para solucionar este problema de forma permanente, actualice AOS a 5.5.8, 5.9.2, 5.10 o posterior.

4. Si ve el siguiente mensaje en un host ESXi cuando ejecuta ntpq , significa que el host ESXi/ESX no puede comunicarse con el servidor NTP configurado:
   No se ha devuelto ningún ID de asociación
   Confirme que la hora en todos los hosts sea correcta y la misma con el comando de fecha hostssh .

   Confirme que las direcciones IP del servidor NTP estén configuradas en el host con /etc/ntp.conf.

   Confirme si la configuración del servidor DNS en los hosts es correcta con el siguiente comando:

   nutanix@cvm$ ssh root@192.168.5.1 esxcli red ip dns lista de servidores >>> Para verificar en un solo host
   nutanix@cvm$ hostssh "esxcli network ip dns server list" >>> Para comprobar todos los hosts
   
   Para resolver esto, corrija la configuración del servidor DNS con el siguiente comando. Alternativamente, agregue la configuración de DNS correcta en Center:
   [root@Esxi:~]esxcli network ip dns server add --server=
5. Si ve el siguiente mensaje en un host AHV cuando ejecuta ntpq :
   Nombre o servicio desconocido
   Este problema puede deberse a que el comando ntpq no puede resolver "localhost" en 127.0.0.1.

   Para solucionar este problema, registre un caso con el Soporte de Nutanix proporcionando los resultados y cualquier resultado de la resolución de problemas generales y la configuración NTP del host actual.

6. Es posible que vea el siguiente tipo de salida cuando ejecuta ntpq -pn en PCVM:
   nutanix@PCVM:~$ ntpq -pn
   refid remoto st t cuando el sondeo alcanza la fluctuación de compensación de retardo
   ================================================== ============================
   x10.48.147.26 .GNSS. 1u 30 64 377 0.910 -4549.1 22.565
   x10.65.140.26 .GNSS. 1u 58 64 377 0.251 -4527.7 15.504
   *127.127.1.0 .LOCL. 10 l 29 64 277 0,000 0,000 0,000
   nutanix@NTNX-10-66-154-101-A-PCVM:~$
   Para obtener más información sobre el comando ntpq , consulte la página del manual de ntpq .

Revisando el contenido del archivo ntp.conf

1. Revise el resultado del comando ntpq -pn mediante el procedimiento anterior.
2. Si no todos los hosts AHV o ESXi sincronizan la hora con NTP, verifique los archivos /etc/ntp.conf de todos los hosts.

   A continuación se muestra un resultado de muestra en el que solo 2 de 3 hosts se sincronizan correctamente con NTP.

   nutanix@cvm$ hostssh cat /etc/ntp.conf
   ============= 10.xx.xx.1 ============
   restringir por defecto kod nomodify notrap nopeer noquery
   restringir 127.0.0.1
   servidor 10.xx.xx.8
   archivo de deriva /etc/ntp.drift
   ============= 10.xx.xx.2 ============
   restringir por defecto kod nomodify notrap nopeer noquery
   restringir 127.0.0.1
   servidor 10.xx.xx.8
   archivo de deriva /etc/ntp.drift
   ============= 10.xx.xx.3 ============
   tinker panic 0
   servidor 10.xx.xx.8
   archivo de deriva /var/lib/ntp/deriva
   archivo de registro /var/log/ntp.log
   restringir 10.8.xx máscara 255.255.255.0 nomodificar notrap
   interfaz ignorar comodín
   interfaz escucha br0
   restringir 127.0.0.1
   restringir -6 ::1
   restringir por defecto kod nomodify notrap nopeer noquery
   restringir -6 por defecto kod nomodify notrap nopeer noquery
   deshabilitar monitor
   En la configuración de muestra anterior, los hosts 10.xx.xx.1 y 10.1xx.xx.2 se sincronizan correctamente con NTP, mientras que 10.xx.xx.3 falla porque restringe la sincronización de NTP.
3. Para resolver esto, siga los Pasos generales de solución de problemas anteriores. Tenga en cuenta que los hosts AHV también se configuran junto con CVM a través de Prism.
4. En caso de un NTP ascendente transitorio o un problema de conectividad, reinicie el servicio ntpd mediante el siguiente procedimiento.
5. Espere de 5 a 10 minutos y ejecute el siguiente comando desde uno de los CVM para verificar si todos los hipervisores ahora se están sincronizando con el servidor NTP:
   nutanix@cvm$ hostssh ntpq -pn
6. Vuelva a ejecutar la comprobación de NCC.
7. Si los pasos mencionados anteriormente no resuelven el problema, registre un caso con el Soporte de Nutanix , proporcionando los resultados y cualquier resultado de la resolución de problemas generales y la configuración NTP del clúster actual.

   Nota: En ESXi, se sabe que la " interfaz escucha br0 " que aparece en /etc/ntp.conf causa el problema anterior. La línea debe eliminarse y el servicio ntpd debe reiniciarse.

Reinicio del servicio ntpd/w32time

En AHV el6 o ESXi, ejecute:

En AHV el7 ejecutar:

Para verificar si la versión AHV instalada pertenece a la familia el6 o el7, use el comando:

 [raíz@AHV]# uname -r
4.19.84-2.el7.nutanix.20190916.410.x86_64

En Hyper-V, ejecute:

Configuración de NTP en Hyper-V

Los hosts de Hyper-V 2016 usan el controlador de dominio como NTP. Para configurar fuentes NTP externas en los controladores de dominio de Active Directory:

1. Abra un símbolo del sistema en el controlador de dominio con permisos administrativos.
2. Detener el servicio de tiempo:
   C:\> parada neta w32time
3. Configure los servidores externos de la lista de pares manual:
   C:\> w32tm /config /syncfromflags:manual /manualpeerlist:” ”
4. Establezca la conexión como confiable:
   C:\> w32tm /config /confiable:sí
5. Inicie la copia de seguridad del servicio horario:
   C:\> inicio neto w32time
6. Pruebe la configuración:
   C:\> w32tm /consulta /configuración y w32tm /consulta /estado

información adicional

• Nutanix KB 4519 - Documento original en Nutanix Portal