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


Published on

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

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Introductions – Matt / JacobLife-Cycle of Cloud Architecture – MattDefining Architecture Objectives – MattFour Key Architecture Components – MattReviewing Workloads Types - JacobManagement Server Architecture & Storage Sizing - JacobBuilding a Repeatable Architecture - Matt
  • The three tracks Business, Operations, and Technology overlay each other for architecture success.
  • May or May not use, haven’t decided.
  • There are two fundamental differences between traditional workloads and cloud-era workloads.SCALE: Traditional enterprise applications serve tens of thousands of users and hundreds of sessions. Driven by the growth of Internet and mobile devices, Internet applications serve tens of millions of users. The orders of magnitude difference in scale translates to significant difference in demand for computing infrastructure. As a result the need to reduce cost and improve efficiency becomes paramount.RELIABILITY: The difference in scale has an important side effect. Enterprise applications can be designed to run on reliable hardware. Application developers do not expect the underlying enterprise-grade server or storage cluster to fail during normal course of operation. Sophisticated backup and disaster recovery procedures can be setup to handle the unlikely scenario of hardware failure. The Internet scale changed the paradigm. As the amount of hardware resources grow, it is no longer possible to deliver the same level of enterprise-grade reliability, backup, and disaster recovery at the scale needed to support Internet workloads in a cost effective and efficient manner.
  • Traditional workloads in the cloud are typically designed with a requirement for high availability and fault tolerance and use common components of an enterprise datacenter to meet those needs. This starts with an enterprise-grade hypervisor, such as VMware vSphere or Citrix XenServer that supports live migration of virtual machines and storage and has built-in high availability. Storage of virtual machine images leverages high-performance SAN devices. Traditional physical network infrastructure like firewalls and layer 2 switching are used and VLANs are designed to isolate traffic between servers and tenants. VPN tunneling provides secure remote access and site-to-site access through existing network edge devices. Applications are packaged using industry-standard OVF files.
  • The desire for cost-savings can easily offset the need for features in designing for a cloud-era workload making open source and commodity components such as XenServer and KVM a more attractive option. In this workload type, virtual machine images are stored on a local or shared storage such as NFS. Because of VLAN scalability limitations, software defined networks are becoming necessary in cloud-era availability zones. CloudPlatform meets this need by supporting Security Groups in L3 networking.
  • As a traditional-style enterprise application, the management server cluster is front ended by a load balancer and connects to a shared MySQL database. While the cluster nodes themselves are stateless and can be easily recreated, the MySQL database node should be backed up and replicated to a remote site to ensure continuing operation of the cloud. The following figure illustrates how a standby management server cluster is setup in a remote datacenter.
  • It is permissible to run management server and MySQL server as virtual machinesLoad Balancer typically handles ports 8080 (HTTP) and 8250 (TCP) - persistence required
  • *Yes – depends on the storage type used and hypervisorAllocation versus UtilizationIt is very important to understand the difference between whether a consumable is tracked via allocation or utilization. This greatly affects the measurement of that resource and how it should be accounted for when looking at sizing. Allocated: Iswhen a consumable is completely accounted for, regardless of whether it is fully utilized or not. Example: A 1TB volumes allocated size is 1TB, even when only 1MB has been written to it.Utilized: Is when a consumable is only measured on the value of the amount of resources that are currently in use. Example: A 1TB volumes utilized size is 1MB if only 1MB has been written to it, regardless of it’s allocated size.For more information, make sure to download the Citrix CloudPlatform Reference Architecture:
  • If using tiered storage, which is quite common in traditional Enterprise style workloads, repeat the calculation for each tier.For more information, make sure to download the Citrix CloudPlatform Reference Architecture:
  • For more information, make sure to download the Citrix CloudPlatform Reference Architecture:
  • This example shows an existing cloud with a pre-determined network-compute-storage ratio. All pods are the same and have same ratios. This allows additional capacity to be added in a disciplined configurations.
  • CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure

    1. 1. Best Practices for ArchitectingYour Cloud InfrastructureTechnical Best Practices for a Solid CloudArchitectureMatt MullinsCloud Platform Implementation Engineer, Worldwide Cloud Services
    2. 2. © 2013 CitrixAgenda2• Introductions• Defining Architecture ObjectivesᵒBusinessᵒTechnicalᵒOperational• Four Key Architecture Components• Reviewing Workloads Types• Management Server Architecture & Storage Sizing• Building a Repeatable Architecture
    3. 3. IntroductionsA quick look at who this guy is…
    4. 4. © 2013 CitrixAbout Matt• Mathias Mullins,• Been working in IT since 1996, living Cloud since 2009• Enterprise and Infrastructure Architect for FedEx‟s 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
    5. 5. Defining Architecture ObjectivesUsing the data you have to help define theCloud…
    6. 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
    7. 7. © 2013 CitrixArchitecture Considerations and Objectives7• Three major considerations must be taken into account from the beginning ofArchitectural DesignᵒBusiness drivers help to define what you need for technology capabilitiesᵒTechnology is just one piece of the puzzleᵒDesign an architecture that is operationally durable
    8. 8. © 2013 CitrixArchitecture ObjectiveBusinessOperationsTechnologyTimeCapabilities
    9. 9. © 2013 Citrix9Architecture Process based on Vitruvian TriadUtilitasVenustas FirmitasBlueprint aka DesignDesign arranged to meet functional needsStandards aka DurabilityMaterials and logistics of constructionFunction aka RequirementsClient’s need for structure* Ref. Palladio Treatise
    10. 10. © 2013 Citrix10Architecture Process based on Vitruvian TriadBusinessTechnical OperationsBlueprint aka DesignDesign arranged to meet functional needsStandards aka DurabilityMaterials and logistics of constructionFunction aka RequirementsClient’s need for structure* Ref. Palladio Treatise
    11. 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 don‟t pay by credit card!• In the Cloud you are no longer an administrator. You are now a service providerᵒService/Operational Level AgreementsᵒProvide capabilities, not administrate requestsᵒCustomer service is back!Cloud Operations is a Business using your Technology – Private, Public, or Hybrid
    12. 12. Four Key ArchitectureComponentsThe foundation of your cloud…
    13. 13. © 2013 Citrix“For the cloud, this phenomenon is represented by what Icall „the four horsemen of dominant design.‟ The fourhorsemen are:1. Servers2. Network3. Storage4. Software”Rob Carter – CIO FedEx Corporation113
    14. 14. © 2013 Citrix14Architecture Process based on Vitruvian TriadBusinessTechnical Operations* Ref. Palladio Treatise
    15. 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
    16. 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-dependenciesᵒGreater network complexityᵒMore dependency on LAN and WAN backbones
    17. 17. © 2013 CitrixInfrastructure Components and Pod Examples17 Reference: Cisco vmdcCPoDDesign20
    18. 18. © 2013 Citrix18
    19. 19. Reviewing Workloads TypesWorkload-Driven Deployment Process
    20. 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)
    21. 21. © 2013 CitrixWorkload Types21• Cloud keeps developing toward IT-as-a-ServiceᵒAlmost 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
    22. 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 failᵒProvide Elastic Service and Capacity?ᵒUtilizes L3 resources?ᵒUse Software/Virtual Services?Start by asking some questions…If you answered Yes to these…You have Traditional WorkloadsIf you answered Yes to these…You have Cloud WorkloadsChances are that you or your customers may have both!
    23. 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
    24. 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
    25. 25. © 2013 CitrixObject StoragevCenter/XenCenterServerClusterServerClusterServerClusterEnterprise Networking (e.g., VLAN)Enterprise Storage (e.g., SAN)AvailabilityZoneAvailabilityZoneAvailabilityZoneServer Virtualization Availability ZoneCloudPlatformMgmt. ServerWorkload Types - Combined
    26. 26. © 2013 CitrixWorkload Types – Combined + Global
    27. 27. Management ServerArchitecture & Storage Sizing
    28. 28. © 2013 CitrixManagement Server Cluster Backup andReplication
    29. 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.
    30. 30. © 2013 CitrixCloudPlatform System MetricsConsumable Over-Provisioning SharingMethodCloudPlatform Limit Logical orPhysicalMeasurementCPU Yes – per Server Scheduling Yes – 80% Physical Allocation & UtilizationMemory No (not yet) SharedSegmentYes – 80% Physical AllocationPrimary Storage Yes* Cluster Level Yes - # of volumes,80% UtilizationPhysical Allocation & UtilizationSecondary Storage No Zone Level Yes - # of Snapshots, #of Templates/ISOsPhysical Allocation & UtilizationPublic IP No Source NAT Per Account ofDomainLogical AllocationManagement IP No No No Logical AllocationVLANs No No No Logical Allocation
    31. 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.
    32. 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.
    33. 33. Building a RepeatableArchitectureKeep your cloud growing…
    34. 34. © 2013 CitrixRepeatable Architectures34Successful Architectures can be replicated and re-replicated because:• Commodity for simplicityᵒCompute• Flexibility to meet customer needsᵒHypervisorsᵒStorage Types• The hyper-standardize wherever possibleᵒPhysical (Racks, Cabling, Power, etc…)ᵒProtocols / NetworkᵒSoftwareᵒOfferings
    35. 35. © 2013 CitrixBuilding Block – Pod Based35Cloud Capacity ExpansionAdd Capacity in Building BlocksComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacityComputeCapacityNetworkCapacityStorageCapacitySoftware
    36. 36. © 2013 CitrixRepeatable Architecture36
    37. 37. © 2013 Citrix
    38. 38. Work better. Live better.