CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure

Download CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure

Post on 18-Nov-2014

572 views

Category:

Technology

0 download

Embed Size (px)

DESCRIPTION

Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure. Presented at CloudExpo New York City.

TRANSCRIPT

<ul><li> 1. Best Practices for ArchitectingYour Cloud InfrastructureTechnical Best Practices for a Solid CloudArchitectureMatt MullinsCloud Platform Implementation Engineer, Worldwide Cloud Services </li> <li> 2. 2013 CitrixAgenda2 Introductions Defining Architecture ObjectivesBusinessTechnicalOperational Four Key Architecture Components Reviewing Workloads Types Management Server Architecture &amp; Storage Sizing Building a Repeatable Architecture </li> <li> 3. IntroductionsA quick look at who this guy is </li> <li> 4. 2013 CitrixAbout Matt Mathias Mullins, mathias.mullins@citrix.com Been working in IT since 1996, living Cloud since 2009 Enterprise and Infrastructure Architect for FedExs 6operating companies for 6 years before joining Citrix Lead Capacity Planner and Designer for 30,000 VMs Work with designing architectures and implementingprivate and public clouds Believe we live in the Clouds every day! Professional Event, Nature and Wildlife photographer Connect at www.linkedin.com/in/mormullins </li> <li> 5. Defining Architecture ObjectivesUsing the data you have to help define theCloud </li> <li> 6. 2013 CitrixLife-Cycle of Cloud Architecture6A solid cloud architecture cannot bedesigned and implemented instantly A strong initial vision has to be defined todevelop a usable architecture Needs of a large number of stakeholders andbe taken into consideration of the design Initial Architecture will be refined and adjustedthrough discovery, analysis, and designphases An architecture that skips this process willnormally find failure and major gaps inimplement and rollout phasesDiscoveryAnalysisDesignImplementRollout </li> <li> 7. 2013 CitrixArchitecture Considerations and Objectives7 Three major considerations must be taken into account from the beginning ofArchitectural DesignBusiness drivers help to define what you need for technology capabilitiesTechnology is just one piece of the puzzleDesign an architecture that is operationally durable </li> <li> 8. 2013 CitrixArchitecture ObjectiveBusinessOperationsTechnologyTimeCapabilities </li> <li> 9. 2013 Citrix9Architecture Process based on Vitruvian TriadUtilitasVenustas FirmitasBlueprint aka DesignDesign arranged to meet functional needsStandards aka DurabilityMaterials and logistics of constructionFunction aka RequirementsClients need for structure* Ref. Palladio Treatise </li> <li> 10. 2013 Citrix10Architecture Process based on Vitruvian TriadBusinessTechnical OperationsBlueprint aka DesignDesign arranged to meet functional needsStandards aka DurabilityMaterials and logistics of constructionFunction aka RequirementsClients need for structure* Ref. Palladio Treatise </li> <li> 11. 2013 CitrixArchitecture Objectives11Mentality Change No matter how technically detailed the cloud is, have to assess the business andoperations components for success. All Private Clouds have customers - they just dont pay by credit card! In the Cloud you are no longer an administrator. You are now a service providerService/Operational Level AgreementsProvide capabilities, not administrate requestsCustomer service is back!Cloud Operations is a Business using your Technology Private, Public, or Hybrid </li> <li> 12. Four Key ArchitectureComponentsThe foundation of your cloud </li> <li> 13. 2013 CitrixFor the cloud, this phenomenon is represented by what Icall the four horsemen of dominant design. The fourhorsemen are:1. Servers2. Network3. Storage4. SoftwareRob Carter CIO FedEx Corporation113 </li> <li> 14. 2013 Citrix14Architecture Process based on Vitruvian TriadBusinessTechnical Operations* Ref. Palladio Treatise </li> <li> 15. 2013 Citrix15Architecture Process based on Vitruvian TriadComputeStorage NetworkRepository for VMs / DataSAN / NFS / LocalConnectivity to ResourcesLAN / WAN / MAN / SANCore Virtualization SystemsCPU / Memory* Ref. Palladio TreatiseSoftwareThe Glue that Pulls it TogetherCloud / Hypervisor / Network / Storage </li> <li> 16. 2013 CitrixFour Key Components16 Architecture success is going to be driven through your use of modulartechnology in the cloud. Modular technology allows for a POD based design to truly work Architectures usually start out looking at traditional and move to POD Building on modular technologies decrease the complexity of system inter-dependenciesGreater network complexityMore dependency on LAN and WAN backbones </li> <li> 17. 2013 CitrixInfrastructure Components and Pod Examples17 Reference: Cisco vmdcCPoDDesign20 </li> <li> 18. 2013 Citrix18 </li> <li> 19. Reviewing Workloads TypesWorkload-Driven Deployment Process </li> <li> 20. 2013 CitrixDeployment Architecture WorkflowDefine target workloadsDetermine how that application workload will be delivered reliablyDevelop the deployment architectureImplement cloud deploymentOperate cloud environment (e.g., monitor, upgrade, patch) </li> <li> 21. 2013 CitrixWorkload Types21 Cloud keeps developing toward IT-as-a-ServiceAlmost any system or platform can be architected into a service, XaaS Most applications can be categorized into two different workloadsCloud WorkloadsTraditional Workloads Fully redundant systems. Backupentire application infrastructure,restore upon failureCloud-Era Workloads Apps are developed to tolerateand adapt to failures </li> <li> 22. 2013 CitrixDetermine Workload Types22 What do my customers need:Scalability?Complete Reliability?Specialized or Dedicated Hardware?Relies on External Physical Devices? Firewall, Load Balancer, etc Can the applications in the Cloud:Immediate scalability?Does the application provide its ownreliability and assumes infrastructure will failProvide Elastic Service and Capacity?Utilizes L3 resources?Use Software/Virtual Services?Start by asking some questionsIf you answered Yes to theseYou have Traditional WorkloadsIf you answered Yes to theseYou have Cloud WorkloadsChances are that you or your customers may have both! </li> <li> 23. 2013 CitrixWorkload Type Traditional StylevCenter/XenCenterServerClusterServerClusterServerClusterEnterprise Networking (e.g., VLAN)Enterprise Storage (e.g., SAN)HypervisorStorageSANNetworkingL2 VLANsNetwork ServicesLoad BalancingMulti-tier AppsMulti-tier VLANs OVFFeature Rich vSphere, XenServer </li> <li> 24. 2013 CitrixWorkload Types Cloud EraHypervisorStorageLocal SharedNetworkingL3 Elastic IPNetwork ServicesSecurity GroupsMulti-tier AppsL3Simple XenServer, KVMSoftware Defined Networks(e.g., Security Groups, EIP, ELB,...)Amazon-Style Availability ZoneServerRacksServerRacksServerRacksServerRacksServerRacksServerRacksServerRacksServerRacksServerRacksElastic Storage </li> <li> 25. 2013 CitrixObject StoragevCenter/XenCenterServerClusterServerClusterServerClusterEnterprise Networking (e.g., VLAN)Enterprise Storage (e.g., SAN)AvailabilityZoneAvailabilityZoneAvailabilityZoneServer Virtualization Availability ZoneCloudPlatformMgmt. ServerWorkload Types - Combined </li> <li> 26. 2013 CitrixWorkload Types Combined + Global </li> <li> 27. Management ServerArchitecture &amp; Storage Sizing </li> <li> 28. 2013 CitrixManagement Server Cluster Backup andReplication </li> <li> 29. 2013 CitrixManagement Server Cluster HardwareLoad Balancer NetScaler VPX or MPXManagement Server 1 Intel or AMD CPU server with at least 2GHZ, 1 socket, 4 cores, 16GBof memory, and 250GB of RAID 1 local disk storageManagement Server 2 Intel or AMD CPU server with at least 2GHZ, 1 socket, 4 cores, 16GBof memory, and 250GB of RAID 1 local disk storage.Primary MySQL Intel or AMD CPU server with at least 2GHZ, 1 socket, 4cores, 16GBof memory, and 250GB of RAID 1 local disk storage.Backup MySQL Intel or AMD CPU server with at least 2GHZ, 1 socket, 4cores, 16GBof memory, and 250GB of RAID 1 local disk storage.Standby Management Server cluster is identical to the primary management server cluster with one difference: backupMySQL server is not required. </li> <li> 30. 2013 CitrixCloudPlatform System MetricsConsumable Over-Provisioning SharingMethodCloudPlatform Limit Logical orPhysicalMeasurementCPU Yes per Server Scheduling Yes 80% Physical Allocation &amp; UtilizationMemory No (not yet) SharedSegmentYes 80% Physical AllocationPrimary Storage Yes* Cluster Level Yes - # of volumes,80% UtilizationPhysical Allocation &amp; UtilizationSecondary Storage No Zone Level Yes - # of Snapshots, #of Templates/ISOsPhysical Allocation &amp; UtilizationPublic IP No Source NAT Per Account ofDomainLogical AllocationManagement IP No No No Logical AllocationVLANs No No No Logical Allocation </li> <li> 31. 2013 CitrixPrimary Storage Sizing FormulaPrimary storage sizing is based on the VM Profile. The formula for calculating theprimary storage for each cluster-specific shared storage would be as follows:R = Average size of the system/root disk.D = Average size of the Data volume.N = Average number of Data volumes attached per VM.V = Total number of VMs per pod.The size of the primary storage required per cluster would be:V * (R + (N*D))Overprovisioning is supported on NFS storage devices in CloudPlatform and canbe used to reduce the initial size requirement of the primary storage per pod. </li> <li> 32. 2013 CitrixSecondary Storage Sizing FormulaFor Secondary Storage Sizing the formula is:N = Number of VMs in the Zone.S = Average Number of Snapshots per VM.G = Average size of snapshot per VM.T = Number of Templates in the zone.I = Number of ISOs in the zone.Secondary Storage sizing would be:((N * S * G) + (I * Avg Size of ISOs) + (T * Avg size of Templates)) * 1.2There is a 20% spare capacity built into the formula. The actual size could befurther reduced based on the following factors Deduplication in the Storage Array. Thin Provisioning. Compression. </li> <li> 33. Building a RepeatableArchitectureKeep your cloud growing </li> <li> 34. 2013 CitrixRepeatable Architectures34Successful Architectures can be replicated and re-replicated because: Commodity for simplicityCompute Flexibility to meet customer needsHypervisorsStorage Types The hyper-standardize wherever possiblePhysical (Racks, Cabling, Power, etc)Protocols / NetworkSoftwareOfferings </li> <li> 35. 2013 CitrixBuilding Block Pod Based35Cloud Capacity ExpansionAdd Capacity in Building BlocksComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacitySoftware </li> <li> 36. 2013 CitrixRepeatable Architecture36 </li> <li> 37. 2013 Citrix </li> <li> 38. Work better. Live better. </li> </ul>