۳۳- put VMi into AvailableVMList
۳۴- Free that VM which has max free space
۳۵- Deploy NewVMReq on it
۳۶- For requests with α=۰ which has no resources Repeat step 6-47
۳۷- }
۳۸- Else { Put NewVMReq in waiting Queue
۳۹- IF NewVMReq’ deadline is finished THEN
۴۰- { counter ++
۴۱- Return reject
۴۲- Repeat step 23 to 47
۴۳- }
۴۴- }
۴۵- }

 

 

 

شکل ۵-۱: الگوریتم زمانبندی مبتنی بر SLA پیشنهادی.
خط ۱۳-۶: اگر درخواست دارای اولویت پایین باشد بررسی می­ شود که آیا VM شروع شده­ای وجود دارد یا خیر. اگر بیش از یک VM با این ویژگی وجود داشتند آنها بر اساس میزان منابع تخصیص نیافته­شان مرتب شده و سپس به لیست VMهای در دسترس اضافه شده و درخواست در VMای با حداقل فضای خالی مستقر می­ شود.
خط ۲۲-۱۴: اگر VM شروع شده­ای با این شرایط وجود نداشت، درخواست وارد صف می­ شود. وقتی درخواست در صف قرار دارد مهلت درخواست در هر لحظه بررسی می­ شود. اگر مهلت درخواست تمام شود درخواست رد شده و شمارنده اضافه می­ شود. در اینجا فراهم­کننده باید جریمه­ای را به مشتری پرداخت نماید. میزان این جریمه و نحوه محاسبه­اش در فصل بعد شرح داده شده است. برای درخواست پذیرفته نشده تخصیص مجدد صورت می­گیرد. . درخواستی که شمارنده­ا­ش یک باشد به عنوان درخواست با اولویت بالا در نظر گرفته می­ شود و بخش مربوط به α=۱ برایش اجرا می­ شود، یعنی در مرحله تخصیص
پایان نامه - مقاله - پروژه
مجدد دیگر منابعی که برای اجرا به این درخواست داده شود نمی­تواند توسط درخواست بالا گرفته شود و در تخصیص مجدد به عنوان درخواست با اولویت بالا در نظر گرفته می­ شود. اگر مهلت درخواست با اولویت پایین تمام نشده باشد به خط ۶ باز می­گردد.
خط ۲۳: اگر α یک باشد یعنی درخواست اولویت بالا دارد.
خط ۳۱-۲۴: اگر درخواست دارای اولویت بالا باشد بررسی می­ شود که آیا VM شروع شده­ای وجود دارد یا خیر. اگر بیش از یک VM با این ویژگی وجود داشتند آنها بر اساس میزان منابع تخصیص نیافته­شان مرتب شده و سپس به لیست VMهای در دسترس اضافه شده و درخواست در VMای با حداقل فضای خالی مستقر می­ شود.
خط ۳۹-۳۲: اگر VM شروع­شده­ای وجود نداشته باشد از بین VMهای شروع شده با اولویت پایین، یعنی VMای که همه درخواست­های داخلش اولویت پایین دارند منابع گرفته شده و VM به درخواست اولویت بالا تخصیص داده می­ شود و برای درخواست با اولویت پایین که منابعش گرفته شده تخصیص مجدد انجام می­ شود.
خط ۴۷-۴۰: اگر هیچ VM شروع­شده­ و هیچ VM با اولویت پایین وجود نداشته باشند درخواست وارد صف می­ شود. وقتی درخواست در صف قرار دارد مهلت درخواست در هر لحظه بررسی می­ شود. اگر مهلت درخواست تمام شود درخواست رد شده و شمارنده یک می­ شود و تخصیص مجدد صورت می­گیرد. از آنجاییکه شمارنده یک شده است فراهم­کننده جریمه ای را متحمل می­ شود. شکل­های ۵-۲ و ۵-۳ به ترتیب روند نمای روش پیشنهادی برای درخواست­های با اولویت پایین و درخواست­های با اولویت بالا را نشان می­ دهند.
۵-۳ جمع­بندی
در این فصل یک روش زمانبندی برای استقرار درخواست­های یک کاربر بر روی یک مرکز داده در یک ابر خصوصی که شامل چندین VM است، با در نظر گرفتن SLA درخواست­های ورودی کاربر پیشنهاد شده است. در این روش تمایزی بین بار کاری در نظر گرفته نشده است، مثلا بار کاری به دو نوع بار تراکنشی و HPC تقسیم نشده­اند، چرا که ممکن است اجرای یک کار وبی که دارای بار تراکنشی است در زمانی خاص برای کاربر نسبت به کار HPC اولویت بالاتری داشته باشد. هدف آن است که SLA کاربر رعایت شود تا فراهم­کننده مجبور به پرداخت جریمه نشود. در این روش اگر منابع برای اجرای درخواست با اولویت بالا وجود نداشته باشد منابع از درخواست با اولویت پایین گرفته می­ شود. چنانچه درخواستی با اولویت پایین برای یکبار رد شود در مرحله تخصیص مجدد اولویتش بالا در نظر گرفته می­ شود. روش ارائه شده سبب به­ کارگیری موثر منابع ابر می­ شود و همچنین برطرف شدن نیازهای SLA کاربر را تضمین می­ کند. در فصل بعد جزئیات پیاده­سازی تشریح شده و سپس با روش تخصیص ساده و تخصیص ایستا مقایسه شده و مورد ارزیابی قرار گرفته است.
شکل ۵-۲: روندنمای اجرای درخواست­های با اولویت پایین.

شکل ۵-۳: روندنمای اجرای درخواست­های با اولویت بالا.
فصل ششم
پیاده­سازی، ارزیابی
۶-۱ مقدمه
در فصل چهارم یک روش زمانبندی برای استقرار درخواست­های یک کاربر روی چند VM با در نظر گرفتن اولویت و SLA درخواست­های ورودی کاربر در یک ابرخصوصی پیشنهاد شد. در این فصل ابتدا مروری بر برخی ابزارهای شبیه­سازی صورت گرفته و سپس پیاده­سازی روش پیشنهادی که با شبیه­ساز کلودسیم انجام شده است مورد بررسی قرار گرفته و در پایان روش پیشنهادی با یک الگوریتم پایه مورد مقایسه و ارزیابی قرار گرفته است.
۶-۲ ابزارهای شبیه­سازی محیط­های محاسبات ابری
همانطور که گفته شد محاسبات ابری به عنوان تکنولوژی پیشرو برای تحویل سرویس­های محاسباتی به صورت مقیاس­پذیر، قابل اطمینان، ایمن، دارای تحمل خطا و مقیاس­پذیر ظهور کرده است. این سرویس­ها به عنوان SaaS, PaaS و IaaS ارائه شده ­اند و می­توانند به صورت مرکز داده ­های خصوصی (ابر خصوصی) و یا به صورت تجاری برای کلاینت­ها (ابر عمومی) و یا به صورت ترکیبی از ابرهای خصوصی و عمومی (ابرهای ترکیبی) پیشنهاد داده شوند. اکوسیستم معماری­ ابری، همراه با افزایش تقاضا برای تکنولوژی­های فناوری اطلاعات به گونه ­ای که از نظر انرژی مقرون به صرفه باشند و ویژگی­هایی مثل تکرارپذیری را داشته باشد نیاز به متدلوژی­های قابل کنترل برای ارزیابی الگوریتم­ها، ابزارهای کاربردی و سیاست­ها قبل از توسعه واقعی محصولات ابری دارد.
از آنجاییکه به­ کارگیری محیط تست واقعی، آزمایش­ها را با توجه به مقیاس محیط تست محدود می­ کند و سبب انجام آزمایش­های مجدد در مقیاس­های وسیع­ می­ شود روش­های جایگزین برای تست تکنولوژی­ها و روش­های جدید ابری به وجود آمده­اند. یک روش جایگزین، به­ کارگیری ابزارهای شبیه­سازی است. این ابزارها امکان ارزیابی فرضیه ­ها را با توجه به توسعه نرم­افزار در محیطی که می­توان تست­ها را تکرار کرد فراهم می­ کنند. به ویژه در رابطه با محیط­های محاسبات ابری که دسترسی به زیرساخت نیاز به پرداخت هزینه دارد، روش­های مبتنی بر شبیه­سازی مزایای زیادی دارد. از جمله اینکه مشتریان ابر امکان تست سرویس­هایشان را در محیط­های قابل تکرار و قابل کنترل به صورت رایگان خواهند داشت و می­توانند گلوگاه­های کارایی روش­هایشان را قبل از پیاده­سازی ابرهای واقعی برطرف نمایند.
از دیدگاه فراهم­کننده ابر، محیط­های شبیه­سازی امکان ارزیابی سناریوهای مختلف اجاره دادن منابع بر اساس بارکاری و توزیع قیمت را فراهم می­ کنند. در صورت نبود این بسترهای پیاده سازی، مشتریان و فراهم­کنندگان ابر مجبور می­شوند به تئوری­ها و
ارزیابی­های غیر دقیق یا انجام روش­های سعی و خطا که منجر به کارایی غیر مؤثر سرویس­ها و تولید هزینه می­ شود تکیه کنند. در گذشته برای شبیه­سازی محیط­های توزیع­شده از شبیه­سازهایی مثل GridSim، SimGrid، OptoStrim و GangSim استفاده می­شده است، اما از آنجایی که این شبیه­سازها قادر به تفکیک لایه­ های سرویس ابر (Iaas , Paas , Saas) نبودند و نمی­توانستند منابع مجازی شده مورد نیاز ابر را مدل کنند ابزارهایی خاص محیط های ابری ایجاد شدند که از جمله معروف­ترین آنها می­توان به CloudSim، Aneka و Eucalyptus اشاره کرد.
مزایای ابزارهای شبیه­سازی: از جمله مزایای ابزارهای شبیه­ساز می­توان به مواردی مثل در نظر گرفتن تأثیر زمان، انعطاف­پذیری و کاربردی بودن، تست سیاست­های مورد نظر در یک محیط قابل کنترل و قابل تکرار و تنظیم گلوگاه­های سیستم قبل از استقرار روی ابر واقعی اشاره کرد. در ادامه دو ابزار CloudSim و Aneka مورد بررسی قرار گرفته­اند.
۶-۲-۱ Aneka
Anek بستری برای توسعه برنامه ­های کاربردی توزیع­شده فراهم کرده است که به سادگی قابل اندازه ­گیری هستند و از مزایای فراساختارهای مبتنی بر ابر هم استفاده می­ کنند. Aneka یک چارچوب نرم­افزاری مبتنی بر تکنولوژی NET. است که در ابتدا در پروژه Gridbus توسعه داده شد و سپس توسط Manjrasoft به صورت تجاری درآمد. Aneka توسعه برنامه ­های کاربردی توزیع­شده را با فراهم کردن مجموعه ­ای از روش­های متفاوت برای بیان منطق برنامه ­های کاربردی توزیع شده، یک فراساختار یکپارچه که مراقب اجرای برنامه ­های کاربردی توزیع­شده است و مجموعه ­ای از مشخصه­های پیشرفته مانند توانایی رزرو و قیمت­ گذاری گره­ها و یکپارچه شدن با ابرهای موجود مانند AmazonEC2 را آسان کرده است. ابر محاسباتی Aneka مبتنی بر مجموعه ­ای از منابع فیزیکی و مجازی است که این منابع از طریق یک شبکه که می­توانند اینترنت یا یک اینترانت باشد به یکدیگر متصل شده اند. هر کدام از این منابع، نمونه ­ای از ظرف[۳۱]Aneka را میزبانی می­ کنند. ظرف، مشخصه­های مدیریتی اصلی یگ گره تنها را فراهم می­ کند و تمامی دیگر اعمال روی سرویس­هایی که میزبانی می­ کند را به کار می برد.
معماری Aneka: یکی از مشخصه­های اصلی Aneka قابلیت فراهم کردن راه­های متفاوت در بیان برنامه ­های کاربردی توزیع­شده با ارائه مدل­های برنامه­نویسی متفاوت است. آرایش رایجی از Aneka در شکل ۶-۱ نشان داده شده است. قلب این ساختار ظرف Aneka است که واحد توسعه اصلی ابرهای مبتنی بر Aneka است. همانطور که در فصل­های گذشته گفته شد انعطاف­پذیری، قابلیت ارتجاع (کاهش و یا افزایش منابع بر اساس تقاضا)، پرداخت هزینه بر اساس استفاده از خصوصیات اصلی مدل محاسباتی ابر است. معماری و پیاده­سازی ظرف نقش کلیدی در حمایت از این سه مشخصه دارد.
Aneka منعطف است، چون مجموعه سرویس­های موجود در ظرف، طبق نیاز­های خاص برنامه کاربردی توسعه داده می­شوند و قابلیت ارتجاع دارد، چرا که می­توان طبق نیازهای کاربر تعداد گره­های ابر Aneka را افزایش داد و از آنجاییکه ظرف واسط گره میزبان است نظارت، اندازه ­گیری و شارژ هر برنامه کاربردی توزیع­شده­ای که روی Aneka اجرا می­ شود ساده است. ظرف، واحد توسعه اصلی ابرهای مبتنی بر Aneka است. شبکه ظرف­ها میان­افزار Aneka را که میزبان محیط زمان اجرای برنامه ­های کاربردی توزیع­شده است را تعریف می­ کند. Aneka مبتنی بر معماری سرویس­گرا است و ظرف یک مؤلفه سبک وزن است که مشخصه­های مدیریتی اصلی گره را فراهم می­ کند. تمامی دیگر اعمالی که توسط میان­افزار لازم است، به عنوان سرویس پیاده­سازی می­گردند. شکل ۶-۲ پشته سرویس­هایی را که در یک توسعه رایج ظرف پیدا می­ شود نشان می­دهد. به طور کلی چهار گروه سرویس وجود دارد که عبارتند از سرویس­های فابریک۲، سرویس­های پایه۳، سرویس­های اجرایی۴ و سرویس­های نوسنجی۵.
شبکه بنگاه خصوصی
اجرا کننده­ها
اجرا کننده
اجرا کننده
زمانبند
اینترنت
اجرا کننده­ها
ابر خصوصی

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


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