Menu Close

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

Red Hat Ceph Storage 4

Ceph StorageクラスターとCeph Object Gatewayクラスターを本番用に計画、設計、展開する。

概要

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

第1章 はじめに

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

1.1. オーディエンス

このガイドは、本番用のCeph Object Gateway環境を導入する予定の方を対象としています。本番用のCeph StorageクラスターおよびCeph Object Gatewayクラスターの計画、設計、および導入に関する一連のトピックを順に説明し、必要に応じてCephの一般文書へのリンクも掲載しています。

1.2. 前提条件

このガイドは、読者がCeph Storage ClusterとCeph Object Gatewayの基本的な知識を持っていることを前提としています。Cephの経験がない読者の方は、このガイドを読み進める前に、小規模なCephテスト環境を設定するか、Ceph Sandbox環境を使用してCephの概念に慣れることを検討してください。

このガイドでは、同じゾーンにある1つの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(Host Bus Adapter)コントローラのスループット特性や、4Kビデオのストリーミングなどの高負荷アプリケーションのネットワークスループットを考慮する必要があります。HBAベースのハードウェアコントローラは、オンボードのコントローラに比べて大幅にパフォーマンスが向上します。
  • 容量の最適化: 容量を最適化したクラスターは、テラバイトあたりのコストを最小限に抑えられるようにします。容量が最適化されたクラスターでは、最も安価なストレージメディアが使用されることが多く、アクセス頻度の低いレガシーな財務記録や古い電子メールなどをアーカイブするような用途では、個別のSSDジャーナルの追加費用を避けることができます。
  • IOPS の最適化: IOPS 最適化クラスターは、読み取り/書き込みの集約型のワークロードに対して高パフォーマンスを提供することを重視しています。Ceph Object Gatewaysでは、IOPSに最適化されたワークロードはそれほど一般的ではありませんが、SSD、フラッシュメモリ、NVMeのCRUSH階層でサポートすることができます。

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

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

2.2. データ・デュラビリティ・メソッドの選択

クラスタ設計では、データの耐久性戦略も考慮する必要があります。Ceph Storageは、データの耐久性を確保するために、レプリケーションまたは消去コーディングを使用します。

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

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

注記

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

2.3. マルチサイト展開の検討

クラスタを設計する際のもう一つの重要なポイントは、クラスタを1つのデータセンターサイトに設置するか、複数のデータセンターサイトにまたがるように設置するかを決めることです。マルチサイトクラスターでは、地理的に分散したフェイルオーバーや、長期にわたる停電、地震、ハリケーン、洪水などの災害時のリカバリーが可能です。また、マルチサイトのクラスターをアクティブ・アクティブに構成すると、コンテンツ・デリバリー・ネットワークのように、クライアント・アプリケーションを利用可能な最も近いクラスターに誘導することができます。データをできるだけクライアントの近くに配置することは、4Kビデオのストリーミングなど、スループットを必要とするワークロードではますます重要になっています。

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

注記

Red Hatでは、Ceph Storageプールを作成する前に、レルム、ゾーングループ、ゾーン名を特定することをお勧めします。いくつかのプール名は、慣習上、ゾーン名の前に付けなければなりません。

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

Ceph StorageクラスターやCeph Object Gatewayクラスターを本番環境で構築する際には、ハードウェアの検討が重要です。ハイレベルな検討事項は以下の通りです。

重要

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

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

クラスタを設計する上で最も重要な要素の一つは、必要なストレージの容量(サイジング)を決めることです。Ceph Storageは、ペタバイト以上の規模に対応できるように設計されています。以下の例は、Cephストレージクラスターの一般的なサイズです。

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

サイジングには、現在のニーズと近い将来のニーズを含める必要があります。ゲートウェイ・クライアントが新しいデータをクラスタに追加する速度を考慮します。それはユースケースごとに異なるかもしれません。例えば、CCTVビデオや4Kビデオ、医療用画像の記録は、金融市場のデータのようにストレージをあまり必要としない情報に比べて、はるかに早く大量のデータを追加することができます。さらに、レプリケーションやイレイジャーコーディングなどの データ永続性 の方法が、必要なストレージメディアに大きく影響することに注意してください。

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

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

クラスタ設計のもう一つの重要な点は、ストレージ密度です。一般的にクラスターは、複製、バックフィル、リカバリーの際に適切なパフォーマンスを確保するため、少なくとも10ノードにデータを保存する必要があります。ノードが故障しても、クラスター内に10台以上のノードがあれば、データの10%だけが生き残ったノードに移動するだけで済みます。ノードの数が大幅に減ると、データの割合が増えて生き残ったノードに移動しなければなりません。さらに、クラスターがデータを書き込むことができるように、ノードの障害に対応するために full_ratio および near_full_ratio を設定する必要があります。そのためには、ストレージの密度を考慮することが重要です。記憶密度が高ければ良いというわけではありません。

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

また、ホットスワップも重要な検討事項です。ほとんどの最新のサーバーは、ドライブのホットスワップをサポートしています。ただし、ハードウェアの構成によっては、ドライブを交換するために複数のドライブを取り外す必要があります。Red Hat では、このような構成を避けることを推奨しています。故障したディスクを交換する際に、必要以上の OSD が停止する可能性があるからです。

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

Ceph Storageの大きな利点は、容量、IOPS、スループットをそれぞれ独立して拡張できることです。クラウドストレージソリューションの重要な点は、クラスターがストレージ容量を使い果たすよりもずっと前に、ネットワークのレイテンシーなどによってIOPSが不足したり、帯域の制約によってスループットが不足したりすることです。つまり、価格や性能の目標を達成するためには、ネットワークのハードウェア構成がユースケースをサポートする必要がある。SSD、フラッシュ、NVMeなどの高性能なストレージの使用を検討する際には、ネットワークパフォーマンスの重要性が増しています。

Ceph Storageのもう一つの重要な点は、クライアントとモニターデータ用のフロントサイドまたはパブリックネットワークと、ハートビート、データレプリケーション、リカバリ用のバックサイドまたはクラスタネットワークをサポートしていることです。つまり、バックエンドネットワークまたはクラスターネットワークには、常に フロントエンドまたはパブリックネットワークよりも多くのネットワークリソースが必要になります。データプールがデータの耐久性のためにレプリケーションを使用するか、消去コーディングを使用するかに応じて、バックサイドまたはクラスタネットワークのネットワーク要件を適切に定量化する必要があります。

最後に、Cephをインストールしてテストする前に、ネットワークのスループットを確認します。Ceph のパフォーマンスに関する問題のほとんどは、ネットワークの問題から始まります。Cat-6 ケーブルのねじれや曲がりといった単純なネットワークの問題は、帯域幅の低下につながります。フロント側のネットワークには、最低でも10Gbeを使用してください。大規模なクラスターでは、バックエンドやクラスターのネットワークに40Gbeの使用を検討してください。また、LACPモード4でネットワークを結合することもできます。また、特にバックエンドやクラスターのネットワークでは、ジャンボフレーム(MTU 9000)を使用してください。

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

Cephの書き込みはアトミックなので、Ceph OSDノードに無停電電源装置(UPS)を導入する必要はありません。しかし、Red HatはCeph MonitorノードにUPSを導入することを推奨しています。監視には、同期書き込みレイテンシーの影響を受ける leveldb を使用します。停電により破損が発生し、クラスターの状態を回復するために技術サポートが必要になることがあります。

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

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

Ceph Storageの大きなメリットは、多くのユースケースに対応できるように構成できることです。一般的にレッドハットは、特定の使用目的のためにOSDホストを同じように構成することを推奨しています。Ceph Storageクラスターの主な使用例は次の3つです。

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

これらのユースケースでは、ドライブ、HBAコントローラ、ネットワークなどの要件が異なるため、1つのノード構成でこれらのユースケースをすべて実現するために、一連の同一のホストを構成することは可能ですが、必ずしもお勧めできません。

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

注記

一般的には、高IOPS、高スループット、大容量など、単一のユースケースに対応するホストを構成・管理する方が簡単です。

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

Ceph Object Gatewayで使用するOSDハードウェアを選択する際には、ユースケースにかかわらず、インデックスプールを保存するための高性能ドライブを少なくとも1台備えたOSDノードが必要となります。これは、バケットに多数のオブジェクトが含まれている場合に特に重要です。

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

注記

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

インデックスエントリーは約 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. カーネルのチューニング

本番クラスのクラスターでは、OSのチューニング、特に制限やメモリの割り当てなどが有効です。調整がクラスタ内のすべてのノードに設定されていることを確認します。その他のガイダンスについては、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 の調整

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

<username>       soft    nproc     unlimited

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

注記

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

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を乗じることになります。

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

4.4.2. 埋め戻しとリカバリーの設定調整

I/Oは埋め戻し作業と復旧作業の両方で悪影響を受け、パフォーマンスの低下とエンドユーザーの不満につながります。クラスタの拡張またはリカバリ時のI/O需要に対応するために、Ceph Configurationファイルで以下のオプションと値を設定します。

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

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

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

[global]
osd_map_message_max=10

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

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

4.4.4. スクラビングの調整

デフォルトでは、Cephはライトスクラビングを毎日、ディープスクラビングを毎週行います。ライトスクラビングでは、オブジェクトのサイズとチェックサムをチェックし、PGが同じオブジェクトデータを保存していることを確認します。ディスクセクタは、オブジェクトサイズやチェックサムに関係なく、時間の経過とともに不良になることがあります。ディープスクラビングは、オブジェクトのコンテンツとそのレプリカのコンテンツを照合し、実際のコンテンツが同じであることを確認します。そのため、fsck の方法で、ディープスクラブがデータの整合性を保ちますが、この手順ではクラスターに I/O のペナルティーを課すことになります。軽くこすっただけでもI/Oに影響が出ます。

デフォルトの設定では、動作のピーク時や高負荷時などの不適切なタイミングでCeph OSDがスクラビングを開始する可能性があります。スクラビング操作がエンドユーザーの操作と衝突すると、エンドユーザーは遅延やパフォーマンスの低下を感じるかもしれません。

エンドユーザーがパフォーマンスの低下を感じないように、Cephにはいくつかのスクラビング設定が用意されており、負荷の低い時間帯やオフピーク時にスクラビングを制限することができます。詳細については、『Red Hat Ceph Storage Configuration Guide』の OSDのスクラビングのセクションを参照してください。

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

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

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

[osd]
osd_scrub_load_threshold = 0.25

4.4.5. objecter_inflight_ops を増やします。

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

objecter_inflight_ops = 24576

4.4.6. rgw_thread_pool_size を増やします。

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

rgw_thread_pool_size = 512

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

Ceph Object Gatewayは、新規および上書きされたオブジェクトのストレージを即座に割り当てます。また、マルチパートのアップロードでは、パートごとにストレージを消費します。

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

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

radosgw-admin gc list

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

一部のワークロードでは、一時的または恒久的にガベージコレクションのアクティビティの速度を上回ることがあります。これは、多くのオブジェクトが短期間保存された後に削除されるような、削除の多いワークロードでは特に顕著です。このようなタイプのワークロードに対して、ストレージ管理者は以下の設定パラメータを使用して、ガベージコレクション操作の優先度を他の操作と比較して高めることができます。

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

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

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

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

注記

テストでは、50% の削除操作と 50% の書き込み操作など、均等にバランスの取れた削除/書き込みワークロードを使用すると、ストレージクラスターは 11 時間で完全にいっぱいになります。これは、Ceph Object Gatewayのガベージコレクションが削除操作に追いついていないためです。この場合、クラスターのステータスは HEALTH_ERR 状態に切り替わります。並列ガベージコレクションの調整項目を積極的に設定することで、テストではストレージクラスタのフィルドの発生を大幅に遅らせることができ、多くのワークロードに有効である。一般的な実世界のストレージクラスターのワークロードでは、主にガベージコレクションが原因でストレージクラスターのフィルが発生することはありません。

管理者は、展開後の実行時にCephの構成設定を変更することもできます。詳細は、「実行時に特定構成の設定」を参照してください。

第5章 Ceph のデプロイ

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

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

初期クラスタが稼働したら、以下のセクションの設定をCephの設定ファイルに追加することを検討します。

第6章 クラスターの拡大

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

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

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

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

注記

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

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

Ceph StorageクラスターとCeph Object Gatewaysを本番環境で使用するように設定する際に難しいのは、効果的なストレージ戦略を定義することです。ストレージ戦略には次のような要素があります。

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

7.1. CRUSH 階層の開発

CephクラスタとObject Gatewayを展開する場合、通常、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は複数のストレージポリシーをサポートしているため、ストレージポリシーのバケットプールは、IOPS最適化、スループット最適化、容量最適化などの異なるユースケースを反映して、異なるCRUSH階層に関連付けられている場合があります。バケットインデックスプールには、SSD ドライブ、NVMe ドライブなどの高性能記憶媒体にバケットインデックスプールをマップするために、独自の CRUSH 階層を使用 すべきです

7.1.1. CRUSH ルートの作成

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

CRUSH階層の詳細については、『Red Hat Ceph Storage Strategies Guide 4』の CRUSHの階層のセクションを参照してください。

CRUSHマップを手動で編集するには、『Red Hat Ceph Storage Strategies Guide』の CRUSHマップの編集 Red Hat Ceph Storage Storage Strategies Guide 4』のセクションを参照してください。

以下の例では、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 ドライブなどの高パフォーマンスメディアを表す はずです。SSD または NVMe メディアに OSD ジャーナルを保存するパーティションを作成することを検討してください。以下に例を示します。

##
# INDEX ROOT DECLARATION
##

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

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

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

CRUSHマップでは、ホスト名はユニークで一度しか使用してはいけません。ホストが複数の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マップが実際のホスト名ではなく論理的なホスト名を使用している場合に前述のいずれかの方法を使用しないと、再起動時にCeph Storage ClusterはOSDが実際のホスト名にマッピングされていると判断し、実際のホスト名はCRUSHマップで見つからず、Ceph Storage ClusterクライアントはOSDとそのデータを見つけることができません。

7.1.3. CRUSH ルールの作成

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

注記

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

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

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

##
# SERVICE RULE DECLARATION
##

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

前述の例では、データが3回複製される場合、同数のOSDノードを搭載したラックがクラスタ内に少なくとも3つ存在する必要があります。

ヒント

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

次の例は、データプールを保存するCRUSH階層のルールを示しています。この例では、ルートの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ストレージクラスターが異なる地域にあることがあります。各ゾーンは同じ名前空間内の各オブジェクトのディープコピーを持っているので、ユーザーは物理的に最も近いゾーンからコピーにアクセスすることができ、レイテンシーを減らすことができます。ただし、セカンダリゾーンがフェイルオーバーやディザスタリカバリのみを目的としている場合は、クラスタをアクティブ-パッシブモードで構成することができます。

注記

複数のゾーンを持つゾーングループの使用にも対応しています。複数のゾーングループを使用することは、テクノロジープレビューのみであり、本番環境ではサポートされていません。

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

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

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

サービスプールには、サービス制御、ガベージコレクション、ロギング、ユーザー情報、使用状況などに関するオブジェクトが格納されています。慣習上、これらのプール名には、プール名の前にゾーン名が付けられています。

注記

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

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

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

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

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

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

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

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

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

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

注記

サービスプールの場合、計算機によるPG数の目安は、OSDあたりの目標PG数よりも大幅に少なくなります。計算機のステップ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はバケットのオブジェクトをインデックスにマッピングします。これにより、Gatewayクライアントはバケット内のオブジェクトのリストなどを要求できます。一般的なユースケースでは、ユーザーがバケットを持ち、バケットごとに限られた数のオブジェクトを持つクオータが考えられますが、バケットには無数のオブジェクトを保存することができます。バケットに数百万個以上のオブジェクトが格納されている場合、SSDやNVMeドライブなどの高性能なストレージメディアを使用してデータを格納することで、インデックスのパフォーマンスが大幅に向上します。さらに、バケットシャーディングもパフォーマンスを劇的に向上させます。

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

注記

PG per Pool Calculatorでは、インデックスプールではプールあたりのPG数を少なくすることを推奨していますが、PG数はサービスプールの約2倍となっています。

注記

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

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

重要

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

7.5.2. データプールの作成

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

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

重要

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

初期設定では、データチャンクが2つ、エンコーディングチャンクが1つとなっており、1つのOSDしか失われないようになっています。より高い回復力を得るためには、より多くのデータおよびエンコーディングチャンクを考慮する必要があります。例えば、大規模なシステムでは、8つのデータチャンクと3つのエンコーディングチャンクを使用しており、3つのOSDが故障してもデータを失うことはありません。

重要

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

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

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

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

注記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.5.6. データ配置の概要

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

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

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

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

Ceph Object Gatewayの本番準備の最終ステップとして、Civetweb、ファイアウォールポート、DNS、ロードバランサーの設定を行います。トピックは以下の通りです。

8.1. Civetweb の設定

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

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

また、Civetweb特有の設定もあります。詳細は、「Civetweb 設定オプション」を参照してください。

オーバーライド可能な追加設定があります。詳細は、「Object Gateway 設定リファレンス」を参照してください。

注記

その他の使用例」のセクションでは、Ceph Object Gatewayをサードパーティのコンポーネントと一緒に使用する場合の詳細な構成例を説明します。

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

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

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

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

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

1つのゾーンでは通常、本番の負荷に対応し、高可用性を維持するために、Ceph Object Gatewayの複数のインスタンスを使用します。本番環境のクラスターでは、ロードバランサーを使用して、リクエストをゲートウェイインスタンスに割り当てるのが一般的です。

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

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

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

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

8.6. Beast 設定オプション

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

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

endpoint および ssl_endpoint

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

ssl_certificate

SSL 対応のエンドポイントに使用する SSL 証明書ファイルへのパス。ファイルが複数のアイテムを含むPEMファイルの場合、その順番は重要です。このファイルは、RGWサーバキーから始まり、次に任意の中間証明書、最後にCA証明書を記述する必要があります。

ssl_private_key

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

tcp_nodelay

一部の環境ではパフォーマンスの最適化が図られています。

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

...

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

注記

デフォルトでは、Beastフロントエンドは、サーバーが処理したすべてのリクエストを記録するアクセスログ行をRADOS Gatewayログファイルに書き込みます。

関連情報

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

クラスタが稼働したら、さらに検討すべきユースケースがあります。

9.1. マルチサイトでクラスタを拡張する

ストレージ戦略を策定する際、「レルムの作成」の手順では、クラスターが独自のレルム、マスターゾーングループ、マスターゾーンを持つマルチサイトを使用するようにすでに構成されていることを確認しました。

一般的な本番クラスタでは、災害時のバックアップとして、物理的に別の場所に独自のCeph Storage Clusterを持つセカンダリゾーンがあります。セカンダリーゾーンを設定するには、本ガイドの手順を繰り返します。一般的に、セカンダリゾーンはマスターゾーンと同じハードウェア構成とサイジングであるべきです。詳細は、「セカンダリーゾーンの設定」を参照してください。

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

gateway realm

9.2. NFSによるデータの移行 ガネーシャ

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

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

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

従来のウェブホスティングでは、ウェブサイトごとにウェブサーバーを設置する場合がありますが、コンテンツが動的に変化しない場合、リソースを非効率的に使用することになります。

Ceph Object Gatewayでは、PHP、サーブレット、データベース、nodejsなどのサーバーサイドサービスを使用していない静的なWebサイトをS3バケットでホスティングすることができます。この方法は、各サイトにウェブサーバーを搭載したVMを設置するよりも、大幅に経済的です。

詳細は、「静的 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 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章 NVMeとLVMの最適な組み合わせ

  1. 要約

    以下の手順では、高速のNVMeベースのSSD(これはSATA SSDにも適用されます)を使用する場合に、Ceph for Object Gatewayの使用を最適に展開する方法を示します。ジャーナルとバケットインデックスは、高速なストレージデバイスにまとめて配置されますので、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データとジャーナルの両方をHDDだけに置くことになります。ただし、ジャーナルはより高速な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プレイブックで、1つのデバイスを複数の目的で使用することをサポートする予定です。その間、SSD 使用率を最適化するのに必要な論理ボリューム (LV) の作成を容易にするために、Playbook の lv-create.yml および lv-vars.yaml が提供されます。lv-create.yml を実行すると、site.yml が正常に実行でき、新たに作成された論理ボリュームが使用されます。

    重要

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

10.1. 1台のNVMeデバイスを使用

この手順では、1つのNVMeデバイスでCeph for Object Gatewayの使用を展開します。

10.1.1. 既存のCephクラスタのパージ

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プレイブックを実行する前に停止します。その後、クラスターのインストール構成は、Object Gatewayをサポートするために最適なNVMe/LVMの使用に特化して調整されます。その時に初めてAnsibleのプレイブックを実行する必要があります。

通常のインストール用にストレージクラスターを設定するには、『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 により開始されます。

そのファイルは、一度に1つのNVMeデバイスしか参照できないようになっています。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. lv-create.yml Ansibleプレイブックの実行

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

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

    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構成の見直し

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

    NVMe上に配置されたHDD1台につき1つのジャーナルLV(/dev/nvme0n1に4つのLVを配置

    各HDDに配置されたデータLV(1つのHDDに1つのLV

    バケットインデックス用のジャーナルLVをNVMe上に配置(/dev/nvme0n1に1LV

    バケットインデックス用のデータLVをNVMe上に配置(/dev/nvme0n1に1LV

    LV は、lsblk および lvscan の出力で確認できます。上記の例では、CephのLVは10個あるはずです。大まかな健全性の確認として、CephのLVを数えて少なくとも10個あることを確認することもできますが、理想的には、適切なLVが適切なストレージデバイス(NVMe vs 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 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. Ceph for NVMeのインストールと成功の検証

NVMe with LVMを最適に使用するようにCeph for installationを設定した後、インストールします。

  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は、Ceph Object Gatewayに1つのNVMeデバイスとLVMを最適に使用するように設定されました。

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

この手順では、2台のNVMeデバイスでCeph for Object Gatewayの使用を展開します。

10.2.1. 既存のCephクラスタのパージ

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プレイブックを実行する前に停止します。その後、クラスターのインストール構成は、Object Gatewayをサポートするために最適なNVMe/LVMの使用に特化して調整されます。その時に初めてAnsibleのプレイブックを実行する必要があります。

通常のインストール用にクラスターを設定するには、『インストールガイド』を参照してください。特に、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 により開始されます。

そのファイルは、一度に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へのデバイスの追加

  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. 1回目の実行では、以下の行を含むようにファイルを編集します。

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

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

10.2.5. lv-create.yml Ansibleプレイブックの実行

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. ストレージデバイスが生であることを確認する

    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)を作成する必要があります。

    両方のNVMeデバイスに配置された1つのHDDにつき1つのジャーナルLV(/dev/nvme0n1に2つのLV、/dev/nvme1n1に2つのLV)。

    各HDDに配置されたデータLV(1つの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のLVは12個あるはずです。大まかな健全性の確認として、CephのLVを数えて少なくとも12個あることを確認することができますが、理想的には、適切なLVが適切なストレージデバイス(NVMe vs 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 Playbook

  1. osd_objectstorebluestoreに設定する。

    lv-create.logから2番目の情報をosds.ymlに追加することに加えて、osds.ymlall.ymlの両方のファイルでosd_objectstorebluestoreに設定する必要があります。

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

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

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

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

10.2.11. Ceph for NVMeのインストールと成功の検証

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

    $ ansible-playbook -v site.yml -i hosts
  2. インストール完了後、Cephが正常に動作していることを確認します。

    # ceph -s
    # ceph osd tree

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

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

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

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

    Cephは、Object Storage Gatewayのために2台のNVMeデバイスとLVMを最適に使用するように設定されました。