¿Cuándo considerar la alta disponibilidad?

“La alta disponibilidad no es algo que se compra, es algo que se hace.” – John Nicholson

Pocas cosas se desean de forma tan universal en TI como las soluciones de alta disponibilidad (HA). Es decir, en serio, di esas palabras y cualquier profesional de TI dirá al instante que quiere eso. HA para sus servidores, sus aplicaciones, su almacenamiento y, por supuesto, incluso sus escritorios. Si hubiera una casilla de verificación junto a cualquier sistema que simplemente dijera “HA”, ¿por qué no la marcaríamos? La marcaríamos, por supuesto. Nadie quiere voluntariamente un sistema que falle mucho. Fallo malo, éxito bueno.

Primero, sin embargo, debemos definir HA. HA puede significar muchas cosas. Como mínimo, HA debe significar que la disponibilidad del sistema en cuestión debe ser superior a la “normal”. ¿Qué es normal? Eso de por sí ya es bastante difícil de definir. HA es, en el mejor de los casos, un término impreciso. En el contexto de su uso más común, no obstante, que es el de las aplicaciones comunes que se ejecutan en hardware empresarial normal, ofrecería este punto de partida para las discusiones sobre HA:

La disponibilidad normal o estándar (SA) se definiría como la disponibilidad de un servidor de línea principal común que ejecuta un sistema operativo empresarial común, ejecutando una aplicación empresarial común en un entorno de mejores prácticas con soporte empresarial. Buenos ejemplos de esto podrían incluir Exchange ejecutándose en Windows Server sobre el HP Proliant DL380 (el servidor de productos básicos de línea principal más común). O BIND (el servidor DNS) ejecutándose en Red Hat Enterprise Linux sobre el Dell PowerEdge R730. Estos son solo ejemplos para establecer una referencia aproximada. No hay una buena manera de medir esto, pero con un buen contrato de soporte y una reparación o reemplazo rápidos en el mundo real, se cree que la fiabilidad de un sistema de esta naturaleza se sitúa entre cuatro y cinco nueves de fiabilidad (99,99 % de tiempo de actividad o superior) cuando no se incluye el fallo humano.

La alta disponibilidad (HA) debería definirse comúnmente como tener una disponibilidad significativamente superior a la de la disponibilidad estándar. Significativamente superior debería ser un mínimo de un orden de magnitud de incremento. Así que al menos cinco nueves de fiabilidad y, más probablemente, seis nueves. (99,9999 % de tiempo de actividad.)

La baja disponibilidad (LA) se definiría comúnmente como tener una disponibilidad significativamente inferior a la de la disponibilidad estándar, donde significativamente, de nuevo, significa al menos un orden de magnitud. Así que normalmente se asumiría que LA ronda entre el 99 % y el 99,9 % o una disponibilidad inferior.

La medición aquí es muy difícil, ya que los factores humanos, ambientales y otros desempeñan un papel enorme a la hora de determinar el tiempo de actividad de las distintas configuraciones. El mismo equipo utilizado en un rol podría alcanzar cinco nueves mientras que en otro no logre alcanzar ni siquiera uno. La calidad del centro de datos, la pericia del personal de soporte, la rapidez del reemplazo de piezas, la granularidad de la supervisión y multitud de otros factores afectarán significativamente la fiabilidad general. Sin embargo, esto no es necesariamente un problema para nosotros. En la mayoría de los casos podemos evaluar las partes del diseño de un sistema que controlamos de tal manera que pueda determinarse la fiabilidad relativa, de modo que al menos podamos demostrar que un enfoque va a ser superior a otro, con el fin de poder entonces aprovechar una toma de decisiones bien fundamentada incluso si no pueden construirse fácilmente modelos precisos de tasa de fallos.

Es importante señalar que, aparte de proporcionar un conjunto de ejemplos de referencia a partir del cual trabajar, no hay nada en las definiciones de alta disponibilidad o baja disponibilidad que hable de cómo deberían alcanzarse estos niveles; eso no es lo que significan los términos. Los términos son conjuntos resultantes de fiabilidad en relación con la referencia y nada más. Hay muchas maneras de alcanzar la alta disponibilidad sin usar los enfoques que comúnmente se asumen, y maneras prácticamente ilimitadas de alcanzar la baja disponibilidad.

Por supuesto, la HA puede definirse en cada capa. Podemos tener plataformas o sistemas operativos de HA pero tener aplicaciones frágiles por encima. Por eso es muy importante comprender a qué nivel estamos hablando en cada momento. Al final del día, a una empresa solo le importará la entrega de servicios con alta disponibilidad, independientemente de cómo se logre, o dónde. Lo que importa es el resultado final, no los detalles “internos” de cómo se consiguió o, como siempre, el fin justifica los medios.

Es extremadamente común hoy en día que los departamentos de TI se distraigan con herramientas de HA nuevas y vistosas en la capa de plataforma y se olviden de buscar HA más arriba y más abajo en la pila para asegurarse de que proporcionamos servicios de alta disponibilidad a la empresa; en lugar de mirar únicamente una capa mientras dejan a la empresa igual de vulnerable, o más, que nunca.

En el mundo real, sin embargo, la HA no siempre es una opción y, cuando lo es, tiene un costo. Ese costo es casi siempre monetario y generalmente conlleva una complejidad adicional también. Y como bien sabemos, cualquier complejidad acarrea además un riesgo adicional, y ese riesgo podría, si no tenemos cuidado, provocar que un intento de alcanzar HA fracase realmente e incluso podría dejarnos con LA o baja disponibilidad.

Una vez que comprendemos este lenguaje necesario para describir lo que queremos decir, podemos empezar a hablar de cuándo la alta disponibilidad, la disponibilidad estándar e incluso la baja disponibilidad pueden ser adecuadas para nosotros. Usamos este alto nivel de granularidad porque es tan difícil medir la fiabilidad de un sistema que entrar en demasiados detalles se vuelve inútil.

Conceptualmente, todos los sistemas conllevan un riesgo de inactividad y nada puede estar siempre activo, eso es imposible. La fiabilidad cuesta dinero, en general, en igualdad de las demás condiciones. Así que, para determinar qué nivel de disponibilidad es el más apropiado para una carga de trabajo, debemos determinar el costo de la mitigación del riesgo (la cantidad de dinero que se necesita para cambiar la cantidad promedio de inactividad) y compararlo con el costo de la propia inactividad.

Esto se vuelve delicado y complicado porque determinar el costo de la inactividad ya es bastante difícil, y luego determinar el riesgo de inactividad es aún más difícil. En muchos casos, la inactividad no es una cifra fija, aunque podría serlo. Este costo podría expresarse como 5 $/minuto o 20 000 $/día o algo similar. Pero una herramienta aún mejor sería crear una “curva de impacto de pérdidas” que muestre cómo se pierde dinero a lo largo del tiempo (dentro de un intervalo razonable).

Por ejemplo, una empresa podría fácilmente no enfrentar pérdida alguna durante los primeros cinco minutos, con pérdidas que aumentan lentamente, pero pequeñas, hasta aproximadamente cuatro horas, cuando el trabajo se detiene porque las personas ya no pueden recurrir al papel o lo que sea, y entonces las pérdidas pasan de casi cero a bastante grandes. O algunas empresas podrían sufrir una pérdida enorme en el momento en que los sistemas se caen, pero las pérdidas se disipan lentamente con el tiempo. La pérdida podría ser impactante únicamente en ciertos momentos del día. Quizás las interrupciones por la noche o durante el almuerzo sean triviales, pero las de media mañana o media tarde sean graves. El impacto, el riesgo y la capacidad de mitigar ese riesgo de cada empresa son diferentes, a menudo de forma drástica.

A veces se reduce a las personas que trabajan en la empresa. ¿Aprovecharán todas con gusto los descansos necesarios para ir al baño, tomar café, comer un tentempié o incluso almorzar en el momento en que un sistema falla, de modo que puedan volver al trabajo cuando esté arreglado? ¿Se irán las personas temprano a casa y vendrán temprano mañana para compensar una interrupción importante? ¿Hay maquinaria que va a quedar inactiva? ¿Se verá afectada la capacidad de responder a los clientes? ¿Fallarán los sistemas de soporte vital? Hay incontables impactos potenciales e incontables formas potenciales de mitigar distintos tipos de fallos. Todo esto debe tenerse en cuenta. El costo de la inactividad podría ser una fracción de los ingresos corporativos minuto a minuto, o la inactividad podría provocar una pérdida de clientes o de confianza que resulte más impactante que los ingresos generados minuto a minuto.

Una vez que tenemos algunas cifras aproximadas de pérdidas con las que trabajar, al menos tenemos un punto de partida. Aunque solo sepamos que los ingresos son de ~10 $/minuto y se espera que las pérdidas ronden los ~5 $/minuto, tenemos una especie de punto de partida. Si disponemos de una curva completa o de un estudio realizado con cifras más detalladas, mucho mejor. Ahora necesitamos averiguar aproximadamente cuál va a ser nuestra referencia. Un servidor bien mantenido, ejecutándose en las instalaciones, con un buen contrato de soporte y buenos procedimientos de copia de seguridad y restauración, puede alcanzar con bastante facilidad cuatro nueves de fiabilidad. Eso significa que experimentaríamos alrededor de cinco horas de inactividad cada cinco años. Esto es en realidad menos que la inactividad generalmente esperada de SA en la mayoría de los entornos, y potencialmente muy inferior a los niveles esperados en entornos excelentes como centros de datos de alta calidad con piezas y servicio cercanos.

Así pues, basándonos en nuestro ejemplo de referencia de alrededor de cinco horas cada cinco años, podemos calcular nuestro riesgo potencial. Si perdemos alrededor de ~5 $/minuto y esperamos aproximadamente 300 minutos de inactividad cada cinco años, estamos ante una pérdida potencial de 1500 $ cada media década.

Eso significa que, en el caso más extremo, nunca podríamos gastar 1500 $ para mitigar ese riesgo; eso sería financieramente absurdo. Esto sucede por varias razones. Una de las más importantes es que esto es solo un riesgo; gastar 1500 $ para protegerse contra la pérdida de 1500 $ tiene poco sentido, pero es un error muy común de cometer cuando las personas no analizan estas cifras cuidadosamente.

El factor más importante es que ninguna técnica de mitigación es completamente eficaz. Si logramos llevar nuestro sistema de cuatro nueves a un sistema de cinco nueves, reduciríamos solo el 90 % de la inactividad promedio, pasando de 1500 $ de pérdida a 150 $ de pérdida. Si gastáramos 1500 $ por esa reducción, la “pérdida” total seguiría siendo de 1650 $ (el costo de la protección es una forma de pérdida financiera). El costo de la mitigación del riesgo combinado con el impacto restante previsto, tomados en conjunto, debe seguir siendo inferior al costo previsto del riesgo sin mitigación o, de lo contrario, la propia mitigación es inútil o activamente perjudicial.

Muchos podrían cuestionar por qué el costo total de la mitigación del riesgo debe ser inferior y no simplemente igual, ya que seguramente eso debe significar que estamos en un punto de “equilibrio de riesgo”. Esto parece cierto en la superficie, pero como estamos tratando con el riesgo, no es así. La mitigación del riesgo es un costo cierto: un daño financiero que asumimos por adelantado con la esperanza de reducir las pérdidas del mañana. Pero el riesgo del mañana es una conjetura, con suerte bien fundamentada, pero solo una conjetura. El costo de hoy es cierto. Asumir un daño cierto hoy con la esperanza de reducir un posible daño mañana solo tiene sentido cuando el daño de hoy es pequeño y el daño esperado o posible de mañana es muy grande, y la eficacia de la mitigación es significativa.

Incluida en la idea del “costo cierto por adelantado” para reducir el “posible costo de mañana” está la idea del valor temporal del dinero. Incluso si una interrupción fuera de un tamaño y un momento conocidos, no gastaríamos el mismo dinero hoy para mitigarla mañana, porque nuestro dinero es más valioso hoy.

En los casos más dramáticos, a veces vemos departamentos de TI exigiendo que se gasten decenas o cientos de miles de dólares por adelantado para evitar perder unos pocos miles de dólares, quizás, en algún momento, tal vez dentro de muchos años en el futuro. Una estrategia a la que podemos referirnos como “dispararnos en la cara hoy para evitar quizás tener dolor de cabeza mañana.”

Está incluido en el concepto de evaluar la mitigación del riesgo, pero debería mencionarse específicamente que, en el caso del equipo de TI, hay muchos ejemplos de intentos de mitigación del riesgo que pueden no ser tan eficaces como se cree. Por ejemplo, tener dos servidores que se encuentran en el mismo rack será potencialmente muy eficaz para mitigar el riesgo de un fallo de hardware del host, pero no mitigará contra desastres naturales, pérdida del sitio, incendios, la mayoría de los casos de descarga eléctrica, activación de la supresión de incendios, interrupciones de red, la mayoría de los fallos de aplicaciones, ataques de ransomware u otros desastres razonablemente posibles.

Es común que los dispositivos de almacenamiento estén equipados con “controladoras duales”, lo que da una fuerte impresión de alta fiabilidad, pero generalmente estas controladoras están dentro de un único chasis con componentes compartidos e, incluso si los componentes no se comparten, a menudo el firmware se comparte y las comunicaciones entre componentes son complejas; lo que con frecuencia conduce a fallos en los que el fallo de un componente desencadena el fallo de otro, convirtiéndolos muy a menudo en dispositivos LA en lugar de SA o de la HA que la gente esperaba al adquirirlos. Por eso es muy crítico considerar si la estrategia de mitigación del riesgo mitigará qué riesgos y si es probable que la técnica de mitigación sea eficaz. Ninguna técnica es completamente eficaz, siempre existe una posibilidad de fallo, pero algunas estrategias y técnicas son más ampliamente eficaces que otras y algunas son simplemente engañosas o realmente contraproducentes. Si no tenemos cuidado, podríamos implementar productos o técnicas costosos que socaven activamente nuestros objetivos.

Algunas técnicas y productos utilizados en la búsqueda de la alta disponibilidad son bastante costosos, lo que podría incluir comprar hardware redundante, arrendar otro edificio, instalar generadores costosos o licenciar software especial. También existen técnicas y software de bajo costo, pero en la mayoría de los casos cualquier avance hacia la alta disponibilidad resultará en un desembolso comparativamente grande de capital de inversión para lograrla. Es absolutamente crítico tener presente que la alta disponibilidad es un proceso; no hay manera de simplemente comprar alta disponibilidad. Alcanzar la HA requiere buena documentación, procedimientos, planificación, soporte, equipo, ingeniería y más. En el mundo de los sistemas, la HA normalmente se aborda primero desde una perspectiva ambiental con generadores de energía de conmutación por error, sistemas de climatización (HVAC) redundantes, acondicionamiento de energía, filtración de aire, sistemas de supresión de incendios y más para garantizar que el entorno para la disponibilidad esté presente. Esto por sí solo a menudo puede hacer innecesaria una inversión adicional, ya que puede ofrecer resultados increíbles. Luego viene el diseño de sistemas de HA, asegurando que no solo una capa de una pila tecnológica sea altamente disponible, sino que toda la pila lo sea, permitiendo que las aplicaciones, los datos o los servicios críticos permanezcan funcionales durante el mayor tiempo posible. Luego, considerar la redundancia de sitio a sitio para poder resistir inundaciones, huracanes, ventiscas, etc. Por supuesto, existen técnicas completamente diferentes, como utilizar servicios de computación en la nube alojados de forma remota en nuestro nombre. Lo que importa es que la alta disponibilidad requiere un pensamiento y una planificación amplios, no puede simplemente adquirirse como una partida y se juzga por la capacidad de devolver un factor de riesgo que proporcione un tiempo de actividad resultante, o una probabilidad de tiempo de actividad, mucho mayor que el que ofrecería un diseño de sistema “estándar”.

Lo que a menudo resulta sorprendente, casi chocante, para muchas empresas y especialmente para los profesionales de TI, que rara vez emprenden un análisis de riesgo financiero y a quienes constantemente se les dice que la HA es una necesidad para cualquier empresa y que comprar los últimos productos de HA es incuestionablemente la forma en que deberían gastarse sus presupuestos, es que cuando se hacen los números y se consideran la realidad de los costos y la eficacia de las estrategias de mitigación del riesgo, la alta disponibilidad tiene muy poco lugar en cualquier organización, especialmente en aquellas que son pequeñas o que tienen cargas de trabajo muy dispares. En el mercado de la pequeña y mediana empresa es casi universal encontrar que el costo y la complejidad (que a su vez trae riesgo, principalmente en forma de falta de experiencia en torno a las técnicas y la evaluación de riesgos) de los enfoques de alta disponibilidad es demasiado costoso como para compensar alguna vez el daño potencial de la interrupción de la que se espera que proteja la mitigación. Hay excepciones, por supuesto, y hay muchas empresas para las cuales las soluciones de alta disponibilidad son absolutamente sensatas, pero estas son la excepción y están muy lejos de ser la norma.

También es sensato concebir las necesidades de alta disponibilidad sobre la base de la carga de trabajo y no a nivel de departamento, de empresa o de toda la tecnología. En una pequeña empresa es común que todas las cargas de trabajo compartan una plataforma común, y la necesidad de alta disponibilidad de una sola carga de trabajo puede arrastrar consigo a otras cargas de trabajo menos críticas. Esto está perfectamente bien y es una excelente manera de compensar el costo de la mitigación del riesgo de la carga de trabajo crítica mediante un beneficio colateral para las cargas de trabajo menos críticas. En una organización más grande, donde hay una plétora de enfoques de plataforma utilizados para distintas cargas de trabajo, es común que solo ciertas cargas de trabajo que son a la vez altamente críticas (en términos de riesgo por el impacto de la inactividad) y que tienen el riesgo prácticamente mitigado (la capacidad de mitigar el riesgo puede variar drásticamente entre distintos tipos de cargas de trabajo) tengan alta disponibilidad aplicada, y que otras cargas de trabajo se dejen a las técnicas estándar.

Ejemplos de cargas de trabajo que pueden ser críticas y que pueden abordarse eficazmente con alta disponibilidad podrían ser un sistema de pedidos en línea donde la latencia creada por la replicación multirregional tiene poco impacto en el sistema general, pero perder pedidos podría ser muy impactante financieramente en caso de que un sistema falle. Un ejemplo de una carga de trabajo donde la alta disponibilidad podría ser fácil de implementar pero ineficaz sería un sitio de intranet interno que sirve preguntas frecuentes de RR. HH.; simplemente no sería rentable evitar pequeñas cantidades de inactividad ocasional para un sistema como este. Un ejemplo de un sistema donde el riesgo es alto pero el costo o la eficacia de la mitigación del riesgo lo hace impráctico o incluso imposible podría ser una base de datos financiera de “ticks” que requiere ingerir cantidades masivas de datos de baja latencia, y donde la capacidad de mantener una réplica no solo sería increíblemente costosa, sino que podría introducir una latencia que socavaría la capacidad del sistema para funcionar adecuadamente. Cada empresa y cada carga de trabajo es única y debe evaluarse cuidadosamente.

Por supuesto, las técnicas de alta disponibilidad pueden ponerse en práctica por etapas; no es una empresa de todo o nada. Podría ser práctico mitigar el riesgo de fallo a nivel de sistema teniendo tolerancia a fallos en la capa de aplicación para protegerse contra el fallo del hardware del sistema, la plataforma de virtualización o el almacenamiento. Pero para la misma carga de trabajo podría no ser valioso protegerse contra la pérdida de un único sitio. Si una carga de trabajo solo da servicio a un sitio en particular o simplemente no es lo suficientemente valiosa como para justificar la gran inversión necesaria para hacerla conmutar entre sitios, fácilmente podría quedar “en el medio.” Es muy común que las cargas de trabajo solo implementen soluciones de alta disponibilidad parciales, a menudo porque un departamento de TI puede ser responsable solo de una parte de ellas y no tener voz sobre cosas como el soporte de energía y la climatización, pero probablemente lo más común sea porque algunas técnicas de alta disponibilidad se ven como de alta visibilidad y fáciles de vender a la dirección, mientras que otras, como la energía y el aire acondicionado de alta calidad, a menudo ni siquiera lo son, aunque puedan ofrecer fácilmente una mejor relación calidad-precio. Hay buenas razones por las que pueden elegirse ciertas técnicas y no otras, ya que afectan a distintos componentes del riesgo y algunos riesgos pueden tener un impacto diferente en una empresa o carga de trabajo individual.

La alta disponibilidad requiere una reflexión cuidadosa sobre si vale la pena considerarla y una reflexión aún más cuidadosa sobre su implementación. Construir verdaderos sistemas de HA requiere una cantidad significativa de esfuerzo y experiencia y, en general, un costo sustancial. Comprender qué componentes de la HA son valiosos y cuáles no requiere no solo una amplia experiencia técnica, sino también habilidades financieras y de gestión. Los departamentos deben trabajar juntos extensamente para comprender verdaderamente cómo la HA impactará a una organización y cuándo valdrá la inversión. Es crítico recordar que la necesidad de alta disponibilidad en una organización o para una carga de trabajo está lejos de ser una conclusión inevitable y no debería sorprender en lo más mínimo descubrir que las prácticas extensivas de alta disponibilidad, o incluso las prácticas informales de alta disponibilidad, resultan ser económicamente imprácticas.

En muchos sentidos esto se debe a que la disponibilidad estándar ha alcanzado tal estado que hay cada vez menos riesgo que mitigar. Los componentes tecnológicos utilizados en una infraestructura empresarial, sobre todo los servidores, el equipo de red y el almacenamiento, se han vuelto tan fiables que la cantidad de inactividad contra la que debemos protegernos es bastante baja. La mayor parte de la creencia en la necesidad de una alta disponibilidad por reflejo proviene de una era diferente, cuando el hardware fiable era inasequible e incluso el equipo más caro era bastante poco fiable para los estándares modernos. Esta sensación de fatalidad inminente de que cualquier dispositivo podría fallar en cualquier momento proviene de una era más antigua, no de la actual. El equipo moderno, aunque obviamente sigue conllevando riesgos, es asombrosamente fiable.

Además de otros riesgos, sobreinvertir en soluciones de alta disponibilidad conlleva riesgos financieros y empresariales que pueden ser sustanciales. Aumenta la deuda técnica frente a la incertidumbre empresarial. ¿Qué pasa si la empresa crece de repente o, peor aún, qué pasa si de repente se contrae, cambia de dirección, es adquirida o quiebra por completo? La inversión en la alta disponibilidad ya está gastada incluso si la necesidad de su protección desaparece. ¿Qué pasa si cambian la tecnología o la ubicación? Parte o la totalidad de una inversión en alta disponibilidad podría perderse antes de lo que lo habría hecho al final de su vida útil prevista.

Como profesionales de TI, evaluar los beneficios, los riesgos y los costos de las soluciones tecnológicas es el núcleo de lo que hacemos. Como todo lo demás en la infraestructura empresarial, determinar el tipo de mitigación del riesgo, el valor de la protección y cuánto es financieramente apropiado es nuestra responsabilidad clave y no puede pasarse por alto ni ignorarse. Nunca podemos simplemente asumir que se necesita alta disponibilidad, ni que simplemente puede omitirse. Es en un análisis de esta naturaleza donde la TI aporta parte de su mayor valor a las organizaciones. Es aquí donde tenemos el potencial de brillar más.