Ceph Storage چیست و چگونه کار می‌کند؟

وقتی حجم اطلاعات یک مجموعه کوچک است، استفاده از چند هارد یا SSD روی یک سرور معمولا مشکل خاصی ایجاد نمی‌کند. اما با بزرگ‌تر شدن زیرساخت، شرایط تغییر می‌کند. ممکن است تعداد زیادی ماشین مجازی روی چندین سرور اجرا شوند، حجم اطلاعات به چند ترابایت یا حتی چند پتابایت برسد و از طرف دیگر، خرابی یک دیسک یا سرور نباید باعث از دسترس خارج شدن اطلاعات شود.

در چنین شرایطی، قرار دادن تمام داده‌ها روی یک سرور یا یک دستگاه ذخیره‌سازی مرکزی همیشه بهترین راهکار نیست. یکی از راه‌های حل این مسئله، توزیع کردن فضای ذخیره‌سازی میان چندین سرور است؛ روشی که به آن ذخیره‌سازی توزیع‌شده گفته می‌شود.

Ceph یکی از شناخته‌شده‌ترین راهکارها برای این نوع معماری است. Ceph می‌تواند دیسک‌های موجود در چندین سرور را به یک مجموعه واحد تبدیل کند و اطلاعات را بر اساس سیاستی مشخص میان آن‌ها توزیع کند. در صورت خرابی یک بخش از زیرساخت نیز می‌تواند اطلاعات را از بخش‌های دیگر بازیابی کند.

نکته مهم این است که Ceph صرفا مجموعه‌ای از هاردها نیست که به یکدیگر متصل شده باشند. این سامانه باید محل قرارگیری داده‌ها را مدیریت کند، خرابی‌ها را تشخیص دهد، اطلاعات را در بخش‌های مختلف توزیع کند و در صورت نیاز، نسخه‌های اضافی یا اطلاعات لازم برای بازیابی را ایجاد کند. همین موضوع معماری آن را نسبت به استفاده مستقیم از یک دیسک بسیار پیچیده‌تر می‌کند.

Ceph Storage چیست؟

Ceph یک سامانه ذخیره‌سازی توزیع‌شده و متن‌باز است که می‌تواند فضای ذخیره‌سازی چندین سرور را در قالب یک مجموعه یکپارچه در اختیار برنامه‌ها قرار دهد.

در یک روش معمول، اگر روی یک سرور چند SSD داشته باشیم، برنامه‌ها مستقیما از همان دیسک‌های محلی استفاده می‌کنند. اگر بخواهیم ظرفیت بیشتری داشته باشیم، باید دیسک‌های بیشتری به همان سرور اضافه کنیم یا سرور دیگری را وارد زیرساخت کنیم و راهی برای استفاده از فضای آن پیدا کنیم.

Ceph این مدل را تغییر می‌دهد. چند سرور می‌توانند در کنار یکدیگر یک مجموعه ذخیره‌سازی تشکیل دهند و دیسک‌های هرکدام بخشی از ظرفیت کلی را تامین کنند. داده‌ها نیز بر اساس قوانین مشخص میان این منابع توزیع می‌شوند.

مزیت دیگر، امکان ایجاد افزونگی است. برای مثال می‌توان سامانه را طوری تنظیم کرد که از یک داده بیش از یک نسخه نگهداری شود. در این صورت، خرابی یک دیسک یا حتی یک سرور لزوما باعث از بین رفتن اطلاعات نمی‌شود.

Ceph همچنین فقط برای یک نوع استفاده طراحی نشده است. می‌توان از آن برای ارائه فضای بلوکی به ماشین‌های مجازی، ایجاد یک سیستم فایل توزیع‌شده یا ذخیره‌سازی اشیا استفاده کرد. به همین دلیل، در زیرساخت‌های ابری، محیط‌های مجازی‌سازی و سامانه‌های بزرگ ذخیره‌سازی کاربرد زیادی دارد.

Ceph چگونه کار می‌کند؟

برای فهم نحوه کار Ceph، بهتر است به جای شروع از اصطلاحات پیچیده، ابتدا یک مثال ساده داشته باشیم.

فرض کنید سه سرور داریم که هرکدام چند دیسک در اختیار دارند. می‌خواهیم این دیسک‌ها را طوری مدیریت کنیم که برنامه‌ها بتوانند از مجموع فضای آن‌ها استفاده کنند و خرابی یک دیسک باعث از بین رفتن اطلاعات نشود.

وقتی برنامه‌ای اطلاعاتی را ذخیره می‌کند، Ceph ابتدا باید مشخص کند این اطلاعات متعلق به کدام بخش از فضای ذخیره‌سازی است. سپس باید محل مناسب برای نگهداری آن را پیدا کند. اگر برای آن داده چند نسخه در نظر گرفته شده باشد، محل نسخه‌های دیگر نیز مشخص می‌شود.

در نهایت، اطلاعات توسط سرویس‌های مخصوص روی دیسک‌های مربوط به آن سرورها نوشته می‌شوند.

اگر بخواهیم این مسیر را به شکل ساده نمایش دهیم، می‌توان گفت:

Client → RADOS → CRUSH → OSD → Disk

هرکدام از این اصطلاحات بخشی از یک فرآیند هستند که در ادامه توضیح داده می‌شوند.

یکی از ویژگی‌های مهم Ceph این است که برای تعیین محل هر داده، به یک کنترلر مرکزی که تمام اطلاعات را در اختیار داشته باشد وابسته نیست. همین موضوع کمک می‌کند با افزایش تعداد سرورها و دیسک‌ها، سامانه بتواند در مقیاس بزرگ‌تری فعالیت کند.

معماری Ceph چگونه ساخته شده است؟

Ceph از چند جزء اصلی تشکیل می‌شود که هرکدام وظیفه مشخصی دارند. برای درک بهتر معماری آن، باید بدانیم هرکدام از این اجزا چه مشکلی را حل می‌کنند.

RADOS چیست؟

RADOS هسته اصلی Ceph است. این بخش مسئول نگهداری داده‌ها در میان منابع مختلف و مدیریت عملیات مربوط به آن‌هاست.

در واقع، سرویس‌های مختلفی که Ceph ارائه می‌کند در لایه زیرین به RADOS متکی هستند. RADOS می‌تواند داده‌ها را میان چندین سرور توزیع کند، نسخه‌های اضافی آن‌ها را مدیریت کند و هنگام خرابی بخشی از زیرساخت، فرآیند بازیابی را انجام دهد.

برای همین، اگر بخواهیم معماری Ceph را خیلی ساده تصور کنیم، RADOS را می‌توان پایه اصلی سامانه دانست و سرویس‌های دیگر را لایه‌هایی در نظر گرفت که امکانات متفاوتی را روی این پایه ارائه می‌کنند.

OSD در Ceph چیست؟

OSD یکی از مهم‌ترین اجزای Ceph است و در واقع همان بخشی است که با فضای ذخیره‌سازی سروکار دارد.

هر OSD یک سرویس نرم‌افزاری است که معمولا روی یک دیسک یا بخشی مشخص از فضای ذخیره‌سازی اجرا می‌شود. این سرویس مسئول خواندن و نوشتن داده، نگهداری اطلاعات، ارتباط با OSDهای دیگر و مشارکت در فرآیندهایی مانند بازیابی اطلاعات و توزیع مجدد داده‌هاست.

بنابراین OSD را نباید با خود دیسک یکی دانست.

برای مثال، فرض کنید یک سرور چهار SSD دارد. می‌توان روی هرکدام از این SSDها یک OSD ایجاد کرد. در این حالت یک سرور چهار OSD خواهد داشت، در حالی که همچنان فقط یک سرور داریم.

وقتی Ceph تصمیم می‌گیرد بخشی از داده را روی یک OSD قرار دهد، در نهایت این سرویس است که اطلاعات را روی فضای ذخیره‌سازی مربوط به خود می‌نویسد.

به همین دلیل، OSD را می‌توان واسطه اصلی میان Ceph و دیسک‌های فیزیکی دانست.

Monitor در Ceph چیست؟

Monitor یا ناظر وظیفه دارد اطلاعات مهم مربوط به وضعیت مجموعه را نگهداری و بین اجزای Ceph هماهنگ کند.

برای مثال، Ceph باید بداند چه سرورهایی در مجموعه حضور دارند، کدام OSDها فعال هستند، وضعیت کلی اجزا چگونه است و ساختار فعلی مجموعه چیست. Monitorها این اطلاعات را مدیریت می‌کنند.

نکته مهم این است که Monitor مسئول انجام تمام عملیات خواندن و نوشتن نیست. اگر هر درخواست داده مجبور بود ابتدا از Monitor عبور کند، خود Monitor به گلوگاه سامانه تبدیل می‌شد.

در عوض، Monitor بیشتر نقش مرجع وضعیت مجموعه را دارد. معمولا چند Monitor در یک مجموعه اجرا می‌شوند تا خرابی یکی از آن‌ها باعث از کار افتادن کل سیستم نشود.

Manager در Ceph چیست؟

Manager یا مدیر Ceph بیشتر وظیفه مدیریت، پایش و ارائه اطلاعات مربوط به عملکرد مجموعه را بر عهده دارد.

برای مثال، مدیر سیستم باید بتواند ببیند چند دیسک و OSD در حال فعالیت هستند، وضعیت کلی مجموعه چگونه است، چه میزان فضا استفاده شده و آیا مشکلی در عملکرد اجزا وجود دارد یا نه.

Manager اطلاعات لازم برای این کار را جمع‌آوری می‌کند و قابلیت‌هایی مانند داشبورد مدیریتی و ابزارهای پایش را در اختیار مدیر زیرساخت قرار می‌دهد.

بنابراین تفاوت ساده این دو جزء را می‌توان این‌طور بیان کرد:

Monitor وضعیت و اطلاعات حیاتی مجموعه را نگهداری می‌کند، در حالی که Manager بیشتر روی مدیریت و پایش آن تمرکز دارد.

MDS در Ceph چیست؟

MDS یا Metadata Server فقط زمانی مورد نیاز است که از Ceph برای ایجاد یک سیستم فایل استفاده کنیم.

برای درک نقش آن، فرض کنید در یک سیستم فایل معمولی، فایلی به نام video.mp4 داخل پوشه‌ای مشخص قرار دارد. سیستم‌عامل علاوه بر محتوای فایل، باید اطلاعاتی مانند نام فایل، مسیر آن، پوشه مربوط، سطح دسترسی و سایر مشخصات را نیز مدیریت کند. این اطلاعات را Metadata یا فراداده می‌نامیم.

در CephFS،مفهوم MDS مسئول مدیریت همین اطلاعات مربوط به فایل‌ها و پوشه‌هاست.

خود محتوای فایل توسط MDS نگهداری نمی‌شود. اطلاعات اصلی همچنان در زیرساخت ذخیره‌سازی Ceph قرار می‌گیرد و MDS مشخص می‌کند ساختار فایل‌ها و پوشه‌ها چگونه است و دسترسی به آن‌ها چگونه مدیریت شود.

به همین دلیل، MDS را می‌توان بخش مدیریتی سیستم فایل دانست، نه محلی برای ذخیره خود فایل‌ها.

CRUSH در Ceph چیست و چرا اهمیت دارد؟

حالا که نقش اجزای اصلی را می‌دانیم، باید ببینیم Ceph چگونه تصمیم می‌گیرد یک داده دقیقا در کجا قرار بگیرد.

این وظیفه بر عهده الگوریتمی به نام CRUSH است.

CRUSH با توجه به ساختار مجموعه و قوانینی که برای آن تعریف شده، محل مناسب قرارگیری داده را محاسبه می‌کند. بنابراین Ceph لازم نیست برای هر درخواست، یک سرور مرکزی داشته باشد که در پاسخ بگوید «این داده روی فلان دیسک قرار دارد».

یکی از مزیت‌های این روش، امکان تعیین نحوه توزیع داده است.

فرض کنید سه نسخه از یک داده داریم و سه سرور در اختیارمان است. می‌توان قانون را طوری تنظیم کرد که هر نسخه روی یک سرور متفاوت قرار بگیرد. در این صورت اگر یکی از سرورها از کار بیفتد، دو نسخه دیگر همچنان در دسترس هستند.

حتی می‌توان قوانین دقیق‌تری تعریف کرد. برای مثال اگر سرورها در چند رک قرار گرفته باشند، می‌توان کاری کرد که نسخه‌های یک داده در رک‌های متفاوت قرار بگیرند. در این حالت خرابی یک رک نیز نباید همه نسخه‌های اطلاعات را همزمان از بین ببرد.

بنابراین CRUSH فقط یک روش برای پیدا کردن محل داده نیست؛ یکی از ابزارهای اصلی Ceph برای توزیع هوشمندانه داده و مدیریت تحمل خرابی است.

عملکرد Ceph نتیجه عملکرد کل معماری است؛ دیسک فقط یکی از اجزای این معماری محسوب می‌شود.

داده‌ها در Ceph چگونه توزیع می‌شوند؟

برای درک این قسمت باید با سه مفهوم Object، Pool و Placement Group آشنا شویم. این اصطلاحات در معماری Ceph اهمیت زیادی دارند، اما مفهوم آن‌ها را می‌توان بدون پیچیده کردن بحث توضیح داد.

Object در Ceph چیست؟

در پایین‌ترین لایه Ceph، داده‌ها به واحدهایی به نام Object تقسیم می‌شوند.

Object را می‌توان یک قطعه منطقی از اطلاعات در نظر گرفت که Ceph می‌تواند آن را ذخیره و مدیریت کند. این مفهوم با فایل در سیستم‌عامل یکسان نیست.

برای مثال، کاربر ممکن است یک فایل بزرگ را ببیند، اما در لایه زیرین، Ceph آن اطلاعات را به واحدهای کوچک‌تری تقسیم کند و آن‌ها را در قالب Objectهای مختلف نگهداری کند.

دلیل استفاده از این مدل، ساده‌تر شدن توزیع اطلاعات میان تعداد زیادی دیسک و سرور است.

Pool در Ceph چیست؟

Pool را می‌توان یک فضای منطقی برای نگهداری Objectها در نظر گرفت.

مدیر سیستم می‌تواند چند Pool ایجاد کند و برای هرکدام سیاست متفاوتی تعیین کند. مثلا ممکن است یک Pool برای ماشین‌های مجازی و Pool دیگری برای اطلاعاتی با حجم بالا در نظر گرفته شود.

مهم‌تر اینکه تنظیماتی مانند تعداد نسخه‌های اطلاعات یا روش محافظت از آن‌ها نیز به Pool مربوط می‌شود.

بنابراین Pool فقط یک پوشه یا محل ذخیره‌سازی ساده نیست؛ مجموعه‌ای از قوانین را برای نحوه نگهداری داده‌ها مشخص می‌کند.

Placement Group یا PG چیست؟

Placement Group که معمولا به اختصار PG نامیده می‌شود، یک لایه میانی بین Object و OSD است. به زبان ساده، PG یک تگ و شناسنامه برای فایل است و نشان می‌دهد که آن آبجکت قرار است در کدام گروه داده قرار بگیرد.

اگر Ceph قرار بود محل هر Object را به‌صورت مستقیم مشخص کند، مدیریت میلیون‌ها یا میلیاردها Object بسیار پیچیده می‌شد. PGها این مشکل را حل می‌کنند.

هر Object ابتدا به یک PG مشخص تعلق می‌گیرد و سپس Ceph مشخص می‌کند آن PG باید روی کدام OSDها قرار داشته باشد.

در نتیجه مسیر کلی را می‌توان این‌طور نمایش داد:

Object → Pool → PG → OSD

این ساختار یکی از دلایل مهمی است که Ceph می‌تواند تعداد بسیار زیادی داده را در میان تعداد زیادی دیسک مدیریت کند.

Ceph چگونه داده را بین چند دیسک توزیع می‌کند؟

فرض کنیم یک فایل یا داده جدید در اختیار Ceph قرار گرفته است.

ابتدا این داده در قالب Objectهای مربوط به خود مدیریت می‌شود. هر Object به یک Pool تعلق دارد و سپس در یک PG قرار می‌گیرد.

در مرحله بعد، CRUSH بر اساس قوانین تعریف‌شده مشخص می‌کند PG موردنظر باید روی کدام OSDها قرار بگیرد.

اگر Pool به شکلی تنظیم شده باشد که سه نسخه از اطلاعات نگهداری شود، PG مربوطه روی سه OSD قرار خواهد گرفت. این OSDها می‌توانند روی سه سرور مختلف باشند.

پس داده مستقیما به یک دیسک خاص «قفل» نمی‌شود. Ceph یک لایه منطقی میان داده و سخت‌افزار ایجاد می‌کند که به آن اجازه می‌دهد با تغییر وضعیت مجموعه، داده‌ها را نیز دوباره توزیع کند.

برای مثال، اگر یک سرور جدید به مجموعه اضافه شود، Ceph می‌تواند بخشی از داده‌ها را به منابع جدید منتقل کند تا بار میان سرورها متعادل‌تر شود.

چرا سرعت دیسک در Ceph با سرعت خام آن یکسان نیست؟

یکی از مهم‌ترین نکاتی که هنگام استفاده از Ceph باید در نظر گرفت، تفاوت میان سرعت خود دیسک و عملکرد کل مجموعه است.

فرض کنید یک NVMe را مستقیما روی یک سرور نصب کرده‌ایم و با یک ابزار آزمایش سرعت، عملکرد آن را اندازه گرفته‌ایم. ممکن است نتیجه بسیار خوبی به دست بیاید.

اما اگر همان NVMe را داخل یک مجموعه Ceph قرار دهیم، نمی‌توان انتظار داشت یک ماشین مجازی یا برنامه کاربردی دقیقا همان عدد را دریافت کند.

دلیل این موضوع این نیست که Ceph سرعت فیزیکی دیسک را کم می‌کند. دیسک همچنان همان سخت‌افزار قبلی است. تفاوت در این است که هنگام استفاده از Ceph، درخواست ذخیره‌سازی دیگر فقط بین برنامه و همان دیسک رد و بدل نمی‌شود.

در اینجا سرویس OSD باید درخواست را پردازش کند، Ceph باید محل داده را مشخص کرده باشد و در صورت استفاده از چند نسخه، اطلاعات باید روی چند OSD نوشته شود. اگر این OSDها روی سرورهای مختلف باشند، شبکه نیز وارد مسیر می‌شود.

بنابراین نتیجه نهایی حاصل عملکرد تمام این اجزاست.

سربار Ceph چگونه روی عملکرد تاثیر می‌گذارد؟

هر قابلیت اضافی در یک سیستم توزیع‌شده نیازمند مقداری پردازش و ارتباط است.

در یک دیسک محلی، مسیر یک درخواست I/O نسبتا کوتاه است. اما در Ceph، علاوه بر دسترسی به دیسک، عملیات دیگری نیز انجام می‌شود.

OSD باید درخواست را پردازش کند، داده را در محل مناسب قرار دهد و در صورت وجود نسخه‌های اضافی، با OSDهای دیگر هماهنگ شود. Ceph همچنین باید وضعیت مجموعه را کنترل کند و هنگام تغییر شرایط، داده‌ها را دوباره توزیع یا بازیابی کند.

این عملیات به پردازنده، حافظه و شبکه نیاز دارند.

بنابراین اگر یک SSD در حالت مستقیم مثلا توانایی تعداد بسیار زیادی عملیات در ثانیه را داشته باشد، این عدد به‌تنهایی نمی‌تواند عملکرد همان SSD در یک مجموعه Ceph را پیش‌بینی کند.

در واقع، Ceph در ازای قابلیت‌هایی مانند افزونگی، مقیاس‌پذیری و تحمل خرابی، عملیات بیشتری نسبت به یک دیسک محلی انجام می‌دهد.

شبکه چه تاثیری روی عملکرد Ceph دارد؟

شبکه در Ceph اهمیت بسیار بیشتری از یک Storage محلی دارد.

در یک سرور معمولی، اگر برنامه و دیسک روی همان سیستم باشند، اطلاعات برای رسیدن به دیسک نیازی به عبور از شبکه ندارند.

اما در Ceph ممکن است ماشین مجازی روی یک سرور اجرا شود و اطلاعات آن روی دیسکی قرار داشته باشد که به سرور دیگری متصل است. در چنین حالتی، شبکه بخشی از مسیر دسترسی به اطلاعات خواهد بود.

از طرف دیگر، اگر داده چند نسخه داشته باشد، اطلاعات باید میان OSDهای مختلف نیز منتقل شود. این موضوع می‌تواند ترافیک قابل توجهی ایجاد کند.

بنابراین عواملی مانند سرعت کارت شبکه، ظرفیت ارتباط میان سرورها، تاخیر شبکه، شلوغی مسیر و معماری کلی شبکه روی عملکرد Ceph تاثیر مستقیم دارند.

به همین دلیل، استفاده از NVMeهای سریع بدون توجه به شبکه می‌تواند نتیجه ناامیدکننده‌ای داشته باشد.

ممکن است دیسک از نظر سخت‌افزاری توانایی بسیار بالایی داشته باشد، اما شبکه اجازه ندهد این توانایی در اختیار برنامه قرار بگیرد.

Replication چگونه روی عملکرد تاثیر می‌گذارد؟

یکی از روش‌های محافظت از اطلاعات در Ceph، نگهداری چند نسخه از داده است که به آن Replication گفته می‌شود.

فرض کنیم یک داده باید سه نسخه داشته باشد. در این حالت Ceph فقط یک بار اطلاعات را روی یک دیسک نمی‌نویسد. باید نسخه‌های دیگر نیز روی OSDهای مناسب ایجاد شوند.

این کار امنیت و دسترس‌پذیری اطلاعات را افزایش می‌دهد، اما طبیعتا عملیات بیشتری نسبت به یک Write ساده ایجاد می‌کند.

اگر سه OSD روی سه سرور مختلف قرار داشته باشند، شبکه نیز برای انتقال اطلاعات میان آن‌ها درگیر خواهد شد.

پس Replication یک هزینه عملکردی دارد، اما در مقابل، امکان ادامه فعالیت سیستم در صورت خرابی بخشی از زیرساخت را فراهم می‌کند.

به همین دلیل نمی‌توان Replication را صرفا یک عامل منفی دانست. این قابلیت در واقع یکی از دلایل اصلی استفاده از Ceph است.

Erasure Coding چه تاثیری روی عملکرد دارد؟

روش دیگری که Ceph برای محافظت از داده‌ها ارائه می‌دهد، Erasure Coding یا کدگذاری حذف است.

در این روش، به جای اینکه چند نسخه کامل از اطلاعات نگهداری شود، داده به چند بخش تقسیم می‌شود و اطلاعات اضافی نیز برای بازیابی بخش‌های از دست رفته تولید می‌شود.

مزیت اصلی Erasure Coding این است که می‌تواند نسبت به نگهداری چند نسخه کامل، از فضای ذخیره‌سازی به شکل بهینه‌تری استفاده کند.

اما این روش محاسبات بیشتری نیاز دارد. هنگام نوشتن یا بازیابی اطلاعات، محاسبات مربوط به قطعات داده و اطلاعات بازیابی باید انجام شود.

به همین دلیل، Erasure Coding می‌تواند برای برخی Workloadها سربار بیشتری نسبت به Replication ایجاد کند و روی تاخیر عملیات تاثیر بگذارد.

در نتیجه، انتخاب میان این دو روش باید بر اساس نوع استفاده، اهمیت ظرفیت، میزان تحمل خرابی مورد نیاز و حساسیت برنامه به عملکرد انجام شود.

چرا Latency در Ceph اهمیت زیادی دارد؟

وقتی درباره سرعت Storage صحبت می‌کنیم، معمولا سرعت خواندن و نوشتن بر حسب MB/s یا GB/s اولین چیزی است که بررسی می‌شود. اما این عدد همیشه معیار مناسبی برای عملکرد واقعی نیست.

Latency یا تاخیر نشان می‌دهد یک درخواست چه مدت زمانی طول می‌کشد تا پاسخ بگیرد.

برای مثال، یک پایگاه داده ممکن است به جای انتقال فایل‌های بسیار بزرگ، تعداد زیادی درخواست کوچک ارسال کند. در چنین شرایطی، پایین بودن تاخیر می‌تواند مهم‌تر از حداکثر سرعت انتقال اطلاعات باشد.

معیارهایی مانند IOPS نیز اهمیت زیادی پیدا می‌کنند. IOPS نشان می‌دهد سیستم ذخیره‌سازی در یک بازه زمانی چه تعداد عملیات ورودی و خروجی را می‌تواند انجام دهد.

Queue Depth نیز مشخص می‌کند چه تعداد درخواست می‌توانند همزمان در صف پردازش قرار بگیرند.

به همین دلیل، برای ارزیابی Ceph باید عملکرد آن را متناسب با Workload واقعی سنجید. یک نتیجه خوب در آزمایش انتقال ترتیبی فایل، لزوما به معنای عملکرد خوب در اجرای ده‌ها ماشین مجازی یا یک پایگاه داده نیست.

تعداد OSDها چگونه روی عملکرد تاثیر می‌گذارد؟

یکی از مزایای Ceph این است که می‌تواند عملیات را میان تعداد زیادی OSD توزیع کند.

با افزایش تعداد OSDها، ظرفیت کلی مجموعه بیشتر می‌شود و امکان انجام همزمان عملیات نیز افزایش پیدا می‌کند. به همین دلیل اضافه کردن منابع در یک معماری درست می‌تواند توان کلی سیستم را افزایش دهد.

اما تعداد بیشتر دیسک همیشه به معنای سرعت بیشتر نیست.

اگر پردازنده سرورها توان کافی نداشته باشد، شبکه محدود باشد یا نوع Workload نتواند از موازی‌سازی استفاده کند، افزایش تعداد OSDها ممکن است تاثیر محدودی داشته باشد.

حتی ممکن است یک مجموعه بزرگ‌تر، به دلیل طراحی نامناسب، عملکرد ضعیف‌تری از یک مجموعه کوچک‌تر اما متعادل داشته باشد.

بنابراین برای افزایش عملکرد Ceph باید کل زیرساخت را در نظر گرفت، نه فقط تعداد دیسک‌ها را.

چرا NVMe سریع به‌تنهایی Ceph را سریع نمی‌کند؟

فرض کنید مجموعه‌ای از سریع‌ترین NVMeهای موجود را در اختیار داریم. آیا همین موضوع تضمین می‌کند Ceph نیز عملکرد فوق‌العاده‌ای خواهد داشت؟

خیر.

اگر شبکه بین سرورها کند باشد، بخشی از ظرفیت دیسک بلااستفاده می‌ماند. اگر پردازنده نتواند عملیات لازم را با سرعت کافی انجام دهد، باز هم دیسک نمی‌تواند تمام توان خود را نشان دهد.

همین موضوع درباره طراحی مجموعه و نوع Workload نیز صادق است.

برای مثال، Storage مورد استفاده برای ماشین‌های مجازی باید بتواند تعداد زیادی عملیات کوچک و همزمان را مدیریت کند. در مقابل، سامانه‌ای که برای نگهداری فایل‌های بزرگ طراحی شده، ممکن است بیشتر به سرعت انتقال ترتیبی اهمیت دهد.

پس نمی‌توان گفت «NVMe سریع داریم، بنابراین Ceph سریع است».

عبارت دقیق‌تر این است:

عملکرد Ceph نتیجه عملکرد کل معماری است؛ دیسک فقط یکی از اجزای این معماری محسوب می‌شود.

چه عواملی عملکرد Ceph را تعیین می‌کنند؟

برای ارزیابی عملکرد Ceph باید مجموعه‌ای از عوامل را همزمان بررسی کرد.

نوع دیسک، سرعت پایه، IOPS و تاخیر را تعیین می‌کند. NVMe معمولا برای بارهای کاری حساس به تاخیر و عملیات تصادفی عملکرد بسیار بهتری از HDD دارد.

پردازنده نیز برای اجرای سرویس‌های Ceph و پردازش عملیات مختلف اهمیت دارد. حافظه می‌تواند روی Cache و عملکرد داخلی سیستم تاثیر بگذارد.

شبکه نیز یکی از مهم‌ترین عوامل است؛ زیرا بخشی از ارتباط میان Clientها، OSDها و سرورهای مختلف از طریق شبکه انجام می‌شود.

روش محافظت از داده نیز اهمیت دارد. Replication و Erasure Coding هرکدام میزان متفاوتی از مصرف منابع و عملیات را ایجاد می‌کنند.

تعداد OSDها، تعداد سرورها، نحوه توزیع آن‌ها، تنظیمات Pool و نوع Workload نیز روی نتیجه نهایی تاثیر دارند.

در نتیجه نمی‌توان عملکرد یک مجموعه Ceph را با یک مشخصه سخت‌افزاری پیش‌بینی کرد.

Ceph چه نوع ذخیره‌سازی‌هایی ارائه می‌دهد؟

یکی از دلایل محبوبیت Ceph این است که یک زیرساخت واحد می‌تواند برای نیازهای مختلف مورد استفاده قرار بگیرد.

ذخیره‌سازی بلوکی با Ceph

Ceph می‌تواند فضای بلوکی را از طریق RBD در اختیار سیستم‌عامل‌ها و ماشین‌های مجازی قرار دهد.

از دید ماشین مجازی، این فضا می‌تواند مانند یک دیسک معمولی مورد استفاده قرار بگیرد، در حالی که اطلاعات در زیرساخت توزیع‌شده Ceph نگهداری می‌شوند.

این قابلیت یکی از دلایل اصلی استفاده از Ceph در محیط‌های مجازی‌سازی و Cloud است.

ذخیره‌سازی اشیا با Ceph

Ceph از طریق RADOS Gateway می‌تواند سرویس ذخیره‌سازی اشیا نیز ارائه دهد.

در این مدل، داده‌ها به صورت فایل و پوشه سنتی در اختیار برنامه قرار نمی‌گیرند؛ بلکه هر داده به عنوان یک شیء با شناسه و اطلاعات مربوط به خود نگهداری می‌شود.

این روش برای حجم زیادی از اطلاعات غیرساختاریافته مانند فایل‌های رسانه‌ای، آرشیو و نسخه‌های پشتیبان کاربرد دارد.

سیستم فایل Ceph

CephFS سیستم فایل توزیع‌شده Ceph است.

در این حالت کاربر یا برنامه می‌تواند با فایل‌ها و پوشه‌ها مانند یک سیستم فایل معمولی کار کند، اما اطلاعات در پشت صحنه میان منابع مختلف Ceph توزیع می‌شوند.

در این معماری، MDS اطلاعات مربوط به نام فایل‌ها، پوشه‌ها و سایر Metadata را مدیریت می‌کند و محتوای اصلی فایل‌ها در لایه ذخیره‌سازی توزیع‌شده قرار می‌گیرد.

مزایا و معایب Ceph چیست؟

Ceph زمانی بیشترین ارزش را دارد که یک مجموعه به ظرفیت بالا، توسعه‌پذیری و تحمل خرابی نیاز داشته باشد. با این حال، چنین قابلیتی بدون پیچیدگی به دست نمی‌آید.

مزایای Ceph

مهم‌ترین مزیت Ceph امکان افزایش تدریجی ظرفیت است. می‌توان سرورها و دیسک‌های بیشتری به مجموعه اضافه کرد و منابع جدید را وارد چرخه ذخیره‌سازی کرد.

افزونگی نیز مزیت مهم دیگری است. با تنظیم صحیح قوانین توزیع داده، خرابی یک دیسک، سرور یا حتی یک رک نباید باعث از بین رفتن تمام نسخه‌های اطلاعات شود.

Ceph همچنین به یک دستگاه ذخیره‌سازی مرکزی وابسته نیست و می‌تواند منابع چندین سرور را در یک مجموعه مدیریت کند.

پشتیبانی از ذخیره‌سازی بلوکی، اشیا و فایل نیز باعث می‌شود یک زیرساخت Ceph بتواند نیازهای مختلف را پوشش دهد.

محدودیت‌های Ceph

در مقابل، مدیریت Ceph به‌مراتب پیچیده‌تر از استفاده مستقیم از یک دیسک یا Storage محلی است.

طراحی شبکه اهمیت زیادی دارد و باید منابع پردازشی و ذخیره‌سازی متناسب با Workload انتخاب شوند.

پایش مداوم وضعیت مجموعه نیز ضروری است؛ زیرا خرابی دیسک، افزایش تاخیر، پر شدن فضا یا ایجاد مشکل در شبکه می‌تواند روی عملکرد کل سیستم تاثیر بگذارد.

همچنین Ceph در همه شرایط سریع‌تر از Storage محلی نیست. در بعضی Workloadها، مخصوصا زمانی که بیشترین عملکرد یک سرور مستقل اهمیت دارد، استفاده مستقیم از یک NVMe می‌تواند انتخاب بهتری باشد.

Ceph برای چه کاربردهایی مناسب است؟

Ceph بیشتر برای محیط‌هایی مناسب است که نیاز به Storage بزرگ، قابل توسعه و مقاوم در برابر خرابی دارند.

زیرساخت‌های Cloud و Private Cloud، محیط‌های مجازی‌سازی، مجموعه‌های بزرگ داده، ذخیره‌سازی بلوکی برای ماشین‌های مجازی، Object Storage و برخی زیرساخت‌های پشتیبان‌گیری از جمله کاربردهای مهم آن هستند.

در چنین محیط‌هایی، امکان اضافه کردن منابع و توزیع داده میان چندین سرور می‌تواند مزیت بزرگی باشد.

در مقابل، برای یک سرور کوچک که فقط به یک دیسک سریع نیاز دارد، استفاده از Ceph معمولا پیچیدگی غیرضروری ایجاد می‌کند.

آیا Ceph برای همه محیط‌ها انتخاب مناسبی است؟

انتخاب Ceph باید بر اساس نیاز واقعی انجام شود، نه صرفا مشخصات سخت‌افزار.

اگر هدف اصلی، رسیدن به بیشترین عملکرد ممکن از یک سرور مستقل باشد، استفاده مستقیم از NVMe یا SSD معمولا مسیر ساده‌تر و کم‌تاخیرتری دارد.

اما اگر قرار است اطلاعات میان چند سرور توزیع شوند، خرابی یک بخش باعث از دست رفتن داده نشود، ظرفیت در آینده افزایش پیدا کند و چندین ماشین مجازی یا سرویس از یک زیرساخت مشترک استفاده کنند، Ceph می‌تواند انتخاب بسیار مناسبی باشد.

در نتیجه، سوال درست این نیست که «Ceph سریع‌تر است یا یک NVMe؟» بلکه باید پرسید کدام معماری برای نیاز موردنظر مناسب‌تر است؟

یک NVMe می‌تواند در حالت مستقیم، عملکرد بسیار بالایی داشته باشد؛ اما Ceph مسئله متفاوتی را حل می‌کند. هدف آن فقط سرعت نیست، بلکه ترکیبی از ظرفیت، توزیع، افزونگی، مقیاس‌پذیری و دسترس‌پذیری است.

عملکرد Ceph به چه چیزی وابسته است؟

Ceph را نمی‌توان صرفا مجموعه‌ای از دیسک‌ها و درایوهای سریع دانست. عملکرد نهایی آن حاصل همکاری تمام اجزای زیرساخت است.

درایو مناسب، پردازنده کافی، حافظه مناسب، شبکه کم‌تاخیر، تعداد مناسب OSD، تنظیم صحیح Pool و انتخاب درست میان Replication و Erasure Coding همگی در نتیجه نهایی نقش دارند.

به همین دلیل، ممکن است دو مجموعه Ceph که از درایوهای مشابه استفاده می‌کنند، عملکرد کاملا متفاوتی داشته باشند. تفاوت می‌تواند از شبکه، پردازنده، نحوه توزیع داده یا حتی نوع Workload ناشی شود.

این موضوع مهم‌ترین نکته‌ای است که باید هنگام طراحی یا خرید زیرساخت Ceph در نظر گرفت: سرعت یک جزء، عملکرد کل مجموعه را تعیین نمی‌کند.

چرا Ceph با وجود سرعت کمتر، انتخاب منطقی‌تری است؟

اگر فقط سرعت خواندن و نوشتن اطلاعات مهم باشد، یک NVMe مستقل می‌تواند از فضای ذخیره‌سازی مبتنی بر Ceph سریع‌تر عمل کند. اما در زیرساخت‌های سروری، سرعت تنها معیار تصمیم‌گیری نیست. پایداری اطلاعات، تحمل خرابی و امکان افزایش ظرفیت نیز اهمیت زیادی دارند.

تفاوت NVMe مستقل با Ceph

یک NVMe مستقل می‌تواند سرعت بالایی ارائه دهد، اما اگر درایو خراب شود، دسترسی به اطلاعات ممکن است مختل شود. برای جلوگیری از این مشکل، باید از راهکارهایی مانند نسخه پشتیبان یا سازوکارهای افزونگی استفاده کرد.

Ceph رویکرد متفاوتی دارد. این فناوری داده‌ها را میان چند درایو یا سرور توزیع می‌کند و با استفاده از روش‌هایی مانند تکثیر داده‌ها، امکان ادامه فعالیت زیرساخت در برابر برخی خرابی‌های سخت‌افزاری را فراهم می‌کند. البته میزان این پایداری به معماری و تنظیمات سیستم بستگی دارد.

مزیت دیگر Ceph، امکان افزایش ظرفیت با اضافه کردن درایوها و سرورهای جدید است. در نتیجه، می‌توان فضای ذخیره‌سازی را متناسب با رشد نیازها گسترش داد، بدون اینکه کل زیرساخت به یک درایو وابسته باشد.

چه عواملی بر سرعت Ceph تاثیر می‌گذارند؟

در یک درایو NVMe، درخواست‌های خواندن و نوشتن مستقیما به درایو می‌رسند؛ اما در Ceph، این درخواست‌ها ممکن است به ارتباط شبکه‌ای، پردازش نرم‌افزاری و هماهنگی میان چند گره پردازشی نیاز داشته باشند. این مراحل سربار ایجاد می‌کنند و می‌توانند سرعت ثبت‌شده در بنچمارک را کاهش دهند؛ حتی اگر درایوهای زیرساخت از نوع SSD یا NVMe باشند.

به همین دلیل، سرعت خام درایوها و درایوها لزوما نشان‌دهنده عملکرد نهایی فضای ذخیره‌سازی مبتنی بر Ceph نیست. سرعت شبکه، تنظیمات زیرساخت، نوع عملیات خواندن و نوشتن و میزان بار همگی بر نتیجه تاثیر می‌گذارند. در برخی شرایط، عملکرد اندازه‌گیری‌شده ممکن است به سرعت یک HDD نزدیک شود؛ اما این نتیجه به پیکربندی و نوع آزمایش بستگی دارد و ویژگی ذاتی Ceph نیست.

انتخاب میان سرعت، پایداری و مقیاس‌پذیری

NVMe مستقل برای کاربردهایی که به کمترین تاخیر و بیشترین سرعت مستقیم نیاز دارند، گزینه مناسبی است. در مقابل، Ceph برای زیرساخت‌هایی ارزشمند است که علاوه بر عملکرد مناسب، به تحمل خرابی، پایداری داده‌ها و امکان افزایش ظرفیت نیاز دارند.

بنابراین، در این سناریو هدف دستیابی به بالاترین سرعت ممکن در یک بنچمارک نیست؛ بلکه ایجاد تعادل میان سرعت، پایداری و مقیاس‌پذیری است. ممکن است Ceph در یک آزمایش از NVMe مستقل کندتر باشد، اما قابلیت‌هایی ارائه دهد که یک درایو به‌تنهایی نمی‌تواند فراهم کند. این تفاوت، انتخاب Ceph را برای بسیاری از زیرساخت‌های توزیع‌شده منطقی می‌کند.