Historic approaches to solving application performance problems were good in their day, but today’s applications can not effectively perform on yesterday’s technology.  On a personal level, try playing COD4 or Crysis on your old single core P4 computer with less than 1GB of RAM and an old 128MB video card.  They just won’t run effectively – if at all – and you won’t realize the true fps potential of the application.  The same principle is true at the corporate level, as well. 

Today’s applications and the volumes of data that they’re able to process need a persistent layer of solid state disk storage.  Without SSD, the applications will labor, and user response, batch processing and/or real-time access to the data will be the casualty.  Attempting to solve these problems with traditional approaches like striping the data across more spindles or adding more cache to the disk array just won’t cut it any longer.  To paraphrase Mr. Obama, “You can put lipstick on an EMC (more spindles and/or more cache), but it’s still a disk array comprised of slow rotating media.” (No disrespect to Ms. Palin intended.)

The answer to today’s application performance challenges is Change.  Change your way of thinking.  Get out of the rut of trying solutions that your Dad’s IT manager used.  “Stand up.  Stand UP!” as Mr. McCain cheers.  Move beyond the limitations of traditional approaches, and use what works:  SSDs.

(Hello.  I’m Barrack Obama, and I did not endorse this blog.)

(Hello.  I’m John McCain, and I, too, did not endorse this blog.)

(Hello.  I’m Joe Biden, and nobody remembers I’m even on the ticket.)

(Hello.  I’m Sarah Palin, and if SSD helps hold back those pesky Russians, I’m all for it.)

First impression at face value may often result in a response being “yes, more is better.”  However, say you are a car enthusiast looking to buy a new sports car to autocross on the track…is simply having more horsepower better? 

Though you could also answer “yes” to the horsepower question, a more appropriate answer in both cases would be “it depends” or “not necessarily.”  If your purpose for the car is for road racing you would also need to consider:  At what RPM band does the car generate its peak HP?  How well does the car handle or use fuel?  What does the power-to-weight ratio, torque curve and lateral acceleration look like? Etc. 

Likewise, if the reason you’re looking for more IOPS is because you need faster response times from your high transaction OLTP application for example, you may also need to look at the app’s I/O Signature.  Are the transactions mostly random or sequential, synchronous or asynchronous?  Or are they accessed in relatively small or large block sizes?

Answers to these questions will no doubt help characterize your application environment, but where are all these high IOPS specs coming from?  We’re pelted daily with specs from storage vendors’ marketing teams claiming high IOPS numbers, some astronomical.  Yet when you evaluate or deploy these solutions, they only perform at a fraction of what their datasheet claimed. Why? The Big “L” for Latency.

On reads, latency is the delay between when you asked for the data until it’s flowing out of the drive. As rotating drives are electromechanical there are two components of latency. The biggest component is the time it takes the read-write head to move across the drive to the proper track (seek latency); the other component is the delay waiting for the rotating platter to move under the head (rotational latency). Both these times are glacial when compared to everything else in the system. Even the fastest rotating drives take .004 seconds on average to deliver the first Byte of data on random accesses.

As we discussed in a previous entry, “Not All IOPS Are Created Equal“, there’s no doubt that if you configure enough disk spindles in an array, you can achieve a potentially high amount of IOPS.  Typically, these high IOPS numbers for disk arrays can only be obtained with an I/O Signature that is very sequential in nature, never random.  Sequential access is really what disks do best, but is not usually the exclusive component of an I/O Signature that most production systems have.  As soon as you put a random “curve” into the mix, performance of these disks tend to fall far below their rated specs.  Therefore, having a high amount of IOPS that can only be achieved under these circumstances will not be better for an application whose I/O Signature requires faster performance for more small random transactions.

DRAM SSDs have always provided the fastest performance of any open storage system technology.  They are the quickest way to retrieve persistent, mission-critical data by providing the lowest access latency from any storage devices available.  Performance is never limited by the access pattern and will perform nearly identically for both random and sequential read or write transactions.  We say SSDs have the speed of memory with more reliability and persistence of disk.  The issue becomes a bit convoluted as disk vendors and Flash SSD vendors try to market their solutions with performance numbers that try to rival DRAM SSDs.  So on paper, they claim more and more IOPS performance to “appear” competitive to DRAM SSDs when in reality, they simply are not.

So if your storage subsystem still has the big “L” on its forehead, it may be time to take The Inside Line to DRAM SSDs…

July 11, 2008 marked Apple’s long-awaited release for iPhone hipsters and wannabes…the new iPhone 3G.  It’s finally here where surfing time on EDGE will hopefully be few and far between.  Being able to finally pick up those new ear buds you’ve been i-balling or downloading a few cool apps at the new App Store is a big plus too…we can talk about the so-called “GPS” later.  If you saw the lines that started the night before or were one of the diehards that were in line, you knew the anticipation was high, almost as much as the first release last year.

So you finally get in the store where you’re able to get your reward.  You go to pick up your new 3G iPhone only to find out that you need to activate the phone in the store before you leave.  As you go through the activation motions, you’ve already figured out the first 5 people you’re going to text/call – but wait, after experiencing failed attempts at activating your new crown jewel, you hear from the store that there’s some glitch with the activation process and the service is down (!!!).  So you wait…”It’s back up again…”  Now it’s down again.  Now they tell you to that you can activate your phone when you get home.  While you’ve been waiting, AT&T already switched your number from your old phone to your new 3G iPhone so you’re starting to feel a bit vulnerable because you have no service in the meantime!  (There are help groups for this…)  So you get home and cradle up your new baby and again you wait…and wait, and wait…and finally after what seemed to be an eternity, an activation signal!  YES, IT’S ALIVE!!!

Could this embarrassing delay in activating your phone have been avoided?  Most definitely.  Many high-transactional service carriers and application companies that have very “peaky” user loads run into this type of situation where an onslaught of simultaneous users brings the application platform down to its knees and, when it happens, it’s critical.  Would having SSDs in place for this activation service have made a positive difference for Apple and AT&T for their 3G iPhone release?  ABSOLUTELY!

Having been involved with various 3G architecture design teams for MVAS providers and carriers around the world, I’ve helped to address these very same types of scenarios in services that require real-time user responses like OTA activation, Identity Management and Real-Time Billing services down to the basic SMS text services.  Implementing SSDs for the backend not only provides the quickest persistent service times to data when updating user’s records, but also provides an enormous amount of additional headroom to the platform by eliminating the excessive queuing, locking and blocking instances of database tables and records created by using slow HDD storage.  Only DRAM SSDs can provide quick enough service times to data, enabling applications that require persistent storage to remain within required millisecond SLA levels. 

Often complex distributed server environments are implemented to “try” addressing these strict SLA requirements, only to find out that heavy reliance on multiple proxy and application servers full of memory tied to a pile of drives in a gluttonous RAID array didn’t cut the mustard.  Had Apple and AT&T implemented a more efficient architecture utilizing SSD technology at Tier0, problems like the one experienced last week and last year would have been mitigated or eliminated.  Can we say “iSSD”? 

In the end, everybody needs their “i’s” checked so problems like this can be avoided in the future but, of course, hindsight even in IT, is 20/20…

Some of the first questions I was asked were very indicative of newbie’s to SSDs: “How much do (DRAM) SSDs cost?”  Followed by “What are the sizes and capacities available?”  My responses were pretty standard: “into the $00′s/GB at list pricing”; and “a 19″ 3U product would have a capacity size of around 100GBs”… “Wow!” one of the guys said.  “You must have a hard time competing with disk…” 

Now if you were at or near this table and were able to listen in on these questions and answers without fully realizing the value propositions that SSDs bring to high-transactional applications, you too may have the same reactions.  Or maybe you’d have initial reactions similar to: “That’s seems way too expensive”; “Why would anyone pay that much for storage, I could buy a heck of a lot more disk for that much money”; or “Only the military and government can afford to spend that much on high-tech storage.”  My humble response to these typical reactions is: “They’re really not as expensive as you might think…”  Really?!

You see, SSDs seem very expensive if you compare them against standard disks based solely on price vs. capacity.  Most people tend to use these metrics for comparing “capacity storage,” but should also realize that other more important metrics should be considered when evaluating SSDs for their value-add.  What most people have not yet grasped about SSDs is their innate ability to provide huge efficiencies of scale to high transactional system architectures.  Integrating SSDs in these system architectures provides a cost-effective alternative to improving the overall performance and reliability of the system platform WITHOUT having to expend large resources in time and $s recoding the application or adding more servers, more memory, more CPUs, more disks, more cache, more licenses and more power. 

SSDs are NOT a capacity play storage device…not by a long shot.  SSDs are purely performance-based and clearly the fastest persistent storage devices available (period).  They sit at the top of the storage food chain at Tier 0 and provide the lowest latency access times to data.   They remove bottlenecks in systems eagerly awaiting a reprieve so that pending CPUs can do what they do best…process lots of data!  What this simply means is there’s a better, more efficient AND, YES CHEAPER way to performance tune and scale your architecture with SSDs than doing it the tired old way you and your uncle have been trying for all these years.

It’s often assumed that increasing the number of spindles in a disk array will get you system performance gains similar to gains you’d get from SSDs. While the random IOPS performance of SSDs can theoretically be matched by striping many rotating drives, big differences in latency (the delay from the time you initiate an I/O until it is complete) have a huge effect on overall system performance and are a key reason to use SSDs.  

In order for disk arrays to equal SSD I/O rates, large server queues must be established using concurrent accesses. This means that in the time it takes for the first I/O to complete, many more I/Os must be issued. For example, if the latency of the disk drives making up the array averages four milliseconds and you need 20,000 IOPS, the server would need to maintain an average queue on the disk array of 80 open I/Os. Often, this is not possible. It may be that the requirement of transaction integrity in the database is in direct conflict with many concurrent accesses. Or it may be that some of the I/Os must be completed and the data processed before the application is able to issue a subsequent I/O. Regardless of the reason, if the queue of 80 cannot be maintained then the 20,000 IOPs will not be achieved. SSDs on the other hand, with as little as 10 microseconds of latency, can achieve 20,000 IOPs with no server queue at all. Another way to look at this is that SSDs can achieve high I/O rates even on synchronous accesses (each I/O completes before the next is issued), while disk arrays cannot. In fact running synchronous I/Os on this theoretical disk array would only achieve 250 IOPS, clearly a Big Difference!

All that glitters is gold

And she thinks SSDs

Are all equal

When she gets there she knows

If her servers are slow

With SSDs

She can get what she came for…

No, my friends, all SSDs are not created equal. We’ve started this blog to separate the reality from the hype.  With your participation, we will challenge the mainstream perceptions and misconceptions of SSDs and illuminate the masses on the role that this technology can play in an enterprise data center.

In general, there are two flavors of SSD on the market today:  Flash-based and DRAM-based.  It is often difficult to have a discussion on one without the other creeping into the conversation at some point.  Indeed, a thread on the differences between these two versions of SSD would be a worthy topic.  Ultimately, though, the core focus of this blog will center around DRAM SSDs and the “Why, When, How and Where” to use them.

So let the banter begin…