Db2 11.5.4 on OpenShift をデプロイしてみた - NFS構成 -

## コンテナ版Db2

Db2 V11.5 にはコンテナ版が提供されていて、無償(※)で利用することができます。
　(※) Db2 Community Edition：4 cores,16 GB RAM までのサーバであれば無償

コンテナ版のDb2には、以下の種類があります。

1. Dockerコンテナ版Db2
2. Db2 on OpenShift  (別名 "Db2 Universal Container (Db2U)")
　　<--- OpenShift Container Platform(以下、OCP) にデプロイするためのコンテナ版Db2

    2-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](https://cloud.ibm.com/login) 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](https://github.com/IBM/charts/tree/master/stable/ibm-db2) を確認してください。

ここでは、OCPは導入済みである前提で進めます。
Helm V2 は、他用途では使われておらずDb2 on OpenShift 導入のために別途導入されるケースもあるかと思いますので、今回行ったセットアップ手順をこちらにまとめます。

 - [Db2 11.5.4 on Openshift デプロイのための前提作業 (1) Helm V2セットアップ](https://qiita.com/mi-kana/items/d7ffd260f0cb649d02b8)

### その他、推奨される設定項目
他にも、Db2 on OpenShift 導入前提手順としては下記の項目があります。

 - [Db2 11.5.4 on Openshift デプロイのための前提作業 (2) CRI-O PID 拡張](https://qiita.com/mi-kana/items/50f664a0b982b39c5f8b)
 - ~~[Db2 11.5.4 on Openshift デプロイのための前提作業 (3) container_manage_cgroup 有効化](https://qiita.com/mi-kana/items/341dd23a7af10a0ef7fd)~~
　(※container_manage_cgroup 有効化は Db2 11.5.4 on OpenShiftインストーラ内で実施されるようになり不要となった)

## 導入環境
今回は、以下のような環境に 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  |
| NFS                     |  4.2  |
| Db2 OLTP               |            11.5.4 |

※ [GitHub Readme](https://github.com/IBM/charts/tree/master/stable/ibm-db2) では前提要件としてのOCPバージョンは4.3と記載されますが、
　 利用可能な環境がOCP4.4しか無かったため、OCP 4.4にデプロイしています。
※ [Db2 11.5 Knowldge Center](https://www.ibm.com/support/producthub/db2/docs/content/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/t_db2u_install.html)には、下記に引用するとおり OCP 4.x がサポート対象と記載されます。
> **Installing Db2 on a Red Hat OpenShift cluster**
> Before you run the installation script, ensure that your Red Hat OpenShift cluster meets the following requirements:
> ・OpenShift version 3.11 or greater, up to and including 4.x versions

###構成
今回は、以下のような構成のOCP環境にDb2をデプロイします。

 - Bastion Node x1
 - Master Node x3
 - Worker Node x3

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/78f81c8d-ab3a-95b1-d4e3-170a714ebce0.png)

ストレージには、当該環境では最も準備が容易だったNFSを選択しています。
今回はBastionサーバをNFSサーバとして構築し、Bastionサーバのローカルファイルシステムの1つをNFSボリュームとしてexportする単純な構成としています。
ストレージ構成は今回の導入検証のための簡易テスト環境であり、実際の本番環境での利用にあたっては技術的な構成確認の場をメーカー(IBM)側にとるようにお願いします。


**NFS構成に関する考慮点：**
DB2 データベースオブジェクトまたはバックアップの NFS 経由での保存は、リモートファイルシステムが Network Appliance Filer、IBM iSCSI、または IBM Network Attached Storage に含まれている場合にのみサポートされます。
参考： https://www.ibm.com/support/pages/db2-and-nfs


###作業を行うノード・ユーザについて

この環境では、ocコマンド/kubectlコマンドはKUBECONFIG環境変数を設定したBastionノードのrootユーザでのみ実行可能となるよう構成されているため、ここから先で実行するコマンド操作は、基本的にすべてBastionノード、rootユーザで実行しています。
実行サーバ・実行ユーザについてはご使用の環境に応じて決めてください。

## インストール方法の公式ドキュメント

オンプレミス版のDb2であれば、Db2マニュアル([KnowledgeCenter](https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.welcome.doc/doc/welcome.html))にインストール方法が記載されますが、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マニュアルにも記載されます。

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 としてデプロイされます。
以下の手順で導入をすすめます。

1. Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
2. NFSサーバの構成
3. クラスタの構成
4. IBM Container Registry へのアクセス
5. Persistent Volume 作成
6. Persistent Volume Claim 作成
7. Helm option の指定
8. PATH設定
9. Db2 on OpenShift のインストール
10. インストール完了確認

ここから先は、特に断りが無い限り
各種コマンドは ocコマンド(kubectl)コマンドが実行可能なユーザで実行します。


##Step1. Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
####① ダウンロード
Db2用のインストーラを単体で入手することはできない。(2020/07時点)
IBMが提供する各種製品群のchartを一括ダウンロードし、そのうちDb2インストーラに該当するchartのみを利用する。

下記URLにアクセスして、Chartをダウンロードする。
https://github.com/IBM/charts
　※インストール・イメージ(バイナリ)は含まれないため、全体でも100MB弱程度におさまる

![Download_chart.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/09d5268b-5729-d67e-a0df-fa959539a5ae.png)

ダウンロードした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/*
```

以後のStep3(クラスタ構成)、Step7(helm option指定)、Step8(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. NFSサーバの構成

####① 空のディレクトリを作成する

```
 mkdir -p /work/nfsdir/Db2NFS
```

####② NFSサーバ上で、エクスポートオプションを指定する

Db2 11.5.4 におけるNFS利用のための前提条件は、マニュアルに記載される。
https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/aese-nfs-storage.html

 - Db2 のPersistent Volume として NFS を利用する場合、NFSサーバ側で以下のエクスポートオプションを指定する。
rw,sync,no_root_squash,no_all_squash

 - IPアドレスは環境に応じて書き換える(db2_openshiftworkerN_IP_address の箇所)

```
echo "/nfsmount db2_openshiftworker1_IP_address(rw,sync,no_root_squash,no_all_squash) db2_openshiftworker2_IP_address(rw,sync,no_root_squash,no_all_squash)" > /etc/exports
```

/etc/exportsファイルでのNFSの設定を反映する (exportfs -a または exportfs -r)

```
exportfs -a
```



-----------------
**補足：**

[Knowledge Center](https://www.ibm.com/support/knowledgecenter/ja/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/aese-nfs-storage.html) には、/etc/fstab ファイルを編集するよう指示があるが、設定するよう指示される hard オプションは後で Persistent Volume の属性に設定するため、この手順はスキップする。

抜粋：
> 各 Db2OpenShiftワーカー・ノードで、マウント・オプションを/etc/fstabに追加します。
NFS ソフト・マウントは NFS タイムアウトの超過後に停止し、呼び出し元に正しくエラーを返さない可能性があります。
この問題によって、クラスター・アプリケーションでデータ破損が生じることがあります。これが、hard オプションを使用する理由です。

> 例えば、以下のシェル・スニペットを使用して更新を行うことができます。
cat <<'EOF' > /etc/fstab
hostname_OR_IP_address_of_NAS/NFS_server:NAS/NFS_share_exported  /nfsmount/ nfs
rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,intr,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,nolock 0 0
EOF


-----------------

##Step3. クラスタの構成
####① プロジェクトの作成
db2u-oltp0 という名前のプロジェクトを作成。

```
oc new-project db2u-oltp0
```

####② セキュリティ構成
Db2インストーラを解凍したディレクトリ配下の pak_extensions サブディレクトリのあるパスへ移動し、
下記コマンドを実行して、SecurityContextConstraints(SCC) を定義する。

```
 cd /work/media/ibm-db2/ibm_cloud_pak/pak_extensions
 ./pre-install/clusterAdministration/createSecurityClusterPrereqs.sh
```

 - SecurityContextConstraints (SCC) は Pod のパーミッションを制御するためのオブジェクト。
 - 参考：[OCP 4.4 Documentation[Managing Security Context Constraints]](https://docs.openshift.com/container-platform/4.4/authentication/managing-security-context-constraints.html)

次に、createSecurityNamespacePrereqs.shスクリプトを実行し、Db2 on OpenShift が 今後 db2u-oltp0 プロジェクト内で利用するサービスアカウント、ロール、ロールバインディングなどを定義する。
このコマンドには、引数(ネームスペース名)を指定する必要がある。

```
 ./pre-install/namespaceAdministration/createSecurityNamespacePrereqs.sh db2u-oltp0
```

 - 参考：[OCP 4.4 Documentation[RBAC の使用によるパーミッションの定義および適用]](
https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.4/html/authentication_and_authorization/using-rbac
)


次に、現在のプロジェクトのadminロールをtillerユーザに追加する。

```
 oc policy add-role-to-user admin "system:serviceaccount:${TILLER_NAMESPACE}:tiller"
```

 - 上の oc policy コマンドの前提はTillerの稼働するネームスペースがOS環境変数 TILLER_NAMESPACE に設定されていることと、Helm用のサービスアカウント名がtillerであることを前提としています。環境に応じて編集して実行してください。
 - この設定(oc policy add-role-to-user) が行われていないと、権限不足により db2u-install コマンドが失敗することがあります。
 - 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}"
```


##Step4. IBM Container Registry へのアクセス
Db2 Community Edition container のイメージは、IBM Cloud Container Registry から入手するため、IBM Cloud Registry にアクセスするための準備を行う。

####① APIキーを作成する
IBM Cloudにログインする
https://cloud.ibm.com/login
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/b7820c66-e6bf-c212-8243-bee47b77c8b9.png)

ツールバーから Manage > Access (IAM) を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/7477b34a-4ea3-052d-3609-18209c3f0370.png)

サイドメニューから「API Keys」を選択し「Create an IBM Cloud API Key(IBM Cloud API キーの作成)」を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/f880be9d-2cdd-fd3e-a6e5-3ce8dca0f9fb.png)

任意の名前/説明を入力し「create」を押下
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/ce5d1f5b-0d52-df44-6701-5f3bcf363842.png)

APIキーをコピーするか、ダウンロードして保管する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/bfbba76b-39c4-1a2c-5a2d-e8937321e7f5.png)


####② 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
```


##Step5. Persistent Volume(PV) 作成
yamlファイルを作成する。

```create_nfs_pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00-nfsdb2
  labels:
    type: nfs-00
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - v4.2
    - context="system_u:object_r:container_file_t:s0"
    - hard
  nfs:
    path: /work/nfsdir/Db2NFS
    server: 10.1.1.1
```

PVを作成する。

```
oc create -f create_nfs_pv.yaml
```

##Step6. Persistent Volume Claim(PVC) 作成
yamlファイルを作成する。

```create_nfs_pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc00-nfsdb2
  namespace: db2u-oltp0
spec:
  selector:
    matchLabels:
      type: "nfs-00"
  accessModes:
    - ReadWriteOnce
  storageClassName: slow
  resources:
    requests:
      storage: 10Gi

```

PVCを作成する。

```
oc create -f create_nfs_pvc.yaml
```

##Step7. Helm option 指定(オプション)
HADR環境として構成したい場合やRESTを利用したい場合など、必要に応じて、helm_option ファイルを編集する。
今回は追加オプションを指定したい要件はないため、編集は行わない。
helm_option ファイルはDb2 on OpenShiftインストーラ(db2u-install)と同じロケーションに配置されている。
　　※<Db2U-installer_Extracted_Dir>/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"
```

##Step8. PATH設定
インストーラ(db2u-install コマンド) 内では helmコマンドが実行されるため、インストーラ実行前にパスを通する必要がある。
PATH環境変数に、helmコマンドのパスを設定する。

```
export PATH=$PATH:/work/HelmV2.16.9/linux-amd64
```


##Step9. 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を利用する想定のため、Step6で作成したPVC名を指定


**【インストールコマンド実行/標準出力例】**

```
./db2u-install --db-type db2oltp --db-name TEST0 --namespace db2u-oltp0 --release-name db2u-oltp-0 --existing-pvc pvc00-nfsdb2 --accept-eula
NAME:   db2u-oltp-0
LAST DEPLOYED: Sun Jul 12 21:33:20 2020
NAMESPACE: db2u-oltp0
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                         DATA  AGE
db2u-oltp-0-db2u-config       2     0s
db2u-oltp-0-db2u-hadr-config  1     0s
db2u-oltp-0-db2u-lic          1     0s
db2u-oltp-0-db2u-uc-config    23    0s
db2u-oltp-0-db2u-wv-config    1     0s

==> v1/Deployment
NAME                   READY  UP-TO-DATE  AVAILABLE  AGE
db2u-oltp-0-db2u-ldap   0/1    1           0          0s
db2u-oltp-0-db2u-tools  0/1    1           0          0s

==> v1/Job
NAME                               COMPLETIONS  DURATION  AGE
db2u-oltp-0-db2u-engn-update-job    0/1          0s        0s
db2u-oltp-0-db2u-nodes-cfg-job      0/1          0s        0s
db2u-oltp-0-db2u-restore-morph-job  0/1          0s        0s
db2u-oltp-0-db2u-sqllib-shared-job  0/1          0s        0s

==> v1/Pod(related)
NAME                                     READY  STATUS             RESTARTS  AGE
db2u-oltp-0-db2u-0                        0/1    Init:0/2           0         1s
db2u-oltp-0-db2u-engn-update-job-r6jsr    0/1    Init:0/2           0         1s
db2u-oltp-0-db2u-ldap-67589cbdb9-gkt96    0/1    Init:0/1           0         1s
db2u-oltp-0-db2u-nodes-cfg-job-rz4mp      0/1    Init:0/1           0         1s
db2u-oltp-0-db2u-restore-morph-job-ktscl  0/1    Init:0/1           0         1s
db2u-oltp-0-db2u-sqllib-shared-job-f8zg7  0/1    ContainerCreating  0         1s
db2u-oltp-0-db2u-tools-695f4bf9f6-jpqnk   0/1    ContainerCreating  0         0s
db2u-oltp-0-etcd-0                        0/1    Init:0/1           0         1s

==> v1/Secret
NAME                  TYPE    DATA  AGE
db2u-oltp-0-db2u-ldap  Opaque  1     0s

==> v1/Service
NAME                      TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)                                                                          AGE
db2u-oltp-0-db2u           ClusterIP  172.30.106.110  <none>       50000/TCP,50001/TCP,25000/TCP,25001/TCP,25002/TCP,25003/TCP,25004/TCP,25005/TCP  0s
db2u-oltp-0-db2u-engn-svc  NodePort   172.30.207.241  <none>       50000:32193/TCP,50001:32269/TCP                                                  0s
db2u-oltp-0-db2u-internal  ClusterIP  None            <none>       50000/TCP,9443/TCP                                                               0s
db2u-oltp-0-db2u-ldap      ClusterIP  172.30.78.251   <none>       50389/TCP                                                                        0s
db2u-oltp-0-db2u-rest-svc  NodePort   172.30.31.163   <none>       50050:30404/TCP                                                                  0s
db2u-oltp-0-etcd           ClusterIP  None            <none>       2380/TCP,2379/TCP                                                                0s

==> v1/StatefulSet
NAME             READY  AGE
db2u-oltp-0-db2u  0/1    0s
db2u-oltp-0-etcd  0/3    0s


NOTES:

db2oltp have been installed
```

上のようなログメッセージが出力されれば、インストールコマンドは正常に実行完了している。

このインストールコマンドによって、Db2 の StatefulSet としてのデプロイが開始される。
(中で実行されるのは、helm install コマンドによる、ibm-db2 chartを用いたDb2のデプロイ)

インストールコマンド完了＝Db2のデプロイ完了というわけではないため、
ocコマンドなどによって、Db2のPodが実行中(Running)状態となり、Db2データベースに接続できる状態であるかを確認していく。

##Step10. インストール完了確認

####① 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-oltp-0-db2u-0                         1/1     Running      0          19m    10.129.2.162   worker1   <none>           <none>
db2u-oltp-0-db2u-engn-update-job-lbcrf     0/1     Completed    0          144m   10.129.2.93    worker1   <none>           <none>
db2u-oltp-0-db2u-ldap-67589cbdb9-twm7z     1/1     Running      0          143m   10.129.2.96    worker1   <none>           <none>
db2u-oltp-0-db2u-nodes-cfg-job-8bcmq       0/1     Completed    0          145m   10.129.2.91    worker1   <none>           <none>
db2u-oltp-0-db2u-restore-morph-job-d2xbv   0/1     Completed    0          144m   10.129.2.94    worker1   <none>           <none>
db2u-oltp-0-db2u-sqllib-shared-job-f8zg7   0/1     Completed    0          147m   10.128.2.44    worker2   <none>           <none>
db2u-oltp-0-db2u-tools-695f4bf9f6-76wm9    1/1     Running      0          142m   10.129.2.98    worker1   <none>           <none>
db2u-oltp-0-etcd-0                         1/1     Running      0          144m   10.129.2.95    worker1   <none>           <none>
db2u-oltp-0-etcd-1                         1/1     Running      0          140m   10.129.2.104   worker1   <none>           <none>
db2u-oltp-0-etcd-2                         1/1     Running      0          129m   10.129.2.106   worker1   <none>           <none>

```

「db2u-oltp-0-db2u-restore-morph-job-d2xbv」の状態が「Completed」であり、
Db2エンジン本体のPodである「db2u-oltp-0-db2u-0」の状態が「Running」であることから、導入成功している。

####② 動作確認
Db2 の Pod「db2u-oltp-0-db2u-0」 にログインし、データベースに接続できることを確認する。
Podには以下のコマンドでログインする。

```
 $ oc rsh <RELEASE_NAME>-db2u-0 /bin/bash
```


**【動作確認例】**
ログイン時のユーザは Db2コマンド実行権限を持たないdb2uadm であるため、Podへのログインが成功したらdb2inst1 ユーザに su する。
以下は、DBに接続しテスト用テーブルを作成し、データを挿入することで動作確認を行う例。

```
# oc rsh db2u-oltp-0-db2u-0 /bin/bash
[db2uadm@db2u-oltp-0-db2u-0 /]$ whoami
db2uadm
[db2uadm@db2u-oltp-0-db2u-0 /]$ su - db2inst1
Last login: Mon Jul 13 04:43:27 UTC 2020 on console
[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ which db2
~/sqllib/bin/db2
[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ db2 list db directory

 System Database Directory

 Number of entries in the directory = 1

Database 1 entry:

 Database alias                       = TEST0
 Database name                        = TEST0
 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-oltp-0-db2u-0 - Db2U db2inst1]$ db2 connect to test0

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.4.0
 SQL authorization ID   = DB2INST1
 Local database alias   = TEST0

[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ db2 list tables

Table/View                      Schema          Type  Creation time
------------------------------- --------------- ----- --------------------------

  0 record(s) selected.

[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ db2 "create table t1 (c1 integer, c2 char(32))"
DB20000I  The SQL command completed successfully.
[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ db2 "insert into t1 values(1,'a'),(2,'b')"
DB20000I  The SQL command completed successfully.
[db2inst1@db2u-oltp-0-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"

C1          C2
----------- --------------------------------
          1 a
          2 b

  2 record(s) selected.

[db2inst1@db2u-oltp-0-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 に有償ライセンスを登録](https://qiita.com/mi-kana/items/66839ee61917fa6d5849)

-----------------
**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. ④ で設定したものとなっている。



-------
以上です。