Menu Close

デプロイメントガイド

Red Hat OpenShift Container Storage 3.11

Red Hat Openshift Container Storage 3.11 のデプロイ

概要

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

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

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

パート I. プランニング

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

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

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

  • Jenkins
  • ElasticSearch
  • Prometheus

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

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

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

注記

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

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

2.1. コンバージドモード

注記

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

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

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

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

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

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

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

Architecture - Converged Mode for OpenShift Container Platform
注記

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-client RPM (glusterfs、glusterfs-client-xlators、glusterfs-libs、glusterfs-fuse) がインストールされている必要があります。以下のコマンドを実行して、RPM がインストールされているかどうかを確認できます。

    # yum list glusterfs glusterfs-client-xlators glusterfs-libs glusterfs-fuse
注記

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

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

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

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

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

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

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

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

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

    • 永続ボリュームごとに最低 8 GB の RAM および 30 MB
    • 同じディスクタイプ
    • heketidb は 2 GB の分散レプリカボリュームを利用
    • 最小 2 つの物理コアペア
注記

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

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

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

    # rpm -q kernel
    kernel-3.10.0-862.14.4.el7.x86_64
    # uname -r
    3.10.0-862.14.4.el7.x86_64

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

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

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 上でコンテナーにストレージを設定するには、目的に合ったワークフローを選択してください。

注記
  • 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.ioregistry.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のデプロイ

  1. インベントリファイルで、[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単位のボリュームのサイズです。

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

    [OSEv3:children]
    masters
    etcd
    nodes
    glusterfs
  3. 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"]'
  4. [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"
  5. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。

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

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

      ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
  6. デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。

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

  1. インベントリーファイルで、[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
  2. インベントリーファイルの [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'
  3. [OSEv3:children] セクションに glusterfs_registry を追加して、`[glusterfs_registry]` グループを有効にします。

    [OSEv3:children]
    masters
    etcd
    nodes
    glusterfs_registry
  4. 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"
  5. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。

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

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

      ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
  6. デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。

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

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

    [OSEv3:vars]
    ...
    openshift_metrics_install_metrics=true
    openshift_metrics_cassandra_storage_type=pv
    openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_storage_volume_size=20Gi
    openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"
    
    openshift_logging_install_logging=true
    openshift_logging_es_pvc_dynamic=true
    openshift_logging_storage_kind=dynamic
    openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_es_pvc_size=20Gi
    openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"
    
    openshift_storage_glusterfs_registry_namespace=infra-storage
    openshift_storage_glusterfs_registry_storageclass=false
    openshift_storage_glusterfs_registry_storageclass_default=false
    openshift_storage_glusterfs_registry_block_deploy=true
    openshift_storage_glusterfs_registry_block_host_vol_create=true
    openshift_storage_glusterfs_registry_block_host_vol_size=100
    openshift_storage_glusterfs_registry_block_storageclass=true
    openshift_storage_glusterfs_registry_block_storageclass_default=false
    注記

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

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

    [OSEv3:children]
    masters
    etcd
    nodes
    glusterfs_registry
  3. 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"]'
  4. [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"
  1. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。

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

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

      ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
      
      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
  2. デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。

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

  1. インベントリーファイルの [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 を設定してください。

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

    [OSEv3:children]
    ...
    glusterfs
    glusterfs_registry
  3. [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"]'
  4. [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"
  5. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {gluster} をデプロイするには、ファイルパスを以下の Playbook へのオプションとして提供します。

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

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

      ansible-playbook -i <path_to_inventory_file> /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/config.yml
      
      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
  6. デプロイメントを確認するには、「デプロイメントの確認」 を参照してください。

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

単一の OCS クラスターで、汎用アプリケーションストレージとインフラストラクチャーストレージの両方をサポートすることが可能です。これを実行するには、インベントリファイルのオプションが、ログとメトリックスでわずかに変更されます。これは、クラスターが 1 つしかない場合、gluster-block StorageClassglusterfs-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 ストレージクラスを削除し、再作成します。

  1. ストレージクラスオブジェクトを yaml ファイルにエクスポートします。

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

    # oc delete sc glusterfs-storage
    # oc create -f glusterfs-storage.yaml

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

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

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

    1. 以下のコマンドを実行して、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
    2. 以下のコマンドを実行して、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
    3. 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
  2. コンバージドモードのストレージプロビジョニングの検証

    1. ストレージクラスリソースを使用して、RHOCSデプロイメントを検証するための新しいPV要求を作成できます。RHOCS デプロイメント時に作成された以下の OCP Storage Class を使用して、PV プロビジョニングを検証します。

      # 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
  3. 検証に heketi-client を使用する

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

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

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

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

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

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

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

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

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

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

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

Arbitrated Replicated ボリュームの利点

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

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

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

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

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

注記

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

4.9.1. Arbiter ボリュームの作成

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

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

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

以下は例になります。

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

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

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

  • user.heketi.arbiter true
  • (オプション)user.heketi.average-file-size 1024

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

# cat glusterfs-storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-container
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
  restuser: "admin"
  volumetype: "replicate:3"
  clusterid: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
  secretNamespace: "default"
  secretName: "heketi-secret"
  volumeoptions: "user.heketi.arbiter true,user.heketi.average-file-size 1024"
  volumenameprefix: "test-vol"
spec:
  persistentVolumeReclaimPolicy: Retain
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
storage: 5Gi

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

注記

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

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

  1. 以下の環境変数および値を追加して、Heketi デプロイメント設定の Glusterfs セクションの下にある設定ファイルを編集します。

    HEKETI_BLOCK_HOSTING_VOLUME_OPTIONS: group gluster-block,user.heketi.arbiter true
  2. Heketi CLI を使用してブロックボリュームを作成します。

      # heketi-cli blockvolume create --size=100
  3. ブロックホスティングボリュームが arbiter ボリュームであることを確認します。

     # gluster v info
    注記

    arbiter ボリュームの管理に関する詳細は、10章Arbitrated Replicated ボリュームの管理 を参照してください。

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

任意のソリューションのデプロイメントワークフローを実行する前に、「RHGS クラスターの設定」 を完了し、「高度なインストーラー変数の指定」 を確認して Ansible 変数および Playbook の推奨事項と要件を理解するようにしてください。ストレージをスタンドアロンの Red Hat Gluster 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.ioregistry.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-レプリケーション関連の各種ファイル、およびその他のファイルを作成することが推奨されます。

  1. Red Hat Enterprise Linux 7 Server のベースインストールの実行

    インデペンデントモードは、Red Hat Enterprise Linux 7 でのみサポートされます。

  2. システムの Subscription Manager への登録

    以下のコマンドを実行し、Red Hat Network のユーザー名およびパスワードを入力して、システムを Red Hat Network に登録します。

    # subscription-manager register
  3. 利用可能なエンタイトルメントプールの特定

    以下のコマンドを実行して、Red Hat Gluster Storage のインストールに必要なリポジトリーが含まれるエンタイトルメントプールを見つけます。

    # subscription-manager list --available
  4. システムへのエンタイトルメントプールのアタッチ

    先の手順で特定したプール ID を使用して、Red Hat Enterprise Linux Server および Red Hat Gluster Storage のエンタイトルメントをシステムにアタッチします。以下のコマンドを実行してエンタイトルメントをアタッチします。

    # subscription-manager attach --pool=[POOLID]

    以下は例になります。

    # subscription-manager attach --pool=8a85f9814999f69101499c05aa706e47
  5. 必要なチャンネルの有効化

    以下のコマンドを実行して、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
  6. チャンネルが有効であるかどうかの確認

    以下のコマンドを実行して、チャンネルが有効であるかどうかを確認します。

    # yum repolist
  7. すべてのパッケージの更新

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

+

# yum update
  1. カーネルバージョンの要件

    インデペンデントモードでは、システムで 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
  2. Red Hat Gluster Storage のインストール

    以下のコマンドを実行して Red Hat Gluster Storage をインストールします。

    # yum install redhat-storage-server
  3. gluster-block を有効にするには、以下のコマンドを実行します。

    # yum install gluster-block
  4. 再起動

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

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. カーネルモジュールの有効化

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

  1. 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
  2. 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 のデプロイ

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

    [OSEv3:children]
    masters
    etcd
    nodes
    glusterfs
  2. [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単位のボリュームのサイズです。

  3. 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" ]'
  4. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {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
  5. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。各クラスターの Red Hat Gluster Storage ノードのいずれかで以下のコマンドを実行して、brick-multiplexing を有効にします。

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

      # 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
    2. 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 をインデペンデントモードでデプロイする

  1. インベントリーファイルの [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 を設定してください。

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

    [OSEv3:children]
    ...
    glusterfs
    glusterfs_registry
  3. [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" ]'
  4. 上記の手順では、より大きな完全なインベントリファイルに追加する必要のあるオプションについて詳しく説明しています。完全なインベントリーファイルを使用して {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.5. 単一の OCS クラスターのインストール

単一の OCS クラスターで、汎用アプリケーションストレージとインフラストラクチャーストレージの両方をサポートすることが可能です。これを実行するには、インベントリファイルのオプションが、ログとメトリックスでわずかに変更されます。これは、クラスターが 1 つしかない場合、gluster-block StorageClassglusterfs-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 ストレージクラスを削除し、再作成します。

  1. ストレージクラスオブジェクトを yaml ファイルにエクスポートします。

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

    # oc delete sc glusterfs-storage
    # oc create -f glusterfs-storage.yaml

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

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

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

    1. 以下のコマンドを実行して、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
    2. 以下のコマンドを実行して、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
  2. インデペンデントモード用のストレージプロビジョニングの検証

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

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

      2 つの PVC とそれぞれの PV が適切に作成されていることを確認します。

      # oc get pvc
  3. 検証に heketi-client を使用する

    1. 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: 5Gi

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

注記

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

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

  1. 以下の環境変数および値を追加して、Heketi デプロイメント設定の Glusterfs セクションの下にある設定ファイルを編集します。

    HEKETI_BLOCK_HOSTING_VOLUME_OPTIONS: group gluster-block,user.heketi.arbiter true
  2. Heketi CLI を使用してブロックボリュームを作成します。

      # heketi-cli blockvolume create --size=100
  3. ブロックホスティングボリュームが 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.ioregistry.access.redhat.comに置き換えます(該当する場合)。
  • 同じアップグレード手順に従って、インデペンデントモード 3.11.0 以上からコンバージドモード 3.11.8 の Red Hat Openshift Container Storage にお使いの環境をアップグレードしてください。アップグレードプロセスを開始する前に、正しいイメージとバージョン番号が設定されていることを確認してください。
  • Red Hat Openshift Container Storage 3.11.8 の有効なイメージは以下のとおりです。

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

6.1. glusterfs グループの Pod のアップグレード

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

6.1.1. 前提条件

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

注記

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

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

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

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

6.1.2. /dev/log の元のラベル値の復元

注記

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

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

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

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

    # mkdir /srv/<directory_name>
    # cd /srv/<directory_name>/   # same dir as above
    # ln -sf /dev/null systemd-tmpfiles-setup-dev.service
    # ln -sf /dev/null systemd-journald.service
    # ln -sf /dev/null systemd-journald.socket
  2. oc クライアントを持つノードで glusterfs Pod を作成する daemonset を編集します。

    # oc edit daemonset <daemonset_name>

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

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

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

    注記

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

    - hostPath:
       path: /srv/<directory_name>/systemd-journald.socket
       type: ""
      name: systemd-journald-socket
    - hostPath:
       path: /srv/<directory_name>/systemd-journald.service
       type: ""
      name: systemd-journald-service
    - hostPath:
       path: /srv/<directory_name>/systemd-tmpfiles-setup-dev.service
       type: ""
    name: systemd-tmpfiles-setup-dev-service
  3. gluster Pod を実行するすべてのノードで以下のコマンドを実行します。これにより、ラベルがリセットされます。

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

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

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

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

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

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

    注記

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

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

    # gluster volume set all cluster.max-bricks-per-process 250
    1. gluster Pod のいずれかで以下のコマンドを実行し、オプションが正しく設定されていることを確認します。

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

      以下は例になります。

      # gluster volume get all cluster.max-bricks-per-process
      cluster.max-bricks-per-process 250
  7. oc クライアントがあるノードで以下のコマンドを実行し、gluster Pod を削除します。

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

    # oc get pods -l glusterfs=storage-pod
  9. Pod をホストするノードにログインし、/dev/log の selinux ラベルを確認します。

    # ls -lZ /dev/log

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

    以下は例になります。

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

    ノードを終了します。

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

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

    以下は例になります。

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

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

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

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

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

    # yum update cns-deploy -y
    # yum update heketi-client -y
  2. Heketi データベースファイルのバックアップを作成します。

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
    • 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

      oc get secret <heketi-admin-secret> -o jsonpath='{.data.key}'|base64 -d;echo
  3. 以下のコマンドを実行して、heketi テンプレートを削除します。

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

    oc create -f /usr/share/heketi/templates/heketi-template.yaml
    template "heketi" created
  5. 以下のコマンドを実行して、heketi サービスアカウントに必要な権限を付与します。

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

    以下に例を示します。

    # oc policy add-role-to-user edit system:serviceaccount:storage-project:heketi-service-account
    # oc adm policy add-scc-to-user privileged -z heketi-service-account
  6. 以下のコマンドを実行して、新しい heketi 設定ファイルを生成します。

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

      注記

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

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

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

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

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

    # oc delete deploymentconfig,service,route heketi
    注記

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

    # oc get all | grep heketi
  9. heketi テンプレートを編集します。

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

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

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

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

      - description: Heketi can use a wrapper to execute LVM commands, i.e. run commands
      in the host namespace instead of in the Gluster container.
      displayName: Wrapper for executing LVM commands
      name: HEKETI_LVM_WRAPPER
      value: /usr/sbin/exec-on-host
    • HEKETI_DEBUG_UMOUNT_FAILURES という名前で、値が true の ENV を追加します。

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

      - displayName: heketi container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
      - displayName: heketi container image version
        name: IMAGE_VERSION
        required: true
        value: v3.11.8
  10. 以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。

    # oc process heketi | oc create -f -
    
      service "heketi" created
      route "heketi" created
    deploymentconfig "heketi" created
    注記

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

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

    # oc get pods

    以下は例になります。

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

6.1.3.2. Red Hat Gluster Storage Pod のアップグレード

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

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

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

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

      # oc project <project_name>

      以下は例になります。

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

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

      # heketi-cli server mode set local-client
    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。

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

      # oc scale dc <heketi_dc> --replicas=0
    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。

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

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

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

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

    以下に例を示します。

    # oc delete ds glusterfs --cascade=false
    daemonset "glusterfs" deleted
  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。

    # oc delete templates glusterfs

    以下に例を示します。

    # oc delete templates glusterfs
    template “glusterfs” deleted
  6. 以下のコマンドを実行して、新しい glusterfs テンプレートを登録します。

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

    以下に例を示します。

    # oc create -f /usr/share/heketi/templates/glusterfs-template.yaml
      template “glusterfs” created
  7. Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。

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

      # oc get nodes -l glusterfs=storage-host
  8. glusterfs テンプレートを編集します。

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

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

       - name: kernel-modules
         mountPath: "/usr/lib/modules"
         readOnly: true
       - name: host-rootfs
         mountPath: "/rootfs"
    • ボリュームの下に以下の行を追加します。

       - name: kernel-modules
         hostPath:
         path: "/usr/lib/modules"
       - name: host-rootfs
         hostPath:
         path: "/"
    • アップグレードするバージョンに応じて、IMAGE_VERSION の下の valuev3.11.5 または v3.11.8 に置き換えます。

      - displayName: heketi container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
      - displayName: heketi container image version
        name: IMAGE_VERSION
        required: true
        value: v3.11.8
  9. 以下のコマンドを実行して、gluster DaemonSet を作成します。

    # oc process glusterfs | oc create -f -

    以下に例を示します。

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

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

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

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  11. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。

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

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

    注記

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

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

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

      # oc delete pod <gluster_pod>

      以下に例を示します。

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

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

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

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

        # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"
    2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。

      # oc get pods -w
        NAME                             READY     STATUS        RESTARTS   AGE
        glusterfs-0vcf3                  1/1       Terminating   0          3d
      …
  13. 以下のコマンドを実行して、Pod が実行していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  14. 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。

    # oc rsh <gluster_pod_name> glusterd --version

    以下は例になります。

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

    # gluster vol get all cluster.op-version
  16. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

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

      # oc scale dc <heketi_dc> --replicas=1
  17. いずれかの Pod で cluster.op-version を 70200 に設定します。

    重要

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

    # gluster --timeout=3600 volume set all cluster.op-version 70200
    • 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

      注記

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

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

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

        # oc get pods

        以下は例になります。

        # oc get pods
        NAME                                          READY     STATUS    RESTARTS   AGE
        glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
        glusterfs-storage-5thpc                       1/1       Running   0          9d
        glusterfs-storage-hfttr                       1/1       Running   0          9d
        glusterfs-storage-n8rg5                       1/1       Running   0          9d
        heketi-storage-4-9fnvz                        2/2       Running   0          8d
      2. glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。

        # oc rsh glusterfs-0vcf3
      3. 以下のコマンドを実行します。

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

        以下は例になります。

        # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
          volume1
          volume set: success
          volume2
        volume set: success
  18. gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

    # oc delete dc glusterblock-provisioner-dc

    以下は例になります。

    # oc delete dc glusterblock-storage-provisioner-dc
  19. 古い Pod から以下のリソースを削除します。

    # oc delete clusterroles.authorization.openshift.io glusterblock-provisioner-runner
    # oc delete serviceaccounts glusterblock-provisioner
    serviceaccount "glusterblock-provisioner" deleted
    # oc delete clusterrolebindings.authorization.openshift.io glusterblock-provisioner
  20. 以下のコマンドを実行して、gluster-block プロビジョナーをデプロイします。

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

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

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

    以下は例になります。

    `sed -e 's/${NAMESPACE}/storage-project/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | sed -e 's/3.11.4/3.11.8/' | oc create -f -
    # oc adm policy add-cluster-role-to-user glusterblock-provisioner-runner system:serviceaccount:storage-project:glusterblock-provisioner
  21. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

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

      # oc rsh <gluster_pod_name>
    2. ブリックの多重化ステータスを確認します。

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

      注記

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

      # gluster volume set all cluster.brick-multiplex on

      以下は例になります。

      # oc rsh glusterfs-770ql
      
        sh-4.2# gluster volume set all cluster.brick-multiplex on
        Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
      volume set: success
    4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

      以下は例になります。

      # gluster volume list
      
        heketidbstorage
        vol_194049d2565d2a4ad78ef0483e04711e
        ...
        ...

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

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

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

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

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

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

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

      # oc project <project_name>

      以下は例になります。

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

      # heketi-cli server operations info
  2. Heketi データベースファイルのバックアップを作成します。

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

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

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

    # yum update heketi-client -y
  4. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

    # oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
  5. HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。

    # oc describe pod <heketi-pod>
  6. 以下のコマンドを実行して、heketi テンプレートを削除します。

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/heketi-template.yml
    template "heketi" created
  8. 以下の手順を実行して、テンプレートを編集します。

    # oc get templates
    NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
    glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
    			  template
    glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
    			  template
    heketi			  Heketi service deployment  7 (3 blank)	3
    template
    1. 既存のテンプレートに 2 つのパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合は、テンプレートを編集して HEKETI_USER_KEY、HEKETI_ADMIN_KEY、HEKETI_ROUTE、IMAGE_NAME、IMAGE_VERSION、CLUSTER_NAME および HEKETI_LVM_WRAPPER を以下の例のように変更します。

      # oc edit template heketi
      parameters:
        - description: Set secret for those creating volumes as type user
        displayName: Heketi User Secret
        name: HEKETI_USER_KEY
        value: <heketiuserkey>
        - description: Set secret for administration of the Heketi service as user admin
        displayName: Heketi Administrator Secret
        name: HEKETI_ADMIN_KEY
        value: <adminkey>
        - description: Set the executor type, kubernetes or ssh
        displayName: heketi executor type
        name: HEKETI_EXECUTOR
        value: kubernetes
        - description: Set the hostname for the route URL
        displayName: heketi route name
        name: HEKETI_ROUTE
        value: heketi-storage
        - displayName: heketi container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
        - displayName: heketi container image version
        name: IMAGE_VERSION
        required: true
        value: v3.11.8
        - description: A unique name to identify this heketi service, useful for running
        multiple heketi instances
        displayName: GlusterFS cluster name
        name: CLUSTER_NAME
        value: storage
        - description: Heketi can use a wrapper to execute LVM commands, i.e. run commands in the host namespace instead of in the Gluster container
        name: HEKETI_LVM_WRAPPER
        displayName: Wrapper for executing LVM commands
        value: /usr/sbin/exec-on-host
    2. テンプレートに IMAGE_NAME のみがある場合は、テンプレートを編集して HEKETI_USER_KEY、HEKETI_ADMIN_KEY、HEKETI_ROUTE、IMAGE_NAME, CLUSTER_NAME および HEKETI_LVM_WRAPPER を以下の例のように変更します。

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

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

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

    注記

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

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

    # oc process heketi | oc create -f -
    
    service "heketi" created
    route "heketi" created
    deploymentconfig "heketi" created
    注記

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

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

    # oc get pods

    以下は例になります。

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

6.1.4.2. Red Hat Gluster Storage Pod のアップグレード

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

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

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

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

      # oc project <project_name>

      以下は例になります。

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

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

      # heketi-cli server mode set local-client
    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。

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

      # oc scale dc <heketi_dc> --replicas=0
    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。

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

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

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

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

    以下に例を示します。

    # oc delete ds glusterfs-storage --cascade=false
    daemonset "glusterfs-storage" deleted
  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterfs-template.yml
    template "glusterfs" created
  7. 以下のコマンドを実行して、古い glusterfs テンプレートを編集します。

    # oc get templates
    NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
    glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
            template
    glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
            template
    heketi			  Heketi service deployment  7 (3 blank)	3
    template
    1. テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterfs テンプレートを更新します。以下は例になります。

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

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

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

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

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

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

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

      # oc get nodes -l glusterfs=storage-host
  9. 以下のコマンドを実行して、gluster DaemonSet を作成します。

    # oc process glusterfs | oc create -f -

    以下に例を示します。

    # oc process glusterfs | oc create -f -
    Deamonset “glusterfs” created
    • 以下のコマンドを実行して、削除する必要のある古い gluster Pod を特定します。

      # oc get pods

      以下に例を示します。

      # oc get pods
      NAME                                          READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
      glusterfs-storage-5thpc                       1/1       Running   0          9d
      glusterfs-storage-hfttr                       1/1       Running   0          9d
      glusterfs-storage-n8rg5                       1/1       Running   0          9d
      heketi-storage-4-9fnvz                        2/2       Running   0          8d
  10. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。

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

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

    注記

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

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

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

      # oc delete pod <gluster_pod>

      以下に例を示します。

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

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

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

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

        # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"
    2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。

      # oc get pods -w
      NAME                             READY     STATUS        RESTARTS   AGE
      glusterfs-0vcf3                  1/1       Terminating   0          3d
      …
  12. 以下のコマンドを実行して、Pod が実行していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  13. 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。

    # oc rsh <gluster_pod_name> glusterd --version

    以下は例になります。

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

    # gluster vol get all cluster.op-version
  15. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

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

      # oc scale dc <heketi_dc> --replicas=1
  16. いずれかの Pod で cluster.op-version を 70200 に設定します。

    注記

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

    # gluster --timeout=3600 volume set all cluster.op-version 70200
  17. 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

    注記

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

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

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

      # oc get pods

      以下は例になります。

      # oc get pods
      NAME                                          READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
      glusterfs-storage-5thpc                       1/1       Running   0          9d
      glusterfs-storage-hfttr                       1/1       Running   0          9d
      glusterfs-storage-n8rg5                       1/1       Running   0          9d
      heketi-storage-4-9fnvz                        2/2       Running   0          8d
    2. glusterfs Pod のいずれかにリモートシェルを実行します。以下は例になります。

      # oc rsh glusterfs-0vcf3
    3. 以下のコマンドを実行します。

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

      以下は例になります。

      # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
          volume1
          volume set: success
          volume2
      volume set: success
  18. gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

    # oc delete dc glusterblock-provisioner-dc

    以下は例になります。

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

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml
    template.template.openshift.io/glusterblock-provisioner created
  21. OCP のバージョンに応じて、glusterblock-provisioner テンプレートを編集して IMAGE_NAME、IMAGE_VERSION および NAMESPACE を変更します。

    # oc get templates
    NAME			  DESCRIPTION		     PARAMETERS		OBJECTS
    glusterblock-provisioner  glusterblock provisioner   3 (2 blank)	4
            template
    glusterfs		  GlusterFS DaemonSet 	     5 (1 blank)	1
            template
    heketi			  Heketi service deployment  7 (3 blank)	3
    template
    1. テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterblock-provisioner テンプレートを更新します。以下は例になります。

      # oc edit template glusterblock-provisioner
      - displayName: glusterblock provisioner container image name
      name: IMAGE_NAME
      required: true
      value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7
      - displayName: glusterblock provisioner container image version
      name: IMAGE_VERSION
      required: true
      value: v3.11.8
      - description: The namespace in which these resources are being created
      displayName: glusterblock provisioner namespace
      name: NAMESPACE
      required: true
      value: glusterfs
      - description: A unique name to identify which heketi service manages this cluster,
        useful for running multiple heketi instances
      displayName: GlusterFS cluster name
      name: CLUSTER_NAME
      value: storage
    2. テンプレートに、パラメーターとして IMAGE_NAME しかない場合、以下のように glusterblock-provisioner テンプレートを更新します。以下は例になります。

      # oc edit template glusterblock-provisioner
      - displayName: glusterblock provisioner container image name
      name: IMAGE_NAME
      required: true
      value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
      - description: The namespace in which these resources are being created
      displayName: glusterblock provisioner namespace
      name: NAMESPACE
      required: true
      value: glusterfs
      - description: A unique name to identify which heketi service manages this cluster,
                  useful for running multiple heketi instances
      displayName: GlusterFS cluster name
      name: CLUSTER_NAME
      value: storage
  22. 古い Pod から以下のリソースを削除します。

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

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

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

    以下は例になります。

    # oc process glusterblock-provisioner -o yaml | oc create -f -
    clusterrole.authorization.openshift.io/glusterblock-provisioner-runner created
    serviceaccount/glusterblock-storage-provisioner created
    clusterrolebinding.authorization.openshift.io/glusterblock-storage-provisioner created
    deploymentconfig.apps.openshift.io/glusterblock-storage-provisioner-dc created
  25. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

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

      # oc rsh <gluster_pod_name>
    2. ブリックの多重化ステータスを確認します。

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

      注記

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

      # gluster volume set all cluster.brick-multiplex on

      以下は例になります。

      # oc rsh glusterfs-770ql
      sh-4.2# gluster volume set all cluster.brick-multiplex on
      Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
      volume set: success
    4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

      以下は例になります。

      # gluster volume list
      
      heketidbstorage
      vol_194049d2565d2a4ad78ef0483e04711e
      ...
      ...

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

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

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

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

    例:

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

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

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

    例:

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

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

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

6.2.1. 前提条件

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

注記

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

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

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

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

6.2.2. /dev/log の元のラベル値の復元

注記

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

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

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

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

    # mkdir /srv/<directory_name>
    # cd /srv/<directory_name>/   # same dir as above
    # ln -sf /dev/null systemd-tmpfiles-setup-dev.service
    # ln -sf /dev/null systemd-journald.service
    # ln -sf /dev/null systemd-journald.socket
  2. oc クライアントを持つノードで glusterfs Pod を作成する daemonset を編集します。

    # oc edit daemonset <daemonset_name>

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

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

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

    注記

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

    - hostPath:
       path: /srv/<directory_name>/systemd-journald.socket
       type: ""
      name: systemd-journald-socket
    - hostPath:
       path: /srv/<directory_name>/systemd-journald.service
       type: ""
      name: systemd-journald-service
    - hostPath:
       path: /srv/<directory_name>/systemd-tmpfiles-setup-dev.service
       type: ""
    name: systemd-tmpfiles-setup-dev-service
  3. gluster Pod を実行するすべてのノードで以下のコマンドを実行します。これにより、ラベルがリセットされます。

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

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

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

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

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

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

    注記

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

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

    # gluster volume set all cluster.max-bricks-per-process 250
    1. gluster Pod のいずれかで以下のコマンドを実行し、オプションが正しく設定されていることを確認します。

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

      以下は例になります。

      # gluster volume get all cluster.max-bricks-per-process
      cluster.max-bricks-per-process 250
  7. oc クライアントがあるノードで以下のコマンドを実行し、gluster Pod を削除します。

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

    # oc get pods -l glusterfs=registry-pod
  9. Pod をホストするノードにログインし、/dev/log の selinux ラベルを確認します。

    # ls -lZ /dev/log

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

    以下は例になります。

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

    ノードを終了します。

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

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

    以下は例になります。

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

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

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

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

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

    # yum update cns-deploy -y
    # yum update heketi-client -y
  2. Heketi レジストリーデータベースファイルをバックアップします。

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
  3. 以下のコマンドを実行して、heketi テンプレートを削除します。

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

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

    # oc get secret <heketi-admin-secret-name> -o jsonpath='{.data.key}'|base64 -d;echo
  5. 以下のコマンドを実行して、heketi テンプレートをインストールします。

    # oc create -f /usr/share/heketi/templates/heketi-template.yaml
    template "heketi" created
  6. 以下のコマンドを実行して、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)のアカウントにだけ付与されます。

  7. 以下のコマンドを実行して、新しい 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 フォーマットが厳密に必要とされています(末尾にスペースを入れない、ブール値はすべて小文字など)。

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

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

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

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

    # oc delete deploymentconfig,service,route heketi-registry
  10. 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 の下の valuev3.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
  11. 以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

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

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

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

      # oc project <project_name>

      以下は例になります。

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

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

      # heketi-cli server mode set local-client
    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。

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

      # oc scale dc <heketi_dc> --replicas=0
    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。

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

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

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

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

    以下に例を示します。

    # oc delete ds glusterfs-registry --cascade=false
    daemonset "glusterfs-registry" deleted
  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。

    # oc delete templates glusterfs

    以下に例を示します。

    # oc delete templates glusterfs
    template “glusterfs” deleted
  6. Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。

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

      # oc get nodes -l glusterfs=registry-host
  7. 以下のコマンドを実行して、新しい glusterfs テンプレートを登録します。

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

    以下に例を示します。

    # oc create -f /usr/share/heketi/templates/glusterfs-template.yaml
    template “glusterfs” created
  8. glusterfs テンプレートを編集します。

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

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

       - name: kernel-modules
         mountPath: "/usr/lib/modules"
         readOnly: true
       - name: host-rootfs
         mountPath: "/rootfs"
    • ボリュームの下に以下の行を追加します。

       - name: kernel-modules
         hostPath:
         path: "/usr/lib/modules"
       - name: host-rootfs
         hostPath:
         path: "/"
    • アップグレードするバージョンに応じて、IMAGE_VERSION の下の valuev3.11.5 または v3.11.8 に置き換えます。

      - displayName: heketi container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
      - displayName: heketi container image version
        name: IMAGE_VERSION
        required: true
        value: v3.11.8
  9. 以下のコマンドを実行して、gluster DaemonSet を作成します。

    # oc process glusterfs | oc create -f -

    以下に例を示します。

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

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

  10. 以下のコマンドを実行して、削除する必要のある古い 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
  11. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。

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

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

    注記

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

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

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

      # oc delete pod <gluster_pod>

      以下に例を示します。

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

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

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

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

        # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"
    2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。

      # oc get pods -w
      NAME                             READY     STATUS        RESTARTS   AGE
      glusterfs-0vcf3                  1/1       Terminating   0          3d
      …
  13. 以下のコマンドを実行して、Pod が実行していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
    • 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。

      # oc rsh <gluster_registry_pod_name> glusterd --version

      以下は例になります。

       # oc rsh glusterfs-registry-4cpcc glusterd --version
      glusterfs 6.0
      # rpm -qa|grep gluster
  14. glusterfs-registry Pod のいずれかで以下のコマンドを実行して、Red Hat Gluster Storage op-version を確認します。

    # gluster vol get all cluster.op-version
  15. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

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

      # oc scale dc <heketi_dc> --replicas=1
  16. いずれかの Pod で cluster.op-version を 70200 に設定します。

    注記

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

    # gluster volume set all cluster.op-version 70200
  17. 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

    注記

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

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

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

      # oc get pods

      以下は例になります。

      # oc get pods
      NAME                                          READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
      glusterfs-storage-5thpc                       1/1       Running   0          9d
      glusterfs-storage-hfttr                       1/1       Running   0          9d
      glusterfs-storage-n8rg5                       1/1       Running   0          9d
      heketi-storage-4-9fnvz                        2/2       Running   0          8d
    2. glusterfs-registry Pod のいずれかにリモートシェルを実行します。以下は例になります。

      # oc rsh glusterfs-registry-g6vd9
    3. 以下のコマンドを実行します。

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

      以下は例になります。

      # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
      volume1
      volume set: success
      volume2
      volume set: success
  18. gluster-block-registry-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

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

    以下は例になります。

    # oc delete dc glusterblock-registry-provisioner-dc
  19. 古い Pod から以下のリソースを削除します。

    # oc delete clusterroles.authorization.openshift.io glusterblock-provisioner-runner
    # oc delete serviceaccounts glusterblock-provisioner
    serviceaccount "glusterblock-provisioner" deleted
    # oc delete clusterrolebindings.authorization.openshift.io glusterblock-provisioner
  20. 以下のコマンドを実行して、gluster-block プロビジョナーをデプロイします。

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

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

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

    以下は例になります。

    `sed -e 's/${NAMESPACE}/storage-project/' /usr/share/heketi/templates/glusterblock-provisioner.yaml | sed -e 's/3.11.4/3.11.8/' | oc create -f -
    # oc adm policy add-cluster-role-to-user glusterblock-provisioner-runner system:serviceaccount:storage-project:glusterblock-provisioner
  21. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

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

      # oc rsh <gluster_pod_name>
    2. ブリックの多重化ステータスを確認します。

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

      注記

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

      # gluster volume set all cluster.brick-multiplex on

      以下は例になります。

      # oc rsh glusterfs-registry-g6vd9
      
      sh-4.2# gluster volume set all cluster.brick-multiplex on
      Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
      volume set: success
    4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

      以下は例になります。

      # gluster volume list
      
      heketidbstorage
      vol_194049d2565d2a4ad78ef0483e04711e
      ...
      ...

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

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

    注記

    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」を実行する必要はありません。

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

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

      # oc project <project_name>

      以下は例になります。

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

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

      # heketi-cli server mode set local-client
    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。

      # heketi-cli server operations info
  2. Heketi データベースファイルのバックアップを作成します。

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

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

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

    # yum update heketi-client -y
  4. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

    # oc get secret heketi-registry-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
  5. HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。

    # oc describe pod <heketi-pod>
  6. 以下の手順を実行して、テンプレートを編集します。

    1. テンプレートに既存の 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. 既存のテンプレートに 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 を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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

    # oc delete deploymentconfig,service,route heketi-registry
  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 のボリュームセット操作を実行します。

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

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

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

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

      # oc project <project_name>

      以下は例になります。

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

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

      # heketi-cli server mode set local-client
    4. 継続中の操作が完了するまで待機し、以下のコマンドを実行し、継続中の操作があるかどうかを監視します。

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

      # oc scale dc <heketi_dc> --replicas=0
    6. 以下のコマンドを実行して、heketi Pod が表示されなくなったことを確認します。

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

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

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

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

    以下に例を示します。

    # oc delete ds glusterfs-registry --cascade=false
    daemonset "glusterfs-registry" deleted
  4. 以下のコマンドを実行して、古い Pod すべてが起動していることを確認します。

    # oc get pods

    以下に例を示します。

    # oc get pods
    NAME                                          READY     STATUS    RESTARTS   AGE
    glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
    glusterfs-storage-5thpc                       1/1       Running   0          9d
    glusterfs-storage-hfttr                       1/1       Running   0          9d
    glusterfs-storage-n8rg5                       1/1       Running   0          9d
    heketi-storage-4-9fnvz                        2/2       Running   0          8d
  5. 以下のコマンドを実行して、古い glusterfs テンプレートを削除します。

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterfs-template.yml
    template "glusterfs" created
  7. 以下のコマンドを実行して、古い glusterfs テンプレートを編集します。

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

      # oc edit template glusterfs
      
      - description: Labels which define the daemonset node selector. Must contain at least
          one label of the format \'glusterfs=<CLUSTER_NAME>-host\'
        displayName: Daemonset Node Labels
        name: NODE_LABELS
        value: '{ "glusterfs": "registry-host" }'
      - displayName: GlusterFS container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.8
      - description: A unique name to identify which heketi service manages this cluster,
          useful for running multiple heketi instances
        displayName: GlusterFS cluster name
        name: CLUSTER_NAME
        value: registry
    2. テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterfs テンプレートを更新します。以下は例になります。

      # oc edit template glusterfs
      - description: Labels which define the daemonset node selector. Must contain at least one label of the format \'glusterfs=<CLUSTER_NAME>-host\'
      displayName: Daemonset Node Labels
      name: NODE_LABELS
      value: '{ "glusterfs": "registry-host" }'
      - displayName: GlusterFS container image name
      name: IMAGE_NAME
      required: true
      value: registry.redhat.io/rhgs3/rhgs-server-rhel7
      - description: A unique name to identify which heketi service manages this cluster,
      useful for running multiple heketi instances
      - displayName: GlusterFS container image version
      name: IMAGE_VERSION
      required: true
      value: v3.11.8
      - displayName: GlusterFS cluster name
      name: CLUSTER_NAME
      value: registry
      注記
  8. Red Hat Gluster Storage Pod を持つすべての OpenShift Container Platform ノードにラベルを付けます。

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

      # oc get nodes -l glusterfs=registry-host
  • name: kernel-modules mountPath: "/usr/lib/modules" readOnly: true
  • name: host-rootfs mountPath: "/rootfs"
  • name: kernel-modules hostPath: path: "/usr/lib/modules"
  • name: host-rootfs hostPath: path: "/"
  • displayName: heketi container image name name: IMAGE_NAME required: true value: registry.redhat.io/rhgs3/rhgs-volmanager-rhel7
  • displayName: heketi container image version name: IMAGE_VERSION required: true value: v3.11.8

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

      # oc process glusterfs | oc create -f -

      以下に例を示します。

      # oc process glusterfs | oc create -f -
      Deamonset “glusterfs-registry” created
    2. 以下のコマンドを実行して、削除する必要のある古い glusterfs_registry Pod を特定します。

      # oc get pods

      以下に例を示します。

      # oc get pods
      NAME                                          READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
      glusterfs-storage-5thpc                       1/1       Running   0          9d
      glusterfs-storage-hfttr                       1/1       Running   0          9d
      glusterfs-storage-n8rg5                       1/1       Running   0          9d
      heketi-storage-4-9fnvz                        2/2       Running   0          8d
    3. 以下のコマンドを実行して、ブリックが 90% を超えていないことを確認します。

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

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

      注記

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

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

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

        # oc delete pod <gluster_pod>

        以下に例を示します。

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

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

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

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

          # for eachVolume in $(gluster volume list);  do gluster volume heal $eachVolume info ;  done | grep "Number of entries: [^0]$"
      2. delete pod コマンドは古い Pod を終了し、新しい Pod を作成します。# oc get pods -w を実行して Pod の Age を確認すると、READY ステータスが 1/1 になっているはずです。以下は、Pod の終了から作成までのステータスの進行を示す出力例です。

        # oc get pods -w
        NAME                             READY     STATUS        RESTARTS   AGE
        glusterfs-registry-4cpcc                  1/1       Terminating   0          3d
        …
    5. 以下のコマンドを実行して、Pod が実行していることを確認します。

      # oc get pods

      以下に例を示します。

      # oc get pods
      NAME                                          READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
      glusterfs-storage-5thpc                       1/1       Running   0          9d
      glusterfs-storage-hfttr                       1/1       Running   0          9d
      glusterfs-storage-n8rg5                       1/1       Running   0          9d
      heketi-storage-4-9fnvz                        2/2       Running   0          8d
    6. 以下のコマンドを実行して、Pod を最新バージョンにアップグレードしているかどうかを確認します。

      # oc rsh <gluster_registry_pod_name> glusterd --version

      以下は例になります。

      # oc rsh glusterfs-registry-abmqa glusterd --version
      glusterfs 6.0
      # rpm -qa|grep gluster
    7. glusterfs-registry Pod のいずれかで以下のコマンドを実行して、Red Hat Gluster Storage op-version を確認します。

      # gluster vol get all cluster.op-version
    8. Gluster Podをアップグレードした後、Heketiを操作モードの設定に戻したことを確認してください。

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

        # oc scale dc <heketi_dc> --replicas=1
    9. いずれかの Pod で cluster.op-version を 70200 に設定します。

      注記

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

      # gluster volume set all cluster.op-version 70200
    10. 以下の手順を実行して、すべてのボリュームでserver.tcp-user-timeoutを有効にします。

      注記

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

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

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

        # oc get pods

        以下は例になります。

        # oc get pods
        NAME                                          READY     STATUS    RESTARTS   AGE
        glusterblock-storage-provisioner-dc-1-ffgs5   1/1       Running   0          3m
        glusterfs-storage-5thpc                       1/1       Running   0          9d
        glusterfs-storage-hfttr                       1/1       Running   0          9d
        glusterfs-storage-n8rg5                       1/1       Running   0          9d
        heketi-storage-4-9fnvz                        2/2       Running   0          8d
      2. glusterfs-registry Pod のいずれかにリモートシェルを実行します。以下は例になります。

        # oc rsh glusterfs-registry-g6vd9
      3. 以下のコマンドを実行します。

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

        以下は例になります。

        # for eachVolume in `gluster volume list`; do echo $eachVolume; gluster volume set $eachVolume server.tcp-user-timeout 42 ; done
        volume1
        volume set: success
        volume2
        volume set: success
    11. gluster-block-registry-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

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

      以下は例になります。

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

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

      # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml
      template.template.openshift.io/glusterblock-provisioner created
    14. OCP のバージョンに応じて、glusterblock-provisioner テンプレートを編集して IMAGE_NAME および NAMESPACE を変更します。

      # oc edit template glusterblock-provisioner
      - displayName: glusterblock provisioner container image name
        name: IMAGE_NAME
        required: true
        value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.8
      - description: The namespace in which these resources are being created
        displayName: glusterblock provisioner namespace
        name: NAMESPACE
        required: true
        value: glusterfs-registry
      - description: A unique name to identify which heketi service manages this cluster, useful for running multiple heketi instances
        displayName: GlusterFS cluster name
        name: CLUSTER_NAME
        value: registry
      • テンプレートに、2 つの別個のパラメーターとして IMAGE_NAME と IMAGE_VERSION がある場合、以下のように glusterblock-provisioner テンプレートを更新します。
        以下は例になります。

        # oc edit template glusterblock-provisioner
        
        - displayName: glusterblock provisioner container image name
          name: IMAGE_NAME
          required: true
          value: registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7
        - displayName: glusterblock provisioner container image version
          name: IMAGE_VERSION
          required: true
          value: v3.11.8
        - description: The namespace in which these resources are being created
          displayName: glusterblock provisioner namespace
          name: NAMESPACE
          required: true
          value: glusterfs-registry
        - description: A unique name to identify which heketi service manages this cluster,
          useful for running multiple heketi instances
          displayName: GlusterFS cluster name
          name: CLUSTER_NAME
          value: registry
    15. 古い Pod から以下のリソースを削除します。

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

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

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

      以下は例になります。

      # oc process glusterblock-provisioner -o yaml | oc create -f -
      clusterrole.authorization.openshift.io/glusterblock-provisioner-runner created
      serviceaccount/glusterblock-registry-provisioner created
      clusterrolebinding.authorization.openshift.io/glusterblock-registry-provisioner created
      deploymentconfig.apps.openshift.io/glusterblock-registry-provisioner-dc created
    18. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。これは、Container-Native Storage 3.6 以降でデフォルトで有効になっています。Container-Native Storage 3.10 から Red Hat Openshift Container Storage 3.11 へのアップグレード中に、ブリックの多重化をオンにするには、以下のコマンドを実行します。

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

        # oc rsh <gluster_pod_name>
      2. ブリックの多重化ステータスを確認します。

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

        注記

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

        # gluster volume set all cluster.brick-multiplex on

        以下は例になります。

        # oc rsh glusterfs-registry-g6vd9
        
        sh-4.2# gluster volume set all cluster.brick-multiplex on
        Brick-multiplexing is supported only for container workloads (Independent or Converged mode). Also it is advised to make sure that either all volumes are in stopped state or no bricks are running before this option is modified.Do you still want to continue? (y/n) y
        volume set: success
      4. 信頼できるストレージプール内のすべてのボリュームを一覧表示します。この手順は、ボリュームセットの操作が実行される場合にのみ必要です。

        以下は例になります。

        # gluster volume list
        
        heketidbstorage
        vol_194049d2565d2a4ad78ef0483e04711e
        ...
        ...

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

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

      注記

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

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

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

      例:

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

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

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

      例:

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

6.3. Heketi Pod の起動

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

  1. 以下のコマンドを実行して、Heketi Pod が実行されているプロジェクトに移動します。

    # oc project <project_name>

    glusterfs namespace の場合は以下を実行します。

    # oc project glusterfs

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

    # oc project glusterfs-registry
  2. 以下のコマンドを実行して、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
  3. 以下のコマンドを実行して、レプリカ数を 0 から 1 に増やします。これにより、Heketi Pod が戻ります。

    # oc scale dc <heketi_dc> --replicas=1
  4. 以下のコマンドを実行して、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 ノードでのクライアントのアップグレード

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

  1. Pod をドレインするには、マスターノード(または cluster-admin アクセスを持つ任意のノード)で、以下のコマンドを実行します。

    # oc adm drain <node_name> --ignore-daemonsets
  2. すべての Pod がドレインされていることを確認するには、マスターノード (または cluster-admin アクセスを持つ任意のノード) で以下のコマンドを実行します。

    # oc get pods --all-namespaces --field-selector=spec.nodeName=<node_name>
  3. 以下のコマンドを実行して、クライアントノードを最新の glusterfs-fuse バージョンにアップグレードします。

    # yum update glusterfs-fuse
  4. Pod のスケジューリングのノードを有効にするには、マスターノード(または cluster-admin アクセスを持つ任意のノード)で以下のコマンドを実行します。

    # oc adm manage-node --schedulable=true <node_name>
  5. 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
  6. 以下のコマンドを実行して、マルチパスデーモンを起動し、マルチパス設定を(再)読み込みします。

    # systemctl start multipathd
    # systemctl reload multipathd

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

注記

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

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

注記

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

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

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

  • openshift_storage_glusterfs_image
  • openshift_storage_glusterfs_heketi_image
  • openshift_storage_glusterfs_block_image
  • openshift_storage_glusterfs_fuse_version

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

  • openshift_storage_glusterfs_health_timeout=10: この変数で、クラスターのヘルスチェックの再試行回数が制限されます。変数の値は 10 の倍数でなければならず、10 は 1 つの再試行、20 は 2 つの再試行を意味します。この値は 10 未満にしないでください。この var のデフォルト値は 30 であるため、何も指定せず、Playbook は 3 回再試行します。
  • openshift_storage_gluster_update_techpreview=true: Playbook はテクノロジープレビュー機能です。アップグレード Playbook を使用するには、この変数を true に設定します。
  • openshift_storage_glusterfs_fuse_version=<version>: ノードを特定のクライアントパッケージにアップグレードするには、アップグレードするバージョンを指定する必要があります。
    の例:
 openshift_storage_glusterfs_fuse_version=-3.12.2-18.el7
  • openshift_storage_glusterfs_check_brick_size_health=false: Playbook の実行時に、ブリックの容量をチェックしますが、ブリックをチェックする時に、ブロックホスティングボリュームに含まれるブリックをチェックから除外する必要があります。そのために、インベントリーファイルで上記の変数を false に設定する必要があります。

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

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

注記

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

ただし、新規のregistryにまだ移行していない場合は、すべてのregistry.redhat.ioregistry.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. 前提条件

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

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
  1. マスターノードで新たに作成されたコンテナー化された Red Hat Gluster Storage プロジェクトを使用します。

    # oc project <project-name>

    以下は例になります。

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

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

    # oc create -f /usr/share/heketi/templates/heketi-template.yaml
    template.template.openshift.io/heketi created
  4. テンプレートが作成されているかどうかを確認します。

    # oc get templates
    
    NAME            DESCRIPTION                          PARAMETERS    OBJECTS
    heketi          Heketi service deployment template   5 (3 blank)   3
  5. マスターノードで以下のコマンドを実行して、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"]
  6. heketi が実行されている RHGS ノードで、以下のコマンドを実行します。

    1. heketidbstorage ボリュームを作成します。

      # heketi-cli volume create --size=2 --name=heketidbstorage
    2. ボリュームをマウントします。

      # mount  -t glusterfs 192.168.11.192:heketidbstorage /mnt/

      192.168.11.192 は RHGS ノードの 1 つになります。

    3. heketi サービスを停止します。

      # systemctl stop heketi
    4. heketi サービスを無効にします。

      # systemctl disable heketi
    5. heketi db を heketidbstorage ボリュームにコピーします。

      # cp /var/lib/heketi/heketi.db /mnt/
    6. ボリュームをアンマウントします。

      # umount /mnt
    7. 以下のファイルを heketi ノードからマスターノードにコピーします。

      # scp   /etc/heketi/heketi.json  topology.json   /etc/heketi/heketi_key  OCP_master_node:/root/

      OCP_master_node は、マスターノードのホスト名になります。

  7. マスターノードで、heketi ノードからコピーした以下の 3 つのファイルの環境変数を設定します。以下の行を ~/.bashrc ファイルに追加し、bash コマンドを実行して変更を適用して保存します。

    export SSH_KEYFILE=heketi_key
    export TOPOLOGY=topology.json
    export HEKETI_CONFIG=heketi.json
    注記

    /etc/heketi/heketi.json の「keyfile」の値を異なる値に変更している場合は、ここで適宜、変更します。

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

    # oc create secret generic heketi-config-secret --from-file=${SSH_KEYFILE} --from-file=${HEKETI_CONFIG} --from-file=${TOPOLOGY}
    
    secret/heketi-config-secret created
  9. 以下のコマンドを実行してシークレットにラベルを付けます。

    # oc label --overwrite secret heketi-config-secret glusterfs=heketi-config-secret heketi=config-secret
    
    secret/heketi-config-secret labeled
  10. heketi-gluster-endpoints.yaml ファイルを作成し、すべての glusterfs ノードの IP アドレスを取得します。

    1. heketi-gluster-endpoints.yaml ファイルを作成します。

      # oc create -f ./heketi-gluster-endpoints.yaml
    2. すべての glusterfs ノードの IP アドレスを取得します。

      # cat heketi-gluster-endpoints.yaml
      apiVersion: v1
      kind: Endpoints
      metadata:
        name: heketi-storage-endpoints
      subsets:
      - addresses:
        - ip: 192.168.11.208
        ports:
        - port: 1
      - addresses:
        - ip: 192.168.11.176
        ports:
        - port: 1
      - addresses:
        - ip: 192.168.11.192
        ports:
        - port: 1

      上記の例では、192.168.11.208、192.168.11.176、192.168.11.192 は glusterfs ノードです。

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

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

  13. Heketi が移行されているかどうかを確認するには、マスターノードで以下のコマンドを実行します。

    # oc rsh po/<heketi-pod-name>

    以下は例になります。

    # oc rsh po/heketi-1-p65c6
  14. 以下のコマンドを実行して、クラスター ID を確認します。

    # heketi-cli cluster list

    出力から、クラスター ID が古いクラスターと一致するかどうかを確認します。

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

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

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

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

    # yum update cns-deploy -y
    # yum update heketi-client -y
  2. Heketi データベースファイルのバックアップを作成します。

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
  3. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

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

    <heketi-admin-secret-name> は、ユーザーが作成した heketi 管理シークレットの名前に置き換えます。

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

    # oc delete templates heketi
  5. 以下のコマンドを実行して、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)のアカウントにだけ付与されます。

  6. 以下のコマンドを実行して、新しい 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 フォーマットが厳密に必要とされています(末尾にスペースを入れない、ブール値はすべて小文字など)。

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

    # oc create secret generic heketi-config-secret --from-file=private_key=${SSH_KEYFILE} --from-file=./heketi.json
    注記

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

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

    # oc delete deploymentconfig,service,route heketi
  9. 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 の下の valuev3.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
  10. 以下のコマンドを実行して、OpenShift の永続ボリュームを作成するために使用する Heketi サービス、ルート、およびデプロイメント設定をデプロイします。

    # oc process heketi | oc create -f -
    
    service "heketi" created
    route "heketi" created
    deploymentconfig "heketi" created
    注記

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

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

    # oc get pods

    以下は例になります。

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

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

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

  1. 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
        },
      .....
    .....
  2. Heketi サービスを再起動します。

    # systemctl restart heketi
    注記

    heketi が Openshift クラスターで Pod として実行されている場合には、この手順は該当しません。

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

    # oc delete dc <gluster-block-dc>

    以下は例になります。

    # oc delete dc glusterblock-provisioner-dc
  4. 古い 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
  5. 以下のコマンドを実行して、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 のアップグレード

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

  1. 以下のコマンドを実行して、heketi クライアントを更新します。

    # yum update heketi-client -y
  2. Heketi データベースファイルのバックアップを作成します。

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
  3. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

    oc get secret heketi-storage-admin-secret -o jsonpath='{.data.key}'|base64 -d;echo
  4. HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。

     # oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
  5. 以下のコマンドで、HEKETI_USER_KEY を先に設定しておくと取得できます。

     # oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
  6. HEKETI_USER_KEY が以前に設定されていた場合は、以下のコマンドを使用して取得することができます。

     #  oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
  7. 以下のコマンドを実行して、heketi テンプレートを削除します。

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/heketi-template.yml
    template "heketi" created
  9. 以下の手順を実行して、テンプレートを編集します。

    # 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 を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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

    # oc delete deploymentconfig,service,route heketi-storage
  2. 以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

    # 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

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

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

     # oc delete templates glusterblock-provisioner
  2. glusterblock プロビジョナーテンプレートを作成します。以下は例になります。

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml
    template.template.openshift.io/glusterblock-provisioner created
  3. gluster-block-provisoner-pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

    glusterfs namespace の場合:

    # oc delete dc glusterblock-storage-provisioner-dc

    glusterfs-registry namespace の場合:

    oc delete dc glusterblock-registry-provisioner-dc
  4. 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
  5. 古い 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
  6. oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
    以下に例を示します。

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

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

注記

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 をアップグレードするには、以下の手順を実行します。

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

  1. 以下のコマンドを実行して、heketi クライアントを更新します。

    # yum update heketi-client -y
  2. Heketi レジストリーデータベースファイルをバックアップします。

    # heketi-cli db dump > heketi-db-dump-$(date -I).json
  3. 以下のコマンドを実行して、現在の HEKETI_ADMIN_KEY を取得します。

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

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

    HEKETI_USER_KEY を取得するには、以下のコマンドを実行します。

    # oc describe pod <heketi-pod> |grep "HEKETI_USER_KEY"
  4. 以下のコマンドを実行して、heketi テンプレートを削除します。

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

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/heketi-template.yml
    template "heketi" created
  6. 以下の手順を実行して、テンプレートを編集します。

    # 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 を参照し、アップグレードに進む前に必要なパラメーターを追加します。

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

    # oc delete deploymentconfig,service,route heketi-registry
  2. 以下のコマンドを実行して、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 のボリュームセット操作を実行します。

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

    # 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 をアップグレードするには、以下の手順を実行します。

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

    # oc delete templates glusterblock-provisioner
  2. glusterblock プロビジョナーテンプレートを作成します。以下は例になります。

    # oc create -f /usr/share/ansible/openshift-ansible/roles/openshift_storage_glusterfs/files/glusterblock-provisioner.yml
    template.template.openshift.io/glusterblock-provisioner created
  3. glusterblock-provisoner Pod がすでに存在する場合は、以下のコマンドを実行してこれを削除します。

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

    以下は例になります。

    # oc delete dc glusterblock-registry-provisioner-dc
  4. 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 の下の valuev3.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 の下の valuev3.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
  5. 古い 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
  6. oc process を実行する前に、適切な provisioner 名を決定してください。複数の gluster block provisioner がクラスターで実行されている場合、名前は他のすべての provisioners とは異なる必要があります。
    以下に例を示します。

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

    # 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
  8. 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 ブロックをアップグレードするには、以下の手順を実行します。

  1. 以下のコマンドを実行して gluster ブロックをアップグレードします。

    # yum update gluster-block
    • gluster ブロックサービスを有効にして起動します。

      # systemctl enable gluster-blockd
      # systemctl start gluster-blockd

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

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

  1. Pod をドレインするには、マスターノード(または cluster-admin アクセスを持つ任意のノード)で、以下のコマンドを実行します。

    # oc adm drain <node_name> --ignore-daemonsets
  2. すべての Pod がドレインされていることを確認するには、マスターノード (または cluster-admin アクセスを持つ任意のノード) で以下のコマンドを実行します。

    # oc get pods --all-namespaces --field-selector=spec.nodeName=<node_name>
  3. ノードで以下のコマンドを実行して、ノード上のクライアントをアップグレードします。

    # yum update glusterfs-fuse
  4. 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
  5. 以下のコマンドを実行して、マルチパスデーモンを起動し、マルチパス設定を(再)読み込みします。

    # systemctl start multipathd
    # systemctl reload multipathd

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

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

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

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

警告

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

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

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

ansible-playbook -i <path_to_inventory_file> -e "openshift_storage_glusterfs_wipe=true" /usr/share/ansible/openshift-ansible/playbooks/openshift-glusterfs/uninstall.yml
注記
  • gluster-block がアンインストールされている場合は、/etc/target/saveconfig.json の gluster-block に対応するエントリーが削除されていることを確認してください。設定ファイルには gluster-block 以外のエントリーが含まれる可能性があるため、gluster-block エントリーを手動で削除する必要があります。
  • OCS のアンインストール後にすべてのイニシエーターから、Dangling iqns をログアウトします。

パート V. ワークロード

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

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

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

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

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

以下は例になります。

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

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

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

ここで、

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

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

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

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

注記

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

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

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

ノード

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

以下は例になります。

# heketi-cli node settags e2a792a43ca9a6bac4b9bfa792e89347 arbiter:disabled

デバイス

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

以下は例になります。

# heketi-cli device settags 167fe2831ad0a91f7173dac79172f8d7 arbiter:required

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

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

ノード

# heketi-cli node rmtags <node id> arbiter

以下は例になります。

# heketi-cli node rmtags e2a792a43ca9a6bac4b9bfa792e89347 arbiter

デバイス

# heketi-cli device rmtags <device id> arbiter

以下は例になります。

# heketi-cli device rmtags 167fe2831ad0a91f7173dac79172f8d7 arbiter

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

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

ノード

# heketi-cli node info <node id>

以下は例になります。

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

デバイス

# heketi-cli device info <device id>

以下は例になります。

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

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

永続ボリュームの作成に関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov を参照してください。

重要

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

以下は例になります。

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

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

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

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

    # gluster volume set VOLUME performance.open-behind off
    # gluster volume set VOLUME performance.write-behind off
    # gluster volume set VOLUME performance.stat-prefetch off
    # gluster volume set VOLUME  performance.quick-read off
    # gluster volume set VOLUME performance.strict-o-direct on
    # gluster volume set VOLUME  performance.read-ahead off
    # gluster volume set VOLUME performance.io-cache off
    # gluster volume set VOLUME performance.readdir-ahead off
  2. 確認するには、以下のコマンドを実行します。

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

    以下は例になります。

    # gluster volume get VOLUME all  | egrep "performance.stat-prefetch | performance.write-behind | performance.open-behind | performance.quick-read | performance.strict-o-direct | performance.read-ahead | performance.io-cache | performance.readdir-ahead"
  3. 動的プロビジョニングの場合には、ボリュームオプションはストレージクラスファイルの「parameter」の下に記載できます。以下は例になります。

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

ファイルストレージのストレージクラスの登録に関する詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov を参照してください。

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

パート VI. 付録

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

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

注記

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

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

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

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

  • Red Hat Gluster Storage コンテナーをホストする各 OpenShift ノードで、/etc/sysconfig/iptables に次のルールを追加して、必要なポートを開きます。

    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24007 -j ACCEPT
    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m multiport --dports 49152:49664 -j ACCEPT
    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24010 -j ACCEPT
    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 3260 -j ACCEPT
    -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT
    注記
    • ポート 24010 と 3260 は、それぞれ gluster-blockd と iSCSI ターゲット用です。
    • 49664 で始まるポート範囲は、ボリュームのブリックとの通信に GlusterFS で使用できるポートの範囲を定義します。上記の例では、許容されるブリックの合計数は 512 です。各ノードでホストできるブリックの最大数に基づいて、ポート範囲を設定します。

    Red Hat Gluster Storage Server のポートの詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html/administration_guide/chap-getting_started を参照してください。

    • 以下のコマンドを実行して、iptables を再読み込みします。

      # systemctl reload iptables
    • 各ノードで以下のコマンドを実行して、iptables が更新されているかどうかを確認します。
# iptables -L

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

cns-deploy ツールを実行する前に、dm_thin_pooldm_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-レプリケーション関連の各種ファイル、およびその他のファイルを作成することが推奨されます。

  1. Red Hat Enterprise Linux 7 Server のベースインストールの実行

    インデペンデントモードは、Red Hat Enterprise Linux 7 でのみサポートされます。

  2. システムの Subscription Manager への登録

    以下のコマンドを実行し、Red Hat Network のユーザー名およびパスワードを入力して、システムを Red Hat Network に登録します。

    # subscription-manager register
  3. 利用可能なエンタイトルメントプールの特定

    以下のコマンドを実行して、Red Hat Gluster Storage のインストールに必要なリポジトリーが含まれるエンタイトルメントプールを見つけます。

    # subscription-manager list --available
  4. システムへのエンタイトルメントプールのアタッチ

    先の手順で特定したプール ID を使用して、Red Hat Enterprise Linux Server および Red Hat Gluster Storage のエンタイトルメントをシステムにアタッチします。以下のコマンドを実行してエンタイトルメントをアタッチします。

    # subscription-manager attach --pool=[POOLID]

    以下は例になります。

    # subscription-manager attach --pool=8a85f9814999f69101499c05aa706e47
  5. 必要なチャンネルの有効化

    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
  6. チャンネルが有効であるかどうかの確認

    以下のコマンドを実行して、チャンネルが有効であるかどうかを確認します。

    # yum repolist
  7. すべてのパッケージの更新

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

    # yum update
  8. カーネルバージョンの要件

    インデペンデントモードでは、システムで 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
  9. Red Hat Gluster Storage のインストール

    以下のコマンドを実行して Red Hat Gluster Storage をインストールします。

    # yum install redhat-storage-server
    1. gluster-block を有効にするには、以下のコマンドを実行します。
# yum install gluster-block
  1. 再起動

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

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. カーネルモジュールの有効化

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

  1. 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
  2. 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 クラスターを準備します。

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

    # 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".
  2. マスターまたはクライアントで以下のコマンドを実行し、コンテナー化されたすべての 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"
  3. プロジェクトが作成されたら、マスターノードで以下のコマンドを実行し、Red Hat Gluster Storage コンテナーが特権モードでしか実行できないように、特権付きコンテナーのデプロイメントができるようにします。

    # oc  adm policy add-scc-to-user privileged -z default
  4. マスターで以下の手順を実行し、ルーターを設定します。

    注記

    ルーターがすでに存在する場合は、手順 5 に進みます。ルーターがすでにデプロイされているかどうかを確認するには、以下のコマンドを実行します。

    # oc get dc --all-namespaces

    すべての namespace のすべてのルーターを一覧表示するには、以下のコマンドを実行します。

    # oc get dc --all-namespaces --selector=router=router
    NAME                                  REVISION   DESIRED   CURRENT   TRIGGERED BY
    glusterblock-storage-provisioner-dc   1          1         0         config
    heketi-storage                        4          1         1         config
    1. 以下のコマンドを実行して、ルーターのデプロイメントを有効にします。

      # oc adm policy add-scc-to-user privileged -z router
    2. 以下のコマンドを実行して、ルーターをデプロイします。

      # oc adm router storage-project-router --replicas=1
    3. /etc/origin/master/master-config.yaml にある config.yaml ファイルのサブドメイン名を編集します。

      以下は例になります。

      subdomain: "cloudapps.mystorage.com"

      詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html-single/configuring_clusters/#customizing-the-default-routing-subdomain を参照してください。

    4. OpenShift Container Platform 3.7 および 3.9 の場合は、以下のコマンドを実行してサービスを再起動します。

      # systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

    ルーター設定の詳細は、https://access.redhat.com/documentation/ja-jp/openshift_container_platform/3.11/html/configuring_clusters/setting-up-a-router を参照してください。

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

    # 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 * ファイルを編集しないでください。

  1. ルーターの実行後に、OpenShift クラスターのサービスにアクセスするように、クライアントを設定する必要があります。クライアントで以下の手順を実行し、DNS を設定します。

    1. 以下のコマンドを実行して、ルーターの IP アドレスを検索します。

      # oc get pods -o wide --all-namespaces | grep router
      storage-project storage-project-router-1-cm874        1/1       Running   119d       10.70.43.132   dhcp43-132.lab.eng.blr.redhat.com
    2. /etc/dnsmasq.conf ファイルを編集し、以下の行をファイルに追加します。

      address=/.cloudapps.mystorage.com/<Router_IP_Address>

      Router_IP_Address は、ルーターが実行されているノードの IP アドレスです。

    3. 以下のコマンドを実行して dnsmasq サービスを再起動します。

      # systemctl restart dnsmasq
    4. /etc/resolv.conf を編集し、以下の行を追加します。

      nameserver 127.0.0.1

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

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

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

注記
  1. まず、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. コンバージドモードのデプロイ

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

  1. クライアントで以下のコマンドを実行し、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
    1. 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-accountobject-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!
  2. 以下のコマンドを実行して、クライアントがコンテナーと通信できるようにします。

    # 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 をインデペンデントモードでデプロイします。

  1. パスワードなしの SSH を Red Hat Gluster Storage ノードすべてに設定するには、Red Hat Gluster Storage ノードごとにクライアントで以下のコマンドを実行します。

    # ssh-copy-id -i /root/.ssh/id_rsa root@<hostname>
  2. クライアントで以下のコマンドを実行し、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
    1. 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-accountobject-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!
  3. ブリック多重化は、1つのプロセスに複数のブリックを追加できる機能です。これにより、リソースの消費が減少し、同じメモリー消費量で前より多くのブリックを実行できるようになります。各クラスターの Red Hat Gluster Storage ノードのいずれかで以下のコマンドを実行して、brick-multiplexing を有効にします。

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

      # 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
    2. 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
  4. 以下のコマンドを実行して、クライアントがコンテナーと通信できるようにします。

    # export  HEKETI_CLI_SERVER=http://heketi-<project_name>.<sub_domain_name>

    以下は例になります。

    # export  HEKETI_CLI_SERVER=http://heketi-storage-project.cloudapps.mystorage.com

    トポロジーで Heketi が読み込まれているかどうかを確認するには、以下のコマンドを実行します。

    # heketi-cli topology info
注記
The cns-deploy tool does not support scaling up of the cluster. To manually scale-up the cluster, see link:https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Managing_Clusters[].

次のステップ: コンバージドモード 3.11 をインストールする場合は、https://access.redhat.com/documentation/ja-jp/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Updating_Registry に進みます。

付録B アンインストール Playbook の使用時に破棄される設定

uninstall.yml Playbook の実行時に、以下の 2 つのファイルが呼び出されます。

  • glusterfs_config_facts.yml
  • glusterfs_registry_facts.yml

以下のコマンドを実行すると、glusterfs_config_facts.yml と glusterfs_registry_facts.yml に関連する data/resources/content/settings が破棄されます。

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

glusterfs_config_facts.yml variables:

    glusterfs_timeout: "{{ openshift_storage_glusterfs_timeout }}"
    glusterfs_namespace: "{{ openshift_storage_glusterfs_namespace }}"
    glusterfs_is_native: "{{ openshift_storage_glusterfs_is_native | bool }}"
    glusterfs_name: "{{ openshift_storage_glusterfs_name }}"
    # map_from_pairs is a custom filter plugin in role lib_utils
    glusterfs_nodeselector: "{{ openshift_storage_glusterfs_nodeselector | default(['storagenode', openshift_storage_glusterfs_name] | join('=')) | map_from_pairs }}"
    glusterfs_use_default_selector: "{{ openshift_storage_glusterfs_use_default_selector }}"
    glusterfs_storageclass: "{{ openshift_storage_glusterfs_storageclass }}"
    glusterfs_storageclass_default: "{{ openshift_storage_glusterfs_storageclass_default | bool }}"
    glusterfs_image: "{{ openshift_storage_glusterfs_image }}"
    glusterfs_block_deploy: "{{ openshift_storage_glusterfs_block_deploy | bool }}"
    glusterfs_block_image: "{{ openshift_storage_glusterfs_block_image }}"
    glusterfs_block_host_vol_create: "{{ openshift_storage_glusterfs_block_host_vol_create }}"
    glusterfs_block_host_vol_size: "{{ openshift_storage_glusterfs_block_host_vol_size }}"
    glusterfs_block_host_vol_max: "{{ openshift_storage_glusterfs_block_host_vol_max }}"
    glusterfs_block_storageclass: "{{ openshift_storage_glusterfs_block_storageclass | bool }}"
    glusterfs_block_storageclass_default: "{{ openshift_storage_glusterfs_block_storageclass_default | bool }}"
    glusterfs_s3_deploy: "{{ openshift_storage_glusterfs_s3_deploy | bool }}"
    glusterfs_s3_image: "{{ openshift_storage_glusterfs_s3_image }}"
    glusterfs_s3_account: "{{ openshift_storage_glusterfs_s3_account }}"
    glusterfs_s3_user: "{{ openshift_storage_glusterfs_s3_user }}"
    glusterfs_s3_password: "{{ openshift_storage_glusterfs_s3_password }}"
    glusterfs_s3_pvc: "{{ openshift_storage_glusterfs_s3_pvc }}"
    glusterfs_s3_pvc_size: "{{ openshift_storage_glusterfs_s3_pvc_size }}"
    glusterfs_s3_meta_pvc: "{{ openshift_storage_glusterfs_s3_meta_pvc }}"
    glusterfs_s3_meta_pvc_size: "{{ openshift_storage_glusterfs_s3_meta_pvc_size }}"
    glusterfs_wipe: "{{ openshift_storage_glusterfs_wipe | bool }}"
    glusterfs_heketi_is_native: "{{ openshift_storage_glusterfs_heketi_is_native | bool }}"
    glusterfs_heketi_is_missing: "{{ openshift_storage_glusterfs_heketi_is_missing | bool }}"
    glusterfs_heketi_deploy_is_missing: "{{ openshift_storage_glusterfs_heketi_deploy_is_missing | bool }}"
    glusterfs_heketi_cli: "{{ openshift_storage_glusterfs_heketi_cli }}"
    glusterfs_heketi_image: "{{ openshift_storage_glusterfs_heketi_image }}"
    glusterfs_heketi_admin_key: "{{ openshift_storage_glusterfs_heketi_admin_key }}"
    glusterfs_heketi_user_key: "{{ openshift_storage_glusterfs_heketi_user_key }}"
    glusterfs_heketi_topology_load: "{{ openshift_storage_glusterfs_heketi_topology_load | bool }}"
    glusterfs_heketi_wipe: "{{ openshift_storage_glusterfs_heketi_wipe | bool }}"
    glusterfs_heketi_url: "{{ openshift_storage_glusterfs_heketi_url }}"
    glusterfs_heketi_port: "{{ openshift_storage_glusterfs_heketi_port }}"
    glusterfs_heketi_executor: "{{ openshift_storage_glusterfs_heketi_executor }}"
    glusterfs_heketi_ssh_port: "{{ openshift_storage_glusterfs_heketi_ssh_port }}"
    glusterfs_heketi_ssh_user: "{{ openshift_storage_glusterfs_heketi_ssh_user }}"
    glusterfs_heketi_ssh_sudo: "{{ openshift_storage_glusterfs_heketi_ssh_sudo | bool }}"
    glusterfs_heketi_ssh_keyfile: "{{ openshift_storage_glusterfs_heketi_ssh_keyfile }}"
    glusterfs_heketi_fstab: "{{ openshift_storage_glusterfs_heketi_fstab }}"
    glusterfs_nodes: "{{ groups.glusterfs | default([]) }}"

glusterfs_registry_facts.yml variables:

    glusterfs_timeout: "{{ openshift_storage_glusterfs_registry_timeout }}"
    glusterfs_namespace: "{{ openshift_storage_glusterfs_registry_namespace }}"
    glusterfs_is_native: "{{ openshift_storage_glusterfs_registry_is_native | bool }}"
    glusterfs_name: "{{ openshift_storage_glusterfs_registry_name }}"
    # map_from_pairs is a custom filter plugin in role lib_utils
    glusterfs_nodeselector: "{{ openshift_storage_glusterfs_registry_nodeselector | default(['storagenode', openshift_storage_glusterfs_registry_name] | join('=')) | map_from_pairs }}"
    glusterfs_use_default_selector: "{{ openshift_storage_glusterfs_registry_use_default_selector }}"
    glusterfs_storageclass: "{{ openshift_storage_glusterfs_registry_storageclass }}"
    glusterfs_storageclass_default: "{{ openshift_storage_glusterfs_registry_storageclass_default | bool }}"
    glusterfs_image: "{{ openshift_storage_glusterfs_registry_image }}"
    glusterfs_block_deploy: "{{ openshift_storage_glusterfs_registry_block_deploy | bool }}"
    glusterfs_block_image: "{{ openshift_storage_glusterfs_registry_block_image }}"
    glusterfs_block_host_vol_create: "{{ openshift_storage_glusterfs_registry_block_host_vol_create }}"
    glusterfs_block_host_vol_size: "{{ openshift_storage_glusterfs_registry_block_host_vol_size }}"
    glusterfs_block_host_vol_max: "{{ openshift_storage_glusterfs_registry_block_host_vol_max }}"
    glusterfs_block_storageclass: "{{ openshift_storage_glusterfs_registry_block_storageclass | bool }}"
    glusterfs_block_storageclass_default: "{{ openshift_storage_glusterfs_registry_block_storageclass_default | bool }}"
    glusterfs_s3_deploy: "{{ openshift_storage_glusterfs_registry_s3_deploy | bool }}"
    glusterfs_s3_image: "{{ openshift_storage_glusterfs_registry_s3_image }}"
    glusterfs_s3_account: "{{ openshift_storage_glusterfs_registry_s3_account }}"
    glusterfs_s3_user: "{{ openshift_storage_glusterfs_registry_s3_user }}"
    glusterfs_s3_password: "{{ openshift_storage_glusterfs_registry_s3_password }}"
    glusterfs_s3_pvc: "{{ openshift_storage_glusterfs_registry_s3_pvc }}"
    glusterfs_s3_pvc_size: "{{ openshift_storage_glusterfs_registry_s3_pvc_size }}"
    glusterfs_s3_meta_pvc: "{{ openshift_storage_glusterfs_registry_s3_meta_pvc }}"
    glusterfs_s3_meta_pvc_size: "{{ openshift_storage_glusterfs_registry_s3_meta_pvc_size }}"
    glusterfs_wipe: "{{ openshift_storage_glusterfs_registry_wipe | bool }}"
    glusterfs_heketi_is_native: "{{ openshift_storage_glusterfs_registry_heketi_is_native | bool }}"
    glusterfs_heketi_is_missing: "{{ openshift_storage_glusterfs_registry_heketi_is_missing | bool }}"
    glusterfs_heketi_deploy_is_missing: "{{ openshift_storage_glusterfs_registry_heketi_deploy_is_missing | bool }}"
    glusterfs_heketi_cli: "{{ openshift_storage_glusterfs_registry_heketi_cli }}"
    glusterfs_heketi_image: "{{ openshift_storage_glusterfs_registry_heketi_image }}"
    glusterfs_heketi_admin_key: "{{ openshift_storage_glusterfs_registry_heketi_admin_key }}"
    glusterfs_heketi_user_key: "{{ openshift_storage_glusterfs_registry_heketi_user_key }}"
    glusterfs_heketi_topology_load: "{{ openshift_storage_glusterfs_registry_heketi_topology_load | bool }}"
    glusterfs_heketi_wipe: "{{ openshift_storage_glusterfs_registry_heketi_wipe | bool }}"
    glusterfs_heketi_url: "{{ openshift_storage_glusterfs_registry_heketi_url }}"
    glusterfs_heketi_port: "{{ openshift_storage_glusterfs_registry_heketi_port }}"
    glusterfs_heketi_executor: "{{ openshift_storage_glusterfs_registry_heketi_executor }}"
    glusterfs_heketi_ssh_port: "{{ openshift_storage_glusterfs_registry_heketi_ssh_port }}"
    glusterfs_heketi_ssh_user: "{{ openshift_storage_glusterfs_registry_heketi_ssh_user }}"
    glusterfs_heketi_ssh_sudo: "{{ openshift_storage_glusterfs_registry_heketi_ssh_sudo | bool }}"
    glusterfs_heketi_ssh_keyfile: "{{ openshift_storage_glusterfs_registry_heketi_ssh_keyfile }}"
    glusterfs_heketi_fstab: "{{ openshift_storage_glusterfs_registry_heketi_fstab }}"
    glusterfs_nodes: "{% if groups.glusterfs_registry is defined and groups['glusterfs_registry'] | length > 0 %}{% set nodes = groups.glusterfs_registry %}{% elif 'groups.glusterfs' is defined and groups['glusterfs'] | length > 0 %}{% set nodes = groups.glusterfs %}{% else %}{% set nodes = '[]' %}{% endif %}{{ nodes }}"

付録C テンプレート

C.1. glusterblock プロビジョナーテンプレート

このセクションでは、Glusterblock Provisioner テンプレート について説明します。

---
kind: Template
apiVersion: v1
metadata:
  name: glusterblock-provisioner
  labels:
    glusterfs: block-template
    glusterblock: template
  annotations:
    description: glusterblock provisioner template
    tags: glusterfs
objects:
- kind: ClusterRole
  apiVersion: v1
  metadata:
    name: glusterblock-provisioner-runner
    labels:
      glusterfs: block-provisioner-runner-clusterrole
      glusterblock: provisioner-runner-clusterrole
  rules:
    - apiGroups: [""]
      resources: ["persistentvolumes"]
      verbs: ["get", "list", "watch", "create", "delete"]
    - apiGroups: [""]
      resources: ["persistentvolumeclaims"]
      verbs: ["get", "list", "watch", "update"]
    - apiGroups: ["storage.k8s.io"]
      resources: ["storageclasses"]
      verbs: ["get", "list", "watch"]
    - apiGroups: [""]
      resources: ["events"]
      verbs: ["list", "watch", "create", "update", "patch"]
    - apiGroups: [""]
      resources: ["services"]
      verbs: ["get"]
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["get", "create", "delete"]
    - apiGroups: [""]
      resources: ["routes"]
      verbs: ["get", "list"]
    - apiGroups: [""]
      resources: ["endpoints"]
      verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner
    labels:
      glusterfs: block-${CLUSTER_NAME}-provisioner-sa
      glusterblock: ${CLUSTER_NAME}-provisioner-sa
- apiVersion: v1
  kind: ClusterRoleBinding
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner
  roleRef:
    name: glusterblock-provisioner-runner
  subjects:
  - kind: ServiceAccount
    name: glusterblock-${CLUSTER_NAME}-provisioner
    namespace: ${NAMESPACE}
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: glusterblock-${CLUSTER_NAME}-provisioner-dc
    labels:
      glusterfs: block-${CLUSTER_NAME}-provisioner-dc
      glusterblock: ${CLUSTER_NAME}-provisioner-dc
    annotations:
      description: Defines how to deploy the glusterblock provisioner pod.
  spec:
    replicas: 1
    selector:
      glusterfs: block-${CLUSTER_NAME}-provisioner-pod
    triggers:
    - type: ConfigChange
    strategy:
      type: Recreate
    template:
      metadata:
        name: glusterblock-provisioner
        labels:
          glusterfs: block-${CLUSTER_NAME}-provisioner-pod
      spec:
        serviceAccountName: glusterblock-${CLUSTER_NAME}-provisioner
        containers:
        - name: glusterblock-provisioner
          image: ${IMAGE_NAME}
          imagePullPolicy: IfNotPresent
          env:
          - name: PROVISIONER_NAME
            value: gluster.org/glusterblock-${NAMESPACE}
parameters:
- name: IMAGE_NAME
  displayName: glusterblock provisioner container image name
  required: True
- name: NAMESPACE
  displayName: glusterblock provisioner namespace
  description: The namespace in which these resources are being created
  required: True
- name: CLUSTER_NAME
  displayName: GlusterFS cluster name
  description: A unique name to identify which heketi service manages this cluster, useful for running multiple heketi instances
  value: storage

C.2. コンバージドモード設定のインベントリーファイルサンプル

本セクションでは、コンバージドモードの設定用のインベントリーファイル例 について説明します。

[OSEv3:children]
masters
nodes
etcd
glusterfs
glusterfs_registry

[OSEv3:vars]
ansible_ssh_user=root
debug_level=5
os_update=false
install_method=rpm
install_update_docker=true
docker_storage_driver=devicemapper
container_runtime_docker_storage_setup_device=/dev/sdc
oreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11
openshift_release=v3.11
openshift_docker_additional_registries=registry.access.redhat.com
openshift_docker_insecure_registries=registry.access.redhat.com
openshift_deployment_type=openshift-enterprise
openshift_web_console_install=true
openshift_enable_service_catalog=false
openshift_set_hostname=true
openshift_override_hostname_check=true
openshift_disable_check=docker_image_availability
openshift_check_min_host_disk_gb=2
openshift_check_min_host_memory_gb=1
openshift_portal_net=172.31.0.0/16
openshift_master_cluster_method=native
openshift_clock_enabled=true
openshift_hosted_router_selector="node-role.kubernetes.io/infra=true"
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"
openshift_use_openshift_sdn=true
osm_use_cockpit=false
osm_cockpit_plugins=['cockpit-kubernetes']

openshift_master_dynamic_provisioning_enabled=true


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


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


# glusterfs
openshift_storage_glusterfs_timeout=900
openshift_storage_glusterfs_namespace=glusterfs
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100


# glusterfs_registry
openshift_storage_glusterfs_registry_namespace=glusterfs-registry
openshift_storage_glusterfs_registry_storageclass=true
openshift_storage_glusterfs_registry_storageclass_default=false
openshift_storage_glusterfs_registry_block_storageclass=true
openshift_storage_glusterfs_registry_block_storageclass_default=false
openshift_storage_glusterfs_registry_block_deploy=true
openshift_storage_glusterfs_registry_block_host_vol_create=true
openshift_storage_glusterfs_registry_block_host_vol_size=100

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi


openshift_storage_glusterfs_heketi_admin_key='<adminkey>'
openshift_storage_glusterfs_heketi_user_key='<heketiuserkey>'


openshift_storage_glusterfs_image='registry.redhat.io/rhgs3/rhgs-server-rhel7:v3.11.x'

openshift_storage_glusterfs_heketi_image='registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.x'

openshift_storage_glusterfs_block_image='registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.x'


openshift_master_cluster_hostname=node101.redhat.com
openshift_master_cluster_public_hostname=node101.redhat.com

[masters]
node101.redhat.com

[etcd]
node101.redhat.com

[nodes]
node101.redhat.com openshift_node_group_name="node-config-master"
node102.redhat.com openshift_node_group_name="node-config-infra"
node103.redhat.com openshift_node_group_name="node-config-compute"
node104.redhat.com openshift_node_group_name="node-config-compute"
node105.redhat.com openshift_node_group_name="node-config-compute"
node106.redhat.com openshift_node_group_name="node-config-compute"
node107.redhat.com openshift_node_group_name="node-config-compute"
node108.redhat.com openshift_node_group_name="node-config-compute"

[glusterfs]
node103.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node104.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node105.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1

[glusterfs_registry]
node106.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node107.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1
node108.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1

C.3. インデペンデントモード設定のインベントリーファイルのサンプル

以下のセクションでは、インデペンデントモード設定のインベントリーファイルのサンプルを紹介します。

[OSEv3:children]
masters
nodes
etcd
glusterfs
glusterfs_registry

[OSEv3:vars]
ansible_ssh_user=root
debug_level=5
os_update=false
install_method=rpm
install_update_docker=true
docker_storage_driver=devicemapper
container_runtime_docker_storage_setup_device=/dev/sdc
oreg_url=registry.access.redhat.com/openshift3/ose-${component}:v3.11
openshift_release=v3.11
openshift_docker_additional_registries=registry.access.redhat.com
openshift_docker_insecure_registries=registry.access.redhat.com
openshift_deployment_type=openshift-enterprise
openshift_web_console_install=true
openshift_enable_service_catalog=false
openshift_set_hostname=true
openshift_override_hostname_check=true
openshift_disable_check=docker_image_availability
openshift_check_min_host_disk_gb=2
openshift_check_min_host_memory_gb=1
openshift_portal_net=172.31.0.0/16
openshift_master_cluster_method=native
openshift_clock_enabled=true
openshift_hosted_router_selector="node-role.kubernetes.io/infra=true"
openshift_hosted_registry_selector="node-role.kubernetes.io/infra=true"
openshift_use_openshift_sdn=true
osm_use_cockpit=false
osm_cockpit_plugins=['cockpit-kubernetes']

openshift_master_dynamic_provisioning_enabled=true


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


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


# glusterfs
openshift_storage_glusterfs_timeout=900
openshift_storage_glusterfs_namespace=glusterfs
openshift_storage_glusterfs_storageclass=true
openshift_storage_glusterfs_storageclass_default=false
openshift_storage_glusterfs_block_storageclass=true
openshift_storage_glusterfs_block_storageclass_default=false
openshift_storage_glusterfs_block_deploy=true
openshift_storage_glusterfs_block_host_vol_create=true
openshift_storage_glusterfs_block_host_vol_size=100
openshift_storage_glusterfs_is_native=false
openshift_storage_glusterfs_heketi_is_native=true
openshift_storage_glusterfs_heketi_executor=ssh
openshift_storage_glusterfs_heketi_ssh_port=22
openshift_storage_glusterfs_heketi_ssh_user=root
openshift_storage_glusterfs_heketi_ssh_sudo=false
openshift_storage_glusterfs_heketi_ssh_keyfile="/root/.ssh/id_rsa"


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

# glusterfs_registry_storage
openshift_hosted_registry_storage_kind=glusterfs
openshift_hosted_registry_storage_volume_size=20Gi


openshift_storage_glusterfs_heketi_admin_key='adminkey'
openshift_storage_glusterfs_heketi_user_key='heketiuserkey'


openshift_storage_glusterfs_heketi_image='registry.redhat.io/rhgs3/rhgs-volmanager-rhel7:v3.11.x'

openshift_storage_glusterfs_block_image='registry.redhat.io/rhgs3/rhgs-gluster-block-prov-rhel7:v3.11.x'


openshift_master_cluster_hostname=node101.redhat.com
openshift_master_cluster_public_hostname=node101.redhat.com

[masters]
node101.redhat.com

[etcd]
node101.redhat.com

[nodes]
node101.redhat.com openshift_node_group_name="node-config-master"
node102.redhat.com openshift_node_group_name="node-config-infra"
node103.redhat.com openshift_node_group_name="node-config-compute"
node104.redhat.com openshift_node_group_name="node-config-compute"

[glusterfs]
node105.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node105_ip
node106.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node106_ip
node107.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node107_ip

[glusterfs_registry]
node108.redhat.com glusterfs_zone=1 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node108_ip
node109.redhat.com glusterfs_zone=2 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node109_ip
node110.redhat.com glusterfs_zone=3 glusterfs_devices='["/dev/sdb"]' glusterfs_cluster=1 glusterfs_ip=node110_ip