Configurar um cluster do Pacemaker para grupos de disponibilidade do SQL Server

  • Artigo

Aplica-se a:SQL Server – Linux

Este artigo descreve como criar um cluster de três nós no Linux usando o Pacemaker e como adicionar um grupo de disponibilidade criado anteriormente como um recurso no cluster. Para alta disponibilidade, um grupo de disponibilidade em Linux exige três nós – consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

Observação

Comunicação livre de desvio

Este artigo contém referências ao termo subordinado, um termo que a Microsoft considera ofensivo quando usado neste contexto. O termo aparece neste artigo porque ele atualmente aparece no software. Quando o termo for removido do software, também o removeremos do artigo.

O SQL Server não é tão totalmente integrado ao Pacemaker no Linux quanto ao WSFC (clustering de failover do Windows Server). Uma instância do SQL Server não reconhece o cluster, e toda a orquestração é feita de fora para dentro. O Pacemaker fornece orquestração de recursos de cluster. Além disso, o nome da rede virtual é específico do clustering de failover do Windows Server. Não há um equivalente no Pacemaker. As DMVs (exibições de gerenciamento dinâmico) do grupo de disponibilidade que consultam as informações do cluster retornam linhas vazias em clusters do Pacemaker. Para criar um ouvinte de reconexão transparente após o failover, registre manualmente o nome do ouvinte em DNS com o IP usado para criar o recurso de IP virtual.

Você ainda poderá criar um ouvinte para usá-lo para reconexão transparente após o failover, mas será necessário registrar manualmente o nome do ouvinte no servidor DNS com o IP usado para criar o recurso de IP virtual (conforme explicado nas seções a seguir).

As seções a seguir descrevem as etapas necessárias para configurar um cluster do Pacemaker e adicionar um grupo de disponibilidade como um recurso no cluster para alta disponibilidade a cada distribuição do Linux com suporte.

A camada de clustering baseia-se no complemento de HA do RHEL (Red Hat Enterprise Linux) criado com base no Pacemaker.

Observação

O acesso à documentação completa do Red Hat exige uma assinatura válida.

Para saber mais sobre configuração de cluster, opções de agentes de recursos e gerenciamento, acesse a Documentação de referência do RHEL.

Roteiro

As etapas para criar um grupo de disponibilidade 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. Configurar o SQL Server nos nós de cluster.

  2. Criar o grupo de disponibilidade.

  3. Configurar um gerenciador de recursos de cluster, como o Pacemaker. Essas instruções estão contidas neste artigo.

    A maneira de configurar um gerenciador de recursos de cluster depende da distribuição específica do Linux.

    Importante

    Os ambientes de produção exigem um agente de isolamento para alta disponibilidade. As demonstrações desta documentação não usam agentes de isolamento. As demonstrações se destinam apenas a teste e validação. Um cluster do Linux 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.

  4. Adicione o grupo de disponibilidade como um recurso no cluster.

Configurar a alta disponibilidade do RHEL

Para configurar a alta disponibilidade do RHEL, habilite a assinatura de alta disponibilidade e configure o Pacemaker.

Habilitar a assinatura de alta disponibilidade para RHEL

Cada nó no cluster deve ter uma assinatura apropriada para RHEL e o complemento de alta disponibilidade. Examine os requisitos em Como instalar pacotes de cluster de alta disponibilidade no Red Hat Enterprise Linux. Siga estas etapas para configurar a assinatura e repositórios:

  1. Registre o sistema.

    sudo subscription-manager register

    Forneça seu nome de usuário e senha.

  2. Liste os pools disponíveis para registro.

    sudo subscription-manager list --available

    Na lista de pools disponíveis, observe a ID do pool para a assinatura de alta disponibilidade.

  3. Atualize o seguinte script. Substitua <pool id> pela ID do pool para alta disponibilidade da etapa anterior. Execute o script para anexar a assinatura.

    sudo subscription-manager attach --pool=<pool id>

  4. Habilite o repositório.

    RHEL 7

    sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms

    RHEL 8

    sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms

Para saber mais, confira Pacemaker – O cluster de alta disponibilidade e software livre.

Após configurar a assinatura, conclua as seguintes etapas para configurar o Pacemaker:

Configurar o Pacemaker

Após registrar a assinatura, conclua as etapas a seguir para configurar o Pacemaker:

  1. Em todos os nós de cluster, abra as portas do firewall do Pacemaker. Para abrir essas portas com o firewalld, execute o seguinte comando:

    sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload

    Se o firewall não tiver uma configuração de alta disponibilidade interna, abra as portas do Pacemaker a seguir.

    • TCP: Portas 2224, 3121 e 21064
    • UDP: Porta 5405

  2. Instale os pacotes do Pacemaker em todos os nós.

    sudo yum install pacemaker pcs fence-agents-all resource-agents

  3. Defina a senha do usuário padrão criado ao instalar pacotes do Pacemaker e do Corosync. Use a mesma senha em todos os nós.

    sudo passwd hacluster

  4. Para que os nós reingressem no cluster após a reinicialização, habilite e inicie o serviço pcsd e o Pacemaker. Execute o seguinte comando em todos os nós.

    sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker

  5. Crie o cluster. Para criar o cluster, execute o seguinte comando:

    RHEL 7

    sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all

    RHEL8

    Para o RHEL 8, você precisará autenticar os nós separadamente. Insira manualmente o nome de usuário e a senha do hacluster quando solicitado.

    sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all

    Observação

    Se você tiver configurado um cluster anteriormente nos mesmos nós, será necessário usar a opção --force ao executar pcs cluster setup. Essa opção é equivalente a executar o pcs cluster destroy. Para reabilitar o Pacemaker, execute o sudo systemctl enable pacemaker.

  6. Instalar o agente do recurso SQL Server para o SQL Server. Execute os seguintes comandos em todos os nós.

    sudo yum install mssql-server-ha

Após configurar o Pacemaker, use pcs para interagir com o cluster. Execute todos os comandos em um nó do cluster.

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

Ao configurar a alta disponibilidade com servidores que têm várias NICs, siga estas sugestões:

  • Verifique se o arquivo hosts está configurado para que os endereços IP do servidor para as várias NICs sejam resolvidos para o nome do host do servidor do Linux em cada nó.

  • Durante a configuração do cluster por meio do Pacemaker, o uso do nome do host dos servidores configura o Corosync para definir a configuração para todas as NICs. Queremos apenas a comunicação entre o Pacemaker e o Corosync em uma só NIC. Depois que o cluster do Pacemaker for configurado, modifique a configuração no arquivo corosync.conf e atualize o endereço IP da NIC dedicada que você deseja usar para a comunicação entre o Pacemaker e o Corosync.

  • O <hostname> especificado no arquivo corosync.conf deve ser o mesmo que a saída fornecida ao fazer uma pesquisa inversa (ping -a <ip_address>) e deve ser o nome curto configurado no host. Verifique se o arquivo hosts também representa o endereço IP adequado para a resolução de nomes.

As alterações no exemplo de arquivo corosync.conf são realçadas abaixo:

  nodelist {
    node {
        ring0_addr: <ip_address_of_node1_NIC1>
        name: <hostname_of_node1>
        nodeid: 1
    }
    node {
        ring0_addr: <ip_address_of_node2_NIC1>
        name: <hostname_of_node2>
        nodeid: 2
    }
    node {
        ring0_addr: <ip_address_of_node3_NIC1>
        name: <hostname_of_node3>
        nodeid: 3
    }
  }

Configurar um dispositivo de isolamento

Os fornecedores de cluster do Pacemaker exigem o isolamento de um nó com falha usando um dispositivo de isolamento definido para uma configuração de cluster compatível. Quando o gerenciador de recursos de cluster não pode determinar o estado de um nó ou de um recurso em um nó, o isolamento traz o cluster para um estado conhecido novamente.

Um dispositivo de isolamento fornece um agente de isolamento. A configuração do Pacemaker no Red Hat Enterprise Linux no Azure fornece um exemplo de como criar um dispositivo de isolamento para esse cluster no Azure. Modifique as instruções de seu ambiente.

O isolamento do recurso garante que não haja dados corrompidos em uma interrupção ao configurar um recurso. Por exemplo, você poderá usar o isolamento no nível do recurso para marcar o disco em um nó como desatualizado quando o link de comunicação ficar inativo.

O isolamento no nível do nó garante que um nó não execute nenhum recurso. Isso é feito redefinindo o nó. O Pacemaker dá suporte a uma grande variedade de dispositivos de isolamento. Os exemplos incluem no-break ou cartões de interface de gerenciamento para servidores.

Para obter mais informações sobre o isolamento de um nó com falha, confira os seguintes artigos:

Observação

Como a configuração de isolamento no nível do nó depende muito do seu ambiente, desabilite-a para este tutorial (ela pode ser configurada posteriormente). O script a seguir desabilita o isolamento no nível do nó:

sudo pcs property set stonith-enabled=false

A ação de desabilitar o isolamento é somente para fins de teste. Caso pretenda usar o Pacemaker em um ambiente de produção, você deve planejar uma implementação do isolamento, dependendo do seu ambiente, e mantê-lo habilitado.

Defina a propriedade de cluster cluster-recheck-interval

cluster-recheck-interval indica o intervalo de sondagem segundo o qual o cluster verifica se há alterações nos parâmetros do recurso, restrições ou outras opções de cluster. Se uma réplica ficar inativa, o cluster tentará reiniciar a réplica em um intervalo associado ao valor failure-timeout e ao valor cluster-recheck-interval. Por exemplo, se failure-timeout for definido como 60 segundos e cluster-recheck-interval for definido como 120 segundos, será realizada uma tentativa de reinicialização em um intervalo superior a 60 segundos, mas inferior a 120 segundos. Recomendamos que você defina o tempo limite de falha como 60 segundos e cluster-recheck-interval com um valor superior a 60 segundos. Não é recomendável definir cluster-recheck-interval com um valor menor.

Para atualizar o valor da propriedade para 2 minutes, execute:

sudo pcs property set cluster-recheck-interval=2min

Se você já tem um recurso de grupo de disponibilidade gerenciado por um cluster do Pacemaker, o pacote do Pacemaker 1.1.18-11.el7 apresenta uma alteração de comportamento para a configuração de cluster start-failure-is-fatal quando o valor dela é false. Essa alteração afeta o fluxo de trabalho de failover. Se uma réplica primária apresentar uma interrupção, o cluster deverá fazer failover para uma das réplicas secundárias disponíveis. Em vez disso, os usuários observarão que o cluster continuará tentando iniciar a réplica primária com falha. Se a primária nunca ficar online (devido a uma interrupção permanente), o cluster nunca fará failover para outra réplica secundária disponível. Devido a essa alteração, a configuração recomendada anteriormente para definir start-failure-is-fatal não é mais válida, e a configuração precisa ser revertida para o valor padrão de true.

Além disso, o recurso do AG precisa ser atualizado para incluir a propriedade failure-timeout.

Para atualizar o valor da propriedade para true, execute:

sudo pcs property set start-failure-is-fatal=true

Para atualizar a propriedade failure-timeout do recurso ag_cluster para 60s, execute:

pcs resource update ag_cluster meta failure-timeout=60s

Para saber mais sobre as propriedades de cluster do Pacemaker, confira Propriedades de clusters do Pacemaker.

Criar um logon do SQL Server para o Pacemaker

  1. Em todas as instâncias do SQL Server, crie um logon de Server para o Pacemaker. O Transact-SQL a seguir cria um logon:

    USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';

ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];

    No momento da criação do grupo de disponibilidade, o usuário do Pacemaker precisará das permissões ALTERAR, CONTROLAR e EXIBIR DEFINIÇÃO no grupo de disponibilidade, após ele ser criado mas antes que os nós sejam adicionados a ele.

  2. Em todas as instâncias do SQL Server, salve as credenciais para o logon do SQL Server.

    echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root

Criar recurso do grupo de disponibilidade

Para criar o recurso do grupo de disponibilidade, use o comando pcs resource create e defina as propriedades do recurso. O comando a seguir cria um recurso do tipo mestre/subordinado ocf:mssql:ag para o grupo de disponibilidade com o nome ag1.

RHEL 7

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true

RHEL 8

Com a disponibilidade do RHEL 8, a sintaxe create foi alterada. Se você usar o RHEL 8, a terminologia master foi alterada para promotable. Use o seguinte comando create em vez do comando acima:

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true

Observação

Ao criar o recurso e, depois, periodicamente, o agente de recurso do Pacemaker define automaticamente o valor do REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT com base na configuração do grupo de disponibilidade. Por exemplo, se o grupo de disponibilidade tem três réplicas síncronas, o agente definirá REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1. Para obter detalhes e mais opções de configuração, consulte Alta disponibilidade e proteção de dados para as configurações de grupo de disponibilidade.

Criar recurso de IP virtual

Para criar o recurso de endereço IP virtual, execute o comando a seguir em um nó. Use um endereço IP estático disponível da rede. Substitua o endereço IP entre <10.128.16.240> por um endereço IP válido.

sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>

Não há nome do servidor virtual equivalente no Pacemaker. Para usar uma cadeia de conexão que aponte para um nome do servidor de cadeia de caracteres, em vez de um endereço IP, registre o endereço de recurso do IP virtual e o nome do servidor virtual desejado no DNS. Para configurações de DR, registre o nome do servidor virtual e o endereço IP desejados com os servidores DNS nos sites primário e de DR.

Adicionar restrição de colocalização

Quase todas as decisões em um cluster do Pacemaker, como escolher o local em que um recurso deve ser executado, são feitas pela comparação de pontuações. As pontuações são calculadas por recurso. O gerenciador de recursos de cluster escolhe o nó com a pontuação mais alta para um recurso específico. Se um nó tiver uma pontuação negativa para um recurso, o recurso não poderá ser executado nesse nó.

Em um cluster do Pacemaker, você pode manipular as decisões do cluster com restrições. As restrições têm uma pontuação. Se uma restrição tiver uma pontuação menor que INFINITY, o Pacemaker a considerará uma recomendação. A opção de INFINITY é obrigatória.

Para verificar se a réplica primária e o recurso de IP virtual são executados no mesmo host, defina uma restrição de colocalização com pontuação igual a INFINITY. Para adicionar a restrição de colocalização, execute o comando a seguir em um nó.

RHEL 7

Quando você cria o recurso ag_cluster no RHEL 7, ele o cria como ag_cluster-master. Use o seguinte comando para o RHEL 7:

sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master

RHEL 8

Quando você cria o recurso ag_cluster no RHEL 8, ele o cria como ag_cluster-clone. Use o seguinte comando para o RHEL 8:

sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master

Adicionar restrição de ordenação

A restrição de colocalização tem uma restrição de ordenação implícita. Ela move o recurso de IP virtual antes de mover o recurso de grupo de disponibilidade. Por padrão, a sequência de eventos é:

  1. O usuário emite pcs resource move ao grupo de disponibilidade primário do node1 para o node2.

  2. O recurso de IP virtual é interrompido no nó 1.

  3. O recurso de IP virtual é iniciado no nó 2.

    Observação

    Neste ponto, o endereço IP aponta temporariamente para o nó 2, enquanto o nó 2 ainda é um secundário de pré-failover.

  4. O grupo de disponibilidade primário no nó 1 é rebaixado para secundário.

  5. O grupo de disponibilidade secundário no nó 2 é promovido para primário.

Para impedir que o endereço IP aponte temporariamente para o nó com o secundário de pré-failover, adicione uma restrição de ordenação.

Para adicionar uma restrição de ordenação, execute o comando a seguir em um nó:

RHEL 7

sudo pcs constraint order promote ag_cluster-master then start virtualip

RHEL 8

sudo pcs constraint order promote ag_cluster-clone then start virtualip

Importante

Depois de configurar o cluster e adicionar o grupo de disponibilidade como um recurso de cluster, você não poderá usar o Transact-SQL para fazer failover dos recursos de grupo de disponibilidade. 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 e, no SLES, use as ferramentas crm.

Faça failover manualmente do grupo de disponibilidade com pcs. Não inicie o failover com o Transact-SQL. Para obter instruções, confira Failover.

Conteúdo relacionado