When I'm creating or reviewing a company's Exchange Server design, I try to make sure that the plan adheres to four key architectural principles: simplicity, integration, cost, and efficiency. Simplicity means ensuring that the design contains everything your business needs and nothing that it doesn't. Integration means finding a compromise between the enterprise view and the point view. Cost means that the design takes into consideration the total cost of ownership (TCO) over time. And efficiency means that the finished design will make your life easier. I've found 10 steps that are invaluable in creating a design that helps meet those four requirements. Here are the first four.
#1: Document the Business Expectations Understanding and documenting your business's messaging requirements is the first task on your plate. Notice that I don't say deciding these requirements. That's because decisions such as mailbox size, retention, recovery, and maintenance windows are best made by the business units that comprise your company. This isn't to say that the IT department doesn't have a say in those decisions, but your primary role should be to explain your messaging technologies' advantages and disadvantages in a nonbiased manner so that the business leaders can make an informed decision. By doing so, you help increase the likelihood that your Exchange architecture will be well aligned with your company's overall business objectives. Consider mailbox-recovery time. Your company's business leaders might decide that one group of users requires an extremely fast recovery time, whereas other users can live with longer recovery times. Knowing this might affect your design and perhaps would lead you to install one mailbox-server configuration for the first set of users and another mailbox-server configuration for the remaining users (depending on their classification).
The key to success is to meet with the leaders of the lines of business within your company. Document their requirements, and ask for elaboration of the key principles. When creating a detailed Exchange design, I first list the business requirements, then reference those requirements throughout the design document. That way, I can give an immediate response to anyone who asks why I've designed a certain aspect of the organization in a certain way. I typically add my own comments, from a technical perspective, regarding the cost and effort necessary to implement each requirement. Doing so up front can help decision makers evaluate the practicality of requirements such as Email must be up 100 percent of the time, and recovery must be within 5 minutes. Framing your input within this type of business view is important when you're presenting a design project to executive management for sponsorship. Finally, circulate the requirements for feedback, approval, and sign-off.
#2: Document the Existing Infrastructure How can you decide the best way to get to where you want to go unless you first know where you are? Designing a successful Exchange solution requires that you know your current messaging infrastructure. This advice might seem like simple common sense, but I'm continually surprised by how many companies lack any sort of formal documentation about their messaging organization. (A bunch of cool schematics made with colored markers on a white board in the Exchange administrator's cubicle doesn't count.)
Microsoft provides many free tools that can help with this task. Using a common application such as Microsoft Office Visio 2003 to document the logical, physical, and technical views of your current messaging environment is a step in the right direction. If your budget allows, an extensive array of third-party products can provide automated documentation. For the more budget-conscious, Microsoft offers free utilities such as the Exchange Server Topology Diagramming Tool (ExMap—http://www.microsoft.com/technet/prodtechnol/ exchange/downloads/2000/exmap.mspx), which can automatically generate a Visio diagram of your site topology; the ExchDump tool (exchdump.exe—http://tinyurl.com/2cp4o) provides both HTML and XML output files of every aspect of an Exchange server.
Another approach to documenting the technical performance of your Exchange server is to leverage Performance Monitor, then save the results to a file. To document the general health of the server, monitor the four main subsystems (i.e., CPU, Network, Memory, and Disk) that make up the server. Select all counters in each performance object. When capturing performance counters for general information, a good sample time is 4 hours during normal production hours, with a sample interval time of 15 to 30 seconds. To keep performance-file size small, select the Text File (Comma Delimited) option on the Log Files tab when scheduling or running Performance Monitor. (Text files are much smaller than binary file types and compress extremely well. In my experience, Performance Monitor produces very small comma-separated value—CSV—files of less than 10MB on average.) I suggest you use Task Scheduler to schedule regular Performance Monitor runs and archive those files to create a performance history log for each server. This information is a great resource when redesigning (or troubleshooting) your Exchange environment. If you want in-depth realtime information that's easy to read and browse, a product such as Quest Software's Quest MessageStats can provide a deeper level of real-time Exchange reporting.
Don't make the common mistake of involving only the Exchange administrator or group in this documentation process. Seek the input and review of your cohorts in other disciplines such as Active Directory (AD), network, DNS, firewall, and security—and don't forget the Help desk! You'd be amazed how many Exchange designs are born in a vacuum. This is also a good time to have your company's business units review their current service level agreements (SLAs); requirements can change, and the technical team is often the last to know.
#3: Run an AD Health Check The next item to consider is your company's AD architecture. An Exchange Server 2003 or Exchange 2000 Server infrastructure requires AD for key items such as user authentication, administration of Exchange mailbox and mail-enabled objects, storage and replication of directory information, the Global Address List (GAL—including Distribution Groups— DGs), and storage of your Exchange configuration settings. If AD isn't healthy, your Exchange organization can grind to a halt.
Exchange makes heavy use of both AD domain controllers (DCs) and Global Catalog (GC) servers for such tasks as email address lookups and message routing. Often, AD is installed before Exchange is designed, primarily for account authentication and authorization rather than for supporting Exchange. Thus, AD might not be sized properly to support the additional demands of Exchange. Furthermore, different versions of Outlook have different AD requirements. Outlook versions earlier than Outlook 2000 receive GC information via the Exchange server, whereas newer versions are redirected directly to a GC server. Understanding how the various versions of Outlook in your infrastructure interact with AD will help you appropriately size and place Exchange and AD services. For example, if your environment is still using older versions of Outlook, consider installing the maximum amount of memory (i.e., 4GB) in your Exchange mailbox servers to provide plenty of memory for the increased demand that those Outlook versions impose. Communicate with the AD team and make sure they understand and approve any AD adjustments that will be necessary before you finalize your Exchange design.
#4: Size Up Your Hardware Now, you're ready to take a look at your hardware. When it comes to configuring hardware for Exchange, the memory and disk subsystems are of primary importance.
As far as memory is concerned, you should plan to add the maximum amount of memory—4GB—to all your Exchange servers, if possible. Exchange 2003 and earlier are bound by a 4GB memory limit, and because memory is relatively cheap, installing the maximum amount allowable makes sense. The more memory Exchange has available, the better the server's performance; Exchange will be able to cache more directory information and thus reduce the load placed on DCs and GC servers. Memory is most important for Exchange servers that perform dedicated routing, such as Exchange front-end or bridgehead servers. Increased memory also improves performance for servers that handle Secure Sockets Layer (SSL) or proxy functions, such as Microsoft Outlook Web Access (OWA) servers. For Exchange back-end servers, additional memory lets functions such as DSAccess and store.exe run more efficiently.
Of the four subsystems in an Exchange server, the disk subsystem receives the least amount of proper attention. I continually find that administrators spend hours discussing whether the Exchange server should have a 3.2GHz CPU or a 3.4GHz CPU, but spend only a few minutes of consideration on the disk subsystem. Yet everything the Exchange server does involves the disk subsystem in some way. Table 1 provides overall guidance for the design of an Exchange mailbox server disk subsystem for DAS. (For Exchange environments that use NAS or a SAN, you'll need to contact your storage vendor for disk-configuration recommendations.) I don't have the space in this article to cover all the architecture and design options for an Exchange disk subsystem, but I will point out some common mistakes that I run into regularly.
Whether Exchange disk storage uses DAS, NAS, or SAN, the Exchange disk drives shouldn't be shared with or used by other applications. Exchange is sensitive to disk latency, and the inherent random nature of Exchange database activity further amplifies that sensitivity. The Microsoft article " Exchange Server and network-attached storage" (http://support.microsoft.com/?kbid=317173) is a good starting point for learning about the effects of disk sensitivity and disk latency.
A key point to remember when dealing with the Exchange disk subsystem is this: Spindles are your friends. You can never have too many spindles for an Exchange mailbox server. The more spindles you dedicate to an Exchange back-end server, the greater the disk I/O rate the server can support and the better the server's performance. Too often, administrators (and managers) focus on disk size rather than spindle count. For example, suppose you have an Exchange server that needs to support 2000 users, with a 150MB mailbox size limit. Is buying a couple of 300GB disks adequate? If you answered "Yes," you're suffering from a false sense of security. Users are, in actuality, disk I/O consumers. Each active Exchange user (or mailbox) requires a certain amount of disk I/O, typically between .1 and .8 I/O operations per second (IOPS) per user (high-end users can require more than 1.0 IOPS.) The average high-performance SCSI disk drive (depending on make and model) supports about 120 IOPS, so the only way you can successfully satisfy the requirements in our example is by adding spindles. This is especially true for the volume (or LUN) that supports the Exchange databases. Exchange database volumes should consist of many smaller spindles (as opposed to a few large spindles). Exchange database activity is extremely random, and having more spindles to service these random disk requests is key to good Exchange performance. You can use Performance Monitor to find out how many IOPS your existing users are consuming. (Take a look at the Microsoft article "Optimizing Your Storage Architecture," http://tinyurl.com/bpn2k, for more information.)
Another mistake is assuming that RAID 5, instead of RAID 0+1 (or RAID 1+0, depending on your hardware implementation) is better for local disk storage. RAID 5 requires more spindles to achieve the same performance as RAID 1+0 because of the added disk writes that RAID 5 must make. RAID 5 might work fine for smaller Exchange servers in remote branch offices, but for dedicated Exchange back-end servers that support many users and large mailbox storage limits, RAID 5 isn't necessarily the best choice. (If you're using SAN technology for your Exchange disk storage, this might not be the case. Contact your storage vendor for help designing SAN storage.)
Sharing Exchange transactions or database logs with other applications can hurt Exchange performance. As Table 1 mentions, Exchange transaction logs are 100 percent write and are sequential. Sharing either volume can cause excessive disk contention and performance degredation. For new Exchange installations, I recommend you run Microsoft Jetstress or Microsoft Exchange Load Simulator (LoadSim) to ensure that the disk subsystem can support the necessary number of mailboxes. (Of the two, Jetstress is the fastest and simplest to install, configure, and run.) These utilities can often uncover disk I/O problems before you put the new Exchange server into production. To find out more about these tools, see the Web-exclusive article "Exchange's Performance Testing Tools," November 2003, InstantDoc ID 40844.
Don't create logical volume sets on the same set of physical spindles. I've seen administrators create one large volume, then create individual logical partitions in an attempt to provide dedicated spindles ( separation) for Exchange transactions and database logs. The results are not good: Because all the logical partitions in the one large logical volume set use the same set of physical spindles, the Exchange server still suffers from disk contention.
One last piece of advice when it comes to disk subsystems: Many hardware vendors provide caching on their disk controllers. If these controllers have battery backup, consider enabling write-ahead caching, which tells the Exchange server that the write request has been committed to disk when in reality, the request is in memory. I've seen dramatic improvement in Exchange performance when this feature is enabled.
More Tips Next Month Next month, I'll cover the remaining design considerations that round out our Top 10. In the meantime, you can begin documenting your design requirements and planning your AD and hardware requirements.
