>> Do you struggle with latency between your application tiers?
Proximity Placement Groups now make it possible for you to
co-locate your virtual machines to achieve minimal latency.
Ziv is here to show us how it works today on Azure Friday.
[MUSIC]
>> Hey everyone, Donovan Brown here with
another episode of Azure Friday.
I'm here with Ziv and we're going to learn
about Proximity Placement Groups.
So what is a Proximity Placement Group, and why do I care?
>> So to begin with,
if you moved your applications to Azure,
enterprise applications on multiple tiers,
you have an application tier and a database tier.
In Azure, you basically are trying
to put them together to get the best latency, right?
>> Right.
>> It's not that easy. Why? Because multiple deployments
in a single region may span multiple data centers.
Even availability zones actually may span multiple data centers.
>> Right.
>> Even scale set and in
the future availability sets may span multiple data centers.
So what do you do? How do you put them together?
Because you want to get the best latency.
This is why we are thrilled to introduce
Proximity Placement Groups or from their on, PPG.
>> Okay.
>> It's a new construct in Azure.
It's an ARM resource enabling you to
co-locate your multiple compute resources.
Today we support only infrastructure as a service resources,
in the same data center to get the best latency.
>> Got you.
>> So you can take
your virtual machines either in or not using availability sets.
You can take multiple scale sets and put them all
inside one PPG or one Proximity Placement Group,
to get the best latency possible or available today in Azure.
>> Got you. So it's really just a logical construct that says,
anything that I assign to this PPG,
make sure that they're extremely close to each other,
so that I can minimize
my latency between the network communication.
>> Correct. Exactly.
>> All right.
>> Yes.
>> Got it.
>> You can use multiple skills.
You're using your application,
using it with GPUs and the database running regular VMs.
You're using Bare-metal for
large instance of SAP HANA for example,
and you want your application servers to
be co-located. Whatever goes.
>> Got you. Okay.
>> As long as it is infrastructure as a service today.
>> Today. Right. So eventually,
I'll be able to have different types of resources
co-located as well such
that between my app service and my database,
just as well as between my database
and my i-ADS, are still going to be faster.
>> Correct.
>> Okay. Great.
>> That is our road map.
>> North star.
>> Yes. So we've just announced a public preview.
>> Okay.
>> For infrastructure as a service only.
Available in almost all regions,
and want to see a demo?
>> Yes. I'd love to see how it works.
>> Actually, before that. We have introduced,
so I mentioned, it's a new resource in ARM.
>> Yes.
>> So you need to start by creating it.
You can use either ARM templates, CLI, or PowerShell.
>> Okay.
>> They are not yet there in the portal.
>> Interesting.
>> You can see a preview. You create
this Proximity Placement Group object
and then you use it when you create your availability set,
or VM, or scale set.
>> Got you. Okay. Show us
an example because here I see you in an ARM template,
and I see that, okay got it.
So right under properties there's the proximity placement.
>> Yes.
>> That's where I'm assigning the resource that I
either provision before this ARM template
or as part of this ARM template as this
is where I want you to put all their resources out of a set.
>> Correct.
>> Got it. Okay. Cool. We can do this,
you said, from the CLI as well.
>> Let's give it a try.
>> Cool.
>> So I just created a new resource group,
and I will try and create my placement group.
>> Okay.
>> So it's PPG.
>> Got it.
>> Create providing the region
and the resource group, I just created it.
Then, I will pick up the ID from this newly created PPG.
>> Okay. So with that IP then you'll be able to.
>> You can see PPG ID. This is how it look like.
>> Okay.
>> Then when I create for example,
an availability set, I have one more parameter,
you see it's PPG ID.
>> Got you.
>> You can see it in the script here.
>> As I start to add additional resources,
is there any limit to the number of
resources I can assign to a PPG?
>> No.
>> Okay.
>> No limit. The only limit is
the physical capacity of the data center.
>> Got you.
>> In other words, if you have 10,000 VMs,
probably PPG is not for you.
>> Oh, interesting. Got you.
That's simply because trying to find that many in
a region or in a data center not a region, right.
That's very specific, so data center.
>> Yes.
>> Because a region is actually made up of multiple data centers,
and I want to be in one data center
that has network close as possible.
>> Correct.
>> Got it. Okay. Good.
>> Now, while it runs I want to flip or actually just.
>> Too fast man. It's done.
>> It's done already. I just want
to highlight one interesting aspect.
So often you use multiple skews within your PPG.
You have the back end running a very large instance,
like an MV2 VM.
>> Okay.
>> You have your application maybe running
some exotic VM like one of the latest GPUs,
and those may not be available in all the data centers.
>> That's right.
>> Even in the region. So if you start with your application tier,
let's say it's a DV3,
which is available almost everywhere.
Then you use PPG,
and then you follow with the MV2,
you may fail because I cannot have it.
I don't have it the MV2 in the same data center.
So the recommendation in that case,
is to start with the more,
what you call exotic skews.
Usually it's the largest, the more expensive.
The one which you may
think that we don't have them
worldwide or in any of the data centers.
>> Got you.
>> In case you see an error,
and the error that you'll see is
an oversubscribed allocation request.
Then simply stop the allocate your VMs and try in a reverse order.
Just change the sequence of
your deployment and we'll do the right thing for you,
or use ARM template where you
can put them all together and we will take it from there.
>> But even if I place it in an ARM template,
if that region simply does not have
the capacity my ARM template will fail.
>> Correct. Yes.
>> But I think I still like your idea
of start with the biggest thing first,
because you don't want to provision
all these other resources just to find
out that the heavy hitter that you once not available in the fail.
>> Exactly.
>> Try the biggest thing first and if that succeeds,
chances are all those little stuff
is going to succeed with them as well.
>> Yeah.
>> Got it.
>> Yeah.
>> All right. Perfect.
>> Few more tips.
Always in this case if latency is an issue for you,
just make sure you're using Accelerated Networking.
>> Okay.
>> I think today it's the default for almost all VM sizes.
>> Okay.
>> Look, we have a documentation of how to
optimize your network throughput for Azure Virtual Machines,
and know what you are measuring.
Okay. If you are looking for latency,
we have documented a tool to measure latency.
Don't try to copy whatever 100 GB
and look for it because you're not really testing latency.
>> Oh, very good point.
>> We're testing many other things. You're testing throughput,
you're testing the bandwidth.
>> The speed and all sorts of stuff.
>> The speed. So if you just want to look for latency,
just make sure you're measuring latency.
>> That's very good advice because a lot of us would
probably see how fast can I download
something from one machine to another.
>> Ping, is not a way to test.
>> Always good to know.
Well, we're learning all about
Proximity Placement Groups here on Azure Friday.
>> [MUSIC].