Updates to the Exchange 2010 Server Role Requirements Calculator

Important: The results of the Exchange 2010 calculator are not applicable to Exchange 2013. For instance, the megacycle calculations in Exchange 2010 leverage a different server baseline than those in Exchange 2013, therefore, the two calculations cannot be compared.

Version 20.9 Updates

Bug Fixes

Additional fixes on CAS/HT CPU calculations formulas

Disabled Distribution tab for Active/Active Single DAG model

Added Distribution tab warning that only one of the two DAGs is shown

Fixed RAID disk calculation for A/A scenario and lagged copies

Version 20.8 Updates

Bug Fixes

Fixed an error with secondary CAS CPU calculations

Version 20.7 Updates

Bug Fixes

Fixed CAS and HT memory calculations formulas to not report #NAME when designing site resilient topologies.

Version 18.9 Updates

Bug Fixes

Fixed the Storage worksheet’s "RAID Storage Configuration" Table to exclude showing "Total Number of Disks Required" for designs that do not have lagged database copies and are deploying in a JBOD configuration.

Added a notification to Role Requirements regarding scenarios that result in >2TB databases.

Fixed an error notification to indicate when the input parameters have resulted in a design that has more HA copies than available Mailbox servers.

Fixed the DAG LUN total space calculation to be based on the total number of database copies, not the total number of mailbox servers.

Fixed the database copy validation formula to ensure there is at least 1 HA copy or lagged database copy in the secondary datacenter when site resilience is enabled.

Fixed servers.csv to not add a space between the comma and drive letter.

Fixed cells to have the correct color formatting.

Updated BDM throughput requirements to stipulate 7.5MB/s per database as the worst case, which aligns with what can potentially be seen in Jetstress runs.

Version 18.2 Updates

Bug Fixes

Fixed the calculator’s database copy validation check function to allow for a single DAG to be stretched between datacenters when the database copy count is even.

Fixed the “Storage Design Results Pane - Total Disks Required” when leveraging the “As Calculated” results to not highlight RAID disks for a datacenter’s server when JBOD was the appropriate choice in the “RAID Storage Configuration” choice. Likewise, the “JBOD Storage Configuration” table’s calculations were also fixed to not highlight the use of JBOD disks for a datacenter’s server when RAID was the appropriate choice.

Fixed an erroneous alert on the Input worksheet regarding not having enough IO capability for JBOD due to isolating logs from databases.

Fixed the calculated maximum database size for JBOD scenarios to allow for 2TB databases when >2.5TB disk sizes are selected.

Version 17.8 Updates

Bug Fixes

Fixed the “Recommended databases per DAG” calculation formula to take into account symmetrical design multiples when the “Calculated Number of Databases for Symmetrical Distribution” is greater than the maximum of databases that can be deployed within the DAG.

Fixed the validation check for when you select more database copies than available servers. As a result, when this scenario is presented, the calculator will no longer provide results.

Fixed "Calculated Number of Supported Databases / DAG" formula to round down to nearest whole number.

Fixed distribution calculation to allow more copies and servers.

Fixed "RAID Storage Architecture / SDC Server" to show the optimal RAID configuration for the SDC servers as opposed to the PDC servers.

Fixed formula issue for number of databases in the environment for standalone scenarios.

Enhancements

Added RAID-6 types 4+2 and 8+2.

Added 10, 20, and 40 processor core options.

Added 3TB disk capacity.

Script changes:

Removed option to remove first database

Revised Diskpart script to format using 64K unit size

Version 17.2 Updates

Bug Fixes

Database Copy Distribution fixes:

Prevented distribution calculation when Input sheet values are invalid; added row in header for counters for databases assigned to a server.

The calculator now includes support for virtualization. When you enable virtualization, you must be sure to configure the processor architecture correctly.

In particular, you must enter in the correct number of processor cores that the guest machine will support, as well as, the correct SPECInt2006 rating for these virtual processor cores. To calculate the SPECInt2006 rate value, you can utilize the following formula:

X/(N*Y) = per virtual processor SPECInt2006 Rate value

Where X is the SPECInt2006 rate value for the hypervisor host server Where N = the number of physical cores in the hypervisor host Where Y = 1 if you will be deploying 1:1 virtual processor-to-physical processor on the hypervisor host Where Y = 2 if you will be deploying up to 2:1 virtual processor-to-physical processor on the hypervisor host

For example, let’s say I am deploying an HP ProLiant DL580 G7 (2.27 GHz, Intel Xeon X7560) system which includes four sockets, each containing an 8-core processor, then the SPECInt2006 rate value for the system is 757.

If I am deploying my Mailbox server role as a guest machine using Hyper-V, and following best practices where I do not oversubscribed the number of virtual CPUs to physical processors, then

757/(32*1) = 23.66

Since each Mailbox server will have a maximum of 4 virtual processors, this means the SPECInt2006 rate value I would enter into the calculator would be 23.66*4 = 95.

In addition, you must ensure that you enter the correct Hypervisor CPU Adjustment Factor to account for the CPU overhead associated guest machines. Work with your hypervisor vendor to determine the correct value.

New Functionality – Database Copy Distribution

In September I released our guidance on how to lay out database copies to ensure symmetrical distribution of the active copies in the event of a failure. This guidance was further expanded and released as a TechNet article in November.

On the Input worksheet, within the Database Configuration table, you can now have a new option, “Calculate Number of Unique Databases / DAG for Symmetrical Distribution”. When this option is enabled, the calculator will use the permutation formula discussed in our guidance to deploy the correct number of databases based on the number of copies and server architecture such that you can potentially achieve a symmetrical distribution after a failure event.

The calculator includes a new worksheet, Distribution. Within the Distribution worksheet, you will find the layout we recommend based on the database copy layout principles.

The Distribution worksheet includes several new options to help you with designing and deploying your database copies:

You can determine what the active copy distribution will be like as server failures occur within your environment.

You can export a set of CSV and PowerShell scripts that perform the following actions:

Diskpart.ps1 (uses Servers.csv) - Formats the physical disks, and mounts them as mount points under an anchor directory on each server.

Important: The database copy layout the tool provides assumes that each server and its associated database copies are isolated from each other server/copies. It is important to take into account failure domain aspects when planning your database copy layout architecture so that you can avoid having multiple copy failures for the same database.

Version 14.4 Updates

Bug Fixes

Fixed stretched DAG scenario that had one database copy in each datacenter not reporting results due to new copy validation check

Fixed "Number of Required Mailbox Processor Cores (Primary Datacenter)" formula to respect when site resilience is disabled and A/A (Single DAG) is selected.

Fixed formatting for scenario that resulted in more HA database copies being deployed in the secondary datacenter than in the primary datacenter and also improved validation checks.

Updated "Custom Number of Databases" (Input Section) and "Number of Databases" (Role Requirements section) text to indicate in standalone situations that the "Custom Number of Databases" is per server and "Number of Databases" is for the environment.

Fixed Number of Active Mailbox Servers in DC2 calculation to not double count lagged copies when deploying Active/Active (Single DAG) scenario and deploying lagged copy in both Primary and Secondary Datacenters

Fixed second DAG Member Layout Table to show number of servers for both Active/Active scenarios

Version 12.3 Updates

Bug Fixes

Fixed Total Number of Databases / Server calculation to deal with scenario where lagged copies are deployed in both datacenters for Active/Active (Single DAG) scenario

Version 12.1 Updates

Bug Fixes

Optimized Number of Active Databases after First PDC Server Formula removing redundant bad code and enabling single database scenario.

Fixed Number of Required Mailbox Processor Cores for both PDC and SDC calculations to take into account the situation where the required megacycles to support the active load is less than the number of megacycles per core.

Optimized Number of Required Mailbox Processor Cores for both PDC and SDC calculations to not assume all required cores would be 100% utilized by changing how rounding works in the formula.

The calculator no longer requires you to enter in the adjusted megacycles per core for the server architecture you are deploying. Instead, you simply need to obtain the SPECint2006 Rate Value for your server platform. To determine your SPECint 2006 Rate Value:

Find the server and processor you are planning to deploy and take note of the result value. For example, let's say you are deploying a Dell PowerEdge M710 8-core server with Intel x5550 2.67GHz processors (2670 Hertz); the SPECint_rate2006 results value is 240.

Added Megacycle Multiplication Factor - this works exactly like the IOPS Multiplication Feature does and was added as a result of RIM providing E2010 guidance on megacycle impact due to Blackberry devices.

Active/Active user distribution scenarios. Yes, really! An Active/Active user distribution architecture has the user population dispersed across both datacenters (usually evenly) with each datacenter being the primary datacenter for its specific user population. In the event of a failure, the user population can be activated in the secondary datacenter (either via cross-datacenter single database *over or via full datacenter activation).

Added a new worksheet/section that documents the Activation Scenarios for DAG deployments.

Added error reporting validation logic if HA solution results in greater than 16 servers in a DAG to not show any results, since the design is invalid.

Dumpster size calculations have been optimized as calendar versioning storage has been reduced from 5.8% impact to 3% impact in SP1.

The calculator offers two types of Active/Active user distribution models:

Active/Active (Single DAG) - This model stretches a DAG across the two datacenters and has active mailboxes located in each datacenter. A corresponding passive copy is located in the alternate datacenter. This scenario does have a single point of failure (potentially), the WAN connection. Loss of the WAN connection will result in the mailbox servers in one of the datacenters going into a failed state from a failover cluster perspective (due to loss of quorum). The Active/Active (Single DAG) scenario supports two deployment types, deploying with dedicated DR Mailbox servers in the alternate datacenter, or using the Active Mailbox Servers as the disaster recovery servers in the event that a datacenter is lost.

---DC1---

---DC2---

DAG1

DAG1

Active Copies

Passive Copies

Passive Copies

Active Copies

In other words:

Active/Active (Multiple DAGs) - This model leverages multiple DAGs to remove single points of failure (e.g., the WAN). In this model, there are least two DAGs, with each DAG having its active copies in the alternate datacenter:

Version 7.7 Updates

Bug Fixes

Fixed an issue in site resilient designs where the number of HA copies between datacenters was asymmetrical that resulted in a condition where the number of activated copies after a server failure was less than the number of copies during normal runtime.

Fixed an issue to prevent a situation where the number of activated database copies per server in the primary datacenter was greater than the total number of copies per server.

Improved the calculations for the number of required servers in the secondary datacenter, as well as, the number of lagged copy servers by rounding up, as opposed to simply rounding.

Improved the number of active database calculations for 2-member DAGs deployed in a site resilient configuration.

Improved the cross-site database failover calculations during double server failure events in the primary datacenter (where a portion of the databases are activated in the secondary datacenter).

Fixed the Number of Required Mailbox Processor Cores (Secondary Datacenter) calculation to only consider solutions that have HA copies in the secondary Datacenter.

Fixed and improved various comments throughout the calculator.

Enhancements

Added two new columns to the primary datacenter "Active Database Configuration / DAG" table. These columns now expose the total number of databases activated in each site after server failure events. This change was added to expose cross-site database failover events.

The calculator now includes an option to activation block secondary datacenter mailbox servers that host HA database copies. This allows you to design a solution where you can activate the secondary datacenter in the event of a primary datacenter failure mode, or choose to activate a copy in the secondary datacenter manually, but prohibits Active Manager from automatically activating a copy in the secondary datacenter. This may be useful in certain environments where WAN costs are high, or utilization of the WAN is high, and thus you want to control when users access data from the secondary datacenter. From a server planning perspective, enabling cross-site database failover has the potential to impact the primary datacenter server design (e.g., can increase the design to support double server failure events, which can impact memory and CPU sizing), while disabling cross-site database failover, can potentially increase your outage scenarios, but allows you to control the situation better.

Over the years, many requests have come in asking to increase the number of mailbox tiers in the calculator. Well finally we did something about it. In this version, we've added a fourth mailbox tier.

Added support for 32-cores.

Originally, the IOPS Multiplication Factor calculations worked as follows:

Base IOPS + (Base IOPS * IOPS Multiplication Factor

This was often times confusing, especially with regards to third-party applications that had multiplication factors, so we've simplified the formula as follows:

(Base IOPS * IOPS Multiplication Factor)

which means that if previously you entered in a value of say .5 as the multiplication factor, you now need to enter into the calculator a value of 1.5.

Version 6.3 Updates

Bug Fixes

Fixed the Secondary datacenter Active and Passive megacycle calculations to take into account the number of activated databases based on the failure mode the secondary datacenter can support.

Fixed the number of Active Databases / Secondary Datacenter Server after a first primary datacenter server failure to not display #VALUE for 2-node site resilient DAG solutions.

Improved the number of Active Databases after double server failure in the primary datacenter site resilient calculation to deal with 3 servers in the primary datacenters, as well as, when there are 2 copies in the primary datacenter.

Version 6.1 Updates

New Functionality

Previous versions of the calculator would sometimes result in a storage design output that required zero disks. This was due to the calculator determining based on the input factors (e.g. deploying a DAG with 3 HA copies in the primary datacenter) that a JBOD architecture would minimize the required number of disks. However, if the disk capacity and/or disk type did not meet the requirements to host a database, the calculator would output zero disks. As seen in the following example, notice only the disk requirements for the secondary datacenter are reported in the Total Disk Requirements table:

In order to rectify this logic issue, the calculator has been updated to allow you to choose the storage design you are interested in deploying. The calculator still shows you both the RAID architecture and JBOD architecture disk requirements:

What is new, however, is that within the Total Disk Requirements results pane, you now will have three options:

As Calculated - this is the default behavior where the calculator determines the most efficient design that ensures the least number of disks are deployed, while still ensuring you have minimized single points of failure by utilizing RAID and/or JBOD based on the decisions found in the "RAID Storage Architecture" and "JBOD Storage Architecture" tables.

Entirely on RAID - Selecting this option outputs the results with each server utilizing the RAID storage defined in the RAID Storage Architecture results section.

Entirely on JBOD - Selecting this option outputs the results with each server utilizing JBOD storage as defined in the JBOD Storage Architecture. There are two caveats worth mentioning here - first, if the design doesn't support JBOD, then JBOD isn't a viable option (e.g., you don't have 3 HA copies); second, choosing this option may result in a situation where you have a single point of failure (e.g., having only a single copy on JBOD in the secondary datacenter). Remember the following conditions when considering JBOD:

In order to deploy on JBOD in the primary datacenter servers: You need a total of 3 or more HA copies within the DAG. If you are mixing lagged copies on the same server that is hosting your HA copies (i.e. not using dedicated lagged copy servers), then you need at least 2 lagged copies.

For the secondary datacenter servers to use JBOD: You should have at least 2 HA copies in secondary datacenter. That way loss of a copy in the secondary datacenter doesn't result in requiring a reseed across the WAN or loss of data (in the datacenter activation case). If you are mixing lagged copies on the same server that is hosting your HA copies (i.e., not using dedicated lagged copy servers), then you need at least 2 lagged copies.

For dedicated lagged copy servers: You should have at least 2 lagged copies within a datacenter in order to use JBOD. Otherwise loss of disk results in loss of your lagged copy (and whatever protection mechanism that was providing).

In addition to the new functionality described above, this version also provides the following enhancements to existing behavior, as well as, corrects several issues reported:

Enhancements

Message profiles have been simplified in order to be more consistent with the rest of our documentation and partner tools. For example, instead of using "20 sent/80 received", the calculator now simply uses "100 messages". The individual breakdown isn't consequential to the overall design of the mailbox server IO and capacity planning algorithms.

Added additional column to the "Active Database Configuration / DAG" table on the Role Requirements tab to expose configurations where you will have a portion of your databases activated in the secondary datacenter as a result of a failure event in the primary datacenter.

Improved "Environment Configuration" table on the Role Requirements tab to indicate the Number of Mailbox Servers and Lagged Copy Servers / DAG in each datacenter.

Re-ordered tables in the Role Requirements Results section.

Bug Fixes

Fixed an issue for site resilience scenarios that resulted in #DIV/0 errors as a result of determining the number of copies that can be mounted in the event of a double server failure when the solution only has 2 servers in the primary datacenter.

Fixed an issue for site resilience scenarios that ensures that double failure events don't result in more databases being activated on the remaining primary datacenter servers than possible when only 2 copies exist in the primary datacenter.

Fixed CPU core calculations to take into account the total number of DAGs being deployed in the situation.

For HA solutions that chose to deploy in JBOD configuration, two fixes were made:

In certain scenarios, the calculator would calculate the number of mailboxes per database to be higher than the total amount of random IO available on the disk. As a result the calculator couldn't recommend a JBOD configuration. This has been corrected by rounding down the number of mailboxes per disk from an IO perspective calculation.

In certain situations the JBOD disk configuration isn't applicable. In past versions, the calculator would simply tell you this was because of "Insufficient Disk Capacity". This has been corrected to tell you if the insufficiency is based on disk capacity or IO capacity.

Addressed several CPU calculation related errors:

Fixed the issue where #VALUE was reported in the secondary datacenter processor core ratio table when you deployed only a lagged copy in the secondary datacenter.

Fixed the required mailbox CPU calculations to take into account certain site resilient scenarios where neither datacenter could support a single server failure (e.g. 2 member DAG).

Fixed an issue with the total disk count calculations with dedicated lagged copy servers as a result of rounding error.

Fixed an issue where /DAG LUN space totals didn't take into account the 2 LUNs / Backup Set architecture.

Version 3.5 Updates

Version 3.5 introduces the following fixes:

Improved the text on the input tab with regards to the number of database copy instances you would like for both HA and lagged copies.

Fixes an issue where in a high availability architecture the calculator may size the solution based on activating more database copies during a second server failure event than the total number of database copies deployed on the server.

Version 3.4 Updates

Version 3.4 corrects a memory and CPU utilization issue where you deploy a site resilient architecture with multiple mailbox servers and a single database copy in the primary datacenter. Specifically, the calculator would determine the active database copy configuration after a single server failure and then size the CPU and memory requirements. However, since there is only a single database copy in the primary datacenter, the solution cannot survive with all copies hosted in the primary datacenter. Therefore, the copies need to be activated in the secondary datacenter. Version 3.4 corrects this scenario by ensuring there are at least 2 database copies in the primary datacenter in order to calculate the active database count after a single server failure.

Version 3.2 Updates

It's been a while since we discussed the Exchange 2010 Mailbox Server Role Requirements Calculator. Well I am pleased to say that today we are launching version 3.2 of the calculator.

And for those that I know will ask, this version of the calculator does not include the Active/Active user distribution site resiliency scenario. For those that need that scenario, what I recommend is the following:

Launch two versions of the calculator.

Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 1 is lost.

Populate the second version for the second DAG in your design. This DAG (DAG2) will utilize Datacenter 2 as its primary location (and thus its user population is based out of Datacenter 2). It has site resiliency by having servers and database copies located in Datacenter 1 that can be activated in the event Datacenter 2 is lost.

Datacenter 1

Datacenter 2

DAG1

Active

Passive

DAG2

Passive

Active

By implementing the architecture in this way, you can ensure that for the majority of scenarios except loss of datacenter, the users remain operational in their primary datacenter location.

Conclusion

Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.

For the explanation of different tabs and how the calculator works, go here. Yup, we updated that too!

There’s a small error in the description. In the active/active paragraph, the second bullet reads:

* Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 2 is lost.

In a site resiliency deployment (active/passive, two servers in each site, total HA copy instances of 4) if the inputs for number of servers hosting active mailboxes/dag = 2 and number of HA database copy instances deployed in secondary datacenter = 2, the Role Requirements page returns a number of divide by zero errors. It does not seem to affect other dual-site configurations with other numbers filled in for these two values.

Odd, when I specify that I have 3 servers in my single site, it tells me to set MaximumActiveDatabases to let’s say 30 and that I could support 1 server failure. But if I then specify I have a second site, suddenly my main site allows me to support up to 2 failures in just my primary site and then my MaximumActiveDatabases shoots up to support all of my databases (let’s say 3). Not sure why that happened and seems like a bug.

Maybe in the future we can say how many server failures we’d like to account for in each datacenter.

Folks, I wanted to let you know of an issue in the v4.5 calc – if you are designing configurations to support multiple DAGs, there is an issue in the reporting of the number of processor cores you need for the various roles. basically the calculator is making an assumption of only having a single DAG in the environment. So you will need to multiply the processor cores per role by the number of DAGs you are deploying to see the full number of cores required. This will be fixed in the next release.

I’m actually improving the reporting of this in the next release. Essentially when you move to a multi-site architecture, you support the ability to have cross-site *over events. So you could survive two server failures (in certain situations within the primary datacenter) because some of the databases can be activated in the secondary site.

I see the issue is still there. Let me go through an example with the default tier settings (24,000 mailboxes):

Single Site – 3 mailbox servers (modified from default of 3) and 3 copies.

Calculator Results:

Normal Run Time – 33 databases

After first server failure – 50 databases

MaximumActivedatabases set to 50

Now let’s turn on Site Resilience. I also increased total number of HA copies to 4 and set the Site Resilient Copies to 1. I was offered 2 for Site Resilient Copies which doesn’t make much sense since I set the mailbox servers in the Primary Datacenter to 3 and total copies to 4. 4-3 is 1 so why did it offer 2 for Site Resilient Copies?

Anyways, I now see that I can support 2 server failures but it tells me that my new maximumactivedatabases is 99? This doesn’t make sense even with automatic *over to a DAG member in another site. It should still be 50 in my eyes. Before, if 1 server failed, 2 servers would pick up the whole slack and your maximumactivedatabases was 50. Now we’re adding a 4th server and if 2 servers go down, you still have 2 servers like before picking up all the slack. Maximumactivedatabases should still be 50.

"Now let’s turn on Site Resilience. I also increased total number of HA copies to 4 and set the Site Resilient Copies to 1. I was offered 2 for Site Resilient Copies which doesn’t make much sense since I set the mailbox servers in the Primary Datacenter to 3 and total copies to 4. 4-3 is 1 so why did it offer 2 for Site Resilient Copies? "

The second issue is a bug.

Ross

I’m not sure why you think you can’t have 2 copies in the primary datacenter with 3 mailbox servers and 2 copies in the secondary datacenter. The number of mailbox servers in the primary datacenter only dictates the maximum number of copies you can have there – so with 3 servers you can have a maximum of 3 copies, but you could also deploy 2 copies.

I am trying to use the Sizer with archiving option. Trying to put the archive size in the Input tab translated into many copies according to the number of members in DAG. Can I keep one copy of archived exchange 2010 data?