Download Solution Brief

Please fill in your details below
Thank you for your interest.
Please click here to download the solution brief
Oops! Something went wrong while submitting the form.
Close
Rakuten Symphony

Kubernetes Automation for Open RAN

Introduction

Common Challenges for Open RAN deployments Legacy Radio Access Networks (RAN) were intentionally designed using closed and proprietary architectures that locked operators to a particular vendor, for both radio and supporting hardware (baseband units). Open RAN is a game-changing RAN evolution combining RAN functionality with cloud-native design,scale and automation.

Open RAN decouples software from hardware and moves the industry to a cloud-native model. The key functionality is provided by software known as Network Functions (NFs) that run on virtually any Commercial Off-The-Shelf (COTS) server.

Kubernetes is the ideal platform for Open RAN and boasts the following advantages:

  • Platform-agnostic flexibility that runs anywhere
  • Resource optimization
  • Scalability
  • Fault-tolerant high availability
  • Meshes well with GitOps principles

All of these come together to reduce CapEx and OpEx, enabling solutions to rapidly transform from one use case to the next, providing business agility that helps you generate revenue faster.

Common Challenges for Open RAN deployments

With Open RAN, the number of elements in the solution is set to grow by 100x, especially in highly populated areas. With this explosion of new service offerings above and beyond Open RAN NFs and services, it's not about tackling a few key objectives anymore, but rather about automating everything in a new way that unifies and wields the solution as a whole. Open RAN gives its customers numerous design automations, including connectivity design splits and the ability to use both VMs and containers. This contributes to the overall customer needs around the following:

  • How do I install faster and scale to 1,000,000+ nodes?
  • Once installed, how does the solution support day 2 lifecycle automation?
  • How do I detect and repair outages?
  • How do I build an economical solution that adapts to varying locational and functional requirements?
  • How do I interoperate with and share resources in a brownfield, virtual machine (VM) deployment?
  • How do I easily provide Open RAN alongside embedded MEC services, such as content delivery networks (CDN), interactive networks, Internet of Things (IoT), and self-service customer application hosting?
  • How do I provide -as-a-Service turn-ups for those internal to my organization, partners and hosted customers?
  • How do I safely and securely provide a shared customer/ provider infrastructure that supports multitenancy and role-based access, with efficiently used shared resources?

Symcloud Platform – An Enhanced Kubernetes Platform

While Kubernetes is the is the north star for cloud computing, it was not originally designed for provider solutions. Rakuten Symphony's Symcloud Platform addresses those challenges through:

  • Container-CNF and VM-VNF harmonization that allows you to transform when you want, freeing you from your NFs and application vendors' roadmaps
  • Fully automated, application-aware stateful storage that backs up not just the storage, but your application + Kubernetes dependencies + data + metadata + secrets
  • A low-footprint edge platform that scales down for edge deployments without losing functionality
  • Automated workload and storage placement
  • Advanced networking capabilities
  • NF and application performance tuning
  • Declarative automation that eliminates the need for CLI and development expertise
  • Multitenant-enabled observability with integrated chargeback and granular RBAC controls

Eliminate CNF/VNF Silos

At some point you began your transition to a software model, be it with VM-based Virtualized Network Functions (VNFs) or Containerized Network Functions (CNFs). At some point in time, the servers they run on will age out. When this happens, you need to be able to transition your VNFs to take advantage of a modern CNF-based Kubernetes network. But in many cases, you can't, because you are stuck on your vendors' containerization timelines, not yours, because not all legacy or older versions of applications will be transitioned to containers. This severely impacts your agility in the new world of 5G and MEC applications where the agile beat the slow and capture the market, every single time.

Running VM-based VNF/CNFs on separate underlying platforms reduces resource utilization, adds operational cost and complexity and ties your modernization timelines to someone else's roadmaps. Symcloud runs both VNFs and CNFs in the same cluster or pod, sharing resources in a common pool (or segregating it), while using the same onboarding procedures. This allows you to run more applications than before. Furthermore, existing VMs run 30% faster on Symcloud Platform than traditional VM platforms such as OpenStack – this is customer-tested and proven.

Just because a vendor has a slick GUI linking together multiple platforms, operational siloes can still exist. There are still multiple platforms to integrate, install and troubleshoot under the covers. Additional features come at the expense of additional API integration tasks between the multiple platforms. Troubleshooting and complexity doubles.

This poses several challenges:

  • How does one manage services and service chaining NF lifecycles, network connections and resources across the different VNFs and CNFs?
  • Which system does the scaling and auto-healing?
  • How does one view and drill down on resource dependencies across VNF/CNF silos?

The answer to this problem is Symcloud Platform, as it runs both VNFs and CNFs on the same Kubernetes platform, with a unified operations model and fully shared resource pools.

Symcloud Platform is one system, built from the ground up to unify VM and container service operations.

With it, everything, including CNFs and VNFs, runs on Kubernetes. Symcloud Platform consolidates all of the resource and lifecycle management operations into a single system, both on the GUI front and resource-sharing front.

CSPs also need to be cautious of falling into a bait-and-switch scenario when considering KubeVirt for VM onboarding. Many vendors claim to support running VMs on Kubernetes, but often what they actually provide is a separate, isolated legacy VM solution that coexists alongside their Kubernetes offering. This is mainly because these vendors prefer leveraging embedded VM solutions like OpenStack, which are more convenient for them, rather than integrating with KubeVirt. Even if they do offer KubeVirt, it doesn't function the same way as standard containers.

In contrast, with Symcloud Platform, VMs are like any other NF in a Pod (defined in PodSpec) as are containers, not depending on custom definition like KubeVirt that uses VirtualMachineInstances. So, what you then eliminate is a siloed solution that adds operational and troubleshooting complexity. With Symcloud, it is all completely unified in the GUI and under the layers, making a streamlined solution.

Stateful Applications and Cloud-Native Storage

While Open RAN NFs are stateless applications, as we all know, the big money is not necessarily in connectivity, but over the top services, and those are stateful. Examples include the Internet of Things (IoT), Industry 4.0, self-driving vehicles, smart cities, video analytics, customized content delivery, security, Database-as-a-service (DBaaS) and self-healing networks. Naturally, it makes sense that your platform supports not only stateless Open RAN NFs, but also stateful, profitable, service applications.

Stateless vs. Stateful Applications

The genesis of the Kubernetes revolution comes down to stateless, web-scale, workloads. In the stateless model, one typically deploys multiple replicas of the same application, running in parallel, to increase availability. The Kubernetes then scales the number of replicas up and down, based on demand. The application itself is stateless because it does not have to perform operations based on a previous operation or data “state”. Think of it as a simple calculator where each set of inputs and the resulting output are unrelated. On the other hand, a stateful application, such as in the case of bank transactions, does care about preexisting conditions and states. Here, each transaction in a ledger considers what was there previously.

Prior to Kubernetes, there was a simple, direct, mapping between data and an application, running on bare metal or in a VM. But with Kubernetes innovation comes added complexity. Kubernetes applications are broken up into many microservices and mapped to different containers, each with a different relationship to the data as they grow, scale, migrate and heal. Not only does data have state, but the condition of your Kubernetes containers and micro-services also has a given state that can change the very moment they are deployed. Therefore, simply rolling back to day 1 is not a good option.

Why We Need More than Plain Kubernetes Storage

The problem is that standard Kubernetes offerings only provide Container Storage Interface (CSI) as a storage interface but do not provide a complete solution to the problems. The Kubernetes CSI provides minimal storage support and does not fully address crucial aspects like data persistence, high availability, auto-scaling, and other requirements needed to successfully and repeatedly run mission-critical edge data services. This becomes particularly challenging in edge, on-premise, environments with limited dedicated storage resources, staffing and access.

Symcloud Storage Advantages

Symcloud Storage revolutionizes storage and data management for Kubernetes deployments, whether on-premises or in the cloud. It seamlessly integrates with Kubernetes-native administrative tools like Kubectl, Helm Charts, and Operators, leveraging standard APIs, CLI, and an intuitive GUI. By deploying Symcloud Storage as a Kubernetes operator, developers and DevOps teams can automate the entire solution based on customizable policies. This automation ensures accurate tracking of application and storage elements throughout the solution's lifespan, minimizing errors and significantly reducing time to achieve desired outcomes.

Symcloud Storage understands, auto-learns and auto-adapts to all application and data permutations and performs any-point-in-time backups, snapshots, cloning and disaster recovery with application and Kubernetesstate awareness.Some vendors claim application awareness, but they require manual intensive tagging and marking over the lifetime of the application. They also need Kubernetes expertise. Symcloud™'s cloud-native storage offers seamless integration with applications, automatically ingesting them from their Helm chart, YAML file, or operator. It then performs auto-discovery, auto-monitoring, and adapts to changes throughout the application's entire lifecycle. Fully automated forever and way easier to use – no Kubernetes expertise required.

Furthermore, Symcloud Storage provides programmable pre and post processing policies that auto-adjust to target environments and can even renumber IP addresses when cloning so there are no network clashes. Additionally, it provides automated storage placement based on easy-to-configure policies and IOPs-based storage QoS and it can even be set to auto-reconnect to an alternate on node outage.

Symcloud™'s industry-leading, software-defined storage supports a comprehensive set of application-aware services, including snapshots, clones, backup, encryption, and business continuity. All data services are application-aware, tracking not only data storage, but also the metadata and the ever-changing Kubernetes application config, protecting a wide range of datasets for “application-consistent” disaster recovery of complex network and storage intensive stateful applications.

That sounds like a lot of complexity and learning, but it isn't. With Symcloud™s user-friendly GUI, equipped with automated storage policies, managing storage becomes effortless. Even using the CLI, complex operations that would typically require multiple commands are streamlined to a single line of code. Symcloud Storage empowers developers, QA, and Ops teams by eliminating the need for extensive storage expertise, enabling them to focus on high-value projects.

Automated Resource Policies, Declarative Modeling and Workload/Storage Placement for Remote NF Tuning

There are very specific performance needs for the different types of workloads found both in the RAN and co-located in the same data centers. They can be processor, memory, storage and networking intensive as well as any combination of the four.

Symcloud™'s best-of-breed Kubernetes-based Symcloud Platform combines 1-click application onboarding with declarative, context-aware workload placement, pinning your NFs and services to automated policies. This enables automatic allocation of resources as they start, stop, migrate and heal. Symcloud Platform makes this plug-and-play with Non-Uniform Memory Access (NUMA) aware, auto-resource discovery, coupled with unique workload placement algorithms and processes to model your needs, then automate and configure them, throughout the service lifecycle.

Most legacy platforms force you to manually configure things like CPU cores, NIC cards, physical ports, virtual ports, pods, nodes, VLANs, and so on – pretty much everything network-wide. For example, you have to explicitly select and configure NUMA node X: CPU1 Core 1 and CPU1 Core 2 on Server Y and then further configure memory and networking options manually, cross-checking with any other config action that came before it. This is extremely time-consuming, overly complex and prone to human error. Furthermore, designing for failover scenarios and enabling automated failover adds even more wrinkles.

Symcloud Platform's user interaction paradigm centers on declarative programmable models. Declarative, as it asks for your desired outcome, but not all of the configuration steps to get there. This is possible because Symcloud™ presents all of the configuration parameters as programmable variables. For example, you may wish to reserve a similar configuration from the previous scenario. The request isn't necessarily based on those two specific cores. It is likely based on a specific need – for example, an application required siblings in the same NUMA node that happen to be Core 1 and Core 2. It could also be based on a different need. But it is still based on some need that can likely be met by any number of cores in the system, not just those two. So instead of making the user search component by component, Symcloud™'s interfaces ask you for the need and do the finding and configuration for you. For example, you say “Give me 4 CPUs in the same NUMA node, 1G memory in the same NUMA node, 2 redundant SR-IOV ports and persistent IP addresses”, then Symcloud™ secures and configures them to support the NF. Furthermore, as your containers and VMs scale, restart, heal or migrate, those policy declarations are automatically reused to adapt to real-time events. That means your NFs are pinned to explicit policies that you only need to set up once.

Additionally, when combined with our application-aware Symcloud Storage, one can also perform storage placement on the desired pods, as well as apply affinity/anti-affinity rules.

Advanced Networking Requirements

To Symcloud Platform, networking is just another resource that is modellable and reusable.

Network Modeling, Network-as-a-Service

With Symcloud Platform, you can define multiple network models with connectivity to Calico overlays, connections to Open vSwitch (OVS) underlays (that can be used to interconnect co-dependent NF pods) and SR-IOV underlays (for high-performance traffic). You can even configure role-based access for any particular underlay or overlay in a network definition. Now you have a set of networks you can instantiate on demand, for any particular user or service request. Adding another cluster? You have a network for that. Moving to a larger or smaller data center? You have a network for that. Setting up a new development site? You have a network for that.

NF Networking Requirements are Different from Traditional Cloud Applications

Network connectivity for traditional cloud applications is simple. In most cases they can connect via a default Kubernetes network, with a simple overlay network separating nodes into separate subnetworks, connecting the nodes, with perhaps an internal ingress load balancer thrown in the mix. Then at some point, the Kubernetes services are attached to an external network with a router, security appliances and external load balancer.

Provider's NFs need more robust connectivity options, that also include high-performance underlays, to deliver the high-throughput, low-jitter services found in 5G applications. These additional networking requirements are not wholly addressed by most cloud platforms and include:

  • Per-pod Multi-IP Network Support
  • Open vSwitch underlays to extend corporate operations networks to NFs
  • SR-IOV underlay networks for high throughput, low jitter, redundancy as well as NF interconnect
  • NIC Bonding for redundancy and throughput
  • IPv4/v6 Support
  • IP Persistency
  • Other Quality of Life Enhancements

Scale Up and Down from Core to Edge with Confidence

One of the many solutions that Open RAN helps enable are mobile edge services and it does so for both public and private 5G. The problem is that legacy Kubernetes solutions, including most open-source, do not scale down at all. K3s was ushered in as a quick fix, but with its smaller size came limited functionality. Some vendors have jumped on that bandwagon with their own proprietary solutions, but once again they stripped out functionalities like advanced monitoring, operators and APIs.

Although Symcloud Platform scales up to support huge clouds, it was designed with optimization in mind. It can run most solutions using only two cores while retaining functionalities like monitoring and ease-of-use. Some applications can even scale down to a single core. This gives you a single solution to run from core to edge, with a single operations model and a completely unified feature set!

Monitoring, Multitenant Charging and Planning Framework

The key elements to using all of this data efficiently are access and correlation. Symcloud Orchestrator accesses the physical resources as well as logical buckets, based on numerous modeled variables. You can use Symcloud™ metrics to gain visibility into the resources across multiple clusters and sites, for troubleshooting automation and planning. See where each service is running, the resources and health status, and collect numerous performance metrics up and down the solution stack, from bare-metal to services.

Symcloud™ has deep insight into all the elements, including physical resources, cloud platform, NFs, services and energy management. They can correlate and display views across any strata from a full drill-down to a solution-wide view, including NF, application, service, pod, node, cluster, server, data center and multi-cloud. Using these metrics, one can customize and monitor operations at multiple levels, not just top-down or bottom-up. Based on this multi-level awareness, the information can be used to troubleshoot, auto-repair, migrate, notify or trigger a MOPs operation using a policy engine. Symcloud monitoring systems give you true everything-awareness and dependency correlation, as well as the tools to use it – like Prometheus, Grafana, and ELK stack (Elasticsearch, Logstash, and Kibana) for monitoring and logging.

All monitoring, energy management, charging and planning functionalities are available on a per tenant basis. Furthermore, the Symcloud solution provides rich RBAC functionality. Not only is there a three-level hierarchy in place, but virtually any operation can be mapped to specific users. Even users in the same privilege group can have access to a different set of operations. This is ideal for self-service and collaborative teams working in a multi-organizational environment.

Conclusion

VNF/CNF Harmonization

Symcloud Platform, in a unique way, runs VMs and containers on the same platform/node/Kubernetes pod, with no resource or lifecycle management/ operations silos. It eliminates the need for separate physical/logical resources, teams and operations models. This means, not two products, not two sets of rules, completely unified under the layers, providing granular NUMA-aware resource pools and multi-tenant separation with integrated security and chargeback.

Application-Aware Storage

Symcloud Storage, available as part of Symcloud Platform or separately, provides fully automated, stateful, software-defined storage that is application-aware. It backs up not just the storage, but your application + Kubernetes dependencies + data + metadata + secrets, and it does so with bare-metal performance. It eliminates complex mappings for backup, clones, replication and recovery.

Low footprint and high scalability

Symcloud™ scales down for the edge while retaining full functionality and scales to over 1,000,000 elements, with advanced features like network-wide monitoring, analytics and closed-loop automation.

Automated and resilient life cycle management

Full stack lifecycle management of the bare-metal HW/SW and cloud platforms, 3rd party appliances and CNF/VNF services chains, providing automated workload, storage placement network-as-a-service and remote performance tuning.

Simplified deployment, flexible and high performing

Symcloud Platform provides fully declarative automation that eliminates the need for CLI and development expertise, with one-click onboarding. It heals and migrates using autoconfigured, service-pinned policies.

Rich Observability

Multitenant-enabled observability with integrated chargeback and granular RBAC controls. Use Symcloud™ metrics to gain visibility into the resources across multiple clusters and sites, for troubleshooting automation and planning.

Connect with us for more information on how we accelerate industry-wide Open RAN deployments.

How can we help?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.