How to run tier 1 applications in the cloud Cloud Expo Europe 2013

Slides @ http://www.slideshare.net/SolidFireInc

Mark Thomas - Solutions Architect

Dave Wright – Founder / CEO@jungledave

Introduction

Mark Thomas, Solutions Architect, Databarracks IT Consultant for 14 years Working with virtualisation since 2002 (ESX 1.5) Working with cloud services since 2009 Worked for VirtualizeIT for 10 years – Consultant / Manager / Director

One of first VAC partners in UK Production systems primarily from day one

Worked for Virtustream for 3 ½ years – Manager and Director One of first specific cloud providers formed for that purpose Gartner Magic Quadrant for IaaS

Dave Wright, Founder / CEO, SolidFire• Left Stanford University in 1998 to help start GameSpy Industries• GameSpy merged with IGN Entertainment as Chief Architect• Founded Jungle Disk in 2007, sold to Rackspace in 2008• Founded SolidFire in 2009 after experiencing the difficulties of high-

performance cloud storage

About Databarracks

A decade of experience in cloud computing True managed services Focussed on security and support Certified Backup to disaster recovery to Infrastructure as a Service Cloud Integrators Cloud Industry Forum Members

Our customers

Our customers

Brazil

USA

Peru

RSA

Canada

Australia

India

China

Russia

Swed

en (

1)

Norway

Poland

Singapore

Italy

UK

UAE

Spain

Germany

Thailand

Hong Kong

SWZ

Greece

The problems

Common issues for tier 1 applications

Vendor / ISV support Vendors say they don’t support virtual /cloud systems Providers struggle to understand the complexities of tier 1 applications in these

environments

Perception that performance is worse in a consolidated / multi-tenant environment

Assumptions that hypervisors add an overhead and don’t perform as well as physical Assumes all systems are many-to-one Lack of understanding of cloud about resource SLA’s Storage is an ‘unknown’ at provider and is key

WAN impact on performance Moving systems away from local introduces latency to sensitive systems Cost and reliability of links

It’s not secure enough View that multi-tenant clouds are not secure enough to host tier 1 data

The noisy neighbour

A VM or VMs consuming all the resource

OVER TIME

RESO

URC

ES C

ON

SUM

ED

BASELINE CAPACITY

BEYOND CAPACITY

xxx x

VM operate within configured resources. Actual physical resource allocated by virtualisation

administrator

As total of all VM resources grows above the total physical capacity. Additional resources are required to satisfy demand or adjusting

VM setting to compensate. Performance issues potentially but easy to manage

100%

0%

100%100%100%

0%0%0%

50%

100%

OVER TIMECLIENT A

The noisy neighbour: worse in multi-tenancy?

Same as before but now with multiple customers, whose VMs get adjusted?

OVER TIME

RESO

URC

ES C

ON

SUM

ED

BASELINE CAPACITY

BEYOND CAPACITY

xxx x

VMs operate within configured resources. Actual physical resource

allocated by service provider service and clients commitment

Service provider managed maximum physical resources. Service provider dictates

potentially how conflict situations are resolved. Not always visible to clients

100%

0%

100%100%100%

0%0%0%

50%

100%

CLIENT A CLIENT B

The common solutions

Compute ring-fencing

Reserving compute Ensure application profiling identifies resource requirements and sensitivity Treat as you would a physical system / your own virtualisation Ensure your service provider understands your environment and has associated services to

support your migration

Dedicating physical compute For things that don’t fit the provider’s shared platform Not as efficient, pay for all physical resources Customer owned or fully managed?

Storage disk reservation

Dedicating disk to provide write IO performance Cost of IO / capacity is a problem Not really cloud storage

Physical Disks

Physical SAN

Client Volumes

Client DClients A-CClients A-C share a set of disks. Client D has dedicated

Both disk pools have the same number and type of disks. Same IO but different usage

Storage auto tiering

Hides IO issues with SSD / fast disk for hot blocks Hard to control who uses what and charge back

Physical Disks

Physical SAN

Client Volumes

Blocks move as accessed

Disk pool with two or more types of disk. Normally less in fast Tier

Standard TierFast Tier

A B CA B C

A B CA B C

Blocks

Re-engineer for the cloud

Businesses should evaluate the benefits of doing things differently Applications that can be web enabled should be Consider re-developing applications using cloud platforms for scalability and performance Running applications from remote data centres is not new, architect the same way Look at changing data access to optimise the traffic (move all services together, move client

desktops close to servers)

Leverage good service provider’s knowledge Should have good SLA’s for resources Should be able to understand Enterprise applications not just web scale Should have options for optimising your environment (resource reallocation, tiers) Should offer complimentary services such as WAN optimization / remote desktops etc. to

support the re-architecture

Databarracks and SolidFire address the key IO issue

How we address the IO Issue

Storage for tier 1 applications can be placed on SolidFire storage for IO SLA’s

Each client has their own logical volume separation for performance monitoring and security segregation

Each client has their own dedicated datastores to leverage hypervisor level IO optimisations if required

Customer IO visibility for tier 1

Price per capacity (included IOPS per GB), IO increase (priced per IO) Customers can see volume IO setting via the Databarracks Service Portal Customers can specify IOP requirements in the portal

The Noisy Neighbor Effect

• Few resource hungry applications negatively affect all other volume performance

Traditional Multi-Tenant Performance

Noisy Neighbor

The Cloud Needs Better Storage

Performance

• Unable to manage performance independent of capacity

• Can not guarantee storage performance

Efficiency

• Low and inefficient utilization rates

• Lack of high performance in-line data reduction

Management

• Complex, manual, lacks automation

Scale

• Limited scalability of both capacity and performance

• Manage multiple islands of storage

Key Differentiators

Cloud ScalabilitySimultaneous scaling of both capacity and performance

Guaranteed Quality of Service (QoS)Fine-grain performance management on a per volume basis

In-lineefficiencyIn-line data reduction and 85% utilization requires less purchased capacity

Complete automationREST-based API for

complete control

SolidFire QoS in Practice

• Applications allocated into performance tiers

• Changes are immediate can be made on the fly

Traditional Multi-Tenant Performance

Application of SolidFire QoS controls

Key Requirements for running all Tier 1 apps in the cloud.

• All-SSD Architecture

• Quality of Service functionality that guarantees application storage performance

• Firm performance based SLAs

Questions?

Mark.Thomas@databarracks.com@databarracks.comwww.databarracks.com

Dave@solidfire.com@jungledavewww.solidfire.com