Skip Headers
StorageTek Automated Cartridge System Library Software Product Information
Release 8.3
E48580-03
  Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

1 Overview

ACSLS 8.3 introduces greater flexibility for customers with varied platform and file-system preferences. The ACSLS package will install in any file system on any contemporary Solaris 10, Solaris 11, or Oracle Linux 6 platform.

Requirements

This section describes the platform, operating system, system, browser, and co-hosting requirements.

Platform Requirements

ACSLS 8.3 will run successfully on any contemporary SPARC or X86 server platform.

Memory

A minimum of 2 GB memory is required for ACSLS 8.3. Additional memory may be desirable in high-volume library environments where multiple requests for mount and dismount operations are to be processed simultaneously or where the GUI is heavily used.

Disk Capacity

A minimum of 40 GB should be available to the file system in which ACSLS 8.3 will be installed. This will accommodate ACSLS and WebLogic binaries, and will allow ample storage for on-going logging and database backup activity.

Network I/O

At least one 10/100/1000-base-T network port is required for client and library communication. Dedicated redundant network adapters are recommended when connecting to SL8500 and SL3000 libraries. Redundant networks are also recommended when connecting to an SL8500 or SL3000 library with the Dual TCP/IP feature.

Fibre-channel

Fibre-channel initiator port is required to support fibre-attached libraries such as the StorageTek SL500 or SL150.

Fibre-channel target port is required if ACSLS is to present logical libraries to fibre-channel client applications. A 4 Gb/s (or higher) QLogic HBA will be necessary for target-mode operation.

Operating System Requirements

  • Solaris 10 Update 10 and Update 11 for SPARC and X86

  • Solaris 11 Update 1 for SPARC and X86

  • Oracle Linux 6.3 and 6.4

    Oracle Linux testing was done in environments using Oracle's Unbreakable Enterprise Kernel and the Red Hat Compatible Kernel. Oracle provides full system support on these systems.

  • Red Hat Enterprise Linux 6.3 or 6.4

    Oracle provides ACSLS 8.3 application support for customers running Red Hat Enterprise Linux 6.3 or 6.4.

Software Requirements

  • ACSLS uses PostgreSQL to manage database services for library control.

    • PostgreSQL 8.3 is a standard inclusion with Solaris 10.For Solaris 11, the PostgreSQL 8.3 packages are provided along with the ACSLS 8.3 package from the Oracle e-delivery site. Installation instructions are provided in the ACSLS 8.3 Installation Guide.For Linux, PostgreSQL 8.4 is provided for easy installation from the Oracle yum repository. Instructions are included in the ACSLS 8.3 Installation Guide.

  • WebLogic 10.3.5 is bundled with ACSLS 8.3.

  • The ACSLS GUI, logical library services, and lib_cmd require Java 1.6 or Java 1.7. The necessary Java runtime environment is a standard package included with Solaris 10, Solaris 11, and Linux 6.

  • ACSLS 8.3 includes (optional) device drivers:

    • The mchanger driver is used to control fibre-attached libraries such as the SL500 and SL150.

    • The qlt and stmf drivers are used to present logical libraries to fibre-channel client applications.

    • If any of these drivers are used, then ACSLS 8.3 must have immediate access to kernel-level functions. In such cases, ACSLS cannot be installed in a Solaris Zoned environment.

Browser Requirements

The ACSLS 8.3 graphical user interface has been tested using the following browsers:

  • FireFox 22.0

  • Chrome 28.0

For Internet Explorer versions 8, 9, and 10, it will be necessary to create an SSL certificate with public/private key pair that is unique to the specific ACSLS server installation. Refer to the ACSLS 8.3 Installation Guide for details on creating such an SSL certificate.

Co-Hosting

To ensure uninterrupted library service and to avoid unanticipated problems due to resource contention, it is generally recommended that ACSLS run in a stand-alone environment on a dedicated server. However, some systems are specifically designed to allow multiple applications to run in co-hosted fashion as though they are completely isolated from one another. Specifically, Solaris Containers and Oracle Solaris VM Server for SPARC enable conditional co-hosting possibilities for use with ACSLS.

The following details the conditions and limitations associated with the various co-hosting options for an ACSLS application:

  • Solaris Containers (zones)

    Solaris Containers (or zones) enable a system administrator to partition a standard, low cost server into four independent Solaris systems, each with its own isolated file system, and its own instance of Solaris. You can assign network resources to each container and you can reboot any local (non-global) zone without affecting applications in other zones on the same platform.

    However, the ability to share kernel resources (such as device drivers) across multiple zones is tenuous at best. Ideally, an application that requires kernel drivers would reside in the global zone. However, it is generally not good practice to install an application in the global zone since any fatal condition with the application could impact all other applications running in the other zones.

    ACSLS 8.x can reside in a Solaris container only if it does not require drivers beyond the network interface. If you intend to use the target-mode fibre-channel driver (qlt) which is required for logical libraries, then your application should not be installed in a Solaris container. Or, if you intend to make use of a fibre-attached library which requires the mchanger driver, the application should not be installed in a Solaris container.


    Note:

    There are no versions of ACSLS-HA that are supported for use in Solaris Containers.

  • Oracle VM Server for SPARC

    Oracle VM Server for SPARC (formerly Logical Domains or LDOMs) is technology available on SPARC T-series servers with Chip Multithreading (CMT) technology. This technology offers significant advantages over Solaris Containers to the extent that each domain is in control of its own Solaris kernel.

    A Solaris administrator can partition hardware resources across the system, assigning a specific resource to a specific domain. Network resources on this virtual machine can easily be shared across any of up to 128 'guest domains' on the server. But applications that require access to I/O devices through the PCIe bus must be installed in special 'I/O domains'. The number of I/O domains that you can create on the VM Server depends on the number of discrete PCIe busses on the SPARC platform. On a system with a single PCIe bus, you can have two I/O domains, and one of these must be the control domain.

    Any ACSLS application that relies solely on network connectivity to the library and for client applications can be installed in a guest domain on this server. The virtual network set-up procedure is described in the document, Oracle VM Server for SPARC 2.1 Administration Guide in the section, entitled ”Using Virtual Networks”.

    If your ACSLS 8.x application is intended for use with logical libraries, or if you intend to connect to a fibre-channel library such as the SL500 or L700, then ACSLS must be installed in an I/O domain. Refer to the section ”Setting up I/O Domains” in the Oracle VM Server for SPARC 2.1 Administration Guide.

    Solaris Cluster Software is supported on the Oracle VM Server for SPARC and this platform can be employed in an ACSLS-HA application. Refer to the Oracle Solaris Cluster Data Service for Oracle VM Server for SPARC Guide.

Overview of ACSLS

This section provides an overview of ACSLS 8.3.

Library Management

ACSLS is automated library management software. It facilitates automated tape operations for multiple clients, providing services and support to enhance library ease-of-use, performance, and availability. One ACSLS server can control libraries connected into a library complex, individual libraries, or a mix of both.

ACSLS includes all library management capabilities available in the legacy ACSLS 7.3.1 product. Support is provided for ACSAPI clients, cmd_proc and ACSLS utilities (startup and shutdown have changed).

Graphical User Interface

The GUI is a browser-based web application which runs within WebLogic. This interface provides an alternative to the traditional cmd_proc interface from ACSLS.

  • Runs as an application with the Oracle's WebLogic.

  • Provides an alternative to the cmd_proc for library administration and operation. It provides the ability to perform most legacy cmd_proc operations, along with new operations related to logical library management.

  • Provides real-time monitoring of tape library components.

  • Provides a tree browser to navigate physical and logical configuration.

  • Real time alerts are visible from each screen.

  • Allows the customizing of filtering capabilities and the ability to download query results to a flat file.

Features

  • Create, edit and delete logical library resources

  • View physical and logical resources

  • Audit physical and logical libraries

  • Perform enters and ejects

  • Perform mounts and dismounts

  • Set clean and set owner for one or more volumes

  • User-customized displays and custom filtering for volume and drive listings.

  • Set the CAP mode and priority

  • Vary operations for physical and logical components

  • System Operations, including ability to cancel selected operations

  • Log viewer for event logs

Logical Libraries

The ACSLS GUI or lib_cmd lets you create logical libraries which include a sub-set of the volumes and drives in a specific physical library. This allows you to define logical subsets of your physical libraries, which can be managed and utilized by client applications as if they were separate logical libraries. You can dedicate a portion (or all) of the volumes and drives in a given physical library to a logical library for use by a specific client application.

  • A logical library can not span more than one physical ACS (or physical partition).

  • Logical libraries are accessible to clients using the ACSLS 8.x SCSI Interface. They are not available to clients that use the legacy ACSAPI.

  • Physical drives and cartridges that are allocated to logical libraries become inaccessible to ACSAPI clients. The physical libraries, along with any drives and volumes that are not allocated to logical libraries, remain accessible to ACSAPI clients.

  • Drives and volumes that are allocated to logical libraries are allocated exclusively. There is no support for sharing of either drives or volumes across logical libraries.

Open Format (Volser)

Before ACSLS 8.x, support for longer volume labels in physical libraries relied on library firmware and configuration.

Now, the ACSLS SCSI Media Changer Interface allows ACSLS to support longer volume labels. You have visibility to the longer volume labels through the GUI, the CLI (cmd_proc), and utilities.

Longer volume labels are viewed by clients using the SCSI Medium Changer interface to access logical libraries. They are not accessible to ACSAPI clients.

SCSI Media Changer over Fibre Client Interface

ACSLS 8.x provides a SCSI Media Changer over Fibre Channel Interface for allowing access to logical libraries. ACSLS can service multiple SCSI clients simultaneously. Each client has exclusive access to its assigned logical library.

This allows client software, such as NetBackup, to utilize the logical libraries as if they were separate physical libraries. Each logical library can be assigned to only one client, but a given client can access multiple logical libraries if desired. ACSLS 8.x does not allow direct SCSI client access to the backing physical libraries - only the volumes and drives assigned to the logical libraries are accessible.

SCSI client access can be established when creating or modifying logical libraries.

ACSAPI Client Interface

ACSLS 8.x provides an ACSAPI client interface which is compatible with existing client applications. The ACSAPI interface is identical to that provided in the legacy ACSLS 7.3 product.

Access and Visibility

ACSAPI clients have neither visibility nor access to logical libraries.

Physical Drives and Cartridges

Physical drives and cartridges that are allocated to logical libraries become inaccessible to ACSAPI clients. The physical libraries, along with any drives and volumes that are NOT allocated to logical libraries, remain accessible to ACSAPI clients.

Command Line Interface

ACSLS 8.x provides a command-line interface in the form of the legacy cmd_proc from ACSLS. This interface provides the same functionality as ACSLS 7.3 for managing physical library resources.

The cmd_proc interface does not provide access to logical libraries. But the physical resources which have been allocated to logical libraries do remain fully accessible through the cmd_proc administrative CLI (although they are not accessible to ACSAPI clients).

Utilities

ACSLS provides a set of utilities which can be executed from a shell running on the ACSLS server. This includes most of the traditional utilities provided in the legacy ACSLS 7.3.1 product.

These utilities include the following:

  • backup and restore operations for database tables

  • import and export operations for database tables

  • startup and shutdown operations

  • dynamic configuration for physical libraries

  • volrpt, moving.sh, and ejecting.sh

Differences and exceptions

  • A new utility (checkGui.sh). The ACSLS GUI installation has multiple dependencies, including WebLogic status, acsls deployment, and possible firewall settings. The utility, checkGui.sh tests these various dependencies and provides a summary report showing the status of each one. For more information, refer to the ”Troubleshooting” appendix in the ACSLS 8.3 Administrator's Guide.

  • A new utility (getHba.sh) manages Fibre Channel (FC) ports. Ports can be configured to operate in target mode (supporting FC clients) or in initiator mode (managing FC-attached physical libraries).

  • ACSLS provides a new command (acsss) for starting and stopping the library management application. This command is available from the shell prompt only, and is not accessible from the GUI.

    The acsss command replaces the db_command, rc.acsss, kill.acsss, and fix_rc.sh commands used in ACSLS. The acsss command also provides the ability to monitor application status. For example, you use:

    • acsss enable to start ACSLS

    • acsss disable to stop ACSLS

    • acsss to see the list of options

No Longer Requires Software Licenses

Beginning with StorageTek ACSLS versions 7.3.1 and 8.x, the right-to-use license is no longer enforced in StorageTek ACSLS, and ACSLS no longer checks for a valid license key. Messages regarding a soon-to-be-expired license key or library capacity license no longer appear on the system console or in the acsss_event.log.

The following utilities no longer function in their capacity to set and check for a valid license key:

  • licensekey.sh

  • get_license_info.sh

To view your library slot usage use the free_cells.sh utility.

testports Utility

Beginning with StorageTek ACSLS versions 7.3.1 and 8.x, a new testports utility tests the connection to TCP/IP libraries and whether the ACS and port connection is online or offline.