Usar o PowerShell ou a CLI do Azure para configurar um grupo de disponibilidade para SQL Server na VM do Azure

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Dica

Há vários métodos de implantação de um grupo de disponibilidade. Simplifique sua implantação sem precisar usar o Azure Load Balancer ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas VMs (máquinas virtuais) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já tiver criado seu grupo de disponibilidade em uma única sub-rede, poderá migrá-lo para um ambiente de várias sub-redes.

Este artigo descreve como usar o PowerShell ou a CLI do Azure para implantar um cluster de failover do Windows, adicionar VMs do SQL Server ao cluster e criar o balanceador de carga interno e o ouvinte de um grupo de disponibilidade Always On em uma só sub-rede.

A implantação do grupo de disponibilidade ainda é feita manualmente por meio do SSMS (SQL Server Management Studio) ou do T-SQL (Transact-SQL).

Embora este artigo use o PowerShell e a CLI do Azure para configurar o ambiente do grupo de disponibilidade, também é possível fazer isso no portal do Azure usando os modelos de Início Rápido do Azure ou manualmente.

Observação

Agora é possível migrar por lift-and-shift sua solução de grupo de disponibilidade para o SQL Server em VMs do Azure usando as Migrações para Azure. Confira Migrar grupo de disponibilidade para saber mais.

Pré-requisitos

Para configurar um grupo de disponibilidade Always On, você deve ter os seguintes pré-requisitos:

  • Uma assinatura do Azure.
  • Um grupo de recursos com um controlador de domínio.
  • Uma ou mais VMs conectadas ao domínio no Azure executando o SQL Server 2016 Edição Enterprise (ou superior) no mesmo conjunto de disponibilidade ou em diferentes zonas de disponibilidade que tenham sido registradas com a extensão do Agente IaaS do SQL.
  • A versão mais recente do PowerShell ou da CLI do Azure.
  • Dois endereços IP disponíveis (não utilizados por nenhuma entidade). Um é para o balanceador de carga interno. O outro é para o ouvinte do grupo de disponibilidade na mesma sub-rede que o grupo de disponibilidade. Se você está usando um balanceador de carga existente, vai precisar de apenas um endereço IP disponível para o ouvinte do grupo de disponibilidade.
  • O Windows Server Core não é um sistema operacional com suporte para os comandos do PowerShell referenciados neste artigo, pois há uma dependência do RSAT, que não está incluída nas instalações principais do Windows.

Permissões

Você precisa das seguintes permissões de conta para configurar o grupo de disponibilidade Always On usando a CLI do Azure:

  • Uma conta de usuário de domínio existente com permissão para Criar Objeto de Computador no domínio. Por exemplo, uma conta de administrador do domínio normalmente tem permissão suficiente (por exemplo: account@domain.com). Essa conta também deve fazer parte do grupo administrador local em cada VM para criar o cluster.
  • A conta de usuário do domínio que controla o SQL Server.

Criar uma conta de armazenamento

O cluster precisa de uma conta de armazenamento do Azure para atuar como a testemunha da nuvem. Você pode usar qualquer conta de armazenamento existente ou criar uma. Se você deseja usar uma conta de armazenamento existente, pule para a próxima seção.

O seguinte snippet de código cria a conta de armazenamento:

# Create the storage account
# example: az storage account create -n 'cloudwitness' -g SQLVM-RG -l 'West US' `
#  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

az storage account create -n <name> -g <resource group name> -l <region> `
  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

Dica

Você poderá ver o erro az sql: 'vm' is not in the 'az sql' command group se estiver usando uma versão desatualizada da CLI do Azure. Baixe a versão mais recente da CLI do Azure para superar esse erro.

Definir metadados do cluster

O grupo de comandos da CLI do Azure az sql vm group gerencia os metadados do serviço WSFC (Windows Server Failover Cluster) que hospeda o grupo de disponibilidade. Os metadados do cluster incluem o domínio do Active Directory, as contas de cluster, as contas de armazenamento a serem usadas como testemunha de nuvem e a versão do SQL Server. Use az sql vm group create para definir os metadados do WSFC para que, quando a primeira VM do SQL Server for adicionada, o cluster seja criado conforme definido.

O snippet de código a seguir define os metadados para o cluster:

# Define the cluster metadata
# example: az sql vm group create -n Cluster -l 'West US' -g SQLVM-RG `
#  --image-offer SQL2017-WS2016 --image-sku Enterprise --domain-fqdn domain.com `
#  --operator-acc vmadmin@domain.com --bootstrap-acc vmadmin@domain.com --service-acc sqlservice@domain.com `
#  --sa-key '4Z4/i1Dn8/bpbseyWX' `
#  --storage-account 'https://cloudwitness.blob.core.windows.net/'

az sql vm group create -n <cluster name> -l <region ex:eastus> -g <resource group name> `
  --image-offer <SQL2016-WS2016 or SQL2017-WS2016> --image-sku Enterprise --domain-fqdn <FQDN ex: domain.com> `
  --operator-acc <domain account ex: testop@domain.com> --bootstrap-acc <domain account ex:bootacc@domain.com> `
  --service-acc <service account ex: testservice@domain.com> `
  --sa-key '<PublicKey>' `
  --storage-account '<ex:https://cloudwitness.blob.core.windows.net/>'

Adicionar VMs ao cluster

A adição da primeira VM do SQL Server ao cluster cria o cluster. O comando az sql vm add-to-group cria o cluster com o nome dado anteriormente, instala a função de cluster nas VMs do SQL Server e as adiciona ao cluster. Os usos subsequentes do comando az sql vm add-to-group adicionam mais VMs do SQL Server ao cluster recém-criado.

O seguinte snippet de código cria o cluster e adiciona a primeira VM do SQL Server a ele:

# Add SQL Server VMs to cluster
# example: az sql vm add-to-group -n SQLVM1 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!
# example: az sql vm add-to-group -n SQLVM2 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM1 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>
az sql vm add-to-group -n <VM2 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>

Use este comando para adicionar outras VMs do SQL Server ao cluster. Modifique apenas o parâmetro -n para o nome da VM do SQL Server.

Configurar o quorum

Embora a testemunha de disco seja a opção de quorum mais resiliente, ela requer um disco compartilhado do Azure que impõe algumas limitações ao grupo de disponibilidade. Assim, a testemunha de nuvem é a solução de quorum recomendada para clusters que hospedam grupos de disponibilidade do SQL Server nas VMs do Azure.

Se você tiver um número par de votos no cluster, configure a solução de quorum que melhor atenda às suas necessidades de negócios. Para obter mais informações, confira Quorum com VMs do SQL Server.

Validar cluster

Para o cluster de failover ter suporte da Microsoft, ele deve passar pela validação de cluster. Conecte-se à VM usando o seu método preferido, como o RDP (Protocolo de Área de Trabalho Remota), e valide o cluster antes de continuar. A falha na validação deixa o cluster com o status sem suporte.

Você pode validar o cluster usando o FCM (Gerenciador de Cluster de Failover) ou o seguinte comando do PowerShell:

Test-Cluster –Node ("<node1>","<node2>") –Include "Inventory", "Network", "System Configuration"

Criar grupo de disponibilidade

Crie manualmente o grupo de disponibilidade, como de costume, usando o SQL Server Management Studio, o PowerShell ou o Transact-SQL.

Importante

Não crie um ouvinte no momento, porque isso é feito por meio da CLI do Azure nas seções a seguir.

Criar balanceador de carga interno

Observação

As implantações do grupo de disponibilidade em várias sub-redes não exigem um balanceador de carga. Em um ambiente de sub-rede única, os clientes que usam o SQL Server 2019 CU8 e posterior no Windows 2016 e posterior podem substituir o ouvinte de VNN (nome da rede virtual) tradicional e o Azure Load Balancer por um ouvinte de DNN (nome da rede distribuída). Se você quiser usar um DNN, ignore todas as etapas do tutorial que configuram o Azure Load Balancer para o grupo de disponibilidade.

O ouvinte do grupo de disponibilidade AlwaysOn requer uma instância interna do Azure Load Balancer. O balanceador de carga interno fornece um endereço IP "flutuante" para o ouvinte do grupo de disponibilidade que permite um failover e uma reconexão mais rápidos. Se as VMs do SQL Server em um grupo de disponibilidade fizerem parte do mesmo conjunto de disponibilidade, você poderá usar um balanceador de carga básico. Caso contrário, precisará usar um balanceador de carga padrão.

Observação

O balanceador de carga interno deve estar na mesma rede virtual que as instâncias de VM do SQL Server.

O seguinte snippet de código cria o balanceador de carga interno:

# Create the internal load balancer
# example: az network lb create --name sqlILB -g SQLVM-RG --sku Standard `
# --vnet-name SQLVMvNet --subnet default

az network lb create --name sqlILB -g <resource group name> --sku Standard `
  --vnet-name <VNet Name> --subnet <subnet name>

Importante

O recurso de IP público de cada VM do SQL Server deve ter uma SKU padrão para ser compatível com o balanceador de carga padrão. Para determinar a SKU do recurso de IP público da sua VM, acesse Grupo de Recursos, selecione o recurso Endereço IP Público para a VM do SQL Server desejada e localize o valor em SKU no painel Visão geral.

Criar ouvinte

Depois de criar manualmente o grupo de disponibilidade, você pode criar o ouvinte usando az sql vm ag-listener.

A ID do recurso de sub-rede é o valor de /subnets/<subnetname> anexado à ID do recurso da rede virtual. Para identificar a ID do recurso de sub-rede:

  1. Vá para o seu grupo de recursos no portal do Azure.
  2. Selecione o recurso de rede virtual.
  3. Selecione Propriedades no painel Configurações.
  4. Identifique a ID do recurso para a rede virtual e anexe /subnets/<subnetname> ao final dela para criar a ID do recurso de sub-rede. Por exemplo:
    • A ID do recurso de rede virtual é: /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet
    • O nome da sua sub-rede é: default
    • Portanto, a ID do recurso de sub-rede é: /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default

O seguinte snippet de código cria o ouvinte do grupo de disponibilidade:

# Create the availability group listener
# example: az sql vm group ag-listener create -n AGListener -g SQLVM-RG `
#  --ag-name SQLAG --group-name Cluster --ip-address 10.0.0.27 `
#  --load-balancer sqlilb --probe-port 59999  `
#  --subnet /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default `
#  --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener create -n <listener name> -g <resource group name> `
  --ag-name <availability group name> --group-name <cluster name> --ip-address <ag listener IP address> `
  --load-balancer <lbname> --probe-port <Load Balancer probe port, default 59999>  `
  --subnet <subnet resource id> `
  --sqlvms <names of SQL VM's hosting AG replicas, ex: sqlvm1 sqlvm2>

Alterar o número de réplicas

Há uma camada adicional de complexidade ao implantar um grupo de disponibilidade nas VMs do SQL Server hospedadas no Azure. O provedor de recursos e o grupo de máquinas virtuais agora gerenciam os recursos. Assim, ao adicionar ou remover réplicas no grupo de disponibilidade, há uma etapa adicional de atualização dos metadados do ouvinte com informações sobre as VMs do SQL Server. Ao modificar o número de réplicas no grupo de disponibilidade, você também deve usar o comando az sql vm group ag-listener update para atualizar o ouvinte com os metadados das VMs do SQL Server.

Adicionar uma réplica

Para adicionar uma nova réplica ao grupo de disponibilidade:

  1. Adicione a VM do SQL Server ao grupo de clusters:

    
# Add the SQL Server VM to the cluster group
# example: az sql vm add-to-group -n SQLVM3 -g SQLVM-RG --sqlvm-group Cluster `
# -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM3 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
-b <bootstrap account password> -p <operator account password> -s <service account password>

  2. Use o SQL Server Management Studio para adicionar a instância do SQL Server como uma réplica no grupo de disponibilidade.

  3. Adicione os metadados da VM do SQL Server ao ouvinte:

    # Update the listener metadata with the new VM
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2 sqlvm3

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs, along with new SQL VM>

Remover uma réplica

Para remover uma réplica especificada do grupo de disponibilidade:

  1. Remova a réplica do grupo de disponibilidade usando o SQL Server Management Studio.
  2. Remova os metadados da VM do SQL Server do ouvinte:
    # Update the listener metadata by removing the VM from the SQLVMs list
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs that remain>
  3. Remova a VM do SQL Server do cluster:
    # Remove the SQL VM from the cluster
# example: az sql vm remove-from-group --name SQLVM3 --resource-group SQLVM-RG

az sql vm remove-from-group --name <SQL VM name> --resource-group <RG name>

Remover ouvinte

Se você precisar remover posteriormente o ouvinte do grupo de disponibilidade configurado com a CLI do Azure, você deve passar pela extensão do Agente IaaS do SQL. Como o ouvinte é registrado por meio da extensão do Agente IaaS do SQL, apenas excluí-lo por meio do SQL Server Management Studio não é suficiente.

O melhor método é exclui-lo por meio da extensão do Agente IaaS do SQL usando o snippet de código a seguir na CLI do Azure. Isso remove os metadados do ouvinte do grupo de disponibilidade da extensão do Agente IaaS do SQL. Também exclui fisicamente o ouvinte do grupo de disponibilidade.

# Remove the availability group listener
# example: az sql vm group ag-listener delete --group-name Cluster --name AGListener --resource-group SQLVM-RG

az sql vm group ag-listener delete --group-name <cluster name> --name <listener name > --resource-group <resource group name>

Remover cluster

Remova todos os nós do cluster para destruí-los e remova os metadados do cluster da extensão do Agente IaaS do SQL. É possível fazer isso usando a CLI do Azure ou o PowerShell.

Remova todas as VMs do SQL Server do cluster:

# Remove the VM from the cluster metadata
# example: az sql vm remove-from-group --name SQLVM2 --resource-group SQLVM-RG

az sql vm remove-from-group --name <VM1 name>  --resource-group <resource group name>
az sql vm remove-from-group --name <VM2 name>  --resource-group <resource group name>

Se essas forem as únicas VMs no cluster, o cluster será destruído. Se houver outras VMs no cluster além das VMs do SQL Server que foram removidas, as outras VMs não vão ser removidas e o cluster não vai ser destruído.

Remova os metadados do cluster da extensão do Agente IaaS do SQL:

# Remove the cluster from the SQL VM RP metadata
# example: az sql vm group delete --name Cluster --resource-group SQLVM-RG

az sql vm group delete --name <cluster name> Cluster --resource-group <resource group name>

Próximas etapas

Depois que o grupo de disponibilidade for implantado, considere otimizar as Configurações de HADR para o SQL Server em VMs do Azure.

Para obter mais informações, consulte: