Twee uplinks maar één tunnel: failover, balanceren of bundelen
Failover, balanceren per stroom en het bundelen van één stroom zijn drie verschillende beloften. Twee standaardroutes geven u de eerste, en niet de andere twee.
Twee internetlijnen kunnen een VPN beschikbaarder maken, en ze kunnen hem voor sommige workloads sneller maken, maar het mechanisme bepaalt welke van de twee gebeurt. Een router met twee standaardroutes is niet gebundeld, en een tunnel die duizenden interne verbindingen draagt is nog steeds één buitenste stroom. Het belofte eerst benoemen is het verschil tussen een ontwerp en een dure teleurstelling. De tabel hieronder scheidt de opties naar wat elk aan de verre kant nodig heeft en wat een linkverlies met een overdracht doet.
Drie beloften, en slechts één heeft een partner nodig
Failover houdt een pad beschikbaar wanneer de voorkeurslink verdwijnt. Balanceren op stroomhash verdeelt onafhankelijke stromen over beide uplinks. Het bundelen van één stroom laat één overdracht beide links tegelijk gebruiken. Dat zijn verschillende producten met verschillende eisen, en alleen de laatste heeft samenwerking nodig van iets buiten uw 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 |
Niets in die tabel is een reden om een tweede lijn te kopen. Wat hij doet is voorkomen dat een failoverontwerp wordt beoordeeld alsof het bundeling is.
Waarom een tunnel voor de router op één stroom lijkt
Een router die belasting balanceert hasht bron- en bestemmingsadressen samen met poorten en stuurt vervolgens de hele stroom waar de hash naartoe wijst. Een VPN-tunnel is vanuit het perspectief van de router één zo'n stroom, wat er ook in draait. Interne verbindingen bereiken nooit de hashbeslissing, omdat de buitenste header het pad al heeft bepaald. Daarom kan een tweede uplink de totale capaciteit voor veel gebruikers verdubbelen en niets veranderen aan de grote overdracht van één gebruiker.
Twee aparte tunnels kunnen u twee kandidaten geven, maar ze hebben nog steeds een bewust beleid nodig dat verkeer toewijst en antwoorden op het pad houdt dat het verzoek droeg. Asymmetrische routering is het gebruikelijke gevolg van het overslaan van die stap. Het minimum is een beleid dat de stroom, de voorkeurslink en de reservelink benoemt.
Ethernet-bundeling gaat niet over ongerelateerde providers heen, omdat de verre kant aan het aggregatieprotocol moet deelnemen. Een bundel over twee providers is een onderzoeksproject tenzij er een samenwerkend eindpunt bestaat.
Wat multipath-TCP aan beide kanten nodig heeft
De Linux-documentatie over Multipath TCP beschrijft meerdere substromen die bij één verbinding horen. Kernelondersteuning aan één kant verandert op zichzelf niets, omdat de tegenpartij die substromen ook moet accepteren. Een proxy aan de verre kant is de andere gangbare opstelling, en die wordt een component met eigen capaciteit en beschikbaarheid waarvoor moet worden gepland. Dezelfde logica sluit een eenvoudig antwoord voor WireGuard uit, waarvan het transport UDP is: MPTCP laat TCP-substromen groeien en kan die tunnel niet bundelen zonder iets anders in het ontwerp.
Controleer of de kernelfunctie is ingeschakeld voordat u eromheen ontwerpt, want veel distributies leveren hem uitgeschakeld. Deze drie opdrachten beantwoorden dat in een minuut.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showKies op basis van de workload, niet van de brochure
Als de workload veel onafhankelijke sessies is, kan balanceren op stroomhash capaciteit toevoegen zonder samenwerking aan de verre kant. Als het één grote overdracht is, helpt alleen een aggregatieontwerp, en dat ontwerp heeft een samenwerkende tegenpartij nodig. Als de eis is dat werk doorgaat wanneer een link sterft, is failover het antwoord en is de doorvoer van één overdracht irrelevant.
Schrijf de eis in één zin met een werkwoord erin: één back-up is twee keer zo snel klaar, of een uitgevallen link beëindigt geen sessie. Vage doelen leveren ontwerpen op die niemand kan accepteren of afwijzen. Beslis daarna wat de verre kant mag zijn, want de goedkoopste optie is vaak degene die daar niets nieuws vraagt. Die beperking schrapt de meeste brochurebeweringen nog voor de eerste vergadering.
Houd de drie beloften gescheiden in het eisendocument. Een ontwerp dat alle drie claimt, levert er meestal één en veronderstelt stilzwijgend de andere. De volgende sectie test welke daadwerkelijk wordt geleverd.
Test één overdracht en veel, trek dan een link eruit
Vergelijk één aanhoudende overdracht met meerdere parallelle overdrachten naar dezelfde bestemming, en noteer verlies, vertraging en benutting per link voor elk. Winst alleen bij parallelle sessies wijst op stroomverdeling, niet op het bundelen van één stroom. Test het verlies van één uplink apart, want capaciteit terwijl beide links werken zegt niets over failover voor een bestaande sessie. Leg de route, de socket en de herverzendtellers vast voor en na elke test.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Wanneer de enkele overdracht nog steeds één uplink gebruikt, doet het ontwerp precies wat een stroomhash impliceert. Wanneer parallelle overdrachten over beide worden verdeeld, werkt het balanceren en het bundelen niet. Noteer welke van de drie beloften het ontwerp werkelijk houdt, en het volgende capaciteitsgesprek begint met bewijs in plaats van een leveranciersclaim.