راه‌اندازی Erasure Coding در Ceph: کاهش هزینه ذخیره‌سازی در مقابل Replication سه‌برابری روی سرور اختصاصی
وقتی یک کلاستر Ceph با پول replication سه‌برابری (size=3) رشد می‌کند، هزینهٔ فضای خام هم با همان نسبت رشد می‌کند؛ از هر ۳ ترابایت دیسک خام فقط ۱ ترابایت فضای قابل استفاده به دست می‌آید. Erasure Coding همین نسبت را با تقسیم داده به چند قطعه و افزودن قطعات parity عوض می‌کند و در عمل فضای مفید را تا بیش از دو برابر افزایش می‌دهد، بدون این‌که سطح تحمل خرابی به‌طور قابل‌توجهی پایین‌تر بیاید. این مقاله نحوهٔ ساخت profile و pool از نوع erasure در Ceph، تاثیر آن روی فضای ذخیره‌سازی و کارایی، و معیارهای انتخاب سرور اختصاصی مناسب برای اجرای آن را پوشش می‌دهد.
Replication سه‌برابری در Ceph و دلیل بالا بودن هزینهٔ آن
در حالت پیش‌فرض، poolهای replicated در Ceph با size=3 و min_size=2 ساخته می‌شوند؛ یعنی هر object به‌صورت کامل سه بار، روی سه OSD (معمولاً روی سه host مجزا) ذخیره می‌شود. اگر یک کلاستر ۳۰۰ ترابایت فضای خام داشته باشد، فضای واقعاً قابل استفاده برای داده حدود ۱۰۰ ترابایت است؛ باقی فضا صرف نسخه‌های تکراری می‌شود.
این مدل دو مزیت دارد: بازیابی سریع (برای ترمیم یک OSD خراب فقط کپی کردن یک نسخهٔ کامل از یک host دیگر لازم است) و تحمل خرابی تا دو OSD هم‌زمان. اما در مقیاس چند صد ترابایتی یا پتابایتی، هزینهٔ ۲۰۰ درصدی overhead روی قیمت دیسک، رک و برق به‌شدت سنگین می‌شود.
Erasure Coding چیست و k و m چه معنایی دارند
در pool از نوع erasure، هر object به k قطعهٔ داده و m قطعهٔ parity تقسیم می‌شود. این k+m قطعه روی OSDهای مختلف (و معمولاً hostهای مختلف) پخش می‌شوند. برای بازخوانی داده فقط به k قطعه نیاز است؛ قطعات parity زمانی به کار می‌آیند که یک یا چند قطعهٔ داده از دست رفته باشد.
نسبت فضای مفید از فرمول k/(k+m) به دست می‌آید و تعداد خرابی قابل تحمل برابر m است. مثلاً در پروفایل k=4, m=2، از هر ۶ واحد فضای خام، ۴ واحد قابل استفاده است (overhead فقط ۵۰ درصد) و کلاستر تا ۲ OSD خرابی هم‌زمان را تحمل می‌کند؛ یعنی همان سطح تحمل خرابی replication سه‌برابری، با نصف هزینهٔ فضا.
محاسبات encode و decode توسط پلاگین‌هایی مثل jerasure یا isa انجام می‌شود که روی CPU هر OSD اجرا می‌شوند، نه یک سرویس جداگانه.
مقایسه فضای ذخیره‌سازی: Replication x3 در برابر پروفایل‌های Erasure Coding
جدول زیر چند پروفایل رایج را از نظر overhead، ظرفیت مفید و تعداد خرابی قابل تحمل مقایسه می‌کند. همهٔ اعداد برای ۳۰۰ ترابایت فضای خام محاسبه شده‌اند.
| پروفایل | Overhead | ظرفیت مفید از فضای خام | ظرفیت مفید (۳۰۰TB خام) | خرابی هم‌زمان قابل تحمل |
|---|---|---|---|---|
| Replication x3 | ۳x | ۳۳٪ | ۱۰۰ ترابایت | ۲ OSD |
| Erasure Coding k=4, m=2 | ۱.۵x | ۶۶٪ | ۲۰۰ ترابایت | ۲ OSD |
| Erasure Coding k=6, m=3 | ۱.۵x | ۶۶٪ | ۲۰۰ ترابایت | ۳ OSD |
| Erasure Coding k=8, m=3 | ۱.۳۷۵x | ۷۳٪ | ۲۱۸ ترابایت | ۳ OSD |
نکتهٔ مهم جدول: پروفایل k=8, m=3 هم ظرفیت مفید بیشتری نسبت به k=4, m=2 می‌دهد و هم یک واحد تحمل خرابی بیشتر از replication سه‌برابری دارد. هزینهٔ این مزیت، تعداد host بیشتری است که برای رعایت crush-failure-domain=host لازم دارید (حداقل ۱۱ host برای این پروفایل).
راه‌اندازی عملی: ساخت erasure code profile و pool در Ceph
این بخش فرض می‌کند یک کلاستر Ceph با Cephadm از قبل راه‌اندازی شده و OSDها آماده‌اند؛ در ادامه فقط erasure code profile و pool جدید روی همین کلاستر ساخته می‌شود.
ساخت profile
ceph osd erasure-code-profile set ec-4-2 \
k=4 m=2 \
crush-failure-domain=host \
plugin=jerasure \
technique=reed_sol_van
پارامتر crush-failure-domain=host به Ceph می‌گوید قطعات یک object را حتماً روی hostهای مجزا پخش کند، نه فقط OSDهای مجزا روی یک سرور. برای این پروفایل حداقل ۶ host مستقل لازم است (k+m)؛ در عمل بهتر است یک یا دو host بیشتر از این حداقل در کلاستر باشد تا در زمان خرابی یا نگهداری، rebalance بدون گیر کردن ادامه پیدا کند.
ساخت pool با این profile
ceph osd pool create ec_pool 128 128 erasure ec-4-2
ceph osd pool set ec_pool allow_ec_overwrites true
ceph osd pool application enable ec_pool rbd
تنظیم allow_ec_overwrites فقط روی OSDهای bluestore کار می‌کند و برای استفاده‌هایی لازم است که نیاز به partial overwrite دارند، مثل RBD یا CephFS. برای poolهای RGW که objectها immutable نوشته می‌شوند، این تنظیم معمولاً لازم نیست.
بررسی وضعیت pool
ceph osd pool ls detail
ceph df
خروجی ceph df ظرفیت MAX AVAIL را بر اساس همین نسبت k/(k+m) محاسبه و نشان می‌دهد، بنابراین بعد از ساخت pool بلافاصله می‌توان عدد واقعی فضای مفید را دید.
تاثیر Erasure Coding روی کارایی
محاسبهٔ parity هنگام نوشتن و بازسازی قطعات هنگام recovery، بار CPU بیشتری روی هر OSD می‌گذارد نسبت به replication. برای I/O تصادفی و کوچک — مثل دیسک‌های بوت ماشین مجازی یا دیتابیس‌ها روی RBD — این overhead در latency قابل احساس است.
روند recovery هم فرق دارد. در replication، بازسازی یک OSD خراب یعنی کپی یک نسخهٔ کامل از یک host دیگر. در erasure coding، بازسازی هر قطعهٔ ازدست‌رفته نیاز به خواندن حداقل k قطعهٔ باقی‌مانده از k host مختلف دارد؛ یعنی ترافیک شبکهٔ بیشتری بین نودهای بیشتری جابه‌جا می‌شود.
به همین دلیل Erasure Coding برای workloadهایی که عمدتاً sequential و read-heavy هستند — object storage روی RGW، بکاپ، آرشیو رسانه، لاگ — انتخاب بهتری است تا برای workloadهای latency-sensitive با I/O تصادفی کوچک.
چه زمانی Erasure Coding را انتخاب کنیم
برای poolهای RGW، بکاپ و آرشیو که حجم بالا و دسترسی کمتر دارند، Erasure Coding معمولاً هزینه را به‌طور قابل‌توجهی پایین می‌آورد بدون این‌که نیاز واقعی تغییر کند. برای RBD یا CephFS با بار I/O تصادفی بالا (دیتابیس، دیسک بوت ماشین مجازی)، replication سه‌برابری همچنان گزینهٔ امن‌تر از نظر latency است.
در عمل خیلی از کلاسترها هر دو را هم‌زمان استفاده می‌کنند: یک pool replicated برای RBD و یک pool erasure برای RGW، روی همان مجموعه OSDها.
انتخاب سرور اختصاصی مناسب برای اجرای Ceph با Erasure Coding
قبل از انتخاب سخت‌افزار، تعداد host باید با پروفایل EC هماهنگ باشد: برای k=4, m=2 حداقل ۶ host مستقل لازم است، و بهتر است ۷ یا ۸ host در دسترس باشد تا crush-failure-domain=host بدون گیر کردن rebalance کار کند. برای جمع‌بندی کلی‌تر دربارهٔ تناسب CPU، RAM و دیسک NVMe با بار کاری ذخیره‌سازی، راهنمای انتخاب سرور اختصاصی برای دیتابیس هم می‌تواند مفید باشد.
روی هر سرور این موارد اهمیت دارد:
- CPU: محاسبهٔ encode/decode روی هر OSD اجرا می‌شود، پس هر هسته باید بار بیشتری نسبت به یک OSD replicated تحمل کند. برای چند OSD در هر سرور، تعداد هسته باید با فاصلهٔ بیشتری از حداقل توصیه‌شدهٔ Ceph انتخاب شود.
- RAM: علاوه بر cache معمول bluestore، در زمان recovery حافظهٔ بیشتری برای buffer کردن قطعات در حال بازسازی مصرف می‌شود.
- دیسک: NVMe برای OSD و به‌خصوص برای WAL/DB، چون در erasure coding حجم I/O مربوط به recovery بین hostهای بیشتری پخش می‌شود و تاخیر هر دیسک مستقیم روی زمان rebuild اثر می‌گذارد.
- شبکه: حداقل 10GbE، و برای کلاسترهای بزرگ‌تر 25GbE، چون ترافیک recovery در erasure coding بین k+m سرور جابه‌جا می‌شود، نه فقط بین دو سرور مثل replication.
برای تامین این مشخصات، سرور اختصاصی روی زیرساخت فیزیکی مناسب‌تر از VPS اشتراکی است، چون کنترل کامل روی تعداد و نوع دیسک، پهنای باند شبکه و تخصیص کامل CPU به OSDها را می‌دهد. سرورهای اختصاصی آریانت را می‌توانید با پیکربندی دلخواه از نظر CPU، RAM و دیسک NVMe، متناسب با تعداد OSD و پروفایل EC مورد نظرتان، از صفحهٔ سرور اختصاصی آریانت انتخاب کنید.
جمع‌بندی
Erasure Coding در Ceph هزینهٔ فضای خام را نسبت به replication سه‌برابری تا بیش از نصف کاهش می‌دهد و در پروفایل‌هایی مثل k=8, m=3 حتی تحمل خرابی بیشتری هم فراهم می‌کند. هزینهٔ این صرفه‌جویی، بار CPU بیشتر روی هر OSD، ترافیک شبکهٔ بیشتر در recovery و افت کارایی در I/O تصادفی کوچک است.
قبل از انتقال یک pool واقعی، پروفایل مورد نظر را روی یک کلاستر آزمایشی کوچک با همان تعداد host که در production استفاده خواهید کرد تست کنید؛ هم رفتار recovery و هم latency واقعی workload را می‌توان قبل از تعهد به یک پروفایل مشخص، با عدد واقعی سنجید.
