¿Cómo sincronizar la hora en máquinas virtuales ESXi Windows en un segundo?

Soy desarrollador y estamos utilizando Quartz.Net, una biblioteca de programación ampliamente utilizada con un almacén de respaldo SQL para ejecutar servidores de clúster de trabajos (VM en el clúster ESXI).

Quartz.Net requiere que la hora se sincronice entre las instancias del servidor de trabajos y recomienda usar NTP para ello.

Los relojes deben estar dentro de un segundo el uno del otro.

Nuestros administradores de sistemas utilizan Windows NTP para sincronizar el tiempo con el controlador de dominio. La sincronización de máquinas virtuales con el host ESXI está desactivada.

Siguen insistiendo en que "dentro de un segundo" no es un requisito correcto y que no se puede cumplir sin dispositivos de sincronización GPS de hardware. Su nivel de SLA y monitoreo son "dentro de 3 minutos".

Estamos experimentando un comportamiento fuera de sincronización de las instancias de Quartz periódicas (una vez cada 2-3 meses) que es consistente con el tiempo que no está sincronizado.

¿Es correcto para nosotros pedir "dentro de un segundo" o tenemos que deshacernos de Quartz por completo?
En caso afirmativo, ¿qué cambios se recomiendan para nuestra configuración?

— Leotsarev
fuente

La sincronización a un segundo no es nada , incluso en servidores virtuales (que tienen una estabilidad de tiempo notoriamente pobre por sí mismos). ¡¿Tres minutos?! Tiene una risa. No puede ejecutar una red de esa manera.

— ligereza corre en órbita el

Respuestas:

Esto es 2018. Windows es capaz de mantener los servidores sincronizados dentro de los 2 ms aproximadamente, como lo requiere el Reglamento MIFID II. Entonces, su problema no es un problema.

Nuestros administradores de sistemas utilizan Windows NTP para sincronizar el tiempo con el controlador de dominio. La sincronización de máquinas virtuales con el host ESXI está desactivada.

¿Por qué? El host puede manejar esto mucho mejor (siendo hardware) y usted tiene mucho menos. Sus administradores de sistemas se disparan en el pie y luego se quejan de que están sangrando.

Siguen insistiendo en que "dentro de un segundo" no es un requisito correcto y que no se puede cumplir sin dispositivos de sincronización GPS de hardware. Su nivel de SLA y monitoreo son "dentro de 3 minutos".

ANTIGUO - antiguo - Windows sincronizado dentro de ese plazo porque los tickets Kerberos tenían una validez de 5 minutos.

Pero esto es, como dije, 2018. La industria financiera tiene requisitos bastante brutales en estos días y MS lo ha manejado desde - creo que desde 2012. 2016 lo puso plenamente en vigencia. La precisión de milisegundos en Internet es un problema resuelto, resuelto hace 50 años en realidad, para una conexión decente. NTP puede manejarlo. Es posible que tenga que colocar una caja de hardware barata si desea reducir el tráfico (es decir, hacer su propia fuente de tiempo NTP de nivel 3), pero eso tampoco es costoso.

¿Es correcto para nosotros pedir "dentro de un segundo" o tenemos que deshacernos de Quartz por completo?

Debe programar para problemas de tiempo ocasionales, como lo haría con el hardware. Pero "dentro de un segundo" es una broma de un requisito: es trivial reunirse en circunstancias normales.

Algunas referencias:

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/accurate-time

Regulaciones gubernamentales como: 50 ms de precisión para FINRA en los EE. UU. 1 ms ESMA (MiFID II) en la UE.

Un montón de detalles e instrucciones allí. Esta es una lectura increíble en realidad si tienes que resolver este problema. Es posible que deba actualizar su hipervisor: hablan sobre Hyper-V. VMWare debería poder hacer lo mismo, pero no estoy seguro de la antigüedad de su versión.

— TomTom
fuente

FWIW, el cumplimiento de MiFID II en la industria financiera [del Reino Unido] es sorprendentemente pobre (los bancos prefieren pagar las multas insignificantes que molestarse con todo ese alboroto), pero técnicamente tiene razón, por supuesto.

— ligereza corre en órbita el

No se trata de cumplimiento, se trata de la HABILIDAD para cumplir. MS lo resolvió hace mucho tiempo. Como tal, la "precisión de 3 minutos" que OP habla sobre la broma del área.

— TomTom

Estoy de acuerdo; esto fue solo un aparte.

— Carreras de ligereza en órbita el

Estoy con usted en que NTP es más que suficientemente rápido, pero VMware no recomienda el uso de servicios de integración para sincronizar el tiempo, en la mayoría (aunque no en todos) los casos, NTP normal hace un trabajo mejor y más rápido.

— HoD

Como su preocupación es el tiempo relativo entre servidores, puede usar NTP para sincronizarlos con los conmutadores de red que a su vez se sincronizan con su ISP, sin necesidad de hardware adicional.

— grahamj42

¿Es correcto para nosotros pedir "dentro de un segundo" o tenemos que deshacernos de Quartz por completo?

Hay muchas razones muy buenas para que varias pilas de aplicaciones necesiten un control estricto del tiempo y lo que está pidiendo Quartz está lejos de ser inusual.

En caso afirmativo, ¿qué cambios se recomiendan para nuestra configuración?

La mejor opción es hacer que cada parte de su sistema use NTP y señalarlos al mismo par de servidores NTP. Por lo tanto, los hosts ESXi y las máquinas virtuales que se ejecutan en ellos, todos usan las mismas fuentes NTP, lo mismo para cualquier otra cosa involucrada. De esta manera, incluso si los servidores NTP están "fuera de tiempo", al menos cada parte de su sistema está actualizada entre sí.

— Chopper3
fuente

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary

Soporte de alta precisión para Windows 8.1 y 2012 R2 (o anterior)

Las versiones anteriores de Windows (anteriores a Windows 10 1607 o Windows Server 2016 1607) no pueden garantizar una hora muy precisa. El servicio de hora de Windows en estos sistemas:

Proporcionó la precisión de tiempo necesaria para satisfacer los requisitos de autenticación Kerberos versión 5
Proporcionó un tiempo poco preciso para los clientes y servidores de Windows unidos a un bosque común de Active Directory

Los requisitos de precisión más estrictos estaban fuera de la especificación de diseño del Servicio de hora de Windows en estos sistemas operativos y no son compatibles.

Windows 10 y Windows Server 2016

La precisión de tiempo en Windows 10 y Windows Server 2016 se ha mejorado sustancialmente, al tiempo que se mantiene la compatibilidad NTP con versiones anteriores de Windows. En las condiciones operativas adecuadas, los sistemas que ejecutan Windows 10 o Windows Server 2016 y versiones más recientes pueden ofrecer 1 segundo, 50 ms (milisegundos) o 1 ms de precisión.

Precisión objetivo: 1 segundo (1s)

Para lograr la precisión de 1s para una máquina objetivo específica en comparación con una fuente de tiempo altamente precisa:

El sistema de destino debe ejecutar Windows 10, Windows Server 2016.
El sistema de destino debe sincronizar el tiempo desde una jerarquía NTP de servidores de tiempo, culminando en una fuente de tiempo NTP altamente precisa y compatible con Windows.
Todos los sistemas operativos Windows en la jerarquía NTP mencionados anteriormente deben configurarse como se documenta en la documentación de Configuración de sistemas para alta precisión.
La latencia de red unidireccional acumulativa entre el destino y la fuente no debe superar los 100 ms. La demora acumulativa de la red se mide agregando las demoras unidireccionales individuales entre pares de nodos cliente-servidor NTP en la jerarquía, comenzando con el destino y terminando en la fuente. Para obtener más información, revise el documento de sincronización de tiempo de alta precisión.

https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/configuring-systems-for-high-accuracy

— Greg Askew
fuente

En realidad, estamos usando Windows 2012R2. Parece que es la raíz del problema (junto con la falta de sincronización con el host ESXI)

— Leotsarev

@Leotsarev: si se trata de miembros del dominio, no deben sincronizarse con el host de VM.

— Greg Askew