From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2IG11uA021503 for ; Tue, 18 Mar 2008 12:01:01 -0400 Received: from barney.tradebotsystems.com (barney.tradebotsystems.com [38.100.176.19]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m2IG0RYa000385 for ; Tue, 18 Mar 2008 12:00:29 -0400 Received: from tradebotsystems.com (tbmail.tradebotsystems.com [192.168.254.26]) by barney.tradebotsystems.com (8.13.6/8.14.1/Linux) with ESMTP id m2IG0Hr3021725 for ; Tue, 18 Mar 2008 11:00:19 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88911.2902ADA8" Date: Tue, 18 Mar 2008 11:00:17 -0500 Message-ID: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com> From: "Taylor Lewick" Subject: [linux-lvm] vgimport without vgexport (hardware crash) Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: linux-lvm@redhat.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C88911.2902ADA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 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. =20 Thanks, Taylor ------_=_NextPart_001_01C88911.2902ADA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

------_=_NextPart_001_01C88911.2902ADA8-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [10.33.0.40] (breeves.fab.redhat.com [10.33.0.40]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id m2IGBYUs023268 for ; Tue, 18 Mar 2008 12:11:34 -0400 Message-ID: <47DFE7AD.9000206@redhat.com> Date: Tue, 18 Mar 2008 16:02:53 +0000 From: "Bryn M. Reeves" MIME-Version: 1.0 Subject: Re: [linux-lvm] vgimport without vgexport (hardware crash) References: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com> In-Reply-To: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com> Content-Transfer-Encoding: 7bit Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii" To: LVM general discussion and development -----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----- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2SCebJs007499 for ; Fri, 28 Mar 2008 08:40:37 -0400 Received: from barney.tradebotsystems.com (barney.tradebotsystems.com [38.100.176.19]) by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id m2SCeR3h018634 for ; Fri, 28 Mar 2008 08:40:27 -0400 Received: from tradebotsystems.com (tbmail.tradebotsystems.com [192.168.254.26]) by barney.tradebotsystems.com (8.13.6/8.14.1/Linux) with ESMTP id m2SCeJZY010711 for ; Fri, 28 Mar 2008 07:40:21 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890D0.E1B9E4AC" Subject: RE: [linux-lvm] vgimport without vgexport (hardware crash) Date: Fri, 28 Mar 2008 07:40:19 -0500 Message-ID: <07774C6E31D94A44A2A60E2085944F09013994F3@tbmail.tradebot.com> In-Reply-To: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com> References: <07774C6E31D94A44A2A60E2085944F0901398E92@tbmail.tradebot.com> From: "Taylor Lewick" Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: LVM general discussion and development This is a multi-part message in MIME format. ------_=_NextPart_001_01C890D0.E1B9E4AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 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). =20 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. =20 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. =20 Taylor =20 =20 =20 ------_=_NextPart_001_01C890D0.E1B9E4AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

 

 

------_=_NextPart_001_01C890D0.E1B9E4AC--