Dua uplink tetapi satu terowongan: failover, penyeimbangan, atau bonding
Failover, penyeimbangan per aliran, dan penggabungan satu aliran adalah tiga janji yang berbeda. Dua rute default memberi Anda yang pertama, bukan dua yang lain.
Dua jalur internet dapat membuat VPN lebih tersedia, dan dapat membuatnya lebih cepat untuk sebagian beban kerja, tetapi mekanismelah yang menentukan mana dari keduanya yang terjadi. Router dengan dua rute default tidak di-bonding, dan terowongan yang membawa ribuan koneksi dalam tetap satu aliran luar. Menamai janji lebih dulu adalah perbedaan antara rancangan dan kekecewaan yang mahal. Tabel di bawah memisahkan pilihan menurut apa yang dibutuhkan masing-masing di ujung jauh dan apa yang dilakukan kehilangan tautan terhadap sebuah transfer.
Tiga janji, dan hanya satu yang butuh mitra
Failover menjaga jalur tetap tersedia ketika tautan pilihan hilang. Penyeimbangan hash aliran menyebarkan aliran independen ke kedua uplink. Penggabungan satu aliran memungkinkan satu transfer memakai kedua tautan sekaligus. Itu produk berbeda dengan persyaratan berbeda, dan hanya yang terakhir membutuhkan kerja sama dari sesuatu di luar router Anda.
| 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 |
Tidak ada apa pun di tabel itu yang menjadi alasan membeli jalur kedua. Yang dilakukannya adalah mencegah rancangan failover dinilai seolah-olah itu bonding.
Mengapa terowongan tampak sebagai satu aliran bagi router
Router yang menyeimbangkan beban melakukan hash pada alamat sumber dan tujuan bersama port, lalu mengirim seluruh aliran ke tempat hash menunjuk. Terowongan VPN adalah satu aliran seperti itu dari sudut pandang router, apa pun yang berjalan di dalamnya. Koneksi dalam tidak pernah mencapai keputusan hash, karena header luar sudah menentukan jalurnya. Itulah sebabnya uplink kedua dapat menggandakan kapasitas total bagi banyak pengguna dan tidak mengubah apa pun pada transfer besar satu pengguna.
Dua terowongan terpisah dapat memberi Anda dua kandidat, tetapi keduanya masih membutuhkan kebijakan yang disengaja untuk menetapkan lalu lintas dan menjaga balasan pada jalur yang membawa permintaan. Perutean asimetris adalah hasil lazim dari melewati langkah itu. Minimumnya adalah kebijakan yang menamai aliran, tautan pilihan, dan tautan cadangan.
Bonding Ethernet tidak melintasi penyedia yang tidak terkait, karena ujung jauh harus berpartisipasi dalam protokol agregasi. Bonding melintasi dua ISP adalah proyek riset kecuali ada titik akhir yang bekerja sama.
Apa yang dibutuhkan TCP multipath di kedua ujung
Dokumentasi Linux tentang Multipath TCP menjelaskan beberapa subaliran yang termasuk dalam satu koneksi. Dukungan kernel di satu ujung tidak mengubah apa pun dengan sendirinya, karena rekan juga harus menerima subaliran itu. Proksi di sisi jauh adalah susunan umum lainnya, dan ia menjadi komponen dengan kapasitas serta ketersediaan sendiri yang harus direncanakan. Logika yang sama menyingkirkan jawaban mudah untuk WireGuard, yang transpor UDP: MPTCP menumbuhkan subaliran TCP dan tidak dapat menggabungkan terowongan itu tanpa sesuatu yang lain dalam rancangan.
Periksa apakah fitur kernel diaktifkan sebelum merancang di sekitarnya, karena banyak distribusi mengirimkannya dalam keadaan mati. Ketiga perintah ini menjawabnya dalam satu menit.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showPilih dari beban kerja, bukan dari brosur
Jika beban kerjanya banyak sesi independen, penyeimbangan hash aliran dapat menambah kapasitas tanpa kerja sama di ujung jauh. Jika satu transfer besar, hanya rancangan agregasi yang akan membantu, dan rancangan itu membutuhkan rekan yang bekerja sama. Jika persyaratannya adalah pekerjaan berlanjut ketika tautan mati, jawabannya failover dan throughput satu transfer tidak relevan.
Tulis persyaratan dalam satu kalimat dengan kata kerja di dalamnya: satu cadangan selesai dua kali lebih cepat, atau tautan yang putus tidak mengakhiri sesi. Tujuan yang kabur menghasilkan rancangan yang tidak dapat diterima atau ditolak siapa pun. Lalu putuskan apa ujung jauh boleh menjadi, karena pilihan termurah sering kali yang tidak menuntut sesuatu yang baru di sana. Batasan itu menyingkirkan sebagian besar klaim brosur sebelum rapat pertama.
Jaga ketiga janji tetap terpisah dalam dokumen persyaratan. Rancangan yang mengklaim ketiganya biasanya memberikan satu dan diam-diam mengasumsikan yang lain. Bagian berikutnya menguji mana yang benar-benar diberikan.
Uji satu transfer dan banyak, lalu cabut satu tautan
Bandingkan satu transfer berkelanjutan dengan beberapa transfer paralel ke tujuan yang sama, dan catat kehilangan, tunda, serta pemanfaatan per tautan untuk masing-masing. Keuntungan hanya pada sesi paralel menunjuk pada distribusi aliran, bukan pada penggabungan satu aliran. Uji kehilangan satu uplink secara terpisah, karena kapasitas saat kedua tautan bekerja tidak mengatakan apa pun tentang failover untuk sesi yang sudah terbentuk. Catat rute, soket, dan penghitung pengiriman ulang sebelum dan sesudah setiap uji.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Ketika transfer tunggal masih memakai satu uplink, rancangan itu melakukan persis apa yang tersirat dari hash aliran. Ketika transfer paralel menyebar ke keduanya, penyeimbangan bekerja dan penggabungan tidak. Catat janji mana dari ketiganya yang benar-benar dipenuhi rancangan, dan percakapan kapasitas berikutnya dimulai dari bukti, bukan dari klaim vendor.