« 2.022: free migrations | Main | 2.024: stuck in the middle with hu »

September 22, 2009

2.023: the future of flash is fast

FASTFutureI had the honor yesterday of hosting an EMC Investor Relations "Tech Talk" webcast on the subject of Flash Drives and EMC FAST (Fully Automated Storage Tiering).

Although Chris Mellor scooped me with his second-hand coverage of the event (Chris leveraged a report put out by Aaron Rakers to customers of Stifel Nicolaus Equity Research for his story), I thought I'd share the session with my readers first-hand.

So, if you have an hour or so, pop over to the IR landing page on EMC.com and click the banner link to the recorded webcast (or go directly to the webcast hosting site). But take notice – this webcast will be available on-line only through October 21, 2009.

I also included the net result of the FAST demo that Chad Sakac presented at VMworld 2009 in yesterday's presentation. If you'd like to see the complete demonstration, it's available on YouTube here:

I have also received a few follow-up questions from the event; I'll answer several of them after the break…
 

fast follow-up in a flash

So here are a few questions that came in to EMC IR after yesterday's Tech Talk.

  • I want to know more about alternative architectures which Barry mentioned at the end. Does it make sense to put EFDs in the server (next to the bus) instead of the SAN. Doesn't the SAN become a bottleneck with a traditional disk array configuration?

    As I have long asserted here in my blog, I am convinced that we will see Flash (and other persistent solid-state storage) play an ever increasing role all through the I/O and storage pipeline. We'll see Flash in the servers, in the network and in external storage arrays, both as persistent target storage and as cache devices. In fact, we're already seeing multiple tiers of Flash deployed for different use cases within a single I/O stack, each supporting different use cases or SLA policies…

    As to the common misperception that SAN overheads creates an insurmountable performance bottleneck, I merely point out that intelligent external storage arrays have been deploying the much-faster SDRAM as a cache buffer for slow disks for nearly 2 decades. This even while it is inarguable that the same SDRAM could be more quickly accessed were it in the servers instead. The benefits of storage consolidation and centralized BC/DR will continue to drive IT to leverage external storage, and of course the new performance capabilities of solid-state will ensure that external storage will evolve to maximize the benefits as well.

  • I have some more technical questions about if the replaced drives (those replaced with Flash) are ones that were short-stroked. Does the same story on flash work if there are not short-stroked drives in the array?

    No, in this workload, the fibre channel disk drives were not short-stroked. Instead, the access density of the drives was clearly higher than what these HDDs could support with optimal response times. And in fact, had they actually been short-stroked, they still wouldn't have met the response times delivered by FAST (despite what the wide-striping consortia would have you believe).

  • Following Flash and FAST appear to be the places EMC is driving competitive advantage. I would like a presentation on data warehousing as these new products may open that market to you in a way it was not open before.

    Yes, indeed – deploying FAST with Flash will undoubtedly change the face of not only on-line transaction processing, but data warehouse as well. Especially when we get to the sub-LUN version of FAST, where the hot blocks can be pre-staged into Flash. At that point, it should be less important that database indexes are optimized around the intended queries, because the traditional disk latencies will play an ever less significant role in query latency.

keep 'em coming

I'll be happy to answer any other questions on the subjects of Flash and FAST that I can - even those from the EMC competitor who continues to censor my comments on their blogs (you know HU you are).

So, ask away! Bring it on

Oh, and here's the link to Chris' article on yesterday's webinar, in case you missed it.

 

Another original post by the storage anarchist.


TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834c659f269e20120a5e4c064970c

Listed below are links to weblogs that reference 2.023: the future of flash is fast:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Barry Whyte

Barry,

Is EMC shipping FAST yet? (the whole lun migrate version, like SVC has been able to do for 6+ years - especially now that TPC 4.1. can provide the heat map of your enterprise and generate the commands you need to migrate...)

the storage anarchist

Hi, Barry!

Yes, indeed, manual/scripted full-LUN relocation has been shipping on Symmetrix DMX for almost 2 years, and V-Max since its GA in April.

FAST builds upon this capability by AUTOMATING the entire DECISION and MIGRATION process of what should be relocated where and when. The full-LUN version will ship before the end of 2009.

Unlike your clumsy SVC implementation, which only generates the script commands for you to perform a migration, FAST will automatically decide, based upon policy, what should be moved and then perform the relocation automatically (with optional administrator pre-approval).

And FAST can move anywhere within the array's 64,000 LUNs and 2+PB of usable capacity, changing RAID protection in the process if desired. FAST is thus not limited to the paltry 8000 total LUNs, the restrictive cluster configuration, the complicated zoning requirements or the manual array-based LUN RAID reconfiguration that the SVC cross-IO-Group migrations entail.

Nice try, though.

soikki

Hi Barry,

when will you be able to migrate dynamically provisioned luns on V-Max? Customers see this as a quite important feature.

Barry Whyte

But imagine it was automagic on SVC too, wouldn't that be a whole lot more flexible again, think outside the monolithic box........

And be sure too that when IBM announces something, you can buy it very soon after...

PS. 8192 luns to be pedantic and 8PB addressable

PPS. Careful now, making quotes like 'complicated zoning' and I could mistake you for he Hu knows no better :)

the storage anarchist

Soikki -

FAST for sub-LUNs is coming mid next year...

the storage anarchist

BarryW -

Oh, right. Like IBM is really going to put a single SVC cluster in front of FOUR 2PBu V-Maxes. That's Hitachi Math for sure.

And to be REALLY pedantic, SVC can only mount 4096 2TB MDisks from storage.

Heck, an ENTRY LEVEL V-Max can present more LUNs and hosts and mirrors (and ports and cache) than your largest SVC cluster can handle!

And unlike Hu, I'll cite my source: V4.3.x - IBM System Storage SAN Volume Controller Restrictions.

As to migration complexity, maybe I'm wrong, but the last time I checked there was still a host outage required to relocate a VDisk from one I/O Group to another I/O Group, whether it was within the same cluster or not.

And if you wanted to change the RAID type of an MDisk...sure, you can move the VDisk to an MDisk with different protection pretty easily, but changing the RAID type of an EXISTING MDisk? Surely you won't insult our intelligence and claim you've automated that as well...

Enrico  Signoretti

Barry,
FAST (V1) is an hold feature you can find in HDS USPs and IBM SVC.
It isn't nothing new! Ok, EMCs FAST (next to be released) is better than features released years ago from others but with new limitations (i.e. thin provisioning not supported).

I wrote a post with all my thoughts about FAST limitations and adoptions risks (TCO): http://blogs.cinetica.it/cinetica/2009/09/23/when-fast-is-not-properly-fast/

Of course, i think Compellent has the best Automated Tiered Storage implementation now and I compared Compellent's Storage Center to EMC's V-MAX because I don't know when FAST will be released on CXs!

thank you very much in advance for your answers!

Enrico

the storage anarchist

Enrico -

Thanks for the questions, but your bias has apparently clouded your objectivity. It probably would have been wiser to wait for the answers before you scored the game.

* FAST v1 will be available for DMX later this year as well.

* FAST for CLARiiON CX4 will be available at the end of 2009, or early 2010.

* FAST v1 is indeed designed specifically for full LUNs, which make up well over 90% of the LUNs in use today by Symmetrix customers.

* The #1 customer request for Flash Drives in today's world is that we automate the decision process of what goes onto Flash and what goes onto SATA.

* FAST v2 will provide sub-LUN tiering to V-Max Virtual Provisioning. At that point, we expect many/most customers will move from FAST v1 to v2.

* There are already migration paths to get from full LUNs to VP LUNs, with more on the way.

* FAST policies can be assigned to Snapshots, Clones and remote replicas, in addition to primary volumes.

* And indeed, FAST will be smart enough to keep the remote replicas' FAST allocation aligned with the source so that fail-over can occur without loss of performance.

* On V-Max and CX, RAID type can be changed by FAST as well as disk class.

* SAS drives offer no significant value over FC drives - they cost the same, they use the same power, they're the same sizes, and they deliver the same net performance as FC drives. It is thus rather silly to be using the disk interface as a competitive differentiator.

* And in fact, SAS being so new, it is probably more risky to use a SAS back-end than a FC one. To date, SAS has only been deployed in relatively smaller mid-tier configurations; none of the enterprise-class arrays support SAS today.

* FC is extremely reliable today thanks to years of refinement, while SAS in large drive count configs is immature and the issues have yet to be found, much less resolved.

Enrico  Signoretti

Barry,

- Ok, so DMX customers will have FAST V1 (and V2 too?) and informations reported by other bloggers are incorrect: “the first unique features of the Symmetrix V-Max line”! or, perhaps, my english is worse than i think!
sorry, if i have misunderstood.

- Ok, So is V1 (LUNs level migration) suitable for 90% of your users? because they are not using TP! This answer really fails in convincing me but, at least, is an answer.
I think it can be painful to move SSDs LUNs to SATA, back and forth, if your customers have spent their bucks for SSDs they need them to cure their performance issues, the only way to automagically gain performance and space is granularity!
And, Ok, you will get granularity in a year, more or less. Granularity will permit your customers to not re-layout (or slice) big LUNs in small ones to use FAST (but if your LUNs are sliced you can move them manually to less valued disks and not buy FAST).

- Ok, migration paths: what do you mean with “migration paths”? , I suppose a GUI interface with a “point-and-click” button “convert-lun-from-fat-to-thin-without-pains-and-no-servise-interruption”… or something more complex?

- Ok, so FAST is flawless/limitless about snapshots, clones, replicas and customers will create profiles with integrated relocation of blocks managed by this features… does it mean that FAST will allow to create profiles, for each LUN, or group of, and its related snapshots?

- Ok, SAS has the same value of FC. All storage industry is going that way and you will too!. Other vendors offer this option right now.

ciao,
Enrico

the storage anarchist

Enrico -

Over the last 2 decades, Symmetrix has earned an installed base that is several orders of magnitude larger than all the storage that Compellent has shipped in its entire lifetime. Solutions that benefit the way customers work today are thus extremely important, even as we present them with the new opportunities and benefits of Virtual Provisioning and FAST v2.

FAST v1 thus demonstrates our continued commitment to our installed base.

You will indeed be able to set policies for each LUN, or group of LUNs - which may include the Clones/Snapshots. But we also expect that most will want different policies for their primary LUNs and their local replicas, if only because the use cases (and desired SLAs) will be different.

Rest assured that a lot of attention is focused in this area of FAST policies - with an array that can deliver up to 64,000 LUNs on 2PB+ usable capacity in typical configurations that include tens of thousands of physical and hundreds of thousands of virtual servers, we have to focus on keeping the interface simple and intuitive. Life indeed would be far simpler if our maximum configurations were as limited as Compellent's.

And indeed, the world will eventually transition to SAS. We will also transition to 10Gb Ethernet and FCoE, but there is a very clear value proposition for the latter; I fail to see any value in being "first to SAS".

Thanks for the questions - keep them coming!

Enrico  Signoretti

Barry,
No doubts, You are doing your Job very well!
you convinced me, tomorrow I will buy a V-MAX.
:-D

soikki

Hi, by lun migration I meant just migrating one dynamically provisioned lun to another. If v-max cannot do this (lun migration) now, I wonder when will it be able to do it on sub-lun level.

Hmm on your post to Enrico:
There are already migration paths to get from full LUNs to VP LUNs, with more on the way.

What's this? PPME?

the storage anarchist

You can clone a thin device into a different pool today; thin-to-thin VLUN migrations are coming soon, on a roadmap near you!

PPME or Open Migrator can indeed be used today, as can Storage vMotion, VXFS/DMP and most other host-based migration utilities. And indeed, more methods are coming soon, on a roadmap near you!

The comments to this entry are closed.

anarchy cannot be moderated

about
the storage anarchist


View Barry Burke's profile on LinkedIn Digg Facebook FriendFeed LinkedIn Ning Other... Other... Other... Pandora Technorati Twitter TypePad YouTube

disclaimer

I am unabashedly an employee of EMC, but the opinions expressed here are entirely my own. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.

search & follow

search blogs by many emc employees:

search this blog only:

 posts feed
      Subscribe by Email
 
 comments feed
 

 visit the anarchist @home
 
follow me on twitter follow me on twitter

TwitterCounter for @storageanarchy

recommended reads

privacy policy

This blog uses Google Ads to serve relevant ads with posts & comments. Google may use DoubleClick cookies to collect information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide ads about goods and services of interest to you. If you would like more information about this practice and your options for not having this information used by Google, please visit the Google Privacy Center.

All comments and trackbacks are moderated. Courteous comments always welcomed.

Email addresses are requested for validation of comment submitters only, and will not be shared or sold.

Use OpenDNS