Sou desenvolvedor e estamos usando Quartz.Net, biblioteca de agendamento amplamente usada com armazenamento de apoio SQL para executar cluster de servidores de jobs (VMs em cluster ESXI).
Quartzo.Netrequeresse horário será sincronizado entre as instâncias do servidor de trabalho e recomenda o uso de NTP para isso.
Os relógios devem estar dentro de um segundo um do outro.
Nossos administradores de sistemas usam o Windows NTP para sincronizar o horário com o controlador de domínio. A sincronização de VMs com host ESXI está desativada.
Eles continuam insistindo que "dentro de um segundo" não é o requisito correto e que não pode ser atendido sem dispositivos de sincronização GPS de hardware. Seu SLA e nível de monitoramento são “dentro de 3 minutos”.
Estamos enfrentando um comportamento fora de sincronia periódico (uma vez a cada 2 a 3 meses) de instâncias do Quartz que é consistente com o tempo fora de sincronia.
- É correto pedirmos "dentro de um segundo" ou precisamos abandonar totalmente o Quartz?
- Se sim, quais mudanças são recomendadas para nossa configuração?
Responder1
Estamos em 2018. O Windows é capaz de manter os servidores sincronizados em cerca de 2 ms, conforme exigido pelos regulamentos MIFID II. Então, seu problema é um não-problema.
Nossos administradores de sistemas usam o Windows NTP para sincronizar o horário com o controlador de domínio. A sincronização de VMs com host ESXI está desativada.
Por que? O host pode lidar com isso muito melhor (sendo hardware) e você tem muito menos. Seus administradores de sistema dão um tiro no próprio pé e depois reclamam que estão sangrando.
Eles continuam insistindo que "dentro de um segundo" não é o requisito correto e que não pode ser atendido sem dispositivos de sincronização GPS de hardware. Seu SLA e nível de monitoramento são “dentro de 3 minutos”.
ANTIGO - antigo - Windows sincronizado dentro desse período porque os tickets Kerberos tinham validade de 5 minutos.
Mas isto é, como eu disse, 2018. O setor financeiro tem exigências bastante brutais atualmente e a MS tem lidado com isso desde 2012, eu acho. 2016 colocou-o totalmente em vigor. A precisão de milissegundos na Internet é um problema resolvido - resolvido há 50 anos, na verdade, para uma conexão decente. O NTP pode lidar com isso. Você pode ter que instalar uma caixa de hardware barata se quiser reduzir o tráfego (ou seja, criar sua própria fonte de tempo NTP de nível 3), mas isso, novamente, nem é caro.
É correto pedirmos "dentro de um segundo" ou precisamos abandonar totalmente o Quartz?
Você precisa programar para problemas ocasionais de tempo - como faria com hardware. Mas "dentro de segundo" é uma piada de exigência - é trivial cumpri-la em circunstâncias normais.
Algumas referências:
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/accurate-time
Regulamentações governamentais como: Precisão de 50 ms para FINRA nos EUA 1 ms ESMA (MiFID II) na UE.
Muitos detalhes e instruções lá. Na verdade, esta é uma leitura incrível se você tiver que resolver esse problema. Talvez seja necessário atualizar seu hipervisor - eles falam tudo sobre o Hyper-V. O VMWare deve ser capaz de fazer o mesmo, mas não tem certeza da idade da sua versão.
Responder2
É correto pedirmos “dentro de um segundo” ou precisamos abandonar totalmente o Quartz?
Existem muitos bons motivos para que várias pilhas de aplicativos precisem de um controle de tempo rígido e o que o Quartz está pedindo está longe de ser incomum.
Se sim, quais mudanças são recomendadas para nossa configuração?
A melhor aposta é fazer com que cada parte do seu sistema use NTP e apontá-las para o mesmo par de servidores NTP. Portanto, os hosts ESXi e as VMs em execução neles, todos usando as mesmas fontes NTP, o mesmo para qualquer outra coisa envolvida. Dessa forma, mesmo que os servidores NTP estejam 'fora do horário', pelo menos todas as partes do seu sistema estarão atualizadas entre si.
Responder3
https://docs.microsoft.com/en-us/windows-server/networking/windows-time-service/support-boundary
Suporte de alta precisão para Windows 8.1 e 2012 R2 (ou anterior)
Versões anteriores do Windows (anteriores ao Windows 10 1607 ou Windows Server 2016 1607) não podem garantir um tempo altamente preciso. O serviço Windows Time nestes sistemas:
Forneceu a precisão de tempo necessária para satisfazer os requisitos de autenticação do Kerberos versão 5
Forneceu tempo pouco preciso para clientes e servidores Windows associados a uma floresta comum do Active Directory
Requisitos de precisão mais rígidos estavam fora da especificação de design do Windows Time Service nesses sistemas operacionais e não são suportados.
Windows 10 e Windows Server 2016
A precisão do tempo no Windows 10 e no Windows Server 2016 foi substancialmente melhorada, mantendo a compatibilidade total do NTP com versões anteriores do Windows. Sob as condições operacionais corretas, os sistemas que executam o Windows 10 ou o Windows Server 2016 e versões mais recentes podem fornecer precisão de 1 segundo, 50 ms (milissegundos) ou 1 ms.
Precisão do alvo: 1 segundo (1s)
Para obter precisão de 1s para uma máquina alvo específica quando comparada a uma fonte de tempo altamente precisa:
O sistema de destino deve executar o Windows 10, Windows Server 2016.
O sistema de destino deve sincronizar o horário de uma hierarquia NTP de servidores de horário, culminando em uma fonte de horário NTP altamente precisa e compatível com Windows.
Todos os sistemas operacionais Windows na hierarquia NTP mencionada acima devem ser configurados conforme documentado na documentação Configurando sistemas para alta precisão.
A latência cumulativa da rede unidirecional entre o destino e a origem não deve exceder 100 ms. O atraso cumulativo da rede é medido adicionando os atrasos unidirecionais individuais entre pares de nós cliente-servidor NTP na hierarquia, começando no destino e terminando na origem. Para obter mais informações, consulte o documento de sincronização de tempo de alta precisão.