[DRBD-user] DRBD primary/primary for KVM - what is the best option?

Michael Iverson miverson at 4hatteras.com
Tue May 11 19:12:23 CEST 2010

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


The interesting bit on the first link was the statement:

"If active-active isn't possible, maybe there is distance involved and it's
doing asynchronous replication, then you will need to implement something
like heartbeat to add the volume using ietadm to the running iSCSI target
once drbd B becomes primary..."

The quote is a little short on implementation details, but based on
it, and some snippets
from the other links, it is the tool to dynamically add or remove
volumes without messing
with the remainder of the live volumes.

The only challenge I see is that any changes that are made are
dynamic, and would not
survive a reboot or a daemon restart. So, somehow, upon a restart, the
ietd daemon needs
a method to reliably determine which volumes it should or should not
be serving, or be
told what to server by heartbeat or the state of the drbd volume.

On Tue, May 11, 2010 at 12:52 PM, Bart Coninckx
<bart.coninckx at telenet.be> wrote:
> On Tuesday 11 May 2010 16:09:08 Michael Iverson wrote:
>> ietadm is the answer.
>>
>> These might help:
>>
>> http://old.nabble.com/IET-on-DRBD-howto--td20567810.html
>> http://www.gossamer-threads.com/lists/linuxha/users/45280
>> http://www.markround.com/archives/50-Building-a-redundant-iSCSI-and-NFS-clu
>> ster-with-Debian-Part-4.html
>>
>> On Tue, May 11, 2010 at 9:51 AM, Bart Coninckx <bart.coninckx at telenet.be>
> wrote:
>> > On Tuesday 11 May 2010 15:15:34 Michael Iverson wrote:
>> >> I've done about zero research into this, but perhaps you could run two
>> >> separate daemon instances, one listening on each IP.
>> >>
>> >> On Tue, May 11, 2010 at 8:55 AM, Bart Coninckx
>> >
>> > <bart.coninckx at telenet.be>wrote:
>> >> > On Tuesday 11 May 2010 12:58:45 Michael Iverson wrote:
>> >> > > I'd be quite interested as well, obviously. So this is what we would
>> >> > > end up with:
>> >> > >
>> >> > > Host A is primary for drbd volume 1, and secondary for drbd volume
>> >> > > 2. It acts as an iSCSI target for whatever's on volume 1.
>> >> > >
>> >> > > Host B is primary for volume 2, and secondary for volume 1. It acts
>> >> > > as a target for whatever's on volume 2.
>> >> > >
>> >> > > If either node fails, the opposite node takes over the secondary
>> >> > > volume, and exports its fallen comrade's iSCSI targets.
>> >> > >
>> >> > > This idea could possibly be extended with Ben's approach of one DRBD
>> >> > > volume per iSCSI target. (Except that it would be in a
>> >> > > primary/secondary role, instead of primary/primary.) This would make
>> >> > > the process of rebalancing the load between the two nodes fairly
>> >> > > trivial.
>> >> > >
>> >> > > Mike
>> >> > >
>> >> > > On Tue, May 11, 2010 at 5:09 AM, Bart Coninckx
>> >> > > <bart.coninckx at telenet.be
>> >> >
>> >> > wrote:
>> >> > > >> It is. I'm planning to showcase this in one of our upcoming
>> >> > > >> webinars.
>> >> > > >>
>> >> > > >> Cheers,
>> >> > > >> Florian
>> >> > > >
>> >> > > > Excellent, any timeframe on this? As it happens I'm dealing with a
>> >> >
>> >> > setup
>> >> >
>> >> > > > now that could definitely benefit from this.
>> >> > > >
>> >> > > > B.
>> >> > > > _______________________________________________
>> >> > > > drbd-user mailing list
>> >> > > > drbd-user at lists.linbit.com
>> >> > > > http://lists.linbit.com/mailman/listinfo/drbd-user
>> >> >
>> >> > Agreed, but what might be less trivial is to convince a running IETD
>> >> > target to
>> >> > have the config for the "other" targets merged to the existing targets
>> >> > and at
>> >> > the same time bind to the new secondary IP address, preferably while
>> >> > not breaking running operation. This all should be taken care of by
>> >> > Heartbeat.
>> >> >
>> >> > I'm going to try to dive into the challenge and report back to the
>> >> > list, unless the webinar would happen fairly soon.
>> >> >
>> >> >
>> >> > B.
>> >> > _______________________________________________
>> >> > drbd-user mailing list
>> >> > drbd-user at lists.linbit.com
>> >> > http://lists.linbit.com/mailman/listinfo/drbd-user
>> >
>> > Not possible:
>> >
>> > http://sourceforge.net/mailarchive/message.php?msg_id=02dd01c8263f%244496
>> >ae60%245dd810d1%40e3demo
>> >
>> >
>> > Rgds,
>> >
>> > B.
>> > _______________________________________________
>> > drbd-user mailing list
>> > drbd-user at lists.linbit.com
>> > http://lists.linbit.com/mailman/listinfo/drbd-user
>>
>
> Building a HA lcuster with IETD and DRBD is not really challenging, has been
> done numerous times. The challenge would be having a active/passive one on
> which each node is both active for some LUNs and active for others, especially
> at failover.
>
> I don't quite get the suggestion on the first link, having a active-active one
> and both nodes serving stuff. But I guess it would not distribute load in
> between two nodes, what my fist idea would do.
>
>
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
>



-- 
Dr. Michael Iverson
Director of Information Technology
Hatteras Printing



More information about the drbd-user mailing list