~ubuntu-branches/ubuntu/utopic/pacemaker/utopic-proposed

« back to all changes in this revision

Viewing changes to doc/Pacemaker_Explained/en-US/Ch-Nodes.txt

  • Committer: Package Import Robot
  • Author(s): Andres Rodriguez
  • Date: 2013-07-16 16:40:24 UTC
  • mfrom: (1.1.11) (2.2.3 experimental)
  • Revision ID: package-import@ubuntu.com-20130716164024-lvwrf4xivk1wdr3c
Tags: 1.1.9+git20130321-1ubuntu1
* Resync from debian expiremental.
* debian/control:
  - Use lower version for Build-Depends on libcorosync-dev
    and libqb-dev.
  - Build-Depends on libcfg-dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
= Cluster Nodes =
 
2
 
 
3
== Defining a Cluster Node ==
 
4
 
 
5
Each node in the cluster will have an entry in the nodes section
 
6
containing its UUID, uname, and type.
 
7
 
 
8
.Example Heartbeat cluster node entry
 
9
======
 
10
[source,XML]
 
11
<node id="1186dc9a-324d-425a-966e-d757e693dc86" uname="pcmk-1" type="normal"/>
 
12
======
 
13
 
 
14
.Example Corosync cluster node entry
 
15
======
 
16
[source,XML]
 
17
<node id="101" uname="pcmk-1" type="normal"/>
 
18
======
 
19
 
 
20
In normal circumstances, the admin should let the cluster populate
 
21
this information automatically from the communications and membership
 
22
data.  However for Heartbeat, one can use the `crm_uuid` tool
 
23
to read an existing UUID or define a value before the cluster starts.
 
24
 
 
25
[[s-node-name]]
 
26
== Where Pacemaker Gets the Node Name ==
 
27
 
 
28
Traditionally, Pacemaker required nodes to be referred to by the value
 
29
returned by `uname -n`.  This can be problematic for services that
 
30
require the `uname -n` to be a specific value (ie. for a licence
 
31
file).
 
32
 
 
33
Since version 2.0.0 of Pacemaker, this requirement has been relaxed
 
34
for clusters using Corosync 2.0 or later.  The name Pacemaker uses is:
 
35
 
 
36
. The value stored in 'corosync.conf' under +ring0_addr+ in the +nodelist+, if it does not contain an IP address; otherwise
 
37
. The value stored in 'corosync.conf' under +name+ in the +nodelist+; otherwise
 
38
. The value of `uname -n`
 
39
 
 
40
Pacemaker provides the `crm_node -n` command which displays the name
 
41
used by a running cluster.
 
42
 
 
43
If a Corosync nodelist is used, `crm_node --name-for-id $number` is also
 
44
available to display the name used by the node with the corosync
 
45
+nodeid+ of '$number', for example: `crm_node --name-for-id 2`.
 
46
 
 
47
[[s-node-attributes]]
 
48
== Describing a Cluster Node ==
 
49
 
 
50
indexterm:[Node,attribute]
 
51
Beyond the basic definition of a node the administrator can also
 
52
describe the node's attributes, such as how much RAM, disk, what OS or
 
53
kernel version it has, perhaps even its physical location.  This
 
54
information can then be used by the cluster when deciding where to
 
55
place resources.  For more information on the use of node attributes,
 
56
see <<ch-rules>>.
 
57
 
 
58
Node attributes can be specified ahead of time or populated later,
 
59
when the cluster is running, using `crm_attribute`.
 
60
 
 
61
Below is what the node's definition would look like if the admin ran the command:
 
62
      
 
63
.The result of using crm_attribute to specify which kernel pcmk-1 is running
 
64
======
 
65
[source,C]
 
66
-------
 
67
# crm_attribute --type nodes --node-uname pcmk-1 --attr-name kernel --attr-value `uname -r`
 
68
-------
 
69
[source,XML]
 
70
-------
 
71
<node uname="pcmk-1" type="normal" id="101">
 
72
   <instance_attributes id="nodes-101">
 
73
     <nvpair id="kernel-101" name="kernel" value="2.6.16.46-0.4-default"/>
 
74
   </instance_attributes>
 
75
</node>
 
76
-------
 
77
======
 
78
A simpler way to determine the current value of an attribute is to use `crm_attribute` command again:
 
79
 
 
80
[source,C]
 
81
# crm_attribute --type nodes --node-uname pcmk-1 --attr-name kernel --get-value
 
82
 
 
83
By specifying `--type nodes` the admin tells the cluster that this
 
84
attribute is persistent.  There are also transient attributes which
 
85
are kept in the status section which are "forgotten" whenever the node
 
86
rejoins the cluster.  The cluster uses this area to store a record of
 
87
how many times a resource has failed on that node but administrators
 
88
can also read and write to this section by specifying `--type status`.
 
89
 
 
90
== Corosync ==
 
91
 
 
92
=== Adding a New Corosync Node ===
 
93
 
 
94
indexterm:[Corosync,Add Cluster Node]
 
95
indexterm:[Add Cluster Node,Corosync]
 
96
 
 
97
Adding a new node is as simple as installing Corosync and Pacemaker,
 
98
and copying '/etc/corosync/corosync.conf' and '/etc/corosync/authkey' (if
 
99
it exists) from an existing node.  You may need to modify the
 
100
+mcastaddr+ option to match the new node's IP address.
 
101
 
 
102
If a log message containing "Invalid digest" appears from Corosync,
 
103
the keys are not consistent between the machines.
 
104
 
 
105
=== Removing a Corosync Node ===
 
106
 
 
107
indexterm:[Corosync,Remove Cluster Node]
 
108
indexterm:[Remove Cluster Node,Corosync]
 
109
 
 
110
Because the messaging and membership layers are the authoritative
 
111
source for cluster nodes, deleting them from the CIB is not a reliable
 
112
solution.  First one must arrange for corosync to forget about the
 
113
node (_pcmk-1_ in the example below).
 
114
 
 
115
On the host to be removed:
 
116
 
 
117
. Stop the cluster: `/etc/init.d/corosync stop`
 
118
 
 
119
Next, from one of the remaining active cluster nodes:
 
120
 
 
121
. Tell Pacemaker to forget about the removed host:
 
122
+
 
123
[source,C]
 
124
# crm_node -R pcmk-1
 
125
+
 
126
This includes deleting the node from the CIB
 
127
 
 
128
[NOTE]
 
129
======
 
130
This proceedure only works for versions after 1.1.8
 
131
======
 
132
 
 
133
=== Replacing a Corosync Node ===
 
134
 
 
135
indexterm:[Corosync,Replace Cluster Node]
 
136
indexterm:[Replace Cluster Node,Corosync]
 
137
 
 
138
The five-step guide to replacing an existing cluster node:
 
139
 
 
140
. Make sure the old node is completely stopped
 
141
. Give the new machine the same hostname and IP address as the old one
 
142
. Install the cluster software :-)
 
143
. Copy '/etc/corosync/corosync.conf' and '/etc/corosync/authkey' (if it exists) to the new node
 
144
. Start the new cluster node
 
145
 
 
146
If a log message containing "Invalid digest" appears from Corosync,
 
147
the keys are not consistent between the machines.
 
148
 
 
149
== CMAN ==
 
150
 
 
151
=== Adding a New CMAN Node ===
 
152
 
 
153
indexterm:[CMAN,Add Cluster Node]
 
154
indexterm:[Add Cluster Node,CMAN]
 
155
 
 
156
=== Removing a CMAN Node ===
 
157
 
 
158
indexterm:[CMAN,Remove Cluster Node]
 
159
indexterm:[Remove Cluster Node,CMAN]
 
160
 
 
161
== Heartbeat ==
 
162
 
 
163
=== Adding a New Heartbeat Node ===
 
164
 
 
165
indexterm:[Heartbeat,Add Cluster Node]
 
166
indexterm:[Add Cluster Node,Heartbeat]
 
167
 
 
168
Provided you specified +autojoin any+ in 'ha.cf', adding a new node is
 
169
as simple as installing heartbeat and copying 'ha.cf' and 'authkeys'
 
170
from an existing node.
 
171
 
 
172
If you don't want to use +autojoin+, then after setting up 'ha.cf' and
 
173
'authkeys', you must use `hb_addnode` before starting the new node.
 
174
 
 
175
=== Removing a Heartbeat Node ===
 
176
 
 
177
indexterm:[Heartbeat,Remove Cluster Node]
 
178
indexterm:[Remove Cluster Node,Heartbeat]
 
179
 
 
180
Because the messaging and membership layers are the authoritative
 
181
source for cluster nodes, deleting them from the CIB is not a reliable
 
182
solution.
 
183
 
 
184
First one must arrange for Heartbeat to forget about the node (pcmk-1
 
185
in the example below).
 
186
 
 
187
On the host to be removed:
 
188
 
 
189
. Stop the cluster: `/etc/init.d/corosync stop`
 
190
 
 
191
Next, from one of the remaining active cluster nodes:
 
192
 
 
193
. Tell Heartbeat the node should be removed
 
194
 
 
195
[source,C]
 
196
# hb_delnode pcmk-1
 
197
 
 
198
. Tell Pacemaker to forget about the removed host:
 
199
 
 
200
[source,C]
 
201
# crm_node -R pcmk-1
 
202
 
 
203
[NOTE]
 
204
======
 
205
This proceedure only works for versions after 1.1.8
 
206
======
 
207
 
 
208
=== Replacing a Heartbeat Node ===
 
209
 
 
210
indexterm:[Heartbeat,Replace Cluster Node]
 
211
indexterm:[Replace Cluster Node,Heartbeat]
 
212
The seven-step guide to replacing an existing cluster node:
 
213
 
 
214
. Make sure the old node is completely stopped
 
215
. Give the new machine the same hostname as the old one
 
216
. Go to an active cluster node and look up the UUID for the old node in '/var/lib/heartbeat/hostcache'
 
217
. Install the cluster software
 
218
. Copy 'ha.cf' and 'authkeys' to the new node
 
219
. On the new node, populate it's UUID using `crm_uuid -w` and the UUID from step 2
 
220
. Start the new cluster node