[ClusterLabs] Merging clusters
Ken Gaillot
kgaillot at redhat.com
Tue Jun 9 14:57:25 UTC 2015
On 06/05/2015 03:50 PM, Carlos Xavier wrote:
> Hi.
>
> We are running two separated clusters, mainly due to the use of DRBD.
> Now the clusters are being moved to VmWare hosts and a storage will be available, so DRBD will not be needed anymore. Also new
> requirements are on place.
>
> Below is what do we have today and what we want to achieve.
>
> HTTP cluster MySQL cluster
> http_server_A http_server_B MySQL_server_BKP MySQL_server
> | | | |
> ------------------------------ ----------------------------
> |OCFS2 shared disk /export | |OCFS2 shared disk /data |
>
>
> One cluster
> http_server_A http_server_B MySQL_server_BKP MySQL_server
> | | | | |
> -------------------------------------- ---------------------------
> |OCFS2 shared disk /export | |OCFS2 shared disk /data |
>
>
> The MySQL_server_BKP will have access to both filesystems and will run as a http server and eventually as a mysql server when in
> failover.
> It will have access to 2 SBD devices
> The MySQL server cant mount the cloned filesystem /export nor can start a clone http server.
> The http servers cant mount the cloned filesystem /data nor can start the MySQL server.
>
> I saw some examples of negating the start of one resource for one server, but I have no clue on how to do this for more tha one
> server.
>
> How can I do this for two or more servers?
> What are the constraints that have to be set?
Constraints work the same regardless of the number of nodes. Simply
configure a constraint for each resource/node combination. A positive
score means prefer the node for that resource, and a negative score
means avoid the node for that resource.
To make it so that a node can never run a resource, add a location
constraint with a score of -INFINITY.
In your example, you probably want -INFINITY location constraints for
your mysql-related resources on the http servers, and -INFINITY location
constraints for your apache-related resources on MySQL_server.
To use MySQL_server_BKP only when one of the others is down, give
positive (but not INFINITY) scores for each resource on the nodes
they're allowed on, and make sure the "main" servers have a higher score
than the backup. Unless you really want to avoid MySQL_sever_BKP
(perhaps it's slower?), it's fine to skip this step and let the cluster
do its thing -- there's no need to specify one as "backup", because the
cluster will use whatever nodes are up.
This assumes you're using the default symmetric-cluster=true (aka
"opt-out" cluster). For details see
http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/index.html#idm254536793808
> Any help are very welcome
> Regards,
> Carlos.
More information about the Users
mailing list