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

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

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

4. Our customers

5. Our customers
Norway
Russia
Canada UK
Germany
Poland
SWZ
USA
Spain Italy Greece
China
UAE India
Hong Kong
Thailand
Singapore
Brazil
Peru
Australia
RSA

6. The problems

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

8. The noisy neighbour
 A VM or VMs consuming all the resource
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 BEYOND CAPACITY
RESOURCES CONSUMED
100%
50%
x
x
x
x
100% 100% 100% 100%
VM operate within configured resources. Actual
physical resource allocated by virtualisation
administrator
0% 0% 0% 0% BASELINE CAPACITY
CLIENT A
OVER TIME

9. The noisy neighbour: worse in multi-tenancy?
 Same as before but now with multiple customers, whose VMs get adjusted?
Service provider managed maximum physical
resources. Service provider dictates
potentially how conflict situations are
resolved. Not always visible to clients
BEYOND CAPACITY
RESOURCES CONSUMED
100%
50%
x
x
x
x
100% 100% 100% 100%
VMs operate within configured
resources. Actual physical resource
allocated by service provider service
and clients commitment
0% 0% 0% 0% BASELINE CAPACITY
CLIENT A CLIENT B
OVER TIME

10. The common solutions

11. 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?

12. Storage auto tiering
 Hides IO issues with SSD / fast disk for hot blocks
 Hard to control who uses what and charge back
Client Volumes
Physical SAN
Disk pool with
two or more Standard Tier
Fast Tier
types of disk.
Normally less in Physical Disks
fast Tier
Blocks move A B C
A B C Blocks
as accessed A B C
A B C

13. Storage disk reservation
 Dedicating disk to provide write IO performance
 Cost of IO / capacity is a problem
 Not really cloud storage
Clients A-C Client D
Clients A-C
share a set of Client Volumes
disks. Client D
has dedicated
Physical SAN
Both disk pools
have the same
number and
type of disks. Physical Disks
Same IO but
different usage

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

15. Databarracks and SolidFire
address the key IO issue

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

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

18. The Noisy
Neighbor Effect Noisy Neighbor
• Few resource hungry
applications
negatively affect all
Traditional Multi-Tenant
other volume Performance
performance

19. Performance
The Cloud
• Unable to manage performance independent of
Needs Better capacity
Storage • 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

20. Key Differentiators
Guaranteed Quality In-line Complete Cloud
of Service (QoS) efficiency automation Scalability
In-line data reduction and REST-based API for Simultaneous scaling of both
Fine-grain performance
85% utilization requires less complete control capacity and performance
management on a per volume
purchased capacity
basis

21. SolidFire QoS
in Practice
Traditional Multi-Tenant
Performance
• Applications allocated Application of SolidFire
into performance tiers QoS controls
• Changes are immediate
can be made on the fly

22. Key • All-SSD Architecture
Requirements • Quality of Service functionality that
guarantees application storage
for running all performance
Tier 1 apps in • Firm performance based SLAs
the cloud.

23. Questions?
Mark.Thomas@databarracks.com
@databarracks.com
www.databarracks.com
Dave@solidfire.com
@jungledave
www.solidfire.com