Modularity in the Deployment Architecture

The reference configuration deployment architecture is based on a Service Delivery Network Architecture (SDNA) approach, in which individual services within a solution are modularized (see https://wikis.sun.com/display/BluePrints/The+Service+Delivery+Network-+A+Case+Study). The result is a deployment architecture consisting of four independent service modules: SRA Gateway, portal, Access Manager, and directory.

In accordance with SDNA principles, each service module in the reference configuration independently implements its own level of availability, security, scalability, and serviceability. The overall solution can therefore be easily deployed, secured, maintained, and upgraded. An explanation of how the reference configuration's modular architecture facilitates quality-of-service objectives is provided in subsequent sections of this chapter.

The service modules that make up the reference configuration, shown in Figure 2–2, have the following common SDNA characteristics:

• Each module consists of two or more instances of the service configured to meet quality-of-service requirements. Each module includes the components that are needed to provide a single service to the overall reference configuration.

  For example, the two Directory Server instances in Figure 2–2 can be considered a unit that provides directory services for the other components in the deployment.

• Each service module is accessed through a load balancer. The load balancer is configured to establish a virtual IP address, or virtual service address, for the module. Other components in the reference configuration are configured to send requests to the virtual service address rather than to the individual component instances.

  For example, when Access Manager needs information from the directory service, it addresses its request to the virtual directory service address that is provided by the load balancer, rather than to a specific instance of Directory Server.

  Each load balancer is responsible for routing incoming requests to a specific service instance, and, where desired, to route successive requests from the same user to the same service instance.

• The component instances in a module can be reconfigured without changing the virtual service address of the module, making changes within the module transparent to other components. Depending on the kinds of usage patterns you experience, you can independently assign system resources and scale each module to meet load requirements, using scaling techniques that are best suited to the module.

While the modular architecture depicted in Figure 2–2 has many advantages, as described in subsequent sections of this chapter, alternative approaches in common practice do exist. The drawbacks of two such alternatives, which are not supported by this reference configuration, are discussed below.

Not Supported: Portal Server and Access Manager Combined

In some situations, the modular architecture of Figure 2–2 might result in lower resource utilization than could be achieved by combining components on the same computer and running them in the same web container. In fact, many deployment architects have traditionally deployed Portal Server and Access Manager in the same web container in an effort to maximize resource utilization and reduce network traffic in updating Access Manager session information. However, such designs cannot realize the availability, security, scalability, and serviceability benefits of SDNA modularity, which generally outweigh the drawbacks.

Not Supported: Access Manager Internal Configuration for Multiple Directory Server Instances

Access Manager supports, by way of post-installation configuration, multiple LDAP directories for each Access Manger service. In this way, Access Manager can detect failure of a primary Directory Server instance and fail over to an standby instance. This built-in mechanism has several drawbacks:

• Configuration of these multiple Directory Server instances needs to be done for each of the Access Manger services: user profiles, policies, LDAP authentication, Membership authentication, and so forth.

• Access Manager does not load balance directory requests: only the primary DS instance is used, while the other(s) are inactive.

• Upon a failure of a primary instance, Access Manager switches over to the standby instance, but if the primary instance comes back online, there is no mechanism to revert back to the original configuration.

By contrast, the modular architecture of Fig 2-2 has the following advantages:

• The only required Access Manager configuration is the load balancer's virtual service address, specified at installation time.

• The directory services load balancer In the reference configuration routes requests to all Directory Server instances, monitors the health of these instances, automatically performs the failover and restoration of a failed instance.

• The modular architecture allows you to configure, manage, scale and monitor the Directory Server instances independent of the Access Manager instances.

In the multimaster replication approach of Figure 2-2, write operations are synchromized between directory instances. In environments with many write operations, the overhead of the multimaster replication process can slow down Directory Server processing of client requests. In these situations, the best approach is to direct all write operations to a single master by placing a Directory Proxy Server instance in front of each Directory Server instance. Such situations are not common in portal service deployments, so the reference configuration does not include Directory Proxy Server.