دانلود رایگان ترجمه مقاله انتقال VM زنده مبتنی بر حافظه مشترک (آی تریپل ای ۲۰۱۶)

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

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

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

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

۱٫ حجم کاری در حالت بیکاری سیستم عامل: در یک سیستم عامل بیکار، صفحات حافظه خراب تولید شده، دارای کمترین زمان تولید در طول مهاجرت VM بدون اجرای هیچ گونه حجم کار سنگینی اند. تغییرات حافظه در صورت بیکار بودن سیستم عامل به منظور ارزیابی مدل مهاجرت زنده VM DSM استفاده می شود.
۲٫ حجم کار فشرده CPU: کامپایل کردن کد منبع (VM لینوکس) و نصب و راه اندازی Cygwin (VM ویندوز) یک بار CPU سنگین بوده و در این موارد از حجم کار، زمان کامپایل در CPU بالاتر از دیگر وظایف پردازنده است.
۳٫ حجم کار فشرده حافظه: حجم کار فشرده حافظه با اجرای ویدئو در طول روند مهاجرت زنده برای هر دو نوع سیستم عامل، ویندوز و لینوکس ایجاد میشود، علاوه بر بار خواندن دیسک فشرده برای ویدئو از هارد دیسک.
۴٫ حجم کار فشرده شبکه: برای وظیفه شبکه ، هر اتصال مشتری به وب سرور باید حفظ شود تا زمانی که مشتری به آن اتصال خاتمه دهد. داده های منتقل شده در وب عمدتا دارای یک حالت شبکه بزرگتر برای حفظ اتصال مشتریان به وب سرور هستند که باعث افزایش ردپای حافظه با ویژگی لوکالیتی بالاتر میشود.
همانگونه که در شکل ۴ الف نشان داده شده، مجموع زمان مهاجرت در تمام حجم کار کاهش یافته است. اما بهترین حالت آن با نصب Cygwin و حجم کار در حالت بیکار بوده که به ترتیب در حدود ۲۵٪ و ۲۰٪ افزایش است، در حالی که این افزایش در حجم کاری وب و ویدئو در حدود ۶٪ و ۸٪ بود. شکل ۴ ج مجموع زمان مهاجرت را در VM لینوکس به تصویر می کشد. با DSM تمامی حجم کار کم بوده و بهترین نرخ در حالت بیکار بودن VM با ۱۶٫۶٪ افزایش یافته است که مجموع زمان مهاجرت را کاهش داده است. از آنجا که ردپای حافظه لینوکس کمتر از ویندوز است، به روز رسانی صفحات خراب با لوکالیتی بالا در لینوکس کمتر از ویندوز می باشد. این باعث می شود تا DSM با ویندوز بهتر عمل کند.
در شکل ۴ ب و ۴ د، زمان خرابی بدست آمده برای ویندوز و لینوکس با DSM ، با یک کاهش عالی در تمام موارد حجم کار مواجه شد است. در حدود ۴۲٫۸٪ کاهش زمان خرابی در حجم کاری وب برای هر دو سیستم عامل ویندوز و لینوکس بدست آمده است. در بازی های ویدئویی ویندوز هیچ افزایشی صورت نگرفته چرا که GPU همراه بار حافظه و چینش تصاویر ویدئویی کار میکند. اما در لینوکس به ۱۰٪ افزایش میرسیم زیرا در لینوکس ویدئوها در یک راه هموار stream نمیشوند. DSM زمان خرابی را با کاهش تعداد صفحات معیوب پس از حالت تعلیق و ادامه کاهش میدهد. پردازنده های موردهدف می توانند تمام صفحات حافظه را به طور مستقیم مشاهده کنند.
شکل های ۵ تا ۱۲ شبکه و عملکرد پردازنده VM را در طول مهاجرت زنده VM نشان می دهند. بازه زمانی به عنوان شکاف زمانی ثابت برای نشان دادن زمان شروع مهاجرت زنده VM ، زمان خرابی و زمان مهاجرت کل نرمالسازی شده است. به وضوح میتوان رابطه بین عملکرد پردازنده های VM و فعالیت ترافیکی را مشاهده کرد. در تمام موارد، ترافیک شبکه به یک پهنای باند ثابت ۱۲Mbps برای محافظت از شبکه محدود شده و در طول دوره خرابی میزان ترافیک برای کاهش خرابی افزایش می یابد.