[ClusterLabs] how to setup single node cluster

[Ken Gaillot]

On Fri, 2021-04-09 at 08:20 +0300, Andrei Borzenkov wrote:
> On 08.04.2021 09:26, d tbsky wrote:
> > Reid Wahl <nwahl at redhat.com>
> > > I don't think we do require fencing for single-node clusters.
> > > (Anyone at Red Hat, feel free to comment.) I vaguely recall an
> > > internal mailing list or IRC conversation where we discussed this
> > > months ago, but I can't find it now. I've also checked our
> > > support policies documentation, and it's not mentioned in the
> > > "cluster size" doc or the "fencing" doc.
> > 
> >    since the cluster is 100% alive or 100% dead with single node, I
> > think fencing/quorum is not required. I am just curious what is the
> > usage case. since RedHat supports it, it must be useful in real
> > scenario.
> 
> 
> I do not know what "disaster recovery" configuration you have in
> mind,
> but if you intend to use geo clustering fencing can speed up fail-
> over
> so it is at least useful.
> 
> Even in single node cluster if resource failed to stop you are stuck
> -
> you cannot actually do anything from that point without manual
> intervention. Depending on configuration and requirements rebooting
> node
> may be considered as an attempt to automatically "reset" cluster
> state.

The use case for a single-node disaster recovery cluster is to have the
main cluster be a full, multi-node cluster with fencing, with a single-
node cluster at a remote site for disaster recovery when the main
cluster is down (possibly for just the most essential resources).

Fencing isn't critical for the DR site because if the DR site is being
used, the main site is already down.

The DR site could be activated automatically with booth (if a third
arbitrator site is available), or manually by an administrator (for
example by changing the target-role resource default, or manually
assigning tickets).

The advantages of using a cluster at all at a manual DR site are that
administrators can use the same cluster management commands they're
familiar with, and certain resources can always run at the DR site to
keep it ready (e.g. shared storage or a database replicant).

There are some ideas about making such a setup easier to manage, such
as being able to coordinate configuration changes (each site has a
separate cluster configuration), and maybe having "storage agents" to
manage shared storage across clusters.
-- 
Ken Gaillot <kgaillot at redhat.com>