Ceph クラスターを構築したいのですか？

1 メガバイトのストレージ単価が重要な場合、最大数のディスクと最大ディスクを搭載するサーバーに引き寄せられるのは当然でしょう。

ここで注意していただきたいことがあります。 狭くて深い」クラスターには、いくつかの考慮事項があります:

1. 各ノードがクラスターのデータのより大きな割合を保持します。 例: 3 ノード クラスターでは、各ノードがデータの 33% を保持します。 10ノードクラスタでは、1ノードあたり10%にとどまります。 小規模なクラスターで 1 つのノードを失うと、特にクラスターがいっぱいになり始めると、データの移行が大幅に増加し、クラスターのフルおよびフルに近い比率を正しく構成していない場合は停止する可能性があります。 Cephはネットワークベースのストレージシステムであるため、ノード数が少ないと、より少ないNICで多くのクライアント・トラフィックを強制的に処理することになります。 ノードあたりのディスク数が増えると、限られた帯域幅でより多くのOSDが競合するため、これはさらに悪化します。 さらに悪いことに、回復イベントの間、回復トラフィックはネットワーク上のクライアント I/O と競合し、ユーザー エクスペリエンスにさらに影響を与えます。
2. ノードあたりのディスク数が多い場合、すべてのディスクをフル速度で伝送するのに十分な帯域幅がないと、ディスク コントローラーがボトルネックとなる場合があります。
3. ノード全体を失った場合、より多くのデータを複製および回復する必要があるため、回復およびヒーリング時間が増加します。

クラスタの集約パフォーマンスは、ノード数が増加すると非常によくスケールします。 ここでは、BlueStoreを使用した3ノードと5ノードのクラスターを比較しています。

大規模なクラスターを目指している場合、すべてのディスクをできるだけ少ないノードに詰め込むという誘惑に打ち勝ちましょう。

要約すると、

• Cephはノード数が増加すると非常によくスケールします。
• クラスタのノード数が少なすぎると、各ノードにクラスタデータが多く置かれ、回復I/Oと回復時間が増加します。
• 最小で 3 つのノードから始めることができますが、ディスクをより多くのノードに分散させる余裕がある場合は、そうする方がよいでしょう。 最低でも運用には 10GbE を目指し、帯域幅を広げるために LACP (Link Aggregation Control Protocol) で結合された複数の 10Gb インターフェイスを持つようにするのが良いでしょう。 Cephはネットワークベースのストレージシステムなので、クラスタに欠けてはならないものの1つはネットワーク帯域幅です。

  パブリック向けのネットワークとクラスタ内部のネットワークは常に分離してください。 パブリック ネットワークはクライアント トラフィックを搬送し、内部ネットワークは OSD 間のハートビート、レプリケーション、およびリカバリ トラフィックを搬送します。 NICに余裕がある場合は、この2つのネットワークを別々のインターフェイスで転送します。 これらを分離すると、リカバリ イベント中のクライアントの応答性が向上し、リカバリ I/O が同じ NIC 上のクライアント I/O と競合しないため、リカバリ イベントがより速く完了します。

  内部ネットワークがレプリケーション トラフィックを伝送することも覚えておいてください。 Cephは、すべてのレプリカのジャーナル/WALに書き込まれたときにのみ、クライアントへの書き込みを認識します – したがって、レプリケーション書き込みがネットワーク上でボトルネックにならないようにする必要があります。 レプリケート プールを多用する場合は、クラスタ ネットワークのサイズをパブリック ネットワークの n-1 倍にすることを検討してください。

  最後に、冗長性のために、冗長トップ オブ ラックスイッチにノードを配線していることを確認してください。 1 つのスイッチが故障したために、ノード全体、またはノードのセットを失いたくないのです。

  まとめると、

  • 10Gbit Ethernet は少なくとも生産用。
  • パブリック ネットワークとクラスタ ネットワークを分離し、理想的には異なる NIC に、少なくとも異なる VLAN/サブネットにします。
  • 複製データの (n-1) 経験則を覚えておいてください。
  • 冗長性のためのケーブル接続と、オペレーティング システム レベルで正しく結合を確立することを忘れないでください。

  BlueStore メタデータ用のフラッシュメディア。

  Ceph は、データがプライマリ OSD のライトアヘッドログ (WAL) とすべてのレプリカの WAL に書き込まれた後、クライアントへの書き込みを認識します。 WALへの書き込みが高速であればあるほど、Cephは書き込みを高速で認識し、クライアントの書き込みIOPSが向上します。

  WAL、および理想的にはBlueStore RocksDBメタデータは、取得できる最速のメディア、最低でもSSD、可能ならNVMeに置く必要があります。 フル HDD クラスターを構築する場合、ノードごとに少し追加費用をかけ、メタデータと WAL 用に少なくとも 2 つの高速メディア デバイスを追加することを強く検討します。

  高速メディア デバイスのボトルネックを回避するには、データ ディスクの持続書き込み速度を考慮し、それを高速デバイスの持続書き込み速度と比較します。 HDD が 100MB/s で持続的に書き込め、SSD が 500MB/s で持続的に管理できる場合、SSD あたり 4 ～ 5 個以上の OSD があると、書き込みの際に SSD がボトルネックになります。 NVMe は、持続的な書き込み速度が 1 秒あたりギガバイトに達するため、このユースケースに最適です。

  最後に、メタデータ デバイスが故障しても、ノード上のすべての OSD を失うことがないように、ノードあたり常に複数の SSD/NVMe デバイスをメタデータ/ウォール用に用意することです。

  要約すると、

  • Cephは、クライアントへの書き込みがプライマリOSDのWALおよびすべてのレプリカのWALに書き込まれたときに、それを認識します。 これは、データの整合性を維持するために行います。
  • WAL および RocksDB は、クライアントへの応答をできるだけ早く得るために、取得できる最速メディア (理想的には NVMe) にあるべきです。
  • WAL/RocksDB に高速デバイスを過剰登録しないようにしてください。 8149>

  まとめ

  Ceph はネットワークベースの Software-Defined Storage システムであり、非常によく水平方向に拡張されます。 狭すぎず深すぎず、クラスタに帯域幅を供給し続け、メタデータとWALに高速なメディアを使用します。