Moving your Exchange server to a storage area network (SAN) based system should be an essential part of your infrastructure...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
planning. It allows Exchange Server 2007 to host all required user email. However, knowing how to get the most out of a chosen storage array must be the cornerstone of those plans. Poor storage and infrastructure planning will result in slow Microsoft Outlook performance, and will require users to control their own email storage.
A SAN -- be it Fibre Channel or an iSCSI array -- has a number of software advantages such as Volume Copy Shadow Service (VSS) snapshot backups, disk LUN thin provisioning and LUN cloning. These enable Exchange administrators to set up lab environments and use a space-efficient copy of live stores to test backups, service packs and upgrades. The belief that using direct-attached storage (DAS) is better because SANs are more expensive is not necessarily true.
All SANs have unique benefits and pitfalls, as well as distinctive ways to manage and write disks. For example, one vendor uses an "onion ring" approach to disks to maximize performance and utilization. Another uses a RAID layout and storage-abstraction layer to maximize disk performance.
However, when it comes to disk-based snapshot backups, the performance of some SANs can drop once the platform stores more than a couple of snapshots. With other platforms, performance can seriously suffer as total disk utilization increases. The difficulty comes in knowing how best to balance the requirements of all business aspects with your Exchange-based imperatives and the budget of Exchange 2007 and storage project(s).
Separating information stores and transaction logs essential on DAS-based Exchange servers is less important on most SAN arrays. Some arrays, such as HP arrays for example, can be configured to treat networked storage as detached DAS. Some vendors assign sets of disks in the same manner as you might see on a direct-attached platform. For example, there might be RAID 1 sets for transaction logs and RAID 5, RAID 10 or RAID 0+1 for stores. These platforms should be avoided unless managed carefully.
Hot spots can be problematic in arrays where disks are configured into a particular RAID array; multiple LUNs are created on that set and presented to various servers across the infrastructure. If one server makes excessive demands on that LUN, the performance of all other servers will suffer. An Exchange administrator may not know a server is performing below expectations, but a drop in performance cannot be blamed solely on the Exchange server.
RAID configuration limitations
Recognizing shortcomings in RAID configurations is important. RAID 6 remains overlooked, primarily because administrators aren't entirely familiar with it. Despite this, RAID 6 represents an innovative improvement in SAN storage in terms of disk efficiency.
RAID 6 is an expansion of RAID 4, which takes the stripe set plus parity disk one step further by adding a second parity disk. This second disk isn't a copy of the first disk, but instead an independent parity disk that is calculated entirely differently. How that second parity is calculated is important, and it gives one vendor a performance edge over another.
What doesn't change is the requirement of keeping databases logically separate from each other. The use of a SAN doesn't mean that you can create one large LUN and put all information stores on it. While each SAN conducts snapshot backups differently, they do share one common trait. Backups and restores occur either on a LUN or volume basis.
If you have two stores on one LUN and restore the LUN that the corrupt store was residing on, everything on that LUN is overwritten. This causes unnecessary downtime for users who are unaffected by the initial corruption or failure. Administrators must wait until their store is restored and logs are replayed. A SAN-based restore process takes only a few minutes; however, you shouldn't take other stores offline without having a viable reason.
About the author: Mark Arnold, MCSE+M and Microsoft MVP, is Principal Consultant with LMA Consulting LLC, a private messaging and storage consultancy based in Philadelphia, Penn. Mark assists customers in designs of SAN-based Exchange Server implementations. He has been a Microsoft MVP in the Exchange discipline since 2001, contributes to various Microsoft-focused technology websites, and can be found in the Exchange newsgroups and other Exchange forums.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
Dig Deeper on Microsoft Exchange Server Storage Management