Planning a Successful Cloud - Design from Workload to Infrastructure

690 views

Published on

Planning a Successful Cloud - Design from Workload to Infrastructure by Tim Mackey, Citrix Cloud Evangelist

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
690
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Planning a Successful Cloud - Design from Workload to Infrastructure

  1. 1. Planning a Successful CloudDesign from Workload to InfrastructureTim MackeyCitrix Cloud Evangelist
  2. 2. Private Cloud, Why Now?• Valid alternative to public clouds that are cheapand 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 ahighly automatedvirtual infrastructurethat enables self-service resourcerequests, andconsumption of theshared environment istracked for eitherchargeback orshowback purposes.”Forrester Research100’s of pilots and few production deployments in 2011; expected to be 10 times more in 2012 - Gartner
  3. 3. 150+Large Scale CloudsIn DeploymentEnterprise and EducationWeb 2.0Service Providers and Telcos
  4. 4. Enterprise Objectives for CloudRemove IT as a service delivery critical pathSelf ServiceReduce IT operational costsManagementAutomationConsistent application and service deploymentWorkloadStandardizationManage complete infrastructure, regardless of scaleCentralizedManagementDrive reduced capital requirementsSmarterVirtualizationCapitalLeverageWorkforceLeverageVisibility into user and line of business usageUsage Metering
  5. 5. Server Virtualization++ CloudBuilt for traditional enterprise apps andclient-server compute• Architected for 100s of hosts• Scale-up (server clusters)• Applications assume reliability• IT Management-centric [1:Dozens]• Proprietary vendor stackThink: vCloud DirectorDesigned around big data, massive scale andnext-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 stackThink: AWS, RAX, GCE, eBay, etc.• More scalable• Lower cost• More open
  6. 6. Key Features for Successful Clouds• Select the correct hypervisor to best match workload needs• Seamlessly manage provisioning process across hypervisorsMulti-Hypervisor Support• Provide optimal workload performance and availability• Management of multiple availability zones from a single consoleAvailability Zones• Define virtual and physical network isolation rules• Support load balancing and VPN access rulesFlexible NetworkManagement• Flexible user, network and provisioning isolation rules• Ability to delegate tenancy for departments and divisionsTenant Isolation• Freedom to define capacity with no per-VM licensesNo per-VM Licensing
  7. 7. Server Virtualization++ Amazon-style CloudAvailabilityZoneAvailabilityZoneObject StoragevCentervSphereESXiClusterEnterprise Networking (e.g., VLAN)Enterprise Storage (e.g., SAN)ESXiClusterESXiClusterCloudStack Management ServerServer Virtualization Availability ZoneAvailabilityZoneORAND
  8. 8. Best practices aren’t always
  9. 9. Density in the cloud
  10. 10. Traditional Server Virtualization• Core ObjectivesᵒServer consolidationᵒPower and cooling savingsᵒHardware independence• Looks LikeᵒVM Density < 20ᵒvCPU = pCPUᵒvRAM = pRAMᵒLow IOPSᵒRedundancy mattersᵒNo templates10
  11. 11. Desktop Virtualization• Core ObjectivesᵒControl of IPᵒEnsuring patch complianceᵒSupporting mobile workstyles• Looks Likeᵒ50 -100 VMs per hostᵒ2-4 vCores = pCoreᵒ1-2 vRAM = pRAMᵒHigh IOPSᵒBoot stormsᵒNetwork contentionᵒHighly templated11
  12. 12. Cloud Services• Core ObjectivesᵒAgile provisioningᵒHigh degrees of tenant isolationᵒLow operating margins• Looks Likeᵒ50-250 VMs per hostᵒ2-8 vCore = pCoreᵒvRAM = pRAMᵒModerate IOPSᵒNetwork contentionᵒLargely templated12
  13. 13. Planning the network
  14. 14. Before Virtualization• Simple management model• Provisioning took a long time• Topologies fairly static
  15. 15. Along Comes Server Virtualization• Multiple VMs/hostᵒLoss of visibilityᵒLoss of control• Edge moves into hostᵒNetwork admins need to understandserver virtualization
  16. 16. Example 1 – Mirroring Traffic• Without virtualization this is prettyeasy• With virtualization you now havemultiple VMs
  17. 17. Example 1 – Mirroring Traffic• Without virtualization this is prettyeasy• With virtualization you now havemultiple VMsᵒPlus VMs can move• Better to monitor at virtual switch
  18. 18. Example 2 – Network Policies• Server admins have significant impacton the networkᵒIP and MAC AddressᵒVirtual NICsᵒProtocols and ports• Granular network control requiresawareness of virtual machinesᵒDefine policies at virtual switch
  19. 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 dataX
  20. 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 connectVMVMVMVMVMVMVMVMVMVMHost 1Host 2VMVMVMVMVMVMVMVMVM
  21. 21. Storage choice is critical
  22. 22. Shared storage growth and provisioning time1,000500VMsCost,AU100 200500VMsProvisioning efficiencyAU – arbitrary units
  23. 23. Combined efficiency and storage evolutionRedesign1,000500VMs100 200 Cost, AUVMs1,000500Cost, AU100 200?AlternativesAU – arbitrary units
  24. 24. RedesignEfficiency and pod storage1,000500VMs100 200 Cost, AUPOD #1POD #2POD #31,000500VMs100 200 Cost, AUAU – arbitrary unitsNo redesign
  25. 25. What about local storage?1,000500VMsCost, AU100 20050VMsProvisioning efficiencyAU – arbitrary units
  26. 26. PODtrendTraditionaltrendCost-Performance TrendsShared Storage Local Storage1,000500VMsCost, AU100 2001,000500VMs100 200 Cost, AULocal storagePerformancetrendLocal storagetrend
  27. 27. Understanding disk usage and sizingVM_COUNT * VM_DISK + SWAP = TOTAL_DISKVM_COUNT * (OS_PARTITION + USR_DATA) + SWAP = TOTAL_DISKVM_COUNT = (TOTAL_DISK – SWAP) ÷ (OS_PARTITION + USR_DATA)VM_DISK SWAPUSR_DATAOS_PARTITIONTOTAL_DISK
  28. 28. Templates and thin provisioning matterVM_COUNT * USR_DATA + OS_PARTITION + SWAP = TOTAL_DISKVM_COUNT = (TOTAL_DISK – SWAP – OS_PARTITION) ÷ USR_DATASWAPTOTAL_DISKOS_PARTITION USR_DATA
  29. 29. Storage performanceIO per DiskRAID PENALTY0 11 25 46 610 250 4Write PenaltiesRPM IOPSSSD 5,000+SAS 15,000 175SAS 10,000 125SAS 7,200 75VM UtilizationITEM ~VALUEIOPS per VM 20Size, KB 4-8Writes, % 80Reads, % 20IOPS = [IOPS per DISK]*[Disk Count]*([% of Reads]+[% of Writes] ÷ [RAID Write Penalty])VM_COUNT = IOPS ÷ [IOPS per VM]
  30. 30. Blueprint for success ….
  31. 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 happenvs.
  32. 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. 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. 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. 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. 36. Cloud Operations• Design for maintainability• Monitor critical componentsᵒManagement servers and system support VMsᵒHypervisor hosts, and critical infrastructureᵒEnd user deployment environmentsIf your cloud has maintenance windows, you’re doing it wrong.- Allan Leinwand Former CTO Zynga
  37. 37. Secure multi-tenant cloud orchestration platform• Turn-key platform for IaaS delivery• Hypervisor agnostic• Massively scalable, secure and open• Simple deployment and administrationHistory• 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, 2013Over 200 contributing organizations
  38. 38. Work better. Live better.

×