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 は異なるワークロードに同じストレージメディアを使用しないようにします。これによりパフォーマンスは予測可能で一貫性が高くなります。

##
# OSD SATA DECLARATION
##
host ceph-osd2-sata {
  id -2   # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.0 weight 1.000
  item osd.3 weight 1.000
}
host ceph-osd1-sata {
  id -3   # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.2 weight 1.000
  item osd.5 weight 1.000
}
host ceph-osd0-sata {
  id -4   # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.1 weight 1.000
  item osd.4 weight 1.000
}

##
# OSD SSD DECLARATION
##

host ceph-osd2-ssd {
  id -22    # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.6 weight 1.000
  item osd.9 weight 1.000
}
host ceph-osd1-ssd {
  id -23    # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.8 weight 1.000
  item osd.11 weight 1.000
}
host ceph-osd0-ssd {
  id -24    # do not change unnecessarily
  # weight 2.000
  alg straw
  hash 0  # rjenkins1
  item osd.7 weight 1.000
  item osd.10 weight 1.000
}

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

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

注記:

ceph-crush-location --cluster {cluster-name} --id {ID} --type {daemon-type}

ceph-crush-location --cluster ceph --id 0 --type osd

osd_crush_location_hook = /path/to/script

ceph-crush-location --cluster {cluster-name} --id {ID} --type {daemon-type}

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 クラスターにおいて、ホストに 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 の数が増えると、復旧時間が短縮されます。

上記の 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 つは 300 の配置グループ、10 個は OSD 用 1000 の配置グループなどとなります。

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

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

各配置グループ、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 はデフォルト値 8 を使用します。これは許容範囲を超えるほど低い値です。プールの配置グループ数を増やすことはできますが、Ceph 設定ファイルで妥当なデフォルト値を設定することを推奨します。

osd pool default pg num = 100
osd pool default pgp num = 100

配置グループ (合計) 数と、オブジェクトに使用される配置グループの数 (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 pg warn max per osd

プール内の配置グループの数を設定するには、プールの作成時に配置グループの数を指定する必要があります。詳細は、「プールの作成」を参照してください。プールに配置グループを設定したら、配置グループの数を増やすことができます (ただし、配置グループの数を減らすことはできません)。配置グループの数を増やすには、以下のコマンドを実行します。

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

配置グループの数を増やしたら、クラスターがリバランスする前に、配置 (pgp_num) の配置グループの数も増やす必要があります。pgp_num は pg_num と同じである必要があります。配置の配置グループの数を増やすには、以下のコマンドを実行します。

ceph osd pool set {pool-name} pgp_num {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 の異なるバケットに配置) を選択するルールを作成します。

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