Failover, balanceamento e bonding: o que muda no evento.

Comece pela aplicação que precisa continuar

A pergunta de compra deve ser concreta: o que acontece com a transação, a chamada ou a transmissão quando um link fica indisponível? Retomar navegação e preservar uma sessão ativa são resultados diferentes. Uma arquitetura pode restabelecer novos acessos rapidamente e ainda exigir reconexão de uma aplicação que já estava em uso.

Liste as atividades críticas e escreva o comportamento aceitável de cada uma. Uma consulta que pode ser refeita não precisa do mesmo desenho de uma saída de vídeo ao vivo. Essa distinção ajuda a avaliar o escopo sem transformar o nome de uma função do roteador em garantia de continuidade.

Failover precisa detectar a falha certa

Uma interface conectada não prova que o destino da aplicação está acessível. Por isso, o projeto deve explicar o que será monitorado, quando um caminho será considerado inadequado e como ocorrerá o retorno ao principal. O teste precisa incluir o serviço usado pela operação, além do estado físico do cabo ou do modem.

A documentação de WAN Backup da MikroTik apresenta um desenho com caminho preferencial e outro de reserva. É uma referência de configuração daquele fabricante; não certifica a configuração de qualquer produto nem define o tempo de troca de uma solução LEGAL.

Balanceamento não é soma automática numa sessão

Em uma distribuição por conexão, diferentes sessões podem seguir caminhos diferentes. Isso ajuda a dividir a demanda total, mas não significa que uma única transferência sempre usará a soma das velocidades disponíveis. Pergunte se a política trabalha por dispositivo, conexão ou outro critério e qual o efeito sobre aplicações sensíveis a mudança de origem.

O PCC do RouterOS é um exemplo de classificação de conexões. Não é uma recomendação para copiar comandos para uma rede de evento: compatibilidade com portal, regras e desenho precisa ser avaliada no equipamento e versão utilizados.

Bonding depende da arquitetura completa

Há soluções de bonding que distribuem pacotes de uma sessão por múltiplos links usando um túnel até um ponto de agregação. A Peplink descreve esse mecanismo em sua tecnologia SpeedFusion. Trata-se de um exemplo específico; não pressupõe que um plano da LEGAL inclua esse recurso.

Equipamentos, software, ponto remoto, licenciamento e condições dos links entram na avaliação. A capacidade efetiva deve ser medida. Não conte duas operadoras como independência absoluta: energia, localização, infraestrutura e outras dependências podem produzir falhas comuns.

Faça um ensaio com critérios de aceite

Em um teste autorizado, execute uma operação representativa, retire o caminho principal e registre o que ocorreu. Houve perda de sessão? A aplicação retomou sozinha? O operador precisou agir? A repetição da transação criou duplicidade? Depois teste a volta do principal.

Use o resultado para escolher o desenho e documentar o procedimento da equipe. O teste deve acontecer antes da abertura e sem interferir em operação de terceiros. Uma demonstração isolada também não prova disponibilidade futura em qualquer cenário.

Checklist proposto

• Definir aplicações e interrupção aceitável.
• Identificar dependências comuns dos links.
• Registrar detecção, troca e retorno.
• Testar sessões e duplicidade de operações.
• Incluir escopo e suporte na proposta.