Db2 on OpenShift 高可用性構成のパターンとその考慮点

Db2 on OpenShift環境における高可用性構成とは
-

Db2 on OpenShiftにおける高可用性構成には、OpenShiftが提供する可用性機能と、Db2 on OpenShiftが提供する可用性機能があります。
どちらか一方もしくは組み合わせて構成することも可能です。
それぞれの機能が対応可能な障害ケースは以下のとおりです。

<dl>
  <dt>OpenShiftが提供する可用性機能</dt>
  <dd>Db2コンテナ障害</dd>
  <dd>Db2 Pod障害</dd>
  <dt>Db2 on OpenShiftが提供する可用性機能</dt>
  <dd>ノード障害/クラスター障害</dd>
</dl>

なお、当記事は、Db2 on openShift 11.5.6（2021/12/01時点）を前提としています。

OpenShiftが提供する可用性機能
-
<strong>Db2コンテナ障害</strong>

Db2コンテナに障害が発生すると、コンテナの再起動ポリシーに従って自動的に再起動が行われます。これはOpenShiftのデフォルトの機能であり、無効にすることはできません。
![Db2Image2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482216/2098386d-5aa3-e3b9-79e9-3c2ac025697c.jpeg)

<strong>Db2 Pod障害</strong>

Db2エンジンはステートフルセットとしてデプロイされるため、Podに障害が発生した場合は、同名のPodが自動的に再起動されます。永続ボリューム（PV）も引き継がれ、障害によって置換された新しいPodと紐付けられます。コンテナ障害と同様、こちらもOpenShiftが提供するデフォルトの可用性の機能になるため、無効にすることはできません。
![Db2Image3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482216/2d2023f9-bd38-d4ce-5a72-cc00bd8d0724.jpeg)

以上が、OpenShiftが提供する可用性構成の機能となります。
なお、OpenShiftはPod/コンテナ内のプロセス障害については対応していません。そのため、Db2コンテナの外部から、プロセス監視やSQL発行による生死確認、別途監視やモニター、Pod再起動の仕組みが必要となります。
プロセス障害への対応としては Liveness Probeを活用する方法も考えられますが、Db2 on OpenShift 11.5.6 現在ではそういった実装は行われていません。
参考として、Db2 on OpenShift起動後に取得したpsコマンド結果を添付します。
Db2オンプレ版と同様、一般的に監視するプロセスはdb2syscになります。
[link-0]:https://www.ibm.com/support/pages/node/646647
参考：[[DB2 LUW] DB2が稼動しているかどうかを確認する方法は？(IM-10-0AB)][link-0] 

<details><summary>ps -ef</summary><div>
$ ps -ef | grep -i db2
db2uadm        1       0  0 10:34 ?        00:00:00 /bin/sh -x /etc/runit/entrypoint.sh
db2uadm        8       1  0 10:34 ?        00:00:00 runsvdir -P /etc/service log: （略）
db2uadm        9       8  0 10:34 ?        00:00:00 runsv db2u
db2uadm       10       8  0 10:34 ?        00:00:00 runsv db2uapi
db2uadm       11       8  0 10:34 ?        00:00:00 runsv sshd
db2uadm       12       8  0 10:34 ?        00:00:00 runsv wolverine
db2uadm       13       9  0 10:34 ?        00:00:00 sleep infinity
db2uadm       15      12  0 10:34 ?        00:00:00 svlogd -tt ./main
db2uadm       16      11  0 10:34 ?        00:00:00 svlogd -tt ./main
db2uadm       17      11  0 10:34 ?        00:00:00 /bin/sh -e ./run
db2uadm      873       8  0 10:35 ?        00:00:00 runsv sssd
db2uadm      933     873  0 10:35 ?        00:00:00 /bin/sh -e ./run
db2uadm     1806      10  2 10:35 ?        00:05:00 db2u-apiserver --type control
root       10202       1  0 10:42 ?        00:00:00 db2wdog 0 [db2inst1]
db2inst1   10204   10202  1 10:42 ?        00:02:01 db2sysc 0
root       10210   10202  0 10:42 ?        00:00:00 db2ckpwd 0
root       10211   10202  0 10:42 ?        00:00:00 db2ckpwd 0
root       10212   10202  0 10:42 ?        00:00:00 db2ckpwd 0
db2inst1   10214   10202  0 10:42 ?        00:00:00 db2vend (PD Vendor Process - 1) 0
db2inst1   10224   10202  0 10:42 ?        00:00:02 db2acd 0 ,0,0,0,1,0,0,00000000,0,0,0000000000000000,0000000000000000,00000000,00000000,00000000,00000000,00000000,00000000,0000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000191e0c000,0000000000000000,0000000000000000,1,0,0,,,,,a89e68,14,1e014,2,0,1,0000000000041fc0,0x240000000,0x240000000,1600000,5,2,29
db2uadm    38286       0  0 11:02 pts/0    00:00:00 /bin/bash
root       38309   38286  0 11:02 pts/0    00:00:00 su - db2inst1
db2inst1   38310   38309  0 11:02 pts/0    00:00:00 -ksh
db2inst1   38754       1  0 11:02 pts/0    00:00:00 /mnt/blumeta0/home/db2inst1/sqllib/bin/db2bp 38310A500 5 A
db2uadm   271502       0  0 13:51 pts/1    00:00:00 /bin/bash
root      271754  271502  0 13:51 pts/1    00:00:00 su - db2inst1
db2inst1  271755  271754  0 13:51 pts/1    00:00:00 -ksh
db2inst1  274491  271755  0 13:53 pts/1    00:00:00 ps -ef
db2inst1  274492  271755  0 13:53 pts/1    00:00:00 grep --color=auto -i db2
$
</div></details>

Db2 on OpenShiftが提供する可用性機能
-

<strong>ノード障害/クラスター障害</strong>

Db2 on OpenShiftが提供する可用性機能として、HADR＋Governor＋etcdが提供されています。HADRはデータ同期（複製）、Governor及びetcdは自動引き継ぎを担います。この可用性機能では、ノード障害及びクラスター障害に対応することが可能です。HADRにより、データは常時複製され、また複製先のDb2は常に起動している状態のため、迅速な引き継ぎが可能となります。
HADR＋Governor＋etcd構成では、複製するスタンバイを3つまで構成することが可能です。ただし、Governerによる自動引き継ぎは1次スタンバイのみがサポートされます（オンプレ版と同じ）。
![Db2Image4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/482216/bf623dae-59b6-b91f-67d6-f6476358e50c.jpeg)
[link-3]:https://www.ibm.com/docs/ja/db2/11.5?topic=db2-high-availability-disaster-recovery-hadr
参考：[Db2 高可用性災害時リカバリー (HADR)][link-3]
[link-1]:https://qiita.com/mi-kana/items/7fb2fecc02067bc8386b
参考：[Db2 HADR on OpenShift かんたんデプロイ][link-1]

HADRは最もサービスレベルが高い可用性構成となりますが、複製先の環境が別途必要となります。それほどの可用性が求められない場合は、バックアップ・リストアで代替が可能な場合があります。また、ディスク障害についても検討が必要になるケースもあります。要件に応じて適切な可用性構成を選択しましょう。

[link-2]:https://qiita.com/mi-kana/items/92f4129405dc45052189
参考：[OpenShift環境でのDb2データベースのオンラインバックアップとリストア][link-2]