دسترس پذیری بالا
پرش به ناوبری
پرش به جستجو
در ارایه سرویس های ابری (خصوصا از نوع سرویس زیرساخت)، چندین نوع خطا ممکن است اتفاق بیفتد:
- خطای زیرساخت: این نوع خطا وقتی است که سخت افزاری که بارکاری بر روی آن قرار دارد دچار مشکل شود. بروز خطا در فوق ناظر نیز از جمله خطاهای زیرساخت محسوب میشود که مجموع بارکاری روی آن را تحت تاثیر قرار میدهد.
- خطای سیستم عامل میهمان: در این خطا، سیستم عاملی که روی ماشین مجازی نصب شده است دچار خطا میشود و ممکن است باعث توقت اجرای آن شود. این در حالی است که فوق ناظر هنوز به کار خود ادامه میدهد.
- خطای برنامه کاربردی: مستقل از زیرساخت، بروز خطا در خود برنامه کاربردی نیز ممکن است اتفاق بیفتد که در این دسته قرار میگیرد.
هر کدام از این نوع خطاها با رویکرد متفاوتی مدیریت میشوند:
- مدیریت خطاهای سطح زیرساخت: معمولا این روش با استفاده از معماری های HA در استقرار ابزارهای زیرساخت قابل تامین است که در آن یک افزونگی در استقرار اجزای نرم افزاری و سخت افزاری ایجاد میشود. مثلا در پروژه اپن استک، نحوه ایجاد این معماری در لینک های زیر شرح داده شده است که عمدتا مبتنی بر ابزاری به نام Pacemaker است که وظیفه آن ایجاد یک کلاستر با دسترس پذیری بالا است:
- http://docs.openstack.org/high-availability-guide/content
- https://openstack.redhat.com/HA_Architecture
- با این حال در خصوص چگونگی ایجاد HA در خود بارکاری مخصوصا وقتی که از جنس محاسباتی است، چالش های زیادی وجود دارد. در حال حاضر سعی مشود با بکارگیری برخی الگوهای طراحی خاص، ریسک این موضوع تا حدی کاهش داده شود.
- مدیریت خطاهای سطح سیستم عامل میهمان: در پروژه اپن استک برای مدیریت این موضوع، در درایور فوق ناظرهایی نظیر libvirt/kvm راهکاری در نظر گرفته شده است که بتواند وقوع خطا در سطح سیستم عامل را شناسایی کرده و در صورت نیاز دستور راه اندازی مجدد ماشین مجازی بصورت خودکار صادر گردد. در نتیجه این امکان وجود خواهد داشت که بتوان از طریق API امکان کنترل سفارشی این موضوع را برای کاربر نیز فراهم کرد.
- مدیریت خطا در سطح برنامه کاربردی: در ارایه سرویس های زیرساخت، مدیریت این موضوع به کاربر نهایی بستگی دارد، اما تلاش زیادی در حال انجام است که راهکارهایی در پشته ابری در نظر گرفته شود تا امکان مانیتورینگ سطح برنامه های کاربردی نیز در محصولات ابری فراهم شود. این موضوع در پروژه هایی نظیر HEAT (از زیرمجموعه اپن استک) قابل پیگیری است که سعی میشود الگوهای قابل تکرار از استقرار برنامه های کاربردی تهیه شود تا صرف نظر از بحث خودکارسازی مراحل استقرار، بتوان کنترل بیشتری روی موضوع نظارت و دسترس پذیری سرویس بدست آورد.