Further to the last article, here is another compelling reason to use the “one store per storage group” rule.
It is called continuous clustered replication.
A lot of people break out into a cold sweat with the word “clustered” as they think of Windows clusters, complexity, Active/Active nodes and tend to think of it as black magic. Not any more.
Continuous clustered replication is clustering but in a totally clever way...the live email server sends a copy of its transaction log to your passive node which receives that log and plays it forward in its own copy of the mail store. Consequently it is only ever about 1MB behind the live server and is working – minimising the downtime by removing the time spent recovering.
That doesn’t sound like DR so why is this titled DR when it is more about continuity and high availability? Well because you are shipping logs which can be done over the Internet without the need for both servers connected to each other (quorum). So if one server burns to the ground, assuming you have prepared for it (!), your remote CCR node is not only your high availability node but is also your DR plan.
You *have* got a DR plan, right?
2 comments:
So tell me again, the database and logs are stored on a separate server - your exchange server dies. You still need to rebuild your dead server and reinstall exchange before then relinking to your clustered stores and logs. Surely the hard part is going to be installing and reconfiguring your exchange. Or is that why you have backups and a DR plan...
You need to run the topologydiscovery service. The install of Exchange gets the files there and the topologydiscovery service picks up the information out of AD to configure your CAS/HT.
Other options would have been to move users to another server such as any legacy Exchange 2003 servers you may still have. Or perhaps install the CAS and HT roles into your mailbox server.
Sembee offered to come in during your problem to fix it :)
Post a Comment