Partilhar via


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

Always On Grupos de Disponibilidade, a solução de alta disponibilidade e recuperação de desastre introduzida no SQL Server 2014, requer o WSFC (Clustering de Failover do Windows Server). Além disso, embora Always On grupos de disponibilidade não dependam de SQL Server clustering de failover, você pode usar uma FCI (instância de clustering de failover) para hospedar um réplica de disponibilidade para um grupo de disponibilidade. É importante saber a função de cada tecnologia 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 Always On conceitos de Grupos de Disponibilidade, consulte Visão geral dos grupos de disponibilidade AlwaysOn (SQL Server).

Windows Server Failover Clustering e grupos de disponibilidade

A implantação Always On grupos de disponibilidade requer um cluster WSFC (Clustering de Failover do Windows Server). Para ser habilitada para grupos de disponibilidade Always On, uma instância de SQL Server deve residir em um nó WSFC e o cluster WSFC e o nó 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 cluster do WSFC. A única exceção é que, embora tenha sido migrado para outro cluster WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

Always On grupos de disponibilidade dependem do cluster WSFC (Clustering de Failover do Windows) para monitorar e gerenciar as funções atuais das réplicas de disponibilidade que pertencem a um determinado grupo de disponibilidade e 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 cluster WSFC monitora este grupo de recursos para avaliar a integridade da réplica primária.

O quorum para grupos de disponibilidade Always On é baseado em todos os nós no cluster WSFC, independentemente de um determinado nó de cluster hospedar réplicas de disponibilidade. Ao contrário do espelhamento de banco de dados, não há nenhuma função de testemunha em Always On Grupos de Disponibilidade.

A integridade geral de um cluster WSFC é determinada pelos votos do quorum de nós no cluster. Se o cluster 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 cluster 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

Always On chaves do Registro de Grupos de Disponibilidade são subchaves do cluster WSFC. Se você excluir e recriar um cluster WSFC, deverá desabilitar e reabilitar o recurso grupos de disponibilidade Always On em cada instância do SQL Server que hospedou um réplica de disponibilidade no cluster WSFC original.

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

Migração entre clusters de Grupos de Disponibilidade AlwaysOn para atualização do sistema operacional

A partir do SQL Server 2012 SP1, Always On Grupos de Disponibilidade dão suporte à migração entre clusters de grupos de disponibilidade para implantações em um novo cluster WSFC (Clustering de Failover do Windows Server). Uma migração entre clusters move um grupo de disponibilidade ou um lote de grupos de disponibilidade para o novo cluster WSFC de destino, com tempo de inatividade mínimo. O processo de migração entre clusters permite manter os SLAs (contratos de nível de serviço) ao atualizar para um cluster do Windows Server 2012. SQL Server 2012 SP1 (ou uma versão posterior) deve ser instalado e habilitado para AlwaysOn no cluster WSFC de destino. O êxito de uma migração entre clusters depende do planejamento e preparação meticulosos do cluster WSFC de destino.

Para obter mais informações, consulte Migração entre clusters de grupos de disponibilidade AlwaysOn para atualização do sistema operacional.

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 clustering de failover junto com o cluster 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.

Always On grupos de disponibilidade 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 a seção "Pré-requisitos e restrições para usar 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 AlwaysOn (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 cluster WSFC Sim Sim
Nível de proteção Instância Banco de dados
Tipo de armazenamento Compartilhada Não compartilhado

Observe que, 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 Clustering de Failover e Grupos de Disponibilidade AlwaysOn para diferentes edições do SQL Server, consulte Recursos compatíveis com as 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 atendam aos pré-requisitos e às restrições do AlwaysOn 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 AlwaysOn (SQL Server).

As FCIs (Instâncias de cluster de failover) do SQL Server 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 cluster WSFC (Windows Server Failover Clustering) para incluir discos compartilhados que não estão disponíveis em todos os nós. Por exemplo, considere um cluster WSFC em dois centros de dados com três nós. Dois dos nós hospedam uma FCI (instância de clustering 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 cluster 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 cluster 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.
No NODE01, Marcel habilita fciInstance1 para grupos de disponibilidade Always On. Em NODE02, ele habilita para Always On Grupos Instance3 de Disponibilidade. 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 disponível em NODE01e o cluster WSFC provoca o failover da fciInstance1 em NODE02. Após o failover, fciInstance1 é uma instância habilitada para grupos de disponibilidade do Always On em execução na função primária em NODE02. No entanto, agora a Instance3 reside no mesmo nó WSFC da fciInstance1. Isso viola a restrição Always On grupos de disponibilidade.
Para resolver o problema apresentado por este cenário, a instância autônoma, Instance3, deve residir em outro nó no mesmo cluster WSFC de NODE01 e NODE02.

Para obter mais informações sobre SQL Server clustering de failover, consulte Instâncias de cluster de failover alwayson (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.

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 de cluster de failover do AlwaysOn (SQL Server)