تفاوت اصلی VMware vMotion و Storage vMotion در بخشی از زیرساخت است که جابهجا میشود. vMotion ماشین مجازی روشن را از یک هاست ESXi به هاست دیگر منتقل میکند، بدون آنکه در مهاجرت معمول، محل فایلهای دیسک تغییر کند. در مقابل، Storage vMotion فایلها و دیسکهای ماشین مجازی را بین Datastoreها جابهجا میکند و ماشین میتواند روی همان هاست به کار خود ادامه دهد. در این راهنما، نحوه عملکرد، پیشنیازها، محدودیتها و سناریوهای عملی این دو فناوری را بررسی میکنیم تا مشخص شود هر روش چه زمانی برای زیرساخت VMware مناسبتر است.
- انتقال هاست: vMotion برای جابهجایی ماشین مجازی روشن بین هاستهای سازگار استفاده میشود.
- انتقال ذخیرهسازی: Storage vMotion محل فایلهای VM و دیسکهای مجازی را تغییر میدهد.
- ذخیرهسازی مشترک: در vMotion استاندارد از نوع Compute-only، هاست مبدأ و مقصد باید به فایلهای ماشین مجازی دسترسی داشته باشند.
- مهاجرت ترکیبی: در سناریوهای پشتیبانیشده، امکان تغییر همزمان هاست و Datastore وجود دارد.
- تأثیر بر منابع: vMotion عمدتاً به شبکه مهاجرت و حافظه وابسته است؛ Storage vMotion معمولاً بار قابل توجهی روی مسیر ذخیرهسازی ایجاد میکند.
- تداوم سرویس: هر دو برای مهاجرت آنلاین طراحی شدهاند؛ بااینحال، وقفههای بسیار کوتاه یا افت موقت عملکرد در شرایط خاص ممکن است رخ دهد.
مفهوم مهاجرت زنده ماشین مجازی در VMware
در زیرساختهای مجازیسازی سازمانی، نگهداری سرورها، ارتقای سختافزار، توسعه ظرفیت ذخیرهسازی و توزیع بار کاری نباید الزاماً به خاموش کردن ماشینهای مجازی منجر شود. فناوری Live Migration این امکان را فراهم میکند که محل اجرای یک ماشین مجازی یا محل نگهداری دادههای آن در حین فعالیت تغییر کند.
VMware این نیاز را از طریق قابلیتهای مهاجرت در پلتفرم VMware vSphere پوشش میدهد. دو قابلیت اصلی در این زمینه، vMotion و Storage vMotion هستند که هرکدام بخش متفاوتی از عملیات مهاجرت را مدیریت میکنند.
مهاجرت زنده یا Live Migration فرآیندی است که در آن ماشین مجازی روشن، بدون نیاز به خاموشسازی برنامهریزیشده، از یک منبع محاسباتی یا ذخیرهسازی به منبع دیگر منتقل میشود. موفقیت این فرآیند به سازگاری زیرساخت، منابع کافی و شرایط عملیاتی وابسته است.
مزیت اصلی این قابلیتها در مراکز داده، کاهش نیاز به پنجرههای تعمیراتی همراه با قطعی سرویس است. البته مهاجرت زنده جایگزین High Availability، پشتیبانگیری یا Disaster Recovery نیست؛ زیرا این فناوریها مسائل متفاوتی را حل میکنند.
VMware vMotion و Storage vMotion چیستند؟
هر دو فناوری برای جابهجایی ماشینهای مجازی طراحی شدهاند، اما تفاوت اصلی آنها در انتقال منابع محاسباتی در برابر انتقال فایلهای ذخیرهسازی است.
VMware vMotion چیست و چه وظیفهای دارد؟
VMware vMotion فناوری مهاجرت زنده ماشین مجازی بین دو هاست ESXi سازگار است. در این عملیات، وضعیت اجرایی ماشین، شامل محتوای حافظه و وضعیت لازم پردازنده و دستگاههای مجازی، به هاست مقصد منتقل میشود.
در مهاجرت استاندارد از نوع Compute-only، فایلهای ماشین مجازی روی Datastore فعلی باقی میمانند و هاست مقصد پس از انتقال، اجرای ماشین را ادامه میدهد. به همین دلیل، هر دو هاست باید به فایلهای موردنیاز ماشین مجازی دسترسی داشته باشند.
این قابلیت برای تخلیه هاست پیش از تعمیرات، ارتقای Firmware، مدیریت ظرفیت محاسباتی و متعادلسازی بار بین سرورها استفاده میشود.
Storage vMotion چیست و چه کاربردی دارد؟
Storage vMotion قابلیتی برای انتقال آنلاین فایلهای ماشین مجازی از یک Datastore به Datastore دیگر است. این فایلها میتوانند شامل دیسکهای مجازی VMDK، فایلهای پیکربندی و سایر اجزای پشتیبانیشده ماشین باشند.
در مهاجرت Storage-only، هاست اجراکننده VM تغییر نمیکند. در عوض، سیستم دادهها را به مقصد منتقل کرده و تغییرات ایجادشده هنگام عملیات را هماهنگ میکند تا ماشین از فایلهای مقصد استفاده کند.
این قابلیت در زمان جایگزینی Storage قدیمی، انتقال داده به ذخیرهساز جدید، آزادسازی ظرفیت Datastore و تغییر سیاستهای ذخیرهسازی کاربرد دارد.
شباهتهای vMotion و Storage vMotion
پشتیبانی از مهاجرت آنلاین
هر دو قابلیت برای جابهجایی ماشین روشن و حفظ تداوم اجرای Workload طراحی شدهاند.
مدیریت از طریق vCenter
عملیات مهاجرت معمولاً از طریق vSphere Client و ابزارهای مدیریتی vCenter انجام و پایش میشود.
اعتبارسنجی مقصد
پیش از شروع، سازگاری مقصد، تنظیمات و منابع موردنیاز براساس نوع مهاجرت بررسی میشود.
کاهش اختلال در نگهداری
در صورت رعایت پیشنیازها، بسیاری از عملیات تعمیر و توسعه زیرساخت بدون خاموشی برنامهریزیشده VM انجام میشوند.
جدول مقایسه VMware vMotion و Storage vMotion
برای انتخاب روش مناسب، باید هدف مهاجرت، نوع منابع منتقلشده، پیشنیازهای زیرساخت و تأثیر احتمالی بر عملکرد بررسی شوند.
| معیار | VMware vMotion | Storage vMotion |
|---|---|---|
| هدف اصلی | انتقال ماشین روشن بین هاستهای ESXi | انتقال فایلهای VM بین Datastoreها |
| منبع تغییرکننده | Compute Host | Storage / Datastore |
| دادههای اصلی منتقلشده | حافظه و وضعیت اجرایی VM | دیسکها و فایلهای ماشین مجازی |
| تغییر هاست | بله | خیر، در حالت Storage-only |
| تغییر Datastore | خیر، در حالت Compute-only | بله |
| نیاز به Storage مشترک | برای Compute-only، فایلهای VM باید از هر دو هاست قابل دسترسی باشند. | هاست اجراکننده باید به مبدأ و مقصد دسترسی داشته باشد؛ اشتراکگذاری Storage بین دو هاست ضرورت ذاتی ندارد. |
| وابستگی اصلی شبکه | شبکه VMkernel با قابلیت vMotion | مسیرهای انتقال و I/O ذخیرهسازی؛ بسته به معماری SAN، NAS یا سایر روشها |
| سازگاری CPU | بین هاست مبدأ و مقصد اهمیت مستقیم دارد. | در Storage-only، تغییر هاست انجام نمیشود و تطبیق CPU بین دو هاست مطرح نیست. |
| تأثیر بر عملکرد | مصرف شبکه و CPU و حافظه در هنگام انتقال | بار خواندن، نوشتن و کپی داده روی Storage و مسیرهای ارتباطی |
| سرعت انتقال | وابسته به حافظه VM، نرخ تغییر صفحات و شبکه | وابسته به حجم داده، نرخ تغییر دیسک و توان I/O |
| کاربرد متداول | نگهداری هاست و توازن بار پردازشی | ارتقای Storage و مدیریت ظرفیت Datastore |
| اتوماسیون مرتبط | قابل استفاده توسط vSphere DRS در شرایط پشتیبانیشده | قابل استفاده در فرآیندهای Storage DRS، با توجه به نسخه و مجوز |
الزام دسترسی مشترک به فایلهای ماشین مجازی مربوط به مهاجرت استاندارد Compute-only است. اگر هاست مقصد به Datastore مبدأ دسترسی ندارد، در شرایط پشتیبانیشده میتوان از مهاجرت همزمان Compute و Storage یا Shared-Nothing vMotion استفاده کرد. بنابراین، نبود Shared Storage به معنای غیرممکن بودن تمام انواع مهاجرت زنده نیست.
نحوه عملکرد فنی vMotion و Storage vMotion
درک فرآیند انتقال نشان میدهد چرا پیشنیازهای این دو قابلیت متفاوت هستند و کدام بخش زیرساخت هنگام مهاجرت بیشتر درگیر میشود.
انتقال وضعیت CPU و RAM در vMotion
هنگام شروع vMotion، هاست مقصد برای دریافت وضعیت ماشین مجازی آماده میشود. اطلاعات حافظه VM از طریق شبکه مهاجرت منتقل شده و تغییرات جدید صفحات حافظه در چند مرحله با مقصد همگام میشوند.
در مرحله نهایی، ماشین برای یک بازه بسیار کوتاه متوقف میشود تا وضعیت باقیمانده پردازنده، حافظه و دستگاههای مجازی منتقل و اجرای ماشین روی هاست مقصد از سر گرفته شود. این مرحله معمولاً کوتاه است، اما مدت و اثر آن با توجه به Workload و شرایط شبکه متفاوت خواهد بود.
- بررسی سازگاری هاست مقصد و منابع موردنیاز ماشین.
- آمادهسازی ماشین در هاست مقصد.
- انتقال وضعیت حافظه و همگامسازی تغییرات در زمان اجرای VM.
- انتقال نهایی وضعیت اجرایی و تغییر محل اجرا.
- ادامه فعالیت ماشین روی هاست مقصد و تکمیل عملیات مدیریتی.
انتقال فایلهای دیسک در Storage vMotion
در Storage vMotion، سیستم فایلهای موردنیاز ماشین را در Datastore مقصد ایجاد و اطلاعات دیسک را در حین اجرای VM منتقل میکند. از آنجا که ماشین همچنان درخواستهای خواندن و نوشتن تولید میکند، تغییرات باید در طول عملیات هماهنگ شوند.
پس از تکمیل انتقال و هماهنگسازی نهایی، ارجاع ماشین به فایلهای مقصد تغییر میکند. جزئیات مکانیزم کپی و هماهنگسازی بسته به نسخه vSphere، نوع Storage و وضعیت ماشین متفاوت است.
انتقال چند دیسک مجازی یا فایلهای پیکربندی به Datastoreهای متفاوت نیز در سناریوهای پشتیبانیشده امکانپذیر است و میتواند به مدیریت ظرفیت و جداسازی Workloadها کمک کند.
نقش VMkernel و شبکه در مهاجرت
برای vMotion بین دو هاست، رابط VMkernel با سرویس vMotion و ارتباط شبکه سازگار میان میزبانها ضروری است. پهنای باند، تأخیر، ازدحام شبکه و پیکربندی صحیح MTU میتوانند بر زمان و موفقیت انتقال اثر بگذارند.
در مقابل، Storage vMotion لزوماً از همان شبکه اختصاصی vMotion استفاده نمیکند. مسیر انتقال داده به معماری ذخیرهسازی بستگی دارد؛ برای مثال، در محیطهای مبتنی بر Fibre Channel SAN، NFS یا iSCSI، زیرساخت و مسیرهای I/O متفاوت هستند.
فعال کردن Jumbo Frames فقط در یک سوئیچ یا یک هاست کافی نیست. اگر از MTU بزرگتر استفاده میکنید، باید سازگاری آن در تمام مسیر مرتبط بررسی شود. همچنین شبکه vMotion باید از نظر دسترسی و امنیت کنترل شود، زیرا دادههای وضعیت ماشین در این مسیر منتقل میشوند.
مزایا، محدودیتها و تأثیر بر عملکرد سیستم
مزایای vMotion برای مدیریت پردازش
نگهداری بدون خاموشی برنامهریزیشده
امکان انتقال VMهای سازگار پیش از تعمیر یا ارتقای هاست و سپس ورود سرور به Maintenance Mode را فراهم میکند.
توازن بار بین هاستها
جابهجایی Workloadها بین سرورهای دارای ظرفیت متفاوت، استفاده از منابع Compute را انعطافپذیرتر میکند.
تسهیل نوسازی سختافزار
در صورت سازگاری CPU، شبکه و نسخههای نرمافزاری، انتقال ماشینها به هاستهای جدید را سادهتر میکند.
هماهنگی با DRS
در محیطهایی که قابلیتهای لازم فعال هستند، DRS میتواند از مهاجرت برای بهبود توزیع منابع استفاده کند.
مزایای Storage vMotion برای مدیریت داده
Storage vMotion به مدیر زیرساخت اجازه میدهد محل دادههای ماشین را بدون جابهجایی هاست اجراکننده تغییر دهد. این قابلیت برای تعویض Array، ارتقای تجهیزات ذخیرهسازی و مدیریت Datastoreهای پرظرفیت اهمیت دارد.
برای نمونه، اگر Datastore فعلی با محدودیت ظرفیت یا تأخیر I/O مواجه باشد، میتوان یک VM سازگار را به فضای ذخیرهسازی مناسبتری منتقل کرد. البته بهبود عملکرد فقط در صورتی رخ میدهد که Storage مقصد از نظر IOPS، Throughput، Latency و ظرفیت واقعاً پاسخگوی Workload باشد.
پیش از چنین تغییری، بررسی روشهای بهینهسازی کارایی ماشینهای مجازی نیز کمک میکند مشکل ناشی از CPU، RAM، شبکه یا ذخیرهسازی بهدرستی تفکیک شود.
محدودیتها و ریسکهای عملیاتی
| چالش | پیامد احتمالی | اقدام پیشنهادی |
|---|---|---|
| کمبود پهنای باند vMotion | طولانی شدن انتقال و افزایش فشار شبکه | بررسی ظرفیت لینک و زمانبندی مهاجرت |
| بار بالای Storage | افزایش Latency در انتقال دیسک | مانیتورینگ I/O و محدودسازی مهاجرت همزمان |
| ناسازگاری CPU | رد شدن بررسی سازگاری vMotion | بررسی CPU Features و EVC |
| کمبود ظرفیت مقصد | عدم امکان تکمیل Storage Migration | بررسی فضای آزاد، Policy و Provisioning |
| دیسکها یا تجهیزات خاص VM | محدود شدن یا ناممکن شدن مهاجرت زنده | بررسی RDM، Shared Disk، Passthrough و مستندات نسخه |
| مهاجرتهای همزمان زیاد | رقابت بر سر منابع محاسباتی و ذخیرهسازی | تعیین اولویت و کنترل نرخ اجرای عملیات |
نمیتوان زمان ثابت یا نسبت سرعت مشخصی برای این دو فناوری اعلام کرد. vMotion عمدتاً به حجم حافظه و نرخ تغییر آن وابسته است، اما Storage vMotion به مقدار دادهای که باید کپی شود و عملکرد مسیر I/O بستگی دارد. اندازهگیری واقعی در محیط عملیاتی برای برآورد زمان مهاجرت ضروری است.
کاربردهای واقعی vMotion و Storage vMotion در دیتاسنتر
انتخاب روش مهاجرت باید از هدف عملیاتی شروع شود: آیا قرار است هاست تغییر کند، Storage تغییر کند یا هر دو منبع به مقصد جدید منتقل شوند؟
سناریوی اول: تعمیر یا ارتقای هاست ESXi
فرض کنید یک هاست باید برای ارتقای Firmware یا انجام تعمیرات از سرویس خارج شود. اگر هاست مقصد با ماشین مجازی سازگار باشد و فایلهای VM از هر دو هاست قابل دسترسی باشند، Compute-only vMotion روش مناسب است.
در این وضعیت، دیسکهای ماشین روی Datastore باقی میمانند و تنها اجرای آن به هاست دیگری منتقل میشود. پس از تخلیه ماشینها میتوان عملیات نگهداری را انجام داد.
سناریوی دوم: انتقال داده از Storage قدیمی
اگر سازمان قصد جایگزینی SAN یا انتقال VMها به یک Array جدید را داشته باشد، Storage vMotion میتواند فایلها را به Datastore مقصد منتقل کند.
پیش از انتقال باید سازگاری Storage Policy، ظرفیت مؤثر، توان پردازش I/O و ارتباطات مسیر ذخیرهسازی بررسی شود. برای طراحی یا بازبینی این زیرساخت میتوان از خدمات ذخیرهسازی سازمانی آکو استفاده کرد.
سناریوی سوم: انتقال ماشین به کلاستر vSAN
هنگام انتقال یک VM از محیط SAN سنتی به کلاستر vSAN، روش اجرا به دسترسی هاستها به Storage، معماری مقصد و سازگاری منابع بستگی دارد.
در صورت امکان، میتوان ابتدا ماشین را به هاست مقصد منتقل و سپس با Storage vMotion فایلهای آن را به vSAN جابهجا کرد. در سناریوهایی که دسترسی مشترک به Datastore وجود ندارد، مهاجرت ترکیبی Compute و Storage ممکن است انتخاب مناسبتری باشد.
برای شناخت معماری مقصد، مقاله ساخت زیرساخت ذخیرهسازی با VMware vSAN اطلاعات تکمیلی درباره نقش ذخیرهسازی نرمافزارمحور ارائه میکند.
سناریوی چهارم: بهینهسازی بار و ظرفیت دیتاسنتر
زمانی که یک سرور ESXi با مصرف بالای CPU یا RAM مواجه است، vMotion میتواند بار آن را به هاست مناسبتری منتقل کند. اما اگر مسئله اصلی افزایش Latency دیسک یا کمبود فضای Datastore باشد، باید ابتدا Storage بررسی شود.
Storage vMotion در این شرایط ابزار جابهجایی داده است؛ نه تضمینی برای برطرف کردن مشکلات عملکردی. در برخی مواقع، اصلاح پیکربندی VM یا افزایش ظرفیت Storage نسبت به مهاجرت مؤثرتر خواهد بود.
| نیاز سازمان | روش مناسب | دلیل انتخاب |
|---|---|---|
| تخلیه هاست برای Maintenance | vMotion | تغییر محل اجرای VM |
| انتقال VMDK به Datastore جدید | Storage vMotion | تغییر محل فایلهای VM |
| توزیع بار پردازشی | vMotion | تغییر هاست بدون انتقال معمول دیسک |
| تعویض Array ذخیرهسازی | Storage vMotion | انتقال آنلاین داده در شرایط سازگار |
| مهاجرت بین هاستهای فاقد Storage مشترک | Shared-Nothing vMotion | انتقال همزمان Compute و Storage |
| انتقال بین دو vCenter | Cross vCenter vMotion | مهاجرت بین محیطهای مدیریتی با رعایت پیشنیازها |
پیشنیازها و مراحل اجرای موفق مهاجرت
اجرای موفق مهاجرت زنده به بررسی سازگاری منابع، وضعیت ماشین مجازی، شبکه، ذخیرهسازی و مجوزهای نرمافزاری وابسته است.
بررسی نسخه vSphere، مجوز و سازگاری CPU
پیش از مهاجرت بین هاستها، سازگاری نسخههای ESXi، قابلیتهای CPU و Virtual Hardware بررسی شود. فناوری Enhanced vMotion Compatibility یا EVC میتواند با ارائه مجموعهای سازگار از قابلیتهای پردازنده، مهاجرت بین برخی نسلهای متفاوت CPU را تسهیل کند.
بااینحال، EVC تمام ناسازگاریهای پردازنده را رفع نمیکند و جایگزین بررسی سازگاری نیست. بهویژه مهاجرت زنده بین معماریهای متفاوت Intel و AMD از محدودیتهای مهم است.
همچنین دسترسی به قابلیتهای vMotion و Storage vMotion، سطح اتوماسیون و مهاجرت بین vCenterها باید با توجه به نسخه محصول، نوع Subscription و شرایط مجوز بررسی شود. برای شناخت بستر نرمافزاری میتوان محصولات VMware vSphere را بررسی کرد.
بررسی شبکه و مسیرهای ارتباطی
- فعال بودن سرویس vMotion روی رابط VMkernel مناسب در هاستهای شرکتکننده.
- برقراری ارتباط شبکه و دسترسی لازم بین هاستها.
- بررسی پهنای باند، Latency، Packet Loss و ازدحام شبکه.
- اعتبارسنجی MTU در صورت استفاده از Jumbo Frames.
- بررسی Port Group و دسترسی شبکه VM روی هاست مقصد.
- کنترل امنیت و جداسازی منطقی ترافیک مهاجرت.
بررسی Storage و وضعیت ماشین مجازی
برای Storage vMotion، دسترسی به Datastore مبدأ و مقصد، فضای ذخیرهسازی کافی و سازگاری سیاستهای دیسک باید بررسی شود. برخی پیکربندیها مانند Shared VMDK، SCSI Bus Sharing، RDM، دیسکهای با حالت خاص یا دستگاههای متصل به VM ممکن است مهاجرت زنده را محدود کنند.
وضعیت Snapshotها، ماشینهای کلاستری، فایلهای ISO متصلشده و وابستگیهای نرمافزاری نیز باید پیش از اجرا بررسی شود؛ زیرا پشتیبانی از هر حالت میتواند به نسخه و پیکربندی وابسته باشد.
برای VMهای دارای دیسک مشترک، Workloadهای کلاستری یا وابستگیهای خاص سختافزاری، فرض نکنید مهاجرت آنلاین همواره پشتیبانی میشود. در بعضی پیکربندیها، Cold Migration یا فرآیند مهاجرت اختصاصی برنامه ضروری است. پشتیبانگیری معتبر و برنامه بازگشت باید پیش از عملیات پرریسک بررسی شوند.
مراحل اجرای مهاجرت در vSphere Client
- انتخاب ماشین مجازی: در vSphere Client، ماشین موردنظر را پیدا کرده و گزینه Migrate را انتخاب کنید.
- تعیین نوع مهاجرت: براساس هدف عملیات، Change compute resource only، Change storage only یا Change both compute resource and storage را انتخاب کنید.
- انتخاب مقصد: هاست، کلاستر، Datastore یا Storage Policy مناسب را مشخص کنید.
- بررسی سازگاری: پیامهای Compatibility Check را مطالعه و خطاهای احتمالی را برطرف کنید.
- شروع عملیات: پس از بازبینی انتخابها، فرآیند مهاجرت را اجرا کنید.
- مانیتورینگ: وضعیت Task، مصرف منابع، Latency و سلامت Workload را در طول انتقال بررسی کنید.
- اعتبارسنجی نهایی: محل اجرای VM، مسیر دیسکها، ارتباط شبکه و عملکرد سرویس را پس از تکمیل کنترل کنید.
کاهش اثر مهاجرت بر عملکرد
بهتر است ماشینهای پرمصرف بهصورت مرحلهای منتقل شوند و مهاجرت انبوه در بازههای کمبار انجام شود. تعداد عملیات همزمان نیز باید با توجه به محدودیتهای نسخه vSphere، پهنای باند و ظرفیت I/O تنظیم شود.
برای پایش پیشرفته میتوان از ابزارهای مدیریتی و مانیتورینگ اکوسیستم VMware استفاده کرد. ابزارهای عملیاتی به شناسایی گلوگاهها و انتخاب زمان بهتر مهاجرت کمک میکنند، اما صرفاً مانیتورینگ به معنای جلوگیری خودکار از تمام خطاهای مهاجرت نیست.
مهاجرت ترکیبی و انتقال بین کلاسترها و vCenterها
برخی پروژهها به تغییر همزمان منابع Compute و Storage نیاز دارند؛ بهخصوص هنگام انتقال Workload از یک کلاستر به کلاستر دیگر یا نوسازی کامل زیرساخت.
Shared-Nothing vMotion چیست؟
Shared-Nothing vMotion به سناریویی گفته میشود که ماشین مجازی روشن همراه با وضعیت اجرایی و دادههای موردنیاز، به هاست و Storage مقصد منتقل میشود؛ بدون آنکه الزاماً هر دو هاست به یک Datastore مشترک دسترسی داشته باشند.
این روش برای مهاجرت بین کلاسترهای دارای ذخیرهسازی مستقل کاربرد دارد. بااینحال، انتقال همزمان حافظه و دیسک ممکن است منابع بیشتری مصرف کند و باید محدودیتهای شبکه، Storage و سازگاری مقصد بررسی شوند.
Cross vCenter vMotion چه تفاوتی دارد؟
Cross vCenter vMotion برای مهاجرت ماشینهای مجازی بین محیطهایی که توسط vCenter Serverهای متفاوت مدیریت میشوند استفاده میشود. بسته به پیکربندی و روش اجرا، مهاجرت میتواند در مرزهای مدیریتی متفاوت انجام شود.
پیشنیازهای این قابلیت شامل سازگاری نسخهها، دسترسی شبکه، مجوزهای موردنیاز، تنظیمات مدیریتی و شرایط مقصد است. بنابراین، پشتیبانی از Cross vCenter vMotion به معنای امکان مهاجرت مستقیم و بدون محدودیت میان هر دو دیتاسنتر یا سرویس ابری نیست.
نقش DRS، Storage DRS و محیطهای Hybrid Cloud
vSphere DRS با بررسی وضعیت منابع کلاستر میتواند در محیطهای پشتیبانیشده از vMotion برای متعادلسازی بار استفاده کند. Storage DRS نیز برای مدیریت جایگذاری و توازن فضای ذخیرهسازی در Datastore Clusterها کاربرد دارد.
این قابلیتها با مهاجرت بین مراکز داده و معماریهای Hybrid Cloud ارتباط عملیاتی دارند، اما اجرای چنین سناریوهایی علاوه بر vMotion به طراحی شبکه، امنیت، سازگاری نسخهها و گاهی ابزارهای مهاجرت اختصاصی نیاز دارد.
انتخاب خودکار محل اجرای VM و توصیههای مبتنی بر دادههای عملکردی میتوانند به بهینهسازی عملیات کمک کنند. بااینحال، نباید قابلیتهای هوش مصنوعی یا مهاجرت خودکار بین ابرها را بدون بررسی نسخه و امکانات واقعی محصول، ویژگی پیشفرض تمام محیطهای vSphere دانست.
جمعبندی؛ چه زمانی vMotion یا Storage vMotion را انتخاب کنیم؟
VMware vMotion و Storage vMotion جایگزین یکدیگر نیستند؛ هرکدام بخشی از نیازهای مدیریتی زیرساخت مجازی را پوشش میدهند. vMotion برای تغییر هاست اجراکننده و Storage vMotion برای تغییر محل دادههای ماشین مجازی طراحی شده است.
اگر مسئله سازمان، تعمیر سرور، ارتقای Compute یا توزیع بار بین هاستها باشد، vMotion انتخاب طبیعیتری است. اگر مسئله به ظرفیت، جابهجایی VMDK یا ارتقای Storage مربوط شود، Storage vMotion اهمیت بیشتری دارد. در پروژههایی که هر دو منبع باید تغییر کنند، مهاجرت ترکیبی قابل بررسی است.
سؤالات متداول درباره vMotion و Storage vMotion
تفاوت اصلی VMware vMotion با Storage vMotion چیست؟
vMotion ماشین مجازی روشن را بین هاستهای ESXi منتقل میکند، درحالیکه Storage vMotion فایلها و دیسکهای VM را بین Datastoreها جابهجا میکند. در حالتهای استاندارد، اولی محل اجرای ماشین و دومی محل ذخیرهسازی داده را تغییر میدهد.
آیا vMotion و Storage vMotion بدون Downtime انجام میشوند؟
هر دو برای مهاجرت آنلاین بدون خاموشی برنامهریزیشده طراحی شدهاند. بااینحال، در مرحله نهایی انتقال یا هنگام فشار منابع، وقفه کوتاه یا افت موقت عملکرد ممکن است رخ دهد و صفر بودن مطلق اختلال تضمین نمیشود.
آیا vMotion به Shared Storage نیاز دارد؟
برای Compute-only vMotion، هاست مبدأ و مقصد باید به فایلهای ماشین مجازی دسترسی داشته باشند. اگر Storage مشترک در دسترس نیست، میتوان در شرایط سازگار از مهاجرت همزمان Compute و Storage استفاده کرد.
آیا امکان استفاده همزمان از vMotion و Storage vMotion وجود دارد؟
بله. در سناریوهای پشتیبانیشده، گزینه Change both compute resource and storage امکان تغییر همزمان هاست و محل ذخیرهسازی VM را فراهم میکند. پیشنیازها و محدودیتهای آن باید جداگانه بررسی شوند.
آیا vMotion بین پردازندههای Intel و AMD امکانپذیر است؟
مهاجرت زنده استاندارد نیازمند سازگاری قابلیتهای CPU است و EVC ناسازگاری بین معماریهای متفاوت Intel و AMD را برطرف نمیکند. برای انتقال بین این دو معماری معمولاً باید روشهای دیگری مانند Cold Migration ارزیابی شوند.
چگونه تأثیر Storage vMotion بر عملکرد I/O را کاهش دهیم؟
با بررسی ظرفیت IOPS و Throughput ذخیرهساز، زمانبندی انتقال در ساعات کمبار، محدود کردن مهاجرتهای همزمان و پایش Latency میتوان فشار ناشی از کپی دادهها را مدیریت کرد.
مطالب و محصولات مرتبط
برای بررسی دقیقتر زیرساخت مجازیسازی، طراحی Storage و مدیریت عملکرد ماشینهای مجازی، منابع زیر میتوانند مسیر مطالعه و ارزیابی فنی را تکمیل کنند.
بررسی راهکار ذخیرهسازی نرمافزارمحور برای محیطهای مجازیسازی و زیرساختهای HCI.
آشنایی با ابزارهای مدیریت عملیات، پایش منابع و تحلیل عملکرد محیطهای VMware.
شناخت معماری یکپارچه زیرساخت ابری خصوصی و جایگاه مجازیسازی در مدیریت دیتاسنتر.
اگر برای انتقال ماشینهای مجازی، ارتقای هاستهای ESXi، جابهجایی Datastore یا طراحی مهاجرت بین کلاسترها برنامهریزی میکنید، بررسی سازگاری تجهیزات، وضعیت Workload و ظرفیت شبکه و Storage پیش از اجرا ضروری است. کارشناسان آکو میتوانند در ارزیابی معماری موجود، انتخاب روش مهاجرت و برنامهریزی اجرای آن همراه شما باشند.
HPE
DELL
Broadcom
HPE
DELL
Broadcom
Vmware