همانطور که میدانید ویژگی vMotion یکی از جذابترین ویژگی های محیط مجازی سازی vSphere می باشد که به شما این امکان را میدهد تا یک ماشین را به صورت زنده از یک مبدا به یک مقصد مشخص منتقل نمایید.
شرکت VMware در گذر زمان اقدام به بهینه سازی این ویژگی جذاب کرده است و آخرین قدرت نمایی این ویژگی در نسخه 7 محصول vSphere به صورت کاملا محسوس قابل رویت است. یکی از این تغییرات کاهش میزان افت کارآیی سیستم در زمان انجام فرآیند vMotion است. در این مقاله می خواهیم به بررسی جزئیات این تغییرات بپردازیم.
به صورت کلی می توانید تغییرات ایجاد شده در این ویژگی از زمان تولد تا به امروز را مشاهده نمایید:
یکی از مزیت های محیط vSphere امکان ایجاد ماشین های مجازی با ابعاد بسیار بزرگ از منظر پردازش می باشد. ماشین هایی که با نام Monster شناخته می شوند می توانند تا 256 هسته پردازنده و 6 ترابایت فضای حافظه اصلی را به خود اختصاص دهند. اما بزرگترین چالش در مقابل این ماشین ها فرآیند انتقال این ماشین ها از یک هاست به هاست دیگر به صورت Live می باشد. اختلال در این فرآیند منجر شده است تا کاربران محیط مجازی سازی vSphere اقدام به کوچک کردن ماشین های مجازی خود نمایند. در نسخه 7 این محصول شرکت VMware تلاش کرده است تا بهینه سازی های متعددی را در خصوص کاهش این افت کارآیی انجام دهد که منجر به کاهش Stun Time یا همان زمان Switch-Over شده است.
در فرآیند vMotion یکی از مهمترین عناصر تاثیرگذار، امکان ردیابی تغییرات در حافظه اصلی اختصاص داده شده به ماشین مجازی است. این فرآیند ردیابی در صورت عملکرد صحیح می تواند منجر به کاهش فرآیند افت کارآیی سیستم در حین vMotion شود. اما این فرآیند به چه شکل انجام می شود؟ در تصویر زیر می توانید به صورت کلی عملکرد این فرآیند را مشاهده نمایید:
در توضیح این تصویر باید بدانید که فرآیند vMotion اقدام به نصب یک Page Tracer بر روی تمام vCPU های یک ماشین مجازی می نماید. نتیجه این امر این است که vMotion از فرآیند Overwritten شدن حافظه اصلی توسط vCPU ها مطلع خواهد شد. به این عملکرد به اصطلاح Page Fire گفته می شود. جهت نصب Page Tracer و انجام فرآیند Page Fire تمام vCPU ها به صورت کاملا غیرمحسوس متوقف می شوند. این توقف تنها چند میکروثانیه زمان می برد اما ممکن است منجر به اختلال در سرویس دهی ماشین نماید، در نتیجه بزرگتر کردن ماشین مجازی از منظر منابع پردازشی احتمال بروز این اختلال را افزایش خواهد داد. بعد از توقف تمام vCPU ها، بخش PTE یا Page Table Entries حافظه اصلی به حالت Read Only تغییر وضعیت میدهد و بخش TLB یا همان Translation Lookaside Buffers تخلیه شده تا فرآیند Mapping حافظه مجازی به حافظه اصلی از طریق این جدول رخ ندهد. در این صورت Page Table Walk جهت دسترسی به اطلاعات حافظه اصلی فراخوانده می شود که در این شرایط فرآیند vMotion به صورت کامل نسبت به تغییرات درون حافظه اصلی آگاهی پیدا می کند. به تمام این فرآیند توضیح داده شده در بالا Stop-based Page Trace Install گفته می شود.
اما در نسخه 7 محصول vSphere این فرآیند کمی تغییر کرده است که نتیجه آن از بین رفتن اختلال لحظه ای مرتبط با نصب Page Tracer بر روی vCPU ها می باشد. در این نسخه روشی با عنوان Loose Page Trace Install معرفی شده است. در این روش تمام مراحل توضیح داده شده در بالا پابرجا می باشند اما به جای متوقف کردن تمام vCPU ها، یک vCPU وظیفه ردیابی تغییرات را بر عهده می گیرد و سایر vCPU ها فرآیند طبیعی خود را ادامه می دهند. در تصویر زیر می توانید به صورت کلی این فرآیند را مشاهده نمایید:
همانطور که از تصویر نیز مشخص است، Page Tracer بر روی یک vCPU نصب شده است اما تمام PTE ها به صورت Read Only تغییر وضعیت داده اند. فرآیند تخلیه TLB نیز با توجه به اینکه هر جدول مختص یک vCPU است طی خواهد شد اما این فرآیند تخلیه شدن در بازه زمانی های مختلف انجام می شود تا اثرگذاری مخرب آن به حداقل ممکن برسد.
با در نظر گرفتن این شرایط، می توان گفت فرآیند Page Tracing به عنوان یک فرآیند مخرب بهبود یافته است. اما این تمام تغییرات در ساختار vMotion نسخه 7 نیست. یکی از بهینه سازی های دیگر انجام شده مربوط به بخش تغییر وضعیت حافظه اصلی به حالت Read Only است که در این تغییر سربار کمتری روی سیستم تحمیل می شود. این روند قبل از اعمال تغییر وضعیت به ازای هر 4 کیلوبایت اطلاعات بر روی حافظه اصلی انجام می شد که در نسخه 7 این مقدار به یک گیگابایت افزایش پیدا کرده است که این از سربار VIMM کم خواهد کرد. در این حالت در صورتیکه یک Page Fire رخ دهد، میزان یک گیگابایت PTE به مقدار 2 مگابایت تا 4 کیلوبایت کاهش پیدا میکند. دلیل این امر این است که ماشین مجازی به صورت لحظه ای اقدام به دستیابی به تمام اطلاعات حافظه اصلی خود نمی کند و این امر با یک تناسب مشخص، بین 10 تا 30 درصد می باشد، لذا افزایش روند تغییر وضعیت به حالت Read Only تا سطح 1 گیگابایت می تواند تاثیر بسزایی در عملکرد vMotion بگذارد.
زمانیکه فرآیند vMotion طی می شود تا به مرحله آخر خود برسد، وارد فازی به نام Switch-Over می شویم. این فاز به شرایطی اطلاق می شود که تمام اطلاعات درون حافظه اصلی مربوط به ماشین مجازی در نقطه مبدا به حافظه اصلی در نقطه مقصد منتقل شده و نهایی سازی جابجایی ماشین مجازی آغاز می شود. در این مرحله ماشین مجازی در نقطه مبدا به حالت تعلیق در آمده و در نقطه مقصد فعال می شود. مدت زمان این فرآیند که به آن Stun Time گفته می شود چیزی کمتر از 1 ثانیه می باشد که برای ماشین های مجازی که به عنوان Monster شناخته می شوند می تواند منجر به بروز اختلال شود. علت این امر این است که آخرین تغییرات درون حافظه اصلی قبل از انجام فاز Switch-Over در قالب یه Bitmap به مقصد ارسال می شود.
اندازه این Bitmap به ازای هر 1 گیگابایت حافظه اصلی معادل 32 کیلوبایت است که با این احتساب برای یک ماشین مجازی با 6 ترابایت حافظه اصلی این عدد به 192 مگابایت می رسد که ارسال آن می تواند تا 1 ثانیه نیز زمانبر باشد. به منظور جلوگیری از بروز رخدادهای تخریبی، در نسخه 7 فرآیند فشرده سازی این Bitmap پیاده سازی شده است که منجر شده تا حجم حداکثری Bitmap برای ماشین های مجازی بسیار بزرگ به حداقل ممکن رسیده و فرآیند انتقال در بازه میلی ثانیه انجام شود.
در دیاگرام زیر می توانید تفاوت vMotion در نسخه های 6.7 و 7 را مشاهده نمایید. این دیاگرام براساس سناریویی ایجاد شده است که در آن یک ماشین مجازی با 72 پردازنده و 512 گیگابایت حافظه اصلی و تحت فشار HammerDB به عنوان یک ابزار ایجاد فشار، vMotion شده است.
ببخشید، برای نوشتن دیدگاه باید وارد بشوید
تمام حقوق متعلق به وب سایت آموزش مجازی می باشد
عالی بود. همیشه از این قابلیت (vMotion)استفاده میکردم ولی نمیدونستم به چه صورت داره کاره انجام میده. ممنون