1. David Nalley email@example.comTwitter/identi.ca: @ke4qqq / IRC: ke4qqq in #cloudstack on freenodeBUILDING AN IAAS CLOUD WITHAPACHE CLOUDSTACK
2. Licensing• This presentation and it’s contents unless otherwise noted are released under a Creative Commons Attributions, Share-Alike 3.0 unported license and Apache Software License v2 at your discretion.
3. History• Original company formed - 2008 (VMOps)• Project open sourced (GPLv3) as CloudStack – May 2010• Acquired by Citrix – July 2011• Dropped open core – August 2011• Relicensed under ASL v2 April 3, 2012• Accepted as a Apache incubating project. April 16, 2012
4. What is CloudStack?Open Source Infrastructure as a Service platformthat supports multiple hypervisors, complexnetwork, firewall, load balancer and VPNconfigurations, high availability, in a multi-tenant environment.
5. What does it really do?• Provide separation for the varied tenants• Allocate compute resources in a deterministic manner• Expose to the end user the ability to provision various computing services in a controlled manner (VLAN allocation, firewall rules, load balancer deployment, VM creation, etc)• Manage High Availability• Massively Scalable• Permit the placement of resource limits to be applied• Measuring usage over time
6. Multiple hypervisor support• KVM• XenServer• Xen Cloud Platform• VMware (via vCenter)• Oracle VM• Bare Metal
7. Multi-tenant Separation• Largely built around abstraction from an end-user POV – No interaction with hypervisor directly – No knowledge of underlying storage• Networking separation – Every account has at least one dedicated/isolated VLAN (Tagged Networking) – Layer 3 isolation aka Security Groups for untagged networking• Option to use dedicated hardware
8. Networking• CloudStack has a number of network models• They are generally broken down by: – Method of isolation (VLAN, Security Groups) – Physical hardware or virtual• CloudStack can manage network infrastructure
10. Networking• CloudStack can also manage physical network hardware (or the virtualized alternatives) – F5-Big IP – NetScaler – Juniper SRX• Additionally you can ‘mix and match’ some network elements as service offerings.
11. Security Groups• Traditional isolation has been via VLAN• VLANs isolate well, but have some problems scaling – Standard has a hard limit of 4096 VLANs – Hardware that can actually keep up with 4096 VLANs is VERY expensive. – Regardless people tend to not like having arbitrary limits on what they can do.• Amazon and others use layer 3 isolation (Security Groups)
12. Security Groups• Assumption of a quasi-trusted Layer 2 network• Typically will only have hypervisors directly connected to that network.• Filtering/isolation occurs at the bridge device (from a Linux perspective – think ebtables)• Deny by default
13. Security Groups
14. Security Groups
15. High Availability• RFMTTR – but apparently HA looks better in marketing slicks and is used that way across the virtualization industry.• CloudStack is not a magical solution for HA – but might be a useful tool in the process to increase availability.• CloudStack will watch for HA-enabled VMs to ensure that they are up, and that the hypervisor it’s on is up – and will restart on another hypervisor if it goes down.• Redundant router
16. Allocation Algorithms• How do you place VMs?, allocate storage, etc.• CloudStack ships with a number of options: – First Fit – Fill first – Disperse – Create your own• Tags• OS Preference
17. Usage• Not billing per se – but does give you something to bill against.• Usage stats show VM count, CPU usage, disk allocation and usage, network usage; all over time.• Lots of integration and howto’s - from Excel spreadsheets to Ubersmith, Amysta, and Cloud Portal.
18. High level Architectural Overview © Copyright David Baird and licensed for reuse under CC-BY license
19. Secondary Storage• Used for storing templates and snapshots• Historically NFS – just added the option of object storage – Technically Swift, but Caringo, GlusterFS and others should work.• Managed by Secondary Storage VM – manages moving templates and snapshots from/to primary storage, aging snapshots out, etc.
20. Primary Storage• In the UI we support NFS, iSCSI, and CLVM.• We can also make use of local storage – No HA, no live migration, etc.• Shared mountpoint – Anything that all the hypervisors can mount and write to.
21. Resource division• We have somewhat arbitrary divisions of resources within CloudStack – Zones • Pods – Clusters
22. Zone• In general practice this is used to designate a specific geographic location.• Shares secondary storage resource across the entire zone• Single network model for the entire zone
23. Pod• In general practice – this is used to refer a rack of machines or a row of racks.• Shares guest network
24. Cluster• This is typically a max of 8-15 machines per cluster and homogenity is enforced: – Same hypervisor (and same version of the hypervisor) – Same CPUs – Same networking (i.e. /dev/eth0 is connected to the same network across all machines)• Primary storage is cluster specific
25. Plethora of Networks• Management Network: Where the hypervisors and management server communicate• Private Network: Default network for system VMs. (virtual router, secondary storage VM, Console proxy VM)• Public Network: The public (often internet-facing network)• Guest Network: The network that VMs are provisioned on.• Link-local network: The RFC 3927 network used for communication between hypervisor and system VMs.
26. Management Server• UI/API pieces are stateless (state is stored in a MySQL database.• All UI functionality is an API call
27. API• RESTful API interface – Unauthenticated API interace on 8096 (for localhost, disabled by default) – Authenticated API interface natively on port 8080 – Responses in XML or JSON – http://demo4.cloudstack.org/client/api?apikey=ZRFLi XIkmAHqgRmZzdiXMfaROyK35P_dXxS517WSa9Tmy1H g&command=deployVirtualMachine&serviceofferingi d=1&templateid=291&zoneid=1&signature=eXW%2fxf qx%2fhu%2frMreFksVsp3cT4M%3d