Configure um ouvinte externo para grupos de disponibilidade em VMs SQL do Azure servidor
Este tópico mostra-lhe como configurar um ouvinte para um Grupo De Disponibilidade Sempre Acessível que seja acessível externamente na internet. Isto é possível associando o endereço virtual IP (VIP) do serviço de nuvem ao ouvinte.
Importante
O Azure tem dois modelos de implementação diferentes para criar e trabalhar com recursos: Resource Manager e Classic. Este artigo abrange utilizando o modelo de implantação Classic. A Microsoft recomenda que as implementações mais novas utilizem o modelo Resource Manager.
O seu Grupo de Disponibilidade pode conter réplicas que são apenas no local, apenas Azure, ou abrangem tanto no local como a Azure para configurações híbridas. As réplicas azure podem residir na mesma região ou em várias regiões usando várias redes virtuais (VNets). Os passos abaixo assumem que já configuraste um grupo de disponibilidade , mas não configuraste um ouvinte.
Diretrizes e limitações para ouvintes externos
Note as seguintes diretrizes sobre o ouvinte do grupo de disponibilidade em Azure quando estiver a implementar usando o endereço VIP público do serviço de nuvem:
- O ouvinte do grupo de disponibilidade é suportado no Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2.
- A aplicação do cliente deve residir num serviço de nuvem diferente daquele que contém os VM do seu grupo de disponibilidade. O Azure não suporta o retorno direto do servidor com o cliente e o servidor no mesmo serviço de cloud.
- Por predefinição, os passos deste artigo mostram como configurar um ouvinte para utilizar o endereço Virtual IP (VIP) do serviço de nuvem. No entanto, é possível reservar e criar vários endereços VIP para o seu serviço na nuvem. Isto permite-lhe usar os passos deste artigo para criar vários ouvintes que estão cada um associado a um VIP diferente. Para obter informações sobre como criar vários endereços VIP, consulte Vários VIPs por serviço na nuvem.
- Se estiver a criar um ouvinte para um ambiente híbrido, a rede no local deve ter conectividade com a Internet pública, além da VPN site-to-site com a rede virtual Azure. Quando na sub-rede Azure, o ouvinte do grupo de disponibilidade só é acessível pelo endereço IP público do respetivo serviço de nuvem.
- Não é suportado para criar um ouvinte externo no mesmo serviço de nuvem onde também tem um ouvinte interno usando o Balanceador de Carga Interno (ILB).
Determinar a acessibilidade do ouvinte
É importante perceber que há duas formas de configurar um ouvinte de grupo de disponibilidade em Azure. As formas diferem no tipo de equilibrador de carga Azure que utiliza quando cria o ouvinte. A tabela a seguir descreve as diferenças:
Tipo de balançador de carga | Implementação | Utilize se: |
---|---|---|
Externo | Utiliza o endereço IP virtual público do serviço de nuvem que acolhe as máquinas virtuais (VMs). | Tem de aceder ao ouvinte de fora da rede virtual, incluindo a partir da Internet. |
Interno | Utiliza um equilibrador de carga interno com um endereço privado para o ouvinte. | Só pode aceder ao ouvinte dentro da mesma rede virtual. Este acesso inclui VPN site-to-site em cenários híbridos. |
Importante
Para um ouvinte que utiliza o VIP público do serviço de nuvem (equilibrador de carga externo), desde que o cliente, ouvinte e bases de dados estejam na mesma região de Azure, não irá incorrer em encargos de erupção. Caso contrário, qualquer dado devolvido através do ouvinte é considerado saída, e é cobrado a taxas normais de transferência de dados.
Um ILB só pode ser configurado em redes virtuais com âmbito regional. As redes virtuais existentes que foram configuradas para um grupo de afinidade não podem utilizar um ILB. Para obter mais informações, consulte a visão geral do balançador de carga interna.
Este artigo centra-se na criação de um ouvinte que utiliza o equilíbrio de carga externa. Se quiser um ouvinte privado da sua rede virtual, consulte a versão deste artigo que fornece passos para a configuração de um ouvinte com o ILB
Criar pontos finais VM equilibrados em carga com retorno direto do servidor
O equilíbrio de carga externa utiliza o endereço VIRTUAL IP virtual virtual do serviço de nuvem que hospeda os seus VMs. Por isso, não é necessário criar ou configurar o equilibrador de carga neste caso.
Deve criar um ponto final equilibrado para cada VM que hospeda uma réplica Azure. Se tiver réplicas em várias regiões, cada réplica para essa região deve estar no mesmo serviço de nuvem no mesmo VNet. Criar réplicas do Grupo Availability que abrangem várias regiões do Azure requer a configuração de vários VNets. Para obter mais informações sobre a configuração da conectividade cross VNet, consulte Configure VNet para VNet Conectividade.
No portal do Azure, navegue para cada VM hospedando uma réplica e veja os detalhes.
Clique no separador Pontos finais para cada um dos VMs.
Verifique se o Nome e a Porta Pública do ponto final do ouvinte que pretende utilizar ainda não está a ser utilizado. No exemplo abaixo, o nome é "MyEndpoint" e o porto é "1433".
No seu cliente local, descarregue e instale o mais recente módulo PowerShell.
Lançamento Azure PowerShell. Abre-se uma nova sessão PowerShell com os módulos administrativos Azure carregados.
Executar Get-AzurePublishSettingsFile. Este cmdlet direciona-o para um navegador para descarregar um ficheiro de configurações de publicação para um diretório local. Pode ser solicitado para as suas credenciais de login para a sua assinatura Azure.
Executar o comando Import-AzurePublishSettingsFile com o caminho do ficheiro de definições de publicação que descarregou:
Import-AzurePublishSettingsFile -PublishSettingsFile <PublishSettingsFilePath>
Uma vez importado o ficheiro de definições de publicação, pode gerir a sua subscrição Azure na sessão PowerShell.
Copie o script PowerShell abaixo num editor de texto e desaprote os valores variáveis de acordo com o seu ambiente (foram fornecidos padrão para alguns parâmetros). Note que se o seu grupo de disponibilidade abrange regiões Azure, deve executar o script uma vez em cada datacenter para o serviço de nuvem e 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 # 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 "ListenerEndpoint" -Protocol "TCP" -PublicPort 1433 -LocalPort 1433 -LBSetName "ListenerEndpointLB" -ProbePort 59999 -ProbeProtocol "TCP" -DirectServerReturn $true | Update-AzureVM }
Depois de definir as variáveis, copie o script do editor de texto para a sua sessão de Azure PowerShell para executá-lo. Se a solicitação ainda aparecer >>, escreva ENTER novamente para se certificar de que o script começa a funcionar.
Verifique se o KB2854082 está instalado se necessário
Em seguida, se algum servidor do cluster estiver a executar o Windows Server 2008 R2 ou Windows Server 2012, deve verificar se o hotfix KB2854082 está instalado em cada um dos servidores no local ou VMs Azure que fazem parte do cluster. Qualquer servidor ou VM que esteja no cluster, mas não no grupo de disponibilidade, também deve ter este hotfix instalado.
Na sessão de desktop remota para cada um dos nós do cluster, baixe O KB2854082 para um diretório local. Em seguida, instale o hotfix em cada nó de aglomerado sequencialmente. Se o serviço de cluster estiver atualmente em funcionamento no nó de cluster, o servidor é reiniciado no final da instalação do hotfix.
Aviso
Parar o serviço de cluster ou reiniciar o servidor afeta a saúde do quórum do seu cluster e do grupo de disponibilidade, e pode fazer com que o seu cluster fique offline. Para manter a elevada disponibilidade do seu cluster durante a instalação, certifique-se de que:
- O cluster está na saúde ideal do quórum.
- Antes de instalar o hotfix em qualquer nó, todos os nós de cluster estão online.
- Antes de instalar o hotfix em qualquer outro nó no conjunto, deixe que a instalação do hotfix seja concluída até ao final de um nó, incluindo reiniciar completamente o servidor.
Abra as portas de firewall em nosmos de grupo de disponibilidade
Neste passo, cria-se uma regra de firewall para abrir a porta da sonda para o ponto final equilibrado de carga (59999, conforme especificado anteriormente) e outra regra para abrir a porta de ouvintes do grupo de disponibilidade. Como criou o ponto final equilibrado de carga nos VMs que contêm réplicas de grupo de disponibilidade, precisa de abrir a porta da sonda e a porta do ouvinte nos respetivos VMs.
Em VMs que acolhem réplicas, inicie o Windows Firewall com Segurança Avançada.
Clique em Regras de Entrada à Direita e, em seguida, clique em Nova Regra.
Na página 'Tipo regra' , selecione Porta e, em seguida, clique em Seguinte.
Na página Protocolo e Portas , selecione TCP, tipo 59999 na caixa de portas locais específica e, em seguida, clique em Seguinte.
Na página Ação , mantenha a ligação selecionada e, em seguida, clique em Seguinte.
Na página 'Perfil' , aceita as definições predefinidos e, em seguida, clica em Seguinte.
Na página Nome , na caixa de texto 'Nome' , especificar um nome de regra, como "Sempre No Ouvinte" e, em seguida, clicar em Terminar.
Repita os passos anteriores para a porta de escuta do grupo de disponibilidade (conforme especificado no parâmetro $EndpointPort do script) e, em seguida, especifique um nome de regra apropriado, como Always On Listener Port.
Criar o ouvinte do grupo de disponibilidade
Crie o ouvinte do grupo de disponibilidade em dois passos. Em primeiro lugar, crie o recurso de cluster de pontos de acesso ao cliente e configuure dependências. Segundo, configure os recursos de cluster com o PowerShell.
Crie o ponto de acesso ao cliente e configuure as dependências do cluster
Neste passo, cria manualmente o ouvinte do grupo de disponibilidade no Failover Cluster Manager e SQL Server Management Studio.
Open Failover Cluster Manager a partir do nó que acolhe a réplica primária.
Selecione o nó 'Redes ' e, em seguida, observe o nome da rede de cluster. Este nome é usado na variável $ClusterNetworkName no script PowerShell.
Expanda o nome do cluster e, em seguida, clique em Papéis.
No painel Roles, clique com o botão direito no nome do grupo de disponibilidade e, em seguida, selecione AdicionarPonto de Acesso ao Clientede Recurso>.
Na caixa Nome , crie um nome para este novo ouvinte, clique em Next duas vezes e, em seguida, clique em Terminar.
Não leve o ouvinte ou o recurso on-line neste momento.Clique no separador Recursos e, em seguida, expanda o ponto de acesso ao cliente que acabou de criar. É apresentado o recurso de endereço IP para cada rede de clusters do seu cluster. Se esta for uma solução apenas para o Azure, apenas é apresentado um recurso de endereço IP.
Efetue um dos seguintes procedimentos:
Para configurar uma solução híbrida:
a. Clique com o botão direito no recurso de endereço IP que corresponde à sua sub-rede no local e, em seguida, selecione Propriedades. Note o nome do endereço IP e o nome da rede.
b. Selecione O Endereço IP estático, atribua um endereço IP não uusado e, em seguida, clique em OK.
Para configurar uma solução apenas azure:
a. Clique com o botão direito no recurso de endereço IP que corresponde à sua sub-rede Azure e, em seguida, selecione Propriedades.
Nota
Se o ouvinte mais tarde não ficar on-line devido a um endereço IP conflituoso selecionado pela DHCP, pode configurar um endereço IP estático válido nesta janela de propriedades.
b. Na mesma janela de propriedades do endereço IP , altere o Nome do Endereço IP.
Este nome é usado na variável $IPResourceName do script PowerShell. Se a sua solução abranger várias redes virtuais Azure, repita este passo para cada recurso IP.
Configure os recursos de cluster na PowerShell
Para equilibrar carga externa, deve obter o endereço IP virtual público do serviço de nuvem que contém as suas réplicas. Inicie sessão no portal do Azure. Navegue para o serviço de nuvem que contém o seu VM do grupo de disponibilidade. Abra a vista do Painel de Instrumentos .
Note o endereço indicado no Endereço IP Virtual Público (VIP). Se a sua solução abranger VNets, repita este passo para cada serviço de nuvem que contenha um VM que acolhe uma réplica.
Num dos VMs, copie o script PowerShell abaixo num editor de texto e defina as variáveis para os valores que observou 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
Depois de definir as variáveis, abra uma janela de Windows PowerShell elevada, em seguida, copie o script do editor de texto e cole na sua sessão de Azure PowerShell para executá-lo. Se a solicitação ainda aparecer >>, escreva ENTER novamente para se certificar de que o script começa a funcionar.
Repita isto em cada VM. Este script configura o recurso IP Address com o endereço IP do serviço de nuvem e define outros parâmetros como a porta da sonda. Quando o recurso IP Address é trazido on-line, pode então responder à sondagem na porta da sonda a partir do ponto final equilibrado de carga criado anteriormente neste tutorial.
Traga o ouvinte on-line
Em Failover Cluster Manager, expanda as funções e, em seguida, realce o seu grupo de disponibilidade.
No separador Recursos , clique com o botão direito no nome do ouvinte e, em seguida, clique em Propriedades.
Clique no separador Dependências . Se vários recursos estiverem listados, verifique se os endereços IP têm ou, não E, dependências.
Clique em OK.
Clique com o botão direito no nome do ouvinte e, em seguida, clique em Bring Online.
Depois de o ouvinte estar online, no separador Recursos , clique com o botão direito no grupo de disponibilidade e, em seguida, clique em Propriedades.
Crie uma dependência do recurso de nome do ouvinte (não o nome de recursos de endereço IP) e, em seguida, clique em OK.
Comece SQL Server Management Studio e, em seguida, ligue-se à réplica primária.
Vá a AlwaysOn High Availability>Availability Grupos><AvailabilityGroupName>>Availability Availability Group.
O nome de ouvinte que criou no Failover Cluster Manager deve ser apresentado.Clique com o botão direito no nome do ouvinte e, em seguida, clique em Propriedades.
Na caixa de Porta , especifique o número da porta para o ouvinte do grupo de disponibilidade utilizando o $EndpointPort que usou anteriormente (neste tutorial, 1433 foi o padrão), e depois clique em OK.
Artigos de acompanhamento
Depois de criar o ouvinte do grupo de disponibilidade, poderá ser necessário ajustar os parâmetros do cluster RegisterAllProvidersIP e HostRecordTTL para o recurso do ouvinte. Estes parâmetros podem reduzir o tempo de reconexão após uma falha, o que pode impedir intervalos de ligação. Para obter mais informações sobre estes parâmetros, bem como o código de amostra, consulte Criar ou configurar um ouvinte de grupo de disponibilidade.
Teste o ouvinte do grupo de disponibilidade (dentro do mesmo VNet)
Neste passo, você testa o ouvinte do grupo de disponibilidade usando uma aplicação de cliente que está executando na mesma rede.
A conectividade do cliente tem os seguintes requisitos:
- As ligações do cliente ao ouvinte devem vir de máquinas que residem num serviço de nuvem diferente daquele que acolhe as réplicas de disponibilidade Always On.
- Se as réplicas Always On estiverem em sub-redes diferentes, os clientes devem especificar MultisubnetFailover=True na cadeia de ligação. Esta condição resulta em tentativas de ligação paralelas a réplicas nas várias subesí redes. Este cenário inclui uma implantação de grupo cross-region Always On availability.
Um exemplo é ligar ao ouvinte de um dos VMs na mesma rede virtual Azure (mas não um que acolhe uma réplica). Uma maneira fácil de completar este teste é tentar ligar SQL Server Management Studio ao ouvinte do grupo de disponibilidade. Outro método simples é executar SQLCMD.exe, da seguinte forma:
sqlcmd -S "<ListenerName>,<EndpointPort>" -d "<DatabaseName>" -Q "select @@servername, db_name()" -l 15
Nota
Se o valor EndpointPort for de 1433, não é obrigado a especiá-lo na chamada. A chamada anterior também pressupõe que a máquina do cliente está unida ao mesmo domínio e que o chamador recebeu permissões na base de dados utilizando a autenticação do Windows.
Ao testar o ouvinte, certifique-se de que falha sobre o grupo de disponibilidade para se certificar de que os clientes podem ligar-se ao ouvinte através de falhas.
Teste o ouvinte do grupo de disponibilidade (através da internet)
Para aceder ao ouvinte de fora da rede virtual, deve utilizar o equilíbrio de carga externa/pública (descrito neste tópico) em vez do ILB, que só é acessível dentro do mesmo VNet. Na cadeia de ligação, especifique o nome do serviço de assistência na nuvem. Por exemplo, se tivesse um serviço de nuvem com o nome mycloudservice, a declaração sqlcmd seria a 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 SQL deve ser utilizada, uma vez que o chamador não pode utilizar a autenticação do Windows através da internet. Para mais informações, consulte o Grupo Always On Availability em Azure VM: Cenários de Conectividade do Cliente. Ao utilizar a autenticação SQL, certifique-se de que cria o mesmo login em ambas as réplicas. Para obter mais informações sobre a resolução de logins com Grupos de Disponibilidade, consulte como mapear logins ou utilizar o utilizador de base de dados SQL contido para ligar a outras réplicas e mapear bases de dados de disponibilidade.
Se as réplicas Always On estiverem em sub-redes diferentes, os clientes devem especificar MultisubnetFailover=True na cadeia de ligação. Isto resulta em tentativas de ligação paralelas a réplicas nas diferentes sub-redes. Note que este cenário inclui uma implantação do Grupo Always On Availability.
Passos seguintes
Além de ligar automaticamente os clientes à réplica primária, um ouvinte pode ser usado para redirecionar cargas de trabalho apenas de leitura para os secundários. Esta utilização pode melhorar o desempenho e a escalabilidade da sua solução global. Para obter mais informações, consulte o ReadIntent Encaminhamento com Azure Always On availability group listener.
Nota
Para obter dicas sobre os ouvintes do Azure, consulte o ouvinte do grupo de resolução de problemas em Azure no blog AlwaysOn Support Team.
Para obter mais informações sobre a utilização de SQL Server em Azure, consulte SQL Server em máquinas virtuais Azure.