実稼働環境向けの Ceph Object Gateway
実稼働環境向けの Ceph Storage クラスターおよび Ceph Object Gateway クラスターのプランニング、設計、およびデプロイ
概要
第1章 はじめに
『実稼働環境向け Ceph Object Gateway』 ガイドへようこそ。本ガイドでは、実稼働環境で使用するための Ceph Storage クラスターおよび Ceph Object Gateway クラスターの構築に関するトピックについて説明します。
1.1. 対象者
本ガイドは、実稼働環境向けに Ceph Object Gateway 環境のデプロイを検討しているユーザーを対象にしています。実稼働環境向けの Ceph Storage クラスターおよび Ceph Object Gateway クラスターのプランニング、設計、およびデプロイを行う一連のトピックを、一般的な Ceph ドキュメントへのリンク(該当する場合)と共に提供します。
1.2. 想定条件
本ガイドでは、読者が Ceph Storage クラスターと 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 ストリームを保存するアプリケーションにとって重要です。スループットが最適化されたクラスターでは、HBA(Host Bus Adapter)コントローラーのスループット特性、および4K ビデオのストリーミングなどの集中型アプリケーションのネットワークスループットを考慮する必要があります。HBA ベースのハードウェアコントローラーでは、オンボードコントローラーと比べて大幅なパフォーマンスの向上が見られます。
- 容量の最適化: 容量を最適化したクラスターは、テラバイトあたりのコストを最小限に抑えられるようにします。容量が最適化されたクラスターでは、あまり高価ではないストレージメディアが使用され、多くの場合、頻繁にはアクセスされないレガシーの経理記録や古い電子メールをアーカイブするなど、アプリケーションで個別の SSD ジャーナルの追加コストが発生しないようにします。
- IOPS の最適化: IOPS 最適化クラスターは、読み取り/書き込みの集約型のワークロードに対して高パフォーマンスを提供することを重視しています。IOPS が最適化されたワークロードは Ceph Object Gateway では一般的ではありませんが、SSD、Flash メモリー、または NVMe CRUSH 階層を使用してサポートされるます。
クラスターの価格とパフォーマンスに大きく影響するため、ハードウェアを考慮する 前 にストレージのユースケースを慎重に検討してください。たとえば、ユースケースが容量の最適化で、ハードウェアがスループット最適化のユースケースにより適したものの場合、ハードウェアが必要以上に高価になってしまいます。逆に、ユースケースがスループットの最適化で、ハードウェアが容量最適化のユースケースにより適したものの場合、クラスターのパフォーマンスが低下します。
また、Ceph Object Gateway はストレージポリシーをサポートするため、前述の すべて のシナリオに対して CRUSH 階層を作成して、API でサポートされているストレージポリシーで呼び出すことができます。詳細は、「 データ配置ストラテジーの作成 」を参照してください。
2.2. データ永続性手法の選択
クラスター設計では、データの永続性手段も考慮する必要があります。Ceph Storage はレプリケーションまたはイレイジャーコーディングのいずれかを使用して、データの永続性を確保します。
レプリケーションでは、ハードウェア障害に備えて、障害ドメインをまたいで 1 つ以上のデータの冗長コピーを保存します。しかし、データの冗長コピーは、規模が大きくなるとコスト高になります。たとえば、1 ペタバイトのデータを 3 つのレプリケーションで保存するには、少なくとも容量が 3 ペタバイトあるストレージクラスターが必要になります。
『Red Hat Ceph Storage 3 ストレージストラテジーガイド』の「 イレイジャーコーディング 」セクションでは、イレイジャーコーディングがデータをデータチャンクおよびコーディングチャンクとして保存する方法を説明しています。データチャンクが失われた場合には、イレイジャーコーディングにより、残りのデータチャンクとコーディングチャンクで失われたデータチャンクを回復できます。イレイジャーコーディングはレプリケーションに比べて大幅に経済的です。たとえば、データチャンク 8 つとコーディングチャンク3 つのイレイジャーコーディングを使用すると、データのコピーが 3 つある状態と同じ冗長性が得られます。ただし、このようなエンコーディングスキームでは、初期のデータ保存量が約 1.5 倍になるのに対し、レプリケーションでは 3 倍になります。
データストレージプール のみ がイレイジャーコーディングを使用できます。サービスデータやバケットインデックスを格納するプールはレプリケーションを使用します。
2.3. マルチサイトデプロイメントの検討
クラスターの設計に関するもう 1 つの重要な点として、クラスターが 1 つのデータセンターサイトにあるか、または複数のデータセンターサイトにまたがるかどうかを判別することです。マルチサイトクラスターは、地理的に分散したフェイルオーバーと、長期的な停電、地震、ハリケーン、洪水、その他の災害からの復旧の恩恵を受けます。さらに、アクティブ/アクティブ構成のマルチサイトクラスターは、クライアントアプリケーションをコンテンツ配信ネットワークの形式で最も近い利用可能なクラスターに転送できます。データを可能な限りクライアントの近く配置することは、4k ビデオのストリーミングなど、スループット集約型のワークロードではますます重要になります。
マルチサイトクラスターの詳細は、Red Hat Ceph Storage 3 の『Object Gateway for Red Hat Enterprise Linux』の「マルチ サイト 」の章を参照してください。
Red Hat は、Ceph Storage プールを作成する「前」に、レルム、ゾーングループ、およびゾーン名を特定することが推奨されます。一部のプール名には、慣例によりゾーン名を先頭に追加する必要があります。
第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 (Solid State Disk) やフラッシュ、NVMe などの高性能なストレージ手段の使用を検討する場合、ネットワークのパフォーマンスの重要性が増しています。
Ceph Storage のもう 1 つの重要な留意点として、クライアントおよびデータのモニター用にフロントサイドまたはパブリックネットワークをサポートし、ハートビート、データのレプリケーション、および復元用にバックサイドまたはクラスターネットワークをサポートすることが挙げられます。つまり、バックエンドネットワークまたはクラスターネットワークには、常に フロントエンドまたはパブリックネットワークよりも多くのネットワークリソースが必要になります。データプールがデータの永続性にレプリケーションまたはイレイジャーコーディングを使用するかどうかに応じて、バックサイドまたはクラスターネットワークのネットワーク要件を適切に定量的に設定する必要があります。
最後に、Ceph をインストールしてテストする前に、ネットワークのスループットを検証します。Ceph のパフォーマンスに関する問題のほとんどは、ネットワークの問題から始まります。Cat-6 ケーブルのねじれや曲がりといった単純なネットワークの問題は、帯域幅の低下につながります。フロント側のネットワークには、最低でも10 GB のイーサネットを使用してください。大規模なクラスターの場合には、バックエンドやクラスターのネットワークに 40GB のイーサネットを使用することを検討してください。あるいは、ネットワークをボンディングするには、LACP モード 4 を使用します。また、特にバックエンドやクラスターのネットワークでは、ジャンボフレーム、最大伝送単位 (MTU) 9000を使用してください。ジャンボフレームを使用する場合には、相互接続ネットワーク機器とノードがすべてジャンボフレームを使用して検証します。ジャンボフレームが完全なネットワークパスで設定されていない場合は、MTU サイズが一致しないとパケットが失われ、Ceph OSD が問題が発生する可能性があります。
その他のリソース
- 詳細は、『 {storage-product} 設定ガイド』の「MTU 値の確認および 設定 」を参照してください。
3.4. 無停電電源装置の検討
Ceph の書き込みは極めて単純(イチかゼロか)なため、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 コントローラー、ネットワーク要件が異なるため、単一ノード構成のこれらのユースケースをすべて促進するために一連の同一ホストを設定することはできますが、必ずしも推奨される方法ではありません。
同じホストを使用して複数の CRUSH 階層を容易に使用するには、CRUSH マップの実際のホスト名ではなく、論理名を使用します。さらに、Ansible などのデプロイメントツールは、すべての OSD をデフォルトの [osds] グループにデプロイするのではなく、各ユースケースのためにグループを検討する必要があります。
通常、高 IOPS、高スループット、または大容量などの単一のユースケースに対応するホストを設定して管理する方が容易です。
3.6. インデックスのメディアの選択
Ceph Object Gateway で使用する OSD ハードウェアを選択する場合（ユースケースに関係なく）、Red Hat は、インデックスプールを保存するための高性能ドライブが少なくとも 1 つある OSD ノードを考慮することを推奨します。これは、バケットに多数のオブジェクトが含まれる場合に特に重要になります。
ホストには、SSD ドライブまたは NVMe ドライブが少なくとも 1 つ必要です。Red Hat のラボテストでは、NVMe ドライブは、同じドライブ上の OSD ジャーナルおよびインデックスプールの両方をサポートするのに十分なパフォーマンスを示していますが、NVMe ドライブの異なるパーティションにはそれぞれ対応します。
インデックスエントリーは約 200 バイトのデータで、leveldb にオブジェクトマップ (omap) として保管されます。これはごくわずかな量のデータですが、Ceph Object Gatewayを使用すると、1 つのバケットに数千万から数億のオブジェクトが含まれる可能性があります。インデックスプールを高性能ストレージメディアの CRUSH 階層にマッピングすることにより、バケットに非常に多くのオブジェクトが含まれている場合に、レイテンシーが短くなり、パフォーマンスが劇的に向上します。
実稼働クラスターでは、OSD ジャーナルとインデックスプールを保存するのに、標準の OSD ノードに SSD または NVMe ドライブが 1 つ以上含まれます。同じ物理ドライブを使用する場合は、別のパーティションまたは論理ボリュームを使用します。
3.7. ノードのモニター用にメディアの選択
Ceph モニターは、同期書き込みレイテンシーの影響を受ける leveldb を使用します。Red Hat は、SSD を使用してモニターデータを保存することを強く推奨します。選択した SSD に連続した書き込みおよびスループットの特徴が十分にあることを確認してください。
第4章 クラスターの設定
実稼働クラスターの初期設定は、概念実証用のシステムの設定と同じです。唯一のマテリアルの違いは、最初のデプロイメントでは実稼働レベルのハードウェアを使用することです。まず、Red Hat Enterprise Linux の『Red Hat Ceph Storage 3 インストールガイド』の「Red Hat Ceph Storage のインストール要件」の章に従い、各ノードに適した手順を実施します。以下のセクションでは、実稼働クラスターに関する追加の説明を提供します。
4.1. ホストの命名
ホストに名前を付ける際には、そのユースケースとパフォーマンスプロファイルについて検討してください。たとえば、ホストがクライアントデータを保存する場合は、ハードウェア構成およびパフォーマンスプロファイルに従って名前を付けることを検討してください。以下に例を示します。
-
data-ssd-1,data-ssd-2 -
hot-storage-1、hot-storage-2 -
sata-1、sata-2 -
sas-ssd-1、sas-ssd-2
命名規則により、クラスターの管理およびハードウェアの問題が発生した際のトラブルシューティングが容易になります。
ホストに複数のユースケース用のハードウェアが含まれている場合（たとえば、ホストに、データ用の SSD、SAS ドライブとジャーナル用の SSD、SATA ドライブとコールドストレージ用の共存するジャーナルが含まれる）、ホストには汎用的な名前を選択します。以下に例を示します。
-
osd-node-1osd-node-2
汎用的なホスト名は、必要に応じて CRUSH 階層で論理ホスト名を使用する場合に拡張できます。以下に例を示します。
-
osd-node-1-ssdosd-node-1-sataosd-node-1-sas-ssdosd-node-1-bucket-index -
osd-node-2-ssdosd-node-2-sataosd-node-2-sas-ssdosd-node-2-bucket-index
詳細は、「 CRUSH マップの論理ホスト名の使用」を 参照してください。
4.2. カーネルのチューニング
実稼働環境用のクラスターでは、一般的にオペレーティングシステムのチューニング (特に制限とメモリー割り当て) が有効です。クラスター内の全ノードに調整が設定されていることを確認します。その他のガイダンスは、Red Hat サポートにお問い合わせください。
4.2.1. OSD 用の空きメモリーの確保
OSD メモリー割り当て要求時にメモリー関連のエラーが不十分なことを防ぐには、OSD ノードの sysctl.conf ファイルで vm.min_free_kbytes オプションを設定します。このオプションは、予約する物理メモリーのサイズを指定します。システムメモリーの量に応じて設定を行うことが推奨されます。以下に例を示します。
RAM が 64 GB の場合は、1 GB を確保します。
vm.min_free_kbytes = 1048576
RAM が 128 GB の場合は、2 GB を確保します。
vm.min_free_kbytes = 2097152
RAM が 256 GB の場合は、3 GB を確保します。
vm.min_free_kbytes = 3145728
4.2.2. ファイル記述子の増加
ファイル記述子が不足すると、Ceph Object Gateway がハングアップする可能性があります。Ceph Object Gateway ノードで /etc/security/limits.conf を変更して、Ceph Object Gateway のファイル記述子を増やします。以下に例を示します。
ceph soft nproc unlimited
4.2.3. 大規模なクラスターでの ulimit の調整
大規模なクラスター(例：1024 OSD 以上)で Ceph の管理コマンドを実行する管理者の場合は、管理コマンドを実行する各ノードに、次の内容の /etc/security/limits.d/50-ceph.conf ファイルを作成します。
<username> soft nproc unlimited
<username> を、Ceph 管理者コマンドを実行する root 以外のアカウントの名前に置き換えます。
RHEL では、root ユーザーの ulimit はすでに「無制限」に設定されています。
4.3. Ansible グループの設定
この手順は、Ansible を使用した Ceph のデプロイでの使用のみを目的としています。ceph-ansible パッケージはすでにデフォルトの osds グループで設定されています。クラスターにユースケースとストレージポリシーが 1 つしかない場合は、Red Hat Enterprise Linux の『 Red Hat Ceph Storage 3 インストールガイド』の「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 倍します。
詳細は、Red Hat Ceph Storage 3 の『設定ガイド』の「 ジャーナル 設定」セクションを参照してください。
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 3 の『設定ガイド』の「 スクラブ 」セクションを参照してください。
クラスターで日中に高負荷が発生し、深夜に低負荷が発生する場合は、スクラブを夜間に制限することを検討してください。以下に例を示します。
[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. filestore_merge_thresholdを設定する
RHCS 3.0 以前のリリースでは、スケーラビリティーを強化するために、filestore_merge_threshold をバージョン 3.1 以降のリリースのデフォルトサイズに増やすことを検討してください。以下に例を示します。
filestore_merge_threshold = -10
4.4.8. ガベージコレクション設定の調整
Ceph Object Gateway は、新規および上書きされたオブジェクトのストレージをすぐに割り当てます。また、マルチパートアップロードの一部もストレージを使用します。
Ceph Object Gateway は、ゲートウェイがバケットインデックスからオブジェクトを削除した後に、Ceph Storage クラスターの削除されたオブジェクトに使用されるストレージ領域をパージします。同様に、ゲートウェイは、複数パートアップロードが完了した後にマルチパートアップロードに関連付けられたデータを削除します。または、設定可能時間枠に対してアップロードが非アクティブになったか、または完了していない場合に、ゲートウェイは削除されます。削除したオブジェクトデータを Ceph Storage クラスターからパージするプロセスは、ガベージコレクションまたは GC と呼ばれています。
ガベージコレクションを待機しているオブジェクトのキューを表示するには、以下を実行します。
# radosgw-admin gc list
ガベッジコレクションは、管理者が Ceph Object Gateway をどのように設定するかによって、負荷が継続的に発生する可能性があるバックグラウンドアクティビティーです。デフォルトでは、Ceph Object Gateway は GC 操作を継続的に実行します。GC 操作は Ceph Object Gateway 操作の通常の部分であるため、特にオブジェクトの削除操作では時間の多いオブジェクトが存在します。
一部のワークロードは、一時的または永続的にガベージコレクションのアクティビティーの回数を上回る場合があります。これは、多くのオブジェクトが短期間保存され、その後に削除される、削除の多いワークロードが特に当てはまります。これらのタイプのワークロードの場合、管理者は、以下の設定パラメーターを使用する他の操作に関連してガベッジコレクション操作の優先度を高くすることができます。
rgw_gc_obj_min_wait 設定は、削除されたオブジェクトのデータをパージする前に最小時間（秒単位）を待機します。デフォルトでは、2 時間に設定されます。負荷が大きいワークロードで、この設定は、過剰なストレージを消費するか、または多数の削除されたオブジェクトをパージする場合があります。このような状況に対処するには、この設定をより短い時間間隔に下げることを検討してください。
rgw_gc_processor_period 構成設定は GC サイクルのランタイムです。つまり、連続して GC スレッドの実行を開始するまでの時間です。GC の実行にこの期間を超える時間がかかる場合、Ceph Object Gateway は GC サイクルを再度実行する前に待機しません。
rgw_gc_max_concurrent_io 設定は、削除されたデータをパージする際にゲートウェイガベッジコレクションスレッドが使用する同時 IO 操作の最大数を指定します。負荷が大きい場合には、この設定を多数の同時 IO 操作に増やすことを検討してください。
rgw_gc_max_trim_chunk 設定は、単一の操作でガベッジコレクターログから削除するキーの最大数を指定します。削除の大きい操作では、各 GC 操作中により多くのオブジェクトがパージされるようにキーの最大数を増やすことを検討してください。
これらのガベージコレクションの設定パラメーターは、Red Hat Ceph Storage 3.3 以降にあります。
テストでは、50% の削除操作や 50% の書き込み操作など、均等にバランスの取れた削除/書き込みワークロードの場合、クラスターは時間的に完全に一杯になります。これは、Ceph Object Gateway のガベージコレクションの削除操作によるペースの保持に失敗するためです。この場合、クラスターのステータスは HEALTH_ERR 状態に切り替わります。並行ガベージコレクションの設定により、クラスターセットのテストが一杯になり、多くのワークロードに役立ちます。実際のクラスターワークロードでは、主にガベージコレクションによりクラスターが一杯になる可能性が高くなります。
管理者は、デプロイ後のランタイム時に Ceph の設定を変更することもできます。詳細は、「実行時に特定の構成設定の設定」を 参照してください。
第5章 Ceph のデプロイ
前提条件と初期チューニングが完了したら、Ceph クラスターをデプロイすることを検討してください。実稼働クラスターをデプロイする場合、Red Hat では、初期モニタークラスターと、active + clean の状態に達するのに十分な OSD ノードを設定することを推奨します。詳細は、Red Hat Enterprise Linux の『Red Hat Ceph Storage 3 インストールガイド』の「Red Hat Ceph Storage クラスター のインストール」セクションを参照してください。
次に、管理ノードに Ceph CLI クライアントをインストールします。詳細は、Red Hat Enterprise Linux の『Red Hat Ceph Storage 3 インストールガイド』の「Ceph コマンドラインインターフェースのインストール」セクションを参照してください。
初期クラスターが実行されたら、以下のセクションの設定を Ceph 設定ファイルに追加することを検討してください。
第6章 クラスターの拡張
初期クラスターが実行し、active+clean の状態になったら、追加の OSD ノードおよび Ceph Object Gateway ノードをクラスターに追加します。各ノードへの「カーネル のチューニング」で説明されている手順を適用し ます。ノードの 追加に関する詳細は、『Red Hat Ceph Storage 3 管理ガイド』の「OSD ノードの追加と削除 」セクションを参照してください。
クラスターに追加された各 OSD ノードについて、クライアントデータを格納するノードの各ドライブごとに OSD をクラスターに追加します。詳細は、『Red Hat Ceph Storage 3 管理ガイド』の「 OSD の追加」セクションを参照してください。Ansible を使用して OSD ノードを追加する場合は、「 Ansible グループの設定 」を参照し、クラスターが複数のユースケースをサポートする場合は OSD ノードを適切なグループに追加します。
各 Ceph Object Gateway ノードに、ゲートウェイインスタンスをインストールします。詳細は、Red Hat Enterprise Linux の 『Red Hat Ceph Storage 3 インストールガイド』の「Ceph Object Gateway のインストール」セクションを参照してください。
クラスターが active+clean 状態に戻ったら、オーバーライド を削除し、「ストレージストラテジー の開発」に進みます。
「ノードの 追加」の手順 3 および「 コマンドラインインターフェースを使用した OSD の追加 」の手順 10 は、「 CRUSH 階層の開発」のトピックで再表示されます。
第7章 ストレージストラテジーの開発
実稼働環境での使用に Ceph Storage クラスターおよび Ceph Object Gateway をセットアップする際の困難な要素の 1 つは、効果的なストレージ計画を定義することです。ストレージ計画には、以下の要素が含まれます。
ストレージストラテジーおよびコマンドラインの使用方法に関する一般的なガイダンスは、『Red Hat Ceph Storage 3 ストレージ戦略 』ガイドを参照してください。
7.1. 想定されるオブジェクト数の検討
Red Hat Ceph Storage 3.1 以降では、追加の引数が ceph osd pool create コマンドに追加されました。新しい引数はストレージプールのオブジェクト数を設定し、この引数は FileStore を使用してストレージプールを作成する場合にのみ機能します。予想されるオブジェクト数を設定すると、大規模なオブジェクト数を見積もるストレージプールにのみ適用されます。プールの作成時に予想されるオブジェクト数を設定すると、配置グループフォルダー分割は即座に行われ、ランタイム時には実行されません。
この動作はすべての Ceph ユースケースに影響を与える可能性がありますが、Object Gateway のユースケースへの影響はより重要です。これは、Object Gateway には多くのオブジェクトが含まれるストレージプールを持つ可能性があるため、default.rgw.buckets.data ストレージプールになります。
[expected-num-objects] 値を設定すると、ランタイムパフォーマンスが向上します。以下に挙げる理由を以下に示します。
-
FileStoreは、オブジェクトをxfsファイルシステムのファイルとして保存します。FileStoreは、これらのオブジェクトファイルをディレクトリーに保存します。オブジェクトカウントが増減するにつれ、FileStoreはディレクトリーを分割またはマージして、オブジェクトを妥当な範囲内に保つことができます。詳細なfilestore_merge_threshold、filestore_split_multipleおよびfilestore_split_rand_factor設定により、この動作が管理されます。 -
FileStoreは分割またはマージ操作時にオブジェクトをあるディレクトリーから別のディレクトリーに移動する必要があるため、FileStoreの分割およびマージ動作にはパフォーマンスに影響があります。FileStoreの使用時に Red Hat Ceph Storage 3.1 以降のリリースでこのパフォーマンスのペナルティーを避けるには、ストレージ管理者がプールを作成するプール BEFORE の予想されるオブジェクト数を予測することが重要です。 -
ゲートウェイクライアントは、ゲートウェイオブジェクトを保存および取得します。このオブジェクトは、1 つ以上の Ceph Storage クラスターオブジェクトとして保存されます。つまり、クライアントオブジェクトは、オブジェクトのストライピングにより 1 つ以上の Ceph Storage クラスターオブジェクトのストレージを呼び出すことができます。たとえば、クライアントが 40 MB のビデオオブジェクトを保存する場合、Ceph Object Gateway はビデオオブジェクトを一連の 10 4 MB のオブジェクトにストライプ化し、クラスター内の異なる OSD に保存します。ストライピングは、並列処理によりパフォーマンスの向上を提供します。高度な
rgw_obj_stripe_size構成設定は、ストライプサイズを制御し、プールの作成後に CANNOT を変更します。
予想されるオブジェクト数を見積もるには、Red Hat Ceph Storage クラスターのストレージ容量でベースとなります。ストレージ容量には、3 つの概算サイズがあります。
- small = 250 TB
- 中 = 1 PB
- Large = 2 PB+
詳細は、『 Red Hat Ceph Storage Hardware Selection Guide 』を参照してください。
OSD のディスクサイズが 4 TB と仮定すると、これらのサイズは以下のように OSD の数を指定します。
- small = 250 TB = 63 OSD
- medium = 1 PB = 256 OSD
- Large = 2 PB+ = 512 OSDs
Red Hat は、以下の式を使用して、ストレージプールごとに予想されるオブジェクト数を決定することを推奨します。
1 m x OSD 数
3 つの概算サイズでは、予想されるオブジェクト数を 63M、256M、および 512M にそれぞれ設定する必要があります。
もう 1 つの考慮事項として、バケットインデックスエントリーは約 200 バイトのデータであり、leveldb にオブジェクトマップ(omap)として保存されます。これは rgw_obj_stripe_size よりも小さいため、バケットインデックスの予想されるオブジェクト数は、クライアントが保存および取得するゲートウェイオブジェクトの数と同じである必要があります。
プールの作成時に、予想されるオブジェクトの数を指定し、filestore_merge_threshold が負の値に設定され、ランタイム時にではなくプールの作成時に配置グループフォルダー分割が実行されるようにします。
ストレージプールが作成されている間、ディレクトリー構造は配置されます。これにはしばらく時間がかかり、ストレージクラスターのリソースを消費します。予想されるオブジェクト数が高すぎる（例： 1 trillion）設定されている場合、OSD の停止タイムアウトが発生する可能性があります。
7.2. 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 ドライブを使用することを強く推奨します。縮小するには、OSD ジャーナルに使用される SSD または NVMe ドライブのインデックス用にパーティションを作成します。さらに、インデックスはバケットシャーディングで設定する必要があります。詳細は、「 インデックスプールの作成 」およびサポートリンクを参照してください。
- 配置プール: 各配置ターゲットの配置プールには、バケットインデックス、データバケット、およびバケットの追加が含まれます。これらのプールは、個別の CRUSH 階層下に分類される場合があります。Ceph Object Gateway は複数のストレージポリシーをサポートすることができるため、ストレージポリシーのバケットプールは異なる CRUSH 階層に関連付け、IOPS 最適化、スループット最適化、容量最適化などの異なるユースケースを反映できます。バケットインデックスプールには、SSD ドライブ、NVMe ドライブなどの高性能記憶媒体にバケットインデックスプールをマップするために、独自の CRUSH 階層を使用 すべきです。
7.2.1. CRUSH ルートの作成
管理ノードのコマンドラインから、各 CRUSH 階層に対して CRUSH マップに CRUSH ルートを作成します。また、潜在的にデータストレージプールを担うことができるサービスプールに、少なくとも 1 つの CRUSH 階層がある 必要があります。そのような SSD、NVMe ドライブなどの高性能ストレージメディアにマッピングされたバケットインデックスプールに、少なくとも 1 つの CRUSH 階層がある はずです。
CRUSH 階層の詳細は、Red Hat Ceph Storage 3 の『ストレージストラテジーガイド』の「{storage-strategies-guid}#crush_hierarchies[CRUSH Hierarchies]」セクションを参照してください。
CRUSH マップを手動で編集するには、Red Hat Ceph Storage 3 の『ストレージストラテジーガイド』の「CRUSH マップの編集」セクションを参照してください。
以下の例では、data0、data1、および data2 という名前のホストは、同じ物理ホストを参照する CRUSH の階層が複数存在するため、data0-sas-ssd、data0-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.2.2. CRUSH マップでの論理ホスト名の使用
RHCS 3 以降のリリースでは、CRUSH はストレージデバイスの「class」の概念をサポートします。これは、RHCS 2 以前のバージョンではサポートされないためです。NVMe、SSD、HDD などの複数のストレージデバイスを含むホストまたはノードを持つ RHCS 3 クラスターでは、デバイスクラスを持つ単一の CRUSH 階層を使用して、ストレージデバイスの異なるクラスを区別します。これにより、論理ホスト名を使用する必要がなくなります。RHCS 2 以前のリリースでは、複数の CRUSH 階層を使用し、デバイスの各クラスに 1 つ、論理ホスト名を使用して CRUSH 階層内のホストまたはノードを区別します。
CRUSH マップでは、ホスト名は一意で、1 回のみ使用する必要があります。ホストが複数の CRUSH 階層とユースケースに対応する場合、CRUSH マップは実際のホスト名の代わりに論理ホスト名を使用して、ホスト名が一度だけ使用されるようにします。たとえば、ノードには、SSD などの複数のドライブ、SSD ジャーナルを備えた SAS ドライブ、および同一ジャーナルを持つ SATA ドライブが複数ある場合があります。RHCS 2 以前のリリースでは、同じホストに複数の CRUSH 階層を作成するには、階層は実際のホスト名の代わりに論理ホスト名を使用する必要があります。そのため、バケット名は CRUSH 階層内で一意となるようにします。たとえば、ホスト名が data2 の場合、CRUSH 階層は、data2-sas-ssd、data2-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 が実際のホスト名にないことを想定し、Ceph Storage Cluster クライアントは OSD とそのデータを見つけません。
7.2.3. CRUSH ルールの作成
デフォルトの CRUSH 階層と同様に、CRUSH マップにはデフォルトの CRUSH ルールも含まれます。
デフォルトの rbd プールはこのルールを使用できます。他のプールを使用して顧客データを保存する場合は、デフォルトのルールを削除しないでください。
CRUSH ルールに関する一般的な情報は、Red Hat Ceph Storage 3 の『ストレージストラテジー』ガイドの「CRUSH ルール」セクションを参照してください。CRUSH マップを手動で編集するには、Red Hat Ceph Storage 3 の『ストレージストラテジー』ガイドの「CRUSH マップの編集」セクションを参照してください。
CRUSH 階層ごとに、CRUSH ルールを作成します。以下の例は、.rgw.root を含むサービスプールを保存する CRUSH 階層のルールを示しています。この例では、ルート sas-ssd がメインの CRUSH 階層として機能します。デフォルトのルールと区別するために、rgw-service という名前を使用します。step take sas-ssd 行は、「 CRUSH ルートの作成」で作成 された sas-ssd ルートを使用するようにプールに指示します。子バケットには、SAS ドライブを備えた OSD と、高スループットのハードウェア構成のジャーナルに SSD ドライブや NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaf の type 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 回複製される 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 chooseleaf の type 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-service と rgw-throughput と区別します。step take index 行は、「 CRUSH ルートの作成」で作成 された インデックス ルートを使用するようにプールに指示します。子バケットには、SSD ドライブ、NVMe ドライブなどの高性能ストレージメディア、または OSD ジャーナルも格納する SSD ドライブまたは NVMe ドライブのパーティションが含まれます。step chooseleaf の type 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.3. ルートプールの作成
Ceph Object Gateway 設定は、レルム、ゾーングループ、ゾーンなど、.rgw.root という名前のプールに保存されます。通常、その名前はゾーン名の前に追加されません。
.rgw.root
Ceph Storage クラスターが実行中の場合には、新しいルールを使用して .rgw.root プールを作成します。PG 数の詳細は、『ストレージストラテジーガイド』の「 Ceph Placement Groups (PGs)per Pool Calculator 」および「配置グループ」の章を参照してください。プールの作成 に関する詳細は、『ストレージストラテジーガイド』の「プールの作成」セクションを 参照してください。
この場合、プールは 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 の数が、calculator のステップ 3 で設定されていることを確認します。
このプールが作成されると、Ceph Object Gateway は設定データをプールに保存できます。
7.4. レルムの作成
Ceph Object Gateway をサポートする Ceph Storage プールは、ゾーングループ内のゾーンに適用されます。デフォルトでは、Ceph Object Gateway はデフォルトのゾーングループおよびゾーンを定義します。
マスターゾーングループおよびゾーンについては、Red Hatは新しいレルム、ゾーングループ、およびゾーンを作成することを推奨します。次に、デフォルトゾーンとそのプールがすでに生成されている場合は削除します。「 マルチサイト 」操作用にクラスターを設定するため、マスターゾーンの 設定をベストプラクティスとして使用します。
- レルムを作成し ます。詳細は、「 レルム 」を参照してください。
- マスターゾーングループを作成し ます。ゾーングループの詳細は、「ゾーングループ」を参照してください。https://access.redhat.com/documentation/ja-jp/red_hat_ceph_storage/3/html-single/object_gateway_guide_for_red_hat_enterprise_linux/#zone_groups
- マスターゾーンを作成し ます。ゾーン の詳細は、「ゾーン」を参照してください。
-
default ゾーングループおよびゾーンを削除し ます。あなたは、デフォルトのプールが作成され、そこにクライアントデータが格納されていない場合は、デフォルトのプールを削除することができます。
.rgw.rootプールは削除 しないでください。 - システムユーザー を作成します。
- 期間を更新し ます。
- Ceph 設定ファイルを更新し ます。
ゲートウェイがプールを手動で作成する可能性があるため、この手順ではゲートウェイの起動手順を省略します。特定の CRUSH ルールおよびデータ永続性手段を指定するには、プールを手動で作成します。
新しいレルム、ゾーングループ、およびゾーンを設定すると、クラスターは、ゾーングループに複数のゾーンがあるマルチサイトクラスターに拡張するための準備が整っています。つまり、クラスターはフェイルオーバーおよび障害復旧用に拡張および設定できます。詳細は、「 マルチサイトでのクラスターの拡張 」を参照してください。
Red Hat Ceph Storage 2 では、複数サイトの設定はデフォルトでアクティブ/アクティブになっています。複数サイトのクラスターをデプロイする場合、ゾーンとその基礎となる Ceph ストレージクラスターは異なる地理的リージョンにある場合があります。各ゾーンには、同じ名前空間内の各オブジェクトのディープコピーがあるため、ユーザーは物理的に最も近いゾーンからコピーにアクセスでき、レイテンシーが短縮されます。ただし、セカンダリーゾーンがフェイルオーバーおよび障害復旧のみを目的としている場合、クラスターはアクティブ/パッシブモードで設定される場合があります。
複数のゾーンを持つゾーングループの使用がサポートされます。複数のゾーングループの使用はテクノロジープレビューとしてのみ提供されており、実稼働環境ではサポートされません。
7.5. サービスプールの作成
Ceph Object Gateway は、さまざまなサービス機能に多くのプールを使用し、バケットインデックス、データ、およびその他の情報を保存するために個別の配置プールセットを使用します。
プールの配置グループをピアリングするのはコンピューティングコストがかかるため、Red Hat は通常、Ceph Object Gateway のサービスプールがデータストレージプールよりもはるかに少ない配置グループを使用することを推奨しています。
サービスプールは、サービス制御、ガベージコレクション、ロギング、ユーザー情報、および使用状況などに関連するオブジェクトを保存します。慣例により、これらのプール名には、プール名の前にゾーン名が付加されます。
-
.<zone-name>.rgw.control: コントロールプール。 -
.<zone-name>.rgw.gc: 削除するオブジェクトのハッシュバケットが含まれるガベージコレクションプール。 -
.<zone-name>.log: ログプールには、すべてのバケット/コンテナーのログおよび create、read、update、および delete などのオブジェクトアクションが含まれます。 -
.<zone-name>.intent-log: 侵入ログプールには、要求が失敗した場合に元に戻す/redo を容易にするためのオブジェクト更新要求のコピーが含まれます。 -
.<zone-name>.users.uid: ユーザー ID プールには、一意のユーザー ID のマップが含まれます。 -
.<zone-name>.users.keys: keys プールには、各ユーザー ID のアクセスキーと秘密鍵が含まれます。 -
.<zone-name>.users.email: メールアドレスには、ユーザー ID に関連付けられたメールアドレスが含まれます。 -
.<zone-name>.users.swift: Swift プールには、ユーザー ID の Swift サブユーザー情報が含まれます。 -
.<zone-name>.usage: 使用状況プールには、ユーザーごとに使用状況のログが含まれます。
ゾーンの取得 手順を実行し、プール名を表示します。
# 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 ルートの 作成」および「 CRUSH ルールの作成 」を参照してください。
PG 数の詳細は、『ストレージストラテジーガイド』の「 Ceph Placement Groups (PGs)per Pool Calculator 」および「配置グループ」の章を参照してください。プールの作成 に関する詳細は、『ストレージストラテジーガイド』の「プールの作成」セクションを 参照してください。
サービスプールの場合、計算結果から推奨される PG 数は、OSD ごとのターゲット PG よりもはるかに少なくなります。計算のステップ 3 で、正しい OSD 数を指定するようにしてください。
通常、.rgw.root プールとサービスプールは同じ CRUSH 階層を使用し、CRUSH ルールの障害ドメインとして少なくとも node を使用する必要があります。.rgw.root プールと同様に、サービスプールは、データの耐久性のために、erasure ではなく、replicated を使用する必要があります。
7.6. データ配置ストラテジーの作成
Ceph Object Gateway には、default-placement と呼ばれるデフォルトのストレージポリシーがあります。クラスターにストレージポリシーが 1 つしかない場合は、default-placement ポリシーで十分です。このデフォルトの配置ポリシーはゾーングループの設定から参照され、ゾーン設定で定義されます。
詳細は、『Red Hat Enterprise Linux の Red Hat Ceph Storage 3 Ceph Object Gateway ガイド』の「ストレージ ポリシー 」セクションを参照してください。
IOPS 最適化、スループットの最適化、容量最適化など、複数のユースケースをサポートするクラスターの場合、ゾーングループ設定の配置ターゲットのセットとゾーン設定の配置プールのセットは各ストレージポリシーを表します。
以下のセクションでは、ストレージポリシーを作成し、それをデフォルトのポリシーに設定する方法を説明します。また、この例では、デフォルトのポリシーがスループット最適化ハードウェアプロファイルを使用することを前提としています。トピックには以下が含まれます。
7.6.1. インデックスプールの作成
デフォルトでは、Ceph Object Gateway はバケットのオブジェクトをインデックスにマッピングするため、ゲートウェイクライアントはバケット内のオブジェクト一覧を他の項目と共に要求できます。一般的なユースケースでは、ユーザーにバケットおよびバケットごとに制限された数のオブジェクトがあるクォータが使用されますが、バケットは列挙可能なオブジェクトを保存できます。バケットが大量のオブジェクトを保存する場合、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 データ永続性メソッド、およびルール名を指定して作成します。FileStore を使用する RHCS 3.1 以降 のリリースでは、「Expected Object Count」を参照し、プールの予想されるオブジェクト数を指定することを検討 してください。以下に例を示します。
# ceph osd pool create .us-west.rgw.buckets.index 64 64 replicated rgw-index [expected-num-objects]
FileStore を使用する Red Hat Ceph Storage 3.1 以降のリリースでは、[expected-num-objects] を予想されるオブジェクト数に置き換えます。rgw-index ルールは、高パフォーマンス SSD、NVMe ドライブ、パーティション、および ラック の CRUSH 階層を CRUSH 障害ドメインとして表します。その他の例については、「インデックスのメディアの選択 」、「CRUSH ルートの 作成」、および「CRUSH ルールの 作成」を参照してください。
バケットが 10 万を超えるオブジェクトを保存する場合は、バケットのオブジェクト数が増える際にインデックスのパフォーマンスが低下しないようにバケットのシャード化を設定します。Red Hat Enterprise Linux の『Ceph Object Gateway ガイド』の「バケットシャード化 の設定」セクションを参照してください。元の構成が適切でなくなった場合のバケットの 再シャード化の詳細については、『Ceph Object Gateway ガイド』の「バケットインデックス の再シャーディング」セクションを参照してください。
7.6.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 データ永続性メソッド、イレイジャーコードプロファイル、およびルール名を指定して実行します。FileStore を使用する RHCS 3.1 以降 のリリースでは、「Expected Object Count」を参照し、プールの予想されるオブジェクト数を指定することを検討 してください。以下に例を示します。
# ceph osd pool create .us-west.rgw.buckets.throughput 8192 8192 erasure 8k3m rgw-throughput [expected-num-objects]
FileStore 3.1 以降のリリースでは、[expected-num-objects] を予想されるオブジェクト数に置き換えます。rgw-throughput ルールは、SSD ジャーナルおよび ホスト を CRUSH 障害ドメインとして持つ SAS ドライブの CRUSH 階層を表します。前述 の例は、「CRUSH ルートの 作成」および「 CRUSH ルールの作成 」を参照してください。
7.6.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.6.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.6.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.6.6. データ配置の概要
クライアント要求を処理する際に、Ceph Object Gateway はデフォルトのストレージポリシーとして新たな throughput-optimized ターゲットを使用します。以下の手順を使用して、マルチサイト構成で異なるゾーンおよびゾーングループに同じターゲットを確立し、必要に応じてプールのゾーン名を置き換えます。
以下の手順を使用して、追加のストレージポリシーを確立します。各ターゲットおよび配置プールのセットの命名は任意です。これには、fast、streaming、cold-storage、またはその他の適切な名前を使用できます。ただし、各セットには、ゾーングループの placement_targets の下に対応するエントリーが必要であり、ターゲットの 1 つは default_placement 設定で参照される 必要があります。また、ゾーンには、ポリシーごとに構成された対応するプールのセットが必要です。
クライアント要求が X-Storage-Policy と別のターゲットを指定しない限り、クライアントリクエストは常にデフォルトのターゲットを使用します。オブジェクトゲートウェイクライアントの使用例については、「コンテナーの 作成」を 参照してください。
第8章 ゲートウェイの設定
実稼働環境用に Ceph Object Gateway を準備する最後のステップでは、Civetweb、ファイアウォールポート、DNS およびロードバランサーを設定する必要があります。トピックには以下が含まれます。
8.1. Civetweb の設定
Ceph Object Gateway の インストール 時に選択した内容に応じて、Ceph 設定ファイルには「レルムの 作成」に関連する手順からの追加の変更を加えた Ceph Object Gateway の各インスタンスのエントリーがすでに含まれています。
デフォルト設定の最も一般的な設定変更は、Ansible が設定したデフォルトのポート 8080 を別のポート (80 など) に変更することです。「 CivetWeb ポートの変更 」を参照してください。
Civetweb に特有の追加設定があります。詳細は、「 Civetweb 設定オプション」 を参照してください。
上書きされる可能性のある追加設定があります。詳細は、「 Object Gateway 設定リファレンス 」を参照してください。
その他のユースケースのセクションは、サードパーティーのコンポーネントで Ceph Object Gateway を使用するための詳細な設定例を提供します。
8.2. ファイアウォールポートの設定
Civetweb のデフォルトポートを変更する場合は、クライアントアクセス用に対応するポートが開いていることを確認してください。詳細は、Red Hat Enterprise Linux の『Red Hat Ceph Storage 3 インストールガイド』の「Red Hat Ceph Storage 用ファイアウォール の設定」セクションを参照してください。
8.3. DNS ワイルドカードの設定
S3 スタイルのサブドメインには、バケット名が CNAME 拡張として組み込まれています。ワイルドカードを DNS に追加して、S3 スタイルのサブドメインを容易にします。詳細は、Red Hat Enterprise Linux の『Red Hat Ceph Storage 3 Ceph Object Gateway ガイド』の「 DNS へのワイルドカードの追加 」セクションを参照してください。
8.4. ロードバランサーの設定
ゾーンには通常、実稼働の負荷を処理し、高可用性を維持するために Ceph Object Gateway のインスタンスが複数含まれます。実稼働クラスターは通常、ロードバランサーを使用してゲートウェイインスタンス間でリクエストを割り当てます。
また、以前の Civetweb バージョンは HTTPS をサポートしません。ロードバランサーは、SSL リクエストを受け入れ、SSL 接続を終了し、HTTP 経由でリクエストをゲートウェイインスタンスに渡すように設定できます。
Ceph Storage は高可用性を維持することを目的としています。このため、Red Hat は HAProxy または keepalived を使用することを推奨しています。詳細は、Red Hat Enterprise Linux の Ceph Object Gateway ガイド の HAProxy/keepalived 設定 セクションを参照してください。
第9章 その他のユースケース
クラスターが稼働したら、追加のユースケースを考慮する必要があります。
9.1. マルチサイトを使用したクラスターの拡張
ストレージ計画を開発する場合、レルムを作成する手順により、クラスターが独自のレルム、マスターゾーングループ、およびマスターゾーンでマルチサイトを使用するように設定されます。
通常の実稼働クラスターには、障害の発生時にバックアップとして機能するための別の物理的な場所に、独自の Ceph Storage クラスターを持つセカンダリーゾーンがあります。セカンダリーゾーンを設定するには、本ガイドの手順を繰り返します。通常、セカンダリーゾーンはマスターゾーンと同じハードウェア設定とサイジングである必要があります。詳細は 、「セカンダリーゾーンの 設定」を参照してください。
セカンダリーゾーンを追加する と、フェイルオーバーおよび災害復旧機能が クラスターに追加されます。
9.2. NFS Ganesha を使用したデータの移行
Ceph Object Gateway および Ceph Storage クラスターがファイルシステムベースのストレージソリューションを置き換える場合は、Ceph の NFS-Ganesha ソリューションを使用してファイルシステムから Ceph Object Gateway にデータを移行することを検討してください。
Red Hat Enterprise Linux の 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 をユーザーおよびアプリケーション用にデプロイしている組織は、Ceph Object Gateway ユーザーを作成する代わりに、Light-weight Directory Access Protocol (LDAP)または Microsoft Active Directory (AD)を使用して Ceph Object Gateway との認証を行うことを選択できます。
LDAP/AD を使用すると、Ceph Object Gateway は組織の LDAP/AD シングルサインオンシステムと統合できます。
詳細は、Red Hat Ceph Storage 3 の LDAP/AD を使用する Ceph Object Gateway ガイド を参照してください。
9.5. OpenStack Keystone を使用するクラスターの設定
OpenStack Swift の代わりに Ceph Object Gateway をデプロイする場合、Ceph Object Gateway ユーザーを作成する代わりに、OpenStack Keystone を使用してユーザーを認証するようにゲートウェイを設定することができます。
詳細は、Red Hat Ceph Storage 3 の『 Keystone を使用した Ceph Object Gateway ユーザー の認証』を参照してください。
第10章 NVMe と LVM の最適な使用
要約
以下の手順では、高速の NVMe ベースの SSD を使用する場合に、Object Gateway の使用に Ceph をデプロイする方法を示しています（これは SATA SSD にも適用されます）。ジャーナルとバケットインデックスは、共に高速ストレージデバイスに置かれるため、1 つのデバイスにすべてのジャーナルがある場合よりもパフォーマンスを向上させることができます。この構成では、
osd_scenarioをlvmに設定する必要があります。2 つの設定例の手順を以下に示します。
- 1 つのバケットインデックスを使用する 1 つの NVMe デバイスおよび 4 つ以上の HDD: 1 つの NVMe デバイス
- 2 つの NVMe デバイスと 2 つのバケットインデックスを使用する少なくとも 4 つのHDD: 2 つの NVMe デバイス
Details
最も基本的な Ceph 設定では、
collocatedのosd_scenario設定を使用します。これにより、1 つのストレージデバイスに OSD データとそのジャーナルが共に保存されます（これは「コロケーション」です）。一般的なサーバー設定には、HDD と SSD の両方が含まれます。HDD は通常 SSD よりも大きいため、ほとんどのストレージ領域を活用するために、共存する構成では HDD が選択され、OSD データとジャーナルの両方をそこに配置します。ただし、ジャーナルはより高速 SSD にあることが理想的です。別のオプションとして、non-collocatedのosd_scenario設定を使用します。これにより、ジャーナル専用のデバイスを設定できるため、OSD データを HDD に、ジャーナルを SSD に配置することができます。OSD データおよびジャーナルの他に、Object Gateway を使用する場合はバケットインデックスをデバイス上に保存する必要があります。この場合、HDD が OSD データを保持し、1 つの SSD がジャーナルを保持し、別の SSD がバケットインデックスを保持するようにCeph が設定されます。これにより、すべてのジャーナルを保持する SSD が飽和し、一方でバケットインデックスを保持する SSD の使用率が低くなり、非常に不均衡な状態が生じる可能性があります。
解決策は、
osd_scenarioをlvmに設定し、論理ボリュームマネージャー (LVM) を使用して、複数の目的で 1 つの SSD デバイスを分割することです。これにより、1 つのデバイスにジャーナルとバケットインデックスを隣りあわせて存在させることができます。最も重要な点として、ジャーナルは複数の SSD 上に存在でき、ジャーナルの集中した IO データの転送を複数のデバイスに分散させることができます。Ceph のインストールに使用される
ceph-ansibleRPM が提供する通常の Ansible Playbook (site.yml、osds.yml など) は、複数の目的で 1 つのデバイスを使用することをサポートしません。今後、通常の Ansible Playbook は複数の目的で 1 つのデバイスの使用をサポートします。その間、SSD 使用率を最適化するのに必要な論理ボリューム (LV) の作成を容易にするために、Playbook の
lv-create.ymlおよびlv-vars.yamlが提供されます。lv-create.ymlを実行すると、site.ymlが正常に実行でき、新たに作成された論理ボリュームが使用されます。重要以下の手順は、新しい BlueStore ストレージバックエンドではなく、FileStore ストレージバックエンドにのみ適用されます。
10.1. 1 つの NVMe デバイスの使用
1 つの NVMe デバイスで Object Gateway を使用するために Ceph をデプロイするには、以下の手順に従います。
10.1.1. 既存の Ceph クラスターのパージ
Ceph がすでに設定されている場合は、最初からやり直すために削除してください。この場合は、purge-cluster.yml という名前の Ansible Playbook ファイルが提供されます。
$ ansible-playbook purge-cluster.yml
purge-cluster.yml の使用方法は、『Installation Guide for Red Hat Enterprise Linux 』の 「 Installation Guide for Red Hat Enterprise Linux or Installation Guide for Ubuntu for Ubuntu」を参照してください。
以下の手順に従って Ceph を再デプロイするためにサーバーを準備するには、クラスターのパージだけでは十分でない可能性があります。Ceph が使用するストレージデバイス上のファイルシステム、GPT、RAID、またはその他の署名があると問題が発生する可能性があります。wipefs を使用して署名を削除する手順は、「Ansible Playbook lv-create.yml の実行」に記載されています。
10.1.2. 通常インストール用のクラスター設定
NVMe や LVM の考慮点以外に設定を行い、通常通り、ansible-playbook site.yml を実行する前に停止するようにクラスターを設定します。その後、クラスターのインストール設定は、Object Gateway をサポートするために、特に NVMe/LVM の使用を最適化するために調整されます。その間のみ ansible-playbook site.yml を実行します。
通常のインストール用にクラスターを設定するには、選択した Linux ディストリビューションに応じて、『 Installation Guide for Red Hat Enterprise Linux or Installation Guide for Ubuntu 』を参照してください。特に、Ansible ログディレクトリーを作成する手順 9 で の「Red Hat Ceph Storage Cluster のインストール 」の手順を完了します。ansible-playbook site.yml の実行時に、手順 10 の前に停止します。
この後に、Ceph for NVMe をインストールして Success が完了するまで ansible-playbook site.yml を実行し ないでください。
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
この例では、以下の未処理のブロックデバイスが使用されます。
NVMe デバイス
-
/dev/nvme0n1
HDD デバイス
-
/dev/sdc -
/dev/sdd -
/dev/sde -
/dev/sdf
lv_vars.yaml ファイルは、選択したデバイスで論理ボリュームの作成を設定します。NVMe、NVMe ベースのバケットインデックス、および HDD ベースの OSD にジャーナルを作成します。実際の論理ボリュームの作成は、lv_vars.yaml を読み込む lv-create.yml により開始されます。
このファイルでは、1 度に 1 つの NVMe デバイスのみが参照される必要があります。2 つの NVMe デバイスで Ceph を最適に使用する方法は、「2 つの NVMe デバイスの使用」を参照してください。
10.1.4. lv_vars.yaml へのデバイスの追加
rootとして/usr/share/ceph-ansible/ディレクトリーに移動します。# cd /usr/share/ceph-ansible
rootで Ansible Playbooklv_vars.yamlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/vars/lv_vars.yaml .
以下の行が含まれるようにファイルを編集します。
nvme_device: /dev/nvme0n1 hdd_devices: - /dev/sdc - /dev/sdd - /dev/sde - /dev/sdf
10.1.5. lv-create.yml Ansible Playbook の実行
Playbook lv-create.yml の目的は、単一の NVMe にオブジェクトゲートウェイバケットインデックスおよびジャーナルに論理ボリュームを作成することです。これは、osd_scenario=non-collocated ではなく osd_scenario=lvm を使用して行います。Ansible Playbook の lv-create.yml により、複雑な LVM の作成および設定を自動化することで Ceph を簡単に設定することができます。
rootで、Ansible Playbooklv-create.ymlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/lv-create.yml .
ストレージデバイスが未処理であることを確認します。
lv-create.ymlを実行して、NVMe デバイスおよび HDD デバイスに論理ボリュームを作成する前に、ファイルシステム、GPT、RAID、その他の署名がないことを確認してください。生でない場合には、
lv-create.ymlを実行すると、以下のエラーで失敗する可能性があります。device /dev/sdc excluded by a filter
ストレージデバイスの署名を消去します（オプション）。
デバイスに署名がある場合は、
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
Ansible Playbook の
lv-teardown.ymlを実行します。lv-create.ymlを実行する前に、常にlv-teardown.ymlを実行します。rootで Ansible Playbooklv-teardown.ymlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/lv-teardown.yml .
Ansible Playbook の
lv-teardown.ymlを実行します。$ ansible-playbook lv-teardown.yml
警告Ansible スクリプト
lv-teardown.ymlを実行する場合は、注意が必要です。データが破棄されます。重要なデータのバックアップを作成してください。Ansible Playbook の
lv-create.ymlを実行します。$ ansible-playbook lv-create.yml
-
エラーなしで
lv-create.ymlが完了すると、次のセクションを続行して、適切に機能していることを確認します。
10.1.6. LVM 設定の確認
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-nvme0n1LVM 設定を確認します。
1 つの NVMe デバイスと 4 つの HDD の例に基づいて、以下の論理ボリューム(LV)を作成する必要があります。
HDD ごとに 1 つのジャーナル LV を NVMe に配置（/dev/nvme0n1 に 4 つの LV）
HDD ごとに 1 つのデータ LV を各 HDD に配置（HDD ごとに 1 つの LV）
バケットインデックスごとに 1 つのジャーナル LV を NVMe に配置（/dev/nvme0n1 に 1 つの LV）
バケットインデックスごとに 1 つのデータ LV を NVMe に配置（/dev/nvme0n1 に 1 つの LV）
LV は、
lsblkおよびlvscanの出力で確認できます。上記の例では、Ceph に 10 の LV があるはずです。簡単な正常性チェックとして、Ceph LV をカウントして、少なくとも 10 個あることを確認できますが、理想的には、適切な数の LV が正しいストレージデバイス (NVMe / HDD) に作成されたことを確認してください。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 Playbooks の編集
-
前述の構成情報を
lv-created.logからlvm_volumes:行の下のgroup_vars/osds.ymlにコピーします。 osd_scenario:をlvmに設定します。osd_scenario: lvm
all.ymlおよびosds.ymlのosd_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 のインストールおよび正常な実行の確認
システムが NVMe と LVM を最適に使用するように Ceph を設定したら、これをインストールします。
Ansible Playbook の
site.ymlを実行して Ceph をインストールします。$ ansible-playbook -v -i hosts site.yml
インストールの完了後に、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 unknownCeph が適切に実行されていることを示す
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 Storage Gateway に最適な NVMe デバイスおよび 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
purge-cluster.yml の使用方法は、『Installation Guide for Red Hat Enterprise Linux 』の 「 Installation Guide for Red Hat Enterprise Linux or Installation Guide for Ubuntu for Ubuntu」を参照してください。
以下の手順に従って Ceph を再デプロイするためにサーバーを準備するには、クラスターのパージだけでは十分でない可能性があります。Ceph が使用するストレージデバイス上のファイルシステム、GPT、RAID、またはその他の署名があると問題が発生する可能性があります。wipefs を使用して署名を削除する手順は、「Ansible Playbook lv-create.yml の実行」に記載されています。
10.2.2. 通常インストール用のクラスター設定
NVMe や LVM の考慮点以外に設定を行い、通常通り、ansible-playbook site.yml を実行する前に停止するようにクラスターを設定します。その後、クラスターのインストール設定は、Object Gateway をサポートするために、特に NVMe/LVM の使用を最適化するために調整されます。その間のみ ansible-playbook site.yml を実行します。
通常のインストール用にクラスターを設定するには、選択した Linux ディストリビューションに応じて、『 Installation Guide for Red Hat Enterprise Linux or Installation Guide for Ubuntu 』を参照してください。特に、Ansible ログディレクトリーを作成する手順 9 で の「Red Hat Ceph Storage Cluster のインストール 」の手順を完了します。ansible-playbook site.yml の実行時に、手順 10 の前に停止します。
この後に、Ceph for NVMe をインストールして Success が完了するまで ansible-playbook site.yml を実行し ないでください。
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
この例では、以下の未処理のブロックデバイスが使用されます。
NVMe デバイス
-
/dev/nvme0n1 -
/dev/nvme1n1
HDD デバイス
-
/dev/sdc -
/dev/sdd -
/dev/sde -
/dev/sdf
lv_vars.yaml ファイルは、選択したデバイスで論理ボリュームの作成を設定します。NVMe、NVMe ベースのバケットインデックス、および HDD ベースの OSD にジャーナルを作成します。実際の論理ボリュームの作成は、lv_vars.yaml を読み込む lv-create.yml により開始されます。
このファイルでは、1 度に 1 つの NVMe デバイスのみが参照される必要があります。また、特定の 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 へのデバイスの追加
rootとして/usr/share/ceph-ansible/ディレクトリーに移動します。# cd /usr/share/ceph-ansible
rootで Ansible Playbooklv_vars.yamlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/vars/lv_vars.yaml .
最初の実行では、次の行が含まれるようにファイルを編集します。
nvme_device: /dev/nvme0n1 hdd_devices: - /dev/sdc - /dev/sdd
ジャーナルサイズ、バケットインデックスの数、それらのサイズおよび名前、およびバケットインデックスのジャーナル名はすべて lv_vars.yaml で調整できます。詳細は、ファイル内のコメントを参照してください。
10.2.5. lv-create.yml Ansible Playbook の実行
Playbook lv-create.yml の目的は、単一の NVMe にオブジェクトゲートウェイバケットインデックスおよびジャーナルに論理ボリュームを作成することです。これは、osd_scenario=non-collocated ではなく osd_scenario=lvm を使用して行います。Ansible Playbook の lv-create.yml により、複雑な LVM の作成および設定を自動化することで Ceph を簡単に設定することができます。
rootで、Ansible Playbooklv-create.ymlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/lv-create.yml .
ストレージデバイスが未処理であることを確認します。
lv-create.ymlを実行して、NVMe デバイスおよび HDD デバイスに論理ボリュームを作成する前に、ファイルシステム、GPT、RAID、その他の署名がないことを確認してください。生でない場合には、
lv-create.ymlを実行すると、以下のエラーで失敗する可能性があります。device /dev/sdc excluded by a filter
ストレージデバイスの署名を消去します（オプション）。
デバイスに署名がある場合は、
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
Ansible Playbook の
lv-teardown.ymlを実行します。lv-create.ymlを実行する前に、常にlv-teardown.ymlを実行します。rootで Ansible Playbooklv-teardown.ymlを現在のディレクトリーにコピーします。# cp infrastructure-playbooks/lv-teardown.yml .
Ansible Playbook の
lv-teardown.ymlを実行します。$ ansible-playbook lv-teardown.yml
警告Ansible スクリプト
lv-teardown.ymlを実行する場合は、注意が必要です。データが破棄されます。重要なデータのバックアップを作成してください。Ansible Playbook の
lv-create.ymlを実行します。$ ansible-playbook lv-create.yml
10.2.6. 最初の NVMe LVM 設定のコピー
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-
この情報を
lvm_volumes:の下にあるgroup_vars/osds.ymlにコピーします。
10.2.7. NVMe デバイス 2 で Playbook lv-create.yml を実行します。
以下の手順は、2 番目の NVMe デバイスを設定する省略手順です。詳細なコンテキストが必要な場合は、上記の関連手順を参照してください。
lv-vars.yamlを、2 番目の NVMe および関連する HDD を使用するように変更します。この例では、
lv-vars.yamlに以下のデバイスが設定されています。nvme_device: /dev/nvme1n1 hdd_devices: - /dev/sde - /dev/sdf
lv-teardown.ymlを実行します。$ ansible-playbook lv-teardown.yml
lv-create.ymlを再度実行します。$ ansible-playbook lv-create.yml
10.2.8. 2 番目の NVMe LVM 設定のコピー
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-
この情報を、
lvm_volumes:で入力した情報の下にあるgroup_vars/osds.ymlにコピーします。
10.2.9. LVM 設定の確認
LVM 設定の確認
2 つの NVMe デバイスと 4 つの HDD の例に基づいて、以下の論理ボリューム(LV)を作成する必要があります。
HDD ごとに 1 つのジャーナル LV を両方の NVMe デバイスに配置（/dev/nvme0n1 に 2 つの LVs、/dev/nvme1n1 に 2 つの LV）。
HDD ごとに 1 つのデータ LV を各 HDD に配置（HDD ごとに 1 つの LV）
バケットインデックスごとに 1 つのジャーナル LV を NVMe に配置（/dev/nvme0n1 に 1 つの LV、/dev/nvme1n1 に 1 つの LV）。
バケットインデックスごとに 1 つのデータ LV を両方の NVMe デバイスに配置（/dev/nvme0n1 に 1 つの LV、/dev/nvme1n1 に 1 つの LV）。
LV は、
lsblkおよびlvscanの出力で確認できます。上記の例では、Ceph に 12 の LV があるはずです。簡単な正常性チェックとして、Ceph LV をカウントして、少なくとも 12 個あることを確認できますが、理想的には、適切な数の LV が正しいストレージデバイス (NVMe / HDD) に作成されたことを確認してください。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 Playbooks の編集
osd_objectstoreをfilestoreに設定します。lv-create.logからの 2 番目の情報セットをosds.ymlに追加する他に、osd_objectstoreをosds.ymlファイルとall.ymlファイルの両方でfilestoreに設定する必要があります。この行は、
osds.ymlとall.ymlの両方で次のようになります。osd_objectstore: filestore
osds.ymlのosd_scenarioをlvmに設定します。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-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 のインストールおよび正常な実行の確認
Ansible Playbook の
site.ymlを実行して Ceph をインストールします。$ ansible-playbook -v -i hosts site.yml
インストールの完了後に、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 unknownCeph が適切に実行されていることを示す
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
Object Storage Gateway 用に、2 つの NVMe デバイスおよび LVM を最適に使用するように Ceph が設定されました。
