Soy desarrollador y estamos usando Quartz.Net, una biblioteca de programación ampliamente utilizada con un almacén de respaldo SQL para ejecutar un clúster de servidores de trabajos (VM en un clúster ESXI).
Cuarzo.Netrequiereese tiempo se sincronizará entre las instancias del servidor de trabajos y recomienda utilizar NTP para ello.
Los relojes deben tener una diferencia de un segundo entre sí.
Nuestros administradores de sistemas utilizan Windows NTP para sincronizar la hora 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 el requisito correcto y que no se puede cumplir sin dispositivos de sincronización GPS de hardware. Su SLA y nivel de monitoreo están "en 3 minutos".
Estamos experimentando un comportamiento desincronizado periódico (una vez cada 2 o 3 meses) en las instancias de Quartz que es consistente con el tiempo no sincronizado.
- ¿Es correcto que solicitemos "en un segundo" o debemos deshacernos de Quartz por completo?
- En caso afirmativo, ¿qué cambios se recomiendan para nuestra configuración?
Respuesta1
Estamos en 2018. Windows es capaz de mantener los servidores sincronizados en aproximadamente 2 ms, según lo exige la normativa MIFID II. Entonces, tu problema no es un problema.
Nuestros administradores de sistemas utilizan Windows NTP para sincronizar la hora 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 (al ser hardware) y usted tiene muchos 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 el requisito correcto y que no se puede cumplir sin dispositivos de sincronización GPS de hardware. Su SLA y nivel de monitoreo están "en 3 minutos".
ANTIGUO - antiguo - Windows se sincronizó dentro de ese período de tiempo porque los tickets de Kerberos tenían una validez de 5 minutos.
Pero estamos, como dije, en 2018. La industria financiera tiene requisitos bastante brutales en estos días y MS se ha encargado de eso desde 2012, creo. 2016 lo puso plenamente en vigor. La precisión de milisegundos en Internet es un problema resuelto; en realidad, se resolvió hace 50 años, para una conexión decente. NTP puede manejarlo. Es posible que tenga que instalar una caja de hardware barata si desea reducir el tráfico (es decir, crear su propia fuente de tiempo NTP de nivel 3), pero eso tampoco es caro.
¿Es correcto que solicitemos "en un segundo" o debemos deshacernos de Quartz por completo?
Necesita programar para problemas de tiempo ocasionales, como lo haría con el hardware. Pero "dentro del segundo" es un requisito de broma: es trivial cumplirlo en circunstancias normales.
Algunas referencias:
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/accurate-time
Regulaciones gubernamentales como: Precisión de 50 ms para FINRA en EE. UU. ESMA de 1 ms (MiFID II) en la UE.
Hay muchos detalles e instrucciones allí. De hecho, esta es una lectura increíble si tienes que resolver este problema. Es posible que tengas que actualizar tu hipervisor; hablan todo sobre Hyper-V. VMWare debería poder hacer lo mismo, pero no estoy seguro de la antigüedad de su versión.
Respuesta2
¿Es correcto que solicitemos "en un segundo" o debemos deshacernos de Quartz por completo?
Hay muchas muy buenas razones para que varias pilas de aplicaciones necesiten un control de tiempo estricto y lo que Quartz está pidiendo 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 utilice NTP y apuntarlas al mismo par de servidores NTP. Entonces, los hosts ESXi y las máquinas virtuales que se ejecutan en ellos, todos usan las mismas fuentes NTP, lo mismo para todo lo demás involucrado. De esta manera, incluso si los servidores NTP están "fuera de tiempo", al menos todas las partes de su sistema estarán actualizadas entre sí.
Respuesta3
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary
Compatibilidad con 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 de Kerberos versión 5.
Proporcionó una hora aproximada 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 las especificaciones de diseño del servicio de hora de Windows en estos sistemas operativos y no son compatibles.
Windows 10 y Windows Servidor 2016
La precisión de la hora en Windows 10 y Windows Server 2016 se ha mejorado sustancialmente, al tiempo que se mantiene la total 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 una precisión de 1 segundo, 50 ms (milisegundos) o 1 ms.
Precisión del objetivo: 1 segundo (1 s)
Para lograr una precisión de 1 s para una máquina de destino específica en comparación con una fuente de tiempo de alta precisión:
El sistema de destino debe ejecutar Windows 10, Windows Server 2016.
El sistema de destino debe sincronizar la hora desde una jerarquía NTP de servidores de hora, lo que culmina en una fuente de hora NTP compatible con Windows de alta precisión.
Todos los sistemas operativos Windows en la jerarquía NTP mencionada anteriormente deben configurarse como se documenta en la documentación Configuración de sistemas para alta precisión.
La latencia acumulada de red unidireccional entre el destino y el origen no debe exceder los 100 ms. El retraso acumulativo de la red se mide sumando los retrasos unidireccionales individuales entre pares de nodos cliente-servidor NTP en la jerarquía que comienza con el destino y termina en el origen. Para obtener más información, revise el documento de sincronización de hora de alta precisión.