IBM Db2 for SAP planning guide

This guide provides information that you can use to plan for the installation of an IBM Db2 Advanced Enterprise Server Edition (AESE) (IBM Db2) system that supports SAP applications on Google Cloud.

To deploy IBM Db2 with SAP products on Google Cloud, see:

For links to more information from SAP about IBM Db2, see SAP on IBM Db2 for Linux, UNIX, and Windows.

For more information about the products that SAP certifies to run on Google Cloud, including IBM Db2, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .

Google Cloud basics

Google Cloud consists of many cloud-based services and products. When running SAP products on Google Cloud, you mainly use the IaaS-based services offered through Compute Engine and Cloud Storage, as well as some platform-wide features, such as tools.

See the Google Cloud platform overview for important concepts and terminology. This guide duplicates some information from the overview for convenience and context.

For an overview of considerations that enterprise-scale organizations should take into account when running on Google Cloud, see the Google Cloud Architecture Framework.

Interacting with Google Cloud

Google Cloud offers three main ways to interact with the platform, and your resources, in the cloud:

  • The Google Cloud console, which is a web-based user interface.
  • The gcloud command-line tool, which provides a superset of the functionality that Google Cloud console offers.
  • Client libraries, which provide APIs for accessing services and management of resources. Client libraries are useful when building your own tools.

Google Cloud services

SAP deployments typically utilize some or all of the following Google Cloud services:

Service Description
VPC networking

Connects your VM instances to each other and to the internet.

Each VM instance is a member of either a legacy network with a single global IP range, or a recommended subnet network, where the VM instance is a member of a single subnetwork that is a member of a larger network.

Note that a Virtual Private Cloud (VPC) network cannot span Google Cloud projects, but a Google Cloud project can have multiple VPC networks.

To connect resources from multiple projects to a common VPC network, you can use Shared VPC, so that the resources can communicate with each other securely and efficiently by using internal IP addresses from that network. For information about how to provision a Shared VPC including requirements, configuration steps, and usage, see Provision Shared VPC.

Compute Engine Creates and manages VMs with your choice of operating system and software stack.
Persistent Disk and Hyperdisk

You can use Persistent Disk and Google Cloud Hyperdisk:

  • Persistent Disk volumes are available as either standard hard disk drives (HDD) or solid-state drives (SSD). For balanced persistent disks and SSD persistent disks, PD Async Replication provides asynchronous replication of SAP data between two Google Cloud regions.
  • Hyperdisk Extreme volumes provide higher maximum IOPS and throughput options than SSD Persistent Disk volumes.
  • By default, Compute Engine encrypts customer content at rest, including content inside Persistent Disk and Hyperdisk volumes. For more information about disk encryption and possible encryption options, see About disk encryption.
Google Cloud console

A browser-based tool for managing Compute Engine resources.

Use a template to describe all of the Compute Engine resources and instances you need. You don't have to individually create and configure the resources or figure out dependencies because the Google Cloud console does that for you.
Cloud Storage You can store your SAP database backups in Cloud Storage for added durability and reliability, with replication.
Cloud Monitoring

Provides visibility into the deployment, performance, uptime, and health of Compute Engine, network, and persistent storage disks.

Monitoring collects metrics, events, and metadata from Google Cloud and uses these to generate insights through dashboards, charts, and alerts. You can monitor the compute metrics at no cost through Monitoring.
IAM

Provides unified control over permissions for Google Cloud resources.

IAM lets you control who can perform control-plane operations on your VMs, including creating, modifying, and deleting VMs and persistent storage disks, and creating and modifying networks.

Pricing and quotas

You can use the pricing calculator to estimate your usage costs. For more pricing information, see Compute Engine pricing, Cloud Storage pricing, and Google Cloud Observability pricing.

Google Cloud resources are subject to quotas. If you plan to use high-CPU or high-memory machines, you might need to request additional quota. For more information, see Compute Engine resource quotas.

Compliance and sovereign controls

If you require your SAP workload to run in compliance with data residency, access control, support personnel, or regulatory requirements, then you must plan for using Assured Workloads - a service that helps you run secure and compliant workloads on Google Cloud without compromising the quality of your cloud experience. For more information, see Compliance and sovereign controls for SAP on Google Cloud.

Deployment architecture

An IBM Db2 installation with a single-partition database on Google Cloud comprises the following components:

  • One Compute Engine VM running your IBM Db2 database.

  • One or more persistent disk drives for the following:

    • The root disk.
    • The database id volume (/db2/<DBSID>/),
    • The instance volume (/db2/db2<dbsid>), which contains the home directory of user db2<dbsid> and the IBM Db2 instance data for <DBSID> as well as the IBM Db2 software.
    • The log volume (/db2/<DBSID>/log_dir), which contains at least the online database log files.
    • The dump/diagnostic volume (/db2/<DBSID>/db2dump), which contains Db2 diagnostic log files, Db2 dump files, and further service engineer information.
    • The data volume (/db2/<DBSID>/sapdata<n> or /db2/<DBSID>/sapdata/sapdata<n>). This is the storage location for tablespaces with container-type database managed space (DMS) FILE or tablespaces with Db2's automatic storage
    • The temporary tablespace volume (/db2/<DBSID>/saptmp<n> or /db2/ <DBSID>/saptmp/saptmp<n>). This is the storage location for temporary tablespaces.

Depending on the requirements of your installation, you might also need to include the following as well:

  • A NAT gateway. A NAT gateway allows you to provide Internet connectivity for your VMs while denying direct Internet connectivity to those VMs. You could also configure this VM as a bastion host that allows you to establish SSH connections to the other VMs on your private subnet. See NAT gateways and bastion hosts for more information.
  • A backup volume for storing warm backups.
  • A storage volume for storing log archives.

Different use cases might require additional devices or databases. For more information, see:

Resource requirements

In many ways, running IBM Db2 with SAP on Google Cloud is similar to running it in your own data center. You still need to think about computing resources, storage, and networking considerations.

For more information, see the appropriate installation guide for your SAP system with IBM Db2.

VM configuration

IBM Db2 is certified to run on all Compute Engine machine types, including custom types. In most cases, use a machine type with two or more virtual CPUs.

For information about different Compute Engine machine types and their use cases, see Machine Types in the Compute Engine documentation.

CPU configuration

The number of vCPUs required varies depending on the application load on IBM Db2 LUW. You should allocate a minimum of two vCPUs to your IBM Db2 installation. To achieve best use of existing resources by your IBM Db2 system, follow the guidance in the SAP on IBM Db2 for Linux, UNIX, and Windows documentation and adjust your computing resources as needed.

Memory configuration

Your IBM Db2 VM should have at least 4 GB of RAM per vCPU. Of this amount, approximately 80% of your RAM should be allocated to IBM Db2, with the rest allocated to the OS on which IBM Db2 is running.

The optimal amount of memory for your use case depends on the complexity of the queries you're running, the size of your data, the amount of parallelism you're using, and the level of performance you're expecting. For further guidance about optimizing your memory configuration, see the SAP on IBM Db2 for Linux, UNIX, and Windows documentation.

Storage configuration

By default, each Compute Engine VM has a small root persistent disk that contains the operating system. In addition, you should create, attach, format, and mount additional disks for your database, your logs, and your stored procedures.

Your disk size and performance requirements will depend on your application. Size each device according to your needs.

For more information about the persistent disk options for IBM Db2, see Persistent disks.

For guidance from SAP on disk sizing, see:

Supported IBM Db2 versions

You must use the SAP-certified IBM Db2 software fix pack (FP) levels. The use of other IBM Db2 software levels is not allowed.

For more information, see SAP Note 101809 - DB6: Supported Db2 Versions and Fix Pack Levels.

Supported IBM Db2 features

SAP supports most IBM Db2 features on Google Cloud. However, the following features are not supported:

  • Multi-partition Db2 databases
  • IBM Db2 pureScale feature

Supported operating systems

SAP has certified Google Cloud to run IBM Db2 on the following SUSE Linux Enterprise Server (SLES), Red Hat Enterprise Linux (RHEL), and Windows Server operating system images:

  • SLES 12 SP2 and above
  • RHEL 7.4
  • Windows Server 2012 R2 and above

For more information about Compute Engine images, see Images.

Deployment considerations

Regions and zones

When you deploy a VM, you must choose a region and zone. A region is a specific geographical location where you can run your resources, and corresponds to a data center location. Each region has one or more zones.

Global resources, such as preconfigured disk images and disk snapshots, can be accessed across regions and zones. Regional resources, such as static external IP addresses, can be accessed only by resources that are in the same region. Zonal resources, such as VMs and disks, can be accessed only by resources that are located in the same zone.

Google Cloud regions and zones

When choosing regions and zones for your VMs, keep the following in mind:

  • The location of your users and your internal resources, such as your data center or corporate network. To decrease latency, select a location that is in close proximity to your users and resources.
  • The location of your other SAP resources. Your SAP application and your database must be in the same zone.

Persistent disks

Persistent disks are durable block storage devices that function similarly to the physical disks in a desktop or a server.

Compute Engine offers different types of persistent disks. Each type has different performance characteristics. Google Cloud manages the underlying hardware of persistent disks to ensure data redundancy and to optimize performance.

You can use any of the following Compute Engine persistent disk types:

  • Standard persistent disks (pd-standard): efficient and economical block storage backed by standard hard disk drives (HDD) for handling sequential read-write operations, but not optimized to handle high rates of random input-output operations per second (IOPS).
  • SSD (pd-ssd): provides reliable, high-performance block storage backed by solid-state drives (SSD).
  • Balanced (pd-balanced): provides cost-effective and reliable SSD-based block storage.
  • Extreme (pd-extreme): provides higher maximum IOPS and throughput options than pd-ssd for larger Compute Engine machine types. For more information, see Extreme persistent disks.

The performance of SSD and balanced persistent disks scales automatically with size, so you can adjust performance by resizing your existing persistent disks or adding more persistent disks to a VM.

The type of VM you are using and the number of vCPUs it contains also affects persistent disk performance.

Persistent disks are located independently from your VMs, so you can detach or move persistent disks to keep your data, even after you delete your VMs.

For more information about the different types of Compute Engine persistent disks, their performance characteristics, and how to work with them, see the Compute Engine documentation:

Local SSD (non-persistent)

Google Cloud also offers local SSD disk drives. Although local SSDs can offer some advantages over persistent disks, don't use them as part of an IBM Db2 system. VM instances with local SSDs attached cannot be stopped and then restarted.

NAT gateways and bastion hosts

If your security policy requires truly internal VMs, you need to set up a NAT proxy manually on your network and a corresponding route so that VMs can reach the Internet. It is important to note that you cannot connect to a fully internal VM instance directly by using SSH. To connect to such internal machines, you must set up a bastion instance that has an external IP address and then tunnel through it. When VMs do not have external IP addresses, they can be reached only by other VMs on the network, or through a managed VPN gateway. You can provision VMs in your network to act as trusted relays for inbound connections, called bastion hosts, or network egress, called NAT gateways. For more transparent connectivity without setting up such connections, you can use a managed VPN gateway resource.

Using bastion hosts for inbound connections

Bastion hosts provide an external facing point of entry into a network containing private-network VMs. This host can provide a single point of fortification or audit and can be started and stopped to enable or disable inbound SSH communication from the Internet.

Bastion host shown in SSH scenario

You can achieve SSH access to VMs that do not have an external IP address by first connecting to a bastion host. A complete hardening of a bastion host is outside the scope of this article, but you can take some initial steps, including:

  • Limit the CIDR range of source IPs that can communicate with the bastion.
  • Configure firewall rules to allow SSH traffic to private VMs from only the bastion host.

By default, SSH on VMs is configured to use private keys for authentication. When using a bastion host, you log into the bastion host first, and then into your target private VM. Due to this two-step login, you should use SSH-agent forwarding to reach the target VM instead of storing the target VM's private key on the bastion host. You must do this even if you are using the same key-pair for both bastion and target VMs, as the bastion has direct access only to the public half of the key-pair.

Using NAT gateways for traffic egress

When a VM does not have an assigned, external IP address, it cannot make direct connections to external services, including other Google Cloud services. To allow these VMs to reach services on the Internet, you can set up and configure a NAT gateway. The NAT gateway is a VM that can route traffic on behalf of any other VM on the network. You should have one NAT gateway per network. Be aware that a single-VM NAT gateway should not be considered highly available, and cannot support high traffic throughput for multiple VMs. See the IBM Db2 Deployment Guide for SAP NetWeaver for instructions on how to set up a VM to act as a NAT gateway.

Custom images

After your system is up and running, you can create custom images. You should create these images when you modify the state of your root persistent disk and want to be able to easily restore the new state. You should have a plan for how to manage the custom images you create. For more information, see Image Management Best Practices.

User identification and resource access

When planning security for an SAP deployment on Google Cloud, you must identify:

  • The user accounts and applications that need access to the Google Cloud resources in your Google Cloud project
  • The specific Google Cloud resources in your project that each user needs to access

You must add each user to your project by adding their Google account ID to the project as a principal. For an application program that uses Google Cloud resources, you create a service account, which provides a user identity for the program within your project.

Compute Engine VMs have their own service account. Any programs that that run on a VM can use the VM service account, as long as the VM service account has the resource permissions that the program needs.

After you identify the Google Cloud resources that each user needs to use, you grant each user permission to use each resource by assigning resource-specific roles to the user. Review the predefined roles that IAM provides for each resource, and assign roles to each user that provide just enough permissions to complete the user's tasks or functions and no more.

If you need more granular or restrictive control over permissions than the predefined IAM roles provide, you can create custom roles.

For more information about the IAM roles that SAP programs need on Google Cloud, see Identity and access management for SAP programs on Google Cloud.

For an overview of identity and access management for SAP on Google Cloud, see Identity and access management overview for SAP on Google Cloud.

Networking and network security

Consider the information in the following sections when planning networking and security.

Minimum privilege model

One of your first lines of defense is to restrict who can reach your network and your VMs by using firewalls. By default, all traffic to VMs, even from other VMs, is blocked by the firewall unless you create rules to allow access. The exception is the default network that is created automatically with each project and has default firewall rules.

By creating firewall rules, you can restrict all traffic on a given set of ports to specific source IP addresses. You should follow the minimum privilege model to restrict access to the specific IP addresses, protocols, and ports that need access. For example, you should always set up a bastion host and allow SSH into your SAP NetWeaver system only from that host.

Custom networks and firewall rules

You can use a network to define a gateway IP and the network range for the VMs attached to that network. All Compute Engine networks use the IPv4 protocol. Every Google Cloud project is provided with a default network with preset configurations and firewall rules, but you should add a custom subnetwork and firewall rules based on a minimum privilege model. By default, a newly created network has no firewall rules and hence no network access.

Depending on your requirements, you might want to add additional subnetworks to isolate parts of your network. For more information, see Subnetworks.

The firewall rules apply to the entire network and all the VMs in the network. You can add a firewall rule that allows traffic between VMs in the same network and across subnetworks. You can also configure firewalls to apply to specific target VMs by using the tagging mechanism.

Some SAP products, such as SAP NetWeaver, require access to certain ports. Be sure to add firewall rules to allow access to the ports outlined by SAP.

Routes

Routes are global resources attached to a single network. User-created routes apply to all VMs in a network. This means you can add a route that forwards traffic from VM to VM within the same network and across subnetworks without requiring external IP addresses.

For external access to Internet resources, launch a VM with no external IP address and configure another virtual machine as a NAT gateway. This configuration requires you to add your NAT gateway as a route for your SAP instance. For more information, see NAT gateways and bastion hosts.

Cloud VPN

You can securely connect your existing network to Google Cloud through a VPN connection using IPsec by using Cloud VPN. Traffic traveling between the two networks is encrypted by one VPN gateway, then decrypted by the other VPN gateway. This protects your data as it travels over the Internet. You can dynamically control which VMs can send traffic down the VPN using instance tags on routes. Cloud VPN tunnels are billed at a static monthly rate plus standard egress charges. Note that connecting two networks in the same project still incurs standard egress charges. For more information, see the VPN Overview and Choosing a VPN Routing Option.

Securing a Cloud Storage bucket

If you use Cloud Storage to host your backups for your data and log, make sure you use TLS (HTTPS) while sending data to Cloud Storage from your VMs to protect data in transit. Cloud Storage automatically encrypts data at rest. You can specify your own encryption keys if you have your own key-management system.

Refer to the following additional security resources for your SAP environment on Google Cloud:

Backup and recovery

You must have a plan for how to restore your system to operating condition if the worst happens.

For information about the backup and recovery of IBM Db2 systems that support SAP, see:

For general guidance about how to plan for disaster recovery using Google Cloud, see:

Automation for IBM Db2 deployments

Google Cloud provides a Terraform configuration file that you can use to automate the deployment of resources for IBM Db2 with Linux.

The sap_db2.tf configuration provided by Google Cloud for IBM Db2 provisions the following resources:

  • A Compute Engine VM instance based on the machine type of your choice.
  • Your choice of Red Hat Enterprise Linux (RHEL) or SUSE Linux Enterprise Server (SLES) operating system.
  • Compute Engine persistent disks.
  • The Google Cloud's monitoring agent for SAP NetWeaver.

For the deployment automation instructions, see Automated VM deployment for IBM Db2 on Linux using Terraform.

High-availability IBM Db2 clusters

You can set up a highly-available and disaster-tolerant IBM Db2 cluster on Google Cloud that is supported by SAP. The cluster is configured and managed by IBM Tivoli System Automation for Multiplatforms (TSAMP) and uses the IBM Db2 HADR function for replication purposes.

Applications connect to the primary IBM Db2 server through a floating IP address, which, in the event of a failover, TSAMP reassigns to the standby server.

The IBM Db2 HADR function supports up to three standby servers. On Google Cloud, the host VMs in the cluster must be in the same region but can be in different zones within the region.

SAP support for DB2 HA clusters on Google Cloud is listed in SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .

For information about the IBM Db2 features that SAP supports, see SAP Note 1555903.

Deployment architectures

You can deploy the host VMs in a IBM Db2 HA cluster across multiple Compute Engine zones in the same region or, if necessary, you can deploy them in a single zone.

For the highest availability, deploy each host VM in different zone.

The following diagram shows a multi-zone deployment that uses a static route implementation for the floating IP address.

Each host of a Db2 HA cluster is deployed in a different zone.

The following diagram shows a single-zone deployment that uses an alias IP implementation for the floating IP address.

Both hosts of a Db2 HA cluster are deployed in the same zone.

Required documentation

To deploy an IBM Db2 HA cluster for SAP, you need to follow both SAP and Google Cloud documentation.

You might need to refer to additional SAP or IBM documentation during the installation of the SAP and IBM components.

Requirements specific to an IBM Db2 HA cluster on Google Cloud

On Google Cloud, SAP supports IBM Db2 HA clusters only on RHEL or SLES operating systems.

For the Google Cloud software requirements for the IBM Db2 instances, see Resource requirements.

For IBM TSAMP, use the latest available version that is supported by your IBM Db2 version and your operating system.

For all other hardware and software requirements, see IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms.

Floating IP addresses for IBM Db2 HA clusters on Google Cloud

An IBM Db2 HA cluster for SAP uses a floating IP address, which is also known as a "virtual IP address" or "shared IP address".

For an IBM Db2 HA cluster, Google Cloud can implement a floating IP address by using either a Google Cloud static route or a Google Cloud alias IP address.

The static route implementation is recommended for multi-zone IBM Db2 HA clusters. Multi-zone deployments help ensure that a single-zone failure does not take down your IBM Db2 system.

However, if your network architecture does not support static routes or you need to avoid solutions like IP overlay or complex routing, you can use the alias IP address implementation with a single-zone IBM Db2 HA cluster. Alias IP addresses are not recommended for multi-zone deployments because the reallocation of the alias might not be guaranteed in the event of a zonal failure.

Depending on whether you choose the static route implementation or the alias IP implementation, the requirements for the IP address that you use for your floating IP address are different.

The use of a static route requires that you select an IP address for your floating IP address that is:

  • Outside of the IP ranges of your existing Virtual Private Cloud subnets where the VMs reside.
  • Does not conflict with any external IP addresses in your extended network.

Consult with your network administrator to determine a suitable IP address for a static route implementation.

The use of an alias IP address requires you to reserve an IP address from your subnetwork IP range for use as the floating IP address.

For more information about floating IP addresses on Google Cloud, see Best Practices for Floating IP Addresses.

SAP recommends the use of floating IP addresses in IBM Db2 HA clusters. SAP does support Automatic Client Reroute (ACR), provided that you account for all requirements and limitations of this method is recognized. For more information, see SAP Note 1568539.

The network tiebreaker

IBM Db2 HA clusters commonly send an ICMP request (ping) to a network gateway, which serves as the default network tiebreaker to determine which node should take over when communication between the nodes in a cluster is lost.

Because network gateways on Google Cloud do not respond to ICMP requests, use any other IP address that can be pinged and that is highly available itself. For example, you could use the virtual IP address of your SAP application Central Services instance or the Google DNS, 8.8.8.8.

If the network tiebreaker cannot respond to ICMP requests during setup, the setup fails.

Other network tiebreakers exist and are defined by IBM. For more information, see Configuring the tiebreaker.

Setup tools for a Db2 HA cluster

You can use either one of the following tools that SAP and IBM provide to configure an IBM Db2 HADR cluster:

  • The SAP cluster setup tool (sapdb2cluster.sh)
  • The IBM DB2 high availability instance configuration utility (db2haicu)

SAP Db2 cluster setup tool (sapdb2cluster.sh)

SAP recommends the SAP-provided cluster setup tool, sapdb2cluster.sh, to configure and create a Db2 HA cluster. The Google Cloud deployment instructions use the SAP cluster set up tool. The cluster setup tool simplifies much of the cluster setup and ensures that it meets SAP support requirements.

Before you create the HA cluster with the SAP cluster setup tool, one of the steps in the Google Cloud deployment instructions makes a minor modification to the SAP cluster setup tool, sapdb2cluster.sh, so that the tool skips the creation of the default IBM.ServiceIP resource class.

Resources created from the IBM TSAMP IBM.ServiceIP resource class issue gratuitous ARP requests, which are not supported in VPC networks on Google Cloud, as explained in Challenges with migrating floating IPs to Compute Engine.

To download the latest version of the cluster setup tool, see SAP Note 960843.

The IBM DB2 high availability instance configuration utility (db2haicu)

As an alternative to using the SAP cluster setup tool, you can use the IBM db2haicu utility instead, which also provides an interactive interface. The SAP cluster setup tool uses db2haicu for the cluster setup.

When using the db2haicu utility, you must configure the HADR relationship first, before you can use the db2haicu utility to setup the cluster. While the overall setup procedure might be more complex with the db2haicu utility, the utility allows for more customization for complex network configurations or other requirements that are specific to your environment.

Always follow SAP and IBM guidelines when you use the db2haicu utility.

For more information about db2haicu, see the IBM Db2 documentation.

Google Cloud helper script for IBM TSAMP cluster integration

To enable the IBM Db2 HA cluster to call the appropriate Google Cloud API commands to start, stop, and monitor the TSAMP resource for the floating IP address, you need to download a helper script from Google Cloud to the host VMs. When you create the floating IP address resource in IBM TSAMP, you reference the Google Cloud helper script.

Licenses

This section provides information about licensing requirements.

IBM Db2 licenses

When running IBM Db2 on Google Cloud, you must bring your own license (BYOL). You can obtain Db2 licenses from SAP or from IBM. For more information about licensing and support, see the following SAP Notes:

For more information about SAP licensing, contact SAP.

Operating system licenses

In Compute Engine, there are two ways to license SLES, RHEL, and Windows Server:

  • With pay-as-you-go licensing, your Compute Engine VM hourly cost includes licensing. Google manages the licensing logistics. Your hourly costs are higher, but you have complete flexibility to increase and decrease your costs, as needed. This is the licensing model used for Google Cloud public images that include SLES, RHEL, and Windows Server.

  • With BYOL, your Compute Engine VM costs are lower because the licensing isn't included. You must migrate an existing license or purchase your own license, which means paying up front, and you have less flexibility.

Support

For issues with Google Cloud infrastructure or services, contact Customer Care. You can find the contact information on the Support Overview page in the Google Cloud console. If Customer Care determines that a problem resides in your SAP systems, then you are referred to SAP Support.

For SAP product-related issues, log your support request with SAP support. SAP evaluates the support ticket and, if it appears to be a Google Cloud infrastructure issue, then SAP transfers that ticket to the appropriate Google Cloud component in its system: BC-OP-LNX-GOOGLE or BC-OP-NT-GOOGLE.

Support requirements

Before you can receive support for SAP systems and the Google Cloud infrastructure and services that they use, you must meet the minimum support plan requirements.

For more information about the minimum support requirements for SAP on Google Cloud, see:

For information about SAP support for Db2, see SAP Note 1168456 - DB6: Support Process and End of Support Dates for IBM DB2 LUW

What's next

To deploy IBM Db2 on Google Cloud, see:

To deploy an IBM Db2 HA cluster to Google Cloud, see the IBM Db2 high-availability cluster for SAP deployment guide.