دو کابل چه مسئله‌ای را حل می‌کنند؟
وصل کردن دو کارت شبکه به دو درگاه، به خودی خود یک مسیر مقاوم یا سریع‌تر نمی‌سازد. باید مشخص باشد سیستم عامل و تجهیزات شبکه چگونه این مسیرها را می‌بینند و هنگام خرابی کدام تصمیم را می‌گیرند. در Linux، درایور bonding می‌تواند چند رابط را زیر یک رابط منطقی قرار دهد. رفتار این مجموعه به حالت انتخابی، پایش سلامت و تنظیم طرف مقابل وابسته است. هدف ممکن است ادامه کار پس از قطع کابل باشد یا توزیع چند جریان روی ظرفیت چند لینک؛ این دو هدف با وجود شباهت ظاهری، قرارداد عملیاتی یکسانی ندارند.
برای شروع، نیاز را به زبان قابل آزمون بنویسید. جمله «شبکه باید افزونه باشد» کافی نیست. آیا خرابی کارت، کابل، درگاه یا کل سوییچ باید تحمل شود؟ چه مدت قطع قابل قبول است و کدام برنامه باید در حین جابه‌جایی ارتباطش را حفظ کند؟ همچنین روشن کنید افزایش ظرفیت برای مجموع کاربران لازم است یا برای یک انتقال بزرگ منفرد. پاسخ این پرسش‌ها انتخاب حالت را هدایت می‌کند. بدون این مرحله ممکن است دو لینک سالم داشته باشید اما همان نقطه شکست قبلی یا همان محدودیت سرعت تک‌جریان باقی بماند.
active-backup و معنای لینک فعال
در حالت active-backup فقط یک عضو در هر لحظه مسیر فعال است و در صورت شکست، عضو دیگری جای آن را می‌گیرد. این حالت برای افزونگی طراحی شده و نباید انتظار جمع شدن پهنای باند همه اعضا را از آن داشت. برای بسیاری از میزبان‌هایی که ظرفیت یک لینک کافی است، چنین مدلی ساده و قابل فهم است. با این حال سادگی حالت به معنی بی‌نیازی از طراحی شبکه نیست. دو عضو باید بتوانند همان شبکه مورد نیاز را فراهم کنند و تغییر عضو نباید میزبان را به محیطی با VLAN یا سیاست متفاوت ببرد.
نشانی MAC و یادگیری آن در تجهیزات بالادست هنگام جابه‌جایی اهمیت پیدا می‌کند. در مستندات هسته، رفتار اعلان‌های gratuitous ARP هنگام failover برای این حالت توضیح داده شده است. هدف این اعلان‌ها کمک به به‌روزرسانی برداشت همسایه‌ها از مسیر رسیدن به میزبان است، اما نتیجه نهایی به رفتار شبکه نیز وابسته است. تنظیمات امنیت درگاه، محدودیت جابه‌جایی MAC یا سیاست‌های مجازی‌سازی می‌توانند مانع شوند. بنابراین آزمایش نباید فقط نشان دهد رابط جدید active شده؛ رسیدن ترافیک واقعی پس از جابه‌جایی هم باید بررسی شود.
LACP و توافق با سوییچ
حالت 802.3ad تجمیع پویای لینک را با سازوکار مرتبط با LACP فراهم می‌کند. اعضای گروه باید از نظر سرعت و duplex شرایط سازگار داشته باشند و سوییچ نیز تجمیع مناسب را پشتیبانی و پیکربندی کند. ساخت bond در میزبان بدون تنظیم متناظر در طرف مقابل، یک گروه سالم ایجاد نمی‌کند. باید شماره گروه، اعضا، حالت مذاکره و ویژگی‌های هر درگاه در هر دو سمت تطبیق داشته باشند. تفاوت یک عضو می‌تواند بخشی از ترافیک را خراب کند و خطایی بسازد که در تست ساده همیشه دیده نمی‌شود.
دو کابل متصل به دو سوییچ مستقل را نباید بدون طراحی پشتیبانی‌شده یک گروه LACP واحد فرض کرد. اگر تجهیزات از فناوری مناسب چندشاسی یا یکپارچه‌سازی پشتیبانی می‌کنند، قرارداد آن فناوری و نحوه ارائه همتای منطقی باید بررسی شود. جزئیات آن به سازنده و مدل وابسته است. اتصال پراکنده به دو دستگاه معمولی همان افزونگی ادعاشده را تضمین نمی‌کند. در مستند طراحی باید روشن باشد میزبان یک همتای تجمیع می‌بیند یا چند مسیر مستقل، و شکست ارتباط میان سوییچ‌ها چه اثری بر دسترسی خواهد داشت.
چرا یک دانلود دو برابر نمی‌شود؟
در بسیاری از حالت‌های تجمیع، انتخاب لینک بر اساس یک تابع هش از مشخصات ترافیک انجام می‌شود. هدف حفظ نظم بسته‌های یک جریان و توزیع جریان‌های مختلف میان اعضاست. در نتیجه یک جریان TCP معمولاً روی یک عضو قرار می‌گیرد و سقف سرعت همان عضو همچنان مهم است. دو لینک ده‌گیگابیتی می‌توانند برای مجموع چند جریان ظرفیت بیشتری فراهم کنند، ولی این موضوع وعده انتقال بیست‌گیگابیتی برای هر ارتباط منفرد نیست. نتیجه تست تک‌اتصال نباید به عنوان شکست قطعی تجمیع تفسیر شود.
تنوع ورودی هش نیز تعیین‌کننده است. اگر سیاست تنها مشخصات لایه‌ای را ببیند که برای همه ترافیک یکسان است، ممکن است بیشتر بار روی یک عضو بیفتد. برای مثال تعداد زیادی ارتباط از پشت یک دروازه می‌تواند از نگاه برخی سیاست‌ها تنوع کمی داشته باشد. گزینه xmit_hash_policy در میزبان به انتخاب مسیر خروجی مربوط است؛ مسیر ورودی را تصمیم سمت مقابل نیز شکل می‌دهد. تغییر سیاست میزبان لزوماً عدم تعادل ورودی را اصلاح نمی‌کند. تحلیل باید هر دو جهت را جدا ببیند و با شمارنده‌های هر درگاه تطبیق دهد.
سیاست هش و نظم بسته‌ها
انتخاب سیاست هش فقط مسئله بیشترین توزیع نیست. مستندات bonding درباره سازگاری برخی سیاست‌ها با الزامات ترتیب بسته در 802.3ad هشدار می‌دهند. جزئیات بسته‌های قطعه‌قطعه و فیلدهایی که برای هش در دسترس هستند می‌تواند اثر داشته باشد. به همین دلیل نباید یک سیاست را صرفاً چون در یک آزمون سرعت عدد بیشتری ساخته برای همه محیط‌ها توصیه کرد. نوع ترافیک، تونل‌ها، اندازه بسته و رفتار همتای شبکه باید در آزمون حضور داشته باشند.
در شبکه‌ای با تونل، بسته بیرونی ممکن است تنوع کمی داشته باشد، در حالی که جریان‌های داخلی متعددند. امکانات نسخه هسته و سیاست‌های پشتیبانی‌شده را باید از مستندات همان محیط بررسی کرد. اگر توزیع مناسب حاصل نشود، ابتدا ورودی واقعی هش را بفهمید و سپس تغییر دهید. افزودن جریان بیشتر به ابزار آزمون بدون شناخت این موضوع می‌تواند نتیجه‌ای خوش‌بینانه بسازد که در بار واقعی تکرار نمی‌شود. شاخص پذیرش باید توزیع و کارایی برنامه واقعی را شامل شود، نه فقط بیشترین عدد یک ابزار آزمایشگاهی.
پایش لینک با تشخیص دسترسی فرق دارد
گزینه miimon وضعیت لینک را در فاصله‌های مشخص بررسی می‌کند. این روش برای تشخیص بسیاری از شکست‌های فیزیکی مفید است، اما بالا بودن carrier لزوماً به معنی رسیدن به مقصد کاربردی نیست. ممکن است کابل و درگاه سالم باشند ولی مسیر بالادست قطع شده باشد. بنابراین باید معلوم شود دقیقاً کدام نوع خرابی با پایش انتخابی دیده می‌شود. اگر نیاز تحمل خرابی خارج از لینک محلی است، طراحی شبکه و روش پایش باید آن را پوشش دهند؛ سبز بودن چراغ کارت پاسخ کامل نیست.
پایش مبتنی بر ARP با گزینه‌هایی مانند arp_interval و arp_ip_target مدل دیگری از بررسی دسترسی فراهم می‌کند، اما سازگاری آن با حالت انتخابی و محدودیت‌هایش باید از مستندات بررسی شود. مقصد پایش باید معنی‌دار باشد و خودش به نقطه شکست گمراه‌کننده تبدیل نشود. پاسخ گرفتن از یک همسایه نزدیک، صحت همه مسیرهای برنامه را ثابت نمی‌کند. همچنین ترکیب روش‌های پایش را نباید بدون بررسی پشتیبانی و معنا انجام داد. هر سنجه باید به یک نوع خرابی مورد انتظار و یک تصمیم روشن متصل باشد.
زمان تشخیص و جابه‌جایی
قطع قابل مشاهده فقط از فاصله بررسی لینک تشکیل نمی‌شود. تشخیص خرابی، انتخاب عضو، یادگیری تجهیزات و تلاش دوباره برنامه همگی در زمان بازیابی نقش دارند. کوچک کردن یک فاصله ممکن است تشخیص را سریع‌تر کند، اما حساسیت به نوسان را بالا ببرد یا مشکل دیگری را آشکار کند. گزینه‌های تأخیر بالا و پایین آمدن لینک نیز باید با رفتار تجهیزات هماهنگ شوند. هدف جلوگیری از رفت‌وبرگشت بی‌دلیل میان اعضاست، بدون اینکه شکست واقعی برای مدت طولانی پنهان بماند.
اگر عضو اصلی پس از خرابی بازگردد، سیاست انتخاب مجدد آن اهمیت دارد. بازگشت خودکار می‌تواند مسیر ترجیحی را برقرار کند ولی یک جابه‌جایی دیگر نیز ایجاد می‌کند. برای برخی سرویس‌ها ثبات مسیر پس از failover ارزش بیشتری دارد. این رفتار باید در قرارداد تست نوشته شود: آیا پس از وصل کردن کابل انتظار بازگشت داریم یا باقی ماندن روی عضو سالم؟ بررسی فقط لحظه قطع، نیمی از داستان است؛ بازگشت تجهیزات و نوسان پی‌درپی نیز باید آزمایش شوند.
پیکربندی پایدار و مالک تنظیمات
در یک میزبان ممکن است NetworkManager، systemd-networkd یا ابزار دیگری مالک پیکربندی شبکه باشد. ترکیب فرمان‌های موقت با چند مدیر مستقل می‌تواند وضعیت زنده و فایل‌های پایدار را از هم جدا کند. پیش از تغییر باید مالک رابط‌ها، محل تعریف IP و مسیرها مشخص شوند. معمولاً آدرس کاربردی روی رابط منطقی یا لایه مناسب بالای آن قرار می‌گیرد، نه اینکه بدون برنامه روی همه اعضا تکثیر شود. جزئیات VLAN و bridge نیز باید در طراحی ترتیب لایه‌ها روشن باشد.
برای تغییر از راه دور، مسیر مدیریتی جایگزین یا کنسول قابل دسترسی اهمیت عملی دارد. جابه‌جایی عضو یا انتقال آدرس ممکن است همان ارتباطی را قطع کند که برای اصلاح تنظیمات استفاده می‌شود. نمونه فرمان عمومی که نام رابط و شبکه را حدس بزند مناسب همه میزبان‌ها نیست. بهتر است ابتدا پیکربندی مورد نظر روی محیط مشابه آزمایش شود و سپس با پنجره تغییر و مسیر بازگشت اجرا گردد. پس از راه‌اندازی مجدد نیز باید وضعیت پایدار با وضعیت مورد انتظار تطبیق داده شود.
مشاهده وضعیت به جای حدس
اطلاعات رابط منطقی، وضعیت اعضا و شمارنده‌ها باید کنار هم خوانده شوند. فایل وضعیت bonding جزئیات حالت و اعضا را نشان می‌دهد و ابزارهای عمومی شبکه نیز به بررسی carrier و آمار کمک می‌کنند. نام bond0 در فرمان‌های زیر نمونه است و باید با رابط واقعی جایگزین شود. مشاهده این خروجی‌ها تغییری در پیکربندی ایجاد نمی‌کند، اما برای تفسیر درست همچنان نیازمند شناخت حالت و طراحی شبکه است.
ip -d link show bond0
cat /proc/net/bonding/bond0
ip -s link show
در LACP اطلاعات تجمیع و همتا را با خروجی سوییچ مقایسه کنید. وجود هر دو عضو در فهرست به تنهایی ثابت نمی‌کند هر دو در گروه فعال مورد انتظار شرکت دارند. سرعت و duplex، وضعیت مذاکره و شمارنده خطا می‌توانند علت عضو کم‌کار را روشن کنند. همچنین شمارنده کل بایت باید در یک بازه زمانی مقایسه شود؛ اختلاف تاریخی از زمان راه‌اندازی ممکن است درباره بار فعلی گمراه‌کننده باشد. ثبت دو نمونه با فاصله مشخص، نرخ هر عضو را قابل مقایسه‌تر می‌کند.
برنامه آزمون خرابی و ظرفیت
آزمون باید چند لایه داشته باشد. نخست دسترسی عادی و سپس قطع یک کابل بررسی شود. بعد، خرابی درگاه یا مسیر بالادست در حد مجاز محیط آزمایش شبیه‌سازی شود تا مرز پایش روشن شود. در تمام این مراحل یک ارتباط طولانی و چند درخواست تازه را مشاهده کنید، چون ادامه جریان موجود و ایجاد جریان جدید ممکن است رفتار متفاوتی داشته باشند. زمان بازیابی از نگاه برنامه ثبت شود و صرف تغییر وضعیت رابط پایان آزمون محسوب نشود.
برای ظرفیت، یک جریان و چند جریان مستقل را جدا اندازه بگیرید و هم‌زمان بار پردازنده، محدودیت مقصد و شمارنده هر عضو را ثبت کنید. اگر مقصد یا ذخیره‌سازی گلوگاه باشد، نتیجه پایین لزوماً از bonding نیست. پس از بازگرداندن عضو قطع‌شده، توزیع و پایداری دوباره بررسی شوند. یک پیکربندی قابل اتکا باید هم وعده افزونگی خود را در خرابی مشخص انجام دهد و هم محدودیت ظرفیتش قابل توضیح باشد. در این صورت دو کابل بخشی از یک طراحی آزموده‌اند، نه صرفاً نشانه ظاهری مقاوم بودن شبکه.
