Attaching Fibre Channel Libraries

One of the interesting things about modern SAN technology is the advent of fibre channel tape drives. With fibre channel tape drives is is possible for multiple hosts to share tape drive devices. This is useful in designing a backup archetecture around a SAN. It makes it possible to move backups off of the IP network and onto the storage network which is many, many times more efficient.

Prior to fibre channel tape drives it was possible but a bit less convenient to accomplish the same thing with a network storage router. The storage router would have scsi connections for tape devices and 1 or more fibre channel ports which could be attached to a SAN. The basic difference in the 2 methods is in how the scsi tape devices are seen by the host. If the tape devices are scsi devices routed through the NSR then on the host they will appear as several logical units on a single target. On the other hand if they are fiber channel devices then they will appear to the host as logical unit 0 on multiple targets.

Here is a sample st.conf configuration file with lun configurations for LTO-2 scsi tape drives and a library robot which are SAN attached via 2 network storage routers. The target and lun definitions are near the bottom. The qla2300.conf file with the bindings to the NSR ports is here

Here is a jnic.conf file with bindings for fibre channel STK HCART drives. The entries of interest are the jnic0 and jnic5 entries near the bottom of the file. This configuration required no additional st.conf entries because lun 0 is defined there by default.

Some advantages of fibre channel tape libraries include:

  • Makes it possible for multiple hosts to share tape drives. For example if one of the backup server clients is a file server serving 2 TB of data to the enterprise it would be far more efficient for that client to write the data directly to a fibre channel tape drive rather than accross the corporate network to the backup server and then to tape. The enterprise backup software vendors today provide this sort of functionality. Legato calls this "Dynamic Drive Sharing" and the client would be a "SAN Storage Node".

  • Allows flexibility as to where the library is located in relation to the backup server.

  • Provides bandwidth for fast modern tape drives.

Gotchas

  • I've seen this happen more than once. The problem can occur when the backup admin defines the library configuration. Usually this includes specifying devices that represent the library robot, and tape drives. In veritas netbackup the tpconfig is used to define library characteristics and with legato networker jbconfig is used. What can happen is this, solaris sees the tape drives as /dev/rmt/0-3 but in fact /dev/rmt/0 is drive 2 from the library's point of view. The result will be that the backup s/w will load tapes into the wrong drive and operations will fail. To avoid this simply load a tape into one of the drives and use mt on the solaris side to confirm that the drive assignment is what you think it should be.

  • When creating a zone with in your fabrics to enable the backup server to see the tape drives, use port zones instead of WWN zones. Tape drives fail more often than switch ports. If you use WWN zones you will have to tinker with the zone definitions as well as the host bindings to the tape drives everytime a tape drive is replaced. With port zones your work will be limited to the host configuration adjustment.

    You are visitor number 1568