deep inside the cloud managements platforms: the openstack case study
TRANSCRIPT
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 2 / 19
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. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19
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. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19
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. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 3 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 4 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 4 / 19
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. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 5 / 19
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. . .
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 5 / 19
The OpenStack case Components and structure
Web Dashboard
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 6 / 19
The OpenStack case Components and structure
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19
The OpenStack case Components and structure
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19
The OpenStack case Components and structure
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 7 / 19
The OpenStack case Components and structure
Cluster, in detail
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 8 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 9 / 19
The OpenStack case Deep inside
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!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19
The OpenStack case Deep inside
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!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19
The OpenStack case Deep inside
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!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 10 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 11 / 19
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 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
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 11 / 19
The OpenStack case Virtual Network Infrastructure
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19
The OpenStack case Virtual Network Infrastructure
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19
The OpenStack case Virtual Network Infrastructure
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19
The OpenStack case Virtual Network Infrastructure
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 12 / 19
The OpenStack case Virtual Network Infrastructure
Inside the nodes
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 13 / 19
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19
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 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
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19
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 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
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19
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 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
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19
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 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
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)
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 14 / 19
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
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 16 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 16 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
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
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 17 / 19
Conclusions
Questions?
Do you have any questions?
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 18 / 19
Conclusions
And that is all!
Thanks for your attention!
Research Fellow: Francesco Foresta (DEI) Deep inside OpenStack platform Jul 17, 2015 19 / 19