¿Servidores NTP locales o públicos?

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?

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

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.

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).

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

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.

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.

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.