Compartilhar via

Aprimoramentos de precisão de tempo para o Windows Server 2016

O Windows Server 2016 aprimorou os algoritmos usados para corrigir a hora e a condição do relógio local para sincronização com a Hora Universal Coordenada (UTC). O Network Time Protocol (NTP) usa quatro valores para calcular a diferença de horário com base nos carimbos de data/hora da solicitação/da resposta do cliente e da solicitação/da resposta do servidor. No entanto, as redes apresentam ruído e pode haver picos nos dados do NTP por causa do congestionamento da rede e a outros fatores que afetam a latência da rede. Os algoritmos do Windows Server 2016 equilibram esse ruído usando diversas técnicas que resultam em um relógio estável e preciso. A fonte que usamos para a hora precisa também referencia uma API aprimorada que nos oferece uma melhor resolução. Com tais aprimoramentos, podemos alcançar uma precisão de 1 ms com relação ao UTC em um domínio.

Hyper-V

O Windows Server 2016 aprimorou o serviço TimeSync do Hyper-V. Os aprimoramentos incluem um tempo inicial mais preciso no início da máquina virtual (VM) ou na restauração da VM e interrupção da correção de latência para exemplos fornecidos para o serviço de Horário do Windows (W32Time). Esse aprimoramento permite nos manter dentro de 10 μs do host com uma Raiz Quadrada Média (que indica variância) igual a 50 μs, mesmo em um computador com 75% de carga. Para obter mais informações, confira Arquitetura do Hyper-V.

Observação

A carga foi criada usando o parâmetro de comparação prime95 usando o perfil equilibrado.

O nível de Camada que o host relata para o convidado é mais transparente. Antes, o host apresentava uma Camada fixa igual a 2, independentemente da precisão. Com as alterações do Windows Server 2016, o host relata a primeira Camada maior que a Camada do host, o que resulta em melhor tempo para os convidados virtuais. A Camada do host é determinada pelo W32Time em meio normal com base no tempo de origem. Os convidados do Windows Server 2016 ingressados no domínio encontram o relógio mais preciso, em vez de usar o padrão do host. Por este motivo, recomendamos desabilitar manualmente a configuração do Provedor de Tempo do Hyper-V nos computadores que participam de um domínio no Windows 2012 R2 e anterior.

Monitoramento

Contadores do Monitor de desempenho foram adicionados. Esses contadores permitem que você defina a linha de base, monitore e solucione problemas de precisão de tempo. A seguinte tabela lista os contadores.

Contador Descrição
Diferença de Horário Calculado A diferença de horário absoluto entre o relógio do sistema e a fonte de horário escolhida, como calculado pelo Serviço W32Time em microssegundos. Quando uma nova amostra válida fica disponível, o horário calculado é atualizado com a diferença de horário indicada pela amostra. Esse tempo é a diferença de horário real do relógio local. O W32Time inicia a correção do relógio utilizando essa diferença e atualiza o horário calculado entre as amostras com a diferença de horário restante que precisa ser aplicada ao relógio local. A precisão do relógio pode ser acompanhada por meio desse contador de desempenho com um intervalo de sondagem baixo (por exemplo, 256 segundos ou menos) e buscando o valor do contador como menor que o limite desejado de precisão do relógio.
Ajuste de Frequência do Relógio O ajuste de frequência do relógio absoluto feito no relógio do sistema local pelo W32Time em partes por bilhão. Esse contador ajuda a visualizar as ações executadas pelo W32Time.
Atraso de Ida e Volta NTP O atraso de ida e volta mais recente enfrentado pelo Cliente NTP no recebimento de uma resposta do servidor em microssegundos. Esse atraso é o tempo decorrido no cliente NTP entre a transmissão de uma solicitação para o servidor NTP e o recebimento de uma resposta válida do servidor. Esse contador ajuda a caracterizar os atrasos experimentados pelo cliente NTP. Viagens de ida e volta maiores ou variáveis podem trazer ruído aos cálculos de tempo do NTP, o que, por sua vez, pode afetar a precisão da sincronização de horário por meio do NTP.
Contagem de Fontes do Cliente NTP Número ativo de fontes de horário do NTP utilizadas pelo cliente NTP. Esse número é uma contagem dos endereços IP ativos e distintos de servidores de horário que respondem às solicitações desse cliente. Esse número pode ser maior ou menor do que os pares configurados, de acordo com a resolução DNS de nomes de pares e da capacidade de alcance atual.
Solicitações de Entrada do Servidor NTP Número de solicitações recebidas pelo servidor NTP (solicitações/seg).
Respostas de Saída do Servidor NTP Número de solicitações respondidas pelo servidor NTP (respostas/seg).

Os três primeiros contadores segmentam cenários para solucionar problemas de precisão. Para mais informações, consulte a seção Solucionar problemas de precisão de tempo e NTP mais adiante neste artigo. Os últimos três contadores abrangem cenários do servidor NTP e são úteis quando você está determinando a carga e a linha de base do desempenho atual.

Atualizações de configuração por ambiente

A tabela a seguir descreve as alterações na configuração padrão entre o Windows Server 2016 e as versões anteriores para cada função. As configurações do Windows Server 2016 e da Atualização de Aniversário do Windows 10 (build 14393) agora são exclusivas e é por isso que elas aparecem como colunas separadas.

Função Configuração Windows Server 2016 Windows 10 Windows Server 2012 R2
Windows Server 2008 R2
Windows 10
Autônomo/Nano Server
Servidor de Horário time.windows.com NA time.windows.com
Frequência de votação 64 a 1.024 segundos NA Uma vez por semana
Frequência de Atualização do Relógio Uma vez por segundo NA Uma vez por hora
Cliente Autônomo
Servidor de Horário NA time.windows.com time.windows.com
Frequência de Sondagem NA Uma vez por dia Uma vez por semana
Frequência de Atualização do Relógio NA Uma vez por dia Uma vez por hora
Controlador de Domínio
Servidor de Horário Controlador de domínio primário/GTIMESERV NA Controlador de domínio primário/GTIMESERV
Frequência de Sondagem 64 a 1.024 segundos NA 1,024-32,768 segundos
Frequência de Atualização do Relógio Uma vez por segundo NA Uma vez por hora
Servidor Membro do Domínio
Servidor de Horário DC NA DC
Frequência de votação 64 a 1.024 segundos NA 1,024-32,768 segundos
Frequência de Atualização do Relógio Uma vez por segundo NA Uma vez a cada 5 minutos
Cliente Membro do Domínio
Servidor de Horário NA DC DC
Frequência de votação NA 1,204-32,768 segundos 1,024-32,768 segundos
Frequência de Atualização do Relógio NA Uma vez a cada 5 minutos Uma vez a cada 5 minutos
Convidado do Hyper-V
Servidor de Horário Seleciona a melhor opção com base na Camada do host e no servidor de horário Seleciona a melhor opção com base na Camada do host e no servidor de horário Usa o host como padrão
Frequência de votação Com base na função acima Com base na função acima Com base na função acima
Frequência de Atualização do Relógio Com base na função acima Com base na função acima Com base na função acima

Observação

Para o Linux no Hyper-V, confira a seção Como permitir que o Linux use o tempo de host do Hyper-V.

Impacto da maior frequência de sondagem e de atualização do relógio

Para fornecer uma hora mais precisa, os padrões de frequências de sondagem e atualizações do relógio são aumentados, para nos permitir fazer pequenos ajustes com mais frequência. Essa alteração provoca mais tráfego UDP (User Datagram Protocol)/NTP. Esses pacotes são pequenos. Assim, deve haver pouco ou nenhum efeito sobre os links de banda larga. O benefício é que o tempo deverá ser melhor em uma variedade maior de hardware e ambientes.

Em dispositivos com suporte de bateria, o aumento da frequência de sondagem pode provocar problemas. Os dispositivos de bateria não armazenam a hora quando estão desligados. Quando eles são retomados, pode ser preciso fazer correções frequentes no relógio. O aumento da frequência de sondagem faz com que o relógio fique instável e também poderá usar mais energia. Recomendamos não alterar as configurações padrão do cliente.

Os controladores de domínio (DCs) devem ser minimamente afetados mesmo com o efeito multiplicado do aumento das atualizações de clientes NTP em um Domínio do Active Directory. O NTP tem um consumo de recursos muito menor em comparação com outros protocolos e um efeito marginal. É mais provável que você chegue aos limites de outras funcionalidades do domínio antes de ser afetado pelo aumento das configurações do Windows Server 2016. O Active Directory usa NTP seguro, que tende a sincronizar o tempo com menos precisão que o NTP simples. Verificamos que ele pode ser escalado para clientes a duas Camadas de distância do controlador de domínio primário (PDC).

Como um plano conservador, você deverá reservar 100 solicitações de NTP por segundo e por núcleo. Por exemplo, com um domínio composto por quatro controladores de domínio com quatro núcleos cada, você deverá conseguir atender a 1.600 solicitações de NTP por segundo. Se tiver 10 mil clientes configurados para sincronizar a hora uma vez a cada 64 segundos e as solicitações forem recebidas de maneira uniforme ao longo do tempo, você verá 10.000/64 ou cerca de 160 solicitações/segundo, distribuídas por todos os controladores de domínio. Essa valor se enquadra facilmente dentro de nossas 1.600 solicitações de NTP/s com base neste exemplo. Essas recomendações de planejamento são conservadoras e dependem muito da rede, das velocidades do processador e das cargas. Como sempre, faça a linha de base e teste em seus ambientes.

S os controladores de domínio estiverem em execução com uma carga considerável de CPU, maior que 40%, isso certamente adiciona ruído às respostas do NTP e afeta a precisão de tempo no domínio. Novamente, você precisa fazer o teste em seu ambiente para entender os resultados reais.

Medidas de precisão de tempo

Para medir a precisão de tempo no Windows Server 2016, usamos diversas ferramentas, métodos e ambientes. Você pode usar essas técnicas para medir e ajustar seu ambiente e determinar se os resultados da precisão atendem às suas necessidades.

Metodologia

O nosso relógio de origem de domínio consistiu em dois servidores NTP de alta precisão com hardware de GPS. Também usamos um computador de teste de referência separado para medições, que também tinha um hardware de GPS de alta precisão de outro fabricante. Para alguns dos testes, você precisa de uma fonte de relógio precisa e confiável para usar como referência, além da fonte de relógio do domínio.

Usamos quatro métodos diferentes para medir a precisão com máquinas virtuais e computadores físicos. Vários métodos forneceram meios independentes para validar os resultados.

  1. Medir o relógio local, que é condicionado por w32tm, em nosso computador de teste de referência que tem o hardware de GPS separado.

  2. Medir os pings do NTP do servidor NTP para os clientes usando "stripchart" do W32tm.

  3. Medir os pings do NTP do cliente para o servidor NTP usando "stripchart" do W32tm.

  4. Medir os resultados do Hyper-V do host para o convidado com o TSC (Contador de Carimbos de Data/Hora). Esse contador é compartilhado entre ambas as partições e a hora do sistema em ambas as partições. Calculamos a diferença entre a hora do host e a hora do cliente na VM. Depois, usamos o relógio de TSC para interpolar a hora do host por meio do convidado, pois as medidas não acontecem ao mesmo tempo. Além disso, usamos o relógio de volume segmentado por tempo para contar com atrasos e latência na API.

O W32tm é interno, mas as outras ferramentas que usamos durante nossos testes estão disponíveis para o repositório da Microsoft no GitHub como software livre para teste e uso. Para mais informações sobre como usar as ferramentas para fazer medições, confira o Wiki de ferramentas de calibragem de tempo do Windows.

Os resultados do teste mostrados são um subconjunto de medidas que fizemos em um dos ambientes de teste. Eles ilustram a precisão mantida no início da hierarquia de tempo e o cliente de domínio filho no final da hierarquia de tempo. Esses resultados são comparados com os mesmos computadores em uma topologia baseada em 2012 para comparação.

Topologia

Para comparação, testamos as topologias baseadas no Windows Server 2012 R2 e no Windows Server 2016. Ambas as topologias consistem em dois computadores host físicos do Hyper-V que referenciam um computador Windows Server 2016 com o hardware de relógio de GPS instalado. Cada host executa três convidados do Windows ingressados no domínio, que são organizados como a topologia a seguir. As linhas representam a hierarquia de tempo e o protocolo/transporte usado.

Diagrama que mostra a topologia de hora do Windows com apenas um cliente de domínio filho em execução no primeiro host Hyper-V.

Diagrama que mostra a topologia de hora do Windows com dois clientes de domínio filho. Um é executado no primeiro host Hyper-V e outro é executado no segundo host Hyper-V.

Visão geral dos resultados gráficos

Os dois gráficos a seguir representam a precisão de tempo de dois membros específicos em um domínio baseado na topologia anterior. Cada gráfico exibe os resultados do Windows Server 2012 R2 e 2016 sobrepostos, o que demonstra os aprimoramentos visualmente. A precisão foi medida dentro do computador convidado em comparação com o host. Os dados gráficos representam um subconjunto de todo o conjunto de testes que fizemos e apresenta os cenários de melhor e pior caso.

Diagrama que mostra a topologia de hora do Windows com o servidor PDC de domínio raiz e os servidores cliente de domínio filho no primeiro host Hyper-V chamado.

Performance do controlador de domínio primário do domínio raiz

O controlador de domínio primário raiz é sincronizado com o host do Hyper-V (utilizando o VMIC), que é um Windows Server 2016 com um hardware de GPS comprovado como sendo preciso e estável. Esse requisito é crítico para uma precisão de 1 ms, que é mostrada como a área sombreada identificada pela chamada.

Diagrama que mostra o domínio raiz.

Performance do cliente de domínio filho

O cliente de domínio filho é anexado a um controlador de domínio primário de domínio filho, que se comunica com o controlador de domínio primário raiz. Seu tempo também está dentro do requisito de 1 ms.

Diagrama que mostra o cliente de domínio filho.

Teste de longa distância

O gráfico a seguir compara um salto de rede virtual para seis saltos de rede física com o Windows Server 2016. Dois gráficos são sobrepostos entre si com transparência para mostrar os dados sobrepostos. O aumento de saltos de rede significa uma latência mais alta e desvios de tempo maiores. O gráfico é ampliado. Portanto, os limites de 1 ms, representados pela sombreada, são maiores. Como você pode ver, o tempo ainda está dentro de 1 ms com vários saltos. Ele é deslocado negativamente, o que demonstra uma assimetria da rede. Cada rede é diferente e as medidas dependem de vários fatores ambientais.

Diagrama que mostra o teste de longa distância.

Práticas recomendadas para a manutenção de hora precisa

Siga estas práticas recomendadas para a manutenção de hora precisa.

Relógio de origem sólido

A hora de um computador está no mesmo nível do relógio de origem com o qual ela é sincronizada. Para atingir 1 ms de precisão, você precisa do hardware de GPS ou de um dispositivo de tempo em sua rede referenciado como o relógio de origem mestre. Usar o padrão de time.windows.com pode não fornecer uma fonte de hora estável e local. À medida que você ficar mais distante do relógio de origem, a rede afetará a precisão. É necessário ter um relógio de origem mestre em cada data center para obter a melhor precisão.

Opções de hardware de GPS

Várias soluções de hardware podem oferecer uma hora precisa. Em geral, as soluções atuais são baseadas em antenas de GPS. As soluções de rádio e modem discado usam linhas dedicadas. Elas se conectam à rede como um dispositivo ou são conectadas a um computador, por exemplo, o Windows por meio de um dispositivo PCIe ou USB. Diferentes opções fornecem diferentes níveis de precisão e, como sempre, os resultados dependem do ambiente. As variáveis que afetam a precisão incluem a disponibilidade de GPS, estabilidade e carga da rede e hardware de computador. Esses são fatores importantes ao escolher um relógio de origem, que é um requisito para uma hora estável e precisa.

Domínio e tempo de sincronização

Os membros do domínio usam a hierarquia de domínio para determinar qual computador eles usam como uma fonte para sincronizar a hora. Cada membro do domínio encontra outro computador para sincronização e o salvará como a fonte de relógio. Cada tipo de membro do domínio segue um diferente conjunto de regras para encontrar uma fonte de relógio para sincronização de hora. O Controlador de domínio primário na raiz da floresta é a fonte de relógio padrão para todos os domínios. A lista abaixo apresenta diferentes funções e descrições de alto nível de como elas encontram uma fonte:

  • Controlador de domínio com a função de controlador de domínio primário: esse computador é a fonte de horário autoritativa para um domínio. Tem a hora mais precisa disponível no domínio. Deve sincronizar com um controlador de domínio no domínio pai, exceto nos casos em que a função GTIMESERV está habilitada.
  • Qualquer outro controlador de domínio: esse computador funciona como uma fonte de horário para clientes e servidores membro no domínio. O controlador de domínio pode ser sincronizado com o controlador de domínio primário do próprio domínio ou com qualquer controlador de domínio no domínio pai.
  • Clientes/Servidores membro: esse computador pode ser sincronizado com qualquer controlador de domínio ou controlador de domínio primário do próprio domínio ou com um controlador de domínio ou um controlador de domínio primário no domínio pai.

De acordo com os candidatos disponíveis, um sistema de pontuação é usado para encontrar a melhor fonte de horário. Esse sistema leva em conta a confiabilidade da fonte de horário e a localização relativa. Essa verificação ocorre uma vez quando a hora é o serviço iniciado. Caso precise ter um controle mais refinado de como o tempo é sincronizado, adicione bons servidores de horário em localizações específicas ou adicione redundância. Para mais informações, consulte a seção Especificar um serviço de hora confiável local usando o GTIMESERV.

Ambientes de SO misto (Windows Server 2012 R2 e Windows Server 2008 R2)

Embora um ambiente de domínio puro do Windows Server 2016 seja necessário para obter a melhor precisão, ainda há benefícios de usar um ambiente misto. A implantação do Hyper-V do Windows Server 2016 em um domínio do Windows Server 2012 beneficia os convidados devido ao aprimoramentos mencionados, mas somente se os convidados também forem o Windows Server 2016. Um controlador de domínio primário do Windows Server 2016 pode fornecer um tempo mais preciso devido aos algoritmos aprimorados e ele é uma fonte mais estável. Como a substituição do controlador de domínio primário pode não ser uma opção, adicione um controlador de domínio do Windows Server 2016 com o conjunto de roll GTIMESERV, que será uma atualização na precisão para o domínio. Um controlador de domínio do Windows Server 2016 pode fornecer um tempo melhor para os clientes de horário downstream; mas ele só é tão bom quanto o tempo do NTP de origem.

Além disso, conforme já mencionado, as frequências de sondagem e atualização do relógio foram modificadas com o Windows Server 2016. Essas frequências podem ser modificadas manualmente para seus DCs de nível inferior ou aplicadas por meio da Política de Grupo. Não testamos essas configurações, mas elas devem se comportar bem no Windows Server 2008 R2 e no Windows Server 2012 R2 e trazer alguns benefícios.

As versões anteriores ao Windows Server 2016 apresentaram diversos problemas na manutenção de hora precisa, o que resultou no descompasso da hora do sistema imediatamente após um ajuste. Por isso, a obtenção de amostras de tempo de uma origem NTP precisa com frequência e o condicionamento do relógio local com os dados levam a um descompasso menor nos relógios do sistema no período de intra-amostragem. O resultado é uma cronometragem melhor nas versões de SO de nível inferior. A melhor precisão observada foi de aproximadamente 5 ms quando um cliente NTP do Windows Server 2012 R2, definido com as configurações de alta precisão, sincronizou a hora em um servidor NTP preciso do Windows Server 2016.

Em alguns casos que envolvem controladores de domínio convidados, as amostras de TimeSync do Hyper-V podem atrapalhar a sincronização de hora do domínio. Esse problema não deve mais existir para convidados do Windows Server 2016 operando em hosts Hyper-V do Windows Server 2016.

Para desabilitar o serviço TimeSync do Hyper-V em fornecer amostras para o W32time, defina a seguinte chave do Registro do convidado:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider "Enabled"=dword:00000000

Permitir que o Linux use a hora do host do Hyper-V

Nos convidados do Linux em execução no Hyper-V, normalmente, os clientes são configurados para usar o daemon NTP para a sincronização de hora em servidores NTP. Se a distribuição do Linux der suporte ao protocolo TimeSync versão 4 e o convidado do Linux tiver o serviço de integração TimeSync habilitado, ele sincroniza em relação à hora do host. Esse cenário pode levar a uma manutenção de hora inconsistente se ambos os métodos estão habilitados.

Para sincronizar exclusivamente com a hora do host, recomendamos desabilitar a sincronização de horário NTP por um dos dois métodos:

  • Desative todos os servidores NTP no arquivo ntp.conf.
  • Desative o daemon NTP.

Nessa configuração, o parâmetro do servidor de horário é esse host. A Frequência de Sondagem é de 5 segundos e a Frequência de Atualização do Relógio também é de 5 segundos.

Para sincronização exclusiva no NTP, recomendamos desabilitar o serviço de integração TimeSync no convidado.

Observação

O suporte para tempo preciso com convidados Linux requer um recurso que só tem suporte nos kernels Linux upstream mais recentes. O recurso ainda não está disponível amplamente em todas as distribuições Linux. Para obter mais informações sobre distribuições de suporte, consulte Máquinas virtuais do Linux e do FreeBSD compatíveis com o Hyper-V no Windows.

Especificar um serviço de hora confiável local com o GTIMESERV

Você pode especificar um ou mais controladores de domínio como relógios de origem precisos usando sinalizador do GTIMESERV, o Servidor de Horário Certo. Por exemplo, os controladores de domínio específicos equipados com hardware de GPS podem ser sinalizados como GTIMESERV. Esse sinalizador garante que o domínio referencie um relógio com base no hardware de GPS.

Observação

Para mais informações sobre os sinalizadores de domínio, consulte a documentação do protocoloMS-ADTS.

TIMESERV é outro Sinalizador de Serviços de Domínio relacionado que indica se um computador está autoritativo no momento, o que pode ser alterado se um controlador de domínio perder a conexão. Um controlador de domínio nesse estado retorna Unknown Stratum quando consultado via NTP. Depois de tentar várias vezes, o controlador de domínio registra o Evento 36 do Serviço de Hora de Evento do Sistema.

Caso você deseje configurar um controlador de domínio como um GTIMESERV, configure manualmente usando o comando a seguir. Nesse caso, o controlador de domínio usa outros computadores como o relógio mestre. Esse computador pode ser um dispositivo ou um computador dedicado.

w32tm /config /manualpeerlist:"master_clock1,0x8 master_clock2,0x8" /syncfromflags:manual /reliable:yes /update

Observação

Para mais informações, confira Configurar o Serviço de Horário do Windows

Se o controlador de domínio tiver o hardware de GPS instalado, use estas etapas para desabilitar o cliente NTP e habilitar o servidor NTP.

Comece desabilitando o cliente NTP e habilite o servidor NTP usando estas alterações de chave do Registro:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t REG_DWORD /d 0 /f

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpServer /v Enabled /t REG_DWORD /d 1 /f

Depois, reinicie o Serviço de Horário do Windows

net stop w32time && net start w32time

Por fim, indique que esse computador tem uma fonte de horário confiável:

w32tm /config /reliable:yes /update

Para verificar se as alterações foram feitas corretamente, execute os comandos a seguir que afetam os resultados mostrados abaixo:

w32tm /query /configuration

Value|Expected Setting|
----- | ----- |
AnnounceFlags| 5 (Local)|
NtpServer |(Local)|
DllName |C:\WINDOWS\SYSTEM32\w32time.DLL (Local)|
Enabled |1 (Local)|
NtpClient| (Local)|

w32tm /query /status /verbose

Value| Expected Setting|
----- | ----- |
Stratum| 1 (primary reference - syncd by radio clock)|
ReferenceId| 0x4C4F434C (source name: "LOCAL")|
Source| Local CMOS Clock|
Phase Offset| 0.0000000s|
Server Role| 576 (Reliable Time Service)|

Windows Server 2016 nas plataformas virtuais de terceiros

Quando o Windows é virtualizado, por padrão, o hipervisor é responsável por fornecer a hora. Porém, os membros ingressados no domínio precisam ser sincronizados com o controlador de domínio para que o Active Directory opere corretamente. É recomendável desabilitar qualquer virtualização de tempo entre o convidado e o host de qualquer plataforma virtual de terceiros.

Descobrir a hierarquia

Como a cadeia de hierarquia de tempo para a fonte do relógio mestre é dinâmica em um domínio e negociada, você precisa consultar o status de um computador específico para entender a fonte de horário e a cadeia para o relógio de origem mestre. Essa informação pode ajudar a diagnosticar problemas de sincronização de hora.

Se você quiser solucionar problemas de um cliente específico, a primeira etapa é entender a fonte de horário usando este comando do w32tm:

w32tm /query /status

Os resultados mostram a origem, entre outras coisas. A origem indica com quem você sincroniza a hora no domínio. Esta é a primeira etapa desta hierarquia de tempo dos computadores. Depois, use a entrada source do comando anterior e use o parâmetro /stripchart para encontrar a próxima fonte de horário na cadeia.

w32tm /stripchart /computer:MySourceEntry /packetinfo /samples:1

Também útil, o comando a seguir lista cada controlador de domínio que ele encontre no domínio especificado e imprime um resultado que permite que você determine cada parceiro. Esse comando inclui computadores configurados manualmente.

w32tm /monitor /domain:my_domain

Com a lista, você pode rastrear os resultados por meio do domínio e entender a hierarquia e a diferença de horário em cada etapa. Ao localizar o ponto em que a diferença de horário fica significativamente pior, você pode identificar a raiz do horário incorreto. Daí em diante, você poderá tentar entender o motivo pelo qual esse horário está incorreto ativando o log do w32tm.

Usar Política de Grupo

Você pode usar a Política de Grupo para chegar a uma precisão mais estrita, por exemplo, atribuir clientes para usar servidores NTP específicos ou controlar como os sistemas operacionais de nível inferior são configurados quando virtualizados. Segue uma lista de possíveis cenários e configurações relevantes da Política de Grupo:

Domínios Virtualizados: para controlar os controladores de domínio virtualizados no Windows Server 2012 R2 para que eles sincronizem a hora com o domínio, não com o host do Hyper-V, você pode desabilitar essa entrada do Registro. Para o controlador de domínio primário, o ideal é não desabilitar a entrada, pois o host do Hyper-V fornece a fonte de horário mais estável. A entrada do Registro exigirá que você reinicie o W32time depois que ele for alterado.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider] "Enabled"=dword:00000000

Cargas sensíveis à precisão: para cargas de trabalho sensíveis à precisão de tempo, você pode configurar grupos de computadores para definir os servidores NTP e as configurações de hora relacionadas, como a frequência de sondagem e atualização do relógio. Normalmente, isso é tratado pelo domínio, mas para obter mais controle, você poderá definir computadores específicos como destino para apontá-los diretamente para o relógio mestre.

Configuração da Política de Grupo Novo valor
NtpServer ClockMasterName,0x8
MinPollInterval 6 a 64 segundos
MaxPollInterval 6
UpdateInterval 100 – uma vez por segundo
EventLogFlags 3 – Todo o log de tempo especial

Observação

As configurações de NtpServer e EventLogFlags estão localizadas em System\Windows Time Service\Time Providers usando as configurações Configurar o cliente NTP do Windows. As outras três estão localizadas em System\Windows Time Service usando as definições de Configuração Global.

Remoto de Cargas sensíveis à precisão remota: para os sistemas em domínios de filial, por exemplo, para Varejo e PCI (Setor de Crédito de Pagamento), o Windows usa as informações do site atual e o localizador de controlador de domínio para encontrar um controlador de domínio local, a menos que haja uma fonte de horário NTP manual configurada. Esse ambiente exige 1 segundo de precisão, que usa a convergência mais rápida para a hora correta. Essa opção permite que o W32Time atrase o relógio. Se esse comportamento for aceitável e cumprir seus requisitos, você poderá criar a política a seguir. Assim como ocorre com qualquer ambiente, lembre-se de testar a sua rede e definir a linha de base dela.

Configuração da Política de Grupo Novo valor
MaxAllowedPhaseOffset 1, mas se houver mais de um segundo, defina o relógio com a hora correta.

configuração MaxAllowedPhaseOffset está localizada em System\Windows Time Service usando as definições de Configuração Global.

Observação

Para obter mais informações sobre a Política de Grupo e as entradas relacionadas, confira Ferramentas do serviço de horário do Windows e o artigo Configurações no TechNet.

Considerações sobre IaaS do Windows e do Azure

Aqui estão alguns pontos a serem considerados para a infraestrutura como serviço (IaaS) do Azure e Windows.

Máquina virtual do Azure: Active Directory Domain Services

Se a VM do Azure que opera o Active Directory Domain Services fizer parte de uma floresta local existente do Active Directory, o TimeSync (VMIC) deverá ser desabilitado. Essa ação permite que todos os controladores de domínio na floresta, físicos e virtuais, usem uma só hierarquia de sincronização de hora. Para mais informações, consulte Executando controladores de domínio no Hyper-V.

Máquina virtual do Azure: Computador ingressado no domínio

Se você estiver hospedando um computador que está ingressado no domínio em uma floresta existente do Active Directory, virtual ou física, a melhor prática será desabilitar a sincronização de hora para o convidado e garantir que o W32Time esteja configurado para sincronizar com o controlador de domínio por meio da configuração da hora como Type=NTP5.

Máquina virtual do Azure: Computador de grupo de trabalho autônomo

Se a VM do Azure não estiver ingressada em um domínio nem for um controlador de domínio, recomendamos manter a configuração de hora padrão e fazer com que a VM seja sincronizada com o host.

Aplicativo do Windows exige a hora precisa

Seguem algumas ações que você pode tomar se seu aplicativo do Windows exigir tempo preciso.

API de carimbo de data/hora

Os programas que exigem a maior precisão em relação ao UTC, e não à passagem do tempo, devem usar a API GetSystemTimePreciseAsFileTime. Usar essa API garante que o aplicativo obtenha a Hora do Sistema, que é condicionada pelo Serviço de Horário do Windows.

Desempenho de UDP

Se você tiver um aplicativo usando a comunicação UDP para transações e for importante minimizar a latência, haverá algumas entradas do Registro relacionadas que você poderá usar para configurar um intervalo de portas a serem excluídas da porta do mecanismo de filtragem base. Essa ação aprimora a latência e aumenta a taxa de transferência. No entanto, as alterações no Registro devem ser limitadas aos administradores experientes. Essa solução alternativa exclui as portas de serem protegidas pelo firewall. Para obter mais informações, confira a referência a seguir.

Para o Windows Server 2012 e o Windows Server 2008, você precisa instalar um hotfix primeiro. Para mais informações, consulte Perda de datagrama ao executar um aplicativo receptor multicast no Windows 8 e no Windows Server 2012.

Atualizar drivers de rede

Alguns fornecedores de rede têm atualizações de driver que aprimoram o desempenho em relação à latência do driver e ao buffer de pacotes UDP. Fale com o fornecedor da rede para ver se há atualizações para ajudar com a taxa de transferência UDP.

Logs para fins de auditoria

Para cumprir as regulamentações de rastreamento de tempo, você poderá arquivar manualmente os logs do w32tm, os logs de eventos e as informações do Monitor de Performance. Posteriormente, as informações arquivadas poderão ser usadas para atestar a conformidade em um momento específico no passado. Os fatores a seguir são usados para indicar a precisão:

  1. Precisão do relógio usando o contador de monitor de performance Diferença de Horário Calculado. Esse contador mostra o relógio com a precisão desejada.
  2. Fonte do relógio procurando Peer Response from nos logs w32tm. Após o texto da mensagem, está o endereço IP ou o VMIC, que descreve a fonte de horário e o próximo na cadeia de relógios de referência a serem validados.
  3. Status da condição do relógio usando os logs w32tm para validar que ClockDispl Discipline: \*SKEW\*TIME\* esteja ocorrendo. Esse status indica que o w32tm está ativo no momento.

Log de eventos

Para a história completa, você também precisará das informações do log de eventos. Se você coletar o log de eventos do sistema e filtrar no Time-Server, Microsoft-Windows-Kernel-Boot e Microsoft-Windows-Kernel-General, poderá descobrir se há outras influências que alteraram a hora, por exemplo, terceiros. Esses logs podem ser necessários para eliminar a interferência externa. A Política de Grupo pode afetar os logs de eventos que são gravados no log. Para mais informações, consulte a seção anterior Usar Política de Grupo.

Log de depuração W32Time

Para habilitar o w32tm para fins de auditoria, o comando a seguir habilita o log que mostra as atualizações periódicas do relógio e indica o relógio de origem. Reinicie o serviço para habilitar o novo log.

Para obter mais informações, confira Ativar o log de depuração no Serviço de Horário do Windows.

w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-73,103,107,110

Monitor de desempenho

O Serviço de Horário do Windows Server 2016 expõe os contadores de desempenho, que podem ser usados para coletar logs de auditoria. Esses contadores ser registrados em log local ou remotamente. Você pode registrar os contadores Diferença de Horário do Computador e Computador e Atraso de Ida e Volta. Como qualquer contador de desempenho, você pode monitorá-los remotamente e criar alertas usando o System Center Operations Manager. Por exemplo, você usar um alerta para informar quando a Diferença de Horário se desloca da precisão desejada. Para obter mais informações, consulte o Pacote de Gerenciamento do System Center.

Exemplo da rastreabilidade do Windows

Em arquivos de log do w32tm, o ideal é validar dois tipos de informação. O primeiro é uma indicação de que o arquivo de log tem um relógio da condição no momento. Esta indicação prova que o seu relógio estava sendo condicionado pelo Serviço de Horário do Windows no momento da controvérsia.

 151802 20:18:32.9821765s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:223 CR:156250 UI:100 phcT:65 KPhO:14307
 151802 20:18:33.9898460s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:64 KPhO:41
 151802 20:18:44.1090410s - ClockDispln Discipline: *SKEW*TIME* - PhCRR:1 CR:156250 UI:100 phcT:65 KPhO:38

O ponto principal é que você vê as mensagens prefixadas com ClockDispln Discipline, que é a prova de que o W32Time está interagindo com o relógio do sistema.

Depois, você precisará localizar o último relatório no log antes do momento da controvérsia que relata o computador de origem que está sendo usado no momento como o relógio de referência. Essa informação pode ser um endereço IP, um nome do computador ou o provedor VMIC, que indica que ele está sendo sincronizado com o host do Hyper-V. O exemplo a seguir fornece um endereço IPv4 10.197.216.105:

151802 20:18:54.6531515s - Response from peer 10.197.216.105,0x8 (ntp.m|0x8|0.0.0.0:123->10.197.216.105:123), ofs: +00.0012218s

Agora que você validou o primeiro sistema na cadeia de tempo de referência, você precisará investigar o arquivo de log na fonte de horário de referência e repetir essas mesmas etapas. Esse processo continuará até que você acesse um relógio físico, como um GPS ou uma fonte de horário conhecida, como o NIST. Se o relógio de referência for um hardware de GPS, os logs do fabricante também poderão ser necessários.

Considerações de rede

Os algoritmos do protocolo NTP têm uma dependência da simetria da rede. À medida que o número de saltos de rede aumenta, a probabilidade de assimetria também aumenta. Por isso, é difícil prever quais tipos de imprecisões você vê nos ambientes específicos.

O Monitor de Desempenho e os novos contadores de Tempo do Windows no Windows Server 2016 podem ser usados para avaliar a precisão dos ambientes e criar linhas de base. Você também pode executar a solução de problemas para determinar a diferença atual de qualquer computador em sua rede.

Há dois padrões gerais de hora precisa na rede:

O Windows dá suporte ao NTP simples (RFC2030) por padrão em computadores não ingressados no domínio. Para os computadores ingressados no domínio, usamos um NTP seguro chamado MS-SNTP, que usa os segredos negociados no domínio, os quais fornecem uma vantagem de gerenciamento em relação ao NTP autenticado descrito no RFC1305 e no RFC5905.

Os protocolos ingressados no domínio e não ingressados no domínio requerem a porta UDP 123. Para obter mais informações sobre as melhores práticas do NTP, consulte Versão preliminar da IETF de melhores práticas atuais do protocolo NTP.

RTC (Relógio de hardware confiável)

O Windows não percorre o tempo, a menos que determinados limites sejam excedidos, mas disciplina o relógio. Isso significa que o w32tm ajusta a frequência do relógio em um intervalo regular, usando a configuração de Frequência de Atualização do Relógio, que usa como padrão uma vez por segundo com o Windows Server 2016. Se o relógio estiver atrasado, isso acelera a frequência. Se estiver adiantado, diminui a frequência. Porém, durante esse tempo entre os ajustes de frequência do relógio, o relógio do hardware fica no controle. Se houver um problema com o firmware ou com o relógio do hardware, a hora do computador poderá se tornar menos precisa.

Esse cenário é outra razão pela qual você precisará fazer testes e definir a linha de base em seu ambiente. Se o contador de performance Diferença de Horário Calculado não se estabilizar com a precisão que você tem como meta, o ideal será verificar se o firmware está atualizado. Como outro teste, você pode ver se o hardware duplicado reproduz o mesmo problema.

Solução de problemas de precisão de tempo e NTP

Use a seção Descobrir a hierarquia para entender a origem da hora imprecisa. Observando a diferença de horário, localize o ponto na hierarquia em que o tempo mais diverge da origem NTP. Assim que você entender a hierarquia, o ideal será tentar entender por que essa fonte de horário específica não recebe a hora precisa.

Ao concentrar-se no sistema com o tempo divergente, use estas ferramentas para coletar mais informações a fim de ajudar a determinar o problema e encontrar uma resolução. A referência UpstreamClockSource é o relógio descoberto usando w32tm /config /status:

  • Logs de evento do sistema
  • Habilite o registro em log usando w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
  • Chave de Registro w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
  • Rastreamentos de rede local
  • Contadores de performance (da máquina local ou UpstreamClockSource)
  • W32tm /stripchart /computer:UpstreamClockSource
  • PING UpstreamClockSource para entender a latência e o número de saltos para a origem
  • Tracert UpstreamClockSource
Problema Sintomas Resolução
O relógio de TSC local não é estável. Usando Perfmon – computador físico, sincronize o relógio estável, mas você ainda verá intervalos de 1 ou 2 minutos de vários 100 us. A atualização do firmware ou validação de outro hardware não exibe o mesmo problema.
Latência da rede. O stripchart w32tm mostra RoundTripDelay de mais de 10 ms. A variação no atraso causa um ruído tão grande quanto metade do tempo de ida e volta, por exemplo, um atraso que só ocorre em uma direção.

UpstreamClockSource é de vários saltos, conforme indicado pelo PING. A TTL deve estar próxima a 128.

Use o Tracert para localizar a latência em cada salto.		 Encontre uma fonte de relógio mais próxima para a hora. Uma solução é instalar um relógio de origem no mesmo segmento ou apontá-lo manualmente ao relógio de origem que está geograficamente mais próximo. Para um cenário de domínio, adicione um computador com a função GTimeServ.
Não é possível acessar a origem NTP de maneira confiável. W32tm /stripchart retorna "Tempo limite da solicitação" de forma intermitente. A origem NTP não está respondendo.
A origem NTP não está respondendo. Verifique os contadores do Perfmon de Contagem de Fontes do Cliente NTP, Solicitações de Entrada do Servidor NTP e Respostas de Saída do Servidor NTP e determine seu uso em comparação com as linhas de base. Usando contadores de desempenho do servidor, determine se a carga mudou em referência às suas linhas de base.

Há problemas de congestionamento de rede?
O controlador de domínio não está usando o relógio mais preciso. Alterações na topologia ou no relógio de tempo mestre adicionado recentemente. w32tm /resync /rediscover
Os relógios do cliente estão em descompasso. Evento Time-Service 36 no log de eventos do sistema e/ou texto no arquivo de log que descreve que o contador de Contagem de Fonte de Tempo do Cliente NTP está indo de 1 para 0. Solucione os problemas da fonte upstream e entenda se ela está tendo problemas de desempenho.

Tempo de definição de linha de base

A definição de linha de base é importante para que você possa entender o desempenho e a precisão da sua rede e compará-los com a linha de base no futuro quando ocorrerem problemas. O ideal será criar uma linha de base do controlador de domínio primário raiz ou de qualquer computador marcado com GTIMESRV. Também recomendamos definir uma linha de base do controlador de domínio primário em cada floresta. Por fim, escolha qualquer controlador de domínio ou computador crítico que tenha características interessantes, como distância ou altas cargas e defina linhas de base para ele.

Também é útil para a linha de base do Windows Server 2016 vs. 2012 R2. Porém, você só tem w32tm /stripchart como uma ferramenta que você pode usar para comparar porque o Windows Server 2012 R2 não tem contadores de performance. Escolha dois computadores com as mesmas características ou atualizar um computador e comparar os resultados após a atualização. O adendo Medições de Tempo do Windows traz mais informações sobre medidas detalhadas entre 2016 e 2012.

Ao usar todos os contadores de desempenho do W32Time, colete dados por, pelo menos, uma semana. Esses dados garantem que você tenha uma referência suficiente para considerar variações na rede ao longo do tempo e uma execução suficiente para ter certeza de que a precisão de tempo é estável.

Redundância do servidor NTP

Para configuração manual do servidor NTP usada com computadores não ingressados no domínio ou o controlador de domínio primário, ter mais de um servidor é uma boa medida de redundância em caso de disponibilidade. Isso também pode oferecer maior precisão, supondo que todas as fontes sejam precisas e estáveis. No entanto, se a topologia não for bem projetada ou se as fontes de horário não forem estáveis, a precisão resultante poderá ser pior. Por isso, tenha cuidado. O limite de servidores de horário compatíveis que o W32Time pode referenciar manualmente é 10.

Segundos bissextos

O período de rotação da Terra varia ao longo do tempo, devido a eventos climáticos e geológicos. Normalmente, a variação é de cerca de um segundo a cada dois anos. Sempre que a variação do tempo atômico aumenta muito, uma correção de um segundo (para cima ou para baixo) é inserida, que é chamada de segundo bissexto. Essa inserção é feita de maneira que a diferença nunca exceda 0,9 segundo. Essa correção é anunciada com seis meses de antecedência da correção real. Antes do Windows Server 2016, o Serviço de Horário da Microsoft não reconhecia os segundos bissextos, mas dependia do serviço de horário externo para cuidar dessa questão. Com o aumento da precisão de tempo do Windows Server 2016, a Microsoft está trabalhando em uma solução mais adequada para o problema de segundo bissexto.

Propagação de Tempo Segura

O W32Time no Server 2016 inclui o recurso Propagação de Tempo Segura. Esse recurso determina o tempo atual aproximado das conexões SSL de saída. Esse valor temporal é usado para monitorar o relógio do sistema local e corrigir os erros grosseiros. Leia mais sobre o recurso nesta postagem no blog. Em implantações com fontes de horário confiáveis e computadores bem monitorados que incluem o monitoramento de diferenças de horário, você pode decidir não usar o recurso Propagação de Tempo Segura e, em vez disso, confiar em sua infraestrutura existente.

Para desabilitar o recurso:

  1. Use a Política de Grupo para gerenciar SecureTimeSeeding. Consulte a seção que se refere à configuração UtilizeSslTimeData: Learn: Política CSP - ADMX_W32Time.

  2. Como alternativa, você pode definir manualmente o valor do Registro. Defina o valor de configuração do Registro de UtilizeSSLTimeData para 0 em um computador específico:

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f

  3. Se não conseguir reinicializar o computador imediatamente, notifique o serviço W32Time sobre a atualização de configuração. Essa notificação interrompe o monitoramento e a imposição de tempo com base nos dados de tempo coletados das conexões SSL.

    W32tm.exe /config /update

  4. A reinicialização do computador torna a configuração efetiva imediatamente e também faz com que ela pare de coletar os dados de tempo das conexões SSL. A última parte tem uma sobrecarga pequena e não deve ser uma preocupação de performance.

  5. Para aplicar essa configuração em um domínio inteiro, defina o valor de UtilizeSSLTimeData na configuração da Política de Grupo do W32Time como 0 e publique a configuração. Quando a configuração for selecionada por um Cliente da Política de Grupo, o W32Time é notificado e interrompe o monitoramento e a imposição de tempo usando dados de tempo do SSL. A coleta de dados de tempo do SSL é interrompida quando cada computador for reinicializado. Se o domínio tiver laptops/tablets compactos portáteis e outros dispositivos, o ideal é excluir esses computadores dessa alteração de política. Esses dispositivos acabam esgotando a bateria e precisarão do recurso Propagação de Tempo Segura para inicializar o tempo.