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 GCP, see the SAP HANA Deployment Guide.

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. At the core of this real-time data platform is the SAP HANA database. Customers can leverage ease of provisioning, highly scalable, and redundant GCP infrastructure capabilities to run their business critical workloads. GCP 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 GCP, 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 best practices for enterprise organizations.

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 Cloud Console offers.
• Client libraries, which provide APIs for accessing services and management of resources. Client libraries are useful when building your own tools.

Important: If you are using the gcloud command-line tool, always make sure that you are using the latest version of the Cloud SDK. To install the latest version of the Cloud SDK, see the gcloud install instructions.

GCP services

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

Service	Description
VPC Networking	Connects your VM instances to each other and to the Internet. Each instance is a member of either a legacy network with a single global IP range, or a recommended subnet network, where the instance is a member of a single subnetwork that is a member of a larger network. Note that a network cannot span Google Cloud projects, but a Google Cloud project can have multiple networks.
Compute Engine	Creates and manages VMs with your choice of operating system and software stack.
Persistent disks	Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD).
Google Cloud Console	Browser-based tool for managing Compute Engine resources. Use a template to describe all of the Compute Engine resources and instances you need. You don't have to individually create and configure the resources or figure out dependencies, because the Cloud Console does that for you.
Cloud Storage	You can back up your SAP database backups into Cloud Storage for added durability and reliability, with replication.
Cloud Monitoring	Provides visibility into the deployment, performance, uptime, and health of Compute Engine, network, and persistent disks. Monitoring collects metrics, events, and metadata from Google Cloud and uses these to generate insights through dashboards, charts, and alerts. You can monitor the compute metrics at no cost through Monitoring.
Cloud IAM	Provides unified control over permissions for Google Cloud resources. Control who can perform control-plane operations on your VMs, including creating, modifying, and deleting VMs and persistent disks, and creating and modifying networks.

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's operations suite 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.

Resource requirements

VM types

The following table shows the Compute Engine virtual machine (VM) types and operating systems that are certified by SAP for production use on Google Cloud. Except where noted in the table, SAP supports the VM types in both single-host (scale-up) and multi-host (scale-out) installations. Scale-out installations can include up to 15 worker hosts, for a total of 16 hosts.

Custom VM types are also certified by SAP, as long as the number of vCPUs is between 32 and 64, and the ratio of memory to vCPUs is 6.5 GB per vCPU.

The table also lists the certified versions of both the Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server operating systems.

For more information about the supported operating systems, see Operating system support for SAP HANA on GCP.

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

Some VM types might not be available in all Google Cloud regions. To confirm that a machine type is available in a region, see Available regions & zones.

SAP lists the certified VM instance types for SAP HANA in the SAP HANA Hardware Directory.

Note: The prefix in the following machine names changed from "n1" to "m1" to more clearly identify the machines as members of the memory-optimized machine-type family:

• n1-megamem-96 is now m1-megamem-96
• n1-ultramem-40 is now m1-ultramem-40
• n1-ultramem-80 is now m1-ultramem-80
• n1-ultramem-160 is now m1-ultramem-160

The machines themselves did not change and the former names are still supported as aliases for these machines.

Google Cloud instance type	vCPU	Memory (GB)	Operating system	CPU platform
N1 high-memory, general-purpose machine types
n1-highmem-32	32	208	RHEL, SUSE	Intel Broadwell
n1-highmem-64	64	416	RHEL, SUSE	Intel Broadwell
n1-highmem-96	96	624	RHEL, SUSE	Intel Skylake
N2 high-memory, general-purpose machine types
n2-highmem-32    (Scale up only)	32	Up to 256	RHEL, SUSE	Intel Cascade Lake
n2-highmem-48    (Scale up only)	48	Up to 348	RHEL, SUSE	Intel Cascade Lake
n2-highmem-64    (Scale up only)	64	Up to 512	RHEL, SUSE	Intel Cascade Lake
n2-highmem-80    (Scale up only)	80	Up to 640	RHEL, SUSE	Intel Cascade Lake
M1 memory-optimized machine types
m1-megamem-96	96	1,433	RHEL, SUSE	Intel Skylake
m1-ultramem-40    (Scale up only,    OLTP workloads only)	40	Up to 961	RHEL, SUSE	Intel Broadwell
m1-ultramem-80    (Scale up only,    OLTP workloads only)	80	Up to 1,922	RHEL, SUSE	Intel Broadwell
m1-ultramem-160	160	Up to 3,844	RHEL, SUSE	Intel Broadwell
M2 memory-optimized machine types
m2-ultramem-208    (Scale up only,    OLTP workloads only)	208	Up to 5,888	RHEL, SUSE	Intel Cascade Lake
m2-ultramem-416    (Scale up only,    OLTP workloads only)	416	Up to 11,776	RHEL, SUSE	Intel Cascade Lake
Custom general-purpose machines
Custom	32-64	6.5 GB for each vCPU	RHEL, SUSE	Intel Broadwell

Storage configuration

SAP HANA is an in-memory database, but even though most data is stored and processed in memory, SAP HANA protects against data loss by saving the data to a persistent storage location.

On Google Cloud, use Compute Engine SSD persistent disks with the SAP-certified VM types for persistent storage of your SAP HANA data.

The SSD disk must be at least 834 GB in size and the VM instance must have at least 32 vCPUs to meet SAP support requirements for SAP HANA on GCP. This configuration provides a sustained throughput of up to 400 MB/sec for writes and 400 MB/sec for reads. SSD persistent disk performance scales linearly until it reaches either the limits of the volume or the limits of the Compute Engine instance.

If you deploy an SAP HANA system by using the Cloud Deployment Manager scripts that Google Cloud provides, Cloud Deployment Manager allocates an SSD persistent disk that is, at a minimum, 834 GB. If your SAP HANA system requires more persistent storage, Cloud Deployment Manager automatically adjusts the sizing of the persistent disks.

Cloud Deployment Manager maps the SAP HANA data, log, sap, and shared directories to the single SSD persistent disk in a single Linux volume group. Each directory is mapped to its own logical volume for easy resizing.

In the following example, the vg_hana volume group is mapped to a single 834 GB SSD persistent disk. The vg_hanabackup volume group is mapped to a standard HDD persistent disk. The sizes of your volumes might differ slightly from what is shown in the example.

hana-ssd-example:~ # lvs
  LV     VG            Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data   vg_hana       -wi-ao---- 496.00g
  log    vg_hana       -wi-ao---- 102.00g
  sap    vg_hana       -wi-ao----  32.00g
  shared vg_hana       -wi-ao---- 204.00g
  backup vg_hanabackup -wi-ao---- 416.00g

You can see the persistent disks that are attached to a VM instance on the Additional disks section of the VM instance details page for the VM instance in the Cloud Console.

For more information about how disk size and the number of vCPUs affect the performance of SSD persistent disks, see SSD persistent disks.

Note: Disk size, machine type memory, and network usage are calculated in gigabytes (GB), where 1 GB is 2³⁰ bytes. This unit of measurement is also known as a gibibyte (GiB).

Storage for backups

Storage for SAP HANA backup is configured with standard HDD persistent disks. Standard HDD persistent disks are efficient and economical for handling sequential read-write operations, but are not optimized to handle high rates of random input-output operations per second (IOPS). SAP HANA uses sequential IO with large blocks to back up the database. Standard HDD persistent disks provide a low-cost, high-performance option for this scenario.

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.

If you use SAP HANA dynamic tiering, 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.

If you use the Cloud Storage Backint agent for SAP HANA, 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 GCP. 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.

Shared storage options

You have a number of choices for shared storage on Google Cloud.

NetApp Cloud Volumes Service for Google Cloud

NetApp Cloud Volumes Service for Google Cloud is a SAP-certified, fully-managed, cloud-native data service platform that you can use to create an NFS file system for SAP HANA scaleup systems on Compute Engine instance types up to 4TB. SAP HANA scaleout systems are not supported.

With NetApp Cloud Volumes Service, you can place all of the SAP HANA directories, including /hana/data and /hana/logs, in shared storage, instead of using Compute Engine persistent disks. With most other shared storage systems, you can only place the /hana/shared directory in shared storage.

SAP support for NetApp Cloud Volumes Service on Google Cloud is listed in the SAP HANA Hardware Directory.

After reviewing the following guidance, you can deploy NetApp Cloud Volumes on Google Cloud by following the instructions in the NetApp Cloud Volumes Service for Google Cloud documentation.

Regional availability of NetApp Cloud Volume Services for SAP HANA

NetApp Cloud Volumes Service for SAP HANA is available in the following Google Cloud regions:

Region	Location
us-east4	Ashburn, Northern Virginia, USA
us-west2	Los Angeles, California, USA

NFS protocol support

NetApp Cloud Volumes Service supports the NFS 3 and NFS 4.1 protocols with SAP HANA on Google Cloud.

Volume requirements for NetApp Cloud Volumes Service with SAP HANA

Except for the /hana/shared volume, NetApp Cloud Volumes Service Extreme is required for all storage volumes. For /hana/shared, use premium to reduce costs.

To meet SAP HANA performance requirements, the following minimum volume sizes are required when running SAP HANA with NetApp Cloud Volume Services:

• /hana/shared 1TB
• /hana/log 2.5TB
• /hana/data 4TB

The minimum throughput rate for NetApp Cloud Volumes Service is 128 MB per second for each 1 TB, so the throughput for 4TB of disk space is 512 MB per second. Provisioning more disk space for the /hana/data volume can reduce startup times. For the /hana/data volume, we recommend either 1.5 times the size of your memory or 4 TB, whichever is greater.

The minimum size for the /hanabackup volume is determined by your backup strategy.

Filestore

For the /hana/shared volume only, you can use Filestore. However, with Filestore, all SAP HANA hosts that share the storage must be within the same Google Cloud zone.

Memory configuration

See the supported VM types table.

Operating system selection

SAP HANA runs on either the Red Hat Enterprise Linux (RHEL) operating system or the SUSE Linux Enterprise Server (SLES) operating system.

The following table shows the RHEL and 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 GCP.

For information from SAP about which operating systems SAP supports with SAP HANA on Google Cloud, see the SAP HANA Hardware Directory.

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.

Operating system	Version	Unsupported VM types
RHEL for SAP
	7.3	n2-highmem m1-ultramem m2-ultramem custom
	7.4	m2-ultramem
	7.6
SLES for SAP
	12 SP3	n1-highmem m1-megamem
	12 SP4
	12 SP5
	15
	15 SP1

Custom operating system images

You can use a Linux image that GCP 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 GCP 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 GCP 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 GCP, 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 GCP provides, see Images.

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

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

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

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 member. 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 Cloud 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 Cloud IAM roles provide, you can create custom roles.

For more information about the Cloud 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.

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.

Important: RHEL and SLES are premium images and all prices for premium images are in addition to charges for using a machine type. For details about premium image pricing, refer to the Premium images.

Note: You might be able to achieve a sustained use discount of up to 30% for your Compute Engine instances.

Quotas

If you have a new GCP account, or if you haven't asked for an increased quota, you will need to do so to complete this guide. View your existing quota, and compare with the following table to see what increase to ask for. You can then request a quota-limit increase.

The following table shows quota values for single-host, scale-up SAP HANA systems by VM instance type. If you host SAP HANA Studio on GCP or use a NAT gateway and bastion host, add the values shown in the table to your total quota requirement.

Instance type	CPU	Memory	Standard PD	SSD PD
n1-highmem-32	32	208 GB	448 GB	834 GB
n1-highmem-64	64	416 GB	864 GB	1,280 GB
n1-highmem-96	96	624 GB	1,280 GB	1,904 GB
n2-highmem-32	32	256 GB	544 GB	834 GB
n2-highmem-48	48	384 GB	800 GB	1,184 GB
n2-highmem-64	64	512 GB	1,056 GB	1,568 GB
n2-highmem-80	80	640 GB	1,312 GB	1,952 GB
m1-megamem-96	96	1,433 GB	2,898 GB	3,717 GB
m1-ultramem-40	40	961 GB	1,954 GB	2,914 GB
m1-ultramem-80	80	1,922 GB	3,876 GB	4,451 GB
m1-ultramem-160	160	3,844 GB	7,720 GB	7,334 GB
m2-ultramem-208	208	5,888 GB	11,808 GB	10,400 GB
m2-ultramem-416	416	11,766 GB	23,564 GB	19,217 GB
Bastion/NAT gateway	1	3.75 GB	8 GB	0 GB
SAP HANA Studio	1	3.75 GB	50 GB	0 GB

Licensing

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

Note: After you deploy SAP HANA on GCP, you must install your permanent SAP HANA license before the temporary license for SAP HANA expires. If you do not, your SAP HANA system might go into database lockdown after the temporary license expires.

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

Deployment architecture

SAP HANA on GCP supports single-host and multi-host architectures.

Single-host architecture

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

Notice that the VM for SAP HANA has no public IP, which means it cannot be reached from an external network. Instead, the deployment uses a NAT bastion host and SAP HANA Studio for accessing SAP HANA. The SAP HANA Studio instance and the bastion host are deployed in the same subnetwork as the SAP HANA instance.

You provision a Windows host on which you install SAP HANA Studio, with the instance placed in the same subnetwork, and with firewall rules that enable you to connect to the SAP HANA database from SAP HANA Studio.

You deploy SAP HANA using a single-host, scale-up architecture that has the following components:

• One Compute Engine instance for the SAP HANA database, with a 834 GB or larger SSD persistent disk, and a network bandwidth of up to 16 Gbps. The SSD persistent disk is partitioned and mounted to /hana/data and /hana/log to host the data and logs.

• An optional, but recommended, subnetwork with a custom topology and IP ranges in the GCP 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.

• An optional, but recommended, Internet gateway configured for outbound Internet access for your SAP HANA and other instances. This guide assumes you are using this gateway.

• Compute Engine firewall rules restricting access to instances.

• Persistent disk for backup of SAP HANA database.

• Compute Engine VM, n1-standard-2, with Windows OS to host SAP HANA studio.

• Compute Engine VM, n1-standard-1 as a bastion host.

• Automated SAP HANA database installation with a configuration file that you create from a template.

• SAP HANA Studio.

Deploying scale-up systems with Deployment Manager

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

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

• A stand-alone, scale-up SAP HANA system
• An active and standby scale-up SAP HANA system on a Linux high-availability cluster

The 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

Note: 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. The Deployment Manager configuration template does not support the specification of custom VM types. For more information about modifying VMs, see Modifying VM configurations for SAP systems.

Multi-host architecture

The following diagram shows a multi-host architecture on Google Cloud.

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

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 16 Gbps.

Standby hosts support the SAP HANA host auto-failover fault recovery solution. For more information about host auto-failover on Google Cloud, see the SAP HANA High Availability and Disaster Recovery Planning Guide.

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 persistent disks, which provide consistent, high IOPS, IO services. The master host also serves as an NFS master for /hana/shared and /hanabackup volumes, which 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.

High availability for SAP HANA scale-out systems on Google Cloud

The following features help ensure the high availability of a SAP HANA scale-out system:

• Compute Engine live migration
• Compute Engine automatic instance restart
• SAP HANA host auto-failover with up to three SAP HANA standby hosts

For more information about high availability options on Google Cloud, see the SAP HANA High Availability and Disaster Recovery Planning Guide.

In the event of a live migration or automatic instance restart event, the protected-persistent-storage-based /hana/shared and /hanabackup volumes can be back online as soon as an instance is up.

If you are using a standby host, in the event of a failure, SAP HANA automatic failover unmounts the /hana/data and /hana/log volumes from the failed host and mounts on them on standby host.

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

A multi-host SAP HANA scale-out architecture on Google Cloud contains the 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 the machine types that are supported by SAP HANA, see VM types.

  Each VM must include SSD and HDD storage, mounted in the correct location.

• 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.

• An optional, but recommended, subnetwork with a custom topology and IP ranges in the GCP 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.

• Optionally, an internet gateway configured for outbound internet access for your SAP HANA instance and other instances.

• Optionally, a Compute Engine n1-standard-2 VM with the Windows operating system installed to host SAP HANA Studio.

• Optionally, a Compute Engine n1-standard-1 VM for a bastion host.

• 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.

Deploying scale-out systems with Deployment Manager

Google Cloud provides 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 the SAP HANA Deployment Guide.

The Deployment Manager scripts can deploy the VMs, persistent disks, and SAP HANA. The script also mounts the NFS solution to the VMs.

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

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

Note: 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. The Deployment Manager configuration template does not support the specification of custom VM types. For more information about modifying VMs, see Modifying VM configurations for SAP systems.

Support

For issues with Google Cloud infrastructure or services, contact Google Cloud Support. You can find contact information on the Support Overview page in the Google Cloud Console. If Google Cloud Support determines that a problem resides in your SAP systems, 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, transfers the ticket to the Google Cloud component 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 (An SAP user account is required)

What's next

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