Without question, the single most important application for any enterprise is email. It’s the lifeline between employees, clients, customers, family, and nothing will drive anyone from a data entry clerk to a CEO to unadulterated insanity faster than slow email. Nobody cares if a report takes an extra 10 seconds to run; everyone cares if email freezes, even momentarily. Is this going to continue? Let’s take a look . . .

Although Microsoft Exchange 2007 and Exchange 2010 brought with it I/O enhancements, Exchange can still face serious latency issues and cause frequent disruptions for the end-user. Exchange storage design hinges on transactional I/O. Without proper storage, tasks such as receiving, sending, sorting, and deleting items in Microsoft Outlook Online Mode or Outlook Web App (OWA) cannot be completed efficiently.

Before diving into the logistics of how latency affects performance, one must understand how Exchange mailbox servers handle I/O. Transactional I/O can be divided into database volume I/O and log volume I/O. With the introduction of Exchange 2010, Microsoft has to do sequential writes and reads for database I/O. Prior to this change, database I/O was frequently bottlenecked by random I/O operations, which are generally more latent than sequential operations due largely to seek times associated with traditional spinning disks. While the adoption of sequential database operations has helped to reduce I/O latency stemming from mechanical seek times, the execution and completion of user requests is still highly sensitive to database I/O latency.

In Exchange 2007 and 2010, the segregation of Exchange server roles across multiple servers has reduced the I/O workload of individual mailbox, transport, and client-access servers, but user activity is still subject to the net effect of these sources of latency. The time required to retrieve data from the Exchange mailbox server storage is productivity lost by the end-user.

Most Exchange users have encountered popup notifications indicating that Outlook is attempting to “retrieve data from the Microsoft Exchange Server.” These alerts stem from storage latency and / or I/O bottlenecks.

Exchange 2007 and 2010 tout improved I/O management, resulting in much lower IOPS/user requirements relative to Exchange 2003. In order to combat database read I/O latency, Microsoft has implemented database caching to expedite database reads. However, this database cache is dependent on the physical memory available to the server.

A Microsoft example, using 2500 moderate users, requires 22.5 GB of database cache, which corresponds to 32 GB of physical RAM to achieve an optimal 0.15 IOPS/user; this physical RAM requirement is prohibitive, particularly to virtual deployments. More realistic IOPS/user projections, depending on the concurrent implementation of supporting technologies like mailbox resiliency, Data Protection Management, antivirus, Blackberry Enterprise Server, and / or archiving / compliance solutions, range from 1 to 3 IOPS/user. Though the IOPS/user requirements have been reduced in Exchange 2007 and 2010, the total IOPS requirement for medium- to large-scale Exchange deployments is still substantial, and the potential for negative impact to an organization’s existing storage solution cannot be ignored.