RDF System Management Manual

Preparing the RDF Environment
HP NonStop RDF System Management Manual—524388-003
2-12
Using SMF With RDF
Using SMF With RDF
RDF supports the full use of SMF on both the primary and backup nodes.
There are two basic ways to configure SMF logical volumes:
•
Map many physical disks to a single virtual disk
Create SMF pools where each is comprised of many physical volumes and create
SMF virtual disks from these pools. In this configuration, the files on any given
virtual disk will be spread across multiple physical disks allowing you to pool
together many physical disks to create a very large virtual disk.
•
Map many virtual disks to a single physical disk
Create SMF pools where each is comprised of a single physical disk and create
SMF virtual disks from these pools. In this configuration, all the files on a given
virtual disk reside on one physical disk allowing you to have a very large physical
disk volume subdivided into a number of smaller logical volumes. In this way it is
possible to have multiple partitions of a file residing on a single physical volume,
with each partition of the file stored on a different logical volume.
Both of these configurations are supported by RDF. There are some restrictions when
using SMF on the backup system which are described in detail later in this section.
Configuring an SMF Environment on the Primary System
When configuring an SMF environment on an RDF primary system, make sure that
SMF catalog files are not replicated by RDF to the backup system. The SMF catalogs
on the primary and backup systems must remain independent of each other. There are
three ways to do so:
•
Place the SMF catalog on a primary system volume that is not protected by RDF.
The extractor ignores any audit generated by disks outside the RDF configuration,
and hence will not replicate any changes to the SMF catalog on the primary
system. With this option, you can store the catalog in either the default SMF
catalog subvolume or your own subvolume.
Note. A single updater process can only work on 500 files at any time. If you have a
virtual disk that has a number of physical disks in its pool, and if the number of files that
need to be updated by the updater assigned to that virtual disk exceeds 500, the updater
will close some files in order to work on files it does not already have open. If this updater
must regularly work on more than 500 files, the performance of the updater will be
impacted. For optimal updater performance, you should ensure that no single updater has
to work on more than 500 files on a regular basis. This might mean that you have to
reduce the number of physical disks in a pool.