NTP: Como estabelecer uma solução redundante para servidores NTP?

Question

Na infraestrutura da minha empresa, existem 5 data centers em locais remotos.

Em cada local remoto, há dois servidores que contêm serviços DNS e NTP e estão configurados em cada um dos servidores desse local para obter chamadas DNS e NTP desses dois servidores.

Todos os servidores são máquinas do CentOS 6.x.

Há uma motivação para criar redundância entre esses dois servidores em termos de DNS e NTP.

A parte do DNS é coberta e só tenho problemas com o NTP.

Qual é o método correto para garantir que, quando um servidor NTP falhar, o segundo / restante dos servidores continuará a servir os clientes como se nada tivesse acontecido?

Eu pesquisei sobre o Google e encontrei uma solução RedHat para definir um dos servidores como primário (por configurando-o nos clientes como "true"), mas caso o servidor "verdadeiro" (primário) falhe ... ele falhará e os clientes não obterão atualizações NTP dele, portanto, não é uma solução redundante pura. / p>

Eu queria saber se alguém tinha alguma experiência com a configuração de tal solução?

Editar # 1:

Para um teste da resposta de MadHatter, fiz o seguinte:

1. I've stopped NTPd on the server which is configured as "preferred" on each one of the NTP clients.
2. I'm waiting for the NTP client to stop working against this server and start working against it's partner NTPd server.
3. I'm running ntpq -p on the client to see the change. This is the output of ntpq -p:

[root@ams2proxy10 ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.X.X.38      .INIT.          16 u    -  128    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u    2   64  377    0.123    0.104   0.220

O que é "como no ntpq"? qual comando devo correr por favor?

Editar # 2: A saída de como:

[root@ams2proxy10 ~]# ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 64638  8011   yes    no  none    reject    mobilize  1
  2 64639  963a   yes   yes  none  sys.peer    sys_peer  3
ntpq>

A saída do pe:

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.X.X.38      .INIT.          16 u    -  512    0    0.000    0.000   0.000
*10.X.X.39      131.211.8.244    2 u   36   64  377    0.147    0.031 18874.7
ntpq>

    

Answer 1

Eu suspeito que isso não seja um problema: o NTP já é resiliente a isso.

Você não tem um servidor NTP "primário" e alguns secundários: você tem um conjunto de servidores configurados. O NTPd decidirá qual é confiável, o que provavelmente oferecerá um bom sinal de tempo, e reavaliará constantemente suas decisões.

Este é o conjunto de ligações do meu servidor de pool NTP no último mês ou mais:

Comovocêpodever,amaiorpartedotempo6(sistemapeer)éocupadopelalinhaverde,ntp0.jonatkins.com,queéumservidordeestrato1aoqualeuligocompermissão(todososoutrosservidoressãostratum2,assim,oNTPdprefereoservidordeestratosuperiorsenenhumoutrofatorseaplicar).

Masvocêpodeverumaquedanessalinhanoiníciodasemana44,eosvaloresnuméricosabaixodaimagemconfirmamque,duranteoperíododográfico,ntp0.jonatkins.comcaiuparaoestado4(outer),enquantolinnaeus.inf.ed.ac.uk,quepassoumuitodoseutemponoestado5(candidato),noentanto,nomáximoem6(sistemapeer).(Aslinhasnãovãoaté4/até6porquesãomédiasde2horasdedadosbrutosde5minutos;presumivelmente,oqueaconteceudurousensivelmentemenosde2horase,portanto,foisuavizado)./p>

Issomostraque,semnenhumacontribuiçãodaminhaparte,aNTPddecidiu,emalgummomento,queseuparusualnãoerasuficientementeconfiáveleescolheuamelhorfontealternativadurantea"interrupção". Assim que seu par preferido passou novamente em seus testes internos de controle de qualidade, ele foi restaurado para o status de mesmo nível.

    

Answer 2

Quatro ou mais pares de NTP fornecem detecção de falsete e redundância de n + 1. Isso também é a recomendação da Red Hat (embora pareça ser apenas conteúdo do assinante agora).

Selecione 4 ou mais fontes da Internet ou use o projeto NTP Pool. Adicione fontes não da Internet, como relógios GPS, se você as tiver. Configure todos os seus servidores NTP para todas essas fontes.

Verifique se os servidores NTP estão espalhados por toda a sua infraestrutura e use o mínimo possível de pontos únicos de falha. Use racks diferentes, distribuição de energia, conectividade de rede e Internet, centros de dados, etc.

Configure todos os hosts "cliente" para usar todos os seus servidores NTP. Configure pelo menos 4 por cliente.

Esta configuração é muito resiliente. Você pode perder qualquer ponto NTP e ainda detectar falsetes, jogando um relógio maluco.