Configurar um cluster do SQL Server no Linux com grupos de disponibilidade Always On e Pacemaker

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

Um banco de dados primário pode falhar quando a região em que está localizado falhar ou se tornar inacessível. Mesmo que uma região esteja disponível e operando normalmente, um banco de dados primário poderá falhar devido a um erro do sistema. Nestes casos, a recuperação de desastres é o processo de disponibilizar um banco de dados secundário aos clientes para processamento contínuo.

Este tutorial é destinado a arquitetos, administradores e engenheiros de banco de dados.

Objetivos

Custos

Este tutorial usa componentes faturáveis ​​de Google Cloud, incluindo:

Use a calculadora de preços para gerar uma estimativa de custo com base no uso projetado.

Antes de começar

Para este tutorial, você precisa de um Google Cloud projeto. Você pode criar um novo ou selecionar um projeto já criado:

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Make sure that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

Prepare o projeto e a rede

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

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

    Vá para o Google Cloud console

  2. Defina seu ID de projeto padrão:

    gcloud config set project PROJECT_ID

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

  3. Defina sua região padrão:

    gcloud config set compute/region REGION

    Substitua REGION pelo ID da região na qual você deseja implantar.

  4. Defina sua zona padrão:

    gcloud config set compute/zone ZONE

    Substitua ZONE pelo ID da zona na qual você deseja implantar. Deve ser uma zona válida na região especificada na etapa anterior.

Crie VMs Linux

Para obter alta disponibilidade e quorum para o cluster do SQL Server, implante três VMs (máquinas virtuais) Linux para hospedar o cluster do SQL Server.

  1. Inicialize as seguintes variáveis:

    PD_SIZE=30
MACHINE_TYPE=n2-standard-8

  2. Crie as VMs 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.

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

    1. Conecte-se a cada uma das suas VMs usando SSH. Consulte a documentação Conectar-se a VMs Linux para obter mais informações.

    2. Abra o arquivo hosts para edição.

      sudo vi /etc/hosts

    3. Encontre o endereço IP interno de cada VM Linux e anexe as entradas do host na parte inferior do arquivo.

      Acesse 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 Linux.

  4. Verifique a comunicação entre suas VMs. Todas as VMs que participam do grupo de disponibilidade Always On devem poder se comunicar com outras VMs:

    1. Retorne a cada VM Linux, execute os comandos de cada VM e verifique se todas as VMs 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

Baixe, instale e configure o mecanismo SQL Server nas três VMs Linux que participarão do grupo de disponibilidade Always On.

  1. SSH para node-1 , node-2 e node-3 e execute as seguintes etapas:

    1. Importe as chaves do repositório público. 

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

    2. Registre o repositório SQL Server Ubuntu. 

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

    3. Atualize os arquivos de índice do pacote e instale o SQL Server. 

      sudo apt-get update
sudo apt-get install -y mssql-server

  2. Configurar o SQL Server:

    1. Execute a ferramenta mssql-conf. 

      sudo /opt/mssql/bin/mssql-conf setup

    2. Escolha a edição Developer para a edição do SQL Server e aceite o contrato de licença.

      A edição para desenvolvedores inclui todos os recursos empresariais, mas você pode usá-la apenas para ambientes que não sejam de produção. Mais informações estão disponíveis sobre edições do SQL Server e licenças da Microsoft .

    3. Especifique uma senha para a conta SA.

    4. Verifique se o serviço mssql-server está em execução. 

      systemctl status mssql-server --no-pager

  3. Se você tiver um firewall habilitado em suas VMs, abra o firewall do SQL Server:

    1. Verifique se Uncomplicated Firewall está instalado e habilitado executando o seguinte comando. 

      sudo ufw status

    2. Se o status estiver ativo, execute os seguintes comandos para abrir as portas. 

      sudo ufw allow 1433
sudo ufw allow 5022
sudo ufw reload

Conecte-se ao SQL Server

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

  1. Crie uma VM do Windows:

    1. Retorne 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

  2. Conecte-se à VM do Windows no node-4 usando a Área de Trabalho Remota:

  3. Atualize o arquivo hosts no node-4 :

    1. Abra o bloco de notas no modo administrador.

    2. Clique em Arquivo > Abrir e abra o arquivo hosts. 

      c:\Windows\System32\drivers\etc\hosts

    3. Anexe as entradas do host ao final 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.

  4. Verifique a conectividade com as VMs do Linux:

    1. Conecte-se à VM do Windows no node-4
    2. Clique no botão Iniciar e digite powershell na barra de pesquisa.
    3. Clique para abrir o aplicativo ISE do Windows PowerShell.

    4. Testa a conectividade executando os comandos a seguir. 

      ping node-1
ping node-2
ping node-3

  5. Instale o Microsoft SQL Server Management Studio (SSMS) com as seguintes etapas:

    1. Conecte-se à VM do Windows no node-4 usando a Área de Trabalho Remota.

    2. Na sua sessão RDP, minimize todas as janelas e inicie o aplicativo Windows PowerShell ISE.

    3. No prompt do PowerShell, baixe e execute o instalador do SSMS. 

      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 o prompt para permitir que alterações sejam feitas.

    6. Quando a instalação for concluída, clique em Reiniciar para reiniciar a máquina remota. Isso fecha a sessão RDP.

  6. Conecte-se à instância do SQL Server no nó-1:

    1. Retorne à VM node-4 usando RDP.

    2. Abra o SSMS e conecte-se ao node-1 usando os parâmetros a seguir. 

      Server name: node-1
Authentication: SQL Server Authentication
Login: sa

      Para obter mais informações, consulte conectar-se a uma instância do SQL Server usando a documentação do SQL Server Management Studio .

    3. Digite a senha da conta SA criada durante a instalação.

    4. Selecione Certificado de servidor confiável .

    5. Clique em Conectar .

Habilitar grupo de disponibilidade Always On

No Linux, você deve primeiro criar um grupo de disponibilidade antes de poder adicioná-lo como um recurso a ser gerenciado pelo Pacemaker:

  1. Habilite o recurso de grupo de disponibilidade Always On para cada instância do SQL Server participante do grupo de disponibilidade. Execute os seguintes comandos em node-1 , node-2 e node-3 :

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

  2. Conecte-se à instância que é o host principal no grupo de disponibilidade usando SSMS:

    1. Abra uma nova janela de consulta.

    2. Execute o trecho de código a seguir para criar uma chave de criptografia, um certificado e uma chave privada.

      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 o certificado e os arquivos de chave

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

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

Transfira o certificado e os arquivos de chave usando o Cloud Storage

Crie um Cloud Storage para transferir arquivos dos nós do cluster primário para o secundário.

  1. Crie um intervalo do Cloud Storage:

    1. Retorne 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 Google Cloud projeto e substitua REGION pelo ID da região onde você deseja que o bucket seja implantado.

    Para obter mais informações, consulte Criar buckets .

  2. Retorne ao SSh em node-1 , node-2 e node-3 para inicializar o Google Cloud CLI:

    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. Digite o nome do seu projeto.

    4. Insira n na pergunta para configurar a região e zona padrão.

  3. Retorne ao node-1 para copiar os arquivos para o Cloud Storage:

    1. Faça upload dos dois arquivos recém-criados para seu 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.

  4. Volte para node-2 e node-3 para copiar os arquivos do Cloud Storage:

    1. Baixe os 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. Altere a propriedade dos arquivos no node-2 e 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.*

Configurar ponto de extremidade de espelhamento de banco de dados

Nesta seção, você 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 dos dados.

  1. Retorne à VM do Windows no node-4 para criar os pontos de extremidade 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 SSMS. Siga as etapas de Conectar-se ao SQL Server usando node-1 , node-2 e node-3 como o nome do servidor e as respectivas senhas definidas para a conta SA.

    2. Crie o certificado nas VMs secundárias node-2 e node-3 a partir dos arquivos copiados. Use as senhas fornecidas ao criar o certificado e a chave no nó primário. 

      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. Retorne ao SSMS para criar pontos de extremidade de espelhamento de banco de dados executando o comando T-SQL para node-1 , node-2 e node-3 .

      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 Always On

Em seguida, crie o grupo de disponibilidade Always On do SQL Server usando o SQL Server Management Studio e use os pontos de extremidade criados anteriormente para replicação.

  1. Retorne à VM do Windows e abra o SSMS:

    1. Conecte-se ao mecanismo de banco de dados SQL Server no node-1 e abra uma nova janela de consulta.

  2. Crie um banco de dados e faça backup dele em preparação para 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';

  3. Crie o grupo de disponibilidade Always On:

    1. Execute o seguinte comando T-SQL no SSMS em node-1 , node-2 e node-3 . Isso garantirá que os pontos de extremidade estejam habilitados e que o SQL Server em cada nó esteja pronto para 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

    2. Execute o seguinte comando T-SQL no 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

    3. Execute o comando T-SQL a seguir node-2 e node-3 para cada instância do SQL Server para ingressar no 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 novo banco de dados denominado bookshelf e adicionou o novo banco de dados a um novo grupo de disponibilidade denominado aoag1 na instância do SQL Server em execução no 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 forma síncrona nas instâncias do SQL Server em todos os três nós.

Instalar e configurar o Pacemaker

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

Crie um logon do SQL Server para o gerenciador de cluster do pacemaker

Nesta seção, você criará uma nova conta do SQL Server para o Pacemaker usar para fazer login em cada instância do SQL Server e gerenciar o grupo de disponibilidade.

  1. Execute o seguinte comando T-SQL 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 marcapasso.

  2. Execute o comando T-SQL para conceder permissões de login do marcapasso ao grupo de disponibilidade: 

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

  3. Retorne ao SSH em node-1 , node-2 e node-3 para executar os comandos para salvar o login e a senha do Pacemaker na pasta de segredos 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 marcapasso.

Instale o marcapasso

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

  1. Abra portas de firewall para marcapasso:

    1. Verifique se Uncomplicated Firewall está instalado e habilitado executando o seguinte comando em node-1 , node-2 e node-3 . 

      sudo ufw status

    2. Se o ufw estiver habilitado, abra as portas do 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

  2. 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

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

    sudo passwd hacluster

Configurar o Corosync

Agora você configurará o Corosync para gerenciar a associação do cluster e as mensagens em todo o cluster.

  1. Crie uma chave de autenticação para Corosync no node-1 : 

    sudo corosync-keygen

  2. Modifique o arquivo de configuração do Corosync:

    1. Retorne ao node-1 e modifique o arquivo corosync.conf . 

      sudo vi /etc/corosync/corosync.conf

    2. Atualize as seções destacadas. Após a edição, o arquivo deverá 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ó.

Transfira os arquivos de configuração usando o Cloud Storage

  1. Faça upload da chave de autenticação gerada e dos arquivos de configuração do corosync do node-1 para seu 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.

  2. Baixe os arquivos Authkey 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.

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

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

Reinicie e verifique a comunicação do cluster

  1. Reinicie os serviços Pacemaker e Corosync em node-1 , node-2 e node-3 : 

    sudo systemctl restart pacemaker corosync

  2. Confirme o status do cluster executando o comando no node-1 : 

    sudo crm status

    Você deverá ver todos os três nós online.

Configure o cluster

Em seguida, você configurará o cluster Pacemaker criando um novo recurso para o grupo de disponibilidade Always On do SQL Server.

  1. Execute o seguinte comando no 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 obter mais informações, consulte Opções de cluster .

  2. Autorize os nós no cluster executando o comando em node-1 . Use a senha definida anteriormente para a conta hacluster : 

    sudo pcs cluster auth -u hacluster

    Você deverá ver que todos os três nós estão autorizados.

  3. Instale o agente de recursos do SQL Server para integração com o Pacemaker em node-1 , node-2 e node-3 : 

    sudo apt-get install mssql-server-ha

  4. Retorne ao node-1 e crie um recurso de grupo de disponibilidade no cluster:

    1. Execute o Gerenciador de Recursos de Cluster. 

      sudo crm

    2. Digite configure para entrar no menu de configuração.

    3. Insira a seguinte configuração. 

      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 alterações.

    5. Digite exit para sair do gerenciador de recursos de cluster.

    6. Verifique a configuração. 

      sudo crm status

      Você deverá ver que node-1 foi promovido para o nó primário. Node-2 e node-3 devem ser definidos como nós secundários.

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

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

  1. Retorne ao Cloud Shell e reserve um endereço IP estático que você usará como 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 onde as VMs do Linux estão implantadas.

  2. Crie grupos de instâncias não gerenciadas 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 onde as VMs do Linux estão implantadas.

  3. Crie uma verificação de integridade do TCP. Os balanceadores de carga usam verificações de integridade para determinar quais instâncias de back-end respondem adequadamente 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 e substitua HEALTH_CHECK_PORT pelo valor de uma porta livre e no intervalo privado de 49152-65535 . Por exemplo, 60.000.

    Para obter mais informações, leia a visão geral das verificações de integridade .

  4. 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.

  5. Crie uma regra de firewall para permitir que as verificações de integridade cheguem aos 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 obter mais informações, consulte Regras de firewall para verificações de integridade .

  6. 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

  7. Adicione os três grupos de instâncias não gerenciadas 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

  8. Defina uma regra de encaminhamento para seu balanceador de carga. Uma regra de encaminhamento especifica o protocolo e as portas nas quais 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.

    Para obter mais informações, consulte Regras de encaminhamento

  9. Para concluir a configuração e testar se o balanceador de carga de rede está configurado corretamente, instale e configure o 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 do haproxy.cfg file , altere o modo para tcp .

    5. Anexe a seguinte seção no 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, 6.000.

    6. Inicie o serviço para confirmar se está configurado corretamente: 

      sudo systemctl start haproxy.service
sudo systemctl enable haproxy.service
sudo systemctl restart haproxy.service

    7. Vá para a página Balanceamento de carga e clique no seu balanceador de carga. Observe seus três grupos de instâncias não gerenciadas, eles agora devem ser relatados como íntegros.

      Vá para Balanceamento de carga

      • Como alternativa, você pode executar o comando a seguir no Cloud Shell para ver o status do serviço de back-end. 

        gcloud compute backend-services get-health aoag1-backend \
--region REGION

        Substitua REGION pela região onde as VMs do Linux estão implantadas.

    8. Depois que todos os três grupos de instâncias não gerenciadas apresentarem relatórios íntegros, passe para a próxima etapa.

      sudo systemctl restart haproxy.service

  10. Crie o recurso de verificação de integridade no Pacemaker:

    1. SSH para node-1 e crie um recurso de verificação de integridade para o serviço HAProxy em seu cluster de marcapasso: 

      sudo pcs resource create aoag1-healthcheck \
service:haproxy \
op monitor interval=10s timeout=20s

    2. Verifique se o recurso de funcionamento foi iniciado no nó primário node-1 : 

      sudo crm status

    3. Se o recurso de verificação de funcionamento não for iniciado no nó primário, mova-o com os seguintes comandos: 

      sudo pcs resource move aoag1-healthcheck node-1
sudo pcs resource clear aoag1-healthcheck

      Você verá que a verificação de integridade do balanceador de carga estará íntegra apenas para node-1 .

      Vá para Balanceamento de carga

  11. Crie um recurso de endereço IP virtual em seu cluster Pacemaker:

    1. Retorne ao SSH no node-1 e encontre o nome da interface de rede do seu 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 primário. 

      sudo crm status

    4. Se o recurso de endereço IP virtual não for iniciado no nó primário, 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 primário. 

      sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY

Crie um ouvinte para seu grupo de disponibilidade do SQL Server

As conexões com o SQL Server com grupos de disponibilidade devem usar um nome de ouvinte de grupo de disponibilidade em vez do nome do servidor. Se houver um failover, o ouvinte redirecionará automaticamente as conexões para o novo nó primário no cluster.

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

  2. 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.

Configure uma cerca STONITH

STONITH é uma estratégia de isolamento para manter a integridade dos nós em um cluster 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 estado desconhecido. Recomendamos o dispositivo de isolamento fence_gce especializado para Compute Engine em Google Cloud.

Configurar dispositivos de cerca

  1. Verifique se o agente fence_gce - Fence para Compute Engine está instalado em node1 : 

    sudo pcs stonith list | grep fence_gce

    Para obter mais informações, consulte:

  2. Em node-1 , crie os recursos do tipo fence 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 onde as VMs do Linux estão implantadas e substitua PROJECT_ID pelo ID do seu projeto.

  3. Você pode testar o status dos agentes de fence 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

  4. Crie restrições de localização para seus dispositivos de fence para garantir que eles estejam sendo executados somente 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

  5. Habilite o isolamento em seu cluster de marcapasso e defina o tempo limite do isolamento do cluster: 

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

  6. Verifique o status do cluster: 

    sudo crm status

Teste os dispositivos de cerca

Após a configuração dos dispositivos de cerca, recomendamos testá-los seguindo as etapas a seguir.

  1. Pare a cerca no node-2 :

    1. Conecte-se ao node-1 e execute o seguinte comando para testar o dispositivo fence associado ao node-2 do seu cluster. 

      fence_gce -o off -n node-2 --zone=REGION-b

    2. Verifique o status do cluster. 

      sudo crm status

    3. Você também verá que node-2 está desativado no Compute Engine.

      Acesse o Compute Engine

  2. Reinicie a cerca no node-2 :

    1. Retorne ao 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. Após um curto período de tempo, você verá que node-2 está online novamente. 

      sudo crm status

Configure o Corosync para reinicialização atrasada

Para evitar problemas de tempo e garantir uma ordem adequada de operações executadas no caso de uma ação de esgrima, recomendamos atrasar a reinicialização do serviço Corosync por 60 segundos.

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

  1. Crie um arquivo drop-in do systemd que defina um atraso no início do serviço 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 seguintes linhas, salve o arquivo e saia do editor. 

      [Service]
ExecStartPre=/bin/sleep 60

    3. Recarregue o gerenciador de serviços e verifique se a configuração foi levada em consideração. 

      sudo systemctl daemon-reload
systemctl status corosync.service --no-pager

      Se você vir a seção Drop-In, então as configurações em seu arquivo drop-in foram levadas em consideração com sucesso

Failover de teste

Agora você está pronto para testar se o failover funciona conforme esperado.

  1. Conecte-se à VM do Windows no node-4 por meio da Área de Trabalho Remota:
  2. Abra uma sessão do PowerShell:

  3. Execute o seguinte script: 

    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 ouvinte e SA_PASSWORD pela senha da conta SA no SQL Server.

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

    Deixe o script em execução.

  4. Retorne ao SSH no node-1 e execute os comandos para acionar um failover no 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

  5. Retorne à sessão do PowerShell no node-4 :

    1. Observe a saída do script em execução e observe que o nome do servidor muda de node-1 para node-2 como resultado do failover.

  6. Retorne ao 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

  7. Retorne ao Powershell no node-4 e interrompa o script pressionando Ctrl+C .

Limpar

Depois de concluir o tutorial, você poderá limpar os recursos criados para que eles parem de usar a cota e de incorrer em cobranças. As seções a seguir descrevem como excluir ou desativar esses recursos.

Excluindo o projeto

A maneira mais fácil de eliminar o faturamento é excluir o projeto que você criou para o tutorial.

Para excluir o projeto:

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.