Tim Mackey discusses key considerations for planning a successful private cloud. Private clouds offer control, speed, and future-proofing compared to public clouds. While server virtualization focused on consolidation and hardware independence, clouds are designed for massive scale, open architectures, and failure tolerance. Key features for successful clouds include multi-hypervisor support, availability zones, flexible networking, and tenant isolation without per-VM licensing. Lessons from companies like Zynga, telcos, and CloudStack emphasize clearly defining offerings, infrastructure choices optimized for workloads, and designing for maintainability and monitoring in cloud operations.
How to Troubleshoot Apps for the Modern Connected Worker
Planning a Successful Cloud - Design from Workload to Infrastructure
1. Planning a Successful Cloud
Design from Workload to Infrastructure
Tim Mackey
Citrix Cloud Evangelist
2. Private Cloud, Why Now?
• Valid alternative to public clouds that are cheap
and readily available
• Speed and agility of deployment
• Control of corporate assets
• Cloud Management Platform market maturity
• Future-proofing for nextgen, webscale workloads
“An IaaS cloud is a
highly automated
virtual infrastructure
that enables self-
service resource
requests, and
consumption of the
shared environment is
tracked for either
chargeback or
showback purposes.”
Forrester Research
100’s of pilots and few production deployments in 2011; expected to be 10 times more in 2012 - Gartner
4. Enterprise Objectives for Cloud
Remove IT as a service delivery critical pathSelf Service
Reduce IT operational costs
Management
Automation
Consistent application and service deployment
Workload
Standardization
Manage complete infrastructure, regardless of scale
Centralized
Management
Drive reduced capital requirements
Smarter
Virtualization
CapitalLeverageWorkforceLeverage
Visibility into user and line of business usageUsage Metering
5. Server Virtualization++ Cloud
Built for traditional enterprise apps and
client-server compute
• Architected for 100s of hosts
• Scale-up (server clusters)
• Applications assume reliability
• IT Management-centric [1:Dozens]
• Proprietary vendor stack
Think: vCloud Director
Designed around big data, massive scale and
next-gen applications
• Cloud architecture for 1000s of hosts
• Scale-out (multi-site server farms)
• Applications assume failure
• Autonomic [1:1,000’s]
• Open, value-added stack
Think: AWS, RAX, GCE, eBay, etc.
• More scalable
• Lower cost
• More open
6. Key Features for Successful Clouds
• Select the correct hypervisor to best match workload needs
• Seamlessly manage provisioning process across hypervisors
Multi-Hypervisor Support
• Provide optimal workload performance and availability
• Management of multiple availability zones from a single console
Availability Zones
• Define virtual and physical network isolation rules
• Support load balancing and VPN access rules
Flexible Network
Management
• Flexible user, network and provisioning isolation rules
• Ability to delegate tenancy for departments and divisions
Tenant Isolation
• Freedom to define capacity with no per-VM licensesNo per-VM Licensing
7. Server Virtualization++ Amazon-style Cloud
Availability
Zone
Availability
Zone
Object Storage
vCenter
vSphere
ESXi
Cluster
Enterprise Networking (e.g., VLAN)
Enterprise Storage (e.g., SAN)
ESXi
Cluster
ESXi
Cluster
CloudStack Management ServerServer Virtualization Availability Zone
Availability
Zone
ORAND
15. Along Comes Server Virtualization
• Multiple VMs/host
ᵒLoss of visibility
ᵒLoss of control
• Edge moves into host
ᵒNetwork admins need to understand
server virtualization
16. Example 1 – Mirroring Traffic
• Without virtualization this is pretty
easy
• With virtualization you now have
multiple VMs
17. Example 1 – Mirroring Traffic
• Without virtualization this is pretty
easy
• With virtualization you now have
multiple VMs
ᵒPlus VMs can move
• Better to monitor at virtual switch
18. Example 2 – Network Policies
• Server admins have significant impact
on the network
ᵒIP and MAC Address
ᵒVirtual NICs
ᵒProtocols and ports
• Granular network control requires
awareness of virtual machines
ᵒDefine policies at virtual switch
19. Network Management Tools Lag
• Assumptions of fixed topology
ᵒFine for physical
ᵒChallenge for dynamic environment
• Not virtualization aware
ᵒIncorrect topology
ᵒIncomplete topology
ᵒVM actions obsolete data
X
20. Virtual Machine Density Planning
• Host capacities are growing rapidly
ᵒvSphere 5 > 512 VMs
ᵒRHEV 3 > 1000 VMs
ᵒHyper-V > 2048 VMs
• Clouds and VDI push limits
• Top of rack switch selection matters?
ᵒARP table
ᵒSwitching performance drops
ᵒVM starts, but can’t connect
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Host 1
Host 2
VM
VM
VM
VM
VM
VM
VM
VM
VM
22. Shared storage growth and provisioning time
1,000
500
VMs
Cost,
AU
100 200
500
VMs
Provisioning efficiency
AU – arbitrary units
23. Combined efficiency and storage evolution
Redesign
1,000
500
VMs
100 200 Cost, AU
VMs
1,000
500
Cost, AU100 200
?
Alternatives
AU – arbitrary units
24. Redesign
Efficiency and pod storage
1,000
500
VMs
100 200 Cost, AU
POD #1
POD #2
POD #3
1,000
500
VMs
100 200 Cost, AU
AU – arbitrary units
No redesign
25. What about local storage?
1,000
500
VMs
Cost, AU100 200
50
VMs
Provisioning efficiency
AU – arbitrary units
31. Cloud Builder Lessons from Zynga
• Public clouds are minivans
• zCloud is a race car
ᵒzCloud is optimized for social gaming
ᵒKnow your application requirements
• Don’t rent what you can own cheaper
ᵒCloud operator doesn’t care about your success
ᵒOptimized applications might be key
• Ensure you have backup plans
ᵒUsage can and does spike
ᵒOutages can and do happen
vs.
32. Cloud Builder Lessons From Telcos
• Utility computing fits business model
ᵒTraditionally operate a low margin business model
ᵒUnderstand tiered service offerings
ᵒHave a history with instant provisioning
• Tiered service demands infrastructure flexibility
ᵒ“Cost per instance” is paramount
ᵒCharge extra for premium features
ᵒInstance doesn’t imply virtualization
ᵒBe prepared to change vendors if better model appears
• Provisioning agility expected
ᵒCustomers expect instant self service access and detailed billing
33. Service Offerings
• Clearly define what you want to offer
ᵒWhat types of applications
ᵒWho has access, and who owns them
ᵒWhat type of access
• Define how templates need to be managed
ᵒOperating system support
ᵒPatching requirements
• Define expectations around compliance and availability
ᵒWho owns backup and monitoring
34. Define Tenancy Requirements
• Department data local to department
ᵒWhere is the application data stored
• Data and service isolation
ᵒVM migration and host HA
ᵒNetwork services
• Encryption of PII/PCI
ᵒWhere do keys live when data location unknown
ᵒNeed encryption designed for the cloud
• Showback to stakeholders
ᵒMore than just usage, compliance and audits
35. Virtualization Infrastructure
• Hypervisor defined by service offerings
ᵒDon’t select hypervisor based on “standards”
ᵒUnderstand true costs of virtualization
ᵒMultiple hypervisors are “OK”
ᵒBare metal can be a hypervisor
• To “Pool” resources or not
ᵒIs there a real requirement for pooled resources
ᵒCan the cloud management solution do better?
ᵒReal cost of shared storage
• Primary storage defined by hypervisor
• Template storage defined by solution
ᵒTypically low cost options like NFS
36. Cloud Operations
• Design for maintainability
• Monitor critical components
ᵒManagement servers and system support VMs
ᵒHypervisor hosts, and critical infrastructure
ᵒEnd user deployment environments
If your cloud has maintenance windows, you’re doing it wrong.
- Allan Leinwand Former CTO Zynga
37. Secure multi-tenant cloud orchestration platform
• Turn-key platform for IaaS delivery
• Hypervisor agnostic
• Massively scalable, secure and open
• Simple deployment and administration
History
• Project open sourced (GPLv3) May 2010
• Acquired by Citrix July 2011
• Relicensed under ASL v2 April 3rd, 2012
• Apache incubating project April 16, 2012
• Graduated March 20, 2013
Over 200 contributing organizations
