The Administration Console contains an embedded version of eDirectory, which contains all configuration information of Access Manager Appliance. 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.
An L4 server is installed. The LB algorithm can be anything (hash/sticky bit), defined at the Real server level.
Persistence (sticky) sessions enabled on the L4 server. You usually define this at the virtual server level.
NOTE:If Access Manager Appliance is configured with public and private interface, the back channel communication will use the private interface. To allow this back channel communication on private interface, modify the NAM-RP configuration to listen on private and public interfaces. For more information, see Section 3.8.2, Managing Reverse Proxies and Authentication.
A Note about Layer 4 Switch: A cluster of Access Manager Appliances should reside behind a Layer 4 (L4) switch. Clients access the virtual IP address of the cluster presented on the L4 switch, and the L4 switch alleviates server load by balancing traffic across the cluster.
Whenever a user accesses the virtual IP address assigned to the L4 switch, the system routes the user to one of the Access Manager Appliances in the cluster, as traffic necessitates.
IMPORTANT:You should not use a DNS round robin setup instead of an L4 switch for load balancing. The DNS solution works only as long as all members of the cluster are working and in a good state. If one of them goes down and traffic is still sent to that member, the entire cluster is compromised and all devices using the cluster start generating errors.
Services of the Real Server: A user’s authentication remains on the real (authentication) server cluster member that originally handled the user’s authentication. If this server malfunctions, all users whose authentication data resides on this cluster member must re-authenticate unless you have enabled session failover. For more information about this feature, see Configuring Session Failover.
Requests that require user authentication information are processed on this server. When the system identifies a server as not being the real server, the HTTP request is forwarded to the appropriate cluster member, which processes the request and returns it to the requesting server.
A Note about Service Configuration: If your L4 switch can perform both SSL and non-SSL health checks, you should configure the L4 switch only for the services that you are using in your Access Manager configuration. For example, if you configure the SSL service and the non-SSL service on the L4 and the base URL of your Identity Server configuration is using HTTP rather than HTTPS, the health check for the SSL service fails. The L4 switch then assumes that all the Identity Servers in the cluster are down. Therefore, ensure that you enable only the services that are also enabled on the Identity Server.
A Note about Alteon Switches When you configure an Alteon switch for clustering, direct communication between real servers must be enabled. If direct access mode is not enabled when one of the real servers tries to proxy another real server, the connection fails and times out.
To enable direct communication on the Alteon:
Go to cfg > slb > adv > direct.
Specify e to enable direct access mode.
Insert the CD containing the software.
Most of the installation process is same for a secondary appliance as for a primary. If this is a second or third appliance, the Administration Console will be configured for the fault tolerance. While installing a secondary appliance:
Deselect the Primary check box.
Specify the IP address of the primary Administration Console.
Specify the user name and password of the primary Administration Console.
Installation of the secondary appliance becomes interactive after the installation of operating system in the following cases:
(Conditional) if this is the fourth appliance: The number of Administration Consoles in a cluster is restricted to three. If more appliances are added into the cluster, the system will ask whether you want proceed with the installation of rest of the components other than Administration Console.
(Conditional) if time is not synchronized between the primary and secondary appliances. The system will prompt a message asking you to re-try the time synchronization or to proceed without synchronization.
If you have firewalls separating your Identity Servers or your L4 switch does not support port translation, you can use iptables to translate the port
Configure the details on the Administration Console Configuration page as specified in step 9 in Installing Access Manager Appliance in the NetIQ Access Manager Appliance 4.1 Installation and Upgrade Guide.
Continue with the installation process.
The Identity Server and the Access Gateway from the secondary appliance are automatically clustered with the primary appliance. If this is second or third secondary appliance, the configuration store will be configured for the fault tolerance. Install at least one secondary console.
After successful installation, the appliance points to the Access Manager Appliance's IP address for the Web server, and the Identity Server points to the local user store. If a cluster is configured for Access Manager Appliance and if primary appliance is down, you cannot authenticate because the user store is on primary and they cannot access the resources because it points to the Web server on primary. Hence, it is advised to change the IP address of the Web server configured in the master proxy service to point to your test or production Web server, and change the Identity Server’s configuration to point to an external user store.
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 Appliance 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, devices are notified. But they continue to run by using the primary console for configuration information. The secondary console can be down for as long as required to fix the problem without affecting other Access Manager Appliance 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, because 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 online, all 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:
Backup and Restore: Backup and restore must be run on the primary console. When the restore is completed, you must restart Tomcat on all secondary consoles.
Enter the following command:
/etc/init.d/novell-ac restart
For more information about backup and restore, see Section 24.0, Back Up and Restore.
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 Access Manager components.
Access Manager Appliance components can use the secondary console to access their configuration information and to respond to configuration changes. When the primary console becomes functional, components revert to using the primary console, but they continue to accept commands from the secondary consoles.