¿Servidores NTP locales o públicos?

11

Para una red relativamente grande (miles de hosts): ¿cuáles son los argumentos a favor y en contra de ejecutar un servidor (es) NTP administrado localmente (quizás establecido periódicamente a través de algún servidor NTP público) y que todos los demás hosts en la red utilicen que (grupo de) servidores NTP versus tener todos los hosts simplemente usan servidores NTP públicos directamente, digamos a través de ntp.pool.org?

Además de los pros y los contras, ¿cuál es la mejor práctica típica de hoy?

BeeOnRope
fuente
pregunta de tarea? Parece que un administrador de red para una red con miles de hosts ya estaría utilizando NTP.
JamesBarnett
2
La pregunta no es si usar NTP, es si defender tu propio NTP o usar los públicos.
Ian Varley
Hah, ha pasado mucho tiempo desde que hice mi tarea :) No soy personalmente un administrador de red con miles de hosts, pero surgió la pregunta y estoy interesado en las mejores prácticas existentes.
BeeOnRope

Respuestas:

12

La mejor práctica es ejecutar su propio grupo de servidores NTP configurados para sincronizarse desde servidores NTP públicos. En el caso de que su organización perdiera el acceso a Internet, no querría que sus relojes se torcieran. Además, es grosero establecer miles de hosts en servidores públicos cuando podría (y debería) operar un espejo.

Finalmente, si tiene un requisito informático seguro, debe operar sus propios hosts NTP independientes. Necesitaría hardware especial para que estos sistemas funcionen.

EDITAR: Ya que hubo una discusión al respecto, aquí hay algo de hardware:

Cualquier hardware compatible con PPS parece funcionar en un ntpd moderno . Esto incluye algunas unidades de GPS, aunque esto parece ser raro, al menos tan raro como las unidades de GPS seriales en estos días. Sin embargo, hay dispositivos de hardware vendidos explícitamente para esta función, incluido un producto llamado TSync-PCIe. Según el sitio del fabricante:

El TSync-PCIe ofrece varias configuraciones de un paquete de lector / generador de código de tiempo sincronizado que ofrece flexibilidad y fácil integración de temporización precisa en una aplicación informática integrada. Elija entre la sincronización con IRIG (y otros códigos de tiempo similares), GPS (receptores internos o externos) o Protocolo de tiempo preciso (PTP / IEEE-1588v2). - Enlace del sitio: http://i564f.6o.to

ewindisch
fuente
1
+1 por mencionar el reloj de hardware. Hay instrucciones en la red para conectar un Garmin 18 LVC barato a una caja de Linux para hacer su propia fuente Stratum 0.
Chris S
Aunque todas esas instrucciones parecen implicar hacer su propio pirateo de hardware para construir una interfaz.
Phil Hollenback
@Phil, las personas que buscan una fuente barata de estrato 0 de GPS probablemente estén dispuestas a hacer un poco de piratería de hardware. Si quieres algo fácil, desembolsa el dinero como todos los demás.
Chris S
Sí, parece una tarea bastante simple obtener un código de tiempo de un dispositivo GPS, por lo que ingenuamente asumiría que sería una conexión simple.
Phil Hollenback
8

Incluso en una red pequeña, uso un servicio NTP local, que se actualiza desde uno externo. Una razón es puramente histórica, se remonta a cuando la única conexión a Internet era a través de módems de acceso telefónico. La otra es que si el servicio NTP es incorrecto por alguna razón, preferiría que todas las máquinas sigan siendo consistentes, lo que es más probable si todas se actualizan desde una sola fuente.

John Gardeniers
fuente
Esta es la forma de hacerlo en mi humilde opinión. Si bien tener el tiempo 'correcto' es definitivamente algo bueno, en realidad puede ser más importante que los dispositivos en una LAN tengan un tiempo constante entre ellos, incluso si es diferente del tiempo correcto. Cosas como la autenticación Kerberos fallarán si el tiempo no está sincronizado entre los servidores y los clientes, y un tiempo constante podría ser importante para cosas como la supervisión de registros, los registros de CCTV (por ejemplo, la cámara y el PVR agregarán una marca de tiempo), etc.
Rob Moir
7

Práctica recomendada, configure 2 (o más) hosts NTP en su ubicación, instálelos. Haga que se sincronicen con al menos 4 (preferiblemente, hasta 8) servidores externos desde 0.pool.ntp.org a 3.pool.ntp.org. Si usa más de 4, debe ajustar la frecuencia con la que encuestan a los miembros del grupo.

Aquí hay una versión editada de mi ntp.conf:

server 0.us.pool.ntp.org minpoll 8 maxpoll 14
server 1.us.pool.ntp.org minpoll 8 maxpoll 14
server 2.us.pool.ntp.org minpoll 8 maxpoll 14
server 3.us.pool.ntp.org minpoll 8 maxpoll 14

peer ntp2.example.com

driftfile /var/db/drift.ntp
logfile /var/log/ntp.log
logconfig +sysall +syncall

Puede omitir los argumentos minpoll y maxpoll, los agrego para que sea un poco más ligero en esos servidores. Los valores son 2 ^ n segundos, donde n es el argumento; esos valores son más altos que los predeterminados (6 y 10) porque ya sondeo 12 servidores diferentes entre mis tres hosts NTP.

Si le preocupa mucho la precisión, también puede agregar lo siguiente:

server tick.usno.navy.mil prefer minpoll 10 maxpoll 16

Esto sondeará el reloj atómico de la marina. Tenga en cuenta los altos tiempos de sondeo, ya que están bastante cargados y han solicitado que las personas se lo tomen con calma en su servidor (en realidad, un clúster de 3 nodos).

Chris S
fuente
¿Qué sucede con esto si los servidores NTP externos no están sincronizados?
Warren Dew
1. Eso no sucede o al menos no en una escala que importa. 2. Depende de qué es exactamente "fuera de sincronización" y de cuánto. Si un único servidor externo está fuera de servicio, no se utilizará. Las posibilidades de que los 4 salgan por una cantidad loca son astronómicamente pequeñas. Si le preocupa la precisión, use el clúster de servidores de USNO, su baja fluctuación hará que sea preferible.
Chris S
3

Como otros han mencionado, para miles de hosts internos, proporcionar sus propios servidores de tiempo es el camino a seguir. Por razones como (como otras ya mencionadas):

  • estructura: configure la configuración del tiempo como lo desee; con tantas fuentes de estrato como sea posible
  • robustez: configure el sistema ntp para que sea robusto según sea necesario; utilizando fuentes de reloj propias (GPS) y / o fuentes NTP con diferentes rutas
  • cortesía: consideración amable para la organización anfitriona de fuentes de tiempo externas; menos carga para ellos
  • rendimiento: limitar el tráfico de red NTP externo a unos pocos hosts (problema menor)
  • seguridad: limitar el tráfico de red NTP externamente a unos pocos hosts reforzados

En cuanto a las mejores prácticas:

Desde http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm , aquí hay una estructura recomendada para fuentes de NTP solamente.

 1a  1b     1c  1d     1e  1f      outside
. \ / ...... \ / ...... \ / ..............
   2a ---p--- 2b ---p--- 2c        inside
  /|\        /|\        /|\
 / | \      / | \      / | \
3a 3b 3c   3e 3f 3g   3h 3i 3j

Key: 1 = stratum-1, 2 = stratum-2, 3 = stratum-3, p = peer

La información adicional para configurar un servidor NTP es de http://www.pool.ntp.org/join/configuration.html . Ejemplos son:

  • Configurar unos 5 servidores
  • Use el ntpd estándar
  • No use el controlador de reloj LOCAL
  • use fuentes de tiempo NTP que estén geográficamente / en la red más cercana a usted y números de estrato bajos
Lars Nordin
fuente
Tenga en cuenta el comentario después de esa entrada en las preguntas frecuentes de que no es deseable tener servidores stratum 3 dependiendo de un solo servidor stratum 2. Por lo tanto, en lugar de seguir exactamente el diagrama anterior, debería haber líneas desde cada servidor del estrato 3 a cada servidor del estrato 2.
Paul Gear
1

Creo que la mayoría de las redes grandes usan un pequeño grupo de servidores ntp internos dedicados. El tráfico de NTTP es bastante ligero, por lo que probablemente no necesite muchos servidores para servir a una organización grande.

Al igual que con todos los servicios de red, la ventaja de ejecutar sus propios servidores ntp es que obtiene más control y puede tomar más decisiones. Por ejemplo, si pierde la conectividad de red con el mundo exterior, sus máquinas pueden seguir hablando con su servidor ntp interno y no tiene que preocuparse de que todos tengan que volver a conectarse a servidores externos.

Si tiene miles de servidores, también debe considerar ejecutar su propio servidor de tiempo dedicado, por ejemplo, desde un dispositivo gps o mediante un reloj atómico dedicado . No estoy seguro de cuánto cuesta eso en estos días, pero no puede ser costoso en relación con los miles de sistemas que ya está soportando. Entonces tiene un servicio de tiempo preciso completamente independiente de su conexión con el mundo exterior.

Otro punto a considerar es que ejecutar sus propios servidores ntp es más cortés. De esta forma, solo tiene unas pocas máquinas que realizan solicitudes externas en lugar de miles. Estoy seguro de que los administradores de los servidores ntp de acceso público lo apreciarán. Además, reducirá ligeramente el tráfico de su red externa (muy levemente), lo que probablemente sea algo bueno.

Además, si ejecuta sus propios servidores ntp, puede reforzar un poco su firewall, ya que solo unas pocas máquinas se conectan al exterior en el puerto 123 en lugar de muchas máquinas. Eso puede ser útil.

ntp es fácil de configurar y una vez que lo tiene funcionando requiere muy poco mantenimiento. Todas las empresas con las que he estado involucrado han configurado sus propios servidores ntp y eso ha funcionado bien.

Phil Hollenback
fuente
0

La mejor práctica en ese caso sería ejecutar su propio servidor NTP, o un grupo según sea necesario, y extraer del grupo NTP más cercano geográficamente. Esto reduce la carga que tienen que soportar los servidores NTP de cara al público, pero aún así le dará una gran precisión. Si necesita aún más precisión, puede extraer de los servidores de Stratum 1, pero hacerlo aumenta la carga que debe soportar el grupo, por lo que solo debe hacerlo si está dispuesto a contribuir con un servidor al grupo.

Amanuense
fuente
0

Una buena razón para ejecutar sus propios servidores NTP en una red grande es asegurarse de que todas sus máquinas estén de acuerdo con la hora correcta. Tener muchos sistemas con su propia configuración para servidores de tiempo externos (o todos con diferentes miembros de pool.ntp.org) puede generar pequeñas diferencias de tiempo en los sistemas, lo que puede generar problemas.

La otra buena razón es que tener su (s) propio (s) servidor (es) NTP significa que la hora sincronizada estará disponible desde unos pocos servidores (¡monitoreados!) Cuando el enlace externo se cae o está saturado de tráfico.

Toda mi opinión como un timegeek.

Koos van den Hout
fuente