Feedback
Table Of Contents
Scenario 2: Centralized Architecture Deployment
Scenario 2: Centralized Architecture Deployment
The shared PAP and shared entitlement-repository option discussed in Chapter 1, "Scenario 1: Distributed Architecture Deployment" may be considered a "centralized" deployment that allows multiple applications to share a common administration and entitlement repository infrastructure.
A shared infrastructure that eliminates the need even to host the PDPs in different geographies is also supported with CEPM via the Shared-PAP and PDP model described in this chapter.
Note
The sizing estimates for this type of deployment are composed of the following elements:
•
•
•
•
Shared-PAP and PDP
With the PAP, entitlement repository, and PDP all located in the same data center, which can be fully replicated for high availability and disaster recovery purposes, the PDP can directly work against the database. The Policy Enforcement Points (PEPs) can be set to automatically failover across two instances of the shared PAP and PDP.
Because the PEPs are remote, they need to communicate with the PDPs via a secured communication channel.Using CEPM, you can configure PEPs to choose the protocol for communication with the PDPs over (HTTPS and RMI). Policy decisions are communicated on the wire.
Figure 2-1 Shared PAP and PDP
Because of the diversity of business and organizational needs that change over time, a hybrid approach of PDP deployments is the most effective. In such an approach, some shared PDP deployments can be used by some applications for testing and production purposes. Some distributed PDPs are deployed closer to the applications but they still share the centralized PAP instances using delegated access.
In all of these scenarios, additional requirements may be imposed to restrict sharing of entitlement repositories or PDPs across different applications, which can be handled in one of two ways:
•
•
Figure 2-2 shows a deployment with no sharing of entitlement repository data in the context of a shared PAP and PDP:
Figure 2-2 Deployment of Shared PAP and PDP Model
For all workloads, such things as the number of applications, depth of resource, group, and role hierarchy, besides the complexity of rules, affect sizing estimates. For workload 2, the variance may be higher. However, eight servers in New York and four each for the other two geographies should be enough, which totals 16 servers running PDPs for all geographies. With the administrative workload expected to be higher because of increased users, PAP must be deployed in a load-balanced cluster of four servers. Database sizing depends on the actual number of users.
All of the scenarios described in this guide easily coexist with reporting tools, such as Actuate and Microstrategy, via the PAP entitlement review APIs and supported database schemas for logs. Table 2-1 details the requirements for CPUs and memory.
Component Guidelines
Cisco Enterprise Policy Manager is agnostic to server platforms and versions for CEPM components such as the PAP and PDP servers.
Tip
Table 2-1 Policy Cache Memory Requirements
100,000
1000
20,000
400 MB
250 MB 1
1 When the heap size for the application server is set to 2-3 GB.
Table 2-2 Software Component Specifications (Scenario 1)
Oracle
10g or 11g
2
JDK
1.6
Number of PDP and PAP instances
PAP
-
2 server instances
PDP
-
8 server instances
PEP
-
Varies
1 CEPM has been tested with and supports the component scenario listed in this table.
Table 2-3 Software Component Specifications (Scenario 2)
Oracle
10g or 11g
4
JDK
1.6
Number of PDP and PAP instances
PAP
-
4 server instances
PDP
-
16 server instances
PEP
-
Varies
1 CEPM has been tested with and supports the component scenario listed in this table.
