Red Hat OpenShift on IBM Cloud VPC で Secondary Disk付きのワーカー・ノードを使う

# はじめに
Red Hat OpenShift on IBM Cloud（以下、ROKS）VPCでCP4D版Watson Discoveryを稼働させていたところ、一部のワーカー・ノードで`Disk Pressure`が発生しました。

Disk Pressureは以下のマニュアルページに記載があるとおり、CP4Dサービス（今回はWatson Discovery）のpodが大きなイメージを持っていること、またローカル・ディスクを消費することにより、100GBのローカル・ストレージを使い果たしてしまうことが原因で発生します。
[Worker nodes show status of disk pressure](https://www.ibm.com/docs/ja/cloud-paks/cp-data/4.6.x?topic=platform-worker-nodes-show-status-disk-pressure)

従来は、ワーカー・ノードにより大きいローカル・ストレージを割り当てることができなかったため、マニュアルページの「問題の解決」にあるような方法で対応する必要がありました。

2023年1Q、ROKS VPCについて、`Secondary Disk付きのワーカー・ノード`の提供が開始されたことにより、より大きなローカル・ストレージを割り当てることが可能になり、課題を解決できるようになりました。今回、既存クラスターのワーカー・ノードをSecondary Disk付きのワーカー・ノードにリプレースすることにより、Disk Pressureを解決した手順をご紹介します。

注）画面イメージおよび手順は2023年2月現在のものです。

# 手順概要
1. 新規ワーカー・プールの作成
2. ワークロードの移動
3. 既存ワーカー・プールの削除

# リプレース前の状態
ワーカー・ノード：
![original_workernode.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/cc903ece-0266-368c-c05e-392a7c7d13b2.png)
ワーカー・プール：
２つのワーカー・プール（defaultとodf）があります。
今回リプレース対象とするのは、CP4D podを稼働させるワーカー・ノードのためのワーカー・プール "default" です。
![original_workerpool.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/0c011231-ea7d-78d8-d6fd-8c15a36e2c8c.png)

# 手順
## 1. 新規ワーカー・プールの作成
Secondary Disk付きのフレーバーで、新規ワーカー・プールを作成します。

1. ワーカー・プール画面から「追加」をクリックします。
2. 選択予定のフレーバーの`２次ストレージ`で「編集」をクリックします。
![add_workerpool1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/8a3c4cb6-b833-56b9-e6e1-af2dbc83fd5c.png)

3. ２次ストレージを選択し、「適用」をクリックします。
![add_workerpool2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/90f746fd-5a98-ee70-3dbf-67fab7a0d80f.png)

4. 適切なフレーバーが選択されていることを確認し、「ワーカー・プール・フレーバーの保存」をクリックします。
![add_workerpool3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/ca010675-53f8-1bc9-277c-df53090cd00d.png)

5. 他のオプションも適切なものが選択されていることを確認し、「作成」をクリックします。
![add_workerpool4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/3a00bbb9-63b4-06be-fbd6-8d4fe6db731f.png)

6. ２次ストレージ付きのフレーバーで新規ワーカー・プール "myworkerpool" が作成されました。
![add_workerpool5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/35611097-8897-9bd8-baae-4fe52ee4c86b.png)

7. 新規ワーカー・プール "myworkerpool" のワーカー・ノードがプロビジョンされます。
![add_workerpool6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/eafb2d40-93e9-30ce-1240-221316ff3bd0.png)

8. すべての新規ワーカー・ノードの状況が`通常`になるまで待ちます。
![add_workerpool7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/8ff16657-585a-d89c-7915-5099f27f8474.png)

OpenShift Web コンソールから、コンピュート・ノードに新規ワーカー・ノードが追加されたことを確認できます。ファイルシステムのサイズ（ファイルシステム列の分母）が、既存ノードに比べ、２次ストレージとして追加した900GiB分大きいことがわかります。
![compute_nodes.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/196d7da1-e52e-6bd3-4d12-fbbc20d059ab.png)


## 2. ワークロードの移動
既存のワーカー・プールのワーカー・ノード上からワークロードを退避させ、新規ワーカー・ノード上で稼働させます。

お使いのワークロードに応じて適切な方法で実施します。
今回は、既存ノードのスケジュールを無効化した状態で、CP4D関連のpodを再起動することで新規ワーカー・ノードに移動しました。
![compute_nodes2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/4cbee548-f110-1d00-c0b4-7683fc1ce527.png)

## 3. 既存ワーカー・プールの削除
既存ワーカー・ノードからのワークロードの退避が完了していること（今回の場合、CP4D関連のpodが既存ワーカー・ノードで１つも稼働していないこと）を確認後、既存ワーカー・プールを削除します。
![delete_workerpool.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2164968/660c3885-2781-0c35-bef9-c87554f625e7.png)