Clustering and Securing Web Applications: A Tutorial

Print-friendly Version

[Part 1] [Part 2]

Delivering continuously available, secure, and high-performance Web applications is a vital concern of many businesses. For simple clustering, failover, and encryption, popular application and Web servers include a software load-balancing and encryption plug-in that can reside on a Web proxy server. In large-scale deployments, it is more common to employ load-balancers and hardware accelerators for encryption and firewalls. Since those hardware appliances are usually from different vendors, the resulting complexity can be daunting. Ensuring correctness, reliability, and interoperability may entail huge costs and an inordinate amount of time.

Alternatively, you can secure and cluster applications with a unique appliance, Sun Secure Application Switch (henceforth, Application Switch), which combines load-balancing, failover, encryption services, into one single appliance. Two other major benefits—

• Switch virtualization, that is, the creation of multiple, virtualized load-balancers and security domains within a single switch. You can partition device resources into multiple virtual switches, each with its own application switching, load-balancing, Secure Socket Layer (SSL) acceleration, and management policies and quotas. Also, you can create virtual switches to obtain robust isolation of network traffic that would otherwise require firewalls along with complex access-control rules.
  
  
• L4 and L7 load-balancing and Virtual Local Area Networks (VLANs), which can function in parallel with virtual switching. The strong virtualization capabilities enable the consolidation of multiple Web infrastructure networks into a single device. For details, read the white paper Network Virtualization and Consolidation With the Sun Secure Application Switch and other Application Switch-related documentation under References in this tutorial.

This tutorial describes how to set up Application Switch to load-balance requests to a simple, clustered application; to transparently secure access to that application; and to handle failover—all with Sun Java System Application Server (henceforth, Application Server). You can apply a similar procedure with other leading application servers and Web servers.

Note: In many cases, the values assigned to the parameters in the command lines are examples only. Replace those values with those that apply to your environment. Also, notwithstanding the line wraps, type the commands in one line.

The sample application, clusterjsp, in this tutorial demonstrates how load-balancing and failover function. Figure 1 shows the architecture for deploying clusterjsp on an application-server cluster.

Figure 1: Deploying a Single Application-Server Cluster

This configuration is typical of large intranets or content delivery portals. Often, SSL is not required or is selectively enabled for certain sensitive content, such as login and password collection screens. Here, we assume that SSL is terminated at Application Switch.

You can use Application Switch in advanced deployment scenarios, such as those discussed in the section Alternative Deployment Architectures in this tutorial.

As a first step, create a simple application-server cluster with two server instances that run on two distinct hosts (machines). Alternatively, you can complete the exercise by having the two instances run on the same host that listens on different ports.

Figure 2 illustrates the deployment and configuration you'll accomplish at the end of the exercise.

Figure 2: Deployment and Configuration of Sample Application-Server Cluster

Simulate the cluster in either of two ways:

• With Project GlassFish, an open-source, application-server implementation of Java Platform, Enterprise Edition 5 and the basis for Sun Java System Application Server Enterprise Edition 9. This option takes about 30 minutes.
  
  
• With Sun Java System Application Server Standard Edition or Enterprise Edition. This option takes longer, up to 90 minutes. Adopt this option if you have administrator privileges on your test systems and would like to evaluate the advanced management, monitoring, and high-availability capabilities.

Since Project GlassFish is targeted for developers, it does not support multimachine administration and failover. However, you can install Project GlassFish on two hosts and cluster them with Application Switch. This tutorial names those two hosts naut-10 and naut-11.

Do the following:

1. Download Project GlassFish. Click Download It and, on the download page, click the name of a recent build under "Promoted binary builds," for example, Build 36 01-Feb-06. On the b36 Promoted Build page, click the name of a binary build for your platform, for example, b36-glassfish-linux.jar. Then do the following:
   
   

   a.	Unpack and place the Project GlassFish bits on your disk. Type: java -Xmx256m -jar b36-glassfish-linux.jar Project GlassFish then creates an installation directory called glassfish. To install Project GlassFish, you must have Java 2 Platform, Standard Edition (J2SE platform) 5.0.
   b.	Configure Project GlassFish. Type these two commands: cd glassfish lib/ant/bin/ant -f setup.xml
   c.	Start Project GlassFish. Type: glassfish/bin/asadmin start-domain domain1 To verify that Project GlassFish has started up properly, check the server.log file in the logs directory or go to http://localhost:8080. We recommend that you read the GlassFish Quick Start Guide to familiarize yourself with the basic administrative operations.

   
   
2. Download clusterjsp, the sample application.
   
   The ZIP file includes the Java archive (JAR) and the source files.
   
   
3. Unzip the file to a directory of your choice.
   
   
4. Install and deploy clusterjsp. Type:
   
   GlassFish_install_dir/bin/asadmin deploy clusterjsp.ear
   
   
5. Repeat steps 1-4 on the other host.
   
   You've now installed clusterjsp into the default domain domain1 on two machines. Later on, you'll cluster the two machines with Application Switch.

Note: In the configuration steps for Application Switch, use the default HTTP listener port number of 8080 for Project GlassFish (instead of 38080).

To simulate the cluster with Application Server Enterprise Edition, which you can download for evaluation, do the following:

1. Go to the Solaris Enterprise System download site and select Sun Java Application Platform Suite under Sun Java Enterprise System. Click Downloads & Media.
   
   The Download Sun Products page is then displayed.
   
   
2. Click the arrow under the platform of your choice (Windows, Solaris, or Linux).
   
   You are then prompted to log in to Sun Developer Network (SDN) with your user name. If you are not an SDN member, simply sign up—membership is free!
   
   
3. Download Application Server Enterprise Edition for your platform (for example, the ZIP file on our test platform is called java_es_05Q4_appserver-gasolaris-sparc.zip). Unzip the file into a directory called basedir.
   
   
4. Change directory to basedir/java_es_05Q4_appserver/Solaris_sparc and execute the installer command.
   
   
5. Start the Domain Administration Server (DAS) and create and start node agents by following the procedures in the Quick Start Guide in the docs directory.

Next, create a working cluster. Do the following:

1. Set up a cluster by following the procedure in the section "Setting Up a Two-Machine Cluster without HADB [high-availability database] Configuration" in the Samples Guide at Application_Server_install_dir/samples/ee-samples/ee-setup.html.
   
   Since you are omitting the part on installing HADB, you will not see the recovery of session data after failover. Everything else works, however. If you can spare the time and hardware, we recommend that you also set up HADB.
   
   Again, this tutorial names the two hosts naut-10 and naut-11.
   
   
2. Deploy the sample application into clusterjsp at Application_Server_install_dir/samples/ee-samples/highavailability/apps/clusterjsp/clusterjsp.ear. Type:
   
   Application_Server_install_dir/bin/asadmin deploy --target cluster_name-availabilityenabled=true Application_Server_install_dir/samples/ee-samples/highavailability/apps/clusterjsp/clusterjsp.ear
   
   
3. Test the application by accessing each of the instances independently at http://Application_Server_instance_hostname:Application_Server_Instance_port_number/clusterjsp.

You are now ready to configure Application Switch.

This tutorial assumes that you have acquired and set up Application Switch in your network. For details on the procedures involved, see the Application Switch documentation.

In particular, do the following:

• Follow the procedures in the Quick Installation Guide and the System Administration Guide for Application Switch to ready the management interface for configuration. Note that the procedures are the same for versions 2.0 and 3.0.
  
  Also, for details on how to run the setup script, see page 11 of the Sun Secure Application Switch Getting Started Guide.
  
  
• Ensure that the machines that host the Application Server instances are ready to be physically connected to Application Switch. Alternatively, you can connect the servers to an existing L2 or L3 distribution network with a physical connection to Application Switch.

You can now administer Application Switch by accessing it at an IP address and port number. There are three ways to configure Application Switch: the HTTPS Web interface, the Secure Shell (SSH), or the Telnet-accessible command-line interface (CLI). This tutorial describes the procedure on the CLI.

You can connect to Application Switch on the CLI or from the Administration Console. On the CLI, type, for example:

# telnet 192.18.88.146

Here is an example of the output:

Trying 192.18.88.146...
Connected to 192.18.88.146.
Escape character is '^]'.
username: admin
password:

sun>

By default, Application Switch contains a "system" virtual switch (vSwitch) that typically connects clients or management networks. You set up the virtual LANs, routers, and load-balancer policy within a vSwitch instantiation.

Follow these steps to plumb the IP configuration for Application Switch and create an instantiation for the vSwitch to connect backend hosts and services:

1. Create a vSwitch. Type:
   

   sun> enable
   sun# config
   sun(config)# vswitch VS1
   

   When prompted with this question—
   

   Create new vSwitch "VS1"? (y or n):
   

   —type y in reply.
   
   
2. Exit. Type:
   

   sun(config-vSwitch-VS1)# exit
   

The vswitch command also creates a default vRouter that's associated with the vSwitch. To view the details that pertain to the vRouter, type:

sun(config-vSwitch-VS1)# show vrouter

Here is an example of the output:

ID:		     4
Name:		     bdefault
Description:	     Default vRouter
Admin State:	     enabled
Operational Status:  up

Proceed with the rest of the setup:

1. Configure the vRouter. Type:
   

   sun(config-vSwitch-VS1)# vRouter default
   

2. Create a VLAN for the services. Type:
   

   sun(config-vSwitch-VS1 vRouter-default)# vlan vlanName
   vlan168 vlanId 168
   

   where the value for vlanName (in this example, vlan168) is the name of the interface; vlanId specifies the VLAN identifier for this network. In the sample deployment, you have attached your two Application Server hosts to this VLAN.
   
   
3. Add physical interfaces to the VLAN. Type:
   

   sun(config-vSwitch-VS1 vRouter-default)# vlan vlan168
   interface ifName eth.1.1
   

   To add the second host, Type:
   

   sun(config-vSwitch-VS1 vRouter-default)# vlan vlan168
   interface ifName eth.1.2
   

   The above commands add ethernet interfaces 1 and 2 at the back of Application Switch to VLAN 168.
   
   
4. Assign an IP address to the VLAN. Type:
   

   sun(config-vSwitch-VS1 vRouter-default)# ip address
   vlan.vlan168 ipAddr 10.18.88.1 netMask 255.255.255.0
   

5. Exit. Type:
   

   sun(config-vSwitch-VS1 vRouter-default)# exit
   

Configure the load-balancer that's associated with the vSwitch, VS1, starting with creating IP addresses for the Application Server hosts.

1. Type:
   

   sun(config-vSwitch-VS1)# loadbalance
   

2. Create and name an Application Server host instance, assign it an IP address, and associate it with a vRouter, VS1 in our example. (In this example, the names are naut-10 (10.18.88.133) and naut-11 (10.18.88.134). Type:
   

   sun(config-vSwitch-VS1 loadBalance)# host naut-10 ipAddress
   10.18.88.133 adminState enabled vrouter VS1:default
   
   sun(config-vSwitch-VS1 loadBalance)# host naut-11 ipAddress
   10.18.88.134 adminState enabled vrouter VS1:default
   

Each of the hosts you create can provide service at TCP or UDP ports. For each port on which your Web service is available, you must create a real service to represent the HTTP listener ports of Application Server. Type:

sun(config-vSwitch-VS1 loadBalance)# realService name appServ10
hostName naut-10 protocol TCP port 38080

sun(config-vSwitch-VS1 loadBalance)# realService name appServ11
hostName naut-11 protocol TCP port 38080

The Application Server instances on the two hosts, naut-10 and naut-11, are both listening for HTTP requests at port 38080. You can change those port numbers for your setup, as necessary.

A service group represents a load-balanced cluster that comprises one or more real services. Here, you also choose the type of load-balancing to be performed by Application Switch. To create a service group for a cluster of two real-server instances defined earlier with the sticky-round-robin algorithm, type:

sun(config-vSwitch-VS1 loadBalance)# serviceGroup name
appServCluster loadBalanceType roundRobin {appServ10; appServ11}

When making a load-balancing decision, Application Server evaluates object rules—boolean predicates—on application URLs in a received request. An object rule is of the form ruleName {predicate}. clusterjsp contains only one context root (clusterjsp). To create an object rule that matches clusterjsp, type:

sun(config-vSwitch-VS1 loadBalance)# objectRule matchClusterJSP
{URI_PATH matches "/clusterjsp/*"}

clusterjsp contains no images. However, if it did and assuming that they reside on a Web-server farm under a different context root "/images/*", you would create an object rule to match and handle them appropriately. For example, type:

sun(config-vSwitch-VS1 loadBalance)# objectRule
matchImages{URI_PATH matches "/images/*"}

Note: You need not execute the above command in this tutorial.

A request policy performs two tasks:

• Tie the action in an object rule to a service group.
• Specify the evaluation order for the object rules

To forward a request that matches the object rule in the preceding section, type:

sun(config-vSwitch-VS1 loadBalance)# requestPolicy name
clusterJSP action forward objectRule matchClusterJSP
serviceGroupName appServCluster

You've now specified that Application Switch forward all the requests that match the object rule, matchClusterJSP, to the group of machines you've added to appServCluster.

Again, if images are being served from a parallel Web-server cluster, type:

sun(config-vSwitch-VS1 loadBalance)# requestPolicy name
getImages action forward objectRule matchImages
serviceGroupName webServCluster

Note: You need not execute the above command in this tutorial.

To have Application Switch insert a switch-managed cookie to track persistence independently of application-defined sessions, type:

sun(config-vSwitch-VS1 loadBalance)# cookiePersistence myCookie
mySESSIONID cookiePath {} cookieExpires {}

sun(config-vSwitch-VS1 loadBalance)# loadBalance requestPolicy
name clusterJSP persistType switchCookie cookiePersist myCookie

Next, assign an IP address with which clients will access the clustered and load-balanced sample application. A virtual service ties the list of request-policy assertions to the description of a client-visible service. Afterwards, the client recognizes the service group as if it were one service at a single IP address and port number that are specified under the virtual service.

You have three choices for the service type: HTTP, HTTPS, or L4 load-balancing.

An HTTP virtual service must include a list of request policies to apply to the traffic that is dispatched to this service. By default, this virtual service runs on port 80. To create an HTTP virtual service, type, for example:

sun(config-vSwitch-VS1 loadBalance)# virtualService name
VService1 appServiceType HTTP ipAddress 192.18.88.148
requestpolicyList {clusterJSP;}

The above command specifies 192.18.88.148 as the client-visible IP address. Replace it with an unused IP address in your network.

You are now ready to test the setup. Do the following:

1. In your browser (for example, Mozilla), go to http://192.18.88.148/clusterjsp/.
   
   The request lands in Application Switch, which then routes it to one of the Application Server instances. The response on the JSP page displays many useful session and request properties; you can identify the Application Server instance on which the request was processed. Look for the name of the machine in the response, Executed From Server: ..., for example:
   

   Executed From Server: naut-10.foo.com
   

2. Establish a new session. On a different machine or in a browser (for example, Firefox), go to http://192.18.88.148/clusterjsp/.
   
   If the response cites another Application Server instance (in the example in step 1, the other instance might be naut-11.foo.com), you're assured that Application Switch is distributing the requests within the available Application Server instances.

To verify that the sticky-round-robin algorithm is functioning properly, on both browser windows, enter values in the two text fields for Name and Value of Attributes and click the ADD SESSION DATA button.

The second requests in each session must land in the same Application Server instance that processed the first request. If the Application Server instance name in the response for the second request is the same as that for the first response, the sticky algorithm is in working order.

To verify that the failover capability is functioning properly, do the following:

1. On a new browser window, again go to http://192.18.88.148/clusterjsp/.
   
   
2. Enter values in the two text fields for Name and Value of Attributes and click the ADD SESSION DATA button.
   
   The browser prints the session data in a response. Note the Application Server instance name cited in the response, Executed From Server: ....
   
   
3. Stop that Application Server instance. Type:
   
   Application_Server_install_dir/bin/asadmin stop-instance -host
   DAS_hostname -port DAS_port_number instance_name
   
   where DAS_hostname and DAS_port_number are the host name and port number, respectively, for the Application Server's Administration Server. instance_name is the name of the instance in the Application Server cluster to be stopped.
   
   
4. Repeat step 2.
   
   This scenario would indicate a smooth go: Application Switch assigns this request to an instance that's running, which then checks if the ID of the requested session is valid. If so, the instance acquires the ID from the HADB. Finally, the response posts the data for both the current and the prefailover sessions.

[Part 1] [Part 2]