OpenStack Networking Services Framework and Model
- Launchpad Entry: services-insertion
- Created: Edgar Magana
- Contributors: Edgar Magana, Ram Durairaj, Mani Ramasamy, Nat Chidambaram & everybody else who wants to join!
Once Cloud Service Provides (CSPs) have got the necessary framework to deliver massively scalable cloud infrastructure, however a new framework to deliver services on the top of that architecture is needed.
This document proposes a model and its respective framework design to deploy, manage, monitor and control on-demand networking services that will be build on the top of the existing OpenStack major components such as compute, storage and networking.
We kindly request feedback for the community to complete this proposal, share with us your comments, reviews and ideas.
There are multiple steps and phases involved on the deployment and management of networking services offered by the Cloud Service Provides (SP) and/or third party entities. Basically, CSPs should be able to offer a wide variety of services such as firewall, load balancing, network acceleration between others, to all its customers and be able to bill them for their use.
There are two basic models to deploy services on cloud computing based on OpenStack. The first one is building the entire network and all the components required based on templates already designed for certain services. The second one is to deploy services on-demand by offering the necessary APIs in order to customize the acquired services and make them fit the computing and networking infrastructure implemented.
The purpose of this document is to define what the best model is to approach and design the respective framework for this proposal. Regardless of that decision there will be multiple steps involved on the deployment and management of networking services offered by the Service Provides (SP). These are some of them:
- Services Definition and Advertising
- Services Insertion (HA Models)
- Services Stitching
- Services Monitoring and Assurance
- Services Management
- Services Statistics and Billing
- Packaging and Bringing Up
- Authorization and Authentication
- OpenStack Dashboard Integration
- Storage Integration (swift/lum)
Services Definition and Advertising
Networking Services should be advertised to CSP’s Customers (Tenants). Services features, benefits and requirements should be clearly exposed to all tenants.
Open Virtualization Format (OVF) offers a standard for distributing software to be run in Virtual Machines. Our work is to define if this is the way to go or something else is needed. The Services definition phase is very important because it will help to understand the computational and networking requirement for each available service. Services Insertion
It defines the way services will be inserted in the network and the necessary configuration steps to have them up and running. There are two types of services, singles and symmetric services.
Single services just require one server to enforce their functionality and they are mostly deployed at the application server side of the network. Example of these type of services are load balancers and firewalls among others.
Symmetric services will require one server running at each side of the edge routers of the network, one for the client side and one for the server application one. Those services may have an understanding of its pair server configuration but it is not necessary. Example of these type of services are service applications accelerator.
Services Insertion Models
Cloud Service Providers deploy and administrate network services
In this model, CSPs will deploy services for all the network traffic of a specific tenant VPC. This means that all the traffic coming from the public network to the tenant's applications will be passing through each one of the networking services. Let's describe an example to clarify this model approach.
CSP will provide networking services that tenants may or may not use as a part of the basic connectivity from the customer’s network to the acquired resources on the Cloud SP. The following figure describes this scenario.
In this scenario, CSP has been deployed a firewall for all incoming traffic to “Enterprise-B” applications. SP manages and maintenance this networking service (firewall) whereas Enterprise-B does not have any control over it. This use case makes sense for the CSP to become more competitive versus other CSPs and also to enhance connectivity performance, security and scalability for its customers.
Tenants deploy and administrate network services
In this model, Tenants will have full control over the networking services and they will be in charge of services’ administration and maintenance. Tenants will decide which services they want to deploy, where they want to deploy them and also how many instances of that service will be available.
In this case Enterprise-B has decided to request a firewall services for all its traffic on the Cloud Data Center, this firewall service is deployed and maintained by the CSP. Enterprise B deploys and controls a web optimization service for network segment “V” and Application Control Engine on network “X”. On the other hand, Enterprise A does not require the firewall services offered by the CSP because its network “Z” has a VPN service activated and it is good enough for the applications running on network “Z”.
Services Insertion Wiring Modes
Regardless the service insertion model used and the type of service that will be inserted in the network, there are different modes to wire a service into the network. These are the two proposing configurations:
- In-Path (Bump in the Wire)
In this mode, the service is placed in the path of the traffic to the server VMs, by splitting the network into two, and having the service bridge between the two, in the process applying the service. This is achievable with the current set of Quantum APIs. HA in this mode is achieved through an external monitoring entity that monitors the health of the service and kill/re-spins if it went down.
- Out-of-Path (Redirection)
In this mode, the service (single node or a cluster of nodes) is placed out of the normal traffic flow path, and the gateway redirects the candidate set of traffic to the service. After the service has been provided to the traffic, it is returned back to the gateway for forwarding to the end host.
HA in this mode is achieved through an external monitoring entity as in the in-path case. In addition, the VPN gateway could also monitor the state of the service and choose to make alternate redirection decisions.
Use Case - Tenants Deploys and Administrate a Service:
Let's describe a use case where a CSP offers not just conventional computational resources but also networking resources through Quantum APIs. We are assuming that Tenant-A has already few applications deployed along three different networks identified as Network Z, V and X. All services in this use case are single services and they will be inserted using the “In-Path” mode.
Enterprise-A wants to have a firewall service on Network-V and Network-X and Wan Optimization services on Network-X. The following diagrams show this configuration before and after inserting these two services. In this use case, tenant will insert both services following the second services insertion model by using Quantum APIs. The set of steps and APIs calls will be as follows:
Creates the new networks and necessary ports:
- create_network (net_name, tenant_id) → network-G
- create_network (net_name, tenant_id) → network-F
- create_port (net_id, tenant_id) → Firewall
- create_port (net_id, tenant_id) → Wan Opt
Unplugging interfaces between the GW and Network X and V:
- unplug_iface (tenent_id, net_id, port_id) → network-X
- unplug_iface (tenent_id, net_id, port_id) → network-V
Instantiate both services from VM images:
- euca-run-instances (Firewall)
- euca-run-instances (Wan Opt)
Connect the interfaces to their corresponding ports
- plug_iface (tenent_id, net_id, port_id) → From Net-V to FW
- plug_iface (tenent_id, net_id, port_id) → From Net-F to FW
- plug_iface (tenent_id, net_id, port_id) → From Net-G to FW
- plug_iface (tenent_id, net_id, port_id) → From Net-X to Web Opt
- plug_iface (tenent_id, net_id, port_id) → From Wan Opt to Net-F
- plug_iface (tenent_id, net_id, port_id) → From Net-G to GW
Management Best Practices:
A easy way to solve potential management issues, Enterprise could create a new network named management network where all services will be connected as we shown on previous image.
- create_network (net_name, tenant_id) → management-network
- create_port (net_id, tenant_id)
- plug_iface (tenent_id, net_id, port_id) → Firewall
- plug_iface (tenent_id, net_id, port_id) → Web Opt