خطاها سخت و برطرف سازی آن ها چالش برانگیز است. از طرفی یک مدل برنامه نویسی واحدی برای برقراری ارتباط در داخل و بین یک سیستم چند هسته ای وجود ندارد. مدل های برنامه نویسی امروزی نیازمند یک برنامه نویس ابر برای نوشتن یک برنامه کاربردی نخی جهت استفاده از منابع درون سیستم می باشند. با وجود همه مطالبی که گفته شد مشکلات برنامه نویسی این سیستم های مقیاس بزرگ، یعنی مدیریت و متعادل کننده بار، به عنوان کاری مشکل و توأم با دلهره اثبات شده است. در گذشته برای حل این مشکلات از راه حل های موقت مثل متعادل کننده های بار سخت افزار استفاده می شد.
گره خوردن کاربران به یک سرویس دهنده خاص
اگرچه در حال حاضر هزینه های مربوط به زیرساخت و راه اندازی ابتدایی سیستم ها کاهش یافته اند و هزینه مربوط به سخت افزار و یا حتی مجوزهای نرم افزاری تا حدود زیادی حذف شده اند، با این حال باید قبول کنیم تمام تلاش و هزینه ای که برای ساخت سیستم پرداخت شده، صرف توسعه سیستمی بر پایه یک سکوی خاص ابری شده است و بنابراین مهاجرت به یک ابر دیگر به معنی دوباره سازی و توسعه مجدد آن نرم افزار خواهد بود. به عنوان مثال برنامه ای که بر روی Amazon EC2 استقرار یافته است به دلیل وابستگی به یک چارچوب ذخیره سازی خاص، به راحتی قابل جابجایی به سکویی دیگر نخواهد بود[18].
وابستگی شدید بین مولفه ها
این مطلب از طریق بیان یک مثال مشابه به خوبی لمس می گردد. فرض کنید قصد خرید یک کامپیوتر شخصی را دارید. دو انتخاب پیش روی شماست، یکی خرید یک کامپیوتر شخصی آماده وابسته به یک مارک خاص به صورت یک جا و دیگری خرید قطعات موردنیاز به صورت جداگانه و در نهایت سر هم بندی سیستم. مزایایی که سر هم بندی نسبت به خرید آماده دارد عبارتند از: گزینه های متعدد و گسترد تری از قطعات، انعطاف پذیری بیشتر در سفارشی محصول و صد البته هزینه کمتر. حال اگر منابع محاسباتی را جایگزین قطعات کامپیوتری کنیم با شرایط دیگری روبرو خواهیم بود. در اینجا با حداقل انعطاف پذیری روبرو هستیم. بنابراین اگر مشتری قصد استفاده از مثلاً سرویس S3 از شرکت آمازون را داشته باشد در اکثر اوقات مجبور است از سایر تکنولوژی ها و سوریس های ارائه شده از همان شرکت مانند EC2 یا Elastic Map Reduce نیز استفاده نماید[19].

فقدان پشتیبانی چند مستاجری110
مفهوم چند مستاجری به معنی پشتیبانی از چندین کلاینت به شکل همزمان از طریق یک نسخه از سیستم و با هدف افزایش بهره وری می باشد[14]. برای به کارگیری این مفهوم سه روش وجود دارد: استفاده از میانجی111 و به اشتراک گذاری. در حال حاضر، ابرهای موجود به طور کامل از چند مستاجری حمایت نمی کنند. بنابراین برای بهره گیری از تمامی پتانسیل چند مستاجری می بایست به مسائل زیر پاسخ مناسبی داده شود.
به اشتراک گذاری منابع: برای کاهش هزینه صرف شده برای سخت افزار، نرم افزار و مدیریت منابع به ازای هر مستاجر.
جداسازی به دلایل امنیتی: برای پیشگیری از دسترسی غیرمجاز، تضادها و مداخلات میان مستاجرین مختلف.
سفارشی سازی: برای پشتیبانی از رابط کاربری، فرآیندها، داده ها و غیره که مختص هر مستاجر باشد.
فقدان پشتیبانی از SLA112
در ابتدا توضیحاتی راجع به SLA ارائه نموده و در مورد فقدان آن بیشتر بحث می کنیم.
تعریف توصیف SLA
به عنوان یک قرارداد بین مشتری و تامین کننده سرویس، توصیف SLA در زبان توصیف، نیازمندی های QoS تامین شده مشروط بر مشتری سرویس را توصیف می کند. یک SLA شامل یک مجموعه SLO113 هاست که محدودیت ها را بر روی پارامترهای QoS اعمال می کند و در واقع ترکیبی از یک یا چند معیار سنجش کیفیت هستند. در مدیریت SLA، از توصیف یک SLA به منظور تطبیق محدودیت های QoS با سایر SLAها که QoS تامین شده به وسیله تامین کنندگان سرویس را توصیف می کند، استفاده می شود.
از آن جا که یک پارامتر QoS باید قابل سنجش باشد، توصیف SLA اجازه بیان کردن توصیف، برای محدودیت های QoS شان را به مشتریان می دهد، برای مشتریان سرویس محتمل تر است که علاقه به کیفیت محتوای ویژگی های QoS داشته باشند تا کمیت. مستندات نگاشت به منظور مربوط کردن توصیف کیفی برای دلال ترکیب استفاده می شود. مثال زیر مستند نگاشت برای پارامترهای QoS فراخوانی قابلیت در دسترس بودن را نشان می دهد. 100-95
95-85
85-0
با این مستند نگاشت، مشتریان سرویس محدودیت QoS را با توصیف کیفی در SLO بیان می کنند. به عنوان مثال یک SLO از توصیف SLA را در نظر بگیریم که شامل دو پارامتر QoS می باشد:
سرویس قابلیت در دسترس پذیری: این سرویس با توصیف کیفی توصیف می شود.
سرویس زمان پاسخ: این سرویس با مقدار کمی تعریف می شود.
مستند SLO به طور مثال در زیر بیان شده است:
0-50

توصیف SLA، قابلیت کشف سرویس های وب و تعامل QoS بین تقاضای کاربر و سرویس های وب را تامین می کند. کاربر سرویس ترکیبی، می تواند چندید SLO را با ترتیبی از اولویت ها در یک درخواست سرویس اعمال کند طوری که SLO با اولویت کمتر در زمانی که سرویس وب، محدودیتی با اولویت بالای SLO را نقض کند، به کار می رود. سرویس ترکیبی می تواند از سرویس وب کنونی با یک SLA با اولویت کمتر هنگامی که نقض SLA بالا رخ دهد، استفاده می کند.
فقدان SLA در ابرهای موجود
در حال حاضر SLA یک مانع بزرگ بر سر راه گسترش محاسبات ابری می باشد. سرویس های زیرساختی مانند EC2 آمازون هنوز قادر نیستند تا SLA مورد نیاز کمپانی هایی که قصد استفاده از محاسبات ابری را در حرفه خود به صورت جدی دارند را امضا کنند. به علاوه عموماً حرفه ماهیتی پویا دارد و قطعاً یک SLA ایستا قادر به پاسخگویی به تغییرات حرفه نخواهد بود در حالیکه این یکی از قول هایی است که راجع به محاسبات ابری داده شده است.
فقدان انعطاف پذیری لازم در واسط کاربری
رابط کاربری یکی از مهمترین قسمت های یک سیستم می باشد و تجربیات کاربر از کار با آن به عنوان یک فاکتور مهم ارزیابی سیستم تجاری مطرح می باشد. در این شرایط کاربران در حوزه محاسبات ابری یا SaaS با محدودیت فراوانی در انتخاب رابط کاربری روبرو هستند.

بعد از اینکه با چالش های موجود در سیستم عامل های ابری آشنا شدیم، سعی می کنیم به ارائه راهکارهایی در این زمینه بپردازیم.
ارائه راهکارها
در این قسمت تلاش شده است راهکارهایی برای مهمترین چالش سیستم عامل های ابری یعنی مقیاس پذیری ارائه شود و در فصل چهارم این راهکارها ارزیابی خواهند شد.
در بحث مقیاس پذیری بهتر است از مقیاس پذیری افقی به جای عمودی استفاده شود. همان طوری که قبلا در همین فصل به آن اشاره شد، مقياس پذيري به دو صورت عمودي و افقي امکان پذير است.
مقياس پذيري عمودي:
افزايش يا کاهش منابع يک سرور را مقياس پذيري عمودي مي گوييم. به عنوان مثال دو يا چند برابر کردن تعداد پردازنده ها، حافظه اصلي و غیره.
مقياس پذيري افقي:
افزايش تعداد ماشين هاي مجازي و تقسيم بار بين آنها را مقياس پذيري افقي مي گوييم. لازم است نرم افزار مشتري با توجه به اين تکنولوژي طراحي و پياده شده باشد.
یعنی به جای اینکه تعداد پردازنده ها یا حافظه اصلی را افزایش دهیم تعداد ماشین های مجازی را افزایش دهیم. که در فصل بعد نشان می دهیم چرا باید این کار صورت پذیرد.
از طرفی می دانیم که سیستم های محاسبات ابری بر پایه اینترنت می باشند و مزیتی که این سیستم ها دارند این است که ما، منابع و سخت افزارهای خود را از شرکت توسعه دهنده آن اجاره می کنیم و سپس در هر کجای دنیا که باشیم کافی است به یک کامپیوتر معمولی و اینترنت دست یابیم تا به منابع و سخت افزارهایی که اجاره کرده ایم دسترسی داشته باشیم، مثل اینکه مقابل کامپیوتر خود در منزل نشسته ایم.
علاوه بر این چون منابع ما در یک مکانی نگهداری می شود با یک تبلت و اینترنت همراه می توانیم به راحتی به منابع خود دسترسی داشته باشیم، حتی زمانی که در یک اتومبیل در حال حرکت نشسته ایم. اما چالشی که در این جا مطرح می شود این است که مکان ما مرتباً در حال تغییر است و این کار شیوه مسیریابی را مشکل می کند. در زمینه شیوه مسیریابی نیز مقیاس پذیری و کاهش سربار داده ناشی از ارسال اطلاعات موقعیت گره ها در شبکه از جمله چالش های موجود در سرویس های موقعیتی می باشد. برای حل این مشکل روشی به نام 114RNP پیشنهاد می شود. این روش می تواند باعث افزایش کارایی، مقیاس پذیری و کاهش سربار به هنگام وسعت گرفتن شبکه و بالا رفتن چگالی گره ها شود.
در روش RNP اگر محیط را به 9 ناحیه تقسیم بندی کنیم، با تغییر موقعیت گره از یک مکان به مکان دیگر اطلاعات از سرور قبلی حذف شده و به سرور نزدیکتر منتقل می شود و سرور جدید اطلاعات موقعیت گره را به سرور اصلی ارسال می کند، با این کار موقعیت گره بروزرسانی می شود. این عمل را می توانید در شکل 3-1 مشاهده نمایید.

شکل3-1: بروز رسانی موقعیت گره
حال اگر در این روش گره A بخواهد بسته ای را ارسال کند ابتدا اطلاعات مکان خود را همانطوری که قبلا گفته شد به نزدیکترین سرور ارسال می کند و سپس بسته را از همان سرور به سرور اصلی ارسال کرده و در نهایت از سرور اصلی به مقصد ارسال می شود. این عمل را می توانید در شکل 3-2 مشاهده نمایید.

شکل3-2: درخواست موقعیت و ارسال بسته
در این فصل سعی می شود شبه کدهای نوشته شده برای این روش ذکر شود و در فصل بعد نیز این کد را در یک نرم افزار شبیه ساز شبکه پیاده سازی کرده و نتایج را مشاهده کنیم. شبه کدهای مربوط به بروز رسانی موقعیت گره ودرخواست موقعیت را در شکل های 3-3 و 3-4 مشاهده می کنید.

شکل 3-3 : شبه کد به روز رسانی موقعیت گره

شکل 3-4 : شبه کد درخواست موقعیت

فصل چهارم

محاسبات و یافته های تحقیق

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

شکل 4-1 : مقایسه سرعت اجرای برنامه با افزایش تعداد پردازنده
اکنون سرعت اجرای برنامه را با افزایش تعداد ماشین های مجازی در شکل 4-2 مشاهده می کنید. در این قسمت از ماشین های مجازی که دارای پردازنده های چهار هسته ای می باشند استفاده شده است.

شکل 4-2 : مقایسه سرعت اجرای برنامه با افزایش تعداد ماشین مجازی
همان گونه که مشاهده می کنید نسبت افزایش تعداد ماشین های مجازی به سرعت اجرای برنامه به مراتب بهینه تر از نسبت افزایش تعداد پردازنده ها به سرعت اجرای برنامه می باشد.
برای این که باز هم نشان دهیم که چرا مقیاس پذیری افقی از کارایی بیشتری نسبت به مقیاس پذیری عمودی برخوردار است، سعی می کنیم با اجاره بهائی که شرکت گوگل برای در اختیار قرار دادن منابع خود( به خصوص ماشین های مجازی و پردازنده ها) از کاربران دریافت می کند این مقیاس پذیری را مورد بررسی

دسته بندی : No category

دیدگاهتان را بنویسید