インストールガイド

Red Hat Ceph Storage 4

Red Hat Enterprise Linux への Red Hat Ceph Storage のインストール

概要

本書では、AMD64 および Intel 64 アーキテクチャーで実行している Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 8 に Red Hat Ceph Storage をインストールする方法を説明します。
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージを参照してください。

第1章 Red Hat Ceph Storage とは

Red Hat Ceph Storage は、スケーラブルでオープンなソフトウェア定義のストレージプラットフォームであり、エンタープライズ向けバージョンの Ceph ストレージシステムと Ceph 管理プラットフォーム、デプロイメントユーティリティー、およびサポートサービスを組み合わせたものです。Red Hat Ceph Storage は、クラウドインフラストラクチャーおよび Web スケールオブジェクトストレージ用に設計されています。Red Hat Ceph Storage クラスターは、以下のタイプのノードで構成されます。

Red Hat Ceph Storage Ansible 管理

Ansible 管理ノードは、以前のバージョンの Red Hat Ceph Storage で使用されていた従来の Ceph 管理ノードとして機能します。Ansibleの管理ノードには、以下の機能があります。

  • 集中ストレージクラスター管理。
  • Ceph 設定ファイルおよびキー。
  • 必要に応じて、セキュリティー上の理由からインターネットにアクセスできないノードに Ceph をインストールするためのローカルリポジトリー。

Ceph Monitor

各 Ceph Monitor ノードは ceph-mon デーモンを実行し、ストレージクラスターマップのマスターコピーを維持します。ストレージクラスターマップには、ストレージクラスタートポロジーが含まれます。Ceph ストレージクラスターに接続するクライアントは、Ceph Monitor からストレージクラスターマッピングの現在のコピーを取得します。これにより、クライアントはストレージクラスターからデータの読み取りおよび書き込みが可能になります。

重要

ストレージクラスターは、1 つの Ceph Monitor でのみ実行できます。ただし、実稼働環境のストレージクラスターで高可用性を確保するために、RedHat は少なくとも 3 つの Ceph Monitor ノードを使用したデプロイメントのみをサポートします。Red Hat は、750 Ceph OSD を超えるストレージクラスター用に合計 5 つの Ceph Monitor をデプロイすることを推奨します。

Ceph OSD

各 Ceph Object Storage Device(OSD)ノードは ceph-osd デーモンを実行し、ノードに接続されている論理ディスクと対話します。ストレージクラスターは、データをこれらの Ceph OSD ノードに保存します。

Ceph は、OSD ノードを非常に少ない状態で実行できます (デフォルトは 3 つですが、実稼働ストレージクラスターは適度な規模から初めてより良いパフォーマンスが向上します)。たとえば、ストレージクラスター内の 50 個の Ceph OSD 等。理想的には、Ceph Storage クラスターには複数の OSD ノードがあり、CRUSH マップを適宜設定して障害のドメインを分離できる場合があります。

Ceph MDS

各 Ceph Metadata Server (MDS) ノードは ceph-mds デーモンを実行し、Ceph File System (CephFS) に保管されたファイルに関するメタデータを管理します。Ceph MDS デーモンは、共有ストレージクラスターへのアクセスも調整します。

Ceph Object Gateway

Ceph Object Gateway ノードは ceph-radosgw デーモンを実行し、librados 上に構築されたオブジェクトストレージインターフェースで、アプリケーションに Ceph ストレージクラスターへの RESTful アクセスポイントを提供します。Ceph Object Gateway は以下の 2 つのインターフェースをサポートします。

  • S3

    Amazon S3 RESTful API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。

  • Swift

    OpenStack Swift API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。

関連情報

第2章 Red Hat Ceph Storage に関する考慮事項および推奨事項

ストレージ管理者は、Red Hat Ceph Storage クラスターを実行する前に考慮すべき内容を基本的に理解しておくようにしてください。ハードウェアおよびネットワークの要件、Red Hat Ceph Storage クラスターと適切に機能するワークロードのタイプや Red Hat の推奨事項を確認してください。Red Hat Ceph Storage は、特定のビジネスニーズまたは要件に基づいて異なるワークロードに使用できます。Red Hat Ceph Storage をインストールする前に、Ceph ストレージクラスターを効率的に実行するには、ビジネス要件を達成するのに必要な計画を立てます。

注記

特定のユースケースで Red Hat Ceph Storage クラスターの使用計画にサポートが必要ですか?レッドハットの担当者にご相談ください。

2.1. 前提条件

  • ストレージソリューションを理解、検討、計画する時間を確保する。

2.2. Red Hat Ceph Storage の基本的な考慮事項

Red Hat Ceph Storage を使用するための最初の考慮事項は、データのストレージストラテジーの開発についてです。ストレージストラテジーとは、特定のユースケースに対応するためのデータを保管する手法を指します。OpenStack などのクラウドプラットフォームのボリュームおよびイメージを保存する必要がある場合は、ジャーナル用に Solid State Drives(SSD)を使用する高速な Serial Attached SCSI(SAS)ドライブにデータを保存することができます。一方、S3 または Swift 準拠のゲートウェイのオブジェクトデータを保存する必要がある場合は、従来の Serial Advanced Technology Attachment(SATA)ドライブなど、より経済的な方法を使用できます。Red Hat Ceph Storage は、同じストレージクラスターの両方のシナリオに対応しますが、クラウドプラットフォーム用に高速ストレージストラテジーと、オブジェクトストア用に従来のストレージを提供する手段が必要です。

Ceph のデプロイメントを正常に実行するための最も重要な手順の 1 つとして、クラスターのユースケースとワークロードに適した価格性能比のプロファイルを特定します。ユースケースに適したハードウェアを選択することが重要です。例えば、コールドストレージアプリケーション用に IOPS が最適化されたハードウェアを選択すると、ハードウェアのコストが必要以上に増加します。一方で、IOPS を多用するワークロードにおいて、より魅力的な価格帯のために容量を最適化したハードウェアを選択すると、パフォーマンスの低下に不満を持つユーザーが出てくる可能性が高くなります。

Red Hat Ceph Storage は、複数のストレージストラテジーをサポートできます。健全なストレージ戦略を策定するには、ユースケース、費用対効果、パフォーマンスのトレードオフ、データの耐久性などを考慮する必要があります。

ユースケース

Ceph は大容量のストレージを提供し、多くのユースケースをサポートします。

  • Ceph Block Device クライアントは、クラウドプラットフォーム向けの代表的なストレージバックエンドで、ボリュームやイメージに対して制限なくストレージを提供し、コピーオンライトクローニングなど、高パフォーマンス機能を備えています。
  • Ceph Object Gateway クライアントは、音声、ビットマップ、ビデオなどのオブジェクト向けの RESTful S3 準拠のオブジェクトおよび Swift 準拠のオブジェクトストレージを提供するクラウドプラットフォームの主要なストレージバックエンドです。
  • 従来のファイルストレージである Ceph ファイルシステム。

コスト vs.パフォーマンス

速度、サイズ、耐久性など高いほうが優れています。ただし、優れた品質にはそれぞれコストがかかるので、費用対効果の面でトレードオフがあります。パフォーマンスの観点からの以下のユースケースを考慮してください。SSD は、比較的少ないデータおよびジャーナリング用に、非常に高速ストレージを提供できます。データベースやオブジェクトインデックスの保存には、非常に高速な SSD のプールが有効ですが、他のデータの保存にはコストがかかりすぎてしまいます。SSD ジャーナリングのある SAS ドライブは、ボリュームやイメージを安価かつ高速なパフォーマンスで提供できます。SSD ジャーナリングのない SATA ドライブは、全体的なパフォーマンスは低くなりますが、ストレージの価格を安価に抑えることができます。OSD の CRUSH 階層を作成する場合は、ユースケースと許容コスト/パフォーマンスのトレードオフを考慮する必要があります。

データの持続性

大規模なクラスターでは、ハードウェア障害は想定されており、例外ではありません。ただし依然として、データの損失および中断は受け入れられません。そのため、データの持続性は非常に重要になります。Ceph は、オブジェクトの複数のレプリカコピー、またはイレイジャーコーディングおよび複数のコーディングのチャンクでデータの持続性に対応します。複数のコピーまたはコーディングチャンクにより、さらに費用対効果の面でのトレードオフが分かります。コピーやコーディングのチャンクが少ない場合にはコストがかかりませんが、パフォーマンスが低下した状態で、書き込み要求に対応できなくなる可能性があります。通常、追加のコピーまたはコーディングチャンクが 2 つあるオブジェクトを使用すると、ストレージクラスターが復旧する間に、パフォーマンスが低下した状態でクラスターの書き込みを行うことができます。

レプリケーションでは、ハードウェア障害に備えて、障害ドメインをまたいで 1 つ以上のデータの冗長コピーを保存します。しかし、データの冗長コピーは、規模が大きくなるとコスト高になります。たとえば、1 ペタバイトのデータを 3 つのレプリケーションで保存するには、少なくとも容量が 3 ペタバイトあるストレージクラスターが必要になります。

イレイジャーコーディングでは、データをデータチャンクとコーディングチャンクに分けて保存します。データチャンクが失われた場合には、イレイジャーコーディングにより、残りのデータチャンクとコーディングチャンクで失われたデータチャンクを回復できます。イレイジャーコーディングはレプリケーションに比べて大幅に経済的です。たとえば、データチャンク 8 つとコーディングチャンク3 つのイレイジャーコーディングを使用すると、データのコピーが 3 つある状態と同じ冗長性が得られます。ただし、このようなエンコーディングスキームでは、初期のデータ保存量が約 1.5 倍になるのに対し、レプリケーションでは 3 倍になります。

CRUSH アルゴリズムは、Ceph が、ストレージクラスター内の異なる場所に追加のコピーまたはコーディングチャンクを保存して、このプロセスをサポートします。これにより、1 つのストレージデバイスまたはノードに障害が発生しても、データ損失を回避するために必要なコピーやコーディングチャンクがすべて失われないようにします。費用対効果の面でのトレードオフやデータの耐性を考慮してストレージ戦略を計画し、ストレージプールとして Ceph クライアントに提示します。

重要

データストレージプールのみがイレイジャーコーディングを使用できます。サービスデータやバケットインデックスを格納するプールはレプリケーションを使用します。

重要

Ceph のオブジェクトコピーやコーディングチャンクを使用すると、RAID ソリューションが古く感じられます。Ceph はすでにデータの持続性に対応しており、質の低い RAID ではパフォーマンスに悪影響があり、RAID を使用してデータを復元すると、ディープコピーや消失訂正を使用するよりもはるかにスピードが遅くなるので、RAID は使用しないでください。

関連情報

2.3. Red Hat Ceph Storage ワークロードに関する考慮事項

Ceph Storage クラスターの主な利点の 1 つとして、パフォーマンスドメインを使用して、同じストレージクラスター内のさまざまなタイプのワークロードをサポートする機能があります。各パフォーマンスドメインには、異なるハードウェア構成を関連付けることができます。ストレージ管理者は、ストレージプールを適切なパフォーマンスドメインに配置し、特定のパフォーマンスとコストプロファイルに合わせたストレージをアプリケーションに提供できます。これらのパフォーマンスドメインに適切なサイズ設定と最適化されたサーバーを選択することは、Red Hat Ceph Storage クラスターを設計するのに不可欠な要素です。

データの読み取りおよび書き込みを行う Ceph クライアントインターフェースに対して、Ceph Storage クラスターはクライアントがデータを格納する単純なプールとして表示されます。ただし、ストレージクラスターは、クライアントインターフェイスから完全に透過的な方法で多くの複雑な操作を実行します。Ceph クライアントおよび Ceph オブジェクトストレージデーモン (Ceph OSD または単に OSD) はいずれも、オブジェクトのストレージおよび取得にスケーラブルなハッシュ (CRUSH) アルゴリズムで制御されたレプリケーションを使用します。Ceph OSD は、ベアメタルサーバでも、ストレージクラスター内のコンテナーでも実行できます。

CRUSH マップはクラスターリソースのトポロジーを表し、マップは、クラスター内のクライアントノードと Ceph Monitor ノードの両方に存在します。Ceph クライアントおよび Ceph OSD はどちらも CRUSH マップと CRUSH アルゴリズムを使用します。Ceph クライアントは OSD と直接通信することで、オブジェクト検索の集中化とパフォーマンスのボトルネックとなる可能性を排除します。CRUSH マップとピアとの通信を認識することで、OSD は動的障害復旧のレプリケーション、バックフィル、およびリカバリーを処理できます。

Ceph は CRUSH マップを使用して障害ドメインを実装します。Ceph は CRUSH マップも使用してパフォーマンスドメインを実装します。パフォーマンスドメインは、基盤のハードウェアのパフォーマンスプロファイルを考慮してください。CRUSH マップは Ceph のデータの格納方法を記述し、これは単純な階層 (例: 非周期グラフ) およびルールセットとして実装されます。CRUSH マップは複数の階層をサポートし、ハードウェアパフォーマンスプロファイルのタイプを別のタイプから分離できます。Cephでは、デバイスの「classes」でパフォーマンスドメインを実装しています。

たとえば、これらのパフォーマンスドメインを同じ Red Hat Ceph Storage クラスター内に共存させることができます。

  • ハードディスクドライブ (HDD) は、一般的にコストと容量を重視したワークロードに適しています。
  • スループットを区別するワークロードは通常、ソリッドステートドライブ (SSD) の Ceph 書き込みジャーナルで HDD を使用します。
  • MySQL や MariaDB のような IOPS を多用するワークロードでは、SSD を使用することが多いです。

ワークロード

Red Hat Ceph Storage は、3 つの主要なワークロードに最適化されています。

  • IOPSを最適化: IOPS (Input, Output per Second) が最適化されたデプロイメントは、MYSQL や MariaDB インスタンスを OpenStack 上の仮想マシンとして稼働させるなど、クラウドコンピューティングの操作に適しています。IOPS が最適化された導入では、15k RPM の SAS ドライブや、頻繁な書き込み操作を処理するための個別の SSD ジャーナルなど、より高性能なストレージが必要となります。一部の IOPS のシナリオでは、すべてのフラッシュストレージを使用して IOPS と総スループットが向上します。

    IOPS が最適化されたストレージクラスターには、以下のプロパティーがあります。

    • IOPS あたり最小コスト
    • 1 GB あたりの最大 IOPS。
    • 99 パーセンタイルのレイテンシーの一貫性。

    IOPS に最適化されたストレージクラスターの用途は以下のとおりです。

    • 典型的なブロックストレージ。
    • ハードドライブ (HDD) の 3x レプリケーションまたはソリッドステートドライブ (SSD) の 2x レプリケーション。
    • OpenStack クラウド上の MySQL
  • 最適化されたスループット: スループットが最適化されたデプロイメントは、グラフィック、音声、ビデオコンテンツなどの大量のデータを提供するのに適しています。スループットが最適化されたデプロイメントには、高帯域幅のネットワークハードウェア、コントローラ、高速シーケンシャル読み取り/書き込み機能のあるハードディスクドライブが必要です。高速なデータアクセスが必要な場合は、スループットを最適化したストレージ戦略を使用します。また、高速な書き込み性能が必要な場合は、ジャーナルに SSD (Solid State Disks) を使用すると、書き込み性能が大幅に向上します。

    スループットが最適化されたストレージクラスターには、以下のような特性があります。

    • MBps あたりの最小コスト (スループット)。
    • TB あたり最も高い MBps。
    • BTU あたりの最大 MBps
    • Watt あたりの MBps の最大数。
    • 97 パーセンタイルのレイテンシーの一貫性。

    スループットを最適化したストレージクラスターの用途は以下のとおりです。

    • ブロックまたはオブジェクトストレージ。
    • 3x レプリケーション。
    • ビデオ、音声、およびイメージのアクティブなパフォーマンスストレージ。
    • 4K 映像などのストリーミングメディア
  • 最適化された容量: 容量が最適化されたデプロイメントは、大量のデータを可能な限り安価に保存するのに適しています。容量が最適化されたデプロイメントは通常、パフォーマンスがより魅力的な価格と引き換えになります。たとえば、容量を最適化したデプロイメントでは、ジャーナリングに SSD を使用するのではなく、より低速で安価な SATA ドライブを使用し、ジャーナルを同じ場所に配置することがよくあります。

    コストと容量が最適化されたストレージクラスターには、次のような特性があります。

    • TB あたり最小コスト
    • TB あたり最小の BTU 数。
    • TB あたりに必要な最小 Watt。

    コストと容量が最適化されたストレージクラスターの用途は以下のとおりです。

    • 典型的なオブジェクトストレージ。
    • 使用可能な容量を最大化するイレイジャーコーディング
    • オブジェクトアーカイブ。
    • ビデオ、音声、およびイメージオブジェクトのリポジトリー。
重要

ストレージクラスターの価格とパフォーマンスに大きな影響を与えるので、どのハードウェアを購入するかを検討する前に、Red Hat Ceph Storage クラスターで実行するワークロードを慎重に検討してください。たとえば、ワークロードの容量が最適化されいるにも拘らず、スループットが最適化されたワークロードに、対象のハードウェアがより適している場合に、ハードウェアが必要以上に高価になってしまいます。逆に、ワークロードのスループットが最適化されていて、容量が最適化されたワークロードに、対象のハードウェアが適している場合は、ストレージクラスターのパフォーマンスが低下します。

2.4. Red Hat Ceph Storage のネットワークに関する考察

クラウドストレージソリューションの重要な点は、ネットワークのレイテンシーなどの要因により、ストレージクラスターが IOPS 不足になることです。また、ストレージクラスターがストレージ容量を使い果たす、はるか前に、帯域幅の制約が原因でスループットが不足することがあります。つまり、価格対性能の要求を満たすには、ネットワークのハードウェア構成が選択されたワークロードをサポートする必要があります。

ストレージ管理者は、ストレージクラスターをできるだけ早く復旧することを望みます。ストレージクラスターネットワークの帯域幅要件を慎重に検討し、ネットワークリンクのオーバーサブスクリプションに注意してください。また、クライアント間のトラフィックからクラスター内のトラフィックを分離します。また、SSD (Solid State Disk) やフラッシュ、NVMe などの高性能なストレージデバイスの使用を検討する場合には、ネットワークパフォーマンスの重要性が増していることも考慮してください。

Ceph はパブリックネットワークとストレージクラスターネットワークをサポートしています。パブリックネットワークは、クライアントのトラフィックと Ceph Monitor との通信を処理します。ストレージクラスターネットワークは、Ceph OSD のハートビート、レプリケーション、バックフィル、リカバリーのトラフィックを処理します。ストレージハードウェアには、最低でも 10GB のイーサネットリンクを 1 つ使用し、接続性とスループット向けにさらに 10GB イーサネットリンクを追加できます。

重要

Red Hat では、レプリケートされたプールをもとに osd_pool_default_size を使用してパブリックネットワークの倍数となるように、ストレージクラスターネットワークに帯域幅を割り当てることを推奨しています。また、Red Hat はパブリックネットワークとストレージクラスターネットワークを別々のネットワークカードで実行することを推奨しています。

重要

Red Hat では、実稼働環境での Red Hat Ceph Storage のデプロイメントに 10GB のイーサネットを使用することを推奨しています。1GB のイーサネットネットワークは、実稼働環境のストレージクラスターには適していません。

ドライブに障害が発生した場合、1 GB イーサネットネットワーク全体で 1 TB のデータをレプリケートするには 3 時間かかります。3 TB には 9 時間かかります。3TB を使用するのが一般的なドライブ構成です。一方、10GB のイーサネットネットワークの場合、レプリケーションにかかる時間はそれぞれ 20 分、1 時間となります。Ceph OSD に障害が発生した場合には、ストレージクラスターは、含まれるデータをプール内の他の Ceph OSD にレプリケートして復元することに注意してください。

ラックなどの大規模なドメインに障害が発生した場合は、ストレージクラスターが帯域幅を大幅に消費することになります。複数のラックで構成されるストレージクラスター (大規模なストレージ実装では一般的) を構築する際には、最適なパフォーマンスを得るために、「ファットツリー」設計でスイッチ間のネットワーク帯域幅をできるだけ多く利用することを検討してください。一般的な 10 GB のイーサネットスイッチには、48 個の 10 GB ポートと 4 個の 40 GB のポートがあります。スループットを最大にするには、Spine (背骨) で 40 GB ポートを使用します。または、QSFP+ および SFP+ ケーブルを使用する未使用の 10 GB ポートを別のラックおよびスパインルーターに接続するために、さらに 40 GB のポートに集計することを検討します。また、LACP モード 4でネットワークインターフェースを結合することも検討してください。また、特にバックエンドやクラスターのネットワークでは、ジャンボフレーム、最大伝送単位 (MTU) 9000を使用してください。

Red Hat Ceph Storage クラスタをインストールしてテストする前に、ネットワークのスループットを確認します。Ceph のパフォーマンスに関する問題のほとんどは、ネットワークの問題から始まります。Cat-6 ケーブルのねじれや曲がりといった単純なネットワークの問題は、帯域幅の低下につながります。フロント側のネットワークには、最低でも10 GB のイーサネットを使用してください。大規模なクラスターの場合には、バックエンドやクラスターのネットワークに 40GB のイーサネットを使用することを検討してください。

重要

ネットワークの最適化には、CPU/帯域幅の比率を高めるためにジャンボフレームを使用し、非ブロックのネットワークスイッチのバックプレーンを使用することを Red Hat は推奨します。Red Hat Ceph Storageでは、パブリックネットワークとクラスターネットワークの両方で、通信パスにあるすべてのネットワークデバイスに同じ MTU 値がエンドツーエンドで必要となります。Red Hat Ceph Storage クラスターを実稼働環境で使用する前に、環境内のすべてのノードとネットワーク機器で MTU 値が同じであることを確認します。

関連情報

  • 詳細は 『Red Hat Ceph Storage Configuration Guide』 の「MTU値の確認と設定」のセクションを参照してください。

2.5. Ceph 実行時の Linux カーネルのチューニングに関する考察

実稼働環境用の Red Hat Ceph Storage クラスターでは、一般的にオペレーティングシステムのチューニング (特に制限とメモリー割り当て) が有効です。ストレージクラスター内の全ノードに調整が設定されていることを確認します。また、Red Hat サポートでケースを開き、追加でアドバイスを求めることもできます。

Ceph OSD 用の空きメモリーの確保

Ceph OSD のメモリー割り当て要求時にメモリー不足関連のエラーが発生しないように、予備として確保する物理メモリーの量を具体的に設定します。Red Hat では、システムメモリーの量に応じて以下の設定を推奨しています。

  • 64 GB の場合は 1 GB を確保する。

    vm.min_free_kbytes = 1048576
  • 128 GB の場合は 2 GB を確保する。

    vm.min_free_kbytes = 2097152
  • 256 GB の場合は 3 GB を確保する。

    vm.min_free_kbytes = 3145728

ファイル記述子の増加

Ceph Object Gateway は、ファイル記述子が不足すると停止することがあります。Ceph Object Gatewayノードの /etc/security/limits.conf ファイルを変更して、Ceph Object Gateway のファイル記述子を増やすことができます。

ceph       soft    nofile     unlimited

大規模ストレージクラスターの ulimit 値の調整

Ceph OSD など、大規模なストレージクラスターで Ceph 管理コマンドを実行する場合は、以下の内容で管理コマンドを実行するノードごとに、/etc/security/limits.d/50-ceph.conf ファイルを作成します。

USER_NAME       soft    nproc     unlimited

USER_NAME は、Cephの管理コマンドを実行する root 以外のユーザーのアカウント名に置き換えます。

注記

Red Hat Enterprise Linux では、root ユーザーの ulimit 値は既にデフォルトで unlimited に設定されています。

2.6. OSD ノードで RAID コントローラーを使用する際の考慮事項

必要に応じて、OSD ノードで RAID コントローラーを使用することを検討してください。考慮すべき事項を以下に示します。

  • OSD ノードに 1 ~ 2 GB のキャッシュがインストールされている RAID コントローラーがある場合は、ライトバックキャッシュを有効にすると、I/O 書き込みスループットが向上する可能性があります。ただし、キャッシュは不揮発性である必要があります。
  • 最新の RAID コントローラーにはスーパーキャパシエーターがあり、電力損失イベント中に不揮発性 NAND メモリーに揮発性メモリーを流すのに十分な電力が提供されます。電源の復旧後に、特定のコントローラーとそのファームウェアがどのように動作するかを理解することが重要です。
  • RAID コントローラーによっては、手動の介入が必要になります。ハードドライブは、ディスクキャッシュをデフォルトで有効または無効にすべきかどうかに関わらず、オペレーティングシステムにアドバタイズします。ただし、特定の RAID コントローラーとファームウェアは、このような情報を提供しません。ファイルシステムが破損しないように、ディスクレベルのキャッシュが無効になっていることを確認します。
  • ライトバックキャッシュを有効にして、各 Ceph OSD データドライブにライトバックを設定して、単一の RAID 0 ボリュームを作成します。
  • Serial Attached SCSI (SAS) または SATA 接続の Solid-state Drive (SSD) ディスクも RAID コントローラーに存在する場合は、コントローラーとファームウェアが pass-through モードをサポートしているかどうかを確認します。pass-through モードを有効にすると、キャッシュロジックが回避され、通常は高速メディアの待ち時間が大幅に低くなります。

2.7. Object Gateway で NVMe を使用する際の考慮事項

必要に応じて、Ceph Object Gateway に NVMe を使用することを検討してください。

Red Hat Ceph Storage のオブジェクトゲートウェイ機能を使用する予定で、OSD ノードが NVMe ベースの SSD を使用している場合は、『実稼働向け Ceph オブジェクトゲートウェイ』「LVM での NVMe の最適な使用」に記載される手順に従ってください。これらの手順では、ジャーナルとバケットインデックスを SSD に一緒に配置する特別に設計された Ansible Playbook の使用方法を説明します。これにより、すべてのジャーナルを 1 つのデバイスに配置する場合に比べてパフォーマンスを向上させることができます。

2.8. Red Hat Ceph Storage の最小ハードウェア要件

Red Hat Ceph Storage は、プロプライエタリーではない、商用ハードウェアでも動作します。小規模な実稼働クラスターや開発クラスターは、適度なハードウェアで性能を最適化せずに動作させることができます。

Red Hat Ceph Storage は、デプロイメントがベアメタルであるか、コンテナー化されているかによって、要件が若干異なります。

注記

ディスク領域の要件は、/var/lib/ceph/ ディレクトリー下の Ceph デーモンのデフォルトパスに基づいています。

表2.1 ベアメタル

Process条件最小推奨

ceph-osd

プロセッサー

1x AMD64 または Intel 64

RAM

BlueStore OSD の場合、Red Hat では、OSD ホストごとに 16 GB の RAM をベースラインとし、デーモンごとにさらに 5 GB の RAM を追加することが推奨されます。

OS ディスク

ホストごとに 1x OS ディスク

ボリュームストレージ

デーモンごとに 1x ストレージドライブ

block.db

任意ですが、Red Hat は、デーモンごとに 1x SSD、NVMe または Optane パーティション、または論理ボリューム 1 つを推奨します。サイズ設定は、オブジェクト、ファイルおよび混合ワークロード用に BlueStore に block.data の 4%、ブロックデバイス、Openstack cinder 、および Openstack cinder ワークロード用に BlueStore に block.data の 1% です。

block.wal

任意、1x SSD、NVMe または Optane パーティション、またはデーモンごとに論理ボリューム。サイズが小さい (10 GB など) を使用し、block.db デバイスよりも高速の場合にのみ使用します。

ネットワーク

2x 10GB イーサネット NIC

ceph-mon

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 15 GB

監視ディスク

任意で、leveldb モニターデータ用 1x SSD ディスク

ネットワーク

2x 1 GB のイーサネット NIC

ceph-mgr

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ネットワーク

2x 1 GB のイーサネット NIC

ceph-radosgw

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 5 GB

ネットワーク

1x 1 GB のイーサネット NIC

ceph-mds

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 2 GB

この数は、設定可能な MDS キャッシュサイズに大きく依存します。通常、RAM 要件は、mds_cache_memory_limit 構成設定に設定された量の 2 倍です。また、これはデーモンのためのメモリーであり、全体的なシステムメモリではないことにも注意してください。

ディスク容量

デーモンごとに 2 MB、さらにロギングに必要な領域があり、構成されたログレベルに応じて異なる場合があります。

ネットワーク

2x 1 GB のイーサネット NIC

これは OSD と同じネットワークであることに注意してください。OSD で 10GB のネットワークを使用している場合は、MDS でも同じものを使用することで、レイテンシーの面で MDS が不利にならないようにする必要があります。

表2.2 コンテナー

Process条件最小推奨

ceph-osd-container

プロセッサー

OSD コンテナーごとに 1x AMD64 または Intel 64 CPU CORE

RAM

1 OSD コンテナーごとに最小 5 GB の RAM

OS ディスク

ホストごとに 1x OS ディスク

OSD ストレージ

OSD コンテナーごとに 1x ストレージドライブ。OS ディスクと共有できません。

block.db

任意ですが、Red Hat は、デーモンごとに SSD、NVMe または Optane パーティション、または lvm を 1 つ推奨します。サイズ設定は、オブジェクト、ファイルおよび混合ワークロード用に BlueStore に block.data の 4%、ブロックデバイス、Openstack cinder 、および Openstack cinder ワークロード用に BlueStore に block.data の 1% です。

block.wal

任意ですが、デーモンごとに 1x SSD、NVMe または Optane パーティション、または論理ボリューム。サイズが小さい (10 GB など) を使用し、block.db デバイスよりも高速の場合にのみ使用します。

ネットワーク

2x 10 GB のイーサネット NIC (10 GB の推奨)

ceph-mon-container

プロセッサー

mon-container ごとに 1x AMD64 または Intel 64 CPU CORE

RAM

mon-container あたり 3 GB

ディスク容量

mon-container ごとに 10 GB (50 GB 推奨)

監視ディスク

任意で、Monitor rocksdb データ用の 1x SSD ディスク

ネットワーク

2x 1 GB のイーサネット NIC (10 GB の推奨)

ceph-mgr-container

プロセッサー

mgr-containerごとに 1x AMD64 または Intel 64 CPU CORE

RAM

mgr-container あたり 3 GB

ネットワーク

2x 1 GB のイーサネット NIC (10 GB の推奨)

ceph-radosgw-container

プロセッサー

radosgw-container ごとに 1x AMD64 または Intel 64 CPU CORE

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 5 GB

ネットワーク

1x 1 GB のイーサネット NIC

ceph-mds-container

プロセッサー

mds-container ごとに 1x AMD64 または Intel 64 CPU CORE

RAM

mds-container あたり 3 GB

この数は、設定可能な MDS キャッシュサイズに大きく依存します。通常、RAM 要件は、mds_cache_memory_limit 構成設定に設定された量の 2 倍です。また、これはデーモンのためのメモリーであり、全体的なシステムメモリではないことにも注意してください。

ディスク容量

mds-container ごとに 2 GB、さらにデバッグロギングに必要な追加の領域を考慮すると、20GB から始めてみることが推奨されます。

ネットワーク

2x 1 GB のイーサネット NIC (10 GB の推奨)

これは、OSD コンテナーと同じネットワークであることに注意してください。OSD で 10GB のネットワークを使用している場合は、MDS でも同じものを使用することで、レイテンシーの面で MDS が不利にならないようにする必要があります。

2.9. 関連情報

第3章 Red Hat Ceph Storage のインストール要件

図3.1 前提条件のワークフロー

install prereq workflow

Red Hat Ceph Storage をインストールする前に、以下の要件をチェックして、各 Monitor、OSD、メタデータサーバー、およびクライアントノードを適宜準備します。

注記

Red Hat Ceph Storage のリリースおよび対応する Red Hat Ceph Storage パッケージのバージョンは、Red Hat カスタマーポータルの「What are the Red Hat Ceph Storage releases and corresponding Ceph package versions?」を参照してください。

3.1. 前提条件

  • ハードウェア が Red Hat Ceph Storage 4 の最小要件を満たしていることを確認します。

3.2. Red Hat Ceph Storage のインストールに関する要件チェックリスト

タスク必須セクション推奨事項

オペレーティングシステムのバージョンの確認

必要

「Red Hat Ceph Storage のオペレーティングシステム要件」

 

Ceph ノードの登録

必要

「Red Hat Ceph Storage ノードの CDN への登録およびサブスクリプションの割り当て」

 

Ceph ソフトウェアリポジトリーの有効化

必要

「Red Hat Ceph Storage リポジトリーの有効化」

 

OSD ノードでの RAID コントローラーの使用

不要

「OSD ノードで RAID コントローラーを使用する際の考慮事項」

RAID コントローラーでライトバックキャッシュを有効にすると、OSD ノードの小規模な I/O 書き込みスループットが増大する場合があります。

ネットワークの設定

必要

「Red Hat Ceph Storage のネットワーク設定の確認」

少なくとも、パブリックネットワークが必要です。ただし、クラスター通信用のプライベートネットワークが推奨されます。

ファイアウォールの設定

不要

「Red Hat Ceph Storage のファイアウォールの設定」

ファイアウォールは、ネットワークの信頼レベルを大きくすることができます。

Ansible ユーザーの作成

必要

sudo アクセスのある Ansible ユーザーの作成」

すべての Ceph ノードで Ansible ユーザーを作成する必要があります。

パスワードを使用しない SSH の有効化

必要

「Ansible のパスワードなし SSH の有効化」

Ansible で必須。

注記

デフォルトでは、ceph-ansible は、NTP/chronyd を要件としてインストールします。NTP/chronyd がカスタマイズされている場合は、「Red Hat Ceph Storage の手動インストール」セクションの「Red Hat Ceph Storage のネットワークタイムプロトコルの設定」を参照して、Ceph で正しく機能するように NTP/chronyd を構成する方法を理解してください。

3.3. Red Hat Ceph Storage のオペレーティングシステム要件

Red Hat Enterprise Linux のエンタイトルメントは、Red Hat Ceph Storage のサブスクリプションに含まれます。

Red Hat Ceph Storage 4 の初期リリースは、Red Hat Enterprise Linux 7.7 または Red Hat Enterprise Linux 8.1 でサポートされています。現行バージョンの Red Hat Ceph Storage 4.2 は、Red Hat Enterprise Linux 7.9、8.2、8.3、または 8.4 でサポートされています。

Red Hat Ceph Storage 4 は、RPM ベースのデプロイメントまたはコンテナーベースのデプロイメントでサポートされます。

重要

Red Hat Ceph Storage 4 を Red Hat Enterprise Linux 7 上に実行中のコンテナーにデプロイすると、Red Hat Enterprise Linux 8 コンテナーイメージで実行している Red Hat Ceph Storage 4 がデプロイされます。

すべてのノードで、同じオペレーティングシステムバージョン、アーキテクチャー、およびデプロイメントタイプを使用します。たとえば、AMD64 アーキテクチャーと Intel 64 アーキテクチャーの両方を備えたノードの混合、Red Hat Enterprise Linux 7 と Red Hat Enterprise Linux 8 オペレーティングシステムの両方を備えたノードの混合、RPM ベースのデプロイメントとコンテナーベースのデプロイメントの両方を備えたノードの混合は使用しないでください。

重要

Red Hat は、異種アーキテクチャー、オペレーティングシステムバージョン、またはデプロイメントタイプを持つクラスターをサポートしません。

SELinux

デフォルトでは、SELinux は Enforcing モードに設定され、ceph-selinux パッケージがインストールされます。SELinux の詳細は、『データのセキュリティーおよび強化機能ガイド』『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド』、および『Red Hat Enterprise Linux 8 SELinux の使用ガイド』を参照してください。

関連情報

要件のチェックリストに戻ります

3.4. Red Hat Ceph Storage ノードの CDN への登録およびサブスクリプションの割り当て

各 Red Hat Ceph Storage ノードをコンテンツ配信ネットワーク (CDN) に登録し、ノードがソフトウェアリポジトリーにアクセスできるように適切なサブスクリプションを割り当てます。各 Red Hat Ceph Storage ノードは、完全な Red Hat Enterprise Linux 8 ベースコンテンツおよび extras リポジトリーコンテンツにアクセスできる必要があります。特に記述がない限り、ストレージクラスター内のベアメタルおよびコンテナーノードで以下の手順を実行します。

注記

インストール時にインターネットにアクセスできないベアメタルの Red Hat Ceph Storage ノードの場合は、Red Hat Satellite サーバーを使用してソフトウェアコンテンツを提供します。ローカルの Red Hat Enterprise Linux 8 Server ISO イメージをマウントし、Red Hat Ceph Storage ノードを ISO イメージに指定します。詳細は、Red Hat サポート にお問い合わせください。

Red Hat Satellite サーバーに Ceph ノードの登録に関する詳細は、Red Hat カスタマーポータルの記事「How to Register Ceph with Satellite 6」および「How to Register Ceph with Satellite 5」を参照してください。

前提条件

  • 有効な Red Hat サブスクリプション
  • Red Hat Ceph Storage ノードはインターネットに接続できるようにする必要があります。
  • Red Hat Ceph Storage ノードへの root レベルのアクセス。

手順

  1. コンテナー デプロイメントの場合には、Red Hat Ceph Storage ノードがデプロイ中にインターネットにアクセス できない 場合に限ります。最初に、インターネットアクセスのあるノードで、以下の手順を実行する必要があります。

    1. ローカルのコンテナーレジストリーを起動します。

      Red Hat Enterprise Linux 7

      # docker run -d -p 5000:5000 --restart=always --name registry registry:2

      Red Hat Enterprise Linux 8

      # podman run -d -p 5000:5000 --restart=always --name registry registry:2

    2. registry.redhat.io がコンテナーレジストリーの検索パスにあることを確認します。

      編集するために、/etc/containers/registries.conf ファイルを開きます。

      [registries.search]
      registries = [ 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']

      registry.redhat.io がファイルに含まれていない場合は、これを追加します。

      [registries.search]
      registries = ['registry.redhat.io', 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']
    3. Red Hat カスタマーポータルから Red Hat Ceph Storage 4 イメージ、Prometheus イメージ、およびダッシュボードイメージをプルします。

      Red Hat Enterprise Linux 7

      # docker pull registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      # docker pull registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
      # docker pull registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:latest
      # docker pull registry.redhat.io/openshift4/ose-prometheus:v4.6
      # docker pull registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6

      Red Hat Enterprise Linux 8

      # podman pull registry.redhat.io/rhceph/rhceph-4-rhel8:latest
      # podman pull registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
      # podman pull registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:latest
      # podman pull registry.redhat.io/openshift4/ose-prometheus:v4.6
      # podman pull registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6

      注記

      Red Hat Enterprise Linux 7 および 8 はいずれも、Red Hat Enterprise Linux 8 をベースとした同じコンテナーイメージを使用します。

    4. イメージにタグを付けます。

      Prometheus のイメージタグのバージョンは、Red Hat Ceph Storage 4.2 の v4.6 です。

      Red Hat Enterprise Linux 7

       # docker tag registry.redhat.io/rhceph/rhceph-4-rhel8:latest LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8:latest
       # docker tag registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
       # docker tag registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:latest LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8:latest
       # docker tag registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:v4.6
       # docker tag registry.redhat.io/openshift4/ose-prometheus:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:v4.6

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。

      Red Hat Enterprise Linux 8

       # podman tag registry.redhat.io/rhceph/rhceph-4-rhel8:latest LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8:latest
       # podman tag registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
       # podman tag registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:latest LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8:latest
       # podman tag registry.redhat.io/openshift4/ose-prometheus-alertmanager:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:v4.6
       # podman tag registry.redhat.io/openshift4/ose-prometheus:v4.6 LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:v4.6

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
    5. etc/containers/registries.conf ファイルを編集し、ファイルに、ノードの FQDN とポートを追加し、保存します。

      [registries.insecure]
      registries = ['LOCAL_NODE_FQDN:5000']
      注記

      この手順は、ローカルの Docker レジストリーにアクセスするすべてのストレージクラスターノードで行う必要があります。

    6. イメージを、起動したローカルの Docker レジストリーにプッシュします。

      Red Hat Enterprise Linux 7

       # docker push --remove-signatures LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # docker push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
       # docker push --remove-signatures LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # docker push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:v4.6
       # docker push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:v4.6

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。

      Red Hat Enterprise Linux 8

       # podman push --remove-signatures LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-rhel8
       # podman push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
       # podman push --remove-signatures LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
       # podman push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:v4.6
       # podman push --remove-signatures LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:v4.6

      置き換え
      • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
    7. Red Hat Enterprise Linux 7 では、docker サービスを再起動します。

      # systemctl restart docker
      注記

      デプロイメント中に RedHat Ceph Storage ノードがインターネットにアクセスできない場合の all.yml ファイルの例は、「Red Hat Ceph Storage クラスターのインストール」インストールを参照してください。

  2. すべてのデプロイメントで、ベアメタル または コンテナー の場合:

    1. ノードを登録します。プロンプトが表示されたら、適切な Red Hat カスタマーポータルの認証情報を入力します。

      # subscription-manager register
    2. CDN から最新のサブスクリプションデータをプルします。

      # subscription-manager refresh
    3. Red Hat Ceph Storage で利用可能なサブスクリプションの一覧を表示します。

      # subscription-manager list --available --all --matches="*Ceph*"

      Red Hat Ceph Storage の利用可能なサブスクリプションのリストから Pool ID をコピーします。

    4. サブスクリプションを割り当てます。

      # subscription-manager attach --pool=POOL_ID
      置き換え
      • POOL_ID を、直前の手順で特定したプール ID に置き換えます。
    5. デフォルトのソフトウェアリポジトリーを無効にし、各バージョンの Red Hat Enterprise Linux でサーバーおよび追加のリポジトリーを有効にします。

      Red Hat Enterprise Linux 7

      # subscription-manager repos --disable=*
      # subscription-manager repos --enable=rhel-7-server-rpms
      # subscription-manager repos --enable=rhel-7-server-extras-rpms

      Red Hat Enterprise Linux 8

      # subscription-manager repos --disable=*
      # subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
      # subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms

  3. システムを更新して、最新のパッケージを受け取ります。

    1. Red Hat Enterprise Linux 7 の場合:

      # yum update
    2. Red Hat Enterprise Linux 8 の場合:

      # dnf update

関連情報

要件のチェックリストに戻ります

3.5. Red Hat Ceph Storage リポジトリーの有効化

Red Hat Ceph Storage をインストールする前に、インストール方法を選択する必要があります。Red Hat Ceph Storage では、以下の 2 つのインストール方法がサポートされます。

  • コンテンツ配信ネットワーク (CDN)

    インターネットに直接接続可能な Ceph ノードを持つ Ceph Storage クラスターの場合は、Red Hat Subscription Manager を使用して必要な Ceph リポジトリーを有効にします。

  • ローカルリポジトリー

    セキュリティー対策がインターネットにアクセスできない Ceph Storage クラスターでは、ISO イメージとして配信される単一のソフトウェアビルドから Red Hat Ceph Storage 4 をインストールします。これにより、ローカルリポジトリーをインストールできます。

前提条件

  • 有効なカスタマーサブスクリプション
  • CDN インストールの場合:

  • 有効にする場合は、Exttra Packages for Enterprise Linux (EPEL) ソフトウェアリポジトリーを無効にします。

    [root@monitor ~]# yum install yum-utils vim -y
    [root@monitor ~]# yum-config-manager --disable epel

手順

  • CDN インストールの場合:

    Ansible 管理ノード で、Red Hat Ceph Storage 4 Tools リポジトリーおよび Ansible リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms --enable=rhel-7-server-ansible-2.9-rpms

    Red Hat Enterprise Linux 8

    [root@admin ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms

  • デフォルトでは、Red Hat Ceph Storage リポジトリーは対応するノードの ceph-ansible により有効になります。リポジトリーを手動で有効にするには、以下を実行します。

    注記

    これらのリポジトリーは不要なため、コンテナー化されたデプロイメントでは有効にしないでください。

    Ceph Monitor ノード で、Red Hat Ceph Storage 4 Monitor リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@monitor ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Enterprise Linux 8

    [root@monitor ~]# subscription-manager repos  --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms

    Ceph OSD ノード で、Red Hat Ceph Storage 4 OSD リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Enterprise Linux 8

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms

    RBD ミラーリングCeph クライアントCeph Object GatewaysMetadata ServersNFSiSCSI ゲートウェイDashboard サーバー などのノード種別で Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@client ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms

    Red Hat Enterprise Linux 8

    [root@client ~]# subscription-manager repos  --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

  • ISO インストールの場合:

    1. Red Hat カスタマーポータルにログインします。
    2. Downloads をクリックして、Software & Download センターに移動します。
    3. Red Hat Ceph Storage エリアで Download Software をクリックして、最新バージョンのソフトウェアをダウンロードします。

関連情報

要件のチェックリストに戻ります

3.6. Red Hat Ceph Storage のネットワーク設定の確認

すべての Red Hat Ceph Storage ノードにはパブリックネットワークが必要です。Ceph クライアントが Ceph monitor ノードおよび Ceph OSD ノードに到達できるパブリックネットワークにネットワークインターフェースカードが設定されている必要があります。

Ceph がパブリックネットワークとは別のネットワークでハートビート、ピアリング、レプリケーション、および復元を実行できるように、クラスターネットワーク用のネットワークインターフェイスカードがある場合があります。

ネットワークインターフェースを設定し、変更を永続化します。

重要

Red Hat では、パブリックネットワークとプライベートネットワークの両方に単一のネットワークインターフェースカードを使用することは推奨していません。

前提条件

  • ネットワークに接続されたネットワークインターフェースカード。

手順

ストレージクラスター内のすべての Red Hat Ceph Storage ノードで、root ユーザーとして以下の手順を実施します。

  1. 以下の設定が、公開されているネットワークインターフェースカードに対応する /etc/sysconfig/network-scripts/ifcfg-* ファイルにあることを確認します。

    1. 静的 IP アドレスについて BOOTPROTO パラメーターは none に設定されます。
    2. ONBOOT パラメーターは yes に設定する必要があります。

      これが no に設定されていると、Ceph ストレージクラスターがリブート時にピアに機能しなくなる可能性があります。

    3. IPv6 アドレス指定を使用する場合には、IPV6_FAILURE_FATAL パラメーターを除き、IPV6INIT などの IPV6 パラメーターを yes に設定する必要があります。

      また、Ceph 設定ファイル /etc/ceph/ceph.conf を編集して Ceph に IPv6 を使用するように指示します。指定しないと、Ceph は IPv4 を使用します。

関連情報

要件のチェックリストに戻ります

3.7. Red Hat Ceph Storage のファイアウォールの設定

Red Hat CephStorage は、firewalld サービスを使用します。

Monitor デーモンは、Ceph Storage クラスター内で通信するために port 33006789 を使用します。

各 Ceph OSD ノードで、OSD デーモンは範囲 6800-7300 内の複数のポートを使用します。

  • パブリックネットワークを介してクライアントおよびモニターと通信するための 1 つ
  • クラスターネットワーク上で他の OSD にデータを送信する 1 つ (利用可能な場合)。それ以外の場合は、パブリックネットワーク経由でデータを送信します。
  • 可能な場合は、クラスターネットワークを介してハートビートパケットを交換するための 1 つ。それ以外の場合は、パブリックネットワーク経由

Ceph Manager (ceph-mgr) デーモンは、6800-7300 範囲内のポートを使用します。同じノード上で Ceph Monitor と ceph-mgr デーモンを共存させることを検討してください。

Ceph Metadata Server ノード (ceph-mds) はポート範囲 6800-7300 を使用します。

Ceph Object Gateway ノードは、デフォルトで 8080 を使用するように Ansible によって設定されます。ただし、デフォルトのポート (例: ポート 80) を変更できます。

SSL/TLS サービスを使用するには、ポート 443 を開きます。

firewalld が有効な場合には、以下の手順は任意です。デフォルトでは、ceph-ansible には group_vars/all.yml に以下の設定が含まれ、これにより適切なポートが自動的に開きます。

configure_firewall: True

前提条件

  • ネットワークハードウェアが接続されている。
  • ストレージクラスター内のすべてのノードへの root または sudo アクセスがある。

手順

  1. ストレージクラスター内のすべてのノードで firewalld サービスを起動します。これを有効にして、システムの起動時に実行し、実行していることを確認します。

    # systemctl enable firewalld
    # systemctl start firewalld
    # systemctl status firewalld
  2. すべてのモニターノードで、パブリックネットワークで port 3300 and 6789 を開きます。

    [root@monitor ~]# firewall-cmd --zone=public --add-port=3300/tcp
    [root@monitor ~]# firewall-cmd --zone=public --add-port=3300/tcp --permanent
    [root@monitor ~]# firewall-cmd --zone=public --add-port=6789/tcp
    [root@monitor ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent

    ソースアドレスに基づいてアクセスを制限するには、以下を実行します。

    firewall-cmd --zone=public --add-rich-rule='rule family=ipv4 \
    source address=IP_ADDRESS/NETMASK_PREFIX port protocol=tcp \
    port=6789 accept' --permanent
    置き換え
    • IP_ADDRESS は、Monitor ノードのネットワークアドレスに置き換えます。
    • NETMASK_PREFIX は、CIDR 表記のネットマスクに置き換えます。

      [root@monitor ~]# firewall-cmd --zone=public --add-rich-rule='rule family=ipv4 \
      source address=192.168.0.11/24 port protocol=tcp \
      port=6789 accept' --permanent

  3. すべての OSD ノードで、パブリックネットワークでポート 6800-7300 を開きます。

    [root@osd ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp
    [root@osd ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp --permanent

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

  4. すべての Ceph Manager (ceph-mgr) ノードで、パブリックネットワークでポート 6800-7300 を開きます。

    [root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp
    [root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp --permanent

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

  5. すべての Ceph Metadata Server (ceph-mds) ノードにおいて、パブリックネットワークでポート 6800-7300 を開きます。

    [root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp
    [root@monitor ~]# firewall-cmd --zone=public --add-port=6800-7300/tcp --permanent

    別のクラスターネットワークがある場合には、適切なゾーンでコマンドを繰り返します。

  6. すべての Ceph Object Gateway ノードで、パブリックネットワーク上の関連するポートを開きます。

    1. デフォルトの Ansible が設定されたポート 8080 を開くには、以下のコマンドを実行します。

      [root@gateway ~]# firewall-cmd --zone=public --add-port=8080/tcp
      [root@gateway ~]# firewall-cmd --zone=public --add-port=8080/tcp --permanent

      ソースアドレスに基づいてアクセスを制限するには、以下を実行します。

      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="8080" accept"
      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="8080" accept" --permanent
      置き換え
      • IP_ADDRESS は、Monitor ノードのネットワークアドレスに置き換えます。
      • NETMASK_PREFIX は、CIDR 表記のネットマスクに置き換えます。

        [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
        source address="192.168.0.31/24" port protocol="tcp" \
        port="8080" accept"

        [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
        source address="192.168.0.31/24" port protocol="tcp" \
        port="8080" accept" --permanent
    2. 必要に応じて、Ansible を使用して Ceph Object Gateway をインストールし、使用する Ceph Object Gateway を Ansible が構成するデフォルトのポートを 8080 からポート 80 に変更した場合は、次のポートを開きます。

      [root@gateway ~]# firewall-cmd --zone=public --add-port=80/tcp
      [root@gateway ~]# firewall-cmd --zone=public --add-port=80/tcp --permanent

      ソースアドレスに基づいてアクセスを制限するには、以下のコマンドを実行します。

      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="80" accept"
      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="80" accept" --permanent
      置き換え
      • IP_ADDRESS は、Monitor ノードのネットワークアドレスに置き換えます。
      • NETMASK_PREFIX は、CIDR 表記のネットマスクに置き換えます。

      [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="192.168.0.31/24" port protocol="tcp" \
      port="80" accept"

      [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="192.168.0.31/24" port protocol="tcp" \
      port="80" accept" --permanent
    3. 任意設定。SSL/TLS を使用するには、443 ポートを開きます。

      [root@gateway ~]# firewall-cmd --zone=public --add-port=443/tcp
      [root@gateway ~]# firewall-cmd --zone=public --add-port=443/tcp --permanent

      ソースアドレスに基づいてアクセスを制限するには、以下のコマンドを実行します。

      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="443" accept"
      firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="IP_ADDRESS/NETMASK_PREFIX" port protocol="tcp" \
      port="443" accept" --permanent
      置き換え
      • IP_ADDRESS は、Monitor ノードのネットワークアドレスに置き換えます。
      • NETMASK_PREFIX は、CIDR 表記のネットマスクに置き換えます。

      [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="192.168.0.31/24" port protocol="tcp" \
      port="443" accept"
      [root@gateway ~]# firewall-cmd --zone=public --add-rich-rule="rule family="ipv4" \
      source address="192.168.0.31/24" port protocol="tcp" \
      port="443" accept" --permanent

関連情報

要件のチェックリストに戻ります

3.8. sudo アクセスのある Ansible ユーザーの作成

Ansible は、ソフトウェアをインストールし、パスワードを要求せずに設定ファイルを作成するための root 権限を持つユーザーとして、すべての Red Hat Ceph Storage (RHCS) ノードにログインできる必要があります。Ansible を使用して Red Hat Ceph Storage クラスターをデプロイおよび設定する際に、ストレージクラスター内のすべてのノードにパスワードなしの root アクセスで Ansible ユーザーを作成する必要があります。

前提条件

  • ストレージクラスター内のすべてのノードへの root または sudo アクセスがある。

手順

  1. root ユーザーとしてノードにログインします。

    ssh root@HOST_NAME
    置き換え
    • HOST_NAME は、Ceph ノードのホスト名に置き換えます。

      # ssh root@mon01

      プロンプトに従い root パスワードを入力します。

  2. 新しい Ansible ユーザーを作成します。

    adduser USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # adduser admin

      重要

      ceph をユーザー名として使用しないでください。ceph ユーザー名は、Ceph デーモン用に予約されます。クラスター全体で統一されたユーザー名を使用すると、使いやすさが向上しますが、侵入者は通常、そのユーザー名をブルートフォース攻撃に使用するため、明白なユーザー名の使用は避けてください。

  3. このユーザーに新しいパスワードを設定します。

    # passwd USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # passwd admin

      プロンプトが表示されたら、新しいパスワードを 2 回入力します。

  4. 新規に作成されたユーザーの sudo アクセスを設定します。

    cat << EOF >/etc/sudoers.d/USER_NAME
    $USER_NAME ALL = (root) NOPASSWD:ALL
    EOF
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # cat << EOF >/etc/sudoers.d/admin
      admin ALL = (root) NOPASSWD:ALL
      EOF

  5. 正しいファイル権限を新しいファイルに割り当てます。

    chmod 0440 /etc/sudoers.d/USER_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      # chmod 0440 /etc/sudoers.d/admin

関連情報

要件のチェックリストに戻ります

3.9. Ansible のパスワードなし SSH の有効化

Ansible 管理ノードで SSH キーペアを生成し、ストレージクラスター内の各ノードに公開キーを配布して、Ansible がパスワードの入力を求められることなくノードにアクセスできるようにします。

注記

Cockpit の Web ベースのインターフェースを使用して Red Hat Ceph Storage をインストールする場合は、この手順は必要ありません。これは、Cockpit Ceph Installer により独自の SSH キーが生成されるためです。「クラスターのすべてのノードに Cockpit SSH キーをコピー」の手順は、「Cockpit Web インターフェースを使用した Red Hat Ceph Storage のインストール」の章になります。

前提条件

手順

  1. SSH キーペアを生成し、デフォルトのファイル名を受け入れ、パスフレーズを空のままにします。

    [ansible@admin ~]$ ssh-keygen
  2. 公開鍵をストレージクラスター内のすべてのノードにコピーします。

    ssh-copy-id USER_NAME@HOST_NAME
    置き換え
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。
    • HOST_NAME は、Ceph ノードのホスト名に置き換えます。

      [ansible@admin ~]$ ssh-copy-id ceph-admin@ceph-mon01

  3. ユーザーの SSH の config ファイルを作成します。

    [ansible@admin ~]$ touch ~/.ssh/config
  4. config ファイルを編集するために開きます。ストレージクラスター内の各ノードの Hostname および User オプションの値を設定します。

    Host node1
       Hostname HOST_NAME
       User USER_NAME
    Host node2
       Hostname HOST_NAME
       User USER_NAME
    ...
    置き換え
    • HOST_NAME は、Ceph ノードのホスト名に置き換えます。
    • USER_NAME は、Ansible ユーザーの新しいユーザー名に置き換えます。

      Host node1
         Hostname monitor
         User admin
      Host node2
         Hostname osd
         User admin
      Host node3
         Hostname gateway
         User admin

      重要

      ~/.ssh/config ファイルを設定すると、ansible-playbook コマンドを実行するたびに -u USER_NAME オプションを指定する必要がありません。

  5. ~/.ssh/config ファイルに正しいファイルパーミッションを設定します。

    [admin@admin ~]$ chmod 600 ~/.ssh/config

関連情報

要件のチェックリストに戻ります

第4章 Cockpit Web インターフェースを使用した Red Hat Ceph Storage のインストール

本章では、Cockpit Web ベースのインターフェースを使用して、Red Hat Ceph Storage クラスターおよびその他のコンポーネント (メタデータサーバー、Ceph クライアント、Ceph Object Gateway など) をインストールする方法を説明します。

このプロセスは、Cockpit Ceph インストーラーのインストール、Cockpit へのログイン、およびインストーラー内の異なるページを使用してクラスターのインストールの設定と開始で構成されます。

注記

Cockpit Ceph Installer は、実際のインストールを実行するために、ceph-ansible RPM によって提供される Ansible および Ansible Playbook を使用します。これらの Playbook を使用して、Cockpit を使用せずに Ceph をインストールすることは引き続き可能です。このプロセスは本章に関連し、直接の Ansible インストール tまたは Ansible Playbook を直接使用 と呼ばれています。

重要

Cockpit Ceph インストーラーは、現在 IPv6 ネットワークをサポートしていません。IPv6 ネットワークが必要な場合は、Ansible Playbook を使用して Ceph を直接 インストールします。

注記

Ceph の管理と監視に使用されるダッシュボード Web インターフェースは、Cockpit がバックエンドで使用する ceph-ansible RPM の Ansible Playbook によってデフォルトでインストールされます。したがって、Ansible Playbook を直接使用する場合や、Cockpit を使用して Ceph をインストールしたりしても、Dashboard の Web インターフェースもインストールされます。

4.1. 前提条件

  • Ansible Red Hat Ceph Storage の直接インストールに必要な 一般的な前提条件 を完了してください。
  • Firefox または Chrome の最新バージョン。
  • 複数のネットワークを使用してクラスター内トラフィック、クライアントからクラスターへのトラフィック、RADOS ゲートウェイトラフィック、または iSCSI トラフィックをセグメント化する場合は、関連するネットワークがホスト上で既に構成されていることを確認してください。詳細は、『ハードウェアガイド』「ネットワークの留意事項」と、「Cockpit Ceph Installer のネットワークページの完了」のこの章のこのセクションを参照してください。
  • Cockpit Web ベースのインターフェースのデフォルトポート 9090 にアクセスできることを確認します。

4.2. インストール要件

  • Ansible 管理ノードとして機能する 1 つのノード。
  • パフォーマンスメトリックおよびアラートプラットフォームを提供するノード。これは、Ansible 管理ノードと同じ場所に配置することができます。
  • Ceph クラスターを構成する 1 つ以上のノード。インストーラーは、Development/POC と呼ばれるオールインワンインストールをサポートします。このモードでは、全 Ceph サービスを同じノードから実行でき、データレプリケーションはデフォルトでホストレベルの保護ではなく、ディスクにデフォルト設定されます。

4.3. Cockpit Ceph Installer のインストールおよび設定

Cockpit Ceph Installer を使用して Red Hat Ceph Storage クラスターをインストールする前に、Cockpit Ceph Installer を Ansible 管理ノードにインストールする必要があります。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • Ansible アプリケーションで使用する ansible ユーザーアカウント。

手順

  1. Cockpit がインストールされていることを確認します。

    $ rpm -q cockpit

    以下に例を示します。

    [admin@jb-ceph4-admin ~]$ rpm -q cockpit
    cockpit-196.3-1.el8.x86_64

    上記の例と同様の出力が表示された場合は、確認用 Cockpit が実行している ステップに進みます。出力が package cockpit is not installed されていない場合は、Install Cockpit のステップに進みます。

  2. 必要に応じて Cockpit をインストールします。

    1. Red Hat Enterprise Linux 8 の場合:

      # dnf install cockpit
    2. Red Hat Enterprise Linux 7 の場合:

      # yum install cockpit
  3. Cockpit が実行中であることを確認します。

    # systemctl status cockpit.socket

    出力に Active: active (listening) が表示されている場合は、Red Hat Ceph Storage 用の Cockpit プラグインのインストール 手順に進みます。代わりに Active: inactive(dead) と表示される場合には、Cockpit の有効化 手順に進んでください。

  4. 必要に応じて、Cockpit を有効にします。

    1. systemctl コマンドを使用して、Cockpit を有効にします。

      # systemctl enable --now cockpit.socket

      以下のような行が表示されます。

      Created symlink /etc/systemd/system/sockets.target.wants/cockpit.socket → /usr/lib/systemd/system/cockpit.socket.
    2. Cockpit が実行中であることを確認します。

      # systemctl status cockpit.socket

      以下のような行が表示されます。

      Active: active (listening) since Tue 2020-01-07 18:49:07 EST; 7min ago
  5. Red Hat Ceph Storage 用の Cockpit Ceph Installer をインストールします。

    1. Red Hat Enterprise Linux 8 の場合:

      # dnf install cockpit-ceph-installer
    2. Red Hat Enterprise Linux 7 の場合:

      # yum install cockpit-ceph-installer
  6. Ansible ユーザーとして、sudo を使用してコンテナーカタログにログインします。

    注記

    デフォルトでは、Cockpit Ceph Installer は root ユーザーを使用して Ceph をインストールします。Ceph をインストールするための前提条件の一部として作成した Ansible ユーザーを使用するには、この手順の残りのコマンドを実行し、sudo を Ansible ユーザーとして実行します。

    Red Hat Enterprise Linux 7

    $ sudo docker login -u CUSTOMER_PORTAL_USERNAME https://registry.redhat.io

    [admin@jb-ceph4-admin ~]$ sudo docker login -u myusername https://registry.redhat.io
    Password:
    Login Succeeded!

    Red Hat Enterprise Linux 8

    $ sudo podman login -u CUSTOMER_PORTAL_USERNAME https://registry.redhat.io

    [admin@jb-ceph4-admin ~]$ sudo podman login -u myusername https://registry.redhat.io
    Password:
    Login Succeeded!

  7. registry.redhat.io がコンテナーレジストリーの検索パスにあることを確認します。

    1. 編集するために、/etc/containers/registries.conf ファイルを開きます。

      [registries.search]
      registries = [ 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']

      registry.redhat.io がファイルに含まれていない場合は、これを追加します。

      [registries.search]
      registries = ['registry.redhat.io', 'registry.access.redhat.com', 'registry.fedoraproject.org', 'registry.centos.org', 'docker.io']
  8. Ansible ユーザーとして、sudo を使用して ansible-runner-service を起動します。

    $ sudo ansible-runner-service.sh -s

    [admin@jb-ceph4-admin ~]$ sudo ansible-runner-service.sh -s
    Checking environment is ready
    Checking/creating directories
    Checking SSL certificate configuration
    Generating RSA private key, 4096 bit long modulus (2 primes)
    ..................................................................................................................................................................................................................................++++
    ......................................................++++
    e is 65537 (0x010001)
    Generating RSA private key, 4096 bit long modulus (2 primes)
    ........................................++++
    ..............................................................................................................................................................................++++
    e is 65537 (0x010001)
    writing RSA key
    Signature ok
    subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = RunnerServer, CN = jb-ceph4-admin
    Getting CA Private Key
    Generating RSA private key, 4096 bit long modulus (2 primes)
    .....................................................................................................++++
    ..++++
    e is 65537 (0x010001)
    writing RSA key
    Signature ok
    subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = RunnerClient, CN = jb-ceph4-admin
    Getting CA Private Key
    Setting ownership of the certs to your user account(admin)
    Setting target user for ansible connections to admin
    Applying SELINUX container_file_t context to '/etc/ansible-runner-service'
    Applying SELINUX container_file_t context to '/usr/share/ceph-ansible'
    Ansible API (runner-service) container set to rhceph/ansible-runner-rhel8:latest
    Fetching Ansible API container (runner-service). Please wait...
    Trying to pull registry.redhat.io/rhceph/ansible-runner-rhel8:latest...Getting image source signatures
    Copying blob c585fd5093c6 done
    Copying blob 217d30c36265 done
    Copying blob e61d8721e62e done
    Copying config b96067ea93 done
    Writing manifest to image destination
    Storing signatures
    b96067ea93c8d6769eaea86854617c63c61ea10c4ff01ecf71d488d5727cb577
    Starting Ansible API container (runner-service)
    Started runner-service container
    Waiting for Ansible API container (runner-service) to respond
    The Ansible API container (runner-service) is available and responding to requests
    
    Login to the cockpit UI at https://jb-ceph4-admin:9090/cockpit-ceph-installer to start the install

    出力の最後の行には、Cockpit Ceph Installer の URL が含まれます。上記の例では、URL は https://jb-ceph4-admin:9090/cockpit-ceph-installer です。お使いの環境で出力される URL を書き留めておきます。

4.4. Cockpit Ceph Installer SSH 鍵をクラスター内のすべてのノードにコピーします。

Cockpit Ceph Installer は、SSH を使用してクラスター内のノードに接続し、設定します。これを実行するために、インストーラーは SSH キーペアを生成し、パスワードを求められることなくノードにアクセスできるようにします。SSH 公開鍵はクラスター内のすべてのノードに転送される必要があります。

前提条件

手順

  1. Ansible 管理ノードに Ansible ユーザーとしてログインします。

    ssh ANSIBLE_USER@HOST_NAME

    以下に例を示します。

    $ ssh admin@jb-ceph4-admin
  2. SSH 公開鍵を最初のノードにコピーします。

    sudo ssh-copy-id -f -i /usr/share/ansible-runner-service/env/ssh_key.pub _ANSIBLE_USER_@_HOST_NAME_

    以下に例を示します。

    $ sudo ssh-copy-id -f -i /usr/share/ansible-runner-service/env/ssh_key.pub admin@jb-ceph4-mon
    /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/usr/share/ansible-runner-service/env/ssh_key.pub"
    admin@192.168.122.182's password:
    
    Number of key(s) added: 1
    
    Now try logging into the machine, with:   "ssh 'admin@jb-ceph4-mon'"
    and check to make sure that only the key(s) you wanted were added.

    クラスターのすべてのノードに対してこの手順を繰り返します。

4.5. Cockpit へのログイン

Cockpit Ceph Installer の Web インターフェースは、Cockpit にログインして確認することができます。

前提条件

手順

  1. Web ブラウザーで URL を開きます。

    cockpit login empty fields
  2. Ansible ユーザー名およびそのパスワードを入力します。

    cockpit login user pass filled
  3. 特権タスクにパスワードを再使用 するラジオボタンをクリックします。

    cockpit login reuse password enabled
  4. ログイン をクリックします。

    cockpit login reuse click log in
  5. Welcome ページをチェックして、インストーラーの動作方法とインストールプロセスの全体的なフローを確認します。

    cockpit welcome page

    Welcome ページで情報を確認したら、Web ページの右下隅にある Environment ボタンをクリックします。

4.6. Cockpit Ceph インストーラーの環境ページの完了

Environment ページでは、使用するインストールソースや、ストレージにハードディスクドライブ (HDD) とソリッドステートドライブ (SSD) を使用する方法など、クラスターの全体的な側面を構成できます。

前提条件

注記

続いて表示されるダイアログには、一部の設定の右側にあるツールチップがあります。これを表示するには、そのあたりに i のようなアイコンにマウスカーソルを合わせたカーソルをかざすようにカーソルを合わせます。

手順

  1. インストールソース を選択します。Red Hat カスタマーポータルからダウンロードした CD イメージを使用するには、Red Hat Subscription Manager からリポジトリーを使用するか、ISO を選択します。

    cockpit installation source

    Red Hat を選択した場合は、他のオプションを指定せずに Target VersionRHCS 4 に設定されます。ISO を選択すると、Target Version が ISO イメージファイルに設定されます。

    重要

    ISO を選択する場合、イメージファイルは /usr/share/ansible-runner-service/iso ディレクトリーにあり、その SELinux コンテキストは container_file_t に設定する必要があります。

    重要

    インストールソースコミュニティー オプションおよび ディストリビューション オプションには対応していません。

  2. Cluster Type を選択します。実稼働 の選択では、CPU 番号やメモリーサイズなどの特定のリソース要件を満たしていないと、インストールが続行できなくなります。リソース要件を満たしている場合でもクラスターのインストールを続行できるようにするには、Development/POC を選択します。

    cockpit cluster type
    重要

    Development/POC モードは、実稼働環境で使用する Ceph クラスターをインストールしないでください。

  3. Service Account Login および Service Account Token を設定します。Red Hat レジストリーサービスアカウントがない場合は、レジストリーサービスアカウントの Web ページ を使用して作成します。

    cockpit service account
  4. Configure FirewallON に設定して、Ceph サービスのポートを開くルールを firewalld に適用します。firewalld を使用していない場合は、OFF 設定を使用します。

    cockpit firewall
  5. 現在、Cockpit Ceph Installer は IPv4 のみをサポートしています。IPv6 サポートが必要な場合は、Cockpit Ceph Installer を使用を停止し、Ansible スクリプトを直接 使用して Ceph のインストールに進む必要があります。

    cockpit network connectivity
  6. OSD TypeBlueStore または FileStore に設定します。

    cockpit osd type
    重要

    BlueStore はデフォルトの OSD タイプです。以前のバージョンでは、Ceph は FileStore をオブジェクトストアとして使用していました。BlueStore はより多くの機能を提供し、パフォーマンスを向上させるため、この形式は Red Hat Ceph Storage 4.0 で非推奨になっています。FileStore は依然として使用できますが、サポート例外が必要です。BlueStore の詳細は、『アーキテクチャーガイド』「Ceph BlueStore」を参照してください。

  7. Flash ConfigurationJournal/Logs または OSD データ に設定します。ソリッドステートドライブ (SSD) を使用している場合は、NVMe または従来の SATA/SAS インターフェースのどちらを使用する場合でも、実際のデータがハードディスクドライブ (HDD) に保存されている間、ジャーナルとログの書き込みにのみ使用することを選択できます。ジャーナリング、ログ、およびデータに SSD を使用し、CephOSD 機能に HDD を使用しないでください。

    cockpit flash configuration
  8. EncryptionNone または Encrypted に設定します。これは、LUKS1 形式を使用したストレージデバイスの残り暗号化を指します。

    cockpit encryption
  9. インストールタイプContainer または RPM に設定します。従来は、Red Hat Enterprise Linux にソフトウェアをインストールするのに Red Hat Package Manager (RPM) が使用されていました。これで、RPM またはコンテナーを使用して Ceph をインストールできます。コンテナーを使用して Ceph をインストールすると、サービスを分離して共存させることができるため、ハードウェアの使用率が向上します。

    cockpit installation type

  10. すべての環境設定を確認し、Web ページの右下隅にある Hosts ボタンをクリックします。

    cockpit hosts button

4.7. Cockpit Ceph インストーラーの Hosts ページの完了

Hosts のページでは、Ceph をインストールするホストと各ホストが使用するロールについて Cockpit Ceph Installer に通知することができます。ホストを追加すると、インストーラーは SSH と DNS 接続の有無をチェックします。

前提条件

手順

  1. Add Host(s) ボタンをクリックします。

    Add Host(s) button
  2. Ceph OSD ノードのホスト名を入力し、OSD のチェックボックスを選択して 追加 ボタンをクリックします。

    Add monitor node(s)

    最初の Ceph OSD ノードが追加されます。

    The first OSD node is shown in the inventory

    実稼働クラスターの場合、少なくとも 3 つの Ceph OSD ノードを追加するまで、この手順を繰り返します。

  3. 必要に応じて、ホスト名のパターンを使用してノードの範囲を定義します。たとえば、jb-ceph4-osd2jb-ceph4-osd3 を同時に追加するには、jb-ceph4-osd[2-3] を入力します。

    Add OSDs using pattern range

    jb-ceph4-osd2jb-ceph4-ods3 の両方が追加されます。

    Multiple OSDs are added to the inventory

  4. クラスター内の他のノードについて上記の手順を繰り返します。

    1. 実稼働クラスターの場合は、少なくとも 3 つの Ceph Monitor ノードを追加します。ダイアログでは、ロールは MON として一覧表示されます。
    2. Metrics の役割を持つノードを追加します。Metrics ロールは Grafana および Prometheus をインストールし、Ceph クラスターのパフォーマンスに関するリアルタイムの洞察を提供します。これらのメトリクスは Ceph Dashboard に提示されています。これにより、クラスターの監視および管理が可能になります。Dashboard、Grafana、および Prometheus のインストールが必要です。Ansible Administration ノードでメトリック関数を同じ場所に配置できます。これを実行する場合は、ノードのシステムリソースが スタンドアロンのメトリックノードに必要とされるもの よりも大きいことを確認します。
    3. 必要に応じて MDS ロールを持つノードを追加します。MDS ロールは Ceph Metadata Server (MDS) をインストールします。Ceph File System をデプロイするには、メタデータサーバーデーモンが必要です。
    4. 必要に応じて RGW ロールを持つノードを追加します。RGW ロールは、Ceph Object Gateway もインストールします。RADOS ゲートウェイは、librados API 上に構築されたオブジェクトストレージインターフェースで、Ceph ストレージクラスターに RESTful ゲートウェイを提供するアプリケーションを提供します。Amazon S3 および OpenStack Swift API をサポートします。
    5. 必要に応じて iSCSI ロールを持つノードを追加します。iSCSI ロールは iSCSI ゲートウェイをインストールするため、iSCSI で Ceph ブロックデバイスを共有することができます。Ceph で iSCSI を使用するには、マルチパス I/O 用に iSCSI ゲートウェイを少なくとも 2 つのノードにインストールする必要があります。
  5. 必要に応じて、ノードを追加する際に複数のロールを選択して、同じノードに複数のサービスを割り当てます。

    Colocate multiple services on a node

    デーモンを同じ場所に配置するデーモンの詳細は、『インストールガイド』「コンテナー化された Ceph デーモンのコロケーション」を参照してください。

  6. 必要に応じて、テーブルのロールをオンまたはオフにして、ノードに割り当てられたロールを変更します。

    Modify roles in table
  7. 必要に応じて、ノードを削除するには、削除するノードの行の右端にあるケバブアイコンをクリックし、Delete をクリックします。

    Delete a node
  8. クラスター内のすべてのノードを追加したら、ページの右下隅にある Validate ボタンをクリックして、必要なロールをすべて設定します。

    Validate nodes
注記

実稼働クラスターの場合は、3 つまたは 5 台のモニターがない場合に Cockpit Ceph インストーラーは続行されません。この例では、Cluster TypeDevelopment/POC に設定されているため、インストールは 1 つのモニターのみを続行できます。

4.8. Cockpit Ceph インストーラーの Validate ページの完了

Validate ページでは、Hosts ページで指定したノードをプローブし、使用するロールのハードウェア要件を満たしていることを確認してください。

手順

  1. Probe Hosts ボタンをクリックします。

    Click the Probe Hosts button

    続行するには、OK ステータス を持つホストを少なくとも 3 台選択する必要があります。

  2. 必要に応じて、ホストについて警告またはエラーが生成された場合は、ホストのチェックマークの左側にある矢印をクリックして、問題を表示します。

    Validate errors
    Validate errors details
    重要

    Cluster TypeProduction に設定すると、生成されたエラーによって StatusNOTOK となり、インストール用に選択できなくなります。エラーを解決する方法は、次の手順を参照してください。

    重要

    Cluster TypeDevelopment/POC に設定すると、生成されたエラーは警告として一覧表示されるため、Status は常に OK になります。これにより、ホストが要件や提案を満たしているかどうかに関係なく、ホストを選択して Ceph をインストールできます。必要に応じて警告を解決できます。警告を解決する方法については、次の手順を参照してください。

  3. 必要に応じて、エラーと警告を解決するには、以下のメソッドを 1 つ以上使用します。

    1. エラーや警告を解決する最も簡単な方法は、特定のロールを完全に無効にしたり、1 台のホストでロールを無効にして、必要なリソースがある別のホストで有効にすることです。

      Development/POC クラスターをインストールしている場合は、警告が残っていても安心して進めることができ、実稼働 クラスターをインストールする場合は、少なくとも 3 台のホストに割り当てられたロールに必要なリソースがすべて揃っていて、警告が残っていても安心して進めることができる組み合わせが見つかるまで、ロールの有効化と無効化を試してみてください。

    2. 必要なロールの要件を満たす新規ホストを使用することもできます。まず、ホスト ページに戻り、問題のあるホストを削除します。

      Delete the host

      次に、新規ホストを追加 します。

    3. ホストのハードウェアをアップグレードするか、または何らかの方法で要件または提案を満たすには、最初にホストに変更を加えてから、再度 ホストのプローブ をクリックします。オペレーティングシステムを再インストールする必要がある場合は、再度 SSH キーをコピーする 必要があります。
  4. ホストの横にあるチェックボックスを選択して、Red Hat Ceph Storage をインストールするホストを選択します。

    Select hosts for installation
    重要

    実稼働クラスターをインストールする場合は、インストール用にエラーを選択する前にエラーを解決する必要があります。

  5. ページの右下隅の Network ボタンをクリックして、クラスターのネットワークを確認し、設定します。

    Click the Network button

4.9. Cockpit Ceph インストーラーのネットワークページの完了

Network ページでは、特定のクラスター通信タイプを特定のネットワークに分離することができます。これには、クラスターのホスト全体に複数の異なるネットワークを設定する必要があります。

重要

Network ページは、Validate ページで実行されたプローブから収集された情報を使用して、ホストがアクセスできるネットワークを表示します。現在、Network ページにすでに進む場合は、新規ネットワークをホストに追加したり、Validate ページに戻り、ホストを再プローブしてから、再度 Network ページに移動して新しいネットワークを使用することができません。選択のためには表示されません。Network ページに移動してからホストに追加したネットワークを使用するには、Web ページを完全に更新し、最初からインストールを再起動する必要があります。

重要

実稼働クラスターの場合は、クラスター内トラフィックをクライアントからクラスターへのトラフィックから別々の NIC に分離する必要があります。クラスタートラフィックの種別を分離する他に、Ceph クラスターの設定時に、ネットワークについて考慮すべき他の考慮点があります。詳細は、『ハードウェアガイド』「ネットワークの考慮事項」を参照してください。

前提条件

手順

  1. ネットワークページで設定できるネットワーク種別を書き留めておきます。各タイプには独自の列があります。クラスターネットワーク および パブリックネットワーク の列は常に表示されます。RADOS Gateway ロールでホストをインストールする場合は、S3 Network 列が表示されます。iSCSI ロールでホストをインストールする場合は、iSCSI ネットワーク の列が表示されます。以下の例では、Cluster NetworkPublic Network、および S3 Network の列が表示されます。

    Network page and network types
  2. 各ネットワーク種別に選択できるネットワークを書き留めておきます。特定のネットワーク種別を構成する全ホストで利用可能なネットワークのみが表示されます。以下の例では、クラスター内の全ホストで利用可能なネットワークが 3 つあります。3 つのネットワークはすべて、ネットワーク種別を構成する全ホストセットで利用可能であるため、各ネットワーク種別には同じ 3 つのネットワークが一覧表示されます。

    Networks available for selection

    利用可能な 3 つのネットワークは、192.168.122.0/24192.168.123.0/24、および 192.168.124.0/24 です。

  3. 各ネットワークが操作する速度を書き留めておきます。これは、特定のネットワークに使用される NIC の速度です。以下の例では、192.168.123.0/24 および 192.168.124.0/24 は 1,000 mbps になります。Cockpit Ceph Installer は 192.168.122.0/24 ネットワークの速度を把握できませんでした。

    Network speeds
  4. 各ネットワークタイプに使用するネットワークを選択します。実稼働クラスターの場合は、Cluster Network および Public Network 用に別個のネットワークを選択する必要があります。Development/POC クラスターでは、両方のタイプに同じネットワークを選択するか、すべてのホストにネットワークが 1 つのみ設定されている場合は、そのネットワークのみが表示され、他のネットワークを選択できなくなります。

    Select networks

    192.168.122.0/24 ネットワークは パブリックネットワーク に使用され、192.168.123.0/24 ネットワークが クラスターネットワーク に使用されます。また、192.168.124.0/24 ネットワークは S3 ネットワーク に使用されます。

  5. ページの右下隅にある Review ボタンをクリックして、インストール前にクラスター設定全体を確認します。

    Click the Review button

4.10. インストール設定の確認

Review ページを使用すると、前のページで設定した Ceph クラスターのインストール設定の詳細と、以前のページに含まれていなかったホストに関する詳細を表示できます。

前提条件

手順

  1. レビューページを表示します。

    View the Review page
  2. Review ページに表示されるように、各ページの情報が予想どおりに表示されていることを確認します。Environment ページの情報の概要が 1Hosts ページが 2Validate ページが 3Network ページが 4、ホストの詳細 (前のページには含まれていなかったいくつかの追加の詳細を含む) が 5 にあります。

    Review page highlights
  3. ページの右下隅にある Deploy ボタンをクリックして、実際のインストールプロセスを確定および開始できる Deploy ページに移動します。

    Click the Deploy button

4.11. Ceph クラスターのデプロイ

Deploy ページを使用すると、インストール設定をネイティブの Ansible 形式で保存し、必要に応じてそれらの設定の確認または変更、インストールの開始、その進捗の監視、インストールが正常に完了した後にクラスターのステータスを表示することができます。

前提条件

手順

  1. ページの右下隅にある Save ボタンをクリックして、実際にインストールを実行するために Ansible が使用する Ansible Playbook にインストール設定を保存します。

    Click the Save button
  2. 必要に応じて、Ansible 管理ノードにある Ansible Playbook の設定を表示するか、またはカスタマイズします。Playbook は /usr/share/ceph-ansible にあります。Ansible Playbook の詳細と、これらを使用してインストールをカスタマイズする方法については、「Red Hat Ceph Storage クラスターのインストール」を参照してください。
  3. Grafana およびダッシュボードのデフォルトユーザー名およびパスワードを保護します。Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。
  4. ページの右下隅にある Deploy ボタンをクリックして、インストールを開始します。

    Click the Deploy button
  5. 実行中のインストールの進捗を確認します。

    1 にある情報は、インストールが実行しているかどうか、開始時間、および経過時間を示します。2 にある情報は、試行された Ansible タスクの概要を示しています。3 にある情報は、インストールされているロールまたはインストールしているロールを示しています。緑色は、そのロールに割り当てられたすべてのホストにそのロールがインストールされているロールを表します。青色は、ロールが割り当てられているホストが依然としてインストールされているロールを表します。4 の場合は、現在のタスクの詳細を表示したり、失敗したタスクを表示できます。Filter by メニューを使用して、現在のタスクと失敗したタスクを切り換えます。

    Installation progress

    ロール名は、Ansible インベントリーファイルから取得されます。mons は Monitors で、mgrs は Managers で、osd は Object Storage Devices で、mdss はメタデータサーバーで、rgws は RADOS ゲートウェイで、metrics はダッシュボードメトリクスの Grafana および Prometheus サービスです。スクリーンショットの例には表示されません。iscsigws は iSCSI ゲートウェイです。

  6. インストールが完了したら、ページの右下隅にある Complete ボタンをクリックします。これにより、ceph status コマンドの出力と Dashboard のアクセス情報を表示するウィンドウが開きます。

    Complete button
  7. 以下の例のクラスターステータス情報を、クラスターのクラスターステータス情報と比較します。この例では、すべての OSD が稼働中、およびすべてのサービスがアクティブな正常なクラスターを示しています。PG は、active+clean 状態です。クラスターの一部の要素が同一ではない場合は、『トラブルシューティングガイド』で問題の解決方法に関する情報を参照してください。

    Ceph Cluster Status Window
  8. Ceph Cluster Status ウィンドウ下部に、URL、ユーザー名、パスワードなど、Dashboard のアクセス情報が表示されます。この情報を書き留めておいてください。

    Dashboard access information
  9. ダッシュボードにアクセス するには、ダッシュボードガイド と共に前のステップの情報を使用します。

    Dashboard

    ダッシュボードは Web インターフェースを提供するので、Red Hat Ceph Storage クラスターを管理および監視することができます。詳細は、『ダッシュボードガイド』を参照してください。

  10. オプション: cockpit-ceph-installer.log ファイルを表示します。このファイルは、作成された選択のログを記録し、生成されたプローブプロセスに関連する警告を記録します。これは、インストーラースクリプトを実行したユーザーのホームディレクトリー ansible-runner-service.sh にあります。

第5章 Ansible を使用した Red Hat Ceph Storage のインストール

本章では、Ansible アプリケーションを使用して Red Hat Ceph Storage クラスターおよびその他のコンポーネントをデプロイする方法を説明します (メタデータサーバーや Ceph Object Gateway など)。

5.1. 前提条件

5.2. Red Hat Ceph Storage クラスターのインストール

Playbook ceph-ansible で Ansible アプリケーションを使用して、ベアメタルまたはコンテナーに Red Hat Ceph Storage をインストールします。実稼働環境で Ceph ストレージクラスターを使用するには、最小で 3 つの監視ノードと、複数の OSD デーモンが含まれる OSD ノードが必要です。通常、実稼働環境で実行されている一般的な Ceph ストレージクラスターは、10 台以上のノードで構成されます。

以下の手順では、特に指示しない限り、Ansible 管理ノードからコマンドを実行します。この手順は、指定しない限り、ベアメタルおよびコンテナーのデプロイメントの両方に適用されます。

重要

Ceph は 1 つのモニターで実行できますが、実稼働クラスターで高可用性を確保するためには、Red Hat は少なくとも 3 つのモニターノードを持つデプロイメントのみをサポートします。

重要

Red Hat Ceph Storage 4 を Red Hat Enterprise Linux 7.7 のコンテナーにデプロイすると、Red Hat Ceph Storage 4 が Red Hat Enterprise Linux 8 コンテナーイメージにデプロイされます。

前提条件

  • 有効なカスタマーサブスクリプションです。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • Ansible アプリケーションで使用する ansible ユーザーアカウント。
  • Red Hat Ceph Storage Tools および Ansible リポジトリーの有効化
  • ISO インストールの場合は、Ansible ノードに最新の ISO イメージをダウンロードします。『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage リポジトリーの有効化」の章の 「ISO のインストール」セクションを参照してください。

手順

  1. Ansible 管理ノードで root ユーザーアカウントとしてログインします。
  2. すべてのデプロイメント (ベアメタル または コンテナー 内) については、ceph-ansible パッケージをインストールします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# yum install ceph-ansible

    Red Hat Enterprise Linux 8

    [root@admin ~]# dnf install ceph-ansible

  3. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  4. 新しい yml ファイルを作成します。

    [root@admin ceph-ansible]# cp group_vars/all.yml.sample group_vars/all.yml
    [root@admin ceph-ansible]# cp group_vars/osds.yml.sample group_vars/osds.yml
    1. ベアメタル デプロイメント:

      [root@admin ceph-ansible]# cp site.yml.sample site.yml
    2. コンテナー デプロイメント:

      [root@admin ceph-ansible]# cp site-container.yml.sample site-container.yml
  5. 新しいファイルを編集します。

    1. group_vars/all.yml ファイルを編集するために開きます。

      重要

      カスタムストレージクラスター名の使用はサポートされていません。cluster パラメーターには ceph 以外の値を設定しないでください。カスタムストレージクラスター名は、librados、Ceph Object Gateway、RADOS ブロックデバイスミラーリングなどの Ceph クライアントでのみサポートされます。

      警告

      デフォルトでは、Ansible はインストール済みの再起動を試みますが、マスクされた firewalld サービスにより、Red Hat Ceph Storage デプロイメントが失敗する可能性があります。この問題を回避するには、all.yml ファイルで configure_firewall オプションを false に設定します。firewalld サービスを実行している場合は、all.yml ファイルで configure_firewall オプションを使用する必要はありません。

      注記

      ceph_rhcs_version オプションを 4 に設定すると、最新バージョンの Red Hat Ceph Storage 4 がプルされます。

      注記

      Red Hat は、group_vars/all.yml ファイルで dashboard_enabled オプションを True に設定し、これを False に変更しないことを推奨します。Dashboard を無効にする場合には、「Disabling the Ceph Dashboard」を参照してください。

      注記

      Dashboard 関連のコンポーネントはコンテナー化されています。したがって、ベアメタル または コンテナー のデプロイメントでは、「ceph_docker_registry_username」および「ceph_docker_registry_password」のパラメーターを追加して、ceph-ansible が、ダッシュボードに必要なコンテナーイメージを取得できるようにする必要があります。

      注記

      Red Hat レジストリーサービスアカウントがない場合は、レジストリーサービスアカウントの Web ページ を使用して作成します。トークンの作成および管理方法に関する詳細は、ナレッジベースアーティクル「Red Hat Container Registry Authentication」を参照してください。

      注記

      ceph_docker_registry_username および ceph_docker_registry_password パラメータにサービスアカウントを使用するだけでなく、カスタマーポータルの認証情報を使用することもできますが、ceph_docker_registry_password パラメータを暗号化してセキュリティーを確保してください。詳細は、「ansible-vault で Ansible のパスワード変数を暗号化する」を参照してください。

      1. CDN インストール用の all.yml ファイルの ベアメタル の例:

        fetch_directory: ~/ceph-ansible-keys
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
        重要

        Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。

        注記

        Red Hat Ceph Storage 4.2 で、インストールにローカルレジストリーを使用している場合は、Prometheus のイメージタグとして 4.6 を使用します。

      2. ISO インストール all.yml ファイルの ベアメタル の例:

        fetch_directory: ~/ceph-ansible-keys
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: iso
        ceph_rhcs_iso_path: /home/rhceph-4-rhel-8-x86_64.iso
        ceph_rhcs_version: 4
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
      3. all.yml ファイルの Containers の例:

        fetch_directory: ~/ceph-ansible-keys
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_image: rhceph/rhceph-4-rhel8
        ceph_docker_image_tag: latest
        containerized_deployment: true
        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_auth: true
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: registry.redhat.io/openshift4/ose-prometheus-node-exporter:v4.6
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: registry.redhat.io/openshift4/ose-prometheus:4.6
        alertmanager_container_image: registry.redhat.io/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
        重要

        Red Hat Ecosystem Catalog で最新のコンテナーイメージタグを検索し、最新のパッチが適用された最新のコンテナーイメージをインストールします。

        注記

        http または https プロキシーで到達可能なコンテナーレジストリーを使用する場合は、group_vars/all.yml ファイルで ceph_docker_http_proxy または ceph_docker_https_proxy 変数を設定する必要があります。

        ceph_docker_http_proxy: http://192.168.42.100:8080
        ceph_docker_https_proxy: https://192.168.42.100:8080

        プロキシー設定で一部のホストを除外する必要がある場合は、group_vars/all.yml ファイルで ceph_docker_no_proxy 変数を使用できます。

        ceph_docker_no_proxy: "localhost,127.0.0.1"
      4. デプロイメント中に Red Hat Ceph Storage ノードがインターネットにアクセスできない場合の、all.yml ファイルの Containers の例:

        fetch_directory: ~/ceph-ansible-keys
        monitor_interface: eth0 1
        public_network: 192.168.0.0/24
        ceph_docker_image: rhceph/rhceph-4-rhel8
        ceph_docker_image_tag: latest
        containerized_deployment: true
        ceph_docker_registry: LOCAL_NODE_FQDN:5000
        ceph_docker_registry_auth: false
        ceph_origin: repository
        ceph_repository: rhcs
        ceph_repository_type: cdn
        ceph_rhcs_version: 4
        dashboard_admin_user:
        dashboard_admin_password:
        node_exporter_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-node-exporter:v4.6
        grafana_admin_user:
        grafana_admin_password:
        grafana_container_image: LOCAL_NODE_FQDN:5000/rhceph/rhceph-4-dashboard-rhel8
        prometheus_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus:4.6
        alertmanager_container_image: LOCAL_NODE_FQDN:5000/openshift4/ose-prometheus-alertmanager:4.6
        1
        これは、パブリックネットワーク上のインターフェースです。
        置き換え
        • LOCAL_NODE_FQDN を、ローカルホストの FQDN に置き換えます。
      5. Red Hat Ceph Storage 4.2からは、dashboard_protocolhttps に設定されており、Ansible でダッシュボードと grafana の鍵と証明書が生成されます。ベアメタル または コンテナー デプロイメントでカスタム証明書の場合には、all.yml ファイルで、dashboard_crtdashboard_keygrafana_crtgrafana_key のAnsible インストーラーホストのパスを更新します。

        構文

        dashboard_protocol: https
        dashboard_port: 8443
        dashboard_crt: 'DASHBOARD_CERTIFICATE_PATH'
        dashboard_key: 'DASHBOARD_KEY_PATH'
        dashboard_tls_external: false
        dashboard_grafana_api_no_ssl_verify: "{{ True if dashboard_protocol == 'https' and not grafana_crt and not grafana_key else False }}"
        grafana_crt: 'GRAFANA_CERTIFICATE_PATH'
        grafana_key: 'GRAFANA_KEY_PATH'

    2. 全デプロイメントの場合には (ベアメタル または コンテナー)、group_vars/osds.ymlファイルを編集します。

      重要

      オペレーティングシステムがインストールされているデバイスに OSD をインストールしないでください。オペレーティングシステムと OSD 間で同じデバイスを共有すると、パフォーマンスの問題が発生することになります。

      ceph-ansible は ceph-volume ツールを使用して、Ceph の使用に向けてストレージデバイスを準備します。ストレージデバイスを使用するように osds.yml を設定し、特定のワークロードのパフォーマンスを最適化することができます。

      重要

      以下の例では、BlueStore オブジェクトストアを使用します。これは、Ceph がデバイスにデータを保存するのに使用する形式です。以前のバージョンでは、Ceph は FileStore をオブジェクトストアとして使用していました。BlueStore はより多くの機能を提供し、パフォーマンスを向上させるため、この形式は Red Hat Ceph Storage 4.0 で非推奨になっています。FileStore は依然として使用できますが、Red Hat サポート例外が必要です。BlueStore の詳細は、『Red Hat Ceph Storage アーキテクチャーガイド』「Ceph BlueStore」を参照してください。

      1. 自動検出

        osd_auto_discovery: true

        上記の例では、システム上の空のストレージデバイスをすべて使用して OSD を作成するため、明示的に指定する必要はありません。この ceph-volume ツールは、空のデバイスを確認するため、空ではないデバイスは使用されません。

      2. 簡易設定

        初回のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb

        または

        2 つ目のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
          - /dev/nvme0n1
          - /dev/sdc
          - /dev/sdd
          - /dev/nvme1n1

        または

        3 つ目のシナリオ

        lvm_volumes:
           - data: /dev/sdb
           - data: /dev/sdc

        または

        4 つ目のシナリオ

        lvm_volumes:
            - data: /dev/sdb
            - data:/dev/nvme0n1

        devices オプションのみを使用する場合には、ceph-volume lvm batch モードは OSD 設定を自動的に最適化します。

        最初のシナリオでは、devices を従来のハードドライブまたは SSD の場合には、デバイスごとに OSD が 1 つ作成されます。

        2 つ目のシナリオでは、従来のハードドライブと SSD が混在している場合、データは従来のハードドライブ (sdasdb) に配置され、BlueStore データベースは SSD (nvme0n1) にできる限り大きく作成されます。同様に、データは従来のハードドライブ (sdcsdd) に配置され、デバイスの順序に関係なく、SSD nvme1n1 に BlueStore データベースが作成されます。

        3 つ目のシナリオでは、データは従来のハードドライブ (sdbsdc) に置かれ、BlueStore データベースは同じデバイスに置かれます。

        4 番目のシナリオでは、従来のハードドライブ (sdb) および SSD (nvme1n1) にデータが配置され、BlueStore データベースが同じデバイスに配置されます。これは、BlueStore データベースが SSD に配置される devices ディレクティブの使用とは異なります。

        重要

        ceph-volume lvm batch mode コマンドは、従来のハードドライブおよび BlueStore データベースに SSD にデータを配置することで、OSD 最適化設定を作成します。使用する論理ボリュームとボリュームグループを指定する場合は、以下の 高度な設定 シナリオに従って、論理ボリュームとボリュームグループを直接作成できます。

      3. 高度な設定

        初回のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
        dedicated_devices:
          - /dev/sdx
          - /dev/sdy

        または

        2 つ目のシナリオ

        devices:
          - /dev/sda
          - /dev/sdb
        dedicated_devices:
          - /dev/sdx
          - /dev/sdy
        bluestore_wal_devices:
          - /dev/nvme0n1
          - /dev/nvme0n2

        最初のシナリオでは、OSD が 2 つあります。sda デバイスおよび sdb デバイスには、独自のデータセグメントと先行書き込みログがあります。追加のディクショナリー dedicated_devices を使用して、sdxsdy のデータベース (block.db とも呼ばれる) を分離します。

        2 つ目のシナリオでは、別のディクショナリー bluestore_wal_devices を使用して、NVMe デバイス nvme0n1 および nvme0n2 のログ先行書き込みを分離します。devices オプション、dedicated_devices オプション、bluestore_wal_devices, オプションを一緒に使用すると、OSD のすべてのコンポーネントを別々のデバイスに分離できます。このように OSD を配置すると、全体的なパフォーマンスが向上する場合があります。

      4. 事前作成された論理ボリューム

        初回のシナリオ

        lvm_volumes:
          - data: data-lv1
            data_vg: data-vg1
            db: db-lv1
            db_vg: db-vg1
            wal: wal-lv1
            wal_vg: wal-vg1
          - data: data-lv2
            data_vg: data-vg2
            db: db-lv2
            db_vg: db-vg2
            wal: wal-lv2
            wal_vg: wal-vg2

        または

        2 つ目のシナリオ

        lvm_volumes:
          - data: /dev/sdb
            db:    db-lv1
            db_vg: db-vg1
            wal: wal-lv1
            wal_vg: wal-vg1

        デフォルトでは、Ceph は論理ボリュームマネージャーを使用して OSD デバイスに論理ボリュームを作成します。上記の 単純な設定 および 高度な設定 例では、Ceph はデバイス上に論理ボリュームを自動的に作成します。lvm_volumes ディクショナリーを指定すると、Ceph で以前に作成した論理ボリュームを使用できます。

        最初のシナリオでは、データは専用の論理ボリューム、データベース、および WAL に置かれます。データ、データおよび WAL、またはデータおよびデータベースのみを指定することもできます。data: 行は、データの保存先の論理ボリューム名を指定し、data_vg: データの論理ボリュームが含まれるボリュームグループの名前を指定する必要があります。同様に、db: は、データベースが保存されている論理ボリュームを指定するために使用されます。db_vg: は、論理ボリュームが存在するボリュームグループを指定するために使用されます。wal: 行は、WAL が格納する論理ボリュームを指定し、wal_vg: 行は、それを含むボリュームグループを指定します。

        2 つ目のシナリオでは、実際のデバイス名が data: オプションに設定されているため、data_vg: オプションを指定する必要はありません。BlueStore データベースおよび WAL デバイスに、論理ボリューム名とボリュームグループの詳細を指定する必要があります。

        重要

        lvm_volumes: では、ボリュームグループと論理ボリュームを、事前に作成する必要があります。ボリュームグループと論理ボリュームは、ceph-ansible では作成されません。

        注記

        すべての NVMe SSD を使用する場合は、osds_per_device: 2 を設定します。詳細は、『Red Hat Ceph Storage インストールガイド』「すべての NVMe ストレージに OSD Ansible 設定の構成」を参照してください。

        注記

        Ceph OSD ノードのリブート後には、ブロックデバイスの割り当てが変更される可能性があります。たとえば、sdc は、sdd になる場合があります。従来のブロックデバイス名ではなく、/dev/disk/by-path/ デバイスパスなどの永続的な命名デバイスを使用できます。

  6. すべてのデプロイメント (ベアメタル または コンテナー) について、Ansible インベントリーファイルを作成してから、そのファイルを開いて編集します。

    [root@admin ~]# cd /usr/share/ceph-ansible/
    [root@admin ceph-ansible]# touch hosts

    それに応じて hosts ファイルを編集します。

    注記

    Ansible インベントリーの場所の編集に関する詳細は、「Ansible インベントリー の場所の設定」を参照してください。

    1. [grafana-server] の下にノードを追加します。このロールは Grafana および Prometheus をインストールし、Ceph クラスターのパフォーマンスに関するリアルタイムの洞察を提供します。これらのメトリクスは Ceph Dashboard に提示されています。これにより、クラスターの監視および管理が可能になります。Dashboard、Grafana、および Prometheus のインストールが必要です。Ansible Administration ノードでメトリック関数を同じ場所に配置できます。これを実行する場合は、ノードのシステムリソースが スタンドアロンのメトリックノードに必要とされるもの よりも大きいことを確認します。

      [grafana-server]
      GRAFANA-SERVER_NODE_NAME
    2. [mons] セクションに monitor ノードを追加します。

      [mons]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_2
      MONITOR_NODE_NAME_3
    3. [osds] セクションに OSD ノードを追加します。

      [osds]
      OSD_NODE_NAME_1
      OSD_NODE_NAME_2
      OSD_NODE_NAME_3
      注記

      ノード名が数値的に連続している場合は、ノード名の末尾に範囲指定子 ([1:10]) を追加できます。以下は例になります。

      [osds]
      example-node[1:10]
      注記

      新規インストールの OSD の場合、デフォルトのオブジェクトストア形式は BlueStore です。

    4. 必要に応じて、コンテナー デプロイメントで、[mon] セクションおよび [osd] セクションに同じノードを追加して、Ceph Monitor デーモンを 1 つのノードの Ceph OSD デーモンと同じ場所に配置します。詳細は、Additional Resources セクションで、Ceph デーモンの配置に関するリンクを参照してください。
    5. [mgrs] セクションに Ceph Manager (ceph-mgr) ノードを追加します。これは、Ceph Manager デーモンと Ceph Monitor デーモンを共存させます。

      [mgrs]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_2
      MONITOR_NODE_NAME_3
  7. 必要に応じて、すべてのデプロイメント (ベアメタル または コンテナー 内) ホスト固有のパラメーターを使用する場合は、ホストに固有のパラメーターが含まれるホストファイルで host_vars ディレクトリーを作成します。

    1. host_vars ディレクトリーを作成します。

      [ansible@admin ~]$ mkdir /usr/share/ceph-ansible/host_vars
    2. host_vars ディレクトリーに変更します。

      [ansible@admin ~]$ cd /usr/share/ceph-ansible/host_vars
    3. ホストファイルを作成します。ファイル名に、host-name-short-name 形式を使用します。以下に例を示します。

      [ansible@admin host_vars]$ touch tower-osd6
    4. 以下のように、ホスト固有のパラメーターでファイルを更新します。

      1. bare-metal デプロイメントでは、devices パラメーターを使用して OSD ノードが使用するデバイスを指定します。OSD が異なる名前のデバイスを使用する場合や、いずれかの OSD でデバイスのいずれかに障害が発生した場合に devices の使用が役に立ちます。

        devices:
            DEVICE_1
            DEVICE_2

        devices:
            /dev/sdb
            /dev/sdc

        注記

        デバイスを指定しない場合は、osds.yml ファイルで osd_auto_discovery パラメーターを true に設定します。

      2. すべてのデプロイメント (ベアメタル または コンテナー 内) で、Ansible でカスタム CRUSH 階層を作成する場合は、特定のホストファイルで osd_crush_location パラメーターを使用して、CRUSH マップの階層に OSD ホストがある場所を指定します。OSD の場所を指定するために、2 つ以上の CRUSH バケットタイプを指定し、1 つのバケットの typehost に指定する必要があります。デフォルトでは、これには、rootdatacenterroomrowpodpdurackchassis および host が含まれます。

        osd_crush_location:
            root: ROOT_BUCKET
            rack: RACK_BUCKET
            pod: POD_BUCKET
            host: CEPH_NODE_NAME

        osd_crush_location:
            root: my-root
            rack: my-rack
            pod: my-pod
            host: tower-osd6

  8. すべてのデプロイメント (ベアメタル または コンテナー 内) では、ログインするか、ansible ユーザーに切り替えます。

    1. Ansible が ceph-ansible Playbook で生成される一時的な値を保存する ceph-ansible-keys ディレクトリーを作成します。

      [ansible@admin ~]$ mkdir ~/ceph-ansible-keys
    2. /usr/share/ceph-ansible/ ディレクトリーに移動します。

      [ansible@admin ~]$ cd /usr/share/ceph-ansible/
    3. Ansible が Ceph ノードに到達できることを確認します。

      [ansible@admin ceph-ansible]$ ansible all -m ping -i hosts
  9. ceph-ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts
      注記

      Red Hat Ceph Storage を Red Hat Enterprise Linux Atomic Host ホストにデプロイする場合は、--skip-tags=with_pkg オプションを使用します。

      [user@admin ceph-ansible]$ ansible-playbook site-container.yml --skip-tags=with_pkg -i hosts
      注記

      デプロイメントの速度を増やすには、--forks オプションを ansible-playbook に指定します。デフォルトでは、ceph-ansible はフォークを 20 に設定します。この設定では、ノードを同時にインストールします。一度に最大 30 台までインストールするには、ansible-playbook --forks 30 PLAYBOOK FILE -i hosts を実行します。管理ノードのリソースが過剰に使用されていないことを確認するために、監視する必要があります。そうである場合は、--forks に渡される数を減らします。

  10. Ceph デプロイメントが完了するまで待ちます。

    出力例

    INSTALLER STATUS *******************************
    Install Ceph Monitor           : Complete (0:00:30)
    Install Ceph Manager           : Complete (0:00:47)
    Install Ceph OSD               : Complete (0:00:58)
    Install Ceph RGW               : Complete (0:00:34)
    Install Ceph Dashboard         : Complete (0:00:58)
    Install Ceph Grafana           : Complete (0:00:50)
    Install Ceph Node Exporter     : Complete (0:01:14)
  11. Ceph Storage クラスターのステータスを確認します。

    1. ベアメタル デプロイメント:

      [root@mon ~]# ceph health
      HEALTH_OK
    2. コンテナー デプロイメント:

      Red Hat Enterprise Linux 7

      [root@mon ~]# docker exec ceph-mon-ID ceph health

      Red Hat Enterprise Linux 8

      [root@mon ~]# podman exec ceph-mon-ID ceph health

      置き換え
      • ID は、Ceph Monitor ノードのホスト名に置き換えます。

        [root@mon ~]# podman exec ceph-mon-mon0 ceph health
        HEALTH_OK

  12. ベアメタル または コンテナー 内のすべてのデプロイメントについて、ストレージクラスターが rados を使用して機能していることを確認します。

    1. Ceph Monitor ノードから、8 つの配置グループ (PG) でテストプールを作成します。

      構文

      [root@mon ~]# ceph osd pool create POOL_NAME PG_NUMBER

      [root@mon ~]# ceph osd pool create test 8

    2. hello-world.txt というファイルを作成します。

      構文

      [root@mon ~]# vim FILE_NAME

      [root@mon ~]# vim hello-world.txt

    3. オブジェクト名 hello-world を使用して、hello-world.txt をテストプールにアップロードします。

      構文

      [root@mon ~]# rados --pool POOL_NAME put OBJECT_NAME OBJECT_FILE_NAME

      [root@mon ~]# rados --pool test put hello-world hello-world.txt

    4. テストプールからファイル名 fetch.txt として hello-world をダウンロードします。

      構文

      [root@mon ~]# rados --pool POOL_NAME get OBJECT_NAME OBJECT_FILE_NAME

      [root@mon ~]# rados --pool test get hello-world fetch.txt

    5. fetch.txt の内容を確認してください。

      [root@mon ~]# cat fetch.txt
      "Hello World!"
      注記

      ストレージクラスターのステータスを確認する他に、ceph-medic ユーティリティーを使用して Ceph Storage クラスター全体の診断を行うことができます。Red Hat Ceph Storage 4 の『トラブルシューティングガイド』ceph-medic をインストールおよび使用して Ceph Storage クラスターの検証」の章を参照してください。

関連情報

5.3. すべての NVMe ストレージに OSD Ansible 設定の構成

全体的なパフォーマンスを向上させるには、Ansible がストレージ用に不揮発性メモリー表現 (NVMe) デバイスのみを使用するように設定することができます。通常、デバイスごとに 1 つの OSD のみが構成されているため、NVMe デバイスの潜在的なスループットが十分に活用されていません。

注記

SSD と HDD を混在する場合、SSD は OSD のデータに使用されず、データベース (block.db) に使用されます。

注記

テストでは、各 NVMe デバイスに 2 つの OSD を設定すると、最適なパフォーマンスが得られます。Red Hat は、osds_per_device オプションを 2 に設定することを推奨しますが、必須ではありません。その他の値により、お使いの環境でパフォーマンスが向上します。

前提条件

  • Ansible 管理ノードへのアクセス
  • ceph-ansible パッケージのインストール。

手順

  1. group_vars/osds.ymlosds_per_device: 2 を設定します。

    osds_per_device: 2
  2. devices の下に NVMe デバイスを一覧表示します。

    devices:
      - /dev/nvme0n1
      - /dev/nvme1n1
      - /dev/nvme2n1
      - /dev/nvme3n1
  3. group_vars/osds.yml の設定は以下のようになります。

    osds_per_device: 2
    devices:
      - /dev/nvme0n1
      - /dev/nvme1n1
      - /dev/nvme2n1
      - /dev/nvme3n1
注記

lvm_volumes ではなく、この設定で devices を使用する必要があります。これは、lvm_volumes が、通常、作成済みの論理ボリュームで使用され、osds_per_device は Ceph による論理ボリュームの自動作成を意味するためです。

関連情報

5.4. メタデータサーバーのインストール

Ansible 自動化アプリケーションを使用して Ceph Metadata Server (MDS) をインストールします。Ceph File System をデプロイするには、メタデータサーバーデーモンが必要です。

前提条件

手順

Ansible 管理ノードで以下の手順を実行します。

  1. 新しいセクション [mdss]/etc/ansible/hosts ファイルに追加します。

    [mdss]
    MDS_NODE_NAME1
    MDS_NODE_NAME2
    MDS_NODE_NAME3

    MDS_NODE_NAME は、Ceph Metadata サーバをインストールするノードのホスト名に置き換えます。

    [osds] セクションおよび [mdss] セクションに同じノードを追加して、1 つのノードにメタデータサーバーと OSD デーモンを同じ場所に置く事ができます。

  2. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  3. 必要に応じて、デフォルトの変数を変更できます。

    1. mdss.yml という名前の group_vars/mdss.yml.sample ファイルのコピーを作成します。

      [root@admin ceph-ansible]# cp group_vars/mdss.yml.sample group_vars/mdss.yml
    2. 必要に応じて、mdss.yml のパラメーターを編集します。詳細は、mdss.yml を参照してください。
  4. ansible ユーザーとして、Ansible Playbook を実行します。

    • ベアメタル デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site.yml --limit mdss -i hosts
    • コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit mdss -i hosts
  5. メタデータサーバーをインストールした後に、それらを設定できるようになりました。詳細は、『Red Hat Ceph Storage ファイルシステムガイド』の「Ceph File System Metadata Server 」の章を参照してください。

関連情報

5.5. Ceph クライアントロールのインストール

ceph-ansible ユーティリティーは、Ceph 設定ファイルと管理キーリングをノードにコピーする ceph-client ロールを提供します。さらに、このロールを使用してカスタムプールおよびクライアントを作成することができます。

前提条件

手順

Ansible 管理ノードで以下のタスクを実行します。

  1. 新しいセクション [clients]/etc/ansible/hosts ファイルに追加します。

    [clients]
    CLIENT_NODE_NAME

    CLIENT_NODE_NAME は、ceph-client ロールをインストールするノードのホスト名に置き換えます。

  2. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  3. clients.yml という名前の clients.yml.sample ファイルの新しいコピーを作成します。

    [root@admin ceph-ansible ~]# cp group_vars/clients.yml.sample group_vars/clients.yml
  4. group_vars/clients.yml ファイルを開き、以下の行をコメント解除します。

    keys:
      - { name: client.test, caps: { mon: "allow r", osd: "allow class-read object_prefix rbd_children, allow rwx pool=test" },  mode: "{{ ceph_keyring_permissions }}" }
    1. client.test を実際のクライアント名に置き換え、クライアントキーをクライアント定義の行に追加します。以下に例を示します。

      key: "ADD-KEYRING-HERE=="

      これで、行全体の例は次のようになります。

      - { name: client.test, key: "AQAin8tUMICVFBAALRHNrV0Z4MXupRw4v9JQ6Q==", caps: { mon: "allow r", osd: "allow class-read object_prefix rbd_children, allow rwx pool=test" },  mode: "{{ ceph_keyring_permissions }}" }
      注記

      ceph-authtool --gen-print-key コマンドは、新しいクライアントキーを生成することができます。

  5. 必要に応じて、プールおよびクライアントを作成するように ceph-client に指示します。

    1. clients.yml を更新します。

      • user_config 設定のコメントを解除して、true に設定します。
      • pools セクションおよび keys セクションのコメントを解除し、必要に応じて更新します。cephx 機能を使用して、カスタムプールとクライアント名をまとめて定義できます。
    2. osd_pool_default_pg_num 設定を all.yml ファイルの ceph_conf_overrides セクションに追加します。

      ceph_conf_overrides:
         global:
            osd_pool_default_pg_num: NUMBER

      NUMBER は、デフォルトの配置グループ数に置き換えます。

  6. ansible ユーザーとして、Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit clients -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit clients -i hosts

関連情報

5.6. Ceph Object Gateway のインストール

Ceph Object Gateway は、RADOS ゲートウェイとも呼ばれ、librados API 上に構築されたオブジェクトストレージインターフェースであり、アプリケーションに Ceph ストレージクラスターへの RESTful ゲートウェイを提供します。

前提条件

警告

Ceph Object Gateway をマルチサイト構成で使用する場合は、ステップ 1 から 6 のみを完了します。マルチサイトを設定する前に Ansible Playbook を実行しないでください。単一のサイト設定で Object Gateway が起動します。Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。ステップ 1 ~ 6 を完了したら、「マルチサイト Ceph Object Gateways の設定」セクションに進み、マルチサイトを設定します。

手順

Ansible 管理ノードで以下のタスクを実行します。

  1. [rgws] セクションの下の /etc/ansible/hosts ファイルにゲートウェイホストを追加して、それらのロールを Ansible に識別します。ホストに連続する命名がある場合は、以下のように範囲を使用します。

    [rgws]
    <rgw_host_name_1>
    <rgw_host_name_2>
    <rgw_host_name[3..10]>
  2. Ansible 設定ディレクトリーに移動します。

    [root@ansible ~]# cd /usr/share/ceph-ansible
  3. サンプルファイルから rgws.yml ファイルを作成します。

    [root@ansible ~]# cp group_vars/rgws.yml.sample group_vars/rgws.yml
  4. group_vars/rgws.yml ファイルを開いて編集します。管理者キーを Ceph Object Gateway ノードにコピーするには、copy_admin_key オプションのコメントを解除します。

    copy_admin_key: true
  5. all.yml ファイルで、radosgw_interface を指定する 必要 があります。

    radosgw_interface: <interface>

    以下を置き換えます。

    • Ceph Object Gateway がリッスンするインターフェースを使用する <interface>

    以下は例になります。

    radosgw_interface: eth0

    インターフェースを指定すると、同じホストで複数のインスタンスを実行している場合に、Civetweb が別の Civetweb インスタンスと同じ IP アドレスにバインドされないようにします。

    詳細は、all.yml ファイルを参照してください。

  6. 通常、デフォルト設定を変更するには、rgws.yml ファイルの設定をコメント解除し、それに応じて変更を加えます。rgws.yml ファイルに含まれていない設定に追加の変更を行うには、all.yml ファイルで ceph_conf_overrides: を使用します。

    ceph_conf_overrides:
        client.rgw.rgw1:
          rgw_override_bucket_index_max_shards: 16
          rgw_bucket_default_quota_max_objects: 1638400

    詳細な設定の詳細は、Red Hat Ceph Storage 4 の『実稼働環境への Ceph Object Gateway ガイド』を参照してください。高度なトピックには以下が含まれます。

  7. Ansible Playbook を実行します。

    警告

    マルチサイトを設定する場合には、Ansible Playbook を実行しないでください。「マルチサイト Ceph Object Gateways の設定」セクションに進み、マルチサイトを設定します。

    1. ベアメタル デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site.yml --limit rgws -i hosts
    2. コンテナー デプロイメント:

      [user@admin ceph-ansible]$ ansible-playbook site-container.yml --limit rgws -i hosts
注記

Ansible は、各 Ceph Object Gateway が確実に実行されていることを確認します。

単一サイトの構成の場合は、Ceph ObjectGateway を Ansible 構成に追加します。

マルチサイトデプロイメントでは、各ゾーンの Ansible 設定を行う必要があります。つまり、Ansible によって、そのゾーン用に Ceph Storage クラスターおよびゲートウェイインスタンスが作成されます。

マルチサイトクラスターのインストールが完了したら、マルチサイト用のクラスターの設定方法は、Red Hat Ceph Storage 4 の『オブジェクトゲートウェイガイド』「マルチサイト」 の章に進んでください。

5.7. マルチサイト Ceph Object Gateway の設定

システム管理者は、障害復旧目的で、マルチサイト Ceph Object Gateways をクラスター間でデータのミラーリングを実行するように設定できます。

1 つ以上の RGW レルムを使用してマルチサイトを設定できます。レルムは、その内部の RGW を独立した状態にし、レルム外の RGW から分離できるようにします。これにより、あるレルムの RGW に書き込まれたデータは、別のレルムの RGW からはアクセスできません。

警告

Ceph-Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。この設定は手動でデプロイできます。レッドハットサポート にお問い合わせください。

注記

Red Hat Ceph Storage 4.1 から、group_vars/all.yml ファイルで rgw_multisite_endpoints_list の値を設定する必要はありません。

5.7.1. 前提条件

5.7.2. 1 つのレルムを使用したマルチサイト Ceph Object Gateway の設定

Ceph-Ansible は、複数のストレージクラスター間で 1 つのレルムのデータをミラーリングするように Ceph Object Gateways を設定します。

警告

Ceph-Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。この設定は手動でデプロイできます。レッドハットサポート にお問い合わせください。

前提条件

手順

  1. プライマリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. システムキーを生成し、multi-site-keys.txt ファイルで出力を取得します。

      [root@ansible ~]# echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys.txt
      [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys.txt
    2. Ceph-Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    3. group_vars/all.yml ファイルを開いて編集します。それぞれ、ZONE_NAMEZONE_GROUP_NAMEZONE_USER_NAMEZONE_DISPLAY_NAME、および REALM_NAME の更新と共に以下の設定を行います。ACCESS_KEY および SECRET_KEYmulti-site-keys.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_multisite: true
      rgw_zone: ZONE_NAME
      rgw_zonegroup: ZONE_GROUP_NAME
      rgw_realm: REALM_NAME
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: ZONE_USER_NAME
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME
      system_access_key: ACCESS_KEY
      system_secret_key: SECRET_KEY
      rgw_multisite_proto: "http"

      rgw_multisite: true
      rgw_zone: juneau
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: true
      rgw_zonesecondary: false
      rgw_zonegroupmaster: true
      rgw_zone_user: synchronization-user
      rgw_zone_user_display_name: "Synchronization User"
      rgw_multisite_proto: "http"
      system_access_key: 86nBoQOGpQgKxh4BLMyq
      system_secret_key: NTnkbmkMuzPjgwsBpJ6o

  2. セカンダリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ceph-Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. group_vars/all.yml ファイルを開いて編集します。以下の設定を構成します。ZONE_USER_NAMEZONE_DISPLAY_NAMEACCESS_KEYSECRET_KEYREALM_NAME、および ZONE_GROUP_NAME の最初のクラスターで使用するものと同じ値を指定します。ZONE_NAME には、プライマリーストレージクラスターとは異なる値を使用します。マスターゾーンの Ceph Object Gateway ノードに MASTER_RGW_NODE_NAME を設定します。なお、プライマリストレージクラスターと比較して、rgw_zonemasterrgw_zonesecondaryrgw_zonegroupmaster の設定が逆にることに注意してください。

      構文

      rgw_multisite: true
      rgw_zone: ZONE_NAME
      rgw_zonegroup: ZONE_GROUP_NAME
      rgw_realm: REALM_NAME
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: false
      rgw_zone_user: ZONE_USER_NAME
      rgw_zone_user_display_name: ZONE_DISPLAY_NAME
      system_access_key: ACCESS_KEY
      system_secret_key: SECRET_KEY
      rgw_multisite_proto: "http"
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: MASTER_RGW_NODE_NAME

      rgw_multisite: true
      rgw_zone: fairbanks
      rgw_zonegroup: alaska
      rgw_realm: usa
      rgw_zonemaster: false
      rgw_zonesecondary: true
      rgw_zonegroupmaster: false
      rgw_zone_user: synchronization-user
      rgw_zone_user_display_name: "Synchronization User"
      system_access_key: 86nBoQOGpQgKxh4BLMyq
      system_secret_key: NTnkbmkMuzPjgwsBpJ6o
      rgw_multisite_proto: "http"
      rgw_pull_proto: http
      rgw_pull_port: 8080
      rgw_pullhost: cluster0-rgw-000

  3. プライマリーストレージクラスターで Ansible Playbook を実行します。

    注記

    クラスターがデプロイされていて、Ceph Object Gateway のみに変更を加える場合は、--limit rgws オプションを使用します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts
  4. セカンダリーのストレジクラスターがプライマリーのストレージクラスターの API にアクセスできることを確認します。

    セカンダリーのストレージクラスターの Object Gateway ノードから、curl または別の HTTP クライアントを使用して、プライマリークラスターの API に接続します。all.ymlrgw_pull_protorgw_pullhost、および rgw_pull_port の設定に使用する情報を使用して URL を作成します。上記の例では、URL は http://cluster0-rgw-000:8080です。API にアクセスできない場合は、URL が正しいことを確認し、必要な場合は all.yml を更新します。URL が有効になり、ネットワークの問題が解決したら、次の手順に進み、セカンダリーのストレージクラスターで Ansible Playbook を実行します。

  5. セカンダリーのストレージクラスターで Ansible Playbook を実行します。

    注記

    クラスターがデプロイされていて、Ceph Object Gateway に変更を加える場合は、--limit rgws オプションを使用します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts

      プライマリーストレージクラスターおよびセカンダリーストレージクラスターで Ansible Playbook を実行した後に、Ceph Object Gateway はアクティブ/アクティブ状態で実行されます。

  6. 両方のサイトでマルチサイト Ceph Object Gateway の設定を確認します。

    構文

    radosgw-admin sync status

5.7.3. 複数のレルムを使用したマルチサイト Ceph Object Gateway の設定

Ceph-Ansible は、複数の RGW インスタンスが含まれる、複数のストレージクラスター全体で複数のレルムのデータをミラーリングするように Ceph Object Gateway を設定します。

警告

Ceph-Ansible は、ゲートウェイがシングルサイト構成で開始した後に、マルチサイトセットアップにゲートウェイを再構成することはできません。この設定は手動でデプロイできます。レッドハットサポート にお問い合わせください。

前提条件

  • Red Hat Ceph Storage クラスターを実行する 2 つ。
  • 各ストレージクラスター内に少なくとも 2 つの Object Gateway ノードがある。
  • Ceph Object Gateway ノード上で、『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage のインストール要件」セクションに記載のタスクを実行します。
  • 各 Object Gateway ノードについて、『Red Hat Ceph Storage インストールガイド』「Ceph Object Gateway のインストール」セクションに記載のステップ 1 から 6 を実施します。

手順

  1. いずれのノードでも、レルム 1 と 2 のシステムアクセスキーとシークレットキーを生成し、それぞれ multi-site-keys-realm-1.txt および multi-site-keys-realm-2.txt という名前のファイルに保存します。

    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-1.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-1.txt
    
    # echo system_access_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 20 | head -n 1) > multi-site-keys-realm-2.txt
    [root@ansible ~]# echo system_secret_key: $(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 40 | head -n 1) >> multi-site-keys-realm-2.txt
  2. プライマリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ceph-Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。rgw_multisite_proto パラメーターのコメントを解除します。

      rgw_multisite: true
      rgw_multisite_proto: "http"
    3. usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    4. プライマリーストレージクラスター上の各 Object Gateway ノードの host_vars にファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、Object Gateway ノードの名前が rgw-primary の場合は、host_vars/rgw-primary ファイルを作成します。

      構文

      touch host_vars/NODE_NAME

      [root@ansible ceph-ansible]# touch host_vars/rgw-primary

      注記

      マルチサイト構成で使用するクラスター内に複数のCeph Object Gateway ノードがある場合は、ノードごとにファイルを作成します。

    5. ファイルを編集して、プライマリーストレージクラスター内の各 Object Gateway にある全インスタンスに対して設定詳細を追加します。最初のレルムに対して、instance_name で以下の設定を行います。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_instances:
        - instance_name: 'INSTANCE_NAME'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: ZONE_NAME_1
          rgw_zonegroup: ZONE_GROUP_NAME_1
          rgw_realm: REALM_NAME_1
          rgw_zone_user: ZONE_USER_NAME_1
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
          system_access_key: ACCESS_KEY_1
          system_secret_key: SECRET_KEY_1
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: PORT_NUMBER_1

      重要

      Ansible Playbook をエラーなく実行するためには、例のように各 -instance_namergw_instances: の下に並んでいることを確認する必要があります。

      rgw_instances:
        - instance_name: 'rgw0'

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080

      注記

      クラスター内に既存のレルムとCeph Object Gatewaysが手動で設定されている場合は、インスタンスと各インスタンスの設定をそれぞれのオブジェクトノードファイルに追加する必要があります。Ceph-ansibleは、Playbook の実行時にすべてのノードの ceph.conf を上書きします。既存のレルムにある既存の Ceph Object Gateways をrgw_instances に追加すると、各ノードの新しい ceph.conf ファイルに新旧の Ceph Object Gateways が必ず存在するようになります。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_realm: local-realm-1
          rgw_zonegroup: local-zone-group-1
          rgw_zone: local-zone-1
          rgw_zone_user: local-user-1
          rgw_zone_user_display_name: "local-user-1"
          system_access_key: P9Eb6S8XNyo4dtZZUUMx
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfA
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
        - instance_name: 'rgw1'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081

    6. オプション: 同一の Object Gateway ノード上に複数のインスタンスがある場合には、他のレルムの instance_name に以下の設定を行います。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。

      構文

        - instance_name: 'INSTANCE_NAME'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: ZONE_NAME_2
          rgw_zonegroup: ZONE_GROUP_NAME_2
          rgw_realm: REALM_NAME_2
          rgw_zone_user: ZONE_USER_NAME_2
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_2"
          system_access_key: ACCESS_KEY_2
          system_secret_key: SECRET_KEY_2
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: PORT_NUMBER_2

        - instance_name: 'rgw1'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081

    7. プライマリーゲートウェイの host_vars ファイルが以下の例のようになっていることを確認します。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080

    8. オプション: 複数のインスタンスの場合には、プライマリーゲートウェイの host_vars ファイルが以下の例のようになっていることを確認します。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: paris
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
        - instance_name: 'rgw1'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_zone: juneau
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081

  3. プライマリーストレージクラスターで Ansible Playbook を実行します。

    注記

    クラスターがデプロイされていて、Ceph Object Gateway のみに変更を加える場合は、--limit rgws オプションを使用します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts
  4. セカンダリーストレージクラスターの Ansible ノードで以下の手順を実行します。

    1. Ceph-Ansible 設定ディレクトリー /usr/share/ceph-ansible に移動します。

      [root@ansible ~]# cd /usr/share/ceph-ansible
    2. group_vars/all.yml ファイルを開いて編集します。rgw_multisite 行のコメントを解除して、true に設定します。rgw_multisite_proto パラメーターのコメントを解除します。

      rgw_multisite: true
      rgw_multisite_proto: "http"
    3. usr/share/ceph-ansiblehost_vars ディレクトリーを作成します。

      [root@ansible ceph-ansible]# mkdir host_vars
    4. セカンダリーストレージクラスター上の各 Object Gateway ノードの host_vars にファイルを作成します。ファイル名は、Ansible インベントリーファイルで使用される名前と同じである必要があります。たとえば、Object Gateway のノード名が rgw-secondary の場合は、host_vars/rgw-secondary というファイルを作成します。

      構文

      touch host_vars/NODE_NAME

      [root@ansible ceph-ansible]# touch host_vars/rgw-secondary

      注記

      マルチサイト構成で使用するクラスター内に複数のCeph Object Gateway ノードがある場合は、ノードごとにファイルを作成します。

    5. ファイルを編集して、セカンダリーストレージクラスタ内の各 Object Gateway にある全インスタンスに対して設定詳細を追加します。最初のレルムに対して、instance_name で以下の設定を行います。ACCESS_KEY_1 および SECRET_KEY_1multi-site-keys-realm-1.txt ファイルに保存されるランダムな文字列を使用します。

      構文

      rgw_instances:
        - instance_name: 'INSTANCE_NAME'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: ZONE_NAME_1
          rgw_zonegroup: ZONE_GROUP_NAME_1
          rgw_realm: REALM_NAME_1
          rgw_zone_user: ZONE_USER_NAME_1
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_1"
          system_access_key: ACCESS_KEY_1
          system_secret_key: SECRET_KEY_1
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: PORT_NUMBER_1
          endpoint: http://RGW_PRIMARY_HOSTNAME:_RGW_PRIMARY_PORT_NUMBER_1_

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: versailles
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://rgw-primary:8080

      注記

      クラスター内に既存のレルムと Ceph Object Gateways を手動で設定している場合は、関連するオブジェクトノードファイルに instance_name と各インスタンスの設定を追加する必要があります。Ceph-ansibleは、Playbook の実行時にすべてのノードの ceph.conf を上書きします。既存のレルムにある既存の Ceph Object Gateways をrgw_instances に追加すると、各ノードの新しい ceph.conf ファイルに新旧の Ceph Object Gateways が必ず存在するようになります。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: true
          rgw_zonesecondary: false
          rgw_zonegroupmaster: true
          rgw_realm: local-realm-2
          rgw_zonegroup: local-zone-group-2
          rgw_zone: local-zone-2
          rgw_zone_user: local-user-2
          rgw_zone_user_display_name: "local-user-2"
          system_access_key: P9Eb6S8XNyo4dtZZUUMx
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfA
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
        - instance_name: 'rgw1'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: versailles
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://rgw-primary:8081

    6. オプション: 同一の Object Gateway ノード上に複数のインスタンスがある場合には、他のレルムの instance_name に以下の設定を行います。ACCESS_KEY_2 および SECRET_KEY_2multi-site-keys-realm-2.txt ファイルに保存されるランダムな文字列を使用します。RGW_PRIMARY_HOSTNAME をプライマリーストレージクラスターの Object Gateway ノードに設定します。

      構文

        - instance_name: 'INSTANCE_NAME'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: ZONE_NAME_2
          rgw_zonegroup: ZONE_GROUP_NAME_2
          rgw_realm: REALM_NAME_2
          rgw_zone_user: ZONE_USER_NAME_2
          rgw_zone_user_display_name: "ZONE_DISPLAY_NAME_2"
          system_access_key: ACCESS_KEY_2
          system_secret_key: SECRET_KEY_2
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: PORT_NUMBER_2
          endpoint: http://RGW_PRIMARY_HOSTNAME:_RGW_PRIMARY_PORT_NUMBER_2_

        - instance_name: 'rgw1'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: fairbanks
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://rgw-primary:8081

    7. セカンダリーゲートウェイの host_vars ファイルが以下の例のようになっていることを確認します。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: versailles
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://rgw-primary:8080

    8. オプション: 複数のインスタンスの場合には、セカンダリーゲートウェイの host_vars ファイルが以下の例のようになっていることを確認します。

      rgw_instances:
        - instance_name: 'rgw0'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: versailles
          rgw_zonegroup: idf
          rgw_realm: france
          rgw_zone_user: jacques.chirac
          rgw_zone_user_display_name: "Jacques Chirac"
          system_access_key: P9Eb6S8XNyo4dtZZUUMy
          system_secret_key: qqHCUtfdNnpHq3PZRHW5un9l0bEBM812Uhow0XfB
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8080
          endpoint: http://rgw-primary:8080
        - instance_name: 'rgw1'
          rgw_zonemaster: false
          rgw_zonesecondary: true
          rgw_zonegroupmaster: false
          rgw_zone: fairbanks
          rgw_zonegroup: alaska
          rgw_realm: usa
          rgw_zone_user: edward.lewis
          rgw_zone_user_display_name: "Edward Lewis"
          system_access_key: yu17wkvAx3B8Wyn08XoF
          system_secret_key: 5YZfaSUPqxSNIkZQQA3lBZ495hnIV6k2HAz710BY=
          radosgw_address: "{{ _radosgw_address }}"
          radosgw_frontend_port: 8081
          endpoint: http://rgw-primary:8081

  5. 各サイト (プライマリーおよびセカンダリー) の Ceph Monitor ノードおよび Object Gateway ノードから、curl または別の HTTP クライアントを使用して、プリマリーサイトへのエンドポイントがセカンダリーサイトからアクセスできることを確認します。rgw_instances の設定にある任意の エンドポイント をチェックする必要があります。
  6. セカンダリーのストレージクラスターで Ansible Playbook を実行します。

    注記

    クラスターがデプロイされていて、Ceph Object Gateway のみに変更を加える場合は、--limit rgws オプションを使用します。

    1. ベアメタル デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site.yml -i hosts
    2. コンテナー デプロイメント:

      [user@ansible ceph-ansible]$ ansible-playbook site-container.yml -i hosts

    プライマリーストレージクラスターおよびセカンダリーストレージクラスターで Ansible Playbook を実行した後に、Ceph Object Gateway はアクティブ/アクティブ状態で実行されます。

  7. 両方のサイトでマルチサイト Ceph Object Gateway の設定を確認します。

    構文

    radosgw-admin sync status

5.8. 同じホストに異なるハードウェアを持つ OSD のデプロイメント

Ansible の device_class 機能を使用して、同じホストに HDD や SSD などの複数の OSD をデプロイすることができます。

前提条件

  • 有効なカスタマーサブスクリプションです。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • Red Hat Ceph Storage Tools および Ansible リポジトリーを有効にします。
  • Ansible アプリケーションで使用する Ansible ユーザーアカウント。
  • OSD がデプロイされている。

手順

  1. group_vars/mons.yml ファイルに crush_rules を作成します。

    crush_rule_config: true
    crush_rule_hdd:
        name: HDD
        root: default
        type: host
        class: hdd
        default: true
    crush_rule_ssd:
        name: SSD
        root: default
        type: host
        class: ssd
        default: true
    crush_rules:
          - "{{ crush_rule_hdd }}"
          - "{{ crush_rule_ssd }}"
    create_crush_tree: true

    注記

    クラスターで SSD デバイスまたは HDD デバイスを使用していない場合は、そのデバイスの crush_rules を定義しないでください。

  2. group_vars/clients.yml ファイルで作成した crush_rules を使用して pools を作成します。

    copy_admin_key: True
    user_config: True
    pool1:
      name: "pool1"
      pg_num: 128
      pgp_num: 128
      rule_name: "HDD"
      type: "replicated"
      device_class: "hdd"
    pools:
      - "{{ pool1 }}"

  3. ルートを OSD に割り当てるためのインベントリーファイルをサンプリングします。

    [mons]
    mon1
    
    [osds]
    osd1 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'host': 'osd1' }"
    osd2 osd_crush_location="{ 'root': 'default', 'rack': 'rack1', 'host': 'osd2' }"
    osd3 osd_crush_location="{ 'root': 'default', 'rack': 'rack2', 'host': 'osd3' }"
    osd4 osd_crush_location="{ 'root': 'default', 'rack': 'rack2', 'host': 'osd4' }"
    osd5 devices="['/dev/sda', '/dev/sdb']" osd_crush_location="{ 'root': 'default', 'rack': 'rack3', 'host': 'osd5' }"
    osd6 devices="['/dev/sda', '/dev/sdb']" osd_crush_location="{ 'root': 'default', 'rack': 'rack3', 'host': 'osd6' }"
    
    [mgrs]
    mgr1
    
    [clients]
    client1

  4. ツリーを表示します。

    構文

    [root@mon ~]# ceph osd tree

    TYPE NAME
    
    root default
         rack rack1
            host osd1
                 osd.0
                 osd.10
            host osd2
                 osd.3
                 osd.7
                 osd.12
         rack rack2
            host osd3
                 osd.1
                 osd.6
                 osd.11
            host osd4
                 osd.4
                 osd.9
                 osd.13
         rack rack3
             host osd5
                 osd.2
                 osd.8
             host osd6
                 osd.14
                 osd.15

  5. プールを検証します。

    # for i in $(rados lspools);do echo "pool: $i"; ceph osd pool get $i crush_rule;done
    
    pool: pool1
    crush_rule: HDD

関連情報

5.9. NFS-Ganesha ゲートウェイのインストール

Ceph NFS Ganesha ゲートウェイは、Ceph Object Gateway 上に構築される NFS インターフェースで、ファイルシステム内のファイルを Ceph Object Storage に移行するために POSIX ファイルシステムインターフェースを使用するアプリケーションを Ceph Object Gateway に提供します。

前提条件

  • 稼働中の Ceph ストレージクラスター (active + clean の状態が望ましい)。
  • Ceph Object Gateway を実行するノードを少なくとも 1 つ。
  • NFS-Ganesha を実行する前に、NFS-Ganesha を実行するホストで実行中のカーネル NFS サービスインスタンスをすべて無効にします。NFS-Ganesha は、別の NFS インスタンスが実行している場合は起動しません。

*パスワードなしの SSH アクセスの有効化

  • rpcbind サービスが実行していることを確認します。

    # systemctl start rpcbind
    注記

    rpcbind を提供する rpcbind パッケージは通常、デフォルトでインストールされます。そうでない場合は、最初にパッケージをインストールします。

  • nfs-service サービスが実行中である場合は、これを停止して無効にします。

    # systemctl stop nfs-server.service
    # systemctl disable nfs-server.service

手順

Ansible 管理ノードで以下のタスクを実行します。

  1. サンプルファイルから nfss.yml ファイルを作成します。

    [root@ansible ~]# cd /usr/share/ceph-ansible/group_vars
    [root@ansible ~]# cp nfss.yml.sample nfss.yml
  2. [nfss] グループの下にゲートウェイホストを /etc/ansible/hosts ファイルに追加して、Ansible へのグループメンバーシップを特定します。

    [nfss]
    NFS_HOST_NAME_1
    NFS_HOST_NAME_2
    NFS_HOST_NAME[3..10]

    ホストに連続する命名がある場合は、[3..10] のように範囲指定子を使用できます。

  3. Ansible 設定ディレクトリーに移動します。

    [root@ansible ~]# cd /usr/share/ceph-ansible
  4. 管理者キーを Ceph Object Gateway ノードにコピーするには、/usr/share/ceph-ansible/group_vars/nfss.yml ファイルの copy_admin_key 設定をコメント解除します。

    copy_admin_key: true
  5. /usr/share/ceph-ansible/group_vars/nfss.yml ファイルの FSAL (File System Abstraction Layer) セクションを設定します。エクスポート ID (NUMERIC_EXPORT_ID)、S3 ユーザー ID (S3_USER)、S3 アクセスキー (ACCESS_KEY)、およびシークレットキー (SECRET_KEY) を提供します。

    # FSAL RGW Config #
    
    ceph_nfs_rgw_export_id: NUMERIC_EXPORT_ID
    #ceph_nfs_rgw_pseudo_path: "/"
    #ceph_nfs_rgw_protocols: "3,4"
    #ceph_nfs_rgw_access_type: "RW"
    ceph_nfs_rgw_user: "S3_USER"
    ceph_nfs_rgw_access_key: "ACCESS_KEY"
    ceph_nfs_rgw_secret_key: "SECRET_KEY"
    警告

    アクセスおよびシークレットキーは任意で、生成できます。

  6. Ansible Playbook を実行します。

    1. ベアメタル デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit nfss -i hosts
    2. コンテナー デプロイメント:

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit nfss -i hosts

5.10. limit オプションについて

本セクションでは、Ansible の --limit オプションを説明します。

Ansible は --limit オプションをサポートし、インベントリーファイルの特定のロールに Ansible Playbook site および site-container を使用できます。

ansible-playbook site.yml|site-container.yml --limit osds|rgws|clients|mdss|nfss|iscsigws -i hosts

ベアメタル

たとえば、ベアメタルに OSD のみを再デプロイするには、Ansible ユーザーとして以下のコマンドを実行します。

[ansible@ansible ceph-ansible]$ ansible-playbook site.yml --limit osds -i hosts

コンテナー

たとえば、コンテナーに OSD のみを再デプロイするには、Ansible ユーザーとして以下のコマンドを実行します。

[ansible@ansible ceph-ansible]$ ansible-playbook site-container.yml --limit osds -i hosts

5.11. 配置グループ autoscaler

配置グループ (PG) チューニングでは、PG の計算ツールを使用して、pg_num の数字のプラグを手動で処理します。Red Hat Ceph Storage 4.1 以降では、Ceph Manager モジュール pg_autoscaler を有効にすると、PG のチューニングを自動的に実行できます。PG autoscaler はプールごとに設定され、pg_num を 2 の累乗でスケーリングします。PG Autoscaler は、推奨される値が実際の値が 3 倍を超える場合に、pg_num への変更のみを提案します。

PG autoscaler には 3 つのモードがあります。

warn
新しいプールおよび既存のプールのデフォルトモード。推奨される pg_num の値が現在の pg_num 値と大きく異なる場合に、ヘルス警告が生成されます。
on
プールの pg_num は、自動的に調整されます。
off
プールでは Autoscaler をオフにすることができますが、ストレージ管理者はプールの pg_num 値を手動で設定する必要があります。

プールに対して PG autoscaler が有効になったら、ceph osd pool autoscale-status コマンドを実行して値の調整を表示できます。この autoscale-status コマンドは、プールの現在の状態を示します。autoscale-status 列の説明は次のとおりです。

SIZE
プールに保存されているデータの合計量をバイト単位で報告します。このサイズには、オブジェクトデータと OMAP データが含まれます。
TARGET SIZE
ストレージ管理者が提供するプールの予想されるサイズを報告します。この値は、プールの理想的な PG 数を計算するために使用されます。
RATE
レプリケートされたバケットのレプリケーション係数、またはイレイジャーコーディングされたプールの比率。
RAW CAPACITY
プールが CRUSH に基づいてマップされるストレージデバイスの raw ストレージ容量。
RATIO
プールによって消費されるストレージの合計比率。
TARGET RATIO
ストレージ管理者によって提供された、ストレージクラスター全体のスペースのどの部分がプールによって消費されるかを指定する比率。
PG_NUM
プールの現在の配置グループ数。
NEW PG_NUM
提案される値。この値は設定できません。
AUTOSCALE
プールに設定された PG Autoscaler モード。

5.11.1. 配置グループ autoscaler の設定

Ceph Ansible を設定して、Red Hat Ceph Storage クラスターの新規プールの PG Autoscaler を有効および設定することができます。デフォルトでは、配置グループ (PG) はオフになっています。

重要

現在、新しい Red Hat Ceph Storage デプロイメントでのみ配置グループ Autoscaler を設定でき、既存の Red Hat Ceph Storage インストールには設定できません。

前提条件

  • Ansible 管理ノードへのアクセス
  • Ceph Monitor ノードへのアクセス

手順

  1. Ansible 管理ノードで、編集のために group_vars/all.yml ファイルを開きます。
  2. pg_autoscale_mode オプションを True に設定し、新規または既存のプールの target_size_ratio の値を設定します。

    openstack_pools:
        - {"name": backups, "target_size_ratio": 0.1, "pg_autoscale_mode": True, "application": rbd}
        - {"name": volumes, "target_size_ratio": 0.5, "pg_autoscale_mode": True, "application": rbd}
        - {"name": vms,     "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}
        - {"name": images,  "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}

    注記

    target_size_ratio 値は、ストレージクラスター内の他のプールとの対比で、重みの値になります。

  3. group_vars/all.yml ファイルへの変更を保存します。
  4. 適切な Ansible Playbook を実行します。

    ベアメタル デプロイメント

    [ansible@admin ceph-ansible]$ ansible-playbook site.yml -i hosts

    コンテナー デプロイメント

    [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts

  5. Ansible Playbook が完了したら、Ceph Monitor ノードから Autoscaler のステータスを確認します。

    [user@mon ~]$ ceph osd pool autoscale-status

5.12. 関連情報

第6章 コンテナー化された Ceph デーモンのコロケーション

本セクションでは、以下を説明します。

6.1. コロケーションの仕組みとその利点

コンテナー化された Ceph デーモンを同じノードの同じ場所に配置できます。Ceph のサービスの一部を共存する利点を以下に示します。

  • 小規模での総所有コスト (TCO) の大幅な改善
  • 最小設定の場合は、6 ノードから 3 ノードまで削減します。
  • より簡単なアップグレード
  • リソース分離の改善

コロケーションの仕組み

Ansible インベントリーファイルの適切なセクションに同じノードを追加することで、次のリストから 1 つのデーモンを OSD デーモン (ceph-osd) と同じ場所に配置できます。

  • Ceph メタデータサーバー (ceph-mds)
  • Ceph Monitor (ceph-mon) および Ceph Manager (ceph-mgr) デーモン
  • NFS Ganesha (nfs-ganesha)
  • RBD ミラー (rbd-mirror)

さらに、Ceph Object Gateway (radosgw) または Grafana の場合は、OSD デーモンと上記のリストのデーモン (RBD ミラーを除く) のいずれかと同じ場所に配置できます。たとえば、以下は、有効な 5 ノードの同じ場所に配置された構成です。

ノードデーモンデーモンデーモン

node1

OSD

Monitor

Grafana

node2

OSD

Monitor

RADOS Gateway

node3

OSD

Monitor

RADOS Gateway

node4

OSD

メタデータサーバー

 

node5

OSD

メタデータサーバー

 

上記の設定のように 5 つのノードクラスターをデプロイするには、以下のように Ansible インベントリーファイルを設定します。

同じ場所に配置されたデーモンを含む Ansible インベントリーファイル

[grafana-server]
node1

[mons]
node[1:3]

[mgrs]
node[1:3]

[osds]
node[1:5]

[rgws]
node[2:3]

[mdss]
node[4:5]

注記

ceph-monceph-mgr は密接に連携するため、コロケーションのために、2 つの別のデーモンとしてカウントしません。

注記

Grafana の OSD および別のデーモンのコロケーションは、Red Hat Ceph Storage 4.1 以降でのみサポートされます。

注記

Red Hat は、Ceph Object Gateway を OSD コンテナーと併置してパフォーマンスを向上することを推奨します。追加コストを発生せずに最高のパフォーマンスを実現するには、group_vars/all.ymlradosgw_num_instances: 2 に設定して、2 つのゲートウェイを使用します。詳細は、「Red Hat Ceph Storage RGW deployment strategies and sizing guidance」を参照してください。

注記

Grafana を他の 2 つのコンテナーと同じ場所に配置するには、適切な CPU とネットワークリソースが必要です。リソースの枯渇が発生した場合は、Grafana と Monitor のみを同じ場所に配置し、それでもリソースの枯渇が発生した場合は、専用ノードで Grafana を実行します。

図6.1「同じ場所に配置されたデーモン」 イメージおよび 図6.2「同じ場所に配置されていないデーモン」 イメージは、同じ場所に置かれたデーモンと、同じ場所に置かれていないデーモンの相違点を示しています。

図6.1 同じ場所に配置されたデーモン

containers colocated daemons updated cardinality 2

図6.2 同じ場所に配置されていないデーモン

containers non colocated daemons updated

複数のコンテナー化された Ceph デーモンを同じノードにコロケートする場合、Playbook ceph-ansible は専用の CPU および RAM リソースをそれぞれに予約します。デフォルトでは、ceph-ansible は、『Red Hat Ceph Storage ハードウェアガイド』「推奨される最小ハードウェア」の章に記載される値を使用します。デフォルト値の変更方法は、「同じ場所に配置されたデーモンの専用リソースの設定」セクションを参照してください。

6.2. 同じ場所に配置されたデーモンの専用リソースの設定

同じノードで 2 つの Ceph デーモンを共存させる場合には、Playbook ceph-ansible は各デーモンに CPU および RAM リソースを予約します。ceph-ansible が使用するデフォルト値は、『Red Hat Ceph Storage ハードウェア選択ガイド』の「推奨される最小ハードウェア」の章に記載されています。デフォルト値を変更するには、Ceph デーモンのデプロイ時に必要なパラメーターを設定します。

手順

  1. デーモンのデフォルト CPU 制限を変更するには、デーモンのデプロイ時に、適切な .yml 設定ファイルに ceph_daemon-type_docker_cpu_limit パラメーターを設定します。詳細は以下の表を参照してください。

    デーモンパラメーター設定ファイル

    OSD

    ceph_osd_docker_cpu_limit

    osds.yml

    MDS

    ceph_mds_docker_cpu_limit

    mdss.yml

    RGW

    ceph_rgw_docker_cpu_limit

    rgws.yml

    たとえば、Ceph Object Gateway のデフォルトの CPU 制限を 2 に変更するには、以下のように /usr/share/ceph-ansible/group_vars/rgws.yml ファイルを編集します。

    ceph_rgw_docker_cpu_limit: 2
  2. OSD デーモンのデフォルト RAM を変更するには、デーモンのデプロイ時に /usr/share/ceph-ansible/group_vars/all.yml ファイルに osd_memory_target を設定します。たとえば、OSD RAM を 6 GB に制限するには、以下を実行します。

    ceph_conf_overrides:
      osd:
        osd_memory_target=6000000000
    重要

    ハイパーコンバージドインフラストラクチャー (HCI) 設定では、osds.yml 設定ファイルの ceph_osd_docker_memory_limit パラメーターを使用して Docker メモリー CGroup 制限を変更することもできます。この場合、ceph_osd_docker_memory_limitosd_memory_target よりも 50% 高く設定し、CGroup の制限は、HCI 設定の場合のデフォルトよりも制限が高くなります。たとえば、osd_memory_target が 6 GB に設定されている場合は、ceph_osd_docker_memory_limit を 9 GB に設定します。

    ceph_osd_docker_memory_limit: 9g

関連情報

  • /usr/share/ceph-ansible/group_vars/ ディレクトリーにある設定ファイルのサンプル

6.3. 関連情報

第7章 Red Hat Ceph Storage クラスターのアップグレード

ストレージ管理者は、Red Hat Ceph Storage クラスターを新しいメジャーバージョンまたは新しいマイナーバージョンにアップグレードしたり、現行バージョンに非同期更新を適用するだけで済みます。Ansible Playbook rolling_update.yml は、Red Hat Ceph Storage のベアメタルまたはコンテナー化されたデプロイメントのアップグレードを実行します。Ansible は Ceph ノードを以下の順序でアップグレードします。

  • ノードの監視
  • MGR ノード
  • OSD ノード
  • MDS ノード
  • Ceph Object Gateway ノード
  • その他すべての Ceph クライアントノード
注記

Red Hat Ceph Storage 3.1 以降、Object Gateway および高速 NVMe ベースの SSD (および SATA SSD) を使用する場合のパフォーマンスのためにストレージを最適化するために、新しい Ansible Playbook が追加されました。Playbook は、ジャーナルとバケットインデックスを SSD にまとめて配置してこれを行います。これにより、1 つのデバイスにすべてのジャーナルがある場合よりもパフォーマンスが向上します。これらの Playbook は、Ceph のインストール時に使用されます。既存の OSD は動作し続け、アップグレード中に追加のステップは必要ありません。このようにストレージを最適化するために OSD を同時に再設定する際に、Ceph クラスターをアップグレードする方法はありません。ジャーナルまたはバケットインデックスに異なるデバイスを使用するには、OSD を再プロビジョニングする必要があります。『実稼働向け Ceph オブジェクトゲートウェイガイド』「LVM での NVMe の最適な使用」を参照してください。

重要

Red Hat Ceph Storage クラスターを以前のサポートされているバージョンからバージョン 4.2z2 にアップグレードすると、モニターがセキュアでない global_id の再要求を許可していると記載の HEALTH_WARN 状態のままアップグレードが完了します。これは、CVE のパッチ適用が原因で、詳細は CVE-2021-20288 を確認してください。この問題は Red Hat Ceph Storage 4.2z2 の CVE で修正されています。

ヘルスに関する警告をオフにすることを推奨します。

  1. AUTH_INSECURE_GLOBAL_ID_RECLAIM の警告の ceph ヘルス詳細 の出力を確認して、更新されていないクライアントを特定します。
  2. すべてのクライアントを Red Hat Ceph Storage 4.2z2 リリースにアップグレードします。
  3. すべてのクライアントが更新され、AUTH_INSECURE_GLOBAL_ID_RECLAIM 警告がクライアントに表示されなくなったことを確認してから、auth_allow_insecure_global_id_reclaimfalse に設定します。このオプションが false に設定されている場合には、パッチを適用していないクライアントは、ネットワークの断続的な障害によりモニターへの接続が切断された後にストレージクラスターに再接続できず、タイムアウト (デフォルトでは72時間) 時に認証チケットを更新できません。

    構文

    ceph config set mon auth_allow_insecure_global_id_reclaim false

  4. AUTH_INSECURE_GLOBAL_ID_RECLAIM の警告が表示されているクライアントがないことを確認してください。
重要

Playbook rolling_update.yml には、同時に更新するノード数を調整する シリアル 変数が含まれます。Red Hat では、デフォルト値 (1) を使用することを強く推奨します。これにより、Ansible がクラスターノードを 1 つずつアップグレードします。

重要

いずれかの時点でアップグレードが失敗した場合は、ceph status コマンドでクラスターの状態を確認して、アップグレードの失敗理由を把握します。不具合の原因や解決方法がわからない場合は、Red Hat サポート にお問い合わせください。

重要

Red Hat Ceph Storage クラスターを以前のバージョンからバージョン 4 にアップグレードする場合、Ceph Ansible 設定ではデフォルトのオブジェクトストアタイプが BlueStore に設定されます。OSD オブジェクトストアに FileStore を使用する場合は、Ceph Ansible 設定を明示的に FileStore に設定します。これにより、新たにデプロイされ、置き換えられた OSD は FileStore を使用します。

警告

マルチサイト設定を RedHat Ceph Storage 3 から RedHat Ceph Storage 4 にアップグレードする場合は、以下の推奨事項に注意してください。そうしないと、レプリケーションが破損する可能性があります。rolling_update.yml を実行する前に、all.ymlrgw_multisite: false を設定します。アップグレード後に rgw_multisite を再度有効にしないでください。アップグレード後に新しいゲートウェイを追加する必要がある場合にのみ使用してください。バージョン 3.3z5 以降の Red Hat Ceph Storage 3 クラスターのみを Red Hat Ceph Storage 4 にアップグレードします。3.3z5 以降に更新できない場合は、クラスターをアップグレードする前にサイト間の同期を無効にします。同期を無効にするには、rgw_run_sync_thread = false を設定して、RADOS Gateway デーモンを再起動します。最初にプライマリークラスターをアップグレードします。Red Hat Ceph Storage 4.1 以降にアップグレードします。3.3z5 に関連するパッケージバージョンを確認するには、「What are the Red Hat Ceph Storage releases and corresponding Ceph package versions?」を参照してください。同期を無効にする方法については、「RGW Multisite の同期を一時的に無効にする方法」を参照してください。

警告

Ceph Object Gateway を使用して Red Hat Ceph Storage 3.x から Red Hat Ceph Storage 4.x にアップグレードする場合、フロントエンドは自動的に CivetWeb から Beast (新しいデフォルト) に変更されます。詳細は、『オブジェクトのゲートウェイ設定および管理ガイド』「設定」を参照してください。

警告

RADOS Gateway を使用している場合には、Ansible はフロントエンドを CivetWeb から Beast に切り替えます。この過程で、RGW のインスタンス名が rgw.HOSTNAME から rgw.HOSTNAME.rgw0 に変更されます。名前が変更されたため、Ansible は ceph.conf 内の既存の RGW 設定を更新せず、代わりにデフォルトの設定を追加して、以前の CivetWeb ベースの RGW 設定はそのままですが、これは使用されません。そうすると、RGW のカスタム設定の変更が失われ、RGW のサービスが中断される可能性があります。これを回避するには、アップグレードの前に、all.ymlceph_conf_overrides セクションに既存の RGW 設定を追加します。ただし、.rgw0 を追加してRGWインスタンス名を変更し、RGWサービスを再起動します。これにより、アップグレード後もデフォルトではない RGW の設定変更が保持されます。ceph_conf_overrides の詳細は、「Cephのデフォルト設定の上書き」を参照してください。

7.1. サポート対象の Red Hat Ceph Storage アップグレードシナリオ

Red Hat は、以下のアップグレードシナリオをサポートします。

ベアメタルコンテナー化された の表を読み、特定のアップグレード後の状態に移行するためにクラスターがログインする必要のある状態を確認します。

ceph-ansible を使用して、ベアメタルまたはコンテナー化アップグレードを行います。この場合、ベアメタまたはホストのオペレーティングシステムのメジャーバージョンは変わりません。Red Hat Enterprise Linux 7 から RedHat Enterprise Linux 8 へのアップグレードは、ceph-ansible ではサポートされていません。Red Hat Ceph Storage のアップグレードの一環としてベアメタルオペレーティングシステムを Red Hat Enterprise Linux 7.9 から Red Hat Enterprise Linux 8.4 にアップグレードするには、『Red Hat Ceph Storage インストールガイド』の「Red Hat Ceph Storage クラスターおよびオペレーティングシステムの手動アップグレード」のセクションを参照してください。

注記

Red Hat は、クラスターを Red Hat Ceph Storage 4 にアップグレードする場合に、クラスターが最新バージョンの Red Hat Ceph Storage 3 を使用していることを推奨しています。Red Hat Ceph Storage の最新バージョンを知るには、What are the Red Hat Ceph Storage releases? を参照してください。詳細は、ナレッジベースの記事を参照してください。

表7.1 ベアメタルデプロイメントでサポートされるアップグレードシナリオ

アップグレード前の状態アップグレード後の状態

Red Hat Enterprise Linux のバージョン

Red Hat Ceph Storage のバージョン

Red Hat Enterprise Linux のバージョン

Red Hat Ceph Storage のバージョン

7.6

3.3

7.9

4.2

7.6

3.3

8.4

4.2

7.7

3.3

7.9

4.2

7.7

4.0

7.9

4.2

7.8

3.3

7.9

4.2

7.8

3.3

8.4

4.2

7.9

3.3

8.4

4.2

8.1

4.0

8.4

4.2

8.2

4.1

8.4

4.2

8.2

4.1

8.4

4.2

8.3

4.1

8.4

4.2

表7.2 コンテナー化されたデプロイメントでサポートされるアップグレードシナリオ

アップグレード前の状態アップグレード後の状態

ホストの Red Hat Enterprise Linux のバージョン

コンテナーの Red Hat Enterprise Linux バージョン

Red Hat Ceph Storage のバージョン

ホストの Red Hat Enterprise Linux のバージョン

コンテナーの Red Hat Enterprise Linux バージョン

Red Hat Ceph Storage のバージョン

7.6

7.8

3.3

7.9

8.4

4.2

7.7

7.8

3.3

7.9

8.4

4.2

7.7

8.1

4.0

7.9

8.4

4.2

7.8

7.8

3.3

7.9

8.4

4.2

8.1

8.1

4.0

8.4

8.4

4.2

8.2

8.2

4.1

8.4

8.4

4.2

8.3

8.3

4.1

8.4

8.4

4.2

7.2. アップグレードの準備

Red Hat Ceph Storage クラスターのアップグレードを開始する前に、いくつかの操作を完了する必要があります。これらのステップは、Red Hat Ceph Storage クラスターのベアメタルおよびコンテナーデプロイメントの両方に適用されます (指定がある場合)。

重要

Red Hat Ceph Storage 4 の最新バージョンにのみアップグレードできます。たとえば、バージョン 4.1 が利用可能な場合、3 から 4.0 にアップグレードすることはできません。4.1 に直接移行する必要があります。

重要

FileStore オブジェクトストアを使用する場合は、Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードした後に BlueStore に移行する必要があります。

重要

Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード中に、ceph-ansible を使用して Red Hat Ceph Storage をアップグレードすることはできません。Red Hat Enterprise Linux 7 を使用する必要があります。オペレーティングシステムもアップグレードするには、「Red Hat Ceph Storageクラスターとオペレーティングシステムの手動アップグレード」を参照してください。

重要

Red Hat Ceph Storage 4.2z2 以降のバージョンでは、オプション bluefs_buffered_io がデフォルトで True に設定されています。このオプションは、場合によって BlueFS でバッファー読み取りができるようにし、カーネルページキャッシュが RocksDB ブロック読み取りのような読み取りの二次キャッシュとして機能できるようにします。たとえば、 OMAP の反復時にすべてのブロックを保持ほど、RocksDB のブロックキャッシュが十分にない場合には、ディスクの代わりにページキャッシュから読み出すことが可能な場合があります。これにより、osd_memory_target が小さすぎてブロックキャッシュのすべてのエントリーを保持できない場合に、パフォーマンスが劇的に向上します。現在、bluefs_buffered_io を有効にし、システムレベルのスワップを無効にすることで、パフォーマンスの低下を防いでいます。

前提条件

  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。
  • バージョン 3 からアップグレードする場合、バージョン 3 クラスターが 「Red Hat Ceph Storage 3 の最新バージョンにアップグレード」されている。
  • バージョン 4 にアップグレードする前に、Prometheus ノードエクスポーターサービスが動作している場合は、サービスを停止する。

    [root@mon ~]# systemctl stop prometheus-node-exporter.service

    重要

    これは既知の問題で、今後の Red Hat Ceph Storage のリリースで修正される予定です。この問題の詳細は、Red Hat ナレッジベースの 記事 を参照してください。

    注記

    アップグレード中にインターネットにアクセスできないベアメタル または コンテナー の Red Hat Ceph Storage クラスターノードの場合は、『Red Hat Ceph Storage Installation Guide』の「Registering Red Hat Ceph Storage nodes to the CDN and attaching subscriptions」のセクションに記載の手順に従います。

手順

  1. ストレージクラスター内のすべてのノードで root ユーザーとしてログインします。
  2. Ceph ノードが Red Hat コンテンツ配信ネットワーク (CDN) に接続されていない場合は、ISO イメージを使用して Red Hat Ceph Storage の最新バージョンでローカルリポジトリーを更新することで、Red Hat Ceph Storage をアップグレードできます。
  3. Red Hat Ceph Storage をバージョン 3 からバージョン 4 にアップグレードする場合は、既存の Ceph ダッシュボードのインストールを削除します。

    1. Ansible 管理ノードで、cephmetrics-ansible ディレクトリーに移動します。

      [root@admin ~]# cd /usr/share/cephmetrics-ansible
    2. purge.yml Playbook を実行して、既存の Ceph ダッシュボードのインストールを削除します。

      [root@admin cephmetrics-ansible]# ansible-playbook -v purge.yml
  4. Red Hat Ceph Storage をバージョン 3 からバージョン 4 にアップグレードする場合は、Ansible 管理ノードで Ceph リポジトリーおよび Ansible リポジトリーを有効にします。

    Red Hat Enterprise Linux 7

    [root@admin ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms --enable=rhel-7-server-ansible-2.9-rpms

    Red Hat Enterprise Linux 8

    [root@admin ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms

  5. Ansible 管理ノードで、ansible パッケージおよび ceph-ansible パッケージの最新バージョンがインストールされていることを確認します。

    Red Hat Enterprise Linux 7

    [root@admin ~]# yum update ansible ceph-ansible

    Red Hat Enterprise Linux 8

    [root@admin ~]# dnf update ansible ceph-ansible

  6. Playbook infrastructure-playbooks/rolling_update.yml 編集し、health_osd_check_retries および health_osd_check_delay の値をそれぞれ 50 および 30 に変更します。

    health_osd_check_retries: 50
    health_osd_check_delay: 30

    各 OSD ノードについて、この値により Ansible は最大 25 分待機し、アップグレードプロセスを続行する前に 30 秒ごとにストレージクラスターの正常性をチェックします。

    注記

    ストレージクラスターで使用されているストレージ容量に基づいて、health_osd_check_retries オプションの値をスケールアップまたはダウンします。たとえば、436 TB 未満の 218 TB (ストレージ容量の 50%) を使用している場合は、health_osd_check_retries オプションを 50 に設定します。

  7. アップグレードするストレージクラスターに exclusive-lock 機能を使用する Ceph Block Device イメージが含まれている場合には、全 Ceph Block Device ユーザーにクライアントをブラックリストに登録するパーミッションがあるようにしてください。

    ceph auth caps client.ID mon 'allow r, allow command "osd blacklist"' osd 'EXISTING_OSD_USER_CAPS'
  8. ストレージクラスターが Cockpit を使用して最初にインストールされている場合は、/usr/share/ceph-ansible ディレクトリーに、Cockpit が作成したインベントリーファイルへのシンボリックリンクを /usr/share/ansible-runner-service/inventory/hosts に作成します。

    1. /usr/share/ceph-ansible ディレクトリーに移動します。

      # cd /usr/share/ceph-ansible
    2. シンボリックリンクを作成します。

      # ln -s /usr/share/ansible-runner-service/inventory/hosts hosts
  9. ceph-ansible を使用してクラスターをアップグレードするには、hosts インベントリーファイルのシンボリックリンクを etc/ansible/hosts ディレクトリーに作成します。

    # ln -s /etc/ansible/hosts hosts
  10. ストレージクラスターが Cockpit を使用して最初にインストールされている場合は、Cockpit で生成された SSH 鍵を Ansible ユーザーの ~/.ssh ディレクトリーにコピーします。

    1. 鍵をコピーします。

      # cp /usr/share/ansible-runner-service/env/ssh_key.pub /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # cp /usr/share/ansible-runner-service/env/ssh_key /home/ANSIBLE_USERNAME/.ssh/id_rsa

      ANSIBLE_USERNAME は、Ansible のユーザー名に置き換えます (通常は admin)。

      # cp /usr/share/ansible-runner-service/env/ssh_key.pub /home/admin/.ssh/id_rsa.pub
      # cp /usr/share/ansible-runner-service/env/ssh_key /home/admin/.ssh/id_rsa

    2. キーファイルに適切な所有者、グループ、およびパーミッションを設定します。

      # chown ANSIBLE_USERNAME:_ANSIBLE_USERNAME_ /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # chown ANSIBLE_USERNAME:_ANSIBLE_USERNAME_ /home/ANSIBLE_USERNAME/.ssh/id_rsa
      # chmod 644 /home/ANSIBLE_USERNAME/.ssh/id_rsa.pub
      # chmod 600 /home/ANSIBLE_USERNAME/.ssh/id_rsa

      ANSIBLE_USERNAME は、Ansible のユーザー名に置き換えます (通常は admin)。

      # chown admin:admin /home/admin/.ssh/id_rsa.pub
      # chown admin:admin /home/admin/.ssh/id_rsa
      # chmod 644 /home/admin/.ssh/id_rsa.pub
      # chmod 600 /home/admin/.ssh/id_rsa

関連情報

7.3. Ansible を使用したストレージクラスターのアップグレード

Ansible デプロイメントツールを使用して、ローリングアップグレードを実行して Red Hat Ceph Storage クラスターをアップグレードできます。これらのステップは、特に特に記載がない限り、ベアメタルおよびコンテナーのデプロイメントの両方に適用されます。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • ansible ユーザーアカウント。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible/

  2. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、group_vars/all.yml ファイル、group_vars/osds.yml ファイル、および group_vars/clients.yml ファイルのバックアップコピーを作成します。

    [root@admin ceph-ansible]# cp group_vars/all.yml group_vars/all_old.yml
    [root@admin ceph-ansible]# cp group_vars/osds.yml group_vars/osds_old.yml
    [root@admin ceph-ansible]# cp group_vars/clients.yml group_vars/clients_old.yml
  3. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、group_vars/all.yml.samplegroup_vars/osds.yml.sample、および group_vars/clients.yml.sample ファイルの新しいコピーを作成し、名前を group_vars/all.ymlgroup_vars/osds.yml、および group_vars/clients.yml に変更します。以前にバックアップしたコピーに基づいて変更を開き、編集します。

    [root@admin ceph-ansible]# cp group_vars/all.yml.sample group_vars/all.yml
    [root@admin ceph-ansible]# cp group_vars/osds.yml.sample group_vars/osds.yml
    [root@admin ceph-ansible]# cp group_vars/clients.yml.sample group_vars/clients.yml
  4. group_vars/osds.yml ファイルを編集します。以下のオプションを追加して設定します。

    nb_retry_wait_osd_up: 60
    delay_wait_osd_up: 10
    注記

    これらはデフォルト値です。ユースケースに従って値を変更できます。

  5. Red Hat Ceph Storage 4 の新規マイナーバージョンにアップグレードする場合は、group_vars/all.ymlgrafana_container_image の値が group_vars/all.yml.sample の値と同じであることを確認します。同じでない場合は、同じになるように編集します。

    grafana_container_image: registry.redhat.io/rhceph/rhceph-4-dashboard-rhel8:4

    注記

    以下に示すイメージパスは、ceph-ansible バージョン 4.0.23-1 に含まれています。

  6. サンプルファイルから最新の site.yml ファイルまたは site-container.yml ファイルをコピーします。

    1. ベアメタル デプロイメントの場合:

      [root@admin ceph-ansible]# cp site.yml.sample site.yml
    2. コンテナー デプロイメントの場合:

      [root@admin ceph-ansible]# cp site-container.yml.sample site-container.yml
  7. group_vars/all.yml ファイルを開き、以下のオプションを編集します。

    1. fetch_directory オプションを追加します。

      fetch_directory: FULL_DIRECTORY_PATH
      置き換え
      • FULL_DIRECTORY_PATH を、書き込み可能な場所 (Ansible ユーザーのホームディレクトリーなど) に置き換えます。
    2. アップグレードするクラスターに Ceph Object Gateway ノードが含まれている場合には、radosgw_interface オプションを追加します。

      radosgw_interface: INTERFACE
      置き換え
      • Ceph Object Gateway がリッスンするインターフェースを使用する INTERFACE
    3. 現在の設定で SSL 証明書が設定されている場合は、以下を編集する必要があります。

      radosgw_frontend_ssl_certificate: /etc/pki/ca-trust/extracted/CERTIFICATE_NAME
      radosgw_frontend_port: 443
    4. デフォルトの OSD オブジェクトストアは BlueStore です。従来の OSD オブジェクトストアを維持するには、osd_objectstore オプションを明示的に filestore に設定する必要があります。

      osd_objectstore: filestore
      注記

      osd_objectstore オプションを filestore に設定し、OSD を置き換えると BlueStore ではなく FileStore が使用されます。

      重要

      Red Hat Ceph Storage 4 以降、FileStore は非推奨の機能になりました。Red Hat は、FileStore OSD を BlueStore OSD に移行することを推奨します。

    5. Red Hat Ceph Storage 4.1 以降、/usr/share/ceph-ansible/group_vars/all.ymldashboard_admin_password および grafana_admin_password をコメント解除するか設定する必要があります。それぞれに安全なパスワードを設定します。dashboard_admin_user および grafana_admin_user のカスタムユーザー名も設定します。
    6. ベアメタル および コンテナー の両方のデプロイメントの場合:

      1. upgrade_ceph_packages オプションをコメント解除して、True に設定します。

        upgrade_ceph_packages: True
      2. ceph_rhcs_version オプションを 4 に設定します。

        ceph_rhcs_version: 4
        注記

        ceph_rhcs_version オプションを 4 に設定すると、最新バージョンの Red Hat Ceph Storage 4 がプルされます。

      3. ceph_docker_registry 情報を all.yml に追加します。

        構文

        ceph_docker_registry: registry.redhat.io
        ceph_docker_registry_username: SERVICE_ACCOUNT_USER_NAME
        ceph_docker_registry_password: TOKEN

        注記

        Red Hat レジストリーサービスアカウントがない場合は、レジストリーサービスアカウントの Web ページ を使用して作成します。詳細は、「Red Hat Container Registry Authentication」のナレッジベース記事を参照してください。

        注記

        ceph_docker_registry_username および ceph_docker_registry_password パラメータにサービスアカウントを使用するだけでなく、カスタマーポータルの認証情報を使用することもできますが、ceph_docker_registry_password パラメータを暗号化してセキュリティーを確保してください。詳細は、「ansible-vault で Ansible のパスワード変数を暗号化する」を参照してください。

    7. コンテナー のデプロイメントの場合:

      1. ceph_docker_image オプションを変更して、Ceph 4 コンテナーバージョンを指定します。

        ceph_docker_image: rhceph/rhceph-4-rhel8
      2. ceph_docker_image_tag オプションを変更して、rhceph/rhceph-4-rhel8 の最新バージョンを参照します。

        ceph_docker_image_tag: latest
  8. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、Ansible インベントリーファイルでデフォルトで /etc/ansible/hosts を開き、[grafana-server] セクションに Ceph ダッシュボードのノード名または IP アドレスを追加します。このセクションが存在しない場合は、ノード名または IP アドレスとともにこのセクションも追加します。
  9. Ansible ユーザーに切り替えるかログインしてから、rolling_update.yml Playbook を実行します。

    [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/rolling_update.yml -i hosts
    重要

    rolling_update.yml Playbook で --limit Ansible オプションを使用することはサポートされていません。

  10. RBD ミラーリングデーモンノードの root ユーザーとして、rbd-mirror パッケージを手動でアップグレードします。

    [root@rbd ~]# yum upgrade rbd-mirror
  11. rbd-mirror デーモンを再起動します。

    systemctl restart ceph-rbd-mirror@CLIENT_ID
  12. Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードする場合は、ceph.conf ファイルの設定オプションをストレージクラスターの設定データベースにインポートします。

    [root@mon ~]# ceph config assimilate-conf -i /etc/ceph/ceph.conf

    1. ストレージクラスターの設定データベースを確認します。

      [root@mon ~]# ceph config dump

    2. ceph.conf ファイルの設定オプションをストレージクラスターの設定データベースにインポートするために、すべての Ceph ノードで上記の手順を繰り返します。
  13. ストレージクラスターのヘルスステータスを確認します。

    1. ベアメタル デプロイメントの場合は、root ユーザーとして monitor ノードにログインし、Ceph status コマンドを実行します。

      [root@mon ~]# ceph -s
    2. container デプロイメントの場合は、Ceph Monitor ノードに root ユーザーとしてログインします。

      1. 実行中のコンテナーの一覧を表示します。

        Red Hat Enterprise Linux 7

        [root@mon ~]# docker ps

        Red Hat Enterprise Linux 8

        [root@mon ~]# podman ps

      2. ヘルスステータスを確認します。

        Red Hat Enterprise Linux 7

        [root@mon ~]# docker exec ceph-mon-MONITOR_NAME ceph -s

        Red Hat Enterprise Linux 8

        [root@mon ~]# podman exec ceph-mon-MONITOR_NAME ceph -s

        置き換え
        • MONITOR_NAME は、前のステップで見つかった Ceph Monitor コンテナーの名前にします。

          [root@mon ~]# podman exec ceph-mon-mon01 ceph -s

  14. オプション: Red Hat Ceph Storage 3.x から Red Hat Ceph Storage 4.x にアップグレードした場合に、Legacy BlueStore stats reporting detected on 336 OSD(s). というヘルスに関する警告が表示される場合があります。これは、新しいコードではプール統計の計算方法が異なることが原因です。正確な報告を行い、警告が表示されないようにするには、すべての OSD で 修復 機能を実行してください。

    1. OSD サービスを停止します。

      [root@osd ~]# systemctl stop ceph-osd.target
    2. 実際の OSD ID を指定して、OSD の修復機能を実行します。

      構文

      ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-OSDID repair

      [root@osd ~]# ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-2 repair

    3. OSD サービスを起動します。

      [root@osd ~]# systemctl start ceph-osd.target
  15. アップグレードが終了したら、Ansible の Playbook を実行して、FileStore OSD を BlueStore OSD に移行します。

    構文

    ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit OSD_NODE_TO_MIGRATE

    [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/filestore-to-bluestore.yml --limit osd01

    移行が完了したら、以下のサブ手順を実行します。

    1. group_vars/osds.yml ファイルを編集するために開き、osd_objectstore オプションを bluestore に設定します。以下に例を示します。

      osd_objectstore: bluestore
    2. lvm_volumes 変数を使用している場合は、journal オプションおよび journal_vg オプションをそれぞれ db および db_vg に変更します。以下に例を示します。

      lvm_volumes:
        - data: /dev/sdb
          journal: /dev/sdc1
        - data: /dev/sdd
          journal: journal1
          journal_vg: journals

      Bluestore への変換後

      lvm_volumes:
        - data: /dev/sdb
          db: /dev/sdc1
        - data: /dev/sdd
          db: journal1
          db_vg: journals

  16. OpenStack 環境で動作する場合には、すべての cephx ユーザーがプールに RBD プロファイルを使用するように更新します。以下のコマンドは root ユーザーとして実行する必要があります。

    1. Glance ユーザー:

      構文

      ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd pool=GLANCE_POOL_NAME'

      [root@mon ~]# ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd pool=images'

    2. Cinder ユーザー:

      構文

      ceph auth caps client.cinder mon 'profile rbd' osd 'profile rbd pool=CINDER_VOLUME_POOL_NAME, profile rbd pool=NOVA_POOL_NAME, profile rbd-read-only pool=GLANCE_POOL_NAME'

      [root@mon ~]# ceph auth caps client.cinder mon 'profile rbd' osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd-read-only pool=images'

    3. OpenStack の一般ユーザーは、以下のようになります。

      構文

      ceph auth caps client.openstack mon 'profile rbd' osd 'profile rbd-read-only pool=CINDER_VOLUME_POOL_NAME, profile rbd pool=NOVA_POOL_NAME, profile rbd-read-only pool=GLANCE_POOL_NAME'

      [root@mon ~]# ceph auth caps client.openstack mon 'profile rbd' osd 'profile rbd-read-only pool=volumes, profile rbd pool=vms, profile rbd-read-only pool=images'

      重要

      ライブクライアントの移行を実行する前に、これらの CAPS 更新を行います。これにより、クライアントがメモリーで実行している新しいライブラリーを使用でき、古い CAPS 設定がキャッシュから破棄され、新しい RBD プロファイル設定が適用されるようになります。

  17. 必要に応じて、クライアントノードで、Ceph クライアント側ライブラリーに依存するアプリケーションを再起動します。

    注記

    QEMU または KVM インスタンスを実行している OpenStack Nova コンピュートノードをアップグレードする場合や、専用の QEMU または KVM クライアントを使用する場合には、インスタンスを再起動しても機能しないため、QEMU または KVM インスタンスを停止して起動してください。

関連情報

7.4. コマンドラインインターフェースを使用したストレージクラスターのアップグレード

ストレージクラスターの実行中に、Red Hat Ceph Storage 3.3 から Red Hat Ceph Storage 4 にアップグレードできます。これらのバージョンの重要な違いは、Red Hat Ceph Storage4 がデフォルトで msgr2 プロトコルを使用することです。これはポート 3300 を使用します。開いていない場合、クラスターは HEALTH_WARN エラーを発行します。

ストレージクラスターのアップグレード時に考慮すべき制約を以下に示します。

  • Red Hat Ceph Storage 4 では、デフォルトで msgr2 プロトコルが使用されます。Ceph Monitor ノードでポート 3300 が開いていることを確認します。
  • ceph-monitor デーモンを Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 にアップグレードしたら、Red Hat Ceph Storage 3 の ceph-osd デーモンは、Red Hat Ceph Storage 4 にアップグレードするまで、新しい OSD を作成 できません
  • アップグレードの進行中はプールを 作成しないでください

前提条件

  • Ceph Monitor ノード、OSD ノード、および Object Gateway ノードへのルートレベルのアクセス。

手順

  1. Red Hat Ceph Storage 3 の実行中に、クラスターがすべての PG の完全スクラブを 1 つ以上完了していることを確認します。これを実行しないと、モニターデーモンは起動時にクォーラムへの参加を拒否し、機能しなくなる可能性があります。クラスターがすべての PG の完全スクラブを 1 つ以上完了していることを確認するには、以下を実行します。

    # ceph osd dump | grep ^flags

    Red Hat Ceph Storage 3 から Red Hat Ceph Storage 4 へのアップグレードを続行するには、OSD マップに recovery_deletes フラグおよび purged_snapdirsフラグが含まれている必要があります。

  2. クラスターが正常な状態でクリーンな状態であることを確認します。

    # ceph health
    HEALTH_OK
  3. ceph-mon および ceph-manager を実行しているノードの場合は、以下のコマンドを実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、それぞれの ceph-mon ノードおよび ceph- manager ノードで以下のコマンドを実行します。

    # firewall-cmd --add-port=3300/tcp
    # firewall-cmd --add-port=3300/tcp --permanent
    # yum update -y
    # systemctl restart ceph-mon@<mon-hostname>
    # systemctl restart ceph-mgr@<mgr-hostname>

    <mon-hostname> および <mgr-hostname> をターゲットホストのホスト名に置き換えます。

  4. OSD をアップグレードする前に、アップグレード中の OSD のリバランスを防ぐために、Ceph Monitor ノードで norebalance フラグを設定します。

    # ceph osd set norebalance
  5. 各 OSD ノードで、以下を実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、OSD ノードを更新します。

    # yum update -y

    ノードで実行している各 OSD デーモンについて、以下のコマンドを実行します。

    # systemctl restart ceph-osd@<osd-num>

    <osd-num> を、再起動する osd 番号に置き換えてください。次の OSD ノードに進む前に、ノード上の全 OSD が再起動したことを確認します。

  6. ceph-disk を使用してデプロイされたストレージクラスターに OSD がある場合には、ceph-volume にデーモンを起動するように指示します。

    # ceph-volume simple scan
    # ceph-volume simple activate --all
  7. Nautilus の機能のみを有効にします。

    # ceph osd require-osd-release nautilus
    重要

    このステップの実行に失敗すると、msgr2 が有効になってから OSD が通信できなくなります。

  8. すべての OSD ノードをアップグレードしたら、Ceph Monitor ノードで noout フラグの設定を解除します。

    # ceph osd unset noout
  9. 既存の CRUSH バケットを、最新のバケットタイプ straw2 に切り替えます。

    # ceph osd getcrushmap -o backup-crushmap
    # ceph osd crush set-all-straw-buckets-to-straw2
  10. Specify v2 プロトコル msgr2 を有効にします。

    # ceph mon enable-msgr2

    これにより、古いデフォルトポート 6789 にバインドされるすべての Ceph Monitor が新しいポート 3300 にバインドされるように指示します。

    1. monitor のステータスを確認します。

      #ceph mon dump
  11. Ceph Object Gateway ノードで、以下を実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms

    Red Hat Ceph Storage 4 パッケージを有効にしたら、ノードを更新して、ceph-rgw デーモンを再起動します。

    # yum update -y
    # systemctl restart ceph-rgw@<rgw-target>

    <rgw-target> を、再起動する rgw ターゲットに置き換えてください。

  12. 管理ノードの場合には、以下のコマンドを実行します。

    # subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms
    # yum update -y
  13. クラスターが正常な状態でクリーンな状態であることを確認します。

    # ceph health
    HEALTH_OK
  14. 必要に応じて、クライアントノードで、Ceph クライアント側ライブラリーに依存するアプリケーションを再起動します。

    注記

    QEMU または KVM インスタンスを実行している OpenStack Nova コンピュートノードをアップグレードする場合や、専用の QEMU または KVM クライアントを使用する場合には、インスタンスを再起動しても機能しないため、QEMU または KVM インスタンスを停止して起動してください。

7.5. Ceph File System Metadata Serve rノードの手動アップグレード

Red Hat Enterprise Linux 7 または 8 を実行している Red Hat Ceph Storage クラスターで、Ceph File System (CephFS) Metadata Server (MDS) ソフトウェアを手動でアップグレードできます。

重要

ストレージクラスターをアップグレードする前に、アクティブな MDS ランクの数を減らし、ファイルシステムごとに 1 つにします。これにより、複数の MDS 間でバージョンの競合が発生しなくなります。また、アップグレードを行う前に、すべてのスタンバイノードをオフラインにしてください。

これは、MDSクラスターにはバージョニングやファイルシステムフラグが組み込まれていないためです。これらの機能がないと、複数の MDS が異なるバージョンの MDS ソフトウェアを使用して通信することになり、アサーションやその他の不具合が発生する可能性があります。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • ノードは Red Hat Ceph Storageバージョン 3.3z64 または 4.1 を使用している。
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。
重要

基盤となる XFS ファイルシステムが ftype=1でフォーマットされているか、d_type をサポートしている。xfs_info /var コマンドを実行し、ftype1 になっていることを確認します。ftype の値が 1 でない場合は、新しいディスクをアタッチするか、ボリュームを作成します。この新しいデバイスの上に、新しいXFSファイルシステムを作成し、/var/lib/containers にマウントします。

Red Hat Enterprise Linux 8.0 以降、mkfs.xfs はデフォルトで ftype=1 を有効にします。

手順

  1. アクティブな MDS ランクを 1 にします。

    構文

    ceph fs set FILE_SYSTEM_NAME max_mds 1

    [root@mds ~]# ceph fs set fs1 max_mds 1

  2. クラスターがすべての MDS ランクを停止するのを待ちます。すべての MDS が停止したら、ランク 0 だけがアクティブになるはずです。残りはスタンバイモードにしておきます。ファイルシステムの状態を確認します。

    [root@mds ~]# ceph status
  3. systemctl を使用して、スタンバイしているすべての MDS をオフラインにします。

    [root@mds ~]# systemctl stop ceph-mds.target
  4. MDS が 1 つだけオンラインになっており、ファイルシステムのランクが 0 であることを確認します。

    [root@mds ~]# ceph status
  5. RHEL 7 で Red Hat Ceph Storage 3 からアップグレードする場合は、Red Hat Ceph Storage 3 のツールリポジトリーを無効にして、Red Hat Ceph Storage 4 のツールリポジトリーを有効にします。

    [root@mds ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    [root@mds ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms
  6. ノードを更新し、ceph-mds デーモンを再起動します。

    [root@mds ~]# yum update -y
    [root@mds ~]# systemctl restart ceph-mds.target
  7. スタンバイ中のデーモンについても同じプロセスを実行します。ツールリポジトリーを無効にして、有効にしてから、各スタンバイ中の MDS をアップグレードし、再起動します。

    [root@mds ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    [root@mds ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-tools-rpms
    [root@mds ~]# yum update -y
    [root@mds ~]# systemctl restart ceph-mds.target
  8. スタンバイ中のすべての MDS の再起動が完了したら、ストレージクラスターの max_mds の値を以前の値に戻します。

    構文

    ceph fs set FILE_SYSTEM_NAME max_mds ORIGINAL_VALUE

    [root@mds ~]# ceph fs set fs1 max_mds 5

7.6. 関連情報

第8章 Red Hat Ceph Storage クラスターおよびオペレーティングシステムの手動によるアップグレード

通常、ceph-ansible を使用する場合には、Red Hat Ceph Storage および Red Hat Enterprise Linux を同時に新しいメジャーリリースにアップグレードすることはできません。たとえば、Red Hat Enterprise Linux 7を使用し、ceph-ansible を使用している場合は、そのバージョンを使用する必要があります。ただし、システム管理者は手動で実行できます。

本章では、Red Hat Enterprise Linux 7.9 で実行しているバージョン 4.1 または 3.3z6 の Red Hat Ceph Storage クラスターを、Red Hat Enterprise Linux 8.4 で実行するバージョン 4.2 の Red Hat Ceph Storage クラスターに手動でアップグレードします。

重要

コンテナー化されたRed Hat Ceph Storage クラスターをバージョン 3.x または 4.x からバージョン 4.2 にアップグレードする場合は、『Red Hat Ceph Storage インストールガイド』の「サポートされているRed Hat Ceph Storageのアップグレードシナリオ」、「アップグレードの準備」および「Ansibleを使用したストレージクラスタのアップグレード」の 3 つのセクションを参照してください。

既存の systemd テンプレートを移行するには、docker-to-podman Playbook を実行します。

[user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/docker-to-podman.yml -i hosts

user は Ansible のユーザーに置き換えます。

重要

1 つのノードに複数のデーモンが配置されている場合には、そのノードに配置されているデーモンに関する、本章の特定のセクションに従ってください。たとえば、Ceph Monitor デーモンや OSD デーモンが配置されているノードなどです。

Ceph Monitor ノードとそのオペレーティングシステムを手動でアップグレード」および「Ceph OSD ノードとそのオペレーティングシステムの手動によるアップグレード」を参照してください。

重要

Leapp アップグレードユーティリティーは OSD 暗号化によるアップグレードをサポートしないため、Ceph OSD ノードとオペレーティングシステムの手動アップグレードは、暗号化された OSD パーティションでは機能しません。

8.1. 前提条件

  • 実行中の Red Hat Ceph Storage クラスター。
  • 各ノード で Red Hat Enterprise Linux 7.9 を使用している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z6 または 4.1 を使用している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

8.2. Ceph Monitor ノードとそのオペレーティングシステムを手動でアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Monitor ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

一度に 1 つのモニターノードのみで手順を実施します。クラスターアクセスの問題を防ぐために、次のノードに進む に、現在のアップグレードされた Monitor ノードが通常の操作に返されていることを確認してください。

前提条件

  • 実行中の Red Hat Ceph Storage クラスター。
  • 各ノード で Red Hat Enterprise Linux 7.9 を使用している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z6 または 4.1 を使用している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. monitor サービスを停止します。

    構文

    systemctl stop ceph-mon@MONITOR_ID

    MONITOR_ID を Monitor の ID 番号に置き換えます。

  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    2. mon リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-mon-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
    2. mon リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable= rhel-7-server-rhceph-4-mon-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    [root@mon ~]# systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    [root@mon ~]# modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      [root@mon ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. mon リポジトリーを有効にします。

      [root@mon ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  12. ceph-mon パッケージをインストールします。

    [root@mon ~]# dnf install ceph-mon
  13. マネージャーサービスが monitor サービスと同じ場所にある場合は、ceph-mgr パッケージをインストールします。

    [root@mon ~]# dnf install ceph-mgr
  14. アップグレードされていない、またはそれらのファイルをすでに復元しているノードから、ceph-client-admin.keyring ファイルおよび ceph.conf ファイルを復元します。
  15. leveldb パッケージをインストールします。

    [root@mon ~]# dnf install leveldb
  16. monitor サービスを起動します。

    [root@mon ~]# systemctl start ceph-mon.target
  17. マネージャーサービスが monitor サービスと同じ場所にある場合は、マネージャーサービスも起動します。

    [root@mon ~]# systemctl start ceph-mgr.target
  18. モニターサービスが復旧し、クォーラムになっていることを確認します。

    [root@mon ~]# ceph -s

    services:mon: 行で、ノードが 定足数 の外ではなく 定足数 内に一覧表示されていることを確認します。

    mon: 3 daemons, quorum ceph4-mon,ceph4-mon2,ceph4-mon3 (age 2h)

  19. マネージャーサービスが monitor サービスと同じ場所にある場合は、それも稼働していることを確認します。

    [root@mon ~]# ceph -s

    services の下にある mgr: 行でマネージャーのノード名を検索します。

    mgr: ceph4-mon(active, since 2h), standbys: ceph4-mon3, ceph4-mon2

  20. すべてのアップグレードが完了するまで、すべての監視ノードで上記の手順を繰り返します。

8.3. Ceph OSD ノードとそのオペレーティングシステムの手動によるアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph OSD ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

この手順は、Ceph クラスターの各 OSD ノードに対して実行する必要がありますが、通常は一度に 1 つの OSD ノードに対してのみ実行してください。OSD ノードに相当する最大 1 つ障害ドメインを並行して実行することが可能です。たとえば、ラックごとのレプリケーションが使用されている場合は、ラックの OSD ノード全体を並行してアップグレードできます。データへのアクセスの問題を防ぐには、現在の OSD ノードの OSD が正常な動作に戻り、クラスターの PG が すべて次の OSD に進む active+clean 状態にあることを確認します。

重要

Leapp アップグレードユーティリティーは OSD 暗号化によるアップグレードをサポートしないため、この手順は暗号化された OSD パーティションでは機能しません。

重要

OSD が ceph-disk を使用して作成されていて、ceph-disk が管理している場合には、ceph-volume を使用してそれらの管理を引き継ぐ必要があります。これは、以下の任意の手順で説明されています。

前提条件

  • 実行中の Red Hat Ceph Storage クラスター。
  • 各ノード で Red Hat Enterprise Linux 7.9 を使用している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z6 または 4.0 を使用している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. OSD の noout フラグを設定して、移行中に OSD がダウンとマークされないようにします。

    ceph osd set noout
  2. クラスター上で不要な負荷を回避するには、OSD nobackfill フラグ、norecover フラグ、norrebalance フラグ、noscrub フラグ、および nodeep-scrub フラグを設定し、ノードが移行のためにダウンした場合にデータの再起動を回避します。

    ceph osd set nobackfill
    ceph osd set norecover
    ceph osd set norebalance
    ceph osd set noscrub
    ceph osd set nodeep-scrub
  3. ノード上のすべての OSD プロセスを正常にシャットダウンします。

    [root@mon ~]# systemctl stop ceph-osd.target
  4. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    2. osd リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-osd-rpms
  5. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 リポジトリーを無効にします。

    1. tools リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
    2. osd リポジトリーを無効にします。

      [root@mon ~]# subscription-manager repos --disable=rhel-7-server-rhceph-4-osd-rpms
  6. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  7. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  8. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  9. OpenSSH SSH デーモンを再起動します。

    [root@mon ~]# systemctl restart sshd.service
  10. Linux カーネルから iSCSI モジュールを削除します。

    [root@mon ~]# modprobe -r iscsi
  11. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  12. ノードを再起動します。
  13. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      [root@mon ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. osd リポジトリーを有効にします。

      [root@mon ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  14. ceph-osd パッケージをインストールします。

    [root@mon ~]# dnf install ceph-osd
  15. leveldb パッケージをインストールします。

    [root@mon ~]# dnf install leveldb
  16. まだアップグレードされていないノードから、またはそれらのファイルがすでに復元されているノードから、ceph.conf ファイルを復元します。
  17. nooutnobackfillnorecovernorrebalancenoscrub、および nodeep-scrub フラグの設定を解除します。

    # ceph osd unset noout
    # ceph osd unset nobackfill
    # ceph osd unset norecover
    # ceph osd unset norebalance
    # ceph osd unset noscrub
    # ceph osd unset nodeep-scrub
  18. 必要に応じて、OSD が ceph-disk を使用して作成されていて、ceph-disk で引き続き管理されている場合には、ceph-volume を使用してそれらの管理を引き継ぐ必要があります。

    1. 各オブジェクトのストレージデバイスをマウントします。

      構文

      /dev/DRIVE /var/lib/ceph/osd/ceph-OSD_ID

      DRIVE は、ストレージデバイス名とパーティション番号に置き換えます。

      OSD_ID を OSD ID に置き換えます。

      [root@mon ~]# mount /dev/sdb1 /var/lib/ceph/osd/ceph-0

      ID_NUMBER が正しいことを確認します。

      構文

      cat /var/lib/ceph/osd/ceph-OSD_ID/whoami

      OSD_ID を OSD ID に置き換えます。

      [root@mon ~]# cat /var/lib/ceph/osd/ceph-0/whoami
      0

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

    2. 新たにマウントしたデバイスをスキャンします。

      構文

      ceph-volume simple scan /var/lib/ceph/osd/ceph-OSD_ID

      OSD_ID を OSD ID に置き換えます。

      [root@mon ~]# ceph-volume simple scan /var/lib/ceph/osd/ceph-0
       stderr: lsblk: /var/lib/ceph/osd/ceph-0: not a block device
       stderr: lsblk: /var/lib/ceph/osd/ceph-0: not a block device
       stderr: Unknown device, --name=, --path=, or absolute path in /dev/ or /sys expected.
      Running command: /usr/sbin/cryptsetup status /dev/sdb1
      --> OSD 0 got scanned and metadata persisted to file: /etc/ceph/osd/0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba.json
      --> To take over management of this scanned OSD, and disable ceph-disk and udev, run:
      -->     ceph-volume simple activate 0 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

    3. デバイスをアクティベートします。

      構文

      ceph-volume simple activate OSD_ID UUID

      OSD_ID を OSD ID に置き換え、UUID を、以前のスキャン出力で出力される UUID に置き換えます。

      [root@mon ~]# ceph-volume simple activate 0 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba
      Running command: /usr/bin/ln -snf /dev/sdb2 /var/lib/ceph/osd/ceph-0/journal
      Running command: /usr/bin/chown -R ceph:ceph /dev/sdb2
      Running command: /usr/bin/systemctl enable ceph-volume@simple-0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba
       stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@simple-0-0c9917f7-fce8-42aa-bdec-8c2cf2d536ba.service → /usr/lib/systemd/system/ceph-volume@.service.
      Running command: /usr/bin/ln -sf /dev/null /etc/systemd/system/ceph-disk@.service
      --> All ceph-disk systemd units have been disabled to prevent OSDs getting triggered by UDEV events
      Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
       stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph-osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
      Running command: /usr/bin/systemctl start ceph-osd@0
      --> Successfully activated OSD 0 with FSID 0c9917f7-fce8-42aa-bdec-8c2cf2d536ba

      追加のオブジェクトストアデバイスに対して上記の手順を繰り返します。

  19. 必要に応じて、OSD が ceph-volume で作成され、直前の手順を完了していない場合は、ここで OSD サービスを起動します。

    [root@mon ~]# systemctl start ceph-osd.target
  20. OSD をアクティベートします。

    BlueStore

    [root@mon ~]# ceph-volume lvm activate --all

  21. OSD がup および in になっていること、ならびに、active+clean 状態にあることを確認します。

    [root@mon ~]# ceph -s

    services: サービス下の osd: 行で、すべての OSD が up および in であることを確認します。

    osd: 3 osds: 3 up (since 8s), 3 in (since 3M)

  22. すべての OSD ノードがアップグレードされるまで、上記の手順をすべての OSD ノードで繰り返します。

8.4. Ceph Object Gateway ノードとそのオペレーティングシステムの手動によるアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Object Gateway (RGW) ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

この手順は、Ceph クラスターの各 RGW ノードに対して実行する必要がありますが、一度に 1 つの RGW ノードに対してのみ実行してください。現在アップグレードした RGW が通常操作に戻るには、クライアントアクセスの問題を防ぐために、次のノードに進む に、通常の操作に戻ります。

前提条件

  • 実行中の Red Hat Ceph Storage クラスター。
  • 各ノード で Red Hat Enterprise Linux 7.9 を使用している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z6 または 4.1 を使用している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. Ceph Object Gateway サービスを停止します。

    # systemctl stop ceph-radosgw.target
  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前チェックを実行します。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のツールリポジトリーを有効にします。

    # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  12. ceph-radosgw パッケージをインストールします。

    # dnf install ceph-radosgw
  13. 必要に応じて、このノードにコロケーションされる Ceph サービスのパッケージをインストールします。必要に応じて追加の Ceph リポジトリーを有効にします。
  14. 必要に応じて、他の Ceph サービスに必要な leveldb パッケージをインストールします。

    # dnf install leveldb
  15. アップグレードされていないノードまたはそれらのファイルを復元しているノードから ceph-client-admin.keyring ファイルおよび ceph.conf ファイルを復元します。
  16. RGW サービスを起動します。

    # systemctl start ceph-radosgw.target
  17. デーモンがアクティブであることを確認します。

    # ceph -s

    services: の下に rgw: 行があります。

    rgw: 1 daemon active (jb-ceph4-rgw.rgw0)

  18. すべてがアップグレードされるまで、すべての Ceph ObjectGateway ノードで上記の手順を繰り返します。

8.5. Ceph Dashboard ノードとそのオペレーティングシステムを手動でアップグレード

システム管理者は、Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Dashboard ソフトウェアを同時に新しいメジャーリリースにアップグレードできます。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • ノードで Red Hat Enterprise Linux 7.9 を実行している。
  • ノードが Red Hat Ceph Storageバージョン 3.3z6 または 4.1 を実行している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. クラスターから既存のダッシュボードをアンインストールします。

    1. /usr/share/cephmetrics-ansible ディレクトリーに移動します。

      # cd /usr/share/cephmetrics-ansible
    2. Ansible Playbook の purge.yml を実行します。

      # ansible-playbook -v purge.yml
  2. Red Hat Ceph Storage 3 を使用している場合は、Red Hat Ceph Storage 3 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
  3. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 ツールリポジトリーを無効にします。

    # subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
  4. leapp ユーティリティーをインストールします。『Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード』を参照してください。
  5. leapp のアップグレード前のチェックを行います。「コマンドラインからのアップグレード可能性の評価」を参照してください。
  6. /etc/ssh/sshd_configPermitRootLogin yes を設定します。
  7. OpenSSH SSH デーモンを再起動します。

    # systemctl restart sshd.service
  8. Linux カーネルから iSCSI モジュールを削除します。

    # modprobe -r iscsi
  9. 『RHEL 7 から RHEL 8 へのアップグレードの実行』に従って、アップグレードを実行します。
  10. ノードを再起動します。
  11. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のツールリポジトリーを有効にします。

    # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  12. Ansible リポジトリーを有効にします。

    # subscription-manager repos --enable=ansible-2.9-for-rhel-8-x86_64-rpms
  13. クラスターを管理するために ceph-ansible を構成します。ダッシュボードがインストールされます。「Ansible を使用した Red Hat Ceph Storage のインストール」 (前提条件を含む) の手順に従ってください。
  14. 上記の手順の一部として ansible-playbook site.yml を実行すると、ダッシュボードの URL が出力されます。URL の場所とダッシュボードへのアクセスに関する詳細は、『ダッシュボード』「Ansible を使用したダッシュボードのインストール」を参照してください。

8.6. Ceph Ansible ノードの手動でのアップグレードと再設定

Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph Ansible ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。この手順は、指定しない限り、ベアメタルおよびコンテナーのデプロイメントの両方に適用されます。

重要

Ceph Ansible ノードの hostOS をアップグレードする前に、group_varshosts ファイルのバックアップを取ります。Ceph Ansibleノードを再設定する前に、作成したバックアップを使用します。

前提条件

  • Red Hat Ceph Storage クラスターが実行中である。
  • ノードで Red Hat Enterprise Linux 7.9 を実行している。
  • ノードが Red Hat Ceph Storageバージョン 3.3z6 または 4.1 を実行している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のツールリポジトリーを有効にします。

    [root@dashboard ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  2. Ansible リポジトリーを有効にします。

    [root@dashboard ~]# subscription-manager repos --enable=ansible-2.9-for-rhel-8-x86_64-rpms
  3. ceph-ansible を設定して、ストレージクラスターを管理します。ダッシュボードがインストールされます。「Ansible を使用した Red Hat Ceph Storage のインストール」 (前提条件を含む) の手順に従ってください。
  4. 上記の手順の一部として ansible-playbook site.yml を実行すると、ダッシュボードの URL が出力されます。URL の場所とダッシュボードへのアクセスに関する詳細は、『ダッシュボード』「Ansible を使用したダッシュボードのインストール」を参照してください。

8.7. Ceph File System Metadata Server ノードとそのオペレーティングシステムを手動でアップグレードします。

Red Hat Ceph Storage クラスターノードおよび Red Hat Enterprise Linux オペレーティングシステム上の Ceph File System (CephFS) Metadata Server (MDS) ソフトウェアを、同時に新しいメジャーリリースに手動でアップグレードできます。

重要

ストレージクラスターをアップグレードする前に、アクティブな MDS ランクの数を減らし、ファイルシステムごとに 1 つにします。これにより、複数の MDS 間でバージョンの競合が発生しなくなります。また、アップグレードを行う前に、すべてのスタンバイノードをオフラインにしてください。

これは、MDSクラスターにはバージョニングやファイルシステムフラグが組み込まれていないためです。これらの機能がないと、複数の MDS が異なるバージョンの MDS ソフトウェアを使用して通信することになり、アサーションやその他の不具合が発生する可能性があります。

前提条件

  • 稼働中の Red Hat Ceph Storage Cluster
  • 各ノード で Red Hat Enterprise Linux 7.9 を使用している。
  • ノードは Red Hat Ceph Storage バージョン 3.3z6 または 4.1 を使用している。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。
  • ストレージクラスター内のすべてのノードへの root レベルのアクセス。
重要

基盤となる XFS ファイルシステムが ftype=1でフォーマットされているか、d_type をサポートしている。xfs_info /var コマンドを実行し、ftype1 になっていることを確認します。ftype の値が 1 でない場合は、新しいディスクをアタッチするか、ボリュームを作成します。この新しいデバイスの上に、新しいXFSファイルシステムを作成し、/var/lib/containers にマウントします。

Red Hat Enterprise Linux 8 以降、mkfs.xfs はデフォルトで ftype=1 を有効にします。

手順

  1. アクティブな MDS ランクを 1 にします。

    構文

    ceph fs set FILE_SYSTEM_NAME max_mds 1

    [root@mds ~]# ceph fs set fs1 max_mds 1

  2. クラスターがすべての MDS ランクを停止するのを待ちます。すべての MDS が停止したら、ランク 0 だけがアクティブになるはずです。残りはスタンバイモードにしておきます。ファイルシステムの状態を確認します。

    [root@mds ~]# ceph status
  3. systemctl を使用して、スタンバイしているすべての MDS をオフラインにします。

    [root@mds ~]# systemctl stop ceph-mds.target
  4. MDS が 1 つだけオンラインになっており、ファイルシステムのランクが 0 であることを確認します。

    [root@mds ~]# ceph status
  5. OS のバージョンに合わせて、ツールのリポジトリーを無効にします。

    1. RHEL 7 で Red Hat Ceph Storage 3 からアップグレードする場合は、Red Hat Ceph Storage 3 のツールリポジトリーを無効にします。

      [root@mds ~]# subscription-manager repos --disable=rhel-7-server-rhceph-3-tools-rpms
    2. Red Hat Ceph Storage 4 を使用している場合は、Red Hat Ceph Storage 4 のツールリポジトリーを無効にします。

      [root@mds ~]# subscription-manager repos --disable=rhel-7-server-rhceph-4-tools-rpms
  6. leapp ユーティリティーをインストールします。leapp の詳細については、「Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのアップグレード」を参照してください。
  7. leapp のアップグレード前のチェックを行います。詳細は、「コマンドラインからのアップグレード可能性の評価」を参照してください。
  8. etc/ssh/sshd_config を編集し、PermitRootLoginyes に設定します。
  9. OpenSSH SSH デーモンを再起動します。

    [root@mds ~]# systemctl restart sshd.service
  10. Linux カーネルから iSCSI モジュールを削除します。

    [root@mds ~]# modprobe -r iscsi
  11. アップグレードを行います。「RHEL 7 から RHEL 8 へのアップグレードの実行」を参照してください。
  12. MDS ノードを再起動します。
  13. Red Hat Ceph Storage 4 for Red Hat Enterprise Linux 8 のツールリポジトリーを有効にします。

    [root@mds ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  14. ceph-mds パッケージをインストールします。

    [root@mds ~]# dnf install ceph-mds -y
  15. 必要に応じて、このノードにコロケーションされる Ceph サービスのパッケージをインストールします。必要に応じて、追加の Ceph リポジトリーを有効にします。
  16. 必要に応じて、他の Ceph サービスに必要な leveldb パッケージをインストールします。

    [root@mds ~]# dnf install leveldb
  17. アップグレードされていないノードまたはそれらのファイルを復元しているノードから ceph-client-admin.keyring ファイルおよび ceph.conf ファイルを復元します。
  18. MDS サービスを開始します。

    [root@mds ~]# systemctl restart ceph-mds.target
  19. デーモンが有効であることを確認します。

    [root@mds ~]# ceph -s
  20. スタンバイ中のデーモンについても同じプロセスを実行します。
  21. スタンバイ中のすべての MDS の再起動が完了したら、クラスターの max_mds の値を以前の値に戻します。

    構文

    ceph fs set FILE_SYSTEM_NAME max_mds ORIGINAL_VALUE

    [root@mds ~]# ceph fs set fs1 max_mds 5

8.8. OSD ノードでのオペレーティングシステムのアップグレード失敗からの復旧

システム管理者は、手動で Ceph OSD ノードとそのオペレーティングシステムをアップグレード する手順に障害が発生した場合に、以下の手順に従って障害から回復することができます。この手順では、ノードに Red Hat Enterprise Linux 8.4 を新規インストールし、OSD が停止している間にダウンしていた書き込み以外に、データを大幅に埋め戻すことなく OSD を回復できます。

重要

OSD をサポートするメディアや、それぞれの wal.db データベースまたは block.db データベースには影響を及ぼさないようにしてください。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • アップグレードに失敗した OSD ノード。
  • Red Hat Enterprise Linux 8.3 のインストールソースにアクセスできる。

手順

  1. 障害のあるノードで Red Hat Enterprise Linux 8.4 の標準的なインストールを実行し、Red Hat Enterprise Linux リポジトリーを有効にします。

  2. Red Hat Enterprise Linux 8 用の Red Hat Ceph Storage 4 用のリポジトリーを有効にします。

    1. tools リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
    2. osd リポジトリーを有効にします。

      # subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  3. ceph-osd パッケージをインストールします。

    # dnf install ceph-osd
  4. アップグレードされていないノードから、またはそれらのファイルがすでに復元されているノードから、ceph.conf ファイルを /etc/ceph に復元します。
  5. OSD サービスを起動します。

    # systemctl start ceph-osd.target
  6. オブジェクトストアデバイスをアクティブにします。

    ceph-volume lvm activate --all
  7. OSD のリカバリーおよびクラスターのバックフィルが、復旧した OSD への書き込みを確認します。

    # ceph -w

    すべての PG が active+clean の状態になるまで、出力を監視します。

8.9. 関連情報

第9章 次のステップ

これは、最新のデータセンターの困難なストレージ要求を満たすために Red Hat Ceph Storage が実行できることの開始点にすぎません。以下は、さまざまなトピックの情報へのリンクになります。

  • パフォーマンスのベンチマークとパフォーマンスカウンターへのアクセスは、Red Hat Ceph Storage 4 の『管理ガイド』の「パフォーマンスのベンチマーク」の章を参照してください。
  • スナップショットの作成および管理。Red Hat Ceph Storage 4 の『ブロックデバイスガイド』の「スナップショット」の章を参照してください。
  • Red Hat Ceph Storage クラスターの拡張については Red Hat Ceph Storage 4 の『オペレーションガイド』の「ストレージクラスターサイズの管理」の章を参照してください。
  • Ceph Block Device のミラーリングは、Red Hat Ceph Storage 4 の『ブロックデバイスガイド』の「ブロックデバイスのミラーリング」の章を参照してください。
  • プロセス管理。Red Hat Ceph Storage 4 の『管理ガイド』の「プロセスの管理」の章を参照してください。
  • 調整可能なパラメーター。Red Hat Ceph Storage 4 の 「設定ガイド」を参照してください。
  • OpenStack のバックエンドストレージとして Ceph を使用する場合には、Red Hat OpenStack Platform の 『ストレージガイド』の「バックエンド」セクションを参照してください。
  • Ceph Dashboard を使用して、Red Hat Ceph Storage クラスターの正常性および容量を監視します。詳細は、『ダッシュボードガイド』を参照してください。

付録A トラブルシューティング

A.1. 予想したデバイスよりも少ないため、Ansible がインストールを停止します。

Ansible 自動化アプリケーションはインストールプロセスを停止し、以下のエラーを返します。

- name: fix partitions gpt header or labels of the osd disks (autodiscover disks)
  shell: "sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}' || sgdisk --zap-all --clear --mbrtogpt -- '/dev/{{ item.0.item.key }}'"
  with_together:
    - "{{ osd_partition_status_results.results }}"
    - "{{ ansible_devices }}"
  changed_when: false
  when:
    - ansible_devices is defined
    - item.0.item.value.removable == "0"
    - item.0.item.value.partitions|count == 0
    - item.0.rc != 0

エラー内容:

/usr/share/ceph-ansible/group_vars/osds.yml ファイルで osd_auto_discovery パラメーターが true に設定されている場合、Ansible は利用可能なすべてのデバイスを自動的に検出して設定します。このプロセス中、Ansible はすべての OSD が同じデバイスを使用することを想定します。デバイスは、Ansible が名前を検出するのと同じ順序で名前を取得します。いずれかの OSD でデバイスのいずれかが失敗すると、Ansible は障害が発生したデバイスの検出に失敗し、インストールプロセス全体を停止します。

状況例:

  1. 3 つの OSD ノード (host1host2host3) は、/dev/sdb ディスク、/dev/sdc ディスク、および dev/sdd ディスクを使用します。
  2. host2 では、/dev/sdc ディスクに障害が発生し、削除されます。
  3. 次回の再起動時に、Ansible は削除した /dev/sdc ディスクの検出に失敗し、host2/dev/sdb および /dev/sdc (以前は /dev/sdd) には 2 つのディスクのみが使用されることを想定します。
  4. Ansible はインストールプロセスを停止し、上記のエラーメッセージを返します。

この問題を修正するには、以下を実行します。

/etc/ansible/hosts ファイルで、障害が発生したディスクを持つ OSD ノードが使用するデバイスを指定します (上記の例の host2 )。

[osds]
host1
host2 devices="[ '/dev/sdb', '/dev/sdc' ]"
host3

詳細は5章Ansible を使用した Red Hat Ceph Storage のインストール をご覧ください。

付録B コマンドラインインターフェースを使用した Ceph ソフトウェアのインストール

ストレージ管理者は、Red Hat Ceph Storage ソフトウェアのさまざまなコンポーネントを手動でインストールすることを選択できます。

B.1. Ceph コマンドラインインターフェースのインストール

Ceph コマンドラインインターフェース (CLI) により、管理者は Ceph 管理コマンドを実行できます。CLI は ceph-common パッケージにより提供され、以下のユーティリティーが含まれます。

  • ceph
  • ceph-authtool
  • ceph-dencoder
  • rados

前提条件

  • 稼働中の Ceph ストレージクラスター (active + clean の状態が望ましい)。

手順

  1. クライアントノードで、Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    [root@gateway ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  2. クライアントノードで、ceph-common パッケージをインストールします。

    # yum install ceph-common
  3. 最初の監視ノードから、Ceph 設定ファイル (ここでは ceph.conf) と管理キーリングをクライアントノードにコピーします。

    構文

    # scp /etc/ceph/ceph.conf <user_name>@<client_host_name>:/etc/ceph/
    # scp /etc/ceph/ceph.client.admin.keyring <user_name>@<client_host_name:/etc/ceph/

    # scp /etc/ceph/ceph.conf root@node1:/etc/ceph/
    # scp /etc/ceph/ceph.client.admin.keyring root@node1:/etc/ceph/

    <client_host_name> を、クライアントノードのホスト名に置き換えてください。

B.2. Red Hat Ceph Storage の手動インストール

重要

Red Hat は、手動でデプロイしたクラスターのアップグレードをサポートしたり、テストしたりしません。したがって、Red Hat は、Ansible を使用して Red Hat Ceph Storage 4 で新規クラスターをデプロイすることを推奨します。詳細は5章Ansible を使用した Red Hat Ceph Storage のインストール をご覧ください。

Yum などのコマンドラインユーティリティーを使用して、手動でデプロイされたクラスターをアップグレードすることができますが、Red Hat ではこのアプローチのサポートまたはテストを行いません。

すべての Ceph クラスターにはモニターが少なくとも 1 つ、最低でも OSD がクラスターに保存されているオブジェクトのコピーとして必要になります。Red Hat は、実稼働環境に 3 台のモニターを使用し、少なくとも 3 つのオブジェクトストレージデバイス (OSD) を使用することを推奨します。

初期モニターのブートストラップは、Ceph ストレージクラスターをデプロイする最初のステップです。Ceph monitor デプロイメントは、以下のようなクラスター全体の重要な基準も設定します。

  • プールのレプリカ数
  • OSD ごとの配置グループ数
  • ハートビートの間隔
  • 認証要件

これらの値の多くはデフォルトで設定されるため、実稼働環境用のクラスターを設定する際に便利です。

コマンドラインインターフェースを使用して Ceph Storage クラスターをインストールするには、以下の手順を行います。

ブートストラップの監視

Monitor のブートストラップおよび Ceph Storage クラスターの拡張には、以下のデータが必要です。

一意識別子
ファイルシステム識別子 (fsid) はクラスターの一意の識別子です。fsid は、Ceph ストレージクラスターが Ceph ファイルシステムに主に使用する場合に使用されていました。Ceph はネイティブのインターフェース、ブロックデバイス、およびオブジェクトストレージゲートウェイのインターフェースもサポートするようになり、fsid は一部の誤検出になります。
監視名
クラスター内の各 Monitor インスタンスには一意の名前があります。一般的には、Ceph Monitor 名はノード名です。Red Hat では、ノードごとに Ceph Monitor を 1 つ推奨していますが、Ceph OSD デーモンを Ceph Monitor デーモンと同じ場所に配置しないことを推奨します。短いノード名を取得するには、hostname -s コマンドを使用します。
マップの監視

初期モニターのブートストラップでは、モニターマップを生成する必要があります。Monitor マップには以下が必要です。

  • ファイルシステム識別子 (fsid)
  • クラスター名、または ceph のデフォルトのクラスター名が使用されます。
  • 1 つ以上のホスト名とその IP アドレス
キーリングの監視
モニターは、秘密鍵を使用して相互に通信します。Monitor 秘密鍵でキーリングを生成し、初期 Monitor のブートストラップ時にこれを提供する必要があります。
管理者キーリング
ceph コマンドラインインターフェースユーティリティーを使用するには、client.admin ユーザーを作成し、そのキーリングを生成します。また、client.admin ユーザーを Monitor キーリングに追加する必要があります。

前述の要件は、Ceph 設定ファイルの作成を意味するものではありません。ただし、Red Hat では、Ceph 設定ファイルを作成し、少なくとも fsidmon initial members、および mon host の設定で設定することを推奨します。

実行時にすべての Monitor 設定を取得および設定できます。ただし、Ceph 設定ファイルには、デフォルト値を上書きする設定のみが含まれる場合があります。Ceph 設定ファイルに設定を追加すると、デフォルト設定が上書きされます。Ceph 設定ファイルでこれらの設定を維持すると、クラスターを簡単に維持できます。

初期モニターをブートストラップするには、以下の手順を実行します。

  1. Red Hat Ceph Storage 4 Monitor リポジトリーを有効にします。

    [root@monitor ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms
  2. 初期 Monitor ノードで、rootceph-mon パッケージをインストールします。

    # yum install ceph-mon
  3. root で、/etc/ceph/ ディレクトリーに Ceph 設定ファイルを作成します。

    # touch /etc/ceph/ceph.conf
  4. root でクラスターの一意の識別子を生成し、一意の ID を Ceph 設定ファイルの [global] セクションに追加します。

    # echo "[global]" > /etc/ceph/ceph.conf
    # echo "fsid = `uuidgen`" >> /etc/ceph/ceph.conf
  5. 現在の Ceph 設定ファイルを表示します。

    $ cat /etc/ceph/ceph.conf
    [global]
    fsid = a7f64266-0894-4f1e-a635-d0aeaca0e993
  6. root として、最初の Monitor を Ceph 設定ファイルに追加します。

    構文

    # echo "mon initial members = <monitor_host_name>[,<monitor_host_name>]" >> /etc/ceph/ceph.conf

    # echo "mon initial members = node1" >> /etc/ceph/ceph.conf

  7. root として、初期 Monitor の IP アドレスを Ceph 設定ファイルに追加します。

    構文

    # echo "mon host = <ip-address>[,<ip-address>]" >> /etc/ceph/ceph.conf

    # echo "mon host = 192.168.0.120" >> /etc/ceph/ceph.conf

    注記

    IPv6 アドレスを使用するには、ms bind ipv6 オプションを true に設定します。詳細は、Red Hat Ceph Storage 4 の『設定ガイド』の「バインド」セクションを参照してください。

  8. root として、クラスターのキーリングを作成し、Monitor シークレットキーを生成します。

    # ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
    creating /tmp/ceph.mon.keyring
  9. root で管理者キーリングを生成し、ceph.client.admin.keyring ユーザーを生成し、ユーザーをキーリングに追加します。

    構文

    # ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon '<capabilites>' --cap osd '<capabilites>' --cap mds '<capabilites>'

    # ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-uid=0 --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow'
    creating /etc/ceph/ceph.client.admin.keyring

  10. rootceph.client.admin.keyring キーを ceph.mon.keyring に追加します。

    # ceph-authtool /tmp/ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
    importing contents of /etc/ceph/ceph.client.admin.keyring into /tmp/ceph.mon.keyring
  11. Monitor マップを生成します。初期 Monitor のノード名、IP アドレス、および fsid を使用して指定し、/tmp/monmap として保存します。

    構文

    $ monmaptool --create --add <monitor_host_name> <ip-address> --fsid <uuid> /tmp/monmap

    $ monmaptool --create --add node1 192.168.0.120 --fsid a7f64266-0894-4f1e-a635-d0aeaca0e993 /tmp/monmap
    monmaptool: monmap file /tmp/monmap
    monmaptool: set fsid to a7f64266-0894-4f1e-a635-d0aeaca0e993
    monmaptool: writing epoch 0 to /tmp/monmap (1 monitors)

  12. 初期モニターノードで、root としてデフォルトのデータディレクトリーを作成します。

    構文

    # mkdir /var/lib/ceph/mon/ceph-<monitor_host_name>

    # mkdir /var/lib/ceph/mon/ceph-node1

  13. root として、最初の Monitor デーモンに Monitor マップとキーリングを設定します。

    構文

    # ceph-mon --mkfs -i <monitor_host_name> --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring

    # ceph-mon --mkfs -i node1 --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring
    ceph-mon: set fsid to a7f64266-0894-4f1e-a635-d0aeaca0e993
    ceph-mon: created monfs at /var/lib/ceph/mon/ceph-node1 for mon.node1

  14. 現在の Ceph 設定ファイルを表示します。

    # cat /etc/ceph/ceph.conf
    [global]
    fsid = a7f64266-0894-4f1e-a635-d0aeaca0e993
    mon_initial_members = node1
    mon_host = 192.168.0.120

    さまざまな Ceph 構成設定に関する詳細は、Red Hat Ceph Storage 4 の 『設定ガイド』 を参照してください。Ceph 設定ファイルの例では、最も一般的な構成設定の一部を示しています。

    [global]
    fsid = <cluster-id>
    mon initial members = <monitor_host_name>[, <monitor_host_name>]
    mon host = <ip-address>[, <ip-address>]
    public network = <network>[, <network>]
    cluster network = <network>[, <network>]
    auth cluster required = cephx
    auth service required = cephx
    auth client required = cephx
    osd journal size = <n>
    osd pool default size = <n>  # Write an object n times.
    osd pool default min size = <n> # Allow writing n copy in a degraded state.
    osd pool default pg num = <n>
    osd pool default pgp num = <n>
    osd crush chooseleaf type = <n>

  15. rootとして、done ファイルを作成します。

    構文

    # touch /var/lib/ceph/mon/ceph-<monitor_host_name>/done

    # touch /var/lib/ceph/mon/ceph-node1/done

  16. root として、新しく作成されたディレクトリーおよびファイルで所有者とグループのアクセス権を更新します。

    構文

    # chown -R <owner>:<group> <path_to_directory>

    # chown -R ceph:ceph /var/lib/ceph/mon
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown ceph:ceph /etc/ceph/ceph.client.admin.keyring
    # chown ceph:ceph /etc/ceph/ceph.conf
    # chown ceph:ceph /etc/ceph/rbdmap

    注記

    Ceph Monitor ノードが OpenStack Controller ノードと同じ場所にある場合、Glance および Cinder キーリングファイルは、それぞれ glance および cinder によって所有されている必要があります。以下は例になります。

    # ls -l /etc/ceph/
    ...
    -rw-------.  1 glance glance      64 <date> ceph.client.glance.keyring
    -rw-------.  1 cinder cinder      64 <date> ceph.client.cinder.keyring
    ...
  17. root として、初期モニターノードで ceph-mon プロセスを開始して有効にします。

    構文

    # systemctl enable ceph-mon.target
    # systemctl enable ceph-mon@<monitor_host_name>
    # systemctl start ceph-mon@<monitor_host_name>

    # systemctl enable ceph-mon.target
    # systemctl enable ceph-mon@node1
    # systemctl start ceph-mon@node1

  18. root として、monitor デーモンが実行していることを確認します。

    構文

    # systemctl status ceph-mon@<monitor_host_name>

    # systemctl status ceph-mon@node1
    ● ceph-mon@node1.service - Ceph cluster monitor daemon
       Loaded: loaded (/usr/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: disabled)
       Active: active (running) since Wed 2018-06-27 11:31:30 PDT; 5min ago
     Main PID: 1017 (ceph-mon)
       CGroup: /system.slice/system-ceph\x2dmon.slice/ceph-mon@node1.service
               └─1017 /usr/bin/ceph-mon -f --cluster ceph --id node1 --setuser ceph --setgroup ceph
    
    Jun 27 11:31:30 node1 systemd[1]: Started Ceph cluster monitor daemon.
    Jun 27 11:31:30 node1 systemd[1]: Starting Ceph cluster monitor daemon...

Red Hat Ceph Storage Monitor をストレージクラスターに追加するには、Red Hat Ceph Storage 4 の『管理ガイド』の「モニターの追加」セクションを参照してください。

OSD ブート制約

モニターを最初に実行したら、オブジェクトストレージデバイス (OSD) の追加を開始できます。オブジェクトのコピー数を処理するのに十分な OSD があるまで、クラスターは active + clean 状態に到達できません。

オブジェクトのデフォルトのコピー数は 3 です。少なくとも 3 つの OSD ノードが必要です。ただし、オブジェクトのコピーを 2 つだけ使用する場合には、OSD ノードを 2 つだけ追加してから、Ceph 設定ファイルの osd pool default size および osd pool default min size 設定を更新します。

詳細は、Red Hat Ceph Storage 4 の『設定』「OSD 設定参照」セクションを参照してください。

初期モニターのブートストラップ後に、クラスターにはデフォルトの CRUSH マップがあります。ただし、CRUSH マップには Ceph ノードにマッピングされた Ceph OSD デーモンがありません。

OSD をクラスターに追加し、デフォルトの CRUSH マップを更新するには、各 OSD ノードで以下のコマンドを実行します。

  1. Red Hat Ceph Storage 4 OSD リポジトリーを有効にします。

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms
  2. root で Ceph OSD ノードに ceph-osd パッケージをインストールします。

    # yum install ceph-osd
  3. Ceph 設定ファイルと管理キーリングファイルを初期 Monitor ノードから OSD ノードにコピーします。

    構文

    # scp <user_name>@<monitor_host_name>:<path_on_remote_system> <path_to_local_file>

    # scp root@node1:/etc/ceph/ceph.conf /etc/ceph
    # scp root@node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph

  4. OSD 用の Universally Unique Identifier (UUID) を生成します。

    $ uuidgen
    b367c360-b364-4b1d-8fc6-09408a9cda7a
  5. root として、OSD インスタンスを作成します。

    構文

    # ceph osd create <uuid> [<osd_id>]

    # ceph osd create b367c360-b364-4b1d-8fc6-09408a9cda7a
    0

    注記

    このコマンドは、後続のステップに必要な OSD 番号識別子を出力します。

  6. root として、新規 OSD のデフォルトディレクトリーを作成します。

    構文

    # mkdir /var/lib/ceph/osd/ceph-<osd_id>

    # mkdir /var/lib/ceph/osd/ceph-0

  7. root として、OSD として使用するドライブを準備し、作成したディレクトリーにマウントします。Ceph データおよびジャーナル用にパーティションを作成します。ジャーナルとデータパーティションは同じディスクに配置できます。以下の例では、15 GB のディスクを使用しています。

    構文

    # parted <path_to_disk> mklabel gpt
    # parted <path_to_disk> mkpart primary 1 10000
    # mkfs -t <fstype> <path_to_partition>
    # mount -o noatime <path_to_partition> /var/lib/ceph/osd/ceph-<osd_id>
    # echo "<path_to_partition>  /var/lib/ceph/osd/ceph-<osd_id>   xfs defaults,noatime 1 2" >> /etc/fstab

    # parted /dev/sdb mklabel gpt
    # parted /dev/sdb mkpart primary 1 10000
    # parted /dev/sdb mkpart primary 10001 15000
    # mkfs -t xfs /dev/sdb1
    # mount -o noatime /dev/sdb1 /var/lib/ceph/osd/ceph-0
    # echo "/dev/sdb1 /var/lib/ceph/osd/ceph-0  xfs defaults,noatime 1 2" >> /etc/fstab

  8. root として、OSD データディレクトリーを初期化します。

    構文

    # ceph-osd -i <osd_id> --mkfs --mkkey --osd-uuid <uuid>

    # ceph-osd -i 0 --mkfs --mkkey --osd-uuid b367c360-b364-4b1d-8fc6-09408a9cda7a
    ... auth: error reading file: /var/lib/ceph/osd/ceph-0/keyring: can't open /var/lib/ceph/osd/ceph-0/keyring: (2) No such file or directory
    ... created new key in keyring /var/lib/ceph/osd/ceph-0/keyring

  9. root として、OSD 認証キーを登録します。

    構文

    # ceph auth add osd.<osd_id> osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-<osd_id>/keyring

    # ceph auth add osd.0 osd 'allow *' mon 'allow profile osd' -i /var/lib/ceph/osd/ceph-0/keyring
    added key for osd.0

  10. root として、OSD ノードを CRUSH マップに追加します。

    構文

    # ceph osd crush add-bucket <host_name> host

    # ceph osd crush add-bucket node2 host

  11. root で OSD ノードを default の CRUSH ツリーに配置します。

    構文

    # ceph osd crush move <host_name> root=default

    # ceph osd crush move node2 root=default

  12. root として、OSD ディスクを CRUSH マップに追加します。

    構文

    # ceph osd crush add osd.<osd_id> <weight> [<bucket_type>=<bucket-name> ...]

    # ceph osd crush add osd.0 1.0 host=node2
    add item id 0 name 'osd.0' weight 1 at location {host=node2} to crush map

    注記

    CRUSH マップを逆コンパイルし、OSD をデバイス一覧に追加することもできます。OSD ノードをバケットとして追加してから、デバイスを OSD ノードの項目として追加し、OSD に重みを割り当て、CRUSH マップを再コンパイルし、CRUSH マップを設定します。詳細は、Red Hat Ceph Storage 4 の『ストレージ戦略ガイド』のセクション「CRUSH マップの編集」を参照してください。

  13. root として、新しく作成されたディレクトリーおよびファイルで所有者とグループのアクセス権を更新します。

    構文

    # chown -R <owner>:<group> <path_to_directory>

    # chown -R ceph:ceph /var/lib/ceph/osd
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown -R ceph:ceph /etc/ceph

  14. OSD ノードは Ceph Storage クラスターの設定にあります。ただし、OSD デーモンは down および in です。新しい OSD は、データの受信開始前に up である必要があります。root として、OSD プロセスを有効にして開始します。

    構文

    # systemctl enable ceph-osd.target
    # systemctl enable ceph-osd@<osd_id>
    # systemctl start ceph-osd@<osd_id>

    # systemctl enable ceph-osd.target
    # systemctl enable ceph-osd@0
    # systemctl start ceph-osd@0

    OSD デーモンを起動すると、これが up および in になります。

モニターと一部の OSD が稼働しています。以下のコマンドを実行して、配置グループピアを監視できます。

$ ceph -w

OSD ツリーを表示するには、以下のコマンドを実行します。

$ ceph osd tree

ID  WEIGHT    TYPE NAME        UP/DOWN  REWEIGHT  PRIMARY-AFFINITY
-1       2    root default
-2       2        host node2
 0       1            osd.0         up         1                 1
-3       1        host node3
 1       1            osd.1         up         1                 1

OSD をストレージクラスターに追加してストレージ容量を拡張するには、Red Hat Ceph Storage 4 『管理ガイド』「OSD の追加」セクションを参照してください。

B.3. Ceph Manager の手動インストール

通常、Ansible 自動化ユーティリティーは、Red Hat Ceph Storage クラスターをデプロイする際に Ceph Manager デーモン (ceph-mgr) をインストールします。ただし、Ansible を使用して Red Hat Ceph Storage を管理しない場合は、Ceph Manager を手動でインストールすることができます。Red Hat は、Ceph Manager デーモンと Ceph Monitor デーモンを同じノードに配置することを推奨します。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスター
  • root または sudo アクセス
  • rhceph-4-mon-for-rhel-8-x86_64-rpms リポジトリーが有効になっている
  • ファイアウォールを使用している場合は、パブリックネットワーク上でポート 6800-7300 を開く

手順

ceph-mgr がデプロイされるノードで、root ユーザーまたは sudo ユーティリティーで以下のコマンドを使用します。

  1. ceph-mgr パッケージをインストールします。

    [root@node1 ~]# yum install ceph-mgr
  2. /var/lib/ceph/mgr/ceph-hostname/ ディレクトリーを作成します。

    mkdir /var/lib/ceph/mgr/ceph-hostname

    hostname を、ceph-mgr デーモンがデプロイされるノードのホスト名に置き換えます。以下に例を示します。

    [root@node1 ~]# mkdir /var/lib/ceph/mgr/ceph-node1
  3. 新しく作成されたディレクトリーで、ceph-mgr デーモンの認証キーを作成します。

    [root@node1 ~]# ceph auth get-or-create mgr.`hostname -s` mon 'allow profile mgr' osd 'allow *' mds 'allow *' -o /var/lib/ceph/mgr/ceph-node1/keyring
  4. /var/lib/ceph/mgr/ ディレクトリーの所有者とグループを ceph:ceph に変更します。

    [root@node1 ~]# chown -R ceph:ceph /var/lib/ceph/mgr
  5. ceph-mgr ターゲットを有効にします。

    [root@node1 ~]# systemctl enable ceph-mgr.target
  6. ceph-mgr インスタンスを有効にして開始します。

    systemctl enable ceph-mgr@hostname
    systemctl start ceph-mgr@hostname

    hostname を、ceph-mgr をデプロイするノードのホスト名に置き換えます。以下に例を示します。

    [root@node1 ~]# systemctl enable ceph-mgr@node1
    [root@node1 ~]# systemctl start ceph-mgr@node1
  7. ceph-mgr デーモンが正常に起動していることを確認します。

    ceph -s

    出力には、services: セクションの下に以下の行と同様の行が含まれます。

        mgr: node1(active)
  8. 追加の ceph-mgr デーモンをインストールして、現在のアクティブなデーモンに障害が発生した場合にアクティブになるスタンバイデーモンとして機能します。

B.4. Ceph ブロックデバイスの手動インストール

以下の手順では、シンプロビジョニングされ、サイズが変更可能な Ceph ブロックデバイスをインストールおよびマウントする方法を説明します。

重要

Ceph ブロックデバイスは、Ceph Monitor ノードと OSD ノードとは別のノードにデプロイする必要があります。同じノードでカーネルクライアントとカーネルサーバーデーモンを実行すると、カーネルのデッドロックが発生する可能性があります。

前提条件

手順

  1. OSD ノード (osd 'allow rwx') 上のファイルへの完全なパーミッションを持つ client.rbd という名前の Ceph Block Device ユーザーを作成し、結果をキーリングファイルに出力します。

    ceph auth get-or-create client.rbd mon 'profile rbd' osd 'profile rbd pool=<pool_name>' \
    -o /etc/ceph/rbd.keyring

    <pool_name> を、client.rbd によるアクセスを許可するプールの名前 (例: rbd) に置き換えます。

    # ceph auth get-or-create \
    client.rbd mon 'allow r' osd 'allow rwx pool=rbd' \
    -o /etc/ceph/rbd.keyring

    ユーザーの作成に関する詳細は、Red Hat Ceph Storage 4 『管理ガイド』「ユーザー管理」セクションを参照してください。

  2. ブロックデバイスイメージを作成します。

    rbd create <image_name> --size <image_size> --pool <pool_name> \
    --name client.rbd --keyring /etc/ceph/rbd.keyring

    <image_name><image_size>、および <pool_name> を指定します。以下に例を示します。

    $ rbd create image1 --size 4G --pool rbd \
    --name client.rbd --keyring /etc/ceph/rbd.keyring
    警告

    デフォルトの Ceph 設定には、以下の Ceph ブロックデバイス機能が含まれます。

    • layering
    • exclusive-lock
    • object-map
    • deep-flatten
    • fast-diff

    カーネル RBD (krbd) クライアントを使用する場合は、ブロックデバイスイメージをマッピングできない可能性があります。

    この問題を回避するには、サポートされていない機能を無効にします。これを行うには、以下のいずれかのオプションを使用します。

    • サポートされていない機能を動的に無効にします。

      rbd feature disable <image_name> <feature_name>

      以下は例になります。

      # rbd feature disable image1 object-map deep-flatten fast-diff
    • rbd create コマンドで --image-feature layering オプションを使用して、新たに作成されたブロックデバイスイメージで 階層化 のみを有効にします。
    • Ceph 設定ファイルで機能のデフォルトを無効にします。

      rbd_default_features = 1

    これは既知の問題です。詳細は、Red Hat Ceph Storage 4 の『リリースノート』「既知の問題」の章を参照してください。

    これらの機能はすべて、ユーザー空間の RBD クライアントを使用してブロックデバイスイメージにアクセスするユーザーに機能します。

  3. 新規に作成されたイメージをブロックデバイスにマッピングします。

    rbd map <image_name> --pool <pool_name>\
    --name client.rbd --keyring /etc/ceph/rbd.keyring

    以下は例になります。

    # rbd map image1 --pool rbd --name client.rbd \
    --keyring /etc/ceph/rbd.keyring
  4. ファイルシステムを作成してブロックデバイスを使用します。

    mkfs.ext4 /dev/rbd/<pool_name>/<image_name>

    以下のように、プール名とイメージ名を指定します。

    # mkfs.ext4 /dev/rbd/rbd/image1

    このアクションには少し時間がかかる場合があります。

  5. 新しく作成されたファイルシステムをマウントします。

    mkdir <mount_directory>
    mount /dev/rbd/<pool_name>/<image_name> <mount_directory>

    以下は例になります。

    # mkdir /mnt/ceph-block-device
    # mount /dev/rbd/rbd/image1 /mnt/ceph-block-device

関連情報

B.5. Ceph Object Gateway の手動インストール

Ceph オブジェクトゲートウェイは RADOS ゲートウェイとしても知られている librados API 上に構築されたオブジェクトストレージインターフェースで、RESTful ゲートウェイを Ceph ストレージクラスターに提供します。

前提条件

手順

  1. Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    [root@gateway ~]# subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-debug-rpms
  2. Object Gateway ノードで、ceph-radosgw パッケージをインストールします。

    # yum install ceph-radosgw
  3. 初期モニターノードで、以下の手順を実施します。

    1. 以下のように Ceph 設定ファイルを更新します。

      [client.rgw.<obj_gw_hostname>]
      host = <obj_gw_hostname>
      rgw frontends = "civetweb port=80"
      rgw dns name = <obj_gw_hostname>.example.com

      ここで、<obj_gw_hostname> はゲートウェイノードの短縮ホスト名です。短縮ホスト名を表示するには、hostname -s コマンドを使用します。

    2. 更新された設定ファイルを新しい Object Gateway ノードおよび Ceph Storage クラスターのその他のノードにコピーします。

      構文

      # scp /etc/ceph/ceph.conf <user_name>@<target_host_name>:/etc/ceph

      # scp /etc/ceph/ceph.conf root@node1:/etc/ceph/

    3. ceph.client.admin.keyring ファイルを新しい Object Gateway ノードにコピーします。

      構文

      # scp /etc/ceph/ceph.client.admin.keyring <user_name>@<target_host_name>:/etc/ceph/

      # scp /etc/ceph/ceph.client.admin.keyring root@node1:/etc/ceph/

  4. Object Gateway ノードで、データディレクトリーを作成します。

    # mkdir -p /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`
  5. Object Gateway ノードで、ユーザーとキーリングを追加して、オブジェクトゲートウェイをブートストラップします。

    構文

    # ceph auth get-or-create client.rgw.`hostname -s` osd 'allow rwx' mon 'allow rw' -o /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/keyring

    # ceph auth get-or-create client.rgw.`hostname -s` osd 'allow rwx' mon 'allow rw' -o /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/keyring

    重要

    ゲートウェイキーの機能を提供する場合は、読み取り機能を指定する必要があります。ただし、Monitor 書き込み機能を提供することはオプションです。指定した場合、Ceph Object Gateway はプールを自動的に作成できます。

    このような場合は、プール内の配置グループの数に適切な数を指定してください。そうでない場合には、ゲートウェイはデフォルトの番号を使用しますが、これはニーズに適しているとは 限りません。詳細は、「Ceph Placement Groups (PGs) per Pool Calculator」を参照してください。

  6. Object Gateway ノードで、done ファイルを作成します。

    # touch /var/lib/ceph/radosgw/ceph-rgw.`hostname -s`/done
  7. Object Gateway ノードで、所有者およびグループのパーミッションを変更します。

    # chown -R ceph:ceph /var/lib/ceph/radosgw
    # chown -R ceph:ceph /var/log/ceph
    # chown -R ceph:ceph /var/run/ceph
    # chown -R ceph:ceph /etc/ceph
  8. Object Gateway ノードで、TCP ポート 8080 を開きます。

    # firewall-cmd --zone=public --add-port=8080/tcp
    # firewall-cmd --zone=public --add-port=8080/tcp --permanent
  9. Object Gateway ノードで、ceph-radosgw プロセスを開始して有効にします。

    構文

    # systemctl enable ceph-radosgw.target
    # systemctl enable ceph-radosgw@rgw.<rgw_hostname>
    # systemctl start ceph-radosgw@rgw.<rgw_hostname>

    # systemctl enable ceph-radosgw.target
    # systemctl enable ceph-radosgw@rgw.node1
    # systemctl start ceph-radosgw@rgw.node1

インストールが完了すると、書き込み機能が Monitor に設定されると、Ceph Object Gateway はプールを自動的に作成します。プールの手動作成に関する詳細は、『ストラテジー戦略ガイド』の「プール」の章を参照してください。

関連情報

付録C Ansible インベントリー場所の設定

オプションとして、ceph-ansible ステージング環境および実稼働環境用のインベントリーの場所ファイルを設定することができます。

前提条件

  • Ansible 管理ノード。
  • Ansible 管理ノードへのルートレベルのアクセス。
  • ceph-ansible パッケージがノードにインストールされている。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [ansible@admin ~]# cd /usr/share/ceph-ansible
  2. ステージングおよび実稼働環境用のサブディレクトリーを作成します。

    [ansible@admin ceph-ansible]$ mkdir -p inventory/staging inventory/production
  3. ansible.cfg ファイルを編集し、以下の行を追加します。

    [defaults]
    inventory = ./inventory/staging # Assign a default inventory directory
  4. 各環境用にインベントリーの「hosts」ファイルを作成します。

    [ansible@admin ceph-ansible]$ touch inventory/staging/hosts
    [ansible@admin ceph-ansible]$ touch inventory/production/hosts
    1. hosts ファイルを開いて編集し、[mons] セクションの下に Ceph Monitor ノードを追加します。

      [mons]
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_1
      MONITOR_NODE_NAME_1

      [mons]
      mon-stage-node1
      mon-stage-node2
      mon-stage-node3

      注記

      デフォルトでは、Playbook はステージング環境で実行されます。実稼働環境で Playbook を実行するには、以下を実行します。

      [ansible@admin ceph-ansible]$ ansible-playbook -i inventory/production playbook.yml

関連情報

付録D Ceph のデフォルト設定の上書き

Ansible 設定ファイルに特に指定しない限り、Ceph はデフォルト設定を使用します。

Ansible は Ceph 設定ファイルを管理するため、/usr/share/ceph-ansible/group_vars/all.yml ファイルを編集して Ceph の設定を変更します。ceph_conf_overrides の設定を使用して、デフォルトの Ceph 設定を上書きします。

Ansible は、Ceph 設定ファイル ([global][mon][osd][mds][rgw] など) と同じセクションをサポートします。特定の Ceph Object Gateway インスタンスなどの特定のインスタンスをオーバーライドすることもできます。以下は例になります。

###################
# CONFIG OVERRIDE #
###################

ceph_conf_overrides:
   client.rgw.server601.rgw1:
      rgw_enable_ops_log: true
      log_file: /var/log/ceph/ceph-rgw-rgw1.log
注記

変数は、ceph_conf_overrides 設定のキーとして使用しないでください。特定の設定値をオーバーライドするセクションに、ホストの絶対ラベルを渡す必要があります。

注記

Ansible には、Ceph 設定ファイルの特定セクションを参照する際に中かっこが含まれません。セクション名および設定名はコロンで終了します。

重要

CONFIG OVERRIDE セクションの cluster_network パラメーターを使用してクラスターネットワークを設定しないでください。競合する 2 つのクラスターネットワークが Ceph 設定ファイルに設定されている可能性があるためです。

クラスターネットワークを設定するには、CEPH CONFIGURATION セクションで cluster_network パラメーターを使用します。詳細は、『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage クラスターのインストール」を参照してください。

付録E 既存の Ceph クラスターの Ansible へのインポート

Ansible が Ansible なしでデプロイされたクラスターを使用するように設定することができます。たとえば、Red Hat Ceph Storage 1.3 クラスターを手動でバージョン 2 にアップグレードした場合は、以下の手順により Ansible を使用するように設定してください。

  1. バージョン 1.3 からバージョン 2 に手動でアップグレードした後、管理ノードに Ansible をインストールおよび設定します。
  2. Ansible 管理ノードに、クラスター内の全 Ceph ノードにパスワードレスの ssh アクセスがあることを確認します。詳細は、「Ansible のパスワードなし SSH の有効化」 を参照してください。
  3. root で、/etc/ansible/ ディレクトリーに Ansible の group_vars ディレクトリーへのシンボリックリンクを作成します。

    # ln -s /usr/share/ceph-ansible/group_vars /etc/ansible/group_vars
  4. rootall.yml.sample ファイルから all.yml ファイルを作成し、編集用に開きます。

    # cd /etc/ansible/group_vars
    # cp all.yml.sample all.yml
    # vim all.yml
  5. group_vars/all.ymlgenerate_fsid 設定を false に設定します。
  6. ceph fsid を実行して、現在のクラスター fsid を取得します。
  7. 取得した fsidgroup_vars/all.yml に設定します。
  8. Ceph ホストが含まれるように、/etc/ansible/hosts の Ansible インベントリーを変更します。[mons] セクションの下にモニター、[osds] セクションの下に OSD、および[rgws] セクションのゲートウェイを追加して、それらのロールをAnsible に特定します。
  9. ceph_conf_overrides セクションが、all.yml ファイルの [global] セクション、[osd] セクション、[mon] セクション、および [client] セクションに使用される元の ceph.conf オプションで更新されていることを確認します。

    osd ジャーナルpublic_networkcluster_network などのオプションはすでに all.yml に含まれているため、ceph_conf_overrides には追加しないでください。all.yml に含まれず、元の ceph.conf にあるオプションのみを ceph_conf_overrides に追加する必要があります。

  10. /usr/share/ceph-ansible/ ディレクトリーから Playbook を実行します。

    # cd /usr/share/ceph-ansible/
    # ansible-playbook infrastructure-playbooks/take-over-existing-cluster.yml -u <username> -i hosts

付録F Ansible によってデプロイされたストレージクラスターのパージ

Ceph ストレージクラスターを使用しない場合には、Playbook purge-docker-cluster.yml を使用してクラスターを削除します。ストレージクラスターのパージは、インストールプロセスが失敗し、最初からやり直したい場合にも役立ちます。

警告

Ceph ストレージクラスターをパージすると、OSD のデータはすべて永続的に失われます。

前提条件

  • Ansible 管理ノードへのルートレベルのアクセス。
  • ansible ユーザーアカウントへのアクセス。
  • ベアメタル デプロイメントの場合:

    • /usr/share/ceph-ansible/group-vars/osds.yml ファイルの osd_auto_discovery オプションが true に設定されている場合、Ansible はストレージクラスターのパージに失敗します。したがって、osd_auto_discovery をコメントアウトし、osds.yml ファイルで OSD デバイスを宣言します。
  • /var/log/ansible/ansible.log ファイルが ansible ユーザーアカウントで書き込み可能であることを確認してください。

手順

  1. /usr/share/ceph-ansible ディレクトリーに移動します。

    [root@admin ~]# cd /usr/share/ceph-ansible
  2. ansible ユーザーとして、purge Playbook を実行します。

    1. ベアメタル デプロイメントの場合は、purge-cluster.yml Playbook を使用して Ceph ストレージクラスターをパージします。

      [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-cluster.yml
    2. コンテナー デプロイメントの場合:

      1. Playbook purge-docker-cluster.yml を使用して Ceph ストレージクラスターをパージします。

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml
        注記

        この Playbook により、パッケージ、コンテナー、設定ファイル、および Ceph Ansible Playbook により作成されたすべてのデータが削除されます。

      2. デフォルトの (/etc/ansible/hosts )以外のインベントリーファイルを指定するには、-i パラメーターを使用します。

        構文

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i INVENTORY_FILE

        置き換え

        INVENTORY_FILE は、インベントリーファイルへのパスに置き換えます。

        [ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/purge-docker-cluster.yml -i ~/ansible/hosts

      3. Ceph コンテナーイメージの削除を省略するには、--skip-tags=”remove_img” オプションを使用します。

        [ansible@admin ceph-ansible]$ ansible-playbook --skip-tags="remove_img" infrastructure-playbooks/purge-docker-cluster.yml
      4. インストール時にインストールしたパッケージの削除を省略するには、--skip-tags=”with_pkg” オプションを使用します。

        [ansible@admin ceph-ansible]$ ansible-playbook --skip-tags="with_pkg" infrastructure-playbooks/purge-docker-cluster.yml

関連情報

付録G ansible-vault を使用した Ansible パスワード変数の暗号化

パスワードの格納に使用する Ansible 変数を暗号化するには ansible-vault を使用し、プレーンテキストとして読み込めないようにします。たとえば、group_vars/all.yml で、ceph_docker_registry_username および ceph_docker_registry_password 変数をサービスアカウントの認証情報またはカスタマーポータルの認証情報に設定できます。サービスアカウントは共有されるように作られていますが、カスタマーポータルのパスワードのセキュリティーを確保する必要があります。ceph_docker_registry_password の暗号化に加えて dashboard_admin_passwordgrafana_admin_password も暗号化することをお勧めします。

前提条件

  • 稼働中の Red Hat Ceph Storage クラスターがある。
  • Ansible 管理ノードへのアクセス

手順

  1. Ansible 管理ノードにログインします。
  2. /usr/share/ceph-ansible/ ディレクトリーに移動します。

    [admin@admin ~]$ cd /usr/share/ceph-ansible/
  3. ansible-vault を実行して、新しい vault パスワードを作成します。

    [admin@admin ceph-ansible]$ ansible-vault encrypt_string --stdin-name 'ceph_docker_registry_password_vault'
    New Vault password:

  4. vault パスワードを再入力して確定します。

    [admin@admin ceph-ansible]$ ansible-vault encrypt_string --stdin-name 'ceph_docker_registry_password_vault'
    New Vault password:
    Confirm New Vault password:

  5. 暗号化するパスワードを入力し、CTRL+D を 2 回入力してエントリーを完了します。

    構文

    ansible-vault encrypt_string --stdin-name 'ceph_docker_registry_password_vault'
    New Vault password:
    Confirm New Vault password:
    Reading plaintext input from stdin. (ctrl-d to end input)
    PASSWORD

    PASSWORD はパスワードに置き換えます。

    [admin@admin ceph-ansible]$ ansible-vault encrypt_string --stdin-name 'ceph_docker_registry_password_vault'
    New Vault password:
    Confirm New Vault password:
    Reading plaintext input from stdin. (ctrl-d to end input)
    SecurePassword

    パスワードの入力後に Enter は押さないようにしてください。暗号化文字列のパスワードの一部として、改行が追加されてしまいます。

  6. ceph_docker_registry_password_vault: !vault | で開始し、数字の行 2-3 行で終了する出力をメモし、次の手順で使用します。

    [admin@admin ceph-ansible]$ ansible-vault encrypt_string --stdin-name 'ceph_docker_registry_password_vault'
    New Vault password:
    Confirm New Vault password:
    Reading plaintext input from stdin. (ctrl-d to end input)
    SecurePasswordceph_docker_registry_password_vault: !vault |
              $ANSIBLE_VAULT;1.1;AES256
              38383639646166656130326666633262643836343930373836376331326437353032376165306234
              3161386334616632653530383231316631636462363761660a373338373334663434363865356633
              66383963323033303662333765383938353630623433346565363534636434643634336430643438
              6134306662646365370a343135316633303830653565633736303466636261326361333766613462
              39353365343137323163343937636464663534383234326531666139376561663532
    Encryption successful

    スペースや改行なしで、パスワード直後に開始される出力が必要となります。

  7. group_vars/all.yml を編集し、上記からの出力をファイルに貼り付けます。

    ceph_docker_registry_password_vault: !vault |
              $ANSIBLE_VAULT;1.1;AES256
              38383639646166656130326666633262643836343930373836376331326437353032376165306234
              3161386334616632653530383231316631636462363761660a373338373334663434363865356633
              66383963323033303662333765383938353630623433346565363534636434643634336430643438
              6134306662646365370a343135316633303830653565633736303466636261326361333766613462
              39353365343137323163343937636464663534383234326531666139376561663532

  8. 以下を使用して、暗号化されたパスワードの下に行を追加します。

    ceph_docker_registry_password: "{{ ceph_docker_registry_password_vault }}"

    注記

    上記のように 2 つの変数を使用する必要があります。これは、Ansible のバグ が原因で、vault 値を直接 Ansible 変数に割り当てる時に、文字列のタイプが破損するためです。

  9. ansible-playbook の実行時に vault パスワードを要求するように Ansible を設定します。

    1. /usr/share/ceph-ansible/ansible.cfg を開いて編集し、[defaults] セクションに以下の行を追加します。

      ask_vault_pass = True
    2. 必要に応じて、ansible-playbook を実行するたびに --ask-vault-pass を渡すことができます。

      [admin@admin ceph-ansible]$ ansible-playbook -v site.yml --ask-vault-pass

  10. site.yml または site-container.yml を再実行して、暗号化されたパスワードに関連するエラーがないことを確認します。

    [admin@admin ceph-ansible]$ ansible-playbook -v site.yml -i hosts --ask-vault-pass

    -i hosts オプションは、/etc/ansible/hosts のデフォルトの Ansible インベントリーの場所を使用していない場合にのみ必要です。

関連情報

付録H Ansible の全般的な設定

これは最も一般的な設定可能な Ansible パラメーターです。ベアメタルまたはコンテナーのデプロイメント方法に応じて、2 つのパラメーターセットを使用できます。

注記

これは、利用可能なすべての Ansible パラメーターの完全なリストではありません。

ベアメタル および コンテナー の設定

monitor_interface

Ceph Monitor ノードがリッスンするインターフェース。

ユーザー定義
必須
はい
注記
1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
monitor_address

Ceph Monitor ノードもリッスンするアドレス。

ユーザー定義
必須
はい
注記
1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
monitor_address_block

Ceph パブリックネットワークのサブネット。

ユーザー定義
必須
はい
注記
ノードの IP アドレスが不明ではあるが、サブネットが既知である場合に使用します。1 つ以上の monitor_* パラメーターに値を割り当てる必要があります。
ip_version
ipv6
必須
IPv6 アドレス指定を使用している場合は必須です。
public_network

IPv6 を使用する場合には、Ceph パブリックネットワークの IP アドレスとネットマスク、または対応する IPv6 アドレス。

ユーザー定義
必須
はい
注記
詳細は、Red Hat Ceph Storage のネットワーク設定の確認を参照してください。
cluster_network

IPv6 を使用する場合には、Ceph クラスターネットワークの IP アドレスとネットマスク、または対応する IPv6 アドレス。

ユーザー定義
必須
いいえ
注記
詳細は、Red Hat Ceph Storage のネットワーク設定の確認を参照してください。
configure_firewall

Ansible は適切なファイアウォールルールの設定を試みます。

true または false
必須
いいえ

ベアメタル 固有の設定

ceph_origin
repository または distro または local
必須
はい
注記
repository 値は、新しいリポジトリーで Ceph をインストールすることを意味します。distro の値は、個別のリポジトリーファイルが追加されず、Linux ディストリビューションに含まれる Ceph のバージョンをすべて取得することを意味します。local の値は、Ceph バイナリーがローカルマシンからコピーされることを意味します。
ceph_repository_type
cdn または iso
必須
はい
ceph_rhcs_version
4
必須
はい
ceph_rhcs_iso_path

ISO イメージの完全パス。

ユーザー定義
必須
はい (ceph_repository_typeiso 設定されている場合)

コンテナー 固有の設定

ceph_docker_image
ローカルの Docker レジストリーを使用している場合には rhceph/rhceph-4-rhel8 または cephimageinlocalreg
必須
必要
ceph_docker_image_tag
ローカルレジストリーの設定中に提供された rhceph/rhceph-4-rhel8 または customtaglatest バージョン。
必要性
はい
containerized_deployment
true
必須
はい
ceph_docker_registry
ローカルの Docker レジストリーを使用している場合は、registry.redhat.io、または LOCAL_FQDN_NODE_NAME
必須
はい

付録I OSD Ansible の設定

これらは、設定可能な OSD Ansible パラメーターの最も一般的なものです。

devices

Ceph のデータが保存されるデバイスの一覧。

ユーザー定義
必須
デバイスの一覧を指定する場合は、はい。
注記
osd_auto_discovery 設定を使用する場合は使用できません。devices オプションを使用する場合は、ceph-volume lvm batch モードにより、最適化 OSD 設定が作成されます。
dmcrypt

OSD を暗号化するには。

true
必須
いいえ
注記
デフォルト値は false です。
lvm_volumes

FileStore または BlueStore ディクショナリーの一覧。

ユーザー定義
必須
はい (ストレージデバイスが devices パラメーターで定義されていない場合)。
注記
各ディクショナリーには、data キー、journal キー、および data_vg キーが含まれている必要があります。論理ボリュームまたはボリュームグループはすべて、完全パスではなく、名前にする必要があります。data キーおよび journal キーは論理ボリューム (LV) またはパーティションにすることができますが、複数の data 論理ボリュームに 1 つのジャーナルを使用しないでください。data_vg キーは、data 論理ボリューム含むボリュームグループである必要があります。必要に応じて、journal_vg キーを使用して、ジャーナル LV を含むボリュームグループを指定できます (該当する場合)。
osds_per_device

デバイスごとに作成する OSD 数。

ユーザー定義
必須
いいえ
注記
デフォルト値は 1 です。
osd_objectstore

OSD の Ceph オブジェクトストアタイプ。

BlueStore または filestore
必須
いいえ
注記
デフォルト値は bluestore です。アップグレードに必要です。