SAP HANA Azure Virtual Machine Storage Configurations

By Ashwin Venugopal -

 



SAP HANA Azure VM Storage Configurations

Azure offers different SAP HANA certified Azure Storage types for SAP HANA deployments such as Azure Premium SSD, Ultra Disk, and  Azure NetApp Files while also providing two deployment methods for VHDs on Azure Standard and Premium Storage. The minimum requirement of SAP HANA certified for different storage types are as follows:
  • Azure Premium SSD- /hana/log can be cached with Azure Write Accelerator whereas /hana/data volume can be placed on Premium SSD without Azure Write Accelerator or on Ultra Disk.
  • vAzure Ultra disk at least for the /hana/log volume- It can be palced on either Premium SSD without Azure Write Accelerator or in order to get faster restart times Ultra Disk.
  • NFS v4.1- Volumes on top of Azure NetApp Files for /hana/log and /hana/data.

In an on-premises world you rarely care about I/O subsystems and its capabilities because the appliance vendor has to make sure that the minimum storage requirements are met for SAP HANA which can result in the need to:

  • Enable read/write on /hana/log of a 250 MB/sec with 1 MB I/O sizes.
  • Enable read activity of at least 400 MB/sec for /hana/data with 16 MB and 64 MB I/O sizes,
  • Enable write activity of at least 250 MB/sec for /hana/data with 16 MB and 64 MB I/O sizes. 

If you want to achieve the minimum throughput of  /hana/log and /hana/data as desired by SAP, you should build a RAID 0 using MDADM or LVM over multiple Azure Premium Storage disks while using the RAID volumes as /hana/data and /hana/log volumes.

Note- Configuration of any redundancy level using RAID volumes is not required, as Azure Premium and Standard Storage keeps three images of a VHD while using the RAID volume to purely configure volumes that offers sufficient I/O throughput. 

Solutions with Premium Storage & Azure Write Accelerator for Azure M-series Virtual Machines

A functionality that is exclusively available for Azure M-series VMs is Azure Write Accelerator which is widely used to improve I/O latency of writes against the Azure Premium Storage and it is necessary to use Azure Write Accelerator or /hana/log volume while using Azure Premium Storage. 

All the writes should be persisted on disk in a reliable fashion which results in the setting of the caching for the different volumes using Azure Premium Storage as follows:

  • /hana/data- no caching
  • /hana/log- no caching except for M- and Mv2- series where Write Accelerator should be enabled without read caching.
  • /hana/shared- read caching

For Azure M-series VMs, the SAP HANA certification is exclusively with Azure Write Accelerator for the /hana/log volume resulting in the configuration of production scenario SAP HANA deployments on Azure M-series VMs with Azure Write Accelerator for the /hana/log volume.  

Note- You should check whether a certain type of VM is supported for SAP HANA by SAP in the SAP documentation for IAAS for production scenarios.

If the workload needs higher volumes for /hana/data and /hana/log, then the number of Azure Premium Storage VHDs should be increased but with more VHDs volume sizing than listed also increases the IOPS and I/O through within the limits of the Azure VM type.

The 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  

You can also use Write Accelerator for disks forming the /hana/log volume.






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...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
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...
Read more