SAP NetWeaver Planning Guide

This guide provides an overview of how SAP NetWeaver works on Google Cloud, and provides details that you can use when planning the migration of your existing SAP NetWeaver system, or when implementing a new system. Google Cloud is certified for running SAP NetWeaver application servers ABAP and Java, and SAP products based on these application server stacks.

This guide does not cover the specifics of deploying the SAP NetWeaver system. To learn how to plan for your deployment of SAP NetWeaver, see the SAP NetWeaver Master Guide.

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.

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.

Overview of SAP NetWeaver on Google Cloud

In many ways, running SAP NetWeaver on Google Cloud is similar to running it in your own data center. You still need to think about computing resources, storage, and networking considerations. You also still need to think through how to handle backups and disaster recovery for your database.

Here are some of the differences that you should understand:

  • You interact with the various infrastructure components through services, which are abstractions or virtualizations of the hardware that you would use on premises. For example, some of the virtualized infrastructure services that you use instead of hardware on Google Cloud include Compute Engine instances and persistent disks, Virtual Private Cloud networks and firewalls, and Cloud Storage buckets for mass storage.
  • Google Cloud services offer particular features and introduce certain limitations.
  • Google Cloud services work together in particular ways.
  • SAP NetWeaver and the Google Cloud services work together in particular ways.

The following diagram provides a high-level overview of SAP NetWeaver running on Google Cloud:

Overview of SAP NetWeaver on Google Cloud

Here are some important things to notice in the diagram:

  • The system uses some number of Compute Engine instances and persistent disks. These components host the software, including the main database system.
  • The SAP NetWeaver system consists of its usual application components plus a Host Agent component.
  • The SAP Host Agent/SAPOSCOL component collects monitoring metadata from Google Cloud's Agent for SAP. Google Cloud's Agent for SAP aggregates metrics from Cloud Monitoring, the Google Cloud monitoring solution.
  • All communication between Google Cloud components and external components pass through a networking layer. This layer provides security features, including firewalls, routes and internet gateways, VPN, and so on.

Two-tier architecture

The following diagram shows some details of a 2-tier architecture running on a Compute Engine instance.

2-tier architecture

In this architecture, all the components run on a single Compute Engine instance. The compute instance has 5 attached Persistent Disk volumes, each serving a specific role. These roles include:

  • Root disk: Contains the operating system for the compute instance.
  • Swap disk: Contains the operating system's paging file.
  • SAP NetWeaver: Contains the NetWeaver installation and the profile files.
  • Data volume: Contains the database files.
  • Logs volume: Contains the database-system logs used for maintaining data consistency, backup, and recovery operations.

Depending on which database server you are using, the data volumes that you need might be different than those shown in the preceding figure.

Up to a limit, the performance of an SSD or balanced persistent disk improves as the size of the disk and the number of vCPUs increases. If you use one of these persistent disk types, create a larger PD volume and logically partition the disk in the guest operating system for multiple file systems. For example, if you use SAP HANA, you can map the /hana/data, /hana/log, and /hana/shared volumes to a single persistent disk. Using a larger single persistent disk also allows for easier resizing in the VM and simplifies management.

Depending on your application, attaching multiple persistent disk volumes to your VM can have operational benefits. For example, it can simplify the use of persistent disk snapshots for specific volumes.

Striping over multiple persistent disk volumes does not provide a significant performance benefit for SAP on Google Cloud.

For more information, see:

The database server is also likely to require higher performance persistent disks than SAP NetWeaver requires.

For example, for a SAP HANA deployment:

  • The disk marked "Data volume" contains the data files.
  • The disk marked "Logs" contains the HANA log files.
  • The HANA binaries and shared files can be hosted on the disk labeled "NetWeaver".
  • You need an additional volume for storing database backups.

For information about SAP HANA on Google Cloud, see:

For a list of the disk drives required for SAP ASE, see the SAP ASE Planning Guide.

For a list of the disk drives required for SAP MaxDB, see the SAP MaxDB Planning Guide.

For a deployment of IBM Db2 for Linux, UNIX and Windows (IBM Db2), more disk drives are required than those shown in the preceding figure. For a list of the required disk drives, see the IBM Db2 for SAP Planning Guide.

For information about Microsoft SQL Server on Google Cloud, see Windows on Compute Engine.

In upcoming sections, you learn about details and recommendations for these components.

Three-tier architecture

The following diagram shows some details of a 3-tier architecture running on Compute Engine.

3-tier architecture

In this architecture, the SAP NetWeaver system distributes work across multiple NetWeaver Application Servers (AS) hosted on multiple VMs. All the NetWeaver AS nodes share the same database, which is hosted on a separate VM. All the NetWeaver AS nodes mount and access a shared file system that hosts the SAP NetWeaver profiles. This shared file system is contained on a persistent disk that is attached to VM 1, along with the SAP central services.

Certified machines

Google Cloud provides most computing resources as VMs, also called VM instances, through Compute Engine. Google Cloud provides bare-metal machines through Bare Metal Solution.

All machine types can:

  • Run operating systems.
  • Host SAP central services.
  • Host SAP AS.
  • Host database servers.

As you plan your SAP implementation, consider the following:

  • The number of machines that your implementation architecture requires. This number can range from one VM for a development, training, or small production system, to many VMs for a scale-out production system.
  • Particular machine types, which determine processing power—CPU types, number of cores, and so on—and available volatile memory.
  • Increasing the number of vCPUs in a VM instance increases the network bandwidth for outgoing communications (the egress rate) from the VM up to a limit that can differ depending on the machine type. See VPC resource quotas per instance.
  • Image types, which determine the operating system, and the database type if you choose to use SQL Server.
  • The location of the VMs. Compute Engine resources run in Google Cloud data centers worldwide, and these data centers are organized by region and zone. You learn more in Plan regions and zones.
  • The amount of persistent disk storage and the number of persistent disks. For most machine types, you can attach up to 257 TB of persistent disk storage. Although you can attach up to 128 persistent disks to most machine types, using fewer persistent disks reduces management overhead.

If you expect high network traffic, as is often the case in three-tier architectures that put the database on a separate VM, select a VM instance with enough vCPUs to provide the throughput you need.

For information on Google Cloud machine types and SAPS, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .

The following sections provide further details.

Machine types

Google Cloud offers SAP-certified machines in the following machine-type families:

  • Compute-optimized machine types: C2 or C2D
  • General-purpose machine types: N1, N2, N2D, T2D, C3, C3D, or C4
  • Memory-optimized machine types: M1, M2, M3, or X4
  • Bare Metal Solution machine types: O2
  • Custom configurations of the machine types: N1, N2, or N2D

For more information about each Compute Engine machine-type family that is certified for SAP applications, see Certified machine types.

The following machine certifications are for SAP NetWeaver. For machine certifications that are specific to SAP HANA, see Certified machine types for SAP HANA.

Before selecting a machine type for use, confirm that it is available in the region and zones that you need.

For more information about each Compute Engine machine type, including its regional and zonal availability, see Machine types.

For the availability of Bare Metal Solution machine types, see Regional availability of SAP-certified Bare Metal Solution machines.

Machine type Virtual CPUs Memory (GB) Minimum CPU platform
C2 standard machine types

c2-standard-4

 4 16 Intel Cascade Lake

c2-standard-8

 8 32 Intel Cascade Lake

c2-standard-16

 16 64 Intel Cascade Lake

c2-standard-30

 30 120 Intel Cascade Lake

c2-standard-60

 60 240 Intel Cascade Lake
C2D high-memory machine types
c2d-highmem-2 2 16 AMD EPYC Milan
c2d-highmem-4 4 32 AMD EPYC Milan
c2d-highmem-8 8 64 AMD EPYC Milan
c2d-highmem-16 16 128 AMD EPYC Milan
c2d-highmem-32 32 256 AMD EPYC Milan
c2d-highmem-56 56 448 AMD EPYC Milan
c2d-highmem-112 112 896 AMD EPYC Milan
C2D standard machine types

c2d-standard-2

 2 8 AMD EPYC Milan

c2d-standard-4

 4 16 AMD EPYC Milan

c2d-standard-8

 8 32 AMD EPYC Milan

c2d-standard-16

 16 64 AMD EPYC Milan

c2d-standard-32

 32 128 AMD EPYC Milan
c2d-standard-56 56 224 AMD EPYC Milan
c2d-standard-112 112 448 AMD EPYC Milan
Custom machine types
N1-based custom machine typeNote 1 or any even number up to 96 3.75 GB or more per vCPU for standard memory usage or 6.5 GB or more per vCPU for high memory usage. Intel Skylake
Intel Broadwell
N2-based custom machine typeNote Any even number up to 32. After 32, the number of vCPUs must be divisible by 4, up to 80 vCPUs. For example, 32, 36, and 40 vCPUs are all valid, but 38 is invalid. 4.0 GB or more per vCPU for standard memory usage or 8.0 GB or more per vCPU for high memory usage. Intel Cascade Lake
N2D-based custom machine typeNote 2 or any even number of vCPUs that is divisible by 4, up to an SAP-support limit of 32 vCPUs. 4.0 GB per vCPU for standard memory usage or 8.0 GB per vCPU for high memory usage. AMD EPYC Rome
M1 memory-optimized machine types
m1-megamem-96 96 1433 Intel Skylake

m1-ultramem-40

 40 961 Intel Broadwell

m1-ultramem-80

 80 1922 Intel Broadwell

m1-ultramem-160

 160 3,844 Intel Broadwell
M2 memory-optimized machine types

m2-ultramem-208

 208 5,888 Intel Cascade Lake

m2-ultramem-416

 416 11,776 Intel Cascade Lake

m2-megamem-416

 416 5,888 Intel Cascade Lake

m2-hypermem-416

 416 8,832 Intel Cascade Lake
M3 memory-optimized machine types
m3-ultramem-32 32 976 Intel Ice Lake
m3-ultramem-64 64 1,952 Intel Ice Lake
m3-ultramem-128 128 3,904 Intel Ice Lake
m3-megamem-64 64 976 Intel Ice Lake
m3-megamem-128 128 1,952 Intel Ice Lake
X4 memory-optimized bare metal machine types
x4-megamem-960-metal 960 16,384 Intel Sapphire Rapids
x4-megamem-1440-metal 1,440 24,576 Intel Sapphire Rapids
x4-megamem-1920-metal 1,920 32,768 Intel Sapphire Rapids
N1 high-memory machine types

n1-highmem-2

 2 13 Intel Skylake
Intel Broadwell

n1-highmem-4

 4 26 Intel Skylake
Intel Broadwell

n1-highmem-8

 8 52 Intel Skylake
Intel Broadwell

n1-highmem-16

 16 104 Intel Skylake
Intel Broadwell

n1-highmem-32

 32 208 Intel Skylake
Intel Broadwell

n1-highmem-64

 64 416 Intel Skylake
Intel Broadwell

n1-highmem-96

 96 624 Intel Skylake
N1 standard machine types

n1-standard-8

 8 30 Intel Skylake
Intel Broadwell

n1-standard-16

 16 60 Intel Skylake
Intel Broadwell

n1-standard-32

 32 120 Intel Skylake
Intel Broadwell

n1-standard-64

 64 240 Intel Skylake
Intel Broadwell

n1-standard-96

 96 360 Intel Skylake
N2 high-memory types
n2-highmem-2 2 16 Intel Ice Lake
Intel Cascade Lake
n2-highmem-4 4 32 Intel Ice Lake
Intel Cascade Lake
n2-highmem-8 8 64 Intel Ice Lake
Intel Cascade Lake
n2-highmem-16 16 128 Intel Ice Lake
Intel Cascade Lake
n2-highmem-32 32 256 Intel Ice Lake
Intel Cascade Lake
n2-highmem-48 48 384 Intel Ice Lake
Intel Cascade Lake
n2-highmem-64 64 512 Intel Ice Lake
Intel Cascade Lake
n2-highmem-80 80 640 Intel Ice Lake
Intel Cascade Lake
n2-highmem-96 96 768 Intel Ice Lake
n2-highmem-128 128 838 Intel Ice Lake
N2 standard machine types
n2-standard-2 2 8 Intel Ice Lake
Intel Cascade Lake
n2-standard-4 4 16 Intel Ice Lake
Intel Cascade Lake
n2-standard-8 8 32 Intel Ice Lake
Intel Cascade Lake
n2-standard-16 16 64 Intel Ice Lake
Intel Cascade Lake
n2-standard-32 32 128 Intel Ice Lake
Intel Cascade Lake
n2-standard-48 48 192 Intel Ice Lake
Intel Cascade Lake
n2-standard-64 64 256 Intel Ice Lake
Intel Cascade Lake
n2-standard-80 80 320 Intel Ice Lake
Intel Cascade Lake
n2-standard-96 96 384 Intel Ice Lake
n2-standard-128 128 512 Intel Ice Lake
N2D high-memory machine types

n2d-highmem-2

 2 16 AMD EPYC Rome
AMD EPYC Milan

n2d-highmem-4

 4 32 AMD EPYC Rome
AMD EPYC Milan

n2d-highmem-8

 8 64 AMD EPYC Rome
AMD EPYC Milan

n2d-highmem-16

 16 128 AMD EPYC Rome
AMD EPYC Milan

n2d-highmem-32

 32 256 AMD EPYC Rome
AMD EPYC Milan
n2d-highmem-48 48 384 AMD EPYC Rome
AMD EPYC Milan
n2d-highmem-64 64 512 AMD EPYC Rome
AMD EPYC Milan
n2d-highmem-80 80 640 AMD EPYC Rome
AMD EPYC Milan
n2d-highmem-96 96 768 AMD EPYC Rome
AMD EPYC Milan
N2D standard machine types

n2d-standard-2

 2 8 AMD EPYC Rome
AMD EPYC Milan

n2d-standard-4

 4 16 AMD EPYC Rome
AMD EPYC Milan

n2d-standard-8

 8 32 AMD EPYC Rome
AMD EPYC Milan

n2d-standard-16

 16 64 AMD EPYC Rome
AMD EPYC Milan

n2d-standard-32

 32 128 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-48 48 192 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-64 64 256 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-80 80 320 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-96 96 384 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-128 128 512 AMD EPYC Rome
AMD EPYC Milan
n2d-standard-224 224 896 AMD EPYC Rome
AMD EPYC Milan
T2D standard machine types

t2d-standard-2

 2 8 AMD EPYC Milan

t2d-standard-4

 4 16 AMD EPYC Milan

t2d-standard-8

 8 32 AMD EPYC Milan

t2d-standard-16

 16 64 AMD EPYC Milan
t2d-standard-32 32 128 AMD EPYC Milan
t2d-standard-48 48 192 AMD EPYC Milan
t2d-standard-60 60 240 AMD EPYC Milan
C4 high-memory machine types
c4-highmem-2 2 15 Intel Emerald Rapids
c4-highmem-4 4 31 Intel Emerald Rapids
c4-highmem-8 8 62 Intel Emerald Rapids
c4-highmem-16 16 124 Intel Emerald Rapids
c4-highmem-32 32 248 Intel Emerald Rapids
c4-highmem-48 48 372 Intel Emerald Rapids
c4-highmem-96 96 744 Intel Emerald Rapids
c4-highmem-192 192 1,488 Intel Emerald Rapids
C4 standard machine types
c4-standard-2 2 7 Intel Emerald Rapids
c4-standard-4 4 15 Intel Emerald Rapids
c4-standard-8 8 30 Intel Emerald Rapids
c4-standard-16 16 60 Intel Emerald Rapids
c4-standard-32 32 120 Intel Emerald Rapids
c4-standard-48 48 180 Intel Emerald Rapids
c4-standard-96 96 360 Intel Emerald Rapids
c4-standard-192 192 720 Intel Emerald Rapids
C3 high-memory machine types
c3-highmem-4 4 32 Intel Sapphire Rapids
c3-highmem-8 8 64 Intel Sapphire Rapids
c3-highmem-22 22 176 Intel Sapphire Rapids
c3-highmem-44 44 352 Intel Sapphire Rapids
c3-highmem-88 88 704 Intel Sapphire Rapids
c3-highmem-176 176 1408 Intel Sapphire Rapids
C3 standard machine types
c3-standard-4 4 16 Intel Sapphire Rapids
c3-standard-8 8 32 Intel Sapphire Rapids
c3-standard-22 22 88 Intel Sapphire Rapids
c3-standard-44 44 176 Intel Sapphire Rapids
c3-standard-88 88 352 Intel Sapphire Rapids
c3-standard-176 176 704 Intel Sapphire Rapids
C3 standard bare metal machine types
c3-standard-192-metal 192 768 Intel Sapphire Rapids
C3 high-memory bare metal machine types
c3-highmem-192-metal 192 1,536 Intel Sapphire Rapids
C3D high-memory machine types
c3d-highmem-4 4 32 Not applicable (N/A)
c3d-highmem-8 8 64 N/A
c3d-highmem-16 16 128 N/A
c3d-highmem-30 30 240 N/A
c3d-highmem-60 60 480 N/A
c3d-highmem-90 90 720 N/A
c3d-highmem-180 180 1440 N/A
C3 standard machine types

c3d-standard-4

 4 16 N/A

c3d-standard-8

 8 32 N/A

c3d-standard-16

 16 64 N/A

c3d-standard-30

 30 120 N/A
c3d-standard-60 60 240 N/A
c3d-standard-90 90 360 N/A
c3d-standard-180 180 720 N/A
O2 Bare Metal Solution machine types
o2-standard-16-metal 16 192 GiB Intel Cascade Lake
o2-standard-32-metal 32 384 GiB Intel Xeon Gold
o2-standard-48-metal 48 768 GiB Intel Xeon Gold
o2-standard-112-metal 112 1,532 GiB Intel Xeon Platinum
o2-highmem-224-metal 224 3 TiB Intel Xeon Platinum

Regional availability of SAP-certified Bare Metal Solution machines

The Bare Metal Solution machines that are certified for SAP applications are available only in Bare Metal Solution region extensions, which are not available for every Google Cloud region. For the full list of regions that have a Bare Metal Solution region extension, see Bare Metal Solution regional availability.

For the availability of Bare Metal Solution machines that are certified for SAP HANA, see Regional availability of Bare Metal Solution machines for SAP HANA.

Images

When you create a Compute Engine VM, you use an image that contains the base components you require. For example, an image can contain a Microsoft Windows Server operating system with a SQL Server installation.

When you order a Bare Metal Solution machine, you also specify the operating system that you need. The machine becomes available with the operating system already installed.

For VMs, there are several ways that you can specify an image. You can:

  • Use the Terraform configuration file (recommended) or the Cloud Deployment Manager template, provided by Google Cloud, that is designed to make setting up SAP NetWeaver easier. For details about how to use Terraform or Cloud Deployment Manager, see the SAP NetWeaver on Google Cloud deployment guide for your operating system.
  • Use a public image. Google provides a variety of public images. You must choose an image that contains components that are supported for SAP NetWeaver.
  • Create your own custom image. You might want to set up your own base system from scratch and create a custom image that you can reuse. You can also create an image by importing an existing boot disk to Compute Engine.

Supported public images

Compute Engine provides public images for supported operating system versions in image families.

To see the available versions in each image family, see the operating system details:

For more information about the support status of the operating system versions that are certified for SAP, see OS support for SAP NetWeaver on Google Cloud.

Planning for image management

After your system is up and running, you can create custom images. Create custom images when you modify the state of your root persistent disk so you can easily restore the new state if needed. Plan for the management of the custom images you create. For more information, see Image Management Best Practices.

Plan regions and zones

When you deploy a VM, you must choose a region and a zone.

Regions are independent geographic areas that consist of zones. Zones and regions are logical abstractions of underlying physical resources. A region consists of three or more zones housed in three or more physical data centers. The regions Mexico, Osaka, and Montreal have three zones housed in one or two physical data centers. These regions are in the process of expanding to at least three physical data centers. When you architect your solutions in Google Cloud, consider the guidance in Cloud locations, Google Cloud Platform SLAs, and the appropriate Google Cloud product documentation.

Global resources, such as pre-configured disk images and disk snapshots, can be accessed across regions and zones. Regional resources, such as regional static external IP addresses, can only be accessed by resources that are in the same region. Zonal resources, such as VMs and disks, can only be accessed by resources that are located in the same zone. For more information, see Global, regional, and zonal resources.

Google Cloud regions and zones.

When you choose a region and zone for your VMs, consider the following:

  • The location of your users and your internal resources, such as your data center or corporate network. To decrease latency, select a location that is in close proximity to your users and resources.
  • The CPU platforms that are available for that region and zone. For example, Intel's Broadwell, Haswell, Skylake, and Ice Lake processors are supported for workloads of SAP NetWeaver on Google Cloud.
  • Ensure that your SAP Application Server and your database are in the same region.

Deploying VMs

You can use the standard Google Cloud methods to deploy your VMs on Compute Engine: the Google Cloud console, the Google Cloud CLI, Deployment Manager, and the REST API. The following pages provide generally useful information about how to deploy VMs:

For detailed information and instructions about deploying your SAP NetWeaver system on Compute Engine VMs, see the following:

Automation for SAP NetWeaver deployments

Google Cloud provides Terraform configuration files and Deployment Manager templates that you can use to automate the deployment of Google Cloud infrastructure for SAP NetWeaver with either a Linux or Windows operating system.

The provided templates instantiate the following resources for SAP NetWeaver:

  • An instance of the machine type of your choice.
  • Your choice of the following operating systems:
    • Red Hat Enterprise Linux (RHEL)
    • SUSE Linux Enterprise Server (SLES)
    • Windows Server
  • Compute Engine standard persistent disks.
  • For Linux, the template instantiates the XFS file system.

For automated deployment instructions, see:

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.

Accessing VMs

The creator of a VM has full root-privileges.

  • On a Linux-based VM, the creator has SSH capability and can use the Google Cloud console to grant SSH capability to other users.
  • On a Windows-based VM, the creator can use the Google Cloud console to generate a username and password; after that, anyone who knows the username and password can connect to the VM using RDP.

After a user with administrative privileges has connected to an instance through SSH or RDP, they can add other system users with standard Linux commands or Windows user-account management. The following pages provide generally useful information about connecting to Compute Engine VMs:

If you use Linux instances, then you need to plan for how you use SSH keys. In general, Compute Engine manages SSH keys for you. You can decide to manage your own SSH keys, but you need to understand the associated risks. For details, see SSH Keys.

For details and instructions about how to connect to Compute Engine VMs in your SAP NetWeaver deployment, see the SAP NetWeaver Deployment Guide for your operating system:

Databases

You can use the following database management systems with SAP NetWeaver on Google Cloud:

  • SAP HANA on Linux.
  • SAP ASE on Linux or Windows.
  • SAP MaxDB on Linux or Windows.
  • IBM Db2 on Linux or Windows.
  • Microsoft SQL Server Enterprise on Windows.
  • Oracle on Bare Metal Solution servers with operating systems that Bare Metal Solution for Oracle supports. For more information, see Operating systems.

SAP HANA

SAP HANA is certified to run in Google Cloud on the following Linux operating systems:

For more information on supported machine types and operating systems, see the SAP HANA planning guide.

For more information about SAP HANA, see the SAP HANA operations guide and the SAP documentation.

To determine the sizing guidelines and recommendations for SAP HANA, see the SAP benchmark sizing page.

SAP ASE

SAP ASE on Google Cloud is supported on the following operating systems:

For more information on supported machine types and operating systems, see the SAP ASE planning guide.

To deploy SAP ASE on Google Cloud, see the ASE deployment guide for your operating system:

For more information about SAP ASE, see the SAP documentation.

SAP MaxDB

SAP MaxDB on Google Cloud is supported on the following operating systems:

For more information on supported machine types and operating systems, see the SAP MaxDB planning guide. To deploy SAP MaxDB on Google Cloud, see the SAP MaxDB deployment guide for your operating system:

For more information about SAP MaxDB, see the SAP MaxDB Library.

IBM Db2 for Linux, UNIX and Windows

IBM Db2 is supported on SLES, RHEL, and Windows Server.

For more information on supported machine types and operating systems, see the IBM Db2 for SAP Planning Guide.

To deploy IBM Db2 on Google Cloud, see:

For more information about IBM Db2, see SAP on IBM Db2 for Linux, UNIX and Windows.

Microsoft SQL Server

You can install SQL Server in several ways:

  • You can use a public image provided by Google with SQL Server Enterprise. The SQL Server in Windows Server image is a premium image, which means that the image cost is bundled with the machine type cost.
  • You can download the SQL Server DVD from SAP, and use the SAP-specific script SQL4SAP.bat that installs SQL Server with the correct settings.
  • You can download the SQL Server DVD either from SAP or Microsoft and use the standard Microsoft setup.exe to install SQL Server so that you can customize your setup.

If you use SQL Server as your database, you must ensure that SQL Server is configured to use the SAP collation, SQL_Latin1_General_CP850_BIN2, for compatibility with SAP systems.

You can confirm the collation of your SQL Server in your server properties:

SQL Server dialog showing collation setting

If you have already configured your SQL Server, then you can update the collation, but you need to recreate the databases afterwards. For more details on how to specify or change the collation, see the SAP NetWeaver on Windows Deployment Guide.

Oracle

SAP on Oracle is supported only on Bare Metal Solution servers, which run in a regional extension that is co-located and connected to select Google Cloud regions.

For more information, see:

Database backup and recovery

You must have a plan for how to restore your system to operating condition if the worst happens. For general guidance about how to plan for disaster recovery using Google Cloud, see:

For information about SAP HANA backup and recovery, see the SAP HANA on Google Cloud Operations Guide.

For information about SAP ASE backup and recovery, see SAP ASE Performance and Tuning Series: Physical Database Tuning.

For information about SAP MaxDB backup and recovery, see SAP MaxDB Database Administration.

For information about IBM Db2 backup and recovery, see Backup and Recovery.

As an alternative to native disaster recovery options, for cross-region active-passive disaster recovery (DR), you can use PD Async Replication. PD Async Replication provides asynchronous replication of data between two Google Cloud regions.

Storage

By default, each Compute Engine VM has a small root persistent disk that contains the operating system. You can add additional disks to your VMs to act as storage for the different components of your system.

Persistent disk storage

For persistent block storage, you can attach Persistent Disk and Hyperdisk volumes to your Compute Engine VMs.

Compute Engine offers different types of Persistent Disk and Hyperdisk. Each type has different performance characteristics. Google Cloud manages the underlying hardware of these disks to ensure data redundancy, and to optimize performance.

With SAP NetWeaver, you can use any of the following Persistent Disk or Hyperdisk types:

  • Persistent Disk types: Standard (pd-standard), Balanced (pd-balanced), Performance or SSD (pd-ssd), and Extreme (pd-extreme)
    • Standard Persistent Disk is backed by standard hard-disk drives (HDD). Disks of this type 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).
    • Balanced, Performance or SSD (pd-ssd), and Extreme Persistent Disk types are backed by solid-state drives (SSD). These disk types provide cost-effective and reliable block storage.
    • Performance (SSD) Persistent Disk provides higher performance than Balanced Persistent Disk.
    • 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 PD Async Replication.
    • While you can use Extreme Persistent Disk (pd-extreme) with your SAP applications, we recommend that you instead use Hyperdisk volumes, which provide greater performance. For information about the machine types that support using Extreme Persistent Disk, see Machine shape support.
  • Hyperdisk types: Hyperdisk Balanced (hyperdisk-balanced) and Hyperdisk Extreme (hyperdisk-extreme)
    • Hyperdisk Extreme provides higher maximum IOPS and throughput options than Persistent Disk types.
    • 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.
    • For information about the machine types that support using Hyperdisk, see Machine type support.
The performance of SSD and Balanced Persistent Disk volumes scale automatically with size. Therefore, you can adjust performance by resizing your existing Persistent Disk volumes or adding more Persistent Disk volumes to a VM. The performance of Extreme Persistent Disk volumes is not affected by size.

The type of VM you are using and the number of vCPUs it contains can also affect or limit persistent disk performance.

The following figure shows approximate performance numbers for Balanced Persistent Disk volumes in an example SAP NetWeaver configuration on Google Cloud. The actual numbers you might see in a similar configuration are likely to differ for a variety of reasons, including improvements made by Compute Engine over time.

Two balanced persistent disks, one 80 GB and the other 250 GB, are attached to an n2-standard-32 host VM that is running SAP NetWeaver

As indicated in the preceding figure, when the Persistent Disk volumes are of the same type, such as SSD or Balanced, then the performance that they provide to the VM is cumulative. Therefore, you can estimate the overall performance by adding the performance numbers of each Persistent Disk volume.

For example, if you attach two Balanced Persistent Disk volumes as shown in the figure, one that provides 180 IOPS for read and write, and throughput of 8.4 MB per second, and the other that provides 1,500 IOPS for reads and writes and 70 MB per second of throughput, then together the two Balanced Persistent Disk volumes provide 1,680 IOPS for reads and writes and 78.4 MB per second of throughput. For more information, see the "Multiple disks attached to a single VM instance" and "Simultaneous reads and writes" sections in Factors that affect disk performance.

Persistent Disk and Hyperdisk volumes are located independently from your VMs, so you can detach or move the disks to keep your data, even after you delete your VMs.

In the VM instances page of the Google Cloud console, you can see the disks 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 block storage offered by Compute Engine, their performance characteristics, and how to work with them, see the Compute Engine documentation:

Persistent disks deployed by the deployment templates

If you deploy the host VM by using the Terraform configuration files or Cloud Deployment Manager templates that Google Cloud provides for SAP NetWeaver, then the deployment automation scripts attach two or three standard persistent disks for the required volumes or drives, depending on whether you are using Windows Server or Linux.

File sharing solutions

Several file sharing solutions are available on Google Cloud, including the following:

  • Filestore
  • NetApp Cloud Volumes ONTAP
  • NetApp Cloud Volumes Service for Google Cloud

To determine which solution is best for your deployment scenario, see File sharing solutions for SAP on Google Cloud.

Local SSD (non-persistent)

Google Cloud offers local SSD disk drives. Although local SSDs can offer some advantages over persistent disks, don't use them as part of an SAP NetWeaver system. VM instances with local SSDs attached cannot be stopped and then restarted.

Using Cloud Storage for object storage

Cloud Storage is an object store for files of any type or format; it has virtually unlimited storage, and you do not have to worry about provisioning it or adding more capacity. An object in Cloud Storage contains file data and its associated metadata, and can be up to 5 terabytes in size. A Cloud Storage bucket can store any number of objects.

It's common practice to use Cloud Storage to store backup files for nearly any purpose. For example, for SAP HANA backups, Cloud Storage is a good place to store the files. For database backup planning, refer to the resources in Database backup and recovery. You can also use Cloud Storage as part of a migration process.

Choose your Cloud Storage option based on how frequently you need to access the data. For frequent access multiple times a month, select the Standard storage class. For infrequent access, select Nearline or Coldline storage. For archival data you don't expect to access, select Archive storage.

When you plan your storage options, start with the frequently accessed tier and age your backup data to the infrequent access tiers, because backups are rarely used as they become older. The probability of needing a backup that is 3 years old is extremely low, and you can age this backup into the Archive tier to optimize costs.

For a more detailed comparison, see Storage Classes. To learn about the different storage options available, see Choosing a Storage Option.

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.

Networking and network security

Consider the information in the following sections when planning networking and network security.

Minimum privilege model

One of your first lines of defense is to restrict who can reach your network and your VMs by using firewalls. By default, all traffic to VMs, even from other VMs, is blocked by the firewall unless you create rules to allow access. The exception is the default network that is created automatically with each project and has default firewall rules.

By creating firewall rules, you can restrict all traffic on a given set of ports to specific source IP addresses. Follow the minimum privilege model in order to restrict access to the specific IP addresses, protocols, and ports that need access. For example, always set up a bastion host and allow SSH into your SAP NetWeaver system only from that host.

Custom networks and firewall rules

You can use a network to define a gateway IP and the network range for the VMs attached to that network. All Compute Engine networks use the IPv4 protocol. Every Google Cloud project is provided with a default network with preset configurations and firewall rules, but you should add a custom subnetwork and add firewall rules based on a minimum privilege model. By default, a newly created network has no firewall rules and hence no network access.

You might want to add more than one subnetwork, if you want to isolate parts of your network, and depending on your requirements. For more information, see Subnetworks.

The firewall rules apply to the entire network and all the VMs in the network. You can add a firewall rule that allows traffic between VMs in the same network and across subnetworks. You can also configure firewalls to apply to specific target VMs by using the tagging mechanism.

SAP requires access to certain ports, so add firewall rules to allow access to the ports outlined by SAP.

Routes

Routes are global resources attached to a single network. User-created routes apply to all VMs in a network. This means you can add a route that forwards traffic from VM to VM within the same network and across subnetworks without requiring external IP addresses.

For external access to internet resources, launch a VM with no external IP address and configure another virtual machine as a NAT gateway. This configuration requires you to add your NAT gateway as a route for your SAP instance.

Using bastion hosts and NAT gateways

If your security policy requires truly internal VMs, you need to set up a NAT proxy manually on your network and a corresponding route so that VMs can reach the internet. It is important to note that you cannot connect to a fully internal VM instance directly by using SSH. To connect to such internal machines, you must set up a bastion instance that has an external IP address and then tunnel through it. When VMs do not have external IP addresses, they can only be reached by other VMs on the network, or through a managed VPN gateway. You can provision VMs in your network to act as trusted relays for inbound connections, called bastion hosts, or network egress, called NAT gateways. For more transparent connectivity without setting up such connections, you can use a managed VPN gateway resource.

Using bastion hosts for inbound connections

Bastion hosts provide an external facing point of entry into a network containing private-network VMs. This host can provide a single point of fortification or audit and can be started and stopped to enable or disable inbound SSH communication from the internet.

Bastion host show in SSH scenario

SSH access to VMs that do not have an external IP address can be achieved by first connecting to a bastion host. A complete hardening of a bastion host is outside the scope of this article, but some initial steps taken can include:

  • Limit the CIDR range of source IPs that can communicate with the bastion.
  • Configure firewall rules to allow SSH traffic to private VMs from only the bastion host.

By default, SSH on VMs is configured to use private keys for authentication. When using a bastion host, you log into the bastion host first, and then into your target private VM. Due to this two-step login, you should use SSH-agent forwarding to reach the target VM instead of storing the target VM's private key on the bastion host. You must do this even if you are using the same key-pair for both bastion and target VMs, as the bastion has direct access only to the public half of the key-pair.

Using NAT gateways for traffic egress

When a VM does not have an assigned, external IP address, it cannot make direct connections to external services, including other Google Cloud services. To allow these VMs to reach services on the internet, you can set up and configure a NAT gateway. The NAT gateway is a VM that can route traffic on behalf of any other VM on the network. Use one NAT gateway per network. A single-VM NAT gateway is not highly available and cannot support high traffic throughput for multiple VMs. For instructions on how to set up a VM to act as a NAT gateway, see the NetWeaver Deployment Guide for your operating system:

Cloud VPN

You can securely connect your existing network to Google Cloud through a VPN connection that uses IPsec by using Cloud VPN. Traffic traveling between the two networks is encrypted by one VPN gateway, then decrypted by the other VPN gateway. This protects your data as it travels over the internet. You can dynamically control which VMs can send traffic down the VPN using instance tags on routes. Cloud VPN tunnels are billed at a static monthly rate plus standard egress charges. Note that connecting two networks in the same project still incurs standard egress charges. For more information, see:

Securing a Cloud Storage bucket

If you use Cloud Storage to host your backups for your data and log, make sure you use TLS (HTTPS) while sending data to Cloud Storage from your VMs to protect data in transit. Cloud Storage automatically encrypts data at rest. You can specify your own encryption keys if you have your own key-management system.

Sending email

To help protect your systems and Google's from abuse, Google Cloud enforces limitations for sending email from Compute Engine. For more information, see Sending email from an instance.

Refer to the following additional security resources for your SAP environment on Google Cloud:

Monitoring

For support and monitoring, Google Cloud provides the Agent for SAP, for SAP workloads running on Compute Engine instances and Bare Metal Solution servers.

As mandated by SAP, to get support from SAP and to enable SAP to meet its service-level agreements (SLAs), you must install Google Cloud's Agent for SAP on all Compute Engine instances and Bare Metal Solution servers that run any SAP system. For more information on the support prerequisites, see SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites .

Version 3.6 (latest) of Google Cloud's Agent for SAP is the successor of Google Cloud's monitoring agent for SAP NetWeaver version 2, monitoring agent for SAP HANA version 2, and the Cloud Storage Backint agent for SAP HANA. Therefore, in addition to the collection of metrics, version 3.6 (latest) of Google Cloud's Agent for SAP includes the optional feature: Backint based backup and recovery for SAP HANA. You can opt in to these features that enable products and services such as Workload Manager for your SAP workloads.

You install Google Cloud's Agent for SAP on the host alongside the SAP system. For instructions about how to install and configure the agent, validate your installation, and verify that the agent is running as expected, see Install the agent on a Compute Engine instance.

If you use the following RHEL or SLES "for SAP" OS images that Google Cloud provides, then Google Cloud's Agent for SAP is packaged with the OS images:

  • RHEL: all "for SAP" images
  • SLES: SLES 15 SP4 for SAP and later versions

Scale-out of SAP NetWeaver application servers

SAP supports a scale-out architecture that uses multiple application servers, which supports a higher workload.

If you are using Windows Server as your operating system, you can use Active Directory running on a VM as a domain controller. For more information, see Setting up Active Directory on Google Compute Engine. Alternatively, you can connect Compute Engine VMs to your on-premises Active Directory domain controller using VPN.

In scale-out configuration, nodes must access a shared file system. For Windows Server, specify where the shared file system is mounted during installation through the SAP installer. For Linux, use the Network File System (NFS) as your fileshare on the NetWeaver binaries/profiles disk of the central system (/sapmnt/[SID], where [SID] is the system ID). See the SAP documentation for details.

For information about the file sharing solutions available on Google Cloud for SAP NetWeaver, see File sharing solutions.

Migrating an existing SAP NetWeaver system

By migrating an existing SAP NetWeaver landscape, you can leverage your investment in your existing setup in the cloud. Migrating a system of any significant scale requires careful planning and step-by-step migration, to avoid losing consistency between the system components.

For migrations, follow SAP standard migration practices. SAP recommends following their best practices for copying components from your source system to a newly created target system. When the source and target systems use the same OS and database system, use homogeneous system copy, and when the source and target systems use a different OS or database system, use heterogeneous system copy.

Licensing

This section provides information about licensing requirements.

SAP Licensing

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

See the following SAP Notes:

For more information from SAP about managing your SAP NetWeaver licenses, see SAP Licensing Procedure.

Microsoft Windows Server and SQL Server

In Compute Engine, there are two ways to license Microsoft software:

  • With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics with Microsoft. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for Google Cloud public images that include Windows Server, with or without SQL Server.

  • With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility. However, with very stable usage needs, or with no-charge or discounted licensing through Microsoft licensing agreements, this approach might be less expensive.

Microsoft's terms for migrating licenses are different for Windows Server and SQL Server. For full details about BYOL on Google Cloud, see Using Existing Microsoft Application Licenses.

For information about SAP license restrictions for SQL Server, see SAP Note 2139358.

Linux

In Compute Engine, there are two ways to license SLES or RHEL:

  • With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for Google Cloud public images that include SLES or RHEL.

  • With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility.

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:

What's next