検索

3.2. 配置グループの制限

download PDF

より多くの配置グループに対するすべての OSD 呼び出し間のデータの持続性とデータの分散性以外にも、CPU とメモリーリソースを節約するための最大パフォーマンスを最大化するために最低限必要な数を減らす必要があります。

3.2.1. データの永続性

Ceph はデータの永続的な損失を防ぐように努めます。ただし、OSD が失敗すると、含まれるデータが完全に回復するまで、永続的なデータの損失のリスクが高まります。まれに、永続的なデータ損失を使用することは可能です。以下のシナリオとして、Ceph が 1 つの配置グループのデータを永続的に失った方法が、3 つのデータのコピーで永久に失われるシナリオを説明します。

  • OSD が失敗し、これに含まれるオブジェクトのすべてのコピーが失われます。OSD に保管されている配置グループ内のすべてのオブジェクトについて、レプリカ数を 3 から 2 に破棄します。
  • Ceph は、新規 OSD を選択して、各配置グループの全オブジェクトの 3 つ目のコピーを再作成して、失敗した OSD に保管されている各配置グループのリカバリーを開始します。
  • 新しい OSD が完全にコピー 3 つになるまで、同じ配置グループのコピーを含む 2 つ目の OSD は失敗します。一部のオブジェクトには、コピーが 1 つだけ含まれます。
  • Ceph はまだ別の OSD を選択し、オブジェクトをコピーして必要なコピー数を復元します。
  • リカバリーが完了するまで、同じ配置グループのコピーを含む 3 つ目の OSD は失敗します。この OSD にオブジェクトの残りのコピーのみが含まれる場合、オブジェクトは永続的に失われます。

ハードウェア障害は例外ではありませんが、予想されます。前述のシナリオを防止するには、リカバリープロセスを最速に行いておく必要があります。クラスターのサイズ、ハードウェア構成、および配置グループの数は、復旧時間の合計における重要な役割を果たします。

小規模なクラスターはすぐにリカバリーしません。

3 つのレプリカプールに 512 の配置グループと共に 10 OSD が含まれるクラスターでは、CRUSH ごとに配置グループ 3 つが提供されます。各 OSD は、ホスト (512 * 3) / 10 = ~150 の配置グループになります。最初の OSD が失敗すると、クラスターは 150 のすべての配置グループのリカバリーを同時に開始します。

Ceph は、9 つの残りの OSD にわたり、残りの 150 の配置グループをランダムに保存している可能性があります。したがって、残りの OSD は、現在割り当てられている 150 個の配置グループの一部を担当することになるため、残りの各 OSD は、他のすべての OSD にオブジェクトのコピーを送信する可能性が高く、また、いくつかの新しいオブジェクトを受け取る可能性があります。

リカバリー合計時間は、プールをサポートするハードウェアによって異なります。たとえば、10 OSD クラスターにおいて、ホストに 1TB SSD を持つ OSD が 1 つあり、10GB/s スイッチが 10 個の各ホストを接続すると、復旧に M 分かかります。一方、ホストに 2 つの SATA OSD が含まれ、1GB/s スイッチが 5 台に接続すると、復元が大幅に長くなります。同様に、このサイズのクラスターで、配置グループの数に直面的には、データの持続性に影響を与えることはありません。配置グループ数は 128 または 8192 で、復元速度は遅くなったり、速くなったりしません。

ただし、同じ Ceph クラスターを 10 OSD ではなく 20 個の OSD に拡張すると、復元を迅速化するため、データの持続性が大幅に向上します。なぜですか?各 OSD は 150 ではなく、75 の配置グループしか参加しません。20 個の OSD クラスターでは、回復するために同じコピー操作を実行するには、残り 19 個すべての OSD が必要になります。10 OSD クラスターでは、各 OSD は約 100 GB をコピーする必要がありました。各 OSD はそれぞれ 20 個の OSD クラスターでは、それぞれ 50 GB のみをコピーする必要があります。ネットワークがボトルネックである場合、リカバリーは高速になります。つまり、OSD の数が増えると、復旧時間が短縮されます。

大規模なクラスターでは、PG 数は重要です。

exemplary クラスターが 40 OSD に拡大すると、各 OSD は 35 の配置グループのみをホストします。OSD が停止した場合、別のボトルネック解決しないと、復旧時間が減少します。ただし、このクラスターが 200 個の OSD を拡張する場合、各 OSD は約 7 の配置グループのみをホストします。OSD が停止した場合、これらの配置グループにある最大 21 (7 * 3) OSD の間に復元が行われます。復元には、40 の OSD があった場合よりも時間がかかります。つまり、配置グループの数を増やす必要があります

重要

リカバリー時間は短い方法に関係ありません。復元中、他の OSD が配置グループの保存時に失敗する可能性があります。

上記の 10 OSD クラスターでは、いずれかの OSD に障害が発生した場合は、約 8 個の配置グループ (つまり、75 pgs / 9 osds が復元されます) には、残りのコピーが 1 つしかありません。残りの 8 つの OSD のいずれかが失敗すると、1 つの配置グループの最後のオブジェクトが失われる可能性があります (つまり、残りの 1 つのコピーのみが復元される 8 pgs / 8 osds など)。このため、大規模なクラスターから始まります (例: 50 OSD)。

クラスターのサイズが 20 個の OSD に増加する場合、3 つの OSD ドロップによって破損した配置グループの数が増えます。2 つ目に失われた OSD は、8 ではなく約 2 (つまり 35 pgs / 19 osds が復元) に低下し、3番目に失われた OSD は、残りのコピーを含む 2 つの OSD の 1 つである場合にのみデータを失います。つまり、回復時間枠内で 1 つの OSD が失われる確率が 0.0001% の場合は、10 OSD のクラスターの8 * 0.0001% から 20 OSD のクラスターの 2 * 0.0001% になります。データの耐性が懸念されるため、50 OSD 未満のクラスターで 512 または 4096 の配置グループがほぼ同等になります。

ヒント

つまり、OSD が多いほどリカバリーが速くなり、カスケーディングが配置グループとそのオブジェクトの永続的な損失が発生するリスクが低くなります。

OSD をクラスターに追加する場合、新しい OSD に配置グループおよびオブジェクトが追加されるまでに長い時間がかかる可能性があります。ただし、オブジェクトの低下はなく、OSD を追加するとデータの持続性は影響を受けません。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.