Comments on: Replacing the Virtualisation Component – II http://thestoragearchitect.com/2008/10/14/replacing-the-virtualisation-component-ii/ Storage, Virtualisation & Cloud Mon, 21 May 2012 20:10:36 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Blaese http://thestoragearchitect.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-389 Blaese Wed, 15 Oct 2008 07:25:00 +0000 http://thestoragearchitect.wordpress.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-389 Actually you can accomplish the same thing with any of the Datacore solutions (SANMelody, SANSymphony) if you're running them as high availability mirrors.<br/><br/>You redirect all of your servers to one of the storage servers (regular path management tools) at which point you can rip out the other one, install a new one or upgrade components etc. Once it's back online, and the synchronization reestablished, you do a rescan from the servers which will present the new WWN as a valid path to the LUN and you can do the same thing with the other storage server.<br/><br/>It's not seamless in that there is definitely some planning and work to do, but it doesn't require any downtime. Actually you can accomplish the same thing with any of the Datacore solutions (SANMelody, SANSymphony) if you’re running them as high availability mirrors.

You redirect all of your servers to one of the storage servers (regular path management tools) at which point you can rip out the other one, install a new one or upgrade components etc. Once it’s back online, and the synchronization reestablished, you do a rescan from the servers which will present the new WWN as a valid path to the LUN and you can do the same thing with the other storage server.

It’s not seamless in that there is definitely some planning and work to do, but it doesn’t require any downtime.

]]> By: BarryWhyte http://thestoragearchitect.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-388 BarryWhyte Tue, 14 Oct 2008 19:52:00 +0000 http://thestoragearchitect.wordpress.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-388 @ Chris, Rob and Chuck - I quickly realised it was not EMC Chuck that was singing the praises of SVC...<br/><br/>Pretty much covered, it all - the only thing to clarify is that because we are a cluster of physically independent nodes we can gracefully shutdown each node in turn. While one node is removed from a "pair", the partner goes into flush and then write through mode. All vdisks that have a "preferred path" to the removed node will temporarily be serviced by the failover paths, until such time as the new node re-joins the cluster. Repeat this process for all nodes. We've had a great number of long term SVC enterprise customers perform this action to upgrade many clusters without issue. Because we control the WWN of the "hba" in the node, it is easy to replicate it to avoid zoning changes.<br/><br/>@mark - wau! - care to explain an more details - I'm genuinely interested - and any input you have too on concurrent code upgrades on Invista, I'm all ears - this is the first I've heard that either could be done - and i think the first Invista user that has spoken up in the blogosphere. Welcome. I suspect both of these are EMC service engineer procedures however. @ Chris, Rob and Chuck – I quickly realised it was not EMC Chuck that was singing the praises of SVC…

Pretty much covered, it all – the only thing to clarify is that because we are a cluster of physically independent nodes we can gracefully shutdown each node in turn. While one node is removed from a “pair”, the partner goes into flush and then write through mode. All vdisks that have a “preferred path” to the removed node will temporarily be serviced by the failover paths, until such time as the new node re-joins the cluster. Repeat this process for all nodes. We’ve had a great number of long term SVC enterprise customers perform this action to upgrade many clusters without issue. Because we control the WWN of the “hba” in the node, it is easy to replicate it to avoid zoning changes.

@mark – wau! – care to explain an more details – I’m genuinely interested – and any input you have too on concurrent code upgrades on Invista, I’m all ears – this is the first I’ve heard that either could be done – and i think the first Invista user that has spoken up in the blogosphere. Welcome. I suspect both of these are EMC service engineer procedures however.

]]> By: Mark http://thestoragearchitect.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-387 Mark Tue, 14 Oct 2008 14:17:00 +0000 http://thestoragearchitect.wordpress.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-387 We replaced the Data Path Controllers (7420s with 7600s)on our Brocade Invista Instance without taking any downtime. We replaced the Data Path Controllers (7420s with 7600s)on our Brocade Invista Instance without taking any downtime.

]]> By: Rob http://thestoragearchitect.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-386 Rob Tue, 14 Oct 2008 14:03:00 +0000 http://thestoragearchitect.wordpress.com/2008/10/14/replacing-the-virtualisation-component-ii/#comment-386 "Question: is SVC the *only* block virtualisation appliance to offer this functionality and is it a seamless operation or does it require downtime?"<br/><br/>There are other block virtualization appliances? Just kidding. The "others" are quite limited in comparison, right?<br/><br/>Check out page 894 here:<br/><br/>http://www.redbooks.ibm.com/redpieces/pdfs/sg246423.pdf<br/><br/>(It is an 18 MB pdf)<br/><br/>You can replace SAN Volume Controller 2145-4F2, SAN Volume Controller 2145-8F2, or<br/>SAN Volume Controller 2145-8F4 nodes with SAN Volume Controller 2145-8G4 nodes in an<br/>existing, active cluster without taking an outage on the SVC or on your host applications. This<br/>procedure does not require that you change your SAN environment because the replacement<br/>(new) node uses the same worldwide node name (WWNN) as the node you are replacing. In<br/>fact you can use this procedure to replace any model node with a different model node. “Question: is SVC the *only* block virtualisation appliance to offer this functionality and is it a seamless operation or does it require downtime?”

There are other block virtualization appliances? Just kidding. The “others” are quite limited in comparison, right?

Check out page 894 here:

http://www.redbooks.ibm.com/redpieces/pdfs/sg246423.pdf

(It is an 18 MB pdf)

You can replace SAN Volume Controller 2145-4F2, SAN Volume Controller 2145-8F2, or
SAN Volume Controller 2145-8F4 nodes with SAN Volume Controller 2145-8G4 nodes in an
existing, active cluster without taking an outage on the SVC or on your host applications. This
procedure does not require that you change your SAN environment because the replacement
(new) node uses the same worldwide node name (WWNN) as the node you are replacing. In
fact you can use this procedure to replace any model node with a different model node.

]]>