We help IT Professionals succeed at work.

Exchange 2003 Cluster Space Issue & Disk Replacement

We have a space issue on a partition containing the exchange MBdata folder (with logs and databases for all information stores).  Our goal is to replace the drives in the RAID with larger capacity 300 GB drives with as little down time and risk to data as possible.  With the cluster setup I thought it would be good to get some feedback on our options.  Our setup specs before I go any further:

Windows 2003 Enterprise Cluster running Exchange 2003 Enterprise
Cluster is a two node active/passive setup on 2 Dell PE2950’s and a SV220s storage device
Exchange partition is a RAID 5 with 3 disks (currently around 130 GB of data)
Other Storage/Function Considerations:
-SQL 2005 (2 disks in a RAID 1)
-Data share used for business critical application (4 disks in RAID 5)
-Quorum (2 disks, RAID 1)
-1 Hot Spare
All disks are 68 GB and are hot swappable

Through some thought and research, we’ve come up with a few options:

A.      A forklift move of Exchange:  Down the Exchange; take the whole partition and copy it up to a NAS device we use for backup.  Then swap out the drives, setup the RAID, format the disk and configure the cluster resources/dependencies to use the new array.  Move everything back down from the NAS, and cross our fingers as we mount exchange again.  Obvious flaw in this plan is how long exchange is down for.  I tested moving an NT backup of the storage group and it took 3.5 hours.  So double that for the move back, we’re looking at 7-8 hours of down time, yuk.

B.      Mailbox move (Option 1):  There is a small message store that contains non critical mailboxes (old users, forwarding accounts, etc…).  The data share partition was way oversized in its inception and has 200 GB free on it.  We could down the message store, move it to the data share partition and then move the mailboxes on the other message stores over without ever having to down exchange.  I’m not really sure if I want to mess with the performance of the application that accesses this data though (since if we go this route exchange will eventually be competing for I/O with its spindles.  I’m not sure how this works on a cluster though- can I put an information store on a disk that is used on other cluster resources and dependencies (as this data partition is)?  Also, I’ve read that for every GB I move, there will be a GB in logs created on the sending and receiving information servers (http://support.microsoft.com/kb/821829); does this still apply if the information is staying on the same server and just moving to another information store and disk?

C.      Mailbox move (Option 2):  Buy another 300 GB in addition to the 3 we already purchased, and put it in place of the hot spare.  Instead of being a spare drive though, configure it as a standalone exchange disk cluster resource.  We can move the same small message store here instead of to the data partition and then move the mailboxes here. Swap other drives out and move the mailboxes back.  The same log question from B still applies, but now I don’t have to worry about overlapping cluster resources or affecting other applications’ performance and now have a big hot spare drive when everything is said and done.  The biggest and only downside I can see to this is that there is no RAID for exchange as we’re making the move, so speed will be affected and there won’t be any redundant disks for a couple of days.  I’m banking on the new disk being a reliable one!

As of right now, we're leaning towards C, but it's still pending approval for another $600 purchase.  Regardless which one I go with, the obvious also applies here as well, multiple good backups, esutil checks for DB consistency, etc.  So I’m looking for any helpful feedback- hopefully there is an expert that has been here before :)

Watch Question

Please have a look at the answer I gave once for a similar question:


The procedure described there is for SQL Server but it's the same we use for any cluster resource/service (done for Oracle, Exchange, SQl, File Share, ecc). It's identical at your option A and is what I prefer the most (except of the longer downtime issue).

The option C involves less downtime but remember that you'll have a RAID 0 volume till you move back to the new expanded partition (more a cross fiure issue :-) ).

I should go for option A but even with C, be sure to have a Full backup.


Thanks for the feedback!  I'm glad I'm getting confirmation on the options we've come up with-  must be doing something right :)  I think we're going to have to end up just crossing our fingers on the RAID 0.  As much as I was pushing for option A, it would a nervous 8 hours for all the users.  The company is very demanding and not very accepting of any downtime- even if it's planned on a weekend.  Of course the down time if new disk fails will be much greater!  


Can anyone comment on the log question from option B?  Do the logs grow a GB with every GB moved if I'm moving within the same server but to different information stores?  


Solution is accurate and the previous linked answer applies.  However it didn't really bring any new information to the party.  That may be mostly because of a thourough post.