Instâncias do cluster de failover do AlwaysOn (SQL Server)
Aplica-se a:
SQL Server
Como parte da oferta do SQL Server Always On, as Instâncias de Cluster de Failover do Always On aproveitam a funcionalidade WSFC (Windows Server Failover Clustering) para fornecer alta disponibilidade local por meio de redundância no nível da instância de servidor, uma FCI (instância de cluster de failover). Uma FCI é uma instância única do SQL Server que é instalada em nós de WSFC (Windows Server Failover Clustering) e, possivelmente, em várias sub-redes. Na rede, uma FCI aparece ser uma instância do SQL Server sendo executada em um único computador, mas proporciona failover de um nó do WSFC para outro se o nó atual se tornar indisponível.
Uma FCI pode aproveitar os Grupos de Disponibilidade para fornecer recuperação remota de desastres no nível do banco de dados. Para obter mais informações, confira Clustering de failover e Grupos de Disponibilidade (SQL Server).
Observação
O Windows Server 2016 Datacenter Edition apresenta suporte para S2D (Espaços de Armazenamento Diretos). As instâncias de cluster de failover do SQL Server dão suporte ao S2D para recursos de armazenamento de cluster. 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 ao CSVs (Volumes Compartilhados de Cluster). Para obter mais informações, veja Noções básicas sobre volumes compartilhados clusterizados em um cluster de failover.
Neste artigo:
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. No caso de uma falha (problemas de hardware, falhas de sistema operacional, aplicativo ou falhas de serviço) ou de uma atualização planejada, a propriedade do grupo de recursos é movida para outro nó do WSFC. 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. 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 caso de uma falha (problemas 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.
Solução de 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.
Zero reconfiguração 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 persistidas
Capacidade de configuração e previsibilidade em tempo de failover por meio de pontos de verificação indiretos em segundo plano
Uso acelerado de recurso durante failovers
Recomendações
Em um ambiente de produção, é recomendável usar endereços IP estáticos juntamente com o endereço IP virtual de uma instância de cluster de failover. Não é recomendável o uso do 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á:
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.
Todos os respectivos serviços do SQL Server no grupo de recursos são parados no nó ativo.
A propriedade de 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 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).
Hora 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, consulte Failover Policy for Failover Cluster Instances.
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
| Conceitos e tarefas | Artigo |
|---|---|
| Descreve o mecanismo de detecção de falha e a política de failover flexível. | Failover Policy for Failover Cluster Instances |
| 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 (SQL Server) |
Tópicos Relacionados
| Descrições do tópico | Artigo |
|---|---|
| Descreve como instalar uma nova FCI do SQL Server . | Criar um novo cluster de failover do SQL Server (instalação) |
| Descreve como atualizar para um cluster de failover do SQL Server . | Atualizar uma Instância de Cluster de Failover do SQL Server |
| Descreve conceitos de clustering de failover do Windows e fornece links para tarefas relativas ao clustering de failover do Windows. | Cluster de Failover do Windows Server com SQL Server |
| Descreve as distinções em conceitos entre nós em uma FCI e réplicas dentro de um grupo de disponibilidade e considerações para usar uma FCI para hospedar uma réplica para um grupo de disponibilidade. | Clustering de failover e Grupos de Disponibilidade (SQL Server) |
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de