-<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.79.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="idm10"></a><h2>DESCRIPTION</h2><p>
+<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.79.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="idm139628772730512"></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>
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="idm22"></a><h2>ANATOMY OF A CTDB CLUSTER</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628772159680"></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
</p><p>
CTDB provides an "all active" cluster, where services are load
balanced across all nodes.
- </p></div><div class="refsect1"><a name="idm26"></a><h2>Recovery Lock</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628770890960"></a><h2>Recovery Lock</h2><p>
CTDB uses a <span class="emphasis"><em>recovery lock</em></span> to avoid a
<span class="emphasis"><em>split brain</em></span>, where a cluster becomes
partitioned and each partition attempts to operate
</p><p>
CTDB can run without a recovery lock but this is not recommended
as there will be no protection from split brains.
- </p></div><div class="refsect1"><a name="idm45"></a><h2>Private vs Public addresses</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628773418304"></a><h2>Private vs Public addresses</h2><p>
Each node in a CTDB cluster has multiple IP addresses assigned
to it:
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="idm53"></a><h3>Private address</h3><p>
+ </p><div class="refsect2"><a name="idm139628775259760"></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
192.168.1.2
192.168.1.3
192.168.1.4
- </pre></div><div class="refsect2"><a name="idm67"></a><h3>Public addresses</h3><p>
+ </pre></div><div class="refsect2"><a name="idm139628775740336"></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
</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="idm88"></a><h2>Node status</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm139628775904560"></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>
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="idm128"></a><h2>CAPABILITIES</h2><p>
+ </p></dd></dl></div></div><div class="refsect1"><a name="idm139628775864032"></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>
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="idm143"></a><h2>LVS</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628775857328"></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
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="idm167"></a><h3>Configuration</h3><p>
+ </p><div class="refsect2"><a name="idm139628775835584"></a><h3>Configuration</h3><p>
To activate LVS on a CTDB node you must specify the
<code class="varname">CTDB_LVS_PUBLIC_IFACE</code>,
<code class="varname">CTDB_LVS_PUBLIC_IP</code> and
192.168.1.2
192.168.1.3
192.168.1.4 slave-only
- </pre></div></div><div class="refsect1"><a name="idm183"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
+ </pre></div></div><div class="refsect1"><a name="idm139628775827248"></a><h2>TRACKING AND RESETTING TCP CONNECTIONS</h2><p>
CTDB tracks TCP connections from clients to public IP addresses,
on known ports. When an IP address moves from one node to
another, all existing TCP connections to that IP address are
a release and take of a public IP address on the same node.
Such connections can get out of sync with sequence and ACK
numbers, potentially causing a disruptive ACK storm.
- </p></div><div class="refsect1"><a name="idm187"></a><h2>NAT GATEWAY</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628775824432"></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)
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="idm192"></a><h3>Operation</h3><p>
+ </p><div class="refsect2"><a name="idm139628770293920"></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
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="idm197"></a><h3>Configuration</h3><p>
+ </p></div><div class="refsect2"><a name="idm139628770290912"></a><h3>Configuration</h3><p>
NATGW is usually configured similar to the following example configuration:
</p><pre class="screen">
CTDB_NATGW_NODES=/usr/local/etc/ctdb/natgw_nodes
See the <em class="citetitle">NAT GATEWAY</em> section in
<span class="citerefentry"><span class="refentrytitle">ctdbd.conf</span>(5)</span> for more details of
NATGW configuration.
- </p></div><div class="refsect2"><a name="idm208"></a><h3>Implementation details</h3><p>
+ </p></div><div class="refsect2"><a name="idm139628770286144"></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
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="idm225"></a><h2>POLICY ROUTING</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm139628770278320"></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
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="idm229"></a><h3>Configuration variables</h3><p>
+ </p><div class="refsect2"><a name="idm139628770276096"></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_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="idm240"></a><h3>Configuration</h3><p>
+ </p></div><div class="refsect2"><a name="idm139628770272128"></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">
</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="idm268"></a><h3>Sample configuration</h3><p>
+ </pre></div><div class="refsect2"><a name="idm139628770256912"></a><h3>Sample configuration</h3><p>
Here is a more complete example configuration.
</p><pre class="screen">
/usr/local/etc/ctdb/public_addresses:
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="idm273"></a><h2>NOTIFICATION SCRIPT</h2><p>
+ </p></div></div><div class="refsect1"><a name="idm139628770254048"></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
</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="idm288"></a><h2>DEBUG LEVELS</h2><p>
+ </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="idm139628770247104"></a><h2>DEBUG LEVELS</h2><p>
Valid values for DEBUGLEVEL are:
- </p><table border="0" summary="Simple list" class="simplelist"><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="idm297"></a><h2>REMOTE CLUSTER NODES</h2><p>
+ </p><table border="0" summary="Simple list" class="simplelist"><tr><td>ERR</td></tr><tr><td>WARNING</td></tr><tr><td>NOTICE</td></tr><tr><td>INFO</td></tr><tr><td>DEBUG</td></tr></table></div><div class="refsect1"><a name="idm139628770243408"></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.
</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="idm305"></a><h2>SEE ALSO</h2><p>
+ </p></div><div class="refsect1"><a name="idm139628770238704"></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>,