Changing Corosync/Heartbeat pair's active node based on MySQL/Galera cluster state

Posted by Hace on Server Fault See other posts from Server Fault or by Hace
Published on 2012-06-04T10:09:55Z Indexed on 2012/06/04 10:43 UTC
Read the original article Hit count: 292

Background

I'm planning on building a High Availability "cluster" for our Zabbix instance by placing two physical servers in one server room and two in another server room.

In each server room one of the physical servers will run Zabbix on RHEL and the other will run Zabbix's MySQL database, also on RHEL. I'd prefer synchronous replication for the MySQL nodes so I'm planning on using Galera in a master-slave configuration. The Zabbix instances on the two Zabbix servers would be controlled by Heartbeat/Corosync (although Red Hat Cluster Suite is also an option...)

If the Zabbix server in Server Room A goes down, the one in Server Room B becomes active (and vice versa). Ditto for the MySQL servers/instances.

If either of those cases happen, however, the connection between the Zabbix server and the MySQL server becomes significantly slower as ti has to travel over WAN.

Question

Is it possible to configure the Heartbeat/CoroSync pair to instruct the MySQL/Galera cluster to change the master node to switch to (if available) the one that's in the server room as the active Heartbeat/Corosync -node and (more challengingly) is it possible to do the same in the other direction, i.e have the Galera cluster change the active Heartbeat/CoroSync server to be in the same room as the active MySQL master server in case of a failover in over to avoid unnecessary WAN transfers between the application and its DB?

Theories

Most likely I can get CoroSync to run something that'd log in to one of the DB nodes to change the MySQL/Galera master but I don't know if it's really possible to do anything similar in the other direction in Galera.

Is it possible to define a "service" in CoroSync/Heartbeat so that both the service and its MySQL service would migrate as one if possible. Using the DB server that's behind WAN should still be a better option to DB downtime.

Am I just using too many tools to solve a problem that'd be far simpler with something else?

© Server Fault or respective owner

Related posts about linux

Related posts about clustering