Partager via

Exchange 2010 Mailbox Role Calc Released - Grab a coffee and start reading...

  • Article

Overview



  • User profile - the message profile, the mailbox size, and the number of users
  • High availability architecture - the number of database copies you plant to deploy, whether the solution will be site resilient, the desired number of mailbox servers
  • Server's CPU platform
  • Storage architecture - the disk capacity / type and storage solution
  • Backup architecture - whether to use hardware or software VSS and the frequency of the backups, or leverage the Exchange native data protection features
  • Network architecture - the utilization, throughput, and latency aspects



  • Input
  • Role Requirements
  • LUN Requirements
  • Backup Requirements
  • Log Replication Requirements
  • Storage Design


Input



Environment Configuration





  1. Do these servers only have the mailbox server role installed? Having the Hub Transport and Client Access server roles also installed on the along with the mailbox server role affects your design in the areas of load balancing client requests, memory utilization, and CPU utilization.
  2. Are you deploying a database availability group (DAG)? Deploying the solution as DAG provides you additional flexibility and resiliency choices like having multiple mailbox database copies, leveraging flexible mailbox protection features in lieu of traditional backups, and flexibility in your storage architecture (e.g. RAID or JBOD).
  3. Are you deploying the DAG in a site resilient configuration? A DAG can be stretched across 2 or more datacenters (the calculator only allows for 1 datacenter) without requiring the AD site or network subnet to be stretched.
  4. What user distribution model will you be leveraging in your site resilient architecture? When planning a site resilience model with Exchange 2010, keep in mind there are two variables that need to be considered: namespace model and user distribution model. For the namespace or datacenter model, Exchange 2010 requires both datacenters to be in an Active/Active configuration. This means that both datacenters participating in the DAG solution must have active, reachable namespaces and have the ability to support active load at any time. For the user distribution model, the design can support both Active/Passive and Active/Active user distribution. At this time, the calculator only supports and Active/Passive user distribution model. An Active/Passive user distribution architecture simply has database copies deployed in the secondary datacenter, but no active mailboxes are hosted there and no database copies will be activated there during normal runtime operations. However, the datacenter supports both single cross-datacenter database *overs, and full datacenter activation.
  5. In your site resilient architecture, how far behind can you get in terms of log shipping between datacenters? The effect of the RPO is to evaluate the non-contiguous peak hours (defined in Step 5), say 8am and 4pm, and determine the resulting throughput requirement, assuming that you can take the time in between 8 and 4 to catch up (within the specified RPO, of course). By allowing replication to get behind there are two outcomes: 1. Active Manager is less likely to choose a database copy that has a high copy queue length (unless more viable alternatives aren't available). 2. If the copy queue length is greater than the target server's AutoDatabaseMountDial setting, the database will not automatically mount once activated. Manually mounting that database will result in the loss of data that had not been copied.
  6. How many mailbox servers are you going to deploy within the primary datacenter? If you enter more than a single server (remember a DAG requires at least two and can support a maximum of 16), the calculator will evenly distribute the user mailboxes across the total number of mailbox servers and make performance and capacity recommendations for each server, as well as, for the entire environment. As for the secondary datacenter, the calculator will determine the number of mailbox servers you need to deploy there based on the requirements (number of databases, number of copies, etc).
  7. How many DAGs are you planning to deploy in the environment? If you enter more than a single DAG, then the calculator will distribute the user mailboxes across the total number of DAGs and make performance and capacity recommendations for each server and each DAG, as well as, for the entire environment.


  1. How many mailbox database copies do you plan to deploy within a DAG? Enter in the number of highly available database copies you plan to have within the environment. This value excludes lagged database copies. For optimal sizing, choose a multiple of the total number of mailbox servers you have selected.
  2. How many lagged database copies do you plan to deploy within a DAG? Lagged database copies are an optional feature that can provide protection against certain disaster scenarios (like logical corruption). Lagged database copies should not be considered an HA database copy as the replay will delay the availability of the database for use once activated. While technically there is no limit to how many lagged copies you can deploy within a DAG, the calculator limits you to a maximum of 2 copies.
  3. How many mailbox database copies do you plan to deploy within the secondary datacenter? If you are deploying a site resilient solution, you can choose to a portion of the total HA database copies deployed in the secondary datacenter.
  4. How many lagged database copies do you plan to deploy within the secondary datacenter? If you are deploying a site resilient solution, you can choose to have a portion or all of your lagged database copies deployed in the secondary datacenter.


  1. Will you deploy the lagged database copies on a dedicated server? Using a dedicated server for lagged database copies certainly makes it easier to manage. For DAGs where the lagged database copies are evenly distributed across all the DAG mailbox servers, you will need to use the Suspend-MailboxDatabaseCopy with the -ActivationOnly flag to prevent them from being mounted, but there are scenarios that can clear this. With a dedicated server you can activation block the entire server and the setting is persistent. The choice can also affect your storage design in terms of choosing RAID or JBOD. Unless you have multiple lagged copies, lagged copies should be placed on storage that is utilizing RAID to provide additional protection. The calculator will determine the appropriate number of lagged copy servers you need to deploy based on the requirements (number of databases, number of copies, etc).
  2. How long will you delay transaction log replay on your lagged copy? This parameter is used to specify the amount of time that the Microsoft Exchange Information Store service should wait before replaying log files that have been copied to the lagged database. The maximum amount of replay delay you can set is 14 days. The value you specify here will influence the log capacity requirements for all copies and the amount of time required to mount a lagged copy.
  3. How long will you delay transaction log truncation on your lagged copy? This parameter is used to specify the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have been copied to the lagged database. The time period begins after the log has been successfully replayed into the lagged copy. The maximum allowable setting for this value is 14 days. The minimum allowable setting is 0, although setting this value to 0 effectively eliminates any delay in log truncation activity. The value you specify here will influence the log capacity requirements for all copies.


  1. What will be the Data Overhead Factor? Microsoft recommends using 20% to account for any extraneous growth that may occur.
  2. How many mailboxes do you move per week? In terms of transactions, you have to take into account how many mailboxes you will either be moving to this server or within this server, as transactions totaling the size of the mailbox will always get generated at the target database.
  3. Are you going to deploy a Dedicated Restore LUN? A dedicated restore LUN is used as a staging point for the restoration of data or could be used during maintenance activities; if one is selected then additional capacity will not be factored into each database LUN.
  4. What percentage of disk space do you want to ensure remains free on the LUN? Most operations management programs have capacity thresholds that alert when a LUN is more than 80% utilized. This value allows you to ensure that each LUN has a certain percentage of disk space available so that the LUN is not designed and implemented at maximum capacity.
  5. Do you have log shipping compression enabled within the DAG? By default, each DAG is configured to compress and encrypt the socket connection used to ship logs across different IP subnets (you can disable these features all together or enable them for all communications regardless of subnet).
  6. What is your compression rate? The compression capability that is obtained for the socket connection used to ship logs will vary with each customer, based on the data obtained in the transaction log files. By default, Microsoft recommends using a value of 30%, however, you can determine this value by analyzing your environment (e.g., once Exchange 2010 is deployed you could evaluate the throughput rate with compression disabled and then compare with compression is enabled) .


  1. What will be the I/O Overhead Factor? Microsoft recommends using 20% to ensure adequate headroom in terms of I/O to allow for abnormal spikes in I/O that may occur from to time.
  2. What additional I/O requirements do you need to factor into the solution for each mailbox server's storage design? For example, let's say the solution requires 500 IOPS for the mailboxes and you have decided you want to ensure there is extra I/O capacity to support additional products (e.g. antivirus) to generate load during the peak user usage window. So you enter 300 IOPS in this input factor. The result is that from a host perspective, the solution needs to achieve 800 IOPS. This may require additional testing by comparing a baseline system against a system that has the I/O generating application installed and running.


  1. Do you want to follow Microsoft's recommendations regarding maximum database size? For standalone mailbox server role solutions, Microsoft recommends that the database size should not be more than 200GB in size. For solutions leveraging mailbox resiliency, Microsoft recommends that the database size should to exceed 2TB. Neither of these is by any means a hard limit, but a recommendation based on the impact database size has to recovery times. If you want to follow Microsoft's recommendation, then select Yes. Otherwise, select No.
  2. Do you want to specify a custom Maximum Database Size? If you selected No for the previous field, then you need to enter in a custom maximum database size.


  1. How many processor cores and what is their megacycle capability are you planning to deploy in each server? For each server type (primary datacenter, secondary datacenter, and lagged copy server) you plan to deploy, select the number of processor cores and the core's corresponding megacycles. For example, the Intel Xeon x5470 3.33GHZ processors (2x4 core arrangement) can deliver 3300 MCycles of performance throughput. Other processor configurations can be estimated by comparing this measured platform to server platforms tested by www.spec.org (SPEC CPU2006 Results).

Mailbox Configuration



  1. How many mailboxes will you deploy in the environment? If deploying a single server environment, this is how many mailboxes you will deploy on this server. If you are deploying multiple servers, then this is how many mailboxes you will deploy in the environment. If you are deploying multiple DAGs, then this is how many mailboxes you will deploy across all of the DAGs. For example, if you choose to deploy 5 servers, and want 3000 mailboxes per server, then enter 15000 here. Or if you plan to deploy 2 DAGs, each with 6 servers, and you entered 24000 total mailboxes, then 12000 mailboxes will be deployed per DAG.
  2. What is the solution's projected growth in terms of number of mailboxes over its lifecycle? Enter in the total percentage by which you believe the number of mailboxes will grow during the solution's lifecycle. For example, if you believe the solution will increase by 30% over the lifecycle of the design and you are starting out with 1000 mailboxes, then at the end of the lifecycle, the solution will have 1300 mailboxes. The calculator will utilize the projected growth plus the number of mailboxes to ensure that the capacity and performance requirements can be sustained throughout the solution's lifecycle.
  3. How much mail do the users send and receive per day on average? The usage profiles found here are based on the work done around the memory and processor scalability requirements.
  4. What is the average message size? For most customers the average message size is around 75KB.
  5. What will be the prohibit send & receive mailbox size limit? If you want to adequately control your capacity requirements, you need to set a hard mailbox size limit (prohibit send and receive) for the majority of your users.
  6. If deploying a personal archive mailbox, what will be the personal archive quota limit? If you want to adequately control your capacity requirements, you need to set a hard mailbox size limit (prohibit send and receive) for the majority of your users.
  7. What is the deleted item retention period? Enter in the deleted item retention period you plan to utilize within the environment. The default retention period is 14 days, however, you should adjust this to match your policy concerning deleted item recovery when enabling Single Item Recovery to eliminate going to backup media to recover deleted items.
  8. Are you deploying Single Item Recovery? Single Item Recovery ensures that all deleted and modified items are preserved for the duration of the deleted item retention window. By default in Exchange 2010 RTM, this is not enabled. When enabled, this feature increases the capacity requirements for the mailbox.
  9. Will you have calendar version logging enabled? By default, all changes to a calendar item are recorded in the mailbox of a user to keep older versions of meeting items for 120 days and can be used to repair the calendar in the event of an issue. This data is stored in the mailbox's dumpster folder. When enabled, this feature increases the capacity requirements for the mailbox.
  10. Do you want to include an IOPS Multiplication Factor in the prediction or custom I/O profile? The IOPS Multiplication Factor can be used to increase the IOPS/mailbox footprint for mailboxes that require additional I/O (for example, these mailboxes may use third-party mobile devices). The way this value is used is as follows: (IOPS value * Multiplication Factor) + IOPS Value = new IOPS value.
  11. Do your Outlook Online Mode clients have versions of Windows Desktop Search older than 4.0 or third-party desktop search engines deployed? The addition of these indexing tools to the online mode clients incur additional read I/O penalties to the mailbox server storage subsystem. Care should be taken when enabling these desktop search engines. Windows Desktop Search 4.0 and later utilizes synchronization protocols that are similar to how Outlook operates in cached mode to index the mailbox contents, and thus has a very minor impact in terms of disk read I/O.
  12. Are you planning to use the I/O prediction formula or define your own IOPS profile to design toward? This question asks whether you want to override the calculator in determining the IOPS / mailbox value. By default the calculator will predict the IOPS / mailbox value based on the number of messages per mailbox, and the user memory profile. For some customers that want to design toward a specific I/O profile, this option will not be viable. Therefore, if you want to design toward a specific I/O profile, select No.
  13. What is your custom IOPS profile / mailbox? Only enter a value in this field if you selected "No" to the "Predict IOPS Value" question.
  14. What will be the database read:write ratio for your custom IOPS profile? Only adjust this value if you selected "No" to the "Predict IOPS Value" parameter. When IOPS prediction is enabled, the calculator will calculate the read:write ratio based on the user profile.

Backup Configuration



  1. What backup methodology will be used to backup the solution? You have several options for a backup methodology, including leveraging a VSS solution (hardware or software based) or leveraging the native data protection features that Exchange provides. The solution you choose will depend on many factors. For example, if you are deploying the mailbox resiliency and single item recovery features, you may be able to forgo a traditional backup architecture in favor of leveraging Exchange as its own backup. Or if you still require a backup (e.g. legal/compliance reasons), then you need to deploy a VSS solution. The type of VSS solution you deploy will depend on your storage architecture. Hardware VSS solutions are available with storage area networks. Software VSS solutions can be leveraged against either storage area networks or direct attached storage architectures. Also, the backup methodology will affect the LUN design; for example, hardware VSS solutions require a LUN architecture that is 2 LUNs / Database.
  2. What will be the backup frequency? You can choose Daily Full, Weekly Full with Daily Differential, Weekly Full with Daily Incremental, or Bi-Monthly Full with Daily Incremental. The backup frequency will affect the LUN design and the disk space requirements (e.g. if performing daily differentials, then you need to account for 7 days of log generation in your capacity design).
  3. How many times can you operate without log truncation? Select how many times you can survive without a full backup or an incremental backup (the minimum value is 1). For example, if you are a performing weekly full backup and daily differential backups, the only time log truncation occurs is during the full backup. If the full backup fails, then you have to wait an entire week to perform another full backup or perform an emergency full backup. This parameter allows you to ensure that you have enough capacity to not have to perform an immediate full backup. If you are leveraging the native data protection features within Exchange as your backup mechanism, then you should enter 3 here to ensure you have enough capacity to allow for 3 days' worth of log generation to occur as a result of potential log replication issues.
  4. How long can you survive a network outage? When a network outage occurs, log replication cannot occur. As a result, the copy queue length will increase on the source; in addition, log truncation cannot occur on the source. For geographically dispersed DAG deployments, network outages can seriously affect the solution's usefulness. If the outage is too long, log capacity on the source may become compromised and as result, capacity must be increased or a manual log truncation event must occur. Once that happens, the remote copies must be reseeded. The Network Failure Tolerance parameter ensures there is enough capacity on the log LUNs so that you can survive an excessive network outage.

Storage Configuration




  1. Do you want to consider storage designs that leverage JBOD? JBOD storage refers to placing a database and its transaction logs on a single disk without leveraging RAID. In order to deploy this type of storage solution for your mailbox server environment, you must have 3 or more HA database copies and have a LUN architecture that is equal to 1 LUN / Database. If you select yes for this input, the calculator will attempt to design the solution so that it can be deployed on JBOD storage. Please note that other factors may alter the viability of JBOD, however (e.g. deploying a single lagged database copy on the same mailbox servers hosting your HA database copies).


  1. What are the disk capacities and types you plan to deploy? For each type of LUN (database, log, and restore LUN) you plan to deploy, select the appropriate capacity and disk type model.

Log Replication Configuration




  1. How many transaction logs are generated for each hour in the day? Enter in the percentage of transaction logs that are generated for each hour in the day by measuring an existing Exchange 2003 or Exchange 2007 server in your environment. If the existing messaging environment is not using Exchange, then evaluate the messaging environment and enter in the rate of change per hour here.



  1. What type of network link will you be using between the servers? Select the appropriate network link you will be using between the two datacenters.
  2. What is the latency on the network link? Enter in the latency (in milliseconds) that exists on the network link.

Role Requirements



Calculations Pane


Results Pane




  • The Number of Databases is the calculated number of databases required to support the mailbox population within a standalone server or DAG.
  • The Recommended Number of Mailboxes / Database is the calculated number of mailboxes per database ensuring that the database size does not go above the recommended database size limit.
  • The Number of Tier-x Mailboxes / Database provides a breakdown of how many mailboxes from each mailbox tier will be stored within a database.
  • The Database Read I/O Percentage defines the percentage of database required IOPS that are read I/Os. This information is required to accurately design the storage subsystem I/O requirements.
  • The Available Database Cache / Mailbox value is the amount of database cache memory that is available per mailbox. A large database cache ensures that read I/Os can be reduced.



  • The Number of Mailboxes that you entered in the Input section (this value will include the projected growth).
  • The Mailbox Size is the actual mailbox size on disk that factors in the prohibit send/receive limit, the number of messages the user sends/receives per day, the deleted item retention window (with or without calendar version logging and single item recovery enabled), and the average database daily churn per mailbox. It is important to note that the Mailbox size on disk is actually higher than your mailbox size limit; this is to be expected.
  • The Transaction Logs Generated / Mailbox value is based on the message profile selected and the average message size and indicates how many transaction logs will be generated per mailbox per day. The log generation numbers per message profile account for:
    • Message size impact. In our analysis of the databases internally we have found that 90% of the database is the attachments and message tables (message bodies and attachments). So if the average message size doubles (from 75 to 150), the worst case scenario would be for the log traffic to increase by 1.9 times. Thereafter, as message size doubles, the impact doubles.
    • Amount of data Sent/received.
    • Database health maintenance operations.
    • Records Management operations
    • Data stored in mailbox that is not a message (tasks, local calendar appts, contacts, etc).
    • Forced log rollover (a mechanism that periodically closes the current transaction log file and creates the next generation).
  • The IOPS / Mailbox value is the calculated IOPS / Mailbox value that is based on the number of messages per mailbox, the user memory profile, and desktop search engine choices. If you had chosen to enter in a specific IOPS / mailbox value rather than allowing the calculator determining the value based on the above requirements, then this value will be that custom value.
  • The Read:Write ratio / Mailbox value defines the ratio of the mailbox's IOPS that are read I/Os. This information is required to accurately design the storage subsystem I/O requirements.







  • The Recommended RAM Configuration for the primary datacenter mailbox servers, secondary datacenter mailbox servers, and lagged copy servers. This is the amount of RAM needed to support the number of maximum activated database copies on a given server, in addition to, the number of mailboxes based on their memory profile.
  • The Mailbox Role CPU Megacycle Requirements value defines the amount of megacycles the primary datacenter servers must be able to sustain when either all mailbox databases are active or the number of mailbox database copies that are activated based on a single server or double server failure event. For secondary servers hosting HA copies, this value defines the amount of megacycles required to support the activation of all databases after datacenter activation. For lagged copy servers, this value defines the amount of megacycles required to support all of the passive lagged copies.
  • The Mailbox Role CPU Utilization value is the expected CPU Utilization for a fully utilized mailbox server role based on the megacycles associated with the user profile and the number of database copies. Depending on the environment, this will either be for a standalone server hosting 100% active databases, or a server participating in a DAG that is dealing with a single or double server failure event (or secondary datacenter activation). It is recommended that standalone servers with only the mailbox role be designed to not exceed 70% utilization during peak period. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 35%. For solutions leveraging mailbox resiliency, it is recommended that the configuration not exceed 80% utilization after a single or double member server failure when the server only has the mailbox role installed. If deploying multiple roles on the server, then the mailbox role should be designed not to exceed 40%. The CPU utilization value is determined by taking the CPU Megacycle Requirements and dividing it by the total number of megacycles available on the server (which is based on the CPU and number of cores). If the calculator reports "Insufficient Processor Cores" this means the design cannot sustain the load - either you must change the design (number of mailboxes, number of copies, etc) or change the server CPU platform.
  • The Recommended Storage Architecture outlines whether the solution should utilize RAID or JBOD for the primary datacenter servers, secondary datacenter servers, and lagged copy servers. JBOD is only considered under the following conditions (this assumes you configured the calculator to consider 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).



  • The total number of DAGs being deployed in the solution.
  • The total number of mailboxes being deployed within each DAG and within the environment.
  • The number of database copies being deployed within each server and the total number of database copies within the DAG.



  • The Number of Active Databases (Normal Run Time) value defines the number of active databases hosted on each server when there are no server outages. Unlike Exchange 2007, Exchange 2010 is no longer bound by an active/passive high availability model. Instead, each server within a DAG can host active mailbox database copies. The calculator distributes the number of unique databases across the primary datacenter servers within the DAG, ensuring an equal distribution of mailbox database copies are activated on each server. In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
  • The Number of Active Databases (After First Server Failure) value defines the number of active databases hosted on each server when there is a single server outage. As a result of the single server outage, the database copies that were activated on the failed server are equally redistributed across all remaining server nodes. In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
  • The Number of Active Databases (After Double Server Failure) value is populated when you have at least 3 HA mailbox copies and at least 4 mailbox servers within your design. It defines the number of active databases hosted on each server when there are two server outages. As a result of the double server outage, the database copies that were activated on the failed servers are equally redistributed across all remaining server nodes In addition, you can also see the total number of mailboxes that are accessible on each server as a result of the activated database copies.
  • The Number of Active Databases (Secondary Datacenter Activation) value defines the number of database copies that are activated on each server within the second datacenter in a site resilient scenario. In addition, you can also see the total number of mailboxes that are accessible on this server as a result of the activated database copies.



  • The User Transaction Logs Generated / Day indicates how many transaction logs will be generated during the day for each active database, each server, within the DAG, and within the environment.
  • The Average Mailbox Move Transaction Logs Generated / Day indicates how many transaction logs will be generated during the day for active database, each server, within a DAG, and within the environment. This number is an assumption and assumes that an equal percentage of mailboxes will be moved each day, as opposed to moving all mailboxes on the same day.
  • The Average Transaction Logs Generated / Day is the total number of transaction logs that are generated per day for active database, each server, within a DAG, and within the environment (includes user generated logs and mailbox move generated logs).



  • The Database Space Required is the amount of space required to support each database and its corresponding copies. This value is derived from the mailbox size on disk, the data overhead factor, whether a dedicated restore LUN is available. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
  • The Log Space Required is the amount of space required to support each database log stream and the corresponding copies. This value takes into account the number of mailboxes moved per week (assumes worst case and that all mailboxes are moved on the same day), the type of backup frequency in use, the number of days that can be tolerated without log truncation and the number of transaction logs generated per day. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
  • The Database LUN Space Required is the LUN size required to support the database (and potentially its log stream). This calculation takes the total disk space required for the database and adds to it the size of a database plus 110% (if a dedicated restore LUN does not exist) for offline maintenance operations, an additional 10% of the database size for content indexing (if enabled), and includes an amount of free space to ensure the LUN is not 100% utilized (based on LUN Free Space Percentage). This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
  • The Log LUN Space Required is the LUN size required to support the databases log stream. This field lists the amount of space required to support the transaction logs for a given set of databases and includes an amount of free space to ensure the LUN is not 100% utilized (based on LUN Free Space Percentage). This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
  • The Restore LUN Space Required is the amount of space needed to support a restore LUN if the option was selected in the Input Factor section; this will include space for up to 7 databases and 7 transaction log sets. Each server will be provisioned with a restore LUN. This row also shows you the space requirements for each server (based on the total number of database copies), each DAG, and within the environment.
  • The Total Required Database IOPS is the amount of read and write host I/O the database disk set must sustain during peak load (this does not factor in any RAID penalties). This row also shows you the IOPS requirements for each server (based on the total number of database copies), each DAG, and within the environment
  • The Total Required Log IOPS is the amount of read and write host I/O that will occur against the transaction log disk set. This row also shows you the IOPS requirements for each server (based on the total number of database copies), each DAG, and within the environment.



  • When to use GPT disks (when a LUN size is greater than 2TB).
  • How to configure your mailbox server to control the maximum number of mailbox databases that can be activated.
  • Whether the design parameters you have chosen have resulted in more mailbox servers being required to support the design than what a DAG can support.

LUN Design



  • 1 LUN / Database
  • 2 LUNs / Database
  • 2 LUNs / Backup Set




  • Simplified storage administration. Fewer LUNs to manage.
  • Potentially reduce the number of backup jobs.
  • Flexibility to isolate the performance between Databases when not sharing spindles between LUNs.




  • Enables hardware-based VSS at a database level, providing single database backup and restore.
  • Flexibility to isolate the performance between databases when not sharing spindles between LUNs.
  • Increased reliability. A capacity or corruption problem on a single LUN will only impact one database. This is an important consideration when you are not leveraging the built-in mailbox resiliency features.


  • 100 databases requires 200 LUNs which could exceed some storage array maximums.
  • A separate LUN for each database causes more LUNs per server increasing the administrative costs and complexity.



  • Simplified storage administration. Fewer LUNs to manage.
  • Potentially reduce the number of backup jobs.


Calculations Pane


Results Pane









Backup Requirements






Log Replication Requirements





  • The Peak Log & Content Index Throughput Required / Database is the total throughput required for a single log stream and content index. This value is based on the peak log generation hour.
  • The Peak Log & Content Index Throughput Required Between Datacenters / DAG is the total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for the database availability group.
  • The Peak Log & Content Index Throughput Required Between Datacenters / Environment is the total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for all database availability groups.




  • The RPO Log & Content Index Throughput Required / Database is the required throughput necessary to replicate the transaction logs and content index based on the RPO to the mailbox servers that are located within the secondary datacenter per database.
  • The RPO Log & Content Index Throughput Required Between Datacenters / DAG is the RPO total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for the database availability group.
  • The RPO Log & Content Index Throughput Required Between Datacenters / Environment is the RPO total throughput required to replicate the transaction logs and content index to all database copies (lagged and non-lagged) that exist within the alternate datacenter for all database availability groups.





Storage Design


Storage Design Input Factors





  • RAID-1/0 supports 1d+1p, 2d+2p, and 4d+4p groupings
  • RAID-5 supports 3d+1p through 20d+1p groupings (though storage solutions could support more than that).
  • RAID-6 supports 6d+2p groupings.




  • For RAID-1/0 implementations, ensure that you factor in an additional 35% performance overhead.
  • For RAID-5/RAID-6 implementations, ensure that you factor in an additional 100% performance overhead.






Calculations Pane


Results Pane













Conclusion