Quais são os limites da execução de servidores NTP em máquinas virtuais? (2010)

Question

Quero configurar vários servidores de horário Stratum 2 em minha rede local. As máquinas virtuais certamente seriam uma maneira mais barata de fazer isso do que comprar três servidores 1U. Que limitações isso imporia? Isto é, até que ponto a precisão será afetada negativamente?

Além disso, meu instinto é que esses servidores de horário local residam em máquinas físicas diferentes para mitigar quaisquer irregularidades de hardware. Esta intuição está correta?

Editar Devo dizer que por "máquinas virtuais" nãoespecificamentesignificarVMware. Em vez disso, quis dizer o conceito geral de instâncias virtualizadas.

Answer 1

Agora é 2023 etodas as respostas anteriores a esta pergunta estão agora erradas(e tem sido desde pelo menos o final de 2016), pelo menos no que diz respeito às VMs Linux. [O conselho abaixo pode não se aplicar a VMs do Windows.]

Se você estiver lendo isso em 2023 ou mais tarde, não acredite nas afirmações das respostas de 2013 ou antes sobre a precisão máxima de 20-100 ms. A sincronização de tempo em VMs modernas pode atingir precisão inferior a 1 milissegundo em uma LAN e aproximar-se de 1 milissegundo em uma conexão de Internet de nível consumidor.

As seguintes perguntas ServerFault contêm discussões mais atualizadas:

• Coisas a considerar ao executar servidores NTP públicos
• As configurações "menos ruins" para o Chrony como servidor NTP em uma máquina virtual

Aqui estão alguns gráficos ilustrativos de deslocamento (apresentados em ordem cronológica) para sustentar minhas afirmações. Em alguns casos, ainda tenho os arquivos de log brutos, que ficaria mais do que feliz em fornecer a qualquer pessoa que queira investigar por conta própria. Observe a escala do gráfico em cada instância:

1. Uma VM rodando ntpdem uma nuvem privada OpenStack sob o hipervisor KVM (em algum tipo de Intel Xeon) no final de 2016:
2. Uma VM em execução ntpdem um host KVM independente (em um Intel Celeron 1037U) em meados de 2020:
3. Várias t3a.microinstâncias da AWS (AMD) em execução chronydno final de 2021:
4. Várias t4g.microinstâncias AWS (ARM) em execução chronydno final de 2021:
5. Várias Standard_B1sinstâncias do Azure (Intel) em execução chronydno início de 2022:
6. Vários contêineres em execução chronydno AWS ECS/Fargate (Intel) no final de 2022:

Answer 2

O simples fato é que em 2010 a precisão do clock em uma VM ainda é muito ruim. Isso vem de alguns pontos, mas o mais importante é que a variação do tempo não é constante; o fator de deriva muda de momento a momento. O NTP é um protocolo que possui compensação de clock integrada, mas foi projetado com um fator de desvio estático integrado. Por exemplo, se uma máquina física perder 12 segundos a cada 30 dias, o NTP poderá compensar isso e o fará muito bem. Mas se essa máquina pode perder de 4 a 70 segundos a cada 30 dias, o NTP não é tão bom em rastrear esse nível de mudança.

O que torna realmente difícil para o NTP acompanhar um ambiente de VM é que o relógio local que ele vê pode alterar seu fator de desvio ao longo de um minuto. Dependendo da frequência com que ele verifica suas fontes de tempo pai, ele pode causar grandes alterações no fator de desvio e ficar fora de sincronia com muito mais frequência. O tempo fora de sincronia ocorre em toda a sua organização.

O NTP para uma rede local é um protocolo de impacto relativamente baixo, com um consumo de memória muito pequeno e pode ser aproveitado em outros servidores de infraestrutura de rede, como servidores DNS e DHCP. Alguns roteadores também podem fornecer funcionalidade NTP, então você pode querer dar uma olhada nisso.

O ideal é que você queira dois servidores separados em locais separados, cada um sincronizado com um conjunto diferente de servidores de estrato superior. Também seria uma boa ideia que ambos os servidores de horário fossem configurados para usar o outro servidor como um 'peer', o que minimizará o impacto no serviço de horário caso uma das fontes de horário upstream dê errado; haverá uma mudança de estrato, mas pelo menos não será relatado fora de sincronia. E, finalmente, seja gentil com seus provedores de horário upstream e configure seus servidores para passarem muito tempo entre as pesquisas, uma vez que o tempo esteja bem estabelecido. Este é o parâmetro 'maxpoll' na linha 'server' e é uma potência de dois em segundos entre as tentativas de sincronização.

Se você realmente tivesse que usar VMs para isso, eu configuraria pelo menos três desses servidores NTP. Cada um deles precisa estar em um host diferente e, se possível, em um data center diferente. Tal como acontece com o que acabei de sugerir, eles precisam de fontes de tempo diferentes e devem emparelhar-se. Em seguida, configure todos os seus clientes NTP para usar todos os três como fontes pai. Certifique-se de que seus valores de maxpoll sejam baixos o suficiente para nunca passar mais de uma hora e meia entre pacotes de sincronização fora da rede e 30 minutos dentro da rede. As chances são boas de que pelo menos um dos três esteja sincronizado a qualquer momento. Para clientes que só podem falar com um host de horário, eles apenas terão que suportar eventos ocasionais de falta de sincronia. No geral, a qualidade do tempo neste cenário não seria tão exata como seria com servidores físicos.

Se eu tivesse que estimar, diria que seu tempo de consenso no ambiente de VM pura provavelmente estaria entre 30 e 100 ms da verdade. Em um ambiente puramente físico, seu tempo de consenso provavelmente seria de 10 ms, uma vez que os servidores de horário estivessem ativos por tempo suficiente para que o tempo se estabilizasse.

Answer 3

Veja a cronometragem do VMwaredocumento. Executar um daemon NTP em uma VM provavelmente não é uma boa ideia, principalmente se você precisar de tempo confiável.

Answer 4

Executando o NTP em um ambiente virtualizado, você terá sorte se conseguir uma precisão de 20 ms (foi o que fizemos usando o VMware). A distorção do relógio virtualizado é ruim, especialmente em um ambiente virtualizado com contenção de recursos.

Depende de quão preciso você precisa ser. Se você se preocupa apenas com o segundo (EG para servidores web), provavelmente ficará bem, desde que não haja contenção de recursos. Se você deseja precisão de milissegundos (como um banco de dados ocupado, servidor de log, projeto de pesquisa), esqueça os servidores de horário virtualizados.

Os servidores NTP devem estar sempre em hosts físicos. Você deve ter pelo menos 3 deles espreitando em um pool (para que um servidor não autorizado seja rejeitado pelo pool); e, se possível, obtenha a hora do GPS ou de outra fonte local de nível 0, em vez da Internet.