This document provides technical best practices for architecting a cloud infrastructure. It discusses defining architecture objectives in terms of business, technical, and operational needs. The four key architecture components are identified as compute, storage, networking, and software. Traditional and cloud-native workload types are reviewed to determine deployment requirements. Formulas are given for sizing management servers and storage. Building repeatable architectures through pod-based design and standardized components is recommended for scalable cloud capacity expansion.
CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure
1. Best Practices for Architecting
Your Cloud Infrastructure
Technical Best Practices for a Solid Cloud
Architecture
Matt Mullins
Cloud Platform Implementation Engineer, Worldwide Cloud Services
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: http://www.citrix.com/content/dam/citrix/en_us/documents/products/citrix_cloudplatform_3_0_x_deployment_reference_architecture.pdf
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: http://www.citrix.com/content/dam/citrix/en_us/documents/products/citrix_cloudplatform_3_0_x_deployment_reference_architecture.pdf
For more information, make sure to download the Citrix CloudPlatform Reference Architecture: http://www.citrix.com/content/dam/citrix/en_us/documents/products/citrix_cloudplatform_3_0_x_deployment_reference_architecture.pdf
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.