راه‌اندازی Octavia (Load Balancer as a Service) در OpenStack با Kolla-Ansible روی سرور اختصاصی

اگر روی یک سرور اختصاصی، OpenStack را با Kolla-Ansible بالا آورده‌اید و حالا به دنبال راهی هستید که ترافیک بین چند اینستنس را توزیع کنید، گزینه پیش‌فرض این روزها Octavia است. پروژه قدیمی‌تر neutron-lbaas از رده خارج شده و Octavia جایگزین رسمی آن در OpenStack است. این مقاله مراحل فعال‌سازی Octavia از طریق Kolla-Ansible، تنظیم گواهی TLS، ساخت شبکه مدیریتی amphora و ساخت اولین لودبالانسر را با دستورات واقعی پوشش می‌دهد. اگر به‌جای OpenStack روی یک کلاستر Kubernetes کار می‌کنید، معادل این کار راه‌اندازی MetalLB برای Load Balancer در Kubernetes است.

Octavia چیست و چرا به آن نیاز دارید

Octavia یک سرویس Load Balancer as a Service برای OpenStack است. برخلاف یک HAProxy دستی که خودتان روی یک سرور جداگانه نصب و نگهداری می‌کنید، Octavia لودبالانسر را به‌صورت یک منبع OpenStack (شبیه به یک instance یا volume) در اختیار تننت‌ها قرار می‌دهد. کاربران نهایی می‌توانند از طریق CLI، Horizon یا API خودشان لودبالانسر بسازند، بدون این‌که به دسترسی روی زیرساخت فیزیکی نیاز داشته باشند.

نکته کلیدی معماری Octavia این است که برای هر لودبالانسر، یک یا چند instance مخصوص به نام amphora ساخته می‌شود. این amphora‌ها همان HAProxy را اجرا می‌کنند، ولی چرخه حیاتشان (ساخت، health check، failover) کاملاً توسط Octavia مدیریت می‌شود.

معماری Octavia: کامپوننت‌ها و شبکه amphora

قبل از شروع پیکربندی، شناخت کامپوننت‌های اصلی کمک می‌کند تا بعداً لاگ‌ها را بهتر بخوانید:

کامپوننت	نقش
octavia-api	دریافت درخواست‌های کاربر (ساخت/ویرایش لودبالانسر)
octavia-worker	اجرای عملیات روی amphora (ساخت، تنظیم listener/pool)
octavia-health-manager	مانیتورینگ سلامت amphora‌ها و شروع failover
octavia-housekeeping	پاکسازی amphora‌های منقضی یا خراب
amphora	instance واقعی اجرا کننده HAProxy، روی شبکه lb-mgmt-net

ارتباط بین سرویس‌های کنترل‌پلین و amphora‌ها از طریق یک شبکه مدیریتی جداگانه به نام lb-mgmt-net انجام می‌شود. روی یک سرور اختصاصی که معمولاً با یک یا دو اینترفیس شبکه کار می‌کنید، این شبکه باید به‌صورت یک بریج یا VLAN جداگانه تعریف شود تا health-manager بتواند بدون واسطه با amphora‌ها صحبت کند.

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

فرض این مقاله بر این است که Kolla-Ansible با سرویس‌های پایه (Keystone، Neutron، Nova، Glance) از قبل روی سرور اختصاصی شما در حال اجراست. علاوه بر آن به این موارد نیاز دارید:

• دسترسی root یا sudo روی نود deploy برای اجرای kolla-ansible
• یک بریج شبکه اختصاصی (مثلاً br-lbmgmt) برای lb-mgmt-net، جدا از شبکه مدیریت اصلی OpenStack
• فضای دیسک کافی برای build کردن ایمیج amphora (حداقل چند گیگابایت آزاد)
• دسترسی اینترنت خروجی روی نود deploy برای دانلود پکیج‌های diskimage-builder

پیکربندی globals.yml برای فعال‌سازی Octavia

در فایل /etc/kolla/globals.yml مقادیر زیر را اضافه یا ویرایش کنید:

enable_octavia: "yes"
enable_octavia_driver_agent: "yes"
octavia_network_interface: "o-hm0"
octavia_amp_flavor:
  name: "amphora"
  vcpus: 1
  ram: 1024
  disk: 3
octavia_amp_network:
  name: "lb-mgmt-net"
  provider_network_type: "flat"
  physical_network: "physnet-lb"

اگر روی همان سرور اختصاصی از یک فیزیکال نتورک مشترک استفاده می‌کنید، physical_network باید با مقداری که در bridge_interface و تنظیمات Neutron شما هم‌خوانی دارد، مطابقت داشته باشد. Kolla-Ansible در زمان deploy، اینترفیس o-hm0 را روی نود کنترلر می‌سازد و آن را به شبکه مدیریتی amphora وصل می‌کند.

گواهی‌های TLS برای ارتباط amphora با کنترل‌پلین

ارتباط بین octavia-worker/octavia-health-manager و هر amphora از طریق TLS رمزگذاری می‌شود. Kolla-Ansible اسکریپتی برای تولید این گواهی‌ها دارد که باید قبل از deploy اجرا شود:

kolla-ansible octavia-certificates

این دستور یک CA داخلی می‌سازد و گواهی‌های لازم برای client (کنترل‌پلین) و server (amphora) را در مسیر /etc/kolla/config/octavia-certs قرار می‌دهد. اگر این مرحله را رد کنید، amphora‌ها ساخته می‌شوند ولی health-manager هرگز نمی‌تواند وضعیت آن‌ها را بخواند و لودبالانسر در وضعیت ERROR باقی می‌ماند.

نکته: تاریخ انقضای این گواهی‌ها پیش‌فرض چند سال است، اما در محیط production بهتر است تاریخ انقضا را در تقویم خودتان یادداشت کنید تا با انقضای ناگهانی گواهی، همه لودبالانسرهای فعال از کار نیفتند.

ساخت و آپلود ایمیج amphora

Octavia برای ساخت instance‌های amphora به یک ایمیج مخصوص نیاز دارد که با ابزار diskimage-builder ساخته می‌شود:

git clone https://opendev.org/openstack/octavia
cd octavia/diskimage-create
./diskimage-create.sh -o amphora-x64-haproxy

openstack image create amphora-x64-haproxy \
  --disk-format qcow2 \
  --container-format bare \
  --tag amphora \
  --private \
  --file amphora-x64-haproxy.qcow2

تگ amphora اجباری است؛ Octavia از همین تگ برای پیدا کردن ایمیج صحیح در زمان ساخت هر لودبالانسر استفاده می‌کند.

اجرای deploy و بررسی سرویس‌ها

بعد از تنظیم globals.yml و ساخت گواهی‌ها:

kolla-ansible deploy --tags octavia
docker ps | grep octavia

باید کانتینرهای octavia_api، octavia_worker، octavia_health_manager و octavia_housekeeping در حالت Up دیده شوند. اگر octavia_health_manager مدام ری‌استارت می‌شود، معمولاً یا اینترفیس o-hm0 بالا نیامده یا مسیر گواهی‌ها در globals.yml اشتباه تنظیم شده است.

ساخت اولین لودبالانسر

با فرض این‌که دو instance بک‌اند روی یک شبکه tenant در حال اجرا هستند، ساخت لودبالانسر به این ترتیب انجام می‌شود:

openstack loadbalancer create --name web-lb --vip-subnet-id tenant-subnet

openstack loadbalancer listener create --protocol HTTP \
  --protocol-port 80 --name web-listener web-lb

openstack loadbalancer pool create --lb-algorithm ROUND_ROBIN \
  --listener web-listener --protocol HTTP --name web-pool

openstack loadbalancer healthmonitor create --delay 5 --timeout 3 \
  --max-retries 3 --type HTTP --url-path / web-pool

openstack loadbalancer member create --subnet-id tenant-subnet \
  --address 10.0.0.11 --protocol-port 80 web-pool
openstack loadbalancer member create --subnet-id tenant-subnet \
  --address 10.0.0.12 --protocol-port 80 web-pool

بعد از چند دقیقه، وضعیت لودبالانسر با openstack loadbalancer show web-lb باید provisioning_status: ACTIVE و operating_status: ONLINE نشان دهد. IP گرفته‌شده در vip_address همان آدرسی است که باید به آن ترافیک بفرستید.

مقایسه HAProxy دستی با Octavia LBaaS

پیش از این‌که سراغ Octavia بروید، شاید بپرسید آیا نصب دستی HAProxy روی یک سرور جداگانه کافی نیست. جدول زیر تفاوت عملی این دو رویکرد را نشان می‌دهد:

ویژگی	HAProxy دستی	Octavia LBaaS
ساخت لودبالانسر توسط کاربر نهایی	نیاز به دسترسی SSH و دانش HAProxy	از طریق API/CLI/Horizon، بدون دسترسی زیرساخت
health check و failover	باید خودتان اسکریپت بنویسید	داخلی، توسط health-manager انجام می‌شود
مقیاس‌پذیری با چند لودبالانسر	هر لودبالانسر یعنی یک سرور/کانتینر جدا برای نگهداری	هر تننت لودبالانسر خودش را مستقل می‌سازد
یکپارچگی با Neutron/Security Groups	جدا از OpenStack، نیاز به هماهنگی دستی شبکه	native، از همان subnet/security group تننت استفاده می‌کند

برای یک محیط تک‌کاربره و ساده، HAProxy دستی هنوز گزینه معقولی است. اما وقتی چند تیم یا چند تننت روی همان OpenStack کار می‌کنند و هرکدام باید مستقل لودبالانسر بسازند، Octavia زمان نگهداری را به‌شکل قابل توجهی کم می‌کند؛ این دقیقاً همان مقیاسی است که در افزودن Compute Node به کلاستر OpenStack با Kolla-Ansible هم به آن پرداخته‌ایم.

چند مشکل رایج

• لودبالانسر در وضعیت ERROR می‌ماند: معمولاً یعنی health-manager به amphora روی lb-mgmt-net دسترسی ندارد؛ اول اتصال o-hm0 را چک کنید.
• amphora ساخته نمی‌شود: بررسی کنید فلیور amphora با منابع کافی (RAM/CPU) در Nova تعریف شده باشد.
• خطای TLS handshake در لاگ health-manager: معمولاً یعنی گواهی‌ها با دستور kolla-ansible octavia-certificates قبل از deploy تولید نشده‌اند، یا مسیرشان در globals.yml اشتباه است.

جمع‌بندی

فعال‌سازی Octavia روی یک استقرار Kolla-Ansible موجود عمدتاً سه بخش دارد: تنظیم شبکه مدیریتی amphora در globals.yml، تولید گواهی‌های TLS پیش از deploy، و ساخت ایمیج amphora با تگ درست. بعد از این مراحل، ساخت لودبالانسر برای کاربران نهایی به چند دستور CLI ساده تبدیل می‌شود.

اگر هنوز زیرساخت OpenStack خودتان را روی یک منبع مشترک اجرا می‌کنید و با نویزی منابع دیگر تننت‌ها مواجه‌اید، اجرای این نوع سرویس‌ها روی یک سرور اختصاصی منابع پایدار و کنترل کامل روی شبکه و دیسک را در اختیارتان می‌گذارد؛ همان چیزی که برای تست و اجرای پایدار Octavia لازم دارید.