it-swarm-es.com

Hyper-V Machine desplaza el tiempo por todas partes, incluso con NTP

Resuelto El problema era Hyper-V en esa máquina. Quité Hyper-V, instalé VMware Server, ejecuté la misma VM. Los problemas de sincronización de tiempo desaparecieron (<100 ms de diferencia después de un día).


Mi configuración es así:

HYV1 - HyperV machine (non domain) - sync irrelevant
AD1  - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1   - Physical machine, sync'd to domain. 
S2   - Physical machine running HyperV, sync'd to domain.
V1   - Linux VM machine on S2, sync'd to AD1. No HyperV integration.

AD1 y S1 tienen sincronización fina: el gráfico de bandas muestra una diferencia de menos de 100 ms.

S2 va a la deriva como loco. Aquí hay un poco del gráfico de tira contra AD1:

18:33:22 d:+00.0010138s o:+05.4101899s 
18:33:24 d:+00.0010138s o:+05.4319765s 
18:33:26 d:+00.0000000s o:+05.4788429s 
18:33:28 d:+00.0000000s o:+05.6089942s 
18:33:30 d:+00.0010138s o:+05.7240269s 
18:33:32 d:+00.0000000s o:+06.0421911s 
18:33:34 d:+00.0081104s o:+06.5613708s 
18:33:37 d:+00.0000000s o:+06.9096594s 
18:33:39 d:+00.0000000s o:+06.8867838s 
18:33:41 d:+00.0010127s o:+06.8936401s 

En 20 segundos, se desvió más de un segundo. Si lo restablezco manualmente en 1 segundo, en unos minutos volverá a la deriva aproximadamente 2 segundos. De la noche a la mañana pasó de ~ 2 a ~ 5 segundos. Linux VM dentro de S2 tiene una sincronización perfecta con AD1.

Aquí está la configuración:

C:\Users\mgg>w32tm /dumpreg /subkey:Parameters

Value Name                 Value Type          Value Data
------------------------------------------------------------

ServiceDll                 REG_EXPAND_SZ       %systemroot%\system32\w32time.dll
ServiceMain                REG_SZ              SvchostEntry_W32Time
ServiceDllUnloadOnStop     REG_DWORD           1
Type                       REG_SZ              NT5DS
NtpServer                  REG_SZ              ad01.mydomain ad02.mydomain


C:\Users\mgg>w32tm /dumpreg /subkey:Config

Value Name                Value Type          Value Data
-----------------------------------------------------------

FrequencyCorrectRate      REG_DWORD           4
PollAdjustFactor          REG_DWORD           5
LargePhaseOffset          REG_DWORD           50000000
SpikeWatchPeriod          REG_DWORD           900
LocalClockDispersion      REG_DWORD           9
HoldPeriod                REG_DWORD           5
PhaseCorrectRate          REG_DWORD           1
UpdateInterval            REG_DWORD           30000
EventLogFlags             REG_DWORD           2
AnnounceFlags             REG_DWORD           5
TimeJumpAuditOffset       REG_DWORD           28800
MinPollInterval           REG_DWORD           2
MaxPollInterval           REG_DWORD           8
MaxNegPhaseCorrection     REG_DWORD           -1
MaxPosPhaseCorrection     REG_DWORD           -1
MaxAllowedPhaseOffset     REG_DWORD           300

Miré el registro de eventos y, aparte de las advertencias sobre la sincronización (después de que se desincroniza mucho), no hay otras advertencias.

¿Cómo puedo solucionar este problema? Es la única máquina que tiene este problema. Todas las demás máquinas (físicas y virtuales) están funcionando bien.

Editar : Para aclarar: La VM (AD1) tiene la integración desactivada y se sincroniza con time.nist.gov. AD1 está bien. Es la máquina física S1 la que puede No se sincroniza con AD1 y se desplaza por todas partes. Todos los demás servidores físicos pueden sincronizarse con AD1 sin problemas.

Actualización Entonces, parece ser un problema de ejecución de la VM. El reloj avanza lentamente con VM apagado. Encendido, inmediatamente comienza a perder segundos. Cambio el VM para usar solo la mitad de los recursos, y eso parece haberlo mitigado un poco, por ahora. ¡Gracias!

10
MichaelGG

El problema está en la implementación virtual de las diversas fuentes de reloj (tsc, jiffies, acpi_pm, cmos_trc). La mejor manera que he encontrado para solucionar este problema con HyperV es apagar off la sincronización de reloj proporcionada por HyperV para su máquina invitada, luego use adjtimex para ajustar la hora. En un sistema operativo invitado Ubuntu, haga esto ...

# rm /var/log/clocks.log
# /etc/init.d/ntp-server stop
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# adjtimex -l -u -h ntp.ubuntu.com

y responda No a ambas preguntas

# while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done

deje que se ejecute durante unas horas para calibrar, presione Ctrl-C para salir.

# adjtimex -r -a -u -h ntp.ubuntu.com

esto hará un análisis de mínimos cuadrados de su reloj y encontrará el ajuste correcto

# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# /etc/init.d/ntp-server start

esto resincronizará la hora en su máquina y ntp debería poder mantenerla sincronizada porque ya no debería desviarse demasiado.

3
Matt Keenan

Este parece ser un problema muy común con las VM. Consulte los siguientes sitios web:

http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html

http://social.technet.Microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

Mi sugerencia sería sincronizar solo con un servidor de tiempo externo y deshabilitar cualquier sincronización de tiempo de integración

Ojalá esto ayude.

2
rmwetmore

Hemos estado ejecutando Hyper-v en Core durante un tiempo. Al principio tuvimos problemas de sincronización de tiempo ... Volví a una de las mejores prácticas de mis viejos tiempos de Windows NT.

Miro los servidores por sistema operativo. Creo un maestro Linux, Router, Windows, Novell.

Puede que no tenga Novell ahora, pero tenga paciencia conmigo.

Cada servidor "maestro" se sincroniza con el enrutador. El enrutador al estrato. Luego, cada servidor miembro tiene su servidor OS maestro y un servidor secundario de uno de los otros Maestros.

  • Linux a enrutador, luego a Novell
  • Novell al enrutador, luego a Windows
  • Windows al enrutador, luego a Linux
  • Enrutador a Stratum, luego a Core switch
  • Core Cambie a Stratum, luego a Router

La última pieza de esta estrategia es ... TODO tiene un servidor de tiempo. Si no tiene un servidor de hora, no se conectará a la red. De tostadora para cambiar a teléfono PBX a servidores.

Esta es una de las primeras cosas que hago cuando llego a un nuevo trabajo y es dedicar tiempo a mapear la red y establecer el tiempo. Entonces puedo simplemente verificarlo aquí y allá y eliminar la sincronización de tiempo como un problema a partir de ese momento.

2
Thomas Denton

Esto puede sonar gracioso, pero apuesto a que está ejecutando una configuración de multiprocesador. Hay problemas conocidos de desviación del reloj con ciertos fabricantes tos AMD tos que sucede con las placas base de varios núcleos/múltiples sockets. La actividad intensa de interrupción, como por ejemplo, ejecutar una máquina virtual o dos, empeora la deriva. La deriva que estás experimentando suena muy sospechosamente así.

Por lo que vale, prefiero las ofertas de AMD a las de Intel, así que no tome esto como un golpe en su contra.

1
Avery Payne

El tiempo se desplaza por todas partes en las máquinas virtuales. Realmente desea asegurarse de que el servidor NTP no esté usando el reloj local en ninguna declaración de 'servidor', ya que el reloj local no es confiable. Una cosa que he hecho para ayudar es establezca el atributo "maxpoll" para servidores en máquinas VMed. Esto obliga al servicio ntp a verificar con sus relojes ascendentes con mucha más frecuencia que el valor predeterminado configurado, lo que ayuda a mantenerlo verdadero.

server [timeserver] maxpoll 12

Pruebe algunas configuraciones para ver qué tan abajo necesita llegar para mantener el tiempo relativamente confiable. 12 funciona para mí, pero cada entorno es diferente.

1
sysadmin1138

Suponiendo que AD1 era un controlador de dominio, creo que el problema aquí puede haber estado relacionado con su servidor Hyper-V configurando su hora desde una de sus propias VM invitadas. Es por eso que el problema desapareció cuando cambió a VMware: el servidor VMware no se siente obligado a sincronizar su reloj con un controlador de dominio de Windows.

1
Skyhawk