manual HA solution using FC and LVM

[Dr. Peer-Joachim Koch]

Hi,

we have a L-class with 2 FC HBA in a small SAN
together with 2 EMC clarrions and some other
stuff.
All LUN's(with dual path) of the clarrions are in one vg. I want now a stand by (!) solution to switch all file server functions (nfs,samba) to
another machine (HP).
We have two other computre, each with 2 HBA's.
How can I make the VG sharable ?

I'm thinking about the following steps:

1) export the vg-informations and copy
the files to the second machine

2) Tell the clarrions to allow other computer
to see the LUN's

3)(?) Set "vgchange -a s ..." on the VG ?

4) vgimport on the second machine

5) Try to see the LUN's on the second machine
(I know, that it would be not the best idea
to mount the LV from two sites.... ;)
ioscan ...

Done ?

What would be the right way to prepare a second machine as a fail over solution ?

Bye, Peer

[Karamanolis Nikos]

Hi,

I don't think that you are going to achieve much with doing so.

Even if the vgchange -a s works, you will end up with chaos on your vg's and filesystems.

The only proper way to do this is to install MC/Serviceguard software. Otherwise you are just looking for trouble.


Hope it helps,
Nikos

[Dr. Peer-Joachim Koch]

Can you explain it in more detail.
I just want to be able to access the LUN's
when the server goes down. MC-Service Guard allows an automatically fail over solution.
I just want a simple way to replace a
server which is down.
When the server is crashed, it will be also possible to import the VG, or not ?
Why not before ?

Please more details!
Just ...will not work ... doesn't help.

Thanks, Peer

[Rainer von Bongartz]

Peer,

you will no succeed in doing this.

vgchange -a s is only available if MC/SG is installed on your system.


Regards
Rainer

[Michael Tully]

If your worried about your server going down, then you could effectively wheel in a new server, recover from an ignite tape and import all of the volumes. This will depend on:

appropriate hardware
up to date ignite tapes
having a copy of the vgexport mapfiles (in preview mode) elsewhere, so that you can use 'vgimport'.

There are a number of posts on doing 'vgexport/vgimport' between servers using the same disk arrays.

As stated you can only use vgchange -a s in MC/SG environment.

You could share the LUN's between two servers with clariions, but I think you are looking at creating a problem, not a solution. You have to be extremely careful in doing this, but it can be done using the navisphere manager, either from CLI or from a management station.

[Sunil Sharma_1]

Hi,

Intreasting question.
It can be done with few limitation.
1. -s option is a part of MCsg software so it will not work without MCSG pakage installed on machine.
Now you can proceed like this.
1 Make all LUN's visiable on both servers.
2.run ioscan and insf to creae device files on second server.
3.OS and patch level should be same to application work properly.
4. Installed application on second server if it is not in shared partition.
5. create directory for volume group in /dev
6. create group file in this.

once this thing is done.
you can test wheather it can work or not just shutdown your server and try to import volume group here using vgexport.

it should work.

Sunil

[Leif Halvarsson_2]

Hi,
- Configure server 1 with the functionality you need. Server 2 should be down.
- Make an Ignite archive of server 1.
- Allow both servers to have the same acess to the SAN devices.
- Shut down server 1
- Clone server 2 with the Ignite tape.

Now you can booth any of the servers and get the same funktionality but only one of server should be up at the same time.

[Michael Steele_2]

The way of approaching this is via cloning the servers via an Ignite Make_tape_recovery tape and restoring data from tape.

I realize its inconvienient to have all that data on the same disk array with no simple way of migration from disk array group to disk array group, but the rules are their for reasons of data integrity.

If you have both servers within the same SAN zone seeing the same disks then management of the disks violates SAN security guidelines for LUN masking.

As far as 'vgchange -a s', VG sharing to obtain a parallel activation works in conjunction with several additional modules. Its not just a simple LVM command execution. It begins with the MC/SG cluster binary and is primarily a component of Oracle Parallel Server. Nothing else. (* I believe *)

But there is also an 'async' driver and special application enhancements needed as well as additional kernel changes.

The problem is with sychronous writes to the same disk and deadlock contention.

I realize this looks like a solution to the LVM problem of unique vg header id's residing on each disk, but its not.

[Pete Randall]

Peer,

I think you can do this, though it will be somewhat limited due to the need to manually fail over to the second machine. Your steps are fine, just omit the vgchange step.

1) vgchange -a n on the affected VGs

2) vgexport -p -s -m /tmp/vgXXmap /dev/vgXX

3) copy the maps to the second machine

4) create the vg structures on the second machine (mkdir /dev/vgXX & mknod /dev/vgXXgroup c64 0xXX0000)

5) vgimport -s -m /tmp/vgXXmap /dev/vgXX


Now failover is simply a matter of activating the VGs on whichever machine is available with vgchange -a y /dev/vgXX.

However, you need to be *very* cautious about activating on both machines simultaneously. This is something you're not supposed to be able to do with vgchange but, believe me, I destroyed a database once when the VGs mistakenly got activated on the second machine.


Pete

[Dr. Peer-Joachim Koch]

Hi,

thanks for all the hints and warning.

First I do NOT want to share the LUN's neither the VG for parralel IO. The second machine
should just be able to see the VG structure
correctly.
Ignite tape will not work, because the second machine is also working (not a perfect standby).
So I can not simple clean up the disk and restore
the other data.

Maybe someone can explain the following points:

What happens to the VG-id, when the devices are imported at a second or a third machine ?

Is it necessary to use exactly the same number
fro the mknod command, or has it only to be unique ?

As a summary everybody points out, that it is
big risky task to make the LUN's visible on
a second machine (at least online).

Shall I just export all VG infos and store
the info's on a second machine and wait for the crash and THEN try to access the disks ?
I would like to get some practice BEFORE the
crash, that was the main topic of this posting .... ;)

Thanks to all !!

Bye, Peer

[Leif Halvarsson_2]

Hi,
Fron your previous post:
"I just want a simple way to replace a
server which is down.
When the server is crashed, it will be also possible to import the VG, or not ? "

Suppose you have two identical servers, one ordinary and one spare, the ordinary server craches but the SAN disk systems is OK.

All you need to do is to clone
the spare system with a Ignite tape from the ordinary server. Of course the spare server also should have the same acess to the SAN as the ordinary server. But this is a question about SAN Zoning and have nothing to do with the server configuration.

Thats all you need to do. You don't need any tricks with the VGs or such.

[Pete Randall]

Peer,

No the VG IDs do not need to be the same. In my situation (in hopes of avoiding the confusion that led to the trashing of the database), the VG is known as vg02 on one machine and vg20 on the other. As far as testing to ensure this works, you can do that anytime, just deactivate the VGs on one machine and activate them on the other, test, then switch back.

Good luck,


Pete

[Dr. Peer-Joachim Koch]

Yes, that's right.
But restoring the system takes some time.
We have two machine's online with the same
HPA's, memeory etc. Every machine HAS nfs.server
and samba installed.
I just need the VG (and the server IP, but that is esay) and everything works within a minute.

You are absolutly right. Simply restoring everything from tape is fine, but why
not use the rest ?

Peer

[Pete Randall]

Peer,

Sorry, forgot one part of your recent question - the minor number used in the mknod command simply needs to be unique.


Pete

[Dietmar Konermann]

Peer,

some comments... you need to distinguish between the VG's number and its VG-ID (aka unique ID).

This VG-ID is stored on disk and is not changed when importing the VG on another host.

The VG's number is the most significant byte of its device files' minor numbers. It can be different on different nodes... it's just a kind of index into the kernel's table of VG structures. It needs to be unique for a given node, of course.

You are talking about NFS server functionality... in this case it is indeed important to have the same VG number on each node, since NFS builds its device ID based on device's major/minor number. If the failover node uses another number, then upon failover all client's mounts get stale and need to be re-mounted.

Concerning the original question... simply import the VG on the failover node using the procedures above. You can test using the readonly activation mode vgchange -a r, to see if all works as desired. In the case of need you can activate -a y and mount, if (and only if) you are sure that the primary node is offline and has no longer access to the VG. This is of course your own responsibility.

Best regards...
Dietmar.

[Alzhy]

I understand completely what you are trying to do. Would you mind a VxVM "recipe" which I find easiest to implement now that VxVM is part of HPUX11i (and nicely integrated btw). You do not even need a separate license -- the base will do. This is precisely a setup that I've done a number of times (poor-man's failover I may say -- works for both Solaris and HP.

1. Make sure ServeA and ServeB have paths to the same LUNs (or disks) on your storage subsystem (SAN or multiported disks).

2. If you want failover automation -- you can setup a private "network" between ServeA and ServeB -- with ServeB always watching for "heartbeat from ServeB".

3. Either manually or via automatic means (2 above) - once ServeA fails - establish ServeB live on the network and do a:

vxdg import datddg
vxvol -g datdg startall
then fsck the volumes (VxFS a must...)
mount the filesystems
resume normal operations


Not truly HA but quickest way to failover to a different server I believe...

[doug mielke]

Maybe I was too simple in my set up, but wanted to do the same thing when I installed my SAN.
1) Made 1 LUN on the SAN for this pair of servers
2) presented it to backup server
3) Made 'vgsan', lvolsan, using entire lun on backup server
4) un presented to backup, presented to primary
5) made vg, lvol, etc. and loaded my data.

In a failure, if I present the LUN to backup server, won't my vol's be seen, and then I can manually mount filesystems?