HPE Storage Users Group

This is well documented by the way. Both in the best practice and port persistance guide.

3.1.3 lifts the requirement for dedicated RC ports, and lets you share host traffic and RC traffic on the same port.

bajorgensen wrote:This is well documented by the way. Both in the best practice and port persistance guide.

3.1.3 lifts the requirement for dedicated RC ports, and lets you share host traffic and RC traffic on the same port.

This is not true I'm afraid, the capability change is the ability to now configure ports on the Hba for either rc or host access, you can't use one port for both a host and rc traffic.(you could have 2 ports for rc and 2 for host, or 1 and 3 etc)

Before, you had to dedicate a Hba to one or the other, but as the 7000 only has 1 Hba slot they allowed you to use the 4 ports for a mix of host and rc ports (this was enabled in 3.1.2), but this wasn't allowed on the 10000 still. 3.1.3 brings in the ability to also do this mix on the 10000 series, but they still can't be shared with disk (initiator) ports.

I am sorry, I misread the notes:

"For HP 3PAR OS 3.1.1 and earlier, the pair of HBAs used for RCFC links must be reserved for exclusive use by HP 3PAR Remote Copy. For HP 3PAR OS 3.1.3 on HP 3PAR StoreServ 7000Storage and HP 3PAR 10000 StoreServ Storage systems, individual ports can be configured for RCFC.

Remote-copy links in asynchronous periodic mode do not have to be dedicated to remote copy, and can be shared with other traffic, but this is not recommended. The remote-copy links in synchronous mode require guaranteed bandwidth over dedicated remote-copy links."

Richard Siemers wrote:
Close... I would suggest:

node 0 port 1 (SAN-A)
node 1 port 2 (SAN-B)
node 2 port 1 (SAN-A)
node 3 port 2 (SAN-B)
--- Call that group SET1, zone hypervisor1 to SET1.

node 0 port 2 (SAN-B)
node 1 port 1 (SAN-A)
node 2 port 2 (SAN-B)
node 3 port 1 (SAN-A)
--- Call that group SET2, zone hypervisor2 to SET2.

Our HP SE has just zoned a new 4-node 7400 as outlined below, which is a perfectly valid configuration but each host is taking 2 ports from each node pair rather than a port from each node.

I raised the alternative configuration that you (Richard) have outlined above which I thought would be preferred but he has come back and said that AO works better with his layout. He was a bit fuzzy about it but said he remembered reading or hearing something on the internal HP grapevine regarding this and is going to get back to me on it but I wondered if anybody might have some insight on why this might be true?

Host1
HBA Port 1
node 0 port 1 (SAN-A)
node 1 port 1 (SAN-A)
HBA Port 2
node 0 port 2 (SAN-B)
node 1 port 2 (SAN-B)

Host2
HBA Port 1
node 2 port 1 (SAN-A)
node 3 port 1 (SAN-A)
HBA Port 2
node 2 port 2 (SAN-B)
node 3 port 2 (SAN-B)

Host3
HBA Port 1
node 0 port 3 (SAN-A)
node 1 port 3 (SAN-A)
HBA Port 2
node 0 port 4 (SAN-B)
node 1 port 4 (SAN-B)

Host4
HBA Port 1
node 2 port 3 (SAN-A)
node 3 port 3 (SAN-A)
HBA Port 2
node 2 port 4 (SAN-B)
node 3 port 4 (SAN-B)

Will be glad to learn something new if it pans out as such. Perhaps it helps consolidate cache to those 2 nodes instead of having the VV cached on all 4.

The concept of a trespass comes to mind, that is EMC clarrion vocabulary for when a node receives a request for a data "owned" by the other node. VV's aren't owned in 3PAR and are usually spread across all 4(or 2,6,8) nodes, which I am sure by the nature of round robin multipath leads to alot of "trespasses" through the 3PAR backplane.

Let us know what he comes back with please.