دسترس پذیری بالا: تفاوت میان نسخه‌ها
پرش به ناوبری
پرش به جستجو
(صفحه‌ای جدید حاوی «در ارایه سرویس های ابری (خصوصا از نوع سرویس زیرساخت)، چندین نوع خطا ممکن است ا...» ایجاد کرد) |
بدون خلاصۀ ویرایش |
||
| (یک نسخهٔ میانیِ ایجادشده توسط همین کاربر نشان داده نشد) | |||
| خط ۱: | خط ۱: | ||
در ارایه سرویس های ابری (خصوصا از نوع سرویس زیرساخت)، | افزایش دسترس پذیری سرویس از موضوعات داغ در حوزه رایانش ابری است که راهکارهای مختلفی برای آن تا کنون ارایه شده است، اما هر کدام از این راهکارها بر حسب اینکه دسترس پذیری را در چه سطحی کنترل کنند، تفاوت هایی با هم دیگر دارند که در اینجا سعی شده است به جزئیات این موضوع و آخرین کارهای انجام شده در خصوص آن پرداخته شود. پیش از بررسی این راهکارها، نگاهی می اندازیم به انواع خطاها (Failures) که ممکن است در پشته ارایه سرویس رخ دهد. در ارایه سرویس های ابری (خصوصا از نوع سرویس زیرساخت)، بطور کلی 3 نوع خطا ممکن است اتفاق بیفتد: | ||
* '''خطای زیرساخت:''' این نوع خطا وقتی است که سخت افزاری که بارکاری بر روی آن قرار دارد دچار مشکل شود. بروز خطا در فوق ناظر نیز از جمله خطاهای زیرساخت محسوب میشود که مجموع بارکاری روی آن را تحت تاثیر قرار میدهد. | * '''خطای زیرساخت:''' این نوع خطا وقتی است که سخت افزاری که بارکاری بر روی آن قرار دارد دچار مشکل شود. بروز خطا در فوق ناظر نیز از جمله خطاهای زیرساخت محسوب میشود که مجموع بارکاری روی آن را تحت تاثیر قرار میدهد. | ||
* '''خطای سیستم عامل میهمان:''' در این خطا، سیستم عاملی که روی ماشین مجازی نصب شده است دچار خطا میشود و ممکن است باعث توقت اجرای آن شود. این در حالی است که فوق ناظر هنوز به کار خود ادامه میدهد. | * '''خطای سیستم عامل میهمان:''' در این خطا، سیستم عاملی که روی ماشین مجازی نصب شده است دچار خطا میشود و ممکن است باعث توقت اجرای آن شود. این در حالی است که فوق ناظر هنوز به کار خود ادامه میدهد. | ||
| خط ۶: | خط ۵: | ||
هر کدام از این نوع خطاها با رویکرد متفاوتی مدیریت میشوند: | هر کدام از این نوع خطاها با رویکرد متفاوتی مدیریت میشوند: | ||
* '''مدیریت خطاهای سطح زیرساخت:''' معمولا این روش با استفاده از معماری های HA در استقرار ابزارهای زیرساخت قابل تامین است که در آن یک افزونگی در استقرار اجزای نرم افزاری و سخت افزاری ایجاد میشود. مثلا در پروژه اپن استک، نحوه ایجاد این معماری در لینک های زیر شرح داده شده است: | * '''مدیریت خطاهای سطح زیرساخت:''' معمولا این روش با استفاده از معماری های HA در استقرار ابزارهای زیرساخت قابل تامین است که در آن یک افزونگی در استقرار اجزای نرم افزاری و سخت افزاری ایجاد میشود. مثلا در پروژه اپن استک، نحوه ایجاد این معماری در لینک های زیر شرح داده شده است که عمدتا مبتنی بر ابزاری به نام Pacemaker است که وظیفه آن ایجاد یک کلاستر با دسترس پذیری بالا است: | ||
:http://docs.openstack.org/high-availability-guide/content | :http://docs.openstack.org/high-availability-guide/content | ||
:https://openstack.redhat.com/HA_Architecture | :https://openstack.redhat.com/HA_Architecture | ||
:با این حال در خصوص چگونگی ایجاد HA در خود بارکاری مخصوصا وقتی که از جنس محاسباتی است، چالش های زیادی وجود دارد. با | :با این حال در خصوص چگونگی ایجاد HA در خود بارکاری مخصوصا وقتی که از جنس محاسباتی است، چالش های زیادی وجود دارد. در حال حاضر سعی مشود با بکارگیری برخی الگوهای طراحی خاص، ریسک این موضوع تا حدی کاهش داده شود. | ||
* '''مدیریت خطاهای سطح سیستم عامل میهمان:''' این موضوع معمولا از طریق کنترل Heartbeat ماشین مجازی (که به روشهای مختلفی انجام میشود) قابل مدیریت می باشد. الگویی که شرکت هایی نظیر وی ام ویر با عنوان FT و HA ارایه میدهند نیز عمدتا برای مدیریت خطا در این سطح می باشد که برای ابرهای خصوصی قابل استفاده است. اما در خصوص ابرهای عمومی در پروژه اپن استک برای مدیریت این موضوع، در درایور فوق ناظرهایی نظیر libvirt/kvm راهکاری در نظر گرفته شده است که بتواند وقوع خطا در سطح سیستم عامل را شناسایی کرده و در صورت نیاز دستور راه اندازی مجدد ماشین مجازی بصورت خودکار صادر گردد. در نتیجه این امکان وجود خواهد داشت که بتوان از طریق API امکان کنترل سفارشی این موضوع را برای کاربر نیز فراهم کرد. | |||
* '''مدیریت خطا در سطح برنامه کاربردی:''' در ارایه سرویس های زیرساخت، مدیریت این موضوع به کاربر نهایی بستگی دارد، اما تلاش زیادی در حال انجام است که راهکارهایی در پشته ابری در نظر گرفته شود تا امکان مانیتورینگ سطح برنامه های کاربردی نیز در محصولات ابری فراهم شود. این موضوع در پروژه هایی نظیر HEAT (از زیرمجموعه اپن استک) قابل پیگیری است که سعی میشود الگوهای قابل تکرار از استقرار برنامه های کاربردی تهیه شود تا صرف نظر از بحث خودکارسازی مراحل استقرار، بتوان کنترل بیشتری روی موضوع نظارت و دسترس پذیری سرویس بدست آورد. | |||
نسخهٔ کنونی تا ۱۹ ژوئن ۲۰۱۵، ساعت ۲۲:۵۳
افزایش دسترس پذیری سرویس از موضوعات داغ در حوزه رایانش ابری است که راهکارهای مختلفی برای آن تا کنون ارایه شده است، اما هر کدام از این راهکارها بر حسب اینکه دسترس پذیری را در چه سطحی کنترل کنند، تفاوت هایی با هم دیگر دارند که در اینجا سعی شده است به جزئیات این موضوع و آخرین کارهای انجام شده در خصوص آن پرداخته شود. پیش از بررسی این راهکارها، نگاهی می اندازیم به انواع خطاها (Failures) که ممکن است در پشته ارایه سرویس رخ دهد. در ارایه سرویس های ابری (خصوصا از نوع سرویس زیرساخت)، بطور کلی 3 نوع خطا ممکن است اتفاق بیفتد:
- خطای زیرساخت: این نوع خطا وقتی است که سخت افزاری که بارکاری بر روی آن قرار دارد دچار مشکل شود. بروز خطا در فوق ناظر نیز از جمله خطاهای زیرساخت محسوب میشود که مجموع بارکاری روی آن را تحت تاثیر قرار میدهد.
- خطای سیستم عامل میهمان: در این خطا، سیستم عاملی که روی ماشین مجازی نصب شده است دچار خطا میشود و ممکن است باعث توقت اجرای آن شود. این در حالی است که فوق ناظر هنوز به کار خود ادامه میدهد.
- خطای برنامه کاربردی: مستقل از زیرساخت، بروز خطا در خود برنامه کاربردی نیز ممکن است اتفاق بیفتد که در این دسته قرار میگیرد.
هر کدام از این نوع خطاها با رویکرد متفاوتی مدیریت میشوند:
- مدیریت خطاهای سطح زیرساخت: معمولا این روش با استفاده از معماری های HA در استقرار ابزارهای زیرساخت قابل تامین است که در آن یک افزونگی در استقرار اجزای نرم افزاری و سخت افزاری ایجاد میشود. مثلا در پروژه اپن استک، نحوه ایجاد این معماری در لینک های زیر شرح داده شده است که عمدتا مبتنی بر ابزاری به نام Pacemaker است که وظیفه آن ایجاد یک کلاستر با دسترس پذیری بالا است:
- http://docs.openstack.org/high-availability-guide/content
- https://openstack.redhat.com/HA_Architecture
- با این حال در خصوص چگونگی ایجاد HA در خود بارکاری مخصوصا وقتی که از جنس محاسباتی است، چالش های زیادی وجود دارد. در حال حاضر سعی مشود با بکارگیری برخی الگوهای طراحی خاص، ریسک این موضوع تا حدی کاهش داده شود.
- مدیریت خطاهای سطح سیستم عامل میهمان: این موضوع معمولا از طریق کنترل Heartbeat ماشین مجازی (که به روشهای مختلفی انجام میشود) قابل مدیریت می باشد. الگویی که شرکت هایی نظیر وی ام ویر با عنوان FT و HA ارایه میدهند نیز عمدتا برای مدیریت خطا در این سطح می باشد که برای ابرهای خصوصی قابل استفاده است. اما در خصوص ابرهای عمومی در پروژه اپن استک برای مدیریت این موضوع، در درایور فوق ناظرهایی نظیر libvirt/kvm راهکاری در نظر گرفته شده است که بتواند وقوع خطا در سطح سیستم عامل را شناسایی کرده و در صورت نیاز دستور راه اندازی مجدد ماشین مجازی بصورت خودکار صادر گردد. در نتیجه این امکان وجود خواهد داشت که بتوان از طریق API امکان کنترل سفارشی این موضوع را برای کاربر نیز فراهم کرد.
- مدیریت خطا در سطح برنامه کاربردی: در ارایه سرویس های زیرساخت، مدیریت این موضوع به کاربر نهایی بستگی دارد، اما تلاش زیادی در حال انجام است که راهکارهایی در پشته ابری در نظر گرفته شود تا امکان مانیتورینگ سطح برنامه های کاربردی نیز در محصولات ابری فراهم شود. این موضوع در پروژه هایی نظیر HEAT (از زیرمجموعه اپن استک) قابل پیگیری است که سعی میشود الگوهای قابل تکرار از استقرار برنامه های کاربردی تهیه شود تا صرف نظر از بحث خودکارسازی مراحل استقرار، بتوان کنترل بیشتری روی موضوع نظارت و دسترس پذیری سرویس بدست آورد.