• Inicio
  • Recursos
  • Blog
  • Redundancia informática y servidores de tiempo
Redundancia informática y servidores de tiempo

El fallo de un servicio dentro de una red informática es un problema que se debe anticipar y resolver lo antes posible cuando no se ha podido evitar.

Cuando el servicio en cuestión es un elemento fundamental de numerosos otros servicios, como la sincronización horaria mediante un servidor de tiempo que integra el protocolo PTP o NTP, entonces el fallo puede tener consecuencias catastróficas. Afortunadamente, existen varios métodos para protegerse contra los fallos.

Comprender las causas potenciales de los fallos

Antes de llevar a cabo cualquier acción en el hardware o el software, es importante identificar los riesgos, es decir las causas posibles de cada avería. Se deben analizar todos los elementos de la red, desde el hardware (alimentación eléctrica, cables, etc), hasta la configuración de los diferentes elementos de software, las fuentes de tiempo, su ubicación en la arquitectura de la red, etc. Cuanto más extensa y compleja sea la red, mayor será el número de puntos potenciales de fallo. Sin embargo, una red minimalista no es más robusta que una red con numerosas máquinas, puesto que un sólo fallo puede paralizar toda la red.

¿Es la redundancia una solución?

Una vez que se han identificado los fallos potenciales, se pueden evitar al usar un principio de redundancia. Por ejemplo, si falla una fuente de alimentación, no tendrá ninguna repercusión que una segunda tome el relevo hasta que se repare la primera.

Crear una redundancia no significa hacer una réplica exacta. El término debe entenderse como una redundancia de servicio más que como una redundancia exacta de hardware: por ejemplo, es posible tener una segunda fuente de alimentación menos potente para paliar el fallo de la primera, que puede ser respaldada por un inversor y una batería.

Además, el hecho de duplicar cada equipo para protegerse de cualquier fallo no es suficiente. Más allá del hardware, se deben tener en cuenta los medios de comunicación. Al diseñar una arquitectura de red, se deben crear varios caminos entre cada punto de la red, para que los mensajes fluyan siempre sin problemas. El principal objetivo es aumentar la tolerancia a los fallos de la red mediante una buena planificación. De hecho, se tolera más un servicio dañado que una interrupción total.

La redundancia externa

A veces, el fallo se debe a un problema de disponibilidad de un servicio externo al sistema informático de la organización. Los problemas externos incluyen los cortes de electricidad, la indisponibilidad de una nube externa (y de los datos asociados), el fallo de un reloj de referencia (o la degradación de su rendimiento sobre todo en caso de interferencia del GNSS).

En caso de fallo de un reloj de referencia, el impacto es significativo cuando deja de funcionar o empieza a desviar, puesto que la sincronización horaria es útil para todos los servicios de una organización.

Aunque ciertos protocolos son más tolerantes que otros, es importante que todos (NTP, PTP, IRIG, etc.) tengan varios relojes de referencia. El hecho de tener varios relojes de referencia permite compensar eficazmente el fallo de uno de ellos, pero también detectar si ciertos relojes empiezan a desviar sin afectar la red todavía. En los protocolos que lo permiten, es importante sincronizar con varias fuentes de referencia horaria para que el fallo de un equipo no tenga consecuencias más abajo en la red.

¿Es la redundancia una solución?

Anticipar para resistir mejor a los fallos

Gestionar un fallo en la red es más una cuestión de anticipación que de reacción. La perturbación o la interrupción de un servicio siempre tendrá consecuencias, aunque se consiga que vuelva a funcionar muy rápidamente. Con una buena anticipación, es posible hacer que las averías y los fallos sean invisibles para los usuarios. Una buena anticipación permite asegurar la alta disponibilidad de los servicios. Ciertamente, se producirán averías en una red informática. Sin embargo, hace falta reducir al máximo su impacto.

Por tanto, es necesario protegerse contra estos fallos, tanto si proceden del exterior como del interior de la red. Los fallos externos como las averías de los relojes de referencia o los problemas de la red eléctrica sólo pueden anticiparse al utilizar la redundancia. De hecho, en estos casos, la organización no tiene ningún control sobre la reparación del servicio.

Priorizar los servicios críticos

Cuanto más crítico sea el servicio en cuestión, más importante es hacerlo tolerante a los fallos. La sincronización horaria de una red es una tarea en la que se basan numerosas aplicaciones. Por tanto, es imprescindible asegurar su continuidad. Anticipar las averías empieza por planificar una arquitectura que evite los nudos de contención: si todas las rutas de sincronización pasan por un sólo servidor, entonces en caso de avería, ninguna máquina se sincronizará. Entonces, hace falta diseñar una arquitectura con dos servidores de tiempo, que no son físicamente dependientes de las mismas rutas dentro de la red informática.

Mejorar la calidad de servicio (QoS) además de protegerse contra los fallos

Ciertos protocolos de red como PTP resuelven la aparición de averías en la red al usar mecanismos que eligen relojes patrón. Sin embargo, es imposible confiar únicamente en este tipo de mecanismo. Para ofrecer un servicio fiable y altamente disponible, hace falta considerar que cada parte de la red puede y va a fallar. Conviene entonces asegurar que cada fallo individual no interrumpa el servicio. Una vez más, la única manera eficaz de paliar los posibles fallos es utilizar la redundancia de hardware.

La redundancia de hardware presenta otra ventaja: los equipos adicionales no están destinados a permanecer inactivos. Además, se pueden utilizar para reducir la carga de cada equipo en la red, lo que permite aumentar la calidad de servicio y la disponibilidad de los sistemas.

Mejorar la QoS

Para concluir

El hecho de añadir equipos a la red para crear una redundancia la hace más compleja de configurar y de mantener, pero resulta necesario para hacerla tolerante a los fallos. El coste inicial evitará muchos problemas cuando se produzca una avería. Tal como lo dicen los especialistas de la tolerancia a los fallos: antes del fallo es demasiado caro, pero después del fallo, es demasiado tarde.

Experto en gestión del tiempo y presente en más de 140 países, Bodet Time es un líder francés en sincronización horaria y tiempo frecuencia. ¿Necesita asistencia para diseñar una arquitectura de distribución horaria eficaz, segura y altamente disponible?

Contáctenos

Compartir el artículo