Reference Architecture: SAP 

S/4HANA on Google Cloud 

Platform 
Overview 1 

Licensing 2 

Sizing 2 

Supported machine types 2 

Disks and file systems for S/4HANA 3 

Recommended Linux directory structure for SAP HANA 3 
Recommended Linux directory structure for ABAP 4 

Deployment 4 
Deployment models 4 
Centralized deployment 4 
Distributed deployment 5 
A note on load balancing 6 
High availability and disaster recovery 6 

Backup and recovery 8 

Backups 8 
Recovery 9 

Important pre-deployment SAP Notes 10 

Overview 
This document is for people who are evaluating Google Cloud Platform (GCP) as a platform for 
deploying SAP S/4HANA, especially for people in the following kinds of jobs: 
 
● SAP technical architect 
● Cloud architect 
● SAP basis administrator 
● Enterprise architect 

1  Licensed under the Creative Commons Attribution 3.0 License.

 
This document also lists issues to consider prior to installation, as well as linking to SAP Notes 
and other documentation to facilitate deployment. 
 
Google Cloud Platform provides a cost-effective, reliable, secure, and high-performance SAP 
certified infrastructure for running SAP S/4HANA on SAP HANA. For a complete list of 
supported SAP solutions on GCP, see S ​ AP and Google Cloud​. 

Licensing 
If you're an SAP customer, you can use your existing license to deploy SAP Business Suite on 
GCP under a bring-your-own-license (BYOL) model. GCP supports the BYOL model for both 
production and non-production use cases. Operating system licenses are included in Compute 
Engine prices; alternatively, you can bring your own OS i​ mage​ and licenses as well. 

Sizing 
Several sizing options are available based on the implementation type. For g ​ reenfield 
implementations, we recommend using the SAP Quick Sizer tool. For detailed information, see 
SAP’s ​Sizing​ page. SAP also provides T-shirt guides for specific solutions and tools for 
migrating current on-premises solutions to GCP. (For example, see ​Find Certified IaaS Platforms 
and S​ AP Applications on Google Cloud Platform: Supported Products and Google VM types​.) 
SAP and GCP use different units to measure IOPS (input/output operations per second); consult 
your SI (Systems Integrator) partner to convert SAP sizing requirements to GCP components. 
 
Before you migrate existing systems from SAP ECC to S/4HANA, SAP recommends that you run 
the /SDF/HDB_SIZING report, as described in SAP note 1872170, ​Business Suite on HANA and 
S/4HANA sizing report​. This sizing report analyzes your source system's current memory and 
processing needs and provides information on the requirements for moving to S/4HANA. 

Supported machine types 

GCP offers Compute Engine instance types that are certified by SAP to match sizing 
requirements when you’re deploying S/4HANA. For more information about sizing on GCP and 
the machine types that are supported, see the following pages: 
● Supported machine types for SAP HANA on GCP​. 
● Supported machine types for SAP NetWeaver on GCP​. 
 

2  Licensed under the Creative Commons Attribution 3.0 License.

Custom machine types for SAP HANA on GCP are also certified by SAP. You can run SAP HANA 
instances with less than 64 vCPUs as long as you maintain a vCPU/Memory ratio of at least 6.5. 
To determine ​SAPS​ provided by your chosen CPU architecture, see S
​ AP SD Standard 
Application Benchmark Results, Two-Tier Internet Configuration​. 
 
SAP provides a certified list of GCP configurations for SAP HANA on its website as well. For 
more details, see ​Find Certified IaaS Platforms​. 

Disks and file systems for S/4HANA  

Google Cloud Platform offers the following storage types: 
 
● Standard (HDD) persistent disks: Low-cost block storage for large devices. 
● SSD persistent disks: Fast and reliable block storage, with high IOPS and low latency. 
● Local SSDs: High-performance local block storage. 
● Cloud Storage buckets: Affordable object storage. 
 
For more information, see ​Storage Options​. 
 
GCP p​ ersistent disks​ are designed for high durability. They store data redundantly to ensure 
data integrity. Each persistent disk can store up to 64 TB, so you can create large logical 
volumes without managing arrays of disks. One key feature is that persistent disks are 
automatically encrypted to protect data. 
 
Upon creation, a Compute Engine instance allocates a single root persistent disk by default that 
contains the operating system. You can add more storage options to the instance as needed. 
For SAP implementations, we recommend using persistent disks, because they are designed for 
high durability and compute instances can access them like physical disks on a local machine. 
 
The following tables describe the Linux directory structures for SAP HANA and ABAP on GCP. 

Recommended Linux directory structure for SAP HANA 

SAP HANA directory structure Storage type

/usr/sap SSD persistent disk 
/hana/data SSD persistent disk 
/hana/log SSD persistent disk 
/hana/shared SSD persistent disk 
/hanabackup Standard persistent disk (HDD) 

3  Licensed under the Creative Commons Attribution 3.0 License.

Recommended Linux directory structure for ABAP 

ABAP directory structure Storage type

/sapmnt Standard persistent disk (HDD) 
/usr/sap/ Standard persistent disk (HDD) 

Deployment 
SAP S/4HANA consists of the following technical components:  
● SAP HANA. 
● PAS—Primary application server. 
o Acts as a web application server for SAP systems. 
● AAS—Additional application server. 
o Usually deployed for application level load balancing. You can install multiple 
AAS to achieve higher availability from an application layer perspective as well. If 
one of the application servers goes down, all user sessions connected to that 
application server are terminated, but users can log in again to the other 
associated AAS in the environment. 
● SAP NetWeaver Gateway. 
● Fiori front end. 
● WD—Web Dispatcher (optional). 
o Intelligent software load balancer that distributes HTTP and HTTPS requests, 
based on application type, to PAS and AAS. 

Deployment models 
You can deploy S/4HANA on GCP in either of two models: centralized deployment or distributed 
deployment. 

Centralized deployment 
In a centralized deployment, you can install S/4HANA and the SAP HANA database on the same 
Compute Engine instance. We recommend this approach for non-production environments such 
as sandbox and development environments. 
 
The following diagram shows a reference architecture for S/4HANA in a centralized deployment 
model. Note that SAP ASCS, PAS, WD, and HANA are all installed on the same instance. 

4  Licensed under the Creative Commons Attribution 3.0 License.

  

Distributed deployment 
In a distributed deployment, you can install the different components on different Compute 
Engine instances. We recommend this approach for production environments or environments 
that require a lot of compute power to handle heavy transaction load. 
 
The following diagram shows a reference architecture for S/4HANA in a distributed deployment 
model. Note that SAP ASCS, PAS, WD, and HANA are all installed on different instances. 

 
To install SAP HANA in a centralized or distributed deployment, use the deployment script. For 
more information, see ​SAP HANA Deployment Guide​. 

5  Licensed under the Creative Commons Attribution 3.0 License.

A note on load balancing 
In a distributed S/4HANA environment, load balancing is mandatory. You can configure 
application load balancing using the SAP application layer. For related information about SAP 
Web Dispatcher, see elsewhere in the ​Deployment​ section of this document. 

High availability and disaster recovery  

High availability (HA) and disaster recovery (DR) are sets of techniques, engineering practices, 
and design principles to enable business continuity in the event of failures. These approaches 
work by eliminating single points of failure and providing the ability to rapidly resume operations 
after a system or component outage with minimal business disruption. Fault recovery is the 
process of recovering and resuming operations after an outage due to a failed component. 
 
For example, here are some HA and DR tools: 
● Linux clustering across zones. 
● Live migration. 
● Automatic restart​. 
● Service auto-restart. 
● Backups. 
 
Some further details about some of those items: 
 
Linux clustering across zones​: Setting up your Linux cluster across z​ ones​ helps guard against 
component failures in a given region. You can deploy a Linux cluster across zones using either 
an active/passive configuration or an ​active/active​ configuration. In both cases, you start by 
setting up two Compute Engine instances in separate zones, each with its own SAP HANA 
database. 
 
● Active/passive configuration​: Configure one instance as the cluster’s primary node 
(active) and the other as the secondary node (passive). Use SAP HANA System 
Replication (SR) to configure the secondary node to take over as primary if the primary 
fails, as shown in the following diagram. For more information on how to configure and 
set up HANA SR, see ​HANA System Replication​. 

6  Licensed under the Creative Commons Attribution 3.0 License.

  
● Active/active configuration​ (read-enabled): Configure both instances to be active, but 
the secondary node as read-only​. This setup is based on continuous log replay. The 
Virtual IP (VIP) is configured to point to the current read/write node. 
 
● For more information, see the ​SAP HANA High Availability and Disaster Recovery 
Planning Guide​. 
 
Live migration​: Compute Engine offers live migration to keep your Compute Engine instances 
running even when a host system event occurs, such as a software or hardware update. In that 
situation, Compute Engine live-migrates your running instance to another host in the same zone, 
rather than requiring your running instance to be rebooted. The mechanism replicates the 
original instance’s VM state, so when the new instance comes up, it already has the original 
instance’s memory pre-loaded. 
 
In the rare case when live migration doesn’t happen, the failed virtual machine is automatically 
restarted on the new hardware within the same zone. 
 
For more details, see ​Live Migration​. 
 
The following diagram shows a typical scenario for live migration on the SAP HANA scale-up 
setup: 

7  Licensed under the Creative Commons Attribution 3.0 License.

  

Backup and recovery 

Make backups of your application server and database on a regular schedule so that you can 
recover in case of a system crash, data corruption, or other problems. 

Backups 
SAP HANA provides a native backup/recovery feature, using Google Cloud Storage as a backup 
destination. 
 
During normal operation, SAP HANA automatically saves data from memory to disk at regular 
save points. Additionally, all data changes are captured in redo log entries. A redo log entry is 
written to disk after each committed database transaction. 
 
From SAP HANA 2.0 onwards, you must use SAP HANA cockpit to back up SAP HANA. 
 
The following diagram shows the flow of the backup feature for SAP HANA. 

8  Licensed under the Creative Commons Attribution 3.0 License.

  
Another option is to back up the entire disk hosting data and log using the ​persistent-disk 
snapshot​ feature of Compute Engine. You can store the snapshots in the same /backup folder. 
The advantage of taking snapshots is that they are incremental, so each subsequent snapshot 
stores only incremental block changes. 

The following diagram shows snapshots of a backup. 

Recovery 
 

9  Licensed under the Creative Commons Attribution 3.0 License.

The recovery tools in SAP HANA can recover to the latest point in time or a specific point in 
time, and you can use these tools to restore to a new system or create a copy of the database. 
Unlike backups, which you can run while the database is operational, you can use recovery tools 
only while the database is shut down. Recovery options are listed below; choose an appropriate 
one for your situation. 
 
● Restore to the most recent state, using any of the following resources: 
○ Full backup or snapshot. 
○ Log backups. 
○ Redo log entries that are still available. 
● Restore to a point in time in the past. 
● Restore to a specified full backup. 

Important pre-deployment SAP Notes 

The following table links to some important SAP Notes; read the ones that are relevant to your 
situation before beginning to deploy SAP S/4HANA on GCP. Before proceeding with any SAP 
product implementation, always check the SAP Marketplace for updated product installation 
guides and notes. 

2456432 SAP Applications on Google Cloud Platform: Supported Products and Google VM 
types 

2446441 Linux on Google Cloud Platform (IaaS): Adaption of your SAP License 

2456953 Windows on Google Cloud Platform (IaaS): Adaption of your SAP License 

1380654 SAP support in public cloud environments 

10  Licensed under the Creative Commons Attribution 3.0 License.