コンテナ版Db2
Db2 V11.5 にはコンテナ版が提供されていて、無償(※)で利用することができます。
(※) Db2 Community Edition：4 cores,16 GB RAM までのサーバであれば無償
コンテナ版のDb2には、以下の種類があります。
-
Dockerコンテナ版Db2
-
Db2 on OpenShift (別名 "Db2 Universal Container (Db2U)")
<--- OpenShift Container Platform(以下、OCP) にデプロイするためのコンテナ版Db22-1. Db2 OLTP
2-2. Db2 Warehouse
Db2 11.5.4 OpenShift (上の2-1.) を OCP 4.x 環境に導入します。
OpenShiftにDb2を導入するための前提
Db2 on OpenShift 11.5.4 (OLTP) 導入にあたり、以下の要件があります。
- Kubernetes Level - ">=1.11.0"
- Helm Level:
- Power: ">=2.12(*) and < 3.0"
- X86: ">=2.14(*) and < 3.0"
- (*) Tested Integrations
- OpenShift Version - "3.11, 4.3"
- PersistentVolume requirements - requires one of the following:
- NFS
- IBM Cloud File Storage (gold storage class)
- Portworx
- Red Hat OpenShift Container Storage 4.3 and above
- or a hostPath PV that is a mounted clustered filesystem
- An IBM Cloud account
マシンリソースの要件は下記の通りです。
- 1 worker node
- Cores: 5.7 (2 for the Db2 engine and 3.7 for Db2 auxiliary services)
- Memory: 10.4 GiB (4 GiB for the Db2 engine and 6.4 GiB for Db2 auxiliary services)
最新の情報は、Db2 Community Edition 11.5.4.0 GitHub Readme を確認してください。
ここでは、OCPは導入済みである前提で進めます。
Helm V2 は、他用途では使われておらずDb2 on OpenShift 導入のために別途導入されるケースもあるかと思いますので、今回行ったセットアップ手順をこちらにまとめます。
---> Db2 11.5.4 on Openshift デプロイのための前提作業(Helm V2セットアップ)
導入環境
今回は、以下のような環境に Db2 11.5.4 on OpenShift をデプロイしました。
| 項目 | バージョン |
|---|---|
| OS(bastion) | RHEL 7.7 |
| OS(master/worker) | RHEL 7.7 |
| OCP(Client) ※ | 4.4.0-202006132207-d038424 |
| OCP(Server) ※ | 4.4.9 |
| Kubernetes | v1.17.1+912792b |
| Helm | 2.16.9 |
| Spectrum Scale | 5.0.5 |
| Db2 OLTP | 11.5.4 |
※ GitHub Readme では前提要件としてのOCPバージョンは4.3と記載されますが、
利用可能な環境がOCP4.4しか無かったため、OCP 4.4にデプロイしています。
※ Db2 11.5 Knowldge Centerには、OCP 4.x がサポート対象と記載されます。
構成
今回は、以下のような構成のOCP環境にDb2をデプロイします。
- Bastion Node x1
- Master Node x3
- Worker Node x3
上の図に示すように、Spectrum Scale(旧称GPFS) クラスタファイルシステム上に作成されたディレクトリを hostPath として利用する構成です。
hostPath ボリュームは、ファイルまたはディレクトリーをホストノードのファイルシステムから Pod にマウントするものです。Spectrum Scale のファイルシステムをDb2 Pod からマウントするために、hostPath PV を構成します。
ここでは、Spectrum Scaleファイルシステム上にDb2用ディレクトリが作成済である前提で、Db2デプロイを行っていきます。
参考：マシンリソース
| 用途 | vCPU | memory | storage |
|---|---|---|---|
| bastion | 4 | 8GB | |
| master | 3 | 16GB | |
| worker | 3 | 64GB | |
| Spectrum Scale (node) | 4 | 64GB | 1TB |
作業を行うノード・ユーザについて
この環境では、ocコマンド/kubectlコマンドはKUBECONFIG環境変数を設定したBastionノードのrootユーザでのみ実行可能となるよう構成されているため、ここから先で実行するコマンド操作は、基本的にすべてBastionノード、rootユーザで実行しています。
実行サーバ・実行ユーザについてはご使用の環境に応じて決めてください。
インストール方法の公式ドキュメント
オンプレミス版のDb2であれば、Db2マニュアル(KnowledgeCenter)にインストール方法が記載されますが、Db2 on OpenShift導入手順は主にGitHub上のReadMeに記載されています。
Db2 Community Edition 11.5.4.0 GitHub Readme
https://github.com/IBM/charts/tree/master/stable/ibm-db2
ストレージ関連のオプションなど、詳細・補助的な情報は一部、Db2マニュアルにも記載されます。
Db2 11.5 KnowledgeCenter [Red Hat OpenShift 上の Db2]
https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/c_db2u_overview.html
ここから記述する導入方法(ログ)は、上の2つの情報源の内容をマージしたものです。
導入の流れ
Db2 11.5.4 on OpenShift (OLTP) は、StatefulSet としてデプロイされます。
以下の手順で導入をすすめます。
- Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
- hostPath用ディレクトリの確認
- SELinuxが有効な環境で hostPathストレージを利用するための前提
- クラスタの構成
- IBM Container Registry へのアクセス
- Persistent Volume 作成
- Persistent Volume Claim 作成
- Helm option の指定
- PATH設定
- Db2 on OpenShift のインストール
- インストール完了確認
ここから先は、特に断りが無い限り
各種コマンドは ocコマンド(kubectl)コマンドが実行可能なユーザで実行します。
Step1. Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
① ダウンロード
Db2用のインストーラを単体で入手することはできない。(2020/07時点)
IBMが提供する各種製品群のchartを一括ダウンロードし、そのうちDb2インストーラに該当するchartのみを利用する。
下記URLにアクセスして、Chartをダウンロードする。
https://github.com/IBM/charts
※インストール・イメージ(バイナリ)は含まれないため、全体でも100MB弱程度におさまる
ダウンロードしたZIPファイルをOCP環境に転送しておく。
今回の環境では導入作業をbastionサーバで行うため、bastionサーバへ転送する。
② 展開
任意のディレクトリで、ZIPファイルを展開する。
unzip charts-master.zip
③ メディア展開用のibm-db2 ディレクトリをコピー
charts-master 配下の先頭のディレクトリ階層は以下のようになっていて、
Db2インストーラは stable/ibm-db2 ディレクトリ配下に展開されている。
cd /media/charts-master
ls -la
total 44
drwxr-xr-x. 12 root root 247 Jul 1 09:48 .
drwxr-xr-x. 3 root root 27 Jul 2 10:00 ..
drwxr-xr-x. 3 root root 34 Jul 1 09:48 .build
drwxr-xr-x. 27 root root 4096 Jul 1 09:48 community
drwxr-xr-x. 46 root root 4096 Jul 1 09:48 components
drwxr-xr-x. 2 root root 81 Jul 1 09:48 deprecated
drwxr-xr-x. 30 root root 4096 Jul 1 09:48 entitled
-rw-r--r--. 1 root root 48 Jul 1 09:48 .gitignore
-rw-r--r--. 1 root root 398 Jul 1 09:48 LICENSE
drwxr-xr-x. 2 root root 4096 Jul 1 09:48 logo
-rw-r--r--. 1 root root 348 Jul 1 09:48 ORIGIN
drwxr-xr-x. 7 root root 85 Jul 1 09:48 pak-extensions
-rw-r--r--. 1 root root 4417 Jul 1 09:48 README.md
drwxr-xr-x. 8 root root 102 Jul 1 09:48 repo
drwxr-xr-x. 3 root root 21 Jul 1 09:48 samples
drwxr-xr-x. 52 root root 4096 Jul 1 09:48 stable
-rw-r--r--. 1 root root 1109 Jul 1 09:48 .travis.yml
このうち、Db2インストーラだけを別ディレクトリに移動(またはコピー)しておく。
cp -pR /media/charts-master/stable/ibm-db2/* /work/media/ibm-db2/*
以後のStep4(クラスタ構成)、Step8(helm option指定)、Step9(Db2 インストール) では
移動先(＝上の例の「/work/media/ibm-db2」配下) のスクリプト・ファイルを利用する。
Tips：
- charts-master.zip から、stable/ibm-db2 ディレクトリのみを抽出・展開したディレクトリで db2u-install コマンドを実行する。
- 面倒なのでと、charts-master.zipを展開したディレクトリの下でそのままDb2インストーラを実行すると、
「This command needs 1 argument: chart name」メッセージが出力され導入が始まらない。(2020/07時点)
Step2. hostPath用ディレクトリの確認
ここでは、Spectrum Scale クラスタファイルシステム上に作成された
「/gpfs00/db2u-hostpath」ディレクトリを Db2 on OpenShift用ストレージとして利用する。
(※ディレクトリは既に作成済であることを前提とします)
hostPathのディレクトリは、利用可能であればワーカーノードから以下のように確認できる。
全てのワーカーノードからも以下のように確認できる状態であることをDb2デプロイ前に確認しておく。
# cd /gpfs00/db2u-hostpath
# ls -la
total 257
drwx------. 2 root root 4096 Jun 9 10:25 .
drwxr-xr-x. 9 root root 262144 Jun 17 19:59 ..
補足：
- Spectrum Scaleが停止していたり、マウントが行われていない状態でDb2 on OpenShiftインストールを行うことはできません。
- Spectrum Scaleが起動しているかどうかの確認はmmgetstate、起動するコマンドはmmstartup、マウントするコマンドはmmmount を実行します。詳細は、ストレージ担当にご確認いただくほうが確実です。
- 参考：IBM Spectrum Scale 5.0.5 Command reference
Step3. SELinuxが有効な環境で hostPathストレージを利用するための前提
SELinuxが有効な環境で hostPathストレージを利用するための構成は、下記マニュアルを参考に進めます。
Db2 11.5 KnowledgeCenter[SELinux 用の hostPath ストレージへのラベル付け]
https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/hostpath-selinux-aese.html
KnowledgeCenter引用：
Security Enhanced Linux® (SELinux) で hostPath ストレージを使用している場合、Red Hat® OpenShift® データベース・サービスが実行されるすべてのノードでストレージ・パスにラベルを付ける必要があります。
以下のコマンドを実行して、すべてのノード上のストレージ・パスに container_file_t SELinux ラベルを適用します。
専用デプロイメントの場合は、ラベルの付いたすべてのノードでコマンドを実行します。非専用デプロイメントの場合は、すべてのワーカー・ノードでコマンドを実行します。
① SELinuxが有効な環境であるかを確認
SELinuxが有効であるかは、sestatus コマンドによって確認します。
# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
---> "SELinux status: enabled" が返されているので、この環境では SELinux が有効であるとわかります。
② ストレージ・パスにラベルを付ける
すべてのワーカーノード上で、下記コマンドをrootユーザで実行する。
<storage_path> には、ストレージ・パス名 (今回の環境では「/gpfs00/db2u-hostpath」) を入れる。。
【コマンド構文】
chmod 777 <storage_path>
semanage fcontext -a -t container_file_t "<storage_path>(/.*)?"
restorecon -Rv <storage_path>
【実行例】
# chmod 777 /gpfs00/db2u-hostpath
# semanage fcontext -a -t container_file_t "/gpfs00/db2u-hostpath(/.*)?"
# restorecon -Rv /gpfs00/db2u-hostpath
restorecon reset /gpfs00/db2u-hostpath context system_u:object_r:unlabeled_t:s0->system_u:object_r:container_file_t:s0
Step4. クラスタの構成
① プロジェクトの作成
db2u-ss1 という名前のプロジェクトを作成。
oc new-project db2u-ss1
② セキュリティ構成
Db2インストーラを解凍したディレクトリ配下の、pak_extensions サブディレクトリのあるパスへ移動する。
セキュリティ権限構成のため、下記コマンドを実行する。
cd /work/media/ibm-db2/ibm_cloud_pak/pak_extensions
./pre-install/clusterAdministration/createSecurityClusterPrereqs.sh
次のコマンドには、引数(ネームスペース名)を指定する必要がある。
./pre-install/namespaceAdministration/createSecurityNamespacePrereqs.sh db2u-ss1
現在のプロジェクトのadminロールをtillerユーザに追加する。
oc policy add-role-to-user admin "system:serviceaccount:${TILLER_NAMESPACE}:tiller"
補足：
Openshift版 Db2 11.5.4 は、Helm V2 を利用します。
上の oc policy add-role-to-user コマンドの前提はTillerの稼働するネームスペースがOS環境変数 TILLER_NAMESPACE に設定されていることと、Helm用のサービスアカウント名がtillerであることを前提としています。環境に応じて編集して実行してください。
また、Helm用サービスアカウントに対しクラスター全体の管理者権限が付与される環境なのであれば、このコマンドの実行は不要です。
③ LDAP blueadmin の Secret を作成する
RELEASE_NAME / PASSWORD には任意の値を指定する
RELEASE_NAME="<RELEASE_NAME>"
PASSWORD="<PASSWORD>"
oc create secret generic ${RELEASE_NAME}-db2u-ldap-bluadmin --from-literal=password="${PASSWORD}"
④ Db2インスタンス の Secret を作成する
RELEASE_NAME / PASSWORD には任意の値を指定する
RELEASE_NAME="<RELEASE_NAME>"
PASSWORD="<PASSWORD>"
oc create secret generic ${RELEASE_NAME}-db2u-instance --from-literal=password="${PASSWORD}"
Step5. IBM Container Registry へのアクセス
Db2 Community Edition container のイメージは、IBM Cloud Container Registry から入手するため、IBM Cloud Registry にアクセスするための準備を行う。
① APIキーを作成する
IBM Cloudにログインする
https://cloud.ibm.com/login
ツールバーから Manage > Access (IAM) を選択
サイドメニューから「API Keys」を選択し「Create an IBM Cloud API Key(IBM Cloud API キーの作成)」を選択
任意の名前/説明を入力し「create」を押下
APIキーをコピーするか、ダウンロードして保管する
② Db2をデプロイするプロジェクトにて、イメージレジストリのSecretを作成する
--docker-passwordの値として、上で作成したAPIキーを指定して Secret を作成する
oc create secret docker-registry ibm-registry \
--docker-server=icr.io \
--docker-username=iamapikey \
--docker-password=<API_KEY>
※ docker-username の値には常に iamapikey を指定する
Pod のイメージのプルにシークレットを使用するため、シークレットをサービスアカウントに追加する。
下記コマンドを実行する
oc secrets link db2u ibm-registry --for=pull
Step6. Persistent Volume(PV) 作成
yamlファイルを作成する。
apiVersion: v1
kind: PersistentVolume
metadata:
name: hostpath-db2u-pv01
labels:
type: local
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 10Gi
storageClassName: scale-hostpath
persistentVolumeReclaimPolicy: Retain
hostPath:
path: "/gpfs00/db2u-hostpath"
PVを作成する。
oc create -f create_ss_pv.yaml
Step7. Persistent Volume Claim(PVC) 作成
yamlファイルを作成する。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: hostpath-db2u-pvc01
namespace: db2u-ss1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: scale-hostpath
PVCを作成する。
oc create -f create_ss_pvc.yaml
Step8. Helm option 指定(オプション)
HADR環境として構成したい場合やRESTを利用したい場合など、必要に応じて、helm_option ファイルを編集する。
今回は追加オプションを指定したい要件はないため、編集は行わない。
helm_option ファイルはDb2 on OpenShiftインストーラ(db2u-install)と同じロケーションに配置されている。
※/ibm_cloud_pak/pak_extensions/common
デフォルトの helm_option ファイルの記述内容はこちら。
rest.enabled="false"
storage.useDynamicProvisioning="true"
storage.enableVolumeClaimTemplates="true"
storage.storageLocation.dataStorage.enablePodLevelClaim="true"
storage.storageLocation.dataStorage.enabled="true"
storage.storageLocation.dataStorage.volumeType="pvc"
storage.storageLocation.dataStorage.pvc.claim.storageClassName="ocs-storagecluster-ceph-rbd"
storage.storageLocation.dataStorage.pvc.claim.size="40Gi"
storage.storageLocation.metaStorage.enabled="true"
storage.storageLocation.metaStorage.volumeType="pvc"
storage.storageLocation.metaStorage.pvc.claim.storageClassName="ocs-storagecluster-cephfs"
storage.storageLocation.metaStorage.pvc.claim.size="40Gi"
Step9. PATH設定
インストーラ(db2u-install コマンド) 内では helmコマンドが実行されるため、インストーラ実行前にパスを通する必要がある。
PATH環境変数に、helmコマンドのパスを設定する。
export PATH=$PATH:/work/HelmV2.16.9/linux-amd64
Step10. Db2 on OpenShift のインストール
Db2 OLTPを導入するには、--db-type に OLTP を指定してインストールコマンド(db2u-install)を実行する。
※くどいですが、charts-master.zipを展開したディレクトリ配下では実行しないほうがよいです。
stable/ibm-db2 ディレクトリだけ移動させたディレクトリで実行するのが、2020/07時点では確実です。
【インストールコマンド構文】
インストールコマンドの構文は下記の通り。
cd /work/media/ibm-db2/ibm_cloud_pak/pak_extensions/common
./db2u-install
--db-type db2oltp
--db-name <DB_NAME>
--namespace <NAMESPACE(PROJECT)_NAME>
--release-name <RELEASE_NAME>
[--existing-pvc STRING | --storage-class STRING | --helm-opt-file FILENAME ] [OTHER ARGUMENTS...]
今回指定したオプションは下記の通り。
■必須オプション
- --db-type : db2oltp (通常のDb2) もしくは db2wh (Db2 Warehouse) を指定
- --namespace：Db2をデプロイするネームスペース(プロジェクト)名を指定
- --release-name：Helmリリース名として任意の文字列を指定
■任意オプション
- --db-name：作成されるデータベースの名称。(省略すると BLUDB になる)
- --existing-pvc：今回は事前定義済のPV/PVCを利用する想定のため、Step7で作成したPVC名を指定
【インストールコマンド実行/標準出力例】
cd /work/media/Db2_11.5.4/ibm-db2/ibm_cloud_pak/pak_extensions/common
./db2u-install --db-type db2oltp --db-name TEST3 --namespace db2u-ss1 --release-name db2u-ss-1 --existing-pvc hostpath-db2u-pvc01 --accept-eula
Mon Aug 3 03:22:25 CDT 2020
NAME: db2u-ss-1
LAST DEPLOYED: Mon Aug 3 03:22:25 2020
NAMESPACE: db2u-hostpath
STATUS: DEPLOYED
RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
db2u-ss-1-db2u-config 2 1s
db2u-ss-1-db2u-hadr-config 1 1s
db2u-ss-1-db2u-lic 1 1s
db2u-ss-1-db2u-uc-config 23 1s
db2u-ss-1-db2u-wv-config 1 1s
==> v1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
db2u-ss-1-db2u-ldap 0/1 1 0 1s
db2u-ss-1-db2u-tools 0/1 1 0 1s
==> v1/Job
NAME COMPLETIONS DURATION AGE
db2u-ss-1-db2u-engn-update-job 0/1 0s 1s
db2u-ss-1-db2u-nodes-cfg-job 0/1 1s 1s
db2u-ss-1-db2u-restore-morph-job 0/1 1s 1s
db2u-ss-1-db2u-sqllib-shared-job 0/1 1s 1s
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
db2u-ss-1-db2u-0 0/1 Init:0/2 0 1s
db2u-ss-1-db2u-engn-update-job-75jxv 0/1 Init:0/2 0 1s
db2u-ss-1-db2u-ldap-fbc58696d-w5bcj 0/1 Init:0/1 0 1s
db2u-ss-1-db2u-nodes-cfg-job-5r7qk 0/1 Pending 0 1s
db2u-ss-1-db2u-restore-morph-job-x2wlv 0/1 Init:0/1 0 1s
db2u-ss-1-db2u-sqllib-shared-job-ztcmc 0/1 Pending 0 1s
db2u-ss-1-db2u-tools-5c7ffb6b64-5wbpr 0/1 ContainerCreating 0 1s
db2u-ss-1-etcd-0 0/1 Init:0/1 0 1s
==> v1/Secret
NAME TYPE DATA AGE
db2u-ss-1-db2u-ldap Opaque 1 1s
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db2u-ss-1-db2u ClusterIP 172.30.4.108 <none> 50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP 1s
db2u-ss-1-db2u-engn-svc NodePort 172.30.242.245 <none> 50000:31703/TCP,50001:31845/TCP 1s
db2u-ss-1-db2u-internal ClusterIP None <none> 50000/TCP,9443/TCP 1s
db2u-ss-1-db2u-ldap ClusterIP 172.30.137.193 <none> 50389/TCP 1s
db2u-ss-1-db2u-rest-svc NodePort 172.30.45.32 <none> 50050:32325/TCP 1s
db2u-ss-1-etcd ClusterIP None <none> 2380/TCP,2379/TCP 1s
==> v1/StatefulSet
NAME READY AGE
db2u-ss-1-db2u 0/1 1s
db2u-ss-1-etcd 0/3 1s
NOTES:
db2oltp have been installed
上のようなログメッセージが出力されれば、インストールコマンドは正常に実行完了している。
このインストールコマンドによって、Db2 の StatefulSet としてのデプロイが開始される。
(中で実行されるのは、helm install コマンドによる、ibm-db2 chartを用いたDb2のデプロイ)
インストールコマンド完了＝Db2のデプロイ完了というわけではないため、
ocコマンドなどによって、Db2のPodが実行中(Running)状態となり、Db2データベースに接続できる状態であるかを確認していく。
Step11. インストール完了確認
① Db2関連Podの稼働状況の確認
Db2 on OpenShift のインストールの状況は、oc get pods コマンドで確認可能。
さらに-o wide オプションを追加すると、どのノードで稼働しているかも確認できる。
「restore-morph」という名前を含むジョブがCompletedの状態になったら、インストールが完了してDb2が使える状態となったことを示す。
インストールコマンド実行にてコンテナ版Db2バイナリのダウンロード等が行われ、所要時間は環境による異なる可能性があり、一概の目安は存在しない。(今回の環境では十数分程度)
oc get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
db2u-ss-1-db2u-0 1/1 Running 0 40m 10.131.0.116 worker3 <none> <none>
db2u-ss-1-db2u-engn-update-job-kvhhz 0/1 Completed 0 40m 10.131.0.120 worker3 <none> <none>
db2u-ss-1-db2u-ldap-fbc58696d-nd6fl 1/1 Running 0 40m 10.129.2.79 worker1 <none> <none>
db2u-ss-1-db2u-nodes-cfg-job-t9n5r 0/1 Completed 0 39m 10.131.0.122 worker3 <none> <none>
db2u-ss-1-db2u-restore-morph-job-q7b9n 0/1 Completed 0 40m 10.131.0.119 worker3 <none> <none>
db2u-ss-1-db2u-sqllib-shared-job-ckcln 0/1 Completed 0 40m 10.129.2.81 worker1 <none> <none>
db2u-ss-1-db2u-tools-5c7ffb6b64-4j7sk 1/1 Running 0 40m 10.131.0.117 worker3 <none> <none>
db2u-ss-1-etcd-0 1/1 Running 0 40m 10.129.2.80 worker1 <none> <none>
db2u-ss-1-etcd-1 1/1 Running 0 39m 10.131.0.124 worker3 <none> <none>
db2u-ss-1-etcd-2 1/1 Running 0 39m 10.128.2.215 worker2 <none> <none>
「db2u-ss-1-db2u-restore-morph-job-d2xbv」の状態が「Completed」であり、
Db2エンジン本体のPodである「db2u-ss-1-db2u-0」の状態が「Running」であることから、導入成功している。
② 動作確認
Db2 の Pod「db2u-ss-1-db2u-0」 にログインし、データベースに接続できることを確認する。
Podには以下のコマンドでログインする。
$ oc rsh <RELEASE_NAME>-db2u-0 /bin/bash
【動作確認例】
ログイン時のユーザは Db2コマンド実行権限を持たないdb2uadm であるため、Podへのログインが成功したらdb2inst1 ユーザに su する。
以下は、DBに接続しテスト用テーブルを作成し、データを挿入することで動作確認を行う例。
# oc rsh db2u-ss-1-db2u-0 /bin/bash
[db2uadm@db2u-ss-1-db2u-0 /]$ whoami
db2uadm
[db2uadm@db2u-ss-1-db2u-0 /]$ su - db2inst1
Last login: Mon Jul 13 04:43:27 UTC 2020 on console
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ which db2
~/sqllib/bin/db2
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 list db directory
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = TESTDB
Database name = TESTDB
Local database directory = /mnt/blumeta0/db2/databases
Database release level = 15.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
Alternate server hostname =
Alternate server port number =
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 connect to testdb
Database Connection Information
Database server = DB2/LINUXX8664 11.5.4.0
SQL authorization ID = DB2INST1
Local database alias = TESTDB
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 list tables
Table/View Schema Type Creation time
------------------------------- --------------- ----- --------------------------
0 record(s) selected.
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 "create table t1 (c1 integer, c2 char(32))"
DB20000I The SQL command completed successfully.
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 "insert into t1 values(1,'a'),(2,'b')"
DB20000I The SQL command completed successfully.
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"
C1 C2
----------- --------------------------------
1 a
2 b
2 record(s) selected.
[db2inst1@db2u-ss-1-db2u-0 - Db2U db2inst1]$ db2 terminate
---> 導入したDb2は問題なく稼働している。
ライセンスの登録状況確認
Db2 V11.5では、ライセンスを適用しなくても Community Editionという無償版ライセンスが適用された状態となっている。旧バージョンのDb2試用版のように90日経過したらDb2が起動しなくなるということはない。
この点はDb2 on OpenShiftも共通。
導入したDb2のライセンスは、下記コマンドを実行することで確認できる。
【確認コマンド実行例】
※「RELEASE_NAME」の箇所は環境に応じて書き換える。
# DB2PATH=`oc rsh <RELEASE_NAME>-db2u-0 bin/bash -c "db2ls | cut -d ' ' -f 1 | awk 'NR==4'" | sed $'s/[^[:print:]\t]//g'`
# oc rsh <RELEASE_NAME>-db2u-0 /bin/bash -c "sudo $DB2PATH/adm/db2licm -l"
Product name: "DB2 Enterprise Server Edition"
License type: "License not registered"
Expiry date: "License not registered"
Product identifier: "db2ese"
Version information: "11.5"
Product name: "IBM DB2 Developer-C Edition"
License type: "Community"
Expiry date: "Permanent"
Product identifier: "db2dec"
Version information: "11.5"
Max amount of memory (GB): "16"
Max number of cores: "4"
Max amount of table space (GB): "100"
Community Edition ライセンスが適用されている状態であることが確認できた。
- 有償版ライセンスを追加する手順はこちら → Db2 on OpenShift に有償ライセンスを登録
Tips：
2020.07時点のKnowledgeCenterに記載の手順ではPermission Deniedエラーのためdb2licmコマンドが失敗する。
Db2 11.5.4 on OpenShift のログイン時のユーザは db2uadm というユーザIDで、db2licmコマンドの実行権限が与えられていないためと考えられる。
そこで、上の手順ではsudoで実行することでroot権限にてdb2licmコマンドを実行している。
接続情報
Liberty など、OCPクラスタ内からのDB接続時に必要となる接続情報として、クラスターIPアドレスとポート番号を確認する。
① クラスターIPアドレス
プロジェクト名、リリース名は環境に応じて書き換えて実行する。
oc get svc -n <PROJECT> <RELEASE-NAME>-db2u-engn-svc -o jsonpath='{.spec.ports[?(@.name=="legacy-server")].nodePort}'
② ポート番号
プロジェクト名、リリース名は環境に応じて書き換えて実行する。
oc get svc -n <PROJECT> <RELEASE-NAME>-db2u-engn-svc -o jsonpath='{.spec.clusterIP}'
なお、インスタンスオーナー db2inst1 ユーザで接続する場合のパスワードは、導入手順 Step3. ④ で設定したものとなっている。
以上です。