[Pacemaker] dopd on openais

[Lars Ellenberg]

On Sat, Jun 06, 2009 at 04:33:48PM +0200, Lars Marowsky-Bree wrote:
> On 2009-06-06T10:59:44, Lars Ellenberg <lars.ellenberg at linbit.com> wrote:
> 
> > > On join of a drbd_<UUID> group, you could see who else is there and
> > > connect to them, and also figure out if people try to start on more than
> > > 2 nodes etc.
> > now since when do you want a dopd bypassing the crm?
> > to ensure that would be the crm's job, no?
> 
> I don't think of this as a bypass. OCFS2/DLM use similar mechanisms to
> ensure their internal integrity as well.
> 
> With drbd supporting active/active or active/passive, for example, the
> CRM/RA can't reliably tell whether the number of activated nodes is
> corrected (and this will get worse if >2 nodes ever are supported),
> without resorting to parse drbd's configuration file, which is icky (and
> relies on the configfile being identical on all nodes).

first, this was about the "dopd" functionality.
that is, to reduce the risk of going online with consistent but
out-of-date, stale, data, because of replication link failure.

you seem to at least mix a few other wishlist items in here.

second, I don't think it is the RAs job to force a particular
configuration.  If you configure "master-max=2" in the cib, and the drbd
config does not allow two primaries, promoting the second master will
fail.  so what.  the other way around, drbd.conf allowing two, but cib
only one master: no harm done at all.

I don't see the problem.

> And also this would reduce the amount of configuration necessary - ie,
> if the IP addresses were inherited from the OpenAIS configuration. (By
> default; of course this could be overridden.)

uh?

> Actually, how about storing the configuration of each drbd instance in
> the instance's meta-data?

sure, possible.

> With internal meta-data, for example, one could then simply say: "start
> device XXX".

you can say that now?
or am I misunderstanding you again?
again nothing to do with "fence peer", mark outdated .

> If the meta-data then was distributed using OpenAIS (say, in a
> checkpoint, quite easy to do I'm told ;-), on the second node, the
> initial setup would be reduced to "drbdadm clone <drbd-id>
> <local-device>"
> 
> There could be a start-or-clone command too (maybe even the default?)
> which would do the right thing (either resync if a copy already existed
> or do a full clone), easing recovery of failed nodes.

I don't follow.
what is it you want to achieve?

> And if the configuration is distributed using OpenAIS, doing a "drbdadm
> configure change syncer-speed 10M" would immediately affect all nodes
> w/o needing to manually modify drbd.conf everywhere.

if you want to "distribute" the drbd config file, use csync2.

if you want get rid of the drbd config file, store everything necessary
in the cib, then rewrite the drbd RA to get all parameters passed in,
drop drbdadm and use drbdsetup directly.
absolutely no need to write yet an other distributed config based on
openais (or other) thingy, when we already have one: the cib.

> Eventually, such a distributed user-space daemon could also allow you to
> shift the meta-data handling and processing from the kernel. Might
> appeal to some. ;-)

exactly who shall be authoritative on which replica contains the
most up-to-date data generation?

> > what we actually are doing right now is placing location constraints on
> > the master role into the cib from the "fence-peer" handler, and removing
> > them again from the "after-sync-target" handler.  sort of works.
> 
> Here I think we need a more extensive discussion. Why doesn't your
> handler modify the master score instead, but add additional
> constraints?

why not.
could easily be changed.

but there is even a technical reason: shoot-out in two-primary.
both try to create the "no-one but me is uptodate" constraint,
with the same xml id.  the first one to place it succeeds.

> There's a lot of random thoughts in the above, hence my hope that
> someone (i.e., you ;-) would come up with a coherent design for how the
> _optimal_ integration between drbd/OpenAIS/Pacemaker could look like ...
> ;-)

lets wait for drbd 8.3.2, and then maybe pick this up again.

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