EDIT: This post has been updated on 5/24/2013 for the new version of calculator. For the list of latest major changes, please see THIS.
Overview
The Exchange Mailbox Server role is arguably one of the most important roles within an Exchange deployment for it stores the data that users will ultimately access on a daily basis. Therefore, ensuring that you design the mailbox server role correctly is critical to your design.
With Exchange 2010 you can deploy a solution that leverages mailbox resiliency and has multiple database copies deployed across datacenters, implements single item recovery for data recovery, and has the flexibility in storage design to allow you to deploy on storage area networks utilizing fibre-channel or SATA class disks or on direct attached storage utilizing SAS or SATA class disks with or without RAID protection. But, in order to design your solution, you need to understand the following criteria:
- 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
Previous versions of Exchange were somewhat rigid in terms of the choices you had in designing your mailbox server role. The flexibility in the architecture with Exchange 2010, allows you the freedom to design the solution to meet your needs. Prior to making any decisions, please review the following topics from the Exchange 2010 Online Help:
- Understanding High Availability and Site Resilience
- Planning for High Availability and Site Resilience
- Understanding Backup, Restore and Disaster Recovery
- Mailbox Server Storage Design Recommendations
- Performance and Scalability
After you have determined the design you would like to implement, you can follow the steps in the Exchange 2010 Mailbox Server Role Design Example article within the Exchange 2010 Online Help to calculate your solution's CPU, memory, and storage requirements, or you can leverage the Exchange 2010 Mailbox Server Role Requirements Calculator.
The calculator is broken out into the following sections (worksheets):
- Input
- Role Requirements
- Activation Scenarios
- Distribution
- LUN Requirements
- Backup Requirements
- Log Replication Requirements
- Storage Design
Important: The data points provided in the calculator are an example configuration. As such any data points entered into the Input worksheet are specific to that particular configuration and do not apply for other configurations. Please ensure you are using the correct data points for your design
Input
When you launch the Exchange 2010 Mailbox Server Role Requirements Calculator, you are presented with the Input worksheet. This worksheet is broken down into 5 key areas. This section is where you enter in all the relevant information regarding your intended design, so that the calculator can generate what you need in order to achieve it.
Note: There are many input factors that need to be accounted for before you can design your solution. Each input factor is briefly listed below; there are additional notes within the calculator that explain them in more detail.
Environment Configuration
Within Step 1 you will enter in the appropriate information concerning your messaging environment's configuration - the high availability architecture and database copy configuration, the data and I/O configuration, and CPU inputs.
Note: For optimal sizing, choose a multiple of the total number of database copies you have selected for the number of mailbox servers.
Exchange Environment Configuration
- What server architecture are you deploying for your global catalogs? You can deploy either the 32-bit or 64-bit architecture for your Active Directory servers. The architecture you deploy will affect your core ratio planning. For more information, please see http://technet.microsoft.com/en-us/library/dd346701.aspx.
- 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.
- Will these servers be deployed as guest machines in a virtualized environment? There is CPU overhead that must be accounted for when deploying guest machines that must be accounted for in the design. For Hyper-V deployments the overhead is about 10%. Check with your hypervisor vendor to determine their overhead and adjust the “Hypervisor CPU Adjustment Factor” accordingly.
- 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).
- 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.).
- 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.
Site Resilience Configuration
- 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.
- 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. The calculator supports three scenarios for these user distribution models:
- 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.
- 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). There are 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):
---DC1--- ---DC2--- DAG1 DAG1 Active Copies Passive Copies Passive Copies Active Copies - 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:
---DC1--- ---DC2--- DAG-A (active/passive copies) DAG-A (Passive Copies) DAG-B (Passive Copies DAG-B (Active/Passive Copies)
- 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):
- 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.
- Will you activation block the mailbox servers in the secondary datacenter? In certain situations (e.g. highly utilized network connection), you may want to control whether cross-site failovers occur automatically. This can be controlled by placing an activation block on the remote mailbox servers, thereby preventing Active Manager from selecting those copies during a failover.
- When deploying an Active/Active (Single DAG) architecture, do you want to deploy dedicated disaster recovery Mailbox servers in the alternate datacenter? If deploying a single DAG Active/Active solution, you can choose to have dedicated DR Mailbox servers deployed in the secondary datacenter to be used in the event of disaster or utilize the existing mailbox servers that are hosting active mailboxes.
Mailbox Database Copy Configuration
- How many highly available (HA) mailbox database copy instances per database 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, but does account for both the active and any passive HA database copies, but includes both the active copy and all passive copies you plan to deploy. For optimal sizing, choose a multiple of the total number of mailbox servers you have selected.
- How many lagged database copy instances per database 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.
- How many highly available mailbox database copy instances per database do you plan to deploy within the secondary datacenter within a DAG? 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.
- How many lagged database copy instances per database do you plan to deploy within the secondary datacenter within a DAG? 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.
Lagged Database Copy Configuration
- 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).
- 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.
- 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.
Exchange Data Configuration
- What will be the Data Overhead Factor? Microsoft recommends using 20% to account for any extraneous growth that may occur.
- 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.
- 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.
- 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.
- 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).
- 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) .
Database Configuration
- 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 not 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.
- 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.
- Would you like the calculator to determine the optimum number of databases for the design? By default the calculator will determine the optimum number of databases for the architecture. In the event that you may want to have a defined number of databases, select No to "Automatically Calculate Number of Databases" and enter in a custom number of databases.
- Do you want to specify the number of databases that should be deployed? If you selected "No" to the previous field, then you need to enter in the number of databases you would like to have deployed within your mailbox server or DAG architecture.
- Do you want to design your database infrastructure such that you deploy the correct number of databases to ensure symmetrical distribution during server failure events? If possible, the calculator will deploy the correct number of databases such that you can achieve a symmetrical distribution of the active copies across the remaining server infrastructure as the DAG experiences server failures. Note that to use this option, you must allow the calculator to automatically calculate the required number of databases.
IOPS Configuration
- 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.
- 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.
Mailbox Configuration
Within Step 2 you will define your user profile for up to four different tiers of user populations.
- 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.
- 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.
- 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.
- What is the average message size? For most customers the average message size is around 75KB.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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) = new IOPS value.
- Do you want to include a Megacycle Multiplication Factor when sizing the CPU requirements for the mailbox tier? The Megacycles Multiplication Factor can be used to increase the CPU cost/mailbox footprint for mailboxes that require perform more CPU work than a typical mailbox (for example, these mailboxes may use third-party mobile devices). The way this value is used is as follows: (Megacycles value * Multiplication Factor) = new Megacycles value.
- 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.
- 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.
- What is your custom IOPS profile / mailbox? Only enter a value in this field if you selected "No" to the "Predict IOPS Value" question.
- 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
Within Step 3 you will define your backup model and your tolerance settings, as well as, choose whether to isolate the transaction logs from the database.
- 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.
- 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).
- Will you isolate the logs from the database? Database/Log isolation refers to placing the DB file an logs from the same Mailbox Database on to different volumes backed by different physical disks. For standalone architectures, the Exchange best practice is to separate database file (.edb) and logs from same database to different volumes backed by different physical disks for recoverability purposes. For solutions leveraging mailbox resiliency, isolation is not required.
- 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.
- 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
Within Step 4 you will define your storage configuration.
Storage Options
- 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).
Primary Datacenter Disk Configuration
- 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.
Secondary Datacenter Disk Configuration
- 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.
Processor Configuration
Within Step 5, you will define the number of processor core you have deployed for each mailbox server within your primary and secondary datacenters, as well as, enter the SPECint2006 Rate Value for the system you have selected.
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, if you are deploying your Exchange servers as guest machines, you can specify the Hypervisor CPU Adjustment Factor to take into account the overhead of deploying guest machines.
Server Configuration
- 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 server’s SPECint2006 rate value. To determine your SPECint2006 Rate Value:
- Open a web browser and got to www.spec.org.
- Click on Results, highlight CPU2006 and then select Search CPU2006 Results.
- Under Available Configurations, select SPECint2006 Rates and click Go. Under Simple Request, enter the search criteria (e.g., Processor matches x5550).
- 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.
Log Replication Configuration
Within Step 6, you will define your hourly log generation rate, the network link, and the network link latency you expect to have within your site resilient architecture.
- 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.
Now you may be wondering how you can collect this data. We've written a simple VBS script that will collect all files in a folder and output it to a log file. You can use Task Scheduler to execute this script at certain intervals in the day (e.g. every 15 minutes). Once you have generated the log file for a 24 hour period, you can import it into Excel, massage the data (i.e. remove duplicate entries) and determine how many logs are generated for each hour. If you do this for each storage group, you will be able to determine your log generation rate for each hour in the day. This script is named collectlogs.vbsrename (just rename it to collectlogs.vbs) and you can find it here: Collectlogs VBS script
Network Configuration
- 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.
- What is the latency on the network link? Enter in the latency (in milliseconds) that exists on the network link.
Role Requirements
This section provides the solution's I/O, capacity, memory, and CPU requirements.
Based on the above input factors the calculator will recommend the following architecture, broken down into four sections:
- Environment Configuration
- Active Database Copy Configuration
- Server Configuration
- Log, Disk Space, and IO Requirements
Processor Core Ratio Requirements
This table identifies the required number of processor cores required to support the activated databases. This table is only populated if you populate the processor core megacycle information on the Input tab.
- The Recommended Minimum Number of Global Catalog Cores identifies the minimum number of processor cores required to sustain the load for global catalog related activities and is based on the number of processor cores required to support the activated databases.
Client Access Server Requirements
This table identifies the memory and CPU requirements for dedicated Client Access servers if you choose to not co-locate the server roles. This table is only populated if you populate the processor core megacycle information on the Input tab.
- The Recommended Minimum Number of Client Access Processor Cores identifies the minimum number of processor cores required per server to sustain the load for client related activities.
- The Recommended Minimum Number of Client Access Server RAM Configuration identifies the minimum amount of memory required per server to sustain the load for client related activities. This number is scaled to a multiple that can be typically installed in a server.
Hub Transport Server Requirements
This table identifies the memory and CPU requirements for dedicated Hub Transport servers if you choose to not co-locate the server roles. This table is only populated if you populate the processor core megacycle information on the Input tab.
- The Recommended Minimum Number of Hub Transport Processor Cores identifies the minimum number of processor cores required per server to sustain the load for client related activities.
- The Recommended Minimum Number of Hub Transport RAM Configuration identifies the minimum amount of memory required per server to sustain the load for client related activities. This number is scaled to a multiple that can be typically installed in a server.
Environment Configuration
The Environment Configuration table identifies the number of mailboxes being deployed in each datacenter, as well as, how many mailbox servers and lagged copy servers you will deploy in each datacenter. This table will also identify the minimum number of dedicated Hub Transport and Client Access servers you should deploy in each datacenter (taking into account worst case failure mode of two simultaneous server failures).
User Mailbox Configuration
The Mailbox Configuration table provides you with:
- The Number of Mailboxes that you entered in the Input section (this value will include the projected growth).
- The Number of Mailboxes / Database provides a breakdown of how many mailboxes from each mailbox tier will be stored within a database.
- The User Mailbox Size within Database 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.
Database Copy Instance Configuration
This table highlights how many HA mailbox database copy instances and lagged database copy instances your solution will have within each datacenter for a given DAG.
Database Configuration
The Database Configuration table provides you with:
- 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 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.
Database Copy Configuration
The Database Copy Configuration table provides you with the number of database copies being deployed within each server and the total number of database copies within the DAG.
Server Configuration
The Server Configuration table provides you with the following:
- 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 number of processor cores utilized during the worst failure mode scenario.
- The CPU Utilization value is the expected CPU Utilization for a fully utilized server 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 servers not exceed 80% utilization during peak period. 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 highlights the CPU utilization with a red background, then this means the design may not be able to sustain the load - either you must change the design (number of mailboxes, number of copies, etc.) or change the server CPU platform.
- The 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 Server Total Available Adjusted Megacycles value defines the total available megacycles the server platform is capable of delivering at 100% CPU utilization. This value has been normalized against the baseline server platform (Intel Xeon x5470 2x4 3.33GHZ processors).
- The Possible Storage Architecture outlines whether the solution could 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).
Transaction Log Requirements
The Transaction Log Requirements table provides you with:
- 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).
Disk Space Requirements
The Disk Space Requirements table provides you with:
- 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.
Host IO and Throughput Performance Requirements
The Host IO and Throughput Performance Requirements table provides you with:
- 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.
- 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 amount of throughput required for Background Database Maintenance operations.
Special Notes
The Special Notes table will provide you with additional information about your design:
- When to use GPT disks (when a LUN size is greater than 2TB).
Activation Scenarios
If you are deploying a highly available and/or site resilient architecture, then this section will break down the failure scenarios. The section is broken up into two scenarios:
- Scenario 1 - Deploying a DAG architecture within a single datacenter or deploying it in a site resilient Active/Passive user distribution model.
- Scenario 2 - Deploying a site resilient DAG architecture with an Active/Active user distribution model.
Important: For the purposes of this calculator, the term "primary datacenter" refers to the datacenter that is preferred for hosting the active copies for a given set of databases, while the term "secondary datacenter" refers to the disaster recovery datacenter that is used for datacenter activation and cross-site database failover events.
Single Datacenter and Active/Passive Environments
The DAG Member Layout table identifies the number of Active Mailbox servers (those that are hosting active mailboxes within the primary datacenter), the Disaster Recovery Mailbox Servers (those that host passive database copies in the second datacenter), and any Lagged Copy Mailbox servers you may be deploying.
There are two tables that provide data around the Active Database configuration, one for the primary datacenter, which outlines the single or double server events, and one for the secondary datacenter, which outlines the activation of that datacenter when the primary datacenter is lost. Both tables provide you with:
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
Active/Active Environments
This section breaks out the architecture into two perspectives, the layout of Datacenter 1 and the layout of Datacenter 2 with respect to the DAG architecture. Recall that
- 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):
---DC1--- ---DC2--- DAG1 DAG1 Active Copies Passive Copies Passive Copies Active Copies - 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:
---DC1--- ---DC2--- DAG-A (active/passive copies) DAG-A (Passive Copies) DAG-B (Passive Copies DAG-B (Active/Passive Copies)
The DAG Member Layout table identifies the number of Active Mailbox servers (those that are hosting active mailboxes within the primary datacenter), the Disaster Recovery Mailbox Servers (those that host passive database copies in the second datacenter), and any Lagged Copy Mailbox servers you may be deploying.
There are two tables that provide data around the Active Database configuration, one for the primary datacenter, which outlines the single or double server events, and one for the secondary datacenter, which outlines the activation of that datacenter when the primary datacenter is lost. Both tables provide you with:
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
- 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. This row exposes the total number of mailboxes that are accessible on each server as a result of the activated database copies. In addition, this row highlights the total number of databases deployed within each datacenter, in the event that cross-site database *overs are allowed to occur.
Distribution
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.
- CreateMBDatabases.ps1 (uses MailboxDatabases.csv) - Creates the mailbox database copies with activation preference value of 1.
- CreateMBDatabaseCopies.ps1 (uses MailboxDatabaseCopies.csv) - Creates the mailbox database copies with the appropriate activation preference values across the server infrastructure.
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
LUN Design
The LUN Requirements section is really a continuation of the Storage Requirements section. It outlines what we believe is the appropriate LUN design based on the input factors and the analysis performed in the previous sections.
Note: The term LUN utilized in the calculator refers only the representation of the disk that is exposed to the host operating system. It does not define the disk configuration.
The LUN Design highlights the LUN architecture chosen for this server solution. The architecture is derived from the backup type, backup frequency, and high availability architecture that were chosen in the Storage Requirements section.
There are three types of LUN architecture that can be leveraged within Exchange 2010:
- 1 LUN / Database
- 2 LUNs / Database
- 2 LUNs / Backup Set
1 LUN / Database
A single LUN per Database architecture means that both the database and its corresponding log files are placed on the same LUN. In order to deploy a LUN architecture that only utilizes a single LUN per database, you must have a Database Availability Group that has 2 or more copies and not be utilizing a hardware based VSS solution.
Some of the benefits of this strategy include:
- 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.
Some of the concerns with this strategy include:
- Limits the ability to take hardware based VSS backup and restores (e.g., clone snapshots). See Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 for more VSS details.
2 LUNs / Database
With Exchange 2010, in the maximum case of 100 Databases, the number of LUNs you provision will depend upon your backup strategy. If your recovery time objective (RTO) is very small, or if you use VSS clones for fast recovery, it may be best to place each Database on its own transaction log LUN and database LUN. Because doing this will exceed the number of available drive letters, volume mount points must be used.
Some of the benefits of this strategy include:
- 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.
Some of the concerns with this strategy include:
- 100 databases require 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.
2 LUNs / Backup Set
A backup set is the number of databases that are fully backed up in a night. A solution that performs a full backup on 1/7th of the databases nightly (i.e. using a weekly or bi-monthly full backup with daily incrementals or differentials) can reduce complexity by placing all of the databases to be backed up on the same log and database LUN. This can reduce the number of LUNs on the server.
Some of the benefits of this strategy include:
- Simplified storage administration. Fewer LUNs to manage.
- Potentially reduce the number of backup jobs.
Some of the concerns with this strategy include:
- Limits the ability to take hardware based VSS backup and restores (e.g., clone snapshots). See Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003 for more VSS details.
- A capacity or corruption problem on a single LUN could impact more than one Database.
Results Pane
Based on the above input factors the calculator will recommend the following architecture:
LUN Design
The LUN Design table highlights the recommended LUN architecture.
LUN Configuration
The LUN Configuration table highlights the number of databases that should be placed on a single LUN. This is derived from LUN Architecture model.
This section also documents how many LUNs will be required for the entire solution, broken out by Database and Log sets, and the number of restore LUNs per server.
Database Configuration
The Database Configuration table outlines the number of databases (or copies) per server, the number of mailboxes per database, the size of each database, and the transaction log size required for each database.
Database and Log LUN Design
The database and log LUN Design table outlines the physical LUN layout and follows the recommended number of databases per LUN approach based on the LUN Architecture model. It also documents the LUN size required to support layout (this is where we factor in the additional capacity for content indexing, the LUN Free Space Percentage, and whether you are using a Restore LUN), as well as the transaction log LUN.
Important: The DB and Log LUN Design Table identify databases by a unique number. However, databases copies are distributed across the servers, and thus, these numbers hold no significance and are used solely as an example to show a server's LUN layout.
Backup Requirements
The Backup Requirements section is really a continuation of the Role Requirements section. It outlines what we believe is the appropriate backup design based on the input factors and the analysis performed in the previous sections.
Backup Configuration
The Backup Configuration table outlines the number of databases that will be placed within a single LUN and the type of backup methodology and frequency in which the backups will occur.
Backup Frequency Configuration
The Backup Frequency Configuration section will provide you with an outline on how you should perform the backups for each server, utilizing either a daily full backup or weekly or bi-monthly full backup frequency.
Log Replication Requirements
The Log Replication Requirements section is another continuation of the Role Requirements section. It outlines what we believe is the throughput required to replicate the transaction logs to each target database copy in the secondary datacenter.
Peak Log and Content Index Replication Throughput Requirements
The Peak Log and Content Index Replication Throughput Requirements table provides you with:
- 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.
RPO Log and Content Index Replication Throughput Requirements
In terms of log replication, RPO means how behind can you get in log shipping? The lower the RPO (a value of 0 or 1 essentially means you want to only lose the open log file), the higher the bandwidth you need because you cannot get behind in log replication. The higher the RPO (approaching 24) less bandwidth is needed as you are expecting to be behind (up to x hours) in log replication and to catch up at some point in the day.
The RPO Log and Content Index Replication Throughput Requirements table provides you with:
- 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.
Chosen Network Link Suitability
The Chosen Network Link Suitability table will dictate whether the chosen network link has sufficient capacity to sustain the peak replication throughput requirements and/or the RPO replication throughput requirements. If the network link cannot sustain the log replication traffic, then you will need to either upgrade the network link to the recommended network link throughput, or adjust the design appropriately.
Recommended Network Link
The Recommended Network Link table recommends an appropriate network link if the chosen network link does not have sufficient capacity to sustain log replication for solution for both the peak and RPO throughput requirements.
Note: The Network Link recommendations do not take into account database seeding or any other data that may also utilize the link.
Storage Design
The Storage Design worksheet is designed to take the data collected from the Input worksheet and Storage Requirements worksheet and help you determine the number of physical disks needed to support the databases, transaction logs, and Restore LUN configurations.
Storage Design Input Factors
In order to determine the physical disk requirements, you must enter in some basic information about your storage solution.
RAID Parity Configuration
For the Database/Log RAID Parity Configuration table you need to select the type of RAID building block your storage solution utilizes. For example, some storage vendors build the underlying storage in sets of data+parity (d+p) groups. A RAID-5 3+1 configuration means that 3 disks will be used for capacity and 1 disk will be used for parity, even though parity is distributed across all the disks. So if you had a capacity requirement that would utilize 15 disks, then you would need to deploy 5 3+1 groups to build that RAID-5 array.
- 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.
Database/Log RAID Rebuild Overhead
When a disk is lost, the disk needs to be replaced and rebuilt. During this time, the performance of the RAID group is affected. This impact as a result can affect user actions. Therefore, to ensure that RAID rebuilds do not affect the overall performance of the mailbox server, Microsoft recommends that you should ensure sufficient overhead is provisioned into the performance calculations when designing for RAID parity. Most RAID-1/0 implementations will suffer a 25% performance penalty during a rebuild. Most RAID-5 and RAID-6 implementations will suffer a 50% performance penalty during a rebuild.
The calculator defaults with the following as Microsoft recommendations, but they are adjustable:
- 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.
In addition, you should consult with your storage vendor to determine the appropriate RAID rebuild penalty.
Database RAID Configuration
By default, for RAID storage solutions, the calculator will recommend either RAID-1/0 or RAID-5 by evaluating capacity and I/O factors and determining which configuration utilizes the least amount of disks while satisfying the requirements. If you would like to override this and force the calculator to utilize a particular RAID configuration for your databases (e.g., RAID-0 or RAID-6), select "Yes" to this option and then select the appropriate RAID configuration in the cell labeled "Desired RAID Configuration." Note that while you can potentially override the database RAID configuration, you cannot do so for the log RAID configuration - that will always be RAID-1/0.
Note: The calculator prevents the use of RAID-5 or RAID-6 with 5.2K, 5.4K, 5.9K and 7.2K disk types, due to performance implications.
Restore LUN RAID Configuration
You can select the type of parity you will be utilizing and the RAID configuration you will be deploying for your Restore LUN.
Results Pane
The Storage Design Results section outputs the recommended configuration for the solution. The recommendations made are for implementing the solution potentially on RAID and JBOD storage.
RAID Storage Architecture
The RAID Storage Architecture Table outlines which servers (primary datacenter servers, secondary datacenter servers, or lagged copy servers) should be deployed on RAID storage.
The RAID Storage Architecture / Server table recommends the optimum RAID configuration and number of disks for each LUN (database, log and restore LUN) for each mailbox server ensuring that performance and capacity requirements are met within the design.
JBOD Storage Architecture
The JBOD Storage Architecture Table outlines which servers (primary datacenter servers, secondary datacenter servers, or lagged copy servers) could be deployed on JBOD storage.
The JBOD Storage Architecture / Server table recommends the optimum JBOD configuration and number of disks for each LUN (database, log and restore LUN) for each mailbox server ensuring that performance and capacity requirements are met within the design.
Total Disks Required
By default, the calculator will determine the storage architecture that should be utilized to reduce the total number of disks required to support the design, in addition, to 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. However, you can change the storage architecture to be built entirely on RAID or entirely on JBOD (if the design supports JBOD as a possible solution; also keep in mind that certain scenarios (e.g., a single database copy in a datacenter) may result in a single point of failure) by selecting the appropriate value in the "Storage Architecture will be Deployed:" drop-down.
The Storage Configuration table will output the total number of disks required for each mailbox server that requires RAID or JBOD storage, as well as, identify the total number of disks requiring RAID or JBOD storage in each datacenter.
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 calculator itself, please see the following link:
Exchange 2010 Server Role Requirements Calculator
