6.6. 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 connection 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 to Red Hat Enterprise Linux System Administration Guide for 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 should not be specified in the conventional /etc/samba/smb.conf file. The Cluster Configuration Tool writes a smb.conf.sharename file to the /etc/samba/ directory for each Samba share (where sharename is the name you specified for the Samba share).
The automated system startup of the Samba daemons smbd and nmbd should be disabled in init.d runlevels. For example: chkconfig --del smb.
Since the cluster infrastructure stops the cluster-related Samba daemons appropriately, do not manually 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 the Cluster Configuration Tool.
Failover of Samba printer shares is not currently supported.
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 understanding the configuration requirements of clustered Samba services.
The conventional, non-clustered Samba configuration model consists of editing the /etc/samba/smb.conf file 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 the smbd and nmbd daemons are automatically started up by the /etc/rc.d/init.d/smb runlevel 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, where sharename is the specific name of the individual configuration file associated with a Samba service. For example, if you created a share called mktg, the corresponding Samba configuration file would be /etc/samba/smb.conf.mktg.
| Note |
|---|---|
A Samba share must be in a service with at least one IP address. |
The format of the smb.conf.sharename file is identical to the conventional smb.conf format. No additional fields have been created for clustered operation. There are several fields within the smb.conf.sharename file which are required for correct cluster operation; these fields will be described in Section 6.8 Fields in the smb.conf.sharename File. When a new Samba service is created using the Cluster Configuration Tool, the corresponding smb.conf.sharename file 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.9 Configuring a Failover Domain for more information. After the initial configuration, should any changes be made to any smb.conf.sharename file, 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 the Cluster Configuration Tool) will have its own individual pair of smbd and nmbd daemons. Consequently, if there are more than one Samba services configured with the cluster, you may see multiple instances of these daemon pairs running on an individual cluster server. These Samba daemons smbd and nmbd are not initiated via the conventional init.d run 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. Consequently, there will be a separate per-service Samba daemon locking and running process directory. These directories are given the name /var/cache/samba/sharename/ for lock files and /var/run/samba/sharename/ for pid files (where sharename is replaced by the Samba share name specified within the service configuration information set using the Cluster Configuration Tool). Continuing the prior example, the corresponding directories for our mktg share would be /var/cache/samba/mktg/ and /var/run/samba/mktg/.