Moving a fibre channel card - LVM Implications

[Denise Doyle]

Hi. Dead simple configuration. V class connected to VA7400 directly via 2 x Tachlite cards. The VA is carved up into 14 x 10Gb LUNS. Each LUN holds 1 x Logical Volume. All LV's are in 1 VG (vg7401). When I set it up I alternated the PV paths allocated to the LV's between the FC cards to load balance between them. Alternate paths have been set up for each LV. OK so far?

Now here is the question. When it was set up both FC cards went into one card cage because of space problems. We now have the opportunity to move one FC card to the other cage for better resilience. I hope to vgexport vg7401, move the card, and then vgimport vg7401 from the new location. If I alternate the PV paths between the controllers when I do the import will I achieve the same load balancing? Anyone aware of any problems or 'gotcha's' in doing this?

Any help greatly appreciate.

Dave

[David Navarro]

Hi Denise.
The answer is no, is you do an vgexport and vgimport, you will loose all you load balancing, new imported vg, will be seen by one controller and the other just for alternate path. At this point you must vgreduce all paths that you're seeing as primary and you want to be alternate, and the vgextend the same. Finally, you will see vg with load balancing, as you want.

I Hope It help you !

[James R. Ferguson · Accepted solution]

Hi Denise:

When you 'vgimport' simply define the order of the paths (primary and alternate) you want in a file (e.g. /tmp/vgXX.newpaths) something like this:

# vgimport -m /tmp/vgXX.mapfile -v -f /tmp/vgXX.newpaths /dev/vgXX

Your import will arrange your primary and alternate links as you choose in one step.

Regards!

...JRF...

[Bill McNAMARA_1]

James solution will work fine, however, if you have olar (I don't think it's possible on the V's) you could do it online with vgreduce - olar card - vgextend.

Later,
Bill

[Roger Baptiste]

Denise,

Yes, you should be able to do it.
Make sure you have the current VGdisplay -v
and ioscan output, as a reference.
Do a vgexport of the vg's; (make note of
VG control number in /dev/vg**/group).

Move the card to the different cage.

Bring the system up; make a note of ioscan
output and see whether all the PV paths
are visible.

Then, get onto figuring out the PV links
of one card vs other. (should be easy, once
you see the pattern of cxtydz).

Next, create mkdir /dev/vg** and group file

Vgimport - Do the vgimport with the
FC1-FC2-FC2-FC1-FC1-FC2.. combination. In that
way, you spread the load across the two cards.
(instead of FC1-FC2-FC1-FC2, which has
all the load on one card, unless a failure
occurs).

If it is a busy system and your disk loads
are estimated to increase , then this
is a worthwhile process. Otherwise, it may
not be worth the pain. You can do the
FC1-FC2-FC2-FC1, even with the current setup
and improve the channel distribution.

HTH
raj

[Wodisch]

Hello Denise,

I do not see the reason for "vgimport" and "vgexport" at all!
Since good ol' LVM does NOT do load balancing (have I missed something here?) it ONLY uses the "primary" PV link.
Hence all you have to do is to "vgreduce" the PV links of the FCcard you want to move, then move it, then "vgextend" the new paths to the volume group.
That's it.
Just my $0.02,
Wodisch
PS: We are talking LVM here, not VxLM, right?

[Denise Doyle]

Thanks all. yes it is LVM - I understand that LVM does not load balance but at least we are splitting the traffic across controllers by using the pri/alt alt/pri routine. I am taking the old SCSI disks off this weekend and re-arranging the cards next. Keep your fingers crossed and thanks again;-)

(Dave, btw, working for Denise.)

[James R. Ferguson]

Hi (again) Denise, Dave & Wodisch:

If the hardware paths (and hence device files) are changing, then, obviously the 'vgexport/vgimprt' method is in order. The primary and alternate links can easily be defined at that time in one-stroke.

In cases where one merely wishes to switch primary and alternate links to achieve load balancing between two channels, then Wodisch is absolutely correct, too. Simply 'vgreduce' the primary link(s) thereby causing the alternate to become the primary and follow that with a 'vgextend' of the original primaray link as the new alternate.

In situations where either method would work, the biggest downside of the export/import is the need to unmount filesystems associated with the volume groups.

Regards!

...JRF...