On 2007-04-10T11:56:59, Michael Schwartzkopff <[EMAIL PROTECTED]> wrote:
> > > At the moment I would like to have that parameter since interop between
> > > LVS and CLUSTERIP is not tested at all. After these tests we can drop it.
> > One can't simply drop a parameter once introduced.
> Why not? My script is still marked alpha and not intended for production use.
> If it getts better variables get fixed.
True, but that means I can't just pull your changes in ;-) For the final
version, this should probably be removed. It seems we agree on this
one.
> > LVS vs clusterip is a good point, but that doesn't depend on this
> > setting, does it? As long as it's detected by the script as above.
> >
> > LVS doesn't work with the clusterip anyway, so that's not really a
> > problem.
> But I did not test what happens if the user configures both.
Just reject it and error out then - lvs_support doesn't work in clone
mode, that is fine.
The load_share parameter doesn't convey any additional meaning than
configuring it as a clone (or not). Cloning an IPaddr2 resource only
makes sense as a clusterip target.
> Per-node ordering might be not the right way. Think about the following. Four
> clones on four machines. Machine 3 dies and the first one has to take over.
> 1) Resource 1 is shout down
> 2) Resource 1 is started
> 3) Resource 3 is started.
>
> Between 1) and 2) there is no connectivity for resource 1.
Uhm. Of course. Machine 3 has just died. Of course there's no
connectivity until it is restarted.
> This might be up to several seconds, which is not acceptable in my
> oppinion.
But, there also won't be any IP rejects/denied being send, as none of
the other node replies to that specific hash bucket yet. So, it'll look
like a brief delay only.
> Is would be better just to start resource 3 on node 1.
That's what happens. If node3 crashed, we obviously don't stop the
resource - that's implied in the node hosting the resource being gone &
fenced.
> Basically there is no big difference between per-node ordering and global
> ordering.
There's a big difference for your case, though. No concurrent
invocations for the same clone on the same node, so you don't need to do
any locking in your script.
I don't see how your suggestion improves availability.
Thanks,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
