Ceph クライアントおよび Ceph OSD はどちらも CRUSH マップと CRUSH アルゴリズムを使用します。

複数のオブジェクトレプリカまたは M イレイジャーコーディングチャンクを使用するとデータの損失を防ぐことができますが、高可用性に対応するには十分ではありません。Ceph Storage クラスターの基礎となる物理組織を反映することで、CRUSH は、関連するデバイスの障害についてのアドレス指定元的なソースをモデル化できます。クラスターのトポロジーをクラスターマップにエンコードすることで、CRUSH 配置ポリシーは別々の障害ドメインにわたって、オブジェクトレプリカまたはイレイジャーコーディングチャンクを別々に使用できます。また、必要な疑似ランダム分散も依然として維持できます。たとえば、同時障害の可能性に対応するには、異なるシェルフ、ラック、電源、コントローラーまたは物理的な場所を使用するデバイス上または消去するチャンクがデバイスにあることが望ましい場合があります。これは、データ損失を回避し、クラスターが動作が低下した状態で動作できるようにします。

CRUSH マップは複数の階層をサポートし、ハードウェアパフォーマンスプロファイルのタイプを別のタイプから分離できます。たとえば、CRUSH はハードディスクドライブと SSD に別の階層を 1 つ作成できます。パフォーマンスドメイン: ベースとなるハードウェアのパフォーマンスプロファイルを把握する階層は、さまざまなパフォーマンス特性をサポートする必要があるため、注目されています。運用上、それらは複数の root タイプバケットを持つ CRUSH マップです。ユースケースの例を以下に示します。

RHCS 3 以降のリリースでは、CRUSH マップはデバイス class の概念をサポートします。Ceph はストレージデバイスの要素を検出し、自動的に hdd、ssd、nvme などのクラスを割り当てることができます。ただし、CRUSH はこれらのデフォルトに限定されません。たとえば、CRUSH の階層を使用して、異なるタイプのワークロードを区切られることもできます。たとえば、SSD は、ジャーナルまたはログ先行書き込み、バケットインデックス、または raw オブジェクトストレージに使用される場合があります。CRUSH は ssd-bucket-index、ssd-object-storage などの異なるデバイスクラスをサポートできるため、Ceph は異なるワークロードに同じストレージメディアを使用しないようにします。これによりパフォーマンスは予測可能で一貫性が高くなります。

CRUSH の場所は、CRUSH マップの階層に関して OSD の場所です。コマンドラインインターフェイスで CRUSH の場所を表すと、CRUSH の場所指定子は、OSD の場所を説明する名前/値のペアの一覧を取得します。たとえば、OSD が特定の行、ラック、シャーシ、およびホストにあり、default の CRUSH ツリーの一部である場合、そのクラッシュの場所は以下のように記述できます。

root=default row=a rack=a2 chassis=a2a host=a2a1

注記:

CRUSH 階層にバケットインスタンスを追加するには、バケット名とそのタイプを指定します。バケット名は CRUSH マップで一意である必要があります。

ceph osd crush add-bucket {name} {type}

たとえば、異なるハードウェアパフォーマンスプロファイルなど、複数の階層を使用する場合 (ハードウェアパフォーマンスプロファイルなど)、ハードウェアのタイプまたはユースケースに基づいてバケットの命名を検討してください。

たとえば、ソリッドステートドライブ (ssd) の階層、SSD ジャーナルのある SAS ディスクの階層 (hdd-journal)、および SATA ドライブ (hdd) に別の階層を作成できます。

ceph osd crush add-bucket ssd-root root
ceph osd crush add-bucket hdd-journal-root root
ceph osd crush add-bucket hdd-root root

Ceph CLI を出力します。

added bucket ssd-root type root to crush map
added bucket hdd-journal-root type root to crush map
added bucket hdd-root type root to crush map

階層に必要な各バケットタイプのインスタンスを追加します。以下の例は、SSD ホストのラックがある行のバケットと、オブジェクトストレージのホストのラックの追加を示しています。

ceph osd crush add-bucket ssd-row1 row
ceph osd crush add-bucket ssd-row1-rack1 rack
ceph osd crush add-bucket ssd-row1-rack1-host1 host
ceph osd crush add-bucket ssd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1 row
ceph osd crush add-bucket hdd-row1-rack2 rack
ceph osd crush add-bucket hdd-row1-rack1-host1 host
ceph osd crush add-bucket hdd-row1-rack1-host2 host
ceph osd crush add-bucket hdd-row1-rack1-host3 host
ceph osd crush add-bucket hdd-row1-rack1-host4 host

これらの手順を完了したら、ツリーを表示します。

ceph osd tree

階層はフラットのままである点に注意してください。CRUSH マップに追加した後に、バケットを階層の位置に移動する必要があります。

初期クラスターの作成時に、Ceph には default という名前のルートバケットのあるの CRUSH マップがあり、初期 OSD ホストは default のバケットに表示されます。CRUSH マップにバケットインスタンスを追加する場合、これは CRUSH 階層に表示されますが、必ずしも特定のバケットに表示されるわけではありません。

CRUSH 階層の特定の場所にバケットインスタンスを移動するには、バケット名とそのタイプを指定します。以下に例を示します。

ceph osd crush move ssd-row1 root=ssd-root
ceph osd crush move ssd-row1-rack1 row=ssd-row1
ceph osd crush move ssd-row1-rack1-host1 rack=ssd-row1-rack1
ceph osd crush move ssd-row1-rack1-host2 rack=ssd-row1-rack1

これらの手順を完了したら、ツリーを表示できます。

ceph osd tree

CRUSH 階層からバケットインスタンスを削除するには、バケット名を指定します。以下に例を示します。

ceph osd crush remove {bucket-name}

または、以下を実行します。

ceph osd crush rm {bucket-name}

高レベルのバケット (例: default などのルート) を削除する場合は、プールがそのバケットを選択する CRUSH ルールを使用するかどうかを確認します。その場合は、CRUSH ルールを変更する必要があります。指定しない場合は、ピアリングに失敗します。

Ceph CLI を使用してバケットを作成する場合、Ceph はデフォルトでアルゴリズムを straw に設定します。Ceph は 4 つのバケットアルゴリズムをサポートします。各アルゴリズムは、パフォーマンスと組織の効率間のトレードオフを示しています。使用するバケットタイプが不明な場合は、straw バケットを使用することが推奨されます。バケットアルゴリズムは次のとおりです。

ceph osd crush tree コマンドは、CRUSH バケットと項目をツリービューで出力します。このコマンドを使用して、特定のバケット内の OSD の一覧を確認します。ceph osd tree のような出力が表示されます。

詳細情報を返すには、以下のコマンドを実行します。

# ceph osd crush tree -f json-pretty

このコマンドは、以下のような出力を返します。

[
    {
        "id": -2,
        "name": "ssd",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -6,
                "name": "dell-per630-11-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 6,
                        "name": "osd.6",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -7,
                "name": "dell-per630-12-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 7,
                        "name": "osd.7",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -8,
                "name": "dell-per630-13-ssd",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 8,
                        "name": "osd.8",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.099991,
                        "depth": 2
                    }
                ]
            }
        ]
    },
    {
        "id": -1,
        "name": "default",
        "type": "root",
        "type_id": 10,
        "items": [
            {
                "id": -3,
                "name": "dell-per630-11",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 0,
                        "name": "osd.0",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 3,
                        "name": "osd.3",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -4,
                "name": "dell-per630-12",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 1,
                        "name": "osd.1",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 4,
                        "name": "osd.4",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            },
            {
                "id": -5,
                "name": "dell-per630-13",
                "type": "host",
                "type_id": 1,
                "items": [
                    {
                        "id": 2,
                        "name": "osd.2",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.449997,
                        "depth": 2
                    },
                    {
                        "id": 5,
                        "name": "osd.5",
                        "type": "osd",
                        "type_id": 0,
                        "crush_weight": 0.289993,
                        "depth": 2
                    }
                ]
            }
        ]
    }
]

OSD を CRUSH 階層に追加することは、OSD を起動する前の最後のステップ (up および in を編集する) であり、Ceph は配置グループを OSD に割り当てます。

OSD を準備してから、CRUSH 階層を追加する必要があります。Ansible 自動化アプリケーションなどのデプロイメントユーティリティーで、このステップを実行します。詳細は、OSD の追加/削除を参照してください。

CRUSH 階層は概念であるため、ceph osd crush add コマンドを使用すると、希望する場所の CRUSH 階層に OSD を追加できます。指定する場所は、実際の場所を反映している はず です。少なくとも 1 つのバケットを指定すると、コマンドにより OSD を指定する最も具体的なバケットに配置され、かつ そのバケットは指定した他のバケットの下に移動します。

OSD を CRUSH 階層に追加するには、以下を実行します。

ceph osd crush add {id-or-name} {weight}  [{bucket-type}={bucket-name} ...]

以下の例では、osd.0 を階層に追加します。

ceph osd crush add osd.0 1.0 root=default datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

Ansible 自動化アプリケーションなど、デプロイメントユーティリティーで OSD が準最適な CRUSH ロケーションで CRUSH マップに追加された場合や、クラスタートポロジーが変更された場合は、CRUSH 階層内の OSD を移動して実際の場所を反映させることができます。

CRUSH 階層内の OSD を移動するには、以下を実行します。

ceph osd crush set {id-or-name} {weight} root={pool-name}  [{bucket-type}={bucket-name} ...]

CRUSH 階層からの OSD 削除は、クラスターから OSD を削除する場合の最初の手順となります。CRUSH マップから OSD を削除すると、CRUSH は配置グループおよびデータリバランスを取得する OSD が再計算されます。詳細は、OSD の追加/削除を参照してください。

実行中のクラスターの CRUSH マップから OSD を削除するには、以下を実行します。

ceph osd crush remove {name}

OSD にデバイスクラスを設定するには、次のコマンドを実行します。

# ceph osd crush set-device-class <class> <osdId> [<osdId>...]

以下に例を示します。

# ceph osd crush set-device-class hdd osd.0 osd.1
# ceph osd crush set-device-class ssd osd.2 osd.3
# ceph osd crush set-device-class bucket-index osd.4

OSD のデバイスクラスを削除するには、以下を実行します。

# ceph osd crush rm-device-class <class> <osdId> [<osdId>...]

以下に例を示します。

# ceph osd crush rm-device-class hdd osd.0 osd.1
# ceph osd crush rm-device-class ssd osd.2 osd.3
# ceph osd crush rm-device-class bucket-index osd.4

そのクラスを使用するすべての OSD のデバイスクラスの名前を変更するには、以下のコマンドを実行します。

# ceph osd crush class rename <oldName> <newName>

以下に例を示します。

# ceph osd crush class rename hdd sas15k

CRUSH マップのデバイスクラスを一覧表示するには、以下を実行します。

# ceph osd crush class ls

出力は以下のようになります。

[
    "hdd",
    "ssd",
    "bucket-index"
]

特定のクラスに属するすべての OSD を一覧表示するには、以下のコマンドを実行します。

# ceph osd crush class ls-osd <class>

以下に例を示します。

# ceph osd crush class ls-osd hdd

出力は、OSD 番号のリストです。以下に例を示します。

0
1
2
3
4
5
6

同じクラスを参照する crush ルールを一覧表示するには、以下のコマンドを実行します。

# ceph osd crush rule ls-by-class <class>

以下に例を示します。

# ceph osd crush rule ls-by-class hdd

CRUSH マップ内の Terabytes で OSD CRUSH 重みを設定するには、以下のコマンドを実行します。

ceph osd crush reweight {name} {weight}

詳細は以下のようになります。

この設定は、OSD を作成するか、OSD の追加直後に CRUSH 重みを調整する際に使用されます。通常、OSD のライフサイクルは変更されません。

ceph osd crush reweight を使用すると、時間がかかる可能性があります。以下を実行して、すべての Ceph OSD 加重をバケット (行、ラック、ノードなど) の下で設定できます。

osd crush reweight-subtree <name>

詳細は以下のようになります。

name は CRUSH バケットの名前です。

ceph osd in および ceph osd out の目的上、OSD はクラスター内 (in) か、クラスター外 (out) のいずれかにあります。これは、モニターする OSD のステータスを記録します。ただし、OSD はクラスター内 in となりますが、修正されるまでは依存したくない機能 (ストレージドライブの置き換え、コントローラーの変更など) 生する可能性があります。

以下を実行して (つまり、テラバイト単位でその重みを変更せずに)、以下のコマンドを実行して、特定の OSD の in 重みを増減できます。

ceph osd reweight {id} {weight}

詳細は以下のようになります。

CRUSH は、新しいデータオブジェクトの PG と PG を OSD に割り当てる書き込み要求のための一貫した確率分散を概観するために設計されています。ただし、クラスターは任意に負荷分散される可能性があります。これは、さまざまな理由で発生する可能性があります。以下に例を示します。

以下を実行することで、使用率に従って OSD を再度有効にできます。

ceph osd reweight-by-utilization [threshold]  [weight_change_amount] [number_of_OSDs] [--no-increasing]

以下に例を示します。

ceph osd test-reweight-by-utilization 110 .5 4 --no-increasing

詳細は以下のようになります。

重みを割り当てる上記またはその他の重みのコマンドを実行すると、このコマンドによって割り当てられる重みが上書きされます (例: osd reweight-by-utilization、osd crush weight、osd weight、in、または out)。

少数の OSD を持つ CRUSH 階層では、一部の OSD が他の OSD よりも長い PG を取得できるため、負荷が高くなることがあります。以下のコマンドを実行して、この状況に対処するために PG ディストリビューションで OSD を再非推奨にすることができます。

osd reweight-by-pg <poolname>

詳細は以下のようになります。

CRUSH ツリーバケットは、リーフの重みの合計である必要があります。CRUSH マップの重みを手動で編集する場合は、以下を実行し、CRUSH バケットツリーがバケット内のリーフ OSD の合計を正確に反映するようにする必要があります。

osd crush reweight-all

コマンドラインから CRUSH ルールを一覧表示するには、以下を実行します。

ceph osd crush rule list
ceph osd crush rule ls

特定の CRUSH ルールの内容をダンプするには、以下を実行します。

ceph osd crush rule dump {name}

CRUSH ルールを追加するには、使用する階層のルートノード、複数の複製するバケットタイプ (例: 'rack'、'row' など)、バケットを選択するモードを指定する必要があります。

ceph osd crush rule create-simple {rulename} {root} {bucket-type} {firstn|indep}

Ceph は、chooseleaf と、指定したタイプのバケットを 1 つ使用してルールを作成します。

以下に例を示します。

ceph osd crush rule create-simple deleteme default host firstn

以下のルールを作成します。

{ "rule_id": 1,
  "rule_name": "deleteme",
  "ruleset": 1,
  "type": 1,
  "min_size": 1,
  "max_size": 10,
  "steps": [
        { "op": "take",
          "item": -1,
          "item_name": "default"},
        { "op": "chooseleaf_firstn",
          "num": 0,
          "type": "host"},
        { "op": "emit"}]}

レプリケートされたプールに CRUSH ルールを作成するには、以下を実行します。

# ceph osd crush rule create-replicated <name> <root> <failure-domain> <class>

詳細は以下のようになります。

以下に例を示します。

# ceph osd crush rule create-replicated fast default host ssd

イレイジャーコードプールで使用する CRUSH ルールを追加するには、ルール名とイレイジャーコードプロファイルを指定できます。

ceph osd crush rule create-erasure {rulename} {profilename}

ルールを削除するには、以下を実行し、CRUSH ルール名を指定します。

ceph osd crush rule rm {name}

バージョン 0.48 より前の Ceph クライアントおよびデーモンは、調整可能を検出せず、バージョン 0.48 以降と互換性がありません。アップグレードする必要があります。調整可能パラメーター CRUSH の値も、主要な Ceph リリースと共に進化しました。

CRUSH を調整する前に、すべての Ceph クライアントおよびすべての Ceph デーモンが同じバージョンを使用するようにする必要があります。最近アップグレードした場合は、デーモンを再起動して、クライアントを再接続していることを確認します。

CRUSH パラメーターを調整する最も簡単な方法は、既知のプロファイルに変更します。以下のとおりです。

実行中のクラスターでプロファイルを選択するには、以下のコマンドを実行します。

# ceph osd crush tunables <profile>

通常、アップグレード後に CRUSH パラメーターを設定するか、警告が表示されるようにする必要があります。バージョン v0.74 以降では、CRUSH パラメーターが最適な値に設定されていない場合に、Ceph は健全性についての警告を発行します。最適な値は v0.73 のデフォルトになります。この警告を外すには、2 つのオプションがあります。

すべてのクライアントが最新のコードを実行していることを確認できる場合は、CRUSH マップを抽出して値を変更し、これをクラスターへ再ミラーリングすることで、調整可能パラメーターを調整できます。

詳細は、CRUSH 調整可能パラメーターのレガシー値を設定できます。

crushtool -i /tmp/crush --set-choose-local-tries 2 --set-choose-local-fallback-tries 5 --set-choose-total-tries 19 --set-chooseleaf-descend-once 0 --set-chooseleaf-vary-r 0 -o /tmp/crush.legacy

ここでも、特別な --enable-unsafe-tunables オプションが必要になります。さらに、上記のように、機能ビットが完全に適用されていないため、レガシー値に戻した後、古いバージョンの ceph-osd デーモンを実行する場合は注意が必要です。

クラスターの CRUSH マップを取得するには、以下を実行します。

ceph osd getcrushmap -o {compiled-crushmap-filename}

Ceph は、コンパイルされた CRUSH マップを指定したファイル名に出力 (-o) します。CRUSH マップはコンパイルフォームにあるため、これを編集する前に先にコンパイルする必要があります。

CRUSH マップをコンパイルするには、以下を実行します。

crushtool -d {compiled-crushmap-filename} -o {decompiled-crushmap-filename}

Ceph は、コンパイルされた CRUSH マップと出力 (-o) を指定したファイル名にコンパイル (-d) します。

CRUSH マップをコンパイルするには、以下を実行します。

crushtool -c {decompiled-crush-map-filename} -o {compiled-crush-map-filename}

Ceph は、コンパイルされた CRUSH マップを指定したファイル名に保存します。

クラスターに CRUSH マップを設定するには、以下を実行します。

ceph osd setcrushmap -i  {compiled-crushmap-filename}

Ceph は、クラスターの CRUSH マップとして指定したファイル名のコンパイルされた CRUSH マップを入力します。

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

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

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

リカバリー合計時間は、プールをサポートするハードウェアによって異なります。たとえば、10 OSD クラスターにおいて、ホストに 1 TB SSD を持つ OSD が 1 つあり、10 GB/s スイッチが 10 個の各ホストを接続すると、復旧に M 分かかります。一方、ホストに 2 つの SATA OSD が含まれ、1 GB/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 の数が増えると、復旧時間が短縮されます。

上記の 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 を追加するとデータの持続性は影響を受けません。

Cepth はホットスポットを避けるようにします。一部の OSD は、その他の OSD よりも多くのトラフィックを受信します。理想的には、CRUSH は配置グループにオブジェクトを均等に割り当て、配置グループが OSD (またはランダムに擬似) に割り当てられる場合でも、プライマリー OSD は、クラスター全体に均等に分散され、ホットスポットやネットワークオーバーサブスクリプションの問題が発生しないようにオブジェクトをストアします。

CRUSH は各オブジェクトの配置グループを計算するが、実際にはこの配置グループ内の各 OSD に保管されるデータの量を認識しないため、配置グループの数と OSD の数の比率が、データの分散に大きく影響する可能性があります。

たとえば、3 つのレプリカプールに OSD が 10 個しかない配置グループが 1 つしかない場合、Ceph は CRUSH には他の選択がないために 3 つの OSD だけを使用します。より多くの配置グループを利用できる場合、CRUSH はオブジェクトを OSD 全体に均等に分散させる可能性が高くなります。また、CRUSH は配置グループを OSD に均等に割り当てます。

OSD よりも多くの配置グループの順序が 1 つまたは 2 つまたは 2 つある限り、ディストリビューションも OSD よりも多くの配置グループで設定される必要があります。たとえば、OSD 3 つは 256 の配置グループ、10 個は OSD 用 512 または 1024 の配置グループなどとなります。

OSD と配置グループの割合は、通常、オブジェクトストライピングのような高度な機能を実装する Ceph クライアントのデータ分散の問題を解決します。たとえば、4 TB ブロックデバイスでは、4 MB オブジェクトになる可能性があります。

CRUSH はオブジェクトサイズを考慮しないため、OSD と配置グループ間の比率は、他のケースで不均等なデータ分散に対応しません。librados インターフェイスを使用して、いくつかの比較的小さなオブジェクトといくつかの非常に大きなオブジェクトを格納すると、データの分散が不均一になる可能性があります。たとえば、10 個の OSD 上に 1,000 個の配置グループの中に、合計 100 万個の 4K オブジェクト (合計で 4 GB) が均等に配置されています。各 OSD で 4 GB / 10 = 400 MB が使用されます。プールに 400 MB オブジェクト 1 つが追加されると、オブジェクトの配置先の配置グループをサポートする 3 つの OSD で 400 MB + 400 MB = 800 MB が使用され、残りの 7 つの OSD は 400 MB のみで占有されます。

各配置グループ、OSD および Ceph モニターにはメモリー、ネットワーク、および CPU を常時必要とし、復旧中にさらに必要です。配置グループ内のクラスターリングオブジェクトによるこのオーバーヘッドの共有は、主な配置グループのいずれかです。

配置グループの数を最小限にすると、リソースの量が大きくなります。

PG の計算ツールを使用して、特定のユースケースに対応する配置グループの数を計算しています。PG の計算ツールは、通常同じルール (CRUSH 階層) を使用して Ceph Object Gateway などの Ceph クライアントを使用する場合に特に役立ちます。引き続き、小規模クラスターの PG 数 および PG 数の計算 に関するガイドラインを使用して手動で PG を手動で計算することもできます。ただし、PG の計算ツールは、PG を計算する方法として推奨されています。

詳細は、Red Hat カスタマーポータル の Ceph Placement Groups (PGs) per Pool Calculator を参照してください。

プールの作成時に、プールに配置グループの数も作成します。配置グループの数を指定しない場合、Ceph はデフォルト値 32 を使用します。これは一部のプールでは小さい値です。プールの配置グループ数を増やすことはできますが、Ceph 設定ファイルで妥当なデフォルト値を設定することを推奨します。

osd pool default pg num = 1024
osd pool default pgp num = 1024

配置グループ (合計) 数と、オブジェクトに使用される配置グループの数 (PG 設定で使用) の両方を設定する必要があります。これらは等しい必要があります。

小規模なクラスターでは、多くの配置グループには利点はありません。OSD の数が増えると、pg_num および pgp_num が正しい値を選択することが重要になります。これは、クラスターの動作に大きな影響を与えるだけでなく、異常が発生した時のデータの耐久性 (致命的なイベントによってデータ損失が発生する可能性) があるためです。小規模なクラスターで PG 計算ツール を使用することが重要です。

OSD が 50 を超える場合は、リソース使用状況、データ耐性、分散のバランスを取るために、OSD ごとに約 50 - 100 個の配置グループを推奨します。OSD が 50 未満の場合は、Small クラスターの PG 数などを選択することが理想的です。オブジェクトのプール 1 つに対して、以下の式を使用してベースラインを取得できます。

                (OSDs * 100)
   Total PGs =  ------------
                 pool size

プールサイズ は、(ceph osd erasure-code-profile get によって返される) レプリケートされたプールのレプリカ数、または異例ジャーコードされたプールの K+M 合計になります。

次に、データの永続性を最大化し、データ分散を最大化し、リソースの使用を最小限に抑えるために、Ceph クラスターが設計した内容が適切かどうかを確認する必要があります。

結果は、最も近い 2 の累乗に切り上げられる必要があります。数の丸めはオプションですが、CRUSH では配置グループ間でオブジェクト数を均等に分散させることが推奨されます。

OSD が 200 でプールサイズ 3 つのレプリカのクラスターの場合、以下のように PG 数を見積もります。

   (200 * 100)
   ----------- = 6667. Nearest power of 2: 8192
        3

8192 個の配置グループを 200 個の OSD に分散することで、OSD ごとに約 41 の配置グループを評価します。また、クラスターで使用される可能性のあるプールの数も考慮する必要があります。これは、各プールで配置グループが作成されるので、クラスターで使用される可能性も検討する必要があります。妥当な 最大 PG 数 があることを確認します。

オブジェクト格納に複数のデータプールを使用する場合は、プールごとの配置グループの数と、OSD ごとの配置グループの合計数が妥当な数になるように、配置グループの合計数のバランスを取る必要があります。この目的は、システムリソースに負荷をかけたり、ピアリングプロセスを遅らせずに、OSD ごとのさまざまな負荷を達成することにあります。

たとえば、10 個の OSD 上の 512 の配置グループを持つ、10 個のプールで設定される Ceph Storage クラスターでは、10 個を超える OSD に広がる 5120 の配置グループや、OSD ごとに 512 の配置グループがあります。ハードウェアの設定によっては、リソースが多すぎる可能性があります。これとは対照的に、512 個の配置グループをそれぞれに持つ 1,000 プールを作成する場合、OSD はそれぞれの配置グループ 50,000 までを処理し、より多くのリソースが必要になります。OSD ごとの配置グループが多すぎると、特にリバランスまたは復旧時にパフォーマンスが大幅に低下します。

Ceph Storage Cluster には、OSD ごとに最大 300 の配置グループの最大値があります。Ceph 設定ファイルに異なる最大値を設定することができます。

mon_max_pg_per_osd

Red Hat Ceph Storage クラスターの各プールには PG の pg_autoscale_mode プロパティーがあり、これを off、on、または warn に設定することができます。

pg_autoscale_mode のデフォルト値は、warn モードです。

SIZE は、プールに保存されているデータ量です。TARGET SIZE は、管理者が指定したデータ量を指しますが、最終的にこのプールに格納されることが予想されます。システムは、計算には、 2 つの値の大きいほうを使用します。

RATE は、プールが使用する RAW ストレージ容量を決定するプールの乗数です。たとえば、3 つのレプリカプールは 3.0 の比率を持ち、k=4,m=2 イレイジャーコードプールの比率は 1.5 になります。

RAW CAPACITY は、プールのデータを保存する OSD 上の RAW ストレージ容量の合計量です。RATIO は、プールが消費している合計容量の比率です。つまり、ratio = size * rate / raw capacity になります。

TARGET RATIO (存在する場合) は、ターゲット比率が設定された他のプールと相対的にプールが消費することが予想されるストレージの比率です。ターゲットサイズバイトと比率の両方が指定される場合、比率が優先されます。

EFFECTIVE RATIO は、次の 2 つの方法で調整した後の目標比率です。1 (目標サイズが設定されたプールで使用されると予想される容量を差し引く)。2. ターゲット比率が設定されたプール間でターゲット比率を正規化し、残りの領域を結合します。たとえば、target ratio が 1.0 の 4 つのプールの effective ratio は 0.25 になります。システムは、実際の比率が大きい場合と、その計算に効果的な比率を使用します。

BIAS は、PG の数に関して、あるプールを他のプールよりも速くスケーリングするために、PG Autoscaler によって使用されるプールプロパティーです。これは基本的に、デフォルトの PG 数よりも多くの PG をプールに提供するために使用する乗数です。このプロパティーは、サイズが小さくてもオブジェクト数が多いメタデータプールに特に使用されるため、パフォーマンスを向上させるには、より迅速にスケーリングすることが重要です。BIAS のデフォルト値は 1.0 です。この値は、ceph osd pool set pool-name pg_autoscale_bias 4 コマンドを実行して設定できます。許可される値は 0 から 1000 までです。ただし、CephFS メタデータプールおよび Ceph Object Gateway インデックスプールでは、BIAS の値をデフォルトで 4.0 に設定することが推奨されます。

PG_NUM は、プールの現在の PG 数、または pg_num の変更が進行中である場合にプールが現在操作している PG 数です。NEW PG_NUM が存在する場合は、推奨される PG 数 (pg_num) です。これは常に 2 の累乗となり、推奨される値は現在の値のみによって 3 倍以上になります。

AUTOSCALE はプール pg_autoscale_mode で、on、off、または warn のいずれかになります。

クラスターの使用状況に基づいて PG を自動的にスケーリングできるようにするのは、PG をスケーリングする最も簡単な方法です。Red Hat Ceph Storage は、利用可能なストレージと、全システムにおける PG のターゲット数を取得して、各プールに保存されたデータ量を比較し、それに応じて PG を評価します。このコマンドは、現在の PG 数 (pg_num) が計算または提案された PG 数から 3 倍以上ずれているプールにのみ変更を加えます。

各 OSD の PG のターゲット数は、mon_target_pg_per_osd 設定に基づいています。デフォルト値は 100 に設定されています。

新規作成されたプールは、クラスター容量の合計を少少なく、システムが PG の数を必要とするシステムに表示されます。ただし、ほとんどの場合、クラスター管理者は、どのプールが時間とともにシステム容量を消費することを認識します。Red Hat Ceph Storage への ターゲットサイズ として知られるこの情報を提供する場合、このようなプールは最初からより適切な数の PG (pg_num) を使用できます。このアプローチは、調整を行う際に、pg_num における後続の変更やデータの移動に関連するオーバーヘッドを防ぎます。

プールの target size は、以下の方法で指定できます。

プール内の配置グループの数を設定するには、プールの作成時に配置グループの数を指定する必要があります。詳細は、プールの作成 を参照してください。プールの作成後に配置グループの数を変更するには、次の手順を実行します。

ceph osd pool set {pool-name} pg_num {pg_num}

配置グループの数を増やしたら、クラスターがリバランスする前に、配置 (pgp_num) の配置グループの数も増やす必要があります。pgp_num は pg_num と同じである必要があります。pgp_num は、CRUSH アルゴリズムによる配置が考慮される配置グループの数になります。pg_num を増やすと配置グループが分割されますが、配置用の配置グループ、つまり pgp_num が増えるまで、データは新しい配置グループに移行されません。配置の配置グループの数を増やすには、以下のコマンドを実行します。

ceph osd pool set {pool-name} pgp_num {pgp_num}

PG の数を減らすと、pgp_num は自動的に調整されます。

プール内の配置グループの数を取得するには、以下のコマンドを実行します。

ceph osd pool get {pool-name} pg_num

クラスター内の配置グループの統計を取得するには、以下を実行します。

ceph pg dump [--format {format}]

有効な形式は plain (デフォルト) および json です。

指定された状態で固まったすべての配置グループを取得するには、以下を実行します。

ceph pg dump_stuck {inactive|unclean|stale|undersized|degraded [inactive|unclean|stale|undersized|degraded...]} {<int>}

Inactive 配置グループは、最新のデータを持つ OSD が up で in になることを待っているため、読み取りや書き込みを処理できません。

Unclean 配置グループには、希望する回数を複製しないオブジェクトが含まれます。これらは回復中である必要があります。

Stale 配置グループは不明な状態にあります それをホストする OSD は、しばらくモニタークラスターに対して報告されていない OSD です (mon_osd_report_timeout で設定されます)。

有効な形式は plain (デフォルト) および json です。このしきい値は、返される統計に含める前に、配置グループがス詰まった最小秒数を定義します (デフォルトは 300 秒)。

特定の配置グループの配置グループマップを取得するには、以下のコマンドを実行します。

ceph pg map {pg-id}

以下に例を示します。

ceph pg map 1.6c

Ceph は配置グループマップ、配置グループ、および OSD のステータスを返します。

osdmap e13 pg 1.6c (1.6c) -> up [1,0] acting [1,0]

特定の配置グループの統計を取得するには、以下のコマンドを実行します。

ceph pg {pg-id} query

配置グループをスクラブするには、以下のコマンドを実行します。

ceph pg scrub {pg-id}

Ceph はプライマリーノードとレプリカノードを確認し、配置グループ内の全オブジェクトのカタログを生成し、オブジェクトが見つからないか、一致しないか、その内容の一貫性を保つようにします。レプリカがすべて一致したことを想定すると、最終的なセマンティックスイープにより、すべてのスナップショット関連のオブジェクトメタデータの一貫性が確保されます。エラーはログにより報告されます。

クラスターが 1 つ以上のオブジェクトが失われ、失われたデータの検索を破棄した場合、失われたオブジェクトを lost とマークする必要があります。

可能なロケーションがすべてクエリーされ、オブジェクトが依然として失われている場合は、失われたオブジェクトは諦めるしかありません。この障害には、書き込み自体が復旧する前に実行された書き込みについて、クラスターが認識できるようにする、障害上の組み合わせが発生したことが考えられます。

現時点で、サポートされる唯一のオプションは revert です。これはオブジェクトの以前のバージョンにロールバックするか、(新しいオブジェクトの場合は) 完全にロールバックします。unfound オブジェクトを lost とマークするには、以下を実行します。

ceph pg {pg-id} mark_unfound_lost revert|delete

新しい元号のコードプロファイルを作成するには、以下の手順を実施します。

ceph osd erasure-code-profile set <name> \
         [<directory=directory>] \
         [<plugin=plugin>] \
         [<stripe_unit=stripe_unit>] \
         [<crush-device-class>]\
         [<crush-failure-domain>]\
         [<key=value> ...] \
         [--force]

詳細は以下のようになります。

イレイジャーコードプロファイルを削除するには、以下のコマンドを実行します。

ceph osd erasure-code-profile rm <name>

プロファイルがプールで参照される場合、削除は失敗します。

イレイジャーコードプロファイルを表示するには、以下のコマンドを実行します。

ceph osd erasure-code-profile get <name>

イレイジャーコードプロファイルの名前を一覧表示するには、以下のコマンドを実行します。

ceph osd erasure-code-profile ls

jerasure プラグインは、最も汎用的で柔軟性のあるプラグインです。Ceph Erasure コードプールのデフォルトでもあります。

jerasure プラグインは JerasureH ライブラリーをカプセル化します。パラメーターの詳細は、jerasure のドキュメントを参照してください。

jerasure プラグインを使用して新しいイレイジャーコードプロファイルを作成するには、以下のコマンドを実行します。

ceph osd erasure-code-profile set <name> \
     plugin=jerasure \
     k=<data-chunks> \
     m=<coding-chunks> \
     technique=<reed_sol_van|reed_sol_r6_op|cauchy_orig|cauchy_good|liberation|blaum_roth|liber8tion> \
     [crush-root=<root>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

詳細は以下のようになります。

jerasure プラグインでは、Ceph が複数の OSD にイレイジャーコーディングされたオブジェクトを保存する際に、1 つの OSD が失われた場合からの復元には、他のすべての OSD からの読み取りが必要です。たとえば、k=8 および m=4 で jerasure を設定する場合は、OSD の 1 つの OSD が失われると、修復のために他の 11 個から読み取る必要があります。

lrc イレイジャーコードプラグインは、少ない OSD を使用して復元できるようにローカルパリティーチャンクを作成します。たとえば、k=8、m=4、および l=4 で lrc を設定する場合は、4 つの OSD ごとに追加のパリティーチャンクが作成されます。Ceph が単一の OSD を失うと、そのオブジェクトデータを eleven ではなく 4 つの OSD のみで復旧できます。

すべてのホストが同じスイッチに接続されている場合はおそらく関心のあるユースケースではありませんが、lrc イレイジャーコードプラグインを使用する際に、ラック間の帯域幅使用量の使用量を低減することができます。

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

1.2 バージョンでは、プライマリー OSD が失われたチャンクと同じラックにある場合に限り、帯域幅を低下させることができます。

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     k=4 m=2 l=3 \
     crush-locality=rack \
     crush-failure-domain=host
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

ceph osd erasure-code-profile set <name> \
     plugin=lrc \
     k=<data-chunks> \
     m=<coding-chunks> \
     l=<locality> \
     [crush-root=<root>] \
     [crush-locality=<bucket-type>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

chunk nr    01234567
step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "" ],
               [ "cDDD____", "" ],
               [ "____cDDD", "" ],
             ]' \
     crush-steps='[
                     [ "choose", "rack", 2 ],
                     [ "chooseleaf", "host", 4 ],
                    ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=DD_ \
     layers='[ [ "DDc", "plugin=isa technique=cauchy" ] ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

$ ceph osd erasure-code-profile set LRCprofile \
     plugin=lrc \
     mapping=__DD__DD \
     layers='[
               [ "_cDD_cDD", "plugin=isa technique=cauchy" ],
               [ "cDDD____", "plugin=isa" ],
               [ "____cDDD", "plugin=jerasure" ],
             ]'
$ ceph osd pool create lrcpool 12 12 erasure LRCprofile

デフォルトの CRUSH ルールは、異なるホストにある OSD を提供します。たとえば、以下のようになります。

chunk nr    01234567

step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

各チャンクに 1 つずつ、正確に 8 つの OSD が必要です。ホストが 2 つ隣り合ったラックにある場合は、最初の 4 つのチャンクを最初のラックに配置し、残りを 2 番目のラックに配置できます。1 つの OSD の失われた状態からのリカバリーには、2 つのラック間で帯域幅を使用する必要はありません。

たとえば、以下のようになります。

crush-steps='[ [ "choose", "rack", 2 ], [ "chooseleaf", "host", 4 ] ]'

rack タイプのクラッシュバケットを 2 つ選択し、それぞれに 4 つの OSD (タイプ host の異なるバケットに配置) を選択するルールを作成します。

また、細かい制御のためにルールを手動で作成することもできます。