Things good to know before the OpenStack Tokyo Summit.

OpenStack has a 6 months release cycle and each release is given a name in which the name is associated to the location where OpenStack Summit was held and follow the sequence of the English alphabet.  The 12th OpenStack release has the name Liberty and is officially available on Oct 15, 2015.

OpenStack Summit Tokyo will be held on Oct 27 - Oct 30 in Tokyo Japan.  On this weekend, a large portion of the OpenStack community is heading to Tokyo with excitement.  Even I am not able to attend this summit in Japan, I am excited to see what new technology innovation will be announced as well as the future direction of OpenStack.  (Note: OpenStack summit actually has 2 parts.  One part is the conference and the other part is the design summit where the open source community gather together to discuss and to shape the direction and/or feature of the next OpenStack release).

What's new in the Liberty release?

Liberty is the first release with the "Big Tent" approach.

Over the weekend, I have a chance to take a look at what's new in the Liberty release.  The most comprehensive and detail description of what's new in the Liberty is of course the release note from OpenStack.  If this is too detailed then Nick Chase (@NickChase) has an good article on the 53 things that are new in Liberty.  Also OpenStack has a very informative web page that describes the Liberty release.  There are 5 categories listed on this page as new features in Liberty:

1. Enhanced Manageability
2. Simplified Scalability
3. Extensibility to Support New Technologies
4. Container Management
5. Orchestration

The categories are all self explanatory.  It is, however, interesting to see that container management is by a category by itself and is not under extensibility to support new technologies. 

In this post let me highlight a few things that interest me the most.

Most Useful

For me the new interface to display network topology - Curvature Network Topology interface in Horizon is the most useful to visual how the network looks like.  A sample display of this new interface is:

image source: https://www.openstack.org/software/liberty/

Hot Trend

There are 2 topics that are widely discussed in the IT industry and these 2 hot technologies are opening up new use cases and to help consumer either to save money or to deploy the services faster and easier.  These 2 hot trends are:

1. Docker container
2. NFV

OpenStack provide a natural infrastructures for these 2 technologies as well as a platform to bring out the essence or core features.

Docker Container

Docker containers need an orchestration engine to make it powerful and there are Docker Swarm, Kubernetes, CoreOS fleet that builds on etcd and systemd as well as Mesos.

In the OpenStack Vancouver summit there is a one day special track on container in which there is Project Magnum which was initially to work with Kubernetes in OpenStack and now the Container Orchestration Engine (COE) in Magnum is expanded to Docker Swarm and Mesos.

In July Google joined the OpenStack Foundation should be able to bring in their expertise on container and Kubernetes to the Magnum project.  I have a blog post on this subject. Also, the introduction of libnetwork brings new networking options to Docker container.

There are 2 new projects related to Docker Containers in the Liberty release:

• Project Kolla - provide production level container deployment tools
• Project Kuryr - leverage OpenStack Neutron for container.

NFV

The service provider industry is embracing NFV because it provides agility and huge cost saving advantages.  AT&T is said to have saved big on capex with NFV. There is the OPNFV project that is driving the advancement of open source NFV functionality and stability.

Both VMware announced vCloud NFV in VMworld Europe 2015.  Cisco also has it NFV offering.

Similar to Docker Container, NFV needs an infrastructure and OpenStack is a able to provide this need.

Interestingly, the effort of NFV in OpenStack is under the Nova project instead of Neutron as one might think.

Security

Role Based Access Control (RBAC) is added to both Heat and Neutron to provide better security on resource management and usage.

Security is essential to all projects and if OpenStack wanted to break into the enterprise market, security is an important element that needs to be addressed.  OpenStack already has a security group to handle security related issue in OpenStack.  Any bug fix that checked in has a SecImpact keyword to flag the OpenStack security group to look at potential security risk that is introduced in the code checkin.  There is also Project Bandit that can check for security issues in Python code in which OpenStack is written in.

Looking Ahead

I am excited to listen to the keynote and the YouTube recording of the various presentations from the OpenStack Tokyo summit. 

It will be interesting to see the future direction of OpenStack as decided by the community at the OpenStack Design Summit.

Another thing that I am looking forward to is to visit Japan and to try out the local ramen and the beer. 

image source: Gary Kevorkian of Cisco when he is at the OpenStack Tokyo Summit.

Network Virtualization for OVS (Open vSwitch) - Open Virtual Network

Open vSwitch is a open source virtual switch that provide logical switching on hypervisors similar to the VMware vSwitch and the Cisco Nexus 1000V. Full feature of Open vSwitch can be found here.  We can find good resource on Open vSwitch here and here

Open vSwitch has 3 main components:

• ovsdv-vswitchd
• ovsdb-server
• Kernel module

 

image source: http://www.jedelman.com/uploads/9/7/8/6/9786883/8614557.jpg?531

This diagram explain the operation of Open vSwitch very well.  Visually we can see the various components in a physical host (a picture is worth a thousand words).

 

image source: https://networkheresy.files.wordpress.com/2011/06/screen-shot-2011-06-05-at-6-44-32-pm.png

When we look at the features supported by Open vSwitch (OVS), we see that the list is very comprehensive for a switch.  (note: a switch is for layer 2 switching, check out my other post if you are not familiar with the 7 Layers of the OSI model).  There are 2 features on the list that makes OVS a good tool for OpenStack.  The 2 features are:

1. OpenFlow protocol support
2. Multiple tunneling protocols (GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)

According to this article, OVS is the most popular plugin for OpenStack.

Open Virtual Network

On Jan 13, 2015, it was announced that a new sub-project was created under the OVS project - Open Virtual Network (OVN).

The main idea of Open Virtual Network is provide a lightweight control plane that provides native support for common virtual networking abstractions.  

Open Virtual Network (OVN) will include:

• logical switches and routers,
• security groups, and
• L2/L3/L4 ACLs,

and they are to be implemented on top of a an overly network such as VXLAN, NVGRE or GENEVE.   This is  most suitable to integrate with OpenStack Neutron as a plugin.

This article further explain that OVN provide Neutron with improved data plane performance through shortcut, distributed logical L3 processing and in-kernel based security groups, without running special OpenStack agents on hypervisors. Lastly, it will provide a scale-out and highly available gateway solution responsible for bridging from logical into physical space.

OVN will also work with Linux container systems.  Containers are also widely deployed in the OpenStack platforms. I also had a blog post on this topic on my OpenStack for Beginners series.

Open Virtual Network Architecture
Open Virtual Network builds on top of OVS and has the following layers:

1. Open vSwitch
2. OVN Controller
3. OVN Database

Detail of the OVN architecture can be found in this OVN Architectural Guide.

1. Open vSwitch
As Open Virtual Network is a sub-project OVS and is therefore a natural layer for the foundation.  OVS has special extension for OpenFlow support and thus OVN is tailor to how OVS used OpenFlow.  OVN may not work with other OpenFlow implementation.

OVN used the OVS integration guide (IntegrationGuide.md) in the OVS repository.  This defines the interaction between the OVN controller and the hypervisor or container that used the OVS.

2. OVN Controller
This controller resides on each hypervisor and is not a centralized model that is popular on most SDN implementation.  The OVN controller runs on the hypervisor or host as a daemon.  The OVN controller on the southbound interface with the ovs-switchd using the OpenFlow protocol and the ovsdb-server using the OSVDB protocol. And on the northbound interfaces with the OVN Database using the OSVDB protocol.

This diagram is taken from the OVN Architecture Guide:

                             OVN Database
                                    |
                                    |
                          (OVSDB Protocol)
                                    |
   +-------------------------------------------------------------------+
   |                                |                                  |
   |                                |                                  |
   |                           ovn-controller                          |
   |                              |     |                              |
   |                              |     |                              |
   |               +--------------+     +--------------+               |
   |               |                                   |               |
   |               |                                   |               |
   |       (OVSDB Protocol)                       (OpenFlow)           |
   |               |                                   |               |
   |               |                                   |               |
   |         ovsdb-server                         ovs-vswitchd         |
   |                                                                   |
   +---------------------------- Hypervisor ---------------------------+

3. OVN Database
At this initial state of OVN, OVSDB is being used as the OVN Database. One of the design goal for the OVN Database is high availability but the ovsdb-server does not support clustering and it is important to resolve this issue as the OVN is supported to be a production ready feature.

This OVN Database stores 3 types of information:

1. Physical Network Information
2. Logical Network Information
3. Binding (logical element location, logical port and MAC address association)

Cloud Management System
Open Virtual Network requires a Cloud Management System such as OpenStack to function.  There is a plugin available for OpenStack and OVN integration.  This plugin translate the Cloud Management System configuration into the OVN Logical network information (in the form of logical data path flows) that are stored in the OVN Database.

More to come in the near future
Hopefully, we can see more development of this Open Virtual Network soon and if I am able to attend the OpenStack Vancouver summit I will certainly gather more information in this area and share them in this blog.

Reference:

"Features." Features. N.p., n.d. Web. 12 Mar. 2015.

 "OVN, Bringing Native Virtual Networking to OVS." Network Heresy. N.p., 13 Jan. 2015. Web. 12 Mar. 2015.

OpenStack Series: Part 18 – Network Function Virtualization in OpenStack

NFV (Network Function Virtualization) is gaining traction these days both in the enterprise and in the carrier market.  The main driving force is NFV's ability to reduce CAPEX and OPEX by moving the the network function from purpose-built, expensive and sometimes under utilized hardware to software that can be run in a virtualized form (virtual machine or Linux container).

Open Platform NFV - OPNFV

The Linux Foundation announced the formation of the Open Platform NFV project whose goal is to focused on accelerating the evolution of Network Functions Virtualization (NFV). OPNFV will establish a carrier-grade, integrated, open source reference platform that industry peers will build together to advance the evolution of NFV and to ensure consistency, performance and interoperability among multiple open source components.  

Open Source for NFV is a key element for better integration with the other already blooming open source projects such as OpenDayLight, OpenStack and CloudStack as well as no need for vendor lock-in with hardware and support contract.

Akanda

On Nov 3, 2014, DreamHost announced launching a new company called Akanda specializing in network virtualization technology.  DreamHost had been using the NFV on their OpenStack platform for over a year in production before spinning out this new company.  Here is a nice write up on Akanda.  According to this article: "Akanda NFV implementation provides OpenStack integrated L3 network virtualization on a VMware NSX L2 overlay. It interfaces with the OpenStack Neutron REST APIs and includes a sophisticated management and orchestration platform to monitor, configure, and manage virtualized routers. In the future, Akanda will be extended to virtualize additional network functions, including load balancing and firewalls, and will feature pluggable backends to alternative L2 overlays."

image source: http://www.convergedigest.com/2014/11/akanda-debuts-open-source-nfv-platform.html

Network Function in a Container

Also as indicated on one of my previous blog post on "Networking options for Dockers" that one networking option for Docket is SDN and there is a new company called SocketPlane bringing SDN into Docker and this will open up ways  using a container for NFV or in this case NFD (Network Function Dockerization) <- a new name that I come up with based on the word "Dockerize".  

When we go to SocketPlane's website we will see "Native to Docker", "Familiar to NetOps" and "Application Friendly".  I think this 3 phases summarize the product direction that this company is heading.  One more thing to note is that the founders of this startup are all veterans of the OpenDayLight projects along with former executive from OpsCode/Chef.

A lots of efforts are being put into integrating containers to work on OpenStack especially in the area of container orchestration where OpenStack Heat can fill in the void. This provides good opportunity for Network Function to be dockerize and being deployed in OpenStack. 

Container orchestration is an important area for container to be deployed in any cloud environment.  In Amazon Web Services Re:Invent, AWS announced EC2 Container Service in addition to its Docker support in AWS Elastic BeanStalk.

When the orchestration puzzle for container is solve, putting network function in a container can provide more cost saving than putting the networking function on a virtual machine.  It can also provide better CAPEX and operational efficiency because of leaner resource utilization.

OpenStack and NFV
In the OpenStack Juno release NFV features are added to Nova to lay the groundwork for large scale providers to further abstract networking capabilities.  A sub team is formed under the Neutron and I think the feature developed under this sub team will be introduce in the Kilo release.

Service provider is looking for a open platform to deliver their services and we can see this trend by the forming of the Open Platform NFV.

OpenStack and NFV is an attractive combination because with the orchestration power of OpenStack NFV is made more powerful to deliver the virtualized network function in a quicker and automated manner.

A lots of works still needs to be done for NFV in OpenStack.

In the press release for the Juno release from OpenStack, the work done is to lay a foundation for OpenStack to be the platform for NFV deployment.  It also mentioned that: NFV represents a massive shift in how networking and telco services are developed and deployed. An NFV development team was formed in May at the OpenStack Summit and has identified nine use cases to run NFV workloads on top of OpenStack environments. Initial features arrived in the Juno release, and additional NFV-related work will continue over coming releases.
The OpenStack NFV development team has put together a good wiki page with a very comprehensive description of OpenStack and NFV including mission statement, definition of NFV, who are working on this project as well as some use cases for NFV in OpenStack.

APIs for NFV in OpenStack
On important and yet not so easy job is to define the APIs for NFV in OpenStack.  The main idea for the API for abstraction and yet user of the API will have to provide the detail parameters for deploying NFV based on individual customer's need.

How do we strike the balance between abstraction and the necessity of providing ability to tune the system by changing parameters?

OpenStack Carrier-grade NFV requirement
At this time the integration of NFV in OpenStack is geared toward Service Providers.  There seems to be more use cases for NFV in the Telco space. There are 3 requirements that is specific to carrier-grade NFV (not just for OpenStack):

• Performance
• Deterministic
• Reliability

I work for the enterprise division of Alcatel-Lucent and I can see that carrier-grade does demand more in these 3 areas.  Workload for one customer may not be very high but for service providers they have a lots of average workload customer plus the service providers have to maintain the service according to the SLA (Service Level Agreement).

To satisfy the carrier-grade requirement, the OpenStack development team is working on the following technologies to make sure the OpenStack infrastructure can deliver the best "horse power" or near native performance from the underneath hardware:

SR-IOV (Single Root I/O Virtualization)

• A PCI-SIG standard to provide native I/O virtualization to PCI Express devices.
• Good article on this subject here, here and here.

DPDK (Data Plane Development Kit)

• a set of software libraries and Ethernet drivers (native and virtualized) that run in Linux user space to boost packet processing throughput on Intel® architecture.
• Works with Intel processors only.

NUMA and L3 Cache 

• Pinning a vCPU to a physical cpu of a multi-socket processor can help access the processor's local memory (L3 Cache) and thus boosting the processing speed.

Large Page Table size

• Larger page table size can help the VM running as NFV to keep the data in memory instead of fetching them from storage.

Big Potential for 2015
I am only touching the surface of this subject and there are lot more to it.  In the month of November 2014 both Juniper and Alcatel-Lucent announced that they are offering virtualized high end/performance router catching up with Cisco and Brocade's Vyatta Router for NFV.  Seems like the year of 2015 we will see hot competition in the carrier market NFV platform.

Again, will blog about this again since networking and security is my main subject of interest.

Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a Web Based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 17: Congress - Policy Service 
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron

Reference:
"About." Home. N.p., n.d. Web. 03 Nov. 2014.
"OpenStack® Juno Release Available Today." Press Release » OpenStack Open Source Cloud Computing Software. N.p., n.d. Web. 05 Nov. 2014.
"01.org." Intel® DPDK. N.p., n.d. Web. 05 Nov. 2014.
"Q: What Is SR-IOV?" Windows IT Pro. N.p., n.d. Web. 05 Nov. 2014. 
cdn-static.zdnet.com/i/r/story/70/00/034207/opnfv-400x260.png 
"Akanda Debuts Open Source NFV Platform ~ Converge! Network Digest." Akanda Debuts Open Source NFV Platform ~ Converge! Network Digest. N.p., n.d. Web. 17 Nov. 2014.

OpenStack Series: Part 8 – Neutron – Networking Service

As indicated in a previous post that compute, storage and network are the 3 main building block of OpenStack.

In the beginning of OpenStack, networking is under the Nova project - nova-networking.  It served its needs to support OpenStack when OpenStack is still in the infant state.  Later on as OpenStack becomes more mature, the need to for a more flexible and "powerful" networking module is required.  Nova-networking is found to be limited in selection of possible network topology, and most of all it cannot utilize third party solutions.  Nova-network can only uses Linux-bridge, limited network type and iptable to provide network services for hypervisor in Nova.  Capability of nova network can be found here.

A new and separate project is incubated and then integrated into OpenStack for networking.  It was initially named Quantum but due to conflict of an existing commercial product, the project is renamed Neutron.  Some of the older documents for OpenStack still reference Quantum as the networking service.

Neutron Components

OpenStack Wiki describe Neutron as:
A standalone service that often deploys several processes across a number of nodes. These processes interact with each other and other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plug-ins for additional processing. 

The OpenStack Networking components are:

neutron server (neutron-server and neutron-*-plugin)

This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server and plugin agents require access to a database for persistent storage and access to a message queue for inter-communication.

plugin agent (neutron-*-agent)

Runs on each compute node to manage local virtual switch (vSwitch) configuration. The plug-in that you use determine which agents run. This service requires message queue access. Optional depending on plugin.

DHCP agent (neutron-dhcp-agent)

Provides DHCP services to tenant networks. This agent is the same across all plug-ins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access.

L3 agent (neutron-l3-agent)

Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. Optional depending on plug-in.

network provider services (SDN server/services)

Provide additional networking services to tenant networks. These SDN services might interact with the neutron-server, neutron-plugin, and/or plugin-agents through REST APIs or other communication channels.

image source: http://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png

Neutron API
Neutron API allow users to define:

Network

• An isolated L2 segment, analogous to VLAN in the physical networking world.

Subnet

• A block of v4 or v6 IP addresses and associated configuration state.

Port

• A connection point for attaching a single device, such as the NIC of a virtual server, to a virtual network. Also describes the associated network configuration, such as the MAC and IP addresses to be used on that port.

Neutron API Extension
With the API extension, user is able to define additional networking function via Neutron plugins.  This diagram shows the relationship of Neutron API, Neutron API extension and Neutron plugin where the plugin interface with an SDN Controller - OpenDaylight.

image source: http://thoughtsoncloud.com/wp-content/uploads/2014/10/SDN-diagram.jpg

Neutron Plug-ins

Plugin is the interface between Neutron and the back-end technologies such as SDN, Cisco, VMware NSX so that the consumer of Neutron can take advantage of these 3rd party networking equipment or software.

Popular plug-ins include:

• Open vSwitch
• Cisco UCS/Nexus
• Linux Bridge
• Nicira Network Virtualization Platform
• Ryu OpenFlow Controller
• NEC OpenFlow

A comprehensive list of Neutron plug-in can be found here and here.

One plugin that is not directly related to the 3rd party vendor but is a very important plugin is the ML2 (Modular Layer 2) plugin that is introduced in the Havana release. This plugin allows concurrent operations of mixed network technologies in Neutron.

image source: http://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/guide-c07-732454.doc/_jcr_content/renditions/guide-c07-732454_0.jpg

Without the ML2 driver, Neutron can only provide one type Layer-2 service because the operation is monolithic.  ML2 has the concept of driver Type and driver Mechanism.  ML2 by itself can be a blog post. Will post more in the coming days.

More to come

There are a lot more to talk about for Neutron.  Will cover more Neutron related topics in the future.  For now this IBM document is a good comprehensive article on Neutron.

Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 6: Cinder - Block Storage Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 9: Horizon - a web based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 17: Congress - Policy Service
OpenStack Series Part 18: Network Function Virtualization in OpenStack
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron
Reference:
"Chapter 24. Networking Architecture." Document ATOM. N.p., n.d. Web. 05 Nov. 2014.