وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

دو پورت شبکه سرور را چطور استفاده کنیم؟ تفاوت Active-backup و LACP

دو پورت شبکه سرور را برای پایداری یا افزایش ظرفیت چطور انتخاب کنیم؟ نیاز سوئیچ، محدودیت سرعت یک اتصال و آزمایش Bond را یاد بگیرید.

انتشار:
توسط تیم فنی نت‌آرام
۷ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله دو پورت شبکه سرور را چطور استفاده کنیم؟ تفاوت Active-backup و LACP در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
سرور اختصاصی شما دو پورت شبکه دارد. شاید بخواهید اگر یکی از کابل‌ها قطع شد، سایت از دسترس خارج نشود. یا انتظار داشته باشید دو پورت یک‌گیگابیتی، یک دانلود تک‌اتصالی را دو گیگابیتی کنند. دو حالت رایج Active-backup و LACP یا 802.3ad برای هدف‌های متفاوتی به کار می‌روند و تنظیم سرور به‌تنهایی کافی نیست.
این راهنما کمک می‌کند پیش از تغییر شبکه، حالت مناسب را انتخاب کنید و نتیجه را در یک محیط آزمایشی ببینید. تغییر نادرست شبکه می‌تواند SSH و سایت را قطع کند؛ روی سرور فعال فقط با کنسول جایگزین، نقشه شبکه، تنظیمات قابل بازگشت و هماهنگی دیتاسنتر اقدام کنید.

Bond شبکه یعنی چه؟

در لینوکس می‌توان چند رابط شبکه را در یک رابط منطقی به نام bond قرار داد. به زبان ساده، سیستم تعدادی مسیر فیزیکی را به‌صورت یک مجموعه مدیریت می‌کند. نام رابط منطقی می‌تواند مثلاً bond0 باشد، اما نام واقعی سرور شما ممکن است فرق کند.
این کار جای پشتیبان‌گیری یا طراحی کامل شبکه را نمی‌گیرد. اگر هر دو کابل به همان سوئیچ، همان منبع برق یا همان مسیر بالادستی وابسته باشند، خرابی مشترک آن بخش هنوز می‌تواند هر دو مسیر را قطع کند. دو کابل الزاماً به معنی دو مسیر مستقل تا اینترنت نیست.

Active-backup: اولویت با پایداری اتصال

در حالت Active-backup معمولاً یک عضو فعال است و عضو دیگر در صورت تشخیص خرابی می‌تواند جای آن را بگیرد. فرض کنید هر دو پورت یک گیگابیت دارند: در حالت معمول، این طراحی برای تحمل خرابی یک مسیر است و نباید آن را دو گیگابیت سرعت یک اتصال حساب کنید.
برای این حالت معمولاً لازم نیست سوئیچ یک گروه LACP بسازد، ولی پورت‌های سوئیچ همچنان باید از نظر VLAN، دسترسی، آدرس‌دهی و سیاست شبکه برای همان سرویس درست و سازگار باشند. نوع تشخیص خرابی و مسیرهای بالادستی نیز اهمیت دارند. مقایسه حالت‌های Bond در مستندات Red Hat تنظیم موردنیاز سمت سوئیچ را برای حالت‌ها توضیح می‌دهد.

LACP: چند مسیر در یک گروه هماهنگ

در حالت 802.3ad یا LACP، سرور و سوئیچ باید درباره گروه پورت‌ها با هم هماهنگ باشند. ممکن است چند جریان مستقل میان مسیرهای عضو تقسیم شوند؛ نتیجه به سیاست توزیع، تعداد ارتباط‌ها و تنظیم سوئیچ بستگی دارد. برای یک اتصال معمول TCP، نباید فرض کنید سرعت از مجموع همه پورت‌ها استفاده می‌کند. راهنمای Bonding کرنل لینوکس محدودیت یک اتصال و شرایط این حالت را توضیح می‌دهد.
مثلاً دو پورت یک‌گیگابیتی ممکن است برای چند مشتری هم‌زمان ظرفیت مجموع بیشتری فراهم کنند، اما یک دانلود از یک مشتری معمولاً از ظرفیت یک عضو بیشتر نمی‌شود. اگر بالادست شما یک پورت یک‌گیگابیتی یا محدودیت ترافیک دارد، مجموع واقعی نیز به همان مسیر وابسته است.
برای LACP، پورت‌های سرور و سوئیچ باید با طراحی سازگار گروه شوند. اتصال به دو سوئیچ مجزا تنها زمانی مناسب است که طراحی و قابلیت‌های آن سوئیچ‌ها چنین تجمیعی را پشتیبانی کنند. بدون تأیید تیم شبکه، حالت سوئیچ یا سرور را در تولید تغییر ندهید.

پیش از انتخاب، این اطلاعات را از دیتاسنتر بگیرید

شماره پورت‌های فیزیکی، سرعت، VLAN یا شبکه هر پورت، روش اختصاص IP و gateway، محدودیت MAC، نوع سوئیچ و امکان LACP را بپرسید. مشخص کنید آیا هر دو مسیر واقعاً مستقل‌اند یا در یک نقطه مشترک قرار دارند. اگر IPv6 هم دارید، مسیر و gateway آن را نیز ثبت کنید.
سپس هدف خود را روشن کنید: اگر فقط می‌خواهید خرابی یک کابل باعث قطع نشود، Active-backup می‌تواند گزینه مناسب باشد. اگر ظرفیت مجموع چند جریان نیز مهم است و سوئیچ و مسیر بالادستی پشتیبانی می‌کنند، LACP را ارزیابی کنید. نام حالت به‌تنهایی تضمین دسترسی دائمی یا سرعت مشخص نیست.

یک آزمایش ساده Active-backup در محیط جداگانه

نمونه زیر فقط برای محیط آزمایشی با NetworkManager و دو رابط بدون تنظیم قبلی است. در مستندات جدید Red Hat، واژه‌های controller و port-type برای نسخه ۹٫۴ به بعد معرفی شده‌اند؛ نسخه‌های قدیمی‌تر ممکن است از master و slave-type استفاده کنند. توزیع، نسخه و ابزار مدیریت شبکه خود را قبل از اجرا با راهنمای رسمی NetworkManager در Red Hat تطبیق دهید.
فرض کنید در آزمایشگاه دو رابط enp7s0 و enp8s0 آزادند، شبکه آزمایشی DHCP دارد، سوئیچ برای این دو پورت به‌درستی تنظیم شده و کنسول ماشین در دسترس است. این نام‌ها نمونه‌اند؛ روی سرور واقعی با نام‌های دیگر یا پورت‌های حامل ترافیک، بدون طراحی و برنامه بازگشت اجرا نکنید.
ابتدا وضعیت رابط‌ها را ببینید:
کد / دستورnmcli device status
این فرمان رابط‌ها و وضعیت اتصالشان را نشان می‌دهد. مطمئن شوید دو رابط انتخابی واقعاً مخصوص آزمایش‌اند و پروفایل فعال دیگری را قطع نمی‌کنید. سپس در همان آزمایشگاه، رابط Bond و دو عضو نمونه را بسازید:
کد / دستورsudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" sudo nmcli connection add type ethernet port-type bond con-name bond0-port1 ifname enp7s0 controller bond0 sudo nmcli connection add type ethernet port-type bond con-name bond0-port2 ifname enp8s0 controller bond0 sudo nmcli connection modify bond0 connection.autoconnect-ports 1
فرمان اول یک پروفایل Bond با پایش وضعیت پیوند می‌سازد؛ دو فرمان بعدی پورت‌ها را به آن متصل می‌کنند و فرمان چهارم شروع خودکار پورت‌های مربوط را برای این پروفایل تنظیم می‌کند. ایجاد پروفایل‌های شبکه می‌تواند بر اتصال اثر بگذارد، به همین دلیل مثال فقط برای محیط جدا و کنسول در دسترس است. در محیط دارای IP ثابت، bridge، VLAN یا IPv6 باید تنظیمات واقعی روی لایه مناسب طراحی شوند؛ مثال DHCP را بدون تطبیق کپی نکنید.
در محیط آزمایشی، پروفایل را بالا بیاورید و وضعیت را ببینید:
کد / دستورsudo nmcli connection up bond0 cat /proc/net/bonding/bond0 ip address show bond0 ip route
در گزارش Bond، حالت، عضوها و عضو فعال را بخوانید. در ip address باید آدرسی که شبکه آزمایشی به bond داده دیده شود و ip route مسیر مناسب را نشان دهد. بعد از بیرون همان شبکه، دسترسی به سرویس آزمایشی را هم بررسی کنید؛ داشتن IP به‌تنهایی دسترسی بیرونی را ثابت نمی‌کند.

پشتیبان واقعاً هنگام خرابی وارد مدار می‌شود؟

در آزمایشگاه و با هماهنگی مسئول شبکه، قطع یکی از مسیرهای فیزیکی را با روش مجاز همان محیط شبیه‌سازی کنید. پیش و پس از آن گزارش /proc/net/bonding/bond0 و پاسخ سرویس را ثبت کنید. عضو فعال باید طبق طراحی تغییر کند و مسیر باقی‌مانده واقعاً به مقصد برسد. آزمون صرفاً با غیرفعال‌کردن نرم‌افزاری یک پروفایل، همه حالت‌های خرابی کابل، سوئیچ یا بالادست را بازسازی نمی‌کند.
پس از آزمون، کابل و تنظیمات آزمایشی را طبق برنامه به حالت قبل برگردانید و سرویس را دوباره کنترل کنید. روی سرور تولیدی، کابل را بدون هماهنگی برای «تست سریع» جدا نکنید. اگر هر دو عضو ظاهراً سالم‌اند اما خارج از سرور دسترسی برقرار نیست، VLAN، gateway، سیاست MAC و مسیر سوئیچ را همراه تیم شبکه بررسی کنید.
در صفحه سرور اختصاصی نت‌آرام می‌توانید مشخصات سرویس را بررسی کنید. پیش از سفارش یا تغییر شبکه، تعداد پورت، اتصال بالادست و روش مجاز پشتیبان‌سازی مسیر را با ارائه‌دهنده تطبیق دهید.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام