Esta página foi traduzida pela API Cloud Translation.

Configurar um cluster do SQL Server no Linux com grupos de disponibilidade sempre ativos e o Pacemaker

Este tutorial descreve como implantar um sistema de banco de dados do Microsoft SQL Server no Linux usando um grupo de disponibilidade sempre ativado (AOAG) e o Pacemaker como uma solução de alta disponibilidade (HA) e recuperação de desastres (DR). Para os fins deste documento, um desastre é um evento em que um banco de dados primário falha ou fica indisponível.

Um banco de dados primário pode falhar quando a região onde ele está falha ou fica inacessível. Mesmo que uma região esteja disponível e operando normalmente, um banco de dados primário pode falhar devido a um erro do sistema. Nesses casos, a recuperação de desastres é o processo de disponibilização de um banco de dados secundário para os clientes continuarem o processamento.

Este tutorial se destina a arquitetos de bancos de dados, administradores e engenheiros.

Preparar o projeto e a rede

Para preparar o projeto Google Cloud e a VPC para a implantação de grupos de disponibilidade sempre ativados do SQL Server, faça o seguinte:

No console do Google Cloud , abra o Cloud Shell clicando no botão Ativar o Cloud Shell .

Acessar o console do Google Cloud
Defina o ID do projeto padrão:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do seu projeto do Google Cloud .
Defina sua região padrão:
```
gcloud config set compute/region REGION
```
Substitua REGION pelo ID da região em que você quer implantar.
Defina a zona padrão:
```
gcloud config set compute/zone ZONE
```
Substitua ZONE pelo ID da zona em que você quer implantar. Ela precisa ser uma zona válida na região especificada na etapa anterior.

Criar VMs do Linux

Para conseguir HA e quórum para o cluster do SQL Server, implante três máquinas virtuais (VMs) do Linux para hospedar o cluster do SQL Server.

Inicialize as seguintes variáveis:
```
PD_SIZE=30
MACHINE_TYPE=n2-standard-8
```

Crie as VMs do Linux:

gcloud compute instances create node-1 \
--project=PROJECT_ID \
--zone REGION-a \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-a/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-2 \
--project=PROJECT_ID \
--zone REGION-b \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-2,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-b/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create node-3 \
--project=PROJECT_ID \
--zone REGION-c \
--machine-type $MACHINE_TYPE \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-3,image=projects/ubuntu-os-cloud/global/images/ubuntu-2004-focal-v20240426,mode=rw,size=$PD_SIZE,type=projects/PROJECT_ID/zones/REGION-c/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Substitua SUBNET_NAME pelo nome da sua sub-rede VPC.

Atualize o arquivo hosts em node-1, node-2 e node-3:

Observação: para uso em produção, a resolução de domínio precisa ser gerenciada por um servidor dedicado de Sistema de Nomes de Domínio (DNS).
1. Conecte-se a cada uma das VMs usando SSH. Consulte a documentação para saber como se conectar a VMs do Linux.
2. Abra o arquivo hosts para edição.
```
sudo vi /etc/hosts
```
3. Encontre o endereço IP interno de cada VM do Linux e anexe as entradas de host à parte inferior do arquivo.
  
  Acessar o Compute Engine
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Substitua NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP pelo endereço IP interno de cada VM do Linux.
Verifique a comunicação entre as VMs. Todas as VMs que participam do grupo de disponibilidade sempre ativado precisam conseguir se comunicar umas com as outras:
1. Volte a cada VM do Linux, execute os comandos de cada uma delas e verifique se todas podem se comunicar entre si.
```
ping -c 4 node-1
ping -c 4 node-2
ping -c 4 node-3
```

Instalar e configurar o SQL Server

Faça o download, instale e configure o mecanismo do SQL Server nas três VMs do Linux que vão participar do grupo de disponibilidade sempre ativado.

Use SSH para se conectar a node-1, node-2 e node-3 e siga estas etapas:

Importe as chaves públicas do repositório.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc \
| sudo tee /etc/apt/trusted.gpg.d/microsoft.asc

Registre o repositório Ubuntu do SQL Server.

sudo add-apt-repository \
"$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"

Atualize os arquivos de índice do pacote e instale o SQL Server.
```
sudo apt-get update
sudo apt-get install -y mssql-server
```

Configure o SQL Server:
1. Execute a ferramenta mssql-conf.
```
sudo /opt/mssql/bin/mssql-conf setup
```
2. Escolha a edição Developer para o SQL Server e aceite o contrato de licença.
  
  A edição Developer inclui todos os recursos empresariais, mas só pode ser usada em ambientes que não sejam de produção. Saiba mais sobre as edições do SQL Server e as licenças da Microsoft.
  
  Observação: para cada instância de VM, é necessária uma licença do SQL Server. Ao executar servidores de aplicativos da Microsoft, a Mobilidade de Licenças via Software Assurance ajuda na transição para o Google Cloud. Para mais informações, consulte Como usar a mobilidade de licença com apps de servidor da Microsoft. Se você não tiver sua própria licença e precisar comprar uma pelo Google (PAYG), siga as etapas em Adicionar uma licença do SQL Server a um disco de inicialização para comprar uma licença para cada instância de VM.
3. Especifique uma senha para a conta da SA.
4. Verifique se o serviço mssql-server está sendo executado.
```
systemctl status mssql-server --no-pager
```
Se houver um firewall ativado nas VMs, abra-o para o SQL Server:
1. Para verificar se Uncomplicated Firewall está instalado e ativado, execute o comando a seguir.
```
sudo ufw status
```
2. Se o status estiver ativo, execute os comandos a seguir para abrir as portas.
```
sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload
```
  Observação: se você estiver usando outras portas para o SQL Server ou para o endpoint do grupo de disponibilidade, mude as regras de firewall de acordo com isso.

Conectar-se ao SQL Server

Aqui, o SQL Server já está instalado. Para se conectar a ele, crie uma máquina Windows na mesma VPC e instale o SQL Server Management Studio (SSMS) para se conectar à instância do SQL Server recém-criada nas VMs:

Crie uma VM do Windows:

Volte ao Cloud Shell e execute o comando a seguir.

gcloud compute instances create node4 \
--project=PROJECT_ID \
--zone ZONE \
--subnet SUBNET_NAME \
--machine-type=n2-standard-4 \
--create-disk=auto-delete=yes,boot=yes,device-name=node4,image=projects/windows-cloud/global/images/windows-server-2022-dc-v20240415,mode=rw,size=50,type=projects/p3rf-sqlserver/zones/ZONE/diskTypes/pd-balanced

Conecte-se à VM do Windows em node-4 usando a Área de trabalho remota:
Atualize o arquivo hosts em node-4:
1. Abra o Bloco de Notas no modo de administrador.
2. Clique em Arquivo > Abrir e abra o arquivo hosts.
```
c:\Windows\System32\drivers\etc\hosts
```
3. Anexe as entradas de host à parte inferior do arquivo.
```
NODE1_INTERNAL_IP node-1
NODE2_INTERNAL_IP node-2
NODE3_INTERNAL_IP node-3
```
  Substitua NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP pelo respectivo endereço IP interno de cada VM.
4. Salve e saia.
Verifique a conectividade com as VMs do Linux:
1. Conectar-se à VM do Windows em node-4
2. Pressione o botão Iniciar e digite "powershell" na barra de pesquisa.
3. Clique para abrir o app do Windows PowerShell ISE.
4. Testa a conectividade executando os comandos abaixo.
```
ping node-1
ping node-2
ping node-3
```
Instale o Microsoft SQL Server Management Studio (SSMS) seguindo estas etapas:
1. Conecte-se à VM do Windows em node-4 usando a Área de trabalho remota.
2. Na sessão RDP, minimize todas as janelas e inicie o app Windows PowerShell ISE.
3. No prompt do PowerShell, faça o download do instalador do SSMS e execute-o.
```
Start-BitsTransfer `
-Source "https://aka.ms/ssmsfullsetup" `
-Destination "$env:Temp\ssms-setup.exe"
& $env:Temp\ssms-setup.exe
```
4. No instalador do SSMS, clique em Instalar.
5. Aceite a solicitação para permitir alterações.
6. Quando a instalação for concluída, clique em Reiniciar para reiniciar a máquina remota. Com isso, a sessão RDP será encerrada.
Conecte-se à instância do SQL Server no nó -1:
1. Volte à VM node-4 usando o RDP.
2. Abra o SSMS e conecte-se a node-1 usando os parâmetros a seguir.
```
Server name: node-1
Authentication: SQL Server Authentication
Login: sa
```
  Para mais informações, consulte Como se conectar a uma instância do SQL Server usando a documentação do SQL Server Management Studio.
3. Digite a senha da conta da SA criada durante a instalação.
4. Selecione Confiar no certificado do servidor.
5. Clique em Conectar.

Ativar o grupo de disponibilidade sempre ativado

No Linux, primeiro é necessário criar um grupo de disponibilidade para adicioná-lo como um recurso gerenciado pelo Pacemaker:

Ative o recurso do grupo de disponibilidade sempre ativado para cada instância do SQL Server que participa do grupo. Execute os seguintes comandos em node-1, node-2 e node-3:

Observação: reinicie o serviço mssql-server para que as alterações entrem em vigor.
```
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
```
Conecte-se à instância que é o host principal no grupo de disponibilidade usando o SSMS:

Dica: recomendamos escolher node-1 como host principal.
1. Abra uma nova janela de consulta.
2. Execute o snippet de código abaixo para criar uma chave de criptografia, um certificado e uma chave privada.
  
  Dica: escolha senhas fortes para a chave de criptografia e a chave privada. Lembre-se dessas senhas, porque você vai usá-las mais tarde.
  Observação: a senha precisa ter pelo menos 8 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.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert';
BACKUP CERTIFICATE my_ag_certificate
TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Substitua ENCRYPTION_KEY_PASSWORD e PRIVATE_KEY_PASSWORD pelas senhas da chave de criptografia e da chave privada.

Transferir os arquivos de certificado e chave

Os arquivos de certificado e de chave criados nas etapas anteriores precisam ser movidos para os nós secundários do SQL Server. Há vários métodos para mover os arquivos de certificado e de chave para os nós secundários em node-2 e em node-3.

Para outras opções de transferência, consulte Transferir arquivos para VMs do Linux.

Transferir os arquivos de certificado e chave usando o Cloud Storage

Crie um Cloud Storage para transferir arquivos dos nós de cluster primários para os secundários.

Crie um bucket do Cloud Storage:
1. Volte ao Cloud Shell e execute o seguinte comando:
```
gcloud storage buckets create gs://BUCKET_NAME \
--project=PROJECT_ID \
--location=REGION \
--public-access-prevention
```
  Substitua BUCKET_NAME pelo nome do bucket a ser criado. Substitua PROJECT_ID pelo ID do seu projeto do Google Cloud e REGION pelo ID da região em que o bucket será implantado.
Para mais informações, consulte Criar buckets.
Volte, use SSH para acessar node-1, node-2 e node-3 e inicialize a CLI do Google Cloud:
1. Execute o comando a seguir para inicializar a CLI do Google Cloud.
```
gcloud init
```
2. Escolha option [1] para usar a conta de serviço pré-instalada.
3. Insira o nome do projeto.
4. Insira n na pergunta para configurar a região e a zona padrão.
Volte para node-1 e copie os arquivos para o Cloud Storage:
1. Faça upload dos dois arquivos recém-criados para o Cloud Storage usando os comandos a seguir.
```
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.cer gs://BUCKET_NAME/
sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME/
```
  Substitua BUCKET_NAME pelo nome do bucket criado.
Volte para node-2 e node-3 e copie os arquivos do Cloud Storage:
1. Faça o download dos dois arquivos do Cloud Storage para node-2.
```
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.cer /var/opt/mssql/data/
sudo gcloud storage cp gs://BUCKET_NAME/my_ag_certificate.pvk /var/opt/mssql/data/
```
  Substitua BUCKET_NAME pelo nome do bucket criado.
2. Mude a propriedade dos arquivos em node-2 e em node-3 executando o comando em um shell raiz.
```
chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.*
chmod 660 /var/opt/mssql/data/my_ag_certificate.*
```
  Dica: saia do shell raiz depois de executar os comandos.

Configurar o endpoint de espelhamento de banco de dados

Nesta seção, você vai criar o endpoint do banco de dados usando uma chave de criptografia e um certificado compartilhado por cada nó no cluster do SQL Server para garantir a replicação segura de dados.

Volte à VM do Windows em node-4 para criar os endpoints de espelhamento de banco de dados:
1. Conecte-se aos bancos de dados do SQL Server em node-1, node-2 e node-3 usando o SSMS. Siga as etapas em Conectar-se ao SQL Server usando node-1, node-2 e node-3 como nome do servidor e as respectivas senhas definidas para a conta de SA.
2. Crie o certificado nas VMs secundárias node-2 e node-3 usando os arquivos copiados. Use as senhas que você forneceu ao criar o certificado e a chave no nó principal.
```
USE MASTER;

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD';
CREATE CERTIFICATE my_ag_certificate
FROM FILE = '/var/opt/mssql/data/my_ag_certificate.cer'
WITH PRIVATE KEY (
    FILE = '/var/opt/mssql/data/my_ag_certificate.pvk',
    DECRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD'
);
```
  Substitua ENCRYPTION_KEY_PASSWORD e PRIVATE_KEY_PASSWORD pelas senhas da chave de criptografia e da chave privada.
3. Volte ao SSMS para criar endpoints de espelhamento de banco de dados executando o comando T-SQL para node-1, node-2 e node-3.
  
  Dica: a porta de detecção padrão é 5022, mas é possível usar qualquer outra porta disponível.
```
CREATE ENDPOINT [my_ag_endpoint]
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE my_ag_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED;
```

Criar e configurar o grupo de disponibilidade sempre ativado

Em seguida, crie o grupo de disponibilidade sempre ativado do SQL Server usando o SQL Server Management Studio e use os endpoints criados anteriormente para a replicação.

Volte à VM do Windows e abra o SSMS:
1. Conecte-se ao mecanismo de banco de dados do SQL Server em node-1 e abra uma nova janela de consulta.

Crie um banco de dados e faça backup dele para preparar-se para a replicação:

USE MASTER;

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

Crie o grupo de disponibilidade sempre ativado:

Execute o comando T-SQL abaixo no SSMS em node-1, node-2 e node-3. Isso garante que os endpoints sejam ativados e que o SQL Server em cada nó esteja pronto para a replicação de dados.

IF (SELECT state FROM sys.endpoints WHERE name = N'my_ag_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [my_ag_endpoint] STATE = STARTED
END
GO

IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
END
IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
BEGIN
    ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
END
GO

Execute o comando T-SQL a seguir em node-1 para criar o AOAG.

USE [master]
GO

CREATE AVAILABILITY GROUP [aoag1]
WITH (
    AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
    DB_FAILOVER = OFF,
    DTC_SUPPORT = NONE,
    CLUSTER_TYPE = EXTERNAL,
    REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
)
FOR DATABASE [bookshelf]
REPLICA ON N'node-1' WITH (
    ENDPOINT_URL = N'TCP://node-1:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-2' WITH (ENDPOINT_URL = N'TCP://node-2:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
    N'node-3' WITH (ENDPOINT_URL = N'TCP://node-3:5022', FAILOVER_MODE = EXTERNAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)
);
GO

Execute o comando T-SQL abaixo em node-2 e em node-3 para que cada instância do SQL Server participe do novo grupo de disponibilidade.

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

ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE;
GO

Você criou um banco de dados chamado bookshelf e o adicionou a um novo grupo de disponibilidade chamado aoag1 na instância do SQL Server em execução em node-1. Node-2 e node-3 foram adicionados ao grupo de disponibilidade e os dados no banco de dados bookshelf serão replicados de maneira síncrona nas instâncias do SQL Server nos três nós.

Instalar e configurar o Pacemaker

O Pacemaker é um software de gerenciamento de recursos de alta disponibilidade e de código aberto que é usado com o mecanismo de cluster Corosync. Nesta seção, você instala e configura o Pacemaker em cada uma das VMs.

Criar um login do SQL Server para o gerenciador de clusters do Pacemaker

Nesta seção, você vai criar uma conta do SQL Server para que o Pacemaker faça login em cada instância do SQL Server e gerencie o grupo de disponibilidade.

Execute o comando T-SQL abaixo em node-1, node-2 e node-3:
```
USE [master];

CREATE LOGIN [pacemaker] with PASSWORD= N'PACEMAKER_LOGIN_PASSWORD';
GO
```
Substitua PACEMAKER_LOGIN_PASSWORD por uma senha para a conta do Pacemaker.

Execute o comando T-SQL para conceder ao Pacemaker as permissões de login para o grupo de disponibilidade:

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker];
GRANT VIEW SERVER STATE TO [pacemaker];
GO

Volte para usar SSH e acessar node-1, node-2 e node-3 para executar os comandos e salvar o nome de usuário e a senha do Pacemaker na pasta de secrets do SQL Server:

echo 'pacemaker' >> ~/pacemaker-passwd
echo 'PACEMAKER_LOGIN_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

Substitua PACEMAKER_LOGIN_PASSWORD pela senha da conta do Pacemaker.

Instalar o Pacemaker

Em seguida, instale o Pacemaker e configure uma conta de login em todas as VMs do Linux para o gerenciamento de recursos.

Abra portas de firewall para o Pacemaker:
1. Para verificar se Uncomplicated Firewall está instalado e ativado, execute o comando a seguir em node-1, node-2 e node-3.
```
sudo ufw status
```
2. Se o ufw estiver ativado, abra portas de firewall em node-1, node-2 e node-3.
```
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 5405/udp
sudo ufw allow 21064/tcp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
```
  Observação: se você estiver usando outras portas para o SQL Server ou para o endpoint do grupo de disponibilidade, mude as regras de firewall de acordo com isso.

Instale o Pacemaker em node-1, node-2 e node-3:

sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents  fence-agents corosync python3-azure pcs

Defina uma nova senha para o usuário hacluster em node-1, node-2 e node-3:

Observação: defina a mesma senha nos três nós. Essa senha será necessária durante o restante da configuração.
```
sudo passwd hacluster
```

Configurar o Corosync

Agora, configure o Corosync para gerenciar a associação e as mensagens no cluster.

Crie uma chave de autenticação para o Corosync em node-1:
```
sudo corosync-keygen
```

Modifique o arquivo de configuração do Corosync:

Retorne a node-1 e modifique o arquivo corosync.conf.
```
sudo vi /etc/corosync/corosync.conf
```

Atualize as seções destacadas. Após a edição, o arquivo deve ficar semelhante ao exemplo a seguir.

# Please read the corosync.conf.5 manual page
totem {
    version: 2

    # Corosync itself works without a cluster name, but DLM needs one.
    # The cluster name is also written into the VG metadata of newly
    # created shared LVM volume groups, if lvmlockd uses DLM locking.
    cluster_name: my_agcluster

    # crypto_cipher and crypto_hash: Used for mutual node authentication.
    # If you choose to enable this, then do remember to create a shared
    # secret with "corosync-keygen".
    # enabling crypto_cipher, requires also enabling of crypto_hash.
    # crypto works only with knet transport
    transport: udpu
    crypto_cipher: none
    crypto_hash: none
}

logging {
    # Log the source file and line where messages are being
    # generated. When in doubt, leave off. Potentially useful for
    # debugging.
    fileline: off
    # Log to standard error. When in doubt, set to yes. Useful when
    # running in the foreground (when invoking "corosync -f")
    to_stderr: yes
    # Log to a log file. When set to "no", the "logfile" option
    # must not be set.
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    # Log to the system log daemon. When in doubt, set to yes.
    to_syslog: yes
    # Log debug messages (very verbose). When in doubt, leave off.
    debug: off
    # Log messages with time stamps. When in doubt, set to hires (or on)
    #timestamp: hires
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}
quorum {
    # Enable and configure quorum subsystem (default: off)
    # see also corosync.conf.5 and votequorum.5
    provider: corosync_votequorum
}
nodelist {
    # Change/uncomment/add node sections to match cluster configuration

    node {
        # Hostname of the node
        name: node-1
        # Cluster membership node identifier
        nodeid: 1
        # Address of first link
        ring0_addr: NODE1_INTERNAL_IP
        # When knet transport is used it's possible to define up to 8 links
        #ring1_addr: 192.168.1.1
    }
    node {
        name: node-2
        nodeid: 2
        ring0_addr: NODE2_INTERNAL_IP
    }
    node {
        name: node-3
        nodeid: 3
        ring0_addr: NODE3_INTERNAL_IP
    }
    # ...
}

Substitua NODE1_INTERNAL_IP, NODE2_INTERNAL_IP e NODE3_INTERNAL_IP pelos endereços IP internos de cada nó.

Transferir arquivos de configuração usando o Cloud Storage

Faça o upload da chave de autenticação gerada e dos arquivos de configuração do Corosync de node-1 para o bucket do Cloud Storage:
```
sudo gcloud storage cp /etc/corosync/authkey gs://BUCKET_NAME/
sudo gcloud storage cp  /etc/corosync/corosync.conf gs://BUCKET_NAME/
```
Substitua BUCKET_NAME pelo nome do bucket criado anteriormente.
Faça o download dos arquivos de chave de autenticação e de configuração para node-2 e node-3:
```
sudo gcloud storage cp gs://BUCKET_NAME/authkey /etc/corosync/
sudo gcloud storage cp gs://BUCKET_NAME/corosync.conf /etc/corosync/
```
Substitua BUCKET_NAME pelo nome do bucket para onde os arquivos de configuração do Corosync foram transferidos.

Atualize as permissões dos arquivos em node-2 e em node-3:

sudo chmod 400 /etc/corosync/authkey
sudo chmod 400 /etc/corosync/corosync.conf

Reiniciar e verificar a comunicação de cluster

Reinicie os serviços do Pacemaker e do Corosync em node-1, node-2 e node-3:
```
sudo systemctl restart pacemaker corosync
```
Confirme o status do cluster executando o comando em node-1:
```
sudo crm status
```
Os três nós vão aparecer on-line.

Configurar o cluster

Em seguida, você vai configurar o cluster do Pacemaker criando um recurso para o grupo de disponibilidade sempre ativado do SQL Server.

Execute este comando em node-1 para definir as propriedades do cluster:

sudo crm configure property stonith-enabled=false
sudo crm configure property cluster-recheck-interval=2min
sudo crm configure property start-failure-is-fatal=true

Para mais informações, consulte Opções de cluster.

Para autorizar os nós no cluster, execute o comando em node-1. Use a senha definida anteriormente para a conta hacluster:
```
sudo pcs cluster auth -u hacluster
```
Os três nós vão aparecer como autorizados.
Instale o agente de recursos do SQL Server para a integração com o Pacemaker em node-1, node-2 e node-3:
```
sudo apt-get install mssql-server-ha
```
Volte a node-1 e crie um recurso de grupo de disponibilidade no cluster:
1. Execute o Resource Manager do cluster.
```
sudo crm
```
2. Digite configure para acessar o menu de configuração.
3. Insira a configuração a seguir.
```
primitive aoag1-cluster \
ocf:mssql:ag \
params ag_name="aoag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 aoag1-cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
```
4. Digite commit para confirmar as mudanças.
  
  Observação: você vai receber um aviso de que nenhuma regra de isolamento foi configurada. Ignore essa mensagem. Uma regra de isolamento será configurada em uma etapa posterior.
5. Digite exit para sair do Resource Manager do cluster.
6. Verifique a configuração.
```
sudo crm status
```
  Observe que node-1 foi promovido a nó principal. Node-2 e node-3 precisam ser definidos como nós secundários.

Configurar o balanceador de carga e o listener do grupo de disponibilidade

Nesta seção, você vai criar um endereço IP virtual e um recurso de verificação de integridade no cluster usando um balanceador de carga TCP de passagem interno que roteia o tráfego para o grupo de disponibilidade.

Volte ao Cloud Shell e reserve um endereço IP estático que será usado como o IP do cluster:

gcloud compute addresses create aoag1-cluster \
--region REGION \
--subnet SUBNET_NAME
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \
--region $(gcloud config get-value compute/region) \
--format=value\(address\)) && \
echo "Cluster IP address: $CLUSTER_ADDRESS"

Substitua REGION e SUBNET_NAME pela região e sub-rede em que as VMs do Linux foram implantadas.

Crie grupos não gerenciados de instâncias para cada um dos nós do cluster e atribua-os ao grupo de instâncias recém-criado. Execute os seguintes comandos no Cloud Shell:

gcloud compute instance-groups unmanaged create node-1-uig \
--zone=REGION-a
gcloud compute instance-groups unmanaged add-instances node-1-uig \
--zone=REGION-a \
--instances=node-1

gcloud compute instance-groups unmanaged create node-2-uig \
--zone=REGION-b
gcloud compute instance-groups unmanaged add-instances node-2-uig \
--zone=REGION-b \
--instances=node-2

gcloud compute instance-groups unmanaged create node-3-uig \
--zone=REGION-c
gcloud compute instance-groups unmanaged add-instances node-3-uig \
--zone=REGION-c \
--instances=node-3

Substitua REGION pela região em que as VMs do Linux foram implantadas.

Crie uma verificação de integridade TCP. Os balanceadores de carga usam verificações de integridade para determinar quais instâncias de back-end respondem corretamente ao tráfego.
```
gcloud compute health-checks create tcp aoag1-healthcheck \
--port=HEALTH_CHECK_PORT --proxy-header=NONE \
--check-interval=10 --timeout=10 --unhealthy-threshold=2 \
--healthy-threshold=2
```
Escolha uma porta que esteja livre e no intervalo privado de 49152 a 65535 e substitua HEALTH_CHECK_PORT pelo valor dela. Por exemplo, 60000.

Para mais informações, consulte a Visão geral das verificações de integridade.

Adicione tags de rede aos nós do cluster. A tag de rede é usada pela regra de firewall para a verificação de integridade:

gcloud compute instances add-tags node-1 \
--tags NETWORK_TAG_NAME \
--zone REGION-a
gcloud compute instances add-tags node-2 \
--tags NETWORK_TAG_NAME \
--zone REGION-b
gcloud compute instances add-tags node-3 \
--tags NETWORK_TAG_NAME \
--zone REGION-c

Substitua NETWORK_TAG_NAME por um nome para a tag de rede.

Crie uma regra de firewall para permitir que as verificações de integridade acessem os nós do cluster com base no nome da tag:

gcloud compute firewall-rules create mssql-aoag1-fw-rule \
--network VPC_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags NETWORK_TAG_NAME \
--rules tcp:HEALTH_CHECK_PORT

Para mais informações, consulte Regras de firewall para verificações de integridade.

Crie o serviço de back-end do balanceador de carga:

gcloud compute backend-services create aoag1-backend \
--load-balancing-scheme internal \
--health-checks aoag1-healthcheck \
--no-connection-drain-on-failover \
--drop-traffic-if-unhealthy \
--failover-ratio 1.0 \
--region REGION \
--global-health-checks

Adicione os três grupos não gerenciados de instâncias ao serviço de back-end:

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-1-uig \
--instance-group-zone REGION-a \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-2-uig \
--instance-group-zone REGION-b \
--failover \
--region REGION

gcloud compute backend-services add-backend aoag1-backend \
--instance-group node-3-uig \
--instance-group-zone REGION-c \
--failover \
--region REGION

Defina uma regra de encaminhamento para o balanceador de carga. Uma regra de encaminhamento especifica o protocolo e as portas em que o balanceador de carga aceita tráfego:
```
gcloud compute forwarding-rules create aoag1-fwd-rule \
--load-balancing-scheme internal \
--address CLUSTER_ADDRESS \
--subnet SUBNET_NAME \
--region REGION \
--backend-service aoag1-backend \
--ports ALL
```
Substitua CLUSTER_ADDRESS pelo endereço IP reservado anteriormente.

Dica: se você precisar que o cluster seja acessível para clientes em qualquer região da rede VPC ou de uma rede conectada, inclua --allow-global-access na definição da regra de encaminhamento.

Para mais informações, consulte Regras de encaminhamento.
Para concluir e testar a configuração do balanceador de carga de rede, instale e configure HAProxy tcp listener em node-1, node-2 e node-3:
1. Instale o HAProxy.
```
sudo apt-get install haproxy
```
2. Escolha Y para concluir a instalação.
3. Edite o arquivo haproxy.cfg.
```
sudo vi /etc/haproxy/haproxy.cfg
```
4. Na seção de padrões de haproxy.cfg file, mude o modo para tcp.
5. Anexe a seguinte seção ao final do arquivo haproxy.cfg.
```
#---------------------------------------------------------------
# Set up health check listener for SQL Server Availability Group
#---------------------------------------------------------------
listen healthcheck
bind *:HEALTH_CHECK_PORT
```
  Substitua HEALTH_CHECK_PORT pela porta de verificação de integridade selecionada anteriormente. Por exemplo, 6000.
6. Inicie o serviço para confirmar se ele está configurado corretamente:
```
sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service
```
7. Acesse a página Balanceamento de carga e clique no balanceador de carga. Os três grupos não gerenciados de instâncias agora devem ser indicados como íntegros.
  
  Acessar o Balanceamento de carga
  - Como alternativa, execute o comando a seguir no Cloud Shell para conferir o status do serviço de back-end.
```
gcloud compute backend-services get-health aoag1-backend \
--region REGION
```
    Substitua REGION pela região em que as VMs do Linux foram implantadas.
8. Quando os três grupos não gerenciados de instâncias estiverem íntegros, prossiga para a próxima etapa.
  
  Observação: se o grupo não gerenciado de instâncias não estiver íntegro, talvez seja preciso reiniciar haproxy.service no nó em questão.
```
sudo systemctl restart haproxy.service
```
Crie o recurso de verificação de integridade no Pacemaker:
1. Use SSH para acessar node-1 e crie um recurso de verificação de integridade para o serviço HAProxy no cluster do Pacemaker:
```
sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s
```
2. Verifique se o recurso de integridade foi iniciado no nó principal node-1:
```
sudo crm status
```
3. Se o recurso de verificação de integridade não for iniciado no nó principal, mova-o com os seguintes comandos:
```
sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck
```
  A verificação de integridade do balanceador de carga só será considerada íntegra para node-1.
  
  Acessar o Balanceamento de carga
Crie um recurso de endereço IP virtual no cluster do Pacemaker:
1. Volte para usar SSH e acessar node-1 para encontrar o nome da interface de rede do nó. Você precisará dele na próxima etapa.
```
ip -c link
```
2. Crie o recurso de endereço IP virtual.
```
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \
ip="CLUSTER_ADDRESS" nic=NIC_NAME cidr_netmask=32 \
op monitor interval=3600s timeout=60s
```
  Substitua NIC_NAME pelo nome da interface de rede da etapa anterior e CLUSTER_ADDRESS pelo endereço IP reservado.
3. Verifique se o recurso de endereço IP virtual foi iniciado no host principal.
```
sudo crm status
```
4. Se o recurso de endereço IP virtual não tiver sido iniciado no nó principal, mova-o com os comandos a seguir.
```
sudo pcs resource move aoag1-vip node-1
```
5. Agrupe os recursos de verificação de integridade e de endereço IP virtual.
```
sudo pcs resource group add aoag1-group \
aoag1-healthcheck aoag1-vip
```
6. Crie uma restrição que localize o novo grupo no mesmo nó que o principal.
```
sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
```

Criar um listener para o grupo de disponibilidade do SQL Server

As conexões com o SQL Server que usam grupos de disponibilidade devem usar um nome de listener do grupo de disponibilidade em vez do nome do servidor. Se houver um failover, o listener vai redirecionar automaticamente as conexões para o novo nó principal no cluster.

Volte ao SSMS e conecte-se ao banco de dados node-1.

Execute a seguinte consulta:

ALTER AVAILABILITY GROUP aoag1
ADD LISTENER 'aoag1-listener' (
    WITH IP (('CLUSTER_ADDRESS','255.255.255.0')), PORT=1433
);
GO

Substitua CLUSTER_ADDRESS pelo endereço IP reservado.

Configurar um isolamento STONITH

O STONITH é uma estratégia de isolamento para manter a integridade dos nós em um cluster de HA. O serviço STONITH funciona no nível do nó e protege o cluster contra nós que não respondem ou estão em um estado desconhecido. Recomendamos o dispositivo de isolamento fence_gce especializado para o Compute Engine em Google Cloud.

Configurar dispositivos de isolamento

Verifique se o agente de isolamento fence_gce do Compute Engine está instalado em node1:
```
sudo pcs stonith list | grep fence_gce
```
Veja mais informações em:
- Agente de isolamento para o Google Compute Engine.
- Para conferir os parâmetros associados à execução do agente.
```
sudo pcs stonith describe fence_gce
```

Em node-1, crie os recursos do tipo de isolamento fence_gce para cada um dos nós participantes:

sudo pcs stonith create node-1-fence fence_gce \
plug=node-1 \
zone=REGION-a \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-2-fence fence_gce \
plug=node-2 \
zone=REGION-b \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

sudo pcs stonith create node-3-fence fence_gce \
plug=node-3 \
zone=REGION-c \
project=PROJECT_ID \
pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \
op monitor interval="300s" timeout="120s" \
op start interval="0" timeout="60s"

Substitua REGION pela região em que as VMs do Linux foram implantadas e PROJECT_ID pelo ID do projeto.

É possível testar o status dos agentes de isolamento executando o comando status:

sudo fence_gce -o status -n node-1 --zone=REGION-a
sudo fence_gce -o status -n node-2 --zone=REGION-b
sudo fence_gce -o status -n node-3 --zone=REGION-c

Crie restrições de local para os dispositivos de isolamento para garantir que eles sejam executados apenas nas instâncias pretendidas:

sudo pcs constraint location node-1-fence avoids node-1
sudo pcs constraint location node-2-fence avoids node-2
sudo pcs constraint location node-3-fence avoids node-3

Ative o isolamento no cluster do Pacemaker e defina o tempo limite de isolamento do cluster:

sudo pcs -f stonith_cfg property set stonith-enabled=true
sudo pcs property set stonith-timeout="300s"

Verifique o status do cluster:
```
sudo crm status
```

Testar dispositivos de isolamento

Após a configuração dos dispositivos de isolamento, teste-os seguindo as etapas abaixo.

Interrompa o isolamento em node-2:
1. Conecte-se a node-1 e execute o comando a seguir para testar o dispositivo de isolamento associado a node-2 no cluster.
```
fence_gce -o off -n node-2 --zone=REGION-b
```
2. Verifique o status do cluster.
```
sudo crm status
```
3. Observe também que node-2 está desativado no Compute Engine.
  
  Acessar o Compute Engine
Reinicie o isolamento em node-2:
1. Retorne a node-1 e reinicie a instância novamente executando o comando a seguir.
```
fence_gce -o on -n node-2 --zone=REGION-b
```
2. Verifique o status do cluster no Pacemaker e no Compute Engine. Depois de um curto período, você vai notar que node-2 está novamente on-line.
```
sudo crm status
```

Configurar o Corosync para reinicialização atrasada

Para evitar problemas de tempo e garantir a ordem correta das operações realizadas em caso de uma ação de isolamento, recomendamos atrasar a reinicialização do serviço do Corosync em 60 segundos.

Para mais informações, consulte o artigo da base de conhecimento da Red Hat.

Crie um arquivo drop-in do systemd que defina um atraso na inicialização do serviço do Corosync em node-1, node-2 e node-3:
1. Abra o corosync.service para edição.
```
sudo systemctl edit corosync.service
```
2. Anexe as linhas a seguir, salve o arquivo e saia do editor.
```
[Service]
ExecStartPre=/bin/sleep 60
```
3. Atualize o gerenciador de serviços e verifique se a configuração foi considerada.
```
sudo systemctl daemon-reload
systemctl status corosync.service --no-pager
```
  Se a seção Drop-in apareceu, as configurações do arquivo drop-in foram consideradas.

Testar o failover

Agora está tudo pronto para testar se o failover funciona corretamente.

Conecte-se à VM do Windows em node-4 pela Área de trabalho remota:
Abra uma sessão do PowerShell:

Execute o script a seguir:

while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=CLUSTER_ADDRESS;User ID=sa;Password=SA_PASSWORD;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT @@SERVERNAME"

  $Adapter = New-Object System.Data.SqlClient.SqlDataAdapter $Cmd
  $Data = New-Object System.Data.DataSet
  $Adapter.Fill($Data) | Out-Null
  $Data.Tables[0] + (Get-Date -Format "MM/dd/yyyy HH:mm:ss")

  Start-Sleep -Seconds 2
}

Substitua CLUSTER_ADDRESS pelo endereço IP do listener e SA_PASSWORD pela senha da conta de SA no SQL Server.

A cada dois segundos, o script se conecta ao SQL Server usando o listener do grupo de disponibilidade ou o listener de DNN e consulta o nome do servidor.

Deixe o script em execução.

Volte para usar SSH e acessar node-1 para executar os comandos e acionar um failover para node-2:

sudo pcs resource move ms-ag1 node-2 --master
sudo pcs resource move aoag1-group  node-2
sudo pcs resource move aoag1-vip node-2

Volte à sessão do PowerShell em node-4:
1. Observe a saída do script em execução e veja que o nome do servidor mudou de node-1 para node-2 como resultado do failover.

Volte a node-1 e inicie um failback para node-1:

sudo pcs resource move ms-ag1 node-1 --master
sudo pcs resource move aoag1-group  node-1
sudo pcs resource move aoag1-vip node-1

Volte ao PowerShell em node-4 e interrompa o script pressionando Ctrl+C.