تاریخچه

 

سیسکو در سال 2004 محصول DCNM را برای مدیریت پیکربندی SAN ارائه کرد. با ظهور تجهیزات نکسوس و به طور خاص سوئیچ های سری 5000 و 7000 در سال 2008 این ابزار برای مدیریت شبکه های LAN و SAN تکامل پیدا کرد.

نسخه 11 از DCNM به عنوان یک ابزار automation آماده برای پیکربندی و مدیریت سوئیچ های MDS، تجهیزات FEX، سوئیچ های N5K، N7K و Nexus 1000v به شمار می رفت. اما این محصول از نسخه 11.3 به بعد قادر بود غیر از خانواده nexus، سوئیچ ها و روترهای مبتنی بر IOS-XE، IOS-XR و حتی برخی از محصولات غیر سیسکویی را نیز پیکربندی و مدیریت نماید.

بر طبق دیتاشیت محصول، نسخه 11.5.3 پشتیبانی از زیرساخت SAN را کنار گذاشت! اما این آخرین نسخه این محصول با این نام محسوب می شد.

از نسخه 12 محصول DCNM سیسکو به Fabric Controller تغییر نام یافت و البته در نخستین datasheet با عنوان کامل Nexus Dashboard Fabric Controller یا NDFC نامیده می شود؛ یک تحول مهم در معماری و پلتفرم نرم افزاری جدید و متفاوت.

بر خلاف DCNM v11 که بصورت ova و یا سخت افزار مستقل عرضه می شد، محصول Fabric Controller حالا به عنوان یک مایکروسرویس روی یک پتلفرم مبتنی بر Container راه اندازی می گردد، user interface جدید دارد و کماکان پشتیبانی از SAN در دستور کار آن می باشد.

این پلتفرم Container-based که مقرر شد سرویس های مستقل بیشتری روی آن منتقل و یکپارچه گردند، Nexus Dashboard نام دارد.

در کنار رشد و توسعه DCNM، سال 2014 سیسکو محصول Application-Centric Infrastructure (ACI) را معرفی کرد؛ فناوری SDN سیسکو برای دیتاسنتر روی برخی سوئیچ های نکسوس 9000؛ سیستم عامل متفاوت از NXOS و مستقل از حوزه مدیریتی DCNM و NDFC.

محصول ACI اگرچه در واقعیت با Open Standard SDN تفاوت های عملکردی معناداری دارد که مهم نیست!، یکی از موفق ترین محصولات در قالب پکیج نرم افزار + سخت افزار از سوی سیسکو به شمار می رود که به ادعای خود سیسکو تاکنون بیش از 13000 مشتری با زیرساخت فعال در سطح جهان دارد.

بر خلاف زیرساخت های سنتی که در آنها داشتن DCNM یا Fabric Controller یک آپشن و ارزش افزوده محسوب می شود، کنترلر ACI یا همان APIC که پوینت مرکزی برای مدیریت پیکربندی و مانیتورینگ این فناوری به شمار می رود، ذاتا یک component اصلی و جدا ناپذیر از پکیج کلی است.

نکته: اصولا طبق تعریف، SDN Controller یکی از اجزاء اصلی در Software-defined networking محسوب می شود.

با توسعه ACI از نسخه 3 به بعد، راهکار Multi-Site معرفی شد که جدای از کلاستر APIC، حالا یک component نرم افزاری جدید با نام Multi-Site Orchestrator (MSO) به آن اضافه شد که نقش مدیریت و مانیتورینگ مجموعه ای از Fabric های مبتنی بر ACI را بر عهده داشته و برخی از پیکربندی ها بصورت متمرکز در یک یا چند سایت توسط آن انجام می پذیرد.

محصول ACI MSO تا پیش از نسخه 3.2، مانند DCNM v11 مستقل بود اما از این نسخه به بعد به یکی دیگر از مایکرو سرویس های روی Nexus Dashboard تغییر یافت و از این پس با عنوان تازه Nexus Dashboard Orchestrator (NDO) شناخته می شود.

---

تا به این جا، دو محصول که نقش پیکربندی، مدیریت و مانیتورینگ مرکزی زیرساخت های مبتنی بر ACI و non-ACI را بر عهده دارند، روی پلتفرم Nexus Dashboard منتقل و عرضه شده اند. اما این داستان همچنان ادامه دارد.

در ادامه و طی سال های 2017 و 2018 سیسکو ابزارهای دیگری را با هدف analytics و telemetry ارائه کرد که در کنار DCNM و MSO مدیریت پیکربندی زیرساخت ها را توسعه می دادند. این ابزار شامل موارد زیر بودند:

• Network Assurance Engine
• Network Insights Advisor
• Network Insights Resources

شاید بد نباشد پیش از معرفی اینها اصطلاح Telemetry را تشریح کنم.

اصطلاح Telemetry

Telemetry مکانیزمی است برای جمع‌آوری خودکار اطلاعات از کل تجهیزات و انتقال آنها به یک یا چند سامانه مرکزی به‌منظور مانیتورینگ، تحلیل و پایش وضعیت شبکه. واژه Telemetry از دو ریشه یونانی tele به معنای «دور» و metron به معنای «اندازه‌گیری» گرفته شده است.

با تمرکز روی شبکه، تجهیزات شبکه Data Source محسوب شده و داده های عملیاتی (Operational Data)، تنظیمات پیکربندی (Configuration Data) و رویدادهای سیستم (Event Data) را به  Data Collectorهای مرکزی ارسال می‌کنند تا امکان مانیتورینگ و تحلیل متمرکز آنها فراهم شود.

اما کاربردهای Telemetry تنها به مانیتورینگ محدود نمی‌شود و طیف گسترده‌ای از سناریوها را شامل می‌شود؛ از جمله تحلیل عملکرد شبکه، Business Intelligence، ظرفیت‌سنجی و برنامه‌ریزی توسعه شبکه، تحلیل‌های امنیتی، Accounting، ثبت وقایع (Logging) و همچنین Traffic Engineering.

کمی پس از عرضه سه محصول فوق در سال 2019 دو ابزار Insights Advisor و Insights Resources با یکدیگر ادغام شدند و یک ابزار جدید به نام Network Insights ایجاد شد. از سوی دیگر در سال 2021، Assurance Engine به طور کلی منقضی شد. لذا تنها ابزار Network Insights، در قالب یک مایکروسرویس جدید روی پلتفرم Nexus Dashboard منتقل شد و از این پس با عنوان Nexus Dashboard Insights (NDI) شناخته می شود. بد نیست کمی به معرفی این محصول شاید کمتر شناخته شده بپردازم.

---

Cisco Nexus Dashboard Insights (NDI)

احتمالا نخستین موضوع در معرفی این ابزار باید این باشد که اصولا NDI یک ابزار مانیتورینگ ساده و کلاسیک مانند OPmanager یا PRTG نیست؛ بلکه درواقع یک پلتفرم Assurance و Analytics برای Day-2 Operations محسوب می شود. یادآوری می کنم:

Day-0 (Planning & Design)

طراحی، معماری و آماده‌سازی زیرساخت قبل از راه‌اندازی

Day-1 (Deployment)

نصب، راه‌اندازی، پیکربندی اولیه و تحویل سرویس

Day-2 (Operations)

مدیریت، مانیتورینگ، عیب‌یابی، بهینه‌سازی و اعمال تغییرات پس از اینکه شبکه وارد محیط عملیاتی شد.

هدف از استقرار این سامانه، دستیابی به درک عمیق‌تری از رفتار شبکه (Network Behavior)، کشف ناهنجاری‌ها (Anomaly Detection)، تحلیل علت ریشه‌ای مشکلات (Root Cause Analysis)، اعتبار سنجی وضعیت و Policyهای شبکه (Network Assurance) و کاهش ریسک تغییرات است؛ نه صرفاً جمع‌آوری شاخص‌هایی مانند میزان مصرف CPU یا Interface Counter.

به زبان ساده، هدف NDI این است که عملیات شبکه از حالت Reactive (بعد از وقوع مشکل) به حالت Proactive (قبل از اینکه کاربر متوجه شود) تبدیل شود و این کار را با سه موتور اصلی انجام میدهد:

Streaming Telemetry Analytics

دریافت دائمی Telemetry از همه تجهیزات.

Assurance Engine

برگرفته از هسته ابزار Network Assurance Engine (NAE)؛ تحلیل شبکه مبتنی بر مدل منطقی شبیه‌سازی شده و اعتبار سنجی عملکرد آن مطابق با نیاز.

Correlation Engine

ارتباط دادن Flow، Log، Event، Configuration و Application Data به یکدیگر.

بنابراین این ابزار فقط SNMP Polling نیست بلکه از Streaming Telemetry  استفاده کرده و Control Plane و Data Plane را باهم می بیند. مهمتر اینکه تحلیل ها در سطح Fabric-wide انجام می شود، نه Device-by-Device. پارامترهای زیر را درنظر بگیرید:

BGP Flap

CRC Error

Packet Drop

Latency Spike

Buffer Drop

ACL Drop

Endpoint Move

به عنوان مثال درباره Latency، پس از پایش مستمر رفتار شبکه NDI در میابد که عدد استاندارد برای latency مربوط به یک flow خاص، دو میلی ثانیه است. اگر این عدد به 20 میلی ثانیه برسد آلارم می دهد.

اگر CRC Error روی یک لینک رخ دهد، فقط Alarm نمیدهد بلکه سعی میکند مشخص کند کدام  Flowها تحت تأثیر قرار گرفتند؛ کدام  Endpointها آسیب دیدند؛ آیا همزمان DOM Anomaly هم وجود داشته؛ احتمالاً علت اصلی چیست؟؟ ضمن اینکه برای هر Flow میتواند path دقیق، میزان Latency end-to-end و حتی محل دقیق drop شدن و علت آن را تحلیل کرده و نمایش دهد.

از سوی دیگر در خصوص Network Assurance، ابزار NDI از شبکه Snapshot میگیرد و یک مدل منطقی و شبیه سازی شده از آن میسازد. سپس بررسی میکند که آیا پیکربندی مورد نظر صحیح است؟؟ آیا Operational State با Configuration مورد نظر سازگار است؟ آیا connectivity طبق انتظار برقرار خواهد بود یا پالیسی ها درست و مطابق انتظار پیش خواهند رفت یا خیر.

و البته قابلیت ها و فیچرهای دیگر که می توانید اطلاعات آنها را از دیتاشیت سیسکو برای این محصول بگیرید.

Cisco Nexus Dashboard Insights White Paper, Release 6.0.1

نکته: لازم به ذکر است، این ابزار قرار نیست برای شما کار Cisco Secure Workload را انجام دهد و به عنوان مثال پس از سه ماه راه اندازی توسط آن بفهمیم کدام workload با کدام workload و سرویس باید بتواند درارتباط باشد یا نباشد. کشف روابط میان اجزای سرویس ها کار NDI نیست، اگرچه شاید بتوان اطلاعاتی در این خصوص از آن استخراج کرد.

جمع بندی اینکه: برای زیرساخت های بزرگ و Enterprise، متشکل از چندین سایت؛ شاید ترکیبی از ACI و NXOS در جایی که سرعت عمل و زمان در کشف Root cause بسیار مهم است و outage هزینه بالایی به همراه دارد، داشتن ابزار NDI می تواند بسیار کارآمد باشد.

---

از توضیحات فوق بگذریم، نهایتا از سال 2021،  سه محصول اصلی Orchestrator، Fabric Controller و Network Insights روی یک پلتفرم نرم افزاری و هاستینگ یکسان با عنوان Nexus dashboard عرضه و تحت عناوین زیر شناخته شدند:

Nexus dashboard Orchestrator (formerly known as MSO) for ACI Multi-Site solution — NDO

Nexus dashboard Insights — NDI

Nexus dashboard Fabric Controller – NDFC

سرویس چهارم: Cisco Nexus Dashboard Data Broker (NDDB)

یکی دیگر از سرویس های ارائه شده سیسکو که از نسخه ای به بعد نام Nexus Dashboard را یدک می کشد، Data Broker است. اما این سرویس از نظر deployment با سه سرویس قبلی کاملا متفاوت و مستقل است.

سرویس Data Broker را میتوان یک لایه هوشمند مدیریت و توزیع ترافیک های Mirror شده (SPAN/ERSPAN) در نظر گرفت که امکان دریافت، پردازش، فیلترینگ و ارسال مجدد Packetها به مقصد های مختلف را بصورت real-time فراهم میکند. به این ترتیب، نیاز نیست هر ابزار و سرویس پایش در شبکه اقدام به اجرای SPAN به صورت مستقل نماید؛ بلکه میتواند از جریانهای پردازش شده توسط Data Broker استفاده کرده و با فیلترینگ های مناسب، جریان Packet مورد نیاز خود را دریافت نماید. اصولا SPAN Session ها دارای rate محدود هستند و چنانچه ابزارهای گوناگون بصورت مستقل اقدام به دریافت این اطلاعات نماید، منابع ASIC تجهیزات، ظرفیت خروجی SPAN و پهنای باند شبکه را تحت تاثیر قرار میدهند.

با استفاده از ابزار Data Broker می توان دیتای دریافتی را به عنوان مثال بر اساس VLAN، رنج آی پی، سرویس و پورت خاص فیلتر کرد. علاوه بر این، بدیهی است ترافیک یکسان می تواند از مسیرهای گوناگون دریافت شود؛ Data Broker می تواند duplicate ها را شناسایی و حذف نماید.

همچنین این ابزار امکان load balancing ترافیک تجمیعی را بین مقاصد خاص دارد. به عنوان مثال: اگر چند نود IDP داشته باشیم که هر کدام بخواهند حدود 2 گیگابایت از ترافیک را دریافت کنند یا بالعکس، چند دستگاه بخواهند همزمان ترافیک های یکسانی را دریافت نمایند.

یکی دیگر از قابلیت های Data Broker، قابلیت Packet Manipulation است. به این معنا که این ابزار می تواند به عنوان مثال: تگ یک VLAN خاص را حذف کند؛ VLAN جدید اضافه کند؛ هدر پکت را تغییر دهد یا packet truncation انجام دهد. علاوه بر این می تواند User Defined Field (UDF) بر اساس Offsetهای دلخواه تعریف کند و روی آن فیلتر بنویسد. این قابلیت برای شناسایی پروتکلها یا فیلدهایی که به‌صورت پیش فرض قابل Match نیستند بسیار کاربردی است.

نکته: ابزار Data Broker دقیقا با Network Test Access Point (TAP) یکسان و معادل نیست. در شرایط استفاده از TAP نیاز به پیکر بندی SPAN روی سوئیچ نیست و این تجهیزات ساخته شده اند تا بتوانند بصورت in-line یک کپی فیزیکی از دیتا بگیرند. در مقابل، Data Broker معمولاً در لایه بعد از تولید Traffic Mirror شده (مانند SPAN، ERSPAN یا TAP) قرار میگیرد و وظیفه آن مدیریت و توزیع هوشمند این Traffic بین ابزارهای مصرف کننده است.

تا پیش از نسخه 3.10، این سرویس با عنوان Cisco Nexus Data Broker (NDB) شناخته می شد. اما از نسخه 3.10.1 به عنوان یک سرویس روی Nexus Dashboard راه اندازی می گردد.

و به این ترتیب با عنوان Nexus Dashboard Data Broker (NDDB) شناخته می شود.

اما نصب و راه اندازی Data Broker با سایر سرویس های سه گانه فوق تفاوت دارد و این تفاوت به نسخه Nexus Dashboard نیز بستگی دارد. اینکه از نسخه ND 4.2 استفاده می کنید یا نسخه های قبلی. 

تا پیش از نسخه ND 4.2، نصب و راه اندازی Data Broker کاملا مستقل از کلاستر اصلی شامل هریک از سرویس های فوق بود. به عنوان مثال شما ممکن است روی نسخه ND 4.1 از سرویس های NDO و NDI به صورت یکپارچه و unified استفاده کنید اما برای راه اندازی و در اختیار داشتن Data Broker اساسا نمیتوانید از این کلاستر استفاده کنید و لازم است یک ماشین لینوکسی مجزا راه اندازی نمایید. به این ترتیب راه اندازی NDDB مستقل و centralized خواهد بود و در صفحه Capacity Planning یا همان Cluster Sizing (که جلوتر درباره آن توضیح داده ام) نیز گزینه ای برای آن وجود ندارد. یکی از دلایلی که می توانست جداسازی Data Broker از سایر سرویس ها را توجیه نماید، حجم بالای دیتا و الگوی کاملا متفاوت از مصرف منابع در اختیار است.

اما با ND 4.2 شرایط می تواند متفاوت باشد و شما درگیر راه اندازی و نگهداری یک سرور لینوکسی مجزا و مدیریت آن خارج از کلاستر اصلی ND نباشید. در این نسخه از Nexus Dashboard سرویس Data Broker به یک اپ مجزا در App Store داخلی Nexus Dashboard تبدیل شده است و البته لازم است مجزا توسط شما نصب گردد. به این ترتیب اگرچه هنوز Data Broker مانند یک سرویس unified کنار سرویس های سه گانه فوق نیست اما مدیریت زیرساخت آن توسط کلاستر ND انجام می شود. به عبارت فنی تر، مواردی همچون: راه اندازی و استقرار سرویس Data Broker، بروز رسانی و آپگرید آن، مدیریت RBAC و احراز هویت ورودی و دسترسی ها حالا توسط کلاستر ND انجام می شود. علاوه بر این، UI/UX هماهنگ و سازگار با سایر سرویس ها خواهد داشت. البته این موضوع فعلا یک آپشن است و ادمین می تواند کماکان روش نصب سنتی روی سرور مجزا لینوکسی را دنبال کند.

در زمان نگارش این سند، آخرین نسخه این سرویس 3.10.5 است.

معماری سخت افزاری – نرم افزاری Nexus Dashboard

پلتفرم Nexus dashboard هم بصورت سخت افزاری، مبتنی بر سرورهای UCS و هم بصورت نسخه ماشین های مجازی در دسترس بوده و هست. تا پیش از نسخه 3.1.1، این محصول صرفا به صورت یک پلتفرم مستقل و مجزا خریداری یا دانلود میشد و پس از راه اندازی کلاستر ND، در گام بعد هریک از سرویس های مورد نظر فوق دانلود و سپس روی آن نصب می شدند.

اما از نسخه 3.1.1، قابلیت Unified Installation معرفی شد، به این صورت که پلتفرم ND و سرویس های فوق در یک نسخه image واحد عرضه شدند. اما با این تفاوت که هر نسخه از ND حالا فقط از یک نسخه مشخص از سرویس های فوق پشتیبانی می کرد. ضمن اینکه نصب همزمان همه سرویس ها امکان پذیر نبود. به عنوان مثال سرویس های NDO و NDFC را نمی توانستیم همزمان و کنار هم روی یک کلاستر ND داشته باشیم. افزوده بر این، امکان تغییر مدل پیاده سازی شده نیز وجود نداشت و ناچار بودیم سرویس نصب شده قبلی را حذف کنیم و همه دیتا نیز از بین می رفت! این محدودیت تا عرضه نسخه چهارم از آن وجود داشت.

علاوه بر اینها، در نسخه های 3.1 و 3.2 قابلیت‌های مدیریتی (Management) و قابلیت های تحلیل و مانیتورینگ (Insights)  در Fabric همچنان دو مؤلفه مستقل محسوب می‌شدند و تجربه‌ای یکپارچه ارائه نمی‌کردند.

نکته: در زمان نگارش این مستند در تاریخ خرداد و تیرماه 1405، نسخه suggested سیسکو برای نصب و استقرار ND نسخه 3.2 می باشد.

Nexus Dashboard 4.1.1

از نسخه 4.1 به بعد، معماری Nexus Dashboard دستخوش تغییر اساسی شد. پلتفرم اصلی و سرویس‌های مجزا در قالب یک محصول کاملاً یکپارچه ادغام شدند. در نتیجه، دیگر نیازی به استقرار، فعال سازی یا مدیریت مستقل سرویس ها وجود ندارد و لذا مفهوم Deployment Mode به‌ طور کامل حذف شده است.

در معماری جدید، بسته به نوع Appliance یا Form Factor مورد استفاده، تمامی قابلیتهایی که در نسخه‌های پیشین بهصورت سرویسهای مستقل ارائه میشدند، از طریق همان پلتفرم واحد در دسترس هستند. به این ترتیب، تجربه کاربری کاملاً یکپارچه شده و دیگر مرزی میان سرویسهای جداگانه وجود ندارد؛ به زبان ساده تمامی قابلیتهای مدیریتی، عملیاتی و تحلیلی از طریق یک داشبورد متمرکز و یکپارچه ارائه میشوند.

باید در نظر داشت، آنچه سیسکو در نسخه ND 4.1 انجام داده، صرفاً یک تغییر ظاهری در UI نیست؛ بلکه یک تغییر معماری (Architectural Shift) محسوب می‌شود.

• در ND 3.x سرویس‌های NDO، NDI و NDFC هویت مستقل داشتند که در ابتدای نصب و فرایند deployment mode توسط ادمین انتخاب و نصب می شدند.
• ظرفیت کلاستر بر اساس Deployment Mode رزرو میشد.
• تغییر نقش کلاستر نیازمند Re-deployment بود.
• سرویس‌ها Lifecycle جداگانه داشتند.

اما از نسخه 4.1

• Nexus dashboard حالا به یک معماری Platform-Centric تبدیل شده است.
• قابلیت‌های فوق به‌جای آنکه به ‌صورت سرویس‌های مجزا دیده شوند، به‌عنوان  Featureهای داخلی یک سوپر اپ ارائه می‌شوند.
• دیگر مفهومی به نام Service Activation یا Deployment Mode وجود ندارد.
• منابع کلاستر به‌ صورت پویا توسط پلتفرم مدیریت می‌شوند.
• کاربر صرفاً قابلیت مورد نیاز خود را مصرف می‌کند، بدون آنکه درگیر استقرار و مدیریت سرویس‌های مستقل شود.

Nexus Dashboard 4.2.1

نسخه 4.2 از Nexus Dashboard یک تحول کاملا استراتژیک به همراه دارد و آنهم دریچه ورود به معماری Nexus One می باشد. این معماری یا الگوی عملیاتی نخستین بار در سیسکو لایو فوریه 2026 مطرح شده است که بطور کلی در مقاله ای مجزا به این معماری خواهم پرداخت اما در یک ایده ساده و اولیه، داستان Nexus One پیرامون این است که بتوانیم چندین زیرساخت متنوع متشکل از ACI، VXLAN EVPN، سایت هایی مبتنی بر Cisco HyperFabric و باز در کنار اینها، سایت هایی بهره مند از سوئیچ های سیسکو اما سیستم عامل SONiC را بصورت واحد و یکپارچه پیکربندی و مدیریت کنیم. این interoperability میان ACI و VXLAN EVPN باید بتواند قابلیت هایی را از ACI در VXLAN سنتی بازنشر کند و توسعه دهد و از طرفی ACI نیز باید بتواند از Borger Gateway در VXLAN Multi-Site پشتیبانی نماید. در کنار اینها، سخت افزارهای قدرتمند شامل سوئیچ ها با نسل جدید ASIC بهینه سازی شده برای ترافیک های AI و پشتیبانی از تعداد بسیار زیاد GPU و throughput خارق العاده حرف های زیادی را برای گفتن خواهد داشت.

علاوه بر این، نسخه 4.2 با 4.1 تفاوت های مهمی دارد که در ادامه به 8 مورد که توجه مخاطبین رو بیشتر جلب می کند اشاره می کنم:

1. پشتیبانی از Nutanix در کنار VMware جهت راه اندازی کلاستر ND بصورت مجازی.
2. در نسخه 4.2.1 محدودیت‌های scalability بهبود زیادی یافته است؛ به‌طوری‌که حجم بیشتری از داده‌های Telemetry دریافت می‌شود و سرویس‌های بیشتری می‌توانند به‌صورت همزمان روی یک Cluster اجرا شوند. این موضوع برای دیتاسنترهای بزرگ، عملکرد و ظرفیت بهتری فراهم می‌کند.
3. در نسخه 4.2.1، تمامی قابلیت‌های Unified Nexus Dashboard از طریق Open API در دسترس قرار گرفته‌اند. این موضوع توسعه Automation، یکپارچه‌سازی با ابزارهای ثالث و پیاده‌سازی Infrastructure as Code را بسیار ساده‌تر می‌کند.
4. این نسخه قابلیت‌هایی مانند Microsoft Entra ID (Azure AD) MFA، محدودسازی دفعات ورود ناموفق، انقضای رمز عبور، جلوگیری از استفاده از رمزهای ضعیف و همچنین امکان تعریف Allowed Host برای دسترسی مدیریتی را اضافه کرده است که امنیت پنل مدیریتی را به شکل محسوسی افزایش می‌دهد.
5. با توجه به پشتیبانی از Interoperability میان ACI و VXLAN EVPN در نسخه 4.2.1 مدیریت Tenant دیگر بخشی از Orchestrator نیست و مستقیماً در خود Nexus Dashboard انجام می‌شود. این تغییر باعث ساده‌تر شدن مدیریت متمرکز چند Fabric و کاهش وابستگی به سرویس Orchestrator شده است.
6. در نسخه 4.2.1 پشتیبانی از LDAP و SSO بهبود یافته و گزینه‌های بیشتری برای اتصال Nexus Dashboard به سرویس‌های مدیریت هویت سازمانی (مانند Active Directory و Microsoft Entra ID) در اختیار مدیران قرار گرفته است. این موضوع مدیریت کاربران را در سازمان‌های بزرگ ساده‌تر می‌کند.
7. از نسخه Nexus Dashboard 4.2.1، سیسکو از Appliance جدید ND-NODE-G5L مبتنی بر Cisco UCS M8 پشتیبانی می‌کند. این Appliance در قالب کلاستر ۳ نودی ارائه شده و با هدف افزایش Performance، ظرفیت پردازش و مقیاس‌پذیری (Scale) برای استقرارهای Enterprise طراحی شده است.
8. پشتیبانی از Native Splunk. به این معنا که از این نسخه، Splunk به‌صورت Embedded داخل خود Nexus Dashboard اجرا می‌شود و دیگر لازم نیست برای بسیاری از سناریوها یک سرور Splunk جداگانه راه‌اندازی شود. Splunk به ‌عنوان یک Application در Analysis Hub قرار گرفته است.

ابزار Cluster Sizing

برای دسترسی سریع به اطلاعاتی نظیر مدل های نصب و استقرار، مقیاس پذیری (Scale) قابل پشتیبانی و الزامات مربوط به Cluster Sizing، میتوانید از ابزار Nexus Dashboard Cluster Sizing Tool استفاده کنید.

Cisco Nexus Dashboard Cluster Sizing Tool

یکی از تفاوت ها در نسخه 4.1 به بعد این است که در فرآیند نصب Nexus Dashboard، ادمین می‌تواند یکی از دو Persona یا الگوی عملیاتی LAN یا SAN را برای کلاستر انتخاب کند. واژه Persona اینجا به معنای نقش یا نوع محیطی است که کلاستر برای آن بهینه می‌شود و مربوط به سرویس NDFC یا به اختصار Controller می باشد.

کلاستر Nexus Dashboard؛ تعداد نودها و نوع آنها

بطور کلی پلتفرم nexus dashboard بصورت یک کلاستر متشکل از تعداد node و node profile های متفاوت تشکیل می شود. همانطور که اشاره شد این کلاستر می تواند مبتنی بر سخت افزار سرورهای UCS باشد، یا نسخه های مجازی روی VMware، KVM و یا حتی Nutanix در نسخه 4.2 باشد. همچنین از نسخه 4.1 امکان راه اندازی این کلاستر روی کلاد AWS نیز فراهم شده است. صرفه نظر از مدل deployment، هر نود از کلاستر ND دارای یک نقش مشخص است که می تواند یکی از گزینه های زیر باشد:

Primary

نودهای اصلی کلاستر که ضمن فراهم سازی منابع Compute، کنترل پیکربندی و مدیریت کل سرویس های فوق را بر عهده دارند

Secondary

این نودها در اصل برای افزایش منابع Compute و اصطلاحا scale out کلاستر استفاده می شوند.

Standby

نودهای standby جزئی از کلاستر هستند که ذاتا نقش عملیاتی ندارند؛ تا زمانی که یکی از نودهای primary دچار failure شود و این نود جایگزین آن گردد.

به صورت پیشفرض، یک کلاستر عملیاتی (و نه لابراتواری) شامل سه نود primary است. شما می توانید یک کلاستر تنها با یک نود primary بسازید اما این صرفا جنبه لب و تست خواهد داشت و scalable نیست. برای داشتن نودهای secondary و standby باید حتما کلاستر سه تایی از نودهای primary در اختیار باشد.

با توجه به مدل deployment کلاستر ND می توان تا سه نود secondary و دو نود standby در کلاستر اضافه کرد.

برای تشخیص تعداد نودهای مورد نیاز برای کلاستر باید به ابزار Cluster sizing مراجعه کرد.

Nexus Dashboard Node Profile

اصولا دو پروفایل node در اینجا دیده می شود که شامل: App-node و Data-node می گردد.

Data-node

این پروفایل نیازمند منابع computing بیشتر و قوی تر است که معمولا در شرایط ترکیب سرویس ها مورد نیاز می باشد.

App-node

این پروفایل نیازمند منابع computing استاندارد است.

بر اساس دیتای موجود در ابزار آنلاین Cluster sizing، میزان منابع مورد نیاز برای هریک از پروفایل های فوق به صورت زیر می باشد:

• Each OVA-Data node requires 32 vCPU, 128GB memory, 3TB SSD/NVMe.
• Each OVA-App node requires 16 vCPU, 64GB memory, 550GB HDD or SSD/NVMe.

اطلاعات فوق ممکن است با توجه به نوع پیکربندی دارای reservation هم باشد و لازم است حتما در ابزار فوق بررسی گردد.

به عنوان مثال  بر اساس اطلاعات Cluster sizing، برای ساخت یک کلاستر ND در نسخه 3.1.1 که صرفا سرویس orchestrator روی آن اجرا می شود نیاز به سه نود داریم که هر سه primary خواهند بود و از پروفایل App-node می باشند. البته می توان برای محیط لابراتوار این سرویس را تنها با یک node از این پروفایل در اختیار داشت.

از سوی دیگر، چنانچه بخواهیم سرویس Insight را نیز در همین نسخه در کنار orchestrator داشته باشیم، شرایط تفاوت زیادی خواهد کرد. در این مدل نیازمند سه نود primary از پروفایل Data-node هستیم همراه با سه نود secondary از پروفایل App-node.