Compartilhar via

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 FCI (instância de cluster de failover) é redundante no nível da instância do 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, 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, consulte clustering de failover e grupos de disponibilidade Always On (SQL Server).

As instâncias de cluster de failover do SQL Server dão suporte aos Espaços de Armazenamento Diretos para recursos de armazenamento de cluster, que foi introduzido no Windows Server 2016 Datacenter Edition. Para obter mais informações, confira Espaços de Armazenamento Diretos no Windows Server.

As instâncias de cluster de failover também dão 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.

Observação

O SQL Server 2025 (17.x) apresenta suporte para impor conexões estritas à instância do cluster de failover.

Benefícios das instâncias de cluster de failover

Quando há falha de hardware ou software do servidor, os aplicativos ou clientes que se conectam ao tempo de inatividade da experiência do servidor. 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 dentro do grupo de disponibilidade. Portanto, FCIs e nós autônomos não devem ser acoplados em 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 desastre por meio de uma FCI de várias sub-redes ou executando um banco de dados hospedado por 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 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 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
  • SQL Server Serviço do Mecanismo de Banco de Dados
  • 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 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 direcionadas automaticamente para o novo nó ativo usando o mesmo nome de rede virtual.

A FCI está online desde que seu cluster WSFC subjacente esteja em boa integridade de quorum. (A maioria dos nós WSFC de quorum está disponível como destinos de failover automático.) Quando o cluster WSFC perde seu quorum, seja devido a hardware, software ou falha de rede ou configuração de quorum inadequado, todo o cluster WSFC, juntamente com a 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 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. 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 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 integridade 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 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. 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 de componente que antecedem a ocorrência de failover para determinar o que causou o failover.

Para obter mais informações, consulte a 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.

Observação

A instalação da instância de cluster de failover do SQL Server 2025 (17.x) falhará se o TLS 1.2 estiver desabilitado no computador.

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 a versão do sistema operacional e o nível do patch, e a versão do SQL Server, o nível do patch, os componentes e o nome da instância. A configuração de software idêntica é necessária para garantir que a FCI possa ser totalmente funcional quando falhar 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 do servidor, a configuração de quorum, a política de failover e as operações de failover, além do nome da 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 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 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 após o início. 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:

Captura de tela do nome da rede FCI 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. Aplicativos e clientes podem se conectar à FCI usando o mesmo nome de rede virtual após um failover de várias sub-redes.

Conceitos e tarefas de failover do SQL Server

Conceitos e tarefas Artigo
Descreve o mecanismo de detecção de falha e a política de failover flexível. Política de failover para instâncias de cluster de failover
Descreve os conceitos na administração e na manutenção da FCI. Administração e manutenção da instância de cluster de failover
Descreve a configuração e os conceitos de várias sub-redes. Clustering de várias sub-redes 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:

Somente as soluções de cluster de servidor podem ser usadas junto com o SQL Server para alta disponibilidade se um nó for perdido ou se houver um problema com uma instância do SQL Server. O Balanceamento de Carga de Rede pode ser usado em alguns casos, juntamente com instalações autônomas do SQL Server somente leitura.

Cada FCI do SQL Server requer:

  • Um grupo de cluster dedicado que atribuiu exclusivamente letras de unidade de disco.
  • 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 always on, consulte:

Sistema operacional com suporte

Para obter informações sobre sistemas operacionais com suporte para clustering de failover do SQL Server, consulte Verificar seu sistema operacional antes de instalar o clustering de failover.

Unidades 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:

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 instalar novamente 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 arquivos de suporte do SQL Server, SQL Server Native Client, Integration Services ou Componentes de Estação de Trabalho, a menos que você esteja recriando todo o nó.

Aviso

Se ocorrerem erros durante o processo de desinstalação, talvez seja necessário recriar o nó para instalar o SQL Server novamente com êxito.

Conteúdo relacionado

  • Last updated on