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

Aplica-se: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 instância de cluster de failover (FCI) é redundante no nível da instância de servidor. Uma FCI é uma única instância do SQL Server instalada em nós de cluster do Windows Server e, possivelmente, em várias sub-redes. Na rede, um FCI aparece como uma instância do SQL Server em execução em um único computador, mas o FCI permite o failover de um nó do WSFC para outro se o nó atual ficar indisponí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, consulte cluster de failover e grupos de disponibilidade Always On (SQL Server).

As instâncias de cluster de failover do SQL Server oferecem suporte a Espaços de Armazenamento Diretos para recursos de armazenamento de cluster, recurso introduzido na edição Datacenter do Windows Server 2016. Para obter mais informações, confira Espaços de Armazenamento Diretos no Windows Server.

As instâncias de cluster de failover também oferecem suporte a CSV (Volumes Compartilhados de Cluster). Para obter mais informações, consulte Noções básicas sobre volumes compartilhados de cluster em um cluster de failover.

Vantagens das instâncias de cluster de failover

Quando ocorre uma falha de hardware ou software no servidor, os aplicativos ou clientes que se conectam ao servidor sofrem indisponibilidade. 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. Se ocorrer uma falha (como falha de hardware, falha do sistema operacional, falha de aplicativo ou serviço) ou durante uma atualização planejada, o cluster moverá a propriedade do grupo de recursos para outro nó WSFC. Esse processo é transparente para o cliente ou aplicativo que se conecta ao SQL Server. O processo minimiza o tempo de inatividade que o aplicativo ou os clientes experimentam durante uma falha. Aqui estão alguns dos principais benefícios que as instâncias de cluster de failover do SQL Server fornecem:

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

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

  Importante

  Em um grupo de disponibilidade, não há suporte para failover automático de uma FCI para outros nós no grupo de disponibilidade. Portanto, FCIs e nós independentes não devem ser combinados dentro de um grupo de disponibilidade se o failover automático for um componente importante da 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 ampla variedade de soluções de armazenamento, incluindo discos de cluster WSFC (iSCSI, Fibre Channel e assim por diante) e compartilhamentos de arquivos SMB (Server Message Block).

• Recuperação de desastres via uma FCI com várias sub-redes ou execução de um banco de dados hospedado em FCI dentro de um grupo de disponibilidade. Com o suporte a várias sub-redes no SQL Server 2012 (11.x), uma FCI de várias sub-redes não requer uma LAN virtual. Esse suporte aumenta 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 da verificação de integridade periódica e detalhada 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, use endereços IP estáticos em conjunto 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 de IP DHCP expirar, será necessário tempo extra para registrar novamente o novo endereço IP DHCP 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
• Serviço do Mecanismo de Banco de Dados do SQL Server
• serviço SQL Server Agent
• Serviço do SQL Server Analysis Services, se ele 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 do grupo de recursos é transferida para outro nó no 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 direcionadas automaticamente para o novo nó ativo usando o mesmo nome de rede virtual.

A FCI permanece online enquanto seu cluster WSFC subjacente estiver com o quorum íntegro. (A maioria dos nós do quorum do WSFC está disponível como destinos para failover automático.) Quando o cluster WSFC perde o quorum, seja por falha de hardware, software ou rede, ou por configuração inadequada do quorum, todo o cluster WSFC, juntamente com a FCI, é colocado fora de serviço. É necessária intervenção manual nesse cenário de failover não planejado para restabelecer o quorum nos nós restantes que ainda estiverem disponíveis, a fim de colocar o cluster WSFC e a FCI novamente online. Para obter mais informações, consulte os modos de quorum WSFC e a 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, poderá haver um número significativo de páginas sujas no cache do buffer. Consequentemente, os failovers duram o tempo necessário para gravar em disco as páginas sujas restantes, o que pode levar a tempos de failover longos e imprevisíveis. A partir do SQL Server 2012 (11.x), a FCI pode usar pontos de verificação indiretos para limitar o número de páginas sujas mantidas no cache do buffer. Embora isso consuma mais recursos em cargas de trabalho regulares, isso torna o tempo de failover mais previsível e mais configurável. Isso é útil quando o contrato de 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, consulte pontos de verificação indiretos.

Monitoramento de saúde confiável e política de failover flexível

Depois que a FCI é iniciada com êxito, o serviço WSFC monitora a integridade do cluster WSFC subjacente e a integridade da instância do SQL Server. A partir do SQL Server 2012 (11.x), 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. Há três implicações resultantes:

• A conexão dedicada com a instância do SQL Server possibilita consultar de forma confiável os diagnósticos dos componentes a todo momento, mesmo quando o FCI está sob alta carga. Essa funcionalidade possibilita distinguir entre um sistema que está sob carga pesada e um sistema que tem condições de falha, evitando problemas como failovers falsos.

• O diagnóstico de componente detalhado possibilita configurar uma política de failover mais flexível, na qual você pode escolher quais condições de falha disparam failovers.

• 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 de Arquivos de Log para inspecionar os estados dos componentes que antecederam a ocorrência do failover, a fim de determinar o que causou o failover.

Para obter mais informações, consulte política de failover para instâncias de cluster de failover.

Configurar a criptografia TLS 1.3

O SQL Server 2025 (17.x) apresenta o suporte ao TDS 8.0 , que permite a imposição de criptografia TLS 1.3 para comunicação entre o Cluster de Failover do Windows Server e suas instâncias de cluster de failover.

Para começar, examine Conectar-se com criptografia estrita.

Elementos de uma instância de cluster de failover

Uma FCI é composta por um conjunto de servidores físicos (nós) com configuração de hardware semelhante e configuração de software idêntica, incluindo a versão e o nível de patch do sistema operacional, bem como a versão do SQL Server, o nível de patch, os componentes e o nome da instância. Uma configuração de software idêntica é necessária para garantir que a FCI possa funcionar plenamente quando ocorrer 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 das configurações e das chaves de registro pontiagudas para garantir a funcionalidade completa da FCI após um failover. Apenas um dos nós no cluster possui o grupo de recursos por vez (o nó ativo). O serviço WSFC gerencia o cluster de servidores, a configuração de quorum, a política de failover e as operações de failover, além do nome de rede virtual e dos endereços IP virtuais da FCI. Se houver uma falha (falhas de hardware, falhas no sistema operacional ou falhas de aplicativo e serviço) ou uma atualização planejada, a propriedade do grupo de recursos será movida para outro nó na FCI. O número de nós compatíveis com 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 do produto são instalados localmente em cada nó da FCI em um processo semelhante às instalações autônomas do SQL Server. No entanto, durante a inicialização, os serviços não são iniciados automaticamente, mas gerenciados pelo WSFC.

Armazenamento

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

Nome da rede

O nome da rede virtual para a FCI fornece um ponto de conexão unificado para a FCI. Esse ponto de conexão unificado permite que os aplicativos se conectem ao nome da rede virtual sem precisar conhecer o nó ativo no momento. Quando ocorre um failover, o nome da rede virtual é registrado no novo nó ativo depois que ele é iniciado. Esse processo é transparente para o cliente ou aplicativo que se conecta ao SQL Server e minimiza o tempo de inatividade que o aplicativo ou os clientes experimentam durante uma falha.

A captura de tela a seguir mostra o nome da rede da instância do cluster de failover no Gerenciador de Cluster de Failover:

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 nome da rede virtual no servidor DNS é atualizado para apontar para o endereço IP virtual da respectiva sub-rede. Aplicações e clientes podem então se conectar à FCI usando o mesmo nome de rede virtual após um failover entre várias sub-redes.

Conceitos e tarefas de failover do SQL Server

Configuração compatível com FCI do SQL Server no WSFC

As FCIs do SQL Server com base no WSFC têm suporte nos seguintes produtos:

• Windows Server 2012
• Windows Server 2012 R2
• Edições do Windows Server 2016 Standard e Datacenter
• Edições do Windows Server 2019 Standard e Datacenter
• Edições do Windows Server 2022 Standard e Datacenter

O Windows Server fornece dois tipos de serviços de clustering:

• Cluster de failover
• Balanceamento de carga de rede

Somente as soluções de cluster de servidores podem ser usadas em conjunto com o SQL Server para alta disponibilidade em caso de perda de um nó ou se houver um problema em uma instância do SQL Server. O Network Load Balancing pode ser usado em alguns casos juntamente com instalações autônomas do SQL Server configuradas como somente leitura.

Cada FCI do SQL Server requer:

• Um grupo de cluster dedicado que possui letras de unidade de disco atribuídas exclusivamente.
• Pelo menos um endereço IP exclusivo.
• Servidor virtual exclusivo e nomes de instância dentro do domínio.

Suporte à solução de cluster que não é da Microsoft

O SQL Server é desenvolvido e testado com o clustering do Microsoft Server. Se você usar um produto de clustering que não seja da Microsoft, o contato de suporte principal para problemas de instalação, desempenho ou comportamento de cluster deverá ser o provedor de solução. A Microsoft fornece suporte comercialmente razoável para instalações de cluster que não são da Microsoft, semelhante ao suporte para implantações autônomas do SQL Server.

Número de nós com suporte

Para obter detalhes sobre o número máximo de nós com suporte para instâncias de cluster de failover do Always On, consulte:

• SQL Server 2025
• SQL Server 2022
• SQL Server 2019
• SQL Server 2017

Sistema operacional com suporte

Para obter informações sobre sistemas operacionais compatíveis com o cluster de failover do SQL Server, consulte Verifique o sistema operacional antes de instalar o cluster de failover.

Unidades de disco montadas

Não há suporte para o uso de unidades montadas em clusters que incluem uma instalação do SQL Server. Para obter mais informações, consulte o suporte do SQL Server para volumes montados.

CSV (Volumes Compartilhados de Cluster)

O SQL Server 2012 (11.x) e versões anteriores não dão suporte ao uso do CSV para SQL Server em um cluster de failover.

Para obter informações sobre como usar o CSV com o SQL Server 2014 (12.x) ou versões posteriores, consulte os seguintes recursos:

• Implantando o SQL Server 2014 com volumes compartilhados de cluster
• Volumes Compartilhados de Cluster
• Uso de Volumes Compartilhados Clusterizados em um cluster de failover

Restrições do controlador de domínio

Não há suporte para instâncias de cluster de failover do SQL Server em nós de instância de cluster de failover configurados como controladores de domínio.

Considerações sobre migração de domínio

O SQL Server 2005 (9.x) e versões posteriores não podem ser migrados para um novo domínio. Você precisa desinstalar e reinstalar os componentes do cluster de failover. Para obter mais informações, consulte Mover um cluster do Windows Server de um domínio para outro.

Antes de desinstalar o SQL Server, você deve seguir as seguintes etapas:

• Defina o SQL Server para usar a segurança do modo misto ou adicione novas contas de domínio aos logons do SQL Server.

• Renomeie a DATA pasta que contém bancos de dados do sistema para que ela possa ser trocada novamente após a instalação novamente para reduzir o tempo de inatividade.

• Não remova os arquivos de suporte do SQL Server, o SQL Server Native Client, o Integration Services ou os componentes da estação de trabalho, a menos que você esteja reconstruindo todo o nó.

Conteúdo relacionado

• Criar uma nova instância de cluster de failover Always On (Configuração)
• Fazer upgrade de uma instância de cluster de failover
• Cluster de Failover do Windows Server com SQL Server
• Clustering de Failover e grupos de disponibilidade Always On (SQL Server)
• SQL Server habilitado pelo Azure Arc
• Exibir instâncias de cluster de failover do Always On no Azure Arc
• Política de Failover para Instâncias de Cluster de Failover
• Política de suporte para produtos do Microsoft SQL Server que estão em execução em um ambiente de virtualização de hardware