Db2 on OpenShift環境における高可用性構成とは
Db2 on OpenShiftにおける高可用性構成には、OpenShiftが提供する可用性機能と、Db2 on OpenShiftが提供する可用性機能があります。
どちらか一方もしくは組み合わせて構成することも可能です。
それぞれの機能が対応可能な障害ケースは以下のとおりです。
- OpenShiftが提供する可用性機能
- Db2コンテナ障害
- Db2 Pod障害
- Db2 on OpenShiftが提供する可用性機能
- ノード障害/クラスター障害
なお、当記事は、Db2 on openShift 11.5.6（2021/12/01時点）を前提としています。
OpenShiftが提供する可用性機能
Db2コンテナ障害
Db2コンテナに障害が発生すると、コンテナの再起動ポリシーに従って自動的に再起動が行われます。これはOpenShiftのデフォルトの機能であり、無効にすることはできません。
Db2 Pod障害
Db2エンジンはステートフルセットとしてデプロイされるため、Podに障害が発生した場合は、同名のPodが自動的に再起動されます。永続ボリューム（PV）も引き継がれ、障害によって置換された新しいPodと紐付けられます。コンテナ障害と同様、こちらもOpenShiftが提供するデフォルトの可用性の機能になるため、無効にすることはできません。
以上が、OpenShiftが提供する可用性構成の機能となります。
なお、OpenShiftはPod/コンテナ内のプロセス障害については対応していません。そのため、Db2コンテナの外部から、プロセス監視やSQL発行による生死確認、別途監視やモニター、Pod再起動の仕組みが必要となります。
プロセス障害への対応としては Liveness Probeを活用する方法も考えられますが、Db2 on OpenShift 11.5.6 現在ではそういった実装は行われていません。
参考として、Db2 on OpenShift起動後に取得したpsコマンド結果を添付します。
Db2オンプレ版と同様、一般的に監視するプロセスはdb2syscになります。
参考：[DB2 LUW] DB2が稼動しているかどうかを確認する方法は？(IM-10-0AB)
ps -ef
$ 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
$
Db2 on OpenShiftが提供する可用性機能
ノード障害/クラスター障害
Db2 on OpenShiftが提供する可用性機能として、HADR＋Governor＋etcdが提供されています。HADRはデータ同期（複製）、Governor及びetcdは自動引き継ぎを担います。この可用性機能では、ノード障害及びクラスター障害に対応することが可能です。HADRにより、データは常時複製され、また複製先のDb2は常に起動している状態のため、迅速な引き継ぎが可能となります。
HADR＋Governor＋etcd構成では、複製するスタンバイを3つまで構成することが可能です。ただし、Governerによる自動引き継ぎは1次スタンバイのみがサポートされます（オンプレ版と同じ）。
参考：Db2 HADR on OpenShift かんたんデプロイ
HADRは最もサービスレベルが高い可用性構成となりますが、複製先の環境が別途必要となります。それほどの可用性が求められない場合は、バックアップ・リストアで代替が可能な場合があります。また、ディスク障害についても検討が必要になるケースもあります。要件に応じて適切な可用性構成を選択しましょう。