Redundância de link dedicado: active-active vs active-standby para ambientes críticos

Por Equipe Técnica JCM TELCOM · Publicado em 2025/06 · Leitura: ~8 min

A disponibilidade de conectividade é um requisito não negociável para operações críticas. Data centers, hospitais, indústrias com automação e escritórios de advocacia com prazos processuais não podem tolerar horas de indisponibilidade. A escolha entre redundância active-active e active-standby determina o custo, a complexidade e o tempo de recuperação em caso de falha.

Conceitos fundamentais de redundância

Redundância de link dedicado significa ter dois ou mais circuitos de acesso à internet de forma que a falha de um não interrompa a operação. As duas arquiteturas principais diferem na forma como os links são utilizados durante a operação normal.

Na arquitetura active-standby, o link principal carrega 100% do tráfego; o link secundário fica em standby, monitorado continuamente. Quando o principal falha, o roteador detecta a queda e redireciona o tráfego para o secundário. O tempo de failover depende do protocolo de detecção de falha utilizado.

Na arquitetura active-active, ambos os links estão em uso simultâneo, dividindo o tráfego por ECMP (Equal-Cost Multi-Path) ou por políticas de roteamento BGP. A falha de um link resulta em redistribuição automática do tráfego para o link restante, sem interrupção perceptível de sessões estabelecidas.

Comparativo técnico

Protocolos de detecção de falha

O tempo de failover em active-standby é determinado pelo protocolo de detecção de falha. O BGP padrão detecta falhas em 90 segundos (3 keepalives de 30s). Com ajuste de timers (holdtime 10s, keepalive 3s), o failover cai para 10 segundos. Com BFD (Bidirectional Forwarding Detection) integrado ao BGP, o failover ocorre em menos de 1 segundo.

Para ambientes que não toleram nem 1 segundo de interrupção (UTI, data center de missão crítica), a única solução é active-active com ECMP, onde não há failover — o tráfego é redistribuído instantaneamente.

Recomendação por vertical

Checklist de implementação

1. Definir RTO (Recovery Time Objective): quanto tempo de indisponibilidade é tolerável
2. Escolher arquitetura com base no RTO: active-active (<1s), active-standby BFD (<1s), BGP padrão (30–90s)
3. Contratar links de provedores com infraestruturas físicas independentes
4. Configurar BGP com BFD se RTO < 10 segundos
5. Testar failover mensalmente em janela de manutenção
6. Documentar o processo de failover e incluir no plano de continuidade de negócios
7. Incluir cláusula de failover no SLA contratual com penalidade por descumprimento

Perguntas Frequentes

Qual a diferença entre active-active e active-standby?

Em active-active, ambos os links estão em uso simultâneo com balanceamento de carga. Em active-standby, apenas um link está ativo; o segundo assume em caso de falha. Active-active oferece maior throughput e failover transparente; active-standby é mais simples e barato.

Qual o tempo de failover típico?

Com BGP padrão: 30–90 segundos. Com BFD integrado ao BGP: menos de 1 segundo. Com active-active ECMP: failover transparente sem interrupção perceptível.

Preciso de dois provedores diferentes para redundância real?

Sim. Dois links do mesmo provedor compartilham infraestrutura física e podem falhar simultaneamente. Redundância real exige provedores com infraestruturas físicas independentes.

BGP é necessário para redundância?

BGP é a solução mais robusta para redundância com múltiplos provedores. Alternativas incluem roteamento estático com failover por script ou appliances SD-WAN para empresas sem ASN próprio.

Qual o custo adicional de uma arquitetura active-active?

Tipicamente 80–120% a mais que um único link equivalente, incluindo o segundo link, equipamento de roteamento com BGP/ECMP e, opcionalmente, ASN próprio.

Redundância física vs redundância lógica

Um erro comum no planejamento de redundância é confundir redundância lógica (dois circuitos virtuais sobre a mesma fibra física) com redundância real. Dois links do mesmo provedor, mesmo que sejam circuitos independentes no sistema de gestão, podem compartilhar o mesmo cabo de fibra no último quilômetro — o que significa que um corte físico derruba ambos simultaneamente.

Redundância real exige diversidade física: dois provedores com rotas de fibra independentes, entrando no prédio por pontos físicos diferentes (preferencialmente por lados opostos do edifício). Exija do provedor a documentação da rota física do cabo e confirme que ela é diferente da rota do provedor principal.

Testes de failover: metodologia e frequência

Redundância não testada não é redundância — é uma ilusão de segurança. Testes de failover devem ser realizados mensalmente, em janela de manutenção programada, com os seguintes passos: desligar o link principal manualmente, medir o tempo até o tráfego ser roteado pelo link secundário, verificar que todas as aplicações críticas continuam funcionando, e restaurar o link principal medindo o tempo de retorno ao estado normal.

Os resultados dos testes devem ser documentados e comparados com o SLA contratual. Se o tempo de failover medido é consistentemente maior que o especificado no SLA, o provedor deve ser notificado formalmente e o problema deve ser resolvido antes de uma falha real.

Redundância em camadas: link, equipamento e energia

Redundância de link é apenas uma camada de um plano de continuidade completo. Equipamentos de borda (roteadores, switches) também devem ter redundância: roteadores em cluster ativo-passivo com failover automático. A alimentação elétrica dos equipamentos de rede deve ser protegida por nobreak (UPS) com autonomia mínima de 4 horas e gerador para operações críticas. Uma falha de energia que derruba o roteador torna inútil a redundância de link.

Documentação e plano de continuidade

A arquitetura de redundância deve ser documentada em um plano de continuidade de negócios (PCN) que inclua: diagrama de rede com todos os links e equipamentos, procedimento de failover manual (caso o automático falhe), contatos de suporte de ambos os provedores, e procedimento de retorno ao estado normal após failover. O PCN deve ser revisado anualmente e testado semestralmente.

Equipes de TI que nunca testaram o failover frequentemente descobrem problemas durante uma falha real: o roteador de backup não estava configurado corretamente, o link secundário estava com capacidade insuficiente, ou as aplicações críticas não reconectaram automaticamente após o failover. Testes regulares eliminam essas surpresas.

ROI da redundância: como calcular

O ROI da redundância é calculado comparando o custo do segundo link com o custo esperado de indisponibilidade. Fórmula: ROI = (Custo por hora de indisponibilidade × Horas de indisponibilidade evitadas por ano) / Custo anual do segundo link. Para uma empresa com custo de indisponibilidade de R$ 10.000/hora e segundo link de R$ 1.500/mês (R$ 18.000/ano), basta evitar 1,8 horas de indisponibilidade por ano para o investimento se pagar.

Custo de downtime vs custo de redundância: a decisão correta

A decisão de implementar redundância deve ser baseada em dados, não em percepção de risco. Calcule o custo por hora de indisponibilidade para o seu negócio: receita perdida, custo de horas improdutivas da equipe, impacto em clientes, e custo de reputação. Compare com o custo mensal do segundo link. Se o custo de 2 horas de downtime por ano supera o custo anual do segundo link, a redundância se justifica economicamente.

Para a maioria das empresas com operações digitais críticas — e-commerce, SaaS, hospitais, indústrias com ERP em nuvem — o custo de 2 horas de downtime por ano supera amplamente o custo de um segundo link de R$ 1.000–2.500/mês. A redundância não é um luxo; é um investimento com ROI mensurável e frequentemente superior a 300% ao ano.

Comece com active-standby se o orçamento for restrito — é mais simples de implementar e gerenciar, e já elimina a maioria dos riscos de indisponibilidade. Migre para active-active quando o volume de tráfego justificar a utilização simultânea de ambos os links e quando a equipe de TI tiver maturidade para gerenciar o roteamento BGP ou SD-WAN necessário.