The HA Harness

Every piece of current HA software on the market is structured as a harness that wraps around existing commodity applications. This is extremely important point because the job of current clusters is to work with commodity (including software), so the old notion of writing an application to a HA API to fit it into the HA System simply doesn't fly anymore. This approach also plays into choosing a HA vendor: you need to choose one with the resources to build these harnesses around a wide selection of existing applications that you might now (or in the future) want to use.

Choosing such a harness can be very environment specific. However, there are several points to consider when making this choice.

• Application monitoring: All applications may fail (or even worse, hang) in strange ways. However, if the harness doesn't detect the failure, you won't recover automatically (and thus the down time will suffer).

• In Node Recovery: If an application failure is detected, can the harness restart it without doing a cross node fail-over. (The application and data are often hot in the node's cache, so local restarts can often be faster).

• Common Application Protection. HA packages usually require an application ``harness'' to interface the given application to the HA software. You should make sure the HA vendor has a good range of pre-packaged harnesses for common applications, and evaluate the vendor's ability to support custom applications easily.