Databarracks & SolidFire- How to run tier 1 applications in the cloud
-
Upload
solidfire-inc -
Category
Documents
-
view
943 -
download
1
description
Transcript of Databarracks & SolidFire- How to run tier 1 applications in the cloud
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?
[email protected]@databarracks.comwww.databarracks.com
[email protected]@jungledavewww.solidfire.com