This time last year there was a lot of debate within the OpenStack community about whether NFV belonged in OpenStack. The debate has now been settled. OpenStack is very much part of the NFV conversation and as reflected in the iconic ETSI MANO conceptual architecture figure below, OpenStack is the primary actor for the Virtualized Infrastructure Manager (VIM) layer. OPNFV, a new open source project focused on accelerating NFV’s evolution through an integrated open platform is leveraging OpenStack and the OpenDaylight SDN Controller in its reference architecture.
For those less familiar with Tacker, it is a project incubated inside OpenStack. It plays the role of the VNF Manager, which is all about the lifecycle management of VNFs. Tacker takes care of configuring the VNF, monitoring it, and if needed, rebooting and/or scaling (auto healing) the VNF. This process completes the full lifecycle prescribed by ETSI MANO.
Tacker has gained a lot of traction since the OpenStack Vancouver summit and Brocade recently hosted the Mid-Cycle Tacker Meetup. In addition to the mid-cycle meetup, weekly IRC meetings are also held to discuss implementation details.
There are four major components of Tacker: VNFD Catalog, VNF Provisioning, VNF Configuration Management, and VNF Monitoring and Auto Healing.
Here’s a quick summary of progress to date in each of these areas.
VNFD Catalog: Early efforts in standardizing around how a VNF should be represented (VNF Descriptor) has now converged around using TOSCA. TOSCA (Topology and Orchestration Specification for Cloud Applications) is a TC or technical committee under the OASIS consortium that drives the development, convergence and adoption of open standards for the global information society. There is a draft version out for the TOSCA Simple Profile for NFV. This specification describes the attributes of the VNF (VNFD), and Tacker maintains the VNFD Catalog.
Once a VNF has been described using the TOSCA NFV template it can be on-boarded into the Tacker VNF Catalog. Once on-boarded, Tacker can instantiate the VNF by interpreting the TOSCA template and translating appropriate portions to OpenStack Heat using a translator. Tacker also takes care of configuring the VNF and continues to monitor and, if needed, auto heal to complete the full lifecycle prescribed by ETSI MANO.
VNF Provisioning: Using the Heat template described above, Tacker uses OpenStack Nova to provision the compute infrastructure. Lot of the features from OpenStack Nova can be leveraged during the compute provisioning process. By creating the right flavor with specific attributes such as SR-IOV Passthrough, NUMA, CPU pinning, large page allocation etc., compute resources are optimized for the VNF.
VNF Configuration Management: Tacker will push specific configurations required by the VNFs through the configuration driver. Configuration management is built as a pluggable framework where different VNF vendors can write their own configuration drivers for their VNFs.
Another approach is to use the SDN controller. There’s been a lot of talk on how SDN and NFV come together. This is a great example of how Tacker using the SDN controller plugin can push configurations for specific VNFs using the SDN controller’s south-bound interfaces.
VNF Monitoring and Auto Healing: One of the key responsibilities of Tacker is to monitor the health of the VNFs. Following the same principles that guide the design of other projects in OpenStack, Tacker will have some ready-to-use loadable monitoring drivers like icmp-ping, http-ping etc. There is also a planned integration with Ceilometer, and VNF vendors can write their own monitoring driver with specific monitoring attributes.
The community has accomplished a lot in a very short time. Kudos to everyone who has committed to the project!
This post first appeared on Brocade’s community site. You can also follow Kashyap on Twitter at @kashyap_madhu. Superuser is always interested in how-tos and other contributions, please get in touch: [email protected]
Cover Photo by Wolfgang Lonien // CC BY NC