Ir más lejos con la disponibilidad
Azure SQL Database y Azure SQL Managed Instance ofrecen excelentes opciones de disponibilidad de forma predeterminada en los distintos niveles de servicio. Puede hacer otras cosas para aumentar o modificar la disponibilidad de las bases de datos o instancias. Podrá ver directamente el impacto en el Acuerdo de Nivel de Servicio (SLA). En esta unidad, verá cómo puede avanzar con diversas opciones de disponibilidad en Azure SQL.
Availability Zones
En el nivel Crítico para la empresa de Azure SQL Database, puede optar por recibir una configuración con redundancia de zona (sin costo adicional) si se admite en la región. En un nivel general, el grupo de disponibilidad (AG) Always On que subyace a las bases de datos y las instancias administradas del nivel Crítico para la empresa se implementa en tres zonas de disponibilidad dentro de una región. Una zona de disponibilidad es básicamente un centro de datos independiente dentro de una región concreta. Siempre hay una separación física entre zonas de disponibilidad. Esta funcionalidad protege frente a errores catastróficos que podrían producirse en una región de un centro de datos.
Desde el punto de vista del rendimiento, es posible que haya un pequeño aumento en la latencia de red, ya que ahora el grupo de disponibilidad se distribuye entre los centros de datos entre los que ya hay cierta distancia. Por esta razón, Availability Zones no se activa de forma predeterminada. Puede optar por usar lo que normalmente se conoce como implementación "AZ múltiple" o "AZ único". Para configurar esta opción solo tiene que agregar un parámetro a un comando de PowerShell o de la CLI de Azure, o bien activar una casilla en Azure Portal.
Las zonas de disponibilidad son relativamente nuevas en Azure SQL, por lo que actualmente solo están disponibles en regiones y niveles de servicio determinados. Con el tiempo, es probable que esta funcionalidad se admita en más regiones y, potencialmente, en más niveles de servicio. Por ejemplo, el nivel De uso general para Azure SQL Database publicó recientemente una versión de vista previa para la implementación "AZ múltiple".
Acuerdo de Nivel de Servicio de Azure SQL
Azure SQL mantiene un Acuerdo de Nivel de Servicio (SLA) que proporciona respaldo financiero al compromiso de alcanzar y mantener los niveles de servicio. Si el nivel de servicio no se alcanza y mantiene tal y como se describe en el Acuerdo de Nivel de Servicio, es posible que cumpla los requisitos para obtener un crédito por una parte de las tarifas de servicio mensuales.
Actualmente, se puede obtener la mayor disponibilidad (99,995 %) de una implementación de nivel Crítico para la empresa de Azure SQL Database con configuración de Availability Zones. El nivel Crítico para la empresa es la única opción del sector que proporciona acuerdos de nivel de servicio de RPO y RTO de 5 y 30 segundos, respectivamente.
- RPO son las siglas de Objetivo de punto de recuperación. Representa la cantidad de datos que podría llegar a perder en el peor de los escenarios.
- RTO son las siglas de Objetivo de tiempo de recuperación. Representa cuánto tiempo se tarda en recuperar si se produce un desastre.
En el caso de las implementaciones de Azure SQL Database o Azure SQL Managed Instance de los tipos De uso general o Crítico para la empresa de zona única, el SLA es del 99,99 %.
El Acuerdo de Nivel de Servicio del nivel Hiperescala depende del número de réplicas. Recuerde que en Hiperescala elige el número de réplicas que tiene. Si no tiene ninguna, el comportamiento de la conmutación por error es más parecido al del nivel De uso general. Si tiene réplicas, el comportamiento de la conmutación por error es más similar a la del nivel Crítico para la empresa. Estos son los SLA, en función del número de réplicas:
- 0 réplicas: 99,5 %
- 1 réplica: 99,9 %
- 2 o más réplicas: 99,99 %
Replicación geográfica y grupos de conmutación por error automática
Después de elegir un nivel de servicio (y considerar las zonas de disponibilidad si corresponde), hay otras opciones para obtener la escala de lectura o la capacidad de conmutar por error a otra región: replicación geográfica y grupos de conmutación por error automática. En una instancia local de SQL Server, la configuración de cualquiera de estas opciones es algo que llevaría mucho planeamiento, coordinación y tiempo.
La nube y, en concreto, Azure SQL, han facilitado este proceso. Los grupos de replicación geográfica y de conmutación por error automática se pueden configurar con unos pocos clics en Azure Portal, o bien con unos cuantos comandos en PowerShell o la CLI de Azure.
Hay algunas consideraciones para ayudarle a decidir si la replicación geográfica o los grupos de conmutación por error automática son los mejores para el escenario:
| Características | Replicación geográfica | Grupos de conmutación por error |
|---|---|---|
| Conmutación por error automática | No | Sí |
| Conmutación por error de varias bases de datos simultáneamente | No | Sí |
| El usuario debe actualizar la cadena de conexión tras la conmutación por error | Sí | No |
| Compatibilidad con Instancia administrada de SQL | No | Sí |
| Posibilidad de estar en la misma región que la principal | Sí | No |
| Varias réplicas | Sí | No |
| Admisión del escalado de lectura | Sí | Sí |