مقالات انگلیسی و ترجمه های فارسی رایگان با فرمت PDF آماده دانلود رایگان میباشند

همچنین ترجمه مقاله با فرمت ورد نیز قابل خریداری و دانلود میباشد

مقاله انگلیسی رایگان (PDF)

ترجمه فارسی رایگان (PDF)

خرید ترجمه با فرمت ورد

فهرست مقاله:

چکیده
مقدمه
کار مرتبط
شرح مدل
فرمول ریاضی
نشانه ها
متغیرهای تصمیم گیری
محدودیت ها
راه حل اکتشافی
مدل اکتشافی
تكنيكهاي اكتشافي رزرو VM
راه حل غیر بهینه
مشکل اصلی فرمول سازی
مسئله فرعی
نتایج
شبیه سازی محیط
اکتشافی
نتایج شبکه کوچک
موارد مختلف تاخیر مجاز
نتایج شبکه بزرگ
نتیجه گیری
تقدیرنامه ها
منابع مالی
مشارکت نویسندگان

بخشی از ترجمه فارسی مقاله:

مقدمه
تقاضای محاسبه ابر برای مشتریان از وعده تبدیل زیرساخت های محاسباتی به یک کالا یا خدمات نشئت می گیرد که سازمان ها دقیقا به همان اندازه ای که آنها استفاده می کنند، برای آن هزینه پرداخت می کنند. این ایده، رویا اجرایی یک شرکت فناوری اطلاعات است. همانطور که تحلیلگر گارتنر یعنی داریل پلومر بیان می کند: “رهبران محصولات تجاری در همه جا، دور از مراکز فناوری اطلاعات به دنبال دریافت برنامه ها ابر هستند .. و برای آنها هزینه پرداخت می کنند مانند اشتراک مجله. هنگامی که این سرویس دیگر مورد نیاز نیست، آنها می توانند این اشتراک را لغو کنند بدون اینکه تجهیزات استفاده شده باشد ” [1] این ایده که محاسبات متمرکز بر شبکه، در آینده است، در اوایل سال 1997 برای رهبران صنعت روشن بود. هیچکسی به غیر از استیو جابز نگفت: ” به هارد دیسک در کامپیوترم نیاز ندارم اگر بتوانم سریعتر به سرور دسترسی پیدا کنم . با حمل و نقل این کامپیوترهای همراه در مقایسه مربوط به روم شرقی می باشد[1] . این نیز برای خرید سازمان ها و برنامه ریزی مراکز داده بزرگ مورد استفاده قرار می گیرد.
به هر حال، عملکرد همچنان عامل مهمی است. اگر – در هر نقطه ای – شک و تردید بیش از توانایی ارائه دهنده به ارائه خدمات با توجه به موافقت نامه های امضا شده سطح خدمات (SLA) رایج می شود، مشتریان ارائه دهندگان دیگری را بررسی و انتخاب می کنند. آنها حتی می توانند بازگشت به مدل خرید و نگهداری را بررسی کنند. ارائه دهندگان تحت فشار ثابت برای بهبود عملکرد هستند، گزینه های استقرار منابع متنوع تر، بهبود قابلیت استفاده از خدمات و افزایش قابلیت حمل برنامه را ارائه می دهند. یک سلاح اصلی در اینجا یک سیستم تخصیص منابع کارآمد است. همانطور که در شکل 1، در سناریوی ابر، مشتریان قادر به اجاره ماشین های مجازی (VMs) از ارائه دهندگان ابر هستند. ارائه دهندگان چندین مدل استقراری ارائه می دهند که در آن پیکربندی VM در محاسبات قدرت، حافظه، ظرفیت ذخیره سازی و پلت فرم فقط چند عامل را نامگذاری می کند.

در طول دوره اجاره، مشتریان نیاز به قابلیت های شبکه دارند. مشتریان اطلاعات را اغلب در میان ستاد مرکزی مشتری (یا ابر خصوصی) و VM ها یا بین دو مشتری VMs تبادل می کنند. هدف در اینجا برنامه ریزی برای برنامه های رزرو VM و درخواست اتصال در سریعترین راه ممکن است در حالی که از منابع مرکز داده بطور بهینه استفاده می کنند. این امر با ظهور مفاهیم داده بزرگتر سخت تر می شود. IBM چالش داده های بیشتری را به 4 ابعاد مختلف به 4 Vs: یعنی حجم، سرعت، تنوع و صداقت خلاصه می کند [2]. با اکثر شرکت هایی که حداقل 100 TB داده ذخیره شده دارند و با 18.6 میلیارد شبکه ارتباطی که فعلا در حال حاضر موجود برآورد می شود[2]، بازده تخصیص منابع هرگز اهمیت زیادی نداشته است.
هنگامی که روش تخصیص منابع با وظیفه طراحی مواجه می شود، چالش های داخلی و خارجی بسیاری را باید در نظر گرفت. تلاش برای خلاصه کردن این چالش ها در [3] یافت می شود. چالش های خارجی عبارتند از چالش های مقررات، جغرافیا و همچنین خواسته های مشتری مرتبط با ذخیره داده ها و مدیریت آنها می باشد. این محدودیت ها منجر به محدودیت در محل VM های محدود شده و محدودیت ها به مکان و انتقال داده می شود. چالش های خارجی نیز شامل بهینه سازی مدل شارژ می باشد به طوری که حداکثر درآمد را ایجاد می کند. چالش های داخلی مورد بحث در [3] شامل مسائل مربوط به داده های محلی نیز می باشد. ماهیت یک برنامه از لحاظ داشتن اطلاعات فشرده باید در هنگام قرار دادن VM و برنامه ریزی اتصالات مربوط به این برنامه بررسی شود.
برای دستیابی به اهداف عملکرد و هزینه مذکور، ارائه دهندگان محاسبات ابری نیاز به سیستم تخصیص منابع جامعی دارند که هر دو منابع شبکه و محاسبات را مدیریت می کند. چنین سیستمی کارآمد می تواند تأثیر مهمی داشته باشد زیرا منابع اضافی به طور مستقیم به درآمد منتقل می شوند. بخش های زیر به شرح ذیل سازماندهی می شوند: بحث در مورد تلاش های تحقیقاتی مربوطه در بخش زیر معرفی می شود که منجر به مشارکت در این مقاله شده است. شرح مدل دقیق در بخش «شرح مدل» آمده است. بخش “فرمولاسيون ریاضی” فرمول مسئله ریاضی را ارائه می دهد. روش های اکتشافی در قسمت “راه حل اکتشافی” ارائه شده است. راه حل های غیربهینه در بخش “راه حل های غربهینه” ارائه شده است. نتایج در بخش “نتایج” نشان داده و تجزیه و تحلیل می شوند. در نهایت بخش “نتیجه گیری” مقاله را نتیجه گیری و کار آتی را معرفی می کند.

بخشی از مقاله انگلیسی:

Introduction

The appeal of cloud computing for clients comes from the promise of transforming computing infrastructure into a commodity or a service that organizations pay for exactly as much as they use. This idea is an IT corporation executive’s dream. As Gartner analyst Daryl Plummer puts it: “Line-of-business leaders everywhere are bypassing IT departments to get applications from the cloud .. and paying for them like they would a magazine subscription. And when the service is no longer required, they can cancel that subscription with no equipment left unused in the corner” [1]. The idea that centralized computing over the network is the future, was clear to industry leaders as early as 1997. None other than Steve Jobs said:“I don’t need a hard disk in my computer if I can get to the server faster .. carrying around these non-connected computers is byzantine by comparison” [1]. This applies as well to organizations purchasing and planning large data centers. However, performance remains the critical factor. If – at any point- doubts are cast over a provider’s ability to deliver the service according to the Service Level Agreements (SLAs) signed, clients will consider moving to other providers. They might even consider going back to the buy-and-maintain model. Providers are under constant pressure to improve performance, offer more diverse resource deployment options, improve service usability, and enhance application portability. A main weapon here is an efficient resource allocation system. As in Fig. 1, in the cloud scenario, clients are able to rent Virtual Machines (VMs) from cloud providers. Providers offer several deployment models where VM configuration differs in computing power, memory, storage capacity and platform just to name a few factors. During the rental period, clients require network capabilities. Clients will have data frequently exchanged between client headquarters (or private clouds) and VMs or between two client VMs. The aim here for a scheduler is to schedule VM reservation requests and connection requests in the fastest possible way while using the data center resources optimally. This task is getting even harder with the emergence of the big data concepts. IBM summarized big data challenges into 4 different dimensions referred to as the 4 Vs: Volume, Velocity, Variety, and Veracity [2]. With most companies owning at least 100 TB of data stored and with 18.6 billion network connections estimated to exist now [2], resource allocation efficiency has never been so important. When faced by the task of designing a resource allocation methodology, many external and internal challenges should be considered. An attempt to summarize these challenges can be found in [3]. External challenges include regulative and geographical challenges as well as client demands related to data warehousing and handling. These limitations result in constraints on the location of the reserved VMs and restrictions to the data location and movements. External challenges also include optimizing the charging model in such a way that generates maximum revenue. Internal challenges discussed in [3] include also data locality issues. The nature of an application in terms of being data intensive should be considered while placing the VMs and scheduling connections related to this application. To achieve these performance and cost objectives, cloud computing providers need a comprehensive resource allocation system that manages both computational and network resources. Such an efficient system would have a major financial impact as excess resources translate directly into revenues. The following sections are organized as follows: a discussion of the related research efforts is introduced in the following section leading to this paper’s contribution. Detailed model description is given in “Model description” section. “Mathematical formulation” section presents the mathematical formulation of the problem. The heuristic methods are presented in “Heuristic solution” section. The suboptimal solution is presented in “Suboptimal solution” section. Results are shown and analyzed in “Results” section. Finally, “Conclusion” section concludes the paper and conveys future work.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

3. مهاجرت زنده VM با استفاده از DSM
دستگاه منبع (Worth) دو ماشین مجازی (Flake و Flask) را اجرا می کند؛ سیستم عامل مهمان (Win7) از Flake مهاجرت خواهد کرد. این فرایند با تحریک تابع مهاجرت از XenServer XAPI آغاز میگردد که پس از آن فرایند مهاجرت برای اجرای پیش نسخه ای مهاجرت VM شروع خواهد شد. DSM دسترسی به حافظه مشترک را برای تمام گره های محاسباتی خوشه فراهم میکند که قادر به دسترسی مستقیم به تمام صفحات حافظه برای سرورهای مجازی منبع و مقصد باشند. فرایند مهاجرت زنده VM توسط ماشین فیزیکی منبع متمرکز میشود، OPENMPI کد سریال را برای یافتن بخش های موازی به منظور افزایش سرعت اسکن میکند. DSM به عنوان یک فضای حافظه سراسری بین گره های محاسباتی خوشه HPC مورد استفاده قرار میگیرد که به فرآیند pulling مهاجرت VM کمک خواهد کرد. در همین حال دستگاه فیزیکی منبع همچنان به واگذاری وضعیت پردازنده VM مجازی و وضعیت شبکه با اولویت بالا ادامه داده و پس از آن انتقال صفحات خراب با اولویت پایین تر انجام خواهد شد. سرورهای مجازی سازی مبدا و مقصد با وظیفه مهاجرت برای شروع و خاتمه مهاجرت زنده VM بر اساس آستانه ثبات تصویر حافظه مقصد VM بارگزاری میشوند که توسط سه پارامتر محدود شده است: حداکثر تعداد تکرارها، تغییرات کمتر صفحات حافظه (تولید صفحات خراب کمتر)، و تصویر حافظه سازگار در مقصد.
DSM روند پیش نسخه مهاجرت زنده VM را با سفارشی سازی برخی از ویژگی های Grappa DSM بهبود می بخشد [4]. اولین تغییر ، به روز رسانی اندازه پیام هاست. فرایند مهاجرت DSM بر روی انتقال صفحات حافظه با متوسط اندازه 4کیلوبایت به جای 32 بایت عمل میکند همانطور که در Grappa استفاده می شود. به روز رسانی اندازه پیام همانند اندازه صفحات حافظه اجرا میشود. این امر تعداد پیام های به روز رسانی را کاهش می دهد. تغییر دوم به انتخاب صفحات حافظه بر اساس مدیریت محلی مربوط می شود. داده مورد نظر با محلیت پایین معمولا روی پردازنده خانگی خود اصلاح میگردد، به جای آنکه یک کپی از تصویر کد به پردازنده مقصد ارسال کند، که در آن داده مورد نظر با محلیت بالا به پردازنده درخواست شده ارسال میگردد. در روش پیشنهادی بهترین کار، انتقال صفحات حافظه با لوکالیتی بالا نیست، بلکه ارسال صفحات حافظه با لوکالیتی پایین با نرخ کمتر صفحات خراب به پردازنده مقصد، کارآمدتر می باشد. این مساله فرکانس به روز رسانی را کمتر خواهد نمود. صفحات حافظه خراب باقی مانده بالاتر، بعدا در حالت تعلیق و ادامه منتقل میشوند. موازی سازی خودکار ، ارسال و دریافت صفحات حافظه VM را بصورت موازی فراهم می کند. شکل 3 روش پیش نسخهDSM سفارشی را به صورت نمودار فضا زمانی توصیف کرده است. به این ترتیب رویکرد پیشنهادی تعداد صفحات خراب ارسالی از پردازنده خانگی به پردازنده مقصد را کاهش می دهد.

4. معیارهای عملکرد
مهاجرت زنده VM برای هر دو سیستم عامل مهمان یعنی ماشین مجازی Flake Windows7 و Ubuntu12 لینوکس Flask ، بین دو سرور میزبانUnhand و Worth انجام گرفته است. این آزمایش برای هر مورد متفاوت ، شش بار اجرا شده تا مطمئن شویم که مقادیر اندازه گیری شده عاری از هر گونه خطاست، و سپس میانگین آن محاسبه شده است.

الف. معیارهای حجم کار VM
سیستم عامل مهمان VM با چهار حجم کاری مختلف برای تست مهاجرت زنده VM تحت سناریوهای مختلف بارگزاری شده، که مهاجرت VM را توسط برنامه های کاربردی که دارای رفتار اجرایی مختلفی هستند لود میکند، همانطور که در جدول 2 داده شده است.

1. حجم کاری در حالت بیکاری سیستم عامل: در یک سیستم عامل بیکار، صفحات حافظه خراب تولید شده، دارای کمترین زمان تولید در طول مهاجرت VM بدون اجرای هیچ گونه حجم کار سنگینی اند. تغییرات حافظه در صورت بیکار بودن سیستم عامل به منظور ارزیابی مدل مهاجرت زنده VM DSM استفاده می شود.
2. حجم کار فشرده CPU: کامپایل کردن کد منبع (VM لینوکس) و نصب و راه اندازی Cygwin (VM ویندوز) یک بار CPU سنگین بوده و در این موارد از حجم کار، زمان کامپایل در CPU بالاتر از دیگر وظایف پردازنده است.
3. حجم کار فشرده حافظه: حجم کار فشرده حافظه با اجرای ویدئو در طول روند مهاجرت زنده برای هر دو نوع سیستم عامل، ویندوز و لینوکس ایجاد میشود، علاوه بر بار خواندن دیسک فشرده برای ویدئو از هارد دیسک.
4. حجم کار فشرده شبکه: برای وظیفه شبکه ، هر اتصال مشتری به وب سرور باید حفظ شود تا زمانی که مشتری به آن اتصال خاتمه دهد. داده های منتقل شده در وب عمدتا دارای یک حالت شبکه بزرگتر برای حفظ اتصال مشتریان به وب سرور هستند که باعث افزایش ردپای حافظه با ویژگی لوکالیتی بالاتر میشود.
همانگونه که در شکل 4 الف نشان داده شده، مجموع زمان مهاجرت در تمام حجم کار کاهش یافته است. اما بهترین حالت آن با نصب Cygwin و حجم کار در حالت بیکار بوده که به ترتیب در حدود 25٪ و 20٪ افزایش است، در حالی که این افزایش در حجم کاری وب و ویدئو در حدود 6٪ و 8٪ بود. شکل 4 ج مجموع زمان مهاجرت را در VM لینوکس به تصویر می کشد. با DSM تمامی حجم کار کم بوده و بهترین نرخ در حالت بیکار بودن VM با 16.6٪ افزایش یافته است که مجموع زمان مهاجرت را کاهش داده است. از آنجا که ردپای حافظه لینوکس کمتر از ویندوز است، به روز رسانی صفحات خراب با لوکالیتی بالا در لینوکس کمتر از ویندوز می باشد. این باعث می شود تا DSM با ویندوز بهتر عمل کند.
در شکل 4 ب و 4 د، زمان خرابی بدست آمده برای ویندوز و لینوکس با DSM ، با یک کاهش عالی در تمام موارد حجم کار مواجه شد است. در حدود 42.8٪ کاهش زمان خرابی در حجم کاری وب برای هر دو سیستم عامل ویندوز و لینوکس بدست آمده است. در بازی های ویدئویی ویندوز هیچ افزایشی صورت نگرفته چرا که GPU همراه بار حافظه و چینش تصاویر ویدئویی کار میکند. اما در لینوکس به 10٪ افزایش میرسیم زیرا در لینوکس ویدئوها در یک راه هموار stream نمیشوند. DSM زمان خرابی را با کاهش تعداد صفحات معیوب پس از حالت تعلیق و ادامه کاهش میدهد. پردازنده های موردهدف می توانند تمام صفحات حافظه را به طور مستقیم مشاهده کنند.
شکل های 5 تا 12 شبکه و عملکرد پردازنده VM را در طول مهاجرت زنده VM نشان می دهند. بازه زمانی به عنوان شکاف زمانی ثابت برای نشان دادن زمان شروع مهاجرت زنده VM ، زمان خرابی و زمان مهاجرت کل نرمالسازی شده است. به وضوح میتوان رابطه بین عملکرد پردازنده های VM و فعالیت ترافیکی را مشاهده کرد. در تمام موارد، ترافیک شبکه به یک پهنای باند ثابت 12Mbps برای محافظت از شبکه محدود شده و در طول دوره خرابی میزان ترافیک برای کاهش خرابی افزایش می یابد.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

3. خلاصه روش‌های موجود
در این بخش، با توجه به روش‌های اصلی، روشی را با جزئیات برای هر بعد طبقه‌بندی ارائه می‌دهیم.

3.1. محدوده
اولین جنبه بعد محدوده نشان می‌دهد که چه کسی مسئول مکانیسم ارتجاعی است. در چنین طرحی، روش ارتجاعی همراه با زیرساخت ابر هسته است و روش‌های مربوطه به عنوان ابر ارائه دهنده خاص تعریف شده‌اند. به عنوان مثال، [37] بر پایه ابزاری است که در بالای زیرساخت‌های IaaS نصب شده است، سیستم DejaVu در [68] قابلیت این زیرساخت‌ها را گسترش داد. مجموعه دیگر پیشنهادات به امتیاز خاصی برای منابع (به عنوان مثال، [54] به ماژول KVM سفارشی و رابط وابسته است، [21] در‌ OpenStack تجمیع شده است و [61] ولتاژ و فرکانس CPU را تنظیم می‌کند) و دسترسی به اطلاعاتی نیاز دارند که تنها ارائه‌دهنده ابر قادر به ارائه آن است (به عنوان مثال، [50] به اطلاعات محلی دستگاه فیزیکی وابسته است). با این وجود، بیشتر پیشنهادات، ارتجاع پیشرفته‌ای را برای خدمات مبتنی بر ابر بدون در نظر گرفتن تعمیم ویژگی‌های ارتجاعی خدمات ابر ارائه می‌دهند؛ آنهایی که در ارتباط با ارائه‌دهندگان خدمات تعیین می‌شوند.
با توجه به نوع کاربردی که پیشنهادات بر آن متمرکز شده‌اند، اکثر آنها مستقل از برنامه کاربردی چندمنظوره هستند و یا برای برنامه‌های کاربردی چندمنظوره مبتنی بر وب طراحی شده‌اند. اکثر پیشنهادها از مدیریت ارتجاعی تمام سه سطح برنامه وب (یعنی، وب سرور، سرور برنامه، سرورهای ذخیره‌سازی) پشتیبانی می‌کنند، به جز در [18 و 32] که تنها قابلیت ارتجاعی سطح سرور برنامه را مدیریت می‌کنند، و [62 و 68] که به سادگی خدمات وب را مورد هدف قرار می‌دهند. بخش قابل توجهی از پیشنهادات ارتجاعی، ناحیه NoSQL را مورد هدف قرار می‌دهند. روش‌ها در این گروه سیستم- خاص (به عنوان مثال، [23] اهداف Cassandra، [27] هدف HBase، [58] اهداف بی‌انتها، در حالی که [47] HDFS را در نظر می‌گیرد) و یا قابل اجرا برای مجموعه بزرگی از سیستم‌های NoSQL مانند Cassandra، HBase، Voldemort و Infinispan [15، 41، 45، 53 و 64] هستند. در [20، 31 و 59] انعطاف‌پذیری در پایگاه‌‌های داده‌ ارتباطی در نظر گرفته می‌شود. [20 و 31] را می‌توان در هر پایگاه داده ارتباطی مورد استفاده قرار داد زیرا موتور پایگاه داده را اصلاح نمی‌کنند، در حالی که در [59] موتور پایگاه داده برای پشتیبانی از حرکت‌های زنده با الهام از روش [30] اصلاح می‌شود. در پایان روش منفردی وجود دارد که به عنوان Storage دسته‌بندی می‌شود [19]، که در آن قابلیت ذخیره‌سازی ارتجاعی عملکرد ذخیره‌سازی ماشین مجازی از طریق روش‌های ذخیره‌سازی در نظر گرفته می‌شود.

3.2. هدف
تمامی روش‌های موجود در جدول 1 به منظور بهبود عملکرد می‌باشد. تنها [55] استثنا است که در آن هدف ارتجا دستیابی را از طریق استفاده از ارائه‌دهندگان چندابری افزایش می‌دهد. هدف عملکرد می‌تواند ثابت باشد (به عنوان مثال، در توافق سطح خدمات یا به عنوان آستانه تعریف شده توسط کاربر تعریف شود) و یا به عنوان ناظر مستمر و بهینه‌سازی ابزار سیستم بیان شود. در چنین کارهایی، کاهش هزینه‌های مالی به طور غیرمستقیم از طریق استفاده از منابع کمی در نظر گرفته می‌شود که عملکرد را به طور قابل قبولی حفظ می‌کنند. در [35 و 36]، هدف هملکرد با ارائه تضمین‌های دسترسی همراه است.
برخی از پیشنهادات به صراحت با هدف کاهش هزینه مالی بیان شده‌اند. به طور خاص در [29، 36 و 57] برآورد هزینه برای مقیاس در درون یا خارج ابر به کار گرفته شد، در حالی که در [25] از تخمین‌های مشابه برای انتخاب میان گسترش در زیرساخت ابر عمومی یا خصوصی استفاده می‌شود و در [62] تحلیل بازده سرمایه‌گذاری (ROI) پیش از گسترش حقیقی ارائه می‌شود. در سایر روش‌ها قابلیت ارتجاعی بنا بر محدودیت بودجه است. به طور خاص، [66] در صورتی که حداکثر هزینه بیش از هزینه قابل دسترس باشد، مانع مقیاس‌گذاری می‌شود، [22] اجرای تنظیم مجدد برنامه (یعنی، پاسخ‌های سرور متنی برای صرفه‌جویی در پهنای باند) را حفظ می‌کند تا هزینه‌ها پایین‌تر از حد بودجه باقی بماند و [32] دسته‌بندی بودجه (یعنی، دسته‌بندی فلزات: طلا/ نقره/ برنز) را ارائه می‌دهد که محدودیت‌های مقیاس‌گذاری منابع را تنظیم می‌کنند. در پایان، [18] تلاش می‌کند تا چندین برنامه کاربردی را در ماشین‌های مجازی هماهنگ کند تا هزینه تأمین شده را کاهش دهد.
علاوه بر این، دو مقاله وجود دارد که صرفه‌جویی در انرژی را با هدف عملکرد در نظر گرفته‌اند. در [50] حرکت زنده به کار گرفته می‌شود تا همانند بسیاری از ماشین‌ها در حالت خواب تنظیم شود، در حالی که در [61]، منابع ماشین‌های مجازی برای مقادیر ولتاژ و فرکانس پویا برای صرفه‌جویی در انرژی مورد استفاده قرار می‌گیرند.

3.3. تصمیم‌گیری
راه‌اندازی فرایند تصمیم‌گیری. مقالات به (1) واکنشی، (2) پیشگیرانه و (3) ترکیب واکنش‌پذیر و پیشگیرانه تقسیم می‌شوند. از یک طرف، روش‌های واکنشی معمولاً بر پایه پیگیری مستمر معیارهای ویژه و اعتبارسنجی قوانین مبتنی بر آستانه استوار هستند. فرایند تصمیم‌گیری اغلب با تخلف از آستانه منفرد به وجود می‌آید. با این وجود، فرایند تصمیم‌گیری تنها پس از یک دوره مشخص می‌تواند آستانه را نقض کند (به عنوان مثال، [55 و 57]) و یا تعداد ارزیابی‌های نقض‌ شده را برای پرهیز از واکنش بیش از حد از قبل تعیین کند (به عنوان مثال، [21]). از سوی دیگر، روش‌های پیشگیرانه مکانیزمی هستند که برای پیش‌بینی تنوع بار آینده و یا رفتار آتی سیستم مورد استفاده قرار می‌گیرند. با این وجود، روش‌های صرفاً پیشگیرانه از این واقعیت رنج می‌برند که قادر به مقابله با افزایش ناگهانی بار کاری نیستند. برای غلبه بر این نگرانی، در مقالاتی مانند [17، 20 و 43] روش ترکیبی در نظر گرفته شده است. علاوه بر این، در [16 و 38] پیشنهاد شد که از روش‌های واکنشی برای مقیاس‌بندی خارجی و از روش‌های پیشگیرانه برای مقیاس‌بندی داخلی استفاده شود. برای اولین بار از سازگاری سریع برای خوشه حجم کار استفاده شد. همچنین مقالاتی وجود دارند که از روش‌های واکنشی در حالتی استفاده می‌کنند که مکانیسم پیشگیرانه از تصمیم‌گیری نامطمئن است [61]، یا پیش‌بینی کننده به اندازه کافی برای تصمیم‌گیری مناسب آموزش ندیده است [51 و 52]. [62] ترکیبی از روش‌های واکنش‌پذیر و پیشگیرانه را ارائه داد که در ادامه بر پایه روزانه فعال می‌شوند. در پایان، در [19] روش‌های واکنش‌پذیر و پیشگیرانه‌ای ارائه شدند که به طور همزمان فعال نیستند اما می‌توان هر یک از آنها را به طور جداگانه پشتیبانی کرد.

مکانیسم تصمیم‌گیری. در بخش قبلی از روش‌های اصلی استفاده شده در تصمیم‌گیری ارتجاعی استفاده کردیم. در اینجا، این موضوع را دقیق‌تر توضیح می‌دهیم، ابتدا کاربرد روش‌های متداول و سپس روش‌های ترکیبی را شرح می‌دهیم.
با این وجود، روش‌های متناظر لزوماً ساده نیستند. به عنوان مثال، [17] از دسته مدل‌های پیش‌بینی به طور همزمان استفاده می‌کند تا برآورد بار و نقاط آستانه بالقوه آتی را بررسی کند. همچنین، [20] از مدل پیش‌بینی برای برآورد بار برای مقیاس پیشگیرانه بر پایه قوانین مشخص استفاده می‌کند. مدل‌سازی سیستم به طور کلی سیاست‌های تصمیم‌گیری را بهبود می‌بخشد. در [49]، سیستم به عنوان صفی از مشاغل مدل‌سازی شد و به اقدامات انعطاف‌پذیری در زمان ورود یا تکمیل شغل منتهی شد. دو روش مبتنی بر قواعد مبتنی بر مدل‌های سیستم غیربدیهی هستند [35]، که در آن سیستم به طور خودکار در حالت‌های مختلف به دلیل اجرای قانون مدل‌سازی می‌شود و در [25] حالتی در نظر گرفته شد که در آن مدل گراف، تأثیر قوانین ارتجاعی را در کل سیستم پذیرفته است. به عنوان مثال نهایی، در [39] روش مبتنی بر قاعده فازی ارائه شد که در آن کاربر قوانین را در فرمی مشخص می‌کند: «اگر بار کاری بالا باشد، و زمان پاسخ کند باشد، آنگاه دو ماشین مجازی بیشتر به منابع موجود افزوده می‌شوند»، بدون نیاز به توصیف ارزش‌های «بالا» و «کند»؛ این ارزش‌ها بر پایه اطلاعات ارائه شده توسط ذی‌نفعان فنی محاسبه می‌شوند.
سیاست مبتنی بر بهینه‌سازی ریاضی/ آماری. این روش‌ها مسأله ارتجاعی را به عنوان بهینه‌سازی مدل‌سازی می‌کنند. در [32] روش مقیاس‌پذیری بهینه به پیروی از روش شاخه‌ای ارائه شد و پس از انجام تحلیل سری‌های پیچیده به پیش‌بینی بار اضافی آتی محدود شد. در [22]، تصمیم‌گیری واکنش‌پذیر مسأله حداکثر رساندن را در برنامه‌های دینامیکی کاهش می‌دهد؛ این روش از مدل صف به عنوان مرحله پیش‌پردازش برای تعیین مزایای بالقوه اشتغال انواع الگوریتم‌های مختلف برای خودسازگاری استفاده می‌کند. روش [50] به بررسی‌های برنولی کمک کرد تا ماشین مجازی مناسب را برای هدایت حرکت زنده پیدا کنند. در پایان، بهینه‌سازی به مدل‌سازی سیستمی اشاره می‌کند که پس از آن ارتجاع را در اختیار می‌گذارد؛ به عنوان مثال، [54] از پروفایل‌های آنلاین و منحنی مناسب برای تولید مدل عملکرد استفاده کرد که قادر به پیش‌بینی آن است که آیا برنامه در حالت تناقض با هدف است یا خیر.
سیاست مبتنی بر یادگیری ماشین. یادگیری ماشین معمولاً در تصمیم‌گیری ارتجاعی مورد استفاده قرار می‌گیرد. [68] مدل سیستم را در قالب طبقه‌بندی ارائه داد، در حالی‌که خوشه‌ها در گروه‌های نمایشی نیز کار می‌کنند. تصمیم‌گیری‌های ارتجاعی قبلی برای گروه مشابه در تصمیم‌گیری‌های آتی تأثیر می‌گذارند. روش [31] مشابه است. در [63] مدل پیش‌بینی مبتنی بر زنجیره مارکوف برآوردهایی را ارائه داد که به طبقه‌بندی چندمتغیره برای دسته‌بندی حالت‌های عادی یا غیرعادی آتی می‌پردازند و اقدامات ارتجاعی را مطابق با آن انجام می‌دهند. مثال روش‌های پیشرفته‌تر در [41، 45 و 64] ارائه شده است که در آنها روش Q-Learning از محاسبه ارزش‌های حالت بهینه به منظور حل غیرمستقیم مدل تصمیم‌گیری مارکوف (MDP) برای توصیف سیستم پیروی می‌کند.
سیاست‌های تئوری کنترل. تئوری کنترل حوزه علمی است که قادر به ارائه راه‌حل‌های محاسباتی ارادی است و با سیاست‌های ارتجاعی خاصی در نظر گرفته می‌شود. به عنوان مثال، [60] از روش تئوری کنترل استفاده کرد که در آن نمایشگر مدل‌سازی صف در سیستم ایجاد می‌شود و پیش‌بینی کننده را نیز به کار می‌گیرد. همچنین در [40] نمونه از کاربرد فیلترهای کالمن و کنترل بازخورد حاصل از ارتجاع ارائه شد. در پایان، در [16] روش کنترلی با ترکیب سیاست‌های فعال و واکنشی مورد بررسی قرار گرفت. همانند سایر مقالات مشابه؛ زیرساخت ابر به عنوان صف مدل‌سازی می‌شود، در حالی که برآوردکنندگانی برای بار اضافی خارجی در نظر گرفته می‌شود.
سیاست‌های ترکیبی. سیاست‌های ذکر شده مطابق با ماژول‌های تصمیم‌گیری است که یکی از مکانیسم‌های مشخص شده را استفاده می‌کنند. با این وجود، روش‌های ارتجاعی اغلب چند مکانیسم را به کار می‌گیرند، همان‌طور که در ادامه بررسی می‌شود.
شایع‌ترین روش ترکیبی، ترکیب قوانین با یکی از مکانیسم‌های آزاد است. قوانین می‌توانند به طور مؤثر راه‌حل‌های تئوری کنترل را گسترش دهند. بر مثال، در [47]، کنترل‌کننده یکپارچه‌ای ارائه شد که بر پایه آستانه مناسب به صورت پویا از آستانه برای تنظیم CPU بالا و پایین مورد استفاده در تصمیم‌گیری‌های ارتجاعی استفاده می‌کند. در [18]، رگرسیون خطی برای پیش‌بینی بار آتی مورد استفاده قرار گرفت و سپس مقادیر پیش‌بینی شده در مدل سازگار با متغیر وابسته به کنترل‌کننده متناسب آزاد مورد استفاده قرار گرفتند. تصمیمات نهایی درباره تعداد ماشین‌های مجازی که باید اضافه یا حذف شوند بر پایه سیاست مبتنی بر قانون اتخاذ می‌شوند. قوانین را می‌توان با روش‌های یادگیری ماشین ترکیب کرد. نمایش این دسته ترکیبی در [51 و 52] اراه شده است، که در آن سه مدل از ابزار WEKA برای حمایت از تصمیم‌گیری استفاده می‌کنند. مدل اول، پیش‌بینی کننده سری زمانی است که حجم کار آتی را پیش‌بینی می‌کند. مدل دوم، مدل بیز است که به طور قابل ملاحظه‌ای به روزرسانی می‌شود و رابطه میان بار کار فعلی و روش دسته‌بندی نقض آستانه را می‌آموزد، و مدل سوم نیز یک مدل نوآوری بیز است که تعداد مطلوب ماشین‌های مجازی را برآورد می‌کند.

خدمات با در نظر گرفتن هزینه و عملکرد الگوریتم های بارگزاری متعادل در ابر

Cost-aware service brokering and performance sentient load balancing algorithms in the cloud

مبتدی (مناسب برای درک مفهوم کلی مطلب)

F2143

الگوریتم بارگزاری ابر را، بر اساس انواع مختلف شرایط برنامه ریزی برای ابر های ترکیبی، ارائه میدهد.نتایج شبیه سازی کارشان نشان میدهد که این الگوریتم بارگزاری، درآمد بارگزاری را به حداکثر رسانده و باعث رضایت کاربران میشود.محققان مکانیزم های صرفه جویی انرژی را به منظور افزایش درآمد کارگزاران، به کار میبرند.Akhter and Othman (2014) شروطی برای ماشین مجازی در غالب یک روش مصرف انرژی برای مرکز داده پیشنهاد دادند، و استراتژی های مختلفی را ترکیب کردند Akhtar and Othman,2016) ).
Kessaci et al., (2013) کاهش به الگوریتم ژنتیک چند هدفه را برای بارگزاری ابر(MOGACB) پیشنهاد دادند، که برای رضایتمندی مشتری و سود کارگزار نشانه گرفته شده است.آنها همچنین ذکر میکنند که رضایت مشتری بیشتر مربوط به زمان پاسخ است تا موارد دیگر.
هدف از بارگزاری متعادل ابر، افزایش سرعت اجرای برنامه هاست.مطالعات متعددی روی بارگزاری متعادل در چند سال گذشته انجام گرفته است.Fang et al., (2010) درباره دو وظیفه برنامه ریزی برای استفاده از منابع بالا بحث میکند.برنامه پیشنهادی و برنامه ریزی سطح وظایف ماشین مجازی توسط برنامه Cloudsim که یک چاچوب شبیه سازی tool kitsimulation است، اثبات شده است.به هرحال عواملی مانند پهنای باند و هزینه را در کارشان، در طول دوره ی زمانی توازن بار در نظر نگرفته اند.
Randless و همکاران در سال 2010 بر اساس یک نمونه گیری تصادفی برای یک رفتار قدیمی و تعادل بارگیری خوشه بندی های فعال، با الهام از زنبور عسل تکنیک بارگزاری متعادل را پیشنهاد دادند.الگوریتم پیشنهادی آنها برای یک محیط ابری همراه با گره های نا همگن گسترش یافت اما روی یک سیستم با مقیاس کوچک شبیه سازی شد.توازن بارگزاری بر اساس دور رابین و تورینگ توسط Wickremasinghe و همکارانش در سال 2010 ارائه شد.آنها روی رفتار برنامه ای مطالعه میکردند که توسط شبیه سازی در یک محیط رایانش ابری در مقیاس عظیم گسترده شده بود.به هر حال کارایی توازن بار میتوانست بیشتر افزایش یابد، به طوری که در الگوریتم پیشنهادی ما نشان داده شده است.
منابع توازن بار ماشین مجازی از یک الگوریتم ژنتیک که توسط Hu و همکارانش در سال 2010 ارائه شده، استفاده میکند.این الگوریتم به عدم توازن بار و مشکلات هزینه مهاجرت، در الگوریتم های قدیمی پیشنهاد شده در کار های قبلی، میپردازد.به هر حال، مکانیزم مدیریت و نظارت هنوز برای تغییرات پویای ماشین های مجازی مورد نیاز است.
Wangetal در سال 2010 به طور فرصت طلبانه، بارگزاری متوازن و بارگزاری متوازن حداقل-حداقل را پیشنهاد میکند که الگوریتم های زمانبندی استاتیک برای سیستم بارگزاری متوازن است.این الگوریتم ها برای سه سطح از شبکه رایانش ابری گسترش یافته است.مدیر درخواست و مدیر خدمات و گره های سرویس، سه جزء از معماری در چارچوب آنهاست.بارگزاری متوازن فرصت طلبانه تاش میکند تا کل سیستم را هنگام اجرا مشغول کند، زمانی که الگوریتم بارگزاری متوازن حداقل-حداقل زمان اجرا را به حداقل میرساند.
Maguluri و همکارانش در سال 2012 یک مدل تصادفی برای بارگزاری متوازن ارائه کردند که شامل محاسبات خوشه ها و تمرکز روی بارگزاری متوازن، در میان سرور هاست.آنها نشان میدهند که زمانبندی بهترین تناسب، بازده مطلوبی ندارد.بر اساس معیار های بهینه سازی مختلف، و محدودیت های کاربر، Lucas-Simarro و همکارانش در سال 2013 یک بارگزاری متوازن و الگوریتم زمانبندی برای ابر های مختلف ارائه دادند.ضمناکار آنها در الگوریتم پیشنهادیشان، هزینه بهره وری و بهبود کارایی را نشان میدهد.
یکی دیگر از الگوریتم های بارگزاری متوازنی که از زنبور عسل الهام گرفته شده، توسط Krishna در سال 2013 ارائه شده است.این الگوریتم، ماشین های مجازی در سرتاسر آن، به بارگزاری متوازن مجهز میکند و کارایی را به حداکثر میرساند و زمان وظایفی که در صف هستند را به حداقل میرساند که منجر به بهبود قابل توجهی برای زمان اجرای متوسط، میشود.این کار بیشتر تمرکز خود را به جای عوامل Qos، روی اولویت وظایف میگزارد.
اولین کار ما روی بارگزاری متعادل توسط Nahaand Othman در سال 2014 ارائه شده است.دور رابین و سرور وابستگی توسط Mahajan و همکارانش در سال 2013 ارائه شده است.نویسندگان عملکرد الگوریتم را توسط یک الگوریتم بارگزاری متعادل کارآمد، بهبود بخشیده اند.به هر حال، از آنجایی که تشخیص تاثیر بیشینه و کمینه شدن ساعات بارگزاری متوازن، بدون حداقل یک روز کاری، امکان پذیر نیست، در این نوع شبیه سازی ها، برنامه ای که برای یک ساعت بارگزاری میشود، ممکن است منجر به نتایج دقیقی نشود.بارگزاری متوازنی که از مدل پرواز آتشین استفاده میکند، در سال 2014 توسط Florence و Shanthi ارائه شد.شبیه سازی این مدل در یک محیط با مقیاس کوچک انجام شد.الگوریتم های وظایف ماشین مجازی مربوط به بازگزاری است را Domanal و Reddy در سال 2014 ارائه کردند.پاسخ الگوریتم را در یک مورد پویا و حجم کاری ترکیبی، مشخص کردند.Sun و همکارانش در سال 2014 یک تجزیه و تحلیل جامع روی یک رویکرد انتخابی از خدمات ابری انجام دادند و یک شکاف تحقیقاتی بالقوه در سرویس ابری انتخابی، یافتند.
3.مدل های سرویس ابری
1-3.مدل های لایه ای سرویس های ابری
IaaS ، PaaS و SaaS سه تا از ساده ترین لایه های سرویس ابری است.شکل 1 مدل سرویس ابری را نشان میدهد.بالاترین لایه، لایه ی SaaS است که مرتبط با الزامات اجرای برنامه است.این لایه الزامات پلتفرم را برای برنامه ترجمه میکند و به لایه ی PaaS میفرستد.
سپس لایه ی PaaS یک کتابخانه گسترش یافته شامل محیط اجرای برنامه، مقیاس گزاری و جداسازی برنامه را آماده میکند.این لایه از طریق یک واسطه ی سنتی عمل میکند، و یک پل بین زیر ساخت و نیاز های برنامه ایجاد میکند.اما ساختار حقیقی مانند، ماشین های مجازی مورد نیاز را تعیین نمیکند.با این حال، نمای بالاتری از واحد های اجرایی مانند، موضوعات، فرآیند و وظایف را نشان نمیدهد.Microsoft Azure و Google App Engine نمونه هایی در دنیای واقعی از سرویس های ابری هستند.
لایه ی IaaS با تعدادی از فرآیند ها سر و کار دارد مانند اندازه دیسک، ماشین مجازی و اتصال شبکه.این لایه تامین منابع مجازی را تعیین میکند.کارگزاران هر ابر نگران این هستند که با در دسترس بودن منابع سیستم، و اطلاع از هزینه های منابع، و کارایی زمان اجرا، نسبت به کارگزاران دیگر چگونه است.الگوریتم پیشنهادی ما برای کارگزاران در لایه ی IaaS ارائه شده است.کارگزاری در لایه های SaaS و PaaS نسبت به معیار های متمایز اجراییشان، باهم تفاوت دارند.کارگزاری لایه ی SaaS بر اساس SLA و نیاز های کاربر است در حالی که کارگزاری لایه ی PaaS بر اساس زمان و پشتیبانی استقرار است.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

طبقه‌بندی‌های مختلف و ویژگی‌ها می‌تواند در یک چارچوب ادغام داده به منظور بهبود دقت طبقه‌بندی در نظر گرفته شود، همان‌گونه که در شکل 2 گزارش شده است.
همان‌گونه که در پایان این مقاله نشان داده شده است، این طبقه‌بندی با بالاترین کیفیت را می‌توان برای پیدا کردن یک دسته حجم کار ناشناخته استفاده کرد.

3. معیار SPEC 2006
CINT2006 [40] معیار CPU متمرکز، بر یک سیستم پردازنده، زیر سیستم حافظه و کامپایلر تاکید می‌کند. SPEC، CPU2006 را برای ارائه یک مقایسه از عملکرد محاسبه متمرکز طراحی. کرده است. تمام معیارها به‌عنوان کد منبع ارائه شده است. دوازده برنامه‌ی گنجانده شده در مجموعه معیارها را می‌توان در کلاس‌های زیر با توجه به قابلیت‌ها گروه‌بندی کرد: کلاس کامپایلر، کلاس بازی، کلاس فشرده‌سازی، کلاس محاسبات علمی، کلاس بهینه‌سازی.
در این کار، مدل‌های حجم کار از شش معیار مشتق شده است، بانام‌های401.bzip2،403.gcc،458.sjeng، 471.omnetpp،400.perlbench و 462.libquantum. . در آزمایش اول، مدل‌های مشتق شده با همان شش معیار تست شده است. مهم است که توجه داشته باشید که داده‌های ورودی از داده‌های مورد استفاده در آموزش متفاوت هستند، در نتیجه توالی اجرا همیشه متفاوت است. در آزمایش دوم، شش معیار دیگر برای ارزیابی شباهت برای ارزیابی مدل‌های حجم کار استفاده شده است.
معیارهای مورد استفاده تنها کسری از برنامه‌های کاربردی مشابه هستند، چرا که I / O و فعالیت حافظه از دست رفته است. بنابراین، نتایج گزارش شده به عنوان یک دیدگاه اولیه از کل در نظر گرفته شده است و تنها در حجم کار متمرکز کامپیوتر است.
توضیح این‌که چطور داده‌های ورودی به معیار‌ها به منظور ایجاد گزارش نتایج قابل تکرار سازمان‌دهی می‌شود، مهم است. SPEC شش ورودی مختلف برای bzip، نه برای gcc و سه برای perlbench. معیار sjeng تنها یک ورودی دارد؛ دو ورودی دیگر برای sjeng از اولین موقعیت‌های شطرنج از chess.html به‌دست می‌آید که از WWW.DOWNSCRIPTS.COM/CHESSDATABASE ASP.NET-SCRIPT.HTML دانلود می‌شود. به‌طور مشابه، omnetpp تنها یک ورودی توسطSPEC دارد و ورودی‌های دیگر از اولین مثال شبکه گزارش شده در HTTP://INET.OMNETPP.ORG/DOC/INET/NEDDOC/INDEX.HTML. به‌دست می‌آید. درنهایت، libquantum از زوج اعداد اضافی زیر داده شده است: (159، 15) و (1413، 17).
تمام معیار‌ها حداقل سه ورودی دارند که برای آموزش استفاده می‌شوند. ورودی‌های اضافی برای تست از روش مشابه به‌دست می‌آید.

4. تنظیم ماشین مجازی
زیرساخت‌های مجازی‌سازی مورد استفاده در این کار توسط نرم افزار VirtualBox [43] ارائه شده است نرم افزار VirtualBox برنامه مجازی‌سازی منبع باز است که مجموعه‌ای غنی از رابط‌های برنامه کاربردی فراهم می‌کند و معیارهای مختلف برنامه‌ی مجازی را ارائه می‌دهد. مجموعه‌ای کامل از API های موجود در شرح داده شده است. SDK، که با VirtualBox ارائه شده، به اشخاص ثالث اجازه می‌دهد تا برنامه‌های کاربردی در تعامل با VirtualBox را توسعه دهند. VirtualBox در سطوح طراحی شده است. در پایین VMM. را توضیح داده‌ایم. VMM قلب مجازی‌سازی است، عملکرد ماشین‌های مجازی را نظارت می‌کند و امنیت و عدم وجود درگیری بین ماشین مجازی و میزبان را فراهم می‌کند. ماژول‌های وجود دارد که قابلیت‌های اضافی، به‌عنوان مثال، سرور RDP (پروتکل از راه دور دسکتاپ) را ارائه می‌کنند. سطح API بالاتر از این بلوک‌های اساسی نمایش داده شده است.
نرم افزار VirtualBox با یک وب‌سرویس همراه است، یک بار در حال اجرا، به عنوان سرور HTTP عمل می‌کند، اتصالات SOAP را می‌پذیرد [38] و آنها را پردازش می‌کند. رابط کاربری در یک فایل زبان توصیف وب‌سرویس (WSDL ) توصیف شده است [45]. نوشتن برنامه‌های مشتری در هر زبان برنامه‌نویسی ممکن است که ابزاری برای پردازش فایل‌های WSDL، مانند جاوا فراهم کرده ، C ++، PHP NET، پایتون، پرل فراهم کرده باشد. علاوه بر جاوا و پایتون، SDK شامل کتابخانه‌هایی آماده برای استفاده است. API با استفاده از مدل شیء گرا (COM ) به‌عنوان یک مدل مرجع پیاده‌سازی شده است. در ویندوز، استفاده از Micrisoft COM طبیعی است. در میزبان‌های دیگر، که COM وجود ندارد، XPCOM که یک برنامه رایگان برای اجرای COM است، استفاده می‌شود.
با وجود مزایای متعدد وب سرویس API، ما از روش COM استفاده کردیم به دلیل این‌که سربار کمتری دارد و نرخ داده‌ی بالاتری دارد. ما یک تبادل اطلاعات انجام دادیم و معلوم شد که وب سرویس قادر است، به‌طورمتوسط 5.96 MS اطلاعات جمع‌آوری کند درحالی‌که با استفاده از داده COM می‌تواند 0.49 MS جمع‌آوری کند. دیگر ویژگی‌های جالب، نگرانی مجموعه‌ای از داده‌های آماری در منابع مورد استفاده است. API توابع زیرا را فراهم می‌کند:
• تعیین می‌کند که کدام گروه‌هها از شاخص‌های مورد علاقه ما هستند (CPU، RAM، شبکه، دیسک).
• تنظیم محدوده اندازه‌گیری (حداقل فاصله زمانی 1)؛
• تنظیم اندازه فریم برای آمار (حداقل، حداکثر، میانگین).
• ساخت پرس ‌و جوهایی در مورد استفاده از یک منبع واحد
5. معیارها
با توجه به معیارها، یک سیستم مالکیت با توجه به دیاگرام شکل 3 توسعه دادیم. مالکیت توسط میزبان هدایت می‌شود؛ تمام دستورات و داده‌های به‌دست آمده از رابط کاربری COM استفاده می‌کند. یک رابط وب برای VMM وجود دارد اما آن از آنچه در بالا بیان شد آهسته‌تر است.

مقادیر اندازه‌گیری برای توصیف حجم کار از دو نوع، یعنی منابع حافظه و تقاضای منبع مورد استفاده قرار می‌گیرد. هر دو مقادیر با استفاده از نرم افزار VirtualBox وکلاس‌های API VMM جمع‌آوری. شده است منابع حافظه، آدرس تولید شده توسط فرآیند‌های مجازی هستند. API IMachineDebugger VMM می‌تواند ارزش شمارنده‌های برنامه مربوط به دستورالعمل در هر 0.5 میلی‌ثانیه را جمع‌آوری کند. در شکل 4، یک تکه از منابع حافظه در حال جمع‌آوری در طول اجرای مجازی از یک معیار SPEC (gobmk) است.

الگوریتم کلونی پیشرفته زنبور عسل برای حفظ تعادل کارآمد بار و برنامه ریزی در ابر

Enhanced Bee Colony Algorithm for Efficient Load Balancing and Scheduling in Cloud

چکیده :
رایانش ابری یک الگوی مفید می باشد که منابعی را برای مشتریان به درخواست خود آن ها با حداقل هزینه فراهم می کند. هزینه موثر برنامه ریزی و متعادل کردن بار چالش های عمده ای در اتخاذ محاسبات ابری می باشند. از روش های توازن بار کارامد تحت شرایط بارگذاری سنگین در دیتا سنترها اجتناب می شود . هنگامی که برخی از ماشین های مجازی با تعدادی چند از وظایف بیش از حد در ارتباط باشند، این وظایف برای ماشین های مجازی تحت بارگذاری مرکز داده های مشابه در جهت حفظ کیفیت سرویس (QoS) است. این مقاله یک اصلاح در الگوریتم کلونی زنبور عسل برای تعادل بار کارآمد و موثر در محیط ابری پیشنهاد می کند. رفتار جستجوگری زنبور عسل برای تعادل بار در تمام ماشین های مجازی استفاده می شود. وظایف بارگذاری ماشین های مجازی به عنوان زنبور عسل و تحت بارگذاری ماشین های مجازی منابع غذایی درمان می شوند. همچنین این روش برای به حداقل رساندن طول و همچنین تعداد انتقال ماشین های مجازی تلاش می کند. نتایج تجربی نشان می دهد که بهبود قابل توجهی در کیفیت سرویس ارائه شده به مشتریان وجود دارد.

1. مقدمه
تکنولوژی در حال ظهور رایانش ابری به طور کامل به اینترنت تکیه می کند، که در آن تمام داده ها و برنامه های کاربردی بر روی دیتاسنترها قرار دارند، که متشکل از هزاران کامپیوتر با شیوه های پیچیده و به هم پیوسته میزبانی می کنند . ارائه دهندگان ابر با استفاده از مدل پرداخت به بهره برداری از منابع می پردازند. بر روی اینترنت، مشتریان می توانند با پرداخت پول تنها برای مدت زمانی از انرژی، منابع نرم افزاری، فضای ذخیره سازی، و غیره استفاده کنند.
علاوه بر اینترنت ، مشتریان ، دیتاسنترها ، و سرور توزیع اصلی سه بخش از یک سیستم سازگار با اکوسیستم ابر هستند . مرکز داده مجموعه ای از سرورهای میزبان برنامه های کاربردی متفاوت و همچنین با امکان ذخیره سازی است . به منظور اشتراک برای برنامه های مختلف، کاربر نهایی نیاز به اتصال به مرکز داده دارد. معمولا یک مرکز داده دور از کاربران نهایی قرار دارد . سرور توزیع بخش هایی از یک محیط ابری که در حال حاضر در سراسر اینترنت میزبان برنامه های کاربردی مختلف هستند.
به منظور اطمینان از کیفیت سرویس برنامه ریزی کارآمد و توازن بار در بین گره ها در محیط ابر توزیع مورد نیاز است. در ابر رایانه های QoS برای تضمین رضایت مشتری بسیار مهم است. یک مکانیزم تعادل بار کارآمد تلاش می کند تا به زمان اجرای برنامه های کاربردی که کاربر درخواست داده سرعت ببخشد. همچنین عدم تعادل سیستم را کاهش می دهد و دسترسی عادلانه ای به کاربران ارائه می دهد.
تعادل بهتر بار در معیارهای QoS خوب مانند استفاده کارآمد از منابع است، و به مقیاس پذیری، زمان پاسخ، و تحمل خطا منجر خواهد شد. همچنین زمان انتقال را می توان با حفظ تعادل بار بهتر بهبود داد. بهبود در عوامل فوق QoS خوب به مشتریان توافقنامه سطح خدمات در نتیجه کمتر (SLA) نقض تضمین خواهد کرد.
ماهیت پویا از محیط محاسبات ابری نیاز به یک الگوریتم پویا برای برنامه ریزی کارآمد و توازن بار کارآمد در میان گره دارد. الگوریتم متعادل کردن بار تنها زمانی که تغییرات کوچک در وظایف سنگین هستند ایستا کار می کند. مسائل توازن بار و زمان بندی ابر به صورت مسائل ان پی هارد در نظر گرفته می شوند.
الگوریتم های الهام گرفته از طبیعت نقش حیاتی در حل پویا مسائل زمان واقعی دارند، که مسائل سخت را با روش های طبیعی حل می کند. این مسائل ان پی هارد در یک محدوده زمانی حل می شود. الگوریتم های الهام گرفته از طبیعت راه حل های بهینه یا تقریبا بهینه برای این مسائل در زمان واقعی در فاصله زمانی چند جمله ای تولید می کنند. ایده پشت الگوریتم هوش تعامل محلی بسیاری از عوامل ساده برای رسیدن به یک هدف ساده ایجاد کرده است.
الگوریتم زنبور عسل یک الگوریتم هوش ازدحامی بر اساس رفتار تغذیه کلنی زنبور عسل تابع حل مسائل عددی است [1]. این تقلید رفتار جستجوگری زنبور عسل . مزیت هایی مانند حافظه، چند شخصیت، جستجوی محلی و بهبود راه حل را فراهم می کند، پس از آن یک راه حل عالی برای مسائل بهینه سازی است [2-4] . الگوریتم متشکل از زنبورها، و منبع مواد غذایی آن ها است. در کندوی زنبور عسل ، به زنبورها برای منابع غذایی علوفه می دهند. پس از پیدا کردن یک منبع غذایی زنبور عسل به کندو بازگشته و یک حرکت ارتعاشی انجام می دهد. بر اساس حرکت ارتعاشی زنبور های دیگر در کندو اطلاعاتی در مورد میزان غذا و فاصله از کندو زنبور عسل دریافت می کنند . سپس زنبورها به دنبال زنبور به محل کندو زنبور عسل رفته و شروع به برداشت آن می کنند . موقعیت منابع غذایی به صورت تصادفی توسط زنبور عسل انتخاب شده است.
در روش ارائه شده، الگوریتم کلونی زنبور عسل اصلاح و آن به نحو احسن برنامه ریزی و تعادل بار در میان گره های ابر در محیط ابری پویا اعمال می شود. این روش حالت قبلی از یک گره در نظر گرفته می شود در حالی که توزیع بار انجام شده است. برای موازنه بار الگوریتم کلونی زنبور عسل پارامترها به محیط ابر برای دستیابی به تعادل بار نقشه برداری می شود. الگوریتم برای رسیدن به حداقل زمان پاسخ و زمان اتمام تلاش می کند . بخش باقی مانده از این مقاله به شرح زیر سازماندهی شده است. بخش 2 در مورد انواع مختلف روش های تعادل بار در ابر است. الگوریتم پیشرفته کلونی زنبور عسل و معماری آن در بخش 3 شرح داده شده. بخش 4 نتایج تجربی را بیان می کند . در نهایت این مقاله در بخش 5 تجزیه و تحلیل را ارائه می دهد

Abstract

Cloud computing is a promising paradigm which provides resources to customers on their request with minimum cost. Cost effective scheduling and load balancing are major challenges in adopting cloud computation. Efficient load balancing methods avoids under loaded and heavy loaded conditions in datacenters. When some VMs are overloaded with several number of tasks, these tasks are migrated to the under loaded VMs of the same datacenter in order to maintain Quality of Service (QoS). This paper proposes a modification in the bee colony algorithm for efficient and effective load balancing in cloud environment. The honey bees foraging behaviour is used to balance load across virtual machines. The tasks removed from over loaded VMs are treated as honeybees and under loaded VMs are the food sources. The method also tries to minimize makespan as well as number of VM migrations. The experimental result shows that there is significant improvement in the QoS delivered to the customers.

1 Introduction

Cloud computing is an emerging technology completely rely on internet, in which all the data and applications are hosted on a datacenters, which consists of thousands of computers interlinked together in a complex manner. The cloud providers adopt pay as you use model for their resource utilization. Over the Internet, the customers can use computation power, software resources, storage space, etc., by paying money only for the duration he has used the resource. Besides Internet, customers, datacenters, and distributed servers are the main three components of a cloud eco system. Datacenter is a collection of servers hosting different applications and also provides storage facility. In order to subscribe for different applications, end user needs to connect to the datacenter. Usually a datacenter is situated far away from the end users. Distributed servers are the parts of a cloud environment which are present throughout the Internet hosting different applications. In order to ensure QoS efficient scheduling and load balancing among nodes are required in the distributed cloud environment. In cloud computing ensuring QoS is crucial for customer satisfaction. An efficient load balancing mechanism tries to speed up the execution time of user requested applications. It also reduces system imbalance and gives a fair access to the users. Better load balancing will result in good QoS metrics such as efficient resource utilization, scalability, response time, fault tolerance. Also migration time can be improved by better load balancing. The improvement in the above factors will ensure good QoS to the customers thereby less Service Level Agreement (SLA) violations. The dynamic nature of cloud computing environment needs a dynamic algorithms for efficient and efficient scheduling and load balancing among nodes. Static load balancing algorithms will works only when small variation in the workloads. Cloud scheduling and load balancing problems are considered as NP hard problems. Nature inspired algorithms plays a vital role in solving dynamic real time problems, which are hard to solve by normal methods. These NP hard problems are hard to solve within a time limit. Nature inspired algorithms produce optimal or near optimal solutions to these real time problems in polynomial time interval. The idea behind swarm intelligence algorithm is that local interaction of many simple agents to attain a simple objective. The Bee Colony algorithm is a swarm intelligence algorithm [1] based on the foraging behavior of honey bee colonies to solve numerical function optimization problems. It mimics the foraging behavior of honey bees. It has advantages such as memory, multi-character, local search and solution improvement mechanism, so it is an excellent solution for optimization problems [2–4]. The algorithm consists of scout bees, forager bees and food source. In bee hives, scout bees forage for food sources. After finding a food source it returned to bee hive and performs a waggle dance. Based on waggle dance other bees in the hive get information about quantity of food and distance from the bee hive. Then forager bees follow the scout bees to the location of bee hive and begin to reap it. The positions of food sources are randomly selected by the bees. In the proposed method, bee colony algorithm is modified and it is applied to efficiently schedule and balance the load among cloud nodes in the dynamic cloud environment. Here this method considers previous state of a node while distributing the load. For load balancing the bee colony algorithms parameters are mapped to cloud environment for achieving load balancing. The algorithm tries to achieve minimum response time and completion time. The remaining part of this paper is organized as follows. Section 2 describes about different kinds of load balancing methods in cloud. Enhanced bee colony algorithm and its architecture described in Sect. 3. The Sect. 4 gives experimental results and analysis. Finally this paper concludes in Sect. 5.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

وظایف این مقاله به شرح زیر می‌باشد. 1. ما نمونه ای اولیه را از سیستم شبکه‌ای منطقه ای برای ارسال پکت داده های جمع آوری شده از بدن به ابر ایجاد کرده و سپس سیستم ارائه‌شده را مورد اعتبارسنجی قرار می‌دهیم. 2. با استفاده از این مدل اولیه، یک منبع ذخیره‌سازی قابل رشد و یک زیرساخت پردازنده را برای سیستم‌های WBANS که مقیاس بالایی دارند، ارائه می‌دهیم. این زیرساخت به طرز کارآمدی قادر خواهد بود داده های حجیم تولیدشده توسط سیستم WBAN را با ذخیره‌سازی و انجام فعالیت‌های تحلیلی مدیریت نماید. 3. جمع‌آوری داده مبتنی بر تکه ابر با استفاده از تکنولوژی‌های ارتباطی مقرون‌به‌صرفه به طور کامل سیستم های محرک WBAN را پشتیبانی می‌کند. این تکنولوژی‌های ارتباطی توسط سیستم WBAN و تکه ابری پشتیبانی می‌شود. این رویکرد با راهکارهای بهداشت موبایلی که به علت داشتن هزینه‌های بالای ارتباطی مانند، 3G و LTE محدودیت‌های خاص خود را دارد، متفاوت می‌باشد. 4. مدل ارائه‌شده راهکاری قابل اطمینان بدون خطا را معرفی می‌کند که می‌تواند سیستم های WBAN را با زمینه‌ها و مقیاس‌های متفاوت مدیریت کند. راه حل پیشنهادی به صورت جهانی قابل اجرا بوده و می‌تواند در گستره مکانی وسیع و زمینه‌های متفاوت مورد استفاده قرار گیرد؛ مانند، آتش‌نشانی، نظامی، نظارت دانش آموزان در دانشگاه‌ها و سالمندان در خانه سالمندان. 6. این راهکار نه در بخش WBANS و نه در بخش تکه ابر نیازی به تجهیزات خاص ندارد. 7. عملکرد مدل پیشنهادی توسط شبیه‌ساز کلودسیم مورد ارزیابی قرار خواهد گرفت تا تاثیر تعداد تکه ابرهای شبیه‌سازی‌شده و محل استقرار آن‌ها مورد ارزیابی قرار گیرد.

2. فعالیت‌های مرتبط
جمع‌آوری اطلاعات مربوط به بدن می‌تواند از یک کاربر به کاربر دیگر و یا از چند کاربر به یک کاربر انجام گیرد که بستگی به هدف اپلیکیشن کاربردی دارد. اپلیکشن هایی مانند برنامه‌هایی که علائم حیاتی بیمار را بررسی می‌نمایند، به تمام حسگرهای نصبی نیاز دارند تا داده‌ها را به نود سینک (SINK NODE) انتقال دهند که این گره به‌نوبه خود اطلاعات را به صورت انتقال بیسیم به سروری خارج از بدن بیمار می‌فرستد.
یکی از مزیت های استفاده از روش جمع‌آوری داده مبتنی بر مرکز این است که داده ها از ترکیب پکت های داده به وجود می آیند که این پکت ها از گره‌های چندگانه آمده و انرژی مصرف‌شده در شبکه را به‌خوبی کاهش می‌دهند. فرآیند ترکیب چند پکت به یک پکت جمع‌آوری داده نامیده می‌شود. هدف جمع‌آوری داده کاهش تعداد پکت هایی است که در خلال شبکه انتقال داده می شوند. سپس، انرژی مصرفی در کل کاهش پیدا می کند. مدل اولیه جمع‌آوری داده که در فصل 13-15 معرفی خواهد شد، از رویکردی کارآمد برای صرفه‌جویی انرژی استفاده می‌کند، این کار از طریق ترکیب پکت های چندگانه که از گره‌های چندگانه دریافت می‌شود و تبدیل آن‌ها به یک پکت واحد و ارسال آن به مقصد انجام می‌شود. در این مدل اولیه، گره‌های حسگر چندگانه یک فعالیت مشترک را نظارت می‌کنند. به همان صورت، گره‌های میان راهی (MIDWAY NODES) نیز همان فعالیت را نظارت کرده و پکت را به صورت یک پکت واحد متراکم کرده و ارسال می کنند. این مدل اولیه به دلایل زیر در مدل اولیه WBAN قابل به‌کارگیری نمی‌باشد 1. تنها هدف نظارت‌هایی که توسط گره‌های حسگر برداده ها در WBAN انجام می‌گیرد، به دست آوردن یک نتیجه کلی است، 2. در شبکه‌های بیسیم هدف از جمع‌آوری داده کاهش تعداد پکت های ارتباطی است و این کار با حذف افزونه‌های اضافی از داده انجام می‌شود. به‌هرحال، هدف از این مقاله این است که میزان مصرف انرژی انتقال پکت های ارتباطی که توسط WIFI مورد استفاده قرار می‌گیرد نسبت به ارتباط سلولی (CELLULAR) کاهش پیدا کند. با انجام مقایسه با انتقال‌های چندگانه در شبکه‌های حس بیسیم، گره‌های حسگر در WBAN برای انتقال مستقیم طراحی می‌شوند. به‌هرحال، حجم عظیم داده هایی که توسط گره‌های WBAN جمع‌آوری می‌شوند، نیازمند زیرساخت‌های قدرتمندی برای پردازش و ذخیره‌سازی می باشند و انتقال داده باید قدرتمند بوده و قابلیت رشد داشته باشد. جمع‌آوری داده مبتنی بر تکه ابر که در این مقاله پیشنهاد می‌شود نقش مهمی را در دستیابی به اهداف فوق آلذکر ایفا می کند. تا آنجایی که ما می‌دانیم، پیش از این هیچ تحقیقاتی در این زمینه انجام نگرفته است.
استفاده از WBAN در حوزه نظارت بر سلامت برای بیش از یک دهه مورد توجه بسیاری قرار گرفت. برخی از مولفان تکنیک های بهداشت موبایلی را ارائه نمودند که بر مبنای WBAN قرار داشت و راهکارهایی مناسبی را برای نظارت بر سلامت بیماران به صورت روزانه عرضه می‌نمود. این مقاله ایده بهداشت موبایل را برای جمع‌آوری اطلاعات و ایجاد ارتباط استفاده می‌کند، درحالی‌که از رایانش ابری تنها برای ذخیره‌سازی اطلاعات و پردازش آن‌ها در سطح سازمانی بهره می‌برد. یک میان افزار خدمات محور (SOA) بعدا و در فصل 19 به شما معرفی خواهد شد. فرض این ساختار بر این است که حسگرهای WBAN توانایی انتقال داده‌ها را از طریق استفاده از گره دروازه (GATEWAY NODE) دارند که این گره وظیفه انتقال دوباره داده‌ها را به یک واحد رایانشی از راه دور دارد. هم‌چنین گره دروازه قابلیت دریافت اطلاعات کنترل کننده (کنترل کننده وضعیت مورد نظارت) و دیگر اطلاعات مربوط به WBAN را از گره‌های از راه دور دارد.
در فصل 20 موبی کلود (ابری موبایل) ارائه می‌گردد که توضیح می‌دهد که چگونه رایانش ابری موبایل از رایانش موبایل و رایانش ابری پدید می آید. در این تحقیق، مولف قلمرو موبی کلود را گسترش داده و سپس به چالش های تحقیقاتی فعلی در زمینه رایانش ابری موبایل می‌پردازد. سیستم موبی کلود پیشنهادی به وجود آمده است تا پژوهش و تحلیل رایانش ابری موبایل را آسان‌تر گرداند. تاثیر استفاده از تکه ابر همراه با رایانش ابری موبایل در اپلیکیشن های تعاملی (مانند، ویرایش فایل ها، ارسال ویدئو و گفتگوهای اینترنتی مشترک) در فصل 21 مورد تحلیل قرار می‌گیرد. در این تحقیق، دو مدل از نظر توان عملیاتی سیستم و تاخیر در انتقال موردبررسی و تحلیل قرار می‌گیرند. نتایج این پژوهش نشان می دهد که در بسیاری از موارد مدل مبتنی بر تکه ابر عملکردی بهتر از مدل مبتنی برابر داشته است. در فصل 22 مولف ساختاری جدید را بانام MOCHA پیشنهاد می‌دهد که دارای ویژگی تشخیص چهره می‌باشد. هدف از این ساختار کاهش زمان پاسخ در هنگام پروسه تشخیص چهره می‌باشد. MOCHA ترکیبی است از دستگاه‌های موبایل، تکه ابر و سرورهای ابری. مشکلات تخصیص منابع و کنترل پذیرش در اپلیکیشن های اجرایی موبایل در تکه ابر در فصل 23 موردبررسی قرارگرفته اند. مولفان این مقاله این مشکلات را با فرمول‌بندی کردن آن‌ها به شکل فرآیند تصمیم‌گیری سمی ماکروف (SMDP) حل نموده اند. مدل ارائه‌شده در این مقاله یک QOS را برای انواع مختلف کاربران تلفن همراه پیشنهاد می‌کند. موانع و مشکلات فنی استفاده از تکه ابر در رایانش موبایل در فصل 24 موردبررسی قرار می‌گیرد. ساختاری جدید برای پرداختن به موانع مطالعه شده در نظر گرفته‌شده است. این ساختار درخواست های صورت گرفته توسط کاربران را در تکه ابر مدیریت می نماید. این مدیریت بر اساس ماشین های مجازی تعریف شده برای هر کاربر موبایل انجام می گیرد.
ایده جدید ادغام سیستم WBAN و رایانش ابری به دلیل قابلیت پشتیبانی سیستم ابری از تقاضاهای افزایش یافته در رابطه با WBAN گرفته شده است. چرا که WBAN قابلیت افزایش حجم ذخیره سازی را داشته و دارای ظرفیت بالایی از منابع رایانشی است. تا آنجای که ما می دانیم، این ایده جدید هرگز پیش ازاین در هیچ تحقیقی به کار گرفته نشده است. علاوه بر این، ما راهکارهایی در غالب وسایل موبایلی آگهی دهنده و در مقیاس بزرگ ارائه داده ایم که به طور کامل توسط سیستم های WBANS مبتنی بر تکه ابر پشتیبانی می شود، این راهکار ها هرگز پیش از این در جایی ارائه نشده است. در حالی که بیشتر راهکارهای پیشنهادی پیش از این عمدتا مسائل مربوط به سلامتی را مورد هدف قرار می داد، راهکارهای پیشنهادی ما راهکارهای جامعی هستند که محدود به حوزه سلامتی نبوده و می توانند در زمینه ها و محیط های مختلف مورد بهره برداری قرار گیرند. نمونه هایی از این کاربردها به شرح زیر است، سازمان های آتش نشانی، نظامی و نظارت دانش آموزان در مدارس و یا سالمندان در خانه های سالمندان که در این مکان ها استفاده از تکه ابرها به تحرک و خوشه بندی کاربران در این برنامه های کاربردی بستگی پیدا می کند.

3. اکتشافات مقدماتی
3.1 نمونه سیستم های اولیه WBAN
یک شبکه بیسیم بدن منطقه (WBAN) به وسیله قرار دادن گره های حسگر متعدد بر روی یک هدف انسانی ایجاد می شود. گره های حسگر برای جمع آوری اطلاعات درباره موارد مختلفی همچون، فشار خون، ضربان قلب، تعداد تنفس، دیابت، دمای بدن، رطوبت، EGG، تحرک، نزدیکی و مسیر مکان و غیره بیمار مورد استفاده قرار می گیرد. گره های حسگر می توانند بر روی بازوها، پیشانی، مچ دست، مچ پا، ران پا و دور کمر قرار گیرند، شکل 1 مکان های جاگذاری این حسگرها را به تصویر می کشد. حسگرهای پوشیدنی شامل 900 MHZ MICA2DOT MOTE با تراشه رادیویی SMARTRF CC100 ساخت شرکت چیپکون (CHIPCON.COM)؛ و کارت حسگرهایی MTS510 ساخت شرکت کراسبو می باشد (XBOW.COM). MICA2DOT MOTE از سیستم عامل TINYOS برای جمع آوری اطلاعات به روش های متفاوت استفاده می کند. یک باتری سلولی 570 میلی آمپری برای راه اندازی گره های MICA2DOT با وزن تقریبی 10 گرم مورد استفاده قرار می گیرد. از پروتکل CSMA و MCA با نرخ داده 19.2 استفاده می شود. به منظور صرفه جویی بیشتر در برق و اجرای سیستم به مدت طولانی تر، طیف انتقال نباید بر روی عددی بیشتر از 1M تنظیم شود. علاوه بر مصرف کمتر انرژی در انتقال، می توانیم از دخالت عوامل خارجی در WBANS های مختلف موجود در شبکه اجتناب کرده و همجنین با ایجاد رقابت حتی میزان مصرف انرژی گیرنده ها و فرستنده ها را بیشتر کاهش دهیم. حسگرهایی که با توپولوژی استار کار می کنند، هرکدام شرایط کیفی خود را به نود سینک ارسال می کنند. در این مرحله می توان داده های جمع آوری شده را به یک پکت واحد تبدیل نمود. سپس داده ادغام شده توسط بلوتوث به یک گوشی هوشمند و یا به یک دستیار دیجیتال شخصی (PDA) فرستاده می شود تا به وسیله اپلیکیشن های نظارتی WBAN مورد بررسی قرار گیرد.
WIFI یک تکنولوژی ویژه است که به وسائل الکترونیکی اجازه می دهد تا بتوانند به صورت بیسیم و با استفاده از امواج رادیویی تبادلات داده ای خود را انجام دهند و به صورت شبکه محلی بیسیم (WAN) تعریف می شود که بر اساس استاندارد های IEEE 802.11 عمل می کند. در حالی که شبکه سلولی شبکه ای است رادیویی که به صورت منطقه ای توزیع می شود و هر شبکه حداقل دارای یک فرستنده-گیرنده با جایگاه ثابت می باشد. شبکه سلولی به تعداد زیادی از دستگاه های تلفن همراه این قابلیت را می دهد که بتوانند با هم از طریق فرستده-گیرنده های ثابت ارتباط برقرار کنند. کاربر WBAN با استفاده از WIFI می تواند پکت های داده ای را با صرف انرژی و تاخیر کمتر نسبت به شبکه سلولی انتقال دهد، اما طیف انتقال از 100M تجاوز نمی کند. این قابلیت WIFI بسیار حیاتی است، چرا که انرژی موجود در حسگرها محدود بوده و حسگرها باید بتواند با صرف انرژی پایین داده ها را به صورت موفقیت آمیز به سیستم ابری انتقال دهند. در روش کاری ما، تکنولوژی WIFI در محدوده تکه ابری قابل دسترسی خواهد بود. مشخص گردیده است که برای انتقال یک پکت 46 بایتی 30 مگاوات انرژی مصرف می شود و مدت زمان ارسال نیز 0.045 میلی ثانیه می باشد. از سوی دیگر، ارتباط شبکه ای گسترده تر (از نظر جغرافیای) شبکه های سلولی (برای مثال، 3G و LTE) این امکان را به وجود می آورد که پکت های داده از هر منطقه ای که تحت پوشش شبکه سلولی باشد، انتقال یابد که معمولا در مقایسه با مناطق تحت پوشش WIFI گستردگی بیشتری دارد. مشخص شده است که برای انتقال پکت داده 46 بایتی نیاز به صرف انرژی به میزان 300 مگاوات بوده و این کار در مدت زمان 0.45 میلی ثانیه انجام می گیرد. در شرایطی که اتصال سلولی از نظر صرف انرژی و زمانی و هزینه برقراری ارتباط بسیار پرهزینه می باشد (WIFI در بیشتر موارد هزینه اتصال رایگان دارد)، این موضوع اهمیت بسیاری دارد که در مواردی که تکه ابر در منطقه وجود ندارد، قابلیت جابجایی کاربران WBAN فراهم شده و قابلیت افزایش توانایی های سیستم برای پشتیبانی از تعداد بالای کاربران WBAN ایجاد شود. همان گونه که ما در بخش 4 در این باره توضیح خواهیم داد.

فراهم کردن امکان جابجایی کاربران WBAN یکی از مهم ترین وظایف مدل پیشنهادی است؛ بنابراین، در هنگام اجرا، یک مدل حرکتی نقطه مسیر تصادفی ارائه شده است تا امکان جابجایی کاربران WBAN ایجاد شود. کاربر تلفن همراه ممکن است با توجه به مکان و زمانی که در آن قرار دارد، در یکی از مناطق ذکر شده در زیر حضور داشته باشد. 1. منطقه تکه ابری (CR): این منطقه توسط WIFI پوشش داده می شود و در این مکان کاربر می تواند با استفاده از تکنولوژی WIFI پکت داده ها را به تکه ابر انتقال دهد. 2. منطقه شرکتی (ER) (منطقه ای که تحت پوشش ابر یک شرکت قرار دارد): این منطقه تحت پوشش شبکه سلولی نام دارد و کاربر تنها با استفاده از تکنولوژی سلولی می تواند پکت داده ها را به ابر شرکتی انتقال دهد. 3. منطقه ای که تحت پوشش قرار ندارد (NC)، در این منطقه نه تکنولوژی WIFI و نه سلولی قابل استفاده نیست و کاربر می تواند داده ها را نگه داشته و زمانی که در منطقه تحت پوشش یکی از این دو تکنولوژی قرار گیرد، ارسال نماید. سپس می تواند داده ها را به ابر تشکیلاتی ارسال کند. با داشتن قابلت تحرک نقطه مسیر تصادفی کاربر می تواند از منطقه ای به منطقه دیگر حرکت نماید، بنابراین مکانیزم انتقال پکت های داده به منطقه تحت پوشش بستگی پیدا می کند. از سوی دیگر، کاربران نیز می توانند داده ها انتقالی را از نزدیک ترین تکه ابر و یا ابر شرکتی دریافت کنند. این داده ها می تواندد شامل پیام های هشداردهنده، کنترل کننده و یا پیام هایی باشند که برای اگاهی از شرایط کاربر WBAN ارسال می شود.

3.2 نمونه های اولیه سیستم های ابری
هدف این بخش توسعه سیستم های اولیه WBAN مبتنی بر تکه ابر می باشد. این سیستم اولیه قصد دارد تا قابلیت مدل ارائه شده را برای نیل به اهداف فوق الذکر به اثبات برساند. در این نمونه، ما به کارگیری ابزار شبیه ساز کلودسیم را گسترش می دهیم تا مدل WBAN مبتنی بر تکه ابر را به خوبی تشریح کنیم. کلودسیم ابزار شبیه ساز مبتنی بر ابری شناخته شده است که در دانشگاه ملبورن استرالیا ابداع شد. کلودسیم اصلی شامل احزاء سازنده تکه ابر WBANS نمی شود. در این نمونه اولیه اجزاء سازنده مورد نیاز WBAN و تکه ابر ایجاد شده و سپس با شبیه ساز کلودسیم ادغام شده اند تا مدل ارائه شده توسط ما مورد بررسی قرار گیرد. این شبیه ساز کلود سیم توسعه یافته بعدا در اختیار عموم قرار خواهد گرفت.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

در (Nasonov D. یک.، 2014) نویسندگان سعی بر مواجهه با سناریوهای مهلت سخت از پیش تعریف شده سیستم هشدار دهنده از طریق بهینه سازی برنامه ریزی پس زمینه با پارامترهای قابلیت اطمینان منابع پذیرفته شده و همچنین تغییرات کم سناریو در حجم کاری هایی که می‌تواند به راحتی با طرح حاضر وفق داده شود، نمودند.
مائو و هامفری در (مائو، 2011) رویکردی برای بهینه سازی اجرای روندهای کاری با مدیریت ماشین‌های مجازی به صورت پویا در محیط ابری توصیف نمودند. هدف اصلی از این تحقیق به حداقل رساندن هزینه اجرا و همچنین سعی بر حفظ مهلت روند کار بود. این کار به پردازش جریان‌های کاری تنها، با مهلت نرم و در یک راه مقرون به صرفه مرتبط است، درحالی که ما سعی برای حفظ چند روند کاری با مهلت سخت داریم.
در (Nebro، 2009) نویسندگان الگوریتم ژنتیک سلولی مبتنی بر تعامل همسایگی پیشنهاد نمودند، که در آن هرکدام از اجزا تنها می‌توانند با همسایگان نزدیکشان در حلقه پرورش همکاری کنند. اگرچه مقایسه این روش در برابر NSGA-II و SPEA2 نتایج خوبی نشان داده است، کاربردپذیری این الگوریتم در سری روندهای‌کاری با امکان مهلت، موضوع تحقیقات آینده است.
3. شرح مشکل
در این بخش ما مفروضات مان در مورد روندهای کاری، وظایف و منابع محاسباتی آنها، تعریف مساله و راه حل پیشنهاد مان برای آن را توصیف می‌کنیم.

3.1 روندهای کاری
معمولا روندهای کاری در قالب گراف غیر مدور و مستقیم (DAG) هستند که در آن گره‌ها برای نشان دادن وابستگی وظایف و لبه‌ها به وظایف (در اکثر موارد وابستگی داده ها) هستند. شرح مفصل این رویکرد در (Sinnen، 2007) داده شده است. در کار ما کل زمان اجرا (makespan) به عنوان پارامتر اصلی بهینه سازی، محدود شده با قید مهلت تعریف شده است. هر روند کاری می‌تواند مهلت زمانی سخت مشخص برای کاربرداشته باشد، که در آن روندهای کاری باید به همه معنا اجرا شوند. ما نمی‌توانیم اجرا را تا زمانی که همه ی مهلت‌ها در برنامه زمانی نگهداری شوند، شروع کنیم.
در این کار ما از تعدادی روند کاری مصنوعی تولید شده که برنامه‌های علمی ‌واقعی از زمینه‌های مختلف علمی ‌را تکرار می‌کند، استفاده می‌کنیم: Montage (نجوم)، CyberShake (علم زلزله)، Epigenomics (زیست شناسی)، Inspiral (فیزیک گرانشی) و SIPHT (زیست شناسی) (Bharathi، 2008 ). اینها اطلاعات دقیقی در مورد ساختار روند کار، زمان اجرای نسبی وظایف، ورودی و خروجی داده برای هر وظیفه و وابستگی داده فراهم می‌کنند. Bharathi و همکاران یک ژنراتور روند کار توسعه دادند، که اجازه تولید نسخه‌ای از روند کاری توصیف شده با تعداد مختلف از وظایف در قالب DAX (گراف غیر مدور مستقیم در XML) را می‌دهد. مثالی از ساختار روندکار را می‌توان در شکل 1 یافت.
زمان اتمام وظیفه در فاز اجرا توسط توزیع نرمال هر وظیفه t با مقدار متوسط m و واریانس d برآورد شده است. در برنامه ریزی زمان اتمام فاز، زمان ثابت و برابر مقدار میانگین در نظر گرفته شده است.

3.2 منابع محاسباتی
همه منابع محاسباتی یک قبابلیت اطمینان معین دارند و ما باید این واقعیت را در نظر بگیریم تا احتمال شکست روند کار با مهلت را به کمترین مقدار برسانیم. برای این منظور ما سعی می‌کنیم، از طریق تکرار هر یک از وظایف این روندکاری با 99٪ قابلیت اطمینان اجرا شود. برای مثال، اگر وظایف را با قابلیت اطمینان 0.8 بر روی منابع نگاشت کنیم باید این کار را بر روی یکی دیگر از منابع با قابلیت اطمینان حداقل 0.95 تکرار کنیم تا قابلیت اطمینان اجرای 99٪ حاصل شود، زیرا P(AB)=P(A).P(B) که در آن P(A) میزان شکست از منابع 1 و P(B)- میزان شکست از منابع 2 است.
در این کار ما محیط محاسباتی را به منظورپیاده سازی تکنیک‌های مجازی سازی در نظر گرفتیم. به این معنی که به جای منابع محاسباتی واقعی، وظایف روند کاری را در تعدادی از منابع مجازی که بر اساس منابع واقعی است، نگاشت کردیم.

3.3 شرح مساله
همانطور که در بالا ذکر شد، زمانی که محدودیتهای مهلت سخت برای نتایج نهایی ضروری است و تکنیک‌های محاسبات فوری مورد نیاز است، موارد بسیاری وجود دارد، که ما را وادار به تغییر اولویت در طول بهینه سازی و انطباق الگوریتم موجود به محدودیت‌های قوی در ابتدا و تنها پس از آن بهینه سازی نمودن makespan توسط خودش با توجه به تغییرات پویا در طول فرآیند اجرا در محیط می‌کند. برای چنین الگوریتمی‌ مهم‌ترین نکته دریافت نتایج در زمان ثابت است همچنین نیاز به پردازش چند روندکاری در یک مرتبه است، که در آن هر یک از آنها می‌توانند معیارهای فوری داشته باشند و باید در مقدار مشخصی از زمان تکمیل شوند، به عبارت دیگر مهلت اجرای سختی دارند. تحقیقات ما با هدف بررسی کاربردپذیری الگوریتم‌های فوق ابتکاری، به ویژه، الگوریتم ژنتیک مرسوم (Butakov، 2014)، برای روند کاری برنامه ریزی با مهلت سخت است.

4. راه حل پیشنهادی
در این بخش الگوریتم‌های فوق ابتکاری تکاملی و الگوریتم‌های اکتشافی اصلاح شده ارائه شده است.

4.1 الگوریتم ژنتیک تکاملی مهلت سخت(HDCGA)
ما مجازی سازی را به عنوان راهی برای افزایش عملکرد زمان بندی در نظر گرفتیم. در (Butakov، 2014) مفهوم رویکرد مرسوم برای برنامه سازی در محیط‌های مجازی ناهمگن بیان شده است. این ایده در مراحل تکاملی به طور همزمان برای زمان بندی وظایف و محیط محاسباتی است. تکامل نگاشت وظایف به روش کلاسیک متقاطع، جهش و انتخاب توسط تابع تناسب سازمان یافته است. تکامل منابع توسط مدیریت منابع مجازی انجام می‌شود. در هر جامعه منابع واقعی به مجموعه‌ای از ماشین‌های مجازی تقسیم می‌شوند. این منابع تشکیل ذرات تکامل می‌دهند، که در شکل 2 نشان داده شده است . طرح اصلی الگوریتم HDCGA در شکل 3 نشان داده شده است. در هر مرحله از فرآیند پیکربندی و برنامه ریزی جمعیت ادغام می‌شوند. سپس برای هر جفت از ذرات زمان بندی ایجاد می‌کنیم، آن را با تابع تناسب ارزیابی می‌کنیم و استراتژی را بر اساس نتایج تابع تناسب اجرا می‌کنیم. در آزمایش‌های‌ ما توجه شده بود که استفاده از این الگوریتم اجازه بهبود لیست اکتشافی، مانند HEFT، تا 84٪ را می‌دهد.

مقاله انگلیسی رایگان (PDF)

ترجمه فارسی رایگان (PDF)

خرید ترجمه با فرمت ورد

بخشی از ترجمه فارسی مقاله:

5.4 تطبیق منابع
دلیل اصلی اضافه نمودن محاسبات ابری از دیدگاه یک کاربر جابجایی از یک مدل CAPEX به OPEX است که این کار به جای خریداری منابع فناوری اطلاعات صورت می گیرد. در این راستا یک کمپانی به کمپانی دیگر برای منابع استفاده شده پول پرداخت خواهد کرد. جنبه مهم این است که کمپانی به مدت طولانی نیازمند تبلیغ منابع اش نخواد بود. امروزه این حالت معمول است زمانی که یک کمپانی منابع خود را در یک شرکت سرمایه گذاری می کند و در نتیجه مقدار منابع توسعه یافته در زمان اوج به حداکثر نخواهد رسید و یک روند منظم را طی می کند. مفهوم کلیدی چهارچوب بحث شده در Zhuand Agrawal (2010) الگوریتم تطبیق پویای منابع است که مبتنی بر فرضیه کنترل است. یک سیاست کنترل هدایت تقویت یادگیری برای تنظیم پارامترها تطبیق داده می شود به طوری که سود برنامه با استفاده از سربار به حداکثر برسد. چنین مدل کنترلی می تواند سریع و با دقت اموزش داده شود. علاوه بر این یک مدل منبع برای نگاشت هر ترکیبی از مقادیر از پارامترهای تطبیقی با ملزوم ساختن منبع صورت می گیرد تا تضمین نماید هزینه از بودجه موجود تجاوز نکند.
Duong et al (2009) یک چهارچوب انعطاف پذیر را برای ارائه منابع پویا و تطبیق در ابرهای IaaS مطرح کردند. هسته این چهارچوب تنظیم الگوریتم های تطبیقی منابع است که بار کاری را با اطلاعات منبع کاربردی ساخته تا تغییرات تصمیات رادر تغییر تقاضای کاربران پوشش دهد.
Senna et al (2011) یک معماری برای مدیریت و تطبیق شبکه های مجازی بر ابر ارائه دادند. زیرساخت آن ها اجازه ساخت شبکه های مجازی مرتبط با اجرای جریان های کاری را داده و از محیط کاربر حفاظت می کند. شبکه های مجازی استفاده شده در اجرای جریان کاری دارای عملکرد نظارت شده اشان توسط مدیری هستند که نقش پیش گیرانه ای در مورد خرابی عملکرد در زمان الزامات را دارد.
انعطاف پذیری تطبیق راه حل های ابر را برای تمامی کاربران صورت می بخشد تا اطمینان دهد ان ها آن چه را که دقیق می خواهند را دریافت کرده اند. بدین وسیله محاسبه ابری نه تنها راه جدیدی از چگونگی اجرای محاسبات را صورت می بخشند بلکه طیفی از مسائل ICT شناخته شده را در مناطق مختلف آموزش و بهداشت و درمان و… حل می کنند.تطبیق منبع میزبان های مجازی باید به طور پویا برای تقاضاهای به روز شده به خوبی برنامه های collocate حل شود تا صرفه جویی در مصرف انرژی صورت پذیرد. Sclater (2011). از مهم تر تراکنش های منبع ، در طول حجم کار است که باید با توجه به عدم تطابق منابع پیشنهادی به حداقل رسانده شود. یک سیستم که می تواند به طور خودکار مقیاس بندی منابع زیرساختی به اشتراک گذاشته را صورت بخشد در Charalambous (2010) انجام شده است. نظارت های مدیر تطبیق و تخصیص خودکار منابع به کاربران از طریقی پویا صورت می گیرد. با این حال این شیوه متمرکز نمی تواند در آینده متناسب با محیط ابری چند ارائه دهنده باشد. زیرا ارائه دهندگان مختلف ممکن نیست بخواهند توسط چنین مدیریت متمرکزی نظارت شوند. درجه مدیریت منابع ، پیوند منابع API و هماهنگی منابع در چندین ابر در روشی بی نقص صورت گرفته و اهداف عملکردی را حفظ می کند که می تواند بسیار شایسته رسیدگی در آینده باشد. همچنین مقیاس بندی پویای LBS و تاثیراتش بر مقیاس بندی کل برنامه در
Vaquero et al (2011) و سرویس مقیاس بندی خودکار آمازون مطرح شده است. هدف نویسندگان در Baldine et al (2009) مدیریت شبکه اساسی به صورت منابع کلاس اولی است که می تواند زمان بندی و تخصیص همکار گونه را با منابع محاسباتی و ذخیره سازی صورت بخشد تا یک شبکه کامل اماده به ساخت را معرفی نماید.
Jung et al (2008) یک شیوه ترکیبی جدید برای رفتاری خودکار پیشنهاد کردند که از مدل های نظریه صف بندی با تکنیک های بهینه سازی استفاده می کند تا رفتار مدل را پیش بینی کرده و به طور خودکار تنظیمات بهینه سیستم را تولید کند. Marshall) 2010 ) مدیریت منابع را اجرا کرده و بر Nimbus toolkit ساخته شدند و به صورت امن و پویا خوشه های فیزیکی را بر ابر ارائه کردند. رابط های مدیریت الاستیک به طور مستقیم با مدیران محلی در ارتبط اند همانند Torque .
Raghavan et al (2009). طراحی و پیاده سازی محدوده نرخ توزیع شده را با همکاری “نر” کلی تجمیع در گوشه های متفاوت مطرح ساخته و سیاست های ترافیک شبکه مبتنی بر ابر را با ان در همکاری قرار داد و همچنان اطمینان داد که جریان های لایه پاسخ ازدحام رفتار جریان گونه ای خواهند داشت اگر به اشتراک گذاشته شوند.
5.4.1 چالش های حل نشده تطبیق منابع
– تقاضا برای استفاده از سرویس های ابر ارائه شده توسط فروشنده چگونه است؟ آیا این امر ثابت است یا به طور گسترده متغیر است؟
– فرکانس استفاده از منابع ابر چیست؟ مکررا تکرار می شود؟ استفاده مکرر در حقیقت مدل پرداخت پس از برداشت را اقتصادی ترمی کند؟ آیا سرویس های سفارشی سازی شده توسط فروشندگان نیازاند؟ فروشندگان ابر سرویس های سفارشی سازی شده را بیشتر ارائه می کنند و به همین ترتیب قیمت کاری آنها جذاب به نظر نمی رسد.
– آیا ماموریت برنامه مهم است؟ یک ماموریت بحرانی آیا نیازمند قدرت SLAs است که نتواند قادر به رفع نیاز ها نباشد؟
– آیا یک مسئله می تواند در قطعه ای برنامه ما رخ دهد که QoE تحت تاثیر انطباق قرار گیرد یا خیر؟
– آیا مسئله اطلاعات یا ما ارائه دهنده سرویس برنامه ما به اشتراک گذاشته خواهد شد اگر برنامه ما نتواند بطور خودکا خود را کنترل کند؟
– آیا می توان تمام جزئیات فعال و غیر فعال را در اتصال و مسیر انتها به انتها و سطوح دامنه ISP نظارت کنیم؟
– می توان تمام اندازه گیری های مربوط به ارائه آفلاین کاربران QoE را تحلیل نمود؟ برای نمونه شناسایی در زمان وقایع غیرعادی تاثیر گذار بر کاربران QoE .

بخشی از مقاله انگلیسی:

5.4. Resource adaptation

The primary reason for adapting cloud computing from a user perspective is to move from the model of capital expenditure (CAPEX) to operational expenditure(OPEX). Instead of buying IT resources like machines, storage devices etc. and employing personnel for operating, maintaining etc., a company pays another company (the provider) for the actual resources used (pay-as-you-go). An important aspect of this is that a company no longer needs to overprovision its IT resources. It is typical today, when a company invests in its own resources, that the amount of resources invested in corresponds to the maximum amount of resources needed at peak times with the result that much of these resources are not needed at all during regular periods. The key conceptual component of framework discussed in Zhu and Agrawal (2010) is a dynamic resource adaptation algorithm, which is based on control theory. A reinforcement learning guided control policy is applied to adjust the adaptive parameters so that application benefit is maximized within the time constraint using modest overhead. Such a control model can be trained fast and accurately. Furthermore, a resource model is proposed to map any given combination of values of adaptive parameters to resource requirements in order to guarantee that the resource cost stays under the budget. Duong et al. (2009) have proposed an extensible framework for dynamic resource provisioning and adaptation in IaaS clouds. The core of this framework is a set of resource adaptation algorithms which utilize workload and resource information to make informed provisioning decisions in light of dynamically changing users demands. Jung et al. (2010) present Mistral, a holistic optimization system that balances power consumption, application performance, and transient power/performance costs due to adaptation actions and decision making in a single unified framework. By doing so, it can dynamically choose from a variety of actions with differing effects in a multiple application, and dynamic workload environment. Calyam et al. (2011) use OnTimeMeasure-enabled performance intelligence to compare utility-driven resource allocation schemes in virtual desktop clouds. The results from the global environment for network innovations(GENI) infrastructure experiments carried out by the authors demonstrated how performance intelligence enables autonomic nature of FI (Future Internet) applications to mitigate the costly resource overprovisioning and user QoE (Quality of Experience) guesswork, which are common in the current Internet. Senna et al. (2011) present an architecture for management and adaptation of virtual networks on clouds. Their infrastructure allows the creation of virtual networks on demand, associated with the execution of workflows, isolating and protecting the user environment. The virtual networks used in workflow execution has its performance monitored by the manager which acts preemptively in the case of performance dropping below stated requirements. Flexibility enables the adaptation of cloud solutions to all users to ensure that they get exactly what they want and need. By that, cloud computing not only introduces a new way of how to perform computations over the Internet, but some observers also observed that it holds the potential to solve a range of ICT (information and communications technology) problems identi- fied within disparate areas such as education, healthcare, climate change, terrorism, economics etc. as per Schubert (2010). Resource adaptation of the virtual hosts should dynamically scale to the updated demands (cloud computing) as well as colocate applications to save on energy consumption (green computing) as per Sclater (2011). Most importantly, resource transitions during workload surges should occur while minimizing the expected loss due to mismatches of the resource predictions and actual workload demands. A system that can automatically scale its share of infrastructure resources is designed in Charalambous (2010). The adaptation manager monitors and autonomically allocates resources to users in a dynamic way. However, this centralized approach cannot fit in the future multiprovider cloud environment, since different providers may not want to be controlled by such a centralized manager. There have been great advances towards automatically managing collections of inter-related and context-dependent VMs (i.e. a service) in a holistic manner by using policies and rules. The degree of resource management, the bonding to the underlying API and coordinating resources spread across several clouds in a seamless manner while maintaining the performance objectives are major concerns that deserve further study. Also, dynamically scaling LBS (location based services) and its effects on whole application scalability are reported in Vaquero et al. (2011) and Amazon auto scaling service. The goal of authors in Baldine et al. (2009) is to manage the network substrate as a first-class resource that can be co-scheduled and co-allocated along with compute and storage resources, to instantiate a complete built-to-order network slice hosting a guest application, service, network experiment, or software environment. The networked cloud hosting substrate can incorporate network resources from multiple transit providers and server hosting or other resources from multiple edge sites (a multi-domain substrate). Jung et al. (2008) propose a novel hybrid approach for enabling autonomic behavior that uses queuing theoretic models along with optimization techniques to predict system behavior and automatically generate optimal system configurations. Marshall et al. (2010) have implemented a resource manager, built on the Nimbus toolkit to dynamically and securely extend existing physical clusters into the cloud. The elastic site manager interfaces directly with local resource managers, such as Torque. Raghavan et al. (2009) present the design and implementation of distributed rate limiters, which work together to enforce a global rate limit across traffic aggregates at multiple sites, enabling the coordinated policing of a cloud-based service network traffic. This abstraction not only enforces a global limit, but also ensures that congestion-responsive transport-layer flows behave as if they traversed a single, shared limiter. Table 10 summarizes some of the resource adaptation schemes. Table 11 lists out the performance metrics of the resource adaptation schemes.

5.4.1. Open challenges in resource adaptation How is the demand for using the cloud services provided by the vendor? Is it mostly constant or widely varying? What is the frequency of usage of cloud resources? Is it highly frequent? Very frequent usage in fact makes less economic sense to go for cloud based pay-as-you-go model. Do we need highly customized services/API (application programming interfaces) to be exposed by the vendor? Cloud vendors would not find it economically attractive to provide highly customized services and hence price for enterprise (users of cloud) might also be not very attractive. Is the application mission critical? A mission critical application would need very stringent SLAs, which cloud vendors could not be able to satisfy as yet. An industry or application with highly stringent compliance requirements might still not find it suitable to consume key services from a vendor due to inherent risks involved. Can a problem occurence in our slice environment that impacts our QoE be identified and notified to our application to adapt and heal? Can problem information also be shared with us and our application service provider if our application cannot automatically heal itself? Can we monitor all the detailed active (e.g., Ping, traceroute, iperf) and passive (e.g., TCP dump, netow, router-interface statistics) measurements at end-to-end hop, link, path and slice levels across multiple federated ISP domains? Can we analyze all the measurements to offline provision adequate resources to deliver satisfactory user QoE, and online i.e., real-time identify anomalous events impacting user QoE?

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

سیستم ابر هنوز مدل سیستم IT نسبتا جدیدی است که راه زیادی پیش رو دارد و بسیاری از کارشناسان معتقدند که یکی از بزرگترین خطرات عوامل ناشناخته است، زیرا اجزای نرم‌افزار و مدل خارج از اندازه‌گیری خطرات آماری عمل نمی‌کند. در حدود سه سال گذشته، ابرها از یک الگوی نسبتا ناشناخته به IT با محبوبیت شدید انتقال یافتند، 60٪ از مشتریان شرکت در تلاش برای حرکت به فناوری ابر برای رسیدن به بازده بیشتر بودند [15، 16]. فن‌اوری ابر معمولا ترکیبی از سخت‌افزار مشخص با برداشت جدید نرم‌افزار از مفاهیم قدیمی مانند hypervisor است. بااین‌حال، مدل کسب‌وکار (1) پرداخت فقط برای مقدار استفاده شده است؛ (2) سرویس‌های وب مرتبط با SOA است (معماری سرویس‌گرا)، و (3) اتوماسیون جدید فن‌آوری ها، ترکیبی بسیار مفیدی برای محاسبات ابری ایجاد می‌کند. این پدیده موجب ایجاد بسیاری از برنامه‌های جدید مانند سرویس مس‌شود، و در حال حاضر میلیون‌ها نفر از کاربران در حال مصرف ابرهای با نرم‌افزار هنوز کامل نشده هستند. قابل درک است که به‌طور مداوم در مورد امنیت مسائل و خطرات مرتبط با ابر بحث کنیم.

چند مستاجره
عامل خطر در چند مستاجره مربوط به مسائل و چالش‌هایی مرتبط با به اشتراک‌گذاری فیزیکی منابع IT مانند CPU، حافظه، سوئیچ شبکه، فایروال‌ها، سخت‌افزار و نرم‌افزار و سایر اجزاء است. چند مستاجره به‎طور بالقوه می‌تواند منجر به اشتراک‌گذاری منابع با رقبای شرکت در بهره‌برداری متقابل برای اخذ اطلاعات شود. علاوه‌براین، اگر مشتری توسط دادگاه برای رسیدگی به پرونده داده‌ها ولاگ‌ها در چند مستاجره احضار شود ممکن است داده‌هایی از اتصال به ماشین‌های مجازی در یک سرور فیزیکی به دست آید. علاوه‌براین، چند مستاجری همراه با مجازی‌سازی باعث می‌شود تا پیاده‌سازی ابزار ردیابی برای اعمال سایبری پزشکی قانونی در محیط ابر دشوار شود که ممکن است منجر به عدم تطابق با مقررات گردد.
پذیرش این فن‌آوری در 10 سال اخیر بسیار مهم بوده و افزایش قابل توجهی داشته است و منجر به چالش‌های مهمی در زیرساخت‍‌های IT شده است. بااین‌حال، ابرها به طور قابل توجهی بنا به پتانسیل موجود در آنها به چالش کشیده می‌شوند. علاوه‌بر‌این، ماهیت چالش مصرف ابر با احترام به حریم خصوصی و قابلیت بازبینی قابل تصحیح است. قوانین نظارتی جدیدی که نیاز به حفظ اسناد برای مدت طولانی دارند، فشار زیادی برای ذخیره‌سازی بیشتر و مقرون به صرفه مطابق با مقررات ابر ایجاد می‌کند؛ اما اگر کنترلی بر منابع ذخیره‌سازی صورت نگیرد خطرات دیگری افزایش می‌یابند.

اتوماسیون و استانداردسازی
محاسبات ابری ویژگی‌های خود را با خودکارسازی بسیاری از فرآیندهای IT مانند تأمین و استقرار ماشین‌های مجازی جدید، مدیریت، پشتیبان‌گیری، تعادل بار، نظارت بر امنیت و فرآیندهای دیگر انجام می‌دهند. مدیران محیط ابر، هزاران سرور از طریق داشبورد ابر و استقرار فرآیندها با “push of a button”(به‌عنوان مثال، به راحتی) انجام می‌دهند. اما اگر یک اشتباه در اسکریپت اتوماسیون ساخته شده رخ دهد، مانند یک خطا، می‌تواند بسیار به سرعت تکرار شود. استانداردسازی دربردارنده‌ی خطر مرتبط با به حداقل رساندن تعداد انواع ماشین‌های مجازی موجود در ابر است. استانداردسازی کمک می‌کند تا محیط همگن ایجاد شود، اما در زمان یکسانی، می‌تواند موجب کاهش گسترش ویروس‌ها و یا نرم‌افزارهای مخرب در ابرها گردد.
یک سرمایه‌گذاری عظیم در اتوماسیون منجر به یکی از مزایای ابر می‌شود و ارائه‌دهندگان ابر از اتوماسیون برای به‌دست آوردن مقیاس اقتصادی، مدیریت تعداد زیادی از ماشین‌ها استفاده می‌کنند. اتوماسیون هزینه پایینی را به ارمغان می‌آورد زیرا توانایی به کارگیری تعداد زیادی از سرورها را به‌صورت همزمان دارد – بیشتر کارشناسان ادعا می‌کنند که 10000 سرور برای هر مدیر در محیط‌های IT از جمله گوگل و آمازون وجود دارد. در ابرهای خصوصی با ظرفیت کمتر، تعداد در محدوده‌ای بین 60 تا 100 سرور برای هر مدیر است. همانطور که گفته شد، اتوماسیون موجب افزایش انعطاف‌پذیری با حداقل تلاش ممکن می‌شود. علاوه‌براین، تقسیم کار موثر در روند ایجاد و حفظ فرآیندهای اتوماسیون نقش بسزایی دارد، چرا که دانش نیاز به اشتراک‌گذاری بین مدیران ندارد.
این مزایا بسیار قانع‌کننده هستند، اما این قدرت نیز یک ضعف به حساب می‌آید. همانطور که گفته شد، اتوماسیون می‌تواند بازده زیادی ارائه کند، اما یک اشتباه در یک اسکریپت می‌تواند به سرعت گسترش یابد و با عواقب فاجعه‌باری همراه گردد. حوادث ناخواسته، مانند طوفان معکوس آمازون، توسط اتوماسیون تشدید می‌یابد، بنابراین منطقی است که انتظار طوفان‌های ابر بیشتری را در آینده داشته باشیم. از آنجا که بخش بزرگی از اتوماسیون ابر، کنترل کاربر ابر است، استراتژی خاصی برای این مورد وجود ندارد. به‌طورکلی، اتوماسیون یک بردار خطرناک‌تر از hypervisor و چندمستاجری است.
استانداردسازی جنبه دیگری نیز دارد که می‌تواند نقاط ضعف و مزایایی داشته باشد. مثلا، اگر یک سرور بدون استانداردسازی مجازی شود، نتیجه آن پیچیدگی بیشتر خواهد بود که در حال حاضر وجود دارد. فرایند استانداردسازی وجود دارد که موجب کاهش تنظیمات و ایجاد یک تعداد محدودی از تنظیمات IT قابل استفاده‌ی مجدد می‌شود و می‌تواند تنها با چند کلیک ماوس خودکار شود [18-20]. این همکاری بین استانداردسازی و اتوماسیون توسط Bittman به هنگام بحث در مورد طراحی برای مجازی‌سازی بهتر اعلام شد [20]، و افراد دیگری مانند Oberle و Fisher [18] به عدم وجود استانداردسازی به‌عنوان یکی از موانع اصلی برای تصویب ابر اذعان کردند. بااین‌حال، این مورد درکار Ring و همکارانش بود [19]. در چارچوب مورد آزمایش انها برای محیط‌های ابر قدرت استانداردسازی برای ایجاد تنظیمات ساده‌تر که بسیار آسان خودکار می‌شوند به وضوح نشان داده شده است. ازسوی دیگر، استاندارد تنوع محیط IT را به حداقل می‌رساند، در نتیجه موجب گسترش ویروس‌ها و نرم‌افزارهای مخرب در سراسر محیط ابر می‌شود. مشابه جهان زیستی، تنوع می‌تواند در برابر ویروس محافظت شود زیرا چالش‌های بیشماری وجود دارد که نیاز به پیچیدگی و کدهای بیشتری برای حمله کردن به از آن تنظیمات به جای فقط چند استاندارد VMS دارند. این یکی از دلایلی است که چرا هوشیاری و دقت در تعمیر و نگهداری نرم‌افزار با استفاده از آخرین نرم‌افزارها به ویژه در محیط‌های ابری مهم است.

احراز هویت و اعتبارسنجی
عامل خطر احراز هویت و اعتبارسنجی در ارتباط با چالش رو در رو با تعداد زیادی از کاربران و اشیاء داده است. احراز هویت سنتی و مدیریت دسترسی (IAM) فن‌آوری است که شناسه‌ها و ACL ها (لیست کنترل دسترسی) را برای 10،000 کاربر و همچنین به خوبی حفاظت از چند میلیون اشیاء مدیریت می‌کند که به سادگی در ابری با مقیاس 200 میلیون کاربر و 100 میلیارد فایل کار نمی‌کند. IAM بر روی یک مدل متمرکز که در محیط توزیع‌شده نیست مانند ابر پیش‌بینی می‌کند. سرعت دسترسی بنا به درخواستهای ابر بسیار سریع‌تر تغییر می‌کند و باعث ایجاد چالش‌های جدید و خطرات می‌شود. چندین سیستم مدیریت هویت و کنترل خدمات احراز هویت از راه دور ایجاد شده است، اما هنوز هیچ شرکتی درجه استانداردی تعریف نکرده است. احراز هویت هنوز مسئله‌ای بسیار مهم است چرا که احراز هویت کاربران نیاز به عبور امن از لایه‌های ابر دارد. از سوی دیگر، فن‌آوری‌های جدید مانند OAuth تأیید (استاندارد باز برای احراز هویت) قادر به کاهش برخی از این خطرات هستند. استانداردهای باز جدید مانند OAuth اجازه می‌دهند تا کاربران توکن‌ها را به جای اعتبار به لایه‌هایی از سرویس‌های ابری برسانند و خطر سرقت هویت و یا جعل هویت به حداقل برسد. با این حال، این فن‌آوری‌ها هنوز هم در مراحل اولیه هستند و همه ارائه‌دهندگان و خدمات ابر به صورت همزمان ار آنها پشتیبانی نمی‌کنند. مثلا، برنامه گوگل موتور ** از OAuth پشتیبانی می‌کند [21]، اما احراز هویت تنها با توجه به حساب‌های خدمات گوگل انجام می‌گیرد، ایجاد خطر تکثیر هویت بین محیط LDAP (دسترسی به دایرکتوری سبک پروتکل) و خدمات گوگل انجام می‌گیرد. علاوه براین، برای پیکربندی یک نرم‌افزار وب گوگل یکی از نیازها ایجاد چند XML (زبان نشانه‌گذاری) فایل‌های web.xml یا YAML (زبان نشانه‌گذاری app.yaml) برای تعریف نرم‌افزار و دسترسی به امتیازات آن می‌باشد. این نوع متدولوژی بسیار درشت دانه است و از سایر موارد مورد نیاز کسب وکار مانند مجوز پشتیبانی نمی‌کند. مثال دیگر ارائه شده توسط کارشناسان مایکروسافت Azure ** است که از SAML (زبان نشانه‌گذاری امن) و STS (سرویس توکن امنیت) برای حمایت از راه‌حل مدیریت توزیع هویت پشتیبانی می‌کند. پروتکل SAML از روش‌های احراز هویت SSO و به‌حداقل رساندن تقلید هویت بین مشتری و ارائه دهنده ابر پشتیبانی می‌کند [22]. عدم وجود استانداردسازی ابر با توجه به روش‌های تأیید هویت و مجوز موجب گسترش غیرسازگار راه‌حل‌های اختصاصی شده است که خطرات امنیتی قابل توجهی تولید می‌کنند.

نقطه‌ی پایانی
ظهور دستگاه‌های تلفن‌همراه فشار قابل توجهی بر کسب‌وکار و پشتیبانی از رابط گرافیکی با دستگاه جدید ایجاد کرده‌اند. دستگاه‌های جدید موبایل مانند تلفن‌های همراه و تبلت‌ها بخشی از ابر تلفن‌همراه هستند و چابکی عظیمی برای کارکنان ارائه کرده‌اند. در زمان یکسانی، این فن‌آوری آسیب‌پذیری زیادی به راه‌حل‌های ابر وارد کرد. به‌عنوان مثال، ارائه‌دهندگان خدمات بهداشتی تحت فشار زیادی برای حمایت از برنامه‌های کاربردی اپل برای بررسی سوابق پزشکی در هر زمان و هر مکانی هستند. این مسئله یک چالش بزرگ است چرا که بسیاری از دستگاه‌های تلفن‌همراه مطابق با حداقل استانداردهای امنیتی نیستند و نرم‌افزارهایی که آنها استفاده می‌کنند در چرخه حیات قرار دارند [23].

تمرکز بر مقادیر
با ظهور مراکز داده mega IT ایجاد شده توسط IBM، گوگل، مایکروسافت، آمازون، یاهو، و بسیاری دیگر، این انبار عظیم شامل ده‌ها هزار سرور است که خطرات و چالش‌های جدید بسیاری ایجاد می‌کند. مقدار زیاد و تراکم سخت‌افزار می‌تواند به‌صورت آماری ذخیره‌سازی و یا خرابی روزمره سرور در ابر را تضمین کند [24، 25]. همچنین، مراکز داده بزرگ تهدیدی جدی برای این مسئله به شمار می‌آیند. تمرکز بر مقادیر موجب تغییر در هر زمان نمی‌شود، زیرا تغییر در مراکز بزرگ داده‌ها با کاهش بودجه و بازده انرژی همراه است. بیشترین مقادیر در ابر متمرکز است و اهداف خدماتی ابر بزرگتر خواهد شد. علاوه‌براین، انتظار و تقاضا برای دردسترس بودن داده‌ها در همه جا یک چالش بزرگ ایجاد کرده است که گاهی برخلاف انسجام داده‌ها است. پایگاه‌های داده‌های توزیع‌شده جدید، نه ب اساس SQL (زبان پرس‌وجو ساختارمند)، در هزینه پایین دسترسی در ابر محبوب هستند. پایگاه داده‌های سنتی رابطه‌ای SQL با دقت و مطابق با ACID قوانین (اتمیک بودن، ثبات، انزوا، دوام) تنظیم شده‌اند، اما آنها دسترس پایین‌تری در داده به‌دلیل مکانیسم commit دو مرحله‌ای دارند. با حجم انبوه از داده‌ها، به‌طورخاص بالاتر از 10 پتابایت، هزینه مرتبط با حمل و پشتیبان‌گیری از داده‌ها به‌صورت نمایی رشد می‌کند. فن‌آوری‌های جدید مانند هادوپ **، NoSQL، Cassandra **، و IBM سیستم فایل موازی عمومی (GPFS *) برای کمک به رسیدگی این نوع داده در ابرها ایجاد شده‌اند. بااین‌حال، این نوع از ابزار گاهی اوقات دسترسی را به جای دقت بهینه‌سازی می‌کند بنابراین این مورد می‌تواند یکپارچگی و امنیت در مسائل را ایجاد کند. علاوه‌براین، تراکم عظیم داده‌ها در ابرها موجب ایجاد تراک مقادیر می‌شود. حجم انبوهی از داده با چالش تقاضای سیری‌ناپذیر برای دردسترس بودن بدون دقت و صحت داده روبهه‌رو هستند. دردسترس بودن و دقت داده‌ها از الزامات است. به‌عنوان یک پارتیشن از داده‌ها برای افزایش دردسترس بودن، ثبات کاهش می‌یابد و زمانی که پارتیشن‌های داده برای افزایش ثبات کاهش می‌یابد وارونگی اتفاق می‌افتد، اما دردسترس بودن کاهش می‌یابد [26].

عوامل انسانی
متاسفانه، همه کارشناسان معتقدند که مهم‌ترین خطر امنیتی موثر بر ابرها عوامل انسانی است، زیرا بیشتر رفتارهای متقابلانه به دلیل تهدید دورنی است. در برخی موارد خطر دورنی در ابرها از IT سنتی بالاتر است زیرا ویژگی تراکم مقادیر ابرها زیاد است. کارشناسان ما توضیح داده‌اند که چگونه ارائه‌دهندگان ابر تلاش گسترده‌ای برای نصب ابزار نظارت پیچیده در پایانه‌های کنسول و داشبورد مدیر انجام داده‌اند. این ابزار نظارتی ساخته شده توسط مدیران سیستم، برای نظارت بر کارکنان مخرب و یا ناراضی ساخته شده‌اند که ممکن است با سرقت اطلاعات و یا خرابکاری در سیستم در ارتباط باشند. با این حال، این عامل خطر، انتظار ادامه یک مشکل برای آینده قابل پیش‌بینی را به همراه دارد، همانطور که هکر معروف جهان کوین میتنیک می‌گوید [27] ، شکستن فایروال انسانی آسان است. علاوه براین، بیش از 70 درصد مصاحبه‌ی کارشناسان برای این مقاله در مورد خطر حملات مهندسی اجتماعی هشدار می‌دهد.

امنیت ابر و انطباق با چارچوب خطرات
در این بخش، بر خطرهای موثر در امنیت ابرها تمرکز خواهیم داشت. تقاضای پذیرش می‌تواند شامل قوانین و مقررات دولتی، فرآیندهای صنعتی و الزامات کسب و کار خاص باشد. انطباق نظارتی دولت شامل قانون Sarbanes-Oxley در سال 2002 (SOX) است، که به ایجاد استانداردهای جدید حسابرسی برای افزایش شفافیت کسب‌وکار و رفتار اخلاقی کمک می‌کند.