Left Hand P4300

[toba_2]

Does HP P4300 support sync replication between two sites.On both sites is the same hardware configuration with HP P4300 and 1GB FC link between this two sites.?

Thanks!

[Uwe Zessin]

Yes, sort-of. They call it 2-, 3- or 4-way replication.

The P4000 technology uses the IP protocol for all communication.
A Fibre Channel link will not help except if you have some boxes that allow you to run IP over FC.

[toba_2]

Do you konw what is diference between P4300 i P4300 Multi-Site SAN storage? I heard that only Multi-Site SAN storage support sync replication?? Whether it is true?

[Uwe Zessin]

sync-replication is (in my opinion) a misleading name and can easily confused with the way that traditional FC storage arrays do 'remote replication'. In reality this is 2, 3, or 4-way mirroring between 2,3 or 4 storage modules. I can do that with physical boxes or the Virtual Storage Appliances (VSAs)

[teledata]

The true "Multi-site" SAN is determined by the way you configure your sites and Virtual IP (VIP)s.

You can simply do 2-way replication (which is synchronous), and place 1 node at site A, and node 2 at site B.

The problem with this configuration is that it takes a bit of time for the SAN/iQ software to detect a failure, and move the VIP over to the other node. This can take several seconds, in chich case your database or email applications will timeout and fail.

Enter the multi-site (also referred to as CAMPUS SAN): Each SITE must have a unique subnet, and you assign a unique VIP for each subnet. Then inside your servers or (ESX) hosts you assign both VIP addresses to the discovery tab. This will now allow your initiator to find multiple unique paths to your storage volumes, 1 at site A, and one at site B. If one of the paths fails the initiator immediately tries the other path. Since there is already an active responding VIP (you don't have to wait for the it to fail-over), you recover connectivity to your storage immediately, and your critical volumes stay online.

You really should have a latency of no more than 2-3ms over the WAN for this to work reliably.

I recently set this up for a customer, and we created both subnets stretched over the WAN, so ESX hosts at both locations, could each use both paths. (we actually setup 2 multi-site SANs, each location has a Failover manager locally, so both locations will maintain their primary SAN in the event of site or link failure).

We were able to verify that either module failure, OR site link failure did not cause a failure of our Exchange server. The multi-site SAN kept serving up the Exchange datastores.

[dan swatman]

Great post :)

We have a similar situation which we are building but I can't quite understand the proper setup.

We have two sites connected via Gbit fiber, site one has three P4300s and site two has three P4300s. The multisite is configured so that two separate networks exist which creates two VIP's one per site. We designate site one as primary. We use Vmware 3.5 with two hosts at each site. The second site is a disaster recovery site.

Your note helped with one thing (pointing the Iscsi initiators on each ESX host to both VIP's) but brings up one question so far which is:

A volume (VMFS) would be available to multiple hosts at the same time which is normal however if the SAN sites are not connected an esx host from site one would not be aware of an esx host on site two which is also writing to the same volume at the same time. A person might say that is not going to happen because the virtual machine assigned to used that VMFS only runs at one site at one time, however a single VMFS might have multiple virtual machines assigned to it thus site one and site two could be writing to the same volume at the same time, I'm not sure how this could ever be reconciled if the sites became connected again?

[teledata]

The VMFS file system inherently protects VMs from running at multiple locations, but that's not your issue here.

The question in your case will be: which site has connectivity to the failover manager?

What will happen in your event, is the site that does NOT have connectivity to the FoM will loose quorum, and connectivity to that storage cluster will fail for those ESX hosts. The VMs will failover to the other hosts at the surviving site. VMs originally at the surviving site will experience no failure (or downtime).

Once site connectivity is restored, the failed site will reconnect, and you could then vmotion the VMs back to the other ESX hosts if you wished.

Hope that helps.

Paul Drangeid
TeleData Consulting, Inc.

[dan swatman]

Paul,

Yes that helps some, I'm still tiring to get an understanding of how the 2 sites interact in my case one site is designated as primary which means the second site could disappear and the first site (Primary) would be fine. In my case with three units at each site the primary designation means that site one has three managers running and the second site has only two thus no FoM issue for the primary site as it does not really need anything else to serve up volumes. So if the connection goes down the first site is fine serving volumes and life is good, however the second site would of course also loose connection to the primary site and with only two managers the FoM would kick in and bring the second site back on line. This would seem to be a situation where both sites would be online serving volumes which could available to the ESX hosts at each site which are no longer aware of each other?

Fun huh? What am I missin?
Thanks in advance for the advice.

[teledata]

Aaah.

Ok, I forgot to do the math. You currently have 3 managers at primary, and 2 at the secondary site.

Link failure means that your secondary site goes offline. What may be an option for you would be this:

Run 2 managers at Production
Run 2 managers at Secondary
Run a Failover Manager on an ESXi server at Production, but have a "CLONE" of that Failover manager VM on an ESXi server at secondary, but powered off.

The Failover Manager would facilitate the manager tiebreaker in the event of a link failure to keep the primary site online.

You keep a failover manager "turned off" at the secondary site. In the event of a site catastrophe (Major failure/power/fire/flood/tornado etc) You can turn ON the failover manager at the secondary site, it will re-establish quorum, and now your secondary site can be brought up as a recovery site.

[dan swatman]

Perfect that makes sense, one follow up question would be why run the FoM on an ESXi since I have production ESX's at each location? What happens if I run the FoM on the production esx at the primary and have the powered of clone at the secondary site sitting on the ESX.