Cuando la ausencia de redundancia es más fiable: el mito de la redundancia

El riesgo es un concepto difícil y requiere mucha formación, reflexión y análisis para evaluar adecuadamente escenarios concretos. A menudo, dado que las evaluaciones de riesgo son tan difíciles, sustituimos el análisis de riesgo simplemente añadiendo redundancia básica y dando por sentado que hemos mitigado el riesgo de forma apropiada. Pero muy a menudo este no es el caso. La introducción de complejidad o de modos de fallo adicionales suele acompañar a la incorporación de redundancia, y estas nuevas formas de fallo tienen el potencial de añadir más riesgo del que elimina la redundancia añadida. Los sistemas de almacenamiento son especialmente propensos a estos procesos de decisión, lo cual es desafortunado, ya que pocos sistemas, si es que hay alguno, son tan susceptibles al fallo y tan importantes de proteger.

RAID es un gran ejemplo de cómo la falta de un pensamiento holístico sobre el riesgo puede conducir a una toma de decisiones extraña. Si observamos un escenario no poco común, veremos cómo el objetivo de protegerse contra el fallo de una unidad puede en realidad conducir a un aumento del riesgo, incluso cuando se aplica redundancia adicional. En este escenario compararemos un arreglo de doce unidades formado por doce discos duros SATA de tres terabytes en un solo arreglo. No es raro oír hablar de personas que eligen RAID 5 para este escenario con el fin de obtener “máxima capacidad y rendimiento” a la vez que tienen una “protección adecuada contra fallos.”

La idea aquí es que RAID 5 protege contra la pérdida de una sola unidad, que puede ser reemplazada, y el arreglo se reconstruirá a sí mismo antes de que falle una segunda unidad. Eso es estupendo en teoría, pero los riesgos reales de un arreglo de este tamaño, treinta y seis terabytes de capacidad de unidad, no provienen de fallos de múltiples unidades, como la gente suele sospechar, sino de la incapacidad de reconstruir el arreglo de forma fiable tras el fallo de una sola unidad, o de un fallo del propio arreglo sin que falle ninguna unidad individual. El riesgo de que falle una segunda unidad es bajo, no inexistente, pero bastante bajo. Las unidades de hoy en día son altamente fiables. Una vez que falla una unidad, sí aumenta la probabilidad de que falle una segunda, lo cual está bien documentado, pero no quiero que este riesgo nos desvíe de observar los verdaderos riesgos – el riesgo de una operación de resilvering fallida.

Lo que ocurre y nos asusta durante una operación de resilvering de RAID 5 es que puede producirse un error de lectura irrecuperable (URE). Cuando ocurre, la operación de resilvering se detiene y el arreglo queda en un estado inservible – se pierden todos los datos del arreglo. En las unidades SATA comunes, la tasa de URE es de 10^14, es decir, una vez cada doce terabytes de operaciones de lectura. Eso significa que un arreglo de seis terabytes que se está resilverando tiene aproximadamente un cincuenta por ciento de probabilidad de encontrar un URE y fallar. Un cincuenta por ciento de probabilidad de fallo es increíblemente alto. Imagina que tu coche tuviera un cincuenta por ciento de probabilidad de que se le cayeran las ruedas cada vez que lo condujeras. Así que con un pequeño (según los estándares actuales) arreglo RAID 5 de seis terabytes usando unidades SATA con URE de 10^14, si perdiéramos una sola unidad, solo tenemos un cincuenta por ciento de probabilidad de que el arreglo se recupere, suponiendo que la unidad se reemplace de inmediato. Eso no incluye el riesgo de que falle una segunda unidad, solo el riesgo de un fallo por URE. También supone que la unidad está completamente inactiva, salvo por la operación de resilvering. Si las unidades se están usando intensamente para otras tareas al mismo tiempo, entonces las probabilidades de que ocurra algo malo, ya sea un URE o el fallo de una segunda unidad, comienzan a aumentar drásticamente.

Con un arreglo de doce terabytes, las probabilidades de pérdida total de datos durante una operación de resilvering comienzan a acercarse al cien por cien – lo que significa que RAID 5 no tiene ninguna funcionalidad en ese caso. Siempre hay una posibilidad de supervivencia, pero es muy baja. A seis terabytes, puedes comparar una operación de resilvering con un juego de ruleta rusa con una bala y seis recámaras, y tienes que apretar el gatillo tres veces. ¡Con doce terabytes tienes que apretarlo seis veces! Esas no son buenas probabilidades.

Pero no estamos hablando de un arreglo de doce terabytes. Estamos hablando de un arreglo de treinta y seis terabytes – que suena grande, pero este es un tamaño que alguien podría tener fácilmente hoy en casa, por no hablar de en una empresa. Todos los principales fabricantes de servidores, así como casi todos los proveedores de almacenamiento de bajo costo, fabrican hoy en día sistemas de almacenamiento de menos de 10.000 dólares en este rango de capacidad. Resilverar un arreglo RAID 5 con el fallo de una sola unidad en un arreglo de treinta y seis terabytes es como jugar a la ruleta rusa, una bala, seis recámaras, ¡y apretar el gatillo dieciocho veces! Tus datos no tienen muchas posibilidades. Añade a eso la increíble cantidad de tiempo necesaria para resilverar un arreglo de ese tamaño, y el riesgo de que falle un segundo disco durante esa ventana de resilvering comienza a convertirse en una amenaza bastante significativa. He visto estimaciones de tiempos de resilvering que ascienden a semanas o meses en algunos sistemas. Ese es mucho tiempo para funcionar sin poder perder otra unidad. Cuando hablamos de horas o días, los riesgos son bastante bajos, pero siguen presentes. Cuando hablamos de semanas o meses de abuso continuo, ya que las operaciones de resilvering son extremadamente intensivas para las unidades, las tasas de fallo aumentan drásticamente.

Con un arreglo de este tamaño, podemos asumir efectivamente que la pérdida de una sola unidad significa la pérdida del arreglo completo, dejándonos sin ninguna protección contra fallos de unidad en absoluto. Ahora bien, si observamos una unidad del mismo o mejor rendimiento con la misma o mejor capacidad bajo RAID 0, que tampoco tiene protección contra la pérdida de unidades, solo necesitamos usar once de las mismas unidades de las que necesitábamos doce para nuestro arreglo RAID 5. Lo que esto significa es que, en lugar de doce discos duros, cada uno de los cuales tiene aproximadamente un tres por ciento de probabilidad de fallo anual, solo tenemos once. Eso por sí solo hace que nuestro arreglo RAID 0 sea más fiable, ya que hay menos unidades que puedan fallar. No solo tenemos menos unidades, sino que no hay necesidad de escribir el bloque de paridad ni de saltarse los bloques de paridad al leer, lo que reduce, muy ligeramente, el desgaste mecánico del arreglo RAID 0 para la misma utilización, dándole una muy ligera ventaja adicional de fiabilidad. El arreglo RAID 0 de once unidades será idéntico en capacidad al arreglo RAID 5 de doce unidades, pero tendrá un rendimiento y una latencia ligeramente mejores. Una victoria en todos los sentidos. Además del ahorro de costos de no necesitar una unidad adicional.

Así que lo que vemos aquí es que en arreglos grandes (grandes en capacidad, no en número de husillos), RAID 0 en realidad supera a RAID 5 en ciertos escenarios. Cuando se usan unidades SATA comunes, esto ocurre a capacidades que incluso experimentan los usuarios avanzados en casa y muchas pequeñas empresas. Si pasamos a unidades SATA empresariales o unidades SAS, entonces la cifra de capacidad en la que esto ocurre se vuelve muy alta y no es una preocupación hoy en día, pero lo será en tan solo unos pocos años, cuando las capacidades de las unidades se hagan aún mayores. Pero esto pone de relieve lo peligroso que es RAID 5 en los tamaños que vemos hoy en día. Todos comprenden los increíbles riesgos de RAID 0, pero puede ser difícil poner en perspectiva que los problemas de RAID 5 son tan extremos que en realidad podría ser menos fiable que RAID 0.

Que RAID 5 pueda ser menos fiable que RAID 0 en un arreglo de este tamaño basándose únicamente en las operaciones de resilvering es solo el comienzo. En un arreglo masivo como este, el tiempo de resilvering puede tardar tanto y cobrarse tal peaje sobre las unidades que el fallo de una segunda unidad también comienza a convertirse en un riesgo mensurable. Y además están los riesgos adicionales causados por errores del controlador del arreglo, que pueden utilizar los algoritmos de resilvering para destruir un arreglo entero incluso cuando no se ha producido el fallo de ninguna unidad. Dado que RAID 0 (o RAID 1 o RAID 10) no tienen algoritmos de resilvering, no sufren este riesgo adicional. Estos son riesgos difíciles de cuantificar, pero lo importante es que son riesgos adicionales que se acumulan al usar un sistema más complejo, cuando un sistema más simple, sin la redundancia, era más fiable desde el principio.

Ahora que hemos establecido que RAID 5 puede ser menos fiable que RAID 0, señalaré los peligros obvios de RAID 0. RAID, en general, se usa para mitigar el riesgo de que falle un solo disco duro aislado. Todos tememos que un solo disco simplemente falle y se pierdan todos los datos. RAID 0, al ser una gran franja de unidades sin ninguna forma de redundancia, toma el riesgo de pérdida de datos por el fallo de una sola unidad y lo multiplica a través de un número de unidades, donde el fallo de cualquier unidad provoca la pérdida total de datos de todas las unidades. Así que en nuestro ejemplo de once discos anterior, si cualquiera de los once discos falla, todo se pierde. Es fácil ver dónde esto es dramáticamente más peligroso que simplemente usar una sola unidad, completamente sola.

Lo que intento señalar aquí es que la redundancia no significa fiabilidad. El simple hecho de que algo sea redundante, como RAID 5, no proporciona ninguna garantía de que siempre vaya a ser más fiable que algo que no es redundante.

Mi analogía favorita aquí es observar casas en un tornado. En un escenario construimos una casa de ladrillo y mortero. En el segundo escenario construimos dos casas redundantes, hechas de paja (nuestros constructores son cerdos, aparentemente). Cuando llega el tornado (o el lobo feroz), ¿cuál es más probable que nos deje con una casa en pie? Está claro que una casa de ladrillo y mortero tiene algunas ventajas significativas de fiabilidad sobre las casas de paja redundantes. La redundancia no importó; la fiabilidad fue lo que importó al final.

La redundancia suele ser engañosa porque es fácil de cuantificar pero difícil de cualificar. La redundancia es una cuestión de blanco o negro: ¿Es redundante? Sí o no. Simple. La fiabilidad no es tan simple. La fiabilidad tiene que ver con tasas de fallo y probabilidades. Tiene que ver con estadística y análisis. Como es difícil cuantificar la fiabilidad de forma significativa, especialmente al vender un proyecto a la gente de negocios, la redundancia a menudo se convierte en un sustituto simple de este concepto complejo.

El concepto de usar la redundancia para desviar las preguntas sobre la fiabilidad también termina aplicándose a los subsistemas de formas muy enrevesadas. En lugar de hacer redundante un “sistema”, se ha vuelto común hacer redundante un subsistema altamente fiable y de bajo costo, y tratar la redundancia del subsistema como si se aplicara a todo el sistema. El ejemplo más común de esto son los controladores RAID en los productos SAN. En lugar de tener una SAN redundante (es decir, dos SAN), los fabricantes a menudo hacen redundante ese componente que no suele ser redundante en los servidores normales, y luego llaman a la SAN redundante – refiriéndose a una SAN que contiene redundancia, lo cual no es en absoluto lo mismo.

Una buena analogía aquí sería comparar tener coches redundantes, es decir, dos coches completos y funcionales, con tener un solo coche con una bomba de agua de repuesto en el maletero por si la principal falla. Claramente, una bomba de agua de repuesto no es algo malo. Pero también es una protección trivial contra el fallo del coche en comparación con tener un segundo coche listo para funcionar. En un caso, todo el sistema es redundante, incluido el chasis. En el otro, estamos haciendo redundante un solo componente, altamente fiable, dentro del chasis. Ni siquiera está a la par con tener una rueda de repuesto que, al menos, es un componente del coche con una mayor probabilidad de fallo.

Al igual que el mito de la fiabilidad de RAID 5 y de la fiabilidad de sistema/subsistema, las tecnologías de almacenamiento compartido como las SAN y los NAS a menudo reciben el mismo trato, especialmente en lo que respecta a la virtualización. Existe un escenario común en el que se emprende un proyecto de virtualización y la gente instintivamente entra en pánico porque un solo host de virtualización representa un único punto de fallo donde, si falla, muchos sistemas fallarán todos a la vez.

Usar el término “único punto de fallo” provoca una sensación de pánico y es un excelente medio para dirigir una conversación. Pero un SPOF, como nos gusta llamarlo, aunque es algo que nos gusta eliminar cuando es posible, puede no ser el fin del mundo. Piensa en nuestra casa de ladrillo. Es un SPOF. Nuestras dos casas de paja no lo son. Sin embargo, una sola brisa derriba nuestras soluciones redundantes más rápido que nuestro fiable SPOF. Buscar SPOFs es una excelente manera de encontrar puntos de fragilidad en un sistema, pero no creas que todo SPOF debe hacerse redundante en cada escenario. La mayoría de las empresas encontrarán su mejor valor teniendo muchos SPOFs en funcionamiento. Nuestro verdadero objetivo es la fiabilidad a un costo apropiado; la redundancia, como hemos visto, no es un sustituto de la fiabilidad, es simplemente una herramienta que podemos usar para lograr la fiabilidad.

La teoría que muchas personas siguen al virtualizar es que toman su host de virtualización y dicen “¡Este host es un SPOF, así que necesito tener dos de ellos y usar funciones de Alta Disponibilidad para permitir una conmutación por error transparente!” Esto está impulsado por el principal proveedor de virtualización, que gana su dinero, en primer lugar, vendiendo costosos productos complementarios de Alta Disponibilidad y, en segundo lugar, siendo propiedad de un gran proveedor de almacenamiento – así que vender almacenamiento compartido adicional innecesario o incluso peligroso es una gran victoria monetaria para ellos y podría ser fácilmente la razón por la que han defendido el espacio de la virtualización desde el principio. Los hosts de virtualización redundantes con almacenamiento compartido suenan estupendos, pero pueden estar extremadamente desencaminados por varias razones.

La primera razón es que el SPOF inicial que se elimina, el host de virtualización, es reemplazado por un nuevo SPOF, el almacenamiento compartido. Esto no logra nada. Suponiendo que estamos usando servidores y almacenamiento compartido de calidad comparable, lo único que hemos hecho es mover dónde está el riesgo, no cambiar cuán grande es. La probabilidad de que falle el sistema de almacenamiento es aproximadamente igual a la probabilidad de que fallara el servidor original. Pero además de barajar el SPOF de un lado a otro como en un juego de trileros, también hemos hecho algo mucho, mucho peor – hemos introducido dependencias de fallo encadenadas o en cascada.

En nuestro escenario original teníamos un solo servidor. Si el servidor seguía funcionando, estábamos bien; si fallaba, no lo estábamos. Simple. Ahora tenemos dos hosts de virtualización, un solo servidor de almacenamiento (SAN, NAS, lo que sea) y una red que los conecta entre sí. Ya hemos determinado que el riesgo de que falle el almacenamiento compartido es aproximadamente igual a nuestro riesgo total del sistema en el escenario original. Pero ahora tenemos las dependencias adicionales de la red y de los dos nodos de virtualización frontales. Cada uno de estos componentes es más fiable que el frágil almacenamiento compartido (cualquier cosa con unidades mecánicas va a ser frágil), pero que tengan menor riesgo no es la cuestión; la cuestión es que los riesgos son combinatorios.

Si cualquiera de estos tres componentes (almacenamiento, red o los nodos frontales) falla, entonces todo falla. La solución a esto es hacer redundante el almacenamiento compartido por sí mismo y hacer redundante la red por sí misma. Con suficiente trabajo podemos superar la fragilidad y el riesgo que introdujimos al añadir el almacenamiento compartido, pero el almacenamiento compartido por sí mismo no es una forma de mitigación del riesgo, sino que es un riesgo en sí mismo que debe ser mitigado. La espiral de complejidad comienza, y el costo asociado con poner este nuevo sistema a la par con la fiabilidad del sistema original de un solo servidor puede ser astronómico.

Ahora que tenemos toda esta redundancia, tenemos un riesgo más del que preocuparnos. Gestionar toda esta redundancia, todas estas piezas móviles, requiere mucho más conocimiento, habilidad y preparación que gestionar un sistema simple de un solo servidor. Hemos pasado de una solución simple a una muy compleja. En mi propia experiencia anecdótica, los verdaderos peligros de soluciones como esta no provienen del fallo del hardware, sino del error humano. No solo se ha hecho poco para evitar que el error humano provoque el fallo de este nuevo sistema, sino que hemos añadido innumerables puntos donde una persona podría accidentalmente derribar todo el sistema, con redundancia y todo. Lo he visto de primera mano; he oído las historias de terror. Cuanto más complejo es el sistema, más probable es que una persona rompa todo accidentalmente.

Es fundamental que, como profesionales de TI, demos un paso atrás y observemos los sistemas completos y consideremos la fiabilidad y el riesgo, y pensemos en la redundancia simplemente como una herramienta a utilizar en la búsqueda de la fiabilidad. La redundancia en sí misma no es una panacea. Tampoco lo es la simplicidad. La fiabilidad es un problema complejo de abordar. Evitar los reemplazos simplistas es un primer paso importante para pasar de encubrir los problemas de fiabilidad a afrontarlos y resolverlos.