Requirements for disk systems

Review the following Tivoli Storage Manager requirements for disk devices and compare them with information from your disk system vendor. A list of supported disk storage devices is not available. Contact the vendor for your disk system if you have questions or concerns about whether Tivoli Storage Manager requirements are supported. The vendor should be able to provide the configuration settings to meet these requirements.

I/O operation results must be reported synchronously and accurately. For the database and the active and archive logs, unreported or asynchronously reported write errors that result in data not being permanently committed to the storage system can cause failures that range from internal processing errors to the inability to restart the server. Depending upon the error, the result could be the loss of some or all stored data.

Data in Tivoli Storage Manager storage pools, database volumes, and log volumes must be interdependent. Tivoli Storage Manager requires that the data written to these entities can be retrieved exactly as it was written. Also data in these entities must be consistent with one another. There cannot be timing windows in which data that is being retrieved varies depending on the way that an I/O system manages the writing of data. Generally, this means that replicated Tivoli Storage Manager environments must use features such as maintenance of write-order between the source and replication targets. It also requires that the database, log, and disk storage pool volumes be part of a consistency group in which any I/O to the members of the target consistency group are written in the same order as the source and maintain the same volatility characteristics. Requirements for I/O to disk storage systems at the remote site must also be met.

Database write operations must be nonvolatile for active and archive logs and DISK device class storage pool volumes. Data must be permanently committed to storage that is known toTivoli Storage Manager Tivoli Storage Manager has many of the attributes of a database system, and data relationships that are maintained require that data written as a group be permanently resident as a group or not resident as a group. Intermediate states produce data integrity issues. Data must be permanently resident after each operating-system write API invocation.

For FILE device type storage pool volumes, data must be permanently resident following an operating system flush API invocation. This API is used at key processing points in the Tivoli Storage Manager application. The API is used when data is to be permanently committed to storage and synchronized with database and log records that have already been permanently committed to disk storage.

For systems that use caches of various types, the data must be permanently committed by the write APIs for the database, the active and archive logs, and DISK device class storage pool volumes and by the flush API (for FILE device class storage pool volumes). Tivoli Storage Manager uses write-through flags internally when using storage for the database, the active and archive logs, and DISK device class storage pool volumes. Data for the I/O operation can be lost if nonvolatile cache is used to safeguard I/O writes to a device and the nonvolatile cache is battery protected. If there is a power loss and power is not restored before the battery is exhausted, then data can be lost. This would be the same as having uncommitted storage resulting in data integrity issues.

To write properly to the Tivoli Storage Manager database, to active and archive logs, and to DISK device class storage pool volumes, the operating system API write invocation must synchronously and accurately report the operation results. Similarly, the operating system API flush invocation for FILE device type storage pool volumes must also synchronously and accurately report the operation results. A successful result from the API for either write or flush must guarantee that the data is permanently committed to the storage system.

These requirements extend to replicated environments such that the remote site must maintain consistency with the source site in terms of the order of writes; I/O must be committed to storage at the remote site in the same order that it was written at the source site. The ordering applies to the set of files that Tivoli Storage Manager is writing, whether the files belong to the database, recovery log, or storage pool volumes. Tivoli Storage Manager can recover from incomplete I/O scenarios if the ordering of writes is consistent between the source and target site.

To avoid having the Tivoli Storage Manager server at the local and remote site losing synchronization, the server at the remote site should not be started except in a fail-over situation. If there is a possibility that data at the source and target locations can lose synchronization, there must be a mechanism to recognize this situation. If synchronization is lost, the Tivoli Storage Manager server at the remote location must be restored by conventional means by using Tivoli Storage Manager database and storage pool restores.

Tivoli Storage Manager supports the use of remote file systems or drives for reading and writing storage pool data, database backups, and other data operations. Remote file systems in particular might report successful writes, even after being configured for synchronous operations. This mode of operation causes data integrity issues if the file system can fail after reporting a successful write. Check with the vendor of your file system to ensure that flushes are performed to nonvolatile storage in a synchronous manner.