CloudStack has many moving parts, and although we will not get too far into the details of each piece, this will be a general overview of the different components of CloudStack. Some example deployments will be provided, how CloudStack interacts with Xen hosts and KVM hosts, as well as storage, networking, permissions, and usage accounting.

1. CloudStack In
Production
Considerations & Design

2. What CloudStack Is
● CloudStack is a cloud management platform (CMP)
○ Hypervisors
○ Layer 2 Network - VLANs / Security Groups / SDN
○ Layer 3 Network - Firewall / Router / VPN / Load Balancer
○ Storage - Primary / Secondary
● CloudStack can be managed
via API and/or a pretty Web GUI

3. What CloudStack Isn't
● CloudStack is not a drop-in replacement for tools such as Virt Manager,
XenCenter, and the vSphere Client

4. CloudStack Hierarchy
● Zone = Datacenter
○ Network mode (basic or advanced)
○ Secondary storage
● Pod = Rack
○ Logical grouping of clusters
● Cluster = Grouping of hosts
○ Shared primary storage
● Host = Server
○ Link-local interfaces (all but VMware)
● Instance = VM

5. Infrastructure Components
● Management Services (Web UI, API, Database)
● Hosts (Servers)
● Guests (VMs/Instances)
● Primary Storage
○ Where your VMs live
● Secondary Storage
○ Static content -- ISO Images, Snapshots, Templates, etc
● Network Components (switches, VLANs, etc)
○ Switches, VLANs, SDN, virtual routers, external
CloudStack managed devices such as Juniper SRX,
NetScaler, F5, etc

6. Primary Storage
● Your VMs run here
● Primary storage is expected to be fault-tolerant, reliable, and
performant
● Supported protocols/methods are:
○ Fibre Channel
○ iSCSI
○ CLVM
○ VMFS (VMware only)
○ NFS
○ SharedMountPoint (KVM only)
■ ShareMountPoint can be a cluster-aware filesystem such as
OCFS2 or GFS2
○ Ceph/RBD (KVM only -- very new, and very experimental)
○ Local storage
■ Note: you cannot live-migrate with local storage

7. Secondary Storage
● Only NFS is supported currently
● Does not need to be as fast or as reliable as primary
● Used to store:
○ Templates
○ Snapshots
○ ISO Images
○ Imported Volumes (temporarily)

8. How ACS Manages Hosts
● VMware
○ Licensed vCenter is required, individual ESXi hosts can
not be managed or accessed by CloudStack
● XenServer, XCP & Xen
○ XAPI is used to manage all Xen based hosts along with a
number of other scripts that CloudStack management will
deploy
● KVM
○ A combination of cloud-agent (the primary means), libvirt,
virsh, and server-side scripts
■ ** Note: Do not run mixed/matched clusters (e.g. Cent
and Ubuntu in the same cluster)

9. CloudStack Network Modes
● Basic Networking Zone
○ Assumes flat public network
○ Assigns public addresses to all instances
○ Uses security groups for guest isolation
○ Less complex configurations and networking
● Advanced Networking Zone
○ VLANs or SDN for guest segregation
○ RFC1918 addresses assigned to instances
○ Security groups not supported
○ VPC supported (virtual private cloud)
○ VPN available (site-to-site and L2TP/IPSec)
○ Inter-VLAN routing (tiered networks)
○ More complex configurations and networking

10. Host Networking
● Physical interfaces (NICs)
● Tagged interfaces (VLANs)
● Virtual NICs (vNIC on the guest) and their representation
on the virtual switch
● Security groups
○ Filtering using ebtables to apply iptables rules within a
bridge
● Bridges
○ Know them, love them

11. Accounts, Domains,
Projects, and Users
● Accounts own resources
○ For example: instances, volumes, templates, networks, etc
○ Two accounts, even on the same domain, cannot see each other's
resources
● Domains are logical containers for accounts
○ Domains can impose limits on accounts within them
● Users are tied to accounts and are used for authentication
○ Users can access CloudStack via the Web UI and/or API
● Projects own resources and can allow multiple accounts to control/share
them same resources
○ One account is delegated the "owner" of the project -- the owner can
add/remove other accounts to the project
○ All accounts must be children of the same domain

12. SDN - Software Defined
Networking
● When 4096 VLANs just aren't enough make millions of tunnels instead!
● GRE
○ Simple, universal, supported by Open vSwitch and others
○ GRE has overhead and doesn't correct for it, this can cause
problems with packets over 1500 bytes unless tcp adjust mss can
be enabled within the tunnel
○ Lightweight, easy to implement and understand
● STT
○ New, promising protocol but not widely implemented
○ No overhead issue
○ Uses TCP offload in NICs to process the tunnel to increase
performance

13. Questions/Discussion
Clayton Weise
clayton@claytonweise.com
Kelcey Jamison-Damage
me@kelceydamage.com
kelcey@bbits.ca

14. Thank You