Seed a Database in an Exchange 2010 DAG with NetApp SAN
Picture this: You have an Exchange 2010 DAG running smoothly in a centralized datacenter — there are no replication issues, and life is good. Then the day comes when you need to implement site failover for Exchange between two datacenters. Great, you think, that shouldn’t be an issue because Exchange 2010 DAGs was designed for these types of scenario, I can implement a stretched DAG. Now, in my past experience with implementing a stretched DAG, I was not overly concerned about the configuration and setup. Instead, what I found most challenging was how I was going to get more than 20TB of data seeded.
I’ll leave the specifics of setting up the stretched DAG for a future article; for now we’re going to discuss how we get that data to the second datacenter. The one requirement was that it needed to be done with very little to no downtime at all. The native Exchange 2010 seeding process can also perform the seeding with no downtime, but as I have seen the past, trying to seed a database that has been in production for a while can fail. I’ve already written about how to manually seed an Exchange 2010 DAG database, but this process involved dismounting databases, which would cause an outage that we are trying to avoid.
When moving such large amounts of data, we needed to also consider other technologies such as the hardware and/or storage platform on which the data is residing. In my experience, Exchange 2010 servers were running as VMs on vSphere 5 using NetApp-based iSCSI a logical unit number (or LUN) to hold the databases as mount point paths. Yes, you did read that correctly: The Exchange servers were running as VMs, using the guest iSCSI initiator to connect to NetApp-based LUNs.
Seeding a Database Using SnapMirror
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
NetApp Filers have some really nice utilities that copy your provisioned volumes or qtrees, using a hardware-based snapshot, to another NetApp Volume or qtree. This process is called SnapMirror, which can be run against any NetApp filer to any destination that is another NetApp filer, even at a secondary datacenter, provided that you have adequate bandwidth. With the dual knowledge of NetApp SnapMirrors and manual seeding of databases, you can incorporate the two to get the data to the second datacenter.
A manual seeding is simply copying the edb file of the dismounted database on the destination server. Here we take the concept of manual seeding, but add a twist: Instead of copying actual edb files, we will be copying the volume of the database LUNs using SnapMirrors to the second datacenter, which also has NetApp filers. This SnapMirror will copy the whole volume, including the luns and complete file directory; when mounted to the other server it will already have the required file structure. We will only SnapMirror the database volumes because the log volumes need to be empty. Why create more work when you can create the log volumes from scratch on the secondary site?
So why don’t I just create a new database that replicates to the second datacenter, followed by a migration of mailboxes to the new database? This would require that I have enough disk space and time to do the migrations — both of which are limited. Before performing any SnapMirror, please get a good backup of your Exchange databases and your server.
You may need to have the Storage engineers perform the SnapMirror process for you if you do not have access. The process can be performed using the NetApp OnCommand System Manager or using SSH connection. I will show you how to do it through the OnCommand System Manager.
Performing a SnapMirror of an Exchange 2010 Database Volume
Open your NetApp OnCommand System Manager and connect to your source filer. This is the filer that contains the volumes for your Exchange database.
Navigate to SnapMirror. Select Create to make the SnapMirror relationship.
The SnapMirror wizard will appear. Select the current filer as your source for the SnapMirror, then select Next.
Select your source volume (this is the volume for your Exchange databases). Browse to the volume that will be SnapMirrored to the secondary site. Select Next.
Select the filer that you will be using through the drop-down menu. Select Next.
In the Destination Details page, select Create a New Volume. Next, select an aggregate in which the new volume will be created, as shown below.
On the Schedule and Initialize page, select On Demand, then select Initialize SnapMirror Relationship.
On the Data Transfers rate page, select Unlimited. (Confirm with your networking team prior to doing this.) If there is a specific rate that your networking team has instructed you to use, select Limit Data Transfer Rate .
Confirm your settings and select Finish.
The time it takes to complete will depend on your network bandwidth to the secondary datacenter as well as the size of your volume that needs to be mirrored.
Completing the SnapMirror Process
Using SnapDrive, create all the log luns you will need on the secondary site server. The mount path should be identical to the one in your primary site.
After SnapMirror completes, you will need to run an update to the relationship so that the destination volume is current with the source volume. Note: If you don’t preform the update your seeding will fail!
Right-click on the SnapMirror relationship, then select Update.
Confirm the update details, then select Update.
When the update has completed you will need to break the SnapMirror relationship. The break allows the destination volume to be used as a writable volume, prior to a break the volume is not writable. To do this, right-click on the SnapMirror relationship and choose Break.
Next, you will need to delete the SnapMirror. Right-click on the SnapMirror and select Delete.
Immediately after the deletion, connect the LUN to the other DAG member server in your secondary datacenter. Open SnapDrive on the secondary datacenter DAG member server, and connect your LUN. If you’re connecting through fiber instead of iSCSI, ensure that your initiators are connected to the LUNs from the filer.
When mounting your LUN, make sure that the mount paths are identical to the source database server. For example, if MBdb1234.edb was located in E:\Exchange Databases\data11, you will need to mount the new LUN as the same path on the new server.
Using the Exchange Management Console (EMC) on the secondary datacenter server, right-click on the database that will get a database copy. Select Add Database Copy.
Select the DAG member server which will hold the database copy. Select Next.
You will get a warning message after the database copy wizard finishes that the server couldn’t communicate with the Exchange Replication service. You can ignore this warning, so go ahead and click Finish.
The Exchange replication service will kick in and try to update and sync the databases. If you select Refresh on the database view, you will see that database goes into a disconnected and then resynchronizing state.
You will need to perform a SnapMirror for your remaining database volumes.
High availability in Exchange 2010 DAG is a great feature that can utilize multiple datacenters to provide site failover. Now with these added features is the challenge of the getting the data to the secondary site after you already have an established DAG. Traditional seeding methods using the EMC or EMS can be time consuming at times and may fail due to the large differences in log files. You will also have to consider the disk space required if you choose to seed by creating a new database and instantly replicating to the secondary site, with a mailbox migration following the creation.
Using NetApp SnapMirror is the “quick ‘n dirty” method — it may not be the method everybody should use, but it is an option that is available for anybody using NetApp storage. I would recommend that you evaluate your options to determine if this method is the right choice for your particular environment for seeding remotely on onsite. If it is, then good luck!