Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
HPE StoreVirtual Storage / LeftHand
cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practices for Normal to Multi-Site SAN Conversions?

mn_trent
Occasional Visitor

Best Practices for Normal to Multi-Site SAN Conversions?

Hello All,

 

I'm looking for some guidance/best practices around moving from a Regular to Multi-Site SAN implementation.

We have two production clusters connected to a 6 host VMWare implementation.
One with 3xP4500G2 and a 4530 (21,781.51GB @ 75% utilization).  (aka as our 'faster' I/O cluster)
 A second with 3xP4300G2 and a 4330 (25,436.81GB @ 57% utilization). (aka as our 'slower' I/O cluster)

 

The newer units were put into production into a building separated (but network extended) location.

I have a secondary monitoring location on-tap for best practice, etc..  What I'd like to know is:
1) Are there any best practices for migrating PRODUCTION environments from Regular to Multi-Site.
2) Are there any pit-falls folks have noted during this process?


I also have an option of utilizing a 3rd 'bulk' cluster which is already configured for multi-site.  2x 4530s (36,574.84GB @ 0% utilization).  

 

 Would it be wiser to migrate the LUNs from their current clusters to the other two?  THEN convert to Multi-Site?  Or am I being far more paranoid then need be.  

I would of course need to be cautious to migrate LUNs related to their I/O requirements.  But I can account for that.

First post.  Please be gentle.  

1 REPLY
oikjn
Honored Contributor

Re: Best Practices for Normal to Multi-Site SAN Conversions?

hi trent and welcome.

 

As suspected, you are being overly paranoid here, but I think in the world of production SANs, that is pretty much universally a good thing.

 

I would suggest you read the manual or the CMC help section on multi-site clusters so you really understand what is happening and the benefits/detractions.

 

Beyond bandwidth and latency, you have to pay attention to quorum and how it is affected by the complete loss of one "site" or the other.  The only real way is to have a 3rd location that would hold the FOM.

 

That said, if you have two buildings, it might make sense or might not to go to multi-site.  Even if you don't go multi-site, you CAN control the order of the nodes in the cluster to ensure that your data exists physically at both locations even if you decide to use a single site cluster.

 

One drawback on multi-site clusters for you would be that by default, if you define the servers and the nodes at the two sites, the servers will only use the local sites nodes for data access and if you really have unrestricted bandwidth/latency, this is an unneeded restriction.  You should be able to get around this by NOT defining the sites for the servers.

 

All that aside, if you decide you want to convert it to be a multi-site cluster, you simply change the node's site assignment.  This will cause a cluster re-stripe which will consume resources, but can be done online with no downtime or loss of connection to the servers (assuming you have the initiators setup correctly for MPIO).