ベアメタルUPIのOpenShift 4.11に、OpenShift Data Foudation (ODF)をインストールする

# 概要

ベアメタルUPIの方法で導入したOpenShift(以下OCP)クラスターに、OpenShift Data Foudation (以下ODF) 4.11を導入した際のメモを記載します。

# 参考リンク

**前提確認**
- [ODF 4.11 Docs / デプロイメントのプランニング / 3. 内部ストレージサービス](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#internal-storage-services_rhodf)

- [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.1. プラットフォーム要件 / 7.1.2. ベアメタル](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#_bare_metal)
- [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.3. リソース要件](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#resource-requirements_rhodf)
- [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.5. ストレージデバイスの要件 / 7.5.2. ローカルストレージデバイス](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#_local_storage_devices)

**Infra node**
- [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.4. Pod の配置ルール](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#pod-placement-rules_rhodf)
- [ODF 4.11 Docs / 7. Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 / 7.1. インフラストラクチャーノードの仕組み](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_and_allocating_storage_resources/index#_anatomy_of_an_infrastructure_node)
- [ODF 4.11 Docs / 7. Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 / 7.3. インフラストラクチャーノードの手動作成](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_and_allocating_storage_resources/index#_manual_creation_of_infrastructure_nodes)
- [KB / OpenShift 4 のインフラストラクチャーノード](https://access.redhat.com/ja/solutions/6377151)

**デプロイ方法**
- [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 1. OpenShift Data Foundation のデプロイの準備](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#_preparing_to_deploy_openshift_data_foundation)
- [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#deploy-using-local-storage-devices-bm)

# 検証環境

**OCP構成**

この記事でのOCPクラスタの前提の構成は、以下のリンク先でインストールしたOCP 4.11の構成となります。
[Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール](https://qiita.com/t_sweetfish/items/81268b29a3a7ad2f3f09)

- OCP 4.10をベアメタルのUPIでインストールしています。
- ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。
- その後、OCP 4.10からOCP 4.11にアップデートした環境を使用します。(fast-4.11でOCP4.11.4にアップデートし、stabel-4.11にしてOCP 4.11.16にアップデート)

(作業前の構成)  
(ODF専用のInfra nodeを作成前)
```bash
[root@bastion-01 ~]# oc version
Client Version: 4.11.16
Kustomize Version: v4.5.4
Server Version: 4.11.16
Kubernetes Version: v1.24.6+5157800
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      3              3                   3                     0                      145d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      145d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      2              2                   2                     0                      145d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node
NAME        STATUS   ROLES    AGE    VERSION
infra-01    Ready    infra    146d   v1.24.6+5157800
infra-02    Ready    infra    146d   v1.24.6+5157800
infra-03    Ready    infra    146d   v1.24.6+5157800
master-01   Ready    master   146d   v1.24.6+5157800
master-02   Ready    master   146d   v1.24.6+5157800
master-03   Ready    master   146d   v1.24.6+5157800
worker-01   Ready    worker   146d   v1.24.6+5157800
worker-02   Ready    worker   146d   v1.24.6+5157800
[root@bastion-01 ~]#
```

**Infra node**
Infra nodeは以下の手順で作成しています。
[Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755)

今回の手順の中で、以下の設定をします。

- 今回は、運用コンポーネント用のInfra nodeとは別に、ODF専用のInfra nodeを追加で作成する方針とします。

- ODF用のノードにはODF関連のPodが稼働するように`cluster.ocs.openshift.io/openshift-storage=""`のラベルを付与します。
- ODF用のノードもInfra nodeにするため、`node-role.kubernetes.io/infra: ""`のラベルを付与します。
- (今回はInfra node用のMCPを作成しているため、Worker node用の`node-role.kubernetes.io/worker: ""`のラベルは削除します。)

- ODF以外のInfra nodeで稼働する運用コンポーネント(ルーター、OCP内部レジストリ、モニタリング、ロギング)が、ODF専用のInfra nodeに移動しないように、ODF専用のInfra nodeにTaintの設定をします。
- (Storage node用のTaintの設定をする場合は、ClusterLoggingリソースのcollection(fluentd)など、ODF専用ノードでも稼働させる必要があるDaemonsetはtolerationsの設定が必要になります。)

**Operator**
ベアメタルのOCP環境でODFを導入する際には、Local Storage Operatorのインストールが必要です。
[ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.1. ローカルストレージ Operator のインストール](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#installing-local-storage-operator_local-bare-metal)

もしLocal Storage Operatorを導入していない場合は、こちらを参照の上、Operatorを導入しておきます。
(ここで、Local Storage Operatorが導入していなくても、ODFクラスタ作成手順の中で導入することもできます。)

今回の検証環境は、一旦ODFを使用せず、Local Storage OperatorのLocalVolumeリソースでモニタリング、ロギング用のPVを作成していたので、Local Storage Operatorは導入済みでした。

(OCP 4.11では`4.11`ではなく`stable`というチャネルしか無くなっていたので、バージョンが明示的に示されたチャネルではなく`stable`チャネルで`4.11.x`のCSVバージョンまで上げています。)

| Operator      | Channel | 更新承認ストラテジー | CSV                                        |
|:--------------|:--------|:-------------|:-------------------------------------------|
| Local Storage | stable  | 手動           | local-storage-operator.4.11.0-202211072116 |

以下の、OpenShift Data Foudation Operatorは、後ほど導入します。
| Operator                 | Channel     | 更新承認ストラテジー |
|:-------------------------|:------------|:-------------|
| OpenShift Data Foudation | stable-4.11 | 手動           |


# 手順の流れ

ベアメタルUPIのOCPに、ODFを導入してODFクラスタを作成する手順の流れは以下になります。

**前提の確認**

**ノードの作成**
- (1) 仮想マシンの作成
- (2) OCPクラスタへの追加
- (3) Storage nodeとInfra nodeのラベルの付与
- (4) Storage nodeのTaintの設定

**ODFのインストール**
- (1) Local Storage Operatorの導入
- (2) OpenShift Data Foudationの導入

**ベアメタル環境でODFクラスタの作成**
- (1) ベアメタル環境でODFクラスタの作成

**ODFクラスタの正常性確認**


# 実際の手順

## 前提の確認

ベアメタルのOCP環境にODFを**インターナルモード**で導入する場合は、ODF用のノードに同じサイズのrawのディスクが存在する必要があります。
(参考) [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.5. ストレージデバイスの要件 / 7.5.2. ローカルストレージデバイス](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#_local_storage_devices)

ODF用ノードのサイジングは以下になります。
(参考) [ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.3. リソース要件](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#resource-requirements_rhodf)

(抜粋)
|デプロイメントモード|ベースサービス|追加のデバイスセット|
|:--|:--|:--|
|内部| 30 個の CPU (論理) <br> 72 GiB メモリー <br> 3 ストレージデバイス|6 個の CPU (論理) <br> 15 GiB メモリー <br> 3 ストレージデバイス|

今回の検証環境では上述要件を少し余裕をもって満たすように、ODF用のInfra nodeの仮想マシンを、`16 vCPU`、`Memory 32GB`、`ODF用追加仮想ディスク 1024GB`で作成しました。

| Server     | vCPU | Memory | Disk  | Disk2  | hostname                            | IP address #1 | IP Address #2  | notes                          |
|:-----------|:-----|:-------|:------|:-------|:------------------------------------|:--------------|:---------------|:-------------------------------|
| bastion #1 | 4    | 4GB    | 120GB |        | bastion-01.cluster-01.example.local | 172.16.100.11 | 192.168.100.11 |                                |
| bastion #2 | 4    | 4GB    | 120GB |        | bastion-01.cluster-01.example.local | 172.16.100.12 | 192.168.100.12 |                                |
| bootstrap  | 4    | 8GB    | 40GB  |        | bastion-01.cluster-01.example.local | 172.16.100.13 | 192.168.100.13 |                                |
| master #1  | 4    | 16GB   | 40GB  |        | master-01.cluster-01.example.local  | 172.16.100.14 | 192.168.100.14 |                                |
| master #2  | 4    | 16GB   | 40GB  |        | master-02.cluster-01.example.local  | 172.16.100.15 | 192.168.100.15 |                                |
| master #3  | 4    | 16GB   | 40GB  |        | master-03.cluster-01.example.local  | 172.16.100.16 | 192.168.100.16 |                                |
| infra #1   | 8    | 48GB   | 40GB  |        | infra-01.cluster-01.example.local   | 172.16.100.17 | 192.168.100.17 | infra node                     |
| infra #2   | 8    | 48GB   | 40GB  |        | infra-02.cluster-01.example.local   | 172.16.100.18 | 192.168.100.18 | infra node                     |
| infra #3   | 8    | 48GB   | 40GB  |        | infra-03.cluster-01.example.local   | 172.16.100.19 | 192.168.100.19 | infra node                     |
| storage #1 | 16   | 32GB   | 40GB  | 1024GB | infra-01.cluster-01.example.local   | 172.16.100.20 | 192.168.100.20 | infra node (for ODF)           |
| storage #2 | 16   | 32GB   | 40GB  | 1024GB | infra-02.cluster-01.example.local   | 172.16.100.21 | 192.168.100.21 | infra node (for ODF)           |
| storage #3 | 16   | 32GB   | 40GB  | 1024GB | infra-03.cluster-01.example.local   | 172.16.100.22 | 192.168.100.22 | infra node (for ODF)           |
| worker #1  | 4    | 60GB   | 120GB |        | worker-01.cluster-01.example.local  | 172.16.100.23 | 192.168.100.23 |                                |
| worker #2  | 4    | 60GB   | 120GB |        | worker-02.cluster-01.example.local  | 172.16.100.24 | 192.168.100.24 |                                |

## ノードの作成
### (1) 仮想マシンの作成

ODF用の仮想マシンは、上述のスペックに従い作成します。

手順は以下と同じ手順です。
(参考) [Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール / 仮想マシン作成](https://qiita.com/t_sweetfish/items/81268b29a3a7ad2f3f09#%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3%E4%BD%9C%E6%88%90)
(参考) [Qiita / Local Storage Operatorで、ロギング、モニタリングの永続ボリュームを作成する / ディスク構成(仮想マシン)](https://qiita.com/t_sweetfish/items/df10abc37764a1f22812#%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E6%A7%8B%E6%88%90%E4%BB%AE%E6%83%B3%E3%83%9E%E3%82%B7%E3%83%B3)

### (2) OCPクラスタへの追加

vCenterサーバーから以下記事の`(infra node / worker nodeの場合)`の手順に従って、ODF用のInfra node x3の仮想マシンを起動します。
(参考) [Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール / iPXEブートを使用したRHCOSのインストール](https://qiita.com/t_sweetfish/items/81268b29a3a7ad2f3f09#ipxe%E3%83%96%E3%83%BC%E3%83%88%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9Frhcos%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)

仮想マシンが起動したら、以下の手順で、Pending状態のCSRがなくなるまで、PendingのCSRを承認します。
(参考) [Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール / マシンの証明書署名要求の承認](https://qiita.com/t_sweetfish/items/81268b29a3a7ad2f3f09#%E3%83%9E%E3%82%B7%E3%83%B3%E3%81%AE%E8%A8%BC%E6%98%8E%E6%9B%B8%E7%BD%B2%E5%90%8D%E8%A6%81%E6%B1%82%E3%81%AE%E6%89%BF%E8%AA%8D)

手順後に、ODF用のinfra nodeが、worker nodeとして、OCPクラスタに追加されます。
(OCP 4.10のiPXEの構成でnodeを追加しても、workerのMCPに属しているので、自動でRHCOSもOCP 4.11にアップデートされます。)
```bash
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      3              3                   3                     0                      145d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      146d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      5              5                   5                     0                      146d
[root@bastion-01 ~]#
```
```bash
[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE    VERSION
infra-01     Ready    infra    146d   v1.24.6+5157800
infra-02     Ready    infra    146d   v1.24.6+5157800
infra-03     Ready    infra    146d   v1.24.6+5157800
master-01    Ready    master   146d   v1.24.6+5157800
master-02    Ready    master   146d   v1.24.6+5157800
master-03    Ready    master   146d   v1.24.6+5157800
storage-01   Ready    worker   80s    v1.24.6+5157800
storage-02   Ready    worker   78s    v1.24.6+5157800
storage-03   Ready    worker   77s    v1.24.6+5157800
worker-01    Ready    worker   146d   v1.24.6+5157800
worker-02    Ready    worker   146d   v1.24.6+5157800
[root@bastion-01 ~]#
```

ODF用の付与した1024GBの仮想ディスク2も認識しています。

(例: storage-01)
```bash
[root@bastion-01 ~]# ssh core@storage-01
The authenticity of host 'storage-01 (172.16.100.20)' can't be established.
ECDSA key fingerprint is SHA256:MqyuUHvXzTU/vO9domdUPGAxiQtnIogBkbS7ibIhUpo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'storage-01,172.16.100.20' (ECDSA) to the list of known hosts.
Red Hat Enterprise Linux CoreOS 411.86.202211072153-0
  Part of OpenShift 4.11, RHCOS is a Kubernetes native operating system
  managed by the Machine Config Operator (`clusteroperator/machine-config`).

WARNING: Direct SSH access to machines is not recommended; instead,
make configuration changes via `machineconfig` objects:
  https://docs.openshift.com/container-platform/4.11/architecture/architecture-rhcos.html

---
[core@storage-01 ~]$
[core@storage-01 ~]$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  127M  0 part
|-sda3   8:3    0  384M  0 part /boot
`-sda4   8:4    0 39.5G  0 part /sysroot
sdb      8:16   0    1T  0 disk
sr0     11:0    1 1024M  0 rom
[core@storage-01 ~]$
```

### (3) Storage nodeとInfra nodeのラベルの付与

今回は、運用コンポーネント用のInfra nodeとは別に、ODF専用のInfra nodeを追加で作成する方針とします。
(参考) [ODF 4.11 Docs / 7. Red Hat OpenShift Data Foundation に専用のワーカーノードを使用する方法 / 7.3. インフラストラクチャーノードの手動作成](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/managing_and_allocating_storage_resources/index#_manual_creation_of_infrastructure_nodes)
  
ODF用のノードにはODF関連のPodが稼働するように`cluster.ocs.openshift.io/openshift-storage=""`のラベルを付与します。
次に、ODF用のノードもInfra nodeにするため、`node-role.kubernetes.io/infra: ""`のラベルを付与します。
今回はInfra node用のMCPを作成しているため、ワーカーノード用の`node-role.kubernetes.io/worker: ""`のラベルは削除します。)

**作業前確認**
storate-0[1-3]のROLEがworkerで、workerのMCPに属しています。
```bash
[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE     VERSION
infra-01     Ready    infra    146d    v1.24.6+5157800
infra-02     Ready    infra    146d    v1.24.6+5157800
infra-03     Ready    infra    146d    v1.24.6+5157800
master-01    Ready    master   146d    v1.24.6+5157800
master-02    Ready    master   146d    v1.24.6+5157800
master-03    Ready    master   146d    v1.24.6+5157800
storage-01   Ready    worker   2m56s   v1.24.6+5157800
storage-02   Ready    worker   2m54s   v1.24.6+5157800
storage-03   Ready    worker   2m53s   v1.24.6+5157800
worker-01    Ready    worker   146d    v1.24.6+5157800
worker-02    Ready    worker   146d    v1.24.6+5157800
[root@bastion-01 ~]#
```
```bash
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      3              3                   3                     0                      145d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      146d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      5              5                   5                     0                      146d
[root@bastion-01 ~]#
```

**設定コマンド**

infraのノードラベル付与します。
```bash
[root@bastion-01 ~]# oc label node storage-01 node-role.kubernetes.io/infra=""
node/storage-01 labeled
[root@bastion-01 ~]# oc label node storage-02 node-role.kubernetes.io/infra=""
node/storage-02 labeled
[root@bastion-01 ~]# oc label node storage-03 node-role.kubernetes.io/infra=""
node/storage-03 labeled
[root@bastion-01 ~]#
```
workerのノードラベル削除します。
```bash
[root@bastion-01 ~]# oc label node storage-01 node-role.kubernetes.io/worker-
node/storage-01 unlabeled
[root@bastion-01 ~]# oc label node storage-02 node-role.kubernetes.io/worker-
node/storage-02 unlabeled
[root@bastion-01 ~]# oc label node storage-03 node-role.kubernetes.io/worker-
node/storage-03 unlabeled
[root@bastion-01 ~]#
```
`cluster.ocs.openshift.io/openshift-storage=""`のノードラベルを付与します。
```bash
[root@bastion-01 ~]# oc label node storage-01 cluster.ocs.openshift.io/openshift-storage=""
node/storage-01 labeled
[root@bastion-01 ~]# oc label node storage-02 cluster.ocs.openshift.io/openshift-storage=""
node/storage-02 labeled
[root@bastion-01 ~]# oc label node storage-03 cluster.ocs.openshift.io/openshift-storage=""
node/storage-03 labeled
[root@bastion-01 ~]#
```

確認します。
ODF用のInfra nodeに、infraのノードラベルが付与され、workerのノードラベルが削除されました。
また、`cluster.ocs.openshift.io/openshift-storage=""`が付与されてます。
```bash
[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE    VERSION
infra-01     Ready    infra    146d   v1.24.6+5157800
infra-02     Ready    infra    146d   v1.24.6+5157800
infra-03     Ready    infra    146d   v1.24.6+5157800
master-01    Ready    master   146d   v1.24.6+5157800
master-02    Ready    master   146d   v1.24.6+5157800
master-03    Ready    master   146d   v1.24.6+5157800
storage-01   Ready    infra    22h    v1.24.6+5157800
storage-02   Ready    infra    22h    v1.24.6+5157800
storage-03   Ready    infra    22h    v1.24.6+5157800
worker-01    Ready    worker   146d   v1.24.6+5157800
worker-02    Ready    worker   146d   v1.24.6+5157800
[root@bastion-01 ~]#
```
```bash
[root@bastion-01 ~]# oc get node storage-01 -o yaml | grep -A 9 labels
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    cluster.ocs.openshift.io/openshift-storage: ""
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: storage-01
    kubernetes.io/os: linux
    node-role.kubernetes.io/infra: ""
    node.openshift.io/os_id: rhcos
  name: storage-01
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node storage-02 -o yaml | grep -A 9 labels
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    cluster.ocs.openshift.io/openshift-storage: ""
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: storage-02
    kubernetes.io/os: linux
    node-role.kubernetes.io/infra: ""
    node.openshift.io/os_id: rhcos
  name: storage-02
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node storage-03 -o yaml | grep -A 9 labels
  labels:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/os: linux
    cluster.ocs.openshift.io/openshift-storage: ""
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: storage-03
    kubernetes.io/os: linux
    node-role.kubernetes.io/infra: ""
    node.openshift.io/os_id: rhcos
  name: storage-03
[root@bastion-01 ~]#
```


infra用の「MCP」と「Node」が紐づいたので、ODF専用のInfra nodeに自動でInfra node用の「MC」が適用されます。
Infra nodeにinfra用の「MC」適用後は、以下のように、infraの「MCP」の「MACHINECOUNT」が`6`になっています。

```bash
[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      6              6                   6                     0                      146d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      146d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      2              2                   2                     0                      146d
[root@bastion-01 ~]#
```
(一般的に「MC」の変更があった場合は、自動でnodeの再起動が走り、新しい「MCP」の「MC」が反映されますが、今回はinfraもworkerも同じ「MC」しか読み込んでおらず変更はなかったのでnodeの再起動はしていないみたいでした。)

### (4) ODF専用のInfra nodeのTaintの設定

ODF以外のInfra nodeで稼働する運用コンポーネント(ルーター、OCP内部レジストリ、モニタリング、ロギング)が、ODF専用のInfra nodeに移動しないように、ODF専用のInfra node用のTaintの設定をします。

**設定コマンド**

Taintを付与します。
```bash
[root@bastion-01 ~]# oc adm taint node storage-01 node.ocs.openshift.io/storage="true":NoSchedule
node/storage-01 tainted
[root@bastion-01 ~]# oc adm taint node storage-02 node.ocs.openshift.io/storage="true":NoSchedule
node/storage-02 tainted
[root@bastion-01 ~]# oc adm taint node storage-03 node.ocs.openshift.io/storage="true":NoSchedule
node/storage-03 tainted
[root@bastion-01 ~]#
```

確認します。
```bash
[root@bastion-01 ~]# oc get node storage-01 -o json | jq -r .spec.taints
[
  {
    "effect": "NoSchedule",
    "key": "node.ocs.openshift.io/storage",
    "value": "true"
  }
]
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node storage-02 -o json | jq -r .spec.taints
[
  {
    "effect": "NoSchedule",
    "key": "node.ocs.openshift.io/storage",
    "value": "true"
  }
]
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get node storage-03 -o json | jq -r .spec.taints
[
  {
    "effect": "NoSchedule",
    "key": "node.ocs.openshift.io/storage",
    "value": "true"
  }
]
[root@bastion-01 ~]#
```

**(補足)**
Cluster Logging OperatorのClusterLoggingリソースで定義された`fluentd`のDaemonsetなどは、ODF専用ノードでも稼働させる必要があります。
今回はODF用のInfra nodeにTaintの設定をしているため、このDaemonsetには、tolerationsの設定が必要になります。
(参考) [OCP 4.11 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.7. 容認を使用した OpenShift Logging Pod 配置の制御 / 4.7.3. 容認を使用したログコレクター Pod 配置の制御](https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.11/html-single/logging/index#cluster-logging-collector-tolerations_cluster-logging-tolerations)


**ClusterLoggingマニフェストの修正前**
(以下は、ODF導入前だったので、Local Storage OperatorのLocalVolumeリソースでPVを作成していました。この後の手順で、ODFクラスタ作成後はPVは置き換えると思いますが一旦ここでは無視してください。)
(この環境では[こちら](https://qiita.com/t_sweetfish/items/a81d23f85c2c18326755#1-nodeselector%E3%81%AE%E3%81%BF%E3%82%92%E4%BD%BF%E7%94%A8)の手順でInfra nodeを作成したので、通常のInfra nodeには特にTaintなどは設定していませんでした。)
logStore(Elasticsearch)、visualization(Kibana)は、Infra nodeで稼働するように`nodeSelector`のみを設定しています。
collection(fluentd)は、全node上で稼働させるために`nodeSelector`などは設定していませんでした。

```yaml
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 1d
      audit:
        maxAge: 1d
    elasticsearch:
      nodeCount: 3
      nodeSelector:
        node-role.kubernetes.io/infra: ''
      storage:
        storageClassName: local-elasticsearch
        size: 80G
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
      nodeSelector:
        node-role.kubernetes.io/infra: ''
  collection:
    logs:
      type: "fluentd"
      fluentd: {}
```
<br>

**ClusterLoggingマニフェストの修正**
collection(fluentd)の部分のみ修正しました。
```yaml
(略)
  collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations:
        - key: node.ocs.openshift.io/storage
          operator: "Exists"
          effect: "NoSchedule"
          tolerationSeconds: 6000
```
またはfluentdはどのnodeでも稼働してほしいで単純に以下でも十分かもしれません。
```yaml
(略)
  collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations:
        - operator: Exists
(略)
```

**修正したClusterLoggingマニフェストの適用**
```bash
[root@bastion-01 logging]# oc apply -f clo-instance-5.4-toleration.yaml
clusterlogging.logging.openshift.io/instance configured
[root@bastion-01 logging]# 
```

collection(fluentd)用のDaemonsetのPodがODF専用のTaintが付けられたInfra node上でも稼働していることが確認できます。
```bash
[root@bastion-01 logging]# oc get pod -n openshift-logging -l component=collector -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
collector-86wjn   2/2     Running   0          2m4s    10.129.4.8     storage-02   <none>           <none>
collector-9m9hl   2/2     Running   0          89s     10.129.3.49    infra-03     <none>           <none>
collector-fzmnw   2/2     Running   0          116s    10.130.4.8     storage-03   <none>           <none>
collector-j2vdt   2/2     Running   0          2m      10.130.2.13    infra-01     <none>           <none>
collector-lp5ng   2/2     Running   0          2m9s    10.130.1.134   master-03    <none>           <none>
collector-mbsfp   2/2     Running   0          93s     10.129.0.159   master-02    <none>           <none>
collector-pt9gj   2/2     Running   0          2m13s   10.128.2.19    infra-02     <none>           <none>
collector-vxnhq   2/2     Running   0          112s    10.131.2.97    worker-01    <none>           <none>
collector-z64z9   2/2     Running   0          98s     10.128.4.18    storage-01   <none>           <none>
collector-zd84v   2/2     Running   0          107s    10.131.0.11    worker-02    <none>           <none>
collector-zq868   2/2     Running   0          103s    10.128.0.45    master-01    <none>           <none>
[root@bastion-01 logging]#
```

## ODFのインストール

### (1) Local Storage Operatorの導入

ベアメタルのOCP環境でODFを導入する際には、Local Storage Operatorのインストールが必要です。
もしLocal Storage Operatorを導入していない場合は、こちらを参照の上、Operatorを導入しておきます。
(ここで、Local Storage Operatorが導入していなくても、ODFクラスタ作成手順の中で導入することもできます。)
(参考) [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.1. ローカルストレージ Operator のインストール](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#installing-local-storage-operator_local-bare-metal)

今回の検証環境は、一旦ODFを使用せず、Local Storage OperatorのLocalVolumeリソースでモニタリング、ロギング用のPVを作成していたので、Local Storage Operatorは導入済みでした。
(OCP 4.11では`4.11`ではなく`stable`というチャネルしか無くなっていたので、バージョンが明示的に示されたチャネルではなく`stable`チャネルで`4.11.x`のCSVバージョンまで上げています。)
| Operator      | Channel | 更新承認ストラテジー | CSV                                        |
|:--------------|:--------|:-------------|:-------------------------------------------|
| Local Storage | stable  | 手動           | local-storage-operator.4.11.0-202211072116 |

![2022-12-06-16-25-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/76d4b271-7b48-3ea4-0947-5451b89a644d.png)

### (2) OpenShift Data Foudationの導入

次にOpenShift Data Foudation Operatorを導入します。
(参考) [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.2. Red Hat OpenShift Data Foundation Operator のインストール](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#installing-openshift-data-foundation-operator-using-the-operator-hub_local-bare-metal)

| Operator                 | Channel     | 更新承認ストラテジー |
|:-------------------------|:------------|:-------------|
| OpenShift Data Foudation | stable-4.11 | 手動           |


今回はOCPのWebコンソールからOpenShift Data Foudation Operatorをインストールします。

OCP Web コンソールにcluster-admin roleのある管理者ユーザーでログインし、左側のメニューからOperator -> OperatorHubを選択します。
検索ボックスで「OpenShift Data Foundation」という文字列を入力して、「OpenShift Data Foudation」をクリックします。
![2022-12-06-16-26-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/63452b93-a3f5-b9f5-5549-06dd783bf148.png)

「OpenShift Data Foudation」画面で「インストール」をクリックします。
![2022-12-06-16-26-46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/b50142b3-672c-5061-52b5-0974fc0a4414.png)

「Operatorのインストール」ページで、「クラスター指定のnamespace」を選択します。デフォルトの`openshift-storage`が表示されており、存在しない場合は自動で作成されます。

その他、「インストールモード」や「更新の承認」などは以下のように設定しました。
設定をしたら「インストール」をクリックします。
|設定項目|デフォルト値|設定値|備考|
|:--|:--|:--|:--|
|更新チャネル|`stable-4.11`|デフォルトのまま| `stable-4.10` / `stable-4.11`が表示|
|インストールモード|クラスターの特定のnamespace| デフォルトのまま||
|インストール済みのnamespace|Operator推奨のnamespace (openshift-storage)| デフォルトのまま| namespace `openshift-storage`は存在しないため、自動で作成されます。|
|更新の承認|自動|手動|(※)実案件ではコンポーネントのバージョンは明確に管理する必要があったり、アップデートするタイミングを業務外にする必要があることがあります。<br>そのような場合には、自動でチャネル内の最新のパッチバージョンに更新されないようにするため「手動」にしたりします。|
|コンソールプラグイン|有効にする|デフォルトのまま||

![2022-12-06-16-33-07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/41e14ee9-544e-9a4c-300e-292b3fb02aea.png)

「更新の承認」を「手動」にしたので、「承認」をクリックします。
![2022-12-06-16-34-38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/5d64c8a8-3255-0bc5-208e-76c95f1f3912.png)

インストールが継続され、インストールが完了します。
![2022-12-06-16-38-19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/32e38a78-b361-6d40-b11d-2abfc4014ff3.png)

OpenShift Data Foudation Operatorが、OCPのWebコンソールの Installed Operatorsセクションに一覧表示されます。
![2022-12-06-16-40-09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/f8af38f7-6ae9-9347-9cb2-0b56a3fe88f3.png)


OpenShift Data Foudation Operatorは、`cluster.ocs.openshift.io/openshift-storage=""`のラベルが付与されたODF用のInfra node上で稼働していました。
```bash
[root@bastion-01 ~]# oc get pod -n openshift-storage -o wide
NAME                                               READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
csi-addons-controller-manager-5595f56479-lj8cp     2/2     Running   0          10m     10.129.4.10   storage-02   <none>           <none>
noobaa-operator-6bb5695f4-9nlj6                    1/1     Running   0          10m     10.130.4.9    storage-03   <none>           <none>
ocs-metrics-exporter-9b987f9d9-f2xh8               1/1     Running   0          9m50s   10.128.4.22   storage-01   <none>           <none>
ocs-operator-546cf489f6-csvjr                      1/1     Running   0          10m     10.128.4.20   storage-01   <none>           <none>
odf-console-54c7845f4f-kpqg5                       1/1     Running   0          10m     10.129.4.9    storage-02   <none>           <none>
odf-operator-controller-manager-6f855ffd95-q8t72   2/2     Running   0          10m     10.128.4.19   storage-01   <none>           <none>
rook-ceph-operator-7cfdb666f8-cbd9j                1/1     Running   0          10m     10.128.4.21   storage-01   <none>           <none>
[root@bastion-01 ~]#
```

(補足)
「コンソールプラグイン」を「有効にする」にするのオプションをつけたまま導入すると、OCP Webコンソールのストレージ -> Data Foudationのメニューが追加されました。
![2022-12-06-16-50-23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/7991e6df-9a8c-a7fc-5c58-1d2c363c5f7b.png)

## ベアメタル環境でODFクラスタの作成

### (1) ベアメタル環境でODFクラスタの作成

以下の手順に従って、ODFクラスタを作成します。
(参考) [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#deploy-using-local-storage-devices-bm)

OCP Web コンソールで、Operator -> インストール済みのOperatorをクリックし、インストールされたOperatorを表示します。Projectは`openshift-storage`を選択します。
表示された「OpenShift Data Foundation Operator」をクリックし、「StorageSystemの作成」をクリックします。
![2022-12-06-16-54-52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/de0c8634-baa7-6e92-cc89-295c49a83f0b.png)

「バッキングストレージ」セクションで、以下を選択し、「次へ」をクリックします。
Local Storage Operatorと連携してODF用のInfra nodeに付与した仮想ディスク2を使用するように、専用に新規ストレージクラスを作成します。
(Local Storage Operatorが導入されていない場合は、ここでインストールが促されるとのことなのでここでインストールします。今回はすでに導入しているのでそのまま進みます。)
|設定項目|デフォルト値|設定値|備考|
|:--|:--|:--|:--|
|デプロイメントタイプ|Full deployment |デフォルトのまま| Full deployment / Multicloud Object Gateway|
|バッキングストレージのタイプ|既存のストレージクラスの使用|ローカルデバイスを使用した新規ストレージクラスの作成|既存のストレージクラスの使用 / ローカルデバイスを使用した新規ストレージクラスの作成 / 外部ストレージプラットフォームの接続|

![2022-12-06-17-00-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/e9e20400-586c-51f0-ca87-8df75129e569.png)

「ローカルボリュームセットの作成」セクションで以下を入力し、「次へ」をクリックします。
今回はODF専用のInfra nodeを作成するので、Taint nodesのチェックボックスにチェックを入れることにしました。
|設定項目|デフォルト値|設定値|備考|
|:--|:--|:--|:--|
|ローカルのボリュームセット名 / ストレージクラス名|blank |(例)localblock |ODFからPVを作成する際に指定する任意のStorage Class名を指定 <br> ODFが自動で作成するStorage Class name (ocs-storagecluster-cephfs、ocs-storagecluster-ceph-rbd、ocs-storagecluster-ceph-rgw、openshift-storage.noobaa.io)とは別の名前を指定する|
|ディスクのフィルター|すべてのノードのディスク (8 ノード)|選択されたノードのディスク|ODF専用のInfra nodeのみを指定するために変更|
|選択されたノードのディスク|storage-0[1-3]|デフォルトのまま|「ディスクのフィルター」で「選択されたノードのディスク」を選択すると、Storage node用のノードラベルが付与されたnodeにデフォルトでチェックが入っている|
|ディスクタイプ|すべて|デフォルトのまま|すべて, SSD/NVMe, HDD|
|「詳細」セクション||||
|ボリュームモード|Block|デフォルトのまま|Block / Filesystem|
|デバイスタイプ|Disk, Part|デフォルトのまま||
|ディスクサイズ| 最小1 - 最大(blank) GiB|デフォルトのまま||
|最大ディスク制限|blank|デフォルトのまま|フィールドが空の場合、一致するノードで利用可能なすべてのディスクについてPVを作成する|

![2022-12-06-17-11-16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/6bee7b0a-0813-ed18-7a9d-7a731b32d4f6.png)
![2022-12-06-17-12-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/d69dbeb5-6db0-5614-61e7-0cca35f5289d.png)

ローカルのボリュームセットの作成を確認するポップアップが表示されるので「Yes」をクリックします。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/33bb1823-66bf-ac4b-1e93-52dd0a0bae45.png width="300">

「永続ボリュームは選択したノードでプロビジョニングされます。」とのメッセージが表示され処理が進みます。
![2022-12-06-17-13-35.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/7ace90bd-4a1f-6856-a938-5acf15ca8975.png)

「容量およびノード」セクションで、以下を入力し、「次へ」をクリックします。

ODF専用のInfra nodeを作成するため、テイントノードにチェックを入れます。
ODF用のInfra nodeにするノードに ODFのコンポーネントのターゲットホストとして事前に設定しておいた`cluster.ocs.openshift.io/openshift-storage=""`というノードラベルは、事前に設定していなければ、このタイミングで自動で付与もできるようでした。

| 設定項目           | デフォルト値        | 設定値   | 備考                                                                                                             |
|:-------------------|:---------------|:---------|:-----------------------------------------------------------------------------------------------------------------|
| 利用可能な Raw 容量 | 3TiB           | デフォルトのまま |                                                                                                                  |
| 選択されたノード         | storage-0[1-3] | デフォルトのまま | ODF専用のInfra nodeが指定                                                                                          |
| テイントノード            | チェックなし         | チェック     | 運用コンポーネント用のInfra nodeのコンポーネントがODF専用のInfra nodeで稼働しないようにTaintを使用するためチェックを入れる。<br>選択されたノードはODFのみが使用。 |

![2022-12-06-17-18-30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/161b0e65-e8f8-6428-0017-494a52199bfc.png)

「セキュリティおよびネットワーク」セクションでは、特に何も設定せずに、「次へ」をクリックしました。
暗号化
| 設定項目                           | デフォルト値 | 設定値   | 備考 |
|:-------------------------------|:--------|:---------|:-----|
| ブロックおよびファイルストレージのデータ暗号化を有効にする | チェックなし  | デフォルトのまま |      |

ネットワーク
| 設定項目 | デフォルト値    | 設定値   | 備考                         |
|:---------|:-----------|:---------|:-----------------------------|
| ネットワーク   | デフォルト(SDN) | デフォルトのまま | 「カスタム(Multus) 」はテクノロジープレビュー) |

![2022-12-06-17-20-52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/3a6f4fa0-46e0-1d9a-af3f-83692134a5da.png)

> (補足)
> 今回の検証環境では、OCPクラスタを構成する各ノードは、OCPクラスタ用のネットワークと、別のサービス用のネットワークにも足を出す構成を想定し、NICは2つにしています。
> 
> 複数NICの場合の場合のオプションとして、以下のMultusを使用する設定があるようでしたが、説明はおそらく以下ではないかと思われます。
> (参考) [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用した OpenShift Data Foundation のデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.5. Multus ネットワークの作成 [テクノロジープレビュー]](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#creating-multus-networks_local-bare-metal)
> (参考)　[ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.6. マルチネットワークプラグイン (Multus) のサポート [テクノロジープレビュー]](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/planning_your_deployment/index#multi-network-plugin-multus-support_rhodf)
> 
> (なお、上述はTPなのと、今回の検証環境は2つ目のNICの用途はODF専用のトラフィック用という想定をしていたわけではないため、今回はデフォルトの「デフォルト(SDN)」のまま何も変更しませんでした。)


「確認および作成」セクションで、設定の詳細を確認し「ストレージシステムの作成」をクリックします。
![2022-12-06-17-25-41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/a2c41c29-0e9d-2c56-22eb-d76d34600350.png)

しばらく待つとOCP Webコンソールのストレージ -> Data Foundationに、「ストレージサブシステム」のエントリが表示されます。
![2022-12-06-17-37-53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/740e6005-bc1e-0558-78e4-33ae574ca951.png)

## ODFクラスタの正常性確認

以下の手順に従ってODFのクラスターが正常にデプロイされているかを確認します。
(参考) [ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用した OpenShift Data Foundation のデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.7. OpenShift Data Foundation デプロイメントの確認](https://access.redhat.com/documentation/ja-jp/red_hat_openshift_data_foundation/4.11/html-single/deploying_openshift_data_foundation_using_bare_metal_infrastructure/index#_verifying_openshift_data_foundation_deployment)

### Podの状態の確認

```bash
[root@bastion-01 ~]# oc get pod -n openshift-storage -o wide
NAME                                                              READY   STATUS      RESTARTS        AGE     IP              NODE         NOMINATED NODE   READINESS GATES
csi-addons-controller-manager-5595f56479-lj8cp                    2/2     Running     1 (6m21s ago)   57m     10.129.4.10     storage-02   <none>           <none>
csi-cephfsplugin-2mzdb                                            3/3     Running     0               8m26s   172.16.100.20   storage-01   <none>           <none>
csi-cephfsplugin-bnjvl                                            3/3     Running     0               8m26s   172.16.100.19   infra-03     <none>           <none>
csi-cephfsplugin-bvwt4                                            3/3     Running     0               8m25s   172.16.100.22   storage-03   <none>           <none>
csi-cephfsplugin-hlqkj                                            3/3     Running     0               8m26s   172.16.100.18   infra-02     <none>           <none>
csi-cephfsplugin-kbwjm                                            3/3     Running     0               8m26s   172.16.100.17   infra-01     <none>           <none>
csi-cephfsplugin-ksc5h                                            3/3     Running     0               8m26s   172.16.100.21   storage-02   <none>           <none>
csi-cephfsplugin-provisioner-747f9b4884-8r2jt                     6/6     Running     0               8m26s   10.130.4.12     storage-03   <none>           <none>
csi-cephfsplugin-provisioner-747f9b4884-vrnmb                     6/6     Running     0               8m26s   10.129.4.14     storage-02   <none>           <none>
csi-cephfsplugin-z5ghg                                            3/3     Running     0               8m26s   172.16.100.24   worker-02    <none>           <none>
csi-cephfsplugin-z5wdt                                            3/3     Running     0               8m26s   172.16.100.23   worker-01    <none>           <none>
csi-rbdplugin-bx8zb                                               4/4     Running     0               8m26s   172.16.100.21   storage-02   <none>           <none>
csi-rbdplugin-cksnl                                               4/4     Running     0               8m26s   172.16.100.19   infra-03     <none>           <none>
csi-rbdplugin-dnqrc                                               4/4     Running     0               8m26s   172.16.100.20   storage-01   <none>           <none>
csi-rbdplugin-kcn77                                               4/4     Running     0               8m26s   172.16.100.17   infra-01     <none>           <none>
csi-rbdplugin-kkcfn                                               4/4     Running     0               8m26s   172.16.100.24   worker-02    <none>           <none>
csi-rbdplugin-mvr2f                                               4/4     Running     0               8m26s   172.16.100.23   worker-01    <none>           <none>
csi-rbdplugin-nprlr                                               4/4     Running     0               8m26s   172.16.100.22   storage-03   <none>           <none>
csi-rbdplugin-provisioner-67c84f6f8c-522qd                        7/7     Running     0               8m26s   10.128.4.25     storage-01   <none>           <none>
csi-rbdplugin-provisioner-67c84f6f8c-p4xdr                        7/7     Running     0               8m26s   10.129.4.15     storage-02   <none>           <none>
csi-rbdplugin-tb29g                                               4/4     Running     0               8m26s   172.16.100.18   infra-02     <none>           <none>
noobaa-core-0                                                     1/1     Running     0               3m46s   10.129.4.23     storage-02   <none>           <none>
noobaa-db-pg-0                                                    1/1     Running     0               3m46s   10.130.4.22     storage-03   <none>           <none>
noobaa-endpoint-767957bc9b-hjtkc                                  1/1     Running     0               2m17s   10.130.4.23     storage-03   <none>           <none>
noobaa-operator-6bb5695f4-9nlj6                                   1/1     Running     1 (3m46s ago)   57m     10.130.4.9      storage-03   <none>           <none>
ocs-metrics-exporter-9b987f9d9-f2xh8                              1/1     Running     0               57m     10.128.4.22     storage-01   <none>           <none>
ocs-operator-546cf489f6-csvjr                                     1/1     Running     1 (6m21s ago)   57m     10.128.4.20     storage-01   <none>           <none>
odf-console-54c7845f4f-kpqg5                                      1/1     Running     0               57m     10.129.4.9      storage-02   <none>           <none>
odf-operator-controller-manager-6f855ffd95-q8t72                  2/2     Running     1 (6m30s ago)   57m     10.128.4.19     storage-01   <none>           <none>
rook-ceph-crashcollector-storage-01-b7fb47f9b-6px45               1/1     Running     0               4m38s   10.128.4.34     storage-01   <none>           <none>
rook-ceph-crashcollector-storage-02-7f7bf67899-bg4tz              1/1     Running     0               4m28s   10.129.4.22     storage-02   <none>           <none>
rook-ceph-crashcollector-storage-03-55947766d6-pvvn8              1/1     Running     0               4m40s   10.130.4.21     storage-03   <none>           <none>
rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-7d8c68cbb72ps   2/2     Running     0               4m40s   10.130.4.20     storage-03   <none>           <none>
rook-ceph-mds-ocs-storagecluster-cephfilesystem-b-5ffd88f567t87   2/2     Running     0               4m38s   10.128.4.33     storage-01   <none>           <none>
rook-ceph-mgr-a-7759bb9c54-rv8qm                                  2/2     Running     0               5m22s   10.128.4.28     storage-01   <none>           <none>
rook-ceph-mon-a-b5d9b98f-xv5hp                                    2/2     Running     0               6m52s   10.129.4.17     storage-02   <none>           <none>
rook-ceph-mon-b-c6b768fcc-rzssr                                   2/2     Running     0               5m51s   10.128.4.27     storage-01   <none>           <none>
rook-ceph-mon-c-5786c7bb6d-f8qhz                                  2/2     Running     0               5m36s   10.130.4.14     storage-03   <none>           <none>
rook-ceph-operator-7cfdb666f8-cbd9j                               1/1     Running     0               57m     10.128.4.21     storage-01   <none>           <none>
rook-ceph-osd-0-78557884b6-zbjxq                                  2/2     Running     0               4m50s   10.128.4.31     storage-01   <none>           <none>
rook-ceph-osd-1-565c8c4fbc-bxjkm                                  2/2     Running     0               4m49s   10.130.4.17     storage-03   <none>           <none>
rook-ceph-osd-2-58d47c974f-mx79n                                  2/2     Running     0               4m48s   10.129.4.20     storage-02   <none>           <none>
rook-ceph-osd-prepare-15c290412ddd96f47052f431b658d0f9-tz8jp      0/1     Completed   0               5m      10.129.4.19     storage-02   <none>           <none>
rook-ceph-osd-prepare-c25e550ad0838aa59928a789f339ce2e-m4468      0/1     Completed   0               5m1s    10.128.4.30     storage-01   <none>           <none>
rook-ceph-osd-prepare-cfece50b59d7a974890c784d9a748ec7-frksn      0/1     Completed   0               5m1s    10.130.4.16     storage-03   <none>           <none>
rook-ceph-rgw-ocs-storagecluster-cephobjectstore-a-56f4465q78vl   2/2     Running     0               4m29s   10.129.4.21     storage-02   <none>           <none>
[root@bastion-01 ~]#
```

### ODFクラスタの正常性確認

OCP Webコンソールのストレージ -> Data Foundationの「ストレージシステム」タブから、「ocs-storagecluster-storagesystem」のリンクをクリックします。
![2022-12-06-17-44-57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/9a4772bc-1669-6516-e26d-d37a4528c69c.png)

「ブロックおよびファイル」タブの「ステータス」欄で「ストレージクラスター」のステータスが緑になっており、各種情報が表示されています。
![2022-12-06-17-46-47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/8f1724eb-2828-08a3-dc73-8c9be6c179b9.png)

### Multicloud Object Gateway が正常であることの確認

「Object」タブの「ステータス」欄で「オブジェクトサービス」のステータスが緑になっており、各種情報が表示されています。
![2022-12-06-17-53-51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/332622/826f12b4-9764-23f3-5e0a-a494220cfe7b.png)

### ODF固有のストレージクラスが存在することの確認

ODF固有の以下のストレージクラスが存在することを確認します。

- ocs-storagecluster-ceph-rbd
- ocs-storagecluster-cephfs
- openshift-storage.noobaa.io
- ocs-storagecluster-ceph-rgw

これに加えて、先ほど「 [(1) ベアメタル環境でODFクラスタの作成](#1-ベアメタル環境でodfクラスタの作成) 」の「ローカルのボリュームセット名 / ストレージクラス名」欄で指定した`localblock`という名前のストレージクラスが作成されています。
```bash
[root@bastion-01 ~]# oc get sc
NAME                          PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
(略)
localblock                    kubernetes.io/no-provisioner            Delete          WaitForFirstConsumer   false                  46m
ocs-storagecluster-ceph-rbd   openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   28m
ocs-storagecluster-ceph-rgw   openshift-storage.ceph.rook.io/bucket   Delete          Immediate              false                  32m
ocs-storagecluster-cephfs     openshift-storage.cephfs.csi.ceph.com   Delete          Immediate              true                   28m
openshift-storage.noobaa.io   openshift-storage.noobaa.io/obc         Delete          Immediate              false                  26m
[root@bastion-01 ~]#
```

### 補足

#### (補足) PV、PVC
LocalVolumeリソースなどは作成されておらず、ODFが使用しているPVとPVCが作成されていました。

```bash
[root@bastion-01 ~]# oc get pv | grep -e "NAME" -e "openshift-storage"
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                                           STORAGECLASS                  REASON   AGE
local-pv-6b3c4558                          1Ti        RWO            Delete           Bound       openshift-storage/ocs-deviceset-localblock-0-data-1hr9d2        localblock                             48m
local-pv-d94c27a1                          1Ti        RWO            Delete           Bound       openshift-storage/ocs-deviceset-localblock-0-data-2sj4q7        localblock                             48m
local-pv-faa39169                          1Ti        RWO            Delete           Bound       openshift-storage/ocs-deviceset-localblock-0-data-0lbwk7        localblock                             48m
pvc-3c3c4b45-a56c-4987-9f31-bb2a01afa630   50Gi       RWO            Delete           Bound       openshift-storage/db-noobaa-db-pg-0                             ocs-storagecluster-ceph-rbd            31m
[root@bastion-01 ~]#
```
```bash
[root@bastion-01 ~]# oc get pvc -n openshift-storage
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
db-noobaa-db-pg-0                        Bound    pvc-3c3c4b45-a56c-4987-9f31-bb2a01afa630   50Gi       RWO            ocs-storagecluster-ceph-rbd   31m
ocs-deviceset-localblock-0-data-0lbwk7   Bound    local-pv-faa39169                          1Ti        RWO            localblock                    33m
ocs-deviceset-localblock-0-data-1hr9d2   Bound    local-pv-6b3c4558                          1Ti        RWO            localblock                    33m
ocs-deviceset-localblock-0-data-2sj4q7   Bound    local-pv-d94c27a1                          1Ti        RWO            localblock                    33m
[root@bastion-01 ~]#
```
PVの詳細の詳細を見ると、ODF専用のInfra nodeに作成したODF用の仮想ディスクが使用されているこれていることがわかります。
- ODF専用のInfra node (`storage-0[1-3]`が、`.spec.nodeAffinity`で選択されている。
- `storage-0[1-3]`のROCOS上で認識されているODF用に作成した1Tiの仮想ディスク2(sdb)が`.spec.local.path`で指定されている。
```yaml
[root@bastion-01 ~]# oc get pv local-pv-6b3c4558 -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: local-volume-provisioner-storage-01-d93bc28a-be43-438b-896a-a312ef4ab0b6
    storage.openshift.com/device-id: scsi-36000c2946232aa74c05f8e3a8faecf00
    storage.openshift.com/device-name: sdb
  creationTimestamp: "2022-12-06T08:14:02Z"
  finalizers:
  - kubernetes.io/pv-protection
  labels:
    kubernetes.io/hostname: storage-01
    storage.openshift.com/owner-kind: LocalVolumeSet
    storage.openshift.com/owner-name: localblock
    storage.openshift.com/owner-namespace: openshift-local-storage
  name: local-pv-6b3c4558
  resourceVersion: "89288078"
  uid: 7fec0f0a-8adb-493f-bb72-7ba33ee6f971
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Ti
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: ocs-deviceset-localblock-0-data-1hr9d2
    namespace: openshift-storage
    resourceVersion: "89288051"
    uid: d84c825e-bf6e-41d4-910e-ed0cc856023d
  local:
    path: /mnt/local-storage/localblock/scsi-36000c2946232aa74c05f8e3a8faecf00
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - storage-01
  persistentVolumeReclaimPolicy: Delete
  storageClassName: localblock
  volumeMode: Block
status:
  phase: Bound
[root@bastion-01 ~]#
```
RHCOSでのディスクの認識
```bash
[root@bastion-01 ~]# ssh core@storage-01
(略)
[core@storage-01 ~]$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0    7:0    0    1T  0 loop
sda      8:0    0   40G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  127M  0 part
|-sda3   8:3    0  384M  0 part /boot
`-sda4   8:4    0 39.5G  0 part /sysroot
sdb      8:16   0    1T  0 disk
sr0     11:0    1 1024M  0 rom
[core@storage-01 ~]$
[core@storage-01 ~]$ ls -l /dev/disk/by-id/ | grep sdb
lrwxrwxrwx. 1 root root  9 Dec  8 12:40 scsi-36000c2946232aa74c05f8e3a8faecf00 -> ../../sdb
lrwxrwxrwx. 1 root root  9 Dec  8 12:40 scsi-SVMware_Virtual_disk_6000c2946232aa74c05f8e3a8faecf00 -> ../../sdb
lrwxrwxrwx. 1 root root  9 Dec  8 12:40 wwn-0x6000c2946232aa74c05f8e3a8faecf00 -> ../../sdb
[core@storage-01 ~]$
[core@storage-01 ~]$ ls -l /mnt/local-storage/localblock/
total 0
lrwxrwxrwx. 1 root root 54 Dec  6 08:14 scsi-36000c2946232aa74c05f8e3a8faecf00 -> /dev/disk/by-id/scsi-36000c2946232aa74c05f8e3a8faecf00
[core@storage-01 ~]$
```

storage-0[2-3]のPV(local-pv-d94c27a1、local-pv-faa39169)も同様です。



<br>

#### (補足)Storage Class
```
[root@bastion-01 ~]# oc get sc
NAME                          PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
(略)
localblock                    kubernetes.io/no-provisioner            Delete          WaitForFirstConsumer   false                  51m
ocs-storagecluster-ceph-rbd   openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   33m
ocs-storagecluster-ceph-rgw   openshift-storage.ceph.rook.io/bucket   Delete          Immediate              false                  37m
ocs-storagecluster-cephfs     openshift-storage.cephfs.csi.ceph.com   Delete          Immediate              true                   33m
openshift-storage.noobaa.io   openshift-storage.noobaa.io/obc         Delete          Immediate              false                  31m
[root@bastion-01 ~]#
```

(補足)Storage Classの詳細
```yaml
[root@bastion-01 ~]# oc get sc localblock -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: "2022-12-06T08:12:55Z"
  labels:
    local.storage.openshift.io/owner-name: localblock
    local.storage.openshift.io/owner-namespace: openshift-local-storage
  name: localblock
  resourceVersion: "89256810"
  uid: fb219980-1877-4b46-917d-eee9f1c6ee96
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
[root@bastion-01 ~]#
```
```yaml
[root@bastion-01 ~]# oc get sc ocs-storagecluster-ceph-rbd -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    description: Provides RWO Filesystem volumes, and RWO and RWX Block volumes
  creationTimestamp: "2022-12-06T08:31:17Z"
  name: ocs-storagecluster-ceph-rbd
  resourceVersion: "89290959"
  uid: 53de781e-f505-438c-98ad-10217a228860
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  csi.storage.k8s.io/fstype: ext4
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  imageFormat: "2"
  pool: ocs-storagecluster-cephblockpool
provisioner: openshift-storage.rbd.csi.ceph.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
[root@bastion-01 ~]#
```
```yaml
[root@bastion-01 ~]# oc get sc ocs-storagecluster-ceph-rgw -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    description: Provides Object Bucket Claims (OBCs)
  creationTimestamp: "2022-12-06T08:26:39Z"
  name: ocs-storagecluster-ceph-rgw
  resourceVersion: "89282523"
  uid: 0f6bfb8b-941d-48b0-95bd-100d19898e04
parameters:
  objectStoreName: ocs-storagecluster-cephobjectstore
  objectStoreNamespace: openshift-storage
  region: us-east-1
provisioner: openshift-storage.ceph.rook.io/bucket
reclaimPolicy: Delete
volumeBindingMode: Immediate
[root@bastion-01 ~]#
```
```yaml
[root@bastion-01 ~]# oc get sc ocs-storagecluster-cephfs -o yaml
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    description: Provides RWO and RWX Filesystem volumes
  creationTimestamp: "2022-12-06T08:31:17Z"
  name: ocs-storagecluster-cephfs
  resourceVersion: "89290958"
  uid: 5f3b4f65-c762-48d0-9042-2adde26b9b93
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  fsName: ocs-storagecluster-cephfilesystem
provisioner: openshift-storage.cephfs.csi.ceph.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
[root@bastion-01 ~]#
```


以上です。
(今後はモニタリング、ロギングのPVなどをODFから作成して使用させる設定をしようと思います。)