در این مجموعه پست آموزشی قصد دارم مفاهیم دسترس پذیری بالا و نحوه اعمال آن در معماری OpenStack را بیان کنم.
دسترس پذیری بالا در سیستم‌ها غالباً با هدف کاهش دو مورد زیر صورت می‌پذیرد:
۱- خرابی سیستم: هنگامی رخ می‌دهد که کاربر با دردسترس نبودن سرویس در یک زمان مشخص مواجه می‌شود
۲- از بین رفتن داده: پاک شدن یا از بین رفتن تصادفی داده
اغلب سیستم‌های دسترس پذیری بالا، از محافظت در زمان خرابی سیستم و از بین رفتن داده تنها در وقوع یک نقصان ضمانت می‌کنند. البته انتظار می‌رود تا از نقصان‌های آبشاری یعنی هنگامیکه یک نقصان منجر به قطعی سرویس‌های متوالی می‌شود نیز از سیستم محافظت کنند. اغلب ارائه کنندگان سرویس، توافقنامه سطح سرویس (SLA) را که بر مبنای زمان در دسترس بودن سرویس محاسبه می‌شود، ضمانت می‌کنند.
افزونگی و غلبه بر نقصان
دسترس پذیری بالا به کمک اجرای سرویس‌های افزونه (تکراری) روی سخت افزارهای افزونه حاصل می‌شود. اگر یکی از سخت افزارها که یک نمونه سرویس روی آن در حال اجراست دچار نقص شود، سیستم به کمک اجرای نسخه‌ی دیگر سرویس روی سخت افزار مشابه این نقصان را برطرف می‌کند.
جنبه‌ی حیاتی دسترس پذیری بالا به حداقل رساندن نقطه تکی شکست (SPOF) است. SPOF یک تجهیز یا نرم افزار است که درصورت بروز نقص در آن موجب از بین رفتن داده یا زمان خرابی در سیستم می‌شود. به منظور به حداقل رساندن SPOF وجود افزونگی در موارد زیر بایستی بررسی شود:
- تجهیزات شبکه مانند سوئیچ‌ها و روترها
- مهاجرت خودکار برنامه‌های کاربردی و سرویس‌ها
- تجهیزات ذخیره‌سازی
- سرویس‌ها تسهیلاتی مانند برق، سیستم خنک کننده و ضد حریق
در هنگام وقوع یک رخداد و از کار افتادن یک جزء، سیستم پشتیبان بایستی به سرعت جایگزین شود. اغلب سیستم‌های دردسترس پذیری بالا این جایگزینی را در حداقل زمان ممکن انجام می‌دهند.
اکثراً سیستم‌های دردسترس پذیری بالا در خرابی‌های مستقل چندگانه (غیر پشت سرهم) عملکرد مناسبی نخواهند داشت. در این گونه مواقع حفظ سلامت داده‌ها اهمیت بالاتری نسبت به زمان در دسترس پذیری خواهد داشت.
سیستم‌های دردسترس پذیری بالا معمولاً به ٪۹۹/۹۹ و یا بیشتر دسترسی می‌رسند، که معادل کمتر از یک ساعت زمان عدم دسترسی در سال می‌باشد. به منظور رسیدن به این مهم، این سیستم‌ها بایستی حداکثر بین یک تا دو دقیقه (و گاهی مقدار قابل توجهی کمتر) بین خرابی‌ها بازیابی شوند.
امکان رسیدن به چنین دردسترس پذیری برای سرویس‌های زیرساختی OpenStack وجود دارد. بدین منظور که رسیدن به زمان دسترسی ٪۹۹/۹۹ برای زیرساخت OpenStack امکان پذیر است. البته OpenStack چنین ضمانتی برای نمونه‌ها (ماشین‌های مجازی) ندارد.
در ادامه قصد دارم نحوه برقراری دردسترس پذیری بالا برای سرویس‌های OpenStack را بیان کنم.
سرویس‌های بی وضعیت در مقابل دارای وضعیت
سرویس بی وضعیت
سرویسی که یک پاسخ را بعد از درخواست ارائه می‌دهد و عملیات بیشتری احتیاج نیست. این سرویس‌ها در محیط OpenStack عبارتنداز: nova-api، nova-conductor، glance-api، keystone-api، neutron-api و nova-scheduler.
سرویس دارای وضعیت
سرویسی ست که جریان درخواست‌ها به آن وابسته به اولین درخواست است. از آنجاییکه یک عملیات ممکن است شامل درخواست‌های متعددی شود، مدیریت این سرویس‌ها خیلی مشکل است. افزودن نمونه‌های بیشتر و تعدیلگر بار مسئله را حل نمی‌کند. برای مثال فرض کنید اگر داشبورد هر بار که کاربر به صفحه جدیدی می‌رود ریست شود، کارایی مطلوبی نخواهد داشت. سرویس‌های دارای وضعیت در محیط OpenStack شامل پایگاه داده و صف پیغام می‌شود. افزودن قابلیت دسترس پذیری بالا به سرویس‌های دارای وضعیت می‌تواند بستگی به انتخاب پیکربندی فعال/غیرفعال یا فعال/فعال داشته باشد.
فعال/غیرفعال در مقابل فعال/فعال
پیکربندی فعال/غیرفعال
این پیکربندی دارای یک نمونه‌ی افزونه است تا زمانیکه سرویس فعال از کار بیفتد، جایگزین آن شود. به طور مثال، OpenStack می‌تواند داده‌های مورد نیاز را به طور همزمان در پایگاه داده اصلی و یک پایگاه داده پشتیبان بنویسد.
نصب فعال/غیرفعال برای سرویس دارای وضعیت معمولاً شامل یک منبع جایگزین است که می‌تواند در مواقع لزوم در حالت برخط قرار گیرد. درخواست‌ها بوسیله آدرس IP مجازی مدیریت می‌شوند، بدین صورت که بازگشت به سرویس‌دهی را با کمترین تغییرات پیکربندی فراهم می‌کند. یک برنامه‌ی مجزا (مانند Pacemaker یا Corosync) بر این سرویس‌ها نظارت می‌کند و در مواقع لزوم سرویس پشتیبان را برخط می‌کند.
پیکربندی فعال/فعال
در این حالت نیز هر سرویس شامل یک پشتیبان است با این تفاوت که سرویس اصلی و سرویس پشتیبان به طور همزمان مدیریت می‌شوند. در این حالت اگر نقصانی رخ دهد بعید است کاربر متوجه آن شود. سیستم پشتیبان همواره برخط است و در مواقع بروز حادثه بار بیشتری را تحمل می‌کند تا سیستم اصلی به حالت پایدار خود بازگردد.
معمولاً نصب فعال/فعال برای یک سرویس بی وضعیت شامل سرویس‌های افزونه می‌شود، و تمامی درخواست‌ها به کمک یک آدرس IP مجازی و یک تعدیلگر بار مانند HAProxy بین آن‌ها تعدیل می‌شوند.
نصب فعال/فعال برای یک سرویس دارای وضعیت معمولاً شامل سرویس‌های افزونه می‌شود، بطوریکه تمامی نمونه‌های آن دارای وضعیت کاملاً یکسانی باشند. به طور مثال در این حالت، وضعیت ماشین مجازی در تمامی نمونه‌های پایگاه داده بایستی یکسان باشد. در این حالت نیز تعدیلگر بار ترافیک ورودی را مدیریت می‌کند.
در بخش دوم به شرح مفاهیم خوشه بندی و کوارم (حد نصاب) و مقدمات معماری دسترس پذیری بالا در محیط OpenStack می پردازم.