Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第6章 コンバージドモードでのRed Hat Openshift Container Storageのアップグレード

本章では、ハイパーコンバージドモード 3.10 の Container Storage から Red Hat Openshift Container Storage をコンバージドモード 3.11 で環境をアップグレードする手順を説明します。

注記
  • 本書では、新しいレジストリー名 registry.redhat.io が使用されます。ただし、新規のregistryにまだ移行していない場合は、すべてのregistry.redhat.ioをregistry.access.redhat.comに置き換えます（該当する場合）。
  • 同じアップグレード手順に従って、インデペンデントモード 3.11.0 以上からコンバージドモード 3.11.8 の Red Hat Openshift Container Storage にお使いの環境をアップグレードしてください。アップグレードプロセスを開始する前に、正しいイメージとバージョン番号が設定されていることを確認してください。

  • Red Hat Openshift Container Storage 3.11.8 の有効なイメージは以下のとおりです。

    • registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.8
    • registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.8
    • registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
    • registry.redhat.io/rhgs3/rhgs-s3-server-rhel7:v3.11.8

6.1. glusterfs グループの Pod のアップグレード
リンクのコピー

以下のセクションでは、Glusterfs Pod をアップグレードする手順を説明します。

6.1.1. 前提条件
リンクのコピー

以下の前提条件を満たしていることを確認します。

注記

cns-deploy ツールを使用するデプロイメントの場合、テンプレートは以下の場所にあります。

  • gluster テンプレート - /usr/share/heketi/templates/glusterfs-template.yaml
  • heketi テンプレート - /usr/share/heketi/templates/heketi-template.yaml
  • glusterblock-provisioner テンプレート - /usr/share/heketi/templates/glusterblock-provisioner.yaml

Ansible Playbook を使用するデプロイメントの場合、テンプレートは以下の場所にあります。

  • gluster テンプレート - /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterfs-template.yml
  • heketi テンプレート - /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/heketi-template.yml
  • glusterblock-provisioner テンプレート - /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml

6.1.2. /dev/log の元のラベル値の復元
リンクのコピー

注記

Red Hat Container Native Storage 3.9 から Red Hat Openshift Container Storage 3.11.8 に環境をアップグレードする場合にのみ、この手順を行ってください。

Red Hat Openshift Container Storage 3.10 以降から Red Hat Openshift Container Storage 3.11.8 に環境を アップグレードする場合は、この手順を省略します。

元の selinux ラベルを復元するには、以下のコマンドを実行します。

  1. gluster Pod を実行するすべてのノードにディレクトリーおよびソフトリンクを作成します。 

    # mkdir /srv/<directory_name>
# cd /srv/<directory_name>/   # same dir as above
# ln -sf /dev/null systemd-tmpfiles-setup-dev.service
# ln -sf /dev/null systemd-journald.service
# ln -sf /dev/null systemd-journald.socket

  2. oc クライアントを持つノードで glusterfs Pod を作成する daemonset を編集します。 

    # oc edit daemonset <daemonset_name>

    volumeMounts セクションで、ボリュームのマッピングを追加します。 

    - mountPath: /usr/lib/systemd/system/systemd-journald.service
  name: systemd-journald-service
- mountPath: /usr/lib/systemd/system/systemd-journald.socket
  name: systemd-journald-socket
- mountPath: /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service
name: systemd-tmpfiles-setup-dev-service

    volumes セクションで、一覧表示されているる各サービスに新しいホストパスを追加します。

    注記

    ここで説明したパスは、手順 1 に記載のものと同じである必要があります。 

    - hostPath:
   path: /srv/<directory_name>/systemd-journald.socket
   type: ""
  name: systemd-journald-socket
- hostPath:
   path: /srv/<directory_name>/systemd-journald.service
   type: ""
  name: systemd-journald-service
- hostPath:
   path: /srv/<directory_name>/systemd-tmpfiles-setup-dev.service
   type: ""
name: systemd-tmpfiles-setup-dev-service

  3. gluster Pod を実行するすべてのノードで以下のコマンドを実行します。これにより、ラベルがリセットされます。 

    # restorecon /dev/log

  4. 以下のコマンドを実行して、すべてのボリュームの自己修復のステータスを確認します。 

    # oc rsh <gluster_pod_name>
# for each_volume in `gluster volume list`; do gluster volume heal $each_volume info ; done  | grep  "Number of entries: [^0]$"

    自己修復が完了するまで待ちます。

  5. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。 

    # df -kh | grep -v ^Filesystem | awk '{if(int($5)>90) print $0}'
    注記

    ブリックの使用率が100％に近い場合、これらのブリックの論理ボリュームマネージャー（LVM）のアクティブ化に時間がかかるか、Pod またはノードを再起動するとスタックする可能性があります。そのブリックの使用率を下げるか、論理ボリューム（LV）を使用している物理ボリューム（PV）を拡張することをお勧めします。

    注記

    df コマンドは、Block Hosting Volume(BHV)に属するブリックには適用できません。BHV では、df コマンドで生成されたブリックの 使用済み サイズは、その Gluster ボリュームのブロックサブボリュームの追加サイズであり、ブロックボリュームにあるデータのサイズではありません。詳細は、How To Identify Block Volumes and Block Hosting Volumes in Openshift Container Storage を参照してください。

  6. gluster Podのいずれかで以下のコマンドを実行し、glusterfsd プロセスの1つのインスタンスで実行可能なブリックの最大数（250）を設定します。 

    # gluster volume set all cluster.max-bricks-per-process 250

    1. gluster Pod のいずれかで以下のコマンドを実行し、オプションが正しく設定されていることを確認します。 

      # gluster volume get all cluster.max-bricks-per-process

      以下は例になります。 

      # gluster volume get all cluster.max-bricks-per-process
cluster.max-bricks-per-process 250

  7. oc クライアントがあるノードで以下のコマンドを実行し、gluster Pod を削除します。 

    # oc delete pod <gluster_pod_name>

  8. Pod の準備ができているかどうかを確認するには、以下のコマンドを実行します。 

    # oc get pods -l glusterfs=storage-pod

  9. Pod をホストするノードにログインし、/dev/log の selinux ラベルを確認します。 

    # ls -lZ /dev/log

    出力に devlog_t ラベルが表示されるはずです。

    以下は例になります。 

    #  ls -lZ /dev/log
srw-rw-rw-. root root system_u:object_r:devlog_t:s0    /dev/log

    ノードを終了します。

  10. gluster Pod で、ラベル値が devlog_t かどうかを確認します。 

    # oc rsh <gluster_pod_name>
# ls -lZ /dev/log

    以下は例になります。 

    #  ls -lZ /dev/log
srw-rw-rw-. root root system_u:object_r:devlog_t:s0    /dev/log
  11. 他の Pod に対して、ステップ 4 から 9 を実行します。

6.1.3. 既存のバージョンが cns-deploy を使用してデプロイされている場合のアップグレード
リンクのコピー

6.1.3.1. cns-deploy および Heketi Server のアップグレード
リンクのコピー

以下のコマンドは、クライアントマシンで実行する必要があります。

  1. 以下のコマンドを実行して、heketi クライアントパッケージおよび cns-deploy パッケージを更新します。 

    # yum update cns-deploy -y
# yum update heketi-client -y

  2. Heketi データベースファイルのバックアップを作成します。 

    # heketi-cli db dump > heketi-db-dump-$(date -I).json

    • 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

      OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。 

      oc get secret <heketi-admin-secret> -o jsonpath='{.data.key}'|base64 -d;echo

  3. 以下のコマンドを実行して、heketi テンプレートを削除します。 

    # oc delete templates heketi

  4. 以下のコマンドを実行して、heketi テンプレートをインストールします。 

    oc create -f /usr/share/heketi/templates/heketi-template.yaml
template "heketi" created

  5. 以下のコマンドを実行して、heketi サービスアカウントに必要な権限を付与します。 

    # oc policy add-role-to-user edit system:serviceaccount:<project_name>:heketi-service-account
# oc adm policy add-scc-to-user privileged -z heketi-service-account

    以下に例を示します。 

    # oc policy add-role-to-user edit system:serviceaccount:storage-project:heketi-service-account
# oc adm policy add-scc-to-user privileged -z heketi-service-account

  6. 以下のコマンドを実行して、新しい heketi 設定ファイルを生成します。 

    # sed -e "s/\${HEKETI_EXECUTOR}/kubernetes/" -e "s#\${HEKETI_FSTAB}#/var/lib/heketi/fstab#" -e "s/\${SSH_PORT}/22/" -e "s/\${SSH_USER}/root/" -e "s/\${SSH_SUDO}/false/" -e "s/\${BLOCK_HOST_CREATE}/true/" -e "s/\${BLOCK_HOST_SIZE}/500/" "/usr/share/heketi/templates/heketi.json.template" > heketi.json
    • BLOCK_HOST_SIZE パラメーターは、gluster-block ボリュームをホストする自動作成された Red Hat Gluster Storage ボリュームのサイズ（GB 単位）を制御します（詳細はhttps://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index#Block_Storageを参照してください）。このデフォルト設定では、より多くの領域が必要になるため、500GB のブロックホスティングボリュームを動的に作成します。

    • または、/usr/share/heketi/templates/heketi.json.template を現在のディレクトリーの heketi.json にコピーし、新規ファイルを直接編集して、各"${VARIABLE}"文字列を必要なパラメーターに置き換えます。

      注記

      JSON フォーマットが厳密に必要とされています（末尾にスペースを入れない、ブール値はすべて小文字など）。

  7. 以下のコマンドを実行して、設定ファイルを保持するためのシークレットを作成します。 

    # oc create secret generic <heketi-config-secret> --from-file=heketi.json
    注記

    heketi-config-secret ファイルがすでに存在する場合は、ファイルを削除して以下のコマンドを実行します。

  8. 以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。 

    # oc delete deploymentconfig,service,route heketi
    注記

    これらのパラメーターの名前は、以下のコマンドの出力から参照することができます。 

    # oc get all | grep heketi

  9. heketi テンプレートを編集します。

    • HEKETI_USER_KEY パラメーターおよび HEKETI_ADMIN_KEY パラメーターを編集します。 

      # oc edit template heketi
parameters:
- description: Set secret for those creating volumes as type user
  displayName: Heketi User Secret
  name: HEKETI_USER_KEY
  value: <heketiuserkey>
- description: Set secret for administration of the Heketi service as user admin
  displayName: Heketi Administrator Secret
  name: HEKETI_ADMIN_KEY
  value: <adminkey>
- description: Set the executor type, kubernetes or ssh
  displayName: heketi executor type
  name: HEKETI_EXECUTOR
  value: kubernetes
- description: Set the hostname for the route URL
  displayName: heketi route name
  name: HEKETI_ROUTE
  value: heketi-storage
- displayName: heketi container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
- displayName: heketi container image version
  name: IMAGE_VERSION
  required: true
  value: v3.11.8
- description: A unique name to identify this heketi service, useful for running
    multiple heketi instances
  displayName: GlusterFS cluster name
  name: CLUSTER_NAME
  value: storage
      注記

      クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。

    • HEKETI_LVM_WRAPPER および値 /usr/sbin/exec-on-host を指定して、ENV を追加します。 

      - description: Heketi can use a wrapper to execute LVM commands, i.e. run commands
in the host namespace instead of in the Gluster container.
displayName: Wrapper for executing LVM commands
name: HEKETI_LVM_WRAPPER
value: /usr/sbin/exec-on-host

    • HEKETI_DEBUG_UMOUNT_FAILURES という名前で、値が true の ENV を追加します。 

      - description: When unmounting a brick fails, Heketi will not be able to cleanup the
Gluster volume completely. The main causes for preventing to unmount a brick,
seem to originate from Gluster processes. By enabling this option, the heketi.log
will contain the output of 'lsof' to aid with debugging of the Gluster processes
and help with identifying any files that may be left open.
displayName: Capture more details in case brick unmounting fails
name: HEKETI_DEBUG_UMOUNT_FAILURES
required=true
    • HEKETI_CLI_USER という名前で、値が admin の ENV を追加します。
    • HEKETI_CLI_KEYという名前で、ENV HEKETI_ADMIN_KEYに指定されているものと同じ値のENVを追加します。

    • アップグレードするバージョンに応じて、IMAGE_VERSION の下の value を v3.11.5 または v3.11.8 に置き換えます。 

      - displayName: heketi container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
- displayName: heketi container image version
  name: IMAGE_VERSION
  required: true
  value: v3.11.8

  10. 以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。 

    # oc process heketi | oc create -f -

  service "heketi" created
  route "heketi" created
deploymentconfig "heketi" created
    注記

    db ワークロード用に、heketidbstorage ボリュームを調整することを推奨します。新たにインストールされた Openshift Container Storage デプロイメントにより、heketidbstorage ボリュームが自動的にチューニングされます。古いデプロイメントの場合は、KCS の記事 Planning to run containerized DB or nosql workloads on Openshift Container Storage? に従って、ボリューム heketidbstorage のボリュームセット操作を実行します。

  11. 以下のコマンドを実行して、コンテナーが実行していることを確認します。 

    # oc get pods

    以下は例になります。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
heketi-storage-4-9fnvz                        2/2       Running   0          8d

6.1.3.2. Red Hat Gluster Storage Pod のアップグレード
リンクのコピー

以下のコマンドは、クライアントマシンで実行する必要があります。

以下は、glusterfs の DaemonSet を更新する手順です。

  1. 以下の手順を実行して、Heketi Pod を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。

    1. 以下のコマンドを実行して、プロジェクトにアクセスします。 

      # oc project <project_name>

      以下は例になります。 

      # oc project storage-project

    2. 以下のコマンドを実行して、DeploymentConfig を取得します。 

      # oc get ds

    3. 以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。 

      # heketi-cli server mode set local-client

    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。 

      # heketi-cli server operations info

    5. 以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。 

      # oc scale dc <heketi_dc> --replicas=0

    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。 

      # oc get pods

  2. 以下のコマンドを実行して、gluster の DaemonSet 名を検索します。 

    # oc get ds

  3. 以下のコマンドを実行して、DaemonSet を削除します。 

    # oc delete ds <ds-name> --cascade=false

    古い DaemonSet を削除する際に --cascade=false オプションを使用しても、gluster Pod は削除されず、DaemonSet のみが削除されます。古い DaemonSet を削除したら、新しい DaemonSet をロードする必要があります。古い Pod を手動で削除すると、作成される新しい Pod には新しい DaemonSet の設定が含まれます。

    以下に例を示します。 

    # oc delete ds glusterfs --cascade=false
daemonset "glusterfs" deleted

  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。 

    # oc get pods

    以下に例を示します。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。 

    # oc delete templates glusterfs

    以下に例を示します。 

    # oc delete templates glusterfs
template “glusterfs” deleted

  6. 以下のコマンドを実行して、新しい glusterfs テンプレートを登録します。 

    # oc create -f /usr/share/heketi/templates/glusterfs-template.yaml

    以下に例を示します。 

    # oc create -f /usr/share/heketi/templates/glusterfs-template.yaml
  template “glusterfs” created

  7. Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。

    1. 以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。 

      # oc get nodes -l glusterfs=storage-host

  8. glusterfs テンプレートを編集します。

    • 以下のコマンドを実行します。 

      # oc edit template glusterfs

    • ボリュームマウントの下に以下の行を追加します。 

       - name: kernel-modules
   mountPath: "/usr/lib/modules"
   readOnly: true
 - name: host-rootfs
   mountPath: "/rootfs"

    • ボリュームの下に以下の行を追加します。 

       - name: kernel-modules
   hostPath:
   path: "/usr/lib/modules"
 - name: host-rootfs
   hostPath:
   path: "/"

    • アップグレードするバージョンに応じて、IMAGE_VERSION の下の value を v3.11.5 または v3.11.8 に置き換えます。 

      - displayName: heketi container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
- displayName: heketi container image version
  name: IMAGE_VERSION
  required: true
  value: v3.11.8

  9. 以下のコマンドを実行して、gluster DaemonSet を作成します。 

    # oc process glusterfs | oc create -f -

    以下に例を示します。 

    # oc process glusterfs | oc create -f -
Deamonset “glusterfs” created
    注記

    クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。

  10. 以下のコマンドを実行して、削除する必要のある古い gluster Pod を特定します。 

    # oc get pods

    以下に例を示します。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  11. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。 

    # df -kh | grep -v ^Filesystem | awk '{if(int($5)>90) print $0}'
    注記

    ブリックの使用率が100％に近い場合、これらのブリックの論理ボリュームマネージャー（LVM）のアクティブ化に時間がかかるか、Pod またはノードを再起動するとスタックする可能性があります。そのブリックの使用率を下げるか、論理ボリューム（LV）を使用している物理ボリューム（PV）を拡張することをお勧めします。

    注記

    df コマンドは、Block Hosting Volume(BHV)に属するブリックには適用できません。BHV では、df コマンドで生成されたブリックの 使用済み サイズは、その Gluster ボリュームのブロックサブボリュームの追加サイズであり、ブロックボリュームにあるデータのサイズではありません。詳細は、How To Identify Block Volumes and Block Hosting Volumes in Openshift Container Storage を参照してください。

  12. 以下のコマンドを実行して、古い gluster Pod を削除します。Gluster Pod はローリングアップグレードに従う必要があります。したがって、次の古い gluster Pod を削除する前に、新しい Pod が実行されていることを確認する必要があります。OnDelete Strategy DaemonSet 更新ストラテジーをサポートします。OnDelete Strategy 更新ストラテジーにより、DaemonSet テンプレートの更新後、新しい DaemonSet Pod は、古い DaemonSet Pod を手動で削除した場合にのみ作成されます。

    1. 以下のコマンドを実行して、古い gluster Pod を削除します。 

      # oc delete pod <gluster_pod>

      以下に例を示します。 

      # oc delete pod glusterfs-0vcf3
pod  “glusterfs-0vcf3” deleted
      注記

      次の Pod を削除する前に、自己修復チェックを行う必要があります。

      1. 以下のコマンドを実行して、gluster Pod のシェルにアクセスします。 

        # oc rsh <gluster_pod_name>

      2. 以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。 

        # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"

    2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。 

      # oc get pods -w
  NAME                             READY     STATUS        RESTARTS   AGE
  glusterfs-0vcf3                  1/1       Terminating   0          3d
…

  13. 以下のコマンドを実行して、Pod が実行していることを確認します。 

    # oc get pods

    以下に例を示します。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  14. 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。 

    # oc rsh <gluster_pod_name> glusterd --version

    以下は例になります。 

     # oc rsh glusterfs-4cpcc glusterd --version
glusterfs 6.0

  15. gluster Pod のいずれかで以下のコマンドを実行し、Red Hat Gluster Storage op-version を確認します。 

    # gluster vol get all cluster.op-version

  16. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

    • DC（デプロイメント設定）をスケールアップします。 

      # oc scale dc <heketi_dc> --replicas=1

  17. いずれかの Pod で cluster.op-version を 70200 に設定します。

    重要

    cluster.op-version を変更する前に、すべての gluster Pod が更新されていることを確認します。 

    # gluster --timeout=3600 volume set all cluster.op-version 70200

    • 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

      注記

      "server.tcp-user-timeout" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。

      これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。

      1. 以下のコマンドを使用して glusterfs Pod を一覧表示します。 

        # oc get pods

        以下は例になります。 

        # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

      2. glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。 

        # oc rsh glusterfs-0vcf3

      3. 以下のコマンドを実行します。 

        # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done

        以下は例になります。 

        # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
  volume1
  volume set: success
  volume2
volume set: success

  18. gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。 

    # oc delete dc glusterblock-provisioner-dc

    以下は例になります。 

    # oc delete dc glusterblock-storage-provisioner-dc

  19. 古い Pod から以下のリソースを削除します。 

    # oc delete clusterroles.authorization.openshift.io glusterblock-provisioner-runner
# oc delete serviceaccounts glusterblock-provisioner
serviceaccount "glusterblock-provisioner" deleted
# oc delete clusterrolebindings.authorization.openshift.io glusterblock-provisioner

  20. 以下のコマンドを実行して、gluster-block プロビジョナーをデプロイします。 

    `sed -e 's/${NAMESPACE}/<NAMESPACE>/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | sed -e 's/<VERSION>/<NEW-VERSION>/' | oc create -f -
    <VERSION>
    OpenShift Container Storage の既存のバージョン。
    <NEW-VERSION>

    アップグレードするバージョンに応じて、3.11.5 または 3.11.8 のいずれか。 

    # oc adm policy add-cluster-role-to-user glusterblock-provisioner-runner system:serviceaccount:<NAMESPACE>:glusterblock-provisioner

    以下は例になります。 

    `sed -e 's/${NAMESPACE}/storage-project/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | sed -e 's/3.11.4/3.11.8/' | oc create -f -
     
    # oc adm policy add-cluster-role-to-user glusterblock-provisioner-runner system:serviceaccount:storage-project:glusterblock-provisioner

  21. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

    1. Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。 

      # oc rsh <gluster_pod_name>

    2. ブリックの多重化ステータスを確認します。 

      # gluster v get all all

    3. 無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。

      注記

      ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。 

      # gluster volume set all cluster.brick-multiplex on

      以下は例になります。 

      # oc rsh glusterfs-770ql

  sh-4.2# gluster volume set all cluster.brick-multiplex on
  Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
volume set: success

    4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

      以下は例になります。 

      # gluster volume list

  heketidbstorage
  vol_194049d2565d2a4ad78ef0483e04711e
  ...
  ...

      すべてのボリュームを再起動します。この手順は、ボリュームセットの操作が前の手順と一緒に実行される場合にのみ必要です。 

      # gluster vol stop <VOLNAME>
# gluster vol start <VOLNAME>
  22. Red Hat Openshift Container Storage での S3 と互換性のあるオブジェクトストアのサポートは、テクノロジープレビュー機能となっています。S3 と互換性のあるオブジェクトストアを有効にするには、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html/operations_guide/s3_object_store を参照してください。
注記

6.1.4. 既存のバージョンが Ansible を使用してデプロイされている場合のアップグレード
リンクのコピー

6.1.4.1. Heketi サーバーのアップグレード
リンクのコピー

以下のコマンドは、クライアントマシンで実行する必要があります。

  1. 以下の手順を実行して、保留中のHeketi操作を確認します。

    1. 以下のコマンドを実行して、プロジェクトにアクセスします。 

      # oc project <project_name>

      以下は例になります。 

      # oc project storage-project

    2. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。 

      # heketi-cli server operations info

  2. Heketi データベースファイルのバックアップを作成します。 

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
    注記

    作成された json ファイルを使用して復元することができるため、選択した永続ストレージに保存する必要があります。

  3. 以下のコマンドを実行して、heketi クライアントパッケージを更新します。インストールされているすべての OCP ノードで、heketi-client パッケージを更新します。新しいインストールでは、いずれのOCPノードにもheketi-client rpm がインストールされていない可能性があります。 

    # yum update heketi-client -y

  4. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

    OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。 

    # oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo

  5. HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。 

    # oc describe pod <heketi-pod>

  6. 以下のコマンドを実行して、heketi テンプレートを削除します。 

    # oc delete templates heketi

  7. 以下のコマンドを実行して、heketi テンプレートをインストールします。 

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/heketi-template.yml
template "heketi" created

  8. 以下の手順を実行して、テンプレートを編集します。 

    # oc get templates
NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
			  template
glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
			  template
heketi			  Heketi service deployment  7 (3 blank)	3
template

    1. 既存のテンプレートに 2 つのパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合は、テンプレートを編集して HEKETI_USER_KEY、HEKETI_ADMIN_KEY、HEKETI_ROUTE、IMAGE_NAME、IMAGE_VERSION、CLUSTER_NAME および HEKETI_LVM_WRAPPER を以下の例のように変更します。 

      # oc edit template heketi
parameters:
  - description: Set secret for those creating volumes as type user
  displayName: Heketi User Secret
  name: HEKETI_USER_KEY
  value: <heketiuserkey>
  - description: Set secret for administration of the Heketi service as user admin
  displayName: Heketi Administrator Secret
  name: HEKETI_ADMIN_KEY
  value: <adminkey>
  - description: Set the executor type, kubernetes or ssh
  displayName: heketi executor type
  name: HEKETI_EXECUTOR
  value: kubernetes
  - description: Set the hostname for the route URL
  displayName: heketi route name
  name: HEKETI_ROUTE
  value: heketi-storage
  - displayName: heketi container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
  - displayName: heketi container image version
  name: IMAGE_VERSION
  required: true
  value: v3.11.8
  - description: A unique name to identify this heketi service, useful for running
  multiple heketi instances
  displayName: GlusterFS cluster name
  name: CLUSTER_NAME
  value: storage
  - description: Heketi can use a wrapper to execute LVM commands, i.e. run commands in the host namespace instead of in the Gluster container
  name: HEKETI_LVM_WRAPPER
  displayName: Wrapper for executing LVM commands
  value: /usr/sbin/exec-on-host

    2. テンプレートに IMAGE_NAME のみがある場合は、テンプレートを編集して HEKETI_USER_KEY、HEKETI_ADMIN_KEY、HEKETI_ROUTE、IMAGE_NAME, CLUSTER_NAME および HEKETI_LVM_WRAPPER を以下の例のように変更します。 

      # oc edit template heketi
parameters:
- description: Set secret for those creating volumes as type user
  displayName: Heketi User Secret
  name: HEKETI_USER_KEY
  value: <heketiuserkey>
- description: Set secret for administration of the Heketi service as user admin
  displayName: Heketi Administrator Secret
  name: HEKETI_ADMIN_KEY
  value: <adminkey>
- description: Set the executor type, kubernetes or ssh
  displayName: heketi executor type
  name: HEKETI_EXECUTOR
  value: kubernetes
- description: Set the hostname for the route URL
  displayName: heketi route name
  name: HEKETI_ROUTE
  value: heketi-storage
- displayName: heketi container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.8
- description: A unique name to identify this heketi service, useful for running
   multiple heketi instances
  displayName: GlusterFS cluster name
  name: CLUSTER_NAME
  value: storage
- description: Heketi can use a wrapper to execute LVM commands, i.e. run commands in the host namespace instead of in the Gluster container
  name: HEKETI_LVM_WRAPPER
  displayName: Wrapper for executing LVM commands
  value: /usr/sbin/exec-on-host
      注記

      クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。

  9. 以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。

    注記

    これらのパラメーターの名前は、以下のコマンドの出力から参照することができます。 

    # oc get all | grep heketi
     
    # oc delete deploymentconfig,service,route heketi-storage

  10. 以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。 

    # oc process heketi | oc create -f -

service "heketi" created
route "heketi" created
deploymentconfig "heketi" created
    注記

    db ワークロード用に、heketidbstorage ボリュームを調整することを推奨します。新たにインストールされた Openshift Container Storage デプロイメントにより、heketidbstorage ボリュームが自動的にチューニングされます。古いデプロイメントの場合は、KCS の記事 Planning to run containerized DB or nosql workloads on Openshift Container Storage? に従って、ボリューム heketidbstorage のボリュームセット操作を実行します。

  11. 以下のコマンドを実行して、コンテナーが実行していることを確認します。 

    # oc get pods

    以下は例になります。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

6.1.4.2. Red Hat Gluster Storage Pod のアップグレード
リンクのコピー

以下のコマンドは、クライアントマシンで実行する必要があります。

以下は、glusterfs の DaemonSet を更新する手順です。

  1. 以下の手順を実行して、Heketi Pod を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。

    1. 以下のコマンドを実行して、プロジェクトにアクセスします。 

      # oc project <project_name>

      以下は例になります。 

      # oc project storage-project

    2. 以下のコマンドを実行して、DeploymentConfig を取得します。 

      # oc get dc

    3. 以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。 

      # heketi-cli server mode set local-client

    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。 

      # heketi-cli server operations info

    5. 以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。 

      # oc scale dc <heketi_dc> --replicas=0

    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。 

      # oc get pods

  2. 以下のコマンドを実行して、gluster の DaemonSet 名を検索します。 

    # oc get ds

  3. 以下のコマンドを実行して、DaemonSet を削除します。 

    # oc delete ds <ds-name> --cascade=false

    古い DaemonSet を削除する際に --cascade=false オプションを使用しても、gluster Pod は削除されず、DaemonSet のみが削除されます。古い DaemonSet を削除したら、新しい DaemonSet をロードする必要があります。古い Pod を手動で削除すると、作成される新しい Pod には新しい DaemonSet の設定が含まれます。

    以下に例を示します。 

    # oc delete ds glusterfs-storage --cascade=false
daemonset "glusterfs-storage" deleted

  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。 

    # oc get pods

    以下に例を示します。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。 

    # oc delete templates glusterfs

  6. 以下のコマンドを実行して、新しい glusterfs テンプレートを登録します。 

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterfs-template.yml
template "glusterfs" created

  7. 以下のコマンドを実行して、古い glusterfs テンプレートを編集します。 

    # oc get templates
NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
        template
glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
        template
heketi			  Heketi service deployment  7 (3 blank)	3
template

    1. テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterfs テンプレートを更新します。以下は例になります。 

      # oc edit template glusterfs
- displayName: GlusterFS container image name
	  name: IMAGE_NAME
	  required: true
	  value: registry.redhat.io/rhgs3/rhgs-server-rhel7
- displayName: GlusterFS container image version
	  name: IMAGE_VERSION
	  required: true
	  value: v3.11.8
- description: A unique name to identify which heketi service manages this cluster, useful for running
     multiple heketi instances
  displayName: GlusterFS cluster name
  name: CLUSTER_NAME
  value: storage
      注記

      クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。

    2. テンプレートにパラメーターとしてIMAGE_NAMEしかない場合は、glusterfsテンプレートを次のように更新します。以下は例になります。 

      # oc edit template glusterfs
- displayName: GlusterFS container image name
  name: IMAGE_NAME
  required: true
  value: registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.8
- description: A unique name to identify which heketi service manages this cluster, useful for running
     multiple heketi instances
  displayName: GlusterFS cluster name
  name: CLUSTER_NAME
value: storage
      注記

      CLUSTER_NAME 変数が正しい値に設定されていることを確認します。

  8. Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。

    1. 以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。 

      # oc get nodes -l glusterfs=storage-host

  9. 以下のコマンドを実行して、gluster DaemonSet を作成します。 

    # oc process glusterfs | oc create -f -

    以下に例を示します。 

    # oc process glusterfs | oc create -f -
Deamonset “glusterfs” created

    • 以下のコマンドを実行して、削除する必要のある古い gluster Pod を特定します。 

      # oc get pods

      以下に例を示します。 

      # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  10. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。 

    # df -kh | grep -v ^Filesystem | awk '{if(int($5)>90) print $0}'
    注記

    ブリックの使用率が100％に近い場合、これらのブリックの論理ボリュームマネージャー（LVM）のアクティブ化に時間がかかるか、Pod またはノードを再起動するとスタックする可能性があります。そのブリックの使用率を下げるか、論理ボリューム（LV）を使用している物理ボリューム（PV）を拡張することをお勧めします。

    注記

    df コマンドは、Block Hosting Volume(BHV)に属するブリックには適用できません。BHV では、df コマンドで生成されたブリックの 使用済み サイズは、その Gluster ボリュームのブロックサブボリュームの追加サイズであり、ブロックボリュームにあるデータのサイズではありません。詳細は、How To Identify Block Volumes and Block Hosting Volumes in Openshift Container Storage を参照してください。

  11. 以下のコマンドを実行して、古い gluster Pod を削除します。Gluster Pod はローリングアップグレードに従う必要があります。したがって、次の古い gluster Pod を削除する前に、新しい Pod が実行されていることを確認する必要があります。OnDelete Strategy DaemonSet 更新ストラテジーをサポートします。OnDelete Strategy 更新ストラテジーにより、DaemonSet テンプレートの更新後、新しい DaemonSet Pod は、古い DaemonSet Pod を手動で削除した場合にのみ作成されます。

    1. 以下のコマンドを実行して、古い gluster Pod を削除します。 

      # oc delete pod <gluster_pod>

      以下に例を示します。 

      # oc delete pod glusterfs-0vcf3
pod  “glusterfs-0vcf3” deleted
      注記

      次の Pod を削除する前に、自己修復チェックを行う必要があります。

      1. 以下のコマンドを実行して、gluster Pod のシェルにアクセスします。 

        # oc rsh <gluster_pod_name>

      2. 以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。 

        # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"

    2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。 

      # oc get pods -w
NAME                             READY     STATUS        RESTARTS   AGE
glusterfs-0vcf3                  1/1       Terminating   0          3d
…

  12. 以下のコマンドを実行して、Pod が実行していることを確認します。 

    # oc get pods

    以下に例を示します。 

    # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

  13. 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。 

    # oc rsh <gluster_pod_name> glusterd --version

    以下は例になります。 

    # oc rsh glusterfs-4cpcc glusterd --version
glusterfs 6.0

  14. gluster Pod のいずれかで以下のコマンドを実行し、Red Hat Gluster Storage op-version を確認します。 

    # gluster vol get all cluster.op-version

  15. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

    • DC（デプロイメント設定）をスケールアップします。 

      # oc scale dc <heketi_dc> --replicas=1

  16. いずれかの Pod で cluster.op-version を 70200 に設定します。

    注記

    cluster.op-version を変更する前に、すべての gluster Pod が更新されていることを確認します。 

    # gluster --timeout=3600 volume set all cluster.op-version 70200

  17. 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

    注記

    "server.tcp-user-timeout" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。

    これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。

    1. 以下のコマンドを使用して glusterfs Pod を一覧表示します。 

      # oc get pods

      以下は例になります。 

      # oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
glusterfs-storage-5thpc                       1/1       Running   0          9d
glusterfs-storage-hfttr                       1/1       Running   0          9d
glusterfs-storage-n8rg5                       1/1       Running   0          9d
heketi-storage-4-9fnvz                        2/2       Running   0          8d

    2. glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。 

      # oc rsh glusterfs-0vcf3

    3. 以下のコマンドを実行します。 

      # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done

      以下は例になります。 

      # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
    volume1
    volume set: success
    volume2
volume set: success

  18. gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。 

    # oc delete dc glusterblock-provisioner-dc

    以下は例になります。 

    # oc delete dc glusterblock-storage-provisioner-dc

  19. 以下のコマンドを実行して、古い glusterblock プロビジョナーテンプレートを削除します。 

     # oc delete templates glusterblock-provisioner

  20. glusterblock プロビジョナーテンプレートを作成します。以下は例になります。 

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml
template.template.openshift.io/glusterblock-provisioner created

  21. OCP のバージョンに応じて、glusterblock-provisioner テンプレートを編集して IMAGE_NAME、IMAGE_VERSION および NAMESPACE を変更します。 

    # oc get templates
NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
        template
glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
        template
heketi			  Heketi service deployment  7 (3 blank)	3
template

    1. テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterblock-provisioner テンプレートを更新します。以下は例になります。 

      # oc edit template glusterblock-provisioner
- displayName: glusterblock provisioner container image name
name: IMAGE_NAME
required: true
value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7
- displayName: glusterblock provisioner container image version
name: IMAGE_VERSION
required: true
value: v3.11.8
- description: The namespace in which these resources are being created
displayName: glusterblock provisioner namespace
name: NAMESPACE
required: true
value: glusterfs
- description: A unique name to identify which heketi service manages this cluster,
  useful for running multiple heketi instances
displayName: GlusterFS cluster name
name: CLUSTER_NAME
value: storage

    2. テンプレートに、パラメーターとして IMAGE_NAME しかない場合、以下のように glusterblock-provisioner テンプレートを更新します。以下は例になります。 

      # oc edit template glusterblock-provisioner
- displayName: glusterblock provisioner container image name
name: IMAGE_NAME
required: true
value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
- description: The namespace in which these resources are being created
displayName: glusterblock provisioner namespace
name: NAMESPACE
required: true
value: glusterfs
- description: A unique name to identify which heketi service manages this cluster,
            useful for running multiple heketi instances
displayName: GlusterFS cluster name
name: CLUSTER_NAME
value: storage

  22. 古い Pod から以下のリソースを削除します。 

    # oc delete clusterroles.authorization.openshift.io glusterblock-provisioner-runner
# oc delete serviceaccounts glusterblock-storage-provisioner
# oc delete clusterrolebindings.authorization.openshift.io glusterblock-storage-provisioner

  23. oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
    以下に例を示します。

    • 2 つ以上のプロビジョナーがある場合、名前は gluster.org/glusterblock-<namespace> である必要があります。ここで、namespace はプロビジョナーがデプロイされている namespace に置き換えられます。
    • 3.11.8 より前にインストールされているプロビジョナーが 1 つしかない場合は、gluster.org/glusterblock で十分です。現在使用中の名前に一意の namespace サフィックスがある場合は、既存の名前を再利用します。

  24. テンプレートの編集後に以下のコマンドを実行して、デプロイメント設定を作成します。 

    # oc process glusterblock-provisioner -o yaml | oc create -f -

    以下は例になります。 

    # oc process glusterblock-provisioner -o yaml | oc create -f -
clusterrole.authorization.openshift.io/glusterblock-provisioner-runner created
serviceaccount/glusterblock-storage-provisioner created
clusterrolebinding.authorization.openshift.io/glusterblock-storage-provisioner created
deploymentconfig.apps.openshift.io/glusterblock-storage-provisioner-dc created

  25. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

    1. Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。 

      # oc rsh <gluster_pod_name>

    2. ブリックの多重化ステータスを確認します。 

      # gluster v get all all

    3. 無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。

      注記

      ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。 

      # gluster volume set all cluster.brick-multiplex on

      以下は例になります。 

      # oc rsh glusterfs-770ql
sh-4.2# gluster volume set all cluster.brick-multiplex on
Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
volume set: success

    4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

      以下は例になります。 

      # gluster volume list

heketidbstorage
vol_194049d2565d2a4ad78ef0483e04711e
...
...

      すべてのボリュームを再起動します。この手順は、ボリュームセットの操作が前の手順と一緒に実行される場合にのみ必要です。 

      # gluster vol stop <VOLNAME>
# gluster vol start <VOLNAME>

  26. Red Hat Openshift Container Storage での S3 と互換性のあるオブジェクトストアのサポートは、テクノロジープレビュー機能となっています。S3 と互換性のあるオブジェクトストアを有効にするには、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html/operations_guide/s3_object_store を参照してください。

    注記

  27. gluster ブロックボリュームプロビジョニングを使用するすべてのストレージクラスは、クラスター内のプロビジョナー名のいずれかに完全に一致する必要があります。指定された namespace で、block provisioner を参照するストレージクラスの一覧を確認するには、以下のコマンドを実行します。 

    # oc get sc -o custom-columns=NAME:.metadata.name,PROV:.provisioner,RSNS:.parameters.restsecretnamespace | grep 'gluster.org/glusterblock' | grep <namespace>

    例: 

    # oc get sc -o custom-columns=NAME:.metadata.name,PROV:.provisioner,RSNS:.parameters.restsecretnamespace | grep 'gluster.org/glusterblock' | grep app-storage
glusterfs-storage-block   gluster.org/glusterblock-app-storage   app-storage

    各ストレージクラス provisioner name を確認します。その namespace に設定された block provisioner name 名に一致しない場合は、これを更新する必要があります。block provisioner 名が configured provisioner 名とすでに一致する場合は、何もする必要はありません。上記で生成された一覧を使用して、プロビジョナー名を更新する必要のあるストレージクラス名をすべて含めます。
    この一覧のすべてのストレージクラスについて、以下を実行します。 

    # oc get sc  -o yaml <storageclass>  > storageclass-to-edit.yaml
# oc delete sc  <storageclass>
# sed 's,gluster.org/glusterblock$,gluster.org/glusterblock-<namespace>,' storageclass-to-edit.yaml | oc create -f -

    例: 

    # oc get sc  -o yaml gluster-storage-block  > storageclass-to-edit.yaml
# oc delete sc  gluster-storage-block
# sed 's,gluster.org/glusterblock$,gluster.org/glusterblock-app-storage,' storageclass-to-edit.yaml | oc create -f -
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る