An advantage of network-based data replication is that it opens the door
for wide-area data replication. Wide-area data replication can give you offsite
copies of your data, which you can use for centralized backup and which provide
some level of disaster tolerance. Some of the products' architectures allow more
wide-area data replication than other architectures allow. Therefore,
investigate product architecture as you evaluate each solution, and prototype
your implementation. Extend your product investigation to the granularity at
which a product lets you select data to mirror. Some products let you select
specific files to mirror, and other products mirror at the volume level. An
additional benefit of network-based data replication is the flexibility that
some products' many-to-one mirroring capabilities provide. This flexibility lets
you mirror many systems to one failover server, an approach that differs from
the paired-server implementation MSCS offers.
The advantage of mirroring data can also be a disadvantage. Because data is
mirrored, every data change results in two or more writes to disk. The or
more comes into play if a log file holds changes before the changes are
written to the target system. Depending on the implementation, the use of log
files can mean that one write on a nonmirrored system can result in four writes
in a mirrored solution: one write to write the data, one write to the source
transaction log, one write to the target transaction log, and one write to the
mirrored target data. The additional overhead these writes cause can make
mirroring solutions less desirable in write-intensive environments. Another
disadvantage of data mirroring is that recovering from a failure requires the
remirroring of data. For long outages affecting large volumes of protected data,
remirroring can cause lengthy recovery times. Data mirroring solutions try to
reduce recovery time by maintaining logs of the changes that have occurred and
mirroring only the changes to the recovered system.
Another factor to investigate when you evaluate data mirroring and failover
solutions is how a solution supports application failover. The products listed
in Table 1 handle the failover of file shares, and OctopusHA+ and Co-StandbyServer handle print shares without a reboot as well. Table 1 also identifies some basic failover features these solutions provide, and it shows that, unlike MSCS, these solutions limit out-of-the-box failover support to the system level. That is, these solutions detect only system failures and fail over all applications, rather than individual applications.
Each solution addresses the intricacies of failing over applications
differently from other solutions. Remember that, unlike MSCS, these products are
attempting to provide failover support to applications such as Exchange 5.0,
which were not written with failover in mind. Beyond file and print services,
all these solutions support only active/standby configurations for most
server applications. Application failover might be version- and feature-specific
and require operator intervention and a reboot at the time of failure.
Application failover support is an area in which prototyping can stop you from
taking the wrong high-availability path. The last three columns in Table 1
identify some failover features data mirroring and failover solutions provide
for major BackOffice applications.
Exchange, with its reliance on primary computer name and account and use of
Registry keys, is a particularly difficult application to support. Initially,
data mirroring failover solutions for Exchange were little more than workarounds
that involved prestaging a failover system for Exchange disaster recovery. The
introduction of MSCS, with its support for active/active server configurations
with active/standby failover support for Exchange 5.5 Enterprise Edition, and
competition among the data mirroring vendors has driven the refinement of data
mirroring with failover solutions. All the vendors in Table 1 now automate the
entire Exchange failover process (changing the primary computer name, stopping
and starting services, patching the Information Store to fix globally unique
identifiers--GUIDs--and in some cases removing the computer from or
adding it to the domain). Microsoft's planned support for MSCS and Exchange
Enterprise Edition versions that support active/active configurations, and
perhaps even service partitioning, should drive the data mirroring vendors to
even higher ground. Some vendors are already investigating the feasibility of
adding many-to-one Exchange failover capabilities.
Taking Stock
I hope you now understand why clustering isn't the only path to increased NT
availability. Although data mirroring doesn't fit my definition of clustering,
nor is it a fault-tolerant solution, it offers features that clustering can't
offer, and it might better meet your NT availability and business requirements.
If you want to use your existing equipment, can tolerate system-level failover
and restart of your existing applications, or are in search of an increased
level of disaster-tolerance, the recent improvements in data mirroring with
failover products more than justify a download from the Internet and a day or so
of evaluation.
End of Article
Prev. page
1
2
3
[4]
next page -->
