Db2uInstance Custom Resource Configuration (Next Gen Operator)

General Page

You can configure the Db2uInstance Custom Resource (CR) for deployments using the Db2U Next Gen operator. Use this reference to customize your Db2 deployment for production, security, and performance needs.

The Db2U next generation operator introduces a streamlined, Kubernetes-native approach to deploying and managing Db2 and Db2 Warehouse services. As part of this model, the Db2uInstance Custom Resource (CR) serves as the central configuration object for defining how your Db2 instance should be deployed and operated.

You deploy Db2 by running Db2uInstance CR commands through a YAML script. This can be done through either the Red Hat OpenShift command-line tool or the command-line tool of a Kubernetes cluster.

The following sections cover CR options that can be included in the YAML file.

Configure the Db2 container image

Use the spec.image field to define the container image, for example:

spec:
  image: icr.io/db2u/db2u.db2wh:12.1.3.0

If you're deploying in a network-isolated (air-gapped) environment and have mirrored the images to a private registry, use the imageRegistryOverride field, for example:

spec:
  imageRegistryOverride: true
  image: localregistry.io/db2u/db2u.db2wh:12.1.3.0

Enabling SSL connections to Db2

To enable SSL (wire encryption) connections to Db2 or to enable the Datalake add-on, you can add new settings in your Custom Resource (CR) with a custom ssl secret to create the Db2uInstance.

For this, you need to create a secret (db2ssl-certs) containing the private key and certificate for the CA before creating the Db2uInstance resource. There are two options to do this:

Option 1: Automatically generate SSL certificates with a cert-manager:

Multi-Tier Hierarchy (Root CA → N-1 Intermediate CAs → Server Cert) Create a certificate chain of any depth by specifying the number of intermediate CAs.
Two-Tier Hierarchy (Root CA → Server Cert) (default).
Self-Signed Certificate (Server Cert only).

Steps:
1. Deploy and configure a certificate manager on the cluster to issue certificates according to your enterprise policies.

2. Submit a request to the certificate manager to create a certificate and associated secret as required, for example:

kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-bootstrap
  namespace: ${NAMESPACE}
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ${DB2_NAME}-ca
  namespace: ${NAMESPACE}
spec:
  isCA: true
  commonName: ${DB2_NAME}-local-ca
  secretName: ${DB2_NAME}-ca
  issuerRef:
    name: selfsigned-bootstrap
    kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ${CERT_ISSUER}
  namespace: ${NAMESPACE}
spec:
  ca:
    secretName: ${DB2_NAME}-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: db2ssl-certificate
  namespace: ${NAMESPACE}
spec:
  secretName: db2ssl-certs
  secretTemplate:
    labels:
      com.db2u.databases.ibm.com/ssl-cert: ${DB2_NAME}
  duration: 21600h
  renewBefore: 360h
  commonName: ${DB2_NAME}
  dnsNames:
    - localhost
    - "*.c-${DB2_NAME}-db2u-head-engn-svc.${NAMESPACE}.svc"
    - "*.c-${DB2_NAME}-db2u-head-engn-svc.${NAMESPACE}.svc.cluster.local"
    - "*.c-${DB2_NAME}-db2u-engn-svc.${NAMESPACE}.svc.cluster.local"
    - "*.c-${DB2_NAME}-db2u-internal.${NAMESPACE}.svc.cluster.local"
    - "*.c-${DB2_NAME}-db2u-internal.${NAMESPACE}.svc"
    ${DNS_ENTRIES}
  ipAddresses:
    - 127.0.0.1
  privateKey:
    algorithm: RSA
    size: 2048
  issuerRef:
    name: ${CERT_ISSUER}
    kind: Issuer
EOF

Where $DB2_NAME is the name of the target Db2uInstance resource and $NAMESPACE is the namespace in which it will be deployed.

The secret is then referenced in the ssl section of the Db2uInstance CR at deployment time as follows:

    ssl:
      fromVolumeSource:
        secret:
          secretName: db2ssl-certs
          items:
            - key: tls.crt
              path: tls.crt
            - key: tls.key
              path: tls.key
            - key: ca.crt  
              path: ca.crt

Option 2: Bring Your Own Certificate:

Create a certificate by providing your own tls.crt, tls.key, and ca.crt and letting the script create the Kubernetes secret.

Steps:
1. Place a copy of the tls.key, ca.crt and tls.crt on the bastion/client node and run the following command to create the secret:

kubectl -n ${NAMESPACE} create secret generic db2ssl-certs \ 
  --from-file=tls.crt=./tls.crt \
  --from-file=tls.key=./tls.key \ 
  --from-file=ca.crt=./ca.crt

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. For more information, see Setting up dedicated nodes for your Db2 or Db2 Warehouse on Red Hat OpenShift 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 can 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 to 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).
Active logs 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.
Non-shared storage volume for temporary table spaces (optional). For more information, see Creating separate storage for temporary table spaces.
Archive logs 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 storage, existing storage, or are 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 configuring template storage for data, active logs, or temporary table spaces, 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 or Db2 Warehouse for a full list of supported storage solutions.

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"

LDAP authentication

In order to configure Db2 to authenticate users via an external LDAP, you must create an LDAP settings ConfigMap with the required settings to connect to your LDAP server.

The following is an example ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: db2u-ldap-settings
data:
  IBMIAMauthldap.ini: |
    ;----------------------------------------------------------------------
    ; SERVER RELATED VALUES
    ;----------------------------------------------------------------------
    ; LDAP_HOST
    ; Name of your LDAP server(s).
    ; This is a space separated list of LDAP server hostnames or IP
    ; addresses, with an option port number for each one:
    ; host1[:port] [host2:[port2] ... ]
    ; The default port number is 389, or 636 if SSL is enabled.
    LDAP_HOST = 9.30.44.141:389
    ; FIPS_MODE
    ; To set SSL encryption FIPS mode on or off.
    ; Optional; Valid values are true (on) and false (off). Defaults to
    ; true (FIPS mode on).
    FIPS_MODE = true
    ;---------------------------------------------------------------------- 
    ; USER RELATED VALUES
    ;----------------------------------------------------------------------
    ; USER_OBJECTCLASS
    ; LDAP object class used for users
    ; Generally "inetOrgPerson" ("user" for MSAD)
    ; internal ldap: 'posixAccount'
    USER_OBJECTCLASS = user
    ; USER_BASEDN
    ; LDAP base DN to use when searching for users.
    ; This is optional. If not specified, user searches will
    ; start at the root of the LDAP directory. Some LDAP servers (particularly
    ; MSAD) may require that you specify a value for this parameter.
    ; internal ldap: 'ou=People,dc=blustratus,dc=com'
    USER_BASEDN = cn=ldapsecp,cn=users,dc=dlud,dc=torolab,dc=ibm,dc=com
    ; USERID_ATTRIBUTE
    ; LDAP user attribute that represents the "userid"
    ; This attribute is combined with the USER_OBJECTCLASS and USER_BASEDN
    ; (if specified) to construct an LDAP search filter when a user issues
    ; a DB2 CONNECT statement with an unqualified userid.
    ; For example, using the default values in this configuration file,
    ;    db2 connect to MYDB user bob using bobpass
    ; results in the following search filter:
    ;    &(objectClass=inetOrgPerson)(uid=bob)
    ; For MSAD, this is frequently "sAMAccountName".
    ; internal ldap: 'uid'
    USERID_ATTRIBUTE = uid
    ; AUTHID_ATTRIBUTE
    ; LDAP user attribute that represents the DB2 "authorization ID"
    ; (typically this is the same as the USERID_ATTRIBUTE).
    ; Again, for MSAD this is frequently "sAMAccountName".
    ; internal ldap: 'uid'
    AUTHID_ATTRIBUTE = uid
    ;----------------------------------------------------------------------
    ; GROUP RELATED VALUES
    ;----------------------------------------------------------------------
    ; GROUP_OBJECTCLASS
    ; LDAP object class used for groups
    ; Generally "groupOfNames" or "groupOfUniqueNames" ("group" for MSAD)
    ; internal ldap: 'posixGroup'
    GROUP_OBJECTCLASS = group
    ; GROUP_BASEDN
    ; LDAP base DN to use when searching for groups
    ; This is optional. If not specified, group searches will
    ; start at the root of the LDAP directory. Some LDAP servers (MSAD)
    ; require that you specify a value for this parameter.
    ; internal ldap: 'ou=Groups,dc=blustratus,dc=com'
    GROUP_BASEDN = cn=test area 1,cn=ldapsecp,cn=groups,dc=dlud,dc=torolab,dc=ibm,dc=com
    ; GROUPNAME_ATTRIBUTE
    ; LDAP group attribute that represents the name of the group
    ; internal ldap: 'cn'
    GROUPNAME_ATTRIBUTE = cn
    ; GROUP_LOOKUP_METHOD
    ; Determines the method used to find the group memberships for a user.
    ; Possible values are:
    ;  SEARCH_BY_DN - Search for groups that list the user as a member.
    ;                 Membership is indicated by the group attribute defined
    ;                 as GROUP_LOOKUP_ATTRIBUTE (typically "member" or
    ;                 "uniqueMember").
    ; USER_ATTRIBUTE - A user's groups are listed as attributes of the user
    ;                  object itself. Search for the user attribute defined
    ;                  as GROUP_LOOKUP_ATTRIBUTE to get the groups (typically
    ;                  "memberOf" for MSAD or "ibm-allGroups" for ITDS).
    ; Many MSAD installation use "GROUP_LOOKUP_METHOD = USER_ATTRIBUTE" and
    ; "GROUP_LOOKUP_ATTRIBUTE = memberOf".
    ; internal ldap: 'SEARCH_BY_DN'
    GROUP_LOOKUP_METHOD = SEARCH_BY_DN
    ; GROUP_LOOKUP_ATTRIBUTE
    ; Name of the attribute used to determine group membership, as described
    ; above.
    ; internal ldap: 'memberUid'
    GROUP_LOOKUP_ATTRIBUTE = memberUid
    
    ;----------------------------------------------------------------------
    ; MISCELLANEOUS VALUES
    ;----------------------------------------------------------------------
    ; SEARCH_DN and SEARCH_PW
    ; If your LDAP server does not support anonymous access, or if anonymous
    ; access is not sufficient when searching for users or groups, then you
    ; can define a DN and password that will be used to perform searches.
    ; Optional.
    ;
    ; MSAD does not, by default, allow anonymous search and will require
    ; a SEARCH_DN and SEARCH_PW.
    ; internal ldap:
    ;   SEARCH_DN = 'cn=bluldap,dc=blustratus,dc=com'
    ;   SEARCH_PW is created for db2credman
    SEARCH_DN = cn=db2public,dc=dlud,dc=torolab,dc=ibm,dc=com
    SEARCH_PW_STASHFILE = 
/mnt/blumeta0/home/db2inst1/sqllib/security64/plugin/IBM/server/IBMIAMauthpasswd.sth

For more information on creating the ConfigMap, see Setting up LDAP on Db2U Next Generation.

Next, to reference the ConfigMap, add the following section to the Db2uInstance CR at deployment time. This includes a database administrator user (admin), an administrator group (adminGroup), and a group of regular users (userGroup) who will be granted access to the database. Also include a password (searcherPassword) for the SEARCH_DN specified in the ConfigMap. Optionally, enable transparent LDAP by providing true for transparentLdap (false by default).

spec:
...
  environment:
    authentication:
      ldap:
        enabled: true
        admin: "regress1"
        userGroup: "db2grp1"
        adminGroup: "admingrp"
        searcherPassword:
          value: "password4ldap"
        fromVolumeSource:
          configMap:
            localObjectReference:
              name: "db2u-ldap-settings"

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 configure limited privileges using unsafe sysctls:

spec:
  account:
    securityConfig:
      privilegedSysctlInit: false

Override the default database settings at deployment time

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

Caution: You should only override the default database settings if you are aware of the risks involved.

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 and dbmConfig) settings at deployment time

You can override the default database configuration settings for your Db2 instance. This can only be done at the time of Db2uInstance creation. After this time, the ADMIN_CMD routine can be used.

Caution: You should only override the default database settings if you are aware of the risks involved.

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 variables at deployment time

You can override the default Db2 registry variable values for your Db2 instance at deployment time. This can only be done at the time of Db2uInstance creation.

Caution: You should only override the default database settings if you are aware of the risks involved.

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"

Update the Db2 database configuration (dbConfig and dbmConfig) settings on an existing instance (post deployment)

You can update the values of the database config, dbConfig, and database manager configs, dbmConfig, on an existing Db2uInstance using the ADMIN_CMD stored procedure via a SQL connection.

For example:

CALL SYSPROC.ADMIN_CMD('UPDATE DBM CFG USING DIAGLEVEL 1');

CALL SYSPROC.ADMIN_CMD ('UPDATE DB CFG USING sortheap 1000');

For configuration changes that are not dynamically applied to the engine, each db2u pod in the instance must be restarted:

kubectl -n <namespace> delete po c-<instance-name>-db2u-0
kubectl -n <namespace> delete po c-<instance-name>-db2u-1
..
kubectl -n <namespace> delete po c-<instance-name>-db2u-n

[{"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":"a8m3p000000LPvoAAG","label":"Openshift"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"12.1.3"}]

Tips

Db2uInstance Custom Resource Configuration (Next Gen Operator)

General Page

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?