همانطور که گفته شد SLA قراردادی بین فراهمکننده و مشتری و بیانکننده جزئیات منابعی که باید فراهم شوند، هزینهای که باید پرداخت شود و پارامترهای QoS که فراهمکننده باید آنها را تامین کند میباشد. برای برآورده کردن درخواستهای مشتری به منظور افزایش سهم بازار و کاهش هزینه باید موارد زیر مورد توجه قرار گرفته شوند.
( اینجا فقط تکه ای از متن پایان نامه درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )
چگونگی مدیریت تغییر پویای درخواستهای مشتری
چگونگی مواجه شدن با ناهمگونی زیرساخت
چگونگی نگاشت نیازهای مشتری به پارامترهای سطح زیرساخت
برای مجزاسازی و برطرف کردن درخواستها بر مبنای سودمندی مطلوب کاربر چندین مشکل درباره تخصیص منبع مبتنی بر SLA وجود دارد. یک دستهبندی از این مشکلات در شکل ۴-۴ نمایش داده شده است ]۱۵[.
شکل ۴-۴: مشکلات تخصیص منبع مبتنی بر SLA ]15[.
۴-۷-۱ مروری بر مطالعات انجام شده در زمینه تخصیص منبع مبتنی بر SLA در محیطهای محاسبات ابری
شکل ۴-۵ نشاندهنده مدل استقرار در ابر و سناریویی از ترکیب سه لایه متفاوت تهیه منبع برای پاسخگویی به درخواستهای مشتری است. با توجه به شکل ابتدا مشتری درخواست سرویس را در سامانه سرویس قرار میدهد (مرحله ۱). سامانه درخواستها را برای اعتبارسنجی به مولفه پردازش درخواست میفرستد (مرحله ۲). اگر درخواست معتبر باشد به زمانبند میرود (مرحله ۳). زمانبند VM مناسب را از طریق موتور تهیه منبع[۲۰] که در لایه “PaaS” قرار دارد برای استقرار سرویس درخواست شده انتخاب می کند و متوازنکننده، توازن بار را بین ماشینهای مجازی انجام میدهد (مرحله ۴). ماشینهای مجازی در لایه معیارهای منبع سطح پایین در لایه “IaaS” نظارت میشوند (مرحله ۶). عملیات در مورد نقض SLA بررسی میشوند (مرحله ۷). وضعیت سرویس به سامانه سرویس فرستاده می شود (مرحله ۸). شکل ۴-۶ نشاندهنده معماری تخصیص منبع مبتنی بر SLA با چهار بخش مهم است که در ادامه توضیح داده شده اند.
شکل ۴-۵: مدل استقرار و تهیه در ابر ]۱۵[.
کاربر/دلال[۲۱]: کاربر با سیستمهای مدیریتی از طریق دلال ارتباط برقرار می کند. دلال درخواستهای کاربر را در ابر برای پردازش ثبت می کند.
تخصیصدهنده منبع SLA: واسط بین محیط ابر و کاربر/دلال است و شامل قسمت های زیر است.
آزمونگر درخواست سرویس و کنترل ورودی: درخواست سرویس کاربر ابتدا به وسیله این مکانیزم تفسیر می شود تا نیازهای QoS درک شوند. این مکانیزم تضمین می کند که هیچ نقص SLA وجود ندارد (با بهره گرفتن از کاهش شانس بار بیش از حد منابع[۲۲]– که به موجب آن درخواستهای دیگر به دلیل کمبود منابع در دسترس انجام نمیشوند)، این مکانیزم نیاز به اطلاعات آخرین وضعیت منابع در دسترس (از مکانیزم نظارت بر VM) و پردازش بار کاری (از مکانیزم نظارت بر درخواست سرویس) دارد تا بتواند تصمیمات تخصیص مؤثری را انجام دهد، سپس درخواستها را به VMها اختصاص میدهد.
شکل ۴-۶: چارچوب معماری سیستم مبتنی بر SLA ]25[.
مدیریت منبع خودکار: تضمین می کند فراهمکنندگان ابر میتوانند حجم زیادی درخواست را بدون نقص SLA پاسخگو باشند. مدیریت منبع خودکار به صورت پویا منابع را با بهره گرفتن از مهاجرت VM مدیریت می کند.
تعیین قیمت: روشی برای مدیریت تقاضای سرویس از منابع ابر و نیز ماکزیممسازی سود فراهمکننده است.
حسابداری و مدیریت SLA: مدیریت SLA مؤلفهای است که SLA مشتریان با فراهمکنندگان و تاریخچه اجرای آنرا پیگیری می کند. براساس SLA، مکانیزم حسابداری استفاده واقعی منابع درخواستی را نگهداری می کند تا هزینه نهایی را بتوان محاسبه کرد، علاوه بر این سوابق اطلاعات مربوط به استفاده را نگهداری میشوند و به وسیله مکانیزم آزمونگر درخواست و کنترل ورودی برای بهبود تصمیمات تخصیص منبع استفاده میشوند.
نظارت بر ابزار کاربردی و VM: براساس سرویس فراهم شده، سیستم مدیریت منبع باید کارایی و وضعیت منابع را در سطوح مختلف پیگیری کند.
توزیعکننده: ابزار کاربردی را روی منبع مجازی مناسب مستقر می کند. همچنین وظیفه ایجاد تصویر VM و آغازش بر روی میزبانهای فیزیکی انتخاب شده را بر عهده دارد.
نظارت بر درخواست سرویس: پیگیری پیشرفت اجرای درخواستهای سرویس را انجام میدهد.
ماشین مجازی: چندین ماشین مجازی میتوانند به صورت خودکار شروع و متوقف شوند تا درخواست پذیرفتهشده انجام شود.
ماشین فیزیکی: شامل مرکز داده و سایر منابع برای برطرف کردن درخواستها میباشد.
در ]۱۵[ با توجه به معماری مذکور، تهیه منبع در Aneka که یک بستر به عنوان سرویس شامل یک واسط برنامهنویسی ابزارهای کاربردی[۲۳] برای توسعه ابزارهای کاربردی میباشد بررسی شده است که در آن دو سرویس مهم برای تشخیص چارچوب مبتنی بر SLA، سرویس زمانبند و سرویس تهیه منبع است. توافقنامه سطح سرویس به صورت فرجه-تخمین زمان اجرای هر وظیفه از یک ابزار کاربردی- برای اجرای ابزارهای کاربردی تعریف شده است. این فرایند به صورت مختصر در الگوریتم شکل ۴-۷ شرح داده شده است. این ابزارفرایند تهیه منبع پویا را به منظور برطرف کردن SLA کاربران به طور خودکار مدیریت می کند. منابع اضافی در زمان نیاز تهیه شده و بعد از رفع نیاز حذف میشوند.
| Algorithm in Aneka | |
| {When a task finishes or a new job is received: Updates estimation of task runtime; Defines estimated job completion time with current amount of resources; IF )completion time > deadline( THEN { Determines number of extra resources required Submits a request for resources to the Provisioner } Else { IF )resources can be released( THEN { Submits request for release of resources to the Provisioner } } } |
|
شکل۴-۷: الگوریتم مبتنی بر توافق نامه سطح سرویس در Aneka ]15[.
وقتی سرویس زمانبند یک کار جدید را دریافت می کند یا وظیفه ای تمام می شود، تخمین میزند که آیا فرجه می تواند با تعداد منابع تخصیصیافته کنونی به کار به دست آید یا نه، از طرفی از آنجایی که تخمین اولیه داده شده توسط کاربر برای زمان اجرا ممکن است غیردقیق باشد، تخمین با داده به دست آمده از اجرای واقعی وظایف بروزرسانی می شود. اگر منابع اضافی مورد نیاز نباشد، زمانبند چک می کند که آیا برخی از منابع تخصیصیافته میتوانند از کار حذف شوند یا نه. اگر زمانبند تشخیص دهد که فرجه می تواند با منابع کمتر، با توجه تخمین بروزرسانیشده زمان اجرای وظیفه رعایت شود منابع اضافی حذف شده و در اختیار دیگر کارها قرار میگیرد. منابع مورد نیاز به سرویس “تهیه مبع پویا” فرستاده می شود. این بسترمیتواند به صورت موثری نیازهای QoS ابزارهای کاربردی را بوسیله تخصیص پویای منابع به صورت مقرونبهصرفهای برطرف کند. در ]۱۶[ پیاده سازی دیگری از الگوریتم مربوط به فرجه در Aneka بررسی شده است.
هیورستیک معرفی شده در ]۲۵[ زمانبندی ابزارهای کاربردی روی ماشینهای مجازی بر اساس SLA و استقرار ماشینهای مجازی روی منابع فیزیکی بر اساس قابلیت در دسترس بودن آنها را بررسی می کند. در شکل ۴-۸ الگوریتم زمانبندی این روش ارائه شده است. ابتدا درخواست سرویس مشتری که شامل SLA است، لیست منابع در دسترس و لیست ماشینهای مجازی موجود بررسی می شود. سپس متوازنکننده تعیین می کند کدام ابزار کاربردی روی کدام ماشین مجازی مستقر شود. اگر ماشین مجازی مناسبی موجود نباشد در صورت در دسترس بودن منابع فیزیکی، ماشین مجازی جدید ساخته می شود و اگر بعد از یک دوره خاص درخواست نتواند اجرا شود پیغام خطا میدهد و در غیر این صورت تخصیص صورت میگیرد. شکل ۴-۹ الگوریتم توازن بار این روش را نشان میدهد.
