A key ask that Azure Site Recovery (ASR) customers often have is the ability to exclude disks from replication, either to optimize the replication bandwidth consumed or to optimize the target-side resources utilized by such disks. ASR's VMware to Azure scenario has had this capability since earlier this year. Today, we are announcing the availability of this feature for ASR&039;s Hyper-V to Azure scenario as well.
Why do customers exclude disks from replication?
Excluding disks from replication is often necessary because:
The data churned on the excluded disk is not important or doesn’t need to be replicated (or / and)
Storage and network resources can be saved by not replicating this churn
Let&039;s elaborate on what data isn&039;t “important”? The importance of replicated data is determined by its usefulness at the time of Failover. Data that is not replicated must also not be needed at the time of failover. The absence of this data should not impact the Recovery Point Objective (RPO) in any way.
What are the typical scenarios?
There are some specific examples of data churn that can be easily identified and are great candidates for exclusion – for example any page file writes, Microsoft SQL server tempdb writes etc. Depending on the workload and the storage subsystem, the page file can register a significant amount churn. However, replicating this data from the primary site to Azure would be resource intensive and completely worthless. Thus the replication of a VM with a single virtual disk having both the OS and the page file can be optimized by:
Splitting the single virtual disk into two virtual disks – one with the OS and one with the page file
Excluding the page file disk from replication
Similarly, for Microsoft SQL Server with tempdb and system database file on the same disk can be optimized by:
Keeping the system database and tempdb on two different disks
Excluding the tempdb disk from replication.
How to Exclude disk from replication?
Follow the normal Enable replication workflow to protect a VM from ASR portal. In the 4th step of Enable replication there is a new column named DISK TO REPLICATE to exclude disk from the replication. By default all the disks are selected for the replication. Unselect the VHD that you want to exclude from replication and complete the steps to enable the replication. Learn more about it in the Hyper-V to Azure(with VMM) or Hyper-V to Azure(no VMM) documentation. You can also view this video to see the feature in action.
Excluding the SQL Server tempdb disk
Let&039;s consider the Hyper-V to Azure scenario for a SQL Server virtual machine that has a tempdb which can be excluded.
Name of the Hyper-V VM: SalesDB
Disks on the source Hyper-V VM:
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1
Disk1
D:
SQL system database and User Database1
DB-Disk2 (Excluded the disk from the protection)
Disk2
E:
Temp files
DB-Disk3 (Excluded the disk from the protection)
Disk3
F:
SQL tempdb database (folder path(F:MSSQLData) –> note down the folder path before failover
DB-Disk4
Disk4
G:
User Database2
Since data churn on two disks of the VM are temporary in nature, while protecting SalesDB VM, exclude Disk2 and Disk3 from the replication. ASR will not replicate those disks and on failover those disks will not be present on the failover VM on Azure
Disks on the Azure VM after failover:
Guest OS disk#
Drive letter
Data type on the disk
DISK0
C:
OS disk
Disk1
E:
Temporary storage [Azure adds this disk and assigns the first available drive letter]
Disk2
D:
SQL system database and User Database1
Disk3
G:
User Database2
Since Disk2 and Disk3 were excluded from SalesDB VM, E: is the first drive letter from the available list. Azure assigns E: to temporary storage volume. For all the replicated disks, drive letter remains the same.
Disk3 which was SQL tempdb disk (tempdb folder path F:MSSQLData) and excluded from replication, the disk is not available on the failover VM. As a result, the SQL service is in stopped state and it needs the F:MSSQLData path.
There are two ways in which you can create this path.
Add a new disk and assign tempdb folder path or
Use existing temporary storage disk for tempdb folder path
Add a new disk:
Note down the SQL tempdb.mdf and tempdb.ldf path before failover.
From the Azure portal, add a new disk to the failover VM with the same or more size as that of source SQL tempdb disk (Disk3).
Login to the Azure VM. From the disk management(diskmgmt.msc) console initialize and format the newly added disk.
Assign the same drive letter that was used by SQL tempdb disk (F:).
Create tempdb folder on F: volume (F:MSSQLData).
Start SQL service from service console.
Use existing temporary storage disk for SQL tempdb folder path:
1. Open a command line console
2. Run SQL server in recovery mode from command line console
Net start MSSQLSERVER /f / T3608
3. Run the following sqlcmd to change the tempdb path to new path
sqlcmd -A -S <SQL server instance name>
sqlcmd -A -S SalesDB
USE master;
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = &039;E:MSSQLtempdatatempdb.mdf&039;);
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = &039;E:MSSQLtempdatatemplog.ldf&039;);
GO
4. Stop Microsoft SQL server service.
Net stop MSSQLSERVER
5. Start Microsoft SQL server service.
Net start SSQLSERVER
Refer to the following Azure guideline for temporary storage disk
Using SSDs in Azure VMs to store SQL Server TempDB and Buffer Pool Extensions
Performance best practices for SQL Server in Azure Virtual Machines
Failback (from Azure to on-premises)
Now let&039;s understand what all disks will be replicated when you do failover from Azure to your on-premises Hyper-V host. Disks that you create manually in Azure will be not be replicated. For example, if you fail over three disks and create two directly in Azure VM, only three disks which were failed over will be failed back. You can&039;t include disks created manually in failback or in re-protect from on-premises to Azure. It also does not replicate temporary storage disk to on-premises.
Failback to OLR
When failback is done to the original location, failback VM disk configuration remains the same as that of original VM disk configuration. That means the disks which were excluded from Hyper-V site to Azure, will be available on the failback VM.
In the above example, Azure VM disk configuration:
Guest OS disk#
Drive letter
Data type on the disk
DISK0
C:
OS disk
Disk1
E:
Temporary storage [Azure adds this disk and assigns the first available drive letter]
Disk2
D:
SQL system database and User Database1
Disk3
G:
User Database2
After planned failover from Azure to on-premises Hyper-V, disks on the Hyper-V VM(Original Location Replication):
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1
Disk1
D:
SQL system database and User Database1
DB-Disk2 (Excluded disk)
Disk2
E:
Temp files
DB-Disk3
(Excluded disk)
Disk3
F:
SQL tempdb database (folder path(F:MSSQLData)
DB-Disk4
Disk4
G:
User Database2
Exclude Paging file disk
Let&039;s consider the Hyper-V to Azure scenario for a virtual machine which has a pagefile disk that can be excluded.
There are two cases:
Case1: Pagefile is configured on the D: drive
Hyper-V VM disk configuration:
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1
(Excluded the disk from the protection)
Disk1
D:
pagefile.sys
DB-Disk2
Disk2
E:
User data 1
DB-Disk3
Disk3
F:
User data 2
Pagefile settings on the Hyper-V VM:
After you failover the VM from Hyper-V to Azure, disks on Azure VM:
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1
Disk1
D:
Temporary storage –> pagefile.sys
DB-Disk2
Disk2
E:
User data 1
DB-Disk3
Disk3
F:
User data 2
Since Disk1 (D:) was excluded, D: is the first drive letter from the available list, Azure assigns D: letter to temporary storage volume. Since D: is available on the Azure VM, pagefile setting of the VM remains the same.
Pagefile settings on Azure VM:
Case2: Pagefile file is configured on any other drive(other than D: drive)
Hyper-V VM disk configuration:
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1 (Excluded the disk from the protection)
Disk1
G:
pagefile.sys
DB-Disk2
Disk2
E:
User data 1
DB-Disk3
Disk3
F:
User data 2
Pagefile settings on the Hyper-V VM:
After you failover the VM from Hyper-V to Azure, disks on Azure VM:
VHD name
Guest OS disk#
Drive letter
Data type on the disk
DB-Disk0-OS
DISK0
C:
OS disk
DB-Disk1
Disk1
D:
Temporary storage –> pagefile.sys
DB-Disk2
Disk2
E:
User data 1
DB-Disk3
Disk3
F:
User data 2
Since D: is the first drive letter available from the list, Azure assigns D: to temporary storage volume. For all the replicated disks, drive letter remains the same. Since G: disk is not available system will use C: drive for pagefile.
Pagefile settings on Azure VM:
You can check out additional product information, and start replicating your workloads to Microsoft Azure using Azure Site Recovery today. You can use the powerful replication capabilities of Site Recovery for 31 days at no charge for every new physical server or virtual machine that you replicate. Visit the Azure Site Recovery forum on MSDN for additional information and to engage with other customers, or use the ASR User Voice to let us know what features you want us to enable next.
Azure Site Recovery, as part of Microsoft Operations Management Suite, enables you to gain control and manage your workloads no matter where they run (Azure, AWS, Windows Server, Linux, VMware or OpenStack) with a cost-effective, all-in-one cloud IT management solution. Existing System Center customers can take advantage of the Microsoft Operations Management Suite add-on, empowering them to do more by leveraging their current investments. Get access to all the new services that OMS offers, with a convenient step-up price for all existing System Center customers. You can also access only the IT management services that you need, enabling you to on-board quickly and have immediate value, paying only for the features that you use.
Pagefile is configured on D: drive
Pagefile file is configured on any other drive(other than D: drive)
Quelle: Azure
Published by