Maybe you are considering migration of on-premise SAP ASE databases to Microsoft Azure, or you may be considering migrating from your existing database vendor to SAP ASE on Azure.
Either way, you will benefit from understanding a good, practical disk topology for SAP ASE on Azure.
In this post, I show how you can optimise use of the SAP ASE, Linux and Azure technical layers to provide a balanced approach to disk use, considering both performance and disk (ASE device) management.
The Different Layers
In an ASE on Linux on Azure (IaaS) setup, you have the following layers:
Azure Storage Services Azure Data Disk Cache Settings Linux Physical Disks Linux Logical Volumes Linux File Systems ASE Database Data Devices ASE Instance
Each layer has different options around tuning and setup, which I will highlight below.
Azure Storage Services
Starting at the bottom of the diagram we need to consider the Azure Disk Storage that we wish to use.
There are 2 design considerations here:
size of disk space required. performance of disk device.
For performance, you are more than likely tied by the SAP requirements for running SAP on Azure.
Currently these require a minimum of Premium SSD storage, since it provides a guaranteed SLA. However, as of June 2020, Standard SSD was also given an SLA by Microsoft, potentially paving the way for cheaper disk (when certified by SAP) provided that it meets your SLA expectations.
Generally, the size of disk determines the performance (IOPS and MBps), but this can also be influenced by the quantity of data disk devices.
For example, by using 2 data disks striped together you can double the available IOPS. The IOPS are an important factor for databases, especially on high throughput database systems.
When considering multiple data disks, you also need to remember that each VM has limitations. There is a VM level IOPS limit, a VM level throughput limit (megabytes per second) plus a limit to the number of data disks that can be attached. These limit values are different for different Azure VM types.
Also remember that in Linux, each disk device has its own set of queues and buffers. Making use of multiple Linux disk devices (which translates directly to the number of Azure data disks) usually means better performance.
Choose minimum of Premium SSD (until Standard SSD is supported by SAP). Spread database space requirements over multiple data disks. Be aware of the VM level limits. Azure Data Disk Cache Settings
Correct configuration of the Azure data disk cache settings on the Azure VM can help with performance and is an easy step to complete.
I have already documented the best practice Azure Disk Cache settings for ASE on Azure in a previous post.
Correctly set Azure VM disk cache settings on Azure data disks at the point of creation. Use LVM For Managing Disks
Always use a logical volume manager, instead of formatting the Linux physical disk devices directly.
This allows the most flexibility for growing, shrinking and striping the disks for size and performance.
You should stripe the data logical volumes with a minimum of 2 physical disks and a maximum stripe size of 128KB (
test it!). This fits within the window of testing that Microsoft have performed in order to achieve the designated IOPS for the underlying disk. It’s also the maximum size that ASE will read at. Depending on your DB read/write profile, you may choose a smaller stripe size such as 64KB, but it depends on the amount of Large I/O and pre-fetch. When reading the Microsoft documents, consider ASE to be the same as MS SQL Server (they are are from the same code lineage).
Stripe the transaction log logical volume(s) with a smaller stripe size, maybe start at 32KB and go lower
but test it (remember HANA is 2KB stripe size for log volumes, but HANA uses Azure WriteAccelerator).
Use LVM to create volume groups and logical volumes. Stipe the data logical volumes with (max) 128KB stripe size & test it. Use XFS File System
You can essentially choose to use your preferred file system format; there are no restrictions – see note 405827.
However, if you already run or are planning to run HANA databases in your landscape, then choosing XFS for ASE will make your landscape architecture simpler, because HANA is recommended to run on an XFS file system (when on local disk) on Linux; again see SAP note 405827.
Where possible you will need to explicitly disable any Linux file system write barrier caching, because Azure will be handling the caching for you.
In SUSE Linux this is the “nobarrier” setting on the mount options of the XFS partition and for EXT4 partitions it is option “barrier=0”.
Choose disk file system wisely. Disable write barriers. Correctly Partition ASE
For SAP ASE, you should segregate the disk partitions of the database to avoid certain system specific databases or logging areas, from filling other disk locations and causing a general database system crash.
If you are using database replication (maybe SAP Replication Server a.k.a HADR for ASE), then you will have additional replication queue disk requirements, which should also be segregated.
A simple but flexible example layout is:
Volume Group Logical Volume Mount Point Description vg_ase lv_ase<SID> /sybase/<SID> For ASE binaries vg_sapdata lv_sapdata<SID>_1 ./sapdata_1 One for each ASE device for SAP SID database. vg_saplog lv_saplog<SID>_1 ./saplog_1 One for each log device for SAP SID database. vg_asedata lv_asesec<SID> ./sybsecurity ASE security database. lv_asesyst<SID> ./sybsystem ASE system databases (master, sybmgmtdb). lv_saptemp<SID> ./saptemp The SAP SID temp database. lv_asetemp<SID> ./sybtemp The ASE temp database. lv_asediag<SID> ./sapdiag The ASE saptools database. vg_asehadr lv_repdata<SID> ./repdata The HADR queue location. vg_backups lv_backups<SID> ./backups Disk backup location.
The above will allow each disk partition usage type to be separately expanded, but more importantly, it allows specific Azure data disk cache settings to be applied to the right locations.
For instance, you can use read-write caching on the vg_ase volume group disks, because that location is only for storing binaries, text logs and config files for the ASE instance. The vg_asedata contains all the small ASE system databases, which will not use too much space, but could still benefit from read caching on the data disks.
TIP: Depending on the size of your database, you may decide to also separate the saptemp database into its own volume group. If you use HADR you may benefit from doing this.
You may not need the backups disk area if you are using a backup utility, but you may benefit from a scratch area of disk for system copies or emergency dumps.
You should choose a good naming standard for volume groups and logical volumes, because this will help you during the check phase, where you can script the checking of disk partitioning and cache settings.
Segregate disk partitions correctly. Use a good naming standard for volume groups and LVs. Remember the underlying cache settings on those affected disks. Add Whole New ASE Devices
Follow the usual SAP ASE database practices of adding additional ASE data devices on additional file system partitions sapdata_2, sapdata_3 etc.
Do not be tempted to constantly (or automatically) expand the ASE device on sapdata_1 by adding new disks, you will find this difficult to maintain because striped logical volumes need at least 2 disks in the stripe set. It will get complicated and is not easy to shrink back from this.
When you add new disks to an existing volume group and then expand an existing lv_sapdata<SID>_n logical volume, it is not as clean as adding a whole new logical volume (e.g. lv_sapdata<SID>_n+1) and then adding a whole new ASE data device.
The old problem of shrinking data devices is more easily solved by being able to drop a whole ASE device, instead of trying to shrink one.
NOTE: The Microsoft notes suggest enabling automatic DB expansion, but on Azure I don’t think it makes sense from a DB administration perspective. Yes, by adding a new ASE device, as data ages you may end up with “hot” devices, but you can always move specific devices around and add more underlying disks and re-stripe etc. Keep the layout flexible.
Add new disks to new logical volumes (sapdata_n+1). Add big whole new ASE devices to the new LVs. Summary:
We’ve been through each of the layers in detail and now we can summarise as follows:
Choose a minimum of Premium SSD. Spread database space requirements over multiple data disks. Correctly set Azure VM disk cache settings on Azure data disks at the point of creation. Use LVM to create volume groups and logical volumes. Stipe the logical volumes with (max) 128KB stripe size & test it. Choose disk file system wisely. Disable write barriers. Segregate disk partitions correctly. Use a good naming standard for volume groups (and LVs). Remember the underlying cache settings on those affected disks. Add new disks to new logical volumes (sapdata_n). Add big whole new ASE devices to the new LVs. Useful Links:
You may also be interested in: