Best Practice of Microsoft Exchange Server 2010 Based on HUAWEI OceanStor 18000 Series Enterprise Storage Systems

Best Practice of Microsoft Exchange Server 2010 Based on HUAWEI OceanStor 18000 Series Enterprise Storage Systems This document describes the best practice of planning and deploying the Microsoft Exchange Server 2010 on HUAWEI OceanStor 18000 Series and the steps to verify the performance of the Exchange Server 2010. This document describes how to design and configure the performance and capacities of storage systems, server CPU, and server memory. Jetstress is used to test the maximal mailbox users that can be supported by the storage systems and servers available so that users can deploy an Exchange on VMware efficiently, with the Exchange performance predictable, to meet enterprise's requirements. Tong Kaiguo tongkaiguo@huawei.com IT Storage Solution SDT, Huawei Enterprise BG 2014-03-24 V1.0 Huawei Technologies Co., Ltd.

Contents 1 Overview... 4 1.1 Description... 4 1.2 Benefits... 4 1.3 Intended Audience... 5 1.4 Terminology... 5 2 HUAWEI OceanStor 18000 Series... 7 2.1 Overview... 7 2.2 Smart Matrix Architecture... 9 2.3 RAID 2.0+ Fully Virtualized Intelligent Volume... 10 2.4 Smart Series Software... 10 2.5 Hyper Series Data Protection Software... 11 2.6 OceanStor DeviceManager... 12 3 Microsoft Exchange 2010... 13 3.1 Roles of Exchange 2010 Servers... 13 3.1.1 Mailbox Server... 13 3.1.2 Mailbox servers perform the following functions:... 13 3.1.3 Mailbox Server Interactions... 14 3.1.4 Services and Executables... 15 3.2 Exchange 2010 Store... 16 3.2.1 Logical Components of the Exchange 2010 Store... 16 3.2.2 File Structure of the Exchange 2010... 16 3.2.3 High Availability and Site Resilience... 17 4 Best Practice Planning... 19 4.1 Descriptions... 19 4.2 Physical Network... 20 4.3 Storage Configuration... 21 4.3.1 RAID Groups Configuration... 21 4.3.2 LUN Configuration... 21 4.4 Configuration Targets... 22 4.5 Test Configuration... 22 4.5.1 Simulated Exchange Configuration... 22 4.5.2 Hardware Configuration... 23 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2

4.5.3 Software Configuration... 23 4.5.4 Storage Configuration of Mailbox Databases... 24 5 Best Practice... 25 5.1 Storage Configuration... 25 5.1.1 Disk Domain Configuration... 25 Disk Type... 26 5.1.2 Storage Pool Configuration... 26 RAID Level... 26 Number of Member Disks in a RAID Group... 27 5.1.3 LUN Configuration... 27 5.1.4 Host and Host Group Configuration... 27 5.1.5 Configuring Port Groups... 28 5.1.6 Mapping View Configuration... 28 5.2 Transaction Performance Planning... 29 5.2.1 Storage Performance Planning... 29 5.2.2 Storage Capacity Planning... 30 5.3 Final Storage Solution... 34 5.4 Mailbox Server Planning... 34 5.4.1 Mailbox Server CPU Planning... 34 5.4.2 Mailbox Server CPU Calculation Capacity Calculation... 34 5.4.3 Mailbox Server Memory Planning... 35 5.4.4 Host Multipathing Configuration... 37 5.4.5 NTFS Allocation Unit Size... 37 5.4.6 HBA Driver... 37 6 Test Results of Best Practice... 38 6.1 Jetstress... 38 6.2 Test Results... 38 6.2.1 Reliability... 38 6.2.2 Storage Performance... 39 6.3 Detailed Test Results... 39 7 Summary... 40 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3

1 Overview Centering on the needs of large- and medium-sized enterprises, the best practice of Exchange based on HUAWEI OceanStor 18000 series enterprise storage systems (the OceanStor 18000 series) describe how to efficiently plan and deploy Exchange services by using the OceanStor 18000. In addition, the practices employ the high database availability group (DAG) of the Exchange 2010 databases to provide high availability and site resilience for email services and data. Lastly, the practice conducts the Exchange Solution Review Program (ESRP) verification with a scale of 9000 mailbox users. The best practice can improve service deployment efficiency and ensure the performance and continuity of Exchange Server 2010 services. 1.1 Description The best practice of Exchange based on the OceanStor 18000 series presents a detailed description of the design and deployment of the Microsoft Exchange on the VMware. The document gives a detailed description of the functions and features of the OceanStor 18000 series and Exchange 2010 in the beginning chapters, followed by the descriptions about how to plan the IOPS performance and capacities of the storage system, server CPU, memory, and multipathing software with 9000 users running on the Exchange 2010. Lastly, the document probes into the verification of service performance and reliability with the best practice applied. With supporting documentation available, the best practice has been verified and can help users efficiently and quickly deploy the Exchange on the VMware and reduce workloads and risks in the planning and deploying stages. 1.2 Benefits With the two models of the OceanStor 18500/18800 available, the OceanStor 18000 series is optimal for an enterprise's core services (that require high reliability and high performance). Geared to the needs of large- and medium-sized enterprises, the best practice of Exchange based on the OceanStor 18000 series is calculable and customizable, protect costumers' investments, and reduce workloads in planning and configuring the system. The best practice presents an open architecture. Users can choose all components recommended, or they choose some of components and deploy them on the OceanStor 18000 series based on the resources available and their budget. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 4

As an indispensable tool is business communication, E-mail enables an enterprise to communicate with its client, potential clients, partners, and suppliers. Nowadays, IT administrators of the Microsoft Exchange are facing the challenges posed by the requirements of high performance and high efficiency. Operating, auditing, protecting, and managing an Exchange environment involving multiple working regions are the demanding challenges to most IT departments. Many enterprises attempt to overcome the bottlenecks by adding physical servers or storage systems, which not only proves ineffective but aggravates the problems. Huawei has secured its position among the top IT basic architecture suppliers in the industry and offers a comprehensive Microsoft Exchange virtual solution that can be deployed efficiently. 1.3 Intended Audience This document is intended for Huawei employees, Huawei partners, and customers. Personnel that deploy this solution are supposed to have met the following requirements: Authorized by Microsoft to sell and install the Exchange solution Authorized by Huawei to sell, install, and configure the OceanStor 18000 series Personnel that deploy the solution must have the know-how to install and configure the following systems: Microsoft Windows Server 2008 R2 Microsoft Exchange Server 2010 the OceanStor 18000 series 1.4 Terminology Table 1-1 Terminology Acronym AD CA DAC DAG DDL DNS ESRP FC IOPS LDAP LUN Full Spelling Active Directory Client Access Server Role Datacenter Activation Coordination Database Availability Group Data Definition Language Domain Name Service Exchange Solution Review Program Fibre Channel Input/Output Operations Per Second Lightweight Directory Access Protocol Logical Unit Number Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 5

Acronym MRM NL-SAS NSPI OAB PAM Full Spelling Messaging Records Management Near Line SAS Name Service Provider Interface Offline Address Book Primary Active Manager POP3 Post Office Protocol 3 RAID RPO SAN SAS SATA SCSI SMTP TCO Redundant Array of Independent Disk Recovery Point Objective Storage Area Network Serial Attached SCSI Serial Advanced Technology Attachment Small Computer System Interface Simple Mail Transfer Protocol Total cost of ownership Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 6

2 HUAWEI OceanStor 18000 Series 2.1 Overview The OceanStor 18000 series enterprise storage systems are ideal storage platforms designed for new-generation data centers. Boasting high reliability, excellent scalability, and outstanding efficiency, the OceanStor 18000 series addresses the mission-critical service storage requirements of various industries, including finance, government, energy, manufacturing, transportation, education, and telecommunication. Figure 2-1 HUAWEI OceanStor 18000 series storage system Secure and Trusted The following describes the highlights of the OceanStor 18000 series. Multi-controller full-redundancy architecture: zero single point of failure and load balancing, ensuring stable system running RAID 2.0+ disk virtualization: no hotspot disk and 20 times faster data recovery, greatly improving data reliability Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 7

Flexible and Efficient Robust Reliability Comprehensive disaster recovery solution: industry's shortest RPO of 0 to 5 seconds and one-click disaster recovery management, protecting business continuity to the maximum Maximum specifications: 1 million SPC-1 IOPS, 16 controllers, 3 TB cache, 7 PB capacity, scalable based on demands, meeting storage requirements in the next 10 years Fastest response: world's only enterprise storage systems that respond in microseconds, delivering 10 times faster service processing Highest efficiency: maximized storage system efficiency, improving storage utilization by three times The OceanStor 18000 series offers incomparable reliability in terms of architecture, data storage, and applications to ensure business continuity. With the Smart Matrix architecture, the OceanStor 18000 series is able to provide 16 fully redundant controllers to maintain system reliability. All the controllers are optically interconnected through PCIe 2.0 to support lossless data exchange among them. All OceanStor 18000 components and channels are redundantly configured so that fault detection, correction, and isolation can be independently carried out on each module or channel without interrupting system services. The OceanStor 18000 series leverages the innovative block virtualization technology to shorten reconstruction time per TB data from 10 hours to 30 minutes, accelerating data reconstruction by 20 times and greatly enhancing data reliability. End-to-end data integrity verification means are implemented based on the Protection Information (PI) technology to prevent data from being damaged. SmartQoS and SmartPartition help critical services get sufficient resources for continuous business running. The Hyper series data protection software executes local and remote protection for customers' data, and ensures business continuity by working with Huawei disaster recovery solutions. PI+DIX end-to-end data protection The OceanStor 18000 series offers the PI+DIX end-to-end data integrity solution to protect data integrity ranging from application systems, host bus adapters (HBAs), storage systems, to disks. The PI+DIX solution prevents silent data corruption and delivers end-to-end data protection. Intensity 9 earthquake resistance The OceanStor 18000 series is the only enterprise storage product that has passed the intensity 9 earthquake resistance test held by the Communication Equipment Earthquake Resistance Performance Quality Inspection and Testing Center, which is under China's Ministry of Industry and Information Technology. The OceanStor 18000 series can prevent faults caused by mechanical vibrations that occur during transportation and operation. Moreover, the OceanStor 18000 series can resist 90% earthquakes in 50 years and ensures zero data loss in case of serious earthquakes. Predictable and manageable SSD lifetime The OceanStor 18800F all-flash enterprise storage system employs the global wear leveling technology to balance the erase frequency of flash cells globally while reducing the erase times of solid-state drives (SSDs) that have little redundant space. The SSD life span is extended as a result. Meanwhile, the OceanStor 18800F provides the unique global anti-wear leveling technology to centralize flash erase operations onto only a few SSDs when most SSDs have reached their wear thresholds, reducing the probability of multi-disk failure to a large degree. The OceanStor 18800F is able to accurately predict Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 8

High Scalability the lifetime of SSDs based on flash erase times, and uses a graphical user interface (GUI) to intuitively show SSD lifetime. The OceanStor 18000 series is highly scalable and supports on-demand capacity and performance expansion. Built on the Smart Matrix architecture, the OceanStor 18000 series can be configured with a maximum of 3216 disks to provide a capacity up to 7 PB. An OceanStor 18000 storage system supports a maximum of 3 TB cache and 192 Fibre Channel or iscsi ports. The 4S expansion technology includes scale-up, scale-out, scale-deep, and scale-in. Scale-up increases storage capacity and performance of controllers. Scale-out enables storage performance to increase linearly with capacity. Scale-deep consolidates third-party storage resources. Scale-in expands performance and capacity of host volumes without adding any hardware resources, and allows the storage system to infinitely adapt to service needs. The OceanStor 18000 series is a distributed multi-controller storage system whose controllers can increase from 2 to 16 non-disruptively with the scale-out technology. A maximally configured OceanStor 18000 storage system consists of eight system bays and two disk bays. Each system bay can house a maximum of 192 3.5-inch disks or 408 2.5-inch disks. Each disk bay can house a maximum of 192 3.5-inch disks. The OceanStor 18000 series offers the disk options of ultrafast enterprise-class SSDs, high-performance enterprise-class SAS disks, and large-capacity NL-SAS disks, as well as the port options of 8 Gbit/s Fibre Channel ports and 10 Gbit/s Ethernet ports used for FCoE and iscsi connections. The OceanStor 18000 series maintains a microsecond-level latency to provide quick response to critical services. 2.2 Smart Matrix Architecture Smart Matrix Architecture The Smart Matrix architecture is exclusively incorporated by the OceanStor 18000 series and enables an OceanStor 18000 storage system to scale up to 16 controllers, 3 TB cache, and 7 PB capacity, breaking the limit of the traditional dual-controller architecture and leading to unprecedented system scalability and availability. PCIe Optical Interconnection Scale-Out Expansion The Smart Matrix architecture adopts PCIe 2.0 to interconnect all controllers in full switch mode and deliver a bandwidth up to 192 GB/s. Each controller integrates front- and back-end ports and global cache, and allows data to be flushed to disks simultaneously from multiple controllers to improve I/O efficiency. The Smart Matrix architecture enables system resources to increase linearly. Controllers of an OceanStor 18000 storage system can online expand to 16 and be deployed in a distributed manner in the data center. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 9

2.3 RAID 2.0+ Fully Virtualized Intelligent Volume New-Generation Intelligent Disk Management Technology Space on all disks in a storage system is divided into chunks. The chunks constitute chunk groups (CKGs), which are divided into extents. The extents then form LUNs. This process enables data to be evenly distributed on disks, greatly improving I/O performance, eliminating hot spot disks, reducing the disk failure rate, and enhancing system reliability. Each disk reserves certain hot spare space. Once a disk is faulty, all the other disks participate in data reconstruction, accelerating data recovery by 20 times and further boosting system reliability. Smart Series Resource Allocation Software The Smart series software provides the OceanStor 18000 series with high efficiency and flexibility. SmarTier automatically optimizes performance and lowers costs. SmartMotion dynamically adjusts data distribution to balance performance and capacity among disks. SmartThin optimizes storage space utilization. SmartQoS controls service quality and prioritize resource demands of critical services. SmartPartition partitions and isolates storage cache, and guarantees cache resources for critical services. SmartVirtualization consolidates heterogeneous storage resources, simplifying storage management and maximizing customers' return on investment (ROI). 2.4 Smart Series Software SmartQoS Service Quality Control SmartQoS classifies I/Os into priority-specific queues according to application priorities. Sufficient storage resources are reserved for I/O queues with high priorities to meet their performance requirements, while a performance upper threshold is set for applications with low priorities to avoid overuse of resources. The execution period of a SmartQoS policy is customizable. SmartPartition Cache Partitioning SmartPartition sets cache partition requirements for critical services, dynamically allocates cache resources to services based on the requirements, and isolates the cache resources between services, preventing unnecessary cache competition and ensuring performance of critical services. SmartTier Intelligent Storage Tiering SmartTier creates different storage tiers based on disk types, analyzes the access frequency of data, and migrates data among tiers based on analysis results. This feature ensures that data is stored in proper storage media, improving system performance and reducing total cost of ownership (TCO). Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 10

SmartMotion Balanced Performance and Capacity Among Disks SmartMotion analyzes the access frequency of data and available capacity on a type of disks, and migrates data among those disks to balance performance and capacity among disks of the same type. This feature eliminates disk hot spots, and improves disk utilization and system performance. In system expansion, SmartMotion reallocates performance and capacity to ensure smooth expansion. SmartThin Optimal Resource Allocation SmartThin allocates storage space on demand and reclaims unused space of typical applications such as VMware, Veritas Storage Foundation, and Windows Server. The space is allocated and reclaimed at a granularity of 64 KB. SmartThin also supports space preallocation for thin LUNs. SmartVirtualization Heterogeneous Storage Virtualization SmartVirtualization consolidates storage resources on a live network by taking control of heterogeneous storage systems to make full use of legacy storage space, reduce management complexity, and maximize customers' ROI. 2.5 Hyper Series Data Protection Software HyperSnap HyperClone HyperReplication/S HyperReplication/A HyperSnap generates snapshots for a source volume of any capacity at specified points in time without interrupting system services. Those snapshots can be used for backup, testing, data mining, and data recovery when the original data is lost by accident. HyperSnap stores only changed data to save storage space. HyperClone generates physical copies (data mirrors) for a primary LUN. After synchronizing and splitting the primary LUN and secondary LUN, users obtain physical copies that are consistent with the primary LUN. A primary LUN in a HyperClone task has a maximum of 16 physical copies, which can be used for different purposes. HyperReplication/S replicates data synchronously from a primary LUN to a secondary LUN on a different storage array. Data is consistent between the primary and secondary LUNs. This feature ensures data availability at disaster recovery sites and achieves zero data loss. HyperReplication/A replicates data asynchronously from a primary LUN to a secondary LUN at a remote site that may be thousands of kilometers away. HyperReplication/A supports a minimum RPO of 5 seconds, minimizing data loss caused by system downtime. The customizable periodic synchronization policy helps mitigate the impact on application and host performance. HyperReplication/CG Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 11

ReplicationDirector HyperReplication/CG allows multiple data volumes that apply the same replication policy to form a consistency group to ensure operation consistency among the data volumes. Huawei OceanStor ReplicationDirector is designed to manage disaster recovery of enterprise data centers. ReplicationDirector incorporates application awareness and value-added features of Huawei storage systems to ensure application data consistency during disaster recovery. This software helps users efficiently configure disaster recovery, easily monitor the running of disaster recovery services, and conveniently perform disaster recovery tests. 2.6 OceanStor DeviceManager Huawei OceanStor DeviceManager is a platform for managing Huawei storage systems. It has the following characteristics: Web-based management interface The software is built in storage systems. Users can log in to its management interface using a web browser. Intuitive navigation Graphical navigation makes operation entries clearly and vividly displayed. Administrators can quickly get started with the software. Simplified storage configuration Centralized configuration entries reduce the procedures and page switching times of storage management tasks. Initial configuration greatly simplifies the process from storage system initialization to storage resource allocation. Intelligent storage system monitoring Various means of event notification allow administrators to initiate active storage management. Classified operations reduce the possibility of misoperations and enhance users' confidence. Performance statistics help administrators find and smash performance bottlenecks. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 12

3 Microsoft Exchange 2010 3.1 Roles of Exchange 2010 Servers Mailbox server A back-end server that hosts mailbox databases and public folder databases Client Access server Handles access protocols, such as Post Office Protocol 3 (POP3), Internet Message Access Protocol 4 (IMAP4), Secure Hypertext Transfer Protocol (HTTPS), and Outlook Anywhere. The Client Access server also hosts Web services. Hub Transport server Handles all mail flow inside the organization Edge Transport server Handles all Internet-facing mail flow and blocks viruses and spam Unified Messaging server Integrates multiple methods of communication and supports the access of multiple types of terminals 3.1.1 Mailbox Server As the most common server role, the Mailbox server role is at the core of an Exchange organization and is closely related to the storage system. Servers on which the Mailbox server is installed are called Mailbox servers. 3.1.2 Mailbox servers perform the following functions: Host mailbox databases Provide e-mail storage Host public folder databases Calculate e-mail address policies Generate address lists and offline address books (OAB) Conduct Multi-Mailbox Searches Provide high availability and site resiliency Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 13

Provide content indexing Provide message records management (MRM) and retention policies 3.1.3 Mailbox Server Interactions The Mailbox server must directly interact with the following: Active Directory Client Access server Hub Transport server Unified Messaging server Microsoft Outlook clients Figure 3-1 Interactions between the Mailbox server and other servers Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 14

1. The Mailbox server uses LDAP to access recipient, server, and organization configuration information from Active Directory. 2. The store driver on the Hub Transport server places messages from the transport pipeline into the appropriate mailbox. The store driver on the Hub Transport server also adds messages from a sender's Outbox on the Mailbox server to the transport pipeline. 3. The Client Access server sends requests from clients to the Mailbox server, and returns data from the Mailbox server to the clients. The Client Access server can also access OAB files on the Mailbox server through NetBIOS file sharing. The types of data that the Client Access server sends between the clients and the Mailbox server include messages, free/busy data, client profile settings, and OAB data. 4. The Unified Messaging server retrieves e-mail, voice mail messages, and calendar information from the Mailbox server for Outlook Voice Access. The Unified Messaging server also retrieves storage quota information from the Mailbox server. 5. Outlook clients inside your firewall can access the Access Client server to send and retrieve messages. Outlook clients outside the firewall can access the Client Access server by using Outlook Anywhere (which uses RPC over HTTP). However, Outlook clients that are viewing or changing public folders can access the Client Access server by using RPC over TCP. 6. The administrator-only computer retrieves Active Directory topology information from the Microsoft Exchange Active Directory topology service. It also retrieves e-mail address policy information and address list information. 7. The Client Access server uses LDAP or Name Service Provider Interface (NSPI) to contact the Active Directory and retrieve users' Active Directory information. 3.1.4 Services and Executables When you install the Exchange 2010 Mailbox server, the service and port executables shown in the follow table are installed and service ports are created. Table 3-1 Services Service Short Name Service Name Associated Executable Port Name MSExchangeIS Microsoft Exchange Information Store Store.exe MSExchangeIS MSExchangeADT opology Microsoft Exchange Active Directory Topology MSExchangeADTopo logyservice.exe MSExchangeAD Topology MSExchangeMailb oxassistants Microsoft Exchange Mailbox Assistants MSExchangeMailbox Assistants.exe MSExchangeMai lboxassistantspo rts MSExchangeSearc h Microsoft Exchange Search Indexer Microsoft.Exchange.S earch.exsearch.exe MSExchangeSea rchports MSExchangeServi cehost Microsoft Exchange Service Host Microsoft.Exchange.S ervicehost.exe MSExchangeSer vicehostports MSExchangeMoni toring Microsoft Exchange Monitoring Microsoft.Exchange. Monitoring.exe MSExchangeMo nitoringports MSExchangeSA Microsoft Exchange System Attendant Mad.exe MSExchangeSA Ports Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 15

Service Short Name Service Name Associated Executable Port Name MSExchangeMail Submission Microsoft Exchange Mail Submission MSExchangeMailSub mission.exe MSExchangeMai lsubmissionports msftesql-exchange Microsoft Search(Exchange Server) Msftesql.exe msftesql-exchan geports MSExchangeTrans portlogsearch Microsoft Exchange Transport Log Search MSExchangeTranspor tlogsearch.exe MSExchangeTra nportlogsearchp orts 3.2 Exchange 2010 Store 3.2.1 Logical Components of the Exchange 2010 Store The primary components of the Exchange store include mailbox databases and public folder databases. These components can reside on a single server, or they can be distributed across multiple servers. Mailbox databases contain the data, data definitions, indexes, checksums, flags, and other information that comprise any public folders in you Exchange organization. Mailbox databases contain data that is private to an individual user and mailbox folders generated when a mailbox is created for that user. A mailbox database is saved as an Exchange database (.edb) file. Public folder databases contain the data, indexes, checksums, flags, and other information that comprise any public folders in your Exchange organization. 3.2.2 File Structure of the Exchange 2010 Exchange 2010 saves data in a specialized set of data files, such as Exchange database (.edb) files, transaction log (.log) files, and checkpoint (.chk) files. Exchange database (.edb) files These files are the repository for mailbox data. They can be accessed by the Extensible Storage Engine (ESE) directly and have a B-tree structure designed for quick access. This enables a user to access any page of data within one input/output cycle. The access speed increases by four folds compared that of the Microsoft Exchange Server 2007. Exchange databases consist of multiple B-trees and ancillary trees that used to store indexes and views. Transaction log (.log) files These files are the repository for database operations such as creating or modifying a message. Committed operations are later written to the database itself (in an.edb file.)the approach guarantees that all complete and incomplete transactions are logged to maintain data integrity in case of a service interruption. Checkpoint (.chk) files Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 16

When a checkpoint occurs, the dirty data (committed data changes) in the memory is forcibly written into a database file. Checkpoint (.chk) files store information that indicates when a transaction is successfully saved to the database files on the hard disk. Exchange 2010 uses checkpoint files to allow an instance of the ESE to automatically replay log files into an inconsistent database when recovering from a service interruption, starting with the next unwritten transaction. 3.2.3 High Availability and Site Resilience Mailbox databases are one of the most critical components of any Exchange organization. In Microsoft Exchange Server 2010, you can protect mailbox databases and the data they contain by configuring your mailbox databases for high availability and site resilience. Exchange 2010 reduces the cost and complexity of deploying a highly available and resilient messaging solution while providing higher levels of end-to-end availability and supporting large mailboxes. Building on the native replication capabilities introduced in Exchange 2007, the new high availability architecture in Exchange 2010 provides a simplified, unified framework for high availability and site resilience. Database Availability Groups Active Manager A DAG is the base component of the high availability and site resilience framework built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that hosts a set of databases and provides automatic database-level recovery from failures that affect individual databases. Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. Exchange 2007 introduces a built-in data replication technology called continuous replication. Continuous replication, which was available in three forms: local, cluster, and standby, significantly reduced the cost of deploying a highly available Exchange infrastructure, and provided a much improved deployment and management experience over previous versions of Exchange. Even with these cost savings and improvements, however, running a highly available Exchange 2007 infrastructure still required much time and expertise because the integration between Exchange and Windows failover clustering wasn't seamless. In addition, customers wanted an easier way to replicate their e-mail data to a remote location, to protect their Exchange environment against site-level disasters. Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework called a database availability group (DAG). After servers are added to a DAG, you can add replicated database copies incrementally (up to 16 total), and Exchange 2010 switches between these copies automatically, to maintain availability. Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, and Unified Messaging), providing full redundancy of Exchange services and data with just two servers. This new high availability architecture also provides simplified recovery from a variety of failures (disk-level, server-level, and datacenter-level), and the architecture can be deployed on a variety of storage types. Microsoft Exchange Server 2010 includes a new component called Active Manager that provides functionality that replaces the resource model and failover management features. The Active Manager has two roles: Primary Active Manager (PAM) and Standby Active Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 17

Manager (SAM). PAM is the Active Manager in a DAG that decides which copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures. The SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange that are running an Active Manager client component. The SAM detects failures of local databases and the local Information Store. It reacts to failures by asking the PAM to initiate a failover. In Exchange 2010, the Microsoft Exchange Replication service periodically monitors the health of all mounted databases. In addition, it monitors ESE for any I/O errors or failures. When the service detects a failure, it notifies Active Manager. Active Manager then determines which database copy should be mounted and what it requires to mount that database. In addition, it tracks the active copy of a mailbox database and provides the tracking results information to the Client Access server. Datacenter Activation Coordination Mode The Datacenter Activation Coordination (DAC) mode is designed for a DAG that covers two sites. The DAC mode can control the DAG activation behaviors in case of a catastrophic failure. Consider the two-datacenter scenario. Suppose there is a complete power failure in the primary datacenter. In this event, all of the servers and WAN are down, and the organization decides to activate the standby datacenter. In almost all such recovery scenarios, when power is restored to the primary datacenter, WAN connectivity is typically not immediately restored. This means that the DAG members in the primary datacenter will power up, but they will not be able to communicate with the DAG members in the activated standby center, which would cause data divergence. The DAC can address this problem. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 18

4 Best Practice Planning 4.1 Descriptions The best practice can be employed by large and medium-sized enterprises that plan to deploy Microsoft 2010 on OceanStor 18000 series and use the Exchange 2010 DAG function. The purpose of the best practice is to use the OceanStor 18000 series to support an Exchange 2010 environment where 9000 mailboxes can be deployed as well as provide outstanding performance and flexibility for existing and future Exchange users. In a scenario where the best practice is employed, 9000 mailboxes are deployed on a site-crossing DAG which contains two Exchange mailbox servers. As shown in Figure 4-1, the two Exchange mailbox servers are deployed at two different sites. Each database contains two copies: DB1 and DB2. One copy is saved at the local site, and the other one is a copy of the first copy and is saved on the server of the standby site. When the DAG is running properly, 4500 active users and 4500 passive users are deployed on each Exchange Mailbox server, and each Exchange Mailbox server can support another 4500 active users that are transferred to it in case of server error or server maintenance. Each user can have 1 GB-sized mailbox and can process (send and receive) up to 100 emails each day (supposing that the average size of emails is 75 KB). Figure 4-1 Mailbox Server DAG Exchange Mailbox Server 1 Exchange Mailbox Server 2 Active database Passive database Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 19

4.2 Physical Network The basic architecture of the best practice consists of the VMware host cluster, OceanStor 18000 series, network switches, virtual machines (VMs) that are used to deploy Exchange, and other supporting components. This document describes how to design and deploy Exchange 2010 based on the best practice. The best practice employs three HUAWEI RH2288 servers to deploy the VMware ESXI 5.0 host cluster and store VMware VMs' data in OceanStor 18000 series. Servers are connected to the storage using 8 GB FC SAN, and GE network ports are used in the cluster network, service network, and management network. The best practice does not specify the models of servers and network switches as long as they can meet the performance requirement. The best practice contains SAN, cluster network, service network, and management network. IP SAN and FC SAN as well as GE and 10GE Ethernet can be used. Figure 4-2 shows the physical networking. Figure 4-2 Physical network diagram OceanStor 18800 Before completing the networking, ensure that servers, network switches, Fibre Channel switches, and storage systems have been released. Connect the cables properly to power up the devices. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 20

4.3 Storage Configuration 4.3.1 RAID Groups Configuration The OceanStor 18000 series use RAID 2.0+ full virtualization smart disks. 48 600 GB 2.5-inch 10K RMP SAS disks are configured in the best practice, and a disk domain consisting of 24 disks is created on engine 0 and engine 1. The following table describes the configurations of system volumes, data volumes, and log volumes. Table 4-1 Configuration of Exchange 2010 resource pools Storage Pool RAID Level StoragePool_ExchangeDB_001 RAID 6 StoragePool_ExchangeDB_002 RAID 6 StoragePool_ExchangeLog_001 RAID 6 StoragePool_ExchangeLog_002 RAID 6 StoragePool_ExchangeOS_001 RAID 6 Disk Type 10k RPM SAS 10k RPM SAS 10k RPM SAS 10k RPM SAS 10k RPM SAS Disk Capacity Resource Pool Capacity 600 GB 8600 GB 600 GB 8600 GB 600 GB 250 GB 600 GB 250 GB 600 GB 100 GB Mailbox databases are deployed on StoragePool_ExchangeDB_001 and StoragePool_ExchangeDB_002, and mailbox transaction logs are deployed on StoragePool_ExchangeLog_001 and StoragePool_ExchangeLog_002, with Mailbox server operating systems deployed on StoragePool_ExchangeOS_001. 4.3.2 LUN Configuration Table 4-2 LUN configuration Owning controller Database Distributed evenly on four controllers Transaction Log Distributed evenly on four controllers LUN capacity 2150 GB 120 GB Number of LUNs 4 4 Stripe depth 128 KB 128 KB Read policy No prefetch No prefetch Write policy Write back and mirror Write back and mirror Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 21

4.4 Configuration Targets The solution comes with the following features: 9000 active users Each user processes (receives and sends) 100 emails each day with the email size averaging 75 KB and IOPS being 0.1 (which is 0.12 in the test). The size of each mailbox is 1 GB (500 MB is used in the test). Two Exchange Mailbox servers, with 4500 active users and 4500 passive users running on each server. (Only one server on which 9000 active users are running is tested.) Each mailbox database has two duplicates, and the local DAG replication mechanism is used. 24/7 background database maintenance (BDM) is enabled. Two HUAWEI OceanStor 18000 storage systems are used. (Two Mailbox servers are connected to on the HUAWEI OceanStor 18000 in the test.) 4.5 Test Configuration 4.5.1 Simulated Exchange Configuration Table 4-3 Simulated Exchange configuration Attribute Value Number of Exchange mailboxes 9000 Number of DAGs 1 Number of Mailbox servers on each DAG Number of active mailboxes on each server Number of databases on each Mailbox server 2 (Only 1 in the test) 4500 (9000 users in the test where Jetstress is used) 4 Number of database copies 4 Number of mailboxes on each database 2250 User IOPS Capacity of a database LUN Capacity of a log LUN 0.10 (0.12 in the test where Jetstress is used) 2 TB 120 GB Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 22

4.5.2 Hardware Configuration Table 4-4 Hardware Configuration Component Storage front-end connection (Fibre Channel or iscsi) Storage model and operating system version Cache Description Fibre Channel OceanStor 18800 V100R001C00 192 GB (on controller) Number of storage controllers 4 Number of storage front-end ports Maximal bandwidth between the storage systems and hosts HBA model 16 (4 on each controller) 32 Gbit/s (4 x 8 Gbit/s Fibre Channel port) Qlogic ALE2562 PCI Express to 8 GB FC Dual Channel Number of HBAs on each server 1 Host type Number of disks HUAWEI Tecal RH2288 V2 with Intel(R) Xeon(R) E5-2640, 2.20 GHz, 96 GB RAM 48(2.5-inch 10k RPM SAS) 4.5.3 Software Configuration Table 4-5 Software configuration Component HBA driver version Description 901.k1.1-14vmw HBA queue depth. 64 Host operating system Microsoft Windows Server 2008 R2 Enterprise Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 23

4.5.4 Storage Configuration of Mailbox Databases Table 4-6 Storage configuration of mailbox databases and transaction logs Attribute Disk type, rotational speed, and firmware version of databases and transaction logs Raw capacity of each disk Description 600 GB SAS 10k RPM 2.5 inch Firmware Hitachi ver A440 600 GB SAS 10k RPM 2.5 inch Firmware Seagate ver 0004 558 GB Number of disks used in the test 48 Storage raw capacity 26784 GB RAID level RAID 6(8+2) Total capacity of databases after disks are formatted Total capacity of transaction logs after disks are formatted 8600 GB (on each Mailbox server) 480 GB (on each Mailbox server) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 24

5 Best Practice Microsoft Exchange Server 2010 is an I/O intensive application, and the I/O loads between Exchange Server 2010 and a storage system fall into the following two categories: random reads/writes of 32 KB data blocks on databases, and sequential writes of data blocks with different sizes (from 512 KB to the size of a log buffer) on transaction logs. 5.1 Storage Configuration In the best practice, the OceanStor 18000 series serves as the base of Exchange. This section describes the best configuration to deploy Exchange 2010 on the OceanStor 18000 series using 2.5-inch 10k SAS disks and Fibre Channel protocols. Basically, it is about the best configuration of allocating storage resources on the storage system for hosts. Log in to the OceanStor DeviceManager following instructions in the OceanStor 18000 release notes and make the following configuration: Figure 5-1 Process of allocating storage resources 5.1.1 Disk Domain Configuration A disk domain is a group of some or all disks in a storage system. These disks are consolidated into one logical domain with reserved hot spare space to provide storage resources for storage pools in a unified manner. The OceanStor 18000 can have one or multiple disk domains. Multiple storage pools can be created using the storage resources of one disk domain. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 25

Disk Type Disks in one disk domain can be of the same or different types (SSD, SAS, and NL-SAS). Faults, performance, and storage resources of one disk domain are separated from those of other domains. The OceanStor 18000 series supports the following disk types: SAS, NL-SAS, SATA, and SSD. It is advisable to deploy Exchange databases and logs on SAS and NL-SAS disks rather than on SATA disks (with lower performance) or SSD disks (with high performance but lower capacities). As 9000 mailbox users are supported in the best practice, databases, logs, and operating systems are deployed on SAS disks to meet the requirements on capacity and relatively higher IOPS. Table 5-1 Disk IOPS Disk Type IOPS 7.2k RPM NL-SAS 50 10k RPM SAS 100 15k RPM SAS 150 5.1.2 Storage Pool Configuration RAID Level A storage pool is a container of storage resources, which are used by all application servers. One storage pool is created based on a specified disk domain, which can dynamically allocate resources to the storage pool. The storage pool provides applications with storage resources that have RAID protection based on the RAID policy of each storage tier. A storage tier is a set of storage media that has similar performance in a storage pool. Storage tiers are used to manage storage media with different performance and provide appropriate storage space for applications that have diversified performance requirements. A storage pool can be divided into several tiers based on the types of disk it contains. When creating a storage pool from a disk domain, you can specify the storage pool's tier, RAID policy, and storage capacity. The OceanStor 18000 series supports RAID 5, RAID 6, and RAID 10. As the capacity tier consists of large-capacity NL-SAS disks, the recommended RAID level is RAID 6 because it provides two parity check mechanisms. In the OceanStor 18000 series, it is advisable to create RAID 6 for SAS disks where operating systems, logs, and mailbox databases are deployed and RAID 10 for NL-SAS disks where mailbox databases are deployed. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 26

Number of Member Disks in a RAID Group Five or nine disks to for a RAID 5 group Six or 10 disks for a RAID 6 group Four or eight disks for a RAID 10 group 5.1.3 LUN Configuration Owning controller The OceanStor 18000 series contains four controllers. It is advisable to distribute all LUNs evenly on the four controllers for load balancing Stripe depth In a RAID 6 group, it is advisable to set the stripe depth of a LUN to 128 KB with the stripe size smaller than or equal to 1 MB. In a RAID 10 group, it is advisable to set the stripe depth of a LUN to 128 KB. Write policy It is advisable to set the write policy to write back and mirror in most scenarios but to write through in scenarios where high demands are imposed on availability and not on performance. Prefetch policy Setting the prefetch policy to no prefetch is recommended. 5.1.4 Host and Host Group Configuration This function allows you to create and manage hosts so that the hosts can use the storage resources allocated by the storage system. To easily manage hosts, you can create a host group, which is similar to VMware cluster management. The best practice of creating hosts and a host group for VDI is as follows: When creating a host, name it after the ESXi host name or the last two parts of the host IP address for easy management and maintenance. When creating a host, set OS to VMware ESX. After creating a host, modify its initiator and add ALUA support. When creating a host group, match it with a VMware cluster and name it after the cluster name for easy management and maintenance. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 27

Figure 5-2 Modifying an initiator 5.1.5 Configuring Port Groups By creating and managing a port group, you allow a specified host group and LUN group to use the ports in the port group to communicate with the storage system. The best practice of creating a port group for Exchange is as follows: Add all ports that are connected to Exchange hosts to a host group for simplified deployment and management. Front-end ports connected to hosts are 8 Gbit/s Fibre Channel ports. It is recommended that each controller has at least two front-end ports for redundancy. 5.1.6 Mapping View Configuration A mapping view enables you to allocate storage resources to hosts and complete the configuration of the storage systems. Figure 5-3 Configuring a mapping view Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 28

5.2 Transaction Performance Planning 5.2.1 Storage Performance Planning Transactional I/O is divided into database volume and log volume I/O. Mailbox databases are random I/Os in small data blocks, and transaction logs are sequential I/Os in small data blocks. After obtaining customer's requests, calculate the storage I/Os required by Exchange. These I/Os contain the I/Os in mailbox database volumes only. Overhead for processing log volume I/Os is very negligibly small because log volume I/Os are sequential, database volumes and log volumes isolated, and a HUAWEI storage system provides write cache. You do not need to consider the log volume I/Os when planning storage. For details, see Understanding Database and Log Performance Factors. You can use the following formula to calculate the database volume I/Os: IOPS required by Exchange = Number of mailbox users x IOPS of each mailbox x 1.2 Microsoft recommends that you add a 20% I/O overhead factor to the IOPS you obtained to reserve some capacity. The two most important factors that can be used to predict Exchange 2010 mailbox IOPS are database cache size of each mailbox and the number of daily incoming/outgoing mails of a user. For details, see Understanding the Mailbox Database Cache. You can refer to the following table for the estimate of the IOPS of each mailbox in the preceding formula for calculating IOPS required by Exchange. Table 5-2 Mail activity-based database cache and IOPS estimate of each mailbox Number of Mails Sent/Received y Each Mailbox (With Mail Sizes Averaging 75 KB) Database Cache of Each Mailbox (MB) A Single Database Copy (Independent): IOPS Estimate of Each 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 Multiple Database Copies (Database Recovery): IOPS Estimate of Each Mailbox For reasons of the IOPS different between a single database copy and multiple database copies, see Improved Database Effectiveness on Understanding the Mailbox Cache. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 29

Calculating RAID Overhead A HUAWEI storage system supports multiple RAID levels, with the overhead for processing write I/Os varying between RAID levels. The ration of I/O reads and writes on Exchange 2010 is 6:4. After obtaining the IOPS required by Exchange, you can calculate the required total IOPS of all disks on different RAID levels by using the following formulas: RAID10: Total IOPS of all disks = IOPS required by Exchange x 0.6 + 2 x (IOPS required by Exchange x 0.4) RAID 5: Total IOPS of all disks = IOPS required by Exchange x 0.6 + 4 x (IOPS required by Exchange x 0.4) RAID 6: Total IOPS of all disks = IOPS required by Exchange x 0.6 + 6 x (IOPS required by Exchange x 0.4) Calculating the Number of Disks Required After calculating the total IOPS of all disks based on the RAID level you choose, you can calculate the number of disks that can meet Exchange IOPS requirements by using the IOPS of a single disk and the following formula: Number of disks required = Total IOPS of all disks/iops of a single disk Calculating the Capacity Required by 9000 Mailbox Users in the Best practice 1. Calculate the IOPS required by Exchange IOPS required by Exchange = 9000 x 0.10 x 1.2 = 1080 2. Calculate RAID overhead After calculating the RAID overhead, calculate the required IOPS of disks. Required IOPS of disks = 1080 x 0.6 + (1080 x 0.4) = 3240 3. Calculated the number of disks required (in RAID 6) If 7.2k RPM NL-SAS disks are chosen, the number of disks required = Total IOPS of all disks/iops of a single disk = 3240/50 = 65 If 10k RPM SAS disks are chosen, the number of disks required = Total IOPS of all disks/iops of a single disk = 3240/100 = 33 5.2.2 Storage Capacity Planning Planning the storage capacity of the Mailbox Server is one of the most important tasks in planning the Exchange 2010 Mailbox Server. You must plan the capacities of mailbox data and logs properly. The following table displays the reference capacity values of disks (after being formatted) with different types on the HUAWEI OceanStor T Series storage systems. Table 5-3 Reference capacity values of disks with different types Disk type Post-Formatting Capacity Coffer Disk Non-coffer Disk 300 GB SAS 273.833 GB 278.833 GB 600 GB SAS 529.348 GB 558.348 GB 900 GB SAS 806.799 GB 837.799 GB Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 30

On the HUAWEI OceanStor T series storage system, the first four disks serve as the coffer disks, and a small amount of capacity in the coffer disks is allocated for storing the configuration information of the storage system. Planning Mailbox Database Capacity You must consider the following factors when planning the capacity of Exchange Server 2010 Mailbox database: mailbox storage quota, white space in the database, deleted item retention window, mailbox size, content indexing, database size, and database growth overhead. Calculating the mailbox size In addition to the mailbox capacity quota, the mailbox size also includes the size of white space and dumpster. For details, see Understanding Mailbox Database and Log Capacity Factors. You can use the following formula to calculate the mailbox size: Mailbox size = Mailbox quota size + White space size + Dumpster size White space size = Daily incoming and outgoing mail x average mail size Dumpster size = (Daily incoming/outgoing mail x average message size x deleted item retention window) + (mailbox quota size x 0.012) + (mailbox quota size x 0.03) Deleted items on Exchange 2010 are stored for 14 days. Each database contains a dumpster that stores soft-deleted items. In addition, Exchange 2010 also includes the ability to prevent the purging of data before the deleted item retention period passed. This functionality is called single item recovery. Single item recovery is disabled by default. However, when single item recovery is enabled, the mailbox size increases by 1.2% for a 14-day deleted item retention period. For calendar version logging data, there is an additional 3% increase in the size of the mailbox. Calendar version logging is enabled by default. Calculating mailbox database size Mailbox database size is determined by the number of mailboxes deployed on the database. Use the following formula to calculate the mailbox database size: Mailbox database size = Mailbox size x Number of Mailboxes deployed on the database x 1.2 Microsoft recommends that you add a 20% increase in database overhead when calculating mailbox database size. This is because you may not be able to see all of the data residing in the database when calculating mailbox size and white space size. Calculating LUN size used in database deployment Exchange 2010 creates an index (occupying 10% of the total database size) that resides on the same LUN with the database. Therefore, you need to consider a 10% increase in the database LUN size to store content indexing. Formula for calculating the database LUN size: Database LUN size = Mailbox database size x 1.1/(1-0.2) The storage system will generate alarms when the utilization rate of LUN capacity exceeds 80%. This is the reason why 20% of the space is reserved. Calculating the total database storage capacity Formula for calculating the total database storage capacity: Total database storage capacity = Database LUN size x Number of database copies Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 31

Planning Log Capacity The transaction log files record every transaction performed by the database engine. All transactions are written into logs first, and then lazily written into the database. A database will dismount if the log capacity associated with it becomes insufficient. The transaction log file size on Exchange 2010 has decreased to 1 MB. Consider the following factors when planning Exchange 2010 transaction log capacity: number of log files generated in each mailbox, log cache retention window, move mailbox operations, log growth overhead, and high availability. Capacity of the logs generated by a mailbox per day The number of log files generated by each mailbox is determined by the number of daily incoming/outgoing mails and average mail size. Refer to the following table for the number of log files generated by a mailbox per day. Table 5-4 Number of log files by a mailbox with different loads Mails Received/Sent Per Mailbox Per Day (Mail Sizes Averaging 75 KB) Number of Log Files Generated by Each Mailbox Per Day 50 10 100 20 150 30 200 40 250 50 300 60 350 70 400 80 450 90 500 100 When the average mail size reaches twice of 75 KB, the logs generated by each mailbox will increase by 1.9 folds. When the mail size exceeds twice of 150 KB, there will a 3.8-fold increase in the logs generated by each mail box. Log cache retention window Log cache retention window determines how often (in days) log truncation operations are performed. Log cache retention window is partially dependent on the backup design and restore design. If your design allows to go back two weeks and replay all logs generated since then, you will need the space to store two weeks of log files. If you plan to use the mailbox resiliency and single item recovery functions as your backup infrastructure (and thus enabling circular logging), the best practice is that you allocate three times the required daily log generation capacity without log truncations. This ensures that, when replication is suspended or not functioning under normal parameters, the databases do not dismount due to truncation failures. Move mailbox operations Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 32

Many large companies move, on a nightly or weekly basis, a specific percentage of user mailboxes to different database, servers, or websites. When mailboxes are being moved, all transfer data is written into transaction logs on the target server, and size of the log capacity is the same as that of the source capacity. Therefore, you need to allocate extra capacity for logs LUNs to support move mailbox operations. Log growth overhead For most deployments, Microsoft recommends that you add an overhead factor of 20% to the log size when creating the log LUN to ensure necessary space exists in case of unexpected logs generation. High availability factors Log capacity of the entire system increases based on the number of database copies chosen in the high availability deployment. You need to provision the same log capacity for each database copy. Calculating log LUN size You can use the following formula to calculate the size of a single log LUN: Log LUN size = (Number of log files generated by a mailbox per day x 1 MB x Number of mailboxes) x Log cache retention window + Move mailbox extra capacity) x 1.2/(1-0.2) Move mailbox extra capacity = Percentage of moved mailboxes x Number of mailboxes x Mailbox size The storage system will generate alarms when the utilization rate of LUN capacity exceeds 80%. This is the reason why 20% capacity space is reserved. Calculating total log capacity After calculating the log LUN size, use the following formula to calculate the required total log capacity: Total log capacity = Log LUN size x Number of database copies Calculating the Capacity Required by 9000 Mailbox Users in the Best practice 1. Calculating the mailbox size White space size = 100 x 75/1204 MB = 7.32 MB Dumpster size = 100 x 75/1024MB x 14 days + 1024 x 0.012 + 1024 MB x 0.03 = 145.55 MB Mailbox size = 1024 + 7.32 + 145.55 = 1176.87 MB 2. Calculating mailbox database size Mailbox database size = 1176.87 x 9000/1024 GB x 1.2 = 12412.30 GB 3. Calculating database LUN size Database LUN size = 12412.30 x 1.1/(1-0.2) = 17066.91 GB 4. Calculating log LUN size Log LUN size = 20 x 1 MB x 9000 x 3 x 1.2/0.8/1024 GB = 791 GB 5. Calculating total storage LUN size Total LUN size = Database LUN size + Log LUN size = 17066.91 GB + 791 GB = 17857.91 GB The test for the best practice is conducted on one server and one storage system with the purpose of verifying the DAG of cross-site database on Exchange. When calculating storage capacity, you need to consider only one database copy. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 33

5.3 Final Storage Solution Considering storage I/O requirements, capacity requirements, the number of Mailbox Servers, and storage features, the final storage solution chooses 600 GB 10k RMP SAS disks to deploy databases and logs with RAID 6. In RAID 6, 33 600 GB 10k RPM SAS disks can meet the performance requirement of 9000 mailbox users. 9000 mailbox users require 17857.91 GB capacity, and the final storage solution chooses 48 600 GB 10k RPM SAS disks that can provide 18022 GB capacity and 2070 GB hot spare capacity. 5.4 Mailbox Server Planning 5.4.1 Mailbox Server CPU Planning Plan the mailbox server performance based on the performance requirement of each mailbox user. Microsoft provides the CPU and memory estimates based on message activity, as shown in the following table: Table 5-5 Database cache and CPU estimates based on message activity Messages Send or Received Per Mailbox Per Day Database Cache Per Mailbox in Megabytes (MB) Megacycles for Active Mailbox or Stand-Alone Mailbox Megacycles for Passive Mailbox 50 3 1 0.15 100 6 2 0.30 150 9 3 0.45 200 12 4 0.60 250 15 5 0.75 300 18 6 0.90 350 21 7 1.05 400 24 8 1.20 450 27 9 1.35 500 30 10 1.5 You must increase the megacycles per active mailbox by 10 percent for each additional database copy after one active copy. 5.4.2 Mailbox Server CPU Calculation Capacity Calculation The megacycle is an estimate based on Intel Xeon x5470 3.33 GHz processor (2 x 4 core). A 3.33 GHz process core equals the performance throughput of 3300 megacycles. You can Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 34

compare the platform with the server platform tested by Standard Performance Evaluation Corporation (SPEC) to estimate the configuration of other processors. For details, see the results of SPEC CPU2006 on the Standard Performance Evaluation Corporation website. For example, if a server with Intel Xeon E5-2640 2.2 GHz process (2 CPU x 8 cores) is deployed, the result of SPECint_rate2006 is 464, and the value per core is 29 (value per core on the new platform in the formula). The SPECint_rate2006 result of the baseline Intel Xeon x5470 3.33 GHz processor (2CPU x 4 cores) is 150, and the value per core is 18.75 (baseline value per core in the formula). Use the following formula to calculate the adjusted megacycle of the server used in the solution: (Value per core on the new platform x Hz per core on the baseline platform)/baseline value per core = The adjusted megacycle per core Perform the following operations to determine the server CPU requirements: 1. Plan the number of servers. 2. Calculate the maximum number of active mailboxes that can be supported by each mailbox server based on the activation model. 3. Calculate the CPU requirement of the active mailbox. 4. Calculate the CPU requirement of the passive mailbox server based on the fault model. After a server is down, the worst result can be that there is no passive mailbox. 5. Add the CPU required by active mailbox servers to the CPU required by passive mailbox servers to get the total CPU requirement, and apply the total CPU requirement to a hardware platform. It is advisable set the CPU usage threshold of the independent server (without faults) to 70% or lower in peak hours. As for the three-node Mailbox server that allows only one faulty node, it is advisable to set its CPU usage threshold to 80% or lower in peak hours (when a node is down). In the best practice, the mailbox server chosen by 9000 mailbox users is configured with a 16-core Intel Xeon E5-2640 2.2 GHz CPU processor. 5.4.3 Mailbox Server Memory Planning The memory configuration of Exchange Server role includes the memory configuration of Mailbox Server and Client Access Server. To ensure that there is sufficient memory for ESE database to run properly, the physical memory volume of each database count-based server must meet the minimum requirement. The minimum requirement applies to both active and passive database copies. The following table lists the minimum memory requirements of a Mailbox Server. Table 5-6 Minimum memory requirement of a Mailbox Server Database Count Minimum Physical Memory of Exchange 1-10 2 GB 11-20 4 GB 21-30 6 GB 31-40 8 GB 41-50 10 GB 51-60 12 GB 61-70 14 GB Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 35

71-80 16 GB 81-90 18 GB 91-100 20 GB The Mailbox Server memory configuration is equal to the memory the mailbox consumes in real time or the maximum memory supported by Exchange Server role, whichever is greater. After the database cache is determined, you need to determine the minimum memory requirement of each server to ensure that the memory can meet the requirement of database cache. You must take into account the database cache when adjusting the memory requirement of a server to ensure, so that the physical memory of a server can meet the requirement of the number of mailboxes when the number of user's configuration files is fixed. The following table describes the default mailbox cache size on a single mailbox server role and multiple mailbox server roles: Table 5-7 Default mailbox database cache size Server Physical Memory (RAM) Database Cache Size (Only Mailbox Server Role) Database Cache Size (Multiple Server Roles) 2 GB 512 MB Not Supported 4 GB 1 GB Not Supported 8 GB 3.6 GB 2 GB 16 GB 10.6 GB 8 GB 24 GB 17.6 GB 14 GB 32 GB 24.4 GB 20 GB 48 GB 39.2 GB 32 GB 64 GB 53.6 GB 44 GB 96 GB 82.4 GB 68 GB 128 GB 111.2 GB 92 GB Perform the following operations to determine the server memory requirements: 1. Multiply the number of mailboxes by user's configuration file-based memory requirement to obtain the required database cache size. 2. Determine the required physical memory by determining the database cache that can be provided by the server configuration. 3. In the best practice, 32 GB memory is configured in the server that is required by 9000 mailbox users. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 36

5.4.4 Host Multipathing Configuration The best practice provides storage resources on an FC SAN architecture, and the optical switches that provide redundancy also provide multiple paths between the host and storage. This makes multipathing software necessary for choosing the optimal path. It is advisable to run the following commands on each ESXi host that is connected by SSH to bear virtual desktops. esxcli storage nmp satp rule add --satp=vmw_satp_alua --vendor= HUAWEI --description OceanStor 18000 esxcli storage nmp satp set --default-psp=vmw_psp_fixed --satp VMW_SATP_ALUA reboot Because Huawei storage's multipathing software for VMware ESXi is being certified by VMware, the best practice uses the ALUA protocol that adapts to the VMware multipathing software. 5.4.5 NTFS Allocation Unit Size The page size of Exchange 2010 is 32 KB. The NTFS allocation unit size must be larger than 32 KB. In a real-world scenario, it is advisable to set the NTFS allocation unit size to 64 KB. 5.4.6 HBA Driver Obtain the latest driver from the HBA manufacturer. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 37

6 Test Results of Best Practice This chapter describes the ESRP test results of the solution. You can find the detailed ESRP test report in HTML in the attachments of this PDF file. This solution uses Microsoft Jetstress 2010 for verification to ensure that the storage design meets disk I/O and capacity requirements. 6.1 Jetstress Exchange Server Jetstress 2010 simulates database-level Exchange I/Os by directly interacting with the ESE (also known as Jet, the constructing basis of Exchange) databases. You can use Jetstress to test the maximum I/O throughput of disk subsystems, receive the configuration file of the number of users and I/O of each user per second, and verify that the disk subsystem can use the configuration file to maintain an acceptable performance level. Before deploying Exchange, use Jetstress to test the storage reliability and performance. Exchange Server Jetstress 2010 generates a test report for every test. The test report contains a high-level passed/failed indicator, which can be used to determine whether values of other test reports can be used in adjusting server size or pre-deployment verification. For details about Jetstress, see Microsoft Exchange Server Jetstress 2010. 6.2 Test Results 6.2.1 Reliability A 24-hour performance test using Jetstress is conducted to verify the storage reliability. (You can find the detailed test results in the attachments.)this test is to ensure that the storage can process high-load I/Os stably for a long time. After the test is complete, log files and database files are analyzed to ensure that there is no database or log error. The test results indicate: No error occurs in the saved event log files. No error occurs in the database or log verification project. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 38

6.2.2 Storage Performance The primary storage performance test takes two hours to verify the storage's ability of supporting Exchange I/Os. The criteria of the test are that the read latency cannot exceed 20 milliseconds and the IOPS cannot be lower than 0.5% of the target value. The following two sections provide the IOPS and average latency in a two-hour test. The test reports of server databases and transaction logs as well as the total of two servers are displayed. The following table lists the total transaction IOPS of all databases on severs, average latency, and the performance value of log files. Table 6-1 Performance of a single server database Database I/O Server Transaction IOPS 10,199.43 Database read IOPS 6714.20 Database write IOPS 3486.23 Database I/O average read latency (Unit: millisecond) 15.72 Database I/O average write latency (Unit: millisecond) 3.22 Table 6-2 Performance of a single server log Transaction Log Transaction log write IOPS 1007.59 Transaction log average write latency (Unit: millisecond) 1.29 6.3 Detailed Test Results The detailed HTML test results are included in the attachments of this document. The test results include: 24-hour performance test 24-hour performance test and database verification test 2-hour performance test 2-hour performance test and database verification test Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 39

7 Summary Best practice of Exchange based on the OceanStor 18000 series provides a verified and virtual platform-based Exchange scenario. The best practice can improve service deployment efficiency and ensure the performance and continuity of Exchange Server 2010 services. The planning and verification results of the best practice indicate that the best practice is an efficient and reliable solution that can be employed by large- and medium-sized enterprises. Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 40

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd. Trademark Notice HUAWEI, and are trademarks or registered trademarks of Huawei Technologies Co., Ltd. Other trademarks, product, service and company names mentioned are the property of their respective owners. General Disclaimer The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and operating results, future product portfolio, new technology, etc. There are a number of factors that could cause actual results and developments to differ materially from those expressed or implied in the predictive statements. Therefore, such information is provided for reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time without notice. HUAWEI TECHNOLOGIES CO., LTD. Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R. China Tel: +86-755-28780808 www.huawei.com Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 41