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 Google Cloud console, the Google Cloud CLI, 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.
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.
Modifying persistent disks or Hyperdisks
If you are changing the size of a persistent disk or Hyperdisk, then 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.
You can use the following procedure to modify the size or type of persistent disks or Hyperdisks that are attached to a VM:
- Back up your SAP systems.
- Stop the SAP systems.
- Stop the VM instance.
- Create snapshots of the persistent disks or Hyperdisks that you are modifying, as described in Create and manage disk snapshots.
Using the snapshots, create new disks of the size and type that you need, as described in Restore from a snapshot.
If your SAP system is SAP HANA, then make sure that the type and size of the new persistent disks or Hyperdisks meet the SAP HANA performance requirements. For more information, see SAP HANA persistent disk storage.
Detach the original disks.
Attach the new disks.
If the new disks are larger than the old disks, then resize the file system to use the additional disk space.
Restart the VM.
Restart the SAP systems.
Validate that the systems are operational.
After your systems are validated, delete or keep the old disks, as needed.
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 Create and manage 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 Google Cloud CLI installed, a local command terminal by issuing the following command:
gcloud compute instances describe instance_name
CPU platform considerations
The 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
If you are using older generation machine families, we recommend that you specify the latest available CPU platform for that machine family. Not only will this provide the best performance for your workload, but it might also improve your system reliability through capabilities provided by newer CPUs. Alternatively, consider updating to newer generation machine types, for example N1 to N2 or N2D, if applicable. If you have existing CPU reservations or Compute Engine commitments for a machine type, please reach out to a sales representative to discuss your options to change reservations or machine type.
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.
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 Compute Engine custom machine types that are certified by SAP for production use of SAP HANA on Google Cloud.
SAP certifies only a subset of the custom machine types that are available from Compute Engine.
Custom machine types 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 custom VM instance.
| Base machine type | vCPUs | Memory (GB) | Operating system | CPU platforms |
|---|---|---|---|---|
| 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) | On Intel Ice Lake, a number of vCPUs from 32 to 80 that is evenly
divisible by 4. On Intel Cascade Lake, a number of vCPUs from 32 to 80 that is evenly divisible by 4. |
Up to 8 GB per vCPU | RHEL, SUSE | Intel Ice Lake, Intel Cascade Lake |
Deployment automation and custom VM types for SAP
If you use the Terraform configuration files or Deployment Manager templates provided by Google Cloud to deploy your VMs, then to deploy a custom VM type, you need to temporarily deploy a predefined VM type that has vCPUs and memory equal to or more than what you need, and then modify the VM to get the vCPUs and memory that you need. The Terraform configurations and Deployment Manager files do not support specifying custom machine types.
For SAP HANA, deploying a VM with slightly more memory than you need ensures that you have enough persistent disk storage for your 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 less memory than you need, then after you add memory, you would also have to increase the size of the persistent disks or Hyperdisks to match the increase in memory.
Alternatively, while using the Terraform configurations for SAP HANA, you can
specify the required disk sizes using the advanced arguments related to the
disk_type argument. For more information, see the deployment guide
for your
deployment scenario. Make sure that you
follow the minimum sizes for SSD-based persistent disks in the SAP HANA
planning guide.
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.