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

Artigo
08/27/2013

O Grupos de Disponibilidade AlwaysOn, a solução de alta disponibilidade e recuperação de desastre incorporada no SQL Server 2012, 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 Grupos de Disponibilidade AlwaysOn, consulte Visão geral de grupos de disponibilidade AlwaysOn (SQL Server).

Neste tópico:

Windows Server Failover Clustering
Clustering de failover do SQL Server
Restrições em relação ao uso do Gerenciador de Cluster de Failover do WSFC com grupos de disponibilidade

Windows Server Failover Clustering e grupos de disponibilidade

A implantação do Grupos de Disponibilidade AlwaysOn exige um cluster do WSFC (Windows Server Failover Clustering). 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 cluster 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 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.

O Grupos de Disponibilidade AlwaysOn conta com o cluster WSFC (Windows Failover Clustering) 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 cluster 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 cluster 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 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
As chaves do Registro de Grupos de Disponibilidade AlwaysOn são subchaves do cluster WSFC. Se você excluir e recriar um cluster 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 cluster WSFC original.

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

Ícone de seta usado com o link Voltar ao Início [Início]

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

A partir do SQL Server 2012 SP1, o recurso Grupos de Disponibilidade AlwaysOn dá suporte à migração entre clusters de grupos de disponibilidade para implantações em um novo cluster WSFC (Windows Server Failover Clustering). 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 contratos de nível de serviço ao atualizar para um cluster do Windows Server 2012. O 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 dos grupos de disponibilidade AlwaysOn para atualização do sistema operacional.

Instâncias de cluster de failover (FCIs) 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 clustering de failover do SQL Server 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.

O 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 pré-requisitos adicionais, consulte a seção "Pré-requisitos e restrições para usar uma instância de cluster de failover do SQL Server (FCI) 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	Compartilhado	Não compartilhado1
Soluções de armazenamento	Conexão direta, rede SAN, pontos de montagem, SMB	Depende do tipo de nó
Secundários legíveis	Não2	Sim
Configurações de política de failover aplicáveis	Quorum WSFC Específica da FCI Configurações de grupo de disponibilidade3	Quorum WSFC Configurações de grupo de disponibilidade
Recursos que recebem failover	Servidor, instância e banco de dados	Somente banco de dados

1Embora 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.

2Enquanto 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.

3As 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 número de nós no Clustering de Failover e grupos de disponibilidade AlwaysOn para edições diferentes 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).

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.
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 disponível em NODE01 e o cluster WSFC provoca o failover da fciInstance1 em NODE02. Após o failover, fciInstance1 torna-se uma instância habilitada para o Grupos de Disponibilidade AlwaysOn executada 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 cluster WSFC de NODE01 e NODE02.

Para obter mais informações sobre clustering de failover do SQL Server, consulte Instâncias de cluster de failover do AlwaysOn (SQL Server).

Ícone de seta usado com o link Voltar ao Início [Início]

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) do grupo de disponibilidade.
Não altere nenhuma propriedade de 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 os grupos de disponibilidade para outros nós ou fazer o failover dos grupos de disponibilidade. O Gerenciador de Cluster de Failover não reconhece o status de sincronização das réplicas de disponibilidade, e isso pode levar a um longo tempo de inatividade. Você deve usar Transact-SQL ou SQL Server Management Studio.

Ícone de seta usado com o link Voltar ao Início [Início]