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 best practices for enterprise organizations.
Interacting with Google Cloud
Google Cloud offers three main ways to interact with the platform, and your resources, in the cloud:
- The Google Cloud Console, which is a web-based user interface.
gcloudcommand-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
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.
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:
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. The Google monitoring agent aggregates metrics from Cloud Monitoring, which is 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.
The following diagram shows some details of a 2-tier architecture running on Compute Engine.
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.
The following diagram shows some details of a 3-tier architecture running on Compute Engine.
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.
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.
You can use the following Compute Engine machine types with SAP NetWeaver:
- C1 compute-optimized machine types
- M1-ultramem machine types
- N1 general-purpose machine types
- N2 general-purpose machine types
- N2D general-purpose machine types
- Custom N1- or N2-based 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|
||4||16||Intel Cascade Lake||5,189|
||8||32||Intel Cascade Lake||10,750|
||16||64||Intel Cascade Lake||20,731|
||30||120||Intel Cascade Lake||36,405|
||60||240||Intel Cascade Lake||70,683|
|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||1 or any even number up to 96||4.0 GB per vCPU for standard memory usage or 8.0 GB per vCPU for high memory usage.||Intel Cascade Lake|
|M1 memory-optimized machine types|
|N1 high-memory, general-purpose machine types|
|N1 general-purpose machine types|
|N2 high-memory, general-purpose machine types|
||2||16||Intel Cascade Lake||2,230|
||4||32||Intel Cascade Lake||5,150|
||8||64||Intel Cascade Lake||10,130|
||16||128||Intel Cascade Lake||19,370|
||32||256||Intel Cascade Lake||35,580|
||48||384||Intel Cascade Lake||54,680|
||64||512||Intel Cascade Lake||70,520|
||80||640||Intel Cascade Lake||82,250|
|N2 general-purpose machine types|
||4||16||Intel Cascade Lake||4,730|
||8||32||Intel Cascade Lake||10,270|
||16||64||Intel Cascade Lake||19,320|
||32||128||Intel Cascade Lake||35,730|
||48||192||Intel Cascade Lake||52,980|
||64||256||Intel Cascade Lake||69,450|
||80||320||Intel Cascade Lake||81,870|
|N2D high-memory, general-purpose machine types|
||2||16||AMD EPYC Rome||3,111|
||4||32||AMD EPYC Rome||6,223|
||8||64||AMD EPYC Rome||12,445|
||16||128||AMD EPYC Rome||24,890|
||32||256||AMD EPYC Rome||49,780|
|N2D general-purpose machine types|
||2||8||AMD EPYC Rome||3,088|
||4||16||AMD EPYC Rome||6,175|
||8||32||AMD EPYC Rome||12,350|
||16||64||AMD EPYC Rome||24,700|
||32||128||AMD EPYC Rome||49,400|
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.
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 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:
These image families contain supported SLES images:
These image families contain supported Windows Server images:
SQL Server Enterprise
These image families contain supported Windows Server with SQL Server Enterprise images:
For more information about the support status of an operating system version, see OS 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.
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.
- For more information, see SAP Note 2456432: SAP Applications on Google Cloud Platform: Supported Products and Google VM types.
- For details about which regions the Haswell, Broadwell, and Skylake processors are available for use with Compute Engine, see Regions and Zones.
That your SAP AS and your database must be in the same region.
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,
Deployment Manager, and the REST API.
The following pages provide generally useful information about how to deploy
For detailed information and instructions about deploying your SAP NetWeaver system on Compute engine, see the NetWeaver Deployment Guide for your operating system:
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:
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 is certified to run in Google Cloud on the following Linux operating systems:
- Red Hat Enterprise Linux (RHEL) for SAP HANA 7.3 and 7.4
- SUSE Linux Enterprise Server (SLES) 12 SP1 and SP2
- SUSE Linux Enterprise Server (SLES) for SAP 12 SP1 and SP2
For more information on supported VM types and operating systems, see the SAP HANA planning guide.
To determine the sizing guidelines and recommendations for SAP HANA, see the SAP benchmark sizing page.
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 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.batthat installs SQL Server with the correct settings.
- You can download the SQL Server DVD either from SAP or Microsoft and use the
setup.exeto 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
SQL_Latin1_General_CP850_BIN2, for compatibility with SAP systems.
You can confirm the collation of your SQL Server in your server properties:
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.
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 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 834 GB for your database data, you can attain the following maximum sustained throughput:
|Virtual CPUs||Reads (MB/s)||Writes (MB/s)|
|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. 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.
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
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
that is created automatically with each project and has default
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 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.
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:
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.
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.
Related security documents
Refer to the following additional security resources for your SAP environment on Google Cloud:
- Securely Connecting to VM Instances
- Security Center
- Compliance in the Google Cloud
- Google Cloud security whitepaper
- Google Infrastructure security design
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, Cloud 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.
The Google 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.
The Google monitoring agent is available for installation alongside SAP NetWeaver on Google Cloud. For details and instructions about how to install the Google 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
[SID] is the system ID). See
the SAP documentation
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.
This section provides information about licensing requirements.
Running SAP on Google Cloud requires you to bring your own license (BYOL).
See the following SAP Notes:
- 2446441 - Linux on Google Cloud Platform (IaaS): Adaption of your SAP License
- 2456953 - Windows on Google Cloud Platform (IaaS): Adaption of your SAP License
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.
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.
For issues with Google Cloud infrastructure or services, contact Google Cloud Support. You can find contact information on the Support Overview page in the Google Cloud Console. If Google Cloud Support determines that a problem resides in your SAP systems, you are referred to SAP Support.
For SAP product-related issues, log your support request with SAP support. SAP evaluates the support ticket and, if it appears to be a Google Cloud infrastructure issue, transfers the ticket to the Google Cloud component BC-OP-LNX-GOOGLE or BC-OP-NT-GOOGLE.
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:
To complete the tasks necessary for deployment, see the NetWeaver Deployment Guide for your operating system:
For an overview of high-availability SAP NetWeaver systems on Google Cloud, see High-availability planning guide for SAP NetWeaver on GCP.
For an overview of disaster recovery options for SAP NetWeaver systems on Google Cloud, see Disaster recovery planning guide for SAP NetWeaver on GCP.
For more details on administration of VMs and monitoring, see the SAP NetWeaver on Google Cloud Operations Guide.