Deploying Infrastructure in Azure Using ARM Templates

I have recently been looking at using Azure Resource Manager templates (ARM) to deploy and redeploy resources in Azure. I haven’t really done a lot with ARM templates so I though it might be helpful to do a few test runs and try figure out how to deploy resource in Azure using ARM templates.

In this post we will be going to through creating a ARM template from an existing resource group and what we need to do to redeploy to a new resources group.

ARM Templates are JSON files that define the infrastructure and configuration that will be deploy.

https://azure.microsoft.com/en-gb/services/arm-templates/

First we are going to export the template from Azure resource group that we want to redeploy to another resource group.

Logon to the Azure portal and go to resource groups.

Select the resource group that we want to export the template from.

Go to Automation and select export template.

This will bring up the ARM template for the resource group. We can then download the template to modify, I will be using visual studio code with the Azure Resource Manager (ARM) Tools extension added to edit the template.

Once the zip file is download and extracted there will be two JSON files, parameters’ and template.

When we look at the template file itself there will be a set of parameters. There are default values for each parameters which are the names of each resource in the resource group. I remove the default values.

The parameters are what is used to define the name of the resources that are created.

When I first started to look at the ARM templates they did seem very confusing but if you break them up in to each part instead of looking at it as a whole it made a lot easier for me to understand how the template worked.

If we take the below as a example this part of the JSON defines the virtual network and subnet to be created. It sets the location, subnet prefixes and one subnet for 10.0.0.0/24.

If there are IP address assigned or the subnet need to be changed this can be updated in the JSON file.

Once the JSON file has been modified we can then use this to deploy to Azure. The two way we will be going through in this post is using Azure portal Deploy from a custom template and second we will be going through adding the parameters to the parameters JSON and deploy using PowerShell.

First we will go through the portal deployment.

Logon to the Azure portal and go to deploy from a custom template.

We could search for template using the quick start template if we don’t have a existing template

but we will be using build your own template so we will be selecting build your own template.

This image has an empty alt attribute; its file name is image-10.png

Once the blade opens click load file and select the JSON template file this will then load the template.

Click save this should then a view like the below that we can manually in put the details we want to use for the deployment.

Click next and the arm template will be validated.

Click create to start the deployment.

When I deployed the template I had some issues with the VM creation.

This was caused by a few different issue. The first was the managed disk which returned the below error.

“Parameter ‘osDisk.managedDisk.id’ is not allowed.”

I found this article on Github https://github.com/Azure/azure-quickstart-templates/issues/3290 that explained the fix was to change the manageddisk from

to the below storage account type

The second issue was to do with requireGuestProvisionSignal property. I found the below forum post that said to remove the line.

https://docs.microsoft.com/en-us/answers/questions/332816/the-property-39requireguestprovisionsignal39-is-no.html

I removed this from the JSON.

The last issue was due to the admin password not being set. To fix this I added a new parameter at the start of the template

and set it under below under os profile

Once this was done I went back to deploy a custom template and readd the details which should now have the addtional admin password field.

The deployment now completed without issue.

The resources now be deployed to the resource group.

The second method we will be going through to deploy the ARM template is to use PowerShell.

We will be using the New-AzResourceGroupDeployment command to deploy the template.

We first will be modifying the parameters file to set the names that will be used.

For the adminpassword I will be adding the password to the parameter’s file but in production this should not be done and instead use something like Azure key vault to store the password.

First we need to install the Azure module

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Next we run

Connect-AzAccount

Next we run the New-AzResourceGroupDeployment I used the verbose parameter to get more details on the deployment. We will be calling the template and parameter JSON files.

New-AzResourceGroupDeployment -ResourceGroupName "resource group"  -TemplateFile "path to template json" -TemplateParameterFile "path to parameters json" 

Below is the command running and provisioning the resources in the template.

Once the deployment completes all the resources will show under the resource group.

We can also use the ARM template to redeploy a resource that has been removed.

If we run the New-AzResourceGroupDeployment again after a resource has been deleted the deployment picks up that the missing resources and redeploys.

This was my first attempt at doing ARM and it not as complicated as I first thought I will probable do a few more post in the future after I have some more time working with ARM templates.

Configure Azure Site Recovery for VMware

Azure site recovery (ASR) is a DR / Migration tool from Microsoft and can be used to configure DR between data centers or Azure.

In this post we will be going through setting up ASR to replicate a VM from VMware to Azure.

There are some limitations for ASR these are listed the below link

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix

The main limits for VMware are guest disk need to be less than 4TB and vCenter needs to be at least 5.5.

I have a previous post on how to configured a recovery service vault so I wont be going over that again but if you need to configure here is the previous post.

https://thesleepyadmins.com/2018/11/23/azure-vm-backup-using-azure-recovery-service-vault/

Logon to Azure

Go to Recovery Services vaults

ASR1Go to the already configure vault, select Site Recovery and click on prepare infrastructureASR2Once the wizard has started select the require goalsASR3I am not running the planning tools as this is a test but it is recommended to run before starting a deployment to verify the required bandwidth. ASR4Next we will download the OVA appliance that will be imported to VMwareASR5Once the OVA has been downloaded and imported to VMware on boot up the server will require you to read / accept a licence agreement and provide an administrator password.

Give the server a name (this will show up in as the configuration server in Azure after the setup as been completed)ASR6Next step is to sign in to Azure tenant that the server will connect to for replicationASR8Next we will go through the configuration steps first step is to set the interface that will be used to connect to on-prem devices & connection back to Azure there can be two different NIC’s assigned if required. ASR9Next is to configure the Recovery vault that will be used, select the subscription, the recovery vault RG and recovery service vault that has been configured. ASR10Install the MySQL software ASR11Next a validation test will run. (I am getting a warring for memory and CPU as I didn’t have enough memory / CPU and had to edit the VM to run on less resource but it will still complete)ASR12Next is to connect to the vCenter server that is running the VM’s that are to be replicated to Azure. ASR13Last step will configure the configuration server in Azure.ASR15Once this has been completed we can go back to the Azure portal and we should now see the configuration server show under prepare infrastructure setupASR16

Select the subscription and deployment model to be used for failover I am using Resource ManagerASR17Next create a replication policy to apply to the ASR configuration server. ASR18ASR19Once the configuration is done we can now protect and replicate our on-prem VM’s , go back to site recovery and select step 1: Replicate Application ASR20Select source, source location (Configuration server on-prem)Machine type (Physical / virtual), vCenter (If virtual) and the process serverASR21Select the subscription, RG that the VM will replicate too and the deployment modelASR22Next select the server that will be replicated the VM must be powered on and be running VMware tools be available for replication other wise they will be grey-outASR23Select the required disk type, storage account ASR24last step is to assign the policy required (Multiple policy can be created base on the recovery time requirements and retention times)ASR25

Last step is to enabled replication

ASR26

Once enabled check the site recovery jobs to see the progressASR27Once replication has completed we can create a recovery plan, go to recovery Plans (Site Recovery and select Recovery planASR28Give the plan a name, select source, target , deployment type and select the VM’s that will be added to the recovery.ASR29ASR31

Azure Migrate Services Setup

With more companies looking to move workloads from on-prem to cloud providers, it can be difficult to work out the cost for current workloads.

In Azure we can utilize Azure Migrate Services.

At the time of this post VMware is only supported, this will be extended to Hyper-v in future releases. VMware VMs must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.

In this post we will be going through the process off assessing the on-prem VMware environment and view the assessment report.

The environment we will be assessing is VMware vCenter 6.7 and ESXi 6.7 and a VM running Windows Server 2016.

The architecture of the Azure Migrate Service is shown in the following diagram

AZMIG

Below is the process

  • Create a project: In Azure, create an Azure Migrate project
  • Discover the machines: Download collector VM as an OVA and import to vCenter
  • Collect the information: The collector collects VM metadata using VMware PowerCLI cmdlets. Discovery is agentless and doesn’t install anything on VMware hosts or VMs. The collected metadata includes VM information (cores, memory, disks, disk sizes, and network adapters). It also collects performance data for VMs
  • Assess the project: The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.

Logon to Azure

Go to All services search for migration projectAZMIG_1

Select Create migration project

AZMIG_2

Give the project a Name, subscription, Resource group & Geography

AZMIG_3

Select Discover & Assess AZMIG_4

Select Discover and Assess. then Discover machines AZMIG_5download OVA. The system requirement for the OVA are:

CPU: 8 vCPU’s; Memory: 16GB; HardDrive: 80GBAZMIG_6

Next step is to import the OVA to VMware

Go to vCenter

AZMIG_7

Browse to the OVA file location and selectAZMIG_8Select the Name and location of the OVAAZMIG_9Select the destination cluster AZMIG_10Click NextAZMIG_11Select destination data store and specify either thick or thin provisioned diskAZMIG_12Select the port group tha the VM will useAZMIG_13Review and confirm settingsAZMIG_14

Once the OVA is imported, power on the VM

Read and accept the license terms and give the collector an admin password.

Log into the VM and run the connector utility on the desktop.

AZMIG_15

Got through the prerequisites checksAZMIG_16

Next step is to connect to the vCenter. Put in the vCenter IP or hostname, Username / Password and once connect select the cluster or host that is currently running the VM’s that need to be assessed for migration.

AZMIG_17

Next step is to connect back to Azure using the migration project credentials that were generated when creating the projectAZMIG_19AZMIG_18

Click continue and the last screen will start the discovery this can take a while to complete (60 minutes or so)AZMIG_20

Once the discovery has completed, we then need to Create assessmentAZMIG_21

Create a new group and select the VM that will be assessedAZMIG_22

Once this has completed go to Overview and click on the assessmentAZMIG_23

Once in the assessment you can see the readiness of your VM and the Monthly estimated cost for running the workloads and AZMIG_24

Click on the VM to view specific details and performance statsAZMIG_25

We can now see what the cost will be for migrating workloads to Azure and this can be presented to give a better understanding of the cost savings that can be achieved with cloud migrations.

 

 

 

 

Azure VM Backup using Azure Recovery Service Vault

In this post I am going to go through setting up a weekly backup for VM’s using Azure Recovery Service Vault.

Recovery Services vaults protect:

  • Azure Resource Manager-deployed VMs
  • Classic VMs
  • Standard storage VMs
  • Premium storage VMs
  • VMs running on Managed Disks
  • VMs encrypted using Azure Disk Encryption
  • Application consistent backup of Windows VMs using VSS and Linux VMs using custom pre-snapshot and post-snapshot scripts

To backup a single VM we can click on the VM and go to backup and configure the Recovery Vault. I want to add all my servers at one time so I will create Recovery Vault first.

Logon on to the Azure portal: https://portal.azure.com

Once logged on go to All Services > Recovery Services vaults

Once in Recovery Services vaults click createRSV1

Give the Recovery Vault a Name, assign a subscription, resource group and location.

RSV2

Once the deployment has finished,  click on the newly create object. RSV3

First thing I am going to set the backup configuration to locally-redundant as this is just for my Lab VM’s and it will save on cost.

Go to Manage > Backup Infrastructure and set to Locally-redundant.RSV4-1

I am going to create a custom policy as I only want to backup my test VM’s once a week. go to Manage > Backup policies and click Add.RSV3-2

Once in the new backup policy configure settings as required. I have set frequency to every sunday at 22:00 and set retention to 4 weeks backups. Click create once all settings are configured. RSV3-1

The policy should now be available to assign to backup jobs. Next step is to setup the backup. Go to Getting started > backup

Select where the work load is running (Azure or on prem), I only want to backup my Azure Lab VM so I selected Azure. Next select backup type

  • VM
  • Azure File Share (in preview at the time of the post)
  • SQL server in Azure VM (in preview at the time of the post)

Select the backup policy, I am using the policy created above. RSV5

Next select the VM’s that will be backed up. RSV6

Click enable backup to finish the config.

I will kick off a manual backup job to get an initial backup.

Click on backup Item > Azure Virtual Machine > Backup nowRSV8RSV9

To view backup jobs go to Monitoring > Backup JobsRSV7

Once the backup is complete, the option to run VM restore or file level recovery becomes available.RSV10

Azure VM deployment

In this post I am going to go through setting up an Azure resource group, VNet and deployment of a basic VM. There are many different VM version that can be deployed.

Below is a table with the current VM types, sizes and description:

Type Sizes Description
General purpose B, Dsv3, Dv3,
DSv2, Dv2,
Av2, DC
Balanced CPU-to-memory ratio. Ideal for testing and development,
small to medium databases, and low to medium traffic web servers.
Compute optimized Fsv2, Fs, F High CPU-to-memory ratio.
Good for medium traffic web servers,
network appliances, batch processes, and application servers.
Memory optimized Esv3, Ev3, M,
GS, G, DSv2,
Dv2
High memory-to-CPU ratio.
Great for relational database servers,
medium to large caches, and in-memory analytics.
Storage optimized Ls High disk throughput and IO.
Ideal for Big Data, SQL, and NoSQL databases.
GPU NV, NVv2, NC,
NCv2, NCv3,
ND
Specialized virtual machines targeted for heavy graphic rendering and video editing,
as well as model training and inferencing (ND)
with deep learning. Available with single or multiple GPUs.
High performance
compute
H Our fastest and most powerful CPU virtual machines
with optional high-throughput network interfaces (RDMA).

First step for deploying a VM is to create a resource group, a resource group is basically a container object that will hold Azure objects like VNet’s, VM and any other Azure serivces that will be added to the RG . A RG can be created while deploying a VM but I prefer to create them before hand.

Logon to the Azure portal, once in the Azure portal if the resource groups tab is not showing.

Go to All services > Resource GroupsAZ1

Once on resource groups click on Add

AZ2

Give the resource group a name, select a subscription and set the location.AZ3

The resource group should only take a few seconds to create. Once created you should get an alert.

AZ4

Now that there is a resource group, we can move to the next step which is to create a new VNet. all services > Virtual networksAZ5

Once in Virtual network’s go to create virtual network. Give the Network a name, IP address space /Subnet mask, select subscription, location,  added to a resource group and set the IP range that will be available for use.

AZ6

Once completed the new VNet will show under virtual networks.AZ7

Final step is to start creating VM’s go to all services > Virtual machinesAZ8

Click on create new Virtual machine

Set the subscriptions that will be used, resource group, VM name & image type. We can also do availability options  for high availability and resilience.AZ9

Select VM size, user name and allowed ports.AZ10

Next page allows you to change the disks used for the VM (premiere SSD, standard SSD or standard HHD) if the disk is change this may reset the VM type so I would usually leave this as is, unless there is a specific reason to change.

Next step is to select the VNet / subnet that will be used for the VM.AZ11

There is auto shutdown feature in Azure. I like to use this on my Lab as it saves credit as this is only a lab server, I want the VM to shut down at 12AM. I can start the VM up again when I want to do any further testing.AZ12

I wont add any guest config, tags so the last step is to review and validate the VMAZ13

The VM should now deploy it will take a while to deploy once completed the VM will now show under Virtual Machines.AZ14

If we check the resource group, we can now see all the object contained in the resource group.AZ15