Tuesday, November 23, 2010

The Morning After

Compellent's big news yesterday generated a lot of traffic and I'm just catching up having otherwise been engaged in pre-sales meetings.  Overall, I think the Compellent marketing crew did a great job and is to be commended for delivering the message globally and in a consistent manner.  And the message seems to have been well received. 


Chris Mellor quoted Chris Evans great in a writeup over at The Register.  I have a great deal of respect for both Chris's but wanted to respond specifically to one key point concerning Live Volume (red font coloring is my doing):

Live Volume will place an extra processing burden on the controller. Storage consultant Chris Evans said: "With Live Volume, as a LUN is moved, the new target array has to both serve data and move data to the new location.  This put significant extra load on the new target. I don't know how many arrays can be in Live Volume, but I would imagine the intention from Compellent would be to have a many to many relationship. If that's the case then I can see a lot of that extra [controller] horsepower being taken up moving data between arrays and handling I/O for non-local data."
Keep in mind that Live Volume is an extension of Remote Instant Replay (Compellent's replication suite) with the ability to mount the target while replication is underway.  In other words, no data is being moved that wouldn't normally be moved during a replication job.  The additional functionality serves IO at the target site by having the target replication device become a pass-through to the source.  The cut over of a volume from one system (array) to a target basically involves the same computational workload as activating the DR site under a traditional replication scheme.  I guess maybe Chris (Evans) is referring to the pass-through IO on the target side being an extra burden but if you consider that the whole point is to transfer workloads then I don't see an undue burden being placed on the target system - it will assume the source role if IO or throughput exceeds the configured threshold anyway.

Like Chris Evans, I can see Live Volume evolving into a many-to-many product eventually, since Remote Instant Replay already supports this type of replication.  In fact, the possibilities are exciting and I'm sure (but not in the loop sad to say) that more enhancements will be coming - personally I'd like to see some level of OS awareness of this movement so that outside events could trigger Live Volume movement.

No comments:

Post a Comment