|
by
Zsolt Kerekes,
editor - December 6, 2011 |
| ..... |
| Need SSD Acceleration ASAP? |
Say hello to
SSD ASAPs
when
I use this term it includes:-
- auto-tiering SSD appliances
- SSD cache - the automatic kind
- SSD acceleration As Soon As Possible
- Auto-tuning SSD Accelerated Pools of storage
- combinations of the above
The idea is simple.
An SSD
ASAP is something which you install between 2 storage systems which have vastly
different latency and capacity.
The ASAP uses its own intelligence to
figure out data hot spots - and tries to ensure - that as often as possible -
the data which you want from the slower, bigger store - is accessible to your
legacy apps
software which still believes it's doing R/W to the slower store.
An
SSD ASAP can take many physical form factors. It can be:-
Why
are ASAPs needed?
Business and economic realities:-
- you need fast storage - because if your apps run slow - you fail to meet
your data goals.
- but - fastest
storage costs a lot more than other types of storage. You can't afford
to make all your storage the fastest kind.
- fastest storage has lower capacity per rack height than bulk storage. It
takes up too much space.
- fastest storage uses more power than bulk storage. Using it for all your
needs would lead to high running costs - and lower the
reliability -
because all that heat added up together could cook your data.
- You can't afford to do this tuning manually.
That's how it used to
be done for decades - by hot spot tuning engineers. There are too few of
them. They cost a lot to engage. And after they've left - your apps might change
and you'd have to start all over again.
why are ASAPs a new market?
There
have always been storage heirarchies in the data storage market - the old
rotating types of storage - such as hard disks, optical drives, HDD RAID arrays
and tape evolved with software and processors over many decades and so too did
ways of dealing with them.
The new new economics of SSD storage took
the CPU designers and OS software developers by surprise.
Instead of
weaving in fast SSD support into computer architecture over a 10 year period -
based on an incremental technology roadmap - the SSD market has gate-crashed
the server party - and the SSD roadmaps are changing too fast for the old
style computer vendors to keep up.
SSD ASAPs provide tactical
solutions to solving storage problems today. Such as accelerating bulk storage
which has HDDs inside.
But SSD ASAPs will always be needed in the
future too - even when all storage is solid state - to interface between fast
and slow SSD storage. They are 1 of the
7 enterprise SSD
application market silos.
In the
big picture model
of SSDs - one way to view SSD ASAPs - is like
SSD controllers - a
special type of SSD intellectual property.
Some storage oems will
design their own ASAP function - but most oems will leverage 3rd party
products.
Is there any pattern emerging in this chaos?
Just as
in the SSD controller market - you can divide architecture into
big versus small
- I think you can do something similar with ASAPs.
Who's doing what
in the SSD ASAP world?
click here to see SSD ASAP
news | |
|
the (original) business case for SSD ASAPs
published here - September 2009
SSD makers have
been talking about auto tuning SSD acceleration tools and software for over
10 years. See
autor-tiering news
for recent details.
The lure of a multi billion dollar ASAPs market
has been sucking new vendors in at the rate of more than 1 / month in the past
2 years. One or some of these new solutions might work. But which ones? And
where do they work best?
Let's start by asking the question - Who
needs ASAPs?
- your live data is too big to fit entirely and economically into
SSD.
You like the idea - SSDs could make your apps go faster. Problem
is you're not in an industry where you can stuff raw low latency and high IOPS
in one end of your business sausage machine and expect to see increased
revenue and dollars streaming out the other end. - (unlike financial traders
and banks).
- your SSD budget is too small to justify the expense of human
tuning.
(Even if your workplace is big - your department's server
budget is small - so you're in the same bind as SMBs. The SSD tuning wizards
can't afford to visit you. Even worse - you can see SSDs doing a great job in
bigger apps in another cubicle.) |
the business case for SSD ASAPs
StorageSearch.com
invented the term "ASAPs" (in September 2009) to describe a new class
of SSDs - which eliminate user waits for the SSD hot-shot - an engineer who
traditionally tunes
SSDs in storage networks to
accelerate HDD based
arrays by analyzing application data hot-spots and bottlenecks and
logically relocating critical segments in high IOPs / low latency
solid state
disks.
The SSD ASAP acronym also works as a concept for users
who want - SSD Acceleration As Soon As Possible.
The manual
tuning process can take anything from 1/2 a day to several days - depending on
the complexity of the environment. And because genuine SSD hot shots are rare -
you may have to wait days or weeks before one of these gurus comes to visit you.
And if your budget isn't big enough? Too bad. Your low
priority score with vanilla SSD vendors means that you may never get to see an
SSD hot shot at all. In that case your only realistic enterprise SSD
acceleration options are:-
- placing ALL your data in solid state storage - which avoids the necessity
for tuning - but is too pricey
for most business situations
- learning how
to tune the SSD / HDD mix yourself
- or buying an ASAP
|
Why Some Users Need ASAPs
In
an article published in
2003 StorageSearch.com predicted that server SSDs had the potential to
become a $10 billion / year market. I had used SSDs with multi-user servers in
the 1980s - and I surprised myself (as well as many SSD vendors) when I
extrapolated various readers and technology trends and saw how 4 factors would
intersect to create the massive new market for SSD server acceleration whose
growing pains we're witnessing today. Those were:-
1 - the relentless
and ever growing need for application performance
2 - the declining
growth rate in processor frequencies since the end of the 1990s due to the
physical limits caused by signal skew on fat data busses as they came out of the
chip. (You could more CPU cores in these chips - but you couldn't get faster
signals out.)
3 - the declining cost of semiconductor memory
4
- the brick wall in hard disk latencies which hadn't altered a jot since the 1st
15K RPM hard drives started shipping in 2000. Most industry analysts
never
expected to see 20K RPM drives. Although shrinking magnetic geometries
increased capacity and throughput - the random access times remained unchanged. |
| The point at which users would turn to SSDs to
speed up their servers would be different in different markets - the user value
proposition being the point where it's cheaper to add SSDs than add new servers,
or impossible to get the same performance in any other way. These factors had
been well known by a small number of SSD experts for many years - but while
memory prices put SSDs out of reach - and while server oems could still sell
fatter CPUs (with more cores) rather than faster CPUs (with better peak
performance) these solutions remained the tools of last resort used by power
users in the defense, intelligence, broadcast and financial markets. And
another factor stopping the secret getting out was that customers who had got
success in using these tools didn't want their competitors (or enemies) knowing
how they'd done it. |
| |
Now of course the SSD server acceleration
paradigm is common knowledge - helped to some degree - by marketing hype from
the
SSD notebook
market. And it's reasonable for users to ask the question - "If SSDs can
make our notebooks faster - why not our servers too?"
The answer
is - "Yes they can - but it may still cost more than you can afford."
If
your corporate data sits in 10TB, 100TB or multiple petabytes it's not
economically feasible to place all your data in an SSD. That's one difference
to the situation with notebooks. It's not just the cost of the memory - the cost
of the SSD controllers
rise astronomically as the speed goes up the levels needed to support servers
apps too.
Tactically - what server owners have done since the dawn of
the SSD server market is try to get as much acceleration as they can afford by
using as little SSD capacity as possible.
Traditionally in
RAID systems and
SANs that process
has meant analyzing the bottlenecks in server apps - where the most
IOPS occur
in the smallest identifiable part of the disk storage system. With some apps -
like databases - whole books have been written on the subject. It's still a
difficult and time consuming task - but if you can get hold of a good SSD hot
shot and the right analysis tools - the data hot spots can be migrated to the
fast SSD storage - and if you're lucky you can get 2x to 40x application
speedups by logically replacing a small percentage of your disk bound data.
And
that's where another economic factor comes in.
The supply of SSD hot
shots - engineers who really understand SSD tuning issues - is limited. Most
work for SSD vendors - and their time is best utilized by focusing on the
biggest new customer prospects. If you work in a user organization where your
SSD budget is less than a million dollars - it's unlikely you will get to meet
one of these people (unless you are willing to be a beta site for a new product
from a new company.)
So - for most of you - the options are:-
- become your own SSD tuning expert (risky unless you work in an environment
which encourages research and trial and error), or
- get someone who's an inexperienced SSD expert to do the job for you. (Ask
them how many SSD tune ups they did in 2005?), or
- test a product which does some of the tuning process for you. This is
the market niche for SSD ASAPs - which in my view is a very big market -
because most small and medium sized organizations don't have million dollar SSD
server budgets yet (December 2009) - even if their organization is already
deploying millions of dollars worth of servers.
There are many flavors
of "auto tuning" within the ASAP market space - and there will be more
to come. Currently they are segmented by interface type. In the future there
will be ASAPs which have been optimized for particular classes of application.
An important argument in favor of the SSDs ASAP type solution - is
that unlike a human tuned system - the ASAP should maintain its initial
effectiveness for longer - because it's always learning. Whereas in a
traditionally tuned system it may be necessary from time to time to revisit the
initial design assumptions if factors in the application environment change
considerably.
Important Warning! No matter how fast the SSD in
the ASAP - you will only get an economic speed up if the assumptions about data
use (designed into the box) correlate well with the actual frequency and shape
of the data usage patterns in your application. If that's not the case - then
shuffling data into a fast cache at a time when that particular data is not the
bottleneck - is simply an expensive way to achieve nothing at all. This is
something which you only learn by trial and error, and experience in modeling.
And another lesson I learned for myself in
1990 (which
is still true today) is that for some applications and some data sets - the
bottleneck is not the disk system but something else! And adding an SSD in
these circumstances achieves no speedup at all - even if all the data is sitting
on the SSD.
To summarize this important point - adding an SSD does
not make the application faster - if the data in the SSD is the wrong data (at
that time) or if the old hard disk system wasn't the bottleneck in the first
place.
I'm an evangelist for using SSDs in the right places for the right
reasons when they are economic. They have many advantages. But like any tool -
you have to know when its use is appropriate.
I just wanted to get that
out of the way. It's an important sanity check. Now let's assume that you might
have an application which might speedup economically using SSDs. You're trying
to investigate this subject in more detail and will do testing on whatever you
shortlist on a try before you buy basis (which the SSD industry started to
adopt more widely after seeing results from our
2004 SSD buyer survey).
Deciding
if you are an ideal user who should be looking at the SSD ASAP market (or
not) sounds like a complicated process. But I think there are some simple
filtering questions you can ask yourself - shown in the table below - which
might be helpful. |
What type of SSD
server acceleration tuning should I be looking at?
Which of the these
best describes your application? |
thousands of servers
homogene ous
environment
Google style architecture. All servers have about the same
weight and run the same or very similar apps. |
Congratulations! Your budget is big enough to
attract an SSD hot shot.
They will probably steer you to embedded SSDs
(either PCIe SSDs or
2.5" SSDs
integrated in each server rack. |
thousands of servers
heterogeneous
environment
Command and control style architecture. Some servers are
heavy weight, others are light weight. They interact at many points in many
complex ways. |
Congratulations! Your budget is big enough to
attract an SSD hot shot.
If your low end servers are bottlenecks -
those may benefit from embedded SSDs (like above).
But that also
places more IOPS
stress upstream - where the only solutions may be
SAN (or
Infiniband)
compatible RAM SSDs.
In addition to the embedded SSDs downstream. |
tens to hundreds of servers
any
environment
any architecture. |
This is a gray area where you may or may not
attract an SSD hot shot.
At the top end of this range you will most
likely benefit from some kind of human adjusted tuning - because ASAPs are an
expensive option when scaled up (compared to the alternatives.)
At
the bottom end of this range using ASAPs (if they work for your type of
application) may be worth testing - because the cost of analyzing and tuning
your system using a human SSD expert may outweigh the theoretical cost
differences between an ASAP and a dumb vanilla SSD. |
1 to 10 servers
any environment
any
architecture. |
It's almost certain you won't attract an SSD
hot shot. (Unless you want to be a beta site.)
The good news is - there
are many possible different ways in which you could use SSDs (inside the box,
outside the box etc). The bad news is there are so many possible solutions which
might work too.
The entry level price for some types of ASAP may be the
determining factor which rules them in our out. Performance scalability is not
an important issue for this low server count. Total disk capacity may be.
You
may have to become your own SSD hot shot expert. | |
| In the current state of the market (September
2009) - with only a handful of vendors offering genuine SSDs ASAP products -
there is a limited range of choices for users who have any particular
interface preference. But I expect this to change in the next few years as the
scale of the market opportunity becomes better understood. This will be driven
by the growing gap between trained SSD hot shots and demand for SSD
acceleration. |
more SSD articles and directories
SSD news
SSD history
the fastest SSDs
Tuning SANs with SSDs
Aspects of
3rd Party Caching
sugaring MLC for the
enterprise
how
fast can your SSD run backwards?
the Problem with
Write IOPS - in flash SSDs
Can you trust flash SSD
specs & benchmarks?
Where
to put your flash SSD accelerators - for best results (pdf) |
|
| | |
| ....... |
 |
|
. |
|
| SSD
auto tiering / caching acceleration related articles | |
|
| |
|
. |
|
|
|
. |
|
|
|
. |
|
| "In May 2003 -Imperial
Technology launched the world's first SSD tuning software tool called -
WhatsHot SSD - which analyzed real-time file usage on the SAN to identify
hot-files to place in SSD." |
| ...from:-
SSD Market
History | | |
|
. |
|
| classic SSDs from
SSD market
history |
|
|
| Nowadays there are many companies in the
auto-caching enterprise SSD market. But the first such systems product was
the XcelaSAN (shown above) which was launched in
September 2009 -
and was advertised here on StorageSearch.com | | |
|
. |
|
| who sells
(or has sold) SSD ASAPs? |
Over 200 companies have marketed SSD
ASAP appliances or technology including:-
Adaptec,
Alacritech,
Atlantis Computing,
Avere Systems,
CacheIO,
Coho Data,
Compellent,
DataCore,
Dataram,
Dell,
Dot Hill,
Drobo,
EMC,
Enmotus,
FlashSoft,
Fusion-io,
GreenBytes,
GridIron Systems,
HGST,
HP (3PAR),
IceWEB,
Infortrend,
Intel,
IO Turbine,
LSI,
Marvell ,
Network Appliance,
Nexenta Systems,
NexGen,
NEVEX Virtual Technologies,
Nimble Storage,
Nutanix,
NVELO,
OCZ,
PernixData,
PMC-Sierra,
Proximal Data,
SANRAD,
Tegile Systems,
VeloBit,
XIO...
For
more similar companies take a look at
SSD ASAP news. | | |
|
. |
|
| "In all SSD caches
and even more so in auto tiering / SSD ASAPs the age or longevity
working with the data set has a big impact on performance." |
| how fast can your SSD
run backwards? | | |
|
. |
|
| "The SSD platform
represents a bigger market opportunity in the next 5 years than any other type
of enterprise software. The winners in SSD software could be as important for
infrastructure as Microsoft was for PCs, or Oracle was for databases, or Google
was for search." |
| get ready for a world
in which all enterprise data touches SSDs | | |
|
. |
|
|
|
. |
|
| "...Cached RAID
solutions are starting to run out of gas in high-performance,
transaction-intensive applications: while the performance demands on e-business
infrastructures are being driven to new levels by exploding demand,
unpredictable peak loads, and an increasingly impatient population of on-line
customers. It's time for another architectural innovation." |
| Michael Casey, Solid Data Systems
(November 2000) - in his article -
Solid State
File-Caching for Performance and Scalability | | |
|
. |
|
| "SSD caching is
most effective with cache-friendly workloads.... On the other hand, some
workloads are not very cache friendly and do not show significant performance
gains..." |
| ...from:- page 30 -
Demartek
SSD Deployment Guide (pdf) (April 2012) | | |
|
. |
|
| 7 SSD types will
satisfy all future enterprise needs |
| The enterprise SSD market is complicated
enough already but despite that - only 7 distinct types of SSD classes are all
that are needed to sustainably satisfy all the architecture needs in the pure
solid state storage data center - one of which is SSD ASAPs. |
 |
If you're an enterprise SSD
user - you can use these classifications to judge where all the current SSDs in
your shortlist today fit within the scope of your (maybe as yet unclear)
future SSD architecture. ...read the article | | | |
|
. |
|
| let's fix
this aspect of SSD jargon ASAP |
Editor:- July 2, 2012 - 3 years ago I started
using the term "SSD ASAP" as a moniker for lumping together a whole
load of related SSD appliance and software products - which included auto
caching, acceleration, auto-tiering etc. When I use this term it includes:-
- auto-tiering SSD appliances
- SSD cache - the automatic kind
- SSD acceleration As Soon As Possible
- Auto-tuning SSD Accelerated Pools of storage
- combinations of the above
I know that many people in the industry
are happy with my SSD ASAPs usage. But despite that - it hasn't been widely
adopted yet.
Part of the reason may be that SSD vendors always prefer
to create the illusion that they are doing something which is uniquely
different to everyone else. And if they refer to their products as "SSD
ASAPs" on their own web sites - it makes it easier for you to locate
possible competitors.
If you're serious about
that type of product
- you're going to do the research anyway - even if 30 different companies call
it by 30 different names.
Maybe
Twitter might be a way to reach
some sort of consensus over the labels for this thing.
Another part of
my reasoning for not wanting to create artificially separate categories for SSD
caching, and tiering and other hot spot optimization techniques is that in the
long term it won't
matter what techniques (or mixture of techniques) vendors use as long as they
work effectively when they sit between 2 different speeds of installed SSD
storage. So in the future - calling this type of function an SSD cache or
tiering appliance wouldn't be strictly accurate anyway. | | |
|
. |
|
 |
|
. |
|
|
|
. |
|
| "a flash-based
write buffer needs to be even more reliable than an NVRAM-based buffer,
because it is larger and the overwrite-absorption and re-sorting might make it
difficult to recover the system to a consistent state upon loss.) On the other
hand, a read cache does not ever store the only copy of any data, so it can be
constructed inexpensively without sacrificing reliability..." |
| Umesh
Maheshwari, Co-Founder and CTO, Nimble Storage in his
blog -
Write
Caching in Flash: A Dubious Distinction (January 12th, 2012) | | |
|
. |
|
| sugaring MLC for the
enterprise |
When flash SSDs started to be used as
enterprise server accelerators in 2004 - competing
RAM SSD makers said
flash wasn't reliable
enough.
RAM SSDs had been used for server speedups
since 1976
- and in 2004 they owned the enterprise market. (Before 2004 - flash SSDs
weren't fast enough and had mostly been used as rugged storage in the
military and
industrial
markets - and in space
constrained civilian products such as smartphones.)
By 2007 it was
clear that the endurance
of SLC flash was more than good enough to survive in high
IOPS server
caches. And in the ensuing years the debate about enterprise flash SSDs shifted
to MLC - because when systems integrators put early cheap consumer grade SSDs
into arrays - guess what happened? They burned out within a few months - exactly
as predicted.
Since 2009 new
controller
technologies and the combined market experience of enterprise MLC pioneers
like Fusion-io and
SandForce have
demonstrated that with the right management - MLC can survive in most (but
still not all) fast SSDs.
Now as we head into 1X nanometer flash
generations new technical challenges are arising and MLC SSD makers disagree
about which is the best way to implement enterprise MLC SSDs.
Which
type of so called "enterprise MLC" is best? Can you believe the
contradictory marketing claims? Can you even understand the arguments? (Probably
not.)
And that's why marketing is going to play a bigger part in the
next round of enterprise SSD wars as SSD companies wave their wands and reveal
more about the magic inside their SSD engines to audiences who don't really
understand half of what they're being told. |
|
| | |
|
. |
|
| an SSD ASAP video |
 |
The special effects budget was not overspent on the creation of
this video - which is about various differing views about the
SSD ASAPs market.
But
what this video lacks in production values - it more than makes up for in
terms of conceptual content.
It's nearly an hour long. That's like 2
episodes of the Big Bang or a whole episode of Galactica. Is it really worth it?
I
skipped the boring bits at the beginning - but then I went back later to see who
starred in it.
Is SSD simply a big
cache or a real storage tier? - was moderated by Chris Evans, editor of
the Storage Architect.
Participating
in this discussion were representatives from
EMC,
STEC,
Nimble Storage,
Velobit,
SolidFire and
Virident.
The
discussion ranged from - where's the best place to put SSDs? and which agency
should determine where to put the hot data? The app or the storage system?
Then we get into - is this flash demarcation going to work as short
term tactical or long term strategic? And what's the best choice for your
career if you're worried it might not work as well as advertised?
The
video was posted in April 2012 - but I only saw it in the 2nd week of June.
Everyone
we hear speak is smart and knows about SSDs and acceleration.
But
this is one of those examples of the
SSD Heresies in which
- after a while you realize that you are on one side or the other. ...click to watch video |
| See also:- my shortlist of classic
SSD videos. |
 | | |
|
. |
|
| "Across the whole
enterprise - a single petabyte of SSD with new software could replace 10 to
50 petabytes of raw legacy HDD storage and still enable all the apps to run
much faster while being hosted on a shrunken population of SSD enhanced
servers." |
| the enterprise SSD
software event horizon | | | |
