[ClusterLabs] How to set up fencing/stonith

[Ken Gaillot]

On Thu, 2018-05-17 at 09:44 -0600, Casey & Gina wrote:
> > > Barring that, where can I download source code packages?  I have
> > > only
> > > been able to find the github, which has 0.9 and 0.10 branches,
> > > but I
> > > can't find any .tar.gz's to download 
> > 
> > Really?
> > 
> > https://github.com/ClusterLabs/pcs/releases
> 
> Thank you - I hadn't seen the "releases" link on github before and
> somehow missed that.  Sorry for that.  I thought there would be
> download links somewhere on the clusterlabs website.  I will try
> compiling this today to try.
> 
> However, won't this have the same result as when I have attempted to
> use crm to add the stonith configuration?  Do you have any insight as
> to why the stonith resource is failing to start as documented in my
> other E-mail in this thread, or advice on how I can figure out what
> is wrong?

The fencing/stonith terminology is simply historical -- at one time,
there were two separate open-source clustering implementations (LHA and
RHCS), each with its own terminology. Now, it's converged, so they are
generally used interchangeably. Stonith is sometimes described as a
subset of fencing -- stonith is specifically power fencing, whereas
fabric fencing (disk and/or network cutoff) is also possible. But that
distinction isn't always used.

The LHA-style ("external/*") vs RHCS-style ("fence_*") fence agents are
another historical legacy. They're two different interface standards,
but serve the same purpose.

LHA-style agents require that pacemaker was compiled with support for
the cluster-glue library. That isn't the case for RHEL-based distros,
so pcs has never really been tested with them, to my knowledge.

As others have mentioned, cloning fence devices is no longer necessary
for the cluster to use the device -- all it will do is make every node
monitor the device.

Whether to use one fence resource for the whole cluster, or one for
each node, is partly a question of what the device requires and partly
a personal preference. Some devices (e.g. most IPMI) can only affect
one node, thus one-resource-per-node is the only option. Otherwise, the
only benefit of one-resource-per-node is that you can set a location
constraint such that a fence target is never monitoring its own fence
device (which would be almost pointless). There was a distant time when
such a constraint was a requirement for fencing to work, but now it's
just for monitoring.

I'm not familiar with VMware fencing, so I can't comment on the
specifics of the agents ...

> 
> Thank you in advance as always,
-- 
Ken Gaillot <kgaillot at redhat.com>