This article is more than 1 year old

Why are enterprises being irresistibly drawn towards SSDs?

Life in the fast lane

Writer's block

Flash naysayers harp on about flash write limits. Traditional magnetic disks don't have write limits so flash is clearly inferior, they say.

This is both true and utter bunk. Yes, flash has write limits. Yes, magnetics don't. But flash tends to last longer than advertised.

Flash naysayers also tend to leave out the part where traditional magnetic disks have mechanical components that break down and flash doesn't. If you want a deeper dive into that conversation go here.

What matters is not the write life of your flash but how you use it

What matters is not the write life of your flash but how you use it.

We have all heard people talk about using flash for read-intensive workloads. Sure, that's a great use of flash, but it is also the really obvious use. I consider it something of a cop out, especially in a world where virtually all of our workloads are virtualised and we tend not to just cram in one workload per storage device.

Flash works just fine if you are using properly: what ultimately matters is the intelligence of your flash storage device.

To simplify the discussion let's take virtualisation and multiple workloads off the table for a moment and think about one workload to one flash drive.

Let's say you are running a web server on top of this flash drive, and that web server doesn't really do anything all day long except make a whole bunch of sub-1KiB appends to a log file. This is the worst possible workload you can throw at a flash drive.

Flash drives are addressed (read and written to) by most operating systems in pages. A common page size would be 2KiB. However, writes can occur on a flash drive only if you first erase the entire block of pages. In the case of 2KiB pages, expect to have to erase 128KiB before you can write that 2KiB page which contains less than 1Kib of new data.

Each erase/write cycle counts against the write limit of the drive. So the manufacturer could say the flash drive is good for 4PB of data over its lifetime, but you manage to write a fraction of that because you burned through all your writes at low efficiency.

Low write-life efficiency is erasing entire blocks just to commit 1KiB of data. High write-life efficiency is when every write sent to the drive is exactly one block in size.

Because SSDs do wear levelling on the blocks they tend not to overwrite the same pages the original data was held in. What matters is that at any given time there is a full block's worth of data to commit, rather than that the operating system thinks it is over-writing data in full block sizes.

What should be obvious from the above is that many of the workloads people consider read intensive (like a web server) can be pretty bad news for an SSD. This is partly why some people have really bad experiences with SSDs, despite thinking they know what they are doing.

A long and happy life

Fortunately, almost nothing out there today is stupid enough to allow this to happen. Operating systems have become more aware of this peculiarity of SSDs so when they are directly in control of an SSD they tend to save up writes until they have enough to bother erasing an entire block.

Similarly, RAID controllers that are not from before-time-began also know how to talk to SSDs so as not to wear a hole in them. As you move higher up the chain into enterprise SSDs, you find that the individual drives have supercapacitors and thus can do a lot of this directly at the drive level, saving further on wear.

Based on the above, you shouldn't get into trouble with higher-end SSDs, whatever the workload. But depending on the workload, you may not need any of the "smarts" that come in the higher-end flash drives at all.

A virtualisation setup with a whole bunch of virtual machines sending lots of writes to the SSD is actually a great use case. No matter how dumb each layer of the stack is, you are likely to see high write-life efficiency.

Those hybrid and all-flash array vendors selling units based on consumer level flash aren't crazy: if you use it properly, you can get write life even out of consumer flash.

Similarly, it doesn't take much to configure a database to perform its writes at a relevant size. If you are using RAID 1, then you might want to have your database write out at the size of the flash drive's block size.

If you were using a four-disk RAID 6, you might want writes to be two flash blocks wide, as each write by the RAID controller will have to consist of two flash blocks of data and two flash blocks of parity.

Handle with care

If you take a bunch of SSDs and cram them into your 10-year old consumer NAS you may be disappointed in the results.

Similarly, it helps to talk to your enterprise array vendor about the points raised in this article and find out if its units have any intelligence regarding flash write coalescing and write-life management.

A good hybrid array can give you all the speed benefits of flash while also allowing you to house the large quantities of bulk data you need. This helps avoid that pesky not-enough-to-go-round problem.

A carefully deployed all-flash array can make databases and tier-one applications very happy, while traditional magnetic disk arrays will probably still be in heavy use for lesser workloads, logfile servers, backups, snapshots and other cold data.

We shouldn't fear flash, especially where it is used properly. Now if only we could solve that supply problem. ®

More about

TIP US OFF

Send us news


Other stories you might like