راه‌اندازی شبکه در OpenStack با Neutron: Provider Network، روتر و Floating IP روی سرور اختصاصی

Neutron جزئی از OpenStack است که شبکه مجازی اینستنس‌ها را مدیریت می‌کند: از ساخت شبکه‌های داخلی گرفته تا مسیریابی ترافیک به بیرون. روی یک سرور اختصاصی، جایی که کنترل کامل روی رابط‌های فیزیکی و پل‌های شبکه در اختیار شماست، پیکربندی Neutron چند مرحلهٔ مشخص دارد که اگر به ترتیب انجام نشوند، معمولاً به این نتیجه می‌رسید: اینستنس بالا می‌آید اما نه IP می‌گیرد و نه از بیرون در دسترس است.

این راهنما فرض می‌کند OpenStack (کنترلر و حداقل یک نود کمپیوت) از قبل نصب شده و فقط بخش شبکه باقی مانده است.

Neutron چه کاری انجام می‌دهد

Neutron شبکه را به‌صورت یک سرویس API ارائه می‌دهد، نه یک پیکربندی ثابت روی هاست. هر شبکه، ساب‌نت، روتر و پورت یک آبجکت در دیتابیس Neutron است که با پلاگین ML2 (Modular Layer 2) به Open vSwitch یا Linux Bridge روی هاست‌های فیزیکی ترجمه می‌شود.

دو نوع شبکه در Neutron اهمیت دارد:

• Provider Network — مستقیماً به شبکهٔ فیزیکی دیتاسنتر متصل است. اینستنس‌هایی که روی این شبکه قرار می‌گیرند IP را از همان رنج شبکهٔ فیزیکی می‌گیرند.
• Self-service Network (Tenant Network) — شبکهٔ ایزولهٔ داخلی هر تنانت است که از طریق VXLAN یا GRE پیاده‌سازی می‌شود و برای دسترسی به بیرون به یک روتر و Floating IP نیاز دارد.

روی سرور اختصاصی معمولاً هر دو الگو همزمان استفاده می‌شوند: Provider Network به‌عنوان شبکهٔ خارجی (external) برای روتر، و Self-service Network برای شبکهٔ داخلی اینستنس‌ها.

پیش‌نیازها روی سرور اختصاصی

قبل از شروع پیکربندی Neutron باید این موارد آماده باشد:

• حداقل دو رابط شبکه فیزیکی: یکی برای مدیریت (Management) و یکی برای ترافیک خارجی (Provider/External).
• Open vSwitch نصب‌شده روی هر نودی که ترافیک شبکه را پردازش می‌کند (کنترلر و/یا نودهای شبکه اختصاصی).
• یک رنج IP عمومی یا اختصاصی معتبر که ISP یا دیتاسنتر برای آن سرور تخصیص داده — همان رنجی که Provider Network بر پایهٔ آن تعریف می‌شود.
• دسترسی root به فایل‌های پیکربندی /etc/neutron/ روی هر نود.

اگر هنوز مطمئن نیستید سرور اختصاصی شما ظرفیت کافی برای اجرای کنترلر و چند نود کمپیوت OpenStack را دارد، این نکته را قبل از شروع نصب بررسی کنید — کمبود CPU یا RAM معمولاً خودش را در همین مرحلهٔ شبکه، با تأخیر یا افت پکت، نشان می‌دهد.

پیکربندی br-ex و اتصال رابط فیزیکی

br-ex پلی است که ترافیک Provider Network را به رابط فیزیکی متصل می‌کند. این پل باید روی هر نودی که قرار است ترافیک خارجی از آن عبور کند (معمولاً نود کنترلر یا یک نود شبکهٔ جداگانه) ساخته شود.

ساخت پل با Open vSwitch

ovs-vsctl add-br br-ex
ovs-vsctl add-port br-ex eth1

eth1 همان رابط فیزیکی متصل به شبکهٔ بیرونی است. بعد از این دستور، IP که قبلاً روی eth1 تنظیم شده بود باید به br-ex منتقل شود، وگرنه اتصال SSH به سرور قطع می‌شود — این مرحله را از طریق کنسول out-of-band دیتاسنتر انجام دهید، نه از طریق همان SSH که روی eth1 باز است.

نگاشت پل در ML2

در فایل /etc/neutron/plugins/ml2/openvswitch_agent.ini:

bridge_mappings = physnet1:br-ex

و در /etc/neutron/plugins/ml2/ml2_conf.ini:

flat_networks = physnet1

physnet1 یک نام دلخواه است که Provider Network بعداً به آن ارجاع می‌دهد؛ باید در هر دو فایل یکسان باشد. بعد از تغییر، سرویس‌ها را ری‌استارت کنید:

systemctl restart neutron-openvswitch-agent

ساخت Provider Network

با CLI (یا از طریق Horizon) شبکهٔ provider را روی physnet1 تعریف می‌کنیم:

openstack network create --share --external \
  --provider-physical-network physnet1 \
  --provider-network-type flat provider-net

openstack subnet create --network provider-net \
  --subnet-range 203.0.113.0/24 \
  --gateway 203.0.113.1 \
  --allocation-pool start=203.0.113.10,end=203.0.113.100 \
  --dns-nameserver 8.8.8.8 \
  provider-subnet

--external مشخص می‌کند این شبکه می‌تواند به‌عنوان gateway برای روترها استفاده شود. رنج allocation-pool باید زیرمجموعهٔ IPهایی باشد که واقعاً به آن سرور اختصاصی تعلق دارند — استفاده از رنجی خارج از تخصیص واقعی باعث می‌شود Floating IPها به بیرون مسیریابی نشوند.

ساخت شبکهٔ داخلی و روتر

شبکهٔ داخلی (Self-service) برای اینستنس‌ها معمولاً VXLAN است و نیازی به تخصیص IP عمومی مستقیم ندارد:

openstack network create internal-net

openstack subnet create --network internal-net \
  --subnet-range 10.0.0.0/24 \
  --dns-nameserver 8.8.8.8 \
  internal-subnet

روتر بین این دو شبکه پل می‌زند:

openstack router create main-router

openstack router set main-router --external-gateway provider-net

openstack router add subnet main-router internal-subnet

از این نقطه به بعد، اینستنس‌هایی که روی internal-net ساخته می‌شوند از طریق main-router به شبکهٔ provider، و از آنجا به اینترنت دسترسی خروجی (SNAT) دارند. اما هنوز از بیرون قابل‌دسترس نیستند — این کار وظیفهٔ Floating IP است.

اختصاص Floating IP

Floating IP یک آدرس از رنج Provider Network است که به‌صورت یک‌به‌یک به پورت یک اینستنس در شبکهٔ داخلی متصل می‌شود:

openstack floating ip create provider-net

openstack server add floating ip my-instance 203.0.113.25

بعد از این دستور، ترافیک ورودی به 203.0.113.25 با NAT روی روتر به IP داخلی اینستنس در internal-subnet ترجمه می‌شود. نکتهٔ رایج فراموش‌شده: security group پیش‌فرض ترافیک ورودی را می‌بندد — باید صراحتاً پورت‌های موردنیاز (مثلاً 22 برای SSH یا 80/443 برای وب) را باز کنید:

openstack security group rule create --proto tcp --dst-port 22 default

Provider Network در برابر Self-service Network

انتخاب اینکه یک اینستنس مستقیماً روی Provider Network قرار بگیرد یا پشت روتر با Floating IP، به سناریوی استفاده بستگی دارد.

ویژگی	Provider Network	Self-service + Floating IP
نوع IP	مستقیم از رنج فیزیکی	داخلی + NAT از طریق روتر
ایزولاسیون بین تنانت‌ها	ندارد	کامل (VXLAN جدا برای هر تنانت)
نیاز به روتر	خیر	بله
مناسب برای	سرویس‌هایی با نیاز به IP ثابت و مستقیم (مثل لود بالانسر لبه)	اکثر workloadهای عمومی، به‌خصوص در محیط چندتنانتی
مدیریت تعداد IP عمومی	هر اینستنس یک IP عمومی مصرف می‌کند	فقط اینستنس‌هایی که نیاز به دسترسی بیرونی دارند IP می‌گیرند

در بیشتر استقرارهای production، ترکیب هر دو رایج است: چند اینستنس حساس (مثل edge load balancer) مستقیم روی Provider Network، و بقیه پشت روتر با Floating IP اختصاصی در صورت نیاز.

عیب‌یابی اتصال شبکه

وقتی اینستنس بالا می‌آید ولی به شبکه دسترسی ندارد، این ترتیب بررسی معمولاً سریع‌ترین راه به جواب است:

1. بررسی کنید پورت اینستنس روی Neutron وضعیت ACTIVE دارد: openstack port list --server <instance>.
2. مطمئن شوید neutron-openvswitch-agent روی نود کمپیوت و نود شبکه در حال اجراست: systemctl status neutron-openvswitch-agent.
3. با ovs-vsctl show بررسی کنید که br-ex واقعاً به رابط فیزیکی متصل است، نه یک پل خالی.
4. اگر Floating IP وصل شده ولی جواب نمی‌دهد، قوانین security group و اینکه روتر واقعاً external-gateway دارد را چک کنید.
5. لاگ neutron-l3-agent.log معمولاً خطای namespace یا مسیریابی را مستقیم نشان می‌دهد.

اکثر مشکلات از یکی از دو مورد است: bridge_mappings که با نام physnet در تعریف شبکه هم‌خوانی ندارد، یا رنج IP روتر که با رنج واقعی provider subnet تداخل دارد.

اجرای این معماری روی سرور اختصاصی

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

جمع‌بندی

راه‌اندازی شبکه در Neutron از چند بخش تشکیل می‌شود که باید به ترتیب و با هماهنگی کامل تنظیم شوند: پل br-ex روی رابط فیزیکی، نگاشت آن در ML2، تعریف Provider Network با رنج IP واقعی، ساخت شبکهٔ داخلی و روتر، و در نهایت اختصاص Floating IP به اینستنس‌هایی که نیاز به دسترسی از بیرون دارند. هر مرحله قابل تست جداگانه است، و بیشتر خطاهای رایج (از جمله اتصال قطع‌شده بعد از ساخت br-ex) با بررسی گام‌به‌گام همین ترتیب قابل ردیابی است.

بعد از تکمیل شبکه، بخش طبیعی بعدی این معماری راه‌اندازی ذخیره‌سازی بلاک با Cinder روی همان سرور اختصاصی است.