Clustering de failover e grupos de disponibilidade AlwaysOn (SQL Server)

Aplica-se a:SQL Server – Somente Windows

O Grupos de disponibilidade AlwaysOn, a solução de alta disponibilidade e recuperação de desastre incorporada no SQL Server 2012 (11.x), requer o WSFC (Windows Server Failover Clustering). Além disso, embora os grupos de disponibilidade Always On não dependam do clustering de failover do SQL Server, você pode usar uma FCI (instância de clustering de failover) para hospedar uma réplica de disponibilidade para um grupo de disponibilidade. É importante saber a função de cada tecnologia de clustering e saber quais considerações são necessárias à medida que você projeta seu ambiente de grupos de disponibilidade Always On.

Clustering de Failover do Windows Server e grupos de disponibilidade

A implantação do Grupos de disponibilidade AlwaysOn exige um WSFC (Windows Server Failover Cluster). Para ser habilitado para Grupos de disponibilidade AlwaysOn, uma instância do SQL Server deve residir em um nó WSFC, e o nó e o WSFC devem estar online. Além do mais, cada réplica de disponibilidade de um determinado grupo de disponibilidade deve residir em um nó diferente do mesmo WSFC. A única exceção é que, embora tenha sido migrado para outro WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

Grupos de disponibilidade AlwaysOn conta com o cluster WSFC (Windows Server Failover Cluster) para monitorar e gerenciar as funções atuais das réplicas de disponibilidade que pertencem a determinado grupo de disponibilidade e especificar como um evento de failover afeta as réplicas de disponibilidade. Um grupo de recursos do WSFC é criado para cada grupo de disponibilidade que você cria. O WSFC monitora este grupo de recursos para avaliar a integridade da réplica primária.

O quorum para o Grupos de disponibilidade AlwaysOn é baseado em todos os nós no WSFC independentemente de se um determinado nó de cluster hospeda qualquer réplica de disponibilidade. Em contraste com o espelhamento de banco de dados, não há nenhuma função testemunha em grupos de disponibilidade Always On.

A integridade geral de um WSFC é determinada pelos votos do quorum de nós no cluster. Se o WSFC for colocado offline devido a um desastre não planejado ou devido a um hardware ou uma falha de comunicação persistente, será necessária intervenção administrativa manual. Um administrador do Windows Server ou do WSFC precisará forçar um quorum e colocar os nós de cluster de sobrevivência novamente online em uma configuração não tolerante a falhas.

Para obter informações sobre como executar o SQL Server em nós WSFC e sobre o quorum do WSFC, consulte o Clustering de Failover do Windows Server com o SQL Server.

FCIs (instâncias de cluster de failover) do SQL Server e grupos de disponibilidade

Você pode configurar uma segunda camada de failover no nível da instância do servidor implementando SQL Server e um FCI junto com o WSFC. Uma instância autônoma do SQL Server ou uma instância de FCI pode hospedar uma réplica de disponibilidade. Somente um parceiro FCI pode hospedar uma réplica para um determinado grupo de disponibilidade. Quando uma réplica de disponibilidade estiver sendo executada em um FCI, a lista de proprietários possíveis para o grupo de disponibilidade conterá apenas o nó de FCI ativo.

Os grupos de disponibilidade Always On não dependem de nenhuma forma de armazenamento compartilhado. No entanto, se você usar uma FCI (instância de cluster de failover) do SQL Server para hospedar uma ou mais réplicas de disponibilidade, cada uma dessas FCIs exigirá armazenamento compartilhado para cada instalação de instância de cluster de failover padrão do SQL Server.

Para obter mais informações sobre pré-requisitos adicionais, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server).

Comparação de instâncias de cluster de failover e grupos de disponibilidade

Independentemente do número de nós na FCI, uma FCI inteira hospeda uma única réplica dentro de um grupo de disponibilidade. A tabela a seguir descreve as distinções em conceitos entre nós em uma FCI e réplicas dentro de um grupo de disponibilidade.

*Considerando que réplicas secundárias síncronas em um grupo de disponibilidade estão sempre em execução em suas respectivas instâncias do SQL Server, os nós secundários em uma FCI realmente não iniciaram suas respectivas instâncias do SQL Server e, portanto, não são legíveis. Em uma FCI, um nó secundário inicia sua instância do SQL Server somente quando a propriedade do grupo de recursos é transferida a ele durante um failover de FCI. No entanto, no nó FCI ativo, quando um banco de dados hospedado por FCI pertence a um grupo de disponibilidade, o banco de dados será legível se a réplica de disponibilidade local estiver em execução como uma réplica secundária legível.

**As configurações de política de failover para o grupo de disponibilidade se aplicam a todas as réplicas, seja hospedadas em uma instância autônoma ou em uma instância de FCI.

Considerações para hospedar uma réplica de disponibilidade em uma FCI

As FCIs (Instâncias de Cluster de Failover) do SQL Server não dão suporte ao failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade que um host FCI só pode ser configurada para failover manual.

Talvez seja necessário configurar um WSFC para incluir discos compartilhados que não estão disponíveis em todos os nós. Por exemplo, considere um WSFC em dois centros de dados com três nós. Dois dos nós hospedam uma FCI do SQL Server no data center primário e têm acesso aos mesmos discos compartilhados. O terceiro nó hospeda uma instância autônoma do SQL Server em um data center diferente e não tem acesso aos discos compartilhados do data center primário. Essa configuração do WSFC dá suporte à implantação de um grupo de disponibilidade se a FCI hospedar a réplica primária e a instância autônoma hospedar a réplica secundária.

Ao escolher uma FCI para hospedar uma réplica de disponibilidade para um determinado grupo de disponibilidade, verifique se um failover de FCI não poderia potencialmente fazer com que um único nó WSFC tentasse hospedar duas réplicas de disponibilidade para o mesmo grupo de disponibilidade.

O exemplo de cenário a seguir ilustra como esta configuração pode resultar em problemas:

• Configure um WSFC com dois nós, NODE01 e NODE02.
• Instala-se uma instância de cluster de failover do SQL Server, fciInstance1, em ambas as NODE01 e NODE02, onde NODE01 é o proprietário atual do fciInstance1.
• On NODE02, you install another instance of SQL Server, Instance3which is a standalone instance.
• No NODE01, você habilita fciInstance1 para grupos de disponibilidade Always On. No NODE02, você habilita Instance3 para grupos de disponibilidade Always On. Em seguida, você configura um grupo de disponibilidade para o qual fciInstance1 hospeda a réplica primária e Instance3 hospeda a réplica secundária.
• Em algum momento, fciInstance1 fica indisponível NODE01e o WSFC causa um failover de fciInstance1 .NODE02 Após o failover, fciInstance1 torna-se uma instância habilitada para o Grupos de disponibilidade AlwaysOnexecutada sob a função primária em NODE02. No entanto, agora a Instance3 reside no mesmo nó WSFC da fciInstance1. Isso violará a restrição do Grupos de disponibilidade AlwaysOn .

Para corrigir o problema que este cenário apresenta, a instância autônoma, Instance3deve residir em outro nó no mesmo WSFC que NODE01 e NODE02.

Para obter mais informações sobre FCIs do SQL Server, consulte Instâncias de cluster de failover Always On (SQL Server).

Restrições ao uso do Gerenciador WSFC com grupos de disponibilidade

Não use o Gerenciador de Cluster de Failover para manipular grupos de disponibilidade. Por exemplo:

• Não adicione ou remova recursos no serviço clusterizado (grupo de recursos) para o grupo de disponibilidade.

• Não altere nenhuma propriedade do grupo de disponibilidade, como os possíveis proprietários e proprietários preferenciais. Essas propriedades são definidas automaticamente pelo grupo de disponibilidade.

• Não use o Gerenciador de Cluster de Failover para mover grupos de disponibilidade para nós diferentes ou para fazer failover de grupos de disponibilidade. O Gerenciador de Cluster de Failover não está ciente do status de sincronização das réplicas de disponibilidade e isso pode levar a um tempo de inatividade estendido. Você deve usar o Transact-SQL ou o SQL Server Management Studio.

Conteúdo relacionado

• O que é um grupo de disponibilidade Always On?
• Habilitar ou desabilitar o recurso de grupo de disponibilidade Always On
• Monitorar grupos de disponibilidade (Transact-SQL)
• Instâncias de cluster de failover Always On (SQL Server)
• Configurar o Windows Failover Clustering para SQL Server (grupo de disponibilidade ou FCI) com segurança limitada
• Blogs da equipe do AlwaysOn do SQL Server: o blog oficial da equipe do AlwaysOn do SQL Server
• Blogs dos engenheiros do CSS SQL Server
• Guia de arquitetura alwayson: criando uma solução de alta disponibilidade e recuperação de desastre usando instâncias de cluster de failover e grupos de disponibilidade
• Guia de soluções AlwaysOn do Microsoft SQL Server para alta disponibilidade e recuperação de desastres