Azure Managed Disks GA & Backup In Preview

Azure Managed Disks became GA a few weeks ago and offer much simpler disk management for Azure IaaS VMs by managing the storage accounts associated with the VM disks. You only have to specify the type (Premium or Standard) and the size of disk you need, and Azure creates and manages the disk for you.

As of today Microsoft have also announced preview support for Azure Backup with Azure Managed Disk VMs – so not quite there for those of us using Azure Backup with production VMs but certainly time to get playing (unless you don’t need to use Azure Backup – in which case get going into prod!).

It is also great to see that Microsoft haven’t left the “how do we migrate” conundrum as they often have done in the past. They are providing a wealth of documentation on how to convert disks from a number of scenarios even including an Azure Classic VM conversion into ARM with Managed Disks – https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

Benefits

Simple and scalable VM deployment

Managed Disks handles storage for you behind the scenes. Previously, you had to create storage accounts to hold the disks (VHD files) for your Azure VMs. When scaling up, you had to make sure you created additional storage accounts so you didn’t exceed the IOPS limit for storage with any of your disks. With Managed Disks handling storage, you are no longer limited by the storage account limits (such as 20,000 IOPS / account). You also no longer have to copy your custom images (VHD files) to multiple storage accounts. You can manage them in a central location – one storage account per Azure region – and use them to create hundreds of VMs in a subscription.

Managed Disks will allow you to create up to 10,000 VM disks in a subscription, which will enable you to create thousands of VMs in a single subscription. This feature also further increases the scalability of Virtual Machine Scale Sets (VMSS) by allowing you to create up to a thousand VMs in a VMSS using a Marketplace image.

Better reliability for Availability Sets

Managed Disks provides better reliability for Availability Sets by ensuring that the disks of VMs in an Availability Set are sufficiently isolated from each other to avoid single points of failure. It does this by automatically placing the disks in different storage scale units (stamps). If a stamp fails due to hardware or software failure, only the VM instances with disks on those stamps fail. For example, let’s say you have an application running on five VMs, and the VMs are in an Availability Set. The disks for those VMs won’t all be stored in the same stamp, so if one stamp goes down, the other instances of the application continue to run.

Better security

You can use Azure Role-Based Access Control (RBAC) to assign specific permissions for a managed disk to one or more users. Managed Disks exposes a variety of operations, including read, write (create/update), delete, export, and retrieving a shared access signature (SAS) URI for the disk. You can grant access to only the operations a person needs to perform his job. For example, if you don’t want a person to copy a managed disk to a storage account, you can choose not to grant access to the export action for that managed disk. Similarly, if you don’t want a person to use an SAS URI to copy a managed disk, you can choose not to grant that permission to the managed disk.

Azure Web Apps – Troubleshooting external http/https calls using Kudu

I recently saw some strange issues with a customer’s Azure Web App where as part of the application they relied on an API call to an external source which was failing. This presented almost as a network routing issue to external resources with “connection timeout” errors.

Working with the Azure support team, we confirmed there was an issue (I’m still waiting the full details from Microsoft as to what..) on the underlying VM/machine.

In one case we resolved by scaling up and then scaling back down the Web App instance which made Azure migrate the Web App to a different underlying machine and in another case we had to escalate to a product team in Microsoft for them to manually migrate the Web App to a different machine as we kept being placed back onto the problematic machine.

At first we were unsure if this was an application/site issue, Azure issue or firewall issue at the 3rd parties side.

By using the Kudu tools in Azure Web Apps we can perform some basic diagnostics and testing to ensure that external http/https calls are possible from the underlying machine our PaaS site is running on.

For example, if we have an Azure hosted site, which requires to make lookup calls to an external API hosted by another provider this can be a useful testing/verification step in event of issues.

You can access the Kudu tools from the Azure portal:-

a

b

Or by navigating to https://abc.scm.azurewebsites.net where abc is the name of your Web App.

c

Choose Debug Console > CMD

d

To test a URL enter curl https://yourexternalurlhere.com and press enter

A successful http:// connection will display the raw HTML like this example –

e

You may sometimes see an SSL error when testing some https:// sites successfully this is often perfectly normal as CURL can’t read the cert fully.

f

If you have a DNS issue expect to see this error –

g

For an external URL you are having connectivity issues with, expect to see timeout errors like this –

h

Disqus, WordPress and Azure Web Apps – “Unable to connect to the Disqus API servers”

Having used Disqus on other sites, I wanted to add it on my blog as the comments system.

I am using WordPress/Project Nami on Azure Web Apps and had some issues getting Disqus setup.

Upon activating the WordPress plugin and following the Disqus documentation, the configuration wizard would fail with the error “Unable to connect to the Disqus API servers”.

Inside the function wp-content\plugins\disqus-comment-system\lib\api\disqus\url.php on line 55 there is a CURL call to fetch information from Disqus, which was failing on certificate/https validation.

I was able to workaround the issue by undertaking these steps –

  1. Download the cacert.pem file manually from https://curl.haxx.se/docs/caextract.html and place it in the lib\api\disqus\ folder

    (Tip – you can use Kudu with Azure Apps to easily upload the file – http://www.jamessturtevant.com/posts/How-to-add-edit-and-remove-files-in-your-azure-webapp-using-the-kudu-service-dashboard/)

  2. Around Line 55 in the api\disqus\url.php file add the following to the $c_options array
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_CAINFO => __DIR__ .’/cacert.pem’

    (You can edit using Kudu, but I edited this file using the new App Service Editor feature from the Azure portal as I wanted to try it out. The App Service Editor is a web based IDE based on the Monaco code editor which ships with Visual Studio Code)appservice

    Don’t forget the comma at the end of the existing CURLOPT_TIMEOUT => SOCKET_TIMEOUT – I’m not a dev guy so this caught me out initially!

curldisqus

Hopefully if you are suffering the “Unable to connect to the Disqus API servers” error this will help. I’m not sure if this is specific to Azure Web Apps or other web hosts too.