برای مهاجرت ماشین های مجازی از نسخه vSphere 8 به نسخه 9، معمولاً سوالی که روزهای اخیر از من می پرسند و دغدغه اصلی است به این شرح است:
ماشین‌هایی که همین حالا سرویس می‌دهند، چطور به محیط جدید منتقل شوند؟ چقدر قطعی خواهیم داشت و آیا لازم است IPها و تنظیمات برنامه‌ها را تغییر بدهیم؟
من برای پاسخ، از وضعیت سرویس‌ها شروع می‌کنم. باید بدانیم چه چیزی قرار است جابه‌جا شود، چه میزان قطعی قابل‌قبول است و مقصد چطور آماده شده. بعد می‌توانیم درباره ابزار تصمیم بگیریم. در این مقاله، مسیر انتقال ماشین‌های مجازی به یک محیط جدید را توضیح می‌دهم و نشان می‌دهم VMware HCX در کدام بخش‌های این کار به ما کمک می‌کند.
اول مشخص کنیم: ارتقای زیرساخت یا مهاجرت ماشین‌ها؟
اگر قرار است vCenter و هاست‌های فعلی را ارتقا بدهید، باید مسیر Upgrade، سازگاری سخت‌افزار و ترتیب ارتقای اجزا را بررسی کنیم. اما اگر محیط جدیدی در کنار محیط فعلی آماده کرده‌اید و می‌خواهید VMها را مرحله‌به‌مرحله به آن ببرید، موضوع ما مهاجرت است. در ادامه درباره همین حالت صحبت می‌کنم.
فرض کنید تعدادی هاست با vSphere 8 دارید و سرویس‌های سازمان روی آن‌ها کار می‌کنند. حالا یک محیط جدید مبتنی بر نسخه 9 آماده کرده‌اید؛ مثلاً یک زیرساخت VCF 9.1. می‌خواهید سرویس‌ها را منتقل کنید، بدون اینکه مجبور شوید همه‌چیز را از اول نصب و تنظیم کنید. اینجاست که HCX می‌تواند کمک کند.
HCX چیست و چه زمانی به آن نیاز داریم؟
HCX ابزار جابه‌جایی ماشین‌های مجازی و فراهم‌کردن ارتباط لازم برای این جابه‌جایی است. خود HCX هاست‌های شما را از نسخه 8 به 9 ارتقا نمی‌دهد. محیط مقصد باید از قبل آماده باشد تا ماشین‌ها به آن منتقل شوند. در مستندات جدید ممکن است نام VCF Operations Workload Mobility را هم ببینید؛ من در ادامه همان نام آشنای HCX را استفاده می‌کنم.
البته برای هر مهاجرتی هم بلافاصله سراغ HCX نمی‌روم. اگر تعداد ماشین‌ها کم باشد و شرایط فنی و مجوزها اجازه بدهند، قابلیت‌های خود vSphere، مثل جابه‌جایی بین vCenterها، ممکن است کافی باشند. انتخاب من به تعداد VMها، وضعیت شبکه و میزان قطعی قابل‌قبول بستگی دارد.
ارزش HCX زمانی بیشتر مشخص می‌شود که بخواهیم تعداد زیادی ماشین را در چند مرحله منتقل کنیم، برای انتقال نهایی زمان تعیین کنیم یا شبکه بعضی ماشین‌ها را در طول مهاجرت حفظ کنیم. قبل از انتخاب آن هم باید نسخه دقیق ESXi، vCenter و HCX و مجوز استفاده را بررسی کنیم؛ عبارت کلی «از 8 به 9» برای تأیید سازگاری کافی نیست.
قبل از مهاجرت، وابستگی سرویس‌ها را مشخص می‌کنم
فرض کنیم تصمیم گرفته‌ایم از HCX استفاده کنیم. من کار را با شناخت سرویس‌ها شروع می‌کنم. برای مثال، یک سامانه مالی ممکن است سه ماشین داشته باشد: وب‌سرور، سرور برنامه و دیتابیس. اگر فقط فهرست VMها را ببینیم، ممکن است یکی را امروز منتقل کنیم و دو تای دیگر را هفته بعد. اما این سه ماشین مرتب با هم ارتباط دارند. فاصله شبکه‌ای جدید می‌تواند روی عملکرد سامانه اثر بگذارد، حتی اگر هر سه ماشین روشن و سالم باشند.
به همین دلیل، من برنامه مهاجرت را بر اساس سرویس می‌چینم. مشخص می‌کنم هر سامانه به کدام VMها، DNS، Active Directory، دیتابیس و سرویس‌های دیگر وابسته است. بعد با مسئول همان سامانه درباره زمان انتقال و روش تست توافق می‌کنم. روشن‌شدن ماشین در مقصد فقط یکی از مراحل کار است؛ باید مطمئن شویم سرویس هم درست کار می‌کند.
اتصال دو محیط با HCX چگونه آماده می‌شود؟
برای راه‌اندازی HCX، دو محیط باید به یکدیگر معرفی شوند. HCX Manager بخش مدیریتی کار را انجام می‌دهد. در محیط VCF 9.1 امکان استقرار آن از مسیر VCF Operations وجود دارد؛ سمت محیط قدیمی هم مسیر استقرار متناسب با همان محیط را داریم. نداشتن NSX در مبدأ، به‌تنهایی مانع استفاده از HCX نیست، اما طراحی شبکه مبدأ و مقصد باید با قابلیت موردنظر سازگار باشد.
بعد از معرفی دو سایت به یکدیگر، مشخص می‌کنیم HCX از چه منابع پردازشی و چه شبکه‌هایی استفاده کند. ارتباط مدیریتی دو طرف Site Pairing نام دارد و مجموعه ارتباط‌ها و Applianceهای لازم برای انتقال، در قالب Service Mesh ساخته می‌شود.
اگر بخواهم ساده بگویم، Site Pairing دو محیط را به هم معرفی می‌کند؛ Service Mesh امکانات لازم برای انتقال بین آن‌ها را فراهم می‌کند. Appliance مربوط به انتقال را با نام IX می‌بینید و اگر به گسترش شبکه نیاز داشته باشیم، NE هم وارد طراحی می‌شود.
در این مرحله من فقط به سبزشدن وضعیت اتصال اکتفا نمی‌کنم. باید ظرفیت واقعی مسیر انتقال، تأخیر و کیفیت ارتباط را هم بدانیم. حجم دیسک ماشین‌ها مهم است، اما سرعت تغییر داده‌ها هم اهمیت دارد؛ مثلاً یک دیتابیس پرکار در زمان انتقال اولیه همچنان داده جدید تولید می‌کند. برنامه زمانی مهاجرت باید این تغییرات را هم در نظر بگیرد.
تفاوت Bulk Migration و RAV؛ ماشین‌ها خاموش می‌شوند؟
میزان قطعی به روش مهاجرت بستگی دارد. من پیش از انتخاب روش، زمان توقف قابل‌قبول هر سرویس را مشخص می‌کنم.
Bulk Migration؛ انتقال اولیه هنگام روشن‌بودن VM
در Bulk Migration، HCX در حالی که ماشین مبدأ روشن است، داده‌های دیسک را به مقصد منتقل می‌کند و تغییرات بعدی را هم همگام نگه می‌دارد. هنگام انتقال نهایی یا Cutover، ماشین مبدأ خاموش می‌شود، آخرین تغییرات منتقل می‌شوند و ماشین در مقصد روشن می‌شود. بنابراین Bulk قطعی دارد، اما بخش اصلی کپی داده‌ها پیش از زمان قطعی انجام شده است.
من Bulk را برای سرویسی بررسی می‌کنم که یک بازه توقف مشخص و موردتوافق دارد. زمان قطعی را هم بدون تست قول نمی‌دهم؛ خاموش‌شدن سیستم‌عامل، همگام‌سازی نهایی و بالا آمدن برنامه همگی روی آن اثر دارند.
RAV؛ تکثیر دیسک و انتقال زنده در مرحله نهایی
اگر بخواهیم انتقال نهایی به‌صورت زنده انجام شود، یکی از گزینه‌ها Replication Assisted vMotion یا RAV است. در این روش، ابتدا داده‌های دیسک تکثیر می‌شوند و مرحله نهایی با انتقال وضعیت در حال اجرای ماشین از طریق vMotion انجام می‌شود.
برای انتخاب RAV باید شرایط همان VM و زیرساخت را بررسی کنیم. سازگاری پردازنده، دسترسی شبکه و وضعیت دیسک‌ها و تجهیزات متصل مهم هستند. بعضی پیکربندی‌ها، مانند دیسک‌های اشتراکی یا اتصال مستقیم بعضی تجهیزات، محدودیت ایجاد می‌کنند. بنابراین من برای همه ماشین‌ها یک روش ثابت انتخاب نمی‌کنم؛ ممکن است بخشی با Bulk و بخشی با روش زنده منتقل شوند.
آیا می‌توان IP ماشین‌های مجازی را حفظ کرد؟
سؤال بعدی معمولاً این است: «IP ماشین‌ها چه می‌شود؟ کلی تنظیمات و ارتباط به این آدرس‌ها وابسته است.» اگر طراحی ما به حفظ شبکه فعلی نیاز داشته باشد، قابلیت Network Extension را بررسی می‌کنیم. این قابلیت شبکه لایه دوم را بین دو محیط امتداد می‌دهد تا ماشین منتقل‌شده بتواند در شبکه گسترش‌یافته، آدرس IP خود را حفظ کند.
این ویژگی برای مهاجرت مرحله‌ای مفید است؛ چون ممکن است مدتی بخشی از ماشین‌های یک سرویس در مبدأ و بخش دیگری در مقصد باشند. اما حفظ IP به معنی حذف وابستگی به شبکه قبلی نیست.
در حالت معمول Network Extension بدون بهینه‌سازی مسیریابی، Gateway می‌تواند همچنان در مبدأ باشد. یعنی ماشین در مقصد اجرا می‌شود، اما برای بعضی ارتباط‌ها هنوز ترافیک به سمت مبدأ برمی‌گردد. قابلیت Mobility Optimized Networking یا MON در طراحی‌های پشتیبانی‌شده به بهینه‌سازی این مسیر کمک می‌کند. پس قبل از جمع‌کردن محیط قدیمی، باید تکلیف Gateway، مسیریابی و پایان‌دادن به شبکه گسترش‌یافته روشن شده باشد.
از انتقال آزمایشی تا تأیید سرویس و برنامه بازگشت
وقتی ارتباط‌ها آماده شد، من با یک سرویس کم‌ریسک شروع می‌کنم؛ سرویسی که مسئول مشخص و روش تست روشن داشته باشد. خوشه، Datastore و شبکه مقصد را تعیین می‌کنم، اعتبارسنجی HCX را انجام می‌دهم و انتقال آزمایشی را جلو می‌برم.
بعد از انتقال، فقط Ping نمی‌گیرم. ورود کاربر، ارتباط برنامه با دیتابیس، دسترسی به سرویس‌های وابسته، مانیتورینگ و اجرای Backup را بررسی می‌کنم. نتیجه این مرحله به من نشان می‌دهد برنامه انتقال گروه بعدی چقدر واقع‌بینانه است.
برای برگشت هم از قبل تصمیم می‌گیرم. در Bulk، باقی‌ماندن نسخه خاموش ماشین در مبدأ می‌تواند مفید باشد، اما وقتی سرویس در مقصد داده جدید تولید کرده، روشن‌کردن نسخه قدیمی به‌تنهایی بازگشت کامل محسوب نمی‌شود. باید وضعیت داده‌ها و جلوگیری از فعالیت هم‌زمان دو نسخه را مدیریت کنیم. همچنین ارتقای Virtual Hardware در مقصد می‌تواند امکان برگشت به محیط قدیمی را محدود کند؛ زمان انجام آن را جداگانه تعیین می‌کنم.
پس اگر از من بپرسید «برای بردن VMها از vSphere 8 به 9 چه‌کار کنم؟»، پیشنهاد من این است: ابتدا مقصد و وابستگی سرویس‌ها را مشخص کنیم، بعد ابزار و روش انتقال را انتخاب کنیم. اگر HCX با شرایط محیط سازگار باشد، می‌توانیم مهاجرت را مرحله‌ای و با زمان‌بندی مشخص جلو ببریم.
من زمانی مهاجرت را تمام‌شده می‌دانم که کاربر بتواند با سرویس کار کند، تیم پشتیبانی بتواند آن را پایش و بازیابی کند و وابستگی باقی‌مانده به محیط قبلی هم مشخص شده باشد. هدف ما انتقال سالم سرویس به زیرساخت جدید، با قطعی قابل‌قبول و مسیر برگشت روشن است.
برای مطالعه مباحث زیربنایی این مسیر، سرفصل‌های آموزش VMware در ابرکلاس مهارت‌های مرتبط با vSphere، شبکه و ابر خصوصی را معرفی می‌کنند.
