مقایسه مختصر معماری SDS یا یافتن بستر ذخیره سازی مناسب (GlusterVsCephVsVirtuozzoStorage)

این مقاله برای کمک به شما در انتخاب راه حل مناسب و درک تفاوت های SDS مانند Gluster، Ceph و Vstorage (Virtuozzo) نوشته شده است.

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

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

گلستر

بیایید با Gluster شروع کنیم، که به طور فعال توسط سازندگان پلتفرم های ابرهمگرا با SDS بر اساس منبع باز برای محیط های مجازی استفاده می شود و می توان آن را در وب سایت RedHat در بخش ذخیره سازی پیدا کرد، جایی که می توانید از دو گزینه SDS انتخاب کنید: Gluster یا Ceph.

گلستر متشکل از پشته ای از مترجمان است - خدماتی که تمام کارهای توزیع فایل ها و غیره را انجام می دهند. Brick سرویسی است که یک دیسک را سرویس می دهد، Volume یک حجم (پول) است که این آجرها را متحد می کند. سپس سرویس توزیع فایل ها به گروه ها با استفاده از عملکرد DHT (جدول هش توزیع شده) ارائه می شود. ما سرویس Sharding را در توضیحات درج نمی کنیم زیرا پیوندهای زیر مشکلات مربوط به آن را شرح می دهند.

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

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

• فضا در گروه ها به طور ناموزون استفاده می شود، بستگی به حجم فایل ها دارد و اگر فضای کافی در گروه برای نوشتن فایل نباشد، با خطا مواجه می شوید، فایل نوشته نمی شود و به گروه دیگری توزیع نمی شود. ;
• هنگام نوشتن یک فایل، IO فقط به یک گروه می رود، بقیه بیکار هستند.
• هنگام نوشتن یک فایل نمی توانید IO کل حجم را دریافت کنید.
• و مفهوم کلی به دلیل عدم توزیع داده ها در بلوک ها کمتر کارآمد به نظر می رسد، جایی که تعادل و حل مشکل توزیع یکنواخت آسان تر است، و نه آنطور که اکنون کل فایل به یک بلوک می رود.

از توضیحات رسمی معماری ما همچنین به طور غیرارادی به این درک می رسیم که گلستر به عنوان ذخیره فایل در بالای RAID سخت افزاری کلاسیک عمل می کند. تلاش‌های توسعه‌ای برای برش (Sharding) فایل‌ها به بلوک‌ها صورت گرفته است، اما همه اینها افزوده‌ای است که باعث کاهش عملکرد بر رویکرد معماری موجود می‌شود، به علاوه استفاده از اجزای آزادانه توزیع شده با محدودیت‌های عملکردی مانند Fuse. هیچ سرویس ابرداده ای وجود ندارد که عملکرد و قابلیت های تحمل خطای ذخیره سازی را هنگام توزیع فایل ها در بلوک ها محدود می کند. شاخص‌های عملکرد بهتر را می‌توان با پیکربندی «Distributed Replicated» مشاهده کرد و تعداد گره‌ها باید حداقل 6 باشد تا یک نسخه قابل اعتماد 3 با توزیع بار بهینه سازماندهی شود.

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


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

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

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

سف

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

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

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

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

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

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

Vstorage

معماری حتی جالب تر به نظر می رسد ذخیره سازی Virtuozzo (Vstorage)، که می تواند همراه با یک هایپروایزر روی همان گره ها، در همان گره ها استفاده شود غده، اما پیکربندی صحیح همه چیز برای دستیابی به عملکرد خوب بسیار مهم است. یعنی استقرار چنین محصولی از جعبه در هر پیکربندی بدون در نظر گرفتن توصیه‌های مطابق با معماری بسیار آسان است، اما سازنده نیست.

چه چیزی می تواند برای ذخیره سازی در کنار خدمات هایپروایزر kvm-qemu وجود داشته باشد، و اینها تنها چند سرویس هستند که در آنها یک سلسله مراتب بهینه فشرده از مؤلفه ها یافت شده است: سرویس مشتری نصب شده از طریق FUSE (تغییر شده، نه منبع باز)، سرویس ابرداده MDS (سرویس فراداده)، بلوک‌های داده سرویس Chunk که در سطح فیزیکی برابر با یک دیسک است و بس. از نظر سرعت، البته، استفاده از یک طرح مقاوم در برابر خطا با دو نسخه بهینه است، اما اگر از حافظه پنهان و لاگ در درایوهای SSD استفاده می‌کنید، می‌توانید کدگذاری مقاوم به خطا (پاک کردن کد یا raid6) را به‌خوبی در یک دستگاه اورکلاک کنید. طرح هیبریدی یا حتی بهتر از آن در تمام فلش ها. EC (پاک کردن کدگذاری) معایبی دارد: هنگام تغییر یک بلوک داده، لازم است مقادیر برابری مجدداً محاسبه شود. برای دور زدن تلفات مربوط به این عملیات، Ceph به طور معوق به EC می نویسد و مشکلات عملکرد ممکن است در طول یک درخواست خاص رخ دهد، زمانی که برای مثال، تمام بلوک ها باید خوانده شوند، و در مورد Virtuozzo Storage، نوشتن بلوک های تغییر یافته انجام می شود. با استفاده از رویکرد "سیستم فایل ساختار یافته"، که هزینه های محاسبه برابری را به حداقل می رساند. برای تخمین تقریبی گزینه هایی با شتاب کار با و بدون EC وجود دارد ماشین حساب. - ارقام بسته به ضریب دقت سازنده تجهیزات می توانند تقریبی باشند، اما نتیجه محاسبات کمک خوبی در برنامه ریزی پیکربندی است.

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

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

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

بیایید فرآیند ضبط را در یک پیکربندی سخت‌افزار ترکیبی با اجزایی که در بالا توضیح داده شد در نظر بگیریم: ضبط شروع به رفتن به گره‌ای می‌کند که کلاینت آن را از آنجا شروع کرده است (سرویس نقطه اتصال FUSE)، اما مؤلفه اصلی Metadata Service (MDS) البته این کار را انجام خواهد داد. مشتری را مستقیماً به سرویس قطعه مورد نظر هدایت کنید (بلاک های CS سرویس ذخیره سازی)، یعنی MDS در فرآیند ضبط شرکت نمی کند، بلکه به سادگی سرویس را به قطعه مورد نیاز هدایت می کند. به طور کلی می توان به ضبط با ریختن آب در بشکه قیاس کرد. هر بشکه یک بلوک داده 256 مگابایتی است.

یعنی یک دیسک تعداد مشخصی از این بشکه ها است، یعنی حجم دیسک تقسیم بر 256 مگابایت. هر کپی به یک گره توزیع می شود، دومی تقریباً به صورت موازی با گره دیگر و غیره... اگر سه نسخه مشابه داشته باشیم و دیسک های SSD برای حافظه پنهان (برای خواندن و نوشتن گزارش ها) وجود داشته باشد، پس از نوشتن، تایید نوشتن اتفاق می افتد. ورود به SSD و بازنشانی موازی از SSD بر روی HDD ادامه می‌یابد، گویی در پس‌زمینه. در مورد سه کپی، رکورد پس از تایید از SSD گره سوم انجام می شود. ممکن است به نظر برسد که مجموع سرعت نوشتن سه SSD را می توان بر سه تقسیم کرد و سرعت نوشتن یک ماکت را بدست آوریم، اما کپی ها به صورت موازی نوشته می شوند و سرعت تأخیر شبکه معمولاً بیشتر از SSD است. و در واقع عملکرد نوشتن به شبکه بستگی دارد. در این راستا، برای مشاهده IOPS واقعی، باید کل Vstorage را به درستی بارگذاری کنید روش شناسی، یعنی آزمایش بار واقعی و نه حافظه و حافظه نهان که در آن لازم است اندازه بلوک داده صحیح، تعداد رشته ها و غیره در نظر گرفته شود.

لاگ ضبط فوق بر روی SSD به گونه ای کار می کند که به محض ورود اطلاعات به آن، بلافاصله توسط سرویس خوانده می شود و بر روی HDD نوشته می شود. چندین سرویس ابرداده (MDS) در هر خوشه وجود دارد و تعداد آنها با حد نصاب تعیین می شود که طبق الگوریتم Paxos کار می کند. از دیدگاه مشتری، نقطه نصب FUSE یک پوشه ذخیره سازی خوشه ای است که به طور همزمان برای تمام گره های خوشه قابل مشاهده است، هر گره طبق این اصل یک کلاینت نصب شده دارد، بنابراین این ذخیره سازی برای هر گره در دسترس است.

برای عملکرد هر یک از رویکردهای توصیف شده در بالا، در مرحله برنامه ریزی و استقرار، بسیار مهم است که شبکه را به درستی پیکربندی کنید، جایی که تعادل به دلیل تجمع و انتخاب صحیح پهنای باند کانال شبکه وجود دارد. در تجمیع، مهم است که حالت هش و اندازه فریم مناسب را انتخاب کنید. همچنین تفاوت بسیار زیادی با SDS توضیح داده شده در بالا وجود دارد، این فیوز با فناوری مسیر سریع در Virtuozzo Storage است. که علاوه بر فیوز مدرن، بر خلاف سایر راه حل های منبع باز، IOPS را به میزان قابل توجهی افزایش می دهد و به شما امکان می دهد با مقیاس بندی افقی یا عمودی محدود نشوید. به طور کلی، در مقایسه با معماری هایی که در بالا توضیح داده شد، این یکی قدرتمندتر به نظر می رسد، اما برای چنین لذتی، البته، برخلاف Ceph و Gluster، باید مجوز خریداری کنید.

به طور خلاصه، می‌توانیم بالای این سه مورد را برجسته کنیم: Virtuozzo Storage از نظر عملکرد و قابلیت اطمینان معماری جایگاه اول را به خود اختصاص داده است، Ceph در جایگاه دوم و Gluster مقام سوم را به خود اختصاص داده است.

معیارهایی که Virtuozzo Storage بر اساس آن انتخاب شد: مجموعه ای بهینه از اجزای معماری است که برای این رویکرد Fuse با مسیر سریع، مجموعه ای انعطاف پذیر از پیکربندی های سخت افزاری، مصرف کمتر منابع و توانایی اشتراک گذاری با محاسبات (محاسبات/مجازی سازی) مدرن شده است. یعنی برای یک راه حل ابرهمگرا که او بخشی از آن است کاملاً مناسب است. رتبه دوم Ceph است زیرا در مقایسه با Gluster، به دلیل عملکرد در بلوک‌ها، و همچنین سناریوهای انعطاف‌پذیرتر و توانایی کار در خوشه‌های بزرگ‌تر، معماری سازنده‌تری دارد.

برنامه‌هایی برای نوشتن مقایسه‌ای بین vSAN، Space Direct Storage، Vstorage و Nutanix Storage، آزمایش Vstorage بر روی تجهیزات HPE و Huawei و همچنین سناریوهایی برای یکپارچه‌سازی Vstorage با سیستم‌های ذخیره‌سازی سخت‌افزار خارجی وجود دارد، بنابراین اگر مقاله را دوست داشتید، می‌توانید آن را انجام دهید. خوشحالم که از شما بازخورد دریافت می کنم، که می تواند انگیزه مقالات جدید را با در نظر گرفتن نظرات و خواسته های شما افزایش دهد.

منبع: www.habr.com