2 votos

Los servidores NTP no se sincronizan en el arranque

Historia: tengo un par de internos startum 1 NTP relojes de los receptores GPS, y 2 servidores NTP que están virtualizados en la parte superior de VMware ESXi que tomar el tiempo desde el S1 relojes y distribuirlo. De lo contrario, esta configuración funciona bastante bien y proporciona un buen tiempo cuando se compara con otros servidores públicos.

Problema: Cuando yo reiniciar las máquinas virtuales, no empezar a sincronizar correctamente, y quedar atrapado en un no sincronizados estado. Abajo está la ntpq -p de salida después de un reinicio.

root@server:~$ ntpq -p
 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.40    .GPS.            1 u   27   64    3    1.533  -258.43 5948.73
 192.168.2.40    .GPS.            1 u   24   64    3    1.118  -258.47 6138.19
 192.168.3.42    .GPS.            1 u   24   64    3    0.709  -258.42 5655.02
 194.100.49.151  194.100.49.134   2 u   22   64    3    8.124  -258.74 7131.65
 gbg1.ntp.se     .PPS.            1 u   26   64    3   21.856  -258.43 4876.90
 ntp2.sptime.se  .PPS.            1 u   23   64    3   19.991  -258.42 7764.97
 ntp1.sptime.se  .PPS.            1 u   27   64    3   20.489  -258.41 8574.46

Si luego de ejecutar servicio de ntp reiniciar me sale esto:

root@server:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.40    .GPS.            1 u    2   64    1    1.517  -258.45   0.065
 192.168.2.40    .GPS.            1 u    1   64    1    1.126  -258.46   0.025
 192.168.3.42    .GPS.            1 u    2   64    1    0.719  -258.42   0.020
 194.100.49.151  194.100.49.134   2 u    5   64    1    8.041  -258.72   0.000
 gbg1.ntp.se     .PPS.            1 u    6   64    1   21.839  -258.41   0.000
 ntp2.sptime.se  .PPS.            1 u    4   64    1   19.968  -258.41   0.000
 ntp1.sptime.se  .PPS.            1 u    3   64    1   20.418  -258.43   0.000

Un segundo más tarde pasos:

root@server:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.40    .STEP.          16 u    2   64    0    0.000    0.000   0.000
 192.168.2.40    .STEP.          16 u    2   64    0    0.000    0.000   0.000
 192.168.3.42    .STEP.          16 u    8   64    0    0.000    0.000   0.000
 194.100.49.151  194.100.49.134   2 u    -   64    1    7.976   -0.261   0.000
 gbg1.ntp.se     .PPS.            1 u    -   64    1   21.840    0.060   0.000
 ntp2.sptime.se  .STEP.          16 u    6   64    0    0.000    0.000   0.000
 ntp1.sptime.se  .STEP.          16 u    6   64    0    0.000    0.000   0.000

Y después de que estamos de vuelta a la normalidad de la operación:

root@server:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.40    .GPS.            1 u    1   64    1    1.474    0.044   0.017
*192.168.2.40    .GPS.            1 u    1   64    1    1.102    0.030   0.005
 192.168.3.42    .GPS.            1 u    1   64    1    0.674    0.049   0.009
 194.100.49.151  194.100.49.134   2 u    8   64    1    7.976   -0.261   0.000
 gbg1.ntp.se     .PPS.            1 u    8   64    1   21.840    0.060   0.000
 ntp2.sptime.se  .PPS.            1 u    6   64    1   19.979    0.059   0.000
 ntp1.sptime.se  .PPS.            1 u    5   64    1   20.440    0.048   0.000

Así que parece que después de reiniciar el reloj del sistema es apagado por un poco, que es lo esperado, pero, ¿por qué ntpd no de pánico, y a pocos pasos del reloj es un poco difícil de entender para mí.

Aquí está mi ntp.conf

tinker panic 0
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 192.168.1.40  iburst
server 192.168.2.40 iburst
server 192.168.3.42 iburst
server time1.mikes.fi
server ntp1.gbg.netnod.se
server ntp2.sptime.se
server ntp1.sptime.se

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

1voto

John Mahowald Puntos 76

ntpd paso predeterminado umbral es de 0.125 s, y el pánico umbral tras el primer paquete es de 1000 s. En otras palabras, de las condiciones de diseño incluye un desplazamiento de saltar por 15 minutos.

Captura el paquete inicial, el paso, y, finalmente, los compañeros de selección. Toma un minuto o dos para establecer, debido a la forma de la NTP algoritmos de trabajo, incluso si se utiliza el iburst opción. Alcance de los 3 indica que sólo dos paquetes fueron recibidos hasta el momento. Esperar más tiempo, si no dejar caer los paquetes NTP.

Si la inicial compensaciones o paso a paso no es aceptable, usted puede esperar hasta que ntpd o el sistema operativo informes sincronizado. Para systemd en Linux, intente dependiendo systemd-time-wait-sync.service.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: