Previous Page | Next Page

Best Practices for Configuring Your Middle Tier

Sample Middle-Tier Deployment Scenarios

Overview of Middle-Tier Deployment Scenarios

This section describes sample topologies for the middle-tier components. These sample topologies can help you design a middle-tier configuration that meets the needs of your organization with regard to performance, security, maintenance, and other factors.

As with all tiers in the SAS Intelligence Platform, deployment of the middle tier involves careful planning. When you design and plan the middle tier, you must balance performance requirements against a number of other criteria. To understand these criteria and to evaluate sample deployment scenarios, see the following subsections:

The topologies that are presented here range from simple to complex. Scenario 1 represents the deployment that results from using the SAS Deployment Wizard to configure the Web application server and deploy the SAS Web applications. Scenarios 2 and 3 provide advanced features, such as greater security and efficiency, but require more effort to implement and to maintain.

All scenarios include the SAS server tier. The server tier consists of a SAS Metadata Server that resides on a dedicated machine. The server tier also includes additional systems that run various SAS application servers, including SAS Workspace Servers, SAS Pooled Workspace Servers, SAS Stored Process Servers, and SAS OLAP Servers.

Scenario 1: Web Applications Deployed in a Single Web Application Server

Scenario 1 illustrates the most basic topology. All of the SAS middle-tier components are installed on a single system. All the SAS Web applications run in a single Web application server. The SAS Remote Services application is also installed on the same middle-tier server, but runs as a server application outside the Web application server.

The following figure illustrates the topology for Scenario 1.

Scenario 1: Middle Tier on a Single System

[Scenario 1: Middle Tier on a Single System]

After installation, the system contains the following middle-tier software:

Here are the advantages and disadvantages of this topology:

Scenario 1 Advantages and Disadvantages
Topic Advantages Disadvantages
Security None The SAS Web applications are exposed to attacks from Web clients.

If SSL is enabled, the middle-tier server has the computational load of encrypting data, in addition to the load of hosting the SAS Web applications.
Performance None In 32-bit computing environments, the Java virtual machine might reach memory addressing limits.
Scalability None This topology does not support hundreds of concurrent users.
Availability None This topology has no provision for planned or unplanned down time.
Maintainability The SAS Deployment Wizard can automate the configuration and deployment.

This topology is simple to maintain and is ideal for development environments where frequent changes might be required.

 None


Further Considerations for Scenario 1

As the maintainability advantages in the previous table indicates, scenario 1 is easy to implement. This middle-tier topology can be completely installed and configured by the SAS Deployment Wizard. SAS provides another topology that can be completely installed and configured by the SAS Deployment Wizard, yet provides better scalability and performance.

In 32-bit computing environments, the scenario 1 topology can reach a performance limit due to the memory constraints of 32-bit addressing and the fact that all of the SAS Web applications are running in a single Java virtual machine that is provided by the Web application server. A variation of this scenario is to use the SAS Deployment Wizard to distribute the SAS Web applications across two Web application server instances (managed servers) on the same middle-tier server. This distribution of Web applications is different from clustering in that there is still only one instance of each application. By distributing the applications to two managed servers, this alternative configuration allows more memory availability for the applications deployed on each managed server and also increases the number of users that can be supported. Some SAS Solutions and some Web application servers that use 32-bit Java environments are configured with multiple servers by the SAS Deployment Wizard automatically. However, you can choose to configure multiple managed servers by running the wizard with the custom prompting level and selecting this feature.

Scenario 2: Static Content Deployed in a Reverse Proxy

This sample topology delivers static HTML content to clients from an HTTP server that is configured as a reverse proxy. This strategy reduces the work load on the Web application server. Examples of HTTP servers that can be configured as reverse proxies are Apache HTTP Server and Microsoft Internet Information Services (IIS).

When a browser makes a request for a SAS Web application, a part of the request is for static content such as HTML files, images, cascading style sheets, and JavaScript scripts. The SAS Themes Web application provides this static content. In this scenario, the SAS Themes content is unpacked and delivered by the reverse proxy. The reverse proxy simply returns the requested content to the browser, and the browser displays the document.

Note:   If you unpack and deploy the SAS Themes static content on the reverse proxy, then you must redeploy this content if you later install a SAS software upgrade or apply maintenance that includes new files for the static content.  [cautionend]

If the reverse proxy can be configured to cache content, then the performance improvement is even greater. The portion of the request that is for dynamic content still requires some type of data manipulation by the SAS Web applications and the Web application server must perform that work before returning the requested page.

The following figure illustrates the topology for scenario 2.

Scenario 2: Using a Reverse Proxy

[Scenario 2: Using a Reverse Proxy]

In a typical configuration, the HTTP server is configured with a module or plug-in that enables the reverse proxy function of communicating with the Web application server. By having the reverse proxy as the single point of contact for browser requests, the Web application server is not directly exposed to clients. The reverse proxy provides a layer of security for the SAS Web applications.

Although this topology must be manually configured and maintained, here are the advantages and disadvantages of this topology:

Scenario 2 Advantages and Disadvantages
Topic Advantages Disadvantages
Security The reverse proxy provides a layer of security.

The network on the middle-tier server can be configured to reject HTTP packets that do not originate from the reverse proxy.

SSL can be enabled on the client side of the reverse proxy without affecting the work load on the Web application server or the performance of the SAS Web applications.

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.

 Adding firewalls to the network is a good next step.
Performance Response time is improved because processing static content is offloaded from the Web application server to the reverse proxy. As with scenario 1, in 32-bit computing environments, the Java virtual machine might reach memory addressing limits. However, a second managed server instance can be configured, as mentioned in the scenario 1 section.
Scalability There are no advantages in this scenario, but the topology provides an upward path to clustering Web application servers. This topology does not support hundreds of concurrent users.
Availability None This topology has no provision for planned or unplanned down time.
Maintainability The SAS Deployment Wizard can still automate the configuration and deployment of the Web application server and the SAS Web applications. After manual or automatic installation and configuration with the SAS Deployment Wizard, there are manual steps to perform.

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

For instructions about how to configure an HTTP server as a reverse proxy for SAS Web applications deployed on JBoss, WebSphere Application Server, or WebLogic Server, see the SAS third-party Web site at http://support.sas.com/resources/thirdpartysupport/v92.

Scenario 3: Web Applications Deployed across a Web Application Server Cluster

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

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.

Scenario 3: Clustered Web Application Servers and a Demilitarized Zone

[Scenario 3: Clustered Web Application Servers and a Demilitarized Zone]

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.  [cautionend]

In the figure, note that the SAS Remote Services Application and SAS Content Server Web application reside on a host 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 hosts in the cluster. The separation in the figure also shows that the SAS Content Server Web application is a Web application that is deployed on a Web application server.

In this scenario, the SAS Content Server is not in a cluster.

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:

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
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. See Scenario 2: Static Content Deployed in a Reverse Proxy.

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 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.

Why session affinity is required: 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.

Additional Considerations for a Deployment

This section presents a few more things that you might want to consider when you plan your middle-tier deployment.


Load-Balancing Software and Hardware for the HTTP Servers

In scenario 3, the Web application servers are clustered to balance the load and to provide increased availability. While this scenario provides redundancy for the application servers, the HTTP server that is deployed as a reverse proxy remains a potential bottleneck and single point of failure. To improve availability and increase capacity, you can distribute HTTP traffic across multiple reverse proxies by placing load-balancing software or hardware in front of those servers. A single load-balancing component can accept client HTTP requests and distribute those requests across a cluster of reverse proxies.

A number of vendors sell load-balancing software and hardware products for HTTP servers, including IBM, Cisco, and Nortel. If you are interested in this type of load-balancing, you can explore the product lines for these and other vendors.


Secure Sockets Layer

If you are moving sensitive information across the Internet, then you might want to use HTTPS and Secure Socket Layer (SSL) to encrypt your communication links. SSL uses Public Key Cryptography, which is based on the implementation of a public and private key pair. Each of your servers that handles encrypted communications manages certificates that contain both the private key and the public key. A description of how Public Key Cryptography and SSL work is beyond the scope of this document. However, there are many good sources for that information.

Here are some factors to consider when determining whether and how to use SSL:


Web Authentication

By default, SAS Web applications use the form-based authentication that is provided by the SAS Logon Manager Web application. When credentials are provided to the SAS Logon Manager Web application, the credentials are sent to the SAS metadata server for authentication. The metadata server then authenticates the credentials against its authentication provider. The default provider is the host operating system.

As an alternative, you can configure the SAS Web applications to authenticate on the middle tier. When users log on to a SAS Web application, the Web application server handles the initial authentication. In this configuration, the Web application server's JAAS login module authentication provider verifies the user's identity. Then, the SAS Logon Manager Web application makes a trusted user connection to the metadata server to check that the authenticated user has a SAS identity in metadata.

Performing Web authentication facilitates single sign-on. Most likely, your organization has several applications behind a common set of reverse proxy and HTTP servers. By having a common server handle authentication, users do not need to re-authenticate for access to each application.

For more information, see the following topics:


Heap Size for SAS Remote Services Application

Middle-tier applications use the SAS Remote Services Application to pass session and user context between Web applications. The SAS Remote Services application enables the user to pass seamlessly through to the target without the requirement for a separate logon.

During installation, the SAS Deployment Wizard enables you to specify the desired initial and maximum heap size for the Remote Services application by using the JVM option format.

JVM options of the SAS Remote Services Application are set to handle a moderately high number of concurrent users. For a very large number of concurrent users and a distributed SAS 9.2 topology, you should tune the JVM options to accommodate the deployment.

If you use the Windows service, you can increase the minimum and maximum heap size of the SAS Remote Services Application. Edit the wrapper.conf file located in the SAS-configuration-directory\Lev1\Web\Applications\RemoteServices directory.

Alternatively, you can add the recommended JVM options to one of the following scripts:

Previous Page | Next Page | Top of Page

Copyright © 2010 by SAS Institute Inc., Cary, NC, USA. All rights reserved.