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.

Objetivos

Custos

Neste tutorial, usamos componentes faturáveis do Google Cloud, incluindo:

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

Antes de começar

Para este tutorial, você precisa de um projeto do Google Cloud. É possível criar um novo projeto ou selecionar um que já foi 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. Verifique se a API NetApp Cloud Volumes está ativada para o projeto do Google Cloud.
  4. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

Preparar o projeto e a rede

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

  1. No Console do Google Cloud, abra o Cloud Shell clicando no botão Ativar o Cloud Shell Ative o Cloud Shell..

    Acesse o console do Google Cloud

  2. Defina o ID do projeto padrão:

    gcloud config set project PROJECT_ID
    

    Substitua PROJECT_ID pelo ID do projeto do Google Cloud.

  3. Defina sua região padrão:

    gcloud config set compute/region REGION
    

    Substitua REGION pelo ID da região em que você quer implantar.

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

  1. Inicialize as seguintes variáveis:

    PD_SIZE=30
    MACHINE_TYPE=n2-standard-8
    
  2. 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/ZONE/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/ZONE/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/ZONE/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 a sub-rede SUBNET_NAME pelo nome da sub-rede VPC.

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

    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.

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

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

    1. 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
      
    2. 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)"
      
    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. 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.

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

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:

  1. Crie uma VM do Windows:

    1. 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
      
  2. Conecte-se à VM do Windows em node-4 usando a Área de trabalho remota:

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

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

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

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

    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 o SSMS:

    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.

      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.

  1. 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 projeto Google Cloud e REGION pelo ID da região em que o bucket será implantado.

    Para mais informações, consulte Criar buckets.

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

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

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

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.

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

      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.

  1. 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.
  2. 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';
    
  3. Crie o grupo de disponibilidade sempre ativado:

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

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

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

  1. 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
      
  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, configure o Corosync para gerenciar a associação e as mensagens no cluster.

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

    sudo corosync-keygen
    
  2. Modifique o arquivo de configuração do Corosync:

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

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

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

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

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

    sudo systemctl restart pacemaker corosync
    
  2. 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.

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

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

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

    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.

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

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

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

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

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

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

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

      sudo systemctl restart haproxy.service
      
  10. 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

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

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

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 no Google Cloud.

Configurar dispositivos de isolamento

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

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

  3. É 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
    
  4. 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
    
  5. 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"
    
  6. 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.

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

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

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

  1. Conecte-se à VM do Windows em node-4 pela Área de trabalho remota:
  2. Abra uma sessão do PowerShell:
  3. 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.

  4. 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
    
  5. 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.
  6. 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
    
  7. Volte ao PowerShell em node-4 e interrompa o script pressionando Ctrl+C.

Limpar

Depois de concluir o tutorial, você pode limpar os recursos que criou para que eles parem de usar a cota e gerar cobranças. Nas seções a seguir, você aprenderá a excluir e desativar esses recursos.

Excluir o projeto

O jeito mais fácil de evitar cobranças é excluindo 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.