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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Clustering Exchange Servers 4

Status
Not open for further replies.

GVN

MIS
Dec 2, 2005
238
US
We are running one Exchange Server 2003, but would like to build in some redundancy in case that box ever decides to die. Is clustering them what we need to do to accomplish redundancy? How hard is it to setup? Do you basically create another Exchange Server, then sync it up to the first one somehow? Any advice would be appreciated.

GVN
 
You will need to do some serious reading first!




Marc
[sub]If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all.
Free Tip: The F1 Key does NOT destroy your PC!
[/sub]
 
For hardware failure, a software solution isn't always the best plan. Clustering is very expensive and incredibly complicated.

A better solution (in my view) would be a single server with redundant power, disks etc configured carefully on a UPS with a good backup procedure in place.
 
I agree with Zel. My company has set exchange clustering up with a very large mortage company. I saw that because the budget for something like this is very large. Set up is (and i have done many enterprise exchange setups) amongst the hardest to configure properly and get stable.

Excellent Advice Zelandakh!

Chris Clancy, EnCE
Miles Technologies
clancy@4miles.com
 
I currently have a single server with redundant power, disks etc configured carefully on a UPS with a good backup procedure in place, as you suggest, -- however, I am wanting to have even a better level of redundancy, if possible. Why do people cluster mail servers, just for more processing power? I thought that redundancy was a driving factor as well...

GVN
 
Microsoft Cluster is primarily a failover tool although it can be designed to load balance the hardware as well if you go active/active.

If you are serious about fault tolerance, and have a serious budget to go with it, it is a good solution. Clusters can be a complex beast to tame and require a SAN or SAN Like Storage. This is where the majority of the complexity can come in.

There are other ways to increase fault tolerance as well. If you only have one Exchange Server, a more simple (and cheaper) alternative would be a second exchange server. This will allow you to split your users between two completly seperate mail servers that are independant of eachother, assuming of corse, properly designed smtp routing. If disaster strikes, you can move the users to the surviving mail server and get them online asap, and restore their mail later. Best part is, only half of your users were impacted.

All that being said, if your goal is zero down time at any cost, cluster is the answer.

On a final note, you may want to start reading up on Exchange 2007 features before you make a final decision. I think they are talking about some replication technologies that may provide a good comprimize to clustering, and you may find it is worth waiting for if you don't have cash for a SAN. I have not yet had time to dig too deep on this subject yet.
 
You can play with LCS and CCS in 2007 out of the box. Have a look at the stuff online about it as it is pretty cool.
 
Clustering essentially gives you failover in the event of a failed motherboard. Some people will argue that's not the case, but think about it:
1. Servers come with error correcting RAM
2. Servers come with multiple network cards (connect each to separate switches)
3. Servers come with RAID controllers and drives (use separate arrays for the transaction logs, stores, os, and paging)
4. Servers come with redundant power supplies (connect each to a separate UPS on separate circuits)

Follow Microsoft's Best Practices and learn the Disaster Recovery guides inside out. Even with clusters, you should do this.

Get the fastest warranty on your servers. With Dell, it's 4 hours. A new part and a tech in 4 hours, 24x7.

Installing clusters, as mentioned above is VERY complex, and extremely expensive. The ROI on clusters is very low.

If you do these things, and stay on top of them, the likelihood that you'll have unplanned downtime is a lot lower. With proper planning, you achieve 5 9's (99.999%) without using clusters.

Pat Richard, MCSE MCSA:Messaging CNA MVP
Want to know how email works? Read for yourself -
 
we run an exchange cluster... it's not that difficult to configure if you read about it. i don't get why so many people are against it.

our configuration is active/passive.

personally i think it solves a lot more than a dead motherboard issue... systems can still crash and servers still need to be restarted/turned off on occasion.

sure it's expensive, mainly because of the storage and licenses, but if email really is mission critical in your application then go for it.

only you can decide if a cluster is a good solution for your environment. i wouldn't give any credit to a post that suggests not to run a cluster because it's complicated or expensive. that's crazy. but make sure you know what you're doing.
 
If you just want hardware redundancy, clustering is crazy and overkill.
Just buy 2 identical machines, from wich one is emptied from disks and ram.
Make sure you have a decent backup and raid solution, and then pretty much anything can die withou you being out of businnes for hours. You swap the disks and the ram and you power on.
It also saves on licenses.

Marc
[sub]If 'something' 'somewhere' gives 'some' error, expect random guesses or no replies at all.
Free Tip: The F1 Key does NOT destroy your PC!
[/sub]
 
Keep in mind, also, that clustering does not prevent any problems involving the databases or logs. This includes fragmentation, corruption, viruses, etc.

Pat Richard, MCSE MCSA:Messaging CNA
Microsoft Exchange MVP
Want to know how email works? Read for yourself -
 
The main advantage of an MSCS A/P cluster is minimizing downtime, both scheduled and unscheduled. Unscheduled downtime for the component failure scenarios mentioned by 58sniper. Scheduled downtime for Service packs/hotfixes/etc.

In SLA situations where you have 99.9% or higher uptime requirements, clustering is often the only way to acheive that (99.9% uptime means only 8 hours and 45 minutes of downtime a year).

A shared storage solution does not protect against storage failure or data corruption, nor does it protect from a whole host of possible catastophic scenarios (fire, flood, earthquake, etc.). In many regulated industries where there are legally mandated retention requirements as well as business continuance requirements, the solutions range from offsite tape rotations to replication and geographic failover. The two major factors to consider are 1: How much data can you afford to lose (RP0) and 2: How long can you afford to be down (RTO). Here's an example of one of my replicated storage designs with an RPO of 5 minutes and an RTO of 2 hours:


The point is, the degree of fault tolerance you need is determined by the requirements of your business, and the service level agreements your organization has with the business units you provide services to. The place to start is to define the requirement.
 
My .02: making scheduled downtime easy is my top reason for appreciating clusters.

As far as redundancy, companies like Stratus ( make servers that make every hardware component redundant. Even the motherboard. They say that they oblivate the need for clusters, but "making scheduled downtime easy" still isn't something they provide for.

It's still a lot cheaper to just build another Exchange server and have a restore plan that can be put into effect quickly. Especially combined with some sort of online backup which allows you to restore data to a remote location. That gives you something that physical clustering can't: out-of-the-building restorability.

ShackDaddy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top