Compare NTPD e ntpdate

22

Quais são os prós e contras entre essas duas maneiras de sincronizar seu servidor?

Parece-me que o seu servidor provavelmente não se movimentaria mais do que 1 segundo todos os dias, portanto, o ntpdate em um crontab estaria ok. Mas ouvi dizer que você poderia usar servidores NTP redundantes aqui

link

para manter o tempo sincronizado em caso de falha.

Você tem alguma sugestão?

    
por Unknown 01.06.2009 / 02:39

10 respostas

26

O algoritmo NTP inclui informações para permitir calcular e corrigir o desvio no relógio do seu servidor. O NTPD inclui a capacidade de usar isso para manter seu relógio sincronizado e será executado com mais precisão do que um relógio em um computador que não esteja executando o NTPD. O NTPD também usará vários servidores para melhorar a precisão.

O ntpdate não mantém nenhum estado para executar este serviço, portanto, não fornecerá o mesmo tipo de precisão. Ele permitirá que você forneça uma lista de servidores que ele usará para tentar fornecer um resultado melhor, mas isso não substitui os sofisticados algoritmos fornecidos no NTPD que rastreiam seu desvio de cada um dos servidores ao longo do tempo. / p>

O NTPDATE corrige a hora do sistema instantaneamente, o que pode causar problemas com algum software (por exemplo, destruir uma sessão que agora parece antiga). NTPD intencionalmente corrige o tempo do sistema lentamente, evitando esse problema. Você pode adicionar a opção -g ao iniciar o NTPD para permitir que o NTPD faça a primeira atualização uma grande, o que é mais ou menos equivalente a executar o ntpdate uma vez antes de iniciar o NTPD, que de uma só vez era prática recomendada.

Quanto a preocupações com segurança, os servidores ntp não se conectam de volta a conexões não iniciadas, o que significa que seu firewall deve saber que você iniciou a solicitação ntp e permite o tráfego de retorno. Não deve haver necessidade de deixar as portas abertas para conexões arbitrárias para que o NTPD funcione.

Na página do manual ntpdate (8):

ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon ntpd. It is also possible to run ntpdate from a cron script. However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.

    
por 01.06.2009 / 04:21
8

O ntpd é preferido em relação ao ntpdate porque você obtém correção de tempo suave em vez de pular no seu relógio. Que sentido você faz dos seus logs quando há um tempo para trás? O ntpdate também alternará de maneira transparente entre os servidores, conforme necessário.

Quanto a exigir portas abertas (como mencionado por Kyle), versões mais novas do ntpd (por exemplo, 4.2.4 no meu servidor Debian) podem ser configuradas para broadcast / multicast para a LAN, com autenticação criptográfica.

Editar: veja também esta pergunta .

    
por 01.06.2009 / 04:22
5

Geralmente, recomendo que você execute o NTPD e sincronize seus servidores com um servidor de horário designado em sua organização. Esse servidor interno normalmente estará sincronizando com um dos servidores NTP públicos (conforme você está vinculado).

Eu usei o método ntpdate sem nenhum problema, mas parece mais trabalhoso do que executar um verdadeiro daemon ntpd.

    
por 01.06.2009 / 02:46
3

Eu já ouvi falar de problemas com o clock skew em máquinas virtuais que executam o ntpd. Também ouvi falar de pessoas corrigindo esse problema executando tarefas cron regulares que chamam o ntpdate em vários servidores do pool. Eu não tive esses problemas, mas já ouvi falar deles várias vezes.

    
por 01.06.2009 / 03:03
3

Como mencionado em outra parte, o NTP fornece uma correção de tempo suave. Se os aplicativos em seu servidor não se importarem em ter segundos inteiros perdidos, ou fazendo os mesmos segundos novamente, então o ntpd não irá te render muito mais do que o ntpdate.

Se, por outro lado, você tiver aplicativos sensíveis ao tempo que são sensíveis a segundos, ou pior ainda, são sensíveis a segundos parciais, então o ntpd é de longe a melhor escolha. Atualizações do registro de data e hora do Novell eDirectory para o tratamento de colisão de atualização, que se torna crítico se as atualizações forem muito rápidas (como durante a corrida de login matinal). Um servidor syslog precisa ter um tempo preciso de pelo menos meio segundo para manter os registros sadios.

Para minha caixa MythTV em casa, percebo quando faltam alguns segundos para o provedor de TV a cabo considerar o tempo, por isso uso o NTP nisso. Para o servidor de monitor UPS no trabalho eu uso ntpdate crontabbed pelas mesmas razões que Kyle Hodgson apontou, como é um host bastion eu não quero que a porta seja aberta mesmo que eu tenha bloqueado o aplicativo; para essa aplicação, ser um segundo fora da verdade não é terrível.

Quanto à redundância, mantemos pelo menos dois hosts de tempo em nossa rede e apontamos todos os nossos hosts internos para esses dois. Estes dois, em seguida, rastreiam diferentes hosts NTP da Internet. Além do mais, eles são configurados em um arranjo de pares para que eles possam manter o tempo entre si de forma consensual se o nosso link de internet cair. O NTP robusto é definitivamente possível de projetar.

    
por 13.06.2009 / 06:23
1

Em um servidor onde o acesso e o endurecimento são críticos, usei o raciocínio de que o xntpd, a versão do ntpd em que eu estava confiando, exigia uma porta UDP aberta 123. Como eu preferia ter apenas o tcp 22 e 80 aberto, Eu usei o ntpdate em um crontab. Eu nunca ouvi uma boa razão para isso, ou que eu me lembre.

Uma das desvantagens de usar uma chamada ntpdate crontab'ed é que ela não pode lidar com a correção de desvio com elegância. O ntpdate, iirc, atualiza o relógio assim que ele percebe que você está desatualizado - os daemons ntp geralmente corrigem o desvio com cuidado. Isso tem o benefício de manter seus registros sadios - você pode imaginar, em um servidor da Web ocupado, por exemplo, que se o RTC tivesse se desviado alguns minutos, a leitura dos registros da Web no dia seguinte poderia inferir que as pessoas conseguiram atingir URLs antes de se conectarem, já que os hits da Web estariam fora de ordem.

    
por 01.06.2009 / 02:59
1

O ntpdate é destinado a atualizações pontuais, se você quiser que o tempo seja regularmente sincronizado, então use o serviço para esse fim, ntpd.

Não há nenhuma razão convincente para não usar o ntpd, tanto quanto eu posso dizer

    
por 01.06.2009 / 04:04
0

Você não precisa usar o crontab, é para isso que o ntpd serve.

Inicialmente, quando o tempo é muito curto, uma maneira é simplesmente parar o ntpd, depois executar ntpdate ntp.server.com para sincronizá-lo e, em seguida, iniciar o ntp novamente.

Se você tiver uma rede grande, provavelmente configurarei um par de servidores ntp locais e obterá todos os hosts para usá-los.

    
por 01.06.2009 / 02:50
0

Veja esta discussão para entender por que "ntpdate" ainda é desejado e usado.

Para resumir: o ntpd é lento em comparação ao fazer um ajuste de tempo massivo, mesmo com a opção -g.

    
por 19.10.2009 / 21:41
-3

Para uso doméstico, o ntpdate não é nada realmente importante. Há uma razão que é "mais lenta". Qualquer um que use um cron com o ntpdate em um ambiente de PRODUÇÃO ENTERPRISE é apenas um idiota.

    
por 14.07.2011 / 17:40