Alternate Links from Mirror UX

[FERNANDO PROIETTO]

Hi All,
I have a question for those of you familiar with using Alternate Links with a SAN. I'm trying to provide a HA solution using Alternate Links (I was using HP-UX Mirroring but this didn't work on the fail-over). When I server 2 LUNs to a K-220 Hp_UX 11.00 (Nov-99) through FC SAN, I configure the first LUN and get the file system runing. Then I vgextend teh second LUN into the volume group. I expected this second LUN to be listed as an Alternate but LVM just lists it as avialable.

Note: I had MIrror Disk UX installed and I removed it, prior to performinh the Alternate Link.

I thought alternate links was standard with LVM. Any possibilities as to why this is happening?

Fernando

[Sridhar Bhaskarla]

Hi Fernando,

Are you sure that c10t0d2 is the same disk as of c9t0d2?. If so, LVM should have automatically detected it. This has nothing to do with mirror disk.

Did you by any chance do a pvcreate on the alternate disk before extending it into the volume group?.

If you are sure that this is the alternate link, then you reduce the disk, do a vgcfgrestore and extend it back.

-Sri

[James R. Ferguson]

Hi:

The device file you used to 'vgextend' isn't an alternate link. Had it been, your 'vgdisplay' would have shown "alternate link" next to the appropriate PV Name in the "Physical Volumes" section. Furthermore, it would *not* have listed it as a separate physical volume, rather it would have shown as one line underneath the other device.

Yes, alternate links are a standard LVM feature and in no way depend on MirrorDisk/UX.

Your physical volume display should look like this for two devices where one is an alternate link:

PV Name /dev/dsk/c2t0d2
PV Name /dev/dsk/c5t1d2 Alternate Link
PV Status available
Total PE 1000
Free PE 45

Regards!

...JRF...

[James R. Ferguson]

Hi:

The device file you used to 'vgextend' isn't an alternate link. Had it been, your 'vgdisplay' would have shown "alternate link" next to the appropriate PV Name in the "Physical Volumes" section. Furthermore, it would *not* have listed it as a separate physical volume, rather it would have shown as one line underneath the other device.

Yes, alternate links are a standard LVM feature and in no way depend on MirrorDisk/UX.

Your physical volume display should look like this for two devices where one is an alternate link:

PV Name /dev/dsk/c2t0d2
PV Name /dev/dsk/c5t1d2 Alternate Link
PV Status available
Total PE 1000
Free PE 45

Regards!

...JRF...

[James R. Ferguson]

...sorry, didn't mean to post twice...I didn't get a response to the first submission...

[Ashwani Kashyap]

Hi the device c10t0d2 is not an alternate link to c9t0d2 other wise you would have seen an entry called Alternate Link under the Physical volumes section in the vgdisplay -v output .

Also the PV status , Total PE and Free PE wpould all be same and occur just one for both the PV's in the vgdisplay output .

Your best options is go in sam -> disks and filesystems -> disk devices .

Select a disk on the SAN , go to actions tab -> View more information and the nselect show alternate paths . It will show you the device name of the alternate link .

Vgextend your VG onto this device and then do a vgdisplay . You should see the alternate link .

[Brian M Rawlings · Accepted solution]

Fernando: one additional point...

It is hard to be sure, but it sounds like you are misunderstanding the use of "PV Links" (alternate links). With mirrordisk, you would specify a different LUN to be the physical secondary device, but that is not how alternate paths work with PV Links.

With SAN-connected arrays (presuming a proper config with dual paths), each LUN will show up twice in an 'ioscan', making it look like you have twice as many LUNs as you really do, and scaring the tar out of the uninitiated. This is only because there are two paths to each LUN, and 'ioscan' sees both, since both work.

Whichever path is added first during the vgextend or vgcreate command will be the primary path. To add the 'Alternate Link', use 'vgextend', and specify the "OTHER PATH" to the SAME LUN you previously added to the VG. LVM will notice that the PV is already in the VG, and, instead of adding the PV's extents, will simply add the alternate path to the LVMTAB entry for this VG.

You can also use the 'strings' command to view entries in the /etc/lvmtab file, to see all PVs assigned to a VG, and see that PV Links are set up properly for a VG.

As Ashwani noted, one of the easiest ways to set up the PV Links/Alternate paths is to use SAM, which has a selection for "Add Alternate Path" (or something like that). To find the alternate paths to a LUN yourself, however, review the output from 'ioscan -fnC disk', and watch for two devices with the same info except the "c" (controller) # in 'c?t?d?'. This is a little vague, since, in a large SAN, there could be lots of apparent matching entries. Hopefully, you know which channels your LUN is attached to, and you can narrow it down to just the two correct ones. If you need more help with this, reply with output from 'ioscan -fnC disk'. There are other utilities and other ways of locating the alternate paths.

Good Luck, hope this helped.

--bmr

[FERNANDO PROIETTO]

Hello Everyone,
first I would like to thank you for submitting your replies. Some info. I already knew, some I didn't and it was helpful. For exampe, I didn't know PV Links could work along side with MirrorDisk. I removed Mirror disk thinking that it was either one way or the other. Thanks for that clarafication.

A little bit about my SAN configuration. I wasn't totaly clear in my intro. post. The K-server (K220) only has room for one HSC FC-HBA - A6685A. The SAN-RAID is not connected directly to the server. I'm using a Brocade 2800 FC switch. Also, I am using a virtualization tool (SANsymphony from DataCore) to allocated and server storage to the k-server. I believe the dilema begins here. I can server 2 LUNs from different virtualization servers called SDS's (Storage Domain Servers) to the K-servers. The K-server accepts them and they appear as separate devices. I think this is why PV Links treats them as individual LUNs. I'm attempting to get the SDS's to mirror the LUNs instead of the K-server. Hence my use of PV links for altrenate pathing.

I think before I continue I will re-load MirrorDisk as I will require it, since my O/S disks are still SCSI attached.
I need to complete the mirror set on the SDS's before I can get the K-servers to do their job. I'll try and keep this thread going so that others can use this info. Thanks for your assistance.

[Keith Clark]

Hi Fernando,

I am not familiar with the Datacore products, but the virtulization that it provides should behave no differently then say an XP or EMC array. If you are mirroring the LUN with Datacore, the K-server should only see one LUN. The mirroring should be transparent to the server.

The only way that PV-links would be of any use is if you had two physical connections to you SAN.

HTH,

Keith

[FERNANDO PROIETTO]

As of this morning and my last reply, I managed to successfully apply PV Llinks to the k-server.
I had to re-zone the SDS servers so taht they see each other (makes sense given that the mirror is done at that level). Once applied the K-server does in-fact see 2 LUN's. Once I vgextend the volume group it does show up as 'Alternate Link". Tried the fail-over and preliminary stats show approx. 3 min. latency before it fully fail-over. Does anyone have fail-over timings for their SAN configuration using an HA solution (that's is some sort of storage redundancy or fault tolerance in place)?

Fernando

[Angus Crome]

Fernando, just a quick note;

You apparently are using the Fibre card in the 10/8 slot on the Core/IO board. The HSC FC-HBA - A6685A is not officially supported by HP in that slot on any K-Series.

They support them in the 4 slot HSC expander, but those are not installable in a K220.

If you have performance problems or quirky behavior, that is the first place HP will tell you to scrutinize.

[Brian M Rawlings]

Fernando: thanks for the config info. The main point of PV Links is that is provides an idle "secondary" connection down a different channel to an array-based disk.

The concept doesn't extend to JBOD drives, for instance, since they only have one connection back to the host (no alternate path exists). With arrays, however, there are two (or more) possible I/O paths that can access each Drive/LUN/Hyper/etc. This provides a complete redundant path, with OS-level fail-over, to provide continuous access to your data even if you lose one channel.

It seems, then, that PV Links will only be of limited usefulness in your case, since you have only one FC card/path. Even if your array has two connections into the SAN, and thus you can see each LUN/Hyper/whatever twice, you still only have one link/path out of your host to the SAN. If your FC card, or the cable, or the SAN switch port/GBIC goes out, you have no alternate channel for that part of the connection.

I suppose that it does provide some redundancy during the 2nd half of the connection (SAN-to-Array), so it is not completely useless. It also protects you against loss of a controller/adapter/port in the RAID Array.

Look at it this way: Mirroring (via mirrordisk SW or via RAID redundancy) protects against DATA LOSS (loss of a drive, typically). PV-Links (or other such things, like PowerPath from EMC) protects against LOSS OF ACCESS to your data. With a single FC connection to your host, you're only partially protecting your access to your data. Your data remains fully protected from loss, however, by the RAID functionality in your Array.

Incidentally, you have exactly the same situation with your boot drives and Mirrordisk/UX SW. In a K-class unit, there is one FWD SCSI bus that runs through all four internal drive slots, and thence to the external port (where it is hopefully terminated). Thus, you only have one I/O path to those drives. If you use Mirrordisk SW, you are protected against DATA LOSS, but you are still not protected against LOSS OF ACCESS to that data, since loss of a SCSI control chip, or faulty terminator/cable, or other electrical issues with a drive might hang the SCSI bus, and you've only got one path. In a K-class, the only protection against LOSS OF ACCESS to the boot drives is to put the mirrored partners in an external drive chassis, running off a different SCSI bus than the four internal drives.

Sorry if I got carried away there, the parallels between your array access and your boot drive access gave me an amused [?!] moment.

Anyway, hope you understand your situation better now.

Best Regards, --bmr

[FERNANDO PROIETTO]

Hi Angus,
from what I've read I'm not aware of HP not supporting an HSC FC-HBA A6685A in the Core HSC slot. After all HSC is HSC. Right? As far as I know what is not supported is booting from a FC-HBA on a K-220. You need at least a K370 to that and also be able to add a 4-port HSC expander board. I have K-370's as well and plan to that too.

Hi Brian,
thanks for the obvious but I'm quite aware of the single-point of failure I have on the K-220's with 1 FC-HBA. These are legacy systems which we were previously using HP-UX Mirror with dual SCSI controllers. This approach is temporary until we migrate over to a Linux Cluster platform. The K-220's have this limitation but I also plan to incorporate our K-370's and they support dual FC cards and hence altenate path proper. Thanks.