Deploying Db2 or Db2 Warehouse on Google Cloud Platform

Deploying Db2 or Db2 Warehouse on Google Cloud Platform

You can deploy a Db2 or Db2 Warehouse database on Google Cloud Platform (GCP) using the Db2 Operator. Google Cloud Platform (GCP) provides the infrastructure and managed Kubernetes services needed to deploy, run, and manage a Db2 database instance in a cloud environment. This tutorial describes how to create a Db2 instance on GCP based on your size and performance requirements.

Objective

Completing the tutorial gives you a working database instance on Google Cloud Platform. 

Steps include:

• Choosing a GCP VM instance
• Setting local environment variables
• Creating a GCP cluster
• Deploying a database instance on your GCP cluster 

Overview 

1. A system administrator creates a GCP account and selects a managed service platform for the database instance. 

2. Using CLI tools, the administrator creates a GCP cluster and configures the instance type, file system, and storage classes.

3. After the GCP cluster is prepared, the administrator runs the Db2 Operator to deploy the Db2 or Db2 Warehouse instance to the GCP environment. 

    

Once the instance is deployed, users can connect to the database just as they would to an on‑premises data source.

Choosing a GCP VM instance type 
Use the information in the following tables to determine the size requirements of your Db2 or Db2 Warehouse instance. Based on your selection, choose the GCP VM instance type that's right for your database deployment. For more information, see Machine families resource and comparison guide. In addition to the sizing values shown in the tables, the instance type list shows other factors to consider, such as cost and region. 

The GCP machine types listed align closely with the target CPU-to-Memory ratios required by typical Db2 OLTP workloads. In addition to core sizing, these recommendations take into account cost efficiency and regional availability, ensuring optimal capacity.

Table 1. Sizing guidelines for Db2 OLTP on GCP

Table 2. Sizing guidelines for Db2 Warehouse SMP (single-partition) on GCP

Table 3. Sizing guidelines for Db2 Warehouse MPP (multi-partition) on GCP

Note: For MPP deployments, the vCPU and memory values reflect the total resources for the full deployment. Select the number of worker nodes based on the workload requirements. 
 

Choosing cloud storage

When choosing cloud storage options for your Db2 on GCP configuration, consider the following points:

• For database storage, log storage, and temporary tablespaces, use a block storage solution.
• For metadata storage and backup storage, use a shared file storage solution.

Google Cloud provides Persistent Disk (PD) for block storage and Filestore for shared file storage. The following diagrams show how storage is distributed in a Db2 OLTP formation and in a Db2 Warehouse MPP formation:

Before you begin
You must install the following command‑line tools locally. These tools are required to interact with Google Cloud Platform resources and the GKE Kubernetes control plane.

• gcloud: The Google Cloud CLI is used for creating and managing Google Kubernetes Engine (GKE) clusters. After installation, run gcloud init to authenticate your Google account and configure a default project. To update to the latest version, run gcloud components update.
• kubectl: The native Kubernetes command-line utility that is used to communicate with the cluster API server. You can install kubectl using gcloud components install kubectl.
• gke‑gcloud‑auth‑plugin: A required authentication plugin that enables kubectl to connect securely to GKE clusters. For more information, see Install required plugins.

Environment variables 

Before you start the configuration, set the following variables locally to be used in this tutorial. 

Note: Environment variables must be set for each shell session. When you open a new terminal or connect to the jumpbox, export the variables again. Any command that includes values such as ${VPC}, ${REGION}, or ${CLUSTER} requires these variables to be defined in the current session.

• PROJECT: A GCP project with billing enabled

  export PROJECT=nzby-gcp-build

• SERVICE_ACCOUNT: A custom service account for cluster, node pool, and jumpbox operations. 

  export SERVICE_ACCOUNT=nz-automation

• SA_EMAIL: Service account email.

  export SA_EMAIL=${SERVICE_ACCOUNT}@${PROJECT}.iam.gserviceaccount.com

• VPC: A VPC for the cluster.

  export VPC=db2u-gke-vpc

• SUBNET: A subnet in the VPC for the region where the cluster will be deployed.

  export SUBNET=db2u-gke-subnet

• REGION: Region where the cluster will be deployed.

  export REGION=us-central1

• ZONE: Specific zone in the region to deploy the nodes.

  export ZONE=us-central1-a

• ROUTER: A cloud router attached to the VPC.

  export ROUTER=db2u-nat-router

• NAT_GATEWAY: A NAT gateway so the private nodes can reach the internet.

  export NAT_GATEWAY=db2u-nat

• NAMESPACE: The namespace where your database instance will be deployed.

  export NAMESPACE=db2u

• NODE_POOL: The name of the node pool that will be added as worker nodes to the cluster.

  export NODE_POOL=db2u-nodepool

• NUM_NODES: The number of worker nodes that are to be provisioned in the node pool.

  export NUM_NODES=1

  Note: Db2 Warehouse MPP deployments require sufficient GKE worker node capacity. Before deploying an MPP instance, ensure that the cluster node pool is sized to meet the requirements defined in the Db2 Warehouse MPP YAML.

• INSTANCE_TYPE: The type of instance to use for provisioning worker nodes. Refer to the sizing guidelines.

  export INSTANCE_TYPE=n2-standard-8

• SSH_JUMPBOX: SSH jumpbox VM for connecting to the GKE cluster.

  export SSH_JUMPBOX=db2u-gke-jumpbox

• CLUSTER: GKE cluster name.

  export CLUSTER=db2u-gke-cluster

Procedure

Set up a Google Cloud account

1. Set up your Google Cloud account from https://cloud.google.com.

2. Create a new GCP project with billing enabled.

3. Install gcloud CLI. For more information, see Install the Google Cloud CLI.

4. Initialize the gcloud CLI to authenticate your Google account and select a default project:

gcloud init

Configure IAM Roles for the Service Account

The service account must have the roles/container.admin IAM role. This role is sufficient to create and manage GKE clusters, node pools, and to retrieve cluster credentials from a jumpbox. Run the following command to assign the roles/container.admin IAM role:

gcloud projects add-iam-policy-binding ${PROJECT} \ 
   --member="serviceAccount:${SA_EMAIL}" \ 
   --role="roles/container.admin" 

Set up a VPC and custom subnet in your desired location

To prepare the environment for your Google Kubernetes Engine (GKE) cluster, first configure the network foundation that the cluster will run on. GKE uses Google Cloud’s Virtual Private Cloud (VPC) networking, which provides an isolated, customizable network for your Db2 deployment. Creating a VPC and defining a custom subnet ensures that your cluster, nodes, and storage resources communicate securely and predictably during deployment.

1. Create a VPC in custom subnet mode to manually manage all subnet creation:

gcloud compute networks create ${VPC} --subnet-mode=custom

2. Create a subnet in the region:

gcloud compute networks subnets create ${SUBNET} --network=${VPC} --region=${REGION} --range=10.10.0.0/20

Configure a NAT gateway for the VPC for worker nodes to pull images

After creating the VPC and subnet, configure outbound internet access for the private worker nodes in your GKE cluster. Because these nodes do not use public IP addresses, a Cloud NAT gateway is required to allow the nodes to pull container images and access Google services during deployment. This configuration ensures that required Db2 components can be retrieved while the cluster remains in a private network.

1. Create a cloud router:

gcloud compute routers create ${ROUTER} --project=${PROJECT} --network=${VPC} --region=${REGION}

2. Create a NAT gateway and attach it to the cloud router created in the previous step:

gcloud compute routers nats create ${NAT_GATEWAY} --project=${PROJECT} --router=${ROUTER} --router-region=${REGION} --nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips --enable-logging

Configure cloud storage for GCP
Db2 on GCP requires both block storage and shared file storage. Block storage is provided through Persistent Disk (PD), and shared storage is provided through Filestore, Google Cloud’s managed NFS file service. Before the cluster can create Filestore‑backed persistent volumes through the Filestore CSI driver, the Google File API must be enabled in your project. The Google File API enables the creation and management of Filestore instances, and must be active for Kubernetes to provision ReadWriteMany (RWX) persistent volumes used by Db2 metadata, backup, and archive‑log storage.

Enable Google File API
Before the GKE cluster can provision the shared storage required by Db2, you must enable the Google File API in your project. Db2 relies on Google Filestore to provide ReadWriteMany (RWX) persistent volumes for metadata, backups, and archive logs, and the API is required for Kubernetes to create and manage these Filestore instances through the Filestore CSI driver. Enabling this API ensures that the cluster can automatically provision the shared storage components needed during deployment.

1.  Enable Google File API to install Google Filestore for shared storage on the GKE cluster:

gcloud services enable file.googleapis.com --project=${PROJECT}

Build a GKE cluster
Create a GKE cluster to host the Db2 Operator and the database instance. The cluster provides the Kubernetes environment required for the Db2 deployment, including support for private nodes and the Filestore CSI driver.

1. Run the following command to build a private cluster and enable the Google Filestore:

gcloud container clusters create ${CLUSTER} --region=${REGION} --network=${VPC} --subnetwork=${SUBNET} --num-nodes=1 --node-locations=${ZONE} --machine-type=e2-small --service-account=${SA_EMAIL} --addons=GcpFilestoreCsiDriver --enable-private-nodes --enable-ip-alias --workload-pool=${PROJECT}.svc.id.goog

2. Add a node pool to the GKE cluster:

gcloud container node-pools create ${NODE_POOL} --cluster=${CLUSTER} --region=${REGION} --node-locations=${ZONE} --num-nodes=${NUM_NODES} --machine-type=${INSTANCE_TYPE} --service-account=${SA_EMAIL}

Build a jumpbox to connect to the GKE cluster

A jumpbox is required to access the private GKE cluster because the worker nodes do not use public IP addresses. The jumpbox provides a controlled entry point for running commands against the cluster and includes the tools needed for authentication and administration during the Db2 deployment.

1. Create a firewall rule for IAP SSH:

gcloud compute firewall-rules create db2u-allow-iap-ssh --network=${VPC} --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=35.235.240.0/20 --target-tags=iap-ssh

2. Create a jumpbox VM:

gcloud compute instances create ${SSH_JUMPBOX} --zone=${ZONE} --machine-type=e2-micro --network=${VPC} --subnet=${SUBNET} --no-address --tags=iap-ssh --service-account=${SA_EMAIL} --scopes=https://www.googleapis.com/auth/cloud-platform

3. SSH to jumpbox via IAP:

gcloud compute ssh ${SSH_JUMPBOX} --zone=${ZONE} --tunnel-through-iap

4. Install tools on the jumpbox to be able to connect to the cluster:

sudo apt-get update
sudo apt-get install -y google-cloud-cli-gke-gcloud-auth-plugin kubectl

5. Get the GKE cluster credentials to be able to connect to the cluster:

gcloud container clusters get-credentials ${CLUSTER} --region ${REGION} --internal-ip

Note: After you SSH to the jumpbox, you must set the following environment variables again: CLUSTER, REGION, VPC, and NAMESPACE. 

Create a custom storage class and provide the VPC network

Before deploying the Db2 instance, you must define a storage class that the GKE cluster will use to provision shared file storage. Db2 requires shared storage for components such as metadata and backups, and on GCP this storage is provided through Google Filestore. The following storage class configuration enables GKE to create Filestore-backed persistent volumes with ReadWriteMany (RWX) access for these components.

1. Run the following command: 

cat << EOF | kubectl create -f -
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    components.gke.io/component-name: filestorecsi
    components.gke.io/component-version: 0.18.11
    components.gke.io/layer: addon
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
    k8s-app: gcp-filestore-csi-driver
  name: standard-db2u-rwx
parameters:
  tier: standard
  network: ${VPC}
provisioner: filestore.csi.storage.gke.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
EOF

Installing OLM to deploy the Db2 Operator
OLM is a component of the Operator Framework, an open source toolkit to manage Kubernetes native applications, called Operators, in an effective, automated, and scalable way. OLM extends Kubernetes to provide a declarative way to install, manage, and upgrade Operators and their dependencies in a cluster. You must install the OLM to run the Db2 Operator.

1. Create the OLM namespace:

kubectl create namespace olm

2. Install OLM:

curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.20.0/install.sh | bash -s v0.20.0

3. Check for pods in the olm namespace:

kubectl get pods -n olm

Deploying a database instance on a GCP cluster
After creating the GKE cluster and configuring storage, you can deploy one of the following instances to the cluster using the Db2 Operator:

• A single-partition instance of Db2.
• A single-partition instance of Db2 Warehouse.
• A multi-partition instance of Db2 Warehouse. 

When you log in to your GKE cluster you will need to complete the following tasks:

• Create the namespace for the Db2 Operator.
• Create a CatalogSource object in the olm namespace to install the Db2 Operator.
• Deploy the Db2 Operator in the namespace.

For information on how to modify your deployment, see Deploying Db2 using the Db2uInstance custom resource.

To deploy a database instance on a GCP cluster:

Deploy the Db2 Operator

1. Log in to your GCP cluster.

2. Install the ibm-db2uoperator-catalog in the namespace where olm is installed:

cat << EOF | kubectl create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: ibm-db2uoperator-catalog
  namespace: olm
spec:
  displayName: IBM Db2U Catalog
  image: icr.io/cpopen/ibm-db2uoperator-catalog@sha256:ac608e4f744be84997e0306e459f086a99223749bc29725045e3f673b1c0446b
  publisher: IBM
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 45m
EOF

3. Create a namespace for installing the Db2 Operator:

kubectl create namespace ${NAMESPACE}

4. Install an operator group in the namespace:

cat << EOF | kubectl create -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: db2u-operator-group
  namespace: ${NAMESPACE}
spec:
  targetNamespaces:
  - ${NAMESPACE}
EOF

5. Create a subscription in the namespace to deploy the Db2 Operator:

cat << EOF | kubectl create -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  generation: 1
  name: ibm-db2uoperator-catalog-subscription
  namespace: ${NAMESPACE}
spec:
  channel: v120104.0
  installPlanApproval: Automatic
  name: db2u-operator
  source: ibm-db2uoperator-catalog
  sourceNamespace: olm
  startingCSV: db2u-operator.v120104.0.0
EOF

6. Wait for the db2u operator pod to be ready:

kubectl get pods -n ${NAMESPACE} | grep db2u-operator

7. After the db2u-operator pod is up and running, run the YAML code to deploy your database instance. 
Choose from the following: 

• YAML for the Db2 instance.
• YAML for the single-partition Db2 Warehouse instance.
• YAML for the multi-partition Db2 Warehouse instance.

8. Check the status of your Db2uInstance:

kubectl get db2uinstance -n ${NAMESPACE} ${DB2U_INSTANCE_NAME}

When the STATE value returns Ready, the instance is deployed successfully.

Related links

Db2 and Db2 Warehouse containerized deployments