OpenVault is a storage library management facility that improves how applications can manage, store, and retrieve removable media (called cartridges). As an overseer of storage applications, and the libraries and drives that manage storage, OpenVault is aware of resources and allocates them accordingly, reducing bottlenecks and device mismanagement.
This chapter introduces OpenVault, and is divided into the following major sections:
“What OpenVault Does”, describes the OpenVault software package.
“How OpenVault Fits In with Other Software”, describes how OpenVault works with other software.
“OpenVault Terms”, defines terms used in this document.
“OpenVault Architecture”, describes the OpenVault architecture.
“How OpenVault Operates”, describes OpenVault operations.
OpenVault is a package of mediation software that helps other applications access and manage removable media. This facility can support a wide range of removable media libraries, as well as a variety of drives associated with these libraries. OpenVault includes a database to track cartridges and storage devices. The modular design of OpenVault eases the task of adding support for new robotic libraries and drives.
The advantage of using OpenVault is that it can manage multiple applications and track the devices and removable media that each application uses. Additionally, because it adds a standards-based layer of software between the storage application and a library device, new libraries can be introduced without having to obtain an updated version of an application, and conversely, new applications can be added without having to update library or drive interface software.
OpenVault also has a command-line interface for performing administrator and operator tasks. These tasks include the following:
Setting up and configuring applications and storage devices to run with OpenVault
Monitoring your storage management operations
Organizing your storage libraries for optimal operation
Chapter 4, “Administering OpenVault”, and Chapter 5, “Operating OpenVault”, describe how to perform administrator and operator tasks. Appendix A, “OpenVault Troubleshooting”, provides an overview of OpenVault administrative commands.
OpenVault, as middleware, operates between applications and devices, as shown in Figure 1-1. OpenVault uses a client/server model and is designed to work equally well in either a single-host computer system or in a networked environment supporting multiple computers.
Software that mediates between operating systems and application programs is called middleware. Middleware creates a common language so that users can access data in a variety of formats, or devices from different vendors.
As middleware, OpenVault receives high-level requests from client applications, and translates these requests into a set of low-level robotic or device-controller commands to accomplish storage-related tasks. As overseer of storage management, OpenVault schedules competing storage requests from different applications for the available devices, establishes and allocates cartridge groups by application, and provides mapping from logical cartridge names (as seen by the application) to physical cartridge numbers (as used by robots).
OpenVault software, as middleware, provides two standard interfaces:
The first for storage-based applications that use cartridges
The second for devices (libraries and drives) that store and retrieve information on cartridges
OpenVault works as a client-server model. At the most basic level, both client and server can operate on the same host. More typical, though, is a distributed system where multiple clients located on a network send requests to a centrally-managed server, which mediates access to locally attached libraries and drives.
This section describes some storage management terms. Terms not specific to OpenVault are followed by an asterisk (*).
This section describes some OpenVault definitions:
OpenVault is organized as a set of cooperating processes. The OpenVault server is a multithreaded process that accepts client connections and fulfills access requests by forwarding them to appropriate library and drive control programs. The OpenVault server maintains a catalog containing information about cartridges in the system, and descriptions of authorized applications, libraries, and drives. Figure 1-1, shows the arrangement of OpenVault components.
AAPI (administrative API) is the language that administrative applications use to communicate with the OpenVault server. Commands and responses are text strings.
The command-response format is semi-asynchronous. After submitting each command, the application waits for the server to acknowledge receiving the command, but need not wait for results before sending the next command. AAPI communications libraries can also work synchronously if this makes implementation more convenient.
CAPI (client application programming interface) is the language that client applications use to communicate with the OpenVault server. CAPI commands and responses are text strings. As with AAPI, the command-response format is semi-asynchronous, and access to the server is session-oriented. CAPI is a subset of AAPI.
The OpenVault Application Programmer's Guide tells how to program AAPI and CAPI.
The OpenVault server accepts requests from applications, and forwards commands to an LCP and DCP, which translate them into low-level robotic and drive control operations to serve that request. OpenVault also schedules competing requests from different applications, creates and enforces cartridge groups for specific application, and maps logical volume names (used by applications) to physical cartridge labels (used by libraries).
The OpenVault server manages cartridges, directing LCP and DCP to mount and unmount a cartridge. Often, cartridges store data. After requesting that a cartridge be mounted, the client application may read and write the media using POSIX standard I/O interfaces. Cartridges can also store audio-video streams for broadcast. In either case, OpenVault is not directly involved in I/O operations.
Client applications, libraries, and drives may be added to a live OpenVault server. The system administrator installs new programs on the appropriate hosts, and issues administrative commands on a live system to inform the OpenVault server that these new programs exist.
A library control program (LCP) is a part of OpenVault that deals with low-level details of a removable media library and its configuration and control procedures. There is at least one LCP associated with each OpenVault-managed library.
The OpenVault server issues directives to the LCP in a language called ALI. The LCP replies to the OpenVault server in a language called ALI response (ALI/R).
A drive control program (DCP) manages the configuration of drives, and performs the drive control tasks associated with CAPI mount and unmount requests. There is at least one DCP associated with each OpenVault-managed drive.
The OpenVault server issues directives to the DCP in a language called ADI. The DCP replies to the OpenVault server in a language called ADI response (ADI/R).
The OpenVault Infrastructure Programmer's Guide describes how to program ALI/LCP and ADI/DCP.
This section describes how LCP and DCP modules move from boot to operational state.
When the LCP boots, it reads its configuration file and opens a connection with the OpenVault server. The server decides if the LCP should currently be in control of the library. If so, the OpenVault server tells the LCP that it controls the library. Once control is established, the LCP checks with its library to obtain additional information, such as:
Whether the library is actually of a type supported by this LCP
Whether barcodes or PCLs are supported
List of cartridge form factors (for example, DLT)
Total number of slots in the library
Total number of occupied slots
Import/export port configuration
Slotmap (barcode-to-slot-location mapping)
Other information that is relevant to the LCP
The LCP retrieves any stored state or configuration information from the OpenVault catalog (such as the error message log level). The LCP sends the OpenVault server its current slotmap and drive inventory so that the catalog can be updated, if necessary. At this point, the library can accept mount and unmount commands from OpenVault.
DCP booting is similar to LCP booting: the difference is that the LCP has an inventory list and the DCP has a capability list.
When the DCP boots, the DCP also reads its configuration file and opens a connection with the OpenVault server. The server adds the drive into its managed drive list and establishes whether the DCP has sole ownership of the drive or shares it with another DCP. If a drive is simultaneously connected to more than one host, the OpenVault server must decide which DCP (on which host) has control of the drive (the server can transfer control to another connected host on demand). Once the control is established, the DCP checks with its drive to obtain additional information, such as:
Whether the drive is actually of a type supported by this DCP
Supported media formats (for example, EXABYTE-8mm-5GB)
Whether the listed access modes are supported
Whether a cartridge is loaded in the drive
To verify or acquire any other information that is relevant to the DCP
The DCP retrieves any stored state or configuration information from the OpenVault catalog (such as the error message log level). The DCP passes its capability list to the OpenVault server. The DCP sends the server its capability list so that the OpenVault catalog can be updated, if necessary.
 | Note: OpenVault applications must run on the same host as the OpenVault DCP client attached to the drive(s) employed by that application. This may or may not be the same host as the OpenVault server and LCP client. |
On IRIX systems, use the inst command (or comparable command) to load OpenVault software. If you choose the default installation, all server software, administrator and user commands, DCPs and LCPs, and man pages will be installed. To customize your installation, see Chapter 2, “Installing OpenVault”.
On SGI ProPack for Linux, use the rpm command to install OpenVault software. The openvault-sw package contains all server software, administrator and user commands, DCPs and LCPS, and man pages.
For more detailed information and recommended procedures for OpenVault installation, see Chapter 2, “Installing OpenVault”.
On IRIX systems, to remove OpenVault software or individual components, use the versions command; see the versions(1M) man page. The following command removes all OpenVault software, databases, configuration files, and log files::
# versions remove OpenVault # rm -rf /var/opt/openvault # rm -rf /usr/openvault |
To remove OpenVault software from SGI ProPack for Linux systems, use the rpm command. On SGI ProPack for Linux systems, OpenVault databases, config files, and logs are created in /var/opt/openvault and OpenVault executables are installed in /opt/openvault.
OpenVault stores and manipulates information on cartridges throughout their life cycles, and includes tools for the administrator to manage and monitor this information. For more information on this topic, see Chapter 3, “Cartridge Life Cycle”.
The life cycle of a cartridge is the chain of states and events which affect a cartridge from the time that it first becomes part of a system until in ceases to be a part of that system. The major events in the life of a cartridge include the following:
Physical and logical introduction of the cartridge into the system
Assignment of ownership (who or what application gets to use the cartridge)
Use of the cartridge by applications
Recycling of a cartridge when one owner no longer needs it
Disposal of the cartridge either by sending it to another system or removing it for disposal when the media reaches the end of its service life