Instâncias de Always On Failover Cluster (SQL Server)

Como parte da oferta Always On do SQL Server, as Instâncias de Cluster de Failover Always On aproveitam a funcionalidade do Windows Server Failover Clustering (WSFC) para fornecer alta disponibilidade local por meio da redundância no nível da instância do servidor — uma instância de cluster de failover (FCI). Uma FCI é uma única instância do SQL Server instalada em nós do WSFC (Clustering de Failover) do Windows Server e, possivelmente, em várias sub-redes. Na rede, uma Instância de Cluster de Failover (FCI) aparenta ser uma instância do SQL Server em funcionamento em um único computador. No entanto, a FCI permite alternância de um nó do Cluster de Failover do Windows Server (WSFC) para outro, caso o nó atual se torne indisponível.

Uma FCI pode aproveitar os Grupos de Disponibilidade AlwaysOnpara fornecer recuperação remota de desastre no nível do banco de dados. Para obter mais informações, consulte Clustering de Failover e Grupos de Disponibilidade Sempre Ativo (SQL Server).

Neste tópico:

• Benefícios

• Recomendações

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

• Elementos de uma instância de cluster de failover

• Conceitos e tarefas de failover do SQL Server

• tópicos relacionados

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. Quando uma instância do SQL Server é configurada para ser uma FCI (em vez de uma instância autônoma), a alta disponibilidade dessa instância do SQL Server é protegida pela presença de nós redundantes na FCI. Somente um dos nós na FCI tem o grupo de recursos do WSFC de cada vez. Em caso de falha (falhas de hardware, falhas no sistema operacional, falhas de aplicativo ou serviço) ou uma atualização planejada, a propriedade do grupo de recursos é movida para outro nó WSFC. Esse processo é transparente para o cliente ou aplicativo que se conecta ao SQL Server e 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 no nível da instância através de redundância

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

  Importante

  Em um grupo de disponibilidade Always On, o failover automático de uma FCI para outros nós dentro do grupo de disponibilidade não é suportado. 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.

• Solução de recuperação de desastre usando uma FCI de várias sub-redes ou executando um banco de dados hospedado por FCI dentro de um grupo de disponibilidade Always On. Com o novo suporte a várias sub-redes no MicrosoftSQL Server 2012, uma FCI de várias sub-redes não requer mais 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 granular para failovers automáticos

• Mudanças automáticas para sistemas alternativos de maneira confiável através de detecção periódica e detalhada de integridade, usando conexões dedicadas e persistentes.

• Configurabilidade e previsibilidade no tempo de failover por meio de pontos de verificação indiretos em segundo plano

• Uso limitado de recursos durante failovers

Recomendações

Em um ambiente de produção, recomendamos que você use endereços IP estáticos junto com o endereço IP virtual de uma Instância de Cluster de Failover. É recomendável não usar o 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 do 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 ocorre um failover, seja um failover automático ou um failover planejado, a seguinte sequência de eventos acontece:

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 obter mais informações, consulte modos de quorum WSFC e configuração de 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, pode haver uma quantidade substancial de páginas sujas no cache de 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. A partir do MicrosoftSQL Server 2012, a FCI pode usar pontos de verificação indiretos para limitar a quantidade de páginas sujas mantidas no cache de 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 saúde confiável e política de reposição automática 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 . A partir do MicrosoftSQL Server 2012, o serviço WSFC usa uma conexão dedicada para sondar a instância ativa do SQL Server para diagnóstico detalhado de componente por meio de um procedimento armazenado do 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, consulte a Política de Failover para Instâncias de Cluster de Failover

Elementos de uma instância de failover cluster

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. Em caso de falha (falhas de hardware, falhas no sistema operacional, falhas de aplicativo ou serviço) ou uma atualização planejada, a propriedade do grupo de recursos é movida para outro nó na FCI. O número de nós com suporte em um grupo de recursos do WSFC depende da 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 Always On, uma FCI deve usar o armazenamento compartilhado entre todos os nós da FCI para o banco de dados e o armazenamento de logs. O armazenamento compartilhado pode estar na forma de discos de cluster WSFC, discos em uma SAN 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. Esse processo é transparente para o cliente ou aplicativo que se conecta ao SQL Server e isso minimiza o tempo de inatividade que o aplicativo ou os clientes experimentam 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