Page MenuHomeClusterLabs Projects
Files F2822495

quickstart.html
No OneTemporary
Actions

quickstart.html
View Options

<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->
<head>
<!--#include virtual="/header.html" -->
<title>Cluster Labs - The Home of Pacemaker</title>
<meta name="description" content="">
</head>
<body>
<!--#include virtual="/banner.html" -->
<section id="main">
<!--#include virtual="/quickstart-common.html" -->
<h2>Quickstart Editions</h2>
<p>
We have a quickstart edition for each major distro. To
continue, select the distribution you'll be using:
<ul>
<li>
<a href="quickstart-redhat.html">RHEL 7</a> (and clones such as CentOS),
</li>
<li>
<a href="quickstart-redhat-6.html">RHEL 6</a> (and clones such as CentOS),
</li>
<li>
openSUSE and <a href="quickstart-suse.html">SLES 12</a>,
</li>
<li>
<a href="quickstart-suse-11.html">SLES 11</a>, or
</li>
<li>
<a href="quickstart-ubuntu.html">Ubuntu Precise LTS</a>
</li>
</ul>
</p>
<h2>Why Does Each Distribution Have its Own Quickstart?</h2>
<p>
Instead of re-inventing the wheel, Pacemaker makes use of
the messaging, membership and quorum capabilities of other
projects (such as Heartbeat or Corosync).
</p>
<p>
Pacemaker is fully functional with all three current
Corosync release series (1.2.x, 1.4.x and 2.0.x) as well
as Heartbeat. However this has been a source of confusion
because Pacemaker needs to be set up differently depending
on what each distribution ships. We call each combination
of Pacemaker + Corosync (or Heartbeat) a "stack".
</p>
<p>
For example, on RHEL6 the supported stack is based on CMAN
which has APIs Pacemaker can use to obtain the membership
and quroum information it needs. Although CMAN uses
Corosync underneath, it is configured via cluster.conf and
Pacemaker is started as a separate init script.
</p>
<p>
However SLES11 doesn't ship CMAN, so its users configure
corosync.conf directly and enable a custom plugin that
gets loaded into Corosync (because Corosync 1.4 doesn't
have the quorum and membership APIs needed by Pacemaker).
This plugin also starts Pacemaker automatically when
Corosync is started.
</p>
<p>
To confuse things further, SLES users start Corosync with
the openAIS init script because it used to be part of that
project.
</p>
<p>
Eventually everyone will move to Corosync 2 which removes
support for CMAN and custom plugins BUT natively includes
the APIs Pacemaker needs for quorum and membership. In
this case, users would configure corosync.conf and use the
Pacemaker init-script to start up after Corosync.
</p>
<p>
There are some architectural differences between the
different stacks, and some are more elegant than others,
but the most important thing by far is that everyone is
getting membership and quorum information from the same
place.
</p>
<p>
See <a href="http://theclusterguy.clusterlabs.org/post/34604901720/pacemaker-and-cluster-filesystems">this
post</a> for a longer discussion on the different stack
options and how they relate to cluster filesystems in particular.
</p>
</section>
<!--#include virtual="/footer.html" -->
</body>
</html>

File Metadata

Mime Type
text/html
Expires
Sat, Jan 25, 5:54 AM (20 h, 23 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
1295192
Default Alt Text
quickstart.html (3 KB)

Event Timeline