ハードウェアガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage におけるハードウェア選択に関する推奨事項

概要

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

第1章 エグゼクティブサマリー

多くのハードウェアベンダーは、個別のワークロードプロファイル向けに設計された Ceph 最適化サーバーおよびラックレベルのソリューションの両方を提供するようになりました。ハードウェア選択プロセスを単純化し、組織のリスクを低減するために、Red Hat は複数のストレージサーバーベンダーと連携して、さまざまなクラスターサイズおよびワークロードプロファイルの特定のクラスターオプションをテストおよび評価しています。Red Hat の厳密な方法論は、パフォーマンステストと、幅広いクラスター機能とサイズの確立されたガイダンスを組み合わせたものです。適切なストレージサーバーとラックレベルのソリューションを使用することで、Red Hat Ceph Storage は、スループットに敏感でコストおよび容量を重視するワークロードから、新しい IOPS 集約型ワークロードまで、さまざまなワークロードに対応するストレージプールを提供できます。

Red Hat Ceph Storage は、エンタープライズデータの保存コストを大幅に削減し、組織が指数関数的なデータの成長を管理できるようにします。このソフトウェアは、パブリックまたはプライベートのクラウドデプロイメント向けの堅牢かつ最新のペタバイトスケールのストレージプラットフォームです。Red Hat Ceph Storage は、エンタープライズブロックおよびオブジェクトストレージに成熟したインターフェースを提供します。これにより、テナントに依存しない OpenStack® 環境がキャリビュー化されたアクティブなアーカイブ、リッチメディア、クラウドのインフラストラクチャーワークロードに最適なソリューションとなります。 [1].統合されたソフトウェア定義のスケールアウトストレージプラットフォームとして提供される Red Hat Ceph Storage は、以下のような機能を提供することで、企業がアプリケーションの革新性と可用性の向上に集中できるようにします。

  • 数百のペタバイトへのスケーリング [2].
  • クラスターに単一障害点はありません。
  • 商用サーバーハードウェア上で実行することで、資本経費 (CapEx) を削減します。
  • 自己管理および自己修復プロパティーで運用費 (OpEx) を削減します。

Red Hat Ceph Storage は、多様なニーズを満たすために、業界標準のハードウェア構成で動作することができます。クラスター設計プロセスを単純化および加速するために、Red Hat は、参加するハードウェアベンダーによるパフォーマンスおよび適合性のテストを実施しています。このテストにより、選択したハードウェアを負荷下で評価し、多様なワークロードに必要な性能とサイジングデータを生成することができ、Ceph ストレージクラスタのハードウェア選択を大幅に簡素化できます。本ガイドで説明しているように、複数のハードウェアベンダーが Red Hat Ceph Storage デプロイメントに最適化されたサーバーおよびラックレベルのソリューションを提供しており、IOPS、スループット、コスト、容量を最適化したソリューションが利用可能なオプションとして提供されています。

ソフトウェア定義ストレージは、要求の厳しいアプリケーションや段階的に増大するストレージのニーズを満たすスケールアウトソリューションを求める組織にとって、多くの利点を提供しています。複数のベンダーで実施される優れた方法論と広範囲のテストにより、Red Hat は、あらゆる環境の需要を満たすためにハードウェアを選択するプロセスを単純化します。重要なことは、本書に記載されているガイドラインやシステム例は、サンプルシステムにおける実稼働環境のワークロードの影響を定量化するための代用品ではないということです。

Red Hat Ceph Storage を実行するサーバーの設定に関する具体的な情報については、『Red Hat Ceph Storage 戦略ガイド』で説明されている方法およびベストプラクティスを参照してください。Red Hat Ceph Storage テスト結果などの詳細情報は、一般的なハードウェアベンダーのパフォーマンスおよびサイジングに関するガイドを参照してください。


[1] 年 2 回の OpenStack ユーザー調査によると、Ceph は OpenStack をリードするストレージであり、その地位を確立しています。

第2章 ハードウェアを選択する一般的な原則

ストレージ管理者は、実稼働用の Red Hat Ceph Storage クラスターを実行するのに適切なハードウェアを選択する必要があります。Red Hat Ceph Storage のハードウェアを選択する際には、以下の一般原則を確認してください。この原則は、時間を節約し、よくある間違いを回避し、お金を節約し、より効果的な解決策を実現するのに役立ちます。

2.1. 前提条件

  • Red Hat Ceph Storage の計画的な使用

2.2. パフォーマンスユースケースの特定

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

Ceph の主なユースケースは以下のとおりです。

  • 最適化された IOPS: IOPS が最適化されたデプロイメントは、MYSQL や MariaDB インスタンスを OpenStack 上の仮想マシンとして実行するなど、クラウドコンピューティングの操作に適しています。IOPS を最適化するデプロイメントでは、頻度の高い書き込み操作を処理するために、15k RPM SAS ドライブや個別のフラッシュベースの BlueStore メタデータデバイスなどのより高いパフォーマンスストレージが必要です。一部の IOPS のシナリオでは、すべてのフラッシュストレージを使用して IOPS と総スループットが向上します。
  • 最適化されたスループット: スループットが最適化されたデプロイメントは、グラフィック、音声、ビデオコンテンツなどの大量のデータを提供するのに適しています。スループット最適化されたデプロイメントには、トータルスループット特性が許容されるネットワーキングハードウェア、コントローラー、ハードディスクドライブが必要です。書き込みパフォーマンスが要件の場合、フラッシュベースの BlueStore メタデータデバイスで書き込みパフォーマンスが大幅に改善します。
  • 最適化された容量: 容量が最適化されたデプロイメントは、大量のデータを可能な限り安価に保存するのに適しています。容量が最適化されたデプロイメントは通常、パフォーマンスがより魅力的な価格と引き換えになります。たとえば、容量が最適化されるデプロイメントは、多くの場合、低速かつ高価な SATA ドライブを使用します。

本書は、これらのユースケースに適した Red Hat テスト済みハードウェアの例を提供します。

2.3. ストレージの密度を考慮する

ハードウェアのプランニングには、ハードウェア障害が発生した場合に高可用性を維持するために、Ceph デーモンや Ceph を使用する他のプロセスを多数のホストに分散させることが含まれていなければなりません。ハードウェア障害が発生した場合のクラスターのリバランスの必要性とストレージ密度のバランスを考慮してください。よくあるハードウェアの選択ミスは、小規模なクラスターで非常に高いストレージ密度を使用することで、バックフィルやリカバリー操作中にネットワークに負荷がかかりすぎる可能性があります。

2.4. 同じハードウェア構成

プールを作成し、プール内の OSD ハードウェアが同じになるように CRUSH 階層を定義します。

  • 同じコントローラー。
  • 同じドライブのサイズ。
  • 同じ RPM。
  • 同じシーク時間。
  • 同じ I/O。
  • 同じネットワークスループット。

プール内で同じハードウェアを使用することで、一貫したパフォーマンスプロファイルが得られ、プロビジョニングが簡素化され、トラブルシューティングの効率が上がります。

警告

複数のストレージデバイスを使用する場合 (再起動時に場合によってはデバイスの順序が変わることがあります)。この問題のトラブルシューティングは、「How do I change the order of storage devices during boot in RHEL 7?」を参照してください。

2.5. ネットワークの考慮事項

クラスターネットワークの帯域幅要件を慎重に検討し、ネットワークリンクのオーバーサブスクリプションに注意してください。また、クライアント間のトラフィックからクラスター内のトラフィックを分離します。

重要

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

ドライブに障害が発生した場合、1Gbps ネットワーク全体で 1 TB のデータをレプリケートするには 3 時間かかります。3 TB には 9 時間かかります。3 TB は、通常のドライブ構成です。これに対して、10 GB のネットワークの場合、レプリケーション時間はそれぞれ 20 分と 1 時間になります。OSD が失敗すると、クラスターはプール内の他の OSD に含まれるデータをレプリケートしてリカバリーすることに注意してください。

ラックなどの大規模なドメインに障害が発生した場合は、ストレージクラスターが帯域幅を大幅に消費することになります。ストレージ管理者は、通常、クラスターをできるだけ早く復元することを優先します。

少なくとも 10 GB のイーサネットリンク 1 つをストレージハードウェアに使用する必要があります。Ceph ノードに各ドライブが多数ある場合には、接続およびスループット用にさらに 10 GB のイーサネットリンクを追加します。

重要

個別の NIC にフロントエンドネットワークとバックサイドネットワークを設定します。

Ceph は、パブリック (フロントエンド) ネットワークとクラスター (バックエンド) ネットワークをサポートします。パブリックネットワークは、クライアントのトラフィックと Ceph モニターとの通信を処理します。クラスター (バックエンド) ネットワークは、OSD のハートビート、レプリケーション、バックフィル、およびリカバリーのトラフィックを処理します。

注記

Red Hat では、レプリケートされたプールの倍数の基礎として osd_pool_default_size を使用して、フロントサイドネットワークの倍数になるようにクラスター (バックサイド) ネットワークに帯域幅を割り当てることを推奨します。Red Hat では、パブリックネットワークとクラスターネットワークを別の NIC で実行することを推奨します。

複数のラックで構成されるストレージクラスター (大規模なストレージ実装では一般的) を構築する際には、最適なパフォーマンスを得るために、「ファットツリー」設計でスイッチ間のネットワーク帯域幅をできるだけ多く利用することを検討してください。一般的な 10 GB のイーサネットスイッチには、48 個の 10 GB ポートと 4 個の 40 GB のポートがあります。スループットを最大にするには、Spine (背骨) で 40 GB ポートを使用します。または、QSFP+ および SFP+ ケーブルを使用する未使用の 10Gbps ポートを別のラックおよびスパインルーターに接続するために、さらに 40 GB のポートに集計することを検討します。

重要

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

関連情報

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

2.6. RAID ソリューションの使用を回避

Ceph はコードオブジェクトの複製または消去が可能です。RAID は、この機能をブロックレベルで複製し、利用可能な容量を減らします。そのため、RAID は不要な費用です。さらに、劣化した RAID はパフォーマンスに 悪影響 を及ぼします。

重要

Red Hat では、各ハードドライブを RAID コントローラーから個別にエクスポートし、ライトバックキャッシングを有効にして 1 つのボリュームとして使用することを推奨します。

これには、ストレージコントローラー上にバッテリーが支援された、または不揮発性のフラッシュメモリーデバイスが必要です。停電が原因で、コントローラー上のメモリーが失われる可能性がある場合は、ほとんどのコントローラーがライトバックキャッシングを無効にするため、バッテリーが動作していることを確認することが重要です。電池は経年劣化するので、定期的に点検し、必要に応じて交換してください。詳細は、ストレージコントローラーベンダーのドキュメントを参照してください。通常、ストレージコントローラーベンダーは、ダウンタイムなしにストレージコントローラー設定を監視および調整するストレージ管理ユーティリティーを提供します。

Ceph で独立したドライブモードでの JBOD (Just a Bunch of Drives) の使用は、すべてのソリッドステートドライブ (SSD) を使用している場合や、コントローラーあたりのドライブ数が多い構成の場合にサポートされています。たとえば、1 つのコントローラーに接続されたドライブ数が 60 などの場合です。このシナリオでは、ライトバックキャッシングが I/O 競合のソースとなります。JBOD はライトバックキャッシュを無効にするため、このシナリオには適しています。JBOD モードを使用する利点の 1 つは、ドライブの追加や交換が簡単で、物理的に接続した後すぐにオペレーティングシステムにドライブを公開できることです。

2.7. ハードウェアを選択する際のよくある間違いの概要

  • パワー不足のレガシーハードウェアを Ceph で使用するために再利用する。
  • 同じプールで異種のハードウェアを使用する。
  • 10Gbps 以上ではなく 1Gbps ネットワークを使用する。
  • パブリックネットワークとクラスターネットワークの両方を設定することを怠っている。
  • JBOD の代わりに RAID を使用する。
  • パフォーマンスやスループットを考慮せずに、価格順でドライブを選択する。
  • スループットの特性が不十分なディスクコントローラーがある。

本書に記載されている Red Hat の異なるワークロード用のテスト済み構成の例を使用して、前述のハードウェアの選択ミスを回避してください。

2.8. 関連情報

第3章 ワークロードのパフォーマンスドメインの最適化

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

以下の一覧は、ストレージサーバーで最適な Red Hat Ceph Storage クラスター設定の特定に Red Hat が使用する基準を示しています。これらのカテゴリーは、ハードウェアの購入および設定決定に関する一般的なガイドラインとして提供され、一意のワークロードの競合に対応するように調整できます。実際に選択されるハードウェア構成は、特定のワークロードミックスとベンダーの能力によって異なります。

最適化した IOPS

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

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

IOPS に最適化されたストレージクラスタの一般的な用途は以下の通りです。

  • 典型的なブロックストレージ。
  • ハードドライブ (HDD) の 3x レプリケーションまたはソリッドステートドライブ (SSD) の 2x レプリケーション。
  • OpenStack クラウド上の MySQL

最適化されたスループット

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

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

スループットを最適化したストレージクラスタの一般的な用途は以下の通りです。

  • ブロックまたはオブジェクトストレージ。
  • 3x レプリケーション。
  • ビデオ、音声、およびイメージのアクティブなパフォーマンスストレージ。
  • ストリーミングメディア。

コストおよび容量の最適化

コストおよび容量が最適化されたストレージクラスターには、通常以下のプロパティーがあります。

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

通常は、コストおよび容量が最適化されたストレージクラスターに使用されます。

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

パフォーマンスドメインの仕組み

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

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

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

以下の例では、パフォーマンスドメインを説明します。

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

これらのパフォーマンスドメインはすべて、Ceph Storage クラスターに共存できます。

第4章 サーバーおよびラックソリューション

ハードウェアベンダーは、最適化されたサーバーレベルとラックレベルのソリューション SKU を提供することで、Ceph に対する熱意に応えてきました。Red Hat との共同テストで検証されたこれらのソリューションは、特定のワークロードに合わせて Ceph ストレージを拡張するための便利なモジュール式のアプローチにより、Ceph の導入において予測可能な価格対性能比を提供します。

一般的なラックレベルのソリューションには、以下が含まれます。

  • ネットワーク切り替え: 冗長性のあるネットワークスイッチはクラスターを相互に接続し、クライアントへのアクセスを提供します。少なくとも 1 つのネットワークスイッチが推奨されます。冗長性を確保するために、2 つのネットワークスイッチが使用され、2 つのスイッチが分割され、各スイッチのパーティションで 2 つのネットワークセグメントがサポートされます。
  • Ceph MON ノード: Ceph モニターはクラスター全体の健全性を確保するためのデータストアで、クラスターログが含まれます。実稼働環境でのクラスタークォーラムには、最低 3 台の監視ノードが強く推奨されます。
  • Ceph OSD ホスト： Ceph OSD ホストはクラスターのストレージ容量を持ち、デバイスが HDD または SSD の場合、個々のストレージデバイスごとに 1 つ以上の OSD を実行します。NVME デバイスの場合、Red Hat は、個々のストレージデバイスごとに 2 つ以上の OSD を実行することを推奨します。OSD ホストは、ワークロードの最適化と、インストールされているデータデバイス (HDD、SSD、または NVMe SSD) の両方に応じて選択および設定されます。
  • Red Hat Ceph Storage: サーバーおよびラックレベルのソリューション SKU の両方がバンドルされている Red Hat Ceph Storage の容量ベースのサブスクリプションを提供しています。
注記

Red Hat は、サーバーとラックソリューションにコミットする前に、Red Hat Ceph Storage:Supported Configurations のアーティクルを確認することを推奨します。その他のサポートは、Red Hat サポート にお問い合わせください。

IOPS 最適化ソリューション

フラッシュストレージの利用が拡大する中、企業は Ceph ストレージクラスターで IOPS を多用するワークロードをホストし、プライベートクラウドストレージで高性能なパブリッククラウドソリューションをエミュレートするケースが増えています。これらのワークロードは通常、MySQL、MariaDB、または PostgreSQL ベースのアプリケーションからの構造化データを必要とします。

一般的なサーバーには、以下の要素が含まれます。

  • CPU: NVMe SSD ごとに 6 コア（GHz CPU が 2 つ想定）
  • RAM: 16 GB ベースラインに加えて、OSD ごとに 5 GB
  • Networking: 2 つの OSD あたり 10 Gigabit Ethernet(GbE)
  • OSD メディア: 高性能で高耐久のエンタープライズ NVMe SSD。
  • OSD: NVMe SSD あたり 2 つ。
  • BlueStore WAL/DB: 高パフォーマンス、高パフォーマンス、高エンドトエンタープライズ NVMe SSD（OSD と共存する）
  • コントローラー: ネイティブ PCIe バス。
注記

非 NVMe SSD の場合は、CPU 用に SSD OSD ごとに 2 つのコアを使用します。

表4.1 IOPS が最適化された Ceph ワークロードのソリューション SKU (クラスターサイズ別)

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

SuperMicro [a]

SYS-5038MR-OSD006P

該当なし

該当なし

[a] 詳細は、「Supermicro® Total Solution for Ceph」を参照してください。

スループットが最適化されたソリューション

スループットが最適化された Ceph ソリューションは通常、半構造化または非構造化データをベースとしています。大規模なブロックの連続 I/O は一般的です。OSD ホストのストレージメディアは通常 HDD で、SSD ベースのボリュームに書き込みジャーナルがあります。

一般的なサーバー要素には以下が含まれます。

  • CPU: HDD ごとに 0.5 コア (2 GHz CPU を想定)
  • RAM: 16 GB ベースラインに加えて、OSD ごとに 5 GB
  • Networking: クライアントおよびクラスター向けネットワーク用に、12 OSD ごとに 10 GbE の OSD が必要です。
  • OSD メディア: 7200 RPM のエンタープライズ HDD
  • OSD: HDD ごとに 1 つ。
  • BlueStore WAL/DB: High-endurance, high-performance enterprise serial-attached SCSI(SAS)または NVMe SSDs。
  • ホストバスアダプター(HBA): 大量のディスク (JBOD)。

いくつかのベンダーは、スループットが最適化された Ceph ワークロードのための設定済みのサーバーおよびラックレベルのソリューションを提供しています。Red Hat は、Supermicro および Quanta Cloud Technologies (QCT) からサーバーのテストや評価を徹底して行っています。

表4.2 Ceph OSD、MON、および TOR (top-of-rack) スイッチ向けのラックレベルの SKU。

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

SuperMicro [a]

SRS-42E112-Ceph-03

SRS-42E136-Ceph-03

SRS-42E136-Ceph-03

表4.3 個別の OSD サーバー

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

SuperMicro [a]

SSG-6028R-OSD072P

SSG-6048-OSD216P

SSG-6048-OSD216P

QCT [a]

QxStor RCT-200

QxStor RCT-400

QxStor RCT-400

[a] 詳細は、「QCT: QxStor Red Hat Ceph Storage Edition」を参照してください。

表4.4 スループットが最適化された Ceph OSD ワークロードの追加サーバー設定

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

Dell

PowerEdge R730XD [a]

DSS 7000 [b], twin node

DSS 7000、ツインノード

Cisco

UCS C240 M4

UCS C3260 [c]

UCS C3260 [d]

Lenovo

System x3650 M5

System x3650 M5

該当なし

[c] 詳細は、「Red Hat Ceph Storage hardware reference architecture」を参照してください。
[d] 詳細は、「UCS C3260」を参照してください。

コストおよび容量が最適化されたソリューション

コストと容量が最適化されたソリューションは、一般的に大容量化、またはより長いアーカイブシナリオに焦点を当てています。データは、半構造化または非構造化のいずれかになります。ワークロードには、メディアアーカイブ、ビッグデータアナリティクスアーカイブ、およびマシンイメージのバックアップが含まれます。大規模なブロックの連続 I/O は一般的です。より大きな費用対効果を得るために、OSD は通常、Ceph の書き込みジャーナルを HDD 上に併置してホストされています。

ソリューションには、通常、以下の要素が含まれます。

  • CPU: HDD ごとに 0.5 コア (2 GHz CPU を想定)
  • RAM: 16 GB ベースラインに加えて、OSD ごとに 5 GB
  • Networking: 12 OSD ごとに 10 GbE（それぞれクライアントおよびクラスター向けネットワーク用）
  • OSD メディア: 7200 RPM のエンタープライズ HDD
  • OSD: HDD ごとに 1 つ。
  • BlueStore WAL/DB: HDD に配置されています。
  • HBA: JBOD。

Supermicro および QCT は、コストと容量を重視した Ceph ワークロード向けに、構成済みのサーバーとラックレベルのソリューション SKU を提供しています。

表4.5 構成済みコストと容量が最適化されたワークロードのためのラックレベル SKU

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

SuperMicro [a]

該当なし

SRS-42E136-Ceph-03

SRS-42E172-Ceph-03

表4.6 コストと容量が最適化されたワークロード用の構成済みのサーバーレベル SKU

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

SuperMicro [a]

該当なし

SSG-6048R-OSD216P [a]

SSD-6048R-OSD360P

QCT

該当なし

QxStor RCC-400 [a]

QxStor RCC-400 [a]

[a] 詳細は、「Supermicro's Total Solution for Ceph」を参照してください。

表4.7 コストと容量が最適化されたワークロード用に構成可能な追加サーバー

ベンター小規模 (250TB)中規模 (1PB)大規模 (2PB 以上)

Dell

該当なし

DSS 7000、ツインノード

DSS 7000、ツインノード

Cisco

該当なし

UCS C3260

UCS C3260

Lenovo

該当なし

System x3650 M5

該当なし

関連情報

第5章 ハードウェアの最小推奨事項

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

注記

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

Process条件最小推奨

ceph-osd

プロセッサー

1x AMD64 または Intel 64

RAM

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

OS ディスク

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

ボリュームストレージ

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

block.db

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

block.wal

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

ネットワーク

2x 1GB イーサネット NIC

ceph-mon

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 15 GB（推奨）

Monitor ディスク

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

ネットワーク

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

ceph-mgr

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ネットワーク

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

ceph-radosgw

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 5 GB

ネットワーク

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

ceph-mds

プロセッサー

1x AMD64 または Intel 64

RAM

デーモンごとに 2 GB

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

ディスク容量

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

ネットワーク

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

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

第6章 コンテナー化された Ceph のハードウェアの最小推奨事項

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

Process条件最小推奨

ceph-osd-container

プロセッサー

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

RAM

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

OS ディスク

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

OSD ストレージ

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

block.db

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

block.wal

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

ネットワーク

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

ceph-mon-container

プロセッサー

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

RAM

mon-container あたり 3 GB

ディスク容量

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

監視ディスク

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

ネットワーク

2x 1GB イーサネット NIC、10 GB 推奨

ceph-mgr-container

プロセッサー

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

RAM

mgr-container あたり 3 GB

ネットワーク

2x 1GB イーサネット NIC、10 GB 推奨

ceph-radosgw-container

プロセッサー

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

RAM

デーモンごとに 1 GB

ディスク容量

デーモンごとに 5 GB

ネットワーク

1x 1GB イーサネット NIC

ceph-mds-container

プロセッサー

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

RAM

mds-container あたり 3 GB

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

ディスク容量

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

ネットワーク

2x 1GB イーサネット NIC、10 GB 推奨

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