Clustering de Failover e grupos de disponibilidade Always On (SQL Server)

Aplica-se a:SQL Server - somente 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), requer o WSFC (Cluster de Failover do Windows Server). Além disso, embora os grupos de disponibilidade 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 para um grupo de disponibilidade. É importante conhecer a função de cada tecnologia de clustering e saber quais considerações são necessárias ao projetar seu ambiente de grupos de disponibilidade Always On.

Observação

Para obter informações sobre os conceitos de grupos de disponibilidade Always On, consulte O que é um grupo de disponibilidade Always On?

Clustering de Failover do Windows Server e grupos de disponibilidade

A implantação de grupos de disponibilidade Always On requer um WSFC (Cluster de Failover do Windows Server). Para ser ativada para Grupos de Disponibilidade Always On, uma instância do SQL Server deve residir num nó WSFC e o WSFC e o nó precisam estar online. Além disso, cada réplica de disponibilidade de um determinado grupo de disponibilidade deve residir num nó diferente do mesmo WSFC. A única exceção é que, ao ser migrado para outro WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

Os grupos de disponibilidade Always On dependem do WSFC (Cluster de Failover do Windows Server) 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 criado. O WSFC monitora esse grupo de recursos para avaliar a integridade da réplica primária.

O quórum para grupos de disponibilidade "Always On" é baseado em todos os nós no WSFC, independentemente de um determinado nó do cluster ter réplicas de disponibilidade hospedadas. Ao contrário do espelhamento de banco de dados, não há nenhum papel de testemunha nos grupos de disponibilidade Always On.

A saúde geral de um WSFC é determinada pelos votos de quórum dos nós no cluster. Se o WSFC ficar offline devido a um desastre não planejado ou devido a uma falha persistente de hardware ou comunicações, a intervenção administrativa manual será necessária. Um administrador do Windows Server ou WSFC precisará forçar um quórum e, em seguida, colocar os nós de cluster sobreviventes online novamente em uma configuração não tolerante a falhas.

Importante

As chaves de registo dos grupos de disponibilidade Always On são subchaves do WSFC. Se você excluir e recriar um WSFC, deverá desabilitar e reativar o recurso de grupos de disponibilidade Always On em cada instância do SQL Server que hospedou uma réplica de disponibilidade no WSFC original.

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

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

Você pode configurar uma segunda camada de failover no nível da instância do servidor implementando o SQL Server e a FCI junto com o WSFC. Uma instância autônoma do SQL Server ou uma instância FCI pode hospedar uma réplica de disponibilidade. Apenas um parceiro FCI pode hospedar uma réplica para um determinado grupo de disponibilidade. Quando uma réplica de disponibilidade está sendo executada em uma FCI, a lista de possíveis proprietários para o grupo de disponibilidade conterá apenas o nó 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 de acordo com a instalação padrão da 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 de instâncias de cluster de failover e grupos de disponibilidade

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

	Nodos dentro de uma FCI	Réplicas dentro de um grupo de disponibilidade
usa o WSFC	Sim	Sim
Nível de proteção	Instância	Base de dados
Tipo de armazenamento	Partilhado	Não compartilhado Embora as réplicas em um grupo de disponibilidade não compartilhem armazenamento, uma réplica hospedada por uma FCI usa uma solução de armazenamento compartilhado, conforme exigido por essa FCI. A solução de armazenamento é compartilhada apenas por nós dentro do FCI e não entre réplicas do grupo de disponibilidade.
Soluções de armazenamento	Conexão direta, SAN, pontos de montagem, SMB	Depende do tipo de nó
Elementos secundários legíveis	Não*	Sim
Configurações de política de failover aplicáveis	Quórum do WSFC Específico da FCI Configurações do grupo de disponibilidade**	Quórum do WSFC Configurações do grupo de disponibilidade
Recursos transferidos por failover	Servidor, instância e banco de dados	Apenas base de dados

*Enquanto as réplicas secundárias síncronas em um grupo de disponibilidade estão sempre em execução em suas respetivas instâncias do SQL Server, os nós secundários em uma FCI na verdade não iniciaram suas respetivas 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 para ela durante um failover de FCI. No entanto, no nó FCI ativo, quando um banco de dados hospedado pela FCI pertence a um grupo de disponibilidade, o banco de dados é legível se a réplica de disponibilidade local estiver sendo executada como uma réplica secundária legível.

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

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

Importante

Se você planeja hospedar uma réplica de disponibilidade em uma FCI (instância de cluster de failover) do SQL Server, verifique se os nós de host do Windows Server 2008 atendem aos pré-requisitos e restrições Always On para FCIs (Instâncias de Cluster de Failover). Para obter mais informações, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On (SQL Server).

As FCIs (Instâncias de Cluster de Failover) do SQL Server não oferecem suporte a 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 data centers 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 oferece 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, certifique-se de que um failover de FCI não possa fazer com que um único nó WSFC tente hospedar duas réplicas de disponibilidade para o mesmo grupo de disponibilidade.

O cenário de exemplo a seguir ilustra como essa configuração pode causar problemas:

Configuras um WSFC com dois nós, NODE01 e NODE02.
Você instalará uma instância de cluster de failover do SQL Server, fciInstance1, no NODE01 e no NODE02, onde NODE01 é o proprietário atual do fciInstance1.
No NODE02, você instala outra instância do SQL Server, Instance3que é 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 torna-se indisponível no NODE01, e o WSFC causa um failover de fciInstance1 para NODE02. Após o failover, fciInstance1 é uma instância habilitada para Grupos de Disponibilidade Always On, em execução sob a função principal em NODE02. No entanto, Instance3 agora reside no nó WSFC onde também se encontra fciInstance1. Isso viola a restrição de grupos de disponibilidade Always On.

Para corrigir o problema que esse cenário apresenta, a instância autônoma, Instance3, deve 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 WSFC Manager 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.

Advertência

Usar o Gerenciador de Cluster de Failover para mover uma instância de cluster de failover que hospeda um grupo de disponibilidade para um nó que já está hospedando uma réplica do mesmo grupo de disponibilidade pode resultar na perda da réplica do grupo de disponibilidade, impedindo que ela fique online no nó de destino. Um único nó de um cluster de failover não pode hospedar mais de uma réplica para o mesmo grupo de disponibilidade. Para obter mais informações sobre como isso ocorre e como recuperar, consulte o blog Réplica inesperadamente descartada no grupo de disponibilidade.

Comentários

Esta página foi útil?

Last updated on 2025-08-26