Sounds easy but the same as computing that has a huge demand, Disks are very important and the better disks have tremendous demand. Not only from their size but also for some other factors like Speed of disk! scaling out is not always the consequence of computing limitation and sometimes is the effect of storage limitation
We have options(base on region and VM SKU) for Standard HDD, Standard SSD, Premium SSD, Ultra Disk and Shared Disk!
Fundamental
IOPS
IOPS, or Input/output Operations Per Second, is the number of requests that your application is sending to the storage disks in one second. An input/output operation could be read or write, sequential, or random. Online Transaction Processing (OLTP) applications like an online retail website need to process many concurrent user requests immediately. The user requests are insert and update intensive database transactions, which the application must process quickly. Therefore, OLTP applications require very high IOPS. Such applications handle millions of small and random IO requests.
IO requests
An IO request is a unit of input/output operation that your application will be performing. Identifying the nature of IO requests, random or sequential, read or write, small or large, will help you determine the performance requirements of your application.
If you are using an application, which does not allow you to change the IO size, use the guidelines in this article to optimize the performance KPI that is most relevant to your application. For example,
- An OLTP application generates millions of small and random IO requests. To handle these types of IO requests, you must design your application infrastructure to get higher IOPS.
- A data warehousing application generates large and sequential IO requests. To handle these types of IO requests, you must design your application infrastructure to get higher Bandwidth or Throughput.
If you are using an application, which allows you to change the IO size, use this rule of thumb for the IO size in addition to other performance guidelines,
- Smaller IO size to get higher IOPS. For example, 8 KB for an OLTP application.
- Larger IO size to get higher Bandwidth/Throughput. For example, 1024 KB for a data warehouse application.
Throughput = IOPS * IO Size
It is often stated by MB/s and it has a limit (maximum) on both disk and VM
Throughput, or bandwidth is the amount of data that your application is sending to the storage disks in a specified interval. If your application is performing input/output operations with large IO unit sizes, it requires high throughput. Data warehouse applications tend to issue scan intensive operations that access large portions of data at a time and commonly perform bulk operations.
| Application Requirement | I/O size | IOPS | Throughput/Bandwidth |
| Max IOPS | 8 KB | 5,000 | 40 MB per second |
Latency
Latency is the time it takes an application to receive a single request, send it to the storage disks and send the response to the client.
Premium Disks are designed to provide single-digit millisecond latencies for most IO operations. If you enable ReadOnly host caching on premium storage disks, you can get much lower read latency
Performance factors: IOPS, throughput, and latency at a glance
| IOPS | Throughput | Latency | |
| IO size | Smaller IO size yields higher IOPS. | Larger IO size to yields higher Throughput. | |
| VM size | Use a VM size that offers IOPS greater than your application requirement. | Use a VM size with throughput limit greater than your application requirement. | Use a VM size that offers scale limits greater than your application requirement. |
| Disk size | Use a disk size that offers IOPS greater than your application requirement. | Use a disk size with Throughput limit greater than your application requirement. | Use a disk size that offers scale limits greater than your application requirement. |
| VM and Disk Scale Limits | IOPS limit of the VM size chosen should be greater than total IOPS driven by storage disks attached to it. | Throughput limit of the VM size chosen should be greater than total Throughput driven by premium storage disks attached to it. | Scale limits of the VM size chosen must be greater than total scale limits of attached premium storage disks. |
| Disk Caching | Enable ReadOnly Cache on premium storage disks with Read heavy operations to get higher Read IOPS. | Enable ReadOnly Cache on premium storage disks with Ready heavy operations to get very low Read latencies. | |
| Disk Striping | Use multiple disks and stripe them together to get a combined higher IOPS and Throughput limit. The combined limit per VM should be higher than the combined limits of attached premium disks. | ||
| Stripe Size | Smaller stripe size for random small IO pattern seen in OLTP applications. For example, use stripe size of 64 KB for SQL Server OLTP application. | Larger stripe size for sequential large IO pattern seen in Data Warehouse applications. For example, use 256 KB stripe size for SQL Server Data warehouse application. | |
| Multithreading | Use multithreading to push higher number of requests to Premium Storage that will lead to higher IOPS and Throughput. For example, on SQL Server set a high MAXDOP value to allocate more CPUs to SQL Server. | ||
| Queue Depth | Larger Queue Depth yields higher IOPS. | Larger Queue Depth yields higher Throughput. | Smaller Queue Depth yields lower latencies. |
Disk caching
Caching is available for the Premium Storage. Disk Caching is not supported for disks 4 TiB and larger.
By default, the cache setting is set to Read/Write for OS disks and ReadOnly for data disks hosted on Premium Storage.
recommended disk cache settings for data disks,
| Disk caching setting | recommendation on when to use this setting |
| None | Configure host-cache as None for write-only and write-heavy disks. |
| ReadOnly | Configure host-cache as ReadOnly for read-only and read-write disks. |
| ReadWrite | Configure host-cache as ReadWrite only if your application properly handles writing cached data to persistent disks when needed. |
ReadOnly, you can achieve low Read latency and get very high Read IOPS and Throughput for your application.
ReadWrite, Using ReadWrite cache with an application that does not handle persisting the required data can lead to data loss, if the VM crashes
None, Currently, None is only supported on data disks. It is not supported on OS disks. If you set None on an OS disk it will override this internally and set it to ReadOnly.
Queue depth = IOPS * Latency
The queue depth or queue length or queue size is the number of pending IO requests in the system. The value of queue depth determines how many IO operations your application can line up, which the storage disks will be processing. It affects all the three application performance indicators that we discussed in this article viz., IOPS, throughput, and latency.
Standard HDD
| Standard Disk Type | S4 | S6 | S10 | S15 | S20 | S30 | S40 | S50 | S60 | S70 | S80 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Disk size in GiB | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| IOPS per disk | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 1,300 | Up to 2,000 | Up to 2,000 |
| Throughput per disk | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 300 MiB/sec | Up to 500 MiB/sec | Up to 500 MiB/sec |
Standard SSD
| Standard SSD sizes | E1 | E2 | E3 | E4 | E6 | E10 | E15 | E20 | E30 | E40 | E50 | E60 | E70 | E80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Disk size in GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| IOPS per disk | Up to 120 | Up to 120 | Up to 120 | Up to 120 | Up to 240 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 500 | Up to 2,000 | Up to 4,000 | Up to 6,000 |
| Throughput per disk | Up to 25 MiB/sec | Up to 25 MiB/sec | Up to 25 MiB/sec | Up to 25 MiB/sec | Up to 50 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 60 MiB/sec | Up to 400 MiB/sec | Up to 600 MiB/sec | Up to 750 MiB/sec |
Azure Premium Storage Disk
| Premium SSD sizes | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
| Disk size in GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1,024 | 2,048 | 4,096 | 8,192 | 16,384 | 32,767 |
| IOPS per disk | 120 | 120 | 120 | 120 | 240 | 500 | 1,100 | 2,300 | 5,000 | 7,500 | 7,500 | 16,000 | 18,000 | 20,000 |
| Throughput per disk | 25 MiB/sec | 25 MiB/sec | 25 MiB/sec | 25 MiB/sec | 50 MiB/sec | 100 MiB/sec | 125 MiB/sec | 150 MiB/sec | 200 MiB/sec | 250 MiB/sec | 250 MiB/sec | 500 MiB/sec | 750 MiB/sec | 900 MiB/sec |
| Max burst IOPS per disk** | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | 3,500 | ||||||
| Max burst throughput per disk** | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | 170 MiB/sec | ||||||
| Max burst duration** | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | ||||||
| Eligible for reservation | No | No | No | No | No | No | No | No | Yes, up to one year | Yes, up to one year | Yes, up to one year | Yes, up to one year | Yes, up to one year | Yes, up to one year |
Ultra Disk
The most recent type of disks with granular IOPS
| Disk Size (GiB) | IOPS Cap | Throughput Cap (MBps) |
|---|---|---|
| 4 | 1,200 | 300 |
| 8 | 2,400 | 600 |
| 16 | 4,800 | 1,200 |
| 32 | 9,600 | 2,000 |
| 64 | 19,200 | 2,000 |
| 128 | 38,400 | 2,000 |
| 256 | 76,800 | 2,000 |
| 512 | 80,000 | 2,000 |
| 1,024-65,536 (sizes in this range increasing in increments of 1 TiB) Max 64 TiB | 160,000 | 2,000 |
Bursting Disk
Premium SSD sizes smaller than P30 now offer disk bursting (preview) and can burst their IOPS per disk up to 3,500 and their bandwidth up to 170 Mbps. Bursting is automated and operates based on a credit system. Credits are automatically accumulated in a burst bucket when disk traffic is below the provisioned performance target and credits are automatically consumed when traffic bursts beyond the target, up to the max burst limit.
Disk Comparison
| Ultra disk | Premium SSD | Standard SSD | Standard HDD | |
|---|---|---|---|---|
| Disk type | SSD | SSD | SSD | HDD |
| Scenario | IO-intensive workloads such as SAP HANA, top tier databases (for example, SQL, Oracle), and other transaction-heavy workloads. | Production and performance sensitive workloads | Web servers, lightly used enterprise applications and dev/test | Backup, non-critical, infrequent access |
| Max disk size | 65,536 gibibyte (GiB) | 32,767 GiB | 32,767 GiB | 32,767 GiB |
| Max throughput | 2,000 MiB/s | 900 MiB/s | 750 MiB/s | 500 MiB/s |
| Max IOPS | 160,000 | 20,000 | 6,000 | 2,000 |
Reserve a disk!
Save on your premium solid-state drive (SSD) usage with reserved capacity, combined with Reserved Virtual Machine Instances you can decrease your total VM costs. The reservation discount is applied automatically to the matching disks in the selected reservation scope, you don’t need to assign a reservation to a Managed disk to get the discounts. Discounts are applied hourly on the disk usage and any unused reserved capacity does not carry over. Managed disk reservation discount does not apply to unmanaged disks, ultra disks, or page blob consumption.
Reservation discounts are not currently available for the following disks:
- Unmanaged disks/page blobs
- Standard SSD or standard HDD
Shared Disks
VMs in the cluster can read or write to your attached disk based on the reservation chosen by the clustered application using SCSI Persistent Reservations (SCSI PR). SCSI PR is a well-known industry standard leveraged by applications running on Storage Area Network (SAN) on-premises. Only available with premium SSDs. As of Feb 2020 only supported in the West Central US region. All virtual machines sharing a disk must be deployed in the same proximity placement groups. Can only be enabled on data disks, not OS disks
Sample workloads:
- SQL Server Failover Cluster Instances (FCI)
- Scale-out File Server (SoFS)
- File Server for General Use (IW workload)
- Remote Desktop Server User Profile Disk (RDS UPD)
- SAP ASCS/SCS
Ephemeral Disk
Ephemeral OS disks are created on the local virtual machine (VM) storage and not saved to the remote Azure Storage. Ephemeral OS disks work well for stateless workloads, where applications are tolerant of individual VM failures, but are more affected by VM deployment time or reimaging the individual VM instances. With Ephemeral OS disk, you get lower read/write latency to the OS disk and faster VM reimage.
The key features of ephemeral disks are:
- Ideal for stateless applications.
- They can be used with both Marketplace and custom images.
- Ability to fast reset or reimage VMs and scale set instances to the original boot state.
- Lower latency, similar to a temporary disk.
- Ephemeral OS disks are free, you incur no storage cost for OS disk.
- They are available in all Azure regions.
- Ephemeral OS Disk is supported by Shared Image Gallery.
Key differences between persistent and ephemeral OS disks:
| Persistent OS Disk | Ephemeral OS Disk | |
|---|---|---|
| Size limit for OS disk | 2 TiB | Cache size for the VM size or 2TiB, whichever is smaller. For the cache size in GiB, see DS, ES, M, FS, and GS |
| VM sizes supported | All | DSv1, DSv2, DSv3, Esv3, Fs, FsV2, GS, M |
| Disk type support | Managed and unmanaged OS disk | Managed OS disk only |
| Region support | All regions | All regions |
| Data persistence | OS disk data written to OS disk are stored in Azure Storage | Data written to OS disk is stored to the local VM storage and is not persisted to Azure Storage. |
| Stop-deallocated state | VMs and scale set instances can be stop-deallocated and restarted from the stop-deallocated state | VMs and scale set instances cannot be stop-deallocated |
| Specialized OS disk support | Yes | No |
| OS disk resize | Supported during VM creation and after VM is stop-deallocated | Supported during VM creation only |
| Resizing to a new VM size | OS disk data is preserved | Data on the OS disk is deleted, OS is re-provisioned |
Disk Disaster Recovery
| Scenario | Automatic replication | DR solution |
|---|---|---|
| Premium SSD disks | Local (locally redundant storage) | Azure Backup |
| Managed disks | Local (locally redundant storage) | Azure Backup |
| Unmanaged locally redundant storage disks | Local (locally redundant storage) | Azure Backup |
| Unmanaged geo-redundant storage disks | Cross region (geo-redundant storage) | Azure Backup Consistent snapshots |
| Unmanaged read-access geo-redundant storage disks | Cross region (read-access geo-redundant storage) | Azure Backup Consistent snapshots |