Comments on: USP-V and Hitachi High Availability Manager http://blogs.rupturedmonkey.com/?p=397 The greatest storage blog in the world.... Mon, 30 Aug 2010 22:25:10 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Earnest Henderson http://blogs.rupturedmonkey.com/?p=397&cpage=1#comment-942 Earnest Henderson Fri, 05 Jun 2009 01:19:42 +0000 http://blogs.rupturedmonkey.com/?p=397#comment-942 Very nice write-up of this new feature - much more information than Hitachi has posted yet.One quick question or three:  Assuming a condition occurs which triggers a failover to the secondary / passive side, how long does this failover operation take?  In other words, how long before I/O is being serviced normally to the attached hosts from the secondary volumes?   Is this length of time the same for a pair of controllers with 500 volumes vs. 50,000 volumes? Very nice write-up of this new feature – much more information than Hitachi has posted yet.One quick question or three:  Assuming a condition occurs which triggers a failover to the secondary / passive side, how long does this failover operation take?  In other words, how long before I/O is being serviced normally to the attached hosts from the secondary volumes?   Is this length of time the same for a pair of controllers with 500 volumes vs. 50,000 volumes?

]]> By: snig http://blogs.rupturedmonkey.com/?p=397&cpage=1#comment-938 snig Tue, 02 Jun 2009 01:25:21 +0000 http://blogs.rupturedmonkey.com/?p=397#comment-938 Chris, thanks for all the great questions.<br /><br />100% availability is a much easier task today with the server virtualization platforms and all they can do.  I can't remember the last time I built a solution without multiple NICs, HBAs, switches (FC and IP), and so on.  The only thing that wasn't really viable from a technology standpoint was the disk subsystem without having to write a ton of scripts and depend on people to update them when changes were made.  Well with HAM, it seems, that HDS has removed that from the list of issues.<br /><br />As far as working to an existing TrueCopy site, I don't see why it wouldn't work.  I've been told that HAM will work at TC Sync distances and will be able to use HUR for a tertiary site as well.<br /><br />Active/Passive is correct, but as with any clustering technology it takes additional work if you want Active/Active.  Nothing really has changed there.  They haven't reinvented clustering, just made it available on their subsystem.<br /><br />"Failover" is addressed in this bullet:<br /> <ul> <li>When I/O’s fail to all P-VOL owner paths, alternate path software issues I/O to the non-owner S-VOL paths.  Storage controller stops the copy of cache data and the S-VOL becomes write enabled.</li> </ul> So the host will handle that failover.  At first HDLM and then other failover software will follow.  The decision will be made based on the same criteria it is today.  A path goes away and times out would be my immediate assumption.<br /><br />The RAID group scenario is an great question.  I don't know that answer.  Thinking through it outloud though it seems to me that you would be able to failover only some LDEVs since you can do that with TC.  But would we have to failover the entire consistency group?<br /> Chris, thanks for all the great questions.

100% availability is a much easier task today with the server virtualization platforms and all they can do.  I can’t remember the last time I built a solution without multiple NICs, HBAs, switches (FC and IP), and so on.  The only thing that wasn’t really viable from a technology standpoint was the disk subsystem without having to write a ton of scripts and depend on people to update them when changes were made.  Well with HAM, it seems, that HDS has removed that from the list of issues.

As far as working to an existing TrueCopy site, I don’t see why it wouldn’t work.  I’ve been told that HAM will work at TC Sync distances and will be able to use HUR for a tertiary site as well.

Active/Passive is correct, but as with any clustering technology it takes additional work if you want Active/Active.  Nothing really has changed there.  They haven’t reinvented clustering, just made it available on their subsystem.

"Failover" is addressed in this bullet:

  • When I/O’s fail to all P-VOL owner paths, alternate path software issues I/O to the non-owner S-VOL paths.  Storage controller stops the copy of cache data and the S-VOL becomes write enabled.

So the host will handle that failover.  At first HDLM and then other failover software will follow.  The decision will be made based on the same criteria it is today.  A path goes away and times out would be my immediate assumption.

The RAID group scenario is an great question.  I don’t know that answer.  Thinking through it outloud though it seems to me that you would be able to failover only some LDEVs since you can do that with TC.  But would we have to failover the entire consistency group?

]]> By: Chris M Evans http://blogs.rupturedmonkey.com/?p=397&cpage=1#comment-937 Chris M Evans Mon, 01 Jun 2009 08:07:57 +0000 http://blogs.rupturedmonkey.com/?p=397#comment-937 Snig,   Good post, but it raises even more questions.  Firstly, 100% availability in an array is no use if the remaining components don't also offer that same redundancy; servers, switches, IP network and so on.  That's not easy to achieve and not cheap and therefore there will be few customers who need that.  Migrating from one array to another after a 3+ year cycle is rarely done without some level of re-stacking or re-organisation.  H-HAM doesn't help in that scenario. Does this configuration operate in a remotely replicated scenario where TrueCopy is already being used to another datacentre?  I doubt it will. Surely those customers who crave 100% availability also want the array to replicate to another location synchronously too? This configuration seems to be active->passive and only active->active if you configure some LUNs for a host to work in each replication direction.  If so, then there's extra management overhead required to make this work. You describe the process of "failover".  What instances this?  The host, or the array?  How does the multipathing software determine the primary volume is none responsive and make the decision to fail over? What is the process of re-establishing the failback after an outage/issue on the primary array?  Is this seamless? If a failure in a RAID group in the primary array occurs, can only some LDEVs be failed over to the remote array? I could go on, but it's getting tedious.  My point is that claiming 100% availability is a big statement; it means both failover/failback are 100% seamless.  Chris Snig,
 
Good post, but it raises even more questions.  Firstly, 100% availability in an array is no use if the remaining components don’t also offer that same redundancy; servers, switches, IP network and so on.  That’s not easy to achieve and not cheap and therefore there will be few customers who need that. 
Migrating from one array to another after a 3+ year cycle is rarely done without some level of re-stacking or re-organisation.  H-HAM doesn’t help in that scenario.
Does this configuration operate in a remotely replicated scenario where TrueCopy is already being used to another datacentre?  I doubt it will. Surely those customers who crave 100% availability also want the array to replicate to another location synchronously too?
This configuration seems to be active->passive and only active->active if you configure some LUNs for a host to work in each replication direction.  If so, then there’s extra management overhead required to make this work.
You describe the process of "failover".  What instances this?  The host, or the array?  How does the multipathing software determine the primary volume is none responsive and make the decision to fail over?
What is the process of re-establishing the failback after an outage/issue on the primary array?  Is this seamless?
If a failure in a RAID group in the primary array occurs, can only some LDEVs be failed over to the remote array?
I could go on, but it’s getting tedious.  My point is that claiming 100% availability is a big statement; it means both failover/failback are 100% seamless. 
Chris

]]> By: Tony Asaro http://blogs.rupturedmonkey.com/?p=397&cpage=1#comment-936 Tony Asaro Fri, 29 May 2009 13:53:15 +0000 http://blogs.rupturedmonkey.com/?p=397#comment-936 Snig - great analysis. I agree that High Availability Manager is extremely useful for data migrations and for companies that want 100% uptime. One of the core tenants of any technology is to automate otherwise mundane, complex and error prone manual processes and that is exactly what this has done. I've spoken to the Hitachi field on this and it is a no-brainer for them - essentially reinvents data migrations in the Enterprise and offers a 100% application uptime option. Snig - great analysis. I agree that High Availability Manager is extremely useful for data migrations and for companies that want 100% uptime. One of the core tenants of any technology is to automate otherwise mundane, complex and error prone manual processes and that is exactly what this has done. I’ve spoken to the Hitachi field on this and it is a no-brainer for them – essentially reinvents data migrations in the Enterprise and offers a 100% application uptime option.

]]>