تنظیم کارایی ‏Ceph‏: از ‏mClock‏ تا هسته و شبکه

۲۱-۱ پیش از شروع#

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

تنظیم کارایی در ‏Ceph‏ بیش از هر چیز یک روش است: هدف را تعریف کنید، خط پایه بگیرید، یک تغییر بدهید و دوباره بسنجید. بسیاری از «توصیه‌های تنظیم» رایج در اینترنت مربوط به ‏FileStore‏، ‏WPQ‏ یا نسخه‌های پیش از ‏Quincy‏ هستند و امروز یا بی‌اثرند یا آسیب می‌زنند. این فصل بر سازوکارهای امروزی تمرکز دارد:

• لایه‌های کارایی کدام‌اند و از کجا شروع کنیم؟
• ‏OSD‏ چگونه درخواست‌ها را بین شاردها و ‏thread‏ها پخش می‌کند؟
• زمان‌بند ‏mClock‏ با چه الگوریتمی بین کلاینت و بازیابی تعادل برقرار می‌کند و پروفایل‌ها چه می‌کنند؟
• حافظه‌ی ‏OSD‏ و کش ‏BlueStore‏ را چگونه تنظیم کنیم؟
• تنظیمات سیستم‌عامل، شبکه و ‏CPU‏ کدام‌اند؟
• چگونه با ‏fio‏، ‏rados bench‏ و ‏CBT‏ اندازه بگیریم؟

۲۱-۲ روش و لایه‌ها#

۲۱-۳ از درون کد: شاردها و ‏thread‏ها#

۲۱-۳-۱ مسیر درخواست در ‏OSD‏#

‏OSD‏ درخواست‌ها را بین چند شارد (‏struct OSDShard‏ در ‏src/osd/OSD.h‏) پخش می‌کند. شارد هر ‏PG‏ با ‏pgid.hash_to_shard(num_shards)‏ تعیین می‌شود؛ بنابراین همه‌ی عملیات یک ‏PG‏ همیشه در یک شارد پردازش می‌شوند و ترتیب حفظ می‌شود. هر شارد صف زمان‌بندی خود و چند ‏thread‏ دارد.

۲۱-۴ از درون کد: ‏mClock‏#

۲۱-۴-۱ الگوریتم ‏dmClock‏#

از ‏Quincy‏، زمان‌بند پیش‌فرض ‏OSD‏ ‏mclock_scheduler‏ است (‏osd_op_queue‏). این زمان‌بند بر پایه‌ی کتابخانه‌ی ‏dmclock‏ (‏src/dmclock/‏) است که الگوریتم ‏mClock‏ را پیاده می‌کند. هر کلاس سرویس سه پارامتر دارد:

• ‏reservation‏: حداقل سهم تضمین‌شده (‏IOPS‏)،
• ‏weight‏: سهم نسبی از ظرفیت اضافه،
• ‏limit‏: سقف سهم.

هر درخواست سه برچسب زمانی (‏R‏، ‏P‏، ‏L‏) می‌گیرد. محاسبه‌ی برچسب در ‏dmclock‏:

// from ceph/ceph, LGPL — src/dmclock/src/dmclock_server.h, RequestTag::tag_calc (excerpt)
if (0.0 == increment) {
  return extreme_is_high ? max_tag : min_tag;
} else {
  double tag_increment = increment * (uint64_t(dist_req_val) + cost);
  return std::max(time, prev + tag_increment);
}

‏increment‏ معکوس پارامتر است (۱/‏reservation‏، ۱/‏weight‏ یا ۱/‏limit‏) و ‏cost‏ هزینه‌ی درخواست. بنابراین کلاسی با ‏reservation‏ بزرگ‌تر، برچسب‌های ‏R‏ نزدیک‌تر به هم می‌گیرد و درخواست‌هایش زودتر «سررسید» می‌شوند. ‏max(time, ...)‏ تضمین می‌کند کلاسی که مدتی بی‌کار بوده، با برچسب‌های قدیمی «اعتبار انباشته» نداشته باشد.

pseudocode: انتخاب درخواست بعدی (خلاصه‌ی این کتاب از dmclock)
  now = clock()
  r = queue.min_by(R)
  if r.R <= now:            return r            # مرحله‌ی رزرو: تضمین حداقل‌ها
  eligible = [q for q in queue if q.L <= now]   # از سقف عبور نکرده‌اند
  if eligible:              return eligible.min_by(P)   # تقسیم ظرفیت اضافه بر اساس وزن
  return none               # همه به سقف رسیده‌اند → صبر تا سررسید

۲۱-۴-۲ پروفایل‌ها#

پروفایل ‏mClock‏ پارامترهای سه کلاس (‏client‏، ‏background recovery‏، ‏background best-effort‏) را به‌صورت درصدی از ظرفیت ‏OSD‏ تنظیم می‌کند. مقادیر زیر از صفحه‌ی ‏mClock Config Reference‏ مستندات ‏latest‏ است:

ceph config get osd osd_mclock_profile
ceph config set osd osd_mclock_profile high_client_ops      # ساعات اوج
ceph config set osd osd_mclock_profile high_recovery_ops    # بازیابی سریع در شب
ceph config show osd.0 | grep -E "osd_mclock_max_capacity_iops|osd_mclock_scheduler"

۲۱-۵ حافظه‌ی ‏OSD‏#

‏osd_memory_target‏ (پیش‌فرض ۴ گیگابایت) هدف مصرف حافظه‌ی هر ‏OSD‏ است و ‏BlueStore‏ با ‏bluestore_cache_autotune‏ (پیش‌فرض ‏true‏) کش‌های ‏onode‏، داده و ‏RocksDB‏ را درون این بودجه تنظیم می‌کند (فصل ۱۲). در ‏cephadm‏، طبق مستندات ‏OSD‏، ‏osd_memory_target_autotune‏ به‌طور پیش‌فرض برای ‏OSD‏های جدید فعال می‌شود و ‏cephadm‏ هدف هر ‏OSD‏ را از حافظه‌ی میزبان ضرب در ‏mgr/cephadm/autotune_memory_target_ratio‏ (پیش‌فرض ۰.۷ در کد ‏cephadm‏)، منهای حافظه‌ی سایر ‏daemon‏ها، تقسیم بر تعداد ‏OSD‏ها تعیین می‌کند.

ceph config get osd osd_memory_target
ceph orch host ls --detail                     # حافظه‌ی میزبان‌ها
ceph config set osd/host:stor-a1 osd_memory_target 8G
ceph daemon osd.3 dump_mempools | jq '.mempool.by_pool | to_entries | sort_by(-.value.bytes) | .[0:5]'

۲۱-۶ لایه‌ی پایین‌تر: حلقه‌ی کنترل حافظه و ‏throttle‏ در ‏BlueStore‏#

دو حلقه‌ی کنترل کمتر دیده‌شده بخش بزرگی از رفتار کارایی یک ‏OSD‏ را تعیین می‌کنند. اولی حافظه‌ی ‏cache‏ها را با مصرف واقعی ‏heap‏ تطبیق می‌دهد. دومی تعیین می‌کند چند تراکنش هم‌زمان می‌تواند وارد ‏BlueStore‏ شود. هر دو در کد چند خط ساده‌اند، ولی اثرشان در سطح خوشه بزرگ است.

۲۱-۶-۱ ‏osd_memory_target‏ چگونه اعمال می‌شود؟#

‏osd_memory_target‏ سقف سخت نیست، هدف یک حلقه‌ی کنترل است. ‏thread‏ حافظه‌ی ‏BlueStore‏ (‏MempoolThread‏) ابتدا مرزهای بودجه‌ی ‏cache‏ را حساب می‌کند (در ‏BlueStore.cc‏) و سپس ‏PriorityCache::Manager::tune_memory‏ در هر دور بودجه را به سمت هدف هل می‌دهد.

pseudocode: مرزها و یک گام tune_memory (بازنویسی این کتاب)
  ltarget = (1 - expected_fragmentation) * target
  min     = cache_min
  max     = ltarget - base     if ltarget > base + min   else min
  new     = clamp(tuned, min, max)
  if mapped < target:  new += (1 - mapped/target) * (max - new)   # رشد، کندتر وقتی به هدف نزدیک است
  else:                new -= (1 - target/mapped) * (new - min)   # کوچک شدن متناسب با بیش‌مصرف
  tuned = new

مثال عددی با پیش‌فرض‌ها#

با ‏osd_memory_target=4G‏، ‏osd_memory_base=768M‏، ‏osd_memory_cache_min=128M‏ و ‏osd_memory_expected_fragmentation=0.15‏:

از این مثال سه نتیجه‌ی عملی گرفته می‌شود:

1. ۱. ‏cache‏ هرگز تمام ‏target‏ را نمی‌گیرد. حتی در بهترین حالت، حدود ۲.۷ ‏GiB‏ از ۴ ‏GiB‏ به ‏cache‏ می‌رسد. بقیه سهم ‏base‏ (حافظه‌ی غیر ‏cache‏ مثل ‏pg log‏، اتصال‌ها و ‏buffer‏ها) و حاشیه‌ی ‏fragmentation‏ است.
2. ۲. واکنش به بیش‌مصرف تدریجی است. با ۱۰٪ بیش‌مصرف، بودجه فقط حدود ۹٪ از فاصله‌ی تا ‏min‏ کم می‌شود. اگر چیزی بیرون از ‏cache‏ (مثلاً ‏pg log‏ بسیار بلند در ‏backfill‏) رشد کند، ‏RSS‏ می‌تواند مدتی از ‏target‏ بالاتر بماند. برای جلوگیری از ‏OOM‏، حاشیه‌ی حافظه‌ی میزبان را بر این اساس برنامه‌ریزی کنید.
3. ۳. ‏mapped‏ از ‏tcmalloc‏ خوانده می‌شود. اگر ‏OSD‏ با ‏allocator‏ دیگری ساخته شده باشد، این حلقه عملاً کار نمی‌کند و مقدار ‏cache‏ ثابت ‏bluestore_cache_size_hdd/ssd‏ (به‌ترتیب ۱‏G‏ و ۳‏G‏) معنا پیدا می‌کند.

۲۱-۶-۲ ‏throttle‏ در ورودی ‏BlueStore‏#

هر تراکنش (‏TransContext‏) پیش از ورود به ‏BlueStore‏ از ‏throttle_bytes‏ با سقف ‏bluestore_throttle_bytes=64M‏ «هزینه» برمی‌دارد. هزینه فقط حجم داده نیست. ‏_txc_calc_cost‏ هزینه را این‌گونه حساب می‌کند:

ios  = 1 + (تعداد aioهای داده)        # یکی برای کامیت kv
cost = ios × throttle_cost_per_io + bytes

مقدار ‏throttle_cost_per_io‏ برای ‏HDD‏ برابر ۶۷۰۰۰۰ و برای ‏SSD‏ برابر ۴۰۰۰ است، مگر اینکه ‏bluestore_throttle_cost_per_io‏ صریحاً تنظیم شده باشد. این عدد در واقع «معادل بایتی» هزینه‌ی یک ‏seek‏ است.

۲۱-۶-۳ ‏Messenger‏ و ‏thread‏#

در هر ‏daemon‏، ‏ms_async_op_threads=3‏ ‏thread‏ اجرای رویداد (‏epoll‏) برای همه‌ی اتصال‌ها کار می‌کنند. هر اتصال به یکی از آن‌ها چسبیده است. روی یک ‏OSD NVMe‏ با صدها کلاینت، این سه ‏thread‏ می‌توانند پیش از دیسک اشباع شوند. نشانه‌اش این است که در ‏top -H‏ سه ‏thread‏ با نام ‏msgr-worker-N‏ نزدیک ۱۰۰٪ ‏CPU‏ کار می‌کنند. ‏ms_tcp_nodelay=true‏ (خاموش کردن ‏Nagle‏) برای پیام‌های کوچک لازم است. ‏ms_tcp_rcvbuf=0‏ یعنی اندازه‌ی بافر دریافت به ‏autotuning‏ هسته سپرده می‌شود (‏net.ipv4.tcp_rmem‏)، که معمولاً بهتر از هر عدد ثابت است.

ceph daemon osd.3 perf dump | jq '.prioritycache'                 # target/mapped/heap
ceph daemon osd.3 dump_mempools | jq '.mempool.total'
ceph daemon osd.3 perf dump | jq '.bluestore | {kv_flush_lat, kv_commit_lat, kv_sync_lat, state_kv_queued_lat}'
ceph config show osd.3 bluestore_throttle_cost_per_io             # 0 ⇒ مقدار hdd/ssd استفاده می‌شود
top -H -p $(pgrep -f 'ceph-osd.*--id 3') -b -n1 | grep msgr-worker

۲۱-۷ تنظیم کارایی با عدد: شارد، حافظه، مسیر نوشتن و ‏dmClock‏#

بخش‌های قبل این فصل گفتند هر لایه‌ی ‏OSD‏ چه پارامتری دارد. این بخش نشان می‌دهد چهار تصمیم مهم با عدد چگونه گرفته می‌شوند: کدام شارد صف یک ‏PG‏ را نگه می‌دارد، ‏cephadm‏ به هر ‏OSD‏ چقدر حافظه می‌دهد، ‏BlueStore‏ کدام نوشتن را ‏deferred‏ می‌کند و ‏dmClock‏ در هر لحظه کدام درخواست را جلو می‌اندازد. همه‌ی ارجاع‌ها به ‏main‏ در نوامبر ۲۰۲۶ است. پیش‌فرض‌های ‏mClock‏ و شاردها در ‏Reef‏ و ‏Squid‏ تغییر کرده‌اند، پس ‏ceph config show osd.N‏ روی کلاستر خودتان معیار نهایی است. عددها با بازپیاده‌سازی پایتونی حساب شده‌اند.

۲۱-۷-۱ نگاشت ‏PG‏ به شارد صف#

pseudocode
num_shards = osd_op_num_shards  اگر ≠ 0  وگرنه (rotational ? osd_op_num_shards_hdd = 1 : osd_op_num_shards_ssd = 8)
threads_per_shard = osd_op_num_threads_per_shard  یا  (hdd: 5 ، ssd: 2)
shard(item) = item.ordering_token.pgid.ps() mod num_shards      # همه‌ی درخواست‌های یک PG در یک شارد
هر شارد: یک صف mClock جدا و threads_per_shard thread

نتیجه‌ی مستقیم: یک ‏PG‏ هرگز از بیش از یک شارد سرویس نمی‌گیرد. روی ‏SSD‏ با پیش‌فرض ۸ × ۲، یک ‏PG‏ بسیار داغ (مثلاً شیء سرصفحه‌ی یک ‏bucket‏ یا یک ‏image‏ با بار سنگین روی چند شیء کم) حداکثر ۲ ‏thread‏ از ۱۶ ‏thread‏ را مشغول می‌کند. توزیع ‏PG‏ها میان شاردها هم یکنواخت نیست. شبیه‌سازی یک ‏OSD‏ با ۱۰۰ ‏PG‏ که شماره‌ی ‏ps‏ آن‌ها تصادفی از ‏pg_num‏ ‏۴۰۹۶ انتخاب شده، تعداد ‏PG‏ هر شارد را ۹، ۹، ۱۶، ۱۷، ۹، ۱۲، ۱۰ و ۱۸ داد. میانگین ۱۲.۵ است، اما پرترین شارد ۴۴ درصد بیشتر از میانگین بار دارد. در ۲۰۰۰ ‏OSD‏ تصادفی، نسبت پرترین شارد به میانگین در میانه ۱.۳۶ و در صدک ۹۵ حدود ۱.۶۸ بود. این یکی از دلیل‌های این است که روی ‏NVMe‏ بالا بردن تعداد ‏PG‏ هر ‏OSD‏ (و در نتیجه هموارتر شدن این توزیع) گاهی کارایی را بیشتر از تغییر تعداد ‏thread‏ بهبود می‌دهد. روی ‏HDD‏ با یک شارد این مسئله وجود ندارد: همه‌ی ‏PG‏ها در یک صف ‏mClock‏ هستند و پنج ‏thread‏ آن را می‌کشند.

۲۱-۷-۲ سهم حافظه‌ی هر ‏OSD‏ در ‏cephadm‏#

pseudocode
total = memory_total_kb × 1024 × autotune_memory_target_ratio (0.7)
for d in daemonهای میزبان:
    mds: total −= mds_cache_memory_limit
    OSD با osd_memory_target_autotune = false: total −= osd_memory_target آن
    OSD دیگر: به فهرست tuned
    هر نوع دیگر: total −= max(min_size_by_type[type] یا 1 GiB، memory_usage فعلی)
        (mgr، mds و nvmeof: 4 GiB ؛ mon: 1 GiB ؛ crash، haproxy، keepalived: 128 MiB)
if total < 0 یا tuned خالی: کاری نکن
per = ⌊total / |tuned|⌋
تنظیم‌های per-OSD قبلی را پاک کن ؛ config set osd/host:<host> osd_memory_target per

مثال عددی. میزبانی ۲۵۶ ‏GiB‏ حافظه، یک ‏mon‏، یک ‏mgr‏، ‏crash‏، ‏node-exporter‏، یک ‏RGW‏ و ۲۰ ‏OSD‏ دارد. ‏total‏ = ۲۵۶ × ۰.۷ = ۱۷۹.۲ ‏GiB‏. فرض کنید مصرف فعلی ‏mon‏ ‏۲.۱ ‏GiB‏ و ‏RGW‏ ‏۱.۵ ‏GiB‏ باشد (عددهای مثال). ‏mgr‏ با مصرف ۳ ‏GiB‏ حداقل ۴ ‏GiB‏ حساب می‌شود، ‏crash‏ ‏۱۲۸ ‏MiB‏ و ‏node-exporter‏ (که در جدول نیست) ۱ ‏GiB‏. جمع این‌ها ۸.۷۲۵ ‏GiB‏ است و برای ‏OSD‏ها ۱۷۰.۴۷۵ ‏GiB‏ می‌ماند. هر ‏OSD‏ ‏⌊۱۷۰.۴۷۵ ‏GiB‏ / ۲۰⌋ = ۹۱۵۲۳۰۶۸۷۲ بایت، حدود ۸.۵۲ ‏GiB‏، می‌گیرد. چون مقدار با ماسک ‏osd/host:<host>‏ نوشته می‌شود، همه‌ی ‏OSD‏های یک میزبان یک عدد دارند. اگر یک ‏OSD‏ را با ‏osd_memory_target_autotune = false‏ و مقدار دستی از این محاسبه بیرون بگذارید، مقدار آن از کل کم می‌شود و بقیه بین ‏OSD‏های خودکار تقسیم می‌شود.

دو تله وجود دارد. اول، مصرف فعلی ‏daemon‏ها در محاسبه می‌آید، پس اگر ‏RGW‏ ناگهان ۱۰ ‏GiB‏ مصرف کند، ده دقیقه بعد سهم هر ‏OSD‏ حدود ۰.۴ ‏GiB‏ کم می‌شود. دوم، ‏osd_memory_target‏ یک هدف برای حافظه‌ی نگاشت‌شده‌ی ‏heap‏ است، نه سقف ‏RSS‏. توضیح خود گزینه می‌گوید ‏RSS‏ ممکن است تا حدود ۲۰ درصد بیشتر شود. سی درصدی که ‏ratio‏ کنار می‌گذارد برای همین، برای سیستم‌عامل و برای ‏page cache‏ است.

۲۱-۷-۳ مسیر نوشتن ‏BlueStore: small‏، ‏big‏ و ‏deferred‏#

pseudocode
# bluestore_write_v2 = false (پیش‌فرض در main)
if offset و end−1 در یک بلوک min_alloc_size باشند و length ≠ min_alloc_size: _do_write_small(کل)
else:
    head = [offset, p2roundup(offset, mas))      → _do_write_small
    tail = [p2align(end, mas), end)               → _do_write_small
    middle = بقیه                                  → _do_write_big (در صورت segment_size، تکه‌تکه)
_do_write_big: اگر l ≤ 2 × prefer_deferred_size: تلاش برای نوشتن در blobهای موجود به‌صورت deferred
_do_alloc_write برای blob تازه: اگر data_size < prefer_deferred_size ⇒ deferred (ابتدا در WAL و RocksDB، بعد روی دستگاه)
                                 وگرنه ⇒ نوشتن مستقیم روی دستگاه، سپس commit فراداده
prefer_deferred_size = bluestore_prefer_deferred_size یا hdd: 64K ، ssd: 0

مثال عددی. ‏OSD‏ روی ‏HDD‏ است، با ‏min_alloc_size‏ ‏۴ ‏KiB‏ (پیش‌فرض ‏main‏ برای ‏hdd‏ و ‏ssd‏) و ‏prefer_deferred_size‏ ‏۶۴ ‏KiB‏.

• ۱۶ ‏KiB‏ در ‏offset‏ صفر یک شیء تازه: ‏offset‏ و ‏end‏ − ۱ در بلوک‌های ۰ و ۳ هستند، پس ‏head‏ و ‏tail‏ صفرند و کل ۱۶ ‏KiB‏ به مسیر ‏big‏ می‌رود. ‏blob‏ تازه است و ۱۶ ‏KiB‏ < ۶۴ ‏KiB‏، پس ‏deferred‏ نوشته می‌شود: داده ابتدا در تراکنش ‏RocksDB‏ (روی دستگاه ‏DB/WAL‏ اگر جدا باشد) می‌نشیند و بعد روی ‏HDD‏ اعمال می‌شود.
• ۶۴ ‏KiB‏ در ‏offset‏ صفر: ۶۴ ‏KiB‏ < ۶۴ ‏KiB‏ برقرار نیست، پس مستقیم روی ‏HDD‏ نوشته می‌شود و فقط فراداده به ‏RocksDB‏ می‌رود.
• ۷۰ ‏KiB‏ در ‏offset‏ ‏۶ ‏KiB‏: ‏head‏ ‏۲ ‏KiB‏ (۶ تا ۸ ‏KiB‏) به مسیر ‏small‏، و ‏middle‏ ‏۶۸ ‏KiB‏ (۸ تا ۷۶ ‏KiB‏) به ‏big‏ و مستقیم می‌رود. چون ‏end‏ = ۷۶ ‏KiB‏ هم‌تراز است، ‏tail‏ صفر است.
• ۱ ‏KiB‏ در ‏offset‏ ‏۱۰۰: درون یک بلوک است و به مسیر ‏small‏ می‌رود.
• ۴ ‏KiB‏ هم‌تراز در ‏offset‏ ‏۸ ‏KiB‏: درون یک بلوک است، اما چون ‏length‏ = ‏min_alloc_size‏ است، به شاخه‌ی ‏else‏ و مسیر ‏big‏ می‌رود و ‏deferred‏ می‌شود.

روی ‏SSD‏ با ‏prefer_deferred_size‏ ‏۰، شرط ‏data_size < 0‏ هرگز برقرار نیست و هیچ نوشتن ‏big deferred‏ نمی‌شود. ‏HDD‏ نمی‌تواند نوشتن‌های کوچک تصادفی را سریع انجام دهد، پس ‏BlueStore‏ آن‌ها را ابتدا ترتیبی در ‏WAL‏ می‌نویسد و بعد در پس‌زمینه اعمال می‌کند. هزینه‌ی این کار دو بار نوشتن است. اگر ‏DB/WAL‏ روی ‏NVMe‏ باشد، این دو بار نوشتن عملاً تأخیر نوشتن کوچک را به تأخیر ‏NVMe‏ نزدیک می‌کند. مسیر ‏small‏ خودش منطق جداگانه‌ای (خواندن-تغییر-نوشتن و ‏deferred‏ روی ‏blob‏ موجود) دارد که در فصل‌های ۱۲ و ۲۴ آمده است. مسیر جدید ‏bluestore_write_v2‏ در ‏main‏ وجود دارد، اما پیش‌فرض آن ‏false‏ است و این مثال‌ها را پوشش نمی‌دهد.

۲۱-۷-۴ ‏dmClock‏ با عدد#

pseudocode
tag_calc(t, prev, inv, extreme_high): inv == 0 ? (high ? max_tag : min_tag) : max(t, prev + inv × cost)
ورود یا رسیدن به سر صف (IsDelayed = true در OSD):
    R = tag_calc(t, R_prev, 1/res, high) ; P = tag_calc(t, P_prev, 1/wgt, high) ; L = tag_calc(t, L_prev, 1/lim, low)
do_next_request(now):
    if کمینه‌ی R ≤ now: سرویس از فاز reservation
    else: هر سری با L ≤ now را ready کن ; اگر ready با P کمینه هست: سرویس از فاز weight
          و R سر صف همان کلاینت را 1/res × cost کم کن      # سرویس weight جزو reservation حساب نشود
    else (AtLimit::Wait در OSD): صبر تا کمینه‌ی R یا L بعدی

در ‏OSD‏، ‏cost‏ هر درخواست ‏max(اندازه به بایت، osd_bandwidth_cost_per_io)‏ است و رزرو و حد برحسب بایت در ثانیه بیان می‌شوند (فصل ۱۰). برای روشن شدن منطق، در این مثال ‏cost‏ هر درخواست را ۱ و واحدها را درخواست در ثانیه گرفته‌ایم.

مثال عددی. سه کلاینت پیوسته درخواست می‌فرستند: ‏client‏ با ‏res‏ = ۳۰۰، ‏wgt‏ = ۱ و بدون حد؛ ‏recovery‏ با ‏res‏ = ۱۰۰، ‏wgt‏ = ۱ و ‏lim‏ = ۲۰۰؛ ‏scrub‏ با ‏res‏ = ۰ و ‏wgt‏ = ۲. شبیه‌سازی ما همین الگوریتم را با بازه‌های ۱ میلی‌ثانیه‌ای اجرا کرد.

• ظرفیت ۱۰۰۰ درخواست در ثانیه: ‏client‏ ‏۳۰۰ درخواست در ثانیه گرفت که همه در فاز ‏reservation‏ بود. ‏recovery‏ ‏۲۰۰ گرفت: ۱۰۰ از ‏reservation‏ و ۱۰۰ از ‏weight‏، و حد ۲۰۰ آن را متوقف کرد. ‏scrub‏ بقیه، یعنی ۵۰۰، را در فاز ‏weight‏ گرفت. چرا ‏client‏ از فاز ‏weight‏ سهمی نگرفت؟ برچسب ‏P‏ هر کلاینت با هر درخواست سرویس‌شده جلو می‌رود، حتی در فاز ‏reservation. 300‏ درخواست ‏client‏ برچسب ‏P‏ آن را ۳۰۰ ثانیه جلو برده است، در حالی که ‏scrub‏ با وزن ۲ هر درخواست فقط ۰.۵ جلو می‌رود. سهم وزنی ‏client‏ از ۸۰۰ درخواستی که برای ‏client‏ و ‏scrub‏ می‌ماند ‏۸۰۰ / ۳ ≈ ۲۶۷ است و از رزرو ۳۰۰ کمتر است. پس ‏client‏ همان ۳۰۰ را می‌گیرد. این همان رفتار مورد انتظار ‏mClock‏ است: هر کلاینت تقریباً ‏max‏(رزرو، سهم وزنی) را می‌گیرد.
• ظرفیت ۳۵۰ درخواست در ثانیه (کمتر از ۴۰۰ درخواست رزروشده): ‏client‏ حدود ۲۶۳ و ‏recovery‏ حدود ۸۸ گرفت، یعنی تقریباً نسبت ۳ به ۱ رزروها. ‏scrub‏ تقریباً هیچ نگرفت. اگر ظرفیت واقعی ‏OSD‏ از مجموع رزروها کمتر باشد، رزروها به نسبت کوچک می‌شوند و کلاینت‌های بدون رزرو گرسنه می‌مانند. به همین دلیل ‏osd_mclock_max_capacity_iops_*‏ اگر بیش از واقعیت تخمین زده شده باشد (فصل ۱۰)، تضمین‌های پروفایل را بی‌معنا می‌کند.

۲۱-۸ سیستم‌عامل، شبکه و ‏CPU‏#

# بررسی سریع روی هر میزبان
cat /sys/block/nvme0n1/queue/scheduler
tuned-adm active
ip -d link show bond0 | grep -E "mtu|bond"
ping -M do -s 8972 -c 3 10.20.0.12          # آزمون مسیر jumbo frame
ethtool -S ens1f0 | grep -iE "drop|err" | grep -v ": 0"

۲۱-۹ طراحی ‏pool‏ و کلاینت#

• تکثیری در مقابل ‏EC‏: برای نوشتن‌های کوچک تصادفی (پایگاه داده روی ‏RBD‏)، تکثیری تأخیر کمتری دارد؛ ‏EC‏ برای داده‌ی بزرگ و ترتیبی. در ‏Tentacle‏، ‏FastEC‏ فاصله را برای بارهای ترکیبی کم کرده است (فصل ۱۳).
• تعداد ‏PG‏: ‏PG‏ کم یعنی موازی‌سازی کم در ‏OSD‏های سریع؛ ‏autoscaler‏ را با ‏bulk‏ و ‏target_size_ratio‏ راهنمایی کنید (فصل ۱۹).
• ‏RBD‏: کش ‏librbd‏ برای ماشین‌های مجازی، ‏rbd_cache_policy‏ و در صورت نیاز کش ‏persistent write-back‏؛ اندازه‌ی شیء (پیش‌فرض ۴ مگابایت) و ‏striping‏ برای بارهای ترتیبی.
• ‏RGW‏: ‏shard‏های شاخص ‏bucket‏ (resharding پویا به‌صورت پیش‌فرض فعال است)، تعداد ‏thread‏های ‏frontend‏ و جداسازی ‏pool‏ شاخص روی ‏NVMe‏.
• ‏CephFS‏: ‏pin‏ کردن زیردرخت‌ها به ‏MDS rank‏ها و چند ‏MDS‏ فعال برای بار متادیتای سنگین.

۲۱-۱۰ سنجش#

۲۱-۱۰-۱ ابزارها#

; fio-rbd.job — نمونه‌ی این کتاب
[global]
ioengine=rbd
clientname=bench
pool=vm-fast
rbdname=fio-test
direct=1
time_based=1
runtime=300
ramp_time=30
group_reporting=1

[randwrite-4k]
rw=randwrite
bs=4k
iodepth=32
numjobs=4

۲۱-۱۱ تکمیلی و به‌روز#

• ‏WPQ‏ دیگر پیش‌فرض نیست؛ از ‏Quincy‏، ‏mClock‏ زمان‌بند پیش‌فرض است و بیشتر راهنماهای تنظیم قدیمی (‏sleep‏های بازیابی، ‏osd_max_backfills‏) با آن کار نمی‌کنند.
• پیش‌فرض شاردهای ‏HDD‏ در نسخه‌ی نقطه‌ای ۱۹.۲.۱ از ‏Squid‏ از ۵×۱ به ۱×۵ تغییر کرد (‏issue 66289‏) و ‏Tentacle‏ و ‏Umbrella‏ هم همین را نگه داشته‌اند.
• سازوکار جلوگیری از گرسنگی صف ‏immediate‏ در ‏mClock‏ (tracker ۶۹۰۷۸) در مستندات ‏latest‏ آمده است.
• ‏FileStore‏ در ‏Reef‏ پشتیبانی نمی‌شود؛ همه‌ی تنظیمات این فصل برای ‏BlueStore‏ است.
• ‏Crimson/SeaStore‏: بازنویسی ‏OSD‏ بر پایه‌ی ‏Seastar‏ در حال توسعه است؛ وضعیت پشتیبانی آن را برای نسخه‌ی خود در مستندات بررسی کنید و آن را در تولید بدون اطمینان از پشتیبانی رسمی به کار نبرید.

۲۱-۱۲ تمرین عملی#

1. ۱. با ‏rados bench‏ و ‏rbd bench‏ خط پایه بگیرید و نتایج را با صدک‌ها ثبت کنید.
2. ۲. پروفایل ‏mClock‏ را بین ‏balanced‏ و ‏high_client_ops‏ تغییر دهید و تأخیر کلاینت را در حین ‏backfill‏ یک ‏OSD‏ مقایسه کنید.
3. ۳. ‏osd_max_backfills‏ را بدون ‏override‏ تغییر دهید و ببینید اثری ندارد؛ سپس با ‏override‏ آزمایش کنید و برگردانید.
4. ۴. مقدار ‏osd_mclock_max_capacity_iops_ssd‏ تعیین‌شده برای هر ‏OSD‏ را با ‏ceph config dump‏ ببینید و با ‏ceph tell osd.N bench‏ مقایسه کنید.
5. ۵. روی یک میزبان ‏MTU‏ را ناهماهنگ کنید (در آزمایشگاه) و اثر را روی ‏heartbeat‏ و هشدارها ببینید.
6. ۶. در ‏dmclock_server.h‏، تابع انتخاب درخواست بعدی را پیدا و با شبه‌کد این فصل مقایسه کنید.

۲۱-۱۳ پرسش‌های مرور#

1. ۱. چرا تنظیم کارایی باید با خط پایه و یک تغییر در هر زمان انجام شود؟
2. ۲. شارد هر ‏PG‏ چگونه تعیین می‌شود و چرا همه‌ی عملیات یک ‏PG‏ در یک شارد است؟
3. ۳. ‏Squid 19.2.1‏ چه تغییری در پیش‌فرض شاردهای ‏HDD‏ داد و چرا معقول است؟
4. ۴. سه پارامتر ‏mClock‏ را تعریف کنید.
5. ۵. برچسب ‏R‏ در ‏dmclock‏ چگونه محاسبه می‌شود و ‏max‏(now, ...) چه نقشی دارد؟
6. ۶. پروفایل ‏high_client_ops‏ چه تفاوتی با ‏balanced‏ دارد؟
7. ۷. چرا تغییر ‏osd_max_backfills‏ در پروفایل‌های داخلی اثری ندارد؟
8. ۸. ‏OSD‏ ظرفیت ‏IOPS‏ خود را چگونه تعیین می‌کند و چه زمانی نتیجه را کنار می‌گذارد؟
9. ۹. سه تنظیم سیستم‌عامل یا شبکه که بیشترین اثر را دارند نام ببرید.
10. ۱۰. چرا باید صدک‌ها را به جای میانگین گزارش کرد؟

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

۲۱-۱۴ منابع این فصل#

• ‏mClock config reference‏
  https://docs.ceph.com/en/latest/rados/configuration/mclock-config-ref/
• ‏OSD config reference‏
  https://docs.ceph.com/en/latest/rados/configuration/osd-config-ref/
• ‏BlueStore config reference‏
  https://docs.ceph.com/en/latest/rados/configuration/bluestore-config-ref/
• ‏cephadm OSD service‏ (memory autotune
  https://docs.ceph.com/en/latest/cephadm/services/osd/
• ‏Hardware recommendations‏
  https://docs.ceph.com/en/latest/start/hardware-recommendations/
• ‏Network config reference‏
  https://docs.ceph.com/en/latest/rados/configuration/network-config-ref/
• ‏CBT‏ (Ceph Benchmarking Tool
  https://github.com/ceph/cbt
• ‏Source: src/dmclock‏
  https://github.com/ceph/ceph/tree/main/src/dmclock
• ‏Source: src/osd/scheduler/mClockScheduler.cc‏
  https://github.com/ceph/ceph/blob/main/src/osd/scheduler/mClockScheduler.cc
• ‏Source: src/common/options/osd.yaml.in‏
  https://github.com/ceph/ceph/blob/main/src/common/options/osd.yaml.in
• ‏Gulati, Merchant, Varman, "mClock: Handling Throughput Variability for Hypervisor IO Scheduling"‏ (OSDI ۲۰۱۰
  https://www.usenix.org/conference/osdi10/mclock-handling-throughput-variability-hypervisor-io-scheduling
• ‏tracker 69078‏
  https://tracker.ceph.com/issues/69078