Modifying VM configurations for SAP systems

After a VM is deployed and your SAP systems are running, sooner or later you will need to modify the VM configuration. You might need to do this for any number of reasons, including an increase in workload or to increase the size of a backup VM in a disaster recovery scenario.

This page discusses considerations for SAP systems when you modify a VM.

High-level procedure

The detailed steps for modifying a VM are documented in Changing the machine type of a stopped instance, in the Compute Engine documentation.

You can use the Cloud Console, the Cloud SDK gcloud commands, or the Compute Engine API. Regardless of which interface you use to modify your VM, the high-level steps that you follow are generally the same:

  1. Back up your SAP system.

  2. Stop your SAP system.

  3. Stop the VM instance.

  4. Modify the configuration of the VM instance.

  5. Start the VM.

  6. Validate your changes.

Modification types

Some changes you can make by stopping your SAP system, stopping the VM, making the changes, and restarting. Other changes might require you to re-partition your drives or restore your database systems from backups.

The following changes can be made by stopping and restarting the VM:

  • Switching to a larger or smaller VM instance type
  • Switching to a later CPU platform
  • Switching from a predefined VM configuration to a custom VM configuration

The following changes might require restoring your SAP system from backups after the change is complete:

  • Reducing the size of a persistent disk
  • Reconfiguring the storage layout or the partitioning
  • Altering the network interface card or the Virtual Private Cloud configuration

For more information about modifying your VM configuration, see Changing the machine type of a stopped instance.

Tips and recommendations

Consider the following tips and recommendations before you modify a VM configuration.

Back up your system before making changes

Before making any changes, back up your data, SAP systems, the current VM configuration, and anything else that might be affected by the change.

One way to backup up your VM configuration is to take a snapshot of the boot disk of your VM. For more information, see Creating persistent disk snapshots.

You can also create custom images from your the boot disk of your VM. For more information, see Creating, deleting, and deprecating custom images.

Test the snapshot or custom image of your boot disk by creating a VM instance from it.

Saving a copy of the configuration details of your VM might also be helpful. Not all of the VM configuration details are captured by persistent disk snapshots or custom images.

You can quickly display and copy the VM configuration details in REST response format by clicking Equivalent REST at the bottom of the VM instance details page in the Google Cloud Console.

You can also display the VM instance details in the Cloud Shell or, if you have the Cloud SDK installed, a local command terminal by issuing the following command:

gcloud compute instances describe instance_name

CPU platform considerations

A SAP certification of a Compute Engine VM type defines the minimum CPU platform that you can use with a VM instance. Because some Compute Engine VM types give you a choice of CPU platforms, when you change a VM configuration, you must make sure that the resulting CPU platform meets the minimum requirements of the SAP certification. This is especially true if you specify Automatic for the CPU platform.

For information about the minimum CPU platforms that are required by the SAP certifications of Compute Engine VM types on Google Cloud, see:

For information about changing your CPU platform, see Specifying a Minimum CPU Platform for VM Instances

For more information about the CPU platforms that are available from Compute Engine, see CPU platforms.

Persistent disk considerations

If you are changing the size of a persistent disk, to reduce the risk associated with any changes, create new disks at the required size and keep the old disks until you have confirmed the change is successful.

Custom machine configurations

When you configure a custom machine, to ensure support from SAP, you must conform to memory-to-vCPU ratios that are based on the machine type you are customizing and SAP guidelines.

The guidelines are different depending on whether the custom machine is for SAP HANA or SAP NetWeaver.

Custom machines for SAP NetWeaver

The following table summarizes the rules for each custom machine type that SAP supports for SAP NetWeaver.

Machine type vCPUs Standard-memory option High-memory option
N1 1, or any even number up to 96 3.75 GB per vCPU 6.5 GB per vCPU
N2 Any even number up to 32. After 32, the number of vCPUs must be divisible by 4, up to 80 vCPUs. For example, 32, 36, and 40 vCPUs are all valid, but 38 is invalid. 4 GB per vCPU 8 GB per vCPU
N2D 2 or any even number of vCPUs that is divisible by 4, up to an SAP-support limit of 32 vCPUs. 4 GB per vCPU 8 GB per vCPU

For more information see, Custom machine configurations.

Custom machines for SAP HANA

The following table shows the customizable Compute Engine virtual machine (VM) types that are certified by SAP for production use of SAP HANA on Google Cloud.

SAP certifies only a subset of the custom VM type configurations that Compute Engine supports.

Custom VM configurations are subject to customization rules that are defined by Compute Engine. The rules differ depending on which machine type you are customizing. For complete customization rules, see Creating a VM Instance with a Custom Machine Type.

Base Google Cloud instance type vCPU Memory (GB) Operating system CPU platform
N1-highmem A number of vCPUs from 32 to 64 that is evenly divisible by 2. 6.5 GB for each vCPU RHEL, SUSE Intel Broadwell
N2-highmem (Scale up only) A number of vCPUs from 32 to 64 that is evenly divisible by 4. 8 GB for each vCPU RHEL, SUSE Intel Cascade Lake

Deployment Manager and custom VM types for SAP

If you use the Google Cloud-provided Deployment Manager templates to deploy your VMs, to deploy a custom VM type, you need to temporarily deploy a predefined VM type and then modify the VM to get the number of vCPUs that you need. The Deployment Manager templates do not support specifying custom machine types.

When you specify a temporary VM type for SAP HANA, select a VM type with slightly more vCPUs than you need and then customize the VM by reducing the number of vCPUs and memory. Deploying a VM with slightly more vCPUs and memory than you need ensures that you have enough persistent disk storage for you SAP HANA system without paying for a lot of persistent disk storage that you don't need. If you were to deploy a VM with fewer vCPUs that you need, after you were to add the vCPUs and memory, you would also have to increase the size of the persistent disks to match the increase in memory.

For SAP NetWeaver, you can select the smallest predefined VM type and then add the vCPUs that you need. You do not need to adjust the sizes of the persistent disks.

More information about creating a custom VM instance

For more information about creating a Compute Engine VM instance with a custom configuration, see Creating a VM instance with a custom machine type.

Test your changes

As the final step in your change process, use a non-production system to test the changes you are making before you apply them in production.

Avoiding downtime when modifying VM configurations

The change process is simplest if the changes you need to make do not require restoring your system from backups and your business can tolerate a short downtime.

If your business can't tolerate any downtime, your SAP systems probably run in a high-availability (HA) configuration, in which case, you can make changes one node at a time. However, while the changes are being made to a secondary node, the secondary system is unavailable for failover if the primary node has problems.

Making VM changes one at a time to the nodes in an HA configuration can also be used for other changes, such as:

  • Operating system patching
  • Database system patching
  • SAP kernel patching, when combined with rolling kernel updates
  • Reconfiguring VM service accounts, networking, and so forth

These types of changes are outside of the scope of this topic and might include additional considerations, steps, or requirements.