Dous enlaces de subida pero un só túnel: conmutación, balanceo ou agregación
A conmutación por fallo, o balanceo por fluxo e a agregación dun só fluxo son tres promesas distintas. Dúas rutas por defecto danlle a primeira, e non as outras dúas.
Dúas liñas de internet poden facer que unha VPN estea máis dispoñible, e poden facela máis rápida para algunhas cargas de traballo, pero o mecanismo decide cal das dúas cousas ocorre. Un router con dúas rutas por defecto non está agregado, e un túnel que transporta miles de conexións internas segue sendo un único fluxo externo. Nomear a promesa primeiro é a diferenza entre un deseño e unha decepción custosa. A táboa de abaixo separa as opcións segundo o que cada unha necesita no extremo remoto e o que fai unha perda de enlace a unha transferencia.
Tres promesas, e só unha necesita un socio
A conmutación por fallo mantén un camiño dispoñible cando o enlace preferido desaparece. O balanceo por hash de fluxos reparte fluxos independentes entre ambos os enlaces de subida. A agregación dun só fluxo permite que unha transferencia use ambos os enlaces á vez. Son produtos distintos con requisitos distintos, e só o último necesita a cooperación de algo máis alá 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 desa táboa é un motivo para comprar unha segunda liña. O que fai é impedir que un deseño de conmutación se avalíe como se fose agregación.
Por que un túnel parece un único fluxo para o router
Un router que balancea carga aplica un hash ás direccións de orixe e destino xunto cos portos, e despois envía todo o fluxo alí onde apunta o hash. Un túnel VPN é un deses fluxos desde a perspectiva do router, sexa o que sexa o que corra dentro. As conexións internas nunca chegan á decisión do hash, porque a cabeceira externa xa decidiu o camiño. Por iso un segundo enlace de subida pode duplicar a capacidade total para moitos usuarios e non cambiar nada na transferencia grande dun só usuario.
Dous túneles separados poden darlles dous candidatos, pero seguen necesitando unha política deliberada que asigne o tráfico e manteña as respostas polo camiño que levou a petición. O encamiñamento asimétrico é o resultado habitual de saltar ese paso. O mínimo é unha política que nomee o fluxo, o enlace preferido e o enlace de reserva.
A agregación Ethernet non cruza provedores non relacionados, porque o extremo remoto ten que participar no protocolo de agregación. Unha agregación entre dous provedores de internet é un proxecto de investigación salvo que exista un extremo que coopere.
Que necesita o TCP multipath en ambos os extremos
A documentación de Linux sobre Multipath TCP describe varios subfluxos que pertencen a unha conexión. O soporte do núcleo nun extremo non converte nada por si só, xa que o par tamén ten que aceptar eses subfluxos. Un proxy no lado remoto é a outra disposición habitual, e convértese nun compoñente coa súa propia capacidade e dispoñibilidade que hai que planificar. A mesma lóxica descarta unha resposta doada para WireGuard, cuxo transporte é UDP: MPTCP fai medrar subfluxos TCP e non pode agregar ese túnel sen algo máis no deseño.
Comprobe se a función do núcleo está activada antes de deseñar ao seu redor, porque moitas distribucións entrégana desactivada. Estes tres comandos respóndeno nun minuto.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showEscolla pola carga de traballo, non polo folleto
Se a carga de traballo son moitas sesións independentes, o balanceo por hash de fluxos pode engadir capacidade sen cooperación no extremo remoto. Se é unha transferencia grande, só axudará un deseño de agregación, e ese deseño necesita un par que coopere. Se o requisito é que o traballo continúe cando morre un enlace, a resposta é a conmutación por fallo e o caudal dunha soa transferencia é irrelevante.
Escriba o requisito nunha frase cun verbo dentro: unha copia de seguridade remata o dobre de rápido, ou un enlace caído non remata unha sesión. Os obxectivos vagos producen deseños que ninguén pode aceptar nin rexeitar. Logo decida que se permite que sexa o extremo remoto, porque a opción máis barata adoita ser a que non esixe nada novo alí. Esa restrición elimina a maioría das afirmacións do folleto antes da primeira reunión.
Manteña as tres promesas separadas no documento de requisitos. Un deseño que afirma as tres normalmente entrega unha e asume en silencio as outras. A sección seguinte comproba cal se entrega de verdade.
Probe unha transferencia e moitas, e despois tire un enlace
Compare unha transferencia sostida con varias transferencias paralelas ao mesmo destino, e rexistre a perda, o retardo e a utilización por enlace de cada unha. Unha ganancia só con sesións paralelas apunta á distribución de fluxos, non á agregación dun só fluxo. Probe a perda dun enlace de subida por separado, porque a capacidade mentres ambos os enlaces funcionan non di nada sobre a conmutación para unha sesión establecida. Capture a ruta, o socket e os contadores de retransmisión antes e despois de cada proba.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Cando a transferencia única segue usando un enlace de subida, o deseño fai exactamente o que implica un hash de fluxo. Cando as transferencias paralelas se reparten entre ambos, o balanceo funciona e a agregación non. Rexistre cal das tres promesas mantén realmente o deseño, e a próxima conversación sobre capacidade comezará con probas en lugar dunha afirmación do provedor.