معماری سرویس ذخیره سازی ابری Ceph) Block Storage)

ما در این سلسه مقالات قصد داریم در رابطه با یک راه‌کار ذخیره سازی نرم افزاری یا همان Software Defined Storage به نام CEPH صحبت کنیم، معماری آن را مورد بررسی قرار داده و در نهایت تجربیات مختلف استفاده از آن را بررسی کنیم. همچنین در مستندات قبل در ارتباط با ذخیره سازی اشیاء صحبت کردیم.

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


سف چیست؟

سف یک نرم‌افزار ذخیره‌سازی توزیع‌شده‌ی متن‌باز است که هدف اصلی آن ایجاد قابلیت توسعه، کارایی بالا و احتراز از مدیریت متمرکز بوده است. ceph یک راه‌کار واقعی و جامع در زمینه‌ی «سرویس‌های یکپارچه ذخیره‌سازی» است و امکاناتی مانند Block Storage و Object Storage را در اختیار ما می‌گذارد.


اما در سف چه اتفاقی می افتد؟

محصول ابریمنت هم در لایه Block storage و هم در لایه Object Storage از دو محصول متفاوت نرم‌افزاری استفاده می‌نماید. در سطح Block محصول Ceph مورداستفاده قرارگرفته که هم در زیرساخت Iaas و هم در بستر PaaS قابلیت ارائه سرویس به کاربر را دارد.

سف یک سرویس نرم‌افزاری ذخیره‌سازی است که با استفاده از یک فرایند نرم‌افزاری به نام RADOS block Device ذخیره‌سازی داده‌ها بر مبنای بلوک را در این سرویس توزیع‌ شده تسهیل کرده است. ایمیج های RBD به‌صورت thin-provisioned هستند به این معنی که سایز این ایمیج ها با گذر زمان می‌تواند تغییر کند. همچنین برای ذخیره‌سازی آن‌ها داده را به چندین بخش تقسیم کرده و بین سرورهای osd موجود در کلاستر توزیع می‏کند. معمولاً RBD از دو نوع کتابخانه استفاده می‌کند. کتابخانه librbd معمولاً در ماشین‌های مجازی استفاده می‌شود و دیگری یک ماژول کرنل است که در سرورهای فیزیکی یا محیط‌های تحت کانتینر استفاده می‌شود. ایمیج های RBD دارای دو فرمت Mirroring و In-memory librbd cache هستند. در شکل زیر یک شمای کلی از نحوه خواندن و نوشتن درخواست‌ها در کلاستر Ceph آورده شده است که یک فضای ذخیره‌سازی بلوکی را فراهم می‏کند.

 شمای کلی خواندن و نوشتن درخواست‌ها در فضای ذخیره‌سازی
شمای کلی خواندن و نوشتن درخواست‌ها در فضای ذخیره‌سازی


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

از طرف دیگر برای اینکه دسترس پذیری اطلاعات وابسته به یک سخت افزار خاص نباشد با استفاده از مکانیسم های replication یا erasure code اقدام به توزیع داده ها در بین سخت افزار های مختلف می کند. در مکانیسم replication چندین کپی از اطلاعات در سخت افزار های مختلف پخش می شود اما در مکانیسم erasure code اطلاعات به m بخش تقسیم می شود و nبلاک parity نیز از روی آنها ساخته می شود و بین m+n سخت افزار مختلف توزیع می شوند. در کلاستر سف فارغ از فرمت ذخیره سازی اطلاعات (آبجکت استور، بلاک استور یا فایل سیستم) تمامی اطلاعات به صورت آبجکت و بر روی osd ذخیره می شوند. هر osd عبارت است از یک daemonکه به یک دیسک نگاشت می شود. هر آبجکت هم شامل یک شناسه، اطلاعات باینری و متادیتا هست. آبجکت ها با استفاده از الگوریتم CRUSHبین osd های موجود در کلاستر سف توزیع می شوند.

برای تشریح الگوریتم CRUSH در حالت replication لازم است با دو مفهوم placement group و pool آشنا باشیم. مجموعه ای از osd ها که در یک دسته بندی منطقی قرار گرفته اند pool گفته می شود، در زمان ساخت pool یک نام به آن اختصاص می دهیم و کلاستر هم به صورت خودکار یک شناسه یکتا به آن اختصاص می دهد. چیزی که اهمیت دارد و در الگوریتم CRUSH از آن استفاده می شود شناسه pool است. هنگام ساخت pool لازم است تعداد placement group ها موجود بر روی آن را نیز تعیین کرد، به نحوی که هر osdموجود در pool بیش از 100 placement group نداشته باشد.

الگوریتم CRUSH یک ورودی دریافت می کند و در خروجی آن لیستی از osd ها برای ذخیره سازی فایل را بر میگرداند. ورودی این الگوریتم به این شکل است، ابتدا hashاسم فایلی که قصد ذخیره سازی آن را داریم را حساب می کند و مقدار آن را بر تعداد pg های poolتقسیم می کند، باقی‌مانده این مقدار به علاوه شناسه pool به عنوان ورودی الگوریتم CRUSHهست، الگوریتم CRUSH با توجه به وروی یک osd را به عنوان primary osd و وابسته به تعداد رپلیکا secondary osd ها را معرفی می کند.