خانه / architecture / حافظه اشتراکی Ceph (بخش اول)

حافظه اشتراکی Ceph (بخش اول)

Ceph یک پروژه اپن سورس تامین کننده حافظه تحت شبکه نرم افزاری است که قابلیت های بالایی در ارائه کارایی و قابلیت تعمیم پذیری دارد. هدف ceph ارائه راهکار های زیر در یک حافظه اشتراکی را دارا می باشد.

  • قابلیت مقیاس پذیری
  • توضیع پذیری و کاهش خطای امکان دسترسی به منابع
  • ارائه راه کار نرم افزاری
  • عدم وابستگی به سخت افزار خاص
  • قابلیت مدیریت یکپارچه و خود سازماندهی

همان طور که در تصویر بالا مشاهده میکنید این ابزار قابلیت ارائه حافظه اشتراکی به صورت فایل، بلاک و object را دارا می باشد که به صورت نرم افزاری این سیستم را ارائه میدهد. 

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

معماری ceph به این صورت است که تمام ذخیره سازی آن از نوع object بود و توسط یک ابزار مدیریتی سطح پایین با نام RADOS کنترل ذخیره سازی به شکل بلاک و فایل را بر پایه object فراهم میکند. در سیستم های رایج ذخیره سازی مدیریت بازیابی اطلاعات و ذخیره آن بر عهده یک سیستم مرکزی می باشد اما در ceph با استفاده از الگوریتم CRUSH این مدیریت بین نود های مختلف در یک خوشه توزیع شده و هر نود می تواند مستقلا محل ذخیره داده ها را بازیابی نماید. عملکرد این الگوریتم به این صورت است که متناسب با درخواست hash معادل آن را ساخته و در جدولی ذخیره میکند و متناسب آن hash مسیر دقیق فایل ذخیره شده در سخت افزار را در کنار آن قرار میدهد بنابراین شما به هر نودی که درخواست خود را ارسال کنید متناسب با درخواست شما داده را فراهم یا ذخیره می کند و به صورت توضیع شده بین تمام نود های خوشه آن را ذخیره میکند. و هر نود خود به تنهایی محل دقیق فایل را در درایو ذخیره سازی مربوطه پیدا خواهد نمود. بر این اساس هر نود به تنهایی مسئول تصمیم گیری جهت محل ذخیره سازی داده در حافظه ذخیره سازی خود می باشد و نیاز به مدیریت مرکزی نخواهد بود. علاوه بر این الگوریتم CRUSH قابلیت خود سازماندهی داشته و درصورتی که اتفاقی برای اجزای آن بیفتد نقشه خود را به روز رسانی کرده و متناسب با خطا عمل خواهد نمود. 

Ceph به صورت مداوم وضعیت فایل ها را بررسی می کند و فایل هایی که دیگر نیاز به ذخیره آن ها نیست را حذف می نماید. 

مدیریت کلاستر و فایل ها توسط deamon ها و سرویس های زیر انجام می پذیرد. دیمن ها شامل :

  • RADOS
  • Monitor
  • OSD
  • Ceph Manager
  • RGW 

می باشد و سرویس های این ابزار عبارت اند از:

  • Block
  • Object
  • File

که در ادامه به تشریح تمام اجزای آن خواهیم پرداخت .

RADOS

Ceph برپایه ابزار ذخیره سازی سطح پایینی به نام RADOS پیاده سازی شده است که با استفاده از سرویس های مورد نظر نیاز های مختلف دستیابی به اطلاعات را برآورده می سازد. شکل زیر نحوه ارتباط این سیستم را با کاربران نشان میدهد.

همانطور که درشکل مشاهده میکنید RADOS به واسطه سرویس های مختلف انواع روش های ذخیره سازی را برای کاربران فراهم میکند. این زیرساخت امکان دسترسی مستقیم به برنامه نویسان برای ایجاد API شخصی خود جهت ذخیره سازی داده ها را نیز فراهم میکند. 

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

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

MONs

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

  • مانیتور یک سیستم شناسایی اهراز هویت ، تشخیص محل ذخیره سازی و سیاست گذاری است.
  • هماهنگی امور برای تمام اجزای کلاستر
  • محافظت از کلاستر توسط الگوریتم PAXOS

Manager

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

  • اطلاعات محاسباتی را جمع آوری میکند
  • عملیات مدیریتی اضافی را پشتیبانی میکند
  • در هر کلاستر به یک واحد مدیریت و یک واحد آماده به کار نیاز است.

OSD

ذخیره داده ، میدیریت کپی ها، بازیابی ، دوباره سازی و تامین اطلاعات مانیتورینگ برای MON ها بر عهده OSD است. به طور کلی:

  • ذخیره اطلاعات برروی HDD یا SSD
  • درخواست های IO را سرویس دهی میکند.
  • ارتباط نودها و کپی ها را سازماندهی میکند
  • در هر کلاستر حداقل به ۳ OSD نیاز داریم

MDS

سرور متا دیتا که اطلاعات اضافی وابسته به سرویس فایل سیستم سف را نگهداری میکند.( سرویس های بلاک و آبجکت نیاز به این سرور ندارند.) این سرویس اجازه اجرای کامند های ساده را به کاربران میدهد.

نحوه ذخیره سازی داد در Ceph

RADOS مسئول ذخیره سازی و کپی داده ها در کلاستر به صورت داینامیک برای کاربران متعدد می باشد. برای این منظور Ceph نیاز به پلن های ذخیره سازی است که عبارت اند از:

Pools

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

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

انعطاف پذیری: شما می توانید استراتژی تعداد کپی های هر داده را در این قسمت انجام دهید همچنینن می توانید تعداد coding chunk ها را برای erasure coded pools  تعریف نمایید. 

PG: شما می توانید تعداد PG ار را متناسب با سناریو خود تعیین نمایید. 

CRUSH Rules: همچنین در این بخش می توایند قوانین خود را برای این الگوریتم تعیین نمایید. 

Snapshot: می توانید در هر زمان یک اسنپشات از کل پول خود تهیه نمایید. 

در بخش بعدی در مورد تنظیمات این قسمت ها صحبت خواهیم نمود. 

Placment Group

سف آبجکت ها را به PG ها نگاشت میدهد. PG ها قسمتی از پول هستند که در OSD ها مجتمع می گردند. این استراتژی متا دیتای آبجکت ها را برای ذخیره سازی کاهش خواهد داد. برای ذخیره سازی بهتر داده متناسب با نیاز خود می توان تعداد PG های هر پول را تغییر داد. نکاتی که برای تعیین تعداد PG ها باید توجه داشت از قرار زیر می باشد. 

اگر تعداد OSD ها کمتر از ۳ باشد بهترین تعداد PG برابر با ۱۲۸ باشد. ( به اضای هر پول)

بین ۵ تا ۱۰ عدد ۵۱۲ مناسب است

بین ۱۰ تا ۵۰ عدد ۱۰۲۴ 

بیشتر از ۵۰ باید به صورت دستی محاسبات انجام شود .

CRUSH Maps

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

با تشکر از اقای مهندس جهانگیری عضو تیم تحقیق توسعه گرین وب و ایران سرور (تمام این مطالب توسط ایشون برای اینجانب ارسال شده و در ادامه بیشتر از تجربه ایشون استفاده میکنیم)

مقاله اصلی ceph

مقاله اصلی crush

کتاب معرفی شده در خصوص ceph

فایل ارایه مهندس جهانگیری

https://github.com/hashem-jahangiri

اگر سوالی در خصوص ceph دارید می توانید با ایمیل در ارتباط باشید

[email protected]

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *