Db2 on Kubernetes

Claus Huempel <[email protected]>

Technical Sales, Hybrid Data Management, IBM Deutschland GmbH
 Legal Disclaimer
Copyright © IBM Corporation 2019 All rights reserved.
U.S. Government Users Restricted Rights - Use, duplication, or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO
VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS” WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON CURRENT THINKING REGARDING TRENDS AND
DIRECTIONS, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. FUNCTION DESCRIBED HEREIN MY NEVER BE DELIVERED BY IBM. IBM
SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY
OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY
WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF ANY
AGREEMENT OR LICENSE GOVERNING THE USE OF IBM PRODUCTS AND/OR SOFTWARE.

IBM, the IBM logo, ibm.com and Db2 are trademarks or registered trademarks of International Business Machines Corporation in the United States, other
countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™),
these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also
be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark
information” at www.ibm.com/legal/copytrade.shtml

2 IBM Cloud 2
 Agenda

▪ Micro Services and Containers

▪ Kubernetes Basics
▪ Deploying Db2 on Kubernetes
− Db2 OLTP Single Server
− Db2 OLTP HADR
− Data Server Manager (DSM)
▪ Additional Resources
▪ Summary

3 IBM Cloud
 Micro Services &
Containers

4 IBM Cloud
 Technology by itself is not the business disruptor.
Failing to be customer centric is the biggest business threat.

Netflix did not kill Blockbuster… ridiculous late fees and rewind fees did.
Uber did not kill the taxi business… limited access and fare control did.
Apple did not kill the music industry… being forced to buy full length albums did.
Airbnb isn’t killing the hotel industry… limited availability and pricing options are.

The right technology for the right job

is an enabler of business disruption

5 IBM Cloud
 Multi-cloud is being driven by cloud native architectures
Microservices and containers are changing IT

The Compound CAGR *: -8%

Microservices and
Annual Growth Rate
containers are keys to
of traditional IT
this transformation
continues to shrink Traditional IT
while public and
private cloud
continues to grow

Public
with Virtual
Private
Cloud

Private Cloud Portable Applications

Public Cloud
Public Cloud

CAGR: 16% CAGR: 30%

6 IBM Cloud
 Microservices – the first key to cloud native applications
Making development & deployment more efficient

Microservice
Microservices benefits *
UI UI
• Improves fault isolation:
Data Larger applications can remain largely
Business
Logic
Access Microservice unaffected by the failure of a single
Layer
module
• Eliminates long-term commitment to
Microservice a single technology stack:
Try out a new technology stack on an
individual service and roll it back if
Microservice Microservice Microservice required
• Easier development:
DB
DB DB DB A new developer can more easily
understand the functionality of a service
Monolithic Microservices
Architecture Architecture • Easier deployment:
Auto provision, auto scale and provide
auto-redundancy
* This is not a claim that a microservice-based application approach is always better for every use case scenario
7 IBM Cloud
 Containers – the second key to cloud native applications
Reducing operational and development costs

Virtual machines vs. containers

App 1 App 2 App 3

Bins/Libs LibsBins/ Bins/Libs App 1 App 2 App 3

Bins/Libs Bins/Libs Bins/Libs

overhea
Guest Guest Guest
d OS OS OS
Container Engine
Hypervisor Operating System
Containers can be 2 – 3 times more resource
Infrastructure Infrastructure efficient than virtual machines

On average Docker developers ship software 7x

more frequently
BV

✓ Containers virtual software in the way that virtual machines have virtualized hardware

8 IBM Cloud
 Container automation and orchestration is essential
Enter: Kubernetes

Containers are revolutionizing IT Kubernetes - κυβερνήτης

But they require orchestration Means “helmsman” or “pilot”

9 IBM Cloud
 Private Clouds address the new IT reality
Created by digital transformation

Method Development Deployment Environment

Perception of cost
Waterfall Monolithic Bare metal On-Premises
Time to value

App 1 App 2 App 3

Bins/Libs Bins/Libs Bins/Libs

Guest Guest Guest

OS OS OS

Hypervisor

Infrastructure

Agile Programming N-Tier Virtual Server Off-Premises

App 1 App 2 App 3

Bins/Libs Bins/Libs Bins/Libs

Container Engine

Operating System

Infrastructure

Agile DevOps Microservices Containers Cloud

10 IBM Cloud
 Public Cloud + Private Cloud = Hybrid Cloud *
Different cloud options
On-Premises Hosted Private
Public Cloud Hybrid Cloud
Private Cloud Cloud
Hardware Shared between
Deployment and Vendor Customer Vendor vendor and
Management customer
Partially shared
Hardware Sharing
Shared Dedicated Dedicated and partially
Model
dedicated

Scalability High Medium High High

Low Cost Yes Sometimes Sometimes Sometimes

Predictable Cost No Yes Yes No

Utility Billing Yes No Depends on vendor Partial

Flexibility Yes Limited Limited Yes

Customization
No Yes Depends on vendor Partial
Capabilities
Enhanced Security
No Yes Yes Yes
and Compliance
Instant
Yes Yes Yes Yes
Provisioning

* A “Hybrid Cloud” is a highly orchestrated environment, where all sources act as one
A “Multi-cloud” environment simply refers to the use of multiple cloud sources of any kind, without necessarily being orchestrated

11 IBM Cloud
 Why care about Private Clouds?
Adoption brings agility and efficiency

Data Center
Cost Efficient & Scalable 50% Benefit
System Utilization & Server Reduction
Infrastructure
Manage Performance
Build, package & deploy applications in 75% Benefit
Elasticity, Bursting, High Availability
containers; run at scale with Kubernetes
DevOps
35% Benefit
Faster Deployments
Accelerate Time to Market
Deployment Efficiency
30% Benefit
Refactor applications into microservices Containers & Microservices
& modernize monolithic applications
Improved Security
50% Benefit
Management & Risk Reduction
Manage Data at Scale
3-Year $5.4 Million Cost Savings; 255% ROI
Access, govern, & analyze your data at Business Value Assessment Customer Output:
scale; accelerate your journey to AI Standard On-Premises vs IBM Cloud Private

12 IBM Cloud
 Private Cloud Platform Market Leaders
OpenShift and IBM Cloud Private

IBM Cloud Private

13 IBM Cloud
 Kubernetes Basics

14 IBM Cloud
 Kubernetes Basics
▪ Kubernetes Overview ▪ Kubernetes Storage
− Open Source Project − Volume types
− Features − Persistent volumes
− Architecture − Persistent volume claims
▪ Kubernetes Workloads ▪ Kubernetes Security
− Pods and YAML − Secrets
− Controllers ▪ IBM Cloud Private Catalog
▪ Kubernetes Networking − Helm Charts
− Services − Helm CLI

15 IBM Cloud
 Kubernetes – Open Source Project
▪ Greek work for “Helmsman”
▪ It’s Open Source - https://github.com/kubernetes/kubernetes
▪ It’s a graduated project of Cloud Native Computing Foundation https://cncf.io
▪ Popularly known as “Container Orchestrator”
▪ It is a modern “Cluster Manager” for automating deployment, scaling and management
of containerized applications.

16 IBM Cloud
 Kubernetes – Features (1)
▪ Automatic binpacking
− Automatically places containers on nodes. Mix critical and best-effort workloads in order to
drive up utilization.
▪ Horizontal scaling
− Scale application up or down with a simple command, with a UI or automatically based on CPU
usage
▪ Automated rollouts and rollbacks
− Kubernetes progressively rolls out changes to the application or its configuration, while
monitoring application health to ensure that it doesn’t kill all instances at the same time.
▪ Storage orchestration
− Automatically mount the storage system of your choice whether from local, public or SAN such
as iSCSI, Gluster, Ceph, Cinder, Flocker, NFS or IBM Spectrum Scale.

17 IBM Cloud
 Kubernetes – Features (2)
▪ Self-healing
− Restart containers that fail, replace and reschedules containers when nodes die, kill
containers that do not respond to user defined health checks
▪ Service discovery and load balancing
− No need to modify the application to use an unfamiliar service discovery mechanism.
Kubernetes gives containers their own IP addresses and a single DNS name for a set of
containers
▪ Secret and configuration management
− Deploy and update secrets and application configuration without rebuilding your image and
without exposing secrets in your stack configuration
▪ Batch Execution
− In addition to services, Kubernetes can manage your batch and CI workloads, replacing
containers that fail, if desired.

18 IBM Cloud
 Kubernetes Architecture
Command
Web UI
Line

Kubernetes REST API

Kubernetes Cluster
Image Registry
Container - Master Node
1
Container - Distributed etcd
2
Container - Scheduler Controller key-value datastore
3
Container -
4
Container -
5
Container -
API Server
6
Container -
7 Kubelet Kubelet Kubelet
Container -
8
Container - Worker Node Worker Node Worker Node
n

19 IBM Cloud
 Kubernetes Workloads
Pod – the basic building block for Kubernetes
▪ Smallest and simplest unit in Kubernetes object model
▪ Pod encapsulates an application container (or multiple containers), storage resources, a
unique network IP, and options that govern how the container should run
▪ Pod is a unit of deployment
▪ Pod runs one or more containers as a unit
▪ Docker is the container runtime used in IBM Cloud Private
▪ One-container-per-pod model is most common use case
▪ Kubernetes manages the pod rather than containers directly
▪ Pods can run multiple containers that need to work together and to
share resources
▪ Pods are designed as relatively ephemeral, disposable entities
▪ Pods do not self-heal by themselves – a higher level abstraction
does this
20 IBM Cloud
 Kubernetes Configurations
Create YAML for creating resources on Kubernetes
▪ YAML – Yet Another Markup Language or YAML Ain’t Markup Language
▪ Types of structures required in Kubernetes
− Maps
− Lists
▪ YAML Maps - let you associate name value pair. For example:
---
apiVersion: v1
kind: pod
▪ YAML Maps – Create a key that maps to another map
---
apiVersion: v1
kind: pod
metadata:
name: db2
labels:
21
app: db2
IBM Cloud
 Kubernetes Configurations – Create YAML (continued)
▪ YAML Lists are literally a sequence of objects. Members in the list can also be maps.
---
apiVersion: v1
A YAML manifest has four components
kind: pod
metadata:
to define a Kubernetes resource:
name: db2 • apiVersion
labels: • kind
app: db2 • metadata
spec: • spec
containers:
- name: front-end
image: nginx
ports:
- containerPort: 80
- name: db2-oltp
image: store/ibmcorp/db2_developer_c:11.1.4.4
ports:
- containerPort: 50000
22 IBM Cloud
 Kubernetes Workloads – Create a Pod
▪ Create a nginx pod – icp01.yaml
---
# Simple yaml file to create an nginx pod
apiVersion: v1
kind: Pod ▪ Create the pod
metadata:
name: nginx $ kubectl apply -f icp01.yaml
labels: pod/nginx created
app: nginx
spec:
▪ Check pod status
containers:
- name: nginx $ kubectl get pods
image: nginx:1.7.9 NAME READY STATUS RESTARTS AGE
ports: nginx 1/1 Running 0 13s
- containerPort: 80

23 IBM Cloud
 Kubernetes Workloads - Controllers
Controllers can create and manage pods for you.
▪ ReplicaSet ▪ DaemonSets
− A ReplicaSet ensures that a specified number − A DaemonSet ensures that nodes (all or some)
of pod replicas are running at any given time. run a copy of pod. As nodes are added, pods
are added to them.
▪ Deployments
− Example: Cluster storage daemon such as
− Deployment is a higher-level concept that
glusterd, ceph, logs collection on each node
manages ReplicaSets and provides
declarative updates to pods. ▪ Jobs, CronJobs
− Example: Create a deployment to rollout a − A job creates one or more pods and ensures
ReplicaSet that a specified number of them successfully
terminate
▪ StatefulSets
− StatefulSets represent a set of pods with
unique, persistent identities and stable
hostnames that are maintained regardless
where they are scheduled
− Examples: Db2, Redis, IBM MQ
24 IBM Cloud
 Kubernetes Network - Services
▪ Without services, Pods are not visible outside the cluster
▪ To enable communication from outside world to the Pods, services are created.
▪ Internal Service Endpoints – Available inside the cluster only
▪ External Service Endpoints - DNS names, C-Names or A-records available to access
pods.
▪ With the help of labels and selectors, the services are tied to the pods
▪ Service Types
− ClusterIP – Service is reachable only from inside of the cluster
− NodePort – Service is reachable through NodeIP:NodePort
− LoadBalancer – Service is reachable through an external load balancer mapped to
NodeIP:NodePort address

25 IBM Cloud
 Kubernetes Storage – Volume types
▪ Host-based ▪ Distributed File System
− EmptyDir − IBM Spectrum Scale
− HostPath − NFS
▪ Block Storage − Ceph
− IBM Block Storage − GlusterFS
− Amazon EBS − Amazon EFS
− GCE Persistent Disk − Azure File System
− vSphere Volumes ▪ Other
− Flocker
− iSCSI
− Git Repository
− Quobyte

26 IBM Cloud
 Kubernetes Storage – Persistence in Pods
▪ Pods are ephemeral and stateless.
▪ Applications need persistent storage.
▪ Volumes is a way to get persistence to a Pod.
▪ Kubernetes volumes are similar to Docker volumes, but are managed differently.
▪ All containers in a Pod can access the volume.
▪ Volumes are associated with the lifecycle of a Pod.
▪ Directories in a host are exposed as volumes in Pod.
▪ Volumes may be based on a variety of back-end storage types.

27 IBM Cloud
 Kubernetes Storage
Persistent volume and persistent volume claim
▪The Kubernetes Volume abstraction provides:
− Persistent Volume (PV) – Provisioned by an administrator
− Persistent Volume Claim (PVC) – Requested by an user and Heketi provisions
PVC – which creates a PV
− Storage Class (SC) – Storage profiles offered by admins
Block Storage / Distributed File System / IBM
Spectrum Scale
Pod 1 Pod 1

Persistent Persistent
Volume Volume
Claim
Worker Node

28 IBM Cloud
 Kubernetes Secrets
Decouple container with sensitive information
▪ Secret holds sensitive information such as password, OAuth tokens and more.
▪ Secret is an abstraction to decouple sensitive data.
▪ To use a secret, Pod needs to reference the secret.
▪ Secret can be used in a Pod as files in a volume mounted on one or more
containers or used by kubelet when pulling images for the Pod.
$ kubectl -n stocktrader \
create secret generic db2 \
--from-literal=id=db2psc \
--from-literal=pwd=password \
--from-literal=host=dev-ibm-db2oltp-dev.default.svc.cluster.local \
--from-literal=port=50000 \
--from-literal=db=PSDB
29 IBM Cloud
 IBM Cloud Private catalog – Helm Charts

Db2 chart

DSM chart

30 IBM Cloud
 IBM Cloud Private catalog – What is a Helm Chart?
▪ Helm is the package manager in IBM Cloud Private.
▪ Tiller is the server that serves the Helm content.
▪ Helm charts help to define, install and upgrade software in an automated
fashion.
▪ Helm charts can be deployed using GUI or command line.
▪ Software packages are available from IBM Charts Repository.
▪ Available at : https://github.com/IBM/charts
▪ IBM Cloud Private catalog requires internet connectivity to show available
charts.
▪ In an air-gap environment, you can build your own Local Charts repository.

31 IBM Cloud
 IBM Charts Repository
https://github.com/IBM/charts/tree/master/stable

Db2 chart

DSM chart

32 IBM Cloud
 Helm command line – Helm and Tiller
▪ Helm is the client and Tiller is the server – runs on master node
$ helm version
Client: v2.7.2+icp
Error: cannot connect to Tiller
▪ Use of --tls is required to do Helm operations
$ helm version --tls
Client: v2.7.2+icp
Server: v2.7.2+icp
▪ Helm and Tiller version must be same – do not download Helm from Internet

33 IBM Cloud
 Deploying Db2 on
Kubernetes

34 IBM Cloud
 Db2-based Containers running on Kubernetes (Sep 2019)
Product Version #Worker #Pods #PVCs Comments
Nodes
Db2 OLTP 11.1.4.4 1 1 1

Db2 OLTP HADR 11.1.4.4 3 5 6 1x Db2 primary, 1x Db2 standby, 3x etcd for cluster
manager, addntl. PVC for HADR setup
Data Server 2.1.5 1 2 2 1x DSM, 1x Db2 repository database
Manager Includes Db2 11.1 engine
Db2 Warehouse 3.10.0 1 1 1 Includes Db2 11.1. engine
SMP
Db2 Warehouse 3.10.0 3+ 3+ 1 Includes Db2 11.1 engine
MPP Requires IBM Cloud Pak for Data

▪ Coming soon
− Red Hat OpenShift Kubernetes support
− Db2 v11.5 engine

35 IBM Cloud
 IBM Cloud Private Kubernetes platform

36 IBM Cloud
 Before deploying Db2 OLTP to Kubernetes a couple of steps
need to be performed
▪ Creating a new namespace (optional)
▪ Configuring a pod security policy
▪ Configuring an image pull secret
▪ Configuring the service account

37 IBM Cloud
 Creating the Namespace for the Db2 OLTP containers
▪ We will create new namespace where all our Pods for Db2 OLTP, Db2 OLTP
HADR and Data Server Manager will run.
▪ Create the namespace, for example stock-trader-data
$ kubectl create namespace stock-trader-data
namespace/stock-trader-data created
▪ Switch the context to the newly created namespace
$ kubectl config set-context $(kubectl config current-context) \
--namespace=stock-trader-data
Context "mycluster-context" modified.
▪ Verify pods. There should be no pods running as we just created the namespace.
$ kubectl get pods
No resources found.

38 IBM Cloud
 Configuring Pod Security Policy for Db2
$ cat pre01.yaml hostNetwork: false
apiVersion: extensions/v1beta1 hostPID: false
kind: PodSecurityPolicy hostPorts:
metadata: - max: 65535
name: db2-privileges min: 1
spec: runAsUser:
allowPrivilegeEscalation: true rule: RunAsAny
privileged: false seLinux:
allowedCapabilities: rule: RunAsAny
- SETPCAP supplementalGroups:
- MKNOD rule: RunAsAny
- AUDIT_WRITE volumes:
- CHOWN - '*'
- NET_RAW
- DAC_OVERRIDE
- FOWNER ▪ Configure the pod security policy:
- FSETID $ kubectl apply -f pre01.yaml
- KILL podsecuritypolicy.extensions/db2-privileges configured
- SETGID
- SETUID
- NET_BIND_SERVICE
▪ Verify the results
- SYS_CHROOT $ kubectl get psp
- SETFCAP db2-privileges false
- SYS_RESOURCE SETPCAP,MKNOD,AUDIT_WRITE,CHOWN,NET_RAW,DAC_OVERRIDE,FOWNER,FSETID,KILL
- IPC_OWNER ,SETGID,SETUID,NET_BIND_SERVICE,SYS_CHROOT,SETFCAP,SYS_RESOURCE,IPC_OWN
- SYS_NICE ER,SYS_NICE RunAsAny RunAsAny RunAsAny RunAsAny
fsGroup: false *
rule: RunAsAny
hostIPC: true

39 IBM Cloud
 Configuring Image Pull Secret for Db2
▪ We need to create a image pull secret to give Kubernetes the credentials to pull the Db2
Developer-C and DSM images from Docker Hub
▪ The username, password and email are the credentials form Docker Hub.
▪ Note, that you need to subscribe the Db2 and DSM images in Docker Hub first.
▪ Configure the image pull secret:
$ kubectl create secret docker-registry dockerhub
--docker-username=<your dockerhub username>
--docker-password=<your dockerhub password>
--docker-email=<your dockerhub email>
--namespace=<your namespace>
secret/dockerhub created
▪ Verify the result:
$ kubectl get secrets
NAME TYPE DATA AGE
default-token-mwvpl kubernetes.io/service-account-token 3 17d
dockerhub kubernetes.io/dockerconfigjson 1 13m

40 IBM Cloud
 Configuring Service Account for Db2
$ more pre04.yaml ▪ The YAML specification file that defines the cluster
--- role and the cluster role binding for the service
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
account.
metadata:
name: db2-privileges-cluster-role
rules: ▪ Configure the service account:
- apiGroups: ['extensions'] $ kubectl apply -f pre04.yaml
resources: ['podsecuritypolicies'] clusterrole.rbac.authorization.k8s.io/db2-
verbs: ['use']
privileges-cluster-role created
resourceNames:
- db2-privileges clusterrolebinding.rbac.authorization.k8s.io/db2-
--- privileges-cluster-role-binding created
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata: ▪ Verify the results
name: db2-privileges-cluster-role-binding $ kubectl get psp
roleRef: db2-privileges false
kind: ClusterRole SETPCAP,MKNOD,AUDIT_WRITE,CHOWN,NET_RAW,DAC_OVERRIDE,FOWNER,FSETID,
name: db2-privileges-cluster-role KILL,SETGID,SETUID,NET_BIND_SERVICE,SYS_CHROOT,SETFCAP,SYS_RESOURCE
apiGroup: rbac.authorization.k8s.io ,IPC_OWNER,SYS_NICE RunAsAny RunAsAny RunAsAny
subjects: RunAsAny false *
- kind: ServiceAccount
name: default
namespace: stock-trader-data

41 IBM Cloud
 Helm Charts for Db2 and DSM

42 IBM Cloud
 Helm install command to deploy Db2 OLTP on Kubernetes
Db2 OLTP
▪ Installing Db2 OLTP server with one database in 2 minutes. Helm chart
name

$ helm install --name db2-01 ibm-charts/ibm-db2oltp-dev

--tls Instance
--set db2inst.instname=db2inst1 owner name
Helm release
name, --set db2inst.password=passw0rd Instance owner
different for each password
deployment --set options.databaseName=MYDB
--set dataVolume.size=20Gi
Name of database that
will be created.
Size of the If not specified no
Db2 data database will be
volume created.
▪ Additional parameters available, for example to enable Oracle compatibility.
See: https://github.com/IBM/charts/tree/master/stable/ibm-db2oltp-dev

43 IBM Cloud
 Let’s verify if we can connect to the MYDB database (1)
▪ Get list of running pods and verify that Db2 OLTP pod is running.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
db2-01-ibm-db2oltp-dev-0 1/1 Running 1 7h57m

▪ Review the logs of the Db2 OLTP container

$ kubectl logs -f db2-01-ibm-db2oltp-dev-0
09/15/2019 16:04:30 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
(*) Starting TEXT SEARCH service ...
CIE00001 Operation completed successfully.
ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA ED25519
(*) All databases are now active.
(*) Setup has completed.

44 IBM Cloud
 Let’s verify if we can connect to the MYDB database (2)
▪ Login to the Db2 OLTP container and connect to MYDB Db2 database.
$ kubectl exec -it db2-01-ibm-db2oltp-dev-0 --/bin/bash
# su - db2inst1
Last login: Sun Sep 15 16:17:11 UTC 2019
$ db2 connect to MYDB

Database Connection Information

Database server = DB2/LINUXX8664 11.1.4.4

SQL authorization ID = DB2INST1
Local database alias = MYDB

45 IBM Cloud
 Cataloging the MYDB database We get the Db2 port
from the Db2 OLTP
▪ We need to catalog the MYDB database to access from Db2 client helm release service
#!/bin/bash definition.

NODE_PORT=$(kubectl get --namespace stock-trader-data \

-o jsonpath="{.spec.ports[0].nodePort}" services db2-01-ibm-db2oltp-dev-db2)

echo "Cataloging node db2tcp1"

db2 -v uncatalog node DB2TCP1
db2 -v catalog tcpip node DB2TCP1 remote 192.168.27.100 server ${NODE_PORT}

echo "Cataloging database MYDB at node db2tcp1"

db2 -v uncatalog database MYDB
db2 -v catalog database MYDB at node DB2TCP1

db2 terminate
46 IBM Cloud
 Kubernetes resources for Db2 OLTP
$ helm status db2-01 --tls
NAME: db2-01
LAST DEPLOYED: Sun Sep 15 08:11:14 2019 1 Secret:
NAMESPACE: stock-trader-data Db2 instance
STATUS: DEPLOYED owner / password
RESOURCES: 1 PVC (RWO) for db
==> v1/Secret
NAME TYPE DATA AGE
files, logs & config
db2-01-ibm-db2oltp-dev Opaque 1 1s
==> v1/PersistentVolumeClaim 2 Services for
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
Db2: 1x external,
db2-01-data-stor Bound vol12 20Gi RWO 1s
1x internal
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db2-01-ibm-db2oltp-dev-db2 NodePort 10.0.0.50 <none> 50000:30463/TCP,55000:32236/TCP 1s
db2-01-ibm-db2oltp-dev ClusterIP None <none> 50000/TCP,55000/TCP,60006/TCP,60007/TCP 1s
==> v1/StatefulSet
NAME DESIRED CURRENT AGE
1 StatefulSet
db2-01-ibm-db2oltp-dev 1 1 1s
==> v1/Pod(related) DESIRED = 1
NAME READY STATUS RESTARTS AGE
db2-01-ibm-db2oltp-dev-0 0/1 Init:0/1 0 1s 1 Pod: runs
the Db2
container
47 IBM Cloud
 Helm install command for deploying Db2 OLTP HADR
▪ Setting up a Db2 OLTP v11.1 HADR cluster pair in 5 minutes with 1 command

helm install --name db2-02 ibm-charts/ibm-db2oltp-dev

--tls
--set db2inst.instname=db2inst1
--set db2inst.password=passw0rd
--set options.databaseName=HADB
--set dataVolume.size=20Gi
--set hadr.enabled=true

Additional parameter
hadr.enabled set to true to
indicate that we want a
HADR setup

48 IBM Cloud
 Verify that Db2 HADR is working

49 IBM Cloud
 Kubernetes resources for Db2 OTLP HADR
NAME: db2-02
LAST DEPLOYED: Tue Sep 17 08:24:33 2019 1 Secret: (1) 5 addntl. PVCs are being created
NAMESPACE: stock-trader-data
STATUS: DEPLOYED Db2 instance implicitly for: 2x Db2 and 3x etcd
RESOURCES: owner / password
==> v1/Secret
NAME TYPE DATA AGE 1 PVC (RWX):
db2-02-ibm-db2oltp-dev Opaque 1 1s for HADR setup (1)
==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE 3 Services:
db2-02-hadr-stor Bound vol09 20Gi RWX 1s 2x Db2, 1x etcd
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db2-02-ibm-db2oltp-dev-db2 NodePort 10.0.0.61 <none> 50000:32422/TCP,55000:32181/TCP 1s
db2-02-ibm-db2oltp-dev ClusterIP None <none> 50000/TCP,55000/TCP,60006/TCP,60007/TCP 1s
db2-02-ibm-db2oltp-dev-etcd ClusterIP None <none> 2380/TCP,2379/TCP 1s
==> v1/StatefulSet
NAME DESIRED CURRENT AGE
db2-02-ibm-db2oltp-dev 2 2 1s
2 StatefulSets:
==> v1beta2/StatefulSet Db2: DESIRED=2
db2-02-ibm-db2oltp-dev-etcd 3 0 1s etcd: DESIRED=3
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
db2-02-ibm-db2oltp-dev-0 0/1 Pending 0 1s 5 Pods:
db2-02-ibm-db2oltp-dev-1 0/1 Pending 0 1s
db2-02-ibm-db2oltp-dev-etcd-0 0/1 ContainerCreating 0 1s 2x Db2, 3x etcd
db2-02-ibm-db2oltp-dev-etcd-1 0/1 Pending 0 1s
db2-02-ibm-db2oltp-dev-etcd-2 0/1 Pending 0 1s

50 IBM Cloud
 Kubernetes Job to deploy SQL
$ cat single04.yaml restartPolicy: Never
apiVersion: batch/v1 volumes:
kind: Job - name: db2-createschema
metadata: configMap:
name: db2-01-create-database-schema name: db2-createschema
spec: defaultMode: 0744
template: backoffLimit: 1
spec: ---
containers: apiVersion: v1
- name: db2-01-create-database-schema data:
image: store/ibmcorp/db2_developer_c:11.1.4.4-x86_64 db2-setup.sh: |
command: [ "/bin/sh","-c","/scripts/db2-setup.sh" ] #!/bin/sh
volumeMounts: export SETUPDIR=/var/db2_setup
- name: db2-createschema source ${SETUPDIR?}/include/db2_constants
mountPath: /scripts source ${SETUPDIR?}/include/db2_common_functions
securityContext: if ! getent passwd ${DB2INSTANCE?} > /dev/null 2>&1; then
capabilities: echo "(*) Previous setup has not been detected. Creating... "
add: ["SYS_RESOURCE", "IPC_OWNER", "SYS_NICE"] create_users
env: fi
- name: LICENSE if ! create_instance; then
value: "accept" exit 1
- name: DB2INSTANCE fi
value: db2inst1 start_db2
- name: DB2INST1_PASSWORD cp /scripts/db2-createschema.sh /database/db2-createschema.sh
valueFrom: chmod +x /database/db2-createschema.sh
secretKeyRef: su - $DB2INSTANCE -c "/database/db2-createschema.sh
name: db2-01-ibm-db2oltp-dev \"$DB2_SERVICE_NAME\" \"$DB2INSTANCE\“
key: password \"$DB2INST1_PASSWORD\" \"$DBNAME\""
- name: DB2_SERVICE_NAME
value: db2-01-ibm-db2oltp-dev
- name: DBNAME
51 value: mydb
IBM Cloud
 Kubernetes Job to deploy SQL (cont’d)
db2-createschema.sh: |
#!/bin/sh
DB2_SERVICE_NAME=$1
DB2INSTANCE=$2
DB2INST1_PASSWORD=$3
DBNAME=$4
echo "Configure schema for database \"$DBNAME\" on host \"$DB2_SERVICE_NAME\"."
db2 "catalog tcpip node DB2NODE remote $DB2_SERVICE_NAME server 50000"
db2 "catalog db $DBNAME as $DBNAME at node DB2NODE"
db2 terminate
db2 "activate database $DBNAME user $DB2INSTANCE using $DB2INST1_PASSWORD"
db2 "connect to $DBNAME user $DB2INSTANCE using $DB2INST1_PASSWORD"
sleep 2
db2 -tvmf /scripts/ps-bp-tbsp.sql
sleep 10
db2 -tvmf /scripts/ps-tables.sql
echo "Database $DBNAME has been configured."
ps-bp-tbsp.sql: |
CREATE BUFFERPOOL BP32K PAGESIZE 32K;
CREATE TABLESPACE TS32 PAGESIZE 32K BUFFERPOOL BP32K;
ps-tables.sql: |
CREATE TABLE PS_TABLE(PS_TABLE_ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 100000, INCREMENT BY 5), […] IN TS32;
INSERT INTO PS_TABLE (SSN,FIRST_NAME,LAST_NAME,JOB_CODE,DEPT,SALARY,DOB) WITH TEMP1 […] ;
CREATE TABLE PS_HISTORY ( FIRSTNAME VARCHAR(20) NOT NULL, LASTNAME VARCHAR(20) NOT NULL, JOBCODE CHAR(4) NOT NULL ) IN TS32 ;
GRANT ALL ON ps_table TO PUBLIC;
GRANT ALL ON ps_history TO PUBLIC;
kind: ConfigMap
metadata:
name: db2-createschema

52 IBM Cloud
 Deploying the Job to run the SQL
▪ We deploy the Kubernetes job that runs the SQL on the MYDB database
$ kubectl apply –f single04.yaml
job.batch/db2-01-create-database-schema created
configmap/db2-createschema configured

▪ We verify that the job has been created

$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
db2-01-create-database-schema 0/1 0s 0s

▪ Eventually, the job completes

$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
db2-01-create-database-schema 1/1 109s 45m
53 IBM Cloud
 Verifying the logs from the Job that runs the SQL on MYDB
▪ We run a script to retrieve the logs form the job
#!/bin/bash
kubectl config set-context $(kubectl config current-context) --
namespace=stock-trader-data
pod=$(kubectl get pods --selector=job-name=db2-01-create-database-schema --
output=jsonpath='{.items[*].metadata.name}')
kubectl logs -f $pod
▪ Output:
[…]
DB20000I The SQL command completed successfully.
GRANT ALL ON ps_table TO PUBLIC
DB20000I The SQL command completed successfully.
GRANT ALL ON ps_history TO PUBLIC
DB20000I The SQL command completed successfully.
Database mydb has been configured.
54 IBM Cloud
 Deploying Data Server Manager (DSM) with the GUI

55 IBM Cloud
 Deploying Data Server Manager (DSM) with the GUI (2)

56 IBM Cloud
 Getting the URL of Data Server Manager
▪ We need to query Kubernetes for the URL of the DSM GUI
#!/bin/bash
export NODE_PORT=$(kubectl get --namespace stock-trader-data -o
jsonpath="{.spec
.ports[1].nodePort}" services dsm-01-ibm-dsm-dev)
export NODE_IP=$(kubectl get nodes --namespace stock-trader-data -o
jsonpath="{.
items[0].status.addresses[0].address}")
echo https://$NODE_IP:$NODE_PORT

=> https://192.168.27.100:30462 (can be different on your system)

57 IBM Cloud
 Accessing Data Server Manager

58 IBM Cloud
 All Db2 OLTP instances running in the
Data Server Manager Homepage same namespace as DSM will be auto-
discovered and monitored by DSM

59 IBM Cloud
 DSM Kubernetes resources (1/2)
$ helm status dsm-01 --tls
LAST DEPLOYED: Mon Sep 16 12:01:02 2019
NAMESPACE: stock-trader-data
STATUS: DEPLOYED
2 RoleBindings
RESOURCES:
==> v1/RoleBinding
NAME AGE
dsm-repodb-dsm-01-repository 8m 2 Services:
dsm-stock-trader-data-dsm-01-ibm-dsm-dev 8m
dsm-dsm-01-ibm-dsm-dev 8m
1x Db2 (repodb),
1x DSM
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
dsm-01-repository NodePort 10.0.0.233 <none> 50000:32695/TCP,55000:32203/TCP 8m
dsm-01-ibm-dsm-dev NodePort 10.0.0.85 <none> 11080:32444/TCP,11081:30462/TCP 8m

==> v1beta1/Deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
dsm-01-repository 1 1 1 1 8m 2 Deployments
dsm-01-ibm-dsm-dev 1 1 1 1 8m

==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE 2 Pods:
dsm-01-repository-76f87d47d4-dlqh4 1/1 Running 0 8m 1 Db2, 1 DSM
dsm-01-ibm-dsm-dev-b976d89bd-dflqn 2/2 Running 0 8m
60 IBM Cloud
 DSM Kubernetes resources (2/2)
[…]
==> v1/Secret 2 Secrets: 1 DSM
NAME TYPE DATA AGE asmin, 1 Db2
dsm-01-repository-db2-passwd Opaque 1 8m
instance owner
dsm-01-ibm-dsm-dev-dsm-passwd Opaque 1 8m

==> v1/PersistentVolumeClaim
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
dsm-01-repository-data-stor Bound vol14 20Gi RWO 8m
dsm-01-ibm-dsm-dev-datavolume Bound vol12 20Gi RWO 8m

==> v1/ServiceAccount
NAME SECRETS AGE
dsm-repodb-dsm-01-repository 1 8m 2 PVCs: 1 DSM,
dsm-dsm-01-ibm-dsm-dev 1 8m Db2
==> v1/Role
NAME AGE
dsm-repodb-dsm-01-repository 8m 3 Roles
dsm-stock-trader-data-dsm-01-ibm-dsm-dev 8m
dsm-dsm-01-ibm-dsm-dev 8m

61 IBM Cloud
 Additional Resources

62 IBM Cloud
 Additional Resources – Kubernetes, Docker, Helm
▪ Kubernetes
− https://kubernetes.io/docs/tutorials/kubernetes-basics/
▪ Kubernetes in the Enterprise eBook
− ibm.biz/BdYA4i
▪ Docker
− https://docs.docker.com/get-started/
▪ Docker Hub
− https://hub.docker.com
▪ Helm
− https://helm.sh/docs/

63 IBM Cloud
 Additional Resources – IBM Cloud Private, OpenShift
▪ IBM Cloud Private Documentation
− https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.2.0/kc_welcome_containers.
html
▪ Deploy IBM Cloud Private Community Edition using Vagrant
− https://github.com/IBM/deploy-ibm-cloud-private/blob/master/docs/deploy-vagrant.md
▪ Red Hat OpenShift Container Platform Documentation
− https://docs.openshift.com/container-platform/4.1/welcome/index.html

64 IBM Cloud
 Additional Resources – Db2, Db2Wh, DSM
▪ Db2 Integration into IBM Cloud Private
− https://developer.ibm.com/recipes/tutorials/db2-integration-into-ibm-cloud-private
▪ Db2 on IBM Cloud Private with Red Hat OpenShift
− https://developer.ibm.com/recipes/tutorials/ibm-db2-on-ibm-cloud-private-with-redhat-
openshift
▪ IBM Db2 Developer-C Edition Helm Chart
− https://github.com/IBM/charts/tree/master/stable/ibm-db2oltp-dev
▪ IBM Data Server Manager Developer-C Edition Helm Chart
− https://github.com/IBM/charts/tree/master/stable/ibm-dsm-dev
▪ Deploying Db2 Warehouse SMP using Kubernetes
− https://www.ibm.com/support/knowledgecenter/en/SSCJDQ/com.ibm.swg.im.dashdb.doc/admin/deploy_ku
bernetes_smp.html
▪ Deploying Db2 Warehouse SMP and MPP on IBM Cloud Pak for Data
− https://www.ibm.com/support/knowledgecenter/en/SSQNUZ_2.1.0/com.ibm.icpdata.doc/zen/admin/db-
reqs.html#db-reqs__db2warehouse
65 IBM Cloud
 Presentation on Db2 and Docker from Db2 Aktuell 2018

66 IBM Cloud
 Summary

67 IBM Cloud
 Summary

▪ Micro Services and Containers

▪ Kubernetes Basics
▪ Deploying Db2 on Kubernetes
− Db2 OLTP Single Server
− Db2 OLTP HADR
− Data Server Manager (DSM)
▪ Additional Resources
▪ Summary

68 IBM Cloud
 Thank You

Claus Huempel IBM Deutschland GmbH

Karl-Arnold-Platz 1a

Technical Sales Professional 40474 Duesseldorf

Hybrid Data Management Germany
Mobile. +49-177-3627278
Email: [email protected]

69 IBM Cloud
70 IBM Cloud