بلاگ/پیکربندی Network Bonding در لینوکس روی سرور اختصاصی: افزایش پهنای باند و Failover خودکار با چند NIC
به‌روز شده

پیکربندی Network Bonding در لینوکس روی سرور اختصاصی: افزایش پهنای باند و Failover خودکار با چند NIC

1405/06/260 بازدید
پیکربندی Network Bonding در لینوکس روی سرور اختصاصی: افزایش پهنای باند و Failover خودکار با چند NIC

پیکربندی Network Bonding در لینوکس روی سرور اختصاصی: افزایش پهنای باند و Failover خودکار با چند NIC

پیکربندی network bonding روی سرور اختصاصی

اگر سرور اختصاصی شما بیش از یک کارت شبکه (NIC) دارد و همچنان فقط از یکی از آن‌ها استفاده می‌کنید، عملاً نصف ظرفیت شبکه‌ی سرور بلااستفاده مانده. Network Bonding چند کارت شبکه‌ی فیزیکی را به‌صورت یک اینترفیس منطقی واحد (مثلاً bond0) در می‌آورد و بسته به حالت انتخابی، یا پهنای باند را جمع می‌زند یا در صورت قطع شدن یک کابل/کارت، بدون افت سرویس به کارت دیگر سوییچ می‌کند.

در این مقاله پیکربندی network bonding در لینوکس را هم با Netplan (اوبونتو/دبیان) و هم با nmcli (سنت‌اواس، رد‌هت، راکی و آلما لینوکس) قدم‌به‌قدم پیش می‌بریم و تفاوت حالت‌های Active-Backup و LACP را با مثال واقعی نشان می‌دهیم.

Network Bonding چیست و چرا روی سرور اختصاصی به آن نیاز دارید؟

هسته‌ی لینوکس با درایور bonding می‌تواند چند اینترفیس فیزیکی (مثلاً eth0 و eth1) را زیر یک اینترفیس مجازی یکی کند. از دید سیستم‌عامل و برنامه‌ها فقط یک IP و یک اینترفیس شبکه وجود دارد؛ کارت‌های فیزیکی زیرمجموعه (slave) آن هستند.

دو دلیل اصلی برای استفاده از bonding روی سرور اختصاصی وجود دارد:

  • Failover (تحمل خطا): اگر یکی از کارت‌های شبکه یا کابل متصل به آن قطع شود، ترافیک بدون قطعی از کارت سالم عبور می‌کند. این برای سرویس‌هایی مثل دیتابیس یا API که نباید حتی چند ثانیه دان شوند حیاتی است.
  • افزایش پهنای باند: با حالت‌هایی مثل LACP، ترافیک بین چند لینک ۱ گیگابیتی یا ۱۰ گیگابیتی تقسیم می‌شود و مجموع توان عبوری بالاتر می‌رود، به‌خصوص برای سرورهای بک‌آپ یا استوریجی مثل کلاستر CephFS که حجم بالای داده بین چند سرور منتقل می‌کنند.

مهم است بدانید bonding یک قابلیت سطح سیستم‌عامل است، نه یک ویژگی شبکه‌ی مجازی؛ برای همین روی سرورهای اختصاصی با دسترسی فیزیکی به چند NIC معنا پیدا می‌کند، نه روی هر VPS. همین ویژگی باعث می‌شود روی نودهای یک کلاستر — مثلاً Compute Node در OpenStack — که ترافیک شبکه‌ی داخلی بین نودها سنگین است، اهمیت بیشتری پیدا کند.

نمودار bonding دو کارت شبکه سرور با failover خودکار: در حالت سالم هر دو لینک فعال‌اند، با قطع یکی ترافیک بدون افت از لینک دیگر عبور می‌کند

حالت‌های مختلف Bonding و تفاوت آن‌ها

درایور bonding لینوکس هفت حالت (mode) دارد، اما در عمل فقط چند تای آن‌ها کاربرد رایج دارند. مهم‌ترین تفاوت بین آن‌ها این است که آیا به پیکربندی خاصی روی سوییچ نیاز دارند یا خیر.

حالتنامنیاز به تنظیم سوییچهدف اصلی
Mode 0balance-rrخیر (اما توصیه نمی‌شود)توزیع دوره‌ای بسته‌ها، احتمال به‌هم‌ریختگی ترتیب پکت‌ها
Mode 1active-backupخیرفقط Failover، یک لینک فعال و بقیه آماده‌به‌کار
Mode 4802.3ad (LACP)بله، پورت‌های Ethernet Channel/LACPافزایش پهنای باند + Failover هم‌زمان
Mode 5balance-tlbخیرتوزیع بار ترافیک خروجی بر اساس بار هر لینک
Mode 6balance-albخیرمشابه tlb به‌علاوه توزیع ترافیک ورودی

برای اکثر سرورهای اختصاصی، دو گزینه واقعی روی میز است:

  • Active-Backup وقتی هدف فقط پایداری سرویس است و دیتاسنتر یا سوییچ کنترل‌شده در اختیار شما نیست (مثلاً پورت‌های سوییچ shared با مشتریان دیگر).
  • LACP (802.3ad) وقتی هم به پهنای باند بیشتر نیاز دارید و هم دسترسی/هماهنگی با تیم شبکه‌ی دیتاسنتر برای فعال‌سازی Port Channel روی سوییچ دارید.

پیش‌نیازها پیش از پیکربندی

قبل از دست بردن در تنظیمات شبکه‌ی یک سرور در حال کار، این موارد را چک کنید:

  • هر دو (یا چند) کارت شبکه باید سرعت یکسان داشته باشند (مثلاً هر دو ۱ گیگ یا هر دو ۱۰ گیگ)؛ ترکیب سرعت‌های متفاوت در bonding پشتیبانی نمی‌شود.
  • برای LACP باید از تیم دیتاسنتر یا نوک بخواهید پورت‌های مربوطه را در یک Port Channel/LAG با LACP فعال قرار دهند؛ بدون این کار، LACP از سمت سرور تنها بالا نمی‌آید.
  • دسترسی root یا sudo، و ترجیحاً دسترسی KVM/iDRAC/iLO به سرور — چون تغییر تنظیمات شبکه از راه دور همیشه ریسک قطع شدن دسترسی SSH را دارد.
  • نام دقیق اینترفیس‌ها را از قبل با ip link show یادداشت کنید.

پیکربندی Bonding با Netplan (اوبونتو/دبیان)

Netplan از اوبونتو ۱۸.۰۴ به بعد روش پیش‌فرض مدیریت شبکه است. تنظیمات در فایلی مثل /etc/netplan/50-bonding.yaml نوشته می‌شود.

حالت Active-Backup با Netplan

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [203.0.113.10/24]
      routes:
        - to: default
          via: 203.0.113.1
      parameters:
        mode: active-backup
        primary: eth0
        mii-monitor-interval: 100

اعمال تنظیمات:

sudo netplan apply

حالت LACP (802.3ad) با Netplan

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [203.0.113.10/24]
      routes:
        - to: default
          via: 203.0.113.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

نکته: تا وقتی سوییچ سمت دیتاسنتر روی همان پورت‌ها LACP را فعال نکرده باشد، اینترفیس bond0 در حالت 802.3ad بالا می‌آید ولی ترافیک واقعی رد و بدل نمی‌شود. همیشه بعد از تغییر، وضعیت را با دستور بخش «تست و عیب‌یابی» بررسی کنید.

پیکربندی Bonding با nmcli (CentOS/RHEL/Rocky/AlmaLinux)

روی توزیع‌های خانواده‌ی رد‌هت، NetworkManager و ابزار خط فرمان آن nmcli مسیر استاندارد است.

ایجاد Bond در حالت Active-Backup

nmcli con add type bond con-name bond0 ifname bond0 mode active-backup

nmcli con add type ethernet con-name bond0-eth0 ifname eth0 master bond0
nmcli con add type ethernet con-name bond0-eth1 ifname eth1 master bond0

nmcli con mod bond0 ipv4.addresses 203.0.113.10/24
nmcli con mod bond0 ipv4.gateway 203.0.113.1
nmcli con mod bond0 ipv4.dns "8.8.8.8 1.1.1.1"
nmcli con mod bond0 ipv4.method manual

nmcli con up bond0
nmcli con up bond0-eth0
nmcli con up bond0-eth1

تنظیم LACP با nmcli

فقط پارامتر mode و چند گزینه‌ی مربوط به LACP فرق می‌کند:

nmcli con add type bond con-name bond0 ifname bond0 \
  mode 802.3ad bond.options "lacp_rate=fast,miimon=100,xmit_hash_policy=layer3+4"

nmcli con add type ethernet con-name bond0-eth0 ifname eth0 master bond0
nmcli con add type ethernet con-name bond0-eth1 ifname eth1 master bond0

nmcli con mod bond0 ipv4.addresses 203.0.113.10/24 ipv4.gateway 203.0.113.1 ipv4.method manual

nmcli con up bond0

تست و عیب‌یابی Bonding

بعد از هر تغییر، وضعیت واقعی bond را از خروجی kernel بگیرید، نه فقط از دستور تنظیم:

cat /proc/net/bonding/bond0

خروجی این فایل نشان می‌دهد کدام NIC در حال حاضر active است (در Active-Backup)، یا وضعیت مذاکره‌ی LACP با سوییچ چگونه است (در 802.3ad). عبارت Bonding Mode و MII Status: up برای هر slave باید سالم باشد.

برای تست واقعی failover، در یک بازه‌ی کم‌ترافیک، کابل یکی از کارت‌ها را فیزیکی جدا کنید یا لینک را با ip link set eth0 down غیرفعال کنید و همزمان یک ping مداوم به سرور بزنید؛ در حالت Active-Backup سالم، حداکثر چند پکت افت می‌شود و ادامه‌ی پینگ بدون قطعی برقرار می‌ماند.

برای LACP، از سمت سوییچ هم وضعیت Port Channel را بررسی کنید (مثلاً show lacp neighbor روی سوییچ‌های سیسکو)؛ اگر سرور LACP را فعال کرده ولی سوییچ نه، لینک بالا می‌آید ولی ترافیک عبور نمی‌کند یا فقط از یک کارت رد می‌شود.

نکات مهم و اشتباهات رایج

  • سرعت نامتقارن کارت‌ها: ترکیب یک کارت ۱ گیگ با یک کارت ۱۰ گیگ در bonding به‌درستی کار نمی‌کند؛ درایور فرض می‌کند همه‌ی لینک‌ها یک ظرفیت دارند.
  • فراموش کردن تنظیم سوییچ برای LACP: رایج‌ترین اشتباه است. LACP یک پروتکل دوطرفه است؛ تنظیم فقط سمت سرور کافی نیست.
  • ناهماهنگی MTU: اگر جامبو فریم (MTU بالاتر از ۱۵۰۰) روی یک NIC تنظیم شده و روی دیگری نه، bond ممکن است بالا بیاید ولی رفتار ناپایدار داشته باشد.
  • استفاده از mode اشتباه برای هدف اشتباه: اگر فقط Failover لازم دارید، Active-Backup ساده‌تر و کم‌ریسک‌تر از LACP است؛ LACP را فقط وقتی اضافه کنید که واقعاً به جمع پهنای باند نیاز دارید.
  • تست نکردن failover واقعی: خیلی از تنظیمات bonding فقط تا زمان اولین قطعی واقعی کابل تست نشده باقی می‌مانند. حتماً قبل از رفتن به production یک بار کابل را عمداً جدا کنید.

تحمل خطای bonding فقط سطح شبکه را پوشش می‌دهد. برای محافظت مشابه در سطح دیسک سراغ پیکربندی RAID با mdadm بروید، و اگر مدیریت انعطاف‌پذیر فضای دیسک هم مطرح است مدیریت دیسک با LVM را ببینید.

جمع‌بندی

پیکربندی network bonding در لینوکس روی سرور اختصاصی — چه با Netplan روی اوبونتو/دبیان و چه با nmcli روی خانواده‌ی رد‌هت — با چند دستور قابل انجام است، اما نتیجه‌ی آن (کاهش نقطه‌ی خرابی واحد شبکه و بالقوه دو برابر شدن پهنای باند) برای سرویس‌های حساس به دان‌تایم ارزش زمان گذاشتن را دارد. Active-Backup را برای پایداری صرف و LACP را وقتی هم پهنای باند و هم Failover لازم دارید انتخاب کنید، و همیشه هماهنگی سوییچ را پیش از تکیه کردن به LACP در production تأیید کنید.

اگر سرور فعلی شما فقط یک NIC دارد یا کارت‌های شبکه‌اش قدیمی‌تر از آن‌اند که از LACP پشتیبانی کنند، می‌توانید مشخصات را روی یک سرور اختصاصی با چند کارت شبکه‌ی هم‌سرعت و دسترسی کامل به تنظیمات شبکه بررسی کنید.