Microsoft provides a large number of guidelines for how to properly configure storage systems that are used in conjunction with Exchange implementations. But an area where Microsoft often still comes up short is in providing best practices for configuring Exchange in conjunction with today’s next generation storage systems. Many of Microsoft’s storage recommendations are based on the assumption that organizations are deploying either direct attached storage (DAS) or storage systems with traditional RAID architectures. But with next generation storage systems such as the 3PAR InServ Storage Server that deliver features such as wide striping, old rules for Exchange storage configurations do not always apply.
To better understand how to balance existing Microsoft recommendations for Exchange storage configurations with new capabilities on modern storage systems, I recently had the opportunity to discuss these issues with Bill Plein, a storage architect on 3PAR’s Strategic Accounts Engineering Team. Bill serves as the liaison between 3PAR and its clients in their Exchange deployments and endeavors to provide storage configurations that best satisfy customer requirements for capacity and performance while still falling in line with Microsoft recommendations which is not always easy to do.
A number of the problems that Plein encounters in the field stem in part from assumptions originally made when Microsoft developed its best practices for storage configurations for its release of Exchange 2007. As part of that release, Microsoft tried to correct some complexity and performance issues that arose from Exchange 2003 deployments where there were numerous suboptimal disk configurations. In particular, smaller organizations were encountering issues when deploying Microsoft Exchange on SANs as they had few, if any, best practices for managing Exchange on SAN implementations in place.
To try to improve this situation, Microsoft came out with a very strong framework around DAS for those shops that had smaller storage configurations. The problem that Microsoft specifically was trying to solve was to dispel the notion that a SAN was necessary to support Exchange. Microsoft found that in these smaller environments introducing a SAN actually added complexity and reliability problems to an Exchange implementation. To counter this “SAN is a requirement” argument, Microsoft developed many of its best practices from the viewpoint that organizations did not need to deploy a SAN in order to support Exchange and framed many of its recommendations on how to support Exchange using DAS.
The trick is that as you move from small to large organizations, Microsoft’s recommendations for best practices for Exchange storage configurations do not change to account for the storage technologies that these size organizations use. Rather they are tailored for the lowest common denominator such as what you might encounter in a small organization. So when large organizations roll out Exchange and call in an Exchange expert to help them configure and implement it, the expert may view storage from this more limited DAS viewpoint and does not recognize new features that next generation storage systems offer.
A prime example of this is the Windows ‘diskpart‘ command. Exchange best practices call for administrators to run the ‘diskpart’ utility to align a partition with the underlying physical disk. If you do not run this command from Windows, Exchange data may be written to two disks instead of one because of how Windows, by default, starts a partition on the last sector of a disk. However by running ‘diskpart’ before installing Exchange, you can avoid unnecessary disk or stripe crossings since ‘diskpart’ starts a partition on the first sector of a disk so there is an increased likelihood that all Exchange data ends up on a single disk drive which improves Exchange performance.
Unfortunately ‘diskpart’ assumes that it is working with a traditional RAID architecture such as RAID 1 or RAID 5 so it follows traditional RAID boundaries. This is not the case with storage systems like the 3PAR InServ Storage Server which uses wide striping as it by default disperses Exchange data across most of the disk drives in its system. So while putting Exchange data on wide striping almost always results in better performance than even what following Microsoft’s best practices will deliver, it may not technically meet the specifics cited Microsoft’s best practices for implementing and configuring Exchange in these enterprise environments.
The good news is that 3PAR provides a mechanism to meet Microsoft’s best practices for Exchange deployments and still automate storage management using wide striping without the need to re-introduce the overhead typically associated with managing and configuring storage volumes using its template feature. I’ll get into how 3PAR’s template feature works in an upcoming blog so that users can follow Microsoft best practices for Exchange storage configurations, still leverage 3PAR’s wide striping feature and even potentially further improve Exchange’s performance running on a 3PAR system.