This guide shows you how to set up Google Cloud resources for an IBM Db2 (IBM Db2) high-availability (HA) cluster for SAP on the Linux operating system.
These instructions are complementary to the instructions provided by SAP and IBM in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms. Always refer to the latest documentation provided by SAP and IBM when installing and configuring an IBM Db2 HA cluster on Google Cloud.
These instructions are for an IBM Db2 HA cluster that uses IBM Tivoli System Automation for Multiplatforms (TSAMP) to monitor the system and initiate appropriate action if the system becomes unresponsive. The cluster uses the IBM Db2 high-availability disaster recovery (HADR) function to replicate logged data changes to the standby database.
The cluster uses a floating IP address that is implemented by Google Cloud with either a Google Cloud static route or an alias IP address. In this context, the term "floating IP address" is synonymous with the term "virtual IP address", which is used in the SAP documentation.
These instructions show you how to set up an IBM Db2 HA cluster that consists of a primary IBM Db2 server and one secondary or standby IBM Db2 server, each of which are deployed on a separate Compute Engine virtual machine (VM).
This guide is intended for experienced SAP and IBM Db2 users who are familiar with high-availability clusters.
For more information about planning a Db2 HA cluster, see High-availability IBM Db2 clusters in the IBM Db2 for SAP Planning Guide.
Required SAP documentation
The instructions for installing and configuring the SAP and IBM components are provided by SAP in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms.
Read both the SAP and Google Cloud documentation before you start the procedures in these instructions. At various stages of deployment, you might need to refer to both the SAP and Google Cloud documentation.
Prerequisites
Before you create the IBM Db2 high-availability cluster, make sure that the following prerequisites are met:
- You or your organization has a Google Cloud account and you have created a project for the IBM Db2 HA cluster deployment. For information about creating Google Cloud projects, see Prerequisites in the IBM Db2 for SAP deployment guide.
- If you require your SAP workload to run in compliance with data residency, access control, support personnel, or regulatory requirements, then you must create the required Assured Workloads folder. For more information, see Compliance and sovereign controls for SAP on Google Cloud.
You have a Virtual Private Cloud network on Google Cloud. For instructions on configuring a VPC network and firewall rules, as well as instructions for setting up a NAT gateway or bastion host for IBM Db2 for SAP, see IBM Db2 for SAP deployment guide.
If OS login is enabled in your project metadata, you need to disable OS login temporarily until your deployment is complete. For deployment purposes, this procedure configures SSH keys in instance metadata. When OS login is enabled, metadata-based SSH key configurations are disabled. After deployment is complete, you can enable OS login again.
For more information, see:
Deploying an IBM Db2 high-availability cluster on Google Cloud
These instructions show you how to deploy two VMs, define a floating IP address, and configure the alias IP address or Google Cloud routes that support the floating IP address. When you need to install the IBM components, you are referred to the SAP documentation.
The main Google Cloud services that you need to set up for an IBM Db2 high-availability cluster are:
- A VPC network and subnetwork
- Firewall rules (if you don't use another form of network access control)
- Compute Engine VMs and persistent disk storage
You also download and use a Google Cloud helper script when you define the custom resource that TSAMP uses to manage switching the floating IP address between hosts. The script enables TSAMP to interact with Google Cloud APIs.
About Deployment Manager
In these instructions, you define the resource options for your installation in a Deployment Manager configuration file template.
Deployment Manager treats all of the resources that are created for your SAP system as a single entity called a deployment. You can view and work with all of the deployments for your project on the Deployments page in the Google Cloud console.
Be aware of the following behaviors when using Deployment Manager:
- Deleting a deployment deletes all of the resources associated with the deployment, including the VMs, the persistent disks, and any SAP systems that are installed on the VM.
By default, Deployment Manager uses the
ACQUIRE
resource creation policy. If you specify a VM name that is already in use by another VM in your project, Deployment Manager doesn't create a new VM, but instead adds the existing VM to your new deployment. If your original VM was created by a previous run of Deployment Manager, the VM is associated with two deployments.If you then delete the new deployment, the acquired VM is deleted from the deployment that originally created it. To avoid such a scenario, either set the Deployment Manager resource policy to
CREATE
, or make sure that you use unique resource names in your new deployment.For information about the policies you can use while creating resources with Deployment Manager and how to specify them, see the Deployment Manager documentation.
Deploying the VMs for an IBM Db2 HA cluster with Deployment Manager
In Cloud Shell, download the
template_ha.yaml
configuration file template to your working directory:wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/template_ha.yaml
To open the Cloud Shell code editor, click the pencil (edit) icon in the upper-right corner of the Cloud Shell terminal window.
Optionally, rename the
template_ha.yaml
file to identify the configuration it defines. For example,db2_ha_s123_dh1.yaml
.To open the
template_ha.yaml
in the code editor, double-click it.Define the VMs and persistent disks in the
template_ha.yaml
file. Thetemplate_ha.yaml
file contains two sections:sap_db2_primary
andsap_db2_secondary
. Each section contains a set of property-value pairs followed by comments that include less-frequently used properties.When you fill out each section, except for the
instanceName
,zone
, andotherHost
properties, the definitions for each VM must be identical.The following table describes the properties included in each section. To use a property, replace the placeholder text and brackets with the values for your installation.
Property Data type Description type String Specifies the location, type, and version of the Deployment Manager template to use during deployment.
The YAML file includes two
type
specifications, one of which is commented out. Thetype
specification that is active by default specifies the template version aslatest
. Thetype
specification that is commented out specifies a specific template version with a timestamp.If you need all of your deployments to use the same template version, use the
type
specification that includes the timestamp.instanceName
String The name of the VM instance on which you install IBM Db2. The name must be 13 characters or less, specified in lowercase letters, numbers, or hyphens. instanceType
String The type of Compute Engine virtual machine on which you install IBM Db2. Specify a machine type with two or more vCPUs. For example, n1-standard-4
.zone
String The zone in which you are deploying the IBM Db2 instance. It must be in the same region that you selected for your subnetwork. subnetwork
String The name of the subnetwork that you created in a previous step. If you are deploying to a shared VPC, specify this value as shared-vpc-project/SUBNETWORK
. For example,myproject/network1
.linuxImage
String The name of the Linux operating- system image or image family that you are using with IBM Db2. To specify an image family, add the prefix family/
to the family name. For example,family/rhel-7-sap-apps
orfamily/sles-12-sp3-sap
. To specify an image, enter only the image name. For the list of available image families, see the Images page in the Google Cloud console.linuxImageProject
String The Google Cloud project that contains the image you are going to use. This project might be your own project or a Google Cloud image project, such as rhel-sap-cloud
orsuse-sap-cloud
. For a list of Google Cloud image projects, see the Images page in the Compute Engine documentation.db2SID
String The database instance ID. db2sidSize
Integer The size in GB of /db2/DBSID, which is the root directory of the database instance. The minimum and default values for db2sidSize
are both 8 GB.db2homeSize
Integer The size in GB of /db2/db2db2sid, which is the home directory of the database instance. The minimum and default values for db2homeSize
are both 8 GB.db2dumpSize
Integer The size in GB of /db2/DBSID/db2dump, which holds the dump files from DB2 that are used for diagnosing problems. The minimum and default values for db2dumpSize
are both 8 GB.db2saptmpSize
Integer The size in GB of /db2/DBSID/saptmp, which holds the database temporary table space. The minimum and default values for db2saptmpSize
are both 8 GB.db2sapdataSize
Integer The size of /sapdb/DBSID/sapdata, which holds the database data files. The minimum and default values for db2sapdataSize
are both 30 GB.db2logSize
Integer The size of /db2/DBSID/logdir, which holds the database transaction logs. The minimum and default values for db2logSize
are both 8 GB.db2backupSize
Integer The size of the /db2backup volume. This property is optional. If you set to 0
or omit, no disk is created.db2sapdataSSD
boolean Specifies whether the data drive uses an SSD persistent disk ( Yes
) or an HDD persistent disk (No
).Yes
is the default.db2logSSD
boolean Specifies whether the log drive uses an SSD persistent disk ( Yes
) or an HDD persistent disk (No
).Yes
is the default. SSD is recommended for the log drive.usrsapSize
Integer Required only if you are installing IBM Db2 to run with SAP NetWeaver on the same VM instance. sapmntSize
Integer Required only if you are installing IBM Db2 to run with SAP NetWeaver on the same VM instance. swapSize
Integer Required only if you are installing IBM Db2 to run with SAP NetWeaver on the same VM instance. otherHost
String The name of the other VM instance in the IBM Db2 HA cluster. The VM instance must be defined in the other set of properties in the same template_ha.yaml
file.networkTag
String Optional. A network tag that represents your VM instance for firewall or routing purposes. If you specify publicIP: No
and don't use a network tag, be sure to provide another means of access to the internet.publicIP
boolean Optional. Determines whether a public IP address is added to your VM instance. The default is Yes
.serviceAccount
String Optional. If you create your own service account with locked down permissions, enter the name of the account here. By default, VMs are deployed using the default project service account. Note that an incorrectly defined service account prevents a successful deployment. The following is an example of a custom service account: myserviceuser@myproject.iam.gserviceaccount.com
sap_deployment_debug
boolean Optional. If this value is set to Yes
, the deployment generates verbose deployment logs. Don't turn this setting on unless a Google support engineer asks you to enable debugging.post_deployment_script
String Optional. Specifies the location of a script to run after the deployment is complete. The script should be hosted on a web server or in a Cloud Storage bucket. The URL should begin with http://
,https://
, orgs://
. Note that this script is executed on all VMs that the template creates. To run it on the primary instance only, add a check at the top of your script.The following example VM definitions from a
template_ha.yaml
configuration file create two VMs for an IBM Db2 HA cluster. For each VM, the configuration file directs Deployment Manager to deploy ann1-standard-4
VM that is running an operating system from the SLES 12 SP3 image family. The VM includes all of the directories that are required to run an IBM Db2 HA cluster. Deployment Manager doesn't create the SAP NetWeaver directories, because the directory sizes are set to0
.resources: - name: sap_db2_primary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py # # By default, this configuration file uses the latest release of the deployment # scripts for SAP on Google Cloud. To fix your deployments to a specific release # of the scripts, comment out the type property above and uncomment the type property below. # # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py # properties: instanceName: db2-ha-s1 instanceType: n1-standard-4 zone: us-central1-c subnetwork: example-sap-subnetwork linuxImage: family/sles-12-sp3-sap linuxImageProject: suse-sap-cloud db2SID: DH1 db2sidSize: 16 db2dumpSize: 16 db2saptmpSize: 16 db2sapdataSize: 50 db2logSize: 16 db2backupSize: 50 db2sapdataSSD: Yes db2logSSD: Yes usrsapSize: 0 sapmntSize: 0 swapSize: 0 otherHost: db2-ha-s2 # # (Comment section omitted from example) # - name: sap_db2_secondary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py # # By default, this configuration file uses the latest release of the deployment # scripts for SAP on Google Cloud. To fix your deployments to a specific release # of the scripts, comment out the type property above and uncomment the type property below. # # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py # properties: instanceName: db2-ha-s2 instanceType: n1-standard-4 zone: us-central1-f subnetwork: example-sap-subnetwork linuxImage: family/sles-12-sp3-sap linuxImageProject: suse-sap-cloud db2SID: DH1 db2sidSize: 16 db2dumpSize: 16 db2saptmpSize: 16 db2sapdataSize: 50 db2logSize: 16 db2backupSize: 50 db2sapdataSSD: Yes db2logSSD: Yes usrsapSize: 0 sapmntSize: 0 swapSize: 0 otherHost: db2-ha-s1
Deploy the VM instance with Deployment Manager.
gcloud deployment-manager deployments create DEPLOYMENT-NAME --config TEMPLATE-NAME.yaml
Where:
DEPLOYMENT-NAME
represents a name of your choosing for the current deployment. This name is used to identify this deployment on the Deployments page of the Google Cloud console.TEMPLATE-NAME
represents the name that you gave to the configuration file or, if you didn't change the name of the default file,template_ha.yaml
.
Deployment Manager reads the specifications in the
template_ha.yaml
file and configures the VM and persistent disks accordingly. The process might take a few minutes. To check the progress of your deployment, follow the steps in the next section.
Verifying deployment
To verify deployment, you check the deployment logs in Cloud Logging and check the configuration of the VM.
Check the logs
In the Google Cloud console, open Cloud Logging to monitor installation progress and check for errors.
Filter the logs:
Logs Explorer
In the Logs Explorer page, go to the Query pane.
From the Resource drop-down menu, select Global, and then click Add.
If you don't see the Global option, then in the query editor, enter the following query:
resource.type="global" "Deployment"
Click Run query.
Legacy Logs Viewer
- In the Legacy Logs Viewer page, from the basic selector menu, select Global as your logging resource.
Analyze the filtered logs:
- If
"--- Finished"
is displayed, then the deployment processing is complete and you can proceed to the next step. If you see a quota error:
On the IAM & Admin Quotas page, increase any of your quotas that do not meet the IBM DB2 requirements that are listed in the IBM DB2 for SAP planning guide.
On the Deployment Manager Deployments page, delete the deployment to clean up the VMs and persistent disks from the failed installation.
Rerun your deployment.
- If
Check the configuration of the VM
After VM deployment is complete, connect to each VM by using
ssh
. From the Compute Engine VM instances page, you can click the SSH button for each VM instance, or you can use your preferred SSH method.Change to the root user.
sudo su -
At the command prompt, enter
df -h
. Ensure that you see output similar to the following:db2-ha-s1:~ # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.4G 0 7.4G 0% /dev tmpfs 12G 0 12G 0% /dev/shm tmpfs 7.4G 18M 7.4G 1% /run tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup /dev/sda1 30G 2.2G 26G 8% / /dev/mapper/vg_db2sid-vol 16G 33M 16G 1% /db2/DH1 /dev/mapper/vg_db2dump-vol 16G 33M 16G 1% /db2/DH1/db2dump /dev/mapper/vg_db2sapdata-vol 50G 33M 50G 1% /db2/DH1/sapdata /dev/mapper/vg_db2saptmp-vol 16G 33M 16G 1% /db2/DH1/saptmp /dev/mapper/vg_db2log-vol 16G 33M 16G 1% /db2/DH1/log_dir /dev/mapper/vg_db2home-vol 16G 33M 16G 1% /db2/db2dh1 /dev/mapper/vg_db2backup-vol 50G 33M 50G 1% /db2backup tmpfs 1.5G 0 1.5G 0% /run/user/1001
If any of the validation steps show that the installation failed:
- Correct the error.
- On the Deployments page, delete the deployment to clean up the VMs and persistent disks from the failed installation.
- Rerun your deployment.
Reserving a floating IP address
You need to select an IP address to use as the floating IP address. You need this IP address later when you set the host VM instance metadata and when you install and configure IBM db2 and the HA cluster.
Depending on whether you choose a route or alias IP implementation type for your floating IP address, the requirements for the floating IP address are different.
If you are using the static route implementation for your floating IP address, the IP address must be outside of your subnetwork IP address range and cannot be used by anything else in your organization's extended networks. Consult with your network admin to determine an appropriate IP address to use.
If you are using the alias IP address implementation for your floating IP address, you must reserve an IP address from the IP address range of the subnetwork that the hosts are using.
For alias IP address implementations only, reserve an alias IP address:
Open a terminal on a host VM or open Cloud Shell.
Reserve an IP address.
gcloud compute addresses create vip-name --region region --subnet subnet-name \ --addresses ip-addr-optional
Specifying the addresses property is optional. If you don't enter an IP address, Compute Engine selects an IP address from your subnetwork for you.
Display and make a note the reserved IP address to use when you install the database server and configure the HA cluster.
gcloud compute addresses describe vip-name --region=region
For example:
db2-ha-s1:~ # gcloud compute addresses describe db2-ha-vip-dh1 --region=us-central1 address: 10.1.0.30 addressType: INTERNAL creationTimestamp: '2018-11-28T11:34:14.478-08:00' description: '' id: '6558342813288977241' kind: compute#address name: db2-ha-vip-dh1 region: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/addresses/db2-ha-vip-dh1 status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/subnetworks/example-sap- subnetwork
Adding the floating IP address to the metadata for each host VM instance
You specify information about your floating IP address, including your chosen route or alias IP implementation type, as custom metadata for each VM instance in the cluster. For more information about choosing an implementation type for your floating IP address, see Floating IP addresses for IBM Db2 HA clusters on Google Cloud.
Depending on your implementation type, the metadata parameters that you set are different. In the following two sections, follow the instructions in the section that applies to your floating IP address implementation
Setting metadata for a route implementation of the floating IP address
If you are using a route implementation for your floating IP address, use the parameters in the following table and the procedure that follows the table to set the instance metadata.
Parameter | Value | Purpose |
---|---|---|
sap_ibm_vip_solution |
route |
Indicates that this is a multi-zone deployment that uses a Google Cloud static route to support switching the floating IP address between hosts. |
sap_ibm_db2_vip |
ip-address | Specifies the floating IP address that you reserved in the previous step. |
sap_ibm_db2_routename |
route-name | Specifies an arbitrary name for the static route. For
example, you could use db2-dh1-vip-route |
sap_ibm_db2_routenet |
vpc-network-name | Specifies the VPC network that contains the IBM Db2 HA cluster. |
To set your instance metadata for a static route implementation of your floating IP address:
Open a terminal on a host VM or open Cloud Shell.
For each host VM instance in the cluster, specify the same metadata for the route implementation of the floating IP address.
gcloud compute instances add-metadata instance-name \ --metadata sap_ibm_vip_solution=route,sap_ibm_db2_vip=ip-address,\ sap_ibm_db2_routename=route-name,sap_ibm_db2_routenet=vpc-network-name \ --zone instance-zone
Setting metadata for an alias IP address implementation of the floating IP address
If you are using an alias IP address implementation for your floating IP address, use the parameters in the following table and the procedure that follows the table to set the instance metadata.
Parameter | Value | Purpose |
---|---|---|
sap_ibm_vip_solution |
alias |
Indicates that this is a single-zone deployment that uses a Google Cloud alias IP address to support switching the floating IP address between hosts. |
sap_ibm_db2_vip |
ip-address | Specifies the floating IP address that you reserved in the previous step. |
sap_ibm_db2_vip_range |
alias-ip-range-name | Optionally, specifies an arbitrary name for the alias
IP range. For example, you could use db2-dh1-vip-alias
The default value is the subnetwork name. |
To set your instance metadata for an alias IP implementation of your floating IP address:
Open a terminal on a host VM or open Cloud Shell.
For each host VM instance in the cluster, specify the same metadata for the alias IP address implementation of the floating IP address.
gcloud compute instances add-metadata instance-name \ --metadata sap_ibm_vip_solution=alias,sap_ibm_db2_vip=ip-address,\ sap_ibm_db2_vip_range=alias-ip-range-name --zone instance-zone
Reviewing or changing your instance metadata
To review the instance metadata that you set.
gcloud compute instances describe instance-name --zone instance-zone
If you need to change your custom metadata.
gcloud compute instances add-metadata instance-name --metadata parm-name=parm-value
Adding host names and IP addresses to /etc/hosts
During cluster setup, the SAP cluster setup tool validates the host
names and internal IP addresses of each host VM and of
the floating IP address. To ensure that the validation is successful, add
the IP address, host name, and the VPC
internal DNS name
for each host VM and the floating IP address to the /etc/hosts
file on
each host VM by using your preferred editor.
For example, as root, the following example updates /etc/hosts
:
echo "#Db2 HA floating IP additions" >> /etc/hosts echo 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal >> /etc/hosts echo 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal >> /etc/hosts echo 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal >> /etc/hosts
In the preceding example, the string between the host name and >>
on each line
is a VPC internal DNS name, which is used by the
VPC internal DNS service.
The host VMs use a zonal internal DNS name, which includes a field for the zone. The floating IP address uses a global internal DNS name, which doesn't include a zone field.
For a VM host, you can retrieve the internal DNS name by entering the following command from a terminal on the host VM:
curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \ -H "Metadata-Flavor: Google"
For a floating IP address, you can enter it yourself by using the following format.
vip-host-name.c.project-name.internal
After you update the /etc/hosts
file, the relevant information in the
/etc/hosts
file should look similar to the following example:
#Db2 HA floating IP additions 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal
Preparing the operating system
After you have created your VM, prepare the operating system for the IBM Db2 HA cluster.
The requirements are defined by SAP and IBM. The SAP documentation calls for installing software, such as Perl and Korn Shell, that might not be pre-installed on your Compute Engine host VMs.
Check the following documents for the latest requirements:
IBM Db2 high availability solution: IBM Tivoli System Automation for Multiplatforms
1984787 - SUSE LINUX Enterprise Server 12: Installation notes
2002167 - Red Hat Enterprise Linux 7.x: Installation and Upgrade
Installing the database server and creating the IBM Db2 HA cluster
Before you start following the instructions in IBM Db2 High availability solution: IBM Tivoli System Automation for Multiplatforms to install and configure IBM Db2 and the HA cluster, review the overview of the following procedure, paying particular attention to the notes.
To install SAP NetWeaver and the primary application server, see the Google Cloud SAP NetWeaver documentation and the applicable SAP installation guides available from the SAP Help Portal.
The following steps are an overview of the installation procedure. Refer to the SAP documentation for details.
Establish key-based SSH connectivity between the primary and secondary instances and between each instance and itself as described in the SAP documentation. SSH is used by the SAP cluster setup tool. Test all connections on each host. For example, on
db2-ha-s1
test both of the following.ssh db2-ha-s1
ssh db2-ha-s2
Download or copy the complete SAP media set for Db2 to your VM from the SAP support portal.
On the primary host VM, use the SAP Software Provisioning Manager (SWPM) to install the IBM Db2 database server.
On the secondary host VM, set up the standby database by using a method such as SAP homogeneous system copy.
On both host VMs, install the license files for IBM Db2 and IBM TSAMP. For more information about installing the IBM licenses that you obtained from SAP, see SAP Note 816773 - DB6: Installing an SAP OEM license.
On both host VMs, install the latest version of TSAMP, as supported by your database version and operating system version.
On the primary host VM, use the latest version of the SAP cluster setup tool
sapdb2cluster.sh
to configure and create the IBM Db2 HA cluster.After the cluster is created, on the primary host, use the DB2 high-availability instance configuration utility (db2haicu) utility to test that the cluster can failover.
Exit the SAP cluster setup tool and the Korn shell.
On the primary instance, confirm that the primary database server is online.
lssam
In the following example excerpt from the
lssam
output, the primary database instance is online:Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1 '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
Switch to the database instance user.
sudo su - db2sid
Start the db2haicu utility.
db2haicusid
In the db2haicu interface, select option 5 and follow the prompts.
Exit the db2haicu utility.
On the primary host, check that the secondary host is now online.
lssam
In the following example excerpt from the lssam output, the secondary database instance is online:
Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs |- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1 '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
To complete the cluster configuration, follow the instructions in the next section to create a custom TSAMP resource for the floating IP address and associate it in TSAMP with the IBM Db2 instance resource.
Creating a TSAMP custom resource for the floating IP address
To enable TSAMP to manage the floating IP address, you need to create a TSAMP custom resource for it. To enable TSAMP to interact with Google Cloud while managing the floating IP address resource, you need to download and configure a helper script from Google Cloud.
Download the Google Cloud helper script
On each host in the cluster, download the Google Cloud helper script and set its permissions.
On both the primary and standby hosts, as the root user from the
/root
directory on the primary VM, download the script.For instances not using a shared VPC configuration:
For instances using a shared VPC configuration:wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip.sh -O gcp_floating_ip.sh
wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/sap_db2/utility/gcp_floating_ip_svpc.sh -O gcp_floating_ip.sh
On both hosts, set the permissions on the script.
chmod 744 gcp_floating_ip.sh
Create and configure a TSAMP custom resource for your floating IP address
On any one host in the cluster, create and configure a TSAMP custom resources for the floating IP address.
On any one host, use your preferred method to create a configuration file called
cluster_res.conf
and paste the following text in it after you update the NodeNameList parameter with your host names.PersistentResourceAttributes:: Name="gcp_floating_ip-rs" ResourceType=1 StartCommand="/root/gcp_floating_ip.sh start" StopCommand="/root/gcp_floating_ip.sh stop" MonitorCommand="/root/gcp_floating_ip.sh status" MonitorCommandPeriod=30 MonitorCommandTimeout=30 StartCommandTimeout=600 StopCommandTimeout=600 UserName="root" RunCommandsSync=1 ProtectionMode=0 NodeNameList={"host-1","host-2"}
On the primary host as the root user, create the TSAMP custom resource with the following commands.
export CT_MANAGEMENT_SCOPE=2 mkrsrc -f cluster_res.conf IBM.Application mkrg -l None gcp_floating_ip-rg chrg -o Online gcp_floating_ip-rg addrgmbr -g gcp_floating_ip-rg -m F IBM.Application:gcp_floating_ip-rs rgreq -o start gcp_floating_ip-rg
On the primary host as the root user, confirm that the Db2 instance resource that is online is on the same host as the online floating IP resource.
lssam
In the output, the online resources should all be on the same host VMs:
Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1 '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2 Online IBM.ResourceGroup:gcp_floating_ip.sh_rg Nominal=Online '- Online IBM.Application:gcp_floating_ip.sh_rs |- Online IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s1 '- Offline IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s2
If the floating IP address resource isn't online on the same host that the database instance is, move the floating IP address resource.
rgreq -o move -n host-to-move-from gcp_floating_ip-rg
As the root user on the primary host, establish a relationship in TSAMP between the database instance resource and the floating IP address resource.
rgreq -o lock gcp_floating_ip-rg rgreq -o lock db2_db2sid_db2sid_SID-rg mkrel -o NoCondition -p Collocated \ -S IBM.Application:gcp_floating_ip-rs -G IBM.Application:db2_db2sid_db2sid_SID-rs \ db2hadr_colo_gcp_floating_ip rgreq -o unlock db2_db2sid_db2sid_SID-rg rgreq -o unlock gcp_floating_ip-rg
After you establish a relationship between the database instance resource and the floating IP address resource, you can test failover again, as described in the next section.
Verifying the deployment of your Db2 HA cluster for SAP on Google Cloud
To confirm that the IBM Db2 HA cluster is configured correctly, trigger a failover and check that all of the online resources move from one host VM to the other.
To perform a failover test.
On the primary host as the root user, note which host VM the online resources are currently on.
lssam
On the primary host, change to the db2 instance user.
sudo su - db2sid
Start the db2haicu utility.
db2haicu
In the db2haicu utility interface, trigger a failover by selecting option 5 and following the prompts.
After the db2haicu utility finishes processing, exit the utility.
Switch to the root user.
sudo su -
Confirm that the online resources have moved to the other host VM.
Validate your installation of Google Cloud's Agent for SAP
After you have deployed a VM and installed your SAP system, validate that Google Cloud's Agent for SAP is functioning properly.
Verify that Google Cloud's Agent for SAP is running
To verify that the agent is running, follow these steps:
Establish an SSH connection with your host VM instance.
Run the following command:
systemctl status google-cloud-sap-agent
If the agent is functioning properly, then the output contains
active (running)
. For example:google-cloud-sap-agent.service - Google Cloud Agent for SAP Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2022-12-02 07:21:42 UTC; 4 days ago Main PID: 1337673 (google-cloud-sa) Tasks: 9 (limit: 100427) Memory: 22.4 M (max: 1.0G limit: 1.0G) CGroup: /system.slice/google-cloud-sap-agent.service └─1337673 /usr/bin/google-cloud-sap-agent
If the agent isn't running, then restart the agent.
Verify that SAP Host Agent is receiving metrics
To verify that the infrastructure metrics are collected by Google Cloud's Agent for SAP and sent correctly to the SAP Host Agent, follow these steps:
- In your SAP system, enter transaction
ST06
. In the overview pane, check the availability and content of the following fields for the correct end-to-end setup of the SAP and Google monitoring infrastructure:
- Cloud Provider:
Google Cloud Platform
- Enhanced Monitoring Access:
TRUE
- Enhanced Monitoring Details:
ACTIVE
- Cloud Provider:
Performing post-deployment tasks
Before using your IBM Db2 high-availability system on Google Cloud, we recommend that you complete all of the post-installation activities that are documented in IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms, including.
Validating the database cluster.
Backing up the TSAMP core policy.
Updating the database fix packs.
Updating Db2 client connections to use the host name and IP address of the floating IP address. For example, update the
db2cli.ini
file on the SAP ABAP application servers.
If you are using a NAT gateway with your DB2 HA cluster, complete the set up of the NAT gateway, as described in Completing the NAT gateway installation in the IBM Db2 for SAP deployment guide.