Around the Storage Block
1748054 Members
4543 Online
108758 Solutions
New Article
StorageExperts

HPE 3PAR Peer Persistence: Persistent Ports

By Andre Carpenter, senior solutions architect, HPE Technology Services  @andrecarpenter

 

Andre_Carpenter.jpegBack in May of this year, I wrote about HPE 3PAR Peer Persistence v1, prior to v2 being certified and released in July.  With version 2, VMware Storage Metrocluster (or vMSC), Peer Persistence v2 is now a fully certified Fibre Channel-based architecture for use in highly available scenarios in stretch VMware environments.  

It’s a different way for how storage architects and practitioners think about storage in a virtual data centre context and how RPO\RTOS are becoming more and more achievable through such developments. Whilst I will leave that topic for another day, I do want to continue this series of posts with its second part –Persistent Ports.


Persistent Ports. What is it?
In a nutshell, Persistent Ports gives HPE 3PAR the ability for its Fibre Channel (FC) ports to have a different identity that can be switched based on certain failure conditions.

For those familiar with it, NPIV or N_Port ID Virtualization allows a single physical N_Port to have multiple WWPNs attached to it. This is a similar concept to Persistent Ports as it allows the ports to share physical ports on the 3PAR with different identities. NPIV is a requirement in Persistent Ports to allow this concept to come to life!

So the nodes on the 3PAR each have a native identity and a guest identity from a partner node as you see in the figure below. 

Diagram1.jpg 
Diagram 1

Native Host Port identity 0:1:1 on Node 0 also has a guest port identity “1:1:1” which you can see has a Native Host Port Identity on Node 1 – this port which also has a Guest port “0:1:1” which was the Native Identify on Node 0!

 
How does it work?
As I mentioned before, a FC Host Port on an HP 3PAR StoreServ can have both a “Native” and a “Guest” Identity associated with it. The Native Identity is the “Port WWN” that a port has on a given node.

In the event of a node failure, the surviving node takes on the native port identities that were associated with the failed node, this occurs when the WWPN’s of those ports logs into the partner fabric.  So let’s use the diagram I used before to articulate this concept.

Digram2.jpg 
Diagram 2

And a node failure occurs…

Diagram3.jpg 
Diagram 3

Node WWN logs into the FLOGI and subsequently the “Guest Ports” become active” on Node 1

 

Use cases?
Based on my own working experience within the storage world, node failures are a rare occurrence, but they are an occurrence so best be prepared. What is cool here is Persistent Ports is really a virtualisation technology built into the 3PAR and extending virtualization right through to the ports to which the outside world connects into it.

So in a disaster scenario, since the partnering nodes already have the names/identities locked in, so it is simply a “switch-on” operation that happens automatically to enable the identities to become active on the surviving port?  (No trespassing LUNS, or takeover commands here folks).

Is it automatic? Like most controller/node failure operation, it is automatic but the switch happens in a few seconds and is not visible at the SCSI layer.


Requirements and best practices
Here’s the technical fun part: In order for Persistent Ports functionality to be supported you must have:

•    HPE 3PAR OS version 3.1.2 and later only. There is no support on OS releases prior to 3.1.2.
•    The same Host Ports on host-facing HBAs in the nodes in a Node Pair must be connected to the same FC fabric and preferably the same FC switch on the fabric (example: 0:1:1 and 1:1:1).
•    The host facing HBA ports must be set to “target” mode.
•    The host facing HBA ports must be configured for point-to-point connection (no support for “loop”).
•    Servers must be zoned to Node Pairs at all times, This is up and above the standard zoning best practices of Server->Node Pair.  The server HBA must not only be zoned to the nodes in a Node Pair it must also be zoned to the same HBA: Port combination on both nodes in a Node Pair. Do not use Switch port zoning (Hard zoning).
•    The Fibre Channel fabric being used must support NPIV and have NPIV enabled. This is extremely important, hence I opened up this blog post with a reference to NPIV.

Virtualization enabled port connectivity within a node.  Simply magic!

Here’s the official technical white paper on Persistent Ports.

About the Author

StorageExperts

Our team of Hewlett Packard Enterprise storage experts helps you to dive deep into relevant infrastructure topics.

Comments