Wednesday, May 20, 2009

EFD Specs

There is a large lack of knowledge about Enterprise Flash Drives, what they can do and what they cant. I for one am one of those with minimal knowledge and understanding. This is some of the information I found at EMCWorld.

An EFD is composed of 16 smaller flash chips, managed by an internal processor with onboard cache

Lifespan - We all know that flash drives have a limited lifespan, is that something I should be concerned with? Supposedly, the EFDs can support millions of rewrites without issue, comporable to that of FC drives.

Performance - A conservative number is 2500 IOPs per disk, and 100 MB/s. These are very conservative numbers and could be up to 10x this.

RAID configurations - You still want redundant disks, just as with FC, SAS, or SATA, so what configuration do you use. All RAID types are available (0,1,5,10), and due to the high performance characteristics, RAID5 is generally appropriate.

READ vs. Write - Read for EFD is considerably faster than Write, but writes are still faster than with traditional disks. This can be improved by enabling the SAN write cache, but it is general practice to leave this disabled.

What are you trying to purchase with your disks? This ultimately determines what type of storage is needed.

SpaceSATA / FC
Response TimEFD
ThroughputEFD / FC

Is EFD a silver bullet for your performance issues? Maybe. It will help resolve many hardware wait issues, but wont resolve all the processing performance issues you may have. You should always make sure and validate where the waits are to ensure this will help.

Time to start using EFDs?

Just went through a session at EMCWorld about using Enterprise Flash Drives (EFD) in Oracle environments. My initial assumption with EFDs was that they were fast and expensive, and only for your biggest databases and workloads did they make sense, now I am starting to think differently. They are still very fast and expensive (I assume, I dont really know the cost), but it may not only be for the biggest and most intensive workloads.

In a database it is best practice to separate workloads onto different disks. The most basic form of this is to put log files on different disks than your database files, but you can also segment your database into multiple files on multiple disks. This way an update to one table wont contend with disk resources for an update to a different table on different disks.

So what does this mean for EFD? Well, if you have a specific table(s) or index(s), that are very busy then you may be able to segment that object onto an EFD, while leaving the remaining objects on FC drives. This way you can have only a handful of EFD drives (i.e. 3 disks in a RAID5 configuration), get exceptional performance, high number of IOPS, and extremely low latency.

Now comes the hard part - how do you identify which object would benefit most from being moved to an EFD? The presenter discussed searching for what is called Hot Tables, or Hot Objects within the database that are waiting for disk resources. Any Oracle DBA worth his salt should be able to identify these using the statspack tool for Oracle. There is a similar tool in MSSQL (I forget the name now) that will give you similar output.

Once I get back to work I expect to try these tools out to identify how some of our DBs could be improved with EFDs. Once I do that, I should be able to properly assess if EFDs would really benefit us performance wise, as well as cost wise.

New Celerra Simulator

In my testing I have used the Celerra simulator quite a bit. This helps me get familiar with the technology and features before trying anything in production. Now, it looks like they have released a new version that has the latest dedupe and iSCSI features.

The simulator can be downloaded from More information on the simulator is available at