Melhorias na precisão de tempo para o Windows Server 2016

O Windows Server 2016 melhorou os algoritmos que usa para corrigir a hora e condicionar o relógio local para sincronizar com o Tempo Universal Coordenado (UTC). O Network Time Protocol (NTP) usa quatro valores para calcular o desvio de tempo com base nas marcas temporais da solicitação/resposta do cliente e da solicitação/resposta do servidor. No entanto, as redes são barulhentas e pode haver picos nos dados do NTP devido ao congestionamento da rede e outros fatores que afetam a latência da rede. Os algoritmos do Windows Server 2016 calculam a média desse ruído usando várias técnicas diferentes, o que resulta em um relógio estável e preciso. A fonte que usamos para um tempo preciso também faz referência a uma API melhorada, o que nos dá uma melhor resolução. Com essas melhorias, podemos alcançar uma precisão de 1 ms em relação ao UTC em um domínio.

Hyper-V

O Windows Server 2016 melhorou o Hyper-V serviço TimeSync. As melhorias incluem um tempo inicial mais preciso quando a máquina virtual (VM) é iniciada ou restaurada e a correção de latência de interrupção para amostras fornecidas ao serviço de Tempo do Windows (W32Time). Esta melhoria permite-nos ficar a 10μs do hospedeiro com uma raiz quadrada média (que indica variância) de 50μs, mesmo numa máquina com 75% de carga. Para obter mais informações, consulte Hyper-V arquitetura.

O nível de stratum que o anfitrião comunica ao hóspede é apresentado de forma mais transparente. Anteriormente, o host apresentaria um estrato fixo de 2, independentemente de sua precisão. Com as alterações no Windows Server 2016, o host relata um Stratum 1 maior do que o Host Stratum, o que resulta em melhor tempo para os convidados virtuais. O estrato do host é determinado pelo W32Time através de meios normais com base no seu tempo de origem. Os convidados do Windows Server 2016 ingressados no domínio encontram o relógio mais preciso em vez de usar o host como padrão. Por esse motivo, recomendamos que você desabilite manualmente a configuração Hyper-V Time Provider para máquinas que participam de um domínio no Windows Server 2012 R2 e versões anteriores.

Monitoring

Foram adicionados contadores do Monitor de Desempenho. Estes contadores permitem-lhe criar uma linha de base, monitorizar e resolver problemas de precisão temporal. A tabela a seguir lista os contadores.

Os três primeiros contadores visam cenários para solucionar problemas de precisão. Para obter mais informações, consulte a seção Solucionar problemas de precisão de tempo e NTP mais adiante neste artigo. Os três últimos contadores cobrem cenários de servidor NTP e são úteis quando se está a determinar a carga e a estabelecer uma linha de base para o 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 versões anteriores para cada função. As configurações do Windows Server 2016 e da Atualização de Aniversário do Windows 10 (compilação 14393) agora são exclusivas, e é por isso que elas são mostradas como colunas separadas.

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

Para fornecer um tempo mais preciso, os padrões para frequências de sondagem e atualizações de relógio são aumentados, o que nos permite fazer pequenos ajustes com mais frequência. Essa alteração causa mais tráfego UDP/NTP (User Datagram Protocol). Estes pacotes são pequenos, pelo que deve haver pouco ou nenhum efeito sobre as ligações de banda larga. O benefício é que o desempenho deve ser melhor numa maior variedade de hardware e ambientes.

Para dispositivos alimentados por bateria, aumentar a frequência de sondagem pode causar problemas. Os dispositivos de bateria não armazenam o tempo enquanto desligados. Quando retomam, podem exigir correções frequentes no relógio. Aumentar a frequência de sondagem faz com que o relógio se torne instável e também pode usar mais energia. Recomendamos que você não altere as configurações padrão do cliente.

Os controladores de domínio (DCs) devem ser minimamente afetados, mesmo com o efeito multiplicado das atualizações aumentadas de clientes NTP num 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ê atinja limites para outras funcionalidades de domínio antes de ser afetado pelo aumento das configurações do Windows Server 2016. O Ative Directory usa NTP seguro, que tende a sincronizar o tempo com menos precisão do que o NTP simples. Verificámos que este pode ser dimensionado para clientes a duas camadas de distância do controlador de domínio primário (PDC).

Como um plano conservador, você deve reservar 100 solicitações NTP por segundo por núcleo. Por exemplo, com um domínio composto por quatro DCs com quatro núcleos cada, você deve ser capaz de atender a 1.600 solicitações NTP por segundo. Se você tiver 10.000 clientes configurados para sincronizar o tempo uma vez a cada 64 segundos e as solicitações forem recebidas uniformemente ao longo do tempo, você verá 10.000/64, ou cerca de 160 solicitações/segundo, espalhadas por todos os DCs. Esse valor cai facilmente dentro de nossas 1.600 solicitações NTP/s com base neste exemplo. Essas recomendações de planejamento são conservadoras e dependem em grande parte da sua rede, velocidades do processador e cargas. Estabeleça a linha de base e teste, como sempre, nos seus ambientes.

Se os seus DCs estiverem a funcionar com uma carga de CPU considerável, superior a 40%, essa carga quase de certeza adiciona ruído às respostas do NTP e afeta a sua precisão de tempo no seu domínio. Novamente, você precisa testar em seu ambiente para entender os resultados reais.

Medições de precisão de tempo

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

Methodology

Nosso relógio fonte de domínio consistia em dois servidores NTP de alta precisão com hardware GPS. Também usamos uma máquina de teste de referência separada para medições, que também tinha hardware GPS de alta precisão instalado de um fabricante diferente. 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 seu domínio.

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

1. Meça o relógio local, que é controlado por w32tm, em relação à nossa máquina de teste de referência, que possui hardware GPS separado.

2. Meça pings NTP do servidor NTP para clientes usando o stripchart W32tm.

3. Meça os pings NTP do cliente para o servidor NTP usando o stripchart W32tm.

4. Meça os resultados de Hyper-V do anfitrião para o hóspede usando o Contador de Data e Hora (TSC). Este contador e a hora do sistema são partilhados entre as duas partições. Calculamos a diferença entre o tempo do host e o tempo do cliente na VM. Em seguida, usamos o relógio TSC para interpolar o tempo do anfitrião do hóspede, porque as medições não acontecem ao mesmo tempo. Além disso, usamos o relógio de volume segmentado por tempo para eliminar atrasos e latência na API.

W32tm está incorporado, mas as outras ferramentas que usamos durante nossos testes estão disponíveis para o repositório da Microsoft no GitHub como código aberto para seu teste e uso. Para mais informações sobre como utilizar as ferramentas para realizar medições, consulte Wiki de Ferramentas de Calibração de Tempo do Windows.

Os resultados do teste mostrados são um subconjunto de medições 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 as mesmas máquinas em uma topologia baseada em 2012 para comparação.

Topology

Para comparação, testamos topologias baseadas no Windows Server 2012 R2 e no Windows Server 2016. Ambas as topologias consistem em duas máquinas físicas Hyper-V host que fazem referência a uma máquina Windows Server 2016 com hardware de relógio GPS instalado. Cada host executa três máquinas virtuais Windows integradas ao domínio, que são organizadas de acordo com a topologia a seguir. As linhas representam a hierarquia de tempo e o protocolo/transporte usado.

Visão geral dos resultados gráficos

Os dois gráficos a seguir representam a precisão de tempo para dois membros específicos em um domínio com base na topologia anterior. Cada gráfico exibe os resultados do Windows Server 2012 R2 e 2016 sobrepostos, o que demonstra visualmente as melhorias. A precisão foi medida a partir de dentro da máquina convidada em comparação com o anfitrião. Os dados gráficos representam um subconjunto de todo o conjunto de testes que realizamos e mostram o melhor e o pior cenário.

Desempenho do domínio raiz PDC

O PDC raiz é sincronizado com o host Hyper-V (usando VMIC), que é um Windows Server 2016 com hardware GPS que provou ser preciso e estável. Esse requisito é crítico para a precisão de 1 ms, que é mostrada como a área sombreada identificada pelo texto explicativo.

Desempenho do cliente de domínio filho

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

Teste de longa distância

O gráfico a seguir compara um salto de rede virtual com seis saltos de rede física com o Windows Server 2016. Dois gráficos são sobrepostos um sobre o outro com transparência para mostrar dados sobrepostos. O aumento dos saltos de rede significa maior latência e maiores desvios de tempo. O gráfico é ampliado, de modo que os limites de 1 ms, representados pela área sombreada, são maiores. Como se pode ver, o tempo ainda fica abaixo de 1 ms com vários saltos. Ele é deslocado negativamente, o que demonstra uma assimetria de rede. Cada rede é diferente e as medições dependem de muitos fatores ambientais.

Práticas recomendadas para uma cronometragem precisa

Siga estas práticas recomendadas para uma cronometragem precisa.

Relógio de fonte sólida

O tempo de uma máquina é tão bom quanto o relógio de origem com o qual ela sincroniza. Para atingir 1 ms de precisão, você precisa de hardware GPS ou um aparelho de tempo em sua rede que você referencia como o relógio de origem mestre. Usar a configuração padrão de time.windows.com pode não proporcionar uma fonte horária estável e local. À medida que você se afasta do relógio de origem, a rede afeta a precisão. Ter um relógio de origem mestre em cada datacenter é necessário para a melhor precisão.

Opções de GPS de hardware

Várias soluções de hardware podem oferecer tempo preciso. Em geral, as soluções hoje são baseadas em antenas GPS. As soluções de rádio e modem dial-up utilizam linhas dedicadas. Ligam-se à sua rede como um aparelho ou ligam-se a um PC, por exemplo, Windows através de um dispositivo PCIe ou USB. Diferentes opções oferecem diferentes níveis de precisão e, como sempre, os resultados dependem do seu ambiente. As variáveis que afetam a precisão incluem disponibilidade de GPS, estabilidade e carga da rede e hardware do PC. Todos esses fatores são importantes quando você escolhe um relógio de origem, que é um requisito para um tempo estável e preciso.

Domínio e tempo de sincronização

Os membros do domínio usam a hierarquia de domínio para determinar qual máquina eles usam como fonte para sincronizar o tempo. Cada membro do domínio encontra outra máquina para sincronizar e salva-a como sua fonte de relógio. Cada tipo de membro do domínio segue um conjunto diferente de regras para encontrar uma fonte de relógio para sincronização de tempo. O PDC na raiz da floresta é a fonte de relógio padrão para todos os domínios. Aqui estão listadas diferentes funções e descrições de alto nível para como eles encontram uma fonte:

• Controlador de domínio com função PDC: Esta máquina é a fonte de tempo autoritativa para um domínio. Tem o tempo mais preciso disponível no domínio. Ele 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: Esta máquina atua como uma fonte de tempo para clientes e servidores membros no domínio. Um controlador de domínio pode sincronizar com o PDC dele próprio ou com qualquer controlador de domínio no seu domínio pai.
• Clientes/servidores membros: Esta máquina pode sincronizar com qualquer DC ou PDC do seu próprio domínio ou com um DC ou PDC no domínio pai.

Com base nos candidatos disponíveis, um sistema de pontuação é usado para encontrar a melhor fonte de tempo. Este sistema tem em conta a fiabilidade da fonte de tempo e a sua localização relativa. Essa verificação acontece uma vez quando o serviço de tempo é iniciado. Caso necessite de um controlo mais preciso sobre como o tempo se sincroniza, pode adicionar servidores de tempo de qualidade em locais específicos ou adicionar redundância. Para obter mais informações, consulte a seção Especificar um serviço de horário confiável local usando o GTIMESERV.

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

Embora um ambiente de domínio puro do Windows Server 2016 seja necessário para a melhor precisão, ainda há benefícios em um ambiente misto. A implantação do Windows Server 2016 Hyper-V em um domínio do Windows Server 2012 beneficia os convidados devido às melhorias mencionadas, mas somente se os convidados também estiverem no Windows Server 2016. Um PDC do Windows Server 2016 pode fornecer um tempo mais preciso devido aos algoritmos aprimorados, portanto, é uma fonte mais estável. Como substituir o PDC pode não ser uma opção, podes adicionar um DC do Windows Server 2016 com o conjunto de funções GTIMESERV, o que seria uma melhoria em termos de precisão para o teu domínio. Um controlador de domínio do Windows Server 2016 pode oferecer um tempo melhor aos clientes de tempo downstream, mas é tão preciso quanto a sua fonte de tempo NTP.

Também como dito, as frequências de sondagem e atualização do relógio foram modificadas com o Windows Server 2016. Essas freqüências podem ser alteradas manualmente para seus DCs de nível inferior ou aplicadas por meio da Diretiva 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 oferecer alguns benefícios.

As versões anteriores ao Windows Server 2016 tinham vários problemas com a cronometragem precisa, o que resultava no desvio de tempo do sistema imediatamente após a realização de um ajuste. Devido a esse problema, a obtenção frequente de amostras de tempo de uma fonte NTP precisa e o condicionamento do relógio local com os dados leva a um desvio menor em seus relógios de sistema no período intra-amostragem. O resultado é um melhor gerenciamento de tempo em versões antigas do sistema operativo. A melhor precisão observada foi de aproximadamente 5 ms quando um cliente NTP do Windows Server 2012 R2, configurado com as configurações de alta precisão, sincronizou seu tempo a partir de um servidor NTP do Windows Server 2016 preciso.

Em alguns cenários envolvendo DCs convidados, Hyper-V exemplos do TimeSync podem interromper a sincronização de tempo de domínio. Esse problema não deve mais existir para convidados do Windows Server 2016 em execução em hosts Hyper-V Windows Server 2016.

Para desativar o Hyper-V serviço TimeSync de fornecer amostras para W32Time, defina a seguinte chave de registro convidado:

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

Permitir que o Linux use Hyper-V tempo de host

Para convidados Linux em execução no Hyper-V, os clientes normalmente são configurados para usar o daemon NTP para sincronização de tempo com servidores NTP. Se a distribuição Linux suportar o protocolo TimeSync versão 4 e o convidado Linux tiver o serviço de integração TimeSync ativado, ele sincronizará com o tempo do host. Esse cenário pode levar a uma cronometragem inconsistente se ambos os métodos estiverem habilitados.

Para sincronizar exclusivamente com o tempo do host, recomendamos que você desabilite a sincronização de tempo 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 Time Server é esse host. A sua Frequência de Sondagem é de 5 segundos e a Frequência de Atualização do Relógio também é de 5 segundos.

Para sincronizar exclusivamente por NTP, recomendamos que você desabilite o serviço de integração do TimeSync no convidado.

Especifique um serviço de horário local confiável usando GTIMESERV

Você pode especificar um ou mais DCs como relógios de origem precisos usando o sinalizador Good Time Server GTIMESERV. Por exemplo, DCs específicos equipados com hardware GPS podem ser sinalizados como GTIMESERV. Este sinalizador garante que o seu domínio faz referência a um relógio baseado no hardware GPS.

TIMESERV é outro sinalizador dos Serviços de Domínio relacionado que indica se uma máquina é autoritativa no momento, o que pode mudar se um controlador de domínio (DC) perder a conexão. Um DC nesse estado retorna Unknown Stratum quando consultado via NTP. Depois de tentar várias vezes, o DC registra o Evento do Sistema Time-Service, Evento 36.

Se você quiser configurar um DC como GTIMESERV, configure-o manualmente usando o seguinte comando. Neste caso, o DC usa outra máquina como relógio mestre. Esta máquina pode ser um aparelho ou uma máquina dedicada.

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

Se o DC tiver o hardware GPS instalado, use as etapas a seguir para desativar o cliente NTP e habilitar o servidor NTP.

Comece desativando 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

Em seguida, reinicie o serviço de Tempo do Windows:

net stop w32time && net start w32time

Finalmente, você indica que esta máquina tem uma fonte de tempo confiável:

w32tm /config /reliable:yes /update

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

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 em plataformas virtuais de terceiros

Quando o Windows é virtualizado, por padrão, o Hypervisor é responsável por fornecer tempo. Mas os membros ingressados no domínio precisam ser sincronizados com o DC para que o Ative Directory funcione corretamente. É melhor desativar a virtualização a qualquer momento entre o convidado e o host de quaisquer plataformas virtuais de terceiros.

Descubra a hierarquia

Como a cadeia de hierarquia de tempo para a fonte de relógio mestre é dinâmica num domínio e negociada, é necessário consultar o estado de uma determinada máquina para compreender a sua fonte de tempo e cadeia para o relógio mestre de origem. Essas informações podem ajudar a diagnosticar problemas de sincronização de tempo.

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

w32tm /query /status

Os resultados mostram a fonte, entre outras coisas. A fonte indica com quem você sincroniza o tempo no domínio. É o primeiro passo da hierarquia de tempo desta máquina. Em seguida, use a entrada de origem do comando anterior e use o parâmetro /stripchart para localizar a próxima fonte na cadeia.

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

Também útil, o comando a seguir lista cada DC que pode encontrar no domínio especificado e imprime um resultado que permite determinar cada parceiro. Este comando inclui máquinas que foram configuradas manualmente.

w32tm /monitor /domain:my_domain

Usando a lista, você pode rastrear os resultados através do domínio e entender a hierarquia e o deslocamento de tempo em cada etapa. Ao localizar o ponto onde o deslocamento de tempo piora significativamente, você pode identificar a raiz do tempo incorreto. A partir daí, pode-se tentar entender por que aquela hora está incorreta ativando o registo w32tm.

Utilizar a Política de Grupo

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

Domínios virtualizados: para controlar DCs virtualizados no Windows Server 2012 R2 para que sincronizem o tempo com seu domínio, em vez de com o host Hyper-V, você pode desabilitar essa entrada do Registro. Para o PDC, você não deseja desativar a entrada porque o host Hyper-V fornece a fonte de tempo mais estável. A entrada de registo requer que reinicie o W32Time depois de ter sido 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 máquinas para definir os servidores NTP e quaisquer configurações de tempo relacionadas, como sondagem e frequência de atualização de relógio. Essa tarefa normalmente é manipulada pelo domínio, mas para obter mais controle, você pode direcionar máquinas específicas para apontar diretamente para o relógio mestre.

Cargas remotas sensíveis à precisãoremoto: Para sistemas em domínios de filiais, por exemplo, Varejo e Indústria de Pagamento por Cartão (PCI), o Windows utiliza as informações atuais do sítio e o Localizador de Controlador de Domínio (DC) para encontrar um DC local, a menos que haja uma fonte de tempo manual NTP configurada. Este ambiente requer precisão de 1 segundo, o que usa uma convergência mais rápida para atingir o tempo correto. Esta opção permite que o W32Time mova o relógio para trás. Se esse comportamento for aceitável e atender aos seus requisitos, você poderá criar a seguinte política. Como em qualquer ambiente, certifique-se de testar e estabelecer uma linha de base para a sua rede.

A MaxAllowedPhaseOffset configuração está localizada em Sistema\Serviço de Tempo do Windows usando as definições de Configuração Global .

Considerações sobre IaaS do Azure e do Windows

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

Máquina virtual do Azure: Serviços de Domínio Ative Directory

Se a VM do Azure que executa os Serviços de Domínio Ative Directory fizer parte de uma floresta do Ative Directory local existente, o TimeSync (VMIC) deverá ser desabilitado. Essa ação permite que todos os DCs na floresta, físicos e virtuais, usem uma única hierarquia de sincronização de tempo. Para obter mais informações, consulte Executando controladores de domínio no Hyper-V.

Máquina virtual do Azure: máquina associada a um domínio

Se estiver a hospedar uma máquina cujo domínio ingressou numa floresta existente do Active Directory, virtual ou física, a prática recomendada é desativar o TimeSync para a máquina virtual e garantir que o W32Time esteja configurado para sincronizar com o seu Controlador de Domínio através da configuração de tempo para Type=NTP5.

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

Se a VM do Azure não estiver associada a um domínio e não for um DC, recomendamos que você mantenha a configuração de hora padrão e faça com que a VM sincronize com o host.

Aplicação do Windows requer tempo preciso

Aqui estão algumas ações que você pode tomar se seu aplicativo do Windows exigir tempo preciso.

API de marca temporal

Os programas que exigem a maior precisão em relação ao UTC, e não a passagem do tempo, devem usar a API GetSystemTimePreciseAsFileTime. O uso desta API garante que a sua aplicação obtenha o Tempo do Sistema, que é condicionado pelo serviço de hora do Windows.

Desempenho UDP

Se você tiver um aplicativo que usa comunicação UDP para transações e for importante minimizar a latência, há algumas entradas do Registro relacionadas que você pode usar para configurar um intervalo de portas a serem excluídas do mecanismo de filtragem de base de porta. Essa ação melhora a latência e aumenta a taxa de transferência. No entanto, as alterações ao registo devem limitar-se a administradores experientes. Esta solução alternativa exclui as portas de serem protegidas pelo firewall. Para obter mais informações, consulte a referência a seguir.

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

Atualizar drivers de rede

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

Registro em log para fins de auditoria

Para estar em conformidade com os regulamentos de rastreamento de tempo, pode arquivar manualmente registos w32tm, registos de eventos e informações do Monitor de Performance. Mais tarde, as informações arquivadas podem ser usadas para atestar a conformidade em um momento específico no passado. Os seguintes fatores são usados para indicar a precisão:

1. Precisão do relógio usando o contador Deslocamento de Tempo Computado Monitor de Desempenho. Este contador mostra o relógio dentro da precisão desejada.
2. Fonte do relógio procurando Peer Response from nos logs de w32tm. Seguindo o texto da mensagem está o endereço IP ou VMIC, que descreve a fonte de tempo e o próximo na cadeia de relógios de referência para validar.
3. Condição do relógio usando os logs de w32tm para validar que ClockDispl Discipline: \*SKEW\*TIME\* está ocorrendo. Esse status indica que w32tm está ativo no momento.

Registo de eventos

Para obter a história completa, você também precisa de informações de log de eventos. Ao recolher o log de eventos do sistema e filtrar em Time-Server, Microsoft-Windows-Kernel-Boot e Microsoft-Windows-Kernel-General, poderá descobrir se outras influências alteraram o tempo, como por exemplo, os terceiros. Esses logs podem ser necessários para excluir interferências externas. A Diretiva de Grupo pode afetar quais logs de eventos são gravados no log. Para obter mais informações, consulte a seção anterior Usar a Diretiva de Grupo.

Registo de depuração W32Time

Para habilitar w32tm para fins de auditoria, o comando a seguir habilita o registro em 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 registro.

Para obter mais informações, consulte Ativar o log de depuração no serviço de Tempo do Windows.

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

Performance Monitor

O serviço de Tempo do Windows Server 2016 expõe contadores de desempenho, que podem ser usados para coletar registos para efeitos de auditoria. Esses contadores podem ser registrados local ou remotamente. Você pode gravar o de Deslocamento de Tempo do Computador e Contadores de 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ê pode usar um alerta para alertá-lo quando o Time Offset se desviar da precisão desejada. Para obter mais informações, consulte o System Center Management Pack.

Exemplo de rastreabilidade do Windows

Dos ficheiros de registo w32tm, quer validar duas informações. O primeiro é uma indicação de que o arquivo de log atualmente funciona como um contador de condições. Esta indicação prova que o seu relógio estava a ser condicionado pelo serviço de Hora do Windows à hora discutida.

 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ê mensagens prefixadas com ClockDispln Discipline, que é a prova de que o W32Time está interagindo com o relógio do sistema.

Em seguida, você precisa encontrar o último relatório no log antes da hora disputada que relata o computador de origem, que está sendo usado atualmente como relógio de referência. Essas informações podem ser um endereço IP, nome do computador ou o provedor VMIC, o que indica que ele está sincronizando com o host do Hyper-V. O exemplo a seguir fornece um endereço IPv4 de 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ê precisa investigar o arquivo de log na fonte de tempo de referência e repetir as mesmas etapas. Esse processo continua até chegar a um relógio físico, como o GPS, ou a uma fonte de tempo conhecida, como o NIST. Se o relógio de referência for hardware GPS, os registos do fabricante também podem ser necessários.

Considerações sobre a rede

Os algoritmos do protocolo NTP dependem da simetria da sua rede. À medida que você aumenta o número de saltos de rede, a probabilidade de assimetria aumenta. Por esse motivo, é difícil prever que tipos de precisão você vê em seus 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 do seu ambiente e criar linhas de base. Você também pode executar a solução de problemas para determinar o deslocamento atual de qualquer máquina na rede.

Existem dois padrões gerais para o tempo preciso através da rede:

• Precision Time Protocol - IEEE 1588(PTP): O PTP tem requisitos mais rígidos na infraestrutura de rede, mas muitas vezes pode fornecer precisão de submicrossegundos.
• Network Time Protocol – RFC 1305(NTP): O NTP funciona em uma maior variedade de redes e ambientes, o que facilita o gerenciamento.

O Windows suporta NTP simples (RFC2030) por padrão para máquinas que não ingressaram no domínio. Para máquinas associadas a domínios, usamos um NTP seguro chamado MS-SNTP, que usa segredos negociados por domínio que fornecem uma vantagem de gerenciamento sobre o NTP autenticado descrito em RFC1305 e RFC5905.

Os protocolos de domínio e não associados ao domínio requerem a porta UDP 123. Para obter mais informações sobre as práticas recomendadas de NTP, consulte Network Time Protocol Best Current Practices IETF Draft.

Relógio de hardware confiável (RTC)

Windows não conta o tempo, a menos que certos limites sejam excedidos, mas apenas disciplina o relógio. Isso significa que 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 assume como padrão uma vez por segundo com o Windows Server 2016. Se o relógio estiver atrasado, acelera a frequência. Se estiver adiantado, reduz a frequência. Durante o período entre os ajustes de frequência do relógio, no entanto, é o relógio do hardware que está no controle. Se houver um problema com o firmware ou o relógio de hardware, o tempo na máquina pode se tornar menos preciso.

Esse cenário é outro motivo pelo qual é necessário testar e definir uma base no teu ambiente. Se o contador de desempenho Deslocamento de Tempo Computado não estabilizar na precisão pretendida, convém verificar se o firmware está atualizado. Como outro teste, você pode ver se o hardware duplicado reproduz o mesmo problema.

Solucionar problemas de precisão temporal e NTP

Você pode usar a seção Descubra a hierarquia para entender a origem do tempo impreciso. Olhando para o desvio de tempo, encontre o ponto na hierarquia onde o tempo mais se desvia da sua fonte NTP. Quando você entende a hierarquia, você quer tentar entender por que essa fonte de tempo específica não recebe tempo preciso.

Ao se concentrar no sistema com tempo divergente, você pode usar as seguintes ferramentas para coletar mais informações para ajudá-lo a determinar o problema e encontrar uma resolução. A referência UpstreamClockSource é o relógio descoberto usando w32tm /config /status:

• Logs de eventos do sistema
• Habilitar o log usando w32tm logs - w32tm /debug /enable /file:C:\Windows\Temp\w32time-test.log /size:10000000 /entries:0-300
• Chave de registo w32Time HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
• Rastreamentos de rede local
• Contadores de desempenho (da máquina local ou UpstreamClockSource)
• W32tm /stripchart /computer:UpstreamClockSource
• PING UpstreamClockSource para identificar a latência e o número de saltos para a origem
• Tracert UpstreamClockSource

Tempo de linha de base

A definição de uma linha de base é importante para que possas compreender o desempenho e a precisão da tua rede e depois compará-la com a linha de base no futuro, quando surgirem problemas. Você deseja estabelecer a configuração padrão no controlador de domínio primário (PDC) raiz ou em quaisquer máquinas marcadas com GTIMESRV. Recomendamos também que se defina uma referência para o PDC em todas as florestas. Por fim, escolha quaisquer CDs ou máquinas críticas que tenham características interessantes, como distância ou cargas elevadas, e estabeleça uma linha de base para essas.

Estabelecer um ponto de referência para comparar o Windows Server 2016 com o 2012 R2 também é útil. No entanto, 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 desempenho. Você deve escolher duas máquinas com as mesmas características ou atualizar uma máquina e comparar os resultados após a atualização. O adendo de Medições de Tempo do Windows tem mais informações sobre como fazer medições detalhadas entre 2016 e 2012.

Usando todos os contadores de desempenho do W32Time, colete dados por pelo menos uma semana. Esses dados garantem que tenha uma referência adequada para contabilizar as variações na rede ao longo do tempo e que o período de coleta seja suficiente para fornecer confiança de que a sua precisão temporal é estável.

Redundância de servidor NTP

Para a configuração manual do servidor NTP usada com máquinas não associadas ao domínio ou com o PDC, ter mais de um servidor é uma boa medida de redundância em caso de disponibilidade. Também pode dar uma melhor precisão, assumindo que todas as fontes são precisas e estáveis. No entanto, se a topologia não for bem projetada ou as fontes de tempo não forem estáveis, a precisão resultante pode ser pior, portanto, recomenda-se cautela. O limite de servidores de tempo suportados que o W32Time pode referenciar manualmente é 10.

Segundos bissextos

O período de rotação da Terra varia ao longo do tempo devido a fenómenos 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 cresce demais, uma correção de um segundo (para cima ou para baixo) é inserida, o que é chamado de segundo bissexto. Esta inserção é feita de tal forma que a diferença nunca excede 0,9 segundos. Esta correção é anunciada seis meses antes da correção efetiva. Antes do Windows Server 2016, o Serviço de Hora da Microsoft não estava ciente dos segundos bissextos, mas dependia do serviço de hora externo encarregado de resolver esse problema. Com o aumento da precisão temporal do Windows Server 2016, a Microsoft está a trabalhar numa solução mais adequada para o problema do segundo intercalar.

Semeadura de tempo segura

O W32Time no Server 2016 inclui o recurso Secure Time Seeding. Esse recurso determina o tempo atual aproximado das conexões SSL de saída. Esse valor de tempo é usado para monitorar o relógio do sistema local e corrigir quaisquer erros grosseiros. Você pode ler mais sobre o recurso nesta postagem do blog . Em implantações com fontes de tempo confiáveis e máquinas bem monitoradas que incluem monitoramento para compensações de tempo, você pode optar por não usar o recurso Secure Time Seeding e confiar em sua infraestrutura existente.

Para desativar o recurso:

1. Utilize a Política de Grupo para gerir SecureTimeSeeding. Consulte a seção que se refere à configuração UtilizeSslTimeData: Saiba mais: Política CSP - ADMX_W32Time.

2. Como alternativa, você pode definir manualmente o valor do Registro. Defina o valor de configuração do registo UtilizeSSLTimeData para 0 numa máquina específica:

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

3. Se não conseguir reiniciar a máquina imediatamente, pode notificar o W32Time sobre a atualização de configuração. Essa notificação interrompe o monitoramento e a imposição do tempo com base nos dados de tempo coletados de conexões SSL.

   W32tm.exe /config /update
   

4. Reinicializar a máquina torna a configuração efetiva imediatamente e também faz com que ela pare de coletar dados de tempo de conexões SSL. A última parte tem uma pequena sobrecarga e não deve ser uma preocupação de desempenho.

5. Para aplicar essa configuração em um domínio inteiro, defina o valor UtilizeSSLTimeData na configuração de Diretiva de Grupo W32Time para 0 e publique a configuração. Quando a configuração é captada por um cliente de Diretiva de Grupo, o W32Time é notificado e interrompe o monitoramento e a imposição do tempo usando dados de tempo SSL. A coleta de dados de tempo SSL para quando cada máquina reinicia. Se o seu domínio tiver laptops/tablets finos portáteis e outros dispositivos, convém excluir essas máquinas desta alteração de política. Esses dispositivos acabam por enfrentar o esgotamento da bateria e precisam do recurso Secure Time Seeding para configurar a sua hora.