خلاصه اجرایی: Broadcom برای حرکت از VCF ۵.۲ به VCF ۹.۱ یک مسیر چندمرحلهای مستند کرده است. بنابراین نباید آن را Direct Upgrade یا Runbook عمومی نامید. پیش از اجرا باید Build دقیق، Precheck، Firmware/HCL، Backup، ظرفیت، NSX/vSAN و وابستگیهای بیرونی ثبت شوند و هر مرحله Gate مستقل داشته باشد.
«مسیر رسمی» دقیقاً چه معنایی دارد؟
وقتی Vendor مسیر ۵.۲ به ۹.۱ را مستند میکند، یعنی برای رسیدن به مقصد، مجموعهای از مراحل و پیشنیازهای پشتیبانیشده تعریف شده است. این عبارت به معنی اجرای یک Bundle روی هر محیط ۵.۲ نیست. Minor release، Build، Patch level و وضعیت اجزای همان محیط تعیین میکنند نقطه ورود و گامهای میانی چه باشند.
بهعلاوه، ارتقای Core Components پایان پروژه نیست. ممکن است پس از رسیدن پلتفرم به مقصد، کارهایی برای Workload Domainها، vDS، vSAN، Licensing، Operations یا Integrationها باقی بماند.
«مسیر ارتقا از VCF ۵.۲ به VCF ۹.۱» درست است؛ «ارتقای مستقیم و یکمرحلهای ۵.۲ به ۹.۱» بدون بررسی Build و مستند رسمی، ادعای قابل اتکایی نیست.
Baseline مبدأ باید Build-aware باشد
ثبت نام VCF ۵.۲ کافی نیست. تیم باید Build دقیق SDDC Manager، vCenter، ESXi، NSX و اجزای مدیریت عملیات را کنار Firmware/Driver و Bundle history قرار دهد. Password و Certificate health، Backup status، Alertهای باز و تغییرهای دستی نیز بخشی از Baseline هستند.
| حوزه | داده مبدأ | چرا مهم است؟ |
|---|---|---|
| SDDC Manager | Build، Bundle history، Depot و Precheck | نقطه ورود Lifecycle و تشخیص مانعها |
| vCenter/ESXi | Build، Custom image، Add-on و Cluster health | Sequence، سازگاری Host و Maintenance |
| NSX | Version، Edge، Transport Node و Integrations | مسیر شبکه و وابستگی سرویسها |
| vSAN/Storage | Architecture، Disk/Policy، ظرفیت و Resync | تحمل Maintenance و Post-upgrade task |
| External tools | Backup، Monitoring، Security و Automation | پشتیبانی API/Plugin در مقصد |
Planning Workbook تشریفات نیست
در نسل جدید VCF، Planning Workbook ورودی تصمیمهای طراحی و ارتقاست. اطلاعات شبکه، Host، Domain، Identity، DNS/NTP، Certificate و سایر وابستگیها باید پیش از Change یکپارچه شوند. اگر چند فایل با اعداد متفاوت بین تیمها وجود دارد، پروژه هنوز Source of Truth ندارد.
Workbook باید نسخهگذاری شود، Owner داشته باشد و تغییر بعد از Freeze Date در Change log ثبت شود. خروجی نهایی باید به Runbook و Validation Matrix متصل باشد تا هر مقدار صرفاً «ثبتشده» نباشد، بلکه اثر آن در اجرا معلوم شود.
سازگاری و ظرفیت دو Gate جدا هستند
ممکن است Host از نظر HCL برای مقصد قابل قبول باشد اما ظرفیت کافی برای خارجکردن یک Node در Maintenance نداشته باشد. یا ممکن است ظرفیت زیاد باشد اما NIC/Controller با Firmware فعلی پشتیبانی نشود. این دو موضوع باید جداگانه پاس شوند.
Compatibility Gate
Server، CPU، NIC، Controller، Drive، BIOS، Firmware، Driver، Custom Image و Add-on با مقصد تطبیق داده میشوند.
Capacity Gate
Compute، Memory، Storage slack، vSAN rebuild، Network و زمان Maintenance در حالت N+۱/N+۲ سنجیده میشوند.
اگر Remediation سختافزار لازم باشد، باید تصمیم گرفت قبل از Upgrade انجام شود، در موج مستقل قرار گیرد یا مسیر Greenfield اقتصادیتر است.
Precheck را زود اجرا کنید، نه شب Change
Precheck باید چند بار و در زمانهای مختلف اجرا شود: یکبار در Assessment برای کشف مانع، بار دوم بعد از Remediation و بار آخر نزدیک پنجره تغییر. خطاها باید با Evidence بسته شوند. عبور اجباری از Warning بدون تحلیل، ریسک را فقط از ابزار به تیم اجرا منتقل میکند.
- سلامت Backup و امکان دسترسی به فایلهای بازیابی؛
- فضای آزاد Repository، Datastore و اجزای مدیریتی؛
- Password، Certificate، DNS، NTP و Account permission؛
- Cluster، vSAN، NSX و سرویسهای متصل؛
- Alertهای قدیمی که باید از رخداد جدید تفکیک شوند؛
- اعتبار Package/Bundle و روش انتقال در محیط Disconnected.
منطق Sequence؛ چرا ترتیب قابل حدس نیست؟
ترتیب دقیق باید از مستندات رسمی همان Release و خروجی ابزارهای Planning استخراج شود. منطق کلی این است که مسیر مدیریت ابتدا در وضعیت قابل کنترل قرار گیرد، سپس Core Components طبق ترتیب پشتیبانیشده جلو بروند و بعد Domainها و وظایف تکمیلی انجام شوند. جابهجاکردن ترتیب برای کوتاهشدن پنجره، بدون تأیید رسمی، میتواند محیط را در حالت نامعتبر قرار دهد.
Readiness
Baseline، Compatibility، Backup، Precheck، Bundle و Runbook نهایی میشوند.
مرحله یا مراحل میانی
محیط مطابق مسیر رسمی از نقطه مبدأ عبور میکند؛ بعد از هر گام Stabilization و Validation انجام میشود.
Core VCF 9.1
اجزای اصلی با ترتیب Release اجرا و وضعیت Lifecycle، API و سرویسهای مدیریت کنترل میشود.
Workload و Post Tasks
Domainها، شبکه، Storage، Licensing و Integrations بر اساس برنامه تکمیل میشوند.
این صفحه عمداً شماره Buildهای میانی را بهعنوان قاعده دائمی فهرست نمیکند؛ Advisory و Release Notes ممکن است بهروزرسانی شوند و باید در زمان اجرا دوباره تأیید شوند.
بعد از Core Upgrade چه چیزهایی باقی میماند؟
رسیدن کنسول به نسخه مقصد به معنی پایان Change نیست. بسته به وضعیت محیط، ممکن است ارتقای Workload Domainها، بازبینی vSphere Distributed Switch، فعالسازی یا تغییر قابلیتهای vSAN، تنظیم License Operations، بازبینی Operations و تکمیل Integrationها لازم باشد.
فعالکردن قابلیت جدید باید از Upgrade جدا شود. ابتدا محیط به Baseline پایدار مقصد برسد؛ سپس Feature adoption در Change مستقل با معیار موفقیت خودش انجام شود. این جداسازی دامنه Troubleshooting را کوچک میکند.
برای هر مرحله Recovery Strategy بنویسید
Rollback عمومی برای کل پروژه عبارت دقیقی نیست. برخی مراحل امکان Retry یا Restore دارند، برخی نیازمند Redeploy یا بازیابی جزء مدیریتیاند و برخی را نمیتوان in-place معکوس کرد. برای همین جدول Recovery باید Step-specific باشد.
| رخداد | تصمیم اولیه | گزینه بازیابی | مالک تصمیم |
|---|---|---|---|
| Precheck failure | No-Go | Remediate و تکرار | Platform lead |
| اختلال سرویس مدیریتی | Pause | روش رسمی Restore/Recovery همان جزء | Incident commander |
| افت Workload | Stop wave | Application recovery یا Failover مصوب | Service owner |
| ناسازگاری Integration | Isolate | نسخه پشتیبانیشده یا مسیر موقت تأییدشده | Tool owner |
موجبندی Change چگونه ریسک را کم میکند؟
مدیریت، شبکه، Storage، Firmware و Workload را تا حد ممکن در موجهایی با Blast Radius روشن قرار دهید. اجرای همزمان همه تغییرها شاید تقویم را کوتاه کند اما تشخیص علت و بازیابی را سختتر میکند.
یک Domain کمریسک میتواند Canary باشد، به شرطی که از نظر معماری نماینده محیط باشد. بعد از هر موج، Stabilization Window و Review رسمی تعیین میشود؛ نبود Incident بهتنهایی معیار موفقیت نیست.
Validation باید از دید سرویس انجام شود
Platform
Health، Lifecycle، Alarm، Certificate، Backup و API.
Infrastructure
vMotion، vSAN policy، Network path، Edge و Performance.
Application
Login، Transaction، Batch، Integration و SLO واقعی.
نتیجه هر تست باید Timestamp، Executor و Evidence داشته باشد. در پایان، Known Issueها، Deferred taskها و Baseline جدید به تیم عملیات تحویل میشوند.
ریسکهای کلیدی این مسیر
- شروع از Build یا Patch level متفاوت با فرض اولیه؛
- سختافزار Supported اما بدون Headroom لازم؛
- ناسازگاری Backup، Monitoring یا افزونههای امنیتی؛
- Certificate، Password یا DNS/NTP نامعتبر؛
- کمبود فضای Repository یا Datastore در میانه کار؛
- فعالسازی همزمان Featureهای جدید و افزایش دامنه Change؛
- نداشتن Recovery time واقعی و تکیه بر Backup آزمایشنشده.
پرسشهای متداول
آیا مسیر ۵.۲ به ۹.۱ رسماً وجود دارد؟
بله، Broadcom آن را در راهنمای Pathways توضیح داده است؛ اما مسیر چندمرحلهای و وابسته به وضعیت واقعی محیط است.
آیا میتوان همه Domainها را در یک پنجره ارتقا داد؟
از نظر برنامه باید Blast Radius، ظرفیت، زمان و Recovery سنجیده شود. موجبندی معمولاً کنترلپذیری بیشتری میدهد.
آیا پس از رسیدن Core به ۹.۱ پروژه تمام است؟
نه لزوماً. Post-upgrade taskها، Workload Domainها، Licensing و Integrationها باید تکمیل و اعتبارسنجی شوند.
آیا Runbook اینترنتی برای همه محیطها قابل استفاده است؟
خیر. مستند رسمی مبناست، اما Runbook باید Build، Hardware، Dependency و Recovery محیط سازمان را منعکس کند.
منابع رسمی و یادداشت نسخه
پیش از اجرا، Release Notes، KBها و Advisoryهای روز باید دوباره بررسی شوند.
برای مطالعه بعدی
Build واقعی را به مسیر رسمی وصل کنید
با Assessment مشخص میشود محیط شما از کدام گامها، Remediationها و پنجرههای تغییر باید عبور کند.