Designing the Deployment Architecture

The deployment architecture merges the two types of information found in the logical architecture and the quality of service requirements. To design your deployment architecture you must consider such questions as the following:

• Which redundancy strategies are you using to meet your availability and reliability requirements? The main redundancy strategies available to you with Java ES are the following:

  • Installing and configuring multiple instances of a component and load balancing the instances

  • Installing and configuring multiple instances of a component on Sun Cluster nodes

  • Using multiple instances of Directory Server that are synchronized through the multimastering and replication features

• How many instances of each component must be installed and configured in order to implement the redundancy strategies you are using in the solution? How many instances must be installed and configured to satisfy your performance requirements?

• How are your component instances combined on your computers? For example, in a medium-sized solution, you could install and configure instances of both Portal Server and Access Manager on a single computer. In a larger solution with more user activity, you might install Portal Server and Access Manager on separate, dedicated computers to meet your performance requirements.

• How many CPUs are needed on each computer to achieve the performance specified in your quality of service requirements?

In addition to answering these questions, you analyze use cases and usage information and determine how the Java ES components and other software can be deployed on your network to provide access and security.

This section describes how the SunWeb team analyzed the SunWeb use cases and developed a deployment architecture.

Analyzing User Interactions with the SunWeb Components

The main user interactions with the set of components used for the SunWeb deployment are illustrated in Figure 3–2 and Figure 3–3. These figures show how users interact with the Java ES components in the proposed logical architecture to obtain the specified services. As you continue the design process, you analyze the component interactions represented in these figures, factor in the user base and usage patterns, and begin to make decisions about a deployment architecture that supports these interactions with the specified quality of service.

Notice that the security requirements are being considered at this stage of the analysis. The figures include proposed access zones for the SunWeb deployment.

The following figure illustrates the interactions between a user who is logged in to the corporate network and the Java ES components in the proposed logical architecture for the SunWeb deployment.

Figure 3–2 Local User Interactions

The interactions shown in the preceding figure are described in the following table.

Table 3–1 Interacting With SunWeb Components Over the Corporate Network

Step	Description
1	A user logs in to a computer connected to the corporate network. The computer can be physically connected to the corporate network or connected to the corporate network over the public Internet with a virtual private network (VPN) session.
2	The user starts a web browser and opens the SunWeb URL. This request is directed to a custom wrapper for the Portal Server desktop servlet.
3	The Portal Server desktop servlet wrapper checks for a SunWeb session cookie:  If the cookie exists (meaning that the user is already authenticated for SunWeb), the Portal Server formats the user's personalized desktop as described in step 5. If the cookie does not exist (meaning that the user has explicitly logged out of his or her previous session), the desktop servlet displays an anonymous view of the SunWeb desktop. The anonymous view includes fields for user ID and password. The user can work with the anonymous view or log in, as described in step 4.
4	If the user supplies a user ID and a password in the desktop login fields, SunWeb's Access Manager (4a) uses a custom authorization module to authenticate the user's ID and password against the corporate LDAP directory (4b). When the user is authenticated, Portal Server displays the user's personalized desktop view, as described in step 5.
5	To display the user's SunWeb desktop, Portal Server aggregates content from a variety of sources. The specific content that appears on each user's personalized desktop is determined by a portal profile that is managed by the SunWeb Access Manager (5a) and stored in the SunWeb Directory Server (5b). The Portal Server mechanisms for aggregating content are described in the following list:  Static content: The Portal Server's URLScraper feature pulls static content that is stored in the local file system as HTML files. These local files are updated every ten minutes by the Portal Content Deliverer (PCD). The PCD scans source material on the corporate content management system (CMS) and updates the local content as necessary. Dynamic content, including the portal mail, calendar, and blog channels: The Portal Server's URLScraper feature dynamically pulls content from URL addresses on the main corporate network (5c) and presents it on the user's desktop.
6	The user reviews his or her portal desktop and chooses to review details of one or more channels.
7	The user can end his or her desktop session by closing the web browser window or by explicitly logging out of the SunWeb portal. If the user closes the web browser window, the SunWeb cookie persists. If the user explicitly logs out, the SunWeb cookie is deleted, and the user must log in to the SunWeb portal again at the beginning of his or her next session.

The following figure illustrates the interactions between an employee who accesses SunWeb services over the public Internet and the Java ES components in the proposed logical architecture.

Figure 3–3 Remote User Interactions

The interactions shown in the preceding figure are described in the following table.

Table 3–2 Interacting With SunWeb Components Over the Internet

Step	Description
1	From a computer not connected to SWAN or a mobile device, the user starts a web browser and opens the URL for SunWeb remote access. This request is routed to the SunWeb gateway service, provided by Portal Server Secure Remote Access.
2	The gateway service displays a login window to the user.
3	The user enters both an ID and a dynamically generated token card code.
4	SunWeb components authenticate the user as follows:  The gateway passes this information to Access Manager (4a). Access Manager uses its SafeWord Module, a standard Access Manager feature, to authenticate the information with the corporate SafeWord service (4b).  If the user is authenticated, the SunWeb portal service displays the user's personalized desktop, as described in step 5. If the user is not authenticated, the user is prompted again for password and token card code.
5	To display the user's SunWeb portal desktop, Portal Server aggregates content from a variety of sources. The specific content that appears on each user's personalized desktop is determined by a portal profile that is managed by the SunWeb Access Manager (5a) and stored in the SunWeb Directory Server (5b).   The Portal Server mechanisms for aggregating content are described in the following list:  Static content: The Portal Server's URLScraper feature pulls static content that is stored in the local file system as HTML files. These local files are updated every ten minutes by the Portal Content Deliverer (PCD). The PCD scans source material on the corporate content management system (CMS) and updates the local content as necessary. Dynamic content, including the mail, calendar, and blog channels: The Portal Server's URLScraper feature dynamically pulls content from URL addresses on the main corporate network (5c) and presents it on the user's desktop.
6	The user reviews his or her portal desktop and chooses to review details of one or more channels.
7	The user closes the web browser and ends the SunWeb session.

Representing the Deployment Architecture Graphically

As you analyze your requirements and user interactions, you develop a graphical representation of your proposed deployment architecture. The graphical representation uses a set of boxes that represent the computers in the deployment. Each box in the figure is labeled with the name of the computer and the components that are installed on the computer. The deployment architecture for the SunWeb deployment is illustrated in the following figure.

Figure 3–4 SunWeb Deployment Architecture

---

Note –

The system names that appear in the preceding figure are not the names used in the actual SunWeb deployment. The system names in the figure are used only to illustrate the architecture.

---

Choosing Redundancy Strategies for the SunWeb Architecture

The architecture represented in the preceding figure uses two redundancy strategies to meet the quality of service specified for the SunWeb deployment. The two redundancy strategies, load balancing and Directory Server multimaster replication are chosen for the following reasons:

• Load balancing. This solution is preferred for components that do not need to synchronize database updates. Load balancing uses redundant hardware and software components to distribute requests for a service among multiple components instances that provide the service so that no single instance is overloaded. 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 built into the deployment, a failure might not result in significant degradation of performance. Load balancing is used for several components in the SunWeb architecture, for example, the Portal Server and Access Manager components on sunwebPS1 and sunwebPS2.

• Directory Server multimaster replication. This solution is preferred for Directory Server, which provides data that is crucial to the operation of the entire deployment. Multimaster replication is specifically designed for Directory Server and is therefore relatively easy to implement. The SunWeb architecture uses Directory Server multimaster replication for all the Directory Server instances included in the SunWeb deployment. The SunWeb architecture uses two instances of Directory Server. All eight instances of Access Manager normally connect to the primary Directory Server instance. If the primary Directory Server fails, all eight instances of Access Manager fail over to the secondary Directory Server.

Choosing Security Strategies for the SunWeb Architecture

The requirements for the SunWeb portal service posed the following security challenges:

• First, each employee's access must be limited to the services and data channels that he or she is authorized to view.

• Second, the SunWeb portal service must allow Sun employees secure remote access to SunWeb services and data channels over the public Internet while preventing unauthorized people from accessing the portal.

For more information on the security requirements, see Security Requirements.

The SunWeb architects met the first challenge by including Access Manager and Directory Server in the deployment to control employee access to portal content. These Access Manager and Directory Server instances are separate from the main corporate LDAP service. The SunWeb directory service is dedicated to maintaining each employee's portal desktop profile. The desktop profile includes any desktop customization performed by the employee, as well as LDAP attributes and object classes that determine what content an employee is authorized to view. For more information on this aspect of the deployment, see The LDAP Schema.

The SunWeb architects met the second challenge by including the Portal Server Secure Remote Access component and its gateway service in the deployment and by designing network access zones that take maximum advantage of the gateway service. The access zones are demarcated by firewalls. The access zones and the firewalls are represented in Figure 3–4.

The outermost zone in Figure 3–4 is the demilitarized zone (DMZ), which contains the portal gateway. The DMZ is reasonably secure. The portal gateway service behind the firewall can be accessed at one specific URL only. Employees who connect to the SunWeb portal with remote web browser clients or mobile clients access the gateway service at the specified URL. The firewall blocks all other ports and addresses.

In addition to deploying the gateway service behind Firewall 3 in the DMZ, the SunWeb architecture protects the gateway service in the following ways:

• The gateway service requires users to authenticate themselves. Employees who open the URL for the gateway service in their web browsers are presented with a login page. Employees must enter a user ID and a dynamically generated password to gain access to any content.

• The computers that provide the gateway service 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, there is only one opening in the firewall for the gateway service, and all of the traffic for the gateway service is routed through the load balancer.

• Not shown in Figure 3–4, but implied in the deployment architecture, is a network topology that creates separate subnets for each of the access zones. The IP addresses used in the subnets are private IP addresses, making the subnets invisible to the public Internet. These subnets are connected only through the load balancers, further impeding the ability of intruders to see the actual computers behind the public URL. For more information on the network topology, see Preparing the Network and Connectivity Specification.

The next zone, behind Firewall 2, is the SunWeb subnet. This zone contains the actual SunWeb portal service, which is provided by eight instances of Portal Server, supported by eight instances of Access Manager and two instances of Directory Server. This zone is defined by an additional firewall (Firewall 2).

In addition to deploying the portal service on its own subnet behind Firewall 2, the SunWeb architecture protects the portal service in the following ways:

• Remote access to the portal service from the public Internet is controlled by the Portal Server SRA gateway service in the DMZ. All remote access to the portal service is through the gateway service. This aspect of the architecture allows the portal service to reside behind an additional firewall and an additional layer of hardware load balancing.

• The load balancer behind Firewall 2 provides a single point of contact for the portal service, even though the service consists of eight Portal Server instances that are running on eight computers. The load balancer is the only opening in the firewall for the portal service, and all of the traffic for the portal service is routed through the load balancer. Employees connected to the main corporate network also access the SunWeb portal through this load balancer.

• Local access to the portal service is only from trusted computers on the main corporate network after users have authenticated themselves to the corporate LDAP directory service.

• The computers running Portal Server and Access Manager are on a different subnet from the computers in the DMZ, and this subnet is defined by private IP addresses. The only bridge between the subnets is the hardware load balancer.

The main corporate network contains various corporate information services that are accessed by the SunWeb portal service. These services are protected by Firewall 1. In addition to Firewall 1, the main corporate network is protected by the following measures:

• There is no direct remote access to these corporate services. All remote access is indirect, through the Portal Server instances.

• The CMS only allows traffic from the PCD instances that are colocated with the Portal Server instances. All other traffic is blocked.

Not shown in Figure 3–4 is the fact that the individual computers running the Java ES services are hardened.

Planning for Scalability in the SunWeb Architecture

The Java ES services used in the SunWeb portal architecture are provided by multiple component instances running on multiple computers behind a load balancer. For example, the portal service is provided by eight Portal Server instances running on computers sunwebPS2 through sunwebPS9.

This architecture could be scaled either horizontally or vertically to handle more incoming connections in the following ways:

• To scale horizontally, the number of computers running Portal Server SRA instances could be increased, up to the capacity of the load balancing hardware. The architecture would remain essentially the same, but the load balancer would be distributing a greater number of incoming connections among a greater number of Portal Server SRA instances. The load on each component instance would remain constant. Similarly, the number of computers running Portal Server, Access Manager, and Directory Server could also be increased, as needed.

  The Access Manager and Directory Server instances could be installed on separate computers, giving each instance more computing resources.

• To scale vertically, additional Solaris 10 zones can be created, if the computers have sufficient memory and disk storage. You can install and run additional component instances in the new zones to increase the capacity of the Java ES services on a single computer hardware system.