With the industry shifting focus from the clients and desktops to the Web and servers, the AS/400 has a new chance to shine. With WebSphere Application Server running on top of the integrated Java Virtual Machine (JVM) and accessing the integrated database, the AS/400 gives you a more stable platform and a more secure solution for running a dot-com business or storefront on the Internet. But that’s not all that you get. With WebSphere’s ability to take advantage of multiple processors, multiple instances, and even multiple machines, you can set up a site that can not only handle the traffic that you want but also give you the stability and throughput that you and your business need.

One of the biggest problems that anyone putting up a Web site has to deal with is closing off, or getting rid of, all the single points of failure. Using WebSphere to manage your site will help to remove some of those points and will increase your availability to your customers. WebSphere provides a stable and secure Web environment through the use of five technologies: workload management, load balancing, fault tolerance, clustering, and data mirroring. In this article, I’ll cover WebSphere’s implementation and use of these technologies and then describe topologies for deployment.

Workload Management

Workload management is a technology that allows you to create identical application servers that together present a single image of a server. All of the servers will have the same deployed application components on them (servlets, JavaServer Pages [JSPs], Enterprise JavaBeans [EJBs], etc.). This will allow any of the servers to handle any request that comes in. The request will not know which server will process it, nor will this information matter.

As a part of workload management, nodes represent a single physical machine that you have configured to run your applications on. You will run your clones of the application servers on these nodes. To do this, you need to make a model of your installed server. Make sure that you make this model after you have installed your servlets. You can add your servlets to your model after you make it, but it’s easier if you do it beforehand and test your environment.

Models

Models are exactly what they sound like: snapshots of your application server environment. Models are then cloned so that the application can be represented on multiple servers. It is through the model that you are going to manage your workload management environment. If you want to add new Beans to your setup, you’ll add them to the model, and the changes will be propagated to the clones. You will also change environment variables, such as a parameter that gets passed into one of the applications that you have set up, and start/stop the clones from the model.

Snoop Example

As an example of workload management configuration, I’ll walk through the setup of a servlet. I’ll use the snoop servlet that is included with the default server. Note that I have already configured my HTTP server instance to talk with my instance of WebSphere and that I have two nodes (physical machines) in my setup: RCH111A for the full-service administration server, and RCH111B as the administration agent. Both are V4R4 machines with WebSphere 3.0.2.1 installed on them.

First, I select my application server under my full-service administration server. You can select any level that you want, but these instructions apply to all of them. From this server, I right-click to bring up the context menu, select the Create option, and then select the Model option. There are a number of options that you can specify, but the one that you will be most concerned about is the Workload Management Selection Policy.

Available policies are Random, Round Robin, Random Prefer Local, and Round Robin Prefer Local. WLM uses the policy to select which server instance will handle an HTTP request. Random and Round Robin do pretty much what you’d expect, but their local derivations first attempt to use the same node as the workload-managed client before using a server instance residing on a remote node.

As shown in Figure 1, I chose Round Robin for this example. After making the model, I need to create some clones. The number of clones depends upon how much hardware you have. There is one job per clone, with all threads that are associated with that clone running under that job. So you need to balance that against the amount of memory and number of CPUs that you have. I am using three clones on one node (RCH111A) and two clones on the other node (RCH111B).

After setting up all of the clones, I restart the HTTP server instance. From the Administrative Console, I start up all the clones from the model. If I’ve configured my administration agents and HTTP server correctly, when I go to the URL for one of my servlets, the servlet will run on any of the clones based on the selection policy that I chose in my model.

Load Balancing

I’ll take a look at one of the benefits that you get from workload management: load balancing. Load balancing is simply the ability to have your workload distributed so that every request or application gets equal time to do its job. The work should be distributed so that no one application is doing all of the work while the others idly sit by. WebSphere can create copies of your servers and then distribute your workload across these copies.

You can also configure your AS/400 to allow additional memory and CPU access for the jobs under which the requests are being processed. Or you can run them with different priorities, customizing which work items get done faster. You will also be able to add additional AS/400 machines to expand your throughput even more.

These customizations give you much better control over the load balancing. They allow you to specify which parts of your model get more hardware resources and how it all runs together. This tweaking of your site will give you the fastest response time for your customers and better allocations of the tasks—from database access to order
processing—that need to be done.

Fault Tolerance

Now that you have a general understanding of load balancing, I’ll look at fault tolerance and how WebSphere provides it. First, what is fault tolerance? In the context of WebSphere, it means that, whatever you are running, WebSphere will handle anything that goes bad. Loss of a job, some threads dying off, a hardware failure, or even an entire machine failure are all examples of possible faults that can occur in your configuration. You will have to program some of this logic into your application, servlet, or EJB to get this functionality, but WebSphere automatically provides fault tolerance. There is a monitor job that runs alongside the main WebSphere server that will restart your instance if the server goes down. The value in the admin.properties file that controls this is mntr.retryValue=. The setting of this property tells WebSphere to attempt to restart the server x number of times whenever it detects that the instance abnormally terminated.

There are also clone restart values that you can set that will allow you to restart in the case of failure. Under the General tab on the Administrative Console, you can find the properties for the clone Maximum startup attempts. While the clone is down, WLM will route the requests to the other clones. When the failed clone restarts and comes back online, it will then be able to receive more requests.

Clustering

With the AS/400’s clustering technology, you have the ability to make the configuration really stand up to the traffic and the ability to handle problems when they come up. You can use clustering to distribute work across even more systems or to gain better failover capability, such as the loss of an entire physical system. As a quick definition, a cluster is a collection of systems that cooperate and interoperate to provide a single, unified computer. This type of setup allows any node in the cluster to handle a request.

Although you can use the cluster concept to increase the number of nodes in a group of WebSphere servers, a cluster is typically used for increased availability of the servers. With the creation of nodes on multiple boxes from WebSphere, you can use the cluster to provide “hot backup” services to the nodes themselves. This means that the backup is a copy of the original box that is monitoring the processes, jobs, or the box itself to make sure that things are going well. In the case of a failure, the second box will assume the IP address of the first one and will continue along while you work on getting the primary box back online.

In a simple two-node clustered environment, when the primary machine fails, the backup would automatically assume the identity and workload of the first box, with very little time off the ‘net. With a better partitioning of the resources on the AS/400s themselves, you could allow both of the machines to be available at the same time. Each node in the cluster would be the primary one for some of the resources, such as servlets, and the backup for other sets, such as EJBs. You would get increased throughput from using two boxes and still get the failover and stability of a hot backup of your environment.

Data Mirroring

It will really help your site if the servlets, JSPs, and EJBs are always available. But what happens if your database goes down? An error in the code itself, a fault tolerance problem, or even a hardware crash will make your database unavailable to you.

To help keep your data safe, you again use clustering to help in fault tolerance. You set up a database on one node in the cluster and put the hot backup on another. You could use this technique for online catalogs and other databases that are going to stay static. It will work great until you change the data in the database. You will need some way of getting the data from the primary to the backup, in either a scheduled time frame or real-time replication. The AS/400 does not provide this solution directly, but there are a few IBM Business Partners that provide various degrees of data mirroring, such as DataMirror

Corporation (www.datamirror.com), Lakeview Technology (www.lakeviewtech.com), and Vision Solutions (www.visionsolutions.com).

With the data copied over and the primary nodes in your configuration all having backups and using workload management in WebSphere itself, you will have a stable and sturdy site that can do your business for you, access your data, process orders, and handle the traffic that you want to have.

Topologies

So, now I’ll explain how many different setups you can have and what they look like. The results that you see from these configurations will depend on the size of the hardware that you have. As you increase memory and processor speed, the results will improve.

If you happen to be starting with just one box, there are still a number of things that you can do to help keep everything up and running. For a starting point, you can use the workload management technology to manage one of your servers across multiple clones. This will give you more stability in the server that you choose and will also increase your throughput. There is a point of diminishing returns when you’re creating clones. At this point, your server will begin to run slower because of resource allocations and communication traffic between the clones, the HTTP plug-in code, and the full administration server.

You can also incorporate some of the clustering technology into your picture to help increase your failover capabilities. You can use clustering to monitor for process failure and then have it run a program to perform some additional error handling. This code could notify someone, restart the servers, or do anything else that you can think of and program. There are a number of single points of failure (SPFs) in this configuration, but it is going to give you better stability than you would have with no workload management or clustering involved.

As shown in Figure 2, by increasing the number of AS/400s to two, you greatly increase the number of possible configurations in your setup. You can use a workload management setup with one box functioning as a full administration server and the other working as an administration agent. You can then create a node for each of the two boxes and disperse clones to each of them depending upon your hardware resources. For an SPF in this setup, if the full-service administration server is lost, then your site is going to be down. For another setup, you can make a cluster of the two machines with one of the machines being the backup of the other one. You can also use data replication to keep the databases in sync so that, if there is a failure in the primary box, then the secondary one will take over with current data. You will get very little downtime, and you will lose only the transactions that were occurring when the primary box went down.

Other configurations include the primary box running the full-service administration agent and the backup box not only serving as a copy of the full-service but also running an administration agent on it. With both machines working as nodes in the setup and the agent box running as a backup to the primary box, you can use both machines at the same time with workload management to spread out the requests and still have a backup of the primary in case of failure. This will give you both load balancing and fault tolerance. By adding in a third box to this, you get even more options. You will be able to set up a site that will handle a large number of requests and still be able to handle failures in the servers.

WebSphere Application Server Performance Pack

Even with all of this, there are still SPFs. One is going to be the full-service administration server, though clustering will help to minimize the time that this is down. You will still need to reconnect to the full-service server from all of the agents when it comes back online. Another point of failure is the HTTP server itself. If your HTTP engine goes down, WebSphere can sit idle—even if you have the most solid setup. To help prevent this, you can run multiple HTTP servers with identical content on them on multiple boxes and use

the WebSphere Performance Pack and the Network Dispatcher. As shown is Figure 3, by setting up a PC in front of your HTTP servers and using the Network Dispatcher, you can send your requests to each of the individual HTTP machines. In the case of a failure in one of the HTTP servers, the Network Dispatcher will send the request to a different server. For additional information on this, see the WebSphere Performance Pack documentation.

AS/400 Dot-com

Your customers will use your site’s downtime to jump to your competitors’ sites; downtime means lost revenues and customers. That’s reason to do everything you can to keep your site up and running as much as possible. Using WebSphere running on top of the AS/400’s integrated JVM and database, you get a stable and secure machine for running a dot-com business or storefront. But that’s not all you get. With WebSphere’s ability to take advantage of multiple processors and even multiple machines, you can set up a site that can not only handle the traffic that you want but also give you the stability that you and your business need. In other words, with WebSphere and the AS/400, your job just got easier.

REFERENCES AND RELATED MATERIALS

• IBM WebSphere Web page: www.as400.ibm.com/products/websphere
• WebSphere Application Server 3 Advanced Edition for AS/400 documentation page: www.as400.ibm.com/products/websphere/docs/as400v302/docs/index.html
• WebSphere Scalability—WLM and Clustering (SG24-6153-00, CD-ROM )
• WebSphere V3 Performance Tuning Guide (SG24-5657-00, CD-ROM )

Figure 1: Use WebSphere’s Administration client applications to configure your application server.

Administration Agent

AS/400 RCH111B Full-service Administration Server

HTTP Server

AS/400 RCH111A

Full-service Administration Server

HTTP Server

Clone 1

Clone 2 Clone 1

Clone 2

Clone 3

Database Clone 1

Clone 2

Clone 3

Database

Clone 1

Clone 2

Clone 3

Database

Cluster of AS/400s

Full-service Administration Server

HTTP Server

AS/400 RCH111B—Backup

Cluster of AS/400s

Figure 2: A cluster is a collection of systems that cooperate and interoperate to provide a single, unified computer.

Web Server

Administration Server

WebSphere Server

Machine B

Web Server

Administration Server WebSphere Server

Machine C

WebSphere Server

Machine A

Web Server

Administration Server

Network Dispatcher

Figure 3: In the case of a failure in one of the HTTP servers, the Network Dispatcher will send the request to a different server.