[ClusterLabs] just some basics

[Ken Gaillot]

On 01/12/2017 11:53 AM, lejeczek wrote:
> hi everyone,
> 
> I'm going through some introductory stuff, reading about it all and one,
> ok, a few questions come to mind.
> I was hoping, before I find answers somewhere at end of the docs someone
> here could quickly clarify:
> 
> It is one cluster per node, right? Not like, that a cluster is
> denominated by hostname/IP and if a node has multiple netIFs/IPs one
> could have multiple clusters (on that node) as long as these use only
> unique node's netIF/IP ?

Correct

> Would relying on IP type of resources only be safe? I'd imagine there
> are some services/apps that, (when use shared/distributed storage)
> without user interacting with them do not need to be off (because do not
> lock/access anything) and user could not (obviously) interact when that
> IP is being off on a node.

Having only IP resources can sometimes be useful, but it has drawbacks.

First, what's the use of having the IP highly available, if the service
itself goes down? For example, if the IP is for a web server, and the
web service goes down on the node that currently has the IP, the cluster
won't know anything is wrong and so will leave the IP there.

Second, the shared storage access itself typically should be a cluster
resource, to be able to use fencing to recover from split-brain.

Lastly, if you're trying to think of ways to avoid fencing, there's no
safe way to do that. Even for just an IP, if two machines try to start
the same IP, packets will go sometimes to one and sometimes the other,
rendering the service unusable.

> These two questions I form having assumed that it's the nodes/machines
> that are monitored and are declared un/available(those IPs of nodes) and
> resources are simply targets for an action the cluster would perform,
> and have nothing to do with "un/available" decision making process - or
> - I've got it wrong and should keep on reading(regardless probably :)) ?
> 
> many thanks,
> L.

The cluster monitors both the nodes and the resources. By default, a
resource failure doesn't make a node unavailable, but that's configurable.

Also, configuring resources for your services gives you considerable
flexibility in pacemaker -- monitoring/failure handling, complex
dependencies between resources (location/ordering), and high-level
features such as node RAM/CPU utilization, time-based rules, etc.