Architecting Your Cloud: Lessons Learned from 100 CloudStack Deployments Speaker: Shannon Williams Vice President Market Development, Cloud Platforms EMEA contact: Olivier Maes Sr Dir Market Development EMEA, Cloud Platforms [email protected], twitter: @omaes72 Cloud computing in 10 years • Computing clouds will have standardized • Servers/Storage/Networking will be commodities available on demand. • Applications will be designed to leverage distributed computing resources • Key questions won’t have changed ᵒ ᵒ ᵒ ᵒ Application Performance Application Reliability Infrastructure Security/Compliance Operational Costs Goal: Deliver applications quicker with more reliably at a fraction of the current cost. Cloud computing today • Start-ups and Web Companies are achieving the 10-year vision today ᵒ Standardizing on big public clouds (Amazon, Softlayer, BT, Terremark, etc.) ᵒ Designing applications that can leverage distributed availability zones for reliability • Enterprises are generally not leveraging cloud computing ᵒ Most apps aren’t written for distribution ᵒ Security/Compliance concerns over leveraging shared resources ᵒ Proven mechanism for delivering apps remains standard. Goal: Provide improved access for developers and operators. 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 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 Since becoming part of Apache CS has exploded “It's just amazing! In just 3 months, CloudStack has gone directly to the same level as OpenStack is. This is much steeper community growth than I could have predicted (if anyone had asked me for predictions, that is...). Source: Cloudstack has proof: Foundations is the way to create a FOSS community http://openlife.cc/blogs/2012/july/cloudstack-hasproof-foundations-way-create-foss-community WINDOWS ON-DEMAND DEV & TEST DISASTER RECOVERY BRIDGE & GATEWAY BYO PLATFORM INFRASTRUCTURE YOUR SERVICE CloudPortal NetScaler CloudPlatform CloudBridge Powered by Apache CloudStack ESX Hyper-V XenServer KVM OVM VIRTUALIZATION Compute Network Storage CloudPortal Delivers Cloud Apps & the Business Logic Account Management Pricing & Billing Self Service Cloud Apps Customer Relationship Dashboard Authentication Account S elf Service Product Definition Sales CRM Usage Reporting Account Provisioning Delegated Account Management Catalog Management Ticketing / HelpDesk Messaging Customer Management Usage Tracking Community Forums Alerts Account Management Cloud Management User Roles Portal Administration Billing Flexible and Extensible SDK Service Status Service Status Payment Processing CloudPortal Plugins Content Management Customer Relationship Billing Authentication Liferay Salesforce.com Zuora CAS (LDAP/AD) Drupal Each cloud drives unique requirements Service Providers 9 Web 2.0 Enterprise 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 Workload categories give us a starting point Traditional Enterprise Applications Disaster Recovery Software Development, Testing and Maintenance Social Media Applications Managed IT Services Batch processing 11 High Performance Computing Possible to categorize workloads into two sets Cloud Workloads Traditional Workload Reliable hardware, backup entire cloud, and restore for users when failure happens Cloud Workload Tell users to expect failure. Users to build apps that can withstand infrastructure failure Both types of workloads must run reliably in the cloud RPO (Recovery Point Objective) Reliability & DR are Workload Specific $ $$ 2 • Recovery Point Objective (RPO) and 1 Regular Recovery Time Objective (RTO) should be determined based on workloads • Deployment and DR plan should be designed per RPO, RTO requirements $$ 3 Critical Mission Critical RTO (Recover Time Objective) • Different types of workloads will achieve workload reliability in different ways 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. Admin controlled failure handling Think Server Virtualization 1.0 Expect failure. Design app for failure. Self-service failure handling Think Amazon Web Services Other functionality will impact design as well VM Features • Resizing • High Availabity • Cloning • Monitoring • Windows Support • Linux Support • Naming • Grouping • Security Networking Features Storage Features Template Management Management Features • Dedicated user networks • Integrated Firewall • Integrated Load Balancing • IP Address Management • Multiple Guest Networks • VPN Termination • Intrusion Prevention • Persistent Storage • Ephemeral Disk • Automated Disk Snapshots • Cloud Storage access • Disk Monitoring • Encryption • Master Template Library • User Template upload • User ISO upload • Blank VM creation • Private templates • Template migration • Delegated Administration • Live Migration of VMs • Live Migration of Storage • Usage Metering • User Interface • Console Access • MultiHypervisor • Open-Source • MultiDatacenter Every cloud starts with basic building blocks Servers Storage Networking Networking Server Clusters Server Clusters Server Clusters Storage Hypervisor Resources Availability Zones Clouds Two sample zone architectures - Traditional server virtualization zone Amazon-Style availability zone Designing a zone for a traditional workload Hypervisor Feature Rich– vSphere, vCenter vCenter Storage Enterprise Networking (e.g., VLAN) ESXi Cluster ESXi Cluster ESXi Cluster Enterprise Storage (e.g., SAN) SAN Networking L2 VLANs Network Services Load Balancing PV-LANs Multi-tier Apps Multi-tier VLANs OVF Designing a zone for a traditional workload • Can achieve significant reliability for applications running in one zone. vCenter Enterprise Networking (e.g., VLAN) ESXi Cluster ESXi Cluster ESXi Cluster Enterprise Storage (e.g., SAN) • Reliability of individual nodes is very high. • All zone storage is replicated to a second storage platform (synchronous or asynchronous) • In event of failure, images are recovered from second storage array. • Existing workloads will run reliably. • Little cost benefit over existing approaches Designing a zone for an Amazon-style workload Amazon-Style Availability Zone Software Defined Networks (e.g., Security Groups, EIP, ELB,...) Server Racks Server Racks Server Racks Server Racks Hypervisor Simple - XenServer Storage Local Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks SDN based L2 Elastic IP Network Services Security Groups Elastic Block Storage Object store Networking L3 Server Racks EBS ELB GSLB Multi-tier Apps L3 SDN based VPC CloudFormation Object store is critical for Amazon-style cloud Amazon-Style Cloud Amazon-Style Availability Zone CloudStack Mgmt. Server Availability Zone Availability Zone Object Storage Software Defined Networks (e.g., Security Groups, EIP, ELB,...) Availability Zone Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Server Racks Elastic Block Storage 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 Availability Zone Availability Zone Object Storage Availability Zone • Applications designed to handle node level failue • DBs and Templates snapped to object store. • In event of failure, images are recreated on new availability zone. • Dramatically less expensive Cloud Transition – General to Workload specific Past General Architecture • General architecture for any workload • Limited definitive failure/disaster recovery strategy • Focused on legacy or cloud app architectures Today Traditional-Style Amazon-Style • Workload-centric architecture • Workload-specific failure/disaster recovery • Separate legacy and cloud app architectures with interoperability Support for different styles is required CloudStack Mgmt. Server Server Virtualization Availability Zone vCenter Enterprise Networking (e.g., VLAN) Availability Zone Availability Zone Availability Zone ESXi Cluster Object Storage ESXi Cluster ESXi Cluster Enterprise Storage (e.g., SAN) Availability zones will be distributed globally CloudStack Management Cluster San Jose London Hosted Dehli Miami Hosted Rio Tokyo Availability zones are becoming on-demand Hosted On Premise Private Cloud Managed Private Cloud Enterprise Data Center Hosted Private Cloud Enterprise Data Center Dedicated resource Total control/security Internal network Multi-tenant Users Enterprise Public Cloud Services Multi-tenant Users 3rd party hosted & operated 3rd party operated • • • Federated/Hybrid Cloud Services • • • • 3rd party owned and operated SLA bound Security Dedicated resource • • • Mix of shared and dedicated resources Shared facility and staff VPN access • • • • Shared resources Elastic scaling Pay as you go Public internet Key takeaways 1. Understand your workload and the type of cloud you want to build. 2. Consider the services you will be delivering from the cloud in the future. 3. Choose a platform and architecture that is flexible enough to support you today and in the future. Work better. Live better.