NFV Monitoring Nicolas Bouthors, CTO, Qosmos Division Qosmos is a division of Enea - www.qosmos.com
In Our Haste to Prove NFV, We Almost Forgot Monitoring Operators use a variety of hardware elements to monitor their networks Physical probes cannot access logical interfaces to monitor functions hosted on the same server but on different VMs, or between VMs located on different servers connected via virtual overlay networks How to monitor the virtualized infrastructure? 2
NFV Challenge #43 NFV administrators cannot perform key tasks, such as service assurance, because The link is broken between QoS KPIs and KPIs for the physical elements delivering that service Repairing this link by processing logs from various systems is a never-ending job that is difficult and costly A new approach to monitoring is needed for NFV 3
Qosmos Approach: NFVI Flow-Based Monitoring (Part 1) NFV probes are deployed within the NFVI to monitor the entire traffic with low granularity NFV probes can collect data with high-granularity on demand Probe data feeds a traffic matrix to map services to their specific NFVI components The NFV administrator can now - Provide continuous visibility to existing OSS/BSS, down to hardware elements, without complex log aggregations - Accelerate root-cause analysis when a service is disrupted - Plan NFVI capacity upgrades to support specific services 4
Example of NFVI Flow-Based Monitoring with VPP Data is collected at the hypervisor level Smart SPAN Port: a configurable VPP node forwards packet copies to NFV Probe (18 Mpps) Flow Table (av: 191 cycles/packet) allows DPI offloading Enables - High-performance NFV Probe - Application monitoring and troubleshooting Independent from SDNgenerated configurations 5
Qosmos Approach: Tenant Flow-Based Monitoring (Part 2) NFV probes are deployed to monitor critical VNFs with high granularity The vswitch is configured via a MANO function to send specific traffic to the NFV probe The NFV administrator can now - Create alarms based on specific criteria for key VNFs - Drill down into specific VNFs when troubleshooting service errors 6
Example of Flow-Based Monitoring Using Tap as a Service (TaaS) Capture selected traffic Route traffic to selected probe Minimize impact on network performance Create and manage a monitoring network Support for tenant views in the traffic matrix 7
Processing Collected Information Available metadata Correlation, Aggregation and Filtering EL K Available metrics Drill Down with Dashboards 8
Summary The move to NFV creates a need for new monitoring solutions that can see into virtualized infrastructure and tie this information to specific services Qosmos has adopted a flow-based monitoring approach with NFV probes: - Run on hypervisors - Deployed in the NFVI and on specific VNFs - Capture packets sent by the vswitch - Data is sent to MANO functions to populate a traffic matrix and to be used by OSS & BSS This approach allows to reconcile the end-user view, the network view and the NFVI view, on a per-service basis in a timely manner Establishing NFV visibility for each service is a key success factor 9
Thank You Qosmos is a division of Enea For more information on Qosmos products, see www.qosmos.com Copyright 2017 Qosmos Tech. All rights reserved. Qosmos, the Qosmos logo, Qosmos Classifier, Qosmos Service Aware Module, Qosmos Service Aware Module for vswitch, Qosmos SAM and Qosmos ixengine are trademarks of Qosmos. The Enea logo is a trademark of Enea. Other names and brands may be claimed as the property of others. Non-contractual information. Products and services and their specifications are subject to change without prior notice.
End-to-End NFV Vision Flow-based Network Monitoring allows to reconcile the end user view, the network view the NFVI view and the applications NMS, VNFM Devops Orchestr. Managing ucpe Access Network SC/SFF Internet Steering Monitoring Monitoring NFVI requires Data Collection and Correlation to be part of the infrastructure ENEA focus on Management and Monitoring Traffic Matrix Troubleshooting 11
An Analytic Platform CORD (Central Office Rearchitected as Datacenter) Cf; http://opencord.org/ Identified generic requirements MUST be scalable and support multitenancy MUST be possible to instrument (control probing level on) services in addition to compute and network devices MUST be possible to adjust the level of probing in the underlying devices MUST be possible to aggregate probing information MUST be possible to redirect data streams through a "probe VM" for deeper level of instrumentation that is not otherwise available from underlying devices 12
Flow-Based Monitoring Use Cases VM migration VM backup planning Safe server updates VM optimization Network troubleshooting KPI tracking Security rules audit 13