Grupo de disponibilidade Always On no SQL Server em VMs do Azure

Aplica-se a:SQL Server na VM do Azure

Este artigo apresenta grupos de disponibilidade Always On (AG) para SQL Server em Máquinas Virtuais (VMs) do Azure.

Para começar, consulte o tutorial do grupo de disponibilidade.

Descrição geral

Os grupos de disponibilidade Always On nas Máquinas Virtuais do Azure são semelhantes aos grupos de disponibilidade Always On no local e dependem do Cluster de Failover do Windows Server subjacente. No entanto, como as máquinas virtuais são hospedadas no Azure, também há algumas considerações adicionais, como redundância de VM e tráfego de roteamento na rede do Azure.

O diagrama a seguir ilustra um grupo de disponibilidade para o SQL Server em VMs do Azure:

Redundância de VM

Para aumentar a redundância e a alta disponibilidade, as VMs do SQL Server devem estar no mesmo conjunto de disponibilidade ou em zonas de disponibilidade diferentes.

Colocar um conjunto de VMs no mesmo conjunto de disponibilidade protege contra interrupções em um data center causadas por falha de equipamento (VMs dentro de um Conjunto de Disponibilidade não compartilham recursos) ou de atualizações (VMs dentro de um conjunto de disponibilidade não são atualizadas ao mesmo tempo).

As Zonas de Disponibilidade protegem contra a falha de um data center inteiro, com cada Zona representando um conjunto de data centers dentro de uma região. Ao garantir que os recursos sejam colocados em diferentes zonas de disponibilidade, nenhuma interrupção no nível do data center pode colocar todas as suas VMs offline.

Ao criar VMs do Azure, você deve escolher entre configurar Conjuntos de Disponibilidade vs Zonas de Disponibilidade. Uma VM do Azure não pode participar de ambos.

Embora as Zonas de Disponibilidade possam fornecer melhor disponibilidade do que os Conjuntos de Disponibilidade (99,99% vs 99,95%), o desempenho também deve ser uma consideração. As VMs dentro de um Conjunto de Disponibilidade podem ser colocadas em um grupo de posicionamento de proximidade que garante que elas estejam próximas umas das outras, minimizando a latência da rede entre elas. As VMs localizadas em diferentes zonas de disponibilidade têm maior latência de rede entre elas, o que pode aumentar o tempo necessário para sincronizar dados entre a(s) réplica(s) primária(s) e secundária(s). Isso pode causar atrasos na réplica principal, bem como aumentar a chance de perda de dados no caso de um failover não planejado. É importante testar a solução proposta sob carga e garantir que ela atenda aos SLAs de desempenho e disponibilidade.

Conectividade

Para corresponder à experiência local de conexão com o ouvinte do grupo de disponibilidade, implante suas VMs do SQL Server em várias sub-redes dentro da mesma rede virtual. Ter várias sub-redes nega a necessidade da dependência extra de um Balanceador de Carga do Azure ou de um DNN (nome de rede distribuído) para rotear seu tráfego para o ouvinte.

Se você implantar suas VMs do SQL Server em uma única sub-rede, poderá configurar um nome de rede virtual (VNN) e um Balanceador de Carga do Azure ou um DNN (nome de rede distribuída) para rotear o tráfego para o ouvinte do grupo de disponibilidade. Analise as diferenças entre os dois e, em seguida, implante um nome de rede distribuída (DNN) ou um nome de rede virtual (VNN) para seu grupo de disponibilidade.

A maioria dos recursos do SQL Server funciona de forma transparente com grupos de disponibilidade ao usar a DNN, mas há certos recursos que podem exigir consideração especial. Consulte Interoperabilidade AG e DNN para saber mais.

Além disso, há algumas diferenças de comportamento entre a funcionalidade do ouvinte VNN e do ouvinte DNN que são importantes observar:

• Tempo de failover: o tempo de failover é mais rápido ao usar um ouvinte DNN, pois não há necessidade de esperar que o balanceador de carga de rede detete o evento de falha e altere seu roteamento.
• Conexões existentes: as conexões feitas com um banco de dados específico dentro de um grupo de disponibilidade de failover serão fechadas, mas outras conexões com a réplica primária permanecerão abertas, pois a DNN permanece online durante o processo de failover. Isso é diferente de um ambiente VNN tradicional, onde todas as conexões com a réplica primária normalmente fecham quando o grupo de disponibilidade faz failover, o ouvinte fica offline e a réplica primária transita para a função secundária. Ao usar um ouvinte DNN, talvez seja necessário ajustar as cadeias de conexão do aplicativo para garantir que as conexões sejam redirecionadas para a nova réplica primária após o failover.
• Transações abertas: Abrir transações em um banco de dados em um grupo de disponibilidade de failover será fechado e revertido, e você precisará se reconectar manualmente . Por exemplo, no SQL Server Management Studio, feche a janela de consulta e abra uma nova.

Configurar um ouvinte VNN no Azure requer um balanceador de carga. Há duas opções principais para balanceadores de carga no Azure: externa (pública) ou interna. O balanceador de carga externo (público) é voltado para a Internet e está associado a um IP virtual público acessível pela Internet. Um balanceador de carga interno suporta apenas clientes dentro da mesma rede virtual. Para qualquer tipo de balanceador de carga, você deve habilitar o Retorno Direto do Servidor.

Você ainda pode se conectar a cada réplica de disponibilidade separadamente conectando-se diretamente à instância de serviço. Além disso, como os grupos de disponibilidade são compatíveis com versões anteriores de clientes de espelhamento de banco de dados, você pode se conectar às réplicas de disponibilidade como parceiros de espelhamento de banco de dados, desde que as réplicas sejam configuradas de forma semelhante ao espelhamento de banco de dados:

• Há uma réplica primária e uma réplica secundária.
• A réplica secundária é configurada como ilegível (opção secundária legível definida como Não).

A seguir está um exemplo de cadeia de conexão de cliente que corresponde a essa configuração semelhante ao espelhamento de banco de dados usando o ADO.NET ou o SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Para obter mais informações sobre a conectividade do cliente, consulte:

• Usando palavras-chave de cadeia de conexão com o SQL Server Native Client
• Conectar clientes a uma sessão de espelhamento de banco de dados (SQL Server)
• Conectando-se ao ouvinte do grupo de disponibilidade em TI híbrida
• Ouvintes de grupo de disponibilidade, conectividade de cliente e failover de aplicativo (SQL Server)
• Usando cadeias de conexão de espelhamento de banco de dados com grupos de disponibilidade

Uma única sub-rede requer balanceador de carga

Quando você cria um ouvinte de grupo de disponibilidade em um WSFC (Cluster de Failover do Windows Server) local tradicional, um registro DNS é criado para o ouvinte com o endereço IP fornecido, e esse endereço IP é mapeado para o endereço MAC da réplica primária atual nas tabelas ARP de switches e roteadores na rede local. O cluster faz isso usando ARP gratuito (GARP), onde transmite o mapeamento de endereço IP para MAC mais recente para a rede sempre que um novo primário é selecionado após o failover. Nesse caso, o endereço IP é para o ouvinte e o MAC é da réplica primária atual. O GARP força uma atualização para as entradas da tabela ARP para os switches e roteadores, e para todos os usuários que se conectam ao endereço IP do ouvinte são roteados diretamente para a réplica primária atual.

Por motivos de segurança, a transmissão em qualquer nuvem pública (Azure, Google, AWS) não é permitida, portanto, os usos de ARPs e GARPs no Azure não são suportados. Para superar essa diferença em ambientes de rede, as VMs do SQL Server em um único grupo de disponibilidade de sub-rede dependem de balanceadores de carga para rotear o tráfego para os endereços IP apropriados. Os balanceadores de carga são configurados com um endereço IP frontend que corresponde ao ouvinte e uma porta de teste é atribuída para que o Balanceador de Carga do Azure pesquise periodicamente o status das réplicas no grupo de disponibilidade. Como apenas a réplica primária da VM do SQL Server responde à sonda TCP, o tráfego de entrada é roteado para a VM que responde com êxito à sonda. Além disso, a porta de teste correspondente é configurada como o IP do cluster WSFC, garantindo que a réplica primária responda à sonda TCP.

Os grupos de disponibilidade configurados em uma única sub-rede devem usar um balanceador de carga ou um DNN (nome de rede distribuída) para rotear o tráfego para a réplica apropriada. Para evitar essas dependências, configure seu grupo de disponibilidade em várias sub-redes para que o ouvinte do grupo de disponibilidade seja configurado com um endereço IP para uma réplica em cada sub-rede e possa rotear o tráfego adequadamente.

Se você já criou seu grupo de disponibilidade em uma única sub-rede, pode migrá-lo para um ambiente de várias sub-redes.

Mecanismo de locação

Para o SQL Server, a DLL do recurso AG determina a integridade do AG com base no mecanismo de concessão AG e na deteção de integridade Always On. A DLL do recurso AG expõe a integridade do recurso por meio da operação IsAlive . O monitor de recursos sonda IsAlive no intervalo de pulsação do cluster, que é definido pelos valores CrossSubnetDelay e SameSubnetDelay em todo o cluster. Em um nó primário, o serviço de cluster inicia o failover sempre que a chamada IsAlive para a DLL do recurso retorna que o AG não está íntegro.

A DLL do recurso AG monitora o status dos componentes internos do SQL Server. Sp_server_diagnostics relata a integridade desses componentes para o SQL Server em um intervalo controlado por HealthCheckTimeout.

Ao contrário de outros mecanismos de failover, a instância do SQL Server desempenha um papel ativo no mecanismo de concessão. O mecanismo de concessão é usado como uma validação LooksAlive entre o host de recursos de cluster e o processo do SQL Server. O mecanismo é usado para garantir que os dois lados (o Serviço de Cluster e o serviço SQL Server) estejam em contato frequente, verificando o estado um do outro e, finalmente, evitando um cenário de cérebro dividido.

Ao configurar um AG em VMs do Azure, muitas vezes há a necessidade de configurar esses limites de forma diferente do que seriam configurados em um ambiente local. Para definir as configurações de limite de acordo com as práticas recomendadas para VMs do Azure, consulte as práticas recomendadas de cluster.

Configuração de rede

Implante suas VMs do SQL Server em várias sub-redes sempre que possível para evitar a dependência de um Balanceador de Carga do Azure ou de um DNN (nome de rede distribuído) para rotear o tráfego para o ouvinte do grupo de disponibilidade.

Em um cluster de failover de VM do Azure, recomendamos uma única NIC por servidor (nó de cluster). A rede do Azure tem redundância física, o que torna NICs adicionais desnecessárias em um cluster de failover de VM do Azure. Embora o relatório de validação de cluster emita um aviso de que os nós só podem ser acessados em uma única rede, esse aviso pode ser ignorado com segurança em clusters de failover de VM do Azure.

Grupo de disponibilidade básica

Como o grupo de disponibilidade básica não permite mais de uma réplica secundária e não há acesso de leitura à réplica secundária, você pode usar as cadeias de conexão de espelhamento de banco de dados para grupos de disponibilidade básica. Usar a cadeia de conexão elimina a necessidade de ter ouvintes. Remover a dependência do ouvinte é útil para grupos de disponibilidade em VMs do Azure, pois elimina a necessidade de um balanceador de carga ou a necessidade de adicionar IPs adicionais ao balanceador de carga quando você tem vários ouvintes para bancos de dados adicionais.

Por exemplo, para se conectar explicitamente usando TCP/IP ao banco de dados AG AdventureWorks em Replica_A ou Replica_B de um AG Básico (ou qualquer AG que tenha apenas uma réplica secundária e o acesso de leitura não seja permitido na réplica secundária), um aplicativo cliente pode fornecer a seguinte cadeia de conexão de espelhamento de banco de dados para se conectar com êxito ao AG

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Opções de implementação

Há várias opções para implantar um grupo de disponibilidade no SQL Server em VMs do Azure, algumas com mais automação do que outras.

A tabela a seguir fornece uma comparação das opções disponíveis:

Próximos passos

Para começar, revise as práticas recomendadas do HADR e implante seu grupo de disponibilidade manualmente com o tutorial do grupo de disponibilidade.

Para saber mais, consulte:

• Cluster de Failover do Windows Server com o SQL Server em VMs do Azure
• Visão geral dos grupos de disponibilidade Always On