The current ETSI NFV architecture defines a limited set of capabilities within the orchestration stack to monitor the deployed NFV-based services and underlying infrastructure, as shown below:
To manage and operate end-to-end services in practise, however, much more expansive monitoring and analysis capabilities are needed than are currently defined by ETSI NFV. These require a big data analytics approach which requires different underlying technologies than those commonly used within the orchestration stack. For an explanation of why see Big Data Analytics and the bifurcation of OSS: what about the F_APS?
Hence the question of how to apply big data analytics in the context of ETSI NFV-based services? We use PNDA to answer that question.
The first step is to aggregate and publish all data into PNDA:
- All types: logs/events, metrics, telemetry, …
- Across all layers and domains: from the infrastructure, from the services, and from the orchestration and control stack
- Data types may be sub-divided in PNDA by topics, e.g. logs on a different topic to metrics, so that analytics applications can subscribe only to the data they need
- Multiple aggregators may be used for a sub-data types, e.g. CollectD may be used for infrastructure metric data, with SNMP used for VNF metric data
There are no new interfaces or protocols needed to enable this – the capabilities exist today. A full list of plugins to get data into PNDA is available here: http://pnda.io/pnda-guide/producer/
Analytics functions are implemented as big data applications built on PNDA or as applications taking a data stream from PNDA.
Note that this will not necessarily remove the need for all monitoring and analysis within the orchestration stack, e.g. a VNFM may still do local monitoring of the VNFs under it’s control so that it can quickly and autonomously address failure or capacity issues. PNDA will enable a much broader and deeper set of analytics applications than could be realized within the orchestration stack, however.
The state in the orchestration and control stack provides the context required for the big data analytics applications to provide meaningful insight. We refer to this context as the Real-time Inventory, although we’re not implying that this must be a discrete function – although it can be.
In ETSI NFV this context information is maintained by the VNFM and NFVO (e.g. in the VNF Info data structure). This state enables associations to be made between data to maximise the insight available from analytics applications. For example, with this state it’s possible to know that disk errors on a host are associated with particular VMs, which support corresponding VNFs belonging to their associated tenants.
For more on the role of the Real-time Inventory see: Ontology, NFV and the Future OSS
Closed Loop Control
To complete the picture, the output from the analytics applications may be used to close the control loop, optimising the deployed services through feedback to the orchestration and control functions:
We’ll cover more on closed loop control and feedback loops in a future post.
What’s needed to enable this?
Actually, nothing; all of the building blocks are available today to build the system we’ve shown; we’ve done that to realise an analytics-based approach to service assurance, for an ETSI NFV based deployment – which we’ll also cover in a future post. If you’re interested in applying PNDA to ETSI NFV, please let us know.