همانطور که گفته شد SLA قراردادی بین فراهم­کننده و مشتری و بیان­کننده جزئیات منابعی که باید فراهم شوند، هزینه­ای که باید پرداخت شود و پارامترهای QoS که فراهم­کننده باید آنها را تامین کند می­باشد. برای برآورده کردن درخواست­های مشتری به منظور افزایش سهم بازار و کاهش هزینه باید موارد زیر مورد توجه قرار گرفته شوند.

چگونگی مدیریت تغییر پویای درخواست­های مشتری
چگونگی مواجه شدن با ناهمگونی زیرساخت
چگونگی نگاشت نیازهای مشتری به پارامترهای سطح زیرساخت
برای مجزاسازی و برطرف کردن درخواست­ها بر مبنای سودمندی مطلوب کاربر چندین مشکل درباره تخصیص منبع مبتنی بر 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­ کاربران به طور خودکار مدیریت می­ کند. منابع اضافی در زمان نیاز تهیه شده و بعد از رفع نیاز حذف می­شوند.

شکل۴-۷: الگوریتم مبتنی بر توافق نامه سطح سرویس در Aneka ]15[.
وقتی سرویس زمانبند یک کار جدید را دریافت می­ کند یا وظیفه ­ای تمام می­ شود، تخمین می­زند که آیا فرجه می ­تواند با تعداد منابع تخصیص­­یافته کنونی به کار به دست آید یا نه، از طرفی از آنجایی که تخمین اولیه داده شده توسط کاربر برای زمان اجرا ممکن است غیردقیق باشد، تخمین با داده به دست آمده از اجرای واقعی وظایف بروزرسانی می­ شود. اگر منابع اضافی مورد نیاز نباشد، زمانبند چک می­ کند که آیا برخی از منابع تخصیص­یافته می­توانند از کار حذف شوند یا نه. اگر زمانبند تشخیص دهد که فرجه می ­تواند با منابع کمتر، با توجه تخمین بروزرسانی­شده زمان اجرای وظیفه رعایت شود منابع اضافی حذف شده و در اختیار دیگر کارها قرار می­گیرد. منابع مورد نیاز به سرویس “تهیه مبع پویا” فرستاده می­ شود. این بسترمی­تواند به صورت موثری نیازهای QoS ابزارهای کاربردی را بوسیله تخصیص پویای منابع به صورت مقرون­به­صرفه­ای برطرف کند. در ]۱۶[ پیاده سازی دیگری از الگوریتم مربوط به فرجه در Aneka بررسی شده است.
هیورستیک معرفی شده در ]۲۵[ زمانبندی ابزارهای کاربردی روی ماشین­های مجازی بر اساس SLA و استقرار ماشین­های مجازی روی منابع فیزیکی بر اساس قابلیت در دسترس بودن آنها را بررسی می­ کند. در شکل ۴-۸ الگوریتم زمانبندی این روش ارائه شده است. ابتدا درخواست سرویس مشتری که شامل SLA است، لیست منابع در دسترس و لیست ماشین­های مجازی موجود بررسی می­ شود. سپس متوازن­کننده تعیین می­ کند کدام ابزار کاربردی روی کدام ماشین مجازی مستقر شود. اگر ماشین مجازی مناسبی موجود نباشد در صورت در دسترس بودن منابع فیزیکی، ماشین مجازی جدید ساخته می­ شود و اگر بعد از یک دوره خاص درخواست نتواند اجرا شود پیغام خطا می­دهد و در غیر این صورت تخصیص صورت می­گیرد. شکل ۴-۹ الگوریتم توازن بار این روش را نشان می­دهد.