Deploying Db2 using the Db2uCluster custom resource

Once the Db2 Operator is installed, the Db2uCluster custom resource (CR) provides the interface required to deploy Db2. This CR is supported by an OpenShift Custom Resource definition.

Accessing the Db2uCluster custom resource

You deploy Db2® by running Db2uCluster CR commands through a YAML script. You can do this in several ways:

Through the Red Hat® OpenShift® console.
Through the Red Hat OpenShift command-line tool.
Through the command-line tool of a Kubernetes cluster.

To use the Red Hat OpenShift console, go to Installed Operators > IBM Db2 and click the Db2uCluster tab. Through this tab page you create your Db2 instance, either by following the on-screen instructions of the form view, or by entering and running the YAML script.

The following sections cover CR options that can be included in the YAML file. An example of a completed Db2uCluster CR is also included.

Configure the Db2 Version

Specifies the version of the Db2 database based on the Db2 operator installed

spec:
  version: "11.5.7.0-cn<container layer release number>"

For a list of Db2 Operator versions, see Table 1 of Db2 on Red Hat OpenShift.

Configure the database name

Specifies the name of the desired Db2 database.

The following example shows how to configure the database name:

spec:
  environment:
    database:
      name: bludb

Deploy on a dedicated node

Specifies how to target labels on specific nodes for dedicated deployments. Deploying on dedicated nodes is a best practice in production. See Setting up dedicated nodes for your Db2 deployment.

The following example shows how to deploy a dedicated node:

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: database
            operator: In
            values:
            - db2u-affinity
  tolerations:
  - effect: NoSchedule
    key: database
    operator: Equal
    value: db2u-affinity

Configure memory and CPU consumption

When deploying Db2 using the Db2 Operator, you have the ability to assign a CPU and Memory profile. This will assign CPU/MEM values to the container running the Db2 Common SQL Engine.

The following example shows how set memory and CPU limits for your Db2 instance:

spec:
  podConfig:
    db2u:
      resource:
        db2u:
          limits:
            cpu: 2
            memory: 4Gi

Configure storage

Configure separate storage areas for the following storage categories:

meta shared storage volume for db2 meta data.
data non-shared storage volume for database storage.
backup shared storage volume for backing up the database (optional).
activelogs non-shared storage volume for transactional logs (optional). For more information, see Creating separate storage for database transaction logs.
tempts non-shared storage volume for temporary tablespaces (optional). For more information, see Creating separate storage for temporary table spaces.

Note: With certain storage solutions, the same storage class can be specified for both.

For example,

spec:
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template
  - name: activelogs
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template
  - name: backup
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: tempts
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template

See Certified storage options for Db2 for a full list of for supported storage solutions.

Use persistent storage claims

Existing persistent volume claims can be used also for deployment.

The following example shows the adding of an existing single, shared volume claim:

storage:
  - claimName: metapvc
    name: <shared-pvc-name>
    spec:
      resources: {}
    type: existing

The following example shows the adding of four existing and separate volume claims:

storage:
  - claimName: <meta-pvc-name>
    name: meta
    spec:
      resources: {}
    type: existing
  - claimName: <meta-pvc-name>
    name: data
    spec:
      resources: {}
    type: existing
  - claimName: <backup-pvc-name>
    name: backup
    spec:
      resources: {}
    type: existing
  - claimName: <activelogs-pvc-name>
    name: activelogs
    spec:
      resources: {}
    type: existing
  - claimName: <tempts-pvc-name>
    name: tempts
    spec:
      resources: {}
    type: existing

Enabling 4K support

When your Db2 on OpenShift deployment is configured to use either OpenShift Container Storage (OCS) or Portworx container storage (PX), ensure that you have enabled 4K support.

The following example code shows the 4K support set to ON:

spec:
  environment:
    ...
    instance:
      registry:
        DB2_4K_DEVICE_SUPPORT: "ON"

Disabling LDAP

The LDAP directory service is enabled by default. The following example shows how to disable LDAP:

spec:
  environment:
    ldap:
      enabled: false

Disabling the Node Port service

Important: This configuration is only available for new deployments. Once the custom resource is created, do not modify this field.

By default, the creation of the Db2u instance activates a nodeport service, for moving external data into your cluster. You can disable this behavior by setting disableNodePortService to true:

spec:           
  environment:
    database:
      disableNodePortService: true

Deploying a Db2 instance with limited privileges

You can set parameters in your CR to create the Db2 instance with limited privileges. This option improves security. The following example shows how to set limited privileges:

spec:
  account:
    privileged: false

Overriding the default database settings

You can override the default database settings for your Db2 instance.

CAUTION:

You should only override the default database settings if you are aware of the risks involved. If you are at all unsure, accept the default settings.

The following example shows how to set the database values for your Db2 instance:

spec:
  environment:
    database:
      settings:
        dftTableOrg: "COLUMN"
        dftPageSize: "32768"
        encrypt: "NO"
        codeset: "UTF-8"
        territory: "US"
        collation: "IDENTITY"

Overriding the Db2 database configuration (dbConfig) settings

You can override the default database configuration settings for your Db2 instance.

CAUTION:

You should only override the dbConfig settings if you are aware of the risks involved. If you are at all unsure, accept the default settings.

The following example shows how to set the dbConfig values fpr your Db2 instance:

spec:
  environment:
    database:
      dbConfig:
        LOGPRIMARY: "50"
        LOGSECOND: "35"
        APPLHEAPSZ: "25600"
        STMTHEAP: "51200 AUTOMATIC"

Setting the Db2 registry variable

You can override the default Db2 registry variable values for your Db2 instance.

CAUTION:

You should only override the Db2 registry variable settings if you are aware of the risks involved. If you are at all unsure, accept the default settings.

The following example shows how to set the Db2 registry variable values for your Db2 instance:

spec:
  environment:
    instance:
      registry:
        DB2_ATS_ENABLE: "NO"
        DB2_OBJECT_STORAGE_SETTINGS: "OFF"
        DB2_DISPATCHER_PEEKTIMEOUT: "2"
        DB2_COMPATIBILITY_VECTOR: "ORA"

Example of a complete Db2uCluster CR

The following example shows the CR code to deploy a Db2u Cluster. The CR creates a Db2OLTP instance with the following configuration:

Database name: BLUDB.
4 CPUs.
16 GB of memory.
5 storage volumes (meta, data, backup, activelogs, and tempts).
DB2 4K SUPPORT enabled.
LDAP disabled.
Privileged instance.

apiVersion: db2u.databases.ibm.com/v1
kind: Db2uCluster
metadata:
  name: db2oltp-test
  namespace: db2u
spec:
  account:
    privileged: true
  environment:
    database:
      name: bludb
    dbType: db2oltp
    ldap:
      enabled: false
  license:
    accept: true
  podConfig:
    db2u:
      resource:
        db2u:
          limits:
            cpu: "4"
            memory: 16Gi
  size: 1
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template
  - name: backup
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 1Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: activelogs
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template
  - name: tempts
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-ceph-rbd
    type: template
  version: 11.5.7.0-cn4