দুটি আপলিংক, একটি টানেল: ফেলওভার, ব্যালান্সিং বা বন্ডিং
ফেলওভার, প্রতি-ফ্লো ব্যালান্সিং এবং একক-ফ্লো অ্যাগ্রিগেশন তিনটি ভিন্ন প্রতিশ্রুতি। দুটি ডিফল্ট রুট আপনাকে প্রথমটি দেয়, বাকি দুটি নয়।
দুটি ইন্টারনেট লাইন একটি VPN-কে আরও উপলব্ধ করতে পারে, এবং কিছু কাজের চাপে এটি দ্রুততরও করতে পারে, কিন্তু কোনটি ঘটবে তা নির্ধারণ করে প্রক্রিয়াটি। দুটি ডিফল্ট রুট থাকা রাউটার বন্ডেড নয়, এবং হাজারো অভ্যন্তরীণ সংযোগ বহনকারী একটি টানেল এখনও একটি বাইরের ফ্লো। প্রতিশ্রুতিটির নাম আগে দেওয়াই একটি নকশা আর একটি ব্যয়বহুল হতাশার মধ্যে পার্থক্য। নিচের সারণিটি প্রতিটি বিকল্পের দূর প্রান্তে কী দরকার এবং লিংক হারালে একটি স্থানান্তরে কী হয়, সেই অনুযায়ী সেগুলোকে আলাদা করে।
তিনটি প্রতিশ্রুতি, এবং একটিরই সঙ্গী দরকার
লিংক ফেলওভার পছন্দের লিংকটি হারিয়ে গেলে একটি পথ উপলব্ধ রাখে। ফ্লো-হ্যাশ ব্যালান্সিং স্বাধীন ফ্লোগুলোকে দুই আপলিংকে ছড়িয়ে দেয়। একক-ফ্লো অ্যাগ্রিগেশন একটি স্থানান্তরকে একসাথে দুই লিংক ব্যবহার করতে দেয়। এগুলো ভিন্ন প্রয়োজনীয়তাসম্পন্ন ভিন্ন পণ্য, এবং কেবল শেষটিরই আপনার রাউটারের বাইরের কোনো কিছুর সহযোগিতা দরকার।
| 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 |
ওই সারণিতে এমন কিছু নেই যা দ্বিতীয় লাইন কেনার কারণ। এটি করে একটিই কাজ: ফেলওভার নকশাকে বন্ডিং হিসেবে মূল্যায়ন করা থেকে বিরত রাখে।
কেন রাউটারের কাছে টানেল একটি একক ফ্লো-এর মতো দেখায়
লোড-ব্যালান্সিং রাউটার উৎস ও গন্তব্য ঠিকানাকে পোর্টের সাথে হ্যাশ করে, তারপর পুরো ফ্লোটি হ্যাশ যেখানে নির্দেশ করে সেখানে পাঠায়। রাউটারের দৃষ্টিতে একটি VPN টানেল এমনই একটি ফ্লো, ভেতরে যা-ই চলুক। অভ্যন্তরীণ সংযোগ কখনো হ্যাশের সিদ্ধান্তে পৌঁছায় না, কারণ বাইরের হেডার আগেই পথটি ঠিক করে ফেলেছে। এজন্যই একটি দ্বিতীয় আপলিংক অনেক ব্যবহারকারীর মোট ধারণক্ষমতা দ্বিগুণ করতে পারে, অথচ একজন ব্যবহারকারীর বড় স্থানান্তরে কিছুই বদলায় না।
দুটি আলাদা টানেল আপনাকে দুটি প্রার্থী দিতে পারে, কিন্তু তাদের তখনও একটি ইচ্ছাকৃত নীতি দরকার যা ট্রাফিক বণ্টন করে এবং অনুরোধ যে পথে গিয়েছিল সেই পথেই উত্তর রাখে। ওই ধাপটি বাদ দিলে অপ্রতিসম রাউটিং স্বাভাবিক ফল। ফ্লো, পছন্দের লিংক ও ফলব্যাক লিংকের নাম উল্লেখ করা নীতিই ন্যূনতম।
ইথারনেট বন্ডিং অসম্পর্কিত প্রদানকারীদের মধ্যে কাজ করে না, কারণ দূর প্রান্তকে অ্যাগ্রিগেশন প্রোটোকলে অংশ নিতে হয়। সহযোগী প্রান্ত না থাকলে দুই ISP-এর মধ্যে বন্ডিং একটি গবেষণা প্রকল্প।
মাল্টিপাথ TCP-র দুই প্রান্তেই কী দরকার
Linux-এর Multipath TCP ডকুমেন্টেশন একটি সংযোগের অন্তর্গত একাধিক সাবফ্লো বর্ণনা করে। এক প্রান্তে কার্নেল সমর্থন নিজে থেকে কিছুই বদলায় না, কারণ সমকক্ষকেও সেই সাবফ্লোগুলো গ্রহণ করতে হয়। দূর প্রান্তে প্রক্সি আরেকটি সাধারণ ব্যবস্থা, এবং এটি নিজের ধারণক্ষমতা ও প্রাপ্যতা নিয়ে পরিকল্পনা করার মতো একটি উপাদান হয়ে ওঠে। একই যুক্তি WireGuard-এর জন্য সহজ উত্তর বাদ দেয়, যার পরিবহন UDP: MPTCP TCP সাবফ্লো বাড়ায় এবং নকশায় অন্য কিছু ছাড়া ওই টানেল অ্যাগ্রিগেট করতে পারে না।
কার্নেল বৈশিষ্ট্যটি চালু আছে কি না তা নকশা করার আগে যাচাই করুন, কারণ অনেক ডিস্ট্রিবিউশন এটি বন্ধ অবস্থায় দেয়। এই তিনটি কমান্ড এক মিনিটে তার উত্তর দেয়।
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showব্রোশিওর নয়, কাজের চাপ দেখে বাছুন
যদি কাজের চাপ হয় অনেক স্বাধীন সেশন, তবে ফ্লো-হ্যাশ ব্যালান্সিং দূর প্রান্তের সহযোগিতা ছাড়াই ধারণক্ষমতা যোগ করতে পারে। যদি হয় একটি বড় স্থানান্তর, কেবল একটি অ্যাগ্রিগেশন নকশাই সাহায্য করবে, আর সেই নকশার একটি সহযোগী সমকক্ষ দরকার। যদি প্রয়োজন হয় লিংক মরে গেলেও কাজ চলবে, তবে উত্তর ফেলওভার এবং একটি স্থানান্তরের থ্রুপুট অপ্রাসঙ্গিক।
প্রয়োজনীয়তাটি একটি ক্রিয়াযুক্ত এক বাক্যে লিখুন: একটি ব্যাকআপ দ্বিগুণ দ্রুত শেষ হয়, অথবা হারানো লিংক একটি সেশন শেষ করে না। অস্পষ্ট লক্ষ্য এমন নকশা তৈরি করে যা কেউ গ্রহণও করতে পারে না, প্রত্যাখ্যানও করতে পারে না। তারপর ঠিক করুন দূর প্রান্ত কী হতে পারবে, কারণ সবচেয়ে সস্তা বিকল্প প্রায়ই সেইটি যা সেখানে নতুন কিছু চায় না। ওই সীমাবদ্ধতা প্রথম বৈঠকের আগেই ব্রোশিওরের বেশিরভাগ দাবি বাদ দেয়।
প্রয়োজনীয়তা নথিতে তিনটি প্রতিশ্রুতি আলাদা রাখুন। যে নকশা তিনটিরই দাবি করে সে সাধারণত একটি দেয় এবং বাকিগুলো নীরবে ধরে নেয়। পরের অংশটি পরীক্ষা করে আসলে কোনটি দেওয়া হচ্ছে।
একটি স্থানান্তর ও অনেকগুলো পরীক্ষা করুন, তারপর একটি লিংক টানুন
একটি ধারাবাহিক স্থানান্তরকে একই গন্তব্যে কয়েকটি সমান্তরাল স্থানান্তরের সাথে তুলনা করুন, এবং প্রতিটির জন্য ক্ষতি, বিলম্ব ও প্রতি-লিংক ব্যবহার লিপিবদ্ধ করুন। কেবল সমান্তরাল সেশনে লাভ হলে তা ফ্লো বিতরণের দিকে ইঙ্গিত করে, একক-ফ্লো অ্যাগ্রিগেশনের দিকে নয়। একটি আপলিংকের ক্ষতি আলাদাভাবে পরীক্ষা করুন, কারণ দুই লিংক চালু থাকা অবস্থায় ধারণক্ষমতা প্রতিষ্ঠিত সেশনের ফেলওভার সম্পর্কে কিছুই বলে না। প্রতিটি পরীক্ষার আগে ও পরে রুট, সকেট এবং পুনঃপ্রেরণ কাউন্টার ধরে রাখুন।
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5একক স্থানান্তর যখন এখনও একটি আপলিংক ব্যবহার করে, তখন নকশাটি ঠিক তাই করছে যা একটি ফ্লো হ্যাশ বোঝায়। যখন সমান্তরাল স্থানান্তর দুই লিংকে ছড়ায়, তখন ব্যালান্সিং কাজ করে আর অ্যাগ্রিগেশন করে না। নকশাটি তিনটি প্রতিশ্রুতির কোনটি সত্যিই রাখে তা লিপিবদ্ধ করুন, এবং পরের ধারণক্ষমতার আলোচনা বিক্রেতার দাবি নয়, প্রমাণ থেকে শুরু হবে।