Db2 Warehouse 11.5.4 on OpenShift（以下Db2WH）を検証環境に導入しました。（手順はGitHubやKnowledge Centerに公開されている情報に基づいています。）
目次
前提要件
コンポーネントの要件
- Kubernetesのバージョン：1.11.0以上
- Helmのバージョン Level:X86: ">=2.14(*) and < 3.0"
- X86の場合：2.14以上、3.0未満
- Powerの場合：2.12以上、3.0未満
- OpenShiftのバージョン：3.11, 4.x
（GitHubには4.3までの記載しかないが、Knowledge Centerでは4.xとなっている） - 永続ボリューム：以下のいずれかが使用可能であること
- 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
- IBM Cloudのアカウントがあること
リソース要件
※Knowledge Center と GitHub で記載されている値が異なりますが、本記事ではGitHubの値を記載しています。必要に応じてKnowledge Centerも参照してください。
- SMPの場合
- ノード数：1
- CPU：7.7コア（4コアがDb2エンジンで使用され、残り3.7コアはそれ以外で使用）
- メモリ：22.4GiB（16GiBがDb2エンジンで使用され、残り6.4GiBはそれ以外で使用）
- MPPの場合
- ノード数：2-999
- CPU：7.7コア（4コアがDb2エンジンで使用され、残り3.7コアはそれ以外で使用）
- メモリ：22.4GiB 以上（使用するワーカー・ノード数に応じて増加）
- ワーカー・ノード1つ：16GiB
- ワーカー・ノード2つ以上：24GiB
導入環境
各コンポーネントのバージョン
| 項目 | バージョン |
|---|---|
| OS(bastion) | RHEL 7.7 |
| OS(master/worker) | RHEL 7.7 |
| OCP(Client) | 4.5.0-202007240519.p0-b66f2d3 |
| OCP(Server) | 4.5.7 |
| Kubernetes | v1.17.1+912792b |
| Helm | 2.16.9 |
| NFS | 4.2 |
| Db2 Warehouse | 11.5.4.0 |
論理構成
今回の検証で使用した環境構成は以下の様になっています。
サーバー・リソース
検証環境の各Nodeサーバーのスペックです。
| 項目 | vCPU | メモリ |
|---|---|---|
| Master node | 4 core | 16GB |
| Worker node | 16 core | 64GB |
| Bastion | 4 core | 8GB |
※ ストレージには、当該環境では最も準備が容易だったNFSを選択しています。
今回はBastionサーバをNFSサーバとして構築し、Bastionサーバのローカルファイルシステムの1つをNFSボリュームとしてexportする単純な構成としています。
ストレージ構成は今回の導入検証のための簡易テスト環境であり、実際の本番環境での利用にあたっては技術的な構成確認の場をメーカー(IBM)側にとるようにお願いします。
事前準備
まずDb2WHデプロイ用のプロジェクトを作成します。
プロジェクトの作成
以下のコマンドでプロジェクトを作成します。
-- 今回はdb2-warehouse1 という名前で作成する
[root@k3bastion]# oc new-project db2-warehouse1
NFSサーバー・PV・PVCの設定
続いて、Db2WHで使用するPV (Persistent Volume)の作成をします。今回はPVのストレージにはNFSを使用するため「NFSサーバーの設定」をしてから「PV・PVCの作成」を行っています。
なお検証環境ではNFSサーバー自体は構築済みだったため、本手順ではディレクトリの作成とNFSエクスポートの設定のみを行います。（詳細はKnowledge Centerを参照してください。）
PV用ディレクトリの作成
Db2WHに保存されるデータの実体がこのディレクトリに保存されます。
-- ディレクトリ作成
[root@k3bastion]# mkdir -p /work/nfsdir/Db2WH
-- 確認
[root@k3bastion]# ls -l /work/nfsdir/
total 8
drwxrwxrwx. 16 root root 4096 Aug 3 02:44 Db2NFS
drwxr-xr-x. 2 root root 6 Aug 3 21:46 Db2WH
drwxrwxrwx. 2 root root 6 May 22 06:54 ocp
-- パーミッションを他のディレクトリと揃える
[root@k3bastion]# chmod 777 /work/nfsdir/Db2WH
-- 確認
[root@k3bastion]# ls -l /work/nfsdir/
total 8
drwxrwxrwx. 16 root root 4096 Aug 3 02:44 Db2NFS
drwxrwxrwx. 2 root root 6 Aug 3 21:46 Db2WH
drwxrwxrwx. 2 root root 6 May 22 06:54 ocp
NFSサーバーのエクスポートオプションの設定
作成したディレクトリをNFSとして登録します。
-- /etc/exports のバックアップを取っておく
[root@k3bastion]# cp -p /etc/exports /etc/exports.`date +%Y%m%d_%H%M%S`
-- 確認
[root@k3bastion]# ls -l /etc/exports*
-rw-r--r--. 1 root root 319 Jul 4 02:18 /etc/exports
-rw-r--r--. 1 root root 319 Jul 4 02:18 /etc/exports.20200803_215846
-rw-r--r--. 1 root root 157 May 25 03:23 /etc/exports.no_fsid
/etc/exports.d:
total 0
-- /etc/exportsを編集
-- db2_openshiftworker1_IP_addressは環境に合わせて入力する
[root@k3bastion]# echo "/work/nfsdir/Db2WH db2_openshiftworker1_IP_address(rw,sync,no_wdelay,no_root_squash,insecure)" >> /etc/exports
-- /etc/exportsファイルのNFSの設定を反映（exportfs -aまたはexportfs -r）
[root@k3bastion]# exportfs -a
-- 構成の反映を確認
[root@k3bastion]# exportfs -v
/etc/fstab の編集
Knowledge Centerには/etc/fstabの編集手順がありますが、以下のPV定義の中（spec.mountOptions）で同様の設定をしているため今回は省略しています。
PVの作成
PVのyamlファイルを作成しPVを作成します。
-- PVのyamlファイルの作成
[root@k3bastion]# vi /work/db2-warehouse/00_db2wh-nfs-pv.yaml
SELinuxが有効になっている場合 Knowledge Centerの記載に従って以下の様にmountOptionsの内容を加える必要があります。
（使用する永続ボリュームの種類によって追加設定の内容が変わります。）
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv00-nfsdb2wh #←任意の名前でよい
labels:
type: nfs-00
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: slow
mountOptions:
#SELinux が有効の場合に必要な設定項目
- v4.2
- context="system_u:object_r:container_file_t:s0"
#Knowledge Center では /etc/fstab を編集するとなっている項目
- hard
nfs:
path: /work/nfsdir/Db2WH #←前手順で作成したディレクトリのパス
server: 10.1.1.1 #←実際のIPアドレス入力する
-- PVの作成
[root@k3bastion]# oc create -f /work/db2-warehouse/00_db2wh-nfs-pv.yaml
PVCの作成
PVCのyamlファイルを作成しPVCを作成します。
-- PVCのyamlファイルの作成
[root@k3bastion]# vi /work/db2-warehouse/00_db2wh-nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc00-nfsdb2wh #←任意の名前でよい
namespace: db2-warehouse1 #←上で作成したプロジェクト名を記載する
spec:
selector:
matchLabels:
type: "nfs-00" #←PVのyamlファイル内のmetadata:labels:typeの値と一致する必要がある
accessModes:
- ReadWriteOnce
storageClassName: slow
resources:
requests:
storage: 10Gi
-- PVCの作成
[root@k3bastion]# oc create -f /work/db2-warehouse/00_db2wh-nfs-pvc.yaml
CRI-O PID拡張
本設定は必須ではなく推奨設定という位置付けです。Db2WHコンテナ内で多くのプロセスが起動される可能性がある場合にPIDの上限を拡張しておく必要があります。
設定手順は以下の記事を参照してください。
Db2 11.5.4 on Openshift デプロイのための前提作業 (2) CRI-O PID 拡張
IBMクラウド・コンテナ・レジストリのsecret作成
IBMクラウド・コンテナ・レジストリにはIBMが公開しているコンテナイメージがあり、Db2WHインストール時にはここからコンテナ・イメージがPullされます。以下ではIBMクラウド・コンテナ・レジストリへの接続情報の取得・登録を行います。
APIキーの取得
IBM Cloud にログインします。
管理 > アクセス(IAM)に進みます。
APIキーの項目に進みます。
IBM Cloud APIキーの作成をクリックします。
名前、説明を入力します。
作成されたAPIキーをコピーするかダウンロードして保管します。
ダウンロードしたAPIキーを使用してシークレットを作成します。
-- 上でコピーしたAPIキーをdocker-passwordに指定する
[root@k3bastion]# oc create secret docker-registry ibm-registry \
--docker-server=icr.io \
--docker-username=iamapikey \
--docker-password= <API_KEY>
-- 作成したシークレットをサービスアカウントに追加する
[root@k3bastion]# oc secrets link db2u ibm-registry --for=pull
Db2WHのインストール
Helm chartのダウンロードと配置
IBMが提供する各製品のHelm chart一式をダウンロードし、その中からDb2 Wharehouseのchartを取り出して利用します。次のURLからチャートをダウンロードします。
https://github.com/IBM/charts/tree/master/
（GitHubの仕様上プロジェクト単位でしかダウンロードができないため、個別のchartのみのダウンロードができません。）
ダウンロードしたzipの中身は以下の構造になっており、この中からibm-db2warehouseディレクトリを取り出して使用します。
charts-master
├── LICENSE
├── ORIGIN
├── README.md
├── #途中省略
└── stable
├── ibm-ace-dashboard-dev
├── #途中省略
├── ibm-db2
├── ibm-db2warehouse '←今回使用するchart'
├── ibm-dsx-dev
└── #以下省略
次にibm-db2warehouseディレクトリをOCP環境（Bastionサーバー）に転送・配置します。
※ibm-db2warehouseを配置するディレクトリには、ibm-db2warehouseのみが存在する状態にしてください。インストール実行時にibm-db2warehouse以外のディレクトリ・ファイルがあるとエラーとなります。
-- 今回は/work/media/Db2_Warehouse_11.5.4.0/に配置した
[root@k3bastion]# tree -L 1 /work/media/Db2_Warehouse_11.5.4.0/
/work/media/Db2_Warehouse_11.5.4.0/
└── ibm-db2warehouse
-- ↑この様にibm-db2warehouseディレクトリのみを配置する
権限・シークレットの構成
先ほど配置したibm-db2warehouseのサブディレクトリに含まれるシェルスクリプトを実行して、Db2WH導入に必要な権限設定及び、シークレットの作成を行います。
-- SecurityContextConstraints(SCC) を定義するシェルの実行する
--（SCC：Podのパーミッションを制御するためのオブジェクト）
[root@k3bastion]# cd /work/media/Db2_Warehouse_11.5.4.0/ibm-db2warehouse/
[root@k3bastion]# cd ibm_cloud_pak/pak_extensions
[root@k3bastion]# ./pre-install/clusterAdministration/createSecurityClusterPrereqs.sh
-- db2uというサービスアカウントを作成するシェルを実行する
--（引数にNameSpaceを指定する）
[root@k3bastion]# ./pre-install/namespaceAdministration/createSecurityNamespacePrereqs.sh db2-warehouse1
-- tillerユーザーにプロジェクトのadmin権限を与える
--（tillerはHelm(V2.x系まで)内のサーバーコンポーネント）
[root@k3bastion]# oc policy add-role-to-user admin "system:serviceaccount:${TILLER_NAMESPACE}:tiller"
続いて LDAP bluadmin・Db2インスタンスのシークレット情報を作成します。
-- bluadminのシークレット作成
[root@k3bastion]# RELEASE_NAME="db2-warehouse1" #←任意のリリース名を付ける
[root@k3bastion]# PASSWORD="passw0rd" #←任意のパスワードを入れる
[root@k3bastion]# oc create secret generic ${RELEASE_NAME}-db2u-ldap-bluadmin --from-literal=password="${PASSWORD}"
-- db2inst1のシークレット作成
[root@k3bastion]# RELEASE_NAME="db2-warehouse1" #←任意のリリース名を付ける
[root@k3bastion]# PASSWORD="passw0rd" #←任意のパスワードを入れる
[root@k3bastion]# oc create secret generic ${RELEASE_NAME}-db2u-instance --from-literal=password="${PASSWORD}"
【参考情報】
SecurityContextConstraints(SCC)について
サービスアカウントについて
Helm Tillerについて
インストール・コマンドの実行
ここまででインストールの準備が完了したので、インストール・コマンド（シェルスクリプト）db2u-installを使用してインストールを実施します。コマンド内ではhelmコマンドが実行されています。
インストールコマンドの構文
./db2u-install --db-type STRING --namespace STRING --release-name STRING
[--existing-pvc STRING | --storage-class STRING | --helm-opt-file FILENAME ] [OTHER ARGUMENTS...]
| 必須オプション | 説明 |
|---|---|
| --db-type STRING | DBタイプとしていずれかを指定する：db2wh, db2oltp |
| --namespace STRING | Db2をインストールするnamespace/project名を指定する |
| --release-name STRING | Helmのリリース名を指定する |
| 任意オプション | |
| --db-name STRING | DB名を指定する（デフォルトではBLUDB） |
| --existing-pvc STRING | 永続ストレージとして使用するPersistentVolumeClaim名を指定する |
| --storage-class STRING | Dynamic プロビジョンに使用するStorageClassを指定する |
| --cpu-size STRING | ポッド起動時のCPUコア数を指定する |
| --memory-size STRING | ポッド起動時のメモリサイズを指定する |
| --helm-opt-file STRING | Helmオプションを含むファイルのパスを指定する |
| --accept-eula | ダイアログを表示せずに使用許諾契約に同意する場合指定する |
| ※上記以外のオプションはGitHubを参照してください。 |
db2u-installコマンドの実行例
-- db2u-installコマンドのディレクトリに移動
[root@k3bastion]# cd /work/media/Db2_Warehouse_11.5.4.0/ibm-db2warehouse/ibm_cloud_pak/pak_extensions/common
-- インストールコマンドの実行
[root@k3bastion]# ./db2u-install --db-type db2wh --namespace db2-warehouse1 --release-name db2-warehouse1 \
--existing-pvc pvc00-nfsdb2wh --accept-eula
NAME: db2-warehouse1
LAST DEPLOYED: Thu Aug 6 02:44:05 2020
NAMESPACE: db2-warehouse1
STATUS: DEPLOYED
RESOURCES:
==> v1/ConfigMap
NAME DATA AGE
db2-warehouse1-db2u-config 2 1s
db2-warehouse1-db2u-hadr-config 1 1s
db2-warehouse1-db2u-lic 1 1s
db2-warehouse1-db2u-uc-config 23 1s
db2-warehouse1-db2u-wv-config 1 1s
==> v1/Deployment
NAME READY UP-TO-DATE AVAILABLE AGE
db2-warehouse1-db2u-ldap 0/1 1 0 1s
db2-warehouse1-db2u-tools 0/1 1 0 1s
==> v1/Job
NAME COMPLETIONS DURATION AGE
db2-warehouse1-db2u-engn-update-job 0/1 1s 1s
db2-warehouse1-db2u-nodes-cfg-job 0/1 1s 1s
db2-warehouse1-db2u-restore-morph-job 0/1 1s 1s
db2-warehouse1-db2u-sqllib-shared-job 0/1 0s 1s
==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
db2-warehouse1-db2u-0 0/1 Init:0/2 0 1s
db2-warehouse1-db2u-engn-update-job-pzn8g 0/1 Init:0/2 0 0s
db2-warehouse1-db2u-ldap-67f6bdd748-ch9gm 0/1 Init:0/1 0 1s
db2-warehouse1-db2u-nodes-cfg-job-l6gk6 0/1 Init:0/1 0 1s
db2-warehouse1-db2u-restore-morph-job-4ppvr 0/1 Init:0/1 0 1s
db2-warehouse1-db2u-sqllib-shared-job-tf2cn 0/1 ContainerCreating 0 1s
db2-warehouse1-db2u-tools-65c8bc64d-zlntj 0/1 ContainerCreating 0 1s
db2-warehouse1-etcd-0 0/1 Init:0/1 0 1s
==> v1/Secret
NAME TYPE DATA AGE
db2-warehouse1-db2u-ldap Opaque 1 1s
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db2-warehouse1-db2u ClusterIP 172.30.136.35 <none> 50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP 1s
db2-warehouse1-db2u-engn-svc NodePort 172.30.68.219 <none> 50000:31382/TCP,50001:31006/TCP 1s
db2-warehouse1-db2u-internal ClusterIP None <none> 50000/TCP,9443/TCP 1s
db2-warehouse1-db2u-ldap ClusterIP 172.30.166.222 <none> 50389/TCP 1s
db2-warehouse1-db2u-rest-svc NodePort 172.30.191.70 <none> 50050:32416/TCP 1s
db2-warehouse1-etcd ClusterIP None <none> 2380/TCP,2379/TCP 1s
==> v1/StatefulSet
NAME READY AGE
db2-warehouse1-db2u 0/1 1s
db2-warehouse1-etcd 0/3 1s
NOTES:
db2wh have been installed
上の様な出力が出たらインストールコマンドは正常終了していますが、全てのPodが正常に起動するのに少し時間がかかります。（検証環境では10分程度）
Db2 Warehouse on OpenShiftは単一Podではなく、複数のPod群で構成されています。以下の様に全てのPodが正常に起動（RunningまたはCompleted）すると、Db2WHが使える状態になります。（まれにPodのSTATUS が Error、Evicted、Init:Error等になっている場合がありますが、同じ役割の別Podが正常に起動していれば問題ありません。）
-- Db2WHをインストールしたnamespaceを指定して、Podの一覧を表示
[root@k3bastion]# oc get pod -n db2-warehouse1
NAME READY STATUS RESTARTS AGE
db2-warehouse1-db2u-0 1/1 Running 0 17d
db2-warehouse1-db2u-engn-update-job-zkdw5 0/1 Completed 0 17d
db2-warehouse1-db2u-ldap-5c798bb7bf-9m69l 1/1 Running 0 17d
db2-warehouse1-db2u-nodes-cfg-job-vgf5k 0/1 Init:Error 0 46h #←このPodは起動に失敗しているが下に別名で同じ役割のPodが正常に起動・終了しているため問題ない
db2-warehouse1-db2u-nodes-cfg-job-2m2m4 0/1 Completed 0 17d
db2-warehouse1-db2u-restore-morph-job-b7fh5 0/1 Completed 0 17d
db2-warehouse1-db2u-sqllib-shared-job-zhvss 0/1 Completed 0 17d
db2-warehouse1-db2u-tools-5996967cb-2p5xn 1/1 Running 0 17d
db2-warehouse1-etcd-0 1/1 Running 0 17d
db2-warehouse1-etcd-1 1/1 Running 0 17d
db2-warehouse1-etcd-2 1/1 Running 0 17d
動作確認
導入後の動作確認として「Podにログインしての操作」「OpenShiftクラスター外のclientからの操作」「Unified Consoleを使用した操作」の3パターンを紹介します。
Pod内でのDb2WHの動作確認
Db2WHのPod db2-warehouse1-db2u-0にログインし、DBの確認、DBへの接続、テスト表の作成を実施します。
-- Podログイン後 db2inst1にスイッチする必要があるため、-cオプションでログインと同時にsuコマンドを実行
[root@k3bastion]# oc rsh -n db2-warehouse1 db2-warehouse1-db2u-0 /bin/bash -c 'su - db2inst1'
-- 作成されているDBを確認
-- →BLUDBが1つだけ作成されている
[db2inst1@db2-warehouse1-db2u-0]$ db2 list db directory
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = BLUDB
Database name = BLUDB
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 =
-- BLUDBに接続
[db2inst1@db2-warehouse1-db2u-0]$ db2 connect to bludb
Database Connection Information
Database server = DB2/LINUXX8664 11.5.4.0
SQL authorization ID = DB2INST1
Local database alias = BLUDB
-- 動作確認用にtest_tableを作成
[db2inst1@db2-warehouse1-db2u-0]$ db2 create table test_table "(c1 int not null primary key, c2 varchar(30))"
DB20000I The SQL command completed successfully.
-- データを挿入
[db2inst1@db2-warehouse1-db2u-0]$ db2 "insert into test_table values(1,'aaa'),(2,'bbb')"
DB20000I The SQL command completed successfully.
-- 挿入したデータの確認
[db2inst1@db2-warehouse1-db2u-0]$ db2 "select * from test_table"
C1 C2
----------- ------------------------------
1 aaa
2 bbb
2 record(s) selected.
クラスター外のDb2 clientを使用した動作確認
Db2WHを導入したOpenShiftクラスター外にあるDb2 Clientを使用した動作確認を行います。今回はローカルPCに導入しているDb2 for Dockerから接続しています。
まずDb2WHへの接続に使用するポートの確認をします。Knowledge Centerで紹介されているNon-SSL portの確認コマンドを使ってポートを確認します。
-- まず、確認対象のサービス名を確認する（db2u-engn-svcが付いているサービス名）
---- 今回のサービス名は db2-warehouse1-db2u-engn-svc
[root@k3bastion murata]# oc get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db2-warehouse1-db2u ClusterIP 172.30.247.160 <none> 50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP 14d
db2-warehouse1-db2u-engn-svc NodePort 172.30.68.125 <none> 50000:32010/TCP,50001:31979/TCP 14d
db2-warehouse1-db2u-internal ClusterIP None <none> 50000/TCP,9443/TCP 14d
db2-warehouse1-db2u-ldap ClusterIP 172.30.49.27 <none> 50389/TCP 14d
db2-warehouse1-db2u-rest-svc NodePort 172.30.238.158 <none> 50050:31116/TCP 14d
db2-warehouse1-etcd ClusterIP None <none> 2380/TCP,2379/TCP 14d
-- 確認したサービス名を使ってサービスの定義情報からNon-SSL接続に使用するポート番号を確認する
[root@k3bastion]# oc get svc -n db2-warehouse1 db2-warehouse1-db2u-engn-svc -o jsonpath='{.spec.ports[?(@.name=="legacy-server")].nodePort}'
32010[root@k3bastion]#
-- 少し分かりにくいが2行目の左端に、確認結果「32010」が出力されている
-- このポートが今回外部からの接続に使用するポート番号（この番号は環境によって変わる）
今回の検証環境ではKnowledge Centerにも書かれている様に、NodePortを介してOpenShiftクラスターの外部と通信をするためにIngressコントローラーの設定をする必要があります。以下の様に/etc/haproxy/haproxy.cfgに設定の追加・反映をします。
-- 設定ファイルを編集する
[root@k3bastion]# vi /etc/haproxy/haproxy.cfg
frontend db2
bind *:32010
default_backend db2u
mode tcp
option tcplog
backend db2u
balance source
mode tcp
server worker1 worker1-PrivateIP:32010 check
server worker2 worker2-PrivateIP:32010 check
server worker3 worker3-PrivateIP:32010 check
#-- worker1(2,3)-PrivateIPは各ワーカーノードのプライベートIPアドレス
-- 設定を反映する
[root@k3bastion]# systemctl reload haproxy
以上の設定で「Bastionサーバーの32010ポート」→「各ワーカーノードの32010ポート」→「Db2WHポッドの50000ポート」という具合に通信が可能になります。
続いてDb2 Client側から実際に接続します。以下の操作はローカルPC上のDb2(containter)を起動してログインして実施しています。
-- 接続先のサーバーをカタログする（ノード名はwhopsftとしている）
---- XXX.XXX.XXX.XXXは今回はBastionサーバーのIPアドレス
[db2inst1@container]$ db2 catalog tcpip node whopsft remote XXX.XXX.XXX.XXX server 32010
-- BLUDBをカタログする
[db2inst1@container]$ db2 catalog db bludb as bludb1 at node whopsft1
-- db2inst1ユーザーを使用してBLUDBに接続する
---- db2inst1_password は db2inst1のシークレット情報作成時に設定したパスワード
[db2inst1@container]$ db2 connect to bludb1 user db2inst1 using db2inst1_password
-- DB内の表一覧の取得
---- Pod内での動作確認を行っていれば、その際に作成した表が確認できる
[db2inst1@container]$ db2 list tables
-- 動作確認用にtest_table2を作成
[db2inst1@container]$ db2 create table test_table2 "(c1 int not null primary key, c2 varchar(30))"
DB20000I The SQL command completed successfully.
-- データを挿入
[db2inst1@container]$ db2 "insert into test_table2 values(1,'AAA'),(2,'BBB')"
DB20000I The SQL command completed successfully.
-- 挿入したデータの確認
[db2inst1@container]$ db2 "select * from test_table2"
C1 C2
----------- ------------------------------
1 AAA
2 BBB
2 record(s) selected.
Unified Consoleを使用したDb2WHの動作確認
Db2WH on OpenShift をWebブラウザのGUIから操作するUnified Consoleを使用した動作確認を行います。
Unified Consoleの導入手順はこちらの記事（Unified Console を導入してみた）を参照してください。
※以下の手順はUnified Consoleの導入及び、セットアップ（ポート・Proxyの設定）が完了している前提となります。
接続情報の確認
まずUnified Consoleに接続するためのIPアドレスとポート番号の確認をします。
IPアドレスはクラスターに接続可能なサーバーのIPアドレスを使用する必要があり、今回の検証環境ではBastionサーバー（参照：論理構成）のIPアドレスを使用します。
続いてポート番号の確認をします。以下の手順で確認するYYYYYがUnified Consoleに接続するために使用するポート番号です。
-
oc get servicesを実行する - Pod名が
{Unified Console のRelease name}-ibm-unified-console-uiのPodを探す -
PORT(S)部分の、8443:YYYYY/TCP,...となっているYYYYYを確認する
-- 実行例
---- 以下では30047がYYYYYに相当する
[root@k3bastion]# oc get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# 途中省略
db2whuc-ibm-unified-console-ui NodePort 172.30.217.104 <none> 8443:30047/TCP,443:31502/TCP 21d
**Unified Consoleへの接続** 上記手順で確認したIPアドレスとポート番号を、以下の様にウェブブラウザのURL欄に入力（`https://XXX.XXX.XXX.XXX:YYYYY/`）してUnified Consoleに接続します。 
接続するとログイン画面が表示されるので、上記手順で設定したbluadminのパスワードを使用してログインします。
ログインすると以下の様にDb2WHの各種モニタリングやスキーマ・表の確認ができます。
【Db2WHの各種モニタリング】
【スキーマ・表定義の確認】
【表のデータの確認】
ライセンスの適用
Db2 11.5.4では以下の様なCommunity Editionという試用ライセンスが適用された状態で出荷されています。商用利用の場合は有償ライセンスが必要となります。適用するライセンスファイルは、個別契約をお持ちの場合はパスポート・アドバンテージからダウンロード可能です。ライセンスファイルの入手方法についての不明点は購入元の販社様・メーカー（IBM）にご確認ください。
以下ではKnowledge Center に記載の手順に従ってライセンス適用を進めます。
-- Db2WHポッド内のDb2のインストールパスを取得する
[root@k3bastion]# DB2PATH=`oc rsh db2-warehouse1-db2u-0 bin/bash -c "db2ls | cut -d ' ' -f 1 | awk 'NR==4'" | sed $'s/[^[:print:]\t]//g'`
-- 現在のライセンスを確認する
-- 期限：Parmanent、種類：Unwarranted の試用ライセンスが当たっている
[root@k3bastion]# oc rsh db2-warehouse1-db2u-0 sudo bash -c "$DB2PATH/adm/db2licm -l"
# 途中省略
Product name: "dashDB"
License type: "Unwarranted" #←有償ライセンスの場合"CPU Option"等となる
Expiry date: "Permanent"
Product identifier: "dashdb"
Version information: "11.5"
Enforcement policy: "Soft Stop"
有償ライセンスを適用します。
-- 有償ライセンス・ファイルの配置（今回は以下の作業ディレクトリに配置した）
[root@k3bastion]# cd /work/db2-warehouse/
[root@k3bastion]# ls -l dash_c.lic
-rwxr-xr-x. 1 murata murata 931 May 26 2016 dash_c.lic
-- ライセンス・ファイルを置き換える
---- リリース・ネーム、ライセンスファイルのパスを設定する
[root@k3bastion]# RELEASE_NAME="db2-warehouse1"
[root@k3bastion]# LICENSE_FILE="/work/db2-warehouse/dash_c.lic"
---- Db2WHのconfigmapを再作成する
[root@k3bastion]# oc delete configmap "${RELEASE_NAME}-db2u-lic"
[root@k3bastion]# oc create configmap "${RELEASE_NAME}-db2u-lic" --from-file=db2u-lic=${LICENSE_FILE}
-- configmapの変更をDb2WHポッドに反映するために、再起動する
--（deleteすると自動的に再始動される）
[root@k3bastion]# oc delete pods "${RELEASE_NAME}-db2u-0"
-- 変更後のライセンスを確認する
[root@k3bastion]# oc rsh db2-warehouse1-db2u-0 sudo bash -c "$DB2PATH/adm/db2licm -l"
Product name: "dashDB"
License type: "CPU Option"
Expiry date: "Permanent"
Product identifier: "dashdb"
Version information: "11.5"
Enforcement policy: "Soft Stop"
【参考情報】
ConfigMapについて
以上でDb2 Warehouse 11.5.4 on OpenShiftの導入・動作・ライセンス適用は終了です。なお今回は検証のため共有ノードへの導入を行いましたが、有償での利用時には占有ノードへの導入が必要です。その場合は以下[参考情報](#参考情報)や[Knowledge Catalog](https://www.ibm.com/support/knowledgecenter/SSCJDQ/com.ibm.swg.im.dashdb.ucontainer.doc/doc/db2w-dednodes.html)をご確認の上導入してください。
参考情報
占有ノードへのインストール
Db2WHを商用利用する場合は1つ、もしくは複数のノードを占有してデプロイする必要があります。以下では Knowledge Center の手順に従って、 worker1ノードに占有デプロイするための設定手順を紹介します。なお導入にあたっては、以下の設定に合わせてdb2u-installコマンドのオプションの設定も必要です。
占有デプロイのためにノードに対する設定をします。
-- ワーカー・ノード名を取得する
[root@k3bastion]# oc get node
-- 占有するノードに指定したラベル以外のポッドが起動しない設定をする
---- worker1 にラベル `database-db2wh`（Db2WHのデフォルト）を付ける
---- --overwrite オプションはすでにworker1が占有されていたり、別のラベルが付いている場合には必須
[root@k3bastion]# oc adm taint node worker1 icp4data=database-db2wh:NoSchedule --overwrite
-- worker1で起動しているポッドを停止する
[root@k3bastion]# kubectl drain worker1 --ignore-daemonsets
-- 停止したポッドを（ラベルに応じて別ノードに）再度スケジュールする
[root@k3bastion]# kubectl uncordon worker1
-- ノードにラベルを付与する
---- worker1 に database-db2wh ラベルを付ける
[root@k3bastion]# oc label node worker1 icp4data=database-db2wh --overwrite
-- ノードに付いているラベルを確認する
[root@k3bastion]# oc get node --show-labels
--【参考】
-- テイント、ラベルの削除
---- node_name：上記例では worker1
---- key- ：上記例ではicp4data
[root@k3bastion]# oc adm taint nodes node_name key-
[root@k3bastion]# oc label nodes node_name key-
-- 例）
[root@k3bastion]# oc adm taint nodes worker1 icp4data-
[root@k3bastion]# oc label nodes worker1 icp4data-