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

Aplica-se a:SQL Server para Windows

Os grupos de disponibilidade Always On, a solução de alta disponibilidade e recuperação de desastres introduzida no SQL Server 2012 (11.x), requerem o WSFC (Windows Server Failover Clustering). Além disso, embora os grupos de disponibilidade do Always On não dependam do cluster de failover do SQL Server, você pode usar uma FCI (instância de cluster de failover) para hospedar uma réplica de disponibilidade de 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.

cluster de failover do Windows Server e grupos de disponibilidade

A implantação de grupos de disponibilidade Always On exige um WSFC (Windows Server Failover Cluster). Para ser habilitada para grupos de disponibilidade Always On, uma instância do SQL Server deve estar em um nó do WSFC, e o WSFC e o nó devem estar online. Além disso, cada réplica de um dado grupo de disponibilidade deve estar localizada 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.

Os grupos de disponibilidade Always On dependem do Cluster de Failover do Windows Server (WSFC) para monitorar e gerenciar as funções atuais das réplicas de disponibilidade que pertencem a um determinado grupo de disponibilidade e para determinar 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 dos grupos de disponibilidade Always On se baseia em todos os nós do WSFC, independentemente de um determinado nó de cluster hospedar alguma 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 saúde geral de um WSFC é determinada pelos votos de um quórum de nós do 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 o quórum e depois colocar novamente online os nós sobreviventes do cluster em uma configuração sem tolerância 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 em execução em um FCI, a lista de proprietários possíveis do grupo de disponibilidade conterá apenas o nó ativo do FCI.

Os grupos de disponibilidade Always On não dependem de nenhuma forma de armazenamento compartilhado. No entanto, se você usar uma instância de cluster de failover (FCI) do SQL Server para hospedar uma ou mais réplicas de disponibilidade, cada uma dessas FCIs exigirá armazenamento compartilhado, conforme a instalação padrão de instância de cluster de failover 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 entre instâncias de cluster de failover e grupos de disponibilidade

Independentemente do número de nós na FCI, a FCI inteira hospeda uma única réplica em 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.

*Enquanto as 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, na verdade, não têm suas respectivas instâncias do SQL Server iniciadas e, portanto, não estão disponíveis para leitura. Em uma FCI, um nó secundário inicia sua instância do SQL Server somente quando o controle do grupo de recursos é transferido para ele durante um failover da FCI. No entanto, no nó ativo do FCI, quando um banco de dados hospedado no FCI pertence a um grupo de disponibilidade, o banco de dados poderá ser lido se a réplica de disponibilidade local estiver em execução como uma réplica secundária legível.

**As configurações da política de failover do grupo de disponibilidade se aplicam a todas as réplicas, estejam elas hospedadas em uma instância independente ou em uma instância FCI.

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

As FCIs (Instâncias de Cluster de Failover) do SQL Server não oferecem suporte ao failover automático pelos grupos de disponibilidade, qualquer réplica de disponibilidade hospedada por uma 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 de um determinado grupo de disponibilidade, verifique se um failover da FCI não possa vir a fazer com que um mesmo nó do WSFC tente 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.
• Em NODE02, você instala outra instância do SQL Server, Instance3, que é uma instância autônoma.
• 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 em NODE01, e o WSFC provoca um failover de fciInstance1 para NODE02. Após o failover, fciInstance1 é uma instância habilitada para Grupos de Disponibilidade Always On em execução na função primária em NODE02. No entanto, agora a Instance3 está no mesmo nó WSFC que fciInstance1. Isso viola a restrição dos grupos de disponibilidade Always On.

Para corrigir o problema apresentado por este cenário, a instância autônoma Instance3 deve estar localizada 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 tem conhecimento do status de sincronização das réplicas de disponibilidade, e fazer isso pode levar a um tempo de inatividade prolongado. Você deve usar o Transact-SQL ou o SQL Server Management Studio.

Conteúdo relacionado

• O que é um grupo de disponibilidade Always On?
• Ative ou desative o recurso de grupo de disponibilidade do Always On
• Monitorar grupos de disponibilidade (Transact-SQL)
• Instâncias de cluster de failover Always On (SQL Server)
• Configurar o Cluster de Failover do Windows 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 Always On: Criando uma solução de alta disponibilidade e recuperação de desastres 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