sync and async replication

[Schmoog]

So I have a two part question...

Part 1) can you have both sync and async remote copy at the same time?

Part 2) if you had two data centers, connected by two 10 gbe private fiber links, one 10km and the other 50km, and were using the built in 1gbe rcip ports, would you feel comfortable doing sync over rcip? Average latency as measured by a windows ping between sites is 1ms or less...

Anybody doing synchronous replication using rcip?

[Cleanur]

Quick and dirty answer is that today sync and async need to be over different ports, typically sync on FC and async on IP.
From memory max latency is 2.6ms RT for sync replication so 1ms RT should be fine so long as it meets your customers SLA's.
Even if latency is low the other thing to watch out for with sync over IP is bandwidth not just wan but the IP ports themselves.
You really don't want the bandwidth to be too saturated >65% as the way the IP stack is handled internally, if the change rate is to high then this can put a lot of pressure on controller resource to maintain sync. So best understand your change rate first.

So yes it's doable and I have customers doing this but there are a lot of variables involved. The vast majority I see are running FC for sync.

[RitonLaBevue]

1) Before 3.1.3 you need to use RCIP and RCFC if you want to have async and sync replication at the same time.
2) You can feel comfortable with such measures.

Ususally RCIP is used for async replication. You can use it for sync replication...

[Patrick]

To test the RCIP latency from the cli

controlport rcip ping x.x.x.x 0:3:1
controlport rcip ping x.x.x.x 1:3:1

From each way on both Storserv's you can get a more accurate number for the latency.

Longer interval testing can be done using the checkrclink command (3.1.3 RC manual page 33).

[Schmoog]

So from a ping, my average latency for each of the rc links is 0.650 ms

I will run a checkrclink when I am back in the office (Friday)

I am a bit concerned about bandwidth, as with 1 gbps rcip that would effectively limit my write bandwidth on sync volumes to 1gbps.

Perhaps the 10gbps nics are in order...

[Cleanur]

The Nics are auto load balanced across each node so total bandwidth will be dependent on the array model and node count 2 to 8 on 3.1.3. But this should only really become an issue if you are doing large sequential writes at the source, which typically most people won't do unless they're restoring data or using the array as a disk based backup target. Either way sync replication probably wouldn't be appropriate for those use cases. If all you have to work with is IP, then unfortunately you need to plan for and work within those limits and in some cases it just may not be possible to meet the Customers SLA's without some level of compromise.

If you're worried about initial sync etc then you could stage it, a remote copy group at a time.

[hdtvguy]

To me IMO Sync replication has well defined use cases where recovery data MUST not be lost and kept lock step with production. At least in my career and industries I work in this is virtually never a requirement, it is a desire. Financial systems and such I can see it being a requirement so that a transaction is never lost. The risks of Sync to me force a real serious evaluation of the requirements vs. desires.

Also to further weigh in the decision is I was told by HP that the best throughput you can expect sustained regardless of number of RC NICs is 125MB/s with peaks upward of 150-175MB/s and based on what we have seen I can say that is true on our V400.