Re: [ClusterLabs] Installed Galera, now HAProxy won't start

2016-03-20 Thread Matthew Mucker
To close the loop, this was the root cause of the problem. There are several 
configuration files that mySQL reads at startup, and later files in the chain 
overwrite settings from files earlier in the chain. I had to edit two or three 
config files on each node to get mySQL to stop binding to 0.0.0.0 (netstat -tl 
is your friend!) but once I did the HAProxy clustered resource came back online.


Hopefully there's enough information in this thread to help those coming across 
this problem after me.


From: Ian 
Sent: Wednesday, March 16, 2016 8:27 PM
To: Cluster Labs - All topics related to open-source clustering welcomed
Subject: Re: [ClusterLabs] Installed Galera, now HAProxy won't start

> configure MariaDB server to bind to all available ports 
> (http://docs.openstack.org/ha-guide/controller-ha-galera-config.html, scroll 
> to "Database Configuration," note that bind-address is 0.0.0.0.). If MariaDB 
> binds to the virtual IP address, then HAProxy can't bind to that address and 
> therefore won't start. Right?

That is correct as far as my understanding goes.  By binding to port 3306 on 
all IPs (0.0.0.0), you are effectively preventing HAProxy from being able to 
use port 3306 on its own IP and vice-versa.

Try setting specific bind addresses for your Galera nodes; I would be surprised 
and interested if it didn't work.
OpenStack Docs: 
Configuration
docs.openstack.org
SELinux¶ Security-Enhanced Linux is a kernel module for improving security on 
Linux operating systems. It is commonly enabled and configured by default on 
Red Hat ...


___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org


[ClusterLabs] Moving resources and implicit bans - please explain?

2016-03-19 Thread Matthew Mucker
I have set up my first three-node Pacemaker cluster and was doing some testing 
by using "crm resource move" commands. I found that once I moved a resource off 
a particular node, it would not come back up on that node. I spent a while 
troubleshooting and eventually gave up and rebuilt the node.

After rebuild, the same thing happened. I then found in the documentation for 
the crm_resource command under the move command "NOTE: This may prevent the 
resource from running on the previous location node until the implicit 
constraints expire or are removed with −−unban"

This is a regrettably vague note. What dictates the conditions for "may 
prevent?" How do I determine what implicit constraints are present on my 
resources and when they'll expire?

I did find that explicitly removing bans with crm_resource -U solved my 
problem. However, I'd like to understand this further. Any explanation would be 
appreciated. A Google search on "pacemaker move resource ban" didn't find me 
anything that was obviously authoritative.

I'd appreciate any expertise the community could share with me!

Thanks,

-Matthew
___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org