Implementation Guide › Architectural Considerations › Architectural Use Cases › Locate the Web Services Security Installation Media › › Hardware Load Balancing

Hardware Load Balancing

CA SiteMinder® supports the use of hardware load balancers configured to expose multiple Policy Servers through one or more virtual IP addresses (VIPs). The hardware load balancer then dynamically distributes request load between all Policy Servers associated with that VIP. The following hardware load balancing configurations are supported:

• Single VIP with multiple Policy Servers exposed by each VIP
• Multiple VIPs with multiple Policy Servers exposed by each VIP

Single VIP, Multiple Policy Servers Per VIP

In the configuration shown in the previous diagram, the load balancer exposes multiple Policy Servers using a single VIP. This scenario presents a single point of failure if the load balancer handling the VIP fails.

Multiple VIPs, Multiple Policy Servers Per VIP

In the configuration shown in the previous diagram, groups of Policy Servers are exposed as separate VIPs by one or more load balancers. If multiple load balancers are used, this amounts to failover between load balancers, thus eliminating a single point of failure. However, all major hardware load balancer vendors handle failover between multiple similar load balancers internally such that only a single VIP is required. If you are using redundant load balancers from the same vendor, you can therefore configure Agent to Policy Server communication with a single VIP and still have robust load balancing and failover.

Note: If you are using a hardware load balancer to expose Policy Servers as multiple virtual IP addresses (VIPs), we recommend that you configure those VIPs in a failover configuration. Round robin load balancing is redundant as the hardware load balancer performs the same function more efficiently.

Policy Server to User Store Communication

The Policy Server can distribute queries over multiple LDAP or ODBC user stores to enable the following:

• Failover
• Round robin load balancing

Note: For more information about configuring user store connections, see the Policy Server Configuration Guide.

More information:

User Store

Failover

Failover is an optional setting in the CA SiteMinder® user store object. In failover mode, a Policy Server distributes all requests to the primary user store and proceeds as follows:

1. If the primary user store does not respond, the Policy Server deems it unavailable and redirects the request, and all subsequent requests, to the next user store that the CA SiteMinder® user store object lists.
2. If the first and second user stores do not respond, the Policy Server deems them both unavailable and redirects the request, and all subsequent requests to the next user store that the CA SiteMinder® user store object lists.

Note: For more information about configuring user store failover, see the Policy Server Configuration Guide.

If an unresponsive user store recovers, the user store is automatically returned to its original place in the failover list and begins receiving all Policy Server requests.

The following diagram illustrates the user store failover process:

Round Robin Load Balancing

Round robin load balancing is an optional CA SiteMinder® user store object setting. Round robin load balancing distributes requests evenly over a set of user stores, which:

• Results in more efficient user store queries
• Prevents a single user store from becoming overloaded with Policy Server requests

Note: Consider the following:

• For more information about configuring load balancing between LDAP user stores, see the Policy Server Configuration Guide.
• The Administrative UI does not include settings to configure round robin load balancing between ODBC user stores. However, the Policy Server installation includes:
  • The CA SiteMinder® Oracle Wire Protocol. This protocol supports load balancing over multiple Oracle stores. You can configure Oracle user store load balancing at the data source level.
  • The CA SiteMinder® SQL Server Wire Protocol, which you can use to configure SQL Server or SQL Server Cluster Enterprise. You can configure SQL Server user store load balancing at the database level.

In round robin mode, a Policy Server distributes requests across all user stores that the CA SiteMinder® user store object lists. A Policy Server:

1. Sends a request to the first user store that the user store object lists.
2. Sends a request to the second user store that the user store object lists.
3. Sends a request to the third user store that the user store object lists.
4. Continues sending requests in this way, until the Policy Server has sent requests to all available user stores. After sending requests to all available user stores, the Policy Server returns to the first user store and the cycle begins again.

Note: Configure load balancing with failover to add the benefit of redundancy in the event of a user store failure. For more information about configuring load balancing and failover, see the Policy Server Configuration Guide.

The following diagram illustrates the user store round robin process:

Policy Server to Policy Store Communication

All Policy Servers must connect to the same policy store for a common view of policy information. However, we recommend that the deployment includes multiple "hot" policy stores to which Policy Servers can failover.

The following are policy store failover scenarios:

• A master policy store configured with replicated versions
• Multi–mastered policy stores

Master Policy Store

Deploying a master policy store with replicated versions is a way to achieve policy store redundancy. A single master policy store lets each Policy Server communicate with the closest replicated version. This method of communication:

• Improves the performance of geographically separated Policy Servers. Sending Policy Server requests to policy stores outside a certain locale can result in increased network communication overhead and network congestion.
• Allows for failover. If a primary policy store fails, Policy Servers failover to a secondary store.

Note: For more information about configuring replication, see your vendor–specific documentation. For more information about configuring policy store failover, see the Policy Server Administration Guide.

The following diagram illustrates a single master policy store environment:

Multi–Mastered Policy Stores

Deploying LDAP directories using multi–master technology is a way to achieve policy store redundancy. A multi–master policy store lets each Policy Server communicate with the closest replicated version. This method of communication:

• Improves the performance of geographically separated Policy Servers. Sending Policy Server requests to policy stores outside a certain locale can result in increased network communication overhead and network congestion.
• Allows for failover. If a primary policy store fails, Policy Servers failover to a secondary store.

The following configuration is recommended when configuring an LDAP policy store in multi-master mode:

• A single master should be used for all administration.
• A single master should be used for key storage.

  This master does not need to be the same as the master used for Administration. However, we recommend that you use the same master store for both keys and administration. In this configuration, all key store nodes should point to the master rather than a replica.

  Note: If you use a master for key storage other than the master for administration, then all key stores must use the same key store value. No key store should be configured to function as both a policy store and a key store.

• All other policy store masters should be set for failover mode.

Due to possible synchronization issues, other configurations may cause inconsistent results, such as policy store corruption or Agent keys that are out of sync.

Contact CA SiteMinder® Support for assistance with other configurations.

The following diagram illustrates a multi–master policy store environment:

Policy Server to Audit Store Communication

By default, each Policy Server stores its own audit information to a text file. This text file is known as the Policy Server log. You can configure a Policy Server to log audit data directly to a database.

CA SiteMinder® audit logs are typically used for audit and compliance purposes. Consider the following:

• Having all Policy Servers write to a centralized audit store, where all data can be queried at once, may be preferable. If you deploy a centralized audit store, we recommend a highly available deployment.

  Note: For more information about configuring an audit store, see the Policy Server Installation Guide. For more information about configuring failover, see the Policy Server Administration Guide.

  Important! If you enable synchronous auditing, we recommend configuring failover to prevent an audit store outage from stopping all Policy Server authentications and authorizations. The Policy Server does not return the result of Agent authentication and authorization requests until the record is saved in the audit database. Users are not authenticated or authorized until the record is saved. For more information about configuring failover, see the Policy Server Administration Guide.

• If your deployment cannot permit Policy Servers to write to a centralized audit store, you can use the smauditimport utility to import individual Policy Server logs into a centralized audit store.

  Note: For more information about Policy Server logging and the smauditimport tool, see the Policy Server Administration Guide.

More information:

CA SiteMinder® Audit Database

Policy Server to Session Store Communication

If you deploy a session store, all Policy Servers in the environment must use the same session store database.

Deploying a master session store is a way to achieve session store redundancy. A master session store lets each Policy Server communicate with the closest replicated version. This method of communication:

• Improves the performance of geographically separated Policy Servers. Sending Policy Server requests to a centralized session store outside a certain locale can result in increased network communication overhead and network congestion.
• Allows for failover. If a primary session store fails, Policy Servers failover to a secondary session store.

Note: For more information about configuring replication, see your vendor–specific documentation. For more information about configuring session store failover, see the Policy Server Administration Guide.

The following diagram illustrates all Policy Servers sharing a common view into a session store.

More information:

Session Store