Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

@t_sweetfish

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

Last updated at Posted at 2022-12-06

概要

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

参考リンク

前提確認

Infra node

デプロイ方法

検証環境

OCP構成

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

  • 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を作成前)

[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を作成する

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

  • 今回は、運用コンポーネント用の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 のインストール

もし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. ローカルストレージデバイス

ODF用ノードのサイジングは以下になります。
(参考) ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.3. リソース要件

(抜粋)

デプロイメントモード ベースサービス 追加のデバイスセット
内部 30 個の CPU (論理)
72 GiB メモリー
3 ストレージデバイス		 6 個の CPU (論理)
15 GiB メモリー
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) インストール / 仮想マシン作成
(参考) Qiita / Local Storage Operatorで、ロギング、モニタリングの永続ボリュームを作成する / ディスク構成(仮想マシン)

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

vCenterサーバーから以下記事の(infra node / worker nodeの場合)の手順に従って、ODF用のInfra node x3の仮想マシンを起動します。
(参考) Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール / iPXEブートを使用したRHCOSのインストール

仮想マシンが起動したら、以下の手順で、Pending状態のCSRがなくなるまで、PendingのCSRを承認します。
(参考) Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール / マシンの証明書署名要求の承認

手順後に、ODF用のinfra nodeが、worker nodeとして、OCPクラスタに追加されます。
(OCP 4.10のiPXEの構成でnodeを追加しても、workerのMCPに属しているので、自動でRHCOSもOCP 4.11にアップデートされます。)

[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 ~]#

[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)

[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. インフラストラクチャーノードの手動作成

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に属しています。

[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 ~]#

[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のノードラベル付与します。

[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のノードラベル削除します。

[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=""のノードラベルを付与します。

[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=""が付与されてます。

[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 ~]#

[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になっています。

[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を付与します。

[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 ~]#

確認します。

[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 配置の制御

ClusterLoggingマニフェストの修正前
(以下は、ODF導入前だったので、Local Storage OperatorのLocalVolumeリソースでPVを作成していました。この後の手順で、ODFクラスタ作成後はPVは置き換えると思いますが一旦ここでは無視してください。)
(この環境ではこちらの手順でInfra nodeを作成したので、通常のInfra nodeには特にTaintなどは設定していませんでした。)
logStore(Elasticsearch)、visualization(Kibana)は、Infra nodeで稼働するようにnodeSelectorのみを設定しています。
collection(fluentd)は、全node上で稼働させるためにnodeSelectorなどは設定していませんでした。

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: {}

ClusterLoggingマニフェストの修正
collection(fluentd)の部分のみ修正しました。

(略)
  collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations:
        - key: node.ocs.openshift.io/storage
          operator: "Exists"
          effect: "NoSchedule"
          tolerationSeconds: 6000

またはfluentdはどのnodeでも稼働してほしいで単純に以下でも十分かもしれません。

(略)
  collection:
    logs:
      type: "fluentd"
      fluentd:
        tolerations:
        - operator: Exists
(略)

修正したClusterLoggingマニフェストの適用

[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上でも稼働していることが確認できます。

[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 のインストール

今回の検証環境は、一旦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

(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 のインストール

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

「OpenShift Data Foudation」画面で「インストール」をクリックします。
2022-12-06-16-26-46.png

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

その他、「インストールモード」や「更新の承認」などは以下のように設定しました。
設定をしたら「インストール」をクリックします。

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

2022-12-06-16-33-07.png

「更新の承認」を「手動」にしたので、「承認」をクリックします。
2022-12-06-16-34-38.png

インストールが継続され、インストールが完了します。
2022-12-06-16-38-19.png

OpenShift Data Foudation Operatorが、OCPのWebコンソールの Installed Operatorsセクションに一覧表示されます。
2022-12-06-16-40-09.png

OpenShift Data Foudation Operatorは、cluster.ocs.openshift.io/openshift-storage=""のラベルが付与されたODF用のInfra node上で稼働していました。

[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

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

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

以下の手順に従って、ODFクラスタを作成します。
(参考) ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用したOpenShift Data Foundationのデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ

OCP Web コンソールで、Operator -> インストール済みのOperatorをクリックし、インストールされたOperatorを表示します。Projectはopenshift-storageを選択します。
表示された「OpenShift Data Foundation Operator」をクリックし、「StorageSystemの作成」をクリックします。
2022-12-06-16-54-52.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

「ローカルボリュームセットの作成」セクションで以下を入力し、「次へ」をクリックします。
今回はODF専用のInfra nodeを作成するので、Taint nodesのチェックボックスにチェックを入れることにしました。

設定項目 デフォルト値 設定値 備考
ローカルのボリュームセット名 / ストレージクラス名 blank (例)localblock ODFからPVを作成する際に指定する任意のStorage Class名を指定
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
2022-12-06-17-12-00.png

ローカルのボリュームセットの作成を確認するポップアップが表示されるので「Yes」をクリックします。

「永続ボリュームは選択したノードでプロビジョニングされます。」とのメッセージが表示され処理が進みます。
2022-12-06-17-13-35.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を使用するためチェックを入れる。
選択されたノードはODFのみが使用。

2022-12-06-17-18-30.png

「セキュリティおよびネットワーク」セクションでは、特に何も設定せずに、「次へ」をクリックしました。
暗号化

設定項目 デフォルト値 設定値 備考
ブロックおよびファイルストレージのデータ暗号化を有効にする チェックなし デフォルトのまま

ネットワーク

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

2022-12-06-17-20-52.png

(補足)
今回の検証環境では、OCPクラスタを構成する各ノードは、OCPクラスタ用のネットワークと、別のサービス用のネットワークにも足を出す構成を想定し、NICは2つにしています。

複数NICの場合の場合のオプションとして、以下のMultusを使用する設定があるようでしたが、説明はおそらく以下ではないかと思われます。
(参考) ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用した OpenShift Data Foundation のデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.5. Multus ネットワークの作成 [テクノロジープレビュー]
(参考)　ODF 4.11 Docs / デプロイメントのプランニング / 7. インフラストラクチャーの要件 / 7.6. マルチネットワークプラグイン (Multus) のサポート [テクノロジープレビュー]

(なお、上述はTPなのと、今回の検証環境は2つ目のNICの用途はODF専用のトラフィック用という想定をしていたわけではないため、今回はデフォルトの「デフォルト(SDN)」のまま何も変更しませんでした。)

「確認および作成」セクションで、設定の詳細を確認し「ストレージシステムの作成」をクリックします。
2022-12-06-17-25-41.png

しばらく待つとOCP Webコンソールのストレージ -> Data Foundationに、「ストレージサブシステム」のエントリが表示されます。
2022-12-06-17-37-53.png

ODFクラスタの正常性確認

以下の手順に従ってODFのクラスターが正常にデプロイされているかを確認します。
(参考) ODF 4.11 Docs / ベアメタルインフラストラクチャーを使用した OpenShift Data Foundation のデプロイ / 2. ローカルストレージデバイスを使用した OpenShift Data Foundation のデプロイ / 2.7. OpenShift Data Foundation デプロイメントの確認

Podの状態の確認

[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

「ブロックおよびファイル」タブの「ステータス」欄で「ストレージクラスター」のステータスが緑になっており、各種情報が表示されています。
2022-12-06-17-46-47.png

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

「Object」タブの「ステータス」欄で「オブジェクトサービス」のステータスが緑になっており、各種情報が表示されています。
2022-12-06-17-53-51.png

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

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

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

これに加えて、先ほど「 (1) ベアメタル環境でODFクラスタの作成 」の「ローカルのボリュームセット名 / ストレージクラス名」欄で指定したlocalblockという名前のストレージクラスが作成されています。

[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が作成されていました。

[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 ~]#

[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で指定されている。
[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でのディスクの認識

[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)も同様です。


(補足)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の詳細

[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 ~]#

[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 ~]#

[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 ~]#

[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から作成して使用させる設定をしようと思います。)

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?