Why do I need SecurePath for HP-UX???

[Marc Dijkstra]

Hi all,

This is from the HP marketing "In the event that a path failure is detected, Secure Path for HP-UX fails over to an alternative path. When the original path becomes available, Secure Path for HP-UX can automatically failback to the original path. "

My issue is that LVM with PVLINKS does that for me!!! Is the securepath software there because the EVA is not as robust as the VA and it NEEDS this, or is this a money making scam.....?

If I do not need loadbalancing etc. and I JUST want path failover, why on earth would I need to add another (very expensive) piece of software when I have LVM??? HP say I have to have it....

Thanks,

MND

[Vincent Fleming]

PVLinks support for the EVA product line is coming - it's due in 6 to 12 months.

We heard you. We're working on it.

-Vince

[Claudiu Schmidt]

Hi Mark,

that wa exactly the same question we had to HP.
And the problem is, EVA has a active passive configuration of the controlers, so if one controler is defect, the second one will take over the io reaquests.but if the cable to the active controler, or the switchport is down, the second controler will NOT take over , so all io's will hang.
The Secure Path software monitors all path's to the EVA, and if one gets down, he will automaticaly switch to the second path.

Rgds,

Claudiu

[Spike Burkhardt]

Marc,

There is no technical reason you need Secure Path. To be blunt, I really have a bias against Secure Path. On our SunFire 3800's, we bought the dual HBA's and Secure Path and it hasn't helped one bit. Since I/O performance on those systems isn't heaving load balancing isn't an issue. Installation of the software is easy but configuration is not. It isn't just a matter of running the configuration utility(spconfig) and if the HBA fails Secure Path switches over to the other HBA.

It would also appear that Secure Path for HP-UX might be a secondary platform. We've had 3.0b for several months but I see that(I forget where) the release of 3.0b for HP-UX is delayed, it would seem to me they are having problems.

On our Solaris machines, we are about to try out Veritas Volume Manager with their DMP(Dynamic Multi-Pathing). I suspect we will have much easier time of management and updating. I hope this helps.

rc

[Alzhy]

Spike,

You can'nt avoid using SecurePath on Solaris machines if you're using HP/CPQ EVA/Storageworks disks. DMP from Veritas works only if the LUN's can present themselves with different serial numbers..

It will be good if all HPQ SAN/array disks will be compatible with DMP like software -- ie. Veritas or work with LVM with PVlinks...

[Marc Dijkstra]

Thanks for the replies all.... seems I am not the only one that has queried this with HP?

Vincent, please could you clarify (from what Spike and Nelson submitted) that it is only the HP PV linking (veritas based) that will be supported, or will the Veritas DMP also be supported without having to purchase the Secure Path addon?

I have been working almost solely with the HP FCXX/VAXXXX range, as well as "3rd party" storage subsystems (LSI logic etc.) and have not encountered the need for additional software for multi-path driving on HP-UX before, that is why I was a little confused.

MND

[Vincent Fleming]

Marc,

Actually, Claudiu is the correct one. Veritas DMP cannot be used because it assumes that the LUNs are active on both controllers at the same time.

The EVA controllers employ an Asymmetric Active/Active failover schema. This means that any one LUN is actually available on only one contoroller at a time. Because of this, the path failover software needs to be a little different - should a *path* fail to the controllers (as opposed to a controller failure), the path failover software needs to tell the EVA that the path failed so it can move the affected LUNs to the other controller.

Since Veritas DMP is a generic product, it does not know how to "talk" to the EVA, and cannot perform this function. The same goes for PVLinks today - HP is adding some more intelligence to PVLinks so it will "talk" to the EVA when it needs to.

The VA7000 product line does not work this way, which is why it doesn't need special path failover software - the VA allows access to all the LUNs through both controllers at all times, so there is no need to "tell" the controller that a path failed.

Compared to 3rd party products - some work line the EVA (ie: EMC Clariion), and some work more like the VA.

You could easily get into a "religous" argument about which is better or worse, but to me it doesn't really matter. It is what it is, and both methods of path/controller failover work equally well if the product implements it well. (ie: as long as it isn't buggy).

Good luck,

Vince

[Zeev Schultz]

By the way True64 doesn't require SecurePath
for EVA,it uses some of it's fs capabilities (True cluster or whatever they call it).I thought it would be merged into LVM/vxfs - else so pv links would become obsolete?

And second Vincent says:
--The EVA controllers employ an Asymmetric Active/Active failover schema. This means that any one LUN is actually available on only one contoroller at a time. Because of this, the path failover software needs to be a little different - should a *path* fail to the controllers (as opposed to a controller failure), the path failover software needs to tell the EVA that the path failed so it can move the affected LUNs to the other controller.

This is bizarre,you have 2 switch links to every controller,making it 4 to each lun (what I saw from sp ,one is Active,One Available,2 are standby?)So the IO balancing is all about
distributing total access between controllers,
like if I have 4 luns - 2 on controller 1 and 2 on controller 2?

Zeev

[Derek_31]

Vince,

Back to the EVA for a second. So are LUNs distributed between the two controllers for load balancing purposes? Or is one controller really 'in charge' of all LUNs? It sounds like both controllers host active LUNs, but the LUN is only served up by one controller at a time and Secure Path can tell the controller to move the LUN should a path fail?

[Claudiu Schmidt]

Hi Derek,

on the EVA you can let the EVA alternate the presented luns between the controlers, or you can manualy choose which luns to belong to which controler.so you can load balance manualy, or you can let the EVA do the load balance. But the manual path selection is just a prefered one, EVA can change this, when seeing some bottleneck.
If you don't use Secure Path, you can only use the 2 path to the controler in charge of the lun.


Rgds,

Claudiu

[Zeev Schultz]

From page 90 of SecurePath 3.0b on HP-UX guide:
"When Load Balancing is enabled, the Secure Path driver attempts to use all the
available paths to a LUN in a round-robin fashion."Of course it uses one path at a time.

http://h18000.www1.hp.com/products/sanworks/secure-path/documentation.html#HP-UX

Regards

[Rob Gill]

I understand the technical reasons for having to have Secure Path for HP-UX, I just don't understand why we (the customers) have to pay for it.

It should be free for HP-UX as you don't need it for Tru64 or VMS (both now HP products). So why do HP charge for their own O/S to use their own storage system?

It's a damn cheek if you ask me.

Rob

[Zeev Schultz]

imho (I'm not a specialist to true64 or ovms) they already have a capabilities provided by
securepath coded inside.I also think it'll come
(sooner or later) in the next hp-ux versions.

[Chris Richardson_1]

Vincent, your description of EMC CLARiiON and DMP are both incorrect. CLARiiONs do allow DMP to work and DMP can be configured in an active/passive mode.

So does HPs inability to provide this functionality stem from a lack of cooperation with Veritas to create the ASL for the EVA? Because Veritas provides many ASLs for arrays that use an active/passive configuration.

And the latest patch for VxVM 3.5 for HPUX 11i includes the addition of support for active/passive configurations.

[Ronald Hendriks]

Lets sched some light on your SecurePath Paths :)

After i make the remark to the HP guy who calls TRU64 true64 :) ....


Function of secure path software.

Securepath provides path verification, anti trashing and failover capabilities.
As traditional EVA/HSG80 controllers are not aware of path failures, securepath polls these paths by a ping (option setting). Otherwise securepath verifies a path by an I/O failure.
If a path failure accours, SP will use a different port on the SAME controller first (so no controller failover, just a path switch). When a controller dies (or the access to it), a lun will be brought online to the other controller within a specified time (HS_service enhances scsi time out for OS to allow gracefull failover). As this needs to be communicated, it is a part of the SP software. Thats why pvlinks doesnt work.

SecurePath also is able to hide luns to the OS (like windows), and only displays 1 in stead of 4 luns.

Loadbalancing is in 3 flavors depending on the OS (windows has 3 (round robin, least I/O, Least bandwidth). However, loadbalacing works on one controller at a time (otherwise you would have to failover controllers every second). It is determinate by the SPagent and is per HBA (not per controller)

So if you want redundant access to a MSA, HSG or EVA, you need SecurePath

(SP is embedded in OVMS and TRU64)

[Mike Naime]

Actually, on the old Compaq side of things. (Pre HP merger) Securepath is part of the Alphaserver firmware. The Alphaserver hardware was designed to boot from SAN devices as part of the firmware/hardware. Not as an added layer on top of the OS.

You have "WWIDMGR" that is a Console level firmware command that allows you to set your boot LUN. It allows for Multi-pathing.

On top of this, you can put VMS, TRU64, or any other OS that will run on the Alpha chip.

I can have several different servers/clusters booting from the same HSG/EVA controller. Each of them might have a different LUN that is presented through a different primary port/path from the storage controller.

Both controllers are Active/Active. If you do a SHO UNIT FULL on the HSG, you can see what LUNS are active on which controller. In the case of a controller failure, the LUNS will be transfered from one controller to the other controller.

In the case of a failure in your fabric itself (SAN switch or Fibre cable failure) you have to have some mechanism for both the HBA and the storage controller to fail over.

With all that said, lets look at the hardware in question. HP UX server and an EVA. Not something that was originally designed to work with each other. Therefor you need a layer on top of your OS to make it work.

Is LMV and PVLINKS a layered product? (Not part of the original OS release)

[Marc Dijkstra]

Thanks for all the replies, glad that this has started some good discussion.

Just done an install on HP-UX 11i with SP v3.0C (had 3.0A and have never seen a HP crash so badly when trying to create volume groups!)

Must say that it works a treat, but still don't know why on earth I would need it.... ;) Must be that I am from the "old" Unix school and like to have as transparent a system to my hardware as possible, don't like not having the control, say from a simple ioscan, to see what I have in the box.

Yeah, PV and LVM are layered, just used to them I guess, also when a path fails, one is used to seeing this immediately in the logs and events, did not get this from SP when I yanked cables...

Hopefully this will either be in-the-os without paying mucho $$ or they will standardise on LVM/dmp.

MND

[Spike Burkhardt]

Marc & all,

This is a great thread. Technically there's really good information and exhibits the problems we system admins have to go thru. Marketing hype versus reality. With what we learned yesterday about SP being in firmware on OVMS & TRU64 it's almost enough to make those systems marketable again!

Just to let you all know, the very same questions are being asked on the Solaris side :)

spike