EMC’s FAST, take 1. Action!

10 12 2009

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:

    D604D646-5ADE-48F1-8BA5-358D78A5F8C1.jpg

    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:

    F19A5D7F-0D02-4C96-B8D1-85DA8AC79D1C.jpg

    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.


    Actions

    Information

    9 responses

    11 12 2009
    EMC announced it’s Fully Automated Storage Tiering (FAST) – Links « BasRaayman's technical diatribe

    […] Bas Raayman – EMC’s FAST, take 1. Action! […]

    11 12 2009
    Nigel Poulton

    Hi Bas,

    Good article and a very balanced opinion.

    Personally Im sure I see much value for FAST v1. While it may be better than what HDS currently has, I come across precious few uses for the HDS equivalent.

    Sub LUN level *might* be more useful, but Im old fashioned and really hve some issues handing control over to the array :-S

    Nigel

    11 12 2009
    Devang

    Hi Bas,

    Totally fair assessment and good post explaining the details of FAST as it stands today and the technology behind it.

    This will go in the deep-dive section of the StorageNerve Blog….

    Keep up the great work…

    Devang

    11 12 2009
    Bas Raayman

    Nigel, Devang, thanks for your comments and the compliments.

    In regards to being old fashioned, what kind of control do you have right now? You can control things like caching and such, but that is also done up to a certain point. Basically you just let the array do it’s thing and hope for the best, or not?

    Or as another example, take the Drobo. You trust that it just does it’s thing and you can’t be bothered with things like raid levels and such. Wouldn’t you want your bigger array to work in the same way?

    Bas

    12 12 2009
    Nigel Poulton

    Bas,

    Hitachi have had a similar feature for a while (although Im willing to admit that it *may* be inferior to what EMC are delivering with FAST). It wasn’t very useful in my opinion except for planned migrations.

    As for existing control over things like cache – I quite often recommend cache partitions on HDS kit to protect certain applications from write pending issues that occasionally occur. The cache algorithms are smart but definitely fallible.

    For me the Drobo comparison does not work. Drobo is not competing with Symmetrix or even Clariion – worlds apart.

    If EMC can pull it off then I will be impressed. For me, most people these days are looking more and more at solutions that allow you to wide-stripe and then forget. Dare I say XIV :-S And I think they are doing this because they dont need huge performance and are happy for most apps to sit on wide-striped LUNs which touch lots and lots of disks and as a result reduce the number of hotspot occurrences. Oh and of course this works well in places where staff are stretched – very little management overhead.

    Nigel

    12 12 2009
    Bas Raayman

    Nigel,

    I wasn’t referring so much to cache in particular, but more to where you would draw the line of keeping control. Is it only defined by size? Or perhaps the value of the data?

    For me Drobo is a perfect example, because it’s in a sense a data store where you only configure how big the partition should be you want to use and then just forget about it. The Drobo takes care of things like performance, informing you when you need to replace or add a disk, and it even balances the data across your disks for you to increase performance and give you an optimal data protection.

    Why would you allow a Drobo to do that to your own precious data, but not expect the same from an enterprise class array? I would feel highly unconfortable if I had a bigger confidence in my home array than in the thing that we manage at the office each day, sell as high value to our own customers and paid a sum for that could normally buy someone a small appartment or even a house? 🙂

    Bas

    12 12 2009
    Nigel Poulton

    Hi Bas,

    I dont realy like the Drobo example because I just cant bring myself to make comparisons between my laptop with my own data on it and the trading data of an investment bank – I know if I was consulting for one of these banks and made a comparison between their data and my own data on my laptop I would very quickly lose their business 😀

    Put it this way….. I let my wife use my computer – thats the difference 😀

    Im interested to see how it works and what people’s experiences are, and Im not saying it wont work – I just need to be convinced.

    Nigel

    12 12 2009
    Bas Raayman

    Well, it’s certainly an example I would doubt actually works in a customer environment. On the other hand it’s all about perspective. You would use a drobo for your own bulk data, but usually something valuable like photographs, or home made movies or something like that. There’s the emotional value (let’s forget pack rat mentality for a while because that will work against us in both environments) or the actual monetary value of for example trading data.

    But that’s part of my point. It’s part of why we are prepared to pay the steep prices for an array. Vendors will talk to you about CapEx and OpEx, baffle you with ROI until you are ready to hand over huge pile of money. And no matter what the return is, anybody who will tell you that you are getting a bargain for an array that would easily get you a new car or house is just plane insane. The enterprise grade stuff is just massively expensive, be it with good reasons (development, testing, coding and so on), but it’s still massively expensive.

    I can see the difference, and I can see your point, but too me personally… My data is way more important to me on that one array, because that is probably all I have for backup in a home environment. 😉

    By the way, wasn’t it the other way around? Didn’t your wife let you use her computer? 😉 😉

    25 10 2015
    Mapami

    I bought a Firewire Drobo 3 years ago and was ermeetxly disappointed by its performance, and how the Drobo would get disconnected by the Firewire when not active, corrupting HFS+ partition and causing 30+ hour file system checks. Even when it worked, the performance with Apple Aperture was atrocious, and it was unusable for Final Cut.Since then the Drobo Firewire has sat under my desk as a ver expensive brick. I really wanted to by into the Drobo eco-system but my woeful experience of the Drobo Firewire made me via I would never use Drobo products again.The Drobo 5D sounds promising. Maybe I would by it. I will wait for trusted reviews before I do, and probably wait for several rounds of software updates to the Drobo (that never materialized for the Drobo Firewire) before making a purchasing decision.It’s a shame. I really, REALLY wanted to be a Drobo evangelist. But once bitten, twice shy.Paul Adams,Registered Drobo owner, but not a Drobo user.I wou

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s




    %d bloggers like this: