手順

1. OpenShift Web コンソールの左側のペインから Administration → Custom Resource Definitions をクリックします。
2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
3. Custom Resource Definition Overview ページで、Actions メニューから View Instances を選択するか、または Instances タブをクリックします。

4. Cluster Logging ページで、Create Cluster Logging をクリックします。

   データを読み込むためにページを更新する必要がある場合があります。

5. YAML でコードを以下に置き換えます。

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: ocs-storagecluster-ceph-rbd
           size: 200G
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         replicas: 1
     curation:
       type: "curator"
       curator:
         schedule: "30 3 * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd: {}

6. 保存 をクリックします。

検証手順

1. Persistent Volume Claim（永続ボリューム要求、PVC）が elasticsearch Pod にバインドされていることを確認します。

   1. Storage → Persistent Volume Claims に移動します。
   2. Project ドロップダウンを openshift-logging に設定します。

   3. Persistent Volume Claim（永続ボリューム要求、PVC）が elasticsearch-* Pod に割り当てられ、Bound (バインド) の状態で表示されることを確認します。

      図2.1 作成済みのバインドされたクラスターロギング

      

2. 新規クラスターロギングが使用されていることを確認します。

   1. Workload → Pods をクリックします。
   2. プロジェクトを openshift-logging に設定します。
   3. 新規の elasticsearch-* Pod が Running 状態で表示されることを確認します。
   4. 新規の elasticsearch-* Pod をクリックし、Pod の詳細を表示します。
   5. Volumes までスクロールダウンし、elasticsearch ボリュームに新規 Persistent Volume Claim (永続ボリューム要求、PVC) に一致する Type があることを確認します (例: elasticsearch-elasticsearch-cdm-9r624biv-3)。
   6. Persistent Volume Claim（永続ボリューム要求、PVC）の名前をクリックし、PersistenVolumeClaim Overview ページでストレージクラス名を確認します。

手順

1. OpenShift Web コンソールに移動します。
2. 左側のナビゲーションバーの Operators をクリックします。
3. Installed Operators を選択します。

4. ウィンドウで、OpenShift Container Storage Operator をクリックします。

   

5. 上部のナビゲーションバーで、右にスクロールし、Storage Cluster タブをクリックします。

   
6. 表示されるリストには 1 つの項目のみが含まれます。右端の (⋮) をクリックして、オプションメニューを拡張します。

7. オプションメニューから Add Capacity を選択します。

   

   ダイアログボックスから、要求される追加容量およびストレージクラスを設定できます。Add capacity には、インストール時に選択された容量が表示され、容量はこの増分値でのみ追加できます。AWS では、ストレージクラスは gp2 に設定する必要があります。VMWare では、ストレージクラスは thin に設定する必要があります。

   注記

   効果的にプロビジョニングされる容量については、OpenShift Container Storage はレプリカ数の 3 を使用するため、Raw Capacity フィールドに入力する値の 3 倍の値にします。

8. Add をクリックします。Ready になると、ストレージクラスターのステータスが表示されます。Ready 状態であることを確認した後に、2 分ほど待機する必要がある場合があります。

検証手順

1. Overview → Persistent Storage タブに移動してから、Capacity breakdown カードをチェックします。

   
2. 容量は選択に応じて増大することに注意してください。

手順

1. OpenShift Container Storage がインストールされている OpenShift Container Platform ノードにストレージ容量を追加するには、以下を実行する必要があります。

   1. ワーカーノードごとに少なくとも 1 つのデバイスを追加するため、利用可能なデバイスの一意の by-id 識別子を見つけます。詳細は、利用可能なストレージデバイスの検索について参照してください。

      注記

      このプロセスを、ストレージを追加する既存ノードのすべて (3 ノード以上) に対して実行するようにしてください。

   2. 一意のデバイス by-id を追加します。

      $ oc edit -n local-storage localvolume local-block

      出力例:

      spec:
        logLevel: Normal
        managementState: Managed
        nodeSelector:
          nodeSelectorTerms:
          - matchExpressions:
            - key: cluster.ocs.openshift.io/openshift-storage
              operator: In
              values:
              - ""
        storageClassDevices:
        - devicePaths:
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402P51P0GGN
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402LM1P0GGN
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402M21P0GGN
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402B71P0GGN    # newly  added device by-id
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402A31P0GGN    # newly  added device by-id
          - /dev/disk/by-id/nvme-INTEL_SSDPE2KX010T7_PHLF733402Q71P0GGN    # newly  added device by-id
          storageClassName: localblock
          volumeMode: Block

      CR の編集後に変更を保存するようにしてください。

      localvolume.local.storage.openshift.io/local-block edited

      この CR に by-id を使用する新規デバイスが追加されていることを確認できます。各デバイスは、3 つのワーカーノードのいずれかで nvme1n1 にマップします。

      • nvme-INTEL_SSDPE2KX010T7_PHLF733402B71P0GGN
      • nvme-INTEL_SSDPE2KX010T7_PHLF733402A31P0GGN
      • nvme-INTEL_SSDPE2KX010T7_PHLF733402Q71P0GGN

2. localVolume CR で使用される storageclass 名と共に PV を表示します。

   $ oc get pv | grep localblock | grep Available

   出力例:

   local-pv-5ee61dcc   894Gi   RWO     Delete  Available   localblock      2m35s
   local-pv-b1fa607a   894Gi   RWO     Delete  Available   localblock      2m27s
   local-pv-e971c51d   894Gi   RWO     Delete  Available   localblock      2m22s
   ...

   新しい OSD に使用されるサイズと同じサイズの 3 つの PV が利用可能です。

3. ストレージ容量を拡張するには、StorageCluster CR の StorageDeviceSets の count を 1 つ増やします。

   $ oc edit storageclusters.ocs.openshift.io -n openshift-storage

   出力例:

   spec:
     monDataDirHostPath: /var/lib/rook
     storageDeviceSets:
     - config: {}
       count: 2    # <-- increase this count by 1
       dataPVCTemplate:
         metadata:
           creationTimestamp: null
         spec:
           accessModes:
           - ReadWriteOnce
           resources:
             requests:
               storage: 894Gi
           storageClassName: localblock
           volumeMode: Block
         status: {}
       name: ocs-deviceset
       placement: {}
       replica: 3
       resources: {}
     version: 4.4.0

   CR の編集後に変更を保存するようにしてください。

   storagecluster.ocs.openshift.io/ocs-storagecluster edited

   重要

   OSD にノード間で保証されたサイズを確保するには、storageDeviceSets のストレージサイズを、ノード上に作成された必要な PV のサイズ以下に指定する必要があります。

4. 3 つの新規 OSD が実行され、それらの対応する新規 PVC が作成されていることを確認します。

   $ oc get -n openshift-storage pods -l app=rook-ceph-osd

   出力例:

   NAME                               READY   STATUS    RESTARTS   AGE
   rook-ceph-osd-0-77c4fdb758-qshw4   1/1     Running   0          1h
   rook-ceph-osd-1-8645c5fbb6-656ks   1/1     Running   0          1h
   rook-ceph-osd-2-86895b854f-r4gt6   1/1     Running   0          1h
   rook-ceph-osd-3-dc7f787dd-gdnsz    1/1     Running   0          10m
   rook-ceph-osd-4-554b5c46dd-hbf9t   1/1     Running   0          10m
   rook-ceph-osd-5-5cf94c4448-k94j6   1/1     Running   0          10m

   上記の例では、osd-3、osd-4、および osd-5 は、新たに OpenShift Container Storage クラスターに追加される Pod です。

   $ oc get pvc -n openshift-storage |grep localblock

   出力例:

   ocs-deviceset-0-0-qc29m   Bound    local-pv-fc5562d3    894Gi   RWO  localblock  1h
   ocs-deviceset-0-1-qdmrl   Bound    local-pv-b1fa607a    894Gi   RWO  localblock  10m
   ocs-deviceset-1-0-mpwmk   Bound    local-pv-58cdd0bc    894Gi   RWO  localblock  1h
   ocs-deviceset-1-1-85892   Bound    local-pv-e971c51d    894Gi   RWO  localblock  10m
   ocs-deviceset-2-0-rll47   Bound    local-pv-29d8ad8d    894Gi   RWO  localblock  1h
   ocs-deviceset-2-1-cgth2   Bound    local-pv-5ee61dcc    894Gi   RWO  localblock  10m

   上記の例では、3 つの新規 PVC が作成されています。

手順

1. Compute → Machine Sets に移動します。
2. ノードを追加する必要のあるマシンセットで、Edit Count を選択します。
3. ノード数を追加し、Save をクリックします。
4. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

5. OpenShift Container Storage ラベルを新規ノードに適用します。

   1. 新規ノードについて、Action menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

手順

1. AWS のユーザーによってプロビジョニングされるインフラストラクチャーまたは VMware のユーザーによってプロビジョニングされるインフラストラクチャーにノードを追加するかどうかに応じて、以下のそれぞれの手順を実行します。

   • AWS の場合:

     1. 必要なインフラストラクチャーで新規 AWS マシンインスタンスを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
     2. 新規 AWS マシンインスタンスを使用して新規 OpenShift Container Platform ノードを作成します。

   • VMware の場合:

     1. 必要なインフラストラクチャーで vSphere に新規の仮想マシンを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
     2. 新規の仮想マシンを使用して新規 OpenShift Container Platform ワーカーノードを作成します。

2. Pending 状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

3. 新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

4. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

5. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

     注記

     異なるゾーンのそれぞれに 3 つのノードを追加することが推奨されます。3 つのノードを追加して、それらすべてのノードに対してこの手順を実行する必要があります。

手順

1. ベアメタル、Amazon EC2、または VMware インフラストラクチャーのどれにノードを追加するかどうかに応じて、以下の手順を実行します。

   • Amazon EC2 の場合

     1. 必要なインフラストラクチャーで新規 Amazon EC2 I3 マシンインスタンスを作成します。AWS での MachineSet の作成、およびサポートされるインフラストラクチャーおよびプラットフォームについて参照してください。
     2. 新規 Amazon EC2 I3 マシンインスタンスを使用して、新規 OpenShift Container Platform ノードを作成します。

   • VMware の場合:

     1. 必要なインフラストラクチャーで vSphere に新規の仮想マシンを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
     2. 新規の仮想マシンを使用して新規 OpenShift Container Platform ワーカーノードを作成します。

   • ベアメタルの場合:

     1. 必要なインフラストラクチャーで新規のベアメタルマシンを取得します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
     2. 新規ベアメタルマシンを使用して新規 OpenShift Container Platform ノードを作成します。

2. Pending 状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

3. 新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

4. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

5. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

     注記

     異なるゾーンのそれぞれに 3 つのノードを追加することが推奨されます。3 つのノードを追加して、それらすべてのノードに対してこの手順を実行する必要があります。

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*

手順

1. OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
2. OpenShift Container Storage Operator をクリックします。

3. OpenShift Container Storage Operator ページで右側にスクロールし、Backing Store タブをクリックします。

   図7.1 バッキングストアタブのある OpenShift Container Storage Operator ページ

   

4. Create Backing Store をクリックします。

   図7.2 Create Backing Store ページ

   

5. Create New Backing Store ページで、以下を実行します。

   1. Backing Store Name を入力します。
   2. Provider を選択します。
   3. Region を選択します。
   4. Endpoint を入力します。これはオプションです。

   5. ドロップダウンリストから Secret を選択するか、または独自のシークレットを作成します。オプションで、Switch to Credentials ビューを選択すると、必要なシークレットを入力できます。

      OCP シークレットの作成に関する詳細は、Openshift Container Platform ドキュメントの「シークレットの作成」を参照してください。

      バッキングストアごとに異なるシークレットが必要です。特定のバッキングストアのシークレット作成についての詳細は 「MCG コマンドラインインターフェースを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加」 を参照して、YAML を使用したストレージリソースの追加についての手順を実行します。

      注記

      このメニューは、Google Cloud およびローカル PVC 以外のすべてのプロバイダーに関連します。

   6. Target bucket を入力します。ターゲットバケットは、リモートクラウドサービスでホストされるコンテナーストレージです。MCG に対してシステム用にこのバケットを使用できることを通知する接続を作成できます。
6. Create Backing Store をクリックします。

検証手順

1. Operators → Installed Operators をクリックします。
2. OpenShift Container Storage Operator をクリックします。
3. 新しいバッキングストアを検索するか、または Backing Store タブをクリックし、すべてのバッキングストアを表示します。

手順

1. Multicloud Object Gateway (MCG) コマンドラインインターフェースから、以下の NooBaa コマンドを実行します。

   noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=http://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local:80

   1. <RGW ACCESS KEY> および <RGW SECRET KEY> を取得するには、RGW ユーザーシークレット名を使用して以下のコマンドを実行します。

      oc get secret <RGW USER SECRET NAME> -o yaml

   2. Base64 からアクセスキー ID とアクセスキーをデコードし、それらのキーを保持します。
   3. <RGW USER ACCESS KEY> と <RGW USER SECRET ACCESS KEY> を、直前の手順でデコードした適切なデータに置き換えます。

   4. <bucket-name> を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

      出力は次のようになります。

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "rgw-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"

1. CephObjectStore ユーザーを作成します。これにより、RGW 認証情報が含まれるシークレットも作成されます。

   apiVersion: ceph.rook.io/v1
   kind: CephObjectStoreUser
   metadata:
     name: <RGW-Username>
     namespace: openshift-storage
   spec:
     store: ocs-storagecluster-cephobjectstore
     displayName: "<Display-name>"

   1. <RGW-Username> と <Display-name> を、一意のユーザー名および表示名に置き換えます。

2. 以下の YAML を S3 と互換性のあるバッキングストアについて適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <backingstore-name>
     namespace: openshift-storage
   spec:
     s3Compatible:
       endpoint: http://rook-ceph-rgw-ocs-storagecluster-cephobjectstore.openshift-storage.svc.cluster.local:80
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       signatureVersion: v4
       targetBucket: <RGW-bucket-name>
     type: s3-compatible

   1. <backingstore-secret-name> を、直前の手順で CephObjectStore で作成したシークレットの名前に置き換えます。
   2. <bucket-name> を既存の RGW バケット名に置き換えます。この引数は、Multicloud Object Gateway に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

手順

1. OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。

   

2. 以下に強調表示されているように左側にある Resources タブを選択します。設定する一覧から、Add Cloud Resource を選択します。

   

3. Add new connection を選択します。

   

4. 関連するネイティブクラウドプロバイダーまたは S3 互換オプションを選択し、詳細を入力します。

   

5. 新規に作成された接続を選択し、これを既存バケットにマップします。

   
6. これらの手順を繰り返して、必要な数のバッキングストアを作成します。

手順

1. OpenShift Web コンソールの左側のペインで Operators → Installed Operators をクリックし、インストールされた Operator を表示します。
2. OpenShift Container Storage Operator をクリックします。

3. OpenShift Container Storage Operator ページで右側にスクロールし、Bucket Class タブをクリックします。

   図7.3 Bucket Class タブのある OpenShift Container Storage Operator ページ

   
4. Create Bucket Class をクリックします。

5. Create new Bucket Class ページで、以下を実行します。

   1. Bucket Class Name を入力し、Next をクリックします。

      図7.4 Create Bucket Class ページ

      

   2. Placement Policy で Tier 1 - Policy Type を選択し、Next をクリックします。要件に応じて、いずれかのオプションを選択できます。

      • Spread により、選択したリソース全体にデータを分散できます。
      • Mirror により、選択したリソース全体でデータを完全に複製できます。

      • Add Tier をクリックし、別のポリシー階層を追加します。

        図7.5 階層 1 - Policy Type 選択ページ

        

   3. 「Tier 1 - Policy Type」で「Spread」 を選択した場合、利用可能な一覧から 1 つ以上の Backing Store リソースを選択してから、Next をクリックします。または、新規バッキングストアを作成することもできます。

      図7.6 階層 1 - Baking Store 選択ページ

      

1. Bucket Class 設定を確認し、確認します。

   図7.7 バケットクラス設定の確認ページ

   
2. Create Bucket Class をクリックします。

検証手順

1. Operators → Installed Operators をクリックします。
2. OpenShift Container Storage Operator をクリックします。
3. 新しい Bucket Class を検索するか、または Bucket Class タブをクリックし、すべての Bucket Class を表示します。

1. MCG コマンドラインインターフェースから以下のコマンドを実行し、ミラーリングポリシーでバケットクラスを作成します。

   $ noobaa bucketclass create mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror

2. 新たに作成されたバケットクラスを新規のバケット要求に設定し、2 つのロケーション間でミラーリングされる新規バケットを生成します。

   $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

1. 以下の YAML を適用します。この YAML は、ローカル Ceph ストレージと AWS 間でデータをミラーリングするハイブリッドの例です。

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     name: hybrid-class
     labels:
       app: noobaa
   spec:
     placementPolicy:
       tiers:
         - tier:
             mirrors:
               - mirror:
                   spread:
                     - cos-east-us
               - mirror:
                   spread:
                     - noobaa-test-bucket-for-ocp201907291921-11247_resource

2. 以下の行を標準の Object Bucket Claim (オブジェクトバケット要求、OBC) に追加します。

   additionalConfig:
     bucketclass: mirror-to-aws

   OBC についての詳細は、「Object Bucket Claim（オブジェクトバケット要求）」を参照してください。

1. OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。

   

2. 左側の buckets アイコンをクリックします。バケットの一覧が表示されます。

   
3. 更新するバケットをクリックします。

4. Edit Tier 1 Resources をクリックします。

   

5. Mirror を選択し、このバケットに使用する関連リソースを確認します。以下の例では、prem Ceph RGW と AWS 間でデータのミラーリングをします。

   
6. 保存 をクリックします。

1. JSON 形式でバケットポリシーを作成します。以下の例を参照してください。

   {
       "Version": "NewVersion",
       "Statement": [
           {
               "Sid": "Example",
               "Effect": "Allow",
               "Principal": [
                       "john.doe@example.com"
               ],
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::john_bucket"
               ]
           }
       ]
   }

   バケットポリシーには数多くの利用可能な要素があります。それらの構成要素および使用方法についての詳細は、「AWS Access Policy Language Overview」を参照してください。

   バケットポリシーの他の例については、「AWS Bucket Policy Examples」を参照してください。

   S3 ユーザーの作成手順は、「Multicloud Object Gateway での AWS S3 ユーザーの作成」 を参照してください。

2. AWS S3 クライアントを使用して put-bucket-policy コマンドを使用してバケットポリシーを S3 バケットに適用します。

   # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy

   ENDPOINT を S3 エンドポイントに置き換えます。

   MyBucket を、ポリシーを設定するバケットに置き換えます。

   BucketPolicy をバケットポリシー JSON ファイルに置き換えます。

   デフォルトの自己署名証明書を使用している場合は、--no-verify-ssl を追加します。

   以下に例を示します。

   # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

   put-bucket-policy コマンドについての詳細は、「AWS CLI Command Reference for put-bucket-policy」を参照してください。

手順

1. OpenShift Storage コンソールで、Overview → Object Service → に移動し、noobaa リンクを選択します。

   

2. Accounts タブで、Create Account をクリックします。

   

3. S3 Access Only を選択し、Account Name を指定します (例: john.doe@example.com)。Next をクリックします。

   

4. S3 default placement を選択します (例: noobaa-default-backing-store)。Buckets Permissions を選択します。特定のバケットまたはすべてのバケットを選択できます。Create をクリックします。

   

手順

1. 以下の行をアプリケーション YAML に追加します。

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <obc-name>
   spec:
     generateBucketName: <obc-bucket-name>
     storageClassName: noobaa

   これらの行は Object Bucket Claim（オブジェクトバケット要求）自体になります。

   1. <obc-name> を、一意の Object Bucket Claim（オブジェクトバケット要求）の名前に置き換えます。
   2. <obc-bucket-name> を、Object Bucket Claim（オブジェクトバケット要求）の一意のバケット名に置き換えます。

2. YAML ファイルにさらに行を追加して、Object Bucket Claim（オブジェクトバケット要求）の使用を自動化できます。以下の例はバケット要求の結果のマッピングです。これは、データを含む設定マップおよび認証情報のあるシークレットです。この特定のジョブは NooBaa からオブジェクトバケットを要求し、バケットとアカウントを作成します。

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: testjob
   spec:
     template:
       spec:
         restartPolicy: OnFailure
         containers:
           - image: <your application image>
             name: test
             env:
               - name: BUCKET_NAME
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_NAME
               - name: BUCKET_HOST
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_HOST
               - name: BUCKET_PORT
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_PORT
               - name: AWS_ACCESS_KEY_ID
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_ACCESS_KEY_ID
               - name: AWS_SECRET_ACCESS_KEY
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_SECRET_ACCESS_KEY

   1. <obc-name> のすべてのインスタンスを、Object Bucket Claim（オブジェクトバケット要求）の名前に置き換えます。
   2. <your application image> をアプリケーションイメージに置き換えます。

3. 更新された YAML ファイルを適用します。

   # oc apply -f <yaml.file>

   1. <yaml.file> を YAML ファイルの名前に置き換えます。

4. 新しい設定マップを表示するには、以下を実行します。

   # oc get cm <obc-name>

   1. obc-name を、Object Bucket Claim（オブジェクトバケット要求）の名前に置き換えます。

      出力には、以下の環境変数が表示されることが予想されます。

      • BUCKET_HOST: アプリケーションで使用するエンドポイント

      • BUCKET_PORT: アプリケーションで利用できるポート

        • ポートは BUCKET_HOST に関連します。たとえば、BUCKET_HOST が https://my.example.com で、BUCKET_PORT が 443 の場合、オブジェクトサービスのエンドポイントは https://my.example.com:443 になります。
      • BUCKET_NAME: 要求されるか、または生成されるバケット名
      • AWS_ACCESS_KEY_ID: 認証情報の一部であるアクセスキー
      • AWS_SECRET_ACCESS_KEY: 認証情報の一部であるシークレットのアクセスキー

手順

1. コマンドラインインターフェースを使用して、新規バケットおよび認証情報の詳細を生成します。以下のコマンドを実行します。

   # noobaa obc create <obc-name> -n openshift-storage

   <obc-name> を一意の Object Bucket Claim（オブジェクトバケット要求）の名前に置き換えます (例: myappobc)。

   さらに、--app-namespace オプションを使用して、Object Bucket Claim（オブジェクトバケット要求）設定マップおよびシークレットが作成される namespace を指定できます(例: myapp-namespace)。

   出力例:

   INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

   MCG コマンドラインインターフェースが必要な設定を作成し、新規 OBC について OpenShift に通知します。

2. 以下のコマンドを実行して Object Bucket Claim（オブジェクトバケット要求）を表示します。

   # oc get obc -n openshift-storage

   出力例:

   NAME        STORAGE-CLASS                 PHASE   AGE
   test21obc   openshift-storage.noobaa.io   Bound   38s

3. 以下のコマンドを実行して、新規 Object Bucket Claim（オブジェクトバケット要求）の YAML ファイルを表示します。

   # oc get obc test21obc -o yaml -n openshift-storage

   出力例:

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     generation: 2
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     resourceVersion: "40756"
     selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
     uid: 64f04cba-f662-11e9-bc3c-0295250841af
   spec:
     ObjectBucketName: obc-openshift-storage-test21obc
     bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     generateBucketName: test21obc
     storageClassName: openshift-storage.noobaa.io
   status:
     phase: Bound

4. openshift-storage namespace 内で、設定マップおよびシークレットを見つけ、この Object Bucket Claim（オブジェクトバケット要求）を使用することができます。CM とシークレットの名前はこの Object Bucket Claim（オブジェクトバケット要求）の名前と同じです。シークレットを表示するには、以下を実行します。

   # oc get -n openshift-storage secret test21obc -o yaml

   出力例:

   Example output:
   apiVersion: v1
   data:
     AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
     AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
   kind: Secret
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40751"
     selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
     uid: 65117c1c-f662-11e9-9094-0a5305de57bb
   type: Opaque

   シークレットは S3 アクセス認証情報を提供します。

5. 設定マップを表示するには、以下を実行します。

   # oc get -n openshift-storage cm test21obc -o yaml

   出力例:

   apiVersion: v1
   data:
     BUCKET_HOST: 10.0.171.35
     BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     BUCKET_PORT: "31242"
     BUCKET_REGION: ""
     BUCKET_SUBREGION: ""
   kind: ConfigMap
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40752"
     selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
     uid: 651c6501-f662-11e9-9094-0a5305de57bb

   設定マップには、アプリケーションの S3 エンドポイント情報が含まれます。

手順

1. OpenShift Web コンソールにログインします。
2. 左側のナビゲーションバーで Storage → Object Bucket Claims をクリックします。

3. 以下のウィンドウで、Create Object Bucket Claim をクリックします。

   

4. 以下のウィンドウで、Object Bucket Claim（オブジェクトバケット要求）の名前を入力し、ドロップダウンメニューから適切なストレージクラスとバケットクラスを選択します。

   

5. Create をクリックします。

   OBC が作成されると、その詳細ページにリダイレクトされます。

   

6. OBC の作成後に、これをデプロイメントに割り当てることができます。

   1. 左側のナビゲーションバーで Storage → Object Bucket Claims をクリックします。
   2. 作成した OBC の横にあるアクションメニュー (✓) をクリックします。

   3. ドロップダウンメニューで、Attach to Deployment を選択します。

      

   4. 以下のウィンドウで、ドロップダウンメニューから必要なデプロイメントを選択してから Attach をクリックします。

      

手順

1. Mult-Cloud Object Gateway ユーザーインターフェースの Overview ページで、 Add Storage Resources をクリックします。

   

2. ウィンドウから Deploy Kubernetes Pool をクリックします。

   

3. Create Pool 手順で、今後インストールされるノードのターゲットプールを作成します。

   

4. Configure 手順で、要求される Pod 数と各 PV のサイズを設定します。新規 Pod ごとに、1 つの PV が作成されます。

   
5. Review 手順で、新規プールの詳細を検索し、ローカルまたは外部デプロイメントのいずれかの使用するデプロイメント方法を選択します。ローカルデプロイメントが選択されている場合、Kubernetes ノードはクラスター内にデプロイされます。外部デプロイメントが選択されている場合、外部で実行するための YAML ファイルが提供されます。

6. すべてのノードは最初の手順で選択したプールに割り当てられ、Resources → Storage resources → Resource name の下で確認できます。

   

手順

1. 置き換える必要のあるノードを特定します。

2. 以下のコマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

3. 以下のコマンドを使用してノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   重要

   このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。

4. 以下のコマンドを使用してノードを削除します。

   $ oc delete nodes <node_name>

5. 必要なインフラストラクチャーで新規 AWS マシンインスタンスを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
6. 新規 AWS マシンインスタンスを使用して新規 OpenShift Container Platform ノードを作成します。

7. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

8. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

9. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

10. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合

    1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェースの使用

    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. 置き換える必要のあるノードの AWS マシンインスタンスを特定します。
2. AWS にログインし、特定された AWS マシンインスタンスを終了します。
3. 必要なインフラストラクチャーで新規 AWS マシンインスタンスを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
4. 新規 AWS マシンインスタンスを使用して新規 OpenShift Container Platform ノードを作成します。

5. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

6. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

7. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

8. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順に失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
2. 置き換える必要のあるノードを特定します。その マシン名 をメモします。

3. 以下のコマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

4. 以下のコマンドを使用してノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   重要

   このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。

5. Compute → Machines をクリックします。必要なマシンを検索します。
6. 必要なマシンの横にある Action menu (⋮) → Delete Machine をクリックします。
7. Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。

8. 新規マシンが起動し、Running 状態に移行するまで待機します。

   重要

   このアクティビティーには少なくとも 5-10 分以上かかる場合があります。

9. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

10. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合

    1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェースの使用

    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. OpenShift Web コンソールにログインし、Compute → Nodes をクリックします。
2. 障害のあるノードを特定し、その Machine Name をクリックします。
3. Actions → Edit Annotations をクリックし、Add More をクリックします。
4. machine.openshift.io/exclude-node-draining を追加し、Save をクリックします。
5. Actions → Delete Machine をクリックしてから、Delete をクリックします。

6. 新しいマシンが自動的に作成されます。新規マシンが起動するのを待機します。

   重要

   このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。

7. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

8. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

9. [オプション]: 失敗した AWS インスタンスが自動的に削除されない場合、インスタンスを AWS コンソールで終了します。

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. 置き換える必要があるノードとその仮想マシンを特定します。

2. 以下のコマンドを実行して、ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

3. 以下のコマンドを使用してノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   重要

   このアクティビティーには少なくとも 5-10 分以上かかる場合があります。この期間に生成される Ceph のエラーは一時的なもので、新規ノードにラベルが付けられ、これが機能すると自動的に解決されます。

4. 以下のコマンドを使用してノードを削除します。

   $ oc delete nodes <node_name>

5. VSphere にログインし、特定された仮想マシンを終了します。

   重要

   仮想マシンはインベントリーからのみ削除し、ディスクから削除しないでください。

6. 必要なインフラストラクチャーで vSphere に新規の仮想マシンを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
7. 新規の仮想マシンを使用して新規 OpenShift Container Platform ワーカーノードを作成します。

8. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

9. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

10. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

11. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合

    1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェースの使用

    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. 置き換える必要があるノードとその仮想マシンを特定します。

2. 以下のコマンドを使用してノードを削除します。

   $ oc delete nodes <node_name>

3. VSphere にログインし、特定された仮想マシンを終了します。

   重要

   仮想マシンはインベントリーからのみ削除し、ディスクから削除しないでください。

4. 必要なインフラストラクチャーで vSphere に新規の仮想マシンを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
5. 新規の仮想マシンを使用して新規 OpenShift Container Platform ワーカーノードを作成します。

6. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

7. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

   $ oc adm certificate approve <Certificate_Name>

8. Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

9. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*
3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。
4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. ノードを特定し、置き換えるノードのラベルを取得します。

   $ oc get nodes --show-labels | grep <node_name>

2. 置き換えるノードで実行されている mon (ある場合) および OSD を特定します。

   $ oc get pods -n openshift-storage -o wide | grep -i <node_name>

3. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

   以下に例を示します。

   $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
   $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
   $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage

4. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

5. ノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   注記

   障害が発生したノードがネットワークに接続されていない場合には、以下のコマンドを使用してそのノードで実行されている Pod を削除します。

   $ oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

6. 障害のあるノードを削除します。

   1. インストーラーでプロビジョニングされるインフラストラクチャーの場合は、障害が発生しているノードに対応するマシンを削除します。新しいノードが自動的に追加されます。

      1. Compute → Machines をクリックします。必要なマシンを検索します。
      2. 必要なマシンの横にある Action メニュー (⋮)→ Delete Machine をクリックします。
      3. Delete をクリックしてマシンの削除を確認します。新しいマシンが自動的に作成されます。

      4. 新規マシンが起動し、Running 状態に移行するまで待機します。

         重要

         このアクティビティーには少なくとも 5-10 分以上かかる場合があります。

   2. ユーザーによってプロビジョニングされるインフラストラクチャーの場合は、以下の手順に従ってください。

      1. ノードを削除します。

         $ oc delete node <node_name>

      2. 必要なインフラストラクチャーで新規 Amazon EC2 I3 マシンインスタンスを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
      3. 新規 Amazon EC2 I3 マシンインスタンスを使用して新規 OpenShift Container Platform ノードを作成します。

      4. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

         $ oc get csr

      5. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

         $ oc adm certificate approve <Certificate_Name>

   3. [オプション]: 失敗した AWS インスタンスが自動的に削除されない場合、インスタンスを AWS コンソールで終了します。
7. OpenShift Web コンソールで Compute → Nodes をクリックします。新規ノードが Ready 状態かどうかを確認します。

8. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

   ユーザーインターフェースを使用する場合

   1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
   2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

   コマンドラインインターフェースの使用

   • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

     $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

9. 新規ワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。

   1. 新規ディスクエントリーを LocalVolume CR に追加します。

      LocalVolume CR を編集します。障害のあるデバイス /dev/disk/by-id/{id} を削除またはコメントアウトし、新規の /dev/disk/by-id/{id} を追加します。

      $ oc get -n local-storage localvolume
      NAME          AGE
      local-block   25h

      $ oc edit -n local-storage localvolume local-block

      出力例:

      [...]
          storageClassDevices:
          - devicePaths:
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS10382E5D7441494EC
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS1F45C01D7E84FE3E9
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS136BC945B4ECB9AE4
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS10382E5D7441464EP
        #   - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS1F45C01D7E84F43E7
        #   - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS136BC945B4ECB9AE8
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS6F45C01D7E84FE3E9
            - /dev/disk/by-id/nvme-Amazon_EC2_NVMe_Instance_Storage_AWS636BC945B4ECB9AE4
            storageClassName: localblock
            volumeMode: Block
      [...]

      CR の編集後に変更を保存するようにしてください。

      この CR に by-id を使用する 2 つの新規デバイスが追加されていることを確認できます。

      • nvme-Amazon_EC2_NVMe_Instance_Storage_AWS6F45C01D7E84FE3E9
      • nvme-Amazon_EC2_NVMe_Instance_Storage_AWS636BC945B4ECB9AE4

   2. localblock と共に PV を表示します。

      $ oc get pv | grep localblock

      出力例:

      local-pv-3646185e   2328Gi  RWO     Delete      Available                                               localblock  9s
      local-pv-3933e86    2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-2-1-v9jp4   localblock  5h1m
      local-pv-8176b2bf   2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-0-0-nvs68   localblock  5h1m
      local-pv-ab7cabb3   2328Gi  RWO     Delete      Available                                               localblock  9s
      local-pv-ac52e8a    2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-1-0-knrgr   localblock  5h1m
      local-pv-b7e6fd37   2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-2-0-rdm7m   localblock  5h1m
      local-pv-cb454338   2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-0-1-h9hfm   localblock  5h1m
      local-pv-da5e3175   2328Gi  RWO     Delete      Bound       openshift-storage/ocs-deviceset-1-1-g97lq   localblock  5h
      ...

10. 以下の手順で、失敗したノードに関連付けられた各 PV および OSD を削除します。

    1. 置き換える OSD に関連付けられた DeviceSet を特定します。

       $ osd_id_to_remove=0
       $ oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc

       ここで、osd_id_to_remove は rook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

       出力例:

       ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68
           ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68

    2. PVC に関連付けられた PV を特定します。

       $ oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

       ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

       出力例:

       NAME                      STATUS        VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
       ocs-deviceset-0-0-nvs68   Bound   local-pv-8176b2bf   2328Gi      RWO            localblock     4h49m

       この例では、関連付けられた PV は local-pv-8176b2bf です。

    3. 先の手順で特定された PVC を削除します。この例では、PVC 名は ocs-deviceset-0-0-nvs68 です。

       $ oc delete pvc ocs-deviceset-0-0-nvs68 -n openshift-storage

       出力例:

       persistentvolumeclaim "ocs-deviceset-0-0-nvs68" deleted

    4. 先のステップで特定された PV を削除します。この例では、PV 名は local-pv-8176b2bf です。

       $ oc delete pv local-pv-8176b2bf

       出力例:

       persistentvolume "local-pv-8176b2bf" deleted

    5. 失敗した OSD をクラスターから削除します。

       $ oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_ID=${osd_id_to_remove} | oc create -f -

    6. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

       # oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage

       注記

       ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

       # oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1

    7. OSD Pod デプロイメントを削除します。

       $ oc delete deployment rook-ceph-osd-${osd_id_to_remove} -n openshift-storage

11. 先の手順で特定された crashcollector Pod デプロイメントを削除します。

    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<old_node_name> -n openshift-storage

12. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

    $ oc get -n openshift-storage pod -l app=rook-ceph-operator

    出力例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          5h3m

    1. rook-ceph-operator を削除します。

       $ oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

       出力例:

       pod "rook-ceph-operator-6f74fb5bff-2d982" deleted

    2. rook-ceph-operator Pod が再起動していることを確認します。

       $ oc get -n openshift-storage pod -l app=rook-ceph-operator

       出力例:

       NAME                                  READY   STATUS    RESTARTS   AGE
       rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

       新規 OSD の作成には、Operator が起動するまでに数分かかる場合があります。

13. ocs-osd-removal ジョブを削除します。

    $ oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" deleted

検証手順

1. 以下のコマンドを実行して、出力で新規ノードが表示されていることを確認します。

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Workloads → Pods をクリックし、新規ノード上の少なくとも以下の Pod が Running 状態にあることを確認します。

   • csi-cephfsplugin-*
   • csi-rbdplugin-*

3. 他の必要なすべての OpenShift Container Storage Pod が Running 状態にあることを確認します。

   また、増分の mon が新規に作成されており、Running 状態にあることを確認します。

   $ oc get pod -n openshift-storage | grep mon

   出力例:

   rook-ceph-mon-a-64556f7659-c2ngc    1/1     Running     0   5h1m
   rook-ceph-mon-b-7c8b74dc4d-tt6hd    1/1     Running     0   5h1m
   rook-ceph-mon-d-57fb8c657-wg5f2     1/1     Running     0   27m

   OSD と mon が Running 状態になるまで数分かかる場合があります。

4. 検証手順が失敗した場合は、Red Hat サポートにお問い合わせください。

手順

1. ノードを特定し、置き換えるノードのラベルを取得します。

   $ oc get nodes --show-labels | grep <node_name>

2. 置き換えるノードで実行されている mon (ある場合) および OSD を特定します。

   $ oc get pods -n openshift-storage -o wide | grep -i <node_name>

3. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

   以下に例を示します。

   $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
   $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
   $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage

4. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

5. ノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   注記

   障害が発生したノードがネットワークに接続されていない場合には、以下のコマンドを使用してそのノードで実行されている Pod を削除します。

   $ oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

6. ノードを削除します。

   $ oc delete node <node_name>

7. 必要なインフラストラクチャーで VMware に新規の仮想マシンを作成します。サポートされているインフラストラクチャーおよびプラットフォームについて参照してください。
8. 新規の仮想マシンを使用して新規 OpenShift Container Platform ワーカーノードを作成します。

9. Pending 状態の OpenShift Container Platform に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

10. 新規ノードに必要なすべての OpenShift Container Platform CSR を承認します。

    $ oc adm certificate approve <Certificate_Name>

11. OpenShift Web コンソールで Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

12. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合

    1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェースの使用

    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

13. これらのワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。

    1. 新規ディスクエントリーを LocalVolume CR に追加します。

       LocalVolume CR を編集し、障害のあるデバイス /dev/disk/by-id/{id} を削除またはコメントアウトし、新規の /dev/disk/by-id/{id} を追加します。この例では、新規デバイスは /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1 です。

       # oc get -n local-storage localvolume
       NAME          AGE
       local-block   25h

       # oc edit -n local-storage localvolume local-block

       出力例:

       [...]
           storageClassDevices:
           - devicePaths:
             - /dev/disk/by-id/scsi-36000c29346bca85f723c4c1f268b5630
             - /dev/disk/by-id/scsi-36000c29134dfcfaf2dfeeb9f98622786
         #   - /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237
             - /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1
             storageClassName: localblock
             volumeMode: Block
       [...]

       CR の編集後に変更を保存するようにしてください。

    2. localblock と共に PV を表示します。

       $ oc get pv | grep localblock

       出力例:

       local-pv-3e8964d3                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-2-0-79j94   localblock                             25h
       local-pv-414755e0                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-1-0-959rp   localblock                             25h
       local-pv-b481410                           100Gi      RWO            Delete           Available                                               localblock                             3m24s
       local-pv-d9c5cbd6                          100Gi      RWO            Delete           Bound     openshift-storage/ocs-deviceset-0-0-nvs68   localblock

14. 障害のあるノードに関連付けられた PV を削除します。

    1. 置き換える OSD に関連付けられた DeviceSet を特定します。

       # osd_id_to_remove=0
       # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc

       ここで、osd_id_to_remove は rook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

       出力例:

       ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68
           ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68

       この例では、PVC 名は OCS-deviceset-0-0-nvs68 です。

    2. PVC に関連付けられた PV を特定します。

       # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

       ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

       出力例:

       NAME                      STATUS        VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
       ocs-deviceset-0-0-nvs68   Bound   local-pv-d9c5cbd6   100Gi      RWO            localblock     24h

       この例では、関連付けられた PV は local-pv-d9c5cbd6 です。

    3. PVC を削除します。

       oc delete pvc <pvc-name> -n openshift-storage

    4. PV を削除します。

       # oc delete pv local-pv-d9c5cbd6

       出力例:

       persistentvolume "local-pv-d9c5cbd6" deleted

15. 失敗した OSD をクラスターから削除します。

    # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_ID=${osd_id_to_remove} | oc create -f -

16. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

    # oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage

    注記

    ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

    # oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1

17. OSD Pod デプロイメントおよび crashcollector Pod デプロイメントを削除します。

    $ oc delete deployment rook-ceph-osd-${osd_id_to_remove} -n openshift-storage
    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<old_node_name> -n openshift-storage

18. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    出力例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h

    1. rook-ceph-operator を削除します。

       # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

       出力例:

       pod "rook-ceph-operator-6f74fb5bff-2d982" deleted

    2. rook-ceph-operator Pod が再起動していることを確認します。

       # oc get -n openshift-storage pod -l app=rook-ceph-operator

       出力例:

       NAME                                  READY   STATUS    RESTARTS   AGE
       rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

       新規 OSD および mon の作成には、Operator が再起動するまでに数分かかる場合があります。

19. ocs-osd-removal ジョブを削除します。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" deleted

手順

1. ノードを特定し、置き換えるノードのラベルを取得します。ラックラベルをメモします。

   $ oc get nodes --show-labels | grep <node_name>

2. 置き換えるノードで実行されている mon（ある場合）およびオブジェクトストレージデバイス (OSD) Pod を特定します。

   $ oc get pods -n openshift-storage -o wide | grep -i <node_name>

3. 先の手順で特定された Pod のデプロイメントをスケールダウンします。

   以下に例を示します。

   $ oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage
   $ oc scale deployment rook-ceph-osd-0 --replicas=0 -n openshift-storage
   $ oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=<node_name>  --replicas=0 -n openshift-storage

4. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

   $ oc adm cordon <node_name>

5. ノードをドレイン (解放) します。

   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

   注記

   障害が発生したノードがネットワークに接続されていない場合には、以下のコマンドを使用してそのノードで実行されている Pod を削除します。

   $ oc get pods -A -o wide | grep -i <node_name> |  awk '{if ($4 == "Terminating") system ("oc -n " $1 " delete pods " $2  " --grace-period=0 " " --force ")}'
   $ oc adm drain <node_name> --force --delete-local-data --ignore-daemonsets

6. ノードを削除します。

   $ oc delete node <node_name>

7. 必要なインフラストラクチャーで新規のベアメタルマシンを取得します。『クラスターのベアメタルへのインストール』を参照してください。
8. 新規ベアメタルマシンを使用して新規 OpenShift Container Platform ノードを作成します。

9. Pending 状態の OpenShift Container Storage に関連する証明書署名要求 (CSR) の有無を確認します。

   $ oc get csr

10. 新規ノードに必要なすべての OpenShift Container Storage CSR を承認します。

    $ oc adm certificate approve <Certificate_Name>

11. OpenShift Web コンソールで Compute → Nodes をクリックし、新規ノードが Ready 状態にあることを確認します。

12. 以下のいずれかを使用して、OpenShift Container Storage ラベルを新規ノードに適用します。

    ユーザーインターフェースを使用する場合

    1. 新規ノードについて、Action Menu (⋮) → Edit Labels をクリックします。
    2. cluster.ocs.openshift.io/openshift-storage を追加し、Save をクリックします。

    コマンドラインインターフェースの使用

    • 以下のコマンドを実行して、OpenS+hift Container Storage ラベルを新規ノードに適用します。

      $ oc label node <new_node_name> cluster.ocs.openshift.io/openshift-storage=""

13. これらのワーカーノードで利用可能なローカルストレージデバイスを OpenShift Container Storage StorageCluster に追加します。

    1. 新規ディスクエントリーを LocalVolume CR に追加します。

       LocalVolume CR を編集し、障害のあるデバイス /dev/disk/by-id/{id} を削除またはコメントアウトし、新規の /dev/disk/by-id/{id} を追加します。この例では、新規デバイスは /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1 です。

       # oc get -n local-storage localvolume
       NAME          AGE
       local-block   25h

       # oc edit -n local-storage localvolume local-block

       出力例:

       [...]
           storageClassDevices:
           - devicePaths:
             - /dev/disk/by-id/scsi-36000c29346bca85f723c4c1f268b5630
             - /dev/disk/by-id/scsi-36000c29134dfcfaf2dfeeb9f98622786
         #   - /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237
             - /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1
             storageClassName: localblock
             volumeMode: Block
       [...]

       CR の編集後に変更を保存するようにしてください。

    2. localblock と共に PV を表示します。

       $ oc get pv | grep localblock

       出力例:

       local-pv-3e8964d3                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-2-0-79j94   localblock                             25h
       local-pv-414755e0                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-1-0-959rp   localblock                             25h
       local-pv-b481410                           100Gi      RWO            Delete           Available                                               localblock                             3m24s
       local-pv-d9c5cbd6                          100Gi      RWO            Delete           Bound    openshift-storage/ocs-deviceset-0-0-nvs68   localblock

14. 障害のあるノードに関連付けられた PV を削除します。

    1. 置き換える OSD に関連付けられた DeviceSet を特定します。

       # osd_id_to_remove=0
       # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc

       ここで、osd_id_to_remove は rook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

       出力例:

       ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68
           ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68

       この例では、PVC 名は OCS-deviceset-0-0-nvs68 です。

    2. PVC に関連付けられた PV を特定します。

       # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

       ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

       出力例:

       NAME                      STATUS        VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
       ocs-deviceset-0-0-nvs68   Bound   local-pv-d9c5cbd6   100Gi      RWO            localblock     24h

       この例では、関連付けられた PV は local-pv-d9c5cbd6 です。

    3. PVC を削除します。

       oc delete pvc <pvc-name> -n openshift-storage

    4. PV を削除します。

       # oc delete pv local-pv-d9c5cbd6

       出力例:

       persistentvolume "local-pv-d9c5cbd6" deleted

15. 失敗した OSD をクラスターから削除します。

    # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_ID=${osd_id_to_remove} | oc create -f -

16. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

    # oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage

    注記

    ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

    # oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1

17. OSD Pod デプロイメントおよび crashcollector Pod デプロイメントを削除します。

    $ oc delete deployment rook-ceph-osd-${osd_id_to_remove} -n openshift-storage
    $ oc delete deployment --selector=app=rook-ceph-crashcollector,node_name=<old_node_name> -n openshift-storage

18. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

    # oc get -n openshift-storage pod -l app=rook-ceph-operator

    出力例:

    NAME                                  READY   STATUS    RESTARTS   AGE
    rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h

    1. rook-ceph-operator を削除します。

       # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

       出力例:

       pod "rook-ceph-operator-6f74fb5bff-2d982" deleted

    2. rook-ceph-operator Pod が再起動していることを確認します。

       # oc get -n openshift-storage pod -l app=rook-ceph-operator

       出力例:

       NAME                                  READY   STATUS    RESTARTS   AGE
       rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

       新規 OSD および mon の作成には、Operator が再起動するまでに数分かかる場合があります。

19. ocs-osd-removal ジョブを削除します。

    # oc delete job ocs-osd-removal-${osd_id_to_remove}

    出力例:

    job.batch "ocs-osd-removal-0" deleted

手順

1. 置き換える必要のある OSC を特定します。

   # oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide

   出力例:

   rook-ceph-osd-0-6d77d6c7c6-m8xj6    0/1    CrashLoopBackOff    0    24h   10.129.0.16   compute-2   <none>           <none>
   rook-ceph-osd-1-85d99fb95f-2svc7    1/1    Running    0    24h   10.128.2.24   compute-0   <none>           <none>
   rook-ceph-osd-2-6c66cdb977-jp542    1/1    Running    0    24h   10.131.2.32   compute-1   <none>           <none>

   この例では、rook-ceph-osd-0-6d77d6c7c6-m8xj6 を置き換える必要があります。

   注記

   置き換える OSD が正常であれば、Pod のステータスは Running になります。

2. 置き換えられる OSD のデプロイメントをスケールダウンします。

   # osd_id_to_remove=0
   # oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0

   ここで、osd_id_to_remove は rook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

   出力例:

   deployment.extensions/rook-ceph-osd-0 scaled

3. rook-ceph-osd Pod が停止していることを確認します。

   # oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}

   出力例:

   No resources found.

   注記

   rook-ceph-osd Pod が terminating 状態にある場合は、force オプションを使用して Pod を削除します。

   # oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --force --grace-period=0

   出力例:

   warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
     pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted

4. 新規 OSD を追加できるようにクラスターから古い OSD を削除します。

   # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_ID=${osd_id_to_remove} | oc create -f -

   警告

   この手順により、OSD はクラスターから完全に削除されます。osd_id_to_remove の正しい値が指定されていることを確認します。

5. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

   # oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage

   注記

   ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

   # oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1

6. 置き換える OSD に関連付けられた PVC リソースを削除します。

   1. 置き換える OSD に関連付けられた DeviceSet を特定します。

      # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc

      出力例:

      ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68
          ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68

      この例では、PVC 名は OCS-deviceset-0-0-nvs68 です。

   2. PVC に関連付けられた PV を特定します。

      # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
      ocs-deviceset-0-0-nvs68   Bound    pvc-0e621d45-7d18-4d35-a282-9700c3cc8524   512Gi      RWO            thin           24h

      この例では、PVC は直前の手順で特定される ocs-deviceset-0-0-nvs68 になり、関連付けられた PV は pvc-0e621d45-7d18-4d35-a282-9700c3cc8524 になります。

   3. 置き換える OSD に関連付けられた prepare-pod を特定します。直前の手順で取得した PVC 名を使用します。

      # oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Mounted

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      Mounted By:    rook-ceph-osd-prepare-ocs-deviceset-0-0-nvs68-zblp7

   4. 関連付けられた PVC を削除する前に osd-prepare Pod を削除します。

      # oc delete -n openshift-storage pod rook-ceph-osd-prepare-ocs-deviceset-<x>-<y>-<pvc-suffix>-<pod-suffix>

      ここで、x、y、pvc-suffix、および pod-suffix は、直前の手順で特定された osd-prepare Pod 名の値です。

      出力例:

      pod "rook-ceph-osd-prepare-ocs-deviceset-0-0-nvs68-zblp7" deleted

   5. デバイスに関連付けられた PVC を削除します。

      # oc delete -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      persistentvolumeclaim "ocs-deviceset-0-0-nvs68" deleted

7. 新規デバイス用に新規 OSD を作成します。

   1. 置き換えられる OSD のデプロイメントを削除します。

      # oc delete -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove}

      出力例:

      deployment.extensions/rook-ceph-osd-0 deleted

   2. 先の手順で特定されたデバイスの PV が削除されていることを確認します。

      # oc get -n openshift-storage pv pvc-0e621d45-7d18-4d35-a282-9700c3cc8524

      出力例:

      Error from server (NotFound): persistentvolumes "pvc-0e621d45-7d18-4d35-a282-9700c3cc8524" not found

      この例では、PV 名は pvc-0e621d45-7d18-4d35-a282-9700c3cc8524 です。

      • PV がまだ存在する場合は、そのデバイスに関連付けられた PV を削除します。

        # oc delete pv pvc-0e621d45-7d18-4d35-a282-9700c3cc8524

        出力例:

        persistentvolume "pvc-0e621d45-7d18-4d35-a282-9700c3cc8524" deleted

        この例では、PV 名は pvc-0e621d45-7d18-4d35-a282-9700c3cc8524 です。

   3. rook-ceph-operator を再起動して新規 OSD をデプロイし、Operator の調整を強制的に実行します。

      1. rook-ceph-operator の名前を特定します。

         # oc get -n openshift-storage pod -l app=rook-ceph-operator

         出力例:

         NAME                                  READY   STATUS    RESTARTS   AGE
         rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h

      2. rook-ceph-operator を削除します。

         # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

         出力例:

         pod "rook-ceph-operator-6f74fb5bff-2d982" deleted

         この例では、rook-ceph-operator Pod 名は rook-ceph-operator-6f74fb5bff-2d982 です。

      3. rook-ceph-operator Pod が再起動していることを確認します。

         # oc get -n openshift-storage pod -l app=rook-ceph-operator

         出力例:

         NAME                                  READY   STATUS    RESTARTS   AGE
         rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

         新規 OSD の作成には、Operator が再起動するまでに数分かかる場合があります。

8. ocs-osd-removal ジョブを削除します。

   # oc delete job ocs-osd-removal-${osd_id_to_remove}

   出力例:

   job.batch "ocs-osd-removal-0" deleted

手順

1. 置き換える必要がある OSD と、その OSD がスケジュールされている OpenShift Container Platform ノードを特定します。

   # oc get -n openshift-storage pods -l app=rook-ceph-osd -o wide

   出力例:

   rook-ceph-osd-0-6d77d6c7c6-m8xj6    0/1    CrashLoopBackOff    0    24h   10.129.0.16   compute-2   <none>           <none>
   rook-ceph-osd-1-85d99fb95f-2svc7    1/1    Running    0    24h   10.128.2.24   compute-0   <none>           <none>
   rook-ceph-osd-2-6c66cdb977-jp542    1/1    Running    0    24h   10.130.0.18   compute-1   <none>           <none>

   この例では、置き換える必要があるのは rook-ceph-osd-0-6d77d6c7c6-m8xj6 であり、OSD がスケジュールされている OCP ノードは compute-2 です。

   注記

   置き換える OSD が正常であれば、Pod のステータスは Running になります。

2. 置き換えられる OSD の OSD デプロイメントをスケールダウンします。

   # osd_id_to_remove=0
   # oc scale -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove} --replicas=0

   ここで、osd_id_to_remove は rook-ceph-osd プレフィックスの直後にくる Pod 名の整数です。この例では、デプロイメント名は rook-ceph-osd-0 です。

   出力例:

   deployment.extensions/rook-ceph-osd-0 scaled

3. rook-ceph-osd Pod が停止していることを確認します。

   # oc get -n openshift-storage pods -l ceph-osd-id=${osd_id_to_remove}

   出力例:

   No resources found in openshift-storage namespace.

   注記

   rook-ceph-osd Pod が terminating 状態にある場合は、force オプションを使用して Pod を削除します。

   # oc delete pod rook-ceph-osd-0-6d77d6c7c6-m8xj6 --grace-period=0 --force

   出力例:

   warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
     pod "rook-ceph-osd-0-6d77d6c7c6-m8xj6" force deleted

4. 新規 OSD を追加できるようにクラスターから古い OSD を削除します。

   1. 古い ocs-osd-removal ジョブを削除します。

      # oc delete job ocs-osd-removal-${osd_id_to_remove}

      出力例:

      job.batch "ocs-osd-removal-0" deleted

   2. クラスターから以前の OSD を削除します。

      # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_ID=${osd_id_to_remove} | oc create -f -

      警告

      この手順により、OSD はクラスターから完全に削除されます。osd_id_to_remove の正しい値が指定されていることを確認します。

5. ocs-osd-removal Pod のステータスをチェックして、OSD が正常に削除されたことを確認します。Completed のステータスで、OSD の削除ジョブが正常に完了したことを確認します。

   # oc get pod -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage

   注記

   ocs-osd-removal が失敗し、Pod が予想される Completed の状態にない場合、追加のデバッグのために Pod ログを確認します。以下に例を示します。

   # oc logs -l job-name=ocs-osd-removal-${osd_id_to_remove} -n openshift-storage --tail=-1

6. 置き換える OSD に関連付けられた Persistent Volume Claim (永続ボリューム要求、PVC) リソースを削除します。

   1. 置き換える OSD に関連付けられた DeviceSet を特定します。

      # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-${osd_id_to_remove} | grep ceph.rook.io/pvc

      出力例:

      ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68
          ceph.rook.io/pvc: ocs-deviceset-0-0-nvs68

      この例では、PVC 名は OCS-deviceset-0-0-nvs68 です。

   2. PVC に関連付けられた PV を特定します。

      # oc get -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      NAME                      STATUS        VOLUME        CAPACITY   ACCESS MODES   STORAGECLASS   AGE
      ocs-deviceset-0-0-nvs68   Bound   local-pv-d9c5cbd6   100Gi      RWO            localblock     24h

      この例では、関連付けられた PV は local-pv-d9c5cbd6 です。

   3. 置き換えるデバイスの名前を特定します。

      # oc get pv local-pv-<pv-suffix> -o yaml | grep path

      ここで、pv-suffix は、前のステップで特定された PV 名の値です。

      出力例:

      path: /mnt/local-storage/localblock/sdb

      この例では、デバイス名は sdb です。

   4. 置き換える OSD に関連付けられた prepare-pod を特定します。

      # oc describe -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix> | grep Mounted

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      Mounted By:    rook-ceph-osd-prepare-ocs-deviceset-0-0-nvs68-zblp7

      この例では、prepare-pod 名は rook-ceph-osd-prepare-ocs-deviceset-0-0-nvs68-zblp7 です。

   5. 関連付けられた PVC を削除する前に osd-prepare Pod を削除します。

      # oc delete -n openshift-storage pod rook-ceph-osd-prepare-ocs-deviceset-<x>-<y>-<pvc-suffix>-<pod-suffix>

      ここで、x、y、pvc-suffix、および pod-suffix は、直前の手順で特定された osd-prepare Pod 名の値です。

      出力例:

      pod "rook-ceph-osd-prepare-ocs-deviceset-0-0-nvs68-zblp7" deleted

   6. 置き換える OSD に関連付けられた PVC を削除します。

      # oc delete -n openshift-storage pvc ocs-deviceset-<x>-<y>-<pvc-suffix>

      ここで、x、y、および pvc-suffix は、直前の手順で特定された DeviceSet の値です。

      出力例:

      persistentvolumeclaim "ocs-deviceset-0-0-nvs68" deleted

7. 古いデバイスを置き換え、新規デバイスを使用して新規の OpenShift Container Platform PV を作成します。

   1. 置き換えるデバイスのある OpenShift Container Platform ノードにログインします。この例では、OpenShift Container Platform ノードは compute-2 です。

      # oc debug node/compute-2

      出力例:

      Starting pod/compute-2-debug ...
      To use host binaries, run `chroot /host`
      Pod IP: 10.70.56.66
      If you don't see a command prompt, try pressing enter.
      # chroot /host

   2. 上記で特定されたデバイス名 sdb を使用して置き換える /dev/disk/by-id/{id} を記録します。

      # ls -alh /mnt/local-storage/localblock

      出力例:

      total 0
      drwxr-xr-x. 2 root root 17 Apr  8 23:03 .
      drwxr-xr-x. 3 root root 24 Apr  8 23:03 ..
      lrwxrwxrwx. 1 root root 54 Apr  8 23:03 sdb -> /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237

   3. LocalVolume CR の名前を見つけ、置き換えるデバイス /dev/disk/by-id/{id} を削除またはコメントアウトします。

      # oc get -n local-storage localvolume
      NAME          AGE
      local-block   25h

      # oc edit -n local-storage localvolume local-block

      出力例:

      [...]
        storageClassDevices:
        - devicePaths:
          - /dev/disk/by-id/scsi-36000c29346bca85f723c4c1f268b5630
          - /dev/disk/by-id/scsi-36000c29134dfcfaf2dfeeb9f98622786
      #   - /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237
          storageClassName: localblock
          volumeMode: Block
      [...]

      CR の編集後に変更を保存するようにしてください。

8. 置き換えるデバイスで OpenShift Container Platform ノードにログインし、古いsymlink を削除します。

   # oc debug node/compute-2

   出力例:

   Starting pod/compute-2-debug ...
   To use host binaries, run `chroot /host`
   Pod IP: 10.70.56.66
   If you don't see a command prompt, try pressing enter.
   # chroot /host

   1. 置き換えるデバイス名の古い symlink を特定します。この例では、デバイス名は sdb です。

      # ls -alh /mnt/local-storage/localblock

      出力例:

      total 0
      drwxr-xr-x. 2 root root 28 Apr 10 00:42 .
      drwxr-xr-x. 3 root root 24 Apr  8 23:03 ..
      lrwxrwxrwx. 1 root root 54 Apr  8 23:03 sdb -> /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237

   2. symlink を削除します。

      # rm /mnt/local-storage/localblock/sdb

   3. symlink が削除されていることを確認します。

      # ls -alh /mnt/local-storage/localblock

      出力例:

      total 0
      drwxr-xr-x. 2 root root 17 Apr 10 00:56 .
      drwxr-xr-x. 3 root root 24 Apr  8 23:03 ..

      重要

      次に進む前に、/dev/mapper と /dev/ の両方をチェックして、ceph に関連する孤立したオブジェクトがあるかどうかを確認します。vgdisplay の結果を使用して、これらの孤立を見つけます。/dev/mapper または /dev/ceph-* に、VG 名の一覧にない名前に ceph が設定されている場合は、dmsetup を使用してこれを削除します。

9. 先の手順で特定された、置き換えるデバイスに関連付けられた PV を削除します。この例では、PV 名は local-pv-d9c5cbd6 です。

   # oc delete pv local-pv-d9c5cbd6

   出力例:

   persistentvolume "local-pv-d9c5cbd6" deleted

10. デバイスを新しいデバイスに置き換えます。

11. 正しい OpenShift Container Platform ノードにログインし、新規ドライブのデバイス名を特定します。デバイス名は古いデバイスと同じにすることができますが、同じデバイスを使用しない限り by-id は変更する必要があります。

    # lsblk

    出力例:

    NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    sda                            8:0    0   60G  0 disk
    |-sda1                         8:1    0  384M  0 part /boot
    |-sda2                         8:2    0  127M  0 part /boot/efi
    |-sda3                         8:3    0    1M  0 part
    `-sda4                         8:4    0 59.5G  0 part
      `-coreos-luks-root-nocrypt 253:0    0 59.5G  0 dm   /sysroot
    sdb                            8:16   0  100G  0 disk

    この例では、新規デバイス名は sdb です。

    1. 新規デバイスの /dev/disk/by-id/{id} を特定し、これを記録します。

       # ls -alh /dev/disk/by-id | grep sdb

       出力例:

       lrwxrwxrwx. 1 root root   9 Apr  9 20:45 scsi-36000c29f5c9638dec9f19b220fbe36b1 -> ../../sdb

12. 新規の /dev/disk/by-id/{id} が利用可能になると、新規ディスクエントリーを LocalVolume CR に追加できます。

    1. LocalVolume CR の名前を検索します。

       # oc get -n local-storage localvolume
       NAME          AGE
       local-block   25h

    2. LocalVolume CR を編集し、新規の /dev/disk/by-id/{id} を追加します。この例では、新規デバイスは /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1 です。

       # oc edit -n local-storage localvolume local-block

       出力例:

       [...]
         storageClassDevices:
         - devicePaths:
           - /dev/disk/by-id/scsi-36000c29346bca85f723c4c1f268b5630
           - /dev/disk/by-id/scsi-36000c29134dfcfaf2dfeeb9f98622786
       #   - /dev/disk/by-id/scsi-36000c2962b2f613ba1f8f4c5cf952237
           - /dev/disk/by-id/scsi-36000c29f5c9638dec9f19b220fbe36b1
           storageClassName: localblock
           volumeMode: Block
       [...]

       CR の編集後に変更を保存するようにしてください。

13. 新規 PV が Available 状態にあり、正しいサイズであることを確認します。

    # oc get pv | grep 100Gi

    出力例:

    local-pv-3e8964d3                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-2-0-79j94   localblock                             25h
    local-pv-414755e0                          100Gi      RWO            Delete           Bound       openshift-storage/ocs-deviceset-1-0-959rp   localblock                             25h
    local-pv-b481410                           100Gi      RWO            Delete           Available

14. 新規デバイス用に新規 OSD を作成します。

    1. 置き換えられる OSD のデプロイメントを削除します。

       # osd_id_to_remove=0
       # oc delete -n openshift-storage deployment rook-ceph-osd-${osd_id_to_remove}

       出力例:

       deployment.extensions/rook-ceph-osd-0 deleted

    2. rook-ceph-operator を再起動して Operator の調整を強制的に実行して新規 OSD をデプロイします。

       1. rook-ceph-operator の名前を特定します。

          # oc get -n openshift-storage pod -l app=rook-ceph-operator

          出力例:

          NAME                                  READY   STATUS    RESTARTS   AGE
          rook-ceph-operator-6f74fb5bff-2d982   1/1     Running   0          1d20h

       2. rook-ceph-operator を削除します。

          # oc delete -n openshift-storage pod rook-ceph-operator-6f74fb5bff-2d982

          出力例:

          pod "rook-ceph-operator-6f74fb5bff-2d982" deleted

          この例では、rook-ceph-operator Pod 名は rook-ceph-operator-6f74fb5bff-2d982 です。

       3. rook-ceph-operator Pod が再起動していることを確認します。

          # oc get -n openshift-storage pod -l app=rook-ceph-operator

          出力例:

          NAME                                  READY   STATUS    RESTARTS   AGE
          rook-ceph-operator-6f74fb5bff-7mvrq   1/1     Running   0          66s

          新規 OSD の作成には、Operator が再起動するまでに数分かかる場合があります。