راه‌اندازی Cinder برای ذخیره‌سازی بلاک در OpenStack با بک‌اند LVM روی سرور اختصاصی

اگر یک کلاستر OpenStack را با Kolla-Ansible بالا آورده‌اید، احتمالاً به این نقطه رسیده‌اید که Nova برای اجرای اینستنس‌ها کافی است اما دیسک ephemeral آن با ری‌استارت یا حذف اینستنس از بین می‌رود. Cinder همین مشکل را حل می‌کند: یک سرویس ذخیره‌سازی بلاک که به اینستنس‌ها ولوم‌های مستقل و پایدار می‌دهد. این راهنما راه‌اندازی Cinder در OpenStack را با بک‌اند LVM روی یک سرور اختصاصی، از آماده‌سازی دیسک تا اولین ولوم واقعی، توضیح می‌دهد.

این روش برای کسانی مناسب است که کلاستر را روی یک یا چند سرور اختصاصی اجرا می‌کنند و فعلاً به یک استوریج توزیع‌شده نیاز ندارند. تمام دستورها روی همان نودی اجرا می‌شود که Kolla-Ansible را برای deploy اولیه کلاستر استفاده کرده‌اید.

Cinder چیست و چه کاری انجام می‌دهد؟

Cinder سرویس ذخیره‌سازی بلاک OpenStack است. وظیفه‌اش ساخت، حذف، snapshot گرفتن و attach/detach کردن ولوم‌ها به اینستنس‌های Nova است. از دید کاربر، یک ولوم Cinder دقیقاً مثل یک دیسک SATA یا SSD معمولی به اینستنس متصل می‌شود و داده‌اش مستقل از چرخه حیات اینستنس باقی می‌ماند.

Cinder خودش داده را ذخیره نمی‌کند؛ این کار را به یک بک‌اند storage می‌سپارد. بک‌اند می‌تواند Ceph RBD، NFS، آرایه‌های SAN تجاری، یا LVM روی دیسک محلی باشد. انتخاب بک‌اند مستقیماً روی کارایی، مقیاس‌پذیری و پیچیدگی نگهداری اثر می‌گذارد.

چرا LVM برای شروع کار منطقی است؟

LVM (Logical Volume Manager) یک لایه مدیریت دیسک در لینوکس است که یک یا چند دیسک فیزیکی را در قالب Volume Group ترکیب می‌کند و از آن، Logical Volume به اندازه دلخواه می‌سازد. Cinder با درایور cinder.volume.drivers.lvm.LVMVolumeDriver مستقیماً از این مکانیزم استفاده می‌کند: هر ولوم Cinder یک LV داخل یک VG مشخص است که از طریق iSCSI به کامپیوت‌نود export می‌شود.

مزیت اصلی LVM این است که به هیچ زیرساخت اضافه‌ای نیاز ندارد؛ فقط یک یا چند دیسک خام روی همان سرور یا یک سرور استوریج اختصاصی کافی است. در مقابل، Ceph کارایی و HA بهتری می‌دهد اما حداقل سه نود مجزا برای مانیتور و OSD می‌خواهد. برای یک کلاستر تک‌سروری یا محیط تست/کوچک، LVM نقطه شروع واقع‌بینانه‌تری است.

جدول زیر تفاوت بک‌اندهای رایج Cinder را خلاصه می‌کند:

بک‌اند	نیاز به نودهای اضافه	High Availability	کارایی I/O	مناسب برای
LVM	خیر، همان سرور کافی است	ندارد (SPOF)	خوب روی SSD محلی	محیط تست، کلاستر تک‌سروری
Ceph RBD	حداقل ۳ نود OSD/MON	دارد	خوب تا عالی، مقیاس‌پذیر	کلاسترهای production چندسروری
NFS	یک NFS server جدا	به NFS server وابسته	متوسط، سربار شبکه‌ای دارد	اشتراک‌گذاری ساده بین چند کامپیوت‌نود

اگر کلاستر بعداً به چند سرور اختصاصی گسترش پیدا کند، مهاجرت از LVM به Ceph با cinder-manage و ابزارهای migration ممکن است، اما از ابتدا برنامه‌ریزی برای آن نگه دارید.

پیش‌نیازها

قبل از شروع مطمئن شوید:

• کلاستر OpenStack با Kolla-Ansible روی سرور اختصاصی از قبل deploy شده و Nova/Neutron کار می‌کنند.
• یک دیسک یا پارتیشن خام و بدون فایل‌سیستم روی همان سرور یا سرور کنترلر برای VG رزرو شده است (نه دیسک سیستم‌عامل).
• دسترسی SSH با کاربر deploy همان کاربری که Kolla-Ansible را اجرا کرده است.
• فایل globals.yml و inventory پروژه Kolla-Ansible در دسترس است.

مرحله ۱: آماده‌سازی دیسک و Volume Group

فرض کنید دیسک خام روی سرور به‌صورت /dev/sdb شناسایی شده است. ابتدا یک Physical Volume بسازید و سپس Volume Group را با نام استاندارد cinder-volumes ایجاد کنید:

sudo pvcreate /dev/sdb
sudo vgcreate cinder-volumes /dev/sdb
sudo vgs

خروجی vgs باید VG جدید را با فضای کامل دیسک نشان دهد. نام cinder-volumes دلخواه نیست؛ همین مقدار باید در globals.yml هم تنظیم شود، پس بهتر است همین نام پیش‌فرض را نگه دارید مگر دلیل خاصی برای تغییرش دارید.

اگر چند دیسک برای این کار در نظر گرفته‌اید، همه را در همان مرحله pvcreate و سپس در یک vgcreate با چند device اضافه کنید:

sudo pvcreate /dev/sdb /dev/sdc
sudo vgcreate cinder-volumes /dev/sdb /dev/sdc

مرحله ۲: پیکربندی Kolla-Ansible برای Cinder

فعال‌سازی سرویس در globals.yml

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

enable_cinder: "yes"
enable_cinder_backend_lvm: "yes"
cinder_volume_group: "cinder-volumes"

اگر بک‌اند دیگری (مثل Ceph) قبلاً فعال بوده و می‌خواهید فقط LVM اضافه شود، بقیه فلگ‌های backend را no نگه دارید. Cinder اجازه چند بک‌اند همزمان را می‌دهد، اما برای این راهنما فرض بر تک‌بک‌اند LVM است.

پیکربندی iSCSI و multipath

بک‌اند LVM از tgtd یا iSCSI target برای export کردن ولوم به کامپیوت‌نودها استفاده می‌کند. Kolla-Ansible این را خودکار مدیریت می‌کند، اما کرنل هاست باید ماژول‌های iSCSI را در اختیار داشته باشد:

sudo modprobe iscsi_tcp
lsmod | grep iscsi

اگر سرور از multipath استفاده نمی‌کند (حالت رایج در یک سرور اختصاصی تک‌دیسکی)، نیازی به تنظیم اضافه نیست؛ Kolla-Ansible مقدار پیش‌فرض را خودش می‌گذارد.

نام‌گذاری backend و volume type

Kolla-Ansible هنگام فعال کردن enable_cinder_backend_lvm یک بخش با نام lvm-1 در cinder.conf می‌سازد و volume_backend_name را روی همین مقدار تنظیم می‌کند. برای اینکه ولوم‌های جدید حتماً روی این بک‌اند ساخته شوند، بعد از deploy یک Volume Type متناظر بسازید:

openstack volume type create lvm-backend
openstack volume type set lvm-backend --property volume_backend_name=lvm-1

بدون این مرحله هم Cinder کار می‌کند چون فقط یک بک‌اند فعال دارید، اما وقتی بعداً بک‌اند دومی (مثلاً Ceph) اضافه کنید، بدون Volume Type درست، Scheduler نمی‌داند ولوم را کجا بسازد.

مرحله ۳: اجرای Deploy

بعد از ذخیره تغییرات در globals.yml، prechecks و deploy را فقط برای تگ cinder اجرا کنید تا سرویس‌های دیگر دست‌نخورده بمانند:

kolla-ansible prechecks -i /etc/kolla/multinode -t cinder
kolla-ansible deploy -i /etc/kolla/multinode -t cinder

اگر خطایی درباره VG یافت نشود گزارش شد، برگردید و مطمئن شوید نام VG در globals.yml دقیقاً با خروجی vgs مطابقت دارد.

مرحله ۴: تست و ایجاد اولین ولوم

بعد از پایان deploy، وضعیت سرویس‌ها را چک کنید:

openstack volume service list

باید cinder-scheduler و cinder-volume را در وضعیت up ببینید. سپس یک ولوم آزمایشی بسازید و به یک اینستنس متصل کنید:

openstack volume create --size 10 test-volume
openstack volume list
openstack server add volume <server-name> test-volume

داخل اینستنس با lsblk باید دیسک جدید را ببینید. این تست ساده تایید می‌کند که مسیر Cinder → iSCSI → Nova به‌درستی کار می‌کند.

گرفتن Snapshot و بکاپ از ولوم

بعد از تایید اینکه ولوم‌سازی درست کار می‌کند، snapshot گرفتن را هم تست کنید. Snapshot در بک‌اند LVM از قابلیت native خود LVM استفاده می‌کند و برخلاف Ceph، فضای جداگانه‌ای از همان VG کم می‌کند:

openstack volume snapshot create --volume test-volume test-snapshot
openstack volume snapshot list

از روی همین snapshot می‌توانید یک ولوم جدید بسازید بدون اینکه به ولوم اصلی دست بزنید:

openstack volume create --snapshot test-snapshot restored-volume

نکته مهم: چون snapshotهای LVM از همان فضای VG کم می‌شوند، اگر فضای خالی VG تمام شود، هم ساخت ولوم جدید و هم snapshotهای موجود دچار مشکل می‌شوند. فضای خالی VG را با vgs -o vg_name,vg_free به‌طور دوره‌ای چک کنید؛ در صورت نیاز به فضای بیشتر، تغییر اندازه گروه حجمی و حجم منطقی گزینه بعدی است.

مانیتورینگ و عیب‌یابی رایج

چند مشکل که معمولاً در همین مرحله پیش می‌آید:

• سرویس cinder-volume در وضعیت down: معمولاً به این معناست که کانتینر به VG دسترسی ندارد. لاگ کانتینر را با docker logs cinder_volume بررسی کنید.
• ولوم در وضعیت error می‌ماند: فضای خالی VG را با vgs چک کنید؛ اگر VG پر شده باشد، ساخت ولوم جدید شکست می‌خورد.
• attach به اینستنس با تایم‌اوت مواجه می‌شود: معمولاً به تنظیمات شبکه بین کامپیوت‌نود و کنترلر (پورت iSCSI ۳۲۶۰) برمی‌گردد؛ فایروال بین نودها را بررسی کنید.

جمع‌بندی

راه‌اندازی Cinder با بک‌اند LVM روی یک سرور اختصاصی به زیرساخت پیچیده‌ای نیاز ندارد: یک دیسک خام، یک Volume Group، و چند خط تنظیم در globals.yml کافی است تا کلاستر OpenStack شما دیسک پایدار برای اینستنس‌ها داشته باشد. وقتی نیاز به مقیاس بیشتر یا HA پیدا کردید، همین ساختار پایه است که مسیر مهاجرت به Ceph یا SAN را هم ساده‌تر می‌کند.

اگر هنوز این کلاستر را روی یک سرور آزمایشی یا اشتراکی اجرا می‌کنید، عملکرد LVM به‌شدت به I/O دیسک زیرین وابسته است. برای گرفتن نتیجه واقعی از این معماری، یک سرور اختصاصی آریانت با دیسک SSD اختصاصی را در نظر بگیرید تا تاخیر و throughput ولوم‌های Cinder قابل پیش‌بینی باشد.