En busca de los cinco 9s: Calculando la disponibilidad de sistemas complejos

Este artículo es la traducción del artículo In search of five 9s: Calculating Availability of Complex Systems, publicado por Bill el 29 de Octubre de 2007. Dado que el artículo original tiene demasiado texto, me he visto obligado a modificar la maquetación y añadir títulos.

Puede parecer un poco largo, pero es realmente interesante. Aunque tiene muchas fórmulas es sencillo de entender, gracias a los ejemplos.

Y he elegido este artículo porque con el cloud que está tan de moda resulta sencillo y relativamente barato redundar máquinas.

Además, éste es el tipo de artículos que realmente me hacen sentir como Ingeniero.

Disponibilidad y SLA

He pasado los últimos días tratando de desarrollar un modelo matemático simple para predecir la disponibilidad esperada en sistemas complejos. En IT se nos suele pedir que desarrollemos y cumplamos acuerdos de nivel de servicio (SLAs ). Si no se analizan los puntos de fallo de un sistema, y después se calcula la disponibilidad del sistema, el (SLA ). es defectuoso desde el principio. Para complicar aún más las cosas, diferentes personas tienen diferentes definiciones de disponibilidad. Por ejemplo: ¿cuenta un downtime planificado de mantenimiento en sus cálculos de disponibilidad del sistema?

Definiciones de Disponibilidad Comunes:

1. Disponibilidad = MTBF / ( MTTR + MTBF ). Ésta es una definición clásica de disponibilidad y es frecuentemente usada por fabricantes de hardware cuando publican una métrica de disponibilidad para un determinado servidor.

2. Disponibilidad = (Uptime + Scheduled Maintenance)/(Unscheduled Downtime + Uptime + Scheduled Maintenance). Consiste en una métrica centrada en IT donde el negocio puede permitirse downtimes durante horas. Este modelo funciona para determinados sistemas, como un servidor de ficheros que no se necesita durante la noche, pero no funciona bien para servicios web, a pesar de que muchas compañías aún lo usan para sus SLAs .

3. Disponibilidad = Uptime/(Uptime + Downtime). Es la métrica que mejor aplica para servicios que se necesitan 24x7, como sitios de comercio electrónico.

Normalmente se expresa la disponibilidad como un porcentaje. En ocasiones, la gente hace referencia a los “cuatro nueves” (99.99%) o los “cinco nueves” (99.999%). Para simplificar las cosas, en la siguiente tabla se muestran los minutos de downtime al año permitidos para un nivel determinado:

Basándose en la tabla anterior, se puede comprobar que hay una gran diferencia entre un SLA que especifique un 99% de disponibilidad (88 horas de downtime al año) y 99.9% de disponibilidad (8.8 horas de downtime al año). Pero ¿cómo se puede estar seguro de cuál es el downtime esperado de un sistema? En su form más simplista, la disponibilidad esperada de un sistema es la disponibilidad esperada de cada una de sus partes multiplicadas entre sí. De esta manera, si el sistema tiene dos servidores, y cada servidor tiene una disponibilidad esperada del 99%, entonces la disponibilidad del sistema sería \(99\% * 99\% = 98.01\%\). Nota: He usado la expresión “disponibilidad esperada”. Estamos calculando el futuro esperado de un sistema sobre un periodo de tiempo, no la disponibilidad histórica. Para el resto de este artículo, eliminaré el término “esperada” por brevedad, pero está siempre implícito.

Sistemas compuestos

El modelo simplista de más arriba es útil para mostrar que el downtime es acumulativo. En otras palabras, si se espera que un componente esté fuera de línea 88 horas/año, y un fallo de cualquier componente es un fallo del sistema, entonces el sistema tiene un downtime esperado de 174 horas. ¿Por qué no 176 horas? Bueno, ocasionalmente ambos componentes estarán caídos al mismo tiempo.

Los sistemas del mundo real nunca son tan simples. Típicamente el sistema estará compuesto de múltiples componentes, con redundancia, y cada uno con distinto nivel de disponibilidad por componente. Modelar esto requiere fórmulas algo más complicadas, pero en cuanto se tengan claros los conceptos, los nuevos cálculos pueden hacerse rápidamente en una hoja Excel. Antes de continuar necesitamos algo de notación básica para simplificar nuestras fórmulas:

• Disponibilidad del componente 1: \(Ac_1\)
• Disponibilidad del componente 2: \(Ac_2\)
• Disponibilidad del componente 3: \(Ac_3\)
• Disponibilidad del componente N: \(Ac_N\)
• Sistema de disponibilidad: \(As\)

Y dicho esto, estamos listos para nuestra primera fórmula. Cuando un sistema está constituído por N componentes que son puntos únicos de fallo, la disponibilidad del sistema se puede calcular como:

$$ As = Ac_1 * Ac_2 * Ac_3 * … Ac_n $$

Ejemplo

Consideremos un sitio de comercio electrónico 24x7 con muchos puntos únicos de fallo. Se podría modelar el sistema con los 8 componentes siguientes:

Si cualquiera de estos componentes falla, el sistema caerá. La disponibilidad esperada del sistema sería \(85\%*90\%*99.9\%*98\%*85\%*99\%*99.99\%*95\% = 59.87\%\). Nótese que se modela cada componente como un todo, en lugar de mirar cada una de sus partes. Se podría dividir el servicio web en el software (Apache), el código (nuestra web) y el hardware (placa base, discos duros, etc). Para nuestros propósitos, la complejidad no mejora necesariamente el modelo, así que trabajaremos con el servicio como un todo. Además, para esta discusión se utilizará la tercera definición de disponibilidad de arriba. Para nuestros usuarios, no importa si el sistema está caído por mantenimiento o por un disco duro roto.

Mejorar la disponibilidad

Si queremos conservar nuestros trabajos, necesitamos encontrar una manera de mejorar esta disponibilidad. Los objetivos obvios para mejorar la estabilidad del sitio son la web y el firewall. La pregunta es qué efecto tendría en la disponibilidad de la web añadir otro servidor. Con esto llegamos a la segunda ecuación. Cuando un sistema está compuesto por dos componentes redundantes, la disponibilidad del sistema se puede calcular como:

$$ As = Ac_1 + ((1 – Ac_1) * Ac_2) $$

Ejemplo

Usando nuestro ejemplo del servidor web con disponibilidad de 85%, añadir un segundo servidor incrementaría la disponibilidad a \(85\% + (1-85\%)*85\% = 97.75\%\). La lógica detrás de esto es que mientras el primer servidor está caído (15% del tiempo) el segundo servidor estará arriba el 85% del tiempo. Esto podría traducirse o no a la disponibilidad en el mundo real. Por ejemplo, si el servicio web está caído tan a menudo porque necesitamos desplegar nuestro código constantemente, añadir un segundo servidor debería traducirse en un incremento de la disponibilidad, ya que se puede desplegar código en el servidor fuera de línea mientras el otro servidor continúa funcionando. En este caso, el incremento de nuestra disponibilidad real debería ser mayor del 12.75%. En caso contrario, si el servicio se cae por errores de código, añadir un segundo servidor podría empeorar la disponibilidad debido al desesperante error.

La idea es que, en general, si has calculado rigurosamente la disponibilidad del componente, la ecuación funcionará. Nótese que la ecuación funcionará igualmente si los componentes tienen distinta estimación de disponibilidad. Supongamos que el servidor web tiene un problema de disponibilidad porque el hardware está subdimensionado. Ahora supongamos que el segundo servidor que hemos comprado tiene el doble de capacidad y determinamos que por sí mismo daría una disponibilidad del 90%, por lo que la ecuación cambia a \(85\% + (1-85\%)*90\% = 98.5\%\).

Volvamos al cálculo del sistema anterior y añadamos esto. Asumiendo que se ha añadido un segundo servidor web y un segundo firewall, incrementando la disponibilidad de estos componentes del sistema a 97.75%. Ahora la disponibilidad de nuestro nuevo sistema sería \(97.75\%*90\%*99.9\%*98\%*97.75\%*99\%*99.99\%*95\% = 79.10\%\). Mejor, pero aún no es buena. Es difícil conseguir cualquier nivel de alta disponibilidad cuando se tienen puntos únicos de fallo. Así que asumamos que añadimos componentes redundantes en todos nuestros servidores y equipos de red. Asumamos un segundo ISP para diversificar el transporte, pero aún estamos en un único CPD . Nuestra ecuación sería ahora: \(97.75\%*99\%*99.9999\%*99.96\%*97.75\%*99.99\%*99.99\%*99.75\% = 94.3\%\). Mejorando. Eliminando los puntos únicos de fallo se mejoró la disponibilidad del sistema del 60% (3506 horas de downtime/año) a 94.3% (500 horas de downtime/año).

Generalizando la fórmula

La ecuación #2 de más arriba modelaba cómo añadir un único componente. En algunos casos es necesario añadir más de un componente redundante. Por ejemplo, se podrían tener más de dos servidores web. En este caso es necesario iterar la ecuación #2 varias veces para agrupar el efecto de los componentes adicionales, lo que implica una tercera ecuación. Cuando se intenta calcular la disponibilidad de un servicio con n componentes redundantes, se calcula:

$$ As = Ac_{n-1} + ((1 – Ac_{n-1}) * Ac_n) $$

Ejemplo

En el caso de nuestro servidor web, añadir un tercer servidor cambia la disponibilidad a: \(97.75\% + (1-97.75\%)*85\% = 99.6625\%\). Añadiendo un cuarto servidor incrementaría la disponibilidad a: \(99.6625\% + (1-99.6625\%)*85\% = 99.949\%\). Nótese que hay una disminución de ganancia. Añadiendo el segundo servidor incrementó la disponibilidad en un 12.75%. Añadir el tercero sólo hizo ganar 1.9125%. El cuarto servidor nos da un insignificante .2865%. E incluso con 3 servidores más para distribuir nuestra carga, aún no se han conseguido los elusivos cuatro nueves de disponibilidad. Diseñar un sistema altamente disponible requiere que cada componente individual sea altamente disponible Y añadir redundancia en los componentes. Si el servidor web individual de nuestro sistema tuviera una disponibilidad del 90% en lugar del 85%, entonces la disponibilidad de los dos servidores sería del 99% y los tres servidores tendrían un 99.99%.

Las ecuaciones #2 y #3 tienen un defecto, ya que asumen que cada componente independiente puede manejar la carga, y que la carga es constante. ¿Qué ocurre si bajo operativa normal un servidor web puede manejar la carga, pero en pico se necesitan tres servidores? En ese caso la disponibilidad de los tres servidores en carga normal sería de 99.775%, mientras que en pico bajaría hasta el 85%. En un pico de carga, la caída de uno de los servidores podría significar una pérdida de servicio, por lo que se transforma a la disponibilidad de una única caja. ¿Y si el pico de carga requiere 2 servidores? En este caso la disponibilidad en pico sería del 97.75%. Si el pico require dos servidores y tenemos tres, la disponibilidad sería equivalente a tener dos servidores. El concepto importante aquí es que hay una relación inversa entre la carga y la disponibilidad.

Redundando el CPD

Debería ser obvio a estas alturas unos verdaderos altos niveles de disponibilidad (99.9% - 99.999%) es muy difícil y muy caro. Uno de los puntos únicos de fallo más caros a eliminar es el propio CPD . En la mayoría de los casos, doblará el coste de la infraestructura, e incluso podría ser más del doble, ya que será necesario invertir en tecnologías para sincronizar ambos CPDs .

De todas formas consideremos añadir un nuevo CPD . En el ejemplo de arriba, la disponibilidad de nuestro sistema con servidores e ISPs redundantes era del 94.3%. Añadir un segundo CPD con la tecnología necesaria para permitir que ambos trabajen de forma activo-activo (ambos centros reciben tráfico al mismo tiempo) incrementaría nuestra disponibilidad a \(94.3\% + (1-94.3\%)*94.3\% = 99.675\%\). ¡Añadir un nuevo CPD puede ahorrar hasta 471 horas de downtime al año!

En este ejemplo se asume que cada CPD es un sistema independiente, por lo que el fallo de un sistema en un CPD sería un fallo de todo el sistema en ese centro. No siempre es así. Por ejemplo, si se diseña correctamente, un servidor web podría conectarse a la base de datos del otro CPD . En este caso la disponibilidad sería mayor del 99.675%. Si se pudiera diseñar el site de manera que cada sistema operara de forma independiente al resto de servicios, la disponibilidad en el ejemplo se incrementaría del 99.675% al 99.888% (cada servicio tendría 3 componentes redundantes, excepto el CPD que sólo tendría uno).

Excel

Estas fórmulas son mucho más sencillas de mostrar en Excel. Pegue la siguiente tabla en una hoja de cálculo, comenzando en la casilla A1:

Ahora que tiene los conceptos claros y el principio de una hoja de cálculo para calcular los cambios de premisas, se puede centrar en aplicar estas teorías a su situación particular. Comenzando por descomponer su sistema, sea una web simple, un sistema de contabilidad o un sistema de ficheros, en servicios de componentes independientes. Para cada servicio, determine el número mínimo de unidades necesarias para trabajar, y la disponibilidad necesaria de cada unidad.

Estimar la disponibilidad puede ser un reto. Una manera es mirar datos históricos. Si no se tiene acceso a buenos datos, se puede formar una estimación basada en los parámetros de su operativa estándar. Por ejemplo, si se despliega código nuevo del servicio web dos veces al mes y cada una causa un downtime de 2 horas, se traduce en 48 horas de parada al año. Si se espera realizar labores de mantenimiento del sistema operativo una vez por trimestre, con un downtime estimado de 2 horas por trimestre, serían otras 8 horas más al año. Si además se anticipa a un fallo hardware al año, con garantía de entrega el siguiente día hábil, se traduciría en 41 horas de downtime al año (fallos en viernes se repararían el lunes, los sábados y domingos en martes). Sumando estos números obtenemos \(48 + 8 + 41 = 98\) horas de downtime al año, o una disponibilidad estimada del 98.882%.

Con un poco de esfuerzo, se puede estimar un nivel de disponibilidad realista para su sistema. Éste es el pilar para crear SLAs realistas y cumplibles. Estas fórmulas pueden ayudar a IT a negociar los SLAs con negocio, y puede ayudar a comparar el RSI de diferentes soluciones. Por ejemplo, digamos que se está intentando elegir una solución para el servidor web, y se tienen dos elecciones:

• La opción 1 consiste en 4 servidores usando hardware barato sin redundancia interna. Cada servidor cuesta 3.000 €. Estimamos la disponibilidad en un 75%.
• La opción 2 consiste en 2 servidores usando hardware caro con discos duros y fuentes de alimentación redundantes. Cada servidor cuesta 20.000 €. Estimas la disponibilidad de cada servidor en un 99%.

Se estima que el coste por downtime es de 500€/hora, y se espera que estos servidores aguanten la carga del sistema los próximos 3 años, tras los cuales se reemplazarán. Usando los números de arriba, la solución #1 tiene una disponibilidad esperada del 99.6% a un coste de 12.000€. La solución #2 tiene una disponibilidad esperada del 99.99%, a un coste de $40.000€. La solución #1 experimentaría 34 horas/año, o 102 horas en los tres años, de downtime más que la solución #2. En tres años, este downtime extra costaría $51.000€. Por lo que el gasto de 28.000€ previo proporcionará un RSI en 3 años del 182%. Nótese que el modelo es tan bueno como lo sean las estimaciones. Si los servidores de la solución #2 sólo tuvieran el 95% de disponibilidad, la disponibilidad combinada sería del 99.75%, lo que sólo proporciona 13 horas menos de downtime anual. En este caso sólo se ahorrarían 20,000€ en los 3 años por la inversión de 28.000€, por lo que podría ser mejor la opción #1.

Conclusión

Diseñar y operar sistemas de alta disponibilidad es un trabajo complicado, pero con unas pocas fórmulas sencillas, es posible entender y predecir su comportamiento general. Esto permitirá realizar mejores decisiones al elegir entre múltiples opciones, y hacer predicciones más realistas a la hora de negociar los SLAs .

Artículo original: In search of five 9s: Calculating Availability of Complex Systems

Traducido por Miguel Ángel García.