Twee opverbindings maar een tonnel: foutoorskakeling, balansering of koppeling
Foutoorskakeling, balansering per vloei en samevoeging van ’n enkele vloei is drie verskillende beloftes. Twee verstekroetes gee jou die eerste, en nie die ander twee nie.
Twee internetlyne kan ’n VPN meer beskikbaar maak, en hulle kan dit vir sommige werkladinge vinniger maak, maar die meganisme bepaal watter van dié twee gebeur. ’n Roeteerder met twee verstekroetes is nie gekoppel nie, en ’n tonnel wat duisende binneste verbindings dra, is steeds een buitenste vloei. Om die belofte eerste te benoem, is die verskil tussen ’n ontwerp en ’n duur teleurstelling. Die tabel hieronder skei die opsies volgens wat elkeen aan die ander kant nodig het en wat ’n skakelverlies aan ’n oordrag doen.
Drie beloftes, en net een het ’n maat nodig
Foutoorskakeling hou ’n pad beskikbaar wanneer die voorkeur-skakel verdwyn. Vloeihash-balansering versprei onafhanklike vloeie oor albei opverbindings. Samevoeging van ’n enkele vloei laat een oordrag albei skakels gelyktydig gebruik. Dit is verskillende produkte met verskillende vereistes, en net die laaste een het samewerking van iets buite jou roeteerder nodig.
| 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 |
Niets in daardie tabel is ’n rede om ’n tweede lyn te koop nie. Wat dit doen, is om te verhoed dat ’n foutoorskakelingsontwerp beoordeel word asof dit koppeling is.
Waarom ’n tonnel vir die roeteerder soos een vloei lyk
’n Lasbalanserende roeteerder hash bron- en bestemmingsadresse saam met poorte en stuur dan die hele vloei waar die hash wys. ’n VPN-tonnel is vanuit die roeteerder se perspektief een so ’n vloei, ongeag wat binne-in dit loop. Binneste verbindings bereik nooit die hash-besluit nie, want die buitenste kop het reeds die pad bepaal. Dit is waarom ’n tweede opverbinding die totale kapasiteit vir baie gebruikers kan verdubbel en niks vir een gebruiker se groot oordrag kan verander nie.
Twee afsonderlike tonnele kan jou twee kandidate gee, maar hulle het steeds ’n doelbewuste beleid nodig wat verkeer toewys en antwoorde op die pad hou wat die versoek gedra het. Asimmetriese roetering is die gewone gevolg as daardie stap oorgeslaan word. ’n Beleid wat die vloei, die voorkeur-skakel en die terugvalskakel benoem, is die minimum.
Ethernet-koppeling kruis nie onverwante verskaffers nie, want die ander kant moet aan die samevoegingsprotokol deelneem. ’n Koppeling oor twee ISP's is ’n navorsingsprojek tensy ’n samewerkende eindpunt bestaan.
Wat multipad-TCP aan albei kante nodig het
Linux se dokumentasie oor Multipath TCP beskryf verskeie substrome wat aan een verbinding behoort. Kernondersteuning aan een kant verander niks op sigself nie, want die eweknie moet ook daardie substrome aanvaar. ’n Instaanbediener aan die ander kant is die ander algemene reëling, en dit word ’n komponent met sy eie kapasiteit en beskikbaarheid om voor te beplan. Dieselfde logika sluit ’n maklike antwoord vir WireGuard uit, wie se vervoer UDP is: MPTCP groei TCP-substrome en kan daardie tonnel nie samevoeg sonder iets anders in die ontwerp nie.
Kontroleer of die kernkenmerk geaktiveer is voordat jy daarom ontwerp, want baie verspreidings lewer dit afgeskakel. Hierdie drie opdragte beantwoord dit in ’n minuut.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showKies uit die werklading, nie die brosjure nie
As die werklading baie onafhanklike sessies is, kan vloeihash-balansering kapasiteit byvoeg sonder samewerking aan die ander kant. As dit een groot oordrag is, sal net ’n samevoegingsontwerp help, en daardie ontwerp het ’n samewerkende eweknie nodig. As die vereiste is dat werk voortduur wanneer ’n skakel sterf, is foutoorskakeling die antwoord en is die deurset van ’n enkele oordrag irrelevant.
Skryf die vereiste in een sin met ’n werkwoord in: een rugsteun voltooi twee keer so vinnig, of ’n verlore skakel beëindig nie ’n sessie nie. Vae doelwitte lewer ontwerpe wat niemand kan aanvaar of verwerp nie. Besluit dan wat die ander kant mag wees, want die goedkoopste opsie is dikwels die een wat niks nuuts daar vereis nie. Daardie beperking skakel die meeste brosjurebewerings uit voor die eerste vergadering.
Hou die drie beloftes apart in die vereistedokument. ’n Ontwerp wat al drie eis, lewer gewoonlik een en aanvaar stilweg die ander. Die volgende afdeling toets watter een werklik gelewer word.
Toets een oordrag en baie, trek dan ’n skakel
Vergelyk een volgehoue oordrag met verskeie parallelle oordragte na dieselfde bestemming, en teken verlies, vertraging en benutting per skakel vir elkeen aan. ’n Wins net met parallelle sessies wys op vloeiverspreiding, nie op samevoeging van ’n enkele vloei nie. Toets die verlies van een opverbinding afsonderlik, want kapasiteit terwyl albei skakels werk sê niks oor foutoorskakeling vir ’n gevestigde sessie nie. Neem die roete, die sok en die herversendingstellers voor en na elke toets op.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Wanneer die enkele oordrag steeds een opverbinding gebruik, doen die ontwerp presies wat ’n vloeihash impliseer. Wanneer parallelle oordragte oor albei versprei, werk balansering en werk samevoeging nie. Teken aan watter van die drie beloftes die ontwerp werklik hou, en die volgende kapasiteitsgesprek begin met bewyse in plaas van ’n verskaffer se bewering.