B Enterprise Library Connection Options

This chapter contains the following:

Overview

There are multiple options for connecting ACSLS to SL8500 and SL3000 libraries. These options can be used independently or together, for communication between ACSLS and an SL8500, or SL3000.

In a string of connected SL8500s, you can implement Dual TCP/IP and/or Multi-library TCP/IP, and/or Redundant Electronics.

In an SL3000 or SL8500, you can implement Dual TCP/IP and/or Redundant Electronics (RE). You can connect to an SL3000 or SL8500 through IPv4.

The following summarizes the connections options:

  • Dual TCP/IP

    Dual TCP/IP provides two separate and independent TCP/IP connections between ACSLS and a Library Controller card. If one of these communication paths fail, ACSLS automatically uses the second path for communication.

    To implement Dual TCP/IP support, routing tables on both the ACSLS server and the library must be defined and managed using the ”route” command. These routing tables force communication between a pair of ports on the ACSLS server and the library to use a defined network communication path.

    Both the SL8500 and the SL3000 support Dual TCP/IP communication with the library.

  • Multi TCP/IP Support

    Multi TCP/IP support allows the ACSLS server to connect to multiple SL8500 libraries in a string of connected SL8500s. If communication with one library fails, ACSLS automatically sends library communication to the connections with the other libraries. The libraries automatically forward the messages to the other libraries.

    Configuring and managing Multi TCP/IP communication is simpler than Dual TCP/IP because routing tables do not need to be defined on the ACSLS server or the SL8500 libraries. However, Multi TCP/IP requires a string of connected SL8500 libraries. It does not apply to single, stand-alone SL8500 or SL3000 libraries.

  • Redundant Electronics (RE)

    RE uses a redundant set of Library Controller cards. At any given time, one set is active and the other set is standby. The active Library Controller can failover to the standby in response to a command from ACSLS or the SL Console. Automatic failover can be initiated by the library if a library card fails.

    RE enables minimally disruptive library firmware (microcode) downloads. Within a string of connected SL8500s, RE can be implemented on a per library basis. You can implement RE in any or all libraries within a complex.

    To support RE in the library, ACSLS 7.3.1 or 8.0.2 or later is required.

Displaying the status of ACSLS Communication with Libraries

Use the query lmu command to view and monitor the status of ACSLS communication with the libraries it manages. The query lmu command also shows the status of ACSs and port connections to libraries.

Dual TCP/IP Support

Dual TCP/IP is an option that can be purchased for the SL8500 and SL3000 libraries (herein known as the library). It provides two TCP/IP connections to the library. However, you can continue to use the library with only one of the two connections operational.

The purpose of dual TCP/IP is to automatically recognize and avoid a failing communication path. Since this is automated, there is no need for you to manually switch from an inoperative connection.

To use dual TCP/IP support on the library, the routing tables on both of the ACSLS server and the library must be managed using the ”route” command. This forces a route to the defined network interfaces on the library which in essence, creates a one- to-one relationship between interfaces. The Customer Systems Administrator (CSA) changes the routing tables on the ACS server and the Customer Systems Engineer (CSE) updates the routing tables on the library. For further information on the UNIX ”route” command, refer to the man pages on your ACSLS server.

Requirements

  • Coordinate with both your system administrator and network administrator to understand your current network environment, and to identify all necessary IP addresses in advance.

  • Coordinate with your system administrator to either configure your network interface, or to validate that it is configured properly.

Configuration

It is recommended that ACSLS keep two connections to the library open since ACSLS uses all active connections. If one connection is inoperative, ACSLS uses the remaining operative connection while continuing to try to re-establish communication on the failing connection.

The preferred configuration for dual TCP/IP implementations would be two network interfaces on two separate subnets for the ACSLS server, as shown in Scenario 1. This provides maximum throughput and minimum resource contention, with regard to network communications while adding a second physical connection, improving reliability.

To configure two TCP/IP connections to a single library, use the acsss_config utility or Dynamic Configuration (config). Enter the number (2) of connections that there are to the library and the IP addresses of the network devices. The SL3000 supports IPv4 connections.

The following scenarios provide examples for configuring the ACSLS server. For instructions on configuring the library dual TCP/IP feature, refer to the appropriate library System Dual TCP/IP Feature document.

The following scenarios use private subnet IP addresses and will not be the same in your environment. These scenarios assume that your network devices have been configured and are functioning properly.

Scenario 1 - Preferred Configuration

Scenario 1 is the preferred configuration for the dual TCP/IP feature.

In this configuration, the ACSLS server contains two network interfaces that reside on two separate subnets. The SL8500 or SL3000 has two network interfaces on the same two subnets as the ACSLS server.

Figure B-1 Preferred Configuration

Surrounding text describes Figure B-1 .

In this scenario, the libraries use a one-to-one relationship with the network interfaces on the ACSLS server in which the:

  • qfe0 interface on the ACSLS server only communicates with the eth0 interface on the SL8500 or SL3000.

  • qfe1 interface on ACSLS only communicates with eth5 on the SL8500 or SL3000.

Using the UNIX ”route” commands, you force this relationship.

  • For Solaris: as user root, type the following commands:

    route -p add 7.0.50 -ifp qfe0 192.168.0.254

    route -p add 192.168.1.50 -ifp qfe1 192.168.1.254

    The first route command routes any communication with 192.168.0.50 to go through qfe0 on the ACSLS server and then go through Router 1.

    The second command routes any communication with 192.168.1.50 to go through qfe1 on the ACSLS server and then go through Router 2.

    You can validate that the routes are in the routing table by typing:

    # netstat –r

Example B-1 IPv4 Routing Table

Destination              Gateway       Flags  Ref  Use  Interface 
______________           ________       _____  ___  ___  _________ 
192.168.0.50             192.168.0.254  UGH    1    0    qfe0 
192.168.1.50             192.168.1.254  UGH    1    0    qfe1 
192.168.0.0              192.168.0.1     U     1    7    qfe0 
192.168.1.0              192.168.1.1     U     1    0    qfe1 
BASE-ADDRESS.MCAST.NET   192.168.0.1     U     1    0    qfe0 
default                  192.168.0.254   UG    1   33 
localhost                localhost       UH    4   77    lo0

The first two entries are the ones that were just added. All communication with 192.168.0.50 will go through QFE0, and communication with 192.168.1.50 will go through QFE1.

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 Modular Library System Dual TCP/IP Feature document.

Scenario 2

Scenario 2 shows:

  • ACSLS server with two interfaces on separate subnets from the library

  • SL8500 or SL3000 library with two network interfaces on separate subnets from ACSLS

  • Both ACSLS and SL8500 or SL3000 using a public network

Figure B-2 ACSLS and SL8500 or SL3000 Using a Public Network

Surrounding text describes Figure B-2 .

Using the UNIX ”route” commands, you force this relationship.

  • For Solaris: as user root, type the following commands:

    #route add 192.168.2.50 -ifp qfe0 192.168.0.254

    #route add 192.168.3.50 -ifp qfe1 192.168.1.254

    The default routes for the ACSLS remain the same. The routes within the subnets will know how to route communication to the libraries through the public LAN and you are still forcing the one to one relationship with the interfaces. Again, this is seen using the following command:

    # netstat –r

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/IP Feature document.

Scenario 3

In this scenario, there is one ACSLS server with one network interface on a separate subnet. The SL8500or SL3000 library has two network interfaces on two subnets that are separate from the ACSLS server.

Figure B-3 SL8500 or SL3000 with Two Network Interfaces

Surrounding text describes Figure B-3 .

Remember: Configure the library routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/ IP Feature document.

Scenario 4

Scenario 4 shows:

  • Two Highly Available (ACSLS HA) servers, both with three network interfaces, two separate private subnets with the SL8500 or SL3000, and a third public network.

  • One SL8500 or SL3000 library with two network interfaces on the same two private subnets as the ACSLS servers.

Figure B-4 ACSLS HA

Surrounding text describes Figure B-4 .

In this scenario, ACSLS HA uses two different servers with each using different network interfaces. This means that custom route entries must be added to both ACSLS servers.

For the Solaris user:

  • On ACSLS server 1, you would type:

    route add 192.168.0.50 –ifp qfe0 192.168.0.254

    route add 192.168.1.50 –ifp qfe1 192.168.1.254

  • On ACSLS Server 2, you would type:

    route add 192.168.0.50 –ifp qfe1 192.168.0.254

    route add 192.168.1.50 –ifp qfe2 192.168.1.254

    You must add the IP addresses for both servers to the libraries' configuration. Refer to the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/IP Feature document.

    It is important that you separate the libraries' network interfaces over two different subnets when on ACSLS HA. The purpose of a Highly Available environment is to build in redundancy and eliminate single points of failure.

Remember: Configure the libraries' routing tables according to the instructions in the StorageTek SL8500 or SL3000 Modular Library System Dual TCP/ IP Feature document

Retaining Customized Routing Table Entries after a Reboot

Any customized routing table entries are lost after a system reboot. This is the nature of system routing tables and is expected behavior.

In order to support the Dual TCP/IP feature on the SL8500 or SL3000, it is necessary to add custom entries to the routing tables on the ACSLS server. When the ACSLS server is rebooted, all routing table entries are flushed and any necessary routes to the libraries are removed. Since this is the nature of the operating system, there are a couple of different ways to handle this situation.

Creating Scripts

You can create scripts to add custom routes to be initialized at boot time. See "Adding Custom Route To Be Initialized At Boot Time" for procedures.

These scripts can then be placed in the rc directory structure for automatic execution at boot time. Refer to your system documentation for details on the best way to implement this.

Use the ACSLS startup scripts to add your custom routing entries at boot up time. The startup scripts check for a file that contains customized route table entries. Any entries found are added to the routing table automatically using the UNIX route command. For standalone ACSLS installations, this is a desirable method to maintain route entries that are necessary for library support.

Important: This solution will not work if the ACSLS installation is a Highly Available ACSLS (ACSLS HA) environment.

In this case, you must use the first method to maintain routing tables.

ACSLS HA handles system initialization differently than a standalone ACSLS server because it relies on Solaris Cluster to manage its clustered resources, which means ACSLS cannot be automatically started by way of the system RC mechanism at boot time. This is handled strictly by the Solaris Cluster agents with the S87ACSLS startup scripts never being used. Add a script with the appropriate ”route add” commands and locate it within the /etc/rc2.d directory structure. It is highly recommended that anyone with an ACSLS HA environment engage Oracle Advanced Customer Support – preferably the same consultant that originally installed the ACSLS HA system.

Adding Custom Route To Be Initialized At Boot Time

To add custom routing entries:

  1. cd to the following directory:

    $ACS_HOME/data/external/ custom_routing.

    This directory contains the template file custom_routing_tables.tpl.

  2. Copy this file and change the file name to custom_routing_tables.

    # cp custom_routing_tables.tpl custom_routing_tables

  3. Edit (vi) the custom_routing_tables file and add your entries.

    The file contains three fields.

    • The IP address for the SL8500 or SL3000.

    • The name of the interface on the ACSLS server that you want to establish the one-to-one relationship.

    • The IP address of the default route for your subnet.

  4. Follow the instructions in the custom_routing_tables comment section for the format.

    Note:

    Make sure that there are no blank lines.

    When your server reboots, ACSLS is automatically initialized, and your custom routes are added to the routing table.

  5. Verify all routes in the routing table with the following command:

    # netstat -r

Refer to your UNIX man pages for complete documentation on both the route and netstat commands.

Removing routing commands

Use the route command to remove any special routing commands that have been added erroneously or are no longer needed to the earlier configuration.

Example: As user root, type the following commands:

# route delete 192.168.0.50 192.168.0.254

This says to remove the route to 192.168.0.50 (the SL8500 or SL3000) using the default route of 192.168.0.254. The route is then removed.

Multi TCP/IP Support

When SL8500 3.97 or higher firmware is installed, ACSLS can connect to more than one SL8500 in an ACS (library complex).

ACSLS supports up to fifteen connections to an ACS. For example, this can be: fifteen connections to four SL8500s; two connections to each of two SL8500s; two connections to one SL8500 and two connections to two other SL8500s; three connections to two or three libraries, and so on.

When ACSLS is connected to more than one library, the connections should be through different subnets for redundancy. If one subnet fails, communication between ACSLS and the library still continues over the other subnet(s).

When ACSLS has two connections to one SL8500 HBC card, you should configure the SL8500 and ACSLS server routing tables as described in "Dual TCP/IP Support". If you have only a single connection between the ACSLS server and each SL8500 HBC card, configuring the ACSLS and SL8500 routing tables is not necessary.

To optimize library performance, and minimize inter-library communication among SL8500s, define your first connection (port 0) to the library with the most activity.

Configuring and managing Multi TCP/IP communication is simpler than Dual TCP/IP because routing tables do not need to be defined on the ACSLS server or the SL8500 libraries. However, Multi TCP/IP requires a string of connected SL8500 libraries. It does not apply to single, stand-alone, SL8500 or SL3000 libraries.

For more information, refer to the StorageTek SL8500 Modular Library System Technical Brief - Host to Library Communications.

Figure B-5 shows an ACSLS with Multi TCP/IP configuration and Figure B-6 shows an ACSLS with Multi TCP/IP and Dual TCP/IP configuration.

Figure B-5 ACSLS with Multi TCP/IP

Surrounding text describes Figure B-5 .

Figure B-6 ACSLS with Multi TCP/IP and Dual TCP/IP

Surrounding text describes Figure B-6 .

Redundant Electronics

The optional SL8500 or SL3000 Redundant Electronics (RE) feature provides failover protection in enterprise libraries. If the library controller experiences errors, it automatically switches operations to an alternate library controller, with minimal disruption to library and host operations. This allows your Oracle support representative to replace the faulty card while the library continues normal operations.

RE also provides minimal disruption of library operations during firmware upgrades.

Note:

The libraries offer redundancy in a variety of components, including robots and power systems. The term ”Redundant Electronics” refers specifically to redundancy in the library and drive controller components.

RE requires all of the following hardware components:

  • Active library controller (HBC or HBCR) paired with the active drive controller (HBT)

  • Standby HBC or HBCR paired with the standby HBT

  • Other redundant components

For more information, refer to the StorageTek SL8500 or SL3000 User's Guide.

Figure B-7 shows ACSLS with RE in a single library.

Figure B-7 ACSLS with RE

Surrounding text describes Figure B-7 .

ACSLS Support for RE

ACSLS handles a mix of active and standby SL8500 Library Controller (LC) cards within a single library complex (an ACS of libraries connected by pass-thru).

As shown in Figure B-8, either of the HBCR cards in each SL8500 can be the active controller card.

Figure B-8 ACSLS with RE and Multi TCP/IP

Surrounding text describes Figure B-8 .

Each library in a string of connected SL8500s can now have its own pair of redundant Library Controllers. In a library complex, some libraries can have a pair of library controller cards, with RE enabled, while other libraries only have a single library controller. ACSLS should be able to communicate with all of the active LCs at the same time.

ACSLS supports RE with Dual TCP/IP, as shown in Figure B-9, or with Dual and Multi TCP/IP, as shown in Figure B-10.

Figure B-9 ACSLS with RE and Dual TCP/IP

Surrounding text describes Figure B-9 .

Figure B-10 RE with Dual TCP/IP and Multi TCP/IP

Surrounding text describes Figure B-10 .

Query and Retry of Mounts and Dismounts

To support RE, ACSLS implemented the Query and Retry of mounts and dismounts during temporary library and drive outages. For more information, refer to "Queue and Retry Mounts and Dismounts when Library is Temporarily Unavailable".

switch lmu for Only a Single Library

The switch lmu command can be used to force a switch between library controllers in an SL3000 or a single SL8500 library. The switch lmu command cannot be used to switch one SL8500 that is connected to other SL8500s in a library complex.