Because the passive HA Screens do not forward, reject, or log packets, the CPU and I/O load on the passive HA Screens is less than that of the active host. This reduces the probability that software or load-induced faults affecting the active HA Screen will affect the passive hosts as well.
The machines that are used as the HA Screen should all be of equivalent power, so that the passive HA Screen can keep up with nearly all the processing of the active HA Screen.
No traffic is allowed out of the passive HA Screens with the exception of administration traffic, such as normal GUI administration, HA administration, and HA heartbeat (the communication signal on the dedicated network that assures that the network is working). This means, for example, that you cannot use telnet to connect to the passive HA hosts. You can, however, use telnet to connect to active HA hosts.
When you configure the hostname resolution in the /etc/nsswitch.conf file for HA hosts, the key word files must appear first in the "hosts line," because:
An HA Screen in the passive mode cannot send packets over the network; therefore, remote hostname resolution, such as DNS or NIS, will fail for passive HA Screens.
The Primary HA Screen manages Secondary HA Screens in an HA cluster. A passive HA Screen within a HA cluster mirrors the state of the active Screen, which can be the Primary or a Secondary HA Screen. When the active Screen fails, the passive Screen that has been running the longest takes over as the active Screen. Primary means the system is the HA administration host for the HA configuration. It does not mean that it is the active host, necessarily.
You must use the unique HA interface address for administration. If one of the shared addresses is used, then that address will always resolve to the HA Screen that is currently active. Since the active host is not necessarily the Primary administration host, there is no other way to ensure that you are communicating with the correct host.
If you do not do this, then, if the remotely administered Primary HA Screen is shut down, the connection will be lost and the administration GUI will hang immediately. You can still administer the active HA Screen from the command line, using the command ssadm, but you will be unaware that you are administering a Secondary HA Screen that will not propagate the configuration to any other HA Screen. The configuration gets overwritten when the Primary HA Screen is up again.