EMC’s FAST, take 1. Action!

As you might have read in my earlier blog post, EMC has announced the release of the first version of their product called “Fully Automated Storage Tiering” or in short “FAST”.

Now, to describe the purpose of this technology in a very simple form, we are talking about the performance of your storage and some logic that will help you put those things that need performance on the fastest bits available in your storage environment.

And that’s about as far as we can go with the concept of simple. Why? Because if this technology is to add value, you need it to be really clever. You would almost need it to be a bit of a mind reader if you will. You will want it to know what your application is going to do, and you will want to know where it does that on the most granular level of your storage, namely the blocks on the disks. Or more simply, you don’t want it to react, you want it to behave proactively.

So, let’s start with some mixed news:

FAST v1 is available on Symmetrix V-Max, Clariion CX4 and Celerra NS

As some of you will notice these three platforms have something in common. EMC tried to get rid of using custom ASICs in favor of using commodity x86 based hardware for as much as they could. In the new V-Max you will only find a custom ASICs that resides on the Virtual Matrix Interface controller, and is responsible for the coordination of local and remote memory access.

This swap to x86/x64 and a 64 bit architecture was done on all three mentioned platforms. On its own this is a good thing, but it would also be a good explanation why EMC as of now is not supporting older arrays. EMC is bound to get requests for this new technology for their older arrays like the CX3 or the DMX4. There are two likely options there:

1: It’s not going to happen.

Porting the code to a different hardware platform is a pain. The logic behind it is still the same, but the question is, up to where would you backport it? DMX3? DMX2? Where would you draw the line? Combine that with the fact that not all the newer features are available on the older machines and you can probably imagine that it would be easier to just not make these features available on older arrays.

2: They are almost done and will release it sooner than anyone thought.

EMC has a lot of developers. Chances are they were also working on FAST for the other platforms and will be releasing it in the not too far future.

Since we will be seeing arrays being removed from the product purchase portfolio, my money is on option number one. You won’t have the option of buying a DMX3 within the next half-year. And you can also replace half a year with 1.5 year for the DMX4. Sure, you can get extended support which will add four or five years to the life cycle of your array, but implementing new features for arrays which will not be sold anymore in the near future? I find that sort of unlikely.

FAST v1 will only work on a LUN level.

As explained before, normally your application won’t be updating the data on the entire LUN. Usually you have a few so-called “hot zones” which are just blocks of data are being accessed by reads and/or writes more frequently. An excellent graphical example of this fact is something called a “heat map”. This heat map is created by an (unfortunately) internal EMC application called SymmMerge but fortunately fellow blogger Barry Burke, a.k.a. “The storage anarchist” allowed me to use some images from his blog.

So, this would be the situation in a fairly common environment:

Note that in this image we are talking about actual disks, but the image will also work if we just simply replace the word “drives” with “blocks”. The green blocks are doing fine, but the red and orange blocks are the ones that are being accessed a lot.

The ideal solution would normally be to put the red and orange blocks on a faster medium. EMC would normally tell you that the ideal medium for these kind of blocks would be EFDs or “Enterprise Flash Drives”. And you could put the green blocks on a medium that might not need quite as much performance or the same response times as regular fiber channel drives or perhaps even cheaper SATA drives for bulk storage. Each class of drive (EFD, FCD, SATA) is called a tier, hence the term “Tiering”.

After a redistribution your image would look something like this, where all blocks would be on a storage class that suits their individual performance needs:

Now, probably one of the biggest pain points for a lot of people is that this version of FAST is not capable of doing this on a block level. Version 1 is only capable of moving data on to a different tier on a LUN level. But your database/CRM/BW/etc. normally does not read and/or write to the entire LUN.

The value of policies.

So with this version of FAST you actually put a lot more data on a faster tier than you would actually need to. On the other hand EMC stated that the key value for FAST version 1 is not so much in the fact that you move your LUNs to different tiers, but in the fact that you can set user policies to have the system do this for you. It takes some of the effort involved and handles things for you.

Now, you can create up to 256 different tiers which in its current version allow you to define tiers based on RAID levels, the speed of a drive and the drive type. It should be noted that the tier definitions will differ when using dynamic or static tiering. Currently disk size and rotational speed are not considered when you create a dynamic tier, so a dynamic tier may contain disks of differing performance characteristics, but a tweet from Barry Burke stated that FAST is actually aware of the RPMs, and knows the latency impacts of contention and utilization. Or at least “it will be in the future“

Now, you can create a policy for a storage group, which is basically a group of disks that are managed as a set, and have that policy associate a storage group with up to three tiers, depending on the tiers you actually have in place. Now, combine that with setting limits for the percentage of capacity that is on a single tier and you will see that you could for example say that you want 80% of you capacity to reside on SATA disks and 20% on EFDs.

Fast will now apply your policy and, depending on the choice you made, automatically move the data around across those tiers or give you a recommendation on what would be a sensible choice. It can even relocate you data to a different RAID type on the other tier, and your SymmDev ID, your WWN, your SCSI ID and all external LUN references will remain unchanged during the move. If you have replication set-up, that stays active as well.

Now since this all stuff that might have a performance impact if done during peak loads on your box, the default is that all the moves are performed as lowest priority jobs during time slots or windows that you as the end-user can define. Just keep in mind that you are limited to 32 concurrent moves and to a maximum of 200 moves per day.

What will it cost me?

Prices start at $5,000 USD for the entry-level systems, and will set you back $22,000 USD for the Symmetrix V-Max. But that is the starting price, and the unbundled price. You could also consider a bundle called the “Symmetrix FAST Suite” that includes the optimizer and priority control & cache partitioning. All to be delivered as a “firmware upgrade” for your array.

So do we need to wait for FAST v2?

Well, I’ve got mixed feelings on that point. I can see how this first version can add some value to your environment, but that will depend on your environment. People who only use one tier might not have as much value, and adding the cost of new disks in to the equation will not make it any easier. Especially when we take the release of FAST v2 into account that is “planned for GA in 2nd Half 2010” and will also provide support for thinly or virtual provisioned LUNs and be able to move stuff around at the block level.

I know there is value in this release for some customers that are actually using the V-Max. The automated tiering can at least help you meet a certain service level, but that added value is highly dependent on your environment. Personally, I’d probably wait for the release of version 2 if possible. On the other hand, EMC needs to gain traction first and they were always open about the fact that they would release two versions of FAST, and stated that version 1 would not have all the features they wanted, and that the rest of the features were planned for version 2. I have somewhat of a hard time with some of the analysts who are now complaining that FAST v1 is actually that what EMC said it would be. Did they just ignore previous statements?

To sum it all up

It’s the same story as usual. Every storage vendor seems to agree on the fact that automated storage tiering is a good thing for their customers. Some have different opinions whether or not the array should be the key in this automation, because you are at risk of the array making a wrong decision.

EMC started off their journey with some steps towards automated tiering, but they delivered just that, the first steps toward an automated tiering vision. If we would remove the argument of a price tag, I would be almost positive I’d recommend version 2 too any possible customers. For version 1, the answer is not that simple. You need to check your environment and see if this feature makes sense for you, or adds value to your setup.

Besides FAST we’ve also seen some new cool features being introduced with the new “firmwares” that were released for the various arrays, such as thin zero reclaim and dedupe enhancements. Look for coming posts that will go in too more detail on the new Flare 29 and Enginuity 5874.