General Introduction to Exchange Server 2010 Sizing - Dell · February 2010 . General Introduction to . Exchange Server 2010 Sizing A Dell Technical White Paper . Dell │ Product

February 2010

General Introduction to Exchange Server 2010 Sizing A Dell Technical White Paper

Dell │ Product Group – Enterprise Solutions Rizwan Ali Farrukh Noman Mahmoud Ahmadian

General Introduction to Exchange Server 2010 Sizing

Dell Enterprise Solutions 2

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND. © 2010 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell. Dell, the DELL logo, and the DELL badge, Dell PowerEdge, Dell PowerConnect, Dell PowerVault, Dell EqualLogic, and Dell|EMC are trademarks of Dell Inc. Microsoft, Windows, Windows Server, Microsoft Exchange Server and Active Directory are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.



Contents

Introduction ..................................................................................................... 4

Core Architectural Improvements in Exchange 2010 .................................................. 5

Performance Improvement ................................................................................. 5

Transport Resiliency ......................................................................................... 6

Continuous Availability and scalability ................................................................... 7

Server Roles and Sizing Consideration ..................................................................... 9

Mailbox Server Role .......................................................................................... 9

Client Access Server Role ................................................................................. 11

Hub Transport Server Role ............................................................................... 11

Edge Transport Server Role .............................................................................. 12

Unified Messaging Server Role ........................................................................... 12

Storage Sizing Consideration ............................................................................... 13

Deployment Models .......................................................................................... 14

Simple Distributed Model ................................................................................. 14

Internal Storage Distributed Model .................................................................. 14

External Storage Distributed Model ................................................................. 16

Agile Consolidated Model ................................................................................. 18

Conclusion ..................................................................................................... 21



Introduction Over the years, messaging systems have evolved from providing basic functionality such as e-mail to providing rich collaboration features. The messaging requirements and needs of today’s information worker have also changed significantly from basic desktop e-mail access to collaboration from anywhere with any device. With all the rich integration and archiving requirements, large mailboxes are becoming a requirement in corporate and educational institutions.

In such an evolving environment, IT administrators face an increasingly complex task of administering and maintaining messaging systems. Business requirements such as security, regulatory compliance, and availability further add to complexity. With the increasing storage requirements, Businesses also face the enormous challenge of implementing a suitable messaging system that meets their Total Cost of Ownership (TCO) and Return on Investment (ROI) targets. Microsoft® Exchange Server 2010 with its new performance enhancements is designed to support low cost storage with new high-availability and disaster-recovery model. It incorporates new features that enable businesses to effectively meet their challenges, without fundamentally altering the traditional methods for end users to access e-mail. This whitepaper highlights some of the major architectural improvement and Dell hardware sizing aspects for Exchange Server roles. It also shows how Dell’s innovative hardware portfolio can take advantage of Exchange 2010 enhancements through its cost-effective deployment models.



Core Architectural Improvements in Exchange 2010 Exchange 2010 offers significant improvement over Exchange 2003 and Exchange 2007, and provides a cost-effective solution to overcome challenges of supporting larger mailboxes and personal archives. A number of rich features and functionalities have been added to support business needs. A few core-architectural changes which affect the deployment and sizing strategy are provided below.

Performance Improvement Exchange 2010 has been optimized to take advantage of low cost JBOD storage systems. Using the newly enhanced Exchange Store schema, the IOPS have been significantly reduced compared to Exchange 2007 and Exchange 2003. The database pages in data structures (B-Tree) are stored in more contiguous fashion as opposed to random allocation in previous versions of Exchange. This contiguity has provided a sequential pattern for reads and writes that allows larger I/Os to be fetched efficiently from a disk subsystem. The page size has also been increased from 8KB (in Exchange 2007) to 32KB. Multiple database page operations are coalesced to produce a single large I/O operation. All these factors including larger I/Os and page size have contributed toward reducing the overall IOPS in Exchange 2010. Figure 1 and Figure 2, show comparisons in database IOPs between Exchange 2007 and Exchange 2010. Lower speed and larger capacity drives, like Near-line SAS and SATA which are optimized for sequential rather than random traffic, can now be deployed in Exchange 2010 storage subsystems without any performance issues.

Figure 1: Database Read/Write I/O comparison between Exchange 2007 and Exchange 2010 for 1,000 Heavy Online mailboxes (configuration details follow)

0255075

100

125

150

175

200

Data Reads/secData Writes/sec

Data Transfers/sec

IOPS

Data I/Os comparison

Exchange 2007

Exchange 2010



Configuration Details: • Server hardware– Dell™ PowerEdge™ R710 with two 2.66 GHz Quad-Core Intel® Xeon®

X5550 Processors and 12 GB memory • Storage hardware – Dell PowerVault MD1000 with RAID1/0 LUN (10 x 300 GB 10K drives)

for data and RAID1 LUN (2 x 300 GB 10K drives) for log • Exchange roles – Mailbox server separate, Hub and Client Access roles consolidated on one

server. No DAG clustering. • Client users – 1000 heavy users simulated with Loadgen load simulator tool. Users simulate

Outlook 2007 clients in online mode. Each user performs approximately 132 Outlook operations per 8 hour user day on a 250 MB mailbox.

Figure 2: Database IOPS per mailbox comparison The contiguous allocation of storage data is another factor that helps maintain the reduction of I/Os. To sustain the expected level of performance, Exchange 2010 needs to defragment the database as changes are made. In Exchange 2007, defragmentation was done with right merges, which is opposite of the direction of a normal database read and write I/O pattern. This created an additional penalty and impacted performance further. To preserve contiguity, Exchange 2010 has completely modified the defragmentation process to align with left merging behavior of data reads and writes and thus optimizing the performance.

Transport Resiliency Exchange 2007 introduced the concept of Transport Dumpster for the Hub Transport Server role which maintains a queue of messages delivered to clustered mailboxes. In the event of a failover, the clustered mailboxes request that all Hub servers in the Active Directory site resubmit the messages in their transport dumpster queues to ensure that no in-flight messages are lost. The transport dumpster however only takes care of hops between Hub and Mailbox servers. Exchange 2010 extends this high availability strategy in the transport role to include Edge Servers by introducing Shadow Redundancy. Shadow redundancy ensures redundancy of messages while in transit. Messages in transport databases remain intact until the transport

0

0.05

0.1

0.15

0.2

Exchange 2007 Exchange 2010

IOPS

/mai

lbox

IOPS reduction

Exchange 2007

Exchange 2010

approx. 70% reduction



server verifies that all hops have completed delivery. Shadow Redundancy does not rely on the state of a transport server as long as multiple delivery paths are available. So a transport server may be brought down for upgrades knowing that other transport servers in the topology will have a shadow copy of the messages in flight.

Continuous Availability and Scalability Microsoft Exchange 2010 high availability leverages the cluster technologies in Continuous Cluster Replication (CCR) based on the Majority Node Set (MNS) model of Microsoft Cluster Server (MSCS). A Data Availability Group or a DAG as it is referred to in Exchange 2010, is a group of 2 or more (up to 16 ) servers hosting mailbox databases to provide database level protection and recovery.

The DAG is a vast improvement over the Exchange 2007 two node failover CCR model. In Exchange 2010, a mailbox database can be hosted on any of the servers within the DAG. One or more secondary copies of the same database may be replicated to other servers (for a total of 16 copies) within the DAG. Secondary database copy gets activated in the event of a primary copy failure which allows for a more granular control over failure scenarios.

With Exchange 2007 if a database hosted on a mailbox server failed, it forced the failover of the entire mailbox server resulting in some downtime for all users on that server. In the DAG model provided by Exchange 2010, only users attached to the database in question are affected. Exchange 2010 also provides incremental deployment capability where mailbox servers may be added to the DAG after Exchange is installed and as the needs of the organization grow.

Extending the boundaries of high availability, a DAG can span multiple sites to provide site resiliency. So the term Standby Cluster Replication (SCR) in Exchange 2007 has been deprecated in Exchange 2010 as all database copies can become active automatically within the DAG. Central to the workings of the Exchange 2010 DAG is a new component named Active Manager. It runs on all servers within a DAG and takes either a primary or secondary role depending on which server it is running on. Microsoft Exchange Replication service monitors the Extensible Storage Engine (ESE) on each server and reports faults or errors to Active Manager. Active Manager initiates a switchover in the event a database fault or failover in the instance of a server component failure. The Active Manger client on the Client Access Server (CAS) gets configuration changes from Active Manager so that clients are properly connected to the active copy when a switchover or a failover is complete.

Some of the major architectural differences between Exchange 2003, Exchange 2007 and Exchange 2010 are summarized in Table 1.



Table 1: Exchange 2003, 2007 and 2010 core design comparison Exchange 2003 Exchange 2007 Exchange 2010

Platform 32-bit application based on x86 Platforms

64-bit application based on x64 Platforms

64-bit application based on x64 Platforms

Memory Limited to 4GB system memory

Scaled beyond 4GB. Memory limit based on performance = 32GB

Scaled beyond 4GB. Upper limit defined by maximum memory supported on a server.

Exchange IOPS

Many small random IOPS Many small random IOPS Large sequential and coalesced IOPs

ESE page size 4 KB 8 KB 32 KB

High-availability type

Shared Storage MSCS based Single-copy clustering

Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Standby Continuous Replication (SCR)

Database availability Group (DAG), provides enhanced availability with multiple copies extended to remote sites

Max. Number of HA copies of database

One database copy shared with clustered servers

Two database copies with non-shared model in CCR based clustering

2 to 16 copies Different lag times can be set for HA or DR setup

Failover / Switch-over granularity

Server-level only Server-level only Database level

Transport state

N/A Transport database is stateful and causes loss of data with loss of service

Shadow redundancy – providing guaranteed delivery. Large messages supported without back-pressure.

Client-Access Server role (CAS)

N/A CAS is not a middle-tier. MAPI and WebDAV clients connect directly to Mailbox Server and impacted for longer time during Mailbox failure.

CAS has been modified to make a middle tier solution. All end user connects through CAS server and provide better user experience. It has also removed number of connections limitation on store.



Server Roles and Sizing Consideration Exchange 2010 distributed its functionality through the same five Server roles concept used in Exchange 2007: Mailbox Server, Client-Access Server, Hub Transport Server, Edge Transport Server and Unified Messaging Server. With the new architectural changes and functional design, the sizing guidelines have significantly changed for the core services. The sizing of Exchange 2010 server roles and database storage design depend on the type of configuration and high-availability requirements.

Mailbox Server Role The Mailbox Server role provides the functionality for hosting user mailboxes, public folders, and calendar data. Exchange 2010 introduces the concept of online archiving as a secondary mailbox to eliminate the PST allocation issues. The advanced Exchange Search operation across mailbox data and entire organization provides a better user experience for large mailboxes.

The memory and CPU sizing requirements for a Mailbox Server role depend on the number of mailboxes, type of load profile and high-availability (DAG) configuration. The Hub Transport and CAS roles sometimes can be tied in to a Mailbox Server role in a larger distribution, for greater availability and cost benefit factors. This Multi-role or All-in-One Server configuration consumes some processor and memory utilization for Hub/CAS resources besides the Mailbox requirements. Table-2 shows Dell’s best practice recommendations for sizing a single active copy (no DAG configuration) on a Mailbox Only server or Multi-role (All-in-One) server. These recommendations are based on Exchange Server 2010 performance characterization tests conducted at Dell labs. The user profiles given in the table are defined as follows:

Medium user: 10 send and 40 receive e-mail operations per 8 hour work day

Heavy user: 20 send and 80 receive e-mail operations per 8 hour work day

Very Heavy user: 30 send and 120 receive e-mail operations per 8 hour work day

Table 2: Best practice user Recommendations for Mailbox-Only role and Multi-role on Dell server hardware

Mailbox Only Server Role All-in-One Server Roles

Server Model PowerEdge R610 PowerEdge R710 PowerEdge R610 PowerEdge R710

RAM (2 GB DIMMs) 24 GB 36 GB 24 GB 36 GB

No. of Medium Users 3,600 6,200 2,700 5,200

No. of Heavy Users 2,500 4,500 2,000 3,800

Processors 2 x Dual Cores 2 x Dual Cores

RAM (4 GB DIMMs) 48 GB 72 GB 48 GB 72 GB

No. of Medium Users 8,500 13,800* 7,500 11,800* No. of Heavy Users 6,300 10,000 5,400 8,600

No. of Very Heavy Users 4,300 6,800 3,700 5,900

Processors 2 x Quad Cores 2 x Quad Cores 2 x Quad Cores 2 x Quad Cores



The recommended server models can scale to more than the number of users mentioned in Table 2, by configuring more system memory using 8 GB or 16 GB DIMMs. Dell 1U rack servers like the PowerEdge R610 can have 96GB memory and the 2U servers like PowerEdge R710 can have 144GB memory using 8GB DIMMs. Besides rack server, other form-factor servers like PowerEdge Blade, Tower and dense rack servers are suitable options for deploying Mailbox Server roles. The preceding recommendations are guidelines for choosing an appropriate PowerEdge server for a single copy (no-DAG) environment.

*Note: Even though a large number of mailboxes can be configured with large DIMMs (as shown in Table 2) without any performance issues, Dells recommends not to exceed more than 10,000 users per server for better handling of server failover and database recovery scenarios.

The sizing recommendations for the Mailbox Server role with a multiple copies (DAG) environment is largely affected by the number of active and passive copies in addition to the user profile factor. The active copy bears 15 – 20% additional overhead associated with each passive copy being replicated on a secondary server. Similarly, a passive copy on the residing server consumes 20 – 25% of the single copy CPU cycles. The passive copy utilizes CPU resources to carry out the validation of replicated logs, content indexing tasks, and the replay of logs into the database. In a DAG configuration, the server can be designed and provisioned with copies in two ways: Full-provisioning and Under-provisioning.

Full-provisioning of resources on a server to handle all the passive copies becoming active after failover on this server. This design provides the best availability with higher cost due to full allocation of resources for all copies. Under-provisioning of resources by hosting more passive copies and limiting the number of passive copies to automatically activate on a server after a failover. Such a design is useful in large distributions with large numbers of copies (4 or more per database), where some servers are deployed to handle worst case scenarios after multiple failures in the configuration. With multiple copies, a few copies can be allowed automatic failover and recovery while the remaining copies can be reserved for manual activation based on where the resources are available. Such a model is a good balance between cost and availability and it requires careful planning and designing.

The Exchange 2010 Mailbox user and read write I/Os have been reduced approximately 70% compared to Exchange 2007. There is a further reduction of 10 – 15% in a DAG configuration for active copy compared to a single copy environment. It is mainly due to 100 MB cache allocation for Log Checkpoint Depth in DAG versus 20 MB in single copy. This change allows multiple data operations on database files, which are held longer in cache before writing data to disk, thereby reducing database write IOPS. On the other hand Log Checkpoint Depth for passive copy is reduced to 5MB to accelerate the process of flushing the data to disk which causes an increase in passive copy write IOPS. The passive IOPS are non-transactional and should not impact the performance as long as they are residing on separate LUN.



Client Access Server Role The Client Access Server (CAS) role hosts services and functions required for supporting a variety of mail clients. It hosts functionality for supporting the Outlook Web App, Exchange ActiveSync client access, POP3/IMAP4 client access, Outlook Anywhere (RPC over HTTP) access, and the new RPC service for MAPI clients. The RPC service allows internal Outlook clients to connect to a CAS server instead of directly connecting to a Mailbox Server. This results in a better client experience and negligible delay during Mailbox Server failover. Due to the connectivity through the CAS role, the number of RPC concurrent connections per Mailbox server has also increased, which can be scaled out based on the number of CAS servers in the network configuration. The CAS role also hosts the Exchange Web service and Auto-discover services with some added functionality enhancements in Exchange 2010.

The sizing of the Client Access Server in Exchange 2010 plays an important part with hosting all external services in addition to off loading significant processing from the Mailbox server. The results have shown that the Exchange 2010 CAS Server role has high CPU requirements, which are directly related to the number of internal/external connections and the mailbox user load. The customer should allocate at least two thirds the CPU resources for the CAS server role compared to the Mailbox CPU requirements. The PowerEdge R610 or the PowerEdge R710 is a suitable server platform for hosting the Exchange CAS role and should be properly sized to handle the required Client access functions. The CAS Server role requirements should be linearly scaled out with the number of Mailbox servers and cores in the configuration. A hardware load balancer is deployed with more than one CAS server role to effectively load balance the connections and provide high availability across the configuration.

Hub Transport Server Role The Hub Transport Server role is responsible for handling all internal mail flow across Exchange roles and for the appropriate delivery of user messages. All incoming external SMTP e-mail is forwarded to the Hub Transport Server by the Edge Transport Server role. It provides functionality such as journaling, server side rules, and an additional layer of anti-virus/anti-spam security. Hub server is mandatory to deploy in each Active Directory site containing a Mailbox server role. Since all messages in the Exchange 2010 Organization are routed to and processed by the Hub server, it enables enforcing messaging compliance policies at this server role.

The Hub Transport Server role does not have high processing and memory requirements compared to Client Access Server role. The CPU utilization requirements tend to increase with the message size, the message rate processing and the antivirus configuration on the Hub role. The general recommendation is to have the Hub and Mailbox core ratio of 1:5 with anti-virus configuration and 1:7 without anti-virus scanning on the Hub server. A minimum of two Hub Transport Servers should be deployed to satisfy high-availability requirements. The PowerEdge R610 or the PowerEdge R710 is a suitable server platform for hosting Exchange Hub Transport Server role. The hardware platform should be appropriately sized for the required Hub role functions. Specifically, ample system resources including processors and memory should be allocated if Edge Server role functions such as ant-virus/anti-spam and rule-based policies are configured on the Hub Server role.



Edge Transport Server Role The Edge Transport Server role sits in the perimeter network and provides functionality for routing external SMTP mail flow to and from the Internet. It provides anti-virus/anti-spam protection, filtering capabilities, and rule-based protection. The Edge Transport Server role is not a member of the Active Directory domain and it sits outside the Active Directory framework. It uses the Active Directory Application Mode and EdgeSync to obtain the required Active Directory information for performing its functions.

The sizing of the Edge Transport Server role depends on the number of accepted SMTP connections and message rate. Even though Edge role does not have any significant CPU and memory requirements, ample resources should be available to handle the overhead associated with anti-virus scanning of connections and accepted messages. The PowerEdge R610 or the PowerEdge R710 is suitable platform for hosting Edge Transport role services. A minimum of two servers should be deployed to handle any unexpected failures and server downtime.

Unified Messaging Server Role The Unified Messaging (UM) Server role was introduced with Exchange 2007 to provide the functionality for the integration of voice mail along with e-mail, into user mailboxes. Outlook Voice Access and Auto-attendant were also part of the UM functionality. Exchange 2010 Unified Messaging Server is built on the same model with additional feature enhancements. Features like Voice Mail preview and protection provide added benefit and advantage to the complete solution. The Voice-Mail preview feature enables speech-to-text format to quickly view the voice-mail messages like an e-mail, without listening to all voice-mails. The voice-mail protection feature uses Rights Management Services to set restriction policies and ensure unauthorized distribution of voice-mails.

The Unified Messaging Server reside between the core Exchange architecture and the Voice-over-IP (VoIP) gateway infrastructure. The VoIP gateway provides integration through IP-PBX to the Public Switching Telephony Network (PSTN). The Unified Messaging Server requires CPU processing power to handle voice connection requests for voice-mail and other features, and compresses it in Windows® supported digital format, using audio codecs. The PowerEdge R610 or the PowerEdge R710 is a suitable rack server for hosting the UM role with a minimum of 2 to 4 processing cores for mid-sized configuration or 8 processing cores for large enterprises.



Storage Sizing Consideration The reduction in IOPS and sequential behavior of database patterns in Exchange 2010 has enabled the philosophy of using low speed and inexpensive disk drives. Now Exchange deployment is not just the domain of expensive fibre-channel class drives, but it performs equally well with NL-SAS and SATA drives. These low-speed drives are usually available in large capacities and are a good fit for very large mailboxes. There are a number of other factors involved in the selection criteria of storage and disk deployment. The rich high-availability feature of Exchange 2010 adds another layer of consideration in storage sizing.

The initial sizing aspects in Exchange 2010 storage design involve defining the number of copies, the number of users, and the size and profiles of mailboxes. The larger the number of DAG copies implies that the storage requirements are multiplied by the same factor. The customer need to realize that as the number of copies increases (from 3 or more), the traditional SAN storage becomes an expensive choice, especially with larger mailboxes (5 GB+). The large number of copies, if deployed in true high-availability (HA) mode without any replication lag, allows the Exchange 2010 application to take control of multiple failures in the system and switchover between copies without any disruption. In such a topology, the RAID setup may not be considered a necessity due to the higher number of copies and the fast switching between copies from one storage device to another. The criteria to deploy RAID or go RAID-less may vary from one configuration to another. To make a more balanced RAID decision, the customer should consider the following also:

Are there enough HA copies to account for different and worst case failure? What are the cost implications of adding RAID versus adding copies? What are the disk drive failure rates or MTBF rates? What are the copy failover and recovery times?

Eliminating RAID (with a large number of copies) frees up the spindles to be used for additional mailboxes or copies. The important point to note in this design is that database distribution should be small enough to fit on fewer spindles. Smaller databases allow faster failover to a secondary copy and less impact to other databases hosted within the same server. Direct-attach storage, internal storage and JBODs can all be considered good candidates for hosting a large number of copies in a scaled-out and distributed fashion.

On the other hand, SAN for Exchange 2010 is considered, where consolidation is required or existing storage infrastructure is deployed. In this setup, the number of copies deployed is less due to expensive storage technology or due to other means available with the storage-based replication and redundancy methods. The performance to handle IOPS is usually not a concern if existing fibre-channel or SAS drives are deployed; rather the configurations are mostly capacity bound. Therefore large mailboxes can become very costly based on the drive types and enclosure expansions. Further consolidation can be accommodated using virtualization technologies.

Dell has categorized the deployment methodologies of Exchange 2010 into two main subdivisions. The next section provides more insight into these models through reference architectures to get a better understanding of the server and storage selection criteria. In addition, Dell has designed a sizing tool based on performance analysis of Exchange 2010 on Dell Servers and Storage platforms. This tool (available as Dell Exchange Advisor tool) provides a complete sizing detail on any design configuration tailored according to your requirements.

http://advisors.dell.com/advisorweb/Advisor.aspx?advisor=b6372fc5-7556-4340-8328-b8a88e2e64b2-001ebc;4&c=us&l=en&cs=g_5�



Deployment Models The Exchange Server 2010 provides different ways to design an Exchange infrastructure based on the configuration size and number of high-availability/DR copies requirement. This is coupled with a variety of options available from server-form factors, storage and disk choices. To provide its customers with a balance between performance, cost and power utilization factors, Dell has developed two basic architecture models to squeeze the most value out of a deployment: the Simple Distributed Model and the Agile Consolidated Model.

Simple Distributed Model With its new highly-available functionality and non-shared storage for same database copies, Exchange Server 2010 enables the use of stand-alone servers with large internal drives or servers with direct attached storage (DAS), as a viable option for mailbox servers. Such a design allows easy incremental deployment for additional mailbox growth and higher number of copies. Furthermore, multiple Exchange roles can be combined on servers in a multi-copy environment which enables smaller and medium sized organizations to provide redundancy of other roles along with the mailbox role in a cost-effective manner.

The Simple Distributed model’s goal is to design a server and storage infrastructure optimized and tuned to provide Exchange 2010 in the simplest, most highly available, and cost-effective manner. Dell recommends using at least three local copies of mailbox database in DAG with either internal storage or direct attached storage (like PowerVault MD1200 or PowerVault MD1220). The objective in this configuration is to have distribution of smaller databases suitable for single or fewer spindles in a RAID-less fashion. The fact of database-level failover in Exchange 2010 can be chimed in perfectly with the higher number of copies to take care of spindle failures and not worry about any RAID configuration. This model makes maximum use of capacity and avoids RAID penalties. The distribution of smaller databases is also an important factor for providing faster recovery on the secondary copy. There are two options for building this simple distributed model: the Internal Storage Distributed Model and External Storage Distributed Model.

Internal Storage Distributed Model This architecture model makes use of the internal disks on a dense server as its building block to host the mailbox database and logs. Optionally, along with hosting the Mailbox, this server building block can optionally host multiple roles such as Hub and CAS in an All-in-One server configuration. Growth is accomplished by scaling out the building block configuration and expanding the exchange deployment as per requirement. This option very much suits the needs of small to medium organizations or satellite offices requiring a cost-effective messaging solution with high availability, ease of management, and capability of expansion. Due to the availability of large capacity NL-SAS/SATA drives and easy scale-out options, this model can be a good fit also for larger organizations that are planning on deploying smaller mailbox sizes in a dedicated Exchange environment, independently of their SAN network.

A sample reference design configuration for the Simple Distributed Model using Internal Storage is shown in Figure 3. The model shows a 5,000 heavy I/O user profile (~100 messages per day) with 2 GB per mailbox in a 3-copy DAG configuration. The 2U PowerEdge R510 with 12 internal 3.5” HDD is used as an All-in-One server (with Mailbox, Hub and CAS combined). It has two flex-



bay 2.5” drives (hidden inside the chassis) that are configured as RAID 1 to host the operating system and the twelve 3.5” drives on the server are used for the mailbox database and logs. For this configuration a total of three such All-in-One servers are required to host 3 copies for each database. A hardware load balancer (not shown in Figure 3) will be required to load balance the CAS. To make maximum use of spindles and provide better failover and recovery, each database with data and log combined is hosted on single disk. Each server has 4 active copies and 8 passive copies for a total of 12 active copies and 24 passive copies in the complete configuration (as shown in Figure 3). The configuration details of the server and storage are provided in Table 3. The design accounts for double failure on the server level or database level. All copies are replicated without any lag to maintain full high availability.

Figure 3: Internal Storage Distributed Model Example Table 3: Configuration details of the Internal Storage Distributed Reference Model



*Note: DAG can be easily extended to remote site (if site-resiliency is required). Dell recommends having at least two copies for remote site in a Simple Distributed configuration.

External Storage Distributed Model The External Storage Distributed model uses JBODs attached as DAS via a RAID controller to the Mailbox or All-in-One server. Compared to the Internal Storage Distributed Model, this model provides additional growth in terms of both capacity and I/O per server by increasing the number of arrays connecting to each server. This model can make maximum use of server resources with multiple storage enclosures before scaling-out the configuration for future expansion needs. This option fits the needs of large or growing organizations that require larger mailboxes and have large I/O requirements.

A sample reference design model for the Simple Distributed Model using External Storage is shown in Figure 4. The reference design shows 10,000 users of 2 GB mailbox size deployment with a very heavy I/O profile of 150 messages per day in a 3-copy DAG environment. For this reference design there are a total of three PowerEdge R710 (2U server) All-in-One servers in a DAG, with each of the servers connecting to 4 x PowerVault MD1200 arrays. There are 12 sets of databases on each server with active and passive copies arranged as shown in Figure 4. Each



database set hosts 835 mailboxes and has 4 drives: 3 x 1 TB 7.2K rpm NL-SAS drives in a RAID-0 configuration for data and 1 x 500 GB 7.2K rpm NL-SAS drive for the log. Further design details are available in Table 4 as follows. The design accounts for up to two failures and is sized to have sufficient resources in terms of memory, processor and storage I/O per server to handle a failure where 2 of the 3 servers go down and all 10,000 users become active on a single server.

Figure 4: External Storage Distributed Model Example Table 4: Configuration details of the External Storage Distributed Reference Model



Agile Consolidated Model This architecture fits Exchange 2010 into what Dell calls the dynamic data center. It assumes that the organization values server and storage consolidation and standardization over building unique infrastructures for each application. In addition, this model can be enabled with virtualization to show further consolidation and the deployment flexibility that comes with abstracting the application and operating system from the hardware infrastructure. Dell SAN products, including Dell EqualLogic™ PS arrays and Dell/EMC CX4 and AX4 arrays, provide the storage foundation for this model.

A sample reference design of an Agile Consolidated Model is shown in Figure 5. The same configuration can be enabled and mapped to a virtualization environment if further consolidation is required. The reference design shows 20,000 users with 1 GB mailbox size and very heavy user I/O profile (~150 messages per day) in a two-copy DAG environment. A third copy (not shown in the figure) for a remote site can be considered also for site resiliency (if required). With lower numbers of copies and expensive means of copy failover in a SAN environment, it becomes necessary in this model to deploy RAID as the first line of defense in case of disk failure. The Mailbox, CAS and Hub roles are separated out on different servers (or VMs in case of virtualization) to provide role service availability.

There are a total of 4 x PowerEdge R710 servers for the Mailbox role, 2 x PowerEdge R610 servers for the CAS Server role and 2 x PowerEdge R610 servers for the Hub Transport Server role in the configuration. The storage section is composed of 4 x EqualLogic PS6500X storage arrays arranged in two iSCSI SANs. Each SAN has two arrays configured in two separate pools, one for active copies and the other for passive copies. A PS6500X array can handle 48 10K rpm spindles. In this setup, the arrays are configured as RAID-50 to make maximum use of capacity. During normal operating mode, each Mailbox Server is hosting 5,000 active mailboxes and each SAN has 10,000 active and 10,000 passive mailbox storage data. Configuration details for these servers and storage systems are provided in Table 5 as follows. This design is capable of



sustaining two server failures and two storage array failures without disrupting the client communication.

Figure 5: Agile Consolidated Model example



Table 5: Configuration details of the Consolidate Storage Reference Model



Conclusion Exchange 2010 architecture has been completely modified to advocate deployment of large mailboxes and inexpensive storage systems. The high-availability model has been redefined to take advantage of continuously replicated multiple copies and provide near instant failover as well as go back point-in-time to handle data corruption scenarios. A number of security and feature enhancements in the core architecture have been added to provide a more reliable and better end-user experience. This paper provides some insight into the core architectural changes impacting your Exchange 2010 design and sizing guidelines for the server and storage to consider before deploying it in your infrastructure. It also presents Dell deployment models to help customers make a balanced decision based on their environment and requirements.

Dell PowerEdge Servers and Dell PowerVault, Dell EqualLogic and Dell | EMC Storage systems provide standard-based hardware platforms for deploying Exchange Server 2010 messaging solutions. For detailed sizing of Microsoft Exchange Server 2010, Dell provides Exchange 2010 Advisor Tool (available at www.dell.com/exchange). Dell Services include assessment, design and implementation tailored for those messaging deployments. Dell also offers end-to-end Exchange messaging solutions that include partner offerings for security, archiving, backup and recovery.



http://www.dell.com/exchange�

Documents

General Introduction to Exchange Server 2010 Sizing - Dell · February 2010 . General Introduction to . Exchange Server 2010 Sizing A Dell Technical White Paper . Dell │ Product