ظرفیت قابل استفاده در Ceph با مجموع ظرفیت دیسک‌های سرورها یکسان نیست. در ابر خصوصی، بخشی از فضای ذخیره‌سازی صرف محافظت از داده می‌شود و بخشی نیز باید برای عملیات و رشد آینده در دسترس بماند. بنابراین عدد ظرفیت خام، به‌تنهایی مبنای مناسبی برای تعهد فضای دیسک به تیم‌های سازمان نیست.
ظرفیت خام و ظرفیت قابل استفاده چه تفاوتی دارند؟
ظرفیت خام، مجموع فضای تجهیزات ذخیره‌سازی است. ظرفیت قابل استفاده، فضای باقی‌مانده پس از درنظرگرفتن سیاست محافظت از داده و محدودیت‌های محیط است. در Poolهای دارای چند نسخه از داده، هر نسخه فضای جداگانه مصرف می‌کند. به همین دلیل، فضای قابل نگهداری داده‌های کاربران از ظرفیت خام کمتر است.
برای برآورد اولیه باید سیاست هر Pool را جداگانه بررسی کرد؛ به‌ویژه وقتی چند Pool با سیاست‌های متفاوت از تجهیزات مشترک استفاده می‌کنند. جزئیات این سیاست‌ها در مستندات رسمی Poolهای Ceph توضیح داده شده است.
Erasure Coding چه اثری بر ظرفیت دارد؟
Erasure Coding داده را به قطعات داده و قطعات محافظتی تقسیم می‌کند. نسبت این قطعات بر سربار ذخیره‌سازی اثر دارد. این روش می‌تواند نسبت به نگهداری چند نسخه کامل، فضای بیشتری برای داده فراهم کند؛ اما انتخاب آن باید با نوع بار کاری، عملکرد موردنیاز و محدودیت‌های نسخه و سرویس همراه باشد.
برای دیسک‌های RBD، استفاده از Pool دارای Erasure Coding به تنظیمات و پشتیبانی قابلیت‌های لازم وابسته است؛ همچنین متادیتا در Pool دارای Replication نگهداری می‌شود. پس انتخاب این روش تنها با مقایسه ظرفیت انجام نمی‌شود. پیش از اجرا، راهنمای رسمی Erasure Coding را برای نسخه نصب‌شده بررسی کنید.
چرا نباید تمام فضای برآوردشده را تخصیص دهیم؟
ظرفیت‌سنجی باید سناریوی خرابی و بازیابی را هم پوشش دهد. سازمان باید بداند هنگام خارج شدن یک گره از مدار، داده‌ها چگونه توزیع می‌شوند و چه منابعی برای بازسازی لازم است. رشد داده، تغییرات Snapshotها و مدت نگهداری نسخه‌ها نیز باید در برنامه ظرفیت لحاظ شوند.
درصد ثابت و یکسانی برای تمام کلاسترها پیشنهاد نمی‌شود. فضای عملیاتی موردنیاز را با توجه به معماری، توزیع مصرف، سناریوی خرابی و زمان افزودن تجهیزات تعیین کنید. میانگین مصرف کل کلاستر هم نباید جای بررسی گره‌ها و دیسک‌های پرمصرف را بگیرد.
ظرفیت دیسک در OpenStack چگونه با مصرف واقعی ارتباط دارد؟
در محیط دارای Thin Provisioning، اندازه منطقی Volumeها ممکن است با فضای فیزیکی مصرف‌شده تفاوت داشته باشد. Cinder تنظیماتی برای مدیریت تخصیص ظرفیت دارد؛ اما میزان تخصیص مجاز و رفتار زمان‌بندی به درایور، گزارش Backend و پیکربندی محیط وابسته است.
اگر مصرف واقعی به تعهدات نزدیک شود، تیم زیرساخت باید پیش از کمبود فضا اقدام کند. مقدار ظرفیت تخصیص‌یافته، مصرف واقعی و روند رشد را کنار هم پایش کنید. جزئیات در مستندات رسمی تخصیص ظرفیت در Cinder آمده است.
برای برنامه‌ریزی رشد چه اطلاعاتی جمع‌آوری کنیم؟
- روند رشد داده برای هر سرویس و پروژه سازمانی.
- سیاست محافظت از داده و مصرف هر Pool.
- مصرف Snapshotها و سیاست نگهداری آن‌ها.
- ظرفیت موردنیاز هنگام خرابی و بازسازی.
- زمان خرید، نصب و ورود تجهیزات جدید به سرویس.
- حد هشدارها و مسئول اقدام پس از هر هشدار.
خروجی این بررسی باید یک برنامه قابل اجرا باشد: چه زمانی ظرفیت جدید لازم می‌شود، چه کسی مسئول تأمین آن است و چه نشانه‌ای اقدام را آغاز می‌کند. این برنامه را با داده‌های واقعی محیط بازبینی کنید.
برای بررسی مسیر طراحی و توسعه زیرساخت سازمان، صفحهٔ خدمات ابر خصوصی دواپس ایران را ببینید.
منابع رسمی در ۸ اکتبر ۲۰۲۶ بررسی شدند. برای اجرا، مستندات نسخه نصب‌شده ملاک است.
نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *
نظر دهید تعداد کاراکتر مانده: 300