Continuous Access warnings (Port based vs. Exchange based routing policy)

[Brian Proteau]

We are evaluating CA for a client. We are using the evaluation period to move production Virtual Disks from one EVA to another.

Setup: 2 EVA6100 arrays. 2 HP Storageworks 4/64 switches. These switches are independent for redundancy only. There is no ISL link between them.

Issue: We started receiving these warnings during the initial full copy.

(a) Excessive out of order message rate on the inter site link
(b) Excessive data exchange retry rate on the inter site link

I understand these are due to the switches set to use Exchange based routing policy rather than Port based routing.

Questions:

(1) Since we are only evaluating, and only moving one Virtual Disk at a time, is it safe to leave the switches at Exchnage Based routing until we can get approval to make the policy change?

(2) Regarding the policies, I want to make sure we're talking about efficiency in regards to the replication and not the integrity of the destination Virtual Disk. That is, can I trust the destination Virtual Disk.

(3) I plan to power down the server, Verify Command View says the Virtual Disk is synchronized, unpresent the source VD, present the destination VD, and power the server back up.

I'm trying to make absolutely sure that replicating with Exchange based policy, although not ideal or most efficient, will still replicate the VD accurately and I can trust the destination VD.

[Víctor Cespón · Accepted solution]

Hi, Continous Access is currently only supported in "Port Based Routing" mode.

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00590193

Having the switches with the default "Exchange Based Routing" setting generates those messages on the event log.

It works, but it's unsupported, I've seen many customers with CA wrongly set that way for months, until they call for an unrelated incident, we request controller event log, and see that they have those warnings.

[Brian Proteau]

Thanks. I have seen that supportability document and I understand that you can't condone an unsuported configuration.

Can you verify if the policy change is strictly realted to performance and efficiency and not replicated VD integrity?

You say it should work so, I am thinking I would schedule the switch policy change during our maintenance window.

However, by then I would have moved 5 or 6 production virtual disks (1 each day) with the current Exchange based policy. I just was looking for definitive answer that it will work in this configuration on a temporary basis. Again destination VD integrity my main concern.

[Urban Petry]

regarding question 3: don't forget to failover the DR group! So the steps should be:

1) power down server
2) verify DR group is in "normal" state (that is: remote data is up-to-date)
3) unpresent the source VD
4) failover the DR group
5) present destination VD
6) power up the server

You can omit step 3 and perform step 5 before starting the test because the EVA will allow access to a VDISK only on the "source side" of the DR group (so you can have the source VD and target VD presented to the same server at the same time). This minimizes the required steps for failover even further ...

[Brian Proteau]

This is a one time EVA to EVA migration rather than a failover test. Instead of failing the DR group over, I'm just removing the member (and the DR group) once source and destination are in synch (keeping source and destination VDs in tact.

Then I'm unpresenting source and presenting destination. I'll keep source for a day until I'm comfortable everything looks fine.

Thanks for the advice. I'll probably test failover after these migration tests.

[McCready]

One more thing to add is to remember to set the destination read/write, which you are probably doing already anyhow.

However, going forward, I would not expect anyone to fully endorse the Exchange-based routing setting to replicate your VDisks, as (although unlikely) you may run into issues where you end up confusing your EVA, which (with an older, V5 xcs code) required us to reboot one of our EVA's with a similar issue

[johnCatBE]

Brian

Was interested to read your remarks here...We had a similar experience on EVA8100, whereby the provocation of the CA out of order messages and excessive retry rates was coincident with our introducing a second non-trunked isl (LW, sinsgle mode).

The two EVA's were in a campus location, about 1km apart.

On a single LW 2Gb connection between physical locations - everything ok. When we introduce a second (non-trunked) ISL at 4Gb LW, the messages arise.

However, we were using Port based routing , after having been given some erroneous advice and resetting from the default of Exchange.

We'll reintroduce port based routing and have another go at using the second ISL.

Thank you for your post - it's helped clarify our own position. I was under the impression that Exchange was ok (albeit not supported).

John

[Brian Proteau]

I did continue through the disk realignment with Exchange based routing and just lived with the messages since our CA use was strictly for this work and the client never agreed to make the policy change. It was going to require switch reboots to take effect.

I spoke to several HP engineers and they said it was due to the switch routing policy setting. What I gathered from their explanation.

1. Exchange Based Routing policy is apparently not ideal for CA replication. The hash it uses to determine source and destination ports changes more than is necessary causing these excessive retries.
2. For Continuous Access, HP recommends Port Based Routing policy. This policy tends to stick to the same replication port reducing these retries.

From what I understand, this policy is more about speed and efficiency and not data integrity but, HP would not commit 100% to this statement.

He also sent me this document explaining the different policies. If you scroll down to Page 13 on the PDF document, the Port Based Routing Policy is briefly explained.
Also on Page 16, the Exchange based routing is explained.

[Tux_1]

Hi,

I have done with following settings on the Brocade Switch,

a) Port Based routing should be on
b)In-order delivery should be on as well
c) Dynamic Load sharing should be off.

but still getting "Excessive data exchange retry rate on the inter site link" errors.. very frequently.

[Brian Proteau]

In my case, I only used CA temporarily to facilitate a disk realignment and just lived with the errors.

It was a while ago but, I vaguely remember specific cabling requirements to the switches which may be related,

I don't recall exactly since we we'ren't moving forward with it but, you might have a look at this guide:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01800459/c01800459.pdf