Hardware fault-tolerant products take NT to the 99.99 percent availability
level in a different way from fault-resilient clusters. Hardware fault-tolerant
solutions (such as Marathon Technologies' Endurance 4000) involve total system
redundancy in which all components perform actively during normal operation.
This configuration allows continuous processing or compute-through capability
for hardware-related failures. Unlike high-availability and fault-resilient
cluster solutions, this configuration requires no application restart. Thus, no
loss of application state or client connectivity to the hardware fault-tolerant
system occurs.
As you move up the scale from 99.9 percent to 99.99 percent availability,
successive solutions result in more than incremental increases in cost. This
fact is why it's imperative that you identify in dollars what availability is
worth to your enterprise.
Data Mirroring with Failover
At the low end of the price and complexity spectrum ($1895 to $3999 for two
nodes), realtime data mirroring between servers lets you increase NT's
availability and provides features that let each server assume the other's
identity in case of failure. Data mirroring with failover between NT systems
isn't new. In fact, it's a high-availability solution I ran across in 1995 and
first used at one of those buried-in-a-mountain government installations. The
air force colonel responsible for the system was concerned about having failover
capability between the system's two new NT servers. He was used to the
fault-resilient capability of the VMS-based clusters he had been relying on, and
he wasn't going to give it up completely when he moved to NT.
What's new in data mirroring is an increase in the number of realtime
data-mirroring products. The abundance of solutions has increased competition
and driven improved product functionality. From a failover standpoint, product
functionality improvement has meant moving away from older active/standby
system-level implementations that, in some cases, require a reboot for the
standby system to assume the identity of the failed system. Today's solutions
can retain their identity while assuming the identities (including NetBIOS names
and TCP/IP addresses) of multiple failed servers.
Table 1, page 132, lists some prominent current solutions that combine data
mirroring with failover capability. (Many data-mirroring products do not include
failover capabilities, and others, such as NT 5.0's IntelliMirror, do not offer
realtime capabilities.) Although the advanced features of the solutions in Table
1 are targeted toward NT 4.0, NSI Software's Double-Take for Windows NT and the
Qualix Group's OctopusHA+ support NT 3.51 but have reduced failover capabilities
with NT 3.51.
The solutions in Table 1 meet the independent OS and application-execution
criteria of my definition of clustering. Where they fall short--and why I don't
classify them as true clusters--is in their inability to access shared storage.
(To learn more about these solutions' features and functionality from a standard
clustering perspective, see Jonathan Cragle, "Clustering Software for Your
Network," July 1998.) Each node accesses data only on its locally attached
storage. This limitation doesn't render these solutions useless in your search
for higher NT availability; in fact, the beauty of these solutions is that their
hardware and software requirements are not (unlike those of MSCS and other
clustering solutions) stringent. For the most part, with these solutions you can
use the systems and (with some elbow grease) applications you already have, to
build a system-level high-availability solution between two or more than two
systems that can run NT. At most, because you are duplicating your data, you
must add disk space. Depending on the traffic your systems support and the data
mirroring and failover product you choose, you might also need to add network
cards to create a private network between the systems you target for data
mirroring and failover. Figure 1 illustrates a typical two-node data-mirroring configuration with internal storage.
Prev. page
1
2
[3]
4
next page 
