Partilhar via

Grupos de Disponibilidade Always On e Agrupamento de Failover (SQL Server)

  • Artigo

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 Clustering 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 Overview of Always On Availability Groups (SQL Server).

Clusters 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 existe função 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 Windows Server Failover Clustering (WSFC) 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 réplica de disponibilidade pode ser hospedada por uma instância autônoma do SQL Server ou por uma instância FCI. 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 a seção "Pré-requisitos e restrições para usar uma Instância de Cluster de Failover (FCI) 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, 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, se a réplica de disponibilidade local estiver sendo executada como uma réplica secundária legível, o banco de dados será legível.

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

Observação

Para obter mais informações sobre Número de nós dentro de FCIs e de Grupos de Disponibilidade Always On para diferentes edições do SQL Server, consulte 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 o/a leitor(a) planeia hospedar uma réplica de disponibilidade numa Instância de Cluster de Failover (FCI) do SQL Server, verifique se os nós de host do Windows Server 2008 cumprem os pré-requisitos e restrições do Always On para Instâncias de Cluster de Failover (FCIs). 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 hospedada por uma FCI só pode ser configurada para failover manual.

Pode ser necessário configurar um WSFC para incluir discos partilhados 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 (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 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, 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 no NODE01e o WSFC aciona 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 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 ou remova recursos no serviço clusterizado (grupo de recursos) para o grupo de disponibilidade.

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

  • Não use o Gestor de Cluster de Failover para mover grupos de disponibilidade para nós diferentes ou para realizar o 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 de hospedar um grupo de disponibilidade para um nó que já hospedar 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.

Conteúdo relacionado

Ver também

Visão geral dos grupos de disponibilidade Always On (SQL Server)
Habilitar e desabilitar grupos de disponibilidade Always On (SQL Server)
Monitorar grupos de disponibilidade (Transact-SQL)
Instâncias de Cluster de Failover Sempre Ativas (SQL Server)