Db2 11.5.5 on OpenShift：GUIベースのデプロイ手順

Db2 11.5.5 on OpenShift は、Operator対応されたことによって、OCP WebコンソールからGUIベースでインストールすることができるようになりました。
OCP WebコンソールからDb2をデプロイするための手順を試してみたので、手順・ポイントなどメモとしてまとめておこうと思います。

 * 前提となるDb2 Operator導入まで実施完了していることを前提とします
 * Db2 Operator導入などの、前提となる手順はこちらに書いています<br>
 　　→ [Db2 11.5.5 on OpenShift デプロイ手順](https://qiita.com/mi-kana/items/6266fcdcdc3b71d8a0fb)
 * すべての作業をGUIだけで行うことができるわけではなく、一部の手順はコマンドラインから実行します

## 導入環境
今回は、以下のような環境に Db2 11.5.5 on OpenShift をデプロイしました。

| 項目                    | バージョン         |
|:------------------------|:------------------|
| OS(bastion)             |          RHEL 7.7 |
| OS(worker)       |          RHEL 7.7 |
| OCP(Client) ※            | 4.5.0-202007240519.p0-b66f2d3 |
| OCP(Server) ※           | 4.5.7             |
| Kubernetes              |  v1.18.3+2cf11e2  |
| NFS                     |  4.2  |
| Db2 OLTP               |            11.5.5 |


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

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

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/f2bb07c6-69fb-5d71-e3b3-f6d4d37f08c7.png)


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

### 作業を行うノード / ユーザ

ここから先で実行するコマンドはすべてBastionノードから実行しています。
また、ユーザは以下の用途で使い分けています。

| ユーザ | 用途/補足 |
|:------------|:----------------|
|rootユーザ   |NFSサーバのセットアップ用   |
|OCPユーザ   |ocコマンド実行<br>(cluster-admin権限付与)   |



コマンド実行ノード・ユーザについてはご使用の環境に応じて決めてください。
また、ocコマンド実行前には、oc login が必要となります。


## 導入の流れ

1. ストレージ構成
2. Db2uCluster(≒シングル構成Db2)導入
3. 動作確認

(補足)導入の全体としての流れは以下の通りで、ここから先の手順はグレーの作業(新規プロジェクト作成、Db2 Operator導入)までは完了していることを前提とします
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/455cc5e7-1931-46cc-017c-0b754706e2b6.png)

##Step1. ストレージ構成
Db2uCluster(Db2本体)導入時は、メタデータ/ユーザデータを配置するためのストレージとして、ストレージクラス、もしくは作成済のPVを指定します。
ここでは、作成済PVを指定してDb2uClusterを導入する手順を想定しています。

### Step1-1. NFSサーバの構成
今回は検証環境であるため、セットアップの容易なNFSをストレージとして利用します。
(※本番稼働環境であれば、性能/可用性/バックアップ取得要件等を考慮した上でストレージ構成を検討することが望ましい)
NFSサーバ(＝bastion) へログインし、root ユーザ にて以下の手順を実行します。

####① 空のディレクトリを作成
メタデータ、ユーザデータ用に2つのディレクトリを作成します

```
# mkdir -p /work/nfsdir/Db2NFS_Data2
# mkdir -p /work/nfsdir/Db2NFS_Meta2
```

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

Db2U 11.5.5 におけるNFS利用のための前提条件は、Db2製品マニュアルに記載されます。
[Db2 11.5 KnowledgeCenter[NFS storage requirements for Db2]
](https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/aese-nfs-storage.html)

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

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

```
# echo "/work/nfsdir/Db2NFS_Data2 10.1.1.1/27(rw,sync,no_wdelay,no_root_squash,insecure)" >> /etc/exports
# echo "/work/nfsdir/Db2NFS_Meta2 10.1.1.1/27(rw,sync,no_wdelay,no_root_squash,insecure)" >> /etc/exports
```

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

```
# exportfs -a
```

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

[Knowledge Center](https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.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


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

### Step1-2. Persistent Volume(PV) 作成
OCP Webコンソールから、メタデータ用とユーザーデータ用の２つのPVを作成します。
左のメニューから [Storage] -> [Persistent Volumes]を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/73219d62-fa35-eac4-231b-eb16bc6f2d09.png)

右上の [Create Persistent Volume] ボタンを押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/df9f1ea9-e259-2609-451b-a6385d9b1a62.png)

Yaml編集画面が開くので、環境に応じた定義内容を記載し、[Create]ボタンを押下しPVを作成します
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/3158ec79-1743-5b45-bd84-f1abb971761a.png)


以下①、②に、今回使用したNFSのPVの定義サンプルを添付します。

####①メタデータ用PVのYamlサンプル

```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-db2meta2
  labels:
    type: nfs-meta2
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - v4.2
    - context="system_u:object_r:container_file_t:s0"
    - hard
  nfs:
    path: /work/nfsdir/Db2NFS_Meta2
    server: 10.1.1.1
```


####②ユーザデータ用PVのYamlサンプル

```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-db2data2
  labels:
    type: nfs-data2
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_Data2
    server: 10.1.1.1

```



## Step2. Db2uCluster デプロイ(Db2 on OpenShiftの導入)


OCP Webコンソールにログインし、[Operators] -> [Installed Operators] の画面を開き、「IBM Db2」を選択します。
※Db2 Operatorが表示されない場合は、「all project」もしくは、作業対象のプロジェクト(ネームスペース)が選択されていることを確認してください
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/8ef27a2d-6a58-8d81-52e7-c840e17c2be9.png)

「Provided APIs」の一覧に並ぶアイコン「Db2u Cluster」の下にある「Create Instance」ボタンを押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/cd5983ef-7bf1-e441-7733-b664533c2833.png)

Db2インスタンスのデプロイ画面が表示され、各種設定項目と[Create]ボタンが表示されます。

 * ライセンス承諾設定等が必要となります。設定の編集を行った後に[Create]します
 *  OCP Webコンソールでは、設定項目の一部がGUI入力画面にて設定できるようになっています
 * GUIはすべての設定項目を網羅していないため、GUIベースのデプロイを行う際、設定項目が無い項目についてはYamlファイルビューで直接Yamlファイルの編集を行います

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/f0c8a46b-cee5-299f-c429-75ecf604d718.png)


下記項目を順次編集していきます。

####①名称、ライセンス

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/288175ed-7ef8-6d86-ff22-d265f5b96f34.png)



####②Image Pull Secret指定

Acount > Image Pull Secrets 下の「Add imagePullSecret」を押下し、[ibm-registry]を指定します
(ibm-registryは既に作成済の前提。作成手順はこちらに記載 -> [Link]())

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/9863c946-ab7b-07c6-a581-227323394d95.png)

(imagePullSecret入力後の画面例)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/e69546b0-264b-8d3b-0f15-f0da5be56e65.png)


####③インスタンスのパスワード情報

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/3566b9cd-2264-bc7b-ab9d-e683bddb66fa.png)



####④ストレージ構成 (一部はYaml編集が必要)
GUI画面のデフォルトでは1つのストレージにメタデータ/ユーザデータを共存させる設定となっています。
また、無指定の状態ではストレージサイズは100Giとなります。
その他、ユーザ要件/環境に沿って、GUIで設定できる項目はGUIで、GUIでは指定できない条件についてはYamlビューにて編集していきます。

 * メタデータ、ユーザデータそれぞれのPVを指定<br>(Step1.で作成しておいたPVに指定したラベル値をmatchExpressionで指定)
 * ユーザデータについてデフォルト100GiB確保される定義を、テスト環境では10GiBへ変更
 * アクセスモードをマニュアルの推奨(※)に合わせて変更

  (※)[Db2 11.5 KnowledgeCenter[Configuring database storage for Db2]](https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/database-storage-aese.html) より引用
  >When provisioning the database, for user data (the main database data), select ReadWriteOnce (RWO) access mode for your storage.

以下はメタデータ用ストレージの定義画面。
1つめのストレージについて、アクセスモードはデフォルトでReadWriteManyとなっているため変更不要です。
Step1.で作成済PVに定義したラベル(nfs-meta2)を指定するため、Selector > MatchExpressions の下の「Add matchExpression]を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/b0fc7208-473b-25b4-06a2-5f75fb978398.png)

Step1.でPVに定義したラベルは、キー(type)とバリュー(nfs-meta2)のペアで構成されます。
Db2uClusterでのストレージ定義にmatchExpressionsでセレクター要件(→PVのラベルのキー値とバリュー値)を記述することによって、作成済のPVをDb2uClusterのPodに使わせることができます。
Valueは、「Add value]ボタン押下により入力可能となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/436f7b89-d351-bb18-284c-c57789790eff.png)

(key - operator - value 入力イメージ)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/bdd7fd98-398c-6bd1-7c09-00f1dbb8f0ee.png)


つづいて、[Add Storage] を押下し、ユーザデータ用ストレージの定義を追加します。

1つ目のメタデータ用ストレージと同様に、name, selector(match expressions)値を入力します。
また、1つ目のストレージと異なり、Access Mode / type の値が空白値となるため、明示的に指定します。

 * Access Mode : ReadWriteOnce
 * type : create

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/050f269e-66e2-9c05-0885-b92617860e87.png)

ここまで編集できたら、Yaml Viewに切り替えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/62066c5d-5e12-1fb7-1cbe-467bf93e7807.png)

デフォルトでは、メタデータ用ストレージサイズは下記抜粋のように100GiBが指定されるため、環境に応じて変更します。
(編集前：100GiB)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/a5af6073-45dc-b1b9-ee57-bbac3fb5412c.png)
(編集後：10GiB)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/251eff6d-68e9-bb49-601a-fd0edb67d670.png)

ユーザデータ用領域も同様に編集します。
　＊ユーザデータ用領域については、[resources]の定義文自体が無いため、meta用の定義をコピーする。

(メタデータ、ユーザデータ用のストレージ定義)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/ffca5f91-d87b-4071-27e7-757ae5a892b4.png)

####⑤podConfig (オプション)(要Yaml編集)
想定リソースについて記述できるpodConfig定義についても、GUI画面には登場しないため、
変更したい場合はYamlビューで記述します。
記述する位置はユーザが意識する必要はなく、Yaml末尾に記述しておくとビュー切替時などに自動的に配置変更されます。

podConfig定義(デフォルト内容)：

```yaml

  podConfig:
    db2u:
      resource:
        db2u:
          requests:
            cpu: 2
            memory: 4Gi
          limits:
            cpu: 2
            memory: 4Gi
```

podConfig定義を手動で追記すると、Formビューにも項目として登場し、GUIベースで編集できるようになります。


####⑥ インストール

[Create]ボタンを押下し、Db2uCluster導入を行います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/e007df2b-93a6-7d43-f431-b10251fcc8ad.png)


[Create]押下後の応答は即時に戻り、作成済Db2uClusterの一覧が表示され、「Status」列で状況がリアルタイムに更新されます。
Db2uClusterデプロイは裏で進行していて、環境によりますが、完了までには数分～十数分程度かかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/4e9c5ce4-e28b-0c59-aad5-c807df208370.png)

####⑦ Db2 on OpenShift デプロイ完了確認

デプロイが完了すると、Statusが「Ready」に変更されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/b6bebf7d-b388-7bd0-63c5-9428518a84fc.png)



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

```
 $ oc rsh c-db2u-nfs1-db2u-0 /bin/bash
```


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

```
$ oc rsh c-db2ucluster-2-db2u-0 /bin/bash
[db2uadm@c-db2ucluster-2-db2u-0 /]$ whoami
db2uadm
[db2uadm@c-db2ucluster-2-db2u-0 /]$ su - db2inst1
Last login: Tue Dec 29 10:43:15 UTC 2020 on pts/4
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ which db2
~/sqllib/bin/db2
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ 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            = c-db2u-cluster-1-db2u-engn-svc
 Alternate server port number         = 50000

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 connect to bludb

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.5.0
 SQL authorization ID   = DB2INST1
 Local database alias   = BLUDB

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 list tables

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

  0 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "create table t1 (c1 integer,c2 char(8))"
DB20000I  The SQL command completed successfully.
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "insert into t1 values(3,'c'),(4,'d')"
DB20000I  The SQL command completed successfully.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 "select * from t1"

C1          C2
----------- --------
          3 c
          4 d

  2 record(s) selected.

[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ db2 terminate
DB20000I  The TERMINATE command completed successfully.
[db2inst1@c-db2ucluster-2-db2u-0 - Db2U db2inst1]$ exit

db2 terminate
DB20000I  The TERMINATE command completed successfully.

```

 ---> 導入したDb2は問題なく稼働していることが確認できました。

##Step4. ライセンスの登録状況確認
Db2 V11.5では、ライセンスを適用しなくても Community Editionという無償版ライセンスが適用された状態となっている。旧バージョンのDb2試用版のように90日経過したらDb2が起動しなくなるということはありません。
この点はDb2 on OpenShiftも共通です。

導入したDb2のライセンス確認/更新を行うには、下記マニュアルに記載コマンドを実行します。

[Db2 11.5 KnowledgeCenter[Upgrading your Db2 Community Edition license certificate key]](
https://www.ibm.com/support/knowledgecenter/SSEPGG_11.5.0/com.ibm.db2.luw.db2u_openshift.doc/doc/t_db2u_upgrd_lic_v11-5-5.html)




## 接続情報
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}'
```

## 関連記事

◆Db2 11.5.5 on OpenShift デプロイ手順
https://qiita.com/mi-kana/items/6266fcdcdc3b71d8a0fb
◆OpenShift環境へのDb2 Operator導入手順
https://qiita.com/mi-kana/items/c3fb640d671caf624eb8
◆Db2 HADR on OpenShift かんたんデプロイ
https://qiita.com/mi-kana/items/7fb2fecc02067bc8386b

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