On Thu, 2018-01-18 at 08:22 +0100, Ulrich Windl wrote:
Ken Gaillot <kgail...@redhat.com> schrieb am 17.01.2018 um
17:04 in Nachricht
<1516205099.5103.3.ca...@redhat.com>:
On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:
Ken Gaillot <kgail...@redhat.com> schrieb am 16.01.2018
um
23:33 in Nachricht
<1516142036.5604.3.ca...@redhat.com>:
As we look to release Pacemaker 2.0 and (separately) update
the
OCF
standard, this is a good time to revisit the terminology and
syntax
we
use for master/slave resources.
I think the term "stateful resource" is a better substitute
for
"master/slave resource". That would mainly be a documentation
change.
If there will be exactly two states, it'll be bi-state
resource,
and
when abandoning the name, you should also abandon names like
promote
and demote, because they stick to master/slave.
So maybe start with describing what a stateful resource is,
then
talk
about names.
BTW: All resoiucres we have are "stateful", because they can be
in
started and stopped states at least ;-)
Good points.
A clone is a resource with a configurable number of instances
using
the
same resource configuration. When a clone is stateful, each
active
s/the same/a common/ # if they were the same, there could be no
differences
Nope, it's identical ... a single <clone>+<primitive> configuration
in
Pacemaker is used to generate all instances. The service's own
configuration doesn't change, either. Each instance is either
completely identical, and simply running on different nodes, or
handles
a subset of requests determined by information available at run-time.
instance is in one of two roles at any given time, and Pacemaker
two: just two or at least two?
Exactly two.
While it is easy to imagine more than two, or even more complex
scenarios (e.g. database server instances can serve as master for
certain tables and replicant for other tables), we don't see any
demand
for managing that via pacemaker, and it would require a complete re-
implementation (and someone with the resources to do that).
manages instances' roles via promote and demote actions.
NOw try to define what promote and demote do ;-)
A successful call to the resource agent's "start" action must leave
the
resource in a particular one of the roles (the default role, from the
cluster's point of view). A successful "promote" action must move an
instance from the default role to the non-default role, and a
successful "demote" action must move an instance from the non-default
role to the default role.
So, it's very generic from the cluster's point of view.
Too bad "roleful" isn't a word ;-)
As you mentioned, "state" can more broadly refer to started,
stopped,
etc., but pacemaker does consider "started in slave role" and
"started
in master role" as extensions of this, so I don't think
"stateful"
is
too far off the mark.
Maybe also state the purpose of having different roles here, and
define what a role as opposed to a state is.
That's part of the problem -- the purpose is entirely up to the
specific application.
Some use it for a master copy of data vs a replicated copy of data, a
read/write instance vs a read-only instance, a coordinating function
vs
an executing function, an active instance vs a hot-spare instance,
etc.
That's why I like "promoted"/"started" -- it most directly implies
"whatever role you get after promote" vs "whatever role you get after
start".
It would even be easy to think of the pacemaker daemons themselves as
clones. The crmd would be a stateful clone whose non-default role is
the DC. The attrd would be a stateful clone whose non-default role is
the writer. (It might be "fun" to represent the daemons as resources
one day ...)
Separately, clones (whether stateful or not) may be anonymous or
unique
(i.e. whether it makes sense to start more than one instance on
the
same node), which confuses things further.
"anonymous clone" should be defined also, just as unique: Aren't
all
configured resources "unique" (i.e. being different from each
other)?
I'm curious about more than two roles, multiple "masters" and
multiple "slaves".
It's a common model to have one database master and a bunch of
replicants, and with most databases having good active/active support
these says, it's becoming more common to have multiple masters, with
or
without separate replicants. It's also common for one coordinator
with
multiple workers.
Regards,
Ulrich
