Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:SQL Server
As instâncias de cluster de failover Always On do SQL Server usam o WSFC (Cluster de Failover do Windows Server) para fornecer alta disponibilidade local. Uma instância de cluster de failover (FCI) é redundante ao 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 a FCI fornece failover de um nó WSFC para outro se o nó atual ficar indisponível.
Uma FCI pode usar 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 oferecem suporte ao Storage Spaces Direct para recursos de armazenamento em cluster, que foi introduzido na edição do Windows Server 2016 Datacenter. Para obter mais informações, consulte Espaços de armazenamento diretos no Windows Server.
As instâncias de cluster de failover também oferecem suporte a Volumes Compartilhados de Cluster (CSV). 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) introduz suporte para impor conexões estritas à sua instância de 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 servidor experimentam 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. Apenas um dos nós na FCI possui o grupo de recursos 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 oferecem:
Proteção no nível da instância por meio de redundância.
Failover automático em caso de falha (falhas de hardware, falhas do sistema operacional ou falhas de aplicativos e serviços).
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 dentro de um grupo de disponibilidade se o failover automático for um componente importante da sua solução de alta disponibilidade. No entanto, esse acoplamento pode ser feito para sua solução de recuperação de desastres .
Suporte para uma ampla gama de soluções de armazenamento, incluindo discos de cluster WSFC (iSCSI, Fiber Channel e assim por diante) e compartilhamentos de arquivos SMB (Server Message Block).
Recuperação de desastres por meio de uma FCI de várias sub-redes ou executando um banco de dados hospedado pela 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 através de detecção periódica e detalhada da saúde do sistema usando conexões dedicadas e persistentes.
Configurabilidade e previsibilidade no tempo de failover através de pontos de verificação de fundo indiretos.
Uso de recursos limitado 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. Em caso de tempo de inatividade, se a concessão de IP DHCP expirar, será necessário mais tempo para registrar novamente o novo endereço IP DHCP associado ao nome DNS.
Visão geral da instância de failover em cluster
Uma FCI é executada num 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 pertencentes a este nó incluem:
- Nome da rede
- endereço IP
- Discos partilhados
- Serviço do Mecanismo de Banco de Dados do SQL Server
- Serviço SQL Server Agent
- Serviço SQL Server Analysis Services, se estiver instalado
- Um recurso de compartilhamento de arquivos, se o recurso FILESTREAM estiver instalado
A qualquer momento, apenas o proprietário do grupo de recursos (e nenhum outro nó na FCI) está executando seus respetivos 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:
A menos que ocorra uma falha de hardware ou sistema, todas as páginas sujas no cache do buffer são gravadas no disco.
Todos os respetivos serviços do SQL Server no grupo de recursos são interrompidos no nó ativo.
A propriedade do grupo de recursos é transferida para outro nó na FCI.
O novo proprietário do grupo de recursos inicia seus serviços do SQL Server.
As solicitações de conexão do aplicativo cliente são direcionadas automaticamente para o novo nó ativo usando o mesmo nome de rede virtual.
A FCI está on-line desde que seu cluster WSFC subjacente esteja em boa saúde de quórum. (A maioria dos nós WSFC de quorum está disponível como destinos de failover automáticos.) Quando o cluster WSFC perde seu quórum, seja devido a falha de hardware, software ou rede ou configuração de quórum inadequada, todo o cluster WSFC, juntamente com a FCI, é colocado offline. A intervenção manual é então necessária neste cenário de failover não planejado para restabelecer o quórum nos nós disponíveis restantes para colocar o cluster WSFC e a FCI novamente online. Para obter mais informações, consulte Modos de quórum WSFC e configuração de votação (SQL Server).
Tempo de failover previsível
Dependendo de quando sua instância do SQL Server executou pela última vez uma operação de ponto de verificação, pode haver um número substancial de páginas sujas no cache de buffer. Consequentemente, os failovers duram tanto quanto o tempo necessário para gravar as páginas sujas restantes no disco, o que pode resultar num 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, 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 (Recovery Time Objetive, 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 obter diagnósticos detalhados de componentes por meio de um procedimento armazenado do sistema. Há três implicações resultantes:
A conexão dedicada à instância do SQL Server possibilita monitorizar de forma confiável os diagnósticos dos componentes constantemente, mesmo quando a FCI está sob carga pesada. Esta capacidade permite distinguir entre um sistema que está sob carga pesada e um sistema que tem condições de falha, evitando assim problemas como falsos failovers.
O diagnóstico detalhado do componente torna possível configurar uma política de failover mais flexível, na qual você pode escolher quais condições de falha acionam failovers.
O diagnóstico detalhado de componentes também permite uma melhor resolução de problemas de failovers automáticos a posteriori. As informações de diagnóstico são armazenadas em arquivos de log, que são colocados com os logs de erro do SQL Server. Você pode carregá-los no Visualizador do Arquivo de Log para inspecionar os estados do componente que levam à ocorrência de failover para 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) introduz suporte ao TDS 8.0 , que permite aplicar a encriptação TLS 1.3 para a comunicação entre o Cluster de Failover do Windows Server e as instâncias do seu cluster de failover.
Para começar, consulte Conectar-se com criptografia rígida.
Observação
A instalação da instância de cluster de failover do SQL Server 2025 (17.x) falha se o TLS 1.2 estiver desativado na máquina.
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 do sistema operacional e nível de patch, e versão do SQL Server, nível de patch, componentes e nome da instância. Uma configuração de software idêntica é necessária para garantir que a FCI possa ser totalmente funcional quando fizer failover entre os nós.
Grupo de recursos do WSFC
Uma FCI do SQL Server é executada em um grupo de recursos WSFC. Cada nó no grupo de recursos mantém uma cópia sincronizada das definições de configuração e chaves do Registro com ponto de verificação para garantir a funcionalidade completa da FCI após um failover. Apenas um dos nós no cluster possui o grupo de recursos de cada 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 da rede virtual e dos endereços IP virtuais da FCI. Se houver uma falha (falhas de hardware, falhas do sistema operacional ou falhas de aplicativos e serviços) ou uma atualização planejada, a propriedade do grupo de recursos será movida para outro nó na FCI. O número de nós com suporte em um grupo de recursos WSFC depende da sua edição do SQL Server. Além disso, o mesmo cluster WSFC pode executar várias FCIs (vários grupos de recursos), dependendo da 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 armazenamento compartilhado entre todos os nós da FCI para armazenamento de banco de dados e log. O armazenamento compartilhado pode ser na forma de discos de cluster WSFC, discos em uma 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 dos dados da 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 clientes enfrentam durante uma falha.
A captura de tela a seguir mostra o nome da rede para a instância de cluster de failover no Gerenciador de Cluster de Failover:
IPs virtuais
No caso de uma FCI com múltiplas sub-redes, é atribuído um endereço IP virtual 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 respetiva sub-rede. Os 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 deteção de falhas e a política de failover flexível. | Política de failover para instâncias de cluster de failover |
| Descreve conceitos em administração e manutenção de FCI. | Administração e manutenção de instâncias 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 com suporte para FCI do SQL Server no WSFC
As FCIs do SQL Server baseadas no WSFC são suportadas nos seguintes produtos:
- Windows Server 2012
- Windows Server 2012 R2
- Edições Windows Server 2016 Standard e Datacenter
- Edições Windows Server 2019 Standard e Datacenter
- Edições 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 em conjunto com o SQL Server para alta disponibilidade se um nó for perdido ou se existir um problema com uma instância do SQL Server. O balanceamento de carga de rede pode ser usado em alguns casos junto com instalações isoladas de SQL Server de apenas 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.
- Nomes exclusivos de servidores virtuais e instâncias dentro do domínio.
Suporte a soluções de cluster que não são da Microsoft
O SQL Server é desenvolvido e testado com o cluster de servidores da Microsoft. Se você usar um produto de cluster que não seja da Microsoft, seu contato de suporte principal para problemas de instalação, desempenho ou comportamento de cluster deverá ser o provedor de soluções. A Microsoft fornece suporte comercialmente razoável para instalações de cluster que não sejam da Microsoft, semelhante ao suporte para implantações autônomas do SQL Server.
Número de nós suportados
Para obter detalhes sobre o número máximo de nós suportados para instâncias de cluster de failover Always On, consulte:
Sistema operativo suportado
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 cluster 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 Suporte do SQL Server para volumes montados.
Volumes Partilhados de Cluster (CSV)
O SQL Server 2012 (11.x) e versões anteriores não oferecem suporte ao uso de CSV para SQL Server em um cluster de failover.
Para obter informações sobre como usar 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 do cluster
- Utilizar Volumes Compartilhados de Cluster num cluster de failover
Restrições do controlador de domínio
Não há suporte para instâncias de failover do SQL Server em nós de cluster 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 executar as seguintes etapas:
Defina o SQL Server para usar a segurança de modo misto ou adicione novas contas de domínio aos logons do SQL Server.
Renomeie a pasta que contém os bancos de dados do sistema para que ela possa ser trocada novamente após a reinstalação para reduzir o
DATAtempo 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 reconstruindo todo o nó.
Advertência
Se ocorrerem erros durante o processo de desinstalação, talvez seja necessário reconstruir o nó para instalar o SQL Server com êxito novamente.
Conteúdo relacionado
- Criar uma nova instância de cluster de failover Always On (Configuração)
- Atualizar uma instância de cluster de failover
- Cluster de Failover do Windows Server com o 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 Always On no Azure Arc
- Política de failover para instâncias de cluster de failover
- Política de suporte para produtos Microsoft SQL Server em execução em um ambiente de virtualização de hardware