Compartir vía

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

  • Artículo

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.

Importante

La configuración con redundancia de zona está en versión preliminar pública para el nivel de servicio De uso general y está disponible con carácter general para el nivel de servicio Crítico para la empresa.

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. Por lo general, cuando aplique revisiones a una instancia o cuando la conmute por error, no se notará el tiempo de inactividad si usa la lógica de reintento en la 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 manera predeterminada, Azure SQL Managed Instance logra la disponibilidad mediante la redundancia local, lo que hace que la instancia esté disponible durante:

  • 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 con:
    • Bastidor en el que se ejecutan las máquinas que alimentan el 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 garantizar que los datos confirmados nunca se pierden debido a errores, que las operaciones de mantenimiento no afectan a 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 confiabilidad del servicio al protegerle del impacto en:

  • La 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 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 de motor de base de datos y que solo contiene datos transitorios y almacenados en caché, como las bases de datos tempdb y model en la memoria SSD conectada, y la memoria caché de planes, el grupo de búferes y el grupo de almacén de columnas en la 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. Aunque este proceso garantiza una alta disponibilidad, una carga de trabajo pesada podría experimentar una degradación del rendimiento durante la transición dado que el nuevo proceso de motor de proceso se inicia con la caché inactiva.

Nivel de servicio de uso general de nueva generación

Nota:

La actualización del nivel de servicio de uso general de nueva generación se encuentra actualmente en versión preliminar.

El Uso general de nueva generación es una actualización arquitectónica al nivel de servicio De uso general existente que usa una capa de almacenamiento remota actualizada que almacena los datos de instancia y los archivos de registro en discos administrados en lugar de blobs en páginas y los mantiene localmente.

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. Para conseguir alta disponibilidad se replica el proceso y el almacenamiento en nodos adicionales.

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

Los archivos de base de datos subyacentes (.mdf o .ldf) se colocan en el almacenamiento SSD conectado para proporcionar una latencia muy baja de E/S para la carga de trabajo. Para implementar alta disponibilidad se usa una tecnología parecida a la de 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 característica se denomina escalado horizontal de lectura y proporciona el 100 % de capacidad de proceso adicional al mismo costo para descargar operaciones de solo lectura, como cargas de trabajo de análisis, desde la réplica principal.

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 manera predeterminada, el clúster de nodos del 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 enruta a un equilibrador de carga que también se implementa en zonas de disponibilidad. Azure Traffic Manager (ATM) controla el enrutamiento del tráfico desde el plano de control al equilibrador de carga.

Mediante una configuración de redundancia de zona, puede hacer que las instancias de nivel Crítico para la empresa o De uso general sean resistentes a un número mucho mayor de errores, como interrupciones catastróficas de los centros de datos, sin necesidad de cambiar 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.

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.

Nivel de servicio Uso general

En el nivel de servicio De uso general, la redundancia de zona se logra colocando nodos de proceso sin estado en distintas zonas de disponibilidad y, después, se basa en un almacenamiento con redundancia de zona con estado (ZRS) que está asociado a cualquier nodo que contiene actualmente el proceso activo de Motor de base de datos de SQL. En caso de interrupción, el proceso de Motor de base de datos de SQL se activa en uno de los nodos sin estado, que luego accede a los datos en el almacenamiento con estado.

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

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

Nota:

La redundancia de zona está disponible actualmente en versión preliminar para el nivel de servicio De uso general.

Nivel de servicio Crítico para la empresa

En el nivel de servicio Crítico para la empresa, la redundancia de zona se logra colocando réplicas de proceso y almacenamiento en diferentes zonas de disponibilidad y, después, usando la tecnología de grupo de disponibilidad Always On subyacente para replicar los cambios de datos de la instancia principal en réplicas en espera en 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 verdadera, las conexiones a la instancia producen un error mientras el servicio SQL se convierte en 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. Pero 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 se comporta normalmente del mismo modo tanto en configuraciones con redundancia local como con redundancia de zona: solo reinicia el proceso 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 a una conmutación por error que se produce para 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 Azure CLI
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.

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 usa la tecnología de grupo de disponibilidad Always On de SQL Server para la replicación y la conmutación por error de la base 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.

Pasos siguientes