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.
•
Place the SMF catalog in the default SMF catalog subvolume on a volume that is protected
by RDF.
The extractor automatically filters out changes to the SMF catalog if the catalog is in the
default SMF catalog subvolume. If you store the catalog in your own subvolume, the extractor
will try to replicate changes to the catalog, which could have an adverse affect on RDF and
any SMF catalogs with the same subvolume name on the backup system.
•
Place the SMF catalog in a subvolume that is explicitly excluded from RDF protection.
INCLUDE and EXCLUDE clauses are described in
Chapter 11 (page 279)
.
Configuring an SMF Environment on the Backup RDF System
RDF supports the replication to SMF logical volumes on the backup system, with the following
restrictions:
•
When replicating to an SMF logical volume, the logical volume must belong to an SMF pool
that contains 15 or fewer physical volumes, hence each updater can apply audit to up to 15
physical disks.
•
The RDF/IMP product limits the total number of physical or virtual UPDATE volumes to
255. RDF/IMPX and ZLT have no such limitation, other than the limit of 255 updaters and
each updater only being able to work on a maximum of 15 physical volumes.
•
Image trail volumes cannot reside on SMF logical volumes.
There are no restrictions on the placement of SMF catalog files on the backup system. If the
backup system could ever become a primary (such as after an RDF takeover, for example, or as
the result of a planned switchover), then the restrictions described in the preceding topic for
primary systems also apply.
NOTE:
A single updater process only works on 3000 files at any time. If you have a virtual disk
that has many 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 3000, 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
3000 files, the performance of the updater is impacted. For optimal updater performance, ensure
that no single updater must work on more than 3000 files on a regular basis. This condition might
mean that you have to reduce the number of physical disks in a pool.
RDF replicates Enscribe file creations when audited Enscribe files are created on RDF protected
volumes. When the UPDATEVOLUME is a virtual disk, the updater process tells SMF to create
the file and register it in the SMF catalog. When the UPDATEVOLUME is a virtual disk consisting
of multiple physical disks, SMF decides which physical disk will store the file. You have no
control over where a new Enscribe file is created. For more information about the factors SMF
uses to decide on the file placement, see the Storage Management Foundation User's Guide .
You can change the physical volume on which files reside in the SMF pool using the FUP
RELOCATE command. This command only works on closed files, so the updaters must be
stopped before relocating any files.
66
Preparing the RDF Environment
Содержание NonStop RDF
Страница 68: ...68 ...
Страница 186: ...186 ...
Страница 260: ...260 ...
Страница 278: ...278 ...
Страница 284: ...284 ...
Страница 290: ...290 ...
Страница 308: ...308 ...
Страница 322: ...322 ...
Страница 336: ...336 ...
Страница 348: ...348 ...
Страница 464: ...464 ...
Страница 478: ......