Presentation from 2012 CloudExpo on Lessons Learned from more than 100 CloudStack deployments.

1. Architecting Your Cloud: Lessons Learned
from 100 CloudStack Deployments
Shannon Williams
Vice President Market Development, Cloud Platforms
CloudExpo New York
June 13, 2012

2. Today’s goal: provide a basic understanding of
different cloud architectures
• Outline a process for defining a cloud
• Describe the building blocks used to
deploy a computing cloud
• Look at traditional workloads and cloud
workloads
• Consider architectures that meet a
broad set of requirements

3. Since 2008 CloudStack has powered hundreds
of clouds
• Secure, multi-tenant cloud
orchestration platform
– Turnkey platform for delivering IaaS clouds
– Hypervisor agnostic
– Highly scalable, secure and open
– Complete Self-service portal
– Open source, open standards
– Deploys on premise or as a hosted solution

4. Each cloud drives unique requirements
Service Providers Web 2.0 Enterprise
4

5. Architecture definition is a process
Iaas Cloud
Define target workloads
Determine how that workload will be delivered reliably
Determine the necessary functionality and performance
Develop your technical architecture
Implement your environment

6. Workload categories give us a starting point
Traditional
Enterprise
Applications
Software
Disaster Development,
Recovery Testing and
Maintenance
Social Media Managed IT
Applications Services
High Performance
Batch processing
Computing
6

7. Possible to categorize workloads into two sets
Cloud Workloads
Traditional Workload Cloud Workload
Reliable hardware, backup entire Tell users to expect failure.
cloud, and restore for users when Users to build apps that can
failure happens withstand infrastructure failure
Both types of workloads must run reliably in the cloud

8. Reliability & DR are Workload Specific
RPO (Recovery Point Objective)
• Recovery Point Objective (RPO) and
$ 1 Recovery Time Objective (RTO) should be
determined based on workloads
$$ Regular
2 • Deployment and DR plan should be
designed per RPO, RTO requirements
$$ 3 Critical • Different types of workloads will achieve
workload reliability in different ways
Mission
Critical
RTO (Recover Time Objective)

9. Workload reliability drives unique requirements
Traditional Workload Cloud Workload
Link Aggregation VM Backup/Snapshots
Storage Multi-pathing Ephemeral Resources
VM HA, Fault Tolerance Chaos Monkey
VM Live Migration Multi-site Redundancy
Expect reliability. Back-up entire cloud. Expect failure. Design app for failure.
Admin controlled failure handling Self-service failure handling
Think Server Virtualization 1.0 Think Amazon Web Services

10. Other functionality will impact design as well
Networking Storage Template Management
VM Features
Features Features Management Features
• Resizing • Dedicated user • Persistent • Master • Delegated
• High Availabity networks Storage Template Administration
• Cloning • Integrated • Ephemeral Library • Live Migration
• Monitoring Firewall Disk • User Template of VMs
• Integrated • Automated upload • Live Migration
• Windows
Support Load Balancing Disk Snapshots • User ISO of Storage
• IP Address • Cloud Storage upload • Usage
• Linux Support
Management access • Blank VM Metering
• Naming
• Multiple Guest • Disk creation • User Interface
• Grouping
Networks Monitoring • Private • Console Access
• Security templates
• VPN • Encryption • Multi-
Termination • Template Hypervisor
• Intrusion migration • Open-Source
Prevention • Multi-
Datacenter

11. Every cloud starts with basic building blocks
Servers Networking
Storage Server Server Server
Clusters Clusters Clusters
Networking
Storage
Hypervisor
Resources Availability Zones Clouds

12. Two sample zone architectures
- Traditional server virtualization zone
- Amazon-Style availability zone

13. Designing a zone for a traditional workload
Hypervisor
Feature Rich– vSphere, vCenter
vCenter
Storage
Enterprise Networking (e.g., VLAN)
SAN
ESXi ESXi ESXi Networking
Cluster Cluster Cluster L2 VLANs
Network Services
Enterprise Storage (e.g., SAN)
Load Balancing PV-LANs
Multi-tier Apps
Multi-tier VLANs OVF

14. Designing a zone for a traditional workload
• Can achieve significant reliability for
vCenter
applications running in one zone.
Enterprise Networking (e.g., VLAN) • Reliability of individual nodes is very high.
• All zone storage is replicated to a second
ESXi
Cluster
ESXi
Cluster
ESXi
Cluster
storage platform (synchronous or
asynchronous)
Enterprise Storage (e.g., SAN) • In event of failure, images are recovered
from second storage array.
• Existing workloads will run reliably.
• Little cost benefit over existing approaches

15. Designing a zone for an Amazon-style workload
Amazon-Style Availability Zone
Software Defined Networks Hypervisor
(e.g., Security Groups, EIP, ELB,...) Simple - XenServer
Server Server Server Server Storage
Racks Racks Racks Racks
Local EBS Object store
Server Server Server Server
Networking
Racks Racks Racks Racks
L3 SDN based L2 Elastic IP
Server Server Server Server
Network Services
Racks Racks Racks Racks
Security Groups ELB GSLB
Elastic Block Storage Multi-tier Apps
L3 SDN based VPC CloudFormation

16. Object store is critical for Amazon-style cloud
Amazon-Style Cloud
Amazon-Style Availability Zone
CloudStack
Mgmt. Server Software Defined Networks
(e.g., Security Groups, EIP, ELB,...)
Server Server Server Server
Racks Racks Racks Racks
Server Server Server Server
Availability Availability Availability
Racks Racks Racks Racks
Zone Zone Zone
Server Server Server Server
Racks Racks Racks Racks
Object Storage Elastic Block Storage

17. Object store is critical for Amazon-style cloud
Amazon-Style Cloud
CloudStack
Mgmt. Server • Workloads are distributed across
availability zones
• No guarantee on zone reliability
• Applications designed to handle node
Availability Availability Availability level failue
Zone Zone Zone
• DBs and Templates snapped to
object store.
• In event of failure, images are
Object Storage recreated on new availability zone.
• Dramatically less expensive

18. Cloud Transition – General to Workload specific
Past Today
General
Traditional-Style Amazon-Style
Architecture
• General architecture for any
• Workload-centric architecture
workload
• Workload-specific failure/disaster
• Limited definitive failure/disaster
recovery
recovery strategy
• Separate legacy and cloud app
• Focused on legacy or cloud app
architectures with interoperability
architectures

19. Support for different styles will be required
CloudStack
Mgmt. Server Server Virtualization Availability Zone
vCenter
Enterprise Networking (e.g., VLAN)
Availability Availability Availability
Zone Zone Zone
ESXi ESXi ESXi
Cluster Cluster Cluster
Object Storage Enterprise Storage (e.g., SAN)

20. Availability zones will be distributed globally
CloudStack Management Cluster
San Jose London
Miami Hosted Dehli Tokyo
Hosted Rio

21. Availability zones are becoming on-demand
On Premise Hosted
Private Cloud Managed Hosted Private Cloud Federated/Hybrid Public
Private Cloud Cloud Services Cloud Services
Enterprise Enterprise Enterprise Multi-tenant Users Multi-tenant Users
Data Center Data Center
3rd party 3rd party hosted &
operated operated
• Dedicated resource • 3rd party owned and • Mix of shared and • Shared resources
• Total control/security operated dedicated resources • Elastic scaling
• Internal network • SLA bound • Shared facility and • Pay as you go
• Security staff • Public internet
• Dedicated resource • VPN access

22. Key takeaways
• Begin with the definition of the workloads your users will run on the cloud.
• Define a clear strategy for what level of reliability those workloads will require,
and how you will deliver it.
• Understand failure scenarios, DR scenarios, monitoring and backup deeply.
• Don’t be afraid to support more than one workload category, it will be key to
driving consumption.
• Open platforms will provide the most flexibility to support a wide variety of
workloads.
• Hypervisor, Networking and Storage models are more important than specific
vendor choices

23. Work better. Live better.