Hey friends, whether you're running SAP, a banking solution
or gaming service. A simple blip or pause in your VMS host
can cause unintended consequences for your VMS now
Azure offers maintenance control for up to 35 days on
platform updates that don't require a reboot to give you
control for when these updates happen. Shantanu is here to
show me how it works today on Azure Friday.
Hey, I'm Scott Hanselman. It's Azure Friday. I'm here is
Shantanu. I have a confession that I have a couple of not
cloud native things they're just running in virtual machines out
there in the world I think that maybe there's more people that
run their things in a single virtual machine, then we realize
that is correct lot of financial companies as well as gaming and
CP workloads. They're running on Azure. Virtual machines, Azure
virtual machines. You might have one. You might have 100 whether
you decide to go and have your systems spread all their traffic
across all of these.
A blip 8 seconds 10 seconds a minute. It can really change the
way the application works and fields and sometimes it's not
acceptable. Yes, so I would say the majority of the workloads VM
workloads. They are designed in such a way that they are not
really impacted by these types of updates, but there are
definitely some ultra sensitive workloads where even a blip or
pause of like few seconds can cause outage on the customer and
so this experience, I'm talking
about. Is designed towards those ultra sensitive workloads so?
How do I know if I have that workload I suspect my blog is
not that workload it may not be? I mean, it has to be really
tested. I would say on what's the tolerance level for each of
these workloads? What we have seen is some of the lift and
shift workloads. Some of the SAP workloads as well as the gaming
workloads where you are depending on the availability of
a single virtual machine. Do get impacted right. So you don't
want the game to pause and 8 seconds is an eternity if you're
playing a game. If you're transferring money or doing
something important. You can't have that positive. But even if
it's only a few seconds or a few minutes when these pauses
happened? What is happening? Why is it? Paused I'm taking an
update and some things paused so most of the Azure updates, the
platform updates mean they are 0 impact to the hosted virtual
machine. However, we have very few of those updates, which do
cause pause or blip or disconnect of up to a few
seconds. So what happens is when the host machine is updated the
VM is either preserved in the memory or it feels like a
disconnect for few seconds OK, so let me think about this. This
is my laptop. I've got hyper V on and pretend that this is
Azure. I'm running 5 or 6 virtual machines. If I actually
reboot. The host that's going to be huge downtime. That's good if
I take a little bit of an update that may be updates. Hyper V
itself. I could have a moment with the network clips or I
could pause the VM.
Take the update and resume the VM is that we're talking about
yes, so most of the added updates. They don't require any
reboot of the host machine, so our update mechanism has evolved
over the years, so most of our updates are these reboot? What
we call reboot less updates, interesting and these updates.
You said that they're not very often, so right now. We are
seeing a frequency of about once a month at least for these
reboots upgrade but the one which will cause a reboot.
They are rare right now actually we have hardware decommission as
1 where we have to reboot. But there's no like fleetwide
reboot. Full types of updates and I've heard you. Called them
re. Bootless updates, but it's updates that do not require a
reboot for the virtual machine and then I just want to know
really. When it happens, because I can find 8 seconds. I can find
a few minutes here and there, I just need to know when so I want
control. This really is about putting control in the hands of
the customer so. Basically, as a customer you decide when you
want to update your virtual machine in your maintenance
window within the window that we are providing which is 35 days
and that 35 day window is an update needs to happen. And
we're going to start o'clock and then you have this whole time to
find a moment in just a moment to take the update you control
it. And if it expires then we force. The updated 35 day that
is correct if it expires before the update but we still respect
the availability constraints, meaning we do it for domain
bifold domain. Another interesting thing is caught is
that whenever you try to whenever you initiate the update
all the pending updates till that moment in time get updated.
It's not like only the update which is started. The 35 day
Clock gets applied. It's everything that is spending at
that very moment. So we apply? What is called the last known
good build which has all the updates included that point of
time OK so then if you're saying is the window starts. Another 2
updates back up against each other, we can do them at the
same time. There's going to all of the same time, Oh that's nice
so that's why internally we have been calling it batched updates
because we're patching up all the updates and applying it as a
bug. That's question mark that would work great for people So
what does that experience like actually hear you got before we
do that? You've got a slide here that talks about that category.
Yes, so for the average general
virtual machine. Yeah, they don't need to use this feature
if they're only impacted by reboot. We're already giving
control on the rare occurrence that we do have to reboot. The
virtual machine. This is only intended for really the
ultrasensitive VMS where you can't tolerate even a blip OK,
Yeah Alright. So this is how the experience works as we were
talking. We are giving control for up to 35 days and the bulk
update gets applied whenever the user initiates the update and
then there is a force update now, what we have available for
this experience. Our APIs and Command Line PowerShell and CLI.
We don't yet have the portal. It's coming. Soon the way this
experience works is like 4 steps user has to create a maintenance
configuration. Then they have to assign that maintenance
configuration to the resource then check for pending updates
and apply the pending update on resource. Sorry one important
point I missed this that this experience is only available for
isolated virtual machines as well as Azure dedicated host in
which case the customer owns the host machine. Basically, they
are the only customer on that particular host app Service plan
is not a good example because that's a virtual machine by
which other people would be on it with me.
Yes, so if you are on a shared host with bunch of other people.
You can't control when it gets updated the idea is if you are
an isolated VM like E64I, something like that where you
are like the single VM on the host machine, or if you are a
customer of our new offering which is Azure dedicated host
where you are the owner of the host machine and you decide
which VMS will go on it, then you can decide when to update it
right, which gets to your original point. If you are
sensitive to these kinds of clips. Then you would have that
offering yes. You need to have that offering for getting this
kind of control. OK, yeah, that makes sense so you set that
maintenance config, which is a declaration of your expectations
of what you want and what does that look like if I were to code
that up so let me actually like jump right into the demo?
I'm setting some parameters here, so we got our location.
We've got our resource group name in our host yes, so this
host I will quickly jump to the portal as well. So I have a
dedicated host the name of the dedicated host is my host and it
is inside a host group called my host group and then it's in East
US 2. So what I'm doing here in my demo is I'm setting this
input parameters and the first step is really creating or
maintenance configuration. So I will run this command.
And here what it is doing is creating the maintenance
configuration is telling that the maintenance is scope is of
the type host and once this maintenance configuration is
created an Azure deployment system gets the signal that
there is a maintenance configuration to escape the
regular updates. An once the maintenance configuration is
created the next step. For me is to assign a resource to this
maintenance configuration, so in this case. I had Azure dedicated
host what I'm doing in this step
is. Assigning that Azure dedicated host name my host to
the maintenance configuration that I had created earlier.
Now, when I do this, the Azure deployment system whenever we
are deploying as soon as we find a host machine, which has VM
which is subscribed to this policy or the maintenance
config. We're going to skip that host machine and continue the
regular deployment and finish it in our region or cluster and
then as a customer you decide when it gets updated so here
because I already had this dedicated host as part of this
maintenance configuration. Some pending updates on it,
usually it will take a while before any pending updates
shows up because as I was saying earlier. Most of our
updates are zero impact so in this step. What I'm doing is
checking if there are any pending updates on my Azure
dedicated host so let's see so here are some interesting
things.
So as you can see, there are there is a pending update with
the impact duration in 2nd as 9 seconds and the impact type is
freeze so the experience that the virtual machine will get is
it will be a freeze of 9 seconds. When this update is
done and another interesting thing is that there is a not
before date so in the not before date. We're telling what's the
Max time allowed for people to self update OK so not before.
That's that window that's that's 25 days that is correct. I love
that you're telling them in
seconds. You can prep yourself for 9 roughly 9 seconds, plus or
minus. I'm sure yes impact type is freeze. What are some other
impact types that I might say so we have the impact type as
redeploy and reboot as well so if the update is of type reboot
or if it's type redeployed then it will show up here as well.
And after checking the pending updates what I'm doing in this
step is applying all the pending
updates. On my Azure dedicated
host. So as you can see I initiated this command what it
will do is it will initiate the update and you can see the
status as in progress. It will take a usually I mean, it
depends on the type of update that is spending on the host
machine, depending on the type. It can take anywhere between 10
minutes to up to even 30 minutes in the rare scenarios, and
people can check the status of the apply update by just
initiating the commands again so easy minutes apply. Update has
started that the update is happening. It's probably already
happened and the freeze happened or does it gets.
Scheduled for sometime, it is started it, but within that
duration of 10 minutes to 15 minutes whenever the update
finishes. There will be a freeze of that nine second during that
duration. Yes, how much how much how careful we how much warning
do we have to have their like it's not right now for 9
seconds. It sometime in the next few minutes? Yes, 4, nine
seconds, yeah, So what we're saying is that once you initiate
the update the update it starts
happening, but The actual nine second impact to your VM can be
within that we see in the window of the updates. I say so. The
update might take some number of minutes. The VM is doing its
thing just fine. The only time in the freezer window within a
window. That's correct. That's very exciting, so this is in a
nutshell. That's about it. So the great thing here is that as
I was saying. We are creating the maintenance configuration
and we are assigning resources to it. So you can have just one
maintenance configuration, you can assign all your resources to
it. And then the interesting
thing is. That this can all be automated in the maintenance
window, So what we have observed is that people have usually
monthly maintenance window where they do their app updates or
weekly window. Whatever the cadences so as part of that they
can just issue. The apply update command so all the other things
are like a one time operation where you're creating a
maintenance configuration. You are assigning the resource to
the maintenance configuration. But as part of their maintenance
window. They can just call the apply update command if there is
no update pending it will be a no op but if there is an update
pending it will just apply
there. So yeah, so customers that usually have that
maintenance window can just call apply update cleanly and if they
were expecting a maintenance window anyway. They can handle
this so this is very exciting because they can use this to be
informed and use this to plan. But even better. They can just
put it in their existing management and they can forget
about them. All the other platform updates that are going
on. Because we are not ruling out any update on their host
machines and as part of their regular maintenance window.
They're just calling the apply update command. They don't have
to worry if there is something
pending not pending. It just gets applied if there's
something quite fantastic, so this feature is supported on
Azure dedicated hosts on isolated virtual machines and
they check out the blog and the documents and we're going to put
into the show notes and you can learn all about. This yes and
one important thing that this maintenance configuration is
also supported across subscriptions and resource
group, so you can have very well create your maintenance
configuration in one subscription and then you can
use it across your other subscription at everything is
very flexible. Fantastic I am learning all about how to
control reboot less platform updates for Azure VMS today.
On Azure Friday.