Deep inside the Cloud Managements Platforms: the OpenStack case study

Deep inside the Cloud Management Platforms: theOpenStack case study

Franco Callegati, Walter Cerroni, Chiara Contoli, Francesco Foresta,Arnau Salas Figuerola, Eduard Reina Fuente

Alma Mater Studiorum - University of BolognaDepartment of Electrical, Electronic and Information Engineering

G. Marconi

Mail: [email protected]

Jul 17, 2015

Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 1 / 19

Overview

1 IntroductionCloud computing and its management

2 The OpenStack caseIntroductionComponents and structureDeep inside

Network parts

Virtual Network InfrastructureSecurity tricks

3 Dynamic Service Chaining in OpenStackL2 topology & VNIProof-of-Concept

4 Conclusions


Introduction Cloud computing and its management

What are Cloud Managing Platforms?

The cloud computing paradigm points out that network resources,storage and computing are offered from a provider to a client as aservice

As it already is for water, gas, electricity, telephone. . .

A cloud platform is a cluster of physical machines which containssome servers that will be offered as a service to a client, in accordingto the IaaS (Infrastructure-as-a-Service) paradigm

It has to be managed ⇒ Cloud management platform

This is an integrated product that provide for the management ofpublic, private and hybrid cloud environments

Many platforms have been developed during these years, e.g. AmazonWeb Services, Google Cloud Platform, HP Cloud, Microsoft Azure,Nebula, Rackspace Cloud, OpenStack. . .




















The OpenStack case Introduction

OpenStack

It’s an Open Source joint project of Rackspace Cloud and NASA,assisted by more than 200 companies from the IT industry

Once installed on a distributed system, users can create a virtualnetwork infrastructure (VNI) composed of instances (e.g.implemented as virtual machines) and networks appliances (routers,firewalls, etc) in a simple and efficient way, taking advantages ofmulti-tenancy


The OpenStack case Introduction

OpenStack

It’s an Open Source joint project of Rackspace Cloud and NASA,assisted by more than 200 companies from the IT industry

Once installed on a distributed system, users can create a virtualnetwork infrastructure (VNI) composed of instances (e.g.implemented as virtual machines) and networks appliances (routers,firewalls, etc) in a simple and efficient way, taking advantages ofmulti-tenancy


The OpenStack case Components and structure

OpenStack Components

OpenStack is composed of various components: each of them worksin a specific area

Nova = computing, Neutron = networking, Keystone = credentials,Glance = image storaging, Horizon = Web dashboard. . .



OpenStack Components

OpenStack is composed of various components: each of them worksin a specific area

Nova = computing, Neutron = networking, Keystone = credentials,Glance = image storaging, Horizon = Web dashboard. . .



Web Dashboard



OpenStack minimal cluster

Every Neutron based OpenStack cluster is composed of at least threephysical servers:

A compute node, where the Virtual Machines are storedA network node, which provides connectivity for themA controller node, which manages all user requests

They contain the OpenStack components and communicate betweenthem with REST API calls

It means HTTP is used to make calls between machines in a verysimple way

These machines are connected by three networks

Management net, used by the admin to access the cluster nodes andfor interservice communicationsExternal net, which provides the Internet access to the VMsData net, used for inter-VM communications

Packets on this net will be VLAN tagged or encapsulated (GRE)























Cluster, in detail


The OpenStack case Deep inside

Virtualization

In the OpenStack environment acts a virtualization software whichco-operate with Nova:

this hypervisor is used to create the virtual environment whichemulates the physical machine’s behaviour ⇒ many virtual hosts arerunning inside a physical host, at the same time!it uses Libvirt, a generic API that supports various virtualizationbackends (VirtualBox, VMWare, XEN, QEMU+KVM) and allows themanaging and migration of the VMs ⇒ NFV



Virtualization


this hypervisor is used to create the virtual environment whichemulates the physical machine’s behaviour ⇒ many virtual hosts arerunning inside a physical host, at the same time!

it uses Libvirt, a generic API that supports various virtualizationbackends (VirtualBox, VMWare, XEN, QEMU+KVM) and allows themanaging and migration of the VMs ⇒ NFV



Virtualization


this hypervisor is used to create the virtual environment whichemulates the physical machine’s behaviour ⇒ many virtual hosts arerunning inside a physical host, at the same time!it uses Libvirt, a generic API that supports various virtualizationbackends (VirtualBox, VMWare, XEN, QEMU+KVM) and allows themanaging and migration of the VMs ⇒ NFV



Neutron abstractions

Neutron defines some network abstractions:

Network: an isolated L2 network segmentSubnet: an IP address block on a certain networkRouter: a gateway between subnetsPort: an attachment point to a network

Neutron implements these abstractions inside the Virtual NetworkInfrastructure in the nodes (host level) ⇒ in this way VMs (at theguest level) can see the virtual networks

Users only see these abstractions!

In order to implement more than one Virtual Router in the Networknode, OpenStack uses network namespaces

They replicate the network software stack ⇒ isolation between multiplenetwork domains in the same host!




















The OpenStack case Virtual Network Infrastructure

Bridges

In the compute and network node there are many OpenVSwitches:an integration bridge which acts as a hub of a star network, br-int ⇒ itis possible to implement SDN traffic steering on it!

a bridge for each physical network, br-data/br-tun if connected to theData net or br-ex if connected to the External neta Linux Bridge for each interface of VMs, qbr-X



Bridges

In the compute and network node there are many OpenVSwitches:an integration bridge which acts as a hub of a star network, br-int ⇒ itis possible to implement SDN traffic steering on it!a bridge for each physical network, br-data/br-tun if connected to theData net or br-ex if connected to the External net

a Linux Bridge for each interface of VMs, qbr-X



Bridges

In the compute and network node there are many OpenVSwitches:an integration bridge which acts as a hub of a star network, br-int ⇒ itis possible to implement SDN traffic steering on it!a bridge for each physical network, br-data/br-tun if connected to theData net or br-ex if connected to the External neta Linux Bridge for each interface of VMs, qbr-X



Multi-tenancy and security groups

In the compute node there are also veth pairs and/or patch portsthat connect the different bridges

One of the main issue in OpenStack, as every other cloudmanagement platform, is to divide different users’ traffic

For every network there is a VLAN internal ID ⇒ the veth pair portattached to the integration bridge is access for a specific VLAN ID(the internal one related to the VM network)

As many GRE tunnels ID or as many VLAN external ID as tenants,depending on the type of data network configured

It is also important to implement a set of firewall rules for every VM⇒ Security Groups

They are implemented by Neutron applying the native kernel filteringfunctions to bridged VM tap interface on Linux BridgeSimply, they are a number of iptables rules on the compute node






For every network there is a VLAN internal ID ⇒ the veth pair portattached to the integration bridge is access for a specific VLAN ID(the internal one related to the VM network)

As many GRE tunnels ID or as many VLAN external ID as tenants,depending on the type of data network configured








For every network there is a VLAN internal ID ⇒ the veth pair portattached to the integration bridge is access for a specific VLAN ID(the internal one related to the VM network)As many GRE tunnels ID or as many VLAN external ID as tenants,depending on the type of data network configured








For every network there is a VLAN internal ID ⇒ the veth pair portattached to the integration bridge is access for a specific VLAN ID(the internal one related to the VM network)As many GRE tunnels ID or as many VLAN external ID as tenants,depending on the type of data network configured





Inside the nodes


Dynamic Service Chaining in OpenStack L2 topology & VNI

Dynamic Service Chaining: implementation details

The topology is similar to the L2 one in the Mininet case, but thereare some noteworthy differences

All virtual network appliances as well as users are implemented as VMs,configured for the case study

The implementation of a real WAN Accelerator, Trafficsqueezer, hasbeen done both at the source and destination through the installationof a specific kernel and the configuration via browserThe destination host is located, as the other destination networkappliances, in a remote server out of the OpenStack cluster ⇒ morerealistic measurements

The Traffic Shaper has been implemented with the Linux TrafficControl command suite, setting the bandwidth to 10 MBit/s

Every VM had an additional interface for all the traffic not related tothe test-bed (e.g. Internet traffic)





All virtual network appliances as well as users are implemented as VMs,configured for the case studyThe implementation of a real WAN Accelerator, Trafficsqueezer, hasbeen done both at the source and destination through the installationof a specific kernel and the configuration via browser

The destination host is located, as the other destination networkappliances, in a remote server out of the OpenStack cluster ⇒ morerealistic measurements







All virtual network appliances as well as users are implemented as VMs,configured for the case studyThe implementation of a real WAN Accelerator, Trafficsqueezer, hasbeen done both at the source and destination through the installationof a specific kernel and the configuration via browserThe destination host is located, as the other destination networkappliances, in a remote server out of the OpenStack cluster ⇒ morerealistic measurements



















Case study: L2 topology & VNI


Dynamic Service Chaining in OpenStack Proof-of-Concept

Results

At the source

1

10

100

1000

0 50 100 150 200 250 300 350 400 450

Thro

ughp

ut (M

bit/s

)

Time (s)

DPI-in (p3)WANA1-in (p4)

WANA1-out (p5)TC-in (p6)

TC-out (p7)

At the destination


Dynamic Service Chaining in OpenStack Proof-of-Concept

Results

At the source

1

10

100

1000

0 50 100 150 200 250 300 350 400 450

Thro

ughp

ut (M

bit/s

)

Time (s)

DPI-in (p3)WANA1-in (p4)

WANA1-out (p5)TC-in (p6)

TC-out (p7)

At the destination


Conclusions

What’s next?

Dynamic Service Chaining in a L3-like topology

Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying newOpenFlow versions

More context awareness ⇒ we will use an orchestrator to installmore dinamically flows in the OVSs

Generalization of the case study, making the whole thing moreautomatic

Experiments with VMs live migration

Cloud perfomances tests

Application of Virtual Tenant Network: a way to create virtualnetworks in a complete automated way, using REST API calls


Conclusions

What’s next?









Conclusions

What’s next?









Conclusions

What’s next?









Conclusions

What’s next?









Conclusions

What’s next?









Conclusions

What’s next?









Conclusions

Questions?

Do you have any questions?


Conclusions

And that is all!

Thanks for your attention!
