راهنمای لایسنس VMware در نسخه 9 و 9.1

تا پیش از نسخه ۹، مفهوم لایسنس VMware برای بسیاری از مدیران زیرساخت با یک رشته ۲۵ کاراکتری گره خورده بود؛ کلیدی که در vCenter، ESXi، vSAN یا هر محصول دیگر وارد می‌شد و باید تاریخ انقضا و ظرفیت آن را جداگانه مدیریت می‌کردیم.

در VMware Cloud Foundation 9 و VMware vSphere Foundation 9 این معماری تغییر کرد. لایسنس دیگر صرفاً یک کلید نیست؛ بخشی از چرخه عملیاتی زیرساخت است که باید ظرفیت خریداری‌شده، مصرف واقعی، وضعیت اشتراک و گزارش‌های دوره‌ای را به‌صورت متمرکز مدیریت کند.

در نسخه ۹ این تحول با VCF Operations، کنسول VCF Business Services و فایل لایسنس آغاز شد. نسخه ۹.۱ نیز با اضافه‌کردن License Server محلی، خودکارسازی Connected Mode، پشتیبانی بهتر از چند License و ارائه APIهای عمومی‌تر، این معماری را کامل‌تر کرد.

در این راهنمای تخصصی از مجموعه مقالات آموزش مجازی سازی ابرکلاس، ابتدا محصولات داخل بسته‌های VVF و VCF را بررسی می‌کنیم، سپس سراغ معماری لایسنس، پیش‌نیازها، محاسبه Core و TiB، نحوه فعال‌سازی و در نهایت تخصیص لایسنس به vCenter، ESX، vSAN و سایر اجزای VMware می‌رویم.

چرا VMware مدل لایسنس را تغییر داد؟

در یک محیط کوچک، واردکردن چند License Key کار سختی نبود؛ اما در یک Private Cloud بزرگ با چند vCenter، صدها ESX Host، چندین کلاستر vSAN و سرویس‌هایی مانند NSX، VCF Automation و HCX، مدیریت مستقل کلیدها به‌سرعت پیچیده می‌شد.

مشکلات مدل قبلی عبارت بودند از:

• تعدد License Keyها و تاریخ انقضای متفاوت آن‌ها
• وابستگی برخی کلیدها به نسخه محصول
• مشاهده‌نشدن مصرف واقعی کل محیط در یک کنسول واحد
• دشواری جابه‌جایی ظرفیت بین سایت‌ها و vCenterها
• مدیریت جداگانه لایسنس Compute، Storage، Network و Add-onها
• احتمال تخصیص بیش از ظرفیت خریداری‌شده

هدف VMware در نسخه ۹ این بود که لایسنس را از یک تنظیم محلی در محصولات، به یک سرویس مرکزی و مبتنی بر گزارش مصرف تبدیل کند.

مقایسه لایسنس VMware در نسخه ۸، ۹ و ۹.۱

در VCF 5.1.1 امکان استفاده از یک Solution License Key نیز وجود داشت، اما معماری همچنان Key-Based بود و برخی اجزا مانند vSAN به تخصیص جداگانه نیاز داشتند. تغییر واقعی در نسخه ۹ اتفاق افتاد؛ جایی که فایل اشتراکی جای کلیدهای پراکنده را گرفت. معماری لایسنس VCF 9.0 در مستندات VMware 

VVF و VCF چه تفاوتی دارند؟

پیش از بررسی لایسنس باید بدانیم چه چیزی خریداری می‌شود. در نسخه ۹، دو بسته اصلی VMware عبارت‌اند از:

• VMware vSphere Foundation یا VVF
• VMware Cloud Foundation یا VCF

VVF برای سازمانی طراحی شده که به یک پلتفرم قدرتمند مجازی‌سازی، ذخیره‌سازی، Kubernetes و مدیریت متمرکز نیاز دارد. VCF علاوه بر این قابلیت‌ها، یک Private Cloud کامل با شبکه نرم‌افزاری، اتوماسیون، مدیریت چندسایتی و سرویس‌های گسترده‌تر ارائه می‌کند.

برای مقایسه کامل‌تر این دو معماری می‌توانید مطلب مقایسه VVF و VCF را نیز مطالعه کنید.

محصولات داخل VMware vSphere Foundation

بر اساس FAQ رسمی نسخه ۹.۱، بسته VVF شامل اجزای زیر است:

• VMware vSphere Enterprise Plus
• VMware vCenter Standard
• VMware vSphere Kubernetes Service یا VKS
• VMware Cloud Foundation Operations
• VCF Operations for Logs
• VCF Operations Diagnostics
• VMware vSAN با ظرفیت پایه ۰٫۲۵ TiB به‌ازای هر Core

بنابراین VVF فقط یک مجوز ESXi نیست. این بسته Compute، مدیریت مرکزی، Kubernetes، عملیات هوشمند و بخشی از ظرفیت vSAN را در یک Subscription قرار می‌دهد. فهرست رسمی اجزای VVF 9.1

محصولات داخل VMware Cloud Foundation

بسته VCF در نسخه ۹.۱ یک Private Cloud کامل‌تر ارائه می‌کند و اجزای اصلی آن عبارت‌اند از:

• VMware vSphere و vCenter
• VMware vSAN
• VMware NSX
• VMware vSphere Kubernetes Service
• VCF Operations
• VCF Automation
• VCF Operations HCX یا Workload Mobility
• VCF Private AI Services
• سرویس‌های مدیریت Fleet و Lifecycle

ظرفیت پایه vSAN در VCF معادل یک TiB فضای Raw به‌ازای هر Core لایسنس‌شده است. این مقدار در VVF فقط ۰٫۲۵ TiB به‌ازای هر Core است. معرفی اجزای VMware Cloud Foundation

چه محصولاتی ممکن است Add-on باشند؟

خرید VCF یا VVF به این معنی نیست که تمام محصولات دارای نام VMware بدون محدودیت در اختیار سازمان قرار می‌گیرند. سرویس‌های زیر، بسته به نسخه و قرارداد، ممکن است به Entitlement یا Add-on مستقل نیاز داشته باشند:

• ظرفیت اضافه vSAN
• VMware Advanced Cyber Compliance
• قابلیت‌های پیشرفته VMware vDefend
• VMware Avi Load Balancer
• VMware Live Recovery و Site Recovery Manager
• Application Services
• Data Services و VMware Data Services Manager
• سرویس‌های پیشرفته Network Observability
• برخی قابلیت‌های Private AI

نکته مهم این است که «داخل سبد VMware بودن»، «قابل نصب بودن» و «داخل Subscription پایه بودن» سه مفهوم متفاوت هستند.

برای مثال در نسخه ۹.۰، VCF Core، VVF Core، ظرفیت vSAN و Private AI Foundation از فایل لایسنس جدید پشتیبانی می‌کردند؛ اما برخی Add-onها همچنان از License Key قدیمی یا مدل SaaS استفاده می‌کردند. بنابراین فرمت فعال‌سازی هر Add-on باید با SPD و قرارداد همان نسخه کنترل شود.

واحد محاسبه لایسنس VCF و VVF چیست؟

لایسنس پایه VCF و VVF بر اساس تعداد هسته‌های فیزیکی پردازنده‌های سرورهای ESX محاسبه می‌شود؛ نه تعداد vCPU ماشین‌های مجازی و نه تعداد Logical Processorهایی که Hyper-Threading ایجاد می‌کند.

قانون حداقل ۱۶ Core برای هر CPU

برای هر پردازنده فیزیکی باید حداقل ۱۶ Core لایسنس شود.

اگر یک CPU فقط ۸ هسته داشته باشد، در محاسبه لایسنس همچنان ۱۶ Core در نظر گرفته می‌شود. اگر پردازنده ۲۴ هسته داشته باشد، همان ۲۴ Core محاسبه خواهد شد.

فرمول ساده برای هر Host به شکل زیر است:

تعداد CPU فیزیکی × حداکثرِ تعداد Core واقعی هر CPU یا ۱۶

یک مثال عملی

فرض کنیم سه ESX Host داریم و هر Host دارای دو CPU با ۲۴ Core است:

3 Host × 2 CPU × 24 Core = 144 Core

برای این محیط حداقل به ۱۴۴ Core لایسنس VCF یا VVF نیاز داریم.

ظرفیت پایه vSAN در این مثال:

• در VCF: حدود ۱۴۴ TiB ظرفیت Raw
• در VVF: حدود ۳۶ TiB ظرفیت Raw

اگر ظرفیت Raw دیسک‌های استفاده‌شده در vSAN بیشتر باشد، باید vSAN Add-on تهیه شود.

Broadcom برای محیط‌های بزرگ استفاده از ابزار License Counting PowerCLI را توصیه کرده است؛ زیرا عدد نمایش‌داده‌شده در داشبورد Capacity مربوط به فضای قابل‌استفاده Datastore است و الزاماً ظرفیت Raw موردنیاز برای لایسنس را نشان نمی‌دهد. راهنمای رسمی محاسبه Core و ظرفیت vSAN

اجزای معماری لایسنس VMware 9

مدل لایسنس نسخه ۹ را می‌توان به چهار لایه اصلی تقسیم کرد:

Broadcom Support Portal / VCF Business Services Console

VCF Operations

License Server در نسخه 9.1

vCenter,Esx,vSAN,NSX , …

۱. Broadcom Support Portal

Entitlementهای خریداری‌شده در Broadcom Support Portal و بخش My Entitlements قابل مشاهده‌اند. این بخش نشان می‌دهد سازمان چه Subscriptionهایی، با چه ظرفیتی و تحت کدام Site ID در اختیار دارد.

داشتن حساب کاربری عادی کافی نیست؛ کاربر باید مجوزهای لازم برای مدیریت لایسنس Site ID مربوطه را نیز داشته باشد.

۲. VCF Business Services Console

VCF Business Services Console از طریق Broadcom Support Portal یا آدرس vcf.broadcom.com در دسترس است.

کارهای اصلی این کنسول عبارت‌اند از:

• مشاهده Entitlementها
• ایجاد و مدیریت License Allocation
• تقسیم ظرفیت لایسنس
• ثبت VCF Operations
• دریافت گزارش مصرف
• تولید یا ارائه فایل لایسنس
• مدیریت Tenant و نقش‌های لایسنس در نسخه ۹.۱

۳. VCF Operations

VCF Operations کنسول عملیاتی داخل دیتاسنتر است و مدیر زیرساخت فعالیت‌های اصلی را از طریق آن انجام می‌دهد:

• ثبت محیط در Business Services Console
• واردکردن یا همگام‌سازی فایل لایسنس
• مشاهده ظرفیت کل، مصرف‌شده و آزاد
• اضافه‌کردن vCenterها
• تخصیص Primary License
• مشاهده هشدارهای انقضا یا کمبود ظرفیت
• تولید Usage Report
• مدیریت Connected و Disconnected Mode

برای استفاده از مدل لایسنس نسخه ۹، وجود VCF Operations و حداقل یک vCenter ضروری است. راهنمای شروع لایسنس VCF و VVF نسخه ۹

۴. License Server در نسخه ۹.۱

مهم‌ترین تغییر معماری نسخه ۹.۱، اضافه‌شدن یک License Server محلی است.

این جزء یک اپلاینس مدیریتی معمولی نیست که ادمین از طریق SSH وارد آن شود و فایل‌هایش را تغییر دهد. License Server به‌صورت Headless و Hardened طراحی شده و چرخه نصب، ارتقا، مانیتورینگ و جایگزینی آن توسط VCF Operations و Management Services مدیریت می‌شود.

ویژگی‌های اصلی آن عبارت‌اند از:

• نصب خودکار همراه با VCF Operations یا Management Services
• ارتقای خودکار در چرخه ارتقای VCF Operations
• نگه‌داری متمرکز و محافظت‌شده اطلاعات لایسنس
• نداشتن دسترسی تعاملی معمول، SSH یا حساب مدیریتی عمومی
• امکان استفاده از یک یا چند License Server در Fleet
• جداسازی منطق لایسنس از سرویس‌های اصلی VCF Operations

با وجود اضافه‌شدن License Server، محل مدیریت روزمره لایسنس همچنان VCF Operations است. تغییرات لایسنس VCF 9.1

در Connected Mode باید ارتباط لازم میان VCF Operations و سرویس‌های Broadcom نیز بر اساس مستندات و سیاست Firewall سازمان فراهم شود. 

Connected Mode چگونه کار می‌کند؟

Connected Mode گزینه پیشنهادی برای محیط‌هایی است که اجازه ارتباط کنترل‌شده با سرویس‌های Broadcom را دارند.

در نسخه ۹.۰، مدیر باید حداقل یک‌بار در هر بازه ۱۸۰روزه عملیات ارسال Usage و دریافت فایل به‌روزشده را تأیید می‌کرد.

در نسخه ۹.۱ این مرحله خودکار شده است:

• اطلاعات مصرف هر ۲۴ ساعت ارسال می‌شود.
• فایل لایسنس به‌روز دریافت می‌شود.
• فایل جدید بدون دخالت مدیر اعمال می‌شود.
• اعتبار جاری لایسنس به‌صورت پیوسته حفظ می‌شود.

این تغییر یکی از مهم‌ترین تفاوت‌های نسخه ۹ و ۹.۱ است؛ زیرا ریسک فراموش‌کردن چرخه ۱۸۰روزه را در محیط‌های متصل کاهش می‌دهد.

اگر سازمان بخواهد قبل از اعمال هر فایل آن را کنترل کند، باید به‌جای Connected Mode خودکار از Disconnected Mode استفاده کند.

Disconnected Mode و محیط Air-Gapped

قطع‌بودن اینترنت مانع استفاده از VCF یا VVF نسخه ۹ نیست. VMware برای دیتاسنترهای حساس، نظامی، مالی یا Air-Gapped مسیر رسمی Disconnected Mode را ارائه می‌کند.

فرایند اولیه معمولاً سه مرحله دارد:

مرحله اول: Registration

از VCF Operations فایل Registration تولید می‌شود. این فایل از طریق یک Transfer Station کنترل‌شده به VCF Business Services Console منتقل خواهد شد.

مرحله دوم: Verification

پرتال پس از بررسی Entitlement و Allocation، فایل Verification یا Confirmation را تولید می‌کند. این فایل به محیط داخلی بازگردانده و در VCF Operations وارد می‌شود.

مرحله سوم: Licensing

فایل لایسنس تولیدشده از Business Services Console دریافت و داخل VCF Operations Import می‌شود. سپس می‌توان آن را به vCenter تخصیص داد.

پس از فعال‌سازی اولیه نیز باید Usage Report و فایل لایسنس به‌روز، حداکثر در چرخه‌های ۱۸۰روزه تبادل شوند.

Air-Gapped به معنی «عدم خروج هیچ داده‌ای» نیست. فایل Usage می‌تواند اطلاعات فنی موردنیاز برای محاسبه مصرف، مانند شناسه محیط، نسخه محصولات، شناسه vCenter، تعداد Host و Core، ظرفیت vSAN و شناسه License Allocation را در بر داشته باشد.

بهتر است برای انتقال این فایل‌ها فرایندی رسمی شامل موارد زیر تعریف شود:

• Transfer Station مشخص
• ثبت Hash فایل‌ها
• ثبت زمان ارسال و دریافت
• تعیین مالک فرایند
• نگه‌داری Audit Log
• تقویم یادآوری چرخه ۱۸۰روزه
• بررسی فایل طبق سیاست طبقه‌بندی اطلاعات سازمان

Reserved License چیست؟

Reserved License برای سایت‌های واقعاً تاریک، تجهیزات Embedded یا محیط‌هایی طراحی شده که امکان انتقال دوره‌ای فایل نیز ندارند.

این ظرفیت باید پیش از استقرار، در VCF Business Services Console به‌عنوان Reserved مشخص شود. Reserved License از چرخه عادی گزارش‌گیری ۱۸۰روزه عبور می‌کند، اما یک گزینه عمومی برای راحتی بیشتر یا دورزدن گزارش مصرف نیست.

امکان استفاده از آن به نوع قرارداد، Entitlement و تأیید Broadcom وابسته است. آزادسازی یا بازگرداندن ظرفیت Reserved نیز معمولاً یک فرایند دستی است.

مراحل کامل فعال‌سازی لایسنس VCF و VVF

گام اول: بررسی Entitlement

وارد Broadcom Support Portal شوید و در بخش My Entitlements موارد زیر را کنترل کنید:

• نام محصول: VCF یا VVF
• تعداد Core خریداری‌شده
• ظرفیت vSAN
• تاریخ شروع و پایان Subscription
• Site ID و Licensee
• Add-onهای خریداری‌شده
• مجوز کاربر برای مدیریت لایسنس

گام دوم: نصب یا ارتقای VCF Operations

VCF Operations باید با VMware Cloud Foundation Installer نصب شود. اگر از VMware Aria Operations استفاده می‌کنید، ابتدا مسیر ارتقا به VCF Operations 9 را طبق ماتریس سازگاری بررسی کنید.

محیط پس از نصب یا ارتقا تا ۹۰ روز در Evaluation Mode قرار می‌گیرد؛ اما بهتر است Registration به روزهای پایانی این بازه موکول نشود.

گام سوم: محاسبه ظرفیت موردنیاز

پیش از Allocation این موارد را به‌طور دقیق استخراج کنید:

• تعداد ESX Hostها
• تعداد CPU فیزیکی هر Host
• تعداد Core فیزیکی هر CPU
• حداقل ۱۶ Core برای هر CPU
• ظرفیت Raw تمام دیسک‌های عضو vSAN
• نوع بسته موردنیاز در هر سایت
• ظرفیت Add-onها

گام چهارم: ایجاد License Allocation

پس از خرید، ظرفیت هر محصول معمولاً در یک Default License Pool تجمیع می‌شود.

اگر فقط یک VCF Operations دارید، می‌توانید ظرفیت مناسب را به همان محیط اختصاص دهید. اگر چند VCF Operations دارید، باید Default Allocation را Split کنید؛ زیرا یک Allocation واحد را نمی‌توان هم‌زمان در دو VCF Operations مستقل استفاده کرد.

در زمان Split باید به این موارد توجه شود:

• مجموع بخش‌ها نباید از ظرفیت اصلی بیشتر باشد.
• حذف یک Split ظرفیت آن را به Default Pool بازمی‌گرداند.
• تاریخ پایان Subscription با Split تغییر ماهوی نمی‌کند.
• Product، Unit، Site ID و شرایط Licensee باید با هم سازگار باشند.

گام پنجم: ثبت VCF Operations

از بخش License Management در VCF Operations عملیات Registration را آغاز کنید.

در Connected Mode پس از انتخاب Allocation، یک Activation Code دریافت می‌شود. با واردکردن آن در VCF Operations، دریافت فایل لایسنس آغاز خواهد شد.

در Disconnected Mode فایل Registration صادر و پس از انجام فرایند پرتال، فایل لایسنس به‌صورت دستی Import می‌شود.

گام ششم: بررسی License Server در نسخه ۹.۱

در نسخه ۹.۱ وضعیت License Server را در VCF Operations کنترل کنید:

• سرویس در وضعیت Healthy باشد.
• Registration کامل شده باشد.
• ارتباط با VCF Operations برقرار باشد.
• vCenter بتواند از طریق HTTPS به آن دسترسی داشته باشد.
• DNS و زمان سیستم صحیح باشند.

به‌دلیل مدل Disposable Appliance، در صورت خرابی شدید معمولاً License Server تعمیر تعاملی نمی‌شود؛ اپلاینس یا سرویس جایگزین و لایسنس‌ها دوباره به آن متصل می‌شوند.

نحوه اختصاص لایسنس به vCenter و محصولات

در معماری جدید، لایسنس پایه مستقیماً روی تک‌تک ESX Hostها وارد نمی‌شود.

۱. اضافه‌کردن vCenter به VCF Operations

ابتدا vCenter باید به‌عنوان Account یا Managed Instance در VCF Operations ثبت شود. پس از برقراری ارتباط، Inventory شامل Datacenter، Cluster، Host و ظرفیت‌های مرتبط کشف خواهد شد.

۲. انتخاب Primary License

از بخش License Management، لایسنس پایه مناسب را انتخاب کنید:

• VMware Cloud Foundation
• VMware vSphere Foundation
• VCF Edge یا سایر Primary Licenseهای واجد شرایط

۳. اختصاص Primary License به vCenter

Primary License به vCenter Instance تخصیص داده می‌شود. پس از این مرحله، اجزای پایه‌ای که زیرمجموعه همان vCenter و همان بسته هستند، به‌صورت خودکار از لایسنس استفاده می‌کنند.

این اجزا می‌توانند شامل موارد زیر باشند:

• ESX Hostها
• vCenter
• NSX در محیط VCF
• VCF Automation
• سایر اجزای Core بسته

بنابراین برای هر ESX Host یک فایل یا کلید جداگانه وارد نمی‌شود. روند رسمی تخصیص لایسنس نسخه ۹

۴. تخصیص ظرفیت vSAN

vSAN بر اساس ظرفیت Raw مصرف‌شده در سطح Cluster محاسبه می‌شود. ابتدا ظرفیت Included بسته و سپس vSAN Add-on سازگار در نظر گرفته خواهد شد.

هنگام بررسی vSAN باید سه مقدار مشخص باشند:

• Included Capacity
• Raw Consumed Capacity
• Add-on Capacity

ظرفیت vSAN موجود در VVF یا VCF می‌تواند بین کلاسترهای واجد شرایط تجمیع و توزیع شود؛ بنابراین الزامی نیست نسبت Core و TiB در هر Cluster دقیقاً یکسان باشد.

۵. تخصیص Add-onها

تمام Add-onها رفتار یکسانی ندارند. Licensed Object ممکن است بر اساس محصول یکی از موارد زیر باشد:

• vCenter
• Cluster
• Host
• ظرفیت TiB
• سرویس یا Appliance
• Subscription ابری

برای نمونه، vSAN در سطح Cluster و بر اساس TiB کنترل می‌شود؛ در حالی که بعضی Data Serviceها ممکن است مدل مبتنی بر اعتماد یا گزارش مصرف داشته باشند. SaaSهایی مانند برخی سرویس‌های VMware Live Recovery نیز می‌توانند چرخه فعال‌سازی جداگانه‌ای داشته باشند.

۶. کنترل مصرف و Compliance

پس از تخصیص، در VCF Operations این مقادیر را بررسی کنید:

• Total Capacity
• Used Capacity
• Free Capacity
• تاریخ آخرین Usage Report
• تاریخ اعتبار جاری فایل
• License Issues
• ظرفیت مصرف‌شده Core
• ظرفیت مصرف‌شده vSAN
• وضعیت Add-onها

در vCenter نیز Hostها و Clusterها نباید در وضعیت Evaluation یا Expired باقی مانده باشند.

قابلیت‌های جدید اختصاص لایسنس در نسخه ۹.۱

نسخه ۹.۱ برای محیط‌های بزرگ چند قابلیت مهم اضافه کرده است.

چند Primary License در یک vCenter

در نسخه‌های قبلی ممکن بود برای استفاده از انواع متفاوت Primary License به vCenterهای جداگانه نیاز باشد. در ۹.۱ یک vCenter می‌تواند چند نوع Primary License و حتی لایسنس‌هایی از چند Site ID را مدیریت کند.

این قابلیت برای سازمان‌هایی که دیتاسنتر مرکزی، شعب و Edge Siteهای متعدد دارند بسیار کاربردی است.

کنترل دسترسی مبتنی بر نقش

در Business Services Console نقش‌های تخصصی‌تری برای لایسنس ارائه شده است، از جمله:

• License Refresh Role
• Tenant License Manager
• Read-Only Role

در نتیجه تیم عملیات، واحد مالی، تیم Compliance و مدیر هر Tenant مجبور نیستند همگی دسترسی Full Administrator داشته باشند.

API برای مشتریان سازمانی

در نسخه ۹.۱ APIهای لایسنس فقط محدود به Service Providerها نیستند. مشتریان سازمانی نیز می‌توانند از API برای مواردی مانند توزیع فایل لایسنس، انتقال در شبکه‌های مدیریتی داخلی و یکپارچه‌سازی با اتوماسیون سازمان استفاده کنند.

اگر چرخه ۱۸۰روزه انجام نشود چه اتفاقی می‌افتد؟

فایل لایسنس نسخه ۹ دارای یک پنجره اعتبار جاری است. این پنجره نباید با تاریخ واقعی پایان قرارداد اشتباه گرفته شود.

در محیط Disconnected باید قبل از پایان چرخه ۱۸۰روزه Usage Report ارسال و فایل جدید دریافت شود. هشدارها معمولاً از ۳۰ روز مانده به موعد نمایش داده می‌شوند.

اگر گزارش و فایل به‌روزشده ارائه نشود، لایسنس می‌تواند Expired تلقی شود. در مرحله Enforcement ممکن است:

• ESX Hostها از Management Plane یا vCenter جدا شوند.
• ساخت و روشن‌کردن Workload جدید محدود شود.
• عملیات Provisioning متوقف شود.
• برخی محصولات وارد Read-Only Mode شوند.
• Workloadهای در حال اجرا همچنان به کار خود ادامه دهند.

پس از اعمال فایل معتبر، مدیریت کامل محیط بازمی‌گردد. Broadcom نیز هشدار داده است که عدم تمدید فایل می‌تواند باعث Disconnect شدن Hostها از vCenter و جلوگیری از شروع عملیات جدید شود. توضیح Broadcom درباره چرخه ۱۸۰روزه

آیا لایسنس VMware 9 و 9.1 در ایران قابل استفاده است؟

پاسخ کوتاه این است: از نظر فنی بله، اما از نظر خرید، Entitlement، دسترسی به پرتال و پشتیبانی کاملاً مشروط است.

VCF، VVF، vCenter، ESX و License Server همگی داخل دیتاسنتر اجرا می‌شوند. حتی Disconnected Mode نیز برای محیط‌هایی طراحی شده که اتصال مستقیم اینترنت ندارند.

اما Disconnected Mode یک روش فعال‌سازی بدون Entitlement یا راهی برای دورزدن محدودیت‌های تجاری نیست. همچنان باید:

• Subscription معتبر وجود داشته باشد.
• License Allocation در Business Services Console ساخته شود.
• فایل رسمی لایسنس دریافت شود.
• Usage Report در بازه مقرر ارائه شود.
• دسترسی قانونی و قراردادی به Site ID برقرار باشد.

برای کاربران و شرکت‌های ایرانی، دسترسی مستقیم به Broadcom Support Portal، خرید رسمی، دریافت پشتیبانی و انجام فرایندهای مالی ممکن است تحت‌تأثیر محدودیت‌های صادراتی و تحریم‌ها قرار بگیرد. شرایط باید پیش از خرید با نماینده مجاز، واحد حقوقی و متن قرارداد بررسی شود.

استفاده از کلیدهای نامعتبر، فایل‌های دست‌کاری‌شده یا پرتال‌هایی که ارتباط رسمی و قابل اثبات با Entitlement Broadcom ندارند، برای محیط Production ریسک جدی ایجاد می‌کند. در نسخه ۹ این ریسک بیشتر شده است؛ زیرا تداوم لایسنس به Registration، Usage Report و فایل‌های امضاشده وابسته است.

برای محیط‌های ایران، اگر Entitlement معتبر و مسیر قانونی دسترسی وجود داشته باشد، Disconnected Mode معمولاً معماری عملی‌تری است. Reserved License نیز فقط در صورت پیش‌بینی آن در قرارداد و تأیید Broadcom قابل اتکا خواهد بود.

جمع‌بندی

تغییر اصلی لایسنس VMware در نسخه ۹، حذف پراکندگی License Keyها و حرکت به سمت یک فایل اشتراکی، ظرفیت‌محور و گزارش‌پذیر بود. VCF Operations به مرکز مدیریت لایسنس تبدیل شد و VCF Business Services Console نقش مدیریت Entitlement و Allocation را بر عهده گرفت.

نسخه ۹.۱ همین معماری را یک قدم جلوتر برد:

• License Server محلی و محافظت‌شده اضافه شد.
• Connected Mode به تبادل و اعمال خودکار روزانه رسید.
• APIهای لایسنس توسعه پیدا کردند.
• نقش‌های مدیریتی دقیق‌تر شدند.
• Multi-Tenancy بهبود یافت.
• امکان استفاده از چند Primary License و چند Site ID در یک vCenter فراهم شد.

در نتیجه، لایسنس دیگر آخرین مرحله نصب VMware نیست؛ بخشی از طراحی عملیاتی Private Cloud است. اگر Allocation، گزارش مصرف، Core، ظرفیت vSAN و دسترسی پرتال از ابتدا درست طراحی نشوند، حتی یک زیرساخت کاملاً سالم نیز ممکن است در آینده با محدودیت مدیریتی روبه‌رو شود.

برای ادامه مسیر آموزش VMware و یادگیری طراحی، نصب و مدیریت زیرساخت‌های مدرن، می‌توانید دوره‌های آموزش مجازی سازی ابرکلاس را دنبال کنید.

اگر برای تهیه لایسنس نسخه 9.1 یا راه اندازی آن در سازمان خود نیاز به مشاوره دارید، تیم طراحی و مشاوره ابرکلاس همراه شما خواهد بود، کافی است این فرم را تکمیل فرمایید تا همکاران ما با شما در ارتباط باشند.