Partilhar via

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

Aplica-se a:SQL Server em Linux

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

Observação

Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo é removido do software, nós o removemos deste artigo.

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

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

As seções a seguir percorrem as etapas para configurar um cluster Pacemaker e adicionar um grupo de disponibilidade como recurso no cluster para alta disponibilidade, para cada distribuição Linux suportada.

A camada de clustering é baseada no complemento Red Hat Enterprise Linux (RHEL) HA construído sobre Pacemaker.

Observação

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

Para obter mais informações sobre configuração de cluster, opções de agentes de recursos e gerenciamento, visite 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. Configure um gerenciador de recursos de cluster, como o Pacemaker. Estas instruções estão neste artigo.

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

    Importante

    Os ambientes de produção exigem um agente de vedação para alta disponibilidade. As demonstrações nesta documentação não usam agentes de proteção. As demonstrações são apenas para teste e validação. Um cluster Linux usa vedação para retornar o cluster a um estado conhecido. A maneira de configurar a vedação depende da distribuição e do ambiente. Atualmente, a esgrima não está disponível em alguns ambientes de nuvem. Para obter mais informações, consulte Políticas de suporte para clusters de alta disponibilidade RHEL - Plataformas de virtualização.

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

Configurar alta disponibilidade para RHEL

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

Habilite a assinatura de alta disponibilidade para RHEL

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

  1. Registe o sistema.

    sudo subscription-manager register

    Forneça o seu nome de utilizador e palavra-passe.

  2. Liste os pools disponíveis para registro.

    sudo subscription-manager list --available

    Observação

    Para RHEL 10, o comando list é o seguinte:

    sudo subscription-manager repos --list

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

  3. Atualize o script a seguir. Substitua <pool id> pelo 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

    RHEL 9

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

    RHEL 10

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

Para obter mais informações, consulte Pacemaker - o cluster de alta disponibilidade de código aberto.

Depois de configurar a assinatura, conclua as seguintes etapas para configurar o Pacemaker:

Configurar Pacemaker

Depois de registrar a assinatura, conclua as seguintes etapas para configurar o Pacemaker:

  1. Em todos os nós do cluster, abra as portas do firewall do Pacemaker. Para abrir essas portas com 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 integrada, abra as seguintes portas para o Pacemaker.

    • TCP: Portas 2224, 3121, 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 para o usuário padrão que é criado ao instalar os pacotes Pacemaker e Corosync. Use a mesma palavra-passe em todos os nós.

    sudo passwd hacluster

  4. Para permitir que os nós voltem ao 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 num único nó:

    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

    RHEL 8 e versões posteriores

    Para o RHEL 8 e versões posteriores, você precisa autenticar os nós separadamente. Insira manualmente o nome de usuário e a senha para 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 já configuraste anteriormente um cluster nos mesmos nós, precisarás usar a opção --force ao executar pcs cluster setup. Esta opção é equivalente à execução pcs cluster destroy. Para reativar o Pacemaker, execute sudo systemctl enable pacemaker.

  6. Instale o agente de recursos do SQL Server para SQL Server. Execute os seguintes comandos em todos os nós.

    sudo yum install mssql-server-ha

Depois que o Pacemaker estiver configurado, use pcs para interagir com o cluster. Execute todos os comandos em um nó do cluster.

Considerações para múltiplas interfaces de rede (NICs)

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 Linux em cada nó.

  • Ao configurar o cluster usando o Pacemaker, é necessário utilizar o nome do host dos servidores para que o Corosync defina a configuração de todas as placas de rede (NICs). Queremos apenas a comunicação Pacemaker/Corosync através de uma única NIC. Depois que o cluster Pacemaker estiver 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 Pacemaker/Corosync.

  • O <hostname> fornecido no arquivo corosync.conf deve ser o mesmo que a saída dada 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 destacadas 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 Pacemaker exigem bloquear um nó com falha, utilizando um dispositivo de isolamento configurado para uma configuração de cluster suportada. Quando o gerenciador de recursos de cluster não pode determinar o estado de um nó ou de um recurso em um nó, a vedação traz o cluster para um estado conhecido novamente.

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

A vedação ao nível de recurso garante que não haja corrupção de dados durante uma falha ao configurar um recurso. Por exemplo, pode usar isolamento de nível de recurso para marcar o disco num nó como desatualizado quando a ligação de comunicação falha.

A vedação no nível do nó garante que um nó não execute nenhum recurso. Isso é feito redefinindo o nó. O pacemaker suporta uma grande variedade de dispositivos de esgrima. Os exemplos incluem uma fonte de alimentação ininterrupta ou placas de interface de gerenciamento para servidores.

Para obter informações sobre o cercamento de um nó falhado, consulte os seguintes artigos:

Observação

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

sudo pcs property set stonith-enabled=false

A desativação da vedação é apenas para fins de teste. Se você planeja usar o Pacemaker em um ambiente de produção, deve planejar uma implementação de vedação dependendo do seu ambiente e mantê-lo habilitado.

Definir a propriedade do cluster, "cluster-recheck-interval"

cluster-recheck-interval indica o intervalo de sondagem no qual o cluster verifica se há alterações nos parâmetros de recursos, restrições ou outras opções de cluster. Se uma réplica ficar inativa, o cluster tentará reiniciar a réplica em um intervalo vinculado pelo valor failure-timeout e pelo valor cluster-recheck-interval. Por exemplo, se failure-timeout estiver definido como 60 segundos e cluster-recheck-interval estiver definido como 120 segundos, a reinicialização será tentada em um intervalo maior que 60 segundos, mas inferior a 120 segundos. Recomendamos que você defina o tempo limite de falha para 60 segundos e cluster-recheck-interval para um valor maior que 60 segundos. Não é recomendável definir cluster-recheck-interval para um valor pequeno.

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

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

Se já tiver um recurso de grupo de disponibilidade gerido por um cluster Pacemaker, o pacote Pacemaker 1.1.18-11.el7 introduziu uma alteração de comportamento para a configuração de cluster start-failure-is-fatal quando o seu valor é false. Essa alteração afeta o fluxo de trabalho de failover. Se uma réplica primária sofrer uma interrupção, é esperado que o cluster faça a comutação para uma das réplicas secundárias disponíveis. Em vez disso, os utilizadores notam que o cluster continua a tentar iniciar a réplica primária que falhou. Se esse primário nunca chegar a estar online (devido a uma interrupção permanente), o cluster nunca fará a conmutação para outra réplica secundária disponível. Devido a essa alteração, uma configuração recomendada anteriormente para definir start-failure-is-fatal não é mais válida e a configuração precisa ser revertida de volta para seu valor padrão de true.

Além disso, o recurso AG deverá ser atualizado de modo a 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 do recurso ag_clusterfailure-timeout para 60s, execute:

pcs resource update ag_cluster meta failure-timeout=60s

Para obter informações sobre as propriedades do cluster Pacemaker, consulte Pacemaker Clusters Properties.

Criar um logon do SQL Server para o Pacemaker

Atenção

Sua senha deve seguir a política de senha de padrão do SQL Server. Por padrão, a senha deve ter pelo menos oito caracteres e conter caracteres de três dos quatro conjuntos a seguir: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos. As palavras-passe podem ter até 128 caracteres. Use senhas tão longas e complexas quanto possível.

  1. Em todas as instâncias do SQL Server, crie um logon de servidor para o Pacemaker.

    O seguinte Transact-SQL cria um login. Substitua <password> por sua própria senha complexa.

    USE [master];
GO

CREATE LOGIN [pacemakerLogin]
    WITH PASSWORD = N'<password>';

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

    No momento da criação do grupo de disponibilidade, o utilizador do Pacemaker requer permissões de ALTER, CONTROLe VIEW DEFINITION no grupo de disponibilidade, após a sua criação, mas antes de qualquer nó ser adicionado ao mesmo.

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

    Substitua <password> por sua própria senha complexa.

    echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo '<password>' >> ~/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 de grupo de disponibilidade

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

RHEL 7

Use o seguinte create comando:

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

RHEL 8 e versões posteriores

Use o seguinte create comando:

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

Observação

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

Criar recurso IP virtual

Para criar o recurso do endereço IP virtual, execute o seguinte comando em um dos nós. 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á nenhum nome de servidor virtual equivalente no Pacemaker. Para usar uma cadeia de conexão que aponte para um nome de servidor de cadeia de caracteres em vez de um endereço IP, registre o endereço de recurso IP virtual e o nome do servidor virtual desejado no DNS. Para configurações de DR, registre o nome do servidor virtual desejado e o endereço IP com os servidores DNS no site primário e no site de DR.

Adicionar restrição de colocation

Quase todas as decisões em um cluster de marcapasso, como escolher onde um recurso deve ser executado, são feitas comparando 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 de marcapasso, você pode manipular as decisões do cluster com restrições. As restrições têm uma pontuação. Se uma restrição tem uma pontuação inferior a INFINITY, o Pacemaker considera-a uma recomendação. É obrigatória uma pontuação de INFINITY.

Para garantir que a réplica primária e os recursos ip virtuais sejam executados no mesmo host, defina uma restrição de colocation com uma pontuação de INFINITY. Para adicionar a restrição de colocation, execute o seguinte comando num nó.

RHEL 7

Quando você cria o recurso ag_cluster no RHEL 7, ele cria o recurso 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 cria o recurso como ag_cluster-clone. Use o seguinte comando:

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

RHEL 9 e versões posteriores

Quando você cria o ag_cluster recurso no RHEL 9 e versões posteriores, ele cria o recurso como ag_cluster-clone. Use o seguinte comando:

sudo pcs constraint colocation add virtualip with promoted ag_cluster-clone INFINITY with-rsc-role=Promoted

Adicionar restrição de ordenação

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

  1. Problemas de usuário pcs resource move para o grupo de disponibilidade primário de node1 para node2.

  2. O recurso IP virtual pára no nó 1.

  3. O recurso IP virtual começa 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 antes do 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 a primário.

Para evitar que o endereço IP aponte temporariamente para o nó com o secundário antes da operação de failover, adicione uma restrição de prioridade.

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

RHEL 7

sudo pcs constraint order promote ag_cluster-master then start virtualip

RHEL 8 e versões posteriores

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, não é possível usáTransact-SQL para fazer failover dos recursos do grupo de disponibilidade. Os recursos de cluster do SQL Server no Linux não são acoplados tão fortemente ao sistema operacional quanto em um WSFC (Cluster de Failover do Windows Server). O serviço SQL Server não está ciente da presença do cluster. Toda a orquestração é feita através das ferramentas de gerenciamento de cluster. Em RHEL ou Ubuntu, use as ferramentas pcs e em 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, consulte Failover.

Conteúdo relacionado

  • Last updated on