Introduction

This article, Part 16 in the series, shows you how to rapidly deliver IBM Tivoli System Automation (TSA) configurations using IBM Rational® Software Architect (RSA). Businesses need high availability (HA) enterprise solutions, but current methods of delivering those solutions are complex and expensive. Common solutions exist, but reuse is difficult because assets are captured in hard-to-reuse formats, such as white papers and presentations.

The IBM High Performance On-Demand Solutions (HiPODS) team developed a reference implementation of an HA Java™ 2 Platform, Enterprise Edition (J2EE) stack, shown in Figure 1. In this solution, IBM HTTP Server (IHS) is the Web server, IBM WebSphere® Application Server (WAS) is the application server, IBM DB2® Information Management for database access, and all application data was stored on a remote file system mounted on a Network File System (NFS) server. This solution took about five months to configure properly by a team of experts in configuring and delivering these types of solutions.

One of the most common methods for improving the availability of a system, or a component of a system, is by using failover clusters. Failover clusters are a group of server nodes that provide a middleware service (for example, WebSphere Application Server). One node actively provides the service and, in the event of a failure to that node, another is brought active in its place. See Figure 2 for an example. Without this behavior, the service would be unavailable until the failed node is restarted. In the example of the J2EE stack, the entire system is unavailable if a node providing one of the services fails because the services form a chain of dependencies. By having active nodes waiting in case of failure, the uptime of each service and the system as a whole is improved.

One way to have active nodes waiting is to use system automation software, such as Tivoli System Automation. Tivoli System Automation monitors and manages the availability of middleware services and applications, and provides automatic recovery of server resources. Unfortunately, configuring Tivoli System Automation is complex and time consuming. By capturing the elements from the reference implementation mentioned earlier as assets in the Rational Software Architect (RSA) Patterns Framework (see Resources), it is possible to easily and quickly generate artifacts to configure failover behavior in Tivoli System Automation.

Back to top

Failover Pattern overview

The Failover Pattern is packaged as a reusable asset that can be imported and installed into RSA. The one pattern included in this asset is the TSAFailoverCluster, which is used to model the entire cluster. It aggregates a collection of server nodes and a service that is being deployed on those nodes. Some additional configuration parameters are also part of the pattern.

A custom UML Profile, UML2TSAProfile, is also included with this asset to provide stereotypes that define components of a Tivoli System Automation failover cluster. Some of the stereotypes represent hardware elements, and some represent the middleware services being deployed in the cluster.

Table 1 shows the stereotypes that extend the UML node stereotype, and are used to represent hardware elements.

Table 2 shows the stereotypes that extend the UML artifact stereotype, and are used to represent the middleware services.

The service stereotypes each provide additional parameters that are necessary for configuring Tivoli System Automation properly with that service.

Back to top

Installing Failover Pattern Asset

The Failover Configuration Pattern Asset requires Rational Software Architect V6.0.0.1 or V6.0.1.

1. Launch the New Repository Connection wizard from the RAS (reusable asset) perspective, and select DeveloperWorks Repository, as shown in Figure 3.
   Figure 3. DeveloperWorks Repository Connection wizard
   
   
2. Open the Asset Explorer in RSA, shown in Figure 4. Navigate to the deploy_soa folder, select the Failover Configuration Pattern asset, right-click and select Import.
   Figure 4. Asset Explorer
   
   
3. After you restart Rational Software Architect, the TSAFailoverCluster pattern appears in the Pattern Explorer, shown in Figure 5.
   Figure 5. Pattern Explorer
   
   

Back to top

Applying the Failover Cluster Pattern

First you need to create a new model named HAServerConfig.emx. It is recommended, for space reasons, that each cluster be in its own diagram. The elements enclosed in this asset are for use in a deployment diagram (in this example, a diagram named WAS has been created). The UML profile will be automatically applied to the model.

To get started, drag out an instance of the TSAFailoverCluster pattern from the Pattern Explorer view, as shown in Figure 6.

There are ten parameters to the TSAFailoverCluster pattern. First, define the Service parameter by creating one of the service stereotypes (in this example, WAS) from the Failover palette, shown in Figure 7. Define any attributes that are associated with the service. In this case, WAS has an attribute named profilesDirectory, which has a default value set for the typical location of the profiles directory for a WAS installation. The pattern instance has also been renamed to wasCluster.

The ServerNode parameter is the collection of nodes that the middleware service will be deployed upon. We'll define three server nodes, named blade1, blade2, and blade3, as shown in Figure 8.

The ServerNode stereotype has four attributes associated with it, shown in Figure 9, which can be defined in the Stereotypes tab in the Properties view:

• hostname: the hostname of the server node
• ip: the IP address of the server node
• interface: the network interface used to communicate with the node
• sharedPartition: a partition of the shared storage (see description of SharedStorage parameter below) allocated for the node. The sharedPartition attribute is not always required. Certain services, such as DB2, require that the shared storage be partitioned to each node to function properly with Tivoli System Automation.

The TieBreakerDisk parameter accepts a stereotype instance of the same name, which can also be dragged from the Failover palette. The TieBreakerDisk stereotype has four attributes that can be set using the Properties tab, the same way as the ServerNode attributes in Figure 9. The attributes are:

• channel: the channel of the disk
• host: the host of the disk
• id: the ID of the disk
• logicalUnitNumber: the logical unit number of the disk

These four are attributes of the disk being used as the tie-breaker and can be determined by using the command:

'dmesg | grep "Attached scsi" | grep sdx'

The SharedStorage parameter is the shared storage that the cluster will access. In this example, we'll use an NFS server to represent the shared storage. An instance of this stereotype can also be created from the Failover palette. The NFS stereotype has four attributes:

• domain: the domain name of the NFS server
• fileSystemType: the file system type of the NFS server
• ip: the IP address of the NFS server
• partition: the shared storage partition provided by this NFS server.

These four attributes also can be defined using the Properties tab in the same manner shown in Figure 9.

The remaining parameters (all string values) of the TSAFailoverCluster pattern are:

• ServiceRoot: the root installation directory of the middleware service
• VirtualIP: the IP address of the cluster
• Netmask: the netmask of the cluster
• Domain: the domain name that identifies the cluster within Tivoli System Automation
• ScriptLocation: the location of the start/stop/monitor script that Tivoli System Automation uses to start, stop, and monitor the status of the middleware service
• ServicePartition: the shared storage allocated to the middleware service in this cluster

Figure 11 shows the pattern defined with three nodes.

Back to top

Run UML to Tivoli System Automation transform

To generate the Tivoli System Automation scripts, you'll use the UML to Tivoli System Automation transformation, which is a transform that's included in this asset. This transform generates Tivoli System Automation scripts from the TSAFailoverCluster pattern object.

First, select the TSAFailoverCluster pattern instance wasCluster, which is the only valid object from your model for this transform. The transform can be invoked by selecting Transform > Run Transformation > UML to TSA Transformation from the Modeling menu, or by right-clicking on the source object either in the Model Explorer shown in Figure 12 or the model in Figure 13.

The next step is to select the target directory for the scripts to be written to, shown in Figure 14, and select Run.

Table 3 shows the three scripts that are written to the target directory.

The .sh files will include the service name in them; for example, TSA-DB2.sh.

Back to top

Deploying the Tivoli System Automation scripts

The HA solution provided by this asset is of the type active-standby, where one server actively provides the service and the other nodes in the cluster act as standby nodes, taking over the task of the active node should it fail. NFS is used as a data store for each service (IHS, WAS, and DB2) and can reside separately on its own cluster or on the same cluster as the service it is acting as a data source for.

A cluster of servers with identical Red Hat Linux™ 4 images is assumed. All steps should be performed as root.

1. Ensure that all nodes have the Secure Shell (SSH) daemon running, with public key authentication for root.

   This simplifies the deployment process because the configuration scripts only need to be executed on one node, which will be called the master node. The master node then connects using SSH to the remaining nodes and executes the configuration scripts. OpenSSH Public Key Authentication provides directions for setting up public key authentication for SSH.

2. Decompress the Tivoli System Automation for Multiplatforms (TSA) package and run the setup script on each node.
3. Install the latest fixpack for Tivoli System Automation on each node, available at IBM Tivoli System Automation for Multiplatforms.
4. Install Tivoli System Automation-SA Policies on the master node.

For Tivoli System Automation to manage resources, it needs to call start, stop, and monitor scripts for each middleware service. The script must accept start, stop, and monitor as arguments, and must return the return codes that Tivoli System Automation expects.

For a monitor inquiry, the return code must be 1 if the service is online or 2 if it is offline. For start or stop, 0 must be returned if the command is completed successfully. These scripts must be placed in the same directory specified by the ScriptLocation parameter of the TSAFailoverCluster pattern object.

The configuration scripts must be deployed in the following order:

1. sa-nfsserver.conf must be copied to the /usr/sbin/rsct/sapolicies/nfsserver/ on the master node to configure NFS properly.
2. The TSA-NFSWAS.sh file must be executed on the master node.
3. The TSA-WAS.sh file must be executed on the master node.

Upon completion of those steps, WebSphere Application Server will be deployed on a failover cluster using remote storage.

Back to top

Summary

This article provides a description and example of how to use the Failover Patterns to configure IBM Tivoli System Automation. This is the first in what we hope will be a large set of highly available patterns to deliver HA solutions more quickly. Many solutions exist today, but they are usually in paper formats. By capturing patterns in Rational Software Architect, solution development and deployment time can be reduced while quality and repeatability are increased.

Back to top

Acknowledgements

The author wishes to thank Christina Lau for reviewing this article. Thanks also to Eric Ye, Joseph Kim, Kai Young, and Dorian Birsan for their assistance in the development of this pattern. Last, thanks to my Extreme Blue Hydra teammates: Michael Chen, Chris Buccella, and Jeannie Lin for all the work in summer 2005 that led to the release of this pattern.

Resources

Learn

• Series overview: Link to previous articles and read about this series, which demonstrates to business analysts, solution designers, and architects how to design and implement on demand solutions using the thirteen capabilities of the IBM On Demand Operating Environment.
  
  
• Rational Software Architect: Learn more about Eclipse-based UML Modeling and Java development.
  
  
• Pattern Solutions: Read more about the role of pattern solutions.
  
  
• OpenSSH Public Key Authentication : Provides directions for setting up public key authentication for SSH.
  
  
• Reusable Asset Specification: Read more about reusable assets.
  
  
• IBM Tivoli System Automation: Learn more about IBM Tivoli System Automation for Multiplatforms.
  
  
• Browse for books on these and other technical topics.
  
  

Get products and technologies

• Download a free trial version of Rational Software Architect Version 6.0.
  
  
• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

About the author

Russ Zumwalt is a Software Engineer for the High Performance On Demand Solutions (HiPODS) team. He began his career with IBM as an Extreme Blue Technical Intern, working on the project that eventually led to this asset. You can reach Russ at rzumwal@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Failover Pattern overview
• Installing Failover Pattern Asset
• Applying the Failover Cluster Pattern
• Run UML to Tivoli System Automation transform
• Deploying the Tivoli System Automation scripts
• Summary
• Acknowledgements
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Tivoli System Automation
• Webcast: Achieve an Agile Organization through Enterprise Architecture
• Briefing: Introduction to Tivoli service management environment
• Buy: Tivoli System Automation

My developerWorks community