Network analysis, telemetry and visualization are critical in any DC network transformation project for rapidly identifying application performance/connectivity issues, for capacity planning as well as for predictive network behaviors. Hence, we chose Network Analytics for the 6th Sign that DC networks are transforming.
Why traditional box-based networks lack analytics?
In box-by-box networking, a network switch or router has multiple challenges in regards to providing built-in network analytics:
- Each network box’s scope is limited to traffic that traverses through it, so it can’t really provide meaningful network-wide analytics
- CPU in a networking box is resource constrained, and hence challenging to devote CPU resources for analytics computation; traditional networking equipment stays in the network for 5-7 years, making the CPU resources even more scarce.
- There is very little storage on board traditional networking boxes, making it very hard to provide telemetry of any sort
DC operators are basically left with a myriad of 3rd party bolt-on tools, that are expensive and limited in functionality. Often, during troubleshooting sessions, NetOps would need to hop and hunt box-by-box using CLI and “show” commands and sift through a mountain of syslogs for hours in an attempt to narrow down the root cause. This is 20-year old architecture and methodology that brings nothing but pain, massive productivity loss and precious nights/weekends away from family.
How have Cloud Giants innovated?
Cloud Giants recognized that analytics are a must for (1) offering network-as-a-service in IaaS cloud and (2) rapid root cause analysis and fine tuning of the underlying network infrastructure to ensure networking SLAs and to plan for growth. They have pioneered the concept of “analytics for every conversation,” thus enabling cloud users to consume IaaS services more optimally. AWS for example provides built-in VPC flow logs which can be sent to CloudWatch monitoring and alerting service. Interestingly, in public cloud environment, analytics are more comprehensive, inclusive of network, compute (e.g. VMs) and storage services.
What is needed to bring built-in analytics capability into networking?
In a nutshell, it needs to have the right architecture. Fundamental insight here is the type of computational resource needed. In networking, we have primarily focused on a fixed-function packet processing, whereas analytics require flexible application processing on x86 servers (with x86 CPU, large memory, large storage) and scale-out clustering. Because of different processing need, analytics could never be embedded in a switch box. In a controller-based architecture, however, this issue is automatically addressed as the controller itself is on an x86 server. In other words, controller-based architectures are the ones that can naturally support built-in analytics.
Could analytics also provide compute and storage information?
For the right architecture, yes. It is often important for the networking team to have visibility to the broader SDDC environment, including hosts, VMs/containers and storage clusters. Typically, a controller-based fabric with integration into SDDC orchestration is needed. Once available, it is easy to provide host information, VMs & Container context, overlay network visibility (such as virtual switches and VNIs) as well as storage cluster information. Now, the network admin has a consistent view of the SDDC environment as do the server and storage admins, so it becomes much easier to do root cause analysis.
What type of network analytics does Big Switch provide?
Since Big Switch’s Big Cloud Fabric (BCF) is a controller-based data center switching fabric, it is an ideal solution to provide built-in analytics. Furthermore, BCF’s integration into SDDC orchestrators, such as VMware vSphere/NSX/vSAN, Nutanix HCI, Kubernetes and OpenStack, provides complete SDDC environment visibility and telemetry. Below screen shots are a few examples demonstrating the power of built-in analytics in BCF.
Packets Drops & Errors Telemetry
Interfaces associated with packet drops
Kubernetes container visibility (via BCF’s integration with Kubernetes)
Fabric Health Details
What could be the next sign (hint: popular AWS network construct on-prem)?
VP & Chief Product Officer
Prashant is responsible for Big Switch's Cloud-First Networking portfolio and strategy, including: product management, product marketing, technology partnerships/solutions and technical marketing. Prashant has been instrumental in the product strategy and development of Big Cloud Fabric and Big Monitoring Fabric products. Additionally, Prashant is responsible for Big Switch led open-source initiative, Open Network Linux (ONL), to accelerate adoption of open networking and HW vendor choice. You can connect with Prashant on LinkedIn.