This document provides an overview of cloud computing management platforms, focusing specifically on OpenStack, an open-source project for building and managing public and private clouds. It details the architecture and components of OpenStack, such as Nova for computing and Neutron for networking, and discusses dynamic service chaining and virtual network infrastructure. The research also explores aspects like multi-tenancy, security groups, and implementation details of a proof-of-concept case study related to dynamic service chaining.

1. Deep inside the Cloud Management Platforms: the
OpenStack case study
Franco Callegati, Walter Cerroni, Chiara Contoli, Francesco Foresta,
Arnau Salas Figuerola, Eduard Reina Fuente
Alma Mater Studiorum - University of Bologna
Department of Electrical, Electronic and Information Engineering
G. Marconi
Mail: francesco.foresta@unibo.it
Jul 17, 2015
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 1 / 19

2. Overview
1 Introduction
Cloud computing and its management
2 The OpenStack case
Introduction
Components and structure
Deep inside
Network parts
Virtual Network Infrastructure
Security tricks
3 Dynamic Service Chaining in OpenStack
L2 topology & VNI
Proof-of-Concept
4 Conclusions
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 2 / 19

3. 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 a
service
As it already is for water, gas, electricity, telephone. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19

4. 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 a
service
As it already is for water, gas, electricity, telephone. . .
A cloud platform is a cluster of physical machines which contains
some servers that will be offered as a service to a client, in according
to the IaaS (Infrastructure-as-a-Service) paradigm
It has to be managed ⇒ Cloud management platform
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19

5. 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 a
service
As it already is for water, gas, electricity, telephone. . .
A cloud platform is a cluster of physical machines which contains
some servers that will be offered as a service to a client, in according
to 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 of
public, private and hybrid cloud environments
Many platforms have been developed during these years, e.g. Amazon
Web Services, Google Cloud Platform, HP Cloud, Microsoft Azure,
Nebula, Rackspace Cloud, OpenStack. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19

6. 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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 4 / 19

7. 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 virtual
network 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 of
multi-tenancy
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 4 / 19

8. The OpenStack case Components and structure
OpenStack Components
OpenStack is composed of various components: each of them works
in a specific area
Nova = computing, Neutron = networking, Keystone = credentials,
Glance = image storaging, Horizon = Web dashboard. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 5 / 19

9. The OpenStack case Components and structure
OpenStack Components
OpenStack is composed of various components: each of them works
in a specific area
Nova = computing, Neutron = networking, Keystone = credentials,
Glance = image storaging, Horizon = Web dashboard. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 5 / 19

10. The OpenStack case Components and structure
Web Dashboard
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 6 / 19

11. The OpenStack case Components and structure
OpenStack minimal cluster
Every Neutron based OpenStack cluster is composed of at least three
physical servers:
A compute node, where the Virtual Machines are stored
A network node, which provides connectivity for them
A controller node, which manages all user requests
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19

12. The OpenStack case Components and structure
OpenStack minimal cluster
Every Neutron based OpenStack cluster is composed of at least three
physical servers:
A compute node, where the Virtual Machines are stored
A network node, which provides connectivity for them
A controller node, which manages all user requests
They contain the OpenStack components and communicate between
them with REST API calls
It means HTTP is used to make calls between machines in a very
simple way
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19

13. The OpenStack case Components and structure
OpenStack minimal cluster
Every Neutron based OpenStack cluster is composed of at least three
physical servers:
A compute node, where the Virtual Machines are stored
A network node, which provides connectivity for them
A controller node, which manages all user requests
They contain the OpenStack components and communicate between
them with REST API calls
It means HTTP is used to make calls between machines in a very
simple way
These machines are connected by three networks
Management net, used by the admin to access the cluster nodes and
for interservice communications
External net, which provides the Internet access to the VMs
Data net, used for inter-VM communications
Packets on this net will be VLAN tagged or encapsulated (GRE)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19

14. The OpenStack case Components and structure
Cluster, in detail
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 8 / 19

15. The OpenStack case Deep inside
Virtualization
In the OpenStack environment acts a virtualization software which
co-operate with Nova:
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19

16. The OpenStack case Deep inside
Virtualization
In the OpenStack environment acts a virtualization software which
co-operate with Nova:
this hypervisor is used to create the virtual environment which
emulates the physical machine’s behaviour ⇒ many virtual hosts are
running inside a physical host, at the same time!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19

17. The OpenStack case Deep inside
Virtualization
In the OpenStack environment acts a virtualization software which
co-operate with Nova:
this hypervisor is used to create the virtual environment which
emulates the physical machine’s behaviour ⇒ many virtual hosts are
running inside a physical host, at the same time!
it uses Libvirt, a generic API that supports various virtualization
backends (VirtualBox, VMWare, XEN, QEMU+KVM) and allows the
managing and migration of the VMs ⇒ NFV
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19

18. The OpenStack case Deep inside
Neutron abstractions
Neutron defines some network abstractions:
Network: an isolated L2 network segment
Subnet: an IP address block on a certain network
Router: a gateway between subnets
Port: an attachment point to a network
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19

19. The OpenStack case Deep inside
Neutron abstractions
Neutron defines some network abstractions:
Network: an isolated L2 network segment
Subnet: an IP address block on a certain network
Router: a gateway between subnets
Port: an attachment point to a network
Neutron implements these abstractions inside the Virtual Network
Infrastructure in the nodes (host level) ⇒ in this way VMs (at the
guest level) can see the virtual networks
Users only see these abstractions!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19

20. The OpenStack case Deep inside
Neutron abstractions
Neutron defines some network abstractions:
Network: an isolated L2 network segment
Subnet: an IP address block on a certain network
Router: a gateway between subnets
Port: an attachment point to a network
Neutron implements these abstractions inside the Virtual Network
Infrastructure in the nodes (host level) ⇒ in this way VMs (at the
guest level) can see the virtual networks
Users only see these abstractions!
In order to implement more than one Virtual Router in the Network
node, OpenStack uses network namespaces
They replicate the network software stack ⇒ isolation between multiple
network domains in the same host!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19

21. 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 ⇒ it
is possible to implement SDN traffic steering on it!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 11 / 19

22. 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 ⇒ it
is possible to implement SDN traffic steering on it!
a bridge for each physical network, br-data/br-tun if connected to the
Data net or br-ex if connected to the External net
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 11 / 19

23. 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 ⇒ it
is possible to implement SDN traffic steering on it!
a bridge for each physical network, br-data/br-tun if connected to the
Data net or br-ex if connected to the External net
a Linux Bridge for each interface of VMs, qbr-X
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 11 / 19

24. The OpenStack case Virtual Network Infrastructure
Multi-tenancy and security groups
In the compute node there are also veth pairs and/or patch ports
that connect the different bridges
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19

25. The OpenStack case Virtual Network Infrastructure
Multi-tenancy and security groups
In the compute node there are also veth pairs and/or patch ports
that connect the different bridges
One of the main issue in OpenStack, as every other cloud
management platform, is to divide different users’ traffic
For every network there is a VLAN internal ID ⇒ the veth pair port
attached to the integration bridge is access for a specific VLAN ID
(the internal one related to the VM network)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19

26. The OpenStack case Virtual Network Infrastructure
Multi-tenancy and security groups
In the compute node there are also veth pairs and/or patch ports
that connect the different bridges
One of the main issue in OpenStack, as every other cloud
management platform, is to divide different users’ traffic
For every network there is a VLAN internal ID ⇒ the veth pair port
attached 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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19

27. The OpenStack case Virtual Network Infrastructure
Multi-tenancy and security groups
In the compute node there are also veth pairs and/or patch ports
that connect the different bridges
One of the main issue in OpenStack, as every other cloud
management platform, is to divide different users’ traffic
For every network there is a VLAN internal ID ⇒ the veth pair port
attached 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 filtering
functions to bridged VM tap interface on Linux Bridge
Simply, they are a number of iptables rules on the compute node
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19

28. The OpenStack case Virtual Network Infrastructure
Inside the nodes
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 13 / 19

29. 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 there
are some noteworthy differences
All virtual network appliances as well as users are implemented as VMs,
configured for the case study
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19

30. 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 there
are 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, has
been done both at the source and destination through the installation
of a specific kernel and the configuration via browser
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19

31. 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 there
are 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, has
been done both at the source and destination through the installation
of a specific kernel and the configuration via browser
The destination host is located, as the other destination network
appliances, in a remote server out of the OpenStack cluster ⇒ more
realistic measurements
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19

32. 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 there
are 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, has
been done both at the source and destination through the installation
of a specific kernel and the configuration via browser
The destination host is located, as the other destination network
appliances, in a remote server out of the OpenStack cluster ⇒ more
realistic measurements
The Traffic Shaper has been implemented with the Linux Traffic
Control command suite, setting the bandwidth to 10 MBit/s
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19

33. 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 there
are 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, has
been done both at the source and destination through the installation
of a specific kernel and the configuration via browser
The destination host is located, as the other destination network
appliances, in a remote server out of the OpenStack cluster ⇒ more
realistic measurements
The Traffic Shaper has been implemented with the Linux Traffic
Control command suite, setting the bandwidth to 10 MBit/s
Every VM had an additional interface for all the traffic not related to
the test-bed (e.g. Internet traffic)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19

34. Dynamic Service Chaining in OpenStack L2 topology & VNI
Case study: L2 topology & VNI
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 15 / 19

35. 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
Throughput(Mbit/s)
Time (s)
DPI-in (p3)
WANA1-in (p4)
WANA1-out (p5)
TC-in (p6)
TC-out (p7)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 16 / 19

36. 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
Throughput(Mbit/s)
Time (s)
DPI-in (p3)
WANA1-in (p4)
WANA1-out (p5)
TC-in (p6)
TC-out (p7)
At the destination
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 16 / 19

37. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

38. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

39. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
More context awareness ⇒ we will use an orchestrator to install
more dinamically flows in the OVSs
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

40. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
More context awareness ⇒ we will use an orchestrator to install
more dinamically flows in the OVSs
Generalization of the case study, making the whole thing more
automatic
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

41. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
More context awareness ⇒ we will use an orchestrator to install
more dinamically flows in the OVSs
Generalization of the case study, making the whole thing more
automatic
Experiments with VMs live migration
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

42. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
More context awareness ⇒ we will use an orchestrator to install
more dinamically flows in the OVSs
Generalization of the case study, making the whole thing more
automatic
Experiments with VMs live migration
Cloud perfomances tests
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

43. Conclusions
What’s next?
Dynamic Service Chaining in a L3-like topology
Use of new OpenFlow controllers (OpenDayLight, Ryu) carrying new
OpenFlow versions
More context awareness ⇒ we will use an orchestrator to install
more dinamically flows in the OVSs
Generalization of the case study, making the whole thing more
automatic
Experiments with VMs live migration
Cloud perfomances tests
Application of Virtual Tenant Network: a way to create virtual
networks in a complete automated way, using REST API calls
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19

44. Conclusions
Questions?
Do you have any questions?
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 18 / 19

45. Conclusions
And that is all!
Thanks for your attention!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 19 / 19