کنترل ورودی و زمانبندی: ایده اصلی این است که تقاضای منبع در پنجره زمانی فعلی نظارت شود تا بتوان درباره تخصیص سرور و نیز ورود کار در پنجره زمانی بعدی تصمیم گیری کرد. در هر چرخه زمانبندی، کنترل ورودی و زمانبندی می تواند سه عملکرد را انجام دهد که شامل کنترل ورودی، اجرای SLA و مقیاسپذیری خودکار است.
کنترل وروردی: در این فرایند درباره اینکه ابزاری می تواند بر مبنای منابع در دسترس و نیازهای QoSاش پذیرفته و اجرا شود تصمیم گرفته می شود. به منظور تخمین اینکه چه مقدار منابع در دسترس خواهد بود مدل ANN استفاده می شود. اگر منابع آزاد در یک میزبان برای اجرای ابزاری کافی باشد آن ابزار پذیرفته می شود. زمانبندی بر اساس یکسری قوانین انجام می شود. در تخصیص آغازین برای ابزارهای تراکنشی منابع رزرو شده همارز با تقاضای زمان اوج است و برای ابزارهای غیرمحاورهای زمانبند تلاش می کند تا منابع باقیمانده در میزبانی که در حال اجرای ابزار تراکنشی است را تخصیص دهد، این کار باعث کاهش نقض SLA و کاهش سربار شبکه به دلیل کاهش مهاجرت VMها می شود.
(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))
مدل 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 (بار کاری دستهای غیر محاورهای) میباشند. در این پایان نامه کارها به دو دسته کارهای با اولویت بالا و کارهای با اولویت پایین تقسیم شده اند و بر نوع بار کاری خاصی تمرکز ندارد.
جدول ۳-۴: بررسی برخی روشهای مطرح شده در این فصل.
[چهارشنبه 1400-09-24] [ 11:02:00 ب.ظ ]
|