Previous Topic: Architectural ConsiderationsNext Topic: CA SiteMinder® Enhanced Session Assurance Architecture and Performance Considerations


Architectural Use Cases

The purpose of the following use cases is to get you thinking about your CA SiteMinder® architecture in terms of high availability and performance. The use cases begin with a simple deployment and progress into more complex scenarios. Each case is based on the idea of a logical "block" of CA SiteMinder® components and illustrates how an environment can contain multiple blocks to address the following architectural considerations:

Extrapolate the necessary infrastructure from these cases to:

More information:

Capacity Planning Introduced

Performance Tuning Introduced

Redundancy and High Availability

Simple Deployment

The simplest CA SiteMinder® deployment requires one "block" of components. A block of components is a logical combination of dependent components that include:

You protect web-based resources by deploying at least one block.

The following diagram illustrates a simple deployment:

Graphic showing a Simple SiteMinder Deployment

Each component has a specific role with resource protection.

Note: For more information about the primary purpose of each component, see CA SiteMinder® Components.

Simple Deployment with Optional Components

You can extend the functionality of a simple deployment through the use of optional CA SiteMinder® components. The decision to implement optional components is determined by the CA SiteMinder® features your enterprise requires. For example:

The following diagram illustrates the optional components and their required dependencies:

Each component has a specific role in resource protection.

Note: For more information about the primary purpose of each component, see CA SiteMinder® Components.

Simple Deployment with Optional Agents

You can extend the functionality of a simple deployment your environment to protect resources that do not reside on a Web Server. For example, if your environment hosts resources on an:

The following diagram illustrates optional Agents:

Graphic showing a Simple SiteMinder deployment with optional Agents

Each component has a specific role with resource protection.

Note: For more information about primary purpose of each component, see CA SiteMinder® Components.

Multiple Components for Operational Continuity

The following use cases show how you can implement multiple blocks of components to build redundancy and failover into the environment using the following methods:

Multiple Components for Operational Continuity Using CA SiteMinder® Load Balancing

You can implement multiple blocks of components to build redundancy and failover into the environment using CA SiteMinder® round robin load balancing. This use case builds on a simple deployment to explain how you can begin thinking about operational continuity. The following diagram illustrates:

Each component has a specific role with resource protection.

Note: For more information about the primary purpose of each component, see CA SiteMinder® Components. For more information about CA SiteMinder® redundancy and high availability, see Redundancy and High Availability.

More information:

Redundancy and High Availability

Multiple Components for Operational Continuity Using Hardware Load Balancing

You can implement multiple blocks of components to build redundancy and failover into the environment using hardware load balancing. This use case builds on a simple deployment to explain how you can begin thinking about operational continuity. The following diagram illustrates:

Each component has a specific role with resource protection.

Note: For more information about the primary purpose of each component, see CA SiteMinder® Components. For more information about CA SiteMinder® redundancy and high availability, see Redundancy and High Availability.

More information:

Redundancy and High Availability

Clustered Components for Scale

You can implement additional clusters to help performance levels remain high as you scale to extend throughput. This use case builds on the multiple components for operational continuity use case to explain how you can begin thinking about your architecture in terms of scale.

The initial deployment section of the diagram illustrates:

Each component has a specific role with resource protection.

Note: For more information about the primary purpose of each component, see CA SiteMinder® Components.

The Scaled for Capacity section of the diagram details another component block and illustrates:

More information:

Redundancy and High Availability

Multiple Components for Operational Continuity Using CA SiteMinder® Load Balancing

Multiple Components for Operational Continuity Using Hardware Load Balancing

Redundancy and High Availability

You configure redundancy and high availability between logical blocks of CA SiteMinder® components to maintain system availability and performance.

Agent to Policy Server Communication

When you configure a CA SiteMinder® Agent, a Host configuration file (named SmHost.conf by default), is created on the host server. The Agent uses the connection information in this Host configuration file to create an initial connection with a Policy Server.

After the initial connection is established, the Agent obtains subsequent Policy Server connection information from the Host Configuration Object (HCO) on the Policy Server.

You can configure the HCO to include multiple Policy Servers and specify the method the Agent uses to distribute requests among multiple Policy Servers.

A CA SiteMinder® Agent can distribute requests among multiple Policy Servers in the following ways:

Alternatively, you can configure the HCO to include a single virtual IP address configured on a hardware load balancer to expose multiple Policy Servers. In this case, the load balancer is responsible for failover and load balancing, rather than the Agent software.

More information:

CA SiteMinder® Agents

Install the SiteMinder WSS Agent for WebLogic on a Windows System

Install the SiteMinder WSS Agent for WebLogic on a UNIX System

Install the SiteMinder WSS Agent for WebSphere on a Windows System

Install the SiteMinder WSS Agent for WebSphere on a UNIX System

Failover

Failover is the default HCO setting. In failover mode, a CA SiteMinder® Agent delivers all requests to the first Policy Server that the HCO lists and proceeds as follows:

  1. If the first Policy Server does not respond, the Agent deems it unavailable and redirects the request, and all subsequent requests, to the next Policy Server that the HCO lists.
  2. If the first two Policy Servers do not respond, the Agent deems both of them unavailable and redirects the request, and all subsequent requests, to the next Policy Server that the HCO lists.

Note: For more information about configuring an HCO with multiple Policy Servers, see the Policy Server Configuration Guide.

If an unresponsive Policy Server recovers, which the Agent determines through periodic polling, the Policy Server is automatically returned to its original place in the HCO list and begins receiving all Agent requests.

The following diagram illustrates the Agent failover process:

Illustration showing a SiteMinder Web Agent communicating in failover mode

Round Robin Load Balancing

Round robin load balancing is an optional HCO setting. Round robin load balancing distributes requests evenly over a set of Policy Servers, which:

Note: For more information about configuring an HCO for round robin load balancing, see the Policy Server Configuration Guide.

In round robin mode, an Agent distributes requests across all Policy Servers that the HCO lists. An Agent:

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

If a Policy Server does not respond, the Agent redirects the request to the next Policy Server that the HCO lists. If the unresponsive Policy Server recovers, which the Agent determines through periodic polling, the Policy Server is automatically restored to its original place in the HCO list.

The following diagram illustrates the round robin process:

Graphic showing a SiteMinder Agent distributing requests in round robin mode.

Policy Server Clusters

Round robin load balancing evenly distributes CA SiteMinder® Agent requests to all Policy Servers that the HCO lists. Although an efficient method to improve system availability and response times, consider that:

A Policy Server cluster is a group of Policy Servers to which Agents can distribute requests. Policy Server clusters provide the following benefits over round robin load balancing:

Note: For more information about configuring a Policy Server cluster, see the Policy Server Administration Guide.

The following diagram illustrates two Policy Server clusters. Each cluster is geographical separated to avoid the network overhead that can be associated with round robin load balancing.

Graphic showing Web Agent load balancing and failover between Policy Server clusters

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, Multiple Policy Servers Per VIP

Graphic showing Load balancer with one VIP and 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

Graphic showing Load balancer with multiple VIPs and 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:

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:

Graphic showing a Policy Server communicating with user stores in failover mode

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:

Note: Consider the following:

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:

Graphic showing a Policy Server communicating with user stores in load balancing mode

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:

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:

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:

Graphic showing the use of a single master policy store to achieve policy store redundancy

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:

The following configuration is recommended when configuring an LDAP policy store in multi-master 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:

Graphic showing the use of a multi-master policy store to achieve policy store redundancy

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:

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:

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.

Graphic showing the use of a master session store to achieve session store redundancy

More information:

Session Store