Exportar (0) Imprimir
Expandir Tudo
Este artigo foi traduzido manualmente. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Tradução
Original

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

O Grupos de Disponibilidade AlwaysOn, a solução de alta disponibilidade e recuperação de desastre incorporada no SQL Server 2014, 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 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:

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.

Observação importante 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 de grupos de disponibilidade AlwaysOn para atualização do sistema operacional.

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

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

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

3 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 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 (http://go.microsoft.com/fwlink/?linkid=232473).

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

Observação importante 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.
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]

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 Transact-SQL ou SQL Server Management Studio.

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

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2014 Microsoft