Partilhar via

Clustering de failover e Grupos de Disponibilidade AlwaysOn (SQL Server)

  • Artigo

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 o Grupos de disponibilidade AlwaysOn não seja dependente 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 quais considerações precisam ser observadas ao criar o ambiente do Grupos de disponibilidade AlwaysOn .

Observação

Para obter informações sobre os conceitos do Grupos de disponibilidade Always On, confira Visão geral dos grupos de disponibilidade Always On (SQL Server).

Windows Server Failover Clustering 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. Ao contrário do espelhamento do banco de dados, não há nenhuma função de testemunha no Grupos de disponibilidade AlwaysOn.

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.

Importante

As chaves do Registro Grupos de disponibilidade AlwaysOn são subchaves do WSFC. Se você excluir e recriar um WSFC, deverá desabilitar e reabilitar o recurso Grupos de disponibilidade AlwaysOn em cada instância do SQL Server que hospedava uma réplica de disponibilidade no WSFC original.

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

SQL Server FCIs (Instâncias de Cluster de Failover) 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 réplica de disponibilidade pode ser hospedada por ou uma instância autônoma do SQL Server ou uma instância FCI. 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.

Grupos de disponibilidade AlwaysOn não depende 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 os pré-requisitos adicionais, veja a seção “Pré-requisitos e Restrições do Uso de uma FCI (Instância de Cluster de Failover) do SQL Server para Hospedar uma Réplica de Disponibilidade” de 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.

Nós dentro de uma FCI Réplicas dentro de um grupo de disponibilidade
Usa o WSFC Sim Sim
Nível de proteção Instância Banco de dados
Tipo de armazenamento Compartilhada Não compartilhado

Embora as réplicas de 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 somente pelos nós dentro da FCI e não entre as réplicas do grupo de disponibilidade.
Soluções de armazenamento Conexão direta, rede SAN, pontos de montagem, SMB Depende do tipo de nó
Secundários legíveis Não* Sim
Configurações de política de failover aplicáveis Quorum WSFC

Específica da FCI

Configurações de grupo de disponibilidade**		 Quorum WSFC

Configurações de grupo de disponibilidade
Recursos que recebem failover Servidor, instância e banco de dados Apenas banco de dados

*Enquanto as réplicas secundárias síncronas em um grupo de disponibilidade sempre estão em execução em suas respectivas instâncias do SQL Server , os nós secundários em uma FCI não iniciaram suas respectivas instâncias do SQL Server de fato 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, se a réplica de disponibilidade local estiver em execução como réplica secundária legível, o banco de dados será legível.

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

Observação

Para obter mais informações sobre o Número de nós em FCIs e nos Grupos de Disponibilidade Always On para edições diferentes do SQL Server, confira Recursos com Suporte nas Edições do SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).

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, é preciso garantir que os nós host do Windows Server 2008 atendem aos pré-requisitos e às restrições do AlwaysOn para FCIs (Instâncias de Cluster de Failover). Para obter mais informações, confira Pré-requisitos, Restrições e Recomendações para Grupos de Disponibilidade Always On (SQL Server).

SQL Server As FCIs (Instâncias de Cluster de Failover) não dão suporte ao failover automático por grupos de disponibilidade, de modo que qualquer réplica de disponibilidade que esteja hospedado por um 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 (instância de cluster de failover) 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 de WSFC oferece suporte à implantação de um grupo de disponibilidade se a FCI hospeda a réplica primária e a instância autônoma hospeda a réplica secundária.

Quando for escolher uma FCI para hospedar uma réplica de disponibilidade para determinado grupo de disponibilidade, assegure-se de que um failover da FCI não tenha a possibilidade de fazer com que um nó 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:

Marcel configura um WSFC com dois nós, NODE01 e NODE02. Ele instala uma instância de cluster de failover do SQL Server , fciInstance1, em NODE01 e NODE02 onde NODE01 é o proprietário atual de fciInstance1.
Em NODE02, Marcel instala outra instância do SQL Server, Instance3, que é uma instância autônoma.
Em NODE01, Marcel habilita a fciInstance1 para o Grupos de disponibilidade AlwaysOn. Em NODE02, ele habilita a Instance3 para o Grupos de disponibilidade AlwaysOn. Depois, ele configura um grupo de disponibilidade para qual a fciInstance1 hospeda a réplica primária e Instance3 hospeda a réplica secundária.
Em determinado momento, a fciInstance1 torna-se não disponível em NODE01, e o WSFC provoca o failover da fciInstance1 em 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 resolver o problema apresentado por este cenário, a instância autônoma, Instance3, deve residir em outro nó no mesmo WSFC de NODE01 e NODE02.

Para obter mais informações sobre FCIs do SQL Server, confira Instâncias do Cluster de Failover do Always On (SQL Server).

Restrições em relação ao uso do Gerenciador de Cluster de Failover do WSFC com grupos de disponibilidade

Não use o Gerenciador de Cluster de Failover para manipular grupos de disponibilidade, por exemplo:

  • Não adicione nem 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 proprietários possíveis e os 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 o failover de grupos de disponibilidade. O Gerenciador de Cluster de Failover não reconhece o status da sincronização das réplicas de disponibilidade, e isso pode resultar em um longo tempo de inatividade. Você deve usar o Transact-SQL ou o SQL Server Management Studio.

Aviso

Usando 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 ele seja colocado online no nó de destino. Um único nó de um cluster de failover não pode hospedar mais de uma réplica do mesmo grupo de disponibilidade. Para obter mais informações sobre como isso ocorre e como recuperar, veja no blog Réplica removida inesperadamente no grupo de disponibilidade.

Conteúdo relacionado

Consulte Também

Visão geral dos Grupos de Disponibilidade AlwaysOn (SQL Server)
Habilitar e desabilitar Grupos de Disponibilidade AlwaysOn (SQL Server)
Monitorar grupos de disponibilidade (Transact-SQL)
Instâncias do cluster de failover do AlwaysOn (SQL Server)