Operating System - HP-UX
1833783 Members
2272 Online
110063 Solutions
New Discussion

Re: Using Clustered VG's outside of Service Guard

 
SOLVED
Go to solution
Keith Elliott
Occasional Contributor

Using Clustered VG's outside of Service Guard

Hi,
I have two N class servers running 11i. Each is connected to an EMC array via fiber channel. We are configuring these servers into an active/passive configuration.
The question I have is how to define and maintain the vg definitions on the spare server so that the passive computer has visibility to the volume groups attached.
Thanks
6 REPLIES 6
Kevin Wright
Honored Contributor

Re: Using Clustered VG's outside of Service Guard

Just create the VG definitions on one server, do a vgexport -p -s -m /tmp/vgXX.map vgXX, scp it to the other box and import it. You just won't be marking the VG's cluster aware, and will have to be sure you only activate and mount the FS on one server at a time.(serviceguard performs this FS protection for you)
Keith Elliott
Occasional Contributor

Re: Using Clustered VG's outside of Service Guard

Thats ok, unfortunately, you have to have inactive volume groups to do a vgexport. I dont have this luxuary more than once a year and would like an alternate option.
steven Burgess_2
Honored Contributor

Re: Using Clustered VG's outside of Service Guard

Hi

Note the -p option is actually a preview, you will be able to do this with the vg active

hth

Steve
take your time and think things through
Keith Elliott
Occasional Contributor

Re: Using Clustered VG's outside of Service Guard

Thanks, the error message is misleading I think.
Tim Sanko
Trusted Contributor

Re: Using Clustered VG's outside of Service Guard

Since I have been in the same boat with you, I came up with this solution.

We use SRDF from EMC to replicate the data and it exists in two places at once...

It is expensive but easy...

Tim Sanko
Dave La Mar
Honored Contributor
Solution

Re: Using Clustered VG's outside of Service Guard

Keith -
As has been mentioned, create your map file using the -p option.
In our environment, we commonly do this since we mount business copy volumes on another machine for backup purposes.
Also, we use the same process to define on the passive machine.
Here's the rub, as you mentioned you have very little opportunities to vgchange the volume group. This makes it very difficult to verify your import on the passive machine.
The verification is essential to insure your failover will occur without error.
Having said that, without the opportunity, you can at least verify the disks involved to match and be in the the correct primary/alternate order.
Do this by utilizing xpinfo -i | grep txxdxx (or grep the ldev), BUT, at sometime you will have to perform the import.
As the SA, your superiors must recognize the nature and consequences of not allowing you to complete necessary lvm work to provide the high availability THEY paid for.

Best of luck,

Regards,
dl
"I'm not dumb. I just have a command of thoroughly useless information."