Instâncias de cluster de failover Always On (SQL Server)

Aplica-se a: SQL Server

As instâncias de cluster de failover Always On do SQL Server usam o WSFC (Clustering de Failover do Windows Server) para fornecer alta disponibilidade local. Uma FCI (instância de cluster de failover) é redundante no nível da instância do servidor. Uma FCI é uma instância única do SQL Server que é instalada em nós do cluster de servidores do Windows e, possivelmente, em múltiplas sub-redes. Na rede, uma FCI aparece como uma instância do SQL Server em execução em um único computador, mas proporciona failover de um nó do WSFC para outro se o nó atual ficar não disponível.

Uma FCI pode usar os grupos de disponibilidade Always On para fornecer recuperação de desastres remota no nível do banco de dados. Para obter mais informações, confira Clustering de failover e grupos de disponibilidade (SQL Server).

Benefícios de uma instância de cluster de failover

Quando há falha de hardware ou de software de um servidor, os aplicativos ou clientes que conectam ao servidor enfrentam um tempo de inatividade. Os nós redundantes protegem a disponibilidade da instância do SQL Server quando ela é uma FCI em vez de uma instância autônoma. Somente um dos nós na FCI tem o grupo de recursos do WSFC de cada vez. No caso de uma falha (falhas de hardware, falhas de sistema operacional, aplicativo ou falhas de serviço) ou de uma atualização planejada, o cluster move a propriedade do grupo de recursos para outro nó do WSFC. Esse processo é transparente para o cliente ou aplicativo que se conecta ao SQL Server. Isso minimiza o tempo de inatividade que o aplicativo ou os clientes experimentam durante uma falha. Alguns dos principais benefícios que instâncias de cluster de failover do SQL Server oferecem:

• Proteção em nível de instância por redundância.

• Failover automático no evento de uma falha (falhas de hardware, falhas de sistema operacional, aplicativo ou falhas de serviço).

  Importante

  Em um grupo de disponibilidade, não há suporte para o failover automático de uma FCI para outros nós dentro do grupo de disponibilidade. Isto significa que os nós das FCIs e autônomos não deverão ser acoplados dentro de um grupo de disponibilidade se o failover automático for um componente importante de sua solução de alta disponibilidade. Porém, este acoplamento pode ser feito para sua solução de recuperação de desastres .

• Suporte para uma matriz ampla de soluções de armazenamento, inclusive discos de cluster do WSFC (iSCSI, Fiber Channel e assim por diante) e compartilhamentos de arquivos de protocolo SMB.

• Recuperação de desastres usando uma FCI de várias sub-redes ou executando um banco de dados hospedado por FCI dentro de um grupo de disponibilidade. Com o novo suporte a várias sub-redes no Microsoft SQL Server 2012 (11.x), uma FCI de várias sub-redes não mais exigirá uma LAN virtual, aumentando a capacidade de gerenciamento e a segurança de uma FCI de várias sub-redes.

• Reconfiguração zero de aplicativos e clientes durante failovers.

• Política de failover flexível para eventos de gatilho granulares para failovers automáticos.

• Failovers confiáveis por meio de detecção de integridade periódica e detalhada usando conexões dedicadas e persistentes.

• Capacidade de configuração e previsibilidade de tempo de failover por meio de pontos de verificação indiretos em segundo plano.

• Uso restrito de recurso durante failovers.

Recomendações

Em um ambiente de produção:

• Use endereços IP estáticos juntamente com o endereço IP virtual de uma instância de cluster de failover.
• Não use DHCP em um ambiente de produção. No caso de tempo de inatividade, se a concessão do IP DHCP expirar, será necessário tempo adicional para registrar novamente o endereço IP DHCP novo associado ao nome DNS.

Visão geral da instância de cluster de failover

Uma FCI é executada em um grupo de recursos do WSFC com um ou mais nós do WSFC. Quando a FCI é iniciada, um dos nós assume a propriedade do grupo de recursos e coloca sua instância do SQL Server online. Os recursos de propriedade deste nó incluem:

• Nome da rede

• Endereço IP

• Discos compartilhados

• SQL Server Serviço do Mecanismo de Banco de Dados

• SQL Server Agent

• SQL Server Analysis Services, se estiver instalado

• Um recurso de compartilhamento de arquivos, se o recurso FILESTREAM estiver instalado

A qualquer momento, somente o proprietário do grupo de recursos (e nenhum outro nó na FCI) está executando os respectivos serviços do SQL Server no grupo de recursos. Quando um failover ocorrer, se for um failover automático ou um failover planejado, esta sequência de eventos acontecerá:

1. A menos que ocorra uma falha de hardware ou de sistema, todas as páginas sujas no cache do buffer serão gravadas no disco.

2. Todos os respectivos serviços do SQL Server no grupo de recursos são parados no nó ativo.

3. A propriedade de grupo de recursos é transferida para outro nó na FCI.

4. O novo proprietário do grupo de recursos inicia seus serviços do SQL Server .

5. As solicitações de conexão de aplicativo cliente são automaticamente direcionadas para o novo nó ativo usando o mesmo VNN (nome de rede virtual).

A FCI fica online contanto que seu cluster WSFC subjacente esteja com boa integridade de quorum (a maioria dos nós do quorum WSFC estão disponíveis como destinos de failover automáticos). Quando o cluster do WSFC perde seu quorum, devido a falha de hardware, software, rede ou configuração de quorum imprópria, o cluster do WSFC inteiro, junto com o FCI, é colocado offline. É necessário realizar uma intervenção manual neste cenário de failover não planejado para restabelecer o quorum nos nós disponíveis restantes para colocar o cluster do WSFC e da FCI online novamente. Para saber mais, consulte Configuração de modos de quorum WSFC e votação (SQL Server).

Tempo de failover previsível

Dependendo de quando sua instância do SQL Server executou uma operação de ponto de verificação pela última vez, poderá haver um número significativo de páginas sujas no cache do buffer. Por consequência, os failovers duram o suficiente para gravar as páginas sujas restantes no disco, o que pode levar a um tempo de failover longo e imprevisível. Do Microsoft SQL Server 2012 (11.x) em diante, a FCI pode usar pontos de verificação indiretos para limitar o número de páginas sujas mantidas no cache do buffer. Embora consuma recursos adicionais sob carga de trabalho normal, isto torna o failover mais previsível e também mais configurável. Isto é muito útil quando o acordo do nível de serviço em sua organização especifica o RTO (objetivo de tempo de recuperação) para sua solução de alta disponibilidade. Para obter mais informações sobre pontos de verificação indiretos, consulte Indirect Checkpoints.

Monitoramento de integridade confiável e política de failover flexível

Depois que a FCI é iniciada com sucesso, o serviço do WSFC monitora a integridade do cluster do WSFC subjacente e também a integridade da instância do SQL Server . Do Microsoft SQL Server 2012 (11.x) em diante, o serviço do WSFC usa uma conexão dedicada para sondar a instância do SQL Server ativa em busca de diagnóstico de componente detalhados por meio de um procedimento armazenado de sistema. São três implicações:

• A conexão dedicada para a instância do SQL Server possibilita sondar diagnóstico de componente com confiança o tempo todo, mesmo quando a FCI está sob carga pesada. Isto possibilita distinguir entre um sistema que está sob carga pesada e um sistema que de fato tem condições de falha, impedindo, portanto, problemas como falsos failovers.

• Os diagnóstico de componente detalhado possibilita configurar uma política de failover mais flexível, por meio da qual você pode escolher quais condições de falha acionam failovers e quais condições de falha não acionam.

• O diagnóstico de componente detalhado também permite uma melhor solução de problemas de failovers automáticos retroativamente. As informações de diagnóstico são armazenadas em arquivos de log que são colocados com os logs de erros do SQL Server . Você pode carregá-los no Visualizador do Arquivo de Log para inspecionar os estados do componente que levam até a ocorrência de failover para determinar o que causa o failover.

Para obter mais informações, confira Política de failover para instâncias de cluster de failover

Elementos de uma instância de cluster de failover

Uma FCI consiste em um conjunto de servidores físicos (nós) que contêm configuração de hardware semelhante e também configuração de software idêntica, que inclui versão de sistema operacional e nível de patch e versão do SQL Server , nível de patch, componentes e nome de instância. A configuração de software idêntica é necessária para assegurar que a FCI possa ser completamente funcional porque ocorre o failover entre os nós.

Grupo de recursos do WSFC
Uma FCI do SQL Server é executada em um grupo de recursos do WSFC. Cada nó no grupo de recursos mantém uma cópia sincronizada dos parâmetros de configuração e chave do Registro como pontos de verificação para assegurar a funcionalidade completa da FCI depois de um failover e somente um dos nós no cluster possui o grupo de recursos de cada vez (o nó ativo). O serviço do WSFC gerencia o cluster de servidores, a configuração de quorum, a política de failover e as operações de failover, assim como os endereços de VNN e IP virtuais para a FCI. No caso de uma falha (no hardware, sistema operacional, aplicativo ou serviço) ou de uma atualização planejada, a propriedade do grupo de recursos é movida para outro nó do FCI. O número de nós que têm suporte em um grupo de recursos do WSFC depende da sua edição do SQL Server. Além disso, o mesmo cluster do WSFC pode executar várias FCIs (vários grupos de recursos), dependendo de sua capacidade de hardware, como CPUs, memória e número de discos.

Binários do SQL Server
Os binários de produto são instalados localmente em cada nó da FCI, um processo semelhante a instalações autônomas do SQL Server . Porém, durante a inicialização, os serviços não são iniciados automaticamente, mas são gerenciados pelo WSFC.

Armazenamento
Ao contrário do grupo de disponibilidade, uma FCI deve usar armazenamento compartilhado entre todos os nós da FCI para o armazenamento do banco de dados e do log. O armazenamento compartilhado pode ser na forma de discos de cluster do WSFC, discos em uma rede SAN, S2D (Espaços de Armazenamento Diretos) ou compartilhamentos de arquivos em um SMB. Deste modo, todos os nós na FCI têm a mesma exibição dos dados de instância sempre que um failover ocorre. No entanto, isto significa que o armazenamento compartilhado tem o potencial de ser o único ponto de falha, e a FCI depende da solução de armazenamento subjacente para assegurar a proteção de dados.

Nome da rede
O VNN para a FCI fornece um ponto de conexão unificado para a FCI. Isto permite que aplicativos conectem-se ao VNN sem a necessidade de conhecer o nó ativo atualmente. Quando um failover ocorre, o VNN é registrado para o novo nó ativo depois de iniciar. Este processo é transparente ao cliente ou aplicativo que se conecta ao SQL Server e isso minimiza o tempo de inatividade pelo qual passa o aplicativo ou os clientes durante uma falha.

IP virtuais
No caso de uma FCI de várias sub-redes, um endereço IP virtual é atribuído a cada sub-rede na FCI. Durante um failover, o VNN no servidor DNS é atualizado para apontar para o endereço IP virtual para a respectiva sub-rede. Aplicativos e clientes podem então se conectar ao FCI usando o mesmo VNN depois de um failover de várias sub-redes.

Conceitos e tarefas de failover do SQL Server

Tópicos relacionados