Configurar o cluster do Ubuntu e o recurso do grupo de disponibilidade

Artigo
08/02/2022
12 minutos para o fim da leitura

Aplica se a:SQL Server (todas as versões com suporte) – Linux

Este artigo descreve como criar um cluster de três nós no Ubuntu 20.04 e 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.

A integração do SQL Server com o Pacemaker em Linux não está tão acoplada quanto a do WSFC em Windows. No SQL Server, não há nenhum conhecimento sobre a presença do cluster, toda a orquestração ocorre de fora para dentro e o serviço é controlado como uma instância autônoma pelo gerenciador de cluster. Além disso, o nome da rede virtual é específico do WSFC e não há equivalente ao mesmo no Pacemaker. As exibições de gerenciamento dinâmico Always On que consultam as informações do cluster retornam linhas vazias.

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 uma solução de cluster de failover.

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:

Configurar o SQL Server nos nós de cluster.
Criar o grupo de disponibilidade.
Configurar um gerenciador de recursos de cluster, como o Pacemaker. Estas instruções são descritas neste documento.

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

Os ambientes de produção exigem um agente de isolamento, como o STONITH 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. No momento, 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.

O isolamento normalmente é implementado no sistema operacional e depende do ambiente. Encontre instruções sobre isolamento na documentação do distribuidor do sistema operacional.
Adicione o grupo de disponibilidade como um recurso no cluster.

Instalar e configurar o Pacemaker em cada nó de cluster

Em todos os nós, abra as portas do firewall. Abra a porta para o serviço de alta disponibilidade do Pacemaker, a instância do SQL Server e o ponto de extremidade do grupo de disponibilidade. A porta TCP padrão para o servidor que executa o SQL Server é a 1433.
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp

sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint

sudo ufw reload
```
Como alternativa, você pode simplesmente desabilitar o firewall:
```
sudo ufw disable
```
Instale os pacotes do Pacemaker. Em todos os nós, execute os comandos a seguir:
```
sudo apt-get install pacemaker pcs fence-agents resource-agents
```
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
```

Habilite e inicie o serviço pcsd e o Pacemaker

O comando a seguir habilita e inicia o serviço pcsd e o Pacemaker. Execute em todos os nós. Isso permite que os nós reingressem no cluster após a reinicialização.

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

O comando enable pacemaker pode ser concluído com o seguinte erro:

pacemaker Default-Start contains no runlevels, aborting.

O erro é inofensivo e a configuração do cluster pode continuar.

Criar o cluster

Remova todas as configurações de cluster existentes de todos os nós.

A execução do comando sudo apt-get install pcs instala o pacemaker, o corosync e o pcs ao mesmo tempo e começa a executar os 3 serviços. Iniciar o corosync gera um arquivo /etc/cluster/corosync.conf de modelo. Para que as próximas etapas tenham sucesso, esse arquivo não deve existir; portanto, a solução alternativa é interromper o pacemaker ou corosync e excluir /etc/cluster/corosync.conf. Com isso, as próximas etapas serão concluídas com sucesso. O comando pcs cluster destroy faz a mesma coisa e pode ser usado como uma etapa de configuração de cluster inicial de execução única.

O comando a seguir remove todos os arquivos de configuração de cluster existentes e interrompe todos os serviços de cluster, destruindo permanentemente o cluster. Execute-o como uma primeira etapa em um ambiente prévio ao de produção. Observe que o comando pcs cluster destroy desabilitou o serviço Pacemaker e precisa ser reabilitado. Execute o seguinte comando em todos os nós.

Aviso

O comando destrói todos os recursos de cluster existentes.
```
sudo pcs cluster destroy 
sudo systemctl enable pacemaker
```
Crie o cluster.

Iniciar o cluster (pcs cluster start) pode falhar com o seguinte erro, pois o arquivo de log configurado em /etc/corosync/corosync.conf, que é criado quando o comando de instalação do cluster é executado, está errado. Para contornar esse problema, altere o arquivo de log para: /var/log/corosync/corosync.log. Como alternativa, você pode criar o aquivo /var/log/cluster/corosync.log por conta própria.
```
Job for corosync.service failed because the control process exited with error code. 
See "systemctl status corosync.service" and "journalctl -xe" for details.
```
O comando a seguir cria um cluster de três nós. Antes de executar o script, substitua os valores entre < ... >. Execute o comando a seguir no nó primário.
```
sudo pcs host auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
```
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 Pacemaker for criado.

Um cenário em que essa regra é importante é usar nomes de domínio totalmente qualificados (FQDN). 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ó.
Se você tiver configurado um cluster anteriormente nos mesmos nós, será necessário usar a opção --force ao executar pcs cluster setup. Isso é equivalente à execução de pcs cluster destroy e o serviço Pacemaker precisa ser reabilitado usando sudo systemctl enable pacemaker.

Configurar isolamento (STONITH)

Os fornecedores do cluster do Pacemaker exigem que o STONITH esteja habilitado e que um dispositivo de isolamento esteja definido para uma configuração de cluster com suporte. (STONITH são as iniciais em inglês pra "acertar a cabeça do outro nó".) 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 é usado para colocar o cluster em um estado conhecido novamente.

O isolamento de nível do recurso garante que não ocorra corrupção de dados se houver uma interrupção. Você pode usar o isolamento no nível do recurso, por exemplo, com o DRBD (Dispositivo de Bloco Replicado Distribuído) 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 pela redefinição do nó e pela implementação do Pacemaker do que é chamado STONITH. O Pacemaker é compatível com uma grande variedade de dispositivos de isolamento, como no-break ou cartões de interface de gerenciamento para servidores.

Para obter mais informações, confira Clusters do Pacemaker do zero e Isolamento e STONITH.

Como a configuração de isolamento no nível do nó depende muito do seu ambiente, nós a desabilitamos para este tutorial (ela pode ser configurada posteriormente). Execute o script a seguir no nó primário:

sudo pcs property set stonith-enabled=false

Neste exemplo, a desabilitação do STONITH destina-se apenas a fins de teste. Se você pretende usar o Pacemaker em um ambiente de produção, deve planejar uma implementação do STONITH dependendo do ambiente e mantê-lo habilitado. Contate o fornecedor do sistema operacional para obter informações sobre os agentes de isolamento em qualquer distribuição específica.

Defina a propriedade de cluster cluster-recheck-interval

A propriedade cluster-recheck-interval indica o intervalo de sondagem segundo o qual o cluster verifica se há alterações nos parâmetros de 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. Você deve definir failure-timeout como 60 segundos e cluster-recheck-interval como um valor maior que 60 segundos. Não é recomendável definir cluster-recheck-interval como um valor menor.

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

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

Se você já tiver um recurso de grupo de disponibilidade gerenciado por um cluster do Pacemaker, observe que todas as distribuições que usam o pacote do Pacemaker 1.1.18-11.el7 ou posterior introduzem uma alteração de comportamento para a configuração de cluster start-failure-is-fatal quando seu valor é 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 continua 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 de volta para seu valor padrão true

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

Para atualizar o valor da propriedade para true, execute:

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

Atualize a propriedade do recurso do AG existente failure-timeout para a execução de 60s (substitua ag1 pelo nome do recurso de grupo de disponibilidade):

pcs resource update ag1 meta failure-timeout=60s

Instale o agente de recursos do SQL Server para integração com o Pacemaker

Execute os seguintes comandos em todos os nós.

sudo apt-get install mssql-server-ha

Em todos os SQL Servers, crie um logon de servidor para 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.

Em todos os SQL Servers, salve as credenciais do 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 abaixo cria um recurso do tipo principal/réplica ocf:mssql:ag para o grupo de disponibilidade com o nome ag1.

sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s 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. Antes de executar o script, substitua os valores entre < ... > 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 de servidor de cadeia de caracteres e não usar o endereço IP, registre o endereço de recurso do IP 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 e 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ó.)

Use restrições para configurar as decisões do cluster. As restrições têm uma pontuação. Se uma restrição tiver uma pontuação menor que INFINITY, ela será apenas uma recomendação. Uma pontuação igual a INFINITY significa que ela é obrigatória.

Para garantir que a réplica primária e o recurso de IP virtual estejam 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ó.

sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY

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 é:

O usuário emite pcs resource move ao grupo de disponibilidade primário do node1 para o node2.
O recurso de IP virtual é interrompido no node1.
O recurso de IP virtual é iniciado no node2.

Neste ponto, o endereço IP aponta temporariamente para o node2, enquanto o node2 ainda é um secundário de pré-failover.
O grupo de disponibilidade primário no node1 é rebaixado para secundário.
O grupo de disponibilidade secundário no node2 é 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ó:

sudo pcs constraint order promote ag_cluster-clone then start virtualip

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 Ubuntu, você deve usar pcs.

Próximas etapas

Operar grupo de disponibilidade de HA