Esta página foi traduzida pela API Cloud Translation.

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

Este tutorial descreve como implementar um sistema de base de dados do Microsoft SQL Server no Linux através de um grupo de disponibilidade Always On (AOAG) e do Pacemaker como solução de alta disponibilidade (HA) e recuperação de desastres (DR). Para efeitos deste documento, um desastre é um evento em que uma base de dados principal falha ou fica indisponível.

Uma base de dados principal pode falhar quando a região em que se encontra falha ou se torna inacessível. Mesmo que uma região esteja disponível e a funcionar normalmente, uma base de dados principal pode falhar devido a um erro do sistema. Nestes casos, a recuperação de desastres é o processo de disponibilização de uma base de dados secundária aos clientes para processamento contínuo.

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

Objetivos

Implemente o SQL Server no Linux
Crie um grupo de disponibilidade Always On para alta disponibilidade e recuperação de desastres
Instale e configure o Pacemaker para gerir a comutação por falha do cluster do SQL Server
Configure um equilibrador de carga para encaminhar o tráfego para o seu grupo de disponibilidade com o SQL Server
Configure uma vedação STONITH (Shoot The Other Node In The Head) para garantir a integridade da HA
Faça um teste de comutação por falha para garantir que o cluster do SQL Server está a funcionar como esperado

Custos

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

Use a calculadora de preços para gerar uma estimativa de custos com base na sua utilização prevista.

Antes de começar

Para este tutorial, precisa de um Google Cloud projeto. Pode criar um novo ou selecionar um projeto que já criou:

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Prepare o projeto e a rede

Para preparar o Google Cloud projeto e a VPC para a implementação de grupos de disponibilidade Always On do SQL Server, faça o seguinte:
1. Na Google Cloud consola, abra o Cloud Shell clicando no botão Ativar Cloud Shell .
  
  Aceda à Google Cloud consola
2. Defina o seu ID do projeto predefinido:
  gcloud config set project PROJECT_ID
  Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.
3. Predefina a sua região:
  gcloud config set compute/region REGION
  Substitua REGION pelo ID da região na qual quer fazer a implementação.
4. Predefina a sua zona:
  gcloud config set compute/zone ZONE
  Substitua ZONE pelo ID da zona na qual quer fazer a implementação. Deve ser uma zona válida na região especificada no passo anterior.
Crie VMs do Linux

Para alcançar a HA e o quórum para o cluster do SQL Server, implemente três máquinas virtuais (VMs) Linux para alojar 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/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 de VPC.
3. Atualize o ficheiro hosts em node-1, node-2 e node-3:
  
  Nota: para utilização em produção, a resolução de domínio deve ser gerida por um servidor de Sistema de Nomes de Domínio (DNS) dedicado.
  1. Estabeleça ligação a cada uma das suas VMs através do SSH. Consulte a documentação sobre como estabelecer ligação a VMs do Linux para mais informações.
  2. Abra o ficheiro hosts para edição.
    
    sudo vi /etc/hosts
  3. Encontre o endereço IP interno de cada VM do Linux e anexe as entradas do anfitrião à parte inferior do ficheiro.
    
    Aceder ao 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 as VMs. Todas as MV que participam no grupo de disponibilidade Always On têm de conseguir comunicar com outras MV:
  1. Regresse a cada VM do Linux, execute os comandos de cada VM e verifique se todas as VMs conseguem comunicar entre si.
    
    ping -c 4 node-1 ping -c 4 node-2 ping -c 4 node-3
Instale e configure o SQL Server

Transfira, instale e configure o motor do SQL Server nas três VMs Linux que vão participar no grupo de disponibilidade Always On.
1. SSH para node-1, node-2 e node-3 e execute os seguintes passos:
  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. Registe o repositório do SQL Server Ubuntu.
    
    sudo add-apt-repository \ "$(wget -qO- https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2019.list)"
  3. Atualize os ficheiros de índice de pacotes 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 a edição do SQL Server e aceite o contrato de licença.
    
    A edição para programadores tem todas as funcionalidades empresariais incluídas, mas só a pode usar para ambientes de não produção. Estão disponíveis mais informações sobre as edições do SQL Server e as licenças da Microsoft.
    
    Nota: é necessária uma licença do SQL Server para cada instância de VM. Se estiver a executar servidores de aplicações Microsoft, a mobilidade de licenças através da Software Assurance ajuda a fazer a transição para Google Cloud. Para mais informações, consulte o artigo Usar a mobilidade de licenças com aplicações de servidor da Microsoft. Se não estiver a trazer a sua própria licença e precisar de comprar uma licença através da Google (pagamento conforme a utilização), siga os passos em Adicione uma licença do SQL Server a um disco de arranque para garantir que compra uma licença para cada instância de VM.
  3. Especifique uma palavra-passe para a conta do SA.
  4. Verifique se o serviço mssql-server está em execução.
    
    systemctl status mssql-server --no-pager
3. Se tiver uma firewall ativada nas suas VMs, abra a firewall para o SQL Server:
  1. Verifique se o Uncomplicated Firewall está instalado e ativado executando o seguinte comando.
    
    sudo ufw status
  2. Se o estado estiver ativo, execute os seguintes comandos para abrir as portas.
    
    sudo ufw allow 1433 sudo ufw allow 5022 sudo ufw reload
    
    Nota: se estiver a usar outras portas para o SQL Server ou para o ponto final do grupo de disponibilidade, altere as regras das firewalls em conformidade.
Estabeleça ligação ao SQL Server

Neste momento, o SQL Server está instalado. Para estabelecer ligação, crie uma máquina Windows na mesma VPC, instale o SQL Server Management Studio (SSMS) para estabelecer ligação à instância do SQL Server recém-criada nas suas VMs:
1. Crie uma VM do Windows:
  1. Regresse ao Cloud Shell e execute o seguinte comando.
    
    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. Estabeleça ligação à VM do Windows em node-4 através do Ambiente de Trabalho Remoto:
3. Atualize o ficheiro hosts em node-4:
  1. Abra o bloco de notas no modo de administrador.
  2. Clique em Ficheiro > Abrir e abra o ficheiro hosts.
    
    c:\Windows\System32\drivers\etc\hosts
  3. Anexe as entradas de anfitrião à parte inferior do ficheiro.
    
    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 respetivo de cada VM.
  4. Guardar e sair.
4. Verifique a conetividade às VMs do Linux:
  1. Estabeleça ligação à VM do Windows em node-4
  2. Clique no botão Iniciar e introduza powershell na barra de pesquisa.
  3. Clique para abrir a app Windows PowerShell ISE.
  4. Testa a conetividade executando os seguintes comandos.
    
    ping node-1 ping node-2 ping node-3
5. Instale o Microsoft SQL Server Management Studio (SSMS) através dos seguintes passos:
  1. Estabeleça ligação à VM do Windows em node-4 através do Ambiente de Trabalho Remoto.
  2. Na sessão RDP, minimize todas as janelas e inicie a app Windows PowerShell ISE.
  3. Na linha de comandos do PowerShell, transfira 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 comando para permitir que sejam feitas alterações.
  6. Quando a instalação estiver concluída, clique em Reiniciar para reiniciar o computador remoto. Esta ação fecha a sessão RDP.
6. Estabeleça ligação à instância do SQL Server no nó 1:
  1. Regresse à node-4 VM através do RDP.
  2. Abra o SSMS e ligue-se ao node-1 através dos seguintes parâmetros.
    
    Server name: node-1 Authentication: SQL Server Authentication Login: sa
    
    Para mais informações, consulte o artigo sobre como estabelecer ligação a uma instância do SQL Server através da documentação do SQL Server Management Studio.
  3. Introduza a palavra-passe da conta de SA criada durante a instalação.
  4. Selecione Confiar no certificado do servidor.
  5. Clique em Ligar.
Ative o grupo de disponibilidade Always On

No Linux, tem de criar primeiro um grupo de disponibilidade antes de o poder adicionar como um recurso a ser gerido pelo Pacemaker:
1. Ative a funcionalidade de grupo de disponibilidade Always On para cada instância do SQL Server que participe no grupo de disponibilidade. Execute os seguintes comandos em node-1, node-2 e node-3:
  
  Nota: reinicie o serviço mssql-server para que as alterações entrem em vigor.
  sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1 sudo systemctl restart mssql-server
2. Efetue a ligação à instância que é o anfitrião principal no grupo de disponibilidade através do SSMS:
  
  Dica: recomendamos que escolha node-1 como anfitrião principal.
  1. Abra uma nova janela de consulta.
  2. Execute o seguinte fragmento do código para criar uma chave de encriptação, um certificado e uma chave privada.
    
    Sugestão: escolha palavras-passe fortes para a chave de encriptação e a chave privada. Memorize estas palavras-passe, uma vez que as vai usar mais tarde.
    Nota: a palavra-passe tem de ter, pelo menos, 8 carateres e conter carateres de três dos seguintes quatro conjuntos: letras maiúsculas, letras minúsculas, dígitos de base 10 e símbolos.
    
    USE MASTER; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'ENCRYPTION_KEY_PASSWORD'; CREATE CERTIFICATE my_ag_certificate WITH SUBJECT = 'my_ag_cert'; BACKUP CERTIFICATE my_ag_certificate TO FILE = '/var/opt/mssql/data/my_ag_certificate.cer' WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/my_ag_certificate.pvk', ENCRYPTION BY PASSWORD = 'PRIVATE_KEY_PASSWORD' );
    
    Substitua ENCRYPTION_KEY_PASSWORD e PRIVATE_KEY_PASSWORD pelas palavras-passe da chave de encriptação e da chave privada.
Transfira os ficheiros de certificado e chave

Os ficheiros de certificado e chave criados nos passos anteriores têm de ser movidos para os nós secundários do SQL Server. Existem vários métodos para mover os ficheiros de certificado e chave para os nós secundários em node-2 e node-3.

Para outras opções de transferência, consulte o artigo Transfira ficheiros para VMs Linux

Transfira os ficheiros de certificado e chave através do Cloud Storage

Crie um Cloud Storage para transferir ficheiros dos nós do cluster principal para os do cluster secundário.
1. Crie um contentor do Cloud Storage:
  1. Regresse 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 contentor a criar. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto e substitua REGION pelo ID da região onde quer implementar o contentor.
  Para mais informações, consulte o artigo Crie contentores.
2. Regresse ao SSH em node-1, node-2 e node-3 para inicializar a CLI do Google Cloud:
  1. Execute o seguinte comando para inicializar a CLI do Google Cloud.
    
    gcloud init
  2. Escolha option [1] para usar a conta de serviço pré-instalada.
  3. Introduza o nome do projeto.
  4. Introduza n na pergunta para configurar a região e a zona predefinidas.
3. Regresse a node-1 para copiar os ficheiros para o Cloud Storage:
  1. Carregue os dois ficheiros criados recentemente para o Cloud Storage executando os seguintes comandos.
    
    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 contentor criado.
4. Regresse a node-2 e node-3 para copiar os ficheiros do armazenamento na nuvem:
  1. Transfira os dois ficheiros 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 contentor criado.
  2. Altere a propriedade dos ficheiros no node-2 e no node-3 executando o comando numa shell de raiz.
    
    chown mssql:mssql /var/opt/mssql/data/my_ag_certificate.* chmod 660 /var/opt/mssql/data/my_ag_certificate.*
    
    Dica: lembre-se de sair da shell de raiz após executar os comandos.
Configure o ponto final da replicação espelhada da base de dados

Nesta secção, vai criar o ponto final da base de dados através de uma chave de encriptação e um certificado partilhados por cada nó no cluster do SQL Server para garantir a replicação segura de dados.
1. Regresse à VM do Windows em node-4 para criar os pontos finais de replicação espelhada da base de dados:
  1. Estabeleça ligação às bases de dados do SQL Server no node-1, node-2 e node-3 através do SSMS. Siga os passos em Estabeleça ligação ao SQL Server usando node-1, node-2 e node-3 como o nome do servidor e as respetivas palavras-passe que definiu para a conta SA.
  2. Crie o certificado nas VMs secundárias node-2 e node-3 a partir dos ficheiros copiados. Use as palavras-passe que indicou quando criou 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 palavras-passe da chave de encriptação e da chave privada.
  3. Regresse ao SSMS para criar pontos finais de espelhamento de bases de dados executando o comando T-SQL para node-1, node-2 e node-3.
    
    Sugestão: a porta de escuta predefinida é 5022, mas pode usar quaisquer outras portas disponíveis.
    
    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;
Crie e configure o grupo de disponibilidade Always On

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

Nota: é necessária uma base de dados para a replicação para criar um grupo de disponibilidade Always On. Neste tutorial, vai criar uma base de dados fictícia denominada bookshelf. Depois de criado, é possível adicionar ou remover bases de dados adicionais do grupo de disponibilidade AlwaysOn.
1. Regresse à VM do Windows e abra o SSMS:
  1. Estabeleça ligação ao motor da base de dados do SQL Server em node-1 e abra uma nova janela de consulta.
2. Crie uma base de dados e faça uma cópia de segurança da base de dados em preparação 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 Always On:
  1. Execute o seguinte comando T-SQL no SSMS em node-1, node-2 e node-3. Isto garante que os pontos finais estão ativados e que o SQL Server em cada nó está 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 seguinte comando T-SQL 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 seguinte comando T-SQL em node-2 e node-3 para cada instância do SQL Server para aderir ao novo grupo de disponibilidade.
    
    ALTER AVAILABILITY GROUP [aoag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL); GO ALTER AVAILABILITY GROUP [aoag1] GRANT CREATE ANY DATABASE; GO
  Criou uma nova base de dados denominada bookshelf e adicionou a nova base de dados a um novo grupo de disponibilidade denominado 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 na base de dados bookshelf vão ser replicados de forma síncrona nas instâncias do SQL Server nos três nós.
Instale e configure o Pacemaker

O Pacemaker é um software de gestão de recursos de alta disponibilidade de código aberto, usado com o motor de cluster Corosync. Nesta secção, instala e configura o Pacemaker em cada uma das suas VMs.

Crie um início de sessão do SQL Server para o gestor de clusters do pacemaker

Nesta secção, vai criar uma nova conta do SQL Server para o Pacemaker usar para iniciar sessão em cada instância do SQL Server e gerir 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 palavra-passe para a conta do pacemaker.
2. Execute o comando T-SQL para conceder as autorizações de início de sessão do pacemaker ao grupo de disponibilidade:
  GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::[aoag1] TO [pacemaker]; GRANT VIEW SERVER STATE TO [pacemaker]; GO
3. Regresse ao SSH em node-1, node-2 e node-3 para executar os comandos para guardar o nome de utilizador e a palavra-passe 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 palavra-passe da conta de marca-passos.
Instale o Pacemaker

Em seguida, instale o Pacemaker e configure uma conta de início de sessão em todas as VMs Linux para a gestão de recursos.
1. Abra as portas da firewall para o pacemaker:
  1. Verifique se o Uncomplicated Firewall está instalado e ativado executando o seguinte comando no node-1, node-2 e node-3.
    
    sudo ufw status
  2. Se o ufw estiver ativado, abra as portas da 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
    
    Nota: se estiver a usar outras portas para o SQL Server ou para o ponto final do grupo de disponibilidade, altere as regras das firewalls em conformidade
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 palavra-passe para o utilizador hacluster em node-1, node-2 e node-3:
  
  Nota: defina a mesma palavra-passe em todos os três nós. Vai precisar desta palavra-passe durante o resto da configuração.
  sudo passwd hacluster
Configure o Corosync

Agora, vai configurar o Corosync para gerir os membros do cluster e as mensagens no cluster.
1. Crie uma chave de autenticação para o Corosync em node-1:
  sudo corosync-keygen
2. Modifique o ficheiro de configuração do Corosync:
  1. Volte a node-1 e modifique o ficheiro corosync.conf.
    
    sudo vi /etc/corosync/corosync.conf
  2. Atualize as secções realçadas. Após a edição, o ficheiro deve ter o seguinte aspeto.
    
    # 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 ficheiros de configuração através do Cloud Storage
1. Carregue a chave de autenticação gerada e os ficheiros de configuração do corosync de node-1 para o seu contentor 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 contentor criado anteriormente.
2. Transfira os ficheiros 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 contentor para o qual os ficheiros de configuração do Corosync foram transferidos.
3. Atualize as autorizações dos ficheiros no node-2 e no node-3:
  sudo chmod 400 /etc/corosync/authkey sudo chmod 400 /etc/corosync/corosync.conf
Reinicie e valide 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 estado do cluster executando o comando em node-1:
  sudo crm status
  Deve ver todos os três nós online.
Configure o cluster

Em seguida, vai configurar o cluster do Pacemaker criando um novo recurso para o grupo de disponibilidade Always On do SQL Server.
1. Execute o seguinte 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 agrupamento.
2. Autorize os nós no cluster executando o comando em node-1. Use a palavra-passe definida anteriormente para a conta hacluster:
  sudo pcs cluster auth -u hacluster
  Deve 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 no node-1, node-2 e node-3:
  sudo apt-get install mssql-server-ha
4. Regresse a node-1 e crie um recurso de grupo de disponibilidade no cluster:
  1. Execute o Gestor de recursos de cluster.
    
    sudo crm
  2. Escreva configure para aceder ao menu de configuração.
  3. Introduza 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. Escreva commit para confirmar as alterações.
    
    Nota: recebe um aviso de que não foi configurada nenhuma regra de restrição. Ignore esta mensagem. Vai configurar uma regra de restrição num passo posterior.
  5. Escreva exit para sair do gestor de recursos do cluster.
  6. Valide a configuração.
    
    sudo crm status
    
    Deve ver que node-1 foi promovido ao nó principal. Node-2 e node-3 devem ser definidos como os nós secundários.
Configure o balanceador de carga e o ouvinte do grupo de disponibilidade

Nesta secção, cria um endereço IP virtual e um recurso de verificação de estado no cluster através de um balanceador de carga TCP de passagem interno que encaminha o tráfego para o grupo de disponibilidade.
1. Regresse ao Cloud Shell e reserve um endereço IP estático que vai usar 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 onde as VMs Linux estão implementadas.
  
  Nota: guarde o endereço IP reservado, pois vai usá-lo num passo posterior.
2. Crie grupos de instâncias não geridos 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 Linux estão implementadas.
3. Crie uma verificação de funcionamento de TCP. Os equilibradores de carga usam verificações de funcionamento para determinar que 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 e substitua HEALTH_CHECK_PORT pelo valor de uma porta que esteja livre e no intervalo privado de 49152 a 65535 . Por exemplo, 60000.
  
  Para mais informações, leia a vista geral das verificações de estado.
4. Adicione etiquetas de rede aos nós do cluster. A etiqueta de rede é usada pela regra da firewall para a verificação de funcionamento:
  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 etiqueta de rede.
5. Crie uma regra de firewall para permitir que as verificações de funcionamento alcancem os nós do cluster com base no nome da etiqueta:
  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 o artigo Regras da firewall para verificações de funcionamento.
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 geridos 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 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.
  
  Sugestão: se precisar que o cluster seja acessível por clientes em qualquer região da rede VPC ou de uma rede ligada, tem de incluir o --allow-global-access na definição da regra de encaminhamento.
  
  Para mais informações, consulte o artigo 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 ficheiro haproxy.cfg.
    
    sudo vi /etc/haproxy/haproxy.cfg
  4. Na secção de predefinições do haproxy.cfg file, altere o modo para tcp.
  5. Anexe a secção seguinte no final do ficheiro 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 estado selecionada anteriormente. Por exemplo, 6000.
  6. Inicie o serviço para confirmar que está configurado corretamente:
    
    sudo systemctl start haproxy.service sudo systemctl enable haproxy.service sudo systemctl restart haproxy.service
  7. Aceda à página Balanceamento de carga e clique no balanceador de carga. Observe os três grupos de instâncias não geridos. Agora, devem ser comunicados como estando em bom estado.
    
    Aceda a Balanceamento de carga
    
    Em alternativa, pode executar o seguinte comando no Cloud Shell para ver o estado do serviço de back-end.
    
    gcloud compute backend-services get-health aoag1-backend \ --region REGION
    
    Substitua REGION pela região onde as VMs Linux estão implementadas.
  8. Quando todos os três grupos de instâncias não geridos estiverem a comunicar um estado de funcionamento, avance para o passo seguinte.
    
    Nota: se o grupo de instâncias não gerido não estiver em bom estado, pode ter de reiniciar o haproxy.service a partir do nó em questão.
    
    sudo systemctl restart haproxy.service
10. Crie o recurso de verificação de funcionamento no Pacemaker:
  1. Use SSH para aceder a node-1 e crie um recurso de verificação de estado 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 saúde foi iniciado no nó principal node-1:
    
    sudo crm status
  3. Se o recurso de verificação de estado 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
    
    Vai ver que a verificação de funcionamento do balanceador de carga só vai estar em bom estado durante node-1.
    
    Aceda a Balanceamento de carga
11. Crie um recurso de endereço IP virtual no cluster do Pacemaker:
  1. Regresse ao SSH em node-1 e encontre o nome da interface de rede do seu nó. Vai precisar dele no passo seguinte.
    
    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 do passo anterior e CLUSTER_ADDRESS pelo endereço IP reservado.
  3. Verifique se o recurso de endereço IP virtual está iniciado no anfitrião principal.
    
    sudo crm status
  4. Se o recurso de endereço IP virtual não for iniciado no nó principal, mova-o com os seguintes comandos.
    
    sudo pcs resource move aoag1-vip node-1
  5. Agrupe os recursos de verificação de funcionamento 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 grupo principal.
    
    sudo pcs constraint colocation add master aoag1-group with master ms-ag1 score=INFINITY
Crie um ouvinte para o seu grupo de disponibilidade do SQL Server

As ligações ao SQL Server com grupos de disponibilidade devem usar um nome de ouvinte do grupo de disponibilidade em vez do nome do servidor. Se ocorrer uma comutação por falha, o ouvinte redireciona automaticamente as ligações para o novo nó principal no cluster.
1. Regresse ao SSMS e estabeleça ligação à base 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 vedação STONITH

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

Configure dispositivos de vedações
1. Verifique se o fence_gce - Fence agent for Compute Engine está instalado em node1:
  sudo pcs stonith list | grep fence_gce
  Para mais informações, consulte:
  - Agente de vedação para o Google Compute Engine.
  - Para ver os parâmetros associados à execução do agente.
    
    sudo pcs stonith describe fence_gce
2. Em node-1, crie os recursos do fence_gcetipo de vedação 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 Linux estão implementadas e substitua PROJECT_ID pelo ID do projeto.
3. Pode testar o estado dos agentes de vedação executando o comando de estado:
  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 os seus dispositivos de vedação para garantir que estão a ser 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 a vedação no cluster do pacemaker e defina o tempo limite da vedação do cluster:
  sudo pcs -f stonith_cfg property set stonith-enabled=true sudo pcs property set stonith-timeout="300s"
6. Verifique o estado do cluster:
  sudo crm status
Teste os dispositivos de vedação

Após a configuração dos dispositivos de vedação, recomendamos que os teste através dos seguintes passos.
1. Parar a vedação em node-2:
  1. Estabeleça ligação a node-1 e execute o seguinte comando para testar o dispositivo de vedação associado a node-2 a partir do cluster.
    
    fence_gce -o off -n node-2 --zone=REGION-b
  2. Verifique o estado do cluster.
    
    sudo crm status
  3. Também verá que a opção node-2 está desativada no Compute Engine.
    
    Aceder ao Compute Engine
2. Reinicie a vedação em node-2:
  1. Volte a node-1 e reinicie a instância novamente executando o seguinte comando.
    
    fence_gce -o on -n node-2 --zone=REGION-b
  2. Verifique o estado do cluster no Pacemaker e no Compute Engine. Após um curto período, vai ver que o canal node-2 está novamente online.
    
    sudo crm status
Configure o Corosync para o reinício atrasado

Para evitar problemas de sincronização e garantir uma ordem adequada das operações realizadas em caso de ação de isolamento, recomendamos que atrase o reinício do serviço Corosync durante 60 segundos.

Para mais informações, consulte o artigo da base de conhecimentos da Red Hat.
1. Crie um ficheiro de substituição do systemd que defina um atraso no início do serviço Corosync no node-1, node-2 e node-3:
  1. Abra o corosync.service para edição.
    sudo systemctl edit corosync.service
  2. Acrescente as seguintes linhas, guarde o ficheiro e saia do editor.
    
    [Service] ExecStartPre=/bin/sleep 60
  3. Atualize o gestor de serviços e verifique se a configuração é tida em conta.
    
    sudo systemctl daemon-reload systemctl status corosync.service --no-pager
    
    Se vir a secção Inserção, significa que as definições no ficheiro de inserção foram tidas em conta com êxito
Teste de comutação por falha

Já pode testar se a comutação por falha funciona conforme esperado.
1. Estabeleça ligação à VM do Windows em node-4 através do Ambiente de Trabalho Remoto:
2. Abra uma sessão do PowerShell:
3. Execute o seguinte guião:
  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 palavra-passe da conta SA no SQL Server.
  
  A cada 2 segundos, o script liga-se ao SQL Server através do ouvinte do grupo de disponibilidade ou do ouvinte da DNN e consulta o nome do servidor.
  
  Deixe o script em execução.
4. Regresse ao SSH em node-1 e execute os comandos para acionar uma comutação por falha 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. Regresse à sessão do PowerShell em node-4:
  1. Observe o resultado do script em execução e repare que o nome do servidor muda de node-1 para node-2 como resultado da comutação por falha.
6. Regresse a node-1 e inicie uma reversão 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 no node-4 e pare o script premindo Ctrl+C.
Limpar

Depois de concluir o tutorial, pode limpar os recursos que criou para que deixem de usar a quota e incorrer em custos. As secções seguintes descrevem como eliminar ou desativar estes recursos.

Eliminar o projeto

A forma mais fácil de eliminar a faturação é eliminar o projeto que criou para o tutorial.

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

Configure um cluster do SQL Server no Linux com grupos de disponibilidade Always On e Pacemaker Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Prepare o projeto e a rede

Crie VMs do Linux

Instale e configure o SQL Server

Estabeleça ligação ao SQL Server

Ative o grupo de disponibilidade Always On

Transfira os ficheiros de certificado e chave

Transfira os ficheiros de certificado e chave através do Cloud Storage

Configure o ponto final da replicação espelhada da base de dados

Crie e configure o grupo de disponibilidade Always On

Instale e configure o Pacemaker

Crie um início de sessão do SQL Server para o gestor de clusters do pacemaker

Instale o Pacemaker

Configure o Corosync

Transfira os ficheiros de configuração através do Cloud Storage

Reinicie e valide a comunicação do cluster

Configure o cluster

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

Crie um ouvinte para o seu grupo de disponibilidade do SQL Server

Configure uma vedação STONITH

Configure dispositivos de vedações

Teste os dispositivos de vedação

Configure o Corosync para o reinício atrasado

Teste de comutação por falha

Limpar

Eliminar o projeto

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