Alta disponibilidad por nivel de servicio
Para comprender las opciones y funciones de disponibilidad de Azure SQL, debe entender los niveles de servicio. El nivel de servicio que seleccione determinará la arquitectura subyacente de la base de datos o instancia administrada que implemente.
Hay dos modelos de compra que se deben tener en cuenta: DTU y núcleo virtual. Esta unidad se centrará en los niveles de servicio de núcleo virtual y sus arquitecturas para lograr alta disponibilidad. Puede equiparar los niveles Básico y Estándar del modelo de DTU a De uso general, y sus niveles Premium a Crítico para la empresa.
De uso general
Las bases de datos y las instancias administradas en el nivel de servicio De uso general tienen la misma arquitectura de disponibilidad. Con la imagen siguiente como guía, tenga en cuenta en primer lugar la aplicación y el anillo de control. La aplicación se conecta al nombre del servidor, que luego se conecta a una puerta de enlace (GW), que apunta la conexión de la aplicación al servidor correcto, que se ejecuta en una máquina virtual. Con De uso general, la réplica principal usa un disco SSD conectado localmente para tempdb. Los archivos de datos y de registro se almacenan en Azure Premium Storage, que es el almacenamiento con redundancia local (varias copias en una región). Los archivos de copia de seguridad se almacenan en Azure Standard Storage, que, de forma predeterminada, es RA-GRS. RA-GRS es un almacenamiento con redundancia global con copias en varias regiones.
Como se ha descrito en un módulo anterior de esta ruta de aprendizaje, la totalidad de Azure SQL se basa en Azure Service Fabric, que actúa como la columna vertebral de Azure. Si Azure Service Fabric determina que es necesario realizar una conmutación por error, será similar a la de una instancia de clúster de conmutación por error (FCI). Service Fabric buscará un nodo con capacidad de reserva y pondrá en marcha una nueva instancia de SQL Server. Después, se conectarán los archivos de base de datos, se ejecutará la recuperación y se actualizarán las puertas de enlace para que las aplicaciones señalen al nuevo nodo. No se necesitan redes virtuales, clientes de escucha ni actualizaciones. Es una funcionalidad integrada.
Crítico para la empresa
El siguiente nivel de servicio que tener en cuenta es Crítico para la empresa, que generalmente consigue el máximo rendimiento y la disponibilidad de todos los niveles de servicio de Azure SQL (De uso general, Hiperescala y Crítico para la empresa). Crítico para la empresa está pensado para aplicaciones críticas que necesitan una latencia baja y un tiempo de inactividad mínimo.
El uso de Crítico para la empresa es similar a la implementación de un grupo de disponibilidad (AG) Always On en segundo plano. A diferencia del nivel De uso general, los archivos de datos y de registro de Crítico para la empresa se ejecutan en un disco SSD conectado directamente, lo que reduce significativamente la latencia de red. (En De uso general se usa almacenamiento remoto). En este grupo de disponibilidad hay tres réplicas secundarias. Puede usar uno de ellos como punto de conexión de solo lectura (sin cargo adicional). Una transacción puede completar una confirmación cuando al menos una de las réplicas secundarias ha protegido el cambio de su registro de transacciones.
El escalado horizontal de lectura con una de las réplicas secundarias admite la coherencia de nivel de sesión, por lo que si la sesión de solo lectura se vuelve a conectar después de un error de conexión causado por la falta de disponibilidad de la réplica, podría redirigirse a una réplica que no está 100 % actualizada con la réplica de lectura y escritura. Del mismo modo, si una aplicación escribe datos mediante una sesión de lectura y escritura, y los lee inmediatamente con una sesión de solo lectura, es posible que las actualizaciones más recientes no estén visibles de inmediato en la réplica. La latencia se debe a una operación de fase de puesta al día del registro de transacciones asincrónica.
Si se produce algún tipo de error y Service Fabric determina que es necesaria una conmutación por error, la conmutación por error a una réplica secundaria es rápida porque ya existe y tiene los datos conectados. En una conmutación por error, no necesita un cliente de escucha. La puerta de enlace redirige la conexión a la principal, incluso después de una conmutación por error. Este cambio se produce rápidamente y, después, Service Fabric se encarga de desarrollar otra réplica secundaria.
Hiperescala
El nivel de servicio Hiperescala solo está disponible en Azure SQL Database. Este nivel de servicio tiene una arquitectura única porque emplea una capa por niveles de servidores de páginas y cachés para expandir la posibilidad de acceder rápidamente a páginas de bases de datos sin tener que acceder directamente al archivo de datos.
Como en esta arquitectura se usan servidores de páginas emparejados, se puede escalar horizontalmente para colocar todos los datos en capas de almacenamiento en caché. Esta nueva arquitectura también permite que Hiperescala admita bases de datos de hasta 100 TB. Como usa instantáneas, se pueden realizar copias de seguridad de base de datos casi instantáneas con independencia del tamaño. Las restauraciones de bases de datos tardan minutos, en lugar de horas o días. También puede escalar o reducir verticalmente en tiempo constante para acomodar las cargas de trabajo.
Otro aspecto interesante es cómo se ha diseñado el servicio de registro en esta arquitectura. El servicio de registro se usa para alimentar las réplicas y los servidores de páginas. Las transacciones se pueden confirmar cuando el servicio de registro se contrae en la zona de aterrizaje, lo que significa que no es necesario el consumo de los cambios por parte de una réplica de proceso secundaria para una confirmación. A diferencia de otros niveles de servicio, puede determinar si quiere réplicas secundarias. Puede configurar de cero a cuatro réplicas secundarias, que se pueden usar todas en el escalado de lectura.
Al igual que los demás niveles de servicio, se producirá una conmutación automática por error si Service Fabric determina que se necesita, pero el tiempo de recuperación dependerá de la existencia de réplicas secundarias. Por ejemplo, si no tiene réplicas y se produce una conmutación por error, el escenario será similar al del nivel de servicio De uso general: Service Fabric primero debe encontrar capacidad de reserva. Si tiene una o más réplicas, la recuperación es más rápida y se alinea más estrechamente a la del nivel de servicio Crítico para la empresa.
Crítico para la empresa mantiene el mayor rendimiento y disponibilidad para cargas de trabajo con pequeñas escrituras de registro que necesitan baja latencia, pero el nivel de servicio Hiperescala permite obtener un mayor rendimiento de registro en términos de MB/segundo, proporciona los tamaños de base de datos más grandes y proporciona hasta cuatro réplicas secundarias para niveles más altos de escala de lectura. Por tanto, deberá tener en cuenta la carga de trabajo al elegir entre los dos.