Deep inside the Cloud Managements Platforms: the OpenStack case study
?
1 like?345 views
Seminar given at VEM Sistemi, Forl¨¬ in July 2015. Based on the understanding of cloud computing and, in particular, of the platform OpenStack.
Deep inside the Cloud Managements Platforms: the OpenStack case study
- 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 o?ered 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 o?ered 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 o?ered 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 o?ered 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 o?ered 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, ?rewalls, etc) in a simple and e?cient 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 speci?c 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 speci?c 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 de?nes 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 de?nes 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 de?nes 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 tra?c 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 tra?c 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 tra?c 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 di?erent 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 di?erent bridges One of the main issue in OpenStack, as every other cloud management platform, is to divide di?erent users¡¯ tra?c For every network there is a VLAN internal ID ? the veth pair port attached to the integration bridge is access for a speci?c 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 di?erent bridges One of the main issue in OpenStack, as every other cloud management platform, is to divide di?erent users¡¯ tra?c For every network there is a VLAN internal ID ? the veth pair port attached to the integration bridge is access for a speci?c 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 con?gured 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 di?erent bridges One of the main issue in OpenStack, as every other cloud management platform, is to divide di?erent users¡¯ tra?c For every network there is a VLAN internal ID ? the veth pair port attached to the integration bridge is access for a speci?c 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 con?gured It is also important to implement a set of ?rewall rules for every VM ? Security Groups They are implemented by Neutron applying the native kernel ?ltering 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 di?erences All virtual network appliances as well as users are implemented as VMs, con?gured 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 di?erences All virtual network appliances as well as users are implemented as VMs, con?gured for the case study The implementation of a real WAN Accelerator, Tra?csqueezer, has been done both at the source and destination through the installation of a speci?c kernel and the con?guration 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 di?erences All virtual network appliances as well as users are implemented as VMs, con?gured for the case study The implementation of a real WAN Accelerator, Tra?csqueezer, has been done both at the source and destination through the installation of a speci?c kernel and the con?guration 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 di?erences All virtual network appliances as well as users are implemented as VMs, con?gured for the case study The implementation of a real WAN Accelerator, Tra?csqueezer, has been done both at the source and destination through the installation of a speci?c kernel and the con?guration 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 Tra?c Shaper has been implemented with the Linux Tra?c 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 di?erences All virtual network appliances as well as users are implemented as VMs, con?gured for the case study The implementation of a real WAN Accelerator, Tra?csqueezer, has been done both at the source and destination through the installation of a speci?c kernel and the con?guration 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 Tra?c Shaper has been implemented with the Linux Tra?c Control command suite, setting the bandwidth to 10 MBit/s Every VM had an additional interface for all the tra?c not related to the test-bed (e.g. Internet tra?c) 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 ?ows 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 ?ows 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 ?ows 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 ?ows 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 ?ows 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