Exchange 2007, Redundant Servers/Load balancing

[young_lew]

Hello, I'm back with some more trivial IT questions lol

Exchange 2007, can this be configured in a farm so that we have a redundant server to fall-over to, should one server go down?

I.e. a server that mirrors our exchange server which can take over if the first server dies. (although i understand it shouldn't die, but theoretically).

Or is it a case of load balancing the storage groups between the separate servers?

The next question is how easy would this be to implement into a system which only has one Exchange server currently. As i understand it would have been easier to set it up this way initially rather than later.

Any help or insight is appreciated.

 

[@Spoonie]

http://www.simple-talk.com/sysadmin/exchange/high-availability-in-exchange-2007/

Pretty much sums up your options.

 

[young_lew]

Ok i'll have a look at that, cheers.

 

[DMS]

Cluster + SAN = WIN.

 

[Cookie]

Cluster + SAN = WIN.

Yesh

I wouldn't even contemplate running Exchange 2007 on anything less than a few servers and a giant SAN for holding p**n/company information

 

[dk]

If you cluster it can only be the mailbox role so you need a third server (or 4 really) to host the hub transport and cas.

We do traditional clustering with shared disk on 2007.

You can't do load balancing as such as ms server is not active active. Load balancing would just be having different storage groups on different servers really.

As 2010 has just been released you might as well look at that as it's all changed massively again, but it's a much light app now so requires less io and you can happily run it on sata storage which was not something which is recommended on 2007.

 

[dk]

Yesh

I wouldn't even contemplate running Exchange 2007 on anything less than a few servers and a giant SAN for holding p**n/company information

You don't need a San with 2007, can happily use the clustering method (which the name escapes me, possibly ccs?) where the two servers both have there own storage and it gets replicated.

 

[Cookie]

I'm sure you don't need to, but I prefer the idea of having one big array and that feeding the cluster

I'm sure I did some testing on it with both ways, I can't remember the results though it was a few years ago

 

[young_lew]

It's just a route we're looking at right now so its not 100%, but Clustered Continuous Replication is what we'll probably do and have two servers running each service i.e hub transport CAS and mailbox. Unified messaging isn't important as we don't use voice mail or fax facilities through exchange.

we do have a NAS where the storage groups could be moved to but i'd rather not go down that route.

Cheers for the help

 

[@Spoonie]

I'm sure you don't need to, but I prefer the idea of having one big array and that feeding the cluster

I'm sure I did some testing on it with both ways, I can't remember the results though it was a few years ago

Typcially CCR will be split storage to remove the single point of failure. Active node is local data centre, passive in DR site. It uses MSCS to detect failures but there is no shared disks. Quorum is MNS.

Just means you can suffer a complete datacentre loss and have Exchange back up and running within minutes.

 

[David]

If you cluster it can only be the mailbox role so you need a third server (or 4 really) to host the hub transport and cas.

We do traditional clustering with shared disk on 2007.

You can't do load balancing as such as ms server is not active active. Load balancing would just be having different storage groups on different servers really.

As 2010 has just been released you might as well look at that as it's all changed massively again, but it's a much light app now so requires less io and you can happily run it on sata storage which was not something which is recommended on 2007.

you have any links on info for this? i thought 2007 would run on anything, we're going to run it in sata storage so this knowledge would be helpful.

 

[dk]

its kind of from experience, exchange 2007 needs fast disks as its quite io intensive and sata disks are not designed for this use, they are for archival data, large media files etc.

you can get about 2-300 io's per sas drive in an san compared to about 40 io's per sata drive, so theres a massive difference, plus the mtbf is much worse and they normally (well hp anyway) only come with a 1yr warranty.

As the io requirements of 2010 are 70% less than 2007 and through the use of dags theres now not as much emphasis on fast resilient san storage, although it wouldn't hurt.

Q. Is it true that Exchange 2010 supports SATA disks and disks not in a RAID array?
A. Exchange 2010 has a new I/O pattern that results in 70 percent lower I/O requirements than Exchange 2007 (and Exchange 2007 had 70 percent lower I/O requirements than Exchange 2003!). This reduced I/O pattern, thanks to optimizations that make it so writes don't come in bursts anymore, combined with advancements in SATA drives, means [COLOR=blue ! important][COLOR=blue ! important]SATA[/color][/color] is now a realistic storage platform for Exchange 2010. SATA was previously just for desktop [COLOR=blue ! important][COLOR=blue ! important]systems[/color][/color].
In addition, with the new database availability group (DAG) for high availability of mailboxes, the new guidance from Microsoft is that if you have databases replicated on at least three [COLOR=blue ! important][COLOR=blue ! important]servers[/color][/color] in the DAG, you don't even need RAID on the storage anymore. Because you have backups of the data in essentially real time on the mailbox duplicates and Hub Transport dumpster, you can use just a bunch of disks (JBOD) configurations. If you don't use DAG or have only two servers replicating a database, you should still use RAID for the database. RAID was previously used for I/O purposes in addition to high availability, but because of the drop in I/O requirements, single disks are now an option. [COLOR=blue ! important][COLOR=blue ! important]Microsoft[/color][/color] is suggesting one disk per database/transaction log going forward, providing you have the database replicated between at least three servers.
It's still very important to perform sizing exercises to ensure that, even with the reduced I/O, pattern the disk configuration will meet requirements.
An illustration of acceptable storage solutions for Exchange from 2003 to 2010 is shown here.

Using SATA makes it easier to allow users to have bigger mailboxes without excessive storage costs, even if you need three separate copies. Also with SATA, you can consider not performing backups anymore. Now you can high availability through multiple copies of the database, configurable lags in replay of transaction logs on certain copies (meaning we have copies of the database that look like the database some number of days ago), archiving, and the protected dumpster protection for deleted items retention. For some companies, performing a backup may no longer be required, if all the right configuration and procedures are in place.

it does all depend on what types of user we are talking, how heavy their profile is and whether they are in cached mode or not etc.

if you are going to use SATA I would recommend going for midline SAS as a minimum which is a SATA drive with a SAS connection making it more reliable.

I personally could not recommend to a customer that they use SATA disks for the message store on 2007, 2010 is a different story......

 

[David]

thanks for that, a lot of the team here don't want to move to 2010 as it's too young, but i can't help but feel there are a considerable number of advanatges. Atm we have a dedictaed iscsi san for exchange but we're migrating from 2003 to 2007, just in my mind we should be skipping 2007 entirely!

 

[Darren S]

Cheers for the heads-up on this dk. We're currently running Exchange 2003 but are weighing-up moving to 2010. Certainly some pointers to think about there.

D.

 

[The Hoff]

Get a Webex with these guys [http://www.mimecast.com], we implemented it at my old place. It's so simply it's freaky, it's quicker to reflect changes over their grid network, than it is to apply them on our servers 10 metres away.

All you basically need to do is to change your MX records, backup your PST's [if you use the b@stards] and send them to Mimecast for manual journalling, then you're set. You can then set fire to your exchange server, upgrade it, turn it off, and not have to worry.

Costs for us were about £30 per user, per year. Could thoroughly recommend them, that is providing of course you're looking to redundancy for BC/DR purposes, and not to get a performance increase from a server that's struggling to juggle.

 

[dk]

thanks for that, a lot of the team here don't want to move to 2010 as it's too young, but i can't help but feel there are a considerable number of advanatges. Atm we have a dedictaed iscsi san for exchange but we're migrating from 2003 to 2007, just in my mind we should be skipping 2007 entirely!

I'd have to agree, 2010 is definitely the way to go, some cool new features in outlook 2010 too, we have headshot pics against emails and some cool thins with calendars. Although I think office is still in rc, exchange is fully out, I've installed it In a test environment but not in a live environment yet but we have a lot of customers doing the usual ms thing and move from 2003 to 2010, skipping a version seems to be common practice.

Although, migrating from 2003 is not as straightforward as going fom 2007, you need to go from 2003 to 2007 and then to 2010. Or depending on the number of users you could export the mailboxes to psts and import them again, but this is ony for small companies as it could get a bit longwinded!

 

[Mike_182]

What David (dk) said RE: 2010. Done it on a 'live' server at a client to host a few people's mailboxes and it seems stable enough so they're going the whole hog shortly. Plenty of massively useful features to justify it (new retention abilities being key for my client!) and 2007 was a bit ropey IMO anyway!

 

[dk]

Get a Webex with these guys [http://www.mimecast.com], we implemented it at my old place. It's so simply it's freaky, it's quicker to reflect changes over their grid network, than it is to apply them on our servers 10 metres away.

All you basically need to do is to change your MX records, backup your PST's [if you use the b@stards] and send them to Mimecast for manual journalling, then you're set. You can then set fire to your exchange server, upgrade it, turn it off, and not have to worry.

Costs for us were about £30 per user, per year. Could thoroughly recommend them, that is providing of course you're looking to redundancy for BC/DR purposes, and not to get a performance increase from a server that's struggling to juggle.

We use mimecast for dr at the moment, think we are their top reseller (meaning we get it free lol, we never pay for anything, which normally means the products we use internally are the best as we have the choice to use them all. So I'd recommend the products we use) and are looking to use their journaling soon, we host te exchange in-house though.

Basically, if our exchange goes down we log into a web portal and all our email is there as it all goes through mimcast when sending and receiving normally.

There are some downsides but in the main it's excellent.

 

[ChrisR]

Don't MS say that you don't need to backup 2010 with all it's fancy redundancy stuff?

 

[dk]

They do, think you need to have several dags or whatever they are called on different sites, they also say you don't need raid too!

 

[The Hoff]

Anybody fooled into thinking MS's efforts will work, without flaws in a DR situation, is exactly that, a fool. Unless I had an MS bod on site, I wouldn't trust them with retaining all of my data, ever.

Mimecast is the way forward, and we'd continue to use it, no matter what platform we're running. The cost versus benefits are ridiculously good. Not sure if they've upgraded their Web Client yet, as when I left 4 months ago it was still a little... Exchange 2k looking, but understood they were upgrading shortly? The other PITA was having to flatten a users mailbox structure in certain circumstances, but I understood they were also improving that.

Either way, recommended.