Configure grupos de disponibilidade Always On do SQL Server com confirmação síncrona através de um equilibrador de carga interno

Os grupos de disponibilidade Always On do Microsoft SQL Server permitem-lhe replicar bases de dados em várias instâncias do SQL Server Enterprise.

Semelhante às instâncias de cluster de comutação por falha do SQL Server, os grupos de disponibilidade Always On usam o clustering de comutação por falha do Windows Server (WSFC) para implementar a alta disponibilidade. No entanto, as duas funcionalidades diferem das seguintes formas:

Grupos de disponibilidade Always On Instâncias de cluster de failover
Âmbito da comutação por falha Grupo de bases de dados Instância
Armazenamento Não partilhado Partilhado

Para uma comparação mais detalhada, consulte o artigo Comparação de instâncias de cluster de failover e grupos de disponibilidade.

Os grupos de disponibilidade Always On suportam vários modos de disponibilidade. Este tutorial mostra como pode implementar grupos de disponibilidade Always On no modo de confirmação síncrono para implementar a alta disponibilidade para uma ou mais bases de dados.

Na configuração, vai criar três instâncias de VM. Duas instâncias de VM, node-1 e node-2, funcionam como nós do cluster e executam o SQL Server. É usada uma terceira instância de VM, witness, para alcançar um quorum num cenário de comutação por falha. As três instâncias de VM estão distribuídas por três zonas e partilham uma sub-rede comum.

Usando um grupo de disponibilidade Always On do SQL Server, uma base de dados de exemplo, bookshelf, é replicada de forma síncrona nas duas instâncias do SQL Server.

Num ambiente de cluster do Windows no local, os anúncios do protocolo de resolução de endereços (ARP) acionam a comutação por falha do endereço IP. Google Cloud, no entanto, ignora os anúncios ARP. Consequentemente, tem de implementar uma das seguintes duas opções: usar um equilibrador de carga interno e um nome de rede distribuído (DNN).

Este artigo pressupõe que já implementou o Active Directory no Google Cloud e que tem conhecimentos básicos do SQL Server, do Active Directory e do Compute Engine. Para mais informações sobre o Active Directory no Google Cloud, consulte a secção Antes de começar.

Usando um grupo de disponibilidade Always On do SQL Server, uma base de dados de exemplo, bookshelf, é replicada de forma síncrona nas duas instâncias do SQL Server. Um balanceador de carga interno garante que o tráfego é direcionado para o nó ativo.

Para mais informações sobre o clustering de failover do Windows Server com um balanceador de carga interno, consulte o artigo sobre o clustering de failover.

Arquitetura

Este diagrama inclui o seguinte:

  • Duas instâncias de VM na mesma região e em zonas diferentes para o cluster de comutação por falha denominado node-1 e node-2. Um aloja a réplica principal da base de dados do SQL Server, enquanto o outro nó aloja a réplica secundária.
  • Uma terceira VM denominada witness serve como testemunha de partilha de ficheiros para fornecer um voto de desempate e alcançar um quórum para a comutação por falha.
  • Um equilibrador de carga interno à frente do cluster fornece um único ponto final para os clientes do SQL Server e usa uma verificação de estado para garantir que o tráfego é direcionado para o nó ativo.

Objetivos

Este tutorial tem como objetivo alcançar os seguintes objetivos:

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 concluir as tarefas neste tutorial, certifique-se de que:

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. Tem um domínio do Active Directory com, pelo menos, um controlador de domínio. Pode criar um domínio do Active Directory com o Microsoft AD gerido. Em alternativa, pode implementar um ambiente do Active Directory personalizado no Compute Engine e configurar uma zona de encaminhamento de DNS privado que encaminha consultas DNS para os controladores de domínio.
  7. Tem um utilizador do Active Directory com autorização para associar computadores ao domínio e pode iniciar sessão através do RDP. Se estiver a usar o Managed Microsoft AD, pode usar o utilizador setupadmin. Para mais informações sobre o aprovisionamento de contas de utilizador do Active Directory, consulte o artigo Aprovisionamento de contas de utilizador do Active Directory
  8. Um Google Cloud projeto e uma nuvem virtual privada (VPC) com conetividade aos controladores de domínio do Active Directory.
  9. Uma sub-rede a usar para as instâncias de VM do cluster de tolerância a falhas do Windows Server.
    10. Quando terminar este tutorial, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpar.

Prepare o seu projeto e rede

Para implementar os grupos de disponibilidade Always On do SQL Server, tem de preparar oGoogle Cloud projeto e a VPC para a implementação. As secções seguintes abordam como pode fazê-lo em detalhe.

Configure o projeto e a região

Para preparar o seu Google Cloud projeto 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 Ative o Cloud Shell..

    Aceda à Google Cloud consola

  2. Inicialize as seguintes variáveis.

    VPC_NAME=VPC_NAME
SUBNET_NAME=SUBNET_NAME

    Substitua o seguinte:

    • VPC_NAME: nome da sua VPC
    • SUBNET_NAME: nome da sua sub-rede

  3. Defina o ID do projeto predefinido.

    gcloud config set project PROJECT_ID

    Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

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

Crie regras de firewall

Para permitir que os clientes se liguem ao SQL Server e à comunicação entre os nós do cluster, tem de criar várias regras de firewall. Pode usar etiquetas de rede para simplificar a criação destas regras de firewall, da seguinte forma:

  • Os dois nós de cluster estão anotados com a etiqueta wsfc-node.
  • Todos os servidores (incluindo o witness) estão anotados com a etiqueta wsfc.

Para criar regras de firewall que usem estas etiquetas de rede, siga estes passos:

  1. Regresse à sua sessão do Cloud Shell existente.

  2. Crie regras de firewall para permitir o tráfego entre nós do cluster.

    SUBNET_CIDR=$(gcloud compute networks subnets describe $SUBNET_NAME --format=value\('ipCidrRange'\))

gcloud compute firewall-rules create allow-all-between-wsfc-nodes \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp,udp,icmp \
  --enable-logging \
  --source-tags=wsfc \
  --target-tags=wsfc \
  --network=$VPC_NAME \
  --priority 10000

gcloud compute firewall-rules create allow-sql-to-wsfc-nodes \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp:1433 \
  --enable-logging \
  --source-ranges=$SUBNET_CIDR \
  --target-tags=wsfc-node \
  --network=$VPC_NAME \
  --priority 10000

Crie instâncias de VM

Crie e implemente duas instâncias de VM para o cluster de comutação por falha. Em qualquer momento, uma destas VMs aloja a réplica principal da base de dados do SQL Server enquanto o outro nó aloja a réplica secundária. As duas instâncias de VM têm de:

  • Estar localizadas na mesma região para que possam ser acedidas por um balanceador de carga de rede de encaminhamento interno.
  • Ter o cluster de tolerância a falhas do Windows Server e o SQL Server instalados.
  • Ter o suporte do WSFC do Compute Engine ativado.

Usar uma imagem premium do SQL Server com o SQL Server 2022 pré-instalado.

Para fornecer um voto de desempate e alcançar um quórum para o cenário de alternativa, implemente uma terceira VM que funcione como um testemunho de partilha de ficheiros através dos seguintes passos:

  1. Regresse à sua sessão do Cloud Shell existente.

  2. Crie um script especializado para os nós do WSFC. Este script instala as funcionalidades do Windows necessárias e cria regras de firewall para o WSFC e o SQL Server.

    cat << "EOF" > specialize-node.ps1

$ErrorActionPreference = "stop"

# Install required Windows features
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
Install-WindowsFeature RSAT-AD-PowerShell

# Open firewall for WSFC
netsh advfirewall firewall add rule name="Allow WSFC health check" dir=in action=allow protocol=TCP localport=59998

# Open firewall for SQL Server
netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433

# Open firewall for SQL Server replication
netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022

# Format data disk
Get-Disk |
 Where partitionstyle -eq 'RAW' |
 Initialize-Disk -PartitionStyle MBR -PassThru |
 New-Partition -AssignDriveLetter -UseMaximumSize |
 Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false

# Create data and log folders for SQL Server
md d:\Data
md d:\Logs
EOF

  3. Crie as instâncias de VM. Nas duas VMs que funcionam como nós do cluster, anexe um disco de dados adicional e ative o clustering de failover do Windows Server definindo a chave de metadados enable-wsfc como true:

    REGION=$(gcloud config get-value compute/region)
ZONE1=ZONE1
ZONE2=ZONE2
ZONE3=ZONE3
PD_SIZE=200
MACHINE_TYPE=n2-standard-8

gcloud compute instances create node-1 \
  --zone $ZONE1 \
  --machine-type $MACHINE_TYPE \
  --subnet $SUBNET_NAME \
  --image-family sql-ent-2022-win-2022 \
  --image-project windows-sql-cloud \
  --tags wsfc,wsfc-node \
  --boot-disk-size 50 \
  --boot-disk-type pd-ssd \
  --boot-disk-device-name "node-1" \
  --create-disk=name=node-1-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --metadata enable-wsfc=true \
  --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1

gcloud compute instances create node-2 \
  --zone $ZONE2 \
  --machine-type $MACHINE_TYPE \
  --subnet $SUBNET_NAME \
  --image-family sql-ent-2022-win-2022 \
  --image-project windows-sql-cloud \
  --tags wsfc,wsfc-node \
  --boot-disk-size 50 \
  --boot-disk-type pd-ssd \
  --boot-disk-device-name "node-2" \
  --create-disk=name=node-2-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --metadata enable-wsfc=true \
  --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1

gcloud compute instances create "witness" \
  --zone $ZONE3 \
  --machine-type e2-medium \
  --subnet $SUBNET_NAME \
  --image-family=windows-2022 \
  --image-project=windows-cloud \
  --tags wsfc \
  --boot-disk-size 50 \
  --boot-disk-type pd-ssd \
  --metadata sysprep-specialize-script-ps1="add-windowsfeature FS-FileServer"

    Substitua ZONE1, ZONE2 e ZONE3 com base nas zonas que está a usar.

  4. Para associar as três instâncias de VM ao Active Directory, faça o seguinte para cada uma das três instâncias de VM:

    1. Monitorize o processo de inicialização da VM vendo a respetiva saída da porta de série.

      gcloud compute instances tail-serial-port-output NAME

      Substitua NAME pelo nome da instância de VM.

      Aguarde alguns minutos até ver o resultado Instance setup finished e, em seguida, prima Ctrl+C. Neste momento, a instância de VM está pronta a ser usada.

    2. Crie um nome de utilizador e uma palavra-passe para a instância de VM.

    3. Estabeleça ligação à VM através do Ambiente de Trabalho Remoto e inicie sessão com o nome de utilizador e a palavra-passe criados no passo anterior.

    4. Clique com o botão direito do rato no botão Iniciar (ou prima Win+X) e clique em Windows PowerShell (administrador).

    5. Clique em Sim para confirmar o pedido de elevação.

    6. Associe o computador ao seu domínio do Active Directory e reinicie-o.

      Add-Computer -Domain DOMAIN -Restart

      Substitua DOMAIN pelo nome DNS do seu domínio do Active Directory.

    7. Introduza as credenciais de uma conta que tenha autorizações para associar uma VM ao domínio

      Aguarde que a VM seja reiniciada. Agora, juntou a instância de VM ao Active Directory.

Reserve endereços IP estáticos

Agora, reserva dois endereços IP estáticos na sua VPC. Um endereço IP é usado como o endereço IP do cluster WSFC predefinido. O outro serve como o IP estático para o ouvinte do grupo de disponibilidade do SQL Server.

Num cluster WSFC, o endereço IP do cluster serve principalmente para fins administrativos e para aceder aos recursos do cluster. Este endereço IP virtual é atribuído ao próprio cluster, o que permite aos administradores gerir o cluster e realizar tarefas como configurar as definições do cluster, monitorizar o estado de funcionamento dos nós e gerir processos de comutação por falha.

No contexto do grupo de disponibilidade do SQL Server, um ouvinte é um nome de rede virtual (VNN) e um endereço IP que permite aos clientes estabelecer ligação ao grupo de disponibilidade sem ter de saber que servidor específico é o nó principal.

Um balanceador de carga interno precisa de um endereço IP interno para encaminhar eficientemente o tráfego interno e suportar a elevada disponibilidade e o balanceamento de carga no contexto de um cluster WSFC. O balanceador de carga interno garante que os pedidos são sempre direcionados para a réplica principal atual do cluster. Durante eventos de comutação por falha, o balanceador de carga deteta alterações na réplica principal e redireciona as ligações de clientes para a nova principal sem exigir intervenção manual, minimizando o tempo de inatividade e garantindo a disponibilidade contínua dos serviços de base de dados.

No contexto de um WSFC com grupos de disponibilidade Always On do SQL Server, os endereços IP estáticos internos reservados para o endereço IP do cluster WSFC predefinido e o ouvinte do grupo de disponibilidade também são usados por equilibradores de carga internos associados.

  1. Para reservar dois endereços IP estáticos na sua VPC, siga os passos abaixo.

    gcloud compute addresses create wsfc-cluster-ip \
  --subnet $SUBNET_NAME \
  --region $(gcloud config get-value compute/region) && \
CLUSTER_IP=$(gcloud compute addresses describe wsfc-cluster-ip \
    --region $(gcloud config get-value compute/region) \
    --format=value\(address\)) && \
echo "cluster IP: $CLUSTER_IP"

  2. Substitua o endereço IP do cluster na variável CLUSTER_IP. Vai precisar dele mais tarde para o especificar como o IP do cluster:

    CLUSTER_IP=CLUSTER_IP

  3. Reserve outro IP estático para o ouvinte do grupo de disponibilidade e capture o endereço numa nova variável de ambiente denominada LISTENER_IP.

    gcloud compute addresses create wsfc-listener-ip \
  --subnet $SUBNET_NAME \
  --region $(gcloud config get-value compute/region)

LISTENER_IP=$(gcloud compute addresses describe wsfc-listener-ip \
  --region $(gcloud config get-value compute/region) \
  --format=value\(address\)) && \
echo "Listener IP: $LISTENER_IP"

  4. Substitua o endereço IP reservado do equilibrador de carga pela variável LISTENER_IP. Vai precisar dele mais tarde para configurar o grupo de disponibilidade.

    LISTENER_IP=LISTENER_IP

O projeto e a VPC estão agora prontos para a implementação do cluster de failover do Windows Server e do SQL Server.

Implementar o cluster de comutação por falha

Agora, pode usar as instâncias de VM para implementar um cluster de tolerância a falhas do Windows Server e o SQL Server. As secções seguintes abordam como pode fazê-lo em detalhe.

Preparar o SQL Server

Crie uma nova conta de utilizador no Active Directory para o SQL Server através dos seguintes passos.

  1. Ligue-se a node-1 através do Ambiente de Trabalho Remoto. Inicie sessão com a sua conta de utilizador do domínio.
  2. Clique com o botão direito do rato no botão Iniciar (ou prima Win+X) e clique em Windows PowerShell (administrador).
  3. Clique em Sim para confirmar o pedido de elevação.

  4. Crie uma conta de utilizador do domínio para o SQL Server e o agente SQL e atribua uma palavra-passe:

    $Credential = Get-Credential -UserName sql_server -Message 'Enter password'
New-ADUser `
  -Name "sql_server" `
  -Description "SQL Admin account." `
  -AccountPassword $Credential.Password `
  -Enabled $true -PasswordNeverExpires $true

Para configurar o SQL Server, siga estes passos em node-1 e node-2:

  1. Abra o Gestor de configuração do SQL Server.
  2. No painel de navegação, selecione Serviços do SQL Server.
  3. Na lista de serviços, clique com o botão direito do rato em SQL Server (MSSQLSERVER) e selecione Propriedades.

  4. Em Iniciar sessão como, altere a conta da seguinte forma:

    • Nome da conta: DOMAIN\sql_server onde DOMAIN é o nome NetBIOS do seu domínio do Active Directory.
    • Palavra-passe: introduza a palavra-passe que escolheu anteriormente.

  5. Clique em OK.

  6. Quando lhe for pedido para reiniciar o SQL Server, selecione Sim.

O SQL Server é agora executado numa conta de utilizador do domínio.

Crie partilhas de ficheiros

Crie duas partilhas de ficheiros na instância de VM witness para que possa armazenar cópias de segurança do SQL Server e atuar como testemunha de partilha de ficheiros:

  1. Ligue-se a witness através do Ambiente de Trabalho Remoto. Inicie sessão com a sua conta de utilizador do domínio.
  2. Clique com o botão direito do rato no botão Iniciar (ou prima Win+X) e clique em Windows PowerShell (administrador).
  3. Clique em Sim para confirmar o pedido de elevação.

  4. Crie uma partilha de ficheiros de testemunho e conceda a si próprio e aos dois nós do cluster acesso à partilha de ficheiros.

    New-Item "C:\QWitness" –type directory

icacls C:\QWitness\ /grant 'node-1$:(OI)(CI)(M)'
icacls C:\QWitness\ /grant 'node-2$:(OI)(CI)(M)'

New-SmbShare `
  -Name QWitness `
  -Path "C:\QWitness" `
  -Description "SQL File Share Witness" `
  -FullAccess $env:username,node-1$,node-2$

  5. Crie outra partilha de ficheiros para armazenar cópias de segurança e conceda acesso total ao SQL Server:

    New-Item "C:\Backup" –type directory
New-SmbShare `
  -Name Backup `
  -Path "C:\Backup" `
  -Description "SQL Backup" `
  -FullAccess  $env:USERDOMAIN\sql_server

Crie o cluster de comutação por falha

Para criar o cluster de comutação por falha, siga estes passos:

  1. Volte à sessão do Ambiente de Trabalho Remoto em node-1.
  2. Clique com o botão direito do rato no botão Iniciar (ou prima Win+X) e clique em Windows PowerShell (administrador).
  3. Clique em Sim para confirmar o pedido de elevação.

  4. Crie um novo cluster.

    New-Cluster `
  -Name sql-cluster `
  -Node node-1,node-2 `
  -NoStorage `
  -StaticAddress CLUSTER_IP

    Substitua CLUSTER_IP pelo endereço IP do cluster que criou anteriormente.

  5. Regresse à sessão do PowerShell em witness e conceda ao objeto de computador virtual do cluster autorização para aceder à partilha de ficheiros.

    icacls C:\QWitness\ /grant 'sql-cluster$:(OI)(CI)(M)'
Grant-SmbShareAccess `
  -Name QWitness `
  -AccountName 'sql-cluster$' `
  -AccessRight Full `
  -Force

  6. Regresse à sessão do PowerShell no node-1 e configure o cluster para usar a partilha de ficheiros no witness como um quorum de cluster.

    Set-ClusterQuorum -FileShareWitness \\witness\QWitness

  7. Verifique se o cluster foi criado com êxito.

    Test-Cluster

    Pode ver os seguintes avisos que pode ignorar com segurança.

    WARNING: System Configuration - Validate All Drivers Signed: The test reported some warnings..
WARNING: Network - Validate Network Communication: The test reported some warnings..
WARNING:
Test Result:
HadUnselectedTests, ClusterConditionallyApproved
Testing has completed for the tests you selected. You should review the warnings in the Report.  A cluster solution is
supported by Microsoft only if you run all cluster validation tests, and all tests succeed (with or without warnings).

    Também pode iniciar o snap-in MMC do Gestor de clusters de failover para rever o estado do cluster executando cluadmin.msc.

  8. Se estiver a usar o AD gerido, adicione a conta do computador usada pelo cluster do Windows ao grupo Contas de associação ao domínio do serviço na nuvem para que possa associar computadores ao domínio.

    Add-ADGroupMember `
  -Identity "Cloud Service Domain Join Accounts" `
  -Members sql-cluster$

  9. Ative os grupos de disponibilidade Always On em ambos os nós.

    Enable-SqlAlwaysOn -ServerInstance node-1 -Force
Enable-SqlAlwaysOn -ServerInstance node-2 -Force

Criar um grupo de disponibilidade

Agora, cria uma base de dados de amostra bookshelf, inclui-a num novo grupo de disponibilidade denominado bookshelf-ag e configura a elevada disponibilidade.

Criar uma base de dados

Crie uma nova base de dados. Para efeitos deste tutorial, a base de dados não tem de conter dados.

  1. Volte à sessão do Ambiente de Trabalho Remoto em node-1.
  2. Abra o SQL Server Management Studio.
  3. Na caixa de diálogo Estabelecer ligação ao servidor, verifique se o nome do servidor está definido como node-1 e selecione Estabelecer ligação.
  4. No menu, selecione Ficheiro > Novo > Consulta com ligação atual.

  5. Cole o seguinte script SQL no editor:

    -- Create a sample database
CREATE DATABASE bookshelf ON PRIMARY (
  NAME = 'bookshelf',
  FILENAME='d:\Data\bookshelf.mdf',
  SIZE = 256MB,
  MAXSIZE = UNLIMITED,
  FILEGROWTH = 256MB)
LOG ON (
  NAME = 'bookshelf_log',
  FILENAME='d:\Logs\bookshelf.ldf',
  SIZE = 256MB,
  MAXSIZE = UNLIMITED,
  FILEGROWTH = 256MB)
GO

USE [bookshelf]
SET ANSI_NULLS ON
SET QUOTED_IDENTIFIER ON
GO

-- Create sample table
CREATE TABLE [dbo].[Books] (
  [Id] [bigint] IDENTITY(1,1) NOT NULL,
  [Title] [nvarchar](max) NOT NULL,
  [Author] [nvarchar](max) NULL,
  [PublishedDate] [datetime] NULL,
  [ImageUrl] [nvarchar](max) NULL,
  [Description] [nvarchar](max) NULL,
  [CreatedById] [nvarchar](max) NULL,
  CONSTRAINT [PK_dbo.Books] PRIMARY KEY CLUSTERED ([Id] ASC) WITH (
    PAD_INDEX = OFF,
    STATISTICS_NORECOMPUTE = OFF,
    IGNORE_DUP_KEY = OFF,
    ALLOW_ROW_LOCKS = ON,
    ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

-- Create a backup
EXEC dbo.sp_changedbowner @loginame = 'sa', @map = false;
  ALTER DATABASE [bookshelf] SET RECOVERY FULL;
  GO
  BACKUP DATABASE bookshelf to disk = '\\witness\Backup\bookshelf.bak' WITH INIT
GO

    O script cria uma nova base de dados com uma única tabela e faz uma cópia de segurança inicial para witness.

  6. Selecione Executar para executar o script SQL.

Configure a alta disponibilidade

Já pode configurar a elevada disponibilidade para o grupo de disponibilidade através do T-SQL ou do SQL Server Management Studio.

Usar T-SQL

Para configurar a elevada disponibilidade para o grupo de disponibilidade através de T-SQL, siga os seguintes passos:

  1. Estabeleça ligação a node-1 e, em seguida, execute o seguinte script para criar o grupo de disponibilidade bookshelf-ag.

    CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS;
GO

USE [bookshelf];
CREATE USER [NET_DOMAIN\sql_server] FOR LOGIN [NET_DOMAIN\sql_server];
GO

USE [master];
CREATE ENDPOINT bookshelf_endpoint
  STATE=STARTED
  AS TCP (LISTENER_PORT=5022)
  FOR DATABASE_MIRRORING (ROLE=ALL);
GO

GRANT CONNECT ON ENDPOINT::[bookshelf_endpoint] TO [NET_DOMAIN\sql_server]
GO

  2. Ligue-se ao node-2 e execute o seguinte script.

    CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS;
GO

CREATE ENDPOINT bookshelf_endpoint
  STATE=STARTED
  AS TCP (LISTENER_PORT=5022)
  FOR DATABASE_MIRRORING (ROLE=ALL);
GO

GRANT CONNECT ON ENDPOINT::[bookshelf_endpoint] TO [NET_DOMAIN\sql_server]
GO

  3. Em node-1 e, em seguida, execute o seguinte script para criar o grupo de disponibilidade bookshelf-ag.

    USE master;
GO

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

  4. No script seguinte, substitua LISTENER_IP pelo endereço IP que reservou anteriormente para o balanceador de carga interno e execute-o.

    USE master;
GO

ALTER AVAILABILITY GROUP [bookshelf-ag]
ADD LISTENER N'bookshelf' (
WITH IP (
  (N'LISTENER_IP', N'255.255.255.0')
),
PORT = 1433);
GO

  5. Ligue-se a node-2 e, em seguida, execute o seguinte script para associar a réplica secundária ao grupo de disponibilidade e ativar a sincronização automática.

    USE master;
GO

ALTER AVAILABILITY GROUP [bookshelf-ag] JOIN;
ALTER AVAILABILITY GROUP [bookshelf-ag] GRANT CREATE ANY DATABASE;

  6. Verifique o estado do grupo de disponibilidade.

    SELECT * FROM sys.dm_hadr_availability_group_states;
GO

    Deve ver synchronization_health_desc como HEALTHY

Usar o SQL Server Management Studio

Para configurar a elevada disponibilidade para o grupo de disponibilidade através do SQL Server Management Studio, siga estes passos:

  1. Na janela Object Explorer, clique com o botão direito do rato em Always On High Availability e, de seguida, selecione New Availability Group Wizard.
  2. Na página Especificar opções, defina o nome do grupo de disponibilidade como bookshelf-ag e, em seguida, selecione Seguinte.
  3. Na página Selecionar bases de dados, selecione a base de dados bookshelf e, de seguida, selecione Seguinte.

  4. Na página Especificar réplicas, selecione o separador Réplicas.

    1. Selecione Adicionar réplica.

    2. Na caixa de diálogo Ligar ao servidor, introduza o nome do servidor node-2 e selecione Ligar.

      A lista de réplicas de disponibilidade contém agora instâncias do SQL Server, node-1 e node-2.

    3. Defina o Modo de disponibilidade como Confirmação síncrona para ambas as instâncias.

    4. Defina a opção Comutação automática por falha como Ativada para ambas as instâncias.

    5. Selecione o separador Ouvinte

      1. Selecione Criar um ouvinte do grupo de disponibilidade.

      2. Introduza as seguintes definições.

        • Nome DNS do ouvinte: bookshelf
        • Porta: 1433
        • Modo de rede: IP estático

      3. Selecione Adicionar e introduza o endereço IP do ouvinte (LISTENER_IP) que reservou anteriormente para o balanceador de carga interno. Em seguida, selecione OK.

    6. Selecione Seguinte.

  5. Na página Selecionar sincronização de dados, selecione Preenchimento automático.

  6. Na página Validação, verifique se todas as verificações foram bem-sucedidas.

  7. Na página Resumo, selecione Concluir.

  8. Na página Resultados, selecione Fechar.

Crie verificações de funcionamento e balanceadores de carga internos

O IP do cluster representa um único ponto final para o cluster de failover do Windows. Utiliza-o para fins administrativos e para gerir recursos do cluster. O IP do cluster aponta sempre para o nó anfitrião (ou principal) do cluster. Implementa um balanceador de carga interno que usa uma verificação de funcionamento que garante que o tráfego é direcionado para o nó anfitrião do cluster. Uma vez que as ferramentas do WSFC requerem vários protocolos para estarem disponíveis para encaminhamento (ICMP, UDP e TCP), recomendamos a implementação de um balanceador de carga interno com vários protocolos que suportam todas as portas.

Para implementar um balanceador de carga interno, siga estes passos:

  1. Regresse à sua sessão do Cloud Shell existente.

  2. Crie dois grupos de instâncias não geridos, um por zona, e adicione os dois nós aos grupos.

    REGION=$(gcloud config get-value compute/region)

gcloud compute instance-groups unmanaged create wsfc-group-1 --zone $ZONE1
gcloud compute instance-groups unmanaged add-instances wsfc-group-1 --zone $ZONE1 \
  --instances node-1

gcloud compute instance-groups unmanaged create wsfc-group-2 --zone $ZONE2
gcloud compute instance-groups unmanaged add-instances wsfc-group-2 --zone $ZONE2 \
  --instances node-2

  3. Crie uma verificação de estado para o IP do cluster que o equilibrador de carga pode usar para determinar qual é o nó ativo na perspetiva do cluster do Windows. A porta predefinida à qual o agente convidado do Compute Engine responde às verificações de funcionamento é 59998. A verificação de estado fornece o endereço IP do cluster no pedido e espera 1 como resposta devolvida do nó ativo.

    gcloud compute health-checks create tcp wsfc-healthcheck \
  --request=$CLUSTER_IP \
  --response=1 \
  --check-interval="2s" \
  --healthy-threshold=2 \
  --unhealthy-threshold=2 \
  --port=59998 \
  --timeout="1s"

  4. Crie um serviço de back-end e adicione os dois grupos de instâncias existentes.

    gcloud compute backend-services create wsfc-backend \
  --load-balancing-scheme internal \
  --region $REGION \
  --health-checks wsfc-healthcheck \
  --protocol UNSPECIFIED

gcloud compute backend-services add-backend wsfc-backend \
  --instance-group wsfc-group-1 \
  --instance-group-zone $ZONE1 \
  --region $REGION

gcloud compute backend-services add-backend wsfc-backend \
  --instance-group wsfc-group-2 \
  --instance-group-zone $ZONE2 \
  --region $REGION

  5. Crie o balanceador de carga interno associado ao IP do cluster.

    gcloud compute forwarding-rules create wsfc \
  --load-balancing-scheme internal \
  --address $CLUSTER_IP \
  --ports ALL \
  --network $VPC_NAME \
  --subnet $SUBNET_NAME \
  --region $REGION \
  --ip-protocol L3_DEFAULT \
  --backend-service wsfc-backend

Para fornecer um único ponto final para clientes do SQL Server que queiram estabelecer ligação a qualquer base de dados no seu grupo de disponibilidade do bookshelf, implemente um novo equilibrador de carga interno dedicado a esse grupo de disponibilidade através dos seguintes passos:

  1. Crie uma verificação de estado para o ouvinte do grupo de disponibilidade que o equilibrador de carga pode usar para determinar qual é o nó principal no grupo de disponibilidade do SQL Server.bookshelf

    gcloud compute health-checks create tcp wsfc-bookshelf-healthcheck \
  --request=$LISTENER_IP \
  --response=1 \
  --check-interval="2s" \
  --healthy-threshold=1 \
  --unhealthy-threshold=2 \
  --port=59998 \
  --timeout="1s"

    A verificação de estado usa a mesma porta do agente convidado do Compute Engine, mas fornece no respetivo pedido o endereço IP do ouvinte do grupo de disponibilidade.bookshelf

  2. Crie um novo serviço de back-end e adicione os dois grupos de instâncias.

    gcloud compute backend-services create wsfc-bookshelf-backend \
  --load-balancing-scheme internal \
  --region $REGION \
  --health-checks wsfc-bookshelf-healthcheck \
  --protocol UNSPECIFIED

gcloud compute backend-services add-backend wsfc-bookshelf-backend \
  --instance-group wsfc-group-1 \
  --instance-group-zone $ZONE1 \
  --region $REGION

gcloud compute backend-services add-backend wsfc-bookshelf-backend \
  --instance-group wsfc-group-2 \
  --instance-group-zone $ZONE2 \
  --region $REGION

  3. Crie o balanceador de carga interno associado ao ouvinte do grupo de disponibilidade do SQL Server.bookshelf-ag

    gcloud compute forwarding-rules create wsfc-bookshelf \
  --load-balancing-scheme internal \
  --address $LISTENER_IP \
  --ports ALL \
  --network $VPC_NAME \
  --subnet $SUBNET_NAME \
  --region $REGION \
  --ip-protocol L3_DEFAULT \
  --backend-service wsfc-bookshelf-backend

Agora, pode estabelecer ligação ao ouvinte do grupo de disponibilidade do SQL Server através do nome DNS bookshelf e da respetiva porta definidos no ouvinte do grupo de disponibilidade do Bookshelf. O equilibrador de carga interno direciona o tráfego para o nó principal do grupo de disponibilidade.bookshelf

Para criar vários grupos de disponibilidade num único cluster de failover, tem de usar serviços de back-end separados e um balanceador de carga separado com a sua própria verificação de estado por grupo de disponibilidade.

Cada grupo de disponibilidade pode ter nós diferentes designados como principais e podem ser diferentes do nó anfitrião do cluster do Windows. Para vários grupos de disponibilidade, precisa do seguinte:

  • Um endereço IP estático reservado para o ouvinte do grupo de disponibilidade que o equilibrador de carga interno usa. Reserve um endereço para cada grupo de disponibilidade.

  • Uma regra de verificação do estado separada para cada grupo de disponibilidade. O pedido de verificação do estado fornece o endereço IP estático do ouvinte do grupo de disponibilidade (que também é o endereço IP reservado no passo anterior). As sondagens de verificação de funcionamento para a resposta 1 devolvidas pelo agente do GCE. Todas as verificações de funcionamento usam a porta 59998.

  • Um serviço de back-end separado para cada grupo de disponibilidade ao qual adiciona os dois grupos de instâncias de computação existentes. O serviço de back-end usa a verificação de estado de funcionamento definida no passo anterior.

  • Um balanceador de carga interno para cada grupo de disponibilidade do serviço de back-end criado no passo anterior. O balanceador de carga está associado ao endereço IP estático do ouvinte do grupo de disponibilidade.

Teste a comutação por falha

Já pode testar se a comutação por falha funciona conforme esperado:

  1. Regresse à sessão do PowerShell em witness.

  2. Execute o seguinte script.

    while ($True){
  $Conn = New-Object System.Data.SqlClient.SqlConnection
  $Conn.ConnectionString = "Server=tcp:bookshelf,1433;Integrated Security=true;Initial Catalog=master"
  $Conn.Open()

  $Cmd = New-Object System.Data.SqlClient.SqlCommand
  $Cmd.Connection = $Conn
  $Cmd.CommandText = "SELECT SERVERPROPERTY('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
}

    Neste guia, usámos o nome DNS bookshelf e o valor da porta 1433 para o ouvinte do grupo de disponibilidade na definição do servidor tcp:bookshelf,1433.

    A cada 2 segundos, o script estabelece ligação ao SQL Server através do ouvinte do grupo de disponibilidade e consulta o nome do servidor.

    Deixe o script em execução.

  3. Volte à sessão de Ambiente de Trabalho Remoto em node-1 para acionar uma comutação por falha.

    1. No SQL Server Management Studio, navegue para Always On High Availability > Availability Groups > bookshelf-ag (Primary) e clique com o botão direito do rato no nó.
    2. Selecione Failover.
    3. Na página Selecionar nova réplica principal, verifique se node-2 está selecionado como nova réplica principal e se a coluna Prontidão para a comutação por falha indica No data loss. Em seguida, selecione Seguinte.
    4. Na página Ligar à réplica, selecione Ligar.
    5. Na caixa de diálogo Ligar ao servidor, verifique se o nome do servidor é node-2 e clique em Ligar.
    6. Selecione Seguinte e, de seguida, Concluir.
    7. Na página Resultados, verifique se a comutação por falha foi bem-sucedida.

  4. Regresse à sessão do PowerShell em witness.

  5. 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. Pare o guião 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.

O que se segue?