راهبری و مدیریت کلاستر ‏Ceph‏

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

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

ساختن کلاستر کار یک روز است؛ راهبری آن کار چند سال. این فصل کارهای روزمره‌ی اپراتور را پوشش می‌دهد: مدیریت سرویس‌ها، پیکربندی، بزرگ و کوچک کردن کلاستر، تعویض دیسک، ارتقای نسخه و کنترل بار بازیابی. کتاب ۲۰۱۹ این کارها را با ویرایش دستی ‏ceph.conf‏، ‏ceph-deploy‏ و ‏unit‏های ‏systemd‏ بسته‌ای انجام می‌داد. در یک کلاستر امروزی با ‏cephadm‏، بیشتر این کارها اعلانی (‏declarative‏) شده‌اند: شما وضعیت مطلوب را می‌گویید و ‏orchestrator‏ آن را برقرار نگه می‌دارد.

• مدیریت سرویس در ‏cephadm‏ چه لایه‌هایی دارد و ‏systemd‏ کجای آن است؟
• پیکربندی امروز کجا نگه‌داری می‌شود و چرا ‏ceph.conf‏ تقریباً خالی است؟
• چطور گره، ‏OSD‏ و ‏MON‏ اضافه یا حذف کنیم؟
• روال امن تعویض دیسک خراب چیست؟
• ارتقای نسخه را چطور بدون قطعی و با کنترل ریسک انجام دهیم؟
• بازیابی و ‏backfill‏ را چطور کند یا تند کنیم، به‌ویژه با زمان‌بند ‏mClock‏؟

۷-۲ مدیریت سرویس‌ها#

۷-۲-۱ لایه‌های کنترل#

در ‏cephadm‏، هر ‏daemon‏ یک کانتینر است که با یک ‏unit systemd‏ اجرا می‌شود. ‏orchestrator‏ (ماژول ‏cephadm‏ در ‏MGR‏) از طریق ‏SSH‏ روی میزبان‌ها ‏daemon‏ می‌سازد، حذف می‌کند یا راه‌اندازی مجدد می‌کند. شما معمولاً فقط با لایه‌ی بالا کار می‌کنید:

ceph orch ls                          # سرویس‌ها و تعداد daemonهای مطلوب/در حال اجرا
ceph orch ps                          # همه‌ی daemonها
ceph orch ps --daemon-type osd --hostname ceph-node2
ceph orch ls --export > cluster-specs.yaml   # پشتیبان از وضعیت مطلوب

۷-۲-۲ شروع، توقف و راه‌اندازی مجدد#

ceph orch restart rgw.objstore            # همه‌ی daemonهای یک سرویس، یکی‌یکی
ceph orch daemon restart osd.3
ceph orch daemon stop mds.fs01.ceph-node3.xyzabc
ceph orch daemon start mds.fs01.ceph-node3.xyzabc
ceph orch daemon redeploy mgr.ceph-node1.abcdef   # ساخت دوباره‌ی کانتینر (مثلاً پس از تغییر image)

۷-۲-۳ ‏systemd‏ در پشت صحنه#

روی هر میزبان، ‏unit‏های ‏systemd‏ نام‌گذاری مشخصی دارند که شامل ‏fsid‏ کلاستر است. این نام‌گذاری اجازه می‌دهد چند کلاستر روی یک میزبان (مثلاً در آزمایشگاه) بدون تداخل اجرا شوند.

FSID=$(ceph fsid)
systemctl list-units "ceph-${FSID}*"
systemctl status ceph-${FSID}@osd.3.service
sudo systemctl stop ceph-${FSID}.target      # توقف همه‌ی daemonهای این کلاستر روی این میزبان
sudo systemctl start ceph-${FSID}.target
journalctl -u ceph-${FSID}@osd.3 --since "1 hour ago"
cephadm logs --name osd.3                  # همان لاگ از طریق cephadm

۷-۳ پیکربندی#

۷-۳-۱ پایگاه پیکربندی متمرکز#

از ‏Mimic‏، پیکربندی کلاستر در پایگاه پیکربندی ‏MON‏ نگه داشته می‌شود و ‏ceph.conf‏ روی میزبان‌ها فقط حداقل اطلاعات لازم برای پیدا کردن ‏MON‏ها را دارد (‏fsid‏ و ‏mon_host‏). کتاب ۲۰۱۹ هنوز افزودن بخش‌های ‏[mon.a]‏ و ‏[osd.0]‏ به ‏ceph.conf‏ را آموزش می‌داد؛ این کار امروز نه لازم است و نه توصیه می‌شود.

cat /etc/ceph/ceph.conf                      # معمولاً چند خط
ceph config dump                              # همه‌ی تنظیمات غیرپیش‌فرض
ceph config get osd osd_memory_target
ceph config set osd osd_memory_target 6442450944
ceph config set osd.12 osd_memory_target 8589934592    # فقط یک OSD
ceph config set osd/class:ssd osd_memory_target 8589934592   # همه‌ی OSDهای SSD (mask)
ceph config set client.rgw.objstore rgw_max_concurrent_requests 2048
ceph config show osd.3 | grep memory_target   # مقدار مؤثر در daemon در حال اجرا
ceph config help osd_memory_target
ceph config log 10                            # تاریخچه‌ی تغییرات

۷-۳-۲ تغییر موقت در زمان اجرا#

ceph tell osd.* config set debug_osd 10/10      # موقتاً، تا راه‌اندازی مجدد
ceph tell osd.* config set debug_osd 1/5        # بازگرداندن
ceph daemon osd.3 config show                    # از طریق admin socket، روی همان میزبان (درون shell cephadm)

۷-۴ بزرگ و کوچک کردن کلاستر#

۷-۴-۱ ‏scale-up‏ یا ‏scale-out‏؟#

۷-۴-۲ افزودن گره و ‏OSD‏#

# روی گره تازه: نصب podman، تنظیم زمان (chrony) و کلید SSH کلاستر
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-node5
ceph orch host add ceph-node5 192.168.10.15 --labels osd
ceph orch device ls ceph-node5 --refresh
# اگر spec OSD شما (مثلاً all-available-devices یا یک spec با فیلتر) فعال است، OSDها خودکار ساخته می‌شوند
ceph orch ls osd
ceph -s

ceph osd set norebalance && ceph osd set nobackfill
ceph orch apply -i osd-spec.yaml
ceph osd tree
ceph osd unset nobackfill && ceph osd unset norebalance

۷-۴-۳ افزودن ‏MON‏ و ‏MGR‏#

در ‏cephadm‏، تعداد و محل ‏MON‏ها با ‏spec‏ سرویس ‏mon‏ تعیین می‌شود:

service_type: mon
placement:
  count: 5
  label: mon

ceph orch host label add ceph-node5 mon
ceph orch apply -i mon-spec.yaml
ceph mon stat
ceph quorum_status -f json-pretty | jq '.quorum_names'

۷-۴-۴ حذف ‏OSD‏#

ceph osd safe-to-destroy osd.9        # آیا بدون از دست رفتن داده می‌توان حذف کرد؟
ceph osd ok-to-stop osd.9             # آیا توقف موقت باعث از دسترس رفتن PG می‌شود؟
ceph orch osd rm 9                    # تخلیه و حذف
ceph orch osd rm status

‏ceph orch osd rm‏ ابتدا وزن ‏OSD‏ را صفر می‌کند، صبر می‌کند تا همه‌ی ‏PG‏ها جای دیگری بروند، سپس ‏daemon‏ را حذف و ‏OSD‏ را از ‏CRUSH‏ و نقشه پاک می‌کند. با ‏--zap‏ دیسک هم پاک‌سازی (‏LVM‏ و ‏partition‏ها) می‌شود تا دوباره قابل استفاده باشد.

۷-۴-۵ حذف یک میزبان کامل#

ceph orch host drain ceph-node5       # همه‌ی daemonها را تخلیه می‌کند، از جمله OSDها
ceph orch osd rm status
ceph orch ps ceph-node5               # باید خالی شود
ceph orch host rm ceph-node5

۷-۵ تعویض دیسک خراب#

وقتی دیسکی خراب می‌شود، ‏OSD‏ آن ‏down‏ می‌شود و پس از ‏mon_osd_down_out_interval‏ (پیش‌فرض ۱۰ دقیقه) به‌صورت خودکار ‏out‏ می‌شود و بازیابی شروع می‌شود. روال پیشنهادی:

ceph health detail
ceph osd tree down
ceph device ls-by-daemon osd.7                 # شناسه‌ی دستگاه و میزبان
ceph device light on <devid> ident             # روشن کردن چراغ شناسایی (اگر سخت‌افزار پشتیبانی کند)
# صبر تا داده بازیابی شود
ceph -s
ceph osd safe-to-destroy osd.7
ceph orch osd rm 7 --replace --zap
ceph orch osd rm status
# پس از تعویض فیزیکی دیسک
ceph orch device ls ceph-node2 --refresh
ceph osd tree | grep osd.7

۷-۶ ارتقای نسخه#

‏cephadm‏ ارتقای نسخه را خودکار و مرحله‌ای انجام می‌دهد و ترتیب درست را رعایت می‌کند. پیش از ارتقا:

• یادداشت‌های انتشار نسخه‌ی مقصد را کامل بخوانید، به‌ویژه بخش «‏Upgrading‏» و تغییرات ناسازگار.
• مسیر ارتقای مجاز را بررسی کنید: ‏Ceph‏ معمولاً ارتقا را حداکثر از دو نسخه‌ی اصلی قبل‌تر پشتیبانی می‌کند.
• کلاستر باید ‏HEALTH_OK‏ باشد و همه‌ی ‏PG‏ها ‏active+clean‏.
• برای ‏Umbrella‏، پیش‌نیازهای میزبان را چک کنید: ‏image‏‌ها مبتنی بر ‏el10‏ هستند و ‏CPU‏ با سطح ‏x86-64-v3‏ لازم است.

ceph versions
ceph orch upgrade start --image quay.io/ceph/ceph:v20.2.5
ceph orch upgrade status
ceph -W cephadm                         # دنبال کردن رویدادهای ارتقا
ceph orch upgrade pause                 # در صورت مشکل
ceph orch upgrade resume
ceph orch upgrade stop

۷-۶-۱ ارتقای مرحله‌ای و محدود#

‏cephadm‏ اجازه می‌دهد ارتقا را به نوع ‏daemon‏، سرویس یا میزبان خاصی محدود کنید. در ‏Umbrella‏ امکان ارتقای ‏OSD‏ها ‏bucket‏ به ‏bucket‏ در ‏CRUSH‏ اضافه شده است که با دستور تازه‌ی ‏ceph osd ok-to-upgrade‏ بررسی می‌کند کدام ‏OSD‏ها را می‌توان هم‌زمان ارتقا داد:

ceph orch upgrade start --image quay.io/ceph/ceph:v21.2.0 --daemon-types mgr,mon
ceph orch upgrade start --image quay.io/ceph/ceph:v21.2.0 --daemon-types osd --crush_bucket_type rack --crush_bucket_name rack-a

۷-۷ ظرفیت و توازن#

۷-۷-۱ نسبت‌های پر شدن#

‏Ceph‏ برای جلوگیری از پر شدن کامل ‏OSD‏ها سه آستانه دارد. پر شدن کامل یک ‏OSD‏ در ‏Ceph‏ بسیار خطرناک است، چون ‏BlueStore‏ برای حذف داده هم به فضای آزاد نیاز دارد:

ceph osd dump | grep -E 'full_ratio|nearfull'
ceph osd df tree                    # درصد استفاده و تعداد PG هر OSD
ceph df detail                      # فضای خام و قابل استفاده هر pool

۷-۷-۲ ظرفیت «قابل استفاده» واقعی#

عدد ‏MAX AVAIL‏ در ‏ceph df‏ ظرفیت قابل استفاده‌ی هر ‏pool‏ را با در نظر گرفتن نوع افزونگی و پرترین ‏OSD‏ محاسبه می‌کند. یعنی عدم توازن، ظرفیت قابل استفاده را کم می‌کند: اگر یک ‏OSD‏ زودتر پر شود، کل ‏pool‏ پر به حساب می‌آید. برای برنامه‌ریزی ظرفیت این قاعده‌ها را به کار ببرید:

• ظرفیت خام را بر ضریب افزونگی تقسیم کنید (۳ برای تکثیر سه‌تایی، ‏(k+m)/k‏ برای ‏EC‏).
• فضای لازم برای تحمل خرابی بزرگ‌ترین دامنه را کم کنید.
• حاشیه‌ی امن تا ‏nearfull‏ را کم کنید (معمولاً هدف مصرف عادی زیر ۷۰ درصد).

۷-۷-۳ ‏balancer‏#

ماژول ‏balancer‏ در ‏MGR‏ با تنظیم نگاشت‌های ‏upmap‏ (جابه‌جایی صریح ‏PG‏ها بین ‏OSD‏ها) توزیع را یکنواخت می‌کند. در نسخه‌های جاری به‌صورت پیش‌فرض فعال است و حالت ‏upmap‏ به کلاینت‌هایی با حداقل نسخه‌ی ‏Luminous‏ نیاز دارد.

ceph balancer status
ceph balancer mode upmap
ceph balancer on
ceph config set mgr target_max_misplaced_ratio .03     # حداکثر ۳٪ داده‌ی جابه‌جا‌شده در هر لحظه
ceph osd df | sort -nk17 | tail                        # پرترین OSDها

۷-۷-۴ مقیاس‌دهی خودکار ‏PG‏#

ماژول ‏pg_autoscaler‏ تعداد ‏PG‏ هر ‏pool‏ را بر اساس داده‌ی ذخیره‌شده یا اندازه‌ی هدفی که اعلام می‌کنید تنظیم می‌کند:

ceph osd pool autoscale-status
ceph osd pool set rbd target_size_ratio 0.4          # این pool قرار است ۴۰٪ کلاستر را بگیرد
ceph osd pool set cephfs.fs01.meta pg_autoscale_mode on
ceph osd pool set images bulk true                   # pool بزرگ: از ابتدا PG کافی بگیرد

۷-۸ از درون کد: ‏MON‏، ‏Paxos‏ و سرویس‌های نقشه#

۷-۸-۱ نقش ‏Paxos‏ در ‏Ceph‏#

همه‌ی نقشه‌های کلاستر (‏MonMap‏، ‏OSDMap‏، ‏MgrMap‏، ‏FSMap‏، پیکربندی مرکزی، کلیدهای ‏cephx‏ و...) روی یک نمونه‌ی ‏Paxos‏ مشترک در ‏src/mon/Paxos.cc‏ ذخیره می‌شوند. هر «سرویس» (‏PaxosService‏؛ مانند ‏OSDMonitor‏، ‏AuthMonitor‏، ‏ConfigMonitor‏) تغییرات خود را به این ‏Paxos‏ پیشنهاد می‌کند و ‏Paxos‏ آن‌ها را یکی‌یکی با شماره‌ی نسخه‌ی پیوسته (‏last_committed‏) در ‏RocksDB‏ مانیتور می‌نویسد. پیاده‌سازی ‏Ceph‏ نسخه‌ای از ‏Multi-Paxos‏ با رهبر پایدار است: پس از انتخابات، رهبر یک بار مرحله‌ی بازیابی (‏collect/last‏) را انجام می‌دهد و سپس هر تغییر فقط به یک رفت‌وبرگشت (‏begin/accept‏) و یک پیام ‏commit‏ نیاز دارد.

یک تفاوت مهم با ‏Paxos‏ کلاسیک: رهبر برای ‏commit‏ منتظر پذیرش همه‌ی اعضای ‏quorum‏ فعلی می‌ماند، نه فقط اکثریت. در ‏Paxos::handle_accept()‏:

// from ceph/ceph, LGPL — src/mon/Paxos.cc, handle_accept() (excerpt)
accepted.insert(from);
...
if (accepted == mon.get_quorum()) {

این ممکن است چون ‏quorum‏ خودش از انتخابات اکثریتی آمده است؛ اگر یکی از اعضای ‏quorum‏ پاسخ ندهد، ‏accept timeout‏ رخ می‌دهد و انتخابات دوباره برگزار می‌شود تا ‏quorum‏ کوچک‌تری (که هنوز اکثریت است) شکل بگیرد. مزیت: همه‌ی اعضای ‏quorum‏ همیشه همه‌ی نسخه‌ها را دارند و می‌توانند خواندن را با ‏lease‏ سرویس دهند.

۷-۸-۲ حالت‌ها و ‏lease‏#

حالت‌های ‏Paxos‏ در ‏Paxos.h‏: ‏STATE_RECOVERING‏، ‏STATE_ACTIVE‏، ‏STATE_UPDATING‏، ‏STATE_UPDATING_PREVIOUS‏، ‏STATE_WRITING‏، ‏STATE_WRITING_PREVIOUS‏، ‏STATE_REFRESH‏ (و ‏SHUTDOWN‏). خواندن از یک ‏peon‏ فقط وقتی مجاز است که ‏lease‏ معتبر داشته باشد. پارامترها:

۷-۸-۳ از فرمان تا نقشه‌ی جدید#

pseudocode: PaxosService (خلاصه‌ی این کتاب از PaxosService.cc و OSDMonitor.cc)
  dispatch(op):
      if preprocess_query(op): return            # فقط‌خواندنی؛ مثلاً osd dump
      if not leader: forward(op to leader); return
      if prepare_update(op):                     # تغییر روی pending_inc
          if should_propose(delay):              # دسته‌بندی با paxos_propose_interval
              schedule propose_pending() after delay
  propose_pending():
      t = new transaction
      encode_pending(t)                          # OSDMap::Incremental → bytes
      paxos.begin(t)                             # OP_BEGIN به quorum
  on commit:
      update_from_paxos()                        # epoch جدید
      publish incrementals to subscribers        # OSDها و کلاینت‌ها
      reply to waiting ops

۷-۸-۴ انتخابات#

‏src/mon/ElectionLogic.h‏ سه راهبرد انتخابات دارد: ‏CLASSIC‏ (بر اساس ‏rank‏؛ کمترین ‏rank‏ برنده می‌شود)، ‏DISALLOW‏ (فهرستی از ‏MON‏ها نباید رهبر شوند) و ‏CONNECTIVITY‏ (شامل ‏DISALLOW‏، و ترجیح ‏MON‏ی با اتصال بهتر بر اساس امتیازهای اتصال که در ‏store‏ ذخیره می‌شوند). ‏stretch mode‏ به ‏connectivity‏ نیاز دارد (فصل ۱۸).

ceph mon dump | grep election_strategy
ceph mon set election_strategy connectivity
ceph mon add disallowed_leader e         # MON داور هرگز رهبر نشود
ceph quorum_status | jq '.quorum_leader_name, .quorum_names'
ceph daemon mon.a sessions | jq length   # روی میزبان MON

۷-۹ عملیات روزمره با عدد: ‏down‏، ‏out‏، ‏grace‏ و ‏MAX AVAIL‏#

چهار الگوریتم این بخش در ‏MON‏ اجرا می‌شوند و به چند پرسش روزمره‌ی اپراتور جواب می‌دهند: چرا ‏OSD‏ در این لحظه ‏down‏ شد یا نشد، چرا بعد از ده دقیقه ‏out‏ شد، و چرا ‏ceph df‏ فضای آزاد کمتری از فضای خام نشان می‌دهد. ارجاع‌ها به ‏main‏ در نوامبر ۲۰۲۶ است و عددها با بازپیاده‌سازی پایتونی حساب شده‌اند.

۷-۹-۱ علامت‌گذاری ‏down‏: گزارش‌دهنده‌ها و ‏grace‏#

pseudocode
گزارش‌دهنده‌ها را بر حسب mon_osd_reporter_subtree_level (پیش‌فرض host) گروه کن
if تعداد گروه‌ها < mon_osd_min_down_reporters (2): هنوز نه
failed_for = now − failed_since                      # از اولین گزارش، با عقب‌بردن زمان
grace = osd_heartbeat_grace (20)
if mon_osd_adjust_heartbeat_grace (true):
    decay = exp(failed_for × ln 0.5 / mon_osd_laggy_halflife (3600))
    grace += decay × laggy_interval × laggy_probability             # سابقه‌ی خود OSD
    grace += میانگین همان جمله برای گزارش‌دهنده‌ها (با decay از down_stamp آن‌ها)
if failed_for ≥ grace: OSD را در نقشه‌ی بعدی down کن
اگر failed_for ≥ grace + osd_heartbeat_stale (600 s) شد و هنوز تصمیمی نیست: گزارش‌ها را دور بریز

مثال عددی. ‏OSD‏ سالمی که سابقه‌ی ‏laggy‏ ندارد (‏p‏ = ۰) وقتی ‏down‏ می‌شود که همتایانش روی دست‌کم دو میزبان متفاوت گزارش بدهند و ‏failed_for‏ به ۲۰ ثانیه برسد. چون ‏OSD‏ها خودشان پس از ۲۰ ثانیه بدون پاسخ ‏ping‏ گزارش می‌دهند، این معمولاً تقریباً هم‌زمان با اولین گزارش‌هاست. اگر همه‌ی گزارش‌ها از ‏OSD‏های یک میزبان باشند، شمارش گروهی ۱ است و ‏OSD‏ هیچ‌وقت ‏down‏ نمی‌شود. این عمدی است، چون مشکل شبکه‌ی یک میزبان نباید باعث ‏down‏ شدن بقیه‌ی کلاستر شود. در کلاستر سه‌میزبانی، اگر دو میزبان دیگر سالم باشند، این شرط برقرار می‌شود.

۷-۹-۲ سابقه‌ی ‏laggy‏: میانگین متحرک نمایی#

pseudocode
w = mon_osd_laggy_weight (0.3)
هنگام boot یک OSD که down علامت خورده بود:
    if boot_epoch == 0 (پردازه واقعاً از نو شروع شده):  p ×= 0.7 ; I ×= 0.7
    else (پردازه زنده بود، یعنی down اشتباه بود):
        gap = min(now − down_stamp, mon_osd_laggy_max_interval 300)
        I = w × gap + (1 − w) × I ;  p = w + (1 − w) × p
اگر down بعدی بیش از 48 × laggy_halflife (48 ساعت) پس از down_stamp قبلی بیفتد: p = I = 0

مثال عددی. ‏OSD‏ی که زیر بار سنگین به اشتباه ‏down‏ می‌شود و هر بار ۴۰ ثانیه بعد برمی‌گردد، پس از بار اول ‏p‏ = ۰.۳ و ‏I‏ = ۱۲ دارد. پس از بار دوم ‏p‏ = ۰.۵۱ و ‏I‏ = ۲۰.۴ است و پس از بار سوم ‏p‏ = ۰.۶۵۷ و ‏I‏ = ۲۶.۲۸. پس ‏grace‏ شکست بعدی تقریباً ۲۰ + ۰.۶۵۷ × ۲۶.۲۸ = ۳۷.۳ ثانیه است. ‏decay‏ در اینجا روی ‏failed_for‏ حساب می‌شود، یعنی چند ده ثانیه، و حدود ۰.۹۹۴ است. سری ‏grace‏ برای ۱ تا ۸ ‏down‏ اشتباه این است: ۲۳.۶، ۳۰.۴، ۳۷.۳، ۴۳.۱، ۴۷.۷، ۵۱.۱، ۵۳.۷ و ۵۵.۵ ثانیه. حد بالای آن ۲۰ + ۴۰ = ۶۰ ثانیه است. یعنی ‏MON‏ خود به خود با ‏OSD‏های «بدقلق» صبورتر می‌شود. چیزی که سابقه را پاک می‌کند گذشت زمان نیست، بلکه ری‌استارت واقعی پردازه یا ۴۸ ساعت بدون ‏down‏ است. همین جمله، با ‏decay‏ بر اساس مدت ‏down‏، به ‏mon_osd_down_out_interval‏ هم اضافه می‌شود. برای مثال بالا، ‏out‏ پس از حدود ۶۱۵ ثانیه انجام می‌شود، نه ۶۰۰.

۷-۹-۳ از ‏down‏ تا ‏out‏#

pseudocode
هر tick برای هر OSD در down_pending_out:
    down = now − زمان down شدن
    grace = mon_osd_down_out_interval (600) + exp(down × ln 0.5 / 3600) × I × p
    if پرچم noout (سراسری یا روی گره CRUSH یا device class) یا can_mark_out رد کند: ادامه
    if کل زیردرختی از نوع mon_osd_down_out_subtree_limit (rack) down است: down_pending_out[o] = now ; ادامه
    if down ≥ grace: OSD را out کن (reweight = 0) ← PGها remap و backfill می‌شوند

مثال عددی. ‏OSD‏ بی‌سابقه دقیقاً ۶۰۰ ثانیه پس از ‏down‏، ‏out‏ می‌شود. اگر یک ‏rack‏ کامل با ۳ میزبان و ۳۶ ‏OSD‏ خاموش شود، شمارنده‌ی هیچ‌کدام جلو نمی‌رود و ‏out‏ خودکار انجام نمی‌شود. این سیاست محافظه‌کارانه است: فرض می‌کند خاموشی کامل یک ‏rack‏ (برق یا سوئیچ) گذرا است و نباید باعث جابه‌جایی چند ده ترابایت داده شود. برای نگه‌داری برنامه‌ریزی‌شده‌ی یک میزبان، به جای پرچم سراسری از ‏ceph osd set-group noout <host>‏ یا ‏ceph orch host maintenance enter‏ استفاده کنید.

۷-۹-۴ ‏MAX AVAIL‏ در ‏ceph df‏#

pseudocode
wm = سهم وزنی هر OSD در rule (get_rule_weight_osd_map، مجموع = 1)
برای هر OSD با وزن > 0:
    avail = max(0, kb_avail − kb × (1 − full_ratio))      # 5٪ ذخیره‌ی پیش از full
    proj  = avail / wm[osd]                                # چقدر داده‌ی خام تا پر شدن همین OSD
raw_avail = min(proj)                                       # پرترین OSD نسبت به سهمش
MAX AVAIL = raw_avail / raw_used_rate     # replicated: size ؛ EC: (k + m) / k

مثال عددی. کلاستری با ۵۲ ‏TiB‏ خام را در نظر بگیرید: یازده ‏OSD‏ چهار ترابایتی و یک ‏OSD‏ هشت ترابایتی. ده ‏OSD‏ چهار ترابایتی ۶۰٪ پرند، ‏osd.10‏ ‏۸۰٪ و ‏osd.11‏ (هشت ترابایتی) ‏۵۵٪. سهم وزنی هر ‏OSD‏ چهار ترابایتی ۴/۵۲ است. برای ‏OSD‏های ۶۰٪ داریم ‏proj‏ = (۱.۶ − ۰.۲) / (۴/۵۲) = ۱۸.۲ ‏TiB‏، اما برای ‏osd.10‏ فقط (۰.۸ − ۰.۲) / (۴/۵۲) = ۷.۸ ‏TiB. MAX AVAIL‏ یک ‏pool‏ سه‌نسخه‌ای ۷.۸ / ۳ = ۲.۶ ‏TiB‏ است و یک ‏pool‏ ‏‏EC‏ ‏۴+۲ برابر ۷.۸ / ۱.۵ = ۵.۲ ‏TiB‏. اگر ‏osd.10‏ هم ۶۰٪ بود، همین ‏pool‏ سه‌نسخه‌ای ۶.۱ ‏TiB‏ نشان می‌داد. پس یک ‏OSD‏ نامتوازن بیش از نیمی از فضای «قابل‌استفاده»ی گزارش‌شده را می‌خورد. این تعریف درست است، چون ‏CRUSH‏ داده را به نسبت وزن پخش می‌کند و همان ‏OSD‏ اول پر می‌شود. علاج آن ‏balancer‏ با حالت ‏upmap‏ است، نه افزودن دیسک.

۷-۱۰ نگهداری روزمره#

۷-۱۰-۱ حالت نگهداری میزبان#

برای کارهای برنامه‌ریزی‌شده (به‌روزرسانی هسته، تعویض قطعه، راه‌اندازی مجدد)، از حالت نگهداری ‏cephadm‏ استفاده کنید. این حالت همه‌ی ‏daemon‏های ‏Ceph‏ روی میزبان را متوقف می‌کند و پرچم ‏noout‏ را فقط برای همان میزبان می‌گذارد تا ‏OSD‏هایش ‏out‏ نشوند و بازیابی بی‌مورد شروع نشود:

ceph osd ok-to-stop $(ceph osd ls-tree ceph-node2 | tr '\n' ' ')   # آیا توقف همه‌ی OSDهای این میزبان امن است؟
ceph orch host maintenance enter ceph-node2
# ... راه‌اندازی مجدد میزبان یا تعمیر ...
ceph orch host maintenance exit ceph-node2
ceph -s

۷-۱۰-۲ پرچم‌های کلاستر#

ceph osd set noout
ceph osd unset noout
ceph osd set-group noout osd.4    # فقط یک OSD
ceph osd set-group noout ceph-node3   # همه‌ی OSDهای یک میزبان (bucket CRUSH)
ceph osd unset-group noout ceph-node3

۷-۱۰-۳ کنترل سرعت بازیابی و ‏backfill‏#

راهنماهای قدیمی برای کند کردن بازیابی، تنظیم مستقیم ‏osd_max_backfills‏، ‏osd_recovery_max_active‏ و ‏osd_recovery_sleep‏ را آموزش می‌دادند. از ‏Quincy‏، زمان‌بند پیش‌فرض ‏OSD‏ ‏mClock‏ است و این تنظیمات را خودش مدیریت می‌کند. راه درست امروزی انتخاب پروفایل است:

ceph config get osd osd_mclock_profile
ceph config set osd osd_mclock_profile high_recovery_ops
# پس از اتمام بازیابی
ceph config set osd osd_mclock_profile balanced

۷-۱۰-۴ اولویت‌دهی به ‏PG‏های خاص#

ceph pg force-recovery 2.1f
ceph pg force-backfill 2.1f 2.20
ceph pg cancel-force-recovery 2.1f

۷-۱۰-۵ ‏scrub‏#

‏scrub‏ سبک (هر روز) فراداده‌ی نسخه‌ها را مقایسه می‌کند و ‏deep-scrub‏ (هر هفته) داده را با ‏checksum‏ بررسی می‌کند. برای کاهش اثر ‏scrub‏ بر کلاینت، آن را به ساعات کم‌بار محدود کنید:

ceph config set osd osd_scrub_begin_hour 1
ceph config set osd osd_scrub_end_hour 6
ceph pg deep-scrub 2.1f
ceph health detail | grep -i scrub

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

• ‏ceph-deploy‏ بازنشسته شده و ‏ceph-ansible‏ هم دیگر مسیر توصیه‌شده نیست؛ ‏cephadm‏ و ‏Rook‏ دو روش پشتیبانی‌شده‌ی استقرار و راهبری هستند.
• پیکربندی متمرکز (‏Mimic‏) جای ویرایش ‏ceph.conf‏ را گرفت.
• ‏mClock‏ (پیش‌فرض از ‏Quincy‏) کنترل بازیابی را به پروفایل‌ها سپرد؛ نسخه‌ی نقطه‌ای ۱۹.۲.۱ از ‏Squid‏ پیش‌فرض‌های ‏shard HDD‏ را به ۱ شارد × ۵ ‏thread‏ تغییر داد (‏issue 66289‏).
• ‏Umbrella‏: ارتقای ‏OSD‏ به ترتیب ‏bucket‏های ‏CRUSH‏ و دستور ‏ceph osd ok-to-upgrade‏؛ پیش‌نیاز ‏CPU x86-64-v3‏ و ‏image‏‌های ‏el10‏؛ و افزایش پیش‌فرض‌های ‏mon_target_pg_per_osd‏ به ۲۰۰ و ‏mon_max_pg_per_osd‏ به ۵۰۰ که بر برنامه‌ریزی ‏PG‏ در کلاسترهای ارتقایافته اثر دارد.
• ‏Tentacle‏: ماژول‌های ‏restful‏ و ‏zabbix‏ از ‏MGR‏ حذف شدند؛ اگر اسکریپت‌های عملیاتی شما به ‏restful‏ وابسته‌اند، پیش از ارتقا آن‌ها را به ‏API‏ داشبورد منتقل کنید.

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

1. ۱. خروجی ‏ceph orch ls --export‏ را ذخیره کنید، تعداد ‏MGR‏ها را تغییر دهید و تفاوت را با ‏diff‏ ببینید.
2. ۲. ‏osd_memory_target‏ را فقط برای ‏OSD‏های کلاس ‏ssd‏ تغییر دهید و با ‏ceph config show‏ در یک ‏OSD‏ بررسی کنید.
3. ۳. یک میزبان را وارد حالت نگهداری کنید، آن را راه‌اندازی مجدد کنید و خارج شوید. در حین کار خروجی ‏ceph -s‏ و پرچم‌ها را یادداشت کنید.
4. ۴. خرابی دیسک را با ‏ceph orch daemon stop osd.N‏ شبیه‌سازی کنید، پس از ‏out‏ شدن، روال تعویض با ‏--replace‏ را اجرا کنید.
5. ۵. پروفایل ‏mClock‏ را به ‏high_recovery_ops‏ تغییر دهید و سرعت بازیابی (‏ceph -s‏) را با ‏balanced‏ مقایسه کنید.
6. ۶. در آزمایشگاه، کلاستر را به آخرین نسخه‌ی نقطه‌ای همان خط ارتقا دهید و مراحل را با ‏ceph -W cephadm‏ دنبال کنید.

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

1. ۱. چرا توقف ‏daemon‏ با ‏systemctl‏ در ‏cephadm‏ توصیه نمی‌شود؟
2. ۲. ترتیب اولویت منابع پیکربندی چیست و مقدار مؤثر را چطور می‌بینید؟
3. ۳. تفاوت ‏ceph tell‏ و ‏ceph daemon‏ چیست؟
4. ۴. مزایا و معایب ‏scale-up‏ و ‏scale-out‏ را از نظر دامنه‌ی خرابی مقایسه کنید.
5. ۵. چرا هنگام افزودن تعداد زیادی ‏OSD‏، پرچم‌های ‏norebalance‏ و ‏nobackfill‏ مفیدند؟
6. ۶. تفاوت ‏ok-to-stop‏ و ‏safe-to-destroy‏ چیست؟
7. ۷. گزینه‌ی ‏--replace‏ در حذف ‏OSD‏ چه مزیتی دارد؟
8. ۸. حالت نگهداری ‏cephadm‏ چه کاری انجام می‌دهد؟
9. ۹. چرا در ‏mClock‏ تنظیم مستقیم ‏osd_max_backfills‏ اثر ندارد و راه درست چیست؟
10. ۱۰. ارتقای ‏OSD‏ به ترتیب ‏bucket‏های ‏CRUSH‏ در ‏Umbrella‏ چه ریسکی را کاهش می‌دهد؟

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

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

• ‏cephadm operations‏
  https://docs.ceph.com/en/latest/cephadm/operations/
• ‏Host management‏
  https://docs.ceph.com/en/latest/cephadm/host-management/
• ‏OSD service‏
  https://docs.ceph.com/en/latest/cephadm/services/osd/
• ‏Upgrading Ceph‏ (cephadm
  https://docs.ceph.com/en/latest/cephadm/upgrade/
• ‏Configuring Ceph‏
  https://docs.ceph.com/en/latest/rados/configuration/ceph-conf/
• ‏ceph command reference‏
  https://docs.ceph.com/en/latest/man/8/ceph/
• ‏mClock config reference‏
  https://docs.ceph.com/en/latest/rados/configuration/mclock-config-ref/
• ‏Device management‏
  https://docs.ceph.com/en/latest/rados/operations/devices/
• ‏Monitor/OSD interaction‏
  https://docs.ceph.com/en/latest/rados/configuration/mon-osd-interaction/
• ‏Adding/removing monitors‏
  https://docs.ceph.com/en/latest/rados/operations/add-or-rm-mons/
• ‏Release index‏
  https://docs.ceph.com/en/latest/releases/
• ‏Tentacle release notes‏
  https://docs.ceph.com/en/latest/releases/tentacle/