More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to Managing Multi-hypervisor OpenStack Cloud with Single Virtual Network
Similar to Managing Multi-hypervisor OpenStack Cloud with Single Virtual Network (20)
More from PLUMgrid
More from PLUMgrid (17)
Recently uploaded
Recently uploaded (20)
Managing Multi-hypervisor OpenStack Cloud with Single Virtual Network
- 1. Managing Multi-hypervisor OpenStack Cloud with Single Virtual Network Dhiraj Sehgal
- 2. Introduction Speaker Photo Dhiraj Sehgal Product and Solution Marketing PLUMgrid PLUMgrid delivers SDN and NFV solutions for OpenStack Clouds
- 3. Transition Cycles for New Workloads Networking enables transition of Apps from Traditional Workloads to Cloud Hyper-v ESX -TraditionalXen KVM - Cloud
- 4. SDxCentral Survey: Multi-hypervisor Deployment in Cloud Source: https://www.sdxcentral.com/wp-content/uploads/2015/10/SDxCentral-SDx-Cloud-Management-RPRT_A.pdf
- 5. Business Drivers for Multi-Hypervisor Environment App Workload Optimization In-house Hypervisor Deployment Knowledge Multi-year Licensing Agreements
- 6. SDxCentral Survey: Most popular cloud management
- 7. SDxCentral Survey: Major Cloud Problem Source: https://www.sdxcentral.com/wp-content/uploads/2015/10/SDxCentral-SDx-Cloud-Management-RPRT_A.pdf
- 8. OpenStack Multi-hypervisor Example https://www.openstack.org/enterprise/virtualization-integration/ API INTERACTIONS Compute Compute Proprietary Virtual Network Switch Proprietary or Open Virtual Network Switch ESXi KVM PROPRIETARY STORAGE MULTIPLE STORAGE SOLUTIONS PROPRIETARY NETWORK PHYSICAL NETWORK BACK-END ORCHESTRATION OpenStack Control Plane open CLOUDPROPRIETARY CLOUD PaaS Automation Policy or Template Driven Orchestration Web GUI Custom Automation INTERNET
- 9. OpenStack Multi-hypervisor Single SDN API INTERACTIONS Compute Compute ESXi KVM PROPRIETARY STORAGE MULTIPLE STORAGE SOLUTIONS PROPRIETARY NETWORK PHYSICAL NETWORK BACK-END ORCHESTRATION OpenStack Control Plane PaaS Automation Policy or Template Driven Orchestration Web GUI Custom Automation INTERNET open CLOUD PLUMgrid ONS
- 10. PLUMgrid ONS Overview PHYSICAL NETWORK INFRASTRUCTURE VIRTUAL DOMAIN Tenant A Bridge Router LB Security Policies Bridge Security Policies Bridge DHCP FW VIRTUAL DOMAIN Tenant B Secure Architecture Non-Stop Forwarding Distributed Data Plane 3rd PARTY VNF LIBRARY PLUMGRID NETWORK LIBRARY
- 11. What are we demo’ing Connectivity between KVM and ESXi workloads across single tenant Using OpenStack Heat Templates Standard Neutron APIs based Setup Overview Commercial OpenStack Distro installed 3 Controller / 1 Compute (ESXi) / 1 Compute (KVM) 1 PLUMgrid Gateway VMware vCenter
- 12. ORCHESTRATION WITH OPENSTACK HEAT TEMPLATE DEMO
- 13. Demo Topology Virtual Domain • PG VMagent • VMware OpenStack Driver Internet PLUMgrid Directors PLUMgrid Gateway PLUMgrid LCM VMWare vCenter VIRTUAL INFRASTRUCTURE VIEW PHYSICAL INFRASTRUCTURE VIEW Compute Node/PLUMgrid Edges VxLAN Powered by
- 15. OpenStack Multi-hypervisor Example API INTERACTIONS Compute Compute ESXi KVM PROPRIETARY STORAGE MULTIPLE STORAGE SOLUTIONS PROPRIETARY NETWORK PHYSICAL NETWORK BACK-END ORCHESTRATION OpenStack Control Plane PaaS Automation Policy or Template Driven Orchestration Web GUI Custom Automation INTERNET open CLOUD PLUMgrid ONS
- 16. PHYSICAL INFRASTRUCTURE VIRTUAL INFRASTRUCTURE Deployment Case Study Internet PLUMgrid Edge / OpenStack Compute Nodes Directors Gateway PLUMgrid LCM Vmware vCenter Powered by Virtual Domain A Virtual Domain B Tenant A Tenant B Security Policies PLUMGRID NETWORK LIBRARY
- 17. Summary: SDN in OpenStack Multi-hypervisor Environment Micro-segmentation: OpenStack with ESXi and KVM Security Policies: Out of Box Automation: Create and Replicate with Heat Templates Optimize Existing Hypervisor Investments
- 18. Come by PLUMgrid’s Booth T#69 See Demos Listen to OpenStack Distro Sessions Awnix, Canonical, Mirantis, Rackspace, Pick SDN Networking Book Check-out User Testimonials Schedule On-site Consulting Pick up gifts & get a postcard Win an Apple Watch! Sign-up for Sandbox DIY on www.plumgrid.com
- 20. PLUMgrid ONS PHYSICAL INFRASTRUCTURE VIRTUAL INFRASTRUCTURE Virtual Compute Compute Virtual Storage CRM VDI ERP IaaSSaaS PaaS Virtual Networks Self Service Portal/Catalog Cloud Management Platform StorageNetwork
Editor's Notes
- We have deployed more than 70 OpenStack Clouds. PLUMgrid ONS is foundational SDN block for OpenStack clouds in Software as a Service, Financial, Service Providers and Retail/ecommerce verticals Few major reasons have been: Multi-tenant micro-segmentation Distributed data plane leveraging IO Visor Comprehensive networking services and management tools
- As everyone ramps-up their cloud applications, builds OpenStack cloud for it, they still want to leverage their traditional ESXi workloads/VMs in OpenStack environment with minimal disruption as they invest moving forward into KVM/Containers/etc. You can also add to this statement that new workloads will leverage containers/bare metal/ any other new technologies and righfully it should be done that way. Enterprise IT/ DevOps have asked us during discussions as their IT adopts cloud, how to leverage their old ESXi workloads in OpenStack…There are few reasons behind it. I’ll share it with audience in next few slides. One of the problems or barriers to accelerate the cloud adoption based on OpenStack in datacenter is networking. Hardware networking has been difficult for virtualized world, SDN hasnt yet made life easier. To support this let me show you next slide
- This slide is a recent survey from SDxCentral where they went to different enterprises and asked about their major clouds. One of the question in survey points to multi-hypervisor deployments in cloud. You can see that the access to and utilization of ESXi traditional workloads is an integral part of cloud strategy conversation irrespective of cloud management platforms such as OpenStack. Most of the time we see that people have to use multi-hypervisors because their applications run different sub-components (Web servers, app servers, database, analytics, etc) in different hypervisor. Next slide I’ll discuss why they believe that ESXi existing workloads are still relevant for their cloud strategy until they completely move their workloads to newer hypervisors. They still want to keep access to their legacy ESXi workloads even if they use newer cloud management platforms. Why Vmware ESXi? 3 reasons.
- As we discussed these 3 reasons, App workload optimization: Single app may leverage ESXi for one part of it and KVM for another. In-house hypervisor – Over years people have knowledge bases, they have optimized these workflows, most probably have productivity gains with the work they done above and beyond just using ESXi and they want to leverage it. Last point is most important, because as they see the benefits of clouds as they saw benefits of virtualizationin early 2000s, they don’t want a lock in with properitary cloud management platform. Hence, they want cloud management platofmrs (which is compute, networking, storage) which doesn’t create lock down.
- As you can see overwhelming people want to use OpenStack and are using OpenStack and rest also want to adopt OpenStack Further majority doesn’t want multi-cloud management, so as OpenStack extends it lead, it has to remove the objections as shown in next slide.
- Top problem in same survey for cloud management platforms is networking. For OpenStack to increase its adoption in datacenter it has to make sure that any problems from networking is not #1 cloud problem for ESXi workloads while working with KVM workloads. And we know how it works in OpenStack and with multi-hypervisor it is amplified to a whole new level. Networking is 5x bigger than next cloud problem. I remember ease of management was pretty high few years back for OpenStack and thanks to community and distro providers like Rackspace, Mirantis, Canonical, Red Hat, Suse that has been largely solved.. Going to back Networking is most critical part of successful part of cloud strategy. DevOps/Solution Architects/IT Strategist everyone has said that if they can connect their traditional ESXi workloads to KVM based workloads for same application in a single networking domain within a single cloud management platform such as OpenStack, it’ll help them move very fast. We need to get networking %age to ease of management level or less.
- This is picture from OpenStack guide for multi-hypervisor from openstack website. Let me walk you through it. Properiatary stack for ESXi. Most probably ESXi/NSX/VSAN…. Almost a vendor lock-in. On the other side you have OpenStack (KVM/SDN options like PG) and storage... For enterprise, this essentially creates 2 clouds which require double effort for same result. This is as designed but OpenStack still helps you with control plane Also, if you have templates for orchestration you have go through hoops to do it differently for Properitary cloud and open cloud. Key Reason you have to do all this is because you some workloads running ESXi and you cannot just throw them away. With PG we have made network easier in OpenStack for such environment, so that next survey of Cloud Management doesnt show networking at 76%.
- Common software defined networking layer which connects both ESXi and KVM VMs running under single OpenStack Control Plane.. Benefits: You need to focus on single type of networking for both stacks, build knowledge bases around one networking and keep your cost lower.
- Software defined networking. No hardware dependencies. We run distributed in same compute nodes of your openstack cloud. The value of PLUMgrid resides in that we render THE FULL NETWORK inside the compute node, vs rendering only a switch or router. This means all network functions (bridge-router-security-NAT-etc.) locally in the compute node, so that the traffic does not have to leave the compute node to be serviced at L3-L7. With other solutions, the compute nodes create a distributed switch (+router in the case of DVR), but anything else needs to be done outside. All VNFs are library of network functions in ONS and as you build your networks with them as per your application requirements, you use virtual domains. A Virtual Domain is a secure logical data center. A Virtual Domain provides complete administrative control to its users to create new networks, change configurations and add new networking services on-demand, without affecting other Virtual Domains or the physical network. Each Virtual Domain contains within it a full featured logical data center that can be provisioned, operated, migrated, cloned and restored by a click of a button or programmatically through the management API. Each Virtual Domain belongs to a tenant or a project. One tenant can have multiple Virtual Domains, however each Virtual Domain is owned by a single tenant. There are two examples I use to illustrate this: 1.- The way datacenters used to be designed 10 years ago: Core-Aggregation-Access layers, with all L4-7 services in the Core. That worked fine with North-south traffic: it'd flow from the internet to the DC, go across the core layer, be serviced by FWs and LBs, the flow down to the servers in Access. This proved to be awfully wrong as soon as virtualization kicked in and East-West traffic (between VMs) amounted tobe 80%+ of the traffic in a DC, which is where it is now. In that case, it does not make sense for the traffic to go access-core-access-core-access-core every time that a L4-7 function needs to be applied between layers. Well, OVS is exactly that: a L2 network between compute nodes and a centralized "core layer" in the network node running L4-7 service. Horrible traffic spaguettis. Terrible single point of failure. Awful scalability. Mammoth server that eventually will fail, vs. nimble distributed services on every compute node. Neutron has been trying to "patch" a wrong design based on distributed L2 and centralized L4-7 since it started. This is likely the main reason for its lack of scalability. Solutions like ours are the fix for this. We do distributed NETWORKS!!!! We are to networks what KVM is to compute. IOvisor is a NETWORK HYPERVISOR.
- Timestamps: REMOVE 48 second (Login Screen of Vmware need to removed)
- Add IP address to VMs in Physical and Virtual Topology OpenStack Controller running as LXC containers.
- To summarize we showed you that with single networking domain based on ONS, you can connect your ESXi workloads with KVM workloads in OpenStack cloud and it can be automated process with Heat Templates.
- ADD OS DISTRO INDEPENDENCE For smoother transition , SDN should provide these 4 bullets Vmware Q3 Earnings Quote: We're seeing a wide variety of use cases in the three broad categories of IT automation, micro-segmentation and application continuity.