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: http://kristiannese.blogspot.no/2013/10/windows-azure-gallery-items-getting.html
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: http://blogs.technet.com/b/privatecloud/archive/2014/07/17/the-windows-azure-pack-vm-role-introduction.aspx
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: http://blogs.technet.com/b/scvmm/archive/2014/04/22/update-now-available-for-the-virtual-machine-role-authoring-tool.aspx
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:
Post a Comment