Web Applications Deployed across a Web Application Server Cluster

Overview

The sample topology in scenario 3 includes a cluster of Web application servers in a network that implements a secure demilitarized zone (DMZ).

28 Chapter 2 / Best Practices for Configuring Your Middle Tier

The following figure illustrates the topology for scenario 3. Note that the Web application servers and SAS Web applications are distributed across multiple middle-tier machines.

Figure 2.3 Scenario 3: Clustered Web Application Servers and a Demilitarized Zone

SAS Workspace Server SAS Web Infrastructure Platform SAS Content Server SAS Stored Process SAS Package Viewer SAS Information Delivery Portal SAS BI Portlets

SAS Web Report Studio SAS BI Dashboard SAS Help Viewer for the Web SAS Workflow

SAS Web Administration Console SAS Shared Web Assets SAS Theme Designer for Flex

Note: As indicated in the figure, if you configure a cluster of Web application servers, then you must deploy all the SAS Web applications to each node in the cluster. Each node must be configured identically.

In the figure, note that the SAS Remote Services application resides on a machine that is separate from the cluster of Web application servers. This separation serves to illustrate that the SAS Remote Services application is a server application that does not participate in clustering. The SAS Remote Services Application could just as well reside on any one of the machines in the cluster.

Sample Middle-Tier Deployment Scenarios 29

Although this topology requires manual configuration and greater maintenance than the topologies in the previous scenarios, here are the advantages and disadvantages of this topology:

Table 2.3 Scenario 3 Advantages and Disadvantages

Topic Advantages Disadvantages

Security The SAS Web applications and the Web application server cluster are protected by the DMZ.

The Web application server and SAS Web applications can be configured to perform Web

authentication for single sign-on to SAS Web applications and other Web resources in the network.

None

Performance Response time is improved because processing static content performed by the reverse proxy and because of the greater computing capacity of the Web application server cluster.

None

Scalability Once the cluster of Web application servers is established, additional managed servers can be added to the cluster to support larger numbers of concurrent users.

None

Availability Clustering provides fault isolation that is not possible with a single Web application server. If a node in the cluster fails, then only the users with active sessions on that node are affected.

You can plan downtime for maintenance by taking managed servers offline. New requests are then directed to the SAS Web applications deployed on the

remaining nodes while maintenance is performed.

None 30 Chapter 2 / Best Practices for Configuring Your Middle Tier

Topic Advantages Disadvantages Maintainability Configuration and deployment of

the first Web application server and the SAS Web applications can still be automated with the SAS

Deployment Wizard. This first Web application server can be cloned to speed the creation of the cluster.

The reverse proxy must be configured with the connection information for the SAS Web applications.

Creating the Web application server cluster requires additional

configuration.

Understanding Clusters

In order to provide greater scalability, availability, and robustness, WebLogic Server, WebSphere Application Server, and JBoss support some form of clustering. With clustering, multiple Web application server instances participate in a load-balancing scheme to handle client requests. Workload distribution is usually managed by the same application server plug-in module that enables the use of a reverse proxy for static content.

The Web application server instances (managed servers) in a cluster can coexist on the same machine (vertical clustering), or the managed servers can run on a group of middle-tier server machines (horizontal clustering). The SAS Web applications can be deployed on both vertical and horizontal clusters.

A different approach to load distribution involves merely deploying individual SAS Web applications on separate, non-clustered Web application servers. Though this approach reduces the memory load for any given server, a clustering strategy is preferable.

Deployment is easier to manage with a cluster because all machines and server instances are identically configured. Furthermore, Web application servers provide deployment management services that facilitate management of a cluster. It is relatively easy to add additional nodes and increase the size of the cluster.

Requirement for Session Affinity

For SAS Web applications to be deployed into a clustered environment, the Web application servers must implement session affinity. Session affinity is an association between a Web application server and a client that requests an HTTP session with that server. This association is known in the industry by several terms, including session affinity, server affinity, and sticky sessions. With session affinity, once a client has been

Sample Middle-Tier Deployment Scenarios 31

assigned to a session with a Web application server, the client remains with that server for the duration of the session. By default, session affinity is enabled in WebSphere Application Server and WebLogic Server.

Although WebSphere Application Server, WebLogic Server, and JBoss provide the ability to migrate HTTP sessions from one server to another, the SAS Web applications do not support this capability. Business intelligence sessions often contain large data elements, such as results sets from ad hoc queries, reporting, and analytical tasks, that cannot be migrated easily among Web application servers.

Understanding Demilitarized Zones

Many organizations use a series of firewalls to create a demilitarized zone (DMZ) between their servers and the client applications. A DMZ provides a network barrier between the servers and the clients. A DMZ provides this protection whether the clients reside within the organization's computing infrastructure (intranet) or reside outside the organization on the Internet.

In the previous figure, the outer firewall that connects to the public network is called the domain firewall. Typically, only the HTTP (80) and HTTPS (443) network ports are open through this firewall. Servers that reside directly behind this firewall are exposed to a wide range of clients through these limited ports, and as a result the servers are not fully secure.

An additional firewall, the protocol firewall, is configured between the non-secure

machines in the DMZ and the machines in the secure middle-tier network. The protocol firewall has additional network ports opened. However, the range of IP addresses that are allowed to make connections is typically restricted to the IP addresses of the servers that reside in the DMZ.

The DMZ usually contains HTTP servers, reverse proxies, and load-balancing software and hardware. Do not deploy Web application servers or any SAS servers that handle important business logic, data, or metadata in the DMZ.

If your applications are accessed by clients through the Internet, then you should

include a DMZ as part of your deployment in order to safeguard critical information. For deployments on a corporate intranet, you might want to implement a DMZ as an

additional layer of security.

32 Chapter 2 / Best Practices for Configuring Your Middle Tier