OpenNaaS-CNSMO

What is OpenNaaS-CNSMO?

OpenNaaS CNSMO150x150_bis

OpenNaaS-CNSMO is the platform providing the network services in Cloud computing environments.

Why OpenNaaS-CNSMO?

Limited access to IaaS network resources

In order for OpenNaaS to model and expose network services, the work started from the premise of having access to IaaS providers’ network resources (either physical or logical network resources) in order to gain control and management over them and provide network services by exposing concrete capabilities to the CYCLONE users. Nevertheless, the market reality is different and comes hand in hand with the different partners bringing cloud IaaS to the project: mostly due to security reasons, it´s not possible to enable access to OpenNaaS to the cloud network resources (switches, Top of the Racks (ToRs), firewalls, etc.), since the provided IaaS is part of a larger infrastructure and utilizes network resources of their production environment.

OpenNaaS-CNSMO

OpenNaaS-CNSMO: Network as a Service for Cloud Application Service Providers.

Limited options while integrating with Cloud Service Management (CSM) Platforms

Previous IaaS related limitation (no access to network resources) could have driven the efforts to provide and deploy network services working on top of the CSP platforms (e.g. AWS, OpenStack, Exoscale) that manage public and private IaaS infrastructures, by working as a plugin to configure and manage the specific network options that they may include. The large amount and heterogeneity of CSMs while managing the network aspects of Cloud infrastructures wold have lead to ad-hoc developments constraoined to the CMSs’ options and roadmaps, preventing OpenNaaS from being a general solution.

Thus, OpenNaaS has been forked in a CYCLONE adapted framework code-named CNSMO, that provides network services using the OpenNaaS concept and abstractions in overlay topologies. The reason to fork OpenNaaS into CNSMO is that the overlay has slightly different requirements. Now, CNSMO has to enable network services inside overlays, that means, user deployments that are being used and paid by users, so the CNSMO modules need to be as transparent as possible to the users not only in terms of using them but in causing minimum impact in the users’ resources usage. CNSMO has to provide also software solutions implementing the network services, something that formerly was out of scope of the original OpenNaaS framework.

Automation, automation and….automation

One of the key values that OpenNaaS-CNSMO aims to bring to the Cloud ecosystem, is the possibility to automate the deployment of network services, thus limiting the intervention of human agents to very limited cases. The artificial intelligence and mechanisms that CNSMO includes, allows users to select the network service(s) they want to deploy together with the applciation, specify a couple of parameters and…that´’s it! No further actions configurations are needed from the users’ side.

Who benefits from OpenNaaS-CNSMO?

Application Service Providers (ASPs) are the current targt which may benefit from the CNSMO solution. CNSMO leverages on Cloud applicaction deployment tools to complement the set of features and network features that can be offered to ASPs while deploying their applications, for instance, to include VPN secured access to the applications or introduce additional firewalling mechanisms, aspect which is extremly important specially in cloud distributed scenarios.

How it works?

Cyclone networking services rely on CNSMO (Cyclone Network Services Manager and Orchestrator) the software component responsible of deploying, configuring and running the networking services in Cloud Federate environments.

CNSMO is composed by two components:

  • The CNSMO core
  • CNSMO agents running networking services

CNSMO core contains a CNSMO agent running services that are key to CNSMO platform itself. It is not directly related to any networking service. Instead, it runs the distributed system state and other support services CNSMO couldn’t work without.

The System State is used to store the application state, so it can recover from failure or system  shutdown. By using it intensively, module can become stateless which turns out to be very useful when scaling. Moreover, the System State has a message queue that is used by every component to communicate to each others. It offers serialization mechanisms providing implementation independency between modules. It also offers load balancing features, useful to distribute the application load between multiple instances of the same CNSMO component, in this case, multiple instances of the same specific network service module (e.g. VPN service module). It also allows a framework where every CNSMO context announces itself when it is ready and allows other service to subscribe to status changes of
services enabling service orchestration if needed.

CNSMO agents are wrappers for a specific service providing CNSMO the ability to manage that service. Thanks to these agents CNSMO discovers the services, is able to spawn or delete service instances but also orchestrate service deployment between many VMs. CNSMO agents are active and report to the CNSMO core (more specifically to the distributed system state) when launched. A different agent is required for each service in each machine.

OpenNaaS – CNSMO services

A “Service” in the context of CYCLONE is a set of modifications in a user deployment (provided by SlipStream) that provides an added value to the default functionalities of the different CSPs. For example, provide connectivity between two or more CSPs, add new firewall functionalities to the user VMs, configure load balancer, etc.

To this target, OpenNaaS CNSMO tool is deployed as a component within the SlipStream application store, so that the services provided by OpenNaaS CNSMO can be made available to the applications at the deployment time.

This section provides an overview on each individual CNSMO service. For a detailed description of each of them, please refer to CNSMO networking services guide for application developers

The multicloud VPN service

The VPN service is in charge of providing secure connectivity between all client VMs even if they are provisioned using different cloud service providers. The following video shows the CNSMO cornerstone s while deploying nework services coupled with Cloud applications and demonstrates the VPN network service.

 

The multicloud Firewalling service

The video shows how OpenNaaS-CNSMO tool deploys a Firewall service in support of an application which requires to leave open concrete ports. One of the virtual machines of the application port 8080 and the other virtual machine of the application, port 8081. The video shows how OpenNaaS-CNSMO leans on SlipStream software to deploy the Firewall Service in Cloud Federated environments.

 

The Load Balancer Service for Multicloud applications

The load Balancer Service is in charge of provide a way to scale the service behind it transparently and low the workload of specific types of services or applications (i.e a web page). In the video, it can be shown the details on how the Load Balancer network service is deployed together with an application which consists of 2 Word Press instances that need tobalance the incoming HTTP requests. Once more, a clear example of how to automate specific network srevices while deployeing multicloud applications.