High Availabilty is a SunScreen configuration consisting of a Primary Screen and a Secondary Screen or Screens that mirror the operations on the Primary; in this way the HA configuration behaves as a single system. Should anything cause the Primary Screen to fail, the Secondary immediately takes over, providing uninterrupted operation. This chapter describes Setting up High Availability SunScreens; you can also find a detailed example of an HA configuration in the SunScreen Configuration Examples manual.
To use High Availability (HA), you must install SunScreen as an HA system as described in the SunScreen Installation Guide. High Availability, its limitations, topology and set up, and capability are described in detail in the SunScreen Reference Manual manual.
HA lets you deploy multiple Screens together in situations where the connection between a protected inside network and a nonsecure outside network is critical. One member of the HA cluster, the active HA Screen, performs packet filtering, network address translation, logging, and encryption/decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, which can be as many as 31 passive HA Screens, receive the same packets, perform the same calculations as the active HA Screen, and mirror the state of the active HA Screen, but they do not forward traffic between the inside network and the outside network. If the active HA Screen fails, one of the passive HA Screens takes over (failover) as the active HA Screen and begins routing and filtering network traffic within seconds. Because the passive HA Screens mirror the active HA Screen, few connections are lost if a failover occurs.
When you set up an HA cluster, you designate one Screen as the Primary HA Screen, and you configure it with the common objects and policy rules the HA cluster will use. When you activate the policy, it is copied from the Primary HA Screen to the other members of the HA cluster. The Solaris system and network configuration are not copied from the Primary HA Screen, and must be identical on all the Screens in the HA cluster.
Keep the HA network physically secure because the HA cluster transmits secret keys and policies in the clear over the dedicated HA network.
The interfaces for network connections must be the same for each HA cluster member. For example, if one HA host uses the le0 interface as its dedicated internal network connection, all HA hosts must use the le0 network interface as the dedicated internal network connection. Similarly, you must assign Screens in the HA cluster the same IP addresses on their non-dedicated interfaces.
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.
You cannot connect to a passive HA Screen directly except with remote administration to the HA interface. You also cannot connect from one HA Screen to another except with remote administration to the HA interface. You can allow:
Heartbeat (the communication between or among HA Screens to assure that the dedicated HA network is working)
Adding additional services or service groups might be useful, for example, if you need to copy Solaris system files between the HA hosts or to be able to log into the active HA Screen remotely and then connect to the Primary administration HA host using telnet. Adding a service to the HA service group circumvents the passive HA mode and allows the traffic that the added service permits through the SunScreen filters.
You can add any services to the HA service group by selecting Service in the Type choice list on the Edit Policy page, save the change, and reactivate the configuration.
The services or service groups that you add to the HA service group are only allowed between the HA hosts.
Depending on the configuration for NAT that you are using, you must add an ARP (Address Resolution Protocol) entry for static NAT mappings on all Screens in Routing mode, active and passive, so that NAT will work after a fail-over. You must replicate all non-SunScreen configurations, including static ARP entries on all HA Screens. Because you must do this every time an HA Screen fails over or every time you reboot a Screen, it is easier if you automate this in one of your start-up scripts. For more information on configuring NAT, see the SunScreen Reference Manual, and for more information on ARP, see the man page for arp.
Configure identical interfaces on all HA machines, by editing the /etc/inet/hostname.interface-name file or running the ifconfig command.
Dedicate one interface on each machine to HA.
You must have a dedicated network between the HA hosts that, for reasons of security, is not connected to any other network.
All the HA machines must be configured with the same interface names and be connected to the network and to each other in the same way.
The dedicated HA interface must have a unique address name and IP address. (This is so that the configurations, including interface configurations, can be synchronized later.)
Connect the HA interfaces of the HA machines one at a time after installing the operating system (if necessary) and configuring the routing on these machines.
Since the HA hosts have the same names and IP addresses, you must connect the non-HA interfaces of only one of the HA machines, for example, HA1 as shown by the solid line in Figure 6-1. This machine will become the Primary and active HA Screen. (This approach prevents confusion from arising in the routing and ARP tables on the active HA Screen. After the HA configuration is complete, the HA software keeps the routing and ARP tables orderly.) You connect the secondary Screen, for example, HA2 as shown by the broken line in Figure 6-1, to the hubs after you have installed, configured, and tested the Primary, active HA Screen and after you have installed and configured the Secondary HA Screen
You do not have to install any special software for HA other than installing SunScreen. The HA software is automatically installed as part of SunScreen.
Install SunScreen on the Secondary HA Screen.
Accept default settings on all install screens except for the Secondary HA Configuration dialog window:
Select YES. The Secondary HA Data dialog window appears.
In the Secondary HA Data dialog window:
Click the OK button.
The Secondary HA Configuration dialog window appears.
Reboot the Secondary HA Screen.
The dedicated HA interface can be any interface on the Screen which has been plumbed and is not defined as a screening interface. To define an HA interface, perform the following steps:
From the Common Objects area, Select interface from the Type choice list.
Click the Search button.
Select the interface name which you want to dedicate to HA and click Edit.
If the interface does not appear, select New... from the Add New choice list.
Define the interface, selecting HA as the Type.
Click the OK button.
From the Common Objects are, select Screen in the Type choice list.
Click and highlight the name of the Screen that you want as the Primary HA Screen then, click the Edit button.
If the Screen object is not yet defined for the Primary Screen, select New... from the Add New choice list and enter the name of the Primary Screen in the Name field.
Click the Primary/Secondary tab.
Select Primary in the High Availability field.
Enter the IP address of the Primary Screen's dedicated HA interface in the High Availability IP Address field.
Enter the ethernet address of the interfaces on the Primary Screen in the Ethernet Address field.
Click the OK button.
Log in to the SunScreen Administration GUI.
Go to the Policies List page.
In the Policies List page, click on Initialize HA.
The Initialize HA dialog window appears.
Choose the interface to be the HA interface from the Interface choice list.
The HA interface on the Primary HA Screen and Secondary HA Screen must be the same.
Click the OK button
The Policies List page appears.
Click the Edit button on the Policies List page.
The Policy Rules page appears.
Select Screen from the Type choice list.
Select New... from the Add New choice list.
The Screen dialog window appears.
Enter the name of the Secondary HA Screen in the Name field.
Click the Primary/Secondary tab in the Screen dialog window.
Enter the following in the Primary/Secondary area of the Screen dialog window:
Click the OK button.
Click the Save Changes button on the Policies List page.
The Activate Policy dialog window appears.
Fully connect the Secondary HA Screen to the network.
After adding an HA Secondary Screen and activating your policy, the new Secondary Screen may become active. If you need to perform additional administration on the Primary Screen, you must direct the Secondary Screen to become passive in order to communicate with the Primary Screen.
Configure the service and policy rules on the Primary HA Screen.
All changes made on the Primary HA Screen are automatically copied to all Secondary HA Screens.
Save and Activate the policy.
You configure the HA cluster just as you configure a single Screen. Policy Rules for passive HA Screens are configured when they connect to the primary HA Screen. You should write a rule for connecting to the unique address of each host in the HA service group.
Updates to the Primary HA Screen are automatically relayed to all the other HA Screens. This synchronization takes place during activation. When a configuration is activated, the primary HA Screen transfers the configuration, including certificates, local keys, addresses, policy rules, and the like, to all other Secondary HA Screens.
When an HA host is in the passive mode, it is impossible to connect to that host directly, except with remote administration to the HA interface. This also applies to connections from one HA host to another on the HA interface.
You can allow other services (other than the standard HA service or remote administration and heartbeat). These services will only be allowed between the HA hosts. Add them to the HA service group by selecting Service in the Type choice list on the Edit Policy page, and add the services you want to include.
Adding these services to the HA service group permits you to circumvent the passive HA mode and allows the traffic through the SunScreen filters even when the host is in the passive mode.
You can upgrade SunScreen EFS 2.0 and 3.0 HA clusters to SunScreen 3.1. There is an upgrade script to aid the transition from EFS 3.0 to SunScreen 3.1. The Upgrade from EFS 2.0 is a more manual process. Please see the SunScreen Installation Guide for upgrade information.
Removing HA involves removing both software and hardware. Simply disabling the HA configuration is insufficient and is only one part of the process. Because there is more than one Screen that has the same IP address on the network, simply disabling HA leaves two or more HA Screens on the network that are trying to route the same traffic. This would disrupt the network traffic through the Screens.
You should remove the HA hosts one at a time to reduce the chances of disrupting the network. If you remove the active HA host, you could lose some connections. If you are removing a passive HA host, no connections will be lost. You should, therefore, remove the passive HA host or hosts first to avoid losing connections.
If you must remove the active HA host, find out if any connections may be lost by running the following command on the active HA host that you want to remove and on the passive HA host that will become the active HA host after you remove the active HA host.
For local administration:
# ssadm lib/statetables
For remote administration:
# ssadm -r <Name_of_Screen> lib/statetables
If the statetables are in an acceptable level of synchronization, you can proceed to remove the active HA host.
Information about the HA Screen is not shown as such in the Log Browser.