Meta SAN Tape Consolidation

Brocade Multiprotocol Routing Services Solution Guide
Meta SAN Tape Consolidation

Version 1.0
Publication Number: 53-0000489-01 Publication Date: March 01, 2004
Copyright 2004, Brocade Communications Systems, Incorporated. ALL RIGHTS RESERVED. Publication Number: 53-0000489-01
Brocade, the Brocade B weave logo, Secure Fabric OS, and SilkWorm are registered trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. FICON is a registered trademark of IBM Corporation in the U.S. and other countries. All other brands, products, or service names are or may be trademarks or service marks of, and are used to identify, products or services of their respective owners. Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be currently available. Contact a Brocade sales office for information on feature and product availability. The authors and Brocade Communications Systems, Inc. shall have no liability or responsibility to any person or entity with respect to any loss, cost, liability, or damages arising from the information contained in this book or the computer programs that accompany it. Notice: The product described by this document may contain open source software covered by the GNU General Public License or other open source license agreements. To find-out which open source software is included in Brocade products, view the licensing terms applicable to the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd. Export of technical data contained in this document may require an export license from the United States Government.
Brocade Communications Systems, Incorporated

Corporate Headquarters 1745 Technology Drive San Jose, CA 95110 T: (408) 487-8000 F: (408) 487-8101 Email: info@brocade.com Asia-Pacific Headquarters 9/F, One International Finance Center, 1 Harbour View Street, Central, Hong Kong Tel: +852 2539 0600 Fax: +852 2539 0613 Email: apac-info@brocade.com European Headquarters 29, route de lAeroport Case Postale 105 CH-1211 Geneva 15, Switzerland T: +41 22 799 56 40 F: +41 22 799 56 41 Email: europe-info@brocade.com Latin America Headquarters 5201 Blue Lagoon Drive Miami, FL 33126 T: (305) 716-4165 Email: latinam-sales@brocade.com
Document History
The table below lists all versions of Meta SAN Tape Consolidation. Document version Initial Release Publication Number Publication Date 53-0000489-01 3/01/2004
Table of Contents
Preface Chapter 1 Meta SAN Tape Consolidation Overview

1-3 1-3
1.1. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1. Meta SAN Tape Consolidation Solution at a Glance . . . . . . . . . . . . . . . . . . . . . . . 1.1.1.1. Assumptions 1.1.1.2. Step-by-Step Overview
Chapter 2
Solution Requirements and Design

2-2 2-3 2-4 2-5
2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Meta SAN Design Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. LSAN Design and Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Detailed Hardware and Software List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 3
Configuring the Brocade Meta SAN

3-2 3-3 3-3 3-4 3-5
3.1. XPATH OS Upgrade Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Configuring FCRS on the Multiprotocol Router . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 FCRS Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Meta SAN Logical Connectivity.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Configuring Multiprotocol Router FCRS Tape Edge Fabric Connectivity .
3.4 Configuring FCRS for SAN 1 and SAN 2 on the Multiprotocol Router . . . . . 3-12 3.4.1 SAN 1 Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 3.4.2 SAN 2 Single Fabric FCRS Configuration Steps. . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.4.3. Verifying the FCR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 3.5. Creating the LSAN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.5.1. LSAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14 3.5.2. LSAN Detailed Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
3.6. LSAN Configuration on SAN 1 Fabric A and SAN 2 . . . . . . . . . . . . . . . . . . . . . 3-21 3.6.1. SAN 1 Fabric A and SAN 3 LSAN Configuration Steps . . . . . . . . . . . . . . . . . . . . 3-21 3.6.2. SAN 2 and SAN 3 LSAN Configuration Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21 3.6.3. Verifying the Completed Meta SAN LSAN Configuration . . . . . . . . . . . . . . . . . . 3-22
Chapter 4
Installation and Setup of Veritas NetBackup

4-2 4-4 4-5 4-6 4-7 4-7 4-9
4.1. Preparing the Sun Solaris Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Installing NetBackup 4.5 on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Installing NetBackup DataCenter GA on the UNIX Hosts . . . . . . . . . . . . . . . . . . 4.2.2. Installing Veritas NetBackup MP6 Patch on Solaris . . . . . . . . . . . . . . . . . . . . . . . 4.2.3. Installing the Solaris Media Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4. OPTIONAL: Configuring the SG Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Preparing the Windows Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4. Installing NetBackup 4.5 on Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 4.4.1. Installing Veritas NetBackup MP6 Patch on Windows . . . . . . . . . . . . . . . . . . . . . 4-11 4.4.2. OPTIONAL: Install Special Critical Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 4.5. Final Setup of NetBackup 4.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13 4.5.1. Configuring the Master Server for Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13 4.5.2. Central Management of Media Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14 4.5.3. Configure the STK Tape Library On the Media Server . . . . . . . . . . . . . . . . . . . . . 4-14 4.5.4. Viewing the NetBackup 4.5 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17 4.5.5. Performing a Test Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18
ii
Preface
Warning: This document is based upon an early release of XPath OS. The information, functionality, and guidelines discussed are preliminary and may change in substance or form prior to GA (General Availability) of Brocade XPath OS.
Introduction
Brocade's new SAN Routing technology extends benefits throughout the enterprise by helping to maximize the value of SANs and by providing a flexible foundation for implementing a utility computing infrastructure. The Multiprotocol Router increases SAN functionality and versatility in a single platform by delivering the following functionality:
Fibre Channel Routing Services (FCRS) for FC-to-FC routing FCIP Tunnelling Services (FCIP) for SAN extension over distance iSCSI Gateway Services (iSCSI) for iSCSI-to-FC protocol conversion
The objective of the Multiprotocol Router Solution Guide is to identify known working configurations and product functionality and then to communicate this information in a form so that customers can easily use the configuration examples or reasonable derivatives, avoid known issues, and successfully evaluate identified product functionality. This Solution Guide covers the planning, design, installation, configuration and implementation of Multiprotocol Router.
Solutions Using the Multiprotocol Router

Multi-protocol SAN Routing Services are deployed using the Brocade SilkWorm Multiprotocol Router, resulting in centralized management of advanced SAN functions with integrated FC routing, iSCSI, and FCIP tunneling on a single platform. The Multiprotocol Router simplifies SAN design, implementation, and management through centralization and consolidation, providing a seamless way to connect and scale across multiple SAN fabrics without the complexity of merging them into a single large fabric. One of the benefits of SAN connectivity using the Multiprotocol Router is that SAN troubleshooting and fault isolation is simplified within smaller environments, increasing data availability. Another benefit is that there is no need to resolve zoning or naming conflicts, which shortens the consolidation process. With the Multiprotocol Router it is possible to create logical SANs (LSANs) that enable selective connectivity between devices residing in different SAN fabrics. Selective sharing of devices using the Multiprotocol Router is useful for SANs that are geographically separated and/or managed by different organizations. Improved asset utilization can be realized by implementing the Multiprotocol Router through more efficient storage resource sharing--for example, sharing tape libraries across multiple SANs or seamlessly moving storage from a SAN that has a storage surplus to a SAN that has a storage deficit. Those SAN administrators familiar with the Brocade SAN environment will appreciate efficient LSAN provisioning through common zoning techniques already used in Brocade SANs today. It is also now easier to interconnect and support SAN fabrics purchased from different storage vendors. The flexibility and SAN extensibility enabled by the Silkworm Multiprotocol Router create many use case scenarios. Here are just a few use case examples for Brocade Multiprotocol Router:
SAN fabric Connectivity: Simplify scalability to support growing SAN environments Enable sharing of centralized resources: selective sharing or full consolidation across multiple SANs to maximize value of valuable storage resources Ease implementation of multiple OEMs and firmware revisions through centralization and consolidation Tape Consolidation: Centralize backup of multiple SANs fabrics in a single location to maximize value of backup devices and resources Increase utilization of high-end backup resources Leverage off-peak network connectivity Reduce management overhead requirements Increase asset utilization Low-cost SAN Connectivity: Enable iSCSI-to-FC protocol conversion so lower-cost servers can utilize shared Fibre Channel storage resources Reduce costs by eliminating the need to purchase Host Bus Adapters (HBAs) for lower-cost servers to access SAN resources Long-distance SAN Extension For Business Continuance: Enable remote devices to connect to SANs by using long-distance FCIP tunnelling capabilities Reduce costs by leveraging existing IP WAN infrastructure for long-distance SAN connectivity
Audience
This Solution Guide is targeted for use by partners and end users. The technical professionals that use this guide may include storage administrators, SAN administrators, system administrators, SAN architects, systems engineers, and SAN operators that are involved with the design, deployment, and management of Brocade SANs and Multiprotocol Router solutions. This Solution Guide is an advanced document and is very concise. Background information and supporting information for a particular topic are kept to a minimum and as appropriate, the reader is referred to supporting documentation. The reader is expected to have working experience with Brocade products. General computer system level troubleshooting skills are always important when configuring sophisticated enterprise solutions. System administration or storage administration experience is also helpful in understanding this document.
About Brocade Products Used in this Solution Guide

Brocade SilkWorm Multiprotocol Router Switch
The Brocade SilkWorm Multiprotocol Router is a 16-port switch that supports link speeds up to 2 Gbit/sec. Each port automatically negotiates to the highest common speed of all devices connected to the port. the Multiprotocol Router includes the Brocade XPath Operating System and is compatible with the entire Brocade SilkWorm product family. the Multiprotocol Router employs Brocades Inter-Switch Link (ISL) Exchange-Based Trunking to provide a high-speed data path between switches and supports an extensive list of additional features such as Fibre Channel routing, Fibre Channel over IP (FCIP), and iSCSI.
Brocade SilkWorm 3200 and 3800 Switches

The SilkWorm 3200 is an 8-port switch; the SilkWorm 3800 is a 16-port switch. Both are Fibre Channel switches support link speeds up to 2 Gbit/sec. Each port automatically negotiates to the highest common speed of all devices connected to the port. The SilkWorm 3200 and SilkWorm 3800 include the Brocade Fabric Operating System version 3.x, and are compatible with the entire Brocade SilkWorm product family. The SilkWorm 3200 and 3800 employ Brocade Inter-Switch Link (ISL) Trunking to provide a high-speed data path between switches.
Brocade SilkWorm 3900 Series Switches

The SilkWorm 3900 is a 32-port Fibre Channel switch that supports link speeds up to 2 Gbit/sec. Each port automatically negotiates to the highest common speed of all devices connected to the port. The SilkWorm 3900 includes the Brocade Fabric Operating System version 4.0.2, and is compatible with the entire Brocade SilkWorm product family. The SilkWorm 3900 employs Brocade Inter-Switch Link (ISL) Trunking to provide a high-speed data path between switches.
Brocade SilkWorm 12000 Switches

The SilkWorm 12000 is an enterprise-level Fibre Channel gigabit switch that supports link speeds up to 2 Gbit/sec. Possible configurations range from a 32-port switch to a dual 64-port switch in a single 14U enclosure. The SilkWorm 12000 employs Brocade Inter-Switch Link (ISL) Trunking to provide a high-speed data path between switches.
Brocade Fabric OS
Brocade Fabric OS is a real-time operating system that provides the core infrastructure growing businesses need to deploy scalable and robust Storage Area Networks (SANs). Fabric OS runs on the SilkWorm family of Fibre Channel switches. It supports scalable SAN fabrics that interconnect thousands of devices while ensuring high-performance data transfer among connected resources and servers. Fabric OS easily manages both large switch fabrics and Fibre Channel Arbitrated Loop (FCAL) configurations. Moreover, Fabric OS is highly flexible, making it easy for network administrators to add functionality and scale their SANs at the speed of business.
Brocade ZONING
Brocade ZONING is a feature allowing an administrator to create segmentation or zones within a Brocade Fabric, comprised of selected storage, servers, or even workstations. It also enforces access of information to only the devices in the defined zone. Zoning ensures environmental security and enables optimization of IT resources in response to user demand and changing user profiles.
Brocade Web Tools

Web Tools provides a graphical interface that allows the administrator to monitor and manage entire fabrics and individual switches and ports from a standard workstation. It is an optionally licensed product that runs on Fabric OS. All switches in the fabric are displayed in the main window of Web Tools, including switches that do not have a Web Tools license. However, only switches that have a Web Tools license installed can be managed through Web Tools (other switches must be managed through Telnet or SES).
Brocade ISL Trunking

Brocade Inter-switch Link (ISL) Trunking is an optionally licensed product available on all Brocade 2 Gbit/sec switches. Brocade ISL Trunking is managed using telnet commands or the Brocade Web Tools interface. The Brocade ISL Trunking feature allows up to four ISLs, connections between two switches through an Expansion Port (E_Port), to merge logically into a single link. When using Brocade ISL Trunking to aggregate bandwidth of up to four ports, the speed of the ISLs between switches in a fabric is quadrupled. For example, at 2 Gbit/sec speeds, Brocade ISL Trunking delivers ISL throughput of up to 8 Gbit/sec. Brocade ISL Trunking simplifies network design and reduces the cost of storage management by optimizing bandwidth utilization and enabling load sharing of traffic at the frame-level.
References

SAN Migration Guide (53-0000360-xx) Brocade SilkWorm, Design, Deployment, and, Management Guide (53-0000366-xx) Designing Next-Generation Fabrics With Brocade Switches (whitepaper http://www.brocade.com) LAN Guidelines For Brocade SilkWorm Switches (53-0000350-0x) Exploring Brocade ISL Trunking (53-0000263-0x) Core Switch PID Format Update Best Practices (53-0001626-0x) Brocade Zoning User's Guide Version 3.1/4.1 (53-0000523-0x) Zoning Implementation Strategies For Brocade San Fabrics (whitepaper http://www.brocade.com) XPath OS Procedures Guide (53-0000607-0x) XPath OS Reference Manual (53-0000605-0x) SilkWorm Multiprotocol Router Hardware Reference Manual (53-0000611-0x)
Solution Guide Conventions

The formatting and conventions used in this document are designed to help the reader locate and comprehend information quickly. In addition to the information provided in standard text, there are Guidelines, Notes, and Warnings to help focus the reader on important information. The following table describes the formatting conventions that are used in this book: Convention bold text Purpose
italic text
code text
identifies GUI elements identifies keywords/operands identifies text to enter at the GUI or CLI provides emphasis identifies variables identifies paths and internet addresses identifies book titles and cross references identifies commands in line with text identifies CLI output identifies syntax examples
Notes and Guidelines

The following notices appear in this document: Note: A note emphasizes important information or provides a reference to related information.
Guideline: A guideline provides a tip or a recommendation.
Warning:
Warnings alert you to potential damage to hardware, firmware, software, or data.
The red circle with a slash through it (shown below) indicates that a particular action or type of connection is not recommended. While the action or connection may function, there are better ways to perform the action or make the connection.
Chapter
Meta SAN Tape Consolidation Overview
To demonstrate the implementation of the Multiprotocol Router in a real-world context, this Guide uses an imaginary company (April Corporation) with typical SAN configurations and Tape Consolidation challenges. APRIL Corporation has multiple SAN Islands for their business units (see Figure 1-1). Currently there is one each for Engineering, Accounting and Sales. SAN 1 has dual fabrics, because critical Engineering data is stored on this SAN. Non -critical Sales and Accounting data (and associated backups) are stored on SAN 2, a single fabric SAN Island. SAN 3, a separate SAN Island, is used for backups of the critical data. The hosts have 3 HBAs, two for accessing the primary storage and a third for backups. APRIL Corporation has multiple Master backup servers and smaller tape libraries. The single tape library used to backup Engineering and Accounting data is not being efficiently utilized. Often it is idle and unused. Due to the separate responsibilities of each group and independent SAN fabric scaling requirements, a merging of SAN Islands to a single larger port count SAN is not feasible. To increase asset utilization and move towards a centralized backup management framework, the company desires a consolidated shared tape SAN environment.
Figure 1-1
APRIL CORP SAN Before Architecture

1-1
After analyzing the business requirements, APRIL Corporation designs a single Meta SAN using a Brocade SilkWorm Multiprotocol Router. By using the Multiprotocol Router, APRIL Corporation is able to increase the utilization of the tape library currently attached to SAN 1. Originally used only by the Engineering department on its dual fabric SAN island, the library is now available to other organizations (see Figure 1-2) . With this change, the second tape library is now free to be re-purposed or retired. The backup SAN Island can now scale completely independently and non-disruptively while achieving increased connectivity. To share this resource among all hosts in the Meta SAN, a Logical SAN (LSAN) is defined on each edge fabric. This allows the tape library to be accessed by a Media Server on each edge fabric. If additional Media Servers are required, it is easy to add them to the LSAN configuration by using the standard Brocade zoning tools. Additional hosts now only need to utilize two HBAs instead of three. The unused HBAs can be repurposed as well. The tape library, now connected as part of a Meta SAN using a single Brocade Multiprotocol Router for Fibre Channel Routing, provides a centralized backup resource that is easier to maintain and manage. Also, the tape library benefits from far greater utilization since all departments are now able to share it. As the company grows, additional edge fabrics and Media Servers can be easily added non-disruptively and scale independently to meet future business unit requirements.
Figure 1-2
Target Meta SAN Tape Consolidation Solution
1-2
1.1. Meta SAN Tape Consolidation Solution Overview

The Multiprotocol Router Tape Consolidation Solution presented in this Guide provides an example of how to deploy a Tape Consolidation Use Case, as discussed in the Brocade Multiprotocol Routing Services technical white paper. Please refer to the white paper for details on this and other use cases. The Multiprotocol Route provides iSCSI, FCIP and Fibre Channel Routing Services (FCRS) services. This solution provides relevant background information and demonstrates the configuration of FCRS for a tape backup environment. ISCSI and FCIP are not covered within the context of this solution. The intent of this Guide is to introduce the Brocade Silkworm Multiprotocol Router and the optionally licensed FCRS feature set to a technical audience by staging an actual FCRS deployment with 3rd party products. The purpose of the solution is to demonstrate how to configure the Multiprotocol Router to attach to multiple Brocade Fibre Channel fabrics. Establishing connectivity is the first step. Next comes setting up LSANs: LSANs will allow the sharing of tape devices among hosts attached to edge fabrics. The actual solution presented in this document was developed at Brocade, with real hardware and software. As it was developed, some guidelines were developed. These are passed along in this Guide to facilitate actual deployment of a similar solution for evaluation purposes.
1.1.1. Meta SAN Tape Consolidation Solution at a Glance

This section will provide an overview of each step required to design and deploy the Meta SAN Tape Consolidation solution. The remainder of the document will discuss details provided in this section.
1.1.1.1. Assumptions
For this specific solution it is assumed that
All Host Bus Adaptors (HBA) are installed in the hosts, and the drivers configured for F_Port attachment to four Brocade edge fabrics. The HDS 9910 and LSI E-Series RAID arrays have been set up to present LUNS for a multi-pathing configuration for each fabric-attached port. All edge fabrics connected to a Multiprotocol Router are properly licensed with Fibre Channel Routing Services (FCRS) and the ports offline. The switches are racked and configured according to the recommendations of the Design, Deployment, and Management (DDM) Guide Version 2.1 (53-0000366-02). All Meta SAN components are powered on and attached using proper cable management techniques. All hosts and switches are configured to properly access the RAID storage devices and are connected to the corporate IP network for management purposes.
1-3
1.1.1.2. Step-by-Step Overview

The document is organized according to the sequence of steps required to complete the deployment.
Design a Meta SAN for the Tape Consolidation use case. The requirements for this design are based primarily on the device-sharing scheme and MAPS (Management, Availability, Performance and Scalability), as presented in the DDM. Once determined, plan out the Meta SAN deployment. Label all fiber cable edge device connections and ISLs. Define and configure the Multiprotocol Router Ex_ports for Fibre Channel Routing. These connections are called Inter Fabric Links (IFLs) and provide the base-level connectivity required for device sharing. Define and configure the LSAN configuration based on the design plan. The LSANs allow devices to be shared between the edge fabrics. Configure each host's HBAs driver for persistent binding. Reboot and verify that the LSAN tape storage is available on each. Install the Solaris patch required for VERITAS Volume Manager. Verify that the Tape Library (in this case the STK L180) can be accessed by the Operating System on each device host. Install and configure VERITAS NetBackup DataCenter 4.5 on the Master Server (int123.) Install the MP6 patch. This includes configuring the SG driver if necessary: The SG driver is installed as part of the NetBackup application. This driver is used for discovering and using the tape library for initiated backup jobs. Once NetBackup has been installed and configured on the Master Server, verify the setup with a test backup. This entails the setup of a backup Policy.Note that int123 (the Master Server) will act as the robot control host. Now install the Media Server on int205 (the Solaris Media Server) and int124 (a Windows Media Server.) Add both to the Master Server configuration so that the Master Server can be managed them. Both Media Servers will point to int123 for the STK robot control. Configure each of the new Media Servers so that they share the STK L180 tape devices with the Master Server. Perform a test backup on the Media Server. Install the NetBackup client software on the remaining eight hosts. Do any final tuning to the NetBackup configuration. (This step is not discussed in this Guide.)
This completes the Overview. Please see the VERITAS NetBackup Installation Guide and the Veritas NetBackup Administrators Guide for UNIX and Windows for background information and further detailed instructions on installation and configuration options.
1-4
Chapter
An excellent discussion of SAN Design exists in Brocades Design, Deployment, and Management (DDM) Guide. For a current softcopy, please go to the Brocade Connect or Partner websites. Although the current version does not cover the Multiprotocol Router with Fibre Channel Routing Services (FCRS), otherwise known as a Fibre Channel Router (FCR), many of these same concepts and trade-offs still apply to the interconnection of related fabrics, which is what is now being called a Meta SAN. Thus the MAPS (Management, Availability, Performance and Scalability) framework covered in the Design section still apply and will be used as a basis for the discussion that follows. The switch and fabric setup should follow the guidelines in the Deployment section.
2-1
2.1. Introduction
A Meta SAN is a related interconnection of previously separate SAN islands. What makes these fabrics related? At one level, they are now connected and frames can be routed from one fabric to another without requiring a fabric merge. Core PID formats, zoning, and other fabric configurations can now remain separate. At a deeper level, devices previously on separate SAN islands can now be shared, providing increased asset utilization. This new sharing paradigm is called an LSAN. It is the LSAN that makes the Meta SAN framework related.
2-2
2.2. Meta SAN Design Connectivity

In the Meta SAN Tape Consolidation solution, the starting point is three separate SAN islands. SAN 1 is a highly available dual core/edge fabric with approximately 250 ports and attached devices. The fabrics that make up this SAN are called Fabric A and Fabric B. SAN 2 is a cascaded two-switch fabric. SAN 3 is a single SilkWorm 3800 with an attached STK Library being used by hosts on SAN 1. This is depicted in Figure XXX. A Meta SAN is desired to improve asset utilization. This will improve the usage of the tape library, but also will increase the number of utilized SAN fabric ports. Note that the FCR does not distinguish between SANs, only fabrics. From a manageability and availability perspective, a single Multiprotocol Router is desired since this Meta SAN is for tape backup purposes. If the Router was to have an unscheduled outage, the hosts still would be able to access the local fabric storage devices without disruption. In this case, therefore, two Multiprotocol Routers are not required. From a performance and scalability perspective, a single Multiprotocol Router also will meet the need. Each tape device uses about 30 MB/sec at peak bandwidth usage. While a single Inter Fabric Link (IFL) will be sufficient, (there are only 4 drives), it is good practice to have a minimum of two: In the event of a downed link, backup jobs can still be performed. Having two IFLs also provides load balancing for frames that traverse the Meta SAN. With 2 IFLs per fabric, a single Multiprotocol Router can connect up to 8 edge fabrics or 4 core/edge dual fabric SANs. The logical design is shown in Figure 2-1.
Fabric A
Fabric B
SAN 1
SAN 1
AP7420 as Multiprotocol FCR Router
SAN 2
SAN 3
Figure 2-1
2-3
2.3. LSAN Design and Plan

Now that the connectivity is designed, the next step is to design and plan out the LSAN configuration. This section will not cover the details of site preparation, rack layout, specific cable assignments for IFLs, ISLs, hosts and storage placements, etc. These details are covered in the Brocade Design, Deployment, and Management (DDM) Guide. Instead, a simple table with the essential information will be developed to illustrate what is minimally needed. One host from each fabric in SAN 1 and SAN 2 requires access to the tape library on SAN 3. The information needed is: the edge fabric to which they are attached; the specific port locations; the HBA and Tape physical WWPN and alias names; LSAN Zones. To uniquely identify a fabric, the FCR-assigned FID will be used. By default, this number is 2 + the physical port number to which an edge fabric switch is attached. The best way to summarize this information is within a table. Table 1 below shows the required information: Table 2-1 SAN Edge Fabric (FID) Switch Switch Name 14 SW3800 sialab88 15 SW3900 int219 8 SW2800 int193 16 SW3800 int185 Device Name and port WWPN Physical Port IDs int124 HBA A on port 10 10:00:00:00:c9:29:04:8f db1a00 int123 HBA B on port 8 10:00:00:00:c9:30:d0:62 580800 int205 on port 4 10:00:00:00:c9:24:94:43 bf0400 STK L180 on ports 0-4 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 b900ef b90100 b90200 b90301 b90401 Imported Zone Alias Names LSAN Zones
SAN 1 Fabric A
IM16_STK_L180 LSAN_int124_win2k_A_IM 16_STKL180_zone IM16_STK_L180 LSAN_int123_sol_B_IM16_ STKL180_zone IM16_STK_L180 LSAN_int205_sol_A_IM16_ STKL180_zone IM14_int124_w2 kIM15_int123_so lIM8_int205_sol LSAN_STKL180_int123_sol _B_zone LSAN_STKL180_int124_wi n2k_zone LSAN_STKL180_int205_sol _zone
SAN 1 Fabric B
SAN 2
SAN 3
Guideline: Before implementing an LSAN, it is highly recommended to create a similar table as part of the planning process. This vastly simplifies the deployment and aids troubleshooting during the setup. This concludes the Meta SAN Design. Before proceeding to a discussion of LSAN deployment, a section will be devoted to the specific hardware and software used in the Meta SAN Tape Consolidation solution.
2-4
2.4. Detailed Hardware and Software List

As shown in the Figure 2-2 below, the Meta SAN in the Tape Consolidation solution features three SAN Islands. SAN 1 is a dual fabric consisting of SilkWorm 2800, 3800, 3900 and 12000 switches deployed in a core/edge topology. SAN 2 is a single fabric that consists of 2 SilkWorm 2800s as a cascade. SAN 3 is a single SilkWorm 3800. SAN 1 has 6 hosts, 2 of which will be backup servers. Fabric A has a Windows host that will become a Media Server. Fabric B has a Solaris host that will become the Master Server. SAN 2 has a Solaris host that will be used as a second Media Server.
Figure 2-2
Meta SAN Tape Consolidation Logical Connections
Local SAN-based storage exists on each fabric. SAN 1 has a dual attached HDS 9910 and an LSI E-Series RAID (also known as an IBM FastT.) SAN 3 has the STK L180 Tape Library with 4 STK 9840 drives. This tape library will be shared among all three hosts, each of which is sitting on an separate edge fabric. The hosts have Emulex HBAs installed. Some are dual attached. Each edge fabric has a separate zoning configuration that is not merged when connecting to the Silkworm Multiprotocol Router. Table 2-2 below lists the hardware and software used for this solution.
2-5
Table 2-2
Equipment, Drivers and Software Summary
TESTED HARDWARE AND SOFTWARE BACKUP SERVERS

Sun Sunfire 280R (int123) 2 UltraSparc III+ 900 Mhz 2048 MB 2 HBA (2 Gb/sec) Solaris File Server Netbackup Master Server Sun Enterprise E450 (int205) 1 Ulrasparc II 250 Mhz 256 MB 2 HBA (1 Gb/sec) Solaris File Server Netbackup Media Server HP Proliant DL580 (int124) 2 Xeon PIII 750 Mhz, 2048 MB 2 HBA (2 Gb/sec) (LSI RDAC Multipathing) Windows SMB File Server NetBackup Media Server Windows 2000 Emulex LP9002L Patch: SP4FW Ver 3.90a7 Full Port Driver Ver 5.2.20.4 64 bit Solaris 8 Emulex LP8000 Patch: Generic_108528-15 FW Ver 3.82a1 Driver Ver 5.02d 64 bit Solaris 8 Emulex LP9002 Patch: Generic_108528-26 FW Ver 3.90A7 Driver Ver 5.01e
ENTERPRISE SOFTWARE
Veritas NetBackup 4.5 Patch: MP6 Solaris Patch: MP6 Windows
META SAN INFRASTRUCTURE

SAN 1 Dual Fabrics A and B 12 BROCADE Switches Total BROCADE SAN 2 (Single Fabric) BROCADE SAN 3 (Single Fabric) BROCADE Fibre Channel Router 2 SilkWorm 12k chassis (core) 2 SilkWorm 3900 (edge) 4 SilkWorm 3800 (edge) 4 SilkWorm 2800 (edge) 2 SilkWorm 2800 1 SilkWorm 3800 1 SilkWorm Multiprotocol Router (Licensed with FCRS) FOS Version: 4.1.1d FOS Version: 4.1.1d FOS Version: 3.1.1d FOS Version: 2.6.1d FOS Version: 2.6.1d FOS Version: 3.0.2q XPATH OS Ver: Alpha68
STORAGE ENCLOSURES
StorageTek L180 Tape Library (4 drives) Two FC STK 9840B Two FC STK 9840 One FC Robot 9910 (Four 2Gb/sec ports used) MetaStor 27722 FAST T Controllers (4 ports) JMR FORTRA JBOD 15 Seagate ST336605FC Firmware: 4.01.00.03 Management GUI 8.20 Firmware 0002 Library Firmware: 3.01.029840B Drive FW: 1.30.3169840 Drive FW: 1.30.110
HDS LSI
2-6
Chapter
Two steps are required to set up the SilkWorm Multiprotocol Router as an FC Router, and to share devices across the edge fabrics that make up the Meta SAN:
Configure the Fibre Channel Routing Services (FCRS) software. This consists primarily of configuring the EX_Ports on the Multiprotocol Router Define and configure the LSAN import/export members on the edge fabrics. Standard zoning commands are used to accomplish this.
Both of these tasks are relatively straightforward. Before beginning the Fibre Channel Routing Services (FCRS) configuration on the Multiprotocol Router, be sure that the Recovery Kernel and XPATH OS components have been updated to a minimum version of 1.3.0.0 and 7.1.0_ respectively. An overview of the required steps to update the Recovery Kernel (if required) and XPATH OS follows. However, this procedure will not be discussed in detail. Please refer to the XPATH OS Procedures Guide for a detailed discussion on the steps required to perform an upgrade. Caution: For this solution, it is assumed that all member switches of each edge fabric has the PID Format set to 1 (Core). This is not required. The PID format, a fabric wide parameter, may be set to different values for different edge fabrics. Be aware that if this is the case, the -p option may be required for portcfgexport.
3-1
3.1. XPATH OS Upgrade Overview

It may be necessary to first upgrade the Recovery Kernel. An upgrade is required for specific versions of XPATH OS as discussed in the release notes. It is highly recommended to check the Recovery Kernel version to verify that an upgrade is required before attempting it. The first steps to upgrade the Recovery Kernel are to boot into the PMON environment, configure the appropriate network boot and installation configuration parameters, and format the filesystem to which the installation packages will be copied. These parameters are defined with the set command. Note that a TFTP server is required to do the installation. Once the parameters are properly defined, a netload is executed. The new Recovery Kernel firmware will load automatically and the Multiprotocol Router will reboot into the new environment without additional keystrokes. This process takes approximately 5 minutes to complete. At the Recovery Kernel prompt (Recovery Kernel %), the new XPATH Base OS component will be loaded. This package (plus the appropriate license) is all that is required for FCR capability. Typically this code is loaded into Bank 1. Since the XPATH OS Base installation package binary exceeds the TFTP file size limitation, FTP is required. Again, use the set command to setup the required parameters. Once the bank version is set, an FTP session will be opened and the package will download automatically into the defined bank (this takes a couple of minutes.) To install the code, define the set cfgbank parameter to point to the desired bank. After about 10 minutes, the packages will be installed. A reboot is required to finish the process. If required, the XPATH SAS component can be installed in the XPATH OS environment by using the rpgsrvr command. Once installed, the Fibre Channel Routing Services (FCRS) can be configured.
3-2
3.2. Configuring FCRS on the Multiprotocol Router

The steps below show in detail how to define, configure and verify the Multiprotocol Router FCRS setup for the attachment of an edge fabric. This primarily involves defining EX_Ports on the Router. When complete, the edge fabric switch to which the Multiprotocol Router is attached will see an E_port and the Front Domain ID as part of the same physical connection to which the Router has an EX_port defined. Warning: If the ports are not configured to be off with portstop, the Multiprotocol Router will attempt to merge with edge fabrics as an ordinary FC switch. Dual fabric SANs could be merged, resulting in loss or corruption of data. The default setting is subject to change for successive versions of XPATH OS.
3.2.1. FCRS Configuration Overview

This section provides an overview of configuring Fibre Channel Routing Services (FCRS) on the SilkWorm Multiprotocol Router. Figure 3-1 below (Meta SAN Logical Connectivity) displays the Tape Consolidation specific logical edge fabric connections. In short, configuring FCRS is a two-step process:
First establish edge fabric connectivity with the Silkworm Multiprotocol Router. Secondly, establish device sharing through the use of LSANs. Both steps are required to set up a useful Meta SAN.
The first step is to establish edge fabric connectivity. This involves the creation of EX_Ports and Front Domains (FD). Configuring the Multiprotocol Router ports to have EX_Ports is a three-step process: First the port is stopped using portstop, then portcfgexport is executed, and finally the port is restarted. The FD are created automatically and the edge fabric will have a Fabric ID (FID) assigned. The FID identifies a particular fabric as a unique entity for the routing of frames. As part of the automatic configuration, a Front Domain (FD) will be created and presented off of the configured EX_Port to the edge fabric. The FD can be thought of as a virtual switch that will become a local member of an edge fabric. A FD basically acts as a doorway to allow frames to be routed by the Multiprotocol Router from edge fabric to edge fabric. If additional links are required to the same edge fabric, the FID must be specified with the -f command line option. A new FD will be created for each additional link. The edge fabric switch will display an E_Port connected to the FD on the link where the physical cable is connected. The Multiprotocol Router will display the same physical connection as an EX_Port. This type of connection is known as an Inter Fabric Link (IFL). This will become clearer once the example is walked through. If desired, both the FID and the preferred FD can be specified as part of the port configuration with portcfgexport. This material is covered in the first subsection. To share devices across the Meta SAN, LSANs are required. LSANs are essentially zones defined at the edge fabrics for imported and exported devices. When an LSAN is established, an Translate (Xlate) Domain (XD) is created automatically. Proxy devices that represent the physical devices are logically attached to the XD and only one XD is created per edge fabric. Additional LSAN zones on the same edge fabrics will use the SAME XD domain. More on this later. Note that LSAN planning becomes extremely important for larger configurations. Some planning guidelines will be discussed. Actually doing each LSAN configuration step is quite straightforward, because standard zoning commands are used to accomplish the task. Note: Note that LSANs are unlike traditional zoning, where, if no configuration is in effect, all devices are allowed to access each other. If LSANs are not defined, the devices will not see each other.
3-3
The first section, Configuring Multiprotocol Router FCRS for Tape Edge Fabric Connectivity, concentrates on configuring the Multiprotocol Router FCRS using portcfgexport for each of the three SANs. Note that there are a total of 4 fabrics that need to be set up. Detailed steps will be shown for SAN 3, where the STK Tape Library resides. The second subsection will display the remaining steps that allow SAN 1 and SAN 2 to attach to the Multiprotocol Router. In this section, the commands required to configure the Router will be shown, but the output will not be shown in detail. The last subsection will illustrate how to do a final verification that confirms that all three SANs that make up the Meta SAN are attached to the Multiprotocol Router, and that the EX_Ports are properly configured and are ready to pass I/O traffic. A separate section, LSAN Detailed Configuration, will discuss how to set up the LSANs for each edge fabric.
3.2.2. Meta SAN Logical Connectivity

Figure 3-1 shows the logical Meta SAN layout and device location. This diagram will be referred to throughout the remaining discussion.
SAN 1 (FID 14, FID 15)

Fabric A FID 14 Fabric B FID 15
NBU 4.5 Master Server
Media Server
int124 Win
FD 11 FD 10
FD 12
int123 Sun
FD 13
Multiprotocol Router AP7420 as FCR
SAN 2 (FID 13)

Fabric A FID 13
FD 8 FD 9
Media Server
SAN 3 (FID 16)

Fabric A FID 16
FD 15 FD 14 STK L180
int205 Sun
Figure 3-1
Tape Consolidation Meta SAN - Logical Connectivity
3-4
3.3. Configuring Multiprotocol Router FCRS for Tape Edge Fabric Connectivity
The section details the steps to configure the tape edge fabric, otherwise known as SAN 3, which consists of a single SilkWorm 3800, while at a telnet session. Note: Neither Brocade Fabric Manager nor Brocade Web Tools will be used for this discussion.
Follow the following steps for a detailed explanation of setting up and verification of the EX_Port connections. 1. 2. Establish a telnet session on the Silkworm Multiprotocol Router as user admin. Verify the current version of XPath OS using the version (or alternately rpgsrvr) command as illustrated. Note that the output will also show which bank was used for the installation, and the network configuration parameters.
AP7420:admin> version RPG file server Root directory FTP username FTP password Download protocol ================== Installed Packages: =================== Package Name Installed from Installed date Administrative status Primary status Secondary Status Disk usage on root fs -
: : : : :
192.168.162.209 /mars ftpuser ftpuser ftp
: : : : : :
xpath_os_v7.1.0_alpha7_bld68 bank1 Jan 16 18:04 (1) up installed and running Total: 280 Mbytes, Free: 181 Mbytes.
3.
Use licenseshow as illustrated below to verify that the proper licenses are installed on the Multiprotocol Router. No additional licenses are required on the edge fabric switches.
AP7420:admin> licenseshow License Key: SQQRSzSzy9TRRSTy Web License Key: bRcSbRcS9RcSdTcY Zoning License Key: SzzzydRyddb000zF Trunking License Key: SzzzydRyddT800zF FCIP License Key: SzzzydRyddT020z9 Fibre Channel Routing Services License Key: cQeRcyzczcdhfSdx Base switch license Ports on Demand - enable all 16 ports
3-5
Note:
For all 16 ports to be enabled, the Ports on Demand license key is required. To use the Multiprotocol Router as a Fibre Channel Router, the Fibre Channel Routing Services license key must be installed. As with Fabric OS-based Silkworm switches, the licenseadd command is used to do this.
Now that the XPATH OS version and license keys are verified, the Multiprotocol Router can have EX_Ports configured. 4. The first step is to use portstop to offline the Multiprotocol Router FCR ports that are to be connected to the edge fabrics. This will prevent the Router from becoming a member of an attached fabric. The ports can be stopped. This is a very important step. These ports should have been defined ahead of time as part of the planning process. In this particular solution, ports 14 and 15 are used for this purpose. (Stopping a port will take a few moments to complete.)
AP7420:admin> portstop 14 port 14 stopped. AP7420:admin> portstop 15 port 15 stopped. AP7420:admin> or AP7420:admin> portstop 14-15 port 14 stopped. port 15 stopped.
Guideline: Always use portstop BEFORE attaching the fiber cables to the Multiprotocol Router and configuring its ports to be used for FC Routing Services. 5. Configure the ports to be used for Fibre Channel Routing using the portcfgexport command as illustrated below. Once the port is started, an EX_Port will be defined and brought online on the Router. On the attached edge fabric switch, an E_Port will be brought online. To facilitate connectivity, a phantom domain will be presented from the Router EX_Port to the attached edge fabric.
AP7420:admin> portcfgexport 14 -a 1
6.
To bring up the EX_Port, use portstart on the Multiprotocol Router as illustrated below. To verify that the port is online, use switchshow. Note that port 14 in the output below is now configured as an EX_Port with a presented phantom domain. Part of this process defines a Fabric ID (FID). In this case it is16. This number uniquely identifies a fabric to the Fibre Channel Routing Service (FCRS). The Multiprotocol Router keeps a table of the FIDs so it knows where to route traffic. The FID is important to know because it is required to set up additional EX_Port connections to the same fabric. If not used, FCRS will define a new FID by default and the Router will think it is attached to a different fabric. In this solution, port 15 will be used to attach to the same fabric. Note that switchshow does not show the phantom domain number assignment. To see this information, use fabricshow:
3-6
AP7420:admin> portstart 14 port 14 started AP7420:admin> switchshow Switch Name : AP7420 Switch State : Online Switch Type : 38.0 Switch Role : Principal Switch Domain: 100 Switch ID : FFFC64 Switch WWN : 10:00:00:05:1e:13:8b:00 beacon status: OFF zoning : ON (backupcfg) FC router BB Fabric ID: 1 Port Media Speed State Info ======================================= 0 id AN No_Light 1 id AN No_Light 2 id AN No_Light 3 id AN No_Light 4 id AN No_Light 5 id AN No_Light 6 id AN No_Light 7 id AN No_Light 8 id AN No_Light 9 id AN No_Light 10 id AN No_Light 11 id AN No_Light 12 id AN No_Light 13 id AN No_Light 14 id N2 Online 14 id N2 id = 16) 15 id AN No_Light stopped
Online
EX_PORT 10:00:00:60:69:51:0e:44 "int185" (fabric
Note that switchshow does not show the Front Domain Number assignment. To see this information, use the portcfgexport command as shown in step 6 or fabricshow on the edge fabric switch as discussed in step 7. 7. Verify the EX_Port configuration. Be sure the Admin: field is set to enabled as shown. It is important to note the Core PID setting: By default it is set to core. This is equivalent to a setting of 1 on the edge fabric switches. In this case, it is assumed that all edge fabrics have the member switches set to 1 so the setting will not be changed. If required, use the appropriate command line option (use the online Help for details.) The Core PID Formats must match or the FD will not be able to become a member of the edge fabric.
Warning:
Note:
Note the FID is set to 16 and the Front Domain (FD) ID is displayed in decimal as 160. This is a0 in hex and is the first byte in the 24 bit PID. Each FD also has a WWN assigned. In the output below it is 50:00:51:e1:38:b0:0e:0e.
3-7
AP7420:admin> portcfgexport 14 Port 14 info Admin: enabled State: OK Pid format: core Operate mode: native Edge Fabric ID: 16 Front Domain ID: 160 Front WWN: 50:00:51:e1:38:b0:0e:0e Principal Switch: 200 principal WWN: 10:00:00:60:69:c0:06:c3 R_A_TOV: 10000 E_D_TOV: 2000
8.
Verify that the Front Domain is presented properly to the edge fabric and has established itself as a member. To display and verify this information, establish a telnet session on the Fabric OS Silkworm switch in question and execute the fabricshow command. Note that in the solution, the phantom domain appears with a name of fcr_fd_160_14 and has a domain number set to a0 hex (160 decimal).
int185:admin> fabricshow Switch ID Worldwide Name Enet IP Addr FC IP Addr Name ------------------------------------------------------------------------160: fffca0 50:00:51:e1:38:b0:0e:0e 0.0.0.0 0.0.0.0 "fcr_fd_160_14" 200: fffcc8 10:00:00:60:69:c0:06:c3 192.168.173.242 0.0.0.0 >"int185" The Fabric has 2 switches
Note:
Note that, when fabricshow is executed on the Multiprotocol Router, neither the attached switch nor the FD appear as fabric members. This is expected, because the Router has not merged with the edge fabric.
AP7420:admin> fabricshow Switch ID Worldwide Name Enet IP Addr Name --------------------------------------------------------100: fffc64 10:00:00:05:1e:13:8b:00 192.168.163.103 >"AP7420" The Fabric has 1 switches
9.
Repeat steps 4 - 7 using the assigned Fabric ID (FID), which in this case is 16, when defining the new EX_Port on port 15 of the Multiprotocol Router. Note that the port has already been stopped with portstop in step 1. The required options are illustrated below.
AP7420:admin> portcfgexport 15 -a 1 -f 16
The command argument breakdown is as follows:
15 is the port number. The -a 1 administratively enables the port for configuration changes. The -f 16 sets the edge FID to 16, since the port on the Multiprotocol Router is to be attached to the same one-switch fabric.
Warning: When establishing a second link to the same edge fabric, use the -f option or the EX_Port will segment. This requirement may not be necessary in future releases.
3-8
With no arguments, portcfgexport shows the current settings. Note that the Preferred Domain ID is set to 1 by default. This means the FD Domain ID will be set to 1 if no other switches in the fabric have claimed it. This option can be changed using a command line option if desired.
AP7420:admin> portcfgexport 15 Port 15 info Admin: enabled State: NOT OK Pid format: core Operate mode: native Edge Fabric ID: 16 Preferred Domain ID: 1 R_A_TOV: 10000 E_D_TOV: 2000
10. Portstart starts the port with the desired settings as shown above. Note that these can be changed if necessary before the port is started with additional usage of the portcfgexport command.
AP7420:admin> portstart 15 port 15 started
11. Once up and running, portcfgexport is executed again to verify the configuration. Note that the Front Domain WWN is now assigned and the front domain is set to 1.
AP7420:admin> portcfgexport 15 Port 15 info Admin: enabled State: OK Pid format: core Operate mode: native Edge Fabric ID: 16 Front Domain ID: 1 Front WWN: 50:00:51:e1:38:b0:0e:0f Principal Switch: 200 principal WWN: 10:00:00:60:69:c0:06:c3 R_A_TOV: 10000 E_D_TOV: 2000
Warning: If the FID is not set with portcfgexport when attaching another Multiprotocol Router EX_Port to the same edge fabric with a previously set FID, the following error will occur, (when viewed from switchshow) 15 id AN No_Light disabled EX_PORT (Last error: Fabric ID oversubscribed). This is because a new fabric ID has been assigned automatically and the Router assumes the Ex_port is attaching to a new edge fabric. Once this happens, the offending port will be disabled. To fix this condition:. Stop the misconfigured port with portstop, set it with the proper FID with portcfgexport, start using portstart and then finally re-enable it with portenable. The EX_Port now will be online. 12. On the Multiprotocol Router, switchshow should now display the following output. Note that the Fabric ID is 16 for both ports 14 and 15:
3-9
AP7420:admin> switchshow Switch Name : AP7420 Switch State : Online Switch Type : 38.0 Switch Role : Principal Switch Domain: 100 Switch ID : FFFC64 Switch WWN : 10:00:00:05:1e:13:8b:00 beacon status: OFF zoning : ON (backupcfg) FC router BB Fabric ID: 1 Port Media Speed State Info ======================================= 0 id AN No_Light 1 id AN No_Light 2 id AN No_Light 3 id AN No_Light 4 id AN No_Light 5 id AN No_Light 6 id AN No_Light 7 id AN No_Light 8 id AN No_Light 9 id AN No_Light 10 id AN No_Light 11 id AN No_Light 12 id AN No_Light 13 id AN No_Light 14 id N2 Online EX_PORT 10:00:00:60:69:c0:06:c3 "int185" (fabric id = 16) 15 id N2 Online EX_PORT 10:00:00:60:69:c0:06:c3 "int185" (fabric id = 16)
13. On the edge fabric switch (which contains the tape library devices) the following output from switchshow and fabricshow is displayed.
int185:admin> switchshow switchName: int185 switchType: 9.2 switchState: Online switchMode: Native switchRole: Principal switchDomain: 185 switchId: fffcb9 switchWwn: 10:00:00:60:69:51:0e:44 switchBeacon: OFF Zoning: OFF port 0: id N1 Online L-Port 1 public port 1: id N2 Online F-Port 50:01:04:f0:00:47:5a:b4 port 2: id N2 Online F-Port 50:01:04:f0:00:47:1e:18 port 3: id N1 Online L-Port 1 public port 4: id N1 Online L-Port 1 public port 5: id N2 No_Light port 6: id N2 No_Light port 7: id N2 No_Light port 8: id N2 No_Light port 9: id N2 No_Light port 10: id N2 No_Light port 11: id N2 No_Light port 12: id N2 No_Light port 13: id N2 No_Light port 14: id N2 Online E-Port 50:00:51:e1:38:b0:0e:0e "fcr_fd_1_14" (down stream) port 15: id N2 Online E-Port 50:00:51:e1:38:b0:0e:0f "fcr_fd_2_15" (down
3-10

stream) int185:admin> fabricshow Switch ID Worldwide Name Enet IP Addr FC IP Addr Name ------------------------------------------------------------------------1: fffc01 50:00:51:e1:38:b0:0e:0e 0.0.0.0 0.0.0.0 "fcr_fd_1_14" 2: fffc02 50:00:51:e1:38:b0:0e:0f 0.0.0.0 0.0.0.0 "fcr_fd_2_15" 185: fffcb9 10:00:00:60:69:51:0e:44 192.168.162.185 0.0.0.0 >"int185" The Fabric has 3 switches
This completes the attachment of the Backup SAN (defined as SAN 3) to the Multiprotocol Router. The following section will show a summary of the commands used to set up the connections of SAN 1 and SAN 2
3-11
3.4. Configuring FCRS for SAN 1 and SAN 2 on the Multiprotocol Router
Now that the Backup SAN 3 (which consists of a single Silkworm 3800) is attached to the FCR, repeat for each edge fabric. SAN 1 has two fabrics. SAN 2 is a single fabric. The commands to do this are shown below--without the output shown. Fcrfabricshow and fcrrouteshow are used to verify that the EX_Ports are setup properly. Note that when using portcfgexport the -f option is used to set the FID. This prevents the possibility of an FID conflict. The commands to do this are summarized below with limited output.
3.4.1. SAN 1 Configuration Steps

The following steps summarize the setup of edge fabric connectivity for each fabric in SAN 1.
SAN 1 Fabric A AP7420:admin> portstop 10-11 port 10 stopped. port 11 stopped. AP7420:admin> portcfgexport 10 -a 1 -f 14 AP7420:admin> portcfgexport 10 AP7420:admin> portcfgexport 11 -a 1 -f 14 AP7420:admin> portcfgexport 11 AP7420:admin> portstart 10-11 port 10 started port 11 started AP7420:admin> fcrfabricshow AP7420:admin> fcrrouteshow SAN 1 Fabric B AP7420:admin> portstop 12-13 port 12 stopped. port 13 stopped. AP7420:admin> portcfgexport 12 -a 1 -f 15 AP7420:admin> portcfgexport 12 AP7420:admin> portcfgexport 13 -a 1 -f 15 AP7420:admin> portcfgexport 13 AP7420:admin> portstart 12-13 port 14 started port 15 started AP7420:admin> fcrfabricshow AP7420:admin> fcrrouteshow
As before, use switchshow and fabricshow on each of the SAN 1 fabrics to verify that the configuration is correct.
3.4.2. SAN 2 Single Fabric FCRS Configuration Steps

The following steps summarize the setup of edge fabric connectivity for the single fabric in SAN 2. Note that the configuration below has two ports from the Multiprotocol Router connecting to each of two switches on the single edge fabric that makes up SAN 2. Prior to connecting the fiber optic cables, the ports have been disabled on the edge fabric switches. Since the FID identifies a single fabric (and not a switch within the edge fabric), note that the portcfgexport configuration commands as shown are correct.
3-12
AP7420:admin> portstop 8-9 port 8 stopped. port 9 stopped. AP7420:admin> portcfgexport AP7420:admin> portcfgexport AP7420:admin> portcfgexport AP7420:admin> portcfgexport AP7420:admin> portstart 8-9 port 8 started port 9 started AP7420:admin> fcrfabricshow AP7420:admin> fcrrouteshow
8 -a 1 -f 13 8 9 -a 1 -f 13 9
As before, use switchshow and fabricshow to verify that the configuration is correct.
3.4.3. Verifying the FCR Configuration

Once all of the SANs have been added to the configuration, it is important to verify all of the edge fabric connections to the Multiprotocol Router. This is done by executing fcrfabricshow and fcrrouteshow. For this solution, the verified FCRS Meta SAN configuration is shown below.
AP7420:admin> fcrfabricshow FCR WWN: 10:00:00:05:1e:13:8b:00, Dom ID: 100, Info: 192.168.163.103, "AP7420" EX_Port FID Neighbor Switch Info (WWN, enet IP, name) -----------------------------------------------------------------------8 13 10:00:00:60:69:10:92:53, 192.168.162.194, "int194" 9 13 10:00:00:60:69:10:90:05, 192.168.162.193, "int193" 10 14 10:00:00:60:69:80:4d:fc, 192.168.162.63, "int63" 11 14 10:00:00:60:69:80:4d:fc, 192.168.162.63, "int63" 12 15 10:00:00:60:69:80:0f:ad, 192.168.173.166, "poc166" 13 15 10:00:00:60:69:80:0f:ad, 192.168.173.166, "poc166" 14 16 10:00:00:60:69:51:0e:44, 192.168.162.185, "int185" 15 16 10:00:00:60:69:51:0e:44, 192.168.162.185, "int185" AP7420:admin> fcrrouteshow Destination NR_Port FCRP Cost Fabric Id PID
WWN of Principal Switch in the Dest. Fabric ----------------------------------------------------------13 640800 1000 10:00:00:60:69:10:90:05 13 640900 1000 10:00:00:60:69:10:90:05 14 640a00 1000 10:00:00:60:69:80:4d:fc 14 640b00 1000 10:00:00:60:69:80:4d:fc 15 640c00 1000 10:00:00:60:69:80:0f:ad 15 640d00 1000 10:00:00:60:69:80:0f:ad 16 640e00 1000 10:00:00:60:69:51:0e:44 16 640f00 1000 10:00:00:60:69:51:0e:44 AP7420:admin>
Next, create the LSAN configuration as defined in the design plan. LSANs allow device sharing between edge fabrics and are easily defined using familiar Brocade zoning commands.
3-13
3.5. Creating the LSAN Configuration

Now that the EX_Port connectivity has been established on the Brocade SilkWorm Multiprotocol Router, it is time to define the LSAN configuration. LSANs enable the sharing of devices between attached edge fabrics. Unless LSANs are defined, there really is no purpose to establishing the connectivity. As part of the planning process, a table of the devices should have been created. For an example, please refer to the section entitled LSAN Design and Plan on page 2-4.
3.5.1. LSAN Overview

LSANs can best be envisioned as device or node exports from one Meta SAN edge fabric to another. As an example, suppose a host on one edge fabric would like to access a target on a second edge fabric. For the LSAN to be properly set up the host WWPN must be exported as a proxy to the target's fabric and the target WWPN must be exported as a proxy to the host's fabric. Thus an LSAN must be created on EACH edge fabric. During this process a Translate (Xlate) Domain is projected from the Multiprotocol Router to each edge fabric. Proxy or imported devices are logically connected to it, with unique PIDs/ This is because both nodes must see each other in each local fabric to access each other. If a device or node is to be exported to three fabrics within a Meta SAN, as in this solution, then four LSAN configurations must be created, one on each edge fabric. If additional sharing is desired between the same edge fabrics, the existing Xlate Domain is used. In this way, an Xlate Domain can be thought of as a virtual switch that is a member of an edge fabric. Below is an overview of the steps required to set up an LSAN configuration between edge fabrics: 1. 2. Gather the SAN documentation. Note the WWPNs of the devices to be shared across edge fabrics. Domain and port numbers cannot be used when doing the setup. Define the LSAN zones on each edge fabric. Use of the standard zoning commands is all that is required. Create device aliases as normally with alicreate. When using zonecreate, the LSAN_ prefix is required to designate an LSAN zone. Validate that the Xlate domain and exported devices exist within each edge fabric with fabricshow, nsallshow and nscamshow respectively. Check to make sure the LSAN shared device is seen by the host by doing the normal configuration tasks. (This is shown in the following section.)
3. 4.
Device imports and exports are WWPN based. Alias names that reference WWPN names must be used during the LSAN configuration process. It is highly recommended to build the LSAN configuration step by step. Start simply, by validating the sharing of two devices on two edge fabrics and then building out from there. Warning: LSAN zoning configurations must be created using WWPN, generally in edge fabric pairs, to create an LSAN configuration, one for each edge fabric.
3-14
3.5.2. LSAN Detailed Configuration

This solution will illustrate how to share STK tape library devices among three hosts in three separate edge fabrics. Again, the example will use the single SW 3800 switch as a basis for the detailed LSAN configuration steps. Briefly, the procedure is:
Set up an LSAN on SAN 3 An import alias needs to be created for the remote HBA. The SilkWorm 3800 (which is the only switch in SAN 3) has the factory install configuration and thus has no zoning configuration defined or enabled. Define a new local alias for the tape library. These aliases are required to use the WWPN.
Set up an LSAN on SAN 1 The host is on Fabric B of SAN 1. The next step is to define an LSAN configuration on this remote edge fabric. It is remote with respect to SAN 3. On this fabric, a zoning configuration is in place and needs to be modified in two ways. First, add an import alias for the tape library. Again, use the WWPN of each device for this. Second, create a LSAN zone that contains the imported tape library devices alias and the local hosts HBA alias, which must also have the WWPN. This new LSAN zone will be added to the existing zoning configuration.
The commands used to configure the other LSANs on each edge fabric pair will be shown without the detailed output. When complete, XLate domains are projected by the Multiprotocol Router and are made members of the local edge fabrics. These domains, like the Front Domains, are seen locally by fabricshow. To see the LSAN creation process illustrated on each edge fabric, follow the procedure below. Warning: Do not use Domain, Port in the device alias names when establishing an LSAN. This will not work. The reason is that the devices need to be uniquely identified and mapped to virtual devices (called proxy devices) by FCRS. 1. 2. Gather the WWNs and host names from the SAN documentation and establish a telnet session on the Silkworm 3800 as an admin user. An LSAN configuration is created using the standard zoning commands. Follow the steps below to set it up. Note the required syntax of LSAN_ which is all upper case and a single underscore. a. Use alicreate to define a local alias for the STK_L180. Next, create an alias name for the remote host as IM15_int123_Sol_B. The IM15 shows that int123 is imported from FID 15. The B shows that it is on a Fabric B. Be aware that alias names cannot be started with numbers or have hyphens.( Refer to the online Help for details on naming convention rules.)
int185:admin> alicreate "STK_L180","50:01:04:f0:00:41:18:00;50:01:04:f0:00:47:5a:b4;50:01:04:f0:00:47:1e:18;50:01:04:f0:00:42 :90:a9;50:01:04:f0:00:42:90:67" int185:admin> alicreate "IM15_int123_sol_B", "10:00:00:00:c9:30:d0:62"
b.
To designate an LSAN use LSAN_ as the prefix for the zone name as shown. Note the name: The first part is the locally-attached STKL180, which is the device being exported. The second name is the remote imported device that will share it. In this case the convention reads IM15_int123_sol_B, where IM stands for import and 15 is the remote edge fabric FID. The second argument includes the aliases created in the first step. Create the configuration with Backup_cfg as the name. Include the zone defined in the previous step.
int185:admin> zonecreate "LSAN_STKL180_IM15_int123_sol_B_zone","STK_L180;IM15_int123_sol_B"
c.
int185:admin> cfgcreate "Backup_cfg", "LSAN_STKL180_IM15_int123_sol_B_zone"
d.
Save and enable the configuration with cfgsave and cfgenable as shown.
int185:admin> cfgsave
3-15
int185:admin> cfgenable "Backup_cfg" Starting the Commit operation... cfgEnable successfully completed
e.
Display the new enabled configuration with cfgshow as shown.
int185:admin> cfgshow Defined configuration: cfg: Backup_cfg LSAN_STKL180_IM15_int123_sol_B_zone zone: LSAN_STKL180_IM15_int123_sol_B_zone STK_L180; IM15_int123_sol_B alias: STK_L180 50:01:04:f0:00:41:18:00; 50:01:04:f0:00:47:5a:b4; 50:01:04:f0:00:47:1e:18; 50:01:04:f0:00:42:90:a9; 50:01:04:f0:00:42:90:67 alias: IM15_int123_sol_B 10:00:00:00:c9:30:d0:62 Effective configuration: cfg: Backup_cfg zone: LSAN_STKL180_IM15_int123_sol_B_zone 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 10:00:00:00:c9:30:d0:62
3.
Follow the steps below to set up Fabric B of SAN 1. Note the required syntax of LSAN_ which is all upper case and a single underscore. a. Create an alias for the remote imported device. Note that the local device that will be part of the LSAN configuration has an alias name defined as int123_sol_B already. Next, create an alias name for the remote library as IM16_STK_L180. As before, the IM16 refers to the imported STK L180 from FID 16.
poc166:admin> alicreate "IM16_STK_L180", "50:01:04:f0:00:41:18:00; 50:01:04:f0:00:47: 5a:b4; 50:01:04:f0:00:47:1e:18; 50:01:04:f0:00:42:90:a9; 50:01:04:f0:00:42:90:67"
b.
Create the zone using zonecreate and add it to the existing ddm_cfg_b configuration with cfgadd.
poc166:admin> zonecreate "LSAN_STKL180_int123_sol_B_zone", "int123_sol_B;IM16_STK_L180" poc166:admin> cfgadd "ddm_cfg_b", "LSAN_STKL180_int123_sol_B_zone"
c.
Enable the updated configuration with cfgenable.
poc166:admin> cfgenable "ddm_cfg_b" zone config "ddm_cfg_b" is in effect Updating flash ...
d.
Finally display the new configuration with cfgshow. Note that the LSAN_Backup_B zone is now part of the enabled configuration.
poc166:admin> cfgshow Defined configuration: cfg: ddm_cfg_B int121_zone_B; int124_zone_B; int202_zone_B; int200_zone_B; int123_zone_B; int211_zone_B; LSAN_Backup_B zone: LSAN_Backup_B int123_sol_B; IM16_STK_L180 zone: int121_zone_B
3-16

int121_sol_B; LSI_B int123_zone_B int123_sol_B; HDS_2J_Sol_B int124_zone_B int124_w2k_B; LSI_B; JMR1_Disks_int124_win2k_B int200_zone_B int200_hpux_B; LSI_B int202_zone_B int202_hpux_B; HDS_2L_HPUX_B int211_zone_B int211_w2k_B; JMR2_DISKS_int211_w2k_B; HDS_2K_Win_B HDS_2J_Sol_B 50:00:60:e8:02:ee:78:18 HDS_2K_Win_B 50:00:60:e8:02:ee:78:19 HDS_2L_HPUX_B 50:00:60:e8:02:ee:78:1a IM16_STK_L180 50:01:04:f0:00:41:18:00; 50:01:04:f0:00:47:5a:b4; 50:01:04:f0:00:47:1e:18; 50:01:04:f0:00:42:90:a9; 50:01:04:f0:00:42:90:67 JMR1_Disks_int124_win2k_B 21:00:00:20:37:15:1f:d0; 21:00:00:20:37:15:1a:f9; 21:00:00:20:37:15:0a:a5; 21:00:00:20:37:15:0c:0b; 21:00:00:20:37:e6:9a:8c; 21:00:00:20:37:e6:9a:a3 JMR2_DISKS_int211_w2k_B 21:00:00:20:37:e6:31:23; 21:00:00:20:37:42:62:d8; 21:00:00:20:37:e6:35:f1 LSI_B 20:04:00:a0:b8:07:5d:c7 int121_sol_B 10:00:00:00:c9:24:f5:f9 int123_sol_B 10:00:00:00:c9:30:d0:62 int124_w2k_B 10:00:00:00:c9:2b:4f:75 int200_hpux_B 50:06:0b:00:00:0a:65:be int202_hpux_B 50:06:0b:00:00:13:0b:ec int211_w2k_B 10:00:00:00:c9:30:d0:9d
zone: zone: zone: zone: zone: alias: alias: alias: alias:
alias:
alias:
alias: alias: alias: alias: alias: alias: alias:
Effective configuration: cfg: ddm_cfg_B zone: LSAN_Backup_B 10:00:00:00:c9:30:d0:62 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 zone: int121_zone_B 10:00:00:00:c9:24:f5:f9 20:04:00:a0:b8:07:5d:c7 zone: int123_zone_B 10:00:00:00:c9:30:d0:62 50:00:60:e8:02:ee:78:18 zone: int124_zone_B 10:00:00:00:c9:2b:4f:75 20:04:00:a0:b8:07:5d:c7 21:00:00:20:37:15:1f:d0 21:00:00:20:37:15:1a:f9 21:00:00:20:37:15:0a:a5 21:00:00:20:37:15:0c:0b 21:00:00:20:37:e6:9a:8c
3-17

21:00:00:20:37:e6:9a:a3 int200_zone_B 50:06:0b:00:00:0a:65:be 20:04:00:a0:b8:07:5d:c7 int202_zone_B 50:06:0b:00:00:13:0b:ec 50:00:60:e8:02:ee:78:1a int211_zone_B 10:00:00:00:c9:30:d0:9d 21:00:00:20:37:e6:31:23 21:00:00:20:37:42:62:d8 21:00:00:20:37:e6:35:f1 50:00:60:e8:02:ee:78:19
zone:
zone:
zone:
4.
Validate the LSAN configuration. Once again, familiar Fabric OS commands are used on each edge fabric. Optionally, the Multiprotocol Router can be checked with several diagnostic commands (some of these will be shown on the following pages.) Checking the Multiprotocol Router is only required if further troubleshooting is required because LSAN devices are not being seen properly on the edge fabrics. On the tape edge fabric, fabricshow now displays an Xlate domain as fcr_xd_3_15. xd stands for Xlate Domain, 3 is the Domain number assigned to it, and 15 is the Fabric ID of the edge fabric the host( int123 _sol_B) is imported from.
Note:
a.
int185:admin> fabricshow Switch ID Worldwide Name Enet IP Addr FC IP Addr Name ------------------------------------------------------------------------1: fffc01 50:00:51:e1:38:b0:0e:0e 0.0.0.0 0.0.0.0 "fcr_fd_1_14" 2: fffc02 50:00:51:e1:38:b0:0e:0f 0.0.0.0 0.0.0.0 "fcr_fd_2_15" 3: fffc03 50:00:51:e3:13:05:ef:0f 0.0.0.0 0.0.0.0 "fcr_xd_3_15" 185: fffcb9 10:00:00:60:69:51:0e:44 192.168.162.185 0.0.0.0 >"int185" The Fabric has 4 switches
b.
On the host's edge fabric, fabricshow now displays an Xlate domain as fcr_xd_1_16. xd stands for Xlate Domain, 1 is the Domain number assigned to it and 16 the Fabric ID of the edge fabric the tape library (STK_L180) is imported from.
poc166:admin> fabricshow Switch ID Worldwide Name Enet IP Addr FC IP Addr Name ------------------------------------------------------------------------1: fffc01 50:00:51:e3:13:05:df:10 0.0.0.0 0.0.0.0 "fcr_xd_1_16" 2: fffc02 50:00:51:e1:38:b0:0e:0d 0.0.0.0 0.0.0.0 "fcr_fd_2_13" 4: fffc04 50:00:51:e1:38:b0:0e:0c 0.0.0.0 0.0.0.0 "fcr_fd_4_12" 89: fffc59 10:00:00:60:69:51:10:42 192.168.155.89 0.0.0.0 "sialab89" 90: fffc5a 10:00:00:60:69:51:0f:2b 192.168.155.90 0.0.0.0 "sialab90" 166: fffca6 10:00:00:60:69:80:0f:ad 192.168.173.166 0.0.0.0 >"poc166" 195: fffcc3 10:00:00:60:69:10:93:14 192.168.162.195 0.0.0.0 "int195" 196: fffcc4 10:00:00:60:69:10:62:2c 192.168.162.196 0.0.0.0 "int196" 219: fffcdb 10:00:00:60:69:90:04:1a 192.168.162.219 0.0.0.0 "int219" The Fabric has 9 switches
The above steps show that the XLate domains are properly set up. Next, check the host and STK L180 devices on the SilkWorm 3800 with the familiar nsallshow and nscamshow commands on each edge fabric.
3-18
Configuring the Brocade Meta SAN c.
Nsallshow now displays 03f001. This is the PID of the host. The other five entries are the tape library devices. Note that 03 is the XLate domain number while b9 is the local switch domain.
Although not shown, this should be repeated on the other edge fabric.
int185:admin> nsallshow { 03f001 b900ef b90100 b90200 b90301 b90401 6 Nx_Ports in the Fabric }
d.
The output of nscamshow displays the cached name server information. Note that the device is present and has a Port WWN of 10:00:00:00:c9:30:d0:62. This number is equivalent to the edge fabric int123 is physically attached to, as expected. The front domains (1 and 2) have no entries, also as expected. Although not shown, this command should be repeated on the other edge fabric.
int185:admin> nscamshow Switch entry for 1 state rev owner known v410 0xfffcb9 Device list: count 0 No entry is found! Switch entry for 2 state rev owner known v410 0xfffcb9 Device list: count 0 No entry is found! Switch entry for 3 state rev owner known v410 0xfffcb9 Device list: count 1 Type Pid COS PortName NodeName N 03f001; 2,3;10:00:00:00:c9:30:d0:62;20:00:00:00:c9:30:d0:62; FC4s: FCIP FCP IPA: 0x00000000,00000000 Fabric Port Name: 50:00:51:e3:13:05:0a:5b
e.
fcrphydevshow and fcrxlateconfig are two useful commands that can be executed on the Multiprotocol Router. These commands show the physical PID and WWNs that are being projected by the FCR out to the edge fabrics with LSAN configurations in place. Each Xlate Domain, as with a Brocade switch, has an assigned WWN. This is shown with fcrxlateconfig. More extensive information can be shown with fcrdbgdevshow. The output is quite large, even with a single LSAN configuration in place (as displayed below.)
Note:
AP7420:admin> fcrphydevshow Device WWN Physical Exists PID in Fabric ----------------------------------------15 10:00:00:00:c9:30:d0:62 db1a00 16 50:01:04:f0:00:41:18:00 b900ef 16 50:01:04:f0:00:42:90:67 b90401 16 50:01:04:f0:00:42:90:a9 b90301 16 50:01:04:f0:00:47:1e:18 b90200 16 50:01:04:f0:00:47:5a:b4 b90100
3-19
AP7420:admin> fcrxlateconfig EdgeFid RemoteFid Domain 015 016 001 016 015 003
OwnerPid 000000 000000
XlateWWN 50:00:51:e3:13:05:df:10 50:00:51:e3:13:05:ef:0f
This concludes the setup of the LSAN zone on the tape edge fabric with FID 16 (SAN 3) and the host (int123) on the edge fabric with FID 15 (SAN 1 Fabric B). The next subsection will provide a summary of the remaining commands required to create the LSANS on each of the other edge fabrics.
3-20
3.6. LSAN Configuration on SAN 1 Fabric A and SAN 2

Now that the Backup SAN 3 (which consists of a single Silkworm 3800) is configured with the appropriate LSAN to share the tape devices with the remote host, the process needs to be repeated. As before, an LSAN zone needs to be created on each pair of edge fabrics where the devices are to be shared. New Xlate domains will be created, since different edge fabrics are to be used. Verification will be repeated in the same manner through the use of fabricshow, nsallshow and nscamshow. The completed configuration will be displayed on the Multiprotocol Router with the use of fcrxlateconfig and fcrphydevshow. The commands to do this are summarized below with limited output.
3.6.1. SAN 1 Fabric A and SAN 3 LSAN Configuration Steps

These steps summarize the commands used to establish LSAN configurations on SAN 1 Fabric A and SAN 3. On SAN 3 (Backup Fabric with STK L180):
int185:admin> alicreate "IM14_int124_win2k_A", "10:00:00:00:c9:29:04:8f" int185:admin> zonecreate "LSAN_STKL180_int124_win2k_zone", "STK_L180;IM14_int124_win2k_A" int185:admin> cfgadd "Backup_cfg", "LSAN_STKL180_int124_win2k_zone" int185:admin> cfgshow int185:admin> cfgsave int185:admin> cfgenable "Backup_cfg" Starting the Commit operation... cfgEnable successfully completed
On SAN 1 Fabric A:
int217:admin> alicreate "IM16_STK_L180","50:01:04:f0:00:41:18:00;50:01:04:f0:00:47:5a :b4;50:01:04:f0:00:47:1e:18;50:01:04:f0:00:42:90:a9;50:01:04:f0:00:42:90:67" int217:admin> zonecreate "LSAN_int124_win2k_A_IM16_STKL180_zone", "int124_w2k_A;IM16_STK_L180" int217:admin> cfgadd "ddm_cfg_a", "LSAN_int124_win2k_A_IM16_STKL180_zone" int217:admin> cfgshow int217:admin> cfgsave Updating flash ... int217:admin> cfgenable "ddm_cfg_a" zone config "ddm_cfg_a" is in effect Updating flash ...
As before, use fabricshow, nsallshow and nscamshow on each edge fabric to verify that the configuration is correct.
3.6.2. SAN 2 and SAN 3 LSAN Configuration Steps

These steps summarize the commands used to establish LSAN configurations on SAN 2 and SAN 3. On SAN 3 (Backup Fabric with STK L180):
int185:admin> alicreate "IM8_int205_sol", "10:00:00:00:c9:24:94:43" int185:admin> zonecreate "LSAN_STKL180_int205_sol_zone", "STK_L180;IM8_int205_sol" int185:admin> cfgadd "Backup_cfg", "LSAN_STKL180_int205_sol_zone" int185:admin> cfgshow int185:admin> cfgsave int185:admin> cfgenable "Backup_cfg" Starting the Commit operation...
3-21
cfgEnable successfully completed
On SAN 2 (Single Fabric):

int191:admin> alicreate "IM16_STK_L180","50:01:04:f0:00:41:18:00;50:01:04:f0:00: 47:5a:b4;50:01:04:f0:00:47:1e:18" int191:admin> aliadd "IM16_STK_L180", "50:01:04:f0:00:42:90:a9;50:01:04:f0:00:42:90:67" int191:admin> zonecreate "LSAN_int205_sol_A_IM16_STKL180_zone", "int205_sol_A;IM16_STK_L180" int191:admin> cfgcreate "Backup_cfg", "LSAN_int205_sol_A_IM16_STKL180_zone" int191:admin> cfgshow int191:admin> cfgsave Updating flash ... int191:admin> cfgenable "Backup_cfg" zone config "Backup_cfg" is in effect Updating flash ...
fabricshow displays both Front Domains and the newly created Xlate Domain.
int191:admin> fabricshow Switch ID Worldwide Name Enet IP Addr FC IP Addr Name ------------------------------------------------------------------------1: fffc01 50:00:51:e1:38:b0:0e:07 0.0.0.0 0.0.0.0 "fcr_fd_1_7" 2: fffc02 50:00:51:e3:13:05:6f:10 0.0.0.0 0.0.0.0 "fcr_xd_2_16" 160: fffca0 50:00:51:e1:38:b0:0e:06 0.0.0.0 0.0.0.0 "fcr_fd_160_6" 191: fffcbf 10:00:00:60:69:10:93:0d 192.168.162.191 0.0.0.0 "int191" 192: fffcc0 10:00:00:60:69:10:52:1d 192.168.162.192 0.0.0.0 >"int192" The Fabric has 5 switches
As before, use fabricshow, nsallshow and nscamshow on each edge fabric to verify that the configuration is correct. Now that the LSAN zones have been established on all edge fabrics, the next step is to verify the entire Meta SAN configuration is properly configured.
3.6.3. Verifying the Completed Meta SAN LSAN Configuration

Once all of the LSANs have been added to the configuration, it is important to verify all of the edge fabric connections to the Multiprotocol Router. This is done by executing fcrphydevshow, fcrxlateconfig, fcrproxydevshow, and lsanzoneshow. For this solution, the Meta SAN LSAN commands generate the output as shown below. 1. In this solution, fcrphydevshow shows what physical devices are being shared in the Meta SAN. In the solution example, the physical STK L180 and HBA devices are shown. Note that each HBA is in a separate edge fabric.
AP7420:admin> fcrphydevshow Device WWN Physical Exists PID in Fabric ----------------------------------------8 10:00:00:00:c9:24:94:43 bf0400 14 10:00:00:00:c9:29:04:8f 580800 15 10:00:00:00:c9:30:d0:62 db1a00 16 50:01:04:f0:00:41:18:00 b900ef 16 50:01:04:f0:00:42:90:67 b90401 16 50:01:04:f0:00:42:90:a9 b90301 16 50:01:04:f0:00:47:1e:18 b90200 16 50:01:04:f0:00:47:5a:b4 b90100
3-22
2.
fcrxlateconfig displays the Xlate domains being projected from the Multiprotocol Router. The assigned domain numbers are located under the Domain column and the WWNs under the XLate WWN column. There should be six (three on the tape edge fabric and one each on fabric A and B of SAN 1 and the fabric that is part of SAN 2). The output shows this is, as expected.
AP7420:admin> fcrxlateconfig EdgeFid RemoteFid Domain 008 016 002 014 016 002 015 016 001 016 008 005 016 014 004 016 015 003 OwnerPid 000000 000000 000000 000000 000000 000000 XlateWWN 50:00:51:e3:13:05:6f:10 50:00:51:e3:13:05:bf:10 50:00:51:e3:13:05:df:10 50:00:51:e3:13:05:ef:08 50:00:51:e3:13:05:ef:0e 50:00:51:e3:13:05:ef:0f
3.
fcrproxydevshow shows the virtual projected devices that are logically attached to the Xlate domains, and related information. The Proxy PID column shows the virtual PID of each projected device. The Physical PID column shows the real PID of the device. The most important column is the State column. All states should say Imported, as shown.
AP7420:admin> fcrproxydevshow Proxy WWN Proxy Device Physical State Created PID Exists PID in Fabric in Fabric ---------------------------------------------------------------------------8 50:01:04:f0:00:41:18:00 02f001 16 b900ef Imported 8 50:01:04:f0:00:42:90:67 02f005 16 b90401 Imported 8 50:01:04:f0:00:42:90:a9 02f004 16 b90301 Imported 8 50:01:04:f0:00:47:1e:18 02f003 16 b90200 Imported 8 50:01:04:f0:00:47:5a:b4 02f002 16 b90100 Imported 14 50:01:04:f0:00:41:18:00 02f001 16 b900ef Imported 14 50:01:04:f0:00:42:90:67 02f005 16 b90401 Imported 14 50:01:04:f0:00:42:90:a9 02f004 16 b90301 Imported 14 50:01:04:f0:00:47:1e:18 02f003 16 b90200 Imported 14 50:01:04:f0:00:47:5a:b4 02f002 16 b90100 Imported 15 50:01:04:f0:00:41:18:00 01f001 16 b900ef Imported 15 50:01:04:f0:00:42:90:67 01f005 16 b90401 Imported 15 50:01:04:f0:00:42:90:a9 01f004 16 b90301 Imported 15 50:01:04:f0:00:47:1e:18 01f003 16 b90200 Imported 15 50:01:04:f0:00:47:5a:b4 01f002 16 b90100 Imported 16 10:00:00:00:c9:24:94:43 05f001 8 bf0400 Imported 16 10:00:00:00:c9:29:04:8f 04f001 14 580800 Imported 16 10:00:00:00:c9:30:d0:62 03f001 15 db1a00 Imported
4.
lsanzoneshow displays a summary of the configured LSAN zones. This command is useful to validate the LSAN definitions from a central location, a much preferable alternative to gathering the zoning information from each Router-attached edge fabric and separately filtering out the local and LSAN zones. Note that the output shows there are six LSAN zones configured.
AP7420:admin> lsanzoneshow Fabric ID: 8 Zone Name: LSAN_int205_sol_A_IM16_STKL180_zone 10:00:00:00:c9:24:94:43 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 Fabric ID: 14 Zone Name: LSAN_int124_win2k_A_IM16_STKL180_zone 10:00:00:00:c9:29:04:8f 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9
3-23
50:01:04:f0:00:42:90:67 Fabric ID: 15 Zone Name: LSAN_int123_sol_B_IM16_STKL180_zone 10:00:00:00:c9:30:d0:62 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 Fabric ID: 16 Zone Name: LSAN_STKL180_int123_sol_B_zone 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 10:00:00:00:c9:30:d0:62 Fabric ID: 16 Zone Name: LSAN_STKL180_int124_win2k_zone 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 10:00:00:00:c9:29:04:8f Fabric ID: 16 Zone Name: LSAN_STKL180_int205_sol_zone 50:01:04:f0:00:41:18:00 50:01:04:f0:00:47:5a:b4 50:01:04:f0:00:47:1e:18 50:01:04:f0:00:42:90:a9 50:01:04:f0:00:42:90:67 10:00:00:00:c9:24:94:43
Once verified, the next step is to prepare the host OS for device discovery and install and configure NetBackup DataCenter. The focus will be on guidelines and gotchas while staging the application software. For full instructions, please refer to the NetBackup Installation and Administrator Guides.
3-24
Chapter
Now that the Meta SAN has been established and the devices shared, this section will summarize the steps required to install Veritas NetBackup on the Solaris and Windows hosts. Before the installation can be started, preliminary configuration of the host HBA drivers must be performed. Once complete, the OS will have access to the STK tape library devices. An overview of this process follows in Sections 4.1 and 4.2. Note that the OS will not need to control the robot: NetBackup will provide the necessary drivers for its configuration. Before installing NetBackup, it is helpful to create a table listing the various roles each host will perform. This greatly facilitates the planning process before the software is installed. Table 4-1 shows the hosts, Edge Fabric IDs, and LSAN zones, as well as the NetBackup roles used in the solution. Table 4-1 Edge FID 15 13 14 Solution Guide NetBackup Host Names and Roles LSAN Zone LSAN_int123_sol_B_IM16_STKL 180_zone LSAN_int205_sol_A_IM16_STKL 180_zone LSAN_int124_win2k_A_IM16_ST KL180_zone Host Platform Sun Solaris 8 Sun Solaris 8 Microsoft Windows 2000 Server Hostname int123 int205 int124 Role Master Server Media Server Media Server Notes Robot Control Host
Note:
Since the hosts are still in a SAN environment, the drives will be configured with SSO. This is done automatically for each Media Server (after the Master Server is set up) for each host sharing the Tape Library.
4-1
4.1. Preparing the Sun Solaris Hosts

As mentioned above, before installing NetBackup, the Sun Solaris hosts need to recognize the STK tape library devices. The procedure below provides a general overview of what to do and how to validate that the OS and the Emulex HBA driver are properly set up. Please refer to the Emulex documentation set and readme notes and the relevant Sun Solaris System Administration guides for detailed explanation and any additional options a specific installation may require. 1. Install the Emulex HBA driver and associated utilities. Manually assign persistent bound tape library targets to 0, 1, 2, 3, 4 using the element order determined earlier, using the Emulex lputil utility in /usr/sbin. Be sure this is consistent with all other hosts participating as part of the backup configuration. When complete, lputil will display the following output:
# /usr/sbin/lpfc/lputil LightPulse Common Utility for Solaris/SPARC. Version 1.5a0 (12/18/2002). Copyright (c) 2002, Emulex Network Systems, Inc. Emulex Fibre Channel Host Adapters Detected: 2 Host Adapter 0 (lpfc0) is an LP9K (Ready Mode) Host Adapter 1 (lpfc1) is an LP9K (Ready Mode) Persistent Bindings: 1. Adapter: 1, Target: 2. Adapter: 1, Target: 3. Adapter: 1, Target: 4. Adapter: 1, Target: 5. Adapter: 1, Target: 6. Adapter: 1, Target:
5, 0, 1, 2, 3, 4,
WWPN: WWPN: WWPN: WWPN: WWPN: WWPN:
50-00-60-e8-02-ee-78-18 50-01-04-f0-00-41-18-00 50-01-04-f0-00-47-5a-b4 50-01-04-f0-00-47-1e-18 50-01-04-f0-00-42-90-67 50-01-04-f0-00-42-90-a9
2.
Edit st.conf in /kernel/drv to open up HBA target and LUN space for the now persistently bound devices. After being edited, the end of st.conf should look like the following.
# tail /kernel/drv/st.conf #name="st" class="scsi" # target=15 lun=0; # This line adds support for Fibre Channel Tapes name="st" parent="fp" target=0; name="st" parent="fp" target=1; name="st" parent="fp" target=2; name="st" parent="fp" target=3; name="st" parent="fp" target=4; #
Note:
Since STK 9840 drives are being used in this example, it is not necessary to configure the tape-config-list drive device attributes.
3.
Clean out any old HBA and other Solaris device entries with devfsadm -Cv. Devices to be deleted appear while devfsadm is executed. If no devices are displayed, old unused entries do not exist.
int123# devfsadm -Cv devfsadm[1232]: verbose: devfsadm[1232]: verbose: devfsadm[1232]: verbose: devfsadm[1232]: verbose: removing removing removing removing file: file: file: file: /devices/pci@8,600000/lpfc@1/sd@0,0:a /dev/dsk/c4t0d0s0 /devices/pci@8,600000/lpfc@1/sd@0,0:b /dev/dsk/c4t0d0s1
4.
Do a reconfigure reboot. This is required for the HBA tape device discovery and persistent binding assignment to take effect.
int123# reboot -- -r
4-2
5.
Validate the configuration. The best way is to check the message log file in /var/adm as shown. Console port output is also helpful. All the tape devices should now appear. Sample partial output appears below:
int123# cat /var/adm/messages Jan 21 23:13:09 int123 genunix: [ID 936769 kern.info] sd6 is /pci@8,700000/scsi@6/sd@6,0 Jan 21 23:13:12 int123 lpfc: [ID 685918 kern.notice] NOTICE: lpfc0: Acquired FCP/SCSI Target 0 LUN 1 Jan 21 23:13:12 int123 D_ID 0xd90d00 WWPN:50:00:60:e8:02:ee:78:08 WWNN:50:00:60:e8:02:ee:78:08 Jan 21 23:13:12 int123 lpfc: [ID 685918 kern.notice] NOTICE: lpfc0: Acquired FCP/SCSI Target 0 LUN 2 Jan 21 23:13:12 int123 D_ID 0xd90d00 WWPN:50:00:60:e8:02:ee:78:08 WWNN:50:00:60:e8:02:ee:78:08 Jan 21 23:13:12 int123 lpfc: [ID 685918 kern.notice] NOTICE: lpfc0: Acquired FCP/SCSI Target 0 LUN 3 Jan 21 23:13:12 int123 D_ID 0xd90d00 WWPN:50:00:60:e8:02:ee:78:08 WWNN:50:00:60:e8:02:ee:78:08
6.
As a final validation, use the mt command to check the tape drive discovery status.
int123# mt -f /dev/rmt/0cbn stat
The following shows sample messages that will be logged in /var/adm/messages.

int123# tail -f Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 Jan 22 16:29:33 /var/adm/messages int123 scsi: [ID 365881 kern.info] /pci@8,600000/lpfc@1/st@1,0 (st22): int123 <StorageTek 9840B> int123 scsi: [ID 193665 kern.info] st22 at lpfc1: target 1 lun 0 int123 genunix: [ID 936769 kern.info] st22 is /pci@8,600000/lpfc@1/st@1,0 int123 scsi: [ID 365881 kern.info] /pci@8,600000/lpfc@1/st@2,0 (st23): int123 <StorageTek 9840B> int123 scsi: [ID 193665 kern.info] st23 at lpfc1: target 2 lun 0 int123 genunix: [ID 936769 kern.info] st23 is /pci@8,600000/lpfc@1/st@2,0 int123 scsi: [ID 365881 kern.info] /pci@8,600000/lpfc@1/st@3,0 (st24): int123 <StorageTek 9840> int123 scsi: [ID 193665 kern.info] st24 at lpfc1: target 3 lun 0 int123 genunix: [ID 936769 kern.info] st24 is /pci@8,600000/lpfc@1/st@3,0 int123 scsi: [ID 365881 kern.info] /pci@8,600000/lpfc@1/st@4,0 (st25): int123 <StorageTek 9840> int123 scsi: [ID 193665 kern.info] st25 at lpfc1: target 4 lun 0 int123 genunix: [ID 936769 kern.info] st25 is /pci@8,600000/lpfc@1/st@4,0
7.
Go to /dev/rmt and verify the tape devices are created. They should appear as shown in the partial output indicated below:
int123# cd /dev/rmt int123# ls 0 0hb 0mb 1 0b 0hbn 0mbn 1b 0bn 0hn 0mn 1bn
1hb 1hbn 1hn
1mb 1mbn 1mn
2 2b 2bn
2hb 2hbn 2hn
2mb 2mbn 2mn
3 3b 3bn
3hb 3hbn 3hn
3mb 3mbn 3mn
8.
Repeat for int205, which will become a Solaris Media Server.
This completes the preparation of the Solaris hosts. The next section will briefly describe the steps for installing NetBackup on int123 (the Master Server and will discuss the differences in setting up int205 as a Media Server.
4-3
4.2. Installing NetBackup 4.5 on Solaris

This subsection is a summary of relevant steps for executing a NetBackup installation on int123(the Solaris-based Master Server.) Only a slight alteration is required for installing a Media Server on int205. These differences will be discussed briefly. As with the other sections, only some of the steps will be illustrated. NetBackup is a complex application and has several options and agents. Please refer to the NetBackup DataCenter Installation Guide for UNIX for detailed instructions on the procedure and installation options. Refer also to the NetBackup SAN Administrators Guide for the NetBackup Shared Storage Option (SSO) and other SAN-related configuration steps. To install NetBackup, the following steps should be performed in the order shown. (Refer to the planning table, Table 4-1.)
int123 (Master Server) Verify that the int123 OS can see the tape library robot and drives. Install and configure NetBackup as the Master Backup Server. Then install the NetBackup application patch cluster as required. If required, configure the SG driver target and LUN parameters. Set up a NetBackup Policy to do a test backup, in order to verify the installation.
int205 (Media Server) Once NetBackup is installed on the Master Server, verify that int205 can see the tape library robot and drives. Install NetBackup and configure as a Media Server. Install the NetBackup application patch cluster. Configure the SG driver target and LUN parameters.
Note:
Although not completed in this solution, as an optional step, the NetBackup Client software can be distributed to the other hosts using the remote install GUI.
Guideline: For true LAN-Free backups, a Media Server must be installed on each host. This keeps all data traffic off of the LAN. Installing as a client is acceptable, but because it doesnt have access to the tape device through the SAN (the Media Server does) part of the data traffic will be LAN based.
4-4
4.2.1. Installing NetBackup DataCenter GA on the UNIX Hosts

This section summarizes the installation steps used in this Brocade Solution Guide. For further information; see the Veritas NetBackup DataCenter Installation Guide for Unix (Solaris Systems). 1. To install the Master and Media Servers, use the Veritas 4.5 UNIX Server Platform CD media. The first host to be installed will be the Master Server (int123). Open a terminal window. As root, navigate to the CD mount point and run the installation script. Follow the automated question and answer session. During the installation, the SG Driver will be installed and configured automatically. This is the driver NetBackup uses for accessing the tape devices, including any robotic element. A trace of the install can be found in /tmp. Use this to verify the installation. To check the configuration of the SG Driver (which was done automatically during the NetBackup installation), execute sgscan (found in /opt/openv/volmgr/bin.) If not correct, the driver will have to be rebuilt after adjusting the target/LUN space. Note that the output shows the STK L180 robot and 4 tape drives as expected. int123# cd /opt/openv/volmgr/bin
int123# ./sgscan /dev/sg/c0t6l0: Cdrom: "TOSHIBA DVD-ROM SD-M1401" /dev/sg/c2t0l0: Disk (/dev/rdsk/c3t0d0): "HITACHI OPEN-E /dev/sg/c2t0l1: Disk (???): "HITACHI OPEN-E -SUN" /dev/sg/c3t0l0: Changer: "STK L180" /dev/sg/c3t1l0: Tape (/dev/rmt/0): "STK T9840B" /dev/sg/c3t2l0: Tape (/dev/rmt/1): "STK T9840B" /dev/sg/c3t3l0: Tape (/dev/rmt/2): "STK 9840" /dev/sg/c3t4l0: Tape (/dev/rmt/3): "STK 9840" /dev/sg/c3t5l0: Disk (/dev/rdsk/c4t5d0): "HITACHI OPEN-E /dev/sg/c3t5l1: Disk (???): "HITACHI OPEN-E -SUN"
2.
3.
-SUN"
-SUN"
Guideline: Make sure that the target numbers are consistent for each tape library device and Element Address on each host. To track this, it is helpful to build a table that shows the tape library device number as referenced by the library, WWPN, Target/LUN, and Element Address. This ends the installation of NetBackup on int123, the Master Server. The next step is to install the patch files to update NetBackup to Maintenance Patch 6 (MP6).
4-5
4.2.2. Installing Veritas NetBackup MP6 Patch on Solaris

This section provides a brief summary of the patch installation. On Solaris this entails removing the currently installed package and removing the start and kill scripts from the rc directories. The patch size is rather large--around 550MB. For detailed instructions, refer to Section 3 entitled Performing an Upgrade Installation of the Veritas NetBackup Installation guide for UNIX. A summary and guidelines follow. 1. To install the NetBackup patch cluster, first download it from the Veritas web site. Use the UNIX uncompress and tar utility to extract the patch files.
Warning: Note that the downloaded file may end in .z. For uncompress to work properly, the file needs to be renamed so that it ends in .Z. 2. Once stopped, use pkgrm to remove the old version. As noted in Veritass instructions, this step is for Solaris hosts only. Be sure to answer y to the question Is this part of an upgrade? Unlike the older versions, only one package is installed and thus is the only one that needs removal.
Guideline: Making the removal part of an upgrade as suggested in the Veritas Installation Guide preserves the licenses and other configuration changes. 3. Run the installation script once again, to install the patches. This takes some time, because it is almost a complete re-installation of the product. This ends the patch installation on the int 123, the Master Server.
Guideline: It is highly recommended to run a test backup on the Master Server at this point. This entails walking through the Getting Started Wizard when NetBackup is first launched.
4-6
4.2.3. Installing the Solaris Media Server

To install int205 as a Media Server, the steps are nearly identical to those above: Install NetBackup and the patch cluster; verify access to the library drives; finally, reconfigure the SG driver if necessary. The only difference is to configure the software installation on int205 as a Media Server, using int123 as the Master Server.
4.2.4. OPTIONAL: Configuring the SG Driver

When deploying Veritas NetBackup in a SAN environment, sometimes the pre-built SG driver is insufficiently configured for the right numbers of target and LUN space. When this happens, it must be reconfigured and rebuilt. Before configuring the SG driver, check /dev/rmt to make sure all tape devices are seen by the host. In this case, there should be 4 devices listed. The output should be similar to the following:
int123# ls /dev/rmt 0 0hb 0mb 1 1hb 1mb 2 2hb 2mb 3 3hb 3mb
To use NetBackup, all tape devices must be available to the SG driver. This driver is installed and configured during the NetBackup installation automatically. Usually, the default settings do not provide the proper configuration for a SAN environment. To check the SG driver configuration, run the sgscan utility. This provides a check of the available tape devices. (The output for this utility is shown below.) The SG driver should see the STK robot and four STK tape drives. Note that the SG driver will also detect the internal drives and any LUNs presented by a RAID array such as the HDS 9910.
int123 >cd /opt/openv/volmgr/bin int123 >./sgscan /dev/sg/c0t0l0: Disk (/dev/rdsk/c0t0d0): "SEAGATE /dev/sg/c0t6l0: Cdrom: "TOSHIBA DVD-ROM SD-M1401" /dev/sg/c2t0l0: Disk (/dev/rdsk/c2t0d0): "HITACHI /dev/sg/c2t0l1: Disk (/dev/rdsk/c2t0d1): "HITACHI /dev/sg/c3t0l1: Changer: "STK L180" /dev/sg/c3t1l0: Disk (/dev/rdsk/c3t1d0): "HITACHI /dev/sg/c3t1l1: Disk (/dev/rdsk/c3t1d1): "HITACHI
ST318404LSUN18G" OPEN-9 -SUN" OPEN-9 -SUN" OPEN-9 -SUN" OPEN-9 -SUN"
Note:
The Master Server sees only a STK L180 robot and no drives. The driver must be rebuilt and relinked.
To rebuild the SG driver, follow the steps below. 1. As root, navigate to the /opt/openv/volmgr/bin/driver directory where the SG configuration files are located.A partial listing of the sg.conf.all file--which includes all of the available targets and LUNs--is shown below. This file and sg.links.all will be edited to reflect the current SAN environment.
int123 >cat sg.conf.all # Configuration file for SCSA Generic. # name="sg" class="scsi" target=0 lun=0; name="sg" class="scsi" target=0 lun=1; name="sg" class="scsi" target=0 lun=2; name="sg" class="scsi" target=15 lun=7;
2.
Use the sg.conf.all and sg.links.all configuration files as a baseline for the edits. Copy the sg.conf and sg.link files to preserve the originals.
int123 int123 int123 int123 >cp >cp >cp >cp sg.conf sg.conf_org sg.conf.all sg.conf sg.links sg.links_org sg.links.all sg.links
4-7
4
3.
Next, edit the new sg.conf and sg.links so that there is only 0,1,2,3 for target numbers, and 0-7 for the LUNs. This entails deleting some lines and is not shown.
Although all of the tape targets and LUNs will not be used at this time, having extra ones set up is convenient. Doing this prevents editing the configuration files and rebuilding the SG driver and links. As an example, additional drives may be added to the STK L180 without further modification to the SG driver. Be aware that extra room for target/LUNs in st.conf is also a requirement. Guideline: Consider adding in extra target/LUN space when configuring the SG driver. Target and LUN space must also be available in st.conf. This will save time by preventing a driver rebuild later. Once the driver parameters are set, now update the driver. In order to this, several steps are required. 1. 2. Remove the old sg.conf in /kernel/drv. If the old file is not removed, the driver cannot be updated.
int123 >rm /kernel/drv/sg.conf
Run the sg.install script to install and add the links automatically.
int123 >./sg.install Copied files to /kernel/drv and to /kernel/drv/sparcv9. Doing add_drv of the sg driver Removing old /dev/sg entries. Editing /etc/devlink.tab... Copying original /etc/devlink.tab to /etc/devlink.tab.09-25-01-09:32:46. Added entry in /etc/devlink.tab file. Made links in /dev/sg
3.
Once built, verify that all tape drives and the robot can be seen by the SG driver using sgscan. This takes a few moments to complete. Once finished, the output should look similar to the sample below:
int123 >cd /opt/openv/volmgr/bin int123# ./sgscan /dev/sg/c0t6l0: Cdrom: "TOSHIBA DVD-ROM SD-M1401" /dev/sg/c2t0l0: Disk (/dev/rdsk/c3t0d0): "HITACHI OPEN-E /dev/sg/c2t0l1: Disk (???): "HITACHI OPEN-E -SUN" /dev/sg/c3t0l0: Changer: "STK L180" /dev/sg/c3t1l0: Tape (/dev/rmt/0): "STK T9840B" /dev/sg/c3t2l0: Tape (/dev/rmt/1): "STK T9840B" /dev/sg/c3t3l0: Tape (/dev/rmt/2): "STK 9840" /dev/sg/c3t4l0: Tape (/dev/rmt/3): "STK 9840" /dev/sg/c3t5l0: Disk (/dev/rdsk/c4t5d0): "HITACHI OPEN-E /dev/sg/c3t5l1: Disk (???): "HITACHI OPEN-E -SUN"
-SUN"
-SUN"
Note:
As shown above, the STK L180 library can now be seen with all of the drives and the robotic arm as displayed by the Changer: entry.
This completes the configuration of the SG driver on the Master Server, int123. This entire section may need to be repeated on other Solaris hosts.
4-8
4.3. Preparing the Windows Host

This section provides a high-level overview for configuring the Windows host to access the STK L180 tape library imported to the hosts local edge fabric, in preparation for the installation of NetBackup. These steps should be completed before the NetBackup installation begins. A few screen shots will help to illustrate the configuration settings, and will also show the final correct setup. For details on the installation and setup of the Emulex HBA, please refer to the Emulex-supplied documentation and readme files. Further assistance can be found on the Emulex website. For details on the installation and setup of the STK L180 please refer to the supplied documentation or contact the vendor it was purchased from. Although the STK library is physically located on a remote edge fabric, the Windows host will see it as directly connected. The fabric the HBA is attached to will see the tape library as if it was locally attached by its virtual proxy PID. It will appear as though it was physically attached to Xlate domain. 1. Install the Emulex Full Port driver. Choose Fabric - Automap SCSI devices for the driver type. As of this writing, two separate software packages are required. Install the driver package first. Once it is up and running, install the utility package, which contains HBAnywhere and other Emulex-supplied tools. The driver package must be installed before the HBA utility package.
Note: 2.
By default the Full Port driver will not be configured to properly discover the remote tape library devices. Unfortunately, this behavior is different from Solaris, where no adjustment is required and the tape devices are discovered immediately after a reconfigure reboot. To configure the Windows Full Port driver properly, select the Use Name Server after RSCN check box. Save the settings and exit. After a reboot, the Emulex Configuration Tool Window appears as shown below. Note that the Mapped SCSI ID column shows all devices as (Present). This indicates that the discovery process has occurred properly.
Figure 4-1
4-9
Warning: If the Use Name Server after RSCN box is not checked, the tape library devices will not be discovered. From a portlogdump analysis, it was noted that the HBA was finished with the disocovery process before the tape library devices appeared on the local fabric. By default, the HBA recieves the ensuing RSCN but no action is taken. Selection of the Use Name Server after RSCN has the HBA request re-read the Brocade Name Server. At this time, the tape library is present. In future releases, this setting may no longer be required. After the reboot, some manual adjustment of the WWN to Mapped SCSI ID (target) mapping is almost always required. This is critical to proper NetBackup operation, because it uses element addresses to establish the device order. (If the default mapping is used, NetBackup will almost always become confused.) This order is determined from the element addresses on the tape library itself, and is what establishes which tape drive is known internally as drive 0, 1, 2 etc. If lessened, this information can be obtained from a web browser. If not, it can be gathered from the front panel. As a best practice, the STK robot should be first in the list with target 0 and the STK L180 tape library device order consistent by element address among ALL hosts participating as part of the backup configuration. In the example, the WWN ending in 1800 is the STK L180 robot. Guideline: All tape libraries should have the devices ordered consistently by use of element address on all backup servers. This is achieved by the proper mapping of the tape library devices. It is highly recommended to have the robot configured as target 0. This rule of thumb holds true for almost all tape libraries with Veritas in a SAN environment. 3. Install the STK tape device drivers by following the instructions provided by STK. These drivers can be found on the StorageTek website. This may take some time.
Warning: As of this writing, the installation of tape driver version 6.1.0.0 takes an extended period of time to complete--5 minutes or more--and may hang on the final screen. When testing on a local fabric, this behavior is not repeated. This shows that it is likely a Multiprotocol Router issue. A temporary workaround is to kill the Computer Management process with Task Manager while at the final screen. Since each drive's driver must be installed separately, more than one reboot may be required. Eventually, Windows will install and start the appropriate drivers normally. Further testing has shown that the driver installation is stable among successive reboots. Brocade is in the process of testing tape devices and thus this behavior should improve with later XPATH OS builds. 4. Once complete, the drivers should be seen in the Computer Management window. The STK Library used in this solution has both 9840A and 9840B drives. Unlike older versions, the same driver is now used for both. NetBackup will provide the driver for the Medium Changer, so no further action is required to install the driver.
Note:
The Windows host, int124, is now prepared for the installation of NetBackup as a Media Server.
4-10
4.4. Installing NetBackup 4.5 on Windows 2000

This section will provide an overview of the installation of the NetBackup Media Server on the Windows host, int124. Included will be a discussion of MP6 patch installation. For details, refer to the NetBackup Windows Installation Guide. Other crucial configuration steps, such as defining backup policies and storage units in preparation of doing actual backups, will be summarized later. For those details, please refer to the online Help and/or NetBackup 4.5 Administration Guide for Windows. The Veritas website also provides good assistance. 1. 2. Choose Server Installation. Some initial configuration is performed once acknowledged on the NetBackup Setup dialog box that appears. Enter the license key and select NetBackup Media Server. After a few steps, the Setup Type window appears. For this solution, a Typical setup was chosen. When the Completing the NetBackup Setup Wizard window appears, note the following: By default, the NetBackup Administration Console will appear. When launched, an Error message appears. Ignore this for now, as the new Media Server needs to be added to the approved Server list on the Master Server. This is required for int124 to be authorized to administer the Master Server.
Note:
This completes the installation of NetBackup GA on the Windows host. Now, install the MP6 and follow-on patches.
4.4.1. Installing Veritas NetBackup MP6 Patch on Windows

Like Solaris, the patch file is quite large--over 300 MB. In fact an ISO is provided on the Veritas website. Follow the provided instructions. Below is a summary. 1. To install the patches, first unzip the file in a temporary directory. Once the setup program is executed, the same splash screen appears as in the GA installation covered previously. After viewing the readme file, select Start NetBackup Server Installation as before. The Welcome to NetBackup Setup Wizard appears. Note that it has found the older version and will do an upgrade. The NetBackup License Key and Server Type screen appears. No license key is required. Select NetBackup Media Server. The Setup Type window appears (not shown). Pick Typical as before. Verify that the Media Server and the Master Server names are correct. In this case they are int124 and int123 respectively.
2.
Note:
3.
The Installing NetBackup window appears and the automated installation begins. Once complete, a reboot is required for the update to take effect. After the reboot, the files and registry entries go through a final update. This takes a few moments to complete.
Note:
This ends the MP6 patch installation. Check the Veritas website for critical issues found after the latest patch release. It may be required, as is in this case, to install a special patch.
4-11
4.4.2. OPTIONAL: Install Special Critical Patches

From time to time, patches for critical issues are released and require installation outside of a normal MP release. This section provides some guidelines on the installation performed in this solution. Refer to the Veritas readme files for details on the patch and installation options. Note: These updates require a particular MP level. Like normal MP releases, these are found online by navigating from Veritas's home page. In this solution, a critical patch was required for MP6.
To do the install, unpack the zip file into a temporary directory and run setup.exe to install. The results.txt file shows whether the update was successful. In this case a reboot is not required to complete the installation. Once complete, the machine is now fully patched. Now that NetBackup is fully installed on each host, it is time to do the final setup. Guideline: Archive all Veritas patch files as part of the preparation for recovering a down NetBackup server.
4-12
4.5. Final Setup of NetBackup 4.5

This section provides the essential configuration steps and guidelines for adding a Media Server to the overall NetBackup configuration in a Brocade MetaSAN. This process is repeated for all Media Servers so that communication with the Master is established over the LAN and the proper management authentication is in place. At the end of this section, a final discussion will show a successfully-completed backup job. Please refer to the Veritas NetBackup Adminstrators Guide for UNIX and the Veritas NetBackup Administrators Guide for Windows for all the details. Note: Be aware that a complete qualification of the solution is beyond the scope of this project. Only a few spot checks are shown that validate that the solution is functional at the most basic level. Additional tuning and testing may be required.
Note:
This solution only shows example flat file backups on Solaris and Windows. Other configuration steps are required for backing up different OS platforms, SQL Server, Oracle, Exchange or other database products, and are not covered here. Server Free Snapshots and NDMP backups are not covered in this document. Setting up these environments can be quite complex. Separate patches also may be required. This information can be found in the Veritas Administration Guides and other specific documentation on these separately-licensed products.
4.5.1. Configuring the Master Server for Backups

Now that NetBackup has been installed, this section will provide a summary for configuring the NetBackup Master Server to use the STK L180 library for backup jobs. Briefly, the steps are:

Note:
Launch the NetBackup Management GUI and access the Master Server NetBackup Administration Console. Run the Getting Started Wizard to Configure Storage Devices, Configure Volumes, Catalog Backup and Backup Policy. Each part can be done separately within the various NetBackup management components. (These steps will not be shown in detail.) Configure a NetBackup Backup Policy on the Master Server. Run a test backup to validate the NetBackup configuration. OPTIONAL: Install the NetBackup Client Software on all other hosts using the remote installation method. (This was not done for this particular solution.)
True SAN-based backups require that each host be configured as a Media Server. If a host is configured as a NetBackup Client only, part of the backup data I/O will occur over the LAN. Backup clients do not access tape devices but instead rely on the Media Server to backup their file systems.
Guideline: The most important step is to have the robot in inventoried. This will confirm whether the Master Server has established communications with it, and that the device configuration has completed successfully. Be sure the robot inventory completes successfully. The final steps are to configure the Volumes, Catalog (which is the backup of the NetBackup configuration), and the Policy. None of these steps are shown. For details, refer to the NetBackup DataCenter Administration Guide for UNIX and Windows. The next section will discuss how to add Media Servers so the Master Server can perform administration tasks and backups.
4-13
4.5.2. Central Management of Media Servers

The Master Server is the only server that can define policies containing schedules and clients, run reports, and view job activity. Adding a Media Server to the Master Server Properties allows it to be authenticated for managing the backup configurations through the Master Server. This is an optional step but is recommended for ease of management. A Media Server must be added for the Master Server to mange its devices and provide robotic control of the STK L180. Other NetBackup servers can perform this function but must be configured to do so. For details on adding a Media Server to a SAN Environment, please refer the Veritas NetBackup SAN Administrators Guide. Guideline: For true LAN-Free backups of a host, a Media Server must be installed. This keeps all data traffic off of the LAN. Installing as client is acceptable, but because it doesnt have access to the tape device through the SAN (the Media Server does), part of the data traffic will be LAN-based. 1. Double-click on the Master Server (int123.brocade.com) from the Host Properties on the left pane of the NetBackup Admin Console window. Left click on the Servers tab. The Servers window appears. Click New under Additional and Media servers and add the entries for each new Media Server (int124 and int205) in the dialog box that appears. Stop and restart the NetBackup daemons from the command line. Use either the scripts in the goodies directory or the start and stop scripts in the rc.d directory. After clicking on the Restart Daemons window, restart the NetBackup Administration Console GUI. Repeat for each Media Server as outlined in Table 4-1.
2. 3. 4.
All Media Servers should now be able to be managed by the Master Server.
4.5.3. Configure the STK Tape Library On the Media Server

Now that the Media Servers are added to the NetBackup management framework, configure the storage devices to be used for backups. This section provides some guidelines when configuring a tape library in a Meta SAN environment. The Windows host (int124) will be used as an example. All tasks are done from the Master Server. Once again, only a summary will be shown. Refer to the Veritas Administration Guides for further details. Guideline: A test backup should have been done on the Master Server prior to starting the Device Configuration on the Media Servers. This will verify that the library is seen through the Meta SAN by the Master Server and is functional. 1. The first step is to launch the Administration Console GUI on the Master Server. This is done by launching jnbSA from /opt/openv/netbackup/bin. Log on and switch servers to int124. Double click on Configure Storage Devices to begin. By default all available device hosts (Media Servers) are selected. Note that because the single STK L180 is to be shared among all hosts, all device hosts must be checked. This will allow the Shared Storage Option (SSO) to be activated automatically
Note:
2.
The Scanning Hosts window appears. After a few moments the devices are auto-discovered. This may take an extended period of time.
4-14
Note:
Note that the tapes drive names are prefaced with (shared). This means SSO has started correctly. The device configuration will be updated.
Warning: The automatic configuration of the storage units did not work well. After several retries, most of the time it failed. A workaround is to manually configure them through the NetBackup Administration Console by selecting them in the left pane.
4-15
4
3.
Manually set up the Storage Unit. The following settings were used for this solution:
Figure 4-2
Guideline: When defining a storage unit as part of the policy definition in a Brocade Meta SAN environment, assign a dedicated Storage Unit to each Media Server rather than choosing Any Available by default.
Guideline: The On demand only option is checked because the drives are being shared with SSO in the Meta SAN. This allows for the drives to be properly reserved and released on demand of a Media Server when a backup job is requested. This completes the Media Server Device Configuration. The next step (not shown) is to define the backup policies. A backup policy contains local policy attributes, schedules, clients, and file systems to be backed up. Once defined, a manual backup should be executed on each Media Server to verify that the backup policy has been set up properly.
4-16
4.5.4. Viewing the NetBackup 4.5 Configuration

The following section shows screenshots that display the NetBackup configuration used in this solution. 1. 2. To validate connectivity, double click on each Media Server host under the Host Properties. If the LAN connectivity is established, a green check mark will be displayed as shown. Double-clicking on the Policies item in the left pane displays each policy. Clicking on the + expands each as shown. To change a policy setting, right click on an Attributes, Schedules, Files, or Clients and select Change. A configuration window will open.
Figure 4-3 3.
NetBackup Policy View
Doubl- clicking on the robot TLD(0) under Media and Device Management shows the available tape volumes and their settings.
4-17
4.5.5. Performing a Test Backup

To validate the entire Meta SAN configuration, use the defined policies to perform a test backup. This should be done for each Media Server. The Master Server, once properly configured to be allowed access, can be used to start the backup jobs. After the test backups complete successfully, perform any final tuning. The following shows how to start a test backup: 1. 2. From the Master Server, select the policy. Right click and select Manual Backup. The backup job will be submitted. To check the real time status, select the Activity Monitor and double click on the Job number. The Job Details pane appears. This shows the current status of the job. A 0 indicates successfully completed. If any other number is displayed, the backup job did not complete or completed abnormally. If this happens, click on the Troubleshooter button. It will identify the error number and help identify possible causes and the solutions.
Figure 4-4
Successful Backup
This completes the Meta SAN Tape Configuration Solution. Note: NetBackup can be tuned extensively and this should be completed after test backups have completed successfully on all Media Servers participating in the Meta SAN. These steps are beyond the scope of this document. Refer to the appropriate NetBackup documentation for these options and recommended settings.
4-18

Meta SAN Tape Consolidation - 489-01

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Meta SAN Tape Consolidation - 489-01

Hochgeladen von

Copyright:

Verfügbare Formate

Brocade Multiprotocol Routing Services Solution Guide

Publication Number: 53-0000489-01 Publication Date: March 01, 2004

Brocade Communications Systems, Incorporated

Preface Chapter 1 Meta SAN Tape Consolidation Overview

Solution Requirements and Design

Configuring the Brocade Meta SAN