4

I'm moving a Heartbeat + Pacemaker setup to openSUSE 12.1. It turns out that Heartbeat isn't supported on this platform anymore, and therefore it is not available from the official repos.

Switching to Corosync isn't really a problem, but I'm curious why this particular decision was made. Is Heartbeat depreciated or is this a distro-specific maintenance problem? What are the benefits of using Corosync as a messaging layer in a HA context?

Szymon Jednac
  • 143
  • 6

1 Answers1

3

I am late to reply to your question, but here goes:

  1. Yes heartbeat is deprecated.
  2. No this is not a distro specific problem
  3. There are a lot of benefits to using Corosync instead of heartbeat, the first and foremost is point number 1 above. Still, I will list as many as I know of here.

Comparison of features:

  1. First off the only benefit(IMO) of using Heartbeat over Corosync is its easier to configure and you can get it running in a matter of few minutes even if you are doing it for the first time. Corosync requires a lot of patience and love.

  2. Heartbeat allows us to define a single primary for all resources, whereas on corosync you can assign different primaries for different resources.

  3. Resource stickiness can be defined with corosync(not available in heartbeat). Resource Stickiness is the priority of resource ownership. Lets say there's a 2 server cluster having Server1 & Server2. Server1 is primary with all active resources and Server2 is secondary. One fine day Server1 goes down and Server2 becomes primary making all its resources active. Now, if this was a Heartbeat cluster it would cause headaches adding back Server1, where as with Corosync(with resource stickiness defined) it would keep Server2 as a primary even if server1 was brought up later.

  4. With corosync you don't need to worry about maintaining the same version of cluster configuration. Corosync clusters automatically sync configuration amongst all the constituent servers, hence minimizing issues caused by operator error.

  5. Heartbeat allows creation of a two node cluster, corosync has a much higher limit(I don't remember the exact number).

  6. Corosync allows resource colocation. There are times when we group a set of resources and want a particular group to run from one server. With Corosync its possible to create such groups and assign different primaries to each group, thereby maximizing compute/network utilization.

  7. It might take some effort but you can also look up Stonith, which is a handy feature to avoid data corruption or conflicts in cluster. Stonith is short for Shoot The Other Node In The Head. And is meant to take care of nodes(switch them off forcefully) which might be having hw/load or other issues.

n3rV3
  • 193
  • 5
  • Correct me if I'm wrong, but aren't those mostly pacemaker features? (stickiness, resource management, stonith and so on) – Szymon Jednac May 21 '13 at 14:01
  • 1
    All these can only be defined if you were using a newer messaging layer similar to corosync. That is the point I was trying to emphasize here. – n3rV3 May 22 '13 at 05:56