Demystifying the complexity of cloud-native 5G network functions deployment using Symworld CNP – Part II

Now that we have discussed the networking part, the next step is placing the application into a host.

Symworld Cloud Native Platform (CNP) has the concept of master, compute, and storage nodes. Typically, the hardware servers would have multiple NUMA nodes. In order to achieve the best performance, the platform should utilize the resources from the same NUMA node. Failing this – if users are consuming a resource from another NUMA node – then their performance would degrade.

NUMA-aware application placement for CNF/VNF

To make sure that the performance is met, Symworld™ Cloud makes sure that the resources, such as CPU, Memory, HugePages, GPU, FPGA, and SRIOV, are assigned from the same NUMA node. To do that, Symworld™ Cloud automatically takes care of scheduling the application in the same NUMA node, based on the input from the application requirements. Users can configure their Symworld™ Cloud bundle with a guaranteed CPU. Once this is done, Symworld™ Cloud would first scan for all the available hosts and wherever there is a single NUMA node available with all the resources, it will use that. This is done automatically, as compared to the manual process of workload placement.

The Symworld™ Cloud planner has tight integration with the Kubernetes topology manager to achieve NUMA-aware placement for guaranteed or shared CPU workloads. Running VNF on CNP with KVM hypervisor is also possible with Symworld™ Cloud. The management would look like a Kubernetes control plane, where users have the same experience of CNFs and VNFs application lifecycle management.

Symworld™ Cloud application bundle

Symworld™ Cloud application bundle refers to the packaging of the application for deploying into the cloud-native platform. It is similar to the Helm chart but is more simplified and intuitive.

• One of the components of the Symworld™ Cloud bundle is the manifest YAML file, which is a blueprint of the application, where users can define the compute, storage, and networking requirements. Additionally, users can perform multiple other configurations such as snapshots, app hooks, affinity or anti-affinity rules, and so on. In essence, it is a single file with the entire definition of the application, as compared to a multi-file setup.
• Next, there is the icon directory and a script directory for the execution of tasks. For example, users may want to do certain checks or perform certain tasks on the application before or after taking a snapshot, and those can be written under the scripts directory.
• Finally, there is the source directory, where users can specify additional container-related parameters or park additional files that need to be pulled up from time to time.

The Symworld™ Cloud bundle can be uploaded easily into Symworld CNP and deployed using an App-Store-like experience. In the same way, Symworld™ Cloud also supports the open-source Helm chart, where users can define their application and run it on Symworld™ Cloud. Additionally, users can integrate Symworld™ Cloud IP pools, its storage, and networking stack with the Helm chart using simple annotations.

Case in point

We talked about different scenarios, how we solve them, and how we reduce the complexity or deploy them.

Let’s take a live example case study of one of our customers for whom we have successfully deployed and run Symworld CNP in production. The client has built and deployed their next-generation 5G, fully containerized telco stack running on top of Symworld CNP.

They have three types of data centers – Central DC, Regional or DC, and Far Edge DC. On the central DC, all the core applications, such as AMF, SMF, and PCF, are run; at the regional edge where all the UPF, CU, some of the RAN components, and MEC applications would run. The Far edge is close to the radio towers, where the DU instance of the radio runs.

Symworld Orchestrator handles end-to-end automation for all of these workloads including cluster management. Scaling can be done depending on the size and location of the cluster. Symworld™ Cloud manages end-to-end automation and orchestration of the cloud platform. The health and operation of CNP clusters can be monitored and managed by Symworld™ Cloud using open-source Prometheus and Grafana.

In conclusion

Operators are challenged with managing NFs in a cloud-native world to achieve low latency and high throughput for 5G applications, meeting scalability targets, achieving bare-metal performance without virtualization overheads, and so on. Symworld™ Cloud is the answer to these challenges and more. The main reasons why customers choose Symworld™ Cloud include:

1. Deploy stateful applications on Kubernetes: Stateful applications rely on infrastructure awareness for seamless functioning which is taken care of automatically on Symworld™ Cloud platforms.
2. Deploy 5G RAN and at scale for operators: Scaling and performance tuning for 5G RAN and core deployments across different sites are again achieved on Symworld CNP.
3. Deploy and manage applications at the Edge: Symworld™ Cloud supports MEC or enterprise edge applications. Users can use the same platform to run containers and VMs, hybrid, on-prem and multi-cloud.
4. Day-2 operations automation: Symworld™ Cloud enables automation at a hyper-scale, in addition to configuring and monitoring the lifecycle management of applications and clusters.

Interested to know more? Hear from our experts on designing future-ready, cloud-native networks that help operators boost performance.

Disclaimer: As of November 2022, Robin.io products have been rebranded to Symworld™ Cloud, under the Rakuten Symphony Unified Cloud BU.