Setting Up a Samba Service

Highly available network file services are one of the key strengths of the clustering infrastructure. Advantages of high availibility Samba services include:

• Heterogeneous file serving capabilities to Microsoft® Windows™ clients using the CIFS/SMB protocol.

• Allows the same set of file systems to be simultaneously network served to both NFS and Windows based clients.

• Ensures that Windows-based clients maintain access to key data, and can quickly reestablish con- nection in the event of server failure.

• Facilitates planned maintenance by allowing the transparent relocation of Samba services to one cluster member, enabling you to fix or upgrade the other cluster member.

• Allows the setup of an active-active configuration to maximize equipment utilization.

Note

A complete explanation of Samba configuration is beyond the scope of this document. Rather, this documentation highlights aspects which are crucial for clustered operation. Refer toRed Hat Enter- prise Linux System Administration Guidefor more details on Samba configuration.

6.6.1. Samba Server Requirements

If you intend to create highly available Samba services, each cluster member on which the services will run must meet the following requirements:

• The Samba RPM packages must be installed. Note that there have been no modifications to the Samba RPMs to support high availability.

• The Samba daemons will be started and stopped by the cluster infrastructure on a per-service basis. Consequently, the Samba configuration information shouldnotbe specified in the conventional /etc/samba/smb.conffile. TheCluster Configuration Toolwrites asmb.conf.sharename

file to the/etc/samba/directory for each Samba share (wheresharenameis the name you specified for the Samba share).

• The automated system startup of the Samba daemonssmbdandnmbdshould be disabled ininit.d runlevels. For example:chkconfig --del smb.

• Since the cluster infrastructure stops the cluster-related Samba daemons appropriately, do not manu- ally run the conventional Samba stop script (service smb stop) as this will terminate all cluster- related samba daemons.

• File system mounts for clustered Samba services should not be included in/etc/fstab. Rather, for clustered services, the parameters describing mounts are entered via theCluster Configuration Tool.

86 Chapter 6. Network File Sharing Services

6.6.2. Samba Operating Model

This section provides background information describing the implementation model in support of Samba high availability services. Knowledge of this information will provide the context for under- standing the configuration requirements of clustered Samba services.

The conventional, non-clustered Samba configuration model consists of editing the /etc/samba/smb.conffile to designate which file systems are to be made network accessible to the specified clients. It also designates access permissions and other mapping capabilities. In the single system model, a single instance of each of thesmbdandnmbddaemons are automatically started up by the/etc/rc.d/init.d/smbrunlevel script.

To implement high availibility Samba services, rather than having a single/etc/samba/smb.conf file, each service has its own Samba configuration file. These files are named /etc/samba/smb.conf.sharename, wheresharenameis the specific name of the individual configuration file associated with a Samba service. For example, if you created a share calledmktg, the corresponding Samba configuration file would be/etc/samba/smb.conf.mktg.

Note

A Samba share must be in a service withat least oneIP address.

The format of thesmb.conf.sharenamefile is identical to the conventionalsmb.confformat. No additional fields have been created for clustered operation. There are several fields within the smb.conf.sharenamefile which are required for correct cluster operation; these fields will be de-

scribed in Section 6.8Fields in thesmb.conf.sharenameFile. When a new Samba service is cre-

ated using theCluster Configuration Tool, the correspondingsmb.conf.sharenamefile is created based on the service-specific parameters, including appropriate client systems, specific directories to share, and read-write permissions.

Copy the /etc/samba/smb.conf.sharename files onto all members in the cluster (or all members in an unrestricted failover domain, if used); refer to Section 3.9Configuring a Failover Domainfor more information. After the initial configuration, should any changes be made to any smb.conf.sharenamefile, you must also copy the updated version to the other members. To facilitate high-availability Samba functionality, each individual Samba service configured within the cluster (through theCluster Configuration Tool) will have its own individual pair ofsmbdand nmbddaemons. Consequently, if there are more than one Samba services configured with the clus- ter, you may see multiple instances of these daemon pairs running on an individual cluster server. These Samba daemonssmbdandnmbdare not initiated via the conventionalinit.drun level scripts; rather they are initiated by the cluster infrastructure based on whichever member is the active service provider.

To allow a single system to run multiple instances of the Samba daemons, every pair of daemons is required to have both its own locking directory and its own process ID (pid) directory. Con- sequently, there will be a separate per-service Samba daemon locking and running process direc- tory. These directories are given the name/var/cache/samba/sharename/for lock files and /var/run/samba/sharename/for pid files (wheresharenameis replaced by the Samba share name specified within the service configuration information set using theCluster Configuration Tool). Continuing the prior example, the corresponding directories for ourmktgshare would be /var/cache/samba/mktg/and/var/run/samba/mktg/.

Chapter 6. Network File Sharing Services 87