Getting Started with Infrastructure Services on Azure

One of the benefits of building your application on Azure Infrastructure services is that you can completely control your virtual machines, so it's much easier to lift and shift an application you have deployed elsewhere or if you are deploying an application that requires components not available on Azure App Service. It is important, however, that you understand how best to deploy your virtual machines so you have a secure and highly available infrastructure. During this blog post I will deploy a simple WordPress site and demonstrate how to secure this infrastructure using Virtual Networks as well as discuss high availability options.

First, Some Theory

Before we jump straight in let me explain a couple of concepts that you really need to understand before working with Azure Infrastructure Services.

Always Start with a Virtual Network

It is possible to jump straight into Azure and spin up a VM. You will be able to select from a wide range of Images, both Microsoft and Third Party, and define the size of VM, depending on it's function and if you need high memory or processing power. Check out this document on all of the different VM sizes available and this one for the types of VM images you can create. However, if you want to separate the tiers of your application, e.g. application and database tiers, into separate subnets and control access between, or if you want to completely block public access to a range of virtual machines, then you really need to start with a virtual network. Actually, I would say, always start with a Virtual Network as you never know when you will need it and it costs you nothing to use it. In fact, now whenever you create a VM a new Vnet will be created for you, so it's just good practise.

Understand Availability Sets

The fact is that there are situations where your virtual machines may be rebooted, and this could be during planned or unplanned maintenance. Obviously, this scenario is avoided as much as possible using live migration where appropriate and you may never actually experience it, but if you are planning for high availability then you should design with this in mind. Start by fully understanding our planned and unplanned maintenance policies for virtual machines.

To achieve high availability and a service level agreement you must place your VMs in an availability set. This will allow you to spread your VMs across fault and update domains. Fault domains are separate facilities within a region that have separate power and networking and are highly unlikely to fail at the same time and update domains are stamps within the data centre that are updated in turn, so no two stamps are updated at the same time. By spreading your VMs across update and fault domains you can survive both planned and unplanned maintenance as well as achieve an SLA of 99.95% uptime. Because VMs within an availability set may be rebooted during maintenance (always leaving at least one running) then there is no point mixing roles within an availability set. That is, don't place an app server and a database server in the same availability set, instead create two availability sets, one for your app servers and one for your database servers. You should also note that Micro soft have no knowledge of what is running inside your VM, that's the benefit of control you have, so it is up to you to ensure your application or database can work this way, i.e. that your application is stateless or stores its state in a central location and that your database is replicated across VMs.

You should also be aware that having a VM without an availability set is perfectly supported and this is a useful scenario if you manage your application availability some other way (e.g. with a cache or queuing mechanism) or if the VM is not running a critical workload. In this scenario if we need to reboot your VM you will get a one week email notification. So make sure your Azure account email address is monitored.

Creating the Infrastructure

In the following steps I will create a virtual network with two subnets, one for our web servers (WordPress) and another for a database server. In the app subnet I will create an availability set with two VMs and show how to setup load balancing between them.

Create a Resource Group and Virtual Network

All of the steps below will be taken with the new portal at portal.azure.com.

Start by creating a new Resource Group. On the left menu click Browse->Resource Groups-> New.  We will place all of our resources into this resource group. Doing this allows us to control everything within our app, like apply access rights, tear down the entire application or export the template for future deployments.

Next create a new Virtual Network (VNet). Browse-> Virtual Networks-> New. Change the subnet to appsubnet and select the resource group created earlier. I always change the address range to 10.1.1.0/24 so that my web servers have an IP address of 10.1.1.x making it easy to identify them. In the next step we will create a subnet for the database tier with the range 10.1.2.x.

Browse to the VNet just created and then click settings and then subnets. Create a subnet called dbsubnet with the address range 10.1.2.0/24.

Creating the WordPress Virtual Machines

Next we will create two WordPress VMs and place them in our appsubnet.

On the left menu click 'New' and type BitNami WordPress into the search bar and press return. This is a free pre-packaged image with WordPress installed and configured. On the screen that follows click the WordPress image and then click create.

Enter a name and access details for the VM. Make sure to select the resource group you created earlier and the data centre region you would like to place the VM in.

Click OK and select an appropriate instance size. Make sure to choose a standard type rather than Basic so that you can take advantage of load balancing. For example, A1.

On the settings page, choose standard storage and select the VNet and appsubnet created earlier. The VM will be assigned an internal IP based on the subnet range defined. It will also be assigned a public IP address which we don't want, so click on public IP address and select none.

Click on the Network Security Group settings and notice the rules that have been setup. For now accept the defaults.

Finally click on the Availability Set settings and enter a new availability set and enter 2 for both fault and update domains. You can of course choose more if required.

Click OK twice and then purchase. You are presented with this screen as you selected a third party VM image, however, there is no cost to this.

Repeat the above procedure for a second WordPress VM accept select the availability set just created.

Now click Browse -> Load Balancers -> Add and create a new load balancer with a public IP address. Here you have the option to name the IP address but you must use a Microsoft owned IP rather than bring your own. Select static if you would like to keep this IP reserved even if this load balancer is deleted. You may want to do this if you want to use an A record to point your domain name to this site. Make note of this IP address as this will be used to access your WordPress site.

Now browse to the load balancer just created and click on Backend Pools and click add.

Enter a name for the WordPress VM pool that this load balancer will manage. Then click add virtual machine and use the availability set method to add both VMs created earlier to the pool.

Once the pool has been created browse to the load balancer and select probes. The probe is used by the load balancer to determine if a VM is healthy and should receive requests. Add a probe called http for port 80.

Now create a load balancer rule for the load balancer, again called http, for port 80 and select the probe just created.

You now should be able to navigate to your WordPress site by entering the public IP address from step 9 above. Navigate to /admin and login with user and bitnami to mange the site.

The above steps show you the basics of creating virtual machines within an availability set and a virtual network. Below I list some of the other steps you would need to take to get the highly available site fully up and running, including building a database backend and pointing your new WordPress site at it.

Next Steps

Deploy a Bitnami MySQL VMs into the DBSubnet in a similar fashion to above. You can deploy two or three and create a replication cluster but this will require knowledge of setting up a MySQL cluster.

You will need to reset the WordPress configuration to point to your new database in step 1 above.

Source: Getting Started with Infrastructure Services on Azure