Aarna Multi-Cluster Orchestration Platform or AMCOP is an open-source platform for orchestration, lifecycle management, and automation of network services consisting of CNFs, PNFs, and VNFs and MEC applications consisting of Cloud Native Applications (CNAs) . AMCOP can be used for use cases like 5GC orchestration, MEC orchestration, ORAN SMO, and many more.
The new features introduced in AMCOP 2.3.0 are given below:
Kubernetes object management using the Generic Action Controller(GAC) helps in Day 0 and Day N management of Kubernetes objects. During Day 0 configuration, if the user wants to deploy the application across multiple clusters but while deploying the user wants to verify or edit an environment variable that is different across the target clusters, GAC helps specify these details, so that the application can be deployed across multiple target clusters with the environmental variable being different across target clusters. It also helps in Day N configuration. Suppose the application is already running and the user wants to edit any value in the config map, she can do that using the single pane dashboard of AMCOP. Thus manual modification by going into 100s of clusters individually can be avoided.
Multicluster orchestration support using service mesh is achieved through a Distributed Traffic Controller (DTC). If one application running on a target cluster wants to discover and talk to another application running on a different target cluster, first discovery takes place and then network traffic steering takes place. The service entries will help the application running on one target cluster to discover the application running on another target cluster. This is taken care of by the DTC of AMCOP.
As part of high availability support, AMCOP now supports multi-master multi-worker deployments. In case a master node or worker node is down, the workload gets distributed automatically across different worker nodes, which are available and the master node takes care of rescheduling.
AMCOP currently has NWDAF support, which introduces the analytics part of a 5G network. If any Network Function requires analytics information it will connect to NRF; NWDAF also is registered with NRF. Hence NRF fetches the analytics function from NWDAF and sends it to the NF requesting the information. With NWDAF, AMCOP can execute closed loop automation. For example, if the prediction of CPU usage is high, horizontal scale out can be triggered by AMCOP. Thus an appropriate action can be triggered by an incident.
The Open Policy Agent (OPA) is a lightweight and powerful CNCF policy engine project, that is included in AMCOP. Using this, the admin can push policies so that the actions required in closed loop automation can be altered by user-defined policies. The policy engine executes the policy to alter the behavior of the closed loop automation.
AMCOP can be used to orchestrate both PNF and CNF based applications (and VNF through Kubevirt). It has a component called CDS (Controller Design Studio) and a Camunda based workflow engine, that help in Day 0 and Day N configuration in PNF devices. Day 0 involves powering up devices, starting workflows and discovery of devices and once the Day 0 configuration is successfully pushed using CDS, Day N configuration can also be executed on PNF devices using AMCOP.
AMCOP 2.4.0 was recently announced the enhancements are as follows:
● RBAC support (Early access)
● Log4j vulnerability fixes for AMCOP components
● Upgrade support from prior a AMCOP release
● Target cluster monitoring agent (Early access)
● Performance improvements
Currently, two roles are possible in AMCOP—admin and tenant. The admin role is a superset of tenant role. Default admin credentials are created during deployment of AMCOP. Using these credentials admin can login and change the password and then admin can start creating tenants. Tenants are one level lower than admins in terms of privileges. The admin can see all the tenants but one tenant cannot see the other tenant created by the admin. For example, each business unit in an organization can be given a separate tenant access to only the applications that the tenant should have access to.
This latest version of AMCOP addresses the vulnerability in Log4j ver 2.8, arising from the Log4 shell. Log4 shell is a remote code execution vulnerability using which remote attackers can take control of any device on the internet if the device is running an application based on Log4j. Some of the components of AMCOP uses Log4j library. In version 2.4.0 of AMCOP, this vulnerability has been fixed to make sure AMCOP is safe and secure.
The current version of AMCOP provides one-click upgrade support from prior release, thus avoiding reinstallation of AMCOP involving migration of databases. Now any production server which has AMCOP 2.3.0 can be upgraded to AMCOP 2.4.0 without any data loss.
AMCOP 2.4.0 has a Target Cluster Monitoring Agent. When a user creates a logical cloud a monitoring agent gets deployed all across the onboarded target clusters which are part of the logical cloud. In the earlier version, AMCOP did not have information over the exact state of the application running in the target cluster. With this monitoring agent AMCOP knows the real state of the application or composite application, running as part of the target cluster. AMCOP dashboard now displays live status of the applications.
AMCOP 2.4.0 provides faster deployment and faster upgrade. Thus the performance of AMCOP has improved greatly.
Try AMCOP for free at aarnanetworks.com/amcop.
