This guide provides an overview of how to manage IT ops for a running SAP NetWeaver system on Compute Engine. This guide does not cover the specifics of managing the SAP NetWeaver product. Google Cloud is certified for running SAP NetWeaver application servers ABAP and Java, and SAP products based on these application server stacks.
- To learn how to operate your deployment of SAP NetWeaver, see the SAP NetWeaver Master Guide.
- To learn how to plan your deployment of SAP NetWeaver, see the SAP NetWeaver on Google Cloud Planning Guide and the SAP NetWeaver Master Guide.
- To learn how to deploy and prepare Google Cloud resources for an SAP NetWeaver system, see the deployment guide for your operating system:
Managing Compute Engine VM instances
This section shows how to perform administrative tasks typically required to operate SAP NetWeaver on Compute Engine, including information about starting, stopping, and cloning systems.
Managing VM lifetime
This section provides information about how to manage the running state of your Compute Engine VMs.
Maintaining VM availability
Compute Engine offers availability policies that determine how a VM behaves during certain infrastructure-related events. For VM instances in your SAP NetWeaver implementation, it is important that you do not disable the following features:
- Live migrate, which enables Compute Engine to keep your instance running when responding to an infrastructure maintenance event.
- Automatic restart, which enables Compute Engine to restart your instance in the event of an instance crash. Note that the SAP system does not automatically restart.
Stopping a VM
You can stop one or multiple SAP NetWeaver hosts at any time; stopping a VM instance shuts down the instance. If the shutdown doesn't complete within 2 minutes, the instance is forced to halt. As a best practice, you should first stop SAP NetWeaver before you stop the instance.
Stopping a VM causes Compute Engine to send the ACPI power-off signal to the VM instance. After it is stopped, you are not billed for the VM instance.
If you have persistent disks attached to the VM, the disks are not deleted and you continue to be charged for them. If the data in the persistent disk is important, you can either:
- Keep the disk.
- Create a snapshot of the persistent disk and then delete the disk. This option can help you save on costs. You can create another disk from the snapshot when you need the data again.
To stop a VM:
In the Google Cloud Console, navigate to the:
Select one or more instances that you want to stop.
At the top of the VM instances page, click stopSTOP.
For alternatives and more information, see Stopping an instance.
Restarting a VM
To restart a VM:
In the Cloud Console, navigate to the:
Select the instances that you want to restart.
At the top right-hand of the page, click play_arrowSTART.
For alternatives and more information, see Restarting an instance.
Modifying a VM
You can change various attributes of a VM, including the VM type, after the VM is deployed. Some changes might require you to restore your SAP system from backups, while others only require you to restart the VM.
For more information, see Modifying VM configurations for SAP systems.
Capturing system state
This section describes scenarios that require saving the state of your system, and the Compute Engine features that you can use for these purposes.
You can create a snapshot of a persistent disk at any time to generate a point-in-time copy of the disk state. Compute Engine stores multiple copies of each snapshot, across multiple locations, with automatic checksums to ensure the integrity of your data.
Snapshots are useful for the following use cases:
|Migrate to a different type of storage.||You can use snapshots to move a persistent disk from one disk type, standard or SSD, to the other type. See Restoring a snapshot to a different disktype in the Compute Engine documentation.|
|Migrate SAP NetWeaver to another zone.||You can use snapshots to move your SAP NetWeaver system from one zone to another zone in the same region, or even from one region to another region. See Moving VMs between regions and zones.|
|Provide an easy, software-independent, and cost-effective backup solution.||Back up your attached persistent disks by using snapshots. You can back up
your root disk and SAP NetWeaver installed binaries.
Snapshots can be useful for taking backups of your database systems. However, depending on your implementation, you might want to use a different approach. For guidance about how to back up and restore databases, see the guides listed in Database operations.
To obtain a consistent snapshot, you must either stop SAP NetWeaver or stop the database from writing to the file system.
To create a snapshot, follow the Compute Engine instructions for creating snapshots. Pay careful attention to the preparation steps, such as flushing the disk buffers to disk, to make sure that the snapshot is consistent.
Cloning your SAP NetWeaver system
To clone your SAP NetWeaver system on Google Cloud, follow the standard SAP export-import procedure:
- Use the Software Provisioning Manager (SWPM) to export the source system.
- Copy the data from the system and database export to your Cloud Storage bucket.
- Use SWPM to create a new, target system and to import the artifacts that you exported from the source system. You can mount the Cloud Storage bucket as a file system for use by the target system.
To capture the state of a boot disk, you can create a custom image. An image is different from a backup because you use an image to create new VM instances that are based on a single, source VM.
When you followed the SAP NetWeaver on Google Cloud Deployment Guide, you should have created one or more images at the end of the deployment steps. However, you might want to create new images after you make important changes to the system, such as installing an update of SAP NetWeaver binaries or upgrading the SAP NetWeaver version.
For instructions, see:
- Creating, Deleting, and Deprecating Custom Images, for Linux-based systems.
- Creating a Windows image, for Windows-based systems.
Moving VMs between regions and zones
Compute Engine enables you to move VMs between zones in the same region and zones in different regions. You might want to move a VM if, for example, a new region or zone becomes available that would give you better performance, or if a zone becomes deprecated.
The Compute Engine documentation contains detailed instructions about how to move your VM to another zone.
Here are considerations for SAP NetWeaver:
- SAP can run only in certain zones because of machine-type restrictions. See the SAP NetWeaver on Google Cloud Planning Guide for details.
- Migrating the VM causes the VM's ID to change. This change triggers an SAP HW Key change, which requires you to import a new SAP license.
- You can use the same hostname in the new zone, if it isn't already in use. If the hostname changes, you need to use the generic operations feature of SAP's SWPM to run a rename operation to change the SAP NetWeaver hostname.
This section provides resources for managing the following database servers on Google Cloud:
- SAP HANA
- SAP ASE
- IBM Db2 for Linux, UNIX and Windows (IBM Db2)
- Microsoft SQL Server
SAP HANA operations
For more information about running SAP HANA on Google Cloud, see the SAP HANA on Google Cloud Operations Guide. That guide provides you with lots of details about administration, backup and recovery, security, networking, and other topics.
SAP ASE operations
For more information about using SAP ASE, see SAP Adaptive Server Enterprise.
IBM Db2 operations
For more information about using IBM Db2 with SAP, see SAP on IBM Db2 for Linux, UNIX and Windows.
Microsoft SQL Server operations
The following resources provide details about how to run Microsoft SQL Server on Google Cloud:
|Best Practices for Microsoft SQL Server||Learn how to configure Microsoft SQL Server for stability and performance on
Note the following important differences in best practices for SAP systems:
|Microsoft SQL Server Performance Tuning on Compute Engine||Discusses how to create a Microsoft SQL server on Compute Engine and then use metrics to optimize its performance.|
|Load Testing Microsoft SQL Server Using HammerDB||This tutorial shows how to use HammerDB to perform load testing on a Compute Engine Microsoft SQL Server instance.|
|Building a Microsoft SQL Server Disaster Recovery Plan on Compute Engine||Demonstrates how to implement a less-expensive disaster recovery solution for Microsoft SQL Server on Google Cloud.|
Controlling access to Google Cloud resources is a critical part of securing and operating your deployment. While SAP provides its own user-management system, GCP's Identity and Access Management (IAM) provides unified control over permissions for Google Cloud resources. You can manage access control by defining who has what access for resources. For example, you can control who can perform control-plane operations on your SAP instances such as creating and modifying VMs, persistent disks, and networking.
For an overview of IAM in Compute Engine, see Access Control Options.
Managing team members
From time to time, you will want to add or remove team members from your project or change their permission levels. For details about how to manage team members, see Add, Remove Team Members, and Change Permissions.
IAM roles are key to granting permissions to users. For a reference about roles and which permissions they provide, see Identity and Access Management Roles.
Managing SSH keys
By default, Compute Engine automatically manages SSH keys. If you have decided to manage your own SSH keys, you need to add and remove keys from time to time during your normal operations. For detailed steps, see Adding and Removing SSH Keys.
Managing service accounts
IAM's service accounts provide a way for you to give permissions to applications and services. It's important to understand how service accounts work in Compute Engine.
If a service account is assigned to a Compute Engine VM, that service account is the default service account for the applications that run on that VM. Any application that uses the VM service account inherits the IAM roles and permissions that are granted to the VM service account.
For more information, see Identity and access management for SAP programs on Google Cloud.
Using Cloud Logging
Cloud Logging is the Google Cloud solution for system-wide logging. Cloud Logging allows you to store, search, analyze, monitor, and alert on log data and events. Using Cloud Logging requires that you have installed the Cloud Logging agent on each VM.
If you didn't install the agent, you can install it now. See Installing the Agent.
See Compute Engine Logs for details about supported logs.
Cloud Logging provides granular access control to logs and logging operations. For details, see the Access Control Guide.
Cloud Audit Logs provides key information about activities happening in GCP through two log types: Admin Activity and Data Access. You can view the Activity Feed and the Logs Viewer in the Cloud Console.
The Google Cloud monitoring agent for SAP NetWeaver
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 Cloud and SAP worked together to create the Google Cloud monitoring agent for SAP NetWeaver.
Metrics collected by the monitoring agent
The metrics collected by Google Cloud monitoring agent for SAP NetWeaver are determined by SAP. For a description of metrics that the agent collects, see SAP Note 2469354.
Understanding the monitoring agent lifecycle
When managing monitoring operations, it's helpful to understand what the Google Cloud monitoring agent for SAP NetWeaver is doing. In general, here's how it works:
- Cloud Monitoring has a local agent that collects metrics, events, and metadata from Google Cloud. Compute Engine also provides APIs that provide monitoring functionality.
- Each VM in your deployment must host an instance of the Google Cloud monitoring agent for SAP NetWeaver. The monitoring agent runs as a Windows service or a Linux process.
- The monitoring agent for SAP NetWeaver combines monitoring data from Monitoring and the Compute Engine APIs.
- The SAP Host Agent polls the Google Cloud monitoring agent for its cached data, over HTTP. It aggregates the metrics, reports them, and stores them in the SAP NetWeaver database.
- SAP's transaction
ST06or the SAPOSCOL command line interface displays the aggregated metrics.
- You can view the data from the Google Cloud monitoring agent by running a command in a terminal window.
When you install the monitoring agent, the provided start-up script completes the following tasks:
- Downloads the latest version of the monitoring agent.
- Downloads the dependencies, such as the OpenJDK and SIGAR libraries.
In Linux, creates two
cronjobs as root that perform the following tasks:
- Monitors whether the metrics agent is running and restarts the agent if necessary.
- Refreshes the agent when Google updates the metrics agent provider.
To view these
sudo su - crontab -l
In Windows, the monitoring system runs as a Windows service, named "GCP Metrics Provider". The service restarts automatically, when needed. The monitoring system also depends on a Windows Task Scheduler task that runs once a day.
Cloud API access for the Google Cloud monitoring agent
Compute Engine recommends configuring your VM instances to allow full access to all Cloud APIs and using only the IAM permissions of the instance service account to control access to Google Cloud resources. For more information, see Best practices.
If you do limit access to the Cloud APIs, the Google Cloud monitoring agent requires the following minimum Cloud API access scopes on the host VM instance:
- Compute Engine: Read Only
- Stackdriver Monitoring API: Read Only
If you are running SAP NetWeaver on a VM that does not have an external IP address, you must enable Private Google Access on the VM's subnet so that the Google Cloud monitoring agent can access Google APIs and services.
To enable Private Google Access on a subnet, see Configuring Private Google Access.
Installing the Google Cloud monitoring agent
For installation instructions see the deployment guide that applies to your deployment senario:
- Linux deployments
- Windows deployments
Administering the Google Cloud monitoring agent
This section describes actions you can take to keep the monitoring agent working properly.
Verifying that the Google Cloud monitoring agent is running
The Google Cloud monitoring agent is a local HTTP server. You can check whether the monitoring agent is running by polling for a health check from the server. Follow these steps:
- Use RDP to connect to the VM instance you want to monitor.
- In a browser, visit
If the monitoring agent is functioning properly, the status is
If the monitoring agent isn't running, see Restarting the Google Cloud monitoring agent.
Verifying that SAP NetWeaver is receiving metrics
To check whether the connection between the Google Cloud monitoring agent and SAP
NetWeaver works, enter transaction
ST06 in your SAP NetWeaver ABAP System. In
the overview pane, check the availability and content of the following fields
for the correct, end-to-end setup of the SAP and Google monitoring
- Cloud Provider: "Google Cloud Platform"
- Enhanced Monitoring Access: "TRUE"
- Enhanced Monitoring Details: "ACTIVE"
Viewing the Google Cloud monitoring agent's data cache
You can view the monitoring agent's activity by polling the server. Follow these steps:
In the Cloud Console, open Cloud Shell.
Connect to the VM instance you want to monitor.
At the command prompt, enter the following command:
- Use RDP to connect to the VM instance you want to monitor.
- In a browser, visit
You should see output from the monitoring agent logged in the terminal window. Here's an example of a line of output:
<metric category="config" context="host" type="string" unit="none" last-refresh="1491828854808" refresh-interval="0"><name>Hardware Model</name><value>Google</value></metric>
Restarting the Google Cloud monitoring agent
If the monitoring agent stops working, follow these steps to restart:
To restart the agent in Linux, navigate to
/opt/gcpmetricsprovider and run
the following command:
nohup jdk1.8.0_25/jre/bin/java -Djava.library.path="/opt/gcpmetricsprovider/sigar-bin/lib/" -jar ./gcpmetricsprovider-1.0-SNAPSHOT.jar >> provider.log&
This command starts the agent as a background job.
You should monitor the log for the monitoring agent, named
Files\Google\GCP Metrics Provider\Logs\gcp-metric-provider.log, and watch
for potential issues
In Windows, the agent is configured as a Windows service, named "GCP Metrics Provider". The service normally ensures that the agent restarts automatically.
Troubleshooting monitoring of SAP NetWeaver in Google Cloud
This section describes issues you can investigate if the monitoring agent isn't working.
Firewall blocks access to the network
The Google Cloud monitoring agent for SAP NetWeaver uses HTTP as its communication protocol and it requires access to your network through a specific port. If the agent isn't working, follow these steps:
In the Google Cloud Console, go to Firewall rules.
Create a new rule or edit an existing rule to open port 18181.
On Windows-based systems, also ensure that the Windows Firewall doesn't block the monitoring agent from using the port.
Check the logs available for the agent:
- For Linux:
- For Windows:
C:\Program Files\Google\GCP Metrics Provider\Logs\gcp-metric-provider.log
If the logs contain an
OutOfMemoryError entry, restart the
Insufficient IAM permissions
The Google Cloud monitoring agent uses the service account of its host VM
to retrieve Cloud Monitoring metrics. Consequently, the monitoring agent
requires that the host VM have a service account and that the service
account includes the
monitoring.timeSeries.list permission, which is
contained in the predefined Monitoring Viewer role.
If you install the Cloud Monitoring agent, you might need to grant additional IAM permissions to your VM service account, such as the predefined Monitoring Metric Writer role. To confirm the permissions that the Monitoring agent requires, see the Cloud Monitoring documentation:
Wrong access scopes for the VM service account
Access scopes are the legacy method of specifying permissions for your instance.
A best practice is to set the full
cloud-platform access scope on the
instance, then securely limit the service account's API access with
IAM roles. For example:
If you do limit the access scopes of your VM, you must ensure that the host VM has the following access scopes:
To change the access scopes, you need to stop your VM instance, make the changes, and then restart the instance. For instructions, see the Compute Engine documentation. You don't need to make any changes to permissions for IAM roles for this issue.
Missing or incorrect SAP Host Agent
For the monitoring system to work, your SAP NetWeaver system must have the SAP Host Agent installed and the required minimum patch level for the Host Agent. For instructions to install the SAP Host Agent, see the SAP documentation.
For version requirements for the SAP Host Agent, refer to the following SAP Notes:
- Linux: SAP Note 2460297 - SAP on Linux on Google Cloud Platform: Enhanced Monitoring
- Windows: SAP Note 1409604 - Virtualization on Windows: Enhanced Monitoring
VM is not exposed to the Internet
If the VM running the Google Cloud monitoring agent for SAP NetWeaver was created without a public IP address, the monitoring agent cannot be downloaded. For a description about how to set up a NAT gateway that gives the VM outbound access to the internet, see the SAP NetWeaver deployment guide for your operating system:
Port not available
The Google Cloud monitoring listens for requests on port 18181. This port
must be available or the monitoring agent cannot start up. In this case,
the SAP Host Agent logs will show a
Connection Refused error. Make sure port
18181 is available for the monitoring agent. If another service is using
port 18181, you might need to restart the other service or otherwise
reconfigure it so that it uses another port.