Deploying Db2 using the Db2uInstance custom resource

Once the Db2 Operator is installed, the Db2uInstance custom resource (CR) provides the interface required to deploy Db2. This CR is supported by a Red Hat OpenShift CR definition.

Access the Db2uInstance custom resource

You deploy Db2 by running Db2uInstance 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 Db2uInstance tab. Through this tab page you create your Db2 either via the db2uCluster API (YAML View) or Db2uInstance CR to deploy Db2.

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

Configure the Db2 version

Specifies the version of the Db2 database based on the Db2 Operator installed
spec:
  version: "s11.5.9.0<container layer release number>"

Configure the database name

Specifies the name of the desired Db2 database.

The following example shows how to configure the database name:
spec: 
  environment:
    dbType: db2oltp
    databases:
      - 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:
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: database
            operator: In
            values:
            - db2u-affinity
  tolerations:
  - key: "database"
    operator: "Equal"
    value: "db2u-affinity"
    effect: "NoSchedule"

Configure memory and CPU consumption

When deploying Db2 using the Db2 Operator, you have the ability to assign a CPU and Memory profile. This assigns 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:
  podTemplate:
    db2u:
      resource:
        db2u:
          limits:
            cpu: 5
            memory: 8Gi

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). This is supported only for single-mode (SMP) deployment and not MPP. For more information, see Creating separate storage for database transaction logs.
  • tempts non-shared storage volume for temporary table spaces (optional). For more information, see Creating separate storage for temporary table spaces.
  • archivelogs shared storage volume for archive logs is mandatory. For more information, see Creating separate storage for database archive logs.
Note: With certain storage solutions, the same storage class can be specified for both.

The CR calls that you make depend on whether you are configuring new or existing storage, or configuring template storage.

For example, you can use the following CR call to configure new or existing storage:
spec:
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: backup
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: archivelogs
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
Note:

If you are deploying Q Replication, note that the following custom resource (CR) calls only work on Db2uInstance for Db2 Warehouse SMP or MPP. The calls will not work with Q Replication deployed on a Db2uInstance for online transaction processing (OLTP).

If you are configuring template storage for data, activelogs, or tempts, then you need to add the following CR calls under the databases section:
    databases:
      - name: BLUDB
        storage:
          - name: data
            type: template
            spec:
              accessModes:
                - ReadWriteOnce
              resources:
                requests:
                  storage: 100Gi
              storageClassName: ocs-storagecluster-ceph-rbd
          - name: activelogs
            type: template
            spec:
              accessModes:
                - ReadWriteOnce
              resources:
                requests:
                  storage: 10Gi
              storageClassName: ocs-storagecluster-ceph-rbd

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

Use existing persistent storage claims

Existing claims can be used also for deployment of any of the storage categories.

The following example shows the adding of six existing and separate volume claims:
storage:
  - claimName: <meta-pvc-name>
    name: meta
    spec:
      resources: {}
    type: existing
  - claimName: <data-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
  - claimName: <archivelogs-pvc-name>
    name: archivelogs
    spec:
      resources: {}
    type: existing

Enabling 4K support

When your Db2 on OpenShift deployment is configured to use either OpenShift Data Foundation (ODF) 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"

Internal LDAP

The LDAP directory service is enabled by default. See Internal LDAP for instructions on how to add and manage internal LDAP users. The following example shows how to disable LDAP:
spec:
  environment:
    authentication:
      ldap:
        enabled: false
Note: If you are deploying a Db2uInstance on version s11.5.8.0-cn1 with LDAP disabled and have an existing instance with LDAP enabled, or you are trying to disable LDAP on s11.5.8.0-cn2, see this troubleshooting doc first: Recovering a Db2u deployment from failure due to missing user-mgmt secret.

External LDAP

The following example shows how to configure external LDAP:
spec:
  environment:
    authentication:
       ldap:
          enabled: true
          admin: bluadmin
          externalLdap: 
            server: "my-ldap-server.example.com"
            port: "389"
            userGroup: usergrp
            adminGroup: admingrp
Note: External LDAP is only supported on Db2 11.5.9.0-cn2 and up. If you are patching an existing instance of Db2, you will also need to restart the Db2 pods and run the configure_user_management script from the Db2 pod on the head node. See External LDAP for more details.

Disable the Node Port service

By default, the creation of the Db2 instance activates a nodeport service, for moving external data into your cluster. The following example shows how to disable this behavior.
environment:
  disableNodePortService: true

Deploy 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 with unsafe sysctls:
spec:
  account: 
    securityConfig:                                                             
      privilegedSysctlInit: false
      
The following example shows how to set limited privileges by setting IPC kernel parameters on the nodes:
spec:
  account: 
    securityConfig:                                                             
      privilegedSysctlInit: false
  advOpts:
    hostIPC: true

Deploy Db2 with a custom service account

A service account is an OpenShift Container Platform account that allows a component to directly access the CR. You can set parameters in your CR to create the Db2 instance with a custom service account.

The following example shows how to set a custom service account to the same name of the custom service account that you just created:
spec:
  account:
    serviceAccountName: ${SERVICE_ACCOUNT}

Override 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:
   databases:
    - name: BLUDB
      settings:
        dftTableOrg: "COLUMN"
        dftPageSize: "32768"
        encrypt: "NO"
        codeset: "UTF-8"
        territory: "US"
        collation: "IDENTITY"   

Override 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 for your Db2 instance:
spec:
  environment:
    databases:
      - name: BLUDB
        dbConfig:
          LOGPRIMARY: "50"
          LOGSECOND: "35"
          APPLHEAPSZ: "25600"
          STMTHEAP: "51200 AUTOMATIC"

Set 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 Db2uInstance CR

The following example shows the CR code to deploy a Db2 Cluster. The CR creates a Db2 instance with the following configuration:
  • Database name: BLUDB.
  • 4 CPUs.
  • 16 GB of memory.
  • 5 storage volumes (meta, data, backup, archivelogs, and tempts).
  • DB2 4K SUPPORT enabled.
  • LDAP disabled.
  • Privileged instance.
apiVersion: db2u.databases.ibm.com/v1
kind: Db2uInstance
metadata:
  name: db2-example
spec:
  account:
    privileged: true
  environment:
    authentication:
      ldap:
        enabled: false
    databases:
    - dbConfig:
        APPLHEAPSZ: "25600"
        LOGPRIMARY: "50"
        LOGSECOND: "35"
        STMTHEAP: 51200 AUTOMATIC
      name: BLUDB
      storage:
        - name: data
          type: template
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 100Gi
            storageClassName: ocs-storagecluster-ceph-rbd
        - name: activelogs
          type: template
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
            storageClassName: ocs-storagecluster-ceph-rbd           
    dbType: db2oltp 
    instance:
      dbmConfig:
        DIAGLEVEL: "2"
      registry:
        DB2_4K_DEVICE_SUPPORT: "ON"
        DB2_ATS_ENABLE: "NO"
        DB2_DISPATCHER_PEEKTIMEOUT: "2"
        DB2_OBJECT_STORAGE_SETTINGS: "OFF"
    partitionConfig:
      dataOnMln0: true
      total: 1
      volumePerPartition: true
  license:
    accept: true
  nodes: 1
  podTemplate:
    db2u:
      resource:
        db2u:
          limits:
            cpu: 4
            memory: 16Gi
  storage:
  - name: meta
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: backup
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  - name: archivelogs
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
      storageClassName: ocs-storagecluster-cephfs
    type: create
  version: s11.5.9.0-cn2