Então, recentemente me dei conta de que, como tenho 3 relógios GPS em minha rede, poderia, tecnicamente, retribuir um pouco e servir ao resto do mundo. Até agora não vi nenhuma desvantagem com essas ideias, mas tenho as seguintes perguntas;
Posso virtualizar isso? Não vou gastar dinheiro e tempo para instalar hardware para isso, portanto, a virtualização é obrigatória. Como os servidores terão acesso a três fontes stratum 1, não consigo ver como isso pode ser um problema, desde que a configuração do ntpd esteja correta
Que tipo de tráfego um servidor NTP público (parte de pool.ntp.org) normalmente vê? E quais VMs grandes eu preciso para isso? O ntpd não deve consumir muitos recursos, pelo que pude perceber, mas prefiro saber de antemão.
Que aspectos de segurança existem para isso? Estou pensando apenas em instalar o ntpd em duas VMs na DMZ, permitir apenas a entrada de ntp pelo FW e apenas a saída de ntp da DMZ para os servidores ntp internos. Também parece haver algumas configurações ntp recomendadas de acordo com a página do pool NTP, mas elas são suficientes? https://www.ntppool.org/join/configuration.html
Eles recomendam não ter o driver de relógio LOCAL configurado, isso é equivalente a remover a configuração da fonte de tempo LOCAL dos arquivos de configuração?
Mais alguma coisa a considerar?
Em primeiro lugar, bom para você; é uma coisa útil e de espírito público a fazer. Dito isso, e dado o seu esclarecimento de que você está planejando criar uma ou mais VMs DMZ que serão sincronizadas e tornarão disponíveis publicamente o horário de seus três servidores stratum-1 (internos) habilitados para GPS Meinberg:
Editar : A virtualização é discutida na lista de bilhar de tempos em tempos; um recente foi em julho de 2015, que pode ser acompanhado a partir deste e-mail . Pergunte a Bjørn Hansen, o 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 agora, então não acho que alguém vá atirar em você por isso e, como um pôster deixa claro, se seu (s) servidor (es) não for confiável, o sistema de monitoramento de pool simplesmente os removerá do piscina. KVM parece ser a tecnologia de virtualização preferida; Não encontrei ninguém especificamente usando VMWare, então não posso comentar sobre o quão "honesta" é uma virtualização. Talvez o melhor resumo sobre o assunto disse
Este é o número médio diário de clientes distintos por segundo que vejo no meu servidor de pool (que está no Reino Unido, zonas europeias e globais) no ano passado:
Isso impõe quase nenhuma carga de sistema detectável (
ntpdparece usar entre 1% e 2% de uma CPU, na maioria das vezes). Observe que, em algum momento do ano, a carga atingiu um breve pico de quase mil clientes por segundo (Máx.: 849,27); Eu monitoro a carga excessiva e nem todos os alarmes dispararam, então só posso observar que mesmo esse nível de carga não causou problemas, embora brevemente.As configurações recomendadas pelo projeto são práticas recomendadas e funcionam para mim. Eu também
iptablescostumo limitar a taxa de clientes a dois pacotes de entrada em uma janela contínua de dez segundos (é incrível quantos clientes rudes existem por aí, que pensam que devem estar livres para estourar para ajustar seus próprios relógios rapidamente).Ou remova todas as linhas referentes a endereços de servidor começando com
127.127.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 de seus três servidores stratum-1.
Também observei que, se você planeja colocar essas duas VMs no mesmo hardware de host, provavelmente deve executar apenas uma, mas dobrar a largura de banda declarada para o pool (ou seja, aceitar o dobro de consultas do que faria de outra forma ).
Em primeiro lugar, parabéns por uma pergunta do NTP que não é material do facepalm. :-) Incluí alguns gráficos no final deste post para dar uma ideia das coisas. A VM em questão está configurada para 100 Mbps no painel de controle do pool e está no Reino Unido, na Europa e em pools globais.
Acho que o MadHatter cobriu bem isso - a virtualização deve funcionar bem. Como você disse, se eles estão se alimentando de seus stratum 1s conectados ao GPS, eles devem ser razoavelmente sólidos. Na minha experiência, as VMs tendem a ser um pouco mais agitadas 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 relógio (espero que bastante eficiente) e potencialmente ruidosas vizinhos. Se você preferir não ver esse tipo de salto, talvez use servidores mais antigos ou desktops não utilizados como seu DMZ stratum 2s.
Esta VM tem 1 núcleo, 2 GB de RAM, rodando Ubuntu 16.04 LTS, virtualizada em OpenStack (hipervisor KVM). Como você pode ver, a RAM é um pouco exagerada.
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.
(Veja acima)
Eu provavelmente começaria a largura de banda no lado baixo e aumentaria a largura de banda depois que você a monitorasse um pouco. Se suas VMs estiverem todas próximas umas das outras e perto de seu estrato 1 em termos de latência de rede, eu provavelmente teria todas as VMs conversando com todos os estratos 1s e provavelmente as emparelharia 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 normal.
Deslocamento do Sistema de Frequência de Rede de
Memória da CPU
Algumas coisas a considerar com o NTP
Já existem algumas boas respostas aqui. Estou apenas adicionando alguns pensamentos para completar, com base em minhas próprias experiências.
Eu sugeriria habilitar o log NTP e as distorções e correções do clock do gráfico em bare metal vs. VM no que se refere 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. Pode ser melhor obter seus próprios números.
Sempre sugeri às pessoas que escolhessem funções de sistema de servidores ou dispositivos de rede que tivessem tempo de CPU razoavelmente constante e que não fossem kernels sem controle ou que tivessem modos de economia de energia ativados. Evite especialmente daemons line cpuspeed ou reguladores de velocidade ou economia de energia avançada em servidores NTP, mesmo que sejam apenas stratum 2 em seu farm. Alguma estabilidade pode ser obtida nunca indo além do C-State 1, mas seu consumo de energia aumentará.
Eu também tento garantir que as pessoas escolham um punhado de servidores stratum 1 que estão a menos de 40 ms de distância da borda de sua rede e, em seguida, divida-os em seus servidores NTP de borda e garanta que nenhum servidor 2 atrás do mesmo SNAT em sua rede esteja conversando para o mesmo servidor stratum 1. Na mesma linha de
burst, não é aconselhável ter vários servidores atrás do mesmo SNAT usando os mesmos servidores upstream, pois parecerá a eles que você ativou o burst mesmo quando não o fez.Você deve sempre honrar o
kodpacote do servidor upstream e ter ferramentas de monitoramento que verifiquem os deslocamentos de tempo e a acessibilidade dos servidores upstream.Você pode querer considerar ter suas próprias fontes de tempo precisas em alguns de seus datacenters para examinar ou recorrer no caso improvável de o GPS SA ser habilitado pelos militares. Existem aparelhos econômicos específicos para isso. Mesmo se você estiver em um ambiente "gaiola" e não tiver seu próprio datacenter, algumas instalações de hospedagem podem acomodá-lo.
Consulte o documento de cronometragem do VMware em http://www.vmware.com/pdf/vmware_timekeeping.pdf
Executar um daemon NTP em uma VM provavelmente não é uma boa ideia, principalmente se você precisar de 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