Entendiendo la Alta Disponibilidad de MySQL: Razones buenas y malas para usarla

El coste del tiempo de inactividad en el entorno empresarial aumenta rápidamente. En una encuesta, el 40% de los encuestados sugirió que sólo una hora de inactividad le costó a su organización más de 1 millón de dólares en pérdidas. Garantizar la disponibilidad constante de los servicios de bases de datos merece la pena.

Ahorra a su organización grandes sumas de dinero, por no mencionar que suaviza las relaciones con las partes interesadas de todas las formas y tamaños.

Entonces, ¿cómo garantizar la disponibilidad continua? El concepto detrás de la disponibilidad persistente se llama alta disponibilidad. En este artículo explicamos qué es la alta disponibilidad y cómo puede conseguirla para sus clústeres MySQL.

También señalamos un lado más oscuro de la alta disponibilidad, en el que los administradores de sistemas confían incorrectamente en la alta disponibilidad para realizar tareas de mantenimiento, y explicamos por qué hacerlo socava los objetivos de la alta disponibilidad, poniendo en riesgo las operaciones de su empresa.

Introducción a la alta disponibilidad

Hablemos primero de disponibilidad. No tiene mucho sentido poner en marcha un servicio como una base de datos si no está disponible para los usuarios la mayor parte del tiempo. Por tanto, cuando hablamos de disponibilidad, nos referimos al grado de accesibilidad de un servicio.

De cualquier servicio que funcione cabe esperar razonablemente que esté disponible cuando se necesite, pero también cabe esperar cierto tiempo de inactividad, uno o dos días al año o quizá un par de horas al mes.

Un servicio disponible de forma general puede ser adecuado para muchos casos de uso, pero cuando el servicio es de naturaleza crítica o cuando un gran volumen de usuarios depende de él, la mera "disponibilidad" no es suficiente.

Y ahí es donde entra en juego la alta disponibilidad. En términos básicos, la alta disponibilidad garantiza un nivel de disponibilidad superior al que se espera normalmente y, más concretamente, un nivel acordado, incluso teniendo en cuenta el mantenimiento, los parches y los errores y fallos generales.

¿Qué nivel de disponibilidad es la alta disponibilidad?

No hay una definición consensuada de lo que se considera alta disponibilidad, sólo que supera lo que generalmente se aceptaría como "disponible" para cumplir un requisito de disponibilidad específico (más alto). De hecho, es probable que su organización defina la disponibilidad que requiere en función de sus necesidades operativas, sopesando los costes de la alta disponibilidad frente a las pérdidas asociadas al tiempo de inactividad.

El nivel de disponibilidad que necesita puede expresarse en porcentaje. Por ejemplo, un 99,99% o "cuatro nueves" de disponibilidad implica un máximo de 52,60 minutos de inactividad al año, mientras que "seis nueves" o 99,9999% de disponibilidad limita el tiempo de inactividad a 31,56 segundos al año.

Esencialmente, la elección es suya, pero, de nuevo, hay una contrapartida. Mantener una alta disponibilidad será caro, ya que requerirá recursos físicos y licencias de software adicionales y agotará también los recursos de personal. Sin embargo, puede que le merezca la pena pagar este precio para evitar los costes derivados de las interrupciones o el riesgo de perder ingresos por culpa de clientes descontentos.

¿Cómo funciona en la práctica la alta disponibilidad?

La naturaleza exacta de su infraestructura de alta disponibilidad dependerá de su carga de trabajo. Sin embargo, a grandes rasgos, podría decirse que la alta disponibilidad se consigue cuando hay tolerancia a fallos, de modo que aunque falle un servicio o dispositivo, la carga de trabajo no se interrumpe. Normalmente, eso significa que no hay un único punto de fallo: todos los servicios y dispositivos son totalmente redundantes tanto a nivel de red como de aplicación.

Dependiendo del servicio, esto podría implicar normalmente una serie de nodos - por ejemplo, su clúster MySQL contendrá varios nodos a través de los cuales se almacenan los datos. A continuación, se combinan varios nodos con una herramienta de equilibrio de carga para que, en caso de fallo de un nodo, las peticiones se dirijan simplemente a otro nodo. Los usuarios seguirán accediendo a un servicio disponible, aunque el rendimiento se vea ligeramente degradado.

Configuración de la alta disponibilidad en MySQL

Su ruta hacia una base de datos MySQL de alta disponibilidad dependerá, por supuesto, de su implementación de MySQL. En términos generales, tendrá que crear algún tipo de clúster MySQL con múltiples nodos - en otras palabras, sus datos deben residir en múltiples servidores MySQL.

A continuación, necesitará un servicio que pueda replicar los datos entre estos nodos, garantizando que cada nodo tenga una copia exacta de los datos contenidos en su base de datos. Por último, necesita un equilibrador de carga que garantice que todas las solicitudes de bases de datos se dirijan de manera uniforme a los nodos de bases de datos, asegurando, sí, una carga equilibrada, pero también garantizando que las solicitudes se satisfagan incluso si un nodo está fuera de línea.

Por ejemplo, MySQL ofrece un producto comercial dirigido a la alta disponibilidad - el MySQL InnoDB Cluster. Se basa en MySQL Group Replication, que es una forma popular de garantizar la alta disponibilidad en un entorno de base de datos MySQL.

Otra alternativa es Galera, que lleva muchos años ofreciendo alta disponibilidad MySQL. Si está utilizando la bifurcación MariaDB de MySQL podría, por ejemplo, configurar su entorno MariaDB para alta disponibilidad ejecutando múltiples nodos usando Galera Cluster - mientras confía en HAProxy para el balanceo de carga. Alternativamente, usted podría mirar el propio producto MaxScale de MariaDB.

BUENAS RAZONES PARA CONFIAR EN LA ALTA DISPONIBILIDAD...

Las cargas de trabajo a escala empresarial utilizan cada vez más los principios de la alta disponibilidad simplemente porque, a largo plazo, ofrece los mejores resultados. Estas son solo algunas de las muchas buenas razones por las que debería considerar la configuración de la alta disponibilidad en sus operaciones:

• Aplicaciones críticas. Algunas aplicaciones simplemente no pueden permitirse ningún tiempo de inactividad, piense en aplicaciones militares o redes de energía. La alta disponibilidad es imprescindible en estos casos, y no tiene más remedio que garantizar unos niveles de disponibilidad extremadamente altos, aunque aún puede evaluar los riesgos y decidir exactamente cuánta garantía de disponibilidad necesita.
• Efectos en cadena. Cuando un sistema está en el núcleo de una carga de trabajo, incluso una breve inactividad puede provocar problemas mucho más generalizados, ya que los sistemas conectados y sincronizados caen en cascada. Merece la pena plantearse invertir en alta disponibilidad en unas pocas áreas centrales -como una base de datos- porque puede merecer la pena el coste, dado que los costes de problemas en cadena mucho mayores de los que puede ser muy difícil recuperarse.
• Pérdida de ingresos. Una alta disponibilidad, aunque sea de un modesto número de nueves, puede evitar la pérdida de ingresos. Para un gran minorista en línea, unas pocas horas de ventas perdidas, combinadas con el daño reputacional asociado, pueden tener un impacto muy significativo en el balance final.
• Expectativas de los clientes y acuerdos de nivel de servicio. Es posible que sus operaciones estén sujetas a acuerdos de nivel de servicio que garanticen a sus clientes un determinado nivel de tiempo de actividad. En ese caso, debe asegurarse de que los servicios que soportan las cargas de trabajo de sus clientes tengan el nivel requerido de tiempo de actividad, y lo hará mediante una alta disponibilidad. No hacerlo puede llevar a la rescisión de los contratos, o a penalizaciones en virtud de los mismos.

Estas son un par de razones válidas para la alta disponibilidad y, de nuevo, en el mundo tecnológico actual hay muchas cargas de trabajo que simplemente no pueden funcionar sin una plataforma de alta disponibilidad.

... y la razón equivocada para confiar en la alta disponibilidad 

Lamentablemente, la creciente prevalencia de la alta disponibilidad también ha dado lugar a abusos. Dado que la alta disponibilidad hace que los sistemas sean increíblemente robustos, los equipos técnicos pueden verse tentados a tomar atajos a la hora de realizar tareas de sysadmin, como la aplicación de parches, porque el equipo asume que la infraestructura de alta disponibilidad simplemente soportará la carga de desconectar una máquina.

En la práctica, puede complicarse rápidamente. Tomemos un clúster MySQL, por ejemplo. Sí, si reinicias una máquina para parchearla, tu clúster MySQL seguirá funcionando gracias a la alta disponibilidad. Sin embargo, recuerde que cuando se quita un nodo para parchearlo y luego se reinicia, se produce una acumulación de datos que requieren entrada. Este proceso puede tardar mucho tiempo en completarse.

Huelga decir que cada host de base de datos debe ver los mismos datos. El peligro viene durante la resincronización: si otro nodo se cae mientras ya has quitado un nodo para parchearlo puedes acabar con una pérdida de quórum válido. En otras palabras, el número de servidores que mantiene la "verdad" sobre los datos cae por debajo de un nivel aceptable. Recuperarse de un estado así puede ser difícil y complejo e incluso provocar la pérdida de datos.

No confíe en la alta disponibilidad para el mantenimiento

La alta disponibilidad está ahí para mantener sus sistemas en funcionamiento incluso cuando algo falla. Esta protección inherente contra fallos no es un pase libre para depender de la robustez de la alta disponibilidad con el fin de realizar el mantenimiento del sistema de forma irresponsable, esperando que nadie se dé cuenta.

En su lugar, los equipos técnicos deberían recurrir a otras soluciones: por ejemplo, establecer una redundancia total para un sistema que está siendo parcheado, en lugar de limitarse a esperar que la infraestructura de alta disponibilidad absorba la presión. O, cuando sea posible recurrir a la aplicación de parches en tiempo real y así eliminar la necesidad de reiniciar un servicio para instalar un parche.

Sin embargo, la dependencia de la alta disponibilidad para las tareas de mantenimiento está mostrando signos preocupantes de convertirse en algo prevalente. Busque un poco e incluso encontrará directrices oficiales de los proveedores que instruyen a los usuarios a depender de la alta disponibilidad para ejecutar tareas de parcheo y que los usuarios simplemente esperan que nada más vaya mal con otros nodos mientras un nodo se desconecta para parchear.

ENVOLVERLO

La alta disponibilidad es crítica para muchas aplicaciones y muy beneficiosa para muchas otras. Configurada correctamente, una base de datos MySQL puede ofrecer una disponibilidad prácticamente perfecta, pero eso no significa que los equipos técnicos puedan darla por sentada.

Abusar de la arquitectura de alta disponibilidad para tomar atajos en el mantenimiento no es una opción: los riesgos son mayores de lo que puede parecer a primera vista.

En su lugar, los administradores de sistemas deben recurrir a alternativas probadas -incluida la redundancia y la aplicación de parches en vivo- para realizar operaciones de mantenimiento sin socavar las capacidades de las soluciones de alta disponibilidad.