1 / 28

Architecting Your Cloud: Lessons Learned from 100 CloudStack Deployments

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 Olivier.maes@citrix.com , twitter: @omaes72.

keelty
Télécharger la présentation

Architecting Your Cloud: Lessons Learned from 100 CloudStack Deployments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architecting Your Cloud: Lessons Learned from 100 CloudStack Deployments Speaker: Shannon Williams Vice President Market Development, Cloud Platforms EMEA contact: Olivier Maes SrDirMarket Development EMEA, Cloud Platforms Olivier.maes@citrix.com, twitter: @omaes72

  2. 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.

  3. 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.

  4. 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

  5. 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

  6. 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: Cloudstackhas proof: Foundations is the way to create a FOSS community http://openlife.cc/blogs/2012/july/cloudstack-has-proof-foundations-way-create-foss-community

  7. CitrixCloudStack WINDOWSON-DEMAND DEV & TEST DISASTER RECOVERY BRIDGE &GATEWAY BYOPLATFORM INFRA-STRUCTURE YOURSERVICE CloudPortal CloudPlatformPowered by Apache CloudStack NetScaler CloudBridge ESX Hyper-V XenServerKVM OVM VIRTUALIZATION Compute Network Storage

  8. CloudPortalDelivers Cloud Apps & the Business Logic Account Management Pricing & Billing Customer Relationship Self Service Cloud Apps Dashboard CloudPortal Plugins

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

  10. Architecture definition is a process IaaS Cloud

  11. Workload categories give us a starting point 11

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

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

  14. 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

  15. Other functionality will impact design as well

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

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

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

  19. Designing a zone for a traditional workload • Can achieve significant reliability for applications running in one zone. • 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 vCenter Enterprise Networking (e.g., VLAN) ESXi Cluster ESXi Cluster ESXi Cluster Enterprise Storage (e.g., SAN)

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

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

  22. 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 level failue • DBs and Templates snapped to object store. • In event of failure, images are recreated on new availability zone. • Dramatically less expensive Availability Zone Availability Zone Availability Zone Object Storage

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

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

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

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

  27. Key takeaways • Understand your workload and the type of cloud you want to build. • Consider the services you will be delivering from the cloud in the future. • Choose a platform and architecture that is flexible enough to support you today and in the future.

More Related