Los grupos de alta disponibilidad Always On son probablemente la herramienta más potente que el SQL Server tiene y creo que deberían ser la primera opción para cualquier empresa que quiera añadir este tipo de configuración para sus servidores. Cómo es algo sencillo de entender, pero muy complicado de masterizar, he pensado que este post podría ayudar mucho.
Qué es Always On en SQL Server
SQL Server Always On Availability Groups utiliza instancias de SQL Server con su propio almacenamiento dedicado (sin almacenamiento compartido entre servidores). Esto significa que hay múltiples copias de los datos, y los cambios en esos datos se replican a todos los nodos del clúster mediante Always On.
- Las transacciones se replican a medida que se confirman, por lo que no hay dependencia temporal en funciones como las copias de seguridad del registro de transacciones.
- Las bases de datos se agrupan en un solo Availability Group (AG). El AG se «mueve» en bloque cada vez que ocurre un failover, por lo que las bases de datos siempre estarán accesibles en el mismo nodo.
- Este grupo puede configurarse con un listener, un nombre de red virtual que siempre apunta al nodo primario del AG, permitiendo que la cadena de conexión que apunta a este listener siempre encuentre el nodo primario.
- Always On replica a nivel de base de datos, pero no a nivel de servidor, por lo que cosas como los logins o los jobs del SQL Agent deben ser replicados a mano (o automatizar los procesos).
Nota: En un clúster de múltiples subredes, se debe configurar una dirección en cada subred en el listener para que funcione correctamente.
Modos de Confirmación (commit) en Always On
- Synchronous commit: Este modo de confirmación asegura que las transacciones se graben en disco en ambos lados. La ubicación geográfica y la red local ayudan a minimizar cualquier latencia de transacción que este modo de confirmación pueda introducir.
- Asynchronous commit: Las transacciones se grabarán por separado en los distintos nodel del AG, por lo tanto existe un mayor riesgo de pérdida de datos en caso de sufrir un failover no esperado, pero esto minimiza cualquier latencia transaccional potencial causada por la separación geográfica de los nodos.
Cifrado y Encriptación en Always On
SQL Server Transparent Data Encryption (TDE) proporciona cifrado de datos en reposo, es decir, siempre que se almacenen en disco, ya sea en un archivo de datos, un archivo de registro, una copia de seguridad o en TempDB. Para que TDE funcione en un clúster, todas las claves y certificados de cifrado a nivel de base de datos deben ser idénticos. Las dos claves a nivel de servidor, la Service Master Key y la Database Master Key, son únicas por instancia y no deben copiarse entre instancias.
La forma más sencilla de implementar TDE en bases de datos en un AG es tener todas las bases de datos en los AGs previamente, crear y distribuir las claves y certificados de cifrado a nivel de base de datos, y luego cifrar los datos. Ese comando de cifrado se replicará a través del clúster y usará los certificados de cifrado copiados.
Si las bases de datos están cifradas antes de configurar el AG, entonces las claves y los certificados deben copiarse a todos los nodos del clúster, pero la base de datos debe agregarse al AG manualmente en lugar de utilizar el asistente (lo cual es un coñazo histórico).
Replicación de SQL Server en Always On
La replicación es una tecnología (antigua en mi opinión) proporcionada por SQL Server para permitir la replicación de los datos en una base de datos hacia otras bases de datos. Es un tecnología que no está preparada para funcionar dentro de un AG de forma nativa, pero puede configurarse para ello. Este es un proceso manual documentado por Microsoft que se basa fundamentalmente en la publicación utilizando un distribuidor remoto en lugar de uno local. Lamentablemente mucha gente usa replicación asi que es bastante posible que necesiteis aprender a hacer esto.
Aquí tenéis la documentación oficial porque sabe dios que yo no tengo ganas de hacerlo: Configurar la replicación para Always On Availability Groups en SQL Server.
SQL Server Reporting Services (SSRS) en Always On
SSRS es otra aplicación proporcionada por SQL Server que no está preparada para trabajar con clústeres de forma nativa. Sin embargo, puede configurarse para trabajar con Always On, normalmente asegurando que todas las fuentes de datos apunten al nombre del listener en sus cadenas de conexión. Los failovers pueden requerir trabajo manual adicional para asegurar que el servidor SSRS solo esté en funcionamiento en el nodo principal (basicamente que el servicio del SSRS sólo esté activo en el nodo primario).
- Las bases de datos de SSRS utilizan cifrado, por lo que su certificado de cifrado deberá exportarse y copiarse en todos los nodos del clúster para permitir que esas bases de datos se agreguen al AG.
- Los informes desplegados deberán sincronizarse manualmente entre los nodos del clúster, sea cual sea la opción de despliegue elegida. Existe un módulo de PowerShell (ReportingServicesTools) que simplifica esto y es especialmente útil para la primera vez que se configura SSRS en Always On cuando muchos informes requieren sincronización.
Más información: Utilizar SSRS con AOAGs en SQL Server.
SQL Server Integration Services (SSIS) en Always On
SSIS se ha actualizado para hacerlo más compatible con Always On. Sin embargo, hay algunas advertencias sobre este proceso que requieren atención. SSIS utiliza cifrado interno y una contraseña para asegurar su contenido que necesitareis a la hora de hacer la configuración. Microsoft ha agregado funcionalidades adicionales para hacer este proceso menos tedioso.
Más información: Detalles sobre SSIS y AOAGs.
SQL Agent, Logins y Usuarios en Always On
Always On solo sincroniza a nivel de base de datos, por lo tanto, no sincronizará los logins del servidor, ni los jobs del SQL Agent o sus configuraciones.
El problema es que la información sobre los logins y los jobs está en las bases de datos master y msdb, y como son bases de datos del sistema, no pueden agregarse a un AG. Se deben implementar otros procesos para garantizar que estos elementos permanezcan sincronizados en los nodos del clúster.
Esto podría hacerse de forma manual para asegurar que los cambios se implementen en todos los nodos del clúster, pero también existe un módulo de PowerShell llamado «dbatools» que ayuda muchisimo con este proceso. Este módulo de PowerShell proporciona funciones para copiar los logins conservando su SID y contraseñas. También proporciona funciones para copiar jobs del SQL Agent o incluso el SQL Agent entero. Lo más típico es automátizar estos procesos para que se ejecuten cada X tiempo y así garantizar que la sincronización ocurre habitualmente.
Backups en Always On
Always On, permite realizar copias de seguridad en cualquiera de los nodos, pero esto es algo que debe configurarse teniendo en cuenta nuestras necesidades.
Linked Servers en Always On
Los Linked Server deben crearse en cada nodo por separado, pero utilizando los mismos nombres para que su uso sea transparente para los usuarios o aplicaciones.
Función para Detectar el Nodo Primario de un Always On
Para ayudar con los jobs que se ejecutan en los diferentes nodos del AG, Microsoft ha creado una función que cuando se invoca devuelve si el nodo actual es primario o secundario. Esto permite que los jobs que ejecutan esta función decidan si continuar ejecutándose o no dependiendo de el rol de ese servidor actualmente. Esta función también se puede usar en un job del SQL Agent que active o desactive jobs según el estado del nodo.
Más información: Función sys.fn.hadr.is_primary_replica en T-SQL.
Beneficios de la Edición Enterprise para Always On
Una pregunta común es sobre los beneficios comparativos de la Edición Enterprise (EE) sobre la Edición Standard (SE). EE suele costar aproximadamente 3.5 veces más por núcleo que SE, sin embargo, otorga acceso a lo siguiente:
- Funcionalidad HADR: Acceso a Always On AGs y clústeres FCI con más de 2 nodos. SE solo permite acceso a clústeres FCI de 2 nodos.
- Software Assurance (SA): solo está disponible para propietarios de la Edición Enterprise. Otorga acceso mejorado a la asistencia técnica de Microsoft, movilidad de licencias con costos reducidos para algunos nodos en una configuración HADR, la capacidad de realizar múltiples failovers al mes, la capacidad de transferir licencias al actualizar la versión de SQL Server e incluso cubre la licencia de un nodo extra para DR en Azure. También incluye acceso a herramientas de informes PowerBI.
- Otorga acceso a funcionalidades mejoradas dentro de SQL Server como la reconstrucción de índices en línea, recuperación rápida, gobernador de recursos y funcionalidades de base de datos inteligente.
La lista completa de diferencias se puede encontrar aquí: Comparación de Ediciones y Componentes de SQL Server.
Si habeis llegado hasta aquí espero que este post haya servidor su propósito (y quizás deberias pensar en poneros a currar que llevareis aquí un ratito)