"¿Alguien sabe realmente qué hora es? ¿A alguien realmente le importa?"
– Chicago, 1969
Quizás a ese grupo de rock no le importaba qué hora era, pero nuestras computadoras necesitan saber la hora exacta. El cronometraje es muy importante para las redes informáticas. En la banca, los mercados bursátiles y otros negocios financieros, las transacciones deben mantenerse en el orden adecuado, y las secuencias de tiempo exactas son críticas para eso. Para los administradores de sistemas y los profesionales de DevOps, es más fácil seguir el rastro del correo electrónico a través de una serie de servidores o determinar la secuencia exacta de eventos utilizando archivos de registro en hosts dispersos geográficamente cuando se mantienen las horas exactas en las computadoras en cuestión.
Solía trabajar en una organización que recibía más de 20 millones de correos electrónicos por día y tenía cuatro servidores solo para aceptar y hacer un filtro básico en la avalancha de correo electrónico entrante. Desde allí, los correos electrónicos se enviaban a uno de los otros cuatro servidores para realizar evaluaciones antispam más complejas, luego se entregaban a uno de varios servidores adicionales donde los correos electrónicos se colocaban en las bandejas de entrada correctas. En cada capa, los correos electrónicos se enviarían a uno de los servidores del siguiente nivel, seleccionado solo por la aleatoriedad del DNS rotatorio. A veces teníamos que rastrear un nuevo mensaje a través del sistema hasta que pudiéramos determinar dónde se "perdió", según los jefes de pelo puntiagudo. Tuvimos que hacer esto con una regularidad aterradora.
La mayor parte de ese correo electrónico resultó ser spam. Algunas personas se quejaron de que faltaba su [chiste, foto de gato, receta, dicho inspirador u otro correo electrónico extraño] del día y nos pidieron que lo encontráramos. Rechazamos esas oportunidades.
Nuestro correo electrónico y otras búsquedas transaccionales fueron asistidas por entradas de registro con marcas de tiempo que, hoy en día, pueden resolverse hasta el nanosegundo incluso en las computadoras Linux modernas más lentas. En entornos de transacciones de gran volumen, incluso unos pocos microsegundos de diferencia en los relojes del sistema pueden significar clasificar miles de transacciones para encontrar la(s) correcta(s).
La jerarquía del servidor NTP
Las computadoras de todo el mundo utilizan el Protocolo de tiempo de red (NTP) para sincronizar sus tiempos con los relojes de referencia estándar de Internet a través de una jerarquía de servidores NTP. Los servidores primarios están en el estrato 1 y están conectados directamente a varios servicios horarios nacionales en el estrato 0 a través de satélite, radio o incluso módems a través de líneas telefónicas. El servicio horario en el estrato 0 puede ser un reloj atómico, un receptor de radio sintonizado con las señales emitidas por un reloj atómico o un receptor GPS que utilice las señales de reloj de alta precisión emitidas por los satélites GPS.
Para evitar que las solicitudes de hora de los servidores de hora más bajos en la jerarquía (es decir, con un número de estrato más alto) abrumen a los servidores de referencia primarios, hay varios miles de servidores públicos NTP de estrato 2 que están abiertos y disponibles para que cualquiera los use. Muchas organizaciones con una gran cantidad de hosts que necesitan un servidor NTP configurarán sus propios servidores de hora para que solo un host local acceda a los servidores de hora del estrato 2, luego configuran los hosts de red restantes para usar el servidor de hora local que, en mi caso , es un servidor de estrato 3.
Opciones NTP
El demonio NTP original, ntpd , se le ha unido uno más nuevo, chronyd . Ambos mantienen la hora del host local sincronizada con el servidor de hora. Ambos servicios están disponibles y no he visto nada que indique que esto cambiará pronto.
Chrony tiene funciones que lo convierten en la mejor opción para la mayoría de los entornos por las siguientes razones:
-
Chrony puede sincronizar con el servidor horario mucho más rápido que NTP. Esto es bueno para computadoras portátiles o de escritorio que no se ejecutan constantemente.
-
Puede compensar las frecuencias de reloj fluctuantes, como cuando un host hiberna o entra en modo de suspensión, o cuando la velocidad del reloj varía debido a los pasos de frecuencia que reducen la velocidad del reloj cuando las cargas son bajas.
-
Maneja las conexiones de red intermitentes y la saturación del ancho de banda.
-
Se ajusta a los retrasos y la latencia de la red.
-
Después de la sincronización de tiempo inicial, Chrony nunca avanza el reloj. Esto asegura intervalos de tiempo estables y consistentes para los servicios y aplicaciones del sistema.
-
Chrony puede funcionar incluso sin una conexión de red. En este caso, el host o servidor local se puede actualizar manualmente.
Los paquetes NTP y Chrony RPM están disponibles en los repositorios estándar de Fedora. Puede instalar ambos y alternar entre ellos, pero las versiones modernas de Fedora, CentOS y RHEL se han movido de NTP a Chrony como su implementación de cronometraje predeterminada. Descubrí que Chrony funciona bien, proporciona una mejor interfaz para el administrador del sistema, presenta mucha más información y aumenta el control.
Solo para que quede claro, NTP es un protocolo que se implementa con NTP o Chrony. Si desea saber más, lea esta comparación entre NTP y Chrony como implementaciones del protocolo NTP.
Este artículo explica cómo configurar clientes y servidores Chrony en un host Fedora, pero la configuración para las versiones actuales de CentOS y RHEL funciona de la misma manera.
Estructura de Chrony
El demonio Chrony, chronyd , se ejecuta en segundo plano y supervisa la hora y el estado del servidor horario especificado en chrony.conf expediente. Si es necesario ajustar la hora local, chronyd lo hace sin problemas sin el trauma programático que ocurriría si el reloj se reiniciara instantáneamente a una nueva hora.
chronyc de Chrony La herramienta le permite a alguien monitorear el estado actual de Chrony y hacer cambios si es necesario. El cronico La utilidad se puede usar como un comando que acepta subcomandos, o se puede usar como un programa interactivo en modo texto. Este artículo explicará ambos usos.
Configuración del cliente
La configuración del cliente NTP es simple y requiere poca o ninguna intervención. El servidor NTP puede definirse durante la instalación de Linux o puede proporcionarlo el servidor DHCP en el momento del arranque. El /etc/chrony.conf predeterminado (que se muestra a continuación en su totalidad) no requiere intervención para funcionar correctamente como cliente. Para Fedora, Chrony usa el grupo NTP de Fedora, y CentOS y RHEL tienen sus propios grupos de servidores NTP. Como muchas distribuciones basadas en Red Hat, el archivo de configuración está bien comentado.
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *
# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2
# Allow NTP client access from local network.
#allow 192.168.0.0/16
# Serve time even if not synchronized to a time source.
#local stratum 10
# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys
# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC
# Specify directory for log files.
logdir /var/log/chrony
# Select which information is logged.
#log measurements statistics tracking
Veamos el estado actual de NTP en una máquina virtual que uso para las pruebas. El cronico comando, cuando se usa con el seguimiento subcomando, proporciona estadísticas que informan qué tan lejos está el sistema local del servidor de referencia.
[root@studentvm1 ~]# chronyc tracking
Reference ID : 23ABED4D (ec2-35-171-237-77.compute-1.amazonaws.com)
Stratum : 3
Ref time (UTC) : Fri Nov 16 16:21:30 2018
System time : 0.000645622 seconds slow of NTP time
Last offset : -0.000308577 seconds
RMS offset : 0.000786140 seconds
Frequency : 0.147 ppm slow
Residual freq : -0.073 ppm
Skew : 0.062 ppm
Root delay : 0.041452706 seconds
Root dispersion : 0.022665167 seconds
Update interval : 1044.2 seconds
Leap status : Normal
[root@studentvm1 ~]#
El ID de referencia en la primera línea del resultado es el servidor con el que está sincronizado el host; en este caso, un servidor de referencia de estrato 3 con el que el host contactó por última vez a las 16:21:30 de 2018. Las otras líneas se describen en el página de manual de chronyc(1).
Las fuentes El subcomando también es útil porque proporciona información sobre la fuente horaria configurada en chrony.conf .
[root@studentvm1 ~]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 6 377 0 -2613us[-2613us] +/- 63ms
^+ dev.smatwebdesign.com 3 10 377 28m -2961us[-3534us] +/- 113ms
^+ propjet.latt.net 2 10 377 465 -1097us[-1085us] +/- 77ms
^* ec2-35-171-237-77.comput> 2 10 377 83 +2388us[+2395us] +/- 95ms
^+ PBX.cytranet.net 3 10 377 507 -1602us[-1589us] +/- 96ms
[root@studentvm1 ~]#
La primera fuente de la lista es el servidor horario que configuré para mi red personal. Los demás los proporcionó la piscina. Aunque mi servidor NTP no aparece en el archivo de configuración de Chrony anterior, mi servidor DHCP proporciona su dirección IP para el servidor NTP. La columna "S" (Estado de origen) indica con un asterisco (* ) el servidor con el que está sincronizado nuestro host. Esto es consistente con los datos del seguimiento subcomando.
La -v proporciona una buena descripción de los campos en esta salida.
[root@studentvm1 ~]# chronyc sources -v
210 Number of sources = 5
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 192.168.0.51 3 7 377 28 -2156us[-2156us] +/- 63ms
^+ triton.ellipse.net 2 10 377 24 +5716us[+5716us] +/- 62ms
^+ lithium.constant.com 2 10 377 351 -820us[ -820us] +/- 64ms
^* t2.time.bf1.yahoo.com 2 10 377 453 -992us[ -965us] +/- 46ms
^- ntp.idealab.com 2 10 377 799 +3653us[+3674us] +/- 87ms
[root@studentvm1 ~]#
Si quisiera que mi servidor fuera la fuente de tiempo de referencia preferida para este host, agregaría la siguiente línea a /etc/chrony.conf archivo.
server 192.168.0.51 iburst preferPor lo general, coloco esta línea justo encima de la primera declaración del servidor del grupo cerca de la parte superior del archivo. No hay una razón especial para esto, excepto que me gusta mantener juntas las declaraciones del servidor. Funcionaría igual de bien en la parte inferior del archivo, y lo he hecho en varios hosts. Este archivo de configuración no es sensible a la secuencia.
El preferir La opción marca esto como la fuente de referencia preferida. Como tal, este host siempre estará sincronizado con esta fuente de referencia (siempre que esté disponible). También podemos usar el nombre de host completo para un servidor de referencia remoto o solo el nombre de host (sin el nombre de dominio) para una fuente de tiempo de referencia local siempre que la declaración de búsqueda esté configurada en /etc/resolv.conf expediente. Prefiero la dirección IP para garantizar que se pueda acceder a la fuente de tiempo incluso si el DNS no funciona. En la mayoría de los entornos, el nombre del servidor es probablemente la mejor opción, porque NTP seguirá funcionando aunque cambie la dirección IP del servidor.
Si no tiene una fuente de referencia específica con la que desea sincronizar, está bien usar los valores predeterminados.
Configurando un servidor NTP con Chrony
Lo bueno del archivo de configuración de Chrony es que este único archivo configura el host como cliente y como servidor. Para agregar una función de servidor a nuestro host (siempre será un cliente, obteniendo su tiempo de un servidor de referencia), solo necesitamos hacer un par de cambios en la configuración de Chrony, luego configurar el firewall del host para aceptar solicitudes NTP.
Abra el /etc/chrony .conf archivo en su editor de texto favorito y descomente el estrato local 10 línea. Esto permite que el servidor Chrony NTP continúe actuando como si estuviera conectado a un servidor de referencia remoto si falla la conexión a Internet; esto permite que el host siga siendo un servidor NTP para otros hosts en la red local.
Reiniciemos chronyd y realice un seguimiento de cómo funciona el servicio durante unos minutos. Antes de habilitar nuestro host como un servidor NTP, queremos probar un poco.
[root@studentvm1 ~]# systemctl restart chronyd ; watch chronyc trackingLos resultados deberían verse así. El reloj El comando ejecuta el seguimiento de chronyc Comando cada dos segundos para que podamos ver los cambios que ocurren con el tiempo.
Every 2.0s: chronyc tracking studentvm1: Fri Nov 16 20:59:31 2018
Reference ID : C0A80033 (192.168.0.51)
Stratum : 4
Ref time (UTC) : Sat Nov 17 01:58:51 2018
System time : 0.001598277 seconds fast of NTP time
Last offset : +0.001791533 seconds
RMS offset : 0.001791533 seconds
Frequency : 0.546 ppm slow
Residual freq : -0.175 ppm
Skew : 0.168 ppm
Root delay : 0.094823152 seconds
Root dispersion : 0.021242738 seconds
Update interval : 65.0 seconds
Leap status : Normal
Observe que mi servidor NTP, el studentvm1 host, se sincroniza con el host en 192.168.0.51, que es mi servidor NTP de red interna, en el estrato 4. La sincronización directa con las máquinas del grupo de Fedora daría como resultado la sincronización en el estrato 3. Observe también que la cantidad de error disminuye con el tiempo. Eventualmente, debería estabilizarse con una pequeña variación alrededor de un rango de error bastante pequeño. El tamaño del error depende del estrato y otros factores de la red. Después de unos minutos, use Ctrl+C para salir del bucle de vigilancia.
Para convertir nuestro host en un servidor NTP, debemos permitirle escuchar en la red local. Quite el comentario de la siguiente línea para permitir que los hosts de la red local accedan a nuestro servidor NTP.
# Allow NTP client access from local network.
allow 192.168.0.0/16
Tenga en cuenta que el servidor puede escuchar solicitudes en cualquier red local a la que esté conectado. La dirección IP en la línea "permitir" solo tiene fines ilustrativos. Asegúrese de cambiar la red IP y la máscara de subred en esa línea para que coincida con la de su red local.
Reiniciar chronyd .
[root@studentvm1 ~]# systemctl restart chronydPara permitir que otros hosts en su red accedan a este servidor, configure el firewall para permitir paquetes UDP entrantes en el puerto 123. Consulte la documentación de su firewall para saber cómo hacerlo.
Prueba
Su host ahora es un servidor NTP. Puede probarlo con otro host o una VM que tenga acceso a la red en la que escucha el servidor NTP. Configure el cliente para usar el nuevo servidor NTP como servidor preferido en /etc/chrony.conf luego monitoree ese cliente usando el chronyc herramientas que usamos anteriormente.
Chronyc como una herramienta interactiva
Como mencioné anteriormente, chronyc se puede utilizar como una herramienta de comando interactivo. Simplemente ejecute el comando sin un subcomando y obtendrá un chronyc símbolo del sistema.
[root@studentvm1 ~]# chronyc
chrony version 3.4
Copyright (C) 1997-2003, 2007, 2009-2018 Richard P. Curnow and others
chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and
you are welcome to redistribute it under certain conditions. See the
GNU General Public License version 2 for details.
chronyc>
Puede ingresar solo los subcomandos en este aviso. Intenta usar el seguimiento , ntpdata y fuentes comandos El cronico la línea de comandos permite recuperar y editar comandos para chronyc subcomandos. Puede utilizar la ayuda subcomando para obtener una lista de posibles comandos y su sintaxis.
Conclusión
Chrony es una poderosa herramienta para sincronizar los tiempos de los hosts de los clientes, ya sea que estén todos en la red local o dispersos por todo el mundo. Es fácil de configurar porque, a pesar de la gran cantidad de opciones disponibles, solo se requieren unas pocas configuraciones para la mayoría de las circunstancias.
Después de que mis computadoras cliente se hayan sincronizado con el servidor NTP, me gusta configurar el reloj del hardware del sistema desde la hora del sistema (SO) usando el siguiente comando:
/sbin/hwclock --systohcEste comando se puede agregar como un trabajo cron o un script en cron.daily para mantener el reloj del hardware sincronizado con la hora del sistema.
Chrony y NTP (el servicio) usan la misma configuración y los contenidos de los archivos son intercambiables. Las páginas de manual de chronyd, chronyc y chrony.conf contienen una increíble cantidad de información que puede ayudarlo a comenzar o aprender acerca de opciones de configuración esotéricas.
¿Ejecutas tu propio servidor NTP? Háganos saber en los comentarios y asegúrese de decirnos qué implementación está usando, NTP o Chrony.