کارایی رایانش ابری (قسمت دوم) - مجازی سازی سیستم عامل

مجازی سازی سیستم عامل، یک سیستم عامل را به نمونه هایی تقسیم می‌کند که مانند سرورهای جداگانه ی guest عمل می‌کنند بطوریکه می‌توانند مستقل از میزبان، مدیریت و راه اندازی مجدد شوند. این کار، نمونه های سرور با کارایی بالا را برای مشتریان ابر و همچنین سرورهای با تراکم بالا را برای اپراتورهای ابر ارائه می دهد. سیستم عامل های guest مجازی سازی شده در شکل زیر، با استفاده از اصطلاحات Solaris Zones نشان داده شده اند.

Global zone در تصویر فوق نشان داده شده است. این به سیستم عامل میزبان اشاره می‌کند که می‌تواند همه guest zones را مشاهده نماید (این مناطق non-global zones نیز نامیده می شود).

این رویکرد از دستورchroot(8) یونیکس سرچشمه می‌گیرد که هر فرآیند را در زیر درختی از سیستم فایل جهانی یونیکس ایزوله می‌کند. در سال 1998، FreeBSD این را بیشتر بعنوان jails FreeBSD توسعه داد و این منجر به ارائه محفظه‌های امنی شد که هرکدام بعنوان سرورهای خود عمل می‌کنند.

در سال 2005، Solaris 10 شامل نسخه‌ای به نام Solaris Zones با کنترل منابع مختلف بود. از طریق OpenSolaris و بعدا SmartOS ناحیه ها (zones) برای محیط عملیاتی ابر عمومی Joyent تولید شد. اخیرا پروژه هایی برای مجازی سازی سیستم عامل لینوکس انجام شده است از جمله LXC Linux Containers وOpen Virtuozzo(OpenVZ) که توسط شرکتparallels پشتیبانی شده و به هسته لینوکس اصلاح شده نیازمند است.

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

 برای برنامه های مهمان که دارای I/O هستند سربار کمی وجود دارد و یا اصلا وجود ندارد زیرا برنامه های مهمان می توانند فراخوانی های سیستمی را مستقیما در هسته میزبان انجام دهند.

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

 یک حافظه پنهان سیستم فایل یکپارچه وجود دارد که توسط میزبان و مهمان ذخیره نشده است.

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

 پردازنده ها، پردازنده های واقعی هستند. لذا مفروضات قفل‌های تطبیقی موتکس، معتبر باقی می‌مانند.

در مقابل معایب زیر نیز وجود دارد:

 هرگونه panic هسته باعث اثرگذاری برروی تمامی سیستمهای مهمان می‌شود.

 مهمانان نمی توانند نسخه های مختلف هسته را اجرا کنند.

برای اجرای نسخه های مختلف هسته و سیستم عامل های مختلف ، به مجازی سازی سخت افزاری نیاز داریم. مجازی سازی سیستم عامل می تواند این نیاز را تا حدی با ارائه رابط های فراخوانی سیستمی متناوب برآورده سازد. نمونه ای از آن Solaris lx Branded Zones بود که یک رابط فراخوانی سیستمی لینوکس و محیط برنامه تحت هسته Solaris ارائه می‌داد.

بخش های زیر ویژگی های مجازی سازی سیستم عامل را شرح می دهد: سربار، کنترل منابع و قابلیت مشاهده. این محتوا بر اساس یک ابر عمومی است که سالها مورد استفاده قرار گرفته است (همچنین احتمالاً بزرگترین ابر مجازی سیستم عامل در سراسر جهان است): اجرای Joyent SmartOS از Zones. این اطلاعات باید به طور کلی برای همه پیاده سازی‌های مجازی سازی سیستم عامل کاربرد داشته باشد، حتی با تفاوت‌های مربوط به پیکربندی و کنترل منابع. Linux lxc Containers می‌تواند از cgroups استفاده کند، که به عنوان نمونه برای موارد مشابه در اینجا توضیح داده شده است.

سربار (Overhead)

درک اینکه چه زمانی نباید انتظار سربار کارایی از مجازی سازی را داشته باشید، در بررسی مشکلات و مسائل مربوط به کارایی ابر مهم است. این سربار کارایی را می توان با توصیف سربار برای اجرای CPU، سربار برای انجام I/O و اثرات سایر مستاجران خلاصه کرد.

سربار CPU

سربار اجرای پردازنده درحالی که یک نخ (thread) در حالت کاربر در حال اجراست، صفر است. نخ های همزمان یا شبیه سازی شده مورد نیاز نیستند، نخ هایی که مستقیما برروی CPU اجرا می شوند و نگه داشته می شوند و یا فراخوانی می شوند.

تا زمانیکه بصورت مکرر فراخوانی نمی‌شوند، به کارایی حساس نیستند. فعالیت‌هایی مانند لیست کردن حالتهای هسته که ممکن است سربار CPU را متحمل شود. این شامل خواندن سیستم فایل /proc با ابزارهای سنجش وضعیت مانند prstat()، top() است که شامل تمامی اطلاعات ورودی فرآیندها می‌شود. کد هسته برای انجام این امر به صورت زیر است:

این کار در سیستم های فعلی اندازه گیری شد و مشخص گردید که به ازای هر 1000 ورودی فرآیند 40 میکرو ثانیه هزینه دارد. برای فعالیت هایی که بندرت ایجاد می شوند هزینه خیلی کمی دارد.

سربار I/O

سربار ورودی/خروجی صفر است، مگر اینکه ویژگی‌های اضافی پیکربندی شده باشد. برای کارکرد اصول مجازی سازی ، هیچ لایه اضافی در پشته نرم افزار لازم نیست. در تصویر زیر مسیر I/O فرآیندهای Unix را با Zones مقایسه می‌کند.

در ادامه دو ردپای پشته هسته (با استفاده از DTrace) برای انتقال بسته های شبکه برای میزبان و مهمان نمایش داده شده است:

اینها یکسان هستند. یک لایه اضافی معمولاً به عنوان فریم های اضافی در پشته ظاهر می شود. جهت دسترسی به سیستم فایل، ممکن است Zones به گونه ای پیکربندی شود که بر روی سیستم فایل های حلقه ای نصب شود، که خود بر روی سیستم فایل های میزبان نصب شده اند. این استراتژی برای مدل مناطق sparse-root استفاده می شود: راهی برای به اشتراک گذاری فایلهای فقط خواندنی (به عنوان مثال /usr/bin) بین zones. اگر از فایل سیستم های loopback استفاده شود، مقدار کمی از سربار CPU برای سیستم فایل ورودی/خروجی ایجاد می شود.

مستاجران دیگر

شواهد حضور مستاجران نشان می دهد که حضور در حال اجرا بودن آنها اثراتی برروی کارایی دارد که مانع افزایش کارایی می‌شود، که به تکنولوژی مجازی سازی مرتبط نمی‌باشد:

 حافظه CPU ممکن است نسبت hit کمتری داشته باشد چراکه سایر مستاجران در حال مصرف و بیرون کردن ورودی هستند.

 اجرای CPU ممکن است برای مدت کوتاهی برای سایر دستگاه‌های مستاجر (به عنوان مثال، ورودی/خروجی شبکه) که روال‌های سرویس وقفه را انجام می دهند، قطع شود.

  • ممکن است در مورد منابع سیستم (همچون دیسک‌ها و رابط‌های شبکه) از سایر مستاجران که از آنها استفاده می‌کنند، اختلاف نظر باشد. آخرین عامل با کنترل منابع مدیریت می‌شود. هرچند برخی از این عوامل در یک محیط سنتی چند کاربره وجود دارد، اما در محاسبات ابری بسیار بیشتر است.

کنترل منابع

در حالیکه زیرساخت مجازی سازی سیستم عامل، امنیت بین همسایگان را کنترل می‌کند، کنترل‌های منابع، کارایی را مدیریت می‌کنند. جدول زیر نواحی کنترل منابع را شرح داده و از پیکربندی ابر عمومی Joyent براساس SmartOS به عنوان نمونه استفاده می‌کند. اینها براساس محدودیت ها و اولویت ها طبقه بندی شده اند که توسط اپراتور یا نرم افزار ابر برای هر مهمان تعیین می‌گردند. محدودیت ها مقدار سقف مصرف منابع هستند. اولویت ها مصرف منابع را برای متعادل سازی استفاده بین همسایگان بر اساس ارزش اهمیت اداره می‌کنند.

CPU

از آنجاییکه یک مهمان مجازی شده با سیستم عامل می‌تواند تمام CPU های فیزیکی روی سیستم را مستقیماً ببیند، گاهی اوقات می توان 100٪ منابع CPU را مصرف کرد. برای سیستم هایی که عمدتا با CPU های بیکار کار می‌کنند، این به سایر مهمانان اجازه می‌دهد که از آن CPU استفاده کنند؛ به ویژه برای سرویس دهی به موج کوتاه تقاضا. Joyent این توانایی را انفجار می‌نامد. این به مشتریان ابری کمک می کند تا تقاضای سنگین کوتاه مدت را بدون تامین بیش از حد پرهزینه مقابله کنند.

سرپوش CPU

Caps می‌تواند برای استفاده از CPU مهمان، محدودیت ایجاد کند و از انفجار آن جلوگیری کند که برحسب درصد کل CPU بیان‌می شود. برخی از مشتریان این را ترجیح می دهند چراکه انتظار کارایی ثابتی را دارند که می تواند برنامه ریزی ظرفیت را ساده کند.

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

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

اشتراک گذاری CPU

اشتراک گذاری را می توان از طریق زمانبندی سهم عادلانه (FSS) برای تقسیم مناسب منابع CPU بین مهمانان استفاده نمود. اشتراک گذاری را می‌توان به طور دلخواه تخصیص داده و برای محاسبه مقدار CPU مهمان مشغول در یک زمان معین با استفاده از فرمول استفاده نمود:

guest CPU=all CPUs x guest shares/total busy shares on system

سیستمی را در نظر بگیرید که 100 سهم دارد و به چند مهمان اختصاص داده شده است. در یک لحظه ، فقط مهمانان A و B منابع CPU را می‌خواهند. مهمان A ده سهم دارد و مهمان B سی سهم. بنابراین مهمان A می تواند از 25٪ از کل منابع CPU روی سیستم استفاده کند: همه CPU ها* 10/(10 + 30).

برای Joyent، به هر مهمان تعدادی سهم برابر با حجم حافظه آن برحسب مگابایت (و بنابراین نسبت به قیمت پرداخت شده) داده می‌شود. سیستم‌هایِ دو برابر اندازه، دو برابر هزینه دارند و بنابراین دو برابر بیشتر از CPU سهام دریافت می‌کنند. این امر باعث می‌شود منابع CPU به طور عادلانه بین افرادی که به آنها نیاز دارند و هزینه آنها را پرداخت کرده‌اند، تقسیم گردد. از سرپوش‌های CPU نیز برای محدود کردن استفاده انفجاری استفاده می‌شود به طوریکه وضعیت از کنترل خارج نشود.