Policy Server Failover, Load Balancing and Clustering

Overview Agent to Policy Server Failover Dynamic Load Balancing Policy Server Clustering Exercise 1: Policy Server Failover Exercise 2: Multiple Agent Identities

SiteMinder allows the following failover and load balancing strategies: Agent to policy server Failover Dynamic load balancing Policy server clustering Policy server to policy store Failover Policy server to user directory Failover Round robin load balancing Failover is a redundancy mode. If the primary Policy Server fails, there is a backup Policy Server to take over policy operations. Failover is the default operation mode. When the Trusted Host initializes, it operates in Failover mode. Load balancing lets the Trusted Host distribute requests across multiple Policy Servers, which provides faster access to Policy Servers and therefore, more efficient user authentication and authorization. It also prevents a single Policy Server from becoming overloaded with requests. SiteMinder can spread LDAP queries over multiple LDAP servers to enable failover and load balancing. If configured for failover, SiteMinder uses one LDAP server to fulfill requests until that server fails to respond. When the default server does not respond, SiteMinder routes the request to the next server specified for failover. This process can be repeated over multiple servers. Once the default server is able to fulfill requests again, SiteMinder routes requests to the original server. The above picture illustrates a hypothetical architecture block for a SiteMinder deployment. The identification of known architecture blocks, with specific numbers of web, policy and directory servers, whose throughput and cost are thoroughly understood is recommended. An increase demand should be dealt with by adding more infrastructure blocks to the production environment. When an addition is made always incorporate the necessary load balancing and failover strategies between the blocks. Fail over is a redundancy mode. If the primary Policy Server fails, there is a backup Policy Server to take over policy operations. Failover is the default operation mode. When the Trusted Host initializes, it operates in Failover mode. Round robin load balancing mode lets the Trusted Host distribute requests across multiple Policy Servers, which provides faster access to Policy Servers and therefore, more efficient user authentication and authorization. It also prevents a single Policy Server from becoming overloaded with requests. Siteminder Web Agent to Policy Server Failover: Failover is a redundancy mode If primary policy server fails, a backup takes over Failover is the default mode when a trusted host is configured with a list of policy servers: first policy server in the list is the primary. if current server fails, it is marked as unavailable; trusted host moves to next available server in the list. if a failed server recovers, it is returned to its original list location NOTE: Both failover and load balancing require common policy and key stores. Failover is a redundancy mode. If the primary Policy Server fails, there is a backup Policy Server to take over policy operations. Failover is the default operation mode. When the Trusted Host initializes, it operates in Failover mode. In this mode, every Trusted Host request is delivered to the first Policy Server in the list. If that Policy Server does not respond, the Trusted Host marks it unavailable and redirects the request to the next Policy Server in the list. If a previously failed Policy Server recovers, SiteMinder returns it to its original place in the list. Trusted host to policy server failover is configured in the trusted host’s Host Configuration Object. The object shown above only lists a single policy server, meaning there is no failover redundancy. To add additional policy servers, Edit the PolicyServer parameter.   Click the Add button to add more policy servers.shown below Edit the PolicyServer parameter and click the Multi-value radio button to enter multiple policy servers. You can use either an IP address or a fully qualified domain name. List the ports that you want the trusted host to talk to. (For 6x agents, you only need to list one port.). This diagram shows the Host Configuration Object dialog, which contains the configuration for any trusted host assigned to this object. In this case, the PolicyServer parameter contains a multi-value list of policy server IP addresses and the EnableFailOver parameter is defaulted to YES. The first policy server in the list is the primary server. If it fails, the trusted host would attempt to establish communications with the next server in the list. Trusted host distributes requests across multiple policy servers Allows for more efficient user authentication and authorization Uses a dynamic load balancing algorithm to send request to best available policy server, based on best response time and throughput. Dynamically adapts to changes in load Equally effective as round-robin in homogeneous environments Extremely effective in heterogeneous environments NOTE: Requires common policy and key stores Dynamic load balancing lets the Trusted Host distribute requests across multiple Policy Servers, which provides faster access to Policy Servers and therefore, more efficient user authentication and authorization. It also prevents a single Policy Server from becoming overloaded with requests. The trusted host sends each request to the best available policy server, where availability is based on best response time and throughput. In a homogeneous environment, where all policy servers exhibit equivalent response time, dynamically load balancing is essentially equivalent to a round robin algorithm that sends requests to each policy server in turn. In a heterogeneous environment, where policy servers run on different hardware and exhibit different performance characteristics, the dynamic load balancing algorithm allows the trusted host to take full advantage of the capabilities of each policy server machine. NOTE: Both failover and load balancing require the configuration of common policy and encryption key data. This can provided by having: a common policy store that includes the key store separate policy stores that are exact replicas including encryption keys separate policy stores that are exact replicas with a common key store The above picture shows the Host Configuration Object dialog, which contains the configuration for any trusted host assigned to this object. In this case, the PolicyServer parameter contains a multi-value list of policy server IP addresses and the EnableFailOver parameter is defaulted to NO. This setting will cause the trusted host to use dynamic load balancing across all of the policy servers specified in the PolicyServer parameter. A cluster is a set of servers with dynamic load balancing. Load is dynamically distributed among the servers in a cluster. Trusted hosts can be configured to failover to another cluster when the available servers fall below a configurable threshold. Once the original cluster recovers sufficiently, trusted hosts automatically fail back. Centralized monitoring of policy servers in a cluster. Load balancing and failover in a SiteMinder deployment provide a high level of system availability and improve response time by distributing requests from SiteMinder Agents to Netegrity Policy Servers. Defining clusters in combination with load balancing and failover further enhance the level of system availability and system response time. Traditional round robin load balancing without clusters distributes requests evenly over a set of servers. However, this method is not the most efficient in heterogeneous environments where computing powers differ, since each server receives the same number of requests regardless of its computing power. Another problem with efficiency may occur when data centers are located in different geographical regions. Sending requests to servers outside a certain locale can lead to the increased network communication overhead, and in some cases to the network congestion. To address these issues and to improve system availability and response time, you can define a cluster of Policy Servers. A cluster is a set of one or more servers, with dynamic load-balancing between the servers. Policy Server clusters provide the following benefits over a traditional load balancing/failover scheme: Load is dynamically distributed between Policy Servers in a cluster based on server response time. A cluster can be configured to failover to another cluster if the number of available servers in the cluster falls below a configurable threshold. The picture above illustrates clusters defined in terms of geographic distribution. Configuring Clusters Use the Clusters tab in the Host Conf Object Define a cluster, set the threshold, and order clusters Settings in the Clusters tab are used instead of the Policy Server parameter in the General tab Clusters are configured in the Clusters tab of the Host Configuration Object. To add a cluster, click the Add button to open the Cluster Setup dialog. Once you have defined all the servers you want included in the cluster, you return to the Clusters tab, where you configure the failover threshold and the ordering of clusters. The failover threshold is defined in terms of the percentage of machines in the cluster that must be available in order for the cluster to be utilized. If the percentage of active servers falls below the percentage you specify, the cluster failovers to the next available cluster in the list of clusters. The Policy Server User interface automatically calculates the Failover Threshold values displayed in the column to the right of the lists of servers in each cluster. The number that appears in the Failover Threshold column is the minimum number of servers in the cluster that must be available. If the number of available servers falls below the specified number, failover occurs. When you set the Failover Threshold Percentage, it applies to all clusters that use the Host Configuration Object. The first cluster in the list is the primary cluster. Use the up and down arrows to reorder clusters. The information in the Clusters tab supersedes the information in the General tab. More specifically, when clusters are configured, the trusted host ignores the PolicyServer parameter configured in the General tab and uses the Clusters information in its place. Timeout and socket settings in the General tab apply to all policy servers in all clusters. Cluster Setup In the Add Server group box: 1. Specify the policy server by performing one of the following: Select the IP Address radio button and enter the IP address of a Policy Server in the cluster in the provided fields. Note: If you do not know the IP address of the Policy Server, but you know the host name, click the DNS Lookup button to search for the IP address of the Policy Server. Select the Domain Name radio button and enter the domain name of the system where the Policy Server is installed. For example, server.company.com. 2. In the Server Port field, enter the port for Policy Server processing. 3. Click the Add to Cluster button. The Policy Server appears in the list of servers in the Current Setup group box.