The Benefits of Creating Multiple Storage Groups - Part 2
Last month I spent the first part of this article series talking about the various memory and hard disk related issues that you must consider when deciding whether or not to use multiple storage groups, or even multiple databases on a mailbox server. Now, I want to turn my attention to some of the practicality aspects of the various architectures.
One of the primary reasons why Exchange Server administrators sometimes divide up their mailboxes into multiple databases is because doing so can make it easier to recover the server in the event of a disaster. As I mentioned last month, dividing up the users into multiple databases can help to ensure that fewer users are impacted when database failures occur. There is more to it than that though.
Suppose for a moment that you had to restore a database from backup. The smaller the database is, the more quickly you could restore it. Distributing user mailboxes among several databases is one way of keeping the database size small.
Keep in mind though, that all of the databases in a storage group share a common set of transaction logs. This means that you may not end up saving much time during your recovery efforts unless each database is a part of a different storage group.
Another major reason for distributing mailboxes among multiple mailbox databases is that doing so can help to increase performance. Again though, the storage group structure plays a role in how well the server will ultimately perform. If all of your databases are located within a common storage group, then the volume containing the transaction logs could potentially become a bottleneck for the server. This volume isn’t always a bottleneck though, it just depends on the number of transactions that need to be processed and the speed of the disk array that stores the transaction logs.
If performance were your only goal, then you would usually be best off placing each database into a separate storage group, and having a dedicated disk array for each database, and for each set of transaction logs. In the real world though, hardware can be a bit pricey, and we don’t always get all the resources that we want. If you don’t have sufficient hardware resources to allow for a dedicated array for each database, and for each set of transaction logs, then you may be better off either using a single database or multiple databases within a single storage group (depending on how many disk arrays you have to work with)
The System Center Capacity Planner
Microsoft offers a free tool called the System Center Capacity Planner. If you are trying to figure out the optimum architecture for mailbox stores and storage groups, then I recommend giving this tool a try. The System Center Capacity Planner isn’t the easiest tool in the world to use, but it does give you some interesting results.
You can use that capacity planner to enter some information about your users, and the volume of mail that they produce. You can then enter information about your server hardware, and your intended Exchange Server architecture. The System Center Capacity Planner will then run a simulation and tell you about any performance problems that it anticipates based on the data that you have given it.
To give you an idea of what I am talking about, check out Figure A. I have created a sample Exchange Server organization, and run a simulation against it. The System Center Capacity Planner then provides me with information regarding the simulated deployment’s performance. Had there been any performance issues detected, those issues would have been reported along with the results shown in the figure.
The System Center Capacity Planner gives you a wealth of information regarding the anticipated performance of your proposed Exchange Server architecture.
By now you’re probably wondering whether you should place all of your mailboxes into a single database or not, and whether or not you should use multiple storage groups. As I said at the beginning of this series, I don’t think that this is one of those situations that has a one-size-fits-all answer. I have explained the various benefits associated with using each approach, but ultimately it is up to you to use the approach that makes the most sense for your own individual situation.
More in Exchange Server
Microsoft to Throttle Email Connections From Outdated Exchange Servers
May 9, 2023 | Rabia Noureen
Microsoft Brings Modern Authentication Support to Exchange Server 2019
May 5, 2023 | Rabia Noureen
Microsoft to Block Unsupported Exchange Servers from Sending Emails to Exchange Online
Mar 24, 2023 | Rabia Noureen
M365 Changelog: (Updated) REST API for On-Premises Mailboxes Preview Ending
Mar 14, 2023 | Petri Staff
Microsoft Advises IT Admins to Remove Some Exchange Server Antivirus Exclusions
Feb 24, 2023 | Rabia Noureen
Microsoft Recommends IT Admins to Patch Exchange Servers
Jan 27, 2023 | Rabia Noureen
Most popular on petri