ハイブリッドおよびマルチクラウドリソースの管理

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
     namespace: openshift-storage
   type: Opaque
   data:
     AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
     AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

   <AWS ACCESS KEY> および <AWS SECRET ACCESS KEY>

   Base64 を使用して独自の AWS アクセスキー ID とシークレットアクセスキーを指定してエンコードし、その結果を <AWS ACCESS KEY ID ENCODED IN BASE64> と <AWS SECRET ACCESS KEY ENCODED IN BASE64> に使用します。

   <backingstore-secret-name>

   前のステップで作成された backingstore シークレットの名前。

2. 特定のバッキングストアについて以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     awsS3:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <bucket-name>
     type: aws-s3

   <bucket-name>

   既存の AWS バケット名。

   <backingstore-secret-name>

   前のステップで作成された backingstore シークレットの名前。

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

   noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage

   <backingstore_name>

   バッキングストアの名前。

   <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY>、および <IBM COS ENDPOINT>

   IBM アクセスキー ID、シークレットアクセスキー、および既存の IBM バケットの場所に対応する該当する地域エンドポイント

   IBM クラウドで上記のキーを生成するには、ターゲットバケットのサービス認証情報を作成する際に HMAC 認証情報を含める必要があります。

   <bucket-name>

   既存の IBM バケット名。この引数は、バッキングストア、およびその後のデータストレージと管理のターゲットバケットとして使用するバケットに関する MCG を示します。

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

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

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
     namespace: openshift-storage
   type: Opaque
   data:
     IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
     IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

   <IBM COS ACCESS KEY ID ENCODED IN BASE64> と <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

   Base64 を使用して独自の IBM COS アクセスキー ID とシークレットアクセスキーを提供およびエンコードし、これらの属性の代わりに結果をそれぞれ使用します。

   <backingstore-secret-name>

   backingstore シークレットの名前。

2. 特定のバッキングストアについて以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     ibmCos:
       endpoint: <endpoint>
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <bucket-name>
     type: ibm-cos

   <bucket-name>

   既存の IBM COS バケット名。この引数は、バッキングストアのターゲットバケットとして使用するバケットについて MCG に指示し、その後、データストレージと管理を行います。

   <endpoint>

   既存の IBM バケット名の場所に対応する地域エンドポイント。この引数は、バッキングストアに使用するエンドポイントを MCG に示し、その後、データストレージと管理を行います。

   <backingstore-secret-name>

   前のステップで作成されたシークレットの名前。

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
   type: Opaque
   data:
     AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
     AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>

   <AZURE ACCOUNT NAME ENCODED IN BASE64> および <AZURE ACCOUNT KEY ENCODED IN BASE64>

   Base64 を使用して独自の Azure アカウント名とアカウントキーを指定してエンコードし、これらの属性の代わりに結果をそれぞれ使用します。

   <backingstore-secret-name>

   backingstore シークレットの一意の名前。

2. 特定のバッキングストアについて以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     azureBlob:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBlobContainer: <blob-container-name>
     type: azure-blob

   <blob-container-name>

   既存の Azure BLOB コンテナー名。この引数は、バッキングストアのターゲットバケットとして使用するバケットについて MCG に指示し、その後、データストレージと管理を行います。

   <backingstore-secret-name>

   前の手順で作成したシークレットの名前に置き換えます。

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
   type: Opaque
   data:
     GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>

   <GCP PRIVATE KEY ENCODED IN BASE64>

   Base64 を使用して独自の GCP サービスアカウントの秘密鍵を提供およびエンコードし、この属性の結果を使用します。

   <backingstore-secret-name>

   backingstore シークレットの一意の名前。

2. 特定のバッキングストアについて以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     googleCloudStorage:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <target bucket>
     type: google-cloud-storage

   <target bucket>

   既存の Google ストレージバケット。この引数は、バッキングストアのターゲットバケットとして使用するバケットについて MCG に指示し、その後、データストレージ dfdand 管理を行います。

   <backingstore-secret-name>

   前のステップで作成されたシークレットの名前。

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

   注記

   このコマンドは、openshift-storage namespace 内から実行する必要があります。

   noobaa backingstore create  pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES>  --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS> -n openshift-storage

   <backingstore_name>

   バッキングストアの名前。

   <NUMBER OF VOLUMES>

   作成するボリュームの数。ボリュームの数を増やすと、ストレージが拡大することに注意してください。

   <VOLUME SIZE>

   各ボリュームの必要なサイズ (GB)。

   <LOCAL STORAGE CLASS>

   ocs-storagecluster-ceph-rbd の使用が推奨されるローカルストレージクラス。

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

   INFO[0001] ✅ Exists: NooBaa "noobaa"
   INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"

1. 特定のバッキングストアについて以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <backingstore_name>
     namespace: openshift-storage
   spec:
      pvPool:
       numVolumes: <NUMBER OF VOLUMES>
       resources:
         requests:
           storage: <VOLUME SIZE>
       storageClass: <LOCAL STORAGE CLASS>
     type: pv-pool

   1. <backingstore_name> を、バッキングストアの名前に置き換えます。
   2. <NUMBER OF VOLUMES> を、作成するボリューム数に置き換えます。ボリュームの数を増やすと、ストレージが拡大することに注意してください。
   3. <VOLUME SIZE> を、各ボリュームに必要なサイズ (GB 単位) に置き換えます。文字 G はそのままにする必要があることに注意してください。
   4. <LOCAL STORAGE CLASS> をローカルストレージクラスに置き換えます。これは、ocs-storagecluster-ceph-rbd を使用する際に推奨されます。

手順

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <namespacestore-secret-name>
     type: Opaque
   data:
     AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
     AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

   ここで、<namespacestore-secret-name> は一意の NamespaceStore 名になります。

   Base64 を使用して独自の AWS アクセスキー ID およびシークレットアクセスキーを指定してエンコードし、その結果を <AWS ACCESS KEY ID ENCODED IN BASE64> および <AWS SECRET ACCESS KEY ENCODED IN BASE64> の代わりに使用する必要があります。

2. OpenShift カスタムリソース定義 (CRD) を使用して NamespaceStore リソースを作成します。

   NamespaceStore は、MCG namespace バケットでデータの read または write ターゲットとして使用される基礎となるストレージを表します。

   NamespaceStore リソースを作成するには、以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: NamespaceStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <resource-name>
     namespace: openshift-storage
   spec:
     awsS3:
       secret:
         name: <namespacestore-secret-name>
         namespace: <namespace-secret>
       targetBucket: <target-bucket>
     type: aws-s3

   <resource-name>

   リソースに指定する名前。

   <namespacestore-secret-name>

   前の手順で作成されたシークレット

   <namespace-secret>

   シークレットが見つかる namespace。

   <target-bucket>

   NamespaceStore 用に作成したターゲットバケット。

3. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。namespace ポリシーには、single または multi のタイプが必要です。

   • タイプ single の namespace ポリシーには、以下の設定が必要です。

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type:
         single:
           resource: <resource>

     <my-bucket-class>

     一意の namespace バケットクラス名。

     <resource>

     namespace バケットの読み取りおよび書き込みターゲットを定義する単一の NamespaceStore の名前。

   • タイプが multi の namespace ポリシーには、以下の設定が必要です。

     apiVersion: noobaa.io/v1alpha1
     
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type: Multi
         multi:
           writeResource: <write-resource>
           readResources:
           - <read-resources>
           - <read-resources>

     <my-bucket-class>

     一意のバケットクラス名。

     <write-resource>

     namespace バケットの write ターゲットを定義する単一の NamespaceStore の名前。

     <read-resources>

     namespace バケットの read ターゲットを定義する NamespaceStores の名前のリスト。

4. 以下の YAML を使用して前の手順に定義されたバケットクラスを使用する Object Bucket Class (OBC) リソースを使用して、バケットを作成します。

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <resource-name>
     namespace: openshift-storage
   spec:
     generateBucketName: <my-bucket>
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: <my-bucket-class>

   注記

   IBM Power および IBM Z インフラストラクチャーの場合は、storageClassName を openshift-storage.noobaa.io として使用します。

   <resource-name>

   リソースに指定する名前。

   <my-bucket>

   バケットに指定したい名前。

   <my-bucket-class>

   前のステップで作成されたバケットクラス。

手順

1. 認証情報でシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <namespacestore-secret-name>
     type: Opaque
   data:
     IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
     IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

   <namespacestore-secret-name>

   一意の NamespaceStore 名。

   Base64 を使用して独自の IBM COS アクセスキー ID およびシークレットアクセスキーを指定してエンコードし、その結果を <IBM COS ACCESS KEY ID ENCODED IN BASE64> および <IBM COS SECRET ACCESS KEY ENCODED IN BASE64> の代わりに使用する必要があります。

2. OpenShift カスタムリソース定義 (CRD) を使用して NamespaceStore リソースを作成します。

   NamespaceStore は、MCG namespace バケットでデータの read または write ターゲットとして使用される基礎となるストレージを表します。

   NamespaceStore リソースを作成するには、以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: NamespaceStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     s3Compatible:
       endpoint: <IBM COS ENDPOINT>
       secret:
         name: <namespacestore-secret-name>
         namespace: <namespace-secret>
       signatureVersion: v2
       targetBucket: <target-bucket>
     type: ibm-cos

   <IBM COS ENDPOINT>

   適切な IBM COS エンドポイント。

   <namespacestore-secret-name>

   前の手順で作成されたシークレット

   <namespace-secret>

   シークレットが見つかる namespace。

   <target-bucket>

   NamespaceStore 用に作成したターゲットバケット。

3. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。namespace ポリシーには、single または multi のタイプが必要です。

   • タイプ single の namespace ポリシーには、以下の設定が必要です。

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type:
         single:
           resource: <resource>

     <my-bucket-class>

     一意の namespace バケットクラス名。

     <resource>

     namespace バケットの read および write ターゲットを定義する単一の NamespaceStore の名前。

   • タイプが multi の namespace ポリシーには、以下の設定が必要です。

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type: Multi
         multi:
           writeResource: <write-resource>
           readResources:
           - <read-resources>
           - <read-resources>

     <my-bucket-class>

     一意のバケットクラス名。

     <write-resource>

     namespace バケットの書き込みターゲットを定義する単一の NamespaceStore の名前。

     <read-resources>

     namespace バケットの read ターゲットを定義する NamespaceStores 名のリスト。

4. 以下の YAML を適用して、前の手順で定義されたバケットクラスを使用する Object Bucket Class (OBC) リソースを使用してバケットを作成します。

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <resource-name>
     namespace: openshift-storage
   spec:
     generateBucketName: <my-bucket>
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: <my-bucket-class>

   注記

   IBM Power および IBM Z インフラストラクチャーの場合は、storageClassName を openshift-storage.noobaa.io として使用します。

   <resource-name>

   リソースに指定する名前。

   <my-bucket>

   バケットに指定したい名前。

   <my-bucket-class>

   前のステップで作成されたバケットクラス。

   OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC と同じ namespace 上に同じ名前で Secret および ConfigMap を作成します。

手順

1. MCG コマンドラインインターフェイスで、NamespaceStore リソースを作成します。

   NamespaceStore は、MCG namespace バケットでデータの read または write ターゲットとして使用される基礎となるストレージを表します。

   $ noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage

   <namespacestore>

   NamespaceStore の名前。

   <AWS ACCESS KEY> と <AWS SECRET ACCESS KEY>

   この目的のために作成した AWS アクセスキー ID とシークレットアクセスキー。

   <bucket-name>

   既存の AWS バケット名。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

2. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。namespace ポリシーは、single または multi のいずれかになります。

   • タイプが single の namespace ポリシーを使用して namespace バケットクラスを作成するには、以下を実行します。

     $ noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

     <resource-name>

     リソースに指定する名前。

     <my-bucket-class>

     一意のバケットクラス名。

     <resource>

     namespace バケットの read および write ターゲットを定義する単一の namespace-store。

   • タイプ multi の namespace ポリシーを使用して namespace バケットクラスを作成するには、以下を実行します。

     $ noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

     <resource-name>

     リソースに指定する名前。

     <my-bucket-class>

     一意のバケットクラス名。

     <write-resource>

     namespace バケットの write ターゲットを定義する単一の namespace-store。

     <read-resources>s

     namespace バケットの read ターゲットを定義する、コンマで区切られた namespace-store の一覧。

3. 前の手順で定義したバケットクラスを使用する Object Bucket Class (OBC) リソースを使用して、バケットを作成します。

   $ noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>

   <bucket-name>

   選択したバケット名。

   <custom-bucket-class>

   前の手順で作成したバケットクラスの名前。

   OBC が Operator によってプロビジョニングされると、バケットが MCG で作成され、Operator は OBC と同じ namespace 上に同じ名前で Secret および ConfigMap を作成します。

手順

1. MCG コマンドラインインターフェイスで、NamespaceStore リソースを作成します。

   NamespaceStore は、MCG namespace バケットでデータの read または write ターゲットとして使用される基礎となるストレージを表します。

   $ noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage

   <namespacestore>

   NamespaceStore の名前。

   <IBM ACCESS KEY>、<IBM SECRET ACCESS KEY>、<IBM COS ENDPOINT>

   IBM アクセスキー ID、シークレットアクセスキー、および既存の IBM バケットの場所に対応する該当する地域エンドポイント

   <bucket-name>

   既存の IBM バケット名。この引数は、MCG に対して、バッキングストア、およびその後のデータストレージおよび管理のためのターゲットバケットとして使用するバケットについて指示します。

2. namespace バケットの namespace ポリシーを定義する namespace バケットクラスを作成します。namespace ポリシーには、single または multi のタイプが必要です。

   • タイプが single の namespace ポリシーを使用して namespace バケットクラスを作成するには、以下を実行します。

     $ noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

     <resource-name>

     リソースに指定する名前。

     <my-bucket-class>

     一意のバケットクラス名。

     <resource>

     namespace バケットの read および write ターゲットを定義する単一の NamespaceStore。

   • タイプ multi の namespace ポリシーを使用して namespace バケットクラスを作成するには、以下を実行します。

     $ noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

     <resource-name>

     リソースに指定する名前。

     <my-bucket-class>

     一意のバケットクラス名。

     <write-resource>

     namespace バケットの write ターゲットを定義する単一の NamespaceStore。

     <read-resources>

     namespace バケットの read ターゲットを定義する NamespaceStores のコンマ区切りリスト。

3. 前の手順で定義したバケットクラスを使用する Object Bucket Class (OBC) リソースを使用して、バケットを作成します。

   $ noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>

   <bucket-name>

   選択したバケット名。

   <custom-bucket-class>

   前の手順で作成したバケットクラスの名前。

手順

1. OpenShift Web コンソールにログインします。
2. Storage → Data Foundation をクリックします。
3. Namespace Store タブをクリックして、namespace バケットで使用される NamespaceStore リソースを作成します。
4. Create namespaces をクリックします。
5. NamespaceStore の名前を入力します。
6. プロバイダーとしてファイルシステムを選択します。
7. 永続ボリュームクレームを選択します。

8. フォルダー名を入力します。

   フォルダー名が存在する場合は、そのフォルダーを使用して NamespaceStore を作成するか、その名前のフォルダーを作成します。

9. Create をクリックします。
10. namespacestore が Ready 状態にあることを確認します。

手順

1. scc を使用してアプリケーションの namespace を表示します。

   $ oc get ns <application_namespace> -o yaml | grep scc

   <application_namespace>

   アプリケーションの namespace の名前を指定します。

   以下に例を示します。

   $ oc get ns testnamespace -o yaml | grep scc
   
   openshift.io/sa.scc.mcs: s0:c26,c5
   openshift.io/sa.scc.supplemental-groups: 1000660000/10000
   openshift.io/sa.scc.uid-range: 1000660000/10000

2. アプリケーションの namespace に移動します。

   $ oc project <application_namespace>

   以下に例を示します。

   $ oc project testnamespace

3. MCG NSFS 機能を使用して、noobaa S3 エンドポイントから消費する Pod に ReadWriteMany (RWX) PVC がマウントされていることを確認します。

   $ oc get pvc
   
   NAME                                               STATUS VOLUME
   CAPACITY ACCESS MODES STORAGECLASS              AGE
   cephfs-write-workload-generator-no-cache-pv-claim  Bound  pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
   10Gi     RWX          ocs-storagecluster-cephfs 12s

   $ oc get pod
   
   NAME                                                READY   STATUS              RESTARTS   AGE
   cephfs-write-workload-generator-no-cache-1-cv892    1/1     Running             0          11s

4. Pod 内の永続ボリューム (PV) のマウントポイントを確認します。

   1. Pod から PV のボリューム名を取得します。

      $ oc get pods <pod_name> -o jsonpath='{.spec.volumes[]}'

      <pod_name>

      pod の名前を指定します。

      以下に例を示します。

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.volumes[]}'
      
      {"name":"app-persistent-storage","persistentVolumeClaim":{"claimName":"cephfs-write-workload-generator-no-cache-pv-claim"}}

      この例では、PVC のボリュームの名前は cephfs-write-workload-generator-no-cache-pv-claim です。

   2. Pod 内のすべてのマウントを一覧表示し、前の手順で特定したボリュームのマウントポイントを確認します。

      $ oc get pods <pod_name> -o jsonpath='{.spec.containers[].volumeMounts}'

      以下に例を示します。

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.containers[].volumeMounts}'
      
      [{"mountPath":"/mnt/pv","name":"app-persistent-storage"},{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-8tnc5","readOnly":true}]

5. Pod 内の RWX PV のマウントポイントを確認します。

   $ oc exec -it <pod_name> -- df <mount_path>

   <mount_path>

   前の手順で特定したマウントポイントへのパスを指定します。

   以下に例を示します。

   $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- df /mnt/pv
   
   main
   Filesystem
   1K-blocks Used Available  Use%  Mounted on
   172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
   10485760  0    10485760   0%    /mnt/pv

6. UID および SELinux ラベルが、レガシー namespace が使用するものと同じであることを確認してください。

   $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

   以下に例を示します。

   $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/
   
   total 567
   drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
   -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
   drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

7. openshift-storage namespace からアクセス可能にするレガシーアプリケーション RWX PV の情報を取得します。

   $ oc get pv | grep <pv_name>

   <pv_name>

   PV の名前を指定します。

   以下に例を示します。

   $ oc get pv | grep pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
   
   pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a   10Gi       RWX            Delete           Bound    testnamespace/cephfs-write-workload-generator-no-cache-pv-claim   ocs-storagecluster-cephfs              47s

8. 1 つ以上の noobaa-endpoint Pod が PVC にアクセスできるように、レガシーアプリケーションの PVC が openshift-storage namespace からアクセス可能であることを確認します。

   1. volumeAttributes から subvolumePath と volumeHandle の値を検索します。これらの値は、レガシーアプリケーション PV の YAML 記述から取得できます。

      $ oc get pv <pv_name> -o yaml

      以下に例を示します。

      $ oc get pv pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a -o yaml
      
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        annotations:
          pv.kubernetes.io/provisioned-by: openshift-storage.cephfs.csi.ceph.com
        creationTimestamp: "2022-05-25T06:27:49Z"
        finalizers:
        - kubernetes.io/pv-protection
        name: pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
        resourceVersion: "177458"
        uid: 683fa87b-5192-4ccf-af2f-68c6bcf8f500
      spec:
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi
        claimRef:
          apiVersion: v1
          kind: PersistentVolumeClaim
          name: cephfs-write-workload-generator-no-cache-pv-claim
          namespace: testnamespace
          resourceVersion: "177453"
          uid: aa58fb91-c3d2-475b-bbee-68452a613e1a
        csi:
          controllerExpandSecretRef:
            name: rook-csi-cephfs-provisioner
            namespace: openshift-storage
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
            clusterID: openshift-storage
            fsName: ocs-storagecluster-cephfilesystem
            storage.kubernetes.io/csiProvisionerIdentity: 1653458225664-8081-openshift-storage.cephfs.csi.ceph.com
            subvolumeName: csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213
            subvolumePath: /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213
        persistentVolumeReclaimPolicy: Delete
        storageClassName: ocs-storagecluster-cephfs
        volumeMode: Filesystem
      status:
        phase: Bound

   2. 前のステップで特定した subvolumePath と volumeHandle の値を使用して、レガシーアプリケーション PV と同じ CephFS ボリュームを指す openshift-storage namespace に新しい PV および PVC オブジェクトを作成します。

      YAML ファイルサンプル:

      $ cat << EOF >> pv-openshift-storage.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: cephfs-pv-legacy-openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi     1
        csi:
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
          # Volume Attributes can be copied from the Source testnamespace PV
            "clusterID": "openshift-storage"
            "fsName": "ocs-storagecluster-cephfilesystem"
            "staticVolume": "true"
          # rootpath is the subvolumePath: you copied from the Source testnamespace PV
            "rootPath": /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213-clone   2
        persistentVolumeReclaimPolicy: Retain
        volumeMode: Filesystem
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: cephfs-pvc-legacy
        namespace: openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 10Gi     3
        volumeMode: Filesystem
        # volumeName should be same as PV name
        volumeName: cephfs-pv-legacy-openshift-storage
      EOF

      1

      openshift-storage namespace で作成する PV のストレージ容量は、元の PV と同じである必要があります。

      2

      openshift-storage で作成するターゲット PV のボリュームハンドルには、元のアプリケーション PV とは異なるハンドルが必要です。たとえば、ボリュームハンドルの末尾に -clone を追加します。

      3

      openshift-storage namespace で作成する PVC のストレージ容量は、元の PVC と同じである必要があります。

   3. 前のステップで指定した YAML ファイルを使用して、openshift-storage namespace に PV と PVC を作成します。

      $ oc create -f <YAML_file>

      <YAML_file>

      YAML ファイルの名前を指定します。

      以下に例を示します。

      $ oc create -f pv-openshift-storage.yaml
      
      persistentvolume/cephfs-pv-legacy-openshift-storage created
      persistentvolumeclaim/cephfs-pvc-legacy created

   4. PVC が openshift-storage namespace で使用可能であることを確認します。

      $ oc get pvc -n openshift-storage
      
      NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      cephfs-pvc-legacy                     Bound    cephfs-pv-legacy-openshift-storage         10Gi       RWX                                          14s

   5. openshift-storage プロジェクトに移動します。

      $ oc project openshift-storage
      
      Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".

   6. NSFS namespace ストアを作成します。

      $ noobaa namespacestore create nsfs <nsfs_namespacestore> --pvc-name='<cephfs_pvc_name>' --fs-backend='CEPH_FS'

      <nsfs_namespacestore>

      NSFS namespace ストアの名前を指定します。

      <cephfs_pvc_name>

      openshift-storage namespace で CephFSPVC の名前を指定します。

      以下に例を示します。

      $ noobaa namespacestore create nsfs legacy-namespace --pvc-name='cephfs-pvc-legacy' --fs-backend='CEPH_FS'

   7. noobaa-endpointPod が再起動し、NSFS namespace ストア (/nsfs/legacy-namespace mountpoint など) に PVC が正常にマウントされていることを確認します。

      $ oc exec -it <noobaa_endpoint_pod_name> -- df -h /nsfs/<nsfs_namespacestore>

      <noobaa_endpoint_pod_name>

      noobaa エンドポイント Pod の名前を指定します。

      以下に例を示します。

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -- df -h /nsfs/legacy-namespace
      
      Filesystem                                                                                                                                                Size  Used Avail Use% Mounted on
      172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c   10G     0   10G   0% /nsfs/legacy-namespace

   8. MCG ユーザーアカウントを作成します。

      $ noobaa account create <user_account> --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid <gid_number> --uid <uid_number> --default_resource='legacy-namespace'

      <user_account>

      MCG ユーザーアカウントの名前を指定します。

      <gid_number>

      GID 番号を指定します。

      <uid_number>

      UID 番号を指定します。

      重要

      レガシーアプリケーションと同じ UID と GID を使用します。前の出力から見つけることができます。

      以下に例を示します。

      $ noobaa account create leguser --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid 0 --uid 1000660000 --default_resource='legacy-namespace'

   9. MCG バケットを作成します。

      1. レガシーアプリケーション Pod の CephFS PV および PVC の NSFS 共有内に S3 専用のフォルダーを作成します。

         $ oc exec -it <pod_name> -- mkdir <mount_path>/nsfs

         以下に例を示します。

         $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- mkdir /mnt/pv/nsfs

      2. nsfs/ パスを使用して MCG バケットを作成します。

         $ noobaa api bucket_api create_bucket '{
           "name": "<bucket_name>",
           "namespace":{
             "write_resource": { "resource": "<nsfs_namespacestore>", "path": "nsfs/" },
             "read_resources": [ { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }]
           }
         }'

         以下に例を示します。

         $ noobaa api bucket_api create_bucket '{
           "name": "legacy-bucket",
           "namespace":{
             "write_resource": { "resource": "legacy-namespace", "path": "nsfs/" },
             "read_resources": [ { "resource": "legacy-namespace", "path": "nsfs/" }]
           }
         }'

   10. レガシーアプリケーションおよび openshift-storage namespace の PVC にあるフォルダーの SELinux ラベルを確認します。

       $ oc exec -it <noobaa_endpoint_pod_name> -n openshift-storage -- ls -ltraZ /nsfs/<nsfs_namespacstore>

       以下に例を示します。

       $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -n openshift-storage -- ls -ltraZ /nsfs/legacy-namespace
       
       total 567
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26      2 May 25 06:35 .
       -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c0,c26 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26     30 May 25 06:35 ..

       $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

       以下に例を示します。

       $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/
       
       total 567
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
       -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

       これらの例では、SELinux ラベルが同じではないため、アクセス許可が拒否されたり、アクセスの問題が発生したりすることがわかります。

9. レガシーアプリケーションと openshift-storage Pod がファイルで同じ SELinux ラベルを使用していることを確認します。

   これは、次のいずれかの方法で実行できます。

   • 「レガシーアプリケーションプロジェクトのデフォルトの SELinux ラベルを、openshift-storage プロジェクトのラベルと一致するように変更します」 をクリックします。
   • 「レガシーアプリケーション PVC をマウントする Pod を持つデプロイメント設定に対してのみ SELinux ラベルを変更する」

10. NSFS namespace ストアを削除します。

    1. MCG バケットを削除します。

       $ noobaa bucket delete <bucket_name>

       以下に例を示します。

       $ noobaa bucket delete legacy-bucket

    2. MCG ユーザーアカウントを削除します。

       $ noobaa account delete <user_account>

       以下に例を示します。

       $ noobaa account delete leguser

    3. NSFS namespace ストアを削除します。

       $ noobaa namespacestore delete <nsfs_namespacestore>

       以下に例を示します。

       $ noobaa namespacestore delete legacy-namespace

11. PV と PVC を削除します。

    重要

    PV と PVC を削除する前に、PV に保持ポリシーが設定されていることを確認してください。

    $ oc delete pv <cephfs_pv_name>

    $ oc delete pvc <cephfs_pvc_name>

    <cephfs_pv_name>

    レガシーアプリケーションの CephFS PV 名を指定します。

    <cephfs_pvc_name>

    レガシーアプリケーションの CephFS PVC 名を指定します。

    以下に例を示します。

    $ oc delete pv cephfs-pv-legacy-openshift-storage

    $ oc delete pvc cephfs-pvc-legacy

手順

1. 以下の YAML を適用します。

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: <desired-app-label>
     name: <desired-bucketclass-name>
     namespace: <desired-namespace>
   spec:
     placementPolicy:
       tiers:
       - backingstores:
         - <backingstore>
         placement: Spread
     replicationPolicy: [{ "rule_id": "<rule id>", "destination_bucket": "first.bucket", "filter": {"prefix": "<object name prefix>"}}]

   この YAML は、配置バケットクラスを作成する例です。バケットにアップロードされた各オブジェクトバケットクレーム (OBC) オブジェクトは、接頭辞に基づいてフィルタリングされ、first.bucket に複製されます。

   <desired-app-label>

   アプリのラベルを指定します。

   <desired-bucketclass-name>

   バケットクラス名を指定します。

   <desired-namespace>

   バケットクラスが作成される namespace を指定します。

   <backingstore>

   バッキングストアの名前を指定します。複数のバッキングストアを通過することが可能です。

   "rule_id"

   ルールの ID 番号を指定します (例: `{"rule_id": "rule-1"})。

   "destination_bucket"

   宛先バケットの名前を指定します (例: {"destination_bucket": "first.bucket"})。

   "prefix"

   オプション。複製する必要があるのはオブジェクトキーの接頭辞であり、たとえば {"prefix": ""} のように、空のままにすることもできます。