chrony vs. systemd-timesyncd: ¿cuáles son las diferencias y los casos de uso como clientes NTP?

De alguna manera, pero no del todo, sobre la base de la pregunta anterior "ntpd vs. systemd-timesyncd - ¿Cómo lograr una sincronización NTP confiable?" , Me gustaría preguntar sobre las diferencias entre chrony y systemd-timesyncd en términos de un cliente NTP .

Sé que systemd-timesyncd es una implementación de cliente ntp más o menos mínima, mientras que chrony es una solución completa de demonio NTP que incluye un cliente NTP.

Las notas de lanzamiento de ubuntu Bionic Beaver establecen lo siguiente:

Por simple necesidad de sincronización de tiempo, el sistema base ya viene con systemd-timesyncd. Chrony solo es necesario para actuar como un servidor de tiempo o si desea que la publicidad sea más precisa y eficiente.

Me gusta la idea de usar una herramienta mínima preinstalada para hacer el trabajo y estoy bastante seguro de que systemd-timesyncd hará el trabajo para mis casos de uso, aún tengo curiosidad:

• ¿Cuáles son las diferencias en el mundo real entre los dos en términos de precisión?
• ¿Cuáles son las diferencias en eficiencia?
• ¿Cuáles son las necesidades de sincronización de tiempo "no simple", también conocidas como casos de uso para crony como cliente NTP?

El anuncio de systemd-timesyncd en el archivo systemd NEWS hace un buen trabajo al explicar las diferencias de esta herramienta en comparación con Chrony y herramientas similares. (énfasis mío):

Se ha agregado un nuevo demonio "systemd-timesyncd" para sincronizar el reloj del sistema a través de la red. Implementa un cliente SNTP . A diferencia de las implementaciones de NTP como chrony o el servidor de referencia NTP, esto solo implementa un lado del cliente y no se molesta con la complejidad completa de NTP, centrándose solo en consultar el tiempo desde un servidor remoto y sincronizar el reloj local . A menos que tenga la intención de servir NTP a clientes en red o desee conectarse a relojes de hardware locales, este simple cliente NTP debería ser más que apropiado para la mayoría de las instalaciones. [...]

Esta configuración es un caso de uso común para la mayoría de los hosts en una flota de servidores. Por lo general, se sincronizarán desde servidores NTP locales, que a su vez se sincronizarán desde múltiples fuentes, posiblemente incluyendo hardware. systemd-timesyncd intenta proporcionar una solución fácil de usar para ese caso de uso común.

Tratando de abordar sus preguntas específicas:

¿Cuáles son las diferencias en el mundo real entre los dos en términos de precisión?

Creo que puede obtener una mayor precisión al obtener datos de sincronización de múltiples fuentes, lo que específicamente no es un caso de uso compatible para systemd-timesyncd. Pero cuando lo usa para obtener datos de sincronización de servidores NTP centrales conectados a su red interna confiable, el uso de múltiples fuentes no es realmente tan relevante y obtiene una buena precisión de una sola fuente.

Si está sincronizando su servidor desde un servidor de confianza en una red local y en el mismo centro de datos , la diferencia de precisión entre NTP y SNTP será prácticamente inexistente. NTP puede tener en cuenta RTT y reducir el tiempo, pero eso no es tan beneficioso cuando su RTT es realmente pequeño, como es el caso de una red local rápida y una máquina cercana. Tampoco necesita múltiples fuentes si puede confiar en la que está utilizando.

¿Cuáles son las diferencias en eficiencia?

Obtener la sincronización de una sola fuente es mucho más simple que obtenerla de múltiples fuentes, ya que no tiene que tomar decisiones sobre qué fuentes son mejores que otras y posiblemente combinar información de múltiples fuentes. Los algoritmos son mucho más simples y requerirán menos carga de CPU para el caso simple.

¿Cuáles son las necesidades de sincronización de tiempo "no simple", también conocidas como casos de uso para crony como cliente NTP?

Eso se aborda en la cita anterior, pero en cualquier caso estos son casos de uso para Chrony que no están cubiertos por systemd-timesyncd:

• ejecutar el servidor NTP (para que otros hosts puedan usar este host como fuente para la sincronización);
• obtener información de sincronización NTP de múltiples fuentes (lo cual es importante para que los hosts obtengan esa información de servidores públicos en Internet); y
• obtener información de sincronización del reloj local, que generalmente involucra hardware especializado como dispositivos GPS que pueden obtener información precisa de la hora de los satélites.

Estos casos de uso requieren Chrony o ntpd o similar.

Como la otra respuesta dice correctamente, chronyimplementa NTP y systemd-timesyncdSNTP.

Desde el punto de vista de un cliente de servicio horario:

SNTP es un protocolo mucho más simple de implementar;
NTP permite incrementos / correcciones paso a paso a tiempo. Una ventaja importante de NTP es que también tiene en cuenta el RTT de la respuesta para obtener un tiempo más exacto.

Desde https://www.meinbergglobal.com/english/faq/faq_37.htm

Si bien un servidor o cliente NTP con todas las funciones alcanza un nivel muy alto de precisión y evita los pasos de tiempo abruptos tanto como sea posible mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP solo se puede recomendar para aplicaciones simples, donde los requisitos para La precisión y la fiabilidad no son demasiado exigentes. Al ignorar los valores de deriva y utilizar formas simplificadas de los métodos de ajuste del reloj del sistema (a menudo pasos simples de tiempo), SNTP solo logra una sincronización de tiempo de baja calidad en comparación con una implementación completa de NTP.

SNTP adopta un enfoque mucho más simple. Se eliminan muchas de las complejidades del algoritmo NTP. En lugar de sesgar el tiempo, muchos clientes SNTP pasan el tiempo. Esto está bien para muchas aplicaciones donde se requiere una simple marca de tiempo. Además, SNTP carece de la capacidad de monitorear y filtrar múltiples servidores NTP. A menudo se usa un enfoque simple de round-robin, donde si un servidor falla, se usa el siguiente en una lista

Desde https://www.masterclock.com/company/masterclock-inc-blog/ntp-vs-sntp

NTP es mucho más preciso y preciso que SNTP, y esto lo convierte en el ganador de facto en la mayoría de las aplicaciones empresariales. Por otro lado, la simplicidad de SNTP lo hace más apropiado para cosas como cámaras IP, DVR y algunos conmutadores de red. Estos tipos de hardware carecen de los recursos de procesamiento para manejar protocolos más complejos, pero a medida que los dispositivos conectados se vuelven cada vez más potentes, eso puede cambiar.

Un punto débil importante de SNTP es que no puede hacerlo más preciso recuperando el tiempo de múltiples fuentes, como lo hace el Protocolo de tiempo de red de forma predeterminada.

Otro punto importante que puedo ver es que las implementaciones de SNTP causan más problemas que NTP en la virtualización, cuando el hipervisor y el demonio NTP intentan cambiar el tiempo de VM. Especialmente con ellos no estar de acuerdo a tiempo con alguna configuración incorrecta hace que ambos estén activos, puede causar grandes problemas. (Si bien los administradores de sistemas competentes solo mantendrán activo un método para la sincronización con el tiempo, puede suceder que ambos estén activos por un error de configuración).

PS systemd-timesyncdno debe ser una alternativa recomendada cuando no se usa systemd.

chronyno es una forma de bifurcación, ntpdpero se implementa desde cero. Implementa los modos cliente y servidor del protocolo NTPv4 completo ( RFC5905 ). En los usuarios de nivel empresarial, estamos viendo una tendencia a cambiar de Red Hat tradicional ntpda chronyRed Hat (RHEL 7 en adelante) y SuSE (de SLES 15).

systemd-timesyncdsolo implemente el modo cliente del protocolo SNTP ( RFC4330 ) . Por lo tanto, los casos de uso complejos no están cubiertos por . Por ejemplo, SNTP no puede hacerlo más preciso al recuperar el tiempo de múltiples fuentes como lo hace NTP de manera predeterminada. Como resultado , no puede proporcionar el tiempo de alta precisión como .systemd-timesyncdsystemd-timesyncdchrony