420 likes | 528 Views
Hypervisor Selection in CloudStack 4.3 and OpenStack Havana. Understanding the choices available. virtg Deep Dive Day 2014. Tim Mackey – XenServer Community Manager and Evangelist. Building a successful cloud. What are we trying to accomplish?. Service Offerings.
E N D
Hypervisor Selection in CloudStack 4.3 and OpenStack Havana Understanding the choices available virtg Deep Dive Day 2014 Tim Mackey – XenServer Community Manager and Evangelist
Building a successful cloud What are we trying to accomplish?
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
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
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? • Real cost of shared storage • Primary storage defined by hypervisor • Template storage defined by solution • Typically low cost options like NFS
Apache CloudStack • Current release: 4.2.1 (4.3 imminent) • Highly scalable • Monolithic architecture • Mostly written in Java • Multi-hypervisor support • XenServer, KVM, OracleVM, vSphere, Linux Containers, Bare metal • 4.3 adds: Hyper-V • Strong backing from Citrix, CloudOps, Shapeblueand others Management Server Load Balancer Management Server Replication Management Server Infrastructure Resources Back Up DB MySQL DB
OpenStack • Current release: Havana • Scalable in 500 node blocks • Distributed architecture • Mostly written in Python • Multi-hypervisor support • Group A: KVM • Group B: Hyper-V, vSphere, XenServer • Group C: All others deprecated in Icehouse • Strong backing from HP, IBM, RAX, RHT, Canonical, Mirantis, Piston Cloud, Cloudscaling
Flat Network – Basic Layer 3 Network Public Network 65.11.0.0/16 Security Group 1 65.11.1.2 Guest VM 1 Guest VM 2 65.11.1.3 65.11.1.4 Guest VM 3 65.11.1.5 Guest VM 4 CloudStack Virtual Router DHCP, DNS Security Group 2
VLANs for Private Cloud Guest Virtual Network 10.0.0.0/8 VLAN 100 Public Network/Internet Guest VM 1 10.1.1.1 Gateway 10.1.1.1 Public IP 65.37.14.1 CloudStack Virtual Router Guest VM 2 10.1.1.3 DHCP, DNS NAT Load Balancing VPN Guest VM 3 10.1.1.4 Guest VM 4 10.1.1.5
Virtual Private Cloud and nTier Applications DC2 DC3 VLAN 1 DC1 DC4 Web S2S VPN Router VLAN 2 App Private GW DC5 VLAN 3 DC6 DB
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
Instances need a home … Storage, Storage and more Storage
Primary Storage Options Cluster Host Host Primary Storage
Secondary Storage Options Zone Pod Cluster Host Host Primary Storage Requires NFS staging area Can be region wide, but must not have NFS secondary storage in zone SecondaryStorage
Core virtualization capabilities The limits and features which matter
Multiple Hypervisor Support in CloudStack • 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
Defining the network The goodness of Neutron (Quantum)
Flat Network – Basic Layer 3 Network Public Network 65.11.0.0/16 Security Group 1 65.11.1.2 Guest VM 1 Guest VM 2 65.11.1.3 65.11.1.4 Guest VM 3 65.11.1.5 Guest VM 4 CloudStack Virtual Router DHCP, DNS Security Group 2
VLANs for Private Cloud Guest Virtual Network 10.0.0.0/8 VLAN 100 Public Network/Internet Guest VM 1 10.1.1.1 Gateway 10.1.1.1 Public IP 65.37.14.1 CloudStack Virtual Router Guest VM 2 10.1.1.3 DHCP, DNS NAT Load Balancing VPN Guest VM 3 10.1.1.4 Guest VM 4 10.1.1.5
Instances need a home … Storage, Storage and more Storage
Multiple Hypervisor Support in OpenStack • Capabilities • Multiple hypervisor support varies by distro • Most deployments are single hypervisor • Difficult to schedule instances to compute nodes • Use host aggregates • Networking • Topology is intersect of chosen hypervisors – ML2 helps • Operations • HA won’t migrate between hypervisors • Capacity planning at the cluster/pod level more difficult • Hyper-V does not work with all Neutron plugins
Picking the “best one” When to use which hypervisor…
KVM • Primary value proposition: • Low cost with available vendor support • Familiar administration model • Broad feature set with active development in both CloudStack and OpenStack • Cloud use cases: • Linux centric workloads • Dev/test clouds • Web hosting • Tenant density which dictates SDN options • Weaknesses: • CloudStack: Requires use of an installed libvirt agent • Limited native storage options • No use of advanced native features
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 • CloudStack: First introduced with CloudStack 4.3 (not yet released)
vSphere • Primary value proposition: • Broad application and operating system support • Readily available pool of vSphere administration talent • Large eco-system of vendor partners • CloudStack: Many 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 • CloudStack: Single data center per zone model
XenServer • Primary value proposition: • Low cost with available vendor support • Broad feature set with active development in both CloudStack and OpenStack • CloudStack: Large 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
Tying it all Together • Define success criteria • Select a topology which works • Decide on storage options • Define supported configurations • Select preferred hypervisor(s) • Validate matrix • Build your Cloud