Thanks to Chuck who pointed out to me SVC's ability to move virtual WWNs between nodes during replacement. At some stage in the future I may get to play with SVC but I haven't so far, so this feature eluded me. Question: is SVC the *only* block virtualisation appliance to offer this functionality and is it a seamless operation or does it require downtime?
How about InVista or Incipient (or any other vendor I may have missed off - we will assume USP doesn't have the facility)? Answers on a postcard comment please.
Tuesday, 14 October 2008
Replacing the Virtualisation Component - II
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
"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.
We replaced the Data Path Controllers (7420s with 7600s)on our Brocade Invista Instance without taking any downtime.
@ 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.
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.
Post a Comment