Single point of failure

Un single point of failure (SPOF) describe la vu­l­ne­ra­bi­li­dad de un sistema en forma de un único co­m­po­ne­n­te. Si el co­m­po­ne­n­te falla, falla todo el sistema. ¿Cuáles son los di­fe­re­n­tes tipos de SPOF y cómo puedes minimizar el riesgo de que se produzcan?

Un single point of failure (SPOF) describe un tipo de vu­l­ne­ra­bi­li­dad dentro de un sistema. Un SPOF se da cuando el mal fu­n­cio­na­mie­n­to de un solo co­m­po­ne­n­te provoca el fallo de todo el sistema. Existen varios “failure modes” o modos de fallo. Pueden dividirse en tres ca­te­go­rías:

1. Talón de Aquiles o “eslabón más débil de la cadena”: la caída de un co­m­po­ne­n­te 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 co­m­po­ne­n­te provoca el fallo sucesivo de otros co­m­po­ne­n­tes que conducen al colapso de todo el sistema.
3. Cuello de botella: un co­m­po­ne­n­te actúa como factor limitante del sistema global. Si el co­m­po­ne­n­te limitante se ve pe­r­ju­di­ca­do, el re­n­di­mie­n­to del sistema se reduce a la capacidad del co­m­po­ne­n­te.

Los SPOF son ha­bi­tua­les en sistemas complejos con co­m­po­ne­n­tes in­te­r­co­ne­c­ta­dos en múltiples capas. Según la es­tru­c­tu­ra del sistema, el fallo de un co­m­po­ne­n­te crítico provoca el fallo de todo el sistema, por lo que hay un single point of failure en forma de un co­m­po­ne­n­te crítico.

La co­m­ple­ji­dad de un sistema de múltiples capas puede di­fi­cu­l­tar la detección de los SPOF. Se­n­ci­lla­me­n­te, no hay una visión de conjunto que permita percibir las in­ter­ac­cio­nes entre los co­m­po­ne­n­tes, por lo que es imposible ide­n­ti­fi­car los peligros y tomar medidas al respecto. En principio, cada co­m­po­ne­n­te no re­du­n­da­n­te que sea crítico para el fu­n­cio­na­mie­n­to 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 du­pli­ca­dos. Si es necesario, el cuerpo compensa el fallo de uno y sigue fu­n­cio­na­n­do con una efi­cie­n­cia reducida.

En un data center, todos los co­m­po­ne­n­tes críticos para el fu­n­cio­na­mie­n­to son po­te­n­cia­les SPOF. Por ello, los se­r­vi­do­res suelen estar equipados con co­ne­xio­nes re­du­n­da­n­tes al tendido eléctrico y a la red. El al­ma­ce­na­mie­n­to masivo se pro­po­r­cio­na de forma re­du­n­da­n­te mediante RAID o te­c­no­lo­gías similares. El objetivo de esto es ga­ra­n­ti­zar que el sistema siga fu­n­cio­na­n­do en caso de que falle un solo co­m­po­ne­n­te crítico.

Hay muchos tipos di­fe­re­n­tes de single points of failure (SPOF). Al fin y al cabo, los SPOF no sólo afectan a los sistemas de in­fo­r­ma­ción. Veamos algunos ejemplos.

En las populares películas de “La Guerra de las Galaxias”, un single point of failure lleva a la de­s­tru­c­ción de la temida “Estrella de la Muerte”. Un único torpedo de protones disparado por el pro­ta­go­ni­s­ta impacta en un punto crítico del reactor. La explosión provoca una ca­ta­s­tró­fi­ca reacción en cadena que destruye toda la Estrella de la Muerte.

En 2021, el buque po­r­ta­co­n­te­ne­do­res “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 re­du­n­da­n­te.

En 2018 y 2019 se pro­du­je­ron dos ac­ci­de­n­tes de aviones Boeing 737 MAX que causaron la muerte de cientos de personas. El origen de los ac­ci­de­n­tes fue un único sensor que su­mi­ni­s­tra­ba datos erróneos. Basándose en los datos del sensor, el sistema de control de vuelo au­to­má­ti­co no funcionó co­rre­c­ta­me­n­te y acabó de­rri­ba­n­do los aviones. Se juntaron varios errores, pero el single point of failure fue el sensor.

Incluso los sistemas diseñados para una alta di­s­po­ni­bi­li­dad no están to­ta­l­me­n­te pro­te­gi­dos de los SPOF. En los últimos años, los pri­n­ci­pa­les servicios en la nube han ex­pe­ri­me­n­ta­do re­pe­ti­da­me­n­te graves fallos. En la mayoría de los casos, el single point of failure era humano. Los datos de co­n­fi­gu­ra­ción erróneos pueden paralizar rá­pi­da­me­n­te todo un sistema de pro­du­c­ción, incluso si sus co­m­po­ne­n­tes están diseñados de forma re­du­n­da­n­te.

Quizá te suene este problema: tu di­s­po­si­ti­vo 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 co­n­fi­gu­ra­ción au­to­má­ti­ca 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 cua­l­quie­ra, pero la respuesta es bastante sencilla:

El eslogan “It’s always DNS” suena divertido, pero se refiere se­ria­me­n­te al posible error de los Domain Name Systems (DNS). Cuando los se­r­vi­do­res 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 di­re­c­cio­nes IP sigue fu­n­cio­na­n­do.

Los errores de DNS suelen pro­du­ci­r­se en el lado del usuario si los se­r­vi­do­res DNS al­ma­ce­na­dos en el sistema no son ac­ce­si­bles. Por eso, es buena práctica almacenar siempre dos di­re­c­cio­nes de se­r­vi­do­res de nombres. Si el primer servidor no está di­s­po­ni­ble, se utiliza el segundo. Esto crea re­du­n­da­n­cia y resuelve el single point of failure.

A menudo, ambos se­r­vi­do­res DNS son de la misma or­ga­ni­za­ción. Si uno de ellos falla, hay una alta pro­ba­bi­li­dad de que el otro también se vea afectado. Para estar seguro, puedes almacenar las di­re­c­cio­nes de dos se­r­vi­do­res de nombres de or­ga­ni­za­cio­nes di­fe­re­n­tes. Una co­m­bi­na­ción popular es 1.1.1.1 y 9.9.9.9 de Clou­d­fla­re y Quad9 como se­r­vi­do­res DNS primario y se­cu­n­da­rio.

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 bi­blio­te­ca 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 vu­l­ne­ra­ble.

En general, la pre­ve­n­ción es la mejor es­tra­te­gia para evitar los SPOF. Por de­fi­ni­ción, un single point of failure lleva a la pérdida de fu­n­cio­na­mie­n­to 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 pre­ve­n­ti­vas y la pla­ni­fi­ca­ción para eme­r­ge­n­cias son la mejor es­tra­te­gia. Reproduce es­ce­na­rios de fallo creíbles y analiza los riesgos y las posibles medidas de pro­te­c­ción. Los di­fe­re­n­tes tipos de single point of failure pueden evitarse con ciertas fu­n­cio­na­li­da­des del sistema:

Los sistemas críticos bien pre­pa­ra­dos se someten a una su­pe­r­vi­sión continua para detectar los errores lo antes posible y co­rre­gi­r­los si es necesario.

Una opción para co­n­tra­rre­s­tar los SPOF es crear re­du­n­da­n­cias. Varias in­s­ta­n­cias de un co­m­po­ne­n­te crítico (por ejemplo, la fuente de ali­me­n­ta­ción, la conexión de red, el servidor DNS) funcionan en paralelo. Si uno falla, el sistema sigue fu­n­cio­na­n­do sin pérdida de re­n­di­mie­n­to.

La re­du­n­da­n­cia también evita muchos SPOF en el ámbito del software. Un ejemplo es un popular mi­cro­se­r­vi­cio comparado con el monolito de software. Un sistema de mi­cro­se­r­vi­cios está des­aco­pla­do y es menos complejo, lo que lo hace más robusto frente a los SPOF. Como los mi­cro­se­r­vi­cios se lanzan como co­n­te­ne­do­res, es más fácil construir re­du­n­da­n­cias.

¿Pero cómo protege exac­ta­me­n­te la re­du­n­da­n­cia a un sistema? Uti­li­ce­mos la es­ti­ma­ción de la fia­bi­li­dad de un sistema mediante la llamada “ley de Lusser” para ilu­s­trar­lo. He aquí un ejemplo:

Su­po­n­ga­mos que un sistema tiene dos co­ne­xio­nes in­de­pe­n­die­n­tes y paralelas a una fuente de ali­me­n­ta­ción. Su­po­n­ga­mos además que la pro­ba­bi­li­dad de que la conexión falle en un periodo de­te­r­mi­na­do es del 1%. Entonces, la pro­ba­bi­li­dad de fallo completo de la conexión de ali­me­n­ta­ción puede ca­l­cu­lar­se como el producto de las pro­ba­bi­li­da­des:

1. Pro­ba­bi­li­dad de fracaso de una instancia:

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

1. Pro­ba­bi­li­dad de que dos in­s­ta­n­cias fallen su­ce­si­va­me­n­te:

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

Como puedes ver, la pro­ba­bi­li­dad de un SPOF no se reduce a la mitad cuando se ejecutan dos in­s­ta­n­cias, sino que se reduce en dos órdenes de magnitud. Es una mejora co­n­si­de­ra­ble. Con tres in­s­ta­n­cias fu­n­cio­na­n­do en paralelo, un fallo de todo el sistema debería ser casi imposible.

Por desgracia, la re­du­n­da­n­cia no es la panacea. Más bien, la re­du­n­da­n­cia protege a un sistema de los SPOF dentro de ciertos supuestos. En primer lugar, la pro­ba­bi­li­dad de fallo de una instancia debe ser in­de­pe­n­die­n­te de la pro­ba­bi­li­dad de fallo de la instancia o in­s­ta­n­cias re­du­n­da­n­tes. Este no es el caso cuando un fallo es causado por un evento externo. Si un centro de datos se incendia, los co­m­po­ne­n­tes re­du­n­da­n­tes fallan juntos.

Además de la re­du­n­da­n­cia de los co­m­po­ne­n­tes in­s­ta­la­dos, la di­s­tri­bu­ción de ciertos co­m­po­ne­n­tes es fu­n­da­me­n­tal para mitigar los SPOF. La di­s­tri­bu­ción geo­grá­fi­ca del al­ma­ce­na­mie­n­to de datos y de la in­frae­s­tru­c­tu­ra in­fo­r­má­ti­ca protege de los desastres am­bie­n­ta­les. Además, vale la pena procurar cierta he­te­ro­ge­nei­dad o di­ve­r­si­dad de los co­m­po­ne­n­tes críticos del sistema. La di­ve­r­si­dad reduce la pro­ba­bi­li­dad de que fallen las in­s­ta­n­cias re­du­n­da­n­tes.

Ilu­s­tre­mos la ventaja de la di­ve­r­si­dad con un ejemplo de ci­be­r­se­gu­ri­dad. Imagina un centro de datos con equi­li­bra­do­res de carga re­du­n­da­n­tes del mismo diseño. Un fallo de seguridad en uno de los equi­li­bra­do­res de carga también estará presente en las in­s­ta­n­cias re­du­n­da­n­tes. En el peor de los casos, un ataque puede paralizar todas las in­s­ta­n­cias. Al utilizar modelos di­fe­re­n­tes, el sistema global tiene más po­si­bi­li­da­des de seguir fu­n­cio­na­n­do con un re­n­di­mie­n­to reducido.

La re­du­n­da­n­cia no siempre es su­fi­cie­n­te para evitar los SPOF. Y algunos co­m­po­ne­n­tes no pueden diseñarse de forma re­du­n­da­n­te. Cuando crear re­du­n­da­n­cia no es una opción, entran en juego otras es­tra­te­gias.

El enfoque de “defensa en pro­fu­n­di­dad” es bien conocido en el ámbito de la ci­be­r­se­gu­ri­dad. Consiste en trazar múltiples anillos de pro­te­c­ción in­de­pe­n­die­n­tes alrededor de un sistema. Estos deben ser vu­l­ne­ra­dos uno tras otro para provocar el fallo del sistema. La pro­ba­bi­li­dad de que todo el sistema falle a causa de un solo co­m­po­ne­n­te es menor.

En cuanto a los sistemas digitales, existen lenguajes de pro­gra­ma­ción es­pe­cia­les con to­le­ra­n­cia a fallos in­co­r­po­ra­da. El ejemplo más conocido es el lenguaje “Erlang” de­sa­rro­lla­do a finales de los años 80. Junto con el entorno de ejecución asociado, el lenguaje es adecuado para crear sistemas altamente di­s­po­ni­bles y to­le­ra­n­tes a fallos.

El triunfo global de la World Wide Web y la difusión del de­sa­rro­llo web su­pu­sie­ron un nuevo reto. Los pro­gra­ma­do­res se vieron obligados a de­sa­rro­llar páginas web que fu­n­cio­na­ran en diversos di­s­po­si­ti­vos. El enfoque básico utilizado en este proceso se conoce como “de­gra­da­ción gradual”. Si un navegador o di­s­po­si­ti­vo no admite una te­c­no­lo­gí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 ide­n­ti­fi­car los single point of failure de tu sistema. Conviene ser proactivo en la Es­tra­te­gia de Gestión de Riesgos. Suelen utilizar análisis de la in­ge­nie­ría de la fia­bi­li­dad, como el análisis del árbol de fallos o del árbol de sucesos. Los Failure Mode and Effects Analysis (FMEA) se utilizan para ide­n­ti­fi­car las fuentes de fallo más críticas.

El enfoque general para ide­n­ti­fi­car los single point of failure en la in­frae­s­tru­c­tu­ra in­fo­r­má­ti­ca de la empresa consiste en realizar una eva­lua­ción de riesgos de las tres di­me­n­sio­nes pri­n­ci­pa­les:

• Hardware
• Software/servicios/proveedor
• Personal

En primer lugar, se crea una lista de co­m­pro­ba­ción del análisis SPOF para mostrar las áreas generales para su posterior análisis. A co­n­ti­nua­ción, se realiza un análisis detallado de los SPOF de cada área:

• Di­s­po­si­ti­vos no su­pe­r­vi­sa­dos en la red
• Sistemas de software o hardware no re­du­n­da­n­tes
• Personal y pro­vee­do­res que no pueden ser su­s­ti­tui­dos en caso de eme­r­ge­n­cia
• Cualquier dato no incluido en las copias de seguridad

Para cada co­m­po­ne­n­te del sistema, se analiza el efecto negativo del fallo. Además, se estima la pro­ba­bi­li­dad apro­xi­ma­da de un fallo ca­ta­s­tró­fi­co. Los re­su­l­ta­dos se in­co­r­po­ran a un plan global de “re­cu­pe­ra­ción de desastres” para ga­ra­n­ti­zar la seguridad del data center.

Como medida básica para evitar los SPOF, debe ga­ra­n­ti­zar­se la re­du­n­da­n­cia del al­ma­ce­na­mie­n­to de datos y la potencia de cálculo en tres niveles:

• A nivel de servidor mediante co­m­po­ne­n­tes de hardware re­du­n­da­n­tes
• A nivel de sistema mediante clu­s­te­ri­ng, es decir, el uso de múltiples se­r­vi­do­res
• A nivel de centro de datos, mediante el uso de sitios de operación di­s­tri­bui­dos geo­grá­fi­ca­me­n­te.