Data Center Advisors

Well, leave it to EMC to get me sufficiently fired up to resume my blogging after a lengthy hiatus. Yes, it’s been too long (some might argue too short), but I’m back. Call it a “blogcation” or a “blogaday”. If either of these terms make entry into Wikipedia I’ll take credit. My absence has been duly noted by friends, family, customers, and even some of our competitors!!

But to the topic at hand: EMC’s announcement of the DMX-4. It happened a few weeks ago today and as is customary for EMC, it was great drama and fanfare, but signifying little. Or at least that is how I see it, your opinion may vary, but that’s what these blogs are for – to sort out the controversies.

They announced 4Gb end-to-end support which puts them on par with other storage vendors, so that’s not exactly a reason to interrupt our normally scheduled programming. Along with that was a 30% improvement over DMX-3 (presumably coming from their “new and improved” point-to-point backend), which when compared to our recently announced USP-V really means that we’re only about 3x-4x faster. Nice try.

They announced “Thin Provisioning” to be delivered sometime next year (like InVista was announced well over 2 years ago, also to be delivered “next year”, and still really hasn’t). We’ll see if EMC can pull this one off.

They announced audit log capability through RSA. This is a capability we announced over a year ago (and doesn’t require a “lock-in” to RSA).

They announced tiered storage by allowing SATA II drives to be interspersed within the DMX-4 frame. Now this one sounds like it could have value, but I would think less than appears on the surface, since the primary consumer of SATA II is archiving and even with 750 GB drives, with DMX-4 you’re using up precious drive space behind an expensive controller for data that has little likelihood of subsequent access. I’m personally much in favor of the Hitachi solution that allows you to attach (externally) up to 247 petabyte of this stuff. But I’ll give them some credit for trying to ”re-invent” the tiered storage model that we delivered 3 years ago.  Related to this was the obligatory “green” announcement (no trees were harmed unless you consider the ones now missing from the marketing collateral that is flowing from Hopkington). My buddy Hu recently commented well on this on his blog so I won’t repeat

There were a few other minor things like a faster TimeFinder and a faster SRDF but maybe I’m just not easily impressed. For the most part I found the announcement rather vacuous.

Tweet

Posted in Tech Talk 3 Comments »

Comments (3 )

Post Comment

WB Claus,

So I’ve quizzed Hu about the marketing figure of 296PB of external attach. He’s neglected to post my comments, hopefully you will.

So lets assume all of that 296PB is 750GB SATA drives that can handle about 80 IOPS each. Scaling that up, thats over 31 MILLION IOPs… even if they are only 25% busy thats almost 8 MILLION IOPs. Now just how can you claim this level of support with a system that istelf can only do 3 MILLION read cache hits – especially when the cache isn’t supported on the external attach…. ? Is this marketing figure really something thats worth mentioning in practice ???

Further I understand there is a limit of about 12K IOPS per port, so that would need 660 ports to attach and make use of the 25%… or 2640 ports for 100% use…

What would you say is a REALISTIC external attach capacity?

Firstly, the number is (only!) 247PB of addressing capacity in external storage, not 296PB. That said, we already have customers with many PB’s of external storage and one approaching 10PB and growing and I think that’s pretty impressive. Will anyone ever reach 247PB? Perhaps. With our recently announced “power down” feature of our midrange AMS line, this becomes an archivers dream. That is, growing to PB of external storage is a capacity play, not just an IOPS play. So your IOPS math, although interesting, is based on assumptions that all external storage is “active”. Having all your storage (SAN, NAS, Archiving, VTL, mainframe, open systems, etc.)in a pool of storage managed from a single interface, is quite compelling.

As far as the 3 million IOPS (actually, it’s 3.5 million), you guys should be so lucky!

Claus,

Thanks for the response. I can see the advantage of having a lot of archive type storage attached behind the USP/V controllers, especially with the ‘MAID’ style function. I think the IBM model and HDS model of virtualization is probably closer than flow-through designs which are limited in the services they can provide, and the idea of a virtualizing controller has its merits.

As far as the 3.5 million IOPs, I know this is a ‘super read cache hit’ number – do you have details of the actual number that USP-V can achieve when reading from actual physical cache and not just the front end FC hardware?

IBM choses not to publish its ‘read cache hit’ 512 byte numbers as they are unrepresentative of any known customer workload and so would lead us open to similar comments like “where’s the other 3.3 million IOPS gone” when we submitted our SPC benchmarks. But I can tell you that our true read cache hit (actually from cache) is not that far behind your 3.5 million. Not bad for a commodity hardware with a non-disruptive hardware upgrade strategy

Post a Comment