Configurar o grupo de disponibilidade Always On do SQL Server para alta disponibilidade no Linux

  • Artigo

Aplica-se a:SQL Server – Linux

Este artigo descreve como criar um grupo de disponibilidade (AG) Always On do SQL Server para alta disponibilidade no Linux. Há dois tipos de configuração para AGs. Uma configuração de alta disponibilidade usa um gerenciador de clusters para fornecer continuidade dos negócios. Essa configuração também pode incluir réplicas de escala de leitura. Este documento explica como criar o AG para alta disponibilidade.

Você também pode criar um AG sem um gerenciador de clusters para escala de leitura. O AG para escala de leitura fornece apenas réplicas somente leitura para expansão de desempenho. Ele não fornece alta disponibilidade. Para criar um AG para escala de leitura, confira Configurar um grupo de disponibilidade do SQL Server para escala de leitura no Linux.

As configurações que garantem alta disponibilidade e proteção de dados exigem duas ou três réplicas de confirmação síncronas. Com três réplicas síncronas, o AG pode se recuperar automaticamente mesmo que um servidor não esteja disponível. Para obter mais informações, confira Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Todos os servidores devem ser físicos ou virtuais e os servidores virtuais devem estar na mesma plataforma de virtualização. Esse requisito ocorre porque os agentes de isolamento são específicos da plataforma. Confira Políticas para clusters de convidados.

Roteiro

As etapas para criar um AG em servidores Linux para alta disponibilidade são diferentes das etapas em um cluster de failover do Windows Server. A lista a seguir descreve as etapas de alto nível:

  1. Diretrizes de instalação para o SQL Server no Linux.

    Importante

    Os três servidores do AG precisam estar na mesma plataforma – física ou virtual – porque a alta disponibilidade do Linux usa agentes de isolamento para isolar os recursos nos servidores. Os agentes de isolamento são específicos para cada plataforma.

  2. Crie o grupo de disponibilidade. Esta etapa é abordada no presente artigo.

  3. Configurar um gerenciador de recursos de cluster, como o Pacemaker.

    A maneira de configurar um gerenciador de recursos de cluster depende da distribuição específica do Linux. Confira os links a seguir para obter instruções específicas para cada distribuição:

    Importante

    Os ambientes de produção exigem um agente de isolamento para alta disponibilidade. Os exemplos neste artigo não usam agentes de isolamento. Eles se destinam apenas a teste e validação.

    Um cluster do Pacemaker usa o isolamento para retornar o cluster a um estado conhecido. A maneira de configurar o isolamento depende da distribuição e do ambiente. Atualmente, o isolamento não está disponível em alguns ambientes de nuvem. Para saber mais, confira Políticas de suporte para clusters de alta disponibilidade do RHEL – plataformas de virtualização.

    Para o SLES, confira Extensão de alta disponibilidade do SUSE Linux Enterprise.

  4. Adicione o AG como um recurso no cluster.

    A maneira de adicionar o AG como um recurso no cluster depende da distribuição do Linux. Confira os links a seguir para obter instruções específicas para cada distribuição:

Considerações sobre NICs (adaptadores de rede) múltiplas

Para obter informações sobre como configurar um grupo de disponibilidade para servidores com várias NICs, confira as seções relevantes para:

Pré-requisitos

Antes de criar o grupo de disponibilidade, você precisa:

  • Definir seu ambiente para que todos os servidores que hospedam réplicas de disponibilidade possam se comunicar.
  • Instale o SQL Server.

Observação

No Linux, você deve criar um grupo de disponibilidade antes de adicioná-lo como um recurso de cluster para ser gerenciado pelo cluster. Este documento fornece um exemplo que cria o grupo de disponibilidade. Para ver instruções específicas à distribuição para criar o cluster e adicionar o grupo de disponibilidade como um recurso de cluster, confira os links em "Próximas etapas".

  1. Atualize o nome do computador para cada host.

    Cada nome do SQL Server deve:

    • Ter 15 caracteres ou menos.
    • Ser exclusivo dentro da rede.

    Para definir o nome do computador, edite /etc/hostname. O script a seguir permite que você edite /etc/hostname com vi:

    sudo vi /etc/hostname

  2. Configurar o arquivo dos hosts.

    Observação

    Se os nomes de host estiverem registrados com o endereço IP no servidor DNS, não será necessário executar as etapas abaixo. Valide que todos os nós que farão parte da configuração do grupo de disponibilidade possam se comunicar uns com os outros. (Um ping para o nome do host deve fornecer o endereço IP correspondente.) Além disso, verifique se o arquivo /etc/hosts não contém um registro que mapeia o endereço IP do localhost 127.0.0.1 com o nome do host do nó.

    O arquivo de hosts em cada servidor contém os endereços IP e nomes de todos os servidores que farão parte do grupo de disponibilidade.

    O comando a seguir retorna o endereço IP do servidor atual:

    sudo ip addr show

    Atualizar /etc/hosts. O script a seguir permite que você edite /etc/hosts com vi:

    sudo vi /etc/hosts

    A exemplo a seguir mostra /etc/hosts no node1 com adições para node1, node2 e node3. Neste exemplo, node1 refere-se ao servidor que hospeda a réplica primária e node2 e node3 refere-se aos servidores que hospedam as réplicas secundárias.

    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

Instale o SQL Server

Instale o SQL Server. Os links a seguir apontam para instruções de instalação do SQL Server para diversas distribuições:

Habilitar Grupos de Disponibilidade Always On

Habilite grupos de disponibilidade Always On para cada nó que hospeda uma instância do SQL Server e reinicie mssql-server. Execute o seguinte script:

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

Habilitar uma sessão de evento AlwaysOn_health

Como opção, é possível habilitar eventos estendidos (XE) para ajudar com o diagnóstico da causa raiz ao solucionar problemas de um grupo de disponibilidade. Execute o seguinte comando em cada instância do SQL Server:

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

Para obter mais informações sobre essa sessão XE, confira Configurar eventos estendidos para grupos de disponibilidade Always On.

Criar um certificado

O serviço do SQL Server no Linux usa certificados para autenticar a comunicação entre os pontos de extremidade de espelhamento.

O script Transact-SQL a seguir cria uma chave mestra e um certificado. Em seguida, ele faz backup do certificado e protege o arquivo com uma chave privada. Atualize o script com senhas fortes. Conecte-se à instância primária do SQL Server. Para criar o certificado, execute o seguinte script 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>**'
        );

Nesse momento, sua réplica primária do SQL Server tem um certificado em /var/opt/mssql/data/dbm_certificate.cer e uma chave privada em var/opt/mssql/data/dbm_certificate.pvk. Copie esses dois arquivos no mesmo local em todos os servidores que hospedarão as réplicas de disponibilidade. Use o usuário mssql ou conceda permissão ao usuário mssql para acessar esses arquivos.

Por exemplo, no servidor de origem, o comando a seguir copia os arquivos para o computador de destino. Substitua os valores **<node2>** pelos nomes das instâncias do SQL Server que hospedarão as réplicas.

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

Em cada servidor de destino, dê permissão ao usuário mssql para acessar o certificado.

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

Criar o certificado em servidores secundários

O script Transact-SQL a seguir cria uma chave mestra e um certificado com base no backup que você criou na réplica primária do SQL Server. Atualize o script com senhas fortes. A senha de descriptografia é a mesma senha que você usou para criar o arquivo. pvk em uma etapa anterior. Para criar o certificado, execute o script a seguir em todos os servidores secundários:

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>**'
        );

Criar os pontos de extremidade de espelhamento de banco de dados em todas as réplicas

Os pontos de espelhamento de banco de dados usam o TCP (Protocolo de Controle de Transmissão) para enviar e receber mensagens entre as instâncias de servidor que participam das sessões de espelhamento de banco de dados ou hospedam réplicas de disponibilidade. O ponto de extremidade de espelhamento de banco de dados escuta em um exclusivo número de porta TCP.

O script Transact-SQL a seguir cria um ponto de extremidade de escuta chamado Hadr_endpoint para o grupo de disponibilidade. Ele começa no ponto de extremidade e concede a permissão de conexão para o certificado que você criou. Antes de executar o script, substitua os valores entre **< ... >**. Ou é possível incluir um endereço IP LISTENER_IP = (0.0.0.0). O endereço IP do ouvinte deve ser um endereço IPv4. Também é possível usar 0.0.0.0.

Atualize o script Transact-SQL a seguir para seu ambiente em todas as instâncias do 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;

Observação

Se você usar o SQL Server Express Edition em um nó para hospedar uma réplica somente de configuração, o único valor válido para ROLE será WITNESS. Execute o seguinte script no 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;

A porta TCP no firewall deve estar aberta para a porta do ouvinte.

Importante

Para a versão do SQL Server 2017, o único método de autenticação com suporte para o ponto de extremidade com espelhamento de banco de dados é o CERTIFICATE. A opção WINDOWS será habilitada em uma versão futura.

Para obter mais informações, consulte O ponto de extremidade de espelhamento de banco de dados (SQL Server).

Criar o grupo de disponibilidade

Os exemplos desta seção explicam como criar o grupo de disponibilidade usando o Transact-SQL. Você também pode usar o assistente de grupo de disponibilidade do SQL Server Management Studio. Quando você cria um AG com o assistente, ele retorna um erro ao associar as réplicas ao AG. Para corrigir isso, conceda ALTER, CONTROL e VIEW DEFINITIONS ao pacemaker no AG em todas as réplicas. Depois que as permissões forem concedidas na réplica primária, una os nós ao AG por meio do assistente, mas para que a HA funcione corretamente, conceda permissão em todas as réplicas.

Para uma configuração de alta disponibilidade que garanta o failover automático, o AG requer pelo menos três réplicas. Qualquer uma das configurações a seguir pode dar suporte à alta disponibilidade:

Para obter informações, confira Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Observação

Os grupos de disponibilidade podem incluir réplicas síncronas ou assíncronas adicionais.

Crie o AG para alta disponibilidade no Linux. Use o CREATE AVAILABILITY GROUP com CLUSTER_TYPE = EXTERNAL.

  • Grupo de disponibilidade: CLUSTER_TYPE = EXTERNAL.

    Especifica que uma entidade de cluster externa gerencia o AG. O pacemaker é um exemplo de entidade de cluster externa. Quando o tipo de cluster AG é externo,

  • Configure as réplicas primária e secundária como: FAILOVER_MODE = EXTERNAL.

    Especifica que a réplica interage com um gerenciador de clusters externo, como Pacemaker.

Os scripts Transact-SQL a seguir criam um AG para alta disponibilidade chamado ag1. O script configura as réplicas do grupo de disponibilidade com SEEDING_MODE = AUTOMATIC. Essa configuração faz com que o SQL Server crie automaticamente o banco de dados em cada servidor secundário. Atualize o script a seguir para o seu ambiente. Substitua os valores <node1>, <node2> ou <node3> pelos nomes das instâncias do SQL Server que hospedam as réplicas. Substitua o <5022> pela porta definida para o ponto de extremidade de espelhamento de dados. Para criar o AG, execute o Transact-SQL a seguir na instância do SQL Server que hospeda a réplica primária.

Importante

Na implementação atual do agente de SQL Server, o nome do nó deve corresponder à propriedade ServerName de sua instância. Por exemplo, se o nome do nó for node1, garanta que SERVERPROPERTY('ServerName') retorna node1 em sua instância do SQL Server. Se houver uma incompatibilidade, suas réplicas entrarão em um estado de resolução depois que o recurso do Pacemaker for criado.

Um cenário em que essa regra é importante é usar nomes de domínio totalmente qualificados. Por exemplo, se você usar node1.yourdomain.com como o nome do nó durante a instalação do cluster, garanta que SERVERPROPERTY('ServerName') retorne node1.yourdomain.com e não apenas node1. As possíveis soluções alternativas para esse problema são:

  • Renomeie o nome do host para o FQDN e use os procedimentos de armazenamento sp_dropserver e sp_addserver para garantir que os metadados no SQL Server correspondem à alteração.
  • Use a opção addr no comando pcs cluster auth para corresponder o nome do nó ao valor SERVERPROPERTY('ServerName') e use um IP estático como o endereço do nó.

Execute apenas um dos scripts a seguir:

Criar um grupo de disponibilidade com três réplicas síncronas

Criar um AG com três réplicas síncronas:

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

Depois de executar o script anterior para criar um AG com três réplicas síncronas, não execute o seguinte script:

Criar um grupo de disponibilidade com duas réplicas síncronas e uma réplica de configuração

Criar AG com duas réplicas síncronas e uma réplica de configuração:

Importante

Essa arquitetura permite que qualquer edição do SQL Server hospede a terceira réplica. Por exemplo, a terceira réplica pode ser hospedada no SQL Server Express Edition. Na Edição Express, o único tipo de ponto de extremidade válido é 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;

Criar um grupo de disponibilidade com duas réplicas síncronas

Criar AG com duas réplicas síncronas

Inclua duas réplicas com o modo de disponibilidade síncrona. Por exemplo, o script a seguir cria um AG chamado ag1. node1 e node2 hospedam réplicas no modo síncrono, com propagação automática e failover automático.

Importante

Execute apenas o script a seguir para criar um AG com duas réplicas síncronas. Não execute o script a seguir se tiver executado algum dos scripts anteriores.

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;

Você também pode configurar um AG com CLUSTER_TYPE=EXTERNAL usando o SQL Server Management Studio ou do PowerShell.

Una réplicas secundárias ao AG

O usuário do Pacemaker exige as permissões ALTER, CONTROL e VIEW DEFINITION no grupo de disponibilidade em todas as réplicas. Para conceder as permissões, execute o seguinte script Transact-SQL depois que o grupo de disponibilidade for criado na réplica primária e em cada réplica secundária imediatamente depois que elas forem adicionadas ao grupo de disponibilidade. Antes de executar o script, substitua <pacemakerLogin> pelo nome da conta de usuário do Pacemaker. Se você não tiver um logon para o Pacemaker, crie um logon do SQL Server para o Pacemaker.

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

O script Transact-SQL a seguir une uma instância do SQL Server a um AG chamado ag1. Atualize o script para o seu ambiente. Em cada instância do SQL Server que hospeda uma réplica secundária, execute o script Transact-SQL a seguir para unir ao AG.

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Adicionar um banco de dados ao grupo de disponibilidade

Verifique se o banco de dados adicionado ao grupo de disponibilidade está no modelo de recuperação completa e tem um backup de log válido. Se esse for um banco de dados de teste ou um banco de dados recém-criado, faça um backup de banco de dados. No SQL Server primário, execute o seguinte script Transact-SQL para criar e fazer backup de um banco de dados chamado db1:

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

Na réplica primária do SQL Server, execute o seguinte script Transact-SQL para adicionar um banco de dados chamado db1 a um grupo de disponibilidade denominado ag1:

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

Verificar se o banco de dados foi criado nos servidores secundários

Em cada réplica secundária do SQL Server, execute a consulta a seguir para ver se o banco de dados db1 foi criado e está sincronizado:

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

Depois de criar o AG, você deve configurar a integração com uma tecnologia de cluster como o pacemaker para alta disponibilidade. Para uma configuração de escala de leitura usando AGs, iniciando com o SQL Server 2017 (14.x), a configuração de um cluster não é necessária.

Caso tenha seguido as etapas deste documento, você terá um AG que ainda não está clusterizado. A próxima etapa é adicionar o cluster. Essa configuração é válida para cenários de escala de leitura/balanceamento de carga; ela não é completa para alta disponibilidade. Para alta disponibilidade, é preciso adicionar o AG como um recurso de cluster. Para obter instruções, consulte Conteúdo relacionado.

Comentários

Importante

Depois de configurar o cluster e adicionar o AG como um recurso de cluster, você não poderá usar o Transact-SQL para fazer failover dos recursos do AG. Os recursos de cluster do SQL Server em Linux não são acoplados tão firmemente com o sistema operacional como são em um WSFC (cluster de failover do Windows Server). O serviço SQL Server não reconhece a presença do cluster. Toda a orquestração é feita por meio das ferramentas de gerenciamento de cluster. No RHEL ou no Ubuntu, use pcs. No SLES, use crm.

Importante

Se o AG for um recurso do cluster, há um problema conhecido na versão atual em que o failover forçado com perda de dados para uma réplica assíncrona não funciona. Isso será corrigido na próxima versão. O failover manual ou automático para uma réplica síncrona é feito com sucesso.

Conteúdo relacionado