[MUSIC]
>> Hello, and thank you for tuning into this online session.
My name is Alec Becker,
I'm a Program Manager with Azure Storage on the disk team.
This presentation is about understanding
disk IO and how to leverage disk bursting.
In this presentation, I will be going
over an overview of Azure Disk.
I'll then be getting into a VM and
disk combination mismatch and
what that can mean for your performance.
Then I'll be getting into some brand new
disk IO utilization metrics.
Then finally, I'll be getting into
disk IO bursting and scenarios that it should
be used for and how the bursting capability works.
Azure disk is the best value persistent storage
for your business critical workloads.
These four unique capabilities of Azure disk will
enables you to seamlessly run your applications on Azure.
Azure disk is the fastest disk in the Cloud.
A single Ultra Disk can support up to 160,000
IOPS and two gigabytes of
throughput while maintaining sub-millisecond latency.
This is ideal for lifting and shifting
latency sensitive applications like MongoDB and MySQL.
This is also great for
applications that require high IOPS and throughput,
such as SQL and SAP HANA,
we have the promise of never losing your data and we are
the only Cloud provider who can say
they've achieved a zero percent AFR.
Customers love the fact that they do not have
to worry about data durability with us.
We offer a 99.9 percent single VM,
SLA for Azure VM leveraging premium or Ultra Disks.
This is the highest single VM SLA for any VM running in the Cloud.
With our money back guaranteeing SLA,
you can bet on our disk infrastructure
for your applications running smoothly.
Finally, we are backed by
an innovative and flexible architecture and with our Ultra Disk,
and that allows customers to dynamically change
their IOPS and throughput based on the workload requirements,
and this works great for seasonal workload peaks.
This allows you to maximize your performance while
also optimizing your costs,
by provisioning for peak performance when energy is only needed.
When evaluating your Azure Disk for your workload,
the primary considerations that you should have
for it or your latency,
which is how long it takes for
a piece of data to be written and persisted?
IOPS for, which is
how many input and output operations
that can be made in a second and throughput?
How much data can actually be transferred in a second?
Once you have a grasp of your workload
requirements for these considerations,
you can then start evaluating
which disk is best for your scenario.
The standard ACT disk is
the most cost-effective block storage offering on Azure.
It is best suited for dev and test environments and
other infrequent access workloads that are less
sensitive to performance variability.
If you're looking for an inexpensive storage
where consistent performance isn't critical,
the Standard HDD Disk is the disk for you.
Now if you need more consistent performance with lower latency,
you should go ahead and check out our Standard SSD Disk.
This offers the lowest gigabyte per
dollar cost of any SSD on the public Cloud.
Now the Standard SSD is great
for an entry level production workloads,
and that require consistent performance.
Now if you're looking for the ability to get
higher IOPS and throughput than the Standard SSD,
look no further than our Premium SSD Disk.
Our Premium SSD Disk is an amazing for production workloads
where performance is critical and that
requires higher IO and throughput.
Now finally, if you're looking for
the highest IOPS and highest throughput
on the Cloud and you're looking for sub-millisecond latency,
look no further than our Ultra Disk on Azure.
This disk also allows you to dynamically scale
your storage capacity and performance parameters independently.
It is our latest and greatest offering for disk on Azure's.
Finally, for all these disks,
we offer an array of different sizes,
that help meet your capacity and performance needs.
Standard HDD, Standard SSD,
and the Premium Disk come with
discrete bucketed sizes where
capacity and performance numbers are set.
However, ultra on the other hand,
gives you the flexibility to tune
your capacity and performance independently.
Now that you have an idea of
which disk to get for your production workload,
and once you have that figured out,
you also need to choose the right Virtual Machine to match this.
This is because virtual machines have their own storage IO limits
and therefore are the other half of
the equation when it comes to storage performance.
Sometimes a VM is not sized
correctly for the storage performance needed
for an application and this is
the scenario that we call VM IO Capped.
Let's run through an example of how this would actually play out.
Right here I have a D48s_v3 VM,
and that's capable of handling
1,152 megabytes per second of throughput.
Then attached to it I have OS disk that can handle 25 megabits of
throughput and two data disks that can handle
900 megabytes for throughput each.
I have an application that's running on top of this.
The application comes in and says, "Hey,
I've got a request for 1,825 megabytes per second of throughput,
" which is the sum total of
all the disks that are attached to this VM.
However, the VM can only handle 1,152 megabytes per second.
So the VM has to turn this request
down when processing it to the data disk.
The OS disk requests of 10 megabytes per second,
but the data does have to come down to 571 megabytes per second.
The data disks see this request and they say, "Okay, cool.
We can respond back with what we've been requested."
These get back to the VM level and get summed up
to 1,152 megabits per second.
This is not ideal.
This is VM IO capping,
where the application is requesting
an amount that the disk can all handle,
but the VM cannot handle this.
Solution for this would be to upgrade your VM
to a VM that could actually
handle this type of throughput request.
Now let's take a look at the other side of the coin where
the disks are the limiting factor
and this is what we call Disk IO Capped.
Here we have the same VM and we have
an application running on top of it
and a request what the VM can handle,
the 1,152 megabytes per second of throughput.
They come through to the disk and this is all fine.
Now this gets shuttled off and now we're dealing with
P30 disks that are attached and they're all data disks.
Now when this gets to the VM,
it gets split up into
different requests to the different data disks,
at 384 megabytes per second of throughput and the data disk goes,
"Hey, we can't handle this."
So what they're going to do is respond back with what they can
handle at 200 megabytes per second of throughput.
Then when it gets to the VM level,
that'll get summed up
into 600 megabytes per
second of throughput that gets surfaced to the application.
This isn't what we want as well.
This is where we're getting limited
by our disks that are attached to the VM.
A way to remedy this would be to either add
more P3 Data Disk to the system
to allow for additional throughput or to
upgrade these disks to a larger size premium disk or up to ultra.
I know you might be asking yourself,
''How can I tell if I'm being Disk IO Capped or
VM IO capped or am I VM and disk combination?"
Now we have these wonderful new IO utilization metrics
that can help you do this exact thing.
How these metrics work is they take
the amount of IO that is happening to your disk
and then it divides that by
the amount that is allotted by this disk.
This essentially gives you a percentage for how
much the disk IO is being utilized.
This is done for both bandwidth and IOPs,
and it also is done on OS Disk and Data disk.
Further, by Q3 of calendar year 2020,
we will have IO utilization metrics available for VMs as well.
This will be a utilization for both IOPs and
bandwidth on both the cached and uncached storage IO.
Now let's take a look at
these storage IO utilization metrics in action.
In this demo, I've gotten into the Azure Portal and set up a VM,
the standard D48s_v3, which is
the same ones that we've been going through with
the examples in this presentation.
Then on it, I've got one OS disk.
I can do 200 megabytes per second throughput,
and then five data disk that can
do 200 megabytes per second of throughput.
We're going to go ahead and connect to this VM via SSH.
Then we're going to run
a disk IO load using FIO to stress test on this disk.
What FIO is telling us near the bottom right now is it's
running at 700 or 800 megabytes per second.
This is nowhere near what we're seeing.
We should see around 1,100.
We're going to go into our Metrics tab
and we're going to take a look at
those new IO utilization metrics.
We'll look at the OS ones first and let me change
my timeframe here. We're going to take a look at it.
It is being utilized to 100 percent of its capacity,
which is what we want to see.
Let's go ahead and take a look at our data disks here.
We're seeing it at 60 percent and that's
overall for all across the data disk.
Let's apply some splitting so we can look at all the data disk
individually and here we can see the ones online,
four, zero and one are being utilized at
100 percent and the ones
at two and three are not being used at all.
To remedy this, we could either switch
the DataPath to FIO to make sure the ones on two and three
are being used or we could add the ones on
two and three to a storage pool that four,
zero and one are using to make sure that they are
being 100 percent used as well.
If you are seeing high utilization,
Bursting can be a great solution for this as well.
We have Disk Bursting feature which allows resources to go
above their provision or on cash limits for 30 minutes a day.
On the disk level, we have a Bursting feature enabled
for our premium disk up to a P20 disk,
which is a half terabyte.
This Bursting feature allows you to burst
your throughput up to 170 megabytes per second,
and also allows you to Burst your IOPs up to 3,500.
This comes enabled by default.
All you have to do is just attach
your premium disk and you get your Bursting feature.
It is based on a credit based system and I
will go over how this credit based system works on the next slide.
Now, on the VM level,
we offer VM level bursting on all Lsv2 series VM's.
We give you the ability to burst your throughput
up to eight times it's uncached amounts.
Again, we give you the ability to burst up to 30 minutes a day.
It comes enabled by default,
and it is also a credit based system.
Today, I'm also pleased to announce that we are unveiling
this VM level bursting on all DV3 and EV3 VMsin select regions.
This will be available in the West central region
and we plan to roll that out to more regions soon.
Now, this bursting feature allows
you to better optimize your performance and cost.
Because now you can provision for
the average IO instead of provisioning it for the peak.
It also allows your VM or
disk to handle unforseen spikes in this traffic.
You can have your peace of mind and knowing
that your disks and VMs can handle spiky traffic.
If you want to get the latest
and greatest about where this feature is all rolled out to,
you can go to Aka.ms/diskbursting.
Now let's get into how this bursting credits are
earned in use for our VMs and our disks.
To do this, I'm going to run through an example,
and we're going to run through an example of a P1 premium disk.
The P1 disk is provisioned to do
120 provision IOPs and it can burst up to 3,500 IOPs.
Just FYI, the disc and the VMs also
come preloaded with all the bursting tokens
when they're spun up or started.
But in this example we're going to assume
that our bucket is empty.
In the beginning, the P1 disk is sitting idle
for ten minutes with no IOPs happening to it.
It'll initially fill up this bucket with 120 IOPs per second.
We begin to fill our bucket for 10 minutes and then all of a
sudden it sees a spike in traffic
and it needs to go and burst up to use.
It can use these bursting tokens
that are now in this bursting bucket.
Now it can go ahead and use these tokens
that's accumulated and it can burst
up to 3,500 IOPs for
20 seconds and that's
how the bursting credits are earned and used.
Now, let's go ahead and see this in action.
Let's see this bursting in action.
What I've provisioned here is the L64s_v2,
which has bursting enabled up to two gigabytes per second and then
I have attached to it
enough disk to do two gigabytes per second of throughput.
Let's go ahead and SSH into this VM.
Just like the previous demo,
I will be running a stress test of FIO on
it to see how much throughput we can get on it.
Let's go ahead and run this FIO test.
Then at the bottom you could see right there we are
getting two gigabytes per second of throughput.
Please feel free to reach out to myself or my team at
azuredisks@Microsoft.com for any questions
related to disk IO utilization metrics,
disk bursting, general disk questions
or general storage questions.
We'd love to help you.
Thank you so much for tuning in and take care.