IBM Support

Adding a database instance to an Azure Redhat OpenShift (ARO) cluster using the Db2 Operator

General Page

This tutorial walks you through a database deployment, using the Db2 Operator, on the Azure Redhat OpenShift Service (ARO). There are many configuration options available to you, based on your size, performance, and redundancy requirements. In this tutorial, you'll be provided with options to create single-partition instances of either Db2 or Db2 Warehouse, or a multi-partition Db2 Warehouse instance. 

Objective

Completing the tutorial gives you a working database instance on Azure Redhat OpenShift Service (ARO). Steps include: 

  • Setting up an Azure account. 

  • Creating an Azure ARO cluster. 

  • Setting up Azure Disk storage to be used as the backend for Red Hat OpenShift Data Foundation (ODF).

  • Setting up storage for your cluster using ODF. 

  • Deploying a Db2 database instance to your ARO cluster. 

  • Connecting to the Db2 database externally. 

Overview of a Db2/Db2 Warehouse on ARO configuration 

Deploying a Db2 or Db2 Warehouse database on ARO can be summarized as follows: 

  1. Your system administrator creates an Azure account and chooses a managed service platform for your database instance. You can run your database on the following Azure managed services: 
    • Azure Red Hat OpenShift Service (ARO).
  2. Using a series of command-line tools, your administrator creates an ARO cluster based on your specific requirements. For storage, ODF should be installed on the cluster.
  3. Your administrator runs the Db2 Operator and deploys your database instance to your ARO cluster. 

Once your database instance is deployed, users can connect to that database in the same way they connect to an on-premises data source. 

The flowchart below shows how users interact with the database instance when it is hosted on Azure Redhat OpenShift Service: 

Db2 and Db2 Warehouse on ARO

Choosing an Azure 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, go to the list of Azure VM instance types to find the Azure VM instance type that's right for your database deployment. In addition to the sizing values shown in the tables, the instance type list shows other factors to consider, such as cost and region. 

For Online Transactional Processing (OLTP) database workloads, choose an instance from the General Purpose or Memory Optimized categories

Table 1. Sizing guidelines for Db2 OLTP on ARO systems:

Table 1. Sizing guidelines for Db2 OLTP on ARO systems

Size 

CPUs 

Memory (GB) 

Azure Instance Type 
(Suggested) 

Description 

Small 

24 

  • Standard_DS4_v2 

  • Standard_D8s_v3 

  • Standard_D8as_v4 

  • Standard_D8ds_v4 

  • Standard_D8ads_v5 

  • Standard_D8ds_v5 

  • Entry level, departmental OLTP workloads. 

  • Five concurrent connections. 

  • 500 GB of data and logs. 

Medium 

16 

128 

General Purpose 

  • Standard_D32as_v4 

  • Standard_D32ds_v4 

  • Standard_D32ads_v5 

  • Standard_D32ds_v5 

Memory Optimized 

  • Standard_DS15_v2 

  • Standard_E16bds_v5 

  • Standard_E16bs_v5 

  • Standard_E16s_v3 

  • Standard_E16ds_v4 

  • Standard_E16as_v4 

  • Standard_E16ads_v5 

  • Standard_E16ds_v5 

  • Mid-range, line-of-business OLTP workloads. 

  • 1.4 TB of data and logs. 

Large 

49 

1001 

  • Standard_M64s 

  • High-end Enterprise OLTP workloads. 

  • 11 TB of data and logs. 

For more information on OLTP Db2 environments, see IBM Db2 database product portal
For Db2 Warehouse workloads on single-partition or multi-partition environments, choose an instance from the Memory Optimized category. 

Table 2. Sizing guidelines for a single-partition Db2 Warehouse on ARO systems 

Table 1. Sizing guidelines for Db2 OLTP on ARO systems

Size 

CPUs 

Memory (GB) 

Azure Instance Type 
(Suggested) 

Description 

Small 

98

  • Standard_DS14-8_v2[1] 

  • Standard_E16-8as_v4[1] 

  • Standard_E16bds_v5 

  • Standard_E16bs_v5 

  • Standard_E16-8s_v3[1] 

  • Standard_E16-8ds_v4[1] 

  • Standard_E16-8ads_v5[1] 

  • Standard_E16-8ds_v5[1] 

  • 2 TB uncompressed data. 

  • 500 GB storage. 

Medium 

15 

226

  • Standard_E32-16as_v4[1] 

  • Standard_E32bds_v5 

  • Standard_E32bs_v5 

  • Standard_E32-16s_v3[1] 

  • Standard_E32-16ds_v4[1] 

  • Standard_E32-16ads_v5[1] 

  • Standard_E32-16ds_v5[1] 

  • 4 TB uncompressed data. 

  • 1 TB storage. 

Large 

31

482

  • Standard_E64-32as_v4[1] 

  • Standard_E64bds_v5 

  • Standard_E64bs_v5 

  • Standard_E64-32s_v3[1] 

  • Standard_E64-32ds_v4[1] 

  • Standard_E64-32ads_v5[1] 

  • Standard_E64-32ds_v5[1] 

  • 8 TB uncompressed data. 

  • 2 TB storage. 

[1] Is based on Constrained vCPU capable VM sizes available on Azure, which allows a higher memory-to-core ratio than the standard VM types, which then allows more appropriate vCPU licensing for memory-heavy applications such as databases.

Table 3. Sizing guidelines for a multi-partition Db2 Warehouse on ARO systems

Table 3. Sizing guidelines for a Db2 Warehouse MPP on ARO systems
Size CPUs  Memory (GB)  Azure Instance Type 
(Suggested)
Description 
Small 39
610

4 vCPU per partition 

2 partitions per pod 

5 pods 

  • Standard_E16-8s_v3[1] 

  • Standard_E16-8ds_v4[1] 

  • Standard_E16-8ads_v5[1] 

  • Standard_E16-8ds_v5[1] 

4 vCPU per partition 

3 partitions per pod 

3 pods 

  • Standard_E32-16as_v4[1] 

  • Standard_E32bds_v5 

  • Standard_E32bs_v5 

  • Standard_E32-16s_v3[1] 

  • Standard_E32-16ds_v4[1] 

  • Standard_E32-16ads_v5[1] 

  • Standard_E32-16ds_v5[1] 

4 (8) vCPU per partition 

4(2) partitions per pod 

2 pods 

  • Standard_E64-32as_v4[1] 

  • Standard_E64-32s_v3[1] 

  • Standard_E64-32ds_v4[1] 

  • Standard_E64-32ads_v5[1] 

  • Standard_E64-32ds_v5[1] 

16 vCPU per partition 

2 partitions per pod 

1 pod 

  • Standard_E96-48as_v4[1] 

  • Standard_E96-48ads_v5[1] 

  • Standard_E96-48ds_v5[1] 

  • 20 TB of uncompressed data. This sizing estimate is for the entire Db2 deployment (all Db2 Warehouse database partitions). 

  • 4 to 32 vCPUs per Db2 Warehouse database partition. 

  • Use a memory (in GB) to vCPU ratio of 8:1 to 32:1, with 16:1 or higher being the optimal range. 

  • Note: The optimal number of Db2 Warehouse database partitions per pod depends on the memory-to-core ratio as well as the ability to scale out or provide fail-over. 

Medium 77 1201

4 vCPU per partition 

3 partitions per pod 

6 pods 

  • Standard_E32-16as_v4[1] 

  • Standard_E32-16s_v3[1] 

  • Standard_E32-16ds_v4[1] 

  • Standard_E32-16ads_v5[1] 

  • Standard_E32-16ds_v5[1] 

8 vCPU per partition 

2 partitions per pod 

4 pods 

  • Standard_E64-16as_v4[1] 

  • Standard_E64-16s_v3[1] 

  • Standard_E64-16ds_v4[1] 

  • Standard_E64-16ads_v5[1] 

  • Standard_E64-16ds_v5[1] 

16 vCPU per partition 

2 partitions per pod 

2 pods 

  • Standard_E96-48as_v4[1] 

  • Standard_E96-48ads_v5[1] 

  • Standard_E96-48ds_v5[1] 

32 vCPU per partition 

2 partition per pod 

1 pod 

  • Standard_M128-64ms[1] 

40 TB of uncompressed data. 
Large 153 2406

4 vCPU per partition 

3 (4) partitions per pod 

12 (10) pods 

  • Standard_E32-16as_v4[1] 

  • Standard_E32-16s_v3[1] 

  • Standard_E32-16ds_v4[1] 

  • Standard_E32-16ads_v5[1] 

  • Standard_E32-16ds_v5[1] 

4 vCPU per partition 

4 partitions per pod 

8 pods 

  • Standard_E64-32as_v4[1] 

  • Standard_E64-32s_v3[1] 

  • Standard_E64-32ds_v4[1] 

  • Standard_E64-32ads_v5[1] 

  • Standard_E64-32ds_v5[1] 

4 vCPU per partition 

8 partitions per pod 

5 pods 

  • Standard_E64-32as_v4[1] 

  • Standard_E64-32s_v3[1] 

  • Standard_E64-32ds_v4[1] 

  • Standard_E64-32ads_v5[1] 

  • Standard_E64-32ds_v5[1] 

4 (8) vCPU per partition 

6 (3) partitions per pod 

6 pods 

  • Standard_E64-32as_v4[1] 

  • Standard_E64-32s_v3[1] 

  • Standard_E64-32ds_v4[1] 

  • Standard_E64-32ads_v5[1] 

  • Standard_E64-32ds_v5[1] 

6 vCPU per partition 

8 partitions per pod 

4 pods 

  • Standard_E96-48as_v4[1] 

  • Standard_E96-48ads_v5[1] 

  • Standard_E96-48ds_v5[1] 

8 vCPU per partition 

8 partitions per pod 

3 pods 

  • Standard_M64 

  • Standard_M64s 

16 vCPU per partition 

8 partitions per pod 

2 pods 

  • Standard_M128s 

  • Standard_M128 

80 TB of uncompressed data. 
[1] Is based on Constrained vCPU capable VM sizes available on Azure, which allows a higher memory-to-core ratio than the standard VM, which then allows more appropriate vCPU licensing for memory-heavy applications such as databases. 

For more information on single or multi-partition Db2 warehouse environments, see IBM Db2 Warehouse database product portal

NOTE: The resource requirements mentioned above are specific to installing and deploying Db2u. If other applications are being deployed, plan the resource sizing accordingly.

Planning Storage

This document describes configuring OpenShift Data Foundation (ODF) as the storage solution for Db2u. ODF requires a minimum of  three nodes and can currently only be installed using internal mode. 

Resource requirements for basic services: 

  • 30 CPU (logical) 

  • 72 GB memory 

  • 3 storage devices 

Refer to the Red Hat ODF planning your deployment documentation for understanding resource requirements. 

The following diagram shows how storage is distributed in a single-partition Db2 formation: 
Db2 cluster formation on the Azure Kubernetes Service (AKS)

The following diagram show how storage is distributed in a Db2 multi-partition Warehouse formation: 

A Db2 Warehouse cluster formation on the Azure Kubernetes Service (AKS)

Creating an Azure OpenShift Cluster (ARO) 
Before you begin
You will need to install the following command-line tools locally. These are required to interact with Azure infrastructure and Kubernetes control plane.  
  • az: Azure CLI command-line utility for creating and managing Kubernetes or OpenShift clusters on Azure. When you first use Azure CLI, install the Azure CLI extension. For more information about extensions, see Use extensions with the Azure CLI. Run az version to find the version and dependent libraries that are installed. To upgrade to the latest version, run az upgrade.  
  • oc: OpenShift command-line utility that is used to communicate with the cluster API server 

Environment 

Before you start the configuration, you need to set some variables locally that are used for this tutorial. When choosing the naming convention for these variable values, we adapted best practices described in Azure Define your naming convention - Cloud Adaptation Framework topic. These variables are:

  • PRINCIPAL_ID: The Azure account name that will be used to do all the steps in this tutorial.  

    export PRINCIPAL_ID=<>
  • SUBSCRIPTION_ID: Your Azure subscription ID associated with your Azure account. 

    export SUBSCRIPTION_ID=<>
  • LOCATION: The region where your Azure instances are being deployed. Use eastus

    export LOCATION=eastus
  • RESOURCE_GROUP: An Azure resource group is a logical group in which Azure resources are deployed and managed. Use rg-db2-demo-eastus-001

    export RESOURCE_GROUP=rg-db2-demo-eastus-001
  • CLUSTER: The name you use for your ARO Cluster. Use aro- db2-demo-eastus-001

    export CLUSTER=aro-db2-demo-eastus-001 
  • NODE_VM_SIZE: The kind of Azure VM size to select for deploying Db2 workloads in the user node pool:
    • For single-partition Db2 instances, use Standard_D8as_v4

      export NODE_VM_SIZE=Standard_D8as_v4
    • For single-partition Db2 Warehouse instances, use  Standard_E16-8as_v4

      export NODE_VM_SIZE=Standard_E16-8as_v4
    • For multi-partition Db2 Warehouse instances, use  Standard_E64-32ds_v4

      export NODE_VM_SIZE=Standard_E64-32ds_v4
  • NUM_NODES: The minimum number of VM nodes for the Azure cluster: 
    • For single-partition Db2 instances, use  3.

      export NUM_NODES=3
    • For single-partition Db2 Warehouse instances, use  3

      export NUM_NODES=3
    • For multi-partition (small) Db2 Warehouse instances, use 6

      export NUM_NODES=6
    • NOTE: Single-partition Db2 instances only require one node. In this case, the minimum number of nodes is set to 3 to support ODF installation. 

  • NODE_VM_DISK_SIZE: The worker node disk size in Gigabytes (per node). This should be determined in sizing based on the number of nodes, workload size and the kind of storage that is being installed. This tutorial uses ODF as the storage provider and its corresponding requirements.
    export NODE_VM_DISK_SIZE=1024
  • NAMESPACE: The namespace where your database instance will be deployed. Use db2u

    export NAMESPACE=db2u
  • DB2U_CLUSTER: The name used in the metadata section of the db2ucluster custom resource used for deploying Db2. Use db2-aro-demo.  

    export DB2U_CLUSTER=db2-aro-demo
  • LOAD_BALANCER_SVC: The name used in the metadata section of the Public Load Balancer service will expose Db2 database connection outside the ARO cluster. Use lb-db2-demo-eastus-001

    export LOAD_BALANCER_SVC=lb-db2-demo-eastus-001
  • ARO_VNET: The name of the virtual network to be created for the ARO cluster.
    export ARO_VNET=db2-ocp-vnet
  • ARO_CLUSTER: The name of the ARO cluster to be created.
    export ARO_CLUSTER=db2-ocp
  • ARO_MASTER_SUBNET: The name of the subnet to be created for the master nodes.
    export ARO_MASTER_SUBNET=db2-ocp-master-subnet
  • ARO_WORKER_SUBNET: The name of the subnet to be created for the worker nodes.
    export ARO_WORKER_SUBNET=db2-ocp-worker-subnet
Steps

Create an Azure account 

Before you begin to create your Azure cluster, you need to have an Azure account. 

  1. From a web browser, go to https://azure.microsoft.com/

  2. Follow the online instructions. 
    NOTE: You will be contacted by phone and be required to enter a verification code on your phone keypad.

Sign in with Azure CLI 

Azure provides numerous authentication methods. We describe the two most common methods bellow. 

  • Interactively using device code flow which will open a browser page with the one-time-passcode (OTP) that you can enter into the CLI terminal to complete the login process: 

    az login
  • Non-interactively by providing the credentials in the CLI command: 

    az login – u <user> -p <password>

Refer to Azure topic Sign in with Azure CLI for details on all the supported authentication methods. 

Grant appropriate access to resources 

When you allow access to Azure resources, it's always a best practice to provide users with the least privilege that's required to do a given task. You can grant access to resources in Azure using two schemes: 

  • Azure role-based access control (Azure RBAC): you can grant access to user accounts (principals) at a specified scope: subscription, resource group, or individual resources. Azure RBAC lets you deploy resources into a resource group and grant permissions to a specific user or group. 
  • Service Principal (SP) objects: Along with providing access to user principals and groups, you can grant the same access to a service principal. 

In this tutorial we will use Azure RBAC for granting access to the principal user at subscription scope for the Azure built-in role Contributor. 

Add API Permission to Service Principal 

OpenShift requires permissions to perform tasks on behalf of the cluster, hence a Service Principal needs to be created and assigned to ARO with the required RBAC. Azure Active Directory (Azure AD) is required to authenticate this SP assigned to this ARO installation. Access to Azure AD is required to complete the following steps.
  1. Create a Service Principal for configuring the Azure AD integration. You will also need sufficient Azure AD permissions (either a member user of the tenant, or a guest user assigned with role Application administrator) to create an application and service principal on your behalf for the cluster.
    az ad sp create-for-rbac --role Contributor --name ${PRINCIPAL_ID} --scopes "/subscriptions/${SUBSCRIPTION_ID}"
    The above command will return the appID and password. Save the values as appID and appPassword which will be later used during cluster creation.
    appID=<> 
    appPassword=<>
  2. Add User.Read permission to the service principal.
    az ad app permission grant --id ${appID} --api 00000003-0000-0000-c000-000000000000 --scope User.Read
Register the Resource Providers
  1. Set the relevant subscription ID if you have multiple Azure subscriptions:
    az account set –subscription "${SUBSCRIPTION_ID}"
  2. Register the Microsoft.RedhatOpenShift resource provider:
    az provider register -n Microsoft.RedhatOpenShift --wait
  3. Register the Microsoft.Compute resource provider:
    az provider register -n Microsoft.Compute --wait
  4. Register the Microsoft.Storage resource provider:
    az provider register -n Microsoft.Storage --wait
  5. Register the Microsoft.Authorization resource provider:
    az provider register -n Microsoft.Authorization --wait
Get a Red Hat Pull Secret to access Red Hat Container Registries
A Red Hat pull secret is required to access Red Hat container registries. This is required to enable Db2u on the OpenShift cluster.
  1. Access the Red Hat account by logging in or create an account.
  2. Click Download Pull Secret to download a pull secret to be used by the ARO cluster. Save the pull secret in a file redhat-pull-secret.txt. This secret will later be used when creating the cluster.
Create a virtual network containing two empty subnets
ARO requires a virtual network (vNet) with two empty subnets for master and worker nodes. 
  1. Create a resource group:
    az group create –-name ${RESOURCE_GROUP} –-location ${LOCATION}
  2. Create a virtual network:
    az network vnet create \ 
          –-resource-group ${RESOURCE_GROUP} \ 
          --name ${ARO_VNET} \ 
          --address-prefixes 10.0.0.0/22
  3. Add an empty subnet for the master node:
    az network vnet subnet create \ 
          –-resource-group ${RESOURCE_GROUP} \ 
          --vnet-name ${ARO_VNET} \ 
          --name ${ARO_MASTER_SUBNET} \ 
          --address-prefixes 10.0.0.0/23
  4. Add an empty subnet for the worker node:
    az network vnet subnet create \ 
          –-resource-group ${RESOURCE_GROUP} \ 
          --vnet-name ${ARO_VNET} \ 
          --name ${ARO_WORKER_SUBNET} \ 
          --address-prefixes 10.0.0.0/23 
Create the ARO Cluster
NOTE: Pass the --pull-secret @path-to- redhat-pull-secret.txt to enable access to container registries. The Red Hat image pull secret was downloaded in the previous steps.
az aro create \ 
      --resource-group ${RESOURCE_GROUP} \ 
      --name ${ARO_CLUSTER} \ 
      --client-id ${appID} \ 
      --client-secret ${appPassword} \ 
      --vnet ${ARO_VNET} \ 
      --master-subnet ${ARO_MASTER_SUBNET} \ 
      --worker-subnet ${ARO_WORKER_SUBNET} \ 
      --worker-count ${NUM_NODES} \ 
      --worker-vm-size ${NODE_VM_SIZE} \ 
      --worker-vm-disk-size-gb ${NODE_VM_DISK_SIZE} \ 
      --pull-secret @path-to-redhat-pull-secret.txt 
It typically takes about 35 minutes to create a cluster after running the above command.
Connect to the ARO Cluster
Once the cluster is deployed you can connect to cluster using the kubeadm user.
  • Run the following command to retrieve the password for kubeadm user:
    az aro list-credentials \ 
          --name ${ARO_CLUSTER} \ 
          --resource-group ${RESOURCE_GROUP} 
     
    kube_user=$(az aro list-credentials --name ${CLUSTER} --resource-group ${RESOURCE_GROUP} | jq -r .kubeadminUsername) 
    kube_password=$(az aro list-credentials --name ${CLUSTER} --resource-group ${RESOURCE_GROUP} | jq -r .kubeadminPassword) 
  • Run the below command to the get the URL to the ARO OpenShift Console:
    az aro show \ 
    --name ${ARO_CLUSTER} \ 
    --resource-group ${RESOURCE_GROUP} 
    --query "consoleProfile.url" -o tsv
  • Run the below command to get API server url for logging in from command line:
    url=$(az aro show -g ${RESOURCE_GROUP} -n ${CLUSTER} --query apiserverProfile.url -o tsv)
Launch the console URL in the browser and login using kubeadm credentials.
To connect to the OpenShift cluster using oc from command line, run the following command:
oc login ${url} -u ${kube_user} -p ${kube_password}
Configuring Storage on the ARO Cluster

Installing OpenShift Data Foundation (ODF) 

Red Hat ODF can be deployed in 3 modes: Internal, Internal-Attached, and External Mode. On ARO, only internal mode is supported.  

To install a specific version of the OpenShift Data Foundation, check the Supportability and Interoperability Guide to find the supported ODF versions for a specific OpenShift version. 

The below steps are documented based on this command line installation article for OpenShift Data Foundation. 

For a complete installation guide, follow the official documentation on OpenShift Data Foundation installation on Microsoft Azure. 

Installing the ODF Operator 

  • Create the openshift-storage namespace:
    cat <<EOF | oc apply -f - 
    apiVersion: v1 
    kind: Namespace 
    metadata: 
     labels: 
       openshift.io/cluster-monitoring: "true" 
     name: openshift-storage 
    spec: {} 
    EOF
  • Create the openshift-storage-operatorgroup in the above namespace:
    cat <<EOF | oc apply -f - 
    apiVersion: operators.coreos.com/v1 
    kind: OperatorGroup 
    metadata: 
     name: openshift-storage-operatorgroup 
     namespace: openshift-storage 
    spec: 
     targetNamespaces: 
     - openshift-storage 
    EOF 
  • Subscribe to the odf-operator for version 4.9 or later:
    cat <<EOF | oc apply -f - 
    apiVersion: operators.coreos.com/v1alpha1 
    kind: Subscription 
    metadata: 
     name: odf-operator 
     namespace: openshift-storage 
    spec: 
     channel: "stable-4.9" 
     installPlanApproval: Automatic 
     name: odf-operator 
     source: redhat-operators 
     sourceNamespace: openshift-marketplace 
    EOF 
  • Label the nodes where ODF is to be installed. In this example, we are installing ODF on three nodes. 
    oc label node <node name> cluster.ocs.openshift.io/openshift-storage=''
    NOTE: ODF should be installed in multiples of 3 nodes.
  • Create the StorageCluster Custom Resource (CR) and specify managed-premium as the backend storage class:
    cat <<EOF | oc apply -f - 
    apiVersion: ocs.openshift.io/v1 
    kind: StorageCluster 
    metadata: 
     name: ocs-storagecluster 
     namespace: openshift-storage 
    spec: 
     manageNodes: false 
     resources: 
       mds: 
         limits: 
           cpu: "3" 
           memory: "8Gi" 
         requests: 
           cpu: "3" 
           memory: "8Gi" 
     monDataDirHostPath: /var/lib/rook 
     storageDeviceSets: 
     - count: 1   
       dataPVCTemplate: 
         spec: 
           accessModes: 
           - ReadWriteOnce 
           resources: 
             requests: 
               storage: "100Gi" 
           storageClassName: managed-premium 
           volumeMode: Block 
       name: ocs-deviceset 
       placement: {} 
       portable: false 
       replica: 3 
       resources: 
         limits: 
           cpu: "2" 
           memory: "5Gi" 
         requests: 
           cpu: "2" 
           memory: "5Gi" 
    EOF
    NOTES: 
    • Under .spec.storageDeviceSets, a count of 1 represents a set of three OSDs. If you need to have more than one storageDeviceSet, then increment the count sequentially.  

    • Under .spec.storageDeviceSets, for each storageDeviceSet in the list, spec.resources.requests.storage represents the storage size (minimum being 100Gi and maximum 4Ti). The underlying backend storage is using managed-premium which uses the disks provisioned along with cluster creation. NODE_DISK_VM_SIZE * NUM_NODES is the total available storage on the cluster. 

  • Verify if all the pods are up and running:
    oc get pods -n openshift-storage
  • List CSV to see that ocs-operator is in Succeeded phase:
    ​oc get csv -n openshift-storage
  • Storage Classes created with this installation are:
    • ocs-storagecluster-cephfs for shared volume (RWX)
    • ocs-storagecluster-ceph-rbd for local block volume (RWO)  
The above steps will create a storage pool with replication factor set to three (default) for data protection. If three-way replication is not required, it can be reduced to two-way replication by creating a new storage pool. See here for details. 

Deploy a database instance on the ARO cluster 

When you have finished creating your ARO cluster and configured your cloud storage option, 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 ARO cluster you will need to complete the following tasks: 

  • Create a CatalogSource object in the openshift-marketplace namespace to install the Db2 operator.  

  • Create the namespace for the Db2 operator.  

  • Deploy the Db2 operator in the namespace.  

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

Procedure 

  1. Log in to your ARO cluster. 
  2. Install the ibm-db2uoperator-catalog in the namespace where openshift-marketplace is installed: 
    cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: ibm-db2uoperator-catalog
      namespace: openshift-marketplace
    spec:
      displayName: IBM Db2U Catalog
      image: icr.io/cpopen/ibm-db2uoperator-catalog@sha256:d8b79c87951e3c6659a5901f8e85136cc803b8553e7c05e77a1031704906519b
      publisher: IBM
      sourceType: grpc
      updateStrategy:
        registryPoll:
          interval: 45m
    EOF
    
  3. Create a namespace for installing the Db2 operator: 
    cat <<EOF | oc apply -f - 
    apiVersion: v1 
    kind: Namespace 
    metadata: 
      name: ${NAMESPACE} 
    spec: {} 
    EOF 
  4. Install an operator group in the namespace: 
    cat << EOF | oc apply -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 | oc create -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: ibm-db2uoperator-catalog-subscription
      namespace: ${NAMESPACE}
      generation: 1
    spec:
      channel: v110508.0
      name: db2u-operator
      installPlanApproval: Automatic
      source: ibm-db2uoperator-catalog
      sourceNamespace: olm
      startingCSV: db2u-operator.v110508.0.0
    EOF
  6. Check that the db2u-operator pod is deployed: 
    oc 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: 
    Parameters common to this code include:
    Parameters common to this code include:
    Field  Values 
    (with examples) 
    Description 
    metadata.name  db2oltp-test  The name of the Db2uCluster CR.
    metadata.namespace db2u  The namespace where the database instance will be deployed.
    .spec.size 1 The number of Db2 nodes. 
    For single-partition Db2 and Db2 Warehouse instances, the value is 1; For multi-partition Db2 Warehouse instances, the value can be 2 or greater. 
    .spec.environment.database.name BLUDB  The database name for the instance.
    .spec.environment.dbType db2oltp  Accepted values: db2wh, db2oltp.
    .spec.environment.ldap.enabled false  To enable LDAP, set this to true.
    .spec.license.accept true This is a required value that must be set to true.
    .spec.podConfig.resource.db2u.limits.cpu "2" The CPU limits for the db2u engine pods. Limits and request are set to the same value (which is the expected value). 
    .spec.podConfig.resource.db2u.limits.memory 8Gi  The memory limits for the db2u engine pods. Limits and request are set to same value (which is the expected value). 
    .spec.version s11.5.8.0  The Db2u version that the operator supports. The value in the left column is the latest release. 
    .spec.storage [] An array of storage configurations. This is the required storage configuration for meta and data (or shared). 
  8. Check the status of your Db2uCluster: 
    oc get db2ucluster -n ${NAMESPACE} ${DB2U_CLUSTER}
    DB2U_CLUSTER is the name value set in the metadata section of the YAML code. For example, 
    name: db2oltp-test
    NOTE: You can define an alternate value for name by using the db2ucluster custom resource
  9. When the STATE value returned is Ready, the instance is deployed successfully. 
    oc -n ${NAMESPACE} get db2ucluster ${DB2U_CLUSTER} 
    NAME                      STATE   MAINTENANCESTATE          AGE 
    db2-001234567890          Ready         None               6h8m 
  10. Log on to the database engine pod as db2inst1
    oc -n ${NAMESPACE} exec -it $(oc get pods -n ${NAMESPACE} | grep ${DB2U_CLUSTER}-db2u-0 | awk '{print $1}') -- su - db2inst1 
  11. Connect to the database bludb on your Azure cluster: 
    db2 connect to bludb
    NOTE: While we are using the database name bludb for this tutorial, you can change this name by using the db2ucluster custom resource
Connecting to Db2 database from outside the ARO cluster

To connect to the Db2 database that you deployed on ARO externally, you need to create a Kubernetes LoadBalancer service to expose Db2 engine TCPIP listener port (50000). 

Create an External Load Balancer service 

Issue the following oc command after logging into the deployed ARO cluster to create a Load Balancer service to expose Db2 engine TCPIP listener port. 

In the example below, we are exposing the non-SSL Db2 port number 50000 for a Db2 Warehouse deployment. 

cat <<EOF | oc apply -f - 
apiVersion: v1 
kind: Service 
metadata: 
  name: ${LOAD_BALANCER_SVC} 
  namespace: ${NAMESPACE} 
spec: 
  ports: 
  - port: 50000 
    protocol: TCP 
    targetPort: 50000 
  selector: 
    app: ${DB2U_CLUSTER} 
    component: db2wh 
    formation_id: ${DB2U_CLUSTER} 
    role: db 
    type: engine 
  externalTrafficPolicy: Local 
  type: LoadBalancer 
EOF 

NOTES: 

  • The component value in the Label selector used to create the Load Balancer service must match the value used in Db2uCluster CR spec field environment.dbType

  • The default Load Balancer externalTrafficPolicy is set to Cluster which takes an extra hop to obscure the client source IP. By changing the externalTrafficPolicy setting to Local, the client source IP is preserved. Avoiding this extra hop results in improved stability of in-bound connections.  

After the Load Balancer service is created, a public (external) IP is generated, and the target port defined in the service spec is exposed. You can query the service created in the cluster to get this information using following oc command:

oc get svc -n ${NAMESPACE} | grep ${LOAD_BALANCER_SVC} 
lb-db2-demo-eastus-001               LoadBalancer   10.0.247.179
20.127.178.10
50000:30856/TCP
     14d d 
You can test if this Load Balancer service endpoint is accessible from outside the ARO cluster using a curl command similar to the following example:
curl -kv 20.127.178.10:50000 
*   Trying 20.127.178.10:50000... 
* Connected to 20.127.178.10 (20.127.178.10) port 50000 (#0) 
> GET / HTTP/1.1 
> Host: 20.127.178.10:50000 
> User-Agent: curl/7.79.1 
> Accept: */* 

[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"ARM Category":[{"code":"a8m500000008Pm6AAE","label":"Install\/Migrate\/Upgrade-\u003EDatabase Upgrade"},{"code":"a8m3p000000LPvoAAG","label":"Openshift"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"11.5.7;and future releases"}]

Document Information

Modified date:
21 April 2023

UID

ibm16850833