Configuración de un grupo de disponibilidad AlwaysOn de SQL Server para alta disponibilidad en Linux

  • Artículo

Se aplica a:SQL Server: Linux

En este artículo se explica cómo crear un grupo de disponibilidad Always On de SQL Server para alta disponibilidad en Linux. Hay dos tipos de configuración de grupos de disponibilidad. Una configuración de alta disponibilidad usa un administrador de clústeres para proporcionar continuidad empresarial. Esta configuración también puede incluir réplicas de escalado de lectura. En este documento se explica cómo crear un grupo de disponibilidad para alta disponibilidad.

También puede crear un grupo de disponibilidad sin un administrador de clústeres para el escalado de lectura. El grupo de disponibilidad para escalado de lectura proporciona únicamente réplicas de solo lectura para el escalado horizontal del rendimiento. No proporciona alta disponibilidad. Para crear un grupo de disponibilidad para escalado de lectura, vea Configuración de un grupo de disponibilidad de SQL Server para escalado de lectura en Linux.

Las configuraciones que garantizan una alta disponibilidad y la protección de los datos requieren dos o tres réplicas de confirmación sincrónicas. Con tres réplicas sincrónicas, el grupo de disponibilidad puede recuperarse automáticamente incluso cuando un servidor no esté disponible. Para más información, vea Alta disponibilidad y protección de datos para las configuraciones de grupo de disponibilidad.

Todos los servidores deben ser físicos o virtuales, y los servidores virtuales deben estar en la misma plataforma de virtualización. Este requisito se debe a que los agentes de barrera son específicos de la plataforma. Vea Directivas de clústeres invitados.

Plan de desarrollo

Los pasos necesarios para crear un grupo de disponibilidad en servidores Linux de alta disponibilidad son diferentes a los de un clúster de conmutación por error de Windows Server. En la lista siguiente, se describen los pasos generales:

  1. Guía de instalación de SQL Server en Linux.

    Importante

    Los tres servidores del grupo de disponibilidad deben estar en la misma plataforma (física o virtual), ya que la alta disponibilidad de Linux usa agentes de barrera para aislar los recursos en los servidores. Los agentes de barrera son específicos de cada plataforma.

  2. Cree el grupo de disponibilidad (AG). Este paso se explica en este mismo artículo.

  3. Configure un administrador de recursos de clúster, como Pacemaker.

    La manera de configurar un administrador de recursos de clúster depende de la distribución específica de Linux. Vea los siguientes vínculos para obtener instrucciones específicas de cada distribución:

    Importante

    Para alcanzar una alta disponibilidad, los entornos de producción necesitan un agente de barrera. En los ejemplos de este artículo no se usan agentes de barrera. Solo se admiten para pruebas y validación.

    Un clúster de Pacemaker usa barreras para devolver el clúster a un estado conocido. La forma de configurar las barreras depende de la distribución y del entorno. Actualmente, las barreras no están disponibles en algunos entornos de nube. Para más información, vea Directivas de soporte para clústeres de alta disponibilidad de RHEL: plataformas de virtualización.

    Para más información sobre SLES, vea Extensión de alta disponibilidad de SUSE Linux Enterprise.

  4. Agregue el grupo de disponibilidad como un recurso en el clúster.

    La forma en que se agregue el grupo de disponibilidad como un recurso en el clúster depende de la distribución de Linux. Vea los siguientes vínculos para obtener instrucciones específicas de cada distribución:

Consideraciones para varias interfaces de red (NIC)

Para obtener información sobre cómo configurar un grupo de disponibilidad para servidores con varias NIC, consulte las secciones pertinentes para:

Requisitos previos

Antes de crear el grupo de disponibilidad, debe:

  • Establecer el entorno de forma que todos los servidores que hospedarán las réplicas de disponibilidad se puedan comunicar.
  • Instale SQL Server.

Nota:

En Linux, debe crear un grupo de disponibilidad antes de agregarlo como un recurso de clúster para que lo administre el clúster. En este documento, se proporciona un ejemplo que crea el grupo de disponibilidad. Para obtener instrucciones específicas de la distribución sobre cómo crear el clúster y agregar el grupo de disponibilidad como recurso del clúster, consulte los vínculos en "Pasos siguientes".

  1. Actualice el nombre de equipo de cada host.

    Cada nombre de SQL Server debe cumplir con los siguientes requisitos:

    • 15 caracteres o menos.
    • Debe ser único en la red.

    Para establecer el nombre del equipo, edite /etc/hostname. El siguiente script le permite editar /etc/hostname con vi:

    sudo vi /etc/hostname

  2. Configure el archivo de hosts.

    Nota

    Si los nombres de host están registrados con su dirección IP en el servidor DNS, no hay que realizar los pasos siguientes. Compruebe que todos los nodos destinados a formar parte de la configuración del grupo de disponibilidad pueden comunicarse entre sí. (Un ping al nombre de host debe responder con la dirección IP correspondiente). Además, asegúrese de que el archivo /etc/hosts no contiene ningún registro que asigne la dirección IP de localhost 127.0.0.1 con el nombre de host del nodo.

    El archivo de hosts de cada servidor contiene las direcciones IP y los nombres de todos los servidores que participarán en el grupo de disponibilidad.

    El comando siguiente devuelve la dirección IP del servidor actual:

    sudo ip addr show

    Actualice /etc/hosts. El siguiente script le permite editar /etc/hosts con vi:

    sudo vi /etc/hosts

    En el ejemplo siguiente, se muestra /etc/hosts en node1 con adiciones para node1, node2 y node3. En este ejemplo, node1 hace referencia al servidor que hospeda la réplica principal y node2 y node3 hacen referencia a los servidores que hospedan las réplicas secundarias.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
::1          localhost localhost6 localhost6.localdomain6
10.128.18.12 node1
10.128.16.77 node2
10.128.15.33 node3

Instalación de SQL Server

Instale SQL Server. Los siguientes vínculos apuntan a las instrucciones de instalación de SQL Server para varias distribuciones:

Habilitación de los Grupos de disponibilidad AlwaysOn

Habilite los grupos de disponibilidad AlwaysOn en cada nodo en el que se hospede una instancia de SQL Server y, a continuación, reinicie mssql-server. Ejecute el siguiente script:

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server

Habilitar una sesión de eventos AlwaysOn_health

Opcionalmente, puede habilitar los eventos extendidos (XE) para ayudar con el diagnóstico de la causa raíz cuando solucione los problemas de un grupo de disponibilidad. Ejecute el comando siguiente en todas las instancias de SQL Server:

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Para obtener más información sobre esta sesión de XE, vea Configuración de eventos extendidos para grupos de disponibilidad Always On.

Crear un certificado

El servicio SQL Server en Linux usa certificados para autenticar la comunicación entre los puntos de conexión de creación de reflejo.

El script de Transact-SQL siguiente crea una clave maestra y un certificado. Después, realiza una copia de seguridad del certificado y protege el archivo con una clave privada. Actualice el script con contraseñas seguras. Conecte con la instancia de SQL Server principal. Para crear el certificado, ejecute el script siguiente de Transact-SQL:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
   TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
   WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

En este momento, la réplica principal de SQL Server tiene un certificado en /var/opt/mssql/data/dbm_certificate.cer y una clave privada en var/opt/mssql/data/dbm_certificate.pvk. Copie estos dos archivos en la misma ubicación en todos los servidores que hospedarán las réplicas de disponibilidad. Utilice el usuario de mssql o conceda permiso al usuario de mssql para tener acceso a estos archivos.

Por ejemplo, en el servidor de origen, el siguiente comando copia los archivos en el equipo de destino. Reemplace los valores **<node2>** por los nombres de las instancias de SQL Server que hospedarán las réplicas.

cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/

En cada servidor de destino, conceda permiso al usuario de mssql para que acceda al certificado.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Crear el certificado en los servidores secundarios

El script de Transact-SQL siguiente crea una clave maestra y un certificado a partir de la copia de seguridad creada en la réplica principal de SQL Server. Actualice el script con contraseñas seguras. La contraseña de descifrado es la misma que ha usado para crear el archivo .pvk en un paso anterior. Ejecute el siguiente script en todos los servidores secundarios para crear el certificado:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
           FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
           DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
        );

Crear los puntos de conexión de creación de reflejo de la base de datos en todas las réplicas

Los extremos de creación de reflejo de la base de datos usan el Protocolo de control de transmisión (TCP) para enviar y recibir mensajes entre las instancias del servidor que participan en las sesiones de creación de reflejo de la base de datos o que hospedan las réplicas de disponibilidad. El extremo de creación de reflejo de la base de datos escucha en un número de puerto TCP exclusivo.

El script de Transact-SQL siguiente crea un punto de conexión de escucha denominado Hadr_endpoint para el grupo de disponibilidad. Se inicia el punto de conexión y se concede permiso de conexión al certificado que ha creado. Antes de ejecutar el script, reemplace los valores entre **< ... >**. Opcionalmente puede incluir una dirección IP LISTENER_IP = (0.0.0.0). La dirección IP de escucha debe ser una dirección IPv4. También se puede usar 0.0.0.0.

Actualice el script de Transact-SQL siguiente para el entorno en todas las instancias de SQL Server:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Nota

Si usa SQL Server Express Edition en un nodo para hospedar una réplica de solo configuración, el único valor válido para ROLE es WITNESS. Ejecute el siguiente script en SQL Server Express Edition:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

El puerto TCP en el firewall debe estar abierto para el puerto de escucha.

Importante

Para la versión de SQL Server 2017, el único método de autenticación que se admite para el punto de conexión de creación de reflejo de la base de datos es CERTIFICATE. La opción WINDOWS se habilitará en una futura versión.

Para obtener más información, vea El punto de conexión de creación de reflejo de la base de datos (SQL Server).

Crear el grupo de disponibilidad

En los ejemplos de esta sección se explica cómo crear el grupo de disponibilidad mediante Transact-SQL. También puede usar el Asistente para grupo de disponibilidad de SQL Server Management Studio. Al crear un grupo de disponibilidad con el asistente, aparecerá un error cuando una las réplicas al grupo de disponibilidad. Para corregir esto, conceda los permisos ALTER, CONTROL y VIEW DEFINITIONS a la instancia de Pacemaker en el grupo de disponibilidad en todas las réplicas. Una vez concedidos los permisos en la réplica principal, una los nodos al grupo de disponibilidad mediante el asistente, pero, para que la alta disponibilidad funcione correctamente, conceda los permisos en todas las réplicas.

En una configuración de alta disponibilidad que garantice la conmutación por error automática, el grupo de disponibilidad requiere al menos tres réplicas. Cualquiera de las siguientes configuraciones puede admitir la alta disponibilidad:

Para más información, vea Alta disponibilidad y protección de datos para las configuraciones de grupo de disponibilidad.

Nota

Los grupos de disponibilidad pueden incluir más réplicas sincrónicas o asincrónicas.

Cree el grupo de disponibilidad para alta disponibilidad en Linux. Use CREATE AVAILABILITY GROUP con CLUSTER_TYPE = EXTERNAL.

  • Grupo de disponibilidad: CLUSTER_TYPE = EXTERNAL.

    Especifica que una entidad de clúster externa administra el grupo de disponibilidad. Pacemaker es un ejemplo de entidad de clúster externa. Cuando el tipo de clúster del grupo de disponibilidad es externo,

  • Establecer las réplicas principal y secundarias: FAILOVER_MODE = EXTERNAL.

    Especifica que la réplica interactúa con un administrador de clústeres externo, como Pacemaker.

Los siguientes scripts de Transact-SQL crean un grupo de disponibilidad para alta disponibilidad denominado ag1. El script configura las réplicas de grupo de disponibilidad con SEEDING_MODE = AUTOMATIC. Esta configuración hace que SQL Server cree de manera automática la base de datos en todos los servidores secundarios. Actualice el script siguiente para su entorno. Reemplace los valores <node1>, <node2> o <node3> por los nombres de las instancias de SQL Server que hospedan las réplicas. Reemplace el valor <5022> por el puerto que haya definido para el punto de conexión de creación de reflejo de datos. Para crear el grupo de disponibilidad, ejecute el siguiente código de Transact-SQL en la instancia de SQL Server que hospeda la réplica principal.

Importante

En la implementación actual del agente de recursos de SQL Server, el nombre del nodo debe coincidir con la propiedad ServerName de la instancia. Por ejemplo, si el nombre del nodo es node1, asegúrese de que SERVERPROPERTY('ServerName') devuelva node1 en su instancia de SQL Server. En caso de que haya una falta de coincidencia, las réplicas pasarán a un estado de resolución una vez creado el recurso de Pacemaker.

Un escenario en el que esta regla es importante es cuando se usan nombres de dominio completos. Por ejemplo, si usa node1.sudominio.com como nombre del nodo durante la configuración del clúster, asegúrese de que SERVERPROPERTY('ServerName') devuelve node1.sudominio.com y no solo node1. Las posibles soluciones alternativas para este problema son las siguientes:

  • Cambie el nombre de host al FQDN y use sp_dropserver y sp_addserver almacene los procedimientos para asegurarse de que los metadatos de SQL Server coincidan con el cambio.
  • Use la opción addr del comando pcs cluster auth para hacer coincidir el nombre del nodo con el valor SERVERPROPERTY('ServerName') y usar una dirección IP estática como dirección del nodo.

Ejecute solo uno de los siguientes scripts:

Crear un grupo de disponibilidad con tres réplicas sincrónicas

Crear un grupo de disponibilidad con tres réplicas sincrónicas:

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
      FOR REPLICA ON
         N'<node1>'
               WITH (
            ENDPOINT_URL = N'tcp://<node1>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node2>'
         WITH (
            ENDPOINT_URL = N'tcp://<node2>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
         N'<node3>'
         WITH(
            ENDPOINT_URL = N'tcp://<node3>:<5022>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Importante

Después de ejecutar el script anterior para crear un grupo de disponibilidad con tres réplicas sincrónicas, no ejecute el script siguiente:

Crear un grupo de disponibilidad con dos réplicas sincrónicas y una réplica de configuración

Crear un grupo de disponibilidad con dos réplicas sincrónicas y una réplica de configuración:

Importante

Esta arquitectura permite que cualquier edición de SQL Server hospede la tercera réplica. Por ejemplo, la tercera réplica se puede hospedar en SQL Server Express Edition. En Express Edition, el único tipo de punto de conexión válido es WITNESS.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
      N'<node1>' WITH (
         ENDPOINT_URL = N'tcp://<node1>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node2>' WITH (
         ENDPOINT_URL = N'tcp://<node2>:<5022>',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = EXTERNAL,
         SEEDING_MODE = AUTOMATIC
         ),
      N'<node3>' WITH (
         ENDPOINT_URL = N'tcp://<node3>:<5022>',
         AVAILABILITY_MODE = CONFIGURATION_ONLY
         );
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Crear un grupo de disponibilidad con dos réplicas sincrónicas

Crear un grupo de disponibilidad con dos réplicas sincrónicas:

Incluya dos réplicas con el modo de disponibilidad sincrónica. Por ejemplo, el siguiente script crea un grupo de disponibilidad llamado ag1. node1 y node2 hospedan réplicas en modo sincrónico, con propagación y conmutación por error automáticas.

Importante

Ejecute únicamente el siguiente script para crear un grupo de disponibilidad con dos réplicas sincrónicas. No ejecute el siguiente script si ejecutó el script anterior.

CREATE AVAILABILITY GROUP [ag1]
   WITH (CLUSTER_TYPE = EXTERNAL)
   FOR REPLICA ON
   N'node1' WITH (
      ENDPOINT_URL = N'tcp://node1:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   ),
   N'node2' WITH (
      ENDPOINT_URL = N'tcp://node2:5022',
      AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
      FAILOVER_MODE = EXTERNAL,
      SEEDING_MODE = AUTOMATIC
   );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

También puede configurar un grupo de disponibilidad con CLUSTER_TYPE=EXTERNAL en SQL Server Management Studio o PowerShell.

Unión de réplicas secundarias al grupo de disponibilidad

El usuario de Pacemaker requiere los permisos ALTER, CONTROL y VIEW DEFINITION en el grupo de disponibilidad en todas las réplicas. Para conceder estos permisos, una vez creado el grupo de disponibilidad, ejecute el siguiente script de Transact-SQL en la réplica principal y en cada réplica secundaria inmediatamente después de agregarlas a dicho grupo de disponibilidad. Antes de ejecutar el script, reemplace <pacemakerLogin> por el nombre de la cuenta de usuario de Pacemaker. Si no tiene un inicio de sesión de Pacemaker, cree un inicio de sesión de SQL Server para Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

El siguiente script de Transact-SQL une una instancia de SQL Server a un grupo de disponibilidad denominado ag1. Actualice el script para su entorno. En cada instancia de SQL Server que hospede una réplica secundaria, ejecute el siguiente script de Transact-SQL para unirla al grupo de disponibilidad.

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Agregar una base de datos al grupo de disponibilidad

Asegúrese de que la base de datos que se agrega al grupo de disponibilidad está en el modelo de recuperación completa y tiene una copia de seguridad de registros válida. Si se trata de una base de datos de prueba o una base de datos recién creada, realice una copia de seguridad de base de datos. En el servidor de SQL Server principal, ejecute el script de Transact-SQL siguiente para crear una base de datos denominada db1 y realizar una copia de seguridad de ella:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'/var/opt/mssql/data/db1.bak';

En la réplica principal de SQL Server, ejecute el script de Transact-SQL siguiente para agregar una base de datos denominada db1 a un grupo de disponibilidad denominado ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Compruebe que la base de datos se crea en los servidores secundarios.

En todas las réplicas secundarias de SQL Server, ejecute la consulta siguiente para ver si la base de datos db1 se ha creado y está sincronizada:

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

Importante

Después de crear el grupo de disponibilidad, debe configurar la integración con una tecnología de clúster, como Pacemaker, para la alta disponibilidad. En el caso de una configuración de escalado de lectura con grupos de disponibilidad, a partir de SQL Server 2017 (14.x) ya no es necesario configurar un clúster.

Si ha seguido los pasos descritos en este documento, tendrá un grupo de disponibilidad que todavía no está agrupado en clúster. El siguiente paso es agregar el clúster. Esta configuración es válida en escenarios de equilibrio de carga y escalado de lectura, pero no está completa para alta disponibilidad. Para lograr la alta disponibilidad, deberá agregar el grupo de disponibilidad como un recurso de clúster. Consulte Contenido relacionado para obtener instrucciones.

Comentarios

Importante

Después de configurar el clúster y agregar el grupo de disponibilidad como un recurso de clúster, no puede usar Transact-SQL para conmutar por error los recursos del grupo de disponibilidad. Los recursos de clúster de SQL Server en Linux no están tan bien integrados con el sistema operativo como lo están en un clúster de conmutación por error de Windows Server (WSFC). El servicio SQL Server no reconoce la presencia del clúster. Toda la orquestación se realiza con las herramientas de administración de clústeres. En RHEL o Ubuntu, use pcs. En SLES, use crm.

Importante

Si el grupo de disponibilidad es un recurso de clúster, existe un problema conocido en la versión actual en el que la conmutación por error forzada con pérdida de datos en una réplica asincrónica no funciona. Esto se corregirá en la próxima versión. La conmutación por error manual o automática en una réplica sincrónica sí se realiza correctamente.

Contenido relacionado