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

Red Hat Ceph Storage 4

実稼働環境向けの Ceph Storage クラスターおよび Ceph Object Gateway クラスターのプランニング、設計、デプロイ

Red Hat Ceph Storage Documentation Team

概要

本ガイドでは、クラスターのプランニング、ストレージストラテジーの開発、ゲートウェイおよびロードバランサーの設定、および Ceph Object Gateway の使用について説明します。

第1章 はじめに

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

1.1. 対象

本ガイドは、実稼働環境で Ceph Object Gateway 環境をデプロイするユーザーを対象としています。該当する一般的な Ceph ドキュメントへのリンクを含む実稼働 Ceph Storage クラスターおよび Ceph Object Gateway クラスターおよび Ceph Object Gateway クラスターのプランニング、設計、デプロイを行うための一連のトピックを提供します。

1.2. 前提条件

本ガイドでは、Ceph Storage クラスターおよび Ceph Object Gateway に関する基本的な理解を前提とします。Ceph の経験がない場合には、本ガイドを進める前に、小規模な Ceph テスト環境を設定するか、Ceph Sandbox 環境を使用して Ceph の概念を理解することを検討してください。

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

1.3. 対象範囲

本ガイドでは、Ceph Storage Cluster および実稼働環境用の Ceph Object Gateway を設定する場合に、以下のトピックについて説明します。

注記

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

第2章 クラスターの計画

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

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

2.1. ユースケースの特定

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

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

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

また、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 では、Ceph ストレージプールを作成するレルム、ゾーングループ、およびゾーン名の特定を推奨します。プール名によっては、規則に従ってゾーン名の前に付ける必要があります。

第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 を設定する必要があります。このため、ストレージの密度を考慮することが重要になります。ストレージ密度が高いことは必ずしも良い方法ではありません。

ストレージ密度が高い場合よりもより多くのノードを優先するもう 1 つの要因は、イレイジャーコーディングです。イレイジャーコーディングを使用してオブジェクトを作成し、ノード を最小 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 の書き込みはアトミックなので、all または nothing:Ceph OSD ノードの割り込み不可能な電源供給(UPS)に投資する必要はありません。ただし、Red Hat は、Ceph Monitor ノード用のベアメタルに投資することを推奨します。監視には、同期書き込みレイテンシーの影響を受ける leveldb を使用します。停電により破損が生じる可能性があり、テクニカルサポートがクラスターの状態を復元する必要があります。

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

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

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

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

通常、これらのユースケースには、その他の要素ではドライブ、HBA コントローラー、ネットワークの要件が異なるため、複数の同一ホストを設定して、単一のノード構成でこれらのユースケースをすべて容易に実施することができますが、必ずしも推奨されません。

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

注記

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

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

Ceph Object Gateway で使用する OSD ハードウェアを選択する場合:ユースケースに関係なく、Red Hat は、インデックスプールを保存するための高パフォーマンスドライブが 1 つ以上ある OSD ノードを考慮することを推奨します。これは、バケットに多数のオブジェクトが含まれる場合に特に重要です。

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

インデックスエントリーは約 200 バイトのデータで、leveldb にオブジェクトマップ (omap) として保管されます。これはデータの量はかなりですが、Ceph Object Gateway の一部では、1 つのバケットに数万または数百万のオブジェクトが作成される可能性があります。インデックスプールを高パフォーマンスストレージメディアの CRUSH 階層にマッピングすることで、レイテンシーが短縮されるため、バケットに多数のオブジェクトが含まれる場合にパフォーマンスが大幅に改善されます。

重要

実稼働クラスターでは、OSD ジャーナルとインデックスプールを格納するために、一般的な OSD ノードには 1 つ以上の SSD または NVMe ドライブがあります。インデックスプールは、同じ物理ドライブを使用する場合は個別のパーティションまたは論理ボリュームを使用します。

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 のある SAS ドライブ、コールドストレージのジャーナルが共存する 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 4 設定ガイド』の「スクラブ」セクションを参照してください。

クラスターで 1 日中に負荷が高く、低負荷が夜に遅い場合は、夜間時間にスクラビングを制限することを検討してください。以下に例を示します。

[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 秒)です。クライアントはオブジェクトを読み取る可能性があるため、オブジェクトはすぐにパージされません。Delete large workloads では、この設定ではストレージを過剰に消費したり、削除されたオブジェクトが多数消去したりできます。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 クラスターおよび実稼働環境向けに Ceph Object Gateways を設定するというより困難な点として、効果的なストレージストラテジーを定義することが挙げられます。ストレージストラテジーは、以下の要素で構成されます。

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

7.1. CRUSH 階層の開発

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

重要

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

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

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

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

7.1.1. CRUSH ルートの作成

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

CRUSH 階層の詳細は、『Storage Strategies Guide for Red Hat Ceph Storage 4』の「 {storage-strategies-guid}#crush_hierarchies[CRUSH Hierarchies]」セクションを参照してください。

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

以下の例では、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 はストレージデバイス「class」の概念をサポートしますが、RHCS 2 以前のリリースではサポートしていません。ホストまたはノードを含む RHCS 3 クラスター(NVMe、SSD、HDD など)では、デバイスクラスと共に単一の CRUSH 階層を使用し、異なるストレージクラスを区別します。これにより、論理ホスト名を使用する必要がなくなります。RHCS 2 以前のリリースでは、複数の CRUSH 階層を使用し、デバイスの各クラスに 1 つずつ、CRUSH 階層内のホストまたはノードを区別するために論理ホスト名を使用します。

CRUSH マップでは、ホスト名は一意であり、1 回のみ使用する必要があります。ホストが複数の CRUSH 階層およびユースケースを提供する場合、CRUSH マップは、ホスト名が一度だけ使用されるように、実際のホスト名の代わりに論理ホスト名を使用できます。たとえば、ノードには SSD、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
}
重要

論理ホスト名を使用する場合は、システムの起動時に OSD の起動スクリプトが実際のホスト名を使用せず、CRUSH マップでのデータの特定に失敗しないようにするため、Ceph 設定ファイルに以下の設定のいずれかがあることを確認します。

前述の例のように、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 マップが実際のホスト名ではなく論理ホスト名を使用する場合に、前述の方法の 1 つが使用されていない場合、Ceph Storage クラスターは 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
}
注記

前述の例では、データが 3 回複製された場合、クラスターに同様の数の OSD ノードが含まれるラックが少なくとも 3 つ必要です。

ヒント

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

以下の例は、データプールを保存する CRUSH 階層のルールを示しています。この例では、root の sas-ssd がメインの CRUSH 階層として機能します。サービスルールと同じ 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 ノードを含むラックがクラスターに多く存在し、イレイジャーコーディングチャンクを容易にする必要があります。小規模なクラスターの場合、これは実用的ではない可能性があるため、前述の例では 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 よりもはるかに少なくなります。また、計算機能のステップ 3 で OSD 数が設定されていることを確認してください。

このプールが作成されると、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 内の各オブジェクトのディープコピーを持つため、ユーザーはゾーンに物理的に近いゾーンからコピーにアクセスし、レイテンシーを短縮できます。ただし、セカンダリーゾーンがフェイルオーバーおよび障害復旧のみを目的としている場合は、クラスターをアクティブ/パッシブモードで設定できます。

注記

複数のゾーンを持つゾーングループの使用に対応しています。複数のゾーングループの使用はテクノロジープレビュー機能であるため、実稼働環境ではサポートされません。

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

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

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

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

  • .<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 数は、1 OSD あたりターゲットの PG 数よりもはるかに少なくなります。計算機能のステップ 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 ガイドの「ストレージポリシー」セクションを参照してください。

IOPS 最適化、スループット最適化、または容量最適化などの複数のユースケースをサポートするクラスターの場合、ゾーングループ設定の一連の配置ターゲットと、ゾーン設定内の一連の配置プールが各ストレージポリシーを表します。

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

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

デフォルトでは、Ceph Object Gateway はバケットのオブジェクトをインデックスにマッピングします。これにより、ゲートウェイクライアントはバケット内のオブジェクト一覧を要求することができます。一般的なユースケースでは、ユーザーがバケットを持ち、1 バケットあたりに限られたオブジェクト数を持つクォータを伴いますが、バケットは列挙可能なオブジェクトを保存することができます。バケットが数百万以上のオブジェクトを保存する場合、SSD や NVMe ドライブなど、高パフォーマンスのストレージメディアを使用してそのデータを格納すると、インデックスのパフォーマンスが大幅に向上します。さらに、バケットのシャード化により、パフォーマンスが大幅に向上します。

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

注記

PG per Pool Calculator では、インデックスプールのプールあたりの PG 数を減らすことが推奨されます。ただし、PG 数はサービスプールとして約 PG の 2 倍です。

インデックスプールを作成するには、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 サブドメインには、バケット名を 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 証明書ファイルへのパス。

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>

関連情報

第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 は静的 Web サイトを S3 バケットでホストすることができます。つまり、PHP、サーブレット、データベース、nodejs などのサーバー側のサービスを使用しないサイトです。このアプローチは、各サイトに Web サーバーが含まれる仮想マシンを設定するよりも大幅に容易です。

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

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

ユーザーおよびアプリケーションに Ceph Object Gateway をデプロイする組織では、Ceph Object Gateway ユーザーを作成する代わりに、LDAP(Light-weight Directory Access Protocol)または Microsoft Active Directory(AD)を使用して 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 をデプロイする場合には、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 の実行前に停止します。その後、クラスターのインストール設定は、NVMe/LVM を使用して Object Gateway をサポートするように調整されます。その時点でのみ 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 に配置される HDD ごとに 1 つのジャーナル LV(/dev/nvme0n1 に 4 つの LV)

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

    NVMe に配置されるバケットインデックス用のジャーナル LV 1 つ(/dev/nvme0n1 に 1 つの LV)

    NVMe に配置されるバケットインデックス用のデータ LV 1 つ(/dev/nvme0n1 に 1 つの LV)

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

    [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 Object Gateway に最適な NVMe デバイスと LVM を使用するように、Ceph がセットアップされました。

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 の実行前に停止します。その後、クラスターのインストール設定は、NVMe/LVM を使用して Object Gateway をサポートするように調整されます。その時点でのみ 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 が両方の NVMe デバイスに配置されます(/dev/nvme0n1 には 2 つの LV が /dev/nvme1n1)

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

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

    バケットインデックスごとに 1 つのデータ LV が両方の NVMe デバイスに配置されます(/dev/nvme0n1 に 1 つの LV が /dev/nvme1n1)

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

    [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_objectstorefilestore に設定します。

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

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

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

    # 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-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 が 2 つの NVMe デバイスと LVM を Object Storage Gateway に最適な使用するように設定されています。

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.