NTP – Sincronização entre o servidor local e remoto

Verificando se o nosso servidor NTP está sincronizando corretamente

Aqui teremos alguns comando para mantermos e termos certeza que nossa configuração está operando como era pretendido. Precisam ler esse tópico com muita atenção, porque é aqui que termos as informações necessárias para diagnosticar problemas de sincronismo entre o nosso servidor local e o remoto.

Índice

• Introdução
• Instalação NTP Server Linux
• Instalação NTP Server Windows
• E suas configurações
• Verificando Sincronização Entre o Servidor Local e o Servidor NTP Remoto
• Configurando NTP Cliente, Linux e Windows
• Considerações

Depois de salvar (gravar) o arquivo, não vamos reiniciar o serviço ainda. Primeiro vamos parar o servidor NTP (caso esteja rodando) e sincronizar o horário do nosso servidor NTP. Para isso usaremos os seguintes comandos:

Parando serviço:

service ntp stop

Sincronizar data e hora dos nossos servidores com os servidores horário atômicos:

ntpdate a.ntp.br

Reiniciando o serviço NTP:

service ntp start

Para verificarmos se os servidores ao qual estamos tentando sincronizar estão fornecendo respostas ao nosso servidor NTP, e se ele está sincronizando o horário corretamente, precisaremos executar o comando de consulta. O resultado é atualizado constantemente nos dois primeiros dias de sincronização, pois as informações de frequência ainda estão sendo atualizadas no arquivo ntp.drift.
Comando de verificação quanto a sincronização:

ntpq -p

O resultado deve variar, mas pode ser como o abaixo:

Remote	refid	st	t	when	poll	reach	delay	offset	jitter
==============================									
a.ntp.br	.INIT.	16	u	-	64	0	0.000	0.000	0.000
ns2.ansp.br	.STEP.	16	u	482	64	0	0.000	0.000	0.001
titan.cais.rnp.	.STEP.	16	u	34m	64	0	0.000	0.000	0.001
b.ntp.br	200.20.186.76	2	u	32	64	1	20.664	-1.971	0.001
c.ntp.br	.STEP.	16		-	64	0	0.000	0.000	0.000

Podemos reparar que os servidores estão marcados como INIT e STEP. Isto acontece, pois nosso servidor é recém configurado e ainda está atualizando as frequências com os servidores NTP de referência. Após alguns minutos a resposta poderá ser como abaixo:

remote	refid	st	t	when	poll	reach	delay	offset	jitter
================									
a.ntp.br	.INIT.	16	u	-	64	0	0.000	0.000	0.000
*ntp.ansp.br	200.192.232.8	3	u	41	64	7	11.962	-65.677	26.804
+titan.cais.rnp.	26.29.7.231	2	u	36	64	7	15.542	-45.002	23.074
+b.ntp.br	200.20.186.76	2	u	38	64	7	17.908	-44.850	22.019
c.ntp.br	.INIT.	16	u	-	64	0	0.000	0.000	0.000

Entendendo a Resposta do NTPq

Após utilizar o comando acima, com certeza queremos saber por que alguns servidores possuem um caracter antes do endereço, chamados de Tally Codes. Os Tally Codes podem variar entre * (asterisco), + (soma), x. Vamos entender qual o significado desses símbolos e qual a função dos itens st, t, when, poll, reach, delay, offset e jitter:

Entendendo os caracteres ou tally codes:

* – system peer, servidor escolhido como principal referência;
+ – candidat, servidor utilizado, porém com menor peso;
x – falsetick, servidor descartado por alguma incoerência verificada na execução do algoritmo de sincronização;
– – outlier, servidor funcional, porém geograficamente distante. A distância pode afetar na sincronização;
. – excess, se existir mais de 10 servidores de referência configurados, então os que não estiverem entre os 10 melhores receberão esta marca;
# – selected, porém não está entre os 6 principais servidores NTP de referência;
– se não houver marcação, então o servidor de referência foi descartado por não estar respondendo.

Verificando as demais informações:

st – o ideal é 1 ou 2, pois o estrato 0 é destinado às fontes dos servidores NTP de referência. 16 significa que não está sincronizado;
when – tempo (em segundos) da última consulta;
poll – tempo (em segundos) entre uma consulta e outra;
reach – transformação em decimal do resultado das últimas consultas. 377 mostra que não houveram falhas;
delay – tempo (em milissegundos) de demora entre consultas;
offset – medidas de deslocamento (em milissegundos), é a diferença de tempo entre nosso servidor NTP e o servidor de referência;
jitter – ou variação, utiliza o offset para informar desvio ou erro do servidor NTP de referência.

Outra maneira de consultar a situação do seu servidor NTP é através do Syslog, para isso utilize o comando abaixo:

tail -f -n 30 /var/log/syslog | grep ntpd

Se está gostando das postagens, se inscreva em nosso site para receber mais materiais de nosso blog, é grátis, você vai ser notificado quando novas postagens forem publicadas, recebendo assim mais conteúdos de qualidades e ainda vai dar aquela força pra nossa comunidade. E não esquece de compartilhar em suas redes sociais os botões estão no final desse página.

No final dessa página temos um campo onde você é bem vindo para deixar seus comentários. Pode ser uma opinião, elogios, críticas ou correções. Pode ficar a vontade para tirar suas dúvidas ou colaborar acrescentando algo que tenhamos deixado passar desapercebido.

Sua visita e feedback é muito importante para o nosso espaço.