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.
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.
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.
Generally, the size of disk determines the performance (IOPS and MBps), but this can also be influenced by the quantity of data disk devices.
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.
Essentials:
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.best practice Azure Disk Cache settings for ASE on Azure in a previous post.
Essentials:
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.
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).
Essentials:
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.
Where possible you will need to explicitly disable any Linux file system write barrier caching, because Azure will be handling the caching for you.
Essentials:
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 Logical 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.
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.
Essentials:
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.
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.
NOTE : The Microsoft notes suggest enabling automatic DB expansion, but on Azure I don’t think it makes sense from a DB administration perspective.
Essentials:
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:
