分散ファイルシステム Ceph ハードウェア

ハードウェアの推奨事項

Ceph はコモディティ ハードウェア向けに設計されているため、PB レベルのデータ クラスターの構築と保守が比較的安価になります。クラスター ハードウェアを計画するときは、ゾーン障害や潜在的なパフォーマンスの問題など、いくつかの要素のバランスを取る必要があります。ハードウェア計画には、Ceph デーモンと Ceph クラスターを使用するその他のプロセスの適切な分散を含める必要があります。一般的に、マシン上で 1 種類のデーモンのみを実行することをお勧めします。ほとんどの専門家は、データ クラスター (OpenStack、CloudStack など) を使用するプロセスを別のマシンにインストールすることを推奨しています。しかし、ハイパーコンバージドアーキテクチャが蔓延しているこの時代では、パブリッククラウドのストレージとしてCephを初めて採用したYouyunのように、それらを一緒に導入する大手メーカーも数多く存在します。

[[311705]]

CPU

Ceph メタデータ サーバーは CPU に敏感で、負荷を動的に再分配するため、メタデータ サーバーには十分な処理能力が必要です (実稼働では 2C デュアル 12 コア CPU を使用しています)。 Ceph の OSD は RADOS サービスを実行し、CRUSH を使用してデータの保存場所を計算し、データを複製し、クラスター操作マップの独自のコピーを維持するため、OSD には一定の処理能力 (デュアルコア CPU など) が必要です。モニターはクラスター グラフのコピーを維持するだけなので、CPU の影響を受けません。ただし、後でマシンが Ceph モニター以外の CPU を集中的に使用するタスクを実行するかどうかを考慮する必要があります。たとえば、サーバーがコンピューティング用の仮想マシン (OpenStack Nova など) を実行する場合は、Ceph プロセスに十分な処理能力を確保しておく必要があるため、CPU を集中的に使用するタスクは他のマシンで実行することをお勧めします。

メモリ

メタデータ サーバーとモニターは、データをできるだけ早く提供できる必要があるため、プロセスごとに少なくとも 1 GB の十分なメモリが必要です。 OSD は日常的な操作にそれほど多くのメモリを必要としません (たとえば、プロセスあたり 500 MB)。ただし、リカバリ中には大量のメモリが必要になります (たとえば、データ 1 TB あたりプロセスあたり約 1 GB)。一般的に、メモリは多ければ多いほど良いです。 (私の本番環境は512Gのメモリを搭載したハイパーコンバージドアーキテクチャです)

データストレージ

コストとパフォーマンスのトレードオフが明らかに存在するため、データ ストレージ構成を慎重に計画してください。オペレーティング システムと複数のデーモンからの並列操作が単一のハード ディスクへの読み取りと書き込みを同時に要求すると、パフォーマンスが大幅に低下する可能性があります。考慮すべきファイル システムの制限もあります。btrfs はまだ実稼働での使用に十分な安定性がありませんが、ジャーナリングとデータの書き込みを同時に行うことができますが、xfs と ext4 ではそれができません。

重要: Ceph は ACK を送信する前にすべてのデータをジャーナルに書き込む必要があるため (少なくとも xfs と ext4 の場合)、ジャーナルと OSD のパフォーマンスのバランスを取ることが非常に重要です。

ハードドライブ

OSD にはオブジェクト データを保存するのに十分なスペースが必要です。大容量ハードディスクの1GBあたりのコストを考慮すると、1TBを超える容量のハードディスクを使用することをお勧めします。通常、ハード ドライブの容量が大きいほど GB あたりのコストに大きく影響するため、GB 数をハード ドライブの価格で割って GB あたりのコストを計算することをお勧めします。たとえば、単価が 75 ドルの 1 TB ハード ドライブの場合、1 GB あたりの価格は 0.07 ドル (75 ドル / 1024 = 0.0732) になります。もう 1 つの例として、単価が 150 ドルの 3 TB ハード ドライブの場合、1 GB あたりの価格は 0.05 ドル (150 ドル / 3072 = 0.0488) になります。 1TB のハードドライブを使用すると、1GB あたりの価格が 40% 上昇し、経済性が低下します。さらに、単一のドライブの容量が大きいほど、特に再バランス調整、バックフィル、および回復時に、対応する OSD に必要なメモリが多くなります。経験則として、1TB のストレージ容量には約 1GB のメモリが必要です。

(現在、私の実稼働環境では 1.2T の高速ディスクを使用しているため、大容量のメモリが必要になります。)

パーティションを考慮せずに単一のハードドライブ上で複数の OSD を実行することは強くお勧めしません。

パーティション分割を考慮せずに、OSD と同じディスク上でモニターまたはメタデータ サーバーを実行することも強くお勧めしません。

ストレージ ドライブは、シーク時間、アクセス時間、読み取りおよび書き込み時間、および全体的なスループットによって制限され、これらの物理的な制限は、特にシステム回復中に、システム全体のパフォーマンスに影響します。したがって、オペレーティング システムとソフトウェア用に別々のドライブを用意し、OSD デーモンごとに 1 つのドライブを用意することをお勧めします。ほとんどの「OSD が遅い」問題は、同じハード ドライブ上で OS、複数の OSD、および/または複数のログ ファイルを実行することによって発生します。パフォーマンスの問題を修正するコストは、ディスク ドライブを追加するコストを簡単に上回る可能性があるため、パフォーマンスを向上させるには、OSD ストレージ ドライブに負担をかけないようにシステムを設計する必要があります。

Ceph ではハードドライブごとに複数の OSD を実行できますが、これによりリソースの競合が発生し、全体的なスループットが低下する可能性があります。 Ceph では、ログとオブジェクト データを同じドライブに保存することもできますが、書き込みの確認に応答する前に Ceph がログに書き込む必要があるため、ログへの書き込みを記録してクライアントに応答する際の待ち時間が長くなる可能性があります。 btrfs ファイル システムはジャーナル データとオブジェクト データの両方を書き込むことができますが、xfs と ext4 は書き込むことができません。

Ceph のベスト プラクティスでは、オペレーティング システム、OSD データ、および OSD ジャーナルを別々のディスクで実行することが推奨されています。

ソリッドステートドライブ

パフォーマンスを向上させる 1 つの方法は、ソリッド ステート ドライブ (SSD) を使用して、ランダム アクセス時間と読み取り待ち時間を短縮し、スループットを向上させることです。 SSD は通常、1 GB あたりのコストがハードディスクの 10 倍以上かかりますが、アクセス時間はハードディスクの少なくとも 100 倍高速です。

SSD には可動機械部品がないため、ハードドライブのような制限はありません。しかし、SSD にも制限があります。 SSD を評価する際には、シーケンシャル読み取りおよび書き込みパフォーマンスが重要です。複数の OSD のログを保存する場合、400 MB/秒のシーケンシャル読み取りおよび書き込みスループットを備えた SSD は、120 MB/秒の SSD よりもはるかに優れたパフォーマンスを発揮します。

重要

パフォーマンスを向上させるために、SSD の使用を検討することをお勧めします。ただし、SSD に多額の投資をする前に、SSD のパフォーマンス指標を検証し、テスト環境でパフォーマンスを測定することを強くお勧めします。

SSD には可動機械部品がないため、多くのストレージスペースを必要としない Ceph での使用に適しています。比較的安価な SSD は魅力的ですが、注意して使用してください。許容可能な IOPS メトリックだけでは、Ceph 用の SSD を選択するには不十分です。ログ記録に SSD を使用する場合、いくつかの重要な考慮事項があります。

書き込み集中型のセマンティクス: ログ記録には書き込み集中型のセマンティクスが含まれるため、選択した SSD の書き込みパフォーマンスがハード ディスクの書き込みパフォーマンスと同等かそれ以上であることを確認する必要があります。安価な SSD はアクセスを高速化する一方で書き込み遅延を引き起こす可能性があり、場合によっては高性能ハードドライブの書き込み速度が安価な SSD の書き込み速度に匹敵することもあります。

順次書き込み: 複数の OSD の複数のジャーナルを単一の SSD に保存する場合、複数の OSD ジャーナルからの書き込み要求を同時に処理する必要があるため、SSD の順次書き込み制限も考慮する必要があります。

パーティションのアライメント: SSD の一般的な問題は、パーティション分割は好むものの、パーティションのアライメントを無視することが多いことです。これにより、SSD のデータ転送速度が大幅に低下する可能性があるため、パーティションがアライメントされていることを確認してください。

SSD はオブジェクト ストレージに使用するには高価すぎますが、OSD ログを SSD に保存し、オブジェクト データを別のハード ディスクに保存すると、パフォーマンスが大幅に向上します。 osd journal オプションのデフォルト値は /var/lib/ceph/osd/$cluster-$id/journal です。オブジェクト データと同じハード ディスクに保存されるファイルではなくなるように、SSD または SSD パーティションにマウントできます。 CephFS ファイルシステムのパフォーマンスを向上させる 1 つの方法は、メタデータを CephFS ファイルのコンテンツから分離することです。 Ceph はデフォルトのメタデータを提供します。 CephFS メタデータはストレージ プールに保存されるため、CephFS メタデータ用のストレージ プールを作成する必要はありませんが、ホスト SSD のみを指す CRUSH マップを作成できます。詳細については、「ストレージ プールへの OSD の割り当て」を参照してください。

コントローラ

ハードディスク コントローラも書き込みスループットに大きな影響を与えるため、パフォーマンスのボトルネックを回避するために慎重に選択する必要があります。

Ceph ブログは、Ceph パフォーマンスに関する質問の優れた情報源となることがよくあります。「Ceph Write Throughput 1」および「Ceph Write Throughput 2」を参照してください。

その他の考慮事項

同じホスト上で複数の OSD を実行できますが、OSD ハード ディスクの合計スループットが、クライアントに読み取りおよび書き込みサービスを提供するために必要なネットワーク帯域幅を超えないようにしてください。また、クラスター内の各ホストに保存されるデータの割合も考慮してください。ホストの割合が大きすぎてハングすると、全体の比率を超えるなどの問題が発生する可能性があり、Ceph はデータ損失を防ぐために操作を終了します。ホストごとに複数の OSD を実行する場合は、カーネルも最新の状態に保つ必要があります。ハードウェアが期待どおりに機能するかどうかを確認するには、glibc および syncfs(2) に関する OS の推奨事項を参照してください。

多数の OSD (たとえば、20 個以上) を持つホストでは、特にリカバリおよび再バランス調整中に、多数のスレッドが生成される場合があります。多くの Linux カーネルでは、デフォルトの最大スレッド数は小さくなっています (32k など)。このような問題に遭遇した場合は、kernel.pid_maxを設定することができます。

値を高く調整します。理論上の最大値は 4194303 です。

たとえば、/etc/sysctl.conf ファイルに次の行を追加します。

カーネル.pid_max = 4194303

ネットワーク

各マシンに少なくとも 2 枚のギガビット ネットワーク カードを搭載することをお勧めします。現在、ほとんどの機械式ハードディスクは約 100MB/秒のスループットを実現できます。ネットワーク カードは、すべての OSD ハード ディスクの合計スループットを処理できる必要があるため、パブリック ネットワーク (フロント エンド) 用とクラスター ネットワーク (バックエンド) 用に、少なくとも 2 枚のギガビット ネットワーク カードを用意することをお勧めします。クラスター ネットワーク (インターネットに接続されていないことが望ましい) は、データ レプリケーションによって生成される追加の負荷を処理し、OSD データのレプリケーション中にデータ配置グループを混乱させ、アクティブ + クリーンな状態に戻れないようにするサービス拒否攻撃を防ぐために使用されます。 10 ギガビット ネットワーク カードの導入を検討してください。 1Gbps ネットワーク経由で 1TB のデータをコピーするには 3 時間かかりますが、3TB (標準構成) の場合は 9 時間かかります。対照的に、10Gbps を使用すると、コピー時間はそれぞれ 20 分と 1 時間に短縮されます。 PB レベルのクラスターでは、OSD ディスク障害は例外ではなく、通常のことです。システム管理者は、合理的な費用対効果を前提として、PG を劣化状態からアクティブ + クリーン状態にできるだけ早く復元したいと考えています。さらに、一部の導入ツール (Dell の Crowbar など) では 5 つの異なるネットワークを導入しますが、ネットワークとハードウェアの管理性を向上させるために VLAN を使用します。 VLAN は 802.1q プロトコルを使用し、VLAN 機能をサポートするネットワーク カードとスイッチが必要です。増加したハードウェア コストは、節約された運用コスト (ネットワークのインストールとメンテナンス) によって相殺されます。 VLAN を使用してクラスターとコンピューティング スタック (OpenStack、CloudStack など) 間の VM トラフィックを処理する場合でも、10G NIC を使用する価値があります。各ネットワークのラック ルータからコア ルータまでの帯域幅は、40 Gbps から 100 Gbps など、より大きくする必要があります。

サーバーはベースボード管理コントローラ (BMC) を使用して構成する必要があり、管理および展開ツールでも BMC を広範に使用する必要があるため、SSH アクセス、VM イメージのアップロード、OS のインストール、ポート管理などの管理によってネットワーク負荷が増加するアウトオブバンド ネットワーク管理のコストと利点のバランスを考慮してください。3 つのネットワークを運用するのは少し過剰ですが、各トラフィック パスは、大規模なデータ クラスターを展開する前に慎重に検討する必要がある潜在的な容量、スループット、およびパフォーマンスのボトルネックを示しています。

障害ドメイン

障害ドメインとは、1 つ以上の OSD にアクセスできなくなる障害を指します。これには、ホスト上のプロセスの停止、ハード ドライブの障害、オペレーティング システムのクラッシュ、ネットワーク カードの障害、電源の不良、ネットワークの停止、停電などが考えられます。ハードウェア要件を計画するときは、障害ドメインを削減するために多大な労力を費やすことで得られるコスト削減と、潜在的な障害ドメインをそれぞれ分離するために増加するコストなど、複数の要件のバランスを取ることが重要です。

最小ハードウェア推奨事項

Ceph は安価な汎用ハードウェア上で実行でき、小規模な本番クラスターと開発クラスターは一般的なハードウェア上で実行できます。

ハードディスクが 1 つしかないマシンで OSD を実行する場合は、データとオペレーティング システムを別のパーティションに配置する必要があります。一般的に、オペレーティング システムとデータには異なるハード ディスクを使用することをお勧めします。

本番環境クラスタインスタンス

PB レベルの本番クラスターでも通常のハードウェアを使用できますが、トラフィックの負荷に対応するために、より多くのメモリ、CPU、およびデータ ストレージ スペースを備える必要があります。

弊社の生産環境のハードウェア構成

CPU: 2*12C
メモリ: 512G
ハードディスク: 20*1.2T
ネットワークカード: 2*10Gb