Around the Storage Block Blog
Find out about all things data storage from Around the Storage Block at HP Communities.

HP 3PAR Peer Persistence: Persistent Ports

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

 

Andre_Carpenter.jpegBack in May of this year, I wrote about HP 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 HP 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:

•    HP 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.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
This profile is for team blog articles posted. See the Byline of the article to see who specifically wrote the article.


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation