Os Grupos de Disponibilidade AlwaysOn do SQL Server são a tecnologia mais recente da Microsoft para atender às necessidades de alta disponibilidade e recuperação de desastres das organizações que usam o SQL Server. Uma grande vantagem do AlwaysOn é a capacidade de lidar com HA e DR em uma implementação. Os principais benefícios do AlwaysOn que experimentamos são os seguintes:
Podemos agrupar bancos de dados relacionados como parte de um único Grupo de Disponibilidade e fazer failover deles juntos em caso de necessidade. Isso é especialmente útil para aplicativos que dependem de mais de um banco de dados, como Microsoft Office SharePoint, Microsoft Lync ou Sage.
Quando comparado com instâncias de cluster de failover do SQL Server, descobrimos que o armazenamento como um único ponto de falha foi eliminado, pois cada instância que constitui uma réplica tem seu próprio armazenamento atribuído.
Com AlwaysOn, é possível configurar HA e DR ao mesmo tempo. Isso é obtido criando clusters de failover do Windows de vários sites como base de sua configuração AlwaysOn. Executar uma alternância de função ao usar AlwaysOn é significativamente mais simples do que fazê-lo ao usar o envio de logs de transações.
A dependência do WSFC
Ao usar o SQL Server AlwaysOn AG para alta disponibilidade e recuperação de desastres, primeiro você precisa configurar um cluster de failover do Windows. Os AGs AlwaysOn dependem do WFCS para gerenciar o AG AlwaysOn como uma função composta por recursos de cluster como o nome do Grupo de Disponibilidade, o nome do compartilhamento de arquivos, o nome do Ouvinte e um endereço IP.
Fig. 1 AlwaysOn AG como um recurso de cluster
Quórum
Quórum é o número mínimo de votos necessários para a maioria em um cluster de failover. O quórum determina quantas falhas de nó o cluster pode sustentar. Por meio da rede privada na porta 3343, todos os nós do cluster comunicam o status de integridade e as informações de monitoramento de recursos. Em caso de falha, os votos mostram quais nós têm status “Up” e em quais recursos do nó devem ser colocados online.
Desde o Windows Server 2012, o número máximo de nós de cluster com suporte é dezesseis. No entanto, na maioria dos ambientes com os quais estou familiarizado, os clusters de dois nós são comuns. Um cluster de dois nós apresenta um pequeno problema em termos de quorum, pois cada nó tem um voto e, se houver um problema de comunicação entre os dois, cada um pode assumir que o outro não está íntegro. Isso é chamado de cenário de cérebro dividido. Cenários de cérebro dividido são o motivo para configurar um desempatador, como um disco ou compartilhamento de arquivos.
Se você tiver um número ímpar de nós, não é necessário configurar um desempatador. A Configuração de Quorum Dinâmico e a Testemunha Dinâmica foram introduzidas no Windows Server 2012 e no Windows Server 2012 R2, respectivamente. Com a ajuda dessas tecnologias, o Windows redistribui automaticamente os votos em um cluster para que o número de nós em um cluster não importe no estabelecimento de um Quorum. O voto de um nó do cluster é removido definindo a propriedade do cluster “NodeWeight” como 0. Esses recursos são habilitados por padrão.
Fig. 2 Obtendo todas as propriedades do cluster usando o PowerShell
Fig. 3 votos atribuídos em um cluster de dois nós
Usando o PowerShell
O comando Get-Cluster do PowerShell pode ser usado para verificar a configuração de quorum em um cluster do Windows. A Fig. 4 mostra como verificar todas as propriedades do Cluster relacionadas ao Quorum em um cluster e a Fig. 5 descreve as propriedades da Testemunha de Compartilhamento de Arquivos. Existem muitos outros comandos do PowerShell para verificar e gerenciar clusters do Windows.
Get-Cluster | Format-List –Property *Quorum*
Fig. 4 Comando do PowerShell para verificar as propriedades relacionadas ao quórum
Get-ClusterResource
Get-ClusterResource -Name "File Share Witness" | Get-ClusterParameter
Fig. 5 Comando do PowerShell para verificar detalhes das propriedades de testemunha de compartilhamento de arquivos
Modos de Quórum
O Cluster de Failover do Windows Server permite configurar até quatro modos. Os modos de quorum são essencialmente opções que você escolhe para determinar como o cluster lidará com falhas de nó.
1. Maioria de nós
Este modo de quórum pode sustentar falhas de até (n/2)-1 nós. É recomendado para clusters com um número ímpar de nós. Por exemplo, em um cluster de cinco nós, seria necessária uma falha de dois nós para causar uma falha de cluster.
2. Maioria de nós e discos
Pode sustentar falhas de até metade do número de nós de cluster, desde que a testemunha de disco (também chamada de disco de quorum) permaneça online.
3. Maioria do compartilhamento de nós e arquivos
Este modo de quórum pode sustentar falhas de até metade do número de nós de cluster, desde que o compartilhamento de arquivos permaneça acessível. A partir do Windows Server 2012 R2, a Microsoft recomenda que uma testemunha (disco ou compartilhamento de arquivos) sempre seja configurada ao criar um cluster.
4. Sem maioria
Este é um modo somente disco. Esse modo pode sustentar falhas de todos os nós, exceto um, desde que o disco esteja online. Este modo não é recomendado, pois o disco se torna um único ponto de falha.
Dicas sobre como configurar a maioria de nós e compartilhamentos de arquivos
Os Grupos de Disponibilidade AlwaysOn suportam apenas dois desses Modos de Quorum:Maioria de nós e Maioria de nós e compartilhamento de arquivos. Ao criar um cluster do Grupo de Disponibilidade AlwaysOn do SQL Server, há alguns pontos que o DBA deve ter em mente:
1. Usando servidores físicos
Ao configurar um cluster de dois nós para AlwaysOn, seus nós devem residir em racks físicos diferentes. O servidor que hospeda seu compartilhamento de arquivos deve residir em um terceiro rack.
2. Usando servidores virtuais
Ao configurar um cluster de dois nós para AlwaysOn, suas máquinas virtuais devem residir em hosts separados. A máquina virtual que hospeda seu compartilhamento de arquivos deve residir em um terceiro host.
3. Clustering de vários sites
Ao configurar um cluster de vários nós para AlwaysOn em data centers, em um cenário ideal, o servidor de arquivos que hospeda seu compartilhamento de arquivos deve residir em um terceiro data center.
4. Permissões de compartilhamento de arquivos
O Objeto Nome do Cluster deve ter permissões no compartilhamento de arquivos usado como Testemunha de Quorum. Sem isso, você normalmente teria erros ao tentar configurar o Quorum Witness.
Fig. 6 permissões no compartilhamento de arquivos
5. Configuração on-line
Os modos de quorum podem ser configurados enquanto o cluster estiver online. Portanto, caso o servidor de compartilhamento de arquivos falhe ou precise ser reconfigurado, certifique-se de reconfigurar rapidamente para garantir que não haja falhas inesperadas, especialmente em um cluster de dois nós.
Um caso de uso real
O diagrama na Fig. 7 mostra um cluster real Multi-Site AlwaysOn AG. É um cluster de quatro nós com dois nós em um site e outros dois em um site remoto de DR. O Servidor de Arquivos que hospeda o Compartilhamento de Arquivos usado como desempatador é hospedado em um terceiro data center. No presente caso, o Servidor de Arquivos reside na mesma cidade do Data Center Primário, mas se você puder pagar, o ideal seria ter o Servidor de Arquivos em outra cidade. A comunicação entre os três lados deve ser de boa qualidade para evitar falsos positivos.
Por exemplo, em nossa implementação inicial desse cluster, usamos “Replicação síncrona com failover automático” nos sites Live e DR. Em mais de uma ocasião, tivemos uma falha na comunicação que acionou um Failover automático para o site de DR e expôs uma falha em nossa configuração. Isso fez com que o nome do Ouvinte fosse resolvido para os endereços IP associados no site de recuperação de desastres e os clientes não pudessem mais se conectar porque a comunicação com esse novo endereço IP não era permitida nos firewalls de rede. Nós simplesmente retornamos ao Site Primário para mitigar o problema e alteramos a configuração para “Replicação Assíncrona com Failover Manual” para nós que residem em data centers. Planejamos cobrir o aspecto de resolução de nomes em nosso próximo artigo “AlwaysOn”.
Fig. 7 Um caso de uso real
Conclusão
O recurso AlwaysOn Availability Groups foi introduzido no SQL Server 2012 e é a tecnologia mais recente da Microsoft para atender às necessidades de alta disponibilidade e recuperação de desastres. A configuração de Grupos de Disponibilidade AlwaysOn depende muito do Serviço de Cluster de Failover do Windows. Os clusters de failover, por sua vez, dependem muito da configuração de quorum correta. Ao criar o AlwaysOn em clusters de vários sites, a latência entre seus nós nos diferentes sites e o compartilhamento de arquivos usado como árbitro realmente importa. Certifique-se de que sua configuração de quorum esteja sempre na melhor forma para evitar comportamentos inesperados com os Grupos de Disponibilidade.
Referências
Visão geral dos grupos de disponibilidade AlwaysOn
Agrupamento de failover do Windows com SQL Server
Documentação do PowerShell
Compreendendo o Quórum de Cluster de Failover do Windows Server
