OSI/MHS Configuration and Management Manual
Planning Your OSI/MHS Subsystem
OSI/MHS Configuration and Management Manual—424827-003
3-17
High Performance
Each group has its own PDU store as a separate database, which you can configure to
reside on several disk volumes.
All the groups in the OSI/MHS subsystem are controlled by a single MHS manager
process and they can all use the same OSI/AS services. Each subsystem represents
one MTA. From an external view, an adjacent MTA does not know to which of the
groups it is connected.
You can configure several MTAs (OSI/MHS subsystems) on the same system.
Some possibilities you may want to consider when planning your configuration are:
•
Segregating incoming associations from a particular group of users on a particular
MR group or MR groups.
•
Spreading the load among multiple MR groups. For example, one MR group can
handle up to 20 associations; however, if you have five MR groups you might
improve performance by having each group listening on a different OSI address
and handling up to four associations.
•
Configuring each adjacent MTA to call on a different address (or you may want
them all to call on the same address).
High Performance
You can affect the performance level of OSI/MHS by carefully considering how you
configure the location of groups and other configuration parameters. The system is
designed to allow for flexibility in configuration so as to avoid bottlenecks that could
limit throughput.
Section 8, Sizing and Tuning Your OSI/MHS Subsystem, discusses some performance
considerations for OSI/MHS.
Fault Tolerance
The MHS manager runs as a NonStop process pair; it ensures fault-tolerant operation.
Individual groups are not run as NonStop process pairs. If a group or a processor
running that group fails, the MHS manager restarts the group, recovers any operations
in progress, and restarts the message processing in that group.
With multiple groups, the failure of any group or CPU does not affect the MTA function.
Other groups provide a fully functioning MTA throughout restart and recovery
procedures.
Data Integrity
All the OSI/MHS databases are protected by TMF. Also, extensive logging occurs at
various stages throughout message transfer and processing. Putting your entire
subsystem on mirrored disks also ensures data integrity. OSI/MHS is designed never
to lose a message and therefore provides complete data integrity.