On Apr 24, 2006, at 1:19 PM, Lars Marowsky-Bree wrote:
On 2006-04-24T13:01:50, Andrew Beekhof <[EMAIL PROTECTED]> wrote:
Comments please?
The recovery seemed a bit harsh, however we already move all healthy
resources away before fencing a node so it isn't so horrible.
Ah, this would be impossible in Alan's proposal. The node would be
blocked at the CCM level, and thus we couldn't communicate with said
node to move any resources away.
oh... missed that connection :-(
Handling it at the CRM level would be better for this exact reason.
could we perhaps use attrd and a rsc_location rule to stop the "bad"
side?
i haven't thought this through at all, but you'd get dampening, it
would be crm-driven, and you avoid fencing (unless the stop fails).
the hard bit is deciding who should send what values to attrd.
just a thought.
I assume the idea is that until un-banned, the node can't join the
cluster? At least that prevents shooting the node over and over
again. For this reason I think un-banning needs to be a manual
process.
Right.
Actually that's an issue with our current fencing mechanism, we can
only
fence, but don't have an explicit "unfence" operation. We might
need to
consider how to model that.
We might need to be careful that a bunch of banned nodes aren't able
to form a cluster of their own and start managing resources.
Good point. Until they have quorum, they shouldn't.
even after that they shouldnt... because presumably they have the
"bad" side of the resource
and depending on no_quorum_policy, they might do so anyway.
--
Andrew Beekhof
"No means no, and no means yes, and everything in between and all the
rest" - TISM
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
