Microsoft has recently released Premium SSD P2 Disk.
This new feature is highlighting a change in the underlying architecture of the storage service in Azure. Before this v2 release, the performance of a disk was always associated with the size of the disk. With the v2 release, there are numerous improvements to the disk service. Among other things you have the ability now to define what kind of IOPS and bandwidth you want without the need to have a larger size on the disk. Also, you can define size more granularly with 1 GB increments, and unlike regular premium disks.
(Well almost close to that flexibility, to be able to set 80,000 IOPS on a disk, that disk must have at least 160 GiBs. Increasing your IOPS beyond 3000 increases the price of your disk.)
This means that we have more flexibility, however, the cost for the service is now split up into IOPS / Bandwidth / Size.
Some of the properties.
- 3000 IOPS by default
- 125 MB/s by default
We can also easily adjust performance of the disks using PowerShell
az disk update --subscription $subscription --resource-group $rgname --name $diskName --disk-iops-read-write=5000 --disk-mbps-read-write=200
So how does this compare with the regular Premium disk offering? In all cases we can see that Premium v2 disks are always cheaper than the current premium offering. We can even have a disk that has twice the performance and still is cheaper if we look at the current example below.
| Disk size | Premium v1 (Performance) | Premium v2 (Performance) | Premium v1 (Cost) | Premium v2 (Cost) |
| 128 GB | 500 IOPS / 100 MB/S | 3000 IOPS / 125 MB/S | 19,7$ | 10,28$ |
| 256 GB | 1100 IOPS / 125 MB/S | 3000 IOPS / 125 MB/S | 38$ | 20$ |
| 512 GB | 2300 IOPS / 150 MB/S | 3000 IOPS / 150 MB/S | 73$ | 42$ |
| 1024 GB | 5000 IOPS / 200 MB/S | 5000 IOPS / 200 MB/S | 135$ | 95$ |
| 2048 GB | 7500 IOPS / 250 MB/S | 7500 IOPS / 250 MB/S | 259$ | 192$ |
| 2048 GB | 7500 IOPS / 250 MB/S | 15000 IOPS / 500 MB/S | 259$ | 251$ |
Now it should be important to note that there are some limitations in the current release.
- Can only be used as a data disk
- Can only be used on VMs that are using Availability Zones
- Does not support Azure Disk Encryption or Encryption at host enabled.
- Azure Backup is currently not supported for this feature
Now in addition to this, Microsoft also has a public preview now for a new CSI driver for AKS (also v2) which is aimed at improving stability for pod failover. It does this by using replica mounts on Azure Disk persistent volumes which automatically pre-creates replica attachments to ensure that the volume will be rapidly available when pods failover between cluster nodes.
Azure Disk CSI Driver V2 scheduler extender influences pod placement by prioritizing healthy nodes where attachment replicas for the required persistent volume(s) already exist (i.e. node(s) to which the managed disk(s) is(are) already attached). It relies on the AzVolumeAttachment instances to determine which nodes have attachment replicas, and the heartbeat information in the AzDriverNode to determine health.
It should also be noted that you do not need to CSI driver v2 to use Premium Disk v2 instances for AKS clusters, you just need to reference it in a storage class, as I’ve done using this storage class definition
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: azure-premiumv2 provisioner: disk.csi.azure.com parameters: Skuname: PremiumV2_LRS reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer
Also, the new CSI drivers also now support live resizing of volumes using Azure Managed Disks. To use this, you can sign up for the preview here –> link
You also need to register the resource features
az feature register --namespace Microsoft.Compute --name LiveResize az feature show --namespace Microsoft.Compute --name LiveResize
Now if you want to extend your volumes you need to
kubectl patch pvc pvc-azuredisk --type merge --patch '{"spec": {"resources": {"requests": {"storage": "15Gi"}}}}'
So, a lot happening! after testing as well, I see that the benchmarks are providing the IOPS referenced.