System information

Chapter 8. HMC duplication and redundancy 249
8.4 Redundant HMC configuration considerations
In a redundant HMC configuration, both HMCs are fully active and accessible at all times,
enabling you to perform management tasks from either HMC at any time. There is no primary
or backup designation.
Both HMCs can be used concurrently. You have to consider the following points:
򐂰 Because authorized users can be defined independently for each HMC, determine
whether the users of one HMC should be authorized on the other. If so, the user
authorization must be set up separately on each HMC.
򐂰 Because both HMCs provide Service Focal Point and Service Agent functions, connect a
modem and phone line to only one of the HMCs and enable its Service Agent. To prevent
redundant service calls, do not enable the Service Agent on both HMCs.
򐂰 Perform software maintenance separately on each HMC, at separate times, so that there
is no interruption in accessing HMC function. This allows one HMC to run at the new fix
level, while the other HMC can continue to run at the previous fix level. However, the best
practice is to upgrade both HMCs to the same fix level as soon as possible.
The basic design of HMC eliminates the possible operation conflicts issued from two HMCs in
the redundant HMC configuration. A locking mechanism provided by the service processor
allows inter-operation in a parallel environment. This allows an HMC to temporarily take
exclusive control of the interface, effectively locking out the other HMC. Usually, this locking
is held only for the short duration of time it takes to complete an operation, after which the
interface is available for further commands.
Both HMCs are automatically notified of any changes that occur in the managed systems, so
the results of commands issued by one HMC are visible in the other. For example, if you
choose to activate a partition from one HMC, you will observe the partition going to the
Starting and Running states on both HMCs.
The locking between HMCs does not prevent users from running commands that might seem
to be in conflict with each other. For example, if the user on one HMC activates a partition,
and a short time later a user on the other HMC selects to power the system off, the system
will power off. Effectively, any sequence of commands that you can do from a single HMC is
also permitted when it comes from redundant HMCs.
For this reason, it is important to consider carefully how to use this redundant capability to
avoid such conflicts. You might choose to use them in a primary and backup role, even
though the HMCs are not restricted in that way. The interface locking between two HMCs is
automatic, usually of short duration, and most console operations wait for the lock to release
without requiring user intervention. However, if one HMC experiences a problem while in the
middle of an operation, it may be necessary to manually release the lock.
When running two HMCs to the same server, you should also be careful with long running
functions, as they may be impacted if they have not completed before an additional function is
run on the second HMC.