Partilhar via

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

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Gorjeta

Há muitos métodos para implantar um grupo de disponibilidade. Simplifique sua implantação e elimine a necessidade de um Balanceador de Carga do Azure ou DNN (nome de rede distribuída) para seu grupo de disponibilidade Always On criando suas máquinas virtuais (VMs) do SQL Server em várias sub-redes dentro da mesma rede virtual do Azure. Se você já criou seu grupo de disponibilidade em uma única sub-rede, pode 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 para um grupo de disponibilidade Always On em uma única sub-rede.

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

Embora este artigo use o PowerShell e a CLI Az para configurar o ambiente do grupo de disponibilidade, também é possível fazê-lo a partir do portal do Azure, usando modelos de Início Rápido do Azure ou Manualmente também.

Nota

Agora é possível elevar e mudar sua solução de grupo de disponibilidade para o SQL Server em VMs do Azure usando o Azure Migrate. Consulte 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 associadas a um domínio no Azure executando o SQL Server 2016 (ou posterior) Enterprise edition no mesmo conjunto de disponibilidade ou zonas de disponibilidade diferentes que foram registradas com a extensão do SQL IaaS Agent.
  • A versão mais recente do PowerShell ou da CLI do Azure.
  • Dois endereços IP disponíveis (não utilizados por qualquer entidade). Um é para o balanceador de carga interno. O outro é para o ouvinte do grupo de disponibilidade dentro da mesma sub-rede que o grupo de disponibilidade. Se você estiver usando um balanceador de carga existente, precisará apenas de 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 mencionados neste artigo, pois há uma dependência do RSAT, que não está incluída nas instalações Core 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 que tenha a permissão Criar Objeto de Computador no domínio. Por exemplo, uma conta de administrador de domínio normalmente tem permissão suficiente (por exemplo: account@domain.com). Essa conta também deve fazer parte do grupo de administradores locais em cada VM para criar o cluster.
  • A conta de usuário de domínio que controla o SQL Server.

Criar uma conta de armazenamento

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

O trecho de código a seguir 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

Gorjeta

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

Definir metadados de cluster

O grupo de comandos do Azure CLI az sql vm group gerencia os metadados do serviço WSFC (Cluster de Failover do Windows Server) que hospeda o grupo de disponibilidade. Os metadados de cluster incluem o domínio do Ative Directory, contas de cluster, contas de armazenamento a serem usadas como testemunha de nuvem e 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 trecho 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

Adicionar a 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 az sql vm add-to-group comando adicionam mais VMs do SQL Server ao cluster recém-criado.

O trecho de código a seguir 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 para o -n nome da VM do SQL Server.

Configurar quórum

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

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

Validar cluster

Para que um cluster de failover seja suportado pela Microsoft, ele deve passar na validação do cluster. Conecte-se à VM usando seu método preferido, como o protocolo RDP (Remote Desktop Protocol) e valide se o cluster passa na validação antes de prosseguir. A falha ao fazer isso deixa o cluster em um estado 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 faria normalmente, usando o SQL Server Management Studio, o PowerShell ou o Transact-SQL.

Importante

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

Criar balanceador de carga interno

Nota

As implantações de 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 VNN (nome de rede virtual) tradicional e o Balanceador de Carga do Azure por um ouvinte DNN (nome de rede distribuído). Se você quiser usar uma DNN, ignore todas as etapas do tutorial que configuram o Balanceador de Carga do Azure para seu grupo de disponibilidade.

O ouvinte do grupo de disponibilidade Always On 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 failover e 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, você precisará usar um balanceador de carga padrão.

Nota

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

O trecho de código a seguir 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 IP público para 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 IP público da sua VM, vá para 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.

O ID do recurso de sub-rede é o valor de anexado ao ID do recurso de /subnets/<subnetname> rede virtual. Para identificar o 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 o ID do recurso para a rede virtual e anexe /subnets/<subnetname> ao final dele para criar o ID do recurso da sub-rede. Por exemplo:
    • Seu ID de recurso de rede virtual é: /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet
    • O nome da sua sub-rede é: default
    • Portanto, seu ID de recurso de sub-rede é: /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default

O trecho de código a seguir 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>

Modificar o número de réplicas

Há uma camada adicional de complexidade quando você está implantando um grupo de disponibilidade para VMs do SQL Server hospedadas no Azure. O provedor de recursos e o grupo de máquinas virtuais agora gerenciam os recursos. Como tal, quando você estiver adicionando ou removendo 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 dentro do 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 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, posteriormente, precisar remover o ouvinte do grupo de disponibilidade configurado com a CLI do Azure, você deverá passar pela extensão do SQL IaaS Agent. Como o ouvinte é registrado por meio da extensão do SQL IaaS Agent, apenas excluí-lo por meio do SQL Server Management Studio é insuficiente.

O melhor método é excluí-lo por meio da extensão do SQL IaaS Agent usando o seguinte trecho de código na CLI do Azure. Isso remove os metadados do ouvinte do grupo de disponibilidade da extensão do SQL IaaS Agent. Ele 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í-lo e, em seguida, remova os metadados do cluster da extensão do SQL IaaS Agent. Você pode fazer isso usando a CLI do Azure ou o PowerShell.

Primeiro, 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 serão removidas e o cluster não será destruído.

Em seguida, remova os metadados do cluster da extensão do SQL IaaS Agent:

# 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óximos passos

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

Para saber mais, consulte: