Single point of failure

Un single point of failure (SPOF) describe la vulnerabilidad de un sistema en forma de un único componente. Si el componente falla, falla todo el sistema. ¿Cuáles son los diferentes tipos de SPOF y cómo puedes minimizar el riesgo de que se produzcan?

Un single point of failure (SPOF) describe un tipo de vulnerabilidad dentro de un sistema. Un SPOF se da cuando el mal funcionamiento de un solo componente provoca el fallo de todo el sistema. Existen varios “failure modes” o modos de fallo. Pueden dividirse en tres categorías:

1. Talón de Aquiles o “eslabón más débil de la cadena”: la caída de un componente provoca una pérdida repentina de la función de todo el sistema.
2. Reacción en cadena o “efecto dominó”: el fallo de un componente provoca el fallo sucesivo de otros componentes que conducen al colapso de todo el sistema.
3. Cuello de botella: un componente actúa como factor limitante del sistema global. Si el componente limitante se ve perjudicado, el rendimiento del sistema se reduce a la capacidad del componente.

Los SPOF son habituales en sistemas complejos con componentes interconectados en múltiples capas. Según la estructura del sistema, el fallo de un componente crítico provoca el fallo de todo el sistema, por lo que hay un single point of failure en forma de un componente crítico.

La complejidad de un sistema de múltiples capas puede dificultar la detección de los SPOF. Sencillamente, no hay una visión de conjunto que permita percibir las interacciones entre los componentes, por lo que es imposible identificar los peligros y tomar medidas al respecto. En principio, cada componente no redundante que sea crítico para el funcionamiento debe ser tratado como un single point of failure.

Tomemos el cuerpo humano como ejemplo. Solo tenemos un corazón o un cerebro: los órganos críticos no están repetidos. Si uno de estos órganos falla, todo el cuerpo falla. El corazón y el cerebro son SPOF. En cambio, los ojos, los oídos, los pulmones y los riñones están duplicados. Si es necesario, el cuerpo compensa el fallo de uno y sigue funcionando con una eficiencia reducida.

En un data center, todos los componentes críticos para el funcionamiento son potenciales SPOF. Por ello, los servidores suelen estar equipados con conexiones redundantes al tendido eléctrico y a la red. El almacenamiento masivo se proporciona de forma redundante mediante RAID o tecnologías similares. El objetivo de esto es garantizar que el sistema siga funcionando en caso de que falle un solo componente crítico.

Hay muchos tipos diferentes de single points of failure (SPOF). Al fin y al cabo, los SPOF no sólo afectan a los sistemas de información. Veamos algunos ejemplos.

En las populares películas de “La Guerra de las Galaxias”, un single point of failure lleva a la destrucción de la temida “Estrella de la Muerte”. Un único torpedo de protones disparado por el protagonista impacta en un punto crítico del reactor. La explosión provoca una catastrófica reacción en cadena que destruye toda la Estrella de la Muerte.

En 2021, el buque portacontenedores “Ever Given” quedó encallado en el Canal de Suez. El barco encalló en un tramo crítico del canal que actúa como vía de agua única. El bloqueo paralizó el tráfico marítimo a lo largo de todo el canal. El single point of failure era la vía de agua no redundante.

En 2018 y 2019 se produjeron dos accidentes de aviones Boeing 737 MAX que causaron la muerte de cientos de personas. El origen de los accidentes fue un único sensor que suministraba datos erróneos. Basándose en los datos del sensor, el sistema de control de vuelo automático no funcionó correctamente y acabó derribando los aviones. Se juntaron varios errores, pero el single point of failure fue el sensor.

Incluso los sistemas diseñados para una alta disponibilidad no están totalmente protegidos de los SPOF. En los últimos años, los principales servicios en la nube han experimentado repetidamente graves fallos. En la mayoría de los casos, el single point of failure era humano. Los datos de configuración erróneos pueden paralizar rápidamente todo un sistema de producción, incluso si sus componentes están diseñados de forma redundante.

Quizá te suene este problema: tu dispositivo está conectado al WiFi, pero el navegador web y el programa de correo se niegan a funcionar. A eso se suman otros errores: desde la configuración automática de la hora hasta la conexión a la cuenta de GitHub a través de SSH. En resumen: problemas por todas partes. Es algo que saca de quicio a cualquiera, pero la respuesta es bastante sencilla:

El eslogan “It’s always DNS” suena divertido, pero se refiere seriamente al posible error de los Domain Name Systems (DNS). Cuando los servidores DNS no responden, las páginas web y los servicios pueden fallar de múltiples maneras. El efecto es similar a perder la conexión a Internet. Sin embargo, en este caso, el tráfico de paquetes entre direcciones IP sigue funcionando.

Los errores de DNS suelen producirse en el lado del usuario si los servidores DNS almacenados en el sistema no son accesibles. Por eso, es buena práctica almacenar siempre dos direcciones de servidores de nombres. Si el primer servidor no está disponible, se utiliza el segundo. Esto crea redundancia y resuelve el single point of failure.

A menudo, ambos servidores DNS son de la misma organización. Si uno de ellos falla, hay una alta probabilidad de que el otro también se vea afectado. Para estar seguro, puedes almacenar las direcciones de dos servidores de nombres de organizaciones diferentes. Una combinación popular es 1.1.1.1 y 9.9.9.9 de Cloudflare y Quad9 como servidores DNS primario y secundario.

A finales de 2021, un gran número de servicios web basados en Java se vieron afectados por la brecha de seguridad Log4Shell. El single point of failure era una biblioteca de registro de Java llamada Log4J. El ataque al sistema llevó en el peor de los casos a la ocupación de todo un sistema vulnerable.

En general, la prevención es la mejor estrategia para evitar los SPOF. Por definición, un single point of failure lleva a la pérdida de funcionamiento de todo el sistema. Una vez que esto ocurre, suele ser demasiado tarde y no queda otra que tratar de limitar los daños.

Por eso las medidas preventivas y la planificación para emergencias son la mejor estrategia. Reproduce escenarios de fallo creíbles y analiza los riesgos y las posibles medidas de protección. Los diferentes tipos de single point of failure pueden evitarse con ciertas funcionalidades del sistema:

Los sistemas críticos bien preparados se someten a una supervisión continua para detectar los errores lo antes posible y corregirlos si es necesario.

Una opción para contrarrestar los SPOF es crear redundancias. Varias instancias de un componente crítico (por ejemplo, la fuente de alimentación, la conexión de red, el servidor DNS) funcionan en paralelo. Si uno falla, el sistema sigue funcionando sin pérdida de rendimiento.

La redundancia también evita muchos SPOF en el ámbito del software. Un ejemplo es un popular microservicio comparado con el monolito de software. Un sistema de microservicios está desacoplado y es menos complejo, lo que lo hace más robusto frente a los SPOF. Como los microservicios se lanzan como contenedores, es más fácil construir redundancias.

¿Pero cómo protege exactamente la redundancia a un sistema? Utilicemos la estimación de la fiabilidad de un sistema mediante la llamada “ley de Lusser” para ilustrarlo. He aquí un ejemplo:

Supongamos que un sistema tiene dos conexiones independientes y paralelas a una fuente de alimentación. Supongamos además que la probabilidad de que la conexión falle en un periodo determinado es del 1%. Entonces, la probabilidad de fallo completo de la conexión de alimentación puede calcularse como el producto de las probabilidades:

1. Probabilidad de fracaso de una instancia:

1% = 1 / 100 = 1 / 10 ^ 2 = 0.01

1. Probabilidad de que dos instancias fallen sucesivamente:

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0.0001

Como puedes ver, la probabilidad de un SPOF no se reduce a la mitad cuando se ejecutan dos instancias, sino que se reduce en dos órdenes de magnitud. Es una mejora considerable. Con tres instancias funcionando en paralelo, un fallo de todo el sistema debería ser casi imposible.

Por desgracia, la redundancia no es la panacea. Más bien, la redundancia protege a un sistema de los SPOF dentro de ciertos supuestos. En primer lugar, la probabilidad de fallo de una instancia debe ser independiente de la probabilidad de fallo de la instancia o instancias redundantes. Este no es el caso cuando un fallo es causado por un evento externo. Si un centro de datos se incendia, los componentes redundantes fallan juntos.

Además de la redundancia de los componentes instalados, la distribución de ciertos componentes es fundamental para mitigar los SPOF. La distribución geográfica del almacenamiento de datos y de la infraestructura informática protege de los desastres ambientales. Además, vale la pena procurar cierta heterogeneidad o diversidad de los componentes críticos del sistema. La diversidad reduce la probabilidad de que fallen las instancias redundantes.

Ilustremos la ventaja de la diversidad con un ejemplo de ciberseguridad. Imagina un centro de datos con equilibradores de carga redundantes del mismo diseño. Un fallo de seguridad en uno de los equilibradores de carga también estará presente en las instancias redundantes. En el peor de los casos, un ataque puede paralizar todas las instancias. Al utilizar modelos diferentes, el sistema global tiene más posibilidades de seguir funcionando con un rendimiento reducido.

La redundancia no siempre es suficiente para evitar los SPOF. Y algunos componentes no pueden diseñarse de forma redundante. Cuando crear redundancia no es una opción, entran en juego otras estrategias.

El enfoque de “defensa en profundidad” es bien conocido en el ámbito de la ciberseguridad. Consiste en trazar múltiples anillos de protección independientes alrededor de un sistema. Estos deben ser vulnerados uno tras otro para provocar el fallo del sistema. La probabilidad de que todo el sistema falle a causa de un solo componente es menor.

En cuanto a los sistemas digitales, existen lenguajes de programación especiales con tolerancia a fallos incorporada. El ejemplo más conocido es el lenguaje “Erlang” desarrollado a finales de los años 80. Junto con el entorno de ejecución asociado, el lenguaje es adecuado para crear sistemas altamente disponibles y tolerantes a fallos.

El triunfo global de la World Wide Web y la difusión del desarrollo web supusieron un nuevo reto. Los programadores se vieron obligados a desarrollar páginas web que funcionaran en diversos dispositivos. El enfoque básico utilizado en este proceso se conoce como “degradación gradual”. Si un navegador o dispositivo no admite una tecnología concreta en una página, esta se renderiza lo mejor posible. Se trata de un enfoque “fail-soft”:

No esperes a que el sistema falle para identificar los single point of failure de tu sistema. Conviene ser proactivo en la Estrategia de Gestión de Riesgos. Suelen utilizar análisis de la ingeniería de la fiabilidad, como el análisis del árbol de fallos o del árbol de sucesos. Los Failure Mode and Effects Analysis (FMEA) se utilizan para identificar las fuentes de fallo más críticas.

El enfoque general para identificar los single point of failure en la infraestructura informática de la empresa consiste en realizar una evaluación de riesgos de las tres dimensiones principales:

• Hardware
• Software/servicios/proveedor
• Personal

En primer lugar, se crea una lista de comprobación del análisis SPOF para mostrar las áreas generales para su posterior análisis. A continuación, se realiza un análisis detallado de los SPOF de cada área:

• Dispositivos no supervisados en la red
• Sistemas de software o hardware no redundantes
• Personal y proveedores que no pueden ser sustituidos en caso de emergencia
• Cualquier dato no incluido en las copias de seguridad

Para cada componente del sistema, se analiza el efecto negativo del fallo. Además, se estima la probabilidad aproximada de un fallo catastrófico. Los resultados se incorporan a un plan global de “recuperación de desastres” para garantizar la seguridad del data center.

Como medida básica para evitar los SPOF, debe garantizarse la redundancia del almacenamiento de datos y la potencia de cálculo en tres niveles:

• A nivel de servidor mediante componentes de hardware redundantes
• A nivel de sistema mediante clustering, es decir, el uso de múltiples servidores
• A nivel de centro de datos, mediante el uso de sitios de operación distribuidos geográficamente.