This describes some of the feature differences between rgmanager and Pacemaker. Pacemaker generally has more features and better dependency support than RGManager. A partial or full rewrite of RGManager would be required in order to make RGManager be able to attain the same level of resource control as Pacemaker - so it really makes a lot of sense to just use Pacemaker.
Feature |
RGManager |
Pacemaker |
Resource Management Model |
Resource Group |
Resource-Dependency, Resource Group |
Dependency Models |
Collocation, Start-After |
User-defined |
Event Handling Model |
Distributed or Centralized |
Centralized |
CLI Management |
Status, Control |
Status, Control, Administration |
Fencing Model |
Assumed(7) |
Resource Level |
Multi State Resources |
No |
Yes |
Site Failover |
No |
Yes(1) |
Event Scripts |
Yes |
No(2) |
Maximum Node Count |
16~32(3) |
More |
Exclusive Services |
Yes |
Yes(4) |
Failover Domains |
Yes |
Yes(4) |
Resource Exclusion |
No |
Yes(4) |
Time-Based Resource Control |
No |
Yes(4) |
Resource Attribute Inheritance |
Yes |
Yes |
Shared Resources |
Yes |
Yes |
Cloned Resources |
Sort of(5) |
Yes |
Resource Agent APIs |
OCF(6), SysV |
OCF(6), SysV, Heartbeat |
Resource Freezing |
Yes |
Yes(8) |
Requires Quorum |
Yes |
Configurable |
Requires DLM |
Yes |
No |
Multi-Partition Resource Management |
No |
Yes(9) |
Non-root Administration |
No |
Yes |
Notes:
Pacemaker 1.2 feature
RIND was introduced in to rgmanager as a way to avoid implementing a dependency engine by making the business logic of RGManager external. It works fairly well, but is very complicated to use as it requires some amount of programming experience in order to use.
RGManager has a built-in distributed state replication algorithm which is inefficient as implemented. This is used to distribute service states individually.
Requires proper configuration of Pacemaker's dependencies.
RGManager supports resources shared between services by using reference counts so that only one instance of a resource is started on a node if multiple services are started there, but this is a different construct than a cloned resource which defines a number of clones cluster-wide.
RGManager does not implement the OCF-required monitor action; instead it uses status. It also stores its agents in a FHS/LSB location instead of OCF. Both Pacemaker and RGManager have diverged from the OCF RA API 1.0 draft in differing ways in order to support other features not possible with the original API draft specification.
RGManager waits for the cluster infrastructure to complete fencing before initiating recovery, whether or not any resources exist on a given node which require fencing. Pacemaker initiates fencing based on resource allocation - if a node has no resources requiring fencing, fencing of the host is not required to perform recovery.
Pacemaker lets you stop managing a resource in order to perform maintenance. This accomplishes the same task as freezing a service in RGManager.
If the cluster partitions, Pacemaker can elect a resource manager in each partition and continue managing the already-running resources within each partition without the need for fencing. You cannot start/stop new resource instances, of course.