実稼働環境向け Ceph Object Gateway ガイド

Red Hat Ceph Storage 4

実稼働環境の場合は、Ceph Storage クラスターのプランニング、設計、およびデプロイを行います。

概要

本ガイドでは、クラスターのプランニング、ハードウェアの開発、ストレージストラテジーの開発、ゲートウェイおよびロードバランサーの設定、および Ceph Object Gateway の使用について説明します。
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

第1章 はじめに

『実稼働環境向け Ceph Object Gateway』 ガイドへようこそ。本ガイドでは、実稼働環境向けの Ceph Storage クラスターおよび Ceph Object Gateway クラスターを構築するトピックについて説明します。

1.1. Audience

このガイドは、実稼働環境に Ceph Object Gateway 環境をデプロイする場合に使用します。ここでは、実稼働用 Ceph Storage クラスターと Ceph Object Gateway クラスターのプランニング、設計、およびデプロイを行うための一連のトピックと、適切な Ceph ドキュメントへのリンクが提供されます。

1.2. 前提条件

本ガイドでは、読者が Ceph Storage Cluster および Ceph Object Gateway の基本的な理解があることを前提とします。Ceph 体験のないリーダーは、小規模な Ceph テスト環境を設定することを検討するか、または Ceph Sandbox 環境を使用して Ceph の概念に精通してから、本ガイドに進んでください。

本ガイドでは、単一の Ceph Storage クラスターと、同じゾーンに複数の Ceph Object Gateway インスタンスで構成される単一のサイトクラスターを想定しています。本書では、セカンダリーゾーングループおよびゾーンに必要な名前変更で、各ゾーンおよびゾーンの手順を繰り返すことで、単一サイトのクラスターがマルチゾーンおよびマルチサイトクラスターに拡張されることを前提としています。

1.3. 対象範囲

本書では、実稼働環境の Ceph Storage クラスターおよび Ceph Object Gateway を設定する際のトピックについて説明します。

注記

本ガイドは、ハードウェア、インストール、管理、および Ceph Object Gateway のガイドを補完することを目的としています。本ガイドでは、他のガイドに置き換わるものではありません。

第2章 クラスターの計画

Ceph Object Gateway で使用するクラスターのプランニングには、重要な考慮事項が複数あります。

これらの要因は、ハードウェアを検討 する際に大きな影響を及ぼします。ハードウェアを選択する前に、これらの要因を慎重に検討してください。

2.1. ユースケースの特定

Ceph Storage は、さまざまなタイプのストレージユースケースを提供できます。Ceph Object Storage の場合、典型的なユースケースは以下のとおりです。

  • スループットの最適化: スループットが最適なクラスターは、迅速なデータへのアクセスを確保するために検索します。ホストバスアダプター(HBA)、高速連続読み取り/書き込み特性と高ネットワーク帯域幅を持つストレージメディアは、グラフィック、音声ストリーミング、ストリーミングなどのアプリケーションの機能を提供します。スループット最適化クラスターは、書き込みのパフォーマンスが考慮されるかどうかも考慮します。ジャーナリングに SSD を使用するスループット最適化クラスターは、CCTV ストリームを保存するアプリケーションにとって重要となる可能性があります。スループット最適化クラスターは、ストリーミング 4K ビデオなどの集約型アプリケーション向けの Host Bus Adapter(HBA)コントローラーのスループットの特性を考慮する必要があります。HBA ベースのハードウェアコントローラーは、オンボードコントローラーに対するパフォーマンスが大幅に改善します。
  • 容量の最適化: 容量を最適化したクラスターは、テラバイトあたりのコストを最小限に抑えられるようにします。容量最適化のクラスターは、最も高価なストレージメディアを使用し、多くの場合、多くの場合、従来の従来の偽装(古い電子メールレコードなど)をアーカイブするなど、別の SSD ジャーナルを追加したのを避けることがよくあります。
  • IOPS の最適化: IOPS 最適化クラスターは、読み取り/書き込みの集約型のワークロードに対して高パフォーマンスを提供することを重視しています。IOPS が最適なワークロードは Ceph Object Gateway では一般的ではありませんが、SSD、Flash メモリー、または NVMe CRUSH 階層でサポートできます。

クラスターの価格とパフォーマンスに大きく影響するため、ハードウェアを考慮する にストレージのユースケースを慎重に検討してください。たとえば、ユースケースが容量最適化されており、ハードウェアがスループット最適化のユースケースに適している場合には、ハードウェアは必要以上のコストが高くなります。反対に、ユースケースが throughput-optimized で、ハードウェアが容量最適化のユースケースに適している場合には、クラスターはパフォーマンスが低下する可能性があります。

また、Ceph Object Gateway はストレージポリシーをサポートするため、前述の すべて のシナリオに対して CRUSH 階層を作成して、API でサポートされているストレージポリシーで呼び出すことができます。詳細は、「データの配置ストラテジーの作成」を参照してください。

2.2. データ持続性メソッドの選択

クラスター設計は、データの持続性ストラテジーを考慮する必要があります。Ceph Storage は複製またはイレイジャーコーディングを使用してデータの持続性を確保します。

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

『Red Hat Ceph Storage 4 ストレージストラテジーガイド』の「イレイジャーコーディング」セクションでは、イレイジャーコーディングがデータをデータチャンクおよびコーディングチャンクとして保存する方法を説明しています。データチャンクが失われた場合、イレイジャーコーディングは、残りのデータチャンクを使用して失われたデータチャンクを復旧し、チャンクをコーディングできます。イレイジャーコーディングはレプリケーションよりも大幅に複雑になります。たとえば、8 データチャンクでイレイジャーコーディングを使用し、3 つのコーディングチャンクを使用すると、データのコピー 3 つと同じ冗長性を提供します。ただし、このようなエンコーディングスキームは、3x のレプリケーションとともに保存されている初期データの約 1.5x を使用します。

注記

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

2.3. マルチサイトのデプロイメントを検討

クラスターを設計するもう 1 つの重要な点として、クラスターが 1 つのデータセンターサイトにあるか、または複数のデータセンターサイトにまたがるかどうかを判別することです。マルチサイトクラスターは、地理的に分散されたフェイルオーバーや障害回復の利点(長期的な電力停止、ハウンクライクス、ハリフンス、その他の障害など)を活用します。さらに、アクティブ/アクティブ設定のマルチサイトクラスターは、コンテンツ配信ネットワークを用いて、最も近いクラスターにクライアントアプリケーションを指示できます。データをできるだけ近くに置くことは、ストリーミング 4k ビデオなどのスループット集約型のワークロードで大幅に重要です。

マルチサイトクラスターの詳細は、『Red Hat Ceph Storage 4 Ceph Object Gateway 設定および管理ガイド』の「マルチサイト」の章を参照してください。

注記

Red Hat は、realm、zone group および zone name BEFORE プールを特定することを推奨しています。プール名によっては、ゾーン名(規則別)で事前修正する必要があります。

第3章 ハードウェアの検討

実稼働環境では、Ceph Storage クラスターおよび Ceph Object Gateway クラスターを構築する上では、ハードウェアを考慮する必要があります。高レベルの考慮事項には、以下が含まれます。

重要

クラスターのコンピューティングハードウェアとネットワークハードウェアを特定して購入する 前に、これらの要素を検討してください。

3.1. ストレージのサイズ設定の検討

クラスター設計における最も重要な要因の 1 つは、ストレージ要件(サイズ調整)を決定することです。Ceph Storage は、ペタバイト以上にスケーリングするように設計されています。Ceph Storage クラスターの一般的なサイズの例を以下に示します。

  • 小規模: 250 テラバイト
  • 中規模: 1 ペタバイト
  • 大規模: 2 ペタバイト以上。

サイジングには、現在のニーズと近い将来的なニーズが含まれているはずです。ゲートウェイクライアントがクラスターに新しいデータを追加するレートについて考えてみましょう。ユースケースによって異なることがあります。たとえば、CCTV ビデオ、4k ビデオ、またはマスカライズングすると、はるかに大量のデータを追加してから、ファイナルマースデータなどのストレージ集中型情報が少なくなる場合があります。さらに、レプリケーションやイレイジャーコーディングなどの データ永続性 の方法が、必要なストレージメディアに大きく影響することに注意してください。

サイズ設定の詳細は、『Red Hat Ceph Storage ハードウェア選択ガイド』およびそれに関連する OSD ハードウェアの選択に関するリンクを参照してください。

3.2. ストレージの密度の検討

クラスター設計のもう 1 つの重要な要素には、ストレージの密度があります。通常、クラスターは、レプリケート、バックフィル、復旧時に適切なパフォーマンスを確保するために、少なくとも 10 のノードにデータを保存する必要があります。ノードに障害が発生した場合に、クラスターに 10 つ以上のノードがある状態で、データの 10% のみがストレッシベリングノードに移動する必要があります。ノードの数が大幅に低くなる場合、データの割合を最も高くなる場合は、割引ノードに移動する必要があります。さらに、クラスターがデータを書き込むことができるように、ノードの障害に対応するために full_ratio および near_full_ratio を設定する必要があります。このため、ストレージの密度を考慮する必要があります。ストレージの密度が高いことは、必ずしも適切なアイデアではありません。

ストレージの密度の高いノード数を増やす別の要因は、イレイジャーコーディングです。イレイジャーコーディングを使用してオブジェクトを作成し、ノード を最小 CRUSH 障害ドメインとして使用する場合、クラスターにはデータおよびコーディングチャンクと同じ数のノードが必要になります。たとえば、k=8, m=3 を使用するクラスターでは、各データまたはコーディングチャンクが別のノードに保存されるように、最低でも 11 個のノードが必要です。

また、ホットスワップも重要な考慮点になります。最新のサーバーの多くは、ドライブホットスワップに対応します。ただし、一部のハードウェア設定では、ドライブを置き換えるために複数のドライブを削除する必要があります。Red Hat では、障害の発生したディスクをスワップアウトする際に、必要以上の OSD をスケールダウンできるため、このような設定を回避することを推奨します。

3.3. ネットワークハードウェアの検討

Ceph Storage の主な利点は、容量、IOPS、スループットを個別にスケーリングできることです。クラウドストレージソリューションの重要な要素として、クラスターはネットワークレイテンシーや他の要素のために IOPS が不足するか、またはクラスターの容量が不足している前に帯域幅の制約によりスループットが不足するためです。つまり、ネットワークハードウェア設定は、価格/パフォーマンスのターゲットを満たすためにユースケースをサポートする必要があります。ネットワークパフォーマンスは、SSD、フラッシュ、NVMe、およびその他の高パフォーマンスのストレージ方法の使用を考慮すると、大幅に重要になります。

Ceph Storage に関するもう 1 つの重要な点として、フロントまたはパブリックネットワーク(クライアント用)およびデータの監視、データのレプリケーション、復旧用にバックサイドまたはクラスターネットワークをサポートしている点です。つまり、バックエンドネットワークまたはクラスターネットワークには、常に フロントエンドまたはパブリックネットワークよりも多くのネットワークリソースが必要になります。データプールがデータの持続性のためにレプリケーションまたはイレイジャーコーディングを使用するかどうかに応じて、バックサイドまたはクラスターネットワークのネットワーク要件が適切に定める必要があります。

最後に、Ceph のインストールおよびテスト前にネットワークスループットを確認します。通常、Ceph のパフォーマンス関連の問題の多くは、ネットワークの問題から始まります。kinked または bent Cat-6 ケーブルなどの単純なネットワークの問題により、帯域幅が低下します。フロントエンドネットワークには、最低 10Gbe を使用します。大規模なクラスターの場合、バックエンドまたはクラスターネットワークに 40Gbe を使用することを検討してください。または、LACP モード 4 を使用してボンディングネットワークに対応します。また、特にバックエンドまたはクラスターネットワーク上で、ジャンボフレーム(MTU 9000)を使用します。

3.4. 無停電電源装置の検討

Ceph 書き込みは atomic-​all または nothing であるため、Ceph OSD ノードの中断不可能な電源は(UPS)であることが必須ではありません。ただし、Red Hat では、Ceph Monitor ノードの UPS を使用することを推奨しています。監視には、同期書き込みレイテンシーの影響を受ける leveldb を使用します。電源の停止により破損が発生する可能性があり、テクニカルサポートがクラスターの状態を復元します。

ストレージコントローラーがライトバックキャッシュを使用する場合は、Ceph OSD には UPS を使用する利点が得られます。このシナリオでは、UPS は、コントローラーがライトバックキャッシュをタイムでフラッシュしない場合に、電源の停止時にファイルシステムの破損を防止するのに役立ちます。

3.5. ユースケース用のハードウェアの選択

Ceph Storage の主な利点は、多くのユースケースに対応するように設定できます。通常、Red Hat は、特定のユースケースで OSD ホストを同じ設定することを推奨します。Ceph Storage クラスターの 3 つの主要なユースケースは以下のとおりです。

  • 最適化した IOPS
  • 最適化されたスループット
  • 容量の最適化

これらのユースケースは、通常、他の要素間で異なるドライブ、HBA コントローラー、およびネットワーク要件があるため、一連の同じホストを設定し、1 つのノード設定でこれらすべてのユースケースを可能にすることは可能ですが、必ずしも推奨される訳ではありません。

同じホストを使用して複数の CRUSH 階層を容易化するには、CRUSH マップの実際のホスト名ではなく、論理的な使用が必要になります。さらに、Ansible などのデプロイメントツールは、すべての OSD をデフォルトの [osds] グループにデプロイするのではなく、各ユースケースのためにグループを検討する必要があります。

注記

通常、IOPS、高スループット、高容量など、単一のユースケースに対応するホストの設定および管理が容易になります。

3.6. インデックスのメディアの選択

Ceph Object Gateway-- で使用できるように OSD ハードウェアを選択する場合、ユースケース-- に関係なく、OSD ノードに OSD ノードが必要になります。これは、バケットに多数のオブジェクトが含まれる場合、特に重要になります。

ホストには、SSD または NVMe ドライブが少なくとも 1 つ必要です。Red Hat のラボテストでは、NVMe ドライブは、同じドライブ上の OSD ジャーナルとインデックスプールの両方をサポートするのに十分なパフォーマンスを示していますが、NVMe ドライブの異なるパーティションにはそれぞれ対応します。

注記

Red Hat は、インデックスプールの HDD デバイスに対応していません。サポート対象構成の情報については、「Red Hat Ceph Storage: Supported configurations」の記事を参照してください。

インデックスエントリーは約 200 バイトのデータで、leveldb にオブジェクトマップ (omap) として保管されます。これは、大量のデータですが、Ceph Object Gateway を使用すると、1 つのバケットに数十万のオブジェクトや数十万のオブジェクトが発生する可能性があります。インデックスプールを高パフォーマンスのストレージメディアの CRUSH 階層にマッピングすることで、バケットに非常に多くのオブジェクトが含まれる場合、レイテンシーが減少します。

重要

実稼働クラスターでは、OSD ジャーナルとインデックスプールを保存するのに、標準の OSD ノードに SSD または NVMe ドライブが 1 つ以上含まれます。同じ物理ドライブを使用する場合は、別のパーティションまたは論理ボリュームを使用します。

3.7. ノードのモニター用にメディアの選択

Ceph モニターは、同期書き込みレイテンシーの影響を受ける leveldb を使用します。Red Hat は、SSD を使用してモニターデータを保存することを強く推奨します。選択した SSD に連続した書き込みおよびスループットの特徴が十分にあることを確認してください。

第4章 クラスターの設定

実稼働クラスターの初期設定は、概念実証用のシステムの設定と同じです。唯一のマテリビューの違いは、最初のデプロイメントが実稼働レードのハードウェアを使用する点です。まず、『Red Hat Ceph Storage 4 インストールガイド』の「Red Hat Ceph Storage のインストール要件」の章に従い、各ノードで適切な手順を実施します。以下のセクションでは、実稼働クラスターに関連する追加のガイダンスを提供します。

4.1. ホストの命名

ホストの命名時に、ユースケースとパフォーマンスプロファイルの使用を検討してください。たとえば、ホストがクライアントデータを保存する場合は、ハードウェア設定とパフォーマンスプロファイルに従って命名することを検討してください。以下に例を示します。

  • data-ssd-1, data-ssd-2
  • hot-storage-1hot-storage-2
  • sata-1sata-2
  • sas-ssd-1sas-ssd-2

命名規則により、クラスターの管理が容易になり、ハードウェアの問題のトラブルシューティングを行うことができます。

たとえば、ホストに複数のユースケース用のハードウェアが含まれる場合、ホストにはデータ用の SSD や、ジャーナル用に SSD ドライブ、およびコールドストレージ用に共存するジャーナルを持つ SATA ドライブが含まれています。これは、ホストの一般名を選択します。以下に例を示します。

  • osd-node-1 osd-node-2

汎用ホスト名は、必要に応じて CRUSH 階層で論理ホスト名を使用する場合に拡張できます。以下に例を示します。

  • osd-node-1-ssd osd-node-1-sata osd-node-1-sas-ssd osd-node-1-bucket-index
  • osd-node-2-ssd osd-node-2-sata osd-node-2-sas-ssd osd-node-2-bucket-index

詳細は、「CRUSH マップの論理ホスト名」を参照してください。

4.2. カーネルのチューニング

実稼働クラスターは、オペレーティングシステム(特に制限およびメモリー割り当て)を調整することができます。クラスター内のすべてのノードに調整が設定されていることを確認します。その他のガイダンスについては、「Red Hat サポート」を参照してください。

4.2.1. OSD 用空きメモリーの確保

OSD メモリー割り当て要求時にメモリー関連のエラーが不十分な状態を防ぐためには、ceph-ansible ノードの group_vars/all.ymlos_tuning_params オプションを設定します。このオプションは、予約する物理メモリーの容量を指定します。推奨される設定は、システム RAM の容量に基づいています。以下に例を示します。

  • 64GB RAM の場合、1GB を予約します。

    vm.min_free_kbytes = 1048576
  • 128GB の RAM の場合、2GB を確保します。

    vm.min_free_kbytes = 2097152
  • 256GB RAM の場合、3GB を予約します。

    vm.min_free_kbytes = 3145728

4.2.2. ファイル記述子の拡張

Ceph Object Gateway は、ファイル記述子が不足するとハングする可能性があります。Ceph Object Gateway ノードで /etc/security/limits.conf を変更して、Ceph Object Gateway のファイル記述子を増やします。以下に例を示します。

ceph       soft    nofile     unlimited

4.2.3. 大規模なクラスターでの ulimit の調整

大規模なクラスターで Ceph 管理者コマンドを実行するシステム管理者(例: 1024 OSD またはそれ以上) では、/etc/security/limits.d/50-ceph.conf ファイルを以下の内容で作成します。

<username>       soft    nproc     unlimited

<username> を、Ceph 管理者コマンドを実行する root 以外のアカウントの名前に置き換えます。

注記

root ユーザーの ulimit は、Red Hat Enterprise Linux ではデフォルトで「無制限」に設定されています。

4.3. Ansible グループの設定

この手順は、Ansible を使用した Ceph のデプロイにだけ重点を置いています。ceph-ansible パッケージはすでにデフォルトの osds グループで設定されています。クラスターにユースケースおよびストレージポリシーが 1 つしかない場合は、『Red Hat Ceph Storage インストールガイド』の「Red Hat Ceph Storage クラスターのインストール」セクションに記載の手順に進んでください。クラスターが複数のユースケースおよびストレージポリシーをサポートする場合は、それぞれにグループを作成します。各ユースケースは、/usr/share/ceph-ansible/group_vars/osd.sample をグループ名のファイルにコピーする必要があります。たとえば、ストレージクラスターに IOPS が最適化され、スループットが最適化され、容量が最適化されているユースケースの場合は、各ユースケースのグループを表す個別のファイルを作成します。

cd /usr/share/ceph-ansible/group_vars/
cp osds.sample osds-iops
cp osds.sample osds-throughput
cp osds.sample osds-capacity

次に、ユースケースに合わせて各ファイルを設定します。

グループ変数ファイルが設定されたら、site.yml ファイルを編集して、各新しいグループが含まれるようにします。以下に例を示します。

- hosts: osds-iops
  gather_facts: false
  become: True
  roles:
  - ceph-osd

- hosts: osds-throughput
  gather_facts: false
  become: True
  roles:
  - ceph-osd

- hosts: osds-capacity
  gather_facts: false
  become: True
  roles:
  - ceph-osd

最後に、/etc/ansible/hosts ファイルに、グループに関連付けられた OSD ノードを対応するグループ名の下に配置します。以下に例を示します。

[osds-iops]
<ceph-host-name> devices="[ '<device_1>', '<device_2>' ]"

[osds-throughput]
<ceph-host-name> devices="[ '<device_1>', '<device_2>' ]"

[osds-capacity]
<ceph-host-name> devices="[ '<device_1>', '<device_2>' ]"

4.4. Ceph の設定

通常、管理者は /usr/share/ceph-ansible/group_vars ディレクトリーにある Ceph Ansible 設定ファイルを使用して、初回のデプロイ前に Red Hat Ceph Storage クラスターを設定する必要があります。

『Red Hat Ceph Storage インストールガイド』の「Red Hat Ceph Storage クラスターのインストール」セクションを参照してください。

  • モニターの場合、sample.mons.yml ファイルから mons.yml ファイルを作成します。
  • OSD の場合は、sample.osds.yml ファイルから osds.yml ファイルを作成します。
  • クラスターは、sample.all.yml ファイルから all.yml ファイルを作成します。

『インストールガイド』の説明に従って設定を変更します。

また、「Ceph Object Gateway のインストール」を参照して、sample.rgws.yml から rgws.yml ファイルを作成します。

注記
前述のファイルの設定は、ceph_conf_overrides の設定よりも優先される場合があります。

mons.yml ファイル、osds.yml ファイル、または rgws.yml ファイルに、対応する値を使用しない設定を設定するには、all.yml ファイルの ceph_conf_overrides セクションに構成設定を追加します。以下に例を示します。

ceph_conf_overrides:
   global:
      osd_pool_default_pg_num: <number>

設定ファイルセクションの詳細は、「設定ファイル構造」を参照してください。

重要

Ansible 設定ファイルで Ceph 構成設定を指定すると共に、Ceph 設定ファイルのレンダリング方法には、構文的な違いがあります。

RHCS バージョン 3.1 以前では、Ceph 設定ファイルは ini スタイルの概念を使用します。Ceph 設定ファイルの [global] 等のセクションは global: として指定し、独自の行にインデントする必要があります。特定のデーモンインスタンスの設定セクションを指定することもできます。たとえば、all.yml ファイルの ceph_conf_overrides セクションに osd.1: を追加すると、Ceph 設定ファイルの [osd.1] としてレンダリングされ、このセクションの下にある設定は osd.1 のみに適用されます。

Ceph 構成設定は、スペースではなくハイフン (-) またはアンダースコア (_) が含まれ、等号 (=) ではなく、コロン (:) で終了するはずです。

Ceph クラスターをデプロイする前に、以下の設定を考慮してください。Ceph の構成設定を行う場合、Red Hat は ceph-ansible 設定ファイルに値を設定することを推奨します。これにより、Ceph 設定ファイルが自動生成されます。

4.4.1. ジャーナルサイズの設定

Ceph クラスターのジャーナルサイズを設定します。Ansible などの設定ツールにはデフォルト値が含まれる場合があります。通常、ジャーナルサイズには同期間隔のプロダクトと、ディスクおよびネットワークスループットの低速、および 2 つの(2)による製品が乗算されます。

詳細は、Red Hat Ceph Storage 4 設定ガイドの「ジャーナル設定」セクションを参照してください。

4.4.2. バックフィルおよびリカバリー設定の調整

I/O は、バックフィルとリカバリー操作の両方による悪影響を受け、パフォーマンスの低下と異常なエンドユーザーです。クラスターの拡張または復旧中の I/O 要求に対応しやすくするには、以下のオプションおよび値を Ceph 設定ファイルに設定します。

[osd]
osd_max_backfills = 1
osd_recovery_max_active = 1
osd_recovery_op_priority = 1

4.4.3. クラスターマップサイズの調整

Red Hat Ceph Storage バージョン 2 以前の場合、クラスターに数千の OSD がある場合、クラスターマップをダウンロードし、そのファイルサイズを確認します。デフォルトでは、ceph-osd デーモンは以前の osdmaps を 500 個キャッシュします。重複排除により、マップはデーモンごとに大量のメモリーを消費する可能性があります。Ceph 設定ファイルでキャッシュサイズを調整すると、メモリー消費が大幅に削減される可能性があります。以下に例を示します。

[global]
osd_map_message_max=10

[osd]
osd_map_cache_size=20
osd_map_max_advance=10
osd_map_share_max_epochs=10
osd_pg_epoch_persisted_max_stale=10

Red Hat Ceph Storage バージョン 3 以降では、ceph-manager デーモンが PG クエリーを処理するため、クラスターマップはパフォーマンスに影響しません。

4.4.4. スクラビングの調整

デフォルトでは、Ceph は軽量でスクラビングを日割り、深いスクラビングを毎週実行します。軽量のスクラビングは、オブジェクトサイズとチェックサムをチェックして、PG が同じオブジェクトデータを保存されるようにします。時間が経つと、ディスクセクターが、オブジェクトサイズやチェックサムが不適切になることがあります。ディープスクラビングは、そのレプリカと共にオブジェクトのコンテンツをチェックして、実際のコンテンツが同じであることを確認します。そのため、fsck の方法で、ディープスクラブがデータの整合性を保ちますが、この手順ではクラスターに I/O のペナルティーを課すことになります。わずかなスクラビングは I/O に影響を及ぼす可能性があります。

デフォルト設定では、Ceph OSD がピーク時の操作時間や負荷が大きい期間など、不動の回数でスクラビングを開始できるようになります。エンドユーザーは、エンドユーザー操作とスクラビング操作の競合が発生した場合に、レイテンシーやパフォーマンスが低下する可能性があります。

エンドユーザーがパフォーマンスが低下するのを防ぐために、Ceph はスクラビングの設定を複数提供します。これにより、負荷が低い、またはオフピーク時の期間にスクラビングを制限できます。詳細は、『Red Hat Ceph Storage Configuration Guide』の「Scrubbing the OSD 」セクションを参照してください

クラスターで日中に高負荷が高くなり、毎夜にかかる負荷が小さい場合には、スクラビングを夜間に制限することを検討します。以下に例を示します。

[osd]
osd_scrub_begin_hour = 23   #23:01H, or 10:01PM.
osd_scrub_end_hour = 6      #06:01H or 6:01AM.

時間制約がスクラブスケジュールを判断する効果的な方法ではない場合は、osd_scrub_load_threshold の使用を検討してください。デフォルト値は 0.5 ですが、負荷が低い場合に変更できます。以下に例を示します。

[osd]
osd_scrub_load_threshold = 0.25

4.4.5. objecter_inflight_ops を増やします。

RHCS 3.0 以前のリリースでは、スケーラビリティーを強化するために、objecter_inflight_ops をバージョン 3.1 以降のリリースのデフォルトサイズに増やすことを検討してください。

objecter_inflight_ops = 24576

4.4.6. rgw_thread_pool_size を増やします。

RHCS 3.0 以前のリリースでは、スケーラビリティーを強化するために、rgw_thread_pool_size のバージョンをバージョン 3.1 以降のリリースのデフォルトサイズに増やすことを検討してください。以下に例を示します。

rgw_thread_pool_size = 512

4.4.7. ガベージコレクション設定の調整

Ceph Object Gateway は、新規および上書きされたオブジェクトにストレージをすぐに割り当てます。また、マルチパートアップロードの一部としては、一部のストレージも使用します。

Ceph Object Gateway は、バケットインデックスからオブジェクトを削除した後に、削除されたオブジェクトに使用されるストレージ領域を削除します。同様に、Ceph Object Gateway は、マルチパートのアップロードが完了した後にマルチパートアップロードに関連付けられたデータを削除するか、またはアップロードが非アクティブになるか、設定可能な期間にわたって完了できませんでした。Red Hat Ceph Storage クラスターから削除されたオブジェクトデータをパージするプロセスは、ガベージコレクション(GC)として知られています。

ガベージコレクションを待っているオブジェクトを表示するには、以下のコマンドを実行します。

radosgw-admin gc list

ガベージコレクションは、ストレージ管理者が Ceph Object Gateway をどのように設定するかに応じて、継続的に実行する、または負荷が低いときに実行するバックグラウンドアクティビティーです。デフォルトでは、Ceph Object Gateway はガベージコレクションの操作を継続的に実行します。ガべージコレクションの操作は、特にオブジェクトの削除操作に関して、Ceph Object Gateway の通常の機能であるため、ガベージコレクションの対象となるオブジェクトはその時間の大半になります。

一部のワークロードでは、ガべージコレクションアクティビティーのレートを一時的に、または永続的に除外できます。これは特に、短期間保存されてから削除されます。これらのタイプのワークロードでは、ストレージ管理者は、以下の設定パラメーターを使用して、他の操作に対してガベージコレクションの操作の優先度を増やすことができます。

  • rgw_gc_obj_min_wait 設定オプションは、削除されたオブジェクトのデータをパージする前に待機する最小時間 (秒単位) です。デフォルト値は 2 時間(7200 秒)です。クライアントがオブジェクトを読み取る可能性があるため、オブジェクトはすぐにパージされません。負荷の高いワークロードの場合、この設定では大量のストレージを消費することや、パージする削除されたオブジェクトが多数あることがあります。Red Hat では、この値を 30 分または 1800 秒に設定しないことを推奨します。
  • rgw_gc_processor_period 設定オプションは、ガベージコレクションサイクルのランタイムです。つまり、ガベージコレクションスレッドの連続実行までの時間です。ガベージコレクションがこの期間よりも長い場合には、Ceph Object Gateway はガベージコレクションサイクルを再度実行するまで待機しません。
  • rgw_gc_max_concurrent_io 設定オプションは、削除されたデータをパージする際にゲートウェイガベッジコレクションスレッドが使用する同時 IO 操作の最大数を指定します。負荷が大きいワークロードを削除するには、この設定を同時 IO 操作の数を増やすことを検討してください。
  • rgw_gc_max_trim_chunk 設定オプションは、単一の操作でガベージコレクターログから削除する鍵の最大数を指定します。削除の大きい操作では、各ガベージコレクションの操作時に、より多くのオブジェクトがパージされるようにキーの最大数を増やすことを検討してください。

Red Hat Ceph Storage 4.1 以降、ガベージコレクションログからインデックスオブジェクトの OMAP をオフロードすると、ストレージクラスターのガべージコレクションアクティビティーのパフォーマンスの影響が低くなります。以下のようにガべージコレクションキューを調整するために、Ceph Object Gateway に新たな設定パラメーターが追加されました。

  • The rgw_gc_max_deferred_entries_size 設定オプションは、ガベージコレクションのキューに遅延エントリーの最大サイズを設定します。
  • rgw_gc_max_queue_size 設定オプションは、ガベッジコレクションに使用する最大キューサイズを設定します。この値は、osd_max_object_size から rgw_gc_max_deferred_entries_size を引いた値から 1KB を引いた値よりも大きくすることはできません。
  • rgw_gc_max_deferred 設定オプションは、ガベージコレクションキューに保存された遅延エントリーの最大数を設定します。
注記

これらのガベージコレクションの設定パラメーターは、Red Hat Ceph Storage 4 以降向けです。

注記

テストでは、50% の削除操作と 50% の書き込み操作など、均等にバランスの取れた削除/書き込みワークロードを使用すると、ストレージクラスターは 11 時間で完全にいっぱいになります。これは、Ceph Object Gateway ガべージコレクションが削除操作とペース残しないためです。この場合、クラスターのステータスは HEALTH_ERR 状態に切り替わります。並行ガベージコレクションの調整可能な設定により、ストレージクラスターセットのテストが一杯になり、多くのワークロードで役立ちます。典型的な実際のストレージクラスターワークロードでは、ガベージコレクションによりストレージクラスターがいっぱいになる可能性はありません。

管理者は、デプロイメント後にランタイム時に Ceph 構成設定を変更することもできます。詳細は、「実行時に特定構成の設定」を参照してください。

第5章 Ceph のデプロイ

前提条件および初期チューニングが完了したら、Ceph クラスターをデプロイすることを検討してください。実稼働クラスターをデプロイする場合、Red Hat では、初期モニタークラスターと、active + clean の状態に達するのに十分な OSD ノードを設定することを推奨します。詳細は、『Red Hat Ceph Storage 4 インストールガイド』の「Red Hat Ceph Storage クラスターのインストール」セクションを参照してください。

次に、管理ノードに Ceph CLI クライアントをインストールします。詳細は、『Red Hat Ceph Storage 4 インストールガイド』のの「Ceph コマンドラインインターフェースのインストール」セクションを参照してください。

初期クラスターの稼働後に、以下のセクションの設定を Ceph 設定ファイルに追加することを検討してください。

第6章 クラスターの拡張

初期クラスターが実行し、active+clean の状態になったら、追加の OSD ノードおよび Ceph Object Gateway ノードをクラスターに追加します。各ノードへの「カーネルのチューニング」に記載の手順を適用します。ノードの追加に関する詳細は、『Red Hat Ceph Storage 4 管理ガイド』の「OSD ノードの追加および削除」セクションを参照してください。

クラスターに追加された各 OSD ノードについて、クライアントデータを格納するノードの各ドライブについて OSD をクラスターに追加します。詳細は、『Red Hat Ceph Storage 4 管理ガイド』の「OSD の追加」セクションを参照してください。Ansible を使用して OSD ノードを追加する場合は、「Ansible グループの設定」を参照し、クラスターが複数のユースケースをサポートする場合は OSD ノードを適切なグループに追加します。

各 Ceph Object Gateway ノードについて、ゲートウェイインスタンスをインストールします。詳細は、『Red Hat Ceph Storage 4 インストールガイド』の「Ceph Object Gateway のインストール」セクションを参照してください。

クラスターが active+clean 状態に戻ると、オーバーライド を削除して「ストレージストラテジーの開発」に進みます。

注記

「ノードの追加」の手順 3 および「コマンドラインインターフェースを使用した OSD の追加」の手順 10 は、「CRUSH 階層の開発」から始まるトピックで再考します。

第7章 ストレージストラテジーの開発

Ceph Storage クラスターの設定に関するより困難な要素の 1 つは、実稼働環境での使用に Ceph Object Gateway を設定するのが、効果的なストレージストラテジーを定義することです。ストレージストラテジーには、以下の要素があります。

ストレージストラテジーおよびコマンドラインの使用方法に関する一般的なガイダンスは、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドを参照してください。

7.1. CRUSH 階層の開発

Ceph クラスターおよび Object Gateway をデプロイする場合には、通常オブジェクトゲートウェイにはデフォルトのゾーングループおよびゾーンがあります。Ceph Storage クラスターにはデフォルトのプールがあり、次にデフォルトの CRUSH 階層とデフォルトの CRUSH ルールを持つ CRUSH マップを使用します。

重要

デフォルトの rbd プールはデフォルトの CRUSH ルールを使用できます。Ceph クライアントがデフォルトのルールまたは階層を使用してクライアントデータを保存している場合は、それらを削除 しないでください

CRUSH 階層に関する一般的な詳細は、『ストレージストラテジー』ガイドの「CRUSH 管理」セクションを参照してください。

実稼働ゲートウェイは通常、ゲートウェイの用途と地理的位置に応じて名前が付けられたカスタムの レルム、ゾーングループ、およびゾーン を使用します。また、Ceph クラスターには、複数の CRUSH 階層を持つ CRUSH マップがあります。

  • サービスプール: 少なくとも 1 つの CRUSH 階層はサービスプール用であり、場合によってはデータ用になります。サービスプールには、.rgw.root と、ゾーンに関連付けられたサービスプールが含まれます。サービスプールは通常単一の CRUSH 階層下にあり、データの持続性にレプリケーションを使用します。データプールは、CRUSH 階層も使用できますが、プールは通常データの持続性を確保するために Erasure cod に設定できます。
  • インデックス: 少なくとも 1 つの CRUSH 階層はインデックスプール用にある 必要があり、CRUSH 階層は SSD ドライブや NVMe ドライブなどの高パフォーマンスのメディアにマップされます。バケットインデックスはパフォーマンスのボトルネックになります。この CRUSH 階層では、SSD または NVMe ドライブを使用することを強く推奨します。economize には、OSD ジャーナルに使用する SSD または NVMe ドライブにインデックスのパーティションを作成します。さらに、インデックスはバケットのシャード化で設定する必要があります。詳細は、「インデックスプールの作成」およびサポートリンクを参照してください。
  • 配置プール: 各配置ターゲットの配置プールには、バケットインデックス、データバケット、およびバケットの追加が含まれます。これらのプールは、個別の CRUSH 階層にある場合があります。Ceph Object Gateway は複数のストレージポリシーをサポートすることができるため、ストレージポリシーのバケットプールは、異なる CRUSH 階層に関連付けることができ、IOPS 最適化、スループット最適化、容量の最適化などの異なるユースケースが反映される場合があります。バケットインデックスプールには、SSD ドライブ、NVMe ドライブなどの高性能記憶媒体にバケットインデックスプールをマップするために、独自の CRUSH 階層を使用 すべきです

7.1.1. CRUSH ルートの作成

管理ノードのコマンドラインから、それぞれの CRUSH 階層の CRUSH マップに CRUSH ルートを作成します。また、潜在的にデータストレージプールを担うことができるサービスプールに、少なくとも 1 つの CRUSH 階層がある 必要があります。そのような SSD、NVMe ドライブなどの高性能ストレージメディアにマッピングされたバケットインデックスプールに、少なくとも 1 つの CRUSH 階層がある はずです

CRUSH 階層の詳細は、『Red Hat Ceph Storage 戦略ガイド』の「CRUSH Hierarchies 」セクションを参照してください。

CRUSH マップを手動で編集するには、『Red Hat Ceph Storage 戦略ガイド』の「CRUSH Map の編集 」セクションを参照してください。

以下の例では、data0data1、および data2 という名前のホストは、同じ物理ホストを参照する CRUSH の階層が複数存在するため、data0-sas-ssddata0-index などの拡張論理名を使用します。

一般的な CRUSH ルートは、ジャーナル用の SAS ドライブと SSD を持つノードを表す場合があります。以下に例を示します。

##
# SAS-SSD ROOT DECLARATION
##

root sas-ssd {
  id -1   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-sas-ssd weight 4.000
  item data1-sas-ssd weight 4.000
  item data0-sas-ssd weight 4.000
}

バケットインデックスの CRUSH ルートは、SSD や NVMe ドライブなどの高パフォーマンスメディアを表す はずです。OSD ジャーナルを格納する SSD または NVMe メディアにパーティションを作成することを検討してください。以下に例を示します。

##
# INDEX ROOT DECLARATION
##

root index {
  id -2    # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-index weight 1.000
  item data1-index weight 1.000
  item data0-index weight 1.000
}

7.1.2. CRUSH マップでの論理ホスト名の使用

RHCS 3 以降のリリースでは、CRUSH は、RHCS 2 以前のリリースでサポートされないストレージデバイス「class」の概念をサポートします。NVMe、SSD、HDD などの複数のストレージデバイスのクラスが含まれるホストまたはノードを持つ RHCS 3 クラスターでは、デバイスクラスで単一の CRUSH 階層を使用して、ストレージデバイスの異なるクラスを識別します。これにより、論理ホスト名を使用する必要がなくなります。RHCS 2 以前のリリースでは、複数の CRUSH 階層を使用し、デバイスのクラスごとに 1 つ、論理ホスト名を使用して、CRUSH 階層内のホストまたはノードを区別します。

CRUSH マップでは、ホスト名は一意で、1 回のみ使用する必要があります。ホストが複数の CRUSH 階層およびユースケースに対応する場合、CRUSH マップは、ホスト名が 1 度だけ使用されるように、実際のホスト名の代わりに論理ホスト名を使用できます。たとえば、ノードに SSD、SAS ドライブ(SSD ジャーナルを持つ SAS ドライブ、同じ場所に配置されたジャーナルを持つ SATA ドライブなど)など、ドライブのクラスが複数存在する場合があります。RHCS 2 以前のリリースで同じホスト用に複数の CRUSH 階層を作成するには、階層化は実際のホスト名の代わりに論理ホスト名を使用する必要があります。これにより、バケット名は CRUSH 階層内で一意になるようにする必要があります。たとえば、ホスト名が data2 の場合、CRUSH 階層は、data2-sas-ssddata2-index などの論理名を使用する可能性があります。以下に例を示します。

host data2-sas-ssd {
  id -11   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.0 weight 1.000
  item osd.1 weight 1.000
  item osd.2 weight 1.000
  item osd.3 weight 1.000
}

前述の例では、ホスト data2 は論理名 data2-sas-ssd を使用して、SSD にジャーナルのある SAS ドライブを 1 つの階層にマッピングします。上記の例の osd.0 から osd.3 の OSD ID は、高スループットのハードウェア構成で SSD ジャーナルを使用する SAS ドライブを表しています。この例では、これらの OSD ID は OSD ID とは異なります。

以下の例では、ホスト data2 は論理名 data2-index を使用してバケットインデックスの SSD ドライブを 2 つ目の階層にマッピングします。以下の例の OSD ID の osd.4 は、バケットインデックスプール専用に使用される SSD ドライブまたはその他の高速ストレージメディアを示しています。

host data2-index {
  id -21   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.4 weight 1.000
}
重要

論理ホスト名を使用する場合には、以下のいずれかの設定が Ceph 設定ファイルに存在し、OSD 起動スクリプトが起動時に実際のホスト名を使用しないようにし、CRUSH マップでデータの検索に失敗します。

CRUSH マップが、通常の例にあるように論理ホスト名を使用する場合、OSD の起動スクリプトが初期化時に実際のホスト名に従ってホストを特定できないようにします。Ceph 設定ファイルの [global] セクションに、以下の設定を追加します。

osd_crush_update_on_start = false

論理ホスト名を定義する別の方法は、Ceph 設定ファイルの [osd.<ID>] セクションで各 OSD の CRUSH マップの場所を定義することです。これにより、OSD の起動スクリプトが定義する場所が上書きされます。前述の例から、エントリーは以下のようになります。

[osd.0]
osd crush location = "host=data2-sas-ssd"

[osd.1]
osd crush location = "host=data2-sas-ssd"

[osd.2]
osd crush location = "host=data2-sas-ssd"

[osd.3]
osd crush location = "host=data2-sas-ssd"

[osd.4]
osd crush location = "host=data2-index"
重要

CRUSH マップが実際のホスト名ではなく論理ホスト名を使用し、再起動時には論理ホスト名を使用する場合には、Ceph Storage Cluster は OSD が実際のホスト名にマップされ、実際のホスト名が CRUSH マップにないことを想定し、Ceph Storage Cluster クライアントは OSD およびそのデータを検出しません。

7.1.3. CRUSH ルールの作成

デフォルトの CRUSH 階層と同様に、CRUSH マップにはデフォルトの CRUSH ルールも含まれます。

注記

デフォルトの rbd プールはこのルールを使用できます。他のプールを使用して顧客データを保存する場合は、デフォルトのルールを削除しないでください。

CRUSH ルールの一般的な詳細は、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドの「CRUSH ルール」セクションを参照してください。CRUSH マップを手動で編集するには、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドの「CRUSH マップ」セクションを参照してください。

CRUSH 階層ごとに、CRUSH ルールを作成します。以下の例は、.rgw.root を含むサービスプールを保存する CRUSH 階層のルールを示しています。この例では、ルート sas-ssd がメインの CRUSH 階層として機能します。デフォルトのルールと区別するために、rgw-service という名前を使用します。step take sas-ssd 行は、「CRUSH ルートの作成」で作成された sas-ssd ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア構成のジャーナルに対して SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaftype rack 部分が障害ドメインになります。以下の例では、ラックです。

##
# SERVICE RULE DECLARATION
##

rule rgw-service {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type rack
 step emit
}
注記

Foregoing の例では、データが 3 回レプリケートされる場合は、同様の OSD ノードを含むクラスターに 3 つ以上のラックが必要です。

ヒント

type replicated 設定は、データ永続性、レプリカ数、またはイレイジャーコーディングとは 関係ありません複製 のみがサポートされます。

以下の例は、データプールを保存する CRUSH 階層のルールを示しています。この例では、rootsas-ssd が、サービスルールと同じ CRUSH 階層として機能します。rgw-throughput を使用して、デフォルトのルールと rgw-service と区別します。step take sas-ssd 行は、「CRUSH ルートの作成」で作成された sas-ssd ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア構成の SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaftype host 部分障害ドメインになります。以下の例では、ホストです。ルールは同じ CRUSH 階層を使用しますが、障害ドメインが異なることに注意してください。

##
# THROUGHPUT RULE DECLARATION
##

rule rgw-throughput {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type host
 step emit
}
注記

前述の例では、プールがデフォルトよりも大きな数のデータとエンコーディングのチャンクを使用してイレイジャーコーディングを使用する場合は、同様の OSD ノードを含むクラスターに少なくとも多くのラックが含まれており、チャンクを同様化できるように、少なくとも多くの OSD ノードを含むラックが多数ある必要があります。小規模なクラスターの場合、これは実用的ではない可能性があるため、前述の例では host を CRUSH 障害ドメインとして使用します。

以下の例は、インデックスプールを保存する CRUSH 階層のルールを示しています。この例では、root の index は主な CRUSH 階層として機能します。rgw-index を使用して、rgw-servicergw-throughput と区別します。step take index 行は、「CRUSH ルートの作成」で作成された index root を使用するようにプールに指示します。その子バケットには、SSD ドライブ、NVMe ドライブなどの高性能ストレージメディア、またはOSD ジャーナルも格納する SSD ドライブまたは NVMe ドライブ上のパーティションが含まれます。step chooseleaftype rack 部分が障害ドメインになります。以下の例では、ラックです。

##
# INDEX RULE DECLARATION
##

rule rgw-index {
 type replicated
 min_size 1
 max_size 10
 step take index
 step chooseleaf firstn 0 type rack
 step emit
}

7.2. ルートプールの作成

Ceph Object Gateway 設定は、レルム、ゾーングループ、ゾーンなど、.rgw.root という名前のプールに保存されます。規則により、その名前の前にゾーン名が追加されます。

.rgw.root

Ceph Storage クラスターが実行中の場合には、新しいルールを使用して .rgw.root プールを作成します。PG 数の詳細は、『ストレージストラテジーガイド』の「Ceph Placement Groups (PGs) per Pool Calculator」および「配置グループ」の章を参照してください。プールの作成に関する詳細は、『ストレージストラテジーガイド』のCreate a Pool「プールの作成」セクションを参照してください。

この場合、プールは replicated を使用し、データ永続性に erasure は使用 しません。以下に例を示します。

# ceph osd pool create .rgw.root 32 32 replicated sas-ssd
注記

.rgw.root を含むサービスプールの場合は、「Ceph Placement Groups (PGs) per Pool Calculator」から提案される PG 数は、1 OSD あたりのターゲットの PG よりもはるかに少なくなります。また、OSD の数が計算のステップ 3 に設定されていることを確認します。

このプールが作成されると、Ceph Object Gateway はその設定データをプールに保存できます。

7.3. レルムの作成

Ceph Object Gateway をサポートする Ceph Storage プールは、ゾーングループ内のゾーンに適用されます。デフォルトでは、Ceph Object Gateway はデフォルトのゾーングループおよびゾーンを定義します。

マスターゾーングループおよびゾーンの場合、Red Hat は新しいレルム、ゾーンを作成することを推奨します。デフォルトゾーンおよびそのプールがすでに生成されている場合には、そのプールを削除します。「マルチサイト」操作用にクラスターを設定するため、「マスターゾーンの設定」をベストプラクティスとして使用します。

  1. 「レルムを作成」します。詳細は、「レルム」を参照してください。
  2. マスターゾーングループを作成 します。ゾーングループの詳細は、「ゾーングループ」を参照してください。
  3. 「マスターゾーンを作成」します。ゾーンの詳細は、「ゾーン」を参照してください。
  4. デフォルトのゾーングループおよびゾーンを削除 します。あなたは、デフォルトのプールが作成され、そこにクライアントデータが格納されていない場合は、デフォルトのプールを削除することができます.rgw.root プールは削除 しないでください
  5. システムユーザーを作成します
  6. 期間を更新します
  7. Ceph 設定ファイルを更新します
注記

この手順では、ゲートウェイがプールを手動で作成する可能性があるので、ゲートウェイの開始ステップを省略します。特定の CRUSH ルールおよびデータの持続性方法を指定するには、プールを手動で作成します。

新しいレルム、ゾーングループ、ゾーン を設定すると、クラスターは、ゾーングループ内に複数のゾーンがあるマルチサイトクラスターへの拡張用に準備されます。つまり、クラスターはフェイルオーバーのために拡張および設定でき、障害復旧を行います。詳細は、「マルチサイトでのクラスターの拡張」を参照してください。

gateway realm

Red Hat Ceph Storage 2 では、マルチサイト設定はデフォルトでアクティブ/アクティブになっています。マルチサイトクラスターをデプロイする場合、ゾーンおよびそれらの基礎となる Ceph ストレージクラスターは、異なる地理的リージョンにある場合があります。各ゾーンには同じ namespace の各オブジェクトのディープコピーがあるため、ユーザーは最も近いゾーンからコピーにアクセスでき、レイテンシーが短縮されます。ただし、セカンダリーゾーンがフェイルオーバーおよび障害復旧のみを目的とする場合には、クラスターは active-passive モードで設定できます。

注記

複数のゾーンでのゾーングループの使用がサポートされます。複数のゾーングループの使用はテクノロジープレビュー機能としてのみ提供され、実稼働環境ではサポートされません。

7.4. サービスプールの作成

Ceph Object Gateway は、さまざまなサービス機能に多くのプールを使用し、バケットインデックス、データ、その他の情報を格納するための個別の配置プールのセットを使用します。

プールの配置グループをピアに計算すると、Red Hat では通常、Ceph Object Gateway のサービスプールが、データストレージプールよりも大幅に少ない配置グループを使用することを推奨しています。

サービスプールは、サービス制御、ガベージコレクション、ロギング、ユーザー情報、使用状況などのオブジェクトを保存します。通常、これらのプール名には、プール名の前にゾーン名が追加されます。

注記

Red Hat Ceph Storage 4.1 以降、ガベージコレクションは OMAP ではなく、通常の RADOS オブジェクトでログメッセージを使用します。今後は、より多くの機能がログプールにメタデータを保存します。したがって、ログプールに NVMe/SSD OSD を使用することが強く推奨されます。

  • .<zone-name>.rgw.control: コントロールプール。
  • .<zone-name>.log: ログプールには、すべてのバケット/コンテナーのログおよび create、read、update、および delete などのオブジェクトアクションが含まれます。
  • .<zone-name>.rgw.buckets.index: このプールは、そのプールのインデックスを保存します。
  • .<zone-name>.rgw.buckets.data: このプールはバケットのデータを格納します。
  • .<zone-name>.rgw.meta: メタデータプールは user_keys およびその他の重要なメタデータを保存します。
  • .<zone-name>.meta:users.uid: ユーザー ID プールには、一意のユーザー ID のマップが含まれます。
  • .<zone-name>.meta:users.keys: keys プールには、各ユーザー ID のアクセスキーと秘密鍵が含まれます。
  • .<zone-name>.meta:users.email: email プールには、ユーザー ID に関連するメールアドレスが含まれます。
  • .<zone-name>.meta:users.swift: Swift プールには、ユーザー ID の Swift サブユーザー情報が含まれます。

「ゾーンの取得」の手順を実行し、プール名を表示します。

# radosgw-admin zone get [--rgw-zone=<zone>]

radosgw-admin はゾーンを作成すると、プール名は、ゾーン名を先頭に追加する 必要があります。たとえば、us-west の名前ゾーンは、次のようになり何かというプールの名前を持っている 必要があります

{ "domain_root": ".rgw.root",
  "control_pool": ".us-west.rgw.control",
  "gc_pool": ".us-west.rgw.gc",
  "log_pool": ".us-west.log",
  "intent_log_pool": ".us-west.intent-log",
  "usage_log_pool": ".us-west.usage",
  "user_keys_pool": ".us-west.users.keys",
  "user_email_pool": ".us-west.users.email",
  "user_swift_pool": ".us-west.users.swift",
  "user_uid_pool": ".us-west.users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
    {  "key": "default-placement",
       "val": { "index_pool": ".us-west.rgw.buckets.index",
                "data_pool": ".us-west.rgw.buckets",
                "data_extra_pool": ".us-west.rgw.buckets.non-ec"
                "index_type": 0
              }
    }
  ]
}

control_pool から始まり、user_uid_pool で終わる場合は、ゾーン名の前にプール名が追加されていれば、そのゾーン名を使用してプールを作成します。前述の例に従って、プールの作成は以下のようになります。

# ceph osd pool create .us-west.rgw.control 32 32 replicated rgw-service
...
# ceph osd pool create .us-west.users.uid 32 32 replicated rgw-service

以前の例から、rgw-service ルールは、SSD ジャーナルおよび rack を CRUSH 障害ドメインとして持つ SAS ドライブの CRUSH 階層を表します。前述の例は、「CRUSH Root の作成」および「CRUSH ルールの作成」を参照してください。

PG 数の詳細は、『ストレージストラテジーガイド』の「Ceph Placement Groups (PGs) per Pool Calculator」および「配置グループ」を参照してください。プールの作成に関する詳細は、『ストレージストラテジーガイド』の「プールの作成」セクションを参照してください。

注記

サービスプールの場合、計算式から推奨される PG 数は OSD ごとのターゲット PG よりも大幅に小さくなります。calculator のステップ 3 で、正しい OSD の数が指定されていることを確認します。

通常、.rgw.root プールとサービスプールは同じ CRUSH 階層を使用し、CRUSH ルールの障害ドメインとして少なくとも node を使用する必要があります。.rgw.root プールと同様に、サービスプールは、データの耐久性のために、erasure ではなくreplicated を使用する必要があります。

7.5. データ配置ストラテジーの作成

Ceph Object Gateway には、default-placement と呼ばれるデフォルトのストレージポリシーがあります。クラスターにストレージポリシーが 1 つしかない場合は、default-placement ポリシーで十分です。このデフォルトの配置ポリシーはゾーングループ設定から参照され、ゾーン設定で定義されます。

詳細は、Red Hat Enterprise Linux 用の Red Hat Ceph Storage 4 Ceph Object Gateway ガイドの「ストレージポリシー」セクションを参照してください。

複数のユースケースをサポートするクラスターの場合(IOPimized、put-optimized、容量の最適化など)、ゾーングループ設定の配置ターゲットセットと、ゾーン設定の配置プールセットは各ストレージポリシーを表します。

以下のセクションでは、ストレージポリシーを作成し、これをデフォルトポリシーにする方法を紹介します。この例では、デフォルトポリシーが throughput-optimized ハードウェアプロファイルを使用することを前提としています。トピックには以下が含まれます。

7.5.1. インデックスプールの作成

デフォルトでは、Ceph Object Gateway はバケットのオブジェクトをインデックスにマップします。これにより、ゲートウェイクライアントは他のオブジェクト間でバケットのオブジェクト一覧を要求できます。一般的なユースケースでは、ユーザーにバケットごとのオブジェクト数と、バケットごとのオブジェクト数が制限されるクォータが必要になりますが、バケットは列挙可能なオブジェクトに保存できます。バケットが何万のオブジェクトも保存する場合、パフォーマンス上のメリットは、SSD または NVMe ドライブなどの高パフォーマンスのストレージメディアを使用してデータを保存しなくなります。また、バケットのシャード化も、パフォーマンスを大幅に向上させます。

PG 数の詳細は、『ストレージストラテジーガイド』の「Ceph Placement Groups (PGs) per Pool Calculator」および「配置グループ」を参照してください。プールの作成に関する詳細は、『ストレージストラテジーガイド』の「プールの作成」セクションを参照してください。

注記

PG per Pool Calculator は、インデックスプールのプールごとに少数の PG 数を推奨します。ただし、PG 数は、サービスプールとしての PG 数に約 2 倍の 1 つです。

注記

Red Hat は、インデックスプールの HDD デバイスに対応していません。サポート対象構成の情報については、「Red Hat Ceph Storage: Supported configurations」の記事を参照してください。

インデックスプールを作成するには、ceph osd pool create にプール名、PG および PGP の数、replicated データ永続性メソッド、およびルール名を指定して作成します。

重要

バケットが 100k を超えるオブジェクトを保存する場合は、バケットのオブジェクト数が増えるため、インデックスのパフォーマンスが低下しないように、バケットのシャーディングを設定します。『Ceph Object Gateway ガイドの設定および管理ガイド』の「バケットシャーディングの構成」セクションを参照してください。元の構成が適切でなくなった場合のバケットの再シャーディングの詳細については、『Ceph Object Gateway ガイド構成および管理ガイド』の「バケットインデックスの再シャーディング」セクションも参照してください。

7.5.2. データプールの作成

データプールは、Ceph Object Gateway が特定のストレージポリシーのオブジェクトデータを保存する場所です。データプールは、サービスプールの PG の数を減らすのではなく、PG を完全な補完する必要があります。データプールは、それが実質的に複製するよりも効率的であり、データの耐久性を維持しながら、大幅に容量要件を減らすことができますよう、イレイジャーコーディングを使用して検討 すべきです

イレイジャーコーディングを使用するには、イレイジャーコードプロファイルを作成します。詳細は、『ストレージストラテジーガイド』の「イレイジャーコーディングプロファイル」セクションを参照してください。

重要

プールの作成後にプロファイルを変更できないため、正しいプロファイルの選択は重要です。プロファイルを変更するには、別のプロファイルを持つ新しいプールを作成し、オブジェクトを古いプールから新しいプールに移行する必要があります。

デフォルト設定は 2 つのデータチャンクと 1 つのエンコーディングチャンクです。つまり、1 つの OSD のみが失われる可能性があります。回復性を高めるには、より多くのデータおよびエンコーディングチャンクを検討してください。たとえば、非常に大きなシステムによって 8 つのデータチャンクと 3 つのエンコーディングチャンクが使用されます。これにより、データが失われることなく 3 つの OSD が失敗します。

重要

各データおよびエンコーディングチャンク SHOULD は、少なくとも異なるノードまたはホストに保存されます。小規模なクラスターの場合、これにより、大量のデータおよびエンコードチャンクを使用する場合に、rack の非現実障害ドメインを最低限の CRUSH 障害ドメインとして使用します。そのため、データプールは、最小 CRUSH 障害ドメインとして、host を持つ別の CRUSH 階層を使用するのが一般的です。Red Hat は、最小障害ドメインとして host を推奨します。イレイジャーコードのチャンクが同じホスト内の OSD に保存されている場合、失敗したジャーナルやネットワークカードなどのホストの障害によりデータが失われる可能性があります。

データの追加プールを作成するには、ceph osd pool create にプール名、PG および PGP の数、erasure データ永続性メソッド、イレイジャーコードプロファイル、およびルール名を指定して実行します。

7.5.3. データ追加プールの作成

data_extra_pool は、イレイジャーコーディングを使用できないデータ向けです。たとえば、マルチパートのアップロードでは、複数の部分に収まるような大規模なオブジェクトをアップロードすることができます。これらの部分は、最初にイレイジャーコーディングなしで保存する必要があります。イレイジャーコーディングは、部分的なアップロードではなく、オブジェクト全体に適用されます。

注記

PG per Pool Calculator では、data_extra_pool 対してプールあたりの PG 数を少なくすることが推奨されています。ただし、PG 数はサービスプールとバケットインデックスプールと同じ PG の約 2 倍です。

データの追加プールを作成するには、ceph osd pool create にプール名、PG および PGP の数、replicated データ永続性メソッド、およびルール名を指定して作成します。以下に例を示します。

# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service

7.5.4. ゾーングループへの配置ターゲットの設定

プールを作成したら、ゾーングループに配置ターゲットを作成します。ゾーングループを取得するには、次のコマンドを実行して、ゾーングループの設定を zonegroup.json というファイルに出力します。

# radosgw-admin zonegroup get [--rgw-zonegroup=<zonegroup>] > zonegroup.json

ファイルの内容は以下のようになります。

{
  "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
  "name": "us",
  "api_name": "us",
  "is_master": "true",
  "endpoints": [
    "http:\/\/rgw1:80"
  ],
  "hostnames": [],
  "hostnames_s3website": [],
  "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
  "zones": [
      {
        "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
        "name": "us-east",
        "endpoints": [
            "http:\/\/rgw1"
        ],
        "log_meta": "true",
        "log_data": "true",
        "bucket_index_max_shards": 0,
        "read_only": "false"
      },
      {
        "id": "d1024e59-7d28-49d1-8222-af101965a939",
        "name": "us-west",
        "endpoints": [
            "http:\/\/rgw2:80"
        ],
        "log_meta": "false",
        "log_data": "true",
        "bucket_index_max_shards": 0,
        "read_only": "false"
      }
  ],
  "placement_targets": [
      {
        "name": "default-placement",
        "tags": []
      }
  ],
  "default_placement": "default-placement",
  "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
}

placement_targets セクションには、各ストレージポリシーが一覧表示されます。デフォルトでは、default-placement という配置ターゲットが含まれます。デフォルトの配置ターゲットは、placement_targets セクションの直後に識別されます。

throughput-optimized と呼ばれる配置ターゲットをデフォルトターゲットとして throughput-optimized とすると、ゾーングループ構成の placement_targets セクションと default_placement 設定を次のように変更する必要があります。

{
  ...
  "placement_targets": [
      {
        "name": "throughput-optimized",
        "tags": []
      }
  ],
  "default_placement": "throughput-optimized",
  ...
}

最後に、変更した zonegroup.json ファイルの設定でゾーングループ構成を設定し、期間を更新します。以下に例を示します。

# radosgw-admin zonegroup set [--rgw-zonegroup=<zonegroup>] --infile zonegroup.json
# radosgw-admin period update --commit

7.5.5. ゾーンへの配置プールの設定

ゾーングループに新しい throughput-optimized 配置ターゲットが割り当てられたら、ゾーン設定で throughput-optimized の配置プールをマッピングします。この手順では、関連するプールへの default-placement のマッピングが、配置グループの throughput-optimized セットに置き換えられます。

「ゾーンの取得」の手順を実行し、プール名を表示します。

# radosgw-admin zone get [--rgw-zone=<zone>] > zone.json

us-west という名前のゾーンを前提とすると、ファイルの内容は以下のようになります。

{ "domain_root": ".rgw.root",
  "control_pool": ".us-west.rgw.control",
  "gc_pool": ".us-west.rgw.gc",
  "log_pool": ".us-west.log",
  "intent_log_pool": ".us-west.intent-log",
  "usage_log_pool": ".us-west.usage",
  "user_keys_pool": ".us-west.users.keys",
  "user_email_pool": ".us-west.users.email",
  "user_swift_pool": ".us-west.users.swift",
  "user_uid_pool": ".us-west.users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
    {  "key": "default-placement",
       "val": { "index_pool": ".us-west.rgw.buckets.index",
                "data_pool": ".us-west.rgw.buckets",
                "data_extra_pool": ".us-west.rgw.buckets.non-ec"
                "index_type": 0
              }
    }
  ]
}

ゾーン設定の placement_pools セクションは、配置プールのセットを定義します。配置グループの各セットは、ストレージポリシーを定義します。ファイルを変更して default-placement エントリーを削除し、throughput-optimized エントリーを、前のステップで作成したプールに置き換えます。以下に例を示します。

{
...
"placement_pools": [
    {  "key": "throughput-optimized",
       "val": { "index_pool": ".us-west.rgw.buckets.index",
                "data_pool": ".us-west.rgw.buckets.throughput"}
                "data_extra_pool": ".us-west.rgw.buckets.non-ec",
                "index_type": 0
    }
  ]
}

最後に、変更した zone.json ファイルからゾーン設定を設定し、期間を更新します。以下に例を示します。

# radosgw-admin zone set --rgw-zone={zone-name} --infile zone.json
# radosgw-admin period update --commit
注記

index_pool は、SSD や他の高パフォーマンスストレージを含むインデックスプールおよび CRUSH 階層を参照し、data_pool は PG に完全補完されたプール、高スループットのホストバスアダプターの CRUSH 階層、ジャーナル用の SAS ドライブおよび SSD を参照します。

7.5.6. データ配置の概要

クライアント要求を処理する際に、Ceph Object Gateway はデフォルトのストレージポリシーとして新たな throughput-optimized ターゲットを使用します。マルチサイト設定の異なるゾーンおよびゾーングループの同じターゲットを確立し、プールのゾーン名を必要に応じて置き換えます。

以下の手順を使用して、追加のストレージポリシーを設定します。各ターゲットおよび配置グループの命名は任意です。これには、faststreamingcold-storage、またはその他の適切な名前を使用できます。ただし、各セットには、ゾーングループの placement_targets の下に対応するエントリーが必要であり、ターゲットの 1 つは default_placement 設定で参照される 必要があります。また、ゾーンには、ポリシーごとに構成された対応するプールのセットが必要です。

クライアント要求が X-Storage-Policy と別のターゲットを指定しない限り、クライアントリクエストは常にデフォルトのターゲットを使用します。オブジェクトゲートウェイクライアントの使用例は、「コンテナーの作成」を参照してください。

第8章 ゲートウェイの設定

実稼働環境の Ceph Object Gateway 準備の最終ステップには、Civetweb、ファイアウォールポート、DNS およびロードバランサーを設定します。トピックには以下が含まれます。

8.1. Civetweb の設定

Ceph Object Gateway の「インストール」時に選択した内容に応じて、Ceph 構成ファイルには 「レルムの作成」に関連する手順からの追加の変更を加えた Ceph ObjectGateway の各インスタンスのエントリーがすでに含まれています。

デフォルト設定の最も一般的な設定変更は、Ansible が設定したデフォルトのポート 8080 を別のポート (80 など) に変更することです。「CivetWeb ポートの変更」を参照してください。

Civetweb に固有の追加設定があります。詳細は、「Civetweb 設定オプション」を参照してください。

上書きされる可能性のある追加設定がいくつかあります。詳細は、「Object Gateway 設定リファレンス」を参照してください。

注記

追加のユースケースのセクションには、サードパーティーコンポーネントと共に Ceph Object Gateway を使用する詳細な設定例が提供されます。

8.2. ファイアウォールポートの設定

Civetweb のデフォルトポートを変更する場合には、対応するポートがクライアントアクセス用に開いていることを確認してください。詳細は、Red Hat Enterprise Linux の『Red Hat Ceph Storage 4 インストールガイド』の「Red Hat Ceph Storage 用ファイアウォールの設定」セクションを参照してください。

8.3. DNS ワイルドカードの設定

S3-style subdomains にはバケット名を CNAME 拡張として組み込みます。S3 スタイルのサブドメインを容易にするために、DNS にワイルドカードを追加します。詳細は、Red Hat Ceph Storage 4 の『Ceph Object Gateway 設定および管理ガイド』の「DNS へのワイルドカードの追加」セクションを参照してください。

8.4. ロードバランサーの設定

通常、ゾーンには、実稼働の負荷を処理し、高可用性を維持するために、Ceph Object Gateway のインスタンスが複数含まれます。実稼働クラスターは、通常、ロードバランサーを使用してゲートウェイインスタンス間での要求を割り当てます。

また、Civetweb の以前のバージョンは HTTPS をサポートしません。ロードバランサーは SSL 要求を受け入れるように設定でき、SSL 接続を終了して、HTTP 経由でゲートウェイインスタンスへ要求を渡すことができます。

Ceph Storage は高可用性を維持することを目的としています。このため、Red Hat は HAProxy または keepalived を使用することを推奨します。詳細は、Ceph Object Gateway の『設定および管理ガイド』の「HAProxy/keepalived の設定」セクションを参照してください。

8.5. Beast フロントエンドの使用

Ceph Object Gateway は、CivetWeb および Beast 埋め込み HTTP サーバーをフロントエンドとして提供します。Beast フロントエンドは、HTTP 解析に Boost.Beast ライブラリーを使用し、非同期ネットワーク I/O に Boost.Asio ライブラリーを使用します。Red Hat Ceph Storage バージョン 3.x では、CivetWeb がデフォルトのフロントエンドとなり、Beast フロントエンドは Red Hat Ceph Storage 設定ファイルの rgw_frontends で指定する必要があります。Red Hat Ceph Storage バージョン 4.0 の時点で、Beast フロントエンドはデフォルトであり、Red Hat Ceph Storage 3.x からのアップグレードにより、rgw_frontends パラメーターが自動的に Beast に変更になります。

8.6. Beast 設定オプション

以下の Beast 設定オプションは、RADOS Gateway の Ceph 設定ファイルの組み込み Web サーバーに渡すことができます。それぞれのオプションにはデフォルト値があります。値の指定がない場合は、デフォルト値が空になります。

オプション詳細デフォルト

endpoint および ssl_endpoint

address[:port] 形式のリスニングアドレスを設定します。アドレスはドット付き 10 進数形式の IPv4 アドレス文字列、または 16 進数表記の IPv6 アドレスが角括弧で囲まれている IPv6 アドレスです。任意のポートのデフォルトは、endpoint8080 になり、ssl_endpoint443 になります。endpoint=[::1] endpoint=192.168.0.100:8000 のように複数回指定できます。

ssl_certificate

SSL 対応のエンドポイントに使用する SSL 証明書ファイルへのパス。ファイルが複数の項目を含む PEM ファイルである場合、順番は重要です。ファイルは RGW サーバーキーから開始してから、中間証明書、最後に CA 証明書で開始する必要があります。

ssl_private_key

SSL 対応のエンドポイントに使用される秘密鍵ファイルへのオプションのパス。ssl_certificate で指定されているファイルがない場合は、秘密鍵として使用されます。

tcp_nodelay

一部の環境でのパフォーマンスの最適化。

SSL を使用する Beast オプションのある /etc/ceph/ceph.conf ファイルの例:

...

[client.rgw.node1]
rgw frontends = beast ssl_endpoint=192.168.0.100:443 ssl_certificate=<path to SSL certificate>

注記

デフォルトでは、Beast フロントエンドは、サーバーによって処理されるすべての要求を記録するアクセスログラインを RADOS Gateway ログファイルに書き込みます。

関連情報

第9章 その他のユースケース

クラスターを起動して実行したら、追加で考慮するユースケースがあります。

9.1. マルチサイトでのクラスターの拡張

ストレージストラテジーを開発する場合、レルムの作成 の手順により、クラスターがすでに独自のレルム、マスターゾーングループ、およびマスターゾーンと共にマルチサイトを使用するように設定されていることを確認します。

一般的な実稼働クラスターでは、障害発生時にバックアップとして機能する別の物理的な場所に、独自の Ceph Storage クラスターを備えたセカンダリーゾーンがあります。セカンダリーゾーンを設定するには、本ガイドで手順を繰り返します。通常、セカンダリーゾーンには、マスターゾーンと同じハードウェア設定とサイジングが必要です。詳細は、「セカンダリーゾーンの設定」を参照してください。

セカンダリーゾーンを追加すると、「フェイルオーバーおよび災害リカバリー」機能がクラスターに追加されます。

gateway realm

9.2. NFS Ganesha を使用したデータの移行

Ceph Object Gateway および Ceph Storage Cluster がファイルシステムベースのストレージソリューションに置き換わる場合には、Ceph の NFS-Ganesha ソリューションを使用してデータをファイルシステムから Ceph Object Gateway に移行することを検討してください。

Ceph Object Gateway の『設定および管理ガイド』の「名前空間の NFS-Ganesha へのエクスポート」の章を参照してください。

9.3. 静的 Web ホスト用のクラスターの設定

従来の Web ホストでは、各 Web サイトに Web サーバーを設定し、コンテンツを動的に変更しない場合にリソースを効果的に使用できます。

Ceph Object Gateway は、S3 バケットで静的 Web サイトをホストできます。つまり、PHP、サーブレット、データベース、nodejs などのサーバー側のサービスを使用しないサイトです。このアプローチは、各サイトに Web サーバーを使用する仮想マシンを設定するよりも大幅に複雑です。

詳細は、「静的 Web ホスト用のゲートウェイの設定」を参照してください。

9.4. LDAP/AD のクラスターの設定

ユーザー向けに Ceph Object Gateway をデプロイする組織は、LDAP(Light-weight Directory Access Protocol)または Microsoft Active Directory(AD)を使用して Ceph Object Gateway ユーザーを作成する際の Ceph Object Gateway での認証を選択することができます。

LDAP/AD を使用すると、Ceph Object Gateway は組織 LDAP/AD のシングルサインオンの開始と統合できます。

詳細は、Red Hat Ceph Storage 4 の「LDAP/AD を使用する Ceph Object Gateway ガイド」を参照してください。

9.5. OpenStack Keystone を使用するためのクラスターの設定

OpenStack Swift の代わりに Ceph Object Gateway をデプロイする場合には、OpenStack Keystone を使用して Ceph Object Gateway ユーザーの作成の代わりに、OpenStack Keystone を使用するようにゲートウェイを設定することができます。

詳細は、Red Hat Ceph Storage 4 の『Keystone を使用した Ceph Object Gateway ユーザーの使用』を参照してください。

第10章 LVM Optimally での NVMe の使用

  1. 要約

    以下の手順は、高速度の NVMe ベースの SSD を使用する場合に Object Gateway の使用に対して Ceph をデプロイする方法を示しています(これは SATA SSD にも適用されます)。ジャーナルとバケットインデックスは、高速ストレージデバイス上に配置されます。これにより、1 つのデバイスにすべてのジャーナルが設定される場合と比較して、パフォーマンスを向上させることができます。この構成では、osd_scenariolvm に設定する必要があります。

    2 つの設定例の手順を以下に示します。

    • 1 つのバケットインデックスを使用する 1 つの NVMe デバイスおよび 4 つ以上の HDD: 1 つの NVMe デバイス
    • 2 つの NVMe デバイスと 2 つのバケットインデックスを使用する少なくとも 4 つのHDD: 2 つの NVMe デバイス
  2. 詳細

    最も基本的な Ceph 設定では、collocatedosd_scenario 設定を使用します。これにより、OSD データとそのジャーナルが 1 つのストレージデバイス("co-located")に保存されます。通常のサーバー設定には、HDD および SSD の両方が含まれます。HDD は通常 SSD を超えるため、配置された設定で HDD のほとんどのストレージ領域を切り離すため、OSD データとジャーナルの両方をそのだけ配置します。ただし、ジャーナルは高速の SSD 上にあるはずです。別のオプションとして、non-collocatedosd_scenario 設定を使用します。これにより、ジャーナル専用のデバイスを設定することができるため、OSD データを HDD に、ジャーナルを SSD に配置できます。

    OSD データおよびジャーナルの他に、Object Gateway を使用する場合は、バケットインデックスをデバイスに保存する必要があります。この場合、Ceph は、HDD が OSD データを保持し、1 つの SSD がジャーナルを保持し、別の SSD がバケットインデックスを保持するように設定されています。これにより、バケットインデックスを持つ SSD の使用率が低くなる一方で、すべてのジャーナルを持つ SSD が搭載される高負荷の状況が発生する可能性があります。

    解決策は、osd_scenariolvm に設定し、論理ボリュームマネージャー (LVM) を使用して、複数の目的で 1 つの SSD デバイスを分割することです。これにより、ジャーナルおよびバケットインデックスは、1 つのデバイス上で側で存在できます。最も重要なことは、ジャーナルを複数の SSD 上に存在させ、複数のデバイス全体でジャーナルの集中 IO データ転送を分散します。

    Ceph のインストールに使用される ceph-ansible RPM が提供する通常の Ansible Playbook (site.yml、osds.yml など) は、複数の目的で 1 つのデバイスを使用することをサポートしません。

    今後、通常の Ansible Playbook は、複数の目的のために 1 つのデバイスの使用をサポートしています。その間、SSD 使用率を最適化するのに必要な論理ボリューム (LV) の作成を容易にするために、Playbook の lv-create.yml および lv-vars.yaml が提供されます。lv-create.yml を実行すると、site.yml が正常に実行でき、新たに作成された論理ボリュームが使用されます。

    重要

    これらの手順は、FileStore ストレージバックエンドにのみ適用され、新しい BlueStore ストレージバックエンドには適用されません。

10.1. 1 つの NVMe デバイスの使用

以下の手順に従って、1 つの NVMe デバイスと共に Object Gateway の使用用に Ceph をデプロイします。

10.1.1. 既存 Ceph クラスターをすべてパージする

Ceph がすでに設定されている場合は、これをパージして最初からやり直します。この目的のために、Ansible Playbook (purge-cluster.yml) が提供されます。

$ ansible-playbook infrastructure-playbooks/purge-cluster.yml -i hosts

purge-cluster.yml の使用方法は、『インストールガイド』「Ansible を使用した Ceph クラスターのパージ」を参照してください。

重要

以下の手順で Ceph を再デプロイするサーバーを準備するには、クラスターのパージが十分ではない場合があります。Ceph が使用するストレージデバイス上のファイルシステム、GPT、RAID、またはその他の署名により、問題が発生する場合があります。wipefs を使用して署名を削除する手順は、「Ansible Playbook lv-create.yml の実行」に記載されています。

10.1.2. 通常インストール用のクラスターの設定

NVMe や LVM の考慮点のほかに、クラスターを設定し、通常通りにクラスターを設定しますが、Ansible Playbook を実行する前に停止します。その後、クラスターのインストール設定は、Object Gateway をサポートするための NVMe/LVM の使用を最適に調整されます。その時点でのみ、Ansible Playbook を実行する必要があります。

通常のインストール用にストレージクラスターを設定するには、『Red Hat Ceph Storage インストールガイド』を参照してください。特に、Ansible ログディレクトリーを作成する手順 9 での「Red Hat Ceph Storage Cluster のインストール」の手順を完了します。ansible-playbook site.yml -i hosts の実行時に、手順 10 の前に停止します。

重要

ここから、「Ceph for NVMe のインストールと成功の確認」までの手順がすべて完了するまで、ansible-playbook site.yml -i hosts を実行しないでください。

10.1.3. NVMe デバイスおよび HDD デバイスの特定

lsblk を使用して、サーバーに接続されている NVMe デバイスおよび HDD デバイスを特定します。lsblk からの出力例は次のとおりです。

[root@c04-h05-6048r ~]# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda       8:0    0 465.8G  0 disk
├─sda1    8:1    0     4G  0 part
│ └─md1   9:1    0     4G  0 raid1 [SWAP]
├─sda2    8:2    0   512M  0 part
│ └─md0   9:0    0   512M  0 raid1 /boot
└─sda3    8:3    0 461.3G  0 part
  └─md2   9:2    0 461.1G  0 raid1 /
sdb       8:16   0 465.8G  0 disk
├─sdb1    8:17   0     4G  0 part
│ └─md1   9:1    0     4G  0 raid1 [SWAP]
├─sdb2    8:18   0   512M  0 part
│ └─md0   9:0    0   512M  0 raid1 /boot
└─sdb3    8:19   0 461.3G  0 part
  └─md2   9:2    0 461.1G  0 raid1 /
sdc       8:32   0   1.8T  0 disk
sdd       8:48   0   1.8T  0 disk
sde       8:64   0   1.8T  0 disk
sdf       8:80   0   1.8T  0 disk
sdg       8:96   0   1.8T  0 disk
sdh       8:112  0   1.8T  0 disk
sdi       8:128  0   1.8T  0 disk
sdj       8:144  0   1.8T  0 disk
sdk       8:160  0   1.8T  0 disk
sdl       8:176  0   1.8T  0 disk
sdm       8:192  0   1.8T  0 disk
sdn       8:208  0   1.8T  0 disk
sdo       8:224  0   1.8T  0 disk
sdp       8:240  0   1.8T  0 disk
sdq      65:0    0   1.8T  0 disk
sdr      65:16   0   1.8T  0 disk
sds      65:32   0   1.8T  0 disk
sdt      65:48   0   1.8T  0 disk
sdu      65:64   0   1.8T  0 disk
sdv      65:80   0   1.8T  0 disk
sdw      65:96   0   1.8T  0 disk
sdx      65:112  0   1.8T  0 disk
sdy      65:128  0   1.8T  0 disk
sdz      65:144  0   1.8T  0 disk
sdaa     65:160  0   1.8T  0 disk
sdab     65:176  0   1.8T  0 disk
sdac     65:192  0   1.8T  0 disk
sdad     65:208  0   1.8T  0 disk
sdae     65:224  0   1.8T  0 disk
sdaf     65:240  0   1.8T  0 disk
sdag     66:0    0   1.8T  0 disk
sdah     66:16   0   1.8T  0 disk
sdai     66:32   0   1.8T  0 disk
sdaj     66:48   0   1.8T  0 disk
sdak     66:64   0   1.8T  0 disk
sdal     66:80   0   1.8T  0 disk
nvme0n1 259:0    0 745.2G  0 disk
nvme1n1 259:1    0 745.2G  0 disk

この例では、以下の raw ブロックデバイスが使用されます。

NVMe デバイス

  1. /dev/nvme0n1

HDD デバイス

  1. /dev/sdc
  2. /dev/sdd
  3. /dev/sde
  4. /dev/sdf

lv_vars.yaml ファイルは、選択したデバイスで論理ボリュームの作成を設定します。NVMe、NVMe ベースのバケットインデックス、および HDD ベースの OSD にジャーナルを作成します。実際の論理ボリュームの作成は、lv_vars.yaml を読み込む lv-create.yml により開始されます。

このファイルには、一度に参照されている NVMe デバイスが 1 つだけ必要になります。2 つの NVMe デバイスで Ceph を使用する方法は、「2 つの NVMe デバイスの使用」を参照してください。

10.1.4. デバイスを lv_vars.yaml に追加します。

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

    # cd /usr/share/ceph-ansible
  2. 以下の行が含まれるようにファイルを編集します。

    nvme_device: /dev/nvme0n1
    hdd_devices:
      - /dev/sdc
      - /dev/sdd
      - /dev/sde
      - /dev/sdf

10.1.5. Ansible Playbook の lv-create.yml の実行

Playbook lv-create.yml の目的は、単一の NVMe にオブジェクトゲートウェイバケットインデックスおよびジャーナルに論理ボリュームを作成することです。これは、osd_scenario=lvm を使用して行います。Ansible Playbook の lv-create.yml により、複雑な LVM の作成および設定を自動化することで Ceph を簡単に設定することができます。

  1. ストレージデバイスが raw であることを確認します。

    lv-create.yml を実行して、NVMe デバイスおよび HDD デバイスに論理ボリュームを作成する前に、ファイルシステム、GPT、RAID、その他の署名がないことを確認してください。

    生でない場合は、lv-create.yml を実行すると、以下のエラーで失敗する可能性があります。

    device /dev/sdc excluded by a filter
  2. ストレージデバイスの署名(オプション)を消去します。

    デバイスに署名がある場合は、wipefs を使用して消去できます。

    wipefs を使用してデバイスを消去する例を以下に示します。

    [root@c04-h01-6048r ~]# wipefs -a /dev/sdc
    /dev/sdc: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdc: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdc: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sdd
    /dev/sdd: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdd: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdd: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdd: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sde
    /dev/sde: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sde: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sde: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sdf
    /dev/sdf: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdf: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdf: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdf: calling ioclt to re-read partition table: Success
  3. Ansible Playbook の lv-teardown.yml を実行します。

    lv-create.yml を実行する前に、常に lv-teardown.yml を実行します。

    Ansible Playbook の lv-teardown.yml を実行します。

    $ ansible-playbook infrastructure-playbooks/lv-teardown.yml -i hosts
    警告

    Ansible スクリプト lv-teardown.yml を実行する場合は、注意が必要です。データを破棄します。必ず重要なデータのバックアップを作成してください。

  4. Ansible Playbook の lv-create.yml を実行します。

    $ ansible-playbook infrastructure-playbooks/lv-create.yml -i hosts
  5. エラーなしで lv-create.yml が完了すると、次のセクションを続行して、適切に機能していることを確認します。

10.1.6. LVM 設定の確認

  1. lv-created.log を確認します。

    Ansible Playbook の lv-create.yml が正常に完了すると、設定情報が lv-created.log に書き込まれます。この情報は後で group_vars/osds.yml にコピーされます。lv-created.log を開き、以下の例のような情報を探します。

      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme0n1
        journal: ceph-journal-bucket-index-1-nvme0n1
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdc
        data_vg: ceph-hdd-vg-sdc
        journal: ceph-journal-sdc
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdd
        data_vg: ceph-hdd-vg-sdd
        journal: ceph-journal-sdd
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sde
        data_vg: ceph-hdd-vg-sde
        journal: ceph-journal-sde
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdf
        data_vg: ceph-hdd-vg-sdf
        journal: ceph-journal-sdf
        journal_vg: ceph-nvme-vg-nvme0n1
  2. LVM 設定の確認

    NVMe デバイスの例と 4 つの HDD の例を基に、以下の論理ボリューム(LV)を作成する必要があります。

    NVMe(/dev/nvme0n1)上にある HDD ごとにジャーナル論理ボリューム 1 つ

    HDD ごとに 1 つのデータ LV(HDD ごとに 1 つの LV)

    NVMe(/dev/nvme0n1)の 1 つのジャーナルインデックス用のジャーナル LV(/dev/nvme0n1 の 1 つの LV)

    バケットインデックス用に 1 つのデータ LV(/dev/nvme0n1)の 1 つの LV(/dev/nvme0n1 の 1 つの LV)

    LV は、lsblk および lvscan の出力で確認できます。上記の例では、Ceph には 10 LV が必要です。サニティーチェックでは、Ceph LV をカウントして、最低 10 台あることを確認できますが、適切なストレージデバイス(NVMe vs HDD)に適切な LV が作成されていることを確認することが理想的です。

    lsblk からの出力例を以下に示します。

    [root@c04-h01-6048r ~]# lsblk
    NAME                                                               MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                                                                  8:0    0 465.8G  0 disk
    ├─sda1                                                               8:1    0     4G  0 part
    │ └─md1                                                              9:1    0     4G  0 raid1 [SWAP]
    ├─sda2                                                               8:2    0   512M  0 part
    │ └─md0                                                              9:0    0   512M  0 raid1 /boot
    └─sda3                                                               8:3    0 461.3G  0 part
      └─md2                                                              9:2    0 461.1G  0 raid1 /
    sdb                                                                  8:16   0 465.8G  0 disk
    ├─sdb1                                                               8:17   0     4G  0 part
    │ └─md1                                                              9:1    0     4G  0 raid1 [SWAP]
    ├─sdb2                                                               8:18   0   512M  0 part
    │ └─md0                                                              9:0    0   512M  0 raid1 /boot
    └─sdb3                                                               8:19   0 461.3G  0 part
      └─md2                                                              9:2    0 461.1G  0 raid1 /
    sdc                                                                  8:32   0   1.8T  0 disk
    └─ceph--hdd--vg--sdc-ceph--hdd--lv--sdc                            253:6    0   1.8T  0 lvm
    sdd                                                                  8:48   0   1.8T  0 disk
    └─ceph--hdd--vg--sdd-ceph--hdd--lv--sdd                            253:7    0   1.8T  0 lvm
    sde                                                                  8:64   0   1.8T  0 disk
    └─ceph--hdd--vg--sde-ceph--hdd--lv--sde                            253:8    0   1.8T  0 lvm
    sdf                                                                  8:80   0   1.8T  0 disk
    └─ceph--hdd--vg--sdf-ceph--hdd--lv--sdf                            253:9    0   1.8T  0 lvm
    sdg                                                                  8:96   0   1.8T  0 disk
    sdh                                                                  8:112  0   1.8T  0 disk
    sdi                                                                  8:128  0   1.8T  0 disk
    sdj                                                                  8:144  0   1.8T  0 disk
    sdk                                                                  8:160  0   1.8T  0 disk
    sdl                                                                  8:176  0   1.8T  0 disk
    sdm                                                                  8:192  0   1.8T  0 disk
    sdn                                                                  8:208  0   1.8T  0 disk
    sdo                                                                  8:224  0   1.8T  0 disk
    sdp                                                                  8:240  0   1.8T  0 disk
    sdq                                                                 65:0    0   1.8T  0 disk
    sdr                                                                 65:16   0   1.8T  0 disk
    sds                                                                 65:32   0   1.8T  0 disk
    sdt                                                                 65:48   0   1.8T  0 disk
    sdu                                                                 65:64   0   1.8T  0 disk
    sdv                                                                 65:80   0   1.8T  0 disk
    sdw                                                                 65:96   0   1.8T  0 disk
    sdx                                                                 65:112  0   1.8T  0 disk
    sdy                                                                 65:128  0   1.8T  0 disk
    sdz                                                                 65:144  0   1.8T  0 disk
    sdaa                                                                65:160  0   1.8T  0 disk
    sdab                                                                65:176  0   1.8T  0 disk
    sdac                                                                65:192  0   1.8T  0 disk
    sdad                                                                65:208  0   1.8T  0 disk
    sdae                                                                65:224  0   1.8T  0 disk
    sdaf                                                                65:240  0   1.8T  0 disk
    sdag                                                                66:0    0   1.8T  0 disk
    sdah                                                                66:16   0   1.8T  0 disk
    sdai                                                                66:32   0   1.8T  0 disk
    sdaj                                                                66:48   0   1.8T  0 disk
    sdak                                                                66:64   0   1.8T  0 disk
    sdal                                                                66:80   0   1.8T  0 disk
    nvme0n1                                                            259:0    0 745.2G  0 disk
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--bucket--index--1--nvme0n1 253:0    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sdc                       253:1    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sdd                       253:2    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sde                       253:3    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sdf                       253:4    0   5.4G  0 lvm
    └─ceph--nvme--vg--nvme0n1-ceph--bucket--index--1                   253:5    0 718.4G  0 lvm
    nvme1n1                                                            259:1    0 745.2G  0 disk

    以下は、lvscan の出力例です。

    [root@c04-h01-6048r ~]# lvscan
      ACTIVE            '/dev/ceph-hdd-vg-sdf/ceph-hdd-lv-sdf' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sde/ceph-hdd-lv-sde' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sdd/ceph-hdd-lv-sdd' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-bucket-index-1-nvme0n1' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sdc' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sdd' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sde' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sdf' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-bucket-index-1' [<718.36 GiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sdc/ceph-hdd-lv-sdc' [<1.82 TiB] inherit

10.1.7. osds.yml および all.yml Ansible Playbook の編集

  1. 前述の構成情報を lv-created.log から lvm_volumes: 行の下のgroup_vars/osds.yml にコピーします。
  2. osd_scenario:lvm に設定します。

    osd_scenario: lvm
  3. all.yml および osds.ymlosd_objectstore: filestore を設定します。

    osds.yml ファイルは、以下のようになります。

    # Variables here are applicable to all host groups NOT roles
    
    osd_objectstore: filestore
    osd_scenario: lvm
    lvm_volumes:
      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme0n1
        journal: ceph-journal-bucket-index-1-nvme0n1
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdc
        data_vg: ceph-hdd-vg-sdc
        journal: ceph-journal-sdc
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdd
        data_vg: ceph-hdd-vg-sdd
        journal: ceph-journal-sdd
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sde
        data_vg: ceph-hdd-vg-sde
        journal: ceph-journal-sde
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdf
        data_vg: ceph-hdd-vg-sdf
        journal: ceph-journal-sdf
        journal_vg: ceph-nvme-vg-nvme0n1

10.1.8. NVMe 用の Ceph のインストールおよび正常な実行

インストール用に LVM で NVMe を使用するように Ceph を設定したら、インストールします。

  1. Ansible Playbook の site.yml を実行して Ceph をインストールします。

    $ ansible-playbook -v site.yml -i hosts
  2. インストール完了後に Ceph が適切に実行されていることを確認します。

    # ceph -s
    # ceph osd tree

    Ceph が適切に実行されていることを示す ceph -s の出力例:

     # ceph -s
      cluster:
        id:     15d31a8c-3152-4fa2-8c4e-809b750924cd
        health: HEALTH_WARN
                Reduced data availability: 32 pgs inactive
    
      services:
        mon: 3 daemons, quorum b08-h03-r620,b08-h05-r620,b08-h06-r620
        mgr: b08-h03-r620(active), standbys: b08-h05-r620, b08-h06-r620
        osd: 35 osds: 35 up, 35 in
    
      data:
        pools:   4 pools, 32 pgs
        objects: 0 objects, 0 bytes
        usage:   0 kB used, 0 kB / 0 kB avail
        pgs:     100.000% pgs unknown
                 32 unknown

    Ceph が適切に実行されていることを示す ceph osd tree の出力例:

    [root@c04-h01-6048r ~]# ceph osd tree
    ID  CLASS WEIGHT   TYPE NAME              STATUS REWEIGHT PRI-AFF
     -1       55.81212 root default
    -15        7.97316     host c04-h01-6048r
     13   hdd  1.81799         osd.13             up  1.00000 1.00000
     20   hdd  1.81799         osd.20             up  1.00000 1.00000
     26   hdd  1.81799         osd.26             up  1.00000 1.00000
     32   hdd  1.81799         osd.32             up  1.00000 1.00000
      6   ssd  0.70119         osd.6              up  1.00000 1.00000
     -3        7.97316     host c04-h05-6048r
     12   hdd  1.81799         osd.12             up  1.00000 1.00000
     17   hdd  1.81799         osd.17             up  1.00000 1.00000
     23   hdd  1.81799         osd.23             up  1.00000 1.00000
     29   hdd  1.81799         osd.29             up  1.00000 1.00000
      2   ssd  0.70119         osd.2              up  1.00000 1.00000
    -13        7.97316     host c04-h09-6048r
     11   hdd  1.81799         osd.11             up  1.00000 1.00000
     16   hdd  1.81799         osd.16             up  1.00000 1.00000
     22   hdd  1.81799         osd.22             up  1.00000 1.00000
     27   hdd  1.81799         osd.27             up  1.00000 1.00000
      4   ssd  0.70119         osd.4              up  1.00000 1.00000
     -5        7.97316     host c04-h13-6048r
     10   hdd  1.81799         osd.10             up  1.00000 1.00000
     15   hdd  1.81799         osd.15             up  1.00000 1.00000
     21   hdd  1.81799         osd.21             up  1.00000 1.00000
     28   hdd  1.81799         osd.28             up  1.00000 1.00000
      1   ssd  0.70119         osd.1              up  1.00000 1.00000
     -9        7.97316     host c04-h21-6048r
      8   hdd  1.81799         osd.8              up  1.00000 1.00000
     18   hdd  1.81799         osd.18             up  1.00000 1.00000
     25   hdd  1.81799         osd.25             up  1.00000 1.00000
     30   hdd  1.81799         osd.30             up  1.00000 1.00000
      5   ssd  0.70119         osd.5              up  1.00000 1.00000
    -11        7.97316     host c04-h25-6048r
      9   hdd  1.81799         osd.9              up  1.00000 1.00000
     14   hdd  1.81799         osd.14             up  1.00000 1.00000
     33   hdd  1.81799         osd.33             up  1.00000 1.00000
     34   hdd  1.81799         osd.34             up  1.00000 1.00000
      0   ssd  0.70119         osd.0              up  1.00000 1.00000
     -7        7.97316     host c04-h29-6048r
      7   hdd  1.81799         osd.7              up  1.00000 1.00000
     19   hdd  1.81799         osd.19             up  1.00000 1.00000
     24   hdd  1.81799         osd.24             up  1.00000 1.00000
     31   hdd  1.81799         osd.31             up  1.00000 1.00000
      3   ssd  0.70119         osd.3              up  1.00000 1.00000

    Ceph が 1 つの NVMe デバイスを使用するように設定され、Ceph Object Gateway で最適な LVM を設定するようになりました。

10.2. 2 つの NVMe デバイスの使用

以下の手順に従って、2 つの NVMe デバイスを持つ Object Gateway の使用用に Ceph をデプロイします。

10.2.1. 既存 Ceph クラスターをすべてパージする

Ceph がすでに設定されている場合は、これをパージして最初からやり直します。この場合は、purge-cluster.yml という名前の Ansible Playbook ファイルが提供されます。

$ ansible-playbook purge-cluster.yml -i hosts

purge-cluster.yml の使用方法は、『インストールガイド』「Ansible を使用した Ceph クラスターのパージ」を参照してください。

重要

以下の手順で Ceph を再デプロイするサーバーを準備するには、クラスターのパージが十分ではない場合があります。Ceph が使用するストレージデバイス上のファイルシステム、GPT、RAID、またはその他の署名により、問題が発生する場合があります。wipefs を使用して署名を削除する手順は、「Ansible Playbook lv-create.yml の実行」に記載されています。

10.2.2. 通常インストール用のクラスターの設定

NVMe や LVM の考慮点のほかに、クラスターを設定し、通常通りにクラスターを設定しますが、Ansible Playbook を実行する前に停止します。その後、クラスターのインストール設定は、Object Gateway をサポートするための NVMe/LVM の使用を最適に調整されます。このときのみ、Ansible Playbook を実行する必要があります。

通常のインストール用にクラスターを設定するには、『インストールガイド』を参照してください。特に、Ansible ログディレクトリーを作成する手順 9 での「Red Hat Ceph Storage Cluster のインストール」の手順を完了します。ansible-playbook site.yml -i hosts を実行する前に、手順 10 を停止します。

重要

ここから、「Ceph for NVMe のインストールと成功の確認」までの手順がすべて完了するまで、ansible-playbook site.yml -i hosts を実行しないでください。

10.2.3. NVMe デバイスおよび HDD デバイスの特定

lsblk を使用して、サーバーに接続されている NVMe デバイスおよび HDD デバイスを特定します。lsblk からの出力例は次のとおりです。

[root@c04-h09-6048r ~]# lsblk
NAME                           MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                              8:0    0 465.8G  0 disk
├─sda1                           8:1    0   512M  0 part /boot
└─sda2                           8:2    0 465.3G  0 part
  ├─vg_c04--h09--6048r-lv_root 253:0    0 464.8G  0 lvm  /
  └─vg_c04--h09--6048r-lv_swap 253:1    0   512M  0 lvm  [SWAP]
sdb                              8:16   0 465.8G  0 disk
sdc                              8:32   0   1.8T  0 disk
sdd                              8:48   0   1.8T  0 disk
sde                              8:64   0   1.8T  0 disk
sdf                              8:80   0   1.8T  0 disk
sdg                              8:96   0   1.8T  0 disk
sdh                              8:112  0   1.8T  0 disk
sdi                              8:128  0   1.8T  0 disk
sdj                              8:144  0   1.8T  0 disk
sdk                              8:160  0   1.8T  0 disk
sdl                              8:176  0   1.8T  0 disk
sdm                              8:192  0   1.8T  0 disk
sdn                              8:208  0   1.8T  0 disk
sdo                              8:224  0   1.8T  0 disk
sdp                              8:240  0   1.8T  0 disk
sdq                             65:0    0   1.8T  0 disk
sdr                             65:16   0   1.8T  0 disk
sds                             65:32   0   1.8T  0 disk
sdt                             65:48   0   1.8T  0 disk
sdu                             65:64   0   1.8T  0 disk
sdv                             65:80   0   1.8T  0 disk
sdw                             65:96   0   1.8T  0 disk
sdx                             65:112  0   1.8T  0 disk
sdy                             65:128  0   1.8T  0 disk
sdz                             65:144  0   1.8T  0 disk
sdaa                            65:160  0   1.8T  0 disk
sdab                            65:176  0   1.8T  0 disk
sdac                            65:192  0   1.8T  0 disk
sdad                            65:208  0   1.8T  0 disk
sdae                            65:224  0   1.8T  0 disk
sdaf                            65:240  0   1.8T  0 disk
sdag                            66:0    0   1.8T  0 disk
sdah                            66:16   0   1.8T  0 disk
sdai                            66:32   0   1.8T  0 disk
sdaj                            66:48   0   1.8T  0 disk
sdak                            66:64   0   1.8T  0 disk
sdal                            66:80   0   1.8T  0 disk
nvme0n1                        259:1    0 745.2G  0 disk
nvme1n1                        259:0    0 745.2G  0 disk

この例では、以下の raw ブロックデバイスが使用されます。

NVMe デバイス

  1. /dev/nvme0n1
  2. /dev/nvme1n1

HDD デバイス

  1. /dev/sdc
  2. /dev/sdd
  3. /dev/sde
  4. /dev/sdf

lv_vars.yaml ファイルは、選択したデバイスで論理ボリュームの作成を設定します。NVMe、NVMe ベースのバケットインデックス、および HDD ベースの OSD にジャーナルを作成します。実際の論理ボリュームの作成は、lv_vars.yaml を読み込む lv-create.yml により開始されます。

このファイルには、一度に参照されている NVMe デバイスが 1 つだけ必要になります。また、特定の NVMe デバイスに関連付けられる HDD デバイスのみを参照する必要があります。複数の NVMe デバイスが含まれる OSD の場合は、各 NVMe の lv_vars.yaml を編集し、NVMe ごとに lv-create.yml を繰り返し実行します。これについては、以下で説明します。

この例では、lv-create.yml が最初に /dev/nvme0n1 で実行され、その後 /dev/nvme1n1 に再び実行されます。

10.2.4. デバイスを lv_vars.yaml に追加します。

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

    # cd /usr/share/ceph-ansible
  2. root で Ansible Playbook lv_vars.yaml を現在のディレクトリーにコピーします。

    # cp infrastructure-playbooks/vars/lv_vars.yaml .
  3. 最初の実行では、以下の行が含まれるようにファイルを編集します。

    nvme_device: /dev/nvme0n1
    hdd_devices:
      - /dev/sdc
      - /dev/sdd

ジャーナルサイズ、バケットインデックスの数、それらのサイズおよび名前、およびバケットインデックスのジャーナル名はすべて lv_vars.yaml で調整できます。詳細は、ファイル内のコメントを参照してください。

10.2.5. Ansible Playbook の lv-create.yml の実行

Playbook lv-create.yml の目的は、単一の NVMe にオブジェクトゲートウェイバケットインデックスおよびジャーナルに論理ボリュームを作成することです。これは、osd_scenario=non-collocated ではなく osd_scenario=lvm を使用して行います。Ansible Playbook の lv-create.yml により、複雑な LVM の作成および設定を自動化することで Ceph を簡単に設定することができます。

  1. root で、Ansible Playbook lv-create.yml を現在のディレクトリーにコピーします。

    # cp infrastructure-playbooks/lv-create.yml .
  2. ストレージデバイスが raw であることを確認します。

    lv-create.yml を実行して、NVMe デバイスおよび HDD デバイスに論理ボリュームを作成する前に、ファイルシステム、GPT、RAID、その他の署名がないことを確認してください。

    生でない場合には、lv-create.yml を実行すると、以下のエラーで失敗する可能性があります。

    device /dev/sdc excluded by a filter
  3. ストレージデバイス署名の消去(オプション)

    デバイスに署名がある場合は、wipefs を使用して消去できます。

    wipefs を使用してデバイスを消去する例を以下に示します。

    [root@c04-h01-6048r ~]# wipefs -a /dev/sdc
    /dev/sdc: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdc: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdc: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sdd
    /dev/sdd: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdd: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdd: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdd: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sde
    /dev/sde: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sde: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sde: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sde: calling ioclt to re-read partition table: Success
    [root@c04-h01-6048r ~]# wipefs -a /dev/sdf
    /dev/sdf: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdf: 8 bytes were erased at offset 0x1d19ffffe00 (gpt): 45 46 49 20 50 41 52 54
    /dev/sdf: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
    /dev/sdf: calling ioclt to re-read partition table: Success
  4. Ansible Playbook の lv-teardown.yml を実行します。

    lv-create.yml を実行する前に、常に lv-teardown.yml を実行します。

    root で Ansible Playbook lv-teardown.yml を現在のディレクトリーにコピーします。

    # cp infrastructure-playbooks/lv-teardown.yml .

    Ansible Playbook の lv-teardown.yml を実行します。

    $ ansible-playbook lv-teardown.yml -i hosts
    警告

    Ansible スクリプト lv-teardown.yml を実行する場合は、注意が必要です。データを破棄します。必ず重要なデータのバックアップを作成してください。

  5. Ansible Playbook の lv-create.yml を実行します。

    $ ansible-playbook lv-create.yml -i hosts

10.2.6. 優先 NVMe LVM 設定のコピー

  1. lv-created.log の確認

    Ansible Playbook の lv-create.yml が正常に完了すると、設定情報が lv-created.log に書き込まれます。lv-created.log を開き、以下の例のような情報を探します。

      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme0n1
        journal: ceph-journal-bucket-index-1-nvme0n1
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdc
        data_vg: ceph-hdd-vg-sdc
        journal: ceph-journal-sdc
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdd
        data_vg: ceph-hdd-vg-sdd
        journal: ceph-journal-sdd
        journal_vg: ceph-nvme-vg-nvme0n1
  2. この情報を lvm_volumes: の下にある group_vars/osds.yml にコピーします。

10.2.7. NVMe デバイス 2 で Playbook lv-create.yml を実行します。

以下の手順は、2 番目の NVMe デバイスを設定する手順の省略形です。必要に応じて、追加のコンテキストについては、上記の関連手順を参照してください。

  1. lv-vars.yaml を、2 番目の NVMe および関連する HDD を使用するように変更します。

    この例では、lv-vars.yaml に以下のデバイスが設定されています。

    nvme_device: /dev/nvme1n1
    hdd_devices:
      - /dev/sde
      - /dev/sdf
  2. lv-teardown.yml を実行します。

    $ ansible-playbook lv-teardown.yml -i hosts
  3. lv-create.yml を再度実行します。

    $ ansible-playbook lv-create.yml -i hosts

10.2.8. 2 番目の NVMe LVM 設定のコピー

  1. lv-created.log の確認

    Ansible Playbook の lv-create.yml が正常に完了すると、設定情報が lv-created.log に書き込まれます。lv-created.log を開き、以下の例のような情報を探します。

      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme1n1
        journal: ceph-journal-bucket-index-1-nvme1n1
        journal_vg: ceph-nvme-vg-nvme1n1
      - data: ceph-hdd-lv-sde
        data_vg: ceph-hdd-vg-sde
        journal: ceph-journal-sde
        journal_vg: ceph-nvme-vg-nvme1n1
      - data: ceph-hdd-lv-sdf
        data_vg: ceph-hdd-vg-sdf
        journal: ceph-journal-sdf
        journal_vg: ceph-nvme-vg-nvme1n1
  2. この情報を、lvm_volumes: で入力した情報の下にある group_vars/osds.yml にコピーします。

10.2.9. LVM 設定の確認

  1. LVM 設定の確認

    2 つの NVMe デバイスの例と 4 つの HDD の例に基づいて、以下の論理ボリューム(LV)を作成する必要があります。

    HDD ごとに 1 つのジャーナル LV(/dev/nvme0n1 の 2 つの論理ボリューム)/dev/nvme1n1 の 2 つのジャーナル論理ボリューム

    HDD ごとに 1 つのデータ LV(HDD ごとに 1 つの LV)

    バケットインデックスごとに 1 つのジャーナル LV(/dev/nvme0n1 にある 1 つの LV)/dev/nvme1n1)

    バケットインデックスごとに 1 つのデータ LV(/dev/nvme0n1 にある 1 つの LV)/dev/nvme1n1 の 1 つの LV

    LV は、lsblk および lvscan の出力で確認できます。上記の例では、Ceph には twelve LV が必要です。サニティーチェックとして、Ceph LV をカウントして少なくとも twelve があることを確認してくださいが、適切なストレージデバイス(NVMe vs HDD)に適切な LV が作成されていることを確認することが理想的です。

    lsblk からの出力例を以下に示します。

    [root@c04-h01-6048r ~]# lsblk
    NAME                                                               MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
    sda                                                                  8:0    0 465.8G  0 disk
    ├─sda1                                                               8:1    0     4G  0 part
    │ └─md1                                                              9:1    0     4G  0 raid1 [SWAP]
    ├─sda2                                                               8:2    0   512M  0 part
    │ └─md0                                                              9:0    0   512M  0 raid1 /boot
    └─sda3                                                               8:3    0 461.3G  0 part
      └─md2                                                              9:2    0 461.1G  0 raid1 /
    sdb                                                                  8:16   0 465.8G  0 disk
    ├─sdb1                                                               8:17   0     4G  0 part
    │ └─md1                                                              9:1    0     4G  0 raid1 [SWAP]
    ├─sdb2                                                               8:18   0   512M  0 part
    │ └─md0                                                              9:0    0   512M  0 raid1 /boot
    └─sdb3                                                               8:19   0 461.3G  0 part
      └─md2                                                              9:2    0 461.1G  0 raid1 /
    sdc                                                                  8:32   0   1.8T  0 disk
    └─ceph--hdd--vg--sdc-ceph--hdd--lv--sdc                            253:4    0   1.8T  0 lvm
    sdd                                                                  8:48   0   1.8T  0 disk
    └─ceph--hdd--vg--sdd-ceph--hdd--lv--sdd                            253:5    0   1.8T  0 lvm
    sde                                                                  8:64   0   1.8T  0 disk
    └─ceph--hdd--vg--sde-ceph--hdd--lv--sde                            253:10   0   1.8T  0 lvm
    sdf                                                                  8:80   0   1.8T  0 disk
    └─ceph--hdd--vg--sdf-ceph--hdd--lv--sdf                            253:11   0   1.8T  0 lvm
    sdg                                                                  8:96   0   1.8T  0 disk
    sdh                                                                  8:112  0   1.8T  0 disk
    sdi                                                                  8:128  0   1.8T  0 disk
    sdj                                                                  8:144  0   1.8T  0 disk
    sdk                                                                  8:160  0   1.8T  0 disk
    sdl                                                                  8:176  0   1.8T  0 disk
    sdm                                                                  8:192  0   1.8T  0 disk
    sdn                                                                  8:208  0   1.8T  0 disk
    sdo                                                                  8:224  0   1.8T  0 disk
    sdp                                                                  8:240  0   1.8T  0 disk
    sdq                                                                 65:0    0   1.8T  0 disk
    sdr                                                                 65:16   0   1.8T  0 disk
    sds                                                                 65:32   0   1.8T  0 disk
    sdt                                                                 65:48   0   1.8T  0 disk
    sdu                                                                 65:64   0   1.8T  0 disk
    sdv                                                                 65:80   0   1.8T  0 disk
    sdw                                                                 65:96   0   1.8T  0 disk
    sdx                                                                 65:112  0   1.8T  0 disk
    sdy                                                                 65:128  0   1.8T  0 disk
    sdz                                                                 65:144  0   1.8T  0 disk
    sdaa                                                                65:160  0   1.8T  0 disk
    sdab                                                                65:176  0   1.8T  0 disk
    sdac                                                                65:192  0   1.8T  0 disk
    sdad                                                                65:208  0   1.8T  0 disk
    sdae                                                                65:224  0   1.8T  0 disk
    sdaf                                                                65:240  0   1.8T  0 disk
    sdag                                                                66:0    0   1.8T  0 disk
    sdah                                                                66:16   0   1.8T  0 disk
    sdai                                                                66:32   0   1.8T  0 disk
    sdaj                                                                66:48   0   1.8T  0 disk
    sdak                                                                66:64   0   1.8T  0 disk
    sdal                                                                66:80   0   1.8T  0 disk
    nvme0n1                                                            259:0    0 745.2G  0 disk
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--bucket--index--1--nvme0n1 253:0    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sdc                       253:1    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme0n1-ceph--journal--sdd                       253:2    0   5.4G  0 lvm
    └─ceph--nvme--vg--nvme0n1-ceph--bucket--index--1                   253:3    0 729.1G  0 lvm
    nvme1n1                                                            259:1    0 745.2G  0 disk
    ├─ceph--nvme--vg--nvme1n1-ceph--journal--bucket--index--1--nvme1n1 253:6    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme1n1-ceph--journal--sde                       253:7    0   5.4G  0 lvm
    ├─ceph--nvme--vg--nvme1n1-ceph--journal--sdf                       253:8    0   5.4G  0 lvm
    └─ceph--nvme--vg--nvme1n1-ceph--bucket--index--1                   253:9    0 729.1G  0 lvm

    lvscan からの出力例を以下に示します。

    [root@c04-h01-6048r ~]# lvscan
      ACTIVE            '/dev/ceph-hdd-vg-sde/ceph-hdd-lv-sde' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sdc/ceph-hdd-lv-sdc' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sdf/ceph-hdd-lv-sdf' [<1.82 TiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme1n1/ceph-journal-bucket-index-1-nvme1n1' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme1n1/ceph-journal-sde' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme1n1/ceph-journal-sdf' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme1n1/ceph-bucket-index-1' [<729.10 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-bucket-index-1-nvme0n1' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sdc' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-journal-sdd' [5.37 GiB] inherit
      ACTIVE            '/dev/ceph-nvme-vg-nvme0n1/ceph-bucket-index-1' [<729.10 GiB] inherit
      ACTIVE            '/dev/ceph-hdd-vg-sdd/ceph-hdd-lv-sdd' [<1.82 TiB] inherit

10.2.10. osds.yml および all.yml Ansible Playbook の編集

  1. osd_objectstorebluestoreに設定します。

    lv-create.log からの 2 番目の情報セットを osds.yml に追加することに加え、osd_objectstore も osd s.yml と all.yml ファイルの両方で bluestore に設定する必要があります。

    この行は、osds.ymlall.yml の両方で次のようになります。

    osd_objectstore: bluestore
  2. osds.ymlosd_scenariolvm に設定します。

    osds.yml ファイルは以下の例のようになるはずです。

    # Variables here are applicable to all host groups NOT roles
    
    osd_objectstore: bluestore
    osd_scenario: lvm
    lvm_volumes:
      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme0n1
        journal: ceph-journal-bucket-index-1-nvme0n1
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdc
        data_vg: ceph-hdd-vg-sdc
        journal: ceph-journal-sdc
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-hdd-lv-sdd
        data_vg: ceph-hdd-vg-sdd
        journal: ceph-journal-sdd
        journal_vg: ceph-nvme-vg-nvme0n1
      - data: ceph-bucket-index-1
        data_vg: ceph-nvme-vg-nvme1n1
        journal: ceph-journal-bucket-index-1-nvme1n1
        journal_vg: ceph-nvme-vg-nvme1n1
      - data: ceph-hdd-lv-sde
        data_vg: ceph-hdd-vg-sde
        journal: ceph-journal-sde
        journal_vg: ceph-nvme-vg-nvme1n1
      - data: ceph-hdd-lv-sdf
        data_vg: ceph-hdd-vg-sdf
        journal: ceph-journal-sdf
        journal_vg: ceph-nvme-vg-nvme1n1

10.2.11. NVMe 用の Ceph のインストールおよび正常な実行

  1. Ansible Playbook の site.yml を実行して Ceph をインストールします。

    $ ansible-playbook -v site.yml -i hosts
  2. インストール完了後に Ceph が適切に実行されていることを確認します。

    # ceph -s
    # ceph osd tree

    Ceph が適切に実行されていることを示す ceph -s の出力例:

    # ceph -s
      cluster:
        id:     9ba22f4c-b53f-4c49-8c72-220aaf567c2b
        health: HEALTH_WARN
                Reduced data availability: 32 pgs inactive
    
      services:
        mon: 3 daemons, quorum b08-h03-r620,b08-h05-r620,b08-h06-r620
        mgr: b08-h03-r620(active), standbys: b08-h05-r620, b08-h06-r620
        osd: 42 osds: 42 up, 42 in
    
      data:
        pools:   4 pools, 32 pgs
        objects: 0 objects, 0 bytes
        usage:   0 kB used, 0 kB / 0 kB avail
        pgs:     100.000% pgs unknown
                 32 unknown

    Ceph が適切に実行されていることを示す ceph osd tree の出力例:

    [root@c04-h01-6048r ~]# ceph osd tree
    ID  CLASS WEIGHT   TYPE NAME              STATUS REWEIGHT PRI-AFF
     -1       60.86740 root default
     -7        8.69534     host c04-h01-6048r
     10   hdd  1.81799         osd.10             up  1.00000 1.00000
     13   hdd  1.81799         osd.13             up  1.00000 1.00000
     21   hdd  1.81799         osd.21             up  1.00000 1.00000
     27   hdd  1.81799         osd.27             up  1.00000 1.00000
      6   ssd  0.71169         osd.6              up  1.00000 1.00000
     15   ssd  0.71169         osd.15             up  1.00000 1.00000
     -3        8.69534     host c04-h05-6048r
      7   hdd  1.81799         osd.7              up  1.00000 1.00000
     20   hdd  1.81799         osd.20             up  1.00000 1.00000
     29   hdd  1.81799         osd.29             up  1.00000 1.00000
     38   hdd  1.81799         osd.38             up  1.00000 1.00000
      4   ssd  0.71169         osd.4              up  1.00000 1.00000
     25   ssd  0.71169         osd.25             up  1.00000 1.00000
    -22        8.69534     host c04-h09-6048r
     17   hdd  1.81799         osd.17             up  1.00000 1.00000
     31   hdd  1.81799         osd.31             up  1.00000 1.00000
     35   hdd  1.81799         osd.35             up  1.00000 1.00000
     39   hdd  1.81799         osd.39             up  1.00000 1.00000
      5   ssd  0.71169         osd.5              up  1.00000 1.00000
     34   ssd  0.71169         osd.34             up  1.00000 1.00000
     -9        8.69534     host c04-h13-6048r
      8   hdd  1.81799         osd.8              up  1.00000 1.00000
     11   hdd  1.81799         osd.11             up  1.00000 1.00000
     30   hdd  1.81799         osd.30             up  1.00000 1.00000
     32   hdd  1.81799         osd.32             up  1.00000 1.00000
      0   ssd  0.71169         osd.0              up  1.00000 1.00000
     26   ssd  0.71169         osd.26             up  1.00000 1.00000
    -19        8.69534     host c04-h21-6048r
     18   hdd  1.81799         osd.18             up  1.00000 1.00000
     23   hdd  1.81799         osd.23             up  1.00000 1.00000
     36   hdd  1.81799         osd.36             up  1.00000 1.00000
     40   hdd  1.81799         osd.40             up  1.00000 1.00000
      3   ssd  0.71169         osd.3              up  1.00000 1.00000
     33   ssd  0.71169         osd.33             up  1.00000 1.00000
    -16        8.69534     host c04-h25-6048r
     16   hdd  1.81799         osd.16             up  1.00000 1.00000
     22   hdd  1.81799         osd.22             up  1.00000 1.00000
     37   hdd  1.81799         osd.37             up  1.00000 1.00000
     41   hdd  1.81799         osd.41             up  1.00000 1.00000
      1   ssd  0.71169         osd.1              up  1.00000 1.00000
     28   ssd  0.71169         osd.28             up  1.00000 1.00000
     -5        8.69534     host c04-h29-6048r
      9   hdd  1.81799         osd.9              up  1.00000 1.00000
     12   hdd  1.81799         osd.12             up  1.00000 1.00000
     19   hdd  1.81799         osd.19             up  1.00000 1.00000
     24   hdd  1.81799         osd.24             up  1.00000 1.00000
      2   ssd  0.71169         osd.2              up  1.00000 1.00000
     14   ssd  0.71169         osd.14             up  1.00000 1.00000

    Ceph が、Object Storage ゲートウェイに 2 つの NVMe デバイスと LVM を使用するように設定されるようになりました。