Decisions behind hypervisor selection in CloudStack 4.3
1 like3,298 views
As presented at the 2014 CloudStack Collaboration Conference in Denver (CCCNA14), this deck covers the matrix of functions and features within each supported hypervisor in CloudStack 4.3. This deck forms an excellent reference document for those seeking to provide multi-hypervisor support within their Apache CloudStack based cloud, and for those seeking to determine which feature elements are supported by a given hypervisor.
More Related Content
What's hot (20)
Viewers also liked (10)
Similar to Decisions behind hypervisor selection in CloudStack 4.3 (20)
More from Tim Mackey (14)
Recently uploaded (20)
Decisions behind hypervisor selection in CloudStack 4.3
- 1. Decisions Behind Hypervisor Selection in CloudStack 4.3
- 2. whoami • Name: Tim Mackey • Current roles: XenServer Community Manager and Evangelist; occasional coder • Cool things I’ve done – Designed laser communication systems – Early designer of retail self-checkout machines – Embedded special relativity algorithms into industrial control system • Find me – Twitter: @XenServerArmy – SlideShare: slideshare.net/TimMackey
- 3. What are we trying to accomplish?
- 4. Service Offerings • Clearly define what you want to offer – What types of applications – Who has access, and who owns them – What type of access • Define how templates need to be managed – Operating system support – Patching requirements • Define expectations around compliance and availability – Who owns backup and monitoring
- 5. Define Tenancy Requirements • Department data local to department – Where is the application data stored • Data and service isolation – VM migration and host HA – Network services • Encryption of PII/PCI – Where do keys live when data location unknown – Need encryption designed for the cloud • Showback to stakeholders – More than just usage, compliance and audits
- 6. Virtualization Infrastructure • Hypervisor defined by service offerings – Don’t select hypervisor based on “standards” – Understand true costs of virtualization – Multiple hypervisors are “OK” – Bare metal can be a hypervisor • To “Pool” resources or not – Is there a real requirement for pooled resources – Can the cloud management solution do better? • Primary storage defined by hypervisor • Template storage defined by solution – Typically low cost options like NFS
- 7. Defining the network …
- 8. Flat Network – Basic Layer 3 Network Option XenServer vSphere KVM LXC Hyper-V Security Groups Yes- bridge No Yes Yes Yes IPv6 No No Yes Yes No Multiple IPs per NIC Yes Yes Yes Yes Yes Nicira NVP Yes No Yes No No BigSwitch VNS Yes No Yes No No 65.11.1.2 65.11.1.3 65.11.1.4 65.11.1.5 Public Network 65.11.0.0/16 Guest VM 1 Guest VM 2 Guest VM 3 Guest VM 4 DHCP, DNS CloudStack Virtual Router Security Group 1 Security Group 2
- 9. VLANs for Private Cloud Option XenServe r vSphere KVM LXC Hyper-V Max VLANs 800 254 1024 1024 4094 IPv6 No No Yes Yes No Multiple IPs per NIC Yes Yes Yes Yes Yes Nicira NVP Yes No Yes No No BigSwitch VNS Yes No Yes No No MidoKura No No Yes No No VPC Yes Yes Yes No Yes NetScaler Yes Yes Yes No Yes F5 BigIP Yes Yes Yes No Yes Juniper SRX No Yes Yes No Yes Cisco VNMC No Yes No No No 10.1.1. 1 10.1.1. 3 10.1.1. 4 10.1.1. 5 Public Network/Internet Guest Virtual Network 10.0.0.0/8 VLAN 100 DHCP, DNS NAT Load Balancing VPN Public IP 65.37.14.1 Gateway 10.1.1.1 Guest VM 1 Guest VM 2 Guest VM 3 Guest VM 4 CloudStack Virtual Router
- 10. Beyond the VLAN – Network Virtualization Option XenServer vSphere KVM LXC Hyper-V OVS GRE tunnels Yes No No No No Nicira STT tunnel Yes Yes Yes No No MidoNet No No Yes No No VXLAN No Yes Yes No No NVGRE No No No No No Nexus 1000v No Yes No No No Juniper Contrail Yes No No No No Palo Alto Yes Yes Yes No No
- 11. Virtual Private Cloud and nTier Applications Feature XenServer vSphere KVM LXC Hyper- V PVLAN Yes - ovs Yes ovs No No Web App DB Router DC1 DC2 DC3 DC4 DC5 DC6 VLAN 1 VLAN 2 VLAN 3 S2S VPN Private GW
- 12. Delivering specific network services • KVM – IPv6 – Security groups – Large quantity of VLANs • vSphere – VXLAN required vSphere Enterprise Plus – Cisco Nexus 1000v and ASA 1000v require vSphere Enterprise Plus • XenServer – Security groups – Large quantity of VLANs – Juniper Contrail
- 13. Instances need a home …
- 14. Primary Storage Options Feature XenServer vSphere KVM LXC Hyper-V Local storage Yes Yes Yes Yes Yes NFS Yes Yes Yes Yes No SMB No No No No SMB3 Single path iSCSI Yes Yes Yes No No Multipath iSCSI PreSetup No No No No Direct array No VAAI No No No Shared Mount No No Yes Yes No Template format VHD OVA QCOW2 TAR VHD SolidFire Plugin Yes Yes Yes No No NetApp Plugin Yes Yes Yes No No Zone wide No Yes Yes No No Ceph RBD No No Yes No No Clustered LVM No No Yes No No Cluster Host Host Primary Storage
- 15. Secondary Storage Options Option XenServer vSphere KVM LXC Hyper-V NFS Yes Yes Yes Yes No Swift(1) Yes Yes Yes Yes No S3 compatible (2) Yes Yes Yes Yes No SMB No No No No Yes (1) Requires NFS staging area (2) Can be region wide, but must not have NFS secondary storage in zone Zone Secondary Storage Pod Cluster Host Host Primary Storage
- 16. Core limits and features that matter
- 17. CloudStack Features Feature XenServer vSphere KVM LXC Hyper-V Disk IO Statistics Yes No Yes No Yes Memory Overcommit Yes (4x) Yes No No No Dedicated resources Yes Not with HA/DRS Yes No Yes Disk IO throttling No No Yes Yes No Disk snapshot (running) Yes Yes No No No Disk snapshot (pluggable) Partial Partial No No No Disk snapshot (Stopped) Yes Yes Yes No Yes Memory snapshot Yes Yes Yes No No Zone wide primary storage No Yes Yes Yes No Resize disk Offline Online Grow Online No No High availability CloudStack Native CloudStack No CloudStack CPU sockets 6.2 and higher Yes Yes Host count Yes Affinity groups Yes Yes Yes No Yes
- 18. XenServer 6.2 Feature Source code model Open Source (GPLv2) Maximum VM Density 650 (Linux) CloudStack VM Density 500 CloudStack integration Direct XAPI calls Maximum native cluster size 16 Maximum pRAM 1 TB Largest VM 16vCPU/128GB Windows Operating System All Windows supported by Microsoft Linux Operating Systems RHEL, CentOS, Debian, Ubuntu, SLES, OEL Advanced features supported ovs, Storage XenMotion, DMC
- 19. vSphere 5.5 Feature Source code model Proprietary Maximum VM Density 512 CloudStack VM Density 128 CloudStack integration vCenter Maximum native cluster size 32 Maximum pRAM 4 TB Largest VM 64 vCPU/1TB Windows Operating Systems DOS, All Windows Server/Client Linux Operating Systems Most Advanced features supported HA, DRS, vDS, Storage vMotion
- 20. KVM (RHEL/CentOS 6.5 and Ubuntu 12.04) Feature Source code model Open Source (GPLv2) Maximum VM Density 10 times the number of pCores CloudStack VM Density 50 CloudStack integration CloudStack Agent (libvirt) Maximum native cluster size No native cluster support Maximum pRAM 2 TB Largest VM 160 vCPU/2TB Windows Operating Systems Windows XP and higher Linux Operating Systems Varies Advanced features supported None
- 21. Linux Containers Feature Source code model Open Source (GPLv2) Maximum container Density 6000 (theoretical) CloudStack container Density 50 CloudStack integration CloudStack Agent (libvirt), requires KVM for SVMs Maximum native cluster size N/A Maximum pRAM 2 TB Largest container 2TB Windows Operating Systems N/A Linux Operating Systems Kernel compatible distros
- 22. Microsoft Hyper-V Feature Source code model Proprietary Maximum VM Density 1024 CloudStack VM Density 1024 CloudStack integration CloudStack Agent (C# calling WMI) Maximum native cluster Size 64 Maximum pRAM 4 TB Largest VM 64 vCPU/1TB Windows Operating Systems All Windows supported by Microsoft Linux Operating Systems RHEL, CentOS, Debian, Ubuntu, SLES, OEL Advanced features supported None
- 23. Picking the “Best One”
- 24. KVM • Primary value proposition: – Low cost with available vendor support – Familiar administration model – Broad CloudStack feature set with active development • Cloud use cases: – Linux centric workloads – Dev/test clouds – Web hosting – Tenant density which dictates SDN options • Weaknesses: – Requires use of an installed CloudStack libvirt agent – Limited native storage options – No use of advanced native features
- 25. Linux Containers • Primary value proposition: – Low cost with available vendor support – Familiar administration model • Cloud use cases: – Dev/test clouds – Web application hosting • Weaknesses: – Requires use of an installed CloudStack libvirt agent – Requires KVM for system VMs – No use of advanced native features – First introduced in CloudStack 4.2
- 26. Microsoft Hyper-V • Primary value proposition: – Unlimited Windows Server VM licenses – Familiar Windows management paradigm • Cloud use cases: – Windows and Linux workloads – Dev/test clouds – .Net application web hosting – Desktop as a Service clouds • Weaknesses: – Minimal use of advanced native features – First introduced with CloudStack 4.3
- 27. vSphere • Primary value proposition: – Broad application and operating system support – Readily available pool of vSphere administration talent – Large eco-system of vendor partners – Many CloudStack features are native implementations – Direct feature integration via vCenter • Cloud use cases: – Private enterprise clouds – Dev/test clouds • Weaknesses: – vSphere up-front license and ongoing support costs – vCenter integration requires redundant designs – Single data center per zone model
- 28. XenServer • Primary value proposition: – Low cost with available vendor support – Broad CloudStack feature set with active development – Large CloudStack install base – Direct integration via XAPI toolstack • Cloud use cases: – Linux centric workloads – Dev/test clouds – Web hosting – Desktop as a Service clouds – Large VM density and secure tenant isolation • Weaknesses: – Minimal use of advanced native features
- 29. What About Multiple Hypervisor Support? • Networking – Ensure network labels match – Topology is intersect of chosen hypervisors • Storage – For system VMs to specific hypervisor type – Zone with primary storage limited • Operations – vSphere Datacenter can not span zones – Hyper-V may not be mixed with other hypervisors – HA won’t migrate between hypervisors – Capacity planning at the cluster/pod level more difficult
- 30. Tying it all Together 1. Define success criteria 2. Select a topology which works 3. Decide on storage options 4. Define supported configurations 5. Select preferred hypervisor(s) 6. Validate matrix 7. Build your Cloud