Main Page
From ClusterLabs
| Table of contents |
Welcome
Welcome to the home of Pacemaker - The scalable High-Availability cluster resource manager formerly part of Heartbeat.
This page and site are extremely bare. More information will be published soon.
Pacemaker is NOT a Fork of Heartbeat
It seems to be a common misconception. See the project history below.
Project History
Pacemaker came to life in 2004 when Lars (http://www.advogato.org/person/lmb/diary.html) convinced SUSE (http://www.novell.com/linux/) to hire me to implement a new cluster resource manager for Heartbeat. Although simple to configure, the old version 1 cluster manager had four key deficiencies
- Maximum of 2-nodes
- Highly coupled design and implementation
- Overly simplistic group-based resource model
- Inability to detect and recover from resource-level failures
A year and a half later, on Saturday July 30 (2005), Heartbeat 2.0.0 was released containing the first public version of the CRM.
Then, at the end of 2007, the decision was made to spin-off the CRM into its own project after the 2.1.3 Heartbeat release in order to
- support both the OpenAIS and Heartbeat cluster stacks equally
- decouple the release cycles of two projects at very different stages of their life-cycles
- foster clearer package boundaries, thus leading to
- better and more stable interfaces
This transition was completed on January 16, 2008 with the 0.6.0 release of Pacemaker which was the first to support both cluster stacks. The (feature frozen) 0.6 stable series is derived from, and fully compatible with, the 2.1.3 CRM and will receive bug-fix-only updates throughout the rest of 2008.
Feature parity and the overhaul of a number of old design decisions are the two key criteria for 1.0 status.
Architecture
| Component | Description |
|---|---|
| stonithd | The Heartbeat fencing subsystem. |
| lrmd | Short for Local Resource Management Daemon. Non-cluster aware daemon that presents a common interface to the supported resource types. Interacts directly with resource agents (scripts). |
| pengine | Short for Policy Engine. Computes the next state of the cluster based on the current state and the configuration. Produces a transition graph contained a list of actions and dependancies. |
| tengine | Short for Transition Engine. Co-ordinates the execution of the transition graph produced by the Policy Engine. |
| cib | Short for Cluster Information Base. Contains definitions of all cluster options, nodes, resources, their relationships to one another and current status. Synchronizes updates to all cluster nodes. |
| crmd | Short for Cluster Resource Management Daemon. Largely a message broker for the PE, TE and LRM. Also elects a leader to co-ordinate the activities of the cluster. |
| plugin | An OpenAIS plugin that spawns Pacemaker processes and relays cluster messages and membership information to the CIB and crmd. |
| ccm | Short for Consensus Cluster Membership. The Heartbeat membership layer. |
| openais | The OpenAIS messaging and membership layer. |
| heartbeat | The Heartbeat messaging layer. |
Helpful Links
Contact
Email Lists
Looks like we're being moderated over at linux-ha.org so I've set up a list here. http://list.clusterlabs.org
Searchable Archives
- http://www.mail-archive.com/pacemaker@clusterlabs.org/
- http://www.gossamer-threads.com/lists/linuxha/pacemaker/
- http://marc.info/?l=pacemaker
- http://dir.gmane.org/gmane.linux.highavailability.pacemaker
IRC
Developers usually hang out at irc.freenode.org on the #linux-ha and #linux-cluster channels
Bugzilla
We've now arranged for Pacemaker bugs to be hosted by the Linux Foundation.
Sharing a bugzilla with Heartbeat and OpenAIS will have the benefit of easily being able to reassign bugs between the three clustering projects.
New Pacemaker bugs can be created at:
http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
The product also supports supports voting, which we will use to help determine what order features/bugs are processed in.
The "old" system, http://bugs.clusterlabs.org, will be left up indefinitely for reference purposes.
Getting Involved
Things are pretty chaotic at the moment but we can always use:
- Testing support
- Code reviews
- People to write documentation
- People to answer questions on the mailing list
- A GUI that doesn't suck
Once things settle down, sufficiently motivated people may also wish to volunteer to maintain some of the CRM's subsystems (thus allowing me to concentrate on the Policy Engine).
