Premium SSD v2 is available to Azure customers with a broad set of features and benefits. In this article we will highlight the options available to best use Premium SSD v2 disks for SAP workloads.
Premium SSD v2 basics
Different storage options are available depending on the requirements. Premium SSD v2 differs from the long-established Premium SSD by providing you with more options and modified pricing for each of these options. The main differences over Premium SSD are:
- Up to 1200 MB/s throughput, low latency, up to 80k IOPS and 64 TiB in size
- Any disk size from 1 GiB to 64 TiB in 1 GiB increments with per GiB pricing
- Throughput and IOPS configurable and adjustable online
- 125 MB/s and 3000 IOPS provided as baseline
- No disk bursting, no host caching and no Write Accelerator with Premium SSD v2
- Cost based on selected size + IOPS + throughput
While with Premium SSD you have set disk sizes or SKUs, which combine billed capacity with set throughput and IOPS limits, with Premium SSD v2 you can freely set each of the three parameters independently. You want a 20 GiB disk with 1000MB/s throughput and 20k IOPS? No problem. You want a 5 TiB disk with 200 MB/s and 3k IOPS? Just set the values and Azure will bill you accordingly. If you compare with Premium SSD, Premium SSD v2 will be cheaper if configured with identical size and throughput.
This means for your SAP workloads, you can provide both faster overall performance and tune the storage parameters to match your requirements, while adding flexibility. See the Azure documentation for details on Premium SSD v2.
One important aspect to consider is that current time Premium SSD v2 can only be attached to zonal VMs, that is VMs with a set zonal deployment. If your SAP landscape is deployed with regional VMs – with or without availability sets – this is not supported at publish time of this blog post. See the documentation details for updates.
SAP use cases with Premium SSD v2
Where can you use Premium SSD v2 with your SAP workloads? In short, for all situations. Premium SSD v2 is certified for use with SAP workloads – SAP note 2015553 – and also noted in individual SAP certification for SAP HANA. It can be used for your application layer such as (A)SCS and application servers, your database servers and any infrastructure servers.
Premium SSD v2 for SAP applications and infrastructure servers
For SAP application layer and any generic infrastructure servers (such as DNS, saprouter, etc.), you can utilize Premium SSD v2 for all data disks. One expected benefit is that you can configure disk sizes with 1 GiB increments, no longer x2 increases in size. If you need an 80 GiB disk containing /usr/sap physical volume, you set and pay for 80 GiB. Set IOPS and throughput as needed, if more than baseline is required.
Premium SSD v2 for SAP HANA
For SAP HANA, Azure documentation provides a recommended starting configuration with Premium SSD v2. As this is a starting configuration, you might need to modify the parameters for size, throughput and IOPS to fit your needs.
As there is no host caching available with Premium SSD v2, host (VM) caching setting for disk must be set to None. This also means that write accelerator caching for HANA log disk(s) is neither available nor should it be needed to meet SAP’s HANA I/O requirements.
No host caching means no write accelerator, which in turn opens a very easy way to use E-series VMs for SAP HANA for smaller memory sizes with only this disk type. Premium SSD v2 performs with low latency for IO, which fulfil SAP HANA requirements.
Premium SSD v2 for non-HANA databases
Every supported SAP database vendor is fully supported and documentation is available with a recommended starting configuration and DB specifics, if any apply.
You can right-size every filesystem of an SAP database, to the exact GiB required and without any fixed disk sizes. Same for IOPS and throughput requirements. Databases often have many different filesystems with different growth and performance requirements, such as archive logs, temporary tablespace locations, undo data , etc. depending on database deployed.
Non-HANA databases with Premium SSD disks can greatly benefit in specific situations from available host caching type readOnly. Host caching can accelerate many I/O requests on these databases. Host caching is not available for Premium SSD v2, which can require you to adjust the needed disk IOPS or throughput sizing for some disks. There is no one-size-fits-all solution. Analyze the workload, see the available Azure documentation for your database vendor and tune managed disk parameters.
Azure provides numerous performance metrics on the used infrastructure, giving you a very transparent view into any existing bottlenecks. For a database centric view, create an Azure Monitor dashboard or workbook to view the VM and individual disk data.
As an example, below is a workbook of a DB VM, with metrics for the VM and disk.
For storage performance evaluation, look at the following metrics:
- VM
- IOPS and bandwidth consumed percentage for VM overall
cached | uncached | disk overall
- IOPS and bandwidth consumed percentage for VM overall
- Disk
- Disk read/write IOPS and throughput
for multi-disk stripe sets, a single disk indicates same usage level of all members
Several Premium SSD disks metrics include IOPS/bytes from the cache
- Disk read/write IOPS and throughput
If you have SAP running in Azure already, it’s likely using Premium SSD and you can see caching usage. You can also leverage machine learning to analyse your disk performance. You can also use Copilot to troubleshoot your disk performance and display disk bottlenecks. As with any AI generated advice, consider if the findings are appropriate.
Premium SSD v2 single disk vs striping
For SAP workloads when using Premium SSD, to reach the necessary performance for database VMs, many customers deploy multiple disks and stripe over them using lvm or Windows storage spaces. Such stripe set combines the throughput and IOPS of individual disk members. With Premium SSD, without depending on bursting, the disk SKU sets the throughput and IOPS limits and can be insufficient on some filesystems.
With Premium SSD v2, you have much higher limits for a single disk – 1200 MB/s throughput and upto 80k IOPS – and can specify the values independent of the disk size. The choice of using a single disk or split the aggregate performance requirements between multiple disks in a stripe sets is yours to make.
With striping, you have to correctly set logical volume manager’s volume group settings on stripe size and count and keep all disks equal in size and performance. You do have the following advantages with this
- VM storage limits are increasing with every generation
- Premium SSD v2 gives each disk a baseline of 125 MB/s and 3000 IOPS
As an example, consider the situation of wanting /hana/data filesystem to provide 2 TiB size, 1000 MB/s and 20000 IOPS.
As option 1, you can deploy a single disk with required parameters.
As option 2, using striping you:
- Deploy 4 disks, set up a volume group
- Each disk 500 GiB
- As baseline over the 4 disks, you have 12k IOPS and 500 MB/s in aggregate
- Add to each of the 4 disks an additional +2k IOPS, for a total of 5k and +375 MB/s for a total of 500MB/s, on each of the 4 disks. Giving you the required performance and size.
The choice to-stripe-or-not is yours to make, as per your workload needs. Consider the support for Premium SSD v2 overall, how does this affect services like backup or disaster recovery and if using striped disks breaks such support.
If striping, keep the number of disks in volume group to a sensible number. Common choice is four disks for data and two for log areas. Such disk counts should be sufficient even for large databases, for very large (>20TB sizes) do not use more than 8 disks for database data and 4 disks for data log areas or other disks, unless recommended by Microsoft. These are recommended maximum disk counts for any stripe set in Azure for SAP, which should only be exceeded in exceptional circumstances only.
Start using Premium SSD v2 for SAP
You want to use Premium SSD v2. Great. How do you best do it for SAP workloads?
Decide first on your migration path from the three options available:
With the first option (01) of building new VMs with Premium SSD v2, you are either new to Azure or want to build a new SAP environment for a clean start. Maybe using own automation pipeline to deploy Azure resources, such as SDAF. Once the new VMs are created, copy the SAP workloads through application means – backup/restore, system copy etc.
This approach allows you to right-size your disk capacity and performance parameters from the start and set everything according to best practices, starting fresh with Premium SSD v2.
---------------------------------------------------------------------------------------------------------
The second option (02), you already are using Premium SSD or other storage type in Azure and want to switch to Premium SSD v2. But you want to make some architectural changes. Maybe you want to resize disks smaller than currently. As you can online increase managed disks (see blog post for details), you can’t reduce size. Maybe you want a different storage setup.
This approach uses the above steps and gives you the following benefits:
- OS and software configuration needs no changes
- Fix / Update on past storage architecture
- Right-size disks and disk count, often reducing storage size
Copying the data from old to new disks is a downtime activity for databases. Consider temporarily upsizing the Azure VM, if limited by total VM storage throughput. Once copy is completed, the source disks should not be needed. Adapt your disk mounts, ensure all data was copied and unmount and eventually delete the source disks.
---------------------------------------------------------------------------------------------------------
The third option (03) is to change the existing disks into Premium SSD v2. This option has its own benefits and drawbacks. While it is a downtime activity – you can’t convert a disk when it is attached to a running VM – you get to keep the same resource name and OS setup. At same time, as you convert existing disks, you can’t reduce the disk size in any case, neither can you reduce the disk count for multi-disk volume groups.
Use the disk change option via any means – portal, API or CLI – you need to be aware of any additional limitations for Premium SSD v2. The key points, current at the time of publishing, are:
- Limit of 50 active conversions at same time per subscription and region
- Host (VM) caching needs to be disabled for the disk
- Conversion process is a background activity. You will have degraded performance for the duration of this background copy on the specific disk. CompletionPercetage property is available to check on status on each disk.
A combination of options (02) and (03) is the creation of new Premium SSD v2 disks from snapshots. A snapshot of another disk is taken as source, be it a Standard or Premium HDD/SSD or another Premium SSD v2 disk. Then a new Premium SSD v2 disk is created, with the snapshot as the source instead of creating an empty disk. This method duplicates a disk of the same size without you needing to copy data within the OS. You can’t reduce the disk size or disk count. As a new disk is created, you have to make OS changes to unmount old and mount new disks. However, there is no data movement inside the VM/OS necessary, as the new disks contain all data from the source snapshot.
The same limitations apply as noted for disk conversion in option (03).
Logical sector sizes
Premium SSD v2 and Ultra Disks introduced the option to specify logical sector sizes. The default value is 4096 bytes, or 4k, both disk types support 512e sector size as well. This is important for some older database versions, as they might require the use of 512e sector size. Examples are Oracle Database version 12.1 and lower and Db2 LUW versions lower than 11.5. See respective DB documentation for any details.
A converted existing disk, whether from a snapshot or through disk type change, will result in a Premium SSD v2 disk with 512e sector size. This has, in our tests and experience, no measurable performance impact. For new Premium SSD v2 disks the recommendation is to use 4k logical sector size, where possible.
Recommended migration to Premium SSD v2
Carefully consider which migration option fits best to your requirements and specifications. Customers which want to renew their SAP landscapes in Azure, such as VM Gen2 deployment, OS major version updates or using VMs without temporary storage will likely consider deploying new VMs with Premium SSD v2 and migrate the application data through backup/restore or DB replication.
We expect many customers will want to adjust disk sizes or align disk striping with updated documentation recommendations. In such case, option (02) with new disks and copying data to new disks gives you the best choice. Especially for database VMs with large disks.
For smaller VMs, application VMs and infrastructure servers with often just one or two managed disks, size changes are not necessary and thousands of small files might have to be moved. Here disk conversion options are likely the most suitable tool, to move to Premium SSD v2.
Select the combination of migration options that works best for your business.
Deploying new or converting to Premium SSD v2 disks will consume Azure quota for this resource type. By default, up to 100 TiB per region and per subscription is available. A second quota type for the number of Premium SSD v2 disks exists. The technical names for the relevant quotas are PremiumV2DiskCount and PremiumV2DiskSizeInGB. Check both quotas on your Azure subscription(s) and create a support request to raise, if necessary.
Summary
Premium SSD v2 has been available in Azure for some time and is fully supported for productive SAP systems. It opens new options with its increased performance, fine grained and uncoupled sizing for disk size, throughput and IOPS. Use of E-series for SAP HANA (observe SAP certified VM sizes) is simplified.
- Independent settings for size | IOPS | MBps on each disk.
- While OS disks are currently not supported, all managed data disks in an SAP system can use Premium SSD v2.
- Determine which deployment / migration scenario best applies to your use case.
- Clarify if existing limitations might block your deployment scenario.
- Host caching for disk access is not available with Premium SSD v2. This includes write accelerator. Write accelerator not necessary for SAP HANA with Premium SSD v2.
- Some workloads might benefit with read cache and require additional IOPS/throughput with Premium SSD v2. Monitor usage and limits on both individual disk and VM level for storage operations before using migrating.
- In general, do not combine different storage types on single VM. Such combinations – for example few disks Premium SSD and others using Premium SSD v2, or with Ultra Disk – should be limited to exceptional workloads only.
- Logical sector size 4k | 512e available – migrated disks will show 512e but expect no application performance impact. Old database versions might require 512e.
- Converting existing disks to Premium SSD v2 uses a background copy process for both disk change and create new disk from snapshot. Check completionPercent on disk, reduced performance while active.
- Check Azure quotas for Premium SSD v2 (#disks, overall size) and supported regions.
Premium SSD v2 information and limitations
Premium SSD v2 snapshot and limitations
Microsoft