This post wraps up our 11-part series on Nimble OS 2.1 with a look at some great new features for Microsoft Exchange Server.
A bit of background first on deploying Microsoft Exchange on Nimble Storage. Nimble is able to store 10-15X more mailboxes per disk than legacy SAN vendors due to our unique CASL architecture. In the past Nimble has provided two Exchange Solution Review Program (ESRP) submissions for Exchange 2010. This is a standard Microsoft benchmark using Jetstress that most storage vendors publish results for. The Nimble results can be found here:
20,000 mailboxes on a CS240G: http://bit.ly/1rHv2Nr
40,000 mailboxes on a CS460G-X2: http://bit.ly/1fiBZsk
Well with the advent of Nimble OS 2.1 and the CS700 platform we’ve submitted a new ESRP but this time for Exchange 2013:
100K mailboxes on a CS700: http://bit.ly/TFfw4V (this one has additional flash and one expansion shelf)
Remember these are 3U arrays with proven uptime of over 99.999% that draw 450-560W of power. Our always on in-line compression greatly reduces the capacity required for Exchange without compromising on performance (approximately 1.6X reduction as measured across our customer base). Due to the capacity density and performance profile of Nimble arrays the cost per mailbox is industry leading.
Additionally, built in to the Nimble arrays is best of breed data protection with hardware snapshots that enable our customers to store literally hundreds of recovery points (up to a 1,000 for any volume) whilst only consuming a fraction of capacity. Recovery from our hardware snapshots only takes seconds to complete. Zero Copy Clones allows our customers to clone and mount a snapshot backup for single item search and/or recovery, for testing purposes, and best of all our clones don’t consume any additional space or require a software license!
The snapshot backups are fully integrated with the Microsoft Volume Shadow Copy Service (VSS) on the host via the lightweight Nimble Windows Toolkit which contains a VSS requestor and hardware provider which works in conjunction with the Exchange VSS writer to ensure all snapshots are application consistent. This enables full snapshot backups to be taken of Exchange data in milliseconds without impact to the application.
Consider a DAG architecture for Exchange 2010 or 2013. A DAG (or Database Availability Group) is simply a Windows Server Failover Cluster that manages multiple copies of a database running on different hosts. The concept is one of the databases will be active and the others replica’s which can be activated in the event that the normally active one fails for any reason (network failure, card failure, database issue and so on). The diagram below illustrates a typical DAG configuration where two copies are available in the production site and another is available in the DR site. Data changes are replicated by Exchange by transferring log files between hosts and database copies.
With Nimble you can configure full snapshot backups to occur not only on the active database copy, but also on the replica database copies. The schedule and retention on each database copy can be different but you must ensure that only one copy of a database is being backed up at a time so therefore stagger you snapshots so that the active and replica backups don’t overlap.
You can only restore the active database copy in Exchange, however if you need to restore a replica copy from a snapshot backup it is possible using the method below:
- Remove replica database copy from the DAG
- Add the database replica back in but with seeding postponed
- Restore the volumes back to the last snapshot
- Resume seeding on the replica
This process effectively performs an incremental reseed of the replica copy i.e. only the differences between the active copy (up to date) and the point in time to which the replica was restored to (time of snapshot in step 3) are replicated.
This snapshot integration has been available in previous Nimble OS versions, but with the release of 2.1 some new functionality is available for Exchange 2010/13; the ability to truncate Exchange transaction logs without requiring a database verification. Previous Nimble OS versions always required database verification to perform log truncation and this added a heavy sequential (256KB) read operation through the database. This is fine if you’re not 24/7 but if you are or have other critical tasks to run each evening this new functionality removes the unnecessary IO load.
To leverage this functionality you must be in a supported configuration as outlined by Microsoft; “For databases in a DAG that has two or more healthy copies, the database consistency checking step can even be skipped”
So how do you leverage this new backup capability where database verification isn’t needed? Here’s the steps:
1. Upgrade your arrays to Nimble OS 2.1 (non-disruptive).
2. Upgrade the version of the Nimble Windows Toolkit (NWT) on the Exchange hosts to 2.1.
This will require a host reboot (as a newer Nimble DSM gets installed) so plan this during a maintenance window or fail over your active database copies to another DAG member server
Note: You should upgrade in this order (Nimble OS then NWT) because NWT1.x/2.0 works with Nimble OS 2.1 and scheduled VSS snapshots will continue to work as expected until the toolkit is upgraded. In place upgrade from NWT2.0 to NWT2.1 is possible, however if you are running NWT1.x you need to uninstall before installing NWT2.1.
3. Edit you volume collections for Exchange and change the “Application” to “MS Exchange Server 2010 or later w/ DAG”. Note you only need to do this on the volume collections you normal verify Exchange on.
4. Then click on the Schedules tab and you’ll see a new option under the “Verify backups” area to “Skip consistency check for database files”
Note that if you hover over the “not recommend” link next to this it highlights the following:
So you must have two or more copies of each database in the DAG to leverage this.
Note: We don’t explicitly check that two or more database copies are available, that’s the responsibility of the admin.
Now when we perform the backup (with verify) we only verify the logs (as per Microsoft’s requirement). No database file (EDB) verification is undertaken and that means much quicker backups and more IO available for other tasks.
And that’s it you’re done. Simple.
I hope you found this blog useful, if you have comments or questions please post below.
You can find the entire Nimble OS 2.1 blog series here: https://connect.nimblestorage.com/docs/DOC-1391