6.2.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=registry-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 を実行します。