SAP NetWeaver Operations Guide

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 Platform (GCP) 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 GCP Planning Guide and the SAP NetWeaver Master Guide.
• To learn how to deploy and prepare GCP resources for an SAP NetWeaver system, see the deployment guide for your operating system:
  • SAP NetWeaver on Linux Deployment Guide
  • SAP NetWeaver on Windows Deployment Guide

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.

Note: The private IP associated with the instance is not released after you stop the instance, so when you start the instance again, it will start with the same private IP address, network, and storage configuration as before.

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:

1. In the Google Cloud Platform Console, navigate to the:

   VM INSTANCES PAGE

2. Select one or more instances that you want to stop.

3. At the top of the VM instances page, click Stop.

For alternatives and more information, see Stopping an instance.

Restarting a VM

To restart a VM:

1. In the GCP Console, navigate to the:

   VM INSTANCES PAGE

2. Select the instances that you want to restart.

3. At the top right-hand of the page, click the Start button to restart the instances.

For alternatives and more information, see Restarting an instance.

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.

Using snapshots

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:

Use case	Details
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 GCP, follow the standard SAP export-import procedure:

1. Use the Software Provisioning Manager (SWPM) to export the source system.
2. Copy the data from the system and database export to your Cloud Storage bucket.
3. 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.

Creating images

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.

Important: Creating an image is a destructive operation with regards to the source VM, so this is not something you would normally do in your live, production system.

When you followed the SAP NetWeaver on GCP 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 GCP 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.

Database operations

This section provides resources for managing the following database servers on GCP:

• 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 GCP, see the SAP HANA on GCP 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 GCP:

Resource	Description
Best Practices for Microsoft SQL Server	Learn how to configure Microsoft SQL Server for stability and performance on Compute Engine. Note the following important differences in best practices for SAP systems: Do not use local SSD drives. Use persistent disk SSDs, instead. For parallel query processing, set the max degree of parallelism to 1, not 8. The transaction log setting must be "FULL" for Microsoft SQL Server databases in production systems. Do not use the buffer pool extension feature.
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 GCP.

IAM operations

Controlling access to GCP resources is a critical part of securing and operating your deployment. While SAP provides its own user-management system, GCP's Cloud Identity and Access Management (Cloud IAM) provides unified control over permissions for GCP 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 Cloud 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

GCP'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. For details, see Service Accounts.

For instructions about how to manage service accounts, see Creating and Enabling Service Accounts for Instances.

Using Stackdriver Logging

Stackdriver Logging is GCP's solution for system-wide logging. Stackdriver Logging allows you to store, search, analyze, monitor, and alert on log data and events. Using Stackdriver Logging requires that you have installed the Stackdriver 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.

Access control

Stackdriver logging provides granular access control to logs and logging operations. For details, see the Access Control Guide.

Audit logging

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

Managing Google's 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. GCP provides its own monitoring system, Stackdriver Monitoring, to collect metrics, events, and metadata. As you implement and operate SAP NetWeaver on GCP, 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 GCP.

Note: You must deploy Google's monitoring agent to get support from SAP to and to enable SAP to meet its service-level agreements (SLAs).

Understanding the monitoring agent lifecycle

When managing monitoring operations, it's helpful to understand what Google's monitoring agent is doing. In general, here's how it works:

• Stackdriver Monitoring has a local agent that collects metrics, events, and metadata from GCP. Compute Engine also provides APIs that provide monitoring functionality.
• Each VM in your deployment must host an instance of Google's monitoring agent for SAP NetWeaver. The monitoring agent runs as a Windows service or a Linux process.
• The monitoring agent combines monitoring data from Stackdriver Monitoring and the Compute Engine APIs.
• The SAP Host Agent polls Google's 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 ST06 or the SAPOSCOL command line interface displays the aggregated metrics.
• You can view the data from Google's 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 cron jobs 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.

Warning: Do not delete these cron entries. They are required for the continuous operation of Google's monitoring agent.

• To view these cron entries:

  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.

Warning: Do not manually stop the monitoring system's Windows service, or delete the Task Scheduler task.

Installing Google's monitoring agent

You can install the monitoring agent by downloading and running the script from the following public Cloud Storage bucket:

• For Linux
• For Windows

If you didn't install Google's monitoring agent while creating your VM, you can install the agent in the following ways:

Linux

• When you launch the VM, provide the start-up script to install the agent. For example:

  curl -s https://storage.googleapis.com/sap-netweaver-on-gcp/setupagent_linux.sh | bash
  

• If your VM is running, you can sign in to the machine and run the script as root. For example:

  sudo su -; curl -s https://storage.googleapis.com/sap-netweaver-on-gcp/setupagent_linux.sh | bash
  

Windows

• If your VM is running, you can sign in to the machine and run the script as admin, For example:

  . { iwr -useb https://storage.googleapis.com/sap-netweaver-on-gcp/installer.ps1 } | iex
  

The remainder of this section provides details about managing Google's monitoring agent.

Adminstering Google's monitoring agent

This section describes actions you can take to keep the monitoring agent working properly.

Verifying that Google's monitoring agent is running

Google's 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:

Linux

1. In the GCP Console, open Cloud Shell.

   OPEN CLOUD SHELL

2. Connect to the VM instance you want to monitor. For information about how to connect to your VM, see the SAP NetWeaver on Linux Deployment Guide.

3. At the command prompt, enter the following command:

   curl http://localhost:18181/health
   

Windows

1. Use RDP to connect to the VM instance you want to monitor.
2. In a browser, visit http://localhost:18181/health.

If the monitoring agent is functioning properly, the status is UP. For example:

{"status":"UP","diskSpace":{"status":"UP","total":105552769024,"free":103920615424f,"threshold":10485760}}

If the monitoring agent isn't running, see Restarting Google's monitoring agent.

Verifying that SAP NetWeaver is receiving metrics

To check whether the connection between Google's 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 infrastructure:

• Cloud Provider: "Google Cloud Platform"
• Enhanced Monitoring Access: "TRUE"
• Enhanced Monitoring Details: "ACTIVE"

Viewing Google's monitoring agent's data cache

You can view the monitoring agent's activity by polling the server. Follow these steps:

Linux

1. In the GCP Console, open Cloud Shell.

   OPEN Cloud Shell

2. Connect to the VM instance you want to monitor.

3. At the command prompt, enter the following command:

   curl http://localhost:18181
   

Windows

1. Use RDP to connect to the VM instance you want to monitor.
2. In a browser, visit http://localhost:18181.

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 Google's monitoring agent

If the monitoring agent stops working, follow these steps to restart:

Linux

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.

Windows

You should monitor the log for the monitoring agent, named C:\Program 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 GCP

This section describes issues you can investigate if the monitoring agent isn't working.

Firewall blocks access to the network

Google's monitoring agent 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:

1. In the Google Cloud Platform Console, go to Firewall rules.

   GO TO THE FIREWALL RULES PAGE

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

Out-of-memory condition

Check the logs available for the agent:

• For Linux: /var/log/gcp-metric-provider/gcp-metric-provider.log.
• For Windows: C:\Program Files\Google\GCP Metrics Provider\Logs\gcp-metric-provider.log

If the logs contain an OutOfMemoryError entry, restart the agent.

Wrong scopes for the default service account

Google's monitoring agent uses the Compute Engine default service account as its identity when calling Stackdriver Monitoring. The monitoring agent is hosted on a VM instance and the VM instance requires certain access scopes for the related APIs. Reporting of metrics by the monitoring agent won't work if the host VM doesn't have permissions for the proper access scopes.

It is a best practice to grant permissions for only the required access scopes. Here is the list of access scopes required by the monitoring agent's host VM:

• https://www.googleapis.com/auth/source.read_write
• https://www.googleapis.com/auth/compute
• https://www.googleapis.com/auth/servicecontrol
• https://www.googleapis.com/auth/service.management.readonly
• https://www.googleapis.com/auth/logging.admin
• https://www.googleapis.com/auth/monitoring
• https://www.googleapis.com/auth/trace.append
• https://www.googleapis.com/auth/devstorage.full_control

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 Google's monitoring agent 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:

• SAP NetWeaver on Linux Deployment Guide
• SAP NetWeaver on Windows Deployment Guide

Port not available

Google's 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. You might need to restart whatever other service is using port 18181 in order to free the port.