Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tuesday 11 May 2010 19:12:23 Michael Iverson wrote: > 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%244 > >> >496 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 > Heartbeat normally takes care of both things: failing over and starting all resources at boot. I guess we need a Heartbeat resource agent that can use ietdadm. I really wonder what the webinar is about. B.