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?
fuente
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.
¿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.
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.
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
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.
fuente
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.
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í.
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
fuente