CEPM Capacity Planning Guide
Distributed Architecture Deployment

Table Of Contents

Scenario 1: Distributed Architecture Deployment

Shared-PAP and Shared-entitlement-repository

Shared-PAP only

Shared-nothing


Scenario 1: Distributed Architecture Deployment


The distributed architecture deployment model is supported by the Cisco Enterprise Policy Manager (CEPM) with a loosely coupled architecture that allows Policy Administration Points (PAPs) and Policy Decision Points (PDPs) to be distributed over a wide area network (WAN). Policy changes configured at the PAP are propagated to the PDPs through various protocols (both push and pull). Additionally, CEPM offers flexibility in sharing an entitlement repository is shared and addresses high availability and load-balancing issues. Administrators can log in to the PAPs and the entitlement infrastructure transparently handles policy propagation across geographies.


Note CEPM supports a rich entitlement policy model. The sizing estimates described here are based on the complexity of policies being resolved.

Users: 50,000 users with 5,000 concurrent queries.

Resources: 1,000 hierarchical resources each with multiple actions.

Latency required: User-level queries of less-than-0.2-second-per-query response time for role- and rule-based decisions.

Distribution: Four target production sites, Asia, Europe, Australia, and United States for distributed architecture. For the workload described in this chapter, the PDP in the United States must be deployed over four servers, and the PDPs in Asia and Europe must be deployed over two servers each. Because the PAP is not involved in critical-path decisions, the PAP can be deployed in a cluster of two servers for high availability.


A Distributed Architecture in CEPM can be achieved in one of the following ways:

Shared-PAP and Shared-entitlement-repository

Shared-PAP only

Shared-nothing

Shared-PAP and Shared-entitlement-repository

In this scenario, the PDPs are distributed, but all of the PDPs share a common entitlement repository with the PAP. The entitlement repository is typically a database co-hosted in the same data center as the PAP. This option has the advantage of easing management of entitlement data that is not replicated across multiple environments. The PDPs also do not need any other communication channel with the PAP for policy update notifications, which can be handled at the database level.

Figure 1-1 Shared-PAP and shared-entitlement repository

Shared-PAP only

In the share-PAP only deployment model, the entitlement repository is managed in a replicated fashion across geographies. Policy changes are communicated from the PAP to the PDPs using database-level replication or application-level replication via any pluggable message orientated middleware (MOM) protocol, such as with a Java Message Service (JMS) interface.

For application-level replication, an add-on component that is colocated with the PDP receives these policy update messages from the PAP and persists them in the local entitlement repositories. The PDP references the local repository for run-time policy decisions. To handle reliable delivery of policy updates, an MOM-based infrastructure is recommended for PAP-PDP communication; currently the replication works only with JMS. Figure 1-2 depicts an application-level replication deployment:

Figure 1-2 Application-level replication deployment

Database-level replication is transparent to CEPM. In this approach, a custom or pluggable persistence layer can be introduced that handles database replication without the involvement of any CEPM components. This approach is useful when you apply proprietary data replication algorithms and technologies for managing entitlement data. Figure 1-3 depicts a database-level replication deployment:

Figure 1-3 Database-level replication deployment

Shared-nothing

In the shared-nothing deployment, even the PAP is not shared across geographies. Each geography deploys its own instance of the PAP that persists the entitlement data locally. The PDPs connect to the local entitlement repository and hence, do not require messaging directly with the PAP.

Figure 1-4 Shared-nothing deployment

Policy updates performed in one PAP (using the PAP UI or PAP APIs) automatically result in an event that is published to other peer PAPs that are distributed geographically over a highly-available MOM infrastructure. Alternatively, custom persistence layer mechanisms (discussed in Shared-PAP only) can also be used to automatically persist and replicate data across multiple repositories.

In all of these cases, Policy Enforcement Points (PEPs) can be configured to failover to alternate instances of PDPs across geographies. So, in cases where a local clustered deployment of PDPs (out-of-process) is unreachable, the PEPs automatically fail over temporarily to other instances of the PDP. PDPs can be deployed for load-balancing (round robin) within geographies.

CEPM supports a rich entitlement policy model. The sizing estimates in this document are based on an educated guess of the complexity of policies being resolved. For the workload indicated in scenario 1, the PDP in the U.S. should be deployed over four servers, and the PDPs in Asia and Europe should be deployed over two servers each. Since the PAP is not involved in critical path decisions, the PAP can be deployed in a cluster of two servers for high availability.