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

14

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

Além disso, meu instinto é que esses servidores de horário local devem residir 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ão o fazia <> especificamente como o VMware . Em vez disso, eu quis dizer o conceito geral de instâncias virtualizadas.

    
por James A. Rosen 26.01.2010 / 19:22

4 respostas

18

O simples fato é que a precisão do clock em uma VM ainda é muito ruim. Isso vem de alguns pontos, mas o mais importante é que o tempo não é constante; o fator de deriva muda de momento para momento. O NTP é um protocolo que possui uma compensação de clock embutida, mas foi projetado com um fator de desvio estático embutido. Por exemplo, se uma máquina física perder 12 segundos a cada 30 dias, o NTP pode compensar isso e o faz 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 acompanhar esse nível de mudança.

O que torna muito difícil manter o NTP em um ambiente de VM é que o relógio local que ele vê pode mudar seu fator de desvio ao longo de um minuto. Dependendo da frequência em que está verificando suas origens de tempo pai, isso pode causar grandes alterações no fator de desvio e fazer com que ele saia de sincronia com muito mais frequência. Tempo de sincronização fora de sincronia em toda a sua organização.

O NTP para uma rede local é um protocolo de impacto relativamente baixo, com um tamanho de memória muito pequeno, e pode ser usado com facilidade em outros servidores de infraestrutura de rede, como os servidores DNS e DHCP. Alguns roteadores também podem fornecer a funcionalidade NTP, então você pode querer investigar isso.

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 idéia de ambos os servidores de tempo terem sido configurados para usar o outro servidor como um 'peer', o que minimizará o impacto no tempo de serviço, caso um dos fontes de tempo upstream dê errado; haverá uma mudança de estrato, mas pelo menos não será reportado fora de sincronia. E, finalmente, seja gentil com seus provedores de tempo de upstream e configure seus servidores para passar 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ê tivesse que usar VMs para isso, eu configuraria nada menos que 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 com o que acabei de sugerir, eles precisam de diferentes fontes de tempo e devem olhar um para o outro. Em seguida, configure todos os seus clientes NTP para usar todos os três como fontes pai. Verifique se os valores de seu maxpoll estão baixos o suficiente para nunca ultrapassar uma hora e meia entre os pacotes de sincronização fora da rede e 30 minutos na rede. As chances são boas, pelo menos, um dos três estará em sincronia a qualquer momento. Para os clientes que só podem conversar com um host de tempo, eles apenas terão que aturar um evento ocasional fora de sincronia. No geral, a qualidade do tempo neste cenário não seria tão exata quanto seria com os servidores físicos.

Se eu tivesse que jogar bola, eu diria que seu tempo de consenso no ambiente de VM pura provavelmente estaria dentro de 30 a 100 ms de verdade. Em um ambiente puramente físico, seu tempo de consenso provavelmente estaria dentro de 10ms, uma vez que os servidores de tempo estivessem ativos o suficiente para que o tempo se resolvesse.

    
por 26.01.2010 / 19:54
10

Veja o documento sobre a cronometragem do vmware . A execução de um daemon NTP em uma VM provavelmente não é uma boa ideia, especialmente se você precisar de tempo confiável.

    
por 26.01.2010 / 19:27
5

infelizmente o ntp e a virtualização não combinam muito bem. os clientes estão ok na maioria dos casos, no entanto, o servidor ntp (esp str2 e acima) geralmente não funcionará de maneira confiável no servidor virtual.

Estou comentando do ponto de vista da empresa xen e xen, mas acredito que o vmware / kvm será o mesmo.

re servidores diferentes, sim, você está certo, idealmente eles devem estar em ambientes diferentes também, de modo que temp / umidade não estão afetando a precisão também, mas pelo menos eu não me incomodo com isso. também não se esqueça de que o que quer que você faça ainda não é tão preciso quanto o próprio relógio atômico, então apenas aceite esse desvio (muito leve).

    
por 26.01.2010 / 19:27
0

Executando o NTP em um ambiente virtualizado, você terá a sorte de atingir 20ms de precisão (foi o que fizemos usando o VMware). O desvio de 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 importa apenas com o segundo (EG para servidores da Web), provavelmente ficará bem, contanto que você não tenha contenção de recursos. Se você quiser precisão em milissegundos (como um banco de dados ocupado, servidor de log, projeto de pesquisa), esqueça os servidores de tempo virtualizados.

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

    
por 26.09.2013 / 06:37