Algorithm 1: Pseudo-code for ProfminVmMaxAvaiSpace

Input request © with QoS parameters, Vm_i
Output: Boolean
Functions:First Time Rent ©
{ IF (there is initiated VM_i with type l matches to the VM typerequested by c) THEN IF (VM_i deployed the same product type as c required) THEN
{ For each initiated VM_i with type l (VM_il) DO
{ IF (VM_i has enough space to place c) THEN
put VM_i into vmList
}
Sort(vmList) according to the available space
Schedule to process c on VMmax, which has maximum available s space
}
Else Initiate new VM with type l and deploy the product type as request c re required
Else While (l+j<=L) loop
{IF (there is initiated VM with next type l+j,where type l+j matches to the VMtype required by request c) THEN
{ Repeat from Step 2 to 13
j++
}
}
}
Upgrade© { IF (upgrade type is ‘add account’) THEN
{ get Id i and type l of VM, which processed the previous r e request from same company as c
IF (VM_i has enough space to place c) THEN
Schedule to process c on VM_i
Else { Repeat step 1 to 21 of First Time Rent©
Transfer data from old VM to new VM
Release space in old VM
}
}
IF (upgrade type is ‘upgrade service’) THEN
Repeat step 7 to 9 of Upgrade©
}

شکل ۴-۲۰: الگوریتم ProfminVmMaxAvaiSpace ]28[.
همانطور که قبلا گفته شد یکی از مسائل پیش روی فراهم­کنندگان ابر اتومات­سازی مدیریت سرورهای مجازی با در نظر گرفتن نیازهای QoS ابزارهای میزبانی شده و نیز هزینه مدیریت منبع است. در ]۲۹[ تحقیقی در اینباره صورت گرفته است که در ادامه به شرح آن پرداخته شده است.
معماری سیستم: در معماری سیستم (شکل ۴-۲۲) مرکزداده شامل یک مجموعه ماشین فیزیکی است که هر یک میزبان چندین VM از طریق یک مدیر VM هستند. فرض شده تعداد ماشین­های فیزیکی ثابت است و همگی متعلق به کلاستر مشابهی هستند و امکان اجرای مهاجرت زنده یک VM بین دو ماشین فیزیکی وجود ندارد. یک محیط ابزار^[۲۶] کاربردی یک ابزار کاربردی میزبان شده بوسیله سیستم ابر را کپسوله می­ کند. هر AE مرتبط با اهداف کارایی خاصی که در قرارداد SLA مشخص شده می­باشد. VMهای در دسترس کاربران باید از بین کلاس­های VM که دارای CPU و RAM مشخصی هستند انتخاب شوند.
شکل ۴-۲۱: استراتژی MaxAvaiSpace ]28[.
شکل ۴-۲۲: معماری سیستم ]۲۹[.
یک ماژول تصمیم محلی^[۲۷] ابزار برای هر AE وجود دارد. هر LDM فرصت تخصیص VMهای بیشتر یا آزادسازی VM موجود به/از AE را بر اساس بارکاری فعلی با بهره گرفتن از سنجه­های سطح سرویس (مثل زمان پاسخ و تعداد درخواست­ها در هر ثانیه) ارزیابی می­ کند. کار اصلی LDM محاسبه یک تابع سودمندی است که معیاری از مشخصه ابزار را می­دهد و این ابزار دارای یک تخصیص منبع مشخص (RAM, CPU) بر اساس بار کاری و اهداف SLAاش است. LDMها با ماژول تصمیم سراسری تعامل دارند. GDM موجودیت تصمیم­ساز داخل حلقه کنترل اتونومیک است و مسئول داوری نیازهای منبعی هر محیط است و با هر LDM به عنوان یک جعبه سیاه رفتار می­ کند. GDM تابع سودمندی هر LDM و نیز سنجه­های کارایی سطح سیستم (مثل بار CPU) از سرورهای فیزیکی و مجازی را به عنوان ورودی دریافت می­ کند و خروجی آن شامل عملیات­های مدیریتی مثل مدیریت چرخه حیات VM و مدیریت مهاجرت زنده VMها و نیز یکسری اعلان توجه که به LDMها فرستاده می­ شود است.

این تذکرات LDM را متوجه می­ کند که ۱- یک VM جدید با ظرفیت منبع خاص به ابزار تخصیص داده شده است. ۲- یک VM موجود upgrade/downgrade شده است ۳- یک VM که برای ابزاری بوده است به انحصار ابزار درآمده و باید سریع توسط ابزار آزاد شود. مولفه­های کلیدی در فرایند زمانبندی یک ابزار کاربردی در VM شامل ۱) کنترل ورودی: تصمیم می­گیرد که آیا VM درخواست شده برای یک ابزار می ­تواند تخصیص یابد و آیا نیازهای QoS­ می­توانند با تعداد منابع دردسترس برآورده شوند یا نه. ۲) مدیر VM: یک VM را آغاز کرده و آنرا به سروری که ظرفیت مورد نظر را دارد تخصیص می­دهد. ۳) زمانبند کار: ابزارها را روی VM تازه آغاز شده زمانبندی می­ کند. ۴) مدیر SLA: SLAهای کنونی و سطح سرویس برای هر ابزار پذیرفته­شده را نظارت می­ کند.
LDM: LDM با دو تابع سودمندی مرتبط است. ۱) تابع سودمندی سطح سرویس ثابت: سطح سرویس را به یک مقدار سودمندی نگاشت می­ کند. ۲) تابع سودمندی سطح منبع پویا: ظرفیت منبع را به یک مقدار سودمندی نگاشت می­ کند و در هر تکرار حلقه کنترل اتونومیک با GDM ارتباط برقرار می­ کند. تابع سودمندی به همراه فرمول­های LDM و GDM در ]۲۹[ تعریف شده است.
GDM: GDM مسئول دو کار مهم است. ۱) تعیین بردار تخصیص VM (N_i) برای هر ابزار a_i (تهیه منبع VMها) و جایگذاری VMها در ماشین­های فیزیکی به گونه­ایکه حداقل ماشین­های فیزیکی فعال باشند (بسته­بندی VMها). این دو فاز به عنوان دو مسئله ارضای محدودیت که توسط یک حل­کننده محدودیت مدیریت می­ شود (شکل ۴-۲۳) بیان شده است.
تهیه منبع VM: در این فاز هدف، یافتن بردار تخصیص VM (N_i) برای هر ابزار a_i است، در حالیکه تلاش می­ شود مقدار سودمندی سراسری (U_global) ماکزیمم شود. خروجی این فاز مجموعه ­ای ازN_iهاست که محدودیت­ها را ارضا و U_global را ماکزیمم می­ کنند. با مقایسه این بردارهای تخصیص با آنهاییکه در تکرارهای قبل بدست آمده بود این نتیجه بدست آمده است که GDM قادر است تعیین کند کدام VMها باید ایجاد شوند، تخریب شوند و یا تغییر سایز یابند.
بسته­بندی VM (VMPacking): این فازN_iها را به عنوان ورودی گرفته و آنها را در یک بردار منفرد V می­ریزد. V لیستی از همه VMهای در حال اجرا در زمان فعلی است. برای هر (PMP_j عضو P) بردار بیت مشخص­کننده مجموعه ­ای از VMهاست که به P_j انتساب داده شده است (مثلا h_J1=1 اگر P_j، VM₁ را میزبان شده باشد). با حل CSP مربوط به این فاز، بردارهای جایگذاری VM (H_i) که برای VMها روی ماشین­های فیزیکی استفاده می­شوند بدست می­آیند. از آنجاییکه GDM به صورت دوره­ای اجرا می­ شود، GDM تفاوتی را با جایگزاری VM تولید شده بعنوان نتایج تکرار قبل را محاسبه می­ کند و این مشخص می­ کند کدام VM نیاز به مهاجرت دارد. در ]۳۰[ از معماری و مفاهیم ]۲۹[ استفاده شده است و دو نوع بار کاری تراکنشی و کارهای دسته­ای غیر محاوره­ای در نظر گرفته شده است. به ابزارها یک مجموعه VM با ظرفیت متغیر پیشنهاد شده است. تسهیلات با مقیاس­پذیری خودکار نیز چنانچه تقاضای منبع از سایز VM تخصیص­یافته بیشتر شود می ­تواند فراهم شود. دو نوع مدل SLA نیز برای ابزارهای تراکنشی و ابزارهای دسته­ای غیرمحاوره­ای ارائه شده است که در ادامه توضیح داده شده ­اند.
شکل ۴-۲۳: حل محدودیت: بسته­بندی تهیه منبع ]۲۹[.
مدل پیش ­بینی: اگر بتوان نیازهای منبع مربوط به یک ابزار را به خوبی پیش ­بینی کرد می­توان سودمندی منبع را با توجه به متفاوت بودن SLA ابزارهای مختلف ماکزیمم کرد. در ]۳۰[ از مدل پیش ­بینی مبتنی بر شبکه عصبی مصنوعی^[۲۸] و الگوریتم انتشار به عقب^۲ استفاده شده است که سودمندی یک روز هر VM از داده ­های یک هفته از یک مجموعه داده را با شبکه حداقل خطای مربع میانه^۳ ریشه نشان می­دهد.