VCF Operations for Networks 9.1؛ از vRNI تا دید یکپارچه شبکه

وقتی یک ماشین مجازی به سرویس دیگری دسترسی ندارد، پرسش واقعی معمولاً این نیست که «کدام پورت Down شده؟» مسئله این است که مسیر ارتباط از کدام لایه‌ها عبور می‌کند، کدام Policy روی آن اثر گذاشته، چه تغییری پیش از اختلال رخ داده و وابستگی این ارتباط به کدام Application Tier است. VCF Operations for Networks 9.1 برای پاسخ‌دادن به همین زنجیره پرسش‌ها ساخته شده است؛ محصولی که ریشه آن به vRealize Network Insight و سپس Aria Operations for Networks می‌رسد، اما اکنون در مدل عملیاتی VMware Cloud Foundation جایگاه متفاوتی دارد.

این مقاله نقش محصول، معماری Platform و Collector، قابلیت‌های تحلیل Flow و Topology، تفاوت نسخه‌های 8، 9 و 9.1، مسیر ارتقا و محدودیت‌های اجرای آن در ایران را بررسی می‌کند. هدف، معرفی یک داشبورد دیگر نیست؛ هدف این است که بدانیم این ابزار در چه سناریویی زمان عیب‌یابی و ریسک تغییرات شبکه را واقعاً کاهش می‌دهد.

VCF Operations for Networks 9.1 دقیقاً چیست؟

VCF Operations for Networks لایه مشاهده‌پذیری و تحلیل شبکه در VMware Cloud Foundation است. این محصول اطلاعات پیکربندی، Inventory، Topology، Flow و رویدادهای منابع مختلف را جمع‌آوری و میان آن‌ها ارتباط ایجاد می‌کند. نتیجه، دیدی است که از یک VM یا Application شروع می‌شود و می‌تواند تا vCenter، Distributed Switch، NSX، Router، Switch فیزیکی و مسیر End-to-End ادامه پیدا کند.

نام محصول در نسل‌های مختلف تغییر کرده است:

vRealize Network Insight یا vRNI: نام قدیمی محصول در خانواده vRealize.
VMware Aria Operations for Networks: نام محصول در نسل Aria و دوره VCF 5.x / vSphere 8.
VCF Operations for Networks: نام جدید آن در VCF 9 و 9.1.

این تغییر فقط Rebranding نیست، اما به معنی بازنویسی کامل محصول هم نیست. در 9.1، Applianceهای Platform و Collector همچنان وجود دارند. تحول اصلی در نحوه استقرار، مدیریت Lifecycle، اتصال به VCF Operations و قرارگرفتن داده‌های شبکه در تجربه عملیاتی یکپارچه VCF دیده می‌شود.

جایگاه محصول در معماری VCF 9.1

VCF Operations 9.1 کنسول مرکزی عملیات Private Cloud است، اما برای تحلیل عمیق Flow، مسیر و Dependency به موتور تخصصی VCF Operations for Networks متکی می‌شود. بنابراین این دو محصول را نباید یکی دانست:

VCF Operations نمای کلی سلامت، ظرفیت، هزینه، Diagnostics، Lifecycle و Observability زیرساخت را ارائه می‌کند.
VCF Operations for Networks داده‌های تخصصی شبکه، Flow، Topology، Path و Application Dependency را جمع‌آوری و تحلیل می‌کند.

در رابط VCF Operations، بخش‌هایی مانند Network Operations و Flows می‌توانند داده‌های این Component را نمایش دهند. بااین‌حال، Appliance شبکه هنوز موتور Collect و Analytics مستقل خود را دارد. همین نکته مهم‌ترین تفاوت آن با VCF Log Management 9.1 است؛ Log Management به سرویس‌های کانتینری VCF Services Runtime منتقل شده، اما Operations for Networks در 9.1 همچنان Appliance-based است.

اجزای معماری: Platform Node و Collector Node

Platform Node

Platform Node مرکز پردازش، ذخیره‌سازی و ارائه تحلیل است. داده‌های دریافتی از Collectorها را نگهداری می‌کند، مدل Topology را می‌سازد، Queryها و Analytics را اجرا می‌کند و رابط کاربری محصول را در اختیار مدیر قرار می‌دهد. در محیط‌های کوچک می‌توان از یک Platform Node استفاده کرد؛ در طراحی‌های بزرگ‌تر، Cluster پلتفرم برای Scale و Availability در نظر گرفته می‌شود.

Collector Node

Collector نزدیک‌تر به Data Sourceها قرار می‌گیرد و وظیفه دریافت اطلاعات از vCenter، NSX و تجهیزات شبکه را دارد. Flowهایی مانند IPFIX، NetFlow و sFlow نیز متناسب با منبع و طراحی به Collector هدایت می‌شوند. جداسازی Collector از Platform دو مزیت دارد: کنترل بهتر مسیرهای ارتباطی و امکان توزیع Collection در سایت‌ها یا Segmentationهای مختلف.

Data Sourceها

ارزش محصول به کیفیت Data Sourceها وابسته است. افزودن صرف vCenter، تصویر کاملی از شبکه فیزیکی یا جریان واقعی ترافیک نمی‌سازد. برای دید End-to-End باید منابع مرتبط مانند NSX Manager، vCenter، Switch و Router پشتیبانی‌شده، VMware HCX و Flow Sourceها مطابق مستندات Compatibility اضافه شوند.

قابلیت‌های اصلی VCF Operations for Networks

Topology و مسیر End-to-End

محصول ارتباط میان اجزای مجازی و فیزیکی را به یک مدل قابل جست‌وجو تبدیل می‌کند. در یک سناریوی عیب‌یابی، مدیر می‌تواند از VM مبدأ و مقصد شروع کند و مسیر منطقی ارتباط، Segmentها، Gatewayها، Ruleها و تجهیزات میانی را بررسی کند. این دید برای محیط‌هایی که vSphere، NSX و شبکه فیزیکی هم‌زمان درگیر هستند، ارزش بیشتری از یک ابزار Monitoring مبتنی بر Ping دارد.

Flow Analytics

صفحه Flow Insight برای تحلیل حجم و الگوی ارتباطات، Top Talkerها، Outlierها و گروه‌های Flow استفاده می‌شود. Flow نشان می‌دهد چه Workloadهایی واقعاً با هم ارتباط دارند؛ Topology فقط می‌گوید چه ارتباطی از نظر طراحی ممکن است. ترکیب این دو، مرز میان «نقشه شبکه» و «رفتار واقعی شبکه» است.

Application Discovery و Dependency Mapping

Applicationها را می‌توان بر اساس Flow، Tag یا الگوی نام‌گذاری کشف و گروه‌بندی کرد. این قابلیت برای شناسایی Tierهای Web، Application و Database پیش از Migration یا Micro-Segmentation ضروری است. اگر Dependencyها ناقص باشند، انتقال یا اعمال Firewall Policy می‌تواند ارتباطی را قطع کند که در مستندات سنتی ثبت نشده است.

Micro-Segmentation Planning

تحلیل Flow کمک می‌کند Ruleهای پیشنهادی بر اساس ارتباط واقعی Workloadها طراحی شوند. VCF Operations for Networks جایگزین NSX یا vDefend نیست و Policy را اجرا نمی‌کند؛ داده‌ای فراهم می‌کند که طراحی Policy بر مبنای حدس انجام نشود. برای درک مرز میان شبکه و امنیت، مقاله تفاوت NSX و vDefend در VCF 9 مکمل این بحث است.

Migration Planning با HCX

در VCF 9، برنامه‌ریزی Migration به ارتباط Operations for Networks و Operations HCX نزدیک‌تر شد. Dependencyها و Application Groupها می‌توانند مبنای تعریف Migration Wave قرار گیرند و سپس اجرای جابه‌جایی به HCX سپرده شود. Operations for Networks مرحله «شناخت و برنامه‌ریزی» را تقویت می‌کند؛ HCX مسئول Mobility و اجرای Migration است.

چه چیزی در نسخه 9.1 واقعاً تغییر کرده است؟

انتقال Lifecycle به VCF Management Services

در VCF 9.0 یک Fleet Management Appliance مستقل برای مدیریت اجزای VCF معرفی شده بود. در VCF 9.1 این Appliance حذف شده و قابلیت آن میان Fleet Lifecycle و SDDC Lifecycle در VCF Management Services توزیع شده است. نصب، Import، Upgrade و Patch محصول باید از Workflowهای VCF Operations و Fleet Lifecycle انجام شود.

این تغییر مهم‌تر از ظاهر UI است؛ Operations for Networks اکنون باید عضو Inventory چرخه‌عمر VCF باشد. Broadcom صراحتاً اعلام کرده است که ارتقای Aria Operations for Networks از رابط داخلی خود محصول پشتیبانی نمی‌شود و Upgrade باید از VCF Operations Fleet LCM اجرا شود.

سخت‌گیری جدید در Certificate

برای ارتقا به 9.1، Certificate تمام Platform Nodeها و Collector Nodeها باید هر دو مقدار FQDN و IP Address را در Subject Alternative Name داشته باشد. این الزام در محیط‌های قدیمی همیشه رعایت نشده بود. نبود FQDN یا IP در SAN می‌تواند Import و Registration محصول در Fleet Lifecycle را متوقف کند.

اتصال عملیاتی به VCF Operations

پس از Deploy یا Upgrade، Adapter مربوط به Operations for Networks باید در VCF Operations ایجاد و فعال باشد تا صفحه Flows و Network Operations داده دریافت کند. سالم‌بودن Appliance به‌تنهایی کافی نیست. اگر Component در Lifecycle حالت Running دارد ولی Flows فعال نمی‌شود، وضعیت Networks Adapter، دسترسی HTTPS و Proxyهای سازمانی باید بررسی شوند.

Patch و Upgrade هماهنگ با استک

Operations for Networks در لایه Management قرار می‌گیرد و Patchهای آن در مدل عملیاتی VCF 9.1 از Lifecycle مرکزی پیگیری می‌شوند. این محصول برای ارتقای Core Stack اجباری نیست و می‌توان Upgrade آن را در Workstream جدا انجام داد؛ بااین‌حال، باقی‌ماندن طولانی روی نسخه قبلی باعث فاصله پشتیبانی و افزایش پیچیدگی Integration می‌شود.

مقایسه نسخه‌های 8، 9 و 9.1

محور	نسخه 8 / Aria 6.x	VCF 9.0	VCF 9.1
نام محصول	Aria Operations for Networks / vRNI	VCF Operations for Networks	VCF Operations for Networks
معماری اجرا	Platform و Collector Appliance	Platform و Collector Appliance	Platform و Collector Appliance
مدیریت Lifecycle	Aria Suite Lifecycle یا مدیریت مستقل	VCF Operations Fleet Management Appliance	Fleet Lifecycle داخل VCF Management Services
تجربه عملیاتی	عمدتاً کنسول مستقل محصول	شروع ادغام Network Operations و Flows با VCF Operations	ادغام Lifecycle و Adapter منسجم‌تر با VCF Operations
Migration Planning	تحلیل Dependency و برنامه‌ریزی مستقل‌تر	همگرایی بیشتر با VCF Operations HCX	ادامه مدل یکپارچه در Fleet VCF
الزام Certificate برای Transition	سخت‌گیری کمتر در بعضی استقرارهای قدیمی	وابسته به طراحی و روش مدیریت	FQDN و IP همه Nodeها باید در SAN باشند
روش Upgrade	متناسب با Aria Suite Lifecycle یا روش مستقل	از Workflowهای Fleet Management	فقط از VCF Operations Fleet Lifecycle برای محیط VCF

نتیجه جدول روشن است: نسخه 9.1 بیشتر یک تغییر در Control Plane مدیریتی و Lifecycle است تا تعویض موتور تحلیل شبکه. بنابراین سازمانی که انتظار دارد همه محدودیت‌های vRNI/Aria با نصب 9.1 ناپدید شوند، انتظار درستی ندارد.

مسیر ارتقا از Aria Operations for Networks

نسخه مبدأ، سلامت Platform Cluster و Collectorها را مستند کنید.
برای مسیر VCF 9.1، محصول Aria Operations for Networks باید ابتدا به نسخه 6.14 برسد.
Snapshot و Backupهای توصیه‌شده را پیش از عملیات آماده کنید و فضای دیسک و سلامت Data Store داخلی را بررسی کنید.
Certificate همه Platform و Collector Nodeها را کنترل کنید؛ FQDN و IP باید در SAN وجود داشته باشند.
محصول را از مسیر Build > Lifecycle > VCF Management به Fleet Inventory وارد کنید.
Upgrade را از Workflow رسمی VCF Operations انجام دهید، نه از UI داخلی Operations for Networks.
پس از ارتقا، نسخه همه Platform و Collector Nodeها باید یکسان باشد.
Networks Adapter، دریافت Data Sourceها و فعال‌شدن Flow Collection در VCF Operations را کنترل کنید.

در محیط Brownfield ممکن است Collectorهای قدیمی در Fleet Lifecycle نمایش داده نشوند. طبق KB رسمی Broadcom این موضوع می‌تواند محدودیت نمایش و مدیریت Day-2 باشد و لزوماً به معنی خرابی Collection نیست. Collectorهای قدیمی حتی در این وضعیت همراه Component اصلی Upgrade می‌شوند، اما عملیات Power و Scale ممکن است مستقیماً از vCenter انجام شود.

نیازمندی‌هایی که پیش از Deploy یا Upgrade باید بررسی شوند

DNS مستقیم و معکوس معتبر برای Nodeها و تطابق کامل با Certificate.
IP و FQDN مجزا برای Platform و Collector و ثبت دقیق آن‌ها در Workbook طراحی.
دسترسی HTTPS میان VCF Operations، VCF Management Services و Operations for Networks.
دسترسی Collector به vCenter، NSX و تجهیزات یا Flow Sourceهای موردنظر.
ظرفیت Compute و Storage متناسب با Brick Size و حجم Flow؛ نه صرفاً تعداد VMها.
هماهنگی NTP در تمام اجزا؛ اختلاف زمان تحلیل رویداد و Flow را مخدوش می‌کند.
بررسی Proxy؛ Proxy احرازهویت‌شونده می‌تواند ثبت Adapter را مختل کند.
تطابق دقیق Build میان Platform و Collector؛ Version Mismatch باعث رد Heartbeat می‌شود.

انتخاب سایز باید با نرخ Flow، تعداد Entity، تعداد Data Source و Retention انجام شود. استفاده از Small Lab برای محیط Production پرترافیک، حتی اگر Deploy موفق باشد، به معنی طراحی صحیح نیست.

سناریوی واقعی: چرا یک Application بعد از تغییر Firewall قطع شد؟

فرض کنید سرویس فروش سه Tier دارد: Web، API و Database. پس از اعمال Policy جدید NSX، بخشی از تراکنش‌ها Timeout می‌شوند، اما Ping میان VMها برقرار است.

Application در Operations for Networks بر اساس Tag و Flow شناسایی می‌شود.
Flowهای Blocked و Protected میان Tierها بررسی می‌شوند.
مسیر VM-to-VM برای تراکنش ناموفق با مسیر سالم مقایسه می‌شود.
Rule مؤثر، Service و Segment در Topology مشخص می‌شوند.
تغییر Policy با زمان شروع خطا تطبیق داده می‌شود.
پس از اصلاح Rule، بازگشت Flow و کاهش Drop از همان View کنترل می‌شود.

بدون این ابزار، تیم Virtualization، Network و Security ممکن است هرکدام سلامت بخش خود را گزارش کنند. Operations for Networks مسئله را از دید مسیر Application بازسازی می‌کند و نقطه مشترک میان این تیم‌ها می‌سازد.

این محصول برای چه سازمانی ارزش دارد؟

اگر محیط تنها چند Host، یک vCenter و شبکه‌ای ساده دارد، هزینه منابع و نگهداری این Component ممکن است توجیه نداشته باشد. ارزش واقعی آن در این شرایط ظاهر می‌شود:

چند vCenter، چند سایت یا چند Workload Domain دارید.
NSX، شبکه فیزیکی و تجهیزات چند Vendor هم‌زمان در مسیر ترافیک هستند.
برای Micro-Segmentation به Flow واقعی و Dependency Mapping نیاز دارید.
Migrationهای بزرگ باید در Waveهای کنترل‌شده انجام شوند.
زمان عیب‌یابی بین تیم‌های Network، Virtualization و Application زیاد است.
برای Audit و تحلیل تغییرات به تاریخچه قابل جست‌وجو نیاز دارید.

آیا VCF Operations for Networks 9.1 در ایران قابل استفاده است؟

از نظر فنی، موتور Collection و Analytics در دیتاسنتر مشتری اجرا می‌شود و برای تحلیل روزمره Flow، Topology و Data Sourceهای داخلی الزام ذاتی به Cloud عمومی ندارد. بنابراین استقرار On-Premises و استفاده عملیاتی در شبکه داخلی ایران امکان‌پذیر است.

محدودیت اصلی فنی نیست؛ دسترسی تجاری و عملیاتی به Entitlement، Binary، Patch، Activation Code، Support Portal و خدمات پشتیبانی Broadcom است. برای محیط‌های ایران باید از ابتدا سناریوی Disconnected Depot، نگهداری امن Binaryها، مستندسازی Buildها و روش تأمین قانونی Entitlement مشخص شود. نبود دسترسی پایدار به Portal را نباید با نبود نیاز به Update اشتباه گرفت.

این مقاله وجود محدودیت منطقه‌ای صریح در موتور On-Premises محصول را ادعا نمی‌کند، چون در مستندات فنی بررسی‌شده چنین Blockی اعلام نشده است. بااین‌حال، امکان خرید، Download و دریافت Support تابع قرارداد، شریک تجاری، قوانین صادراتی و وضعیت حساب Broadcom است و باید پیش از طراحی Production به‌صورت مستقل تأیید شود.

جایگاه موضوع در مسیر آموزش VMware

در یک مسیر درست آموزش VMware، یادگیری Operations for Networks باید بعد از مبانی vSphere Networking، NSX و Flow Monitoring قرار گیرد. مشاهده داشبوردها بدون فهم VLAN، Routing، DVS، Overlay و Firewall Policy مهارت عملی تولید نمی‌کند.

برای دانش‌پذیر آموزش مجازی سازی، این محصول پلی میان مدیریت VM و عملیات شبکه است. در مسیر آموزش VCF، تمرکز باید روی Integration، Fleet Lifecycle و طراحی Multi-Site باشد. در آموزش VVF نیز شناخت مرز قابلیت‌های پایه Operations با سرویس‌های پیشرفته VCF مانع طراحی اشتباه می‌شود. مقاله VCF Operations 9.1 تصویر کامل‌تری از کنسول مرکزی عملیات ارائه می‌کند و مقاله مهاجرت از Aria Suite به VCF 9.1 تغییر نام و Lifecycle محصولات قدیمی را توضیح می‌دهد.

جمع‌بندی فنی

VCF Operations for Networks 9.1 یک محصول جدید با موتور کاملاً متفاوت نیست؛ بلوغ همان تبار vRNI و Aria Operations for Networks در معماری مدیریتی VCF است. Platform و Collector باقی مانده‌اند، اما Lifecycle از Appliance مستقل 9.0 به VCF Management Services منتقل شده، Certificateها سخت‌گیرانه‌تر شده‌اند و Integration با VCF Operations نقش جدی‌تری پیدا کرده است.

برای سازمانی با NSX، چند سایت، Migration گسترده یا Micro-Segmentation، ارزش محصول در سه خروجی خلاصه می‌شود: دید مسیر واقعی، شناخت Dependency برنامه‌ها و تبدیل Flow به تصمیم عملیاتی. اگر این سه نیاز وجود ندارد، Deploy کردن Component صرفاً برای تکمیل فهرست محصولات VCF، منابع و پیچیدگی غیرضروری ایجاد می‌کند.

سؤالات متداول

آیا VCF Operations for Networks 9.1 همان Aria Operations for Networks است؟

ادامه همان محصول و معماری اصلی است، اما با نام جدید و Integration و Lifecycle متناسب با VCF 9.1. Broadcom نیز در KB رسمی این نام‌های قبلی را صراحتاً ذکر کرده است.

آیا این Component در VCF 9.1 اجباری است؟

خیر. Broadcom آن را جزء Core Upgrade اجباری معرفی نکرده و Deploy یا Upgrade آن می‌تواند بعداً انجام شود. نیاز واقعی باید بر اساس Flow Analytics، Network Visibility و Migration Planning تعیین شود.

آیا Operations for Networks جایگزین NSX Manager است؟

خیر. NSX شبکه و Policy را ایجاد و اجرا می‌کند؛ Operations for Networks وضعیت، مسیر، Flow و Dependency را مشاهده و تحلیل می‌کند.

آیا می‌توان مستقیماً از Aria Operations for Networks 6.14 به 9.1 رفت؟

مسیر رسمی مستلزم آماده‌سازی نسخه 6.14، Import در Fleet Lifecycle و اجرای Workflowهای ارتقا از VCF Operations است. جزئیات دقیق باید بر اساس نسخه Build مبدأ و Release Notes جاری کنترل شود.

چرا بعد از Deploy صفحه Flows در VCF Operations فعال نمی‌شود؟

یکی از علت‌های مستندشده ایجادنشدن خودکار Networks Adapter است. ارتباط HTTPS، Proxy، Inventory Sync و وضعیت Adapter باید بررسی شوند؛ Running بودن Appliance به‌تنهایی اثبات‌کننده Integration کامل نیست.

آیا نسخه 9.1 در محیط کاملاً آفلاین کار می‌کند؟

عملیات Collection و Analytics داخلی می‌تواند On-Premises انجام شود، اما تهیه Binary، Patch، Entitlement و Lifecycle Bundle باید در طراحی Disconnected Depot پیش‌بینی شود.