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 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.