Each new version of Exchange Server includes features, functionality and tweaks that provide greater flexibility....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Two prime examples in Exchange 2010 are the one LUN per database and two LUNs per database storage architectures.
These setups allow admins configurations that were not previously available. While they might seem to initially buck Microsoft best practices of versions past, they do offer several advantages.
The evolution of Exchange Server storage
A common rule of thumb in Exchange circles is that organizations should place mailbox databases on a separate disk from the corresponding transaction logs. If the disk containing the database fails, the transaction logs will not be affected. This lets administrators use transaction logs to bring the database back to a current state after a restore.
Exchange database and transaction log isolation still applies today, but Exchange Server and storage itself have evolved quite a bit. For example, even though Exchange Server 2007 supported continuous replication, Exchange 2010 supports database availability groups (DAGs). The way DAGs protect mailbox servers allows Exchange administrators to have more creativity when it comes to storage architecture.
Storage has also changed. Prior to Exchange 2010, Exchange Server communicated directly with individual disks or disk arrays (through the operating system). Exchange 2010 still does this, but it is becoming increasingly more common for the OS -- or virtualization platform -- to abstract physical storage. Therefore, Exchange may not always be aware of the actual storage architecture you’re using.
Exchange 2010 LUN architecture: One LUN per database
One of the storage architectures many Exchange admins use is called one LUN per database. This architecture involves placing both the mailbox database and its corresponding log files onto a single logical unit number (LUN).
This architectural setup might seem to be a direct contradiction of the best practices for Exchange storage, but it’s not. That said, Microsoft only recommends this architecture if the mailbox server is a member of a DAG and two or more copies of the database exist within the DAG.
The one LUN per database architecture offers two distinct advantages:
- It simplifies storage management. Using one LUN for each database allows admins to greatly reduce the total number of LUNs they have to manage.
- It also simplifies database performance management. Assuming that your LUNs are not sharing spindles with any other LUNs, each database’s performance is tied directly to the underlying LUN’s performance. If a database is performing poorly, you may be able to solve the problem by adding additional spindles to its LUN.
Inadequate memory can also affect database performance, so keep that in mind when diagnosing a database performance problem.
The only major disadvantage to the one LUN per database architecture is that it undermines your ability to perform hardware-level VSS-based backup and restoration. This is an issue for Exchange organizations that create snapshots of their database servers.
Exchange 2010 LUN architecture: Two LUNs per database
Two LUNs per database is another architectural option. As you might guess, this architecture involves placing each database into a dedicated LUN and using a secondary LUN for each database’s transaction logs.
The main advantage to this configuration is that it maintains logical separation between the databases and transaction logs. If a LUN fails, the recovery process is similar to a non-storage area network (SAN) environment. Furthermore, because this method isolates the transaction logs and databases into separate LUNs, you aren’t required to build a DAG -- although having a DAG is always a good idea.
On the other hand, the main disadvantage with this architecture is that storage management can become an issue for larger Exchange Server deployments. For example, Exchange supports up to 100 databases. If you maxed out Exchange Server’s capabilities, you’d end up with 200 LUNs. That would be quite difficult to manage.
Exceeding your storage hardware’s capabilities is another potential pitfall. Not all SANs can provision 200 LUNs. Of course, most Exchange Server deployments don’t use 100 databases (or 200 LUNs), but it’s important to verify your SAN’s limitations before committing to the two LUN per database architecture.
A final issue with the two LUN per database architecture is that Exchange servers will quickly run out of drive letters. Attach to each LUN using volume mount points instead of drive letters.
As you can see, Exchange Server 2010 is more flexible than previous versions of Exchange when it comes to storage architecture. However, careful storage planning is still essential to ensure adequate performance and recoverability.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
Dig Deeper on Microsoft Exchange Server Storage Management