Setting Up a High Availability Samba Service

Samba Server Requirements

If you intend to create highly available Samba services, then there are a few requirements which must be met by each cluster server. These requirements include:

• The Samba RPM packages must be installed. Red Hat Enterprise Linux AS ships with the following Samba-related packages: samba and samba-common. 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. The automated system startup of the Samba daemons smbd and nmbd should be disabled in init.d run levels. For example: chkconfig --del smb.

• Since the cluster infrastructure stops the cluster related Samba daemons appropriately, system administrators should not manually run the conventional samba stop script (e.g. 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 cluadmin configuration utility.

• Failover of samba printer shares is not currently supported.

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 filesystems are to be made network accessible to the specified Windows 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.

In order to implement high availibility Samba services, rather than having a single /etc/samba/smb.conf file; there is an individual per-service samba configuration file. These files are called /etc/samba/smb.conf.sharename; where sharename is the specific name of the individual configuration file associated with a Samba service. For example, one share could be called eng and another share acct, the corresponding Samba configuration files would be /etc/samba/smb.conf.eng and /etc/samba/smb.conf.acct, respectively.

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 an upcoming section. When a new Samba service is created using the cluadmin utility, a default template smb.conf.sharename file will be created based on the service specific parameters. This file should be used as a starting point from which the system administrator should then adjust to add in the appropriate Windows client systems, specific directories to share as well as permissions.

The system administrator is required to copy the /etc/samba/smb.conf.sharename files onto both cluster members. After the initial configuration time, should any changes be made to any smb.conf.sharename file, it is necessary to also copy this updated version to the other cluster member.

To facilitate high-availability Samba functionality, each individual Samba service configured within the cluster (via cluadmin) will have its own individual pair of smbd/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/nmbd are not initiated via the conventional init.d run level scripts; rather they are initiated by the cluster infrastructure based on whichever node is the active service provider.

In order to allow a single system to run multiple instances of the Samba daemons, each pair of daemons is required to have its own locking directory. Consequently, there will be a separate per-service Samba daemon locking directory. This directory is given the name /var/cache/samba/sharename; where sharename is replaced by the Samba share name specified within the service configuration information (via cluadmin). Following the prior example, the corresponding lock directories would be /var/cache/samba/eng and /var/cache/samba/acct.

When the cluadmin utility is used to configure a Samba service, the /var/cache/samba/sharename directory will be automatically created on the system on which the cluadmin utility is running. At this time a reminder will be displayed that you need to manually create this lock directory on the other cluster member. For example: mkdir /var/cache/samba/eng

Gathering Samba Service Configuration Parameters

When preparing to configure Samba services, determine configuration information such as which filesystems will be presented as shares to Windows based clients. The following information is required in order to configure NFS services:

• Service Name — A name used to uniquely identify this service within the cluster.

• Preferred Member — Defines which system will be the Samba server for this service when more than one cluster member is operational.

• Relocation Policy — whether to relocate the service to the preferred member if the preferred member was not running at the time the service was initially started. This parameter is useful as a means of load balancing the cluster members as Samba servers by assigning half the load to each.

• Status Check Interval — specifies how often (in seconds) the cluster subsystem should verify that the pair of Samba daemons smbd/nmbd which are associated with this service are running. In the event that either of these daemons have unexpectedly exited, they will be automatically restarted to resume services. If a value of 0 is specified, then no monitoring will be performed. For example, designating an interval of 90 seconds will result in monitoring at that interval.

• IP Address — Windows clients access file shares from a server as designated by its IP Address (or associated hostname). In order to abstract Windows clients from knowing which specific cluster member is the acting Samba server, the client systems should not use the cluster member's hostname as the IP address by which a service is accessed. Rather, clustered Samba services are assigned floating IP addresses which are distinct from the cluster server's IP addresses. This floating IP address is then configured on which ever cluster member is actively serving the share. Following this approach, the Windows clients are only aware of the floating IP address and are unaware of the fact that clustered Samba services have been deployed. When you enter a Samba service's IP address, you will also be prompted to enter an associated netmask and broadcast address. If you select the default of None, then the assigned netmask and broadcast will be the same as what the network interface is currently configured to.

• Mount Information — for non-clustered filesystems, the mount information is typically placed in /etc/fstab. In contrast, clustered filesystems must not be placed in /etc/fstab. This is necessary to ensure that only one cluster member at a time has the filesystem mounted. Failure to do so will result in filesystem corruption and likely system crashes.

  • Device special file — The mount information designates the disk's device special file and the directory on which the filesystem will be mounted. In the process of configuring a Samba service you will be prompted for this information.

  • Mount point directory — A Samba service can include more than one filesystem mount. In this manner, the filesystems will be grouped together as a single failover unit.

  • Mount options — The mount information also designates the mount options.

  • Forced unmount — As part of the mount information, you will be prompted as to whether forced unmount should be enabled or not. When forced unmount is enabled, if any applications running on the cluster server have the designated filesystem mounted when the service is being disabled or relocated, then that application will be killed off to allow the unmount to proceed.

• Export Information — this information is required for NFS services only. If you are only performing file serving to Windows based clients, answer no when prompted regarding NFS exports. Alternatively, you can configure a service to perform heterogeneous file serving by designating both NFS exports parameters and the Samba share parameter.

• Samba Share Name — In the process of configuring a service you will be asked if you wish to share the filesystem to Windows clients. If you answer yes to this question, you will then be prompted for the Samba share name. Based on the name you specify here, there will be a corresponding /etc/samba/smb.conf.sharename file and lock directory /var/cache/samba/sharename. By convention the actual Windows share name specified within the smb.conf.sharename will be set in accordance with this parameter. In practice, you can designate more than one Samba share within an individual smb.conf.sharename file. There can be at most 1 samba configuration specified per service; which must be specified with the first device. For example, if you have multiple disk devices (and corresponding file system mounts) within a single service, then specify a single sharename for the service. Then within the /etc/samab/smb.conf.sharename file, designate multiple individual samba shares to share directories from the multiple devices. To disable samba sharing of a service, the share name should be set to None.

When running the cluadmin utility to configure Samba services:

• Please take care that you correctly enter the service parameters. The validation logic associated with Samba parameters is currently not very robust.

• In response to most of the prompts, you can enter the [?] character to obtain descriptive help text.

• After configuring a Samba service via cluadmin, remember to tune the /etc/samba/smb.conf.sharename file for each service in accordance with the clients and authorization scheme you desire.

• Remember to copy the smb.conf.sharename file over to the other cluster member.

• Perform the recommended step to create the Samba daemon's lock directory on the other cluster member, for example: mkdir /var/cache/samba/acct.

• If you delete a Samba service, be sure to manually remove the /etc/samba/smb.conf/sharename file. The cluadmin utility does not automatically delete this file in order to preserve your site specific configuration parameters for possible later usage.

Example Samba Service Configuration

In order to illustrate the configuration process for a Samba service, an example configuration is described in this section. This example consists of setting up a single Samba share which houses the home directories of four members of the accounting team. The accounting team will then access this share from their Windows based systems.

The following are the service configuration parameters which will be used as well as some descriptive commentary.

• Service Name — samba_acct. This name was chosen as a reminder of the service's intended function to provide exports to the members of the accounting team.

• Preferred Member — clu4. In this example cluster, the member names are clu3 and clu4.

• User Script — The cluster infrastructure includes support for Samba services. Consequently, there is no need to create a User Script when configuring a Samba service. For this reason, when prompted to specify a User Script, the default value of None should be selected.

• Monitoring Interval — 90 seconds.

• IP Address — 10.0.0.10. There is a corresponding hostname of cluacct associated with this IP address, by which Windows based clients access the share. Note that this IP address is distinct from that of both cluster members (clu3 and clu4). The default netmask and broadcast address will be used.

• Mount Information — /dev/sdb10 refers to the partition on the shared storage RAID box on which the filesystem will be physically stored. ext2 refers to the filesystem type which was specified when the filesystem was created. /mnt/users/accounting specifies the filesystem mount point. rw,nosuid,sync are the mount options.

• Export Information — for simplicity in this example, the filesystem is not being NFS exported.

• Share Name — acct. This is the share name by which Windows based clients will access this Samba share, e.g. \\10.0.0.10\acct.

The following is an excerpt of the /etc/hosts file used to represent IP addresses and associated hostnames used within the cluster:

10.0.0.3        clu3          # cluster member

10.0.0.4        clu4          # second cluster member

10.0.0.10       cluacct    # floating IP address associated with accounting team NFS service

The following is an excerpt from running cluadmin to configure this example Samba service:

Service name: samba_acct
Preferred member [None]: clu4
Relocate when the preferred member joins the cluster (yes/no/?) [no]: yes
User script (e.g., /usr/foo/script or None) [None]: 
Status check interval [0]: 90
Do you want to add an IP address to the service (yes/no/?) [no]: yes

        IP Address Information

IP address: 10.0.0.10
Netmask (e.g. 255.255.255.0 or None) [None]: 
Broadcast (e.g. X.Y.Z.255 or None) [None]: 
Do you want to (a)dd, (m)odify, (d)elete or (s)how an IP address, or 
are you (f)inished adding IP addresses [f]: 
Do you want to add a disk device to the service (yes/no/?) [no]: yes

Disk Device Information

Device special file (e.g., /dev/sdb4): /dev/sdb12
Filesystem type (e.g., ext2, ext3 or None): ext2
Mount point (e.g., /usr/mnt/service1) [None]: /mnt/users/accounting
Mount options (e.g., rw,nosuid,sync): rw,nosuid,sync
Forced unmount support (yes/no/?) [yes]: 
Would you like to allow NFS access to this filesystem (yes/no/?)\
	    [no]: no 
Would you like to share to Windows clients (yes/no/?)  [no]: yes

You will now be prompted for the Samba configuration: 
Samba share name: acct

The samba config file /etc/samba/smb.conf.acct does not exist.

Would you like a default config file created (yes/no/?)  [no]: yes

Successfully created daemon lock directory /var/cache/samba/acct.
Please run `mkdir /var/cache/samba/acct` on the other cluster member.

Successfully created /etc/samba/smb.conf.acct.
Please remember to make necessary customizations and then copy the file
over to the other cluster member.

Do you want to (a)dd, (m)odify, (d)elete or (s)how DEVICES, or 
are you (f)inished adding DEVICES [f]: f
name: samba_acct
preferred node: clu4
relocate: yes
user script: None
monitor interval: 90
IP address 0: 10.0.0.10
  netmask 0: None
  broadcast 0: None
device 0: /dev/sdb12
  mount point, device 0: /mnt/users/accounting
  mount fstype, device 0: ext2
  mount options, device 0: rw,nosuid,sync
  force unmount, device 0: yes
  samba share, device 0: acct
Add samba_acct service as shown? (yes/no/?) yes

After running cluadmin as shown above to configure the service, remember to:

• Customize /etc/samba/smb.conf.sharename accordingly.

• Copy /etc/samba/smb.conf.sharename over to the other cluster member.

• Create the suggested lock directory on the other cluster member, e.g. mkdir /var/cache/samba/acct

smb.conf.sharename File Fields

This section describes the fields within the smb.conf.sharename file which are most relevant to the correct operation of highly available Samba services. It is beyond the scope of this document to completely describe all of the fields within a Samba configuration file. There have been no additional field names added in support of clustering, and the file format follows the normal Samba conventions.

Shown below is an example smb.conf.sharename file which was automatically generated by cluadmin in response to the service specific parameters. This example file matches the above cluadmin service configuration example.

# Template samba service configuration file - please modify to specify
# subdirectories and client access permissions.
# Remember to copy this file over to other cluster member, and create
# the daemon lock directory /var/cache/samba/acct.
#
# From a cluster perspective, the key fields are:
# lock directory - must be unique per samba service.
# bind interfaces only - must be present set to yes.
# interfaces - must be set to service floating IP address.
# path - must be the service mountpoint or subdirectory thereof.
# Refer to the cluster documentation for details.

[global]
        workgroup = RHCLUSTER
        lock directory = /var/cache/samba/acct
        log file = /var/log/samba/%m.log
        encrypt passwords = yes
        bind interfaces only = yes
        interfaces = 10.0.0.10

[acct]
        comment = High Availability Samba Service
        browsable = yes
        writable = no
        public = yes
        path = /mnt/service12

The following are descriptions of the most relevant fields, from a clustering perspective, in the /etc/samba/smb.conf.sharename file. In this example, the file is named /etc/samba/smb.conf.acct in accordance with the share name being specified as acct while running cluadmin. Only the cluster specific fields are described below. The remaining fields follow standard Samba convention and should be tailored accordingly.

Windows Client Access to Samba Shares

Windows clients see no discernible difference when accessing shares that are being served by a high availability cluster. From the Windows client's perspective the only requirement is that they access the Samba share via its floating IP address (or associated hostname) which was configured using cluadmin, e.g. 10.0.0.10. The Windows clients should not directly access the share from either of the cluster member system's IP address (e.g. clu3 or clu4).

Depending upon the authorization scheme to be utilized in the cluster environment, the smbpasswd command may have to be used to establish Windows account information on the cluster servers. When establishing these accounts, it is required that the same Samba related account information be setup on both cluster members. This can be accomplished either by running smbpassword similarly on both cluster members, or by running the command on one system and then copying over the resulting /etc/samba/smbpasswd file to the other system. For example, to enable a Windows client system named sarge to access a Samba share served by the cluster members, run the following command on both cluster members, taking care to specify the same username and password each time:

smbpasswd -a sarge

On a Windows client, the Samba share can then be accessed in the conventional manner. For example, it is possible to click on the Start button on the main taskbar, followed by selecting Run. This brings up a dialog box where the clustered Samba share name can be specified. For example: \\10.0.0.10\acct or \\cluacct\acct. To access the samba share from a Windows client it is also possible to use the Map Network Drive feature. Ensure that the hostname portion of the share name refers to the floating service IP address. Following the hostname / IP addresses from the above /etc/hosts excerpt; the correct name to refer to this highly available cluster share is \\cluacct\acct. The share should not be accessed by referring to the name of the cluster server itself. For example, do not access this share as either \\clu3\acct or \\clu4\acct. If a share is incorrectly referred to by the cluster server name (e.g. \\clu3\acct), then the Windows client will only be able to access the share while it is being actively served by clu3, thereby negating any high availability benefits.

Unlike the NFS protocol, the Windows based CIFS/SMB protocol is more stateful. As a consequence, in the Windows environment, it is the responsibility of the individual application to take appropriate measures to respond to the lack of immediate response from the Samba server. In the case of a planned service relocation or a true failover scenario, there is a period of time where the Windows clients will not get immediate response from the Samba server. Robust Windows applications will retry requests which timeout during this interval.

Well-behaved applications will correctly retry for a service response, resulting in Windows clients being completely unaware of service relocations or failover operations. In contrast, poorly behaved Windows applications will result in error messages in the event of a failover or relocation indicating the inability to access the share. It may be necessary to retry the operation or restart the application in order to enable Windows client systems to reattach to a Samba share for applications that do not correctly behave during failover or service relocation.

The behavior of a Windows based client in response to either failover or relocation of a samba service also varies on which release of windows is installed on each client system. For example, Windows 98 based systems often encounter errors such as, "The network path was not found". Whereas, later versions such as Windows 2000 transparently recover under the same set of circumstances.