H.A. Clusters (tm) High Availability Clustering Software
H.A. Clusters High Availability Clustering Software detects failures on the primary server and provides an automatic failover to a standby server.
Click on an image to view a larger version.
English
Supported Technologies
AIX,
HP/UX,
Linux,
OS/400,
SCO UNIX/PC UNIX,
Silicon Graphics IRIX,
Solaris/Sun OS,
Windows XP/2000/NT
Software
Click on a technology to view similar products within this category.
Pricing
Server
2000 to 14000
sales@tech-sol.com
612-513-3204
direct and through resellers
Additional Product Information
H.A. Clusters™ High Availability Clustering Software from H.A. Technical Solutions is high availability software designed to manage and control the automatic failover of applications running on servers that are networked in a client server environment, servers running special applications in the telecommunications market, or applications running on dedicated boards in real-time or other operating environments.
A high availability solution needs several components to make it work. H.A. Clusters provides the first component: system management software that detects failures and provides an automatic failover to a standby server. To make that software work, however, requires several other components:
A heartbeat connection
In order to monitor each server and its LAN connections, there needs to be a physical connection between the active server(s) and the standby server(s). This connection can by a serial connection or an Ethernet connection, which requires a second network interface card in each server.
When you configure H.A. Clusters, you will provide it with the physical interface names and addresses for the heartbeat connection so H.A. Clusters can use them.
An "Active IP" address
If a server fails, H.A. Clusters will failover to a standby server automatically. In order for this to work, however, client workstations need to have a way to address the server that is independent of the physical server. If your applications use the IP address to access the server, this is accomplished by setting up an "Active IP" address. This is an alias IP address that will be used instead of a physical IP address by all clients to access the server. (The /etc/hosts file on each client machine needs to list this "Active IP" address and name; the H.A. Clusters user interface lets you do this.) In H.A. Clusters, you will set up configuration information that maps this active IP address to the physical IP addresses of the active server(s) and the standby server(s).
If the active server is operating, when clients access the "Active IP" address, they will be routed to the active server automatically. If the active server fails, clients accessing the "Active IP" address will be routed to the standby server automatically. All of this is transparent to the clients; they simply know the server by its "Active IP" address (or its alias or name).
An active host name
Some applications use the server's host name, in most cases to verify the software is licensed to that server. To allow such applications to work in the event of a failover, you can configure a common or active host name that applications can use instead of the actual server host names. This active host name is unique to each job and is not assigned an IP address in the /etc/hosts file. (This is an advanced function that requires modification of the software's configuration file.)
A job
H.A. Clusters can automatically monitor for hardware failures on the servers and on the LAN. However, since each application is different, you need to set up your own monitoring for application failures, using job scripts. You can do this in two ways:
- First, you can have the job script itself monitor the application and invoke H.A. Clusters to do a failover to a standby server when necessary. The software's user guide includes an example of how to do this.
- Second, in the job script you can invoke a program (in C language, for example) that monitors the application and reports its status to H.A. Clusters on a regular basis, using built-in API function calls. If the program reports an application error to H.A. Clusters, then it will automatically failover the job to the standby server. The software's user guide includes examples of API function calls
In a simple configuration, you could have one job running all of your applications. If, however, you want to be able to failover applications selectively, then you need to set up multiple jobs. When you do this, you need to set up a alias IP connection and an active IP address and name for each job. The software's user guide describes how to do this.
A shared disk or disk array
If a server fails, H.A. Clusters can failover to a standby server. However, clients need to continue to access the same data they were using before the failure. This is handled by setting up a multi-ported or dual-ported SCSI or fiber-channel disk array, a network attached storage (NAS) device, a storage area network (SAN) or an external SCSI disk. Since this shared disk or disk array is accessed from both servers, clients will have continued access to the same data after a failover occurs.
Combining with data replication
If you want to provide an even greater degree of high availability, you can use H.A. EchoStream™ Data Replication Software to replicate all data from your primary disk device to a secondary disk device. This can be done continuously, so that, if your primary disk device fails, your users will be switched to a secondary disk device with no loss of data.