Monday, July 28, 2014

Workaround for VM Roles and Storage Classifications

Solving classification for your VM Roles with VMM

Since you are reading this blog post, and hopefully this blog now and then, you are most likely familiar with the concept of Gallery Items in Windows Azure Pack.

Useful Resources

If not, I suggest that you read the following resources:

If you want all the details around everything, please download our “Hybrid Cloud with NVGRE (Cloud OS)” whitepaper that put everything into context.

My good friend and fellow MVP – Marc van Eijk, will publish a couple of blog posts at “Bulding Clouds blog”, where he dive into the nasty details around VM Roles. Here’s the link to his first contribution:

Gallery Items and VM Roles

Before we proceed. Gallery Items brings “VM Roles” into Azure Pack, which reminds you a lot of service templates in VMM in the way that they are able to climb up the stack and embrace applications and services during the deployment. However, a VM Role is not completely similar to a service template in VMM as it has no knowledge of any of the profiles (Hardware Profile, Application Profile, SQL Profile and Guest OS Profile).

This is where it gets tricky.

Gallery Items are designed for Azure and brings consistency to the Cloud OS vision, by letting you create VM Roles through the VMRoleAuthoringTool from Codeplex for both Azure Pack (Private Cloud) and Microsoft Azure (Public Cloud).

The components of a VM Role are:

·         Resource Definition file (required – and imported in Azure Pack)
·         View Definition file (required – presents the GUI/wizard to the tenants)
·         Resource Extension (optional – but required when you want to deploy applications, server roles/features and more to your VM Role

The tool let you create, alter and update all these components and you can read more about the news on this blog post:

So far, in 2014, I have been visiting many customers who are trying to adopt Azure Pack and Gallery Items with VM Roles. They want to provide their tenants with brilliant solutions, that are easy to understand and deploy, and can be serviced easily by the cloud administrators.
However, there are some important things to note prior to embracing the VM Roles in Azure Pack, especially when it comes to storage.

·         VM Roles are only using Differential disks
·         You can’t benefit from storage classifications associated with your VMM Clouds – and determine where the VHDX’s will be stored

Why are we using Differential disks for VM Roles?

This is a frequently asked question. In the VMM world, we are familiar with the BITS operation during VM deployment. Luckily, fast file copy was introduced with VMM 2012 R2 and we can also leverage ODX for deployment now, so hopefully BITS is nothing that you see very often when deploying VMs anymore.
However, in order to speed things up a bit more, we are using Diff disks for VM Roles. This is because we intend to reduce deployment time and improve performance. Shared bits from the parent VHDX would be served up from cache in most scenarios and new VMs simply create a new diff disk and boot up. This goes for both OS disk and data disks for the VM Role. No file copy need to occur (except for the first VM to require the disk). When you then decide to scale a VM Role in Azure Pack (scale out), the new instance can boot almost immediately and start walking through the setup.

Ok, I understand the decision around Differential disks now, but what about storage classification and where to put these disks?

Since VM Roles in Azure Pack are only linked to the disks in the VMM library (by using tags), we can’t map it towards any of the storage classifications.
Out of the box, there is no way to modify this prior to the deployment.

Tip 1 – Default parent disks path on the hosts

In VMM, navigate to Fabric and click on properties on your hosts in the host groups associated with the cloud used by Hosting Plans in Azure Pack.

Here you can specify the default parent disk paths to be used for the virtual machines (VM Roles).
If you have dedicated shares or CSVs, this might be helpful and can streamline where the VM roles are living.

Tip 2 – Live Storage Migration post deployment

At a customer site earlier this year, we ended up by using Powershell to move the disks around after deployment.

This is something we added to SMA afterwards that was automatically triggered post the create operation of every new VM Role.

Here’s the script:

### Get every VM Role in a specific VMM Cloud used by Azure Pack

$vms = Get-SCVirtualMachine | Where-Object {$_.AvailabilitySetNames -cnotcontains $null -and $_.Cloud -like "Service Provider Cloud"}

### Move the storage to the preferred/dedicated directory
       foreach ($vm in $vms)

Move-SCVirtualMachine -VM $vm -Path "C:\ClusterStorage\CSV01\" -UseLAN -RunAsynchronously

As you can see, we are querying virtual machines that has an availability set associated. Each and every time you deploy a VM Role with Azure Pack, the underlying cloud resource in VMM gets an availability set to ensure that when you scale out the VM Role, the workloads are spread on different Hyper-V nodes in a Cluster (assuming you are using a Hyper-V Cluster for your workloads).

That’s it, and hopefully this gave you some ideas and more information around VM Roles in Azure Pack.

No comments: