Configuración adecuada de NTP para algunos servidores


9

Tengo alrededor de 20 servidores Linux en una red pequeña y necesito sus relojes decentemente cerca uno del otro (por ejemplo, dentro de 20 ms). Comencé con cada uno de ellos sincronizado con europe.pool.ntp.org y el trabajo está hecho.

Ahora tengo dos preguntas:

  1. ¿Soy una carga notable para la piscina? Es decir, ¿hay alguna diferencia notable en el grupo si estoy accediendo desde 20 servidores o desde 2?
  2. Si marca la diferencia, ¿cuál es la configuración / configuración que mantendrá mi subred sincronizada y el grupo bajo carga ligera? Hay pautas para redes enormes ( http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101 ) pero no he encontrado ninguna para redes pequeñas.

1
Por lo general, debe tener uno o dos servidores horarios internos con los que sincronizar su red interna. Sus dos servidores internos pueden tener una peerrelación. Véase, por ejemplo, ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3101
Marki el

Gracias por los comentarios y enlace Marki. Con respecto al enlace, señala que es para "una gran red", que ciertamente no es mi caso. Con respecto a su sugerencia: no creo que un servidor de tiempo interno sea una buena idea (punto único de falla) pero 2 parece una buena idea. ¿Puede explicar qué es una relación entre pares (o proporcionar un enlace)?
ndemou

También debería tener en cuenta que definitivamente no soy un experto en NTP, ni mucho menos :-)
ndemou

No te dolerá si googleas un poco sobre lo que es un compañero. Tenga en cuenta que este sitio no sirve nada en bandeja de plata cuando las personas no realizan ninguna investigación por sí mismas.
Marki

No me malinterpreté, hice mi tarea, pero NTP es uno de estos temas en los que la mayoría de la documentación es demasiado difícil de manejar (este es el ntp.conf, solo úselo) o demasiado profundo (50 páginas de teoría de la operación para leer antes de usted puede comenzar a comprender los hechos básicos).
ndemou

Respuestas:


8
  1. ¿Soy una carga notable para la piscina? Es decir, ¿hay alguna diferencia notable en el grupo si estoy accediendo desde 20 servidores o desde 2?

Dado que el grupo necesita constantemente servidores durante muchos años (ver [1]), diría que aunque 2 o 20 servidores realmente no hacen la diferencia, siempre debe recordar que no está solo. Así que es mejor que piense en decir 1000 administradores, en cuyo caso estamos hablando de 2000 o 20000 servidores y esto hace la diferencia.

  1. Si marca la diferencia, ¿cuál es la configuración / configuración que mantendrá mi subred sincronizada y el grupo bajo carga ligera?

Debe sincronizar dos [2] servidores en su red con el grupo (llamémoslos Servidores NTP primarios ) y luego sincronizar todos los demás servidores con esos dos. Este método también tiene la ventaja de que el tiempo entre todos sus servidores será más similar (en menos de 1 ms). Esto está de acuerdo con las mejores prácticas de IETF .

1) La configuración para los servidores NTP primarios

Reemplace las líneas servery restrictde su ntp [d] .conf con lo siguiente y mantenga el resto en sus valores predeterminados de distribución [3]:

server 10.11.12.1  iburst peer
#      ^^^^^^^^^^^
#      The LAN IP of the _other_ Primary NTP server 
server 0.europe.pool.ntp.org 
server 1.europe.pool.ntp.org 
server 2.europe.pool.ntp.org 
server 3.europe.pool.ntp.org 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

Tenga en cuenta que esta configuración también permite que los hosts de todo Internet consulten su tiempo de host a través de consultas NTP. Use su firewall si no lo desea. En mi ejemplo, 10.11.12.1 y 10.11.12.2 son las IP de los servidores NTP primarios (tienen dos tarjetas de red, una frente a Internet pública y otra a la subred local 10.11.12.x). Cada servidor NTP primario tiene el otro declarado como un igual (el igual básicamente significa servidor y cliente: usted usa el otro host como fuente de tiempo y el otro host también lo usa a usted como fuente de tiempo). Por lo tanto, ajuste la IP en la primera línea para que la configuración de cada servidor NTP primario apunte al otro como un igual. Ver [4] con respecto a mi elección de usar 4 servidores.

2) La configuración para todos los demás servidores

2A) Si tiene dos interfaces de red

Es mejor usar la segunda interfaz para crear una subred local (por ejemplo 10.11.12.0/24) y usarla para consultas NTP. En ese caso, las líneas de restricción pueden ser más ajustadas. Así que de nuevo reemplace las líneas servery restrictde su ntp [d] .conf con lo siguiente y mantenga el resto en sus valores predeterminados de distribución [3]:

restrict -4 default ignore
restrict -6 default ignore
restrict 10.0.0.0 mask 255.0.0.0 kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

2B) Si no tiene dos interfaces de red

Debe usar las siguientes líneas de restricción (y leer la nota sobre el uso de su firewall para bloquear el acceso a sus servidores NTP arriba). Así que de nuevo reemplace las líneas servery restrictde su ntp [d] .conf con lo siguiente y mantenga el resto en sus valores predeterminados de distribución [3]:

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

# Only use our Primary NTP Servers
server 10.11.12.1 iburst
server 10.11.12.2 iburst
#      ^^^^^^^^^^
#      The IPs of your 2 Primary NTP Servers

Notas

[1] De 2006 a 2012 solicitan constantemente más servidores para unirse: la solicitud de 2006 , la de 2009 y la de 2012 . Visite www.pool.ntp.org para obtener actualizaciones sobre el estado actual.

[2] Dos servidores NTP primarios solo se sugieren como una forma simple de tener redundancia sin complicados arreglos de alta disponibilidad. Puede optar por 3 o 4 por otros motivos (lea nuevamente las mejores prácticas de IETF )

[3] En la práctica y sin importar su distribución, lo único que debe incluir en su configuración de ntpd es una línea que defina un directorio para colocar un archivo de deriva y un nombre para él, por ejemplo driftfile /var/lib/ntp/ntp.drift. He probado mi solución en CentOS, Debian y Ubuntu. Supongo que funciona en la mayoría de las otras distribuciones.

[4] He configurado 4 servidores de grupo siguiendo las mejores prácticas . La configuración de más de 4 servidores es técnicamente aceptada, pero aumentará la carga al grupo NTP para obtener una ganancia cuestionable en la disponibilidad, así que no lo haga. En las mejores prácticas veo que "a partir de ntp-4.2.6, la directiva 'pool' generará" suficientes "asociaciones para proporcionar un servicio de tiempo robusto", así que si usa .pool. direcciones como lo hago aquí y ntp> = 4.2.6 el número exacto de líneas de servidor probablemente no importa.

Rant Oh! Odio NTP (excepto que me gusta que funcione). La documentación oficial está llena de información obsoleta y tienen "¿cómo la uso?" información mezclada con detalles científicos sobre las partes internas. Y también odio lo que restrict 127.0.0.1realmente significaallow everything for 127.0.0.1


Historial de actualizaciones.

He eliminado la iburstopción de la configuración de los servidores NTP locales porque su amistad con el grupo es discutible. (ver comentarios). Eliminarlos solo agrega un par de minutos de tiempo de espera a la primera sincronización.


Créditos

Los comentarios y respuestas de los usuarios de SF Marki y Sven proporcionaron un buen punto de partida para esta respuesta. Gracias a ambos.


1
+1 de mi parte Ejecuto un servidor de grupo y no puedo exagerar la exactitud de esta publicación, excepto que iburstes un parámetro molesto para usar en servidores públicos, así que no lo hagas (aunque no es tan molesto como burst). Los administradores de los servidores de grupos de servidores le están haciendo un favor sin saber quién es usted, y sin ninguna recompensa para sí mismos, simplemente para el mejor funcionamiento de Internet. Si usted, trabajando más duro, puede facilitarles la vida, se lo debe a ellos.
MadHatter

Gracias MadHatter Con respecto a iburst, pensé que estaba bien para los servidores típicos "siempre activos". ¿Tiene algún enlace que respalde su consejo de no usar esta opción? (Revisé www.pool.ntp.org/en/use.html y también busqué en Google durante 10 minutos, pero no encontré nada concluyente)
ndemou

Compartiré felizmente mis estadísticas de tráfico; una muestra rápida sugiere que los hosts mal configurados, es decir, los hosts que transmiten con más frecuencia que una vez por minuto, representan aproximadamente el 45% de mis clientes pero son responsables de aproximadamente el 75% del tráfico. Eso será principalmente de servidores que usan burst, pero incluso iburstdice (desde la ntpdpágina de manual) " con esta opción se intercambia una gran cantidad de mensajes para preparar los datos y configurar el reloj en aproximadamente 10 segundos ". Usar iburstdice " configurar mi reloj rápidamente es más importante que mantener baja la carga en su servidor ", y eso es descortés.
MadHatter

Tiene razón sobre la "descarga de mensajes", pero hasta donde puedo entender, esta explosión solo ocurrirá durante el inicio del demonio NTP y (tal vez) si el servidor de la agrupación no se puede alcanzar momentáneamente (es desde la inicial). Aquí hay un resumen de la página NTPd de Arch wiki: "Se recomienda la opción iburst, y envía una ráfaga de paquetes solo si no puede obtener una conexión con el primer intento. La opción de ráfaga siempre hace esto, incluso en el primer intento, y nunca debe usarse sin permiso explícito y puede resultar en una lista negra ".
ndemou 01 de

Tienes razón, eso iburstes mucho menos objetable que burst. Mi punto es que cuando estás usando el recurso de otra persona de forma gratuita, hay un argumento de que debes inclinarte hacia atrás para ser considerado; simplemente no ser activamente desconsiderado puede no considerarse suficiente. Estoy de acuerdo en que se dice que es la mejor práctica, pero esos documentos no tienen en cuenta si los servidores ascendentes a los que está sincronizando son parte de su empresa o no; dictan las mejores prácticas técnicas (que, estoy de acuerdo, es usar iburst) en lugar de las mejores prácticas sociales .
MadHatter

6

El enfoque habitual para esto es usar una configuración escalonada: sincroniza uno o dos servidores en su red con el grupo y luego los usa como su fuente de tiempo local. Estos niveles se llaman estratos en la jerga NTP.

Además, piénselo: si hace esto como lo describió, no se notará realmente, pero si 1000 sitios de su tamaño comienzan esto, terminará con 20k solicitudes en su mayoría innecesarias y, en algún momento, se notará.

Lea http://en.wikipedia.org/wiki/Network_Time_Protocol


Pero considere el punto de vista alternativo: veinte clientes más además de millones de clientes existentes no son casi nada.
200_success

2
Como él dijo, si todos comienzan a pensar de esa manera ...
Marki

¿Pero en qué punto te detienes? Piense en todos los dispositivos de la clase Linksys que se envían preconfigurados para su uso pool.ntp.org. Seguramente el tráfico DNS excede el tráfico NTP. ¿También tiene que almacenar en caché DNS localmente? Es probable que incluso el tráfico DNS sea minúsculo en comparación con el resto del consumo de ancho de banda.
200_success

@ 200_success: No vale la pena debatirlo, pero la mayoría de estos dispositivos de "clase Linksys" realmente almacenan en caché el tráfico DNS localmente, y consultan su DNS ISP, que también se almacena en caché ...
Sven

1
Si Linksys envía dispositivos que se sincronizan con ntp.pool.orgellos, infringen los términos del grupo ; si lo han hecho correctamente al solicitar una zona de proveedor (ver enlace), también se espera que contribuyan al proyecto del grupo en proporción a su carga (nuevamente, vea el enlace).
MadHatter
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.