Dois uplinks mas um só túnel: failover, balanceamento ou agregação
O failover, o balanceamento por fluxo e a agregação de um único fluxo são três promessas diferentes. Duas rotas padrão dão-lhe a primeira, e não as outras duas.
Duas linhas de internet podem tornar uma VPN mais disponível, e podem torná-la mais rápida para algumas cargas de trabalho, mas o mecanismo decide qual das duas coisas acontece. Um router com duas rotas padrão não está agregado, e um túnel que transporta milhares de ligações internas continua a ser um único fluxo externo. Nomear a promessa primeiro é a diferença entre um projeto e uma desilusão cara. A tabela abaixo separa as opções segundo o que cada uma exige no extremo remoto e o que uma perda de ligação faz a uma transferência.
Três promessas, e só uma precisa de um parceiro
O failover mantém um caminho disponível quando a ligação preferida desaparece. O balanceamento por hash de fluxos reparte fluxos independentes pelos dois uplinks. A agregação de um único fluxo permite que uma transferência use as duas ligações ao mesmo tempo. São produtos diferentes com requisitos diferentes, e só o último precisa da cooperação de algo além do seu router.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
Nada nessa tabela é motivo para comprar uma segunda linha. O que ela faz é impedir que um projeto de failover seja avaliado como se fosse agregação.
Porque é que um túnel parece um único fluxo ao router
Um router que balanceia carga faz hash dos endereços de origem e destino juntamente com as portas e depois envia o fluxo inteiro para onde o hash aponta. Um túnel VPN é um desses fluxos do ponto de vista do router, seja o que for que corra lá dentro. As ligações internas nunca chegam à decisão do hash, porque o cabeçalho exterior já decidiu o caminho. É por isso que um segundo uplink pode duplicar a capacidade total para muitos utilizadores e não mudar nada na grande transferência de um só utilizador.
Dois túneis separados podem dar-lhe dois candidatos, mas continuam a precisar de uma política deliberada que atribua tráfego e mantenha as respostas no caminho que levou o pedido. O encaminhamento assimétrico é o resultado habitual de saltar esse passo. O mínimo é uma política que nomeie o fluxo, a ligação preferida e a ligação de reserva.
A agregação Ethernet não atravessa fornecedores não relacionados, porque o extremo remoto tem de participar no protocolo de agregação. Uma agregação entre dois fornecedores de internet é um projeto de investigação a menos que exista um ponto final cooperante.
O que o TCP multipath exige nas duas pontas
A documentação do Linux sobre Multipath TCP descreve vários subfluxos que pertencem a uma ligação. O suporte do kernel numa ponta não muda nada por si só, já que o par também tem de aceitar esses subfluxos. Um proxy do lado remoto é a outra disposição comum, e torna-se um componente com a sua própria capacidade e disponibilidade a planear. A mesma lógica exclui uma resposta fácil para o WireGuard, cujo transporte é UDP: o MPTCP faz crescer subfluxos TCP e não pode agregar esse túnel sem outra coisa no projeto.
Verifique se a funcionalidade do kernel está ativa antes de projetar à volta dela, porque muitas distribuições entregam-na desligada. Estes três comandos respondem a isso num minuto.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showEscolha pela carga de trabalho, não pelo folheto
Se a carga de trabalho são muitas sessões independentes, o balanceamento por hash de fluxos pode acrescentar capacidade sem cooperação no extremo remoto. Se é uma transferência grande, só um projeto de agregação ajudará, e esse projeto precisa de um par cooperante. Se o requisito é que o trabalho continue quando uma ligação morre, a resposta é o failover e o débito de uma só transferência é irrelevante.
Escreva o requisito numa frase com um verbo dentro: uma cópia de segurança termina duas vezes mais depressa, ou uma ligação caída não termina uma sessão. Objetivos vagos produzem projetos que ninguém pode aceitar ou rejeitar. Depois decida o que o extremo remoto pode ser, porque a opção mais barata é muitas vezes a que não exige nada de novo lá. Essa restrição elimina a maioria das afirmações do folheto antes da primeira reunião.
Mantenha as três promessas separadas no documento de requisitos. Um projeto que reivindica as três costuma entregar uma e assumir em silêncio as outras. A secção seguinte testa qual é realmente entregue.
Teste uma transferência e muitas, e depois tire uma ligação
Compare uma transferência sustentada com várias transferências paralelas para o mesmo destino, e registe perda, atraso e utilização por ligação de cada uma. Um ganho só com sessões paralelas aponta para a distribuição de fluxos, não para a agregação de um único fluxo. Teste a perda de um uplink em separado, porque a capacidade enquanto as duas ligações funcionam não diz nada sobre failover para uma sessão estabelecida. Registe a rota, o socket e os contadores de retransmissão antes e depois de cada teste.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Quando a transferência única continua a usar um uplink, o projeto está a fazer exatamente o que um hash de fluxo implica. Quando as transferências paralelas se repartem pelos dois, o balanceamento funciona e a agregação não. Registe qual das três promessas o projeto cumpre de facto, e a próxima conversa sobre capacidade começa com provas em vez de uma afirmação do fornecedor.