دانلود رایگان ترجمه مقاله محاسبات سبز در ابرهای بزرگ (آی تریپل ای ۲۰۱۱)

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

۲٫ معماری سیستم
شکل ۲ (سمت چپ) معماری واسط ابر را نشان می دهد. مؤلفه های لایه واسط روی تمام دستگاه ها اجرا می شود. منابع ابر در درجه اول توسط نمونه های ماژول مصرف می شوند که به موجب آن قابلیت های یک سایت از یک یا چند ماژول ساخته شده است. واسط، شامل بخشی از منطق خدمات یک سایت (نشان داده‌شده با mi در شکل ۲) یا مدیر سایت (نشان داده‌شده با SMi) است.

هر دستگاه یک مؤلفه مدیر دستگاه که سیاست تخصیص منابع را محاسبه می کند را اجرا می کند، که شامل تصمیم گیری نمونه های ماژول برای اجرا می شود. سیاست تخصیص منابع توسط یک پروتکل (در این مقاله GRMP نامیده می شود) محاسبه می شود که در مؤلفه مدیر منابع اجرا می شود. این مؤلفه تقاضای طرح ریزی شده را برای هر ماژول به‌عنوان ورودی می گیرد که دستگاه اجرا می کند. سیاست تخصیص محاسبه‌شده، به زمان‌بند ماژول برای اجرا و همچنین مدیر سایت برای تصمیم گیری درباره درخواست ارسال، ارسال می شود. مدیر پوشش ، یک الگوریتم توزیع‌شده را اجرا می کند که یک نمودار پوشش از دستگاه در ابر را حفظ می-کند و هر مدیر منبع یک لیست دستگاه ها برای تعامل فراهم می کند.
معماری ما یک مدیر سایت را با هر سایت مرتبط می سازد. هر مدیر سایت، درخواست کاربران به یک سایت خاص را کنترل می کند. این دو مؤلفه مهم دارد: ایجادکننده مشخصات تقاضا و ارسال کننده درخواست. ایجادکننده مشخصات تقاضا، تقاضای منابع از هر ماژول سایت بر اساس آمار درخواست، اهداف کیفیت سرویس و غیره را برآورد می کند. (نمونه هایی از چنین ایجادکننده مشخصات می تواند در [۱۲] و [۱۳] یافت شود). برآورد برای تمامی مدیران دستگاه ها که نمونه هایی از ماژول های متعلق به سایت را اجرا می کنند، ارسال می شود. به‌طور مشابه، ارسال کننده درخواست، درخواست های کاربران را برای پردازش برای نمونه های ماژول های متعلق به سایت ارسال می کند. تصمیم درخواست ارسال، سیاست تخصیص منابع و محدودیت هایی از قبیل وابستگی جلسه را به حساب می آورد. شکل ۲ (سمت راست) مؤلفه های یک مدیر سایت و چگونگی ارتباط با مدیران دستگاه را نشان می دهد.

شکل ۲٫ معماری برای واسط ابر (سمت چپ) و مؤلفه های برای رسیدگی درخواست ها و تخصیص منابع (سمت راست) [۷].
از نقطه نظر مصرف انرژی، ما یک دستگاه که دارای دو حالت فعال و آماده‌به‌کار است را در نظر می گیریم. یک دستگاه فعال تمام لایه های نرم افزار و مؤلفه های نشان داده‌شده در شکل ۲ را اجرا می کند و بنابراین سطح بالایی از انرژی را مصرف می کند، درحالی‌که یک دستگاه آماده‌به‌کار، همه مؤلفه های در شکل ۲ را اجرا نمی-کند و در نتیجه مصرف انرژی آن کم یا ناچیز است. در این کار به خاطر دلایل آورده شده در [۱۴]، ما خودمان را محدود به حالت آماده‌به‌کار می کنیم، با دانستن اینکه استاندارد ACPI سطوح مختلف حالت آماده‌به‌کار را تعریف می کند [۱۵]. حالت آماده‌به‌کار در کار ما، می تواند به‌عنوان حالت ACPI G2 در مشخصات ACPI تحقق یابد. دلیل این است که حالت، فعال سازی یک دستگاه راه دور از طریق یک بسته شبکه را اجازه می دهد. هر دستگاه در ابر، با خدمات مخزن دستگاه نشان داده‌شده در شکل ۳ ثبت می شود و ردیابی حالت انرژی دستگاه را نگه می دارد، به‌عنوان مثال، فعال یا آماده‌به‌کار.

شکل ۳٫ خدمات مخزن دستگاه
مؤلفه مدیر منابع تعیین می کند که آیا یک دستگاه می تواند به حالت آماده‌به‌کار برود یا یک دستگاه اضافی برای فعال شدن نیاز است. در مورد اول، آن یک پیام تعویض به حالت آماده‌به‌کار، به خدمات مخزن دستگاه می فرستد که متعاقباً دستگاه را به حالت آماده‌به‌کار تعویض می کند. در مورد دوم، آن پیام فعال کردن دستگاه را به خدمات می فرستد، که شناسه یک دستگاه فعال را اگر یکی در دسترس باشد، بر می گرداند. در ادامه این مقاله به قابلیت مؤلفه مدیر منابع تمرکز می شود. برای دیگر مؤلفه های معماری ما، مانند مدیر پوشش و ایجادکننده مشخصات تقاضا، ما به راه حل های شناخته شده تکیه می کنیم. یک طراحی برای خدمات مخزن دستگاه، بخشی از کارهای آینده ما است.

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

A. مدل
ما ابر را به‌عنوان یک سیستم با مجموعه ای از سایت ها (S) و مجموعه ای از دستگاه ها (N) که سایت ها را اداره می کنند، مدل می کنیم. هر سایت s∈S از مجموعه ای از ماژول ها که با Ms نشان داده می شود، تشکیل شده است، و مجموعه ای از تمام ماژول های موجود در ابر، M=⋃_(s∈S)▒M_s است.
ما تقاضا پردازنده را با بردار ω(t)=[ω_۱ (t),ω_۲ (t),…,ω_|M| (t)]^T و تقاضا حافظه را با بردار γ=[γ_۱,γ_۲,…,γ_|M| ]^T مدل می کنیم، با این فرض که تقاضا پردازنده وابسته به زمان است، درحالی‌که تقاضا حافظه وابسته به زمان نیست [۱۶].
ما یک سیستم را در نظر می گیریم که ممکن است بیش از یک نمونه از ماژول m که هر یک در دستگاه مختلف است را اداره کند. که در این صورت تقاضا پردازنده آن، در میان نمونه هایش تقسیم می شود. تقاضا ω_(n,m) (t) از یک نمونه m در حال اجرا در دستگاه n با ω_(n,m) (t)=α_(n,m) (t)ω_m (t) نشان داده می شود که در آن ∑_(n∈N)▒〖α_(n,m) (t)=1〗 و α_(n,m) (t)≥۰ است. ما ماتریس A با عناصر α_(n,m) (t) را پیکربندی (ماتریس) سیستم می-نامیم. A یک ماتریس غیر منفی با ۱^T A=1^T است.