CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure
-
Upload
mormullins -
Category
Technology
-
view
582 -
download
0
description
Transcript of CloudExpo NYC - Citrix Cloud Platforms Best Practices for Architecting Your Cloud Infrastructure
Best Practices for Architecting Your Cloud Infrastructure
Technical Best Practices for a Solid Cloud Architecture
Matt MullinsCloud Platform Implementation Engineer, Worldwide Cloud Services
© 2013 Citrix2
Agenda
• Introductions
• Defining Architecture Objectivesᵒ Businessᵒ Technicalᵒ Operational
• Four Key Architecture Components
• Reviewing Workloads Types
• Management Server Architecture & Storage Sizing
• Building a Repeatable Architecture
IntroductionsA quick look at who this guy is…
© 2013 Citrix
About Matt• Mathias Mullins, [email protected]
• Been working in IT since 1996, living Cloud since 2009
• Enterprise and Infrastructure Architect for FedEx’s 6 operating companies for 6 years before joining Citrix
• Lead Capacity Planner and Designer for 30,000 VMs
• Work with designing architectures and implementing private and public clouds
• Believe we live in the Clouds every day!
• Professional Event, Nature and Wildlife photographer
• Connect at www.linkedin.com/in/mormullins
Defining Architecture ObjectivesUsing the data you have to help define the Cloud…
© 2013 Citrix6
Life-Cycle of Cloud Architecture
A solid cloud architecture cannot be designed and implemented instantly
• A strong initial vision has to be defined to develop a usable architecture
• Needs of a large number of stakeholders and be taken into consideration of the design
• Initial Architecture will be refined and adjusted through discovery, analysis, and design phases
• An architecture that skips this process will normally find failure and major gaps in implement and rollout phases
Discovery
Analysis
DesignImplement
Rollout
© 2013 Citrix7
Architecture Considerations and Objectives
• Three major considerations must be taken into account from the beginning of Architectural 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
© 2013 Citrix
Architecture Objective
Business
Operations
Technology
Time
Resource
s
Capa
biliti
es
© 2013 Citrix9
Architecture Process based on Vitruvian Triad
Utilitas
Venustas Firmitas
Blueprint aka DesignDesign arranged to meet functional needs
Standards aka DurabilityMaterials and logistics of construction
Function aka RequirementsClient’s need for structure
* Ref. Palladio Treatise
© 2013 Citrix10
Architecture Process based on Vitruvian Triad
Business
Technical Operations
Blueprint aka DesignDesign arranged to meet functional needs
Standards aka DurabilityMaterials and logistics of construction
Function aka RequirementsClient’s need for structure
* Ref. Palladio Treatise
© 2013 Citrix11
Architecture Objectives
Mentality Change
• No matter how technically detailed the cloud is, have to assess the business and operations 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
Four Key Architecture Components
The foundation of your cloud…
© 2013 Citrix13
“For the cloud, this phenomenon is represented by what I call ‘the four horsemen of dominant design.’ The four horsemen are:
1. Servers 2. Network3. Storage4. Software”
Rob Carter – CIO FedEx Corporation1
© 2013 Citrix14
Architecture Process based on Vitruvian Triad
Business
Technical Operations
* Ref. Palladio Treatise
© 2013 Citrix15
Architecture Process based on Vitruvian Triad
Compute
Storage Network
Repository for VMs / DataSAN / NFS / Local
Connectivity to ResourcesLAN / WAN / MAN / SAN
Core Virtualization SystemsCPU / Memory
* Ref. Palladio Treatise
SoftwareThe Glue that Pulls it
TogetherCloud / Hypervisor / Network / Storage
© 2013 Citrix16
Four Key Components
• Architecture success is going to be driven through your use of modular technology 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
© 2013 Citrix17
Infrastructure Components and Pod Examples
Reference: Cisco vmdcCPoDDesign20
© 2013 Citrix18
Reviewing Workloads TypesWorkload-Driven Deployment Process
© 2013 Citrix
Deployment Architecture Workflow
Define target workloads
Determine how that application workload will be delivered reliably
Develop the deployment architecture
Implement cloud deployment
Operate cloud environment (e.g., monitor, upgrade, patch)
© 2013 Citrix21
Workload Types
• 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 workloads
Cloud Workloads
Traditional Workloads
• Fully redundant systems. Backup entire application infrastructure, restore upon failure
Cloud-Era Workloads
• Apps are developed to tolerate and adapt to failures
© 2013 Citrix22
Determine Workload Types
• 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 own reliability 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 Workloads
If you answered Yes to these…You have Cloud Workloads
Chances are that you or your customers may have both!
© 2013 Citrix
Workload Type – Traditional Style
vCenter/XenCenter
Server Cluster
Server Cluster
Server Cluster
Enterprise Networking (e.g., VLAN)
Enterprise Storage (e.g., SAN)
Hypervisor
Storage
SAN
Networking
L2 VLANs
Network Services
Load Balancing
Multi-tier Apps
Multi-tier VLANs OVF
Feature Rich– vSphere, XenServer
© 2013 Citrix
Workload Types – Cloud Era
Hypervisor
Storage
Local Shared
Networking
L3 Elastic IP
Network Services
Security Groups
Multi-tier Apps
L3
Simple – XenServer, KVM
Software Defined Networks (e.g., Security Groups, EIP, ELB,...)
Amazon-Style Availability Zone
Server Racks
Server Racks
Server Racks
Server Racks
Server Racks
Server Racks
Server Racks
Server Racks
Server Racks
Elastic Storage
© 2013 Citrix
Object Storage
vCenter/XenCenter
Server Cluster
Server Cluster
Server Cluster
Enterprise Networking (e.g., VLAN)
Enterprise Storage (e.g., SAN)
Availability Zone
Availability Zone
Availability Zone
Server Virtualization Availability ZoneCloudPlatform Mgmt. Server
Workload Types - Combined
© 2013 Citrix
Workload Types – Combined + Global
Management Server Architecture & Storage Sizing
© 2013 Citrix
Management Server Cluster Backup and Replication
© 2013 Citrix
Management Server Cluster Hardware
Load Balancer NetScaler VPX or MPX
Management Server 1 Intel or AMD CPU server with at least 2GHZ, 1 socket, 4 cores, 16GB of memory, and 250GB of RAID 1 local disk storage
Management Server 2 Intel or AMD CPU server with at least 2GHZ, 1 socket, 4 cores, 16GB of memory, and 250GB of RAID 1 local disk storage.
Primary MySQL Intel or AMD CPU server with at least 2GHZ, 1 socket, 4cores, 16GB of memory, and 250GB of RAID 1 local disk storage.
Backup MySQL Intel or AMD CPU server with at least 2GHZ, 1 socket, 4cores, 16GB of memory, and 250GB of RAID 1 local disk storage.
Standby Management Server cluster is identical to the primary management server cluster with one difference: backup MySQL server is not required.
© 2013 Citrix
CloudPlatform System MetricsConsumable Over-Provisioning Sharing
MethodCloudPlatform Limit Logical or
PhysicalMeasurement
CPU Yes – per Server Scheduling Yes – 80% Physical Allocation & Utilization
Memory No (not yet) Shared Segment
Yes – 80% Physical Allocation
Primary Storage Yes* Cluster Level Yes - # of volumes, 80% Utilization
Physical Allocation & Utilization
Secondary Storage No Zone Level Yes - # of Snapshots, # of Templates/ISOs
Physical Allocation & Utilization
Public IP No Source NAT Per Account of Domain
Logical Allocation
Management IP No No No Logical Allocation
VLANs No No No Logical Allocation
© 2013 Citrix
Primary Storage Sizing FormulaPrimary storage sizing is based on the VM Profile. The formula for calculating the primary 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 can be used to reduce the initial size requirement of the primary storage per pod.
© 2013 Citrix
Secondary 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.2
There is a 20% spare capacity built into the formula. The actual size could be further reduced based on the following factors • Deduplication in the Storage Array. • Thin Provisioning. • Compression.
Building a Repeatable Architecture
Keep your cloud growing…
© 2013 Citrix34
Repeatable Architectures
Successful 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
© 2013 Citrix35
Building Block – Pod Based
Cloud Capacity Expansion
Add Capacity in Building Blocks
ComputeCapacity
NetworkCapacity
StorageCapacity
ComputeCapacity
NetworkCapacity
StorageCapacity
ComputeCapacity
NetworkCapacity
StorageCapacity
ComputeCapacity
NetworkCapacity
StorageCapacity
ComputeCapacity
NetworkCapacity
StorageCapacity
Software
© 2013 Citrix36
Repeatable Architecture
© 2013 Citrix
QUESTIONS?
Work better. Live better.