[ClusterLabs] start a resource

Ken Gaillot kgaillot at redhat.com
Fri May 13 21:31:33 UTC 2016


On 05/06/2016 01:01 PM, Dimitri Maziuk wrote:
> On 05/06/2016 12:05 PM, Ian wrote:
>> Are you getting any other errors now that you've fixed the
>> config?
> 
> It's running now that I did the cluster stop/start, but no: I
> wasn't getting any other errors. I did have a symlink resource
> "stopped" for no apparent reason and with no errors logged.
> 
> The cluster is a basic active-passive pair. The relevant part of
> the setup is:
> 
> drbd filesystem floating ip colocated with drbd filesystem +inf 
> order drbd filesystem then floating ip
> 
> ocf:heartbeat:symlink resource that does /etc/rsyncd.conf ->
> /drbd/etc/rsyncd.conf colocated with drbd filesystem +inf order
> drbd filesystem then the symlink
> 
> ocf:heartbeat:rsyncd resource that is colocated with the symlink 
> order symlink then rsyncd order floating ip then rsyncd
> 
> (Looking at this, maybe I should also colocate rsyncd with floating
> ip to avoid any confusion in pacemaker's little brain.)

Not strictly necessary, since rsync is colocated with symlink which is
colocated with filesystem, and ip is also colocated with filesystem.

But it is a good idea to model all logical dependencies, since you
don't know what changes you might make to the configuration in the
future. If you want rsyncd to always be with the floating ip, then by
all means add a colocation constraint.

> But this is not specific to rsyncd: the behaviour was exactly the
> same when a co-worker made a typo in apache config (which is
> another resource on the same cluster). The only way to restart
> apache was to "pcs cluster stop ; pcs cluster start" and that
> randomly killed ssh connections to the nodes' "proper" IPs.

That is definitely not a properly functioning cluster. Something is
going wrong at some level.

When you say that "pcs resource cleanup" didn't fix the issue, what
happened after that? Did "pcs status" still show an error for the
resource? If so, there was an additional failure.





More information about the Users mailing list