کنترل ورودی و زمانبندی: ایده اصلی این است که تقاضای منبع در پنجره زمانی فعلی نظارت شود تا بتوان درباره تخصیص سرور و نیز ورود کار در پنجره زمانی بعدی تصمیم ­گیری کرد. در هر چرخه زمانبندی، کنترل ورودی و زمانبندی می ­تواند سه عملکرد را انجام دهد که شامل کنترل ورودی، اجرای SLA و مقیاس­پذیری خودکار است.
کنترل وروردی: در این فرایند درباره اینکه ابزاری می ­تواند بر مبنای منابع در دسترس و نیازهای QoSاش پذیرفته و اجرا شود تصمیم گرفته می­ شود. به منظور تخمین اینکه چه مقدار منابع در دسترس خواهد بود مدل ANN استفاده می­ شود. اگر منابع آزاد در یک میزبان برای اجرای ابزاری کافی باشد آن ابزار پذیرفته می­ شود. زمانبندی بر اساس یکسری قوانین انجام می­ شود. در تخصیص آغازین برای ابزارهای تراکنشی منابع رزرو شده هم­ارز با تقاضای زمان اوج است و برای ابزارهای غیرمحاوره­ای زمانبند تلاش می­ کند تا منابع باقیمانده در میزبانی که در حال اجرای ابزار تراکنشی است را تخصیص دهد، این کار باعث کاهش نقض SLA و کاهش سربار شبکه به دلیل کاهش مهاجرت VMها می­ شود.
پایان نامه - مقاله - پروژه
مدل SLA برای کار غیر محاوره­ای: مرکز داده درخواست را برای اجرای یک کار دسته­ای غیرمحاوره­ای تنها وقتیکه بتواند آنرا با میزان ظرفیت CPU قبل از پایان مهلتش تخصیص دهد می­پذیرد. در هر لحظه وقتی کاری برای اجرا می­رسد زمانبند ابتدا دسترس­پذیری منابع سرورهای فعال را در جاییکه یک ابزار وبی میزبان شده است بررسی می­ کند. به منظور دانستن اینکه آیا کار می ­تواند با موفقیت با توجه به مهلتش اجرا شود زمان تکمیل و زمان اجرا تخمین زده می­ شود. شکل ۴-۲۴ نشان­دهنده چهار روش است که یک کار می ­تواند زمانبندی شود. اگر کاری بتواند قبل از مهلتش در میزبانی تمام شود کار پذیرفته شده و در غیر اینصورت رد می­ شود.
مدل SLA برای کار تراکنشی: اگر کاربر VMای با ظرفیت C بخواهد درخواست زمانی پذیرفته می­ شود که مرکز داده بتواند VMای با ظرفیت C را روی سروری بدون توجه به منابع استفاده شده بوسیله کارهای محاسباتی سنگین[۲۹] زمانبندی کند. VM وبی بر مبنای best fit زمانبندی می­ شود. شکل ۴-۲۵ چهار امکان برای استقرار VM وبی و شکل ۴-۲۶ الگوریتم مطرح شده را نشان می­ دهند.
شرح الگوریتم: برای اجرای SLA تقاضای منبع برای هر ابزار تراکنشی تا چرخه بعدی زمانبندی مجدد محاسبه می­ شود (خط ۲-۱). اگر VM وبی به منابعی کمتر از آنچه پیش ­بینی شده نیاز داشته باشد (ظرفیت تخصیص داده شده فعلی)، منابع اضافی به HPCVM در حال اجرا روی همان میزبان تخصیص داده خواهد شد (خط ۲۱-۲۰ و ۵-۳)، در غیر اینصورت اگر WEBVM به منابعی بیش از آنچه به او تخصیص­یافته نیاز داشته باشد (و این منابع کمتر از ظرفیت قول داده شده در SLA باشد) منابع بیشتری به WEBVM تخصیص میابد تا تقاضا برطرف شود (خط ۷-۶)، به طور متناظر منابع تخصیص­یافته به HPCVM کاهش خواهد یافت (خط ۸). اگر WEBVM منابعی بیش از آنچه در SLA آمده نیاز داشته باشد تصمیم بر مبنای اینکه آیا کاربر “مقیاس­پذیری خودکار” را انتخاب کرده است یا نه گرفته می­ شود (خط ۱۵-۱۰). این فرایند برای هر ابزار تراکنشی تکرار می­ شود. برای هر کار HPC اگر منابعی روی همان سروری که VM در آن میزبانی شده است در دسترس باشد ظرفیت VMشان افزایش می­یابد (خط ۱۸-۱۷). بر اساس منابع تخصیص­یافته به HPCVM زمان تکمیل کار مجدد محاسبه می­ شود (خط ۲۰). اگر کار HPC درحال اجرایی وجود داشته باشد که به نظر برسد مهلتش درحال اتمام است VM متناظرش مهاجرت میابد (خط ۲۱). فرایند مشابهی برای هر کار HPC در صف کار دسته­ای تکرار می­ شود. زمانبند WEBVMهایی را که در حال اجرا روی سرورهایی هستند که با کمبود منبع مواجهند را مجتمع می­ کند.
شکل ۴-۲۴: کار غیر محاوره­ای ]۳۰[.
شکل ۴-۲۵: کار تراکنشی ]۳۰[.

 

Algorithm 1: SLA Enforcement and Rescheduling
Input: Current Utilization of VMs and Current Resource Demand
Output: Decision on Capacity Planning and Auto-scaling
Notations: VMweb−i: VM running Transactional (Web) Applications;
CurResDemand(VMweb−i): Current Resource Demand; CurAllocResVMweb−i: CurrentAllocated Capacity; ReservedRes(VMweb−i): Reserved VMs Capacity Specified in SLA; VMhpc−i:VM running HPC Application
{FOR each VMweb−i DO
{Clculate the current resource demand CurResDemand(VMweb−i)
IF (CurResDemand(VMweb−i) < CurAllocResVMweb−i) THEN
Reduce the resource capacity of VMweb−i to match the demand
Else IF (CurResDemand(VMweb−i) ≤ ReservedRes(VMweb−i)) THEN
{Increase the resource capacity of VMweb−i to match the demand
Reduce correspondingly the resource capacity allocated to HPC
application (VMhpc−i) on the same server
}
Else IF (SLA contains Auto-scaling Option) THEN
Initiate new VMs and offload the application demand to new VMs
}
FOR Each Batch Job VMhpc−i DO
{IF slack resources available on the server where HPC VM is running THEN
Allocate the slack resources
Recompute the estimated finish time of the job
Reschedule the Batch Job VM if missing the deadline
}
}

شکل ۴-۲۶: الگوریتم اجرای SLA و زمانبندی مجدد ]۳۰[.
در بیشتر مقالات مربوط به تخصیص منبع مبتنی بر SLA تمرکز بر روی میزان استفاده از CPU و RAM بوده است و ورودی/خروجی را مورد توجه قرار نداده­اند. در ]۳۱[ به این موضوع پرداخته شده است و یک مهاجرت VM با بهره گرفتن از دسترسی به حافظه مستقیم از راه دور[۳۰] پیشنهاد شده است تا مهاجرت VMها به صورت موثرتری صورت گیرد. در ]۳۲[ انواع زمانبندی­های وظیفه از قبیل زمانبندی سرویس ابر، زمانبندی در سطح کاربر، زمانبندی ایستا و پویا، زمانبندی بلادرنگ و زمانبندی جریان کار مورد بررسی و مقایسه قرار گرفته است. فرایند استقرار VM، نگاشت VM به PM را انجام می­دهد و در آن منابع محاسباتی PM و منابع VM درخواستی دو ورودی اصلی به مسئله جایگذاری هستند در ]۳۳[ یک الگوریتم استقرار VM بر مبنای الگوریتم هانگارین ]۳۴[ به منظور حمایت از استقرار همروند با چندین نمونه VM ارائه شده است. در این الگوریتم هیچ پارامتر SLA در نظر گرفته نشده است.
در ]۳۵[ یک تکنیک تخصیص مشترک به نام LibraSLA معرفی شده است که سودمندی کارهای جدید پذیرفته شده در کلاستر را بر اساس SLA­شان در نظر می­گیرد. پارامترهای QoS در نظر گرفته شده است که در ادامه توضیح داده شده ­اند. ۱- نوع مهلت: مهلت سخت (کار باید قبل از مهلتش تمام شود) و مهلت نرم (کار می ­تواند با تاخیر انجام شود) ۲- مهلت (Deadline) 3- بودجه ۴- نرخ جریمه و پارامترهای SLA شامل موارد زیر است. ۱- RunTime، ۲- تعداد پروسسورهایی که توسط کار i مورد نیاز است. به منطور بهبود سودمندی مجموع برای کلاستر، LibraSLA نیاز دارد تا به سودمندی هر کار به منظور تعیین اینکه کدام کار بازگشت بالاتری دارد توجه کند. از آنجاییکه SLA هر کار یک تابع جریمه را ترکیب می­ کند، LibraSLA کنترل ورودی را پیاده­سازی می­ کند تا مشخص ­کند که آیا کار جدید در کلاستر بر اساس موارد زیر پذیرفته می­ شود یا خیر. ۱- Returnj2- DeadlineTypenew3-NumProcnew . یک الگوریتم برای نمایش اینکه LibraSLA چگونه تصمیم می­گیرد (اینکه آیا کار جدید براساس گره­های با بالاترین بازگشت پذیرفته می­ شود) و الگوریتمی نیز برای محاسبه بازگشت جدید یک گره ارائه شده است.
نظارت بر ابزار کاری چالش برانگیز است، چرا که سنجه­های نظارت در سطح زیرساخت و بستر نمی ­توانند به راحتی به سنجه­های نظارت در سطح ابزار نگاشت شوند و از طرفی ممکن است چندین ابزار VMهای مشابهی را به اشتراک بگذارند یا یک ابزار روی چندین VM اجرا شود (مثل ابزارهای موازی یا ابزارهای توزیع شده). در ]۳۸[ یک معماری نظارت بر ابزارهای کاربردی معرفی شده است که قادر به مدیریت کل چرخه حیات تهیه منبع سرویس در محیط ابر است و شامل تخصیص منبع به سرویس­ها، زمانبندی­ سرویس­ها، نظارت بر ابزار و شناسایی نقض SLA است. در ]۳۶[ یک روش معرفی شده که بر وظایف مدیریتی روتین خودکار، تحویل منابع فناوری اطلاعات مجازی شده به طور منعطف و رشد ظرفیت سیستم (بدون OverProvisioning و داشتن تاثیر غیر قابل انتطار روی اهداف QoS) متمرکز است. منابع بطور خودکار تهیه شده، گردآوری شده و براساس سیاست­های کسب­وکار بر حسب تقاضا تحویل داده می­شوند.
برای غلبه بر رفتار غیرقطعی، خطا در تخمین­ها و بارکاری پویای مرتبط با تهیه منبع ابر یک مکانیزم تطبیقی پیشنهاد شده است که در آن لایه SaaS شامل یک مکانیزم کنترل ورودی بر مبنای تعداد درخواست­های روی هر نمونه ابزار است. اگر همه نمونه­های روی ابزار مجازی شده دارای K درخواست در صفشان باشند درخواست جدید رد می­ شود، چرا که احتمالا TSاش (زمان سرویس) نقض می­ شود. درخواست­های پذیرفته شده به فراهم­کننده PaaS که سیستم پیشنهادی را پیاده­سازی می­ کند فرستاده می­ شود. بطور خلاصه، سیستم تعداد مورد نیاز از نمونه­های ابزار کاربردی (m) را بسته به QoS جاری، میانگین زمان اجرای فعلی و سودمندی منبع بروزرسانی می­ کند. اگر یک m داده شده برای رعایت QoS کافی نباشد تعداد نمونه­های ابزار کاربردی به m+1 تنظیم می­ شود و جستجوی آینده از این مقدار جدید (m+1) شروع می­ شود. اگر سودمندی منابع مرکز داده پایین باشد تهیه کننده منبع برخی نمونه­های ابزار کاربردی را خراب می­ کند. در این مورد اولین نمونه ­ابزار کاربردی که خراب می­ شود نمونه ­ای است که بیکار است. اگر تعداد نمونه­های بیکار از تعداد نمونه­هایی که باید خراب شوند کمتر باشند، نمونه­هایی که دارای درخواست­های کمتری هستند برای تخریب انتخاب می­شوند، البته آنها فورا تخریب نمی­شوند، بلکه دریافت درخواست­های ورودی بیشتر متوقف می­ شود و وقتی درخواست­های در حال اجرایش تمام شوند تخریب می­شوند، به عبارت دیگر اگر انتظار می­رود نرخ ورود افزایش یابد یا QoS رعایت نشود تهیه­کننده منبع ابزار کاربردی ابتدا نمونه­های ابزار کاربردی که انتخاب شده ­اند تا تخریب شوند، اما هنوز در حال پردازش ابزار کاربردی هستند را پیدا کرده و آنها را از لیست نمونه­هایی که باید تخریب شوند حذف می­ کند تا وقتی که تعداد نمونه­هایی که باید تخریب شوند بدست آید. اگر تعداد نمونه­های ابزار کاربردی که تولید شده نا کافی باشد، به مرکز داده درخواست ساخت نمونه­های مشابه با همان ویژگی نمونه­های از قبل ساخته شده داده می­ شود.
شی مرکز داده فعالیت­های مدیریتی مرکز داده را مدیریت می­ کند. مرکز داده یک متوازن­کننده VM را برای تعیین اینکه کدام VM باید به درخواست بعدی تخصیص یابد استفاده می­ کند. بیشتر متوازن­کننده­ های VM، الگوریتم­های توازن بار نظارت فعال و Throttled هستند. متوازن کننده بار Throttled یک رکورد از حالت هر VM (مشغول/ بیکار) را نگه­ می­دارد و متوازن کننده بار نظارت فعال اطلاعاتی راجع به هر VM وتعداد درخواست­هایی که در حال حاضر در هر VM تخصیص یافته را نگهداری می­ کند. در ]۳۷[ یک متد توازن بار VM پیشنهاد شده است که شامل دو فاز است، در فاز اول سودمندی CPU، میزان حافظه مصرفی مورد نیاز برای هر نمونه، چرخه CPU در هر دسترسی و حافظه هر VM بدست می­یاید. در فاز دوم منابع در دسترس و منابع مورد نیاز مقایسه می­شوند. اگر منابع در دسترس کافی باشند نمونه اضافه می­ شود، در غیر اینصورت نمونه رد می­ شود و در نهایت حالت نمونه به کاربر برگردانده می­ شود.
۴-۸ جمع­بندی
در این فصل ابتدا مفهوم SLA ، مولفه­های SLA، مزایا و چرخه حیات SLA تشریح شد و سپس مروری بر مطالعات انجام شده در زمینه تخصیص منبع مبتنی بر SLA صورت گرفت. جدول ۳-۴ مروری بر الگوریتم­های مطرح شده در این فصل است. موضوع محاسبات ابری مبحثی نو در فناوری اطلاعات می­باشد و در نتیجه مسائل مرتبط به آن مثل تخصیص منبع و یا مسائل امنیتی نیز جدید هستند و همانطور که در این فصل بررسی شد هر یک از پژوهش­ها پارامترهای خاص خود را داشته و امکان مقایسه بین روش­ها از نظر پارامتر و یا برتری روش وجود ندارد، اما در یک جمع­بندی می­توان به موارد زیر اشاره کرد.
در بسیاری از مطالعات صورت گرفته پارامتر مهلت (Dealline) به عنوان تنها پارامتر SLA در نظر گرفته شده است مثل ]۱۵[ و ]۱۶[، چرا که زمان پارامتری کلیدی در اجرای درخواست­ها می­باشد. در الگوریتم ارائه شده در این پایان نامه نیز Dealline به عنوان SLA برای کاربر در نظر گرفته شده است.
در تمام روش­ها هدف فراهم­کنندگان کاهش هزینه، افزایش سود و کسب رضایت مشتری است. در این پایان نامه همین اهداف برای فراهم­کننده SaaS در نظر گرفته شده است.
در برخی از پژوهش­ها الگوریتم­هایی مختص ابزارهای خاص ارائه شده است، چرا که ابزارهای مختلف دارای بار کاری متفاوت هستند و در نتیجه دارای نیازهای Qos و SLAهای متفاوت هستند. به عنوان مثال مطالعه انجام شده در ]۲۸[ برای ابزار ERP و پژوهش­های انجام شده در ]۲۵ [و ]۳۰[ برای ابزارهای وبی (بار کاری تراکنشی) و HPC (بار کاری دسته­ای غیر محاوره­ای) می­باشند. در این پایان نامه کارها به دو دسته کارهای با اولویت بالا و کارهای با اولویت پایین تقسیم شده ­اند و بر نوع بار کاری خاصی تمرکز ندارد.
جدول ۳-۴: بررسی برخی روش­های مطرح شده در این فصل.

موضوعات: بدون موضوع  لینک ثابت


فرم در حال بارگذاری ...