در یک Private Cloud واقعی، ساخت VM فقط شروع کار است. تیم زیرساخت باید مشخص کند چه کسی اجازه درخواست سرویس دارد، سرویس در کدام Zone قرار بگیرد، چه سهمیهای مصرف شود، هزینه آن چگونه دیده شود و پس از ایجاد، چه عملیات Day-2 در اختیار مصرفکننده باشد. VCF Automation 9.1 این لایه Self-Service و Governance را میسازد؛ VCF Operations Orchestrator 9.1 نیز موتور Workflow و Extensibility است که فرایندهای اختصاصی سازمان را اجرا میکند.
این تفکیک اهمیت دارد، چون تغییر نامهای زنجیره vRealize و Aria ممکن است این تصور اشتباه را ایجاد کند که Orchestrator با VCF Automation ادغام و حذف شده است. چنین نیست. این دو محصول با هم کار میکنند، اما نقش یکسانی ندارند. در این مقاله معماری، قابلیتهای نسخه 9.1، مسیر مهاجرت، محدودیتها و سناریوی عملی آنها را بررسی میکنیم.
VCF Automation 9.1 دقیقاً چه کاری انجام میدهد؟
VCF Automation لایه ارائه سرویس در VMware Cloud Foundation است. Provider Administrator زیرساخت، Region، Zone، سهمیه، Policy و سرویسهای قابل ارائه را تعریف میکند؛ Organization Administrator این ظرفیت را بین Projectها و Namespaceها توزیع میکند؛ و مصرفکننده از طریق Catalog یا API سرویس موردنیاز خود را دریافت میکند.
خروجی میتواند یک ماشین مجازی، VM Service، کلاستر VKS، Container Service یا یک Application Stack باشد. بنابراین VCF Automation را نباید صرفاً «ابزار ساخت VM» دانست. محصول، مرز میان تیم پلتفرم و تیم برنامه را مدیریت میکند و درخواست کاربر را به یک Deployment کنترلشده تبدیل میکند.
جایگاه VCF Operations Orchestrator
VCF Operations Orchestrator ادامه مسیر vRealize Orchestrator و Aria Automation Orchestrator است. وظیفه اصلی آن ساخت و اجرای Workflow، Action، Policy و Plug-in است. Automation میتواند Workflowهای Orchestrator را در Catalog قرار دهد یا با Event Broker Service در نقاط مختلف Lifecycle فراخوانی کند.
به زبان ساده، VCF Automation تصمیم میگیرد چه سرویسی، برای چه کاربری و تحت چه سیاستی ارائه شود؛ Orchestrator مشخص میکند مراحل اختصاصی اجرای آن سرویس چگونه انجام شود. برای نمونه، Automation یک VM را تحویل میدهد و Orchestrator پس از Provisioning آن را در Active Directory ثبت، Agent مانیتورینگ را نصب و رکورد CMDB را ایجاد میکند.
معماری تعامل Automation و Orchestrator
- کاربر از Catalog، API، VCF CLI یا Terraform یک سرویس را درخواست میکند.
- VCF Automation هویت، Organization، Project، Quota و Policyهای درخواست را ارزیابی میکند.
- Placement Policy، Zone و زیرساخت مناسب را تعیین میکند.
- Provisioning از طریق سرویسهای VCF و Endpointهای متصل انجام میشود.
- Event Broker Service رویدادهای Lifecycle را منتشر میکند.
- Subscription مرتبط، Workflow موجود در VCF Operations Orchestrator را فراخوانی میکند.
- Workflow اقدام تکمیلی را روی vCenter، NSX، سرویسهای سازمانی یا APIهای بیرونی اجرا میکند.
- وضعیت Deployment و عملیات Day-2 از همان لایه Self-Service در دسترس میماند.
Orchestrator همچنین میتواند بهصورت مستقل یا کلاسترشده ارتقا یابد و از طریق Plug-inها به سامانههای دیگر متصل شود. در طراحی Enterprise باید HA، Certificate، DNS، NTP، دسترسی API و نگهداری Credentialها برای آن جداگانه بررسی شود.
مهمترین تغییرات VCF Automation 9.1
Container Service بهعنوان Runtime مستقل
در 9.1 سه مسیر مصرف Workload واضحتر شده است: VM Service، Container Service و VMware vSphere Kubernetes Service. Container Service برای اجرای Container بدون تحمیل پیچیدگی اداره یک کلاستر Kubernetes کامل طراحی شده است. Lifecycle شامل Deploy، Configure، Monitor، Upgrade و Delete از رابط VCF Automation مدیریت میشود. این قابلیت جای VKS را نمیگیرد؛ VKS برای سناریویی است که تیم به API و قابلیتهای کامل Kubernetes نیاز دارد.
Fast Deploy برای VM و VKS
Broadcom در معرفی رسمی 9.1 از Fast Deploy برای عملیات مبتنی بر VM و ایجاد کلاسترهای VKS نام میبرد. این قابلیت برای VMهایی که از Blueprint ایجاد میشوند پس از Upgrade فعال میشود و هدف آن کاهش زمان Provisioning است. نتیجه عملی، کوتاهتر شدن فاصله ثبت درخواست تا تحویل محیط آماده است؛ با این حال زمان واقعی همچنان به Template، Guest Customization، Storage، Network و Workflowهای Post-Provisioning وابسته است.
Application Stack Formation
در App Stack Formation میتوان توپولوژی در حال اجرا شامل گروهی از VMها، شبکه و Diskها را به Blueprint قابل استفاده مجدد تبدیل کرد. این قابلیت برای استانداردسازی محیطهای Dev، Test و Production مهم است، چون یک برنامه چندلایه بهعنوان یک واحد مدیریت میشود و میتوان ترتیب روشنشدن، Snapshot و عملیات گروهی را برای آن تعریف کرد.
Infrastructure Placement Policy
نسخه 9.1 امکان تعریف Policyهای اجباری و اختیاری برای Placement را توسعه داده است. Provider میتواند Policy را به Region Quota متصل کند و Organization آن را در Namespace مصرف کند. معیارهایی مانند ویژگی سیستمعامل یا Labelها به Policyهای Compute در vSphere نگاشت میشوند تا Workload روی Host یا Cluster مناسب قرار بگیرد.
کاربرد عملی این بخش فقط Performance نیست. میتوان Windows Workloadها را روی Cluster مشخص برای کنترل مصرف License هدایت کرد، Workloadهای حساس را در محدوده جغرافیایی یا سختافزاری تعیینشده نگه داشت و سیاستهای Affinity را بدون واگذاری کنترل vCenter به مصرفکننده اعمال کرد.
Day-2، شبکه و امنیت Self-Service
مصرفکننده در 9.1 میتواند با Policy مناسب CPU، Memory، Storage و Network را تغییر دهد و عملیاتهایی مانند Snapshot و VM Group را انجام دهد. در حوزه شبکه نیز قابلیتهایی نظیر چند اتصال خارجی، چند Transit Gateway برای Tenant، شبکه Self-Service، Gateway Firewall، Shared Subnet و اتصال VLAN توسعه یافتهاند. اجرای هر قابلیت به طراحی NSX، نقشها و Policyهای Provider وابسته است؛ وجود گزینه در Product به معنی مجاز بودن خودکار برای تمام کاربران نیست.
Cost Visibility و Quota
داده هزینه از Rate Card در VCF Operations وارد تجربه Provisioning میشود تا برآورد اولیه هزینه سرویس و Drill-down در سطح Organization، Project و Namespace قابل مشاهده باشد. این قابلیت Billing مالی مستقل نیست؛ ابزار Showback و Chargeback داخلی برای شفافکردن مصرف است.
در 9.1 میتوان کل ظرفیت یک Region را با مدل Fully Allocated Region Quota در اختیار Organization قرار داد، بدون اینکه از ابتدا Zone مشخصی محدودکننده باشد. این مدل انعطاف بیشتری ایجاد میکند، اما کنترل Capacity و جلوگیری از مصرف نامتوازن را حذف نمیکند.
Terraform و API یکپارچهتر
Terraform Provider در 9.1 دامنه بیشتری از Provisioning، مدیریت Image و Policy-as-Code را پوشش میدهد. API مدیریت VKS نیز به الگوی VCF API نزدیک شده است تا VM، Container و VKS از مسیرهای سازگارتر توسط VCF CLI، Terraform یا ابزارهای توسعه اداره شوند. برای تیمی که آموزش VCF را جدی دنبال میکند، یادگیری UI کافی نیست؛ API، YAML، Terraform و Workflow Design بخشی از مهارت عملی نسل جدید VCF هستند.
جدول مقایسه Aria Automation 8، VCF Automation 9 و 9.1
| موضوع | Aria Automation 8.x | VCF Automation 9.0 | VCF Automation 9.1 |
|---|---|---|---|
| مدل محصول | مجموعه Aria با Lifecycle جداگانه | ورود به مدل VCF و Fleet Management | مدیریت Lifecycle از VCF Operations و VCF Management Services |
| مصرف سرویس | Cloud Templates، Catalog و Service Broker | Self-Service مبتنی بر Organization و Project | تکمیل مدل VM، Container و VKS بهعنوان Runtimeهای مشخص |
| Placement | Constraint و Tagهای Cloud Zone | Policyهای VCF Automation | Infrastructure Placement Policy اجباری و اختیاری با Governance گستردهتر |
| Application | Blueprint از پیش طراحیشده | Blueprint و سرویسهای VCF | App Stack Formation برای Capture توپولوژی در حال اجرا |
| هزینه | وابسته به CloudHealth/Aria Operations و Integration | Cost Integration اولیه | نمایش Cost در Org و Project و برآورد پیش از Provisioning |
| Orchestration | Aria Automation Orchestrator | VCF Operations Orchestrator | همان نقش Workflow و Extensibility با Integration و Lifecycle جدید |
| Upgrade | مدیریت با Aria Suite Lifecycle | Import در Fleet | Import/Upgrade از VCF Operations؛ برای 9.0.x مدل Side-by-Side و Precheck اهمیت دارد |
مهاجرت از Aria Automation 8.x و VCF Automation 9.0
Broadcom توصیه میکند Automation بهعنوان Workstream مستقل برنامهریزی شود، زیرا Blueprint، Custom Code، Integration و Workflowهای سازمانی ممکن است به Validation و اصلاح نیاز داشته باشند. در مسیر 8.x، Applianceهای Aria Automation ابتدا در VCF Operations Import میشوند و Upgrade از مسیر Build > Lifecycle > VCF Management انجام میشود.
طبق KB رسمی Upgrade Sequence، در مهاجرت از Aria Suite Lifecycle 8.x، پس از Upgrade به VCF Automation 9.1، vRealize Suite Lifecycle Manager و VMware Identity Manager میتوانند موقتاً به کار ادامه دهند تا Identity به VMware Identity Broker منتقل و اجزای قدیمی Decommission شوند. در 9.1، VCF Fleet Management Appliance نسل 9.0 دیگر محل Lifecycle نیست و این قابلیت به VCF Management Services منتقل شده است.
برای Upgrade از 9.0.x نیز باید ظرفیت شبکه موقت، DNS، NTP، Certificate، Credential، وضعیت Database و Precheckها بررسی شود. معماری Side-by-Side به IPهای آزاد نیاز دارد؛ KB 446018 نمونهای را مستند کرده که Upgrade از 9.0.2 به 9.1 در صورت کمتر از هشت IP آزاد در Management Block متوقف میشود. این عدد را نباید بدون بررسی Build و مستندات جاری به همه طراحیها تعمیم داد، اما نشان میدهد برنامه IP بخش واقعی پروژه Upgrade است.
محدودیتها و Known Issueهای مهم Orchestrator 9.1
Race Condition در Workflowهای Post-Provisioning
KB 445188 توضیح میدهد که در VCF Automation و VCF Operations Orchestrator 9.1.0 برخی Workflowهای Extensibility ممکن است هنگام اجرای بسیار سریع پس از Provisioning، پیش از تکمیل Cloud-init یا Cloudbase-init، بهصورت مقطعی شکست بخورند. راهکار عملی شامل Retry Logic، یک Workflow مسدودکننده برای انتظار تا پایان Guest Initialization و سبککردن فرایندهای Template است. قرار دادن تمام Subscriptionها روی Priority صفر همیشه تصمیم درستی نیست.
ریاتصال vCenter پس از Reboot
KB 452127 یک نقص در Orchestrator 9.1.0.0 را ثبت کرده است که ممکن است Plug-in اتصال خود به vCenter را پس از Reboot از دست بدهد. Workaround اجرای Workflow بهروزرسانی vCenter Server Instance است و Broadcom رفع آن را برای 9.1.1 و بالاتر هدفگذاری کرده است. پیش از Upgrade یا نصب Patch باید وضعیت واقعی Release و KB دوباره بررسی شود.
FQDN، Certificate و Proxy
در 9.1 استفاده از FQDN معتبر برای Endpointها ضروری است. KB 453407 نشان میدهد اتصال PowerCLI به vCenter از طریق IP میتواند به PNID mismatch، WebSSO failure و در ادامه مسدودشدن Proxy داخلی منجر شود. طراحی درست DNS و Certificate یک پیشنیاز عملی است، نه کار تزئینی پس از نصب.
سناریوی واقعی: تحویل خودکار VM سازمانی
فرض کنید تیم نرمافزار یک Windows Server برای محیط Test میخواهد. فرایند استاندارد میتواند چنین باشد:
- کاربر Blueprint ویندوز را از Catalog انتخاب و Project، اندازه و شبکه را مشخص میکند.
- VCF Automation سهمیه و Approval Policy را کنترل میکند.
- Infrastructure Placement Policy ماشین را روی Cluster دارای مجوز Windows قرار میدهد.
- vDefend Tag و Network Policy متناسب با محیط Test اعمال میشود.
- پس از روشنشدن VM، Event Broker یک Workflow در Orchestrator فراخوانی میکند.
- Workflow تا آمادهشدن VMware Tools و پایان Guest Customization صبر میکند.
- ماشین به Domain متصل و رکوردهای DNS، CMDB، Backup و Monitoring ساخته میشوند.
- VCF Automation سرویس آماده را با Cost Estimate و عملیات Day-2 مجاز در اختیار کاربر میگذارد.
این همان نقطهای است که آموزش VMware از مدیریت دستی vCenter فاصله میگیرد. متخصصی که فقط ساخت VM را بلد است، لایه Service Delivery را پوشش نمیدهد. مسیر آموزش مجازی سازی و نقشه راه VMware ابرکلاس باید در کنار آموزش VVF، مفاهیم VCF Operations، Automation، API و Governance را نیز پوشش دهد.
پیادهسازی در ایران و محیط آفلاین
VCF Automation 9.1 یک سرویس SaaS عمومی نیست و در Private Cloud سازمان مستقر میشود؛ بنابراین پس از دریافت قانونی Software و Entitlement، اجرای روزمره آن الزاماً به اینترنت عمومی وابسته نیست. چالش اصلی محیطهای ایران Download و Lifecycle است. Software Depot، Bundleها، Patchها، Plug-inها و Contentهای لازم باید با روش موردپشتیبانی Broadcom دریافت و برای محیط Disconnected آماده شوند.
Download Token را نباید داخل Script، Log یا Repository ذخیره کرد. در طراحی آفلاین، Repository داخلی، کنترل Hash، نسخهبندی Bundle، پشتیبانگیری از Workflow Packageها و مستندسازی Plug-inها ضروری است. درباره Licensing نیز باید به Entitlement جاری قرارداد رجوع کرد؛ وجود VCF Automation در مستندات پلتفرم بهتنهایی مجوز استفاده از هر Advanced Service یا Integration جانبی را اثبات نمیکند.
رابطه این مقاله با مجموعه VCF 9.1 ابرکلاس
برای درک نقشه محصول ابتدا مقاله پایان Aria Suite و مسیر مهاجرت به VCF 9.1 را بخوانید. برای Lifecycle و Fleet به VCF Operations 9.1 مراجعه کنید. Observability لاگ در مقاله VCF Log Management 9.1 و تحلیل جریان شبکه در VCF Operations for Networks 9.1 بررسی شده است.
جمعبندی فنی
VCF Automation 9.1 لایه مصرف Private Cloud را از یک Catalog ساده فراتر میبرد. Runtimeهای VM، Container و VKS، سیاست Placement، Cost Visibility، Quota، App Stack و عملیات Day-2 در یک مدل Provider و Tenant قرار میگیرند. VCF Operations Orchestrator نیز موتور اجرای منطق اختصاصی باقی میماند و از طریق Workflow، Plug-in و Event Subscription فاصله میان سرویس استاندارد VCF و فرایندهای واقعی سازمان را پر میکند.
موفقیت این معماری به تعداد Blueprintها وابسته نیست. معیار واقعی، استانداردبودن Identity، Network، Policy، Template، Workflow، Error Handling و Lifecycle است. در برنامه آموزش VCF، طراحی Service Delivery و Orchestration باید در کنار Compute، Storage و Network تدریس شود؛ و در آموزش VVF نیز مرز قابلیتهای VVF با سرویسهای کامل VCF باید شفاف بماند.
سوالات متداول
آیا VCF Operations Orchestrator جایگزین VCF Automation است؟
خیر. VCF Automation پورتال Self-Service، Catalog، Policy، Quota و Lifecycle Deployment را فراهم میکند. Orchestrator موتور Workflow و Integration است و معمولاً توسط Automation یا مدیر زیرساخت فراخوانی میشود.
آیا Orchestrator در نسخه 9.1 حذف یا کاملاً داخل Automation ادغام شده است؟
خیر. نام محصول به VCF Operations Orchestrator تغییر کرده، اما همچنان مؤلفه مشخصی برای Workflow و Extensibility است و میتواند با VCF Automation یکپارچه شود.
آیا Upgrade از Aria Automation 8.x به 9.1 درجا است؟
مسیر رسمی با Import اجزای موجود در VCF Operations و اجرای Workflowهای Lifecycle انجام میشود. جزئیات به نسخه مبدأ و توپولوژی وابسته است و باید Release Notes، Upgrade Sequence و Precheckهای همان Build بررسی شوند.
آیا VCF Automation 9.1 برای محیط بدون اینترنت قابل استفاده است؟
بله، Workload و Control Plane در مرکز داده سازمان اجرا میشوند؛ اما تهیه Bundle، Patch، Plug-in و Lifecycle در محیط Disconnected به Repository و فرایند انتقال کنترلشده نیاز دارد.
Container Service جای VKS را میگیرد؟
خیر. Container Service اجرای Container با پیچیدگی عملیاتی کمتر را هدف میگیرد، در حالی که VKS یک کلاستر Kubernetes کامل برای تیمهایی است که به API و اکوسیستم Kubernetes نیاز دارند.
مهمترین پیشنیاز عملی Orchestrator چیست؟
در کنار منابع محاسباتی، DNS و FQDN صحیح، Certificate معتبر، NTP، دسترسی Endpoint، Credential Management، طراحی Retry و تست Workflowها قبل و بعد از Upgrade ضروریاند.
