>> Hey friends. I'm Scott Hanselman and it's
another episode of Azure Friday and I'm always
thrilled to talk to Ziv Rafalovich
because he's always here to save me money.
And today we're going to talk about
low priority scale sets
and virtual machines. How are you?
>> Thank you. I'm happy to be here again Scott.
>> Yeah.
>> So, yeah. Today, low priority scale sets.
And the big news is between 60 to 80 percent discount.
>> Eighty percent?
>> Eighty percent. Well, 60 for windows and nearly 80 or
actually a bit more than 80 on
different VM sizes for Linux.
>> That's amazing.
>> Yeah.
>> So, if I'm serious about saving money,
I can find a compromise between
getting my work done and saving serious bucks.
>> Yes, exactly. Go to
the pricing calculator in Azure and see the actual price.
>> Okay. So, how does this work?
This is the difference between paying for
guaranteed SLAs and guaranteed
virtual machines versus using that Slack capacity.
>> Exactly. We have unutilized
capacity in Azure, buffers,
capacity we just on-boarded but no one actually used yet,
and we want to resell it.
So, we will give it to customers,
we will sell it at this discount.
In all regions today still in public cloud,
all VM sizes with one exception which is the B size,
but imagine the biggest VMs,
you can try for 80% discount.
>> All right. Okay.
>> Yeah.
>> So, what's the catch?
>> There's always a but.
So, availability is not guaranteed.
>> Makes sense.
>> Capacity's not guaranteed.
>> Also makes sense.
>> We will not service heal you.
So, if something goes wrong,
your VM will be fairly already deallocated.
We will give you one full domain,
so don't plan for any high volubility typologies.
And instances will be
evicted when a paying customer asks for the capacity.
>> That makes sense.
>> Now, when we
need to kick you out, we call it the eviction.
It's a nicer word. And there are
two policies you can pick.
The first which is the default is to deallocate,
we just stop the VM,
you get your disk it's still there.
You're still paying for the disk right away.
So, if you use the disk it's a long boot time,
you saved local state on the disk,
you may be able to try and redeploy that VM.
The second policy is delete.
We'll just delete the VM,
delete the underlying disks
and you won't pay for the disk.
And the actual benefit for deletion is,
it works well with other scales.
So, you can actually put VM scale set and
then VM skeptic auto scaling.
So, we will evict your VM on one end,
but auto scaling will compensate for it on the other end.
>> And compensate by trying
to find somewhere else for you to live.
>> Yes.
>> So, somehow I'm imagining myself in a hotel where I'm
sleeping in rooms that no one's paying for right now,
so I get the Slack space.
You give me 30 seconds warning.
I pack my bags, I get out of the hotel.
>> To the next room maybe.
>> Paying customer doesn't know I was there,
but maybe I find another room.
>> Yeah. So, you mentioned the notification.
We are offering 30 seconds notification,
using our in VM scheduled events.
So, it's a local end point non-routable IP.
You just make a simple call and
you'll get 30 seconds notification.
You can save state or
notify some job scheduler and so on so forth.
>> Okay, so if I'm pulling for that,
if I write my software where I'm smart and my software is
written such that I know I am
part of the low priority scale sets.
>> Right.
>> I would just pull that local endpoint,
I see that I've got 30 seconds, finish up what I'm doing,
shutdown, save my state somewhere else in Azure
maybe storage in a queue somewhere. It's up to me.
>> Notify a job scheduler of some sort.
>> Yes. And then get ready to pack my bags and leave.
>> Yes. So, let's go to a dome.
>> Let's do it.
>> All right. We'll start with CloudShell.
And we'll use the CLI to create low priority scale set.
>> Okay.
>> And it doesn't go simpler than that.
You see that's the simplest VM scaleset creation.
>> Right.
>>I just added a priority low.
Okay I'm just going to copy it.
And nothing new same good
old scale set already placed. And here goes nothing.
And we are just going to
provision a low priority scale set.
So, you hit enter at this point.
Yeah. It will take a couple of minutes,
but in the meantime I want to actually show
you two other interesting use cases.
So, the first one is as we mentioned,
we combined the delete on eviction policy,
with VM scale set autoscaling.
So, when Azure needs the capacity,
my VM is being evicted,
but then autoscale VM scale set
will try and recreate another instance.
So, this is finding another one
that is still low priority.
>> Yes. Still operating.
>> I'm being moved, but I'm still saving money.
Exactly. So, I have here,
from the existing things you've made before.
>> Yes.
>> There is a low priority one in the West Central.
>> Correct.
>> That's a low priority scale set.
And as you can see.
>> And auto scaling is on there.
>> You can see looking back,
this is evictions from last night.
This is the template who actually published
and it's a web form of some sort.
And you can start creating
jobs to actually run those CPUs busy.
In my auto scaling rule used average CPU,
right, to scale up.
So, there is an auto scaling here.
Said do 60 percent
I bump up in less than 30 I bumped down,
and range between five and 20.
Again, all low priority VMs.
If I look at my instances,
I've been running these for quite some time,
now I'm currently in my instance 183.
So, every here then Azure will evict my VM.
Then if there is a load or I
came below that I reached the minimum
to 5 for instances on a scale to try
and compensate and provision a new one.
If I look back like the last 24 hours,
I can see that yesterday I put them all to do some work.
And you can see that each of those bumps is an eviction.
So, somewhere around whatever 2:00 p.m. yesterday,
the last VM which did some work got evicted,
and then auto scaled compensated and created
another low priority VM which didn't do any work.
So, now my VMs do nothing,
but they still have five low quality VMs.
>> And you've had 183 different versions
of VM out there because.
>> It's a very simple web server which does some.
>> Which brings up an interesting question though,
what kind of work would I want to do?
I don't think I want to run my website necessarily
on low priority VMs if they were important.
>> Exactly.
>> So, whether your application can
handle a single VM being evicted.
So, that's key.
You need to have this smarts or have your VMs settlers.
And then, if you want some sort of
a minimal guaranteed number of VMs.
This brings us to
the second use case which we call hybrid scale set.
So, in this case we actually combined two scale sets.
One is it on demand, fully paid,
guaranteed self instances and the other is low priority.
Two scale set behind a single load balancer.
You can't control both with two different auto scaling.
You can say, "Hey, I need
minimum five VMSS and the rest could be low price."
>> That sounds like actually a really nice solution,
because I might have a minimum of five,
I'm going to pay full price,
but then I might have another 10 or
15 or 100 or 100, yeah that are all over.
Actually that's interesting because I could have
prices from 60 or 80 percent
off for the price of one. I could have five.
>> That's exactly the math to keep in mind.
Well, if you're using non-Windows.
>> Using non-Windows. Yes.
>> So, the way this one looks
like and I call it believe it or not hybrid.
In the template again, we've done this with our template,
because there are not rules
and non-default balancing rules.
So, first we're using the standard SLB not the basic,
so it's the non-default.
You need that because if you
want to load balance to scale sets,
you actually need a standard load balancer.
>> Makes sense.
>> By the way, those could spread
multiple availability zones.
>> Indeed.
>> As long as it's within the same region.
So, those are on the single subnet
behind a single load balancer as I mentioned.
And then you can see I have the LP,
the low priority scale set and the regular scale set.
So, in this case,
the regular I just set it to one.
So, I have one guaranteed instance
and the rest may burst.
So, if we just look at the load balancer at this time.
Yeah, back in pool three virtual machines.
>> Yes.
>> So, you can see that I have one regular RAG.
And just at this time two low priority.
And again if I turn on the CPU,
turn on the load on those VMs,
it will scale first on the low priority and then
eventually if I fail to scale on demand.
>> It really sounds to me like from
an application developers perspective,
if I'm thinking about Cloud first,
if I'm not thinking about old style
where all my states in
the VM and my VMs really have to
be around for 24 hours a day.
I'm thinking about using
other things like you said Job Schedulers,
Azure Storage and keeping my VM stateless,
this is hugely valuable.
>> Yes. One use case we've already tried with customers,
if you have any rendering job,
then you basically save state in an ongoing fashion,
and you just use low priority to
burst and finish your job faster.
Azure batch have been using low
priorities scale set for quite some time.
Actually, they were our guinea pig.
So, that was the first service
using low priority scale set,
and I'm really happy to say
that based on the confidence we've gained,
we decided to let other workloads and other customers
to benefit from our low priority and discounted.
>> So, people can certainly look to
Azure Batch if their jobs are batch appropriate jobs.
But now other people who can just
have any virtual machine based job, can do this work.
>> Yes. Before I forget,
if you look at your ARM template,
there's only one thing to keep in mind,
just bump the API version to
anything above December 2017,
this is where we started supporting scale set.
And then within your visual machine profile
you'll see two new properties.
One is the priority,
which is low if you want low priority and
Eviction policy which is either
delete or the default which is deallocate.
>> Maybe let's run over to your CLI and
see if your VMs got created.
>> Yes. Actually we can just go and look for.
>> Go look for the research.
>> The resource itself and do a refresh.
>> And do a refresh.
I just called it low priority.
>> Yeah, there it is showed up in Central.
>> And yeah by default it will be a single state scale
set behind that SLB on a V-net with a public AP.
That's the default no fancy net
or load balancing rules here, that's just the basic.
>> Fantastic. So, people can check this out
and they can go look at the docs and learn about this?
>> Yeah. So, the doc currently
available is the low priority
VM scale sets, it's a preview.
The doc is been published a few weeks back.
We'll do some more noise as we get closer to a build.
There are some known issues with the preview,
so I hope by the time this
goes out we'll figure out all of
those known issues and
just go ahead and try low priority skill sets.
>> Fantastic. Great way to use
that Slack capacity and save a ton of money.
>> Yes.
>> All right. I'm learning all about
low priority virtual machines and
scale sets here on Azure Friday.