Linux High Availability – Alternatives to Heartbeat, Pacemaker, and CoroSync

Knowing what the problem actually is would, as Kamil says, be awfully useful information. However, I've got a few problems for you straight off the bat:

• Your IP address has five octets: 192.168.250.xxx.xxx
• I'm not aware of an operation called 'minitor': op minitor interval="60s" timeout="30s"
• I use the lsb:mysql class, rather than ocf:heartbeat:mysql; if you're having problems with that part of things, it might be worth giving it a go.
• You probably don't want virtual_master_ip and virtual_slave_ip in the same group if you've got a -INF colocation constraint. That'll give pacemaker an arrythmia.

I'm not even sure that you want to be doing what you think you're doing, though. I'd be more inclined to setup two resources, mysql_as_master and mysql_as_slave, which makes sure that MySQL is running in the appropriate mode on the machine (I'd be starting MySQL with the read-only option set on the command line, rather than jiggering with the config file, and using the mysql client to query the running server to ensure that it's running read-only or read-write, as required), and then grouping them with the associated IP address.

Does EC2 monitor the health of services inside the guests?

If not, and that is something you want, then Pacemaker would be relevant here. Corosync probably isn't an option yet as it only does mcast and bcast, so it would be a pacemaker+heartbeat scenario.

Here's a guide to how people do it with linode instances, much of it is likely to also be relevant on EC2: http://library.linode.com/linux-ha/

To answer the question of what the pieces are, Pacemaker is the thing that starts and stops services and contains logic for ensuring both that they're running, and that they're running in only one location (to avoid data corruption).

But it can't do that without the ability to talk to itself on the other node(s), which is where heartbeat and/or corosync come in.

Think of heartbeat and corosync as a bus that any node can throw messages on and know that they'll be received by all its peers. The bus also ensures that everyone agrees who is (and is not) connected to the bus and tells you when that list changes.

For two nodes Pacemaker could just as easily use sockets, but beyond that the complexity grows quite rapidly and is very hard to get right - so it really makes sense to use existing components that have proven to be reliable.