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:
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:
Each component has a specific role with resource protection.
Note: For more information about the primary purpose of each component, see CA SiteMinder® 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.
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:
Each component has a specific role with resource protection.
Note: For more information about primary purpose of each component, see CA SiteMinder® Components.
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:
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.
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.
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:
Note: For more information about Agent and Policy Server redundancy and high availability, see Redundancy and High Availability.
Note: For more information about Policy Server and user store redundancy and high availability, see Redundancy and High Availability.
Note: For more information about Policy Server and policy store redundancy, see Redundancy and High Availability.
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:
Note: For more information about failover thresholds for Policy Server cluster failover thresholds, see the Policy Server Administration Guide.
You configure redundancy and high availability between logical blocks of CA SiteMinder® components to maintain system availability and performance.
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.
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:
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:
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:
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:
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.
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
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.
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.
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:
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 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:
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:
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:
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:
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:
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.
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:
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:
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.
Note: For more information about Policy Server logging and the smauditimport tool, see the Policy Server Administration Guide.
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.
|
Copyright © 2013 CA.
All rights reserved.
|
|