Planning for Implementing SAP Solutions on Azure (part 3 of 5)

By Ashwin Venugopal -

 


To read part 1 please click here
To read part 2 please click here
To read part 4 please click here
To read part 5 please click here



Azure VM Storage Considerations

While planning your disk layout you can find optimal configuration with the help of following factors:
  • The number of data files
  • The number of disks that contain the files
  • The IOPS quotas of a single disk
  • The data throughput per disk
  • The number of additional data disks possible per VM size
  • The number of storage throughput a VM can provide
  • The latency difference an Azure Storage type can provide
  • VM SLAs

Paging/Swap Files

While configuring the paging/swap files you should use the following recommendations:
  • Windows operating system pagefile should reside on the D: drive (i.e. non-persistent disk)
  • Linux swapfile should reside under/mnt/resource and can be configured in the configuration file of the Linux Agent/etc/waagent.conf; you can also add or change the following settings-
  1. ResourceDisk.EnableSwap=y
  2. ResourceDisk.SwapSizeMB= <size_in_MBs>

  • To activate the changes, you need to restart the Linux Agent by running sudo service waagent restart.

Managed Disks

It is recommended to use managed disks for all SAP workloads. They are also required to implement Write Accelerator which is a disk capability of M-series Azure VMs with Premium storage-based Azure managed disks, whose main purpose is to improve the I/O latency of writes. Write Accelerator is ideally suited where log file updates are required to persist to disk in a highly performant manner for modern databases.

Premium Storage

Premium storage offers significantly better performance as compared to Standard Storage, especially for critical transaction log writes. It is recommended by Microsoft to minimally use Azure Standard SSD storage for Azure VMs hosting the SAP application layer as well as for non-performance sensitive DBMS deployment while using Azure Premium SSD storage for all the other Azure VMs DBMS workloads.

Standard storage is only certified for unmanaged disks and since application servers don't host any data, you can also use the smaller P4 aand P6 Premium Storage disks to help minimize the cost.

Multi-Disk Volumes

IOPS traffic to different data files is not always the same as existing customer systems may have different size of data files representing their databases, hence it is recommended to use striping over multiple disks to create volumes hosting data files.

Since the operations like writing savepoints or loading data in-memory after cash recovery can also be critical making it essential to leverage Azure Premium Disks for /hana/data and /hana/log volumes. To achieve the minimum throughput of /hana/data and /hana/log, you can build a RAID 0 volume by using MDADM or LVM over multiple Azure premium Storage disks and for RAID 0 stripe sizes recommended are- 64 KB or 128 KB for /hana/data and 32 KB for /hana/log. 

Caching

You can easily choose if you want to cache the I/O traffic between the VM and those disks located in Azure storage whenever you mount disks to VMs and the following caching recommendations assume these I/O characteristics for standard DBMS:
  • I/O consists mostly of a read workload against the data files of a database who are performance critical for DBMS systems. 

  • Writing against the data files occurs in bursts based on checkpoints or a constant stream and on an average there are fewer rights than reads per day that are asynchronous as well as doesn't hold up any user transactions.

  • There are hardly any reads from the transaction log or redo files except for large I/Os when you perform transaction log backups.

  • The main load against transaction or redo log files is writes and depending on the nature of the workload, you can also have the I/Os as small as 4 KB, or in other cases, I/O sizes of 1 MB or more.

  • All writes must be persisted on disk in a reliable fashion.

It is recommended by Microsoft to use Azure Write Accelerator for your DBMS deployment for M-series deployments which should be enabled for /hana/log volume for Azure M-series VMs SAP HANA certification. The current limitations of Azure Premium Storage VHDs per VM that can be supported by Azure Write Accelerator are as follows:
  • 16 VHDs for an M128xx and M416xx VM
  • 8 VHDs for an M64xx and M208xx VM
  • 4 VHDs for an M32xx VM



To read part 1 please click here
To read part 2 please click here
To read part 4 please click here
To read part 5 please click here








Comments

Post a Comment

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

By Ashwin Venugopal -
Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use Azure Load Balan
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more