[linux-lvm] vgimport without vgexport (hardware crash)

[linux-lvm] vgimport without vgexport (hardware crash)

[Taylor Lewick]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

We have a database server accessing a disk array. (Array supports only a
single host connection)

Should that server suffer a hardware failure, we'd like to connect up a
standby server to take its place.

So in the event of a bad hardware failure, I won't be able to unmount
the filesystems, vgchange -an, and vgexport the volume groups.

 

Can I expect a vgscan and vgimport to work on the new server if I wasn't
able to run vgexport?  Any other data I would need to make this work?

I know in HP-UX you were able to run a vgexport in output mode only, and
give it a map file and you could then import using this map file in this
scenario.

 

Thanks,

Taylor


[-- Attachment #2: Type: text/html, Size: 3284 bytes --]

Re: [linux-lvm] vgimport without vgexport (hardware crash)

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Taylor Lewick wrote:
> Should that server suffer a hardware failure, we?d like to connect up a
> standby server to take its place.
> 
> So in the event of a bad hardware failure, I won?t be able to unmount
> the filesystems, vgchange ?an, and vgexport the volume groups.
> 
> Can I expect a vgscan and vgimport to work on the new server if I wasn?t
>  able to run vgexport?  Any other data I would need to make this work?

Yes - this isn't a problem with LVM2 - you'll be able to activate the VG
on any other host that can see the storage by issuing a vgchange.

The vgimport/vgexport just toggle a flag in the LVM2 metadata that marks
the VG status and PV statuses as imported or exported, e.g.:

Before exporting t0:

t0 {
        id = "ecajMI-eLGR-5Gmn-T3KG-f3Ey-4JkR-VIQGh0"
        seqno = 1
        status = ["RESIZEABLE", "READ", "WRITE"]
[...]
        physical_volumes {

                pv0 {
                        id = "5LgAWX-Qc1q-e3IB-ak8P-EkEK-uY0q-Ar3Im6"
                        device = "/dev/loop0"   # Hint only

                        status = ["ALLOCATABLE"]
[...]
                }
        }

}

After exporting t0:

t0 {
        id = "ecajMI-eLGR-5Gmn-T3KG-f3Ey-4JkR-VIQGh0"
        seqno = 2
        status = ["EXPORTED", "RESIZEABLE", "READ", "WRITE"]
[...]
        physical_volumes {

                pv0 {
                        id = "5LgAWX-Qc1q-e3IB-ak8P-EkEK-uY0q-Ar3Im6"
                        device = "/dev/loop0"   # Hint only

                        status = ["ALLOCATABLE", "EXPORTED"]
[...]
                }
        }

}

The tools won't allow you to change the VG while it's exported, e.g.:

# lvcreate -n foo -L 10M t0
  Volume group t0 is exported

But it's fine to activate and use a VG previously created/used on
another host without doing the vgexport step first - the HA LVM service
in Red Hat Cluster Suite uses this for e.g. since it's not always
possible to cleanly export the VG when a node dies. We just change the
host tags used on the VG and activate it on the new node.

You might still need to fsck file systems if they weren't unmounted
cleanly but from LVM2's side it should be fine.

Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH3+et6YSQoMYUY94RAjtWAKDhho6glzvP8+LkvlVf2IUPUdsZkwCfVI5f
mc60NA1vw1AFXaGSDuQg9Ew=
=vC7h
-----END PGP SIGNATURE-----

RE: [linux-lvm] vgimport without vgexport (hardware crash)

[Taylor Lewick]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

Just wanted to let everyone know, that I've tested moving a disk array
between two hosts several times and everything works.

Our setup is a database server connected to a dell md1000 disk array and
the disks have been carved into 3 volume groups.

 

We've simulated a server crash by just powering it off, and connecting
the disk array to another like linux server.

When you boot up the new server you just have to tell the bios to import
the foreign configuration (that's at hardware level).

 

The first time I tried it, because we didn't run a vgexport on the
primary server (you wouldn't have the chance to do that in a crash
situation),

I had to vgexport the volume groups, then vgimport and vgchange them,
then mount the filesystems.  But I discovered, that if you add the same
entries to /etc/fstab for the logical volumes on the backup server, that
you do not have to run any lvm steps like vgexport, vgimport, or
vgchange, the OS does all of that automatically.  And if you boot the
backup server when its not connected to the disk array, it just fails
trying to mount those drives but it doesn't keep the O.S. from starting
up.

 

So the net of all of this is if we have a hardware failure on our
database server we can have it back up and running on a secondary server
in less then 5 minutes, unless it has to do an fsck on the filesystems.

 

Taylor

 

 

 


[-- Attachment #2: Type: text/html, Size: 5236 bytes --]