از vSphere 8 به VVF و VCF 9.1.1 چطور به روز رسانی کنیم؟

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

نحوه Upgrade محصولات VMware از نسخه ۸ به ۹، در دو سری VVF و VCF، به چه شکل است؟ می‌توانیم همین محیط فعلی را Upgrade کنیم یا باید یک محیط جدید راه بیندازیم و VMها را به آن منتقل کنیم؟

بعد هم معمولاً سؤال‌های بعدی مطرح می‌شود؛ اینکه سرورهای فعلی قابل استفاده هستند یا نه، باید Storage را عوض کنیم، تکلیف NSX چه می‌شود و این کار چقدر Downtime دارد.

قصد دارم در این مقاله موضوع را یک‌جا توضیح بدهم تا مشخص شود چه راه‌هایی داریم و هرکدام کجا به کارمان می‌آیند. مبنای بحث هم نسخه 9.1.1 است.

اول از همه، قرار نیست برای تمام سازمان‌ها یک روش پیشنهاد بدهیم. محیطی که فقط vCenter و ESXi دارد، با محیطی که NSX و Aria Automation هم دارد، یکسان نیست. سازمانی هم که از قبل VCF دارد، مسیر خودش را دارد.

پس قبل از اینکه سراغ نصب برویم، باید ببینیم الان چه چیزی داریم و از نسخه جدید چه انتظاری داریم.

وقتی می‌گوییم نسخه ۸، دقیقاً منظورمان چیست؟

معمولاً وقتی کسی می‌گوید «VMware ما نسخه ۸ است»، منظورش vSphere 8 است؛ یعنی vCenter و ESXi نسخه ۸، شاید هم در کنار vSAN 8.

اما ممکن است همین سازمان NSX 4.x و Aria Operations 8.x هم داشته باشد. اگر هم از قبل VCF داشته باشد، ممکن است نسخه آن 5.2.x باشد.

این‌ها همگی یک شماره نسخه ندارند که بخواهیم همه را با یک روش از ۸ به ۹ ببریم.

از طرف دیگر، باید مشخص کنیم مقصد VVF است یا VCF. آیا می‌خواهیم همان بستر Virtualization را با امکانات جدید ادامه بدهیم، یا قرار است سراغ یک Private Cloud با قابلیت‌های شبکه، Automation و ارائه سرویس برویم؟

این تصمیم روی مسیر کار، منابع موردنیاز و حجم تغییرات تأثیر می‌گذارد.

Upgrade، Converge، Import و Migration چه فرقی دارند؟

قبل از توضیح سناریوها، این چهار اصطلاح را روشن کنیم؛ چون بخش زیادی از ابهام دقیقاً از همین‌جا می‌آید.

مثلاً وقتی یک محیط را Converge می‌کنیم، الزاماً قرار نیست VMها را از روی سرورهای فعلی برداریم و جای دیگری ببریم. ممکن است همان محیط را نگه داریم و Componentها و ساختار مدیریتی موردنیاز را به آن اضافه کنیم.

اما وقتی درباره Migration صحبت می‌کنیم، موضوع جابه‌جایی VM، Data یا خود Application است. این دو کار را نباید یکی در نظر بگیریم. مسیرهای استقرار VCF

حالت اول: فقط vSphere داریم و می‌خواهیم به VVF برویم

فرض کنیم چند Host با ESXi 8 داریم، یک vCenter هم آن‌ها را مدیریت می‌کند. NSX نداریم و فعلاً هم برنامه‌ای برای راه‌اندازی آن یا پیاده‌سازی یک Private Cloud کامل نداریم.

اینجا می‌شود پروژه را در حد نیاز سازمان جلو برد. لازم نیست به خاطر Upgrade، هم‌زمان طراحی شبکه و Storage و روش ارائه سرویس را هم تغییر بدهیم.

در راهنمای رسمی ۹.۱، برای محیط‌های بدون NSX دو روش مطرح شده است:

• استفاده از Workflowهای Installer برای رسیدن به VVF یا VCF.
• آماده کردن VCF Operations و License Server و سپس Upgrade کردن vCenter و Hostها.

اگر Aria Operations از قبل نصب شده باشد، مسیر Upgrade همان Instance هم باید بررسی شود. راهنمای رسمی مسیرهای Upgrade

پس جواب این سؤال که «می‌توانم همین محیط را نگه دارم و Upgrade کنم؟» در این سناریو می‌تواند بله باشد؛ به شرط اینکه نسخه‌ها، سخت‌افزار و پیش‌نیازهای لازم تأیید شده باشند.

فقط نباید با ذهنیت قدیمی جلو برویم که یک ISO برای vCenter و یکی برای ESXi بگیریم و کار تمام شود. در نسل جدید، Operations و Licensing هم بخشی از برنامه هستند.

حالت دوم: vSphere داریم، ولی مقصد ما VCF است

حالا فرض کنیم سازمان می‌خواهد VCF داشته باشد، اما ترجیح می‌دهد تا جای ممکن از زیرساخت فعلی استفاده کند.

اینجا باید Converge را بررسی کنیم.

در این روش، محیط فعلی بررسی می‌شود و اگر شرایط لازم را داشته باشد، می‌تواند نقطه شروع VCF باشد. VCF Installer هم برای بررسی پیش‌نیازها و اجرای Workflow مربوطه استفاده می‌شود. توضیحات Converge در مستند رسمی VMware

من این روش را وقتی بررسی می‌کنم که محیط فعلی وضعیت مناسبی داشته باشد. یعنی سخت‌افزار هنوز قابل استفاده باشد، طراحی موجود مشکل اساسی نداشته باشد و منابع لازم برای Componentهای جدید هم فراهم باشد.

اما اگر محیط فعلی مشکلات جدی دارد، نباید انتظار داشته باشیم Converge آن‌ها را حل کند.

مثلاً اگر DNS مشکل دارد، Certificateها درست نیستند یا Cluster ظرفیت کافی ندارد، این موارد باید تعیین تکلیف شوند. قرار نیست با اضافه شدن Componentهای VCF، این مشکلات خودشان برطرف شوند.

اگر NSX داشته باشیم چطور؟

اینجا دیگر نباید مثل یک محیط ساده vSphere جلو برویم.

در راهنمای رسمی مسیرهای ۹.۱، برای محیط دارای NSX، مسیر VCF Installer و Workflowهای Converge/Convert/Import مطرح شده است؛ روش Upgrade مستقل Componentها که برای محیط بدون NSX توضیح دادیم، گزینه معادل این سناریو نیست. KB 440630

بنابراین از همان ابتدا باید نسخه NSX، وضعیت Edgeها و وابستگی‌های شبکه را بررسی کنیم. نمی‌شود vCenter را Upgrade کنیم و بعد ببینیم برای NSX چه کاری باید انجام بدهیم.

حالت سوم: VCF داریم و می‌خواهیم محیط‌های قبلی را به آن اضافه کنیم

فرض کنیم یک VCF جدید راه‌اندازی کرده‌ایم، ولی چند محیط vSphere 8 هم داریم که هنوز سرویس‌های سازمان روی آن‌ها هستند.

در این حالت، یکی از گزینه‌ها Import است؛ یعنی محیط موجود را، در صورت داشتن شرایط لازم، به‌عنوان Workload Domain وارد ساختار VCF کنیم.

نکته مهم این است که Import کردن، الزاماً به معنی Upgrade شدن فوری vCenter و تمام Hostها نیست.

در نسل ۹.۱، امکان Import محیط‌های واجد شرایط vSphere 8.0 Update 3 وجود دارد. البته حداقل Patch لازم برای vCenter و ESX را باید دقیق و جداگانه بررسی کنیم. قابلیت‌های Import در VCF 9.1

این موضوع کمک می‌کند پروژه را مرحله‌ای جلو ببریم. یعنی اول محیط را وارد ساختار مدیریتی کنیم و بعد، طبق مسیر پشتیبانی‌شده، سراغ Upgrade برویم.

فقط یک نکته را اشتباه نگیریم: اضافه کردن vCenter به VCF Operations برای Monitoring، همان Import کردن آن به‌عنوان Workload Domain نیست. اینکه اطلاعات یک vCenter را در Dashboard ببینیم، به‌تنهایی یعنی آن محیط را Monitor می‌کنیم؛ نه اینکه تمام فرایند Import آن انجام شده باشد.

حالت چهارم: از قبل VCF 5.2.x داریم

اگر محیط فعلی VCF است، مسیر کار با سناریوهای قبلی فرق دارد. اینجا باید خود پلتفرم را از مسیر Lifecycle آن Upgrade کنیم.

من در چنین محیطی Componentها را جداگانه و خارج از Workflow مربوطه Upgrade نمی‌کنم؛ حتی اگر فایل نسخه جدید آن‌ها در دسترس باشد.

در مسیر کلی، آماده‌سازی یا Upgrade کردن VCF Operations، Componentهای مدیریتی، VCF Management Services و سرویس Licensing مطرح است. بعد هم Upgrade اجزای Domainها طبق برنامه انجام می‌شود. نسخه‌های واسط و ترتیب دقیق کار را باید بر اساس مبدأ و مقصد مشخص کرد. راهنمای Upgrade به VCF 9.1

ضمن اینکه در ۹.۱، VCF Management Services بخشی از معماری است و سرویس‌هایی مثل Lifecycle و Software Depot روی آن قرار می‌گیرند. برای این بخش هم باید منابع و پیش‌نیازها را در نظر بگیریم.

پس صرف اینکه الان VMهای سازمان بدون مشکل اجرا می‌شوند، به این معنی نیست که حتماً برای Upgrade و Componentهای مدیریتی جدید هم ظرفیت کافی داریم.

حالت پنجم: محیط جدید راه بیندازیم و VMها را منتقل کنیم

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

مثلاً قرار است سرورها عوض شوند، طراحی شبکه تغییر کند، Storage جدید داشته باشیم یا محیط فعلی آن‌قدر تغییرات پراکنده داشته که ترجیح بدهیم مقصد را از ابتدا درست طراحی کنیم.

در این روش، VVF یا VCF جدید راه‌اندازی می‌شود، آن را تست می‌کنیم و بعد VMها و سرویس‌ها را مرحله‌ای منتقل می‌کنیم. این هم یکی از مسیرهای رسمی رسیدن به نسل جدید است. بررسی مسیرهای Upgrade و Migration

البته باید منابع کافی برای دوره‌ای که هر دو محیط فعال‌اند داشته باشیم. این روش نیاز به برنامه Migration دارد و لزوماً ارزان‌تر یا سریع‌تر نیست؛ ولی در بعضی پروژه‌ها کنترل بیشتری روی تغییرات به ما می‌دهد.

برای Migration چه گزینه‌هایی داریم؟

HCX

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

روش‌هایی مثل Bulk Migration و Replication Assisted vMotion یا RAV برای نیازهای متفاوت در اختیارمان هستند. Network Extension هم در سناریوی مناسب می‌تواند به حفظ IP کمک کند، ولی همچنان باید مسیر ترافیک و وضعیت شبکه مقصد را طراحی کنیم.

HCX قرار نیست vCenter یا ESXi مبدأ را Upgrade کند؛ کارش جابه‌جایی Workload است. نسخه‌های پشتیبانی‌شده و قابلیت‌های License هم باید بررسی شوند. معرفی رسمی HCX

vMotion و Cross-vCenter vMotion

در شرایط مناسب می‌توانیم این روش‌ها را هم بررسی کنیم. اما اینکه هر دو طرف VMware هستند، برای تأیید Migration کافی نیست.

نسخه‌های مبدأ و مقصد، CPU، Network، نوع و نسخه Switch و شرایط خود VM مهم‌اند. پس نباید بدون بررسی Compatibility، فرض کنیم هر محیط ۸ را می‌توان مستقیم به هر محیط ۹ منتقل کرد. پیش‌نیازهای Cross-vCenter Migration

Cold Migration

اگر سرویس امکان Downtime دارد، Cold Migration هم می‌تواند گزینه مناسبی باشد؛ یعنی VM را خاموش کنیم و از مسیر پشتیبانی‌شده به مقصد منتقل کنیم.

قرار نیست برای هر VM حتماً پیچیده‌ترین روش را انتخاب کنیم. گاهی یک Downtime مشخص و هماهنگ‌شده، کار را ساده‌تر می‌کند.

Backup و Restore

یکی دیگر از گزینه‌ها، Restore کردن VM در محیط مقصد است؛ البته به شرط پشتیبانی نرم‌افزار Backup از نسخه مقصد.

اینجا باید زمان Restore، آخرین وضعیت Data و مدت Downtime را حساب کنیم. اینکه Backup داریم، به‌تنهایی مشخص نمی‌کند این روش برای سرویس موردنظر مناسب است یا نه.

Migration در سطح Application یا Database

گاهی هم اصلاً لازم نیست خود VM را منتقل کنیم. می‌توانیم در مقصد یک VM جدید بسازیم، Application را آماده کنیم و Data را با روش مناسب همان سرویس منتقل کنیم.

مثلاً اگر قرار است هم‌زمان OS یا Database هم تغییر کند، بهتر است این گزینه را بررسی کنیم؛ نه اینکه صرفاً VM قدیمی را به محیط جدید ببریم و بقیه کارها را عقب بیندازیم.

چرا در این بحث نسخه 9.1.1 مهم است؟

یکی از موضوعاتی که در مسیر Upgrade دردسر ایجاد می‌کرد، Back-in-Time Upgrade بود.

اسمش شاید در نگاه اول عجیب باشد: چطور ممکن است از نسخه ۸ به ۹ برویم، ولی Upgrade ما Back-in-Time محسوب شود؟

موضوع شماره اصلی نسخه نیست؛ زمان انتشار Build و اصلاحاتی است که داخل آن وجود دارد.

ممکن است یک Patch از شاخه ۸، بعد از انتشار 9.1.0 ارائه شده باشد و Fixهایی داشته باشد که در Build مقصد 9.1.0 وجود ندارند. در این شرایط، بزرگ‌تر بودن عدد ۹ به معنی مجاز بودن Upgrade نیست.

این محدودیت برای بعضی Buildهای vSphere 8.0 Update 3j و بعد از آن و NSX 4.2.4 و بعد از آن مطرح بود. Broadcom توضیح داده که BOM جدید VCF 9.1.1.0 محدودیت مورد اشاره را برطرف کرده است. KB 448135

ولی این را نباید به شکل «دیگر از هر نسخه‌ای می‌شود مستقیم رفت روی 9.1.1» برداشت کنیم.

هنوز باید Build دقیق را بررسی کنیم:

• در Upgrade Path ببینیم مسیر مبدأ به مقصد پشتیبانی می‌شود یا نه.
• در Interoperability Matrix ببینیم Componentها در مراحل کار و در وضعیت نهایی با هم سازگار هستند یا نه.

حتی ممکن است Import یک محیط مجاز باشد، ولی Upgrade آن به یک Build مشخص مجاز نباشد؛ چون Import لزوماً Buildهای موجود را تغییر نمی‌دهد. تفاوت محدودیت‌های Upgrade، Converge و Import

بنابراین قبل از اجرا، Release Notes، Known Issueها و Patchهای موردنیاز را دوباره بررسی می‌کنیم. صرف اینکه مقصد را «۹.۱.۱» نوشته‌ایم، برنامه Upgrade کامل نشده است.

باید Storage را هم عوض کنیم؟

نه، صرف رفتن به نسل ۹ به این معنی نیست که باید Storage فعلی را کنار بگذاریم.

باید ببینیم مدل Storage، Protocol و معماری فعلی در سناریوی مقصد پشتیبانی می‌شوند یا نه. ضمن اینکه گزینه‌های Storage در Greenfield Deployment، Converge و Import الزاماً یکسان نیستند. گزینه‌های Storage در VCF

در مورد vSAN هم باید Upgrade نسخه را از تغییر معماری جدا کنیم.

اگر الان vSAN OSA داریم، Upgrade نسخه آن را خودکار به ESA تبدیل نمی‌کند. برای رفتن از OSA به ESA، In-place Upgrade نداریم؛ باید Cluster مناسب ESA با سخت‌افزار تأییدشده آماده شود و Data به آن منتقل شود. راهنمای انتقال از OSA به ESA

پس اگر سازمان می‌خواهد هم نسخه جدید داشته باشد و هم از OSA به ESA برود، باید این دو بخش را جداگانه در برنامه ببینیم.

چند مورد که بهتر است قبل از شروع فراموش نکنیم

اگر هنوز از Baseline استفاده می‌کنیم

در نسل ۹ باید موضوع vSphere Lifecycle Manager Images را جدی بگیریم.

روش قدیمی VUM Baseline محدودیت‌های مهمی دارد؛ از جمله اینکه Upgrade کردن Host به ۹ از مسیر ISO-based Upgrade در VUM انجام نمی‌شود. باید مسیر استفاده از Image را بررسی کنیم و ESX Version، Vendor Add-on و Driverهای مناسب را در آن ببینیم. مدیریت Lifecycle با vLCM Images

Licensing را برای آخر کار نگذاریم

در معماری ۹.۱، License Server محلی و مدیریت Licensing از طریق VCF Operations مطرح است.

محیط Disconnected هم فرایند خودش را دارد. آفلاین بودن یعنی باید روش دریافت و انتقال فایل‌های لازم را از قبل آماده کنیم، نه اینکه Licensing دیگر کاری از ما نمی‌خواهد. معماری Licensing در ۹.۱

دسترسی به فایل‌ها، Depot و Licensing باید قبل از شروع آماده باشد. وسط Maintenance Window زمان مناسبی برای حل این موارد نیست.

فقط خود vSphere را بررسی نکنیم

نرم‌افزار Backup، Storage Pluginها، راهکارهای Security، ابزارهای Monitoring، Kubernetes و Scriptهایی که در سازمان استفاده می‌کنیم، همگی باید بررسی شوند.

ممکن است Upgrade خود vCenter موفق باشد، ولی یکی از ابزارهای موردنیاز تیم دیگر با آن کار نکند.

حتی محصولات Aria هم همگی یک روش Upgrade ندارند. برای نمونه، رفتن به Log Management جدید در ۹.۱، یک In-place Upgrade ساده روی Appliance قبلی Logs نیست؛ سرویس جدید مستقر می‌شود و انتقال Data مسیر خودش را دارد. راهنمای Upgrade و Componentهای جانبی

چقدر Downtime داریم؟

تا محیط و سرویس‌ها را نبینم، برای کل پروژه عدد نمی‌دهم.

Downtime بخش Management با Downtime خود Application فرق دارد. ممکن است vCenter برای مدتی در دسترس نباشد، ولی VMها همچنان کار کنند. از طرف دیگر، ممکن است یک VM به دلیل شرایط خاص خودش به خاموش شدن نیاز داشته باشد.

وجود Live Patching هم به این معنی نیست که Upgrade اصلی از ۸ به ۹ بدون Reboot انجام می‌شود. این قابلیت برای Patchهای واجد شرایط است، نه تمام عملیات Upgrade. توضیحات Express Patching

برای همین باید سرویس‌به‌سرویس مشخص کنیم چه مقدار Downtime قابل قبول است و بعد از کار، چه کسی عملکرد آن را تست می‌کند.

روشن بودن VM برای تحویل گرفتن سرویس کافی نیست. ممکن است VM روشن باشد، ولی Application به Database وصل نشود یا Backup آن دیگر اجرا نشود.

من از کجا شروع می‌کنم؟

اول نسخه و Build دقیق Componentها، وضعیت سخت‌افزار، Storage، Network و ظرفیت آزاد را جمع می‌کنم. در کنار این‌ها، وابستگی سرویس‌های مهم را هم مشخص می‌کنم.

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

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

من ترجیح می‌دهم تغییرات را تا جای ممکن مرحله‌ای انجام بدهم. اگر هم‌زمان نسخه، Network، Storage و تنظیمات Application را تغییر بدهیم، موقع بروز مشکل پیدا کردن علت سخت‌تر می‌شود.

Rollback Plan هم باید قبل از اجرا مشخص باشد. جمله «اگر مشکل شد Snapshot را برمی‌گردانیم» برای این پروژه کافی نیست.

باید بدانیم کدام تغییر قابل برگشت است، برگشت چقدر زمان می‌برد و با Data جدیدی که بعد از Migration در مقصد ایجاد شده چه می‌کنیم. داشتن محیط قبلی، به‌تنهایی تضمین نمی‌کند که برگشت به آن بدون مشکل خواهد بود.

در نهایت چه روشی را انتخاب کنیم؟

اگر محیط ساده و سالمی داریم و هدفمان ادامه کار در قالب VVF است، مسیر Upgrade همان محیط را بررسی می‌کنیم.

اگر می‌خواهیم از زیرساخت فعلی برای رسیدن به VCF استفاده کنیم، Converge مطرح می‌شود. اگر VCF از قبل راه‌اندازی شده، Import محیط‌های واجد شرایط هم یک گزینه است.

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

در یک سازمان بزرگ ممکن است هر سه روش را داشته باشیم؛ یک Cluster را Upgrade کنیم، یک محیط را Import کنیم و VMهای روی سرورهای قدیمی را به Cluster جدید ببریم.

بنابراین برای رفتن از ۸ به ۹، اول وضعیت فعلی و مقصد را مشخص می‌کنیم. بعد روش را انتخاب می‌کنیم. دانلود فایلهای نصب و اجرای Upgrade، مرحله بعد از این تصمیم‌هاست.