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
- Implantar o SQL Server no Linux
- Criar um grupo de disponibilidade sempre ativado para alta disponibilidade e recuperação de desastres
- Instalar e configurar o Pacemaker para gerenciar o failover do cluster do SQL Server
- Configurar um balanceador de carga para rotear o tráfego para um grupo de disponibilidade com o SQL Server
- Configurar um isolamento STONITH (Shoot The Other Node In The Head) para garantir a integridade da HA
- Realizar um teste de failover para confirmar se o cluster do SQL Server está funcionando conforme o esperado
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:
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Verifique se a API NetApp Cloud Volumes está ativada para o projeto do Google Cloud.
-
In the Google Cloud console, 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:
No Console do Google Cloud, abra o Cloud Shell clicando no botão Ativar o Cloud Shell
.
Defina o ID do projeto padrão:
gcloud config set project
PROJECT_ID Substitua
PROJECT_ID
pelo ID do 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=
\ --zonePROJECT_ID
-a \ --machine-type $MACHINE_TYPE \ --subnetREGION
\ --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/SUBNET_NAME
/zones/PROJECT_ID
/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=ZONE
\ --zonePROJECT_ID
-b \ --machine-type $MACHINE_TYPE \ --subnetREGION
\ --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/SUBNET_NAME
/zones/PROJECT_ID
/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=ZONE
\ --zonePROJECT_ID
-c \ --machine-type $MACHINE_TYPE \ --subnetREGION
\ --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/SUBNET_NAME
/zones/PROJECT_ID
/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_writeZONE Substitua a sub-rede
SUBNET_NAME
pelo nome da sub-rede VPC.Atualize o arquivo hosts em
node-1
,node-2
enode-3
:- Conecte-se a cada uma das VMs usando SSH. Consulte a documentação para saber como se conectar a VMs do Linux.
Abra o arquivo hosts para edição.
sudo vi /etc/hosts
Encontre o endereço IP interno de cada VM do Linux e anexe as entradas de host à parte inferior do arquivo.
node-1NODE1_INTERNAL_IP
node-2NODE2_INTERNAL_IP
node-3NODE3_INTERNAL_IP Substitua
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_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:
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
enode-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:
Execute a ferramenta mssql-conf.
sudo /opt/mssql/bin/mssql-conf setup
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.
Especifique uma senha para a conta da SA.
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:
Para verificar se
Uncomplicated Firewall
está instalado e ativado, execute o comando a seguir.sudo ufw status
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:
Crie uma VM do Windows:
Volte ao Cloud Shell e execute o comando a seguir.
gcloud compute instances create node4 \ --project=
\ --zonePROJECT_ID
\ --subnetZONE
\ --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/SUBNET_NAME
/diskTypes/pd-balancedZONE
Conecte-se à VM do Windows em
node-4
usando a Área de trabalho remota:Atualize o arquivo hosts em
node-4
:- Abra o Bloco de Notas no modo de administrador.
Clique em Arquivo > Abrir e abra o arquivo hosts.
c:\Windows\System32\drivers\etc\hosts
Anexe as entradas de host à parte inferior do arquivo.
node-1NODE1_INTERNAL_IP
node-2NODE2_INTERNAL_IP
node-3NODE3_INTERNAL_IP Substitua
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_INTERNAL_IP
pelo respectivo endereço IP interno de cada VM.Salve e saia.
Verifique a conectividade com as VMs do Linux:
- Conectar-se à VM do Windows em
node-4
- Pressione o botão Iniciar e digite "powershell" na barra de pesquisa.
- Clique para abrir o app do Windows PowerShell ISE.
Testa a conectividade executando os comandos abaixo.
ping node-1 ping node-2 ping node-3
- Conectar-se à VM do Windows em
Instale o Microsoft SQL Server Management Studio (SSMS) seguindo estas etapas:
Conecte-se à VM do Windows em
node-4
usando a Área de trabalho remota.Na sessão RDP, minimize todas as janelas e inicie o app Windows PowerShell ISE.
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
No instalador do SSMS, clique em Instalar.
Aceite a solicitação para permitir alterações.
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:
Volte à VM
node-4
usando o RDP.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.
Digite a senha da conta da SA criada durante a instalação.
Selecione Confiar no certificado do servidor.
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
enode-3
: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:
Abra uma nova janela de consulta.
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 = '
'; 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 = 'ENCRYPTION_KEY_PASSWORD
' );PRIVATE_KEY_PASSWORD Substitua
ENCRYPTION_KEY_PASSWORD
ePRIVATE_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:
Volte ao Cloud Shell e execute o seguinte comando:
gcloud storage buckets create gs://
\ --project=BUCKET_NAME
\ --location=PROJECT_ID
\ --public-access-preventionREGION Substitua
BUCKET_NAME
pelo nome do bucket a ser criado. SubstituaPROJECT_ID
pelo ID do projeto Google Cloud eREGION
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
enode-3
e inicialize a CLI do Google Cloud:Execute o comando a seguir para inicializar a CLI do Google Cloud.
gcloud init
Escolha
option [1]
para usar a conta de serviço pré-instalada.Insira o nome do projeto.
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: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://
/ sudo gcloud storage cp /var/opt/mssql/data/my_ag_certificate.pvk gs://BUCKET_NAME
/BUCKET_NAME Substitua
BUCKET_NAME
pelo nome do bucket criado.
Volte para
node-2
enode-3
e copie os arquivos do Cloud Storage:Faça o download dos dois arquivos do Cloud Storage para
node-2
.sudo gcloud storage cp gs://
/my_ag_certificate.cer /var/opt/mssql/data/ sudo gcloud storage cp gs://BUCKET_NAME
/my_ag_certificate.pvk /var/opt/mssql/data/BUCKET_NAME Substitua
BUCKET_NAME
pelo nome do bucket criado.Mude a propriedade dos arquivos em
node-2
e emnode-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.
Volte à VM do Windows em
node-4
para criar os endpoints de espelhamento de banco de dados:Conecte-se aos bancos de dados do SQL Server em
node-1
,node-2
enode-3
usando o SSMS. Siga as etapas em Conectar-se ao SQL Server usandonode-1
,node-2
enode-3
como nome do servidor e as respectivas senhas definidas para a conta de SA.Crie o certificado nas VMs secundárias
node-2
enode-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 = '
'; 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 = 'ENCRYPTION_KEY_PASSWORD
' );PRIVATE_KEY_PASSWORD Substitua
ENCRYPTION_KEY_PASSWORD
ePRIVATE_KEY_PASSWORD
pelas senhas da chave de criptografia e da chave privada.Volte ao SSMS para criar endpoints de espelhamento de banco de dados executando o comando T-SQL para
node-1
,node-2
enode-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.
Volte à VM do Windows e abra o SSMS:
- Conecte-se ao mecanismo de banco de dados do SQL Server em
node-1
e abra uma nova janela de consulta.
- Conecte-se ao mecanismo de banco de dados do SQL Server em
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
enode-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 emnode-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
enode-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
enode-3
:USE [master]; CREATE LOGIN [pacemaker] with PASSWORD= N'
'; GOPACEMAKER_LOGIN_PASSWORD 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
enode-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-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/passwdPACEMAKER_LOGIN_PASSWORD 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:
Para verificar se
Uncomplicated Firewall
está instalado e ativado, execute o comando a seguir emnode-1
,node-2
enode-3
.sudo ufw status
Se o ufw estiver ativado, abra portas de firewall em
node-1
,node-2
enode-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
Instale o Pacemaker em
node-1
,node-2
enode-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
emnode-1
,node-2
enode-3
: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 arquivocorosync.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:
# 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:NODE1_INTERNAL_IP
} node { name: node-3 nodeid: 3 ring0_addr:NODE2_INTERNAL_IP
} # ... }NODE3_INTERNAL_IP Substitua
NODE1_INTERNAL_IP
,NODE2_INTERNAL_IP
eNODE3_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://
/ sudo gcloud storage cp /etc/corosync/corosync.conf gs://BUCKET_NAME
/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
enode-3
:sudo gcloud storage cp gs://
/authkey /etc/corosync/ sudo gcloud storage cp gs://BUCKET_NAME
/corosync.conf /etc/corosync/BUCKET_NAME 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 emnode-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
enode-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 contahacluster
: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
enode-3
:sudo apt-get install mssql-server-ha
Volte a
node-1
e crie um recurso de grupo de disponibilidade no cluster:Execute o Resource Manager do cluster.
sudo crm
Digite
configure
para acessar o menu de configuração.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"
Digite
commit
para confirmar as mudanças.Digite
exit
para sair do Resource Manager do cluster.Verifique a configuração.
sudo crm status
Observe que
node-1
foi promovido a nó principal.Node-2
enode-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
\ --subnetREGION
CLUSTER_ADDRESS=$(gcloud compute addresses describe aoag1-cluster \ --region $(gcloud config get-value compute/region) \ --format=value\(address\)) && \ echo "Cluster IP address: $CLUSTER_ADDRESS"SUBNET_NAME Substitua
REGION
eSUBNET_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=
-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-3REGION 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=
--proxy-header=NONE \ --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2HEALTH_CHECK_PORT 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
\ --zoneNETWORK_TAG_NAME
-a gcloud compute instances add-tags node-2 \ --tagsREGION
\ --zoneNETWORK_TAG_NAME
-b gcloud compute instances add-tags node-3 \ --tagsREGION
\ --zoneNETWORK_TAG_NAME
-cREGION 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
\ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tagsVPC_NAME
\ --rules tcp:NETWORK_TAG_NAME 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
\ --global-health-checksREGION 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
-a \ --regionREGION
gcloud compute backend-services add-backend aoag1-backend \ --instance-group node-2-uig \ --instance-group-zoneREGION
-b \ --failover \ --regionREGION
gcloud compute backend-services add-backend aoag1-backend \ --instance-group node-3-uig \ --instance-group-zoneREGION
-c \ --failover \ --regionREGION 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
\ --subnetCLUSTER_ADDRESS
\ --regionSUBNET_NAME
\ --backend-service aoag1-backend \ --ports ALLREGION Substitua
CLUSTER_ADDRESS
pelo endereço IP reservado anteriormente.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
emnode-1
,node-2
enode-3
:Instale o HAProxy.
sudo apt-get install haproxy
Escolha
Y
para concluir a instalação.Edite o arquivo
haproxy.cfg
.sudo vi /etc/haproxy/haproxy.cfg
Na seção de padrões de
haproxy.cfg file
, mude o modo paratcp
.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.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
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.
Quando os três grupos não gerenciados de instâncias estiverem íntegros, prossiga para a próxima etapa.
sudo systemctl restart haproxy.service
Crie o recurso de verificação de integridade no Pacemaker:
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
Verifique se o recurso de integridade foi iniciado no nó principal
node-1
:sudo crm status
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
.
Crie um recurso de endereço IP virtual no cluster do Pacemaker:
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
Crie o recurso de endereço IP virtual.
sudo pcs resource create aoag1-vip ocf:heartbeat:IPaddr2 \ ip="
" nic=CLUSTER_ADDRESS
cidr_netmask=32 \ op monitor interval=3600s timeout=60sNIC_NAME Substitua
NIC_NAME
pelo nome da interface de rede da etapa anterior eCLUSTER_ADDRESS
pelo endereço IP reservado.Verifique se o recurso de endereço IP virtual foi iniciado no host principal.
sudo crm status
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
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
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 (('
','255.255.255.0')), PORT=1433 ); GOCLUSTER_ADDRESS 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
Verifique se o agente de isolamento
fence_gce
do Compute Engine está instalado emnode1
: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 isolamentofence_gce
para cada um dos nós participantes:sudo pcs stonith create node-1-fence fence_gce \ plug=node-1 \ zone=
-a \ project=REGION
\ 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=PROJECT_ID
-b \ project=REGION
\ 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=PROJECT_ID
-c \ project=REGION
\ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30 \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s"PROJECT_ID Substitua
REGION
pela região em que as VMs do Linux foram implantadas ePROJECT_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=
-a sudo fence_gce -o status -n node-2 --zone=REGION
-b sudo fence_gce -o status -n node-3 --zone=REGION
-cREGION 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
:Conecte-se a
node-1
e execute o comando a seguir para testar o dispositivo de isolamento associado anode-2
no cluster.fence_gce -o off -n node-2 --zone=
-bREGION Verifique o status do cluster.
sudo crm status
Observe também que
node-2
está desativado no Compute Engine.
Reinicie o isolamento em
node-2
:Retorne a
node-1
e reinicie a instância novamente executando o comando a seguir.fence_gce -o on -n node-2 --zone=
-bREGION 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
enode-3
:Abra o corosync.service para edição.
sudo systemctl edit corosync.service
Anexe as linhas a seguir, salve o arquivo e saia do editor.
[Service] ExecStartPre=/bin/sleep 60
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=
;User ID=sa;Password=CLUSTER_ADDRESS
;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 }SA_PASSWORD Substitua
CLUSTER_ADDRESS
pelo endereço IP do listener eSA_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 paranode-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
:- Observe a saída do script em execução e veja que o nome do servidor
mudou de
node-1
paranode-2
como resultado do failover.
- Observe a saída do script em execução e veja que o nome do servidor
mudou de
Volte a
node-1
e inicie um failback paranode-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 pressionandoCtrl+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:
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.