This presentation provides an overview of Apache CloudStack, an open source cloud computing platform. It discusses CloudStack's history and licensing, its ability to provide infrastructure as a service across multiple hypervisors, and how it enables multi-tenancy, high availability, scalability, and resource allocation. Key CloudStack components and concepts are also summarized, such as networking models, security groups, primary and secondary storage, usage tracking, and its management architecture.

1. David Nalley david@cloudstack.org
Twitter/identi.ca: @ke4qqq / IRC: ke4qqq in #cloudstack on freenode
BUILDING AN IAAS CLOUD WITH
APACHE 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 platform
that supports multiple hypervisors, complex
network, firewall, load balancer and VPN
configurations, 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

9. Networking
• Services managed by CloudStack
– DHCP
– VLAN allocation
– Firewall
– NAT/Port forwarding
– Routing
– VPN
– Load Balancing

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

28. UI
• Go play with the UI

29. Questions
• ASK!

30. Contact
• http://cloudstack.org
• Docs: http://docs.cloudstack.org
• IRC: #cloudstack on Freenode
• Twitter/identi.ca: @cloudstack
• Mailing Lists
– cloudstack-users@incubator.apache.org
– cloudstack-dev@incubator.apache.org
• Forums