The Administration Console contains an embedded version of eDirectory™, which contains all the configuration information for the Access Manager. It also contains a server communications module, which is in constant communication with the Access Manager modules. If the Administration Console goes down and you have not installed any secondary consoles, your Access Manager components also go down and your protected resources become unavailable.
You can create fault tolerance by installing up to two secondary consoles. We highly recommend that you install at least one secondary console.
For a secure configuration, secondary consoles must be installed on the same network as the primary console. The administration consoles should not be required to use a router to communicate with each other.
The administration consoles must have their time synchronized. The easiest way to ensure this is to configure the machines to use the same network time server for time synchronization.
If you are going to install your clustered Identity Servers on the same machines as your primary and secondary consoles, the Administration Consoles cannot be configured as a virtual group on an L4 switch. For more information, see Managing Administration Consoles Installed on Clustered Identity Servers.
You can install the primary Administration Console and the Identity Server on the same machine, even when the Identity Server is going to assigned to a cluster of Identity Servers. You can install a secondary Administration Console on another member of the Identity Server cluster. The Administration Consoles cannot be configured as a virtual group on an L4 switch, because the L4 switch interferes with the communication process between the Administration Consoles and the Access Manager components. Each Access Manager component knows which Administration Console is its primary console and its secondary console and knows how to communicate directly with each console. The component, rather than an L4 switch, needs to make the decision on which console it needs to contact.
However, traffic destined for a cluster of components (Identity Servers or Access Gateways) can pass through an L4. Figure 4-1 illustrates this configuration, showing Identity Servers on the same machine as Administration Consoles.
Figure 4-1 Identity Server Clustering with a Secondary Administration Console
Install the primary Administration Console and an Identity Server on one machine, using the Administration Console’s IP address when importing the Identity Server component. (See the Novell Access Manager 3.0 SP4 Installation Guide.)
Install the secondary Administration Console and a second Identity Server on another machine, using the primary Administration Console’s IP address when importing the second Identity Server.
Specify the L4 VIP as the DNS for the Identity Server cluster configurations that both Identity Servers use. (See Section 1.3, Creating a Basic Identity Server Configuration.)
Insert the CD containing the Administration Console software.
Most of the installation process is the same for a secondary console as for a primary. For these basic instructions, see Novell Access Manager 3.0 SP4 Installation Guide.
To install a secondary console, answer No to the following prompt:
Is this the primary administration server in a failover group?
When prompted, enter the IP address of the primary console.
Continue with the installation process.
After installing a secondary console, you might have to wait from 30 to 60 minutes before using it. The components query the primary console hourly for information about available consoles, and they reject commands from a console that is not in their approved list. You can force the components to recognize the secondary console by restarting the Integration Agent on each Identity Server, Linux Access Gateway, and Linux J2EE Agent with the following command:
If you have added multiple replicas for any of the user stores, you need to manually add them to the secondary console. See Novell Access Manager 3.0 SP4 Administration Guide.
The primary and secondary consoles use eDirectory synchronization to keep their configuration databases current.
WARNING:As long as the primary console is running, all configuration changes should be made at the primary console. If you make changes at both a primary console and a secondary console, browser caching can cause you to create an invalid configuration.
Access Manager devices use the secondary console only when the primary console is down. Therefore, if a secondary console goes down while the primary console is running, the devices are notified, but they continue as they were, using the primary console for configuration information. The secondary console can be down for as long as required to fix the problem without effecting the other Access Manager devices.
When the primary console goes down, all of the devices discover this and switch to using the secondary console. This can take a few minutes, as each device has its own trigger for checking in with the Administration Console. After the device has switched to using the secondary console, it continues to run just as it did when it was communicating with the primary console. When the primary console comes back on line, all of the devices discover this and switch back to using the primary console. Again, this can take a few minutes.
Not all tasks are available from the secondary console:
The primary console must be used for the following tasks:
New Device Installation: The primary console must be running when you install new devices such as another Access Gateway or SSL VPN server.
Backup and Restore: Backup and restore must be run on the primary console. When the restore has completed, you must restart Tomcat on all secondary consoles.
Linux: Enter the following command:
Windows: Enter the following commands:
net stop Tomcat5 net start Tomcat5
For more information about backup and restore, see Novell Access Manager 3.0 SP4 Administration Guide.
When the primary console goes down, the secondary console can be used for the following tasks:
Administrators can make configuration changes on a secondary console, and these changes are sent to the Access Manager components.
Access Manager components can use the secondary console to access their configuration information and to respond to configuration changes. As soon as the primary console comes back online, the components revert to using the primary machine, but they continue to accept commands from the secondary consoles.