راه‌اندازی CephFS: فضای ذخیره‌سازی اشتراکی بین چند سرور اختصاصی و VPS

وقتی چند سرور باید هم‌زمان به مجموعه‌ای مشترک از فایل‌ها دسترسی داشته باشند، کپی‌کردن داده میان آن‌ها خیلی زود دردسرساز می‌شود. فایل‌های کاربران، خروجی پردازش‌ها، نسخه‌های پشتیبان یا داده‌های یک سامانه وب ممکن است روی یک سرور تغییر کنند و لازم باشد همان تغییر بلافاصله برای سرورهای دیگر هم قابل مشاهده باشد. CephFS یک فایل‌سیستم توزیع‌شده و سازگار با POSIX است که روی ذخیره‌سازی شیء Ceph قرار می‌گیرد. کلاینت‌ها آن را مانند یک فایل‌سیستم معمولی مانت می‌کنند، اما داده میان OSDهای کلاستر توزیع می‌شود. در نتیجه، یک سرور NFS منفرد در مسیر دسترسی قرار نمی‌گیرد و ظرفیت ذخیره‌سازی نیز محدود به دیسک یک ماشین نیست. در این راهنما، راه‌اندازی CephFS را روی یک کلاستر Ceph موجود انجام می‌دهیم، سرویس MDS را فعال می‌کنیم و سپس فایل‌سیستم را با kernel client و ceph-fuse روی چند سرور اختصاصی یا VPS مانت می‌کنیم.

CephFS چگونه کار می‌کند؟

CephFS داده و متادیتا را از هم جدا نگه می‌دارد. محتوای فایل‌ها داخل یک data pool ذخیره می‌شود و اطلاعاتی مانند نام فایل، مسیر، مالک، مجوز و ساختار دایرکتوری‌ها در metadata pool قرار می‌گیرد. سرویس Metadata Server یا MDS عملیات مربوط به متادیتا را مدیریت می‌کند. MDS خود داده فایل را نگه نمی‌دارد؛ کلاینت پس از دریافت اطلاعات لازم، داده را مستقیماً از OSDهای Ceph می‌خواند یا روی آن‌ها می‌نویسد. همین طراحی باعث می‌شود انتقال داده از یک سرور واسط عبور نکند.

Ceph علاوه بر CephFS، به‌عنوان ذخیره‌سازی بلوکی هم کاربرد دارد؛ برای نمونه در استفاده از Ceph RBD به‌عنوان بک‌اند ذخیره‌سازی برای ماشین‌های مجازی KVM همین کلاستر برای دیسک ماشین‌های مجازی به کار می‌رود. تفاوت اصلی در این است که CephFS یک فایل‌سیستم مشترک با دسترسی هم‌زمان چند کلاینت ارائه می‌دهد، درحالی‌که RBD یک دیسک بلوکی معمولاً برای یک ماشین مجازی است. اجزای اصلی در این سناریو عبارت‌اند از: - کلاستر Ceph شامل MON، MGR و OSD - یک pool برای داده‌های CephFS - یک pool جداگانه برای متادیتا - دست‌کم یک MDS فعال - کلاینت‌های لینوکسی متصل به شبکه کلاستر - کاربر Ceph با دسترسی محدود به فایل‌سیستم موردنظر این آموزش فرض می‌کند وضعیت کلاستر موجود سالم است و ابزار ceph روی نود مدیریتی در دسترس قرار دارد. اگر هنوز چنین کلاستری ندارید، ابتدا راه‌اندازی کلاستر Ceph با Cephadm روی سرور اختصاصی را انجام دهید.

پیش‌نیازهای راه‌اندازی CephFS

پیش از ایجاد فایل‌سیستم، سلامت کلاستر را بررسی کنید:

ceph status
ceph health detail
ceph osd tree

وضعیت HEALTH_OK حالت مطلوب است. بعضی هشدارهای کنترل‌شده مانع ساخت CephFS نمی‌شوند، اما نباید خطاهایی مانند OSDهای خارج از دسترس، کمبود فضای جدی یا از دست رفتن quorum مانیتورها را نادیده گرفت. ارتباط شبکه‌ای کلاینت‌ها با MONها و OSDها نیز ضروری است. اگر میان VPS، سرور اختصاصی و شبکه Ceph فایروال وجود دارد، پورت‌های نسخه نصب‌شده Ceph را طبق پیکربندی همان کلاستر باز کنید (برای تنظیم قوانین فایروال ببینید: راه‌اندازی فایروال nftables روی سرور لینوکس). در نسخه‌های جدید، MON معمولاً از پورت‌های 3300 و 6789 استفاده می‌کند و ترافیک OSD روی بازه پورت تنظیم‌شده برای سرویس‌های Ceph جریان دارد. همچنین ساعت سیستم‌ها باید با NTP یا سرویس مشابه همگام باشد. اختلاف ساعت محسوس میان اعضای کلاستر و کلاینت‌ها می‌تواند عیب‌یابی احراز هویت و لاگ‌ها را دشوار کند.

ساخت poolهای داده و متادیتا

برای نمونه، نام فایل‌سیستم را sharedfs انتخاب می‌کنیم. ابتدا دو pool می‌سازیم:

ceph osd pool create cephfs_shared_data 64
ceph osd pool create cephfs_shared_metadata 32

اعداد 64 و 32 تعداد placement groupهای اولیه هستند و برای همه کلاسترها مقدار مناسبی محسوب نمی‌شوند. مقدار درست به تعداد OSDها، اندازه کلاستر، نسخه Ceph و فعال‌بودن autoscaler بستگی دارد. در کلاسترهای جدید بهتر است وضعیت autoscaler را بررسی کنید:

ceph osd pool autoscale-status

برای فعال‌کردن autoscaling روی poolها می‌توانید اجرا کنید:

ceph osd pool set cephfs_shared_data pg_autoscale_mode on
ceph osd pool set cephfs_shared_metadata pg_autoscale_mode on

metadata pool معمولاً باید replication مطمئنی داشته باشد، چون خرابی متادیتا می‌تواند کل ساختار فایل‌سیستم را تحت تأثیر قرار دهد. استفاده از erasure coding برای data pool در بعضی طراحی‌ها ممکن است، اما metadata pool باید replicated باشد. اکنون فایل‌سیستم را ایجاد کنید:

ceph fs new sharedfs cephfs_shared_metadata cephfs_shared_data

نتیجه را بررسی کنید:

ceph fs ls
ceph fs status sharedfs

در این مرحله فایل‌سیستم ساخته شده است، ولی برای ارائه کامل سرویس به MDS نیاز داریم.

راه‌اندازی سرویس MDS

اگر کلاستر با cephadm مدیریت می‌شود، MDS را با orchestrator مستقر کنید:

ceph orch apply mds sharedfs --placement="2"

این فرمان دو daemon ایجاد می‌کند. CephFS به‌صورت معمول یکی را فعال نگه می‌دارد و دیگری می‌تواند در وضعیت standby باشد. در محیط عملیاتی، بهتر است MDSها روی میزبان‌های جدا قرار بگیرند تا خرابی یک میزبان هر دو نمونه را متوقف نکند. برای تعیین میزبان‌ها به‌صورت صریح می‌توان از placement سازگار با نسخه Ceph کلاستر استفاده کرد؛ برای مثال:

ceph orch apply mds sharedfs --placement="2 mds01 mds02"

سپس وضعیت را ببینید:

ceph orch ps --daemon-type mds
ceph fs status sharedfs

باید یک MDS در حالت active دیده شود. نمونه دوم معمولاً به‌عنوان standby آماده جایگزینی است. افزایش تعداد daemonها لزوماً به معنی چند MDS فعال نیست؛ فعال‌کردن چند rank تصمیم جداگانه‌ای است و بیشتر برای بارهای متادیتای سنگین کاربرد دارد.

ساخت کاربر محدود برای کلاینت‌ها

استفاده از کلید مدیر کلاستر روی سرورهای مصرف‌کننده خطر غیرضروری ایجاد می‌کند. یک کاربر مخصوص CephFS بسازید:

ceph auth get-or-create client.cephfs \
  mon 'allow r' \
  mds 'allow rw fsname=sharedfs' \
  osd 'allow rw tag cephfs data=sharedfs'

برای ذخیره keyring:

ceph auth get client.cephfs \
  -o /etc/ceph/ceph.client.cephfs.keyring

فایل ceph.conf و keyring را از مسیری امن به هر کلاینت منتقل کنید. مجوز فایل کلید را محدود نگه دارید:

chmod 600 /etc/ceph/ceph.client.cephfs.keyring

اگر هر سرور یا هر گروه کاری باید مجوز متفاوتی داشته باشد، برای آن‌ها کاربران جدا بسازید. CephX امکان محدودکردن دسترسی به مسیر مشخصی از CephFS را نیز فراهم می‌کند؛ این روش برای جداکردن داده چند سرویس از یکدیگر مفید است.

مانت CephFS با kernel client

kernel client معمولاً برای سرورهای لینوکسی انتخاب اول است. این روش در فضای kernel اجرا می‌شود، سربار کمتری دارد و برای بارهای ورودی و خروجی مداوم مناسب است. ابتدا بسته‌های کلاینت Ceph را از مخزن سازگار با نسخه سیستم‌عامل نصب کنید. سپس مسیر مانت را بسازید:

mkdir -p /mnt/sharedfs

برای مانت با قالب قدیمی که در نسخه‌های مختلف Ceph رایج است، آدرس MONها را وارد کنید:

mount -t ceph 10.10.0.11:6789,10.10.0.12:6789,10.10.0.13:6789:/ \
  /mnt/sharedfs \
  -o name=cephfs,fs=sharedfs,secretfile=/etc/ceph/cephfs.secret

فایل cephfs.secret باید فقط مقدار کلید را داشته باشد، نه کل محتوای keyring. می‌توانید آن را از خروجی زیر دریافت و با دسترسی محدود ذخیره کنید:

ceph auth print-key client.cephfs

در نسخه‌های جدید Ceph، قالب دستگاه نیز قابل استفاده است:

mount -t ceph cephfs@.sharedfs=/ /mnt/sharedfs \
  -o mon_addr=10.10.0.11:6789/10.10.0.12:6789/10.10.0.13:6789,secretfile=/etc/ceph/cephfs.secret

پس از مانت، یک آزمایش ساده انجام دهید:

touch /mnt/sharedfs/test-from-server-a
ls -la /mnt/sharedfs
df -hT /mnt/sharedfs

همان مسیر را روی سرور دوم مانت کنید و وجود فایل آزمایشی را بررسی کنید. اگر فایل بلافاصله دیده شود، اشتراک‌گذاری پایه درست کار می‌کند. برای مانت خودکار پس از راه‌اندازی سیستم، ورودی متناسب با روش انتخاب‌شده را به /etc/fstab اضافه کنید. گزینه _netdev مهم است، چون مانت باید پس از آماده‌شدن شبکه انجام شود:

10.10.0.11:6789,10.10.0.12:6789,10.10.0.13:6789:/ /mnt/sharedfs ceph name=cephfs,fs=sharedfs,secretfile=/etc/ceph/cephfs.secret,_netdev,noatime 0 2

پیش از ریبوت، تنظیم را آزمایش کنید:

umount /mnt/sharedfs
mount -a

مانت با ceph-fuse

ceph-fuse فایل‌سیستم را در فضای کاربر مانت می‌کند. این روش زمانی مفید است که kernel client سیستم قدیمی یا ناسازگار باشد، امکان نصب ماژول مناسب وجود نداشته باشد یا عیب‌یابی در فضای کاربر ترجیح داده شود. پس از نصب بسته ceph-fuse، مسیر مانت را بسازید و فرمان زیر را اجرا کنید:

mkdir -p /mnt/sharedfs
ceph-fuse --id cephfs --client_fs sharedfs /mnt/sharedfs

این فرمان انتظار دارد فایل‌های /etc/ceph/ceph.conf و /etc/ceph/ceph.client.cephfs.keyring وجود داشته باشند. وضعیت مانت را با این دستورها بررسی کنید:

mount | grep sharedfs
ceph-fuse --version

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

fusermount -u /mnt/sharedfs

در بیشتر بارهای عملیاتی، kernel client عملکرد بهتری دارد. ceph-fuse بیشتر برای سازگاری، آزمایش یا محیط‌هایی مناسب است که کنترل محدودی روی kernel دارند.

مقایسه CephFS با NFS و GlusterFS

انتخاب فایل‌سیستم اشتراکی باید با اندازه زیرساخت و نحوه استفاده از داده هماهنگ باشد.

معیار	CephFS	NFS	GlusterFS
معماری	توزیع‌شده روی RADOS	معمولاً متکی به یک یا چند سرور فایل	توزیع‌شده روی brickها
مقیاس‌پذیری ظرفیت	بالا با افزودن OSD	وابسته به ظرفیت سرور یا سامانه پشت NFS	با افزودن brick قابل توسعه است
نقطه خرابی منفرد	با MON، MDS و OSD افزونه قابل حذف است	در نصب ساده، سرور NFS نقطه خرابی است	با replica و quorum قابل کاهش است
پیچیدگی نگهداری	زیاد؛ نیازمند کلاستر Ceph سالم	کم در نصب‌های کوچک	متوسط
دسترسی کلاینت	kernel client یا ceph-fuse	پشتیبانی گسترده در سیستم‌عامل‌ها	FUSE یا روش‌های سازگار
کاربرد مناسب	زیرساخت‌های متوسط و بزرگ مبتنی بر Ceph	اشتراک فایل ساده و محدود	فایل‌سیستم توزیع‌شده بدون کلاستر Ceph موجود

اگر فقط دو یا سه سرور و حجم محدودی از داده دارید، NFS ممکن است ساده‌تر باشد. اگر از قبل کلاستر Ceph دارید، افزودن CephFS معمولاً منطقی‌تر از ساخت یک سامانه ذخیره‌سازی مستقل است. GlusterFS نیز گزینه‌ای جداگانه است، اما نگهداری هم‌زمان Ceph و GlusterFS پیچیدگی عملیاتی را افزایش می‌دهد.

تنظیم مجوزها برای چند سرور

CephFS مجوزهای معمول لینوکس، مالکیت فایل و ACL را پشتیبانی می‌کند. بااین‌حال UID و GID کاربران باید میان کلاینت‌ها یکسان باشد. اگر کاربر سرویس وب روی سرور اول UID برابر 1001 و روی سرور دوم UID دیگری داشته باشد، نام کاربر ظاهری کمکی به کنترل دسترسی نمی‌کند؛ فایل‌سیستم مقدار عددی شناسه را می‌بیند. برای بررسی شناسه کاربر اجرا کنید:

id www-data

در محیط‌های بزرگ‌تر می‌توان هویت‌ها را با LDAP، FreeIPA یا سامانه مشابه هماهنگ کرد. برای یک سرویس محدود نیز ساخت کاربر سیستمی با UID و GID ثابت روی همه کلاینت‌ها کافی است. اگر چند برنامه از یک CephFS استفاده می‌کنند، برای هرکدام یک زیرشاخه بسازید:

mkdir -p /mnt/sharedfs/apps/site-a
mkdir -p /mnt/sharedfs/apps/site-b
chown -R 1001:1001 /mnt/sharedfs/apps/site-a
chmod 750 /mnt/sharedfs/apps/site-a

سپس مجوز CephX هر کلاینت را به مسیر موردنیاز محدود کنید تا نفوذ به یک سرور، تمام فایل‌سیستم را در معرض دسترسی قرار ندهد.

آزمون عملکرد و پایش

آزمون با dd فقط تصویری ابتدایی از سرعت ترتیبی می‌دهد:

dd if=/dev/zero of=/mnt/sharedfs/test.bin bs=1M count=1024 conv=fdatasync

برای ارزیابی دقیق‌تر از fio با الگوی نزدیک به بار واقعی استفاده کنید. نتیجه CephFS به سرعت شبکه، تعداد و نوع OSDها، replication، اندازه فایل‌ها، الگوی I/O و بار متادیتا وابسته است. فرمان‌های زیر برای بررسی روزمره مفیدند:

ceph fs status sharedfs
ceph health detail
ceph osd df
ceph mds stat

ظرفیت آزاد را پیش از رسیدن کلاستر به آستانه‌های nearfull و full افزایش دهید. پرشدن Ceph فقط CephFS را تحت تأثیر قرار نمی‌دهد و می‌تواند سایر poolهای همان کلاستر را نیز مختل کند. برای دسترس‌پذیری بهتر، MONها، MDSهای فعال و standby و OSDها را روی میزبان‌های متفاوت پخش کنید. نسخه پشتیبان را هم حذف نکنید: replication در Ceph از خرابی دیسک محافظت می‌کند، اما جای نسخه پشتیبان مستقل در برابر حذف اشتباه، باج‌افزار یا خطای نرم‌افزاری را نمی‌گیرد. برای این کار می‌توانید از پشتیبان‌گیری خودکار و رمزنگاری‌شده از سرور لینوکس با Restic استفاده کنید.

زیرساخت مناسب برای کلاینت‌های CephFS

کیفیت شبکه بین کلاینت و کلاستر روی تأخیر و سرعت CephFS اثر مستقیم دارد. برای بارهای پرترافیک، سرورهای متصل به شبکه خصوصی و پایدار معمولاً نتیجه بهتری از کلاینت‌هایی می‌دهند که از مسیر عمومی یا تونل‌های پرنوسان به کلاستر وصل شده‌اند. تنظیمات شبکه سمت کلاینت هم روی نتیجه اثر دارد؛ بهینه‌سازی شبکه سرور لینوکس با TCP BBR و sysctl نمونه‌ای از این تنظیمات است. اگر برای نودهای ذخیره‌سازی یا کلاینت‌های پرمصرف به منابع فیزیکی و شبکه اختصاصی نیاز دارید، مشخصات سرور اختصاصی آریاسرویس را بررسی کنید. برای کلاینت‌های سبک‌تر، نودهای مدیریتی یا سرویس‌هایی با مصرف متغیر نیز سرور ابری می‌تواند گزینه مناسب‌تری باشد.

جمع‌بندی

راه‌اندازی CephFS روی یک کلاستر موجود شامل ایجاد poolهای داده و متادیتا، ساخت فایل‌سیستم، استقرار MDS و تعریف دسترسی محدود برای کلاینت‌ها است. پس از آن، سرورهای اختصاصی و VPSها می‌توانند با kernel client یا ceph-fuse به فضای مشترک وصل شوند. kernel client برای بیشتر محیط‌های عملیاتی انتخاب مناسب‌تری است و ceph-fuse در سناریوهای سازگاری یا آزمایش کاربرد دارد. پیش از استفاده در محیط تولید، افزونگی MDS، هماهنگی UID و GID، محدودیت‌های CephX، سلامت کلاستر، ظرفیت آزاد و برنامه پشتیبان‌گیری را بررسی کنید. CephFS زمانی بیشترین فایده را دارد که زیرساخت Ceph از قبل درست طراحی شده باشد و چند سرور واقعاً به دسترسی هم‌زمان و مقیاس‌پذیر به فایل‌ها نیاز داشته باشند.