راه‌اندازی Ceph Object Gateway (RGW): ذخیره‌سازی آبجکت سازگار با S3 روی کلاستر Ceph در سرور اختصاصی

اگر یک کلاستر Ceph روی سرور اختصاصی دارید و می‌خواهید علاوه بر Block Storage (RBD) یا فایل‌سیستم (CephFS) به کاربران و اپلیکیشن‌ها دسترسی آبجکتی هم بدهید، سرویسی که به آن نیاز دارید Ceph Object Gateway یا همان RGW است. RGW یک لایه HTTP روی RADOS اضافه می‌کند و رابطی سازگار با S3 (و تا حدی Swift) در اختیار کلاینت‌ها قرار می‌دهد؛ یعنی هر ابزار یا SDK که با S3 کار می‌کند، بدون تغییر با کلاستر Ceph شما هم کار خواهد کرد.

این راهنما فرض می‌کند یک کلاستر Ceph سالم روی سرور اختصاصی (یا چند نود) از قبل با cephadm بالا آمده و OSDها فعال هستند. تمرکز مقاله روی افزودن سرویس RGW، ساخت کاربر و کلید دسترسی S3، و تست عملی با AWS CLI است.

Ceph Object Gateway چیست و چه زمانی به آن نیاز دارید

RGW یک دیمن (radosgw) است که روی هر نود از کلاستر می‌تواند اجرا شود و درخواست‌های HTTP/HTTPS را به عملیات RADOS ترجمه می‌کند. از دید کاربر نهایی، یک endpoint شبیه به S3 می‌بینید: باکت می‌سازید، آبجکت آپلود می‌کنید، ACL تنظیم می‌کنید، و همان API که برای AWS S3 نوشته‌اید کار می‌کند.

موارد رایج استفاده از RGW روی سرور اختصاصی:

• بک‌آپ و آرشیو اپلیکیشن‌ها با ابزارهایی مثل s3cmd، rclone یا SDKهای S3
• ذخیره‌سازی رسانه (تصویر، ویدیو، فایل استاتیک) برای اپلیکیشن‌های وب
• جایگزینی سرویس‌های S3 عمومی برای داده‌هایی که باید روی زیرساخت داخلی بمانند
• بک‌اند ذخیره‌سازی برای ابزارهایی مثل Velero، Loki یا هر پروژه‌ای که خروجی S3-compatible می‌خواهد

اگر فقط به دیسک بلاک یا فایل‌سیستم مشترک نیاز دارید، RBD یا CephFS کافی است و نیازی به RGW نیست. RGW زمانی معنا پیدا می‌کند که مصرف‌کننده‌ی داده با API آبجکتی کار می‌کند، نه با mount شدن دیسک.

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

قبل از افزودن RGW این موارد را بررسی کنید:

• کلاستر Ceph فعال با حداقل یک مانیتور، یک منیجر و چند OSD سالم (ceph -s باید HEALTH_OK بدهد)
• دسترسی cephadm و docker/podman روی نودها (cephadm سرویس‌ها را به‌صورت کانتینر اجرا می‌کند)
• یک پورت آزاد (پیش‌فرض 80 یا 8080 برای HTTP، 443 برای HTTPS) روی نودی که RGW روی آن مستقر می‌شود
• فضای کافی روی OSDها متناسب با حجم داده‌ای که قرار است ذخیره شود

اگر کلاستر را روی سرور اختصاصی خودتان بالا آورده‌اید، حتماً مطمئن شوید که فایروال پورت RGW را به سمت شبکه‌ای که کلاینت‌ها از آن وصل می‌شوند باز کرده باشد؛ این مورد در تست اولیه بیشترین خطاهای «connection refused» را ایجاد می‌کند.

استقرار سرویس RGW با cephadm

با cephadm، افزودن RGW به یک دستور خلاصه می‌شود. ابتدا یک realm و zone پیش‌فرض (در صورت نبود) ساخته می‌شود، سپس سرویس روی نود یا نودهای مشخص مستقر می‌شود.

# بررسی سلامت کلاستر قبل از افزودن سرویس جدید
ceph -s

# استقرار RGW روی یک نود مشخص با placement صریح
ceph orch apply rgw my-rgw --placement="1 host1"

برای استقرار روی چند نود (جهت توزیع بار و تحمل خطا):

ceph orch apply rgw my-rgw --placement="3 host1 host2 host3"

وضعیت سرویس را می‌توانید این‌طور بررسی کنید:

ceph orch ps --daemon-type rgw

خروجی باید دیمن(های) radosgw را با وضعیت running نشان دهد. پیش‌فرض cephadm پورت 80 را برای هر دیمن RGW باز می‌کند؛ اگر چند دیمن روی یک نود اجرا می‌شود، پورت‌ها به‌صورت خودکار افزایش می‌یابند (80، 8000، 8001 و...).

تنظیم HTTPS برای RGW

برای محیط production، ترافیک RGW باید روی HTTPS باشد. ساده‌ترین راه، تعریف یک سرویس با فلگ SSL و گواهی از پیش آماده است:

ceph orch apply rgw my-rgw --placement="1 host1" --port=443 --ssl

گواهی SSL را می‌توانید با ceph config-key set به‌صورت داخلی به کلاستر بدهید یا یک reverse proxy (مثل HAProxy یا Nginx) جلوی RGW قرار دهید و ترمینیشن TLS را آنجا انجام دهید. برای سرورهای اختصاصی با ترافیک زیاد، گزینه‌ی reverse proxy معمولاً انعطاف بیشتری برای لاگ‌گیری و rate limiting می‌دهد.

ساخت کاربر و کلید دسترسی S3

RGW کاربران خودش را جدا از کاربران سیستم‌عامل یا Ceph auth مدیریت می‌کند. برای ساخت کاربری که access key و secret key سازگار با S3 داشته باشد:

radosgw-admin user create \
  --uid="app-user" \
  --display-name="Application User" \
  --email="app-user@example.com"

خروجی این دستور یک بلوک JSON برمی‌گرداند که شامل access_key و secret_key است:

"keys": [
  {
    "user": "app-user",
    "access_key": "XXXXXXXXXXXXXXXXXXXX",
    "secret_key": "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY"
  }
]

این دو مقدار را جایی امن نگه دارید؛ همین‌ها بعداً در پیکربندی AWS CLI یا هر SDK دیگری استفاده می‌شوند. برای دیدن مجدد کلیدهای یک کاربر بدون ساخت کاربر جدید:

radosgw-admin user info --uid="app-user"

اگر نیاز به محدود کردن سهمیه‌ی کاربر دارید (مثلاً حداکثر حجم یا تعداد آبجکت)، از quota استفاده کنید:

radosgw-admin quota set --uid="app-user" --quota-scope=user --max-size=100G
radosgw-admin quota enable --uid="app-user" --quota-scope=user

تست با AWS CLI

با کلیدهای ساخته‌شده، می‌توانید مستقیماً از AWS CLI برای کار با RGW استفاده کنید؛ کافی است endpoint را به آدرس RGW خودتان تغییر دهید.

ابتدا یک پروفایل جدید بسازید:

aws configure --profile ceph-rgw
# AWS Access Key ID: access_key از مرحله قبل
# AWS Secret Access Key: secret_key از مرحله قبل
# Default region name: خالی بگذارید یا هر مقدار دلخواه
# Default output format: json

سپس هر دستور S3 را با فلگ --endpoint-url به سمت RGW هدایت کنید:

# ساخت باکت
aws --profile ceph-rgw --endpoint-url https://rgw.example.internal:443 \
  s3 mb s3://test-bucket

# آپلود فایل
aws --profile ceph-rgw --endpoint-url https://rgw.example.internal:443 \
  s3 cp ./sample.txt s3://test-bucket/

# فهرست آبجکت‌های باکت
aws --profile ceph-rgw --endpoint-url https://rgw.example.internal:443 \
  s3 ls s3://test-bucket/

اگر گواهی SSL self-signed است، برای تست اولیه می‌توانید از --no-verify-ssl استفاده کنید؛ اما در production حتماً گواهی معتبر یا CA داخلی را به سیستم کلاینت اضافه کنید تا نیازی به این فلگ نباشد.

مقایسه RGW با گزینه‌های دیگر ذخیره‌سازی آبجکت

اگر بین Ceph RGW، MinIO و سرویس S3 عمومی مردد هستید، تفاوت اصلی در کنترل، مقیاس‌پذیری و هزینه‌ی نگهداری است.

ویژگی	Ceph RGW	MinIO	AWS S3 عمومی
محل استقرار	روی زیرساخت خودتان (سرور اختصاصی)	روی زیرساخت خودتان	فضای ابری AWS
سازگاری با S3 API	بالا	بالا	مرجع اصلی S3
مقیاس‌پذیری	با افزودن OSD/نود در همان کلاستر	با افزودن نود MinIO جدا	نامحدود، مدیریت‌شده توسط AWS
اشتراک زیرساخت با RBD/CephFS	بله، همان کلاستر Ceph	خیر، سرویس مجزا	موضوعیت ندارد
هزینه در مقیاس بزرگ	هزینه ثابت سرور، بدون هزینه per-GB جاری	هزینه ثابت سرور	هزینه per-GB و per-request مداوم
کنترل روی داده و محل نگهداری	کامل	کامل	محدود به منطقه AWS

اگر از قبل کلاستر Ceph برای RBD یا CephFS دارید، افزودن RGW ارزان‌ترین مسیر است چون از همان OSDها و همان ظرفیت استفاده می‌کند. اگر هیچ کلاستر Cephی در کار نیست و فقط ذخیره‌سازی آبجکتی می‌خواهید، MinIO راه‌اندازی ساده‌تری دارد.

نکات امنیتی و بهینه‌سازی

چند نکته که معمولاً بعد از راه‌اندازی اولیه فراموش می‌شوند:

• محدود کردن دسترسی شبکه‌ای: پورت RGW را فقط به سمت شبکه‌ای که واقعاً باید به آن دسترسی داشته باشد باز کنید، نه به اینترنت عمومی، مگر اینکه سرویس واقعاً عمومی باشد.
• چرخش کلید: برای کاربران با دسترسی حساس، کلید access/secret را به‌صورت دوره‌ای با radosgw-admin key create و key rm جایگزین کنید.
• لاگ دسترسی: RGW لاگ‌های خودش را در کنار لاگ کانتینر دارد؛ برای محیط production ارسال این لاگ‌ها به یک سیستم مرکزی (مثل Loki) کمک زیادی در تشخیص مشکلات می‌کند.
• Multi-site: اگر بعداً نیاز به replication بین دو سرور اختصاصی یا دو دیتاسنتر داشتید، Ceph از پیکربندی multi-site برای RGW پشتیبانی می‌کند؛ این موضوع خارج از محدوده این راهنما است ولی از همین معماری تک‌سایت قابل ارتقا است.

جمع‌بندی

راه‌اندازی Ceph Object Gateway روی یک کلاستر Ceph موجود، کار پیچیده‌ای نیست: یک دستور ceph orch apply rgw، ساخت کاربر با radosgw-admin، و تست با AWS CLI کافی است تا یک endpoint کاملاً سازگار با S3 داشته باشید. مزیت اصلی نسبت به سرویس‌های آبجکتی جدا این است که همان کلاستری که برای RBD یا CephFS دارید را برای ذخیره‌سازی آبجکت هم به کار می‌گیرید، بدون هزینه‌ی نگهداری یک سیستم موازی.

اگر هنوز کلاستر Ceph روی زیرساخت خودتان ندارید یا منابع فعلی برای اجرای OSDها و RGW کافی نیست، این کار روی یک سرور اختصاصی با دیسک و شبکه مناسب قابل انجام است؛ می‌توانید کلاستر را از صفر با cephadm بالا بیاورید و همین مراحل را روی آن پیاده کنید.