Partilhar via

Clusters de Failover do Windows Server com SQL Server

Aplica-se a:SQL Server

Este artigo apresenta uma visão geral da utilização de um Cluster de Failover Windows Server (WSFC) com SQL Server para alta disponibilidade e recuperação de desastres. Um Cluster de Failover do Windows Server (WSFC) é um grupo de servidores independentes que trabalham em conjunto para aumentar a disponibilidade de aplicações e serviços. O SQL Server aproveita os serviços e capacidades do WSFC para suportar grupos de disponibilidade Always On e instâncias de cluster de failover SQL Server.

Termos e definições

Cluster de Failover do Windows Server (WSFC) Um WSFC é um grupo de servidores independentes que trabalham em conjunto para aumentar a disponibilidade de aplicações e serviços.

Node
Um servidor que participa num WSFC.

Recurso do cluster
Uma entidade física ou lógica que pode ser possuída por um nó, ativada e desativada, movida entre nós e gerida como um objeto de cluster. Um recurso de cluster pode ser propriedade de apenas um único nó em qualquer momento.

Funções
Uma coleção de recursos de cluster geridos como um único objeto de cluster para fornecer funcionalidades específicas. Para o SQL Server, um papel será um grupo de disponibilidade Always On (AG) ou uma instância de cluster de failover Always On (FCI). Uma função contém todos os recursos do cluster necessários para um AG ou FCI. Failover e failback funcionam sempre no contexto das funções. Para uma FCI, o papel contém um recurso de endereço IP, um recurso de nome de rede e os recursos SQL Server. Uma função AG contém o recurso AG; e, se estiver configurado um ouvinte, um nome de rede e um recurso IP.

Recurso de nomes de rede
Um nome lógico de servidor que é gerido como um recurso de cluster. Um recurso de nome de rede deve ser usado com um recurso de endereço IP. Estas entradas podem requerer objetos nos Serviços de Domínio do Active Directory e/ou DNS.

Dependência de recursos
Um recurso do qual depende outro recurso. Se o recurso A depende do recurso B, então B é uma dependência de A. O recurso A não poderá começar sem o recurso B.

Proprietário preferencial
Um nó no qual um grupo de recursos prefere executar. Cada grupo de recursos está associado a uma lista de proprietários preferenciais ordenados por ordem de preferência. Durante o failover automático, o grupo de recursos é movido para o próximo nó preferencial na lista de proprietários preferidos.

Possível proprietário
Um nó secundário onde um recurso pode executar. Cada grupo de recursos está associado a uma lista de possíveis proprietários. As funções só podem ser transferidas para nós que estão listados como possíveis proprietários.

Modo quórum
A configuração de quórum num cluster de failover determina o número de falhas de nós que o cluster pode suportar.

Forçar quórum
O processo para iniciar o agrupamento, mesmo que apenas uma minoria dos elementos necessários para o quórum esteja em comunicação.

Visão Geral do Cluster de Failover do Windows Server

O Windows Server Failover Clustering fornece funcionalidades de infraestrutura que suportam os cenários de alta disponibilidade e recuperação de desastres de aplicações de servidor alojadas, como Microsoft SQL Server e Microsoft Exchange. Se um nó ou serviço do cluster falhar, os serviços que estavam alojados nesse nó podem ser transferidos automática ou manualmente para outro nó disponível num processo conhecido como failover.

Os nós numa WSFC trabalham em conjunto para fornecer coletivamente estes tipos de capacidades:

  • Metadados e notificações distribuídos. Os metadados do serviço WSFC e da aplicação alojada são mantidos em cada nó do cluster. Estes metadados incluem a configuração e o estado do WSFC, além das definições da aplicação alojada. Alterações aos metadados ou ao estado de um nó são automaticamente propagadas para os outros nós do WSFC.

  • Gestão de recursos. Nódulos individuais no WSFC podem fornecer recursos físicos, tais como armazenamento de ligação direta, interfaces de rede e acesso a armazenamento em disco partilhado. As aplicações alojadas registam-se como um recurso de cluster e podem configurar dependências de arranque e de saúde sobre outros recursos.

  • Monitorização da saúde. A detecção de saúde entre nós e o nó primário é realizada através de uma combinação de comunicações de rede em estilo batimento cardíaco e monitorização de recursos. A saúde geral da WSFC é determinada pelos votos de um quórum de nós na WSFC.

  • Coordenação por failover. Cada recurso está configurado para ser alojado num nó primário, e cada um pode ser transferido automática ou manualmente para um ou mais nós secundários. Uma política de failover baseada na saúde do sistema controla a transferência automática de propriedade de recursos entre nós. Os nós e aplicações alojadas são notificados quando ocorre failover para que possam reagir adequadamente.

Para mais informações, consulte: Failover Clustering Overview - Windows Server.

Tecnologias SQL Server Always On e WSFC

O SQL Server Always On é uma solução de alta disponibilidade e recuperação de desastres que tira partido do WSFC. As funcionalidades Always On fornecem soluções integradas e flexíveis que aumentam a disponibilidade das aplicações, proporcionam melhores retornos sobre investimentos em hardware e simplificam a implementação e gestão de alta disponibilidade.

Tanto os grupos de disponibilidade Always On como as instâncias de cluster de failover Always On utilizam a WSFC como tecnologia de plataforma, registando componentes como recursos do cluster WSFC. Recursos relacionados são combinados numa função, que pode ser configurada para depender de outros recursos do cluster WSFC. O WSFC pode então detectar e sinalizar a necessidade de reiniciar a instância do SQL Server ou de passá-la automaticamente para outro nó de servidor dentro do WSFC.

Importante

Para tirar pleno proveito das tecnologias SQL Server Always On, deve aplicar vários pré-requisitos relacionados com o WSFC.

Para obter mais informações, consulte: Pré-requisitos, Restrições e Recomendações para grupos de disponibilidade Sempre On.

Alta disponibilidade ao nível da instância com instâncias de cluster de failover Always On

Uma instância de failover cluster Always On (FCI) é uma instância do SQL Server que é instalada entre vários nós em um WSFC. Este tipo de instância depende de recursos para armazenamento e nome de rede virtual. O armazenamento pode usar Fibre Channel, iSCSI, FCoE ou SAS para armazenamento partilhado em disco, ou usar armazenamento localmente ligado com Storage Spaces Direct (S2D). O recurso de nome da rede virtual depende de um ou mais endereços IP virtuais, cada um numa sub-rede diferente. O serviço SQL Server e o serviço SQL Server Agent também são recursos, e ambos dependem dos recursos de armazenamento e de nomes de rede virtual.

No caso de um failover, o serviço WSFC transfere a propriedade dos recursos da instância para um nó de failover designado. A instância do SQL Server é então reiniciada no nó de failover, e as bases de dados são recuperadas normalmente. A qualquer momento, apenas um único nó no cluster pode hospedar a FCI e os recursos subjacentes.

Observação

Uma instância de cluster de failover Always On requer armazenamento partilhado em disco simétrico, como uma rede de área de armazenamento (SAN) ou partilha de ficheiros SMB. Os volumes partilhados de armazenamento em disco devem estar disponíveis para todos os potenciais nós de failover no cluster WSFC.

Para mais informações, veja: Instâncias de cluster de failover Always On.

Disponibilidade elevada ao nível da base de dados com Grupos de Disponibilidade Always On

Um grupo de disponibilidade Sempre Ligado (AG) é um agrupamento de uma ou mais bases de dados de utilizadores que fazem failover em conjunto. Um grupo de disponibilidade consiste numa réplica primária de disponibilidade e de uma a quatro réplicas secundárias que são mantidas através da movimentação de dados baseada em registo do SQL Server para proteção de dados sem necessidade de armazenamento partilhado. Cada réplica é hospedada por uma instância do SQL Server em um nó diferente do WSFC. O grupo de disponibilidade e um nome de rede virtual correspondente são registrados como recursos no cluster WSFC.

Um ouvinte de grupo de disponibilidade no nó da réplica primária responde a pedidos recebidos do cliente para se ligar ao nome da rede virtual e, com base nos atributos da cadeia de ligação, redireciona cada pedido para a instância SQL Server apropriada.

No caso de um failover, em vez de transferir a propriedade dos recursos físicos partilhados para outro nó, o WSFC é usado para reconfigurar uma réplica secundária noutra instância do SQL Server para se tornar a réplica principal do grupo de disponibilidade. O recurso de nome de rede virtual do grupo de disponibilidade é então transferido para essa instância.

Em qualquer momento, apenas uma única instância do SQL Server pode hospedar a réplica principal das bases de dados de um grupo de disponibilidade, todas as réplicas secundárias associadas devem residir numa instância separada, e cada instância deve residir em nós físicos separados.

Observação

Os grupos de disponibilidade Always On não exigem a implementação de uma instância de cluster de failover nem a utilização de armazenamento partilhado simétrico (SAN ou SMB).

Uma instância de cluster de failover (FCI) pode ser usada juntamente com um grupo de alta disponibilidade para melhorar a disponibilidade de uma réplica de alta disponibilidade. No entanto, para evitar condições de corrida potenciais no cluster WSFC, o failover automático do grupo de disponibilidade não é suportado nem para uma réplica de disponibilidade alojada num Failover Cluster Instance (FCI), nem a partir dela.

Para mais informações, veja: Visão geral dos grupos de disponibilidade Always On.

Monitorização da saúde e failover do WSFC

A elevada disponibilidade para uma solução Always On é alcançada através da monitorização proativa da saúde dos recursos físicos e lógicos do cluster WSFC, juntamente com failover automático e reconfiguração de hardware redundante. Um administrador de sistemas pode também iniciar um failover manual de um grupo de disponibilidade ou instância do SQL Server de um nó para outro.

Políticas de failover (tolerância a falhas) para nós, instâncias de clusters de failover e grupos de disponibilidade

Uma política de failover é configurada ao nível do nó WSFC, da instância do cluster de failover SQL Server (FCI) e do grupo de disponibilidade. Estas políticas, baseadas na gravidade, duração e frequência do estado insalubre dos recursos do cluster e da resposta dos nós, podem desencadear um reinício do serviço ou um failover automático dos recursos do cluster de um nó para outro, ou podem desencadear a transferência de uma réplica primária de grupo de disponibilidade de uma instância SQL Server para outra.

O failover de uma réplica de grupo de disponibilidade não afeta a instância subjacente do SQL Server. O failover de uma FCI move as réplicas do grupo de disponibilidade hospedadas com a instância.

Para mais informações, veja: Política de failover para instâncias de clusters de failover.

Deteção de saúde de recursos da WSFC

Cada recurso numa WSFC pode reportar o seu estado e estado de saúde, periodicamente ou sob demanda. Várias circunstâncias podem indicar falha de recursos; por exemplo, falha de energia, erros de disco ou memória, erros de comunicação de rede ou serviços não responsivos.

Os recursos da WSFC, como redes, armazenamento ou serviços, podem ser tornados dependentes uns dos outros. A saúde acumulada de um recurso é determinada pela integração sucessiva da sua saúde com a saúde de cada uma das suas dependências de recurso.

Deteção de integridade entre os nós da WSFC e votação em quórum

Cada nó numa WSFC participa na comunicação periódica dos batimentos cardíacos para partilhar o estado de saúde do nó com os outros nós. Nódulos não responsivos são considerados em estado falhado.

O quórum é um mecanismo que ajuda a garantir que o WSFC está operacional, assegurando que há recursos suficientes disponíveis no WSFC. Se o WSFC tiver votos suficientes, é saudável e capaz de fornecer tolerância a falhas ao nível dos nós.

Está configurado no WSFC um modo quórum que dita a metodologia usada para a votação do quórum e quando realizar um failover automático ou desligar o cluster.

Sugestão

É uma boa prática ter sempre um número ímpar de votos de quórum numa WSFC. Para efeitos de votação de quórum, o SQL Server não tem de ser instalado em todos os nós do cluster. Um servidor adicional pode atuar como membro do quórum, ou o modelo de quórum da WSFC pode ser configurado para usar uma partilha remota de ficheiros como critério de desempate.

Para mais informações, consulte: Modos de Quórum e Configuração de Votação da WSFC.

Recuperação de desastres através da imposição de quórum

Dependendo das práticas operacionais e da configuração do WSFC, pode incorrer em failovers automáticos e manuais, mantendo ainda assim uma solução SQL Server Always On robusta e tolerante a falhas. No entanto, se um quórum dos nós com direito a voto no WSFC não conseguir comunicar entre si, ou se o cluster do WSFC falhar na validação de integridade, então o WSFC poderá ficar offline.

Se o WSFC ficar offline devido a um desastre não planeado, ou devido a uma falha persistente de hardware ou comunicações, então é necessária intervenção administrativa manual para forçar o quórum e reativar os nós sobreviventes do cluster numa configuração não tolerante a falhas.

Posteriormente, é necessário seguir uma série de passos para reconfigurar a WSFC, recuperar as réplicas da base de dados afetadas e restabelecer um novo quórum.

Para mais informações, veja: WSFC Recuperação de Desastres através do Quórum Forçado.

Relação dos componentes SQL Server Always On com o WSFC

Existem várias camadas de relações entre o SQL Server Always On e as funcionalidades e componentes do WSFC.

Os grupos de disponibilidade Always On são alojados em instâncias do SQL Server.
Um pedido de cliente que especifica um nome lógico de rede de ouvinte de um grupo de disponibilidade para se conectar a uma base de dados primária ou secundária é redirecionado para o nome de rede apropriado da instância SQL Server subjacente ou do SQL Server FCI.

As instâncias do SQL Server estão ativamente alojadas num único nó.
Se presente, uma Instância SQL Server autónoma reside sempre num único Nó com um nome de rede de instância estático. Se presente, uma FCI do SQL Server está ativa num dos dois ou mais nós de failover possíveis com um único Nome de Rede de Instância virtual.

Os nós são membros de um cluster WSFC.
Os metadados de configuração e o estado do WSFC para todos os nós são armazenados em cada nó. Cada servidor pode fornecer volumes de armazenamento assimétrico ou armazenamento partilhado (SAN) para bases de dados de utilizadores ou do sistema. Cada servidor tem pelo menos uma interface física de rede numa ou mais subredes IP.

O WSFC monitoriza a saúde e gere a configuração de um grupo de servidores.
Os mecanismos da WSFC propagam alterações nos metadados e estados da configuração da WSFC para todos os nós da WSFC. Se for usada uma testemunha de disco, os metadados também são armazenados aí. Por defeito, cada nó da WSFC tem direito a um voto para o quórum e uma testemunha será usada se necessário e estiver configurada.

As chaves de registo dos grupos de disponibilidade Always On são subchaves do cluster WSFC.

Se eliminar e recriar um WSFC, deve desativar e reativar a funcionalidade de grupos de disponibilidade Always On em cada instância de servidor que estava ativada para os grupos de disponibilidade Always On no WSFC original. Para mais informações, consulte Ativar e Desativar grupos de disponibilidade Always On.

Captura de ecrã do cluster de failover do Windows Server.

Tarefas relacionadas

Conteúdo relacionado

  • Last updated on