When configuring a DAG you should consider using a separate network for replication. DAGs offer the capability to configure nodes to use a specific network for the replication traffic. This provides two benefits. Firstly, in a LAN scenario, users are not competing with the replication traffic for access to the mailboxes over the LAN. Alternatively in a WAN configuration, if the environment has access to multiple networks, the replication traffic
could potentially be movied to a lower cost network. Consider the scenario where a large enterprise has multiple offices connected with an MPLS network. MPLS provides high bandwidth and good performance but is expensive. The large enterprise will also likely have IPSec tunnels set up across Internet connections to provide for a secondary network in the event of a failure of the enterprise’s MPLS links. The cheaper IPSec tunnels could be used for offloading the DAG replication traffic. This will reduce the load on the main network and save the expensive of using the more expensive network.
Another way to optimize DAG performance is to balance the load across the multiple DAG replicas. In Exchange Server 2010 replication is performed at the database level as opposed to the server level. Thus, instead of running in Active/Passive pairs, one can effectively be active for some databases and passive for others on the very same server. Therefore a site may have three DAG members in a single location for redundancy and could be running 1/3rd of the databases as the “master” on Node 1, 1/3rd on Node 2 and the final 1/3rd on Node 3, with the replicas going to the other 2 nodes. Node 1 could be “master” for databases 1-5, the second priority for
the databases 6-10 and third priority for the databases 11-15. therefore in the event of a node failing, the load would be doubled on the remaining two servers instead of tripled on a single node. Administrators can get the best performance out of the server hardware by carefully planning the loads for both a “normal” and a “Disaster Recovery” scenarios.
The Mailbox server role will likely have the biggest impact on performance of all the servers in Exchange Server 2010. Mailbox servers were traditionally very dependent on the disk subsystem for their performance. In
Exchange Server 2010, however, this has changed somewhat and the disk behavior is very related to the system memory. As a result, the primary rule for performance of an Exchange Server 2010 Mailbox server is to configure it with as much memory as you possible. As an example, in Exchange Server 2003, running a RAID 0+1 configuration and for a load of 2,000 users who generated an average of 1 disk I/O per second and you would require 4GB of memory and 40 disks (assuming a 10k RPM disk and 100 random disk I/O for each disk) to achieve the performance you would expect out of an Exchange server. For Exchange Server
2010, the I/O load per user would be approximately 0.15 disk I/O per second and you could therefore reduce the number of disks required by about 85% if you were to increase the system memory to 12GB. Thus with a mailbox server, the trick is to achieve a balance costs versus performance. For large implementations, it is less costly to replace high-performance disks with memory which makes direct attached disks a viable option for Exchange Server 2010 mailbox servers.
Although the disk requirements for Exchange Server 2010 mailbox servers are lower than previous versions of Exchange Server, the disk subsystem is still an important consideration in performance tuning. Databases benefit the most using high-performance disks. Consider using 15k RPM drives which provide more I/O performance per disk – typically 50% more random I/O capacity compared to a 10k RPM disk. Given the reduction in disk required to support the databases, you should consider using RAID 0+1 as opposed to RAID 5 to avoid incurring the write penalties associated with RAID 5.
Log files also require fast disks to to commit information quickly, but have the advantage of being sequential I/O as opposed to random (therefore the write heads of the disk do not have to jump all over the disk to located the object to which they need to write). Logs always start at one point on a disk and write sequentially without having to modify old logs.
Exchange Server 2010 has implemented several changes which specifically improve performance when using SATA disks. Exchange Server 2010 has altered the I/O pattern and now disk writes are better spread out
and are less “bursty” than in previous versions. This means SATA disks are now a more viable choice for Exchange Server.
Another performance benefit with Exchange Server 2010 is the potential to entirely eliminate RAID. Database Availability Groups are being used with three or more replicas of mailbox databases, there is likely already sufficient redundancy in the system as a whole to eliminate the redundancy at the individual server level which RAID provides. Thus redundancy is provided at the application level as opposed to the server level. This is similar in many ways to the redundancy in Active Directory. In Active Directory,in the event a domain controller fails, it is usually not a major issue provided there are other DCs to assume the load. Instead of fixing a DC, we can simply build a new one and let it replicate the directory. In similar fashion, in Exchange Server 2010, if a DAG member fails, instead of restoring it, we can simply build a new one and let it replicate the data. Another DAG member will take over from the failed node and services would not be significantly impacted.
Ideally all databases and logs should be on their own dedicated disks. Although this is not always possible or practical, it provides the best performance since read/write patterns for databases and logs are very different. Keeping databases and logs on separate disks also makes recovery much easier.
Mailbox servers handle large amounts of network traffic. Email messages are usually small and as a consequence, the transmission of these messages is not always efficient. If possible, equip mailbox servers with Gigabit Ethernet interfaces and if you are not clustering the mailbox servers run the network interfaces in a teamed mode. Thiswill improve both the performance and reliability.
Since mailbox servers also hold the public folder stores, you should consider running a dedicated public folder server if the environment heavily leverages public folders. Public folder servers regularly store very large files which users access, therefore separating the load of large files from the mailbox servers will result in improved overall performance for the users.
In the event that public folders are only lightly used, it may require some investigation of the environment to determine if it is optimal to run a centralized public folder server or else maintain replicas of the public folders in multiple locations.
]]>