Level: Intermediate Russ Zumwalt (rzumwal@us.ibm.com), Software Engineer, IBM
09 Jan 2006 In this sixteenth article in the
series, you use the Failover Configuration Pattern Asset to simplify your development and deployment of high availability solutions. Ever felt the pain of configuring high availability failover behavior using IBM Tivoli® System Automation? Ever done the manual script authoring, debugging typos, and changing the same value in multiple files? Shouldn't there be an easier way to generate the configuration files in a consistent format? If you answer yes to these questions, the Tivoli System Automation Failover Configuration Pattern asset can help. By visually modeling your configuration in Unified Modeling Language (UML), the configuration scripts for IBM Tivoli System Automation can be generated from the model. Read all about it in this article.
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.
Figure 1. J2EE stack
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.
Figure 2. Examples of failover clusters
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.
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 1. Stereotypes that extend the UML node stereotype
| Stereotype | Definition |
|---|
| NFS | Represents an Network File System server, which contains attributes about the
server's location and what data is partitioned to the cluster | | ServerNode | Used to model a node within a failover cluster | | TieBreakerDisk | Represents a disk that is used to "break the tie" if two nodes become
active simultaneously |
Table 2 shows the stereotypes that extend the UML artifact stereotype, and are used to represent the middleware services.
Table 2. Stereotypes that extend the UML artifact stereotype
| Stereotype | Definition |
|---|
| DB2 | Represents an instance of DB2 | | IHS | Represents an instance of IBM HTTP Server (IHS) | | WAS | Represents an instance of WebSphere Application Server |
The service stereotypes each provide additional parameters that are necessary for configuring Tivoli System Automation properly with that service.
Installing Failover Pattern Asset
The Failover Configuration Pattern Asset requires Rational Software Architect V6.0.0.1 or V6.0.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
- 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
- After you restart Rational Software Architect, the TSAFailoverCluster pattern appears in the Pattern
Explorer, shown in Figure 5.
Figure 5. Pattern Explorer
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.
Figure 6. Failover Pattern Instance
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.
Figure 7. Service parameter defined
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.
Figure 8. Server nodes defined
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.
Figure 9. ServerNode attributes
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' |
where sdx is the name of the disk.
Figure 10. TieBreakerDisk defined
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.
Figure 11. Failover pattern defined with three nodes
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.
Figure 12. Model Explorer view
Figure 13. Launching the transform from the model object
The next step is to select the target directory for the scripts to be written to, shown in Figure 14,
and select Run.
Figure 14. UML to Tivoli System Automation Transform GUI
Table 3 shows the three scripts that are written to the target directory.
Table 3. Scripts written to the target directory
| TSA-WAS.sh | Configures Tivoli System Automation to perform failover behavior with the middleware service | | TSA-NFSWAS.sh | Configures Tivoli System Automation so that the middleware service uses NFS | | sa-nfsserver.conf | Configures system automation with the NFS server |
The .sh files will include the service name in them; for example, TSA-DB2.sh.
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.
- 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.
- Decompress the Tivoli System Automation for Multiplatforms (TSA) package and run the setup script on each node.
- Install the latest fixpack for Tivoli System Automation on each node, available at
IBM Tivoli System Automation for Multiplatforms.
- 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:
- sa-nfsserver.conf must be copied to the
/usr/sbin/rsct/sapolicies/nfsserver/ on the master node to configure NFS properly.
- The TSA-NFSWAS.sh file must be executed on the master node.
- 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.
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.
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
Get products and technologies
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. |
Rate this page
| 
