Como configurar uma instância de cluster de failover do SQL Server que usa o Storage Spaces Direct

As instâncias de cluster de failover sempre ativadas (FCI) do Microsoft SQL Server permitem que você execute uma única instância do SQL Server em vários nós do cluster de failover do Windows Server (WSFC). A qualquer momento, um dos nós do cluster hospeda ativamente a instância do SQL. No caso de falha, o WSFC transfere automaticamente a propriedade dos recursos da instância para outro nó.

O FCI do SQL Server requer a localização dos dados em um armazenamento compartilhado para que possa ser acessado em todos os nós do WSFC. Neste guia, você verá como implantar uma instância de cluster de failover do SQL Server 2019 que usa o Storage Spaces Direct (S2D) para armazenamento compartilhado. O S2D fornece uma SAN virtual baseada em software que pode usar discos de dados da VM do Compute Engine para armazenar o banco de dados SQL.

O diagrama a seguir ilustra a implantação:

Arquitetura

Ao implementar uma arquitetura hiperconvergente, as instâncias de VM node-1 e node-2 servem como nós WSFC e hosts do armazenamento compartilhado. Uma terceira instância de VM, witness, é usada para alcançar um quórum em um cenário de failover. As três instâncias de VM são distribuídas em três zonas e compartilham uma sub-rede comum.

Os clientes se comunicam com a instância do SQL Server por meio de um balanceador de carga TCP interno. Esse balanceador de carga usa uma verificação de integridade personalizada para determinar qual nó WSFC está hospedando a instância SQL no momento e encaminha o tráfego para essa instância.

O artigo pressupõe que você já implantou o Active Directory no Google Cloud e que tem conhecimentos básicos de SQL Server, Active Directory e Compute Engine.

Objetivos

Implante um WSFC com duas instâncias de VM do SQL Server e uma terceira instância de VM que funciona como uma testemunha de compartilhamento de arquivos.
Implantar uma FCI do SQL Server no WSFC.
Verifique se o cluster está funcionando simulando um failover.

Custos

Neste tutorial, há componentes faturáveis do Google Cloud, entre eles:

Use a calculadora de preços para gerar uma estimativa de custo com base na projeção de uso.

Antes de começar

Para concluir este guia, você precisa do seguinte:

Um domínio do Active Directory atual com pelo menos um controlador de domínio. Crie um domínio do Active Directory usando o Microsoft AD gerenciado. Se preferir, implante um ambiente personalizado do Active Directory no Compute Engine e configure uma zona de encaminhamento de DNS particular que encaminhe consultas DNS aos controladores de domínio.
Um usuário do Active Directory que tenha permissão para associar computadores ao domínio e pode fazer login usando o RDP. Se você estiver usando o Microsoft AD gerenciado, utilize o usuário setupadmin.
Um projeto do Google Cloud e uma VPC com conectividade aos controladores de domínio do Active Directory.
Uma sub-rede a ser usada para as instâncias de VM do WSFC.

Para concluir o guia, você também precisa de um projeto do Google Cloud:

Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

Acessar o seletor de projetos

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

Acessar o seletor de projetos

Verifique se a cobrança está ativada para o seu projeto do Google Cloud.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Como fazer a limpeza.

Como preparar o projeto e a rede

Para preparar o projeto do Google Cloud e a VPC para a implantação da FCI do SQL Server, faça o seguinte:

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

Acesse o Console do Google Cloud
Inicialize as seguintes variáveis:
```
VPC_NAME=VPC_NAME
SUBNET_NAME=SUBNET_NAME
```
Em que:
- VPC_NAME: nome da VPC.
- SUBNET_NAME: nome da sub-rede.
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.

Crie regras de firewall

Para permitir que os clientes se conectem ao SQL Server, permita a comunicação entre os nós WSFC e que o balanceador de carga realize verificações de integridade, você precisa criar várias regras de firewall. Para simplificar a criação dessas regras de firewall, use tags de rede:

Os dois nós WSFC são anotados com a tag wsfc-node.
Todos os servidores (incluindo a testemunha) são anotados com a tag wsfc.

Crie regras de firewall que usem estas tags de rede:

Volte para a sessão atual do Cloud Shell.

Crie regras de firewall para os nós do WSFC:

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 uma regra de firewall que permita verificações de integridade dos intervalos de IP das sondas do Google Cloud:

gcloud compute firewall-rules create allow-health-check-to-wsfc-nodes \
  --direction=INGRESS \
  --action=allow \
  --rules=tcp \
  --source-ranges=130.211.0.0/22,35.191.0.0/16 \
  --target-tags=wsfc-node \
  --network=$VPC_NAME \
  --priority 10000

Crie instâncias de VM

Agora, implante duas instâncias de VM para o cluster de failover. A qualquer momento, apenas uma dessas VMs serve como o nó FCI ativo enquanto o outro nó atua como o nó de failover. As duas instâncias de VM precisam atender aos seguintes requisitos:

Elas estão localizadas na mesma região para que possam ser acessadas por um balanceador de carga TCP interno.
O agente convidado está configurado para usar o modo WSFC. Nesse modo, o agente convidado ignora os endereços IP dos balanceadores de carga internos ao configurar a interface de rede local. Esse comportamento é necessário para evitar conflitos de endereço IP durante eventos de failover do WSFC.

usar uma imagem premium do SQL Server que tenha o SQL Server 2019 pré-instalado.

Para dar um voto de desempate e conquistar um quórum para o cenário de failover, você implanta uma terceira VM que serve como uma testemunha de compartilhamento de arquivos.

Volte para a sessão atual do Cloud Shell.

Crie um script de especialização para os nós WSFC. O script instala o recurso necessário do Windows 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 SQL Server health check" dir=in action=allow protocol=TCP localport=59997

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

EOF

Crie as instâncias de VM. Nas duas VMs que servem como nós S2D e WSFC, anexe outros discos de dados e ative o modo WSFC definindo a chave de metadados enable-wsfc como true:

REGION=$(gcloud config get-value compute/region)
PD_SIZE=50
MACHINE_TYPE=n2-standard-8

gcloud compute instances create node-1 \
  --zone $REGION-a \
  --machine-type $MACHINE_TYPE \
  --subnet $SUBNET_NAME \
  --image-family sql-ent-2019-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-1,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-1-datadisk-2,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-1-datadisk-3,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-1-datadisk-4,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 $REGION-b \
  --machine-type $MACHINE_TYPE \
  --subnet $SUBNET_NAME \
  --image-family sql-ent-2019-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-1,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-2-datadisk-2,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-2-datadisk-3,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
  --create-disk=name=node-2-datadisk-4,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 $REGION-c \
  --machine-type n2-standard-2 \
  --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"

Para mesclar 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. Monitore o processo de inicialização da VM visualizando a saída da porta serial:
```
gcloud compute instances tail-serial-port-output NAME
```
  Substitua NAME pelo nome da instância de VM.
  
  Aguarde alguns minutos até ver a saída Instance setup finished e pressione Ctrl+C. Nesse momento, a instância de VM está pronta para ser usada.
2. Crie um nome de usuário e uma senha para a instância de VM.
3. Conecte-se à VM usando a Área de trabalho remota e faça login usando o nome de usuário e a senha criados na etapa anterior.
4. Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
5. Confirme a elevação do prompt clicando em Sim.
6. Associe o computador ao seu domínio do Active Directory e reinicie:
```
Add-Computer -Domain DOMAIN -Restart
```
  Substitua DOMAIN pelo nome DNS do seu domínio do Active Directory.
  
  Aguarde aproximadamente um minuto para que a reinicialização seja concluída.

Reservar endereços IP do cluster

Agora você reserva dois endereços IP estáticos na sua rede VPC. Os dois endereços servem a propósitos diferentes:

IP do balanceador de carga: esse endereço IP é usado pelos clientes para se conectarem ao SQL Server.
IP do cluster: esse endereço IP é usado internamente pelo WSFC.

Para reservar os endereços IP estáticos, faça o seguinte:

Reserve um IP estático para o balanceador de carga interno e capture o endereço em uma nova variável de ambiente chamada LOADBALANCER_ADDRESS:

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

LOADBALANCER_ADDRESS=$(gcloud compute addresses describe wsfc \
  --region $(gcloud config get-value compute/region) \
  --format=value\(address\)) && \
echo "Load Balancer IP: $LOADBALANCER_ADDRESS"

Anote o endereço IP, você precisará dele mais tarde.

Reserve outro endereço IP estático usado como IP do cluster

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

Anote o endereço IP, você precisará dele mais tarde.

Agora o projeto e a VPC estão prontos para a implantação do WSFC e do SQL Server.

Criar um compartilhamento de arquivos da testemunha

Para preparar o witness que serve como uma testemunha de compartilhamento de arquivos, crie um compartilhamento de arquivos e conceda a você e aos dois nós WSFC acesso ao compartilhamento de arquivos:

Conecte-se a witness usando a Área de trabalho remota. Faça login com a conta de usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.

Crie a pasta da testemunha e compartilhe-a:

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$

Como implantar o cluster de failover

Use as instâncias de VM para implantar um WSFC e SQL Server.

Implantar o WSFC

Agora você está pronto para criar o cluster de failove.

Conecte-se a node-1 usando a Área de trabalho remota. Faça login com a conta de usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.
Crie um novo cluster:
```
New-Cluster `
  -Name windows-fci `
  -Node node-1,node-2 `
  -NoStorage `
  -StaticAddress CLUSTER_ADDRESS
```
Substitua CLUSTER_ADDRESS pelo endereço IP do cluster que você criou anteriormente.

O comando cria uma conta de computador windows-fci no seu domínio do Active Directory.

Volte à sessão do PowerShell em witness e conceda à conta do computador a permissão windows-fci para acessar o compartilhamento de arquivos:

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

Retorne à sessão do PowerShell em node-1 e configure o cluster para usar o compartilhamento de arquivos em witness como um quórum de cluster:
```
Set-ClusterQuorum -FileShareWitness \\witness\QWitness
```

Verifique se o cluster foi criado com sucesso:

Test-Cluster

Talvez sejam exibidos alguns avisos que podem ser ignorados 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 é possível executar o snap-in de MMC do failover para analisar a integridade do cluster executando cluadmin.msc.

Se você estiver usando o AD gerenciado, adicione a conta de computador usada pelo WSFC ao grupo de Contas mescladas de domínio do Cloud Service para que ela possa juntar computadores ao domínio:
```
Install-WindowsFeature RSAT-ADDS
Add-ADGroupMember `
  -Identity "Cloud Service Domain Join Accounts" `
  -Members windows-fci$
```

Como ativar o Storage Spaces Direct

Agora, ative o S2D e crie um volume compartilhado de cluster que combine os três discos permanentes criados anteriormente:

Volte para a sessão do PowerShell em node-1.
Ative o S2D:
```
Enable-ClusterStorageSpacesDirect
```
Opcionalmente, se você quiser melhorar o desempenho do disco, adicione SSDs locais de SCSI aos nós S2D, além dos discos permanentes SSD padrão. Os SSDs locais podem funcionar como camada de cache do S2D. Escolha como número de drives de capacidade (discos permanentes SSD, neste caso) um múltiplo do número de SSDs locais. Execute o seguinte comando em vez de ativar o S2D com armazenamento em cache:
```
Enable-ClusterStorageSpacesDirect -CacheDeviceModel "EphemeralDisk"
```
Aceite o padrão quando solicitado a confirmar. Talvez você veja alguns avisos que podem ser ignorados com segurança:
```
WARNING: 2021/04/08-13:12:26.159 Node node-1: No disks found to be used for cache
WARNING: 2021/04/08-13:12:26.159 Node node-2: No disks found to be used for cache
```
Opcionalmente, defina o cache na memória de volume de cluster compartilhado (CSV) como 2048 MB para melhorar a capacidade de leitura:
```
(Get-Cluster).BlockCacheSize = 2048
```

Crie um novo volume que use as versões de volume compartilhada do cluster do ReFS e um tamanho de cluster de 64 KB:

New-Volume `
  -StoragePoolFriendlyName S2D* `
  -FriendlyName FciVolume `
  -FileSystem CSVFS_ReFS `
  -UseMaximumSize `
  -AllocationUnitSize 65536

Como testar o failover do pool de armazenamento

Como alternativa, é possível testar se o failover do pool de armazenamento funciona corretamente:

Conecte-se a node-2 usando a Área de trabalho remota. Faça login com a conta de usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e selecione Executar
Digite cluadmin.msc e selecione OK.
No painel da janela à esquerda, acesse Failover Cluster Manager > windows-fci > Storage > Pools.

Você verá um pool chamado Cluster Pool 1 com o nó do proprietário definido como node-1.
Volte ao Cloud Shell e redefina a VM node-1 para simular um failover:
```
gcloud compute instances reset node-1 --zone $REGION-a
```
Volte para o Failover Cluster Manager em node-2.
Observe o status do pool de armazenamento pressionando repetidamente F5 para atualizar a visualização.

Depois de cerca de 30 segundos, o nó do proprietário deve alternar automaticamente para node-2.

Remover a instalação padrão do SQL Server

Agora, remova a instalação padrão do SQL Server dos dois nós e a substitua por uma nova configuração de FCI.

Para cada um dos dois nós WSFC, node-1 e node-2, execute as seguintes etapas:

Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.

Remova a instância do SQL Server padrão:

C:\sql_server_install\Setup.exe /Action=Uninstall /FEATURES=SQL,AS,IS,RS /INSTANCENAME=MSSQLSERVER /Q

Remova o driver OLE da Microsoft:

Get-Package -Name "Microsoft OLE*" | Uninstall-Package -Force

Remova o driver ODBC da Microsoft:

Get-Package -Name "Microsoft ODBC*" | Uninstall-Package -Force

Reinicie o computador:
```
Restart-Computer
```
Aguarde aproximadamente um minuto para que a reinicialização seja concluída.

Instalar a FCI do SQL Server

Antes de instalar a nova configuração da FCI, verifique se o node-1 é o nó ativo no cluster:

Reconecte-se ao node-1 usando a área de trabalho remota e faça login usando o usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e selecione Executar
Digite cluadmin.msc e selecione OK.
No painel da janela à esquerda, acesse Failover Cluster Manager > windows-fci.

Verifique se o servidor host atual está definido como node-1.

Se o servidor do host atual estiver definido como node-2, clique com o botão direito do mouse em windows-fci no painel da janela à esquerda e selecione More actions > Move core cluster resources > Select node… > node-1 e clique em OK.
No painel da janela à esquerda, acesse Failover Cluster Manager > windows-fci > Storage > Pools.

Verifique se o nó do proprietário do Pool de clusters 1 está definido como node-1.

Se o nó do proprietário estiver definido como node-2, clique com o botão direito do mouse no pool, selecione Move > Select Node > node-1 e clique em OK.

Agora, crie uma nova instalação do cluster de failover do SQL Server em node-1:

Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.

Crie uma conta de usuário de domínio para o servidor SQL e o agente SQL e atribua uma senha:

Active Directory

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

Microsoft AD gerenciado

$Credential = Get-Credential -UserName sql_server -Message 'Enter password'
New-ADUser `
  -Name "sql_server" `
  -Description "SQL Agent and SQL Admin account." `
  -AccountPassword $Credential.Password `
  -Enabled $true -PasswordNeverExpires $true `
  -Path "OU=Cloud,DOMAIN"

Substitua DOMAIN pelo nome distinto do seu domínio, por exemplo, DC=example,DC=org.

Inicie a configuração do SQL Server:
```
& c:\sql_server_install\setup.exe
```
No menu à esquerda, selecione Installation.
Selecione Nova instalação do cluster de failover do SQL Server.
Na página Microsoft Update, selecione Próxima para iniciar a instalação.
Na página Instalar regras de cluster de failover, você verá um aviso Avisos de verificação de cluster MSCS e Firewall do Windows. Ignore esses avisos e selecione Próxima.
Na página Product Key, mantenha os padrões e selecione Next.
Na página Termos de licença, analise os termos e, se você aceitar, selecione Próxima.
Na página Seleção de recurso, selecione Serviços do banco de dados e depois Próximo.
Na página Configuração da instância, digite sql como o nome da rede e a instância nomeada e selecione Próxima.
Na página Cluster Resource Group, mantenha os padrões e selecione Next.
Na página Seleção de disco do cluster, ative o Disco virtual do cluster (FciVolume) e desative todos os outros discos. Selecione Próxima.
Na página Cluster Network Configuration, defina as configurações a seguir e selecione Next:
- DHCP: claro
- Endereço IP: insira o endereço IP do balanceador de carga interno.
Na página Configuração do servidor, defina as configurações a seguir para o SQL Server Agent e o SQL Server Database Engine:
- Nome da conta: DOMAIN\sql_server em que DOMAIN é o nome do NetBIOS do seu domínio do Active Directory
- Senha: digite a senha que você criou anteriormente
Selecione a guia Agrupamento e selecione o agrupamento que você quer usar. Depois clique em Next.
Na página Configuração do mecanismo do banco de dados, selecione Adicionar usuário atual para designar o usuário atual como administrador do SQL Server. Depois, selecione Próxima.
Na página Pronto para instalar, revise as configurações e selecione Instalar.
Após a conclusão da instalação, selecione Fechar.

Seu domínio do Active Directory agora contém uma conta de computador sql que representa a instância do SQL Server e uma entrada DNS correspondente que aponta para o endereço IP do balanceador de carga interno.

Agora adicione node-2 ao cluster de failover do SQL Server:

Conecte-se ao node-2 usando a área de trabalho remota e faça login usando o usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.
Inicie a configuração do SQL Server:
```
& c:\sql_server_install\setup.exe
```
No menu à esquerda, selecione Installation.
Selecione Adicionar nó a um cluster de failover do SQL Server.
Siga as instruções do assistente de instalação e aceite as configurações padrão até chegar à página Contas de serviço.
Na página Contas de serviço, digite a senha que você criou anteriormente para o SQL Server Agent e o SQL Server Database Engine. Depois, selecione Próxima.
Na página Pronto para instalar, revise as configurações e selecione Instalar.
Após a conclusão da instalação, selecione Fechar.

Configurar verificações de integridade

A última etapa é configurar o cluster para expor um endpoint de verificação de integridade que possa ser usado por um balanceador de carga interno:

Volte para a sessão do PowerShell em node-2
Inicialize uma variável com o endereço IP do balanceador de carga.
```
$LoadBalancerIP = 'IP_ADDRESS'
```
Substitua IP_ADDRESS pelo endereço IP do wsfc que você reservou anteriormente.

Configure o cluster de failover para responder ao serviço de verificação de integridade:

$SqlGroup = Get-ClusterGroup |
  Where-Object {$_.Name.StartsWith("SQL Server")}
$SqlIpAddress = Get-ClusterResource |
  Where-Object {$_.Name.StartsWith("SQL IP Address")}

$SqlIpAddress | Set-ClusterParameter -Multiple @{
 'Address'=$LoadBalancerIP;
 'ProbePort'= 59997;
 'SubnetMask'='255.255.255.255';
 'Network'= (Get-ClusterNetwork).Name;
 'EnableDhcp'=0; }

Reinicie o recurso do cluster:

$SqlIpAddress | Stop-ClusterResource
$SqlIpAddress | Start-ClusterResource

Reinicie o grupo do cluster:

$SqlGroup | Stop-ClusterGroup
$SqlGroup | Start-ClusterGroup

Crie um balanceador de carga interno

Agora, para fornecer um único endpoint para clientes do SQL Server, implante um balanceador de carga interno que use uma verificação de integridade que garanta que o tráfego seja direcionado ao nó ativo da WSFC

Volte para a sessão atual do Cloud Shell.

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

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

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

Crie uma verificação de integridade que o balanceador de carga possa usar para determinar qual é o nó ativo.
```
gcloud compute health-checks create tcp wsfc-healthcheck \
  --check-interval="2s" \
  --healthy-threshold=1 \
  --unhealthy-threshold=2 \
  --port=59997 \
  --timeout="1s"
```
A verificação de integridade sonda a porta 59997, que é a porta configurada anteriormente como ProbePort para o recurso de endereço IP do SQL Server.

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

gcloud compute backend-services create wsfc-backend \
  --load-balancing-scheme internal \
  --region $(gcloud config get-value compute/region) \
  --health-checks wsfc-healthcheck \
  --protocol tcp

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

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

Criar o balanceador de carga interno:

gcloud compute forwarding-rules create wsfc-sql \
  --load-balancing-scheme internal \
  --address $LOADBALANCER_ADDRESS \
  --ports 1433 \
  --network $VPC_NAME \
  --subnet $SUBNET_NAME \
  --region $REGION \
  --backend-service wsfc-backend

Como testar o cluster de failover

Você concluiu a instalação do cluster de failover, mas ainda precisa testar se o cluster funciona corretamente.

Preparar um cliente

Crie uma nova instância de VM que possa ser usada para se conectar ao cluster de failover:

Volte para a sessão atual do Cloud Shell.

Crie uma nova instância de VM:

gcloud compute instances create sqlclient \
  --zone $REGION-a \
  --machine-type n2-standard-2 \
  --subnet $SUBNET_NAME \
  --image-family sql-ent-2019-win-2022 \
  --image-project windows-sql-cloud \
  --boot-disk-size 50 \
  --boot-disk-type pd-ssd

Monitore o processo de inicialização da VM visualizando a saída da porta serial:
```
gcloud compute instances tail-serial-port-output sqlclient
```
Aguarde alguns minutos até ver a saída Instance setup finished e pressione Ctrl+C. Nesse momento, a instância de VM está pronta para ser usada.
Crie um nome de usuário e uma senha para a instância de VM.
Conecte-se à VM usando a Área de trabalho remota e faça login usando o nome de usuário e a senha criados na etapa anterior.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell (administrador).
Confirme a elevação do prompt clicando em Sim.
Associe o computador ao seu domínio do Active Directory:
```
Add-Computer -Domain DOMAIN
```
Substitua DOMAIN pelo nome DNS do seu domínio do Active Directory.
Reinicie o computador:
```
Restart-Computer
```
Aguarde aproximadamente um minuto para que a reinicialização seja concluída.

Fazer o teste

Use a VM sqlclient para testar se é possível se conectar ao cluster de failover e verificar se o failover funciona corretamente:

Conecte-se ao sqlclient usando a área de trabalho remota e faça login usando o usuário do seu domínio.
Clique com o botão direito do mouse no botão Iniciar (ou pressione Win+X) e clique em Windows PowerShell.

Conecte-se ao cluster do SQL Server usando TCP/IP e o nome DNS sql e consulte a tabela dm_os_cluster_nodes:

& "$env:ProgramFiles\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\SQLCMD.EXE" `
   -S tcp:sql -E -Q "SELECT * FROM sys.dm_os_cluster_nodes"

O resultado vai ser semelhante a este:

NodeName                       status      status_description is_current_owner
------------------------------ ----------- ------------------ ----------------
NODE-1                                   0 up                                1
NODE-2                                   0 up                                0

(2 rows affected)

node-1 é o proprietário atual do recurso de cluster de failover do SQL Server.

Volte ao Cloud Shell e desative a VM node-1 para testar o cenário de failover.
```
gcloud compute instances stop node-1 --zone $REGION-a
```

Repita a consulta:

& "$env:ProgramFiles\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\SQLCMD.EXE" `
   -S tcp:sql -E -Q "SELECT * FROM sys.dm_os_cluster_nodes"

A resposta será semelhante a esta:

NodeName                       status      status_description is_current_owner
------------------------------ ----------- ------------------ ----------------
NODE-1                                   1 down                              0
NODE-2                                   0 up                                1

(2 rows affected)

Observe que, independentemente da perda do node-1, a consulta é bem-sucedida e mostra que o node-2 já é o proprietário atual do cluster de failover.

Limitações

O S2D só é compatível com o Windows Server 2016 e versões mais recentes.
Com o S2D, cada disco tem apenas uma visualização parcial dos dados gerais. Portanto, não basta tirar um snapshot de um disco permanente para fazer backup dos dados. Em vez disso, use o backup nativo do SQL.

Limpeza

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:

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

No Console do Google Cloud, acesse a página Gerenciar recursos.
Acessar "Gerenciar recursos"
Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

Saiba como configurar uma instância de cluster de failover do SQL Server que usa discos permanentes no modo de vários gravadores.