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, mathias.mullins@citrix.com

• 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.