Does a standard 7200 fit for peer persistence ?

[bervon]

Hello experts,

I'm completely new to implementing 3PAR Storeserv and I heading to my first setup of two 7200's that will have to form a peer-persistence couple for VMWare vMSC.
The 7200's are standard, so no optional HBA installed and therefore have two FC hostports per node.
From the load of manuals i've been digging thrue, I think I'm 'a little short' on FC ports to realize the setup.
I've read that peer persistence is only supported with vMSC when using RCFC.
Also, the RCFC link should be dedicated for remote copy so this would mean that I would have just one FC port per node left for production.
Would this still be a supported situation ?
Or do I definitely need the 4 port FC HBA (x4) to be able to get the solution working ?

I hope you guys can help with some answers, which i would greatly appreciate !

TIA for any enlightment !

Berndt

[Cleanur]

Peer Persistence replication is also supported by HP over RCIP, it's still uniform access though so you still require a stretch fabric for the hosts.

From memory though even then you're going to need the additional HBA, as the remote standby FC target ports should be on separate physical ports to the active ports attached to the local ESX nodes. I believe this was a recommendation due to a VMware limitation, but will see if I can confirm later using some notes I took. If that is still the case even using RCIP you'd end up with only a single port per node per site for local production.

Confirmed above is incorrect info based on a rather vague statement in the RC guide, you should use the same N:S:P on each array. So if you use RCIP for repliation (note same max latency figures apply) you will still have 4 x FC ports available per site to host ESX.

[RitonLaBevue]

Usually, we first use slot 1 for host and last two ports of the quad for RCFC.
Ports 0:2:4 and 1:2:3 for RCFC, one per fabric.

[Davidkn]

Peer Persistence replication is also supported by HP over RCIP, it's still uniform access though so you still require a stretch fabric for the hosts.

From memory though even then you're going to need the additional HBA, as the remote standby FC target ports should be on separate physical ports to the active ports attached to the local ESX nodes. I believe this was a recommendation due to a VMware limitation, but will see if I can confirm later using some notes I took. If that is still the case even using RCIP you'd end up with only a single port per node per site for local production.

Confirmed above is incorrect info based on a rather vague statement in the RC guide, you should use the same N:S:P on each array. So if you use RCIP for repliation (note same max latency figures apply) you will still have 4 x FC ports available per site to host ESX.

I've had it confirmed several times now that rcip is NOT supported for peer persistence. There is a doc that lists the remote copy requirements for pp that incorrectly lists rcip in there, but it's referring to synchronous rep in general rather than for pp.

I've investigated this fully in the uk, and the official word from HP was that they would only support it for FC, they admitted the docs were a little misleading but currently it's only FC.

So you will definitely need the 4 port FC card for any pp installations.

[Schmoog]

I think that the bigger issue is that pp requires synchronous replication, and that synchronous over rcip is a really bad idea number 1, and number 2 doesnt merge the fabrics which is also required

[Cleanur]

Agree if you're building a PP environment then you have to support Uniform access anyway so you need FC infrastructure between sites to support all hosts accessing all storage. In which case why wouldn't you use RCFC for the replication ? But if you have a small environment or test/dev etc and limited resource then maybe you don't have the available ports to dedicate to RCFC, it is entirely possible to do this using RCIP. Longer term I would look to add sufficient ports to dedicate RCFC links, but if they weren't factored into the design someone is going to have to pay for them.

See this link for RCIP support on peer persistence (3.1.3), note you need access to SPOCK to view this http://goo.gl/QRUxJC

[Davidkn]

Ah cool, so RCIP support has come with 3.1.3.

The only reason my customer wanted to do it using that was because the FC cards for the 3par are about £2.5k each, and so 4 of those is not an insignificant amount of money, £10k or $17k, especially as they already had the ip links to support it anyway, so could just use the Onboard ports on the controllers.

[Patrick]

As long as the amount of data being sent across the RCIP ports is small enough with 3.1.3 or later it should work.

[Schmoog]

Problem I have (and maybe it's just me) is that bandwidth is only part of the issue.

FC connectivity is guaranteed to be lossless, and also has predictably low latency and jitter.

Jitter and latency can be a major problem if you're doing sync replication. And don't forget that the RCIP links are inherently more latent due to encapsulation, IP headers, etc.

[Davidkn]

Which I guess is why FCIP isn't supported still on sync.