Disponibilidad mediante redundancia local y de zona: Azure SQL Managed Instance

Se aplica a:Azure SQL Managed Instance

En este artículo se describe la arquitectura de Azure SQL Managed Instance que logra la disponibilidad mediante la redundancia local y la alta disponibilidad mediante la redundancia de zona.

Información general

SQL Managed Instance se ejecuta en la versión estable más reciente del motor de base de datos de SQL Server en el sistema operativo Windows con todas las revisiones aplicables. Azure SQL Managed Instance controla automáticamente las tareas de mantenimiento críticas, como la aplicación de revisiones, copias de seguridad, actualizaciones del motor de base de datos de Windows y SQL, y eventos no planeados, como los errores subyacentes de hardware, software o red. Cuando se aplique un parche a una instancia o se produzca una conmutación por error, el tiempo de inactividad no tendrá un impacto significativo si implementas lógica de reintento en tu aplicación. SQL Managed Instance puede recuperarse rápidamente, incluso en las circunstancias más críticas, lo que garantiza que los datos estén siempre disponibles. La mayoría de los usuarios no observan que las actualizaciones se realizan continuamente.

De forma predeterminada, Azure SQL Managed Instance logra la disponibilidad mediante redundancia local, asegurándose de que la instancia controla las interrupciones, como:

  • Operaciones de administración iniciadas por el cliente que dan lugar a un breve tiempo de inactividad.
  • Operaciones de mantenimiento de servicio
  • Problemas e interrupciones del centro de datos relacionados con:
    • Bastidor donde están funcionando las máquinas que dan soporte a tu servicio.
    • Máquina física que hospeda la máquina virtual que ejecuta el motor de base de datos SQL.
    • Máquina virtual que ejecuta el motor de base de datos SQL
  • Otros problemas con el motor de base de datos SQL
  • Otras posibles interrupciones locales no planeadas

La solución de disponibilidad predeterminada está diseñada para asegurarse de que los datos confirmados nunca se pierden debido a errores, que las operaciones de mantenimiento tienen un impacto mínimo en la carga de trabajo y que la instancia no es un único punto de error en la arquitectura de software.

Pero para minimizar el impacto en los datos en caso de una interrupción en toda una zona, puede lograr una alta disponibilidad habilitando la redundancia de zona. Sin redundancia de zona, las conmutaciones por error se producen localmente dentro del mismo centro de datos, lo que puede provocar que la instancia no esté disponible hasta que se resuelva la interrupción; la única manera de recuperarse es mediante una solución de recuperación ante desastres, como mediante un grupo de conmutación por error o una restauración geográfica de una copia de seguridad con redundancia geográfica. Para más información, revise la Introducción a la continuidad empresarial.

La alta disponibilidad aumenta la fiabilidad de su servicio al protegerlo frente al impacto en:

  • Zona de disponibilidad que forma el centro de datos

Hay dos modelos de arquitectura de disponibilidad diferentes basados en el nivel de servicio:

  • El modelo de almacenamiento remoto se basa en una separación de proceso y almacenamiento en los niveles de servicio de uso general y de uso general de nueva generación que depende de la disponibilidad y confiabilidad del almacenamiento remoto y de la disponibilidad de los clústeres de proceso que administra Azure Service Fabric. Este modelo de disponibilidad va dirigido a las aplicaciones de negocio preocupadas por la economía que pueden permitirse una cierta degradación del rendimiento durante las actividades de mantenimiento.
  • El modelo de almacenamiento local se basa en un clúster de procesos del motor de base de datos que dependen de un cuórum de nodos de motor de base de datos disponibles en el nivel de servicio Crítico para la empresa que tienen almacenamiento local. Este modelo de almacenamiento local tiene como destino aplicaciones críticas que tienen una alta tasa de transacciones y requieren un alto rendimiento de E/S. La arquitectura de alta disponibilidad garantiza un impacto mínimo en el rendimiento de la carga de trabajo durante las actividades de mantenimiento.

A fin de obtener más información sobre los Acuerdos de Nivel de Servicio específicos para los distintos niveles de servicio, vea Acuerdo de Nivel de Servicio para Azure SQL Managed Instance.

Disponibilidad mediante redundancia local

La disponibilidad con redundancia local se basa en almacenar los nodos de ejecución y los datos dentro de un único centro de datos de la región primaria y protege los datos en caso de error local, como una red a pequeña escala o un error de alimentación. Si se produce un desastre a gran escala como un incendio o una inundación en una región, es posible que todas las réplicas de una cuenta de almacenamiento o los datos de nodos de ejecución se pierdan o no se puedan recuperar. Por lo tanto, para proteger aún más los datos al usar la opción de disponibilidad con redundancia local, considere la posibilidad de usar una opción de almacenamiento más resistente para las copias de seguridad de la base de datos.

Nivel de servicio de uso general

El nivel de servicio De uso general usa la arquitectura de disponibilidad de almacenamiento remoto. En la siguiente ilustración se muestran cuatro nodos diferentes con las capas de proceso y almacenamiento separadas.

Diagrama que muestra la separación del proceso y el almacenamiento.

El modelo de disponibilidad de almacenamiento remoto incluye dos capas:

  • Una capa de proceso sin estado que ejecuta el proceso del motor de base de datos y que solo contiene datos transitorios y almacenados en caché, como las bases de datos tempdb y model en el SSD conectado, y la caché de planes, el grupo de búferes y el grupo de columnas en memoria. Azure Service Fabric controla este nodo sin estado, que inicializa el motor de base de datos, controla el estado del nodo y realiza la conmutación por error a otro nodo si es necesario.
  • Una capa de datos con estado con archivos de base de datos (.mdf o .ldf) que se almacenan en Azure Blob Storage. Azure Blob Storage presenta características integradas de redundancia y disponibilidad de los datos. La disponibilidad con redundancia local se basa en almacenar los datos en el almacenamiento con redundancia local (LRS), que copia los datos tres veces dentro de un único centro de datos de la región primaria. Garantiza que todos los registros del archivo de registro o de la página del archivo de datos se conservarán aunque se bloquee el proceso de motor de base de datos.

Siempre que se actualice el motor de base de datos o el sistema operativo, o se detecte un error, Azure Service Fabric moverá el proceso sin estado de motor de base de datos a otro nodo de proceso sin estado con capacidad suficiente disponible. Los datos de Azure Blob Storage no se ven afectados por esta operación y los archivos de registro o de datos se asocian al proceso de motor de base de datos recién inicializado. Este proceso garantiza una alta disponibilidad, pero una carga de trabajo intensa podría experimentar cierta degradación del rendimiento durante la transición, ya que el nuevo proceso del motor de base de datos se inicia con la caché en frío.

Nivel de servicio de uso general de nueva generación

Próxima Generación de Uso General es una actualización arquitectónica del nivel de servicio de Uso General existente que utiliza una capa de almacenamiento remoto mejorada que guarda los datos de instancia y los archivos de registro en Elastic SAN en lugar de blobs de página y los gestiona localmente.

La redundancia de zona no está disponible para la actualización del nivel de servicio de Uso General de Próxima Generación.

Nivel de servicio Crítico para la empresa

El nivel de servicio Crítico para la empresa aprovecha el modelo de disponibilidad de almacenamiento local, que integra recursos de proceso (proceso del motor de base de datos) y almacenamiento (SSD conectado localmente) en un único nodo. La disponibilidad se logra mediante la replicación del proceso y el almacenamiento en nodos adicionales.

Diagrama de un clúster de nodos del motor de base de datos.

Los archivos subyacentes de la base de datos (.mdf/.ldf) se colocan en almacenamiento SSD conectado para proporcionar una latencia de E/S muy baja para su carga de trabajo. La disponibilidad se implementa mediante una tecnología similar a los grupos de disponibilidad AlwaysOn de SQL Server. El clúster incluye una única réplica principal que es accesible para las cargas de trabajo de cliente de lectura y escritura, y hasta tres réplicas secundarias (proceso y almacenamiento) que contienen copias de los datos. La réplica principal inserta constantemente los cambios en las réplicas secundarias en orden y garantiza que los datos se conservan en un número suficiente de réplicas secundarias antes de confirmar cada transacción. Este proceso garantiza que, si la réplica principal o una réplica secundaria legible dejan de estar disponibles por cualquier motivo, siempre habrá disponible una réplica totalmente sincronizada a la que conmutar. La conmutación por error la inicia Azure Service Fabric. Una vez que una réplica secundaria se convierte en la nueva réplica principal, se crea otra réplica secundaria para asegurarse de que el clúster tiene un número suficiente de réplicas para mantener el cuórum. Una vez completada la conmutación por error, las conexiones Azure SQL se redirigen automáticamente a la nueva réplica principal (o a la réplica secundaria legible en función de la cadena de conexión).

Como ventaja adicional, el modelo de disponibilidad de almacenamiento local incluye la posibilidad de redirigir las conexiones de Azure SQL de solo lectura a una de las réplicas secundarias. Esta funcionalidad se llama Read Scale-Out. Proporciona un 100 % adicional de capacidad de proceso sin coste adicional para descargar de la réplica principal las operaciones de solo lectura, como las cargas de trabajo analíticas.

Alta disponibilidad mediante redundancia de zona

La disponibilidad con redundancia de zona se basa en la colocación de réplicas en tres zonas de disponibilidad de Azure en la región primaria. Cada zona de disponibilidad es una ubicación física individual con alimentación, refrigeración y redes independientes.

De forma predeterminada, el clúster de nodos para el modelo de disponibilidad de almacenamiento local se crea en el mismo centro de datos. Con la incorporación de Azure Availability Zones, SQL Managed Instance coloca diferentes réplicas en diferentes zonas de disponibilidad de la misma región. Para eliminar un único punto de error, también se duplica el anillo de control en varias zonas. Después, el tráfico del plano de control se dirige a un equilibrador de carga que también está desplegado en varias zonas de disponibilidad. Azure Traffic Manager (ATM) controla el enrutamiento del tráfico desde el plano de control al equilibrador de carga.

Al utilizar una configuración con redundancia de zona, puede hacer que sus instancias Business Critical o General Purpose sean resistentes a un conjunto mucho más amplio de fallos, incluidas caídas catastróficas del centro de datos, sin realizar ningún cambio en la lógica de la aplicación. Puede convertir a la configuración de redundancia de zona cualquier instancia existente de nivel Crítico para la empresa o De uso general. La redundancia de zona no está disponible para el nivel de servicio De uso general de próxima generación.

Como las instancias con redundancia de zona tienen réplicas en distintos centros de datos situados a cierta distancia entre ellos, la mayor latencia de red puede aumentar el tiempo de confirmación de la transacción y, por lo tanto, afectar al rendimiento de algunas cargas de trabajo OLTP. Siempre puede volver a la configuración de zona única; para ello, deshabilite la configuración de redundancia de zona. Este proceso es una operación en línea similar a la actualización normal del objetivo de nivel de servicio. Al final del proceso, la instancia se migra desde un anillo con redundancia de zona a un anillo de zona única, o viceversa.

A fin de empezar a trabajar con la redundancia de zona para la instancia administrada de SQL, consulte Configuración de la redundancia de zona. Revise la disponibilidad de redundancia de zona por región para Azure SQL Managed Instance.

Nivel de servicio de uso general

En el nivel de servicio Uso general, la redundancia de zona se consigue colocando nodos de proceso sin estado en distintas zonas de disponibilidad y luego apoyándose en un almacenamiento con redundancia de zona (ZRS), vinculado al nodo que contiene en cada momento el proceso activo del motor de base de datos SQL. En caso de caída del servicio, el proceso del Motor de base de datos SQL se activa en uno de los nodos sin estado, desde el que luego accede a los datos del almacenamiento persistente.

En el diagrama siguiente se muestra la arquitectura de redundancia de zona para el nivel de servicio De uso general:

Diagrama de la arquitectura con redundancia de zona en el nivel de servicio de uso general.

Nivel de servicio Crítico para la empresa

En el nivel de servicio Crítico para el negocio, la redundancia de zona se logra colocando réplicas de proceso y almacenamiento en distintas zonas de disponibilidad y utilizando la tecnología subyacente de grupos de disponibilidad Always On para replicar los cambios en los datos desde la instancia principal hasta las réplicas en espera de otras zonas de disponibilidad. En caso de interrupción, hay una conmutación automática por error que realiza una transición sin problemas de una de las réplicas en espera para que sea la principal.

En el diagrama siguiente se muestra la arquitectura de redundancia de zona para el nivel de servicio Crítico para la empresa:

Diagrama de la arquitectura de redundancia de zona en el nivel de servicio Crítico para la empresa.

Prueba de la resistencia a errores de la aplicación

La disponibilidad es una parte fundamental de la plataforma SQL Managed Instance que funciona de modo transparente para la aplicación de base de datos. Sin embargo, podría ser conveniente probar el modo en que las operaciones de conmutación por error automáticas iniciadas durante los eventos planeados o no planeados afectarían a una aplicación antes de implementarla para producción. Puede desencadenar manualmente una conmutación por error mediante una llamada a una API especial para reiniciar una instancia administrada. Dado que la operación de reinicio es intrusiva y un gran número de ellas podría agotar la plataforma, solo se permite una llamada de conmutación por error cada 15 minutos para cada instancia administrada.

Durante una conmutación por error real, las conexiones a la instancia fallan mientras el servicio SQL pasa a ser el principal en un nodo diferente. Para simular una conmutación por error, invoque el comando que reinicia el proceso de SQL a fin de simular el inicio del servicio como si hubiera una conmutación por error. Sin embargo, las conexiones pueden producir un error durante un período más largo durante una conmutación por error verdadera en comparación con una conmutación por error simulada, ya que durante una conmutación por error verdadera, el proceso SQL se convierte en el principal en otra máquina virtual del clúster (ya sea localmente o en otra zona si está habilitada la redundancia de zona) y durante una conmutación por error simulada, el proceso SQL se reinicia en la máquina virtual existente.

El comando de conmutación por error manual de esta sección normalmente se comporta del mismo modo tanto en configuraciones con redundancia local como con redundancia de zona; solo reinicia el proceso de SQL localmente y no inicia una conmutación por error a otro nodo, aunque se aplican algunas excepciones. Esta conmutación por error local es diferente de la conmutación por error que se produce en un grupo de conmutación por error.

Se puede iniciar una conmutación por error local mediante PowerShell, la API REST o la CLI de Azure:

PowerShell API DE REST CLI de Azure
Invoke-AzSqlInstanceFailover SQL Managed Instance: Conmutación por error az sql mi failover se puede usar para invocar una llamada a la API REST desde la CLI de Azure.

Pruebas automáticas de conectividad interna

Para ayudar a garantizar la disponibilidad del servicio, Azure SQL Managed Instance ejecuta pruebas automáticas de conectividad interna para supervisar la confiabilidad del servicio y acelerar la detección de problemas. Estas pruebas se ejecutan cada 10 segundos desde direcciones IP internas dentro de la subred de la instancia administrada de SQL y tienen un impacto insignificante en el rendimiento de la red y el rendimiento del servicio. Una prueba valida la conectividad de un extremo a otro mediante el intento de un inicio de sesión con una credencial conocida por error (AzureSQLConnectivityChecker), que genera entradas de inicio de sesión con errores esperadas en registros de auditoría, eventos extendidos y registros de errores de SQL. Estas entradas son normales y no indican un problema de seguridad. Para obtener más información, incluida la identificación de firmas de prueba en los registros, consulte Pruebas automáticas de conectividad interna.

Conclusión

Azure SQL Managed Instance presenta una solución de alta disponibilidad incorporada, que está totalmente integrada con la plataforma Azure. El servicio depende de Service Fabric para detectar fallos y recuperarse, del almacenamiento Azure Blob para proteger los datos y de las zonas de disponibilidad para una mayor tolerancia a fallos. Y para el nivel de servicio Business Critical, SQL Managed Instance utiliza la tecnología de grupos de disponibilidad Always On de SQL Server para la replicación y la conmutación por error de bases de datos. La combinación de estas tecnologías permite que las aplicaciones obtengan todos los beneficios de un modelo de almacenamiento mixto y admite los SLA más exigentes.

Contenido relacionado

  • Last updated on