Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fault-tolerant Exchange storage 1

Status
Not open for further replies.

racy

IS-IT--Management
Apr 29, 2002
35
0
0
BR
Hi,

I have two exchange server nodes (over a SAN) and they are working pretty fine.

This basic exchange cluster provides just "services failover".

I need to avoid an exchange database crash.

How can I create a Fault-tolerant Exchange storage ?


Thank you

Racy


 
Thank you for your reply !

It is a HP solution.

Is Synchronous replication able to not replicate a crashed database ?

Is it by hardware or software ?

Best regards

Racy
 
Look to your hardware vendor for a solution. To move the data from the primary site to the secondary site, you're talking about replication. Your options are:

Synchronous
Semi-Synchronous
Asynchronous

When we talk about fault tolerant DR options, there are two main areas to consider. The first is RPO, or recovery point objective. This simply state how much data you are willing to lose in the event of a failure. The second is RTO or recovery time option. This represents the time it takes to restore funtionality.

With Synchronous replication, the RPO is zero. With semi-synchronous or asynchronous replication, the RPO is some value larger than zero usually expressed as a time. For example, if you use asynchronous replication sheduled at three hour intervals, the RPO in the event of failure is up to 3 hours depending on exactly when the failure occurred and when the data was last replicated.

To answer your question, asynchronous replication will provide some protection againt database corruption at the cost of an RPO greater than zero. Sychronous replication also provides some degree of protection, depending on the nature of the corruption, with an RPO of zero.

Another approach is to combine snapshots in the mix. In this approach you would snap tha databases every couple of hours, and the log files at a much more frequent interval. Then, replicate the snapshots. This gives you the greater protection from corruption that you get with Asynchronous replication, while reducing the RPO by replicating logs more frequently. On startup of the recovery server, the logs are replayed, so the cost of this approach is a potentially longer RTO.

 
Thank you xmsre,

Now I know what I do have to do !

It was a valuable post!

Best Regards

Racy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top