فرض کنید سازمان شما ۱۸ روتر، چند لینک WAN، یک اینترنت مرکزی و دو کنترلر بیسیم دارد. تیم شبکه میخواهد بداند چه کسی پهنای باند را مصرف میکند، کدام Application باعث اشباع لینک میشود و آیا افزایش ظرفیت واقعاً لازم است یا نه. تصمیم برای استفاده از ManageEngine NetFlow Analyzer گرفته شده، اما هنگام استعلام لایسنس یک سؤال ساده به مسئله اصلی تبدیل میشود: «ما چند لایسنس لازم داریم؟ تعداد Device مهم است یا Interface؟ Edition را بر چه اساسی انتخاب کنیم؟»
این سؤال مهم است، چون در NetFlow Analyzer مدل لایسنس با تعداد Interfaceهای مدیریتشده ارتباط مستقیم دارد و اگر Sizing را بر اساس تعداد Router یا Switch انجام دهید، ممکن است هم کمتر از نیاز خرید کنید و هم بیش از نیاز هزینه بدهید. از طرف دیگر، انتخاب Edition فقط به تعداد Interface وابسته نیست؛ نیاز به Raw Data، نگهداری تاریخی، محیط توزیعشده، Capacity Planning، Security Analytics و معماری چندسایتی هم در تصمیم اثر دارد.
در این راهنما، مدل لایسنس NetFlow Analyzer را از زاویه اجرایی بررسی میکنیم تا قبل از استعلام قیمت بدانید چه چیزهایی را باید بشمارید، چه چیزهایی را نباید بشمارید و چه اطلاعاتی باید برای Quote دقیق آماده باشد. برای استعلام رسمی قیمت محصولات ManageEngine در ایران نیز میتوانید از صفحه برآورد هزینه و قیمت لایسنس ManageEngine در مدانت استفاده کنید.
NetFlow Analyzer چه چیزی را لایسنس میکند؟
در مدل رایج NetFlow Analyzer، واحد اصلی لایسنس Interface است؛ یعنی Interfaceهایی که Flow Export از آنها دریافت میشود و قرار است در محصول بهصورت Managed فعال باشند. مستند رسمی ManageEngine توضیح میدهد که License Management فهرست Routerها و Interfaceهایی را نشان میدهد که NetFlow یا Flowهای مشابه را ارسال میکنند و تنها Interfaceهای مدیریتشده میتوانند Graph و Report کامل تولید کنند.
بنابراین «یک Router» لزوماً «یک لایسنس» نیست. اگر یک Router چهار Interface مهم دارد و روی هر چهار Interface Flow Export فعال است و شما میخواهید هر چهار را مانیتور کنید، باید آن چهار Interface را در Sizing لحاظ کنید.
| سناریو | آنچه باید در Sizing لحاظ شود | نکته |
|---|---|---|
| یک Router با دو لینک WAN | ۲ Interface | اگر هر دو لینک باید Managed باشند |
| ۱۰ Router شعبه، هرکدام یک WAN | ۱۰ Interface | در صورت مانیتور شدن فقط WAN |
| Core Switch با ۴ Uplink مهم | ۴ Interface | فقط Interfaceهای Flow-enabled و Managed |
| Router با ۲۰ Interface ولی فقط دو لینک مهم | ۲ Interface | اگر فقط همان دو Interface مدیریت شوند |
| WLC و Access Pointها | باید جداگانه بررسی شود | در Buildهای جدید، APهای WLC میتوانند در شمارش Interface اثر داشته باشند |
فرق Device Count و Interface Count؛ رایجترین اشتباه در استعلام
یکی از اشتباههای رایج این است که سازمان میگوید «ما ۳۰ Router داریم، پس لایسنس ۳۰ تایی میخواهیم.» این عدد ممکن است درست باشد، اما فقط در صورتی که دقیقاً یک Interface از هر Router قرار باشد Managed شود.
در عمل، تعداد Interfaceهای موردنیاز میتواند از تعداد Device کمتر یا بیشتر باشد. برای مثال ممکن است یک Router مرکزی چند لینک اینترنت، MPLS، Backup WAN و Inter-VLAN Interface داشته باشد. از آن طرف ممکن است صدها Switch Access در شبکه وجود داشته باشند ولی Flow Export فقط روی Core و WAN Edge فعال شود.
پس قبل از خرید، بهجای Inventory عمومی تجهیزات، یک Flow Monitoring Scope بسازید؛ یعنی مشخص کنید کدام Interfaceها واقعاً برای تحلیل ترافیک ارزش دارند.
فرمول ساده برای محاسبه اولیه لایسنس
برای برآورد اولیه میتوانید از این مدل استفاده کنید:
تعداد Interface موردنیاز = WANهای اصلی + Internet Edge + Uplinkهای حیاتی + Interfaceهای دیتاسنتر + Interfaceهای امنیتی/DMZ + سایر Interfaceهایی که نیاز به Flow Analysis دارند.
بعد از آن بهتر است ۱۰ تا ۲۰ درصد ظرفیت رشد منطقی در نظر بگیرید؛ نه برای اینکه لایسنس بیشتری بخرید، بلکه برای اینکه بدانید در ۶ تا ۱۲ ماه آینده Scope چقدر میتواند تغییر کند.
مثال: سازمان با ۱۲ شعبه
فرض کنید ساختار زیر را دارید:
- ۱۲ شعبه با یک WAN Interface در هر شعبه: ۱۲ Interface
- دو اینترنت در مرکز: ۲ Interface
- دو لینک ارتباطی دیتاسنتر: ۲ Interface
- دو Uplink مهم در Core: ۲ Interface
- یک لینک Backup که باید مانیتور شود: ۱ Interface
برآورد اولیه میشود ۱۹ Interface. در چنین حالتی انتخاب Package یا License Tier باید بر اساس نزدیکترین ظرفیت بالاتر، Edition موردنیاز و برنامه رشد انجام شود.
Free Edition و Evaluation برای Pilot چه کاربردی دارند؟
ManageEngine برای NetFlow Analyzer یک Evaluation دورهای و همچنین Free Edition محدود ارائه میکند. طبق مستندات فعلی، Free Edition امکان مانیتور کردن تا دو Interface را فراهم میکند و Evaluation نیز برای آزمایش محصول پیش از خرید قابل استفاده است.
این موضوع برای Pilot بسیار ارزشمند است. بهجای اینکه ابتدا کل شبکه را وارد Scope کنید، دو Interface مهم انتخاب کنید؛ مثلاً Internet Edge و WAN اصلی. سپس بررسی کنید آیا Flow Export درست است، Applicationها بهدرستی شناسایی میشوند، Top Talkerها معنیدار هستند و Reportها همان چیزی را نشان میدهند که تیم NOC نیاز دارد.
یک Pilot خوب قبل از خرید میتواند چند سؤال را روشن کند: آیا Sampling روی تجهیزات درست تنظیم شده؟ آیا IPFIX یا NetFlow Export پایدار است؟ آیا NAT باعث کاهش Visibility میشود؟ آیا نیاز به Raw Data دارید؟ و آیا Flow Rate واقعی شبکه با معماری انتخابشده سازگار است؟
Standard، Professional یا Enterprise؛ Edition را فقط با قیمت انتخاب نکنید
صفحه رسمی Editionهای NetFlow Analyzer سه سطح Standard، Professional و Enterprise را معرفی میکند. تفاوت آنها فقط «امکانات بیشتر» نیست؛ نوع استفاده سازمان، Data Retention، Distributed Monitoring و قابلیتهای پیشرفته هم تفاوت ایجاد میکنند.
| معیار تصمیم | Standard | Professional | Enterprise |
|---|---|---|---|
| مانیتورینگ و گزارش پایه Flow | مناسب | مناسب | مناسب |
| محیط کوچک یا متوسط | اغلب کافی | مناسب | معمولاً بیش از نیاز |
| Raw Data و تحلیل پیشرفته | بررسی دقیق Feature Matrix لازم است | مناسبتر | مناسب |
| نگهداری تاریخی بلندمدت | محدودتر | گستردهتر | گستردهتر |
| Distributed / Multi-Site Architecture | محدود | برای بسیاری سناریوها مناسب | انتخاب اصلی محیطهای بزرگ و توزیعشده |
| Security Analytics و Scale بالا | نیاز به بررسی | بسته به Add-on | مناسبتر برای معماری بزرگ |
Feature Matrix و شرایط License با Build و مدل قرارداد ممکن است تغییر کنند. برای همین، Edition را باید با Requirement واقعی سازمان تطبیق داد، نه صرفاً با یک جدول قدیمی یا قیمت مشاهدهشده در اینترنت.
Flow Rate با Interface License یکی نیست
دو سازمان ممکن است هرکدام ۵۰ Interface داشته باشند، اما Load بسیار متفاوتی روی NetFlow Analyzer ایجاد کنند. یک شبکه اداری معمولی با تعداد Flow محدود با یک دیتاسنتر پرترافیک یا Service Provider قابل مقایسه نیست.
Interface Count تعیین میکند چه تعداد Interface قرار است Managed شوند؛ Flow Rate تعیین میکند Server و Architecture باید چه حجم دادهای را پردازش کنند. بنابراین Sizing درست باید هر دو محور را بررسی کند.
در مستندات Editionهای فعلی، ManageEngine ظرفیت پردازش Flow را برای Editionها و Probeها مشخص میکند. اما این اعداد باید با Build واقعی، وضعیت Raw Data، منابع سختافزاری، Retention و نوع Flow Export تطبیق داده شوند.
Raw Data چرا روی Sizing اثر دارد؟
NetFlow Analyzer داده را در سطحهای مختلف ذخیره میکند. Raw Data برای Forensics و Drill-down دقیق بسیار مفید است، اما نگهداری آن Storage و Processing بیشتری میخواهد. اگر Requirement امنیتی یا Troubleshooting شما میگوید باید بتوانید بعداً Conversation دقیق Source/Destination را بررسی کنید، Raw Data اهمیت پیدا میکند.
از طرف دیگر، اگر هدف فقط Trend، Capacity و Top Application باشد، ممکن است Retention سنگین Raw Data ضرورت نداشته باشد. تصمیم درباره Raw Data باید قبل از Sizing Server گرفته شود، چون روی Disk، IOPS، Backup و نگهداری داده اثر دارد.
Capacity Planning؛ قبل از خرید پهنای باند، داده بخرید نه حدس
یکی از قابلیتهای کاربردی NetFlow Analyzer، Capacity Planning است. این Reportها میتوانند Trend مصرف را بر اساس Speed، Volume، Utilization و Packet نمایش دهند و برای Interfaceها و IP Groupها استفاده شوند.
نکته مهم این است که Capacity Planning فقط «نمودار مصرف» نیست. گزارش رسمی ManageEngine مقدارهای Min، Max، Average، Standard Deviation و 95th Percentile را هم نمایش میدهد. همچنین میتوان Business Hour و Weekend را فیلتر کرد تا Peakهای غیرواقعی یا خارج از ساعت کاری تصمیم را منحرف نکنند.
این قابلیت کمک میکند قبل از Upgrade لینک بپرسید: آیا مشکل واقعاً کمبود Bandwidth است؟ یا یک Application، Backup Job، Replication، Update یا Traffic Pattern غیرعادی باعث اشباع موقت شده است؟
95th Percentile چه چیزی به شما میگوید؟
اگر فقط Average مصرف را ببینید، Peakهای مهم پنهان میشوند. اگر فقط Maximum را ببینید، یک Spike کوتاه ممکن است باعث تصمیم اشتباه برای افزایش ظرفیت شود. 95th Percentile یک معیار متعادلتر برای دیدن مصرف بالا بدون تأثیر بیش از حد Spikeهای بسیار کوتاه است.
NetFlow Analyzer در Capacity Planning و Billing از Percentile استفاده میکند و در Billing مقدار 95th Percentile بهصورت پیشفرض قابل انتخاب است. این موضوع برای سازمانهایی که هزینه ارتباطات را بین واحدها Chargeback میکنند یا لینکهایی با مدل Billing مبتنی بر Percentile دارند، اهمیت بیشتری پیدا میکند.
IP Groupها؛ وقتی میخواهید هزینه پهنای باند را به واحدها نسبت دهید
همیشه سؤال شبکه این نیست که «کدام Interface شلوغ است؟» گاهی مدیر فناوری اطلاعات میخواهد بداند کدام واحد سازمانی بیشترین مصرف را دارد.
در NetFlow Analyzer میتوان IP Rangeها را در IP Groupهای منطقی قرار داد؛ مثلاً Finance، R&D، Branch-Tehran یا DataCenter-Services. سپس مصرف Bandwidth، Application و Trend هر گروه جداگانه تحلیل میشود.
این مدل برای Capacity Planning و حتی Chargeback داخلی کاربرد دارد. اگر هزینه MPLS یا اینترنت بین چند Business Unit تقسیم میشود، داده Flow میتواند تصمیم مالی را شفافتر کند.
NBAR و CBQoS چه زمانی Edition یا Scope را تغییر میدهند؟
اگر فقط Source، Destination و Protocol کافی نیست و میخواهید Application Recognition دقیقتری داشته باشید، NBAR میتواند ارزشمند باشد. در محیطهای Cisco، CBQoS نیز برای بررسی اثربخشی Policyهای QoS استفاده میشود.
NetFlow Analyzer میتواند Pre-policy، Post-policy و Drop را در CBQoS Report نمایش دهد تا مشخص شود Policy واقعاً Traffic حیاتی را محافظت کرده یا فقط روی Router تعریف شده است. این موضوع مخصوصاً برای VoIP، Video، ERP، VDI و سرویسهای Real-time مهم است.
در زمان استعلام، اگر NBAR، CBQoS، Security Analytics، NCM Add-on یا DPI جزو Requirement است، حتماً باید از ابتدا اعلام شود تا Edition و Add-on درست انتخاب شوند.
اگر OpManager دارید، NetFlow Analyzer را جدا بخریم یا یکپارچه؟
بسیاری از سازمانها در کنار Traffic Analysis به Availability، CPU، Memory، Interface Status و Device Health هم نیاز دارند. در این حالت باید معماری محصول را بهصورت یکپارچه دید.
مدانت صفحه اختصاصی OpManager Plus را برای مانیتورینگ جامع شبکه و ترافیک ارائه کرده است. اگر سازمان هم Network Monitoring و هم Flow Analysis میخواهد، بررسی OpManager Plus یا Integration بین OpManager و NetFlow Analyzer میتواند از خرید جزیرهای جلوگیری کند.
برای تیمهایی که میخواهند ابتدا معماری مانیتورینگ را طراحی کنند، مقاله Adaptive Thresholds در OpManager نیز نشان میدهد که کیفیت Alerting و Baseline چطور باید در کنار Traffic Visibility طراحی شود.
آیا تمام Interfaceها را باید لایسنس کنیم؟
نه الزاماً. هدف، Visibility معنادار است؛ نه زیاد کردن تعداد Interfaceهای Managed.
برای مثال، روی یک Access Switch ممکن است دهها Interface وجود داشته باشد، اما اگر Traffic مهم شبکه از Uplink عبور میکند و Flow Export همان Uplink اطلاعات کافی میدهد، لزوماً مانیتور کردن تکتک Access Portها ارزش ندارد.
در عوض، Internet Edge، WAN Link، DC Uplink، VPN Concentrator و Interfaceهایی که Bottleneck یا Cost بالایی دارند معمولاً اولویت بیشتری دارند.
چه Interfaceهایی معمولاً باید در فاز اول وارد Scope شوند؟
- Internet Edgeهای اصلی و Backup
- WAN / MPLS / SD-WAN Linkهای شعب
- Uplinkهای Core و Data Center
- لینکهای ارتباطی بین Siteها
- DMZ و مسیرهای سرویسهای Public
- Interfaceهای مرتبط با Cloud Connectivity
- لینکهای گران یا دارای محدودیت ظرفیت
- Interfaceهایی که سابقه Congestion دارند
یک روش سهمرحلهای برای Sizing درست
مرحله اول: Inventory
فهرست Router، Switch، Firewall، WLC و WAN Deviceها را تهیه کنید. برای هر Device مشخص کنید کدام Interface Flow Export پشتیبانی میکند و کدام Interface از نظر کسبوکار مهم است.
مرحله دوم: Monitoring Scope
Interfaceها را به سه دسته تقسیم کنید:
- Must Monitor: حیاتی و ضروری
- Should Monitor: مفید ولی غیرحیاتی
- Future Scope: برای توسعه آینده
مرحله سوم: Technical Sizing
Flow Rate، نوع Export، Sampling، Raw Data Retention، تعداد Site، HA، Database، Storage و گزارشهای موردنیاز را مشخص کنید. این مرحله تعیین میکند فقط Interface License کافی است یا باید Architecture بزرگتری طراحی شود.
Checklist اطلاعاتی که برای استعلام لایسنس باید آماده کنید
| اطلاعات | چرا لازم است؟ |
|---|---|
| تعداد Interfaceهای Must Monitor | مبنای اصلی License Sizing |
| تعداد Deviceها و Siteها | برای طراحی Architecture |
| نوع Flow: NetFlow/IPFIX/sFlow/J-Flow... | برای بررسی Compatibility |
| Flow Rate تقریبی | برای Sizing پردازش |
| نیاز به Raw Data | برای Storage و Forensics |
| Retention موردنیاز | برای Disk و Edition |
| نیاز به NBAR/CBQoS | برای Feature/Addon انتخابی |
| Multi-Site یا Distributed بودن | برای Enterprise Architecture |
| HA/Failover | برای Availability Design |
| رشد ۱۲ ماه آینده | برای جلوگیری از خرید کوتاهمدت |
چطور از Over-Licensing جلوگیری کنیم؟
Over-Licensing معمولاً وقتی رخ میدهد که سازمان بدون تعریف Scope، همه Interfaceهای موجود را در Quote وارد میکند. راه بهتر این است که Interfaceهایی را که Flow Visibility واقعی ایجاد میکنند جدا کنید.
مثلاً اگر یک شعبه فقط یک WAN Link دارد، مانیتور کردن دهها Interface داخلی ممکن است ارزش اضافهای برای هدف Capacity Planning نداشته باشد. با Pilot میتوان مشخص کرد چه سطحی از Granularity کافی است.
چطور از Under-Licensing جلوگیری کنیم؟
Under-Licensing زمانی رخ میدهد که فقط Interfaceهای فعلی شمرده شوند اما Growth، Backup Link، WLC، Site جدید یا تغییر معماری در نظر گرفته نشود.
اگر قرار است طی شش ماه سه شعبه اضافه شوند یا SD-WAN جای MPLS را بگیرد، بهتر است این تغییر در Quote اولیه مطرح شود تا Edition و ظرفیت با Roadmap سازگار باشد.
لایسنس و Architecture را جدا از هم تصمیم نگیرید
یک Quote خوب فقط عدد Interface نیست. باید مشخص کند Architecture انتخابشده برای Flow Rate، Retention و تعداد Site مناسب است. ممکن است از نظر License تعداد Interface درست باشد، اما Server از نظر CPU، Memory یا Storage برای Raw Data مناسب نباشد.
برای محیطهای بزرگ، Distributed Architecture و Probe-based Design اهمیت پیدا میکند. در این حالت Placement Probeها، پهنای باند بین Probe و Central Server و Failure Domainها هم باید بررسی شوند.
چه زمانی NetFlow Analyzer برای شما ارزش بیشتری دارد؟
NetFlow Analyzer زمانی بیشترین ارزش را دارد که سؤالهای تیم شبکه فراتر از Up/Down باشد:
- چه کسی پهنای باند را مصرف میکند؟
- کدام Application باعث Congestion شده؟
- Traffic بین کدام Source و Destination در حال رشد است؟
- آیا افزایش ظرفیت Link لازم است؟
- QoS واقعاً اثر کرده یا نه؟
- آیا رفتار Traffic غیرعادی است؟
- کدام واحد سازمانی سهم بیشتری از مصرف دارد؟
اگر نیاز فقط Availability و Device Health است، OpManager ممکن است اولویت بالاتری داشته باشد. اگر سؤال اصلی رفتار Traffic و Bandwidth است، NetFlow Analyzer لایه Visibility تخصصیتری ارائه میکند.
نکات کلیدی قبل از خرید
- لایسنس را بر اساس تعداد Device حدس نزنید؛ Interfaceهای Managed را بشمارید.
- Flow Rate و Interface Count دو مسئله جدا هستند و هر دو باید Sizing شوند.
- Free/Evaluation را برای Pilot واقعی استفاده کنید، نه صرفاً دیدن Dashboard.
- Raw Data Retention را قبل از انتخاب Server مشخص کنید.
- Edition را بر اساس Requirement انتخاب کنید، نه فقط پایینترین قیمت.
- WLC، Add-on، Multi-Site، HA و Security Analytics را از ابتدا در Scope بیاورید.
- Capacity Planning و 95th Percentile را قبل از Upgrade Bandwidth بررسی کنید.
- اگر OpManager دارید، Integration یا OpManager Plus را هم در معماری مقایسه کنید.
منابع
- ManageEngine NetFlow Analyzer Licensing
- NetFlow Analyzer License Management
- NetFlow Analyzer Editions
- Capacity Planning Reports
- NetFlow Analyzer User Guide
- NBAR and CBQoS Monitoring
سخن پایانی
خرید لایسنس NetFlow Analyzer زمانی دقیق است که قبل از قیمت، Scope را مشخص کرده باشید. تعداد Router بهتنهایی جواب نمیدهد؛ باید بدانید کدام Interfaceها واقعاً Managed میشوند، Flow Rate چقدر است، چه مقدار Raw Data نگه میدارید و آیا معماری شما تکسایتی یا توزیعشده است.
اگر این اطلاعات درست جمعآوری شوند، هم احتمال Over-Licensing کمتر میشود و هم سازمان بعد از نصب با کمبود Interface یا ظرفیت پردازشی روبهرو نمیشود. برای طراحی Scope، انتخاب Edition و دریافت Quote متناسب با تعداد Interfaceهای واقعی میتوانید از استعلام لایسنس ManageEngine مدانت یا درخواست جلسه و پروپوزال تخصصی استفاده کنید. مدانت علاوه بر لایسنس، خدمات مشاوره، پیادهسازی، آموزش و پشتیبانی NetFlow Analyzer و سایر راهکارهای ManageEngine را ارائه میکند.

