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:
n Which links do you want to encrypt? In the figures shown for the various scenarios, each arrow represents a potential communications link that might be encrypted. You should consider encrypting the following:
o Encrypt any data that is capable of moving across the public Internet. If
connections to your site go through a virtual private network (VPN), then those connections are already encrypted. Otherwise, traffic to and from your site is open to packet analysis by Internet users.
Sample Middle-Tier Deployment Scenarios 33
o Encrypt all traffic that moves between the client and your HTTP server that resides in the DMZ.
o Always encrypt traffic that is used to transmit credit card numbers, Social Security numbers, and any other sensitive information.
To achieve strong security, encrypt links all the way to the Web application server. If you are concerned about internal packet analysis, you can encrypt everything.
However, total encryption comes with a cost, as explained in the remaining considerations.
n Some load-balancing schemes might rely on packet content for routing. When that is the case, encryption can impede the work that is performed by load-balancing
software or hardware because encryption renders the packet content undecipherable.
n Cryptography requires resource-intensive computation, and this resource requirement typically reduces the amount of traffic that your servers are able to handle.
n The certificates that are used with SSL expire at fixed intervals. When a user's certificate expires, the user must obtain a new certificate before logging on to your applications. If you want a highly available system, then you should prepare for certificate renewal in advance to avoid unexpected downtime.
n You must decide whether to use certificates that are generated by a Certification Authority (CA), or whether self-signed certificates are adequate for your application.
Self-signed certificates can save you money, but you are responsible for managing their distribution to clients.
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
34 Chapter 2 / Best Practices for Configuring Your Middle Tier
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:
n For a detailed explanation of different types of authentication, see “Authentication Mechanisms” in the SAS Intelligence Platform: Security Administration Guide.
n For information about setting up the middle-tier applications to use Web authentication, see the SAS third-party Web site at http://support.sas.com/
resources/thirdpartysupport/v93.
n For information about achieving a single sign-on approach to authentication, see
“Using Single Sign-On among Web Applications” on page 44 .
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 SAS Remote Services application by using the JVM option format. You must run the SAS Deployment Wizard at the Custom prompting level to set these values.
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 topology, you should tune the JVM options to accommodate the deployment.
Sample Middle-Tier Deployment Scenarios 35
If you use the Windows service, you can increase the initial and maximum heap size of the SAS Remote Services application. Edit the wrapper.conf file located in the SAS-config-dir\Lev1\Web\Applications\RemoteServices directory.
Alternatively, you can add the recommended JVM options to one of the following scripts:
n On Windows:
SAS-config-dir\Lev1\Web\Applications\RemoteServices\RemoteServices.bat
n On UNIX and z/OS:
SAS-config-dir/Lev1/Web/Applications/RemoteServices/RemoteServices.sh