OpenVault helps simplify the engineering of software to control removable media libraries, by providing standard interfaces for robotic libraries, loadable drives, client applications, and library administration.
This chapter describes in more detail what this product provides and why it is useful, and gives an overview of OpenVault architecture and its standard interfaces.
OpenVault is a package of mediation software that helps other applications manage removable media. This facility can support a wide range of removable media libraries, as well as a variety of drives interfaced to these libraries. The modular design of OpenVault eases the task of adding support for new robotic libraries and drives.
A unit of removable media is called a cartridge. This could be a tape reel, a tape cartridge, an optical disc, a removable magnetic disk, or a videotape.
OpenVault itself does not provide an end-user interface, nor does it generally become involved in I/O operations to cartridges loaded in drives. User interfaces are provided by OpenVault client applications, which perform I/O to drives using system facilities after control programs have mounted and loaded a cartridge for the application.
The following tertiary storage applications can all benefit from OpenVault:
Tape access, for example with tar or cpio
Backup, to guard against system crash or accidental data loss
Archive, for long-term storage of unused data
Hierarchical storage management (HSM)
CD-ROM jukeboxes or information libraries
Broadcast libraries containing videotapes
Because of the proliferation of data, many information professionals have trouble putting their fingers on the data they want. Secondary storage on disk drives is usually near capacity, and is generally devoted to system overhead and working files. Tertiary storage often contains the desired data, but is reachable only after expenditure of time and effort. Attentive management of removable media libraries can enhance the availability of information without significantly increasing overall system cost.
The traditional way of dealing with robotic libraries is with specialized applications that interface to particular libraries and drives. Generally, devices are monopolized by a single application. This approach has several shortcomings:
Manufacturers of robotic libraries and drives have to develop device drivers for each new product on all supported system platforms.
Software vendors must develop additional code to integrate new robotic libraries and drives, resulting in product support delays.
Computer system providers have a difficult time offering a complete range of robotic libraries and applications when customers want them.
Users and administrators have no access to the removable media library except as granted by a specialized application--sharing is not possible.
OpenVault solves these problems by providing a set of standard interfaces that raise the level of abstraction, enabling rapid deployment of removable media libraries, drives, systems, and client applications.
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 using devices from different vendors. OpenVault is middleware in the sense that it mediates between client applications and device control programs, making it possible for different users to share a removable media library.
Middleware can often improve release independence. With its modular architecture, OpenVault assists vendors in adding support for new removable media libraries and drives and delivering upgraded client applications, without requiring rerelease of other OpenVault components.
OpenVault is organized as a set of cooperating components, as shown in Figure 1-1.
The central mediation component is the media library manager (MLM), a multithreaded process that accepts client connections and fulfills access requests by forwarding them to appropriate library and drive control programs. The MLM server maintains persistent storage containing information about cartridges in the system, and descriptions of authorized applications, libraries, and drives.
OpenVault consists of the following pieces:
One MLM server process mediates among other components.
Any number of client applications can make requests using the client application programming interface, CAPI; the MLM server replies in CAPI response (CAPI/R).
An administrative interface makes system requests in a similar but less restricted administrative API, AAPI; the MLM server replies in AAPI response (AAPI/R).
Persistent storage (a database) tracks cartridges and system components.
A library control program (LCP) is required for each removable media library controlled by the MLM server.
The MLM server talks to an LCP using the abstract library interface (ALI), and receives answers in ALI response (ALI/R). An LCP translates from ALI to the actual library control interface, and replies in ALI/R.
A drive control program (DCP) is required for each drive controlled by the MLM server. Some removable media libraries contain multiple drives, in which case each drive has its own DCP. Drives need not be associated with a robotic library.
The MLM server talks to a DCP using the abstract drive interface (ADI), and receives answers in ADI response (ADI/R). A DCP translates from ADI to the actual drive control interface, and replies in ADI/R.
The OpenVault languages consist entirely of ASCII strings.
The MLM 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. MLM also schedules competing requests from different applications, creates and enforces cartridge groups for each application, and maps logical cartridge names (used by applications) to physical cartridge labels (used by libraries).
The MLM 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, MLM is not directly involved in I/O operations.
Client applications, libraries, and drives may be added to a live MLM server. The system administrator installs new programs on the appropriate hosts, and issues administrative commands on a live system to inform the MLM server that these new programs exist.
Client applications may choose their own names for cartridges. Because OpenVault client applications operate in separate name spaces, different applications may use the same name for different cartridges. Moreover, cartridges used by one application are not visible to or accessible from another application, unless the system administrator permits specific cartridges to be moved from one application to another.
Some robotic libraries can interpret barcodes and labels affixed to cartridges. It is the responsibility of the LCP to pass any physical cartridge label (PCL) information to the MLM server.
The OpenVault languages CAPI, CAPI/R, AAPI, AAPI/R, ALI, ALI/R, ADI, and ADI/R are expressed exclusively in text strings, which travel between components by means of TCP sockets. The underlying communications layer is encapsulated in a C library; so OpenVault developers need not worry about the details.
This section describe the various OpenVault programming interfaces.
CAPI (client application programming interface) is the language client applications use to communicate with the MLM server.
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. CAPI communications libraries can also work synchronously if this makes implementation more convenient.
Access to the server is session-oriented. The application initiates a session with the hello command, and ends with a goodbye. Meanwhile, the application may send commands to the server to mount and unmount removable media, or to change attributes of media.
Here is a list of CAPI commands organized alphabetically:
allocate requests volumes for use by this application.
attribute sets attribute-value pairs associated with OpenVault volumes.
deallocate returns volumes to the free pool.
mount asks the MLM server to provide volumes for data access.
reject tells the server to recategorize a volume.
rename declares a new name for a volume.
show displays information about OpenVault volumes.
unmount says that volumes are no longer needed for data access.
unwelcome informs the client of an MLM server version mismatch.
welcome tells the client which version of the MLM server is responding.
The OpenVault Application Programmer's Guide describes how to program CAPI.
AAPI (administrative API) is the language that administrative applications use to communicate with the MLM server. AAPI commands and responses are ASCII strings. As with CAPI, the command-response format is semi-asynchronous, and access to the server is session-oriented. AAPI is a superset of CAPI.
Here is a list of AAPI commands organized alphabetically:
attribute sets attribute-value pairs associated with OpenVault volumes.
create establishes a volume or object in the OpenVault database.
delete removes a volume or object from the OpenVault database.
eject pushes a cartridge out of a library into the operator's hand.
export removes a volume from the OpenVault database.
inject allows the operator to insert a cartridge into a library.
mount tells the MLM server to provide data access to a volume.
move relocates a cartridge from one slot in a library to another.
rename declares a new name for a volume.
show displays information about OpenVault volumes.
unwelcome informs the client of an MLM server version mismatch.
unmount says that volumes are no longer needed for data access.
welcome tells the client which version of the MLM server is responding.
The OpenVault Application Programmer's Guide describes how to program the AAPI.
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 MLM-managed library. The purpose of an LCP is to expose library configuration to the MLM server, and to control a library as requested.
The MLM server issues directives to the LCP in a language called ALI. The LCP replies to the MLM server in a language called ALI response (ALI/R).
ALI/R implements a different command set from ALI, reflecting different needs of an LCP and the MLM server. The ALI language is primarily a library control interface, whereas ALI/R constitutes a status reporting interface with support for administration and configuration. Like CAPI, ALI and ALI/R are semi-asynchronous.
If you are developing a library control program, your program must be able to read ALI from, and write ALI/R to, the MLM server. The OpenVault infrastructure developer's kit includes an ALI parser and ALI/R generator. The parser and generator, as well as the communications layer, are delivered with a C language interface.
The OpenVault Infrastructure Programmer's Guide describes the ALI and ALI/R languages, and offers an introduction to creating library control programs.
Here is a list of ALI commands organized alphabetically:
activate disable forces the LCP to stop talking to the library.
activate enable forces the LCP to resynchronize its internal information with the physical state of the library, and keep it synchronized.
attribute sets and unsets named attributes in the LCP.
barrier tells the LCP to complete all asynchronous commands before continuing.
cancel revokes a command that the LCP has queued but not yet started.
eject pushes a cartridge out of the library immediately, or queues a cartridge to be pushed out of the library (if queueing is implemented).
exit tells the LCP to store state information, clean up, and exit.
mount asks the LCP to put cartridges into drives.
move requests transfer of a cartridge from one physical slot into another.
openPort instructs the LCP to open the library door, so that cartridges can be added to or removed from the library.
reset instructs the LCP to reinitialize its library.
scan has the LCP ask its library to verify physical labels of cartridges in the library.
show obtains the current value of an attribute.
unmount tells the LCP to take cartridges out of drives.
Here is a list of ALI/R commands organized alphabetically:
attribute sets and unsets named attributes in the OpenVault database.
cancel prevents execution of a command that has been queued but not yet started.
config copies information (such as slot state) from the LCP to the MLM server.
goodbye asks MLM to end this session (vice versa for ALI).
message sends a message of a specified severity level to an operator or logfile.
ready tells the MLM server about library status for cartridge operations.
response indicates success or failure of an ALI command, and returns results.
show obtains values of attributes stored in the OpenVault database.
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 MLM-managed drive. The purpose of DCP is to expose the drive configuration to the MLM server, and to control drives as requested.
The MLM server issues directives to the DCP in a language called ADI. The DCP replies to the MLM server in a language called ADI response (ADI/R).
ADI/R implements a different command set from ADI, reflecting different needs of a DCP and the MLM server. The ADI language is primarily a drive control interface, whereas the ADI/R language constitutes a status reporting interface with support for administration and configuration. Like CAPI, ADI and ADI/R are semi-asynchronous
If you are developing a drive control program, your program must be able to read ADI from, and write ADI/R to, the MLM server. The OpenVault infrastructure developer's kit includes an ADI parser and ADI/R generator. The parser and generator, as well as the communications layer, are delivered with a C language interface.
The OpenVault Infrastructure Programmer's Guide describes the ADI and ADI/R languages, and offers an introduction to creating drive control programs.
Here is a list of ADI commands organized alphabetically:
activate disable forces the DCP to store persistent state and stop communicating with its hardware.
activate enable forces the DCP to resynchronize with its drive hardware, ensuring that the DCP has the current drive state.
attach selects the appropriate access method, and binds it to a drive handle.
attribute sets and unsets named attributes in the DCP.
barrier tells the DCP to complete all asynchronous commands before continuing.
cancel requests the DCP to stop execution of a command, if possible.
detach removes the access method binding created by an attach command.
exit tells the DCP to store state information, clean up, and exit.
load pushes a cartridge into the drive and engages media at the media access point (read/write head), or verifies that the drive is loaded.
reset instructs the DCP to attempt drive reinitialization.
response indicates success or failure of an ADI command, and returns results.
show asks the DCP to return state or configuration information.
unload rewinds if necessary, disengages media from the media access point, and returns media to its cartridge.
Here is a list of ADI/R commands organized alphabetically:
attribute stores persistent state in the OpenVault database.
cancel tells OpenVault to prevent execution of a particular command, if possible.
config tells OpenVault about access modes, form factors, and media formats.
goodbye asks MLM to end this session (vice versa for ADI).
message sends a message of some severity level to an operator or logfile.
ready informs OpenVault of the status of the DCP's connection to the drive.
response indicates success or failure of an ADI command, and returns results.
show queries persistent state stored in the OpenVault database.
OpenVault can be administered with commands given from the system prompt. Most of these commands cause MLM to forward library or drive requests to a particular LCP or DCP. Most OpenVault commands produce helpful usage messages when invoked with the wrong syntax or with the -help option. For a list of OpenVault commands, see the OpenVault Operator's and Administrator's Guide
The user mount shell, umsh, is a system command that provides user and administrator access to OpenVault volumes. See the umsh(1M) man page for details.
 | Note: To access OpenVault man pages, on IRIX systems add /usr/openvault/man to the MANPATH environment variable. On SGI ProPack for Linux systems, add /opt/ openvault/man to the MANPATH environment variable. See man(1) for more information. |