[Linux-ha-dev] Quorum server and split-site

[Serge Dubrouski]

On Thu, Feb 14, 2008 at 11:22 AM, Lars Marowsky-Bree <lmb at suse.de> wrote:
> In a call today the question was raised why I considered the quorumd
>  design, as it stands today, as not capable of supporting split-side
>  configurations.
>
>  The call was a bit tight, so I'd like to elaborate here:
>
>  1. Consider the easy case of 2 nodes at two sites, with a 3rd quorum
>  server somewhere.
>
>  2. Consider loss of link between the two sites; possibly site A also
>  loses connection to the quorum server.
>
>  3. After a timeout, the quorum server will grant quorum to site B; site
>  A will have lost it.
>
>  4. Site A will try to stop resources as soon as it loses quorum. However
>  it _cannot deal with stop failures_ at this stage.
>
>  It cannot use fencing, as the current setup cannot differentiate between
>  two sites, and doesn't know it has to consider the other site dead
>  already. (It'd block eternally.) Further, if there's just one node, the
>  suicide plugin wouldn't work - see the discussion on the linux-ha list.
>
>  The same scenario occurs with >2 nodes, just more so - the system
>  doesn't know the difference between site-local and site-remote fencing,
>  and cannot cope.
>
>  Basically, quorumd only "works" in scenarios where fencing is not
>  required and stop failures don't hurt; most of the time, DR scenarios
>  are requested for mission critical services though.
>
>
>  There's also the rathert fundamental design issue that I don't
>  personally like the stretched cluster implementation as-is; running a
>  local cluster protocol over a WAN link is not exactly perfect. However,
>  that could be considered an inefficiency; the limitations above limit
>  the use cases of the quorum server to a very, very small subset.

I can't agree more on this point. In fact local clustering products
and DR organizing products are usually considered as different
products as Oracle RAC and Oracle DataGuard for example. First case
usually involves shared data storage and heavy heartbeat protocol
while second one requires data replication and some kind of
controlling of the state for the primary site and switching DR site to
active state if primary fails. Trying to use Heartbeat protocol over
WAN sounds like not a really good idea. WAN could create high latency
and provoke false failovers that would make a whole project more
unstable.


>
>  I personally favor the cluster-of-clusters approach, but I concede that
>  I don't have working code for that either. ;-)
>
>
>  Regards,
>     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-Dev: Linux-HA-Dev at lists.linux-ha.org
>  http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>  Home Page: http://linux-ha.org/
>



-- 
Serge Dubrouski.