DEV Community

Wiluey Sousa
Wiluey Sousa

Posted on

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

Fala pessoal!

Na nova série que se inicia, vamos aprender a criar um Windows Server Failover Cluster sem o uso do Active Directory (AD) no Azure.

Depois vamos criar um SQL AlwaysOn Availability Group em cima dessas máquinas usando a feature do WSFC recém criada.

A principio, o processo é bem simples, porém requer conhecimento em Azure, portanto para o post ser produtivo, vamos aprender do zero.

Então a série completa abordará:

  • Como criar as VNets e Subnets
  • Fazer o Peering entre as redes
  • Como criar as máquinas virtuais (VMs) no Azure
  • Atrelar as VNets e Setar IPs estáticos nas VMs
  • Criar o WSFC entre as VMs
  • Criar o AlwaysOn AG
  • Testar e validar

Lembrando que por ser um post que pretende ensinar de maneira clara e objetiva todos os níveis, vou tentar deixá-lo o mais "entendível" possível, portanto evitarei ao máximo o uso de scripts CLI ou Powershell e entrarei no detalhe de alguns conceitos.

Existem outros meios de fazer todo o processo por meio do Azure DevOps ou utilizando ferramentas de Infra as a Code (IaC) como o Terraform e o Packer, mas isso ficará para uma próxima série mais High Level.

Bom, chega de introdução, vamos la!

No post de hoje vamos aprender primeiramente a criar duas Azure Virtual Networks (VNets)e suas respectivas Subnets, como a ideia é termos alta disponibilidade, então cada uma será criada em uma Availability Zone diferente.

Mas antes: O que é uma VNET?

É o bloco fundamental de sua rede privada no Azure. Ela permite que vários tipos de recursos do Azure possam se comunicar de forma segura com a Internet, com as redes locais e com outras redes pareadas. Ela seria a sua rede principal e fazendo um comparativo com um Datacenter on-premises, seria a responsável pela conectividade entre seus servidores e seus switchs, porém aqui por ser parte de uma arquitetura própria, entrega escalabilidade, disponibilidade e isolamento.

Basicamente a sua VNet é composta pelos itens abaixo:

  • Address space: Como o nome diz, é seu espaço de endereço, ele hospedará sua subnet (sub-rede), onde você conectará outros recursos do Azure.
  • Subnets: Um segmento da rede virtual que consiste em uma ou mais sub-redes, você aloca uma parte do espaço de endereço da rede virtual (VNet) a cada uma delas. Por padrão, um IP em uma subnet pode se comunicar com qualquer outro IP dentro da VNet. Também pode ser feito uma rota de tráfego (route traffic) entre subnets e até mesmo para fora da VNet.
  • Regions: Cada VNet pode ser atrelada à apenas uma unica região ou localização. Caso queira conectar um ou mais subnets de regiões distintas, é necessário criar um VNet Peering.
  • Subscription: VNets estão no escopo de uma Subscription, ou seja, é um dos vários recursos que ficam atrelados diretamente à uma assinatura.

Pelo menos a rede no Azure é mais sobre roteamento IP. Um Datacenter tradicional geralmente usa Comutação de VLAN ou Camada 2 e menos roteamento, o que deixa a administração mais complexa.

Bom, esse é apenas um resumo básico de redes, em breve vou lançar um artigo APENAS sobre Arquitetura de Redes, ai vamos entrar no detalhe de muitas outras coisas que não cabem aqui nesta série.

Agora vamos à prática! :)

Primeiramente vamos logar no Azure: www.portal.azure.com

Acessando com a sua conta, vamos criar o grupo de recursos dentro da nossa Subscription.

Caso seja sua primeira experiência com Azure, abra o CloudShell clicando onde a seta da imagem abaixo aponta.

Alt Text

No primeiro acesso, ele pede a criação de uma simples Storage Account para a configuração do CloudShell, basta clicar em "yes" e tudo certo, não é necessário fazer mais nada.

Com o CloudShell ativo, execute o comando: az account list --output table

Caso você tenha mais de uma Subscription, ela será listada para você (conforme imagem abaixo).

Alt Text

Após decidir qual a subscription utilizar, execute o comando abaixo:
az account set --subscription "Sua SubscriptionID AQUI"

"Setando" a assinatura, agora chegou a vez de criar seu grupo de recursos (resource group).
Execute o comando abaixo:
az group create -l eastus -n Cluster_VM_Azure_EUA

Lembrando que essa primeira VNet ficará no EUA, portanto o parâmetro "-l" do script está criando o grupo de recursos e tudo o que vier a seguir na localidade East US.

A saída deverá ser idêntica a da imagem abaixo:
Alt Text

Feito isso, agora vamos para a criação da Azure Virtual Networks (VNet) e conforme prometido, usando pouca scriptação para facilitar o entendimento.

Volte o portal do Azure e acesse Resource Group que você acabou de criar.

Clique em "Add", conforme imagem abaixo:
Alt Text

No marketplace, procure por Virtual Network, conforme imagem abaixo:
Alt Text

Na próxima tela vamos dar um nome à nossa VNet, atrelar ao Resource Group (RG) recém criado e garantir que a Localização seja a mesma em que se encontra nosso RG, no caso, East US (vide imagem).
Alt Text

Agora vamos atribuir nosso espaço de endereço à nossa VNet, no caso do LAB, estipulei uma rede "/16" (barra 16) para a VNET e um "/24" para a subnet.
Alt Text

Ponto de Atenção: Aqui estou criando apenas os espaços de endereço (Address Space) da minha VNet, não estou definindo os IPs que minhas futuras máquinas virtuais utilizarão.
Outro ponto importante, os 3 primeiros e os 3 últimos IPs são reservados para o roteamento e a resolução de nomes do Azure, então meu range deverá obrigatoriamente começar em "10.0.0.4".

Voltando ao Azure, na próxima aba Security, deixe tudo com status DISABLE.

Agora clique em REVIEW + CREATE e depois clique em CREATE.
A partir daqui ocorrerá o deploy da sua VNet.

Agora vamos criar a outra Vnet, que será atrelada à segunda máquina virtual.
Para o artigo não ficar extenso, volte para o inicio e repita todos os passos até aqui, trocando apenas os parâmetros abaixo:

  • Resource Group: Cluster_VM_Azure_BR
  • Localização: Brazil South

Ou seja, volte ao Cloud Shell e execute o comando abaixo:
az group create -l brazilsouth -n Cluster_VM_Azure_BR

E nos passos seguintes, basta atrelar a nova VNet ao RG Cluster_VM_Azure_BR.

A partir daqui entendo que ambos os Resource Groups estão criados, as VNETs e Subnets atreladas corretamente.

Então ao final, sua rede ficou assim:

  • Cluster_VM_Azure_EUA
    VNET: 10.0.0.0/16
    SUBNET: 10.0.0.0/24

  • Cluster_VM_Azure_BR
    VNET: 10.1.0.0/16
    SUBNET: 10.1.0.0/24

Agora vamos ao passo mais importante: a criação do VNet Peering para garantir que ambas as Subnets enxerguem-se.

Acessando o Resource Group Cluster_VM_Azure_EUA, clique no recurso já criado vnet_vm_eua.

Navegue no menu à esquerda e clique em "Peerings" (imagem), depois clique em + add.
Alt Text

Abrirá a tela abaixo:
Alt Text

Atenção: As setas vermelhas são os nomes do "Peering" e a seta verde é a VNET que fará o pareamento com a nossa rede atual.
Obviamente se eu comecei configurando a VNET EUA, então nesse menu eu escolho a VNET BR.

Logo abaixo, tem as opções de permissão de tráfego:
Alt Text

Atenção:

  • Quadrado Vermelho: Estas opções habilitadas permitirão o tráfego entre as VNets.
  • Quadrado Verde: Permite o tráfego encaminhado de uma VNet para outra, quando temos uma VPN ou uma Vnet-to-Vnet configurada.
  • Quadrado Azul: Permite que se use uma VPN gateway pareada no estilo "cross-premises" ou uma VNet-to-VNet.

Depois que clicar em CREATE, o processo de deploy se iniciará.

Aqui validamos se o Peering está conectado:
Alt Text

Estando tudo OK, então fechamos as configurações iniciais de REDES.

No próximo post desta série, vamos criar as nossas máquinas virtuais, atribuir nossas VNets à elas, criar os IPs estáticos e habilitar o WSFC.

Até o próximo post!

Abraços.

Top comments (0)