خلاصه اجرایی: محاسبه License فقط ضرب تعداد Server در یک عدد نیست. باید Scope حقوقی و فنی، Coreهای قابل محاسبه، ظرفیت رزرو، طراحی Consolidation، انتخاب VCF یا VVF و اقلام خارج از Bundle روشن شوند. این صفحه قیمت ثابت یا Quote عمومی ارائه نمیکند؛ چون شرایط تجاری و Entitlementها باید در تاریخ خرید از کانال رسمی تأیید شوند.
چرا Licensing یک مسئله معماری است؟
تعداد Core فقط یک داده مالی نیست. انتخاب CPU پرهسته، تعداد Host، سطح HA، تفکیک Management و Workload، رشد سهساله و تصمیم میان Consolidation یا Expansion همزمان بر ظرفیت فنی و دامنه خرید اثر میگذارند. اگر Licensing بعد از طراحی بررسی شود، ممکن است معماری از نظر فنی درست اما از نظر هزینهای نامتناسب باشد.
از طرف دیگر، کمبرآوردکردن دامنه برای کاهش رقم اولیه میتواند ظرفیت Failover، رشد یا رعایت Entitlement را به خطر بیندازد. هدف Commercial Architecture پیدا کردن «کمترین عدد» نیست؛ ساختن BOM قابل دفاع برای سناریوی عملیاتی واقعی است.
نسخه قرارداد، SKU، Subscription Term و قواعد تجاری میتوانند تغییر کنند. محتوای وب باید روش تصمیم را توضیح دهد، نه اینکه جای Quote و قرارداد رسمی بنشیند.
برای برآورد اولیه چه دادهای لازم است؟
فهرست Compute
تعداد Host، تعداد Socket، Core فعال هر CPU، مدل CPU و اینکه کدام Host واقعاً در Scope است.
توپولوژی Cluster
Management، Workload، Edge، DR، Stretched/Separate site و هر ظرفیت رزرو یا Standby.
نیاز عملیاتی
Automation، Operations، Network virtualization، Kubernetes، Multi-tenancy، رشد و سطح پشتیبانی مورد نیاز.
مرز سازمانی
شرکتها و واحدهای حقوقی، محیط Production/DR/Lab، محل استقرار و نحوه استفاده از ظرفیت.
Inventory ناقص معمولاً خودش را در Quote نشان نمیدهد؛ بعداً هنگام Deployment، True-up یا رشد آشکار میشود. برای همین Source of Truth باید مشخص باشد و هر عدد تاریخ و Owner داشته باشد.
محاسبه Core را چگونه قابل ممیزی کنیم؟
بهجای نوشتن یک عدد نهایی بدون توضیح، محاسبه باید Host-by-Host قابل بازبینی باشد. برای هر سرور، مدل CPU، تعداد Socket، Core فیزیکی فعال و وضعیت قرارگیری در Cluster ثبت میشود. سپس قواعد همان SKU و قرارداد روی داده اعمال میشود. اگر حداقل Core یا ضریب خاصی در پیشنهاد تجاری وجود دارد، باید عیناً از سند رسمی همان Quote استخراج شود؛ نه از حافظه یا محتوای قدیمی اینترنت.
| Host | CPU/Sockets | Core فیزیکی | نقش | وضعیت در Scope | مرجع Evidence |
|---|---|---|---|---|---|
| Host Group A | از Inventory واقعی | قابل شمارش | Management | تأیید/نیازمند بررسی | vCenter + BOM سازنده |
| Host Group B | از Inventory واقعی | قابل شمارش | Workload | تأیید/نیازمند بررسی | vCenter + قرارداد |
| DR Hosts | مستقل ثبت شود | قابل شمارش | DR/Standby | براساس حقوق استفاده | Quote و Terms رسمی |
عدد ساختگی میتواند بهاشتباه بهعنوان قاعده عمومی برداشت شود. Workbook واقعی باید با Inventory سازمان و Terms همان زمان تکمیل شود.
طراحی Cluster چگونه هزینه را تغییر میدهد؟
دو معماری با ظرفیت کاربردی مشابه میتوانند Core Count متفاوتی بسازند. CPUهای بسیار پرهسته، Hostهای زیاد با Utilization پایین، تفکیک بیش از حد Clusterها و ظرفیت رزروی بدون تحلیل از عوامل رایجاند. در مقابل، Consolidation افراطی ممکن است Fault Domain، Maintenance و Blast Radius را بدتر کند.
| تصمیم | اثر بالقوه بر هزینه | اثر عملیاتی | سؤال کنترل |
|---|---|---|---|
| CPU پرهستهتر | افزایش Core در هر Host | Consolidation بیشتر، Failure impact بزرگتر | آیا Workload واقعاً از این تراکم استفاده میکند؟ |
| Host بیشتر | Core Scope بالاتر | Maintenance و Failure Domain منعطفتر | N+۱ یا N+۲ چگونه محاسبه شده است؟ |
| Clusterهای جدا | احتمال ظرفیت تکراری | Isolation و Governance بهتر | تفکیک فنی لازم است یا فقط تاریخی؟ |
| DR اختصاصی | وابسته به حقوق استفاده و ظرفیت | Recovery شفافتر | Active/Passive و تست DR چگونه تعریف شده؟ |
بهینهسازی واقعی زمانی رخ میدهد که Cost per usable capacity، Availability، رشد و محدودیتهای License با هم سنجیده شوند.
انتخاب VCF یا VVF از روی تعداد VM انجام نمیشود
VCF و VVF فقط دو بسته با قیمت متفاوت نیستند؛ سطح متفاوتی از Operating Model، Automation، Network/Storage Integration و Cloud Management را هدف میگیرند. انتخاب باید از Use Case شروع شود: آیا سازمان به مدل Private Cloud یکپارچه، Lifecycle گستردهتر، Kubernetes، چندمستاجری یا شبکه پیشرفته نیاز دارد؟ یا هدف اصلی، مجازیسازی Compute با دامنه سادهتر است؟
ویژگیها و Entitlementها در نسخهها و قراردادها تغییر میکنند. بنابراین Decision Matrix باید با Feature Comparison رسمی همان Release و Quote روز تطبیق داده شود. مقاله مستقل مقایسه VCF و VVF این تصمیم را از منظر عملیاتی باز میکند.
BOM فنی با BOM تجاری چه تفاوتی دارد؟
BOM فنی
Host، CPU، RAM، NIC، Storage، Site، ظرفیت، رشد، Availability و اجزایی که برای معماری مقصد لازماند.
BOM تجاری
SKU، Quantity، Term، Support، Add-on، شرایط استفاده، Currency/Validity و ارجاع به Quote رسمی.
این دو باید Traceable باشند: هر Quantity تجاری باید به یک نیاز یا دارایی فنی برگردد و هر جزء فنی باید مشخص کند در کدام SKU یا Entitlement پوشش داده میشود. اقلام مبهم در یک Assumption Register باقی میمانند تا پیش از Purchase بسته شوند.
سه سناریوی تصمیم، بدون عددسازی
حفظ وضع موجود
کمترین تغییر سختافزار؛ مناسب وقتی Compatibility و Headroom کافی است. ریسک آن، ادامهدادن تراکم یا Core Count نامتناسب تاریخی است.
Consolidation کنترلشده
کاهش تعداد Host یا بازطراحی CPU با حفظ HA. نیازمند تحلیل Performance، Maintenance و Failure Domain است.
رشد مرحلهای
خرید برای ظرفیت نزدیک و تعریف Trigger برای Wave بعد. نیازمند قرارداد روشن و پیشبینی زمان Procurement است.
در خروجی، این سناریوها با شاخصهایی مثل ظرفیت قابلاستفاده، Headroom، ریسک، پیچیدگی عملیات و TCO مقایسه میشوند. قیمت قطعی فقط از Quote معتبر میآید.
خطاهای رایج در License Planning
- شمارش VM یا Socket بهجای استفاده از مدل و Terms جاری؛
- نادیدهگرفتن Hostهای DR، Standby یا ظرفیت رزرو بدون بررسی حقوق استفاده؛
- استفاده از Core Count دیتاشیت بهجای Inventory واقعی و CPU فعال؛
- فرض اینکه همه قابلیتهای مورد نیاز داخل یک Bundle قرار دارند؛
- خرید پیش از نهاییشدن Architecture و Hardware Readiness؛
- ثبتنکردن Assumptionها و وابستهکردن تصمیم به یک فایل شخصی؛
- مقایسه Quoteها بدون یکسانکردن Term، Support و دامنه فنی.
چه مدارکی باید همراه درخواست خرید باشد؟
Inventory امضاشده
Host، CPU، Core، Role و Scope با تاریخ استخراج.
Architecture Decision Record
چرا VCF یا VVF، چرا این Cluster layout و چه گزینههایی رد شدهاند.
Quantity Workbook
محاسبه قابل ردگیری، Assumptionها، رشد و سناریوهای جایگزین.
Entitlement Matrix
نیازها، قابلیتها، SKUها، Add-onها و موارد نیازمند تأیید رسمی.
Quote Comparison
Validity، Term، Support، Currency، مالیات و شرایط بهصورت هممبنا.
خروجی خدمت Licensing راگا
- Core Inventory و Scope Map قابل ممیزی؛
- Technical/Commercial BOM با ارتباط شفاف بین نیاز و Quantity؛
- مقایسه سناریوهای حفظ، Consolidation و رشد؛
- VCF/VVF Decision Matrix بر مبنای Use Case؛
- Assumption، Risk و Open Question Register؛
- فهرست پرسشهای لازم برای Distributor/Vendor پیش از Quote نهایی؛
- Executive Summary برای تیم فنی، Procurement و مدیریت.
مرز تعهد و اطلاعات متغیر
این صفحه مشاوره حقوقی یا Quote فروش نیست. قیمت، Discount، Currency، Tax، حداقلها، حق استفاده در DR و ترکیب SKUها باید در تاریخ خرید از اسناد رسمی و قرارداد تأیید شوند. هیچ محاسبهای بدون Inventory معتبر و Scope سازمانی نباید مبنای Purchase Order قرار گیرد.
پرسشهای متداول
آیا تعداد VM برای برآورد License کافی است؟
خیر. VM Count برای Capacity Planning مفید است اما Quantity تجاری به مدل جاری و Core/Scope زیرساخت وابسته است.
آیا CPU پرهسته همیشه اقتصادیتر است؟
نه. ممکن است تعداد Host را کم کند اما Core Scope و Blast Radius را بالا ببرد. باید TCO و Availability همزمان بررسی شوند.
آیا میتوان قیمت قطعی را در سایت اعلام کرد؟
قیمت و شرایط قراردادی متغیرند. سایت باید روش و دامنه را روشن کند و Quote رسمی، تاریخ اعتبار و Terms داشته باشد.
آیا آزمایشگاه و DR همیشه از محاسبه خارجاند؟
نمیتوان چنین قاعده عمومیای داد. حقوق استفاده و شرایط قرارداد باید صریحاً بررسی شوند.