سنجش کارایی و ابزارهای کارشناسی ‏Ceph‏

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

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

«کلاستر ما چقدر سریع است؟» سؤالی است که هر تیم ‏Ceph‏ بالاخره با آن روبه‌رو می‌شود، و جواب درست آن تقریباً هیچ‌وقت یک عدد نیست. این فصل روش سنجش کارایی را از پایین‌ترین لایه (دیسک و شبکه) تا رابط‌ها آموزش می‌دهد و سپس به جعبه‌ابزار اپراتور کارشناس می‌پردازد: ‏admin socket‏، ‏ceph tell‏، ‏API‏ مدیریتی، پروفایل حافظه و ‏ceph-objectstore-tool‏. سرفصل قدیمی چند ابزار را هم داشت که امروز کنار رفته‌اند (‏ceph-medic‏، ماژول ‏restful‏، ‏BlueStore‏ «آزمایشی»)؛ وضعیت آن‌ها را هم روشن می‌کنیم.

• چرا باید سنجش را لایه‌به‌لایه انجام داد؟
• خط پایه‌ی دیسک و شبکه را چطور بگیریم؟
• ‏rados bench‏، ‏rbd bench‏ و ‏fio‏ را چطور درست اجرا و تفسیر کنیم؟
• ‏admin socket‏ و ‏ceph tell‏ چه تفاوتی دارند و چه اطلاعاتی می‌دهند؟
• مصرف حافظه‌ی ‏daemon‏ها را چطور بررسی کنیم؟
• ‏ceph-objectstore-tool‏ چه زمانی ابزار نجات است و چه زمانی خطرناک؟

۱۰-۲ روش سنجش لایه‌ای#

اگر ‏rbd bench‏ عدد ناامیدکننده‌ای بدهد، نمی‌دانید مشکل از دیسک است، از شبکه، از پیکربندی ‏OSD‏ یا از کلاینت. اما اگر بدانید هر دیسک چند ‏IOPS‏ می‌دهد و شبکه چند گیگابیت، می‌توانید سقف نظری را حساب کنید و ببینید کجا فاصله ایجاد شده است. قاعده‌ی کلی:

1. ۱. سقف هر دیسک و هر لینک شبکه را جداگانه اندازه بگیرید.
2. ۲. سقف نظری کلاستر را حساب کنید (با در نظر گرفتن ضریب تکثیر یا ‏EC‏).
3. ۳. ‏RADOS‏ را مستقیم بسنجید.
4. ۴. رابط‌ها (‏RBD‏، ‏RGW‏، ‏CephFS‏) را بسنجید.
5. ۵. بار واقعی برنامه را آزمایش کنید.

۱۰-۳ خط پایه‌ی سخت‌افزار#

۱۰-۳-۱ دیسک#

ابزار درست برای سنجش دیسک ‏fio‏ است؛ ‏dd‏ فقط یک الگوی ساده‌ی ترتیبی را می‌سنجد و عمق صف را کنترل نمی‌کند. آزمایش‌های زیر را روی دیسکی انجام دهید که هنوز ‏OSD‏ نشده است، چون نوشتن مستقیم روی دیسک خام داده‌ی آن را نابود می‌کند.

# نوشتن ترتیبی بلوک بزرگ (توان)
sudo fio --name=seqwrite --filename=/dev/sdX --rw=write --bs=4M --direct=1 \
  --ioengine=libaio --iodepth=16 --runtime=60 --time_based --group_reporting
# نوشتن تصادفی بلوک کوچک با sync (نزدیک به رفتار WAL)
sudo fio --name=syncwrite --filename=/dev/sdX --rw=randwrite --bs=4k --direct=1 \
  --sync=1 --ioengine=libaio --iodepth=1 --numjobs=1 --runtime=60 --time_based
# خواندن تصادفی
sudo fio --name=randread --filename=/dev/sdX --rw=randread --bs=4k --direct=1 \
  --ioengine=libaio --iodepth=32 --runtime=60 --time_based

۱۰-۳-۲ اجرای هم‌زمان روی چند دیسک#

برای پیدا کردن گلوگاه کنترلر یا گذرگاه، همان آزمایش را هم‌زمان روی همه‌ی دیسک‌های یک گره اجرا کنید و مجموع را با حاصل‌ضرب تعداد دیسک در عدد تک‌دیسک مقایسه کنید. اگر مجموع بسیار کمتر است، کنترلر ‏HBA‏، ‏expander‏ یا ‏PCIe‏ گلوگاه است.

sudo fio --rw=write --bs=4M --direct=1 --ioengine=libaio --iodepth=16 --runtime=60 --time_based --group_reporting \
  --name=d1 --filename=/dev/sdb --name=d2 --filename=/dev/sdc --name=d3 --filename=/dev/sdd

۱۰-۳-۳ شبکه#

# روی گره ۱
iperf3 -s
# روی گره ۲: چند جریان موازی، چون یک جریان TCP معمولاً لینک ۲۵ یا ۱۰۰ گیگابیتی را پر نمی‌کند
iperf3 -c ceph-node1 -P 8 -t 30
# بررسی MTU و jumbo frame از سر تا سر
ping -M do -s 8972 -c 3 ceph-node1

۱۰-۳-۴ سقف نظری#

با اعداد خط پایه می‌توانید سقف تقریبی را حساب کنید. مثلاً با ۶ گره، هر کدام ۱۰ ‏SSD‏ که هرکدام ۱.۵ گیگابایت بر ثانیه نوشتن ترتیبی دارند، و شبکه‌ی ۲۵ گیگابیتی (حدود ۳ گیگابایت بر ثانیه) در هر گره:

• دیسک‌ها: ۶ × ۱۰ × ۱.۵ = ۹۰ گیگابایت بر ثانیه نوشتن خام.
• با تکثیر سه‌تایی، هر بایت کاربر سه بار نوشته می‌شود: حدود ۳۰ گیگابایت بر ثانیه.
• اما شبکه‌ی هر گره فقط ۳ گیگابایت بر ثانیه است و هر بایت ورودی دو بار دیگر روی شبکه به ثانویه‌ها می‌رود؛ پس شبکه گلوگاه است و سقف واقعی بسیار پایین‌تر از ۳۰ است.

این نوع محاسبه نشان می‌دهد سرمایه‌گذاری بعدی باید روی شبکه باشد، نه دیسک.

۱۰-۴ سنجش ‏RADOS‏#

۱۰-۴-۱ بنچمارک ‏OSD‏ منفرد#

هر ‏OSD‏ یک بنچمارک داخلی دارد که مستقیماً روی ‏BlueStore‏ همان ‏OSD‏ می‌نویسد (بدون شبکه و تکثیر). برای پیدا کردن ‏OSD‏های کند در میان صدها ‏OSD‏ مفید است:

ceph tell osd.0 bench                       # پیش‌فرض: ۱ گیگابایت با بلوک ۴ مگابایتی
ceph tell osd.0 bench 12288000 4096 4194304 100   # کل بایت، اندازه‌ی بلوک، اندازه‌ی شیء، تعداد اشیا
for i in $(ceph osd ls); do echo -n "osd.$i "; ceph tell osd.$i bench -f json | jq -r .bytes_per_sec; done | sort -nk2 | head

۱۰-۴-۲ ‏rados bench‏#

‏rados bench‏ بار را مستقیماً روی یک ‏pool‏ می‌فرستد و مسیر کامل ‏RADOS‏ (شبکه، تکثیر، ‏commit‏) را می‌سنجد. ‏pool‏ جداگانه بسازید تا داده‌ی آزمایشی با داده‌ی واقعی مخلوط نشود:

ceph osd pool create benchpool 128 128
ceph osd pool application enable benchpool rados-bench --yes-i-really-mean-it
rados bench -p benchpool 60 write -b 4M -t 16 --no-cleanup
rados bench -p benchpool 60 seq -t 16
rados bench -p benchpool 60 rand -t 16
rados bench -p benchpool 60 write -b 4K -t 64 --no-cleanup     # IOPS بلوک کوچک
rados -p benchpool cleanup

۱۰-۵ سنجش ‏RBD‏#

۱۰-۵-۱ ‏rbd bench‏#

rbd create rbd/benchimg --size 100G
rbd bench --io-type write --io-size 4K --io-threads 32 --io-total 10G --io-pattern rand rbd/benchimg
rbd bench --io-type read --io-size 4K --io-threads 32 --io-total 10G --io-pattern rand rbd/benchimg
rbd bench --io-type readwrite --rw-mix-read 70 --io-size 16K --io-pattern rand rbd/benchimg

۱۰-۵-۲ ‏fio‏ با موتور ‏rbd‏#

‏fio‏ موتور ‏rbd‏ دارد که مستقیماً از ‏librbd‏ استفاده می‌کند؛ بدون نیاز به ‏rbd map‏ یا ماشین مجازی. این روش برای مقایسه‌ی پیکربندی‌ها ایده‌آل است:

# rbd-randwrite.fio
[global]
ioengine=rbd
clientname=admin
pool=rbd
rbdname=benchimg
direct=1
time_based=1
runtime=120
ramp_time=15
group_reporting=1

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

[randread-4k]
stonewall
rw=randread
bs=4k
iodepth=32
numjobs=4

fio rbd-randwrite.fio --output-format=json > result.json
jq '.jobs[] | {name: .jobname, write_iops: .write.iops, read_iops: .read.iops, p99_us: (.write.clat_ns.percentile."99.000000" // .read.clat_ns.percentile."99.000000")/1000}' result.json

۱۰-۵-۳ پیش‌گرم کردن ‏image‏#

اولین نوشتن روی هر بخش از ‏image‏ تازه کندتر است، چون اشیای ‏RADOS‏ باید ساخته شوند. پیش از سنجش نوشتن تصادفی، ‏image‏ را یک بار با نوشتن ترتیبی کامل پر کنید؛ در غیر این صورت عدد اندازه‌گیری‌شده ترکیبی از «ساخت شیء» و «بازنویسی» است.

۱۰-۶ جعبه‌ابزار اپراتور#

۱۰-۶-۱ ‏admin socket‏ و ‏ceph tell‏#

هر ‏daemon‏ یک ‏admin socket‏ (فایل سوکت یونیکس) دارد که دستورهای تشخیصی را بدون نیاز به ‏MON‏ یا شبکه پاسخ می‌دهد. در ‏cephadm‏، سوکت‌ها زیر ‏/var/run/ceph/<fsid>/‏ قرار دارند و ساده‌ترین راه استفاده، ‏cephadm shell --name‏ است:

cephadm shell --name osd.3 -- ceph daemon osd.3 help
cephadm shell --name osd.3 -- ceph daemon osd.3 dump_ops_in_flight
cephadm shell --name osd.3 -- ceph daemon osd.3 dump_historic_ops
cephadm shell --name osd.3 -- ceph daemon osd.3 perf dump bluestore
cephadm shell --name osd.3 -- ceph daemon osd.3 config diff

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

ceph tell osd.3 dump_ops_in_flight
ceph tell osd.3 dump_historic_slow_ops
ceph tell osd.* version
ceph tell mon.* sessions | jq length
ceph tell mds.fs01:0 perf dump

۱۰-۶-۲ ‏API‏ مدیریتی#

در گذشته «‏Ceph REST API‏» بر اساس ماژول ‏restful‏ ارائه می‌شد. این ماژول در ‏Tentacle‏ حذف شد. برای خودکارسازی امروز دو راه دارید:

• ‏API Dashboard‏ برای عملیات مدیریتی (فصل ۹)، با احراز هویت ‏JWT‏ و نسخه‌دار.
• کتابخانه‌های ‏librados‏ (پایتون، ‏C‏، ‏Go‏ و ...) برای دسترسی برنامه‌نویسی به ‏RADOS‏ و حتی ارسال دستورهای ‏MON‏ (فصل ۱۴).

import rados, json
cluster = rados.Rados(conffile='/etc/ceph/ceph.conf', name='client.monitor')
cluster.connect()
ret, out, err = cluster.mon_command(json.dumps({"prefix": "df", "format": "json"}), b'')
stats = json.loads(out)["stats"]
print(stats["total_bytes"], stats["total_used_raw_bytes"])
cluster.shutdown()

۱۰-۷ سنجش ‏RGW‏ و ‏CephFS‏#

۱۰-۷-۱ ذخیره‌سازی شیء#

برای ‏RGW‏، ابزار عمومی و متن‌باز رایج ‏warp‏ است (از پروژه‌ی ‏MinIO‏) که هر سرویس سازگار با ‏S3‏ را می‌سنجد. پیش از اجرا یک کاربر و ‏bucket‏ جدا برای آزمایش بسازید:

radosgw-admin user create --uid=bench --display-name="Benchmark user"
# کلیدها را از خروجی بردارید و در متغیرهای محیطی بگذارید، نه در خط فرمان
export WARP_ACCESS_KEY=... WARP_SECRET_KEY=...
warp put --host rgw.example.internal:8080 --bucket bench-put --obj.size 4MiB --concurrent 32 --duration 2m
warp get --host rgw.example.internal:8080 --bucket bench-get --obj.size 4MiB --concurrent 32 --duration 2m
warp mixed --host rgw.example.internal:8080 --bucket bench-mixed --obj.size 64KiB --duration 3m

۱۰-۷-۲ فایل‌سیستم#

برای ‏CephFS‏ دو نوع آزمایش لازم است: داده (توان خواندن و نوشتن فایل‌های بزرگ) و فراداده (ساخت، ‏stat‏ و حذف تعداد زیادی فایل کوچک). ‏fio‏ برای داده کافی است؛ برای فراداده، ابزارهایی مثل ‏mdtest‏ (از مجموعه‌ی ‏IOR‏ در جامعه‌ی ‏HPC‏) یا یک اسکریپت ساده مناسب‌اند.

# داده: چند job هم‌زمان روی فایل‌های جدا
fio --name=cephfs-seq --directory=/mnt/fs01/bench --rw=write --bs=4M --size=8G \
    --numjobs=8 --direct=1 --ioengine=libaio --iodepth=8 --group_reporting
# فراداده: ساخت و حذف ۱۰۰ هزار فایل خالی
time (mkdir -p /mnt/fs01/meta && cd /mnt/fs01/meta && seq 1 100000 | xargs -P 16 -n 1000 touch)
time rm -rf /mnt/fs01/meta
ceph tell mds.fs01:0 perf dump mds_server | jq '.mds_server | {req: .handle_client_request}'

۱۰-۸ گزارش بنچمارک#

عدد بدون زمینه بی‌ارزش است. هر گزارش بنچمارک باید شامل این موارد باشد تا دیگران بتوانند آن را تکرار یا مقایسه کنند:

۱۰-۹ از درون کد: ‏osd bench‏، ‏rados bench‏ و سنجش ظرفیت ‏mClock‏#

۱۰-۹-۱ دو ابزار، دو چیز متفاوت#

خطای رایج این است که خروجی ‏ceph tell osd.N bench‏ را با ‏rados bench‏ مقایسه کنیم. این دو ابزار دو لایه‌ی کاملاً متفاوت را می‌سنجند و کد آن‌ها هم این تفاوت را نشان می‌دهد.

pseudocode: ObjBencher::write_bench (خلاصه‌ی این کتاب)
  start status_printer thread
  for slot in 0..concurrentios-1: aio_write(obj_name(slot), data)
  while elapsed < seconds:
      wait any completion c                      # lc.cond
      record latency(c) → min/max/avg, iops
      issue next aio_write in the same slot
  wait all ; write metadata object (BENCH_LASTRUN_METADATA)
  print: Bandwidth (MB/sec), Average IOPS, Average Latency(s), Stddev

ceph tell osd.4 bench                       # 1G با بلوک 4M
ceph tell osd.4 bench 12288000 4096 4194304 100   # همان پارامترهای آزمون بوت mClock
ceph config dump | grep osd_mclock_max_capacity_iops
rados bench -p bench 60 write -t 32 -b 4M --no-cleanup
rados bench -p bench 60 rand -t 32 ; rados -p bench cleanup
ceph osd perf                               # commit/apply latency هر OSD در حین آزمون

۱۰-۱۰ سه الگوریتم سنجش با عدد#

۱۰-۱۰-۱ سقف ایمنی ‏osd bench‏#

pseudocode
duration = osd_bench_duration (30)
if bsize > osd_bench_max_block_size (64M): EINVAL
elif bsize < 1M: max_count = bsize × duration × osd_bench_small_size_max_iops (100)
else:            max_count = osd_bench_large_size_max_throughput (100M) × duration
if count > max_count: EINVAL
if osize and bsize > osize: bsize = osize
run: flush cache ; prefill onum × osize ; write count بایت در تکه‌های bsize ; cleanup
bandwidth = count / elapsed ; iops = bandwidth / bsize

مثال عددی. با ‏ceph tell osd.4 bench 12288000 4096 4194304 100‏ داریم ‏bsize‏ = ۴‏K‏ < ۱‏M‏. پس ‏max_count‏ = ۴۰۹۶ × ۳۰ × ۱۰۰ = ۱۲۲۸۸۰۰۰. ‏count‏ دقیقاً برابر سقف است و پذیرفته می‌شود. کد آزمون بوت ‏mClock‏ هم همین عدد را به کار می‌برد. این آزمون ۳۰۰۰ نوشتن ۴‏K‏ را در ۱۰۰ شیء ۴ مگابایتی پخش می‌کند. اگر ۱۰ ثانیه طول بکشد، ‏bandwidth‏ = ۱۲۲۸۸۰۰ ‏B/s‏ و ‏iops‏ = ۳۰۰.

برای بلوک ۴‏M‏، سقف ۱۰۰‏M‏ × ۳۰ = ۳۱۴۵۷۲۸۰۰۰ بایت است. همین عدد برای بلوک ۱‏M‏ هم از قاعده‌ی ‏IOPS‏ به دست می‌آید (۱‏M‏ × ۳۰ × ۱۰۰)، پس دو قاعده در مرز ۱‏M‏ پیوسته‌اند. ‏ceph tell osd.4 bench 4294967296 4194304‏ (۴ ‏GiB‏) با ‏EINVAL‏ رد می‌شود.

۱۰-۱۰-۲ پذیرش ظرفیت اندازه‌گیری‌شده برای ‏mClock‏#

pseudocode
if scheduler ≠ mClock or osd_mclock_skip_benchmark or store == memstore: return
key = rotational ? osd_mclock_max_capacity_iops_hdd : …_ssd
if !force_run_benchmark_on_init and current(key) ≠ default(key): return   # کاربر یا بوت قبلی تنظیم کرده
iops = OSDBenchTest(count 12288000, bsize 4096, osize 4M, onum 100).run()
(lo, hi) = rotational ? (50, 500) : (1000, 80000)
if lo ≤ iops ≤ hi: mon_cmd_set_config(key, iops)       # در پایگاه پیکربندی MON
else: هشدار کلاستر و نگه داشتن مقدار فعلی

مثال عددی.

• ‏HDD‏، اندازه‌گیری ۳۰۰ ‏IOPS‏: در بازه‌ی [۵۰، ۵۰۰] است، پس در پایگاه پیکربندی ‏MON‏ ذخیره می‌شود. از بوت بعد، چون مقدار دیگر پیش‌فرض نیست، آزمون اجرا نمی‌شود.
• ‏HDD‏ با کش نوشتن، ۶۰۰۰ ‏IOPS‏: بزرگ‌تر از ۵۰۰ است، پس رد می‌شود و ۳۱۵ می‌ماند.
• ‏SSD‏، اندازه‌گیری ۴۵۰۰۰: در بازه‌ی [۱۰۰۰، ۸۰۰۰۰] است و ذخیره می‌شود.
• ‏NVMe‏، اندازه‌گیری ۲۵۰۰۰۰: رد می‌شود و ۲۱۵۰۰ می‌ماند. برای چنین دستگاهی باید مقدار را خودتان از ‏fio‏ تنظیم کنید.

برای اندازه‌گیری دوباره، ‏ceph config rm osd.N osd_mclock_max_capacity_iops_ssd‏ و راه‌اندازی دوباره‌ی ‏OSD‏ لازم است، یا ‏osd_mclock_force_run_benchmark_on_init = true‏.

۱۰-۱۰-۳ از ظرفیت تا رزرو هر کلاس#

pseudocode
bw = osd_mclock_max_sequential_bandwidth_{hdd 150M | ssd 1200M} ; iops = max_capacity_iops
cost_per_io = bw / iops ; cap_per_shard = bw / num_shards (hdd 1 ، ssd 8)
for class in (client, background_recovery, background_best_effort):
    res = r ? r × cap_per_shard : کمینه ; lim = l ? l × cap_per_shard : بی‌سقف ; weight = w
cost(op) = max(op_bytes, cost_per_io)      # opهای کوچک دست‌کم یک «IO کامل» هزینه دارند

مثال عددی (‏HDD‏ با پیش‌فرض‌ها). ‏cost_per_io‏ = ۱۵۷۲۸۶۴۰۰ / ۳۱۵ = ۴۹۹۳۲۲ بایت. پس یک نوشتن ۴‏K‏ هزینه‌ای برابر ۴۸۸ ‏KiB‏ دارد. با پروفایل پیش‌فرض ‏balanced‏ (v۲۱.۲.۰):

• ‏client‏: رزرو ۰.۵ × ۱۵۰ ‏MiB/s‏، معادل ۱۵۷.۵ ‏op‏ کوچک در ثانیه.
• ‏background_recovery‏: همان ۱۵۷.۵.
• ‏background_best_effort‏: رزرو ۰.۰۵، معادل ۱۵.۷۵ ‏op‏، و سقف ۰.۹، معادل ۲۸۳.۵ ‏op‏.

در ‏high_client_ops‏ رزرو ‏client‏ به ۱۸۹ و وزنش به ۲ می‌رسد. در ‏SSD‏ با ۲۱۵۰۰ ‏IOPS‏ و ۸ شارد، ‏cost_per_io‏ = ۵۸۵۲۵ بایت است و رزرو ‏client‏ در ‏balanced‏ برای هر شارد ۱۳۴۳.۷۵ ‏op‏ و در کل ۱۰۷۵۰ ‏op‏ می‌شود. یعنی همان نیمی از ۲۱۵۰۰.

۱۰-۱۱ سنجش واقعی روی یک کلاستر آزمایشی#

دو اندازه‌گیری این بخش روی یک کلاستر سه‌‏OSD‏ی ‏BlueStore‏ اجرا شده‌اند: ‏Ceph 18.2.7‏ از بسته‌های ‏Debian‏، با فایل‌های ‏sparse‏ ده‌گیگابایتی روی دیسک یک ماشین مجازی. عددهای مطلق سخت‌افزار واقعی را نشان نمی‌دهند، چون ‏cache‏ صفحه‌ی سیستم‌عامل و یک ‏CPU‏ مشترک در کارند. اما شکل منحنی‌ها همان چیزی است که روی هر کلاستری خواهید دید. هدف آموختن خواندن این منحنی‌هاست.

۱۰-۱۱-۱ هم‌روندی، تأخیر و قانون ‏Little‏#

pseudocode
rados bench -t T: همیشه دقیقاً T عملیات در پرواز ← هر completion یک op تازه می‌فرستد
X = IOPS اندازه‌گیری‌شده ؛ R = میانگین تأخیر
قانون Little برای سامانه‌ی بسته: L = X · R = T
پس: R = T / X  ←  وقتی X اشباع شود، R خطی با T رشد می‌کند

اندازه‌گیری (نوشتن ۴ ‏KiB‏، ‏‏pool‏ با ‏size‏ = ۲، هر نقطه ۸ ثانیه).

ستون آخر عملاً همان ‏T‏ است. این ثابت می‌کند ‏rados bench‏ یک بار کاری حلقه‌بسته است. نتیجه‌ی عملی: اگر با بالا بردن ‏-t‏ تأخیر بالا می‌رود ولی ‏IOPS‏ کمتر از نسبت بالا می‌رود (از ۱۶ به ۶۴، چهار برابر هم‌روندی فقط ۱.۶۵ برابر ‏IOPS‏ داد)، به گلوگاه رسیده‌اید. از آنجا به بعد، هم‌روندی بیشتر فقط صف را طولانی‌تر می‌کند.

در گزارش بنچمارک همیشه ‏-t‏ را کنار ‏IOPS‏ بنویسید. عدد ‏IOPS‏ بدون هم‌روندی معنا ندارد. وقتی سنجش با ‏iodepth‏ ثابت (‏fio‏) یا با نرخ ثابت (حلقه‌باز) انجام شود، این رابطه شکل دیگری دارد.

۱۰-۱۱-۲ اندازه‌ی شیء: از سقف ‏IOPS‏ تا سقف پهنای باند#

اندازه‌گیری (‎-‏t 16‏). از ۴ ‏KiB‏ تا ۶۴ ‏KiB‏، ‏‏IOPS‏ تقریباً ثابت می‌ماند (۸۷۳۳، ۶۲۸۶ و ۶۴۴۳) و ‏MB/s‏ با اندازه رشد می‌کند. یعنی گلوگاه هزینه‌ی هر عملیات است: ‏CPU‏، پیام‌رسانی و تراکنش ‏RocksDB‏. از ۲۵۶ ‏KiB‏ به بالا، ‏MB/s‏ روی حدود ۶۵۰ ثابت می‌شود و ‏IOPS‏ با اندازه کم می‌شود. گلوگاه حالا پهنای باند است.

نقطه‌ی شکست (حدود ۶۴ تا ۲۵۶ ‏KiB‏ در این کلاستر) را برای هر کلاستر جداگانه اندازه بگیرید. این نقطه می‌گوید کدام بار کاری را با «‏IOPS‏» و کدام را با «‏MB/s‏» باید سنجید.

در ‏BlueStore‏ نقطه‌ی مهم دیگری هم هست. نوشتن کوچک‌تر از ‏bluestore_prefer_deferred_size‏ ابتدا در ‏WAL‏ ‏‏RocksDB‏ نوشته و بعداً اعمال می‌شود (فصل ۱۲). روی ‏HDD‏ همین جا منحنی تأخیر می‌شکند.

۱۰-۱۱-۳ پروفایل حافظه#

مصرف حافظه‌ی ‏OSD‏ها با ‏osd_memory_target‏ (پیش‌فرض ۴ گیگابایت، در ‏cephadm‏ با ‏autotune‏) کنترل می‌شود. وقتی یک ‏daemon‏ بیش از انتظار حافظه مصرف می‌کند، اول ببینید حافظه کجا رفته است:

ceph tell osd.3 dump_mempools | jq '.mempool.by_pool | to_entries | sort_by(-.value.bytes) | .[0:5]'
ceph tell osd.3 heap stats
ceph tell osd.3 heap release           # برگرداندن حافظه‌ی آزاد tcmalloc به سیستم‌عامل
ceph orch ps --daemon-type osd --format json | jq -r '.[] | "\(.daemon_name) \(.memory_usage)"' | sort -nk2 | tail

برای اشکال‌زدایی نشت حافظه، ‏profiler‏ داخلی ‏tcmalloc‏ را موقتاً فعال کنید:

ceph tell osd.3 heap start_profiler
# چند دقیقه یا ساعت صبر کنید تا الگو ظاهر شود
ceph tell osd.3 heap dump
ceph tell osd.3 heap stop_profiler
# فایل‌های heap در مسیر لاگ daemon ساخته می‌شوند و با pprof (google-perftools) تحلیل می‌شوند

۱۰-۱۱-۴ ‏ceph-objectstore-tool‏#

‏ceph-objectstore-tool‏ مستقیماً روی داده‌ی یک ‏OSD‏ متوقف‌شده کار می‌کند: می‌تواند ‏PG‏ها و اشیا را فهرست کند، یک ‏PG‏ را ‏export‏ یا ‏import‏ کند، فراداده را بخواند و در موارد خاص اصلاح کند. کاربرد کلاسیک آن نجات ‏PG‏ی است که همه‌ی نسخه‌های سالمش روی ‏OSD‏هایی بوده که دیگر بالا نمی‌آیند، اما دیسکشان هنوز خواناست.

ceph orch daemon stop osd.12
cephadm shell --name osd.12
# درون shell
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-12 --op list-pgs
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-12 --pgid 5.3a --op info
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-12 --pgid 5.3a --op export --file /var/log/ceph/pg5.3a.export
exit
# روی OSD مقصد (آن هم متوقف)
ceph orch daemon stop osd.20
cephadm shell --name osd.20 -- ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-20 --op import --file /var/log/ceph/pg5.3a.export
ceph orch daemon start osd.20
ceph pg 5.3a query | jq .state

۱۰-۱۱-۵ ابزارهای کنار رفته#

cephadm check-host
ceph health detail | grep -i cephadm

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

• ‏FileStore‏ از ‏Reef‏ به بعد پشتیبانی نمی‌شود (هنگام ارتقا هشدار ‏OSD_FILESTORE‏ می‌دهد) و ‏BlueStore‏ تنها پشته‌ی ذخیره‌سازی پشتیبانی‌شده‌ی ‏OSD‏ کلاسیک است؛ ‏crimson/SeaStore‏ هنوز پیش‌نمایش فناوری‌اند (‏Squid‏ و ‏Tentacle‏).
• ماژول ‏restful‏ در ‏Tentacle‏ حذف شد.
• ‏cephadm‏: بررسی میزبان و هشدارهای ‏orchestrator‏ جایگزین ابزارهای جانبی بررسی پیکربندی شدند.
• ‏mClock‏ نتیجه‌ی بنچمارک را تحت تأثیر قرار می‌دهد: پروفایل فعال (‏balanced‏، ‏high_client_ops‏) سهم کلاینت را تعیین می‌کند؛ در گزارش بنچمارک، پروفایل را ذکر کنید.

۱۰-۱۳ تمرین عملی#

1. ۱. روی یک دیسک خالی، سه آزمایش ‏fio‏ این فصل را اجرا کنید و نتایج را در جدول بنویسید. آزمایش ‏sync‏ را روی یک ‏SSD‏ مصرفی و یک ‏SSD‏ دیتاسنتری (اگر دارید) مقایسه کنید.
2. ۲. با ‏iperf3‏ و ‏ping‏ با ‏MTU‏ بزرگ، شبکه‌ی ‏public‏ و ‏cluster‏ را بین همه‌ی جفت گره‌ها بسنجید.
3. ۳. با حلقه‌ی ‏ceph tell osd.N bench‏، کندترین سه ‏OSD‏ را پیدا کنید.
4. ۴. ‏rados bench‏ را با بلوک ۴ مگابایت و ۴ کیلوبایت اجرا کنید و نسبت توان و ‏IOPS‏ را با سقف نظری مقایسه کنید.
5. ۵. فایل ‏fio‏ این فصل را با موتور ‏rbd‏ اجرا کنید و ‏p99‏ تأخیر را استخراج کنید. سپس پروفایل ‏mClock‏ را تغییر دهید و تکرار کنید.
6. ۶. در آزمایشگاه، یک ‏PG‏ از ‏OSD‏ متوقف را ‏export‏ و روی ‏OSD‏ دیگری ‏import‏ کنید و ‏peering‏ را مشاهده کنید.

۱۰-۱۴ پرسش‌های مرور#

1. ۱. چرا سنجش کارایی باید لایه‌به‌لایه انجام شود؟
2. ۲. چرا ‏fio‏ برای سنجش دیسک بر ‏dd‏ ترجیح دارد؟
3. ۳. چرا آزمایش نوشتن ‏sync‏ با عمق صف ۱ برای انتخاب ‏SSD‏ مهم است؟
4. ۴. ‏MTU‏ ناهماهنگ چه علائمی در ‏Ceph‏ ایجاد می‌کند؟
5. ۵. در مثال سقف نظری، چرا شبکه گلوگاه شد؟
6. ۶. تفاوت ‏ceph tell osd.N bench‏ و ‏rados bench‏ چیست؟
7. ۷. چرا باید ‏image RBD‏ را پیش از سنجش نوشتن تصادفی پر کرد؟
8. ۸. تفاوت ‏admin socket‏ و ‏ceph tell‏ چیست و هر کدام چه زمانی مفیدترند؟
9. ۹. در خروجی ‏heap stats‏، حافظه‌ی ‏freelist‏ چه معنایی دارد؟
10. ۱۰. پیش از استفاده از ‏ceph-objectstore-tool‏ چه اقدام‌هایی لازم است؟

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

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

• ‏rados manual‏
  https://docs.ceph.com/en/latest/man/8/rados/
• ‏rbd manual‏
  https://docs.ceph.com/en/latest/man/8/rbd/
• ‏Control commands‏ (osd bench
  https://docs.ceph.com/en/latest/rados/operations/control/
• ‏Memory profiling‏
  https://docs.ceph.com/en/latest/rados/troubleshooting/memory-profiling/
• ‏ceph-objectstore-tool manual‏
  https://docs.ceph.com/en/latest/man/8/ceph-objectstore-tool/
• ‏Troubleshooting OSDs‏
  https://docs.ceph.com/en/latest/rados/troubleshooting/troubleshooting-osd/
• ‏Ceph API‏
  https://docs.ceph.com/en/latest/mgr/ceph_api/
• ‏librados Python‏
  https://docs.ceph.com/en/latest/rados/api/python/
• ‏fio documentation‏
  https://fio.readthedocs.io/en/latest/fio_doc.html
• ‏iperf3‏
  https://software.es.net/iperf/
• ‏warp‏ (S۳ benchmark
  https://github.com/minio/warp
• ‏IOR and mdtest‏
  https://github.com/hpc/ior
• ‏ceph-medic repository‏
  https://github.com/ceph/ceph-medic
• ‏Tentacle release notes‏
  https://docs.ceph.com/en/latest/releases/tentacle/