Once you have selected your Exchange Hosting provider, give some time on analyzing your hardware desing, though this part is done by your hoster. One of the key design elements which ultimately can improve the efficiency of Exchange is by isolating the Exchange database and the Exchange logs onto a different hard drive volume. This is because logs does write operation & databases read mostly. Hence separating these elements onto different volumes increases server performance substantially. This best practise should be followed even in smallest Exchange server implementations.Below figures shows some examples of how the database and log volumes can be configured.
On Server1, the OS and logs are located on the same mirrored C: volume and the data base is located on a separate RAID-5 drive set, although in a different channel. OS partition is cornerstone, doing many type of operations and consume more processing power. Putting Exchange logs along with it is not a good idea.
On Server2, the configuration has gone to very next level, by having OS only on C:, the logs on D: and the database on the RAID-5 E: volume.This is good, but there is a room to improve.
Server3 below considered the optimal configuration, by separating volumes for each database and volume for the log files. The sideaffect is more complex drive configuration. However, the most important factor that must be remembered is to separate the Exchange databse from the logs wherever possible.
Understand a littile bit on the Exchange databases and Storage Group
The Enterprise Edition of Exchange Server 2007 not only enables databases of larger than 75 GB, it also enables the creation of multiple separate databases on a single server. This concept gives great flexibility in design while enabling reduced downtime and increased performance. A storage group is a logical grouping of databases that share a single set of logs. Each Exchange Server 2007 Enterprise edition can handle a maximum of 50 Storage groups per server. Each storage group can contain a maximum of five databases each, although the total number of databases on a server cannot equal more than 50. If you have a plan to use cluster continuous replication (CCR), it only supports a single database per storage group. Also, Microsoft recommend no more than 30 databases on a server running CCR.
Following are the various scenario where multiple databases can solve come customer’s concern.
- Reduce database restore time – smaller databases take less time to restore from tape. This concept can be helpful if there is a group of users who require quicker recovery time (e.g. senior management).
- Provide for separate mailbox limit plocies – each database can be configured with different mailbox storage limits. e.g, the standard user database with 200-MB limit on mailboxes, and the management database with 500 MB limit.
- Minimize the risk by distributing user load balance – distribute user load across multipel databases. e.g., if a single database is failed that contained all users, no one would be able to mail. If those users were divided across 4 databases, however, only one fourth of those users would be unable to mail in the event of a database failure.
For more details on storage design, watch the following Webcast: http://msevents.microsoft.com/cui/WebCastEventDeta…ode=US
Following are some nice articles on this topic:
Technorati : Exchange_Storage Designing_Storage Exchange_Server_Performance