[TechNote] IBM File System Locking Protocol Test for WebSphere Application Server

IBM File System Locking Protocol Test for WebSphere Application Server

Abstract

The File System Locking Protocol Test for WebSphere® Application Server will indicate if a shared file system can support the failover of transaction logs in WebSphere® Application

Download Description

For many customers, the dependency on information technology for business success has increased. With the pervasiveness of the Internet, globalization of economies and impact due to natural disasters or terrorism, any downtime of IT services can seriously impact the performance of a business. One way to increase the availability of IT systems is to have redundant systems with automatic failover of processing from one system to the other system. It is often necessary to share configuration or persistent data between the redundant systems via a shared file system. This allows each redundant system to have access to state data so that when a system fails over to another system, the failover system can start processing at the point of failure of the failed system.

In Websphere, the transaction manager utilizes a shared file system to make transaction logs available to each redundant system in the WebSphere Cluster. This allows failover WebSphere servers to recover the transaction logs of a failed WebSphere server.
Messaging Engines that use the Service Integration Bus Filestore can also utilize a shared file system to make this message store available to all WebSphere servers in the cluster. This allows the Messaging Engine to failover to any of the servers while retaining access to the filestore.
The failover of the transaction logs and the filestore in a high availability environment depends on specific functionality in the shared file system.
Specifically, the shared file system must provide lease based locking protocol and write through to disk on flush. The procedures and executable programs of this verification test tool will determine if the shared file system supports the leased based locking protocol that is required for successful transaction log or filestore failover.

This verification test consists of a set of executable programs and a description of manual procedures that must be followed in order to perform the verification. These manual procedures are unavoidable due to the nature of the test. The test requires processes and systems to be terminated and the network to be disconnected.

The following is the overall approach for this test:

• Lock file that resides on a shared file system from one system (System A)
• While that system A holds the lock on the file, "terminate" system A
• From another system (system B) that has access to the shared file system, test to see if the lock is still held after system A has terminated.

Files in package:
fsLock.class
fsVerify.class
properties.txt
README.txt
licenses

Dependencies:
The executable programs can be run independent of a WebSphere installation. However, the programs are Java programs and do require a J2SE 1.4 or higher.

This test will require two systems (system A and B) to be attached to a shared file system.

Prerequisites

The tool runs on the same system as the WebSphere Application Server installation.

Installation Instructions

Procedures:

Steps 1 and 2 must be performed once on each system in the test.
Steps 3-6 must be performed 3 times, once for each termination procedure described in step 4.



1. Put the files in the package on a directory in your local file system and make that directory the current working directory. Do this on both system A and B.
   
   
2. Edit the properties.txt file. There is one entry in the properties.txt file
   filename - this is the name of a file that will be locked. It must reside on the shared file system that is being tested. It must not currently exist. If it does currently exist the contents of the file will be overwritten. This property must be modified. Do this on both system A and B.
   
   
3. On system A, lock the file. To start the test, you will need to lock the file that resides on the shared file system. The file (specified by the value of the filename property in the properties.txt file) is locked by invoking the java program fsLock. The following is the command to invoke the java program:
   java fslock
   
   The program will lock the file and then go into a sleep.
   The output of this file will look like this:
   C:>java fsLock
   Obtained lock and now sleeping
   
   It is important to perform step 4 while the program is sleeping.
   
   
4. Terminate system A. There are 3 termination procedures that must be followed to ensure the verification is complete.
   
   Termination procedure a)
   Process termination: This procedure is to terminate the process that is holding the lock. This can be done by doing a CTL-c in the command window or shell that is running the fsLock program.
   
   Termination procedure b)
   System termination: This procedure is to stop system A while it is holding the lock. This can be done by issuing shutdown immediate commands or turning off power to the system.
   
   Termination procedure c)
   Network termination: This procedure is to disconnect the network connection to the shared DASD from system A.
   
   This can be done by removing the network cable from the Network Interface Card that is connected to the shared DASD unit.
   
   
5. On system B, verify the lock is freed. The correct outcome of terminating the process is that the lock should be freed and the file available on other systems.
   
   The Java program, fsVerify will check the lock and verify that the file is not locked. On system B, invoke the fsVerify java program with the following command:
   java fsVerify
   
   This program will test the lock on the file and output if the lock is held or not. The correct output will look like this:
   C:>java fsVerify
   Lease based lock test PASSED: Lock free
   
   This output should be returned for each of the 3 termination procedures. If the output is not PASSED, then the shared file system does not support lease base locking protocol and will not be able to function correctly for WebSphere Application Server failover of transaction logs or Service Integration Bus Filestores.
   
   
6. Start any terminated systems and go back to step 3 until all termination procedures have been tested