Transcript Tim Mackey - Home - Virtualization Group

Leveraging Cloud
Architectures in the
Enterprise
Tim Mackey
Citrix Systems Cloud Evangelist
Capital Leverage
Workforce Leverage
Enterprise Objectives for Cloud
Self Service
Management
Automation
Remove IT as a service delivery critical path
Reduce IT operational costs
Workload
Standardization
Consistent application and service deployment
Usage Metering
Visibility into user and line of business usage
Centralized
Management
Manage complete infrastructure, regardless of scale
Smarter
Virtualization
Drive reduced capital requirements
Server Virtualization++
Cloud
•
•
•
More scalable
Lower cost
More open
Built for traditional enterprise apps
and client-server compute
Designed around big data, massive
scale and next-gen applications
•
•
•
•
•
•
•
•
•
•
Architected for 100s of hosts
Scale-up (server clusters)
Applications assume reliability
IT Management-centric [1:Dozens]
Proprietary vendor stack
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: vCloud Director
Think: AWS, RAX, zCloud, eBay, etc.
Enterprises should, and will,
become more cloud-like…
…but adoption of new cloud
architecture is the future
Key Features for Successful Clouds
Multi-Hypervisor Support
• Select the correct hypervisor to best match workload needs
• Seamlessly manage provisioning process across hypervisors
Availability Zones
• Provide optimal workload performance and availability
• Management of multiple availability zones from a single console
Flexible Network
Management
• Define virtual and physical network isolation rules
• Support load balancing and VPN access rules
Tenant Isolation
• Flexible user, network and provisioning isolation rules
• Ability to delegate tenancy for departments and divisions
No per-VM Licensing
• Freedom to define capacity with no per-VM licenses
A Cloud Role Model: AWS
Amazon Web Services Architecture
• Availability Zone
◦ Location engineered for failure isolation
◦ Contains compute, network and storage
• Region
◦ Geographically dispersed data centers
◦ Contains one or more Zones
• Instance
◦ Predefined compute element with template
◦ Local storage destroyed with instance
• Elastic Design
◦ Predictable costing model
◦ On demand provisioning
Availability and Implementation Assumptions
• No zone uptime guarantee
◦ SLA: Region has uptime of 99.95% in last year
• Customer owns application
◦ Infrastructure is Amazon’s problem
• Zone implementation hidden
◦ Compute unit based  “early-2006 1.7Ghz Xeon”
◦ Hypervisor is heavily customized Xen
◦ Network details fully abstracted
• Instance configuration pre-defined
◦ Supports custom templates within instance type
US West
(California)
US East
(Virginia)
Enterprise Applications and AWS
• Instance location is unknown
◦ Which host is running the instance?
◦ Are multiple nodes on the same host?
• Storage and Network are unknown
◦ Performance optimizations limited
◦ IO control limited
• Compliance
◦ Limited capability to audit and monitor
◦ No visibility into network segmentation
◦ Security groups a proven model
VM
VM
VM
VM
VM
Cloud Builder Lessons from Amazon
• Customizing the hypervisor made sense …. In 2006
◦ Hypervisor is a commodity. Go with proven solution for best supportability
• Infrastructure should be abstracted, but core architecture needs to make sense
◦ Design with the expectation that a core component may need to be replaced
• Traditional packaged enterprise applications not designed for agility
◦ Assume outages, not availability
◦ Assume stateless, not statefull
◦ Assume dynamic scale, not static capacity planning
• IaaS model do work, but you need to plan for them
◦ Start with new projects, don’t try and migrate as the first cut
Learning from Amazon
Case Study: Zynga
• Online gaming studio based in CA
◦ Believes internet should be for fun
◦ FarmVille reached 25 million daily users in 5 months
• Started with traditional colo model
◦ Couldn't scale fast enough and outgrew data center
◦ No agility, and agility is key for games
• Leverages Amazon AWS
◦ Low cost development platform
◦ Provides fixed cost services during rollout
• zCloud is internal private cloud
◦ Looks and feels like AWS, only more control
◦ Favorable cost model at game scale
Anatomy of zCloud
• Agility is the core requirement
• zCloud tuned for the needs of Zynga
◦ In memory databases
◦ Single digit latency between nodes
◦ Very quick provisioning
◦ AWS Large Instance  zCloud host
• Can provision 1000 hosts in < 24 hours
◦ Key solution elements: CloudStack, RightScale and XenServer
• Jan 2011 80% of workloads in AWS
• Jan 2012 80% in zCloud
Manage What You Own
• Profile applications in AWS, then move in house
◦ Built game monitoring tools
◦ Games are the assets
• “All-In” monitoring of external infrastructure
◦ Service providers show 4-5 9s, but users say different
◦ Redundant providers at each level
◦ Direct fiber to multiple AWS regions
◦ Implemented data replication
◦ Fully automated provisioning at each level
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.
Case Study: Korea Telecom uCloud
• South Korean telecom giant
◦ Largest landline, and second largest mobile provider
• uCloud provides Enterprise and Consumer Services
◦ Compute, Storage, Backup and virtual desktop services
• Core requirements were performance and agility
• Delivers services for 40% less than AWS
Case Study: TATA InstaCompute
• Largest Indian telco, and provider of global
IT services
• InstaCompute designed for DevOps and IT
outsourcing
• Pilot to production in under 9 months
• Delivers compute costs 50% below AWS
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
Designing Your Enterprise Cloud
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
Enterprise 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
Virtualization Infrastructure
• Hypervisor defined by service offerings
◦ Don’t select hypervisor based on “standards”
◦ Understand true costs of virtualization
◦ Multiple hypervisors are “OK”
• 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
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.
Candidate Cloud Deployment Model
Zone 1
Load Balancer
Firewall
• A Host is the basic unit of scale.
• A Cluster groups compatible hosts
L3 switch
Pod 1
Pod N
L2 switch
….
Cluster N
….
Host 2
Secondary
Storage
• A Pod is one or more clusters, usually with a
L2 switch. Typically a pod is a rack.
• Zones contain one or more pods, and have
access to secondary storage for templates
• Firewall and Load balancers separate public
and private networks
Cluster 1
Host 1
• All hosts in a cluster have access to shared
(primary) storage
Primary
Storage
Cloud Architectures are the Key to Success
Worlds largest public cloud environment
Delivering video on demand via the cloud
Uses the cloud to sell more pigs
Transformed their hosting business with the cloud
Uses the cloud to disrupt the way we communicate
Built one of the fastest growing and most innovative
companies on the planet