Sizing an Exchange Server 2003 system when you're migrating or upgrading isn't a trivial task. Administrators often use sizing calculators (e.g., HP ProLiant Server Sizer for Microsoft Exchange Server 2003) and load-testing tools (e.g., Exchange Server Load Simulator—LoadSim—2003) when designing systems, but sometimes they guess or rely on assumptions when providing input for these tools. (For more information about these tools and their needed inputs, see the sidebar "Tools and Resources for Designing an Exchange 2003 System," page 6.) When I perform an assessment before designing a system, I'm amazed at the lack of good data or insight into answering the root question: How do people use the current Exchange system? To answer this question, you need to determine, at a minimum, the following information:
- typical length of the users' workday
- typical peak work hours
- how often people use the mail system and what they use it for
- how often users open and reopen a message or attachment
- how much storage space people use
|
Exploring the Peaks and Valleys
Two important questions you need to answer before you size an Exchange system are how long is your users' typical workday? and what are their peak work hours? This information is important because you'll need to size your system so that the performance will be acceptable during peak demand. A typical workday for most users is 8 or 9 hours long, but many offices have some type of flexible scheduling, so not everyone starts their day at the same time. For example, some people might start their day at 6:00 a.m., whereas others might start at 9:00 a.m. Work-from-home trends have made flexible scheduling more the norm than the exception. A flexible schedule increases the overall length of the workday past the historical 8 hours of the 9-to-5 job.
Another factor to consider is users' distribution across time zones. If your organization has people spread across several time zones and you plan to use centralized servers, you need to account for this fact when determining the length of the workday. For example, if you have users in California and Washington, DC, the minimum workday is 11 to 12 hours long because of the 3-hour time-zone difference. When you factor in flexible work schedules, a more realistic number is having a workday that's 15 to 18 hours long.
Although knowing the length of the workday is important, it's more important to know when you can expect peak loads and how long the load periods last. Most administrators expect loads to be highest first thing in the morning and right after lunch. However, the loads really depend on how your organization does business. To determine the peaks and their durations, you need to monitor your system, which is easily accomplished by using the Windows Performance Monitor tool.
Performance Monitor has four Information Store (IS) counters that I find useful: User Count, Active User Count, Connection Count, and Active Connection Count. The User Count and Active User Count counters tell you the total number of connections on a per-logon basis. The Connection Count and Active Connection Count counters tell you the total number of connections to resources within the IS. The distinction of an active count is that it shows information about activities performed within the last 10 minutes of the sample. The difference between a connection count and a user count is that a single user can have multiple connections, so generally the connection count is higher than the user count because each user often makes several connections to the IS. For example, a user might have three connections—one to access his or her mailbox, one to access the public folder store, and one to access another user's calendar.
Email-enabled applications, such as Research In Motion's BlackBerry Enterprise Server, can also create connections. You need to consider the source of the connections because different sources can create different loads on the system. For example, at HP, we've found that each BlackBerry user creates the same load as 2.21 Outlook users. You need to consider this type of loading factor when calculating the number of users to put on a server.
Figure 1 shows a graph representing the actual system load results from a server in a site. I added the vertical bars so that you can correlate the user and connection counts to the time of day. This server's administrator had assumed that the load was heaviest early in the morning and at lunch time, but as you can see, users in this organization tend to establish connections when they arrive and don't close them until they leave for the day. The users also tend to be fairly consistent with the frequency in which they interact with the mail system throughout the day. For the day this sample was taken, the server hosted 750 users and the peak user count was 660. Samples from other days showed similar results. So, the administrator and I determined that approximately 80 percent of the user population is consistently online at the same time. This information is needed to help determine how many mailboxes a server can support.
When you use Performance Monitor, don't just take samples for a few days or on certain days. Make sure you sample over a long period of time, then aggregate the results. You might find, for example, that Mondays and Fridays have different results than other days of the week. Or you might find that there's higher utilization a certain week each month because of a recurring event. Don't forget to discount atypical periods, such as weeks that contain a holiday. Finally, don't assume every server is used the same throughout an organization. If you have many servers, those individual servers likely support individual business units. Sometimes business units work differently, and you might find that one set of servers sees steady usage, such as the server represented in Figure 1, whereas other servers have very jagged connection graphs with extreme peaks (high utilization) and valleys (low utilization). You should gather data from a large number of servers, if not all of them, to determine what server types and configurations you need. This information will help you determine, for example, whether you should deploy five or six high-end servers for centralized users and two midrange servers for field offices or deploy a series of identically configured midrange servers for all locations.