ibm.com/redbooks Redpaper

Front cover

Managing device addressing of SAN attached tape For use with Tivoli Storage Manager

Steve Strutt

Practical guidance for TSM administrators

Manage your shared tape devices with TSM

Understand Persistent Naming

International Technical Support Organization

Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

April 2002

© Copyright International Business Machines Corporation 2002. All rights reserved.Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions setforth in GSA ADP Schedule Contract with IBM Corp.

First Edition (April 2002)

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. QXXE Building 80-E2650 Harry RoadSan Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.

Take Note! Before using this information and the product it supports, be sure to read the general information in “Special notices” on page v.

Contents

Special notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v

IBM trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiAbout the author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiNotice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiTivoli Storage Manager and tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Why does adding or removing devices cause an issue? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Managing device addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Ensuring data integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Device name assignment in SANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Fibre device to SCSI address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Persistent device addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

HBA persistent naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Gateway and router persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Host device name assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8TSM device definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Windows device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9AIX device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Sun Solaris device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Managing without persistent naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Managing SAN tape devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11SAN hardware configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Switch zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Systems Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12SAN Management tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

© Copyright IBM Corp. 2002 iii

iv Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Special notices

References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service.

Information in this document was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites.

© Copyright IBM Corp. 2002 v

IBM trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:

e (logo)® IBM®

Redbooks™Tivoli®

Redbooks (logo)™

Other company trademarksThe following terms are trademarks of other companies:

C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries.

PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license.

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries.

UNIX is a registered trademark in the United States and other countries licensed exclusively through The Open Group.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

vi Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Preface

Fibre Channel based SANs provide a flexible way of connecting storage devices and hosts over a shared network. Tivoli Storage Manager (TSM) exploits the bandwidth and connectivity to provide LAN-Free backup and library sharing capabilities using shared tape devices over the SAN. However, the building of SANs to support the use of shared tape devices must take into account a number of considerations specific to the use of tape. These are required to ensure that the addition of new storage devices, or that the removal or failure of existing devices on the SAN does not result in TSM operational failures when using shared tape devices. This paper is not intended to be an exhaustive description of the TSM or SAN hardware configuration options that avoid tape device addressing issues, but it is intended to provide practical guidance for TSM administrators and people implementing TSM in SAN environments. It covers the Microsoft Windows, IBM AIX, and Sun Solaris platforms; as well as some of the common hardware components used when building SANs.

About the authorSteve Strutt has worked with storage and storage management products for the last 15 years. Currently he works as a systems engineer for the IBM Software Group in the UK, specializing in presales support for the Tivoli storage management product set. Before joining the Software Group, he worked in IBM's S/390 and Storage Systems divisions on storage and storage management products, working with the Tivoli Storage Manager (then called ADSM) product since before it was first announced. His recent focus has been on Storage Area Networks, concentrating on how they can be exploited and managed using Tivoli Software. Steve is a recognized expert in his field and has worked with many major European customers.

This paper was converted to Redpaper format by:

Barry KadleckInternational Technical Support Organization, San Jose Center

NoticeThis publication is intended to help TSM administrators to configure and manage TSM in SAN environments. The information in this publication is not intended as the specification of any programming interfaces that are provided by Tivoli Storage Manager.

Comments welcomeYour comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about this Redpaper or other Redbooks in one of the following ways:

� Use the online Contact us review redbook form found at:

ibm.com/redbooks

� Send your comments in an Internet note to:

© Copyright IBM Corp. 2002 vii

redbook@us.ibm.com

� Mail your comments to the address on page ii.

viii Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Tivoli Storage Manager and tape Fibre Channel based SANs provide a flexible way of connecting storage devices and hosts over a shared network. Tivoli Storage Manager (TSM) exploiting the bandwidth and connectivity to provide LAN-Free backup and library sharing capabilities using shared tape devices over the SAN.

However, the building of SANs to support the use of shared tape devices must take into account a number of considerations specific to the use of tape. These are required to ensure that the addition of new storage devices, removal or failure of existing devices on the SAN does not result in TSM operational failures when using shared tape devices.

Why does adding or removing devices cause an issue?The potential for impact on TSM arises from the ability of Fibre Channel based SANs to allow devices to be added and removed without disruption, and to be automatically mapped to hosts without administrator involvement. This flexibility can affect access to existing devices as the addition or removal of devices can result in the SCSI addresses and the device names e.g. //./Tape0, assigned to existing devices changing. The impact of changes depends on the host platform, and typically results in TSM losing access to the devices. Environments using AIX are relatively insensitive to changes, but other platforms, such as Microsoft Windows and Sun Solaris, require more attention and careful setup to avoid changes in device names and SCSI addresses.

Current releases of TSM rely on pre-configured definitions for tape devices that assume the relationship between the host device names specified in the TSM device definitions and the physical devices does not change. Changes in the device name to physical device relationship, or in the host SCSI address of a device, may result in invalid TSM device definitions, where the specified SCSI addresses or device names point to the wrong device or a device that does not exist. This can give rise to loss of access to the device, I/O errors, and operational failures, which results in increased TSM administration.

As SAN configurations grow, the device definitions for many systems can be affected by a single device change on the SAN. The impact of this on the reliability and operation of TSM environments using library sharing or LAN-Free backup starts to become significant. Hence, the challenge is to ensure that changes in the SAN configuration do not affect the device addresses and names that TSM uses to access tape devices.

© Copyright IBM Corp. 2002 1

Managing device addressingThe main approach that is used to ensure that the relationship between a host device name and a physical device does not change is the use of Host Bus Adapter (HBA) persistent naming with a static device naming convention. Persistent naming or binding creates a fixed physical device to SCSI address relationship, which does not change as devices are added or removed. Static device naming ensures that the same device name is always assigned to the same physical device and usually relies on persistent naming to ensure that the device's SCSI address remains fixed to accomplish this.

The remainder of this paper looks at what persistent naming is and the device naming conventions that can be used to ensure that no impact on TSM as SANs change. Then, for environments where persistent naming is not available, it looks at the configuration options and practices that can minimize the likelihood of device addressing changes and their impact on TSM. The recommendations made are summarized at the end of this paper.

Ensuring data integrityTypically, the first indication that a TSM device definition is invalid, and does not point to the correct device, is when I/O errors occur while accessing the device. If the definition points to a non-existent device, no harm results. However, if it points to another real tape device which is already in use, then the integrity of data being written to the device may be compromised. To avoid this and ensure the integrity of tape-based data, the SCSI command set enables serialization of tape drive usage through the implementation of a protocol called Reserve/Release.

During normal operation TSM performs SCSI Reserves against the tape devices it is using to ensure that it is the sole user of the devices. This means that one host cannot accidentally access a tape drive while another TSM server or Storage Agent is using it. After use, ownership of the drive is released via a SCSI Release command. Any invalid access to a drive currently in use will result in an I/O error on the host with the invalid device definition. The existing SCSI Reserve blocks the invalid access, without impact on the host already using the drive.

The use of SCSI Reserve/Release by TSM’s device driver avoids any possibly of data corruption, but administrator involvement is required to correct the invalid device definition. The best practice is to avoid device address changes in the first place. This Reserve/Release capability is also provided in the IBM Ultrium LTO device drivers. For Windows 2000 it is recommended that level 5.0.2.4 or higher of the LTO driver should be used, as levels prior to this did not use SCSI Reserves.

Device name assignment in SANsThere are several stages in mapping a physical device to TSM. In this process there are a number of different address mappings and all are potential causes of device address changes.

2 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Figure 1 shows the different stages in mapping a tape device to a TSM device name. The operating system (OS) device name, which TSM uses for device access is typically assigned when the HBA logs into the SAN fabric as the system is powered up. The HBA maps the World Wide Names (WWNs) of the fibre devices presented by the fabric to the SCSI addresses that the host OS understands. When using Qlogic adapters with Windows hosts, an intermediate step of mapping the WWNs to loop ID by the HBA driver is also apparent. The SCSI device addresses are then mapped to device names by the host OS.

Figure 1 Stages of device name mapping

If the tape devices are not directly fibre attached, and are attached via a fibre to SCSI router or gateway, an additional level of address mapping exists from the SCSI addresses of the tape devices to the LUN addresses it presents to the fabric.

As mentioned earlier, the main approach to managing the issue of device address changes is the use of persistent naming by the HBA coupled with a static device naming convention. Persistent naming or binding creates a fixed SCSI address to the physical device relationship, which does not change as devices are added or removed. Use of a static naming convention ensures that the same device name is always assigned to the same physical device, and typically refers to a device's SCSI address, which must remain unchanged. Together these ensure that the relationship between the device name and the physical device do not change, ensuring that there is no impact on TSM as the SAN changes.

Fibre device to SCSI address mappingIn a switched fabric the device driver for the HBA performs the mapping of Fibre Channel device addresses (WWNs) to SCSI addresses. Using a Qlogic HBA as an example in a Microsoft Windows environment, two address mappings occur. The WWN is mapped to a loop ID which is then mapped to a corresponding host SCSI address.

Figure 2 is from the Qlogic QLconfig utility and shows the assigned loop IDs for a HBA connected to a SAN that is comprised of Brocade switches. The loop ID is determined when the HBA logs into the switched fabric. These are assigned dynamically and depend on the devices that the HBA can see within the zones of which it is a member. In the example Windows environment, the ordering of the devices by loop ID apparently comes from the order in which the devices are found in the fabric Name Server table.

HBAOS

DeviceDriver

TSM

OS DeviceName to

TSM DeviceName

SCSI IDto

OS DeviceName

DeviceWWN

toSCSI ID

ID1

ID2

ID3

WWNTape

Drives

Gateway/Router

SAN

HOST

WWN

Device WWNSCSI ID to LUN

3

Figure 2 Qlogic QLconfig utility

Figure 3 shows the Name Server table for a fabric comprised of two Brocade 2400 switches. Devices are ordered in the table by the switch domain number and then by the port number of the switch they are connected to. The ordering of the devices in the Name Server table is used for the sequence in which devices are assigned loop IDs by Qlogic HBAs in Windows environments. A comparison of the Port WWN column in Figure 3 to the Device Port Name column in Figure 2 shows the same device order.

4 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Figure 3 Brocade Name Server Table

The loop IDs are then translated by the HBA device driver into the SCSI addresses that the host OS sees. The seven devices shown in Figure 2 and Figure 3 have the following loop ID to SCSI ID, and SCSI bus mapping using Qlogic HBAs in the example SAN (Table 1).

Table 1 SCSI mapping

A consequence of using the order of the entries in the Name Server Table to determine the assigned loop ID, and hence, SCSI ID, is that the relationship between device identified by a WWN and its SCSI address can change. When devices are added, removed, fail or are swapped from one switch port to another, the existing assigned loop ID, and hence, SCSI address by which they and other devices are accessed may change. These changes may not necessarily become apparent immediately at the attached hosts, but usually the next time the system is restarted. If persistent naming is supported and used, then the issue of existing SCSI addresses changing does not arise. The physical device as defined by its WWN is always mapped to the same SCSI address.

As can be seen from the previous discussion, device changes can result in changes to the SCSI addresses that are assigned to devices, though this is only if persistent naming is not used or supported. Typically, this may cause any existing TSM device definitions to become invalid, and the devices will not be accessible.

Loop ID SCSI Target ID SCSI Bus

130 0 0

131 1 0

... ... ...

136 6 0

5

If device changes are properly planned and implemented via consistent change control processes, then changes in SCSI addresses may be corrected in the TSM device definitions, before failures occur. This will usually require systems to be restarted and the device definitions updated. The unsocial hours when hardware changes can be made, and when there are opportunities to restart systems, is a good incentive to avoid the issue. Change Management, however, cannot help in a situation when unplanned changes occur due to device failures.

The effects caused by unplanned changes can be minimized through use of SAN network topology monitoring tools such as Tivoli Storage Network Manager (TSNM). Unplanned changes due to device failures can be detected and any affected systems updated. In the absence of proactive SAN network monitoring, operational failures caused by unplanned changes can be identified through systems management monitoring of TSM device errors.

Persistent device addressingThere are two aspects to providing persistence of device SCSI addresses for tape devices in a SAN. The first is the persistence in the relationship between the host SCSI address and a fibre tape device. The second is when the tape devices are not attached directly to the SAN, but via a gateway or router.

Most HBA vendors have already provided solutions to the problem of device addresses changing by implementing static device mapping capabilities in their HBA drivers. This can be known as SCSI mapping, persistent binding, or naming. This provides persistent device mapping across system restarts, ensuring that once a SCSI address has been assigned to a device, it does not change as devices are added or removed. This is usually performed by fixing the SCSI address to the WWN of the device.

The previously discussed considerations relating to the assignment of SCSI addresses also apply to a gateway or router as this is also a fibre attached device. However, in addition, the gateway or router also applies its own address mapping from the SCSI addresses of its attached devices to the LUN addresses that the gateway or router presents to the fabric. This mapping must also remain static as devices are added or removed from behind the device.

HBA persistent namingAll HBAs provide persistence of SCSI addresses while a system is operating between reboots. SCSI addresses assigned to devices at boot time or if detected during operation, remain assigned until the system is shutdown. This is also true if devices are removed from the SAN. The SCSI addresses assigned to existing devices remain unchanged until the system is shutdown.

EmulexThe Emulex multi-protocol drivers for Microsoft Windows and Sun Solaris provide the capability to track a Fibre Channel device, and ensure that the same SCSI addresses are applied at all times. The term used is SCSI mapping.

With SCSI device mapping, the default is to track devices using their World Wide Port Names (WWPN). Once a device has been assigned a bus/SCSI target ID, the device will always continue to be mapped to the same bus/target ID based on WWPN or Nodename.

On the Windows platform, the elxcfg utility is provided with the multi-protocol driver to configure the SCSI mapping and additionally to provide LUN mapping.

6 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Figure 4 shows the elxcfg utility with the option selected to map SCSI addresses. By default when new devices are detected, they are added to the end of the existing mapping with higher SCSI addresses. The LUN Mapping checkbox can also be selected to perform tracking of device LUNs behind gateways and routers.

Figure 4 Emulex elxcfg utility

QlogicCurrently, Qlogic only provides persistent device addressing with their drivers for Sun Solaris. The Qlogic term for this is persistent binding. This feature is not currently provided for the Windows platform.

Gateway and router persistenceWith fibre attached tape devices, the drive is usually mapped to LUN0 of the device. When the tape drives are SCSI devices attached through a gateway or router an additional mapping occurs. This is from the SCSI addresses of the devices attached to gateway or router to the LUN addresses that are presented to the fabric.

From a TSM perspective, the LUN address for a device must also remain static. The addition of new tape devices, removal or failure of a device behind a gateway or router should not result in LUN addresses changing. The gateway or router must, therefore, be configured to ensure static and persistent LUN mapping, regardless of device changes. In a Windows environment that uses Emulex adapters, static LUN mapping can also be performed by the HBA. The recommendation is to perform LUN mapping at the gateway or router as this provides fixed LUN mapping for all platforms.

7

For SCSI tape devices attached to a SAN via a gateway or router, the HBA determines the host SCSI target ID, bus and port address for the device. The LUN address used for the tape device comes from the gateway or router itself and there are a number of different ways LUN addresses can be mapped. Of the two commonly used gateways and routers, the persistent LUN mapping options ensure that if devices fail or are removed the existing LUN mapping remains unchanged.

CrossRoadsThe CrossRoads CONxSAN 4x50 range of storage routers provide a number of LUN mapping modes. The most relevant are Auto Addressing and Indexed Addressing.

Auto Addressing: A new SCSI to LUN address map is created each time the device is rebooted. This is not useful in a TSM environment, as the failure of a device can result in the LUN mapping changing at the next time the router is rebooted. This is the default.

Indexed Addressing: This provides a persistent and static mapping of SCSI ID to LUN address, and is maintained by either editing the mapping table, or by an automatic population of the mapping table initiated by an administrator when the device is configured.

ADIC and IBM SAN Data GatewayThe ADIC and IBM SAN Data Gateway by default use a static SCSI ID to LUN mapping.

When the gateway is first installed, and the attached SCSI devices have been powered up, these are automatically mapped and the mapping is retained. If additional devices are added to the gateway, these are added to the end of the existing device mapping without changing previous entries.

If major device changes are made, then the mapping can be reset. This should not be considered lightly as it may result in all the LUN addresses assigned to devices behind the gateway changing, and may require updates to the device definitions for all the TSM Servers and LAN-Free clients (Storage Agents).

Host device name assignmentIn addition to persistent naming at the HBA, the second half of the solution to ensuring that the device name to physical device relationship remains constant, is the use of static device naming. This does not change as devices are added or removed.

The platforms supported by TSM use different approaches to device naming. The device drivers on AIX perform intelligent tracking of physical devices, and ensure that the assigned device name always points to the same physical tape device. It is, therefore, largely immune from the effects of device changes. This device naming approach is static by its nature.

However, Microsoft Windows and Sun Solaris behave differently. Static device naming on these platforms relies on HBA support for persistent device naming ensuring fixed SCSI addresses in changing SANs.

Before looking at how device names are assigned by hosts to tape devices, we need to look at how devices are defined to TSM. The current releases of TSM rely on preconfigured device definitions, which assume a host device name to physical device relationship remains constant over time. Without the use of persistent naming and static device names, this is not guaranteed.

8 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

TSM device definitions In TSM, libraries and tape devices are defined using DEFINE LIBRARY, DRIVE, DRIVEMAPPING and PATH statements. The PATH statement is new in TSM 4.2.1 and supersedes the DRIVEMAPPING statement.

The DEFINE LIBRARY and DEFINE DRIVE commands map the host OS assigned device names to the TSM administrator assigned device names by which the libraries and tape drives are known and accessed by TSM Servers, Library Managers, and Library Clients. The DEFINE DRIVEMAPPING or DEFINE PATH commands define to the TSM Server how Storage Agents access tape devices.

To set the device names used in these definitions, access is required to each TSM server or Storage Agent to determine the device names used by each host to access the devices. The utility TSMDLST is provided and can be executed on each host to determine the device names that have to be defined to TSM.

Windows device namingThe default Microsoft Windows naming scheme for tape devices is dynamic and device names change as devices are added and removed. It assigns device names in the form \\.\Tapex, where 'x' is a number. In this naming scheme, tape devices are given names starting with the tape device with the lowest SCSI address first and then numbered in ascending order starting from zero.

The disadvantage is that the name assigned to a physical device can easily change if new devices are added with lower SCSI addresses, or if the SCSI addresses given to devices change. Windows will name the new devices starting from \\.\Tape0 and the names assigned to existing devices will change. This means if devices are added, any existing TSM DRIVE or PATH definitions using Windows device names may have to be changed to refer to the correct physical device. Correspondingly, if devices fail or are removed from the fabric, existing \\.\Tapex device names can change.

With Windows NT, the mapping of SCSI addresses to OS device names is performed at boot time. If new devices are added after boot time, it has no impact on the existing OS device name mapping until the next time the system is rebooted. At the next restart, depending on the SCSI addresses assigned by the HBA, a different device name to SCSI address mapping can be applied, requiring changes to the TSM device definitions.

With Windows 2000, the SCSI address to OS device name mapping is performed both at boot time and due to the plug-and-play capabilities of Windows 2000; it is also performed when new devices are detected or devices removed. This means that in addition to the device name mapping potentially changing at boot time, it can also change whenever a new device is added, or a device is removed or fails. In-flight changes such as this can cause potentially serious problems, and TSM ensures data integrity by issuing SCSI reserves against the devices it is using to avoid an errant system accessing and writing to drives already in use by other systems.

It is recommended that because of the potentially changing nature of \\.\Tapex names on Windows NT and Windows 2000 platforms, this naming convention is not used. The alternative is to use a device alias name in the form of mtx.y.z.n for all tape devices. This identifies a device explicitly by its SCSI target ID, LUN, SCSI bus number and SCSI port on the host, rather than by its Windows assigned device name. On the Microsoft Windows platforms, the TSM supplied device driver (ADSMSCSI) uses this device naming scheme by default. This OS device name to physical device mapping remains constant if the SCSI addressing remains unchanged, which is the case when HBA persistent naming is used.

9

This recommendation also applies to tape devices that do not use the TSM device driver, such as IBM Magstar 3590, Ultrium LTO, or devices that use the native Windows device drivers. From the TSM Device Driver, Device Information screen, the SCSI address of a device can be determined and used to define the device to TSM in the form of mtx.y.z.n.

Figure 5 shows two tape devices \\.\Tape1 and \\.\Tape2. The device address information can be taken from the ID, LUN, bus and port columns, and is used to define device addresses of the form mtx.y.z.n where; 'x' is the SCSI target ID, 'y' is LUN, 'z' is the SCSI bus, 'n' is the SCSI port.

Figure 5 TSM Device Driver, Device Information screen

Note that the SCSI target ID and bus values are determined by the HBA. The SCSI port number depends on the number of SCSI and fibre adapters in the system, and can change if adapters are added or removed. The LUN address will typically be 0 for a direct fibre attached tape device, or if a SCSI device is behind a gateway, or determined by the gateway itself.

Using the devices from Figure 5 as examples, the alias definitions to be used by TSM are:

\\.\Tape1 mt7.1.0.4

\\.\Tape2 mt7.2.0.4

AIX device namingAIX device drivers handle tape device addressing in a persistent and intelligent manner. Once a device has been detected and assigned a device address such as /dev/mt0, or, if it is an IBM tape device /dev/rmt0, AIX will ensure that at each restart or device reconfiguration, the same device is always mapped to /dev/mt0 or /dev/rmt0. If the SCSI device address changes due to a SAN configuration change, then these changes are transparent to any user of the device, as it is always mapped to the same OS device name.

This remains true as long as the existing tape device definitions are not removed and redefined when new devices are added. Addition or upgrading of device drivers may sometimes make it necessary to remove all existing device definitions, in this case the TSM device definitions should be rechecked after reconfiguring the devices to AIX.

10 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

Sun Solaris device namingSun Solaris uses a fixed device mapping from SCSI ID to OS device name. When using the TSM device driver, device names are in the form of /dev/rmt/xmt, where x is a number. The IBM tape devices, such as Ultrium LTO, Magstar 3570 and 3590, use the device name form /dev/rmt/xst. Once the device definition has been created, the mapping of the device name to SCSI address remains fixed.

Coupled with the static SCSI addresses provided by HBA persistent naming, ensures that the device name to physical device relationship remains unchanged, as devices are added or removed from the SAN. Both Emulex and Qlogic provide persistent naming capabilities with their HBA device drivers on Solaris.

SCSI addresses are assigned depending on the number of devices visible to the HBA. However different from Windows, it has been found that with Qlogic adapters, it is not safe to say that the same SCSI mapping will be applied at each restart when persistent naming is not used, even if no changes occur on the SAN.

If changes are required in the Solaris device name definitions because devices have been added or removed, the device name mapping changes have to be manually performed by an administrator.

Managing without persistent namingIn environments where persistent naming is not supported or used, the use of systems management tools and processes can greatly help reduce or eliminate the impact that device addressing changes might have on the operation of TSM. Currently, this is especially relevant to Microsoft Windows environments using Qlogic HBAs for tape. The rest of this section assumes that persistent naming is not being used, and that SCSI address will change as devices are added or removed.

Even when persistent naming is not supported it is still recommended that on Windows 2000 the mtx.y.z.n approach to device naming is used. This avoids the additional problems associated with changes in \\.\Tapex device names resulting from the dynamic addition or removal of devices.

Managing SAN tape devicesThe largest opportunity for changes in device addressing occurs when systems and devices are being powered up. In environments that are not changing, the application of consistent processes to ensure that all storage devices have been powered up before servers are restarted, will help to ensure that the same device addressing is applied at each restart.

As can be seen from the earlier explanation of how SCSI addresses are assigned to Microsoft Windows hosts, the same device names and SCSI addresses will be assigned, as long as all the storage devices are visible to the host when it is booted.

However, if devices fail to power up or have been removed, the device mappings for each affected system must be checked to ensure that it is still as expected, or whether changes must be made to the TSM device definitions.

If changes cannot be avoided, then there are a number of approaches to minimize or eliminate the effects that device changes can have on TSM.

11

These can be broadly broken into two areas, hardware and systems management:

� Hardware

SAN zoning

� Systems Management

Change ManagementSAN Management Event Management

SAN hardware configurationCareful use of SAN zoning can minimize the number of hosts affected by the addition or removal of devices.

Switch zoningZoning can be used to restrict the number of devices that a specific host is able to see, to just those that it uses, and hence, reduces the effects that adding new devices to the SAN has on assigned SCSI addresses. At the logical extreme, this means one zone per host.

Only when devices are added to zones containing the host will possible changes occur to the assigned SCSI addresses for existing devices. Devices added in different zones will not affect the SCSI addresses that are already assigned.

By careful introduction of new devices and zoning, the impact of addressing changes can be minimized, and the systems requiring device configuration changes can be easily identified. However, this does imply restrictive zoning of devices and hosts, resulting in many zones, and more complex zone administration.

To maintain maximum SAN flexibility and usability, the preference is for fewer zones with device access being controlled by the applications or storage subsystems. This results in lower administration requirements and easier addition of new devices and hosts.

Systems ManagementThe use of Systems Management tools and processes can greatly help reduce or eliminate the impact that device changes have on the operation of TSM.

Change ManagementThe careful introduction of new devices, using Change Management procedures can eliminate device issues for controlled changes. All systems affected by a change can be identified prior to the device change, rebooted after the change, and their TSM device definitions updated to refer to the correct devices.

This works well for controlled changes, but does not help with unplanned changes or device failures.

12 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

SAN Management tools SAN Network discovery and monitoring tools such as TSNM can alert administrators to the fact that device changes have occurred on their SANs. Action can be taken to either repair or replace failed devices. Or, no further action may be required, other than taking the effected device offline to TSM. Systems can then be restarted and any addressing issues resolved at the next available opportunity.

Event ManagementIf tools like TSNM are not available, the first indication of a problem will be TSM device access failures and I/O errors. Event Management tools such as the Tivoli Event Console can be used to monitor TSM operations and alert administrators if problems occur. Action can then be taken immediately to determine the cause of the problem, and any device definitions updated to affect the current device configuration.

Summary The intent of this paper has been to show that the configuration of SANs for use with tape devices and TSM, requires careful thought. It provides recommendations on how the device addressing of SAN attached tape devices can be successfully managed to provide reliable business recovery and continuity solutions.

RecommendationsThe recommendations made in this paper on how to manage device addressing are summarized below:

� Where it is supported, use HBA persistent naming to ensure a fixed device WWN to SCSI address mapping. This is sometimes also known as SCSI mapping or persistent binding. Table 0-2 shows support for this feature by platform and by the HBA adapters looked at in this paper.

Table 0-2 Persistent binding support

� When SCSI tape devices are attached to a SAN via a gateway or router, ensure that a static mapping of tape device SCSI addresses to LUN addresses by the gateway or router is used.

� On the Microsoft Windows NT and Windows 2000 platforms, when a device driver other than the TSM driver is being used, use a static device naming convention. By default, Windows uses a \\.\Tapex device naming convention with non-TSM managed drives. The recommendation is to use a device alias name in the form of mtx.y.z.n for all tape devices which identifies a device by its SCSI and LUN address.

� When using IBM Ultrium LTO devices on Windows 2000, it is recommended that level 5.0.2.4 or higher of the LTO driver should be used.

Platform Emulex Qlogic

AIX Not applicablea

a. IBM 6227 or 6228 adapter is recommended

Not applicablea

Microsoft Windows Yes Nob

b. Not currently supported as of December 2001 at the 8.00.08 level

Sun Solaris Yes Yes

13

Device address and name persistence is central to building reliable SAN infrastructures for tape devices, and fortunately this is available for most platforms and commonly used HBAs today. For those platforms where device name persistence is not available, or cannot be implemented, systems management tools and processes can help considerably in managing device changes in these environments:

� Use switch zoning to limit the number of devices visible to a host, and hence, minimize the opportunity for device name changes.

� Change Management can be used manage change in a controlled fashion and ensure the device definitions of all effected systems are updated

� SAN Management tools can be used to identify if unscheduled changes occur due to device failures, and processes can be put in place to ensure that effected systems are updated.

� Event Management can be used to monitor TSM and determine if device errors are occurring due to unplanned changes.

14 Managing the device addressing of SAN attached tape for use with Tivoli Storage Manager

®

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

Redpaper

Managing device addressing of SAN attached tape For use with Tivoli Storage Manager

Practical guidance for TSM administrators

Manage your shared tape devices with TSM

Understand Persistent Naming

Fibre Channel based SANs provide a flexible way of connecting storage devices and hosts over a shared network. Tivoli Storage Manager (TSM) exploits the bandwidth and connectivity to provide LAN-Free backup and library sharing capabilities using shared tape devices over the SAN.

However, the building of SANs to support the use of shared tape devices must take into account a number of considerations specific to the use of tape. These are required to ensure that the addition of new storage devices, or that the removal or failure of existing devices on the SAN does not result in TSM operational failures when using shared tape devices.

This paper is not intended to be an exhaustive description of the TSM or SAN hardware configuration options that avoid tape device addressing issues, but it is intended to provide practical guidance for TSM administrators and people implementing TSM in SAN environments. It covers the Microsoft Windows, IBM AIX, and Sun Solaris platforms; as well as some of the common hardware components used when building SANs.

Back cover