بخش تخصصی (۴): ‏RBD‏ — چیدمان روی ‏RADOS‏، ‏striping‏، ‏object map‏ و ‏fast-diff‏، و مرجع ‏rbd‏

۳۷-۱ پیش از شروع#

فصل ۲ نشان داد یک ‏image‏ قالب ۲ چه اشیایی دارد و شناسه‌ی آن چگونه ساخته می‌شود (الگوریتم ۲-۱). این فصل همان چیدمان را کلید به کلید باز می‌کند: ‏header‏ یک ‏image‏ دقیقاً چه کلیدهای ‏omap‏ دارد، اشیای سطح ‏pool‏ (‏rbd_directory‏، ‏rbd_trash‏، ‏rbd_mirroring‏، ‏rbd_namespace‏ و دیگران) چه چیزی نگه می‌دارند، ‏striping‏ با ‏stripe_unit‏ و ‏stripe_count‏ آفست را چگونه به شیء می‌برد، ‏object map‏ بیت‌ها را چگونه بسته‌بندی و ذخیره می‌کند، و ‏fast-diff‏ چگونه بدون خواندن داده تغییرات میان دو ‏snapshot‏ را می‌یابد. فصل با مرجع کامل دستور ‏rbd‏ و ‏rbd-nbd‏ تمام می‌شود. نام‌ها با شاخه‌ی ‏main‏ مخزن ‏ceph/ceph‏ (نوامبر ۲۰۲۶) تطبیق داده شده‌اند.

۳۷-۱-۱ این فصل به چه سؤال‌هایی جواب می‌دهد؟#

• ‏header‏ یک ‏image‏ چه کلیدهایی دارد و هر کدام چه کسی آن را می‌نویسد؟
• نام شیء داده با ‏data pool‏ جدا چه فرقی می‌کند؟
• با ‏stripe_unit=64K‏ و ‏stripe_count=4‏، آفست ۱۰۰۰۰۰۰ در کدام شیء است؟
• ‏object map‏ هر شیء را با چند بیت نگه می‌دارد و بایت‌ها روی دیسک چه ترتیبی دارند؟
• ‏EXISTS_CLEAN‏ چه معنایی دارد و چه زمانی تنظیم می‌شود؟
• ‏fast-diff‏ از کدام حالت‌ها برای تشخیص تغییر استفاده می‌کند؟
• ‏pool‏ و ‏namespace‏ و ‏trash‏ و گروه‌ها در ‏RADOS‏ چگونه نمایه می‌شوند؟

۳۷-۱-۲ پیش‌نیاز#

فصل ۲ (‏RBD‏)، فصل ۱۵ (‏cls‏)، فصل ۳۴ و ۳۶ (‏omap‏، ‏SnapContext‏ و ‏clone‏).

۳۷-۲ اشیای یک ‏image‏#

۳۷-۲-۱ ‏header‏#

همه‌ی فراداده‌ی یک ‏image‏ قالب ۲ در ‏omap‏ شیء ‏rbd_header.<id>‏ است و فقط از طریق متدهای کلاس ‏rbd‏ (‏src/cls/rbd/cls_rbd.cc‏) تغییر می‌کند:

افزون بر ‏omap‏، ‏xattr‏ ‏‏lock.rbd_lock‏ (کلاس ‏lock‏) قفل مشورتی را نگه می‌دارد که ‏ManagedLock‏ برای ‏exclusive-lock‏ از آن استفاده می‌کند (فصل ۳۸). همین شیء ‏header‏ هدف ‏watch‏ همه‌ی کلاینت‌های باز آن ‏image‏ است.

مجموع پیش‌فرض (‏rbd_default_features‏) برابر ۱+۴+۸+۱۶+۳۲ = ۶۱ است.

۳۷-۲-۲ اشیای داده و ‏object map‏#

اشیای داده ‏<object_prefix>.<objectno:016x>‏ نام دارند. اگر ‏image‏ با ‏--data-pool‏ ساخته شود، ‏header‏ و فراداده در ‏pool‏ اصلی می‌مانند (که باید ‏replicated‏ باشد) و داده در ‏pool‏ دوم (اغلب ‏EC‏ با ‏allow_ec_overwrites‏) نوشته می‌شود. در این حالت پیشوند شامل شناسه‌ی ‏pool‏ اصلی است: ‏rbd_data.<metadata-pool-id>.<image-id>‏، تا اشیای ‏image‏های چند ‏pool‏ مختلف در یک ‏data pool‏ مشترک با هم برخورد نکنند.

‏object map‏ در شیء ‏rbd_object_map.<id>‏ برای ‏head‏ و ‏rbd_object_map.<id>.<snapid:016x>‏ برای هر ‏snapshot‏ ذخیره می‌شود.

۳۷-۲-۳ اشیای سطح ‏pool‏#

‏namespace‏ در ‏RBD‏ همان ‏namespace‏ در ‏RADOS‏ است (فصل ۳۴). همه‌ی اشیای فهرست‌شده در بالا جداگانه در هر ‏namespace‏ ساخته می‌شوند. با ‏cap‏ ‏‏profile rbd pool=P namespace=N‏ می‌توان یک کلاینت را به یک ‏namespace‏ محدود کرد، بی‌آنکه برای هر مستاجر ‏pool‏ جدا ساخت.

# مثال: خواندن مستقیم header (فقط برای بررسی؛ هرگز با rados تغییرش ندهید)
rados -p rbd listomapkeys rbd_header.5f3a2b8c1d4e
rados -p rbd getomapval rbd_header.5f3a2b8c1d4e object_prefix

مثال (خروجی):
access_timestamp
create_timestamp
features
flags
modify_timestamp
object_prefix
order
size
snap_seq
snapshot_0000000000000004
value (25 bytes) :
00000000  15 00 00 00 72 62 64 5f  64 61 74 61 2e 35 66 33  |....rbd_data.5f3|
00000010  61 32 62 38 63 31 64 34  65                       |a2b8c1d4e|

چهار بایت اول (‏15 00 00 00‏ یعنی ۲۱) طول رشته به‌صورت ‏little-endian‏ است؛ همه‌ی رشته‌ها در کدگذاری ‏Ceph‏ همین قالب را دارند.

۳۷-۳ ‏striping‏#

به‌طور پیش‌فرض ‏stripe_unit‏ برابر اندازه‌ی شیء و ‏stripe_count‏ برابر ۱ است، پس ‏image‏ به‌سادگی به قطعه‌های پشت‌سرهم ۴ ‏MiB‏ تقسیم می‌شود. با ‏striping‏ سفارشی، داده به‌صورت ‏round-robin‏ میان ‏stripe_count‏ شیء پخش می‌شود تا نوشتن‌های ترتیبی کوچک هم‌زمان به چند ‏OSD‏ بروند.

pseudocode
su = stripe_unit ; sc = stripe_count ; os = object_size
if sc == 1: su = os
stripes_per_object = os / su
while left > 0:
    blockno     = cur / su
    stripeno    = blockno / sc
    stripepos   = blockno % sc
    objectsetno = stripeno / stripes_per_object
    objectno    = objectsetno * sc + stripepos
    x_offset    = (stripeno % stripes_per_object) * su + cur % su
    x_len       = min(su - cur % su, left)
    emit (objectno, x_offset, x_len) ; cur += x_len ; left -= x_len

مثال عددی. ‏object_size = 4 MiB‏، ‏stripe_unit = 64 KiB‏، ‏stripe_count = 4‏، نوشتن ۳۰۰۰۰۰ بایت از آفست ۱۰۰۰۰۰۰. هر شیء ۶۴ ‏stripe‏ دارد و یک «‏object set‏» از ۴ شیء ۱۶ ‏MiB‏ را می‌پوشاند.

نوشتن ۳۰۰ ‏KB‏ به هر چهار شیء می‌رسد. با ‏striping‏ پیش‌فرض همین نوشتن فقط شیء ۰ را (آفست ۱۰۰۰۰۰۰ تا ۱۳۰۰۰۰۰) لمس می‌کرد. ‏striping‏ برای بار ترتیبی تک‌جریانی با عمق صف کم سودمند است، ولی برای بار تصادفی ۴‏K‏ فقط تعداد اشیای درگیر را زیاد می‌کند. ‏krbd‏ از نسخه‌ی ۴.۱۷ هسته ‏striping‏ سفارشی را پشتیبانی می‌کند (فصل ۲۹).

rbd create pool/img --size 10G --object-size ۴M --stripe-unit 64K --stripe-count 4

۳۷-۴ ‏object map‏#

۳۷-۴-۱ حالت‌ها و بسته‌بندی بیت#

‏object map‏ برای هر شیء ۲ بیت دارد (‏BitVector<2>‏):

هر بایت چهار شیء را نگه می‌دارد و شیء با شماره‌ی کوچک‌تر در بیت‌های بالاتر است: ‏shift = (3 − objectno % 4) × 2‏. کدگذاری روی دیسک سه بخش دارد: ‏header‏ (طول، نسخه و تعداد عناصر)، داده‌ی خام، و ‏footer‏ شامل ‏crc32c‏ ‏‏header‏ و یک ‏crc32c‏ برای هر بلوک ۴۰۹۶ بایتی داده. پس به‌روزرسانی یک شیء فقط یک بلوک ۴ ‏KiB‏ و ‏crc‏ آن را بازنویسی می‌کند (متد ‏object_map_update‏ در ‏cls_rbd‏).

۳۷-۴-۲ چه کسی حالت را عوض می‌کند؟#

• نوشتن روی شیئی که ‏NONEXISTENT‏ یا ‏EXISTS_CLEAN‏ است، پیش از ارسال نوشتن، ‏object map‏ را به ‏EXISTS‏ به‌روز می‌کند (اول در حافظه، سپس با ‏object_map_update‏ روی ‏RADOS‏). اگر شیء از قبل ‏EXISTS‏ باشد، هیچ هزینه‌ای ندارد.
• ‏discard‏ یا حذف ابتدا حالت را ‏PENDING‏ می‌کند، شیء را حذف می‌کند و سپس ‏NONEXISTENT‏.
• گرفتن ‏snapshot‏ نقشه‌ی ‏head‏ را در ‏rbd_object_map.<id>.<snapid>‏ کپی و سپس همه‌ی ‏EXISTS‏های ‏head‏ را به ‏EXISTS_CLEAN‏ تبدیل می‌کند (‏object_map_snap_add‏ در ‏cls_rbd‏).
• حذف ‏snapshot‏ بیت‌های ‏EXISTS‏ نقشه‌ی آن ‏snapshot‏ را با نقشه‌ی ‏snapshot‏ بعدی (یا ‏head‏) ادغام می‌کند تا اطلاعات «تغییر کرده» از دست نرود (‏object_map_snap_remove‏).

‏object map‏ فقط با ‏exclusive-lock‏ معتبر است، چون فقط مالک قفل حق تغییر آن را دارد. اگر کلاینت در میانه‌ی به‌روزرسانی از کار بیفتد، پرچم ‏OBJECT_MAP_INVALID‏ در ‏flags‏ می‌نشیند و ‏rbd object-map rebuild‏ باید اجرا شود.

۳۷-۴-۳ ‏fast-diff‏#

pseudocode
# برای هر snapshot از from_snap تا end_snap (و head)، نقشه‌ی آن بارگذاری و با وضعیت قبلی ترکیب می‌شود
first map (from_snap):  state[o] = HOLE if NONEXISTENT else DATA (PENDING → DATA_UPDATED)
each later map m:
    HOLE:         if m[o] != NONEXISTENT → DATA_UPDATED     (diff-iterate: فقط در نقشه‌ی پایانی)
    DATA:         if m[o] == NONEXISTENT → HOLE_UPDATED
                  elif m[o] != EXISTS_CLEAN → DATA_UPDATED
    HOLE_UPDATED: if m[o] != NONEXISTENT → DATA_UPDATED
    DATA_UPDATED: if m[o] == NONEXISTENT → HOLE_UPDATED
objects beyond the previous size (image grew) → HOLE or DATA_UPDATED

نکته‌ی کلیدی ‏EXISTS_CLEAN‏ است: اگر شیئی در ‏from_snap‏ وجود داشته و در همه‌ی نقشه‌های بعدی ‏EXISTS_CLEAN‏ مانده، یعنی پس از ‏from_snap‏ نوشتنی نداشته است و در ‏diff‏ نمی‌آید. ‏rbd diff --whole-object‏، ‏rbd du‏ و ‏rbd export-diff‏ (و حالت ‏snapshot‏ در ‏rbd-mirror‏) همه از همین محاسبه استفاده می‌کنند. اگر ‏FAST_DIFF_INVALID‏ روشن باشد، ‏librbd‏ به ‏list_snaps‏ روی تک‌تک اشیا برمی‌گردد که بسیار کندتر است.

مثال عددی. ‏image‏ ‏۱۰ ‏GiB‏ با ۲۵۶۰ شیء. پس از ‏snap1‏، بیست شیء نوشته شده و سه شیء ‏discard‏ شده است. با ‏fast-diff‏، ‏rbd export-diff --from-snap snap1‏ فقط دو نقشه‌ی ۶۴۰ بایتی (و ‏header‏ و ‏footer‏) می‌خواند و ۲۳ شیء را پیدا می‌کند. بدون آن، ۲۵۶۰ فراخوانی ‏list_snaps‏ لازم بود.

۳۷-۵ مرجع ‏rbd‏#

۳۷-۵-۱ ‏image‏ و ‏snapshot‏#

۳۷-۵-۲ ‏map‏ کردن#

# مثال: ساخت image با striping و data pool، و بررسی آن
rbd create rbd/vm01 --size 10G --stripe-unit 64K --stripe-count 4 --data-pool rbd-ec
rbd info rbd/vm01

مثال (خروجی):
rbd image 'vm01':
	size 10 GiB in 2560 objects
	order 22 (4 MiB objects)
	snapshot_count: 0
	id: 5f3a2b8c1d4e
	data_pool: rbd-ec
	block_name_prefix: rbd_data.3.5f3a2b8c1d4e
	format: 2
	features: layering, striping, exclusive-lock, object-map, fast-diff, deep-flatten, data-pool
	op_features:
	flags:
	create_timestamp: Sun Nov 15 09:41:07 2026
	access_timestamp: Sun Nov 15 09:41:07 2026
	modify_timestamp: Sun Nov 15 09:41:07 2026
	stripe unit: 64 KiB
	stripe count: 4

‏block_name_prefix‏ همان ‏object_prefix‏ است و عدد ۳ در آن شناسه‌ی ‏pool‏ ‏‏rbd‏ است، چون ‏data pool‏ جدا داریم.

۳۷-۶ تنظیم و عیب‌یابی#

• کندی نخستین نوشتن روی ‏image‏ تازه: هر نخستین نوشتن روی یک شیء یک ‏object_map_update‏ هم دارد. پس از پر شدن ‏image‏ این هزینه از بین می‌رود. برای آزمون کارایی، ‏image‏ را اول پر کنید.
• ‏rbd du‏ یا ‏export-diff‏ کند است: ‏rbd info‏ را ببینید؛ اگر ‏flags: object map invalid, fast diff invalid‏ است، ‏rbd object-map rebuild‏ اجرا کنید (روی ‏snapshot‏ها هم جداگانه).
• ‏image‏ با ‏--data-pool‏ روی ‏EC‏ ساخته نمی‌شود: ‏allow_ec_overwrites‏ روی ‏pool‏ ‏‏EC‏ و اجرای ‏rbd pool init‏ روی هر دو ‏pool‏ را بررسی کنید.
• حذف ‏image‏ بزرگ کند است: حذف به تعداد اشیای موجود وابسته است؛ با ‏object map‏ فقط اشیای موجود حذف می‌شوند. برای کارهای بلند از ‏rbd trash mv‏ و سپس ‏rbd trash rm‏ یا ‏ceph rbd task add remove‏ استفاده کنید.
• هرگز ‏header‏ را با ‏rados setomapval‏ تغییر ندهید: ‏cls_rbd‏ ناسازگاری‌ها را بررسی می‌کند ولی کلاینت‌های باز از تغییر خبر نمی‌گیرند (هیچ ‏notify‏ فرستاده نمی‌شود).

۳۷-۷ تکمیلی و به‌روز#

• ‏clone‏ قالب ۲ (پیش‌فرض ‏rbd_default_clone_format: auto‏، که اگر همه‌ی کلاینت‌ها ‏Mimic‏ یا جدیدتر باشند قالب ۲ را برمی‌گزیند) به ‏protect‏ نیازی ندارد و فرزندان را در ‏snap_children_*‏ همان ‏header‏ والد نگه می‌دارد.
• مقدار ‏op_features‏ در نسخه‌های جدید بیت‌هایی برای ‏snapshot‏ در ‏trash‏ و گروه‌ها دارد؛ کلاینت قدیمی که ‏op_feature‏ ناشناخته ببیند، ‏image‏ را باز نمی‌کند.
• در شاخه‌ی ‏main‏، ‏rbd-nbd‏ با ‏netlink‏ و ‏--try-netlink‏ پایدارتر از روش ‏ioctl‏ است؛ پشتیبانی از ‏ubbd‏ به بسته‌بندی توزیع وابسته است.

۳۷-۸ تمرین عملی#

1. ۱. یک ‏image‏ بسازید و با ‏rados listomapkeys‏ و ‏getomapval‏ همه‌ی کلیدهای ‏header‏ را بخوانید. سپس یک ‏snapshot‏ بگیرید و کلید تازه را پیدا کنید.
2. ۲. یک ‏image‏ با ‏--stripe-unit 64K --stripe-count 4‏ بسازید، ۳۰۰۰۰۰ بایت در آفست ۱۰۰۰۰۰۰ بنویسید (‏rbd bench‏ یا ‏dd‏ روی ‏rbd-nbd‏) و با ‏rados ls | grep‏ ببینید کدام اشیا ساخته شدند. با جدول مثال مقایسه کنید.
3. ۳. ‏rados get rbd_object_map.<id> /tmp/om‏ بگیرید و با ‏xxd‏ چهار بایت اول داده (پس از ‏header‏ هجده‌بایتی) را با حالت اشیای ۰ تا ۱۵ تطبیق دهید.
4. ۴. پس از یک ‏snapshot‏، چند شیء بنویسید و ‏rbd diff --from-snap‏ را با و بدون ‏fast-diff‏ (پس از ‏rbd feature disable ... fast-diff‏) زمان‌گیری کنید.

۳۷-۹ پرسش‌های مرور#

1. ۱. کدام کلیدهای ‏header‏ برای ساختن نام اشیای داده لازم‌اند؟
2. ۲. با ‏data pool‏ جدا، نام اشیای داده چه تغییری می‌کند و چرا؟
3. ۳. ‏rbd_directory‏ چه دو نوع کلیدی دارد؟
4. ۴. در مثال ‏striping‏، بایت آفست ۱۱۰۰۰۰۰ در کدام شیء و کدام آفست است؟
5. ۵. ‏object map‏ هر شیء را با چند بیت نگه می‌دارد و شیء ۰ در کدام بیت‌های بایت اول است؟
6. ۶. چرا ‏footer object map‏ برای هر بلوک ۴ ‏KiB‏ یک ‏crc‏ جدا دارد؟
7. ۷. ‏EXISTS_CLEAN‏ چه زمانی تنظیم و چه زمانی پاک می‌شود؟
8. ۸. در ‏fast-diff‏ اگر شیء در ‏from_snap‏ ‏‏DATA‏ و در ‏head‏ ‏‏EXISTS‏ باشد، نتیجه چیست؟
9. ۹. چرا ‏object map‏ به ‏exclusive-lock‏ وابسته است؟
10. ۱۰. ‏namespace‏ در ‏RBD‏ چگونه پیاده شده و چه مزیتی دارد؟

پاسخ این پرسش‌ها در پیوست ه: پاسخ پرسش‌ها آمده است. پاسخ پرسش‌های این فصل →

۳۷-۱۰ منابع این فصل#

• ‏cls_rbd.cc‏
  https://github.com/ceph/ceph/blob/main/src/cls/rbd/cls_rbd.cc
• ‏rbd_types.h‏ و ‏features.h‏
  https://github.com/ceph/ceph/blob/main/src/include/rbd/features.h
• ‏Striper.cc‏
  https://github.com/ceph/ceph/blob/main/src/osdc/Striper.cc
• ‏bit_vector.hpp‏
  https://github.com/ceph/ceph/blob/main/src/common/bit_vector.hpp
• ‏librbd/object_map/DiffRequest.cc‏
  https://github.com/ceph/ceph/blob/main/src/librbd/object_map/DiffRequest.cc
• مستند ‏RBD layering‏ و ‏striping‏
  https://docs.ceph.com/en/latest/dev/rbd-layering/
• مرجع دستور ‏rbd‏
  https://docs.ceph.com/en/latest/man/8/rbd/
• مرجع ‏rbd-nbd‏
  https://docs.ceph.com/en/latest/man/8/rbd-nbd/