WSFC + SQL AlwaysOn no AZURE sem Active Directory [#3]

Fala pessoal!

Na etapa anterior, vimos como criar nossas máquinas virtuais, atrelar um IP estático a elas e habilitar a Feature de Cluster.

Nesta última parte da série, vamos criar nosso WSFC e habilitar o SQL Server AlwaysOn Availability Groups.

Para quem não leu a primeira e segunda parte, segue os links:
https://dev.to/wiluey/wsfc-sql-alwayson-no-azure-sem-active-directory-1-405g

https://dev.to/wiluey/criando-um-wsfc-sem-ad-sql-alwayson-no-azure-parte-1-1bhl

Mas antes preciso esclarecer que isso só é possível ser feito no Windows Server 2016 em diante, pois a partir dele é possível criar um Failover Cluster (de 2 ou mais nós) em Domínios diferentes ou em servidores Workgroup (que não fazem parte de um AD).
Este é chamado de Workgroup Cluster e será o tipo de cluster que criaremos.

Então vamos lá!

Primeiramente acesse cada uma das máquinas virtuais, acesse o Powershell como administrador e execute o script abaixo:
New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Esse script é para habilitar na chave de registro do Windows a opção de acesso remoto aos compartilhamentos administrativos, uma vez que por segurança o acesso só pode ser feito por contas de domínio.
E o script desabilita o filtro de tokens das contas locais desbloqueia o acesso remoto a essas contas.

Após isso, reinicie ambas as máquinas virtuais.

A partir daqui vamos falar de alguns conceitos de Infraestrutura para melhorar o entendimento.

O primeiro passo é configurarmos o Sufixo DNS Primário, pois ele nos permitirá configurar os nós para comunicarem-se via FQDN.

O FQDN (Fully Qualified Domain Name) é a abreviatura que significa o nome de domínio completo e ser composto por domínio e/ou diversos subdomínios.

Como o Listener do SQL AlwaysOn usa resolução de DNS, é necessário configurarmos o FQDN, pois por características do produto, o SQL Server não faz Proxy Reverso, por isso é uma má prática apontamos para o IP do Listener ao invés do DNS.

Agora acesse as máquinas virtuais e configure o Sufixo DNS Primário seguindo os passos abaixo:

• Acesse System properties do Windows
  

• Na tela abaixo, clique em "More"
  

• Em DNS Suffix and NetBIOS Computer Name digite o nome de Domínio DNS (de sua escolha)
  

Finalizado os passos acima, clique em OK até ser solicitado o boot do servidor, reinicie as máquinas.

Após logar nas máquinas, verá que agora ela possui um nome completo:

Agora vem o "pulo do gato", nós vamos "enganar" e fazê-lo acreditar que as entradas no DNS estão criadas.

A diferença aqui é que se eu não usar um AD, ainda precisarei do DNS Domain para registrar as entradas do meu FQDN.

Acesso o arquivo HOSTS do servidor, geralmente fica em "c:\windows\system32\drivers\etc".

Insira no Arquivo Hosts todos os servidores que farão parte do Cluster, faça isso em TODOS os servidores.

A partir de agora, as máquinas conseguirão fazer um ping entre si resolvendo o FQDN.

Agora estamos prontos para colocar o Windows em Cluster, ou seja, finalmente criar o WSFC.

Execute Windows+R e digite Cluadmin.msc para abrir o Failover Cluster Manager.

Clique com o botão direito do mouse em "Create Cluster" e siga o passo a passo abaixo:

• Nesta tela clique em "next"
  

• Nesta tela digite um nome de servidor de cada vez e clique em "Add", o nome deve ser o FQDN, depois clique em "next".
  

• Nesta tela clique em "Yes" para rodar o Cluster Validate, e depois em "next".
  

• Nesta tela, selecione a opção Run only tests I select e clique em "next".
  

• Como não estamos com Storage compartilhada, desmarque a opção de validação dos discos e clique em "next".
  

Após isso clique novamente em "Next" e espere o processo de validação que levará alguns minutos.

O processo vai reclamar que não encontrou o Active Directory (ah vá! haha), ignore!
ele também vai gerar alguns Warnings, ignore também!
Finalizando a validação, clique em "finish".

• Nesta tela você dá um nome ao seu WSFC

Após isso, só clicar em "next" até iniciar o processo de criação do WSFC.

• Ao final vai gerar esta tela com alguns Warnings, só clicar em "finish".

Ao final do processo você verá que o serviço do Cluster não ficou online e mesmo executando um "Bring Online" ele não sobe de maneira alguma.

Calma rs! Aqui vem um outro pulo do gato!

Isso ocorre porque houve um conflito de IPs, como na criação o processo de deploy não nos permite inserir o IP Vip manualmente, ele pega os IPs disponíveis nas interfaces e como eu propositadamente não inseri mais de uma interface, ele tentou pegar um IP que estava em uso.

Para resolver é simples, clique com o botão direito em cima do recurso do cluster e vá em "Properties".

Na tela abaixo, clique em cima de um dos IPs e depois em "Edit".

Altere a opção do endereço de IP para Use Static, insira um novo IP (dentro do seu bloco CIDR) e clique em OK.

Repita o processo para a outra interface.

Clique em "apply", depois em "OK".

Pronto, recurso no ar novamente!

"Mas Will, ainda tem um recurso offline, ainda tá dando erro!"

Calma Padawan, isso é completamente normal, lembre-se que cada uma das máquinas virtuais estão em uma VNET diferente, portanto estamos usando o conceito de Multi-subnet Failover, na qual garantimos a alta disponibilidade a nível de rede também.
Ou seja, somente em caso de Failover/Chaveamento a outra interface ficará online. Então fica tranquilo! =)

Agora sim, nosso WSFC está no ar e operante!

Agora chegou o momento de configurarmos o SQL Server AlwaysOn Availability Group.

Digite Windows+R e depois digite SQLServerManager14.msc.

No serviço do SQL Server, clique na opção abaixo, depois em OK e reinicie o serviço do SQL.

Faça isso em ambos os servidores!

Agora localize o Microsoft SQL Server Management Studio 18.

Abra-o e logue com a sua conta.

PONTO DE ATENÇÃO!!!
A partir daqui, tudo o que você fizer, certifique-se que está usando o mesmo usuário na qual criou o WSFC.

Antes disso:
Como tudo é autenticação no Active Directory, precisamos garantir que as contas de serviço gerem tokens confiáveis e que consigam registrar as ações no SQL Server.

Para que isso aconteça, vamos precisar criar uma Chave Simétrica e um Certificado.

A chave simétrica tem como objetivo proteger as chaves privadas dos certificados, garantindo a segurança, já que é criptografada com o algoritmo AES_256.

Já o certificado é um objeto de segurança assinado digitalmente que contém uma chave pública (e, opcionalmente, uma privada) e é protegido pela chave simétrica.

Agora vamos iniciar nosso passo a passo:

• Logue no servidor primário, abra o Management Studio e execute o script abaixo para criar a Chave Simétrica.
  USE master
  GO
  CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Wiluey@123'; GO

Lembre-se de adaptar o script para a sua realidade!

• Em seguida execute o comando abaixo para criar o Certificado.
  USE master
  GO
  CREATE CERTIFICATE Cluster_VM_BR_cert
  WITH SUBJECT = 'Cluster-VM-BR certificate for Availability Group';
  GO

• Em seguida, execute o comando para criar o Endpoint.
  USE master
  GO
  CREATE ENDPOINT Endpoint_AvailabilityGroup
  STATE = STARTED
  AS TCP
  (
  LISTENER_PORT = 5022, LISTENER_IP = ALL
  )
  FOR DATABASE_MIRRORING
  (
  AUTHENTICATION = CERTIFICATE Cluster_VM_BR_cert,
  ENCRYPTION = REQUIRED ALGORITHM AES,
  ROLE = ALL
  );
  GO

Agora vamos fazer o BACKUP do Certificado, pois precisaremos copiá-lo para os outros NODES que compõem o Cluster.

• Execute o comando abaixo.
  USE master
  GO
  BACKUP CERTIFICATE Cluster_VM_BR_cert TO FILE = 'F:\data\Cluster_VM_BR_cert.cer';
  GO

Copie o Certificado gerado na execução do script acima para o Servidor Secundário!

Repita o Procedimento acima nos outros Nodes do Cluster, gerando as respetivas chaves simétricas, os certificados, gerando os backups e copiando os arquivos para todos os outros nodes.

Feito isso, vamos ao passo abaixo!

• Retorne ao servidor primário, lá vamos criar um Login/User com perfil administrador e posteriormente associá-lo na criação do Availability Group:
  USE master
  GO
  CREATE LOGIN [SQL-AG] WITH PASSWORD = 'Wiluey@123';
  GO

USE master
GO
CREATE USER [SQL-AG] FOR LOGIN [SQL-AG];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SQL-AG];
GO

• Neste passo vamos associar a conta [SQL-AG] ao Certificado para que ela possa autenticar nos outros Nodes.
  USE master
  GO
  CREATE CERTIFICATE Cluster_VM_EUA_cert
  AUTHORIZATION [SQL-AG] FROM FILE = 'F:\data\Cluster_VM_EUA_cert.cer';
  GO

• Neste passo autorizamos a conta [SQL-AG] a conectar no Endpoint.
  USE master
  GO
  GRANT CONNECT ON ENDPOINT::Endpoint_AvailabilityGroup TO [SQL-AG];
  GO

Repita o Procedimento acima nos outros Nodes do Cluster, criando o Login/User e autorizando a conexão via Certificado.
Atentar-se para o certificado utilizado e justar o script.

Agora vamos criar o Availability Group!

Antes disso, acesso o SQL Server no seu servidor primário e crie um banco de dados de teste, altere o Recovery Model para FULL e faça um Backup Full deste banco de dados recém criado.

• Agora sim, acesse seu servidor primário e execute o procedimento abaixo (lembre-se de fazer isso com logado com o usuário SQL-AG):
  USE [master]
  GO
  CREATE AVAILABILITY GROUP [Wiluey_AG]
  WITH
  (
  AUTOMATED_BACKUP_PREFERENCE = PRIMARY,
  DB_FAILOVER = ON,
  DTC_SUPPORT = NONE
  )
  FOR DATABASE [TESTE_WILUEY]
  REPLICA ON
  N'Cluster-VM-BR' WITH
  (
  ENDPOINT_URL = N'TCP://Cluster-VM-BR.ALWAYSON.COM:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  SECONDARY_ROLE
  (
  ALLOW_CONNECTIONS = NO
  )
  ),
  N'Cluster-VM-EUA' WITH
  (
  ENDPOINT_URL = N'TCP://Cluster-VM-EUA.ALWAYSON.COM:5022',
  FAILOVER_MODE = AUTOMATIC,
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
  SECONDARY_ROLE
  (
  ALLOW_CONNECTIONS = NO)
  );
  GO

• Availability Group criado, agora vamos criar o LISTENER.
  USE [master]
  GO
  ALTER AVAILABILITY GROUP [Wiluey_AG]
  ADD LISTENER N'LS_Wiluey_AG' (
  WITH IP
  ((N'10.0.0.25', N'255.255.255.0'),
  (N'10.1.0.25', N'255.255.255.0')
  )
  , PORT=1433);
  GO

Lembrando que aqui é um IP "barra 24", já que está atrelado à Subnet da interface de rede do servidor.

Feito isso, vamos validar a conexão no SQL AlwaysOn via LISTENER

TUDO CERTO!

Agora vamos validar o Failover!

TUDO CERTO NOVAMENTE!

E com isso fechamos nossa série, nela aprendemos a criar um SQL Server AlwaysOn AG utilizando a feature Workgroup Cluster do Windows Server 2016.
Aprendemos a criar máquinas virtuais no Azure, a configurar uma interface de rede, criando VNETs e Subnets.
Também foi aprendido como se faz um Vnet Peering entre VMs em zonas de disponibilidade ou regiões distintas.

Agora um ponto de atenção super importante:
Este foi apenas um laboratório que servirá de estudos e aprendizado aos leitores.
E por ser um laboratório, diversas regras de segurança foram deixadas de lado, portanto se um dia houver a necessidade de criar uma arquitetura desta em ambiente produtivo, conte com um arquiteto experiente que conheça bem a segurança do Azure e as boas práticas para manter os dados da sua empresa seguros, não arrisque as práticas deste tutorial!

E é isso pessoal, espero que tenham gostado!

No próximo post, vamos aprender a configurar um verdadeiro Active Directory Domain Services (ADDS) como serviço e vamos inserir estas máquinas em um dominio e atrelá-las à um DNS Domain original, vamos fazer o inverso. =)

Acompanhem o blog para ficar por dentro do mundo Azure!

Grande abraço e até a próxima!