Month: May 2023

Configure Azure Site Recovery Zone to Zone Replication

In this post we will be going through setting up and configuring Azure Site Recovery (ASR) using zone to zone replication.

The zone to zone replication feature of Azure Site Recovery allows the replicate data and resources within the same region but across different zones. This is particularly useful for high availability of applications and services in the event of a zone outage.

Zone to Zone Replication in Azure ASR offers several advantages. It provides low recovery point objectives (RPOs) and recovery time objectives (RTOs) by continuously replicating changes. This ensures minimal data loss and enables quick failover in case of a disruption.

When configuring zone to zone replication there are a few pre-req, one is that the VM’s that are going to be replicated needs to be in an availability zone if not you wont be able to select it.

For existing VM’ the only way to move to an availability zone is through a CLI to copy and re deploy the VM.

Setting the availablity zone can be done when building the VM through the portal or using bicep /arm templates.

The second pre-req is that there is enough free IP on the subnet.

To keep the same IP address as the source VM it needs to be configured to use a static address on the network adapter settings.

To start using ASR we need to create a new recovery services vault.

To create a new ASR go to Recovery Services vaults blade in the Azure portal and click on create.

Select the subscription that the vault will be deployed, resource group, give the vault a name and set the region.

Add tags if in use and then review and create.

The deployment of the vault can take a few minutes complete.

Select the vault, go to replicated items and select Azure virtual machines.

Select the region, resource group and select the availability zone that the VM was deployed too.

Select the VM to be replicated, if the VM doesn’t show check to make sure it was deployed to an availability zone.

Next either create a new target resource group or use an existing one and select failover network.

Select availability options to specify the target zone.

Select the default or create a replication policy. I set to update extension to allow ASR to manage (this will create an Azure Automation Account).

Review setting to confirm everything is correct and enable.

If we check the site recovery jobs we should see the replication be create.

We can also see the status of the replication under replicated items.

It will take a little while for the synchronization to complete. Once completed there will be a warning, this is just alerting that the failover hasn’t been tested.

Last step will be to test failover.

If we click on the three dots beside the replicated item we then have the option to failover or test failover.

select the recover point and virtual network (for a test failover this can’t be the same as the production VNET.)

To check the status of the failover job, go to Monitoring > Site Recovery Jobs and select the failover job.

Once the job completed there should be a VM running with -test at the end of the name in the recovery resource group.

The VM will have a different IP address than the production VM, once where finished testing the last step is to clean up the failover test.

Go back to the replicated items and select cleanup test failover.

We can add in a note if we want, tick testing complete and then click ok to remove the test VM.

The cleanup job will run this will take a few minutes to complete and the test VM should now be gone.

To do the full failover is the same process just using failover.

Create Azure VNETs Using Az PowerShell

In this post we will go over creating VNETs and subnets using PowerShell, we will also be create a script to use a CSV to deploy multiple VNETs / subnets.

Azure PowerShell is a command-line tool that allows you to manage and deploy Azure resources using the PowerShell scripting language.

Azure VNETs provide a secure and isolated network environment within Azure. Subnets allow you to divide a VNET into smaller, logical segments to control network traffic and provide network segregation.

To deploy Azure VNET and subnets using Azure PowerShell, we first either need to create a resource group or use a pre existing one.

We can create a resource group using Az PowerShell

First connect to Azure PowerShell using 

Connect-AzAccount

Once connected if there is multiple subscription make sure to select the correct one before creating the resource group or any other resource.

Next we will create the resource group this requires a name and a location. 

New-AzResourceGroup -Name 'resource group name' -Location northeurope

Next we can create a VNET and subnet will be using splatting to specifying the parameters. 

$vnet = @{
  Name              = 'vnet name'
  ResourceGroupName = 'resource group'
  Location          = 'northeurope'
  AddressPrefix     = '172.17.0.0/22'
}
New-AzVirtualNetwork @vnet

Once we have a VNET created we can create the subnets. 

$vnet = Get-AzVirtualNetwork -Name "vnet name" -ResourceGroupName "resource group name"
$subnet = @{
  Name           = 'subnet name'
  VirtualNetwork = $vnet
  AddressPrefix  = '172.17.1.0/24'
}
Add-AzVirtualNetworkSubnetConfig @subnet

If we check the subnet wont be showing under the VNET.

The last step is to set virtual network config using 

 $vnet | Set-AzVirtualNetwork

Now if we check the subnets we can see the subnet.

Now that we have the command we can use these to create the script to run using a CSV.

First create the CSV file for the script I used the below headings.

Below is the full script I added some error handling incase the VNET doesn’t exist or the subnet has an error when being created.

Below is the scripts running to create two new subnets.

If we check Azure VNET we can see the new subnets.

Below shows the error handling