デプロイメントガイド

Red Hat OpenShift Container Storage 3.11

Red Hat Openshift Container Storage 3.11 のデプロイ

概要

本書では、前提条件について説明し、Red Hat Openshift Container Storage をデプロイする手順をステップごとに説明します。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージをご覧ください。

パート I. プランニング

第1章ワークロードの特定

本章では、Red Hat Openshift Container Storage でサポートされるワークロードの一覧を記載しています。

ブロックストレージでサポートされる永続ボリュームは、以下のワークロードで推奨される方法です。

Jenkins
ElasticSearch
Prometheus

トランザクションワークロードにファイルストレージを使用する場合は、11章カスタムボリュームオプションの設定 の説明に従って、パフォーマンストランスレーターをオフにします。

第2章ユースケースの特定

本章では、Containerized Red Hat Gluster Storage で利用可能な 2 つのユースケースを簡単に紹介します。

注記

Red Hat Openshift Container Storage は、ansible ワークフローを使用したコンバージドモードとインデペンデントモードを同時にデプロイすることをサポートしていません。したがって、コンバージドモードまたはインデペンデントモードのいずれかをデプロイする必要があります。デプロイメント時に両方のモードを混在させることはできません。

Red Hat は、OCS の OpenShift Container Platform 内で Heketi のみをサポートします。

2.1. コンバージドモード

注記

コンバージドモードは、以前は Container-Native Storage と呼ばれていました。

このデプロイメントでは、Red Hat Gluster Storage をホストするストレージコンテナーがコンピュートコンテナーと共存し、コンピュートコンテナーにローカルまたは直接アタッチされたストレージを持つホストからストレージを提供する、ハイパーコンバージドのソリューションを提供します。このソリューションは、Red Hat Gluster Storage のデプロイメントおよび管理を OpenShift サービスに統合します。その結果、永続ストレージは、コンピュートおよびファイルストレージの両方を提供する OpenShift Pod 内に提供されます。

OpenShift Container Platform 向けのコンバージドモードは、以下の 3 つの主要テクノロジーを中心に構築されています。

OpenShift は、Kubernetes コンテナー管理に基づく Platform as a Service (PaaS) インフラストラクチャーを提供します。基本的な OpenShift アーキテクチャーは、各システムにノードセットが含まれる複数のマスターシステムで構築されます。
Red Hat Gluster Storage は、Red Hat Gluster Storage 3.5 コンテナーに基づくコンテナー化された分散ストレージを提供します。各 Red Hat Gluster Storage ボリュームは、ブリックのコレクションで構成されています。各ブリックは、ノードとエクスポートディレクトリーの組み合わせになります。
Heketi は、Red Hat Gluster Storage ボリュームのライフサイクル管理を提供します。Red Hat Gluster Storage ボリュームを動的に作成し、複数の Red Hat Gluster Storage クラスターをサポートします。

以下は、管理者にソリューションワークフローを提供するための一覧です。管理者は以下を行うことができます。

複数の永続ボリューム (PV) を作成し、これらのボリュームを OpenShift に登録します。
その後、開発者は永続ボリューム要求 (PVC) を送信します。
PV は、利用可能な PV のプールから識別および選択され、PVC にバインドされます。
次に、OpenShift Pod は永続ストレージに PV を使用します。

図2.1 アーキテクチャー: OpenShift Container Platform のコンバージドモード

Architecture - Converged Mode for OpenShift Container Platform

注記

2.2. インデペンデントモード

注記

インデペンデントモードは、以前は Container-Ready Storage と呼ばれていました。

Red Hat Gluster Storage がスタンドアロンのストレージとしてデプロイされ、コンテナにストレージを提供する場合、これはインデペンデントモードと呼ばれます。このモードでは、ストレージプラットフォームのライフサイクルは、コンテナープラットフォームのライフサイクルとは別に維持されます。

Red Hat Gluster Storage が OpenShift クラスター上にデプロイされると、これはコンバージドモードと呼ばれます。

インデペンデントモードは、動的にプロビジョニングされたストレージ、静的にプロビジョニングされたストレージ、RWO サポート、および RWX サポートを提供します。さらに、ロギング、メトリックス、レジストリーサービスなどの OpenShift Container Platform インフラストラクチャーサービスへのフルサポートを提供します。

永続ストレージのユーザーの場合、デプロイメントモードは完全に透過的です。ただし、管理者は、システムのセットアップ、管理、およびスケーリングの方法にバリエーションがあることを確認できます。インデペンデントモードでは、ストレージは Red Hat Gluster Storage のように管理されます。

デプロイメントのインデペンデントモードを選択する主要なドライバーの一部を以下に示します。

OpenShift Container Platform の管理者は、ストレージを管理したくない場合があります。インデペンデントモードは、コンテナー管理からストレージ管理を分離します。
レガシーストレージ（SAN、Arrays、Old filers）の活用: 従来のストレージベンダーのストレージアレイは、多くの場合、OpenShift のサポートが限定されているか、またはサポートがありません。インデペンデントモードを使用すると、OpenShift Container の既存のレガシーストレージを活用できます。
コスト効率が高い: 新しいインフラストラクチャに関連するコストが課題となる環境では、既存のストレージアレイを再利用して、インデペンデントモードでOpenShiftをサポートできます。インデペンデントモードは、仮想マシン内で Red Hat Gluster Storage を実行し、これらのストレージアレイからの LUN またはディスクを OpenShift に提供でき、動的プロビジョニングを含むOpenShiftストレージサブシステムが提供するすべての機能を提供できる状況で最適となります。これは、インフラストラクチャが追加される可能性のある環境で非常に役立つソリューションです。

インデペンデントモードでは、Heketi およびその他のプロビジョナー（インデペンデントモードのコンポーネント）が OpenShift クラスターノード上にデプロイされます。Red Hat は、OCS の OpenShift Container Platform 内で Heketi のみをサポートします。Heketiは、自動化されたRed Hat Gluster Storageボリュームプロビジョニングのサービスエンドポイントであり、OpenShift PVをサポートするためのRed Hat Gluster Storageボリュームの割り当て要求がkubernetesから送信されます。Heketi は、Red Hat Gluster Storage ボリュームの割り当ておよび割り当て解除を動的に管理します。

注記

インデペンデントモードでは、Heketi が Gluster クラスターを完全に制御する必要があります。

第3章前提条件の検証

本章では、デプロイメントの前に、Containerized Red Hat Gluster Storage で利用可能な 2 つの異なるユースケースについて事前に確認する必要がある前提条件について説明します。

重要

Red Hat Enterprise Linux Atomic Host のサポートは、Red Hat OpenShift Container Storage 3.11.5 では非推奨になりました。Red Hat では、Red Hat Enterprise Linux Atomic Host の使用を推奨しなくなり、新規のデプロイメントでの使用をサポートしていません。Red Hat OpenShift Container Storage 3.11.5 にアップグレードする既存のデプロイメントは、引き続きサポートされます。

3.1. コンバージドモード

3.1.1. サポート対象バージョン

Red Hat Gluster Storage Server および Container-Native Storage を備えた OpenShift Container Platform のサポートされているバージョンについては https://access.redhat.com/articles/3403951 を参照してください。

3.1.2. 環境要件

このセクションでは、Red Hat Enterprise Linux Atomic Host、Red Hat OpenShift Container Platform、Red Hat Enterprise Linux、および Red Hat Gluster Storage の要件について説明しています。OpenShift Container Platform 環境を備えた Red Hat Gluster Storage Container Native は、Red Hat Enterprise Linux Atomic Host または Red Hat Enterprise Linux のいずれかにインストールされた Red Hat OpenShift Container Platform で構成されます。

3.1.2.1. OpenShift Container Platform を備えた Red Hat Openshift Container Storage の Red Hat Enterprise Linux 7 へのインストール

このセクションでは、Red Hat Enterprise Linux 7 ベースの OpenShift Container Platform 3.11 に、OpenShift Container Platform を備えた Red Hat Gluster Storage Container Native をインストールする手順を説明します。

3.1.2.1.1. Openshift マスターのクライアントとしての設定

OpenShift マスターをクライアントとして使用して、OpenShift のインストール時にクラスター全体で oc コマンドを実行できます。通常、これはクラスター内のスケジュールされていないノードとして設定されます。これは、OpenShift インストーラーを使用する場合のデフォルト設定です。クライアントをローカルマシンにインストールして、クラスターにリモートでアクセスすることも選択できます。詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html/cli_reference/cli-reference-get-started-cli#installing-the-cli を参照してください。

heketi-client パッケージのインストール

以下のコマンドを実行して、heketi-client パッケージをインストールします。

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

# yum install heketi-client

3.1.2.2. OpenShift Container Platform のオプション

デフォルトでは、コンテナログは、Dockerによってローテーションまたは最大サイズに制限されるように設定されていません。コンテナが十分に長く実行され、十分なログが生成されると、ログファイルが大きくなりすぎて、ディスク領域がいっぱいになる可能性があります。
ホスト --log-opt 上のコンテナーのログ制限の設定は、max-size および max-file で設定できます。これにより、コンテナーのログが最大制限に達したときにロールオーバーされ、特定数のファイルのみが、破棄される前に保存されます。
```
# cat /etc/sysconfig/docker

OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=50m --log-opt max-file=5'
```

注記

上記のオプションが実行されない場合、ログが大きくなると Pod をエビクトできます。

3.1.3. Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件

以下の一覧は、Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件を示しています。

Red Hat Enterprise Linux システムのすべての OpenShift ノードには、glusterfs-client RPM (glusterfs、glusterfs-client-xlators、glusterfs-libs、glusterfs-fuse) がインストールされている必要があります。以下のコマンドを実行して、RPM がインストールされているかどうかを確認できます。
```
# yum list glusterfs glusterfs-client-xlators glusterfs-libs glusterfs-fuse
```

注記

クライアント RPM は、gluster-rhgs-server と同じバージョンである必要があります。gluster-rhgs-server バージョンは、選択した OCS バージョンに基づいています。

ネイティブクライアントパッケージのインストールに関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html-single/administration_guide/index#Installing_Native_Client を参照してください。

3.1.4. デプロイメントおよびスケーリングのガイドライン

潜在的なデプロイメントまたはスケーリングの問題を防ぐために、OpenShift Container Platformでコンバージドモードをデプロイする前に、以下のガイドラインを確認してください。

信頼できるストレージプールのサイズが適切であり、オンデマンドで動的にスケーリングできる余地があることを確認してください。このアクションにより、以下の上限を超えてスケーリングしないようにできます。

コンバージドモードでのサイジング

ファイルインターフェースでサポートされる永続ボリューム: 一般的な操作の場合、4 ノードのコンバージドモードクラスターごとにファイルでサポートされる 500-800 の永続ボリュームのサイズです。ファイルインターフェースでサポートされる永続ボリュームの上限は、コンバージドモードのデプロイメントで 4 ノードクラスターごとに 2000 の永続ボリュームです。マイクロサービスが、要求に応じて動的にスケーリング可能であることを考慮すると、初回のサイジングではスケーリングに十分な余裕を持たせることをお勧めします。追加のスケーリングが必要な場合は、新しい 4 ノードのコンバージドモードクラスターを追加して、追加の永続ボリュームをサポートします。
信頼できるストレージプールごとのファイルベースの永続ボリュームのデフォルト制限は 1000 に、サポートされる最大値は 2000 に設定されています。デフォルト制限の 1000 と最大値 2000 を超えるために実行する必要のある手順についての詳細は、How to have more PV’s beyond default limit in OCS? を参照してください。
ブロックベースのストレージにサポートされる永続ボリューム: 4 ノードのコンバージドモードのクラスターごとに最大 300 の永続ボリュームのサイズです。
ファイルとブロックでサポートされる永続ボリューム: 300-500 の永続ボリュームのサイズ（ファイルによるサポート）および 100-200 の永続ボリュームのサイズ（ブロックによるサポート）ファイル PV およびブロックホスティングボリュームを含む 1000 Gluster ボリューム。
Red Hat Openshift Container Storage クラスターの最小サイズ (4): 高可用性要件を適切に満たすために、Red Hat Openshift Container Storage クラスターに最低でも 4 つのノードを含めることが推奨されます。永続ボリューム要求を作成するには3つのノードが必要ですが、3ノードクラスター内の1つのノードに障害が発生すると、永続ボリュームクレームを作成できなくなります。4 番目のノードは高可用性を提供し、ノードに障害が発生した場合でも、永続ボリューム要求を作成できます。
最小要件: コンバージドモードピアをホストする各物理または仮想ノードには、以下が必要です。
- 永続ボリュームごとに最低 8 GB の RAM および 30 MB
- 同じディスクタイプ
- heketidb は 2 GB の分散レプリカボリュームを利用
- 最小 2 つの物理コアペア

注記

2 つの物理コアのペアは、ハイパースレッディングされていないシステムの場合は 4 vCPU に変換し、ハイパースレッディングシステムの場合は 8 vCPU に変換します。

コンバージドモードでのデプロイメントガイドライン

コンバージドモードでは、Red Hat Openshift Container Storage ノード、Heketi、およびすべてのプロビジョナー Pod を OpenShift Container Platform インフラストラクチャーノードまたは OpenShift Container Platform アプリケーションノードにインストールすることができます。
OpenShift Container Platform を備えた Red Hat Gluster Storage Container Native は、デフォルトでボリュームごとに最大 14 のスナップショットをサポートします (Heketi テンプレートでは snap-max-hard-limit =14)。
必要なカーネルバージョンは kernel-3.10.0-862.14.4.el7.x86_64 以降です。以下のコマンドを実行して、インストール済みの実行中のカーネルのバージョンを確認します。
```
# rpm -q kernel
kernel-3.10.0-862.14.4.el7.x86_64
```
```
# uname -r
3.10.0-862.14.4.el7.x86_64
```

3.2. インデペンデントモード

3.2.1. サポート対象バージョン

3.2.2. 環境要件

3.2.2.1. OpenShift Container Platform を備えた Red Hat Openshift Container Storage の Red Hat Enterprise Linux 7 へのインストール

3.2.2.1.1. Openshift マスターのクライアントとしての設定

heketi-client パッケージのインストール

以下のコマンドを実行して、heketi-client パッケージをインストールします。

# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms

# yum install heketi-client

3.2.2.2. OpenShift Container Platform のオプション

デフォルトでは、コンテナログは、Dockerによってローテーションまたは最大サイズに制限されるように設定されていません。コンテナが十分に長く実行され、十分なログが生成されると、ログファイルが大きくなりすぎて、ディスク領域がいっぱいになる可能性があります。
ホスト --log-opt 上のコンテナーのログ制限の設定は、max-size および max-file で設定できます。これにより、コンテナーのログが最大制限に達したときにロールオーバーされ、特定数のファイルのみが、破棄される前に保存されます。
```
# cat /etc/sysconfig/docker

OPTIONS='--insecure-registry=172.30.0.0/16 --selinux-enabled --log-opt max-size=50m --log-opt max-file=5'
```

注記

上記のオプションが実行されない場合、ログが大きくなると Pod をエビクトできます。

3.2.3. Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件

以下の一覧には、Red Hat OpenShift Container Platform の要件が記載されています。

Red Hat Enterprise Linux システムのすべての OpenShift ノードには、glusterfs-client RPM (glusterfs、glusterfs-client-xlators、glusterfs-libs、glusterfs-fuse) がインストールされている必要があります。以下のコマンドを実行して、RPM がインストールされているかどうかを確認できます。
```
# yum list glusterfs glusterfs-client-xlators glusterfs-libs glusterfs-fuse
```

注記

glusterfs-client RPM の最新バージョンがインストールされていることを確認します。クライアント RPM は、gluster-rhgs-server バージョンと同じバージョンである必要があります。gluster-rhgs-server バージョンは、選択した OCS バージョンに基づいています。

3.2.4. Red Hat Gluster Storage の要件

以下の一覧は、Red Hat Gluster Storage の要件についての詳細を示しています。

Heketi パッケージのインストールには、Red Hat Gluster Storage Server リポジトリーへの有効なサブスクリプションが必要です。
Red Hat Gluster Storage のインストールは、Red Hat Gluster Storage Installation Guide で説明されている要件に準拠する必要があります。
「サポート対象バージョン」セクションの情報に従い、Red Hat Enterprise OpenShift と Red Hat Gluster Storage の統合バージョンは互換性がなければなりません。
Red Hat Gluster Storage サーバーノードには、完全修飾ドメイン名を設定する必要があります。適切な DNS レコードが存在し、完全修飾ドメイン名が正引きおよび逆引きの DNS ルックアップの両方で解決可能であることを確認します。
GlusterFS ボリュームにアクセスするには、すべてのスケジュール可能なノードで mount.glusterfs コマンドを利用できる必要があります。RPM ベースのシステムの場合は、glusterfs-fuse パッケージがインストールされている必要があります。
```
# yum install glusterfs-fuse
```
このパッケージはすべての RHEL システムにインストールされています。ただし、Red Hat Gluster Storage の利用可能な最新バージョンに更新することが推奨されます。そのためには、以下の RPM リポジトリーを有効にする必要があります。
```
# subscription-manager repos --enable=rh-gluster-3-client-for-rhel-7-server-rpms
```
glusterfs-fuse がノードにすでにインストールされている場合、最新バージョンがインストールされていることを確認します。
```
# yum update glusterfs-fuse
```

重要

スナップショットの使用に関する制限

スナップショットの作成後に、ユーザーサービス可能なスナップショット機能のみを使用してアクセスする必要があります。これは、以前のバージョンのファイルを必要な場所にコピーするために使用できます。
ボリュームをスナップショットの状態に戻すことはサポートされていないため、データの一貫性を損傷する可能性があるため、実行しないでください。
スナップショットのあるボリュームでは、ボリューム拡張などのボリューム変更操作を実行できません。

3.2.5. デプロイメントおよびスケーリングのガイドライン

潜在的なデプロイメントまたはスケーリングの問題を防ぐために、OpenShift Container Platformでインデペンデントモードをデプロイする前に、以下のガイドラインを確認してください。

インデペンデントモードにおけるサイジングのガイドライン

ファイルインターフェースでサポートされる永続ボリューム: 一般的な操作の場合、4 ノードのインデペンデントモードクラスターごとにファイルでサポートされる 500-800 の永続ボリュームのサイズです。ファイルインターフェースでサポートされる永続ボリュームの上限は、インデペンデントモードのデプロイメントにおいて 4 ノードクラスターごとに 2000 の永続ボリュームです。マイクロサービスが、要求に応じて動的にスケーリング可能であることを考慮すると、初回のサイジングではスケーリングに十分な余裕を持たせることをお勧めします。追加のスケーリングが必要な場合は、新しい4ノードのインデペンデントモードクラスターを追加して、追加の永続ボリュームをサポートします。

信頼できるストレージプールごとのファイルベースの永続ボリュームのデフォルト制限は 1000 に、サポートされる最大値は 2000 に設定されています。デフォルト制限の 1000 と最大値 2000 を超えるために実行する必要のある手順についての詳細は、How to have more PV’s beyond default limit in OCS? を参照してください。

ブロックベースのストレージにサポートされる永続ボリューム: 4ノードのインデペンデントモードクラスターごとに最大300の永続ボリュームのサイズ。
ファイルとブロックでサポートされる永続ボリューム: 300-500 の永続ボリュームのサイズ（ファイルによるサポート）および 100-200 の永続ボリュームのサイズ（ブロックによるサポート）ファイル PV およびブロックホスティングボリュームを含む 1000 Gluster ボリューム。
ボリュームタイプ: 唯一サポートされるボリュームタイプは、3 方向の分散複製ボリュームと arbitrated ボリュームです。
Red Hat Openshift Container Storage クラスターの最小サイズ (4): 高可用性要件を適切に満たすために、Red Hat Openshift Container Storage クラスターに最低でも 4 つのノードを含めることが推奨されます。永続ボリューム要求を作成するには3つのノードが必要ですが、3ノードクラスター内の1つのノードに障害が発生すると、永続ボリュームクレームを作成できなくなります。4 番目のノードは高可用性を提供し、ノードに障害が発生した場合でも、永続ボリューム要求を作成できます。
最小要件: Red Hat Gluster Storage インデペンデントモードピアをホストする各物理または仮想ノードには、以下が必要です。
- 永続ボリュームごとに最低 8 GB の RAM および 30 MB
- 同じディスクタイプ。
- heketidb は 2 GB の分散レプリカボリュームを利用
- 最小 2 つの物理コアペア

注記

インデペンデントモードのデプロイメントガイドライン

インデペンデントモードでは、Heketi とすべてのプロビジョナー Pod を OpenShift Container Platform インフラストラクチャーノードまたは OpenShift Container Platform アプリケーションノードにインストールすることができます。
OpenShift Container Platform を備えた Red Hat Gluster Storage Container Native は、デフォルトでボリュームごとに最大 14 のスナップショットをサポートします (Heketi テンプレートでは snap-max-hard-limit =14)。
必要なカーネルバージョンは kernel-3.10.0-862.14.4.el7.x86_64 バージョン以降です。以下のコマンドを実行して、インストール済みの実行中のカーネルのバージョンを確認します。
```
# rpm -q kernel
kernel-3.10.0-862.14.4.el7.x86_64
```
```
# uname -r
3.10.0-862.14.4.el7.x86_64
```

パート II. デプロイ

第4章コンバージドモードでのコンテナー化されたストレージのデプロイ

ご希望のソリューションのデプロイメントワークフローに従う前に、必ず「高度なインストーラー変数の指定」を確認して、ansible変数とPlaybookの推奨事項と要件を理解してください。

OpenShift Cluster 上でコンテナーにストレージを設定するには、目的に合ったワークフローを選択してください。

表4.1 デプロイメントワークフロー
デプロイメントワークフロー	レジストリー	メトリクス	ロギング	アプリケーション
「コンバージドモードでのRed Hat Openshift Container Storageのデプロイ」				✔
「レジストリーを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ」	✔
「ロギングとメトリクスを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ」		✔	✔
「レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をコンバージドモードでデプロイする」	✔	✔	✔	✔

注記

Red Hat Openshift Container Storage は、ansible ワークフローを使用したコンバージドモードとインデペンデントモードを同時にデプロイすることをサポートしていません。したがって、コンバージドモードまたはインデペンデントモードのいずれかをデプロイする必要があります。デプロイメント時に両方のモードを混在させることはできません。
s3 は、Ansible インストーラーを介してではなく、手動でデプロイされます。手動デプロイメントの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#S3_Object_Store を参照してください。

注記

本書では、新しいレジストリー名 registry.redhat.io が使用されます。

ただし、新規のregistryにまだ移行していない場合は、すべてのregistry.redhat.ioをregistry.access.redhat.comに置き換えます（該当する場合）。

4.1. 高度なインストーラー変数の指定

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/installing_clusters/#install-planningに記載されているクラスターインストールプロセスを使用して、一方または両方のGlusterFSノードグループをインストールできます。

glusterfs: ユーザーアプリケーションで使用するための一般的なストレージクラスター。
glusterfs-registry: 統合 OpenShift Container レジストリーなどのインフラストラクチャーアプリケーションで使用するための専用ストレージクラスター。

I/O およびボリューム作成のパフォーマンスへの潜在的な影響を回避するために、両方のグループをデプロイすることをお勧めします。これらは両方とも、インベントリホストファイルで定義されています。

クラスターを定義するには、`[OSEv3:children]`グループに関連する名前を追加し、類似した名前付きグループを作成して、グループにノード情報を設定します。その後 [OSEv3:vars] グループのさまざまな変数を使用してクラスターを設定できます。glusterfs 変数は openshift_storage_glusterfs_ で始まり、glusterfs-registry 変数は openshift_storage_glusterfs_registry_ で始まります。openshift_hosted_registry_storage_kind などのその他のいくつかの変数は、GlusterFS クラスターと対話します。

すべてのコンテナー化されたコンポーネントに、イメージ名とバージョンタグを指定することが推奨されます。これは、Red Hat Gluster Storage Pod などのコンポーネントが、ソフトウェアバージョンが大きく異なるクラスターが発生する可能性のある停止後にアップグレードされないようにするためです。関連する変数は以下のとおりです。

openshift_storage_glusterfs_image
openshift_storage_glusterfs_block_image
openshift_storage_glusterfs_heketi_image

以下は、Red Hat Openshift Container Storage の今回のリリースにおける推奨値です。

openshift_storage_glusterfs_image=registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.8
openshift_storage_glusterfs_block_image=registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
openshift_storage_glusterfs_heketi_image=registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.8
openshift_storage_glusterfs_s3_server_image=registry.redhat.io/rhgs3/rhgs-s3-server-rhel7:v3.11.8

変数の完全なリストは、GitHub の https://github.com/openshift/openshift-ansible/tree/release-3.11/roles/openshift_storage_glusterfs を参照してください。

変数を設定したら、インストールの環境に応じて、いくつかの Playbook が利用可能になります。

クラスターインストールのメイン Playbook を使用すると、OpenShift Container Platform の初期インストールと並行して GlusterFS クラスターをデプロイできます。
- これには、GlusterFS ストレージを使用する統合された OpenShift Container Registry のデプロイが含まれます。
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml を使用して、クラスターを既存の OpenShift Container Platform インストールにデプロイできます。
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/registry.yml を使用して、クラスターを既存の OpenShift Container Platform インストールにデプロイできます。さらに、これにより、GlusterFS ストレージを使用する統合 OpenShift Container レジストリーがデプロイされます。
重要
- OpenShift Container Platform クラスターに既存のレジストリーがあってはなりません。
playbooks/openshift-glusterfs/uninstall.yml を使用して、インベントリーホストファイルの設定に一致する既存のクラスターを削除できます。これは、設定エラーによってデプロイメントが失敗した場合に、Red Hat Openshift Container Storage 環境をクリーンアップするのに便利です。
注記
GlusterFS Playbook は、べき等である保証はありません。GlusterFS インストール全体 (ディスクデータを含む) を削除してインストールし直すことなく、特定のインストールに対して Playbook を複数回実行することは、現在はサポートされていません。

4.2. コンバージドモードでのRed Hat Openshift Container Storageのデプロイ

インベントリファイルで、[OSEv3:vars]セクションに以下の変数を追加し、設定に合わせてそれらを調整します。

[OSEv3:vars]
openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false

注記

openshift_storage_glusterfs_block_host_vol_sizeは整数を取ります。これは、Gi単位のボリュームのサイズです。

インベントリファイルで、[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。
```
[OSEv3:children]
masters
etcd
nodes
glusterfs
```
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs] セクションを追加します。ノードごとに glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスが記載されている必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。
```
<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
```
以下に例を示します。
```
[glusterfs]
node103.example.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]'
node104.example.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]'
node105.example.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]'
```

[glusterfs] の下に一覧表示されているホストを [nodes] グループに追加します。

[nodes]
...
node103.example.com openshift_node_group_name="node-config-infra"
node104.example.com openshift_node_group_name="node-config-infra"
node105.example.com openshift_node_group_name="node-config-infra"

上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。
1. 初回の OpenShift Container Platform インストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml
```
2. 既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
```
デプロイメントを確認するには、「デプロイメントの確認」を参照してください。

4.3. レジストリーを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ

インベントリーファイルで、[OSEv3:vars] セクションに以下の変数を追加し、設定に合わせてそれらを調整します。

openshift_storage_glusterfs_registry_namespace=app-storage
openshift_storage_glusterfs_registry_storageclass=true
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false

インベントリーファイルの [OSEv3:vars] に以下の変数を設定します。

[OSEv3:vars]
...
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=5Gi
openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'

[OSEv3:children] セクションに glusterfs_registry を追加して、`[glusterfs_registry]` グループを有効にします。
```
[OSEv3:children]
masters
etcd
nodes
glusterfs_registry
```
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs_registry] セクションを追加します。ノードごとに、 glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。
```
<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
```
以下に例を示します。
```
[glusterfs_registry]
node106.example.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]'
node107.example.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]'
node108.example.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]'
```
- [glusterfs_registry] の下に一覧表示されているホストを [nodes] グループに追加します。
```
[nodes]
...
node106.example.com openshift_node_group_name="node-config-compute"
node107.example.com openshift_node_group_name="node-config-compute"
node108.example.com openshift_node_group_name="node-config-compute"
```
上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。
1. 初回の OpenShift Container Platform インストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml
```
2. 既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
```
デプロイメントを確認するには、「デプロイメントの確認」を参照してください。

4.4. ロギングとメトリクスを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ

インベントリーファイルの [OSEv3:vars] に以下の変数を設定します。

[OSEv3:vars]
...
openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=pv
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"

openshift_logging_install_logging=true
openshift_logging_es_pvc_dynamic=true
openshift_logging_storage_kind=dynamic
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_pvc_size=20Gi
openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"

openshift_storage_glusterfs_registry_namespace=infra-storage
openshift_storage_glusterfs_registry_storageclass=false
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false

注記

すべての変数の詳細は、https://github.com/openshift/openshift-ansible/tree/release-3.11/roles/openshift_storage_glusterfs を参照してください。

[OSEv3:children]` セクションに glusterfs_registry を追加して、`[glusterfs_registry] グループを有効にします。
```
[OSEv3:children]
masters
etcd
nodes
glusterfs_registry
```
GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs_registry] セクションを追加します。ノードごとに、glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスを一覧に含める必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は次の形式で指定します。
```
<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
```
以下に例を示します。
```
[glusterfs_registry]
node106.example.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]'
node107.example.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]'
node108.example.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]'
```
[glusterfs_registry] の下に一覧表示されているホストを [nodes] グループに追加します。

[nodes]
...
node106.example.com openshift_node_group_name="node-config-compute"
node107.example.com openshift_node_group_name="node-config-compute"
node108.example.com openshift_node_group_name="node-config-compute"

上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。

初回の OpenShift Container Platform インストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml

既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml

ansible-playbook -i <path_to_the_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

ansible-playbook -i <path_to_the_inventory_file>  /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml

デプロイメントを確認するには、「デプロイメントの確認」を参照してください。

4.5. レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をコンバージドモードでデプロイする

インベントリーファイルの [OSEv3:vars] に以下の変数を設定します。

[OSEv3:vars]
...
openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'
openshift_hosted_registry_storage_volume_size=5Gi
openshift_hosted_registry_storage_kind=glusterfs

[OSEv3:vars]
...
openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=pv
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"

openshift_logging_install_logging=true
openshift_logging_es_pvc_dynamic=true
openshift_logging_storage_kind=dynamic
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_pvc_size=20Gi
openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"

openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=false

openshift_storage_glusterfs_registry_namespace=infra-storage
openshift_storage_glusterfs_registry_storageclass=false
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false

注記

このデプロイメントシナリオでは、openshift_storage_glusterfs_block_deploy=false を設定してください。

[OSEv3:children] セクションに glusterfs と glusterfs_registry を追加し、[glusterfs] と [glusterfs_registry] グループを有効にします。
```
[OSEv3:children]
...
glusterfs
glusterfs_registry
```
[glusterfs] セクションと [glusterfs_registry] セクションを追加し、両セクションに GlusterFS ストレージをホストするストレージノードを入力します。ノードごとに、GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に `glusterfs_devices` を設定します。少なくとも 1 つのデバイスを一覧に記載する必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。
```
<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
```
以下は例になります。
```
[glusterfs]
node103.example.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]'
node104.example.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]'
node105.example.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]'

[glusterfs_registry]
node106.example.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]'
node107.example.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]'
node108.example.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]'
```

[glusterfs] と [glusterfs_registry] に一覧表示されているホストを [nodes] グループに追加します。

[nodes]
...
node103.example.com openshift_node_group_name="node-config-compute"
node104.example.com openshift_node_group_name="node-config-compute"
node105.example.com openshift_node_group_name="node-config-compute"
node106.example.com openshift_node_group_name="node-config-infra"
node107.example.com openshift_node_group_name="node-config-infra"
node108.example.com openshift_node_group_name="node-config-infra"

初回の OpenShift Container Platform インストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml

既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml

ansible-playbook -i <path_to_the_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

ansible-playbook -i <path_to_the_inventory_file>  /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml

デプロイメントを確認するには、「デプロイメントの確認」を参照してください。

4.6. 単一の OCS クラスターのインストール

単一の OCS クラスターで、汎用アプリケーションストレージとインフラストラクチャーストレージの両方をサポートすることが可能です。これを実行するには、インベントリファイルのオプションが、ログとメトリックスでわずかに変更されます。これは、クラスターが 1 つしかない場合、gluster-block StorageClass が glusterfs-storage-block になるためです。
レジストリー PV は、2 番目のクラスター [glusterfs_registry] が存在しない場合に、この単一のクラスターに作成されます。高可用性を確保するには、このクラスターに 4 つのノードが含まれることが非常に重要です。openshift_storage_glusterfs_block_host_vol_size のサイズを選択には、特別な注意を払う必要があります。
これは、ロギングとメトリックス用に作成される gluster-block デバイスのホスティングボリュームです。別のホストボリュームを作成する必要がある場合は、サイズがこれらのすべてのブロックボリュームに対応でき、十分なストレージがあることを確認してください。

[OSEv3:children]
...
nodes
glusterfs

[OSEv3:vars]
...
# registry
...

# logging
openshift_logging_install_logging=true
...
openshift_logging_es_pvc_storage_class_name='glusterfs-storage-block'
...

# metrics
openshift_metrics_install_metrics=true
...
openshift_metrics_cassandra_pvc_storage_class_name='glusterfs-storage-block'
...

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"


# OCS storage cluster for applications
openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
...

[nodes]
…
ose-app-node01.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node02.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node03.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node04.ocpgluster.com openshift_node_group_name="node-config-compute"

[glusterfs]
ose-app-node01.ocpgluster.com glusterfs_zone=1 glusterfs_devices='[ "/dev/xvdf" ]'
ose-app-node02.ocpgluster.com glusterfs_zone=2 glusterfs_devices='[ "/dev/xvdf" ]'
ose-app-node03.ocpgluster.com glusterfs_zone=3 glusterfs_devices='[ "/dev/xvdf" ]'
ose-app-node04.ocpgluster.com glusterfs_zone=1 glusterfs_devices='[ "/dev/xvdf" ]'

注記

openshift_storage_glusterfs_block_host_vol_sizeは整数を取ります。これは、Gi単位のボリュームのサイズです。

4.7. ゾーン全体にブリックを配置するように Heketi を設定する

Heketi は、ノードゾーンをブリック配置のヒントとして使用します。異なるゾーンでレプリカブリックを厳密に配置するように Heketi に強制するには、Heketi の "strict zone checking" 機能を有効にする必要があります。この機能を有効にすると、各ブリックセットが十分な数のゾーンに分散している場合にのみ、ボリュームが正常に作成されます。

注記

heketi の厳密なゾーンを使用するように StorageClass を設定する前に、OCS ノードに正しいゾーンでラベルが付けられていることを確認します。

この機能は、StorageClass のパラメーターセクションの必要な設定で "volumeoptions" フィールドを追加して設定できます。以下は例になります。

volumeoptions: "user.heketi.zone-checking strict"

あるいは

volumeoptions: "user.heketi.zone-checking none"

設定は以下のとおりです。

strict: 異なるゾーンに少なくとも 3 つのノードが存在している必要があります（レプリカ 3 と仮定）。
none: 以前（および現在のデフォルト）の動作

"strict zone checking" 機能が設定された StorageClass ファイルのサンプルを以下に示します。

# cat glusterfs-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-container
provisioner: kubernetes.io/glusterfs
reclaimPolicy: Delete
parameters:
  resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
  restuser: "admin"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.zone-checking strict"
  volumenameprefix: "test-vol"
allowVolumeExpansion: true

注記

既存のストレージクラスの仕様は編集できません。将来のすべてのアプリケーションに、必要なボリュームオプションを指定して新しいストレージクラスを作成することができます。ただし、既存のストレージクラスの設定を変更する必要がある場合は、最初に既存のストレージクラスを削除してから、以前のクラスと同じ名前の新しいストレージクラスを再作成する必要があります。

以下のコマンドを実行して、新しい設定で glusterfs-storage ストレージクラスを削除し、再作成します。

ストレージクラスオブジェクトを yaml ファイルにエクスポートします。
```
# oc get sc glusterfs-storage --export=true -o yaml > glusterfs-storage.yaml
```
推奨されるエディターを使用して、新しいパラメーターを追加します。
ストレージクラスオブジェクトを削除し、再作成します。
```
# oc delete sc glusterfs-storage
# oc create -f glusterfs-storage.yaml
```

4.8. デプロイメントの確認

以下の手順を実行してデプロイメントを確認します。

コンバージドモードのインストール検証

以下のコマンドを実行して、app-storage namespace のインストールを検証します。これは、OCP マスターノード、または OC CLI がインストールされている Ansible デプロイホストから実行できます。

# switch to the app-storage namespace
oc project app-storage
# get the list of pods here (3 gluster pods +1 heketi pod + 1 gluster block provisioner pod)
oc get pods
NAME                                          READY     STATUS    RESTARTS   AGE
glusterblock-storage-provisioner-dc-1-mphfp   1/1       Running   0          1h
glusterfs-storage-6tlzx                       1/1       Running   0          1h
glusterfs-storage-lksps                       1/1       Running   0          1h
glusterfs-storage-nf7qk                       1/1       Running   0          1h
glusterfs-storage-tcnd8                       1/1       Running   0          1h
heketi-storage-1-5m6cl                        1/1       Running   0          1h

以下のコマンドを実行して、infra-storage namespace のインストールを検証します。これは、OCP マスターノード、または OC CLI がインストールされている Ansible デプロイホストから実行できます。

# switch to the infra-storage namespace
oc project infra-storage
# list the pods here (3 gluster pods, 1 heketi pod and 1 glusterblock-provisioner pod)
oc get pods
NAME                                         READY   STATUS       RESTARTS       AGE
glusterblock-registry-provisioner-dc-1-28sfc 1/1  Running      0              1h
glusterfs-registry-cjp49                       1/1  Running      0              1h
glusterfs-registry-lhgjj                     1/1  Running      0              1h
glusterfs-registry-v4vqx                     1/1  Running      0              1h
heketi-registry-5-lht6s                      1/1  Running      0              1h

OCP インフラストラクチャー Red Hat Openshift Container Storage がサポートするレジストリー PVC が存在することを確認します。このボリュームは、openshift-ansible デプロイメントで静的にプロビジョニングされました。

oc get pvc -n default
NAME                      STATUS      VOLUME                                    CAPACITY         ACCESSMODES      STORAGECLASS               AGE
registry-claim            Bound       pvc-7ca4c8de-10ca-11e8-84d3-069df2c4f284  25Gi             RWX                                         1h

レジストリー DeploymentConfig を確認して、この glusterfs ボリュームを使用していることを確認します。

oc describe dc/docker-registry -n default | grep -A3 Volumes
    Volumes:
    registry-storage:
    Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName: registry-claim

コンバージドモードのストレージプロビジョニングの検証
1. ストレージクラスリソースを使用して、RHOCSデプロイメントを検証するための新しいPV要求を作成できます。RHOCS デプロイメント時に作成された以下の OCP Storage Class を使用して、PV プロビジョニングを検証します。
  「コンバージドモードでのRed Hat Openshift Container Storageのデプロイ」を使用して RHOCS をデプロイした場合に、glusterfs-storage-block OCP Storage Class リソースを使用して新規永続ボリューム要求を作成します。
  以下のワークフローのいずれかを使用して RHOCS をデプロイした場合は、glusterfs-registry-block OCP Storage Class リソースを使用して新規永続ボリューム要求を作成します。
  「レジストリーを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ」
  「ロギングとメトリクスを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ」
  「レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をコンバージドモードでデプロイする」
```
# oc get storageclass

NAME                                TYPE
glusterfs-storage                   kubernetes.io/glusterfs
glusterfs-storage-block             gluster.org/glusterblock
$ cat pvc-file.yaml
kind: PersistentVolumeClaim
apiVersion: v1
spec:
  name: rhocs-file-claim1
  annotations:
    storageClassName: glusterfs-storage
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
storage: 5Gi
```
```
# cat pvc-block.yaml
kind: PersistentVolumeClaim
apiVersion: v1
spec:
  name: rhocs-block-claim1
  annotations:
    storageClassName: glusterfs-storage-block
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
```
```
# oc create -f pvc-file.yaml
# oc create -f pvc-block.yaml
```
  2 つの PVC とそれぞれの PV が適切に作成されていることを確認します。
```
# oc get pvc
```

検証に heketi-client を使用する

heketi-client パッケージは、Ansible デプロイホストまたは OCP マスターにインストールする必要があります。インストールしたら、heketi-clientコマンド（heketi-cli）を実行するための必要な環境変数を簡単にエクスポートするために、2つの新しいファイルを作成する必要があります。各ファイルの内容と便利な heketi-cli コマンドの詳細を以下に示します。

以下の内容を含む新規ファイル（例: "heketi-exports-app"）を作成します。

export HEKETI_POD=$(oc get pods -l glusterfs=heketi-storage-pod -n app-storage -o jsonpath="{.items[0].metadata.name}")
export HEKETI_CLI_SERVER=http://$(oc get route/heketi-storage -n app-storage -o jsonpath='{.spec.host}')
export HEKETI_CLI_KEY=$(oc get pod/$HEKETI_POD -n app-storage -o jsonpath='{.spec.containers[0].env[?(@.name=="HEKETI_ADMIN_KEY")].value}')
export HEKETI_ADMIN_KEY_SECRET=$(echo -n ${HEKETI_CLI_KEY} | base64)
export HEKETI_CLI_USER=admin

ファイルをソースして、HEKETI app-storage 環境変数を作成します。

source heketi-exports-app
# see if heketi is alive
curl -w '\n' ${HEKETI_CLI_SERVER}/hello
Hello from Heketi
# ask heketi about the cluster it knows about
heketi-cli cluster list
Clusters:
Id:56ed234a384cef7dbef6c4aa106d4477 [file][block]
# ask heketi about the topology of the RHOCS cluster for apps
heketi-cli topology info
# ask heketi about the volumes already created (one for the heketi db should exist after the OCP initial installation)
heketi-cli volume list
Id:d71a4cbea22af3453615a9020f261b5c Cluster:56ed234a384cef7dbef6c4aa106d4477
Name:heketidbstorage

以下の内容を含む新規ファイル（例: "heketi-exports-infra"）を作成します。

export HEKETI_POD=$(oc get pods -l glusterfs=heketi-registry-pod -n infra-storage -o jsonpath="{.items[0].metadata.name}")
export HEKETI_CLI_SERVER=http://$(oc get route/heketi-registry -n infra-storage -o jsonpath='{.spec.host}')
export HEKETI_CLI_USER=admin
export HEKETI_CLI_KEY=$(oc get pod/$HEKETI_POD -n infra-storage -o jsonpath='{.spec.containers[0].env[?(@.name=="HEKETI_ADMIN_KEY")].value}')
export HEKETI_ADMIN_KEY_SECRET=$(echo -n ${HEKETI_CLI_KEY} | base64)

ファイルをソースして、HEKETI infra-storage 環境変数を作成します。

source heketi-exports-infra
# see if heketi is alive
curl -w '\n' ${HEKETI_CLI_SERVER}/hello
Hello from Heketi
# ask heketi about the cluster it knows about (the RHOCS cluster for infrastructure)
heketi-cli cluster list
Clusters:
Id:baf91b261cbca2bb4b62caece63f60d0 [file][block]
# ask heketi about the volumes already created
heketi-cli volume list
Id:77baed02f79f4518326d8cc1db6c7af8 Cluster:baf91b261cbca2bb4b62caece63f60d0 Name:heketidbstorage

4.9. Arbiter ボリュームの作成（オプション）

Arbiter ボリュームは、同様の整合性と少ないディスク容量要件で、すべての永続ボリュームタイプをサポートします。Arbitrated Replicated ボリュームまたは arbiter ボリュームは、3 方向の複製ボリュームのように動作し、3 つおきのブリックは arbiter と呼ばれる特殊なタイプのブリックです。Arbiter ブリックはファイルデータを格納しません。ファイル名、構造、メタデータのみを格納します。arbiter は、クライアントクォーラムを使用して、このメタデータを他のノードのメタデータと比較し、ボリュームの一貫性を確保し、スプリットブレイン状態を防ぎます。

Arbitrated Replicated ボリュームの利点

同様の一貫性: arbiter が設定されている場合、arbitration ロジックはクライアント側のクォーラムを自動モードで使用して、スプリットブレイン状態につながるファイル操作を防止します。
ディスクの必要容量が少なくて済む: arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリューム内の他のブリックよりもはるかに小さくすることができます。

Arbitrated Replicated ボリュームの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html-single/administration_guide/index#Creating_Arbitrated_Replicated_Volumes を参照してください。

arbiter ボリュームを作成する前に、heketi-client パッケージがインストールされていることを確認します。

# subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms

# yum install heketi-client

既存の Heketi サーバーをアップグレードする場合は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/index#upgrade_heketi_rhgs を参照してください。

注記

Arbiter ボリュームは、データブリックよりも Arbiter ブリックのほうが早くいっぱいになるので、ファイルサイズのワークロードが予測できない場合やファイルサイズが小さい場合には適していない可能性があります。arbiter ボリュームを使用する場合には、arbiter ブリックがワークロードに対応できるように、データブリックのサイズとファイル数に基づいてファイルサイズを平均より若干少なめに選択することを推奨します。

4.9.1. Arbiter ボリュームの作成

Arbiter ボリュームは、Heketi CLI を使用して、または storageclass ファイルを更新して作成できます。

4.9.1.1. Heketi CLI を使用した Arbiter ボリュームの作成

Heketi CLI を使用して Arbiter ボリュームを作成するには、レプリカ 3 ボリュームを要求し、Heketi 固有のボリュームオプション "user.heketi.arbiter true" を指定して、システムがレプリカ 3 の Arbiter バリアントを作成するように指示します。

以下は例になります。

# heketi-cli volume create --size=4 --gluster-volume-options='user.heketi.arbiter true'

4.9.1.2. Storageclass ファイルを使用した Arbiter ボリュームの作成

storageclass ファイルを使用して arbiter ボリュームを作成するには、storageclass ファイルに以下の 2 つのパラメーターを含めるようにしてください。

user.heketi.arbiter true
（オプション）user.heketi.average-file-size 1024

以下は、storageclass ファイルのサンプルです。

# 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"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.arbiter true,user.heketi.average-file-size 1024"
  volumenameprefix: "test-vol"
spec:
  persistentVolumeReclaimPolicy: Retain
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
storage: 5Gi

4.9.2. Arbiter ボリュームとしてのブロックホストボリュームの作成

注記

storageclass ファイルに変更はありません。

ブロックホスティングボリュームを arbiter ボリュームとして作成するには、以下を実行します。

以下の環境変数および値を追加して、Heketi デプロイメント設定の Glusterfs セクションの下にある設定ファイルを編集します。
```
HEKETI_BLOCK_HOSTING_VOLUME_OPTIONS: group gluster-block,user.heketi.arbiter true
```
Heketi CLI を使用してブロックボリュームを作成します。
```
  # heketi-cli blockvolume create --size=100
```
ブロックホスティングボリュームが arbiter ボリュームであることを確認します。
```
 # gluster v info
```
注記
arbiter ボリュームの管理に関する詳細は、10章Arbitrated Replicated ボリュームの管理 を参照してください。

第5章インデペンデントモードでのコンテナーストレージのデプロイ

任意のソリューションのデプロイメントワークフローを実行する前に、「RHGS クラスターの設定」を完了し、「高度なインストーラー変数の指定」を確認して Ansible 変数および Playbook の推奨事項と要件を理解するようにしてください。ストレージをスタンドアロンの Red Hat Gluster Storage クラスターとしてストレージを設定するには、目的に合ったワークフローを選択します。

表5.1 デプロイメントワークフロー
デプロイメントワークフロー	レジストリー	メトリクス	ロギング	アプリケーション
「インデペンデントモードでの Red Hat Openshift Container Storage のデプロイ」				✔
「レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をインデペンデントモードでデプロイする」	✔	✔	✔	✔

注記

Red Hat Openshift Container Storage は、ansible ワークフローを使用したコンバージドモードとインデペンデントモードを同時にデプロイすることをサポートしていません。したがって、コンバージドモードまたはインデペンデントモードのいずれかをデプロイする必要があります。デプロイメント時に両方のモードを混在させることはできません。
s3 は、Ansible インストーラーを介してではなく、手動でデプロイされます。手動デプロイメントの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#S3_Object_Store を参照してください。

注記

本書では、新しいレジストリー名 registry.redhat.io が使用されます。

ただし、新規のregistryにまだ移行していない場合は、すべてのregistry.redhat.ioをregistry.access.redhat.comに置き換えます（該当する場合）。

5.1. RHGS クラスターの設定

インデペンデントモードの設定では、専用の Red Hat Gluster Storage クラスターが OpenShift Container Platform の外部で利用できます。ストレージは Red Hat Gluster Storage クラスターからプロビジョニングされます。

5.1.1. Red Hat Gluster Storage Server の Red Hat Enterprise Linux へのインストール (階層化インストール)

階層型インストールでは、Red Hat Enterprise Linux に Red Hat Gluster Storage がインストールされます。

重要

ログファイルには十分な大きさ (50GB - 100GB) の別個の /var パーティション、geo-レプリケーション関連の各種ファイル、およびその他のファイルを作成することが推奨されます。

Red Hat Enterprise Linux 7 Server のベースインストールの実行
インデペンデントモードは、Red Hat Enterprise Linux 7 でのみサポートされます。
システムの Subscription Manager への登録
以下のコマンドを実行し、Red Hat Network のユーザー名およびパスワードを入力して、システムを Red Hat Network に登録します。
```
# subscription-manager register
```
利用可能なエンタイトルメントプールの特定
以下のコマンドを実行して、Red Hat Gluster Storage のインストールに必要なリポジトリーが含まれるエンタイトルメントプールを見つけます。
```
# subscription-manager list --available
```
システムへのエンタイトルメントプールのアタッチ
先の手順で特定したプール ID を使用して、Red Hat Enterprise Linux Server および Red Hat Gluster Storage のエンタイトルメントをシステムにアタッチします。以下のコマンドを実行してエンタイトルメントをアタッチします。
```
# subscription-manager attach --pool=[POOLID]
```
以下は例になります。
```
# subscription-manager attach --pool=8a85f9814999f69101499c05aa706e47
```
必要なチャンネルの有効化
以下のコマンドを実行して、Red Hat Gluster Storage 3.5 を Red Hat Enterprise Linux 7.7 にインストールするために必要なリポジトリーを有効にします。
```
# subscription-manager repos --enable=rhel-7-server-rpms
# subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms
# subscription-manager repos --enable=rhel-7-server-extras-rpms
```
チャンネルが有効であるかどうかの確認
以下のコマンドを実行して、チャンネルが有効であるかどうかを確認します。
```
# yum repolist
```
すべてのパッケージの更新

以下のコマンドを実行して、すべてのパッケージが最新の状態であることを確認します。

# yum update

カーネルバージョンの要件
インデペンデントモードでは、システムで kernel-3.10.0-862.14.4.el7.x86_64 バージョン以降を使用する必要があります。以下のコマンドを実行して、インストール済みの実行中のカーネルのバージョンを確認します。
```
# rpm -q kernel
kernel-3.10.0-862.14.4.el7.x86_64
```
```
# uname -r
3.10.0-862.14.4.el7.x86_64
```
重要
いずれかのカーネルパッケージを更新した場合は、以下のコマンドを実行してシステムを再起動します。
+
```
# shutdown -r now
```
Red Hat Gluster Storage のインストール
以下のコマンドを実行して Red Hat Gluster Storage をインストールします。
```
# yum install redhat-storage-server
```
gluster-block を有効にするには、以下のコマンドを実行します。
```
# yum install gluster-block
```
再起動
システムを再起動します。

5.1.2. ポートアクセスの設定

このセクションでは、インデペンデントモードで開く必要のあるポートに関する情報を提供します。

Red Hat Gluster Storage Server は、一覧表示されているポートを使用します。ファイアウォール設定が、これらのポートへのアクセスを妨げないようにしてください。

以下のコマンドを実行して、すべての Red Hat Gluster Storage ノードで、ランタイムおよび永続設定の両方で必要なポートを開きます。

# firewall-cmd --zone=zone_name --add-port=24010/tcp --add-port=3260/tcp --add-port=111/tcp --add-port=22/tcp --add-port=24007/tcp --add-port=49152-49664/tcp
# firewall-cmd --zone=zone_name --add-port=24010/tcp --add-port=3260/tcp --add-port=111/tcp --add-port=22/tcp --add-port=24007/tcp --add-port=49152-49664/tcp --permanent

注記

ポート 24010 と 3260 は、それぞれ gluster-blockd と iSCSI ターゲット用です。
49664 で始まるポート範囲は、ボリュームのブリックとの通信に GlusterFS で使用できるポートの範囲を定義します。上記の例では、許容されるブリックの合計数は 512 です。各ノードでホストできるブリックの最大数に基づいて、ポート範囲を設定します。
オプション client.bind-insecure が設定されている場合、Gluster ネイティブクライアント（gfapi クライアントを含む）は、ポート 1023 または 49152 で始まる最初の利用可能なポートを使用します。

5.1.3. カーネルモジュールの有効化

以下のコマンドを実行して、カーネルモジュールを有効にします。

dm_thin_pool モジュールおよび target_core_user モジュールが、Red Hat Gluster Storage ノードに読み込まれていることを確認する必要があります。
```
# modprobe target_core_user
```
```
# modprobe dm_thin_pool
```
以下のコマンドを実行して、モジュールが読み込まれているかどうかを確認します。
```
# lsmod | grep dm_thin_pool
```
```
# lsmod | grep target_core_user
```
注記
これらの操作が再起動後も維持されるようにするには、以下のファイルを作成し、各ファイルを更新します。
```
# cat /etc/modules-load.d/dm_thin_pool.conf
dm_thin_pool
```
```
# cat /etc/modules-load.d/target_core_user.conf
target_core_user
```
dm_multipath モジュールがすべての OpenShift Container Platform ノードに読み込まれることを確認する必要があります。
```
# modprobe dm_multipath
```
以下のコマンドを実行して、モジュールが読み込まれているかどうかを確認します。
```
# lsmod | grep dm_multipath
```
注記
これらの操作が再起動後も維持されるようにするには、以下のファイルを作成し、上記の内容で更新します。
```
# cat /etc/modules-load.d/dm_multipath.conf
dm_multipath
```

5.1.4. サービスの起動と有効化

以下のコマンドを実行して、glusterd および gluster-blockd を起動します。

# systemctl start sshd

# systemctl enable sshd

# systemctl start glusterd

# systemctl enable glusterd

# systemctl start gluster-blockd

# systemctl enable gluster-blockd

5.1.5. 2 TB（以上）のブロックボリュームの作成

インデペンデントモードでブロックボリュームの 2 TB 以上（最大 2.5 TB）を作成するには、以下のように GB_CLI_TIMEOUT パラメーターを設定する必要があります。

/etc/sysconfig/gluster-blockd 設定ファイルを編集します。GB_CLI_TIMEOUT パラメーターのコメントを解除し、パラメーター値を 900 として更新します。

5.2. 高度なインストーラー変数の指定

glusterfs: ユーザーアプリケーションで使用するための一般的なストレージクラスター。
glusterfs-registry: 統合 OpenShift Container レジストリーなどのインフラストラクチャーアプリケーションで使用するための専用ストレージクラスター。

すべてのコンテナー化されたコンポーネントに、バージョンタグを指定することが推奨されます。これは主にコンポーネントが、ソフトウェアバージョンが大きく異なるクラスターが発生する可能性のある停止後にアップグレードされないようにするためです。関連する変数は以下のとおりです。

openshift_storage_glusterfs_image
openshift_storage_glusterfs_block_image
openshift_storage_glusterfs_heketi_image

注記

gluster-block のイメージ変数は、対応するデプロイメント変数 (末尾が _block_deployにある変数) が true の場合にのみ必要です。

以下は、Red Hat Openshift Container Storage の今回のリリースにおける推奨値です。

openshift_storage_glusterfs_image=registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.8
openshift_storage_glusterfs_block_image=registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
openshift_storage_glusterfs_heketi_image=registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.8
openshift_storage_glusterfs_s3_server_image=registry.redhat.io/rhgs3/rhgs-s3-server-rhel7:v3.11.8

変数の完全なリストは、GitHub の https://github.com/openshift/openshift-ansible/tree/release-3.11/roles/openshift_storage_glusterfs を参照してください。

変数を設定したら、インストールの環境に応じて、いくつかの Playbook が利用可能になります。

クラスターインストールのメイン Playbook を使用すると、OpenShift Container Platform の初期インストールと並行して GlusterFS クラスターをデプロイできます。
これには、GlusterFS ストレージを使用する統合された OpenShift Container Registry のデプロイが含まれます。
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml を使用して、クラスターを既存の OpenShift Container Platform インストールにデプロイできます。
/usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/registry.yml を使用して、クラスターを既存の OpenShift Container Platform インストールにデプロイできます。さらに、これにより、GlusterFS ストレージを使用する統合 OpenShift Container レジストリーがデプロイされます。
重要
OpenShift Container Platform クラスターには、既存のレジストリーを含めることはできません。
注記
GlusterFS Playbook は、べき等である保証はありません。現在GlusterFS インストール全体 (ディスクデータを含む) を削除してインストールし直すことなく、特定のインストールに対して Playbook を複数回実行することは、現在はサポートされていません。

5.3. インデペンデントモードでの Red Hat Openshift Container Storage のデプロイ

インベントリファイルで、[OSEv3:children]セクションにglusterfsを追加して、[glusterfs]グループを有効にします。
```
[OSEv3:children]
masters
etcd
nodes
glusterfs
```

[OSEv3:vars] セクションに以下の変数を追加し、設定に合わせてそれらを調整します。

[OSEv3:vars]
...
openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_is_native=false
openshift_storage_glusterfs_heketi_is_native=true
openshift_storage_glusterfs_heketi_executor=ssh
openshift_storage_glusterfs_heketi_ssh_port=22
openshift_storage_glusterfs_heketi_ssh_user=root
openshift_storage_glusterfs_heketi_ssh_sudo=false
openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"

注記

openshift_storage_glusterfs_block_host_vol_sizeは整数を取ります。これは、Gi単位のボリュームのサイズです。

GlusterFS ストレージをホストする各ストレージノードのエントリーを含む [glusterfs] セクションを追加します。ノードごとに glusterfs_devices を GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に設定します。少なくとも 1 つのデバイスが記載されている必要があります。各デバイスは、パーティションや LVM PV がないベアでなければなりません。また、glusterfs_ipをノードのIPアドレスに設定します。変数の指定は以下の形式になります。
```
<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'
```
以下は例になります。
```
[glusterfs]
gluster1.example.com glusterfs_zone=1 glusterfs_ip=192.168.10.11 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
gluster2.example.com glusterfs_zone=2 glusterfs_ip=192.168.10.12 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
gluster3.example.com glusterfs_zone=3 glusterfs_ip=192.168.10.13 glusterfs_devices='[ "/dev/xvdc", "/dev/xvdd" ]'
```
上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。
- 初回の OpenShift Container Platform インストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml
```
- 既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合
```
ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
```

ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。各クラスターの Red Hat Gluster Storage ノードのいずれかで以下のコマンドを実行して、brick-multiplexing を有効にします。

以下のコマンドを実行して、ブリックの多重化を有効にします。

# gluster vol set all cluster.brick-multiplex on

以下は例になります。

# gluster vol 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

heketidb ボリュームを再起動します。

# gluster vol stop heketidbstorage
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: heketidbstorage: success

# gluster vol start heketidbstorage
volume start: heketidbstorage: success

5.4. レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をインデペンデントモードでデプロイする

インベントリーファイルの [OSEv3:vars] に以下の変数を設定します。

[OSEv3:vars]
...
openshift_hosted_registry_selector='node-role.kubernetes.io/infra=true'
openshift_hosted_registry_storage_volume_size=5Gi
openshift_hosted_registry_storage_kind=glusterfs

openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=pv
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"

openshift_logging_install_logging=true
openshift_logging_es_pvc_dynamic=true
openshift_logging_storage_kind=dynamic
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_pvc_size=20Gi
openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"

openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=false
openshift_storage_glusterfs_is_native=false
openshift_storage_glusterfs_heketi_is_native=true
openshift_storage_glusterfs_heketi_executor=ssh
openshift_storage_glusterfs_heketi_ssh_port=22
openshift_storage_glusterfs_heketi_ssh_user=root
openshift_storage_glusterfs_heketi_ssh_sudo=false
openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"


openshift_storage_glusterfs_registry_namespace=infra-storage
openshift_storage_glusterfs_registry_storageclass=false
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false
openshift_storage_glusterfs_registry_is_native=false
openshift_storage_glusterfs_registry_heketi_is_native=true
openshift_storage_glusterfs_registry_heketi_executor=ssh
openshift_storage_glusterfs_registry_heketi_ssh_port=22
openshift_storage_glusterfs_registry_heketi_ssh_user=root
openshift_storage_glusterfs_registry_heketi_ssh_sudo=false
openshift_storage_glusterfs_registry_heketi_ssh_keyfile="/root/.ssh/id_rsa"

注記

このデプロイメントシナリオでは、openshift_storage_glusterfs_block_deploy=false を設定してください。

[OSEv3:children] セクションに glusterfs と glusterfs_registry を追加し、[glusterfs] と [glusterfs_registry] グループを有効にします。
```
[OSEv3:children]
...
glusterfs
glusterfs_registry
```

[glusterfs] セクションと [glusterfs_registry] セクションを追加し、両セクションに GlusterFS ストレージをホストするストレージノードを入力します。ノードごとに、GlusterFS クラスターの一部として完全に管理される raw ブロックデバイスの一覧に `glusterfs_devices` を設定します。少なくとも 1 つのデバイスを一覧に記載する必要があります。各デバイスはパーティションや LVM PV がないベアでなければなりません。変数は以下の形式で指定します。

<hostname_or_ip> glusterfs_zone=<zone_number> glusterfs_ip=<ip_address> glusterfs_devices='[ "</path/to/device1/>", "</path/to/device2>", ... ]'

以下は例になります。

[glusterfs]
node11.example.com glusterfs_zone=1 glusterfs_ip=192.168.10.11 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'
node12.example.com glusterfs_zone=2 glusterfs_ip=192.168.10.12 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'
node13.example.com glusterfs_zone=3 glusterfs_ip=192.168.10.13 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'

[glusterfs_registry]
node15.example.com glusterfs_zone=1 glusterfs_ip=192.168.10.15 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'
node16.example.com glusterfs_zone=2 glusterfs_ip=192.168.10.16 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'
node17.example.com glusterfs_zone=3 glusterfs_ip=192.168.10.17 glusterfs_devices='["/dev/xvdc", "/dev/xvdd" ]'

初回の OpenShift Container Platform インストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/prerequisites.yml

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/deploy_cluster.yml

既存の OpenShift Container Platform クラスターへのスタンドアロンインストールの場合

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml

ansible-playbook -i <path_to_the_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml

ansible-playbook -i <path_to_the_inventory_file>  /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml

デプロイメントを確認するには、「デプロイメントの確認」を参照してください。

5.5. 単一の OCS クラスターのインストール

[OSEv3:children]
...
nodes
glusterfs

[OSEv3:vars]
...
# registry
...

# logging
openshift_logging_install_logging=true
...
openshift_logging_es_pvc_storage_class_name='glusterfs-storage-block'
...

# metrics
openshift_metrics_install_metrics=true
...
openshift_metrics_cassandra_pvc_storage_class_name='glusterfs-storage-block'
...

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"


# OCS storage cluster for applications
openshift_storage_glusterfs_namespace=app-storage
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_is_native=false
openshift_storage_glusterfs_heketi_is_native=true
openshift_storage_glusterfs_heketi_executor=ssh
openshift_storage_glusterfs_heketi_ssh_port=22
openshift_storage_glusterfs_heketi_ssh_user=root
openshift_storage_glusterfs_heketi_ssh_sudo=false
openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"
...

[nodes]
…
ose-app-node01.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node02.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node03.ocpgluster.com openshift_node_group_name="node-config-compute"
ose-app-node04.ocpgluster.com openshift_node_group_name="node-config-compute"

[glusterfs]
ose-app-node01.ocpgluster.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]' glusterfs_ip=192.168.0.11
ose-app-node02.ocpgluster.com glusterfs_zone=2 glusterfs_devices='["/dev/sdd"]' glusterfs_ip=192.168.0.12
ose-app-node03.ocpgluster.com glusterfs_zone=3 glusterfs_devices='["/dev/sdd"]' glusterfs_ip=192.168.0.13
ose-app-node04.ocpgluster.com glusterfs_zone=1 glusterfs_devices='["/dev/sdd"]' glusterfs_ip=192.168.0.14

注記

openshift_storage_glusterfs_block_host_vol_sizeは整数を取ります。これは、Gi単位のボリュームのサイズです。

5.6. ゾーン全体にブリックを配置するように Heketi を設定する

注記

heketi の厳密なゾーンを使用するように StorageClass を設定する前に、OCS ノードに正しいゾーンでラベルが付けられていることを確認します。

この機能は、StorageClass のパラメーターセクションの必要な設定で "volumeoptions" フィールドを追加して設定できます。以下は例になります。

volumeoptions: "user.heketi.zone-checking strict"

あるいは

volumeoptions: "user.heketi.zone-checking none"

設定は以下のとおりです。

strict: 異なるゾーンに少なくとも 3 つのノードが存在している必要があります（レプリカ 3 と仮定）。
none: 以前（および現在のデフォルト）の動作

"strict zone checking" 機能が設定された StorageClass ファイルのサンプルを以下に示します。

# cat glusterfs-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-container
provisioner: kubernetes.io/glusterfs
reclaimPolicy: Delete
parameters:
  resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
  restuser: "admin"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.zone-checking strict"
  volumenameprefix: "test-vol"
allowVolumeExpansion: true

注記

以下のコマンドを実行して、新しい設定で glusterfs-storage ストレージクラスを削除し、再作成します。

ストレージクラスオブジェクトを yaml ファイルにエクスポートします。
```
# oc get sc glusterfs-storage --export=true -o yaml > glusterfs-storage.yaml
```
推奨されるエディターを使用して、新しいパラメーターを追加します。
ストレージクラスオブジェクトを削除し、再作成します。
```
# oc delete sc glusterfs-storage
# oc create -f glusterfs-storage.yaml
```

5.7. デプロイメントの確認

以下の手順を実行してデプロイメントを確認します。

インデペンデントモードのインストール検証

以下のコマンドを実行して、app-storage namespace のインストールを確認します。

# switch to the app-storage namespace
oc project app-storage

# get the list of pods here (1 heketi pod)
oc get pods
NAME                    READY          STATUS          RESTARTS          AGE

heketi-storage-1-v5skm  1/1            Running         0                 1h

# switch to the infra-storage namespace
oc project infra-storage

# list the pods here (1 heketi pod and 1 glusterblock-provisioner pod)
oc get pods
NAME                                              READY   STATUS       RESTARTS       AGE
glusterblock-registry-provisioner-dc-1-28sfc         1/1  Running      0              1h
heketi-registry-5-lht6s                              1/1  Running      0              1h

oc get pvc -n default
NAME                      STATUS      VOLUME                                    CAPACITY         ACCESSMODES      STORAGECLASS               AGE
registry-claim            Bound       pvc-7ca4c8de-10ca-11e8-84d3-069df2c4f284  25Gi             RWX                                         1h

レジストリー DeploymentConfig を確認して、この glusterfs ボリュームを使用していることを確認します。

oc describe dc/docker-registry -n default | grep -A3 Volumes
    Volumes:
    registry-storage:
    Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName: registry-claim

インデペンデントモード用のストレージプロビジョニングの検証
1. OCP デプロイメント時に作成された glusterfs および glusterblock OCP Storage Class を使用して、PV のプロビジョニングを検証します。2 つの Storage Class リソース (glusterfs-storage および glusterfs-storage-block) を使用して、Red Hat Openshift Container Storage デプロイメントの検証用に新規永続ボリューム要求を作成できます。glusterfs-storage storageclass を使用する新規 PVC は、app-storage プロジェクトの gluster Pod で利用可能なストレージを使用します。
```
# oc get storageclass

NAME                                TYPE
glusterfs-storage                   kubernetes.io/glusterfs
glusterfs-storage-block             gluster.org/glusterblock
$ cat pvc-file.yaml
kind: PersistentVolumeClaim
apiVersion: v1
spec:
  name: rhocs-file-claim1
  annotations:
  storageClassName: glusterfs-storage
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
storage: 5Gi
```
```
# cat pvc-block.yaml

kind: PersistentVolumeClaim
apiVersion: v1
spec:
  name: rhocs-block-claim1
  annotations:
  storageClassName: glusterfs-storage-block
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
```
```
# oc create -f pvc-file.yaml
# oc create -f pvc-block.yaml
+
```
  2 つの PVC とそれぞれの PV が適切に作成されていることを確認します。
```
# oc get pvc
```

検証に heketi-client を使用する

以下の内容を含む新規ファイル（例: "heketi-exports-app"）を作成します。

export HEKETI_POD=$(oc get pods -l glusterfs=heketi-storage-pod -n app-storage -o jsonpath="{.items[0].metadata.name}")
export HEKETI_CLI_SERVER=http://$(oc get route/heketi-storage -n app-storage -o jsonpath='{.spec.host}')
export HEKETI_CLI_KEY=$(oc get pod/$HEKETI_POD -n app-storage -o jsonpath='{.spec.containers[0].env[?(@.name=="HEKETI_ADMIN_KEY")].value}')
export HEKETI_ADMIN_KEY_SECRET=$(echo -n ${HEKETI_CLI_KEY} | base64)
export HEKETI_CLI_USER=admin

ファイルをソースして、HEKETI app-storage 環境変数を作成します。

source heketi-exports-app
# see if heketi is alive
curl -w '\n' ${HEKETI_CLI_SERVER}/hello
Hello from Heketi
# ask heketi about the cluster it knows about
heketi-cli cluster list
Clusters:
Id:56ed234a384cef7dbef6c4aa106d4477 [file][block]
# ask heketi about the topology of the RHOCS cluster for apps
heketi-cli topology info
# ask heketi about the volumes already created (one for the heketi db should exist after the OCP initial installation)
heketi-cli volume list
Id:d71a4cbea22af3453615a9020f261b5c Cluster:56ed234a384cef7dbef6c4aa106d4477
Name:heketidbstorage

以下の内容を含む新規ファイル（例: "heketi-exports-infra"）を作成します。

export HEKETI_POD=$(oc get pods -l glusterfs=heketi-registry-pod -n infra-storage -o jsonpath="{.items[0].metadata.name}")
export HEKETI_CLI_SERVER=http://$(oc get route/heketi-registry -n infra-storage -o jsonpath='{.spec.host}')
export HEKETI_CLI_USER=admin
export HEKETI_CLI_KEY=$(oc get pod/$HEKETI_POD -n infra-storage -o jsonpath='{.spec.containers[0].env[?(@.name=="HEKETI_ADMIN_KEY")].value}')
export HEKETI_ADMIN_KEY_SECRET=$(echo -n ${HEKETI_CLI_KEY} | base64)

ファイルをソースして、HEKETI infra-storage 環境変数を作成します。

source heketi-exports-infra
# see if heketi is alive
curl -w '\n' ${HEKETI_CLI_SERVER}/hello
Hello from Heketi
# ask heketi about the cluster it knows about (the RHOCS cluster for infrastructure)
heketi-cli cluster list
Clusters:
Id:baf91b261cbca2bb4b62caece63f60d0 [file][block]
# ask heketi about the volumes already created
heketi-cli volume list
Id:77baed02f79f4518326d8cc1db6c7af8 Cluster:baf91b261cbca2bb4b62caece63f60d0 Name:heketidbstorage

5.8. Arbiter ボリュームの作成（オプション）

Arbitrated Replicated ボリュームの利点

同様の一貫性: arbiter が設定されている場合、arbitration ロジックはクライアント側のクォーラムを自動モードで使用して、スプリットブレイン状態につながるファイル操作を防止します。
ディスクの必要容量が少なくて済む: arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリューム内の他のブリックよりもはるかに小さくすることができます。

arbiter ボリュームを作成する前に、heketi-client パッケージがインストールされていることを確認します。

# subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms

# yum install heketi-client

注記

5.8.1. Arbiter ボリュームの作成

Arbiter ボリュームは、Heketi CLI を使用して、または storageclass ファイルを更新して作成できます。

5.8.1.1. Heketi CLI を使用した Arbiter ボリュームの作成

以下は例になります。

# heketi-cli volume create --size=4 --gluster-volume-options='user.heketi.arbiter true'

5.8.1.2. Storageclass ファイルを使用した Arbiter ボリュームの作成

storageclass ファイルを使用して arbiter ボリュームを作成するには、storageclass ファイルに以下の 2 つのパラメーターを含めるようにしてください。

user.heketi.arbiter true
（オプション）user.heketi.average-file-size 1024

以下は、storageclass ファイルのサンプルです。

# 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"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.arbiter true,user.heketi.average-file-size 1024"
  volumenameprefix: "test-vol"
spec:
  persistentVolumeReclaimPolicy: Retain
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
storage: 5Gi

5.8.2. Arbiter ボリュームとしてのブロックホストボリュームの作成

注記

storageclass ファイルに変更はありません。

ブロックホスティングボリュームを arbiter ボリュームとして作成するには、以下を実行します。

以下の環境変数および値を追加して、Heketi デプロイメント設定の Glusterfs セクションの下にある設定ファイルを編集します。
```
HEKETI_BLOCK_HOSTING_VOLUME_OPTIONS: group gluster-block,user.heketi.arbiter true
```
Heketi CLI を使用してブロックボリュームを作成します。
```
  # heketi-cli blockvolume create --size=100
```
ブロックホスティングボリュームが arbiter ボリュームであることを確認します。
```
 # gluster v info
```
注記
arbiter ボリュームの管理に関する詳細は、10章Arbitrated Replicated ボリュームの管理 を参照してください。

パート III. アップグレード

第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. 前提条件

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

「Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件」
Red Hat Gluster Storage Server および Red Hat Openshift Container Storage を備えた OpenShift Container Platform のサポートされているバージョンがあることを確認します。サポートされるバージョンの詳細は、「サポート対象バージョン」を参照してください。
以下のコマンドを実行し、最新バージョンの Ansible テンプレートを取得してください。
```
# yum update openshift-ansible
```

注記

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 ラベルを復元するには、以下のコマンドを実行します。

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

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

gluster Pod を実行するすべてのノードで以下のコマンドを実行します。これにより、ラベルがリセットされます。
```
# restorecon /dev/log
```
以下のコマンドを実行して、すべてのボリュームの自己修復のステータスを確認します。
```
# 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]$"
```
自己修復が完了するまで待ちます。
以下のコマンドを実行して、ブリックが 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 を参照してください。
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
```
oc クライアントがあるノードで以下のコマンドを実行し、gluster Pod を削除します。
```
# oc delete pod <gluster_pod_name>
```
Pod の準備ができているかどうかを確認するには、以下のコマンドを実行します。
```
# oc get pods -l glusterfs=storage-pod
```
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
```
ノードを終了します。

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

他の Pod に対して、ステップ 4 から 9 を実行します。

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

6.1.3.1. cns-deploy および Heketi Server のアップグレード

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

以下のコマンドを実行して、heketi クライアントパッケージおよび cns-deploy パッケージを更新します。
```
# yum update cns-deploy -y
# yum update heketi-client -y
```
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
```
以下のコマンドを実行して、heketi テンプレートを削除します。
```
# oc delete templates heketi
```
以下のコマンドを実行して、heketi テンプレートをインストールします。
```
oc create -f /usr/share/heketi/templates/heketi-template.yaml
template "heketi" created
```

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

以下のコマンドを実行して、新しい 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 フォーマットが厳密に必要とされています（末尾にスペースを入れない、ブール値はすべて小文字など）。
以下のコマンドを実行して、設定ファイルを保持するためのシークレットを作成します。
```
# oc create secret generic <heketi-config-secret> --from-file=heketi.json
```
注記
heketi-config-secret ファイルがすでに存在する場合は、ファイルを削除して以下のコマンドを実行します。
以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi
```
注記
これらのパラメーターの名前は、以下のコマンドの出力から参照することができます。
```
# oc get all | grep heketi
```

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

以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

# 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 を更新する手順です。

以下の手順を実行して、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
```
以下のコマンドを実行して、gluster の DaemonSet 名を検索します。
```
# oc get ds
```
以下のコマンドを実行して、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
```

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

以下のコマンドを実行して、古い glusterfs テンプレートを削除します。
```
# oc delete templates glusterfs
```
以下に例を示します。
```
# oc delete templates glusterfs
template “glusterfs” deleted
```

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

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

以下に例を示します。

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

Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。
1. 以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
```
# oc get nodes -l glusterfs=storage-host
```

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

以下のコマンドを実行して、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 を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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

以下のコマンドを実行して、ブリックが 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 を参照してください。
以下のコマンドを実行して、古い 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 を削除する前に、自己修復チェックを行う必要があります。
  以下のコマンドを実行して、gluster Pod のシェルにアクセスします。
  # oc rsh <gluster_pod_name>
  以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。
  # 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
…
```

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

以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。
```
# oc rsh <gluster_pod_name> glusterd --version
```
以下は例になります。
```
 # oc rsh glusterfs-4cpcc glusterd --version
glusterfs 6.0
```
gluster Pod のいずれかで以下のコマンドを実行し、Red Hat Gluster Storage op-version を確認します。
```
# gluster vol get all cluster.op-version
```
Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。
- DC（デプロイメント設定）をスケールアップします。
```
# oc scale dc <heketi_dc> --replicas=1
```
いずれかの 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
gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
```
# oc delete dc glusterblock-provisioner-dc
```
以下は例になります。
```
# oc delete dc glusterblock-storage-provisioner-dc
```

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

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

ブリック多重化は、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>
```
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 レジストリー Pod がある場合は、「glusterfs レジストリーグループの Pod のアップグレード」に記載の手順に進み、heketi と glusterfs レジストリー Pod をアップグレードします。
glusterfs レジストリー Pod がない場合は、「Heketi Pod の起動」に記載の手順に進み、heketi Pod を元に戻してから「Red Hat OpenShift Container Platform ノードでのクライアントのアップグレード」に記載の手順に進んで、Red Hat Openshift Container Platform ノードでクライアントをアップグレードします。

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

6.1.4.1. Heketi サーバーのアップグレード

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

以下の手順を実行して、保留中のHeketi操作を確認します。
1. 以下のコマンドを実行して、プロジェクトにアクセスします。
```
# oc project <project_name>
```
  以下は例になります。
```
# oc project storage-project
```
2. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
```
# heketi-cli server operations info
```
Heketi データベースファイルのバックアップを作成します。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
注記
作成された json ファイルを使用して復元することができるため、選択した永続ストレージに保存する必要があります。
以下のコマンドを実行して、heketi クライアントパッケージを更新します。インストールされているすべての OCP ノードで、heketi-client パッケージを更新します。新しいインストールでは、いずれのOCPノードにもheketi-client rpm がインストールされていない可能性があります。
```
# yum update heketi-client -y
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
# oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
```
HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。
```
# oc describe pod <heketi-pod>
```
以下のコマンドを実行して、heketi テンプレートを削除します。
```
# oc delete templates heketi
```

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

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

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

# 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

既存のテンプレートに 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

テンプレートに 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

注記

以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
注記
これらのパラメーターの名前は、以下のコマンドの出力から参照することができます。
```
# oc get all | grep heketi
```
```
# oc delete deploymentconfig,service,route heketi-storage
```
以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

# 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 を更新する手順です。

以下の手順を実行して、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
```
以下のコマンドを実行して、gluster の DaemonSet 名を検索します。
```
# oc get ds
```
以下のコマンドを実行して、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
```

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

以下のコマンドを実行して、古い glusterfs テンプレートを削除します。
```
# oc delete templates glusterfs
```

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

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

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

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

注記

テンプレートにパラメーターとして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 変数が正しい値に設定されていることを確認します。

Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。
1. 以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
```
# oc get nodes -l glusterfs=storage-host
```

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

以下のコマンドを実行して、ブリックが 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 を参照してください。
以下のコマンドを実行して、古い 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 を削除する前に、自己修復チェックを行う必要があります。
  以下のコマンドを実行して、gluster Pod のシェルにアクセスします。
  # oc rsh <gluster_pod_name>
  以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。
  # 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
…
```

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

以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。
```
# oc rsh <gluster_pod_name> glusterd --version
```
以下は例になります。
```
# oc rsh glusterfs-4cpcc glusterd --version
glusterfs 6.0
```
gluster Pod のいずれかで以下のコマンドを実行し、Red Hat Gluster Storage op-version を確認します。
```
# gluster vol get all cluster.op-version
```
Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。
- DC（デプロイメント設定）をスケールアップします。
```
# oc scale dc <heketi_dc> --replicas=1
```
いずれかの 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
```
gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
```
# oc delete dc glusterblock-provisioner-dc
```
以下は例になります。
```
# oc delete dc glusterblock-storage-provisioner-dc
```
以下のコマンドを実行して、古い glusterblock プロビジョナーテンプレートを削除します。
```
 # oc delete templates glusterblock-provisioner
```

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

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

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

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

テンプレートに、パラメーターとして 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

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

oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
以下に例を示します。
- 2 つ以上のプロビジョナーがある場合、名前は gluster.org/glusterblock-<namespace> である必要があります。ここで、namespace はプロビジョナーがデプロイされている namespace に置き換えられます。
- 3.11.8 より前にインストールされているプロビジョナーが 1 つしかない場合は、gluster.org/glusterblock で十分です。現在使用中の名前に一意の namespace サフィックスがある場合は、既存の名前を再利用します。

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

# 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

ブリック多重化は、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>
```
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 レジストリー Pod がある場合は、「glusterfs レジストリーグループの Pod のアップグレード」に記載の手順に進み、heketi と glusterfs レジストリー Pod をアップグレードします。
- glusterfs レジストリー Pod がない場合は、「Heketi Pod の起動」に記載の手順に進み、heketi Pod を元に戻してから「Red Hat OpenShift Container Platform ノードでのクライアントのアップグレード」に記載の手順に進んで、Red Hat Openshift Container Platform ノードでクライアントをアップグレードします。
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 -
```

6.2. glusterfs レジストリーグループの Pod のアップグレード

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

6.2.1. 前提条件

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

「Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件」
Red Hat Gluster Storage Server および Red Hat Openshift Container Storage を備えた OpenShift Container Platform のサポートされているバージョンがあることを確認します。サポートされるバージョンの詳細は、「サポート対象バージョン」を参照してください。
以下のコマンドを実行し、最新バージョンの Ansible テンプレートを取得してください。
```
# yum update openshift-ansible
```

注記

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.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 ラベルを復元するには、以下のコマンドを実行します。

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

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

gluster Pod を実行するすべてのノードで以下のコマンドを実行します。これにより、ラベルがリセットされます。
```
# restorecon /dev/log
```
以下のコマンドを実行して、すべてのボリュームの自己修復のステータスを確認します。
```
# 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]$"
```
自己修復が完了するまで待ちます。
以下のコマンドを実行して、ブリックが 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 を参照してください。
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
```
oc クライアントがあるノードで以下のコマンドを実行し、gluster Pod を削除します。
```
# oc delete pod <gluster_pod_name>
```
Pod の準備ができているかどうかを確認するには、以下のコマンドを実行します。
```
# oc get pods -l glusterfs=registry-pod
```
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
```
ノードを終了します。

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

他の Pod に対して、ステップ 4 から 9 を実行します。

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

6.2.3.1. cns-deploy および Heketi Server のアップグレード

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

以下のコマンドを実行して、heketi クライアントパッケージおよび cns-deploy パッケージを更新します。
```
# yum update cns-deploy -y
# yum update heketi-client -y
```
Heketi レジストリーデータベースファイルをバックアップします。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
以下のコマンドを実行して、heketi テンプレートを削除します。
```
# oc delete templates heketi
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
# oc get secret <heketi-admin-secret-name> -o jsonpath='{.data.key}'|base64 -d;echo
```
以下のコマンドを実行して、heketi テンプレートをインストールします。
```
# oc create -f /usr/share/heketi/templates/heketi-template.yaml
template "heketi" created
```
以下のコマンドを実行して、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
```
注記
Heketi/rhgs-volmanager Pod は heketidb ストレージ Gluster ボリュームを「glusterfs」のボリュームタイプとしてマウントし、PersistentVolume(PV)ではなく heketidb ストレージ Gluster ボリュームを「glusterfs」としてマウントするため、heketi Pod で使用するサービスアカウントは特権が必要です。
OpenShift の security-context-constraints の規定によると、configMap、downwardAPI、emptyDir、hostPath、nfs、persistentVolumeClaim、secret のタイプではないボリュームをマウントできる機能は、特権付き SCC(Security Context Constraint)のアカウントにだけ付与されます。
以下のコマンドを実行して、新しい 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 フォーマットが厳密に必要とされています（末尾にスペースを入れない、ブール値はすべて小文字など）。
以下のコマンドを実行して、設定ファイルを保持するためのシークレットを作成します。
```
# oc create secret generic <heketi-registry-config-secret> --from-file=heketi.json
```
注記
heketi-registry-config-secret ファイルがすでに存在する場合は、ファイルを削除して以下のコマンドを実行します。
以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi-registry
```

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

注記

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

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

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

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

# 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.2.3.2. Red Hat Gluster Storage レジストリー Pod のアップグレード

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

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

以下の手順を実行して、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
```
以下のコマンドを実行して、gluster の DaemonSet 名を検索します。
```
# oc get ds
```
以下のコマンドを実行して、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
```

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

以下のコマンドを実行して、古い glusterfs テンプレートを削除します。
```
# oc delete templates glusterfs
```
以下に例を示します。
```
# oc delete templates glusterfs
template “glusterfs” deleted
```
Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。
1. 以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
```
# oc get nodes -l glusterfs=registry-host
```

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

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

以下に例を示します。

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

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

以下のコマンドを実行して、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 を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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

以下のコマンドを実行して、ブリックが 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 を参照してください。
以下のコマンドを実行して、古い 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-0vcf3
pod  “glusterfs-0vcf3” deleted
```
  注記
  次の Pod を削除する前に、自己修復チェックを行う必要があります。
  以下のコマンドを実行して、glusterfs-registry Pod のシェルにアクセスします。
  # oc rsh <gluster_pod_name>
  以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。
  # 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
…
```

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

以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。
```
# oc rsh <gluster_registry_pod_name> glusterd --version
```
以下は例になります。
```
 # oc rsh glusterfs-registry-4cpcc glusterd --version
glusterfs 6.0
```
```
# rpm -qa|grep gluster
```

glusterfs-registry Pod のいずれかで以下のコマンドを実行して、Red Hat Gluster Storage op-version を確認します。
```
# gluster vol get all cluster.op-version
```
Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。
- DC（デプロイメント設定）をスケールアップします。
```
# oc scale dc <heketi_dc> --replicas=1
```
いずれかの Pod で cluster.op-version を 70200 に設定します。
注記
cluster.op-version を変更する前に、すべての glusterfs-registry Pod が更新されていることを確認します。
```
# gluster 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-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
```
gluster-block-registry-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
```
# oc delete dc <gluster-block-registry-dc>
```
以下は例になります。
```
# oc delete dc glusterblock-registry-provisioner-dc
```

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

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

ブリック多重化は、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>
```
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 ノードでクライアントをアップグレードします。

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

6.2.4.1. Heketi サーバーのアップグレード

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

注記

OCS 3.10 を Ansible 経由でデプロイした場合は、「yum update cns-deploy -y」を実行する必要はありません。

以下の手順を実行して、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
```
Heketi データベースファイルのバックアップを作成します。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
注記
作成された json ファイルを使用して復元することができるため、選択した永続ストレージに保存する必要があります。
以下のコマンドを実行して、heketi クライアントパッケージを更新します。インストールされているすべての OCP ノードで、heketi-client パッケージを更新します。新しいインストールでは、いずれのOCPノードにもheketi-client rpm がインストールされていない可能性があります。
```
# yum update heketi-client -y
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
# oc get secret heketi-registry-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
```
HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。
```
# oc describe pod <heketi-pod>
```

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

テンプレートに既存の 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-registry
- 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: registry
- 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

# 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-registry
- 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-registry cluster name
  name: CLUSTER_NAME
  value: registry
- 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

注記

以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi-registry
```
以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。
```
# oc process heketi | oc create -f -

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

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

# 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.2.4.2. Red Hat Gluster Storage レジストリー Pod のアップグレード

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

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

以下の手順を実行して、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
```
以下のコマンドを実行して、gluster の DaemonSet 名を検索します。
```
# oc get ds
```
以下のコマンドを実行して、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
```

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

以下のコマンドを実行して、古い glusterfs テンプレートを削除します。
```
 # oc delete templates glusterfs
```

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

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

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

テンプレートに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

# 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

注記

CLUSTER_NAME 変数が正しい値に設定されていることを確認します。
クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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 を削除する前に、自己修復チェックを行う必要があります。
    以下のコマンドを実行して、glusterfs-registry Pod のシェルにアクセスします。
    # oc rsh <gluster_pod_name>
    以下のコマンドを実行して、すべてのボリュームの自己修復ステータスを確認します。
    # 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
```

6.3. Heketi Pod の起動

glusterfs と registry namespace の両方に対して、クライアントマシンで以下のコマンドを実行します。

以下のコマンドを実行して、Heketi Pod が実行されているプロジェクトに移動します。
```
# oc project <project_name>
```
glusterfs namespace の場合は以下を実行します。
```
# oc project glusterfs
```
たとえば、レジストリー namespace の場合は以下を実行します。
```
# oc project glusterfs-registry
```

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

# oc get dc

たとえば、glusterfs-registry プロジェクトでは以下を実行します。

# oc get dc
NAME                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
glusterblock-storage-provisioner-dc   1          1         0         config
heketi-storage                        4          1         1         config

たとえば、glusterfs プロジェクトでは以下を実行します。

# oc get dc
NAME                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
glusterblock-storage-provisioner-dc   1          1         0         config
heketi-storage                        4          1         1         config

以下のコマンドを実行して、レプリカ数を 0 から 1 に増やします。これにより、Heketi Pod が戻ります。
```
# oc scale dc <heketi_dc> --replicas=1
```

以下のコマンドを実行して、heketi Pod が glusterfs および glusterfs-registry namespace の両方に存在することを確認します。

# oc get pods

たとえば、glusterfs の場合は以下を実行します。

# 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

たとえば、レジストリー Pod の場合は以下を実行します。

# 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.4. Red Hat OpenShift Container Platform ノードでのクライアントのアップグレード

各ノードで以下のコマンドを実行します。

Pod をドレインするには、マスターノード（または cluster-admin アクセスを持つ任意のノード）で、以下のコマンドを実行します。
```
# oc adm drain <node_name> --ignore-daemonsets
```
すべての Pod がドレインされていることを確認するには、マスターノード (または cluster-admin アクセスを持つ任意のノード) で以下のコマンドを実行します。
```
# oc get pods --all-namespaces --field-selector=spec.nodeName=<node_name>
```
以下のコマンドを実行して、クライアントノードを最新の glusterfs-fuse バージョンにアップグレードします。
```
# yum update glusterfs-fuse
```
Pod のスケジューリングのノードを有効にするには、マスターノード（または cluster-admin アクセスを持つ任意のノード）で以下のコマンドを実行します。
```
# oc adm manage-node --schedulable=true <node_name>
```

multipath.conf ファイルに以下の内容を作成して追加します。

注記

multipath.conf ファイルは、以前のアップグレード時に変更が実装されているため、変更する必要はありません。

# cat >> /etc/multipath.conf <<EOF
# LIO iSCSI
devices {
  device {
    vendor "LIO-ORG"
    user_friendly_names "yes" # names like mpatha
    path_grouping_policy "failover" # one path per group
    hardware_handler "1 alua"
    path_selector "round-robin 0"
    failback immediate
    path_checker "tur"
    prio "alua"
    no_path_retry 120
    rr_weight "uniform"
  }
}
EOF

以下のコマンドを実行して、マルチパスデーモンを起動し、マルチパス設定を(再)読み込みします。
```
# systemctl start multipathd
```
```
# systemctl reload multipathd
```

第7章 Playbook を使用したアップグレード

注記

テクノロジープレビュー機能は、Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、お客様は機能性をテストし、開発プロセス中にフィードバックをお寄せいただくことができます。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/を参照してください。

注記

Openshift Container Storage のアップグレードの実行中に、クラスター上で実行されているアプリケーション Pod に問題が発生してエラー状態になっても、アップグレード Playbook は失敗せず、警告も表示されません。そのため、クラスター管理者は Openshift Container Storage アップグレード Playbook の実行中にクラスター内のすべての Pod およびノードの正常性を確認する必要があります。

重要

アップグレード Playbook は、利用可能な最新の OpenShift Container Storage ビットにアップグレードする場合にのみ使用されます。

Playbook: upgrade.yml

この Playbook は、既存の OpenShift クラスターで GlusterFS 関連のリソースをアップグレードすることを目的としています。これは、コンバージドモードの config.yml Playbook を使用してデプロイされた GlusterFS リソースにのみ適用されます。
この Playbook はテクノロジープレビュー機能で、変数 openshift_storage_gluster_update_techpreview=true を使用して確認する必要があります。
以下の変数を必要なバージョンに更新した後に、インストールの同じインベントリーを再利用する必要があります。

openshift_storage_glusterfs_image
openshift_storage_glusterfs_heketi_image
openshift_storage_glusterfs_block_image
openshift_storage_glusterfs_fuse_version

7.1. アップグレード Playbook のパラメーター

openshift_storage_glusterfs_health_timeout=10: この変数で、クラスターのヘルスチェックの再試行回数が制限されます。変数の値は 10 の倍数でなければならず、10 は 1 つの再試行、20 は 2 つの再試行を意味します。この値は 10 未満にしないでください。この var のデフォルト値は 30 であるため、何も指定せず、Playbook は 3 回再試行します。
openshift_storage_gluster_update_techpreview=true: Playbook はテクノロジープレビュー機能です。アップグレード Playbook を使用するには、この変数を true に設定します。
openshift_storage_glusterfs_fuse_version=<version>: ノードを特定のクライアントパッケージにアップグレードするには、アップグレードするバージョンを指定する必要があります。
の例：

 openshift_storage_glusterfs_fuse_version=-3.12.2-18.el7

openshift_storage_glusterfs_check_brick_size_health=false: Playbook の実行時に、ブリックの容量をチェックしますが、ブリックをチェックする時に、ブロックホスティングボリュームに含まれるブリックをチェックから除外する必要があります。そのために、インベントリーファイルで上記の変数を false に設定する必要があります。

第8章インデペンデントモードでの Red Hat Openshift Container Storage のアップグレード

本章では、インデペンデントモード環境をアップグレードする手順を説明します。

注記

本書では、新しいレジストリー名 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

8.1. 前提条件

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

「Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件」
ポートアクセスの設定: https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#CRS_port_access
カーネルモジュールの有効化: https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#CRS_enable_kernel
サービスの起動と有効化: https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#Start_enable_service
Red Hat Gluster Storage Server および Red Hat Openshift Container Storage を備えた OpenShift Container Platform のサポートされているバージョンがあることを確認します。サポートされるバージョンの詳細は、「サポート対象バージョン」を参照してください。
Heketi が Red Hat Gluster Storage ノードの 1 つでスタンドアロンサービスとして実行されている場合は、Heketi のポートを開くようにしてください。デフォルトでは、Heketi のポート番号は 8080 です。このポートを開くには、Heketi が実行されているノードで以下のコマンドを実行します。
```
# firewall-cmd --zone=zone_name --add-port=8080/tcp
# firewall-cmd --zone=zone_name --add-port=8080/tcp --permanent
```
Heketi が別のポートでリッスンするように設定されている場合は、コマンド内のポート番号を適宜変更します。
ブリックの多重化が有効になっていることを確認します。ブリックの多重化ステータスは、以下のコマンドを使用して確認できます。
```
# gluster v get all all
```
マスターノードで以下のコマンドを実行して、Ansible テンプレートの最新バージョンを取得してください。
```
# yum update openshift-ansible
```

8.2. glusterfs グループのノードと Pod のアップグレード

以下のセクションの手順に従って、インデペンデントモードの設定をアップグレードします。

8.2.1. Red Hat Gluster Storage Cluster のアップグレード

Red Hat Gluster Storage クラスターをアップグレードするには、In-Service Software Upgradeを参照してください。

8.2.2. RHGS ノードの Heketi のアップグレード/移行

注記

Heketi が Openshift ノードにある場合は、このセクションを省略し、代わりに「Openshift ノードでの Heketi のアップグレード」を参照してください。

重要

OCS 3.11 では、RHGS ノードの Heketi のアップグレードはサポートされていません。したがって、heketi を新規の heketi Pod に移行する必要があります。
今後のバージョンで移行パスが存在しない可能性があるため、サポートされている heketi デプロイメントに移行してください。
cns-deploy rpm がマスターノードにインストールされていることを確認します。これは、heketi Pod の設定に必要なテンプレートファイルを提供します。
```
# subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms
```

# yum install cns-deploy

マスターノードで新たに作成されたコンテナー化された Red Hat Gluster Storage プロジェクトを使用します。
```
# oc project <project-name>
```
以下は例になります。
```
# oc project gluster
```

マスターノードで以下のコマンドを実行して、サービスアカウントを作成します。

# oc create -f /usr/share/heketi/templates/heketi-service-account.yaml
serviceaccount/heketi-service-account created

マスターノードで以下のコマンドを実行して、heketi テンプレートをインストールします。
```
# oc create -f /usr/share/heketi/templates/heketi-template.yaml
template.template.openshift.io/heketi created
```

テンプレートが作成されているかどうかを確認します。

# oc get templates

NAME            DESCRIPTION                          PARAMETERS    OBJECTS
heketi          Heketi service deployment template   5 (3 blank)   3

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

# oc policy add-role-to-user edit system:serviceaccount:gluster:heketi-service-account
role "edit" added: "system:serviceaccount:gluster:heketi-service-account"

# oc adm policy add-scc-to-user privileged -z heketi-service-account
scc "privileged" added to: ["system:serviceaccount:gluster:heketi-service-account"]

heketi が実行されている RHGS ノードで、以下のコマンドを実行します。
1. heketidbstorage ボリュームを作成します。
```
# heketi-cli volume create --size=2 --name=heketidbstorage
```
2. ボリュームをマウントします。
```
# mount  -t glusterfs 192.168.11.192:heketidbstorage /mnt/
```
  192.168.11.192 は RHGS ノードの 1 つになります。
3. heketi サービスを停止します。
```
# systemctl stop heketi
```
4. heketi サービスを無効にします。
```
# systemctl disable heketi
```
5. heketi db を heketidbstorage ボリュームにコピーします。
```
# cp /var/lib/heketi/heketi.db /mnt/
```
6. ボリュームをアンマウントします。
```
# umount /mnt
```
7. 以下のファイルを heketi ノードからマスターノードにコピーします。
```
# scp   /etc/heketi/heketi.json  topology.json   /etc/heketi/heketi_key  OCP_master_node:/root/
```
  OCP_master_node は、マスターノードのホスト名になります。
マスターノードで、heketi ノードからコピーした以下の 3 つのファイルの環境変数を設定します。以下の行を ~/.bashrc ファイルに追加し、bash コマンドを実行して変更を適用して保存します。
```
export SSH_KEYFILE=heketi_key
export TOPOLOGY=topology.json
export HEKETI_CONFIG=heketi.json
```
注記
/etc/heketi/heketi.json の「keyfile」の値を異なる値に変更している場合は、ここで適宜、変更します。

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

# oc create secret generic heketi-config-secret --from-file=${SSH_KEYFILE} --from-file=${HEKETI_CONFIG} --from-file=${TOPOLOGY}

secret/heketi-config-secret created

以下のコマンドを実行してシークレットにラベルを付けます。

# oc label --overwrite secret heketi-config-secret glusterfs=heketi-config-secret heketi=config-secret

secret/heketi-config-secret labeled

heketi-gluster-endpoints.yaml ファイルを作成し、すべての glusterfs ノードの IP アドレスを取得します。
1. heketi-gluster-endpoints.yaml ファイルを作成します。
```
# oc create -f ./heketi-gluster-endpoints.yaml
```
2. すべての glusterfs ノードの IP アドレスを取得します。
```
# cat heketi-gluster-endpoints.yaml
apiVersion: v1
kind: Endpoints
metadata:
  name: heketi-storage-endpoints
subsets:
- addresses:
  - ip: 192.168.11.208
  ports:
  - port: 1
- addresses:
  - ip: 192.168.11.176
  ports:
  - port: 1
- addresses:
  - ip: 192.168.11.192
  ports:
  - port: 1
```
  上記の例では、192.168.11.208、192.168.11.176、192.168.11.192 は glusterfs ノードです。

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

# oc create -f ./heketi-gluster-service.yaml

以下に例を示します。

# cat heketi-gluster-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: heketi-storage-endpoints
spec:
  ports:
  - port: 1

以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。
```
# oc process heketi | oc create -f -
service/heketi created
route.route.openshift.io/heketi created
deploymentconfig.apps.openshift.io/heketi created
```
注記
db ワークロード用に、heketidbstorage ボリュームを調整することを推奨します。新たにインストールされた Openshift Container Storage デプロイメントにより、heketidbstorage ボリュームが自動的にチューニングされます。古いデプロイメントの場合は、KCS の記事 Planning to run containerized DB or nosql workloads on Openshift Container Storage? に従って、ボリューム heketidbstorage のボリュームセット操作を実行します。
Heketi が移行されているかどうかを確認するには、マスターノードで以下のコマンドを実行します。
```
# oc rsh po/<heketi-pod-name>
```
以下は例になります。
```
# oc rsh po/heketi-1-p65c6
```
以下のコマンドを実行して、クラスター ID を確認します。
```
# heketi-cli cluster list
```
出力から、クラスター ID が古いクラスターと一致するかどうかを確認します。

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

8.2.3.1. Openshift ノードでの Heketi のアップグレード

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

以下のコマンドを実行して、heketi クライアントパッケージおよび cns-deploy パッケージを更新します。
```
# yum update cns-deploy -y
# yum update heketi-client -y
```
Heketi データベースファイルのバックアップを作成します。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
oc get secret <heketi-admin-secret-name> -o jsonpath='{.data.key}'|base64 -d;echo
```
<heketi-admin-secret-name> は、ユーザーが作成した heketi 管理シークレットの名前に置き換えます。
以下のコマンドを実行して、heketi テンプレートを削除します。
```
# oc delete templates heketi
```
以下のコマンドを実行して、heketi テンプレートをインストールします。
```
# oc create -f /usr/share/heketi/templates/heketi-template.yaml
template "heketi" created
```
- 以下のコマンドを実行して、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
```
  注記
  Heketi/rhgs-volmanager Pod は heketidb ストレージ Gluster ボリュームを「glusterfs」のボリュームタイプとしてマウントし、PersistentVolume(PV)ではなく heketidb ストレージ Gluster ボリュームを「glusterfs」としてマウントするため、heketi Pod で使用するサービスアカウントは特権が必要です。
  OpenShift の security-context-constraints の規定によると、configMap、downwardAPI、emptyDir、hostPath、nfs、persistentVolumeClaim、secret のタイプではないボリュームをマウントできる機能は、特権付き SCC(Security Context Constraint)のアカウントにだけ付与されます。
以下のコマンドを実行して、新しい heketi 設定ファイルを生成します。
```
# sed -e "s/\${HEKETI_EXECUTOR}/ssh/" -e "s#\${HEKETI_FSTAB}#/etc/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/#Block_Storageを参照してください）。このデフォルト設定では、より多くの領域が必要になるため、500GB のブロックホスティングボリュームを動的に作成します。
- または、/usr/share/heketi/templates/heketi.json.template を現在のディレクトリーの heketi.json にコピーし、新規ファイルを直接編集して、各"${VARIABLE}"文字列を必要なパラメーターに置き換えます。
  注記
  JSON フォーマットが厳密に必要とされています（末尾にスペースを入れない、ブール値はすべて小文字など）。
以下のコマンドを実行して、設定ファイルを保持するためのシークレットを作成します。
```
# oc create secret generic heketi-config-secret --from-file=private_key=${SSH_KEYFILE} --from-file=./heketi.json
```
注記
heketi-config-secret ファイルがすでに存在する場合は、ファイルを削除して以下のコマンドを実行します。
以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi
```

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

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

# 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: ssh
  - description: Set the fstab path, file that is populated with bricks that heketi creates
    displayName: heketi fstab path
    name: HEKETI_FSTAB
    value: /etc/fstab
  - 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

注記

アップグレードするバージョンに応じて、IMAGE_NAME の下の 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:v3.11.8

以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

# 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

8.2.3.2. Gluster ブロックのアップグレード

以下の手順を実行して、glusterブロックをアップグレードします。

注記

ブロックストレージに推奨される Red Hat Enterprise Linux(RHEL)バージョンは RHEL 7.5.4 です。カーネルのバージョンが 3.10.0-862.14.4.el7.x86_64 と一致していることを確認してください。確認するには、以下を実行します。

# uname -r

最新のカーネル更新を有効にするためにノードを再起動します。

gluster ブロックを使用するには、/etc/heketi/heketi.JSON の heketi 設定ファイルの glusterfs セクションに、以下の 2 つのパラメーターを追加します。
```
auto_create_block_hosting_volume
block_hosting_volume_size
```
ここで、
auto_create_block_hosting_volume: 見つからない場合や、既存のボリュームが使い切った場合には、ブロックホストが自動的に作成されます。この機能を有効にするには、値を true に設定します。
block_hosting_volume_size: 上記のサイズで、ボリュームをホストする新しいブロックが作成されます。これは、auto_create_block_hosting_volume が true に設定されている場合にのみ考慮されます。推奨されるサイズは 500G です。
以下は例になります。
```
.....
  .....
  "glusterfs" : {
      "executor" : "ssh",

      "db" : "/var/lib/heketi/heketi.db",

      "sshexec" : {
      "rebalance_on_expansion": true,
      "keyfile" : "/etc/heketi/private_key"
      },

      "auto_create_block_hosting_volume": true,

      "block_hosting_volume_size": 500G
    },
  .....
.....
```
Heketi サービスを再起動します。
```
# systemctl restart heketi
```
注記
heketi が Openshift クラスターで Pod として実行されている場合には、この手順は該当しません。
gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
```
# oc delete dc <gluster-block-dc>
```
以下は例になります。
```
# oc delete dc glusterblock-provisioner-dc
```

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

glusterfs 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

レジストリー 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

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

# sed -e 's/\\\${NAMESPACE}/<NAMESPACE>/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | oc create -f -

# 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 | oc create -f -

# oc adm policy add-cluster-role-to-user glusterblock-provisioner-runner system:serviceaccount:storage-project:glusterblock-provisioner

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

8.2.4.1. Openshift ノードでの Heketi のアップグレード

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

以下のコマンドを実行して、heketi クライアントを更新します。
```
# yum update heketi-client -y
```
Heketi データベースファイルのバックアップを作成します。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
```
HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。
```
 # oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
```
以下のコマンドで、HEKETI_USER_KEY を先に設定しておくと取得できます。
```
 # oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
```
HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。
```
 #  oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
```
以下のコマンドを実行して、heketi テンプレートを削除します。
```
 # oc delete templates heketi
```

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

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

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

# 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

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

注記

HEKETI_LVM_WRAPPER パラメーターの値は、LVM のラッパーコマンドを参照します。インデペンデントモードの設定では、ラッパーは以下のように値を空の文字列に変更します。

# 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: ssh
- description: Set the fstab path, file that is populated with bricks that heketi creates
  displayName: heketi fstab path
  name: HEKETI_FSTAB
  value: /etc/fstab
- 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: ""

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

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: ssh
  - description: Set the fstab path, file that is populated with bricks that heketi creates
    displayName: heketi fstab path
    name: HEKETI_FSTAB
    value: /etc/fstab
  - 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.7
  - 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: ""

注記

以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi-storage
```
以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

# 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

8.2.4.2. Ansible を使用してデプロイされた場合の Gluster ブロックのアップグレード

以下の手順を実行して、glusterブロックをアップグレードします。

注記

# uname -r

最新のカーネル更新を有効にするためにノードを再起動します。

以下のコマンドを実行して、古い glusterblock プロビジョナーテンプレートを削除します。
```
 # oc delete templates glusterblock-provisioner
```

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

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

gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
glusterfs namespace の場合:
```
# oc delete dc glusterblock-storage-provisioner-dc
```
glusterfs-registry namespace の場合:
```
oc delete dc glusterblock-registry-provisioner-dc
```

glusterblock-provisioner テンプレートを編集して IMAGE_NAME、IMAGE_VERSION および NAMESPACE を変更します。

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

# 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

テンプレートに、パラメーターとして 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

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

glusterfs 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

レジストリー 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

oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
以下に例を示します。
- 2 つ以上のプロビジョナーがある場合、名前は gluster.org/glusterblock-<namespace> である必要があります。ここで、namespace はプロビジョナーがデプロイされている namespace に置き換えられます。
- 3.11.8 より前にインストールされているプロビジョナーが 1 つしかない場合は、gluster.org/glusterblock で十分です。現在使用中の名前に一意の namespace サフィックスがある場合は、既存の名前を再利用します。

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

# 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

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 - storageclass.storage.k8s.io/glusterfs-registry-block created
```

8.2.5. S3 と互換性のあるオブジェクトストアの有効化

S3 と互換性のあるオブジェクトストアのサポートは、テクノロジープレビューです。S3 と互換性のあるオブジェクトストアを有効にするには、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#S3_Object_Store を参照してください。

注記

glusterfs レジストリー namespace に gluster ノードと heketi Pod がある場合は、「glusterfs レジストリーグループのノードと Pod のアップグレード」セクションの手順に従います。
S3 と互換性のあるオブジェクトストアは、Red Hat Openshift Container Storage 3.11.4 以前リリースでのみ利用可能です。

8.3. glusterfs レジストリーグループのノードと Pod のアップグレード

このセクションの手順に従って、glusterfs の registry namespace で gluster ノードと heketi Pod をアップグレードします。

8.3.1. Red Hat Gluster Storage レジストリークラスターのアップグレード

Red Hat Gluster Storage クラスターをアップグレードするには、In-Service Software Upgradeを参照してください。

8.3.1.1. Heketi レジストリー Pod のアップグレード

注記

Heketi が Openshift ノードにない場合には、RHGS ノードの Heketi を Openshift ノードに移行する必要があります。移行方法の詳細は、「RHGS ノードの Heketi のアップグレード/移行」を参照してください。

Heketi レジストリー Pod をアップグレードするには、以下の手順を実行します。

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

以下のコマンドを実行して、heketi クライアントを更新します。
```
# yum update heketi-client -y
```
Heketi レジストリーデータベースファイルをバックアップします。
```
# heketi-cli db dump > heketi-db-dump-$(date -I).json
```
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを自由に選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
```
# oc get secret heketi-registry-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
```
HEKETI_USER_KEY を取得するには、以下のコマンドを実行します。
```
# oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
```
以下のコマンドを実行して、heketi テンプレートを削除します。
```
# oc delete templates heketi
```

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

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

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

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

注記

# 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: ssh
- description: Set the fstab path, file that is populated with bricks
  that heketi creates
  displayName: heketi fstab path
  name: HEKETI_FSTAB
  value: /etc/fstab
- description: Set the hostname for the route URL
  displayName: heketi route name
  name: HEKETI_ROUTE
  value: heketi-registry
- 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: registry
- 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: ""

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: ssh
  - description: Set the fstab path, file that is populated with bricks that heketi creates
    displayName: heketi fstab path
    name: HEKETI_FSTAB
    value: /etc/fstab
  - description: Set the hostname for the route URL
    displayName: heketi route name
    name: HEKETI_ROUTE
    value: heketi-registry
  - displayName: heketi container image name
    name: IMAGE_NAME
    required: true
    value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.7
  - description: A unique name to identify this heketi service, useful for running multiple heketi instances
    displayName: GlusterFS cluster name
    name: CLUSTER_NAME
    value: registry
  - 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:""

注記

以下のコマンドを実行して、heketi のデプロイメント設定、サービス、ルートを削除します。
```
# oc delete deploymentconfig,service,route heketi-registry
```
以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。
```
# oc process heketi | oc create -f -
service "heketi-registry" created route "heketi-registry" created deploymentconfig "heketi-registry" created
```
注記
db ワークロード用に、heketidbstorage ボリュームを調整することを推奨します。新たにインストールされた Openshift Container Storage デプロイメントにより、heketidbstorage ボリュームが自動的にチューニングされます。古いデプロイメントの場合は、KCS の記事 Planning to run containerized DB or nosql workloads on Openshift Container Storage? に従って、ボリューム heketidbstorage のボリュームセット操作を実行します。

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

# 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

8.3.2. glusterblock-provisioner Pod のアップグレード

glusterblock-provisioner Pod をアップグレードするには、以下の手順を実行します。

以下のコマンドを実行して、古い glusterblock プロビジョナーテンプレートを削除します。
```
# oc delete templates glusterblock-provisioner
```

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

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

glusterblock-provisoner Pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。
```
# oc delete dc <gluster-block-registry-dc>
```
以下は例になります。
```
# oc delete dc glusterblock-registry-provisioner-dc
```

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

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

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

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

  - displayName: glusterblock provisioner container image version
    name: IMAGE_VERSION
    required: true
    value: v3.11.8

テンプレートに、パラメーターとして 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-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

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

  - displayName: glusterblock provisioner container image name
    name: IMAGE_NAME
    required: true
    value: rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8

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

oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
以下に例を示します。
- 2 つ以上のプロビジョナーがある場合、名前は gluster.org/glusterblock-<namespace> である必要があります。ここで、namespace はプロビジョナーがデプロイされている namespace に置き換えられます。
- 3.11.8 より前にインストールされているプロビジョナーが 1 つしかない場合は、gluster.org/glusterblock で十分です。現在使用中の名前に一意の namespace サフィックスがある場合は、既存の名前を再利用します。

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

# 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

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

8.3.3. Gluster ブロックのアップグレード

gluster ブロックをアップグレードするには、以下の手順を実行します。

以下のコマンドを実行して gluster ブロックをアップグレードします。
```
# yum update gluster-block
```
- gluster ブロックサービスを有効にして起動します。
```
# systemctl enable gluster-blockd
# systemctl start gluster-blockd
```

8.4. Red Hat OpenShift Container Platform ノードでのクライアントのアップグレード

各ノードで以下のコマンドを実行します。

Pod をドレインするには、マスターノード（または cluster-admin アクセスを持つ任意のノード）で、以下のコマンドを実行します。
```
# oc adm drain <node_name> --ignore-daemonsets
```
すべての Pod がドレインされていることを確認するには、マスターノード (または cluster-admin アクセスを持つ任意のノード) で以下のコマンドを実行します。
```
# oc get pods --all-namespaces --field-selector=spec.nodeName=<node_name>
```
ノードで以下のコマンドを実行して、ノード上のクライアントをアップグレードします。
```
# yum update glusterfs-fuse
```
Pod のスケジューリングのノードを有効にするには、マスターノード（または cluster-admin アクセスを持つ任意のノード）で以下のコマンドを実行します。
```
# oc adm manage-node --schedulable=true <node_name>
```
- multipath.conf ファイルに以下の内容を作成して追加します。
注記
multipath.conf ファイルは、以前のアップグレード時に変更が実装されているため、変更する必要はありません。
+
```
# cat >> /etc/multipath.conf <<EOF
# LIO iSCSI
devices {
  device {
    vendor "LIO-ORG"
    user_friendly_names "yes" # names like mpatha
    path_grouping_policy "failover" # one path per group
    hardware_handler "1 alua"
    path_selector "round-robin 0"
    failback immediate
    path_checker "tur"
    prio "alua"
    no_path_retry 120
  }
}
EOF
```
以下のコマンドを実行して、マルチパスデーモンを起動し、マルチパス設定を(再)読み込みします。
```
# systemctl start multipathd
```
```
# systemctl reload multipathd
```

パート IV. アンインストール

第9章 Red Hat OpenShift Container Storage のアンインストール

Red Hat Openshift Container Storage の場合には、OpenShift Container Platform Advanced Installer には、クラスターから全リソースおよびアーティファクトをアンインストールする Playbook が同梱されています。これを使用するには、Red Hat Openshift Container Storage のターゲットインスタンスのインストールに使用された元のインベントリーファイルを指定し、以下の Playbook を実行します。

Openshift Container Storage をアンインストールする前に、Openshift Container Storage ファイルを使用するすべてのアプリケーションおよびブロック物理ボリュームおよび、すべての PV が削除されていることを確認します。削除しなかった場合には、ノードが再起動されるまでリソースを保持し続ける可能性があります。

警告

この手順では、データが破棄されます。注意して進めてください。

ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml

さらに、Playbook は、openshift_storage_glusterfs_wipe という変数の使用をサポートします。これが有効な場合には、Red Hat Gluster Storage バックエンドストレージに使用されたブロックデバイス上のデータを破棄します。破棄される設定/変数の詳細は、付録B アンインストール Playbook の使用時に破棄される設定 を参照してください。この変数は、以下の形式で使用することが推奨されます。

ansible-playbook -i <path_to_inventory_file> -e "openshift_storage_glusterfs_wipe=true" /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml

注記

gluster-block がアンインストールされている場合は、/etc/target/saveconfig.json の gluster-block に対応するエントリーが削除されていることを確認してください。設定ファイルには gluster-block 以外のエントリーが含まれる可能性があるため、gluster-block エントリーを手動で削除する必要があります。
OCS のアンインストール後にすべてのイニシエーターから、Dangling iqns をログアウトします。

パート V. ワークロード

第10章 Arbitrated Replicated ボリュームの管理

10.1. Arbiter ブリックサイズの管理

標準レプリカ 3 ボリュームには、各セットで同じサイズのブリックが含まれていますが、arbiter ボリュームにはブリックセットの中にデータブリックよりも小さいサイズのブリックが 1 つ含まれている場合があります。

Arbiter ブリックのサイズを最適化するために、Heketi では、Aribiter ブリックの最終サイズを計算するために使用される平均的なファイルサイズ値を指定できます。これは、ボリュームオプション「user.heketi.average-file-size NUM」を使用して実行されます。ここで、NUM は KiB の整数値になります。デフォルトでは、Heketi は 64KiB の値を使用します。

heketi-cli コマンドラインツールを使用して、カスタム平均ファイルサイズで arbiter ボリュームを作成するには、ボリュームオプション "user.heketi.arbiter true" および "user.heketi.average-file-size 1024" を指定する必要があります。

以下は例になります。

# heketi-cli volume create --size=4 --gluster-volume-options='user.heketi.arbiter true,user.heketi.average-file-size 1024'

10.2. Arbiter ブリック配置の管理

Arbiter ブリックの配置先を制御するタスクの実行に、Heketi は特定のノードおよびデバイスタグを使用します。Arbiter 機能の場合、「arbiter」タグは「supported」、「required」、または「disabled」の値が指定されたノードまたはデバイスに適用できます。

ここで、

supported: arbiter ブリックとデータブリックの両方が可能です。
required: Arbiter ブリックのみが許可され、データブリックは拒否されます。
disabled: データブリックのみが許可され、arbiter ブリックは拒否されます。

ユースケースに基づいて、ノードまたはデバイスにタグを設定できます。

たとえば、Arbiter を使用して Arbiter ノードがデータをホストするノード間の専用のタイブレーカーとして機能するようにノードを分割するには、ノードにタグを設定します。

以下の例は、デバイスにタグを設定する方法を示しています。ノードには異種のデバイスタイプがあり、1 つのノードには、サイズの小さい nvme デバイスを、2 つ (以上の) ノードにはサイズの大きい SSD を指定するなど、特定の省スペースパターンを設定します。これを実行するには、サイズの小さいデバイスを d1(arbiter:required)として、サイズの大きいデバイスを d2 および d3(arbiter:disabled)として識別して、デバイスにタグを設定します。

注記

明示的なタグのないデバイスは、接続先のノードから arbiter タグ値を自動的に継承します。デバイスへの明示的なタグは常にノードのタグよりも優先されます。

10.2.1. Heketi CLI を使用したタグの設定

heketi-cli コマンドラインツールを使用してノードとデバイスにタグを設定するには、以下のコマンドを実行します。

ノード

# heketi-cli node settags <node id> arbiter:<tag>

以下は例になります。

# heketi-cli node settags e2a792a43ca9a6bac4b9bfa792e89347 arbiter:disabled

デバイス

# heketi-cli device settags <device id> arbiter:<tag>

以下は例になります。

# heketi-cli device settags 167fe2831ad0a91f7173dac79172f8d7 arbiter:required

10.2.2. Heketi CLI を使用したタグの削除

arbiter タグを削除する場合は、以下のコマンドを実行します。

ノード

# heketi-cli node rmtags <node id> arbiter

以下は例になります。

# heketi-cli node rmtags e2a792a43ca9a6bac4b9bfa792e89347 arbiter

デバイス

# heketi-cli device rmtags <device id> arbiter

以下は例になります。

# heketi-cli device rmtags 167fe2831ad0a91f7173dac79172f8d7 arbiter

10.2.3. Heketi CLI を使用したタグの表示

タグを表示するには、以下のコマンドを実行します。ノードまたはデバイスにタグがある場合、"Tags" の見出しの下にある一覧に表示されます。

ノード

# heketi-cli node info <node id>

以下は例になります。

# heketi-cli node info e2a792a43ca9a6bac4b9bfa792e89347
Node Id: e2a792a43ca9a6bac4b9bfa792e89347
State: online
Cluster Id: ddb14817873c13c5bb42a5c04969daf9
Zone: 1
Management Hostname: 10.0.0.1
Storage Hostname: 10.0.0.1
Tags:
  arbiter: disabled
  test: demonstration
Devices:
Id:0b39f89c0677e8c0b796caf00204e726   Name:/dev/vdb            State:online    Size (GiB):500     Used (GiB):0       Free (GiB):500     Bricks:0
Id:167fe2831ad0a91f7173dac79172f8d7   Name:/dev/vdg            State:online    Size (GiB):500     Used (GiB):0       Free (GiB):500     Bricks:0

デバイス

# heketi-cli device info <device id>

以下は例になります。

# heketi-cli device info 167fe2831ad0a91f7173dac79172f8d7
Device Id: 167fe2831ad0a91f7173dac79172f8d7
Name: /dev/vdg
State: online
Size (GiB): 500
Used (GiB): 0
Free (GiB): 500
Tags:
  arbiter: required
  foobar: magic
Bricks:

10.3. 永続ボリュームの作成

永続ボリュームの作成に関する詳細は、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 を参照してください。

重要

Storage Class ファイルでは、volumeoptions パラメーターに "user.heketi.arbiter true" を追加して、Arbiter ボリュームを作成します。

以下は例になります。

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"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.arbiter true"
  volumenameprefix: "test-vol"
allowVolumeExpansion: "true"

第11章カスタムボリュームオプションの設定

共有永続ボリュームを設定するには、Red Hat Openshift Container Storage Pod のいずれかで以下のコマンドを実行します。

静的プロビジョニングの場合：以下のコマンドを実行してボリュームオプションを設定します。

# gluster volume set VOLUME performance.open-behind off
# gluster volume set VOLUME performance.write-behind off
# gluster volume set VOLUME performance.stat-prefetch off
# gluster volume set VOLUME  performance.quick-read off
# gluster volume set VOLUME performance.strict-o-direct on
# gluster volume set VOLUME  performance.read-ahead off
# gluster volume set VOLUME performance.io-cache off
# gluster volume set VOLUME performance.readdir-ahead off

確認するには、以下のコマンドを実行します。

# gluster volume get VOLUME all  | grep <performance translator>

以下は例になります。

# gluster volume get VOLUME all  | egrep "performance.stat-prefetch | performance.write-behind | performance.open-behind | performance.quick-read | performance.strict-o-direct | performance.read-ahead | performance.io-cache | performance.readdir-ahead"

動的プロビジョニングの場合には、ボリュームオプションはストレージクラスファイルの「parameter」の下に記載できます。以下は例になります。

parameters:
  resturl: http://heketi-storage-glusterfs.router.default.svc.cluster.local
  restuser: admin
  secretName: heketi-storage-admin-secret
  secretNamespace: glusterfs
  volumeoptions: performance.stat-prefetch off performance.write-behind off performance.open-behind off performance.quick-read off performance.strict-o-direct on performance.read-ahead off performance.io-cache off performance.readdir-ahead off

ファイルストレージのストレージクラスの登録に関する詳細は、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 を参照してください。

ブロックストレージ用のストレージクラスの登録に関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#Block_dynamic_prov_vol を参照してください。

パート VI. 付録

付録A 任意のデプロイメント方法（cns-deploy を使用）

以下のセクションでは、cns-deploy を使用して Red Hat Openshift Container Storage をデプロイする任意の方法を説明します。

注記

CNS-deploy は非推奨となり、新規デプロイメントについて今後の Openshift Container Storage バージョンではサポートされません。

A.1. コンバージドモードの設定

コンバージドモード環境は、アプリケーションが共有ストレージと、コンピュートインスタンスとストレージインスタンスを同じハードウェアでスケジュールして実行するコンバージドインフラの柔軟性の両方を必要とするユースケースに対応しています。

A.1.1. ポートアクセスの設定

Red Hat Gluster Storage コンテナーをホストする各 OpenShift ノードで、/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 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
```
注記
- ポート 24010 と 3260 は、それぞれ gluster-blockd と iSCSI ターゲット用です。
- 49664 で始まるポート範囲は、ボリュームのブリックとの通信に GlusterFS で使用できるポートの範囲を定義します。上記の例では、許容されるブリックの合計数は 512 です。各ノードでホストできるブリックの最大数に基づいて、ポート範囲を設定します。
Red Hat Gluster Storage Server のポートの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html/administration_guide/chap-getting_started を参照してください。
- 以下のコマンドを実行して、iptables を再読み込みします。
```
# systemctl reload iptables
```
- 各ノードで以下のコマンドを実行して、iptables が更新されているかどうかを確認します。

# iptables -L

A.1.2. カーネルモジュールの有効化

cns-deploy ツールを実行する前に、dm_thin_pool、dm_multipath、および target_core_user モジュールが OpenShift Container Platform ノードにロードされていることを確認する必要があります。以下のコマンドを Gluster ノードでのみ実行して、モジュールが読み込まれているかどうかを確認します。

# lsmod | grep dm_thin_pool

# lsmod | grep dm_multipath

# lsmod | grep target_core_user

モジュールが読み込まれていない場合は、以下のコマンドを実行してモジュールを読み込みます。

# modprobe dm_thin_pool

# modprobe dm_multipath

# modprobe target_core_user

注記

これらの操作が再起動後も維持されるようにするには、以下のファイルを作成し、上記の内容でそれぞれの操作を更新します。

# cat /etc/modules-load.d/dm_thin_pool.conf
dm_thin_pool

# cat /etc/modules-load.d/dm_multipath.conf
dm_multipath

# cat /etc/modules-load.d/target_core_user.conf
target_core_user

A.1.3. サービスの起動と有効化

以下のコマンドを実行して、gluster Pod をホストするすべてのノードで rpcbind を有効にし、実行します。

# systemctl add-wants multi-user rpcbind.service
# systemctl enable rpcbind.service
# systemctl start rpcbind.service

以下のコマンドを実行して、rpcbind のステータスを確認します。

# systemctl status rpcbind

rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-08-30 21:24:21 IST; 1 day 13h ago
 Main PID: 9945 (rpcbind)
   CGroup: /system.slice/rpcbind.service
└─9945 /sbin/rpcbind -w

次のステップ: 「環境の設定」に進み、OpenShift で Red Hat Gluster Storage Container Converged の環境を準備します。

注記

cns-deploy を使用して実行した Red Hat Openshift Container Storage のインストールを削除するには、cns-deploy --abort コマンドを実行します。Gluster がコンテナー化されている場合は、-g オプションを使用します。

Pod が削除されると、すべての Gluster 状態がノードから削除される訳ではありません。そのため、Gluster Pod を実行しているすべてのノードで rm -rf /var/lib/heketi /etc/glusterfs /var/lib/glusterd /var/log/glusterfs コマンドを実行し、Heketi が消費したすべてのストレージデバイスに対して wipefs -a <device> を実行する必要もあります。これにより、各ノードの残りの Gluster 状態がすべて消去されます。デバイスの wipe コマンドを実行するには、管理者でなければなりません。

A.2. インデペンデントモードの設定

A.2.1. Red Hat Gluster Storage Server の Red Hat Enterprise Linux へのインストール (階層化インストール)

階層型インストールでは、Red Hat Enterprise Linux に Red Hat Gluster Storage がインストールされます。

重要

Red Hat Enterprise Linux 7 Server のベースインストールの実行
インデペンデントモードは、Red Hat Enterprise Linux 7 でのみサポートされます。
システムの Subscription Manager への登録
以下のコマンドを実行し、Red Hat Network のユーザー名およびパスワードを入力して、システムを Red Hat Network に登録します。
```
# subscription-manager register
```
利用可能なエンタイトルメントプールの特定
以下のコマンドを実行して、Red Hat Gluster Storage のインストールに必要なリポジトリーが含まれるエンタイトルメントプールを見つけます。
```
# subscription-manager list --available
```
システムへのエンタイトルメントプールのアタッチ
先の手順で特定したプール ID を使用して、Red Hat Enterprise Linux Server および Red Hat Gluster Storage のエンタイトルメントをシステムにアタッチします。以下のコマンドを実行してエンタイトルメントをアタッチします。
```
# subscription-manager attach --pool=[POOLID]
```
以下は例になります。
```
# subscription-manager attach --pool=8a85f9814999f69101499c05aa706e47
```
必要なチャンネルの有効化
Red Hat Enterprise Linux 7.7 での Red Hat Gluster Storage 3.5 の場合
以下のコマンドを実行して、Red Hat Gluster Storage のインストールに必要なリポジトリーを有効にします。
```
# subscription-manager repos --enable=rhel-7-server-rpms
# subscription-manager repos --enable=rh-gluster-3-for-rhel-7-server-rpms
```
チャンネルが有効であるかどうかの確認
以下のコマンドを実行して、チャンネルが有効であるかどうかを確認します。
```
# yum repolist
```
すべてのパッケージの更新
以下のコマンドを実行して、すべてのパッケージが最新の状態であることを確認します。
```
# yum update
```
カーネルバージョンの要件
インデペンデントモードでは、システムで kernel-3.10.0-862.14.4.el7.x86_64 バージョン以降を使用する必要があります。以下のコマンドを実行して、インストール済みの実行中のカーネルのバージョンを確認します。
```
# rpm -q kernel
kernel-3.10.0-862.14.4.el7.x86_64
```
```
# uname -r
3.10.0-862.14.4.el7.x86_64
```
重要
いずれかのカーネルパッケージを更新した場合は、以下のコマンドを実行してシステムを再起動します。
+
```
# shutdown -r now
```
Red Hat Gluster Storage のインストール
以下のコマンドを実行して Red Hat Gluster Storage をインストールします。
```
# yum install redhat-storage-server
```
1. gluster-block を有効にするには、以下のコマンドを実行します。

# yum install gluster-block

再起動
システムを再起動します。

A.2.2. ポートアクセスの設定

このセクションでは、インデペンデントモードで開く必要のあるポートに関する情報を提供します。

以下のコマンドを実行して、すべての Red Hat Gluster Storage ノードで、ランタイムおよび永続設定の両方で必要なポートを開きます。

# firewall-cmd --zone=zone_name --add-port=24010/tcp --add-port=3260/tcp --add-port=111/tcp --add-port=22/tcp --add-port=24007/tcp --add-port=49152-49664/tcp
# firewall-cmd --zone=zone_name --add-port=24010/tcp --add-port=3260/tcp --add-port=111/tcp --add-port=22/tcp --add-port=24007/tcp --add-port=49152-49664/tcp --permanent

注記

ポート 24010 と 3260 は、それぞれ gluster-blockd と iSCSI ターゲット用です。
49664 で始まるポート範囲は、ボリュームのブリックとの通信に GlusterFS で使用できるポートの範囲を定義します。上記の例では、許容されるブリックの合計数は 512 です。各ノードでホストできるブリックの最大数に基づいて、ポート範囲を設定します。

A.2.3. カーネルモジュールの有効化

以下のコマンドを実行して、カーネルモジュールを有効にします。

dm_thin_pool モジュールおよび target_core_user モジュールが、Red Hat Gluster Storage ノードに読み込まれていることを確認する必要があります。
```
# modprobe target_core_user
```
```
# modprobe dm_thin_pool
```
以下のコマンドを実行して、モジュールが読み込まれているかどうかを確認します。
```
# lsmod | grep dm_thin_pool
```
```
# lsmod | grep target_core_user
```
注記
これらの操作が再起動後も維持されるようにするには、以下のファイルを作成し、各ファイルを更新します。
```
# cat /etc/modules-load.d/dm_thin_pool.conf
dm_thin_pool
```
```
# cat /etc/modules-load.d/target_core_user.conf
target_core_user
```
dm_multipath モジュールがすべての OpenShift Container Platform ノードに読み込まれることを確認する必要があります。
```
# modprobe dm_multipath
```
以下のコマンドを実行して、モジュールが読み込まれているかどうかを確認します。
```
# lsmod | grep dm_multipath
```
注記
これらの操作が再起動後も維持されるようにするには、以下のファイルを作成し、上記の内容で更新します。
```
# cat /etc/modules-load.d/dm_multipath.conf
dm_multipath
```

A.2.4. サービスの起動と有効化

以下のコマンドを実行して、glusterd および gluster-blockd を起動します。

# systemctl start sshd

# systemctl enable sshd

# systemctl start glusterd

# systemctl enable glusterd

# systemctl start gluster-blockd

# systemctl enable gluster-blockd

次のステップ: 「環境の設定」に進み、OpenShift で Red Hat Gluster Storage Container Converged の環境を準備します。

A.3. 環境の設定

本章では、Red Hat Openshift Container Platform の環境設定に関する詳細について説明します。

A.3.1. Red Hat OpenShift Container Platform クラスターの準備

以下の手順を実行して、Red Hat OpenShift Container Platform クラスターを準備します。

マスターまたはクライアントで、以下のコマンドを実行し、クラスター管理者としてログインします。

# oc login

以下は例になります。

# oc login
Authentication required for https://dhcp46-24.lab.eng.blr.redhat.com:8443 (openshift)
Username: test
Password:
Login successful.

You have access to the following projects and can switch between them with 'oc project <project_name>':

  * default
    kube-system
    logging
    management-infra
    openshift
    openshift-infra


Using project "default".

マスターまたはクライアントで以下のコマンドを実行し、コンテナー化されたすべての Red Hat Gluster Storage サービスが含まれるプロジェクトを作成します。
```
# oc new-project <project_name>
```
以下は例になります。
```
# oc new-project storage-project

Now using project "storage-project" on server "https://master.example.com:8443"
```
プロジェクトが作成されたら、マスターノードで以下のコマンドを実行し、Red Hat Gluster Storage コンテナーが特権モードでしか実行できないように、特権付きコンテナーのデプロイメントができるようにします。
```
# oc  adm policy add-scc-to-user privileged -z default
```
マスターで以下の手順を実行し、ルーターを設定します。
注記
ルーターがすでに存在する場合は、手順 5 に進みます。ルーターがすでにデプロイされているかどうかを確認するには、以下のコマンドを実行します。
```
# oc get dc --all-namespaces
```
すべての namespace のすべてのルーターを一覧表示するには、以下のコマンドを実行します。
```
# oc get dc --all-namespaces --selector=router=router
NAME                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
glusterblock-storage-provisioner-dc   1          1         0         config
heketi-storage                        4          1         1         config
```
1. 以下のコマンドを実行して、ルーターのデプロイメントを有効にします。
```
# oc adm policy add-scc-to-user privileged -z router
```
2. 以下のコマンドを実行して、ルーターをデプロイします。
```
# oc adm router storage-project-router --replicas=1
```
3. /etc/origin/master/master-config.yaml にある config.yaml ファイルのサブドメイン名を編集します。
  以下は例になります。
```
subdomain: "cloudapps.mystorage.com"
```
  詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/configuring_clusters/#customizing-the-default-routing-subdomain を参照してください。
4. OpenShift Container Platform 3.7 および 3.9 の場合は、以下のコマンドを実行してサービスを再起動します。
```
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
```
  注記
  ルーターの設定に失敗した場合は、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-Port_Fwding の説明に従って、ポート転送方法を使用します。
ルーター設定の詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html/configuring_clusters/setting-up-a-router を参照してください。

以下のコマンドを実行して、ルーターが実行中かどうかを確認します。

# oc get dc <_router_name_>

以下は例になります。

# oc get dc storage-project-router
NAME                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
glusterblock-storage-provisioner-dc   1          1         0         config
heketi-storage                        4          1         1         config

注記

ルーターが起動するまで、*/etc/dnsmasq.conf * ファイルを編集しないでください。

ルーターの実行後に、OpenShift クラスターのサービスにアクセスするように、クライアントを設定する必要があります。クライアントで以下の手順を実行し、DNS を設定します。
1. 以下のコマンドを実行して、ルーターの IP アドレスを検索します。
```
# oc get pods -o wide --all-namespaces | grep router
storage-project storage-project-router-1-cm874        1/1       Running   119d       10.70.43.132   dhcp43-132.lab.eng.blr.redhat.com
```
2. /etc/dnsmasq.conf ファイルを編集し、以下の行をファイルに追加します。
```
address=/.cloudapps.mystorage.com/<Router_IP_Address>
```
  Router_IP_Address は、ルーターが実行されているノードの IP アドレスです。
3. 以下のコマンドを実行して dnsmasq サービスを再起動します。
```
# systemctl restart dnsmasq
```
4. /etc/resolv.conf を編集し、以下の行を追加します。
```
nameserver 127.0.0.1
```

DNS の設定に関する詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html/installing_clusters/install-config-install-prerequisites#prereq-dns を参照してください。

A.3.2. コンテナー化された Red Hat Gluster Storage Solutions のデプロイ

以下のセクションでは、コンバージドモード Pod、インディペンデントモード Pod、および *cns-deploy * ツールの使用について説明します。

注記

OpenShift Container Platform インフラストラクチャーのワークロード（レジストリー、ロギングおよびメトリクス）およびアプリケーション Pod ストレージには、別のクラスターを使用することが推奨されます。したがって、ノードが6 つ以上ある場合は、最低でも 3 つのノードで複数のクラスターを作成します。インフラストラクチャークラスターは default プロジェクト namespace に所属する必要があります。
Red Hat Openshift Container Storage 設定で暗号化を有効にする必要がある場合は、以下の手順に進む前に 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-Enabling_Encryption を参照してください。

まず、Red Hat Gluster Storage ノードのトポロジーと、アタッチされたストレージデバイスのトポロジーを記述した heketi のトポロジーファイルを指定する必要があります。サンプルのフォーマットされたトポロジーファイル(topology-sample.json)は、 'heketi-client' パッケージで /usr/share/heketi/ ディレクトリーにインストールされます。
```
{
    "clusters": [
        {
            "nodes": [
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "node1.example.com"
                            ],
                            "storage": [
                                "192.168.68.3"
                            ]
                        },
                        "zone": 1
                    },
                    "devices": [
                        "/dev/sdb",
                        "/dev/sdc",
                        "/dev/sdd",
                        "/dev/sde",
                        "/dev/sdf",
                        "/dev/sdg",
                        "/dev/sdh",
                        "/dev/sdi"
                    ]
                },
                {
                    "node": {
                        "hostnames": {
                            "manage": [
                                "node2.example.com"
                            ],
                            "storage": [
                                "192.168.68.2"
                            ]
                        },
                        "zone": 2
                    },
                    "devices": [
                        "/dev/sdb",
                        "/dev/sdc",
                        "/dev/sdd",
                        "/dev/sde",
                        "/dev/sdf",
                        "/dev/sdg",
                        "/dev/sdh",
                        "/dev/sdi"
                    ]
                },
.......
.......
```
** clusters: はクラスターの配列になります。
+ 配列上の各要素は、以下のようにクラスターを記述するマップです。
- nodes: Red Hat Gluster Storage コンテナーをホストする OpenShift ノードの配列です。
  配列の各要素は、以下のようにノードを記述するマップです。
- node: 以下の要素のマップです。
  - zone: この値は、ノードが属するゾーン番号を表します。ゾーン番号は、異なるゾーンにブリックのレプリカを配置して、heketi がブリックの最適な位置を選択するために使用します。したがって、ゾーン番号は障害ドメインと似ています。
  - hostnames: 管理およびストレージアドレスを一覧表示するマップです。
    manage: ノードとの通信に Heketi が使用するホスト名/IP アドレスです。
    storage: ノードと通信するために他の OpenShift ノードによって使用される IP アドレスです。ストレージデータトラフィックは、この IP に割り当てられたインターフェースを使用します。OpenShift環境では、Heketiはこれもエンドポイントと見なすため、これはホスト名ではなくIPアドレスである必要があります。
- devices: 追加する各ディスクの名前

注記

トポロジーファイルをデフォルトの場所からお使いの場所にコピーしてから、これを編集します。

# cp /usr/share/heketi/topology-sample.json /<_Path_>/topology.json

node.hostnames.manage セクションの下にある Red Hat Gluster Storage Pod ホスト名と、node.hostnames.storage セクションの下にある Red Hat Gluster Storage Pod のホスト名に基づいて、IP アドレスを指定してトポロジーファイルを編集します。/usr/share/heketi/topology-sample.json ファイルは、それぞれドライブが 8 個含まれるノード 4 つだけを設定して、簡素化します。

重要

heketi は、そのデータベースを Red Hat Gluster Storage ボリュームに保存します。ボリュームがダウンした場合に、信頼された分散型ストレージプールが提供するボリュームが利用できないので、Heketi サービスは応答しません。この問題を解決するには、Heketi ボリュームを含む、信頼されたストレージプールを再起動します。

A.3.3. コンバージドモードのデプロイ

以下のコマンドを実行して、コンバージドモードをデプロイします。

クライアントで以下のコマンドを実行し、heketi および Red Hat Gluster Storage Pod をデプロイします。

# cns-deploy -v -n <namespace> -g --admin-key <admin-key> --user-key <user-key> topology.json

注記

Container-Native Storage 3.6 以降では、Red Hat Openshift Container Storage での S3 と互換性のあるオブジェクトストアのサポートは、テクノロジープレビュー機能となっています。Red Hat Openshift Container Storage に S3 と互換性のあるオブジェクトストアをデプロイするには、以下のサブステップ (i) を参照してください。
上記のコマンドでは、admin-key の値は、heketi 管理ユーザーのシークレット文字列です。heketi 管理者は、すべての API およびコマンドにアクセスできます。デフォルトでは、シークレットは使用されません。
cns-deploy の BLOCK_HOST_SIZE パラメーターは、gluster-block ボリュームをホストする、自動作成された Red Hat Gluster Storage ボリュームのサイズ（GB 単位）を制御します。このデフォルト設定では、より多くの領域が必要な場合に、サイズが 500GB のブロックホスティングボリュームを動的に作成します。この値を変更する場合は、cns-deploy で --block-host を使用します。以下は例になります。
```
# cns-deploy -v -n storage-project -g --admin-key secret --user-key mysecret --block-host 1000 topology.json
```

以下は例になります。

# cns-deploy -v -n storage-project -g --admin-key secret --user-key mysecret topology.json

Welcome to the deployment tool for GlusterFS on Kubernetes and OpenShift.

Before getting started, this script has some requirements of the execution
environment and of the container platform that you should verify.

The client machine that will run this script must have:
* Administrative access to an existing Kubernetes or OpenShift cluster
* Access to a python interpreter 'python'

Each of the nodes that will host GlusterFS must also have appropriate firewall
rules for the required GlusterFS ports:
* 111 - rpcbind (for glusterblock)
* 2222 - sshd (if running GlusterFS in a pod)
* 3260 - iSCSI targets (for glusterblock)
* 24010 - glusterblockd
* 24007 - GlusterFS Management
* 24008 - GlusterFS RDMA
* 49152 to 49251 - Each brick for every volume on the host requires its own
port. For every new brick, one new port will be used starting at 49152. We
recommend a default range of 49152-49251 on each host, though you can adjust
this to fit your needs.

The following kernel modules must be loaded:
* dm_snapshot
* dm_mirror
* dm_thin_pool
* dm_multipath
* target_core_user

For systems with SELinux, the following settings need to be considered:
* virt_sandbox_use_fusefs should be enabled on each node to allow writing to
remote GlusterFS volumes

In addition, for an OpenShift deployment you must:
* Have 'cluster_admin' role on the administrative account doing the deployment
* Add the 'default' and 'router' Service Accounts to the 'privileged' SCC
* Have a router deployed that is configured to allow apps to access services
running in the cluster

Do you wish to proceed with deployment?

[Y]es, [N]o? [Default: Y]: Y
Using OpenShift CLI.
Using namespace "storage-project".
Checking for pre-existing resources...
GlusterFS pods ... not found.
deploy-heketi pod ... not found.
heketi pod ... not found.
glusterblock-provisioner pod ... not found.
gluster-s3 pod ... not found.
Creating initial resources ... template "deploy-heketi" created
serviceaccount "heketi-service-account" created
template "heketi" created
template "glusterfs" created
role "edit" added: "system:serviceaccount:storage-project:heketi-service-account"
OK
node "ip-172-18-5-29.ec2.internal" labeled
node "ip-172-18-8-205.ec2.internal" labeled
node "ip-172-18-6-100.ec2.internal" labeled
daemonset "glusterfs" created
Waiting for GlusterFS pods to start ... OK
secret "heketi-config-secret" created
secret "heketi-config-secret" labeled
service "deploy-heketi" created
route "deploy-heketi" created
deploymentconfig "deploy-heketi" created
Waiting for deploy-heketi pod to start ... OK
Creating cluster ... ID: 30cd12e60f860fce21e7e7457d07db36
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node ip-172-18-5-29.ec2.internal ... ID: 4077242c76e5f477a27c5c47247cb348
Adding device /dev/xvdc ... OK
Creating node ip-172-18-8-205.ec2.internal ... ID: dda0e7d568d7b2f76a7e7491cfc26dd3
Adding device /dev/xvdc ... OK
Creating node ip-172-18-6-100.ec2.internal ... ID: 30a1795ca515c85dca32b09be7a68733
Adding device /dev/xvdc ... OK
heketi topology loaded.
Saving /tmp/heketi-storage.json
secret "heketi-storage-secret" created
endpoints "heketi-storage-endpoints" created
service "heketi-storage-endpoints" created
job "heketi-storage-copy-job" created
service "heketi-storage-endpoints" labeled
deploymentconfig "deploy-heketi" deleted
route "deploy-heketi" deleted
service "deploy-heketi" deleted
job "heketi-storage-copy-job" deleted
pod "deploy-heketi-1-frjpt" deleted
secret "heketi-storage-secret" deleted
template "deploy-heketi" deleted
service "heketi" created
route "heketi" created
deploymentconfig "heketi" created
Waiting for heketi pod to start ... OK

heketi is now running and accessible via http://heketi-storage-project.cloudapps.mystorage.com . To run
administrative commands you can install 'heketi-cli' and use it as follows:

# heketi-cli -s http://heketi-storage-project.cloudapps.mystorage.com --user admin --secret '<ADMIN_KEY>' cluster list

You can find it at https://github.com/heketi/heketi/releases . Alternatively,
use it from within the heketi pod:

# /bin/oc -n storage-project exec -it <HEKETI_POD> -- heketi-cli -s http://localhost:8080 --user admin --secret '<ADMIN_KEY>' cluster list

For dynamic provisioning, create a StorageClass similar to this:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://heketi-storage-project.cloudapps.mystorage.com"

Ready to create and provide GlusterFS volumes.
clusterrole "glusterblock-provisioner-runner" created
serviceaccount "glusterblock-provisioner" created
clusterrolebinding "glusterblock-provisioner" created
deploymentconfig "glusterblock-provisioner-dc" created
Waiting for glusterblock-provisioner pod to start ... OK
Ready to create and provide Gluster block volumes.

Deployment complete!

注記

For more information on the cns-deploy commands, refer to the man page of  cns-deploy.

# cns-deploy --help

S3 と互換性のあるオブジェクトストアを Heketi および Red Hat Gluster Storage Pod とともにデプロイするには、以下のコマンドを実行します。

#  cns-deploy /opt/topology.json --deploy-gluster  --namespace <namespace> --yes --admin-key <admin-key>  --user-key <user-key> --log-file=<path/to/logfile> --object-account <object account name> --object-user <object user name>  --object-password <object user password> --verbose

object-account、object-user、および object-password は、gluster-s3 コンテナーのデプロイに必要な認証情報です。これらのいずれかがない場合は、gluster-s3 コンテナーのデプロイメントが省略されます。

object-sc および object-capacity はオプションのパラメーターです。object-sc は、オブジェクトストアをバックアップする Red Hat Gluster Storage ボリュームの作成用の、既存の Storage Class を指定するために使用され、object-capacityは、オブジェクトデータを格納する Red Hat Gluster Storage ボリュームの総容量です。

以下は例になります。

#  cns-deploy /opt/topology.json --deploy-gluster --namespace storage-project --yes --admin-key secret --user-key mysecret --log-file=/var/log/cns-deploy/444-cns-deploy.log --object-account testvolume --object-user adminuser --object-password itsmine --verbose
Using OpenShift CLI.

Checking status of namespace matching 'storage-project':
storage-project   Active    56m
Using namespace "storage-project".
Checking for pre-existing resources...
  GlusterFS pods ...
Checking status of pods matching '--selector=glusterfs=pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=pod'.
not found.
  deploy-heketi pod ...
Checking status of pods matching '--selector=deploy-heketi=pod':
No resources found.
Timed out waiting for pods matching '--selector=deploy-heketi=pod'.
not found.
  heketi pod ...
Checking status of pods matching '--selector=heketi=pod':
No resources found.
Timed out waiting for pods matching '--selector=heketi=pod'.
not found.
  glusterblock-provisioner pod ...
Checking status of pods matching '--selector=glusterfs=block-provisioner-pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=block-provisioner-pod'.
not found.
  gluster-s3 pod ...
Checking status of pods matching '--selector=glusterfs=s3-pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=s3-pod'.
not found.
Creating initial resources ... /usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/deploy-heketi-template.yaml 2>&1
template "deploy-heketi" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/heketi-service-account.yaml 2>&1
serviceaccount "heketi-service-account" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/heketi-template.yaml 2>&1
template "heketi" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/glusterfs-template.yaml 2>&1
template "glusterfs" created
/usr/bin/oc -n storage-project policy add-role-to-user edit system:serviceaccount:storage-project:heketi-service-account 2>&1
role "edit" added: "system:serviceaccount:storage-project:heketi-service-account"
/usr/bin/oc -n storage-project adm policy add-scc-to-user privileged -z heketi-service-account
OK
Marking 'dhcp46-122.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-122.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-122.lab.eng.blr.redhat.com" labeled
Marking 'dhcp46-9.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-9.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-9.lab.eng.blr.redhat.com" labeled
Marking 'dhcp46-134.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-134.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-134.lab.eng.blr.redhat.com" labeled
Deploying GlusterFS pods.
/usr/bin/oc -n storage-project process -p NODE_LABEL=glusterfs glusterfs | /usr/bin/oc -n storage-project create -f - 2>&1
daemonset "glusterfs" created
Waiting for GlusterFS pods to start ...
Checking status of pods matching '--selector=glusterfs=pod':
glusterfs-6fj2v   1/1       Running   0         52s
glusterfs-ck40f   1/1       Running   0         52s
glusterfs-kbtz4   1/1       Running   0         52s
OK
/usr/bin/oc -n storage-project create secret generic heketi-config-secret --from-file=private_key=/dev/null --from-file=./heketi.json --from-file=topology.json=/opt/topology.json
secret "heketi-config-secret" created
/usr/bin/oc -n storage-project label --overwrite secret heketi-config-secret glusterfs=heketi-config-secret heketi=config-secret
secret "heketi-config-secret" labeled
/usr/bin/oc -n storage-project process -p HEKETI_EXECUTOR=kubernetes -p HEKETI_FSTAB=/var/lib/heketi/fstab -p HEKETI_ADMIN_KEY= -p HEKETI_USER_KEY= deploy-heketi | /usr/bin/oc -n storage-project create -f - 2>&1
service "deploy-heketi" created
route "deploy-heketi" created
deploymentconfig "deploy-heketi" created
Waiting for deploy-heketi pod to start ...
Checking status of pods matching '--selector=deploy-heketi=pod':
deploy-heketi-1-hf9rn   1/1       Running   0         2m
OK
Determining heketi service URL ... OK
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- heketi-cli -s http://localhost:8080 --user admin --secret '' topology load --json=/etc/heketi/topology.json 2>&1
Creating cluster ... ID: 252509038eb8568162ec5920c12bc243
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node dhcp46-122.lab.eng.blr.redhat.com ... ID: 73ad287ae1ef231f8a0db46422367c9a
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp46-9.lab.eng.blr.redhat.com ... ID: 0da1b20daaad2d5c57dbfc4f6ab78001
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp46-134.lab.eng.blr.redhat.com ... ID: 4b3b62fc0efd298dedbcdacf0b498e65
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
heketi topology loaded.
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- heketi-cli -s http://localhost:8080 --user admin --secret '' setup-openshift-heketi-storage --listfile=/tmp/heketi-storage.json --image rhgs3/rhgs-volmanager-rhel7:3.3.0-17 2>&1
Saving /tmp/heketi-storage.json
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- cat /tmp/heketi-storage.json | /usr/bin/oc -n storage-project create -f - 2>&1
secret "heketi-storage-secret" created
endpoints "heketi-storage-endpoints" created
service "heketi-storage-endpoints" created
job "heketi-storage-copy-job" created

Checking status of pods matching '--selector=job-name=heketi-storage-copy-job':
heketi-storage-copy-job-87v6n   0/1       Completed   0         7s
/usr/bin/oc -n storage-project label --overwrite svc heketi-storage-endpoints glusterfs=heketi-storage-endpoints heketi=storage-endpoints
service "heketi-storage-endpoints" labeled
/usr/bin/oc -n storage-project delete all,service,jobs,deployment,secret --selector="deploy-heketi" 2>&1
deploymentconfig "deploy-heketi" deleted
route "deploy-heketi" deleted
service "deploy-heketi" deleted
job "heketi-storage-copy-job" deleted
pod "deploy-heketi-1-hf9rn" deleted
secret "heketi-storage-secret" deleted
/usr/bin/oc -n storage-project delete dc,route,template --selector="deploy-heketi" 2>&1
template "deploy-heketi" deleted
/usr/bin/oc -n storage-project process -p HEKETI_EXECUTOR=kubernetes -p HEKETI_FSTAB=/var/lib/heketi/fstab -p HEKETI_ADMIN_KEY= -p HEKETI_USER_KEY= heketi | /usr/bin/oc -n storage-project create -f - 2>&1
service "heketi" created
route "heketi" created
deploymentconfig "heketi" created
Waiting for heketi pod to start ...
Checking status of pods matching '--selector=heketi=pod':
heketi-1-zzblp   1/1       Running   0         31s
OK
Determining heketi service URL ... OK

heketi is now running and accessible via http://heketi-storage-project.cloudapps.mystorage.com . To run
administrative commands you can install 'heketi-cli' and use it as follows:

  # heketi-cli -s http://heketi-storage-project.cloudapps.mystorage.com --user admin --secret '<ADMIN_KEY>' cluster list

You can find it at https://github.com/heketi/heketi/releases . Alternatively,
use it from within the heketi pod:

  # /usr/bin/oc -n storage-project exec -it <HEKETI_POD> -- heketi-cli -s http://localhost:8080 --user admin --secret '<ADMIN_KEY>' cluster list

For dynamic provisioning, create a StorageClass similar to this:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://heketi-storage-project.cloudapps.mystorage.com"

Ready to create and provide GlusterFS volumes.
sed -e 's/\${NAMESPACE}/storage-project/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
clusterrole "glusterblock-provisioner-runner" created
serviceaccount "glusterblock-provisioner" created
clusterrolebinding "glusterblock-provisioner" created
deploymentconfig "glusterblock-provisioner-dc" created
Waiting for glusterblock-provisioner pod to start ...
Checking status of pods matching '--selector=glusterfs=block-provisioner-pod':
glusterblock-provisioner-dc-1-xm6bv   1/1       Running   0         6s
OK
Ready to create and provide Gluster block volumes.
/usr/bin/oc -n storage-project create secret generic heketi-storage-project-admin-secret --from-literal=key= --type=kubernetes.io/glusterfs
secret "heketi-storage-project-admin-secret" created
/usr/bin/oc -n storage-project label --overwrite secret heketi-storage-project-admin-secret glusterfs=s3-heketi-storage-project-admin-secret gluster-s3=heketi-storage-project-admin-secret
secret "heketi-storage-project-admin-secret" labeled
sed -e 's/\${STORAGE_CLASS}/glusterfs-for-s3/' -e 's/\${HEKETI_URL}/heketi-storage-project.cloudapps.mystorage.com/' -e 's/\${NAMESPACE}/storage-project/' /usr/share/heketi/templates/gluster-s3-storageclass.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
storageclass "glusterfs-for-s3" created
sed -e 's/\${STORAGE_CLASS}/glusterfs-for-s3/' -e 's/\${VOLUME_CAPACITY}/2Gi/' /usr/share/heketi/templates/gluster-s3-pvcs.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
persistentvolumeclaim "gluster-s3-claim" created
persistentvolumeclaim "gluster-s3-meta-claim" created

Checking status of persistentvolumeclaims matching '--selector=glusterfs in (s3-pvc, s3-meta-pvc)':
gluster-s3-claim        Bound     pvc-35b6c1f0-9c65-11e7-9c8c-005056b3ded1   2Gi       RWX       glusterfs-for-s3   18s
gluster-s3-meta-claim   Bound     pvc-35b86e7a-9c65-11e7-9c8c-005056b3ded1   1Gi       RWX       glusterfs-for-s3   18s
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/gluster-s3-template.yaml 2>&1
template "gluster-s3" created
/usr/bin/oc -n storage-project process -p S3_ACCOUNT=testvolume -p S3_USER=adminuser -p S3_PASSWORD=itsmine gluster-s3 | /usr/bin/oc -n storage-project create -f - 2>&1
service "gluster-s3-service" created
route "gluster-s3-route" created
deploymentconfig "gluster-s3-dc" created
Waiting for gluster-s3 pod to start ...
Checking status of pods matching '--selector=glusterfs=s3-pod':
gluster-s3-dc-1-x3x4q   1/1       Running   0         6s
OK
Ready to create and provide Gluster object volumes.

Deployment complete!

以下のコマンドを実行して、クライアントがコンテナーと通信できるようにします。
```
# export  HEKETI_CLI_SERVER=http://heketi-<project_name>.<sub_domain_name>
```
以下は例になります。
```
# export  HEKETI_CLI_SERVER=http://heketi-storage-project.cloudapps.mystorage.com
```
トポロジーで Heketi が読み込まれているかどうかを確認するには、以下のコマンドを実行します。
```
# heketi-cli topology info
```

注記

The cns-deploy tool does not support scaling up of the cluster. To manually scale-up the cluster, see link: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-Managing_Clusters[]

次のステップ: インデペンデントモード 3.11 をインストールする場合は、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-Updating_Registry に進みます。

A.3.3.1. インデペンデントモードのデプロイ

以下のコマンドを実行して、Red Hat Openshift Container Storage をインデペンデントモードでデプロイします。

パスワードなしの SSH を Red Hat Gluster Storage ノードすべてに設定するには、Red Hat Gluster Storage ノードごとにクライアントで以下のコマンドを実行します。
```
# ssh-copy-id -i /root/.ssh/id_rsa root@<hostname>
```

クライアントで以下のコマンドを実行し、heketi Pod をデプロイし、Red Hat Gluster Storage ノードのクラスターを作成します。

# cns-deploy -v -n <namespace> -g --admin-key <admin-key> --user-key <user-key> topology.json

注記

S3 と互換性のあるオブジェクトストアのサポートは、テクノロジープレビューです。S3 と互換性のあるオブジェクトストアをデプロイするには、以下のサブステップ (i) を参照してください。
上記のコマンドでは、admin-key の値は、heketi 管理ユーザーのシークレット文字列です。heketi 管理者は、すべての API およびコマンドにアクセスできます。デフォルトでは、シークレットは使用されません。
cns-deploy の BLOCK_HOST_SIZE パラメーターは、gluster-block ボリュームをホストする、自動作成された Red Hat Gluster Storage ボリュームのサイズ（GB 単位）を制御します。このデフォルト設定では、より多くの領域が必要な場合に、サイズが 500GB のブロックホスティングボリュームを動的に作成します。この値を変更する場合は、cns-deploy で --block-host を使用します。以下は例になります。
```
# cns-deploy -v -n storage-project -g --admin-key secret --user-key mysecret --block-host 1000 topology.json
```

以下は例になります。

# cns-deploy -v -n storage-project -g --admin-key secret -s /root/.ssh/id_rsa --user-key mysecret topology.json
Welcome to the deployment tool for GlusterFS on Kubernetes and OpenShift.

Before getting started, this script has some requirements of the execution
environment and of the container platform that you should verify.

The client machine that will run this script must have:
* Administrative access to an existing Kubernetes or OpenShift cluster
* Access to a python interpreter 'python'

Each of the nodes that will host GlusterFS must also have appropriate firewall
rules for the required GlusterFS ports:
* 2222 - sshd (if running GlusterFS in a pod)
* 24007 - GlusterFS Management
* 24008 - GlusterFS RDMA
* 49152 to 49251 - Each brick for every volume on the host requires its own
port. For every new brick, one new port will be used starting at 49152. We
recommend a default range of 49152-49251 on each host, though you can adjust
this to fit your needs.

The following kernel modules must be loaded:
* dm_snapshot
* dm_mirror
* dm_thin_pool

For systems with SELinux, the following settings need to be considered:
* virt_sandbox_use_fusefs should be enabled on each node to allow writing to
remote GlusterFS volumes

Do you wish to proceed with deployment?

[Y]es, [N]o? [Default: Y]: y
Using OpenShift CLI.
Using namespace "storage-project".
Checking for pre-existing resources...
GlusterFS pods ... not found.
deploy-heketi pod ... not found.
heketi pod ... not found.
Creating initial resources ... template "deploy-heketi" created
serviceaccount "heketi-service-account" created
template "heketi" created
role "edit" added: "system:serviceaccount:storage-project:heketi-service-account"
OK
secret "heketi-config-secret" created
secret "heketi-config-secret" labeled
service "deploy-heketi" created
route "deploy-heketi" created
deploymentconfig "deploy-heketi" created
Waiting for deploy-heketi pod to start ... OK
Creating cluster ... ID: 60bf06636eb4eb81d4e9be4b04cfce92
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node dhcp47-104.lab.eng.blr.redhat.com ... ID: eadc66f9d03563bcfc3db3fe636c34be
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp47-83.lab.eng.blr.redhat.com ... ID: 178684b0a0425f51b8f1a032982ffe4d
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp46-152.lab.eng.blr.redhat.com ... ID: 08cd7034ef7ac66499dc040d93cf4a93
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
heketi topology loaded.
Saving /tmp/heketi-storage.json
secret "heketi-storage-secret" created
endpoints "heketi-storage-endpoints" created
service "heketi-storage-endpoints" created
job "heketi-storage-copy-job" created
service "heketi-storage-endpoints" labeled
deploymentconfig "deploy-heketi" deleted
route "deploy-heketi" deleted
service "deploy-heketi" deleted
job "heketi-storage-copy-job" deleted
pod "deploy-heketi-1-30c06" deleted
secret "heketi-storage-secret" deleted
template "deploy-heketi" deleted
service "heketi" created
route "heketi" created
deploymentconfig "heketi" created
Waiting for heketi pod to start ... OK

heketi is now running and accessible via http://heketi-storage-project.cloudapps.mystorage.com . To run
administrative commands you can install 'heketi-cli' and use it as follows:

# heketi-cli -s http://heketi-storage-project.cloudapps.mystorage.com --user admin --secret '<ADMIN_KEY>' cluster list

You can find it at https://github.com/heketi/heketi/releases . Alternatively,
use it from within the heketi pod:

# /usr/bin/oc -n storage-project exec -it <HEKETI_POD> -- heketi-cli -s http://localhost:8080 --user admin --secret '<ADMIN_KEY>' cluster list

For dynamic provisioning, create a StorageClass similar to this:

Deployment complete!

注記

For more information on the cns-deploy commands, refer to the man page of the cns-deploy.

# cns-deploy --help

S3 と互換性のあるオブジェクトストアを Heketi および Red Hat Gluster Storage Pod とともにデプロイするには、以下のコマンドを実行します。

#  cns-deploy /opt/topology.json --deploy-gluster --namespace <namespace> --admin-key <admin-key> --user-key <user-key> --yes --log-file=<path/to/logfile> --object-account <object account name> --object-user <object user name>  --object-password <object user password> --verbose

以下は例になります。

#  cns-deploy /opt/topology.json --deploy-gluster  --namespace storage-project --admin-key secret --user-key mysecret --yes --log-file=/var/log/cns-deploy/444-cns-deploy.log --object-account testvolume --object-user adminuser --object-password itsmine --verbose
Using OpenShift CLI.

Checking status of namespace matching 'storage-project':
storage-project   Active    56m
Using namespace "storage-project".
Checking for pre-existing resources...
  GlusterFS pods ...
Checking status of pods matching '--selector=glusterfs=pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=pod'.
not found.
  deploy-heketi pod ...
Checking status of pods matching '--selector=deploy-heketi=pod':
No resources found.
Timed out waiting for pods matching '--selector=deploy-heketi=pod'.
not found.
  heketi pod ...
Checking status of pods matching '--selector=heketi=pod':
No resources found.
Timed out waiting for pods matching '--selector=heketi=pod'.
not found.
  glusterblock-provisioner pod ...
Checking status of pods matching '--selector=glusterfs=block-provisioner-pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=block-provisioner-pod'.
not found.
  gluster-s3 pod ...
Checking status of pods matching '--selector=glusterfs=s3-pod':
No resources found.
Timed out waiting for pods matching '--selector=glusterfs=s3-pod'.
not found.
Creating initial resources ... /usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/deploy-heketi-template.yaml 2>&1
template "deploy-heketi" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/heketi-service-account.yaml 2>&1
serviceaccount "heketi-service-account" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/heketi-template.yaml 2>&1
template "heketi" created
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/glusterfs-template.yaml 2>&1
template "glusterfs" created
/usr/bin/oc -n storage-project policy add-role-to-user edit system:serviceaccount:storage-project:heketi-service-account 2>&1
role "edit" added: "system:serviceaccount:storage-project:heketi-service-account"
/usr/bin/oc -n storage-project adm policy add-scc-to-user privileged -z heketi-service-account
OK
Marking 'dhcp46-122.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-122.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-122.lab.eng.blr.redhat.com" labeled
Marking 'dhcp46-9.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-9.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-9.lab.eng.blr.redhat.com" labeled
Marking 'dhcp46-134.lab.eng.blr.redhat.com' as a GlusterFS node.
/usr/bin/oc -n storage-project label nodes dhcp46-134.lab.eng.blr.redhat.com storagenode=glusterfs 2>&1
node "dhcp46-134.lab.eng.blr.redhat.com" labeled
Deploying GlusterFS pods.
/usr/bin/oc -n storage-project process -p NODE_LABEL=glusterfs glusterfs | /usr/bin/oc -n storage-project create -f - 2>&1
daemonset "glusterfs" created
Waiting for GlusterFS pods to start ...
Checking status of pods matching '--selector=glusterfs=pod':
glusterfs-6fj2v   1/1       Running   0         52s
glusterfs-ck40f   1/1       Running   0         52s
glusterfs-kbtz4   1/1       Running   0         52s
OK
/usr/bin/oc -n storage-project create secret generic heketi-config-secret --from-file=private_key=/dev/null --from-file=./heketi.json --from-file=topology.json=/opt/topology.json
secret "heketi-config-secret" created
/usr/bin/oc -n storage-project label --overwrite secret heketi-config-secret glusterfs=heketi-config-secret heketi=config-secret
secret "heketi-config-secret" labeled
/usr/bin/oc -n storage-project process -p HEKETI_EXECUTOR=kubernetes -p HEKETI_FSTAB=/var/lib/heketi/fstab -p HEKETI_ADMIN_KEY= -p HEKETI_USER_KEY= deploy-heketi | /usr/bin/oc -n storage-project create -f - 2>&1
service "deploy-heketi" created
route "deploy-heketi" created
deploymentconfig "deploy-heketi" created
Waiting for deploy-heketi pod to start ...
Checking status of pods matching '--selector=deploy-heketi=pod':
deploy-heketi-1-hf9rn   1/1       Running   0         2m
OK
Determining heketi service URL ... OK
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- heketi-cli -s http://localhost:8080 --user admin --secret '' topology load --json=/etc/heketi/topology.json 2>&1
Creating cluster ... ID: 252509038eb8568162ec5920c12bc243
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node dhcp46-122.lab.eng.blr.redhat.com ... ID: 73ad287ae1ef231f8a0db46422367c9a
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp46-9.lab.eng.blr.redhat.com ... ID: 0da1b20daaad2d5c57dbfc4f6ab78001
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
Creating node dhcp46-134.lab.eng.blr.redhat.com ... ID: 4b3b62fc0efd298dedbcdacf0b498e65
Adding device /dev/sdd ... OK
Adding device /dev/sde ... OK
Adding device /dev/sdf ... OK
heketi topology loaded.
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- heketi-cli -s http://localhost:8080 --user admin --secret '' setup-openshift-heketi-storage --listfile=/tmp/heketi-storage.json --image rhgs3/rhgs-volmanager-rhel7:3.3.0-17 2>&1
Saving /tmp/heketi-storage.json
/usr/bin/oc -n storage-project exec -it deploy-heketi-1-hf9rn -- cat /tmp/heketi-storage.json | /usr/bin/oc -n storage-project create -f - 2>&1
secret "heketi-storage-secret" created
endpoints "heketi-storage-endpoints" created
service "heketi-storage-endpoints" created
job "heketi-storage-copy-job" created

Checking status of pods matching '--selector=job-name=heketi-storage-copy-job':
heketi-storage-copy-job-87v6n   0/1       Completed   0         7s
/usr/bin/oc -n storage-project label --overwrite svc heketi-storage-endpoints glusterfs=heketi-storage-endpoints heketi=storage-endpoints
service "heketi-storage-endpoints" labeled
/usr/bin/oc -n storage-project delete all,service,jobs,deployment,secret --selector="deploy-heketi" 2>&1
deploymentconfig "deploy-heketi" deleted
route "deploy-heketi" deleted
service "deploy-heketi" deleted
job "heketi-storage-copy-job" deleted
pod "deploy-heketi-1-hf9rn" deleted
secret "heketi-storage-secret" deleted
/usr/bin/oc -n storage-project delete dc,route,template --selector="deploy-heketi" 2>&1
template "deploy-heketi" deleted
/usr/bin/oc -n storage-project process -p HEKETI_EXECUTOR=kubernetes -p HEKETI_FSTAB=/var/lib/heketi/fstab -p HEKETI_ADMIN_KEY= -p HEKETI_USER_KEY= heketi | /usr/bin/oc -n storage-project create -f - 2>&1
service "heketi" created
route "heketi" created
deploymentconfig "heketi" created
Waiting for heketi pod to start ...
Checking status of pods matching '--selector=heketi=pod':
heketi-1-zzblp   1/1       Running   0         31s
OK
Determining heketi service URL ... OK

heketi is now running and accessible via http://heketi-storage-project.cloudapps.mystorage.com . To run
administrative commands you can install 'heketi-cli' and use it as follows:

  # heketi-cli -s http://heketi-storage-project.cloudapps.mystorage.com --user admin --secret '<ADMIN_KEY>' cluster list

You can find it at https://github.com/heketi/heketi/releases . Alternatively,
use it from within the heketi pod:

  # /usr/bin/oc -n storage-project exec -it <HEKETI_POD> -- heketi-cli -s http://localhost:8080 --user admin --secret '<ADMIN_KEY>' cluster list

For dynamic provisioning, create a StorageClass similar to this:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://heketi-storage-project.cloudapps.mystorage.com"

Ready to create and provide GlusterFS volumes.
sed -e 's/\${NAMESPACE}/storage-project/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
clusterrole "glusterblock-provisioner-runner" created
serviceaccount "glusterblock-provisioner" created
clusterrolebinding "glusterblock-provisioner" created
deploymentconfig "glusterblock-provisioner-dc" created
Waiting for glusterblock-provisioner pod to start ...
Checking status of pods matching '--selector=glusterfs=block-provisioner-pod':
glusterblock-provisioner-dc-1-xm6bv   1/1       Running   0         6s
OK
Ready to create and provide Gluster block volumes.
/usr/bin/oc -n storage-project create secret generic heketi-storage-project-admin-secret --from-literal=key= --type=kubernetes.io/glusterfs
secret "heketi-storage-project-admin-secret" created
/usr/bin/oc -n storage-project label --overwrite secret heketi-storage-project-admin-secret glusterfs=s3-heketi-storage-project-admin-secret gluster-s3=heketi-storage-project-admin-secret
secret "heketi-storage-project-admin-secret" labeled
sed -e 's/\${STORAGE_CLASS}/glusterfs-for-s3/' -e 's/\${HEKETI_URL}/heketi-storage-project.cloudapps.mystorage.com/' -e 's/\${NAMESPACE}/storage-project/' /usr/share/heketi/templates/gluster-s3-storageclass.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
storageclass "glusterfs-for-s3" created
sed -e 's/\${STORAGE_CLASS}/glusterfs-for-s3/' -e 's/\${VOLUME_CAPACITY}/2Gi/' /usr/share/heketi/templates/gluster-s3-pvcs.yaml | /usr/bin/oc -n storage-project create -f - 2>&1
persistentvolumeclaim "gluster-s3-claim" created
persistentvolumeclaim "gluster-s3-meta-claim" created

Checking status of persistentvolumeclaims matching '--selector=glusterfs in (s3-pvc, s3-meta-pvc)':
gluster-s3-claim        Bound     pvc-35b6c1f0-9c65-11e7-9c8c-005056b3ded1   2Gi       RWX       glusterfs-for-s3   18s
gluster-s3-meta-claim   Bound     pvc-35b86e7a-9c65-11e7-9c8c-005056b3ded1   1Gi       RWX       glusterfs-for-s3   18s
/usr/bin/oc -n storage-project create -f /usr/share/heketi/templates/gluster-s3-template.yaml 2>&1
template "gluster-s3" created
/usr/bin/oc -n storage-project process -p S3_ACCOUNT=testvolume -p S3_USER=adminuser -p S3_PASSWORD=itsmine gluster-s3 | /usr/bin/oc -n storage-project create -f - 2>&1
service "gluster-s3-service" created
route "gluster-s3-route" created
deploymentconfig "gluster-s3-dc" created
Waiting for gluster-s3 pod to start ...
Checking status of pods matching '--selector=glusterfs=s3-pod':
gluster-s3-dc-1-x3x4q   1/1       Running   0         6s
OK
Ready to create and provide Gluster object volumes.

Deployment complete!

以下のコマンドを実行して、ブリックの多重化を有効にします。

# gluster vol set all cluster.brick-multiplex on

以下は例になります。

# gluster vol 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

heketidb ボリュームを再起動します。

# gluster vol stop heketidbstorage
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
volume stop: heketidbstorage: success

# gluster vol start heketidbstorage
volume start: heketidbstorage: success

以下のコマンドを実行して、クライアントがコンテナーと通信できるようにします。
```
# export  HEKETI_CLI_SERVER=http://heketi-<project_name>.<sub_domain_name>
```
以下は例になります。
```
# export  HEKETI_CLI_SERVER=http://heketi-storage-project.cloudapps.mystorage.com
```
トポロジーで Heketi が読み込まれているかどうかを確認するには、以下のコマンドを実行します。
```
# heketi-cli topology info
```

注記

The cns-deploy tool does not support scaling up of the cluster. To manually scale-up the cluster, see link: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-Managing_Clusters[].

次のステップ: コンバージドモード 3.11 をインストールする場合は、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-Updating_Registry に進みます。

付録B アンインストール Playbook の使用時に破棄される設定

uninstall.yml Playbook の実行時に、以下の 2 つのファイルが呼び出されます。

glusterfs_config_facts.yml
glusterfs_registry_facts.yml

以下のコマンドを実行すると、glusterfs_config_facts.yml と glusterfs_registry_facts.yml に関連する data/resources/content/settings が破棄されます。

ansible-playbook -i <path_to_inventory_file> -e "openshift_storage_glusterfs_wipe=true" /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml

glusterfs_config_facts.yml variables:

    glusterfs_timeout: "{{ openshift_storage_glusterfs_timeout }}"
    glusterfs_namespace: "{{ openshift_storage_glusterfs_namespace }}"
    glusterfs_is_native: "{{ openshift_storage_glusterfs_is_native | bool }}"
    glusterfs_name: "{{ openshift_storage_glusterfs_name }}"
    # map_from_pairs is a custom filter plugin in role lib_utils
    glusterfs_nodeselector: "{{ openshift_storage_glusterfs_nodeselector | default(['storagenode', openshift_storage_glusterfs_name] | join('=')) | map_from_pairs }}"
    glusterfs_use_default_selector: "{{ openshift_storage_glusterfs_use_default_selector }}"
    glusterfs_storageclass: "{{ openshift_storage_glusterfs_storageclass }}"
    glusterfs_storageclass_default: "{{ openshift_storage_glusterfs_storageclass_default | bool }}"
    glusterfs_image: "{{ openshift_storage_glusterfs_image }}"
    glusterfs_block_deploy: "{{ openshift_storage_glusterfs_block_deploy | bool }}"
    glusterfs_block_image: "{{ openshift_storage_glusterfs_block_image }}"
    glusterfs_block_host_vol_create: "{{ openshift_storage_glusterfs_block_host_vol_create }}"
    glusterfs_block_host_vol_size: "{{ openshift_storage_glusterfs_block_host_vol_size }}"
    glusterfs_block_host_vol_max: "{{ openshift_storage_glusterfs_block_host_vol_max }}"
    glusterfs_block_storageclass: "{{ openshift_storage_glusterfs_block_storageclass | bool }}"
    glusterfs_block_storageclass_default: "{{ openshift_storage_glusterfs_block_storageclass_default | bool }}"
    glusterfs_s3_deploy: "{{ openshift_storage_glusterfs_s3_deploy | bool }}"
    glusterfs_s3_image: "{{ openshift_storage_glusterfs_s3_image }}"
    glusterfs_s3_account: "{{ openshift_storage_glusterfs_s3_account }}"
    glusterfs_s3_user: "{{ openshift_storage_glusterfs_s3_user }}"
    glusterfs_s3_password: "{{ openshift_storage_glusterfs_s3_password }}"
    glusterfs_s3_pvc: "{{ openshift_storage_glusterfs_s3_pvc }}"
    glusterfs_s3_pvc_size: "{{ openshift_storage_glusterfs_s3_pvc_size }}"
    glusterfs_s3_meta_pvc: "{{ openshift_storage_glusterfs_s3_meta_pvc }}"
    glusterfs_s3_meta_pvc_size: "{{ openshift_storage_glusterfs_s3_meta_pvc_size }}"
    glusterfs_wipe: "{{ openshift_storage_glusterfs_wipe | bool }}"
    glusterfs_heketi_is_native: "{{ openshift_storage_glusterfs_heketi_is_native | bool }}"
    glusterfs_heketi_is_missing: "{{ openshift_storage_glusterfs_heketi_is_missing | bool }}"
    glusterfs_heketi_deploy_is_missing: "{{ openshift_storage_glusterfs_heketi_deploy_is_missing | bool }}"
    glusterfs_heketi_cli: "{{ openshift_storage_glusterfs_heketi_cli }}"
    glusterfs_heketi_image: "{{ openshift_storage_glusterfs_heketi_image }}"
    glusterfs_heketi_admin_key: "{{ openshift_storage_glusterfs_heketi_admin_key }}"
    glusterfs_heketi_user_key: "{{ openshift_storage_glusterfs_heketi_user_key }}"
    glusterfs_heketi_topology_load: "{{ openshift_storage_glusterfs_heketi_topology_load | bool }}"
    glusterfs_heketi_wipe: "{{ openshift_storage_glusterfs_heketi_wipe | bool }}"
    glusterfs_heketi_url: "{{ openshift_storage_glusterfs_heketi_url }}"
    glusterfs_heketi_port: "{{ openshift_storage_glusterfs_heketi_port }}"
    glusterfs_heketi_executor: "{{ openshift_storage_glusterfs_heketi_executor }}"
    glusterfs_heketi_ssh_port: "{{ openshift_storage_glusterfs_heketi_ssh_port }}"
    glusterfs_heketi_ssh_user: "{{ openshift_storage_glusterfs_heketi_ssh_user }}"
    glusterfs_heketi_ssh_sudo: "{{ openshift_storage_glusterfs_heketi_ssh_sudo | bool }}"
    glusterfs_heketi_ssh_keyfile: "{{ openshift_storage_glusterfs_heketi_ssh_keyfile }}"
    glusterfs_heketi_fstab: "{{ openshift_storage_glusterfs_heketi_fstab }}"
    glusterfs_nodes: "{{ groups.glusterfs | default([]) }}"

glusterfs_registry_facts.yml variables:

    glusterfs_timeout: "{{ openshift_storage_glusterfs_registry_timeout }}"
    glusterfs_namespace: "{{ openshift_storage_glusterfs_registry_namespace }}"
    glusterfs_is_native: "{{ openshift_storage_glusterfs_registry_is_native | bool }}"
    glusterfs_name: "{{ openshift_storage_glusterfs_registry_name }}"
    # map_from_pairs is a custom filter plugin in role lib_utils
    glusterfs_nodeselector: "{{ openshift_storage_glusterfs_registry_nodeselector | default(['storagenode', openshift_storage_glusterfs_registry_name] | join('=')) | map_from_pairs }}"
    glusterfs_use_default_selector: "{{ openshift_storage_glusterfs_registry_use_default_selector }}"
    glusterfs_storageclass: "{{ openshift_storage_glusterfs_registry_storageclass }}"
    glusterfs_storageclass_default: "{{ openshift_storage_glusterfs_registry_storageclass_default | bool }}"
    glusterfs_image: "{{ openshift_storage_glusterfs_registry_image }}"
    glusterfs_block_deploy: "{{ openshift_storage_glusterfs_registry_block_deploy | bool }}"
    glusterfs_block_image: "{{ openshift_storage_glusterfs_registry_block_image }}"
    glusterfs_block_host_vol_create: "{{ openshift_storage_glusterfs_registry_block_host_vol_create }}"
    glusterfs_block_host_vol_size: "{{ openshift_storage_glusterfs_registry_block_host_vol_size }}"
    glusterfs_block_host_vol_max: "{{ openshift_storage_glusterfs_registry_block_host_vol_max }}"
    glusterfs_block_storageclass: "{{ openshift_storage_glusterfs_registry_block_storageclass | bool }}"
    glusterfs_block_storageclass_default: "{{ openshift_storage_glusterfs_registry_block_storageclass_default | bool }}"
    glusterfs_s3_deploy: "{{ openshift_storage_glusterfs_registry_s3_deploy | bool }}"
    glusterfs_s3_image: "{{ openshift_storage_glusterfs_registry_s3_image }}"
    glusterfs_s3_account: "{{ openshift_storage_glusterfs_registry_s3_account }}"
    glusterfs_s3_user: "{{ openshift_storage_glusterfs_registry_s3_user }}"
    glusterfs_s3_password: "{{ openshift_storage_glusterfs_registry_s3_password }}"
    glusterfs_s3_pvc: "{{ openshift_storage_glusterfs_registry_s3_pvc }}"
    glusterfs_s3_pvc_size: "{{ openshift_storage_glusterfs_registry_s3_pvc_size }}"
    glusterfs_s3_meta_pvc: "{{ openshift_storage_glusterfs_registry_s3_meta_pvc }}"
    glusterfs_s3_meta_pvc_size: "{{ openshift_storage_glusterfs_registry_s3_meta_pvc_size }}"
    glusterfs_wipe: "{{ openshift_storage_glusterfs_registry_wipe | bool }}"
    glusterfs_heketi_is_native: "{{ openshift_storage_glusterfs_registry_heketi_is_native | bool }}"
    glusterfs_heketi_is_missing: "{{ openshift_storage_glusterfs_registry_heketi_is_missing | bool }}"
    glusterfs_heketi_deploy_is_missing: "{{ openshift_storage_glusterfs_registry_heketi_deploy_is_missing | bool }}"
    glusterfs_heketi_cli: "{{ openshift_storage_glusterfs_registry_heketi_cli }}"
    glusterfs_heketi_image: "{{ openshift_storage_glusterfs_registry_heketi_image }}"
    glusterfs_heketi_admin_key: "{{ openshift_storage_glusterfs_registry_heketi_admin_key }}"
    glusterfs_heketi_user_key: "{{ openshift_storage_glusterfs_registry_heketi_user_key }}"
    glusterfs_heketi_topology_load: "{{ openshift_storage_glusterfs_registry_heketi_topology_load | bool }}"
    glusterfs_heketi_wipe: "{{ openshift_storage_glusterfs_registry_heketi_wipe | bool }}"
    glusterfs_heketi_url: "{{ openshift_storage_glusterfs_registry_heketi_url }}"
    glusterfs_heketi_port: "{{ openshift_storage_glusterfs_registry_heketi_port }}"
    glusterfs_heketi_executor: "{{ openshift_storage_glusterfs_registry_heketi_executor }}"
    glusterfs_heketi_ssh_port: "{{ openshift_storage_glusterfs_registry_heketi_ssh_port }}"
    glusterfs_heketi_ssh_user: "{{ openshift_storage_glusterfs_registry_heketi_ssh_user }}"
    glusterfs_heketi_ssh_sudo: "{{ openshift_storage_glusterfs_registry_heketi_ssh_sudo | bool }}"
    glusterfs_heketi_ssh_keyfile: "{{ openshift_storage_glusterfs_registry_heketi_ssh_keyfile }}"
    glusterfs_heketi_fstab: "{{ openshift_storage_glusterfs_registry_heketi_fstab }}"
    glusterfs_nodes: "{% if groups.glusterfs_registry is defined and groups['glusterfs_registry'] | length > 0 %}{% set nodes = groups.glusterfs_registry %}{% elif 'groups.glusterfs' is defined and groups['glusterfs'] | length > 0 %}{% set nodes = groups.glusterfs %}{% else %}{% set nodes = '[]' %}{% endif %}{{ nodes }}"

付録C テンプレート

C.1. glusterblock プロビジョナーテンプレート

このセクションでは、Glusterblock Provisioner テンプレート について説明します。

---
kind: Template
apiVersion: v1
metadata:
  name: glusterblock-provisioner
  labels:
    glusterfs: block-template
    glusterblock: template
  annotations:
    description: glusterblock provisioner template
    tags: glusterfs
objects:
- kind: ClusterRole
  apiVersion: v1
  metadata:
    name: glusterblock-provisioner-runner
    labels:
      glusterfs: block-provisioner-runner-clusterrole
      glusterblock: provisioner-runner-clusterrole
  rules:
    - apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
    - apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
    - apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
    - apiGroups: [""]
      resources: ["events"]
      verbs: ["list", "watch", "create", "update", "patch"]
    - apiGroups: [""]
      resources: ["services"]
      verbs: ["get"]
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "create", "delete"]
    - apiGroups: [""]
      resources: ["routes"]
      verbs: ["get", "list"]
    - apiGroups: [""]
      resources: ["endpoints"]
      verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner
    labels:
      glusterfs: block-${CLUSTER_NAME}-provisioner-sa
      glusterblock: ${CLUSTER_NAME}-provisioner-sa
- apiVersion: v1
  kind: ClusterRoleBinding
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner
  roleRef:
    name: glusterblock-provisioner-runner
  subjects:
  - kind: ServiceAccount
    name: glusterblock-${CLUSTER_NAME}-provisioner
    namespace: ${NAMESPACE}
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner-dc
    labels:
      glusterfs: block-${CLUSTER_NAME}-provisioner-dc
      glusterblock: ${CLUSTER_NAME}-provisioner-dc
    annotations:
      description: Defines how to deploy the glusterblock provisioner pod.
  spec:
    replicas: 1
    selector:
      glusterfs: block-${CLUSTER_NAME}-provisioner-pod
    triggers:
    - type: ConfigChange
    strategy:
      type: Recreate
    template:
      metadata:
        name: glusterblock-provisioner
        labels:
          glusterfs: block-${CLUSTER_NAME}-provisioner-pod
      spec:
        serviceAccountName: glusterblock-${CLUSTER_NAME}-provisioner
        containers:
        - name: glusterblock-provisioner
          image: ${IMAGE_NAME}
          imagePullPolicy: IfNotPresent
          env:
          - name: PROVISIONER_NAME
            value: gluster.org/glusterblock-${NAMESPACE}
parameters:
- name: IMAGE_NAME
  displayName: glusterblock provisioner container image name
  required: True
- name: NAMESPACE
  displayName: glusterblock provisioner namespace
  description: The namespace in which these resources are being created
  required: True
- name: CLUSTER_NAME
  displayName: GlusterFS cluster name
  description: A unique name to identify which heketi service manages this cluster, useful for running multiple heketi instances
  value: storage

C.2. コンバージドモード設定のインベントリーファイルサンプル

本セクションでは、コンバージドモードの設定用のインベントリーファイル例 について説明します。

[OSEv3:children]
masters
nodes
etcd
glusterfs
glusterfs_registry

[OSEv3:vars]
ansible_ssh_user=root
debug_level=5
os_update=false
install_method=rpm
install_update_docker=true
docker_storage_driver=devicemapper
container_runtime_docker_storage_setup_device=/dev/sdc
oreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11
openshift_release=v3.11
openshift_docker_additional_registries=registry.access.redhat.com
openshift_docker_insecure_registries=registry.access.redhat.com
openshift_deployment_type=openshift-enterprise
openshift_web_console_install=true
openshift_enable_service_catalog=false
openshift_set_hostname=true
openshift_override_hostname_check=true
openshift_disable_check=docker_image_availability
openshift_check_min_host_disk_gb=2
openshift_check_min_host_memory_gb=1
openshift_portal_net=172.31.0.0/16
openshift_master_cluster_method=native
openshift_clock_enabled=true
openshift_hosted_router_selector="node-role.kubernetes.io/infra=true"
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"
openshift_use_openshift_sdn=true
osm_use_cockpit=false
osm_cockpit_plugins=['cockpit-kubernetes']

openshift_master_dynamic_provisioning_enabled=true


# logging
openshift_logging_install_logging=true
openshift_logging_storage_kind=dynamic
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_cluster_size=1
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_pvc_size=20Gi
openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"


# metrics
openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=pv
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"


# glusterfs
openshift_storage_glusterfs_timeout=900
openshift_storage_glusterfs_namespace=glusterfs
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100


# glusterfs_registry
openshift_storage_glusterfs_registry_namespace=glusterfs-registry
openshift_storage_glusterfs_registry_storageclass=true
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi


openshift_storage_glusterfs_heketi_admin_key='<adminkey>'
openshift_storage_glusterfs_heketi_user_key='<heketiuserkey>'


openshift_storage_glusterfs_image='registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.x'

openshift_storage_glusterfs_heketi_image='registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.x'

openshift_storage_glusterfs_block_image='registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.x'


openshift_master_cluster_hostname=node101.redhat.com
openshift_master_cluster_public_hostname=node101.redhat.com

[masters]
node101.redhat.com

[etcd]
node101.redhat.com

[nodes]
node101.redhat.com openshift_node_group_name="node-config-master"
node102.redhat.com openshift_node_group_name="node-config-infra"
node103.redhat.com openshift_node_group_name="node-config-compute"
node104.redhat.com openshift_node_group_name="node-config-compute"
node105.redhat.com openshift_node_group_name="node-config-compute"
node106.redhat.com openshift_node_group_name="node-config-compute"
node107.redhat.com openshift_node_group_name="node-config-compute"
node108.redhat.com openshift_node_group_name="node-config-compute"

[glusterfs]
node103.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node104.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node105.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1

[glusterfs_registry]
node106.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node107.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node108.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1

C.3. インデペンデントモード設定のインベントリーファイルのサンプル

以下のセクションでは、インデペンデントモード設定のインベントリーファイルのサンプルを紹介します。

[OSEv3:children]
masters
nodes
etcd
glusterfs
glusterfs_registry

[OSEv3:vars]
ansible_ssh_user=root
debug_level=5
os_update=false
install_method=rpm
install_update_docker=true
docker_storage_driver=devicemapper
container_runtime_docker_storage_setup_device=/dev/sdc
oreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11
openshift_release=v3.11
openshift_docker_additional_registries=registry.access.redhat.com
openshift_docker_insecure_registries=registry.access.redhat.com
openshift_deployment_type=openshift-enterprise
openshift_web_console_install=true
openshift_enable_service_catalog=false
openshift_set_hostname=true
openshift_override_hostname_check=true
openshift_disable_check=docker_image_availability
openshift_check_min_host_disk_gb=2
openshift_check_min_host_memory_gb=1
openshift_portal_net=172.31.0.0/16
openshift_master_cluster_method=native
openshift_clock_enabled=true
openshift_hosted_router_selector="node-role.kubernetes.io/infra=true"
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"
openshift_use_openshift_sdn=true
osm_use_cockpit=false
osm_cockpit_plugins=['cockpit-kubernetes']

openshift_master_dynamic_provisioning_enabled=true


# logging
openshift_logging_install_logging=true
openshift_logging_storage_kind=dynamic
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_cluster_size=1
openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_logging_es_pvc_size=20Gi
openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"


# metrics
openshift_metrics_install_metrics=true
openshift_metrics_cassandra_storage_type=pv
openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
openshift_metrics_storage_volume_size=20Gi
openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"


# glusterfs
openshift_storage_glusterfs_timeout=900
openshift_storage_glusterfs_namespace=glusterfs
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_is_native=false
openshift_storage_glusterfs_heketi_is_native=true
openshift_storage_glusterfs_heketi_executor=ssh
openshift_storage_glusterfs_heketi_ssh_port=22
openshift_storage_glusterfs_heketi_ssh_user=root
openshift_storage_glusterfs_heketi_ssh_sudo=false
openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"


# glusterfs_registry
openshift_storage_glusterfs_registry_namespace=glusterfs-registry
openshift_storage_glusterfs_registry_storageclass=true
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100
openshift_storage_glusterfs_registry_is_native=false
openshift_storage_glusterfs_registry_heketi_is_native=true
openshift_storage_glusterfs_registry_heketi_executor=ssh
openshift_storage_glusterfs_registry_heketi_ssh_port=22
openshift_storage_glusterfs_registry_heketi_ssh_user=root
openshift_storage_glusterfs_registry_heketi_ssh_sudo=false
openshift_storage_glusterfs_registry_heketi_ssh_keyfile="/root/.ssh/id_rsa"

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi


openshift_storage_glusterfs_heketi_admin_key='adminkey'
openshift_storage_glusterfs_heketi_user_key='heketiuserkey'


openshift_storage_glusterfs_heketi_image='registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.x'

openshift_storage_glusterfs_block_image='registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.x'


openshift_master_cluster_hostname=node101.redhat.com
openshift_master_cluster_public_hostname=node101.redhat.com

[masters]
node101.redhat.com

[etcd]
node101.redhat.com

[nodes]
node101.redhat.com openshift_node_group_name="node-config-master"
node102.redhat.com openshift_node_group_name="node-config-infra"
node103.redhat.com openshift_node_group_name="node-config-compute"
node104.redhat.com openshift_node_group_name="node-config-compute"

[glusterfs]
node105.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node105_ip
node106.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node106_ip
node107.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node107_ip

[glusterfs_registry]
node108.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node108_ip
node109.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node109_ip
node110.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node110_ip

デプロイメントガイド

Red Hat Openshift Container Storage 3.11 のデプロイ

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

パート I. プランニング

第1章 ワークロードの特定

第2章 ユースケースの特定

2.1. コンバージドモード

2.2. インデペンデントモード

第3章 前提条件の検証

3.1. コンバージドモード

3.1.1. サポート対象バージョン

3.1.2. 環境要件

3.1.2.1. OpenShift Container Platform を備えた Red Hat Openshift Container Storage の Red Hat Enterprise Linux 7 へのインストール

3.1.2.1.1. Openshift マスターのクライアントとしての設定

3.1.2.2. OpenShift Container Platform のオプション

3.1.3. Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件

3.1.4. デプロイメントおよびスケーリングのガイドライン

3.2. インデペンデントモード

3.2.1. サポート対象バージョン

3.2.2. 環境要件

3.2.2.1. OpenShift Container Platform を備えた Red Hat Openshift Container Storage の Red Hat Enterprise Linux 7 へのインストール

3.2.2.1.1. Openshift マスターのクライアントとしての設定

3.2.2.2. OpenShift Container Platform のオプション

3.2.3. Red Hat OpenShift Container Platform および Red Hat Openshift Container Storage の要件

3.2.4. Red Hat Gluster Storage の要件

3.2.5. デプロイメントおよびスケーリングのガイドライン

パート II. デプロイ

第4章 コンバージドモードでのコンテナー化されたストレージのデプロイ

4.1. 高度なインストーラー変数の指定

4.2. コンバージドモードでのRed Hat Openshift Container Storageのデプロイ

4.3. レジストリーを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ

4.4. ロギングとメトリクスを使用したコンバージドモードでの Red Hat Openshift Container Storage のデプロイ

4.5. レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をコンバージドモードでデプロイする

4.6. 単一の OCS クラスターのインストール

4.7. ゾーン全体にブリックを配置するように Heketi を設定する

4.8. デプロイメントの確認

4.9. Arbiter ボリュームの作成（オプション）

4.9.1. Arbiter ボリュームの作成

4.9.1.1. Heketi CLI を使用した Arbiter ボリュームの作成

4.9.1.2. Storageclass ファイルを使用した Arbiter ボリュームの作成

4.9.2. Arbiter ボリュームとしてのブロックホストボリュームの作成

第5章 インデペンデントモードでのコンテナーストレージのデプロイ

5.1. RHGS クラスターの設定

5.1.1. Red Hat Gluster Storage Server の Red Hat Enterprise Linux へのインストール (階層化インストール)

5.1.2. ポートアクセスの設定

5.1.3. カーネルモジュールの有効化

5.1.4. サービスの起動と有効化

5.1.5. 2 TB（以上）のブロックボリュームの作成

5.2. 高度なインストーラー変数の指定

5.3. インデペンデントモードでの Red Hat Openshift Container Storage のデプロイ

5.4. レジストリー、ロギングおよびメトリックスを使用したアプリケーション向けの Red Hat Openshift Container Storage をインデペンデントモードでデプロイする

5.5. 単一の OCS クラスターのインストール

5.6. ゾーン全体にブリックを配置するように Heketi を設定する

5.7. デプロイメントの確認

5.8. Arbiter ボリュームの作成（オプション）

5.8.1. Arbiter ボリュームの作成

5.8.1.1. Heketi CLI を使用した Arbiter ボリュームの作成

5.8.1.2. Storageclass ファイルを使用した Arbiter ボリュームの作成

5.8.2. Arbiter ボリュームとしてのブロックホストボリュームの作成

パート III. アップグレード

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

6.1. glusterfs グループの Pod のアップグレード

6.1.1. 前提条件

6.1.2. /dev/log の元のラベル値の復元

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

6.1.3.1. cns-deploy および Heketi Server のアップグレード

6.1.3.2. Red Hat Gluster Storage Pod のアップグレード

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

6.1.4.1. Heketi サーバーのアップグレード

6.1.4.2. Red Hat Gluster Storage Pod のアップグレード

6.2. glusterfs レジストリーグループの Pod のアップグレード

6.2.1. 前提条件

6.2.2. /dev/log の元のラベル値の復元

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

6.2.3.1. cns-deploy および Heketi Server のアップグレード

6.2.3.2. Red Hat Gluster Storage レジストリー Pod のアップグレード

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

6.2.4.1. Heketi サーバーのアップグレード

6.2.4.2. Red Hat Gluster Storage レジストリー Pod のアップグレード

6.3. Heketi Pod の起動

第1章ワークロードの特定

第2章ユースケースの特定

第3章前提条件の検証

第4章コンバージドモードでのコンテナー化されたストレージのデプロイ

第5章インデペンデントモードでのコンテナーストレージのデプロイ

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

第8章インデペンデントモードでの Red Hat Openshift Container Storage のアップグレード

第11章カスタムボリュームオプションの設定