Closed loop architecture and persistent volumes for network functions – Highlights in OSM release THIRTEEN

Open Source MANO (OSM) has announced its thirteenth version which is supported for six months (short-term support). This release targets feature enhancements for VNF vendors residing in the OSM ecosystem. It features new scalable architecture for service assurance and closed-loop operations, using Apache Airflow and Prometheus. It is capable of handling service assurance scenarios including auto scaling and auto healing in cloud environments and various edge locations. Additional features include enhancements in the deployment of Network Services (NS), execution environments, life cycle management (LCM), air-gapped installation, improved persistent volume management, and a few advancements in the OSM client.

Service providers are adopting new technologies such as 5G and IoT, each with its own set of needs. OSM is model-driven and offers convenience in designing complex network functions (NFs) having interconnectivity with each other. The reusability of NFs abstracts the underlying details of network function virtualisation (NFV). On the whole, release THIRTEEN’s new features offer opportunities for service providers to address scalability challenges and expand their range of orchestration features.

 Highlights from this release include:

New closed-loop life cycle architecture 

The current release possesses a new state-of-the-art closed-loop architecture with scalable capabilities. It includes new workflow processes for obtaining the status of Network Functions (NF), Network Services (NS) , and Virtualised Infrastructure Managers (VIMs). Airflow Directed Acyclic Graphs (DAGs) are used to monitor workflows dynamically against Virtual Infrastructure Manager (VIM) accounts.

This brings certain improvements:

• The previous architectures had limitations such as being monolithic and difficult to scale. So, the new scalable closed-loop architecture overcomes these limitations by proposing the use of multi-stage analytic pipelines to process metrics. This allows metrics to be obtained from external sources, normalised for the understanding of Prometheus rules, and then input into OSM.
• Metrics for NS topology, VM status, and VIM status can be obtained from MongoDB and sent to Prometheus using the Prometheus Pushgateway. The end-to-end flow is managed through Airflow DAGs and the Prometheus Pushgateway, and extended metrics for Virtual Machine (VM), VNF, and NS can be monitored using Prometheus recording rules. Real-time visualisations can be observed in Grafana dashboards.
• In a recent webinar, network services (NS) have been instantiated in an Openstack-based VIM. The VNF and VM statistics are monitored in the Prometheus dashboard. Metrics are normalised for better understanding using Prometheus recording rules. The Airflow DAG automatically discovers the status for VNF, VM, and NS topology through an associated VIM account. The demonstration includes the creation of a new NS composed of one VM in the Google Cloud Platform (GCP). The new workflow gets detected in Airflow to get the status of VIM and VM in GCP. This implementation allows users to monitor the real-time status of VNFs hosted on both private and public clouds.
• The acquisition of VNFs metrics such as resource consumption is also improved with the new architecture. The MON and POL modules in OSM will also be gradually added into the new architecture for metric acquisition, alerts generation in case of failures using webhooks, and basic status monitoring in OSM client.  Few enhancements are still to be incorporated in new architecture to make it more flexible and feature enriched.

Persistent volumes in NS 

OSM now enables volumes to stay permanent in VIM during NS deployments and failures. It also enables storing certificate authority CA as part of VIM registration. The ability of a platform to persist the data is a practical use case for service providers. The NFs may face failures, but data loss cannot be afforded. OpenStack allows several ways to persist the data for VNFs.

• The webinar demonstrated the instantiation of NS in Openstack. The persistent volume is defined in the VNF descriptor. After successful creation of VNF, data is mounted on persistent volume. When NS is deleted, OSM terminates VNF and Openstack deletes the VM but the persistent volume remains intact. The new NS service is created and persistent volume is attached to it, the same data is now attached to new NS and thus persistent volumes for NFs enable data to persist even if the NF is deleted.
• Persistent volumes in NS provide customers with a flexible way to manage their data storage requirements. They don’t need to recreate and destroy the volume everytime they create a new NS.

Internal Life cycle management (LCM) evolution

LCM is mainly responsible for managing the life cycle of VNF and NS, such as creation, termination, scaling, healing, and upgrading. This release includes the use of the saga-based pattern for workflow management in selected operations. In addition to that, a Kafka message broker was introduced between LCM and the resource orchestrator (RO). 

OSM installation experience

The installer is now able to detect OSM installations from behind the web proxy and perform desired configurations. This will ease the global installation experience. The new scalable architecture can now be tested by installing it with a specific flag. 

Execution Environments (Day-2)

Release THIRTEEN enhances the secure communication channel between the Helm-based execution environments (EE) and NF, enabling the upgrading of the Helm-based EE. It also introduces a new naming convention for Juju applications in the Juju-based EE.

OSM client

OSM client facilitates the easy registration of Prometheus-based telemetry systems within the VIM. OSM client commands have been redesigned. An installation procedure for Windows and Red Hat Enterprise Linux is also introduced in addition to the existing Ubuntu installation. 

Summary 

OSM release THIRTEEN brings enhancement features to OSM by targeting field use cases. VNF vendors and service providers leverage new features of scalable closed-loop architecture and persistent volumes. In the NFV ecosystem, OSM is continuously integrating new technologies for next-generation cloud platforms. Release THIRTEEN laid grounds for cloud-native environments to build, scale, and grow with capabilities for CI/CD pipelines and workflows defined in Airflow DAG. The Prometheus-Grafana integration enables real-time visualisation of statistics for improved observability.  Service providers can use enriched features of OSM and innovate in cost-optimised environments.

To understand more about telco network orchestration, visit our website.