Implementation Guide › Configuration Considerations › Multiple Data Centers

Multiple Data Centers

CA SiteMinder® treats a global deployment the same as multiple data centers in the same continent. As such, factors outside of CA SiteMinder® affect the performance of a multi–data center deployment. The following key factors include:

• Network latency
• Resiliency

We recommend that you consider the following outside factors as you plan for a multi–data center deployment:

• Network infrastructure
• Application locations
• User locations
• User store vendors and their restrictions, such as the number of masters allowed

Best Practices

Consider the following when configuring data centers:

• Collocating the following components in each data center helps to reduce the effect network latency and resiliency has on CA SiteMinder® performance:
  • CA SiteMinder® Agents
  • Policy Servers
  • User stores

    Note: If a CA SiteMinder® feature, such as Password Services, requires a write–enabled store, we recommend having a write–enabled store in each data center.

• If all components cannot be in the same data center, we recommend at least collocating Policy Servers and user stores in the same data center.

Architectural Considerations

Consider the following architectural factors when planning for a CA SiteMinder® data center:

• CA SiteMinder® Password Services attempts to perform an LDAP write to the user account on every authentication.

  Note: For more information about Password Services, see the Policy Server Configuration Guide.

• CA SiteMinder® follows LDAP write referrals when communicating with a read–only consumer directory.
• If you deploy a master policy store with replicated versions, consider using a local host file on the Policy Server host system (LDAP) or the ODBC data source to point Policy Servers to the local policy store. Using this method lets all Policy Servers share the same policy store and avoids the latency that can occur when all Policy Servers must communicate with the policy store over the wide area network (WAN).
• If you deploy master/consumer user stores, consider using a local host file on the Policy Server host system (LDAP) or the ODBC data source name (DSN) to point Policy Servers to the local consumer. Using this method lets all Policy Servers read the same user store and avoids the latency that can occur when all Policy Servers must read user account information over the WAN.

Example: Local Host Files Pointing Policy Servers to the Local Consumer User Store

Two geographically separated data centers include Policy Servers pointing to a consumer user store named myusers.

• The local consumer in data center one is available at 111.11.111.1
• The local consumer in data center two is available at 222.22.222.2

To point Policy Server to the local consumer

1. From the Policy Server host systems in data center one, use a local host file to map myusers to 111.11.111.1.
2. From the Policy Server host systems in data center two, use a local host file to map myusers to 222.22.222.2.

Multiple Data Center Use Cases

The purpose of the following use cases is to get you thinking about your CA SiteMinder® data centers in terms of network latency and resiliency. The use cases begin with a simple deployment and progress into more complex scenarios.

These use cases are intended to identify techniques that you can use as part of a global architecture and are not intended as a final architecture. Extrapolate the necessary infrastructure from these cases to configure data centers that best meet the needs of your organization.

All Components in One Data Center

The simplest deployment includes all required CA SiteMinder® components in a single data center.

The following diagram illustrates:

• All applications in a single data center.
• A Policy Server writing to a master user store. CA SiteMinder® Password Services attempts to perform an LDAP write to the user account on every authentication.

  Important! For more information about multi–mastered LDAP user store support limitations, see the Policy Server Release Notes.

• CA SiteMinder® reading a consumer user store.

  

Consider the following:

• Although not illustrated, CA SiteMinder® supports database clusters that are configured for write and read–only transactions.
• You can configure multiple components in a data center for operational continuity, redundancy, and high availability.

More information:

Redundancy and High Availability

All Components in Multiple Data Centers

You extend the CA SiteMinder® environment by deploying multiple data centers. The following factors can influence your decision to implement multiple data centers:

• The network infrastructure
• The location of applications
• The location of users

The following diagram illustrates applications in multiple data centers:

• Each data center uses its own policy store.
• Data center one contains the primary policy store. Data center two contains the replicated version, as the dotted line details.

  Note: Every Policy Server in the deployment must share a common view into the same policy store. For more information about policy store redundancy, see Policy Server to Policy Store Communication.

• Each data center uses its own master/consumer user stores.

  Important! For more information about multi–mastered LDAP user store support limitations, see the Policy Server Release Notes.

• A centralized replicated session store enables single sign–on between all applications.

  

More information:

Policy Server to Policy Store Communication

All Components in One Data Center

CA SiteMinder® Agent Communicating Across a Data Center

If all components cannot be in the same data center, we recommend collocating Policy Servers and user stores in the same data center.

The following diagram illustrates applications in multiple data centers:

• Data center one only contains a web server with a CA SiteMinder® agent. The agent communicates across the wide area network to a Policy Server in data center two.
• Data centers two and three share a common view into the policy store through a master/replicated policy store.
• Data centers two and three use their own master/consumer user stores.
• A centralized replicated session store enables single sign–on between all applications.

  

More information:

Policy Server to Policy Store Communication

Policy Server Communicating Across a Data Center

If all components cannot be in the same data center, we recommend collocating Policy Servers and user stores in the same data center.

The following diagram illustrates applications in multiple data centers:

• Data center one contains an agent and a Policy Server. The Policy Server only communicates across the wide area network to perform LDAP writes to the master user store in data center two.

  Important! We do not recommend configuring a Policy Server to communicate across the wide area network to perform LDAP reads and writes.

• All data centers share a common view into the policy store through a master/replicated policy store.
• A centralized replicated session store enables single sign–on between all applications.
• Data centers two and three use their own master/consumer user stores.

  Important! For more information about multi–mastered LDAP user store support limitations, see the Policy Server Release Notes.

  

Login Server Controlling User Store Writes

The location of LDAP writable masters can constrain a CA SiteMinder® deployment. To eliminate requirements for writable masters in each data center, consider using one or more centralized login servers.

The following diagram illustrates a multiple data center deployment:

• The Policy Server in data center one is communicating across the WAN to perform an LDAP write.
• The remaining data centers include all components.
• A login server is deployed in data centers two and three.

  

When a user requests access to a protected URL in data center one:

1. The agent redirects the request to the login server in data center two. The redirect is based on the authentication scheme that is protecting the resource.

   Note: For more information about authentication schemes, see the Policy Server Configuration Guide.

2. The Policy Server in data center two authenticates the user and writes to the master user store.
3. The Policy Server creates a CA SiteMinder® session ticket and passes it back to the original protected URL.

   Note: For more information about user sessions, see the Policy Server Configuration Guide.

4. The agent places the CA SiteMinder® session ticket into a cookie. The agent uses the cookie to handle subsequent authentication and authorization requests in the data center, until one of the following occurs:
   • The user requests another resource that requires re-authentication.
   • The session expires.