Title Text. Making OpenStack Work in an Existing Environment - Challenges and Solutions. Amrish Kapoor, Pushkar Acharya, Ken Hui, Roopak Parikh

Transcription

1 Title Text Making OpenStack Work in an Existing Environment - Challenges and Solutions Amrish Kapoor, Pushkar Acharya, Ken Hui, Roopak Parikh

2 About Platform9 Founded 2013, San Francisco Bay Area Founded by early VMware Engineers Easy Button for the OpenStack OpenStack as a Service Growing.. we are hiring!! 2

3 Platform9 Overview Nova-api/ scheduler/ Glance- Api/ Registry KeyStone Other OpenStack Services Platform9 Services Platform9 Cloud PF9 Agent PF9 Appliance VMware vcenter ESX ESX ESX ESX ESX Linux (KVM) Hypervisor Customer Datacenter 3

4 Motivation Projects start small, organically grow Virtualization has been around IAAS cloud is still new DevOps practice is growing Remove Silos Strong customer feedback Contribute to OpenStack!! 4

5 HOW? 5

6 Existing asset types Per Host / cluster VM instances Networks Instance IPs, and the networks they attach to VM images / templates 6

7 VM Instances Instances Nova Conductor Periodically check for instances on the hypervisor New VM (Flavor = unknown, Image = unknown ) Report discovered instances to OpenStack as new instances VM Sync VM Info vcenter / KVM Apppropriate metadata - uuid, name, BDM etc. Instances on DB but not on hypervisor are deleted to maintain sync 7

8 Special tenant and user Discovery occurs at startup - before any users or tenants are created Create a pre-existing user and tenant ( service ) during deployment, under which discovery can be performed All instances are discovered as owned by this user Other users and tenants can be added later, as needed 8

9 Flavors and Quotas No good way of knowing the image or flavor Created an unknown image, and an unknown flavor VM can still be used as an otherwise regular OpenStack instance, along with most operations Quotas are still updated correctly - For e.g. BDM is calculated cumulatively 9

10 Networks New Network (Label = Network-<name> ) vcenter / KVM Network Info Nova Network Network Sync Networks Periodically check networks on hosts, and report them to novanetwork When a network is added in vcenter, it gets discovered and automatically added to OpenStack! 10

11 Instance IPs Instances Networks Instances are queried for their IP addresses, and their associated networks Nova Conductor IP Sync Nova Network periodically VM IP Info Reported to nova to update the instance info Allows using an external networking agent, like vcenter / KVM DHCP, to assign IP addresses to instances outside of OpenStack, and still have OpenStack recognize them 11

12 Template Images Template discovery queries for existing vcenter templates, and reports them to glance as new Images images Template Info Handle cases where VMs are converted to templates, and vice- Glance New Image Template Sync versa Nova augmented to handle cloning from a template image 12

13 Other Image Types Simplify using other existing image types - vmdk, qcow2 etc Designate a special folder to watch, and report any vmdk images found in it to Glance Any images copied to this folder are discovered instantly 13

14 Title Putting Text everything together Instances Nova Conductor IP Sync Nova Network Networks New VM (Flavor = unknown, Image = unknown ) VM IP Info New Network (Label = Network-<name> ) VM Sync VM Info vcenter / KVM Network Info N/w sync Images Glance New Image Template Sync Template Info Existing OpenStack Hypervisor Platform9 Addition

15 Putting everything together Dropped in place a new Platform9 deployment; authorized our existing data stores and clusters Once all the tasks kicked in, we had a fully functional OpenStack-based private cloud! Completely seamless - existing operations continued while this cloud and discovery was put in place Teams switch over to using the OpenStack API to perform their provisioning tasks now, instead of going directly to vcenter 15

16 16 Demo

17 Deployment - Integrated Integrate instance and network discovery into nova, as another set of periodic tasks Similarly integrate image discovery into Glance Advantage Can provide driver interfaces that each hypervisor can choose to implement Disadvantage Each component that needs discovery (nova, glance, networks) will need to implement this 17

18 Deployment - Separate Service Provide a new service for environment discovery that houses all discovery tasks Advantage Can add discovery independently of other OpenStack components Disadvantage Service needs to have modules for each component that needs discovery 18

19 Future Work Build network discovery into Neutron Build volume discovery into Cinder Contribute back to the community! 19

20 Summary OpenStack is a great solution to cloud-ify internal hypervisor infrastructure To enable drop-in and seamless transition, needs to play well with existing assets We made changes to discover and continually sync the hypervisor and OpenStack views of a set of assets Result - up and running with a fully OpenStackbased cloud in minutes!

21 Backup Slides

22 Team Founders Sirish Raghuram, CEO Madhura Maskasky, VP Product Roopak Parikh, VP Engineering Bich Le, Chief Architect Founded by early VMware engineers 100+ man years at VMware, built Workstation, ESXi, vsphere, vcloud Director Team ex VMware, Pivotal, Microsoft, Cisco, Stanford, UC Berkeley 22

23 Existing Infrastructure vsphere clusters used to house the following disparate setups Infra-related VMs - DHCP, Teamcity, OpenGrok Dev / Test workloads - Developer VMs, test suites, experimental components, trial & verification instances Sales & marketing workloads - Demo setups to use latest builds, demo sandbox environments Internal dogfooding environments - Continually setup, update, monitor and use internal Pf9-based setups 23

24 Problem Cannot reliably separate workloads into separate clusters, because load demands are not constant across all uses at all times Dev workloads hit a peak during prototyping phases, test workloads typically at the end of a release, sales & marketing workloads spike during events Need to use all of our computing capacity, and assign workloads flexibly across all of it without worrying about workload type, and periodic spikes - we need a private cloud! Need to also do this without disrupting ongoing work, i.e. as seamless as possible 24

25 Solution - OpenStack! Private cloud abstraction over hypervisors which addresses most of our questions Partition various user types into their own segments, assign access rights, quotas, and allow everyone to use the same API layer to access compute capacity This is great, but how do we get it to work with our existing assets, and not have to tear down everything and rebuild? 25