عیب‌یابی کلاستر Ceph: رفع PG های Stuck و OSD های Down روی سرور اختصاصی
یک روز ceph -s را اجرا می‌کنید و به‌جای HEALTH_OK با HEALTH_WARN روبه‌رو می‌شوید. چند OSD داون شده‌اند، چند PG هم stuck مانده‌اند و کلاستر دیگر آن‌طور که باید جواب نمی‌دهد. این مقاله دستورهای تشخیص و رفع این دو مشکل رایج روی سرور اختصاصی را قدم‌به‌قدم نشان می‌دهد.
چرا Ceph به HEALTH_WARN می‌رود؟
Ceph هر چند ثانیه وضعیت سلامت کلاستر را از سه مانیتور اصلی (MON)، دمون‌های OSD و PG ها جمع می‌کند. وقتی چیزی خارج از حالت عادی باشد، وضعیت از HEALTH_OK به HEALTH_WARN یا حتی HEALTH_ERR تغییر می‌کند. برای دیدن جزئیات کافی است این دستور را اجرا کنید:
ceph -s
ceph health detail
خروجی health detail دقیقا می‌گوید کدام OSD پاسخ نمی‌دهد و کدام PG در چه وضعیتی گیر کرده. اکثر مشکلات روی سرور اختصاصی به یکی از این سه دلیل برمی‌گردد: دیسک خراب یا پر شده، شبکهٔ بین نودها قطع یا کند شده، یا دمون OSD به‌خاطر کمبود رم یا CPU از کار افتاده. اگر کلاستر را هنوز راه‌اندازی نکرده‌اید یا می‌خواهید روش استاندارد را ببینید، راه‌اندازی کلاستر Ceph با Cephadm مرحله‌های اول را نشان می‌دهد.
OSD Down روی سرور اختصاصی: علت‌های رایج
وقتی یک یا چند OSD در وضعیت down قرار می‌گیرند، اول باید فهرست کامل را ببینید:
ceph osd tree
ceph osd df
ستون STATUS در ceph osd tree وضعیت هر OSD را نشان می‌دهد. اگر عدد up کمتر از تعداد کل OSD هاست، باید سرویس مربوط را چک کنید. روی هر نود:
systemctl status ceph-osd@<id>
journalctl -u ceph-osd@<id> -n 100 --no-pager
چند علت رایج که در لاگ دیده می‌شود:
| علت | نشانهٔ معمول در لاگ | اقدام اول |
|---|---|---|
| دیسک پر یا نزدیک به ظرفیت | OSD full یا backfillfull | فضای خالی روی دیسک را افزایش دهید یا دادهٔ قدیمی را حذف کنید |
| خرابی فیزیکی دیسک | خطای I/O، read error در dmesg | با smartctl -a /dev/sdX سلامت دیسک را بررسی کنید |
| قطع یا کندی شبکه بین نودها | heartbeat timeout | پینگ و پهنای باند بین نودها را تست کنید |
| کمبود رم و OOM kill | پیام oom-kill در dmesg | مصرف رم دمون OSD را با free -h و ceph osd df چک کنید |
برای خرابی فیزیکی، smartctl -a /dev/sdX را روی دیسک مربوط به آن OSD اجرا کنید؛ اگر Reallocated_Sector_Ct یا Current_Pending_Sector عدد بالایی نشان دهد، دیسک در حال خراب شدن است و باید جایگزین شود، نه فقط ریستارت.
رفع OSD Down گام‌به‌گام
اگر سرویس فقط کرش کرده و دیسک سالم است، این ترتیب را دنبال کنید:
- سرویس را ریستارت کنید:
systemctl restart ceph-osd@<id> - چند ثانیه صبر کنید و دوباره
ceph osd treeرا بزنید تا وضعیت به up برگردد. - اگر برنگشت، فضای دیسک را با
df -h /var/lib/ceph/osd/ceph-<id>چک کنید. - اگر دیسک پر است، یا دادهٔ قدیمی را پاک کنید یا موقتا فلگ
nooutرا ست کنید تا Ceph شروع به بازتوزیع دادهٔ آن OSD نکند تا شما مشکل را رفع کنید:
ceph osd set noout
بعد از رفع مشکل، این فلگ را بردارید؛ وگرنه حتی اگر آن OSD کاملا از دسترس خارج بماند، کلاستر دادهٔ آن را دوباره توزیع نمی‌کند:
ceph osd unset noout
اگر OSD به‌خاطر دیسک خراب برنمی‌گردد و تصمیم گرفتید آن را کنار بگذارید، به‌جای ریستارت پشت‌سرهم، آن را رسما از کلاستر خارج کنید:
ceph osd out <id>
ceph osd crush remove osd.<id>
ceph auth del osd.<id>
ceph osd rm <id>
این مرحله باعث می‌شود Ceph دادهٔ جایگزین را روی OSD های سالم بازتوزیع کند، به‌جای این‌که منتظر برگشتن یک دیسک خراب بماند.
PG های Stuck: انواع و معنی هر وضعیت
PG (Placement Group) واحد توزیع داده در Ceph است. وقتی یک PG بیش از حد انتظار در یک حالت می‌ماند، به آن stuck می‌گویند. همین مکانیزم توزیع داده پشت استفاده‌های دیگر Ceph هم هست؛ مثلا وقتی از RBD به‌عنوان بک‌اند ذخیره‌سازی ماشین‌های KVM یا CephFS برای ذخیره‌سازی اشتراکی بین چند سرور استفاده می‌کنید، باز هم داده روی همین PG ها پخش می‌شود. برای دیدن فهرست کامل PG های stuck:
ceph pg dump_stuck
ceph pg stat
هر وضعیت معنی متفاوتی دارد:
| وضعیت PG | معنی | علت معمول |
|---|---|---|
| stuck inactive | PG آماده پذیرش خواندن/نوشتن نیست | OSD های لازم برای peering در دسترس نیستند |
| stuck unclean | PG کپی کامل داده را ندارد | OSD داون یا در حال recovery کند |
| stuck stale | PG مدتی گزارش جدید نداده | OSD میزبان آن از کار افتاده یا شبکه قطع است |
| degraded | تعداد کپی‌ها کمتر از مقدار تنظیم‌شده است | یک یا چند OSD از دسترس خارج شده |
| incomplete | داده برای بازسازی کافی نیست | حذف چند OSD هم‌زمان قبل از پایان recovery |
برای بررسی یک PG خاص:
ceph pg <pgid> query
خروجی این دستور نشان می‌دهد PG منتظر کدام OSD است و در کدام مرحله از peering یا recovery گیر کرده.
رفع PG های Stuck
اگر علت stuck شدن، یک OSD داون است، با برگرداندن آن OSD طبق بخش بالا معمولا PG هم خودش جمع می‌شود. اگر نه، این دستورها را به ترتیب امتحان کنید:
ceph pg repair <pgid>
این دستور برای PG هایی که دادهٔ ناسازگار بین کپی‌ها دارند (معمولا بعد از scrub error) استفاده می‌شود، نه برای PG های صرفا منتظر OSD.
اگر PG در وضعیت incomplete مانده و مطمئن هستید دادهٔ آن قابل بازیابی نیست (مثلا بعد از حذف چند OSD هم‌زمان)، آخرین راه این است:
ceph osd force-create-pg <pgid>
این دستور PG جدید و خالی می‌سازد و دادهٔ قبلی آن از بین می‌رود؛ فقط وقتی استفاده کنید که مطمئن شده‌اید دادهٔ اصلی در جای دیگری هم نیست. قبل از اجرا، ceph pg <pgid> query را دوباره بخوانید و ببینید کدام OSD ها در لیست recovery_state هستند؛ اگر یکی از آن‌ها قابل برگشت است، اول آن را امتحان کنید.
پیشگیری: مانیتورینگ و تنظیمات کلاستر
بیشتر این مشکلات زمانی سراغتان می‌آید که یک نگهداری برنامه‌ریزی‌شده (مثل ریستارت یک نود یا آپدیت سیستم) باعث OSD down موقت می‌شود. برای این حالت، قبل از شروع نگهداری:
ceph osd set noout
ceph osd set noscrub
ceph osd set nodeep-scrub
و بعد از اتمام کار، همهٔ این فلگ‌ها را بردارید. این سه خط کلاستر را از بازتوزیع بی‌مورد داده و اجرای scrub در وسط نگهداری باز می‌دارد.
برای پیشگیری بلندمدت، سلامت دیسک‌ها را به‌صورت دوره‌ای با smartctl چک کنید و مصرف رم دمون‌های OSD را روی هر نود زیر نظر داشته باشید؛ یک OSD که به‌خاطر کمبود رم بالا و پایین می‌شود، PG های اطرافش را هم به‌مرور وارد وضعیت degraded می‌کند. اگر هنوز داشبورد مشخصی برای این اعداد ندارید، راه‌اندازی مانیتورینگ سرور با Prometheus و Grafana راه‌اندازی آن را نشان می‌دهد.
اگر کلاستر Ceph روی یک سرور اختصاصی اجرا می‌شود، ثبات سخت‌افزار زیرساخت هم مستقیما روی این مشکلات اثر دارد؛ دیسک و شبکهٔ پایدار یعنی تعداد کمتر OSD down غیرمنتظره (برای انتخاب مشخصات مناسب، راهنمای خرید سرور اختصاصی برای دیتابیس معیارهای رم، دیسک NVMe و CPU را توضیح می‌دهد). سرورهای اختصاصی آریانت را از این صفحه ببینید.
سؤالات متداول
چرا بعد از برگرداندن یک OSD، کلاستر هنوز HEALTH_WARN نشان می‌دهد؟
چون recovery و backfill زمان می‌برد. با ceph -s پیشرفت درصد recovery را ببینید؛ تا تمام نشود وضعیت هشدار باقی می‌ماند.
فلگ noout چه فرقی با noscrub دارد؟ noout از بازتوزیع داده هنگام خروج موقت یک OSD جلوگیری می‌کند؛ noscrub و nodeep-scrub اجرای بررسی صحت داده را موقتا متوقف می‌کنند. هر دو برای نگهداری برنامه‌ریزی‌شده مفید هستند.
آیا force-create-pg همیشه امن است؟
نه. این دستور دادهٔ قبلی PG را پاک می‌کند و فقط برای PG هایی که دادهٔ قابل بازیابی ندارند مناسب است. قبل از اجرا با ceph pg query مطمئن شوید راه دیگری نیست.
چطور بفهمم مشکل از دیسک است یا از شبکه؟
با smartctl -a سلامت دیسک را چک کنید و با پینگ و تست پهنای باند بین نودها وضعیت شبکه را ببینید. اگر چند OSD روی نودهای مختلف هم‌زمان stale شدند، احتمال مشکل شبکه بیشتر از خرابی دیسک است.
