コンテナ版Db2
Db2 V11.5 にはコンテナ版が提供されていて、無償(※)で利用することができます。
(※) Db2 Community Edition：4 cores,16 GB RAM までのサーバであれば無償
コンテナ版のDb2には、以下の種類があります。
-
Dockerコンテナ版Db2
-
Db2 on OpenShift (別名 "Db2 Universal Container (Db2U)")
<--- OpenShift Container Platform(以下、OCP) にデプロイするためのコンテナ版Db22-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 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 を確認してください。
ここでは、OCPは導入済みである前提で進めます。
Helm V2 は、他用途では使われておらずDb2 on OpenShift 導入のために別途導入されるケースもあるかと思いますので、今回行ったセットアップ手順をこちらにまとめます。
その他、推奨される設定項目
他にも、Db2 on OpenShift 導入前提手順としては下記の項目があります。
- Db2 11.5.4 on Openshift デプロイのための前提作業 (2) CRI-O PID 拡張
-
Db2 11.5.4 on Openshift デプロイのための前提作業 (3) container_manage_cgroup 有効化
(※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 では前提要件としてのOCPバージョンは4.3と記載されますが、
利用可能な環境がOCP4.4しか無かったため、OCP 4.4にデプロイしています。
※ Db2 11.5 Knowldge Centerには、下記に引用するとおり 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
ストレージには、当該環境では最も準備が容易だった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)にインストール方法が記載されますが、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 としてデプロイされます。
以下の手順で導入をすすめます。
- Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
- NFSサーバの構成
- クラスタの構成
- IBM Container Registry へのアクセス
- Persistent Volume 作成
- Persistent Volume Claim 作成
- Helm option の指定
- PATH設定
- Db2 on OpenShift のインストール
- インストール完了確認
ここから先は、特に断りが無い限り
各種コマンドは ocコマンド(kubectl)コマンドが実行可能なユーザで実行します。
##Step1. Db2 on OpenShift インストーラ(Helm Chart)のダウンロード
####① ダウンロード
Db2用のインストーラを単体で入手することはできない。(2020/07時点)
IBMが提供する各種製品群のchartを一括ダウンロードし、そのうちDb2インストーラに該当するchartのみを利用する。
下記URLにアクセスして、Chartをダウンロードする。
https://github.com/IBM/charts
※インストール・イメージ(バイナリ)は含まれないため、全体でも100MB弱程度におさまる
ダウンロードした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 には、/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]
次に、createSecurityNamespacePrereqs.shスクリプトを実行し、Db2 on OpenShift が 今後 db2u-oltp0 プロジェクト内で利用するサービスアカウント、ロール、ロールバインディングなどを定義する。
このコマンドには、引数(ネームスペース名)を指定する必要がある。
./pre-install/namespaceAdministration/createSecurityNamespacePrereqs.sh db2u-oltp0
次に、現在のプロジェクトの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
ツールバーから Manage > Access (IAM) を選択
サイドメニューから「API Keys」を選択し「Create an IBM Cloud API Key(IBM Cloud API キーの作成)」を選択
任意の名前/説明を入力し「create」を押下
APIキーをコピーするか、ダウンロードして保管する
####② 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ファイルを作成する。
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ファイルを作成する。
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)と同じロケーションに配置されている。
※/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 に有償ライセンスを登録
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. ④ で設定したものとなっている。
以上です。