LVM on a redundant system

[JUP]

Before I start I would like to say that I am not using Service Guard and at this moment do not intend to.

I have two HP 9000 connected to a High Availability Storage Server (HASS) with two drives in it. One for data the other for mirroring. I have configured the drives perfectly on System A. When I go into SAM on system B the drives are stated as "unused". If I try to configure the drives from B then I loose the data on them as they get initilised. System B should be able to load the drives when A is down (redundant system). I have the redundant software but I can't get System B to read the drives without clearing them. Tried VGEXPORT and VGIMPORT - anyone with ideas.

Thanks

[Andy Monks]

What are the exact commands your using?

Assuming system A isn't using the disks, just doing a vgimport on system B should be enough.

I'm assuming your not doing vgcreate?

[Manju Kampli]

you should be able to use the disks from system B. make sure the volume group is not activated on system A when you are trying to do vgimport on system B. Please post what errors you are getting when you are doing vgimport/vgexport.

[melvyn burnard]

Why not MC/ServiceGuard? Or is the application maybe not able to restart from a crash.
Anyway, provided the vg is created on the node A and then vgexported/vgimported across to node B it should be no problem.
The one suggestion may be to ensure, just as for MC/SG, that the vg names, VG minor numbers etc all match up on both systems.
You may also want to try using the -s option to export the vg, and then reimport it on node B

[Patrick Wessel]

Let me add my thoughts?

System B is supposed to be the fail-over system for system A. The nature of this situation is, that you are planing to use the disks on system B when system A is down, right? Well, I'm afraid there is no way to execute a vgexport on a down system?

[JUP]

Thank you everyone for your quick replies. I have my own software to switch servers after a crash. The problem is not the switching its the accessing of the drives from system B.

Manju: I'm not doing a vgcreate - if I do then won't I loose the data thats already on the drive.
Melvyn: How do I de-activate it on system A ?
Am i suppose to run vgexport on A and vgimport on B ?

I read alot of vgexport / vgimport commands form the messages, but no luck. Can someone please be a bit more precise.

Thanks

[JUP]

Patrick - are you saying that if I don't use ServiceGuard that there is no way of switching. Both systems have their own local drives to boot from. System A has the drives from the H.A.S.S working fine. When it crashes System B will then take over and load the drives from H.A.S.S. My problem is that I'm not sure how to setup the drives on System B without re-formatting as they have been setup on System A.

[melvyn burnard]

I would suggest you go and read the following manual section from teh Managing MC/ServiceGuard manual:

http://docs.hp.com:80/dynaweb/hpux11/hiaven1a/mcsgen1a/@ebt-link?window=CURRENT;target=%25N%14_6007_START_RESTART_N%25

It explains how to activate/deactivate VG,s and export and import them.

[Andy Monks]

On system A, you don't have to vgexport. You just need to ensure that either system A is down, or it's done a vgchange -a n /dev/vgXX

Then system B, can import them

[melvyn burnard]

Paul, You will also need to ensure that your HASS unit is connected using Self-terminating SCSI cables, and that the interfaces in the 2 nodes have the internal terminators removed.
Otherwise if node A dies, you activate the discs to node B, and then disconnect the cables from Node A for a repair, you break the SCSI chain, and Node B will have problems with the VG!

If you read the manual section I gave the URL for, it covers most of what you need, just be aware that if you do NOT change the /etc/lvmrc file on the nodes, they will both attempt to activate the VG on boot-up, and WILL do it!
So your fail-over scenario will need to include a script to activate the vg on the required node ONLY, else data corruption will occur.

[Antoanetta Naghiu]

Paul,
Is your vgxx mirrored? Can you, please post here the errors that you get in the following:
1.SysA -up, do vgexport -m mapfile vgxx
2. get mapfile to sysB (ftp, rcp whatever)
3.Shutdown (power off sysA) and than in sysB do:
vgimport -m mapfile -s -v /dev/vgxx /dev/dsk/cXtYdZ ...
4.in sys B vgchange -a y /dev/vgxx
What error do you get?

[Dave Wherry]

You say "If I try to configure the drives from B then I loose the data on them as they get initilised". What are you trying to do at that point? If you are doing anything in sam or doing a vgcreate, the disks will be initialized and you will lose everything.
As one post said, if A is down you can not vgexport it. Another post said to vgchange -a n and deactivate the vg. Again, can not do it if A is down.
I think you need to do a vgchange -a s to make it shared on A for the high availability environment. Then when A goes down the you should be able to vgimport on B.

[JUP]

Thanks guys for your help.
Still no luck.

Antoanetta: On Sys A, I typed in the following:

vgexport -m mapfile.exp vg01

and got the following message:

Volume group "vg01" is still active.
vgexport: Couldn't export volume group "vg01".

Then I tried again, this time, after I unmounted the device that I want to export:

"umount /data1"

same error message as above.

The device I'm trying to export is: /dev/dsk/c0t14d0 and its mirror /dev/dsk/c0t15d0. They were mounted to /data1 on System A. I want to unmount it and mount it to /data1 on System B.

Do you have any ideas ?
Current

[Denver Osborn · Accepted solution]

I havent read all the posts to your originial question, but here's my 2 cents.

If you want to export vg01 from SYSTEM A and import it on SYSTEM B try this;

SYSTEM A
# umount /data1
# vgchange -a n /dev/vg01
# vgexport -v -s -m /tmp/vg01.map
-=ftp the map file to system b=-
SYSTEM B
# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# vgimport -v -s -m /tmp/vg01.map
# vi /etc/fstab -> add entry for /data1
# mkdir /data1 -> if not there
# mount /data1

When you want to take it back, use the same steps.

After looking over your last response, it looks like you didnt deactivate the vg before exporting it. Are there any other filesystems in vg01 other than /data1 - make sure they are also unmounted before attempting to deactivate vg01.

[Denver Osborn]

oops... almost forgot something.

after doing the vgimport on SYSTEM B, and before mounting /data1, activate the vg.

# vgchange -a y /dev/vg01

[JUP]

Denver,

you are a champion - it all works.

Thank you everyone for your tips - all of them were useful.

I will assign points shortly.

[Denver Osborn]

glad it was what you were looking for...
with the vgexport I forgot to tell it what vg to export, but it sounds like you caught that. should've been;

# vgexport -v -s -m /tmp/vg02.map /dev/vg02

[Rick Tweedy_1]

Hi Paul,

I just posted another message similiar to yours. Although we are not trying to accomplish the exact same thing I did do all the same steps. I am finding on the second system though it does not seem to re-read the disk unless I mount/umount the vol.

When you change the contents of the FS does both system pick up the changes immediatly? Did you have to do anything special? Thanx

[Trevor Dyson]

Hi,

Denver's solution to the problem is almost perfect, however there is one further twist that I can think of.

The solution shown above does a full vgexport of the volume group from SYSTEM A. For SYSTEM A to access this volume group again vgimport must be run again on SYSTEM A.

If the purpose of the excercise is to allow SYSTEM B to access the volume group on the shared HASS in the event of a crash on SYSTEM A and allow for a switch back to SYSTEM A when it is available then I suggest the following tweak to Denver's solution. Add the -p (preview option) to the vgexport command on SYSTEM A, ie:

vgexport -v -s -p -m /tmp/vg02.map /dev/vg02

This will create the map file without actually exporting the volume group from SYSTEM A. You also do not need to deactivate the volume group before creating the map file when using the -p option.

Theoretically you may then be able to deactivate the volume group on SYSTEM A with (assuming the volume group is vg01):

SYSTEM A
vgchange -a n /dev/vg01

SYSTEM B
vgchange -a y /dev/vg01

I say theoretically because I have not tried this as yet in a non-serviceguard environment.

If you do want SYSTEM B to take over in the event of SYSTEM A crashing then you need to be certain that SYSTEM A is really not accessing the shared volume group or data corruption will occur if the volume group is active on both systems at the same time.

Serviceguard ensures this by TOCing one of the systems (Transfer of Control - basically crashing one of the systems on purpose to ensure only one will access the shared volume group)

Take heed of Melvyn Burnard's post. If all volume groups are activated automatically on boot up on either of your systems then you could get into hot water if SYSTEM A crashes, you activate the volume group to SYSTEM B then SYSTEM A also activates the shared volume group after it auto reboots. See the following post for information on how to control volume group activation on boot up:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x08767e990647d4118fee0090279cd0f9,00.html

I wish I had the hardware right now to test this out completely.

Regards,

Trevor Dyson

[wyan lowe]

the auto-activate vg setting is in the /etc/lvmrc file:
make the changes to be:

AUTO_VG_ACTIVATE=0

custom_vg_activation()
{
/sbin/vgchange -a y /dev/vg00
return 0
}

so auto_vg_activate=0 means don't automatically activate volume groups
in the custom_vg_activation() function, add the entry for vg00...
other volumegroups won't be activated by default on reboot...