1. OCP クラスターを拡張して、新規ノードを追加します。詳細は https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/configuring_clusters/#adding-cluster-hosts_adding-hosts-to-cluster を参照してください。

   注記

   • 新規ノードがすでに OCP クラスターの一部である場合は、このステップを省略してステップ 2 に進みます。
   • OCP クラスターをスケールアップして、コンピュートノードまたはインフラノードのいずれかとして新規ノードを追加できます。たとえば、インフラの場合は node3.example.com openshift_node_group_name='node-config-infra' で、コンピュートノードの場合は node3.example.com openshift_node_group_name='node-config-compute' になります。

2. ファイアウォールルールを設定します。

   注記

   ノードを正常に追加するには、glusterd 通信のポートが開いていることを確認します。ポートの詳細は https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html/installation_guide/port_information を参照してください。

   1. 以下のルールを、新たに追加した glusterfs ノードの /etc/sysconfig/iptables ファイルに追加します。

      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24007 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24008 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m multiport --dports 49152:49664 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24010 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 3260 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT

   2. iptables を再読み込み/再起動します。

      # systemctl restart iptables

3. RHGS コンテナーがデプロイされるノードにラベルを追加するには、以下の手順を実行します。

   1. 以下のコマンドを実行して、Red Hat Openshift Container Storage が既存プロジェクトでデプロイされ、予想通りに機能していることを確認します。

      # oc get ds

      以下に例を示します。

      # oc get ds
      NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
      glusterfs-storage   3         3         3         3            3           glusterfs=storage-host   1d

   2. 新たに追加される各ノードのラベルを追加します。ここでは、Red Hat Gluster Storage Pod が新規クラスターに追加されます。

      # oc label node <NODE_NAME> glusterfs=<node_label>

      ここで、

      • NODE_NAME: 新規に作成されたノードの名前です。
      • node_label: 既存のデーモンセットで使用される名前です。これは、直前の手順で oc get ds を実行する際に取得した値です。

      以下に例を示します。

      # oc label node 192.168.90.3 glusterfs=storage-host
      node "192.168.90.3" labeled

   3. 以下のコマンドを実行して、Red Hat Gluster Storage Pod が新規に追加されたノードで実行されているかどうかを確認します。

      これらの新規ノードで起動する追加の Gluster Storage Pod を確認します。

      # oc get pods

      以下に例を示します。

      # oc get pods
      NAME              READY     STATUS    RESTARTS   AGE
      glusterfs-356cf   1/1       Running   0          30d
      glusterfs-fh4gm   1/1       Running   0          30d
      glusterfs-hg4tk   1/1       Running   0          30d
      glusterfs-v759z   0/1       Running   0          1m

      追加の Gluster Storage Pod が表示されるはずです。この例では、以前の 3 つではなく 4 つの gluster Pod が表示されるはずです。それらは正常な状態になるまでに 1 - 2 分かかります (例: glusterfs-v759z 0/1 not healthy yet)。

   4. Red Hat Gluster Storage Pod が実行中であることを確認します。

      # oc get pods -o wide -l glusterfs=storage-pod

4. Heketi CLI を使用して新規ノードをクラスターに追加します。以下では、CLI を使用して、zone 1 の新規ノードを 597fceb5d6c876b899e48f599b988f54 クラスターに追加する方法を示しています。

   # heketi-cli node add --zone=1 --cluster=597fceb5d6c876b899e48f599b988f54 --management-host-name=node4.example.com --storage-host-name=192.168.10.104
   
   OUTPUT:
   Node information:
   Id: 095d5f26b56dc6c64564a9bc17338cbf
   State: online
   Cluster Id: 597fceb5d6c876b899e48f599b988f54
   Zone: 1
   Management Hostname node4.example.com
   Storage Hostname 192.168.10.104

5. Heketi CLI を使用してデバイスをクラスターに追加します。デバイスの追加に関する詳細は、「新しいデバイスの追加」を参照してください。
6. heketi を使用して、ノードが gluster の信頼済みストレージプールに追加しても自動的に更新されないため、エンドポイントを手動で更新します。エンドポイントの更新方法に関する詳細は、「新規ノードの追加後のエンドポイントの更新」 を参照してください。

1. 以下のコマンドを実行して、Red Hat Openshift Container Storage が既存プロジェクトでデプロイされ、予想通りに機能していることを確認します。

   # oc get ds

   以下に例を示します。

   # oc get ds
   NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
   glusterfs-storage   3         3         3         3            3           glusterfs=storage-host   1d

   注記

   「新規ノードの追加」セクションでステップ 1 とステップ 2 を実行して、新しいホストを追加します。追加するすべてのノードで、ステップを繰り返します。

2. 以下のコマンドを実行して、Red Hat Gluster Storage Pod が実行されているかどうかを確認します。

   # oc get pods

3. 新たに追加される各ノードのラベルを追加します。ここでは、以下のコマンドを実行して Red Hat Gluster Storage Pod が新規クラスターに追加され、実行されます。

   # oc label node <NODE_NAME> glusterfs=<node_label>

   ここで、

   • NODE_NAME: 新規に作成されたノードの名前です。
   • node_label: 既存のデーモンセットで使用される名前です。

   以下に例を示します。

   # oc label node 192.168.90.3 glusterfs=storage-host
   node "192.168.90.3" labeled

   これらの新規ノードで起動する追加の Gluster Storage Pod を確認します。

   # oc get pods

   以下に例を示します。

   # oc get pods
   NAME              READY     STATUS    RESTARTS   AGE
   glusterfs-356cf   1/1       Running   0          30d
   glusterfs-fh4gm   1/1       Running   0          30d
   glusterfs-hg4tk   1/1       Running   0          30d
   glusterfs-v759z   0/1       Running   0          1m
   glusterfs-rgs3k   0/1       Running   0          1m
   glusterfs-gtq9f   0/1       Running   0          1m

   追加の Gluster Storage Pod が表示されるはずです。この例では、以前の 3 つではなく 6 つの gluster Pod が表示されるはずです。それらは正常な状態になるまでに 1 - 2 分かかります (例: glusterfs-v759z, glusterfs-rgs3k, and glusterfs-gtq9f 0/1 not healthy yet)。

4. 以下のコマンドを実行して、Red Hat Gluster Storage Pod が実行されているかどうかを確認します。

   # oc get ds

   以下に例を示します。

   # oc get ds
   NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
   glusterfs-storage   6         6         6         6            6           glusterfs=storage-host   2h

5. 以下のコマンドを使用して、Heketi に新しいクラスターを作成します。

   # heketi-cli cluster create

6. 新しいデバイスの追加 および 新規ノードの追加 で説明されているように、新たに作成されたクラスターにノードとデバイスを追加します。

1. 以下のコマンドを使用して、障害が発生しているデバイスを探します。

   # heketi-cli topology info

   …
   …
   ...
       Nodes:
   Node Id: 8faade64a9c8669de204b66bc083b10d
   ...
   ...
   …
                   Id:a811261864ee190941b17c72809a5001   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):281     Free (GiB):218
                           Bricks:
                                   Id:34c14120bef5621f287951bcdfa774fc   Size (GiB):280     Path: /var/lib/heketi/mounts/vg_a811261864ee190941b17c72809a5001/brick_34c14120bef5621f287951bcdfa774fc/brick
   …
   …
   ...

   以下の例は、障害が発生したデバイスの置き換えに必要な操作シーケンスを説明しています。この例では、ID 8faade64a9c8669de204b66bc083b10das を持つノードに属するデバイス ID a811261864ee190941b17c72809a5001 を使用します。

2. 置き換えられるデバイスと同じノードに新しいデバイスを追加することが推奨されます。

   # heketi-cli device add --name /dev/vdd --node 8faade64a9c8669de204b66bc083b10d
   Device added successfully

3. 障害が発生したデバイスを無効にします。

   # heketi-cli device disable a811261864ee190941b17c72809a5001
   Device a811261864ee190941b17c72809a5001 is now offline

4. 障害が発生したデバイスを削除します。

   # heketi-cli device remove a811261864ee190941b17c72809a5001
   Device a811261864ee190941b17c72809a5001 is now removed

   この段階で、ブリックは障害が発生したデバイスから移行されます。Heketi は、ブリック割り当てアルゴリズムに基づいて適切なデバイスを選択します。その結果、すべてのブリックが新たに追加されたデバイスに移行されない可能性があります。

5. 障害が発生したデバイスを削除します。

   1. 以下の heketi-cli delete コマンドを使用してデバイスを削除します。

      # heketi-cli device delete a811261864ee190941b17c72809a5001
      Device a811261864ee190941b17c72809a5001 deleted

      注記

      • Heketi-cli device delete <device-ID> コマンドとともに、--force-forget オプションを使用して、障害が発生したデバイスを削除できます。ただし、このオプションは、device delete コマンドが失敗した場合のみ使用することが推奨されます。
      • システムコマンドを使って、デバイスが削除されているか、 heketi 以外でシステムがクリーンであることを確認した後にのみ、--force-forget オプションを使用する必要があります。

   2. 修復を完了できるように、performance.read-ahead オプションは無効にする必要があります。

      # gluster volume set <VOLUME> performance.read-ahead off

      注記

      ボリューム修復タスクが完了するまで performance.read-ahead オプションを OFF に設定します。修復が完了したら、デフォルト状態のON に戻します。

   3. 100,000 を超えるエントリーに修復が必要な場合は、追加の shd を開始する必要があります。追加の自己修復デーモンの起動方法は https://access.redhat.com/solutions/3794011 を参照してください。

6. 別のデバイスで上記の手順を繰り返す前に、自己修復操作が完了するのを待つ必要があります。Number of entries の値が 0 の値を返すと、自己修復操作が完了していることを確認できます。

   # oc rsh <any_gluster_pod_name>
   for each in $(gluster volume list) ; do gluster vol heal $each info | grep "Number of entries:" ; done
   Number of entries: 0
   Number of entries: 0
   Number of entries: 0

1. 以下のコマンドを使用して、障害が発生しているノードを探します。

   # heketi-cli topology info
   
   …
   …
   ...
       Nodes:
   Node Id: 8faade64a9c8669de204b66bc083b10d
   ...
   ...
   …
             Id:a811261864ee190941b17c72809a5001   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):281     Free (GiB):218
                     Bricks:
                             Id:34c14120bef5621f287951bcdfa774fc   Size (GiB):280     Path: /var/lib/heketi/mounts/vg_a811261864ee190941b17c72809a5001/brick_34c14120bef5621f287951bcdfa774fc/brick
   …
   …
   ...

   以下の例は、障害が発生したノードの置き換えに必要な操作シーケンスを説明しています。この例では、ノード ID 8faade64a9c8669de204b66bc083b10d を使用します。

   OCP クラスターを拡張して、置き換え用のノードを追加します。ノードの追加方法に関する詳細は、「新規ノードの追加」セクションの手順を参照してください。

   注記

   置き換え用のノードがすでに OCP クラスターの一部である場合は、このステップを省略してステップ 2 に進みます。

2. 交換するノードと同じ数のデバイスとサイズの新しいノードを追加することを推奨します。「新規ノードの追加」 の手順を参照してください。

   # heketi-cli node add --zone=1 --cluster=597fceb5d6c876b899e48f599b988f54 --management-host-name=node4.example.com --storage-host-name=192.168.10.104
   
   # heketi-cli device add --name /dev/vdd --node 8faade64a9c8669de204b66bc083b10d
   
   Node and device added successfully

3. 障害が発生したノードを無効にします。

   # heketi-cli node disable 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d is now offline

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

   # heketi-cli node remove 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d is now removed

   この段階で、ブリックは障害が発生したノードから移行されます。Heketi は、ブリック割り当てアルゴリズムに基づいて適切なデバイスを選択します。

5. 関連付けられたデバイスがあるノードは削除できないため、以下のコマンドを実行して、ノードに関連付けられているデバイスを削除します。

   # heketi-cli device delete <device_id>

   以下に例を示します。

   # heketi-cli device delete 56912a57287d07fad0651ba0003cf9aa
   Device 56912a57287d07fad0651ba0003cf9aa deleted

   ノード上のすべてのデバイスに対してコマンドを実行します。

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

   # heketi-cli node delete 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d deleted

   注記

   ノードからブロックを置き換える場合は、「Block Storage 上のノードの置き換え」を参照してください。

1. 作成するエンドポイントを指定するには、コピーした sample-gluster-endpoints.yaml ファイルを、環境に基づいて作成されるエンドポイントで更新します。Red Hat Gluster Storage の信頼済みストレージプールには、それぞれ、信頼済みストレージプールのノードの IP を持つ独自のエンドポイントが必要です。

   # cat sample-gluster-endpoints.yaml
   apiVersion: v1
   kind: Endpoints
   metadata:
     name: glusterfs-cluster
   subsets:
     - addresses:
         - ip: 192.168.10.100
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.101
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.102
       ports:
   - port: 1

   name

   エンドポイントの名前。

   ip

   Red Hat Gluster Storage ノードの IP アドレス。

2. 以下のコマンドを実行してエンドポイントを作成します。

   # oc create -f <name_of_endpoint_file>

   以下に例を示します。

   # oc create -f sample-gluster-endpoints.yaml
   endpoints "glusterfs-cluster" created

3. エンドポイントが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get endpoints

   以下に例を示します。

   # oc get endpoints
   NAME                       ENDPOINTS                                                     AGE
   storage-project-router     192.168.121.233:80,192.168.121.233:443,192.168.121.233:1936   2d
   glusterfs-cluster          192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3s
   heketi                     10.1.1.3:8080                                                 2m
   heketi-storage-endpoints   192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3m

4. 以下のコマンドを実行して gluster サービスを作成します。

   # oc create -f <name_of_service_file>

   以下に例を示します。

   # cat sample-gluster-service.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: glusterfs-cluster
   spec:
     ports:
   - port: 1

   # oc create -f sample-gluster-service.yaml
   service "glusterfs-cluster" created

5. サービスが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get service

   以下に例を示します。

   # oc get service
   NAME                       CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE
   storage-project-router     172.30.94.109   <none>        80/TCP,443/TCP,1936/TCP   2d
   glusterfs-cluster          172.30.212.6    <none>        1/TCP                     5s
   heketi                     172.30.175.7    <none>        8080/TCP                  2m
   heketi-storage-endpoints   172.30.18.24    <none>        1/TCP                     3m

   注記

   エンドポイントとサービスは、永続ストレージを必要とする各プロジェクトに対して作成する必要があります。

6. GlusterFS から Replica 3 の 100 G 永続ボリュームを作成し、このボリュームを記述する永続ボリュームの仕様を pv001.json ファイルに出力します。

   $ heketi-cli volume create --size=100 --persistent-volume-file=pv001.json

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null
     },
     "spec": {
       "capacity": {
         "storage": "100Gi"
       },
       "glusterfs": {
         "endpoints": "TYPE ENDPOINT HERE",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}

   重要

   Labels 情報は .json ファイルに手動で追加する必要があります。

   以下は、参照用の YAML ファイルの例です。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-storage-project-glusterfs1
     labels:
       storage-tier: gold
   spec:
     capacity:
       storage: 12Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     glusterfs:
       endpoints: TYPE END POINTS NAME HERE,
   path: vol_e6b77204ff54c779c042f570a71b1407

   name

   ボリュームの名前。

   storage

   このボリュームに割り当てられるストレージの量。

   glusterfs

   使用されているボリュームタイプ。この場合は glusterfs プラグインです。

   endpoints

   作成された信頼済みストレージプールを定義するエンドポイント名

   path

   信頼済みストレージプールからアクセスされる Red Hat Gluster Storage ボリューム。

   accessModes

   accessModes は、PV と PVC を一致させるためのラベルとして使用されます。現時点で、これらはいずれの形態のアクセス制御も定義しません。

   labels

   ラベルを使用して、ボリューム間で共有している共通の属性や特性を識別します。この例では、gluster ボリュームを定義し、storage-tier という名前のカスタム属性 (キー) を持たせて、gold という値を割り当てています。要求で storage-tier=gold を使用して PV を選択すると、その PV に一致します。

   注記

   • heketi-cli は、コマンドラインのエンドポイント名 (--persistent-volume-endpoint="TYPE ENDPOINT HERE") も受け入れます。次に、これをパイプで oc create -f - に渡して永続ボリュームをすぐに作成できます。
   • 環境内に複数の Red Hat Gluster Storage の信頼済みストレージプールがある場合は、heketi-cli volume list コマンドを使用して、ボリュームが作成される信頼済みストレージプールを確認できます。このコマンドはクラスター名を一覧表示します。次に、pv001.json ファイルのエンドポイント情報を適宜更新できます。
   • レプリカ数がデフォルト値の 3(レプリカ 3) に設定された 2 つのノードのみを持つ Heketi ボリュームを作成する場合、3 つの異なるノードに 3 つのディスクのレプリカセットを作成するスペースがないため、Heketi がエラー"No space"を表示します。
   • すべての heketi-cli 書き込み操作 (volume create、cluster create など) が失敗し、読み取り操作 (例:topology info、volume info など) に成功すると、gluster ボリュームが読み取り専用モードで動作している可能性があります。

7. pv001.json ファイルを編集し、エンドポイントのセクションにエンドポイントの名前を入力します。

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null,
       "labels": {
         "storage-tier": "gold"
       }
     },
     "spec": {
       "capacity": {
         "storage": "12Gi"
       },
       "glusterfs": {
         "endpoints": "glusterfs-cluster",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}
   }

8. 以下のコマンドを実行して永続ボリュームを作成します。

   # oc create -f pv001.json

   以下に例を示します。

   # oc create -f pv001.json
   persistentvolume "glusterfs-4fc22ff9" created

9. 永続ボリュームが作成されたことを確認するには、以下のコマンドを実行します。

   # oc get pv

   以下に例を示します。

   # oc get pv
   
   NAME                 CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
   glusterfs-4fc22ff9   100Gi      RWX           Available                       4s

10. 永続ボリューム要求ファイルを作成します。以下に例を示します。

    # cat pvc.yaml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: glusterfs-claim
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
        selector:
          matchLabels:
    storage-tier: gold

11. 以下のコマンドを実行して、永続ボリュームを永続ボリューム要求 (PVC) にバインドします。

    # oc create -f pvc.yaml

    以下に例を示します。

    # oc create -f pvc.yaml
    persistentvolumeclaim"glusterfs-claim" created

12. 永続ボリュームと永続ボリューム要求がバインドされていることを確認するには、以下のコマンドを実行します。

    # oc get pv
    # oc get pvc

    以下に例を示します。

    # oc get pv
    
    NAME                 CAPACITY   ACCESSMODES   STATUS    CLAIM                  REASON    AGE
    glusterfs-4fc22ff9   100Gi      RWX           Bound     storage-project/glusterfs-claim             1m

    # oc get pvc
    
    NAME              STATUS    VOLUME               CAPACITY   ACCESSMODES   AGE
    glusterfs-claim   Bound     glusterfs-4fc22ff9   100Gi      RWX           11s

13. この要求はアプリケーションで使用できます。以下に例を示します。

    # cat app.yaml
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: busybox
    spec:
      containers:
        - image: busybox
          command:
            - sleep
            - "3600"
          name: busybox
          volumeMounts:
            - mountPath: /usr/share/busybox
              name: mypvc
      volumes:
        - name: mypvc
          persistentVolumeClaim:
    claimName: glusterfs-claim

    # oc create -f app.yaml
    pod "busybox" created

    アプリケーションで glusterfs 要求を使用する方法についての詳細は https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-storage-examples-gluster-example を参照してください。

14. Pod が作成されたことを確認するには、以下のコマンドを実行します。

    # oc get pods -n <storage_project_name>

    以下に例を示します。

    # oc get pods -n storage-project
    
    NAME                               READY     STATUS    RESTARTS   AGE
    block-test-router-1-deploy         0/1       Running     0          4h
    busybox                            1/1       Running   0          43s
    glusterblock-provisioner-1-bjpz4   1/1       Running   0          4h
    glusterfs-7l5xf                    1/1       Running   0          4h
    glusterfs-hhxtk                    1/1       Running   3          4h
    glusterfs-m4rbc                    1/1       Running   0          4h
    heketi-1-3h9nb                     1/1       Running   0          4h

15. 永続ボリュームがコンテナー内でマウントされていることを確認するには、以下のコマンドを実行します。

    # oc rsh busybox

    / $ df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-1310998-81732b5fd87c197f627a24bcd2777f12eec4ee937cc2660656908b2fa6359129
                          100.0G     34.1M     99.9G   0% /
    tmpfs                     1.5G         0      1.5G   0% /dev
    tmpfs                     1.5G         0      1.5G   0% /sys/fs/cgroup
    192.168.121.168:vol_4fc22ff934e531dec3830cfbcad1eeae
                           99.9G     66.1M     99.9G   0% /usr/share/busybox
    tmpfs                     1.5G         0      1.5G   0% /run/secrets
    /dev/mapper/vg_vagrant-lv_root
                           37.7G      3.8G     32.0G  11% /dev/termination-log
    tmpfs                     1.5G     12.0K      1.5G   0% /var/run/secretgit s/kubernetes.io/serviceaccount

1. GID の値を指定してストレージクラスファイルを作成します。以下に例を示します。

   # cat glusterfs-storageclass.yaml
   
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: gluster-container
   provisioner: kubernetes.io/glusterfs
   parameters:
     resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
     restuser: "admin"
     secretNamespace: "default"
     secretName: "heketi-secret"
     gidMin: "2000"
   gidMax: "4000"

   注記

   gidMin 値および gidMax 値が指定されていない場合、動的にプロビジョニングされたボリュームには 2000 から 2147483647 までの GID が設定されます。

2. 永続ボリューム要求 (PVC) を作成します。詳細は、「Persistent Volume Claim(永続ボリューム要求、PVC) の作成」を参照してください。
3. Pod の要求を使用します。この Pod が特権を持たないことを確認します。詳細は、「Pod での要求の使用」を参照してください。

4. GID が指定の範囲内にあるかどうかを確認するには、以下のコマンドを実行します。

   # oc rsh busybox

   $ id

   以下に例を示します。

   $ id
   uid=1000060000 gid=0(root) groups=0(root),2001

   ここで、上記の出力の 2001 は、永続ボリュームに割り当てられた GID で、ストレージクラスで指定された範囲内にあります。割り当てられた GID を使用して、このボリュームに書き込むことができます。

   注記

   永続ボリューム要求 (PVC) が削除されると、永続ボリュームの GID がプールから解放されます。

手順

1. 必要なタグを heketi デバイスに適用します。

   # heketi-cli device settags <device-name> <key>:<value>

   例:

   # heketi-cli device settags 1fe1b83e5660efb53cc56433cedf7771 disktype:hdd

2. 適用されたタグをデバイスから削除します。

   # heketi-cli device rmtags <device-name> <key>

   例:

   # heketi-cli device rmtags 1fe1b83e5660efb53cc56433cedf7771 disktype

3. デバイスに追加されたタグを確認します。

   # heketi-cli device info <device-name>

   例:

   # heketi-cli device info 1fe1b83e5660efb53cc56433cedf7771

   出力例:

   Device Id: 1fe1b83e5660efb53cc56433cedf7771
   State: online
   Size (GiB): 49
   Used (GiB): 41
   Free (GiB): 8
   Create Path: /dev/vdc
   Physical Volume UUID: GpAnb4-gY8e-p5m9-0UU3-lV3J-zQWY-zFgO92
   Known Paths: /dev/disk/by-id/virtio-bf48c436-04a9-48ed-9 /dev/disk/by-path/pci-0000:00:08.0 /dev/disk/by-path/virtio-pci-0000:00:08.0 /dev/vdc
   Tags:
     disktype: hdd    ---> added tag

4. タグ付けされたデバイスを使用してボリュームを作成します。

    # heketi-cli volume create --size=<size in GiB> --gluster-volume-options'user.heketi.device-tag-match <key>=<value>’

   重要

   • ボリュームの作成時に、新しいボリュームオプション user.heketi.device-tag-match を渡す必要があります。ここで、オプションの値は、タグキーに続いて"=" または "!="のいずれか、これにタグの値が続きます。
   • すべての一致は完全一致であり、大文字と小文字が区別され、1 つの device-tag-match のみを指定できます。

   例:

   # heketi-cli volume create --size=5 --gluster-volume-options 'user.heketi.device-tag-match disktype=hdd’

   注記

   ボリュームが作成されると、ボリュームオプションの一覧が固定されます。tag-match ルールは、ボリューム拡張およびブリックの置き換えの目的で、ボリュームのメタデータと共に永続化されます。

5. ストレージクラスを作成します。

   • ハードディスク上にのみボリュームを作成するストレージクラスを作成します。

     # cat hdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-hdd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate

   • より高速なソリッドステートストレージだけを使用してボリュームを作成するストレージクラスを作成します。

     重要

     ハードディスクデバイスを除外する負のタグのマッチングルールを使用する必要があります。

     # cat sdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-dd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype!=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate

1. 以下のコマンドを実行して、heketi からゾーンおよびクラスター情報を取得します。

   # heketi-cli topology info --user=<user> --secret=<user key>

   --user

   heketi ユーザー

   --secret

   指定されたユーザーのシークレットキー

2. クラスター ID およびゾーン ID を取得したら、Adding New Nodes を参照して新規ノードを追加します。

3. 次のコマンドを実行してデバイスを追加します。

   # heketi-cli device add --name=<device name> --node=<node id> --user=<user> --secret=<user key>

   --name

   追加するデバイスの名前

   --node

   新たに追加されたノードの ID

   以下に例を示します。

   # heketi-cli device add --name=/dev/vdc --node=2639c473a2805f6e19d45997bb18cb9c --user=admin --secret=adminkey
   Device added successfully

4. 新規ノードとその関連デバイスを heketi に追加した後に、障害が発生したまたは不要なノードを heketi から削除できます。

   heketi からノードを削除するには、以下のワークフローに従います。

   • ノードの無効化 (オフラインにしてノードの使用の禁止する)
   • ノードの置き換え (ノードとその関連デバイスすべてを Heketi から削除する)
   • デバイスの削除 (Heketi ノードからデバイスを削除する)
   • ノードの削除 (Heketi 管理からのノードを削除する)

5. 以下のコマンドを実行して、heketi からノード一覧を取得します。

   #heketi-cli node list --user=<user> --secret=<user key>

   以下に例を示します。

   # heketi-cli node list --user=admin --secret=adminkey
   Id:05746c562d6738cb5d7de149be1dac04    Cluster:607204cb27346a221f39887a97cf3f90
   Id:ab37fc5aabbd714eb8b09c9a868163df    Cluster:607204cb27346a221f39887a97cf3f90
   Id:c513da1f9bda528a9fd6da7cb546a1ee    Cluster:607204cb27346a221f39887a97cf3f90
   Id:e6ab1fe377a420b8b67321d9e60c1ad1    Cluster:607204cb27346a221f39887a97cf3f90

6. 以下のコマンドを実行して、heketi から削除する必要があるノードのノード情報を取得します。

   # heketi-cli node info <nodeid> --user=<user> --secret=<user key>

   以下に例を示します。

   # heketi-cli node info c513da1f9bda528a9fd6da7cb546a1ee --user=admin --secret=adminkey
   Node Id: c513da1f9bda528a9fd6da7cb546a1ee
   State: online
   Cluster Id: 607204cb27346a221f39887a97cf3f90
   Zone: 1
   Management Hostname: dhcp43-171.lab.eng.blr.redhat.com
   Storage Hostname: 10.70.43.171
   Devices:
   Id:3a1e0717e6352a8830ab43978347a103   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):100     Free (GiB):399     Bricks:1
   Id:89a57ace1c3184826e1317fef785e6b7   Name:/dev/vdd            State:online    Size (GiB):499     Used (GiB):10      Free (GiB):489     Bricks:5

7. 以下のコマンドを実行して、heketi からノードを無効にします。これにより、ノードがオフラインになります。

   # heketi-cli node disable <node-id> --user=<user> --secret=<user key>

   以下に例を示します。

   # heketi-cli node disable ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
   Node ab37fc5aabbd714eb8b09c9a868163df is now offline

8. 以下のコマンドを実行して、Heketi からノードとその関連デバイスをすべて削除します。

   #heketi-cli node remove <node-id> --user=<user> --secret=<user key>

   以下に例を示します。

   # heketi-cli node remove ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
   Node ab37fc5aabbd714eb8b09c9a868163df is now removed

9. 以下のコマンドを実行して、heketi ノードからデバイスを削除します。

   # heketi-cli device delete <device-id> --user=<user> --secret=<user key>

   以下に例を示します。

   # heketi-cli device delete 0fca78c3a94faabfbe5a5a9eef01b99c --user=admin --secret=adminkey
   Device 0fca78c3a94faabfbe5a5a9eef01b99c deleted

10. 以下のコマンドを実行して、Heketi 管理からノードを削除します。

    #heketi-cli node delete <nodeid> --user=<user> --secret=<user key>

    以下に例を示します。

    # heketi-cli node delete ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
    Node ab37fc5aabbd714eb8b09c9a868163df deleted

11. いずれかの gluster Pod で以下のコマンドを実行して、障害のあるノードを新しいノードに置き換えます。

    1. 以下のコマンドを実行して、block-hosting-volume 配下でホストされるブロックボリュームの一覧を取得します。

       # gluster-block list <block-hosting-volume> --json-pretty

    2. 以下のコマンドを実行して、ブロックボリュームをホストするサーバーの一覧を取得し、後で使用できるように GBID および PASSWORD の値を保存します。

       # gluster-block info <block-hosting-volume>/<block-volume> --json-pretty

    3. 以下のコマンドを実行して、障害のあるノードを新しいノードに置き換えます。

       # gluster-block replace <volname/blockname> <old-node> <new-node> [force]

       以下に例を示します。

       {
         "NAME":"block",
         "CREATE SUCCESS":"192.168.124.73",
         "DELETE SUCCESS":"192.168.124.63",
         "REPLACE PORTAL SUCCESS ON":[
           "192.168.124.79"
         ],
         "RESULT":"SUCCESS"
       }
       
       Note: If the old node is down and does not come up again then you can force replace:
       gluster-block replace sample/block 192.168.124.63 192.168.124.73 force --json-pretty
       
       {
         "NAME":"block",
         "CREATE SUCCESS":"192.168.124.73",
         "DELETE FAILED (ignored)":"192.168.124.63",
         "REPLACE PORTAL SUCCESS ON":[
           "192.168.124.79"
         ],
         "RESULT":"SUCCESS"
       }

    注記

    次の手順は、置き換えるブロックがまだ使用中の場合にのみ実行されます。

12. ブロックボリュームが現在マウントされていない場合は、この手順を省略します。ブロックボリュームがアプリケーションで使用されている場合は、イニシエーター側でマッパーデバイスをリロードする必要があります。

    1. イニシエーターノードとターゲット名を特定します。

       イニシエーターノードを把握するには、以下を実行します。

       # oc get pods -o wide | grep <podname>

       ここで、podname は、ブロックボリュームがマウントされる Pod の名前です。

       以下に例を示します。

       # oc get pods -o wide | grep cirros1 cirros1-1-x6b5n   1/1       Running   0          1h        10.130.0.5     dhcp46-31.lab.eng.blr.redhat.com    <none>

       ターゲット名を把握するには、以下を実行します。

       # oc describe pv <pv_name> | grep IQN

       以下に例を示します。

       # oc describe pv pvc-c50c69db-5f76-11ea-b27b-005056b253d1 | grep IQN
         IQN: iqn.2016-12.org.gluster-block:87ffbcf3-e21e-4fa5-bd21-7db2598e8d3f

    2. イニシエーターノードで以下のコマンドを実行して、マッパーデバイスを把握します。

       # mount | grep <targetname>

    3. マッパーデバイスを再読み込みします。

       # multipath -r mpathX

       以下に例を示します。

       # mount | grep iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a/dev/mapper/mpatha on /var/lib/origin/openshift.local.volumes/plugins/kubernetes.io/iscsi/iface-default/192.168.124.63:3260-iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a-lun-0 type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
       # multipath -r mpatha

13. イニシエーターで以下のコマンドを実行し、古いポータルからログアウトします。

    # iscsiadm -m node -T <targetname> -p <old node> -u

    以下に例を示します。

    # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.63 -u
    Logging out of session [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260]
    Logout of [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260] successful.

14. 新しいノードを再検出するには、以下のコマンドを実行します。

    # iscsiadm -m discovery -t st -p <new node>

    以下に例を示します。

    # iscsiadm -m discovery -t st -p 192.168.124.73
    192.168.124.79:3260,1 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a
    192.168.124.73:3260,2 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a

15. 以下を実行して新しいポータルにログインします。

    1. 認証の認証情報を更新します (ステップ 11ii の GBID および PASSWORD を使用)

       # iscsiadm -m node -T <targetname> -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v <GBID> -n node.session.auth.password -v <PASSWORD> -p <new node ip>

    2. 新しいポータルにログインします。

       # iscsiadm -m node -T <targetname> -p <new node ip> -l

       以下に例を示します。

       # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -n node.session.auth.password -v a6a9081f-3d0d-4e8b-b9b0-d2be703b455d -p 192.168.124.73
       # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.73 -l

16. 有効にしたホストボリュームが正常に置き換えられ、実行されているかどうかを確認するには、イニシエーターで以下のコマンドを実行します。

    # ll /dev/disk/by-path/ip-* | grep <targetname> | grep <“new node ip”>

17. gluster ブロックの永続ボリューム (PV) を新しい IP アドレスで更新してください。

    PV は定義によって不変であるため、PV を編集することはできません。つまり、PV の古い IP アドレスを変更できません。この問題を回避する手順 (新しい PV を作成し、ストレージデバイスで古い PV 定義を削除) を含むドキュメントが作成されました。Red Hat ナレッジベースソリューションの Gluster block PVs are not updated with new IPs after gluster node replacement を参照してください。

1. /var/lib/glusterd/secure-access ファイルを作成します。

   # touch /var/lib/glusterd/secure-access

1. /var/lib/glusterd/secure-access ファイルを作成します。

   # touch /var/lib/glusterd/secure-access

1. さらなる手順に進む前に、Red Hat Openshift Container Storage がデプロイされていることを確認します。詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Setting_the_environment-Deploy_CNS を参照してください。

2. 静的にプロビジョニングされたボリュームまたは動的にプロビジョニングされたボリュームを作成できます。ボリュームの静的プロビジョニングの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Static_Prov を参照してください。ボリュームの動的プロビジョニングに関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov を参照してください。

   注記

   静的にプロビジョニングされたボリュームの作成時に暗号化を有効にするには、以下のコマンドを実行します。

    # heketi-cli volume create --size=100 --gluster-volume-options="client.ssl on","server.ssl on"

3. 以下のコマンドを実行してボリュームを停止します。

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   gluster pod nameは、ボリュームが属する信頼済みストレージプールの Red Hat Gluster Storage Pod のいずれかの名前です。

   注記

   VOLNAME を取得するには、以下のコマンドを実行します。

   # oc describe pv <pv_name>

   以下に例を示します。

   # oc describe pv  pvc-01569c5c-1ec9-11e7-a794-005056b38171
   Name:           pvc-01569c5c-1ec9-11e7-a794-005056b38171
   Labels:         <none>
   StorageClass:   fast
   Status:         Bound
   Claim:          storage-project/storage-claim68
   Reclaim Policy: Delete
   Access Modes:   RWO
   Capacity:       1Gi
   Message:
   Source:
       Type:               Glusterfs (a Glusterfs mount on the host that shares a pod's lifetime)
       EndpointsName:      glusterfs-dynamic-storage-claim68
       Path:               vol_0e81e5d6e46dcbf02c11ffd9721fca28
       ReadOnly:           false
   No events.

   VOLNAME は、上記の出力の"path"の値です。

4. ボリュームにアクセスする全サーバーの共通名の一覧を設定します。ボリュームにアクセスできるクライアントの共通名を含めるようにしてください。

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'

   注記

   auth.ssl-allow オプションの値として* を設定すると、TLS 認証されたクライアントはアプリケーション側からボリュームをマウントおよびアクセスできます。したがって、オプションの値を * に設定するか、または信頼済みストレージプールのノードおよびクライアントの共通名を指定します。

5. ボリュームで client.ssl オプションおよび server.ssl オプションを有効にします。

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
   # oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

6. ボリュームを起動します。

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

1. Red Hat Gluster Storage ボリュームを持つすべてのアプリケーション Pod を停止します。

2. ボリュームを停止します。

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   gluster pod nameは、ボリュームが属する信頼済みストレージプールの Red Hat Gluster Storage Pod のいずれかの名前です。

3. ボリュームにアクセスできるクライアントの共通名の一覧を設定します。すべてのサーバーの共通名を含めるようにしてください。

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'

   注記

   auth.ssl-allow オプションの値として* を設定すると、TLS 認証されたクライアントはアプリケーション側からボリュームをマウントおよびアクセスできます。したがって、オプションの値を * に設定するか、または信頼済みストレージプールのノードおよびクライアントの共通名を指定します。

4. 以下のコマンドを使用して、ボリュームで client.ssl および server.ssl を有効にします。

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
   # oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

5. ボリュームを起動します。

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

6. アプリケーション Pod を起動し、I/O が暗号化された Red Hat Gluster Storage ボリュームを使用します。

1. Red Hat Gluster Storage ボリュームを持つすべてのアプリケーション Pod を停止します。

2. すべてのボリュームを停止します。

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Red Hat Gluster Storage Pod を停止します。

   # oc delete daemonset glusterfs-storage

4. デーモンセットを削除すると、Pod がダウンします。Pod がダウンしているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

5. すべての OpenShift ノードに /var/lib/glusterd/secure-access ファイルを作成します。

   # touch /var/lib/glusterd/secure-access

6. 以下のコマンドを実行して、Red Hat Gluster Storage daemonset を作成します。

   注記

   Ansible デプロイメントでは、コマンドを実行する前に、イメージ名とバージョンをテンプレートで指定する必要があります。

   # oc process glusterfs | oc create -f -

7. デーモンセットを作成すると、Pod が起動します。Pod が起動しているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

8. すべてのボリュームを起動します。

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

9. アプリケーション Pod を起動して、管理が暗号化された Red Hat Gluster Storage を使用します。

1. Red Hat Gluster Storage ボリュームを持つすべてのアプリケーション Pod を停止します。

2. すべてのボリュームを停止します。

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. ボリュームの暗号化オプションをすべてリセットします。

   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME auth.ssl-allow
   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME client.ssl
   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME server.ssl

4. すべての OpenShift ノードで以下のコマンドを使用して、ネットワークの暗号化に使用したファイルを削除します。

   # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca

   注記

   管理暗号化が有効なセットアップでこれらのファイルを削除すると、glusterd がすべての gluster Pod で失敗するため、回避する必要があります。

5. Red Hat Gluster Storage Pod を停止します。

   # oc delete daemonset glusterfs

6. デーモンセットを削除すると、Pod がダウンします。Pod がダウンしているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

7. 以下のコマンドを実行して、Red Hat Gluster Storage daemonset を作成します。

   注記

   Ansible デプロイメントでは、コマンドを実行する前に、イメージ名とバージョンをテンプレートで指定する必要があります。

   # oc process glusterfs | oc create -f -

8. デーモンセットを作成すると、Pod が起動します。Pod が起動しているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

9. ボリュームを起動します。

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. アプリケーション Pod を起動し、I/O が暗号化された Red Hat Gluster Storage ボリュームを使用します。

1. Red Hat Gluster Storage ボリュームを持つすべてのアプリケーション Pod を停止します。

2. すべてのボリュームを停止します。

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Red Hat Gluster Storage Pod を停止します。

   # oc delete daemonset glusterfs

4. デーモンセットを削除すると、Pod がダウンします。Pod がダウンしているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

5. すべての OpenShift ノードで /var/lib/glusterd/secure-access ファイルを削除して、管理暗号化を無効にします。

   # rm /var/lib/glusterd/secure-access

6. すべての OpenShift ノードで以下のコマンドを使用して、ネットワークの暗号化に使用したファイルを削除します。

   # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca

7. 以下のコマンドを実行して、Red Hat Gluster Storage daemonset を作成します。

   注記

   Ansible デプロイメントでは、コマンドを実行する前に、イメージ名とバージョンをテンプレートで指定する必要があります。

   # oc process glusterfs | oc create -f -

8. デーモンセットを作成すると、Pod が起動します。Pod が起動しているかどうかを確認するには、以下のコマンドを実行します。

   # oc get pods

9. すべてのボリュームを起動します。

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. アプリケーション Pod を起動して、管理が暗号化された Red Hat Gluster Storage を使用します。