ACSLS 8.5 introduces greater flexibility for customers with varied platform and file-system preferences.
The ACSLS 8.5.1 package installs in any file system on the following platforms:
Solaris 11.3 or 11.4
Oracle Linux 6.8, 6.10, 7.3, 7.6, or 7.8
For additional ACSLS documentation, refer to the Oracle Technical Network (OTN) at:
ACSLS Release 8.5.1 includes the following enhancements:
SL4000 Library Enhancements:
Support for SL4000 v1.0.2.
Support for feature cards running SL4000 v1.0.2.
New acs_partition.sh utility to update ACSLS partition IDs aligned to the SL4000.
Platform and Operating System Support:
Oracle Enterprise Linux (OEL) 6.8, 6.10, 7.3, 7.6, and 7.8 standalone servers.
Solaris 11.3 SRU 35 SPARC and x86 standalone servers.
Solaris 11.4 SRU 8 SPARC and x86 standalone servers.
SL4000 Feature Card running SL4000 v1.0.2.
SL4000 Application Feature Card Enhancements
Ability to run ACSLS on a single feature card or dual feature cards.
Ability to run ACSLS on one feature card and SDP2 on the other feature card.
Ability to run ACSLS with enhanced availability capabilities using the ACSLS Feature Card Availability Toolkit (FCAT).
Performance and Tuning Improvements
Assorted enhancements also include Target Mode support for QLogic HBAs at speeds of 32Gb and greater.
Installer Enhancements
Assorted enhancements, including a new capability to enable core dumps at the time of ACSLS installation.
Bug Fixes
Assorted ACSLS bug fixes and security updates (WebLogic).
Documentation Enhancements and Updates
Assorted enhancements, including new sections for ACSLS installation on the SL4000 feature card and documentation for using cmd_proc_shell.
Note:
SNMP Agent is not supported in this release. This support will be available in a subsequent release.Refer to the ACSLS Installation Guide for ACSLS software, system, browser, and co-hosting requirements.
ACSLS 8.5 has been developed and tested for the following operating system environments:
ACSLS Release 8.5.1
Oracle's Sun SPARC and X86 platforms running Solaris 11, Update 3, or Solaris 11, Update 4:
For Solaris 11, Update 3, Support Repository Update (SRU) 35 or later is required.
For Solaris 11, Update 4, Support Repository Update (SRU) 8 or later is required.
Oracle recommends using the latest SRU available. Visit the My Oracle Support page at https://www.support.oracle.com for more information.
Oracle Enterprise Linux releases 6.8, 6.10, 7.3, 7.6 and 7.8
ACSLS Release 8.5.0
Oracle's Sun SPARC and X86 platforms running Solaris 11, Update 3.
Support Repository Update (SRU) 35 or later is required.
Oracle recommends using the latest SRU available. Visit the My Oracle Support page at https://www.support.oracle.com for more information.
Oracle Enterprise Linux releases 6.8 and 7.3
Oracle Linux testing was performed in environments using Oracle's Unbreakable Enterprise Kernel. Other operating systems, including virtual environments, are not tested or supported.
Note:
Special device drivers are provided in ACSLS for use with logical libraries and with fibre-attached libraries, such as the SL500 and SL150. This is an issue for Solaris zoned environments. Because such device drivers are attached to the system kernel, they must reside in the global zone. In cases where such drivers are used, ACSLS cannot be installed in the local zoned environment. Logical libraries are not supported on the Linux operating system.Memory: 4GB minimum
To show system memory:
Solaris
prtconf | grep Mem
Linux
grep MemTotal /proc/meminfo
Swap Space: Solaris and Linux systems should be equipped with a minimum of 4GB of memory and a minimum of 2GB of swap space. When system memory exceeds 6GB, provide swap space that is no less than 30% of physical memory. To check swap space, enter one of the following operating system commands:
Solaris
vmstat -S
The result is expressed in kilobytes.
Linux
vmstat -s | grep total
The result is expressed in kilobytes.
File systems and required databases:
ACSLS enables you to install in any file system. You must define the following directories before installing ACSLS:
A base directory where the ACSLS components will be installed.
A default directory for ACSLS backups. It is recommended (but not required) to place the ACSLS backup directory in a separate file system from the ACSLS base directory.
Although you can install ACSLS in any directory, the default directories used for ACSLS are:
/export/home is the default ACSLS base directory.
/export/backup is the default ACSLS backup directory.
The ACSLS base directory file system requires a minimum of 5GB free. Reserve an additional 5GB free for ACSLS backups. To view file system sizes, enter the following command:
df -h
Fibre card (optional) is optional. A suitable HBA is required for Fibre Channel operations.
For target mode operation, supporting the Logical Library feature, this HBA must be a contemporary QLogic fibre card (4Gb or higher).
For initiator mode operation, supporting a fibre-connected library such as the SL500 or SL150, ACSLS is fully tested and certified with QLogic and Emulex HBAs.
Oracle recommends that you install the latest version of the Java Development Kit (JDK) on your ACSLS server before you install ACSLS. The following Java releases are supported:
Java 7, Update 131 or later
Java 8, Update 172 or later (recommend Java 1.8.0u221 or later)
The ACSLS GUI can operate with most common browsers, though formal testing has been limited to recent releases of FireFox, Chrome, and Internet Explorer. The Chrome browser and earlier versions of FireFox have tested well using the default settings for ACSLS in the WebLogic server. Internet Explorer V8 (and above) and FireFox V39 (and above) require configuration settings to provide a 2048-bit self-signed digital certificate for https. Please refer to the section, "Configuring a Self-Assigned Digital Certificate for HTTPS" in the ACSLS 8.5 Installation Guide.
To ensure uninterrupted library service and to avoid unanticipated problems due to resource contention, it is generally recommended that ACSLS run in a standalone environment on a dedicated server. However, some systems are designed to allow multiple applications to run in co-hosted fashion as though they are completely isolated from one another. Solaris Containers and Oracle Solaris VM Server for SPARC enable conditional co-hosting possibilities for use with ACSLS.
The following list details the conditions and limitations associated with the various co-hosting options for an ACSLS application.
Solaris Zones (containers)
Solaris 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 zone 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 bad practice to install an application in the global zone since any irrecoverable error condition with the application could impact all other applications running in the other zones.
ACSLS can reside in a Solaris zone only if it does not require drivers beyond the network interface. Any use of Logical Libraries requires a target-mode fibre-channel driver, and any connection to an SL500 or SL150 library requires an initiator-mode fibre-channel driver. Either of these configurations dictates that ACSLS must be installed in the global zone.
Oracle VM Server for SPARC
Oracle VM Server for SPARC (formerly Logical Domains or LDOMs) 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 buses 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 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.
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.
Support is provided for ACSAPI clients, cmd_proc and ACSLS utilities (startup and shutdown have changed).
The Web-based ACSLS Graphical User Interface (GUI) provides a graphical console for manipulating and monitoring library operations and for the administration and operation of logical libraries. Refer to the online help for procedures and detailed information for using the GUI.
An alternative library console with greatly expanded flexibility and ease of use. It provides most of the operations that are available in the legacy cmd_proc.
Logical library support.
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.
Real-time monitoring of tape library components.
A tree browser to navigate physical and logical configuration.
Real time alerts that are visible from each screen.
An alert informs you of conditions that might result in damage to hardware, corruption of data, or corruption of application software. It always precedes the information to which it pertains.
The ability to filter volume and drive displays with user-specified criteria.
User-customized views of system events and system logs.
Online help.
The ACSLS GUI or lib_cmd enables you to create logical libraries which include a sub-set of the volumes and drives in a specific physical library. This enables you to define logical subsets of your physical libraries, which can be managed and used 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 cannot 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.
Logical libraries are only supported on the Solaris operating system. They are not supported in the Linux environment.
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.
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 use 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.
ACSLS provides an ACSAPI client interface which is compatible with existing client applications.
Two ACSLS command-line interfaces, cmd_proc and lib_cmd are accessible to users acsss and acssa.
The primary command-line interface for library control is cmd_proc. The cmd_proc gives you access to all library operational functions related to physical tape volumes and drives. These functions include mount, dismount, enter, eject, audit, query, display, and vary.
A second command-line interface, lib_cmd, is primarily used for configuring logical libraries, but has a limited set of commands related to physical libraries, including display, vary and eject.
ACSLS provides a set of utilities which can be executed from a shell running on the ACSLS server.
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.
Cartridge vaulting operations.
Library management utilities.
Library inventory reporting.
ACSLS software consists of multiple services that are operated with a simple command, acsss. The acsss macro enables you to start, stop, and check status of the multiple services as a single entity. Common operations with the acsss macro include:
acsss enable to start ACSLS.
acsss disable to stop ACSLS.
acsss status to check the status of the various services.
Once enabled, the various services are controlled and monitored by the Solaris Service Management Facility (SMF), or the Linux init service utility. These respective system utilities handle automatic restart operations after a system boot.