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

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. 認証情報でシークレットを作成します。

   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>

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

   <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 → Object Storage をクリックします。
3. NamespaceStore タブをクリックして、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 で CephFS PVC の名前を指定します。

      以下に例を示します。

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

   7. noobaa-endpoint Pod が再起動し、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. アカウント名を取得します。

   アカウントを一覧表示するには、次のコマンドを実行します。

   $ noobaa account list

   出力例:

   NAME           ALLOWED_BUCKETS   DEFAULT_RESOURCE               PHASE   AGE
   account-test   [*]               noobaa-default-backing-store   Ready   14m17s
   test2          [first.bucket]    noobaa-default-backing-store   Ready   3m12s

   または、ターミナルから oc get noobaaaccount コマンドを実行します。

   $ oc get noobaaaccount

   出力例:

   NAME           PHASE   AGE
   account-test   Ready   15m
   test2          Ready   3m59s

2. noobaa アカウントの S3 資格情報を再生成するには、次のコマンドを実行します。

   $ noobaa account regenerate <noobaa_account_name> [options]

   $ noobaa account regenerate
   FATA[0000] ❌ Missing expected arguments: <noobaa-account-name>
   
   Usage:
       noobaa account regenerate <noobaa-account-name> [flags] [options]
   
   Use "noobaa options" for a list of global command-line options (applies to all commands).

3. noobaa account regenerate コマンドを実行すると、"This will invalidate all connections between S3 clients and NooBaa which are connected using the current credentials." という警告がプロンプトされ、確認が求めます。

   以下に例を示します。

   $ noobaa account regenerate account-test

   出力例:

   INFO[0000] You are about to regenerate an account's security credentials.
   INFO[0000] This will invalidate all connections between S3 clients and NooBaa which are connected using the current credentials.
   INFO[0000] are you sure? y/n

4. 承認すると、資格情報が再生成され、最終的にそれらが出力されます。

   INFO[0015] ✅ Exists: Secret "noobaa-account-account-test"
   Connection info:
   AWS_ACCESS_KEY_ID      : ***
   AWS_SECRET_ACCESS_KEY  : ***

手順

1. OBC 名を取得するには、次のコマンドを実行します。

   $ noobaa obc list

   出力例:

   NAMESPACE   NAME       BUCKET-NAME                                     STORAGE-CLASS       BUCKET-CLASS                  PHASE
   default     obc-test   obc-test-35800e50-8978-461f-b7e0-7793080e26ba   default.noobaa.io   noobaa-default-bucket-class   Bound

   または、ターミナルから oc get obc コマンドを実行します。

   $ oc get obc

   出力例:

   NAME       STORAGE-CLASS       PHASE   AGE
   obc-test   default.noobaa.io   Bound   38s

2. noobaa OBC S3 資格情報を再生成するには、次のコマンドを実行します。

   $ noobaa obc regenerate <bucket_claim_name> [options]

   $ noobaa obc regenerate
   FATA[0000] ❌ Missing expected arguments: <bucket-claim-name>
   
   Usage:
      noobaa obc regenerate <bucket-claim-name> [flags] [options]
   
   Use "noobaa options" for a list of global command-line options (applies to all commands).

3. noobaa obc regenerate コマンドを実行すると、"This will invalidate all connections between the S3 clients and noobaa which are connected using the current credentials." (これにより、現在の認証情報を使用して接続されている S3 クライアントと noobaa の接続はすべて無効になります) という警告がプロンプトされ、確認が求めます。

   以下に例を示します。

   $ noobaa obc regenerate obc-test

   出力例:

   INFO[0000] You are about to regenerate an OBC's security credentials.
   INFO[0000] This will invalidate all connections between S3 clients and NooBaa which are connected using the current credentials.
   INFO[0000] are you sure? y/n

4. 承認すると、資格情報が再生成され、最終的にそれらが出力されます。

   INFO[0022] ✅ RPC: bucket.read_bucket() Response OK: took 95.4ms
   
   ObjectBucketClaim info:
     Phase                  : Bound
     ObjectBucketClaim      : kubectl get -n default objectbucketclaim obc-test
     ConfigMap              : kubectl get -n default configmap obc-test
     Secret                 : kubectl get -n default secret obc-test
     ObjectBucket           : kubectl get objectbucket obc-default-obc-test
     StorageClass           : kubectl get storageclass default.noobaa.io
     BucketClass            : kubectl get -n default bucketclass noobaa-default-bucket-class
   
   Connection info:
    BUCKET_HOST            : s3.default.svc
    BUCKET_NAME            : obc-test-35800e50-8978-461f-b7e0-7793080e26ba
       BUCKET_PORT            : 443
       AWS_ACCESS_KEY_ID      : ***
       AWS_SECRET_ACCESS_KEY  : ***
   
   Shell commands:
     AWS S3 Alias           : alias s3='AWS_ACCESS_KEY_ID=***
   AWS_SECRET_ACCESS_KEY=*** aws s3 --no-verify-ssl --endpoint-url ***'
   
   Bucket status:
     Name                   : obc-test-35800e50-8978-461f-b7e0-7793080e26ba
     Type                   : REGULAR
     Mode                   : OPTIMAL
     ResiliencyStatus       : OPTIMAL
     QuotaStatus            : QUOTA_NOT_SET
     Num Objects            : 0
     Data Size              : 0.000 B
     Data Size Reduced      : 0.000 B
     Data Space Avail       : 13.261 GB
     Num Objects Avail      : 9007199254740991

手順

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": ""} など、空のままにすることができます。

手順

1. OpenShift Web コンソールで、Storage → Object Storage → Object Bucket Claims に移動します。
2. Create ObjectBucketClaim をクリックします。
3. ObjectBucketName の名前を入力し、StorageClass および BucketClass を選択します。
4. Enable replication チェックボックスを選択して、レプリケーションを有効にします。
5. Replication policy セクションで、Optimize replication using event logs チェックボックスをオンにします。

6. Event log Bucket の下にログが含まれるバケットの名前を入力します。

   ログがバケットのルートに保存されていない場合は、s3:// なしで完全パスを指定します。

7. 接頭辞を入力すると、名前が指定された接頭辞で始まるオブジェクトのみが複製されます。

手順

1. namespacestores で使用される認証情報を含むシークレットを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <namespacestore-secret-name>
   type: Opaque
   data:
       TenantID: <AZURE TENANT ID ENCODED IN BASE64>
       ApplicationID: <AZURE APPLICATIOM ID ENCODED IN BASE64>
       ApplicationSecret: <AZURE APPLICATION SECRET ENCODED IN BASE64>
       LogsAnalyticsWorkspaceID: <AZURE LOG ANALYTICS WORKSPACE ID ENCODED IN BASE64>
       AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
       AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>

2. Azure で作成したコンテナーを基盤とする NamespaceStore を作成します。

   詳細は、OpenShift Container Platform ユーザーインターフェイスを使用した namespace バケットの追加 を参照してください。

3. これを使用する新規の Namespace-Bucketclass および OBC を作成します。
4. ターゲット OBC の YAML を調べるか、すべての S3 バケット (例: - s3 ls) をリストして、オブジェクトバケット名を確認します。

5. 次のテンプレートを使用し、.spec の下の YAML に次の内容を追加して、ソース OBC に Azure レプリケーションポリシーを適用します。

   replicationPolicy:'{"rules":[ {"rule_id":"ID goes here", "sync_deletions": "<true or false>"", "destination_bucket":object bucket name"}
    ], "log_replication_info":{"endpoint_type":"AZURE"}}'

   sync_deletion

   ブール値 true または false を指定します。

   destination_bucket

   要求ではなく、オブジェクトバケットの名前を使用するようにしてください。この名前は、s3 ls コマンドを使用するか、OBC の YAML での値を検索して取得できます。

検証手順

1. オブジェクトをソースバケットに書き込みます。
2. MCG が複製するまで待ちます。
3. ソースバケットからオブジェクトを削除します。
4. オブジェクトがターゲットバケットから削除されたことを確認します。

手順

1. OpenShift Web コンソールで、Storage → Object Storage → Object Bucket Claims に移動します。
2. Create new Object bucket claim をクリックします。
3. (任意) Replication rules セクションで、各ルールの Sync deletion チェックボックスを個別に選択します。

4. Event log Bucket の下にログが含まれるバケットの名前を入力します。

   ログがバケットのルートに保存されていない場合は、s3:// なしで完全パスを指定します。

5. 接頭辞を入力すると、名前が指定された接頭辞で始まるオブジェクトのみが複製されます。