El Eslabón Más Débil: Cómo las Dependencias Encadenadas Afectan al Riesgo del Sistema

Al evaluar los escenarios de riesgo de un sistema es muy fácil pasar por alto las dependencias “encadenadas”. Estamos entrenados para examinar el riesgo a nivel de “nodo”, preguntándonos “qué probabilidad hay de que esta única cosa falle”. Pero el riesgo de un sistema es mucho más complicado que eso.

En la mayoría de los sistemas hay algunos componentes que dependen de otros componentes. El lugar más habitual donde examinamos esto es en el diseño del almacenamiento para servidores, pero ocurre en cualquier diseño de sistema. Otro buen ejemplo es cómo las aplicaciones web necesitan tanto hosts de aplicaciones como hosts de bases de datos para poder funcionar.

Lo más sencillo es explicar las dependencias encadenadas con un ejemplo. Examinaremos un diseño de virtualización estándar con almacenamiento SAN para entender dónde existen los límites de los dominios de fallo y dónde existen las dependencias encadenadas, y qué papel desempeña la redundancia en la mitigación del riesgo a nivel de sistema.

En un diseño SAN (red de área de almacenamiento) estándar para virtualización se tienen hosts de virtualización (a los que llamaremos los “servidores” para simplificar), switches SAN (switches dedicados a la red de almacenamiento) y las propias cabinas de discos. Cada una de estas tres “capas” depende de las otras para que el sistema, en su conjunto, funcione. Si tuviéramos el conjunto más simple posible, con un servidor, un switch y una cabina de discos, tendríamos muy claramente tres dispositivos que representan tres puntos de fallo distintos. Que cualquiera de los tres falle provoca que todo el sistema falle. Ninguna pieza es útil por sí sola. Esto es una dependencia encadenada y la cadena es solo tan fuerte como su eslabón más débil.

En nuestro ejemplo simplista, cada dispositivo representa un dominio de fallo. Podemos mitigar el riesgo mejorando la fiabilidad de cada dominio. Podemos añadir un segundo servidor e implementar una estrategia de alta disponibilidad o de tolerancia a fallos en la capa de virtualización para reducir el riesgo de fallo del servidor. Esto mejora la fiabilidad de un dominio de fallo, pero deja dos sin tocar y tan arriesgados como estaban antes. A continuación podemos abordar la capa de conmutación añadiendo un switch redundante y configurando una estrategia de múltiples rutas (multi-pathing) para gestionar la pérdida de una única ruta de conmutación, reduciendo el riesgo en esa capa. Ahora se han abordado dos dominios de fallo. Por último, tenemos que abordar el dominio de fallo del almacenamiento, lo que se hace, de forma similar, añadiendo redundancia mediante una segunda cabina de discos que se replica en la primera y es capaz de hacer una conmutación por error (failover) de forma transparente en caso de fallo.

Ahora que hemos reforzado nuestro sistema, seguimos teniendo tres dominios de fallo en una cadena de dependencias. Lo que hemos hecho es que cada “eslabón” de la cadena, cada dominio de fallo, sea más resiliente por sí mismo. Pero la cadena sigue existiendo. Esto significa que el sistema, en su conjunto, es mucho menos fiable de lo que es por sí solo cualquier dominio de fallo individual dentro de la cadena. Hemos creado algo mucho mejor que el punto de partida, pero seguimos teniendo muchos dominios de fallo. Estos riesgos se suman.

Lo difícil a la hora de determinar el riesgo global es que debemos evaluar el riesgo de cada elemento, luego determinar el nuevo riesgo tras la mitigación (mediante la adición de redundancia) y después hallar el riesgo acumulado de cada uno de los dominios de fallo en conjunto dentro de una cadena para determinar el riesgo total de todo el sistema. Es extremadamente difícil determinar el riesgo dentro de cada dominio de fallo, ya que la manera de mitigar el riesgo desempeña un papel importante. Por ejemplo, un clúster de cabinas de discos de almacenamiento que conmute por error con demasiada lentitud puede provocar un fallo general del sistema incluso cuando el propio clúster de almacenamiento parece haber funcionado correctamente. Por tanto, incluso definir con claridad qué es un fallo puede resultar complicado.

A menudo resulta tentador adoptar una evaluación del riesgo “desde arriba”, lo cual es muy peligroso, pero muy común en las personas que no practican la evaluación de riesgos con regularidad. La tendencia aquí es examinar el riesgo viendo únicamente el dominio de fallo “más alto” (por lo general los servidores en un caso como este) e ignorando cualquier riesgo que se sitúe por debajo de ese punto, considerándolo “bajo el capó” en lugar de parte de la evaluación de riesgos. Es fácil ignorar los componentes más técnicos, menos expuestos y peor comprendidos, como la red y el almacenamiento, y centrarse en los aspectos de fiabilidad de la capa superior, relativamente fáciles de entender y muy comercializados. Esta “visión desde arriba” significa que los riesgos situados por debajo del nivel superior quedan ocultos y por lo general se ignoran, lo que conduce a un riesgo elevado sin una buena comprensión de por qué.

Comprender el concepto de las dependencias encadenadas explica por qué los sistemas complejos, incluso con estrategias complejas de mitigación de riesgos, a menudo acaban siendo mucho más frágiles que los sistemas más sencillos. En nuestro ejemplo anterior, podríamos hacer varias cosas para “colapsar” la cadena, dando como resultado un sistema más fiable en su conjunto.

El componente más obvio que puede colapsarse es el dominio de fallo de la red. Si elimináramos los switches por completo y conectáramos el almacenamiento directamente a los servidores (no siempre es posible, claro está), eliminaríamos efectivamente un dominio de fallo entero y quitaríamos un eslabón de nuestra cadena. Ahora, en lugar de tres cadenas, cada una de las cuales tiene cierto potencial de fallo, solo tenemos dos. Más simple es mejor, siendo todo lo demás igual.

En teoría, también podríamos colapsar el dominio de fallo del almacenamiento pasando del almacenamiento externo a usar almacenamiento local en los propios servidores, lo que esencialmente nos llevaría de dos dominios de fallo a un único dominio de fallo; el único dominio restante, por supuesto, carga con más complejidad de la que tenía antes del colapso, pero la complejidad general del sistema se reduce enormemente. De nuevo, esto es con todos los demás factores permaneciendo iguales.

Otro enfoque a considerar es hacer que los nodos individuales sean más fiables por sí mismos. Hoy en día está de moda examinar sistemas más grandes y abordar la mitigación del riesgo de esa manera, añadiendo nodos redundantes de bajo coste para aportar fiabilidad a los dominios de fallo. Pero tradicionalmente esta no era la vía por defecto que se seguía para lograr la fiabilidad. En el pasado era mucho más común, como demuestra la antigua prevalencia de los mainframes y sistemas de clase similar, incorporar altos grados de fiabilidad en un único nodo. Los mainframes y los sistemas de almacenamiento de gama alta, por ejemplo, todavía lo hacen hoy en día. Este puede ser en realidad un enfoque extremadamente eficaz, pero no aborda muchos escenarios y por lo general resulta extremadamente costoso, a menudo agravado por la necesidad de que los sistemas sean mantenidos parcial o incluso completamente por el proveedor. Esto tiende a funcionar solo en circunstancias de nicho especiales y no es práctico a una escala más general.

Así pues, en cualquier sistema de esta naturaleza tenemos tres estrategias clave de mitigación de riesgos a considerar: mejorar la fiabilidad de un único nodo, mejorar la fiabilidad de un único dominio o reducir el número de dominios de fallo (eslabones) en la cadena de dependencias. Combinarlas de forma prudente puede ayudarnos a alcanzar el nivel de mitigación de riesgos adecuado para nuestro escenario empresarial.

Donde reside la verdadera dificultad, y seguirá residiendo, es en la comparación de las distintas estrategias de mitigación de riesgos. El riesgo de un único nodo por lo general puede estimarse con cierto nivel de confianza. Una estrategia de redundancia dentro de un único dominio tiene mucha menos capacidad de ser estimada: algunas estrategias de redundancia son muy eficaces y crean dominios de fallo extremadamente fiables, mientras que otras pueden de hecho resultar contraproducentes y reducir la fiabilidad de un dominio. La complejidad que a menudo conlleva las estrategias de redundancia nunca está exenta de salvedades y, aunque por lo general dará sus frutos, rara vez aporta el grado de beneficio de fiabilidad que se espera inicialmente. Estimar el riesgo de una cadena de dependencias es, por tanto, mucho más difícil, ya que requiere una comprensión clara de los riesgos asociados a cada uno de los dominios de fallo individualmente, así como una comprensión de la posibilidad de fallo existente en los límites entre dominios (como el fallo por retardo en la conmutación por error del almacenamiento señalado anteriormente).

Exploremos las cuestiones en torno a la determinación del riesgo en dos enfoques muy comunes del mismo escenario, partiendo de lo que hemos comentado anteriormente.

Dos ejemplos extremos de la misma situación que hemos venido comentando son un único servidor con almacenamiento interno utilizado para alojar máquinas virtuales frente a una “cadena” de seis dispositivos con dos servidores y utilizando una solución de alta disponibilidad en la capa de servidor, dos switches con redundancia en la capa de conmutación y dos cabinas de discos que proporcionan alta disponibilidad en la capa de almacenamiento. Si modificamos cualquier factor importante aquí, por lo general podemos ofrecer una estimación bastante clara del riesgo relativo: si a alguno de los dominios de fallo le falta una redundancia fiable, por ejemplo, podemos determinar con bastante claridad que el único servidor es el sistema más fiable en su conjunto, salvo en los casos en que se asigne una cantidad extrema de fiabilidad de nodo único a un solo nodo, lo cual por lo general es una estrategia poco práctica desde el punto de vista financiero. Pero con cada dominio de fallo manteniendo redundancia nos vemos obligados a comparar los riesgos relativos de la fiabilidad intradominio (la cadena redundante) frente a la fiabilidad interdominio (la cadena colapsada, el único servidor).

Con los dos enfoques completamente distintos no hay forma razonable de evaluar los riesgos comparativos de los dos medios de mitigación del riesgo. Por lo general se acepta que el enfoque de seis (o más) nodos con una amplia mitigación del riesgo intradominio es el más fiable de los dos enfoques, y esto es casi con total seguridad cierto en general. Pero no siempre es cierto y rara vez este enfoque supera a la estrategia de nodo único por un margen verdaderamente significativo, mientras que suele costar de cuatro a diez veces más que la estrategia de un único servidor. Eso es potencialmente un coste muy alto a cambio de lo que probablemente sea una pequeña ganancia en fiabilidad y un pequeño riesgo potencial de una pérdida de fiabilidad. Cada pieza adicional de redundancia añade una complejidad que un ser humano debe implementar, supervisar y mantener, y con la complejidad y la interacción humana llega cada vez más riesgo. Evitar el error humano a menudo puede ser más importante que evitar el fallo mecánico.

También debemos considerar el coste de la recuperación. Si llega a producirse un fallo, por lo general es trivial recuperarse del fallo de un sistema sencillo. Un sistema extremadamente complejo, una vez que ha fallado, puede requerir un gran esfuerzo para restaurarlo a un estado funcional. Los sistemas complejos también requieren grados de experiencia y de confianza mucho más amplios y profundos para su mantenimiento.

No hay una respuesta sencilla para determinar la fiabilidad de los sistemas. Los sistemas modernos de entrega de información son sencillamente demasiado grandes y demasiado complejos, con demasiados factores indeterminables, como para poder evaluarlos en todos los casos. Con una buena comprensión de las dependencias encadenadas, sin embargo, y una comprensión de las estrategias de mitigación de riesgos, podemos dar pasos prácticos para determinar niveles de riesgo relativos de forma aproximada, ver cómo se comparan en coste escenarios de riesgo similares, identificar puntos de fragilidad, reconocer dominios de fallo y cadenas de dependencias, y apreciar cómo los cambios en el diseño del sistema nos acercarán o nos alejarán claramente de la fiabilidad.