پایش OpenStack و Ceph زمانی به پایداری ابر خصوصی کمک می‌کند که هشدارها به تصمیم و اقدام مشخص برسند. نمایش نمودارهای متعدد، بدون تعیین مسئول رسیدگی و روش بررسی، برای مدیریت رخداد کافی نیست. تیم زیرساخت باید بداند چه اتفاقی افتاده، چه سرویس‌هایی ممکن است تحت تأثیر باشند و بررسی را از کجا شروع کند.
پایش را از تجربه کاربر شروع کنید
کاربر ابر خصوصی معمولاً با نتیجه عملیات سروکار دارد: آیا می‌تواند وارد سامانه شود، ماشین مجازی بسازد، دیسک متصل کند یا به برنامه دسترسی داشته باشد؟ برنامه پایش باید این مسیرها را در کنار وضعیت اجزای زیرساخت بررسی کند.
برای مثال، موفق بودن بررسی یک API به‌تنهایی ثابت نمی‌کند که تمام مراحل ساخت ماشین مجازی به‌درستی انجام می‌شوند. آزمون‌های دوره‌ای کنترل‌شده می‌توانند مسیر واقعی عملیات را بررسی کنند. منابع آزمایشی، زمان اجرا و پاک‌سازی آن‌ها باید از پیش مشخص باشند.
سلامت Ceph را با جزئیات هشدار بررسی کنید
Ceph مجموعه‌ای از بررسی‌های سلامت با شناسه‌های مشخص دارد. این شناسه‌ها به تیم عملیات کمک می‌کنند نوع مسئله را تشخیص دهد. برای نمونه، هشدار مربوط به Monitor در دسترس‌نبودن، با هشدار کمبود فضای دیسک Monitor یکسان نیست؛ هرکدام مسیر بررسی متفاوتی دارند.
وضعیت کلی کلاستر، نقطه شروع بررسی است. جزئیات هشدار و شرایط محیط باید پیش از انتخاب اقدام اصلاحی خوانده شوند. خاموش‌کردن هشدار بدون رفع علت، نشانه بازگشت سرویس به وضعیت مطلوب نیست. منبع: مستندات رسمی بررسی‌های سلامت Ceph.
Prometheus چه بخشی از این مسیر را پوشش می‌دهد؟
ماژول Prometheus در Ceph، اطلاعات پایش را برای جمع‌آوری در اختیار Prometheus قرار می‌دهد. طراحی جمع‌آوری باید با نسخه Ceph، معماری استقرار و دسترسی شبکه هماهنگ باشد. منبع: راهنمای رسمی ماژول Prometheus در Ceph.
در استقرارهای مبتنی بر Kolla-Ansible نیز امکاناتی برای راه‌اندازی Prometheus و جمع‌آوری شاخص‌های اجزای مختلف وجود دارد. این قابلیت را نباید به تمام روش‌های نصب OpenStack تعمیم داد؛ اجزای فعال و تنظیمات محیط باید جداگانه بررسی شوند. منبع: راهنمای پایش در Kolla-Ansible.
کدام شاخص‌ها برای شروع اهمیت دارند؟
- موفقیت و زمان پاسخ عملیات مهم از دید کاربر.
- دسترس‌پذیری سرویس‌های کنترلی و وابستگی‌های آن‌ها.
- سلامت Ceph و وضعیت اجزای ذخیره‌سازی.
- روند مصرف ظرفیت و توزیع آن میان گره‌ها.
- تأخیر و خطاهای ذخیره‌سازی متناسب با بار کاری.
- کامل‌بودن جمع‌آوری داده و دسترس‌پذیری خود سامانه پایش.
آستانه هشدار را با داده واقعی و نیاز سرویس تعیین کنید. یک مقدار ثابت برای تمام محیط‌ها، ممکن است در یک سازمان هشدارهای بی‌اثر ایجاد کند و در سازمان دیگر دیر عمل کند. مدت تداوم وضعیت نیز باید در طراحی هشدار لحاظ شود.
هر هشدار باید راهنمای رسیدگی داشته باشد
یک هشدار کاربردی باید منبع، زمان شروع، دامنه احتمالی اثر و مسئول رسیدگی را روشن کند. راهنمای همراه آن بهتر است بررسی‌های اولیه، اطلاعات لازم برای ارجاع و معیار پایان رخداد را مشخص کند.
فرض کنید تأخیر دیسک ماشین‌های مجازی افزایش یافته است. تیم باید زمان شروع و گستره اثر را با وضعیت ذخیره‌سازی، شبکه و تغییرات اخیر مقایسه کند. هم‌زمانی دو نمودار، به‌تنهایی اثبات رابطه علت و معلولی نیست؛ نتیجه بررسی باید با شواهد ثبت شود.
پس از رخداد، کیفیت هشدار را بازبینی کنید
پس از رسیدگی، بررسی کنید هشدار به‌موقع صادر شده، به فرد مناسب رسیده و اطلاعات کافی داشته است یا نه. هشدارهای تکراری و بدون اقدام را اصلاح کنید و راهنمای رسیدگی را با یافته‌های واقعی به‌روز نگه دارید.
برای بررسی نیازهای طراحی و بهره‌برداری زیرساخت سازمان، صفحه خدمات ابر خصوصی دواپس ایران را ببینید.
منابع رسمی در ۱۷ اکتبر ۲۰۲۶ بررسی شدند. صفحات latest ممکن است مربوط به نسخه توسعه باشند؛ برای اجرا، مستندات نسخه نصب‌شده ملاک است.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300