Após meu comentário inicial, uma resposta um pouco mais longa.
Como regra geral, quando o próprio protocolo, ou as implementações comuns desse protocolo, já suportam nativamente a resiliência, a alta disponibilidade e o failover, você não precisa fornecer esses recursos no nível da infraestrutura.
(Exceto quando você usa casos do exigem que eles ...)
Balanceamento de carga e clusterização são técnicas úteis, mas também requerem manutenção especializada e eu vi muito mais clusters de alta disponibilidade travar de forma catastrófica do que eu vi administradores quebrar dois servidores diferentes ao mesmo tempo.
Com relação ao NTP, você fornece um único servidor NTP para seus clientes ou de maneira otimizada você configura 4 ou mais ...
O Ntpd precisa que a maioria dos servidores concorde com o tempo antes de poder sincronizar.
Se você tiver apenas um servidor , esse servidor será acreditado. Isso tem o benefício de que pelo menos todos os seus sistemas serão configurados para o mesmo (embora talvez um incorreto) tempo e você ainda pode correlacionar eventos de segurança e confiar em protocolos dependentes do tempo como o Kerberos.
Se você tiver dois servidores atrás de um balanceador de carga , seus clientes se comportarão como se houvesse apenas um servidor NTP. Se o tempo nesses dois servidores de backend for diferente (dependendo do algoritmo de balanceamento de carga), metade dos servidores usará uma data completamente diferente dos outros ou você poderá ver saltos aleatórios no tempo quando ocorrer failover.
Se você configurar vários servidores NTP, a maioria (se não todas) as implementações do cliente NTP são capazes (se você configurou servidores suficientes) para distinguir um "falso ticker" e desconsiderá-lo alcançando uma votação majoritária .