The TruCluster Server environment allows you to make existing applications more highly available to their clients with minimal effort. You can also develop new applications that take greater advantage of the performance and availability features of a cluster. You can deploy highly available applications having no embedded knowledge that they are executing in a cluster, and that can access their disk data from any member in the cluster.
Using the TruCluster Server cluster application availability (CAA) subsystem, applications can recover from member and resource failures by restarting on another cluster member. If the cluster member on which an application is running fails, or if a particular required resource fails, CAA relocates or fails over the application to another member that either has the required resources available or on which the required resource can be started.
TruCluster Server also lets you run components of distributed applications in parallel, providing high availability while taking advantage of cluster-specific synchronization mechanisms and performance optimizations.
If you are new to TruCluster Server, read the TruCluster Server Cluster Technical Overview manual for an overview of the TruCluster Server product. Also, read the following chapters of this manual to understand the TruCluster Server features that applications can use to become highly available:
Chapter 2 discusses using the CAA subsystem to make single-instance applications highly available.
Chapter 3 discusses using a cluster alias with multi-instance applications to make the cluster appear as a single system to its network clients.
If you are moving from a TruCluster Available Server or TruCluster Production Server environment, read Part 2, which discusses how to move ASE-style applications to TruCluster Server.
This chapter discusses the following types of cluster applications. These application types are described in Section 1.1.
Single-instance
Multi-instance
Distributed
Cluster applications can be divided into the basic types that are
listed in
Table 1-1.
Table 1-1: TruCluster Server Application Types
| Type | Description | Example |
| Single-instance | A single-instance application runs on only one member of a cluster at a time. | Single-instance Dynamic Host Configuration Protocol (DHCP) server |
| Multi-instance | A multi-instance application runs on one or more members of a cluster. It has no restrictions that prevent it from running more than one copy in a cluster. | Multi-instance Apache Web server |
| Distributed | A distributed application runs as independent, cooperating modules that are distributed among cluster members. | Oracle Parallel Server (OPS), Oracle 9i Real Application Clusters (RAC) |
The following sections describe these three application types in
more detail.
1.1.1 Single-Instance Applications
A single-instance application runs on only one cluster member at a time.
All clients access the single-instance application on one member as
shown in
Figure 1-1.
Figure 1-1: Accessing a Single-Instance Application
If the cluster member where the application is installed fails or loses
access to a resource, the CAA subsystem can fail the application over
to another running member.
(See
Chapter 2
for information on how to use CAA.)
Figure 1-2
shows how the failure of one cluster
member results in the failover of an application to the second
cluster member.
Figure 1-2: Application Failover Using CAA
Table 1-2
summarizes single-instance application
architectural differences in TruCluster Server and the previous
TruCluster software products.
Table 1-2: Single-Instance Application Architectural Differences
| TruCluster Server Version 5.0 or Later | TruCluster Available Server and TruCluster Production Server Version 1.6 or Earlier |
| Application installation and configuration on a single member of the cluster can be seen on all members because of the cluster file system (CFS). However, the application can be run only on one member at a time because no synchronization has been built into the application. | Application installation and configuration on a single member of the cluster is visible and usable only on that member. |
| CAA is used to define application start, stop, and resource dependency needs. Storage is transparently handled by CFS and the device request dispatcher. You can use the cluster alias or an interface alias within a CAA action script to handle IP aliasing needs. | ASE is used to define application start, stop, storage, and IP aliases. |
Because TruCluster Server is binary compatible with Tru64 UNIX
Version 5.1B, any application that runs properly on Tru64 UNIX
and recognizes the new-style device names
(dsk) will run on at least one member of a cluster.
See
Section 4.2
for more information about
device naming.
1.1.2 Multi-Instance Applications
A multi-instance application can run multiple instances of itself on a single system or on more than one member of a cluster. If multiple instances of an application run on more than one system, the application has been modified to have some cluster awareness, for example, temporary file names have been changed to avoid being overwritten.
A multi-instance application is typically highly available; the failure
of one cluster member does not affect the instances of the application
running on other members.
Multi-instance applications can take advantage
of cluster aliasing to distribute client requests among all cluster members
as shown in
Figure 1-3.
In this figure, clients are
accessing a multi-instance application through the cluster alias
deli.
Figure 1-3: Accessing a Multi-Instance Application
Table 1-3
summarizes multi-instance application
architectural differences in TruCluster Server and previous
TruCluster software products.
Table 1-3: Multi-Instance Application Architectural Differences
| TruCluster Server Version 5.0 or Later | TruCluster Available Server and TruCluster Production Server Version 1.6 or Earlier |
| A multi-instance application that is cluster-aware makes explicit use at the source level of the distributed lock manager (DLM) application programming interface (API). Cluster alias automates routing of client requests among instances of the application. | An application can be run as multi-instance by creating multiple ASE services, each with its own interface alias. There is no cluster alias. Load balancing and delivery of client requests to application instances must be designed into the application. The application must be able to access distributed raw disk (DRD) devices for storage and must use UNIX file locking semantics, the DLM, or an application-specific locking mechanism. |
| A multi-instance application that is not cluster-aware must synchronize access to shared data by using standard UNIX file locking or the DLM. | Because there is no clusterwide implementation of standard UNIX file locking, an application that is not cluster-aware must explicitly use the DLM. |
For an application to successfully run multiple instances in a cluster:
Interprocess communication must be performed through remote procedure calls (RPCs) or socket connections.
Access to shared files or data must be synchronized.
Use
flock() system calls or the distributed lock manager
(DLM) to synchronize access to shared data.
Use context-dependent symbolic links (CDSLs) or other means to create separate log and temporary files for multiple instances of an application.
If an application has member-specific configuration requirements, you might need to log on to each member where the application will run and configure the application. For example, if an application's installation script is not cluster-aware (that is, the application does not know that it is being installed in a cluster), you may need to tailor the application's configuration after installing it. For more information, see the configuration documentation for the application.
If you want to use the default cluster alias to distribute network connections
among members, define application ports in the
/etc/clua_services
file.
Add the
in_multi
alias attribute so that the cluster alias
subsystem distributes connection requests directed to the default
cluster alias among all members of the alias.
See
clua_services(4) for more information about defining
ports, and see
Chapter 3
for information on how to use
cluster aliasing for transparent client access to multi-instance applications.
See
Chapter 4
for more information about these
considerations and other general application migration issues.
1.1.3 Distributed Applications
A distributed application is cluster-aware; that is, it knows it is running in a cluster and typically takes advantage of the performance gains of distributed execution. A distributed application uses the cluster application programming interfaces (APIs) such as DLM and Memory Channel. See Chapter 6 for more information about distributed applications.