Creating remote storage pools on hosts running Linux or the UNIX system

On hosts running Linux or the UNIX system, remote storage pools allow you to distribute VOB storage across multiple physical volumes or hosts.

On hosts running Linux or the UNIX system, which support symbolic links to file systems on other hosts running Linux or the UNIX system or to NAS devices, you can distribute a VOB's storage pools to provide additional VOB storage capacity. These remote pools can be on another host (which need not have HCL VersionVault installed) or on another disk partition on the VOB host.

There are several requirements to consider when deciding whether to use remote storage pools:
  • Backup and recovery can be more complicated for a VOB that uses remote storage pools. See If the VOB has remote storage pools.
  • VOB tags for VOBs with remote storage pools must include additional information if they are to be accessed by Windows® computers. See Windows tags for VOBs on Linux or the UNIX system with remote storage pools.
  • The remote location must be accessible over the network by all hosts that use the VOB. A remote host with multiple network interfaces (and multiple host names) might not work in this role.
  • Unless the entire VOB storage directory is located on a NAS device, the VOB database (db subdirectory) must be a subdirectory of the VOB storage directory. It cannot be a symbolic link to a directory on another computer.
When deciding which hosts to use for new storage pools, consider that each kind of storage pool has a different pattern of use:
  • Source pools. These pools store the most critical data: checked-in versions of file elements. Traffic to and from these pools is relatively light, but data integrity is very important. Source storage pools should be kept within the VOB storage directory. This strategy optimizes data integrity: a single disk partition contains all of the VOB's essential data. It also simplifies backup and restore procedures. These concerns typically override performance considerations, because losing a source pool means that developers must re-create the lost versions. If you decide to use remote source pools, choose a robust file server for which you provide frequent, reliable data backups.
  • Cleartext pools. These pools probably get the heaviest traffic (assuming that many of your file elements are stored in delta or compressed format), but the data in them is expendable, because it can be reconstructed from the data in the source pools. The ideal host for cleartext pools is a computer with a fast file system.
  • Derived object pools. These pools can become quite large if derived objects are maintained for numerous releases and platforms. Derived objects, like cleartext, can usually be regenerated from the information in the VOB database and source pools, but regeneration of earlier derived objects can sometimes be difficult.
    Note: If you check in a derived object, it becomes a versioned object and is no longer stored in a derived object pool.