Lifecycle Manager Architecture
LM software is deployed as separated distinct component sets which can be considered in two groups;
- Core Stratoss™ Lifecycle Manager (LM) consisting of a number of microservices
- Dependencies: Foundation functionality consisting of industry standard third party implementations
- Message Bus
- Data Persistence
- Authentication Server
Stratoss LM Core Microservices
The Stratoss LM microservices are namely:
- User Interface
- Host for Stratoss LM User Interface.
- API Gateway
- A gateway for the full set of published Stratoss LM APIs used by the Stratoss LM User Interface and available for use by any number of configured Client applications. It supports full management of the set of Network Services governed by Stratoss LM
- Service Registry
- The first instantiated Stratoss LM service, The Service Registry is responsible for making per service configuration available to each Stratoss LM Service (instance) as it is instantiated
- Intent Engine
- Core Stratoss LM service, the Intent Engine is responsible for deriving the set of lifecycle transitions on each deployed resource to transition the Network Service from its current state to an intended/desired state in real-time and optimally orchestrating their execution leveraging opportunities for concurrency while reflecting transition dependencies.
- Process Repository
- Helper service for the Intent engine supporting its High Availability operation for stateful operations
- Component Catalogue
- A Data Presentation service for the set of defined NS, VNF and VNFc’s
- Graph Network Service Topology
- A Graph of deployed Network Services and their constituent components to the leaf VNFC level
- Deployment Topology
- Service maintaining a view of deployment environments and their capability in support of Deployment Policy enforcement (affinity & pinning support)
- Behavioural Scenario Execution Engine
- Test and certification service. Allowing managed, in situ scenarios to be executed against individual Network Services and the collection of specific metrics while the test is in play
- Stratoss LM Policy Enforcement
- Integrity (Heal) and Scaling (Horizontal) Metric Monitor and Policy execution. This is responsible for enforcing the policy across the set of all VNFCs under management
- Resource Manager
- The resource manager is issued with individual Lifecycle transition instructions by the Intent Engine. It is responsible for performing infrastructure provisioning and lifecycle transitions at the individual VNFC level. It utilizes modularized Infrastructure Manager specific drivers to allow it to communicate with a number of Infrastructure Managers.
- VIM Drivers
- One logical Driver per NFVI/VIM
- VNFC Driver
- Scaled set of VNFC deployment worker nodes
Stratoss LM Core application is realized by a number of microservices deployed on Kubernetes environment. Each microservice has a specific role/function within the Stratoss LM application and communicate with each other via RESTful APIs and through a Kafka message bus.
Each Stratoss LM microservice is realized as a Kubernetes service and implemented as a set of service instances which are reachable via a load balancer. Every service operates in a fully active instance set. That is, all service instances within the set are fully operational and capable of servicing any request made of it concurrent to its peers within the service.
A Stratoss LM instance is deployed in full in a single Data Centre. The colocation of the set of microservices that make up a Stratoss LM instance to a single Data Center is for efficiency and to reduce latency in inter microservice communication
Stratoss LM installation assumes an existing Kubernetes cluster with a sufficient number of nodes to deploy the services on. Distribution of Kubernetes nodes on virtual machines and eventually on physical resources in a data center to secure resilience against various infrastructure failures is managed by Kubernetes and layers under it.
Features of Kubernetes are leveraged to provide High Availability of Stratoss LM. High Availability is realized by managing a set of service instances for each logical service. By default Stratoss LM HA configuration defaults to 3 instances per service. Although, the actual number of instances needs to factor in the load and the expectation.
This is based on a simple case of:
- HA = R + L, where:
- R: The number of required redundant instances. That is the number of failed instances the system must cater for without the ability to cater for the current load.
- L: The number of required instances for the system to maintain operation.
High Availability for Stratoss LM is configurable on a per service (service set) basis for all services in Stratoss LM. Each individual Stratoss LM Microservice is configured to be deployed with the following Kubernetes parameters: * minReplicas * maxReplicas * Replicas
Of these minReplicas and maxReplicas are used to manage the number of instances per service. Replicas is used to identify how many are created on deployment of Stratoss LM. This will represent the number of instances that are required to support the HA requirement of minReplicas.
Within a Service Set, the set of service instances should ideally be distribution across the set of available Kubernetes nodes. This provides resilience to the loss of a node will result in the loss of not more than one instance within a given service set. This is managed using a preferredDuringScheduling request in the configuration. This allows the system to maintain the number of instances in a set even when the number of worker nodes is insufficient to maintain one service instance per worker node. This may occur if there is the loss of a node or if scaling results in the need to ‘double-up’ due to the size of the service set exceeding the number of available nodes.
maxReplicas can be used to cap a particular service at a level. This prevents run away and the risk of an individual service scaling to a level that results in the exhaustion of underlying resources to the detriment of other services and their ability to scale.
Figure below illustrates the positioning of Stratoss LM with other main components involved in service development and orchestration.
The main responsibilities of Stratoss LM is to enable modelling of network services (NS) and drive them through their lifecycles according to requests it receives. Stratoss LM integrates on its northbound interface with Order management tools to take in orders to deploy, maintain or decommission service instances.
Incoming requests are resolved to required actions, broken down to VNF and eventually to VNFC level lifecycle transitions to be executed. Finally, the resource level requests are passed to responsible VIMs, SDN Controllers, VNF Managers and VNFs to fulfil their responsibilities.
Integration to OSS enables among other things closed loop monitoring of service health and load, and access to resource inventory.
Stratoss LM provides also seamless integration to CI/CD tools and processes to ensure automation of service development process and testing. Stratoss LM comes with a CI/CD hub providing pre-integrated CI/CD toolset and framework to be used as a reference implementation of CI/CD pipeline.
Centralized user and log management can also be integrated through corresponding interfaces.