HA Alerts

Note the following HA limitations:

• HA is currently only supported in routing mode.

• HA does not work on x86 machines running Solaris 7.

• Screens in an HA cluster do not exchange state information, they independently accumulate state by processing the same packets. For optimal performance, whenever possible, it is recommended that an HA cluster comprise systems of equal size (same CPU speed, and memory size). A slower Screen in passive mode can fall behind in processing and eventually fail to have the same state as the active Screen.

• To reinstate a repaired Screen back into an HA cluster, install it as a secondary Screen and add it to the cluster.

It is not necessary to switch back to the original Screen except when its abilities or speeds are better. If they are, you can force the faster machine to take over as the active Screen, or wait until both machines have the same state because eventually the out-of-sync connections will timeout and become synchronized, then force the failover.

• Secrets are sent in the clear on the dedicated HA network. This is done intentionally to facilitate administrative communication within the HA cluster. Reserve the HA interface as a separate network from other traffic to avoid the possibility of the Screen's private certificates being discovered.

• Each Screen in an HA cluster must have a unique nodename and a unique IP address on the dedicated HA network. All other aspects of the Solaris system configurations must be identical on all Screens in the HA cluster. This includes the configuration of all network interfaces (other than the HA interface).

• HA does not work well with proxies because proxy state tables are not present on all HA machines.

• The HA Screens must be connected to each other through a shared network (such as a 10BaseT or 100BaseT hub) and not through a switched network (such as an Ethernet switch because it would send each packet to only one HA Screen, rather than to all of them).

• HA cannot be used on networks that use media other than Ethernet, such as FDDI, Token-Ring, or ATM.

• Because passive HA hosts do not generate traffic (other than automatic administrative traffic, such as HA administration and HA heartbeat), you cannot telnet into passive HA Screens. You can telnet into an active HA Screen only.

• In general, the HA cluster decides internally which member will be the active Screen. If you need to remotely administer the HA cluster, you may first need to connect to the secondary Screen and direct it to become passive so that you can communicate with the primary Screen.