Share via


Azure: Moving form ASM to ARM with ASR (Part 1)

Introduction

Well, what we mean with this title is that we will move some resources from the classic Azure portal (ASM) to the new portal (ARM) with Azure Site Recovery (ASR).

While doing this Proof of Concept, we will also try out a few other things that Azure made possible:

  • – create classic ASM Resources through the new ARM Portal
  • – use the new VNET peering between a VNET in ASM and a VNET in ARM

Create ASM resources through the ARM portal

The ASM design contains two Web VM’s and one SQL Server in a Cloud Service where the Web servers are load balanced on incoming HTTP requests.

Create the virtual network

https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/asmvnet.png?resize=419%2C426   https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/asmvnetdetails.png?resize=208%2C427

Quick check in the old portal shows that the provided VNET name gets changed:

https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/resultasmvnet.png?resize=1024%2C209

What we can see here is that during the creation, it has added some prefixes to the name we gave it:

group comes from ‘resource groups’

asm2arm is the name of the resource group

In the new portal, it’s mandatory to specify Resource groups (check the red asterisk next to resource group selection). However, Resource Groups are new and specific to ARM and hence not known in the old portal.

Create the Web VMs

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ws2012r2classicdeploy.png?resize=369%2C354     https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ws2012r2classicdeploydetails1.png?resize=414%2C335

https://i2.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ws2012r2classicdeploydetails3.png?resize=288%2C428        https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ws2012r2classicdeployoverview.png?resize=479%2C441

Checking the VM names after deployment shows that this went well, it didn’t add any RG prefixes to the name.

What's noticeable, is that we have selected the new F1 VM size for the WebVM’s and in the classic portal it shows as A0 Shared.

https://i2.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/vmsize1.png?resize=300%2C189 https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/vmsize2.png?resize=455%2C182

So which one won? Lets go have a look inside the VM itself (drums please).

https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/vmsize3.png?resize=368%2C70

As we can see, the VM has 2GB of RAM, which is what the F1 Size has.

What IS different than using a ARM deployment is that during the network settings we must also specify a DNS name for our cloud service. 

Looking in the old portal shows that this Cloud Service is built:

https://i2.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ASMcloudservice-1.png?resize=462%2C168

Create the Load Balancer Set

If we paid attention to the deploy settings of WebVMs, we might notice that we added an HHTP endpoint for the  Cloud Service (and its load balancer), but we actually needed to remove this one to have a fully functional load balancing over both Web VMs.

This is how it goes if we want to create the LB for the CS in the new portal:

On WebVM1 select Load Balancer Set:

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/cslbset1.png?resize=257%2C391     https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/cslbset1b.png?resize=482%2C278

Result WebVM1:

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/cslbset1c.png?resize=744%2C220

Doing the same for WebVM2, but here we select the previously created LBset:

https://i2.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/cslbset2.png?resize=281%2C300https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/cslbset2c.png?resize=474%2C128

Create SQL Server

Secondly, we deploy our SQL server. To make it easy on ourself we choose to select a SQL SKU from the Azure marketplace, which will result in a prepared and functional SQL server.

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/SQL.png?resize=737%2C231

https://i2.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/sqldetails.png?resize=475%2C528

Remark regarding the endpoints listed in ARM and what is actually set in ASM, in the output we see that the ports are mapped 1 on 1. However these settings are different in the old portal:

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/portmappings.png?resize=375%2C140

When we add endpoints in ASM, these are automatically open to the internet (with some NATing rules on them), especially for SQL ports this is not a preferred setting so we closed these down by setting an Access Control List on that:

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/ACL.png?resize=383%2C111

Checking the SQL VM in the classic portal also shows that this specific VM must be resized through the new portal:

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/sqlsize.png?resize=384%2C211

Configure the application

Now that we have all the compute available for our application, we still needed to add the application settings and data to the servers.

To do so, we have two PowerShell DSC scripts that automate this process, but even while the new portal shows the option to use ‘VM Extentions’. This will fail upon use as this is not supported on ASM VMs, so in this case we had to do this manually.

Remark: Trying out VM extentions on ASM VMs resulted in having difficulties when starting and stopping the VMs, multiple retries are required since this test.

Anyhow, the application is up and running and available through the Cloud Service DNS name we specified and web requests are load balancing between the two web servers:https://i1.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/application.png?resize=1024%2C381

https://i0.wp.com/www.prof-its.be/wp/wp-content/uploads/2017/01/loadbalancing.png?resize=1024%2C337

Conclusion

What would be better is that when we select the ‘Classic’ deployment option during VM creation it would only show us the options that are available for ASM and that the naming of the VNET is consistent.

Conclusion of this first part could be that the new portal is good to look at ASM resources, but using it to deploy ASM resources still needs some improvements.

Overview

This article is part of a series, check for the overview here:  Azure: Moving form ASM to ARM with ASR (TOC)