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

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different groups of computers, re
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning of alert rule parameter
Read more

Design Planning (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Complex Organizational Structures SIEM can be an expensive security control, hence, it is common multiple businesses to contribute to the overall expense. Various organizational units may require a level of access to specific dashboards or sets of data. Microsoft Sentinel offers the ability to assign table-level permissions and limit the level of access to the minimum required to perform requisite job functions.  Role-based Access Control (RBAC) Requirements Microsoft Sentinel offers an extensive list of Azure built-in roles that can be used to provide granular access according to the job requirements and permitted level of access. Some of them are various Microsoft Sentinel dedicated roles: Microsoft Sentinel Contributor- Can perform all engineering-related configuration, such as creating alert rules, configuring data connectors, and additional similar tasks.  Microsoft Sentinel Reader- Can query the log data stor
Read more