1
<chapter id="ch-intro"><title>Read-Me-First</title>
2
<section id="s-intro-scope">
3
<title>The Scope of this Document </title>
5
The purpose of this document is to definitively explain the concepts used to configure Pacemaker.
6
To achieve this, it will focus exclusively on the XML syntax used to configure the CIB.
9
For those that are allergic to XML, Pacemaker comes with a cluster shell; a Python based GUI exists, too, however these tools will not be covered at all in this document<footnote>
10
<para>I hope, however, that the concepts explained here make the functionality of these tools more easily understood.</para>
11
</footnote>, precisely because they hide the XML.
14
Additionally, this document is NOT a step-by-step how-to guide for configuring a specific clustering scenario.
15
Although such guides exist, the purpose of this document is to provide an understanding of the building blocks that can be used to construct any type of Pacemaker cluster.
18
<section id="s-intro-pacemaker">
19
<title>What Is Pacemaker?</title>
21
Pacemaker is a cluster resource manager.
22
It achieves maximum availability for your cluster services (aka. resources) by detecting and recovering from node and resource-level failures by making use of the messaging and membership capabilities provided by your preferred cluster infrastructure (either <ulink url="http://www.corosync.org/">Corosync</ulink> or <ulink url="http://XXXX/TODO">Heartbeat</ulink>).
24
<para>Pacemaker's key features include:</para>
25
<itemizedlist spacing="compact">
26
<listitem><para>Detection and recovery of node and service-level failures</para></listitem>
27
<listitem><para>Storage agnostic, no requirement for shared storage</para></listitem>
28
<listitem><para>Resource agnostic, anything that can be scripted can be clustered</para></listitem>
29
<listitem><para>Supports <ulink url="http://en.wikipedia.org/wiki/STONITH">STONITH</ulink> for ensuring data integrity</para></listitem>
30
<listitem><para>Supports large and small clusters</para></listitem>
31
<listitem><para>Supports both <ulink url="http://en.wikipedia.org/wiki/Quorum_(Distributed_Systems)">quorate</ulink> and <ulink url="http://devresources.linux-foundation.org/dev/clusters/docs/ResourceDrivenClusters.pdf">resource driven</ulink> clusters TODO: quorum-driven?</para></listitem>
32
<listitem><para>Supports practically any <ulink url="http://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations">redundancy configuration</ulink></para></listitem>
33
<listitem><para>Automatically replicated configuration that can be updated from any node</para></listitem>
34
<listitem><para>Ability to specify cluster-wide service ordering, colocation and anti-colocation</para></listitem>
35
<listitem><para>Support for advanced services type
36
<itemizedlist spacing="compact">
37
<listitem><para>Clones: for services which need to be active on multiple nodes</para></listitem>
38
<listitem><para>Multi-state: for services with multiple modes (eg. master/slave, primary/secondary)</para></listitem>
41
<listitem><para>Unified, scriptable, cluster shell</para></listitem>
44
<section id="s-intro-redundancy">
45
<title>Types of Pacemaker Clusters</title>
46
<para>Pacemaker makes no assumptions about your environment, this allows it to support practically any <ulink url="http://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations">redundancy configuration</ulink> including Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N.</para>
49
<figure id="fig-redundancy-active-passsive">
50
<title>Active/Passive Redundancy</title>
53
<imagedata fileref="images/pcmk-active-passive.png" width="10cm" depth="7.5cm" align="center"/>
55
<caption>Two-node Active/Passive clusters using Pacemaker and DRBD are a cost-effective solution for many High Availability situations.</caption>
60
<figure id="fig-redundancy-n-plus-one">
61
<title>Shared Failover</title>
64
<imagedata fileref="images/pcmk-shared-failover.png" width="10cm" depth="7.5cm" align="center"/>
66
<caption>By supporting many nodes, Pacemaker can dramatically reduce hardware costs by allowing several active/passive clusters to be combined and share a common backup node</caption>
71
<figure id="fig-redundancy-n-to-n">
72
<title>N to N Redundancy</title>
75
<imagedata fileref="images/pcmk-active-active.png" width="10cm" depth="7.5cm" align="center"/>
78
When shared storage is available, every node can potentially be used for failover.
79
Pacemaker can even run multiple copies of services to spread out the workload.
85
<section id="s-intro-architecture">
86
<title>Pacemaker Architecture</title>
87
<para>At the highest level, the cluster is made up of three pieces:</para>
88
<itemizedlist spacing="compact">
90
Core cluster infrastructure providing messaging and membership functionality (illustrated in red)
93
Non-cluster aware components (illustrated in green).
94
In a Pacemaker cluster, these pieces include not only the scripts that knows how to start, stop and monitor resources, but also a local daemon that masks the differences between the different standards these scripts implement.
97
A brain (illustrated in blue) that processes and reacts to events from the cluster (nodes leaving or joining) and resources (eg. monitor failures) as well as configuration changes from the administrator.
98
In response to all of these events, Pacemaker will compute the ideal state of the cluster and plot a path to achieve it.
99
This may include moving resources, stopping nodes and even forcing nodes offline with remote power switches.
103
<figure id="fig-stack-concept">
104
<title>Conceptual Stack Overview</title>
107
<imagedata fileref="images/pcmk-overview.png" width="10cm" depth="7.5cm" align="center"/>
109
<caption>Conceptual overview of the cluster stack</caption>
113
<para>When combined with Corosync, Pacemaker also supports popular open source cluster filesystems<footnote>
115
Even though Pacemaker also supports Heartbeat, the filesystems need to use the stack for messaging and membership and Corosync seems to be what they're standardizing on.
116
Technically it would be possible for them to support Heartbeat as well, however there seems little interest in this.
119
Due to recent standardization within the cluster filesystem community, they make use of a common distributed lock manager which makes use of Corosync for its messaging capabilities and Pacemaker for its membership (which nodes are up/down) and fencing services.
122
<figure id="fig-stack-ais">
123
<title>The Pacemaker Stack</title>
126
<imagedata fileref="images/pcmk-stack.png" width="10cm" depth="7.5cm" align="center"/>
128
<caption>The Pacemaker stack when running on Corosync</caption>
132
<section id="s-pcmk-internals">
133
<title>Internal Components</title>
134
<para>Pacemaker itself is composed of four key components (illustrated below in the same color scheme as the previous diagram):</para>
135
<itemizedlist spacing="compact">
136
<listitem><para>CIB (aka. Cluster Information Base)</para></listitem>
137
<listitem><para>CRMd (aka. Cluster Resource Management daemon)</para></listitem>
138
<listitem><para>PEngine (aka. PE or Policy Engine)</para></listitem>
139
<listitem><para>STONITHd</para></listitem>
142
<figure id="fig-stack-internal">
143
<title>Internal Components</title>
146
<imagedata fileref="images/pcmk-internals.png" width="10cm" depth="7.5cm" align="center"/>
148
<caption>Subsystems of a Pacemaker cluster</caption>
153
The CIB uses XML to represent both the cluster's configuration and current state of all resources in the cluster.
154
The contents of the CIB are automatically kept in sync across the entire cluster and are used by the PEngine to compute the ideal state of the cluster and how it should be achieved.
157
This list of instructions is then fed to the DC (Designated Controller).
158
Pacemaker centralizes all cluster decision making by electing one of the CRMd instances to act as a master.
159
Should the elected CRMd process (or the node it is on) fail...
160
a new one is quickly established.
162
<para>The DC carries out PEngine's instructions in the required order by passing them to either the LRMd (Local Resource Management daemon) or CRMd peers on other nodes via the cluster messaging infrastructure (which in turn passes them on to their LRMd process).</para>
163
<para>The peer nodes all report the results of their operations back to the DC and, based on the expected and actual results, will either execute any actions that needed to wait for the previous one to complete, or abort processing and ask the PEngine to recalculate the ideal cluster state based on the unexpected results.</para>
165
In some cases, it may be necessary to power off nodes in order to protect shared data or complete resource recovery.
166
For this Pacemaker comes with STONITHd.
167
STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and is usually implemented with a remote power switch.
168
In Pacemaker, STONITH devices are modeled as resources (and configured in the CIB) to enable them to be easily monitored for failure, however STONITHd takes care of understanding the STONITH topology such that its clients simply request a node be fenced and it does the rest.
added
removed
doc/Pacemaker_Explained/en-US/Ch-Intro.xml
