SAP HANA planning guide

This guide provides an overview of what is required to run SAP HANA on Google Cloud, and provides details that you can use when planning the implementation of a new SAP HANA system.

For details about how to deploy SAP HANA on Google Cloud, see:

• For single-host scale-up and multi-host scale-out deployments, see:
  • Terraform: SAP HANA scale-up deployment guide
  • Deployment Manager: SAP HANA scale-up deployment guide
• For scale-out system with host auto-failover deployments, see:
  • Terraform: SAP HANA scale-out system with host auto-failover deployment guide
  • Deployment Manager: SAP HANA scale-out system with host auto-failover deployment guide
• For scale-up high-availability cluster configurations, see:
  • Terraform: SAP HANA scale-up high-availability cluster configuration guide
  • Deployment Manager: SAP HANA high-availability cluster configuration guide
  • Manual HA scale-up cluster configuration on RHEL
  • Manual HA scale-up cluster configuration on SLES
• For scale-out high-availability cluster configurations, see:
  • Terraform: SAP HANA scale-out high-availability cluster configuration guide
  • Manual HA scale-out cluster configuration on SLES

About SAP HANA on Google Cloud

SAP HANA is an in-memory, column-oriented, relational database that provides high-performance analytics and real-time data processing. Customers can leverage ease of provisioning, highly scalable, and redundant Google Cloud infrastructure capabilities to run their business critical workloads. Google Cloud provides a set of physical assets, such as computers and hard disk drives, and virtual resources, such as Compute Engine virtual machines (VMs), located in Google data centers around the world.

When you deploy SAP HANA on Google Cloud, you deploy to virtual machines running on Compute Engine. Compute Engine VMs provide persistent disks, which function similarly to physical disks in a desktop or a server, but are automatically managed for you by Compute Engine to ensure data redundancy and optimized performance.

Google Cloud basics

Google Cloud consists of many cloud-based services and products. When running SAP products on Google Cloud, you mainly use the IaaS-based services offered through Compute Engine and Cloud Storage, as well as some platform-wide features, such as tools.

See the Google Cloud platform overview for important concepts and terminology. This guide duplicates some information from the overview for convenience and context.

For an overview of considerations that enterprise-scale organizations should take into account when running on Google Cloud, see the Google Cloud Architecture Framework.

Interacting with Google Cloud

Google Cloud offers three main ways to interact with the platform, and your resources, in the cloud:

• The Google Cloud console, which is a web-based user interface.
• The gcloud command-line tool, which provides a superset of the functionality that Google Cloud console offers.
• Client libraries, which provide APIs for accessing services and management of resources. Client libraries are useful when building your own tools.

Google Cloud services

SAP deployments typically utilize some or all of the following Google Cloud services:

Pricing and quotas

You can use the pricing calculator to estimate your usage costs. For more pricing information, see Compute Engine pricing, Cloud Storage pricing, and Google Cloud Observability pricing.

Google Cloud resources are subject to quotas. If you plan to use high-CPU or high-memory machines, you might need to request additional quota. For more information, see Compute Engine resource quotas.

Compliance and sovereign controls

If you require your SAP workload to run in compliance with data residency, access control, support personnel, or regulatory requirements, then you must plan for using Assured Workloads - a service that helps you run secure and compliant workloads on Google Cloud without compromising the quality of your cloud experience. For more information, see Compliance and sovereign controls for SAP on Google Cloud.

Resource requirements

Certified machine types for SAP HANA

For SAP HANA, SAP certifies only a subset of the machine types that are available from Google Cloud.

The machine types that SAP certifies for SAP HANA includes Compute Engine virtual machines (VMs) and Bare Metal Solution bare-metal machines.

Custom configurations of the general-purpose n1- and n2-highmem VM types are also certified by SAP. For more information, see Certified custom VM types for SAP HANA.

For the operating systems that are certified for use with HANA on each machine type, see Certified operating systems for SAP HANA.

Some machine types are not available in all Google Cloud regions. To check the regional availability of a Compute Engine virtual machine, see Available regions & zones. For Bare Metal Solution machines that are certified for SAP HANA, see Regional availability of Bare Metal Solution machines for SAP HANA.

SAP lists the certified machine types for SAP HANA in the Certified and Supported SAP HANA Hardware Directory.

For more information about different Compute Engine VM types and their use cases, see machine types.

Certified Compute Engine VMs for SAP HANA

The following table shows Compute Engine VMs that are certified by SAP for SAP HANA:

The following table shows all of the Google Cloud machine types that are certified by SAP for production use of SAP HANA.

The table does not include the machine types that SAP certifies for SAP Business One on SAP HANA. For the machine types that SAP certifies for SAP HANA with SAP Business One, see Certified SAP applications on Google Cloud.

Certified Bare Metal Solution machines for SAP HANA

The following table shows Bare Metal Solution machines that are certified by SAP for SAP HANA exclusively in a three-tier architecture.

To see which regions these certified machine types are available in, see Regional availability of Bare Metal Solution machines for SAP HANA.

Certified custom machine types for SAP HANA

The following table shows the Compute Engine custom machine types that are certified by SAP for production use of SAP HANA on Google Cloud.

SAP certifies only a subset of the custom machine types that are available from Compute Engine.

Custom machine types are subject to customization rules that are defined by Compute Engine. The rules differ depending on which machine type you are customizing. For complete customization rules, see Creating a custom VM instance.

Regional availability of Bare Metal Solution machines for SAP HANA

The following table shows the current Google Cloud regions that support SAP HANA on Bare Metal Solution.

If you do not see the region that you need in the preceding table, contact Google Cloud Sales.

Memory configuration

Your memory configuration options are determined by Compute Engine VM instance type you choose. For more information, see the Certified machine types for SAP HANA table.

Network configuration

Your Compute Engine VM network capabilities are determined by its machine family, and not by its network interface (NIC) or IP address.

Based on its machine type, your VM instance is capable of 2-32 Gbps network throughput. Certain machine types also support throughputs up to 100 Gbps, which requires the use of the Google Virtual NIC (gVNIC) interface type with a Tier_1 network configuration. The ability to achieve these throughput rates is further dependent on the traffic direction and the type of the destination IP address.

Compute Engine VM network interfaces are backed by redundant and resilient network infrastructure using physical and software-defined network components. These interfaces inherit the redundancy and resiliency of the underlying platform. Multiple virtual NICs can be used for traffic separation, but that offers no additional resilience or performance benefits.

A single NIC provides the needed performance for SAP HANA deployments on Compute Engine. Your particular use case, security requirements or preferences might also require additional interfaces for separating traffic, such as Internet traffic, internal SAP HANA System Replication traffic, or other flows that might benefit from specific network policy rules. We recommend that you employ traffic encryption offered by the application, and secure network access following a least privilege firewall policy to restrict access.

Depending on your requirements, you can improve security on multiple ways as described in the SAP HANA Security Guide for SAP HANA Platform. For example, you can implement network isolation but it provides lower security without encryption and port and IP specific allowlistiing.

Consider the need for traffic separation early on as part of your network design and allocate additional NICs when you deploy VMs. You must attach each network interface to a different Virtual Private Cloud network. Your choice for the number of network interfaces depends on the level of isolation that you require, with up to 8 interfaces allowed for VMs with 8 vCPUs or more.

For example, you might define a Virtual Private Cloud network for your SAP HANA SQL application clients (SAP NetWeaver application servers, custom applications, etc.), and a separate network for inter-server traffic, such as SAP HANA System Replication. Consider that too many segments might complicate management and troubleshooting of network issues. If you change your mind later, then you can use Compute Engine machine images to recreate your VM instance while retaining all associated configuration, metadata and data.

For more information, see networking overview for VMs, multiple network interfaces and VM network bandwidth.

Certified operating systems for SAP HANA

The following table shows the Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) operating systems that are certified by SAP for production use with SAP HANA on Google Cloud.

Except where noted in the table, each operating system is supported with SAP HANA on all certified Compute Engine VM types.

For information about the current support status of each operating system and which operating systems are available from Google Cloud, see Operating system support for SAP HANA on Google Cloud.

For information from SAP about which operating systems SAP supports with SAP HANA on Google Cloud, go to Certified and Supported SAP HANA Hardware Directory, click on the required machine type, and then see Operating System.

The following table does not include:

• Certified operating system versions that are no longer in mainstream support.
• Operating system versions that are not specific to SAP.

Custom operating system images

You can use a Linux image that Google Cloud provides and maintains (a public image) or you can provide and maintain your own Linux image (a custom image).

Use a custom image if the version of the SAP-certified operating system that you require is not available from Google Cloud as a public image. The following steps, which are described in detail in Importing Boot Disk Images to Compute Engine, summarize the procedure for using a custom image:

1. Prepare your boot disk so it can boot within the Google Cloud Compute Engine environment and so you can access it after it boots.
2. Create and compress the boot disk image file.
3. Upload the image file to Cloud Storage and import the image to Compute Engine as a new custom image.
4. Use the imported image to create a virtual machine instance and make sure it boots properly.
5. Optimize the image and install the Linux Guest Environment so that your imported operating system image can communicate with the metadata server and use additional Compute Engine features.

After your custom image is ready, you can use it when creating VMs for your SAP HANA system.

If you are moving a RHEL operating system from an on-premises installation to Google Cloud, you need to add Red Hat Cloud Access to your Red Hat subscription. For more information, see Red Hat Cloud Access.

For more information about the operating system images that Google Cloud provides, see Images.

For more information about importing an operating system into Google Cloud as a custom image, see Importing Boot Disk Images to Compute Engine.

For more information about the operating systems that SAP HANA supports, see:

• Certified and Supported SAP HANA Hardware Directory
• SAP Note 2235581 - SAP HANA: Supported Operating Systems

OS clocksource on Compute Engine VMs

The default OS clocksource is kvm-clock for SLES and TSC for RHEL images.

Changing the OS clocksource is not necessary when SAP HANA is running on a Compute Engine VM. There is no difference in performance when using kvm-clock or TSC as the clocksource for Compute Engine VMs with SAP HANA.

If you need to change the OS clocksource to TSC, then connect to your VM using SSH and issue the following commands:

echo "tsc" | sudo tee /sys/devices/system/clocksource/*/current_clocksource
sudo cp /etc/default/grub /etc/default/grub.backup
sudo sed -i '/GRUB_CMDLINE_LINUX/ s|"| clocksource=tsc"|2' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Persistent disk storage

Supported disk types

Compute Engine offers different Persistent Disk and Hyperdisk types based on either solid-state drive (SSD) technology or standard hard disk drive (HDD) technology. Each type has different performance characteristics. Google Cloud manages the underlying hardware of the disks to ensure data redundancy and to optimize performance.

For performance reasons, the SAP HANA /hana/data and /hana/log volumes require SSD-based persistent storage disks. SSD-based Persistent Disk and Hyperdisk types that are certified by SAP for use with SAP HANA include the following:

• SSD-based Persistent Disk types: Balanced (pd-balanced), Performance or SSD (pd-ssd), and Extreme (pd-extreme)

  • These disk types provide cost-effective and reliable block storage.
  • Performance (SSD) Persistent Disk (pd-ssd) provides higher performance than Balanced Persistent Disk (pd-balanced).
  • Use Balanced Persistent Disk as the recommended disk for hosting the following for VM instances:
    • VM boot volume.
    • The /usr/sap volume.
    • The /hana/shared volume, if you're hosting it on its own disk.
    • The /hanabackup volume, if you save your backups to a disk. If you want to reduce the backup costs, then you can use a Standard HDD Persistent Disk (pd-standard). Balanced Persistent Disk provides faster backups than Standard HDD Persistent Disk. While selecting the disk, make sure that your VM type supports the disk type.
  • Balanced and Performance (SSD) Persistent Disk support PD Async Replication. You can use this feature for cross-region active-passive disaster recovery. For more information, see Disaster recovery using PD Async Replication.
  • While Extreme Persistent Disk (pd-extreme) is certified for use with SAP HANA, we recommend that you instead use Hyperdisk Extreme (hyperdisk-extreme), which provides greater performance. If you want to use Extreme Persistent Disk, then make sure to provision the disks in accordance with the information in Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.

• Hyperdisk types: Hyperdisk Extreme (hyperdisk-extreme) and Hyperdisk Balanced (hyperdisk-balanced)

  • Hyperdisk Extreme provides higher maximum IOPS and throughput options than SSD-based Persistent Disk types.
  • For a list of the machine types that support Hyperdisk Extreme and Hyperdisk Balanced, see Machine type support.
  • Use Hyperdisk Balanced as the recommended disk for hosting the following for Compute Engine bare metal instances such as X4:
    • The boot disk.
    • The /usr/sap volume.
    • The /hana/shared volume, if you're hosting it on its own disk.
    • The /hanabackup volume, if you save your backups to a disk.
  • For Hyperdisk Extreme, you select the performance you need by provisioning IOPS, which also determines your throughput. For more information, see Throughput.
  • For Hyperdisk Balanced, you select the performance you need by provisioning IOPS and throughput. For more information, see About IOPS and throughput provisioning for Hyperdisk.
  • You can use Hyperdisk Extreme for the /hana/data and /hana/log volumes when you require the highest performance.
  • To enable the best performance from Hyperdisk Extreme for SAP HANA, update your SAP HANA system properties as recommended in Hyperdisk Extreme performance.

Supported disk layouts

The following figure shows the disk storage layout in suggested architectures for SAP HANA on Google Cloud.

In the preceding figure, the configuration on the left uses a split-disk layout. The /hana/data and /hana/log volumes are on separate Hyperdisks. The /hana/data volume can be hosted on more than one disk. The /hana/shared and /usr/sap volumes, which don't require as high a performance, are on individual balanced persistent disks, which cost less than a Hyperdisk Extreme.

The configuration on the right uses a unified-disk layout, where the /hana/data, /hana/log, /hana/shared, and /usr/sap volumes are all mounted on a single Hyperdisk Extreme.

Persistent disks and Hyperdisks are located independently from your VMs, so you can detach or move these disks to keep your data, even after you delete your VMs.

In the Google Cloud console, you can see the persistent disks and Hyperdisks that are attached to your VM instances under Additional disks on the VM instance details page for each VM instance. For more information about the different types of Compute Engine Persistent Disk and Hyperdisk volumes, their performance characteristics, and how to work with them, see the following documentation:

• Storage options
• About Hyperdisk
• Block storage performance
• Other factors that affect performance
• Add a Persistent Disk to your VM
• Create and manage disk snapshots
• Migrate SAP HANA Persistent Disk volumes to Hyperdisk volumes

Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes

When you size certain Compute Engine SSD-based persistent disks for SAP HANA, you need to account for not only the storage requirements of your SAP HANA instance, but also for the performance of the persistent disk.

Within limits, the performance of an SSD or balanced persistent disk increases as the size of the disk and the number of vCPUs increase. If an SSD or balanced persistent disk is too small, then it might not provide the performance that SAP HANA requires.

The performance of Hyperdisk is not affected by disk size. Its performance is determined by the IOPS or throughput that you provision. For information about the performance of Hyperdisk, see About Hyperdisk.

A 550 GB SSD or a 943 GB balanced persistent disk provides a sustained throughput of 400 MB per second for reads and writes, which is the minimum. For general information about persistent disk performance, see Block storage performance.

The following table shows the minimum recommended sizes for SSD persistent disk (pd-ssd), balanced persistent disk (pd-balanced), Hyperdisk Extreme (hyperdisk-extreme), and Hyperdisk Balanced (hyperdisk-balanced) to meet SAP HANA performance requirements in a production environment for each Compute Engine machine type that is certified for SAP HANA. The minimum sizes for Hyperdisk volumes, which are based solely on the amount of memory, are included in the table for reference.

For information about the recommended storage configuration for SAP HANA systems running on X4 instances, see Supported block storage for X4.

The sizes in the following table assume that you are mounting all the SAP HANA volumes on individual disks.

Determining persistent disk or Hyperdisk size

Calculate the amount of persistent disk storage that you need for the SAP HANA volumes based on the amount of memory that your selected Compute Engine machine type contains.

The following guidance about disk sizes refers to the minimum sizes that Google Cloud recommends for your deployments. This guidance, while exceeding SAP's minimum requirements, is designed to balance the storage requirements of your SAP HANA system, the performance requirements of the disks, and the total cost of ownership. You can increase the disk sizes up to the limit that the underlying disk types support. For information about the required minimum disk sizes, see Minimum sizes for SSD-based persistent disks.

Persistent disk size requirements for scale-up systems

For SAP HANA scale-up systems, use the following formulas for each volume:

• /hana/data: 1.2 x memory
• /hana/log: either 0.5 x memory or 512 GB, whichever is smaller
• /hana/shared: either 1 x memory or 1,024 GB, whichever is smaller
• /usr/sap: 32 GB
• /hanabackup: 2 x memory, optional allocation

Persistent disk size requirements for scale-out systems

For SAP HANA scale-out systems, use the same formula as SAP HANA scale-up systems for /hana/data, /hana/log, and /usr/sap volumes. For /hana/shared volume, calculate the persistent disk or Hyperdisk size based on the number of worker hosts in your deployment. For each four worker hosts, increase the disk size by 1 x memory, or 1 TB, whichever is smaller. For example:

• From 1 to 4 worker hosts: 1 x memory, or 1 TB, whichever is smaller
• From 5 to 8 worker hosts: 2 x memory, or 2 TB, whichever is smaller
• From 9 to 12 worker hosts: 3 x memory, or 3 TB, whichever is smaller
• From 13 to 16 worker hosts: 4 x memory, or 4 TB, whichever is smaller

To determine your overall storage quota requirements for SAP HANA scale-out systems, you need to total up the disk sizes for each type of disk that is used with all of the hosts in the scale-out system. For example, if you have put /hana/data and /hana/log on pd-ssd persistent disks, but /hana/shared and /usr/sap on pd-balanced persistent disks, then you need separate totals for pd-ssd and pd-balanced to request separate quotas.

For an SAP HANA scale-out system with host auto-failover, you only need to calculate the persistent disk size for master and worker hosts. The standby hosts do not have their own /hana/data, /hana/log, and /usr/sap volumes. If there is a failure, then SAP HANA automatic failover unmounts the /hana/data, /hana/log, and /usr/sap volumes from the failed host and mounts on them on a standby host. The /hana/shared and /hanabackup volumes for a standby host are mounted on a separately-deployed NFS solution.

Allocating additional persistent disk storage

Select a persistent disk or Hyperdisk size that is no smaller than the minimum size that is listed for your persistent disk or Hyperdisk type in Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.

If you are using SSD or balanced persistent disks, then the minimum size might be determined by SAP HANA performance requirements rather than SAP HANA storage requirements.

For example, if you are running SAP HANA on an n2-highmem-32 VM instance, which has 256 GB of memory, your total storage requirement for the SAP HANA volumes is 723 GB: 307 GB for the data volume, 128 GB for the log volume, 256 GB for the shared volume, and 32 GB for the /usr/sap volume. However, if you use a balanced persistent disk, then the required minimum size is 943 GB, where the additional 220 GB is allocated to the data volume to meet the required performance. Therefore, if you use a n2-highmem-32 VM instance with balanced persistent disks to run SAP HANA, then you need to provision a persistent disk storage of 943 GB or more.

so you need to size your persistent disk at 943 GB or more. The additional provision of 220 GB is applied to the data volume to provide the required performance.

Apply any additional persistent disk storage to the /hana/data volume.

For information from SAP about sizing for SAP HANA, see Sizing SAP HANA.

Hyperdisk performance

Hyperdisk provides higher maximum IOPS and throughput options for the /hana/log and /hana/data volumes than the other SSD-based persistent disks. For more information about provisioning IOPS and throughput options for Hyperdisk, see About IOPS and throughput provisioning for Hyperdisk.

Unlike with SSD-based persistent disks, when you use Hyperdisk with SAP HANA, you don't need to worry about performance when you size the Hyperdisk. The sizing for Hyperdisk is based solely on the storage requirements of SAP HANA. For more information about sizing persistent disks or Hyperdisk, see Determining persistent disk size.

While using Hyperdisk with SAP HANA, to enable the best performance, we recommend that you update your SAP HANA system properties as follows:

• Update your global.ini file:
  • In the fileio section, set num_completion_queues = 12
  • In the fileio section, set num_submit_queues = 12
• Update your indexserver.ini file:
  • In the parallel section, set tables_preloaded_in_parallel = 32
  • In the global section, set load_table_numa_aware = true

When you create a Hyperdisk Extreme volume, the number of IOPS that you provision determines its maximum throughput. The following formula can be used as a starting point. It provides a minimum of 2500 MBps throughput (256 KB per IOPS * 10,000 IOPS) and more for larger machine types with larger disks.

• When using the default deployment with separate disks for /hana/log and /hana/data:
  • IOPS for the data disk: maximum(10,000, size of data disk in GB * 2)
  • IOPS for the log disk: maximum(10,000, size of log disk in GB * 2)
• When a single disk is used for /hana/data, /hana/log, /hana/shared, and /usr/sap:
  • IOPS for disk: maximum(10,000, size of data disk GB * 2) + maximum(10,000, size of log disk in GB * 2)

The maximum number of IOPS that you can provision can differ depending on the machine type you are using. For a list of the machine types that support Hyperdisk Extreme, as well as the maximum IOPS and throughput that Hyperdisk Extreme can provide with each machine type, see Machine type support.

When you create a Hyperdisk Balanced volume, you can provision the IOPS and throughput to meet your workload performance needs, taking into consideration the rules for IOPS provisioning and throughput provisioning. For SAP HANA, the minimum supported provisioned IOPS is 3000 and throughput is 400 MBps.

Persistent disks and Hyperdisks deployed by the deployment automation scripts

When you deploy an SAP HANA system using the Terraform configurations that Google Cloud provides, the deployment script allocates persistent disks or Hyperdisks for the SAP volumes as follows:

• By default, separate disks are deployed for each of the following directories: /hana/data, /hana/log, /hana/shared, and /usr/sap.

  Optionally, you can choose to deploy a single-disk layout where a single persistent disk or Hyperdisk hosts these SAP directories. Also, for SAP HANA scale-out deployments, the /hana/shared directory is hosted by an NFS solution.

• Optionally, a disk for the /hanabackup directory.

The following example shows how Terraform maps the volumes for SAP HANA on a Compute Engine n2-highmem-32 VM, which has 256 GB of memory.

hana-ssd-example:~ # lvs
  LV     VG             Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data   vg_hana_data   -wi-ao---- 308.00g
  log    vg_hana_log    -wi-ao---- 128.00g
  shared vg_hana_shared -wi-ao---- 256.00g
  usrsap vg_hana_usrsap -wi-ao----  32.00g
  backup vg_hanabackup  -wi-ao---- 512.00g

The sizes of your volumes for the same machine type might differ slightly from what is shown in this example.

When you use the Deployment Manager templates that Google Cloud provides for SAP HANA, or when you opt to deploy a single-disk layout using the Terraform configurations, the deployment script maps the SAP HANA /hana/data, /hana/log, /usr/sap, and /hana/shared directories each to its own logical volume for easy resizing and maps them to the SSD-based persistent disk or Hyperdisk in a single volume group. Terraform or Deployment Manager maps the /hanabackup directory to a logical volume in a separate volume group, which it then maps to a balanced persistent disk (pd-balanced).

Optional persistent disk storage for backups

When storing SAP HANA backups on a disk, we recommend that you use a Balanced Persistent Disk (pd-balanced).

If you want to reduce costs, you can use a Standard HDD Persistent Disk (pd-standard). However, use a balanced persistent disk when a higher throughput or concurrency is needed.

The SAP HANA backup volume size is designed to provide optimal baseline and burst throughput as well as the ability to hold several backup sets. Holding multiple backup sets in the backup volume makes it easier to recover your database if necessary.

To make the SAP HANA backups available as a regional resource for disaster recovery, you can use Compute Engine persistent disk snapshots. You can schedule snapshots to regularly and automatically back up your persistent disk. For more information, see Persistent disk snapshots.

If you use SAP HANA dynamic tiering, then the backup storage must be large enough to hold both the in-memory data and the data that is managed on disk by the dynamic tiering server.

You can use other mechanisms for storing SAP HANA backups. If you use the Backint feature of Google Cloud's Agent for SAP, then you can backup SAP HANA directly to a Cloud Storage bucket, which makes the use of a persistent disk for storing backups optional.

SAP HANA dynamic tiering

SAP HANA dynamic tiering is certified by SAP for use in production environments on Google Cloud. SAP HANA dynamic tiering extends SAP HANA data storage by storing data that is infrequently accessed on disk instead of in memory.

For more information, see SAP HANA Dynamic Tiering on Google Cloud.

SAP HANA Fast Restart option

For SAP HANA 2.0 SP04 and later, Google Cloud strongly recommends the SAP HANA Fast Restart option.

This option is automatically enabled if you deploy SAP HANA using Google Cloud's Terraform module sap_hana or sap_hana_ha, version 202309280828 or later. For information about how to manually enable SAP HANA Fast Restart, see Enabling SAP HANA Fast Restart.

SAP HANA Fast Restart reduces restart time in the event that SAP HANA terminates, but the operating system remains running. To reduce the restart time, SAP HANA leverages the SAP HANA persistent memory functionality to preserve MAIN data fragments of column store tables in DRAM that is mapped to the tmpfs file system.

Additionally, on VMs in the M2 and M3 families of Compute Engine memory-optimized machine types, SAP HANA Fast Restart improves recovery time if uncorrectable errors occur in memory. For more information, see Memory-error recovery with Fast Restart on Compute Engine VMs.

Required OS settings for SAP HANA Fast Restart

To use SAP HANA Fast Restart, your operating system must be tuned as required by SAP.

If you use the Terraform configuration files or Deployment Manager templates that Google Cloud provides, then the kernel settings are set for you.

If you don't use the deployment files that Google Cloud provides, SAP provides guidance for configuring both the RHEL and SLES operating systems for SAP HANA. For SAP HANA Fast Restart, pay particular attention to setting numa_balancing and transparent_hugepage correctly.

If you use RHEL, use the sap-hana tuned profile, if it is available. For the configuration steps, see:

• SAP note 2292690 - SAP HANA DB: Recommended OS settings for RHEL 7
• SAP note 2777782 - SAP HANA DB: Recommended OS Settings for RHEL 8
• SAP note 3108302 - SAP HANA DB: Recommended OS Settings for RHEL 9

If you use SLES, use the saptune tool from SUSE to apply the required configuration. To apply all of the recommended SAP HANA settings, including both of the preceding kernel parameters, specify the following saptune command:

saptune solution apply HANA

For more information about configuring SLES for SAP HANA, see:

• SAP note 2205917 - SAP HANA DB: Recommended OS settings for SLES 12 / SLES for SAP Applications 12
• SAP note 2684254 - SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15

Memory-error recovery with Fast Restart on Compute Engine VMs

Enabling SAP HANA Fast Restart on VMs in the M2 and M3 families of Compute Engine memory-optimized machine types reduces the time it takes SAP HANA to recover from uncorrectable memory errors.

By leveraging Intel processor capabilities, the M2 and M3 machine types can keep running when uncorrectable errors occur in the memory subsystem. If SAP HANA Fast Restart is enabled when the memory error occurs, the affected SAP HANA process restarts, but the whole database doesn't need to be reloaded, only the affected file block.

Machine types that support memory-error recovery

The following Compute Engine machine types support memory-error recovery:

• m3-ultramem-32
• m3-ultramem-64
• m3-ultramem-128
• m3-megamem-64
• m3-megamem-128
• m2-ultramem-208
• m2-ultramem-416
• m2-megamem-416
• m2-hypermem-416

Required operating systems for memory-error recovery

With the required kernel patches, the following operating systems support memory-error recovery with SAP HANA Fast Restart:

• SUSE Linux Enterprise Server (SLES) for SAP, 12 SP3 or later.
  • Included in Compute Engine public images with a build date of v202103* or later.
  • If you need to apply the latest kernel patches to an existing deployment, follow your standard update process. For example, issue the following commands:
    • sudo zypper refresh
    • sudo zypper update
• Red Hat Enterprise Linux (RHEL) for SAP, 8.4 or later.

File server options

The file server options for SAP HANA on Google Cloud include Filestore and NetApp Cloud Volumes Service for Google Cloud.

For more information about all of the file server options for SAP on Google Cloud, see File sharing solutions for SAP on Google Cloud.

Filestore

For the /hana/shared volume in a single zone scale-out configuration, we suggest using the Filestore Basic service tier as it is desgined for zonal resources. For scenarios where additional resilience is required, you can use Filestore Enterprise. For more information, see Components in an SAP HANA scale-out system on Google Cloud.

NetApp Cloud Volumes Service for Google Cloud

NetApp Cloud Volumes Service for Google Cloud is a fully-managed, cloud-native data service platform that you can use to create an NFS file system for SAP HANA scale-up systems on all Compute Engine instance types that are certified for SAP HANA. For information about using NetApp Cloud Volumes Service for Google Cloud with your SAP HANA deployment, see About NetApp Cloud Volumes Service for Google Cloud.

User identification and resource access

When planning security for an SAP deployment on Google Cloud, you must identify:

• The user accounts and applications that need access to the Google Cloud resources in your Google Cloud project
• The specific Google Cloud resources in your project that each user needs to access

You must add each user to your project by adding their Google account ID to the project as a principal. For an application program that uses Google Cloud resources, you create a service account, which provides a user identity for the program within your project.

Compute Engine VMs have their own service account. Any programs that that run on a VM can use the VM service account, as long as the VM service account has the resource permissions that the program needs.

After you identify the Google Cloud resources that each user needs to use, you grant each user permission to use each resource by assigning resource-specific roles to the user. Review the predefined roles that IAM provides for each resource, and assign roles to each user that provide just enough permissions to complete the user's tasks or functions and no more.

If you need more granular or restrictive control over permissions than the predefined IAM roles provide, you can create custom roles.

For more information about the IAM roles that SAP programs need on Google Cloud, see Identity and access management for SAP programs on Google Cloud.

For an overview of identity and access management for SAP on Google Cloud, see Identity and access management overview for SAP on Google Cloud.

Bare metal machine types for SAP HANA

This section provides information about running SAP HANA on the bare metal machine types provided by Compute Engine, which include the following:

• C3 bare metal machine types: The C3 series of general-purpose machines includes bare metal machine types.

  • For information about the C3 bare metal machine types that SAP has certified for use with SAP HANA, see C3 general-purpose bare metal machine types.
  • For information about the operating system versions that you can use with the C3 bare metal machine types to run SAP HANA workloads, see Certified operating systems for SAP HANA.
  • For information about the minimum block storage that you need to run SAP HANA on the C3 bare metal machine types, see Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.
  • For more information about the C3 machine series, see C3 machine series.

• X4: The fourth generation of memory-optimized machine types offered by Compute Engine. These machines are designed to primarily support SAP workloads that require up to 32 TB of memory.

  • For information about the X4 machine types that SAP has certified for use with SAP HANA, see X4 memory-optimized bare metal machine types.
  • For information about the operating system versions that you can use with the X4 machine types to run SAP HANA workloads, see Certified operating systems for SAP HANA.
  • For information about supported block storage for running SAP HANA on X4 machine types, see Supported block storage for X4.
  • For more information about the X4 machine series, see X4 machine series.

Supported block storage for X4

To provide block storage for running SAP HANA workloads on X4 machines, you can use Hyperdisk Extreme or Hyperdisk Balanced volumes.

For information about storage configurations recommended by Google Cloud for X4 instances, see the following sections:

• Cost-optimized configuration
• Performance-tuned configuration
• Flexible performance configuration

Cost-optimized configuration

The following table shows a cost-optimized storage configuration for running SAP HANA on X4 machine types. The sizes in the following table assume that you are mounting all the SAP HANA volumes on individual disks.

Performance-tuned configuration

The following table shows a performance-tuned storage configuration for running SAP HANA on X4 machine types. The sizes in the following table assume that you are mounting all the SAP HANA volumes on individual disks.

Flexible performance configuration

The following table shows a storage configuration that offers a flexible performance for running SAP HANA on X4 machine types. The sizes in the following table assume that you are mounting all the SAP HANA volumes on individual disks.

Deployment automation

To run SAP HANA, you can deploy the bare metal instances using the Terraform configurations provided by Google Cloud. These configurations are designed to perform the following by default:

• Deploy Hyperdisk Extreme volumes to host the SAP HANA data and log volumes. To deploy Hyperdisk Balanced volumes instead, use the disk_type Terraform argument.
• Enable the SAP HANA Fast Restart option.
• If you're hosting the SAP HANA backup volume on a disk, then these Terraform configurations deploy a Hyperdisk Balanced volume for it by default. This disk deployment is determined by the backup_disk_type Terraform argument.

For information about the Terraform configurations that Google Cloud provides for deploying SAP HANA, see Supported SAP solutions.

Post-deployment tasks

After you deploy a bare metal instance to run SAP HANA, we recommend that you do the following:

• Make sure that version 3.6 (latest) of Google Cloud's Agent for SAP is installed. For information about how to install the agent, see Install and configure Google Cloud's Agent for SAP on a Compute Engine VM instance. For information about how to update to the latest version, see Update Google Cloud's Agent for SAP.
• On X4 instances, optimize the OS configuration to best support SAP HANA workloads. You can do this by using Google Cloud's Agent for SAP. For more information, see Configure guest OS on bare metal instances.
• Evaluate your SAP workload using Workload Manager - a rule-based validation service that lets you scan your workloads and detect deviations from standards, rules, and best practices prescribed by SAP, Google Cloud, and OS vendors. For information about how to evaluate your SAP workload, see Create and run an evaluation. For information about the supported evaluations for SAP workloads, see Workload Manager best practices for SAP.

Hyperthreading

Hyperthreading is enabled by default and is the recommended setting for all Compute Engine machine types.

For the optimal performance of SAP HANA on compute instances with over 1,000 vCPUs, we strongly recommend that you use SAP HANA 2.0 SPS7 revision 76 or later.

If you're running an older version of SAP HANA with an OLTP workload on compute instances with over 1,000 vCPUs, then turning off hyperthreading might have a marginal performance benefit. We recommend testing this during load testing. For information about how to disable hyperthreading for your X4 instance by using Google Cloud's Agent for SAP, see Disable hyperthreading for an X4 instance.

Pricing and quota considerations for SAP HANA

You are responsible for the costs incurred for using the resources created by following this deployment guide. Use the pricing calculator to help estimate your actual costs.

Quotas

SAP HANA requires more CPU and memory than many workloads on Google Cloud. If you have a new Google Cloud account, or if you haven't asked for an increased quota, then you would need to do so to deploy SAP HANA.

The following table shows quota values for single-host, scale-up SAP HANA systems by VM instance type.

For a scale-out SAP HANA system or multiple scale-up systems, you need to include the total resource amounts for all systems. For guidance on determining the storage requirements for scale-out systems, see Determining persistent disk size.

View your existing quota, and compare with your resource (CPU, memory, and storage) requirements to see what increase to ask for. You can then request a quota-limit increase.

While extreme persistent disk (pd-extreme) is still certified for use with SAP HANA, we recommend that you use Hyperdisk Extreme instead, which provides greater performance. If you want to use extreme persistent disks, then you must provision them using the Hyperdisk Extreme sizes.

Licensing

Running SAP HANA on Google Cloud requires you to bring your own license (BYOL).

For more information from SAP about managing your SAP HANA licenses, see License Keys for the SAP HANA Database.

Deployment architectures

On Google Cloud, you can deploy SAP HANA in scale-up and scale-out architectures.

Scale-up architecture

The following diagram shows the scale-up architecture. In the diagram, notice both the deployment on Google Cloud and the disk layout. You can use Cloud Storage to back up your local backups available in /hanabackup. This mount must be sized equal to or greater than the data mount.

On Google Cloud, an SAP HANA single-host, scale-up architecture can include the following components:

• One Compute Engine instance for the SAP HANA database with a network bandwidth of up to 32 Gbps, or up to 100 Gbps on selected machine types using high-bandwidth networking. For information about the machine types that are certified for use with SAP HANA, see Certified machine types for SAP HANA.

• SSD based Compute Engine Persistent Disk or Hyperdisk volumes, as follows:

  • One disk for each of the following directories: /hana/data, /hana/log /hana/shared, and /usr/sap. For information about disk recommendations for SAP HANA, see Persistent disk storage. For SAP optimum performance, the Persistent Disk or Hyperdisk volumes must be sized according to the table in Minimum sizes for SSD-based Persistent Disk and Hyperdisk volumes.

  • One Balanced Persistent Disk for the boot disk.

  • Optionally, a disk for the backup of the SAP HANA database.

• Compute Engine firewall rules restricting access to instances.

• Google Cloud's Agent for SAP. From version 2.0, you can configure this agent to collect the SAP HANA monitoring metrics, which lets you monitor your SAP HANA instances. From version 3.0, you can also use its Backint feature to store SAP HANA backups directly in Cloud Storage bucket, and retrieve as required.

• An optional, but recommended, subnetwork with a custom topology and IP ranges in the Google Cloud region of your choice. The SAP HANA database and the other Compute Engine instances are launched within this subnetwork. You can use an existing subnetwork for SAP HANA.

• Optional components:

  • SAP HANA Cockpit or SAP HANA Studio on a small Compute Engine VM.

If you provision your SAP HANA system without a public IP, then it cannot connect directly to resources through the public internet. Therefore, you need to provide an indirect method for internet access using the following options:

• Configure Google private access so that your VM can access the Google Cloud APIs.

• Use Cloud NAT or configure a VM as a NAT gateway to access the public internet.

• For administrative purposes, you can use TCP forwarding to connect to the systems. For information about using Identity-Aware Proxy for TCP forwarding, see Using IAP for TCP forwarding.

• Use Compute Engine VM that is configured as a bastion host to access the public internet.

Scale-out architectures

The scale-out architecture consists of one master host, a number of worker hosts, and, optionally, one or more standby hosts. The hosts are interconnected through a network that supports sending data between hosts at rates of up to 32 Gbps, or up to 100 Gbps on selected machine types using high-bandwidth networking.

As the workload demand increases, especially when using Online Analytical Processing (OLAP), a multi-host scale-out architecture can distribute the load across all hosts.

The following diagram shows a scale-out architecture for SAP HANA on Google Cloud:

Standby hosts support the SAP HANA host auto-failover fault recovery solution. For more information about host auto-failover on Google Cloud, see SAP HANA host auto-failover on Google Cloud.

The following diagram shows a scale-out architecture with host auto-failover on Google Cloud.

Disk structures for SAP HANA scale-out systems on Google Cloud

Except for standby hosts, each host has its own /hana/data, /hana/log, and, usually, /usr/sap volumes on SSD-based persistent disks or Hyperdisks, which provide consistent, high IOPS, and IO services. The master host also serves as an NFS master for the /hana/shared and /hanabackup volumes, and this NFS master is mounted on each worker and standby host.

For a standby host, the /hana/data and /hana/log volumes are not mounted until a takeover occurs.

Components in an SAP HANA scale-out system on Google Cloud

A multi-host SAP HANA scale-out architecture on Google Cloud contains the following components:

• 1 Compute Engine VM instance for each SAP HANA host in the system, including 1 master host, up to 15 worker hosts, and up to 3 optional standby hosts.

  Each VM uses the same Compute Engine machine type. For information about the machine types that are certified for use with SAP HANA, see Certified machine types for SAP HANA.

• SSD based Persistent Disk or Hyperdisk volumes, as follows:

  • Each VM must include a disk, mounted in the correct location.
  • Optionally, if you are not deploying an SAP HANA host auto-failover system, then a disk for the /hanabackup local volume for each VM instance.

• A separately deployed NFS solution for sharing the /hana/shared and the /hanabackup volumes with the worker and standby hosts. You can use Filestore or another NFS solution.

• Compute Engine firewall rules or other network access controls that restrict access to your Compute Engine instances while allowing communication between the instances and any other distributed or remote resources that your SAP HANA system requires.

• Google Cloud's Agent for SAP. From version 2.0, you can configure this agent to collect the SAP HANA monitoring metrics, which lets you monitor your SAP HANA instances. From version 3.0, you can also use its Backint feature to store SAP HANA backups directly in Cloud Storage bucket, and retrieve as required.

• An optional, but recommended, subnetwork with a custom topology and IP ranges in the Google Cloud region of your choice. The SAP HANA database and the other Compute Engine instances are launched within this subnetwork. You can use an existing subnetwork if you prefer.

• Optional components:

  • SAP HANA Cockpit or SAP HANA Studio on a small Compute Engine VM.

If you provision your SAP HANA system without a public IP, then it cannot connect directly to resources through the public internet. Therefore, you need to provide an indirect method for internet access using the following options:

• Configure Google private access so that your VM can access the Google Cloud APIs.

• Use Cloud NAT or configure a VM as a NAT gateway to access the public internet.

• For administrative purposes, you can use TCP forwarding to connect to the systems. For information about using Identity-Aware Proxy for TCP forwarding, see Using IAP for TCP forwarding.

• Use Compute Engine VM that is configured as a bastion host to access the public internet.

High availability for SAP HANA systems on Google Cloud

To design a high-availability configuration for SAP HANA on Google Cloud, you can use a combination of Google Cloud, SAP, and OS-native features.

For information about the high-availability options, see SAP HANA high-availability planning guide.

Automation for SAP HANA deployments

Google Cloud provides Terraform configuration files and Deployment Manager templates that you can use to automate the deployment of Google Cloud infrastructure and, optionally, SAP HANA.

The deployment automation options that Google Cloud provides support the following SAP HANA deployment scenarios:

• Scale up
• Scale up in a two-node high-availability cluster
• Scale out without standby nodes
• Scale out without standby nodes in a high-availability cluster
• Scale out with SAP HANA Host auto-failover standby nodes

For more information about the automation for the scale-up or scale-out deployment scenarios, see:

• Deployment automation for scale-up systems
• Deployment automation for scale-out systems

Automating the deployment of the SAP HANA instance

Optionally, you can include the installation of SAP HANA with the automated deployment of the Google Cloud infrastructure.

The installation scripts that Google Cloud provides install SAP HANA after the infrastructure is deployed.

If any problems prevent the installation of an SAP HANA instance, the infrastructure is usually still deployed and configured. You can then either use the deployed infrastructure and install SAP HANA manually or delete the infrastructure, correct the problem, and rerun the deployment automation until the SAP HANA instance is installed successfully.

When you use the installation scripts that Google Cloud to install SAP HANA, you must provide values for certain parameters. If you omit these parameters or don't specify valid values for all of them, then the installation script fails to install the SAP HANA instance on the deployed infrastructure.

• When you use the Terraform configuration files that Google Cloud provides to install SAP HANA, you must provide valid values for the following arguments: sap_hana_deployment_bucket, sap_hana_sid, sap_hana_sidadm_uid, sap_hana_sidadm_password, and sap_hana_system_password. For more information about the Terraform arguments, see Terraform: SAP HANA scale-up deployment guide.

• When you use the Deployment Manager templates that Google Cloud provides to install SAP HANA, you must provide valid values for the following configuration parameters: sap_hana_deployment_bucket, sap_hana_sid, sap_hana_instance_number, sap_hana_sidadm_password, sap_hana_system_password, and sap_hana_scaleout_nodes. For more information about the Deployment Manager properties, see Deployment Manager: SAP HANA scale-up deployment guide.

Password management

To automate the installation of SAP HANA on the deployed Compute Engine VMs, you must specify the passwords for the SIDadm user and the database user. You can specify these passwords in your Terraform configuration file in the following ways:

• (Recommended) To provide the passwords to the installation scripts securely, you can create secrets using Secret Manager, which is a charged service of Google Cloud, and then specify the names of the secrets as values for the sap_hana_sidadm_password_secret and sap_hana_system_password_secret arguments.

  For information about Secret Manager pricing, see Secret Manager pricing.

• Alternatively, you can specify the passwords in plain text on the sap_hana_sidadm_password and sap_hana_system_password arguments.

Disk deployment by Terraform

When you automate the deployment of SAP HANA by using the Terraform configuration provided by Google Cloud, then the default disk deployment is as follows:

Custom VMs and automated deployments

The Terraform configuration files and Deployment Manager templates do not support the specification of Compute Engine custom VMs.

If you need to use a custom VM type, deploy a small predefined VM type first and, after the deployment is complete, customize the VM as needed.

For more information about modifying VMs, see Modifying VM configurations for SAP systems.

Deployment automation for scale-up systems

Google Cloud provides Terraform configuration files and Deployment Manager configuration templates that you can use to automate the deployment of SAP HANA single-host scale-up systems.

The Terraform or Deployment Manager scripts can be used for the following scenarios:

• A stand-alone, scale-up SAP HANA system.

  See the Terraform or Deployment Manager deployment guide.

• An active and standby scale-up SAP HANA system on a Linux high-availability cluster.

  See the Terraform or Deployment Manager deployment guide.

The Terraform or Deployment Manager scripts can deploy the VMs, persistent disks, SAP HANA, and, in the case of the Linux HA cluster, the required HA components.

The Deployment Manager scripts do not deploy the following system components:

• The network and subnetwork
• Firewall rules
• NAT gateways, bastion hosts, or their VMs
• SAP HANA Studio or its VM

Except SAP HANA Studio or its VM, you can use Terraform to deploy all of these system components.

For information about creating these components, see the Prerequisites section in the following guides:

• Terraform: SAP HANA scale-up deployment guide
• Deployment Manager: SAP HANA scale-up deployment guide

Deployment automation for scale-out systems

Google Cloud provides Terraform configuration files and Deployment Manager configuration templates that you can use to automate the deployment of the SAP HANA multi-host scale-out systems.

• To deploy a scale-out system that does not include SAP HANA host auto-failover, see Terraform: SAP HANA Deployment Guide or Deployment Manager: SAP HANA Deployment Guide.
• To deploy a scale-out system without standby hosts in a Linux high-availability cluster, see Terraform: SAP HANA high-availability cluster configuration guide.
• To deploy a scale-out system that includes standby hosts, see Terraform: SAP HANA Scale-Out System with Host Auto-Failover Deployment Guide or Deployment Manager: SAP HANA Scale-Out System with Host Auto-Failover Deployment Guide.

The Terraform configuration or Deployment Manager templates can deploy the VMs, persistent disks, and SAP HANA. They can also map NFS mount points to the SAP HANA shared and backup volumes. For multi-host scale-out deployments, the Terraform configuration or Deployment Manager template can also deploy new Filestore instances to host the SAP HANA shared and backup volumes.

The Deployment Manager scripts do not deploy the following system components:

• The network and subnetwork
• Firewall rules
• NAT gateways, bastion hosts, or their VMs
• SAP HANA Studio or its VM

Except SAP HANA Studio or its VM, you can use Terraform to deploy all of these system components.

File sharing solutions for multi-host scale-out deployments

The Terraform configuration that Google Cloud provides for SAP HANA multi-host scale-out deployment, by default, creates NFS exports for the /hana/shared and /hanabackup volumes on the primary SAP HANA VM instance and shares the volumes with the worker nodes.

However, if you want to use an NFS solution for sharing the /hana/shared and /hanabackup volumes with your worker hosts, then you can use one of the following options:

• To associate an existing NFS solution that you have deployed on Google Cloud, you need to specify the NFS mount points of the /hana/shared and /hanabackup volumes to the sap_hana_shared_nfs and sap_hana_backup_nfs arguments, respectively, in your Terraform configuration file.

• To deploy new Filestore instances and associate their file shares with the /hana/shared and /hanabackup volumes, you need to define a google_filestore_instance resource and then specify the names of the file shares to the sap_hana_shared_nfs_resource and sap_hana_backup_nfs_resource arguments, respectively, in your Terraform configuration file.

To view an example, see sample configuration.

Support

For issues with Google Cloud infrastructure or services, contact Customer Care. You can find the contact information on the Support Overview page in the Google Cloud console. If Customer Care determines that a problem resides in your SAP systems, then you are referred to SAP Support.

For SAP product-related issues, log your support request with SAP support. SAP evaluates the support ticket and, if it appears to be a Google Cloud infrastructure issue, then SAP transfers that ticket to the appropriate Google Cloud component in its system: BC-OP-LNX-GOOGLE or BC-OP-NT-GOOGLE.

Support requirements

Before you can receive support for SAP systems and the Google Cloud infrastructure and services that they use, you must meet the minimum support plan requirements.

For more information about the minimum support requirements for SAP on Google Cloud, see:

• Getting support for SAP on Google Cloud
• SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites (An SAP user account is required)

What's next

• For more information from SAP about SAP HANA dynamic tiering, see SAP HANA Dynamic Tiering.