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 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 server’s 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

Share this post :