As we discussed last week, the hardware you choose for your Exchange deployment will greatly affect your server's performance. Because of its significant impact, we are devoting two entire issues on hardware configurations. Having already covered the processor and memory, we devote this week's article to the network interface and disk subsystem.
Fortunately for you, much of the network interface subsystem will be tuned automatically. Server-based network cards and their drivers are very good at intelligently detecting the type and level of traffic passing through the network interface and will self-tune to reflect this information. Beyond ensuring that you have the latest device driver on the server, there is not much to do here. If you plan to configure IP security (IPSec) on your Exchange 2000 server, perhaps because of a front-end and back-end server configuration, you may want to invest in a specialized network card that can offload IPSec processing from the main CPU.
Ultimately, your disk subsystem is one of the most important areas of configuration. Probably the most asked question is: "I have n disks in my server; what is the best way to partition them?" Before this question can be answered, though, you have to consider the role of the server. For example, tuning a bridgehead server will be different from tuning a mailbox server.
Generally, if the server is an SMTP bridgehead server, the best disk layout is to create one partition. Messages will arrive on the SMTP interface, be written into the Mailroot directory (which should be on an NTFS formatted system), and then passed to the next computer. The best performance will be gained by spanning the Mailroot directory over as many disks as possible. The following number of disk spindles available will largely determine your recommended hardware RAID configuration:
2 disk spindles = RAID1, Mirroring, 1 partition
3 to 5 disk spindles = RAID5, Distributed parity, 1 partition
6+ disk spindles = RAID0+1, Data striping and mirroring, 1 partition
If your hardware RAID controller has a mirrored, battery-backed cache that allows you to tune the read/write cache ratio, you should set it to 100 percent write. The reasoning behind this is that the server can only acknowledge receipt of a message after it has been written to disk. Therefore, the faster the server can write to disk, the more responsive the server will be to other computers. Setting the cache to 100 percent write is especially important for RAID5 configurations where one application input/output (I/O) means four disk I/Os. Although it is true that the message contents need to be reread before being relayed to the next computer, the SMTP service will have an open file handle to the data and will retrieve the contents from the NTFS cache. This setting will also speed up SMTP service shutdown, which is useful if you increase the SMTP file handles.
If, on the other hand, your Exchange 2000 Server houses many X.400 connectors or connects to legacy messaging systems, you should consider creating a separate disk partition for transaction logs if you have enough spindles. Messages that use these Exchange components will move data through the Store.exe process. If the server is heavily loaded, additional performance will be gained by splitting the transaction logs from the database. When a message is received by the MTA, the data is written into the MTAdata directory on an NTFS partition and passed into the Store.exe process through an MTS-IN virtual queue. Because the message goes to the Store.exe, data will be written to the transaction log files. The message then goes through the categorization and routing process. If routing has determined that the message should be sent out through an X.400 connector, the data will be moved into the MTS-OUT virtual queue. Legacy messaging connectors use a similar process. Again, the number of disk spindles available will largely determine your hardware RAID configuration:
2 disk spindles =
RAID1, Mirroring, 1 partition
3 to 4 disk spindles =
RAID5, Distributed parity, 1 partition
5 disk spindles =
RAID5 (drive C) for three disks; binaries and database
RAID1 (drive D) for two disks; logs
6 disk spindles =
RAID5 (drive C) for three disks; binaries and database
RAID1 (drive D) for two disks; logs
No RAID (drive E) for one disk; Pagefile
If your hardware RAID controller has a mirrored, battery-backed cache that allows you to tune the read/write cache ratio, you should set it to 100 percent write for configurations that use a single partition and 100 percent write on the transaction log partition when five or more disks are used. You will see better performance by using write cache on the transaction logs rather than read cache on the database drive.
If, however, you are configuring a single database collaboration server, your disk design will be similar to that of an Exchange 5.5 server. Split the transaction logs and database onto separate disk spindles to gain performance on transaction logging and to take advantage of sequential writes. Not only should the logs be on a different spindle set, but that spindle set should be dedicated only to logs. For example, you will not receive the performance benefits of the split if you choose to place the pagefile or Windows binary files on the same spindle set as the logs.
If you intend to create multiple storage groups on the server, your number one priority again is to split the logs onto dedicated spindles. However, to gain any performance, you must have a dedicated spindle set for each storage group. Once you have a dedicated spindle set, it's time to work out how many spindles you have left. On most servers, you won't have that many disk slots available, so your best option may be to place all databases on the same partition. There are some good reasons, though, for placing database files from different storage groups on separate partitions. First of all, it makes management easier and more logical. Secondly, if the drive array housing one set of databases goes off-line, it won't affect databases in other storage groups.
With enough disks, you could split the properties database (.edb) files from the streaming database (.stm) files. The performance benefit of splitting these files will be dictated by the types of clients that your server accommodates. MAPI and Microsoft Outlook Web Access clients will read and write data to and from the .edb file. Technically, clients communicate to the Store.exe process, so they have no understanding of .edb files versus .stm files. All other clients will use the .stm file. The information below indicates the preferred location used by different clients:
Client Type: Outlook in MAPI mode or CDO 1.21
Submitting Data: .edb files
Retrieving Data: .edb files
Client Type: POP or IMAP
Submitting Data: .stm files (through SMTP)
Retrieving Data: .stm files
Client Type: Outlook Web Access
Submitting Data: .stm files (but full promotion to .edb files)
Retrieving Data: .edb files
Client Type: IFS, ADO/OLE DB, or CDO for Exchange 2000
Submitting Data: .stm files
Retrieving Data: .stm files
Client Type: SMTP
Submitting Data: .stm files
Retrieving Data: Not applicable
Client Type: SMTP (with MAPI data)
Submitting Data: .stm files (but full promotion to .edb files)
Retrieving Data: Not applicable
Although the information above indicates the preferred file type, cross conversions can and do occur. In most scenarios, there is no real benefit to splitting the .edb files and .stm files on separate spindles. For example, if you have six disks, you have to ask yourself whether creating two RAID5 partitions over three disks each would give more performance than a single RAID0+1 (stripe and mirror) partition. The answer is that RAID0+1 will always perform better.
It should also be noted that specialized storage subsystems (such as EMC) that employ gigabytes of cache and lots of hard disks usually have their own partition management and fault-tolerant operating system. When working with these devices, it is normal to place all data on the same disk partition and let the hardware perform the optimizations.
On front-end servers, which are not disk intensive, you should delete the databases through the Exchange System Manager and stop the Store.exe process. This will free up valuable processing time for the InetInfo process. Like everything else, there are exceptions to the rule of deleting databases. For example, some companies will want a front-end server to accept SMTP messages from clients. In this scenario, the mailbox store is used for tasks, such as generating non-delivery reports (NDRs).
In summary, the following are your best guidelines for configuring collaboration servers:
First, create a RAID1 partition for Windows and Exchange binary files. Second, place the pagefile on a separate spindle. (This can be coupled with the binary drive on smaller servers.) Third, create one dedicated fault-tolerant partition for each storage group for the transaction logs (RAID1 or RAID0+1). Fourth and finally, create at least one fault-tolerant partition for your databases. If you only have one array, place all databases on this array. If you have multiple arrays, use one array for each storage group (databases only). These manual hardware configurations will surely improve your Exchange 2000 Server environment.
