[DRBD-user] moving a drbd/xen/heartbeat to another cluster

Lars Ellenberg lars.ellenberg at linbit.com
Tue Feb 17 10:34:08 CET 2009

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Tue, Feb 17, 2009 at 09:48:45AM +0100, Heiko wrote:
> On Mon, Feb 16, 2009 at 8:30 PM, Lars Ellenberg
> <lars.ellenberg at linbit.com> wrote:
> > On Mon, Feb 16, 2009 at 01:19:26PM +0100, Heiko wrote:
> >> On Mon, Feb 16, 2009 at 10:58 AM, Heiko <rupertt at gmail.com> wrote:
> >> > Hello,
> >> >
> >> > we have one XEN VM that is running on a lvm device, replicated with
> >> > drbd between 2 machines and we
> >> > now need to move this setup to another pair of machines, What is the
> >> > best way to do this?
> >> > The new setup will have the same paramteter than the old one, 10GB LVM device.
> >> >
> >> >
> >> I missed to give some infos,
> >> all the hosts run on Centos 5.2, drbd ist 8.0.13-1, xen is 3.1.
> >> Would this transfer work with  an simple dd of the drbd device?
> >
> > yes, but only if you quiescen it before you start the dd.
> > downtime, obviously.
> >
> >> Is there a way to get nearly zero downtime by adding one of the new
> >> server to the existing cluster,
> >> than remove both old ones and add the second new server?
> >> Has this be done before and how would look the complete procedure?
> >
> > I'd probably replace the current secondary with one of the new nodes,
> > do a _full_ sync, then switch over, and replace the other node.
> >
> Hello Lars,
> 
> i wrote down all the steps I would do to transfer the VM to the new
> pair of machines,
> would this work that way or do I have any wrong steps in there?
> 
> --------start-----------
> 
> shutdown the 'old secondary' with "drbdadm down "resource""
> 
> remove it from the config file on the 'old secondary' server
yes.

> change the resource to the new server on the 'old primary' (will this
> work if there is more than one drbd device?)

yes.
you replace the "old secondary" with the "new server"
in the config on the "old primary".
(brgs. do not call nodes with their current roles,
 as roles will change, and then it gets horribly confusing)

> Add the device to the 'new secondary' config file.
> 
> create the new device on the 'new secondary' with:
> 
> drbdadm create-md "resource"
> drbdadm up "resource"

I prefer "adjust".
# see what drbdsetup commands would be executed
drbdadm -d adjust "resource"
# do it
drbdadm adjust "resource"

> drbdadm secondary "resource"

not necessary.
it is secondary already,
and remains secondary until made primary.

> than sync it, on the 'old primary' do:
> drbdadm -- --overwrite-data-of-peer primary "resource"

not necessary, and does not even do a thing,
because it is already Primary.

and the resync should already have started anyways.
if not, double check ips and connectivity,
then drbdadm adjust.

> when thats done, shut down the resource on the 'old primary' with
> "drbdadm down "resource"".
> remove it from the config file on the 'old primary'.

yes.

> now add the resource to the configfile on the 'new primary' server.
> change the resource in the configfile on the 'new secondary' to
> reflect the new primary.

these are not Primary server and Secondary server.
Primary and Secondary are _roles_.

I know you know that.
but please also get used to _think_ this way,
or you will get confused, and confuse people you talk to.

the just previously synced new server can be made primary now,
and you can go online with resources already.

you can be online with the resource while it is still primary
on one of the old servers, then just do a switchover by hand
to the first new server you used to replicate to.
minimal downtime.
you could even live-migrate, if you did that before,
and the host systems are sufficiently similar.

then disconnect from the old server,
and connect to the other new server.

it is really that easy.

> when thats done, make the 'new primary' a primary on the 'new primary':

wow. listen to yourself.
see what I mean?

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed



More information about the drbd-user mailing list