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.

GCP basics

GCP consists of many cloud-based services and products. When running SAP products on GCP, 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 GCP 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 GCP, see best practices for enterprise organizations.

Interacting with GCP

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

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 Stackdriver pricing.

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

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 of the hardware you normally use. For example, computers are always virtual machines (VMs), and components such as networks, firewalls, and mass storage are managed as abstractions.
  • 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 VMs and persistent disk drives. 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 a monitoring agent component provided by Google. Google's monitoring agent aggregates metrics from Stackdriver Monitoring, which is Google Cloud's 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 Compute Engine.

2-tier architecture

In this architecture, all the components run on a single VM. The VM has 5 attached disk drives, and each drive serves a specific role. These roles include:

  • Root disk: Contains the operating system for the VM.
  • 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.

The required disk drives for the database server might be different than those shown in the preceding figure depending on which database server you are using.

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.

See the HANA Planning Guide for more information about the deployment architecture for SAP HANA on Google Cloud.

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.

Virtual machines

Google Cloud provides computing resources as VMs, also called VM instances, through Compute Engine. When you run SAP NetWeaver on Google Cloud, you use Compute Engine VMs to:

  • 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 VMs 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's data centers worldwide, and these data centers are organized by region and zone. You learn more in Planning regions and zones.
  • The amount of persistent disk storage and the number of persistent disks. For most VM types, you can attach up to 64 TB of persistent disk storage. Although you can attach up to 128 persistent disks to most VM types, using fewer persistent disks reduces management overhead and can improve performance.

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 GCP machine types and SAPS, see SAP Note 2456432.

The following sections provide further details.

Machine types

You can use any of the following general-purpose, compute-optimized, or custom machine types.

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

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.

Machine Name Virtual CPUs Memory (GB) Minimum CPU platform SAPS
Compute-optimized machine types

c2-standard-4

4 16 Intel Cascade Lake 5,189

c2-standard-8

8 32 Intel Cascade Lake 10,750

c2-standard-16

16 64 Intel Cascade Lake 20,731

c2-standard-30

30 120 Intel Cascade Lake 36,405

c2-standard-60

60 240 Intel Cascade Lake 70,683
Custom general-purpose machines
N1-based custom machineNote 1 or any even number up to 96 3.75 GB per vCPU for standard memory usage or 6.5 GB per vCPU for high memory usage. Intel Broadwell
N2-based custom machineNote Certification pending
N1 high-memory, general-purpose machine types

n1-highmem-2

2 13 Intel Broadwell 1,290

n1-highmem-4

4 26 Intel Broadwell 3,580

n1-highmem-8

8 52 Intel Broadwell 7,550

n1-highmem-16

16 104 Intel Broadwell 14,670

n1-highmem-32

32 208 Intel Broadwell 27,920

n1-highmem-64

64 416 Intel Broadwell 51,372

n1-highmem-96

96 624 Intel Skylake 70,030
N1 general-purpose machine types

n1-standard-8

8 30 Intel Broadwell 7,680

n1-standard-16

16 60 Intel Broadwell 14,620

n1-standard-32

32 120 Intel Broadwell 27,720

n1-standard-64

64 240 Intel Broadwell 50,230

n1-standard-96

96 360 Intel Skylake 68,650
N2 high-memory, general-purpose machine types

n2-highmem-2

2 16 Intel Cascade Lake 2,230

n2-highmem-4

4 32 Intel Cascade Lake 5,150

n2-highmem-8

8 64 Intel Cascade Lake 10,130

n2-highmem-16

16 128 Intel Cascade Lake 19,370

n2-highmem-32

32 256 Intel Cascade Lake 35,580

n2-highmem-48

48 384 Intel Cascade Lake 54,680

n2-highmem-64

64 512 Intel Cascade Lake 70,520

n2-highmem-80

80 640 Intel Cascade Lake 82,250
N2 general-purpose machine types

n2-standard-4

4 16 Intel Cascade Lake 4,730

n2-standard-8

8 32 Intel Cascade Lake 10,270

n2-standard-16

16 64 Intel Cascade Lake 19,320

n2-standard-32

32 128 Intel Cascade Lake 35,730

n2-standard-48

48 192 Intel Cascade Lake 52,980

n2-standard-64

64 256 Intel Cascade Lake 69,450

n2-standard-80

80 320 Intel Cascade Lake 81,870

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. There are several ways you can specify an image for your VMs. You can:

  • Use the Cloud Deployment Manager script, provided by Google, that is designed to make setting up SAP NetWeaver easier. For details about how to use the Cloud Deployment Manager script, 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.

Cloud Deployment Manager templates

Cloud Deployment Manager provides a way to declare a set of Google Cloud resources and then deploy those resources in a consistent, repeatable fashion. For SAP NetWeaver, Google provides Cloud Deployment Manager templates that makes it easier for you to set up a SAP-certified SAP NetWeaver architecture on Google Cloud.

The provided templates instantiate the following resources:

  • VM type of your choice.
  • Windows Server 2012 R2, SUSE Linux Enterprise Server (SLES) 12.1 premium OS, or Red Hat Enterprise Linux (RHEL) 7.
  • Persistent disks for SAP NetWeaver.
  • For Linux, the template instantiates the XFS file system.

Supported public images

You can use public images from the following image families.

Red Hat Linux

These image families contain supported RHEL images:

  • rhel-6
  • rhel-7
  • rhel-7-4-sap
  • rhel-7-6-sap-ha
SUSE Linux

These image families contain supported SLES images:

  • sles-11 (sp4 versions only)
  • sles-12
  • sles-12-sp2-sap
  • sles-12-sp3-sap
Windows Server

These image families contain supported Windows Server images:

  • windows-2016
  • windows-2016-core
  • windows-2012-r2
  • windows-2012-r2-core
SQL Server Enterprise

These image families contain supported Windows Server with SQL Server Enterprise images:

  • sql-ent-2016-win-2016
  • sql-ent-2016-win-2012-r2
  • sql-ent-2014-win-2012-r2
  • sql-ent-2012-win-2012-r2

For more information about the support status of an operating system version, see Operating system support for SAP NetWeaver on GCP.

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.

Planning regions and zones

When you deploy a VM, you must choose a region and zone. A region is a specific geographical location where you can run your resources, and corresponds to a data center location. Each region has one or more zones.

Global resources, such as preconfigured disk images and disk snapshots, can be accessed across regions and zones. Regional resources, such as 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.

Google Cloud regions and zones

When you are choosing a region and zone for your VMs, consider:

  • 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. SAP NetWeaver on Google Cloud is supported for Intel's Broadwell, Haswell, and Skylake processors, for production workloads.

  • That your SAP AS and your database must be in the same region.

Deploying VMs

You can use the standard Google Cloud methods to deploy your VMs on Compute Engine: the Cloud Console web UI, the gcloud command-line tool, Cloud 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, see the NetWeaver Deployment Guide for your operating system:

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 Cloud Console to grant SSH capability to other users.
  • On a Windows-based VM, the creator can use the 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, you need to plan for how you will 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

SAP HANA

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

For more information on supported VM 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 sizing calculator.

SAP ASE

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

For more information on supported VM 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 VM 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 for SLES 12 SP2, RHEL 7.4, and Windows Server 2012 R2 and later. For more information on supported VM types and operating systems, see the IBM Db2 for SAP Planning Guide. To deploy IBM Db2 on Google Cloud, see the IBM Db2 for SAP Deployment Guide.

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, you can update the collation, but you will 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.

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.

For information about creating an SQL Server backup and recovery plan, see Building a Microsoft SQL Server Disaster Recovery Plan on Compute Engine.

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 disks

Persistent disks are durable storage devices that function similarly to the physical disks in a desktop or a server. Google manages the hardware behind these devices to ensure data redundancy and to optimize performance. Persistent disks are available as either standard hard disk drives (HDD) or solid-state drives (SSD). 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).

Persistent disks are located independently from your VMs, so you can detach or move persistent disks to keep your data, even after you delete your VMs. Persistent disk performance scales automatically with size, so you can resize your existing persistent disks or add more persistent disks to a VM to meet your performance and storage space requirements.

Add a persistent disk to your instance when you need reliable and affordable storage with consistent performance characteristics.

If you use an SSD with at least 1.7 terabytes for your database data, you can attain the following maximum sustained throughput:

Virtual CPUs Reads (MB/s) Writes (MB/s)
16 480 240
32 (see note) 800 400

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.

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

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.

For security best practices, see Cloud Storage Security.

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 SAP NetWeaver on Google Cloud

To help you perform tasks such as analyzing system performance and detecting and diagnosing problems early, SAP NetWeaver provides a central monitoring system that collects data about the components and activities system-wide. Google Cloud provides its own monitoring system, Stackdriver Monitoring, to collect metrics, events, and metadata. As you implement and operate SAP NetWeaver on Google Cloud, dealing with two disconnected systems and trying to figure out where the real issues exist can become challenging for support personnel. To make things easier, Google and SAP have worked together to create a monitoring agent for SAP NetWeaver running on Google Cloud.

Google's monitoring agent provides data to the SAP monitoring system. The monitoring agent provides metrics about:

  • CPU, for example, CPU utilization.
  • Storage, for example, disk throughput and latency.
  • Memory, for example, memory consumption.
  • Networks, for example, network bandwidth.
  • Configuration, for example, VM information.

Google's monitoring agent is available for installation alongside SAP NetWeaver on Google Cloud. For details and instructions about how to install Google's monitoring agent, see the NetWeaver Deployment Guide for your operating system:

For details about the monitoring lifecycle and operations, see the SAP NetWeaver on Google Cloud Operations Guide.

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.

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

Google Cloud customers either with a Production Support Role or with Enterprise Support can request assistance with the provisioning and configuration of the Google Cloud resources that are required for SAP systems. Google Cloud Production-level support or Enterprise support is required for support of SAP systems in production environments.

For more information about Google Cloud support options, see Google Cloud 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 queue.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...