>> Hey everyone,
I'm Sofia Joison,
and I work in the Azure Core Fundamentals Team.
Today, we're going to be talking about how to optimize for quick,
and reliable virtual machine deployments.
We know that when someone wants a Virtual machine from Azure,
they want it fast.
Whether you're pushing a button on portal or sending an API call,
the desired outcome is the same.
I'm going to show you
how virtual machine provisioning happens and then take you
behind the scenes on
some internal platform capabilities
that can speed up your experience.
Creating a Virtual Machine pretty much
never means just a Virtual Machine by its lonesome.
As we saw in Alex's presentation on arm templates,
creating a Virtual Machine includes
the creation or use of many additional resources,
some required, and some only
needing depending on your workload, and goals.
You have the Network Interface or the NIC,
this is the interconnection between the virtual machine,
and the virtual network.
Then you have the network security group along with the Subnet,
and that Subnet is part of a V net.
If you want more data,
you can have associated data disks.
If you need to get information about your VM during provisioning,
you can have your diagnostics, logs,
and screenshots stored in a storage account.
Lastly, of course, you have an IP in order to interact with a VM.
On top of the additional resources,
there are choices that you're going to have to
make for the virtual machine itself.
The size and the type of the virtual machine,
the operating system,
the image, the distribution,
and the version, and then the availability options.
There are so many selections to
choose from in order to fit your workload needs.
I'm going to share how you can
optimize for performance and reliability.
When you think about
conventional resource provisioning, everything happens on-demand.
As a customer, you might log into the Azure portal to create
a virtual machine that you want when that request comes in.
The virtual machine,
and all the associated resources which we saw on
the previous slide are created at run time.
We build the machine up,
and then we run it through provisioning,
which you can akin to as if you were installing
Windows on your laptop for the very first time.
This process is all about building
the resources together at the time of the request.
The virtual machine itself,
the NICs, the storage accounts.
Over time, we've made
optimizations to create these resources faster.
That is the journey that we're going to dive into
so that you can learn how to leverage them.
The first optimization I want to talk about is pre-fetch.
When Azure was beginning,
we made the decision to put the OS disk on remote storage.
That way, if there were any issues on the host node,
we could spin up a VM on a new node,
and the user wouldn't be impacted by any loss of data.
This additional reliability was a trade-off with performance.
Of all the steps that occur in
conventional resource provisioning,
there's one specific step that takes the longest,
and that is what we're going to optimize here.
The goal of pre-fetch is to reduce
the latency that is incurred between
the node and storage by bringing down
the OS contents to the host node before they're needed.
Because we can't bring everything.
We tried to determine what is needed as accurately as possible.
When a new image gets published to
the image repositories in Azure,
pre-fetched service is invoked in the background.
Now, what pre-fetched service will actually do is bring
up a sample virtual machine with that image,
and look at the OS disk activity that's
occurring during the boot, and provisioning phases.
This metadata is captured and then put back on the OS disk,
which we call pre-fetched metadata stamping.
One of VM is booting on the host node.
It will check for that pre-fetch metadata and read it.
Tip number one here,
if you're building your own image,
ensured that the first megabyte of the OS disk is
empty so that we can stamp the pre-fetch metadata.
This will ensure that your images prefetchable
and will yield significant latency games.
If you're building your image from an approved base,
you don't need to worry about this part.
Another optimization is managed boot diagnostics.
Boot diagnostics is a feature for virtual machines
that allow for the diagnosis of VM boot failures.
This feature enables you to
observe the state of the virtual machine
as it's booting by collecting log information and screenshots.
In order to have that,
you need to have a storage option for this data to be retained in.
Previously, you only have the choice to either leverage
a user-managed storage account or disable the feature.
For the user-managed storage account,
if you didn't have one already,
you would need to create one,
meaning another resource being
created at run time along with the virtual machine.
With the new managed account option,
you can get the diagnostics without needing to
manage or even create a storage account.
These storage accounts are pre-created ahead of time,
resulting in minimal latency and Azure is owning the accounts,
making the management easier on you.
Tip number two here is to leverage managed
storage accounts for virtual machines if you can.
This will reduce your VM provisioning latency
and management overhead.
The next platform capability I want to share with you-all is
something called pre-provisioned virtual machines.
This platform capability seeks to remove
as much of the resource creation at run time as possible.
There are three high-level steps
to pre-provisioned virtual machines.
The first is prediction,
where we analyze the virtual machine deployments across Azure and
predict what will be needed in the future using AI capabilities.
That prediction is then leveraged to prepare
virtual machines in advance of a request coming in.
These VMs are kept in what we call a partially provision state.
The last step I like to call activation,
where final configuration specific
to a customer requests are applied,
and the virtual machines are handed
off in a fully provisioned state.
What does this mean for you-all as a customer?
First thing is significantly lower latency
experienced in virtual machine deployment,
the need to fully provision
a virtual machine at the time of requests coming in is removed.
This obviously has a benefit to the latency that's experienced.
The other is reliability.
As VMs in this pathway are already up and running.
Let's dive into each phase in a bit more detail.
Millions of virtual machines are deployed every day in Azure.
Our algorithm looks at
a history of all the virtual machine deployments
and predicts what virtual machines
will be needed in the future for customers.
As we went over in the beginning,
there are a lot of
different specifications for customers
to select for virtual machines.
All these properties can really be
bubbled up into two categories,
from a pre-provisioned virtual machine perspective,
things that are immutable and things that are not.
What makes something immutable?
The answer is, if it needs a rebuilt.
I can't make a Linux machine into a Windows machine.
I'm going to have to predict for the operating system.
I also can take a DBN image
and make it the latest Databricks image.
I'll need to predict for the image.
On the other hand, I can't change
the username or the machine name.
This is the principle that guides us for what we need
to predict for versus what we can handle on the fly.
Believe it or not,
the number of possible virtual machine configurations
comes close to 70,000.
I want to make a quick note on our algorithm.
Our very talented data scientists created
a new framework in order to best approach this problem.
The prediction component predicts for
future demands and model's prediction uncertainty.
The optimization component conducts
probabilistic optimization factoring in
the most beneficial customer experience.
It then goes through a period of training and maximizes
the solution quality and finalizes the pre-provisioning plan.
Of course, this is a very simplified description.
If you're interested in learning more,
we have some scholarly articles linked
on the last content slide from the team.
The last step of the prediction phase is to hand off
the top NVM configurations and the suggested count of each.
This next step here is the actual pre-provisioning.
Once the prediction is received,
it will go through another level of
platform filtering in order to scope to
the maximum number of predictions
balanced with capacity needs and so on.
From a platform perspective,
it actually seems like we're creating a VM just as usual.
The only difference here is that it's
tagged to denote a special functionality.
Inside the guest is where it understands that this
is a pre-provision virtual machine and not a regular one.
It'll go into a mode where it's waiting for
those customer specific settings to be supplied.
Which basically means we have an agent
running inside the gas that's doing all the magic.
From a security perspective,
I want to call out that these VMs have no public IP,
and no Internet connectivity.
This means that no one can connect to them
and they're secured in this dormant state.
The last step is activation.
When a request comes into Azure with
the virtual machine configuration
matching one that has been pre-created,
we can give that virtual machine to the customer.
The agents are taken out of the waiting mode
by getting supplied the information that they're
looking for and the process for finishing up
provisioning and handing off
the virtual machine to a customer can begin.
A transfer of resources occurs and we relinquished
any control over the virtual machine
and its owned fully by the customer.
There's of course some really cool technical,
innovative details that happens here.
I have to keep some ingredients to the secret source secret.
The big question that's probably
left on your mind at the end of this is,
this is really great stuff.
How do I leverage it?
Because pre-provision machines is
an internal platform capability,
customers don't directly interact with it.
As I said, there are 70,000 possible configurations.
How do you optimize for being predicted?
Let's shift over to some tips for that.
In general, the term latest is greatest is a good rule of thumb to
follow for maximizing your deployments
with pre-provision virtual machine capabilities.
This is true whether you're thinking about images,
feature offering, VM sizes, etc.
Now let's take a quick focus on images.
Using the most recent images from Linux or Windows,
we'll ensure that you have support at the image level.
When specifying the version of the image going with the latest,
will provide an additional boost to predictability.
This last point, which is super key,
leveraging Azure Platform Image Repository or
Shared Image Gallery for
your images to ensure accessibility to them.
The next thing I want to talk about is
virtual machines sizes and types.
Whether you're optimizing for CPU, storage or memory,
every virtual machine family has
either premium or standard options.
These terminologies more or less map to
the existence of an S in the name.
A simple example would be the general purpose T family VMs.
There's the DB4 series,
which is considered standard,
and the DSP-4 series which is considered premium.
For better performance opt for
the premium virtual machines skills.
Another note I want to make on virtual machines is
making sure that you have the right size.
The storage throughput,
or maximum IOPS,
will depend on the virtual machine size and the size of the disk.
Put it this way, if we were in
a shoe store and you were in-between sizes,
my recommendation would be to size up.
This would reduce the potential for IOPS
throttling during virtual machine provisioning.
Of course, this is a balance with cost as well.
The same philosophy can be
applied for premium versus standard storage.
My recommendation is to opt for premium storage if you can,
for better performance and reliability.
The last thing I want to talk about are
the several availability offerings for virtual machines,
opting for the newest ones if you can,
other availability zones or the super recently public previewed
virtual machines scale sets with
flexible orchestration will improve
the provisioning experience and prediction.
For the newly announced virtual machines scale sets
with flexible orchestration,
I can't even begin to list out the benefits to customers.
Fast scalability, ease of use,
high availability, customizable, and so much more.
The combination of this and
pre-provision virtual machines is well, fast and furious.
Thank you so much for having me here today.
Here are some resources that I've linked that relate to the talk.
Now let's go back to live for some Q&A.