6.2.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 オプションを使用しても、glusterfs_registry Pod は削除されず、DaemonSet のみが削除されます。古い DaemonSet を削除したら、新しい DaemonSet をロードする必要があります。古い Pod を手動で削除すると、作成される新しい Pod には新しい DaemonSet の設定が含まれます。

    以下に例を示します。 

    # oc delete ds glusterfs-registry --cascade=false
daemonset "glusterfs-registry" 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 テンプレートを編集します。

    1. テンプレートにIMAGE_NAMEがある場合は、glusterfsテンプレートを次のように更新します。以下は例になります。 

      # oc edit template glusterfs

- description: Labels which define the daemonset node selector. Must contain at least
    one label of the format \'glusterfs=<CLUSTER_NAME>-host\'
  displayName: Daemonset Node Labels
  name: NODE_LABELS
  value: '{ "glusterfs": "registry-host" }'
- 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: registry

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

      # oc edit template glusterfs
- description: Labels which define the daemonset node selector. Must contain at least one label of the format \'glusterfs=<CLUSTER_NAME>-host\'
displayName: Daemonset Node Labels
name: NODE_LABELS
value: '{ "glusterfs": "registry-host" }'
- displayName: GlusterFS container image name
name: IMAGE_NAME
required: true
value: registry.redhat.io/rhgs3/rhgs-server-rhel7
- description: A unique name to identify which heketi service manages this cluster,
useful for running multiple heketi instances
- displayName: GlusterFS container image version
name: IMAGE_VERSION
required: true
value: v3.11.8
- displayName: GlusterFS cluster name
name: CLUSTER_NAME
value: registry
      注記

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

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

      # oc get nodes -l glusterfs=registry-host
  • 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: "/"
  • 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

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

      # oc process glusterfs | oc create -f -

      以下に例を示します。 

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

    2. 以下のコマンドを実行して、削除する必要のある古い glusterfs_registry 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

    3. 以下のコマンドを実行して、ブリックが 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 を参照してください。

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

      1. 古い glusterfs-registry Pod を削除するには、以下のコマンドを実行します。 

        # oc delete pod <gluster_pod>

        以下に例を示します。 

        # oc delete pod glusterfs-registry-4cpcc
pod “glusterfs-registry-4cpcc” deleted
        注記

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

        1. 以下のコマンドを実行して、glusterfs-registry 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-registry-4cpcc                  1/1       Terminating   0          3d
…

    5. 以下のコマンドを実行して、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

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

      # oc rsh <gluster_registry_pod_name> glusterd --version

      以下は例になります。 

      # oc rsh glusterfs-registry-abmqa glusterd --version
glusterfs 6.0
      # rpm -qa|grep gluster

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

      # gluster vol get all cluster.op-version

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

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

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

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

      注記

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

      # gluster volume set all cluster.op-version 70200

    10. 以下の手順を実行して、すべてのボリュームで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-registry Pod のいずれかにリモートシェルを実行します。以下は例になります。 

        # oc rsh glusterfs-registry-g6vd9

      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

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

      # oc delete dc <gluster-block-registry-dc>

      以下は例になります。 

      # oc delete dc glusterblock-registry-provisioner-dc

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

       # oc delete templates glusterblock-provisioner

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

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

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

      # 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-registry
- 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: registry

      • テンプレートに、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-registry
- 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: registry

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

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

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

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

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

      # 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-registry-provisioner created
clusterrolebinding.authorization.openshift.io/glusterblock-registry-provisioner created
deploymentconfig.apps.openshift.io/glusterblock-registry-provisioner-dc created

    18. ブリック多重化は、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-registry-g6vd9

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>

    19. 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 を参照してください。

      注記

      glusterfs レジストリーのアップグレード後に 「Heketi Pod の起動」 に記載の手順に進み、heketi Pod を元に戻してから 「Red Hat OpenShift Container Platform ノードでのクライアントのアップグレード」 に記載の手順に進んで、Red Hat Openshift Container Platform ノードでクライアントをアップグレードします。

    20. 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 infra-storage
  glusterfs-registry-block   gluster.org/glusterblock               infra-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 glusterfs-registry-block > storageclass-to-edit.yaml
# oc delete sc glusterfs-registry-block
storageclass.storage.k8s.io "glusterfs-registry-block" deleted
# sed 's,gluster.org/glusterblock$,gluster.org/glusterblock-infra-storage,' storageclass-to-edit.yaml | oc create -f -
storageclass.storage.k8s.io/glusterfs-registry-block created