A deployment architectureis a mapping of software components to a hardware environment. More specifically, for the Portal Service on Application Server Cluster reference configuration, it represents how to map the components in the logical architecture to networked computers in a way that achieves the specified quality-of-service requirements.
The logical architecture in Figure 2–1 identifies the components that are needed to meet the functional requirements of the reference configuration. The deployment architecture, however, shows how to do so with the specified quality of service.
The following sections present the deployment architecture diagram and discuss how the deployment architecture addresses the quality-of-service requirements:
The quality-of-service requirements for the portal service on Application Server Cluster reference configuration are summarized in the following table.Table 2–4 Quality-of-Service Requirements for the Reference Configuration
Response time under two seconds for default portal channels at peak load levels.
Service availability with both user session availability and application session state availability.
No single points of failure.
Protected services in separate network subnets.
Firewall protection for Internet access and for portal service subnet zone.
Encrypted Internet transport over SSL.
Easily scalable so that no computer system is more than 80% utilized under daily peak load. Also the deployed system should accommodate long-term growth of 10% per year.
Minimize planned downtime needed to scale the portal service or to upgrade software components in the configuration.
Figure 2–2 is a graphical representation of the deployment architecture for the Portal Service on Application Server Cluster reference configuration. It shows the following features of the deployment architecture:
The grouping of computers, components, and load balancers into service modules
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.
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.
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.
The deployment architecture that is represented in Figure 2–2 uses several strategies to meet the availability requirements of the reference configuration. Availability requirements fall into the two categories that are discussed in the following sections:
Service availability means that a service is available, even when a service provider fails. Service availability is generally achieved using multiple identically configured service instances (redundancy). Redundancy eliminates single points of failure (assuming that simultaneous failure of all instances is extremely unlikely). If one instance providing a service fails, another instance is available to take over. This mechanism is known as service failover.
Service failover is supported in the reference configuration through two mechanisms:
Load balancing. Load balancing uses redundant hardware and software components to distribute requests for a service among multiple component instances that provide the service. This redundancy provides greater capacity than would be possible with a single instance. This redundancy also means that if any one instance of a components fails, other instances are available to assume a heavier load. Depending on the latent capacity that is built into the deployment, a failure might not result in significant degradation of performance. Load balancing is used in all of the service modules in the reference configuration.
Directory Server multimaster replication. The preferred solution for Directory Server, this mechanism provides data that is crucial to the operation of the entire deployment. Multimaster replication is specifically designed to synchronize data between the two (or more) Directory Server instances shown in the deployment architecture. Multimaster replication is the simplest directory service failover implementation and is suitable for all but the highest-end deployments that need to support millions of users.
Session state availability means that data associated with a user session is not lost during a service failover. When a service failover occurs, the session state data that is stored by the failed instance is made available to the failover instance. This mechanism is known as session failover. The result is that the service failover is transparent to the user: the user will not be required to log in again or to restart a business operation.
Session failover is supported in the reference configuration through two mechanisms:
Access Manager session failover. Access Manager session information is created when a user is authenticated and stored in a replicated database. This database is shared by Access Manager instances and accessed through Message Queue. If an Access Manager instance fails, the load balancer routes all user requests to a failover instance (service failover). The failover instance retrieves session information from the shared database and maintains the session.
Portlet session failover. The JSR 168 portlet specification requires portlets to map state information to an HTTP session. If a web container supports highly available HTTP sessions, and if a Portal Server instance fails, the HTTP session state can be recovered by the failover instance. In the reference configuration, Portal Server is deployed in an Application Server cluster, in which High Availability Session Store (HADB) is used to store and replicate portlet session state. The failover instance retrieves session information from HADB and maintains the session.
Portlet session failover requires availability of Access Manager session state. An Access Manager failure could therefore interfere with portlet session failover, unless Access Manager session failover is also implemented.
When a user is successfully authenticated with Access Manager, the browser is redirected to a Portal Server instance. A portal desktop session is created on this instance and is mapped to the user's Access Manager session. This portal desktop session is used to track Portal Server specific information such as the user's merged display profile and provider properties. If a Portal Server instance fails, the desktop session is automatically re-created by using the user's display profile and attributes that are stored in the Access Manager's user session. However, provider properties that are stored in local memory are lost.
The security requirements of the portal service reference configuration (see Security Requirements) are met through several mechanisms, each of which are discussed in the following sections:
Each user's access must be limited to the portal services and data channels that he or she is authorized to view.
The reference configuration uses Access Manager and Directory Server to control user access to portal content. The directory service maintains each user's portal desktop profile. This profile includes any desktop customization that is performed by the user, as well as mechanisms for determining what content the user is authorized to view.
The modularized architecture makes it easy for different organizations to administer different service modules so that each organization has the level of administrative security it needs. In most enterprises, for example, directory services and Access Manager services are administered by security-oriented organizations, while portal services are administered by end-user applications organizations.
The portal service must be secured against unauthorized and unauthenticated access.
The deployment architecture uses a secure network topology for the portal service, which includes the use of firewalls, controlled access through load balancers with virtual service addresses, and private subnets behind the firewall.
Figure 2–2 shows a portal services zone in which the portal service, Access Manager service, and directory service modules are deployed behind the Internal Firewall. Within this zone, the deployment architecture protects the service modules in the following ways:
A load balancer provides a single point of contact for the portal service, even though the service consists of two Portal Server instances that are running on two computers. This means that there is only one opening in the firewall for the portal service, and all of the traffic for the portal service is routed through the load balancer. Note that employees connected to the main corporate network also access the portal through this load balancer.
Local access to the portal service is only from trusted computers on the corporate network, by users who have authenticated themselves to the corporate network.
Not shown in Figure 2–2, but implied in the deployment architecture, is a network topology that creates separate subnets for accessing each service module. The IP addresses that are used in the subnets are private IP addresses, making the subnets invisible to the outside world. These subnets are connected only through the load balancers, further impeding the ability of intruders to access the actual computers behind the public URL. For more information on the network topology, see Network Connectivity Specification.
Not shown in Figure 2–2 is that the individual computers hosting service instances are hardened and that the operating system installations are minimized. Minimizing the number of installed Solaris OS packages means fewer security holes. Because the majority of system penetrations are through exploitation of operating system vulnerabilities, minimizing the number of installed operating system packages will reduce the number of vulnerabilities. Minimizing the operating system is covered in detail in Computer Hardware and Operating System Specification.
The secure remote access option provides secure access to portal services, applications, and other content on an internal intranet to employees or customers on the public Internet. This option prevents such access to unauthorized people.
The requirement for secure remote access is met in the Portal Service on Application Server Cluster reference configuration through Portal Server SRA components, specifically the SRA Gateway service, and by network access zones, demarcated by firewalls, that take maximum advantage of the SRA Gateway service. The access zones and the firewalls are represented in Figure 2–2.
The outermost zone in Figure 2–2 is the so-called demilitarized zone, or DMZ, which contains the SRA Gateway service. The Gateway service can only be accessed through the External Firewall at one specific URL. Employees or customers who connect to the portal service with remote browser clients or mobile clients do so by accessing the Gateway service at the specified URL. The External Firewall blocks all other ports and addresses.
Because remote access to the portal service from the public Internet is through the Gateway service, the portal service itself can reside behind an additional firewall (the Internal Firewall) and an additional layer of hardware load balancing.
In addition to deploying the Gateway service behind an Internet-facing firewall, the deployment architecture secures the Gateway service in the following ways:
The Gateway service requires the authentication of all users. Users who access the URL for the Gateway service in their browsers are presented with a login page and must type a user ID and password to gain access to any content.
The Gateway service instances are behind a hardware load balancer. The load balancer provides a single point of contact for the Gateway service, even though multiple component instances are running on multiple computers. As a result, only one port in the firewall is needed for the Gateway service, and all requests are routed through the load balancer.
The communication between the browser and the Gateway service load balancer is encrypted through using the SSL protocol. This protocol is required because this traffic will circulate through an unsecured network (the Internet). The SSL protocol also requires the use of server certificates to ensure that service providers have not been tampered with. Optionally, client certificates can be used to better authenticate access to the Gateway service.
The modular nature of the reference configuration's deployment architecture means that you can scale each module independently, depending on the kind of traffic that your portal service receives.
Each service module in the deployment architecture is composed of two or more service instances running on separate computers behind a load balancer. This architecture allows you to scale any of the modules vertically (by adding CPUs or memory to the host computers) or horizontally (by adding additional service instances). Some modules are better suited to vertical scaling, and some modules are better suited to horizontal scaling.
The recommended techniques for scaling each module in the reference configuration are as follows:
Scaling the directory service module:
Directory Server scales almost linearly up to 12 CPUs, so vertical scaling is an effective technique for this module.
A limitation on the performance of Directory Server is the complexity of the LDAP directory tree. Access Manager creates access control instructions (ACIs) for each Access Manager organization. Creating multiple organizations increases the load on Directory Server, as it must process more requests from Access Manager. At some point (at about 1000 organizations), vertical scaling is no longer effective.
In that case it becomes more effective to scale horizontally, keeping the multiple Directory Server instances synchronized by using the Directory Server's multimaster replication feature. Other approaches include trimming down the number of ACIs created for each organization and running Access Manager in realm mode instead of legacy mode. Having thousands of organizations is not a common requirement, so the reference configuration does not explore the architectural implications of large numbers of Access Manager organizations.
Scaling the portal and Access Manager service modules:
These modules can be scaled effectively by adding computers running additional component instances to the module. This approach is cost-effective and also helps maintain availability because spreading the load over additional computers ensures that only a relatively smaller amount of capacity will be lost if a single hardware system fails.
Both Portal Server and Access Manager run in web containers. When they run in a 32–bit web container, as described in this reference configuration, the maximum process size is 4 Gbytes of memory, limiting the number of user session objects that can be stored. If increased memory is needed or increased throughput is desired, these modules should be scaled horizontally.
It might seem that to better utilize memory (the computers used in the reference configuration have 16 Gbytes of memory), it would be possible to run multiple instances on the same hardware. However, this kind of vertical scaling breaks the modularity of the architecture and does not substantially increase throughput (the number of pages that are rendered per second).
Scaling the gateway service module:
The Gateway service can be scaled effectively by adding computers running additional component instances to the module. This approach is cost effective and also helps maintain availability because spreading the load over additional computers ensures that only a relatively smaller amount of capacity will be lost if a single hardware system fails.
The reference configuration architecture builds the portal service out of several subservices, such as the Access Manager service and directory service. Because each subservice is implemented in a separate module, it is possible to maintain each module independently.
In addition, the reference configuration architecture creates each subservice as a virtual service, which means that interoperability among the subservices is not dependent on specific hardware connections, and the individual subservices are maintained, upgraded, replaced, and scaled without affecting each other. For example, if it is necessary to add an Access Manager instance to the architecture, the Portal Server instances that depend on Access Manager do not need to be modified or affected in any way.