This guide discusses the considerations for SAP systems running on Google Cloud when you modify the configuration of the Compute Engine instances that host them.
After deploying an SAP system on Compute Engine instances, sooner or later you experience the need to modify the configuration of the instances. This can be for reasons such as an increase in the workload, to take advantage of the latest infrastructure for faster storage or networking speeds, or to optimize the price-to-performance ratio compared to the existing infrastructure.
Modification types
Some changes you can make by stopping your SAP system, stopping the compute instance, making the changes, and restarting the compute instance and SAP system. 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 compute instance:
- Switching to a later CPU platform
- Switching from a predefined VM configuration to a custom VM configuration
Switching to a larger or smaller machine type
If you're using a first or second generation machine series and you want to switch to a machine type that belongs to the third generation or later machine series, then you can't edit the machine type of your instance and instead need to move your SAP system to a new compute instance. For more information, see Edit the machine type of a compute instance.
The following changes might require restoring your SAP system from backups after the change is complete:
- Reducing the size of a Persistent Disk or Hyperdisk volume
- Reconfiguring the storage layout or the partitioning
- Switching the network interface card, from VirtIO to gVNIC, or modifying the Virtual Private Cloud configuration
Tips and recommendations
Before you modify the configuration of a compute instance that hosts your SAP system, consider the following tips and recommendations.
Back up your system
Before you make any changes, we recommend that you back up your data, the SAP systems, the configuration of the original (source) compute instance, and anything else that might be affected by the change.
To back up the configuration of your compute instance, you can use the following options:
- Create a boot disk snapshot: One way to backup up your compute instance configuration is to create a snapshot of its boot disk. For information about how to do this, see Create and manage disk snapshots.
- Create a boot disk image: You can also create a custom OS image based on the boot disk of your compute instance. For information about how to do this, see Create custom images.
Save a copy of the configuration: Not all of the configuration details are captured by disk snapshots or custom images. Saving a copy of the configuration details of your compute instance might also be helpful. You can display and copy the configuration details as follows:
- In the Google Cloud console, go to the VM instance details page, and then click Equivalent REST. You can view and copy the configuration details in the REST response format.
From Cloud Shell, or a terminal where you've installed the Google Cloud CLI, display the instance details:
gcloud compute instances describe INSTANCE_NAME
Replace
INSTANCE_NAME
with the name of your compute instance.
After creating a backup, make sure to test the disk snapshot or custom image of your boot disk by creating a compute instance from it. For information about how to do this, see the following:
Review CPU platform considerations
The SAP certification of a Compute Engine machine type defines the minimum CPU platform that you can use with a compute instance. Because some machine types give you a choice of CPU platforms, when you change an instance's 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 machine 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, then we recommend that you specify the latest available CPU platform for that machine family. Not only does 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, if applicable. If you have existing CPU reservations or Compute Engine commitments for a machine type, then reach out to a Google Cloud sales representative or Cloud Customer Care to discuss your options to change reservations or machine type.
For information about changing your CPU platform, see Specify a minimum CPU platform for VM instances
For more information about the CPU platforms that are available from Compute Engine, see CPU platforms.
Review SAP guidelines for custom machine configurations
When you configure a custom machine, to ensure support from SAP, you must conform to the 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 compute instances, 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 don't 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 by 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 don't 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.
Avoiding downtime while modifying compute instances
The change process is simplest if the changes you need to make don't require restoring your SAP system from backups and your business can tolerate a short downtime.
If your business can't tolerate any downtime, then 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 changes to the compute instances 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 document and might include additional considerations, steps, or requirements.
Test your changes in a non-production environment
As the final step in your preparation process, use a non-production environment to test the changes that you want to make before you apply the changes in production.
High-level procedures
The following sections provide high-level procedures for different scenarios where you need to modify the configuration of compute instances that host your SAP systems.
If you want to move SAP HANA to a Compute Engine bare metal machine type such as X4 or C3-metal, then see Migrate SAP HANA to a Compute Engine bare metal instance.
Modify disk configuration
If you are changing the size of a Persistent Disk or Hyperdisk volume, or if you're changing the type of disk you're using, 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 that the change is successful.
If you're running SAP HANA, then see the following guides for detailed instructions:
To modify the size or type of disks that are attached to a compute instance that host your SAP system, complete the following steps:
- Back up your SAP system.
- Stop the SAP system.
- Stop the compute instance.
- Create snapshots of the Persistent Disk or Hyperdisk volumes that you are modifying, as described in Create and manage disk snapshots.
By 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 Disk or Hyperdisk volumes meet the SAP HANA performance requirements. For more information, see SAP HANA persistent disk storage.
Detach the original disks from the compute instance. These can be reattached in the event of a rollback.
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 compute instance.
Restart the SAP system.
Verify that the system is running as expected.
Clean up the resources that you don't require, such as the disks and disk snapshots.
Modify network configuration
This section describes the high-level procedure that you can use to modify the network configuration of a compute instance that hosts your SAP system.
For the third and later generations of Compute Engine machine types, Google Virtual NIC (gVNIC) replaces VirtIO-Net as the only supported network interface. Because you can't edit the network interface of a compute instance, you first need to deploy the required type of instance, and then move your SAP system to the new instance.
For example, consider an SAP system running on an M1 instance that uses VirtIO. If you want to switch to an M3 machine type, which only supports gVNIC, then you have to deploy the M3 instance first, and then move your SAP system to it.
To modify the network interface of a compute instance from VirtIO to gVNIC, complete the following steps:
Stop the SAP system.
Stop the compute instance.
Create a snapshot of the boot disk.
For information about how to create a disk snapshot, see Create archive and standard disk snapshots.
By using the boot disk snapshot, create a custom image that is enabled with the
GVNIC
guest OS feature.For information about how to create a custom image, see Create custom images.
Except the boot disk, detach all disks from the compute instance. These can be reattached in the event of a rollback.
For information about how to detach a disk from a compute instance, run the
gcloud compute instances detach-disk
command.Optionally, if you want to cascade the metadata of the original (source) compute instance to the new compute instance, then do the following:
Make note of the instance metadata, such as the instance name, IP address, labels, and tags.
Reserve the IP address that is allocated to your compute instance.
Delete the original (source) compute instance.
For information about how to do this, see Delete a Compute Engine instance.
By using the custom image that you created, create a new compute instance.
For information about how to do this, see Create an instance from a custom image. While creating the instance, do the following:
- Add the disks that you detached from the original (source) compute instance.
- Ensure that the instance uses
gVNIC
as the network interface card. - Cascade the metadata that you noted from the original (source) compute instance in a previous step.
Verify the configuration of the new compute instance.
Start the SAP system.
Verify that the SAP system is running as expected.
Clean up the resources that you don't require, such as the disk snapshots, custom image, and the original (source) compute instance.
Modify disk and network configuration
This section describes the high-level procedure that you can use to migrate your SAP system to a machine type that doesn't support the disk type and network interface card used by the original (source) compute instance.
For example, if your SAP system is running on an M2 instance that uses Persistent Disk volumes as block storage and VirtIO as the network interface card, then to switch to an M4 instance, which only supports Hyperdisk volumes and gVNIC, you need to manage both modifications.
To modify the disk and network interface card, complete the following steps:
Stop the SAP system.
Stop the compute instance.
Create a snapshot of the boot disk.
For information about how to create a disk snapshot, see Create archive and standard disk snapshots.
Create a snapshot of the other disks attached to the compute instance.
By using the boot disk snapshot, create a custom image that is enabled with the
GVNIC
guest OS feature.For information about how to create a custom image, see Create custom images.
Except the boot disk, detach all disks from the compute instance. These can be reattached in the event of a rollback.
For information about how to detach a disk from a compute instance, run the
gcloud compute instances detach-disk
command.Optionally, if you want to cascade the metadata of the original (source) compute instance to the new compute instance, then do the following:
Make note of the instance metadata, such as the instance name, IP address, labels, and tags.
Reserve the IP address that is allocated to your compute instance.
Delete the original (source) compute instance.
For information about how to do this, see Delete a Compute Engine instance.
By using the disk snapshots that you created, create Hyperdisk volumes.
For information about how to do this, see Create a disk from a snapshot and optionally attach it to an instance.
By using the custom image that you created, create a new compute instance.
For information about how to do this, see Create an instance from a custom image. While creating the instance, do the following:
- Add the Hyperdisk volumes that you created.
- Ensure that the instance uses
gVNIC
as the network interface card. - Cascade the metadata that you noted from the original (source) compute instance in a previous step.
Verify the configuration of the new compute instance.
Start the SAP system.
Verify that the SAP system is running as expected.
Clean up the resources that you don't require, such as the disk snapshots, custom image, and the original (source) compute instance.