Updates to the Exchange 2007 Mailbox Server Role Storage Requirements Calculator

To read the updated calculator blog post and get the calculator, go HERE.

All future calculator updates will be rolled into this page, sorted from newer to older.

UPDATE ON 06/16/2010:

Version 17.6

Bug Fixes

• Fixed Read IOPS / mbx calculation to take into account the four scenarios (no desktop search engine and no multiplication factor, no desktop search engine and multiplication factor, desktop search engine and no multiplication factor, desktop search engine and multiplication factor)

UPDATE ON 06/15/2010:

Version 17.5

Bug Fixes & Enhancements

• Fixed the IOPS calculation formula to take into account the scenario where both the IOPS Multiplication Factor is set to a value above 1 and the Outlook client type is Online Mode.
• The calculator now correctly evaluates the formatted disk capacity of disks, as opposed to estimating it.

UPDATE ON 05/06/2010:

Version 17.3

Bug Fixes

• Changed the Input and Results sections to correctly indicate whether you are utilizing standalone or clustered mailbox servers.
• Fixed storage design calculations to exclude RAID-5 and RAID-6 for 7.2K disk scenarios as they are not recommended due to the IO overhead when compared with RAID-1/0 solutions.
• Made it so that for backup failure tolerance you must select a number greater than zero.
• Fixed step 4 description on the Input page.
• Fixed RAID Rebuild overhead calculations to not deal with 100% or greater scenarios
• Updated storage design important statement

Enhancements
Originally, the IOPS Multiplication Factor calculations worked as follows:

<Base IOPS> + (<Base IOPS> * <IOPS Multiplier>) = <New IOPS Profile>

This was often times confusing, especially with regards to third-party applications that had multiplication factors.  To coincide with the updated BlackBerry Enterprise Server for Microsoft Exchange 2007 Performance Benchmarking Guide we’ve simplified the formula as follows:

<Base IOPS> * <IOPS Multiplier> = <New IOPS Profile>

UPDATE ON 04/27/2009:

Version 16.9

Bug Fixes

• Fixed the LUN Configuration table's SCR Target column results to accurately reflect the correct number of LUNs based on the SCR target configuration per source server.

UPDATE ON 04/23/2009:

Version 16.8

Enhancements

There are many add-ons, applications, client devices that impact the mailbox I/O profile in terms of some multiple.  To aid you in your designs where you know this impact, we are introducing a new input field in the Mailbox and Client Configuration of the storage calculator.  The way this value is used is as follows: ((db reads + db writes) * Multiplication Factor) + (db reads + db writes) = new IOPS value.  To understand this, let's evaluate a few scenarios:

1. If you have mailboxes with a 2GB heavy message profile utilizing cached mode clients, with the IOPS prediction formula enabled and want to include an additional impact of 3.67, then the IOPS per mailbox will be:

= (((0.0048 * 100) * (5 ^ -0.65)) + (0.00152 * 100))* 3.67) + (((0.0048 * 100) * (5 ^ -0.65)) + (0.00152 * 100))
= (.32 * 3.67) + .32
= 1.49

2. If you have mailboxes with a 2GB heavy message profile utilizing online mode clients, with the IOPS prediction formula  enabled and want to include an additional impact of 3.67, then the IOPS per mailbox will be:

Online Mode Impact for 2GB mailbox = 12.5
DB Reads = (((0.0048 * 100) * (5 ^ -0.65))* 3.67) + ((0.0048 * 100) * (5 ^ -0.65) * 12.5) = 2.73
DB Writes = ((0.00152 * 100)* 3.67) + (0.00152 * 100) = .71

= 2.73 + .71
= 3.44

The reason this formula differs from the cached mode formula is that we already over provision database read I/Os for online mode due to the likelihood that desktop search solutions are indexing against the mailbox server.  As a result, we didn't want to include the multiplication factor with that overhead (in other words the multiplication factor impact ignores the fact that the client is operating in online mode).

3. If you have mailboxes with a 2GB heavy message profile utilizing cached mode clients, with the IOPS prediction formula disabled (configured to use 1.0 custom IOPS profile) and want to include an additional impact of 3.67, then the IOPS per mailbox will be:

= (1.0 * 3.67) + 1.0
= 4.76

Bug Fixes

• The Disk Space and Requirements table was updated to remove confusion around space requirements vs. LUN requirements as they are two separate entities.  The space requirements fields simply state the space required for the Logs or database while LUN requirements fields include the content index capacity, the LUN free space requirement, restore/maintenance capacity (if restore LUN is disabled).
• On the Storage Design tab, the Total Number of SCR Disks Required for the Single Mailbox Server row was updated to include the correct count of SCR disks when the source solution is CCR and the SCR target configuration is designed to match the source configuration.
• 7.2K SAS disks were added to the Storage Design Disk Type field.  These disks provide 60 random IOPS at the controller when under a 4K/8K 1:1 read:write ratio with latency under 20ms with 80% capacity utilized (essentially they are about 20% faster than 7.2K SATA disks from a random I/O perspective).
• The User Mailbox Configuration table on the Storage Requirements tab now exposes the calculated database cache / mailbox (which is based on the recommended memory configuration and is used in the I/O prediction formula calculations) as opposed to the desired database cache based on the message profile.
• Updated various comment fields.

UPDATE ON 01/06/2009:

Version 16.3

Enhancements

• We added the calculated (or user defined) read/write ratio per mailbox tier into the Storage Requirements Results User Mailbox Configuration table.
• We added the server's calculated database read I/O percentage value into the Storage Requirements Results Disk Space & Performance Requirements table.
• Since the Recovery Point Objective input question only dealt with SCR, we moved that from the Log Replication section to the Standby Continuous Replication Configuration table.
• We added a new message profile, Extra Heavy.  With this additional profile, we now have 5 available messaging profiles as defined in the following table:

Mailbox profile	Message profile	Logs generated / mailbox (50KB Message Size)	Database Cache / Mailbox	IOPS Profile / Mailbox (Cached Mode)
Light	5 sent/20 received	6	2 MB	0.11
Average	10 sent/40 received	12	3.5 MB	0.18
Heavy	20 sent/80 received	24	5 MB	0.32
Very Heavy	30 sent/120 received	36	5 MB	0.48
Extra Heavy	40 sent/160 received	48	5 MB	0.64

Our TechNet guidance will also be updated to include this new profile in upcoming months.  In addition, LoadGen will include this new profile in a future web release.

Bug Fixes

• In prior versions, when you selected to use SCR and wanted to match the source configuration design, the following tables did not accurately reflect the correct values for the given SCR configuration (in so far as by selecting to match a source CCR configuration that means there are 2 SCR targets for every active database instance, so if you had 2 CCR clusters then you would have at least 2 SCR targets per CCR cluster):
  1.    Disk Space & Performance Requirements - Total for all SCR Servers column, all rows.
  2.    LUN Configuration (per Server) - SCR Targets column, Total Recommended Exchange LUNs row.
  3.    Storage Configuration - Environment column, Total Number of SCR Disks Requirement row and Total Number of Disks Required row.

UPDATE ON 09/23/2008:

Version 16.0

Bug Fixes / Enhancements

• The changes introduced in v15.6 in the Storage Design worksheet introduced a logic error where the recommended RAID Configuration / Server would recommend a null configuration when you selected "--" for the database disk type in Configuration 3.  This has been corrected to ensure that only enabled disk configurations are considered when making a recommendation.
• Validation logic was added to the custom database size input factor to remind you that you need to enter in a value greater than 0.
• Fixed various input factor comments.
• Fixed RAID-0 calculations for the database and log configuration options 2 and 3.  In previous releases, the RAID-0 values for these configurations were utilizing the RAID-1/0 data points.
• Updated the backup and restore rate input factors to indicate that these only apply for steaming backup calculations.  Also added validation logic to disable the input options when VSS backup methodologies are chosen.
• Fixed the streaming backup rate calculations to include all transaction logs generated in a day (user generation + move mailbox).  Previous releases only considered user log generation.
• Updated the text and note for the "Additional I/O Requirement" field to indicate that the input value is per mailbox server.
• Added streaming restore calculations for both full database restore and incremental / differential backup restore to the Backup requirements worksheet.
• Added the following note to the Storage Design worksheet - Important: This tool should only be used for storage modeling purposes.  Please consult with the storage vendor regarding storage design and follow recommended storage design testing processes.  The example configuration provided within this calculator is just that, an example, and as such, each input option needs to be evaluated as to how it will affect your design.

UPDATE ON 08/20/2008:

Version 15.6

Bug Fixes / Enhancements - Storage Design Worksheet

• We now explicitly show that in CCR configurations there is a Restore LUN on both the active and passive nodes.  In previous versions, the calculator only included that in the "Total Number of Disks Required (Replica)" calculation but did not show it in the "Recommended RAID Configuration / Server" table.
• We changed the way you enter in different disk configurations in the "Input Factors - Disk Selection".  In the previous release there were three tables, one table for the database disks, one table for the log disks, and one table for the restore LUN disks.  This view was confusing to end users and ultimately in terms of how we displayed the results.  As a result, in this version, we now have three tables, one for each disk configuration.  In this way, a configuration table can be considered as a potential storage solution that you might want to deploy. 
• In the previous release, the "Recommended RAID Configuration / Server" table could provide disk configurations that were incompatible with one another (for example, database disks used 146GB 2.5" SAS disks (Option 1) while the log disks used 300GB 3.5" FC disks (Option 2), while the restore LUN disks used 500GB SATA disks (Option 3)).  In this release, we now ensure that the disks and the number of disks being recommended all come from the same disk configuration input table.  The storage recommendation in the results table still follows the basic principle of recommending the disk configuration that utilizes the least total number of disks while still ensuring both I/O performance and disk capacity are met.
• We added an important note to emphasize that the calculator solely bases its recommendation on the least number of total disks and does not take into consideration cost or power consumption.

Bug Fixes / Enhancements - Log Replication Requirements Worksheet

• We fixed "SCR Log Throughput Required / SCR Target" to display throughput requirements per source mailbox server for the scenario where there are multiple source mailbox servers (for the scenario where you want to know the log throughput requirements for each source mailbox server); this field was also renamed to "SCR Log Throughput Required / SCR Target / Source".
• We added a "Geographically Dispersed CCR Throughput Required / CMS" metric for the scenario where there are multiple mailbox servers and you want to know the log throughput requirements for each source mailbox server.

Bug Fixes / Enhancements - General

• We fixed the mistake where the Tier-2 Mailbox input table listed Tier-3 in the text instead of Tier-2.
• We now indicate that the LUN Requirements and Backup Requirements worksheets are per server and not for the entire solution.
• We added the following information to the "Additional I/O Requirements" comment field: 

Or consider this methodology.  You know an application that you will be using will generate an I/O increase per mailbox.  To determine how much I/O you need follow these simple steps:

1. Determine the I/O requirements without the application's overhead. -> For example, you are designing a solution for 1000 heavy profile mailboxes.  From the output of the calculator you know that each mailbox will require .32 IOPS, for a total of 320 host IOPS required to sustain all the databases.
2. Determine the application overhead. ->For example, the application increases the I/O overhead by a factor of 4.  For this scenario that would be (1000 *.32 *4) = 1280.  So the total I/O that has to be sustained from the host perspective for the databases is (1280 + 320) = 1600
3. Enter in the application overhead into the "Additional I/O Requirements" field. -> For our scenario you would enter 1280.

New Functionality

• None.

UPDATE ON 06/26/2008:

Version 14.8.

Bug Fixes

• When you have a source mailbox server that is CCR and SCR is enabled and configured to match the source configuration, we replicate the logs to both nodes of the SCR standby cluster to ease activation.   As a result of that the replication throughput for SCR doubles for each mailbox server source.  Version 14.7 did not take this into account.  Version 14.8 as a result corrects this and ensures that the proper throughput requirements are shown.

UPDATE ON 06/12/2008:

Version 14.7.

Bug Fixes

• Fixed the mailbox size calculation formulas to always round up, thereby providing a consistent result.
• Added support note for GPT disks in Windows Server 2003 clusters (http://support.microsoft.com/?id=919117).

Usability Enhancements

• Quite a few people have requested that we provide a "High Availability Model" option as opposed to a "Continuous Replication Model" input option. In this version we now allow you to choose between no HA, LCR or CCR configurations, and SCC configurations.
• The SCR input options have been expanded to include the high availability model you would like to use for the target environment. You can select either "Single-Node" or "Match Source Configuration" for the high availability configuration. If you choose single-node you are either deploying 2-node source clusters (CCR or SCC) and want only a single node to be the standby cluster or you are deploying standalone mailbox servers (or LCR); the other option for "Single-Node" is if you are performing database portability instead of server recovery. If you choose "Match Source Configuration" you are performing server recovery to retain the same level of availability as the source environment. Also when you choose "Match Source Configuration" and you are utilizing CCR as your source mailbox server, then the calculator will automatically assume that you want to replicate the storage groups to both nodes within the SCR standby cluster, thus removing the need to perform a database seed to the passive node when you activate the standby cluster.
• Enhancements have been made to various sections of the Input worksheet to do disable features based on a previous input and to ensure you provide the correct values:
  • For example, if you select to have zero SCR targets, the other SCR input options are grayed out:

•  
  • For example, if you want to provide your own IOPS values and not use the IOPS prediction formula, you must enter both an IOPS value and a read:write ratio.

• On the Storage Requirements worksheet, we now provide you with a listing of the number of mailbox and SCR target servers that you will be deploying based on your Input worksheet selections. As you can see from the below screenshots, you will be deploying 2 CCR source servers and require 2 SCR single-node cluster targets for each CCR source server. This design will provide 4 database copies per storage group for each clustered mailbox server.

• On the Storage Requirements worksheet, we now outline the total disk space required for the environment. In the Disk Space & Performance Requirements table, we now provide the following breakdown:
  • Single Server - This is the amount of disk space and I/O required for each replica for the clustered or standalone (LCR if enabled) mailbox server. For example, in a CCR configuration, each replica will need to sustain 231 IOPS and have a database LUN that has 1958 GB of capacity.
  • Total for all Mailbox Servers - this is the total (i.e. includes source and replica) amount of disk space and I/O required for all the mailbox servers that will exist in the environment. For example, for 2 CCR environments, the total database LUN space required is 7833 GB (1958 GB * 4).
  • Total for all SCR Servers - this is the total amount of disk space and I/O required for all SCR target servers that will exist in the environment. Note that if you select the SCR HA Configuration to "Match Source Configuration" and you are deploying CCR, then it is assumed that you will be replicating the source storage groups to both nodes in the SCR standby cluster.

 

New Features - Storage Design

In the past, the mailbox storage calculator only provided capacity and I/O requirements for the design. With this release, the mailbox storage calculator includes a new worksheet, Storage Design. The Storage Design worksheet allows you to select the disk types and capacities you would like to use in your environment. The calculator will determine the appropriate RAID configuration and the number disk spindles you need that meet your capacity and performance requirements. The key features are:

• You can select the type of parity grouping mechanism your storage utilizes.
• You can deploy a specific RAID configuration (RAID-0, RAID-1/0, RAID-5, or RAID-6).
• You can select the rebuild overhead penalty you would like to build into your configuration.
• You can compare up to 3 different disk types/capacities to ensure that you are utilizing the best configuration while reducing the number of spindles.

Important: The Storage Design worksheet is not designed for any particular storage vendor, and as such, you should validate the design not only with your storage vendor, but by utilizing stress and load generation tools before production implementation.

For more information on how to use the Storage Design worksheet, see the Exchange 2007 Mailbox Server Role Storage Requirements Calculator blog article.

UPDATE ON 02/29/2008:

Version 13.7.

Bug Fixes

• Fixed the print margins so that now each worksheet will print out on a single page.
• Updated several comments across several tables to ensure accuracy with the data being represented.

Enhancements

• Added the latest version link URL so that you can always check the site to see whether a new version is available.
• Improved the Log Replication Requirements results section.  The new format should make it very clear as to whether the chosen network link is acceptable for log replication.  If it is not, a suitable network link is recommended.  Additionally, the appropriate Windows Server 2003 TCP/IP settings are listed for both geographically dispersed CCR and SCR.
• The Storage Requirements result section was updated and enhanced in preparation of a new feature most of you have been asking for...see below, don't want to spoil it...

And last, but not least... New Features

Projected Number of Mailboxes Growth

The first new feature that has been added is the ability for you to specify during the solution's lifecycle the projected growth in terms of number of mailboxes.  This way you can now easily model the increase in capacity and performance requirements by dialing the projected growth.

Network Failure Tolerance

When deploying geographically dispersed CCR or SCR across a WAN link there is the possibility that the network link between the two locations will become unavailable.  As a result, truncation on the source cannot occur.  To ensure you have enough space to survive the network outage an additional parameter needs to be taken into account when sizing space for the Log LUN.  Since the calculator already includes a backup failure tolerance parameter, this parameter will only supersede that parameter if it is larger.

As a result, the formula for calculating backup log space requirements is as follows:

NumTLogs x factor

= [If SCRReplayLagTime=0 and SCRTargets<>0 then 50 + NumTLogs, otherwise just NumTLogs] x factor

Where factor is

If performing daily differential backups, factor  = MAX(MAX(7, MAX(BackupFailureTolerance,NetFailureTolerance),SCRReplayLagTime+SCRTruncationLagTime),7* MAX(BackupFailureTolerance,NetFailureTolerance))

>>The above formula is for daily differential backups and ensures that we have the largest window in terms of capacity to survive multiple truncation failures (since log truncation only occurs once a week), a network outage, or to have enough capacity to handle the SCR window.

• If Restore LUN = yes, factor = MAX(SCRReplayLagTime+SCRTruncationLagTime, MAX(BackupFailureTolerance,NetFailureTolerance))

  >>The above formula is for daily incremental backups or daily full backups (with Restore LUN) and ensures we have enough capacity to survive multiple truncation failures, a network outage, or to have enough capacity to handle the SCR window.  Since a Restore LUN exists, we don't need to be concerned with restore capacity (i.e. 7 days worth worst case with daily incremental backups) on the Log LUN.

  • If Restore LUN = no and performing daily incremental backups, factor = MAX(MAX(BackupFailureTolerance,NetFailureTolerance),SCRReplayLagTime+SCRTruncationLagTime,7)

>>The above formula is for daily incremental backups (without a Restore LUN) and ensures that we have enough capacity to handle restoration of all logs (7 days) or survive multiple truncation failures, a network outage, or have enough capacity to handle the SCR window.

•  
  • If Restore LUN = no and performing daily full backups, factor = MAX(SCRReplayLagTime+SCRTruncationLagTime,MAX(BackupFailureTolerance,NetFailureTolerance))

>>The above formula is for daily full backups (without a Restore LUN) and ensures that we have enough capacity to survive multiple truncation failures, a network outage, or have enough capacity to handle the SCR window.

Multiple Mailbox Server Support

This has been the most requested feature for the calculator.  So I've delivered it finally!  You can now enter into the calculator how many mailbox servers you want in your environment.  In turn, the calculator will recommend per server requirements, as well as, output requirements for all servers entered.  Please note that there are a few restrictions/caveats:

1. All mailbox servers are configured the same (i.e. you cannot select CCR for some and not the rest).
2. The calculator will evenly distribute the number of mailboxes entered in Step 2 across all mailbox servers.  So if you enter into the calculator 10000 mailboxes, and choose to have 2 mailbox servers, 5000 mailboxes will be placed on server 1 and 5000 mailboxes will be placed on server 2.

UPDATE ON 12/19/2007:

Version 13.0.

• We have updated the log generation numbers per message profile to be in line with our updated guidance.
• In v11.8, we decided to list the database cache per mailbox in the Storage Requirements results section.  However this lead to confusion because it was named "Memory Profile / Mailbox" which implied that you would only utilize the associated amount of memory with the message profile (i.e. 5MB with Heavy profile), however that is not always the case. For example, 1200 2GB Light message profile mailboxes only requires 5GB of RAM (1200 * 2MB + 2GB), however the design requires 13 databases, which with SP1 requires 6GB of RAM.  ESE will utilize 4GB of that RAM for the cache.  As a result, 4096MB / 1200 ? 3.5MB per mailbox. So to make this clear, we have changed this text to be "Database Cache / Mailbox" which indicates how much cache is available per mailbox.
• In the scenario where you override the IOPS prediction formula for your mailbox tiers, we have adjusted the "Read:Write Ratio" input to allow you to enter any read percentage you would like, rather than restricting you to a few key ratios.
• We updated the "Database Reads / Mailbox" calculation description.
• We updated the Log Replication Requirements worksheet, simplifying the data displayed in the results section.
• We have included new functionality for log replication requirements.  You now have the input options for entering your network link type and its associated latency.  These options are then used to recommend TCP/IP optimization settings for Windows Server 2003 when utilizing geographically dispersed clustering and/or standby continuous replication.  In addition, if the chosen network link cannot sustain the throughput requirements for log replication, we will recommend an appropriately sized network link and Windows Server 2003 TCP/IP optimization settings.

UPDATE ON 10/24/2007:

Version 12.0.

Bug Fixes / Miscellaneous:

• Addressed the scenario where database read transfers, database write transfers and log transfers did not take into consideration the Additional I/O Requirement input value when it did not equal zero.
• Added a note to the Storage Requirements tab that discusses the difference between Log I/O (sequential) and Database I/O (random).

Memory Enhancements:

Back at RTM, we released guidance about requiring a minimum amount of RAM based on the servers number of storage groups.  This basically worked out to requiring 500MB of RAM per storage group. 

In SP1, we have made some jet/store improvements (to be covered in a later blog post) that have reduced that footprint.  As a result we are updating our guidance (will be published in the November content refresh) as follows:

Storage group count	Exchange 2007 minimum required physical memory	Exchange 2007 Service Pack 1 minimum required physical memory
1-4	2GB	2GB
5-8	4GB	4GB
9-12	6GB	5GB
13-16	8GB	6GB
17-20	10GB	7GB
21-24	12GB	8GB
25-28	14GB	9GB
29-32	16GB	10GB
33-36	18GB	11GB
37-40	20GB	12GB
41-44	22GB	13GB
45-48	24GB	14GB
49-50	26GB	15GB

Therefore, we have updated the calculator to take these changes into account.  Now when using the calculator, you have the option to select whether you will be deploying the RTM or SP1 version of the product.  Based on the version you select, the corresponding column from the above table will be taken into account when calculating the minimum amount of memory required for the server based on the number of storage groups.

UPDATE ON 10/9/2007:

Version 11.8.

Based on customer feedback, this release introduces several usability improvements and bug fixes.

Bug fixes / Usability Improvements

• The Memory Profile / Mailbox output in the Storage Requirements Results Pane now lists the calculated memory profile that was used in determining the server's memory requirements, rather than simply listing the message profile's memory profile.
• Fixed the 2TB Special Note so that it does not appear when Restore LUN is disabled.
• Fixed the database read and database write I/O calculations to take into consideration user concurrency.
• Moved SCR related input factors into a dedicated table.

SCR & Log Capacity Calculation Changes

With the release of 11.x we received very positive feedback regarding the incorporation of SCR planning into the calculator.  However, we also received feedback that the SCR options did not provide the same granularity that exists in the Exchange 2007 SP1 product.  As a result of this feedback, we made the following changes:

• Added SCR Log Truncation Lag Time option (entered in seconds).  The default for this is zero seconds.
• Adjusted SCR Log Replay Lag Time option to also be entered in seconds.   The default for this parameter is 24 hours (in the case of the calculator, this is entered as 86400 seconds).

Due to the incorporation of SCR's truncation lag time parameter, we also had to adjust the way we calculate log backup capacity to include the truncation lag time for both source and replica (if you are wondering why we are including it in both source and replica it is to allow you to activate and reverse the SCR location for the entire server).    The new logic for the backup capacity formula  is as follows:

NumTLogs x factor

= [If SCRReplayLagTime=0 and SCRTargets<>0 then 50 + NumTLogs, otherwise just NumTLogs] x factor

Where factor is

• If performing daily differential backups, factor  = MAX(MAX(7,BackupFailureTolerance,SCRReplayLagTime+SCRTruncationLagTime),7*BackupFailureTolerance)

>>The above formula is for daily differential backups and ensures that we have the largest window in terms of capacity to survive multiple truncation failures (since log truncation only occurs once a week) or to have enough capacity to handle the SCR window.

•  
  • If Restore LUN = yes, factor = MAX(SCRReplayLagTime+SCRTruncationLagTime,BackupFailureTolerance)

>>The above formula is for daily incremental backups or daily full backups (with Restore LUN) and ensures we have enough capacity to survive multiple truncation failures or to have enough capacity to handle the SCR window.  Since a Restore LUN exists, we don't need to be concerned with restore capacity (i.e. 7 days worth worst case with daily incremental backups) on the Log LUN.

•  
  •  
    • If Restore LUN = no and performing daily incremental backups, factor = MAX(BackupFailureTolerance,SCRReplayLagTime+SCRTruncationLagTime,7)

>>The above formula is for daily incremental backups (without a Restore LUN) and ensures that we have enough capacity to handle restoration of all logs (7 days) or survive multiple truncation failures or have enough capacity to handle the SCR window.

•  
  •  
    • If Restore LUN = no and performing daily full backups, factor = MAX(SCRReplayLagTime+SCRTruncationLagTime,BackupFailureTolerance)

>>The above formula is for daily full backups (without a Restore LUN) and ensures that we have enough capacity to survive multiple truncation failures or have enough capacity to handle the SCR window.

Important

Changes made to the calculator in the v11.x time frame have resulted in the calculator no longer being backwards compatible with older versions of Excel.  If you do not have Excel 2007 and would like to use the calculator, please download VirtualPC 2007 (http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en) and the Office 2007 VHD (http://www.microsoft.com/downloads/details.aspx?FamilyID=f9956176-cf66-478b-b20d-b9b92dd0dbfa&DisplayLang=en).

UPDATE ON 8/31/2007:

Version 11.2.

• V11.0 introduced a bug where the Restore LUN capacity calculation would result in less capacity than compared with previous versions when you had a LUN Design Architecture of 2 LUNs / SG.  This has been corrected.
• The LUN Configuration table will now show the appropriate SCR LUN configuration when LCR/CCR are not enabled.

UPDATE ON 8/27/2007:

Version 11.0.

In this release we have made a few formatting changes, in addition to the following major changes:

LUN Architecture Changes

 

 

 

In previous versions of the calculator, if the LUN Architecture was based on the 2 LUNs / Backup Set model, the calculator would align the LUNs so that there were always 7 SGs per LUN.  So for example, if you had a server architecture with 10 storage groups and you wanted to use the 2 LUNs / Backup Set model, the calculator would recommend LUNs 1 and 2 for SG1 through SG7 and LUNs 3 and 4 for SG8 through SG10; as you can see this was configuration was not very desirable because of the uneven split of storage groups.  In this version of the calculator, we split the storage groups up appropriately - so for example in the 10 SG scenario, you will see LUNs 1 and 2 for SG1 - SG5 and LUNs 3 and 4 for SG6 - SG10.

Backup Architecture Changes

 

 

 

Just like with the LUN Architecture, if the LUN Architecture was based on the 2 LUNs / Backup Set model, the calculator would align the LUNs so that there were always 7 SGs per LUN when performing weekly full backups.  With the change to the LUN Architecture to group the storage groups together appropriately, the backup architecture was also updated to reflect the correct backup sets.

I/O Calculation Changes

1. Further analysis of production environments has yielded more information with regards to the transaction log write I/Os.  Previously, we had stated that the transaction log write to database write ratio was 1:2 (meaning that there are twice as many database writes as there are log writes).  Production data has shown us that the ratio is between 1:2 and 1:1.  As a result we have changed the log write to database write ratio to 3:4 (meaning that for every single database write, there is a 3/4 write to the log stream).  The effect is here is essentially that we foresee more transaction log write I/Os.
2. Previous versions of the calculator had you select the database read:write ratio; however since we are predicting the IOPS per mailbox via a formula, we can also predict the database read:write ratio for those mailboxes.  So in this version we determine the database read:write ratio based on the message profile, database cache / mailbox, and the Outlook mode usage.  In the case where you do not want to use the IOPS / mailbox prediction formula, you can still specify the database read:write ratio per mailbox tier.

    

SCR & Log Capacity Calculation Changes

In the last version (v9.6) we added in Standby Continuous Replication (SCR), but calculations were not complete as we didn't cover log replay delay.  SCR has a feature that allows you to delay transaction logs from being replayed into the database to reduce the likelihood of having to perform a database reseed.  The log replay feature is configurable and can be set from 0 days (disabled) up to 7 days (note: if you set log replay to 0 days, we will still keep 50 logs from being replayed).  This feature affects capacity - the longer the replay delay, the more capacity you may need.  So as a result, we had to change the "Log Disk Space Required - Backups" calculation:

The original calculation went like this:

Log Disk Space Required - Backups = NumTLogs x factor

Where factor is

• If performing daily differential backups, factor = 7
• If restore LUN = yes, factor = BackupFailureTolerance (default value of 2)
  • If restore LUN =no and performing daily incremental backups, factor =7
  • If restore LUN=no and performing daily full backups, facto r= BackupFailureTolerance

     

Which presented a few problems:

• If doing daily differentials you are at capacity when you fail the full backup, which means you either take an emergency backup or you go down (i.e. there is no capacity to wait for backupfailuretolerance).
• This doesn't account for SCR Log Replay (max value here is 7 days).

   

The new formula for calculating "Log Disk Space Required - Backups" is:

= [If SCRReplayDelay = Disabled and SCRTargets<>0 then 50 + NumTLogs, otherwise just NumTLogs] x factor

Where factor is

• If performing daily differential backups, factor  = 7*BackupFailureTolerance
• If restore LUN = yes, factor = [If SCRTargets<>0 and SCRLogReplay<>Disabled, MAX(SCRLogReplay,BackupFailureTolerance) otherwise just BackupFailureTolerance]
  • If restore LUN =no and performing daily incremental backups, factor = MAX(7,BackupFailureTolerance)
  • If restore LUN=no and performing daily full backups, factor = [If SCRTargets<>0 and SCRLogReplay<>Disabled, MAX(SCRLogReplay,BackupFailureTolerance) otherwise just BackupFailureTolerance]

     

Log Generation Updates

• In previous versions of the calculator we only reported log generation (per server and per storage group) based on the message profiles and mailbox tiers.  We were not reporting transaction logs generated by mailbox moves.  To fix this, the following was added to this version of the calculator:
• As an input parameter, you still enter in the percentage of mailbox moves per week.
• From a "Log Disk Space Required - Mailbox Moves" capacity perspective, we are still calculating the worst case where all mailbox moves are performed on the same day (equally across all storage groups).  This ensures there is enough capacity if you do move all the mailboxes on a single day.
• In this release, we've added a metric that breaks down the average number of transaction logs generated for mailbox moves / day (per server and per storage group) measurements.  This metric assumes that a percentage of mailbox moves happens each day on each SG.  The worst case is that you do move all the mailboxes in a single day, in which case, this number doesn't mean anything since it averages out the entire mailbox move percentage across seven days.  This metric will also be used by the upcoming Data Protection Manager 2007 Calculator.
• We have also adjusted where "data overhead factor" is used so that it is seen in the "user transaction log generation" and "move mailbox transaction log generation" numbers as opposed to being factored into the capacity number outcome.  The outcome is still the same as in previous versions, it's just better to explain the overhead in terms of logs generated vs. capacity.

   

Special Notes

We have added two special notes into the results section based on input parameters and the outcome of the design.

1. Important: The calculator recommends a LUN size greater than 2TB.  In order to implement this size you have two options.  The preferred method is to reduce the number of mailboxes, reduce the size of the database, or decrease the mailbox size to ensure that you are below the 2TB MBR partition limit.  The second option is to utilize GPT partitions which do not have a 2TB limit; however if you are clustering, Windows Server 2003 Failover Clustering does not support GPT disks.  For more information on partition best practices with Exchange 2007, please see http://technet.microsoft.com/en-us/library/bb124518.aspx.

    

2. Important: The Log Replication Throughput metrics for both Geographically Dispersed CCR and/or SCR are dependent upon knowing the proper log generation rate per hour of the day for your environment.  If this data is unknown, then the log replication throughput metrics may not be accurate.

    

UPDATE ON 8/10/2007:

Version 9.6 corrects a bug where the Tier-2 Mailbox Class I/O requirements were not included in the database peak IOPS calculation.

UPDATE ON 7/9/2007:

Version 9.4 which adds an additional results table to the Storage Requirements tab that breaks down the number of tiered mailboxes per database.  We hope this usability improvement helps.

UPDATE on 7/5/2007:

In this release, we have redesigned the look of the calculator, fixed some bugs, and as always, added new functionality based on customer feedback.

New Look

• We split the calculator up into more worksheets.    Now all input is entered into a single worksheet and the requirements are outlined in separate worksheets.
• The input worksheet is now broken out into steps that provide instructions on how to enter the data.

Bug Fixes

• Message Size is now taken into account when determining the log generation rate per mailbox.
• We now clearly show what the LUN requirements are by separating out the data overhead and LUN capacity figures for both databases and transaction logs.
• We made several formatting changes within the tables that should make it easier to understand the results.
• We corrected the calculation of LUN free space percentage so that it actually ensured the correct percentage of free space would be available.

New Functionality

• We have added multiple mailbox profiles to the calculator.  Now customers can design single servers that can house multiple mailbox tiers (different send/receive limits, different mailbox sizes, different I/O profiles, etc).  However, I should point out for simplicity, the calculator will not segregate out the mailbox tiers into their own storage groups; instead we distribute the mailbox tiers across all databases.
• We have added the capability for you to enter a custom maximum database size.  Before the calculator used a maximum database size of 100GB for non-continuous replication scenarios, and 200GB for continuous replication scenarios.  Many customers sent me notes asking for customization around this because they wanted smaller database sizes.   Well you can do it.  By default the calculator will still use the 100GB/200GB sizing, but you can turn that off and enter your own value.
• We have updated the calculator to include Exchange 2007 SP1 Standby Continuous Replication functionality.  Now you can select how many targets (up to 4) you would like to have.
• We have added the capability for you to determine how much throughput you need for log replication when deploying geographically dispersed Cluster Continuous Replication or the Exchange 2007 SP1 Standby Continuous Replication functionality.
• Message Size is now taken into account when determining the log generation rate per mailbox.

Older calculator versions update announcements can be found here and here.

- Ross Smith IV