راه‌اندازی Swift برای ذخیره‌سازی آبجکت در OpenStack با Kolla-Ansible روی سرور اختصاصی
اگر پروژه‌ای دارید که حجم زیادی فایل، بکاپ یا محتوای استاتیک تولید می‌کند، دیر یا زود به یک لایه ذخیره‌سازی آبجکت نیاز پیدا می‌کنید. Swift یکی از قدیمی‌ترین و پایدارترین سرویس‌های OpenStack است که دقیقاً همین کار را انجام می‌دهد. در این مقاله راه‌اندازی Swift در OpenStack را با استفاده از Kolla-Ansible، روی چند سرور اختصاصی، قدم‌به‌قدم بررسی می‌کنیم.
Swift چیست و چه زمانی به آن نیاز دارید
Swift یک سرویس ذخیره‌سازی آبجکت (Object Storage) توزیع‌شده است. برخلاف ذخیره‌سازی بلاک که فایل‌سیستم روی یک دیسک مجازی می‌نشیند، Swift داده را به شکل آبجکت در کانتینرها نگه می‌دارد و از طریق API قابل دسترسی است. مدل دسترسی آن شبیه S3 است، با این تفاوت که API بومی خودش را هم دارد.
نقطه قوت Swift تحمل خطای بالا است. داده‌ها بین چند نود و چند دیسک کپی می‌شوند و از دست رفتن یک دیسک یا حتی یک نود کامل، معمولاً باعث از دست رفتن داده نمی‌شود.
تفاوت Swift با Cinder و Ceph
قبل از شروع نصب بهتر است بدانید Swift دقیقاً جای چه چیزی را پر می‌کند و جای چه چیزی را نه.
| ویژگی | Swift | Cinder | Ceph (RBD) |
|---|---|---|---|
| نوع ذخیره‌سازی | آبجکت | بلاک | بلاک + آبجکت + فایل |
| مورد استفاده | بکاپ، فایل استاتیک، آرشیو | دیسک مجازی برای VM | همه موارد، معماری یکپارچه‌تر |
| API | Swift API / سازگار با S3 | iSCSI/RBD داخلی OpenStack | RBD، RGW (سازگار با S3)، CephFS |
| پیچیدگی راه‌اندازی | متوسط | کم (اغلب روی Ceph یا LVM سوار می‌شود) | بالا |
اگر فقط به ذخیره‌سازی بلاک برای دیسک ماشین‌های مجازی نیاز دارید، Cinder کافی است. اگر هدف یک پلتفرم ذخیره‌سازی یکپارچه برای همه چیز است یا به API سازگار با S3 روی یک کلاستر Ceph نیاز دارید، Ceph Object Gateway گزینه جامع‌تری است. Swift زمانی انتخاب درستی است که نیاز مشخص‌تان ذخیره‌سازی آبجکت باشد، بدون پیچیدگی اضافه یک کلاستر Ceph کامل.
پیش‌نیازها روی سرور اختصاصی
Kolla-Ansible، Swift را به شکل کانتینر روی نودهای از پیش آماده‌شده دیپلوی می‌کند. قبل از اجرای playbook باید چند چیز آماده باشد.
دیسک‌ها و پارتیشن‌بندی
Swift برای هر دیسکی که قرار است داده روی آن ذخیره شود، یک پارتیشن با لیبل مشخص می‌خواهد. روی هر سرور اختصاصی که قرار است به‌عنوان storage node عمل کند:
parted /dev/sdb -- mklabel gpt
parted /dev/sdb -- mkpart primary 0% 100%
mkfs.xfs -L d1 /dev/sdb1
mkdir -p /srv/node/d1
mount /dev/sdb1 /srv/node/d1
XFS فایل‌سیستم توصیه‌شده برای Swift است، به دلیل پشتیبانی از extended attributes که Swift برای متادیتای آبجکت‌ها از آن استفاده می‌کند. این مراحل باید روی هر دیسکی که می‌خواهید در Ring شرکت کند تکرار شود؛ معمولاً حداقل دو تا سه دیسک جداگانه در هر نود منطقی است (برای سناریوهایی که در آن‌ها افزونگی در سطح سخت‌افزار هم مد نظر است، پیکربندی RAID نرم‌افزاری با mdadm می‌تواند مکمل Ring باشد).
شبکه و اینترفیس‌ها
Swift روی یک شبکه مجزا (storage network) بهتر کار می‌کند تا ترافیک replication با ترافیک API قاطی نشود. در /etc/kolla/globals.yml این شبکه را از طریق storage_interface مشخص می‌کنید. اگر سرورهای اختصاصی شما فقط یک کارت شبکه دارند، می‌توانید موقتاً از همان اینترفیس اصلی استفاده کنید، اما برای محیط پروداکشن یک رابط جدا یا حداقل یک VLAN اختصاصی توصیه می‌شود.
پیکربندی Kolla-Ansible برای Swift
با فرض اینکه Kolla-Ansible از قبل نصب و bootstrap شده و اینونتوری (multinode) نودها را می‌شناسد، کافی است سرویس Swift را در globals.yml فعال کنید:
enable_swift: "yes"
swift_interface: "{{ storage_interface }}"
سپس باید دیسک‌هایی که در مرحله قبل آماده کردید را به Kolla-Ansible معرفی کنید. فایل /etc/kolla/config/swift/swift.conf یا متغیر swift_devices_match_by در inventory مشخص می‌کند که Swift بر چه اساسی (مثلاً لیبل پارتیشن) دیسک‌های مربوط به خودش را پیدا کند. روش رایج استفاده از لیبل‌هایی مثل d1، d2 است که در مرحله mkfs.xfs -L ساختید.
بعد از تنظیم globals.yml، مرحله prechecks را اجرا کنید تا مطمئن شوید دیسک‌ها و اینترفیس‌ها به‌درستی شناسایی می‌شوند:
kolla-ansible -i multinode prechecks
ساخت Ring های Swift
Ring قلب معماری Swift است؛ نقشه‌ای است که مشخص می‌کند هر آبجکت روی کدام دیسک و کدام نود قرار می‌گیرد. Swift سه نوع ring دارد: account، container و object. Kolla-Ansible این کار را با یک دستور جداگانه انجام می‌دهد:
kolla-ansible -i multinode deploy --tags swift
قبل از deploy کامل، معمولاً Ring را به‌صورت دستی یا با اسکریپت Kolla-Ansible می‌سازید تا تعداد replica و partition power را خودتان کنترل کنید:
swift-ring-builder account.builder create 10 3 1
swift-ring-builder container.builder create 10 3 1
swift-ring-builder object.builder create 10 3 1
عدد ۱۰ قدرت پارتیشن (تعداد پارتیشن‌ها برابر با ۲ به توان ۱۰) و عدد ۳ تعداد replicaهاست، یعنی هر آبجکت در سه نسخه روی دیسک‌های مختلف ذخیره می‌شود. برای محیط‌های تستی با منابع کم، می‌توان replica را به ۲ کاهش داد، اما برای پروداکشن ۳ نسخه استاندارد است.
بعد از اضافه کردن دیسک‌ها به هر builder با دستور swift-ring-builder account.builder add و اجرای rebalance، فایل‌های .ring.gz تولید می‌شوند و باید روی همه نودهای Swift توزیع شوند. Kolla-Ansible این توزیع را در فرآیند deploy خودکار انجام می‌دهد، به شرطی که فایل‌های builder در مسیر /etc/kolla/config/swift/ قرار گرفته باشند.
دیپلوی چند-نودی و تست سرویس
برای یک دیپلوی واقعی روی چند سرور اختصاصی، حداقل سه نود storage توصیه می‌شود تا replica factor سه به‌درستی معنا پیدا کند. بعد از اتمام deploy، سرویس را با CLI یا curl تست کنید:
openstack container create test-container
openstack object create test-container ./sample.txt
openstack object list test-container
اگر فایل در خروجی دیده شود و بدون خطا دانلود شود، Ring و سرویس‌های proxy/account/container/object به‌درستی با هم هماهنگ هستند. در صورت بروز خطای ۵۰۳ یا timeout، اولین جای بررسی لاگ‌های کانتینر swift_proxy_server و اتصال شبکه بین proxy و storage nodeهاست.
نکات نگهداری و مقیاس‌پذیری
اضافه کردن یک دیسک یا نود جدید به Swift نیازی به توقف سرویس ندارد. کافی است دیسک جدید را آماده کنید، به builder اضافه کنید، rebalance بزنید و دوباره deploy را با تگ swift اجرا کنید. Swift به‌تدریج داده را روی دیسک جدید جابه‌جا می‌کند بدون قطعی برای کلاینت‌ها.
نظارت بر مصرف فضا و سلامت دیسک‌ها را جدی بگیرید؛ چون replica در سطح Ring مدیریت می‌شود، پر شدن یک دیسک باعث fail نوشتن روی آن می‌شود، نه خطای کلی سرویس. تنظیم آلارم روی درصد پر بودن هر دیسک به شما کمک می‌کند قبل از رسیدن به ظرفیت کامل، دیسک یا نود اضافه کنید.
جمع‌بندی
راه‌اندازی Swift در OpenStack با Kolla-Ansible شامل چند مرحله مشخص است: آماده‌سازی دیسک‌ها با XFS، تنظیم شبکه storage، فعال‌سازی Swift در globals.yml، ساخت Ring برای account/container/object و در نهایت deploy چند-نودی. نتیجه یک لایه ذخیره‌سازی آبجکت مقیاس‌پذیر و مقاوم در برابر خطا است که می‌توانید برای بکاپ، آرشیو یا سرویس‌دهی فایل استاتیک از آن استفاده کنید.
اگر می‌خواهید این معماری را روی زیرساخت واقعی پیاده‌سازی کنید، برای دیپلوی چندنودی Swift به سرورهایی با دیسک‌های مجزا و شبکه قابل اتکا نیاز دارید. سرورهای اختصاصی آریانت دقیقاً برای چنین سناریویی مناسب هستند و منابع دیسک و شبکه اختصاصی لازم برای یک کلاستر Swift پایدار را فراهم می‌کنند.
