|Back | Next | Contents||Cams Administrator's Guide|
This document provides an overview of Cams policy server clustering: a way to run multiple Cams policy servers to implement fault tolerance and increased scalability. Understanding the information in this document is important for effective deployment and administration of multiple Cams policy servers in a clustered configuration.
Other related documents on Cams policy server clustering include:
The primary benefits of running multiple Cams policy servers in a cluster include:
The primary mechanism by which Cams provides fault tolerance is failover. Cams web agents configured to communicate with multiple Cams policy servers in a cluster will automatically detect a failed Cams policy server and avoid further communication with it until it has recovered. Instead, security requests are sent to an accessible Cams policy server.
Scalability is provided in the Cams environment by use of load balancing, which refers to the ability of Cams web agents to delegate security requests to different Cams policy servers based on an algorithm and/or heuristic. For example, a round-robin load balancing strategy simply loops over a finite list of Cams policy servers.
Cams clustering has various configuration, networking, and licensing requirements.
Cams clustering has the following system requirements:
One of the most significant factors when running multiple Cams policy servers in clustered environment is maintaining consistent and compatible configuration settings. Consequently, Cams policy server clustering has the following configuration requirements:
Cams policy server clustering has various network-related requirements and/or recommendations including:
Production Cams licenses are issued by host IP address and maximum number of concurrent sessions. Licensing requirements include:
NOTE: You do not need a special Cams policy server license to run it in a cluster.
Please visit the Cams support page for more details.
Figure 1 shows a recommended Cams deployment with two Cams web agents, and a Cams cluster containing two Cams policy servers. Key aspects of this topology include:
NOTE: Using a shared file system across Cams policy server hosts is not recommended because it is a single point of failure and therefore decreases fault tolerance.
If you prefer to use a shared file system to simplify Cams policy server administration, we recommend a fault-tolerant RAID system. The recommended strategy for centralizing Cams policy server configuration is to edit files in a single location, then copy them to a server-specific local file system.
Figure 1 - The recommended Cams policy server cluster deployment topology
This section provides an overview of Cams policy server cluster configuration settings, failover, and load balancing mechanisms. More detail is provided in Policy Server Clustering.
When each Cams policy server starts on its own computer system, it is assigned a cluster name and a server name. This is done using a Cams policy server registration file, which is either CAMS_HOME/conf/cams-reg-default.conf or CAMS_HOME/conf/cams-reg-IP_ADDRESS.conf, where IP_ADDRESS is the static Internet Protocol address assigned to the Cams policy server host. For example, for a system with IP address 192.168.1.100:
Each Cams policy server must load a different registration file to be assigned a unique server name, so use of the IP address-specific file is recommended. The Cams policy server registration file contains the following properties:
The value of cams.server.name and cams.cluster.name may contain only alpha-numeric characters: A-Z, a-z,and 0-9. Spaces, tabs, periods, underscores, dashes, and all punctuation characters are prohibited.
Configuration files that are loaded from a local file system are:
Except for server-specific properties, like cams.server.name, each Cams policy server in a cluster generally loads the same configuration settings as all other servers in the cluster. This ensures that all security services are available to Cams web agents from all Cams policy servers in a cluster.
Every Cams web agent must specify the Cams cluster that it will use by setting the following web agent configuration property (in cams-webagent.conf):
This value must exactly match the cluster name configured for each Cams policy server in the cluster.
A Cams web agent may be configured to use one or more Cams policy servers within a cluster. In general, Cams web agents should be configured to use all Cams policy servers in the cluster. The URL for each Cams policy server is specified using properties of the following form within cams-webagent.conf:
cams.server.url.<Cams policy server name>=cams://<Cams policy server host>:<Cams policy server port>
For example, the following properties set two Cams policy servers for use by a Cams web agent:
The Cams policy server name must exactly match the value configured by the Cams policy server at the associated URL. Each Cams policy server name must be unique within the cluster. All other connection parameters within cams-webagent.conf, like agent authentication credentials, object pool parameters, etc. are shared for each configured Cams policy server connection.
Cams web agents are responsible for detecting unavailable Cams policy servers in a cluster and failing over to an accessible Cams policy server. Figure 2 shows a Cams cluster in which policy host 2 has failed. Cams web agents automatically detect the failed Cams policy servers and failover to live Cams policy servers.
A Cams policy server is considered to have failed under any of the following circumstances:
Figure 2 - Failure of a Cams policy server host
Cams web agents are also responsible for detecting recovered or newly accessible Cams policy servers. They do so by attempting to connect with the failed policy server for new authentication requests only. Once a failed server comes back on line, it begins to receive authentication requests and the associated access checks after users successfully authenticate.
Cams supports round-robin load balancing. Each Cams web agent maintains a list of available Cams policy servers and delegates requests in order. Because Cams does not support replication of user sessions across Cams policy servers, not every request can be load balanced. Once a user has authenticated with a given Cams policy server, all subsequent requests for that user (including additional authentications with other security domains) will be sent to the same policy server. This sticky server strategy ensures that access control checks will have access to the user's session.
Every Cams policy server is a member of a Cams cluster, even if the cluster contains only one server. Managing multiple Cams policy servers within a cluster adds a little extra setup and discipline to ensure that all servers in a cluster are running the same configuration. Other than that, Cams clustering is largely transparent.
NOTE: The most important single consideration when managing a cluster of Cams policy servers is to ensure that all servers use the same access control policy and login configuration information. Consequently, it is very important to use consistent and reliable administration practices to ensure that every Cams policy server uses the same configuration files, Java classes, etc. The basic procedure is:
Each Cams policy server in a cluster largely uses the same configuration files as all other policy servers, but server-specific configuration settings can also be specified. Regardless, the most reliable strategy is to copy all files (even those that are for a different Cams policy server or another cluster) to every Cams policy server host.
More details are provided in Policy Server Clustering.
Cams clustering has the following limitations: