[Pacemaker] Andrew and Lars please confirm this.

[Andrew Beekhof]

On Wed, Mar 4, 2009 at 05:46, Romi Verma <romi3rdfeb at gmail.com> wrote:
> Thanks Andrew,
>
>
>>
>>
>> Pacemaker has various options for how it behaves during a split-brain, but
>> 1) Its more desirable to avoid them in the first place
>> 2) None of the strategies are (yet) really suited to failing over from
>> one physical location to another
>
>
> i could not understand the second point.  i am new to openais-pacemaker ,
> but as far as i know we have lots of stoniths . for example if we have
> configured ilo properly then we can use riloe stonith and fence the node
> residing in other partiton. what is stopping us and why we are saying that
> we dont support cluster whose nodes spans over multiple site?? could you
> please explain it bit more.

How does a node in Australia connect to a stonith device in Germany if
the network is down?
Or more generally, how can the nodes in Australia ensure that the
nodes in Germany are not running the same services?

How do you even know that the nodes in Australia should take over?

Things generally become much more complex (and have non-obvious
implications) in a multiple-site scenario.

> and when u say "None of the strategies are (yet) really suited to failing
> over from
> one physical location to another"
> does it apply to nodes who sapns over adjancent rooms also.??

At the Pacemaker level, distance isn't the issue.  Distance only
increases the chance of the problem occurring (and complicates
fencing).

What we don't handle well is the idea of partitioning the cluster into
"sites" consisting of _multiple_ servers.
Whether those sites are 10cm or 10,000km apart isn't the main issue -
the problem is being able to treat them as a logical entity where some
events result in services being moved around within the site, and
other events cause _all_ the services to be moved to another site.

There are some tricks that allow an approximation of this, but its not
a complete solution and is far easier to get wrong than right.