Back in February I read a blog post from Andre Leibovici (VDI and Microsoft Outlook, analysing the variables), a very well known and respected expert in the virtualization and VDI community. His article discussed the challenges in dealing with Outlook in VDI environments, including how to address OST/PST files and how searching is affected. Although I’m a little late to the party here I thought I’d add my thoughts on this and make sure folks aren’t seeing this as a barrier to adopting VDI.
I recommend reading Andre’s post to get more information on this topic. The short version is this – Exchange/Outlook best practices do not necessarily work in a VDI environment.
When using Outlook in an Exchange environment, it is recommended to use Cached Exchange Mode. In this mode a copy of the user’s mailbox is downloaded into an OST file and stored offline on the user’s desktop. This mode offers better performance for the end user and reduces utilization on the Exchange environment as well. In addition, using Cached Exchange Mode allows users to use Outlook Instant Search for fast searching of items in their mailbox. Instant Search works by indexing the contents of the OST file so all searches occur locally and not on the Exchange server, further improving performance and reducing utilization on Exchange.
VDI environments that we see at our clients are typically configured as non-persistent or floating pools of desktops. That is, each user connects to a pool of identical desktops and grabs whatever desktop is available. When the user logs off, any changes written to the VDI desktop are discarded and the desktop returns to a pristine state. There are mechanisms and tools in place to make sure user data is retained at logoff.
So if user data is retained at logoff, why can’t we use Cached Exchange Mode in non-persistent VDI environments?
- The OST file is equal in size to the user’s mailbox so storing a 15-30GB OST (not unusual at our clients) is not that practical from a performance or storage perspective. If this data is being stored on the SAN, then you’re essentially doubling your Exchange storage (which may already be doubled or tripled if you’re using Exchange 2010 w/ DAGs). In addition, the length of time it would take to download that file every time and the I/O impact that would cause makes it completely impractical.
- OST files are not supported when stored on network shares, so redirecting the OST to a home directory is out.
- Indexing of files on virtual desktops is typically disabled to reduce I/O demands. This would prevent the use of Outlook Instant Search even if the OST was present.
For these and other reasons, Outlook is typically configured in Online mode when used with VDI. This keeps all mailbox operations and searches on the Exchange server, placing the processing and I/O burden solely on the Exchange environment. That sounds bad, but advances in Exchange technology specifically with Exchange 2010 have made this much less of an issue. In fact, Microsoft states that IOPS requirements for Cached Exchange Mode and Online mode are essentially equal now, meaning there is no I/O “penalty” for using Online mode.
Exchange 2010 Performance
Let’s take an example scenario of 500 VDI users all running Outlook in Online mode against an Exchange 2010 backend. We’ll estimate high and assume they all have a mailbox profile of 300 messages sent/received per day. According to Microsoft that amounts to a 0.3 IOPS per user requirement of 150 IOPS total, or roughly equivalent to the capabilities of one 15k RPM disk.
We can make it worse and assume that all 500 users also have Blackberry devices, which introduces a multiplier of 2.16 IOPS per user. (Note: this number is specific to Exchange 2007 as I haven’t been able to find a definitive number for Exchange 2010, but expect that the multipler will be even lower) That brings our IOPS per user calculation to 0.65 (2.16 x 0.3), bringing the total IOPS requirement for all 500 users to 324 IOPS or roughly three 15K RPM disks (excluding RAID penalty, though this is less of an issue on modern storage arrays). It is unlikely that all 500 users would have Blackberry devices and also send/receive 300 messages/day, so the actual requirement is likely lower than that.
Searching in Outlook
What about searching from Outlook? Doesn’t that impose a significant IOPS burden on the Exchange server? According to Microsoft, the penalty for searching in Online mode is just 10-15% of the database I/O based on user profile. Using our 300 messages sent/receive per day number of 0.3 IOPS/user, 15% of 0.3 is just 0.045 additional IOPS. It’s no wonder that Microsoft states “Search catalog read I/O occurs when clients issue search queries, and it’s a rare enough occurrence to not be relevant to Exchange 2010 storage design.”
In other words – it doesn’t impact the Exchange environment enough to matter. Is searching in Online mode slower than using Outlook Instant Search? No question it’s slower, but search performance has improved significantly with Exchange 2010 so it isn’t as bad as it was in the past. And the impact on the performance of the Exchange environment is almost negligible.
Quick breakdown of the numbers used above:
500 users each with a Blackberry and sending/receiving 300 messages/day = 324 IOPS
Impact of all 500 users performing searches = 0.3 x 15% x 500 = 22.5 additional IOPS
Drawbacks to Online Mode
It’s not all rainbows and unicorns when it comes to using Outlook in Online mode unfortunately. In my opinion the major drawback of using Outlook in Online Mode is not performance but rather availability.
In Exchange 2010, the RPC endpoint has been moved from the Mailbox server to the Client Access Server. This change means, among other things, that users are not interrupted when moving databases between nodes in a DAG. Unfortunately that is only true if the user is using Cached Exchange Mode, as Online Mode users experience a brief period where Outlook becomes frozen and unresponsive.
Similarly, if the Exchange environment experiences an outage then Online Mode users are completely frozen and locked out of their mailbox with no access to messages. Cached Exchange Mode users would not be able to send and receive new messages but would still have access to the contents of their mailbox since they are working off a locally cached copy.
There are many significant advances in Exchange 2010 that have reduced the overall disk I/O requirements down to a tiny fraction of what was required in previous versions. There is no longer any penalty for using Online Mode vs. Cached Exchange Mode in terms of IOPS required per user, and the example above clearly shows that it is easy to meet the I/O demands of even heavy Exchange users. The user experience may be slightly better with Cached Exchange Mode but likely not by much.
Most of the issues with Outlook in a VDI environment are around availability, not performance. Although these cannot be eliminated, properly architecting your Exchange 2010 environment can help eliminate single points of failure and provide excellent availability to users.
If you’re considering VDI and are concerned about Outlook performance, I’d strongly recommend moving to Exchange 2010. Many of the problems are addressed in Exchange 2010 and it can deliver a good Outlook experience for all VDI users.