آیا Failed شدن درخواست ایجاد VM به دلیل نبود منابع کافی در تمامی مراکز داده، نقض SLA محسوب میشود یا نه؟

Question

آیا رد شدن درخواست ایجاد ماشین مجازی به دلیل نبود منابع مورد نیاز آن ماشین در تمامی مراکز داده و در نهایت دور انداختن درخواست موجب نقض موافقتنامه سطح سرویس خواهد شد یا نه؟

در کلاد سیم چگونه میتوان میزان نقض توافقنامه سطح سرویس را در این زمینه بدست آورد؟

 

Answer 1

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

Availability
 (در مرکز داده رو در بر می گیره که به معنای مدت زمان دردسترس بودن سرویس خواسته شده است ( و نه توانایی اختصاص منابع به اندازه ی گفته شده مانند مقالات و کارهای پژوهشی

 .شما به لینک زیر مراجعه کنید و مشخصات توافق نامه سطح خدمات آمازون رو بدقت مطالعه کنید.

http://aws.amazon.com/ec2/sla/

 در همین جا اشاره می کنه که آمازون درصد مشخص از 

Uptime

 رو پشتیبانی می کنه که برابر با 100 درصد منهای مدت زمانی که یکی از حوزه های سرویس اون 

Unavailable

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

• “Monthly Uptime Percentage” is calculated by subtracting from 100% the percentage of minutes during the month in which Amazon EC2 or Amazon EBS, as applicable, was in the state of “Region Unavailable.” Monthly Uptime Percentage measurements exclude downtime resulting directly or indirectly from any Amazon EC2 SLA Exclusion (defined below).

• Monthly Uptime Percentage	Service Credit Percentage
  Less than 99.95% but equal to or greater than 99.0%	10%
  Less than 99.0%	30%

 

Comments

آیا بعد از سپری شدن یک مدت زمان انتظار امکان دارد که این درخواست ایجاد ماشین مجازی drop شود یا اینقدر انتظار را تحمل میکند تا بالاخره منابع لازم در مرکز داده آزاد شود و تخصیص صورت گیرد؟

در خیلی از تحقیقات گفته شده یک درخواست وقتی به یک مرکزداده ی انتخابی ارسال میشود اگر مرکز مورد نظر منابع لازم را نداشت درخواست به مرکز دیگر هدایت میشود و در صورتی که کلیه مراکز موجود منابع لازم را نداشته باشند آن درخواست دور انداخته  (drop)میشود.

حالا این دو مطلب را چطور به هم ربط دهیم؟

---

ببینید بحث تحقیقات با شرایط عملی کاملا متفاوت هست. بسیاری از تحقیقات به مسئله ی توافق نامه ی سطح خدمات به شکل تامین منابع توافق شده می پردازند و مسائلی چون نقض توافق رو بر اساس کمبود منابع اختصاص یافته و مانند آن نشان می دهند در حالی که در سرویس های رایانش ابری عملیاتی چنین شرایطی وجود ندارد و لااقل من در مورد سرویس های رایانش ابری تجاری مکانیزم کامل نظارت بر اختصاص منابع و محاسبه ی موارد نقض توافق بر اساس عدم تامین منابع رو ندیدم.
در کارهای تحقیقاتی دید قالب به مسئله ی درخواست ورودی به سرویس رایانش ابری به شکل گرید هست که در اون یک درخواست کار (Job) یا دریافت شده و یا Drop می شه. در حالی که شما چنین شرایطی رو در سرویس های ابر عملیاتی ندارید. در این سرویس ها یک درخواست در صف انتظار قرار می گیرد و منابع مختلف از دیتاسنترهای گوناگون بررسی می شود تا بتوان درخواست مورد نظر را ایجاد کرد و حتی ممکن است منابع از یک فراهم کننده ی ابر عمومی دیگر فراهم بشه. در این صورت درخواست هیچ وقت Drop نشده و میزان نقض توافق نامه ی سطح خدمات در زمینه ی Avaialbility سرویس و  بصورت مدت زمان دردسترس بودن سرویس به کل زمان اجرا نشون داده می شه. یعنی شما با یک دید تجاری می تونید درخواستی که منابع کافی برای ایجاد اون وجود نداره رو در صف قرار بدید تا در یکی از منابع موجود فضای کافی برای ایجاد اون بوجود بیاد و پس از اختصاص منابع مدت زمانی که درخواست در صف بوده رو  نسبت به کل زمان اجرا به عنوان زمان نقض توافق در نظر بگیرید. یا می تونید در صورت نبود منابع کافی برای ایجاد درخواست، درخواست رو رد کرده و یک درصد مشخصی از Credit اون درخواست رو به عنوان جریمه به فراهم کننده سرویس رایانش ابری تحمیل کنید.
در نهایت نوع رفتار بار درخواستی به شما بستگی داره و در هر دو نوع از حالت ممکن (تحقیقاتی، تجاری) مرجع کافی برای پشتیبانی از مکانیزم خود در اختیار دارید و انتخاب هرکدوم بسته به شماست. البته این نظر بنده است. دوستان ممکنه نظر دیگه ای داشته باشند.

---

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

با فرض پاسخ شما، این صف چقدر گنجایش داره ؟ این درخواستها چقدر باید در صف منتظر باشند؟ و ...
اگر این اصل را درنظر بگیریم باید یک صف برای درخواستهای معلق داشته باشیم و با یک اولویت بندی درخواستهای این صف را وارد صف اصلی کنیم و این نیاز به مدیریتی سخت داشته و هزینه بردار خواهد بود.
لذا ما هم مساله را بخاطر درگیر نشدن با این موضوعات بدون اصل صف بندی درنظر میگیریم و با اجرای کارها هم کار نداریم و فقط تمرکز ما برروی جایگذاری vmها در مراکز داده است. لطفا به سوال اینجانب  با این شرایط پاسخ دهید.
البته به نظر بنده تحقیقاتی که بدون در نظر گرفتن شرایط واقعی (عملی) باشد قابل پیاده سازی و اجرا نیست و در نهایت با شکست مواجه میشود.

---

بنده به اجرای کار اشاره ای نکردم و مستقیم به مسئله ی ایجاد VM پرداختم. اوناج هم گفتم و مراجع کافی برای بررسی هم داده شد که در صورت نبود منابع کافی در دیتاسنتر برای پذیرش درخواست زمان طول کشیده تا اختصاص منابع در پروسه ی نقض توافق محسوب می شه. اینکه که می فرمایید برخلاف نظر من در کارهای تحقیقاتی طور دیگری عمل می شه خودم در پاسخم اشاره کرده بودم لطفا به متن بالا دوباره مراجعه کنید. اصولا بیشتر کارهای تحقیقاتی و پژوهشی کاملا  متفاوت از کار عملی انجام می شه. برای نمونه مدل های محاسبه ی نقض توافق نامه ی خدمات که در مقالات متعدد کار شده مثل کارهای Buyya و Beloglazov
Optimal Online Deterministic Algorithms and Adaptive Heuristics
for Energy and Performance Efficient Dynamic Consolidation of
Virtual Machines in Cloud Data Centers
.در این کار"مدت زمانی که  وضعیت Utilization=100% است در هاست نسبت به کل زمان فعال بودن هاست" به عنوان معیاری  نقض توافق  به حساب می آد. که دراین  مقاله  با نام SLATAH معرفی شده. شما تقریبا هیچ کدوم از  این  مدل های محاسبه ی نقض توافق نامه ی سطح خدمات رو در سرویس های رایانش ابری تجاری نمی بینید. اگر هست خوشحال می شم ببینم.
بنده توافق نامه ی سطح خدمات سرویس رایانش ابری آمازون به عنوان یک نمونه ی تجاری رو هم در اختیار جنابعالی گذاشتم و نشون دادم . حق انتخاب هم در اختیار شما گذاشتم که هر یک از متد های موجود تحقیقاتی و یا تجاری رو انتخاب کنید.
در مورد طول صف ، انتظار در صف به پارامترهایی مثل دردسترس قرار گرفتن منابع کافی در دیتاسنتر، مشکلات فنی در دیتاسنتر و یا ارتباط آن و غیر بستگی داره و هر درخواست سرویس بلافاصله در صف قرار نمی گیره مگر منابع کافی اون در دیتاسنتر وجود نداشته باشه (بدلیل Overload و یا مشکلات فنی)
در مورد مسئله ی Task و VM و تفاوت ها باید به ذات تفاوت در Grid و Cloud اشاره کرد که در ابر شما برای اختصاص Task های خود به ابر به عنوان یک کاربر باید منابع کرایه شده یعنی همون VM ها رو در اختیار داشته باشید بنابراین برای اختصاص Task جهت اجرا شما به VM های برای پذیرش این درخواست ها و اجرای اونها احتیاج دارید. کما اینکه در مدل شبیه سازی CloudSim هم Cloudlet ها تنها قابل اجرا و اختصاص به VM ها هستند. اما اینکه کاربر نهایی باید درگیر VM ها بشه به ساختار سرویس دهی بستگی داره. اگر یک فراهم کننده ی دسته سوم به عنوان میانجی در حال اختصاص منابع برای اجرای Task به کاربر نهایی است و از مکانیزم های چون LoadBalancer ها برای توزیع بار و ایجاد و یا تخریب VM استفاده می کنه در این صورت کاربر نهایی نیازی به درگیر شدن در مسئله ی مدیریت ماشین های محازی رو نداره. اما اگر شما همون میانجی هستید و وظیفه ی مدیریت و توزیع درخواست ها میان ماشین های مجازی رو بر عهده دارید پس شما هم وظیفه ی مدیریت ایجاد و تخریب VM ها رو بر عهده دارید.

---

جناب خوشدل از توضیحات کامل شما تشکر می کنم. قصد جسارت نداشتم و فقط اطلاعات خودم در نتیجه مطالعه مقالات مختلف را بیان کردم. که البته شما هم در پاسخ قبلی اشاره ای به نوع و محتوای تحقیقات صورت گرفته در این زمینه داشتید.
اما وقتی تحقیقات و مقالات مختلف را در این زمینه کنار هم قرار دادم و بررسی کردم متوجه شدم که یه بعضی چیزا با هم جور نیست و دقیقا برام شده مساله انیشتین از طرفی این مساله مثل مساله اون فیل هست و اینکه در یک فضای تاریک  هر فردی برداشت خاصی از موضوع داره و همین هم یک چالش بزرگه.
باز هم ممنون از حوصله ای که بخرج دادید.