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.
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:
Back up your SAP system.
Stop your SAP system.
Stop the VM instance.
Modify the configuration of the VM instance.
Start the VM.
Validate your changes.
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:
- Certified Compute Engine machine types for SAP applications
- Certified Compute Engine VMs for SAP HANA
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
Custom machine configurations have certain constraints that affect sizing and deployment.
Memory to vCPU ratios
If you are changing to a custom VM configuration, the ratio of memory to vCPUs must adhere to the guidelines that are defined by SAP to ensure adequate performance for your workloads and to meet SAP support requirements.
For SAP Netweaver systems, you can use either 3.75 GB per vCPU or 6.5 GB per vCPU.
For SAP HANA systems, custom configurations must have from 32 to 64 vCPUs with 6.5 GB of memory for each vCPU. You do not need to open an SAP support ticket. For more information, see Custom general-purpose machines in the table in Certifications for SAP HANA on GCP.
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.