Deploying Microsoft Exchange Server 2010 on the Hitachi Adaptable Modular Storage 2500

Deploying Microsoft Exchange Server 2010 on the Hitachi Adaptable Modular Storage 2500 Reference Architecture Guide By Patricia Brailey July 2010

Summary IT administrators need email solutions that provide data protection and simple management in environmentally friendly data centers. Using Microsoft Exchange Server 2010 with SAN storage like the Hitachi Adaptable Modular Storage 2000 family accomplishes those business-critical objectives. The reference architecture described in this white paper leverages changes in Exchange Server 2010 and the advantages of the 2000 family to lower administration costs, to improve system efficiency and to enable virtualization. Exchange Server 2010 can be deployed for many types and numbers of users in a wide variety of infrastructure topologies. By implementing Exchange Server 2010 with the Hitachi Adaptable Modular Storage 2000 family of storage systems, you can effectively scale an environment from a few thousand users to hundreds of thousands of users. The active-active nature of the 2000 family controllers and the use of Hitachi Dynamic Provisioning software also allow you to combine different workloads in a single storage frame for greater flexibility. For best results use Acrobat Reader 8.0.

Feedback Hitachi Data Systems welcomes your feedback. Please share your thoughts by sending an e-mail message to SolutionLab@hds.com. Be sure to include the title of this white paper in your email message.

Table of Contents Solution Components... 1 Hitachi Adaptable Modular Storage 2500... 1 Hitachi Dynamic Provisioning Software... 2 Exchange Server 2010... 2 Reference Architecture... 4 Mailbox and Site Resiliency... 4 Storage Area Network... 6 Networking... 7 Storage Design... 8 Storage Design Considerations... 14 Determining I/O Requirements... 14 Determining Capacity Requirements... 15 RAID Group and LU Design... 17 Processor and Memory Design... 17 Engineering Validation... 20 Test Methodology... 20

Deploying Microsoft Exchange Server 2010 on the Hitachi Adaptable Modular Storage 2500 Reference Architecture Guide IT administrators need email solutions that provide data protection and simple management in environmentally friendly data centers. Using Microsoft Exchange Server 2010 with SAN storage like the Hitachi Adaptable Modular Storage 2000 family accomplishes those business-critical objectives. The reference architecture described in this white paper leverages changes in Exchange Server 2010 and the advantages of the 2000 family to lower administration costs, to improve system efficiency and to enable virtualization. Exchange Server 2010 can be deployed for many types and numbers of users in a wide variety of infrastructure topologies. By implementing Exchange Server 2010 with the Hitachi Adaptable Modular Storage 2000 family of storage systems, you can effectively scale an environment from a few thousand users to hundreds of thousands of users. The active-active nature of the 2000 family controllers and the use of Hitachi Dynamic Provisioning software also allow you to combine different workloads in a single storage frame for greater flexibility. This reference architecture is for a deployment of 60,000 users across two Hitachi Adaptable Modular Storage 2500 storage systems. The users reside at two sites within multiple Database Availability Groups (DAGs). This reference architecture focuses on planning and deploying the Exchange Server 2010 mailbox role and is intended for use by IT administrators responsible for Exchange and storage. It assumes some familiarity with Hitachi Storage Navigator Modular 2 software, Microsoft Windows 2008 R2 and Exchange Server 2010. For information about deploying other Exchange server roles, see the Microsoft TechNet library Exchange Server 2010. Solution Components The following sections describe the key components needed to deploy this solution. Hitachi Adaptable Modular Storage 2500 The Hitachi Adaptable Modular Storage 2500 provides a reliable, flexible, scalable and cost effective modular storage system for the Microsoft Exchange 2010 solution described in this white paper. The 2500 is ideal for a demanding application like Exchange and delivers enterprise-class performance, capacity and functionality at a midrange price. The Hitachi Adaptable Modular Storage 2500 is the only midrange storage product with symmetric active-active controllers that provide integrated, automated hardware-based front-to-back-end I/O load balancing. Both controllers in a 2500 storage system are able to dynamically and automatically assign the access paths from the controller to the LU. All LUs are accessible regardless of the physical port or the server from which the access is requested. Utilization rates of each controller are monitored so that a more even distribution of workload between the two controllers can be maintained. Storage administrators are no longer required to manually define specific affinities between LUs and controllers, simplifying overall administration. In addition, this controller design is fully integrated with standard host-based multipathing, thereby eliminating mandatory requirements to implement proprietary multipathing software. 1

No other midrange storage product that scales beyond 100TB has a serial attached SCSI (SAS) drive interface. The point-to-point back-end design virtually eliminates I/O transfer delays and contention associated with Fibre Channel arbitration and provides significantly higher bandwidth and I/O concurrency. It also isolates any component failures that might occur on back-end I/O paths. For more information about the 2500 and other models of the 2000 family, see the Hitachi Adaptable Modular Storage 2000 Family Overview brochure. Hitachi Dynamic Provisioning Software On Hitachi Adaptable Modular Storage 2000 family systems, Hitachi Dynamic Provisioning software provides a wide-striping technology that dramatically improves performance, capacity utilization and management of your environment. By deploying your Exchange Server 2010 mailbox servers using volumes from Hitachi Dynamic Provisioning storage pools on the 2500, you can expect the following benefits: An improved I/O buffer to burst into during peak usage times A smoothing effect to the Exchange workload that can eliminate hot spots, resulting in reduced mailbox moves related to performance Minimization of excess, unused capacity by leveraging the combined capabilities of all disks comprising a storage pool Elimination of the need to manage the placement of power users and worrying about which users currently use or might be getting a BlackBerry, Windows Mobile device or iphone Exchange Server 2010 Exchange Server 2010 introduces several architectural changes that need to be considered when planning deployment on a Hitachi Adaptable Modular Storage 2500 system. Storage Groups Exchange Server 2010 does not use storage group objects. This change from previous versions of Exchange facilitates database mobility and means that Exchange data is now protected at the database level instead of at the server level. This results in a simpler and faster failover and recovery process. Limits on the number of databases per server still exist; the maximum for the standard edition of Exchange Server 2010 is five and the maximum for the enterprise edition is 100. Database Availability Groups To support database mobility and site resiliency, Exchange Server 2010 introduces Database Availability Groups (DAGs). A DAG is an object in Active Directory that can include up to 16 Mailbox servers that host a set of databases; any server within a DAG has the ability to host a copy of a mailbox database from any other server within the DAG. DAGs support mailbox database replication and database and server switchovers and failovers. Setting up a Windows failover cluster is no longer necessary for high availability; however, the prerequisites for setting up a DAG are similar to that of a failover cluster. 2

Figure 1 shows two DAGs across two sites. Figure 1. Database Availability Groups Across Two Sites For more information about how this reference architecture s DAG is configured, see the Mailbox and Site Resiliency section. Databases In Exchange Server 2010, the changes to the Extensible Storage Engine (ESE) enable the use of large databases (approximately 2TB) on larger, slower disks while maintaining adequate performance. The ESE uses larger and more sequential I/O, and database maintenance routines like online defragmentation and checksums are run continually in the background. The Exchange Store s database tables make better use of the underlying storage system and cache and the store no longer relies on secondary indexing, making it less sensitive to performance issues. 3

Reference Architecture This reference architecture is for a deployment of 60,000 users across two Hitachi Adaptable Modular Storage 2500 storage systems. Each user sends and receives an average of 100 messages per day. The reference architecture uses 36 mailbox servers that are divided into six Database Availability Group (DAGs) of six servers each with three servers per DAG at each site. Two high-availability copies of the mailbox databases (one active and one passive) with half of the active copies are located at each site. Figure 2 shows the topology of this Exchange 2010 implementation using 36 servers and six DAGs across two sites. Figure 2. Reference Architecture Topology The mailbox servers in the diagram each have a LAN connection to both the MAPI and replication networks. The MAPI and replication networks at each site are connected by a WAN link. Mailbox and Site Resiliency A key aspect of this Exchange 2010 reference architecture on the 2500 is mailbox resiliency. Mailbox resiliency allows you to deploy your mailbox servers so that they are protected by automatic failover at the individual database level. This is accomplished by using DAGs. In this reference architecture, because the Exchange 4

databases reside on intelligent, RAID-protected disks, only two copies of the databases are deployed; one active and one passive. To maintain manageability, the 36 servers are divided into six DAGs of six servers each. Within the DAGs, each server hosts an active database and a passive database for a total of two databases. Figure 3 shows the DAG configuration. Figure 3. DAG Configuration 5

In a production environment, it is important to design the mailbox resiliency scenario to handle the load of all active copies on both the storage system and servers. Two 2500 storage systems, one at each site, host both the active and passive copies of the 36 servers with 18 sets of active copies on each. A single 2500 can handle all 36 sets of active copies (60,000 mailboxes) in the case of a site failure. In addition to deploying multiple passive copies of the Exchange databases, you can configure copies populated with delayed log replay data or lag copies. This can be useful to protect against data corruption and is an alternative to taking regular backups. In this reference architecture, site resiliency is ensured by placing the second 2500 at a separate, geographically distant site. In addition to the 2500, Hitachi Data Systems recommends deploying dual Fibre Channel switches at each site to maintain high availability within the storage area network architecture. Deploying Exchange 2010 in a mailbox resiliency scenario allows you to increase the database size to 2TB because you have the ability to restore from a passive copy of the database rather than a backup. Another benefit of using mailbox resiliency is maximizing hardware efficiency by distributing the active database copies across all servers in the DAG. For more information about mailbox and site resiliency, see Microsoft s TechNet article High Availability and Site Resilience. Storage Area Network The storage area network (SAN) configuration for this reference architecture uses two Fibre Channel switches at each site for high availability. Two redundant paths are configured from each Exchange mailbox server to the 2500. Each server has two host bus adapters (HBAs) installed for high availability purposes. The latest version of Hitachi Dynamic Link Manager software is used for multipathing, employing the roundrobin multipathing policy. Hitachi Dynamic Link Manager software s round-robin load balancing algorithm automatically selects a path by rotating through all available paths, thus balancing the load across all available paths and optimizing IOPS and response time. Another option is to use the round-robin algorithm available with the Windows native MPIO feature. Figure 4 shows the Fibre Channel SAN architecture for a two-site DAG implementation like the one described in this reference architecture guide. 6

Figure 4. SAN Architecture Example Networking When deploying Exchange mailbox servers in a DAG, Hitachi Data Systems recommends having two separate local area network subnets available to the members: one for client access and the other for replication purposes. The configuration is similar to the public, mixed and private networks used in previous versions of Exchange. In Exchange 2010, networks are now referred to as the MAPI network, which is used for communication among the DAG members and other Exchange servers, and the replication network, which is dedicated to log shipping and seeding. Using a single network is a supported configuration, but it is not recommended by Hitachi Data Systems. Having at least two networks connected to two separate network adapters in each server provides redundancy and enables Exchange to distinguish between a server failure and a network failure. Each DAG member must have the same number of networks and at least one MAPI network. Follow Microsoft s guidance regarding network latency for DAG members located in different geographic sites. For more information about network planning for Exchange Server 2010, see the Microsoft TechNet article Planning for High Availability and Site Resilience. In a very large, site-resilient solution such as the one described in this guide, other networking equipment including WAN optimizers and load-balancers are also needed at each site. The maximum network latency that can be tolerated by Exchange Server 2010 is 250ms. To maintain that level of latency, a WAN optimizer is likely to be needed. A network load balancer must be deployed in front of the CAS servers to distribute the user load, because this functionality is not built in to Exchange. Software-based network load balancers (like Microsoft s NLB) could be used for smaller environments, but for a large environment like this one, use a hardware network load-balancing solution. 7

Storage Design To satisfy 60,000 users needing 1GB of mailbox capacity and an I/O profile of.12 IOPS, this reference architecture uses two Dynamic Provisioning pools on each Hitachi Adaptable Modular 2500 storage system. Pool 0 contains 32 RAID-5 (4+1) groups for the Exchange databases and Pool 1 contains 16 RAID-1+0 (2+2) for the Exchange transaction logs. The two pools contain a total of 224 600GB 15K SAS disks. Table 2 shows the drive configuration for one 2500. Table 2. Drive Configuration Drive Slot 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 RKA 14 RKA 13 RKA 12 RKA 11 RKA 10 RKA 9 RKA 8 RKA 7 RKA 6 RKA 5 RKA 4 RKA 3 RKA 2 RKA 1 RKA 0 RAID-5 (4+1) Pool 0 RAID-1+0 (2+2) Pool 1 The following tables describe the LU layouts from each of the Dynamic Provisioning pools and their descriptions. The database LUs are 1.8TB in size and the log LUs are 100GB in size. 8

Table 3 describes the LU layouts for Dynamic Provisioning pool 0 on site A. Table 3. Dynamic Provisioning Pool 0 Site A Server LUN Description 1 1 Database 1, active 2 2 Database 2, active 3 3 Database 3, active 7 4 Database 7, active 8 5 Database 8, active 9 6 Database 9, active 13 7 Database 13, active 14 8 Database 14, active 15 9 Database 15, active 19 10 Database 19, active 20 11 Database 20, active 21 12 Database 21, active 25 13 Database 25, active 26 14 Database 26, active 27 15 Database 27, active 31 16 Database 31, active 32 17 Database 32, active 33 18 Database 33, active 1 19 Database 6, passive 2 20 Database 5, passive 3 21 Database 4, passive 7 22 Database 12, passive 8 23 Database 11, passive 9 24 Database 10, passive 13 25 Database 18, passive 14 26 Database 17, passive 15 27 Database 16, passive 19 28 Database 24, passive 20 29 Database 23, passive 21 30 Database 22, passive 25 31 Database 30, passive 26 32 Database 29, passive 27 33 Database 28, passive 9

Server LUN Description 31 34 Database 36, passive 32 35 Database 35, passive 33 36 Database 34, passive Table 4 describes the LU layouts for Dynamic Provisioning pool 0 on site B. Table 4. Dynamic Provisioning Pool 0 Site B Server LUN Description 4 1 Database 4, active 5 2 Database 5, active 6 3 Database 6, active 10 4 Database 10, active 11 5 Database 11, active 12 6 Database 12, active 16 7 Database 16, active 17 8 Database 17, active 18 9 Database 18, active 22 10 Database 22, active 23 11 Database 23, active 24 12 Database 24, active 28 13 Database 28, active 29 14 Database 29, active 30 15 Database 30, active 34 16 Database 34, active 35 17 Database 35, active 36 18 Database 36, active 4 19 Database 3, passive 5 20 Database 2, passive 6 21 Database 1, passive 10 22 Database 9, passive 11 23 Database 8, passive 12 24 Database 7, passive 16 25 Database 15, passive 17 26 Database 14, passive 18 27 Database 13, passive 22 28 Database 21, passive 10

Server LUN Description 23 29 Database 20, passive 24 30 Database 19, passive 28 31 Database 27, passive 29 32 Database 26, passive 30 33 Database 25, passive 34 34 Database 33, passive 35 35 Database 32, passive 36 36 Database 31, passive Table 5 describes the LU layouts for Dynamic Provisioning pool 1 on site A. Table 5. Dynamic Provisioning Pool 1 Site A Server LUN Description 1 41 Log 1, active 2 42 Log 2, active 3 43 Log 3, active 7 44 Log 7, active 8 45 Log 8, active 9 46 Log 9, active 13 47 Log 13, active 14 48 Log 14, active 15 49 Log 15, active 19 50 Log 19, active 20 51 Log 20, active 21 52 Log 21, active 25 53 Log 25, active 26 54 Log 26, active 27 55 Log 27, active 31 56 Log 31, active 32 57 Log 32, active 33 58 Log 33, active 1 59 Log 6, passive 2 60 Log 5, passive 3 61 Log 4, passive 7 62 Log 12, passive 8 63 Log 11, passive 11

Server LUN Description 9 64 Log 10, passive 13 65 Log 18, passive 14 66 Log 17, passive 15 67 Log 16, passive 19 68 Log 24, passive 20 69 Log 23, passive 21 70 Log 22, passive 25 71 Log 30, passive 26 72 Log 29, passive 27 73 Log 28, passive 31 74 Log 36, passive 32 75 Log 35, passive 33 76 Log 34, passive Table 6 describes the LU layouts for Dynamic Provisioning pool 1 on site B. Table 6. Dynamic Provisioning Pool 1 Site B Server LUN Description 4 41 Log 4, active 5 42 Log 5, active 6 43 Log 6, active 10 44 Log 10, active 11 45 Log 11, active 12 46 Log 12, active 16 47 Log 16, active 17 48 Log 17, active 18 49 Log 18, active 22 50 Log 22, active 23 51 Log 23, active 24 52 Log 24, active 28 53 Log 28, active 29 54 Log 29, active 30 55 Log 30, active 34 56 Log 34, active 35 57 Log 35, active 36 58 Log 36, active 12

Server LUN Description 4 59 Log 3, passive 5 60 Log 2, passive 6 61 Log 1, passive 10 62 Log 9, passive 11 63 Log 8, passive 12 64 Log 7, passive 16 65 Log 15, passive 17 66 Log 14, passive 18 67 Log 13, passive 22 68 Log 21, passive 23 69 Log 20, passive 24 70 Log 19, passive 28 71 Log 27, passive 29 72 Log 26, passive 30 73 Log 25, passive 34 74 Log 33, passive 35 75 Log 32, passive 36 76 Log 31, passive The following table describes the port layout on the 2500. Half the servers are connected to the 2500 at site A and half are connected to the 2500 at site B. Table 7. Server to Port Layout Servers Primary Path Secondary Path 1-9 0A 1A 10-18 0B 1B 19-27 0C 1C 28-36 0D 1D 13

Table 8 lists the port to LU mapping for the Exchange databases and logs. Table 8. Port to LU Mapping Port LUN 0A 1 2 3 4 5 6 7 8 9 41 42 43 44 45 46 47 48 49 1A 1 2 3 4 5 6 7 8 9 41 42 43 44 45 46 47 48 49 0B 10 11 12 13 14 15 16 17 18 50 51 52 53 54 55 56 57 58 1B 10 11 12 13 14 15 16 17 18 50 51 52 53 54 55 56 57 58 0C 19 20 21 22 23 24 25 26 27 59 60 61 62 63 64 65 66 67 1C 19 20 21 22 23 24 25 26 27 59 60 61 62 63 64 65 66 67 0D 28 29 30 31 32 33 34 35 36 68 69 70 71 72 73 74 75 76 1D 28 29 30 31 32 33 34 35 36 68 69 70 71 72 73 74 75 76 Storage Design Considerations Proper storage design requires careful planning. This section contains information regarding what factors need to be considered when designing the storage infrastructure as well as how to size it appropriately. Determining I/O Requirements When designing the storage architecture for Exchange 2010 always start by calculating the I/O requirements. You must determine how many I/Os per second (IOPS) each mailbox needs. This is also known as determining the I/O profile. Microsoft has guidelines and tools available to help you determine this number. Two factors are used to estimate the I/O profile: how many messages a user sends and receives per day and the amount of database cache available to the mailbox. The database cache (which is located on the mailbox server) is used by the ESE to reduce I/O operations. Generally, more cache means less I/O operations eventually hitting the storage system. Table 9 lists Microsoft s guidelines. Table 9. Estimated IOPS per Mailbox Messages Sent and Received per Mailbox per Day Database Cache per Mailbox (MB) Standalone Estimated IOPS per Mailbox Mailbox Resiliency Estimated IOPS per Mailbox 50 3 0.06 0.05 100 6 0.12 0.10 150 9 0.18 0.15 200 12 0.24 0.20 250 15 0.30 0.25 300 18 0.36 0.30 350 21 0.42 0.35 400 24 0.48 0.40 450 27 0.54 0.45 500 30 0.60 0.50 14

For this reference architecture, an I/O profile of 100 messages a day, or 0.1 IOPS per mailbox, was used. To ensure that the architecture can provide sufficient overhead for periods of extremely high workload, Hitachi adds 20 percent overhead for testing scenarios for a total of 0.12 IOPS. To calculate the total number of IOPS or transactions per second (TPS) for an Exchange environment use the following formula. (# of users) x (estimated IOPS per mailbox) = required host IOPS (TPS) For example, 60,000 users x 0.12 IOPS = 7200 IOPS. This calculation provides the number of application IOPS required by the host to service the environment, but it does not calculate the exact number of physical IOPS required on the storage side. Additional calculations must be performed to factor in the read-write ratio used by Exchange Server 2010 and the write penalty incurred by the various types of RAID levels. Exchange Server 2010 exhibits a 65 percent read and a 35 percent write workload. Use this ratio to calculate how many read and write IOPS are required. The transaction logs in Exchange Server 2010 require approximately 10 percent as many I/Os as the databases. For mailbox databases in a resiliency scenario, the log write I/O is 50 percent of the database write I/O. For log read I/O in a mailbox resiliency situation, apply a 10 percent overhead to account for the use of continuous replication. For example, if the databases on a server require 1,000 I/Os, the logs require 100 I/Os. Of those 100 I/Os, 50 are write I/O and 50 plus 10 percent (or 55) are read I/O. After you calculate the transactional log I/O, Microsoft recommends adding another 20 percent overhead to ensure adequate capacity for busier-than-normal periods. For more information about determining I/O capacity for Exchange Server 2010, see Microsoft TechNet article Understanding Database and Log Performance Factors. Determining Capacity Requirements In addition to the mailbox quota requirement, you must also consider the size of the database dumpster and the amount of white space the database is likely to have. The database always has free pages or white space spread throughout. During online maintenance, items marked for removal from the database are removed, freeing those pages. The amount of white space in the database can be estimated by knowing the amount of mail (in MB) sent and received by the users with mailboxes inside the database. Each database also has a dumpster that stores items deleted from a user s mailbox. By default, these items are stored for 14 days (calendar items are stored for 120 days). In addition to the dumpster, Exchange Server 2010 includes the single item recovery feature. This feature is disabled by default and it prevents the purging of data before the deleted item retention window has passed. When enabled, this feature increases the size of the mailbox for a two-week period and must be considered when determining the capacity requirements. You must also consider content indexing, which allows you to perform a quick and easy search of your mail items. This factor contributes about 10 percent of the total database size of additional overhead. The personal archive feature was not included in this reference architecture; however, if you plan to use it you must increase the storage quota for each mailbox to include the additional data. A personal archive mailbox can be created at any time, and it resides on the same mailbox database as the user s primary mailbox. Special quotas for the archive are configured at creation to help manage the growth of the archive data. By default, the archive quotas are set to unlimited. The personal archive was created to eliminate the need for.pst files by allowing users to keep historical data within the Exchange database rather than on their local computers. By bringing the archive data back into the Exchange database, users and administrators can manage this data with features like retention policies and legal holds, they can recall the data easily with multimailbox search, and this data can now be protected by native Exchange processes. If you plan to use a recovery database in your environment, you must allocate sufficient capacity for all the databases you plan to recover per server. 15

The transaction log files maintain a record of every transaction and operation performed by the Exchange 2010 database engine. Transactions are written to the log first then written to the database. The message size and I/O profile (based on the number of messages per mailbox per day) can help estimate how many transaction logs are generated per day. Table 10 provides guidelines for estimating how many transaction logs are generated for a 75K average message size. Table 10. Number of Transaction Logs Generated per I/O Profile for 75K Average Message I/O Profile Transaction Logs Generated per Day 50 10 100 20 150 30 200 40 250 50 300 60 350 70 400 80 450 90 500 100 As message size increases, the number of logs generated per day grows. According to Microsoft, if your message size doubles to 150K, the logs generated per mailbox increases by a factor of 1.9. If the message size doubles again to 300K, the factor of 1.9 doubles to 3.8, and so on. Consider these additional factors when determining transaction log capacity: Backup and restore factors Move mailbox operations Log growth overhead High availability factors If you plan to include lag copies in your Exchange environment, you must determine capacity for both the database copy and the logs. The log capacity requirements depend on the delay and usually require more capacity than the non-lagged copy. For more information about calculating capacity requirements, see the Microsoft TechNet article Understanding Mailbox Database and Log Capacity Factors. You can download Microsoft s Exchange 2010 Mailbox Server Role Requirements Calculator from the Microsoft Exchange Team Blog. 16

RAID Group and LU Design This reference architecture uses enterprise-class 600GB 15K SAS drives in the Hitachi Adaptable Modular Storage 2500. Mid-tier drives (in the 7200RPM range) can be used for Exchange 2010 as long as the number of spindles can satisfy Exchange s I/O requirements. The 2500 can house both SAS (serial-attached SCSI) and SATA (serial ATA) drives. The decision about which type to use also depends on the I/O and capacity requirements of the Exchange environment. Hitachi Data Systems recommends using RAID-1+0 or RAID-5 for the Exchange 2010 workload. RAID-1+0 is the preferred RAID configuration for both enterprise and mid-tier drives because it offers the best of both performance and reliability, however, it is not always the most cost-effective configuration. RAID-5 still offers reliability but because of the write penalty associated with this RAID type, it is not the best performance option. RAID-5 does offer better capacity utilization and is therefore more cost effective. Due to the lower I/O requirements of Exchange 2010 and the features of the Hitachi Adaptable Storage 2000 family, a RAID-5 configuration is more than adequate to meet the I/O requirements for this reference architecture. Hitachi Dynamic Provisioning software is used in this reference architecture and Hitachi Data Systems recommends using it for all Exchange 2010 implementations. Separate the database and log LUs into different pools.. Based on the testing that Hitachi has performed for the Exchange Solution Reviewed Program (ESRP) v3.0, size the LUs for the Exchange databases to be about 2TB in size. Databases of this size perform with average response times under 20ms, which is the metric that Microsoft uses as a success factor in its Jetstress Tool. For more information about ESRP submissions from Hitachi, see the Engineering Validation section. Processor and Memory Design Designing an Exchange 2010 implementation requires consideration of processor and memory requirements for your mailbox servers. Processor Capacity Planning With the release of Exchange 2010, Microsoft has new processor configuration recommendations for servers that host the mailbox role. This is due to the implementation of mailbox resiliency. It is now based on two factors: whether the server will host both active and passive database copies and the number of database copies. A passive database copy requires CPU resources to perform the following tasks: Check or validate replicated logs Replay replicated logs into the database Maintain the content index associated with the database copy When calculating CPU requirements for a server that will host both active and passive copies, calculate the requirements for the active copies and add 15 percent CPU capacity for each passive database. For each active database copy on a mailbox server, increase the CPU capacity by 10 percent. See Table 11 for Microsoft s guidelines for estimating how many CPU megacycles are needed for each mailbox database. For the reference architecture described in this document, the row describing the profile of 100 messages per day provides the number of CPU megacycles needed for active and passive mailboxes. 17

Table 11. Estimating CPU Megacycles Total MessagesSent or Received per Mailbox per Day Database Cache per Mailbox (MB) Standalone Estimated IOPS per Mailbox Mailbox Resiliency Estimated IOPS permailbox Megacycles for Active or Standalone Mailbox Megacycles for Passive Mailbox 50 3 0.06 0.05 1 0.15 100 6 0.12 0.10 2 0.30 150 9 0.18 0.15 3 0.45 200 12 0.24 0.20 4 0.60 250 15 0.30 0.25 5 0.75 300 18 0.36 0.30 6 0.90 350 21 0.42 0.35 7 1.05 400 24 0.48 0.40 8 1.20 450 27 0.54 0.45 9 1.35 500 30 0.60 0.50 10 1.50 Megacycles equate to megahertz, or one million periods per second. For example, a server with 2 x 4 core Intel Xeon x5470 3.33GHz processors equates to 26,640 megacycles (8 x 3,330MHz). For more information about CPU planning for the mailbox server role, see the Microsoft TechNet article Mailbox Server Processor Capacity Planning. Physical Memory Sizing Memory sizing for the Exchange mailbox server role is critical to reducing the I/O workload presented by the server to the storage platform. Increasing the amount of memory on the mailbox server results in fewer I/Os to the storage system. In Exchange 2010, the log checkpoint depth target is 100MB per database when a database has more than one copy (from 20MB in Exchange 2007). Log checkpoint depth is used to ensure that changes made to the log and database cache are written to the database file in a reasonable amount of time. Because of this, the write I/O for databases with more than one copy can be up to 40 percent less than standalone databases. Subsequently, the checkpoint depth on passive copies is reduced to enable faster recovery from failovers or switchovers. At a minimum, physical memory capacity per server is based on database count (both active and passive). Table 12 shows the required minimum memory requirements per mailbox database as recommended by Microsoft. 18

Table 12. Estimated Minimum Memory Requirements Number of Databases Minimum Physical Memory (GB) 1-10 2 11-20 4 21-30 6 31-40 8 41-50 10 51-60 12 61-70 14 71-80 16 81-90 18 91-100 20 Database Cache An understanding of database cache is necessary for sizing an Exchange 2010 environment from a transactional I/O perspective and also from a physical memory perspective. Determining the size of the mailbox servers helps determine your overall high availability architecture. Use Table 9 to determine the database cache requirements per server based on I/O profile and mailbox count. From Table 9, you can see that you need 6MB of cache per mailbox for a message profile of 100. For this reference architecture, each mailbox server has 1,667 active mailboxes. Adding the second copies, or passive mailboxes, brings the total to 3,334. With a user profile of 100 messages per day, the calculation for database cache is 3,334 x 6MB = 20GB. Table 13 lists the default mailbox database cache sizes according to Microsoft. Use this table to determine the minimum memory requirements per server to ensure the database cache size requirements can be met. Referencing the database cache size column for a server with only the mailbox role installed in Table 13, and using the previous calculation of 20GB, the server needs 32GB of physical memory (rounding up). 19

Table 13. Default Mailbox Database Cache Sizes Server Physical Memory (GB) Database Cache Size for Mailbox Role Only (GB) Database Cache Size for Multiple Roles* (GB) 2 0.5 Not supported 4 1.0 Not supported 8 3.6 2 16 10.4 8 24 17.6 14 32 24.4 20 48 39.2 32 64 53.6 44 96 82.4 68 128 111.2 92 * For example, mailbox plus hub transport and client access roles Engineering Validation This reference architecture is based on the Exchange Solution Reviewed Program (ESRP) submission titled Hitachi Adaptable Modular Storage 2500 Dynamically Provisioned 68,800 User Exchange 2010 Resiliency Storage Solution. The Microsoft Exchange Solution Reviewed Program is a program designed to facilitate third-party storage testing and solution publishing for Exchange Server. It provides a storage testing harness (Jetstress) with solution publishing guidelines. Version 3 is for Exchange Server 2010 storage solutions. Additional Hitachi submissions can be found on the ESRP web site. Test Methodology Exchange Jetstress 2010 is used to verify the performance and stability of a disk subsystem prior to putting an Exchange 2010 server into production. It helps verify disk performance by simulating Exchange database and log file I/O loads. It uses Performance Monitor, Event Viewer and ESEUTIL to ensure that the storage system meets or exceeds your performance criteria. Jetstress generates I/O based on Microsoft s estimated IOPS per mailbox user profiles. Exchange Load Generator 2010 Beta was also used as a simulation tool to test the Database Availability Group feature. LoadGen measures the effect of MAPI, OWA, ActiveSync, IMAP, POP and SMTP clients on Exchange 2010 servers. LoadGen is run on a client computer and sends messaging requests to the Exchange servers, generating a mail load. It is useful for sizing servers and validating a deployment plan. 20

Corporate Headquarters 750 Central Expressway, Santa Clara, California 95050-2627 USA Contact Information: + 1 408 970 1000 www.hds.com / info@hds.com Asia Pacific and Americas 750 Central Expressway, Santa Clara, California 95050-2627 USA Contact Information: + 1 408 970 1000 www.hds.com / info@hds.com Europe Headquarters Sefton Park, Stoke Poges, Buckinghamshire SL2 4HD United Kingdom Contact Information: + 44 (0) 1753 618000 www.hds.com / info.uk@hds.com Hitachi is a registered trademark of Hitachi, Ltd., in the United States and other countries. Hitachi Data Systems is a registered trademark and service mark of Hitachi, Ltd., in the United States and other countries. All other trademarks, service marks and company names mentioned in this document or Web site are properties of their respective owners. Notice: This document is for informational purposes only, and does not set forth any warranty, expressed or implied, concerning any equipment or service offered or to be offered by Hitachi Data Systems. This document describes some capabilities that are conditioned on a maintenance contract with Hitachi Data Systems being in effect and that may be configuration dependent, and features that may not be currently available. Contact your local Hitachi Data Systems sales office for information on feature and product availability. Hitachi Data Systems Corporation 2010. All Rights Reserved. AS-051-00 July 2010