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

Transcription

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

2 Summary IT administrators need 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.

3 Feedback Hitachi Data Systems welcomes your feedback. Please share your thoughts by sending an message to Be sure to include the title of this white paper in your message.

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

5 Deploying Microsoft Exchange Server 2010 on the Hitachi Adaptable Modular Storage 2500 Reference Architecture Guide IT administrators need 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 For information about deploying other Exchange server roles, see the Microsoft TechNet library Exchange Server 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

6 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

7 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

8 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

9 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

10 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 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

11 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

12 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 GB 15K SAS disks. Table 2 shows the drive configuration for one Table 2. Drive Configuration Drive Slot 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

13 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 Database 19, active Database 20, active Database 21, active Database 25, active Database 26, active Database 27, active Database 31, active Database 32, active 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 Database 18, passive Database 17, passive Database 16, passive Database 24, passive Database 23, passive Database 22, passive Database 30, passive Database 29, passive Database 28, passive 9

14 Server LUN Description Database 36, passive Database 35, passive 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 Database 22, active Database 23, active Database 24, active Database 28, active Database 29, active Database 30, active Database 34, active Database 35, active Database 36, active 4 19 Database 3, passive 5 20 Database 2, passive 6 21 Database 1, passive Database 9, passive Database 8, passive Database 7, passive Database 15, passive Database 14, passive Database 13, passive Database 21, passive 10

15 Server LUN Description Database 20, passive Database 19, passive Database 27, passive Database 26, passive Database 25, passive Database 33, passive Database 32, passive 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 Log 13, active Log 14, active Log 15, active Log 19, active Log 20, active Log 21, active Log 25, active Log 26, active Log 27, active Log 31, active Log 32, active 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

16 Server LUN Description 9 64 Log 10, passive Log 18, passive Log 17, passive Log 16, passive Log 24, passive Log 23, passive Log 22, passive Log 30, passive Log 29, passive Log 28, passive Log 36, passive Log 35, passive 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 Log 10, active Log 11, active Log 12, active Log 16, active Log 17, active Log 18, active Log 22, active Log 23, active Log 24, active Log 28, active Log 29, active Log 30, active Log 34, active Log 35, active Log 36, active 12

17 Server LUN Description 4 59 Log 3, passive 5 60 Log 2, passive 6 61 Log 1, passive Log 9, passive Log 8, passive Log 7, passive Log 15, passive Log 14, passive Log 13, passive Log 21, passive Log 20, passive Log 19, passive Log 27, passive Log 26, passive Log 25, passive Log 33, passive Log 32, passive Log 31, passive The following table describes the port layout on the 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 B 1B C 1C D 1D 13

18 Table 8 lists the port to LU mapping for the Exchange databases and logs. Table 8. Port to LU Mapping Port LUN 0A A B B C C D D 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

19 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

20 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 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

21 RAID Group and LU Design This reference architecture uses enterprise-class 600GB 15K SAS drives in the Hitachi Adaptable Modular Storage 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

22 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 Megacycles equate to megahertz, or one million periods per second. For example, a server with 2 x 4 core Intel Xeon x GHz 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

23 Table 12. Estimated Minimum Memory Requirements Number of Databases Minimum Physical Memory (GB) 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

24 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) Not supported Not supported * 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

25 Corporate Headquarters 750 Central Expressway, Santa Clara, California USA Contact Information: / info@hds.com Asia Pacific and Americas 750 Central Expressway, Santa Clara, California USA Contact Information: / info@hds.com Europe Headquarters Sefton Park, Stoke Poges, Buckinghamshire SL2 4HD United Kingdom Contact Information: + 44 (0) / 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 All Rights Reserved. AS July 2010