سلام بر خوانندگان خبر. با این مقاله مجموعه ای را باز می کنیم که در مورد سیستم ابرهمگرا AERODISK vAIR که توسعه داده ایم صحبت می کنیم. در ابتدا می خواستیم در مقاله اول همه چیز را در مورد همه چیز بگوییم، اما سیستم کاملاً پیچیده است، بنابراین ما فیل را به صورت قسمتی می خوریم.
بیایید داستان را با تاریخچه ایجاد سیستم شروع کنیم، به سیستم فایل ARDFS که اساس vAIR است بپردازیم و همچنین کمی در مورد موقعیت این راه حل در بازار روسیه صحبت کنیم.
در مقالات آینده با جزئیات بیشتری در مورد اجزای مختلف معماری (خوشه، هایپروایزر، متعادل کننده بار، سیستم مانیتورینگ و غیره)، فرآیند پیکربندی، طرح مسائل مربوط به مجوز، نمایش جداگانه تست های تصادف و البته نوشتن در مورد تست بار و ... صحبت خواهیم کرد. اندازه گیری ما همچنین مقاله جداگانه ای را به نسخه جامعه vAIR اختصاص خواهیم داد.
آیا Aerodisk داستانی در مورد سیستم های ذخیره سازی است؟ یا چرا در وهله اول شروع به انجام hyperconvergence کردیم؟
در ابتدا، ایده ایجاد ابرهمگرایی خودمان در حدود سال 2010 به ذهنمان رسید. در آن زمان، نه Aerodisk و نه راه حل های مشابه (سیستم های هیپرهمگرا با جعبه های تجاری) در بازار وجود داشت. وظیفه ما به شرح زیر بود: از مجموعه ای از سرورها با دیسک های محلی، که توسط یک اتصال از طریق پروتکل اترنت متحد شده اند، لازم بود یک ذخیره سازی گسترده ایجاد کنیم و ماشین های مجازی و یک شبکه نرم افزاری را در آنجا راه اندازی کنیم. همه اینها باید بدون سیستم های ذخیره سازی پیاده سازی می شد (زیرا به سادگی هیچ پولی برای سیستم های ذخیره سازی و سخت افزار آن وجود نداشت و ما هنوز سیستم های ذخیره سازی خود را اختراع نکرده بودیم).
ما بسیاری از راه حل های متن باز را امتحان کردیم و در نهایت این مشکل را حل کردیم، اما راه حل بسیار پیچیده و تکرار آن دشوار بود. علاوه بر این، این راه حل در رده "آیا کار می کند؟ دست نزن! بنابراین، پس از حل این مشکل، ایده تبدیل نتیجه کار خود به یک محصول کامل را توسعه ندادیم.
پس از آن اتفاق، از این ایده فاصله گرفتیم، اما همچنان این احساس را داشتیم که این مشکل کاملاً قابل حل است و مزایای چنین راه حلی بیش از پیش آشکار بود. پس از آن، محصولات HCI منتشر شده از شرکت های خارجی تنها این احساس را تایید کرد.
بنابراین، در اواسط سال 2016، ما به عنوان بخشی از ایجاد یک محصول تمام عیار به این وظیفه بازگشتیم. در آن زمان ما هنوز هیچ رابطه ای با سرمایه گذاران نداشتیم، بنابراین مجبور شدیم یک غرفه توسعه را برای پول نه چندان بزرگ خود بخریم. با جمع‌آوری سرورها و سوئیچ‌های استفاده شده در Avito، وارد کار شدیم.
وظیفه اولیه اصلی ایجاد سیستم فایل خود، هرچند ساده، اما خودمان بود، که می توانست به طور خودکار و یکنواخت داده ها را در قالب بلوک های مجازی بر روی nامین گره های خوشه ای که توسط یک اتصال از طریق اترنت به هم متصل می شوند، توزیع کند. در عین حال، FS باید به خوبی و به راحتی مقیاس شود و مستقل از سیستم های مجاور باشد، یعنی. از vAIR به شکل "فقط یک مرکز ذخیره سازی" بیگانه شود.
اولین مفهوم vAIR
ما عمداً استفاده از راه حل های منبع باز آماده برای سازماندهی ذخیره سازی طولانی (ceph، gluster، luster و موارد مشابه) را به نفع توسعه خودمان رها کردیم، زیرا قبلاً تجربه پروژه زیادی با آنها داشتیم. البته خود این راه حل ها عالی هستند و قبل از کار روی Aerodisk بیش از یک پروژه یکپارچه سازی با آنها اجرا کردیم. اما اجرای یک کار خاص برای یک مشتری، آموزش کارکنان و شاید خرید پشتیبانی از یک فروشنده بزرگ یک چیز است، و ایجاد یک محصول به راحتی قابل تکرار که برای کارهای مختلف مورد استفاده قرار می گیرد، که ما به عنوان یک فروشنده، حتی ممکن است در مورد خودمان بدانیم که نمی‌دانیم. برای هدف دوم، محصولات منبع باز موجود برای ما مناسب نبودند، بنابراین تصمیم گرفتیم خودمان یک سیستم فایل توزیع شده ایجاد کنیم.
دو سال بعد، چندین توسعه‌دهنده (که کار بر روی vAIR را با کار بر روی سیستم ذخیره‌سازی موتور کلاسیک ترکیب کردند) به نتیجه خاصی دست یافتند.
تا سال 2018، ما یک فایل سیستم ساده نوشتیم و آن را با سخت افزارهای لازم تکمیل کردیم. این سیستم دیسک‌های فیزیکی (محلی) را از سرورهای مختلف در یک استخر مسطح از طریق یک اتصال داخلی ترکیب کرد و آنها را به بلوک‌های مجازی «برش» داد، سپس دستگاه‌هایی با درجات مختلف تحمل خطا از بلوک‌های مجازی ایجاد شد که روی آنها مجازی‌ها ایجاد شدند. و با استفاده از ماشین های هایپروایزر KVM اجرا شد.
ما زیاد با نام فایل سیستم خود را خسته نکردیم و به طور خلاصه آن را ARDFS نامیدیم (حدس بزنید مخفف آن چیست))
این نمونه اولیه خوب به نظر می رسید (البته نه از نظر بصری، هنوز طراحی بصری وجود نداشت) و از نظر عملکرد و مقیاس بندی نتایج خوبی از خود نشان داد. پس از اولین نتیجه واقعی، ما این پروژه را راه اندازی کردیم و یک محیط توسعه کامل و یک تیم جداگانه را سازماندهی کردیم که فقط با vAIR سروکار داشت.
درست در آن زمان، معماری کلی راه حل بالغ شده بود، که هنوز دستخوش تغییرات عمده ای نشده است.
غواصی در سیستم فایل ARDFS
ARDFS پایه و اساس vAIR است که ذخیره‌سازی داده‌های توزیع‌شده و مقاوم در برابر خطا را در کل خوشه فراهم می‌کند. یکی از (اما نه تنها) ویژگی های متمایز ARDFS این است که از هیچ سرور اختصاصی اضافی برای ابرداده و مدیریت استفاده نمی کند. این در ابتدا برای ساده کردن پیکربندی راه حل و برای قابلیت اطمینان آن در نظر گرفته شد.
ساختار ذخیره سازی
در تمام گره های خوشه، ARDFS یک استخر منطقی از تمام فضای دیسک موجود سازماندهی می کند. درک این نکته مهم است که یک استخر هنوز داده یا فضای قالب بندی شده نیست، بلکه صرفاً نشانه گذاری است، یعنی. هر گره ای که vAIR نصب شده باشد، هنگامی که به خوشه اضافه می شود، به طور خودکار به استخر مشترک ARDFS اضافه می شود و منابع دیسک به طور خودکار در کل خوشه به اشتراک گذاشته می شود (و برای ذخیره سازی داده های آینده در دسترس است). این رویکرد به شما امکان می دهد بدون هیچ گونه تأثیر جدی بر روی سیستم در حال اجرا، گره ها را اضافه و حذف کنید. آن ها مقیاس کردن سیستم در آجرها بسیار آسان است و در صورت لزوم گره ها را در خوشه اضافه یا حذف می کند.
دیسک‌های مجازی (اشیاء ذخیره‌سازی ماشین‌های مجازی) در بالای استخر ARDFS اضافه می‌شوند که از بلوک‌های مجازی با اندازه ۴ مگابایت ساخته شده‌اند. دیسک های مجازی مستقیماً داده ها را ذخیره می کنند. طرح تحمل خطا نیز در سطح دیسک مجازی تنظیم شده است.
همانطور که قبلاً حدس زده اید، برای تحمل خطا در زیرسیستم دیسک، ما از مفهوم RAID (آرایه اضافی از دیسک های مستقل) استفاده نمی کنیم، بلکه از RAIN (آرایه اضافی گره های مستقل) استفاده می کنیم. آن ها تحمل خطا بر اساس گره‌ها، نه دیسک‌ها، اندازه‌گیری، خودکار و مدیریت می‌شود. البته دیسک ها نیز یک شی ذخیره سازی هستند، آنها، مانند هر چیز دیگری، نظارت می شوند، می توانید تمام عملیات استاندارد را با آنها انجام دهید، از جمله مونتاژ یک RAID سخت افزاری محلی، اما خوشه به طور خاص بر روی گره ها عمل می کند.
در شرایطی که شما واقعاً RAID را می‌خواهید (به عنوان مثال، سناریویی که از خرابی‌های متعدد در خوشه‌های کوچک پشتیبانی می‌کند)، هیچ چیز مانع از استفاده از کنترل‌کننده‌های RAID محلی و ایجاد فضای ذخیره‌سازی طولانی و معماری RAIN در بالا نمی‌شود. این سناریو کاملاً زنده است و توسط ما پشتیبانی می شود، بنابراین در مقاله ای در مورد سناریوهای معمولی برای استفاده از vAIR در مورد آن صحبت خواهیم کرد.
طرح‌های تحمل خطای ذخیره‌سازی
می تواند دو طرح تحمل خطا برای دیسک های مجازی در vAIR وجود داشته باشد:
1) ضریب تکرار یا به سادگی تکرار - این روش تحمل خطا به سادگی یک چوب و طناب است. همانندسازی همزمان بین گره ها با ضریب 2 (2 کپی در هر خوشه) یا 3 (3 کپی) انجام می شود. RF-2 به یک دیسک مجازی اجازه می دهد تا در برابر شکست یک گره در خوشه مقاومت کند، اما نیمی از حجم مفید را "می خورد" و RF-3 در برابر شکست 2 گره در خوشه مقاومت می کند، اما 2/3 از آن را ذخیره می کند. حجم مفید برای نیازهای آن این طرح بسیار شبیه به RAID-1 است، یعنی یک دیسک مجازی پیکربندی شده در RF-2 در برابر شکست هر یک از گره ها در خوشه مقاوم است. در این صورت همه چیز با داده ها درست می شود و حتی I/O متوقف نمی شود. هنگامی که گره سقوط کرده به سرویس بازگردد، بازیابی/همگام سازی خودکار داده ها آغاز می شود.
در زیر نمونه هایی از توزیع داده های RF-2 و RF-3 در حالت عادی و در وضعیت خرابی آورده شده است.
ما یک ماشین مجازی با ظرفیت 8 مگابایت داده منحصربفرد (مفید) داریم که روی 4 گره vAIR اجرا می شود. واضح است که در واقعیت بعید است که چنین حجم کمی وجود داشته باشد، اما برای طرحی که منطق عملیات ARDFS را منعکس می کند، این مثال قابل درک ترین است. AB بلوک های مجازی 4 مگابایتی حاوی داده های ماشین مجازی منحصر به فرد هستند. RF-2 دو کپی از این بلوک ها را به ترتیب A1+A2 و B1+B2 ایجاد می کند. این بلوک‌ها در سراسر گره‌ها قرار می‌گیرند و از تقاطع داده‌های مشابه روی همان گره اجتناب می‌کنند، یعنی کپی A1 در همان گره کپی A2 قرار نخواهد گرفت. B1 و B2 هم همینطور.
اگر یکی از گره ها از کار بیفتد (به عنوان مثال، گره شماره 3 که حاوی یک کپی از B1 است)، این کپی به طور خودکار در گره ای که هیچ کپی از کپی آن وجود ندارد (یعنی یک کپی از B2) فعال می شود.
بنابراین، دیسک مجازی (و VM، بر این اساس) می تواند به راحتی از شکست یک گره در طرح RF-2 جان سالم به در ببرد.
طرح تکرار، در حالی که ساده و قابل اعتماد است، از همان مشکل RAID1 رنج می برد - فضای قابل استفاده کافی نیست.
2) کدگذاری پاک کردن یا کدگذاری پاک کردن (همچنین به عنوان "کدگذاری اضافی"، "کدگذاری پاک کردن" یا "کد افزونگی" نیز شناخته می شود) برای حل مشکل بالا وجود دارد. EC یک طرح افزونگی است که در دسترس بودن داده های بالایی را با سربار فضای دیسک کمتر در مقایسه با تکرار فراهم می کند. اصل عملکرد این مکانیزم مشابه RAID 5، 6، 6P است.
هنگام رمزگذاری، فرآیند EC یک بلوک مجازی (به طور پیش فرض 4 مگابایت) را بسته به طرح EC به چندین "تکه داده" کوچکتر تقسیم می کند (به عنوان مثال، یک طرح 2+1 هر بلوک 4 مگابایتی را به 2 تکه 2 مگابایتی تقسیم می کند). در مرحله بعد، این فرآیند «تکه‌های برابری» را برای «تکه‌های داده» تولید می‌کند که بزرگتر از یکی از قسمت‌های تقسیم‌شده قبلی نیستند. هنگام رمزگشایی، EC با خواندن داده‌های «بازمانده» در کل خوشه، تکه‌های گمشده را تولید می‌کند.
به عنوان مثال، یک دیسک مجازی با طرح EC 2 + 1، که بر روی 4 گره خوشه پیاده سازی شده است، به راحتی در برابر شکست یک گره در خوشه مانند RF-2 مقاومت می کند. در این صورت هزینه های سربار کمتر خواهد بود، به ویژه ضریب ظرفیت مفید برای RF-2 2 و برای EC 2+1 1,5 خواهد بود.
برای توصیف ساده تر، ماهیت این است که بلوک مجازی به 2-8 قطعه تقسیم می شود (چرا از 2 تا 8، در زیر مشاهده کنید) "قطعه" و برای این قطعات "قطعات" برابری با حجم مشابه محاسبه می شود.
در نتیجه، داده ها و برابری به طور مساوی در تمام گره های خوشه توزیع می شوند. در عین حال، مانند تکرار، ARDFS به‌طور خودکار داده‌ها را بین گره‌ها توزیع می‌کند، به گونه‌ای که از ذخیره داده‌های یکسان (کپی از داده‌ها و برابری آنها) در همان گره جلوگیری می‌کند تا احتمال از دست دادن داده‌ها را از بین ببرد. به این واقعیت که داده ها و برابری آنها به طور ناگهانی به یک گره ذخیره سازی می رسد که از کار می افتد.
در زیر یک مثال با همان ماشین مجازی 8 مگابایتی و 4 گره، اما با طرح EC 2+1 آورده شده است.
بلوک های A و B به دو تکه 2 مگابایتی (دو تا به دلیل 2+1) تقسیم می شوند، یعنی A1+A2 و B1+B2. بر خلاف ماکت، A1 یک کپی از A2 نیست، یک بلوک مجازی A است که به دو قسمت تقسیم شده است، همان بلوک B. در مجموع، ما دو مجموعه 4 مگابایتی دریافت می کنیم که هر کدام شامل دو قطعه دو مگابایتی است. در مرحله بعد، برای هر یک از این مجموعه ها، برابری با حجمی بیش از یک قطعه (یعنی 2 مگابایت) محاسبه می شود، یک + 2 قطعه اضافی (AP و BP) بدست می آوریم. در کل داده های 4×2 + برابری 2×2 داریم.
در مرحله بعد، قطعات در میان گره ها قرار می گیرند تا داده ها با برابری آنها تلاقی نداشته باشند. آن ها A1 و A2 روی همان گره AP قرار نخواهند داشت.
در صورت خرابی یک گره (به عنوان مثال، سوم)، بلوک سقوط کرده B1 به طور خودکار از برابری BP که در گره شماره 2 ذخیره شده است، بازیابی می شود و در گره ای که وجود دارد فعال می شود. بدون برابری B، یعنی قطعه BP در این مثال، این گره شماره 1 است
من مطمئن هستم که خواننده یک سوال دارد:
"هر چیزی که شما توضیح دادید مدتهاست که هم توسط رقبا و هم در راه حل های منبع باز اجرا شده است، تفاوت بین اجرای EC شما در ARDFS چیست؟"
و سپس ویژگی های جالب ARDFS وجود خواهد داشت.
پاک کردن کدگذاری با تمرکز بر انعطاف پذیری
در ابتدا، ما یک طرح نسبتاً انعطاف‌پذیر EC X+Y ارائه کردیم، که در آن X برابر با عددی از 2 تا 8 است و Y برابر با عددی از 1 تا 8 است، اما همیشه کمتر یا مساوی X است. این طرح ارائه شده است. برای انعطاف پذیری افزایش تعداد قطعات داده (X) که بلوک مجازی به آنها تقسیم می شود، امکان کاهش هزینه های سربار، یعنی افزایش فضای قابل استفاده را فراهم می کند.
افزایش تعداد قطعات برابری (Y) باعث افزایش قابلیت اطمینان دیسک مجازی می شود. هر چه مقدار Y بزرگتر باشد، تعداد بیشتری گره در خوشه ممکن است از کار بیفتند. البته افزایش حجم برابری میزان ظرفیت قابل استفاده را کاهش می دهد، اما این بهایی است که باید برای اطمینان پرداخت کرد.
وابستگی عملکرد به مدارهای EC تقریباً مستقیم است: هرچه "قطعه ها" بیشتر باشد، عملکرد پایین تر است؛ البته در اینجا، یک دید متعادل مورد نیاز است.
این رویکرد به مدیران اجازه می دهد تا فضای ذخیره سازی کشیده را با حداکثر انعطاف پذیری پیکربندی کنند. در استخر ARDFS می توانید از هر طرح تحمل خطا و ترکیب آنها استفاده کنید که به نظر ما بسیار مفید است.
در زیر جدولی وجود دارد که چندین طرح (نه همه ممکن) RF و EC را مقایسه می کند.
جدول نشان می دهد که حتی "ترس" ترین ترکیب EC 8+7، که امکان از دست دادن 7 گره در یک خوشه را به طور همزمان فراهم می کند، فضای قابل استفاده کمتری (1,875 در مقابل 2) نسبت به تکرار استاندارد "می خورد" و 7 برابر بهتر محافظت می کند. ، که این مکانیسم حفاظتی را اگرچه پیچیده تر می کند، اما در شرایطی که لازم است حداکثر قابلیت اطمینان در شرایط فضای دیسک محدود اطمینان حاصل شود بسیار جذاب تر است. در عین حال، باید درک کنید که هر "به علاوه" به X یا Y یک سربار عملکرد اضافی خواهد بود، بنابراین در مثلث بین قابلیت اطمینان، صرفه جویی و عملکرد باید بسیار با دقت انتخاب کنید. به همین دلیل، ما یک مقاله جداگانه به اندازه کدگذاری پاک کردن اختصاص خواهیم داد.
قابلیت اطمینان و استقلال سیستم فایل
ARDFS به صورت محلی بر روی تمام گره های خوشه اجرا می شود و آنها را با استفاده از ابزار خود از طریق واسط های اختصاصی اترنت همگام می کند. نکته مهم این است که ARDFS به طور مستقل نه تنها داده ها، بلکه ابرداده های مربوط به ذخیره سازی را همگام سازی می کند. در حین کار بر روی ARDFS، ما به طور همزمان تعدادی از راه حل های موجود را مطالعه کردیم و متوجه شدیم که بسیاری از آنها متای سیستم فایل را با استفاده از یک DBMS توزیع شده خارجی، که ما نیز برای همگام سازی استفاده می کنیم، همگام می کنند، اما فقط از تنظیمات استفاده می کنیم، نه فراداده FS (در مورد این و سایر زیرسیستم های مرتبط. در مقاله بعدی).
همگام‌سازی ابرداده‌های FS با استفاده از یک DBMS خارجی، البته، یک راه‌حل کارساز است، اما پس از آن، سازگاری داده‌های ذخیره‌شده در ARDFS به DBMS خارجی و رفتار آن بستگی دارد (و صادقانه بگوییم، این یک خانم دمدمی مزاج است)، که در نظر ما بد است چرا؟ اگر ابرداده FS آسیب ببیند، به خود داده های FS نیز می توان گفت «خداحافظ»، بنابراین ما تصمیم گرفتیم مسیر پیچیده تر اما قابل اعتمادتری را در پیش بگیریم.
ما زیرسیستم همگام سازی ابرداده را خودمان برای ARDFS ساختیم و کاملاً مستقل از زیرسیستم های مجاور زندگی می کند. آن ها هیچ زیرسیستم دیگری نمی تواند داده های ARDFS را خراب کند. به نظر ما، این مطمئن ترین و صحیح ترین راه است، اما زمان نشان خواهد داد که آیا واقعاً چنین است. علاوه بر این، یک مزیت اضافی با این روش وجود دارد. ARDFS را می توان مستقل از vAIR استفاده کرد، درست مانند ذخیره سازی کشیده، که مطمئناً در محصولات آینده از آن استفاده خواهیم کرد.
در نتیجه، با توسعه ARDFS، ما یک سیستم فایل انعطاف‌پذیر و قابل اعتماد دریافت کردیم که به شما امکان می‌دهد در ظرفیت خود صرفه‌جویی کنید یا از همه چیز در عملکرد صرفه‌جویی کنید، یا ذخیره‌سازی فوق‌العاده قابل اعتماد را با هزینه‌ای معقول، اما الزامات عملکرد را کاهش دهید.
همراه با یک خط مشی صدور مجوز ساده و یک مدل تحویل انعطاف پذیر (با نگاهی به آینده، vAIR توسط گره مجوز داده می شود و به عنوان نرم افزار یا به عنوان یک بسته نرم افزاری تحویل داده می شود)، این به شما امکان می دهد راه حل را با دقت بسیار زیادی برای طیف گسترده ای از نیازهای مشتری تنظیم کنید. سپس به راحتی این تعادل را حفظ کنید.
چه کسی به این معجزه نیاز دارد؟
از یک طرف می توان گفت که در حال حاضر بازیگرانی در بازار وجود دارند که راه حل های جدی در زمینه هایپرهمگرایی دارند و ما در واقع به این سمت می رویم. به نظر می رسد که این گفته درست است، اما ...
از طرف دیگر، وقتی به میدان می رویم و با مشتریان ارتباط برقرار می کنیم، ما و شرکایمان می بینیم که اصلاً اینطور نیست. وظایف زیادی برای ابر همگرایی وجود دارد، در برخی جاها مردم به سادگی نمی دانستند که چنین راه حل هایی وجود دارد، در برخی دیگر گران به نظر می رسید، در برخی دیگر آزمایش های ناموفق راه حل های جایگزین وجود داشت، و در برخی دیگر به دلیل تحریم ها خرید را اصلا ممنوع می کنند. به طور کلی معلوم شد که زمین شخم نشده است، بنابراین ما به پرورش خاک بکر رفتیم))).
چه زمانی سیستم ذخیره سازی بهتر از GCS است؟
همانطور که ما با بازار کار می کنیم، اغلب از ما سوال می شود که چه زمانی بهتر است از یک طرح کلاسیک با سیستم های ذخیره سازی استفاده کنیم و چه زمانی از hyperconvergent استفاده کنیم؟ بسیاری از شرکت‌های تولیدکننده GCS (مخصوصاً آن‌هایی که سیستم‌های ذخیره‌سازی را در مجموعه خود ندارند) می‌گویند: «سیستم‌های ذخیره‌سازی منسوخ می‌شوند، فقط همگرا می‌شوند!» این یک جمله جسورانه است، اما به طور کامل واقعیت را منعکس نمی کند.
در حقیقت، بازار ذخیره سازی واقعاً به سمت همگرایی بیش از حد و راه حل های مشابه در حال حرکت است، اما همیشه یک "اما" وجود دارد.
اولاً، مراکز داده و زیرساخت‌های فناوری اطلاعات که بر اساس طرح کلاسیک با سیستم‌های ذخیره‌سازی ساخته شده‌اند را نمی‌توان به راحتی بازسازی کرد، بنابراین مدرن‌سازی و تکمیل چنین زیرساخت‌هایی هنوز میراثی برای 5-7 سال است.
ثانیاً، زیرساختی که در حال حاضر در اکثر موارد در حال ساخت است (منظور فدراسیون روسیه است) بر اساس طرح کلاسیک با استفاده از سیستم های ذخیره سازی ساخته شده است، و نه به این دلیل که مردم از ابر همگرایی اطلاعی ندارند، بلکه به این دلیل که بازار ابرهمگرایی جدید است، راه حل ها و استانداردها هنوز ایجاد نشده اند، افراد فناوری اطلاعات هنوز آموزش ندیده اند، آنها تجربه کمی دارند، اما باید مراکز داده را اینجا و اکنون بسازند. و این روند برای 3-5 سال دیگر ادامه خواهد داشت (و سپس یک میراث دیگر، به نقطه 1 مراجعه کنید).
ثالثاً، یک محدودیت فنی صرفاً در تأخیرهای کوچک اضافی 2 میلی ثانیه در هر نوشتن (البته به استثنای حافظه پنهان محلی) وجود دارد که هزینه ذخیره سازی توزیع شده است.
خوب، بیایید استفاده از سرورهای فیزیکی بزرگ را که عاشق مقیاس عمودی زیرسیستم دیسک هستند، فراموش نکنیم.
بسیاری از وظایف ضروری و محبوب وجود دارد که در آنها سیستم های ذخیره سازی بهتر از GCS رفتار می کنند. در اینجا، البته، آن دسته از تولیدکنندگانی که سیستم های ذخیره سازی در سبد محصولات خود ندارند، با ما موافق نیستند، اما ما آماده بحث منطقی هستیم. البته، ما به عنوان توسعه دهندگان هر دو محصول، قطعاً سیستم های ذخیره سازی و GCS را در یکی از انتشارات آینده خود مقایسه خواهیم کرد، جایی که به وضوح نشان خواهیم داد که در چه شرایطی کدام بهتر است.
و کجا راه حل های ابرهمگرا بهتر از سیستم های ذخیره سازی کار می کنند؟
با توجه به نکات فوق می توان سه نتیجه واضح گرفت:
- در جایی که 2 میلی ثانیه تاخیر اضافی برای ضبط، که به طور مداوم در هر محصولی رخ می دهد (اکنون در مورد مواد مصنوعی صحبت نمی کنیم، نانوثانیه ها را می توان بر روی مواد مصنوعی نشان داد)، غیر بحرانی است، فوق همگرا مناسب است.
- در جایی که بار سرورهای فیزیکی بزرگ را می توان به بسیاری از سرورهای مجازی کوچک تبدیل کرد و بین گره ها توزیع کرد، ابرهمگرایی نیز در آنجا به خوبی کار خواهد کرد.
- در جایی که مقیاس بندی افقی اولویت بالاتری نسبت به مقیاس عمودی دارد، GCS در آنجا نیز به خوبی عمل می کند.
این راه حل ها چیست؟
- کلیه خدمات زیرساخت استاندارد (سرویس دایرکتوری، پست الکترونیکی، EDMS، سرورهای فایل، سیستم های ERP و BI کوچک یا متوسط و غیره). ما این را "محاسبات عمومی" می نامیم.
- زیرساخت ارائه دهندگان ابر، که در آن لازم است به سرعت و استاندارد شده به صورت افقی گسترش یابد و تعداد زیادی ماشین مجازی برای مشتریان به راحتی "برش" شود.
- زیرساخت دسکتاپ مجازی (VDI)، که در آن بسیاری از ماشین‌های مجازی کاربر کوچک اجرا می‌شوند و به آرامی در یک خوشه یکنواخت شناور می‌شوند.
- شبکه های شعب، که در آن هر شعبه به یک زیرساخت استاندارد، قابل تحمل خطا، اما ارزان قیمت از 15-20 ماشین مجازی نیاز دارد.
- هر گونه محاسبات توزیع شده (مثلاً خدمات کلان داده). جایی که بار نه "در عمق" بلکه "در عرض" می رود.
- محیط های آزمایشی که در آن تاخیرهای کوچک اضافی قابل قبول است، اما محدودیت های بودجه ای وجود دارد، زیرا این ها آزمایش هستند.
در حال حاضر، برای این وظایف است که ما AERODISK vAIR را ساخته‌ایم و روی آنها تمرکز می‌کنیم (تا کنون با موفقیت). شاید این موضوع به زودی تغییر کند، زیرا ... جهان ثابت نمی ماند
بنابراین…
این قسمت اول یک سری مقالات بزرگ را تکمیل می کند؛ در مقاله بعدی در مورد معماری راه حل و اجزای مورد استفاده صحبت خواهیم کرد.
ما از سوالات، پیشنهادات و اختلافات سازنده استقبال می کنیم.
منبع: www.habr.com