Alta disponibilidad para Azure SQL Database e Instancia administrada de SQL

Se aplica a: Azure SQL Database Azure SQL Managed Instance

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

La configuración con redundancia de zona está actualmente en versión preliminar para SQL Managed Instance y solo está disponible para el nivel de servicio Crítico para la empresa.

Información general

El objetivo de la arquitectura de alta disponibilidad en Azure SQL Database y SQL Managed Instance es garantizar que la base de datos funcione como mínimo el 99,99 % del tiempo, sin preocuparse del efecto de las operaciones de mantenimiento y las interrupciones. Para más información sobre el Acuerdo de Nivel de Servicio específico para los distintos niveles, consulte SLA para Azure SQL Database y SLA para Azure SQL Managed Instance.

Azure controla automáticamente las tareas de mantenimiento críticas, como la aplicación de revisiones, copias de seguridad, actualizaciones de Windows y Azure SQL, y eventos no planeados, como los errores subyacentes de hardware, software o red. Cuando se conmute por error la base de datos subyacente de Azure SQL Database o se le apliquen revisiones, no se notará el tiempo de inactividad si usa la lógica de reintento en su aplicación. Azure SQL Database e Instancia administrada de SQL pueden recuperarse rápidamente, incluso en las circunstancias más críticas, lo que garantiza que los datos estén siempre disponibles.

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 base de datos no será un único punto de error en la arquitectura de software. No hay ventanas de mantenimiento ni tiempos de inactividad que puedan requerir que detenga la carga de trabajo mientras se actualiza o se mantiene la base de datos.

Hay dos modelos arquitectónicos de alta disponibilidad:

  • El modelo de disponibilidad estándar que se basa en la separación del proceso y el almacenamiento. Depende de la alta disponibilidad y la confiabilidad de la capa de almacenamiento remoto. Esta arquitectura va dirigida 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 disponibilidad prémium que se basa en un clúster de procesos del motor de base de datos. Depende del hecho de que siempre hay un quórum de nodos del motor de base de datos disponibles. Esta arquitectura va dirigida a aplicaciones críticas con alto rendimiento de E/S y elevada tasa de transacciones, y garantiza un impacto mínimo sobre el rendimiento de la carga de trabajo durante las actividades de mantenimiento.

Azure SQL Database y SQL Managed Instance se ejecutan en la versión estable más reciente del Motor de base de datos de SQL Server y del sistema operativo Windows, y la mayoría de los usuarios no advierten que las actualizaciones se realizan continuamente.

Disponibilidad con redundancia local de los niveles de servicio Básico, Estándar y De uso general

Los niveles de servicio Básico, Estándar y De uso general utilizan la arquitectura de disponibilidad estándar para los procesos aprovisionados y sin servidor. 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 estándar incluye dos capas:

  • Una capa de proceso sin estado que ejecuta el proceso sqlservr.exe 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. Este nodo sin estado lo opera Azure Service Fabric, que inicializa sqlservr.exe, 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. 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 sqlservr.exe.

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 sqlservr.exe 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 sqlservr.exe recién inicializado. Aunque este proceso garantiza el 99,99 % de disponibilidad, una carga de trabajo pesada podría experimentar una degradación del rendimiento durante la transición dado que el nuevo proceso de sqlservr.exe se inicia con la caché inactiva.

Disponibilidad con redundancia de zona del nivel de servicio De uso general

La configuración con redundancia de zona para el nivel de servicio de uso general se ofrece tanto para el proceso de aprovisionamiento como sin servidor. Esta configuración emplea Azure Availability Zones para replicar las bases de datos entre varias ubicaciones físicas dentro de una región de Azure. Al seleccionar la redundancia de zona, puede hacer que las bases de datos de uso general sin servidor o aprovisionadas existentes y los grupos elásticos sean capaces de resistir 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.

La configuración con redundancia de zona para el nivel De uso general tiene dos capas:

  • Una capa de datos con estado con los archivos de base de datos (.mdf o .ldf) que se almacenan en ZRS (almacenamiento con redundancia de zona). Con ZRS, los archivos de datos y de registro se copian de forma sincrónica en tres zonas de disponibilidad de Azure aisladas físicamente.
  • Una capa de proceso sin estado que ejecuta el proceso sqlservr.exe y que solo contiene datos transitorios y 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 memoria. Azure Service Fabric controla este nodo sin estado, que inicializa sqlservr.exe, controla el estado del nodo y realiza la conmutación por error a otro nodo si es necesario. En el caso de las bases de datos de uso general sin servidor y aprovisionadas, con redundancia de zona, los nodos con capacidad de reserva están disponibles fácilmente en otras zonas de disponibilidad para la conmutación por error.

En el diagrama siguiente se ilustra la versión con redundancia de zona de la arquitectura de alta disponibilidad para el nivel de servicio De uso general:

Diagrama de la configuración con redundancia de zona para nivel de uso general

  • En el nivel De uso general, la configuración con redundancia de zona es de disponibilidad general en las siguientes regiones: Oeste de Europa, Norte de Europa, Oeste de EE. UU. 2, Centro de Francia, Este de EE. UU. 2, Este de EE. UU., Sudeste de Asia y Centro de Catar. Está en versión preliminar en las siguientes regiones: Este de Australia, Este de Japón y Sur de Reino Unido.
  • 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.
  • La configuración con redundancia de zona solo está disponible en SQL Database cuando se selecciona hardware de Gen5. La configuración con redundancia de zona está actualmente en versión preliminar para SQL Managed Instance y solo está disponible para el nivel de servicio Crítico para la empresa.

Disponibilidad con redundancia local de los niveles de servicio Premium y Crítico para la empresa

Los niveles de servicio Prémium y crítico para la empresa usan el modelo de disponibilidad Prémium, que integra recursos de proceso (proceso de sqlservr.exe) y almacenamiento (SSD conectado localmente) en un único nodo. Para conseguir alta disponibilidad se replica el proceso y el almacenamiento en nodos adicionales a fin de crear un clúster formado por tres o cuatro nodos.

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. El nodo principal inserta constantemente los cambios en los nodos secundarios en orden y garantiza que los datos se conservan en al menos una réplica secundaria antes de confirmar cada transacción. Este proceso garantiza que si el nodo principal se bloquea por cualquier motivo, siempre hay un nodo totalmente sincronizado al que conmutar por error. La conmutación por error se inicia en Azure Service Fabric. Una vez que la réplica secundaria se convierte en el nuevo nodo principal, se crea otra réplica secundaria para garantizar que el clúster tiene suficientes nodos (conjunto de quórum). Cuando finaliza la conmutación por error, las conexiones de Azure SQL se redirigen automáticamente al nuevo nodo principal.

Como ventaja adicional, el modelo de disponibilidad prémium 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 de los niveles de servicio Premium y Crítico para la empresa

De forma predeterminada, el clúster de nodos del modelo de disponibilidad premium se crea en el mismo centro de datos. Con la incorporación de Azure Availability Zones, SQL Database puede colocar diferentes réplicas de la base de datos de nivel Crítico para la empresa en diferentes zonas de disponibilidad de la misma región. 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). Como la configuración de redundancia de zona de los niveles de servicio Premium y Crítico para la empresa no crean redundancia adicional de base de datos, puede habilitarla sin costo adicional. Si selecciona una configuración de redundancia de zona, puede hacer que las bases de datos de los niveles premium o crítico para la empresa 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 grupo o base de datos existente del nivel Premium o Crítico para la empresa.

Como las bases de datos 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 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 nivel de servicio. Al final del proceso, la base de datos o el grupo se migra desde un anillo con redundancia de zona a un anillo de zona única, o viceversa.

Importante

Actualmente, esta característica está disponible en versión preliminar para SQL Managed Instance. En SQL Database, cuando se usa el nivel Crítico para la empresa, la configuración de redundancia de zona solo está disponible cuando se selecciona el hardware de serie estándar (Gen5). Para información actualizada sobre las regiones que admiten bases de datos con redundancia de zona, consulte Soporte técnico de servicios por región.

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.

  • Esta característica está actualmente en versión preliminar para SQL Managed Instance y solo está disponible en el nivel de servicio Crítico para la empresa. En SQL Database, cuando se usa el nivel Crítico para la empresa, la configuración de redundancia de zona solo está disponible cuando se selecciona el hardware Gen5. Para información actualizada sobre las regiones que admiten bases de datos 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.

Importante

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.

Durante la versión preliminar, la redundancia de zona para SQL Managed Instance está disponible en el nivel de servicio Crítico para la empresa y se admite en las siguientes regiones:

Geography Regiones que admiten redundancia de zona para el nivel de servicio Crítico para la empresa
Europa, Oriente Medio, África Norte de Europa, Este de Noruega, Norte de Sudáfrica, Centro de Suecia, Norte de Suiza, Oeste de Europa, Norte de Emiratos Árabes Unidos, Sur de Reino Unido
América Sur de Brasil, Centro de Canadá, Este de EE. UU., Centro y Sur de EE. UU., Oeste de EE. UU. 3
Asia Pacífico Este de Australia, Este de Asia, Centro de la India, Este de Japón, Centro de Corea del Sur

Disponibilidad con redundancia local del nivel de servicio Hiperescala

La arquitectura de nivel de servicio de hiperescala se describe en Arquitectura de funciones distribuidas y solo está disponible actualmente para SQL Database, no para Instancia administrada de SQL.

Diagrama que muestra la arquitectura funcional de Hiperescala.

El modelo de disponibilidad de Hiperescala incluye cuatro capas:

  • Una capa de proceso sin estado que ejecuta los procesos sqlservr.exe y que solo contiene datos transitorios y almacenados en caché, como la memoria caché RBPEX sin cobertura, tempdb y model, etc. en la memoria SSD conectada, la memoria caché de planes, el grupo de búferes y el grupo de almacén de columnas en memoria. Esta capa sin estado incluye la réplica de proceso principal y, opcionalmente, un número de réplicas de proceso secundarias que pueden servir como destinos de conmutación por error.
  • Una capa de almacenamiento sin estado formada por servidores de páginas. Esta capa es el motor de almacenamiento distribuido para los procesos sqlservr.exe que se ejecutan en las réplicas de proceso. Cada servidor de páginas solo contiene datos transitorios y almacenados en caché, como la memoria caché de RBPEX de cobertura en la SSD conectada y las páginas de datos almacenadas en memoria caché. Cada servidor de páginas tiene un servidor de páginas emparejadas en una configuración activa-activa para proporcionar equilibrio de carga, redundancia y una alta disponibilidad.
  • Una capa de almacenamiento de registro de transacciones con estado formada por el nodo de proceso que ejecuta el proceso de servicio de registro, la zona de entrada del registro de transacciones y el almacenamiento a largo plazo del registro de transacciones. La zona de aterrizaje y el almacenamiento a largo plazo usan Azure Storage, que proporciona disponibilidad y redundancia para el registro de transacciones, lo que garantiza la durabilidad de los datos para las transacciones confirmadas.
  • Una capa de almacenamiento de datos con estado con los archivos de base de datos (.mdf/.ndf) que se almacenan en Azure Storage y que los servidores de páginas actualizan. Esta capa utiliza las características de disponibilidad de datos y redundancia de Azure Storage. Garantiza que todas las páginas de un archivo de datos se conserven aunque se bloqueen los procesos de otras capas de la arquitectura de Hiperescala o si se produzca un error en los nodos de proceso.

Los nodos de proceso de todas las capas de Hiperescala se ejecutan en Azure Service Fabric, que controla el estado de cada nodo y realiza conmutaciones por error en los nodos correctos disponibles según sea necesario.

Para más información sobre la alta disponibilidad en Hiperescala, consulte Alta disponibilidad de base de datos en Hiperescala.

Disponibilidad con redundancia de zona del nivel de servicio Hiperescala

La habilitación de esta configuración garantiza la resistencia de nivel de zona a través de la replicación en Availability Zones para todas las capas de Hiperescala. Al seleccionar la redundancia de zona, puede hacer que las bases de datos de Hiperescala sean capaces de resistir 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. Todas las regiones de Azure que tienen Availability Zones admiten la base de datos hiperescala con redundancia de zona.

Tenga en cuenta las limitaciones siguientes:

  • La configuración con redundancia de zona solo se puede especificar durante la creación de la base de datos. Esta configuración no se puede modificar una vez aprovisionado el recurso. Use Copia de base de datos o restauración a un momento dado, o cree una réplica geográfica para actualizar la configuración con redundancia de zona para una base de datos de Hiperescala existente. Al usar una de las opciones de actualización, si la base de datos de destino se encuentra en una región diferente a la del origen, o si la redundancia del almacenamiento de copia de seguridad de base de datos del destino difiere de la base de datos de origen, la operación de copia será una operación del tamaño de los datos.
  • Solo se admite hardware de la serie estándar (Gen5).
  • Las réplicas mencionadas no se admiten actualmente.
  • Actualmente, no se puede especificar la redundancia de zona al migrar una base de datos existente desde otro nivel de servicio de Azure SQL Database a Hiperescala.
  • Se requiere al menos una réplica de proceso de alta disponibilidad y el uso del almacenamiento de copia de seguridad con redundancia de zona o geográfica para habilitar la configuración con redundancia de zona para Hiperescala.

Importante

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.

Creación de una base de datos de Hiperescala con redundancia de zona

Use Azure PowerShell o la CLI de Azure para crear una base de datos de Hiperescala con redundancia de zona. Confirme que tiene la versión más reciente de la API para garantizar la compatibilidad con los cambios recientes.

Especifique el parámetro -ZoneRedundant para habilitar la redundancia de zona para la base de datos de Hiperescala mediante Azure PowerShell. La base de datos debe tener al menos una réplica de alta disponibilidad y se debe especificar el almacenamiento de copia de seguridad con redundancia de zona.

Para habilitar la redundancia de zona mediante Azure PowerShell, use el siguiente comando de ejemplo:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone -RequestedServiceObjectiveName HS_Gen5_2'

Creación de una base de datos de Hiperescala con redundancia de zona mediante la creación de una réplica geográfica

Para que una base de datos de Hiperescala existente tenga redundancia de zona, use Azure PowerShell o la CLI de Azure para crear una base de datos de Hiperescala con redundancia de zona mediante la replicación geográfica activa. La réplica geográfica puede estar en la misma región o en una región diferente de la base de datos de Hiperescala existente.

Especifique el parámetro -ZoneRedundant para habilitar la redundancia de zona para la base de datos secundaria de Hiperescala. La base de datos secundaria debe tener al menos una réplica de alta disponibilidad y se debe especificar el almacenamiento de copia de seguridad con redundancia de zona.

Para crear la base de datos con redundancia de zona mediante Azure PowerShell, use el siguiente comando de ejemplo:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

Creación de una base de datos de Hiperescala con redundancia de zona mediante la creación de una copia de la base de datos

Para que una base de datos de Hiperescala existente tenga redundancia de zona, use Azure PowerShell o la CLI de Azure para crear una base de datos de Hiperescala con redundancia de zona mediante una copia de la base de datos. Esta copia puede estar en la misma región o en una región diferente de la base de datos de Hiperescala existente.

Especifique el parámetro -ZoneRedundant para habilitar la redundancia de zona para copia de la base de datos de Hiperescala. La copia de la base de datos debe tener al menos una réplica de alta disponibilidad y se debe especificar el almacenamiento de copia de seguridad con redundancia de zona.

Para crear la base de datos con redundancia de zona mediante Azure PowerShell, use el siguiente comando de ejemplo:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone

Disponibilidad con redundancia de zona de la base de datos master

En Azure SQL Database, un servidor es una construcción lógica que actúa como punto administrativo central para una colección de bases de datos. En el nivel de servidor, puede administrar inicios de sesión, autenticación de Azure Active Directory, reglas de firewall, reglas de auditoría, directivas de detección de amenazas y grupos de conmutación por error automática. Los datos relacionados con algunas de estas características, como inicios de sesión y reglas de firewall, se almacenan en la base de datos master. De forma similar, los datos de algunas DMV, por ejemplo , sys.resource_stats, también se almacenan en la base de datos master.

Cuando se crea una base de datos con una configuración con redundancia de zona en un servidor lógico, la base de datos master asociada al servidor también se convierte automáticamente en redundancia de zona. Esto garantiza que, en una interrupción zonal, las aplicaciones que usan la base de datos no se ven afectadas porque las características que dependen de la base de datos master, como inicios de sesión y reglas de firewall, siguen estando disponibles. Hacer que la redundancia de zona de base de datos master sea un proceso asincrónico y tardará algún tiempo en finalizar en segundo plano.

Cuando ninguna de las bases de datos de un servidor tiene redundancia de zona o cuando se crea un servidor vacío, la base de datos master asociada al servidor no tiene redundancia de zona.

Puede usar Azure PowerShell o la CLI de Azure o la API REST para comprobar la ZoneRedundant propiedad de la base de datos master:

Use el siguiente comando de ejemplo para comprobar el valor de la propiedad "ZoneRedundant" de la base de datos master.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Recuperación de base de datos acelerada (ADR)

Recuperación acelerada de la base de datos (ADR) es una característica del motor de base de datos que mejora considerablemente la disponibilidad de la base de datos, en especial en presencia de transacciones de larga duración. ADR están disponible actualmente para Azure SQL Database, Azure SQL Managed Instance y Azure Synapse Analytics.

Prueba de la resistencia a errores de la aplicación

La alta disponibilidad es una parte fundamental de la plataforma SQL Database e Instancia administrada de SQL 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 base de datos, un grupo elástico o una instancia administrada. En el caso de una base de datos de propósito general aprovisionada o sin servidor con redundancia de zona o un grupo elástico, 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. Como 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 base de datos, grupo elástico o instancia administrada.

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

Tipo de implementación PowerShell API DE REST Azure CLI
Base de datos Invoke-AzSqlDatabaseFailover Conmutación por error de la base de datos az rest se puede usar para invocar una llamada a la API REST desde la CLI de Azure.
Grupo elástico Invoke-AzSqlElasticPoolFailover Conmutación por error del grupo elástico az rest se puede usar para invocar una llamada a la API REST desde la CLI de Azure.
Instancia administrada de SQL 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.

Importante

El comando de conmutación por error no está disponible para las réplicas secundarias legibles de las bases de datos de hiperescala.

Conclusión

Azure SQL Database y Azure SQL Managed Instance presentan una solución de alta disponibilidad incorporada, que está totalmente integrada con la plataforma de Azure. Depende de Service Fabric para la detección y la recuperación de errores, de Azure Blob Storage para la protección de datos y de Availability Zones para la mayor tolerancia a errores (como ya se ha mencionado en el documento, aún no es aplicable a Azure SQL Managed Instance). Al mismo tiempo, SQL Database e Instancia administrada de SQL usan la tecnología de grupo de disponibilidad Always On de la instancia de SQL Server para la replicación y la conmutación por error. La combinación de estas tecnologías permite que las aplicaciones obtengan todos los beneficios de un modelo de almacenamiento mixto y puedan admitir los SLA más exigentes.

Pasos siguientes