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 (see Shared-nothing), the PDP can directly work against the database without requiring messaging from the PAP. 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 an enterprise standard messaging infrastructure such as a standard Message-Oriented Middleware (MOM). Using CEPM, you can configure PEPs to choose the protocol for communication with the PDPs; you can also add custom listeners. Policy decisions are communicated on the wire, along with prefetched policy decisions. In-memory PDP is not an option in this case.
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.
Tip
