how to put 12H on different scsi paths

[Donald Kok]

Hi,
I like to know how to put this autoraid on some other scsipaths. I have the following scenario in mind:

- vgexport the vg
- shutdown the system
- reconnect the scsicables
- start the system
- vgimport the vg

I like some confirmation (or shooting) on this scenario, since I never did this.

Thanks in Advance
Donald

[Eugeny Brychkov]

Donald,
you have 2 SCSI controllers in the autoraid. You connect these SCSI controllers to different host's HBAs. You create LUN in the autoraid. So you see this LUN through 2 paths. All you need is to create vg and tell the command second, altarnate, path for the LUN.
vgexport and vgimport you should do only if you're creating clustered environment (to be able to see same LUN from different hosts in the same manner)
Eugeny

[Donald Kok]

Hi,

The 12H is already working (with vg's) for years. Now I want to put the 12H on other scsiports.

Thanks
Donald

[Eugeny Brychkov]

Donald,
which configuration do you have now? Do you have 12h connected only by one controller to the server? What exactly you want to do with 12h connections? Please tell it to me and I will tell you what to do.
Eugeny

[Bill McNAMARA_1 · Accepted solution]

Hi donald what you want to do, and the way you want to do it, look good.. once you umount the fs's and disactivate the vg before (vgchange -an vgs).. you need to do this for all vgs on the 12H.

What you should be using however for the vgexport and vgimport, is the -m option (to create the map files) A quick search in the forums on "mapfile vgexport vgimport" will give you the correct procedure.

If all messes up a vgscan could assist restoring the vg on the 12H. ( a quick search on "vgscan autoraid" will produce more on this)

Consider a backup just in case.

Good luck,
Bill

[Brian M Rawlings]

Donald: a backup is a must, for something like this. There are too many ways to flub it up, especially if you are new at it.

One of the reasons to do this is to allow your VG to "load-balance" the data to the array, increasing your overall performance. This can also be done without wiping out the data, but it is a little tricky (see backup rant above).

To do this, however, you need at least two LUNs. If you only have one per VG, no load balancing is possible. Four LUNs is even better, but the 12H allows for only 8 LUNs, so use them wisely.

Say you have two LUNs. You have your data on one of them. You us vgextend to add the 2nd LUN to your VG, but you specify the new SCSI path in your vgextend statement. Thus, data to the 2nd LUN will flow down the other SCSI path, allowing full bandwidth on each to be used. But, the second one won't get used until the first LUN is completely full, unless you play a trick on LVM.

To do this, you then use lvextend (plus options) to extend your logical volume into the additional space, but adding the striping option to stripe the data across the two "physical volumes" (your LUNs) that LVM sees. Now, each write in turn uses one LUN, then the other, then back and forth. Depending on your usage patterns, this can increase performance a little or a lot.

Lastly, to provide data path redundnacy (all access continues even if one SCSI channel goes out), you use vgextend to add the 2nd SCSI path to the first LUN, and add the 1st SCSI path to the 2nd LUN.

This is also a bit tricky, but, basically, when you do an 'ioscan', each LUN shows up twice (when you have both SCSI channels connected to the 12H array). That's because each LUN is accessible on each SCSI path. You pick one to use on your 'vgextend' command, and it becomes the primary channel. If you then use 'vgextend' but specify the other channel, LVM sees that you are really extending the same drive it already knows about, and just adds the 2nd path as a failover channel. (you can specify both paths in your 'vgextend' command, but then LVM decides which will be primary, and you want control over this to do your load balancing act).

When you do it right, you end up with improved performance for the VG, fully automatic failover if you lose a SCSI HBA, cable, or 12H controller, and your boss notices and gives you a big raise. Well, that's the theory, anyway.

To see if you've done it right, use vgdisplay -v, and watch for the 'physical volumes' at the end of each VG. If they are set up right, you'll see that each physical volume (LUN, in this case) has a /dev/dsk/c?t?d?, and then the other path listed benieth as "alternate path". Use lvdisplay for each LV to see if you've got striping set up right.

And don't forget the backups. Did I mention that? In this case, it might actually be advantageous to delete the data and then roll it back on from tape, in order to maximize the performance you'd get from the striping. Unless you do this, your existing data will remain where it is (all one the one LUN), and only new writes would alternate across the LUNs, following the stripe pattern. Eventually, most of the high-use data would be written as striped, but... if you can afford the time to delete it and roll it on from tape, it would all be striped.

This is a common practice, and if you have questions about it, there are many other posts regarding doing LVM this way to an array. The term "pvlinks" or "pv-links" is used to describe the concept of a primary and alternate (unused except for failure of the primary) link to an array.

Good Luck, hope this helps.

--bmr