1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>ctdb</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry"><a name="ctdb.7"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ctdb — Clustered TDB</p></div><div class="refsect1"><a name="idm140609684204512"></a><h2>DESCRIPTION</h2><p>
CTDB is a clustered database component in clustered Samba that
provides a high-availability load-sharing CIFS server cluster.
</p><p>
The main functions of CTDB are:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
Provide a clustered version of the TDB database with automatic
rebuild/recovery of the databases upon node failures.
</p></li><li class="listitem"><p>
Monitor nodes in the cluster and services running on each node.
</p></li><li class="listitem"><p>
Manage a pool of public IP addresses that are used to provide
services to clients. Alternatively, CTDB can be used with
LVS.
</p></li></ul></div><p>
Combined with a cluster filesystem CTDB provides a full
high-availablity (HA) environment for services such as clustered
Samba, NFS and other services.
</p></div><div class="refsect1"><a name="idm140609684961120"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
A CTDB cluster is a collection of nodes with 2 or more network
interfaces. All nodes provide network (usually file/NAS) services
to clients. Data served by file services is stored on shared
storage (usually a cluster filesystem) that is accessible by all
nodes.
</p><p>
CTDB provides an "all active" cluster, where services are load
balanced across all nodes.
</p></div><div class="refsect1"><a name="idm140609685346832"></a><h2>Private vs Public addresses</h2><p>
Each node in a CTDB cluster has multiple IP addresses assigned
to it:
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
A single private IP address that is used for communication
between nodes.
</p></li><li class="listitem"><p>
One or more public IP addresses that are used to provide
NAS or other services.
</p></li></ul></div><p>
</p><div class="refsect2"><a name="idm140609684667584"></a><h3>Private address</h3><p>
Each node is configured with a unique, permanently assigned
private address. This address is configured by the operating
system. This address uniquely identifies a physical node in
the cluster and is the address that CTDB daemons will use to
communicate with the CTDB daemons on other nodes.
</p><p>
Private addresses are listed in the file specified by the
<code class="varname">CTDB_NODES</code> configuration variable (see
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, default
<code class="filename">/etc/ctdb/nodes</code>). This file contains the
list of private addresses for all nodes in the cluster, one
per line. This file must be the same on all nodes in the
cluster.
</p><p>
Private addresses should not be used by clients to connect to
services provided by the cluster.
</p><p>
It is strongly recommended that the private addresses are
configured on a private network that is separate from client
networks.
</p><p>
Example <code class="filename">/etc/ctdb/nodes</code> for a four node
cluster:
</p><pre class="screen">
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
</pre></div><div class="refsect2"><a name="idm140609686901840"></a><h3>Public addresses</h3><p>
Public addresses are used to provide services to clients.
Public addresses are not configured at the operating system
level and are not permanently associated with a particular
node. Instead, they are managed by CTDB and are assigned to
interfaces on physical nodes at runtime.
</p><p>
The CTDB cluster will assign/reassign these public addresses
across the available healthy nodes in the cluster. When one
node fails, its public addresses will be taken over by one or
more other nodes in the cluster. This ensures that services
provided by all public addresses are always available to
clients, as long as there are nodes available capable of
hosting this address.
</p><p>
The public address configuration is stored in a file on each
node specified by the <code class="varname">CTDB_PUBLIC_ADDRESSES</code>
configuration variable (see
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>, recommended
<code class="filename">/etc/ctdb/public_addresses</code>). This file
contains a list of the public addresses that the node is
capable of hosting, one per line. Each entry also contains
the netmask and the interface to which the address should be
assigned.
</p><p>
Example <code class="filename">/etc/ctdb/public_addresses</code> for a
node that can host 4 public addresses, on 2 different
interfaces:
</p><pre class="screen">
10.1.1.1/24 eth1
10.1.1.2/24 eth1
10.1.2.1/24 eth2
10.1.2.2/24 eth2
</pre><p>
In many cases the public addresses file will be the same on
all nodes. However, it is possible to use different public
address configurations on different nodes.
</p><p>
Example: 4 nodes partitioned into two subgroups:
</p><pre class="screen">
Node 0:/etc/ctdb/public_addresses
10.1.1.1/24 eth1
10.1.1.2/24 eth1
Node 1:/etc/ctdb/public_addresses
10.1.1.1/24 eth1
10.1.1.2/24 eth1
Node 2:/etc/ctdb/public_addresses
10.1.2.1/24 eth2
10.1.2.2/24 eth2
Node 3:/etc/ctdb/public_addresses
10.1.2.1/24 eth2
10.1.2.2/24 eth2
</pre><p>
In this example nodes 0 and 1 host two public addresses on the
10.1.1.x network while nodes 2 and 3 host two public addresses
for the 10.1.2.x network.
</p><p>
Public address 10.1.1.1 can be hosted by either of nodes 0 or
1 and will be available to clients as long as at least one of
these two nodes are available.
</p><p>
If both nodes 0 and 1 become unavailable then public address
10.1.1.1 also becomes unavailable. 10.1.1.1 can not be failed
over to nodes 2 or 3 since these nodes do not have this public
address configured.
</p><p>
The <span class="command"><strong>ctdb ip</strong></span> command can be used to view the
current assignment of public addresses to physical nodes.
</p></div></div><div class="refsect1"><a name="idm140609686926800"></a><h2>Node status</h2><p>
The current status of each node in the cluster can be viewed by the
<span class="command"><strong>ctdb status</strong></span> command.
</p><p>
A node can be in one of the following states:
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">OK</span></dt><dd><p>
This node is healthy and fully functional. It hosts public
addresses to provide services.
</p></dd><dt><span class="term">DISCONNECTED</span></dt><dd><p>
This node is not reachable by other nodes via the private
network. It is not currently participating in the cluster.
It <span class="emphasis"><em>does not</em></span> host public addresses to
provide services. It might be shut down.
</p></dd><dt><span class="term">DISABLED</span></dt><dd><p>
This node has been administratively disabled. This node is
partially functional and participates in the cluster.
However, it <span class="emphasis"><em>does not</em></span> host public
addresses to provide services.
</p></dd><dt><span class="term">UNHEALTHY</span></dt><dd><p>
A service provided by this node has failed a health check
and should be investigated. This node is partially
functional and participates in the cluster. However, it
<span class="emphasis"><em>does not</em></span> host public addresses to
provide services. Unhealthy nodes should be investigated
and may require an administrative action to rectify.
</p></dd><dt><span class="term">BANNED</span></dt><dd><p>
CTDB is not behaving as designed on this node. For example,
it may have failed too many recovery attempts. Such nodes
are banned from participating in the cluster for a
configurable time period before they attempt to rejoin the
cluster. A banned node <span class="emphasis"><em>does not</em></span> host
public addresses to provide services. All banned nodes
should be investigated and may require an administrative
action to rectify.
</p></dd><dt><span class="term">STOPPED</span></dt><dd><p>
This node has been administratively exclude from the
cluster. A stopped node does no participate in the cluster
and <span class="emphasis"><em>does not</em></span> host public addresses to
provide services. This state can be used while performing
maintenance on a node.
</p></dd><dt><span class="term">PARTIALLYONLINE</span></dt><dd><p>
A node that is partially online participates in a cluster
like a healthy (OK) node. Some interfaces to serve public
addresses are down, but at least one interface is up. See
also <span class="command"><strong>ctdb ifaces</strong></span>.
</p></dd></dl></div></div><div class="refsect1"><a name="idm140609682287456"></a><h2>CAPABILITIES</h2><p>
Cluster nodes can have several different capabilities enabled.
These are listed below.
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">RECMASTER</span></dt><dd><p>
Indicates that a node can become the CTDB cluster recovery
master. The current recovery master is decided via an
election held by all active nodes with this capability.
</p><p>
Default is YES.
</p></dd><dt><span class="term">LMASTER</span></dt><dd><p>
Indicates that a node can be the location master (LMASTER)
for database records. The LMASTER always knows which node
has the latest copy of a record in a volatile database.
</p><p>
Default is YES.
</p></dd><dt><span class="term">LVS</span></dt><dd><p>
Indicates that a node is configued in Linux Virtual Server
(LVS) mode. In this mode the entire CTDB cluster uses one
single public address for the entire cluster instead of
using multiple public addresses in failover mode. This is
an alternative to using a load-balancing layer-4 switch.
See the <em class="citetitle">LVS</em> section for more
details.
</p></dd><dt><span class="term">NATGW</span></dt><dd><p>
Indicates that this node is configured to become the NAT
gateway master in a NAT gateway group. See the
<em class="citetitle">NAT GATEWAY</em> section for more
details.
</p></dd></dl></div><p>
The RECMASTER and LMASTER capabilities can be disabled when CTDB
is used to create a cluster spanning across WAN links. In this
case CTDB acts as a WAN accelerator.
</p></div><div class="refsect1"><a name="idm140609686954304"></a><h2>LVS</h2><p>
LVS is a mode where CTDB presents one single IP address for the
entire cluster. This is an alternative to using public IP
addresses and round-robin DNS to loadbalance clients across the
cluster.
</p><p>
This is similar to using a layer-4 loadbalancing switch but with
some restrictions.
</p><p>
In this mode the cluster selects a set of nodes in the cluster
and loadbalance all client access to the LVS address across this
set of nodes. This set of nodes are all LVS capable nodes that
are HEALTHY, or if no HEALTHY nodes exists all LVS capable nodes
regardless of health status. LVS will however never loadbalance
traffic to nodes that are BANNED, STOPPED, DISABLED or
DISCONNECTED. The <span class="command"><strong>ctdb lvs</strong></span> command is used to
show which nodes are currently load-balanced across.
</p><p>
One of the these nodes are elected as the LVSMASTER. This node
receives all traffic from clients coming in to the LVS address
and multiplexes it across the internal network to one of the
nodes that LVS is using. When responding to the client, that
node will send the data back directly to the client, bypassing
the LVSMASTER node. The command <span class="command"><strong>ctdb
lvsmaster</strong></span> will show which node is the current
LVSMASTER.
</p><p>
The path used for a client I/O is:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
Client sends request packet to LVSMASTER.
</p></li><li class="listitem"><p>
LVSMASTER passes the request on to one node across the
internal network.
</p></li><li class="listitem"><p>
Selected node processes the request.
</p></li><li class="listitem"><p>
Node responds back to client.
</p></li></ol></div><p>
</p><p>
This means that all incoming traffic to the cluster will pass
through one physical node, which limits scalability. You can
send more data to the LVS address that one physical node can
multiplex. This means that you should not use LVS if your I/O
pattern is write-intensive since you will be limited in the
available network bandwidth that node can handle. LVS does work
wery well for read-intensive workloads where only smallish READ
requests are going through the LVSMASTER bottleneck and the
majority of the traffic volume (the data in the read replies)
goes straight from the processing node back to the clients. For
read-intensive i/o patterns you can acheive very high throughput
rates in this mode.
</p><p>
Note: you can use LVS and public addresses at the same time.
</p><p>
If you use LVS, you must have a permanent address configured for
the public interface on each node. This address must be routable
and the cluster nodes must be configured so that all traffic
back to client hosts are routed through this interface. This is
also required in order to allow samba/winbind on the node to
talk to the domain controller. This LVS IP address can not be
used to initiate outgoing traffic.
</p><p>
Make sure that the domain controller and the clients are
reachable from a node <span class="emphasis"><em>before</em></span> you enable
LVS. Also ensure that outgoing traffic to these hosts is routed
out through the configured public interface.
</p><div class="refsect2"><a name="idm140609686941328"></a><h3>Configuration</h3><p>
To activate LVS on a CTDB node you must specify the
<code class="varname">CTDB_PUBLIC_INTERFACE</code> and
<code class="varname">CTDB_LVS_PUBLIC_IP</code> configuration variables.
Setting the latter variable also enables the LVS capability on
the node at startup.
</p><p>
Example:
</p><pre class="screen">
CTDB_PUBLIC_INTERFACE=eth1
CTDB_LVS_PUBLIC_IP=10.1.1.237
</pre><p>
</p></div></div><div class="refsect1"><a name="idm140609686937856"></a><h2>NAT GATEWAY</h2><p>
NAT gateway (NATGW) is an optional feature that is used to
configure fallback routing for nodes. This allows cluster nodes
to connect to external services (e.g. DNS, AD, NIS and LDAP)
when they do not host any public addresses (e.g. when they are
unhealthy).
</p><p>
This also applies to node startup because CTDB marks nodes as
UNHEALTHY until they have passed a "monitor" event. In this
context, NAT gateway helps to avoid a "chicken and egg"
situation where a node needs to access an external service to
become healthy.
</p><p>
Another way of solving this type of problem is to assign an
extra static IP address to a public interface on every node.
This is simpler but it uses an extra IP address per node, while
NAT gateway generally uses only one extra IP address.
</p><div class="refsect2"><a name="idm140609681464768"></a><h3>Operation</h3><p>
One extra NATGW public address is assigned on the public
network to each NATGW group. Each NATGW group is a set of
nodes in the cluster that shares the same NATGW address to
talk to the outside world. Normally there would only be one
NATGW group spanning an entire cluster, but in situations
where one CTDB cluster spans multiple physical sites it might
be useful to have one NATGW group for each site.
</p><p>
There can be multiple NATGW groups in a cluster but each node
can only be member of one NATGW group.
</p><p>
In each NATGW group, one of the nodes is selected by CTDB to
be the NATGW master and the other nodes are consider to be
NATGW slaves. NATGW slaves establish a fallback default route
to the NATGW master via the private network. When a NATGW
slave hosts no public IP addresses then it will use this route
for outbound connections. The NATGW master hosts the NATGW
public IP address and routes outgoing connections from
slave nodes via this IP address. It also establishes a
fallback default route.
</p></div><div class="refsect2"><a name="idm140609681461760"></a><h3>Configuration</h3><p>
NATGW is usually configured similar to the following example configuration:
</p><pre class="screen">
CTDB_NATGW_NODES=/etc/ctdb/natgw_nodes
CTDB_NATGW_PRIVATE_NETWORK=192.168.1.0/24
CTDB_NATGW_PUBLIC_IP=10.0.0.227/24
CTDB_NATGW_PUBLIC_IFACE=eth0
CTDB_NATGW_DEFAULT_GATEWAY=10.0.0.1
</pre><p>
Normally any node in a NATGW group can act as the NATGW
master. Some configurations may have special nodes that lack
connectivity to a public network. In such cases,
<code class="varname">CTDB_NATGW_SLAVE_ONLY</code> can be used to limit the
NATGW functionality of thos nodes.
</p><p>
See the <em class="citetitle">NAT GATEWAY</em> section in
<span class="citerefentry"><span class="refentrytitle">ctdb.conf</span>(5)</span> for more details of
NATGW configuration.
</p></div><div class="refsect2"><a name="idm140609681457152"></a><h3>Implementation details</h3><p>
When the NATGW functionality is used, one of the nodes is
selected to act as a NAT gateway for all the other nodes in
the group when they need to communicate with the external
services. The NATGW master is selected to be a node that is
most likely to have usable networks.
</p><p>
The NATGW master hosts the NATGW public IP address
<code class="varname">CTDB_NATGW_PUBLIC_IP</code> on the configured public
interfaces <code class="varname">CTDB_NATGW_PUBLIC_IFACE</code> and acts as
a router, masquerading outgoing connections from slave nodes
via this IP address. If
<code class="varname">CTDB_NATGW_DEFAULT_GATEWAY</code> is set then it
also establishes a fallback default route to the configured
this gateway with a metric of 10. A metric 10 route is used
so it can co-exist with other default routes that may be
available.
</p><p>
A NATGW slave establishes its fallback default route to the
NATGW master via the private network
<code class="varname">CTDB_NATGW_PRIVATE_NETWORK</code>with a metric of 10.
This route is used for outbound connections when no other
default route is available because the node hosts no public
addresses. A metric 10 routes is used so that it can co-exist
with other default routes that may be available when the node
is hosting public addresses.
</p><p>
<code class="varname">CTDB_NATGW_STATIC_ROUTES</code> can be used to
have NATGW create more specific routes instead of just default
routes.
</p><p>
This is implemented in the <code class="filename">11.natgw</code>
eventscript. Please see the eventscript file and the
<em class="citetitle">NAT GATEWAY</em> section in
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
</p></div></div><div class="refsect1"><a name="idm140609681449328"></a><h2>POLICY ROUTING</h2><p>
Policy routing is an optional CTDB feature to support complex
network topologies. Public addresses may be spread across
several different networks (or VLANs) and it may not be possible
to route packets from these public addresses via the system's
default route. Therefore, CTDB has support for policy routing
via the <code class="filename">13.per_ip_routing</code> eventscript.
This allows routing to be specified for packets sourced from
each public address. The routes are added and removed as CTDB
moves public addresses between nodes.
</p><div class="refsect2"><a name="idm140609681447104"></a><h3>Configuration variables</h3><p>
There are 4 configuration variables related to policy routing:
<code class="varname">CTDB_PER_IP_ROUTING_CONF</code>,
<code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code>,
<code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_LOW</code>,
<code class="varname">CTDB_PER_IP_ROUTING_TABLE_ID_HIGH</code>. See the
<em class="citetitle">POLICY ROUTING</em> section in
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details.
</p></div><div class="refsect2"><a name="idm140609681443136"></a><h3>Configuration</h3><p>
The format of each line of
<code class="varname">CTDB_PER_IP_ROUTING_CONF</code> is:
</p><pre class="screen">
<public_address> <network> [ <gateway> ]
</pre><p>
Leading whitespace is ignored and arbitrary whitespace may be
used as a separator. Lines that have a "public address" item
that doesn't match an actual public address are ignored. This
means that comment lines can be added using a leading
character such as '#', since this will never match an IP
address.
</p><p>
A line without a gateway indicates a link local route.
</p><p>
For example, consider the configuration line:
</p><pre class="screen">
192.168.1.99 192.168.1.1/24
</pre><p>
If the corresponding public_addresses line is:
</p><pre class="screen">
192.168.1.99/24 eth2,eth3
</pre><p>
<code class="varname">CTDB_PER_IP_ROUTING_RULE_PREF</code> is 100, and
CTDB adds the address to eth2 then the following routing
information is added:
</p><pre class="screen">
ip rule add from 192.168.1.99 pref 100 table ctdb.192.168.1.99
ip route add 192.168.1.0/24 dev eth2 table ctdb.192.168.1.99
</pre><p>
This causes traffic from 192.168.1.1 to 192.168.1.0/24 go via
eth2.
</p><p>
The <span class="command"><strong>ip rule</strong></span> command will show (something
like - depending on other public addresses and other routes on
the system):
</p><pre class="screen">
0: from all lookup local
100: from 192.168.1.99 lookup ctdb.192.168.1.99
32766: from all lookup main
32767: from all lookup default
</pre><p>
<span class="command"><strong>ip route show table ctdb.192.168.1.99</strong></span> will show:
</p><pre class="screen">
192.168.1.0/24 dev eth2 scope link
</pre><p>
The usual use for a line containing a gateway is to add a
default route corresponding to a particular source address.
Consider this line of configuration:
</p><pre class="screen">
192.168.1.99 0.0.0.0/0 192.168.1.1
</pre><p>
In the situation described above this will cause an extra
routing command to be executed:
</p><pre class="screen">
ip route add 0.0.0.0/0 via 192.168.1.1 dev eth2 table ctdb.192.168.1.99
</pre><p>
With both configuration lines, <span class="command"><strong>ip route show table
ctdb.192.168.1.99</strong></span> will show:
</p><pre class="screen">
192.168.1.0/24 dev eth2 scope link
default via 192.168.1.1 dev eth2
</pre></div><div class="refsect2"><a name="idm140609681427920"></a><h3>Sample configuration</h3><p>
Here is a more complete example configuration.
</p><pre class="screen">
/etc/ctdb/public_addresses:
192.168.1.98 eth2,eth3
192.168.1.99 eth2,eth3
/etc/ctdb/policy_routing:
192.168.1.98 192.168.1.0/24
192.168.1.98 192.168.200.0/24 192.168.1.254
192.168.1.98 0.0.0.0/0 192.168.1.1
192.168.1.99 192.168.1.0/24
192.168.1.99 192.168.200.0/24 192.168.1.254
192.168.1.99 0.0.0.0/0 192.168.1.1
</pre><p>
The routes local packets as expected, the default route is as
previously discussed, but packets to 192.168.200.0/24 are
routed via the alternate gateway 192.168.1.254.
</p></div></div><div class="refsect1"><a name="idm140609681425088"></a><h2>NOTIFICATION SCRIPT</h2><p>
When certain state changes occur in CTDB, it can be configured
to perform arbitrary actions via a notification script. For
example, sending SNMP traps or emails when a node becomes
unhealthy or similar.
</p><p>
This is activated by setting the
<code class="varname">CTDB_NOTIFY_SCRIPT</code> configuration variable.
The specified script must be executable.
</p><p>
Use of the provided <code class="filename">/etc/ctdb/notify.sh</code>
script is recommended. It executes files in
<code class="filename">/etc/ctdb/notify.d/</code>.
</p><p>
CTDB currently generates notifications after CTDB changes to
these states:
</p><table border="0" summary="Simple list" class="simplelist"><tr><td>init</td></tr><tr><td>setup</td></tr><tr><td>startup</td></tr><tr><td>healthy</td></tr><tr><td>unhealthy</td></tr></table></div><div class="refsect1"><a name="idm140609681418144"></a><h2>DEBUG LEVELS</h2><p>
Valid values for DEBUGLEVEL are:
</p><table border="0" summary="Simple list" class="simplelist"><tr><td>EMERG (-3)</td></tr><tr><td>ALERT (-2)</td></tr><tr><td>CRIT (-1)</td></tr><tr><td>ERR (0)</td></tr><tr><td>WARNING (1)</td></tr><tr><td>NOTICE (2)</td></tr><tr><td>INFO (3)</td></tr><tr><td>DEBUG (4)</td></tr></table></div><div class="refsect1"><a name="idm140609681413296"></a><h2>REMOTE CLUSTER NODES</h2><p>
It is possible to have a CTDB cluster that spans across a WAN link.
For example where you have a CTDB cluster in your datacentre but you also
want to have one additional CTDB node located at a remote branch site.
This is similar to how a WAN accelerator works but with the difference
that while a WAN-accelerator often acts as a Proxy or a MitM, in
the ctdb remote cluster node configuration the Samba instance at the remote site
IS the genuine server, not a proxy and not a MitM, and thus provides 100%
correct CIFS semantics to clients.
</p><p>
See the cluster as one single multihomed samba server where one of
the NICs (the remote node) is very far away.
</p><p>
NOTE: This does require that the cluster filesystem you use can cope
with WAN-link latencies. Not all cluster filesystems can handle
WAN-link latencies! Whether this will provide very good WAN-accelerator
performance or it will perform very poorly depends entirely
on how optimized your cluster filesystem is in handling high latency
for data and metadata operations.
</p><p>
To activate a node as being a remote cluster node you need to set
the following two parameters in /etc/sysconfig/ctdb for the remote node:
</p><pre class="screen">
CTDB_CAPABILITY_LMASTER=no
CTDB_CAPABILITY_RECMASTER=no
</pre><p>
</p><p>
Verify with the command "ctdb getcapabilities" that that node no longer
has the recmaster or the lmaster capabilities.
</p></div><div class="refsect1"><a name="idm140609681408144"></a><h2>SEE ALSO</h2><p>
<span class="citerefentry"><span class="refentrytitle">ctdb</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdbd</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdbd_wrapper</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ltdbtool</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">onnode</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ping_pong</span>(1)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdb-statistics</span>(7)</span>,
<span class="citerefentry"><span class="refentrytitle">ctdb-tunables</span>(7)</span>,
<a class="ulink" href="http://ctdb.samba.org/" target="_top">http://ctdb.samba.org/</a>
</p></div></div></body></html>
|
