نصب و راه‌اندازی OpenStack روی سرور اختصاصی با Kolla-Ansible

OpenStack مجموعه‌ای از سرویس‌های متن‌باز برای ساخت و مدیریت زیرساخت ابری است. با استفاده از آن می‌توانید روی سخت‌افزار خود ماشین مجازی، شبکه خصوصی، آدرس IP شناور، دیسک ابری و سرویس‌های دیگری شبیه امکانات ارائه‌دهندگان کلود عمومی ایجاد کنید. نصب دستی OpenStack به دلیل تعداد زیاد سرویس‌ها و وابستگی میان آن‌ها پیچیده است؛ اگر با روش نصب دستی روی توزیع‌های دیگر آشنا هستید، نصب پلتفرم OpenStack در لینوکس RHEL/CentOS 7 تفاوت این دو رویکرد را نشان می‌دهد. Kolla-Ansible این فرایند را ساده‌تر می‌کند: سرویس‌های OpenStack داخل کانتینر اجرا می‌شوند و Ansible نصب، پیکربندی و هماهنگی آن‌ها را بر عهده می‌گیرد. در این راهنما، فرایند نصب OpenStack روی سرور اختصاصی را با معماری All-in-One بررسی می‌کنیم. این معماری برای آزمایش، آموزش، توسعه و کلودهای خصوصی کوچک مناسب است. برای محیط عملیاتی بزرگ یا حساس، باید کنترلرها، نودهای محاسباتی و سرویس‌های ذخیره‌سازی را روی چند سرور توزیع کنید.

Kolla-Ansible چیست و چرا از آن استفاده کنیم؟

Kolla پروژه‌ای از اکوسیستم OpenStack است که ایمیج‌های کانتینری آماده برای سرویس‌هایی مانند Nova، Neutron، Keystone، Glance و Horizon فراهم می‌کند. Kolla-Ansible نیز مجموعه‌ای از Playbookهای انسیبل است که این کانتینرها را روی نودهای مقصد مستقر و مدیریت می‌کند. در روش سنتی باید بسته‌ها، فایل‌های پیکربندی، پایگاه داده، صف پیام و سرویس‌های سیستمی را جداگانه تنظیم کنید. در مقابل، Kolla-Ansible بیشتر این مراحل را به‌صورت تکرارپذیر انجام می‌دهد و ارتقا یا بازپیکربندی سرویس‌ها را نیز منظم‌تر می‌کند. | روش استقرار | پیچیدگی اولیه | جداسازی سرویس‌ها | تکرارپذیری | کاربرد مناسب | |---|---:|---:|---:|---| | نصب دستی | زیاد | وابسته به طراحی | کم | یادگیری عمیق اجزای OpenStack | | DevStack | کم | محدود | متوسط | توسعه و آزمایش کوتاه‌مدت | | Kolla-Ansible | متوسط | زیاد، مبتنی بر کانتینر | زیاد | آزمایش جدی و محیط عملیاتی | | OpenStack-Helm | زیاد | مبتنی بر Kubernetes | زیاد | زیرساخت‌های Kubernetesمحور | مزیت اصلی Kolla-Ansible فقط کوتاه‌شدن نصب نیست. مهم‌تر از آن، دستیابی به یک فرایند استاندارد است که بتوان آن را روی چند نود تکرار، مستندسازی و عیب‌یابی کرد.

پیش‌نیازهای سخت‌افزاری و شبکه

منابع موردنیاز به تعداد ماشین‌های مجازی و سرویس‌های فعال بستگی دارد. برای یک استقرار All-in-One آزمایشی، حداقل ۸ هسته پردازنده، ۱۶ گیگابایت رم و حدود ۱۰۰ گیگابایت فضای آزاد در نظر بگیرید. برای تجربه روان‌تر، ۳۲ گیگابایت رم، فضای SSD یا NVMe و پردازنده‌ای با قابلیت مجازی‌سازی سخت‌افزاری توصیه می‌شود. قابلیت Intel VT-x یا AMD-V باید در BIOS/UEFI فعال باشد. وضعیت آن را می‌توانید با دستور زیر بررسی کنید:

egrep -c '(vmx|svm)' /proc/cpuinfo

خروجی بزرگ‌تر از صفر نشان می‌دهد فلگ مجازی‌سازی در اختیار سیستم‌عامل قرار گرفته است.

طراحی رابط‌های شبکه

بهتر است سرور حداقل دو رابط شبکه داشته باشد: - رابط مدیریتی برای SSH، APIهای OpenStack و ارتباط داخلی سرویس‌ها - رابط خارجی برای اتصال Neutron به شبکه Provider و تخصیص Floating IP رابط خارجی معمولاً نباید مستقیماً آدرس IP داشته باشد، زیرا Kolla-Ansible آن را به bridge شبکه خارجی متصل می‌کند. نام رابط‌ها را پیش از شروع با این دستور پیدا کنید:

ip -br address

در ادامه فرض می‌کنیم رابط مدیریتی eno1، رابط خارجی eno2 و آدرس VIP داخلی برابر 10.20.0.250 است. این مقادیر نمونه‌اند و باید با شبکه واقعی شما جایگزین شوند. آدرس VIP باید در همان شبکه مدیریتی آزاد باشد و توسط دستگاه دیگری استفاده نشود.

آماده‌سازی سیستم‌عامل

نسخه سیستم‌عامل باید با نسخه Kolla-Ansible انتخاب‌شده سازگار باشد. پیش از نصب، ماتریس پشتیبانی همان انتشار OpenStack را بررسی کنید؛ زیرا نسخه‌های پشتیبانی‌شده Python، Ansible و سیستم‌عامل در انتشارهای مختلف تغییر می‌کنند. ابتدا سیستم را به‌روزرسانی و ابزارهای پایه را نصب کنید:

sudo apt update
sudo apt upgrade -y
sudo apt install -y python3-dev python3-venv python3-pip \
  gcc libffi-dev libssl-dev git

برای جلوگیری از خطاهای احراز هویت و TLS، زمان سرور را همگام نگه دارید:

sudo timedatectl set-ntp true
timedatectl status

نام میزبان باید مشخص و قابل Resolve باشد. برای نمونه:

sudo hostnamectl set-hostname openstack-aio

سپس نام میزبان و IP مدیریتی را در /etc/hosts ثبت کنید:

10.20.0.10 openstack-aio

اگر فایروال میزبان فعال است، پورت‌های موردنیاز باید مطابق معماری باز شوند. غیرفعال‌کردن دائمی فایروال راه‌حل مناسبی برای محیط عملیاتی نیست؛ قوانین را بر اساس APIها، داشبورد، SSH و ترافیک شبکه مجازی تنظیم کنید.

نصب Kolla-Ansible در محیط مجازی Python

استفاده از محیط مجازی مانع تداخل وابستگی‌های Kolla-Ansible با بسته‌های سیستم‌عامل می‌شود:

python3 -m venv ~/kolla-venv
source ~/kolla-venv/bin/activate
python -m pip install --upgrade pip
pip install kolla-ansible

سپس فایل‌های نمونه پیکربندی و Inventory را کپی کنید:

sudo mkdir -p /etc/kolla
sudo chown "$USER":"$USER" /etc/kolla
cp -r ~/kolla-venv/share/kolla-ansible/etc_examples/kolla/* /etc/kolla/
cp ~/kolla-venv/share/kolla-ansible/ansible/inventory/all-in-one ./

Collectionهای موردنیاز Ansible را نیز نصب کنید:

kolla-ansible install-deps

نسخه Kolla-Ansible باید با انتشار موردنظر OpenStack هماهنگ باشد. در محیط عملیاتی، نسخه را در فایل وابستگی‌ها ثابت کنید تا اجرای بعدی ناخواسته از نسخه جدیدتری استفاده نکند.

تنظیم فایل globals.yml

فایل اصلی تنظیمات در مسیر /etc/kolla/globals.yml قرار دارد. برای یک نصب All-in-One ساده، مهم‌ترین گزینه‌ها به شکل زیر هستند:

---
kolla_base_distro: "ubuntu"
kolla_install_type: "binary"
network_interface: "eno1"
neutron_external_interface: "eno2"
kolla_internal_vip_address: "10.20.0.250"
enable_haproxy: "yes"
enable_horizon: "yes"
enable_cinder: "no"

گزینه network_interface رابط شبکه مدیریتی و neutron_external_interface رابط شبکه خارجی را تعیین می‌کند. انتخاب اشتباه رابط خارجی ممکن است دسترسی SSH سرور را قطع کند؛ بنابراین قبل از دیپلوی، نام رابط‌ها و مسیر پیش‌فرض شبکه را دوباره بررسی کنید. در این نمونه Cinder غیرفعال است. اگر به Block Storage نیاز دارید، باید یک backend مانند LVM، Ceph یا سامانه ذخیره‌سازی سازگار تعریف کنید. فعال‌کردن Cinder بدون آماده‌کردن backend، فضای ذخیره‌سازی قابل استفاده‌ای ایجاد نمی‌کند.

تولید رمزهای سرویس‌ها

OpenStack از حساب‌ها و رمزهای متعددی برای ارتباط داخلی استفاده می‌کند. Kolla-Ansible می‌تواند این رمزها را تولید کند:

kolla-genpwd

خروجی در /etc/kolla/passwords.yml ذخیره می‌شود. این فایل اطلاعات حساس دارد؛ دسترسی آن را محدود کنید و نسخه پشتیبان رمزگذاری‌شده داشته باشید:

chmod 600 /etc/kolla/passwords.yml

رمز کاربر مدیریتی OpenStack در کلید keystone_admin_password قرار می‌گیرد. از قرار دادن فایل رمزها در Git یا ارسال آن در پیام‌رسان خودداری کنید.

آماده‌سازی و بررسی سرور

Kolla-Ansible ابتدا وابستگی‌های سیستم، Docker و تنظیمات لازم نود مقصد را آماده می‌کند:

source ~/kolla-venv/bin/activate
kolla-ansible -i ./all-in-one bootstrap-servers

پس از پایان این مرحله، بررسی‌های پیش از نصب را اجرا کنید:

kolla-ansible -i ./all-in-one prechecks

Precheck مواردی مانند دسترسی Ansible، وضعیت رابط شبکه، تنظیمات Docker، آزادبودن VIP و سازگاری پیکربندی را کنترل می‌کند. اگر خطایی نمایش داده شد، قبل از ادامه علت را برطرف کنید. نادیده‌گرفتن خطای شبکه ممکن است دیپلوی ظاهراً موفقی ایجاد کند که APIها یا ماشین‌های مجازی آن قابل دسترسی نیستند. برای اطمینان از دسترسی Ansible نیز می‌توانید دستور زیر را اجرا کنید:

ansible -i ./all-in-one all -m ping

دیپلوی سرویس‌های OpenStack

پس از موفقیت Precheck، استقرار اصلی را آغاز کنید:

kolla-ansible -i ./all-in-one deploy

در این مرحله ایمیج‌ها دریافت می‌شوند و سرویس‌هایی مانند MariaDB، RabbitMQ، Keystone، Glance، Nova، Neutron و Horizon داخل کانتینرها راه‌اندازی می‌شوند. زمان اجرا به سرعت شبکه، قدرت سرور و تعداد سرویس‌های فعال بستگی دارد. بعد از پایان دیپلوی، فایل دسترسی مدیریتی و ابزار خط فرمان را آماده کنید:

kolla-ansible -i ./all-in-one post-deploy
pip install python-openstackclient
source /etc/kolla/admin-openrc.sh
openstack service list

اگر سرویس‌ها در خروجی دیده شوند، لایه احراز هویت و API اصلی فعال است. وضعیت کانتینرها را نیز بررسی کنید:

docker ps

اگر با مدیریت و پاک‌سازی ایمیج‌ها و کانتینرهای Docker آشنا نیستید، مرور آن پیش از عیب‌یابی سرویس‌های Kolla-Ansible مفید است. داشبورد Horizon معمولاً از طریق آدرس VIP در دسترس است:

http://10.20.0.250/

نام کاربری پیش‌فرض مدیریتی admin است و رمز آن را می‌توان از فایل passwords.yml دریافت کرد.

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

برای اجرای نخستین Instance به یک ایمیج، Flavor، شبکه و کلید SSH نیاز دارید. ابتدا یک ایمیج ابری سازگار، مانند Ubuntu Cloud Image یا CirrOS، دریافت و در Glance بارگذاری کنید:

openstack image create "test-image" \
  --file ./image.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --public

سپس یک Flavor کوچک بسازید:

openstack flavor create --ram 2048 --disk 20 --vcpus 2 small-2

شبکه Provider باید با VLAN، رنج IP، Gateway و ساختار واقعی دیتاسنتر هماهنگ شود. نمونه زیر صرفاً الگوی کلی است:

openstack network create --external \
  --provider-network-type flat \
  --provider-physical-network physnet1 public-net
openstack subnet create public-subnet \
  --network public-net \
  --subnet-range 192.0.2.0/24 \
  --allocation-pool start=192.0.2.100,end=192.0.2.150 \
  --gateway 192.0.2.1 \
  --no-dhcp

رنج 192.0.2.0/24 مستنداتی و غیرقابل استفاده در اینترنت واقعی است. آن را با اطلاعات شبکه‌ای که ارائه‌دهنده سرور در اختیار شما قرار داده جایگزین کنید. همچنین پیش از ساخت Instance، Security Group را برای SSH و ICMP به‌صورت محدود تنظیم کنید.

خطاهای رایج در نصب OpenStack روی سرور اختصاصی

یکی از رایج‌ترین مشکلات، انتخاب رابط شبکه اشتباه است. اگر رابط مدیریتی را به‌عنوان رابط خارجی Neutron معرفی کنید، اتصال شما به سرور ممکن است قطع شود. استفاده از کنسول مدیریتی خارج از باند مانند IPMI یا KVM هنگام تغییر شبکه، ریسک قفل‌شدن بیرون از سرور را کاهش می‌دهد. مشکل دیگر به نبود منابع کافی مربوط است. OpenStack حتی پیش از اجرای ماشین مجازی، چندین پایگاه داده، API، Agent و سرویس پیام‌رسان اجرا می‌کند. کمبود رم می‌تواند باعث Restart مداوم کانتینرها یا کندی شدید داشبورد شود. ناسازگاری نسخه‌های Ansible، Python و Kolla-Ansible نیز خطاهای مبهمی ایجاد می‌کند. محیط مجازی جدا، تثبیت نسخه‌ها و مراجعه به مستندات همان انتشار OpenStack از بسیاری از این مشکلات جلوگیری می‌کند. در نهایت، موفقیت دستور deploy به‌تنهایی کافی نیست. ایجاد شبکه، تخصیص Floating IP، دسترسی SSH به Instance، آپلود ایمیج و بازیابی سرویس پس از Reboot را نیز آزمایش کنید.

ملاحظات محیط عملیاتی

معماری All-in-One نقطه خرابی واحد دارد. خرابی سرور، دیسک یا رابط شبکه می‌تواند تمام کنترل‌پلین و ماشین‌های مجازی را از دسترس خارج کند. برای کلود خصوصی عملیاتی، معمولاً حداقل سه نود کنترلر برای سرویس‌های حساس و چند نود Compute مستقل در نظر گرفته می‌شود. همچنین باید برای TLS، مانیتورینگ، جمع‌آوری Log، پشتیبان‌گیری از MariaDB، حفاظت از فایل رمزها، Patch Management و ارتقای دوره‌ای برنامه مشخصی داشته باشید. قرار دادن مستقیم APIهای مدیریتی روی اینترنت عمومی توصیه نمی‌شود؛ دسترسی مدیریتی را از طریق VPN، Bastion Host یا شبکه اختصاصی محدود کنید. برای اقدامات تکمیلی سخت‌سازی سرور میزبان، راهنمای افزایش امنیت سرور لینوکس را نیز مطالعه کنید. اگر برای اجرای OpenStack به سخت‌افزار مستقل، منابع پایدار و دسترسی کامل به شبکه نیاز دارید، می‌توانید مشخصات و گزینه‌های سرور اختصاصی آریانت را بررسی کنید. پیش از سفارش، تعداد رابط‌های شبکه، امکان مجازی‌سازی سخت‌افزاری، نوع دیسک و رنج IP موردنیاز را با معماری کلود خصوصی خود تطبیق دهید.

جمع‌بندی

Kolla-Ansible مسیر ساخت کلود خصوصی را استانداردتر می‌کند و پیچیدگی نصب دستی سرویس‌های OpenStack را کاهش می‌دهد. بااین‌حال، بخش اصلی موفقیت پروژه به طراحی درست شبکه، انتخاب نسخه‌های سازگار، تأمین منابع کافی و برنامه‌ریزی برای امنیت و نگهداری وابسته است. برای شروع، یک استقرار All-in-One فرصت خوبی برای شناخت Keystone، Nova، Neutron، Glance و Horizon فراهم می‌کند. پس از آزمایش کامل می‌توانید Inventory را به معماری چندنودی گسترش دهید، نودهای Compute اضافه کنید و یک backend ذخیره‌سازی پایدار مانند Ceph در نظر بگیرید. به این ترتیب، نصب OpenStack روی سرور اختصاصی از یک محیط آموزشی ساده به زیرساخت ابری قابل توسعه تبدیل می‌شود.