Lars Marowsky-Bree wrote:
> On 2007-04-12T08:05:29, Alan Robertson <[EMAIL PROTECTED]> wrote:
>
>> So, if you would consider an R2/CRM/CIB configuration, it interacts with
>> STONITH in a completely different way, which might not be ideal either,
>> but it should start the other resources (you can _make_ it start the
>> other resources).
>
> It'll start them as long as no fencing is required during startup; so in
> an otherwise healthy cluster (except for the STONITH monitor/start
> failure), the rest will come up automatically - you don't have to "make"
> it do that.
But, the default is to require fencing during some cluster startups -
those where everything doesn't come up at once.
In this case, no resources will be started unless you disable initial
fencing.
That's what I meant by "have to make it".
Let's say you have a 5 node cluster with one broken node - for some
reason, and STONITH broken in this fashion.
Then until you fix the node or the stonith device, or reconfigure it to
not require initial fencing, then no resources should be started.
As I said, this is much better than the R1 behavior.
I'm not 100% sure what happens if a node that was scheduled to be
STONITHed with a broken STONITH device comes up on its own and joins the
cluster.
But, no matter how you look at it, it's better than the R1 behavior.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________
Linux-HA mailing list
[EMAIL PROTECTED]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
