خلاصه اجرایی: ابتدا باید معلوم شود سازمان واقعاً در کدام مسیر رسمی قرار دارد—Converge، Upgrade یا Greenfield. سپس برای هر موج، Gate ورود، شرط توقف، معیار موفقیت و راه بازیابی تعریف شود. عبارت «ارتقای مستقیم» بدون دانستن Build مبدأ، BOM، وضعیت SDDC Manager، NSX، vSAN و سختافزار، تصمیم قابل اتکایی نیست.
چرا Upgrade یک پروژه است، نه یک دکمه؟
در یک محیط VCF، نسخه تنها متعلق به ESXi نیست. SDDC Manager، vCenter، NSX، vSAN، Firmware، درایورها، ابزارهای پشتیبانگیری، Monitoring، افزونههای امنیتی و گاهی اتوماسیونهای بیرونی به هم وابستهاند. ممکن است هر جزء بهتنهایی «قابل ارتقا» باشد، اما ترکیب آنها در Buildهای فعلی سازمان مسیر دیگری بسازد.
به همین دلیل معیار موفقیت نباید فقط نمایش نسخه جدید در کنسول باشد. سرویسهای مدیریتی باید سالم بمانند، Workloadها طبق SLO کار کنند، Backup و Restore معتبر باشند، مسیرهای شبکه و Storage Policyها کنترل شوند و تیم عملیات بتواند Lifecycle بعدی را ادامه دهد.
اگر نسخه مبدأ، مقصد، وابستگی و روش بازگشت در یک سند واحد دیده نمیشوند، هنوز Upgrade Plan نداریم؛ فقط یک فهرست فعالیت داریم.
نسخه مبدأ را با نام محصول تعریف نکنید
عبارتهایی مثل «ما VCF ۵ داریم» یا «زیرساخت vSphere ۸ است» برای برنامهریزی کافی نیستند. Baseline باید در یک Freeze Date ثبت شود تا تغییرهای همزمان، نتیجه Assessment را مخدوش نکنند.
اطلاعات مدیریتی
Build دقیق SDDC Manager و vCenter، وضعیت Bundleها، Password/Certificate health، Depot configuration، Backup و تاریخ آخرین Precheck.
Compute و سختافزار
مدل Host، CPU Generation، BIOS، Firmware، Driver، NIC، Controller، Boot Device و انطباق با راهنمای سازنده و Compatibility Guide.
Network و Security
نسخه NSX، توپولوژی Edge، MTU، Routing، Certificate، سرویسهای امنیتی، Integrations و هر Extension خارج از Bill of Materials.
Storage و Data Protection
نوع vSAN، Disk/Storage Pool، Policy، ظرفیت آزاد، Encryption، Backup product، Proxyها، Snapshotهای مانده و آزمون Restore.
این Baseline فقط Inventory نیست؛ باید کنار هر مورد، وضعیت پشتیبانی، فاصله با مقصد، Owner، Evidence و اثر احتمالی ثبت شود.
اول مسیر رسمی را مشخص کنید
Broadcom برای رسیدن به نسل جدید VCF سه مسیر کلی را تفکیک میکند. این تفکیک مهم است، چون «تبدیل محیط vSphere به VCF»، «ارتقای یک VCF موجود» و «ساخت محیط جدید» سه پروژه با داده ورودی، ریسک و خروجی متفاوتاند.
| مسیر | چه زمانی مطرح است؟ | پرسش محوری | ریسک غالب |
|---|---|---|---|
| Converge | اجزای VMware وجود دارند اما بهعنوان VCF مدیریت نمیشوند | آیا وضعیت موجود قابل ورود به مدل Lifecycle یکپارچه است؟ | ناسازگاری Build و Drift پیکربندی |
| Upgrade | محیط VCF موجود باید به نسخه هدف برسد | کدام مسیر چندمرحلهای و کدام ترتیب برای همین Build معتبر است؟ | Dependency، ظرفیت و پنجره تغییر |
| Greenfield | محیط جدید ساخته و Workload منتقل میشود | چه چیز باید از نو طراحی شود و چه چیز مهاجرت کند؟ | طراحی مقصد و موجهای Migration |
انتخاب مسیر از روی ترجیح تیم انجام نمیشود. وضعیت سختافزار، زمان، امکان خرید، مهارت عملیاتی، محدودیت Downtime و کیفیت محیط فعلی تعیین میکنند کدام مسیر دفاعپذیرتر است.
Gateهای آمادگی قبل از Change
یک Runbook خوب فقط «چه کاری انجام دهیم» را نمیگوید؛ مشخص میکند در چه شرایطی اجازه ورود به مرحله بعد نداریم.
Gate مستندات
Build Matrix، Dependency Map، حسابهای دسترسی، Backup evidence و Contact Matrix کامل و بازبینی شدهاند.
Gate سازگاری
Host، Firmware، Driver، NIC، Storage Controller و نرمافزارهای متصل برای مقصد بررسی شدهاند؛ «احتمالاً سازگار است» وضعیت قابل قبول نیست.
Gate ظرفیت
فضای آزاد، Headroom محاسباتی، ظرفیت مدیریت و امکان جابهجایی Workload در زمان Maintenance تأیید شده است.
Gate عملیات
Precheckها بدون خطای حلنشدهاند، Alertهای قدیمی تفکیک شدهاند و تیم NOC میداند کدام هشدار در Change مورد انتظار است.
Gate بازگشت
Backup تنها «گرفته» نشده؛ محل، دسترسی، مدت بازیابی و مسئول اجرای Recovery مشخص است.
ترتیب اجرا چگونه ساخته میشود؟
Sequence نهایی باید از مستندات همان Release و خروجی Planning Workbook استخراج شود. با این حال منطق اجرایی معمولاً از لایه مدیریت آغاز میشود، سلامت اجزای مرکزی را تثبیت میکند و سپس Workload Domainها را موجبندی میکند. هر مرحله باید ورودی، اقدام، آزمون و تصمیم Go/No-Go داشته باشد.
| موج | تمرکز | نمونه Validation | شرط توقف |
|---|---|---|---|
| آمادهسازی | Backup، Download/Depot، دسترسی و Precheck | بازیابیپذیری و سلامت سرویسها | خطای Critical یا Evidence ناقص |
| Management | اجزای مدیریتی مطابق ترتیب رسمی | Login، Inventory، Lifecycle و Alarm baseline | اختلال سرویس مدیریتی یا ناسازگاری |
| Network/Storage | NSX، vSAN و Firmware در نقطه مناسب | Routing، Edge، Policy compliance و Resync | Packet loss، Degraded policy یا ظرفیت ناکافی |
| Workload Domains | Clusterها بر اساس اهمیت کسبوکار | Application smoke test و Monitoring | عبور از SLO یا خطای تکرارشونده |
| تثبیت | Post-check، Documentation و Handover | Backup، Alert، Performance و عملیات روزمره | عدم پذیرش تیم عملیات |
ترتیب نمونه جای مستند Release را نمیگیرد. در VCF، ترتیب دقیق میتواند بین نسخهها تغییر کند؛ بنابراین Runbook باید Build-aware باشد، نه محصولمحور.
Downtime را با یک عدد کلی پنهان نکنید
زمان Upgrade با زمان اختلال کسبوکار یکی نیست. ممکن است پنجره عملیات چند ساعت باشد اما اپلیکیشن بهدلیل Redundancy وقفه قابلمشاهده نداشته باشد؛ یا برعکس، یک Restart کوتاه روی سرویس وابسته اثر جدی بگذارد. برنامه باید چهار زمان را جدا کند:
- Maintenance Window: کل زمانی که Change در جریان است.
- Management Plane Impact: زمانی که کنسول یا API مدیریتی محدود میشود.
- Workload Impact: اثر قابل مشاهده روی VM یا اپلیکیشن.
- Stabilization Window: زمانی که تغییر جدید اجرا نمیشود و تیم فقط پایش میکند.
RTO و RPO متعلق به سرویس کسبوکارند، نه به محصول VMware. تیم اپلیکیشن باید Validation و پذیرش هر موج را امضا کند.
Rollback با Recovery یکی نیست
در بعضی مراحل امکان بازگشت in-place محدود یا نامعتبر است. بنابراین استفاده عمومی از واژه Rollback میتواند انتظار نادرست بسازد. برای هر فعالیت باید یکی از این پاسخها روشن باشد: توقف و ادامهندادن، Retry طبق مستند، Restore از Backup، Redeploy جزء مدیریتی، Failover سرویس یا بازگشت Workload به مسیر قبلی.
این تفاوت روی زمان، ابزار، مهارت و مالک تصمیم اثر دارد. «Backup داریم» بدون آزمون Restore و بدون برآورد زمان، استراتژی بازیابی محسوب نمیشود.
Upgrade به چه تیمهایی وابسته است؟
Platform
مالک Runbook، SDDC Manager، vCenter، ESXi و هماهنگی کلی.
Network/Security
مالک Underlay، NSX، Firewall، Edge، Route و تغییرهای دسترسی.
Storage/Backup
مالک vSAN، SAN/NAS متصل، Backup، Restore و ظرفیت.
Application
تعریف Smoke Test، SLO و پذیرش سرویس پس از هر موج.
NOC/Operations
ثبت Baseline، پایش Alert و تحویلگیری مدل عملیاتی جدید.
Change Manager
تصمیم Go/No-Go، ارتباطات، پنجره تغییر و ثبت شواهد.
خروجیای که باید تحویل بگیرید
- As-Is و Target Build Matrix با مرجع رسمی هر تصمیم؛
- Compatibility و Remediation Register برای Hardware و Software؛
- Dependency Map و نقشه ارتباط با ابزارهای بیرونی؛
- Runbook موجبندیشده با Owner، زمان، Evidence و Go/No-Go؛
- Backup/Recovery Plan و آزمونهای قبل و بعد؛
- Application Validation Matrix و Sign-off ذینفعان؛
- Operational Handover شامل Monitoring، Backup، Patch و Known Issueها.
یک سناریوی نمونه برای تصمیمگیری
فرض کنید سازمانی دو Workload Domain، یک Management Domain، NSX Edge مشترک، vSAN با ظرفیت محدود و ابزار Backup متصل به vCenter دارد. اجرای همه چیز در یک آخر هفته، از نظر تقویمی جذاب است اما سه ریسک را همزمان میکند: ظرفیت جابهجایی VM، تغییر شبکه و اعتبار Integration پشتیبانگیری.
طرح قابل دفاعتر ممکن است ابتدا Remediation سختافزار و پاکسازی Alertها، سپس Management Domain، بعد یک Domain کمریسک و در نهایت Domain بحرانی باشد. بین موجها Stabilization تعریف میشود. این مثال توصیه نسخهای نیست؛ نشان میدهد Wave Design از وضعیت واقعی میآید، نه از تعداد صفحههای راهنمای نصب.
این خدمت چه چیزی را تضمین نمیکند؟
پیش از Assessment نمیتوان مدت قطعی، مسیر دقیق Buildها یا امکان حفظ همه سختافزارها را قطعی اعلام کرد. همچنین پشتیبانی هر ابزار Third-party باید توسط سازنده همان ابزار تأیید شود. پیشنهاد راگا باید با Release Notes، Compatibility Guide، Planning Workbook و وضعیت واقعی محیط در تاریخ اجرا تطبیق داده شود.
پرسشهای متداول
آیا میتوان VCF را مستقیماً به آخرین نسخه برد؟
فقط پس از شناسایی Build مبدأ و بررسی مسیر رسمی میتوان پاسخ داد. در بسیاری از محیطها مسیر چندمرحلهای یا پیشنیازهای میانی وجود دارد.
آیا Upgrade حتماً Downtime اپلیکیشن دارد؟
خیر، اما نبود Downtime هم قابل فرض نیست. معماری Redundancy، نوع جزء، ظرفیت و آزمون اپلیکیشن تعیینکنندهاند.
آیا Snapshot برای بازگشت کافی است؟
خیر. بعضی اجزای مدیریتی روش Backup/Restore مشخص دارند و Snapshot میتواند محدودیت یا ریسک خود را داشته باشد.
آیا Firmware را میتوان بعداً اصلاح کرد؟
اگر Firmware/Driver بخشی از Compatibility مقصد باشد، عقبانداختن آن ممکن است خود Upgrade را متوقف یا محیط را در وضعیت پشتیبانینشده قرار دهد.