Controladora passiva: o que ocorre no failover

Índice:

• O que ocorre no failover?
• Como funciona a unidade em espera?
• Por que o heartbeat inicia a troca?
• Quais etapas formam o failover?
• Como o cache afeta a retomada?
• Onde a controladora passiva faz sentido?
• Quais riscos aparecem após a troca?
• Como testar um storage com duas unidades?
• Como escolher entre ativa e passiva?
• Como integrar um NAS QNAP ao plano?
• Como reduzir o impacto no negócio?
• Por que testar o failover evita surpresas?

Uma controladora passiva fica em espera até uma falha atingir a unidade ativa. No failover, ela assume discos, volumes, serviços e caminhos de rede conforme as regras do cluster.

Esse processo evita uma parada longa, mas não elimina toda indisponibilidade. Alguns segundos podem afetar máquinas virtuais, bancos e arquivos abertos. Além disso, um erro no heartbeat pode gerar disputa entre nós.

Por isso, a equipe precisa entender cada etapa, desde a detecção até a retomada dos acessos. Assim, a controladora passiva deixa de parecer apenas uma peça reserva e passa a integrar a estratégia de alta disponibilidade.

O que ocorre no failover?

Uma controladora passiva assume os recursos quando a unidade ativa falha e o cluster confirma esse evento. Em poucos segundos, o sistema interrompe o acesso antigo, registra a troca e libera os volumes para o novo nó.

O processo começa com dois ou mais sinais. O heartbeat monitora o estado do parceiro, enquanto os caminhos SAS, Fibre Channel ou Ethernet verificam a comunicação com discos e clientes. Ainda assim, uma falha isolada em uma porta não deve iniciar a troca.

Quando o diagnóstico confirma a perda, a unidade reserva importa a configuração, recupera o cache válido e publica os mesmos endereços lógicos. Muitas vezes, o usuário percebe apenas uma pausa curta. Portanto, failover é uma troca controlada e não uma simples ligação automática.

Como funciona a unidade em espera?

A controladora passiva recebe metadados, parâmetros e sinais do nó ativo, mas normalmente não atende operações de leitura ou escrita. Esse desenho reduz o consumo, simplifica o controle e deixa uma segunda unidade pronta para assumir.

Algumas arquiteturas replicam o cache antes de confirmar cada gravação. Outras usam memória espelhada ou um módulo protegido por bateria. Ainda assim, cada fabricante aplica regras próprias para volumes, LUNs, interfaces e permissões.

Em um storage com oito discos SAS, por exemplo, ambas as controladoras podem enxergar o mesmo conjunto. A unidade ativa administra o RAID e a passiva acompanha o estado. Assim, o sistema reduz o tempo até a retomada sem duplicar todas as operações.

Por que o heartbeat inicia a troca?

O heartbeat envia sinais periódicos entre os nós para identificar uma falha real. Dois ou três canais independentes reduzem falsos alarmes, pois um cabo rompido não deveria derrubar um servidor saudável.

Além disso, o cluster observa energia, processador, memória, controladoras e caminhos para os discos. Uma regra simples usa tempo limite, contagem de respostas ausentes e estado dos serviços. Raramente um único indicador oferece segurança suficiente.

Se a rede interna perde contato, mas ambos os nós continuam ativos, surge o risco de split brain. Nesse cenário, duas controladoras podem tentar gravar no mesmo volume. Por isso, o mecanismo precisa bloquear um participante antes que a corrupção de arquivos alcance os clientes.

Quais etapas formam o failover?

O primeiro estágio interrompe novas gravações no nó com problema. Em seguida, o cluster verifica o cache, encerra sessões antigas e transfere a posse dos volumes para a controladora reserva.

Depois, a unidade promovida monta os sistemas de arquivos, ativa LUNs e anuncia endereços virtuais. Alguns ambientes também atualizam rotas, grupos multipath e serviços SMB ou NFS. Ainda assim, aplicações sensíveis podem exigir reconexão manual.

Por fim, os logs registram causa, horário, volume afetado e duração da troca. Em um banco com duas instâncias virtuais, essa sequência reduz o impacto, mas não substitui testes periódicos. Um failover sem ensaio costuma esconder dependências esquecidas.

Como o cache afeta a retomada?

O cache acelera muitas gravações porque reúne pequenos blocos antes do envio aos discos. Porém, uma pane elétrica pode apagar dados que ainda não chegaram ao RAID. Por isso, a controladora precisa usar bateria, supercapacitor ou espelhamento entre nós.

Alguns equipamentos confirmam a gravação somente após proteger o conteúdo. Outros respondem antes para ganhar desempenho. Essa diferença muda o risco para bancos, máquinas virtuais e sistemas transacionais. Além disso, uma bateria degradada pode forçar o modo seguro e reduzir a velocidade.

Durante o failover, a unidade reserva lê o diário, confere blocos pendentes e reabre volumes consistentes. Muitas vezes, esse trabalho acrescenta alguns segundos. Na prática, a proteção do cache vale mais que uma pequena vantagem em IOPS.

Onde a controladora passiva faz sentido?

Uma arquitetura ativa e passiva atende workloads que não aceitam longas paradas. Servidores de arquivos, bancos, hipervisores e aplicações industriais costumam usar esse modelo por causa do valor alto da continuidade.

Em um datacenter pequeno, duas controladoras SAS podem servir um pool all flash com baixa latência. Em outro cenário, um NAS com duas unidades coordena compartilhamentos SMB, snapshots e replicação. Ainda assim, poucos usuários precisam desse desenho em uma rede doméstica.

O custo cresce com licenças, fontes, interfaces e suporte especializado. Portanto, a escolha faz sentido quando alguns minutos indisponíveis custam mais que a estrutura redundante. Para arquivos secundários, um backup bem testado talvez entregue melhor resultado financeiro.

Quais riscos aparecem após a troca?

O failover pode terminar sem erro aparente e ainda deixar sessões incompletas. Arquivos abertos, locks SMB e transações interrompidas exigem validação posterior. Além disso, um cliente pode conservar o endereço antigo na tabela multipath.

Uma segunda dificuldade surge quando o nó reserva usa firmware diferente. Pequenas diferenças em RAID, Btrfs, EXT4 ou protocolos podem impedir a montagem correta. Raramente a compatibilidade surge por acaso, pois cada versão precisa seguir a matriz indicada pelo fabricante.

Se a equipe reinicia o nó original sem isolamento, o split brain volta a ameaçar os volumes. O fencing resolve esse conflito ao desligar ou bloquear o participante suspeito. Assim, uma ação automática protege os dados, embora possa interromper um servidor ainda saudável.

Como testar um storage com duas unidades?

O teste começa com uma janela controlada e uma carga conhecida. A equipe registra latência, IOPS, sessões, rotas e tempo até a publicação dos volumes. Também precisa avisar usuários e separar um plano para retorno.

Depois, os técnicos simulam perda elétrica, queda do heartbeat e falha em uma porta SAS. Cada cenário revela uma dependência diferente. Algumas equipes testam duas vezes por ano, enquanto cargas críticas exigem ciclos trimestrais.

O resultado precisa aparecer em um relatório simples. Esse documento registra causa, duração, arquivos afetados e comportamento das aplicações. Ainda, um teste de retorno confirma se a controladora original recupera a posse sem apagar alterações recentes.

Como escolher entre ativa e passiva?

Uma controladora ativa e passiva simplifica a posse dos volumes, pois apenas um nó grava por vez. Esse desenho reduz conflitos e facilita a administração. Em troca, parte do hardware fica ociosa durante a operação normal.

Já o modo ativo e ativo divide leituras ou volumes entre os nós. A capacidade cresce, mas a coordenação exige mais cache, software e regras de balanceamento. Além disso, uma falha pode concentrar toda a carga em um único participante.

Para um NAS corporativo com muitas máquinas virtuais, o ganho ativo e ativo pode justificar a complexidade. Para um file server com poucas sessões, a arquitetura passiva costuma simplificar a rotina. Portanto, o perfil da carga decide mais que a quantidade de controladoras.

Como integrar um NAS QNAP ao plano?

Algumas linhas QNAP voltadas a alta disponibilidade trabalham com dois equipamentos e replicação interna. O administrador precisa conferir o modelo, a versão do QuTS hero ou QTS, a lista de discos e os requisitos para HA.

O conjunto deve usar fontes independentes, duas redes para heartbeat e caminhos separados para usuários. Também convém reservar uma VLAN para gestão e outra para replicação. Ainda, o NAS precisa enviar logs para um servidor externo, pois a falha pode esconder eventos no próprio equipamento.

Um QNAP com snapshots, RAID, permissões SMB e backup externo reduz vários impactos. Porém, o failover não substitui cópias offline nem replica dados contra ransomware. Nesse cenário, o NAS participa da continuidade, enquanto o backup protege a recuperação.

Como reduzir o impacto no negócio?

Uma política eficiente começa com metas claras para RTO e RPO. O RTO define quanto tempo a operação aceita ficar parada, enquanto o RPO define quantos dados a empresa aceita perder.

Com essas duas medidas, a equipe dimensiona cache, links, discos, licenças e suporte. Também separa falha física, corrupção lógica, ransomware e desastre no local. Cada ameaça exige uma resposta diferente, pois nenhum failover corrige dados apagados.

Alguns indicadores ajudam na rotina. A equipe acompanha temperatura, bateria, erros SAS, latência, capacidade e alertas do RAID. Frequentemente, esse acompanhamento encontra uma controladora degradada antes que o failover se torne necessário.

Por que testar o failover evita surpresas?

Uma arquitetura redundante só ajuda quando os dois nós conhecem os mesmos volumes, regras e caminhos. O teste confirma essa sincronização e revela atrasos que a documentação raramente mostra.

Além disso, a simulação aproxima a equipe do evento real. Técnicos aprendem quais serviços retornam sozinhos, quais clientes exigem login e quais aplicações precisam de validação. Algumas horas de ensaio evitam muitas horas de diagnóstico durante uma pane.

Quando a empresa combina controladora passiva, backup, snapshots e monitoramento, ela reduz o alcance das falhas. Ainda assim, a redundância precisa de revisão, atualização e exercícios regulares. Portanto, um failover bem planejado é a resposta para continuidade sem depender da sorte.