Welcome to Azure IaaS Day.
My name is Bill DeForeest.
I'm a member of the Azure Compute team here at Microsoft
and I'm really excited to share with you a deep dive
into our new on-demand capacity reservation feature
that's currently in public preview.
In this session,
we're going to look at what this feature does.
We're going to compare it to our traditional VMRI features
and look at the billing and payment implications.
We're going to do a deep dive into how this feature works
at a technical level and then we're going to conclude
with a demonstration of this feature being used
with a virtual machine scale set.
On-demand capacity reservations
is a feature for virtual machines
that allows you to reserve capacity
for quantities of one or more VM sizes
in a specific Azure location.
When this feature becomes generally available,
we will have an SLA
that backs all of the deployed capacity reservations
to make sure that you get your guaranteed capacity
when you do your virtual machine deployments.
This feature will be accessible
through all of the usual Azure methods,
the portal, the command line interface, our PowerShell SDK,
as well as all of the other STKs that Azure supports.
So, let's compare on-demand capacity reservation
to our traditional VMRIs
that have been offered for many years.
Both of these features are for virtual machines.
The on-demand capacity reservation as the name suggests
is created on demand.
You can create and delete whenever you want.
There's no term commitment that's required.
That also means though that there is no built-in discount.
This will be charged at normal VM rates
from the minute that you successfully create
an on-demand capacity reservation.
The VM reserved instances on the other hand
remain one in three-year term commitments.
And as a result of that commitment,
and you do get significant discounts
for your virtual machine usage.
One of the primary differences
is that the new on-demand capacity reservation
will come with an SLA at general availability
that will guarantee the capacity availability
for your subsequent virtual machine deployments.
The virtual machine RIs
will still retain their capacity priority capabilities,
but they are not technically backed by the same SLA.
So, the good news is that these two features
can be used together.
So, as just mentioned, the on-demand capacity reservation
will begin billing as soon as it's deployed
and you will get the SLA for that capacity.
If you make the separate decision
to purchase the virtual machine RI discounts,
those will be applied to on-demand capacity reservations
just like they would be to virtual machines.
So, you will be always charged for the hardware once.
If you have an empty capacity reservation,
then you'll be charged for the reservation
and if you have an applicable VMRI term discount,
that will be applied to the empty reservation.
If you have a reservation that is occupied
by a virtual machine, you'll instead be charged
for the virtual machine,
but again, the reserved instance discount will be applied
if it's available.
You will always be charged for the hardware once
regardless of state of use
and you will always be eligible for your term discounts
if they are available.
We already have extensive documentation published
on our website.
We also have an introductory video
that goes through some of the very basics of this feature
already published.
I invite you to go view that video
if this feature is completely new to you.
So, let's talk about some of the technical details
of this feature.
Capacity reservations always function in groups.
You always start by creating a capacity reservation group
and then you move to creating your individual reservations.
When you define your group,
you pick the location that that group will exist.
So, in this case, US East,
and you'll notice that it didn't specify
in availability zones,
so, that means that this reservation will be
at the regional level.
Once I create my group,
I would then subsequently create individual reservations
like I do here.
I have a quantity of 10 for D4_v3
and a quantity of 5 for E8_v3.
When I go to deployment of virtual machines,
I will reference the capacity reservation group.
Azure will workout based on the VM deployed,
which reservation you are trying to target,
and it will consume that reservation as applicable.
So, in these two examples of VM A and VM B,
I'm deploying a D4_v3 and an E8_v3, in US East,
those match the reservation and so they will succeed.
VM C however, I picked the correct VM size
and the correct VM region,
but I also added the availability zone.
This will fail because this particular reservation
is for the entire region of US East
and is not specific to AZ1.
We'll talk about zone reservations momentarily.
Similarly, if I try to deploy a D16_v3
to this reservation group,
that will fail
because I don't have a reservation for D16_v3.
Reservations are always for specific VM sizes
and you must deploy that matching size
in order to consume your reserved capacity.
If you reserve capacity by zone,
then when you create your group,
you'll specify not only the location, such as US East,
but also the specific availability zones
that you want to target.
In this case, AZ1 & AZ2.
Typically you will then create matching sets of reservations
in the two different availability zones.
So, on the left, you see that I've created
my D series reservation in AZ1
as well as an E series reservation in AZ1.
And on the right I've created matching reservations
for each size in AZ2.
If I subsequently create a virtual machine scale set
that has one of the matching sizes
and uses the same location and the same set of zones,
I can associate my scale set to my reservation group.
And at that point, the scale set
will automatically begin consuming your reserved capacity.
If I instead create a scale set for that size
but it's only in US East
and doesn't specify the availability zones, this will fail.
That would mean you would need to create
a regional reservation like we showed in the last slide
in order to use this use case.
Finally, zonal reservations are also applicable
to individual VMs, they're not just for scale sets.
So in this case,
I want to deploy a single VM to US East
in AZ1 of the matching size
and that will succeed just like the scale set.
Let's talk about some of the intricacies
of managing capacity reservations.
Groups carry the name, the location,
and optionally whatever zones you want to use.
All of these properties are immutable,
meaning they can't be changed after you create them.
If you want to make a change,
you would need to create a new crafty reservation group,
create new sets of reservations
and potentially migrate your virtual machines
to that environment.
Similarly, reservations also carry a name, a location,
and at most one zone.
Those properties are also immutable.
If you want to change any of these properties,
you would create a new reservation,
potentially migrate your virtual machines
to the new reservation, and then delete the old one.
What can be changed is the quantity.
Subject to quota and available capacity in Azure,
you are allowed to increase the quantity at any time.
You can also decrease the quantity
at any time that you don't need
the reserved capacity anymore
and there are even some cases where it might make sense
to reduce the quantity to zero.
And you can read the documentation
for examples of where that might make sense.
Finally, let's talk about the most nuanced topic
of capacity reservations
and that is their allocation state.
When you create a capacity reservation
in this case of size three, for any particular VM size,
it will be empty.
You'll have a spot for three virtual machines.
In this first example,
I've deployed one of my three virtual machines
meaning that I remain under allocated.
I still have two more VM slots that I can deploy to
that will receive an SLA.
Once I've deployed all three virtual machines,
I move to a fully allocated state,
meaning that I have consumed all of the slots
that carry an SLA.
However, it's also allowed for me
to go into an over-allocated state.
In this example, I've now deployed a fourth virtual machine,
even though I only have three spots reserved.
This is completely normal and supported by Azure.
Imagine a case where you have an auto-scale role
that triggers in the middle of the night
while everyone's asleep.
We don't want Azure to block that deployment
because you happen to hit
the maximum of your capacity reservation.
As long as we have capacity and you have quota,
you will be allowed to deploy the fourth virtual machine.
Any of the four that you delete,
say, I delete the original VM zero
that I deployed way back on the left,
Azure will automatically reconfigure
the capacity reservation and you will revert automatically
to the fully allocated state in the middle.
In this way, Azure gives you the flexibility
to treat the reservation as a minimum
and is never a maximum.
With that, let's look at a demonstration
of how to use this feature with virtual machine scale sets.
So as we just discussed, when using reservations,
you always start with the capacity reservation group
and that allows you to create reservations
within that group.
To create a reservation group,
you go to that tab in the portal.
Since this is a deployed object,
you always pick the resource group that it goes in,
you give it a name.
You need to pick the location,
which in this case is US West two
And then you optionally pick the availability zones.
And remember, all of these properties cannot be changed
once the group is created.
Because I picked three availability zones,
I will be given the opportunity to create reservations
in each of those availability zones.
So in this example, I'm going to reserve a single VM
in each of the three zones
and they're all going to be of the D2s_v3 size.
And then if I go to review and create,
you can see now that I will reserve three slots
and you can see that they're going to be distributed
across each of these three availability zones.
And you can see the summary here at the bottom.
I've already created one of these.
And so if we look at the Emp at a reservation
that is in the empty state when it's been first created,
and I look at the tab, you can see here
that I have a reservation in each of my three zones.
None of the allocations are used,
and I don't even have any virtual machines associated,
meaning that they're targeted to use this reservation
if they were subsequently deployed.
And you can see that over allocated state is no
because I still have SLA slots available.
So let's look at a scale set and how I would associate
the scale set with this capacity reservation.
So if we create a new scale set,
again, I need to pick the resource group.
Live, interesting.
And here again, you remember
that I picked availability zones
when I created my capacity reservation group
and so I need to pick the same set of availability zones
on my scale set so that this will all match at runtime.
If I scroll down here, I have the matching size
of the reservation that I already created.
The next thing I want to do for demonstration purposes
is change the quantity, the initial quantity
to be four rather than two.
You would obviously set this to whatever scale you wanted
as your initial set.
If I go to the advanced tab and I scroll towards the bottom,
there's now a capacity reservation option.
And if I click on this, Azure will notice
that there is a matching capacity reservation
that's already been created.
This will allow me to choose this.
And that means that my VM scale set
will now use my reserve capacity at deployment time.
If I click on review and create,
you would see all of the expected parameters.
I have my name.
I have the fact that it's targeted
across three availability zones.
And if you scroll to the bottom,
it shows that you're using a capacity reservation group.
So again, I've already created one of these.
So let's go look at that object.
So here I have my resource group.
I have my subscription just like you would normally expect.
If you scroll down here,
you see that it's using three availability zones.
My virtual machine profile,
which is the basic definition of the virtual machine
that I'm using in my scale set,
you'll notice that it references
that capacity reservation group
that I specified during creation of my scale set.
Since this is already fully deployed,
if we scroll back up here,
you have status of four or four VMs have been allocated.
So now I can go look at
what my reservation group looks like.
If I do that, you'll see that I have
these VM sizes deployed in each of these availability zones.
And here you'll see the allocated state.
So in AZ2 and AZ3, I'm in the fully allocated state
because I've used my one reserved spot.
But here's an example because I set
the initial scale to be four, Azure has gone back to AZ1
and deployed a fourth virtual machine,
which puts the reservation in AZ1
in the over-allocated state.
Meaning you have two VMs deployed
even though you only have one reserved.
And again, this is totally normal and expected.
This will mean that if you hit an auto allocation rule
or an auto-scale rule at any time overnight
or in the middle of the day when you're at lunch,
it doesn't matter.
Azure is not going to block you
from scaling out your scale set.
On the reservation, if I look at the resources,
you can see all of the individual VMs
that have been deployed.
And in this case, you can tell
from the way that this is set up
that it's the name of the scale set
and it's a slash zero and a slash three,
that these are virtual machines that are associated
with the front end scale set that I created earlier.
And this way you can come and see at any time
which set of virtual machines
are using your capacity reservation.
If you need to, you can go de-allocate
those virtual machines
or you can extend your capacity reservation quantity
to match if you decide that all these virtual machines
warrant reserved capacity.
So I hope that demonstration showed
the power of this new capability,
both to support your scale sets,
as well as your individual virtual machines.
Thank you for joining Azure IaaS Day.
We hope you found it both informative and enjoyable.