Storage is a critical element of Exchange Server administration, and can have the most impact on operations. From...
the planning standpoint, it is important to design Exchange Server storage in a manner that meets:
- Exchange Server performance requirements
- The present sizing needs of the Exchange Server information stores
- The location of the information stores, transaction logs, SMTP queues, the pagefile used by the Windows operating systems, and the Windows operating system
If budgetary constraints do not exist or are not imposed on critical infrastructure like email servers, adequate planning and sizing for Exchange Server storage subsystems is usually not a problem. Such environments typically also have experienced Exchange Server administrators and more readily available access to outside consultants.
It is the small- and medium-sized organizations where most Exchange Server storage and sizing errors occur.
Exchange Server storage performance
When planning Exchange Server storage, performance should be considered before capacity. Yet many deployments fail to give adequate consideration to performance -- or never consider performance at all.
Disk performance is measured in input/output operations per second (IOPS). For an Exchange Server deployment to perform satisfactorily, you need to provide enough IOPS with acceptable latency. Disk IOPS required per user is calculated as light, average or heavy user.
Microsoft's definition of a heavy user, for instance, is one who sends 30 messages a day, receives 100 messages, and has an average mailbox size of 100 MB. Such a user would generate .75 IOPS on the database volume. If you have 1,000 users with this profile, they will generate 750 IOPS on the database volume. The profiles of your users may differ, depending upon usage patterns in your Exchange Server environment.
The Exchange Server transaction log volume experiences roughly 10% of the IOPS seen on the database volume. In the above scenario, it would generate 75 IOPS on that volume.
It is also important to consider performance penalties imposed by storage technologies like RAID 5.
For more information about storage performance and optimization, I recommend reading the white paper: Optimizing storage for Microsoft Exchange Server 2003 on the Microsoft Exchange TechCenter.
Exchange Server storage sizing
It's easy to arrive at a ballpark number for Exchange Server storage capacity by multiplying the number of mailboxes by the average mailbox size, and then adding a random buffer to allow for growth. But too often, one or more of the following factors aren't considered in Exchange Server deployments:
Deleted Items Retention: By default, deleted items are stored in the Exchange Server database for seven days; deleted mailboxes are retained for 30 days. Items and mailboxes are not permanently deleted before a backup of the store is completed. Depending on volume of traffic and usage patterns, this can easily make up 5% to15% of the store size.
Future growth: When sizing Exchange servers, including the storage subsystem, it is critical to estimate the approximate growth of the number of total mailboxes -- whether these are employees or contractors, consultants or partners, resource mailboxes, or public folders.
Present and future email retention policies: Adequate consideration should also be given to requirements that may arise down the road, such as those imposed by the myriad compliance regulations like Sarbanes-Oxley or HIPAA. These may result in message archiving policies that require email to be stored for an extended period of time. Such requirements may also result in the need for third-party email archiving software or services that store a copy of items outside the Exchange Server stores.
Unified messaging: Another Exchange Server storage sizing factor is unified messaging -- a technology available in the recently released Exchange Server 2007. In addition to email, unified messaging allows users to receive and store voicemail and faxes in their mailboxes. Voicemail and fax messages generally create much larger message sizes than email when stored digitally in a mailbox. You should also consider the possible compliance and retention requirements that may be imposed on those voicemail and fax messages.
Growth of transaction logs: Exchange Server transaction logs normally follow an orderly growth pattern that can be baselined and planned for. Nevertheless, there may be times when growth happens due to temporary events, like moving a number of mailboxes together, performing bulk operations -- or worse, a virus outbreak or attack that uses email to propagate, or a denial of service attack on the mail server itself.
In addition, there are rare occasions when Exchange Server backups fail and transaction logs are not purged. Small- and medium-sized organizations are more prone to backup failures going unnoticed. If backups do not resume successfully, transaction logs continue to grow, eventually making the volume they reside on run out of disk space; this will cause the information stores in the storage group to unmount.
Store maintenance operations: When ESEUTIL is used to perform an offline defragmentation (ESEUTIL /D) of an Exchange Server database, it creates a new database and requires 110% of the database size in free disk space. Free disk space requirements when running ESEUTIL to repair a database (ESEUTIL /P) depends on the number of corrupt pages in the database. Twenty-five percent of the Exchange Server database size is a conservative estimate.
The above operations are not performed very frequently. A different location -- another local or network drive -- can be specified for the temporary file by using the /T switch. See Microsoft Knowledge Base article 183888, XADM: Free Disk Space Requirements for Eseutil.exe for more information.
BEST PRACTICES GUIDE: THE 10 MOST COMMON EXCHANGE SERVER ISSUES
Issue #1: Exchange Server storage sizing and location
Issue #2: SMTP virtual server and connector configuration
Issue #3: Exchange recipient policies and Recipient Update Service
Issue #4: Exchange Server messaging hygiene
Issue #5: Exchange Server and DNS
Issue #6: Front-end/back-end Exchange Server topology issues
Issue #7: Exchange Server information stores and mailbox sizes
Issue #8: Moving or removing Exchange servers
Issue #9: Exchange Server backups and disaster recovery
Issue #10: Exchange Server monitoring -- or lack thereof
|ABOUT THE AUTHOR:|
| Bharat Suneja, Microsoft Exchange MVP
Bharat Suneja is a Microsoft Certified Trainer (MCT), Exchange MVP, and Principal Exchange Architect for Zenprise, Inc., maker of real-time troubleshooting and diagnostics software for Exchange. Bharat Suneja has over 10 years of experience in IT, architecting and managing Exchange Server and Active Directory environments, ranging from small and mid-sized businesses and e-commerce companies to large ISPs and ASPs. An active writer and contributing editor for international IT publications such as PC Quest, Bharat was also a technical reviewer for Exchange Server 2003 24 Seven by Jim McBee. Visit Bharat Suneja's blog at www.exchangepedia.com/blog.