VENDAS: 1-800-867-1389

Tutorial: Configuração de ouvinte para Grupos de Disponibilidade AlwaysOn

Atualizado: janeiro de 2015

Este tópico mostra a você como configurar um ouvinte para um Grupo de Disponibilidade AlwaysOn. Seu Grupo de Disponibilidade pode conter réplicas que são apenas locais, Azure apenas ou estendem-se localmente e Azure para configurações híbridas. Réplicas do Azure podem residir na mesma região ou em múltiplas regiões usando várias redes virtuais (VNets).

Os passos abaixo supõem que você já tenha configurado um grupo de disponibilidade, mas não configurou um ouvinte. Observe as seguintes limitações no ouvinte do grupo de disponibilidade no Azure:

  • O ouvinte de grupo de disponibilidade tem suporte no Windows Server 2008 R2, no Windows Server 2012 e no Windows Server 2012 R2.

  • O aplicativo cliente deve residir em um serviço de nuvem diferente que o que contém as máquinas virtuais de seu grupo de disponibilidade. Azure não oferece suporte a retorno de servidor direto com cliente e servidor no mesmo serviço de nuvem.

  • Somente um ouvinte de grupo de disponibilidade é suportado por serviço de nuvem, porque o ouvinte está configurado para usar o endereço IP do serviço de nuvem ou o endereço IP Virtual (VIP) do Balanceador de Carga Interno (ILB).

  • Se você estiver criando um ouvinte para um ambiente híbrido, a rede local deve ter conectividade à Internet pública além da VPN local a local com a rede virtual do Azure. Quando estiver na sub-rede do Azure, o ouvinte de grupo de disponibilidade é alcançável somente pelo endereço IP público do serviço de nuvem respectivo.

ImportantImportante
Este tutorial foca no uso de PowerShell para criar um ouvinte para um Grupo de Disponibilidade que inclui réplicas do Azure. Para obter mais informações sobre como configurar ouvintes usando o SSMS ou Transact-SQL, consulte Criar ou configurar um ouvinte de grupo de disponibilidade.

Primeiro, você deve decidir se deseja usar balanceamento de carga externo (público) ou interno (privado) para o ouvinte. Se o servidor de banco de dados tiver de ser acessível de fora da Rede Virtual (VNet) que contém o Grupo de Disponibilidade, você deve usar o public load balancing com um endereço IP público acessível pela Internet. No entanto, se só acessar o ouvinte na VNet (incluindo VPN site a site em cenários híbridos), você deve usar o Internal Load Balancing (ILB) com um endereço IP privado para o ouvinte. Como o ILB não é acessível de fora da VNet do Azure, isso oferece outra camada de segurança. No restante deste tutorial, algumas seções terão etapas diferentes para configurações do public load balancing versus Internal Load Balancing. Siga as instruções para sua abordagem selecionada.

noteObservação
O ILB só pode ser configurado em redes virtuais com um escopo regional. As redes virtuais existentes configuradas para um grupo de afinidades não podem usar o ILB. Para obter mais informações, consulte Balanceador de Carga Interno.

Para o ILB, você deve criar primeiro o balanceador de carga interno. Isso é feito no script a seguir. No ILB e no balanceamento de carga público, você deve criar um ponto de extremidade com balanceamento de carga para cada VM hospedando uma réplica do Azure. Se você tiver réplicas em várias regiões, cada réplica para essa região deve estar no mesmo serviço de nuvem na mesma VNet. Criar réplicas de Grupo de Disponibilidade que expandem múltiplas regiões do Azure requer configurar múltiplas VNets. Para obter mais informações sobre configurar através de conectividade VNet, consulte Configurar VNet para Conectividade VNet.

  1. No portal do Azure, navegue para cada VM hospedando uma réplica e visualize os detalhes.

  2. Clique na guia Pontos de extremidade para cada uma das máquinas virtuais.

  3. Verifique se o Nome e a Porta Pública do ponto de extremidade do ouvinte que você quer usar já não está em uso. No exemplo a seguir, o nome é “MyEndpoint” e a porta é “1433”.

  4. No cliente local, baixe e instale o módulo do PowerShell mais recente.

  5. Inicie o Azure PowerShell. Uma nova sessão do PowerShell é aberta com os módulos administrativos do Azure carregados.

  6. Execute Get-AzurePublishSettingsFile. Esse cmdlet direciona para um navegador para baixar um arquivo de configurações de publicação para um diretório local. Você pode ser solicitado a fornecer suas credenciais de logon para sua assinatura do Azure.

  7. Execute o comando Import-AzurePublishSettingsFile com o caminho do arquivo de configurações de publicação que você baixou:

    Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
    

    Assim que o arquivo de configurações de publicação tiver sido importado, você poderá gerenciar sua assinatura do Azure na sessão do PowerShell.

  8. Se estiver usando public load balancing, continue com esta etapa. Se estiver usando Internal Load Balancing (ILB), pule para a próxima etapa. Copie o script do PowerShell abaixo em um editor de texto e defina os valores da variável que se adaptam a seu ambiente. Observe que se seu grupo de disponibilidade abranger regiões do Azure, você deverá executar o script uma vez em cada data center para o serviço de nuvem e os nós que residem nesse datacenter.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "MyEndpoint" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    
    # Configure a load balanced endpoint for each node in $AGNodes, with direct server return enabled
    ForEach ($node in $AGNodes)
    {
        Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -Protocol "TCP" -PublicPort $EndpointPort -LocalPort $EndpointPort -LBSetName "$EndpointName-LB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM
    }
    
  9. Se estiver usando Internal Load Balancing (ILB), continue com esta etapa. Se estiver usando public load balancing, pule para a próxima etapa. Para ILB, você deve atribuir um endereço IP estático. Em primeiro lugar, examine a configuração atual da VNet executando o seguinte comando:

    (Get-AzureVNetConfig).XMLConfiguration
    

    Primeiro anote o nome da Sub-rede para a sub-rede que contém as VMs que hospedam as réplicas. Isso será usado no parâmetro $SubnetName no script. Em seguida, anote o nome VirtualNetworkSite e o início de AddressPrefix da sub-rede que contém as VMs que hospedam as réplicas. Procure um Endereço IP disponível, passando os dois valores para o comando Test-AzureStaticVNetIP e examinando o AvailableAddresses. Por exemplo, se a VNet foi nomeada MyVNet e tinha um intervalo de endereços de sub-rede iniciados em 172.16.0.128, o seguinte comando lista os endereços disponíveis:

    (Test-AzureStaticVNetIP -VNetName "MyVNet" -IPAddress 172.16.0.128).AvailableAddresses
    

    Escolha um dos endereços disponíveis e use-o no parâmetro $ILBStaticIP do script a seguir.

    Copie o script do PowerShell abaixo em um editor de texto e defina os valores da variável que se adaptam a seu ambiente. Observe que as implantações existentes que usam grupos de afinidade não podem adicionar ILB. Para obter mais informações sobre os requisitos de ILB, consulte Balanceador de Carga Interno. Observe que se seu grupo de disponibilidade abranger regiões do Azure, você deverá executar o script uma vez em cada data center para o serviço de nuvem e os nós que residem nesse datacenter.

    # Define variables
    $ServiceName = "<MyCloudService>" # the name of the cloud service that contains the availability group nodes
    $AGNodes = "<VM1>","<VM2>","<VM3>" # all availability group nodes containing replicas in the same cloud service, separated by commas
    $EndpointName = "<MyEndpoint>" # name of the endpoint
    $EndpointPort = "1433" # public port to use for the endpoint
    $ILBName = "<MyInternalLoadBalancer>" # chosen name for the new ILB
    $SubnetName = "<MySubnetName>" # subnet name that the replicas use in the VNet
    $ILBStaticIP = "<MyILBStaticIPAddress>" # static IP address for the ILB in the subnet
    
    Add-AzureInternalLoadBalancer -InternalLoadBalancerName $ILBName -SubnetName $SubnetName -ServiceName $ServiceName -StaticVNetIPAddress $ILBStaticIP
    
    # Configure a load balanced endpoint for each node in $AGNodes using ILB
    ForEach ($node in $AGNodes)
    {
    Get-AzureVM -ServiceName $ServiceName -Name $node | Add-AzureEndpoint -Name $EndpointName -LBSetName "$EndpointName-LB" -Protocol tcp -LocalPort $EndpointPort -PublicPort $EndpointPort -ProbePort 59999 -ProbeProtocol tcp -ProbeIntervalInSeconds 10 -InternalLoadBalancerName $ILBName -DirectServerReturn $true | Update-AzureVM 
    }
    
  10. Assim que você tiver definido as variáveis, copie o script do editor de texto na sessão do Azure PowerShell para executá-lo. Se o prompt ainda mostrar >>, digite ENTER novamente para iniciar a execução do script.

    noteObservação
    O Portal de Gerenciamento do Azure não suporta o Balanceador de Carga Interno neste momento, por isso não verá o ILB ou os pontos de extremidade no portal. No entanto, o Get-AzureEndpoint retorna um endereço IP interno se o Balanceador de Carga estiver sendo executado nele. De outra forma, retorna nulo.

Em seguida, se todos os servidores no cluster estiverem executando o Windows Server 2008 R2 ou Windows Server 20012, você deverá instalar o hotfix KB2854082, instalado em cada servidor local ou na VM do Azure que faz parte do cluster. Qualquer servidor ou VM que esteja no cluster, mas não esteja no grupo de disponibilidade, também deverá ter esse hotfix instalado.

Na sessão da área de trabalho remota para cada um dos nós do cluster, baixe a KB2854082 para um diretório local. Em seguida, instale o hotfix em cada um dos nós do cluster em sequência. Se o serviço de cluster estiver sendo executado no momento no nó de cluster, o servidor será reiniciado no final da instalação do hotfix.

WarningAviso
Parar o serviço de cluster ou reiniciar o servidor afeta a integridade do quorum do seu cluster e o grupo de disponibilidade, e pode fazer o cluster ficar offline. Para manter a alta disponibilidade do seu cluster durante a instalação, verifique se:

  • O cluster está com a integridade de quorum ideal,

  • Todos os nós de cluster estão online antes de instalar o hotfix em qualquer nó e

  • Permita a instalação do hotfix para executar até a conclusão em um nó, incluindo reinicialização completa do servidor, antes de instalar o hotfix em qualquer outro nó no cluster.

Nesta etapa, você cria uma regra de firewall para abrir a porta de investigação para o ponto de extremidade com balanceamento de carga (59999 conforme especificado antes), e outra regra para abrir a porta do ouvinte de grupo de disponibilidade. Como você criou o ponto de extremidade com balanceamento de carga nas VMs do Azure que contêm réplicas do grupo de disponibilidade, precisará abrir a porta de investigação e a porta do ouvinte nas respectivas máquinas virtuais do Azure.

  1. Em VMs hospedando réplicas, inicie o Firewall do Windows com Segurança Avançada.

  2. Clique com o botão direito do mouse em Regras de Entrada e clique em Nova Regra.

  3. Na página Tipo de Regra, selecione Porta e clique em Avançar.

  4. Na página Protocolo e Portas, selecione TCP e digite 59999 na caixa Portas locais específicas. Em seguida, clique em Avançar.

  5. Na página Ação, mantenha Permitir a conexão selecionado e clique em Avançar.

  6. Na página Perfil, aceite as configurações padrão e clique em Avançar.

  7. Na página Nome, especifique um nome de regra, como Porta de Investigação do Ouvinte AlwaysOn na caixa de texto Nome e clique em Concluir.

  8. Repita as etapas anteriores para a porta do ouvinte do grupo de disponibilidade (conforme especificado antes no parâmetro $EndpointPort do script) e especifique um nome de regra apropriado, como Porta do Ouvinte AlwaysOn.

Nessa etapa, você cria manualmente o ouvinte do grupo de disponibilidade no Gerenciador de Cluster de Failover e no SQL Server Management Studio (SSMS).

  1. Abra o Gerenciador de Cluster de Failover a partir do nó hospedando a réplica primária.

  2. Selecione o nó redes e anote o nome da rede do cluster. Esse nome será usado na variável $ClusterNetworkName no script do PowerShell.

  3. Expanda o nome do cluster e clique em Funções.

  4. No painel Funções, clique com o botão direito no nome do grupo de disponibilidade e depois selecione Adicionar Recurso > Ponto de Acesso para Cliente.

    Adicionar ponto de acesso de cliente para grupo de disponibilidade

  5. Na caixa Nome, crie um nome para este novo ouvinte e, em seguida, clique em Avançar duas vezes e clique em Concluir. Não coloque o ouvinte ou recurso online neste momento.

  6. Clique na guia Recursos, depois expanda para o Ponto de Acesso de Cliente que você acabou de criar. Você verá o recurso Endereço IP para cada rede de cluster no seu cluster. Se essa é uma solução somente no Azure, você verá somente um recurso de endereço IP.

  7. Se você estiver configurando uma solução híbrida, prossiga neste passo. Se você estiver configurando uma solução apenas do Azure, pule para o próximo passo.

    1. Clique com o botão direito do mouse no recurso de endereço IP que corresponda à sua sub-rede local, depois selecione Propriedades. Anote o Nome do Endereço IP e o nome da rede.

    2. Selecione Endereço IP Estático, atribua um endereço IP não usado e depois clique em OK.



  8. Clique com o botão direito do mouse no recurso Endereço IP que corresponde à sua sub-rede do Azure e, em seguida, selecione Propriedades.

    TipDica
    Se o ouvinte posteriormente não ficar online, devido a um endereço IP conflitante selecionado pelo DHCP, você pode configurar um Endereço IP estático válido nessa janela de propriedades.

  9. Na mesma janela de propriedades do Endereço IP, altere o Nome do Endereço IP. Esse nome de endereço IP será usado na variável $IPResourceName do script do PowerShell. Repita este passo para cada recurso de IP se sua solução expandir múltiplas VNets do Azure.

  10. Se estiver usando public load balancing, continue com esta etapa. Se estiver usando Internal Load Balancing, pule para a próxima etapa. Para o public load balancing, você deve obter o endereço IP virtual público do serviço de nuvem que contém suas réplicas. Faça logon no portal do Azure. Navegue para o serviço de nuvem que contém seu VM de grupo de disponibilidade. Abra a exibição Painel. Observe o endereço mostrado em Endereço IP Virtual Público (VIP). Se sua solução abranger VNets, repita essa etapa para cada serviço de nuvem que contém uma VM que hospeda uma réplica.

    Em uma das VMs, copie o script do PowerShell abaixo em um editor de texto e defina as variáveis para os valores anotados anteriormente.

    # Define variables
    $ClusterNetworkName = "<ClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
    $IPResourceName = "<IPResourceName>" # the IP Address resource name 
    $CloudServiceIP = "<X.X.X.X>" # Public Virtual IP (VIP) address of your cloud service
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$CloudServiceIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$CloudServiceIP probeport=59999  subnetmask=255.255.255.255
    
  11. Se estiver usando Internal Load Balancing (ILB), continue com esta etapa. Se estiver usando public load balancing, pule para a próxima etapa. Para ILB, você deve usar o endereço IP do ILB criado anteriormente. Use o script a seguir para obter esse endereço IP no PowerShell.

    # Define variables
    $ServiceName = "<MyServiceName>" # the name of the cloud service that contains the AG nodes
    (Get-AzureInternalLoadBalancer -ServiceName $ServiceName).IPAddress
    

    Em uma das VMs, copie o script do PowerShell abaixo em um editor de texto e defina as variáveis para os valores anotados anteriormente.

    # Define variables
    $ClusterNetworkName = "<MyClusterNetworkName>" # the cluster network name (Use Get-ClusterNetwork on Windows Server 2012 of higher to find the name)
    $IPResourceName = "<IPResourceName>" # the IP Address resource name 
    $ILBIP = “<X.X.X.X># the IP Address of the Internal Load Balancer (ILB)
    
    Import-Module FailoverClusters
    
    # If you are using Windows Server 2012 or higher, use the Get-Cluster Resource command. If you are using Windows Server 2008 R2, use the cluster res command. Both commands are commented out. Choose the one applicable to your environment and remove the # at the beginning of the line to convert the comment to an executable line of code. 
    
    # Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
    # cluster res $IPResourceName /priv enabledhcp=0 overrideaddressmatch=1 address=$ILBIP probeport=59999  subnetmask=255.255.255.255
    
  12. Quando você tiver definido as variáveis, abra uma janela do Windows PowerShell elevada, depois copie o script do editor de texto e copie na sua sessão do Azure PowerShell para executá-lo. Se o prompt ainda mostrar >>, digite ENTER novamente para iniciar a execução do script. Repita isso em cada VM.

    Esse script configura o recurso do Endereço IP com o endereço IP do serviço de nuvem e define outros parâmetros como a porta de investigação. Quando o recurso de endereço IP é colocado online, ele pode responder à sondagem na porta de investigação no ponto de extremidade com balanceamento de carga criado anteriormente neste tutorial.

  13. Navegue de volta para o Gerenciador de Cluster de Failover. Expanda Funções e depois realce seu Grupo de Disponibilidade. Na guia Recursos, clique com o botão direito do mouse no nome do ouvinte e clique em Propriedades.

  14. Clique na guia Dependências. Se houver vários recursos listados, verifique se os endereços IP têm dependência OU e não E. Clique em OK.

  15. Clique com o botão direito do mouse no nome do ouvinte e clique em Colocar Online.

  16. Quando o ouvinte estiver online, na guia Recursos, clique com o botão direito do mouse no grupo de disponibilidade e clique em Propriedades.

    Configurar o recurso do grupo de disponibilidade

  17. Crie uma dependência no recurso do nome de ouvinte (não o nome dos recursos do endereço IP). Clique em OK.

    Adicionar dependência no nome do ouvinte

  18. Inicie o SQL Server Management Studio e conecte à réplica primária.

  19. Navegue até Alta Disponibilidade AlwaysOn | Grupos de Disponibilidade | <AvailabilityGroupName> | Ouvintes do Grupo de Disponibilidade. Você agora deverá ver o nome do ouvinte que criou no Gerenciador de Cluster de Failover. Clique com o botão direito do mouse no nome do ouvinte e clique em Propriedades.

  20. Na caixa Porta, especifique o número da porta do ouvinte do grupo de disponibilidade usando o $EndpointPort utilizado antes (neste tutorial, 1433 como foi sugerido) e clique em OK.

Após o ouvinte do grupo de disponibilidade ser criado, pode ser necessário ajustar os parâmetros de cluster RegisterAllProvidersIP e HostRecordTTL para o recurso de ouvinte. Esses parâmetros podem reduzir o tempo de reconexão após um failover que pode impedir tempos limites de conexão. Para obter mais informações sobre esses parâmetros, bem como código de amostra, consulte Criar ou Configurar um Ouvinte do Grupo de Disponibilidade.

Nesta etapa, você testa o ouvinte do grupo de disponibilidade usando um aplicativo cliente sendo executado na mesma rede.

Para conectividade de cliente, observe os seguintes requisitos:

  • Conexões de cliente para o ouvinte devem vir de máquinas que residem em um serviço de nuvem diferente daquele que hospeda as réplicas de disponibilidade do AlwaysOn.

  • Se as réplicas do AlwaysOn estiverem em sub-redes diferentes, os clientes deverão especificar “MultisubnetFailover=True” na cadeia de conexão. Isso resulta em tentativas de conexão paralelas para as réplicas em sub-redes diferentes. Observe que esse cenário inclui uma implantação de grupo de disponibilidade do AlwaysOn entre regiões.

Um exemplo seria conectar-se ao ouvinte de uma das VMs na VNet do Azure (mas não uma que hospede uma réplica). Uma forma fácil para concluir este teste é tentar conectar SSMS para o ouvinte do grupo de disponibilidade. Outro método simples é executar SQLCMD.exe como a seguir:

sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15
TipDica
Observe que, se o valor EndpointPort for 1433, não será necessário especificá-lo na chamada. A chamada anterior também pressupõe que o computador cliente está conectado ao mesmo domínio e que o chamador tem permissões no banco de dados usando a autenticação do Windows.

Ao testar o ouvinte, realize o failover do grupo de disponibilidade para verificar se os clientes podem se conectar ao ouvinte entre failovers.

No caso do public load balancing, o teste anterior não funciona fora da VNet do Azure. Para acessar o ouvinte de fora da rede virtual, você deve especificar o nome do serviço de nuvem. Para um serviço de nuvem com o nome mycloudservice, a instrução sqlcmd seria o seguinte:

sqlcmd -S "mycloudservice.cloudapp.net,<EndpointPort>" -d "<DatabaseName>" -U "<LoginId>" -P "<Password>"  -Q "select @@servername, db_name()" -l 15

Ao contrário do exemplo anterior, a autenticação do SQL deve ser usada, porque o chamador não pode usar a autenticação do Windows pela Internet. Para obter mais informações, consulte Grupo de disponibilidade AlwaysOn na VM do Windows Azure: cenários de conectividade de cliente. Ao usar a autenticação SQL, certifique-se de que você cria o mesmo logon em ambas as réplicas. Para obter mais informações sobre como solucionar problemas de logons com grupos de disponibilidade, consulte Como mapear logons ou usar usuário do banco de dados SQL independente para se conectar a outras réplicas e mapear para bancos de dados de disponibilidade.

Se as réplicas do AlwaysOn estiverem em sub-redes diferentes, os clientes deverão especificar “MultisubnetFailover=True” na cadeia de conexão. Isso resulta em tentativas de conexão paralelas para as réplicas em sub-redes diferentes. Observe que esse cenário inclui uma implantação de grupo de disponibilidade do AlwaysOn entre regiões.

noteObservação
O teste nesta etapa não funciona com o ILB, porque o balanceador de carga interno não está acessível de fora da VNet do Azure.

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2015 Microsoft