Around the Storage Block
cancel
Showing results for 
Search instead for 
Did you mean: 

HP 3PAR Peer Persistence: Persistent Ports

StorageExperts

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.

About the Author

StorageExperts

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

Comments
Trickster

The URL to the Persistent Ports White Paper no longer works (404 error).

http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA4-4545ENW

HPEStorageGuy

@Trickster - thanks for pointing that out. The blog post is from 5 years ago, when we were still HP so not a surprise that it's a broken link. I searched the HPE Storage Information Library and couldn't find an updated version. I'll ask the 3PAR team if there is one but don't think there is. I'm also hoping to get the team to write an updated blog post on Peer Persistence. 

Labels
Events
See posts for
dates/locations
HPE at 2018 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2018.
Read more
See posts for dates/locations
Reimagine 2018
Join us at one of the Reimagine 2018 stops and see how we Simplify Hybrid IT, innovate at the Intelligent Edge and bring it all together with HPE Poin...
Read more
View all