Tutorial: configurar um grupo de disponibilidade Always On de três nós com o HPE Serviceguard para Linux

Aplica-se a:SQL Server – Linux

Esse tutorial explica como configurar grupos de disponibilidade do SQL Server com o HPE Serviceguard para Linux em execução em VMs (máquinas virtuais) locais ou em VMs baseadas no Azure.

Confira Clusters do HPE Serviceguard para obter uma visão geral dos clusters do HPE Serviceguard.

Observação

A Microsoft dá suporte à movimentação de dados, ao grupo de disponibilidade e aos componentes do SQL Server. Entre em contato com a HPE para obter suporte relacionado à documentação sobre gerenciamento de cluster e de quorum do HPE Serviceguard.

Este tutorial é composto pelas seguintes etapas:

  • Instalar SQL Server em todas as três VMs que serão parte do grupo de disponibilidade
  • Instalar o HPE Serviceguard nas VMs
  • Criar o cluster do HPE Serviceguard
  • Criar o balanceador de carga no portal do Azure
  • Criar o grupo de disponibilidade e adicionar um banco de dados de exemplo ao grupo de disponibilidade
  • Implantar a carga de trabalho do SQL Server no grupo de disponibilidade por meio do gerenciador de cluster do Serviceguard
  • Realizar um failover automático e ingressar o nó de volta no cluster

Pré-requisitos

  • No Azure, crie três VMs (Máquinas Virtuais) baseadas em Linux. Para criar máquinas virtuais baseadas em Linux no Azure, confira Início Rápido: criar máquinas virtuais do Linux no portal do Azure. Ao implantar as VMs, use distribuições do Linux com suporte do HPE Serviceguard. Se preferir, você também pode implantar as VMs em um ambiente local, com base em uma localização.

    Para obter um exemplo de uma distribuição compatível, confira HPE Serviceguard para Linux. Entre em contato com a HPE para obter informações sobre suporte para ambientes de nuvem pública.

    As instruções no tutorial são validadas junto ao HPE Serviceguard para Linux. Uma edição de avaliação está disponível para download com a HPE.

  • Arquivos de banco de dados do SQL Server na LVM (montagem de volume lógico) para todas as três máquinas virtuais. Confira Guia de início rápido para o Serviceguard para Linux (HPE)

  • Verifique se você tem um runtime Java OpenJDK instalado nas VMs. O SDK de Java da IBM não é compatível.

Instale o SQL Server

Em todas as três VMs, siga uma das etapas abaixo com base na distribuição do Linux que você escolher para este tutorial, a fim de instalar o SQL Server e as ferramentas.

Red Hat Enterprise Linux (RHEL)

SUSE Linux Enterprise Server (SLES)

Depois de concluir esta etapa, você deve ter o serviço e as ferramentas do SQL Server instalados em todas as três VMs que participarão do grupo de disponibilidade.

Instalar o HPE Serviceguard nas VMs

Nesta etapa, instale o HPE Serviceguard para Linux em todas as três VMs. A tabela a seguir descreve a função que cada servidor desempenha no cluster.

Número de VMs Função HPE Serviceguard Função da réplica de grupo de disponibilidade do Microsoft SQL Server
1 Nós de cluster do HPE Serviceguard Réplica primária
1 ou mais Nó de cluster do HPE Serviceguard Réplica secundária
1 Servidor de quorum do HPE Serviceguard Réplica somente de configuração

Observação

Consulte este vídeo da HPE, que descreve como instalar e configurar um cluster HPE Serviceguard via interface do usuário.

Para instalar o Serviceguard, use o método cminstaller. Instruções específicas estão disponíveis nos seguintes links:

Depois de concluir a instalação do cluster do HPE Serviceguard, você poderá habilitar o portal de gerenciamento de cluster na porta TCP 5522 no nó da réplica primária. As etapas a seguir adicionam uma regra ao firewall para permitir 5522. O comando a seguir é para um RHEL (Red Hat Enterprise Linux). Você precisa executar comandos semelhantes para outras distribuições:

sudo firewall-cmd --zone=public --add-port=5522/tcp --permanent
sudo firewall-cmd --reload

Criar um cluster do HPE Serviceguard

Siga estas instruções para configurar e criar o cluster do HPE Serviceguard. Nesta etapa, você também configurará o servidor de quorum.

  1. Configure o servidor de quorum do Serviceguard no terceiro nó. Consulte a seção Configure_QS.
  2. Configure e crie o cluster do Serviceguard nos outros dois nós. Consulte a seção Configure_and_create_Cluster.

Observação

Você pode ignorar a instalação manual do cluster e quorum do HPE Serviceguard, adicionando a extensão HPE Serviceguard para Linux (SGLX) do marketplace de VMs do Azure ao criar sua VM.

Criar o grupo de disponibilidade e adicionar um banco de dados de exemplo

Nessa etapa, crie um grupo de disponibilidade com duas (ou mais) réplicas síncronas e uma réplica somente de configuração, que fornece proteção de dados e também pode fornecer alta disponibilidade. O seguinte diagrama representa essa arquitetura:

Screenshot showing how the primary replica synchronizes user data and configuration data with the secondary replica. The primary replica only synchronizes configuration data with the configuration only replica. The configuration only replica doesn't have user data replicas.

  1. Replicação síncrona de dados do usuário para a réplica secundária. Ela também inclui metadados de configuração do grupo de disponibilidade.

  2. Replicação síncrona de metadados de configuração do grupo de disponibilidade. Ela não inclui dados do usuário.

Para obter mais informações, confira Duas réplicas síncronas e uma réplica somente de configuração.

Para criar o grupo de disponibilidade, siga estas etapas:

  1. Habilite grupos de disponibilidade e reinicie o MSSQL Server em todas as VMs, incluindo a réplica somente de configuração.
  2. Habilitar uma sessão de evento AlwaysOn_health (opcional)
  3. Criar um certificado na VM primária
  4. Criar o certificado em servidores secundários
  5. Criar os pontos de extremidade de espelhamento de banco de dados nas réplicas
  6. Criar grupo de disponibilidade
  7. Ingressar as réplicas secundárias
  8. Adicionar um banco de dados ao grupo de disponibilidade

Habilitar grupos de disponibilidade e reiniciar o mssql-server

Habilite grupos de disponibilidade em todos os nós que hospedam uma instância do SQL Server. Em seguida, reinicie o mssql-server. Execute seguinte script em todos os três nós:

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

Habilitar uma sessão de evento AlwaysOn_health (opcional)

Opcionalmente, habilite eventos estendidos de grupos de disponibilidade Always On 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

Criar um certificado na VM primária

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 e 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, a 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 de node2 pelo nome do host que executa a instância secundária do SQL Server. Copie o certificado na réplica somente de configuração também e execute os comandos abaixo também nesse nó.

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

Agora, nas VMs secundárias que executam a instância secundária e a réplica somente de configuração do SQL Server, execute os comandos abaixo para que o usuário do mssql possa ser o proprietário do certificado copiado:

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, exceto na réplica somente de configuração:

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 nas réplicas

Nas réplicas primária e secundária, execute os seguintes comandos para criar os pontos de extremidade de espelhamento de banco de dados:

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;

Observação

5022 é a porta padrão usada para o ponto de extremidade de espelhamento de banco de dados, mas você pode alterá-la para qualquer porta disponível.

Na réplica somente de configuração, crie o ponto de extremidade de espelhamento de banco de dados usando o comando abaixo. Observe que o valor da função aqui é definido como WITNESS, que é o valor necessário para a réplica somente de configuração.

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;

Criar grupo de disponibilidade

Na instância da réplica primária, execute os comandos a seguir. Esses comandos criam um grupo de disponibilidade chamado ag1, que tem um EXTERNAL cluster_type e concede permissão para de criação de banco de dados ao grupo de disponibilidade.

Antes de executar os scripts a seguir, substitua os espaços reservados <node1>, <node2> e <node3> (réplica somente de configuração) pelo nome das VMs que você criou nas etapas 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
        ),
    
    N'<node3>' WITH (
        ENDPOINT_URL = N'tcp://<node3>:<5022>',
        AVAILABILITY_MODE = CONFIGURATION_ONLY
        );
          
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Ingressar as réplicas secundárias

Execute os comandos a seguir em todas as réplicas secundárias. Esses comandos ingressam as réplicas secundárias no grupo de disponibilidade ag1 com a réplica primária e permitem acesso de criação de banco de dados ao grupo de disponibilidade ag1.

ALTER AVAILABILITY GROUP [ag1]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
ALTER AVAILABILITY GROUP [ag1]
GRANT CREATE ANY DATABASE;
GO

Adicionar um banco de dados ao grupo de disponibilidade

Conecte-se à réplica primária e execute os seguintes comandos T-SQL para:

  1. Criar um banco de dados de exemplo chamado db1, que será adicionado ao grupo de disponibilidade.
  2. Definir o modelo de recuperação do banco de dados para completo. Todos os bancos de dados em um grupo de disponibilidade requerem o modelo de recuperação completa.
  3. Fazer backup do banco de dados. Um banco de dados requer pelo menos um backup completo para que você possa adicioná-lo a um grupo de disponibilidade.
-- creates a database named db1
CREATE DATABASE [db1];
GO

-- set the database in full recovery model
ALTER DATABASE [db1] SET RECOVERY FULL; 
GO

-- backs up the database to disk
BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';
GO

-- adds the database db1 to the AG
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
GO

Depois de concluir com êxito as etapas anteriores, você pode ver um grupo de disponibilidade ag1 criado e as três VMs são adicionadas como réplicas com uma réplica primária, uma réplica secundária e uma réplica somente de configuração. ag1 contém um banco de dados.

Implantar a carga de trabalho do grupo de disponibilidade do SQL Server (Gerenciador de Cluster HPE)

No HPE Serviceguard, implante a carga de trabalho do SQL Server no grupo de disponibilidade por meio da interface do usuário do gerenciador de cluster do Serviceguard.

Implante a carga de trabalho do grupo de disponibilidade e habilite a HA (alta disponibilidade), DR (recuperação de desastre) via cluster do Serviceguard usando a interface gráfica do usuário do gerenciador do Serviceguard. Consulte a seção Proteger grupos de disponibilidade Always On do Microsoft SQL Server em Linux.

Criar o balanceador de carga no portal do Azure

Para implantações no Azure Cloud, o HPE Serviceguard para Linux requer um balanceador de carga para habilitar conexões de cliente com a réplica primário, para substituir os endereços IP tradicionais.

  1. No portal do Azure, abra o grupo de recursos que contém as máquinas virtuais ou nós de cluster do Serviceguard.

  2. No grupo de recursos, selecione Adicionar.

  3. Pesquise "balanceador de carga" e, em seguida, nos resultados da pesquisa, selecione o Balanceador de Cargapublicado pela Microsoft.

  4. No painel Balanceador de carga, selecione Criar.

  5. Configure o balanceador de carga da seguinte maneira:

    Configuração Valor
    Nome O nome do balanceador de carga. Por exemplo, SQLAvailabilityGroupLB.
    Tipo Interna
    SKU Básica ou Standard
    Rede virtual VNet usada para as réplicas de VM
    Sub-rede Sub-rede na qual as instâncias do SQL Server estão hospedadas
    Atribuição de endereço IP Estático
    Endereço IP privado Criar um IP privado na sub-rede
    Assinatura Escolher a assinatura em questão
    Grupo de recursos Escolher o grupo de recursos em questão
    Localidade Selecionar o mesmo local que nós SQL

Configurar o pool de back-end

O pool de back-end são os endereços das duas instâncias nas quais o cluster Serviceguard está configurado.

  1. No grupo de recursos, selecione o balanceador de carga criado.
  2. Navegue até Configurações > Pools de back-end e selecione Adicionar para criar um pool de endereços de back-end.
  3. Em Adicionar pool de back-end, em Nome, digite um nome para o pool de back-end.
  4. Em Associado a, selecione Máquina virtual.
  5. Selecione a máquina virtual no ambiente e associe o endereço IP apropriado a cada seleção.
  6. Selecione Adicionar.

Criar uma investigação

A investigação define como o Azure verifica qual do nó de cluster Serviceguard é a réplica primária. O Azure investiga o serviço com base no endereço IP em uma porta que você define quando cria o teste.

  1. No painel Configurações do balanceador de carga, selecione Investigações de integridade.

  2. No painel Investigações de integridade, selecione Adicionar.

  3. Use os valores a seguir para configurar a investigação:

    Configuração Valor
    Nome Nome que representa a investigação. Por exemplo, SQLAGPrimaryReplicaProbe.
    Protocolo TCP
    Porta Você pode usar qualquer porta disponível. Por exemplo, 59999.
    Intervalo 5
    Limite não íntegro 2
  4. Selecione OK.

  5. Entre em todas as suas máquinas virtuais e abra a porta de investigação usando os seguintes comandos:

    sudo firewall-cmd --zone=public --add-port=59999/tcp --permanent
    sudo firewall-cmd --reload
    

O Azure cria a investigação e a usa para testar o nó Serviceguard no qual a instância de réplica primária do grupo de disponibilidade está em execução. Lembre-se da porta configurada (59999), que é necessária para implantar o AG no cluster Serviceguard.

Definir as regras de balanceamento de carga

As regras de balanceamento de carga configuram como o balanceador de carga roteia o tráfego para o nó Serviceguard, que é a réplica primária no cluster. Para esse balanceador de carga, habilite o retorno do servidor direto, pois apenas um dos nós de cluster Serviceguard pode ser uma réplica primária por vez.

  1. No painel Configurações do balanceador de carga, selecione Regras de balanceamento de carga.

  2. No painel Regras de balanceamento de carga, selecione Adicionar.

  3. Defina a regra de balanceamento de carga usando as seguintes configurações:

    Configuração Valor
    Nome Nome que representa as regras de balanceamento de carga. Por exemplo, SQLAGPrimaryReplicaListener.
    Protocolo TCP
    Porta 1433
    Porta de back-end 1433. Esse valor é ignorado porque essa regra usa IP flutuante.
    Investigação Use o nome da investigação que você criou para este balanceador de carga.
    Persistência de sessão Nenhum
    Tempo limite de ociosidade (minutos) 4
    IP flutuante habilitado
  4. Selecione OK.

  5. O Azure configura a regra de balanceamento de carga. Agora, o balanceador de carga está configurado para rotear o tráfego para o nó Serviceguard, que é a instância de réplica primária no cluster.

Anote o endereço IP de front-end do balanceador de carga "LbReadWriteIP", que é necessário para implantar o AG no cluster Serviceguard.

Neste ponto, o grupo de recursos tem um balanceador de carga que se conecta em todos os nós Serviceguard. O balanceador de carga também contém um endereço IP para os clientes se conectarem à instância de réplica primária no cluster, para que qualquer computador que seja uma réplica primária possa responder a solicitações para o grupo de disponibilidade.

Realizar um failover automático e ingressar o nó de volta no cluster

Para o teste de failover automático, você pode desativar a réplica primária (desligar), o que replicará a indisponibilidade repentina do nó primário. O comportamento esperado é:

  1. O gerenciador de cluster promove uma das réplicas secundárias no grupo de disponibilidade para primária.
  2. A réplica primária com falha é ingressada automaticamente no cluster após o backup dela ser realizado. O gerenciador de cluster promove-a para réplica secundária.

Para o HPE Serviceguard, consulte a seção Testar a configuração para prontidão de failover