Understanding Exchange 2010 LUN Architecture
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
In many cases, the physical disk, or optimal logical unit number (LUN), that the operating system recognizes is abstracted from the hardware used to present the disk to the operating system. LUN architecture is used in Microsoft Exchange Server 2010.
Although there are many ways to design LUNs in Exchange 2010, we recommend the following designs to limit complexity:
One LUN per Database
Two LUNs per Database
Two LUNs per Backup Set
One LUN per Database
Single LUN per database architecture means that both the database and its corresponding log files are placed on the same LUN. To deploy a LUN architecture that only uses a single LUN per database, you must have a database availability group (DAG) that has two or more copies, and not be using a hardware-based Volume Shadow Copy Service (VSS) solution.
Some of the benefits of this strategy include:
Simplifies storage administration with fewer LUNs to manage.
Reduces (potentially) the number of backup jobs.
Provides flexibility to isolate the performance between databases when not sharing spindles between LUNs.
A concern with this strategy is that it limits the ability to perform hardware-based VSS backup and restore procedures (for example, clone snapshots). For VSS details, see Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003.
Return to top
Two LUNs per Database
With Exchange 2010, in the maximum case of 100 databases, the number of LUNs you provision will depend upon your backup strategy. If your recovery time objective is small, or if you use VSS clones for fast recovery, it may be best to place each database on its own transaction log LUN and database LUN. This approach will exceed the number of available drive letters; therefore, volume mount points must be used.
Some of the benefits of this strategy include:
Enables hardware-based VSS at a database level, providing single database backup and restore.
Provides flexibility to isolate the performance between databases when not sharing spindles between LUNs.
Increases reliability because a capacity or corruption problem on a single LUN will only impact one database. This is an important consideration when you aren't leveraging the built-in mailbox resiliency features.
Some of the concerns with this strategy include:
100 databases require 200 LUNs, which could exceed some storage array maximums.
A separate LUN for each database causes more LUNs per server, which increases administrative costs and complexity.
Return to top
Two LUNs per Backup Set
A backup set is the number of databases fully backed up in a night. A solution that performs a full backup on 1/7th of the databases nightly (for example, using a weekly or bimonthly full backup with daily incremental or differential backups) can reduce complexity by placing all of the databases to be backed up on the same log and database LUN. This can reduce the number of LUNs on the server.
Some of the benefits of this strategy include:
Simplifies storage administration with fewer LUNs to manage.
Reduces (potentially) the number of backup jobs.
Some of the concerns with this strategy include:
The ability to perform hardware-based VSS backup and restore procedures (for example, clone snapshots) is limited. For VSS details, see Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003.
A capacity or corruption problem on a single LUN could impact more than one database.
Return to top
© 2010 Microsoft Corporation. All rights reserved.