Pregunta NTP en ejecución, la hora del servidor es incorrecta en la VM


El tiempo del servidor fue de 7 horas de descanso (en lugar de las 10AM fue de 3AM, aunque date mostró la zona horaria correcta). La salida para ntpq fue:

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 xx.xxx.xxx.x.ar xxx.x.xx.xx      2 u   72 1024  177    6.516  2520657 1650156
 ntp.xxxx.ac.uk  xxx.xxx.xxx.x    2 u   7h 1024  377   14.039  2520655 1347346
 xxx.xxx.xxx.xx  xxx.xxx.xxx.x    2 u  114 1024  377    5.449  -18.941 2130343
 ns1.xxxxxxx.com xxx.x.xx.xx      2 u  148 1024  377    8.050  2520655 1650156

El tiempo fue fijado por:

ntpdate -u 0.europe.pool.ntp.org

Sin embargo, volvió a pasar unos días después. Sospecho la segunda fila en ntpq -p, que dice que ha sido 7h desde el último paquete recibido. Pero si esa es la razón, entonces ¿por qué ntp usó los otros servidores para sincronizar la hora?

¿Lo que ha sucedido? ¿Cómo evitarías que esto vuelva a suceder?

Editar Otra cosa que podría ser útil considerar es que es una máquina virtual. ¿Es posible que la máquina virtual estuviera en algún tipo de estado de pausa?

Tenga en cuenta que vmware-toolbox-cmd timesync status está desactivado.


6
2018-04-28 09:24


origen


La tercera línea de salida anterior es interesante; Parece que uno de tus servidores tiene un reloj equivocado. ¿Es ese un servidor público? (Y Alessandro tiene razón; ofuscar la lista de servidores no tiene sentido). - MadHatter
He tenido problemas para correr ntp en máquinas virtuales. A menos que el reloj sea virtual, ntpd Puede intentar modificar el reloj del sistema. Normalmente, un problema como este es el resultado de que el sistema espera que el reloj del hardware se ajuste a una hora diferente a la que realmente está configurado. El contenedor usualmente tiene un mecanismo de sincronización de tiempo, que parece estar deshabilitado. - BillThor


Respuestas:


Cuando se inicia, ntpd verifica la diferencia horaria entre su host y los servidores NTP remotos. Si esa diferencia es demasiado grande (10-15 minutos, típicamente) desperdicios para cambiar cualquier cosa.

Cuando ejecutaste ntpdate utiliza de manera efectiva una implementación SNTP más simple e instantánea que lleva su tiempo en milisegundos a lo que haría el propio ntpd. Ahora, si reinicia el servicio ntpd, debería tener un servidor sincronizado (verifique esto con ntpq -p).

Una solución simple y permanente sería el primer uso. ntpdate Al principio del proceso de arranque, y después de un tiempo, inicie el demonio "real" ntp. Para el registro, CentOS 6.xy 7.x hacen lo mismo: si instala tanto ntpdate como ntp, el primero se usará al principio del proceso de arranque, mientras que el último se usará en una etapa posterior.


5
2018-04-28 09:48



Entonces, ¿cuál podría ser la razón por la que la diferencia entre mi vm y el servidor NTP es demasiado grande? ¿Por qué no usó los otros 3 servidores? - sina
El sesgo de tiempo inicial puede ser debido a una serie de factores; por ejemplo, su VM se detuvo / suspendió y luego se reanudó. La razón por la que no se sincronizó se explica en la respuesta: el sesgo de tiempo fue demasiado alto y ntp decidió no hacer nada. ntpdate es un comando más simple, "do-what-I-want", por lo que no se quejó. - shodanshok
Gracias, la vm fue suspendida de hecho. ¿Eso significa que si mi máquina virtual se suspende durante más de 10 a 15 minutos, el NTP no será útil después? Esto apesta porque tengo que usar "ntpdate" manualmente para arreglarlo. Intenté agregar "nptdate" como un trabajo cron por hora, pero luego me di cuenta de que ya hay un trabajo "ntpd" por hora, por lo que sería una exageración. - sina
Desafortunadamente, sí: tenías que correr ntpdate. Para decir la verdad, como ntpdate está en desuso en la nueva instalación de Linux, también puede usar ntp con parámetros especiales (ver página de manual para más detalles). Su hipervisor VM proporciona adiciones especiales para invitados, instálelas: a menudo incluyen algún canal de comunicación en serie con la máquina host, lo que permite la sincronización de tiempo a petición. - shodanshok


Parece que su ntp no se sincroniza debido a un exceso de fluctuación / desviación. Le sugiero que pruebe un grupo diferente de servidores ntp cerca de su país.

No hay necesidad de ofuscar la IP en su estado porque estas IP son servidores públicos y bien documentados.

Si ejecuta la máquina bajo VMware, por favor verifique también http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf y mantener el reloj ntp del servidor físico alineado.

Acerca de "Otra cosa que podría ser útil tener en cuenta es que es una VM. ¿Es posible que la VM estuviera en algún tipo de estado de pausa?"

Sí, VMware vuelve a sincronizar el reloj después de una pausa, incluso si las herramientas de vmware están configuradas para deshabilitar la sincronización

Independientemente de si activa la sincronización de tiempo periódica de VMware Tools, la sincronización de tiempo se produce después de ciertas operaciones:

  • Cuando se inicia el daemon de VMware Tools (como durante un reinicio o encendido)
  • Al reanudar una máquina virtual desde una operación de suspensión
  • Después de volver a una instantánea
  • Después de encoger un disco

3
2018-04-28 09:43



Eso es interesante. Solo para aclarar, ¿significa eso que, en este caso, es posible que vm se haya reanudado desde un estado de suspensión, y luego haya sincronizado el tiempo (incorrecto) con su host, aunque haya desactivado timesync? - sina
Parece: compruebe VMware KB 1189 kb.vmware.com/selfservice/microsites/…. "El tiempo se vuelve a sincronizar cuando migra la máquina virtual mediante vMotion, toma una instantánea, restaura una instantánea, reduce el tamaño del disco virtual o reinicia el servicio VMware Tools en la máquina virtual (incluido el reinicio de la máquina virtual)". - Alessandro Carini
Parece que el vm fue suprimido mientras tomaba una instantánea - sina