Alta disponibilidad para Azure SQL Managed Instance

  • Artículo

Se aplica a:Azure SQL Managed Instance

En este artículo se describe la alta disponibilidad en Azure SQL Managed Instance.

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

El objetivo de la arquitectura de alta disponibilidad en Azure SQL Managed Instance es minimizar el impacto en las cargas de trabajo del cliente de las operaciones de administración iniciadas por el cliente que se traducen en un breve tiempo de inactividad, operaciones de mantenimiento del servicio y cortes no planificados. Para más información sobre los Acuerdos de Nivel de Servicio específicos para los distintos niveles de servicio, consulte Azure SQL Managed Instance.

La alta disponibilidad le protege del impacto en:

  • Zona de disponibilidad que forma el centro de datos (en caso de región de varias zonas)
  • Bastidor en el que los nodos que activan el servicio se están ejecutando
  • Nodo en sí
  • Nivel de aplicación

Para minimizar el impacto en caso de interrupciones regionales o mayores, puede usar una de las técnicas disponibles que se tratan con nuestra visión general de la continuidad empresarial.

Azure 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 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.

La solución de alta disponibilidad 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 será un único punto de error en la arquitectura de software.

Hay dos modelos de arquitectura de alta 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 alta disponibilidad y confiabilidad del almacenamiento remoto y de la alta disponibilidad de los clústeres de proceso administrados por Azure Service Fabric. Este modelo de alta 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.

Disponibilidad con 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.

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.

Disponibilidad con redundancia de zona

La disponibilidad con redundancia de zona se basa en la colocación de réplicas de nodos de ejecución y almacenamiento 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 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 puede colocar diferentes réplicas de la instancia de nivel Crítico para la empresa en diferentes zonas de disponibilidad de la misma región. De la misma manera, los nodos de ejecución sin estado de un nivel de servicio de uso general se colocan en una zona de disponibilidad diferente, mientras que el almacenamiento con estado usa la configuración de almacenamiento con redundancia de zona (ZRS).

Para eliminar un punto de error único, también se duplica el anillo de control en varias zonas como tres anillos de puerta de enlace. El enrutamiento a un anillo de puerta de enlace específico se controla mediante Azure Traffic Manager (ATM). Si selecciona 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. También puede aplicar la configuración de redundancia de zona a 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.

En el diagrama siguiente se ilustra la versión con redundancia de zona de la arquitectura de alta disponibilidad:

Diagrama de la arquitectura de alta disponibilidad con redundancia de zona.

Al usar la redundancia de zona, tenga en cuenta lo siguiente:

  • La redundancia de zona no está disponible para el nivel de servicio de uso general de nueva generación.
  • Para información actualizada sobre las regiones que admiten configuraciones con redundancia de zona, consulte Soporte técnico de servicios por región.
  • Para la disponibilidad con redundancia de zona, la elección de una ventana de mantenimiento distinta de la predeterminada está disponible actualmente en regiones seleccionadas.

Regiones admitidas para instancias de nivel Crítico para la empresa

La redundancia de zona para SQL Managed Instance de nivel Crítico para la empresa se admite en las siguientes regiones:

América Europa Oriente Medio África Asia Pacífico
Sur de Brasil Centro de Francia Centro de Catar Norte de Sudáfrica Este de Australia
Centro de Canadá Norte de Italia Centro de Israel Centro de la India
Centro de EE. UU. Centro-oeste de Alemania Japón Oriental
Este de EE. UU. Este de Noruega Centro de Corea del Sur
Este de EE. UU. 2 Norte de Europa Sudeste de Asia
Centro-sur de EE. UU. Sur de Reino Unido Este de Asia
Oeste de EE. UU. 2 Centro de Suecia
Oeste de EE. UU. 3 Norte de Suiza
Centro de Polonia

Regiones admitidas para instancias de nivel De uso general

Nota:

La configuración de la redundancia de zona está en versión preliminar pública para el nivel de servicio De uso general.

América Europa Oriente Medio África Asia Pacífico
Sur de Brasil Centro de Francia Centro de Catar Norte de Sudáfrica Este de Australia
Este de EE. UU. Norte de Italia Centro de Israel Centro de la India
Este de EE. UU. 2 Centro-oeste de Alemania Japón Oriental
Centro-sur de EE. UU. Este de Noruega Centro de Corea del Sur
Oeste de EE. UU. 2 Norte de Europa Sudeste de Asia
Oeste de EE. UU. 3 Sur de Reino Unido Este de Asia
Centro de Suecia
Norte de Suiza
Centro de Polonia

Prueba de la resistencia a errores de la aplicación

La alta 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. En el caso de una instancia con redundancia de zona, la llamada a la API daría lugar a la redirección de las conexiones de cliente al nuevo elemento principal en una zona de disponibilidad diferente a la zona principal anterior. Por lo tanto, además de probar cómo afecta la conmutación por error a las sesiones de base de datos existentes, también puede comprobar si cambia el rendimiento de un extremo a otro debido a los cambios en la latencia de la red. 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.

Se puede iniciar una conmutación por error 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