acrofix

Author: Ankita Dutta

articles/site-recovery/azure-to-azure-architecture.md

@@ -27,7 +27,7 @@ The components involved in disaster recovery for Azure VMs are summarized in the
 **Source VM storage** | Azure VMs can be managed, or have non-managed disks spread across storage accounts.<br/><br/>[Learn about](azure-to-azure-support-matrix.md#replicated-machines---storage) supported Azure storage.
 **Source VM networks** | VMs can be located in one or more subnets in a virtual network (VNet) in the source region. [Learn more](azure-to-azure-support-matrix.md#replicated-machines---networking) about networking requirements.
 **Cache storage account** | You need a cache storage account in the source network. During replication, VM changes are stored in the cache before being sent to target storage.  Cache storage accounts must be Standard.<br/><br/> Using a cache ensures minimal impact on production applications that are running on a VM.<br/><br/> [Learn more](azure-to-azure-support-matrix.md#cache-storage) about cache storage requirements. 
-**Target resources** | Target resources are used during replication, and when a failover occurs. Site Recovery can set up target resource by default, or you can create/customize them.<br/><br/> In the target region, check that you're able to create VMs, and that your subscription has enough resources to support VM sizes that will be needed in the target region. 
+**Target resources** | Target resources are used during replication, and when a failover occurs. Site Recovery can set up target resource by default, or you can create/customize them.<br/><br/> In the target region, check that you're able to create VMs, and that your subscription has enough resources to support VM sizes that are needed in the target region. 
 
 ![Diagram showing source and target replication.](./media/concepts-azure-to-azure-architecture/enable-replication-step-1-v2.png)
 
@@ -49,8 +49,8 @@ When you enable replication for a VM, Site Recovery gives you the option of crea
 
 You can manage target resources as follows:
 
-- You can modify target settings as you enable replication. Please note that the default SKU for the target region VM is the same as the SKU of the source VM (or the next best available SKU in comparison to the source VM SKU). The dropdown list only shows relevant SKUs of the same family as the source VM (Gen 1 or Gen 2).
-- You can modify target settings after replication is already working. Similar to other resources such as the target resource group, target name, and others, the target region VM SKU can also be updated after replication is in progress. A resource which cannot be updated is the availability type (single instance, set or zone). To change this setting, you need to disable replication, modify the setting, and then reenable. 
+- You can modify target settings as you enable replication. Note that the default SKU for the target region VM is the same as the SKU of the source VM (or the next best available SKU in comparison to the source VM SKU). The dropdown list only shows relevant SKUs of the same family as the source VM (Gen 1 or Gen 2).
+- You can modify target settings after replication is already working. Similar to other resources such as the target resource group, target name, and others, the target region VM SKU can also be updated after replication is in progress. A resource, which cannot be updated is the availability type (single instance, set or zone). To change this setting, you need to disable replication, modify the setting, and then reenable. 
 
 ## Replication policy 
 
@@ -95,13 +95,13 @@ The following table explains different types of consistency.
 
 **Description** | **Details** | **Recommendation**
 --- | --- | ---
-A crash consistent snapshot captures data that was on the disk when the snapshot was taken. It doesn't include anything in memory.<br/><br/> It contains the equivalent of the on-disk data that would be present if the VM crashed or the power cord was pulled from the server at the instant that the snapshot was taken.<br/><br/> A crash-consistent doesn't guarantee data consistency for the operating system, or for apps on the VM. | Site Recovery creates crash-consistent recovery points every five minutes by default. This setting can't be modified.<br/><br/>  | Today, most apps can recover well from crash-consistent points.<br/><br/> Crash-consistent recovery points are usually sufficient for the replication of operating systems, and apps such as DHCP servers and print servers.
+A crash consistent snapshot captures data that was on the disk when the snapshot was taken. It doesn't include anything in memory.<br/><br/> It contains the equivalent of the on-disk data that would be present if the VM crashed or the power cord was pulled from the server at the instant that the snapshot was taken.<br/><br/> A crash-consistent doesn't guarantee data consistency for the operating system, or for apps on the VM. | Site Recovery creates crash-consistent recovery points every five minutes by default. This setting can't be modified.<br/><br/>  | Today, most apps can recover well from crash-consistent points.<br/><br/> Crash-consistent recovery points are sufficient for the replication of operating systems, and apps such as DHCP servers and print servers.
 
 ### App-consistent
 
 **Description** | **Details** | **Recommendation**
 --- | --- | ---
-App-consistent recovery points are created from app-consistent snapshots.<br/><br/> An app-consistent snapshot contain all the information in a crash-consistent snapshot, plus all the data in memory and transactions in progress. | App-consistent snapshots use the Volume Shadow Copy Service (VSS):<br/><br/>   1) Azure Site Recovery uses Copy Only backup (VSS_BT_COPY) method which does not change Microsoft SQL's transaction log backup time and sequence number </br></br> 2) When a snapshot is initiated, VSS perform a copy-on-write (COW) operation on the volume.<br/><br/>   3) Before it performs the COW, VSS informs every app on the machine that it needs to flush its memory-resident data to disk.<br/><br/>   4) VSS then allows the backup/disaster recovery app (in this case Site Recovery) to read the snapshot data and proceed. | App-consistent snapshots are taken in accordance with the frequency you specify. This frequency should always be less than you set for retaining recovery points. For example, if you retain recovery points using the default setting of 24 hours, you should set the frequency at less than 24 hours.<br/><br/>They're more complex and take longer to complete than crash-consistent snapshots.<br/><br/> They affect the performance of apps running on a VM enabled for replication. 
+App-consistent recovery points are created from app-consistent snapshots.<br/><br/> An app-consistent snapshot contain all the information in a crash-consistent snapshot, plus all the data in memory and transactions in progress. | App-consistent snapshots use the Volume Shadow Copy Service (VSS):<br/><br/>   1) Azure Site Recovery uses Copy Only backup (VSS_BT_COPY) method, which does not change Microsoft SQL's transaction log backup time and sequence number </br></br> 2) When a snapshot is initiated, VSS perform a copy-on-write (COW) operation on the volume.<br/><br/>   3) Before it performs the COW, VSS informs every app on the machine that it needs to flush its memory-resident data to disk.<br/><br/>   4) VSS then allows the backup/disaster recovery app (in this case Site Recovery) to read the snapshot data and proceed. | App-consistent snapshots are taken in accordance with the frequency you specify. This frequency should always be less than you set for retaining recovery points. For example, if you retain recovery points using the default setting of 24 hours, you should set the frequency at less than 24 hours.<br/><br/>They're more complex and take longer to complete than crash-consistent snapshots.<br/><br/> They affect the performance of apps running on a VM enabled for replication. 
 
 ## Replication process
 
@@ -162,17 +162,17 @@ Allow HTTPS outbound: port 443 | Allow ranges that correspond to Azure Key Vault
 Allow HTTPS outbound: port 443 | Allow ranges that correspond to Azure Automation Controller (This is required only for enabling auto-upgrade of mobility agent for a replicated item via portal) | GuestAndHybridManagement
 
 
-#### Control access with NSG rules
+#### Control access with Network Security Group rules
 
-If you control VM connectivity by filtering network traffic to and from Azure networks/subnets using [NSG rules](../virtual-network/network-security-groups-overview.md), note the following requirements:
+If you control VM connectivity by filtering network traffic to and from Azure networks/subnets using [Network Security Group rules](../virtual-network/network-security-groups-overview.md), note the following requirements:
 
-- NSG rules for the source Azure region should allow outbound access for replication traffic.
+- Network Security Group rules for the source Azure region should allow outbound access for replication traffic.
 - We recommend you create rules in a test environment before you put them into production.
 - Use [service tags](../virtual-network/network-security-groups-overview.md#service-tags) instead of allowing individual IP addresses.
     - Service tags represent a group of IP address prefixes gathered together to minimize complexity when creating security rules.
     - Microsoft automatically updates service tags over time. 
 
-Learn more about [outbound connectivity](azure-to-azure-about-networking.md#outbound-connectivity-using-service-tags) for Site Recovery, and [controlling connectivity with NSGs](concepts-network-security-group-with-site-recovery.md).
+Learn more about [outbound connectivity](azure-to-azure-about-networking.md#outbound-connectivity-using-service-tags) for Site Recovery, and [controlling connectivity with Network Security Groups](concepts-network-security-group-with-site-recovery.md).
 
 
 ### Connectivity for multi-VM consistency

articles/site-recovery/azure-to-azure-how-to-enable-replication-s2d-vms.md

@@ -1,30 +1,30 @@
 ---
-title: Replicate Azure VMs running Storage Spaces Direct with Azure Site Recovery 
-description: Learn how to replicate Azure VMs running Storage Spaces Direct using Azure Site Recovery.
+title: Replicate Azure virtual machines running Storage Spaces Direct with Azure Site Recovery 
+description: Learn how to replicate Azure virtual machines running Storage Spaces Direct using Azure Site Recovery.
 ms.author: ankitadutta
 author: ankitaduttaMSFT
 manager: rochakm
 ms.topic: how-to
-ms.date: 01/29/2019
+ms.date: 02/19/2024
 ms.service: site-recovery
 
 ---
 
-# Replicate Azure VMs running Storage Spaces Direct to another region
+# Replicate Azure virtual machines running Storage Spaces Direct to another region
 
-This article describes how to enable disaster recovery of Azure VMs running storage spaces direct.
+This article describes how to enable disaster recovery of Azure virtual machines running storage spaces direct.
 
 >[!NOTE]
 >Only crash consistent recovery points are supported for storage spaces direct clusters.
->
 
-[Storage spaces direct (S2D)](/windows-server/storage/storage-spaces/deploy-storage-spaces-direct) is software-defined storage, which provides a way to create [guest clusters](https://techcommunity.microsoft.com/t5/failover-clustering/bg-p/FailoverClustering) on Azure.  A guest cluster in Microsoft Azure is a failover cluster comprised of IaaS VMs. It allows hosted VM workloads to fail over across guest clusters, achieving higher availability SLA for applications, than a single Azure VM can provide. It is useful in scenarios where a VM hosts a critical application like SQL or scale-out file server.
+
+[Storage spaces direct (S2D)](/windows-server/storage/storage-spaces/deploy-storage-spaces-direct) is software-defined storage, which provides a way to create [guest clusters](https://techcommunity.microsoft.com/t5/failover-clustering/bg-p/FailoverClustering) on Azure.  A guest cluster in Microsoft Azure is a failover cluster comprised of IaaS virtual machines. It allows hosted virtual machine workloads to fail over across guest clusters, achieving higher availability SLA for applications, than a single Azure virtual machine can provide. It is useful in scenarios where a virtual machine hosts a critical application like SQL or scale-out file server.
 
 ## Disaster recovery with storage spaces direct
 
 In a typical scenario, you may have virtual machines guest cluster on Azure for higher resiliency of your application like Scale out file server. While this can provide your application higher availability, you would like to protect these applications using Site Recovery for any region level failure. Site Recovery replicates the data from one region to another Azure region and brings up the cluster in disaster recovery region in an event of failover.
 
-Below diagram shows a two-node Azure VM failover cluster using storage spaces direct.
+Below diagram shows a two-node Azure virtual machine failover cluster using storage spaces direct.
 
 ![storagespacesdirect](./media/azure-to-azure-how-to-enable-replication-s2d-vms/storagespacedirect.png)
 
@@ -37,12 +37,12 @@ Below diagram shows a two-node Azure VM failover cluster using storage spaces di
 **Disaster Recovery Considerations**
 
 1. When you are setting up [cloud witness](/windows-server/failover-clustering/deploy-cloud-witness#CloudWitnessSetUp) for the cluster, keep witness in the Disaster Recovery region.
-2. If you are going to fail over the virtual machines to the subnet on the DR region which is different from the source region then cluster IP address needs to be change after failover.  To change IP of the cluster you need to use the Site Recovery [recovery plan script.](./site-recovery-runbook-automation.md)</br>
-[Sample script](https://github.com/krnese/azure-quickstart-templates/blob/master/asr-automation-recovery/scripts/ASR-Wordpress-ChangeMysqlConfig.ps1) to execute command inside VM using custom script extension 
+2. If you are going to fail over the virtual machines to the subnet on the disaster recovery region, which is different from the source region then cluster IP address needs to be change after failover.  To change IP of the cluster, you need to use the Site Recovery [recovery plan script.](./site-recovery-runbook-automation.md)</br>
+[Sample script](https://github.com/krnese/azure-quickstart-templates/blob/master/asr-automation-recovery/scripts/ASR-Wordpress-ChangeMysqlConfig.ps1) to execute command inside virtual machine using custom script extension 
 
 ### Enabling Site Recovery for S2D cluster:
 
-1. Inside the recovery services vault, click “+replicate”
+1. Inside the recovery services vault, select **+replicate**
 1. Select all the nodes in the cluster and make them part of a [Multi-VM consistency group](./azure-to-azure-common-questions.md#multi-vm-consistency)
 1. Select replication policy with application consistency off* (only crash consistency support is available)
 1. Enable the replication
@@ -55,20 +55,23 @@ Below diagram shows a two-node Azure VM failover cluster using storage spaces di
    ![Screenshot that shows the virtual machines are protected and a part of a multi-VM consistency group.](./media/azure-to-azure-how-to-enable-replication-s2d-vms/storagespacesdirectgroup.PNG)
 
 ## Creating a recovery plan
+
 A recovery plan supports the sequencing of various tiers in a multi-tier application during a failover. Sequencing helps maintain application consistency. When you create a recovery plan for a multi-tier web application, complete the steps described in [Create a recovery plan by using Site Recovery](site-recovery-create-recovery-plans.md).
 
 ### Adding virtual machines to failover groups
 
 1.	Create a recovery plan by adding the virtual machines.
-2.	Click on 'Customize' to group the VMs. By default, all VMs are part of 'Group 1'.
+2.	Select on 'Customize' to group the virtual machines. By default, all virtual machines are part of `Group 1`.
 
 
 ### Add scripts to the recovery plan
+
 For your applications to function correctly, you might need to do some operations on the Azure virtual machines after the failover or during a test failover. You can automate some post-failover operations. For example, here we are attaching load balancer and changing cluster IP.
 
 
 ### Failover of the virtual machines 
-Both the nodes of the VMs need to be fail over using the Site Recovery [recovery plan](./site-recovery-create-recovery-plans.md) 
+
+Both the nodes of the virtual machines need to be fail over using the Site Recovery [recovery plan](./site-recovery-create-recovery-plans.md) 
 
 ![storagespacesdirect protection](./media/azure-to-azure-how-to-enable-replication-s2d-vms/recoveryplan.PNG)
 
@@ -90,6 +93,8 @@ For more information, see [Test failover to Azure in Site Recovery](site-recover
 4.	To start the failover process, select the recovery point.
 
 For more information, see [Failover in Site Recovery](site-recovery-failover.md).
+
 ## Next steps
 
 - [Learn more](./azure-to-azure-tutorial-failover-failback.md) about running failback.
+