<   Previous Post  IBM Information...
Some people are hard...  Next Post:   >

Comments (17)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Trackback

You will of course note that I later corrected my mistake about mirrored writes.<div>&nbsp;</div> But thanks for confirming my points about power wastage and double drive failures in the XIV. <div>&nbsp;</div> Your misdirection of my power observations to a flash drive comparison for the DMX is strange, given the fact that I compared apples-to-apples SATA configurations for both XIV and both Symm and CLARiiON.<div>&nbsp;</div> But then, you underscore the fact that XIV doesn't even support flash drives! Worse, it apparently would require a minimum of 180 of them if it did.<div>&nbsp;</div> And I seriously doubt the XIV will get anywhere near the maximum possible IOPS from 180 flash drives...just like it took you more than the supported number of SVC nodes to get to 1M+ IOPS - how many FusionIO drives per SVC node was that? 4 maybe?<div>&nbsp;</div> I'm sure these points won't be lost on your readers.<div>&nbsp;</div> And while you (and others) seem to want to argue probabilities of double-drive failures, the real issue is that WHEN (not if) a double drive failure does occur, ALL of the data on the XIV array is lost, not just a RAID set or a RAID stripe.<div>&nbsp;</div> To date, nobody has refuted my assertion that the XIV array has no way to determine which LUNs were not yet completely rebuilt. And I'm sure that nobody will - and you can ask your IBM CS engineer to verify that.<div>&nbsp;</div> And oh, sure - you can recover from backups, but you'll be recovering up to 80TB of data - every byte of single LUN - before you're fully back on-line.<div>&nbsp;</div> And adding the SVC with thin provisioning in front of one (or more) XIV arrays only makes the double drive failure problem exponentially worse - then you would have TWO controllers that have absolutely no clue what data was lost. In fact, you might actually have to recover ALL of the data from backups on the XIV before you could even restart a single application on the other side of your SVC (dependent on how many LUNs the SVC was using for its thin pools).<div>&nbsp;</div> You are telling those inquisitive customers all this, right?<div>&nbsp;</div> Seems Marc Farley was more accurate than he intended - you inded can put SVC lipstick on the XIV pig, but it's STILL A PIG!!!

2 localhost commented Permalink

And could you please get your blog software fixed so that it shows normal punctuation characters correctly?

3 localhost commented Trackback

Bloody hell, fair old bit of registration to go through to comment. Anyhoo...<div>&nbsp;</div> "The alternative is to go for something like Invista's approach and provide volume level virtualization with no cache. This doesn't get the best out of virtualization however, as you can't stripe for performance, you are limited to the performance of the single volume."<div>&nbsp;</div> No you're not. With Invista not only can your stripe across multiple volumes but you can stripe across multiple volumes in multiple arrays.<div>&nbsp;</div> "Nor can you perform sub-volume level migrations.."<div>&nbsp;</div> Invista supports sub-volume level migrations.<div>&nbsp;</div> "..hot-spot management"<div>&nbsp;</div> Is granular to the host and array level with Invista.<div>&nbsp;</div> "enhance performance with caching etc"<div>&nbsp;</div> One of those big arguments, but does that enhance performance or just mask performance deficiencies from the hosts? What happens to all the connected hosts when the cache fills up? Do they all suffer from a performance drop off?<div>&nbsp;</div> Bottom line without getting into box bashing, Invista obviously does a hell of a lot more than people realise.

4 localhost commented Trackback

My last comment was corrupted in SVC cache. :)

5 localhost commented Permalink

I am getting details on the recovery from dual failure and will post in due course - I have not confirmed or denied your points Barry. Double drive failures in any case will result in some recovery action as I stated.<div>&nbsp;</div> As for power, I didn't want to get into that due to the 101 other factors to consider. Like DMX license costs, power path license costs, the physical box costs in the first place. Until you weigh up ALL the costs of a box taking one thing and isolating it means you are bound to have found one that that matches the point you are trying to make.<div>&nbsp;</div> As for performance, the proof of concept we just previewed is not an eventual hardware point, its a proof point, that scale out clustered storage devices stand a much better chance of bring the flash performance benefits to the market. I could throw back exactly the same comments about the DMX - maybe 4 EFD's per quadrant - max? I know you SUPPORT 32, but since you brought up maxiumum throughput, maybe 16 for a whole frame? 20 at a push?<div>&nbsp;</div> Zilla,<div>&nbsp;</div> How do you make use of the DMX Snapshot and Replication functions with Invista then? Or do you have to rely on the local cloning (with offline targets until clone complete) and Kashya blades if you do the kind of striping you mention. Last time I looked the extent size was a volume, but I guess I haven't looked at the specs for a while - thanks for the corrections.<div>&nbsp;</div> As for cache filling up, this should never happen, if you have the backend disk capability to match your host performance needs, the cache will stay in a nice steady state. Try and run more capability through the system than the ultimate hardware can cope with (in heavy write situations) and anyones cache will have problems.<div>&nbsp;</div> And yes, the blog corruption is annoying me too - I've reported and am awaiting a fix - it seems to have today stopped letting Firefox comment again

6 localhost commented Permalink

So you admit that a single SVC node can't keep up with more than 4 flash drives? How many is it exactly? 2 maybe? Tell us - exactly how many SVC nodes running on what hardware did it take you to drive 40 FusionIO drives to 1million-plus IOPS?<div>&nbsp;</div> You've been hammering me on this point for months - yet now you won't come clean about your own reality...why is that?<div>&nbsp;</div> Eventually, you'll admit that the point with flash isn't about maximizing the iops off of each drive - that's a metric for disk drives that just isn't as important with SSDs. And in fact, IOPS will always be limited by everything between the host CPU and the physical storage device, and the maximum won't be any better than what you could get using a LOT of hard disk drives anyway. You want more IOPS, you'll always have to add more I/O channels and compute power - there's no magic here.<div>&nbsp;</div> But response time is where SSDs really pay off, and you don't have to max out the IOPS per SSD to reap the benefits of sub-millisecond response times for read-misses. EMC has customers evaluating DMX4's with more than 128 SSDs, and they're ecstatic about what they're seeing, even operating well below the max IOPS that a DMX4 config can deliver.<div>&nbsp;</div> But I have to admit - I have no clue what you're trying to say about cache staying in a "nice steady state" - in my experience, real-world workloads are anything but "steady state", especially when you're running multiple different servers and applications against a single storage array (as is typical for just about every DMX installed on this planet).<div>&nbsp;</div> Eventually, and quite frequently, there will be congestion as multiple applications "peak" at the same time. It is then that an Intelligent Cached Disk Array really demonstrates its value (well, a good one like DMX does, anyway). Lacking knowledge of disk head location and rotational positioning, an external I/O redirector like the SVC has no ability to optimize request queues for individual drives to minimize head movement and response times. Nor can an external device adjust the array's cache strategies to match the changing workloads and the demands of local or remote replication...<div>&nbsp;</div> The only thing I can imagine is that the benchmarks that you run must not reflect the real workloads that storage arrays encounter, and thus they've led you to believe that the world is cache-friendly...but then, you and I have been arguing that point for years!!!<div>&nbsp;</div> SMILEY (because :*) does not work)! (except, oddly, in preview mode?)

7 localhost commented Trackback

SRDF works fine with that. You would create clones with Invista which are full volume mirrors like TimeFinder/Mirror but unlike BCVs can be created on heterogeneous storage. CDP with RecoverPoint is also available and all of it can be controlled through EMC Replication Manager. <div>&nbsp;</div> RecoverPoint is also used in heterogeneous replication such as replication from virtualised to non-virtualised environments. Production might be encapsulated by Invista but DR could be standard mid-range or Enterprise storage. <div>&nbsp;</div> When people say oh but you can not do some of that without RecoverPoint well I have not seen an Invista sold without RecoverPoint in a very long time. <div>&nbsp;</div> As for the cache thing. Well how much cache is there in an SVC node? How many FC ports? The DS8300 can have up to 128GB of cache and what 128FC ports? Beyond volume mobility is there a performance improvement gained by putting SVC in front of a system like that? <div>&nbsp;</div> You will notice I have tried to avoid crazy characters. -Smile-

8 localhost commented Permalink

BarryB,<div>&nbsp;</div> I don't see any admission of the sort. All I will say is that we used just over the currently supported number of nodes. But remember is a node is 1U, plus 1U UPS, so a big difference from 1U to 1 rack/frame. But I may have been -quote- hammering -quote- you for an answer on how many SSDs you can run flat out, purely because you've never answered. Ive even been generous pointing at a similar 70/30 4K workload... but I dont see an answer yet? I guess I never will, as I know what an STEC drive can sustain at that workload and that would be admitting what performance you can expect from a DMX - something EMC dont like to divulge in public *for some reason*...<div>&nbsp;</div> I do, and have agreed that the *general purpose* benefits of flash are the response time, and what you have done with DMX and now CX4 will provide a great benefit to response time as you state. *However* there is another side to this too, and thats the max IOPs side. So if a customer needs low response times, relatively low capacity but very high IOPs then todays storage controllers wont hack it. Thats where we were coming from with Quicksilver. Our customers can see that and the interest has been astonishing, even compared with what Id hoped for.<div>&nbsp;</div> Cache steady state is more about a level of cache fullness. Our algorithms are finely tuned to balance what we know each controller can handle (based on measured metrics in the given environment) and how much we keep in cache. You dont want the cache to fill completely and be in a 1 in 1 out state, as then you are at the mercy of the controller, for entry, midrange this can be bad. For something like DS8K or DMX, that does have disk knowledge, why would SVC behave like anything other than a server? You (DMX) get a bunch of I/O requests and you handle that as best you can. This is no different to a direct attached host. Why would SVC need to care about disk abilities, seek algorithms, etc YOU take care of that as you say, so we are offloading that work to you and your cache... see what I mean?<div>&nbsp;</div> Anyway I seem to have touched a nerve, maybe its my continual nipping at how many STEC drives you can max out... I'd still like to know... but I guess you cant tell me. Maybe its in your Business Conduct Guidelines to not divulge performance information... no response needed.<div>&nbsp;</div> Zilla,<div>&nbsp;</div> Thanks again for the input, I guess the multi-blade approach has some merits, even if cost isnt one of them. <div>&nbsp;</div> Cache wise, yes there is a benefit, think of it as bonus cache in those cases where you have that bit more. DS8K does not support than many host ports, because it doesnt need to (different architecture, we can share ports with different hosts etc as I believe DMX cannot - but maybe you will correct me there too) and if you have enough bandwidth behind the ports you dont need to provide as many ports. More isnt always better. With SVC we can and I do drive the ports to very close to their theoretical limit, there is no dis-advantage to this, its not how much you have, but what you do with it and how well you utilise what you already have. One of the key benefits virtualization itself provides.<div>&nbsp;</div> Anyway, been fun guys as always -smile-<div>&nbsp;</div> PS. Avoided funky characters too -smile wink-<div>&nbsp;</div> <div>&nbsp;</div> <div>&nbsp;</div>

9 localhost commented Permalink

---geeze---<div>&nbsp;</div> I thought I had avoided funky characters...

10 localhost commented Trackback

I make no bones that Invista is not a mid range product and is not priced as such. Invista customers all have large amounts of storage under management. <div>&nbsp;</div> Ah. Bonus cache. Does that go away if we have a node failure? Neh. It does not matter.<div>&nbsp;</div> See what I did there? No funky characters. Most uptight comments ever.

11 localhost commented Permalink

On the power consumption issue: The main point that is wrong in the "anarchist" comparison is that he/she compares x SATA drives on XIV with x SATA drives on DMX. That is not equivalent. DMX with such configuration will perform poorly as compared with XIV. To make a fair comparison, he/she would have to compare systems with equal performance (Disk IOPS). Then the figure would change a lot.

12 localhost commented Permalink

Thx rechden, you make a valid point. I can hear *anarchist* now (he btw) - well how well does it perform - and of course we will never know the comparison to DMX as they won't tell anyone. Not even their customers.<div>&nbsp;</div> Zilla, Anarchist,<div>&nbsp;</div> I've escalated the &amp;HTML issue, as my normal contact is on leave...

13 localhost commented Trackback

Umm...help me here. Explain to me why it isn't fair to compare apples to apples (SATA to SATA) because there's no DMX performance data?<div>&nbsp;</div> At the moment, there is also no XIV performance data - just claims that XIV SATA is as fast as 10-15K rpm FC drives.<div>&nbsp;</div> While we wait for proof of that statement, I'd say it is totally fair to compare XIV SATA to CX or DMX SATA. it's not like a SATA drive is going to magically run faster, just because Moshe says so! There's no such thing as 100% cache hit in the real world, and spindle speed has a direct correlation to I/O response times. Even with lots of cache, sooner or later you WILL have to go to disk...and suffer response times 12-19ms (or longer).<div>&nbsp;</div> And by the way - customers are beginning to realize that XIV SATA isn't really all that cheap - even after all the bundling and discounting. The reality seems to be that it's barely competitive with SATA-based CLARiiONs and DMX's...more marketing FUD from the XIV machine.<div>&nbsp;</div>

14 localhost commented Permalink

Sorry, may be I was too short on my explanation. First of all, we have to consider workloads. I should have said RANDOM Disk IOs, i.e, workloads based on transactions. When you spread the data over 180 disks instead of doing it on 5 or 6, along with high processing parallelism, it is easy to understand that you should get a better and flatter response time. It is just plain queueing theory. That does not include caching at all. The key thing to achieve this is to be able to cut the data in pieces and to dispatch the tasks of processing the chunks to many servers in parallel. Although the service time of each chunk is twice as bigger as it would be on FC drives, the much higher parallelism overcompensate the slower spinning of each drive. The similar approach was and it is used on processors to achieve high processing capacity even using processors with limited processing power. You are right that 180 SATA disks perform equally as other 180 SATA disks of the same type. The key differentiation of XIV is that it is able to always explore the performance of all disks at once. I.e, "keep then all busy all the time"!

15 localhost commented Permalink

I have a few questions<div>&nbsp;</div> 1. If SVC and XIV are such a good play, why does Moshe say the opposite? I have heard him on a number of occasions say that with XIV you will not need/want SVC. It seems that XIV is sold as a solution that does it all. It is Tier 0,1,2,3,4 with all the features you could ever want for the price of SATA and comodity servers. How can you sell a solution like SVC that preaches heterogeneaus storage and decoupling of homogenous features along with a product that claims to be the only storage you will ever need or want in your environment?2. What a few people are pointing out is that SVC is not a very scalable solution for the enterprise. That does not mean that you have not sold it in many enterprise shops, however the limitations are endless. Why would you ever want or need multiple clusters for SV in a single DC??? The answer is marketing spin I am sure...3. While we are talking about Invista, can you (Storage Anarchist) elaborate on how many customers have actually bought this product? I have looked at it, and talked to a number of shops who have evaluated it, and no one seems to be using it. I don't think it is fair to compare the leading storage virtualization product to a product that most EMC sales rep will tell you that you want no part of. 4. Why no mention of Yotta Yotta on this blog? Do you not consider them a player in the SV market? I won't go into the current status of the company or lack of...however the the architecture of their product is infinitly more scalable than Invista or SVC and the potentials of this architecture are almost limitless. I hope they resurface.