Upcoming Webinar
Cayosoft Shows How Forest Recovery Tech Addresses Survey Issues
Join this webinar and not only learn about what your peers are doing, but also learn about a new patent-pending modern approach to AD forest recovery from Cayosoft.
New episode!
The Scoop on Loop: The Latest Innovations Directly From Microsoft!
Darrell Webster speaks to Rebecca Keys, a Program Manager from the Microsoft Loop team.
Turn Data Protection into an MRR Growth Engine
Security for your customers, revenue for your MSP practice. Access key insights on how to scale your practice with SkyKick’s new eGuide.
MSP eGuide to Package, Sell and Deliver M365 Security Services
Based on input from our top-performing MSPs, SkyKick prepared the MSP Guide to help you navigate the security landscape.

The Benefits of Creating Multiple Storage Groups – Part 2

Introduction

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.

Disaster Recovery

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.

Performance

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.

Figure A

The System Center Capacity Planner gives you a wealth of information regarding the anticipated performance of your proposed Exchange Server architecture.

Conclusion

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.