The Toolbox

The CTDB package supplies two useful programs, ctdb and onnode, along with the daemon ctdbd. The ctdb tool is the client interface for CTDB cluster management. The most frequently used command is bound to be ctdb status, which outputs the general status of the cluster (Figure 2). The ctdb ip command shows the distribution of public IP addresses over the nodes (Figure 3). ctdb lets the admin trigger actions in the cluster, such as enabling or disabling individual nodes, adding or removing public IPs, forcing a recovery, or applying various tweaks. See the CTDB man page [24] for more information.

The onnode script is a very useful tool that lets you run commands on one or multiple nodes:

onnode node[,node...] Kommando

onnode gleans the node details from the /etc/ctdb/nodes file. The target can be one or multiple node numbers or a numeric range. Also all nodes (all), connected nodes (con), healthy nodes (ok), and the recovery master (rm) have symbolic names. onnode uses SSH to establish connections to the nodes; password-less SSH logins are thus a good idea on the internal CTDB network.

Using onnode, the admin can easily roll out service configuration files on the nodes or install the same software package after storing the data on the cluster filesystem beforehand:

onnode all cp /shared/smb.conf /etc/samba/smb.conf

Because onnode only needs to reference the nodes file, you can use it to launch ctdbd on all or selected nodes:

onnode 0,2-5 service ctdb start

For more, see the onnode man page [25].

Listeners

To guarantee trouble-free monitoring and failover operations in CTDB, it is important not to use the interfaces or bind interfaces only configuration parameters to restrict the IP addresses or network interfaces you want Samba to listen on. Samba service monitoring requires Samba to listen on the wildcard address, 0.0.0.0, or :: for IPv6.

Listing 2 shows an example of a Samba configuration file that the admin would distribute to all the nodes in the cluster. The smbstatus shows the connections for all nodes in the cluster. To do so, it not only lists the process IDs of the smbd processes, but outputs their node number prefixes (Figure 4). Similarly, admins can influence the Samba daemons throughout the cluster using smbcontrol.

When running a Samba cluster, it doesn't make any sense to run the NetBIOS name service, nmbd, on multiple nodes – the broadcast would just suffer from a split personality. Also, the WINS service is not cluster-capable because Samba does not handle the wins.dat database with CTDB.

Conclusion

For the first time, and conditional on a freely available clustering filesystem that passes the ping-pong test, Samba 3.3 in combination with CTDB offers a highly scalable CIFS cluster that is easily installable for production use without the need for patches and workarounds. After the basic setup, registry-based configuration and the onnode script make managing the cluster a pleasant task. Read on for more on Samba's new registry configuration system.