Microsoft Azure: disponibilidad y consistencia de la base de datos para Azure SQL

Cuando usted o su empresa deciden trasladar su base de datos de sus servidores/computadoras locales a un entorno en la nube, la consistencia y la disponibilidad son dos factores importantes a considerar.

La consistencia de la base de datos es mucho más compleja. Significa que no importa cómo o dónde acceda a sus datos, la misma consulta le dará la misma salida de datos. También significa que sus datos permanecen intactos en caso de falla de una aplicación, desastre natural, etc.  

En este artículo, nuestro objetivo es simplificar cómo Azure Database for MySQL logra los objetivos de coherencia de datos y alta disponibilidad, a través de diferentes opciones de implementación. Obtendremos una visión general de los siguientes conceptos:

• Descripción de los 2 modos de implementación que ofrece Azure
• Disponibilidad y consistencia para la implementación de un solo servidor.
• Disponibilidad y coherencia para una implementación flexible.

Terminologías clave

Antes de comenzar, familiarícese con las siguientes palabras clave:

• PaaS:   plataforma como servicio
• Instancia: servidores virtuales que se ejecutan en hardware físico (en este caso, Azure)
• SLA: Acuerdo de nivel de servicio

Modos de implementación en Azure

Azure Database for MySQL es una PaaS (Plataforma como servicio). Esto significa que Azure le proporciona una instancia (o varias instancias) del servidor MYSQL. Azure se encarga de todo, desde la aplicación de parches hasta las actualizaciones. Para este modo, hay 2 opciones de implementación disponibles:

1. Implementación de un solo servidor: esta opción solo se recomienda si actualmente tiene una aplicación/carga de trabajo que utiliza un solo servidor y desea migrarla a la nube de Azure. Un solo servidor requiere una personalización mínima por parte del usuario. Proporcionó un SLA de 99,99% de disponibilidad dentro de una sola región.  
2. Implementación de servidor flexible: esta opción es muy recomendable para las cargas de trabajo de producción. Es flexible y le permite elegir zonas de disponibilidad, niveles de precios, optimizaciones de costos y más.  

Entonces, ahora que tiene una comprensión básica de los Nodes de implementación, profundicemos en la disponibilidad y la coherencia de estos 2 modos.  

Disponibilidad y Consistencia

Para la implementación de un solo servidor

Tiempo de inactividad planificado: como ejemplo, suponga que comienza con 4 núcleos virtuales en su instancia de Azure Database. A medida que agrega más y más aplicaciones, aumenta la carga de su base de datos. Para manejar esto, es posible que deba aumentar sus núcleos virtuales. Esta es una instancia de tiempo de inactividad planificado. Como puede ver en la arquitectura, Azure Database for MySQL está construido a partir de componentes separados como

• Puerta de enlace/proxy
• Servidor de base de datos
• almacenamiento azul

• Si necesita escalar hacia arriba o hacia abajo sus instancias informáticas, se proporciona un nuevo servidor de base de datos. Esto sucede con un tiempo de inactividad mínimo.
• Ampliar el almacenamiento no requiere tiempo de inactividad.
• Las actualizaciones, las correcciones de parches y las correcciones de errores requieren un tiempo de inactividad mínimo, de hasta 60-120 segundos como máximo. Sin embargo, se aconseja a los usuarios que eliminen las transacciones pesadas que se ejecutan en sus instancias de base de datos en tiempos de inactividad planificados.
• Tiempo de inactividad no planificado: cada vez que su servidor enfrenta un tiempo de inactividad inesperado, Azure implementa automáticamente otro servidor en un minuto. Para errores de almacenamiento de Azure, no hay tiempo de inactividad. Esto se debe a que los datos se replican 3 veces y, si una copia falla, los servidores Azure cambian para leer los datos de las otras 2 copias.
• También puede configurar réplicas de lectura de Azure (copias de bases de datos de respaldo) en varias regiones de Azure para garantizar la recuperación ante desastres (DR) en caso de fallas en una región completa.

Para implementación de servidor flexible:

 Hay 2 modos principales de diseño:

• Arquitectura con redundancia de zona: este diseño creará un servidor de base de datos principal en la zona de disponibilidad (como el este de EE. UU.). Otro servidor con exactamente las mismas configuraciones se colocará en una zona de disponibilidad diferente dentro de la misma región (como east us 2). Este modelo proporciona una mayor tolerancia a fallas, pero una mayor latencia en la transmisión de tráfico.
• Misma arquitectura de zona: en este diseño, tanto el servidor principal como el secundario se ubican dentro de la misma zona de disponibilidad. La transmisión de datos es más rápida, la latencia es menor debido a que los servidores están físicamente cerca. Sin embargo, la tolerancia a fallos es menor.
• Con ambas arquitecturas, los usuarios pueden aprovisionar réplicas de lectura para respaldo y consistencia de la base de datos. Las réplicas de lectura son una copia de solo lectura de su base de datos de Azure, diseñada para reducir la carga en su servidor principal. Puede encontrar una guía detallada para leer réplicas aquí.

Azure Database for MYSQL tiene un conjunto completo de servicios que garantizan la disponibilidad y la coherencia de los datos. Hay varias opciones para que elijas entre diferentes servidores, arquitecturas y pagues solo por los servicios que utilizas.