در نسخههای قدیمیتر، تیم زیرساخت برای پاسخ به یک سؤال ساده مانند «چرا این کلاستر کند شده است؟» ناچار بود بین vCenter، Aria Operations، SDDC Manager، ابزارهای لاگ و گاهی چند داشبورد دیگر جابهجا شود. VCF Operations 9.1 تلاش میکند این پراکندگی را به یک مدل عملیاتی واحد تبدیل کند؛ مدلی که فقط مانیتورینگ نیست و از مشاهده سلامت و ظرفیت تا Lifecycle، لایسنس، Certificate، Password و مدیریت Fleet را پوشش میدهد.
VCF Operations ادامه VMware Aria Operations است، اما صرفاً نسخهای با نام جدید محسوب نمیشود. در VMware Cloud Foundation 9، نقش آن از یک پلتفرم Monitoring و Capacity Management به «اتاق فرمان Private Cloud» توسعه پیدا کرد. نسخه 9.1 این مسیر را با معماری VCF Management Services، مقیاس بالاتر، Observability سریعتر و اتصال عمیقتر میان عملیات، امنیت و Lifecycle کاملتر میکند.
این مقاله سومین بخش از مجموعه فنی VCF 9.1 ابرکلاس است. برای درک تغییر نامها و مسیر مهاجرت محصولات قدیمی، ابتدا مقاله بعد از Aria؛ نقشه مدیریت VCF 9.1 را بخوانید. در این مطلب تمرکز فقط روی خود VCF Operations، معماری آن، تفاوت نسخههای 8، 9 و 9.1 و ملاحظات پیادهسازی است.
VCF Operations 9.1 دقیقاً چیست؟
VMware Cloud Foundation Operations لایه مرکزی مدیریت و عملیات VCF است. این محصول دادههای زیرساخت را جمعآوری و تحلیل میکند، اما نقش آن به نمودارهای Performance محدود نیست. VCF Operations در معماری جدید چند حوزه را کنار هم قرار میدهد:
- پایش سلامت، Performance، Capacity و Availability زیرساخت؛
- تحلیل Cost، Pricing، Showback و Chargeback؛
- Fleet Management برای مدیریت چند VCF Instance و Workload Domain؛
- برنامهریزی Patch و Upgrade و اجرای Pre-checkهای Lifecycle؛
- مدیریت Certificate، Password و License در سطح Fleet؛
- Diagnostics و Findings برای مشکلات شناختهشده، VMSA، CVE و KB؛
- مشاهده وضعیت vCenter، ESX، vSAN، NSX و VKS از یک کنسول؛
- توسعه Monitoring با Management Packها و APIها.
بنابراین اگر در نسل Aria، Operations Manager را بیشتر یک ابزار مانیتورینگ میدیدیم، در VCF 9.1 باید آن را نقطه ورود به عملیات روزمره Private Cloud در نظر بگیریم.
رابطه VCF Operations با اجزای دیگر VCF
نام محصولات جدید ممکن است باعث شود VCF Operations با VCF Operations for Networks، VCF Operations for Logs یا VCF Operations HCX اشتباه گرفته شود. خود VCF Operations پلتفرم اصلی و کنسول مرکزی است؛ محصولات دیگر قابلیتهای تخصصی شبکه، لاگ یا جابهجایی Workload را ارائه میکنند و به تجربه عملیاتی یکپارچه متصل میشوند.
| جزء | نقش اصلی | رابطه با VCF Operations |
|---|---|---|
| VCF Operations | Fleet، Health، Performance، Capacity، Cost و Lifecycle | کنسول مرکزی مدیریت و عملیات |
| VCF Management Services | Runtime مشترک سرویسهای Fleet Lifecycle، Depot، License، Log و Real-time Data | زیرساخت سرویسهای مدیریتی در 9.1 |
| VCF Operations Cloud Proxy | جمعآوری داده و اتصال VCF Instanceها به VCF Operations | مسیر ارتباطی الزامی در معماری و Upgrade 9.1 |
| VCF Log Management | تجمیع، جستوجو و Forward کردن Log | رابط Log در تجربه VCF Operations ادغام میشود |
| VCF Operations for Networks | Flow، Path، Application Discovery و تحلیل شبکه | محصول تخصصی شبکه با Lifecycle تحت مدیریت VCF |
| VCF Automation | Self-Service، IaaS، Governance و Provisioning | مصرفکننده سرویسهای مشترک و دادههای عملیاتی VCF |
تغییر معماری مهم در نسخه 9.1: VCF Management Services
در VCF 9.0 قابلیتهای Fleet Management وارد VCF Operations شدند، اما بخشی از سرویسهای کنترلی هنوز روی Applianceهای مستقل اجرا میشدند. در نسخه 9.1، Broadcom یک Services Runtime مشترک با عنوان VCF Management Services معرفی کرده است. سرویسهایی مانند Fleet Lifecycle، SDDC Lifecycle، Software Depot، License Service، Log Management و Real-time Data روی این Runtime میزبانی میشوند.
این تغییر یک جابهجایی ظاهری در منوها نیست. در Upgrade از VCF 9.0.x به 9.1، دادههای Fleet Management به Management Services منتقل میشوند و Fleet Management Appliance قدیمی پس از تکمیل انتقال، از مدار خارج و خاموش میشود. نتیجه این معماری، Lifecycle یکپارچهتر و وابستگی کمتر به مجموعهای از Applianceهای پراکنده است.
آیا VCF Operations در 9.1 حذف یا کوچک شده است؟
خیر. VCF Operations همچنان رابط و موتور اصلی تجربه عملیاتی است. Management Services زیرساخت اجرای سرویسهای مشترک را فراهم میکند. این دو را نباید جایگزین یکدیگر دانست: کاربر عملیات را از VCF Operations مدیریت میکند، درحالیکه بخشی از Workflowها و سرویسهای Lifecycle در Runtime جدید اجرا میشوند.
مقایسه Aria Operations 8، VCF Operations 9 و 9.1
| موضوع | Aria Operations 8.18 | VCF Operations 9.0 | VCF Operations 9.1 |
|---|---|---|---|
| جایگاه محصول | پلتفرم Monitoring، Capacity و Cost | کنسول مرکزی Operations و Fleet | اتاق فرمان Fleet با Management Services مشترک |
| Lifecycle | وابسته به Aria Suite Lifecycle و SDDC Manager | تجمیع Lifecycle در UI عملیات با Fleet Appliance | انتقال سرویسهای Lifecycle به Management Services Runtime |
| مقیاس مدیریت ESXi | وابسته به Sizing و معماری Aria | حدود نصف ظرفیت اعلامشده برای 9.1 | تا ۵۰۰۰ میزبان ESXi در یک Instance طبق اعلام Broadcom |
| ارتقای موازی | مدل Fleet یکپارچه نسل 9 را ندارد | ظرفیت پایینتر؛ Broadcom برای 9.1 افزایش چهاربرابری اعلام کرده است | تا ۲۵۶ کلاستر بهصورت موازی |
| Diagnostics | Alert و Troubleshooting سنتی | Health و Findings یکپارچه VCF | Public API برای Findings و یکپارچگی با Ticketing و Risk Management |
| Observability بلادرنگ | Collection Interval سنتی | دید یکپارچهتر Metrics، Logs و Flows | Collection قابل تنظیم تا ۲ ثانیه برای ESX Host |
| Log Management | Aria Operations for Logs بهصورت محصول مستقل | قابلیتهای جدید Log در مسیر VCF | رابط Log Management در VCF Operations ادغام شده است |
| هزینه Kubernetes | پوشش محدودتر | کشف و پایش Supervisor و Kubernetes | Showback، Chargeback و Pricing برای VKS |
| Integration | Management Packهای سنتی | Management Pack و API | Management Pack Builder بدون کدنویسی، Prometheus MP و APIهای AI-ready |
مهمترین قابلیتهای جدید VCF Operations 9.1
مقیاس مدیریت تا ۵۰۰۰ میزبان ESXi
Broadcom اعلام کرده است یک Instance از VCF Operations 9.1 میتواند تا ۵۰۰۰ میزبان ESXi را مدیریت کند؛ دو برابر مقیاس نسخه قبلی. این عدد برای سازمانهای چندسایتی و Service Providerها مهم است، اما به معنی حذف Sizing نیست. تعداد Object، Metric، Retention، Management Pack و HA Mode همچنان روی اندازه Cluster و Storage موردنیاز اثر میگذارند.
ارتقای موازی تا ۲۵۶ کلاستر
ظرفیت Parallel Upgrade در 9.1 چهار برابر شده و تا ۲۵۶ کلاستر را پوشش میدهد. کاربرد واقعی این قابلیت در Fleetهای بزرگ است؛ جایی که اجرای ترتیبی Maintenance Window را بیش از حد طولانی میکند. افزایش Parallelism نباید بدون بررسی ظرفیت vCenter، شبکه، Depot و توان عملیاتی تیم پشتیبانی فعال شود.
Public API برای Health and Diagnostics Findings
در نسخه 9.1 یافتههای Diagnostics از طریق API عمومی در دسترس قرار میگیرند. سازمان میتواند Findings را وارد سیستم Ticketing، CMDB، Risk Management یا Pipeline داخلی خود کند. این قابلیت مرز میان «دیدن Alert» و «ساخت فرآیند پاسخگویی قابل اندازهگیری» را از بین میبرد.
Real-time Observability با بازه دوثانیهای
VCF Operations 9.1 امکان جمعآوری Metric از ESX Host را با Interval قابل تنظیم تا دو ثانیه فراهم میکند. این بازه برای بررسی Spikeهای کوتاه Performance و Workloadهای حساس مفید است، اما استفاده گسترده از آن حجم داده، Retention و نیاز پردازشی را افزایش میدهد. فعالسازی باید هدفمند و برای Scope محدود انجام شود.
Capacity و FinOps برای Memory Tiering و VKS
نسخه 9.1 برای NVMe Memory Tiering پیشنهاد ظرفیت و What-If Analysis ارائه میکند تا تأثیر جابهجایی صفحات سرد حافظه از DRAM به NVMe بر Density و Cost قابل برآورد باشد. در حوزه Kubernetes نیز هزینه VKS برای Pricing، Showback و Chargeback قابل مشاهده میشود. پشتیبانی از چارچوب FOCUS، خروجی هزینه را به مدل استانداردتری نزدیک میکند.
Management Pack Builder و Prometheus
Management Pack Builder امکان ساخت Integrationهای شخص ثالث را بدون توسعه کامل یک Management Pack سنتی فراهم میکند. همچنین اتصال مستقیم به Prometheus Server Management Pack، دادههای زیرساخت و Application را به تجربه Observability نزدیکتر میکند. این قابلیت به معنی پشتیبانی خودکار از هر Vendor نیست؛ کیفیت Integration به API و Data Model منبع وابسته است.
Security Posture و Advanced Cyber Compliance
VCF Operations وضعیت VMSA، CVE، Encryption، Confidential Computing و یافتههای امنیتی را در Dashboardهای SecOps نمایش میدهد. قابلیت VMware Advanced Cyber Compliance برای Assessment و Remediation برخی Benchmarkها یک Advanced Service جداگانه است و نباید آن را جزو قابلیت پایه تمام لایسنسهای VCF فرض کرد.
نیازمندیهای معماری و استقرار
Cloud Proxy فقط یک Collector اختیاری نیست
در Upgrade به 9.1، Cloud Proxy نقش ارتباطی میان VCF Operations، SDDC Manager و VCF Management Services را دارد. Broadcom تصریح کرده است Adapter مربوط به VCF Instance باید به Cloud Proxy سالم یا Collector Group اختصاصیافته اشاره کند؛ استفاده از Local Collector میتواند Validation استقرار Management Services را متوقف کند.
برای محیطهای بزرگ، Cloud Proxy را بر مبنای Site، Network Boundary و حجم Object طراحی کنید. قرار دادن همه Adapterها روی یک Proxy بدون HA یا Collector Group، یک نقطه شکست و Bottleneck ایجاد میکند.
DNS و Certificate باید پیش از Deploy آماده باشند
برای Nodeهای VCF Operations و Cloud Proxy به FQDN یکتا، رکورد Forward و Reverse و دسترسی صحیح به DNS نیاز است. Knowledge Baseهای Broadcom نشان میدهند بستهبودن TCP/53، ناقصبودن PTR Record یا نبودن FQDN در SAN گواهی میتواند Deployment را در مرحله OVA Installation یا First Boot متوقف کند. تست UDP DNS بهتنهایی کافی نیست؛ مسیر TCP/53 نیز باید بررسی شود.
Sizing را از تعداد Host حدس نزنید
ورودیهای اصلی Sizing شامل تعداد VM، Host، Datastore، Metric، Management Pack، Retention، Availability Mode و رشد چندساله است. عدد ۵۰۰۰ Host سقف مقیاس اعلامشده است، نه نسخه پیشنهادی برای هر Cluster. برای Production باید Sizing Tool و Detailed Design رسمی همان نسخه مبنا قرار گیرد.
مسیر استقرار و Upgrade
اگر Aria Operations 8.x دارید
- نسخه Aria Operations را به 8.18 و Patch موردنیاز برسانید.
- Backup و Snapshot موقت مورد تأیید Workflow را تهیه کنید.
- با فایل PAK مربوط به VCF Operations 9.1، Operations Cluster را Upgrade کنید.
- Cloud Proxy را Deploy یا به Unified State منتقل و Adapterهای VCF را روی آن تنظیم کنید.
- پس از Upgrade اجزای لازم، VCF Management Services را Deploy کنید.
- انتقال Lifecycle و Fleet Data را کنترل و Health Check نهایی اجرا کنید.
اگر VCF Operations 9.0.x دارید
ابتدا VCF Operations و Cloud Proxy به 9.1 ارتقا پیدا میکنند. سپس SDDC Manager 9.1 و Management Services مستقر میشوند. دادههای Fleet Management به Runtime جدید منتقل شده و Appliance قبلی پس از موفقیت انتقال خاموش میشود. بررسی Unified بودن Cloud Proxyها یکی از Pre-checkهای مهم این مسیر است.
اگر استقرار جدید VCF 9.1 دارید
VCF Operations در VCF 9.x جزء اجباری معماری است. در Greenfield Deployment معمولاً VCF Installer و Workflowهای Fleet Lifecycle، Nodeهای VCF Operations و Cloud Proxy را براساس Design انتخابشده ایجاد میکنند. FQDN، Certificate، Placement، IP Pool و دسترسی Depot باید قبل از اجرای Wizard قطعی شده باشند.
سناریوی واقعی: عملیات یک Fleet چندسایتی
فرض کنید سازمان سه دیتاسنتر، ۲۵۰ Host و چند Workload Domain دارد. در مدل سنتی، هر Site ممکن است Dashboard، Upgrade Plan و روش مدیریت Certificate متفاوتی داشته باشد. در VCF Operations 9.1، تیم مرکزی میتواند Health کل Fleet را ببیند، Findingهای مرتبط با VMSA را استخراج کند، Upgrade Plan بسازد و Certificateهای چند Component را بهصورت Bulk مدیریت کند.
برای این سناریو یک معماری منطقی شامل VCF Operations Cluster با HA، Cloud Proxy یا Collector Group در هر Site، Management Services در VCF Instanceهای مربوط، DNS دوطرفه و Depot متناسب با Connected یا Disconnected Mode است. تیم عملیات نیز باید Alert Ownership، Maintenance Window، Retention و اتصال Ticketing را پیش از Go-Live تعریف کند. نصب Appliance بدون این فرآیندها فقط ابزار جدیدی به مجموعه اضافه میکند.
محدودیتها و نکات طراحی
- VCF Operations جایگزین کامل vCenter نیست؛ عملیات اختصاصی VM و Cluster همچنان در vSphere Client انجام میشوند.
- VCF Operations for Networks و Log Management اجزای تخصصی مستقلاند؛ یکسانبودن نام به معنی یک Appliance واحد نیست.
- Collection Interval دوثانیهای باید محدود و هدفمند باشد، وگرنه هزینه پردازش و Retention افزایش مییابد.
- Management Packهای قدیمی Aria باید از نظر Compatibility با 9.1 بررسی شوند.
- Advanced Cyber Compliance یک Advanced Service است و به Entitlement جدا نیاز دارد.
- در Brownfield Upgrade، جایگاه VCF Operations VM و Cloud Proxy نسبت به Management vCenter باید با Workflow مقصد سازگار باشد.
استفاده از VCF Operations 9.1 در ایران و محیط آفلاین
از نظر فنی، VCF 9.1 برای Connected و Disconnected Deployment مسیر رسمی دارد. در حالت Connected، Software Depot و Licensing با سرویسهای Broadcom ارتباط برقرار میکنند و License File بهصورت خودکار بهروزرسانی میشود. در 9.1 برای اتصال Online Depot از Activation Code استفاده میشود، نه Download Token نسل قبلی.
در شبکههای محدود یا کاملاً ایزوله میتوان از Disconnected Depot استفاده کرد و Binaryها را در یک Depot داخلی آماده کرد. بااینحال Offline بودن، نیاز به Entitlement معتبر، دریافت قانونی Binary و فایلهای لایسنس را حذف نمیکند. محدودیت حساب، منطقه، پرداخت یا صادرات باید بهصورت موردی با Broadcom، Partner مجاز و مشاور حقوقی بررسی شود؛ مستندات فنی عمومی Broadcom تضمین مشخصی درباره دسترسی از ایران ارائه نمیکنند.
برای پیادهسازی داخل ایران، مدل عملیتر معمولاً Disconnected Mode، Depot داخلی، DNS/NTP داخلی، فرآیند کنترلشده انتقال Binary و نگهداری نسخههای سازگار است. وابستگیهای Connected Mode و URLهای لازم نیز باید قبل از طراحی قطعی توسط تیم امنیت و شبکه آزمایش شوند.
VCF Operations در مسیر یادگیری VMware
در یک مسیر درست آموزش VMware، یادگیری VCF Operations باید پس از تسلط بر vSphere، vSAN و مفاهیم پایه Monitoring انجام شود. دانشجو باید بتواند رابطه Object، Metric، Alert، Symptom، Policy، Capacity و Cost را درک کند و سپس به Fleet Management و Lifecycle برسد.
برای آموزش مجازی سازی در سطح عملیاتی، صرف ساخت Dashboard کافی نیست. طراحی Cloud Proxy، Troubleshooting Adapter، تنظیم Policy، Capacity Planning، Upgrade Pre-check و مدیریت Disconnected Depot مهارتهایی هستند که یک VVF Admin یا VCF Admin در محیط واقعی به آنها نیاز دارد. در مسیر آموزش VVF تمرکز بیشتر روی عملیات vSphere و vSAN است؛ در آموزش VCF مدیریت Fleet، NSX، Automation، Log و Lifecycle نیز به Scope اضافه میشوند.
جمعبندی فنی
VCF Operations 9.1 را نباید Aria Operations با پوستهای جدید دانست. نسخه 9.0 آن را به مرکز Fleet و Lifecycle تبدیل کرد؛ نسخه 9.1 با VCF Management Services، مقیاس بیشتر، Upgrade موازی، Diagnostics API، Observability سریع و FinOps برای Workloadهای مدرن این نقش را تثبیت میکند.
ارزش واقعی محصول زمانی دیده میشود که Monitoring، Lifecycle، Security Findings، Capacity و Cost در یک Runbook مشترک قرار گیرند. اگر VCF Operations فقط برای نمایش نمودار نصب شود، بخش بزرگی از مزیت معماری 9.1 استفاده نخواهد شد.
سؤالات متداول
آیا VCF Operations همان Aria Operations است؟
هسته Monitoring و Analytics آن ادامه Aria Operations است، اما در VCF 9 نقشهای Fleet Management، Lifecycle، Licensing، Certificate و مدیریت یکپارچه VCF به آن افزوده شدهاند.
آیا VCF Operations در VCF 9.1 اجباری است؟
بله. طبق راهنمای رسمی Upgrade، VCF Operations در VCF 9.x جزء اجباری است و اگر در محیط قبلی وجود نداشته باشد باید در مسیر ارتقا Deploy شود.
آیا VCF Management Services جای VCF Operations را گرفته است؟
خیر. Management Services Runtime اجرای سرویسهای مشترک Lifecycle، Depot، License، Log و Data را میزبانی میکند؛ VCF Operations همچنان کنسول و پلتفرم اصلی عملیات است.
برای Upgrade از Aria Operations چه نسخهای لازم است؟
محیط باید پیش از ارتقا به VCF Operations 9.1 به Aria Operations 8.18 و Patchهای موردنیاز مسیر ارتقا رسیده باشد.
آیا Cloud Proxy در 9.1 ضروری است؟
برای Integration میان VCF Operations، VCF Instance، SDDC Manager و Management Services ضروری است. Adapterهای VCF باید روی Cloud Proxy سالم یا Collector Group مناسب قرار گیرند.
آیا VCF Operations 9.1 در محیط بدون اینترنت کار میکند؟
بله، Disconnected Depot مسیر رسمی است؛ اما دریافت Binary، Entitlement و License معتبر همچنان باید خارج از محیط آفلاین انجام و سپس با فرآیند کنترلشده منتقل شود.
