デプロイメントガイド
Red Hat Openshift Container Storage 3.11 のデプロイ
概要
多様性を受け入れるオープンソースの強化
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 のコンバージドモード
Red Hat Openshift Container Storage は、ansible ワークフローを使用したコンバージドモードとインデペンデントモードを同時にデプロイすることをサポートしていません。したがって、コンバージドモードまたはインデペンデントモードのいずれかをデプロイする必要があります。デプロイメント時に両方のモードを混在させることはできません。
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 ボリュームの割り当ておよび割り当て解除を動的に管理します。
Red Hat Openshift Container Storage は、ansible ワークフローを使用したコンバージドモードとインデペンデントモードを同時にデプロイすることをサポートしていません。したがって、コンバージドモードまたはインデペンデントモードのいずれかをデプロイする必要があります。デプロイメント時に両方のモードを混在させることはできません。
インデペンデントモードでは、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-clientRPM (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. サポート対象バージョン
Red Hat Gluster Storage Server および Container-Native Storage を備えた OpenShift Container Platform のサポートされているバージョンについては https://access.redhat.com/articles/3403951 を参照してください。
3.2.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.2.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.2.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.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 バージョンに基づいています。
ネイティブクライアントパッケージのインストールに関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html-single/administration_guide/index#Installing_Native_Client を参照してください。
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 つの物理コアペア
2 つの物理コアのペアは、ハイパースレッディングされていないシステムの場合は 4 vCPU に変換し、ハイパースレッディングシステムの場合は 8 vCPU に変換します。
インデペンデントモードのデプロイメントガイドライン
- インデペンデントモードでは、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 は、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 へのオプションとして提供します。
初回の 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
- デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。
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 へのオプションとして提供します。
初回の 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
- デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。
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注記[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"
上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {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.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
コンバージドモードのストレージプロビジョニングの検証
ストレージクラスリソースを使用して、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 リソースを使用して新規永続ボリューム要求を作成します。
# 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: 5Gi4.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 は、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. 高度なインストーラー変数の指定
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 クラスターと対話します。
すべてのコンテナー化されたコンポーネントに、バージョンタグを指定することが推奨されます。これは主にコンポーネントが、ソフトウェアバージョンが大きく異なるクラスターが発生する可能性のある停止後にアップグレードされないようにするためです。関連する変数は以下のとおりです。
-
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" ]'
上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {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
- デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。
5.5. 単一の 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 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 は、ノードゾーンをブリック配置のヒントとして使用します。異なるゾーンでレプリカブリックを厳密に配置するように 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
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
以下のコマンドを実行して、infra-storage namespace のインストールを検証します。これは、OCP マスターノード、または OC CLI がインストールされている Ansible デプロイホストから実行できます。
# 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
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
インデペンデントモード用のストレージプロビジョニングの検証
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-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
5.8. 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 ブリックがワークロードに対応できるように、データブリックのサイズとファイル数に基づいてファイルサイズを平均より若干少なめに選択することを推奨します。
5.8.1. Arbiter ボリュームの作成
Arbiter ボリュームは、Heketi CLI を使用して、または storageclass ファイルを更新して作成できます。
5.8.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'
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: 5Gi5.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
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 を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
以下のコマンドを実行して、
DeploymentConfigを取得します。# oc get ds
以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。
# heketi-cli server mode set local-client
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。
# oc scale dc <heketi_dc> --replicas=0
以下のコマンドを実行して、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 ノードにラベルを付けます。
以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
# 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 を手動で削除した場合にのみ作成されます。以下のコマンドを実行して、古い 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]$"
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" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。
これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。
以下のコマンドを使用して 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
glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。
# oc rsh glusterfs-0vcf3
以下のコマンドを実行します。
# 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 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。
Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。
# oc rsh <gluster_pod_name>
ブリックの多重化ステータスを確認します。
# gluster v get all all
無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。
注記ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。
# 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
信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。
以下は例になります。
# 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操作を確認します。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
Heketi データベースファイルのバックアップを作成します。
# heketi-cli db dump > heketi-db-dump-$(date -I).json
注記作成された json ファイルを使用して復元することができるため、選択した永続ストレージに保存する必要があります。
以下のコマンドを実行して、heketi クライアントパッケージを更新します。インストールされているすべての OCP ノードで、
heketi-clientパッケージを更新します。新しいインストールでは、いずれのOCPノードにもheketi-clientrpm がインストールされていない可能性があります。# yum update heketi-client -y
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
# oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echoHEKETI_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
注記クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。
以下のコマンドを実行して、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 を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
以下のコマンドを実行して、
DeploymentConfigを取得します。# oc get dc
以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。
# heketi-cli server mode set local-client
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。
# oc scale dc <heketi_dc> --replicas=0
以下のコマンドを実行して、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注記クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container 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 ノードにラベルを付けます。
以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
# 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 を手動で削除した場合にのみ作成されます。以下のコマンドを実行して、古い 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]$"
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" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。
これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。
以下のコマンドを使用して 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
glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。
# oc rsh glusterfs-0vcf3
以下のコマンドを実行します。
# 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 サフィックスがある場合は、既存の名前を再利用します。
-
2 つ以上のプロビジョナーがある場合、名前は
テンプレートの編集後に以下のコマンドを実行して、デプロイメント設定を作成します。
# 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 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。
Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。
# oc rsh <gluster_pod_name>
ブリックの多重化ステータスを確認します。
# gluster v get all all
無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。
注記ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。
# 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
信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。
以下は例になります。
# 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
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
注記クラスターに 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-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 を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
以下のコマンドを実行して、
DeploymentConfigを取得します。# oc get ds
以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。
# heketi-cli server mode set local-client
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。
# oc scale dc <heketi_dc> --replicas=0
以下のコマンドを実行して、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 ノードにラベルを付けます。
以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
# 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 を手動で削除した場合にのみ作成されます。古い 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]$"
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" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。
これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。
以下のコマンドを使用して 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
glusterfs-registry Pod のいずれかにリモートシェルを実行します。以下は例になります。
# oc rsh glusterfs-registry-g6vd9
以下のコマンドを実行します。
# 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 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。
Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。
# oc rsh <gluster_pod_name>
ブリックの多重化ステータスを確認します。
# gluster v get all all
無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。
注記ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。
# 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
信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。
以下は例になります。
# 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 を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
以下のコマンドを実行して、
DeploymentConfigを取得します。# oc get ds
以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。
# heketi-cli server mode set local-client
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
Heketi データベースファイルのバックアップを作成します。
# heketi-cli db dump > heketi-db-dump-$(date -I).json
注記作成された json ファイルを使用して復元することができるため、選択した永続ストレージに保存する必要があります。
以下のコマンドを実行して、heketi クライアントパッケージを更新します。インストールされているすべての OCP ノードで、
heketi-clientパッケージを更新します。新しいインストールでは、いずれのOCPノードにもheketi-clientrpm がインストールされていない可能性があります。# yum update heketi-client -y
以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。
OCS 管理者は、インフラストラクチャーによって使用されていない限り、ユーザーキーに任意のフレーズを設定することを選択できます。これは、OCSのデフォルトでインストールされているリソースでは使用されません。
# oc get secret heketi-registry-admin-secret -o jsonpath='{.data.key}'|base64 -d;echoHEKETI_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
既存のテンプレートに 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-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
注記クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。
以下のコマンドを実行して、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 を停止し、ボリュームの作成やボリュームの削除に関する新しいリクエストを受け入れないようにします。
以下のコマンドを実行して、プロジェクトにアクセスします。
# oc project <project_name>
以下は例になります。
# oc project storage-project
以下のコマンドを実行して、
DeploymentConfigを取得します。# oc get dc
以下のコマンドを実行して heketi サーバーを設定し、local-client からのリクエストのみを受け入れます。
# heketi-cli server mode set local-client
継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。
# heketi-cli server operations info
以下のコマンドを実行して、レプリカ数を 1 から 0 に減らします。これにより、Heketi Pod の数が減ります。
# oc scale dc <heketi_dc> --replicas=0
以下のコマンドを実行して、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テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterfs テンプレートを更新します。以下は例になります。
# oc edit template glusterfs - description: Labels which define the daemonset node selector. Must contain at least one label of the format \'glusterfs=<CLUSTER_NAME>-host\' displayName: Daemonset Node Labels name: NODE_LABELS value: '{ "glusterfs": "registry-host" }' - displayName: GlusterFS container image name name: IMAGE_NAME required: true value: registry.redhat.io/rhgs3/rhgs-server-rhel7 - description: A unique name to identify which heketi service manages this cluster, useful for running multiple heketi instances - displayName: GlusterFS container image version name: IMAGE_VERSION required: true value: v3.11.8 - displayName: GlusterFS cluster name name: CLUSTER_NAME value: registry注記- CLUSTER_NAME 変数が正しい値に設定されていることを確認します。
- クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。
Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。
以下のコマンドを使用して、ノードに適切なラベルでラベル付けされているかどうかを確認します。
# 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
以下のコマンドを実行して、gluster DaemonSet を作成します。
# oc process glusterfs | oc create -f -
以下に例を示します。
# oc process glusterfs | oc create -f - Deamonset “glusterfs-registry” created
以下のコマンドを実行して、削除する必要のある古い 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 を手動で削除した場合にのみ作成されます。古い 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]$"
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 …
以下のコマンドを実行して、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-abmqa 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" オプションは、アプリケーションから送信されたデータがブリックから確認応答されないままになることができる最大時間（秒単位）を指定します。
これは、強制的な切断や接続の切断（ノードが予期せず停止した場合にファイアウォールがアクティブ化されるなど）を早期に検出し、アプリケーションが全体的なフェイルオーバー時間を短縮できるようにするために使用されます。
以下のコマンドを使用して 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
glusterfs-registry Pod のいずれかにリモートシェルを実行します。以下は例になります。
# oc rsh glusterfs-registry-g6vd9
以下のコマンドを実行します。
# 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
以下のコマンドを実行して、古い 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 および 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
古い 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 サフィックスがある場合は、既存の名前を再利用します。
-
2 つ以上のプロビジョナーがある場合、名前は
テンプレートの編集後に以下のコマンドを実行して、デプロイメント設定を作成します。
# 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
ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。
Gluster Pod に対して実行するには、以下のコマンドを実行し、gluster Pod のいずれかにリモートシェルを実行します。
# oc rsh <gluster_pod_name>
ブリックの多重化ステータスを確認します。
# gluster v get all all
無効になっている場合は、以下のコマンドを実行して、ブリックの多重化を有効にします。
注記ブリックの多重化が有効になっている間は、すべてのボリュームが停止状態にあるか、ブリックが実行されていないことを確認してください。
# 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
信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。
以下は例になります。
# 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 ノードでクライアントをアップグレードします。
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.ymlPlaybook を使用してデプロイされた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 ノードで、以下のコマンドを実行します。
heketidbstorage ボリュームを作成します。
# heketi-cli volume create --size=2 --name=heketidbstorage
ボリュームをマウントします。
# mount -t glusterfs 192.168.11.192:heketidbstorage /mnt/
192.168.11.192 は RHGS ノードの 1 つになります。
heketi サービスを停止します。
# systemctl stop heketi
heketi サービスを無効にします。
# systemctl disable heketi
heketi db を heketidbstorage ボリュームにコピーします。
# cp /var/lib/heketi/heketi.db /mnt/
ボリュームをアンマウントします。
# umount /mnt
以下のファイルを 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 アドレスを取得します。heketi-gluster-endpoints.yamlファイルを作成します。# oc create -f ./heketi-gluster-endpoints.yaml
すべての 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
注記クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container 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;echoHEKETI_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: ""
クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。
以下のコマンドを実行して、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ブロックをアップグレードします。
ブロックストレージに推奨される Red Hat Enterprise Linux(RHEL)バージョンは RHEL 7.5.4 です。カーネルのバージョンが 3.10.0-862.14.4.el7.x86_64 と一致していることを確認してください。確認するには、以下を実行します。
# 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
テンプレートに、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 から以下のリソースを削除します。
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 サフィックスがある場合は、既存の名前を再利用します。
-
2 つ以上のプロビジョナーがある場合、名前は
テンプレートの編集後に以下のコマンドを実行して、デプロイメント設定を作成します。
# 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;echoHEKETI_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
既存のテンプレートに 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-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: ""
テンプレートに 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-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:""
クラスターに 1000 を超えるボリュームがある場合は、How to change the default PVS limit in Openshift Container Storage を参照し、アップグレードに進む前に必要なパラメーターを追加します。
以下のコマンドを実行して、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 サフィックスがある場合は、既存の名前を再利用します。
-
2 つ以上のプロビジョナーがある場合、名前は
テンプレートの編集後に以下のコマンドを実行して、デプロイメント設定を作成します。
# 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"
パート 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. インデペンデントモードの設定
インデペンデントモードの設定では、専用の Red Hat Gluster Storage クラスターが OpenShift Container Platform の外部で利用できます。ストレージは Red Hat Gluster Storage クラスターからプロビジョニングされます。
A.2.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 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
- gluster-block を有効にするには、以下のコマンドを実行します。
# yum install gluster-block
再起動
システムを再起動します。
A.2.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 です。各ノードでホストできるブリックの最大数に基づいて、ポート範囲を設定します。
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
以下のコマンドを実行して、ルーターのデプロイメントを有効にします。
# oc adm policy add-scc-to-user privileged -z router
以下のコマンドを実行して、ルーターをデプロイします。
# oc adm router storage-project-router --replicas=1
/etc/origin/master/master-config.yaml にある config.yaml ファイルのサブドメイン名を編集します。
以下は例になります。
subdomain: "cloudapps.mystorage.com"
OpenShift Container Platform 3.7 および 3.9 の場合は、以下のコマンドを実行してサービスを再起動します。
# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers
ルーター設定の詳細は、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 を設定します。
以下のコマンドを実行して、ルーターの 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
/etc/dnsmasq.conf ファイルを編集し、以下の行をファイルに追加します。
address=/.cloudapps.mystorage.com/<Router_IP_Address>Router_IP_Address は、ルーターが実行されているノードの IP アドレスです。
以下のコマンドを実行して
dnsmasqサービスを再起動します。# systemctl restart dnsmasq
/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 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. 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: --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: glusterfs-storage provisioner: kubernetes.io/glusterfs parameters: resturl: "http://heketi-storage-project.cloudapps.mystorage.com" 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
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 --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!
ブリック多重化は、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
以下のコマンドを実行して、クライアントがコンテナーと通信できるようにします。
# 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: storageC.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=1C.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