Pontos a serem considerados ao executar servidores NTP públicos

Recentemente, ocorreu-me que, como tenho 3 relógios GPS na minha rede, eu poderia, tecnicamente, retribuir um pouco e servir tempo ao resto do mundo. Até agora, não vi nenhuma desvantagem com essas idéias, mas tenho as seguintes perguntas;

1. Posso virtualizar isso? Eu não vou gastar dinheiro e tempo em pé com hardware para isso, então a virtualização é uma obrigação. Como os servidores terão acesso a três fontes do estrato 1, não vejo como isso pode ser um problema, desde que a configuração do ntpd esteja correta

2. Que tipo de tráfego um servidor NTP público (parte de pool.ntp.org) normalmente vê? E de quais VMs grandes eu preciso para isso? O ntpd não deve consumir muitos recursos, tanto quanto posso, mas prefiro saber antes.

3. Que aspectos de segurança existem para isso? Estou pensando em apenas instalar o ntpd em duas VMs na DMZ, permitir apenas o ntp através do FW e apenas o ntp do DMZ para os servidores internos do ntp. Também parece haver algumas configurações de NTP recomendadas de acordo com a página do pool NTP, mas elas são suficientes? https://www.ntppool.org/join/configuration.html

4. Eles recomendam não ter o driver do relógio LOCAL configurado. Isso equivale a remover a configuração da fonte da hora LOCAL dos arquivos de configuração?

5. Mais alguma coisa a considerar?

Em primeiro lugar, bom para você; é uma coisa útil e de espírito público a se fazer. Dito isso, e dado seu esclarecimento de que você está planejando criar uma ou mais VMs DMZ que serão sincronizadas e disponibilizarão publicamente o tempo de seus três servidores estrato 1 (internos) Meinberg habilitados para GPS:

1. Editar : a virtualização surge para discussão na lista de pools de tempos em tempos; um recente foi em julho de 2015, que pode ser seguido a partir deste e-mail . Pergunte a Bjørn Hansen, líder do projeto, postou no tópico e não se manifestou contra a virtualização. Claramente, vários operadores de servidores de pool estão virtualizando no momento, então não acho que alguém o atenda por isso, e como um pôster deixa claro, se seus servidores não são confiáveis, o sistema de monitoramento de pool simplesmente os remove do piscina. KVM parece ser a tecnologia de virtualização preferida; Não encontrei ninguém especificamente usando o VMWare; portanto, não posso comentar sobre o quão "honesta" é uma virtualização. Talvez o melhor resumo sobre o assunto tenha dito

   Meus servidores de pool são virtualizados com o KVM em meus próprios hosts KVM. O monitoramento diz que o servidor é bastante preciso e oferece tempo estável nos últimos 2 a 3 anos. Mas eu não configuraria um servidor de pool em um servidor virtual alugado de outro provedor.

2. Esse é o número médio diário de clientes distintos por segundo que vejo no meu servidor de pool (que fica no Reino Unido, na Europa e nas regiões globais) no ano passado:

   

   Isso impõe quase nenhuma carga detectável do sistema ( ntpdparece usar entre 1% e 2% de uma CPU, na maioria das vezes). Observe que, em algum momento do ano, a carga atingiu um pico de quase mil clientes por segundo (Máx: 849,27); Eu monitorei a carga excessiva e os alarmes nem todos dispararam, então só posso observar que mesmo esse nível de carga não causou problemas, embora brevemente.

3. As configurações recomendadas pelo projeto são práticas recomendadas e funcionam para mim. Eu também uso iptablespara limitar a taxa de clientes a dois pacotes de entrada em uma janela de dez segundos (é incrível quantos clientes rudes existem por aí, que pensam que devem estar livres para estourar para definir seus próprios relógios rapidamente).

4. Ou remova qualquer linha referente aos endereços do servidor começando com 127.127.

5. As diretrizes de práticas recomendadas também recomendam mais de três relógios. Portanto, convém escolher alguns outros servidores públicos ou servidores de pool específicos, além dos três servidores do estrato 1.

   Eu também observaria que, se você planeja colocar essas duas VMs no mesmo hardware host, provavelmente deve executar uma, mas duplicar a largura de banda declarada no pool (por exemplo, aceite duas vezes mais consultas do que você faria )

Em primeiro lugar, parabéns por uma pergunta NTP que não seja material de facepalm. :-) Incluímos alguns gráficos na parte inferior deste post para dar uma ideia das coisas. A VM em questão está definida como 100 Mbps no painel de controle do pool e está no Reino Unido, na Europa e em pools globais.

1. Eu acho que o MadHatter cobriu esse bem - a virtualização deve estar bem. Como você diz, se eles estão se alimentando do seu estrato 1s conectado por GPS, eles devem ser razoavelmente sólidos. Na minha experiência, as VMs tendem a ser um pouco mais nervosas do que o bare metal em termos de frequência (veja o gráfico abaixo), mas é o que você esperaria - elas estão lidando com uma camada de emulação de clock (esperançosamente bastante eficiente) e potencialmente barulhenta vizinhos. Se você preferir não ver esse tipo de jumpiness, talvez use servidores mais antigos ou desktops não utilizados como seu estrato 2 da DMZ.

2. Esta VM tem 1 núcleo, 2 GB de RAM, executando o Ubuntu 16.04 LTS, virtualizado no OpenStack (hypervisor KVM). Como você pode ver, a RAM é um pouco exagerada.

3. As configurações recomendadas - incluindo não ter o driver local configurado - são as padrão no Ubuntu 16.04. Estou correndo muito perto da configuração de estoque, além da lista de pares.

4. (Veja acima)

5. Eu provavelmente começaria a largura de banda no lado inferior e aumentaria a largura de banda depois que você a monitorasse um pouco. Se todas as suas VMs estiverem próximas umas das outras e próximas ao estrato 1s em termos de latência de rede, provavelmente eu teria todas as VMs conversando com todos os estratos 1s e provavelmente as associaríamos e ativaria o modo órfão também.

Aqui estão os gráficos - todos eles cobrem o mesmo período de aproximadamente 3 semanas, exceto o da rede, que teve alguns picos devido a backups. Quando os picos de rede estavam lá, eu não conseguia nem ver o tráfego NTP normal, então ampliei um pouco para mostrar o plano de fundo usual.

Offset do sistema de frequência da rede da memória da CPU

Algumas coisas a considerar com o NTP

Já existem muitas boas respostas aqui. Estou apenas adicionando alguns pensamentos por questões de integridade, com base em minhas próprias experiências.

Eu sugeriria a ativação do registro NTP e dos desvios e correções do relógio gráfico no bare metal vs. VM, no que diz respeito a essa discussão, se isso for uma preocupação. Não acredito que isso possa ser generalizado facilmente, pois o hardware e a configuração variam entre as implementações. Talvez seja melhor obter seus próprios números nesse número.

Eu sempre sugeri para as pessoas escolherem funções de sistemas de servidores ou dispositivos de rede que tenham um tempo de CPU bastante constante e que não sejam kernels sem ticks ou que tenham os modos de economia de energia ativados. Evite especialmente os daemons na linha de velocidade, velocidade ou velocidade avançada ou economia de energia avançada nos servidores NTP, mesmo que eles sejam apenas o estrato 2 do seu farm. É possível obter alguma estabilidade nunca mais fundo que o estado C 1, mas o consumo de energia aumentará.

Também tento garantir que as pessoas escolham um punhado de servidores estratos 1 a menos de 40ms da borda da rede, depois os divida pelos servidores NTP de borda e garanta que nenhum servidor atrás do mesmo SNAT da rede esteja falando para o mesmo servidor do estrato 1. Na mesma linha que burst, não é aconselhável ter vários servidores atrás do mesmo SNAT usando os mesmos servidores upstream, pois parecerá que eles ativaram o burst mesmo quando não o fizeram.

Você sempre deve honrar o kodpacote do servidor upstream e ter ferramentas de monitoramento para verificar as compensações de tempo e a acessibilidade dos servidores upstream.

Você pode considerar a possibilidade de ter suas próprias fontes de tempo precisas em alguns de seus datacenters para espiar ou recorrer no caso improvável de o GPS SA ser ativado pelos militares. Existem aparelhos econômicos especificamente para isso. Mesmo se você estiver em um ambiente de "gaiola" e não tiver seu próprio datacenter, algumas instalações de hospedagem podem acomodar isso.

Consulte o documento de cronometragem do vmware em http://www.vmware.com/pdf/vmware_timekeeping.pdf

A execução de um daemon NTP em uma VM provavelmente não é uma boa ideia, principalmente se você precisar de um tempo confiável.

Aqui está um bom KB da VMware com parâmetros de configuração reais para diferentes distribuições do Linux

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427