CloudStack is an open source cloud computing platform that allows for provisioning of computing resources in a controlled multi-tenant environment. It supports multiple hypervisors and provides separation, networking, security groups, high availability, and usage tracking. CloudStack manages the allocation of resources through zones, pods, clusters, and provides an API and UI interface.

1. C LO U D STAC K
Clayton Weise cweise@iswest.net
IRC: iswcin #cloudstack on freenode

2. LICENSING
 This presentation and it’s contents unless otherwise
noted are released under a Creative Commons
Attributions, Share-Alike 3.0 unported license.

3. H I STO RY
 Original company formed - 2008 (VMOps)
 Project open sourced as CloudStack – May 2010
 Acquired by Citrix – July 2011
 Dropped open core – August 2011
 Release of Acton (3.0) – Real soon now

4. W H AT I S C LO U D STAC K ?
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. W H AT D O ES I T R EA L LY D O ?
 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. M U LT I P L E H Y P E RV I S O R S U P P O RT
 KVM
 XenServer
 Xen Cloud Platform
 VMware (via vCenter)
 Oracle VM
 Bare Metal

7. M U LT I - T E N A N T S E PA R AT I O N
 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. N E T WO R K I N G
 CloudStack has a number of network models
 They are generally broken down by:
 Method of isolation (VLAN, Security Groups)
 Physical hardware or virtual
 CloudStack largely manages network infrastructure

9. N E T WO R K I N G
 Services managed by CloudStack
 DHCP
 VLAN allocation
 Firewall
 NAT/Port forwarding
 Routing
 VPN
 Load Balancing

10. N E T WO R K I N G
 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. S EC U R I T Y G RO U P S
 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. S EC U R I T Y G RO U P S
 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. S EC U R I T Y G RO U P S

14. S EC U R I T Y G RO U P S

15. H I G H AVA I L A B I L I T Y
 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. A L LO C AT I O N A LG O R I T H M S
 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. U SAG E
 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. H I G H L E V E L A RC H I T EC T U R A L OV E RV I E W
© Copyright David Baird and licensed for reuse under this CC-BY

19. S ECO N DA RY STO R AG E
 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. P R I M A RY STO R AG E
 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. R ES O U RC E D I V I S I O N
 We have some somewhat arbitrary divisions of resources
within CloudStack
 Zones
• Pods
– Clusters

22. ZO N E
 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. C LU ST E R
 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. P L E T H O R A O F N E T WO R KS
 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. M A N AG E M E N T S E RV E R
 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)
 Authenticated API interface natively on port 8080
 Responses in XML or JSON
 http://demo4.cloudstack.org/client/api?apikey=ZRFLiXIkm
AHqgRmZzdiXMfaROyK35P_dXxS517WSa9Tmy1Hg&comm
and=deployVirtualMachine&serviceofferingid=1&template
id=291&zoneid=1&signature=eXW%2fxfqx%2fhu%2frMreF
ksVsp3cT4M%3d

28. UI
 Go play with the UI

29. Q U EST I O N S
 ASK!

30. CO N TAC T
 http://cloudstack.org
 Docs: https://cwiki.apache.org/CLOUDSTACK
 IRC: #cloudstack on Freenode
 Twitter/identi.ca: @cloudstack
 Mailing Lists
 https://lists.sourceforge.net/mailman/listinfo/cloudstack-users
 https://lists.sourceforge.net/mailman/listinfo/cloudstack-devel
 Forums