pvlinks using single hba

[Mike OBrien_1]

Does PVlinks support failover to multiple controllers from single HBA? How about for remote boot? We are connecting IBM FAStT (STK or LSI) storage ver 5.4.15 firmWARE with HP_UX 11.11 with HP HBAs (a5158a & a6685a) Driver level b.11.11.09)
firmware 44.12
McDATA 4500 Switches, v 6.01 firmware

[Sundar_7]

I guess you mean a single HBA with multiple SCSI initiators ?

LVM doesnt care as long as it sees the same LUN from both the paths. It cannot differentiate between dual initiators or seperate HBAs.

But then by doing so, you are basically defeating the sole purpose of multipathing:= to eliminate the HBA as the single point of failure.

If the HBA is to go bad, I would think both the SCSI intiators are going to be unavailable and thus all the available paths to the LUN are down.

Remeber, LVM doesnt do any kind of IO load balancing between the PV links.

[Mike OBrien_1]

There are anywhere from 5-100 LUNS as targets on these servers. This is a development shop, so 1 HBA in most servers but multiple paths to disk controller once you hit the switch. We tried zoning HBA, and 2 storage controller ports but vgimport took minutes or longer. When zoned with only 1 WWPN on storage controller and the HBA WWPN, LUNS came right up.

[David Child_1]

If you have more than one path to any device then yes, you should be able to use pvlinks. In your description it is hard to tell what you really have. Generally if you have only 1 hba and 1 storage controller port then you only have 1 path (even if you have multiple switch hops using multiple ports). In this case pvlinks will not work (or any other failover software).

If you do have two or more paths then you should see multiple controller numbers in your disk names. Example;

/dev/dsk/c3t2d4
/dev/dsk/c5t2d4

Both of those might be the same LUN. If after running ioscan;insf you only see one controller number then you only have one path (e.g. cXt2d4). Remember to ignore your internal drives while investigating this.

If you do determine you have two or more paths and you want to add the second path into the volume group as an alternate path (i.e. pvlink) just do the following;

vgextend /dev/vgXX /dev/dsk/cXt2d4 (replace X's with appropriate info). It is very important that you do *NOT* run pvcreate on the second path. If it lets you extend in this way a simple vgdisplay -v on the volume group should now show an alternate path.

David

[Patrick Wallek]

PVLINKs are designed to provide an alternate path in case one path fails. This is done at the VG level. Now if you have a single HBA in a system I don't see how it is possible to have multiple paths to the same disk.

I think the real key here is for you to check your ioscan output and see if you can see the same LUN on the disk array with multiple /dev/dsk/c?t?d? device names. If you do, then you can have alternate paths via pvlinks. If you don't, then you can't.

[Mike OBrien_1]

see diagram....not sure if attaching

[Charbel Bou-eid]

Hi Mike,

As far as I've seen with FC HBAs and FC Disk Arrays (at least HP VA), the Dual Controller config does not create a Multi-Path. The Mulitpathing is achieved with two initiators which are in this case 2x FC HBAs per server. The Dual Controller config is for Redundnacy in case of HP VA and for Redundnacy/Load Balancing for HP EVA. Unfortunately, I do not know much about IBM Storage.

Hope that my understanding of FC mutlipathing is correct.

Regards,
Charbel

[Geoff Wild]

Yes - you can.

For example, I have 4 paths to my disks on 2 HBA's - no reason why you can't have 2 on 1 HBA.

Your HBA is a SPoF - single point of failure. You do have redundancy in your SAN...


Rgds...Geoff

[Bill Costigan]

Yes PV links can work with a single HBA.

The problem you might be having is the way the fastT uses its controllers. Different Arrays work differently.

For example on the EVA a LUN can only be accessed by one controller at a time. Using PV links LVM would see the LUN through both controllers by if it tried to access through the "wrong" one LVM hangs.

SecurePath works by switching the controller that "owns" the LUN. On the other hand, on va7410 both controllers can access the same LUN without a problem. So PVlinks work just fine.

The EMV Clariion is like the EVA in that only one controller is active. With EMCs paowerpath you can access the LUN through either controller however, accessing it through the "wrong" one causes powerpath to switch that controller to the active one.
This takes time and EMC recommends that you pick only 1 path for each LUN.

My guess is that the Fast-T is working similar to the Clariion, By accessing both paths during the vgimport you are forcing the Fast-T to do some kind of reconfiguration of which controllers are responsible for which LUNs. This is taking time and that is why the vgimport takes so long when both paths are included.

[David Child_1]

Yes, as Geoff mentioned, you can have multiple paths using 1 HBA. To do so however you need two targets (e.g. storage controller ports). For the below explaination I will use target instead of storage controller port.

The device controller number in HP-UX (c#t0d0) is partially derived (in a fabric environment) from the switch port ID where the target is connected. This way if you have two targets connected to switch port 1 and 2 for example, even if both are zoned to the same HBA you will get two controller numbers in HP-UX (for example c3td0d0 and c7t0d0).

This of course can also cause problems. Try moving a target from one switch port to another; you will no longer have access to the /dev/dsk/c#t#d# that currently exist on your server. You would need to run ioscan;insf and this would create new device files with new controller numbers. So although WWN zoning allows you to easily move the HBA from one switch port to another without having to re-zone, you will not be able to move targets between switch ports. The zones will be okay, but the system device files will change.

Sorry, I got side tracked.

Anyway, the environment shown in your diagram provides some information, but the real question is are the LUNs you are trying to access from your server assigned to more than one of the FastT ports (e.g. A1 & B1) or are they assigned to only one of those (e.g. B1 only). If you are assigning the LUNs to only one FastT port (target) then you will not get multiple paths with one HBA.

David

[Charbel Bou-eid]

Hi Geoff,

Is your Disk Array an HP EVA? Because the HP EVA has normally 4 ports and therfore you can achieve 4 paths to it via 2x HBAs and HP Secure Path for EVA.

For HP VA, I do not think this is possible, and you need 2x HBAs to have 2 paths only to a particular LUN via pvlinks.

Please note that this is what I've been getting while installing HP VA and I do not know if I'm missing something in the configuration for it to have 4 paths with 2x HBAs.

Regards,
Charbel

[Geoff Wild]

What I have is:

HBA1------Brocade Sw1------EMC FA1
------EMC FA2

HBA2------Brocade Sw2------EMC FA3
------EMC FA4


Rgds...Geoff

[Steven E. Protter]

The point of pvlinks is reliability not peformance.

Your question looks at it from the point of view of a problem with the san switches or other components on the san

The answers look to it from the point of view of HBA failure.

How a single HBA can access disks on two paths, I admit mystifies me. Perhaps its a zoning trick or connector I don't know about.

The reason you want two HBA's is because of what happened to us a few months ago. HBA 0 failed and the san admin hadn't zoned HBA 1.

Results: Unplanned downtime.

SEP

[Mike OBrien_1]

The challenge has been working through active/active FAStT controller with dozens of small LUNS migrated from an older generation storage with active/passive controler with prior systems. Buying a second HBA was not the answer when it is acceptable to have single server outages. However, we wanted to give servers access to the second controller since it is available. Zoning to one HBA improved time to import LUNs but took the second controller away from the system.