اگر vSphere را فقط «ESX بهعلاوه vCenter» ببینیم، بخش مهم تغییر نسخه 9.1 را از دست میدهیم. در این نسل، Broadcom روی سه مسئله عملیاتی تمرکز کرده است: کوتاهکردن پنجره نگهداری، استانداردکردن وضعیت میزبانها و استفاده بهتر از سختافزارهای جدید. نتیجه، مجموعهای از قابلیتهاست که از Quick Patch در vCenter تا Live Patch گستردهتر در ESX، استقرار Zero-Touch، Memory Tiering و اجرای موازی vMotionهای DRS را در بر میگیرد.
این مقاله بهجای تکرار فهرست بازاریابی، توضیح میدهد هر قابلیت در معماری واقعی چه اثری دارد، چه پیشنیازی میخواهد و در چه شرایطی نباید روی آن حساب قطعی باز کرد. برای شناخت جایگاه این لایه در کل پلتفرم، ابتدا مطلب مقایسه VVF و VCF 9.1 و مسیر آموزش VMware ابرکلاس را نیز ببینید.
vSphere 9.1 دقیقاً چیست؟
در اسناد جدید Broadcom نام Hypervisor بهصورت VMware ESX 9.1 و لایه مدیریت بهصورت VMware vCenter Server 9.1 نوشته میشود. این دو، هسته Compute در VMware Cloud Foundation 9.1 و VMware vSphere Foundation 9.1 هستند. بنابراین «vSphere 9.1» نام مناسبی برای بحث فنی درباره مجموعه Compute و Management است، اما هنگام بررسی Entitlement و دانلود باید محصول بالادستی یعنی VCF یا VVF را نیز مشخص کرد.
بعضی قابلیتهای مهم این نسخه به اجزای دیگر وابستهاند. برای نمونه، Memory Tiering به NVMe سازگار و پیکربندی Cluster نیاز دارد؛ اعتبارسنجی Firmware در vSAN Cluster معنا پیدا میکند؛ و عملیات Lifecycle در VCF/VVF 9.1 با VCF Operations و License Server جدید پیوند خورده است. پس مشاهده یک گزینه در رابط کاربری، بهتنهایی تضمین نمیکند که سختافزار، لایسنس و Topology موجود از آن پشتیبانی میکنند.
مقایسه vSphere 8، 9.0 و 9.1
| حوزه | vSphere 8.x | vSphere 9.0 | vSphere 9.1 |
|---|---|---|---|
| نگهداری vCenter | Patch و Upgrade سنتی؛ RDU در نسلهای جدیدتر | بلوغ Reduced Downtime Upgrade | Quick Patch هدفمند، RDU با Online Depot و API اعلام Maintenance |
| Patch میزبان | Image-based Lifecycle و Maintenance Mode | Live Patch برای بخشی از Patchها | Live Patch پیشفرض برای Patch سازگار، پشتیبانی TPM و پوشش بیشتر vmkernel و Daemonها |
| Desired State | Host Profiles و آغاز Configuration Profiles | گسترش VCP و Image-based Management | Remediation خودکار میزبان جدید، Bootstrap کردن VDS و اتصال به Memory Tiering |
| استقرار میزبان | Auto Deploy متکی به الگوهای قدیمیتر Boot | خودکارسازی بیشتر Lifecycle | Zero-Touch با UEFI HTTP/S Boot، Secure Boot و TPM؛ بدون TFTP خارجی |
| حافظه | DRAM و قابلیتهای متداول Memory Management | معرفی Memory Tiering | Memory Tiering کاملتر با Claim و Software Mirroring اختیاری NVMe از طریق VCP |
| زمانبندی و Mobility | DRS و vMotion بالغ | بهینهسازی نسل جدید Scheduler | Topology-aware Scheduling و پردازش موازی vMotionهای DRS |
| Certificate | مدیریت عمدتاً برنامهریزیشده توسط Admin | بهبود Lifecycle گواهی | تمدید خودکار Certificateهای تحت VMCA با آستانههای مشخص |
| Licensing | کلیدهای سنتی نسخه 8 | Entitlement و License جدید پلتفرم 9 | VCF License Server اجباری برای VCF و VVF 9.1 |
این جدول نباید به این برداشت منجر شود که 9.1 همه قابلیتهای 9.0 را از نو ساخته است. بسیاری از فناوریها در 9.0 معرفی شدند و در 9.1 به سطحی عملیاتیتر رسیدند. تفاوت مهم، کاهش اصطکاک در Day-2 Operations است: Patch، Provisioning، Drift Control و Scale به هم نزدیکتر شدهاند.
قابلیتهای جدید vCenter Server 9.1
Quick Patch؛ Patch هدفمند بهجای تعویض همه بستهها
در Patch سنتی، حتی اجزایی که تغییر کد نداشتند نیز در چرخه Update قرار میگرفتند. vCenter Quick Patch فقط RPMها یا Binaryهای تغییرکرده در Payload را بهروزرسانی میکند. Broadcom برای Patchهای مناسب، Downtime کمتر از یک دقیقه و در برخی موارد بدون Downtime را مطرح میکند. نکته کلیدی عبارت «Patch مناسب» است؛ Quick Patch جایگزین همه Updateها و Upgradeهای Major نیست.
برای سازمانی که Automation، Backup و Kubernetes API آن به vCenter متصل است، این کاهش Downtime ارزش بیشتری از چند دقیقه دسترسی UI دارد. کوتاهشدن وقفه API یعنی Jobهای Provisioning و عملیات روزمره کمتر با شکست زنجیرهای مواجه میشوند.
Reduced Downtime Upgrade آنلاین و آفلاین
RDU در 9.1 میتواند برای نسخههای آتی 9.1.x از Online Depot استفاده کند؛ روش Offline با ISO Mount شده نیز باقی مانده است. این نکته برای دیتاسنترهای ایران مهم است: معماری کاملاً متصل شرط فنی RDU نیست، اما تیم باید ISO و Binary صحیح را از Broadcom Support Portal و با Entitlement معتبر دریافت و به محیط منتقل کند. محدودیت دسترسی به Portal، Download Token و Mirror داخلی باید پیش از شروع Upgrade حل شود، نه وسط Change Window.
vCenter 9.1 همچنین API جدیدی برای اعلام Maintenance برنامهریزیشده یا جاری ارائه میکند. Reverse Proxy مبتنی بر Envoy میتواند پاسخ 503 را همراه تخمین زمان پایان نگهداری برگرداند. ابزارهای Automation میتوانند بهجای تفسیر یک خطای مبهم، Maintenance را تشخیص دهند و Retry منطقی انجام دهند.
تغییر اندازه vCenter با یک API
API با مسیر deployment/size و متد PATCH امکان Scale-up منابع Compute و Disk آپلاینس vCenter را فراهم میکند؛ اعمال تغییر به Reboot نیاز دارد. مزیت اصلی این قابلیت، تکرارپذیری است. در چند vCenter، میتوان ظرفیت را بر مبنای Profile استاندارد و از مسیر API کنترل کرد، ولی انتخاب Size همچنان باید با Inventory، نرخ Task، Backup Concurrency و راهنمای Sizing تطبیق داده شود.
Hardware Version آپلاینس vCenter
در RDU از 8.x یا 9.0.x به 9.1، چون آپلاینس جدید ساخته میشود، Hardware Version از 10 به 17 ارتقا مییابد. در In-place Update از 9.0.x، این تغییر خودکار نیست و باید با خاموشکردن vCenter انجام شود. KB رسمی 403995 تأکید میکند Hardware Version باید دقیقاً 17 باشد؛ ارتقای بالاتر میتواند Inventory را در VCF Operations بهاشتباه 9.0.x نشان دهد.
ESX 9.1؛ Maintenance کوتاهتر و Lifecycle قابلاعتمادتر
Live Patch پیشفرض، اما نه برای هر Patch
در Clusterهای 9.1، Live Patch بهصورت پیشفرض برای Payload سازگار استفاده میشود. اگر Patch قابلیت Live Patch نداشته باشد، رفتار عادی بازگشت به Maintenance Mode و Reboot است. Admin میتواند حالت Enforce را انتخاب کند؛ در آن حالت Remediation برای میزبانی که Reboot لازم دارد مسدود میشود. این تنظیم برای Compliance سختگیرانه مفید است، اما اگر بدون کنترل Patch Matrix فعال شود ممکن است Cluster را روی نسخه قدیمی نگه دارد.
نسخه 9.1 Live Patch را با سرورهای TPM-enabled سازگار کرده و دامنه بیشتری از vmkernel، سرویسها و Daemonهای vSAN و Storage را پوشش میدهد. بااینحال عبارت «بدون Downtime» به معنی بینیازی از DRS، ظرفیت آزاد و برنامه Rollback نیست؛ Patch باید رسماً Live-Patch Capable باشد.
Integrity برای Imageهای Lifecycle
Image Definitionهای صادرشده از vSphere Lifecycle Manager اکنون SHA-256 Checksum دارند. در انتقال Image میان دو vCenter، تیم میتواند یکپارچگی تعریف Image را در مبدأ و مقصد مقایسه کند. این Checksum مربوط به تعریف Image است و نباید با Hash مستقل همه VIBها اشتباه شود.
vLCM در vSAN Clusterها حتی بدون Hardware Support Manager میتواند Driver و Firmware جاری Device را گزارش و در سطح اولیه با HCL اعتبارسنجی کند. برخی Deviceها بدون HSM قادر به گزارش Firmware نیستند؛ بنابراین این قابلیت جایگزین Integration کامل Vendor یا کنترل Hardware Compatibility List نمیشود.
Zero-Touch Provisioning و Elastic Provisioning
Zero-Touch Provisioning روی پایه Auto Deploy ساخته شده، اما از UEFI HTTP/S Boot استفاده میکند و به TFTP خارجی نیاز ندارد. سرور جدید با Boot URL به vCenter هدایت میشود؛ Image و Configuration بر اساس Cluster مقصد تعیین میشوند. Secure Boot و TPM نیز در طراحی مدرن آن در نظر گرفته شدهاند. اگر UEFI برای Boot یک IP ثابت ندارد، DHCP همچنان لازم است.
در Cluster دارای vSphere Configuration Profile، میزبان با Desired State همان Cluster آماده میشود. اگر VCP کامل نشده باشد، میتوان میزبان را به Cluster بدون VCP Boot کرد و با تنظیمات پیشفرض Join داد. در محیط Production بهتر است این مسیر اضطراری با Baseline امنیتی، VLAN، NTP، DNS، Certificate و Storage از قبل مستندسازی شود.
vSphere Configuration Profiles؛ Desired State در سطح Cluster
VCP در 9.1 فقط جانشین Host Profile نیست. این مکانیزم Image، تنظیمات Host، Distributed Switch و حتی Claim کردن NVMe برای Memory Tiering را در Desired State جمع میکند. هنگام اضافهشدن Host جدید، مشخصههای ویژه مانند IP استخراج و در بخش Host-specific Profile قرار میگیرند. Remediation خودکار بهطور پیشفرض خاموش است و میتواند در سطح vCenter یا Cluster فعال شود.
برای vSAN، Remediation به Maintenance Mode Policy و دسترسپذیری Objectها احترام میگذارد. این یکپارچگی احتمال Drift را کم میکند، اما جای Capacity Check را نمیگیرد. پیش از Remediation باید FTT، Resync Traffic و ظرفیت آزاد بررسی شود. جزئیات ذخیرهسازی در مقاله vSAN 9.1 جداگانه تحلیل شده است.
Performance در vSphere 9.1
Enhanced NVMe Memory Tiering
Memory Tiering از NVMe پرسرعت بهعنوان Tier دوم حافظه استفاده میکند: دادههای داغ در DRAM میمانند و صفحات سردتر به NVMe منتقل میشوند. هدف، افزایش ظرفیت مؤثر حافظه و بالا بردن تراکم VM بدون خرید همان مقدار DRAM است. در 9.1، NVMe از طریق VCP Claim میشود و یک Device اضافی را میتوان برای Software Mirroring اختیاری اختصاص داد.
این قابلیت «تبدیل SSD به RAM همسرعت» نیست. نتیجه به Latency و Endurance دیسک، Working Set برنامه، NUMA، فشار Memory و Hardware Compatibility وابسته است. برای Database یا VDI باید Pilot با نسبت واقعی Hot/Cold و ابزارهای Monitoring اجرا شود. اعداد TCO اعلامشده Broadcom مبتنی بر آزمونها و فرضیات داخلیاند و نباید بدون مدل ظرفیت محلی وارد Business Case شوند.
Topology-aware Scheduling
در سرورهای چند Socket و معماریهایی مانند SNC، فاصله منطقی CPU و Memory اهمیت زیادی دارد. Scheduler جدید هزینه Page Migration و Topology پردازنده را در Placement لحاظ میکند تا Overpacking یک Node و جابهجایی غیرضروری Page کاهش یابد. این قابلیت برای VMهای بزرگ و Workloadهای حساس به NUMA مهمتر از VMهای کوچک عمومی است.
Parallel Processing of DRS vMotion
DRS در گذشته بخشی از Migrationها را بهصورت Batchهای متوالی اجرا میکرد. در 9.1، پردازش موازی vMotionها میتواند Evacuation و Rebalance Cluster را سریعتر کند. موازیسازی به معنی ظرفیت نامحدود نیست؛ Uplink، Storage Backend و شبکه vMotion باید Burst همزمان را تحمل کنند. در محیطهای 10GbE اشباعشده، افزایش Concurrency بدون QoS میتواند نتیجه معکوس بدهد.
Scale در vCenter
Broadcom برای vCenterهای Large و X-Large افزایش تا 25 درصد Operations per Minute و Backup Concurrency حدود 500 تا 1000 عملیات را، بسته به Size، اعلام کرده است. File Transferها Thread اختصاصی دارند تا Taskهای دیگر کمتر آسیب ببینند. این ارقام سقف تضمینشده برای هر محیط نیستند؛ Extensionها، Latency دیتابیس، Plug-inها و الگوی Backup باید در آزمون ظرفیت لحاظ شوند.
Certificate Management و امنیت
Certificateهای مدیریتشده توسط VMCA در 9.1 خودکار تمدید میشوند: TLS vCenter پنج روز و Certificate میزبان ESX سی روز پیش از انقضا. آستانه ESX از Advanced Setting با نام vpxd.certmgmt.certs.autoRenewThreshold قابل تغییر است. Certificate صادرشده از CA خارجی خودکار تمدید نمیشود و همچنان مسئولیت PKI سازمان است.
اگر Root Certificate مربوط به VMCA کمتر از یک سال اعتبار داشته باشد، Upgrade vCenter میتواند Root و Solution User Certificateهای وابسته را تجدید کند؛ اما TLS Certificateهای vCenter و ESX در همان عملیات الزاماً تمدید نمیشوند. قبل از Upgrade، Chain اعتماد سرویسهایی مانند Backup، Monitoring و Automation باید آزمایش شود.
معماری عملی vSphere 9.1 در VVF و VCF
در VVF 9.1، هسته شامل ESX، vCenter، vSAN و قابلیتهای Operations متناسب با Entitlement است. VCF 9.1 همین پایه را با NSX، Automation، Lifecycle سراسری و سرویسهای مدیریت توسعه میدهد. VCF Management Services در VCF اجباری و در استقرار VVF اختیاری است؛ License Server جدید در هر دو مدل اجباری است.
این تمایز برای طراحی اهمیت دارد. تیمی که فقط چند Cluster مستقل میخواهد، نباید از روی قابلیتهای کامل VCF نتیجه بگیرد همه آنها با VVF قابل استفادهاند. در مقابل، سازمانی که چند Workload Domain، NSX و Self-Service دارد، ارتقای صرف vCenter و ESX را نمیتواند مستقل از توالی Lifecycle پلتفرم انجام دهد. برای مدیریت یکپارچه، مقاله VCF Operations 9.1 را بخوانید.
سناریوی واقعی: ارتقای یک کلاستر بانکی
فرض کنید یک بانک سه Cluster دارد: Core Banking، VDI و Kubernetes. هدف، کاهش پنجره Patch و افزایش ظرفیت حافظه است. مسیر منطقی چنین است:
- Compatibility سختافزار، Firmware، Driver، Backup و Solutionهای جانبی با 9.1 بررسی شود.
- Entitlement و VCF License Server قبل از ارتقای Hostها آماده شود.
- vCenter با RDU ارتقا یابد؛ در محیط ایزوله ISO از Depot داخلی Mount شود.
- Hardware Version آپلاینس بررسی شود؛ در In-place Update از 9.0 آن را دقیقاً به 17 برسانند.
- یک Cluster کمریسک با Image جدید، VCP و Live Patch Pilot شود.
- Memory Tiering ابتدا روی VDI و با اندازهگیری Latency، Endurance و Page Migration آزمایش شود؛ نه مستقیماً روی Core Banking.
- Concurrency مربوط به DRS vMotion با ظرفیت شبکه و Storage تنظیم و سپس Rollout مرحلهای انجام شود.
برای Cluster Kubernetes، هماهنگی Supervisor و VKS بخشی جدا از Upgrade است. مقاله VKS 3.6 در VCF 9.1 محدودیتهای آن را پوشش میدهد.
نیازمندیها و محدودیتهایی که باید قبل از ارتقا بررسی شوند
- ترتیب ارتقا: در VCF/VVF 9.1 توالی Componentها اجباری است. vCenter و ESX را خارج از Workflow پشتیبانیشده بهصورت مستقل ارتقا ندهید.
- Back-in-Time Restriction: بعضی Buildهای جدید 8.0 U3 ممکن است از Build اولیه 9.1 جدیدتر تلقی شوند و Pre-check را متوقف کنند؛ Matrix و KB جاری را کنترل کنید.
- License Server: فرمت و امضای License در 9.1 تغییر کرده است. KB 441178 هشدار موقت License Assignment بعد از Reboot میزبان را ثبت کرده؛ اعتبار واقعی Host را در VCF Operations بررسی کنید.
- Hardware Compatibility: TPM، UEFI HTTP/S، NVMe Memory Tiering و Intel QAT به سختافزار و Firmware سازگار نیاز دارند.
- Offline Depot: Image و Add-onهای Vendor باید پیش از Change Window دانلود، Hash و در Repository داخلی نگهداری شوند.
- Backup و Restore: قبل از RDU یا In-place Upgrade، File-based Backup معتبر vCenter و بازیابی آزمایشی ضروری است.
استفاده از vSphere 9.1 در ایران
از نظر فنی، ESX و vCenter در دیتاسنتر On-Premises و حتی شبکه Air-Gapped قابل پیادهسازیاند. مانع اصلی معمولاً Compute نیست؛ Entitlement معتبر، دسترسی به Broadcom Support Portal، دریافت Binary و Patch، Hardware Compatibility و Support رسمی است. استفاده از فایلهای بازنشرشده ناشناس ریسک Supply Chain، نبود Hash قابل اعتماد و شکست Lifecycle را ایجاد میکند.
برای محیط آفلاین باید یک ایستگاه متصل مجاز، فرایند انتقال کنترلشده، Repository داخلی، نگهداری ISO و Component Metadata و تقویم همگامسازی تعریف شود. Download Token را Secret عملیاتی در نظر بگیرید و آن را در Script، Screenshot یا مخزن عمومی قرار ندهید. License Server محلی وابستگی اجرای روزمره به اینترنت را کم میکند، اما جای Entitlement قانونی و دسترسی به Patch را نمیگیرد.
vSphere 9.1 برای چه سازمانی ارزش ارتقا دارد؟
اگر پنجره Patch کوتاه، استقرار پیوسته میزبانهای جدید، کنترل Drift، تراکم حافظه یا Clusterهای بسیار بزرگ مسئله واقعی شماست، 9.1 ارزش Pilot دارد. اگر سختافزار قدیمی است، Solution جانبی هنوز Certification ندارد یا دسترسی مطمئن به Binary و Support وجود ندارد، ماندن موقت روی آخرین Build پشتیبانیشده 8.x میتواند تصمیم کمریسکتری باشد.
در برنامه آموزش مجازی سازی و آموزش VMware، بهتر است یادگیری از نصب ESX فراتر برود و Image-based Lifecycle، VCP، Certificate، API و مدل VVF/VCF را در بر بگیرد. برای معماران، ترکیب آموزش VVF با آموزش VCF تصویر دقیقتری از مرز Compute و Private Cloud میسازد.
جمعبندی فنی
ارزش vSphere 9.1 در یک قابلیت منفرد نیست؛ در پیوند بین Maintenance، Desired State و Performance است. Quick Patch و RDU وقفه vCenter را کم میکنند، Live Patch دامنه Patch بدون Reboot را گسترش میدهد، Zero-Touch و VCP ورود Host را استاندارد میکنند و Memory Tiering و DRS موازی برای سختافزارهای جدید ظرفیت بیشتری آزاد میکنند.
اما هر چهار محور شرط دارند: Payload باید Live-Patch Capable باشد، Certificate خارجی خودکار تمدید نمیشود، Memory Tiering جای DRAM را بدون هزینه Performance نمیگیرد و Zero-Touch بدون طراحی DHCP، UEFI، شبکه و Desired State کامل نیست. ارتقای موفق از یک Lab واقعی، Compatibility Check و Runbook بازگشت شروع میشود؛ نه از کلیک روی Update.
پرسشهای متداول درباره vSphere 9.1
آیا ESXi در نسخه 9.1 حذف شده است؟
خیر. Broadcom در اسناد جدید بیشتر از نام ESX 9.1 استفاده میکند، اما همان Hypervisor نسل vSphere است. تغییر نام به معنی حذف لایه Bare-Metal نیست.
آیا همه Patchهای ESX 9.1 بدون Reboot نصب میشوند؟
خیر. فقط Payloadهایی که Live Patch را پشتیبانی میکنند بدون چرخه معمول Maintenance و Reboot اعمال میشوند. برای سایر Patchها، رفتار پیشفرض بازگشت به روش معمول است.
آیا Quick Patch همان Reduced Downtime Upgrade است؟
خیر. Quick Patch برای تغییر هدفمند Binaryها و Security Fixهای مناسب طراحی شده است. RDU روش Upgrade/Patch با ساخت و جابهجایی به آپلاینس vCenter جدید است.
آیا Memory Tiering روی هر NVMe کار میکند؟
خیر. Hardware Compatibility، Performance و Endurance Device باید بررسی شود. نتیجه نیز به Working Set برنامه وابسته است و باید با Pilot اندازهگیری شود.
آیا vSphere 9.1 را میتوان بدون اینترنت اداره کرد؟
بله، روشهای Offline برای RDU و Lifecycle وجود دارد؛ ولی دریافت قانونی Binaryها، Metadata، Patchها و Entitlement باید از قبل حل و Repository داخلی ساخته شود.
آیا ارتقا مستقیم از vSphere 8 به 9.1 ممکن است؟
مسیرهای رسمی برای Deploymentهای vCenter و ESX نسخه 8.x وجود دارد، اما Build دقیق، Solutionهای جانبی و توالی VCF/VVF باید با Upgrade Guide و Interoperability بررسی شود. وجود برخی Buildهای جدید 8.0 U3 میتواند Back-in-Time Restriction ایجاد کند.
