Sumit Gupta's Blog

Persistent bind solution, Creating consistent tape links across SAN

The famous "Persistent Bind" (aka Consistent Binding) issue: For a very long time I was just told that the "tape links are not persistent". I always replied "They dont change across reboots. Whats the exact problem ?" and everybody I asked, had a different definition of it.

Recently when I talked to a SUN support engineer for a specific account and he explained me the exact steps which lead to this problem.

Problem Description
To simplify management of servers in SAN-based data-centers, the SAN Foundation Software stack in the Solaris OS dynamically detects devices in a SAN and builds associated /dev tree entries without the need to edit configuration files. In most cases this greatly simplifies SAN management however, for tape devices, some system administrators would still like the ability to explicitly specify how /dev entries are created and to insure the /dev entries are identical across multiple servers on a SAN. The procedure given below describes how administrators can specify this tape binding in the Solaris OS while retaining the benefits of automatic discovery and addition for disk-based devices.

Background
The /dev/rmt directory contains links to physical devices under /devices for tape devices. Each tape LUN seen by the system is represented by 24 minor nodes in the form of /dev/rmt/<N>, /dev/rmt/<N>b, /dev/rmt/<N>bn where N can be any number starting from 0. This number is picked up by devfsadm during enumeration of new devices. Every new tape LUN found by devfsadm gets the next available number in /dev/rmt.

Since the /dev/rmt name is dependent upon the order in which devices appear in the device tree, it changes from host to host i.e. For a given tape drive seen by two or more different hosts, the /dev/rmt link can be different on each of these hosts. This breaks the most common usage of Netbackup (SSO option). Also if the drive is replaced the links change unless the vendor provides a way to retain the PWWN of the drive.

Approach
The /etc/devlink.tab file is called the default device table file. It specifies rules that devfsadm uses to create links in the /dev directory. See 'man devlinks' for more information. Currently there are no entries in this file for tapes because devfsadm already knows how to create links for tape drives, but rules can be added that will take modify the default behavior for creating tape links.

The following is a sample entry for tape in devlink.tab:

type=ddi_byte:tape;addr=w<PWWN>,<LUN>; rmt/<rmt #>\M0

the administrator should change the rmt # to whatever /dev/rmt/<N> is required. Then change the Port World-Wide Name (PWWN) and Logical Unit Number (LUN) to match the desired tape device. This information can be obtained by doing a ls -l on the existing /dev/rmt/ link as shown below.

# ls -l /dev/rmt/4
lrwxrwxrwx 1 root root 69 Oct 6 14:57 /dev/rmt/4 ->
../../devices/pci@1f,700000/SUNW,qlc@2/fp@0,0/st@w5005076300617717,0:
#

If, for example, the administrator wants the /dev/rmt/ number to be 40, the entry in /etc/devlink.tab will look like:

type=ddi_byte:tape;addr=w5005076300617717,0; rmt/40\M0

The administrator can then add this line to the devlink file on every Solaris server on the SAN that uses this drive so that it always appears as minor node 40.

Notes
1. For any tape drives visible to Solaris but not specified in the devlink file, devfsadm will automatically assign minor node numbers starting from zero. These will conflict with any low numbers assigned by the administrator in /etc/devlink.tab so be sure to assign numbers high enough to avoid conflicts.

2. This approach can easily lead to duplicate links in /dev/rmt. That is because any tapes discovered before entries are specified in /etc/devlink.tab will have automatically-created links. Then when entries are added and devfsadm is run, the original links will remain resulting in duplicate links. To remove the original links in /dev/rmt, run 'rm /dev/rmt/*' before running devfsadm as described in the specific steps below.

3. This approach cannot be used with multi-ported tape drives that are attached to multiple HBA ports. If one does have multiple HBA ports attached to the same tape LUN then the system now thinks that there are two tape drives instead of one the one that appears last in prtconf output will get the link generated by the /etc/devlink.tab.

Specific Configuration Steps
1. Create the entries in /etc/devlink.tab as shown above. If devfsadm has previously discovered the devices, the device address can be obtained by doing a ls -l on the existing link. Take care to assign /dev/rmt/<N> numbers, to avoid conflicts with any automatically configured devices as described above.

2. Remove existing links from /dev/rmt by running 'rm /dev/rmt/*'

3. Run devfsadm. This will create new links as per the entries in /etc/devlink.tab in addition to automatically creating links for any unspecified devices.

Posted at 11:32AM Nov 01, 2005 by hbainsights in General  |  Comments[12]