ストレージストラテジーガイド

Red Hat Ceph Storage 4

Red Hat Ceph Storage クラスターのストレージストラテジーの作成

Red Hat Ceph Storage Documentation Team

概要

本書では、CRUSH 階層の作成、配置グループ数の推定、プールの作成、プールの作成および管理など、ストレージストラテジーの作成方法について説明します。

第1章 概要

Ceph クライアントから見ると、Ceph ストレージクラスターとの対話は非常に簡単です。

  1. クラスターへの接続
  2. プール I/O コンテキストの作成

この非常にシンプルなインターフェースは、Ceph クライアントが定義するストレージストラテジーのいずれかを選択する方法です。ストレージストラテジーは、ストレージの容量とパフォーマンス以外のすべての場合に Ceph クライアントには表示されません。

1.1. ストレージストラテジーとは何ですか?

ストレージストラテジーは、特定のユースケースに対応するデータを保存する方法です。たとえば、OpenStack などのクラウドプラットフォームのボリュームおよびイメージを保管する必要がある場合には、SSD ベースのジャーナルと共に合理的に機能する SAS ドライブにデータを保存することを選択する場合があります。これとは対照的に、S3 または Swift 準拠のゲートウェイのオブジェクトデータを保存する必要がある場合は、SATA ドライブなど、より安全なものを使用するように選択できます。Ceph は同じ Ceph クラスターで両方のシナリオに対応できますが、クラウドプラットフォーム(OpenStack の Glance および Cinder など)に SAS/SSD ストレージストラテジーを提供する手段と、オブジェクトストアに SATA ストレージを提供する手段が必要です。

ストレージストラテジーには、ストレージメディア(ハードドライブ、SSD など)、ストレージメディアのパフォーマンスおよび障害ドメインを設定する CRUSH マップ、配置グループの数、プールインターフェースが含まれます。Ceph は複数のストレージストラテジーをサポートします。ユースケース、コスト/利点のパフォーマンストレードオフ、およびデータ永続性は、ストレージ戦略を駆動する主な考慮事項です。

  1. ユースケース: Ceph は大容量のストレージを提供し、多くのユースケースをサポートします。たとえば、Ceph Block Device クライアントは、コピーオンライトのクローン作成などのパフォーマンス機能の高いボリュームやイメージ向けに無制限のストレージを提供する OpenStack などのクラウドプラットフォームの主要なストレージバックエンドです。これとは対照的に、Ceph Object Gateway クライアントはクラウドプラットフォームの最先端のストレージバックエンドで、音声、ミック、ビデオ、その他のデータ等のオブジェクトに RESTful S3 準拠のオブジェクトストレージを提供します。
  2. パフォーマンスのコスト/利点: 高速さはより優れています。大きい方が優れています。耐久性が向上します。ただし、人的品質ごとに価格があり、対応する費用/利点のトレードオフが生じます。パフォーマンスの観点からは、以下のユースケースを考慮してください。SSD は、比較的少ないデータとジャーナリングのために、非常に高速のストレージを提供できます。データベースまたはオブジェクトインデックスを保存すると、非常に高速な SSD のプールからメリットが得られますが、その他のデータにはコストがかかります。SSD ジャーナリング付きの SAS ドライブは、ボリュームとイメージの価格でパフォーマンスを高速に提供します。SSD ジャーナリングのない SATA ドライブは、全体的なパフォーマンスが低下し、簡易ストレージを提供します。OSD の CRUSH 階層を作成する際には、ユースケースと、許容可能なコスト/パフォーマンスのトレードオフを考慮する必要があります。
  3. 耐久性: 大規模なクラスターでは、ハードウェア障害は予想され、例外ではありません。ただし、データの損失やサービスの中断は受け入れられません。このため、データの永続性は非常に重要です。Ceph は、オブジェクトのディープコピー、またはイレイジャーコーディングと複数のコーディングチャンクを使用したデータの永続性に対応します。複数のコピーまたはコーディングチャンクにより、追加のコスト/利点のトレードオフが発生します。これは、コピーまたはコーディングチャンクの数を減らすことが犠牲になりますが、低下した状態での書き込みリクエストに対応できなくなる可能性があります。通常、2 つの追加のコピー (つまり size = 3) または 2 つのコーディングチャンクを持つオブジェクトを使用すると、クラスターが復旧する間に、クラスターが動作が低下した状態での書き込みを行うことができます。CRUSH アルゴリズムは、Ceph が追加のコピーを保存するか、またはクラスター内の異なる場所にチャンクをコーディングできるようにすることで、このプロセスを支援します。これにより、単一のストレージデバイスまたはノードが失敗しても、データ損失を防ぐのに必要なコピーまたはコーディングチャンクがすべて失われることはありません。

ユースケース、コスト/利点のあるストレージストラテジーにおけるパフォーマンスのトレードオフやデータ永続性を把握し、それをストレージプールとして Ceph クライアントに提示することができます。

重要

Ceph のオブジェクトコピーまたはコーディングチャンクにより、RAID が廃止されます。RAID は使用しないでください。Ceph がすでにデータ永続性を処理し、低下した RAID はパフォーマンスに悪影響を及ぼし、RAID を使用したデータの復旧は、ディープコピーまたはイレイジャーコーディングチャンクを使用するよりも大幅に遅くなります。

1.2. ストレージストラテジーの設定

ストレージストラテジーを設定するには、Ceph OSD を CRUSH 階層に割り当て、プールの配置グループの数を定義し、プールを作成します。概略手順は次のとおりです。

  1. ストレージストラテジーの定義: ストレージストラテジーでは、ユースケース、コスト/利点のパフォーマンストレードオフおよびデータ永続性を分析する必要があります。次に、そのユースケースに適した OSD を作成します。たとえば、高パフォーマンスのプール用に SSD でバッキングされる OSD、高パフォーマンスのブロックデバイスボリュームおよびイメージには SAS ドライブ/SSD のジャーナルベースの OSD、コストが低いストレージ用に SATA がサポートする OSD を作成することができます。理想的には、ユースケースに適した各 OSD のハードウェア設定が同じで、パフォーマンスプロファイルの一貫性が保たれることが理想的です。
  2. CRUSH 階層の定義: Ceph ルールは、CRUSH 階層にあるノード (通常は ルート) を選択し、配置グループおよびそれに含まれるオブジェクトを保存するための適切な OSD を特定します。ストレージストラテジーの CRUSH 階層および CRUSH ルールを作成する必要があります。CRUSH 階層は、CRUSH ルール設定によりプールに直接割り当てられます。
  3. 配置グループの計算: Ceph はプールを配置グループにシャード化します。プールの適切な配置グループ数を設定し、複数のプールを同じ CRUSH ルールに割り当てる場合に、正常な配置グループ数内に残る必要があります。
  4. プールの作成: 最終的にプールを作成し、複製されたストレージまたはイレイジャーコーディングされたストレージを使用するかどうかを判別する必要があります。プールの配置グループの数、プールのルール、永続性 (サイズまたは K+M コーディングチャンク) を設定する必要があります。

プールはストレージクラスターに対する Ceph クライアントのインターフェースですが、ストレージストラテジーは Ceph クライアントに対しては完全に透過的です (容量とパフォーマンスを除く)。

第2章 CRUSH 管理

CRUSH (Controlled Replication Under Scalable Hashing) アルゴリズムは、コンピューティングデータストレージの場所によるデータの格納および取得方法を決定します。

 

十分に高度な技術は、一部と区別できません。

 
 -- Arthur C. Clarke

2.1. CRUSH の概要

ストレージクラスターの CRUSH マップは、CRUSH 階層内のデバイスの場所と、Ceph がデータを保存する方法を決定する各階層のルールを記述します。

CRUSH マップには、ノードの階層が少なくとも 1 つ含まれ、残ります。Ceph の「buckets」と呼ばれる階層のノードは、種別で定義されているストレージのロケーションの集約です。たとえば、行、ラック、シャーシ、ホスト、デバイスなどです。階層の各リーフは、ストレージデバイスの一覧にあるストレージデバイスの 1 つで構成されます。リーフは常に 1 つのノードまたは「bucket」に含まれています。 CRUSH マップには、CRUSH がデータを保管および取得する方法を決定するルールの一覧もあります。

注記

ストレージデバイスは、OSD をクラスターに追加する際に CRUSH マップに追加されます。

CRUSH アルゴリズムはデバイスごとの重みの値に従ってデータオブジェクトをストレージデバイス全体に分散し、統一された確率の分布を申請します。CRUSH は、管理者が定義する階層クラスターマップに従って、オブジェクトとそのレプリカまたはイレイジャーコーディングチャンクを分散します。CRUSH マップは、利用可能なストレージデバイスおよびルール用の論理バケット、およびルールを使用する各プールを拡張する論理バケットを表します。

障害ドメインまたはパフォーマンスドメイン全体で OSD に配置グループをマップするために、CRUSH マップはバケットタイプの階層的な一覧を定義します。これは、生成された CRUSH マップの types の下にあります。バケット階層を作成する目的は、障害ドメイン、パフォーマンスドメイン、またはその両方でリーフノードを分離することです。障害ドメインには、ホスト、シャーシ、ラック、電源分散ユニット、Pod、行、部屋、およびデータセンターが含まれます。パフォーマンスドメインには、特定の設定の障害ドメインおよび OSD が含まれます。たとえば、SSD、SSD ジャーナルのある SAS ドライブ、SATA ドライブなど。RHCS 3 では、デバイスは hddssdnvme などの class の概念を持ち、デバイスのクラスを使用して CRUSH 階層をより迅速にビルドします。

OSD を表すリーフノードを除き、残りの階層は任意であり、デフォルト種別が要件に適さない場合には、それを独自のニーズに合わせて定義することができます。CRUSH マップバケットタイプを組織のハードウェア命名規則に適用し、物理ハードウェア名を反映するインスタンス名を使用することが推奨されます。命名方法により、OSD またはその他のハードウェアの誤作動や、管理者がホストまたはその他のハードウェアへのリモートまたは物理的なアクセスが必要な場合は、クラスターの管理を容易にし、問題のトラブルシューティングを行うことができます。

以下の例では、バケット階層には 4 つのリーフバケット (osd 1-4)、ノードバケット (host 1-2)、および 1 つのラックノード (rack 1) があります。

CRUSH 階層

リーフノードは、CRUSH マップの開始時に devices 一覧に宣言されたストレージデバイスを反映するため、それらをバケットインスタンスとして宣言する必要はありません。階層で 2 番目に小さいバケットタイプは、通常、デバイスを集約します。つまり、通常はストレージメディアを含むコンピューターで、「ノード」、「コンピューター」、「サーバー」、「ホスト」、「マシン」、「マシン」、「マシン」、「マシン」など、管理者を優先する用語を使用します。高密度な環境では、カードやシャーシごとに複数のホスト/ノードを確認することが一般的です。カードおよびシャーシの障害も考慮してください。たとえば、ノードに障害が発生した場合には、カードやシャーシをプルする必要性により、ホスト/ノードとその OSD が大量にダウンする可能性があります。

バケットインスタンスを宣言する場合は、その型を指定し、一意の名前を文字列として指定し、負の整数として表現される任意の一意の ID を割り当て、アイテムの合計容量または機能に対する重みを指定し、straw などのバケットアルゴリズムを指定します。また、通常はハッシュアルゴリズム rjenkins1 を反映した 0 となるハッシュを指定します。バケットには 1 つまたは複数の項目を含めることができます。項目は、ノードバケットまたは残りで構成されます。項目は、アイテムの相対的な重みを反映する重みを持つことができます。

2.1.1. データの動的配置

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

  • Ceph Clients: CRUSH マップを Ceph クライアントに配布することにより、CRUSH は Ceph クライアントが OSD に直接通信できるようにします。つまり、Ceph クライアントは集中型のオブジェクトルックアップテーブルを回避します。これは、単一障害点、パフォーマンスのボトルネック、一元管理されたルックアップサーバーでの接続制限、およびストレージクラスターのスケーラビリティーへの物理的な制限となります。
  • Ceph OSD: CRUSH マップを Ceph OSD に分散することにより、Ceph は OSD を変換してレプリケーション、バックフィル、およびリカバリーを処理します。これは、Ceph OSD が Ceph クライアントの代わりにオブジェクトレプリカ(またはコーディングチャンク)のストレージを処理することを意味します。また、これは、Ceph OSD がクラスターをリバランス(バックフィル)し、障害から動的に回復するのに十分なクラスターを認識していることを意味します。

2.1.2. 障害ドメインの確立

複数のオブジェクトレプリカまたは M イレイジャーコーディングチャンクを使用するとデータの損失を防ぐことができますが、高可用性に対応するには十分ではありません。Ceph Storage Cluster の基盤の物理的構成を反映することで、CRUSH は関連するデバイス障害のアドレスの潜在的なソースをモデル化して、そのソースをモデル化できます。クラスターのトポロジーをクラスターマップにエンコードすることで、CRUSH 配置ポリシーは、必要な擬似乱数分散を維持しながら、異なる障害ドメイン間でオブジェクトレプリカまたはイレイジャーコーディングチャンクを分離できます。たとえば、同時障害の可能性に対応するには、データのレプリカまたはイレイジャーコーディングチャンクが、別のシブレッシング、ラック、電源、コントローラー、または物理的な場所を使用してデバイス上にあることを確認します。これは、データ損失を回避し、クラスターがパフォーマンスが低下した状態で動作できるようにします。

2.1.3. パフォーマンスドメインの確立

Ceph は複数の階層をサポートし、あるタイプのハードウェアパフォーマンスプロファイルを別のタイプのハードウェアパフォーマンスプロファイルから分離することができます。たとえば、CRUSH はハードドライブの階層を 1 つ作成し、SSD には別の階層を作成できます。パフォーマンスドメイン: ベースとなるハードウェアのパフォーマンスプロファイルを考慮に入れる階層は、異なるパフォーマンス特性をサポートする必要があるため、頻繁に人気があります。運用上、それらは複数の root タイプバケットを持つ CRUSH マップです。ユースケースの例を以下に示します。

  • 仮想マシン: OpenStack、CloudStack、ProxMox、OpenNebula などのクラウドプラットフォームのバックエンドとして機能する Ceph ホストは、ジャーナリング用に高性能 SSD がパーティション化されている SAS ドライブ上の XFS など、最も安定したファイルシステムを使用する傾向があります。XFS はジャーナルと書き込みを同時に行わないためです。一貫したパフォーマンスプロファイルを維持するには、このようなユースケースで同様のハードウェアを CRUSH 階層に統合する必要があります。
  • Object Storage: S3 および Swift インターフェースのオブジェクトストレージバックエンドとして機能する Ceph ホストは、仮想マシンに適さない SATA ドライブなど、より安価なストレージメディアを利用する場合があります。また、オブジェクトストレージのギガバイトあたりのコストを軽減しつつ、クラウドプラットフォームでボリュームやイメージを保管するより高性能なストレージホストとより安価なストレージホストを分離することができます。HTTP はオブジェクトストレージシステムのボトルネックとなる傾向があります。
  • コールドストレージ: コールドストレージ用に設計されたシステム (アクセス頻度が低いデータや、パフォーマンス要件が緩和されたデータの取得) では、より安価なストレージメディアやイレイジャーコーディングを利用できます。ただし、イレイジャーコーディングには、追加の RAM と CPU が必要となる場合があり、オブジェクトストレージまたは仮想マシンに使用されるホストからの RAM および CPU 要件が異なります。
  • SSD でバックアップされるプール: SSD は高価ですが、ハードドライブよりも大きな利点があります。SSD にはシーク時間がなく、高スループットを提供します。クラスターは、ジャーナリングに SSD を使用する他に、SSD がサポートするプールをサポートすることもできます。一般的なユースケースには、高パフォーマンスの SSD プールが含まれます。たとえば、Ceph Object Gateway の .rgw.buckets.index プールを SATA ドライブではなく SSD にマッピングすることができます。

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

2.1.3.1. RHCS 2 および Earlier で異なるデバイスクラスの使用

RHCS 2 以前には、デバイスクラスの概念はありません。RHCS 2 とそれ以前で、SSD ドライブや SATA ドライブなど、異なるストレージクラスを使用するには、SSD ドライブと SATA ドライブをポイントするプールを作成します。これらのプールに送信されるデータは、それぞれ SSD ドライブと SATA ドライブに対して別々のルート階層を作成して分離する必要があります。CRUSH マップは SSD には階層を 1 つ定義し、SATA ドライブには 1 つの階層を定義する必要があります。SSD および SATA ドライブは、同じホストまたは別のホストまたは別のホストに置くことができます。

CRUSH 階層が 2 つ配置したら、SSD および SATA 階層に別個のルールを作成し、適切なルールセットを使用するように各プールを設定します。

注記
Red Hat は、RHCS 3.0 以降のリリースでの ruleset の概念はサポートしていません。CRUSH ルールセットについての詳細は、RHCS 2 のドキュメントを参照してください。

これを行うには、CRUSH マップを変更します (変更するには CRUSH マップを逆コンパイルします。詳細は「CRUSH マップのでコンパイル」セクションを参照してください)。CRUSH アルゴリズムがオブジェクトを保存する 2 つの異なるルートポイントまたはエントリーポイントを作成します。SSD ディスク用のルートと SATA ディスク用のルートが 1 つあります。以下の例では、各ホストに 2 つの SATA ディスクと 2 つの SSD ディスクがあり、合計 3 つのホストがあります。CRUSH は、2 つの異なるプラットフォームがあると考えます。

CRUSH マップの例:

##
# 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
}
  1. OSD を含む 2 つのルートを作成します。

    ##
    # SATA ROOT DECLARATION
    ##
    
    root sata {
      id -1   # do not change unnecessarily
      # weight 6.000
      alg straw
      hash 0  # rjenkins1
      item ceph-osd2-sata weight 2.000
      item ceph-osd1-sata weight 2.000
      item ceph-osd0-sata weight 2.000
    }
    
    ##
    # SATA ROOT DECLARATION
    ##
    
    root ssd {
      id -21    # do not change unnecessarily
      # weight 6.000
      alg straw
      hash 0  # rjenkins1
      item ceph-osd2-ssd weight 2.000
      item ceph-osd1-ssd weight 2.000
      item ceph-osd0-ssd weight 2.000
    }
  2. SSD に 2 つの新規ルールを作成します。

    ##
    # SSD RULE DECLARATION
    ##
    
    # rules
    rule ssd {
     ruleset 0
     type replicated
     min_size 1
     max_size 10
     step take ssd
     step chooseleaf firstn 0 type host
     step emit
    }
    
    ##
    # SATA RULE DECLARATION
    ##
    
    rule sata {
     ruleset 1
     type replicated
     min_size 1
     max_size 10
     step take sata
     step chooseleaf firstn 0 type host
     step emit
    }
  3. 新しいマップをコンパイルし、挿入します。

    $ crushtool -c lamap.txt -o lamap.coloc
    $ sudo ceph osd setcrushmap -i lamap.coloc
  4. 結果を確認します。

    $ sudo ceph osd tree
    # id  weight  type name up/down reweight
    -21 12  root ssd
    -22 2       host ceph-osd2-ssd
    6 1             osd.6 up  1
    9 1             osd.9 up  1
    -23 2       host ceph-osd1-ssd
    8 1             osd.8 up  1
    11  1           osd.11  up  1
    -24 2       host ceph-osd0-ssd
    7 1             osd.7 up  1
    10  1           osd.10  up  1
    -1  12  root sata
    -2  2       host ceph-osd2-sata
    0 1             osd.0 up  1
    3 1             osd.3 up  1
    -3  2       host ceph-osd1-sata
    2 1             osd.2 up  1
    5 1             osd.5 up  1
    -4  2       host ceph-osd0-sata
    1 1             osd.1 up  1
    4 1             osd.4 up  1

次に、プールで作業します。

  1. プールを作成します。

    プールの ssd:

    root@ceph-mon0:~# ceph osd pool create ssd 128 128

    プールの sata:

    root@ceph-mon0:~# ceph osd pool create sata 128 128
  2. プールにルールを割り当てます。

    pool 8 crush_ruleset を 0 に設定します。

    root@ceph-mon0:~# ceph osd pool set ssd crush_ruleset 0

    pool 9 crush_ruleset を 1 に設定します。

    root@ceph-mon0:~# ceph osd pool set sata crush_ruleset 1
  3. ceph osd dump の結果:

    pool 8 'ssd' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins
    pg_num 128 pgp_num 128 last_change 116 flags hashpspool stripe_width 0
    pool 9 'sata' replicated size 2 min_size 1 crush_ruleset 1 object_hash rjenkins
    pg_num 128 pgp_num 128 last_change 117 flags hashpspool stripe_width 0
注記

サービスの再起動時に OSD がデフォルトの CRUSH の場所に戻されないようにするには、osd crush update on start = false を使用して、デーモンの開始時に CRUSH マップの更新を無効にします。

2.1.3.2. RHCS 3 以降で異なるデバイスクラスの使用

RHCS 3 でパフォーマンスドメインを作成するには、デバイスクラスと単一の CRUSH 階層を使用します。CLI を使用して RHCS 2 と同じ方法で、OSD を CRUSH 階層に追加するだけです。次に、以下を行います。

  1. 各デバイスにクラスを追加します。以下に例を示します。

    # ceph osd crush set-device-class <class> <osdId> [<osdId>]
    # ceph osd crush set-device-class hdd osd.0 osd.1 osd.4 osd.5
    # ceph osd crush set-device-class ssd osd.2 osd.3 osd.6 osd.7
  2. 次に、デバイスを使用するルールを作成します。

    # ceph osd crush rule create-replicated <rule-name> <root> <failure-domain-type> <class>
    # ceph osd crush rule create-replicated cold default host hdd
    # ceph osd crush rule create-replicated hot default host ssd
  3. 最後に、ルールを使用するようにプールを設定します。

    ceph osd pool set <poolname> crush_rule <rule-name>
    ceph osd pool set cold_tier crush_rule cold
    ceph osd pool set hot_tier crush_rule hot

RHCS 3 以降では、CRUSH マップを手動で編集する必要はありません。

2.2. CRUSH 階層

CRUSH マップは適切なレガシーグラフであるため、複数の階層に対応することができます(例: パフォーマンスドメイン)。CRUSH 階層を作成および変更する最も簡単な方法は、Ceph CLI で行います。ただし、CRUSH マップのコンパイル、編集、再コンパイル、およびアクティベートを行うこともできます。

Ceph CLI でバケットインスタンスを宣言する場合には、そのタイプを指定し、一意の名前(文字列)を指定する必要があります。Ceph はバケット ID を自動的に割り当て、アルゴリズムを straw に設定しrjenkins1 を反映してハッシュを 0 に設定し、重みを設定します。コンパイルされていない CRUSH マップを変更する場合は、バケットに負の整数 (任意) として表現される一意の ID を割り当て、アイテムの合計容量/機能に対する重みを指定し、バケットアルゴリズム (通常は straw)、およびハッシュ (通常はハッシュアルゴリズム rjenkins1 を反映させ 0)。

バケットには 1 つまたは複数の項目を含めることができます。項目は、ノードバケット(ラック、行、ホストなど)または残り(OSD ディスクなど)で構成されます。項目は、アイテムの相対的な重みを反映する重みを持つことができます。

コンパイルされていない CRUSH マップを変更する場合、以下の構文でノードバケットを宣言できます。

[bucket-type] [bucket-name] {
    id [a unique negative numeric ID]
    weight [the relative capacity/capability of the item(s)]
    alg [the bucket type: uniform | list | tree | straw ]
    hash [the hash type: 0 by default]
    item [item-name] weight [weight]
}

たとえば、上記の図を使用して、2 つのホストバケットと 1 つのラックバケットを定義します。OSD は、ホストバケット内の項目として宣言されます。

host node1 {
    id -1
    alg straw
    hash 0
    item osd.0 weight 1.00
    item osd.1 weight 1.00
}

host node2 {
    id -2
    alg straw
    hash 0
    item osd.2 weight 1.00
    item osd.3 weight 1.00
}

rack rack1 {
    id -3
    alg straw
    hash 0
    item node1 weight 2.00
    item node2 weight 2.00
}
注記

前述の例では、ラックバケットには OSD が含まれていないことに注意してください。さらに、低レベルのホストバケットが含まれ、アイテムエントリーに重みの合計が含まれます。

2.2.1. CRUSH の場所

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

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

注記:

  1. 鍵の順序は重要ではありません。
  2. キー名 (= の左) は有効な CRUSH type である必要があります。デフォルトでは、これには、rootdatacenterroomrowpodpdurackchassis、および host が含まれます。CRUSH マップを編集して、タイプをニーズに合わせて変更できます。
  3. すべての buckets/keys を指定する必要はありません。たとえば、デフォルトでは Ceph は ceph-osd デーモンの場所を root=default host={HOSTNAME} に自動的に設定します (hostname -s からの出力に基づいています)。

2.2.1.1. デフォルトの ceph-crush-location フック

起動時に、Ceph は、デフォルトで ceph-crush-location ツールを使用して各デーモンの CRUSH の場所を取得します。ceph-crush-location ユーティリティーは、指定のデーモンの CRUSH の場所を返します。CLI の使用は以下で構成されます。

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

たとえば、以下のコマンドは OSD.0 の場所を返します。

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

デフォルトでは、ceph-crush-location ユーティリティーは、指定のデーモンの CRUSH の場所文字列を返します。優先される順で返される場所は、以下に基づいています。

  1. Ceph 設定ファイルの {TYPE}_crush_location オプションたとえば、OSD デーモンの場合、{TYPE}osd のようになり、設定は osd_crush_location となります。
  2. Ceph 設定ファイル内の特定のデーモン用の crush_location オプション。
  3. root=default host=HOSTNAME のデフォルト。ホスト名が hostname -s コマンドで返されます。

典型的なデプロイメントシナリオでは、プロビジョニングソフトウェア (またはシステム管理者) は単にホストの Ceph 設定ファイルの crush_location フィールドを設定して、データセンターまたはクラスター内でのマシンの場所を記述できます。これにより、Ceph デーモンやクライアントが場所を認識できるようになります。

2.2.1.2. カスタムの場所フック

階層内の OSD デーモンの配置に、汎用フックの代わりにカスタムの場所フックを使用することができます。(起動時に、OSD ごとに正しく場所が正しいことを確認します)。

osd_crush_location_hook = /path/to/script

このフックは複数の引数が渡され (以下)、CRUSH の場所の説明で単一行を stdout (標準出力) に出力する必要があります。

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

--cluster 名前は通常「ceph」で、--id はデーモン識別子 (OSD 番号) に、デーモン --type は通常 osd です。

2.2.2. バケットの追加

バケットインスタンスを 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
注記

Ansible 自動化アプリケーションまたは別のツールを使用して OSD をクラスターに追加する場合、ホストノードは CRUSH マップにすでにある可能性があります。

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

ceph osd tree

階層がフラットのままであることに注意してください。CRUSH マップに追加した後に、バケットを階層的な場所に移動する必要があります。

2.2.3. バケットの移動

初期クラスターの作成時に、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
注記

ceph osd crush create-or-move を使用して、OSD の移動中に場所を作成することもできます。

2.2.4. バケットの削除

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

ceph osd crush remove {bucket-name}

または:

ceph osd crush rm {bucket-name}
注記

削除するには、バケットが空である必要があります。

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

2.2.5. バケットアルゴリズム

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

  1. Uniform: Uniform バケットは、完全に 同一の重みを持つデバイスを集約します。たとえば、ハードウェアが消費または停止した場合に、通常は、同一の物理設定(一括購入など)を持つ多くのマシンに対して実行します。ストレージデバイスの重みが完全に一致する場合は、uniform されたバケットタイプを使用できます。これにより、CRUSH が一定の時間内にレプリカを統一されたバケットにマップできます。一意でない重みでは、別のバケットアルゴリズムを使用する必要があります。
  2. List: List バケットは、コンテンツをリンクリストとして集約します。RUSH (Replication Under Scalable Hashing) P アルゴリズムに基づいて、リストはクラスターを拡張する ための自然で直感的な選択です。オブジェクトは、適切な確率で最新のデバイスに再配置されるか、以前と同じように古いデバイスに残っています。その結果、項目をバケットに追加する際に最適なデータ移行が行われます。ただし、一覧の途中または末尾から削除された項目は、大量の不要な移動が大量に実行され、リストバケットが 縮小されない (またはほとんどない) 状況に最適です。
  3. Tree: Tree バケットはバイナリー検索ツリーを使用します。バケットにより多くの項目セットが含まれる場合に、一覧表示のバケットよりも効率的です。RUSH (Replication Under Scalable Hashing) R アルゴリズムに基づいたツリーバケットは、配置時間を O(log n) に短縮し、より大きなデバイスセットやネストしたバケットの管理に適しています。
  4. Straw (デフォルト): List および Tree バケットは、特定の項目の優先順位 (たとえば、リストの最初に項目の優先順位) を提供するか、すべての項目のサブツリー全体を考慮する必要がなくなります。これにより、レプリカの配置プロセスのパフォーマンスが向上しますが、アイテムの追加、削除、または再重み付けによりバケットの内容が変更される際に、最適な再編成動作も導入できます。straw バケットタイプを使用すると、ストックの作成と同様のプロセスを介してレプリカの配置を行うために、すべての項目を相互に適切に「接続」することができます。

2.3. CRUSH の Ceph OSD

OSD の CRUSH 階層を取得したら、OSD を CRUSH 階層に追加します。既存の階層から OSD を移動するか、または削除することもできます。Ceph CLI の使用値は、以下のように設定します。

id
詳細
OSD の数値 ID。
整数
必須
はい
0
name
詳細
OSD のフルネーム。
文字列
必須
はい
osd.0
weight
詳細
OSD の CRUSH 重み。
double
必須
はい
2.0
root
詳細
OSD が置かれている階層またはツリーのルートバケットの名前。
キーと値のペア。
必須
はい
root=defaultroot=replicated_rule など
bucket-type
詳細
1 つ以上の名前と値のペア。name はバケットタイプ、値はバケットの名前になります。CRUSH 階層で OSD の CRUSH の場所を指定できます。
キーと値のペア。
必須
いいえ
datacenter=dc1 room=room1 row=foo rack=bar host=foo-bar-1

2.3.1. CRUSH での OSD の表示

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
                    }
                ]
            }
        ]
    }
]
注記

RHCS 3 以降では、OSD オブジェクトには device_class 属性も含まれます。

2.3.2. OSD の CRUSH への追加

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

注記

RHCS 3 では、デバイスクラスを追加することもできます。

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 をルートに直接アタッチします。ただし、CRUSH ルールは OSD がホストまたはシャーシの内部にあり、ホストまたはシャーシはクラスタートポロジーを反映する他のバケットの内部にある 必要 があります。

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

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

ceph osd crush set または ceph osd crush create-or-move を使用して、OSD を CRUSH 階層に追加することもできます。

2.3.3. CRUSH 階層内での OSD の移動

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

重要

CRUSH 階層で OSD を移動すると、Ceph は OSD に割り当てられる配置グループを再計算し、データの再分配が著しく発生する可能性があることを意味します。

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

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

ceph osd crush create-or-move を使用して、CRUSH 階層内で OSD を移動することもできます。

2.3.4. CRUSH 階層からの OSD の削除

CRUSH 階層から OSD を削除することは、クラスターから OSD を削除する際に最初に行います。CRUSH マップから OSD を削除すると、OSD がそれに応じて配置グループおよびデータのリバランスを取得する CRUSH を再計算します。詳細は、「OSD の追加/削除」を参照してください。

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

ceph osd crush remove {name}

2.4. デバイスクラス

Ceph の CRUSH マップは、データ配置の制御に非常に柔軟性を提供します。これは Ceph の最も強固な強みの 1 つです。初期の Ceph デプロイメントでは、ほぼ 1 つのハードドライブのみを使用していました。現在、Ceph クラスターは、さまざまなタイプのストレージデバイス(HDD、SSD、NVMe、もしくは前述のさまざまなクラスにも)で構築されます。たとえば、Ceph Object Gateway のデプロイメントでは、クライアントが低速な HDD にデータを保存できるストレージポリシーと、高速 SSD にデータを保存するその他のストレージポリシーを設定することが一般的です。Ceph Object Gateway デプロイメントには、バケットインデックスの高速 SSD がサポートするプールが含まれる場合があります。さらに、OSD ノードでは、CRUSH マップに表示されないジャーナルまたは書き込みログ用にのみ使用される SSD も頻繁に存在します。これらの複雑なハードウェアシナリオではこれまで、CRUSH マップを手動で編集する必要がありましたが、これは時間がかかり、面倒です。RHCS 3 では新たな「device class」が追加されました。これにより、CRUSH 階層の作成が大幅に簡素化されます。RHCS 3 以上では、異なるストレージデバイスクラスごとに異なる CRUSH 階層を持つ必要がなくなりました。

CRUSH ルールは CRUSH 階層に基づいて動作します。ただし、同じホスト内に異なるストレージデバイスのクラスが存在する場合、このプロセスはより複雑になり、デバイスの各クラスに複数の CRUSH 階層を作成し、CRUSH 階層管理の多くを自動化する osd crush update on start オプションを無効にします。デバイスクラスは、使用するデバイスのクラスを CRUSH ルールに通知してこの無駄を排除し、CRUSH 管理タスクを大幅に簡素化します。

注記

RHCS 3 以降では、ceph osd tree コマンドに、デバイスクラスを反映した列があります。

以下のセクションでは、デバイスクラスの使用について詳しく説明します。その他の例については、「RHCS 3 以降におけるさまざまなデバイスクラスの使用」および「CRUSH ストレージ戦略の例」を参照してください。

2.4.1. デバイスクラスの設定

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
注記

Ceph はクラスをデバイスに自動的に割り当てることができます。ただし、クラス名は任意の文字列です。hddssdnvme に準拠する必要はありません。前述の例では、bucket-index という名前のデバイスクラスが、Ceph Object Gatway プールが排他的バケットインデックスワークロードを使用する SSD デバイスを示す場合があります。すでに設定されているデバイスクラスを変更するには、最初に ceph osd crush rm-device-class を使用します。

2.4.2. デバイスクラスの削除

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

2.4.3. デバイスクラスの名前変更

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

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

以下に例を示します。

# ceph osd crush class rename hdd sas15k

2.4.4. デバイスクラスの一覧表示

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

# ceph osd crush class ls

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

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

2.4.5. デバイスクラスの OSD の一覧表示

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

# ceph osd crush class ls-osd <class>

以下に例を示します。

# ceph osd crush class ls-osd hdd

出力は単に OSD 番号の一覧です。以下に例を示します。

0
1
2
3
4
5
6

2.4.6. クラスによる CRUSH ルールの一覧表示

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

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

以下に例を示します。

# ceph osd crush rule ls-by-class hdd

2.5. CRUSH 重み

CRUSH アルゴリズムは、OSD デバイスごとに重み値をテラバイト単位で割り当てます。これは、新規データオブジェクトを PG および PG に割り当てる書き込み要求についての統一された確率分布を適用することを目的としています。このため、ベストプラクティスとして、同じタイプおよびサイズのデバイスで CRUSH 階層を作成し、同じ重みを割り当てることが推奨されます。また、パフォーマンスの特性がデータの分散に影響しない場合でも、CRUSH 階層のパフォーマンス特性が統一されるように、同じ I/O およびスループットの特性を持つデバイスを使用することが推奨されます。

統一されたハードウェアを使用することは常に実用的ではないため、異なるサイズの OSD デバイスを取り入れて相対的な重みを使用することで、Ceph はより多くのデータを大規模デバイスに分散し、データをより小さいデバイスに分散させることができます。

2.5.1. OSD の重みを Terabytes に設定

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

ceph osd crush reweight {name} {weight}

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

name
詳細
OSD のフルネーム。
文字列
必須
はい
osd.0
weight
詳細
OSD の CRUSH 重み。これはテラバイト単位で OSD のサイズになります。1.0 は 1 テラバイトです。
double
必須
はい
2.0

この設定は、OSD の作成時または OSD の追加直後に CRUSH 重みを調整する際に使用されます。通常、OSD の有効期間は変更しません。

2.5.2. バケットの OSD 重みの設定

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

osd crush reweight-subtree <name>

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

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

2.5.3. OSD の in 重みの設定

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

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

ceph osd reweight {id} {weight}

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

  • id は OSD の番号です。
  • weight は 0.0 ~ 1.0 の範囲です。0 はクラスター内 (in) には含まれません (つまり、PG がクラスターに割り当てられていません)。1.0 はクラスター内 (in) です (つまり、OSD は他の OSD と同じ数の PG を受信します)。

2.5.4. 使用状況による OSD の重みの設定

CRUSH は、新規データオブジェクト PG および PG を OSD に割り当てる書き込み要求についての統一された可能性の分布を概算するように設計されています。ただし、クラスターが不安定になる可能性があります。これは、さまざまな理由で発生する可能性があります。以下に例を示します。

  • 複数のプール: CRUSH 階層に複数のプールを割り当てることができますが、プールには異なる配置グループの数、サイズ (保存するレプリカ数)、およびオブジェクトサイズの特性を持たせることができます。
  • カスタムクライアント: クライアントからのブロックデバイス、オブジェクトゲートウェイ、ファイルシステムシャードデータなどの Ceph クライアント。統一されたサイズの小さい RADOS オブジェクトとして、データをクラスター全体でオブジェクトとしてストライプ化します。したがって、前述のシナリオ以外では、通常 CRUSH はその目的を達成します。ただし、クラスターに不安定な状態が生じるもう 1 つのケースがあります。つまり、librados を使用してオブジェクトのサイズを正規化せずにデータを保存することです。このシナリオでは、クラスターのバランスが取れなくなる可能性があります(例: 100 1MB オブジェクトと 10 4MB のオブジェクトを保存すると、OSD の数データが他よりも多くなります)。
  • 可能性: 統一されたディストリビューションでは、PG が多い OSD と少ない OSD が発生します。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

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

  • threshold は、OSD がデータストレージ負荷を高くする使用率が低くなり、割り当てられた PG の数が減ります。デフォルト値は 120 で、120 % を反映しています。100 以降の値はすべて有効なしきい値です。任意です。
  • weight_change_amount は重みを変更する量です。有効な値は 0.0 - 1.0 より大きいです。デフォルト値は 0.05 です。任意です。
  • number_of_OSDs は、リライトする OSD の最大数です。大規模なクラスターの場合、リライトする OSD の数を制限すると、大規模なリバランスを防ぐことができます。任意です。
  • no-increasing は、デフォルトで off になっています。reweight-by-utilization コマンドまたは test-reweight-by-utilization コマンドを使用すると、osd 重みを増やすことができます。このオプションをこれらのコマンドで使用すると、OSD の使用率が低くても OSD の重みが増えなくなります。任意です。
重要

大規模なクラスターに reweight-by-utilization を実行することが推奨されます。使用状況のレートは徐々に変化する可能性があり、クラスターのサイズやハードウェアが変更するにつれ、使用率の変化を反映するように重み付けを更新する必要があります。使用率に基づいて調整する場合は、使用率、ハードウェア、またはクラスターのサイズの変更としてこのコマンドを再実行する必要があります。

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

2.5.5. PG ディストリビューションでの OSD の重みの設定

OSD の数が少ない CRUSH 階層では、OSD によっては他の OSD よりも多くの PG を取得でき、これにより負荷が大きくなる可能性があります。PG ディストリビューションで OSD を調整し、この状況に対応するには、以下のコマンドを実行します。

osd reweight-by-pg <poolname>

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

  • poolname はプールの名前です。Ceph は、プールが PG を OSD に割り当てる方法を調べ、このプールの PG ディストリビューションに従って OSD を書き換えます。複数のプールを同じ CRUSH 階層に割り当てることができます。1 つのプールのディストリビューションに従って OSD を重み付けすると、同じ CRUSH 階層に割り当てられた他のプール(レプリカの数)と PG がない場合に、意図しない影響が生じる可能性があります。

2.5.6. CRUSH ツリーの重みの再計算

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

osd crush reweight-all

2.6. プライマリーアフィニティー

Ceph クライアントは、データを読み取りまたは書き込みする場合には、動作しているセットで常にプライマリー OSD に接続します。[2, 3, 4] セットの場合には、osd.2 がプライマリーになります。他の OSD と比較すると、OSD がプライマリーとして機能することに適さない場合があります(たとえば、ディスクが遅い場合や、コントローラーが遅い場合など)。ハードウェア使用率を最大化しつつ(特に読み取り操作上)パフォーマンスのボトルネックを防ぐために、CRUSH が動作しているセットで OSD をプライマリーとして使用する可能性は低くなります。

ceph osd primary-affinity <osd-id> <weight>

プライマリーアフィニティーはデフォルトで 1 です (つまり、OSD がプライマリーとして機能する可能性があります)。OSD のプライマリー範囲を 0-1 に設定できます。ここで、0 は OSD をプライマリーとして 使用しない ことを意味します。1 は、OSD がプライマリーとして使用される可能性があることを意味します。重みが <1 の場合は、CRUSH が、プライマリーとして機能する Ceph OSD デーモンを選択する可能性は低くなります。

2.7. CRUSH ルール

CRUSH ルールは、Ceph クライアントがバケットとその内部のプライマリー OSD の選択方法を定義し、プライマリー OSD がバケットとセカンダリー OSD の選択方法およびレプリカの保存またはコーディングチャンクを定義します。たとえば、2 つのオブジェクトレプリカについて SSD がサポートするターゲット OSD のペアを選択するルールと、3 つのレプリカについて、異なるデータセンター内の SAS ドライブがサポートする 3 つのターゲット OSD を選択するルールを作成することができます。

ルールは以下の形式になります。

rule <rulename> {

    ruleset <ruleset>
    type [ replicated | raid4 ]
    min_size <min-size>
    max_size <max-size>
    step take <bucket-type> [class <class-name>]
    step [choose|chooseleaf] [firstn|indep] <N> <bucket-type>
    step emit
}
RuleSet
詳細
(非推奨) ルールを一連のルールに属するように分類する手段。プールにルールセットを設定してアクティベートされます。RHCS 2 以前のリリースではサポート。RHCS 3 以降のリリースではサポートされません。
目的
ルールマスクのコンポーネント。
整数
必須
はい
デフォルト
0
type
詳細
ストレージドライブ(複製)または RAID のルールを説明します。
目的
ルールマスクのコンポーネント。
文字列
必須
はい
デフォルト
replicated
有効な値
現在は replicated のみ
min_size
詳細
プールのレプリカがこの数よりも少ない場合、CRUSH はこのルールを選択しません。
整数
目的
ルールマスクのコンポーネント。
必須
はい
デフォルト
1
max_size
詳細
プールがこの数を超えるレプリカを作成する場合、CRUSH はこのルールを選択しません。
整数
目的
ルールマスクのコンポーネント。
必須
はい
デフォルト
10
step take <bucket-name> [class <class-name>]
詳細
バケット名を取り、ツリーの反復を開始します。RHCS 3 以降でデバイスのクラス名が使用される可能性があります。
目的
ルールのコンポーネント。
必須
はい
step take data step take data class ssd
step choose firstn <num> type <bucket-type>
詳細

指定のタイプのバケットの数を選択します。この数は、通常プール内のレプリカ数です(プールサイズ)。

  • <num> == 0 の場合は、pool-num-replicas バケット (利用可能なすべて) を選択します。
  • <num> > 0 && < pool-num-replicas の場合は、多くのバケットを選択します。
  • <num> < 0 の場合、これは pool-num-replicas - {num} を意味します。
目的
ルールのコンポーネント。
前提条件
step take または step choose の後に行います。
step choose firstn 1 type row
step chooseleaf firstn <num> type <bucket-type>
詳細

{bucket-type} のバケットのセットを選択し、バケットのセットの各バケットのサブツリーからリーフノードを選択します。セット内のバケット数は、通常プール内のレプリカ数(プールサイズ)です。

  • <num> == 0 の場合は、pool-num-replicas バケット (利用可能なすべて) を選択します。
  • <num> > 0 && < pool-num-replicas の場合は、多くのバケットを選択します。
  • <num> < 0 の場合、これは pool-num-replicas - <num> を意味します。
目的
ルールのコンポーネント。使用法により、2 つの手順でデバイスを選択する必要がなくなります。
前提条件
step take または step choose の後に行います。
step chooseleaf firstn 0 type row
step emit
詳細
現在の値を出力し、スタックをエミュレートします。通常、ルールの最後に使用されますが、同じルール内の異なるツリーから選択するために使用することもできます。
目的
ルールのコンポーネント。
前提条件
step choose の後に行います。
step emit
firstn と indep
詳細
OSD が CRUSH マップにダウンすると、代替ストラテジー CRUSH が使用する制御を行います。このルールをレプリケートされたプールで使用する場合はこれを firstn にする必要があります。イレイジャーコーディングされたプールの場合は、indep にする必要があります。
OSD 1、2、3、4、5 に保存されていますが、その中で PG が落ちています。最初のシナリオでは、firstn モードの場合、CRUSH は、計算を調整して 1 および 2 を選択し、次に 3 を選択しますがそれがダウンしていることを検出したため、再試行して 4 と 5 を選択し、新しい OSD 6 を選択します。最終的な CRUSH マッピングの変更は 1、2、3、4、5 から 1、2、4、5、6 になります。2 つ目のシナリオでは、イレイジャーコーディングされたプールに indep モードが設定されていると、CRUSH は失敗した OSD 3 の選択を試行し、1、2、3、4、5 から 1、2、6、4、5) の最終変換に 6 を選択します。
重要

指定の CRUSH ルールは複数のプールに割り当てることができますが、単一プールに複数の CRUSH ルールを設定することはできません。

2.7.1. ルールの一覧表示

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

ceph osd crush rule list
ceph osd crush rule ls

2.7.2. ルールのダンプ

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

ceph osd crush rule dump {name}

2.7.3. 単純なルールの追加

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"}]}
注記

RHCS 3 以降のリリースでは、ruleset はサポートされません。RHCS 2 以前のリリースでは Ceph の後方互換性にのみ存在します。

2.7.4. Replicated Rule の追加

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

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

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

  • <name>: 仮想マシンの名前。
  • <root>: CRUSH 階層のルート。
  • <failure-domain>: 障害ドメイン。たとえば、host または rack です。
  • <class>: ストレージデバイスクラス。たとえば、hdd または ssd です。RHCS 3 以降のみ。

以下に例を示します。

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

2.7.5. 評価コードルールの追加

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

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

2.7.6. ルールの削除

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

ceph osd crush rule rm {name}

2.8. CRUSH Tunables

Ceph プロジェクトは多くの変更と新機能が多くなり、指数関数的に増大しました。商業的にサポートされている最初のメジャーリリース v0.48(Argonaut)以降、Ceph では CRUSH アルゴリズムの特定パラメーターを調整する機能が提供されます。つまり、ソースコードでは設定はフリーズしません。

以下の重要な点を考慮する必要があります。

  • CRUSH 値を調整すると、ストレージノード間の PG が移動される可能性があります。Ceph クラスターがすでに多くのデータを保存している場合は、一部のデータが移動できるように準備してください。
  • ceph-osd デーモンおよび ceph-mon デーモンは、更新されたマップを受け取るとすぐに、新しい接続の機能ビットを要求するようになります。ただし、すでに接続済みのクライアントは実質的にグレインされており、新機能をサポートしないと誤作動します。Ceph クライアントを更新する Ceph Storage Cluster デーモンもアップグレードする場合は、必ず確認してください。
  • CRUSH の調整可能パラメーターがレガシー以外の値に設定され、後でレガシー値に戻された場合は、その機能をサポートするのに ceph-osd デーモンは必要ありません。ただし、OSD ピアリングプロセスでは、古いマップを調べ、理解する必要があります。したがって、クラスターが以前に非レガシー CRUSH 値を使用していた場合は、マップの最新バージョンがレガシーデフォルトの使用に戻されたとしても、古いバージョンの ceph-osd デーモンを実行しないでください。

2.8.1. CRUSH の調整可能パラメーターの進化

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

レガシー値

CRUSH Tunables を使用する新規クラスターにデプロイされたレガシー値は、誤作動する可能性があります。問題には以下が含まれます。

  • リーフバケットにデバイスが少ない階層では、PG によっては必要なレプリカ数よりも少ない数にマッピングされます。これは一般的に、「ホスト」ノードが各ノードの下にネストされている OSD の小規模な数(1-3)を持つ階層で発生します。
  • 大規模なクラスターの場合、PG の一部の割合は必要な OSD 数未満にマッピングされます。これは、階層内に複数の層がある場合に、より顕著です。たとえば、row、rack、host、osd です。
  • 一部の OSD にマークが付けられると、データは階層全体ではなく、ほぼアクティブな OSD に再分配される傾向があります。
重要

Red Hat は、CRUSH の調整可能パラメーターを利用するために、Ceph クライアントと Ceph デーモンの両方をサポート対象メジャーリリースにアップグレードすることをお勧めします。Red Hat では、すべてのクラスターデーモンとクライアントが同じリリースバージョンを使用することを推奨します。

Argonaut(レガシー)

これは、商業的にサポートされている最初の Ceph リリースです。

  • バージョン要件

    • Ceph 0.48、0.49 以降
    • Linux カーネル 3.6 以降(RBD カーネルクライアントを含む)
  • サポートされる CRUSH Tunables:

    • choose_local_tries: ローカル再試行の数。レガシー値は 2 で、最適値は 0 です。
    • choose_local_fallback_tries: レガシー値は 5 で、最適値は 0 です。
    • choose_total_tries: アイテムの選択試行回数の合計。レガシー値は 19 で、後続のテストは、通常のクラスターに対して 50 の値が適切であることを示します。非常に大規模なクラスターの場合、大きな値が必要になる場合があります。

Bobtail

  • バージョン要件

    • Ceph 0.55、0.56.x 以降
    • Linux カーネル 3.9 以降(RBD カーネルクライアントを含む)
  • サポートされる CRUSH Tunable:

    • chooseleaf_descend_once: 再帰的な chooseleaf の試行で再試行するか、1 回だけ試行して、元の配置の再試行を許可するか。レガシーのデフォルト値は 0 で、最適値は 1 です。

Firefly

これは、Red Hat がサポートする最初のバージョンの Ceph です。

  • バージョン要件

    • Red Hat Ceph Storage 1.2.3 以降
    • RBD カーネルクライアントを含む Red Hat Enterprise Linux 7.1 以降
  • サポートされる CRUSH Tunables:

    • chooseleaf_vary_r: 親がすでに行った試行回数に基づいて、再帰的な chooseleaf 試行がゼロ以外の値の r で開始するかどうか。レガシーのデフォルトは 0 ですが、この値 CRUSH はマッピングを見つけることができないことがあります。計算コストおよび正確性の最適な値は 1 です。ただし、既存データが多数あるレガシークラスターの場合は、データを 0 から 1 に変更すると、大量のデータが移動します。4 または 5 の値を指定すると CRUSH が有効なマッピングを見つけることができますが、データの移動は少なくなります。
    • straw_calc_version: ストローバケットの CRUSH マップで計算および保存される内部重みにいくつかの問題がありました。具体的には、CRUSH 重みが 0、またはその両方のアイテムがあった場合、重みが混在しており、重複する重み CRUSH の一部がデータを正しく分散し、重みに比べませんでした。0 を値として指定すると、以前の破損した内部重みの計算は維持されます。値 1 を指定すると、動作が修正されます。straw_calc_version を 1 に設定し、アイテムの追加、削除、再重み付けを行うか、reweight-all コマンドを使用して straw バケットを調整すると、クラスターが問題のある状態のいずれかに到達した場合は、データ移動の量を軽減するよう小規模にトリガーできます。この調整可能なオプションは、クライアント側で必要なカーネルバージョンに全く影響を及ぼさないため、特別なものです。

hammer

hammer 調整可能なプロファイルは、調整可能なプロファイルを変更するだけで、既存の CRUSH マップのマッピングには影響しませんが、新規のバケットタイプ straw2 がサポートされるようになりました。

  • バージョン要件

    • Red Hat Ceph Storage 1.3 以降
    • RBD カーネルクライアントを含む Red Hat Enterprise Linux 7.1 以降
  • 新規バケットタイプ:

    • 新しい straw2 バケットタイプは、元の straw バケットのいくつかの制限を修正します。具体的には、古い straw バケットは、重みの調整時に変更される必要のあるマッピングを変更しますが、straw2 バケットは、重みが変更したバケットアイテムへのマッピングのみ、または変更されたバケットアイテムのみを変更するという元の目的を達成しました。straw2 バケットは、新規に作成されたすべてのバケットのデフォルトです。バケットタイプを straw から straw2 に変更すると、バケット項目の重みがどれくらい異なるかに応じて、ある程度のデータが移動することになります。重みがすべて同じ場合には、データは移動せず、項目の重みが大幅に変化すると、移動が多くなります。

jewel

Red Hat Ceph Storage 2 は Red Hat Enterprise Linux 7.2 以降でサポートされていますが、jewel 調整可能なプロファイルは Red Hat Enterprise Linux 7.3 以降でのみサポートされます。jewel 調整可能なプロファイルは、CRUSH の全体的な動作を改善します。これにより、OSD のマークが付けられる際にマッピングの変更が大幅に削減されます。

  • バージョン要件

    • Red Hat Ceph Storage 2 以降
    • RBD カーネルクライアントおよび CephFS カーネルクライアントを含む Red Hat Enterprise Linux 7.3 以降
  • サポートされる CRUSH Tunable:

    • chooseleaf_stable: 再帰的な chooseleaf の試行で、OSD がマークアウトされたときのマッピング変更の数を大幅に減らす内部ループにより良い値を使用するかどうか。レガシー値は 0 で、新しい値 1 は新しいアプローチを使用します。既存クラスターでこの値を変更すると、ほとんどの場合、すべての PG マッピングが変わるように、大量のデータが移動する可能性が高くなります。

2.8.2. CRUSH のチューニング

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

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

  • legacy: v0.47 (pre-Argonaut) 以前のバージョンのレガシー動作。
  • argonaut: v0.48 (Argonaut) リリースがサポートするレガシーの値。
  • bobtail: v0.56 (Bobtail) リリースでサポートされる値。
  • firefly: 0.80 (Firefly) リリースでサポートされる値。
  • hammer: v0.94 (Hammer) リリースでサポートされる値。
  • jewel: v10.0.2 (Jewel) リリースでサポートされる値。
  • optimal: 現在の最適値
  • default: 新規クラスターの現在のデフォルト値。

コマンドを使用して、実行中のクラスターでプロファイルを選択できます。

# ceph osd crush tunables <profile>
注記

これにより、データが移動する可能性があります。

通常、アップグレード後に CRUSH 調整可能パラメーターを設定するか、または警告が表示されます。バージョン v0.74 以降では、CRUSH の調整可能なパラメーターが最適な値に設定されていない場合に、ヘルスの警告が出されます。つまり、v0.73 の最適な値はデフォルト値になります。この警告を外すには、以下の 2 つのオプションがあります。

  1. 既存のクラスターで調整可能パラメーターを調整します。これにより、一部のデータが移動することに留意してください(おそらく 10%)。これは優先されるルートですが、データの移動がパフォーマンスに影響を与える可能性のある実稼働クラスターについては検討する必要があります。以下を使用して、最適なチューニング可能パラメーターを有効にすることができます。

    # ceph osd crush tunables optimal

    たとえば、負荷が過剰になっていて、処理のほとんど行われていない場合や、クライアントの互換性の問題(以前の kernel cephfs または rbd クライアント、または以前の外部 librados クライアント)がある場合は、以前のプロファイルに戻すことができます。

    # ceph osd crush tunables <profile>

    たとえば、pre-v0.48(Argonaut)の値を復元するには、次のコマンドを実行します。

    # ceph osd crush tunables legacy
  2. 以下のオプションを、ceph.conf ファイルの [mon] セクションに追加すると、CRUSH に変更を加えずに警告を離れることができます。

    mon warn on legacy crush tunables = false

    変更を有効にするには、モニターを再起動するか、またはオプションを使用してモニターを実行するオプションを適用します。

    # ceph tell mon.\* injectargs --no-mon-warn-on-legacy-crush-tunables

2.8.3. CRUSH のチューニング(Hard Way)

すべてのクライアントが最近のコードを実行していることを確認できます。CRUSH マップを抽出し、値を変更し、これをクラスターに再挿入することで、調整可能なパラメーターを調整することができます。

  • 最新の CRUSH マップを展開します。

    ceph osd getcrushmap -o /tmp/crush
  • 調整可能パラメーターを調整します。これらの値は、テストした大規模なクラスターおよび小規模なクラスターの両方に最善の動作を提供するように見えます。このコマンドが機能するには、crushtool--enable-unsafe-tunables 引数も指定する必要があります。このオプションは細心の注意を払って使用してください。

    crushtool -i /tmp/crush --set-choose-local-tries 0 --set-choose-local-fallback-tries 0 --set-choose-total-tries 50 -o /tmp/crush.new
  • 変更したマップを再挿入します。

    ceph osd setcrushmap -i /tmp/crush.new

2.8.4. レガシー値

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 デーモンを実行する場合は注意が必要です。

2.9. CRUSH マップの編集

通常、Ceph CLI を使用してランタイム時に CRUSH マップを変更する方が、CRUSH マップを手動で編集するよりも便利です。ただし、デフォルトのバケットタイプの変更や straw 以外のバケットアルゴリズムの使用など、編集を選択できます。

既存の CRUSH マップを編集するには、以下を実行します。

  1. CRUSH マップを取得します
  2. CRUSH マップを 逆コンパイル します。
  3. 1 つ以上のデバイス、およびバケットおよびルールを編集します。
  4. CRUSH マップを 再コンパイル します。
  5. CRUSH マップを設定します

特定のプールの CRUSH マップルールをアクティブにするには、共通のルール番号を特定し、プールの作成時にプールのルール番号を指定します。

2.9.1. CRUSH マップの取得

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

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

Ceph はコンパイルされた CRUSH マップを指定したファイル名に出力します。CRUSH マップはコンパイル形式であるため、編集する前に先にコンパイルする必要があります。

2.9.2. CRUSH マップのコンパイル

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

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

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

2.9.3. CRUSH マップのコンパイル

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

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

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

2.9.4. CRUSH マップの設定

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

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

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

2.10. CRUSH ストレージストラテジーの例

ほとんどのプールを大規模なハードドライブでバッキングし、いくつかのプールを高速ソリッドステートドライブ(SSD)がサポートする OSD にマッピングする場合、CRUSH はこれらのシナリオを容易に処理できます。

RHCS 2 and Earlier

RHCS 2 以前のリリースでは、異なるパフォーマンスドメインを反映するために、同じ CRUSH マップ内に複数の独立した CRUSH 階層を持たせることができます。2 つの異なるルートノードを持つ 2 つの階層を定義します。たとえば、ハードディスク用(root platter)と SSD(例: root ssd)用です。

device 0 osd.0
device 1 osd.1
device 2 osd.2
device 3 osd.3
device 4 osd.4
device 5 osd.5
device 6 osd.6
device 7 osd.7

  host ceph-osd-ssd-server-1 {
      id -1
      alg straw
      hash 0
      item osd.0 weight 1.00
      item osd.1 weight 1.00
  }

  host ceph-osd-ssd-server-2 {
      id -2
      alg straw
      hash 0
      item osd.2 weight 1.00
      item osd.3 weight 1.00
  }

  host ceph-osd-platter-server-1 {
      id -3
      alg straw
      hash 0
      item osd.4 weight 1.00
      item osd.5 weight 1.00
  }

  host ceph-osd-platter-server-2 {
      id -4
      alg straw
      hash 0
      item osd.6 weight 1.00
      item osd.7 weight 1.00
  }

  root platter {
      id -5
      alg straw
      hash 0
      item ceph-osd-platter-server-1 weight 2.00
      item ceph-osd-platter-server-2 weight 2.00
  }

  root ssd {
      id -6
      alg straw
      hash 0
      item ceph-osd-ssd-server-1 weight 2.00
      item ceph-osd-ssd-server-2 weight 2.00
  }

  rule data {
      ruleset 0
      type replicated
      min_size 2
      max_size 2
      step take platter
      step chooseleaf firstn 0 type host
      step emit
  }

  rule metadata {
      ruleset 1
      type replicated
      min_size 0
      max_size 10
      step take platter
      step chooseleaf firstn 0 type host
      step emit
  }

  rule rbd {
      ruleset 2
      type replicated
      min_size 0
      max_size 10
      step take platter
      step chooseleaf firstn 0 type host
      step emit
  }

  rule platter {
      ruleset 3
      type replicated
      min_size 0
      max_size 10
      step take platter
      step chooseleaf firstn 0 type host
      step emit
  }

  rule ssd {
      ruleset 4
      type replicated
      min_size 0
      max_size 4
      step take ssd
      step chooseleaf firstn 0 type host
      step emit
  }

  rule ssd-primary {
      ruleset 5
      type replicated
      min_size 5
      max_size 10
      step take ssd
      step chooseleaf firstn 1 type host
      step emit
      step take platter
      step chooseleaf firstn -1 type host
      step emit
  }

次に、以下を実行して SSD ルールを使用するようにプールを設定できます。

ceph osd pool set <poolname> crush_ruleset 4
注記
Red Hat は、RHCS 3 以降のリリースの ruleset 設定および crush_ruleset 設定をサポートしません。

SSD プールは、高速ストレージプールとして機能することができます。同様に、ssd-primary ルールを使用して、プール内の各配置グループを、プライマリーとして SSD を使用し、レプリカとしてプラッターを使用して配置することができます。

RHCS 3 以降

RHCS 3 以降のリリースでは、デバイスクラスを使用します。このプロセスはかなりシンプルで、各デバイスにクラスを追加します。以下に例を示します。

# ceph osd crush set-device-class <class> <osdId> [<osdId>]
# ceph osd crush set-device-class hdd osd.0 osd.1 osd.4 osd.5
# ceph osd crush set-device-class ssd osd.2 osd.3 osd.6 osd.7

次に、デバイスを使用するルールを作成します。

# ceph osd crush rule create-replicated <rule-name> <root> <failure-domain-type> <device-class>:
# ceph osd crush rule create-replicated cold default host hdd
# ceph osd crush rule create-replicated hot default host ssd

最後に、ルールを使用するようにプールを設定します。

ceph osd pool set <poolname> crush_rule <rule-name>
ceph osd pool set cold crush_rule hdd
ceph osd pool set hot crush_rule ssd

1 つの階層がデバイスのクラスを複数提供できるため、CRUSH マップを手動で編集する必要はありません。RHCS 2 の前述の例と比較すると、デバイスクラスを使用する場合の RHCS 3 の CRUSH マップは非常に簡単です。

device 0 osd.0 class hdd
device 1 osd.1 class hdd
device 2 osd.2 class ssd
device 3 osd.3 class ssd
device 4 osd.4 class hdd
device 5 osd.5 class hdd
device 6 osd.6 class ssd
device 7 osd.7 class ssd

  host ceph-osd-server-1 {
      id -1
      alg straw
      hash 0
      item osd.0 weight 1.00
      item osd.1 weight 1.00
      item osd.2 weight 1.00
      item osd.3 weight 1.00
  }

  host ceph-osd-server-2 {
      id -2
      alg straw
      hash 0
      item osd.4 weight 1.00
      item osd.5 weight 1.00
      item osd.6 weight 1.00
      item osd.7 weight 1.00
  }

  root default {
      id -3
      alg straw
      hash 0
      item ceph-osd-server-1 weight 4.00
      item ceph-osd-server-2 weight 4.00
  }


  rule cold {
      ruleset 0
      type replicated
      min_size 2
      max_size 11
      step take default class hdd
      step chooseleaf firstn 0 type host
      step emit
  }


  rule hot {
      ruleset 1
      type replicated
      min_size 2
      max_size 11
      step take default class ssd
      step chooseleaf firstn 0 type host
      step emit
  }

第3章 配置グループ (PG)

配置グループ(PG)は Ceph クライアントには表示されませんが、Ceph Storage クラスターでは重要な役割を果たします。

Ceph Storage クラスターでは、過剰なストレージ容量に達するために、数千の OSD が必要になる場合があります。Ceph クライアントは、クラスター全体の論理サブセットであるプールにオブジェクトを保存します。プールに保存されているオブジェクトの数は、何百万以上にも簡単に実行することができます。オブジェクト数が非常に多いか、より現実的にオブジェクトごとに配置を追跡することはできないが、依然として機能します。Ceph はオブジェクトを配置グループに割り当て、配置グループを OSD に割り当てて、動的かつ効率的にリバランスを行います。

 

コンピューターリンクのすべての問題は、当然多数の間接的な問題を除いて、別のレベルの間接解決で解決できます。

 
 -- David Wheeler

3.1. 配置グループの概要

プール内のオブジェクトごとにオブジェクト配置を追跡するには、スケーリングにコストがかかります。スケーリング時に高パフォーマンスを容易にするために、Ceph はプールを配置グループに分割し、各個別のオブジェクトを配置グループに割り当て、配置グループを プライマリー OSD に割り当てます。OSD が失敗した場合、またはクラスターのリバランスに失敗した場合、Ceph は配置グループ全体を移動または複製できます(例: 配置グループの全オブジェクト)。各オブジェクトを個別に対応する必要はありません。これにより、Ceph クラスターは効率的にリバランスまたは復旧できるようになります。

PG について

CRUSH が配置グループを OSD に割り当てる際に、これは一連の OSD を計算します。1 つ目はプライマリーです。レプリケートされたプールの場合は osd_pool_default_size 設定から 1 を引いた、イレイジャーコーディングされたプール用のコーディングチャンク M の数が、データを永続的に失わない配置グループを保存できる OSD の数を決定します。プライマリー OSD は、CRUSH を使用してセカンダリー OSD を特定し、配置グループの内容をセカンダリー OSD にコピーします。たとえば、CRUSH がオブジェクトを配置グループに割り当て、配置グループがプライマリー OSD として OSD 5 に割り当てられている場合、CRUSH が配置グループの OSD 1 および OSD 8 がセカンダリー OSD であることを算出すると、プライマリー OSD 5 はデータを OSD 1 および 8 にコピーします。クライアントの代わりにデータをコピーすることにより、Ceph はクライアントのインターフェースを単純化し、クライアントの負荷を減らします。同じプロセスでは、Ceph クラスターを動的にリカバリーおよびリバランスすることができます。

CRUSH 階層

プライマリー OSD が失敗し、クラスター外にマークが付けられると、CRUSH は配置グループを別の OSD に割り当てます。この OSD は配置グループ内のオブジェクトのコピーを受け取ります。Up Set 内の別の OSD は、プライマリー OSD ロールを想定します。

オブジェクトレプリカ数またはコーディングチャンクの数を増やす場合、CRUSH は各配置グループを必要に応じて追加の OSD に割り当てます。

注記

PG は OSD を所有しません。CRUSH は、データがクラスター全体に均等に分散されるように、多くの配置グループを各 OSD の擬似ランダムに割り当てます。

3.2. 配置グループトレードオフ

さらに配置グループについてのすべての OSD コール間のデータの永続性およびデータ分散は、CPU およびメモリーリソースを節約するためにパフォーマンスを最大限にするために必要最小限の数に減らす必要があります。

3.2.1. データの永続性

Ceph は、データの永続的な損失を防ぐために努めています。ただし、OSD が失敗すると、含まれるデータが完全に復元されるまで永続的なデータが失われるリスクが高まります。永続的なデータ損失は稀ですが、まだ可能です。以下のシナリオでは、データのコピーを 3 つ含む 1 つの配置グループで、Ceph でデータを永続的に失います。

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

ハードウェア障害は例外ではなく、予想されます。前述のシナリオを回避するには、復元プロセスが妥当なタイミングで十分になるように理想的です。クラスターのサイズ、ハードウェア構成、配置グループの数は、合計リカバリー時間において重要な役割を果たします。

小規模なクラスターは、迅速に復元しません。

3 つのレプリカプールに 512 の配置グループを持つ 10 OSD を含むクラスターでは、CRUSH に各配置グループ 3 つの OSD が割り当てられます。各 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 分かかります。一方、ホストに SATA OSD が 2 つあり、1GB/s スイッチが 5 台のホストを接続すると、復旧にかなり時間がかかります。このサイズのクラスターで、配置グループの数はデータの永続性にほとんど影響を与えません。配置グループ数は 128 または 8192 で、リカバリーの速度は低下したり、速くしたりしません。

ただし、10 OSD ではなく、同じ Ceph クラスターを 20 OSD に拡張すると、復元が高速化され、データの永続性が大幅に向上する可能性が高くなります。なぜですか?各 OSD は、150 ではなく 75 の配置グループのみに参加するようになりました。20 OSD クラスターでは、復旧のために残りの 19 個の OSD が同じ量のコピー操作を実行する必要があります。10 OSD クラスターでは、OSD ごとに約 100 GB をコピーする必要がありました。20 OSD クラスターでは、OSD はそれぞれ 50GB のみをコピーする必要があります。ネットワークがボトルネックであった場合、復元の速度は 2 倍になります。つまり、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 に増大すると、OSD が 3 つ低下すると、配置グループの数が破損します。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% になります。配置グループを 512 または 4096 にすると、データの永続性が懸念される範囲で、OSD が 50 未満のクラスターでほぼ同等です。

ヒント

nutshell では、OSD を増やすことで復元が速くなり、そのリスクが低くなるため、配置グループおよびそのオブジェクトが永久に失われます。

OSD をクラスターに追加する場合、新規 OSD に配置グループおよびオブジェクトを設定するのに時間がかかる場合があります。ただし、オブジェクトのパフォーマンスが低下したり、OSD を追加してもデータの永続性に影響を与えることはありません。

3.2.2. データ分散

Ceph は、ホットスポットを回避するために試みます。つまり、OSD によっては、他の OSD よりもかなり多くのトラフィックを受信します。理想的には、CRUSH はオブジェクトを配置グループに割り当てることが理想的です。これにより、配置グループが OSD に割り当てられるとき(またランダムな擬似)、OSD ストアオブジェクトはクラスター全体に均等に分散され、データ分散によりホットスポットやネットワークオーバーサブスクリプションの問題は開発できません。

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

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

OSD よりも配置グループの 1 つまたは 2 つの順序がある限り、ディストリビューションもでなければなりません。たとえば、3 OSD 用の 300 配置グループ、10 OSD の場合は 1000 配置グループなど。

OSD と配置グループ間の比率は、通常、オブジェクトストライピングなどの高度な機能を実装する Ceph クライアントに対して不均等にデータ分配の問題を解決します。たとえば、4TB ブロックデバイスは 4MB のオブジェクトをシャード化する可能性があります。

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

3.2.3. リソース使用状況

各配置グループについて、OSD および Ceph モニターには、常にメモリー、ネットワーク、および CPU が必要です。さらにリカバリー中にもメモリー、ネットワーク、および CPU が必要です。配置グループ内のオブジェクトをクラスタリングしてこのオーバーヘッドを共有することは、主な配置グループが存在する理由の 1 つです。

配置グループの数を最小限にすると、大量のリソースが節約されます。

3.3. PG 数

プール内の配置グループの数は、クラスターのピアがどのようにデータやリバランスを行うかにおいて重要な役割を果たします。配置グループの数を増やしても、小規模のクラスターでは、大規模なクラスターと比べてパフォーマンスが向上しました。ただし、同じ OSD にアクセスするプールが多数あるクラスターは、Ceph OSD がリソースを効率的に使用するように PG 数について注意して検討する必要があります。

ヒント

Red Hat は、OSD ごとに 100 から 200 までの PG を推奨しています。

3.3.1. PG Calculator

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

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

3.3.2. デフォルトの PG 数の設定

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

注記

正常性についての警告 POOL_PG_NUM_NOT_POWER_OF_TWO メッセージを回避するために、配置グループに 2 のべき乗の値を使用します。

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

配置グループの数(全体)と、オブジェクトに使用される配置グループの数(PG 分割で使用)の両方を設定する必要があります。これらは同等でなければなりません。

3.3.3. 小規模なクラスターの PG 数

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

3.3.4. PG 数の計算

OSD が 50 を超える場合は、リソースの使用、データの永続性、および分散のバランスを取るために、OSD ごとに約 50-100 の配置グループを推奨します。OSD が 50 未満の場合は、Small Clusters の 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 数 があることを確認します。

3.3.5. 最大 PG 数

オブジェクトを格納するために複数のデータプールを使用する場合は、確実に配置グループの数を OSD ごとに配置グループ数と分散し、配置グループの合計が妥当になるようにする必要があります。この目的は、システムリソースをトレーシングしたり、ピアリングプロセスが遅すぎる場合でも、OSD ごとに若干低い差異を実現することです。

10 プールで構成される exemplary Ceph Storage Cluster では、10 つの OSD 上に 512 の配置グループを持つ各プールでは、合計 5,120 配置グループが 10 つの OSD に分散するか、OSD ごとに 512 の配置グループに分散します。ハードウェア構成によっては、リソースを過剰に使用しない可能性があります。一方、512 個の配置グループを持つ 1,000 プールを作成すると、OSD は ~50,000 の配置グループを処理するため、より多くのリソースが必要になります。OSD ごとに配置グループの数が多過ぎると、特にリバランスまたは復旧時にパフォーマンスが大幅に低下します。

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

mon_max_pg_per_osd
ヒント

Ceph Object Gateways は 10-15 プールでデプロイします。したがって、1 OSD あたり 100 PG 未満の値を使用して、妥当な最大数に到達することを検討してください。

3.4. 配置グループの自動スケーリング

プール内の配置グループ(PG)の数は、クラスターのピア、データの分散、およびリバランスの方法について、重要な役割を果たします。

PG の数を自動スケーリングすると、クラスターの管理が容易になります。pg-autoscaling コマンドは、PG のスケーリングの推奨事項を示します。または、クラスターの使用状況に応じて PG を自動的にスケーリングします。

:context:strategies

3.4.1. 配置グループの自動スケーリング

auto-scaler の仕組み

auto-scaler はプールを分析し、サブツリーごとに調整します。各プールは異なる CRUSH ルールにマッピングでき、各ルールはデータを異なるデバイスに分散できるため、Ceph は階層の各サブツリーの使用率を個別に検討します。たとえば、クラス ssd の OSD にマップするプールと hdd クラスの OSD にマップするプールは、それぞれがそれぞれのデバイスタイプの数に依存する最適な PG 数を持ちます。

3.4.2. 配置グループの自動スケーリングモードの設定

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

  • off: プールの自動スケーリングを無効にします。管理者は、各プールに適切な PG 番号を選択するのはユーザー次第です。詳細は 「PG の数」セクションを参照してください。
  • on: 指定プールの PG 数の自動調整を有効にします。
  • warn: PG 数の調整が必要な場合にヘルスアラートを示します。

手順

  1. pg_autoscaling_mode を設定するには、以下を実行します。

    1. 既存のプールの場合:

      ceph osd pool set pool-name pg_autoscale_mode mode

      たとえば、プール testpool の自動スケーリングを有効にするには、以下を実行します。

      $ ceph osd pool set testpool pg_autoscale_mode on
    2. 新規作成されたプールのデフォルトとして、以下のコマンドを実行します。

      # ceph config set global osd_pool_default_pg_autoscale_mode <mode>

3.4.3. 配置グループの自動スケーリングの推奨事項の表示

手順

  1. 以下を使用して、各プール、その相対使用率、PG 数への推奨変更を表示できます。

    $ ceph osd pool autoscale-status

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

       POOL    SIZE  TARGET SIZE  RATE  RAW CAPACITY   RATIO
       a     12900M                3.0        82431M  0.4695
       c         0                 3.0        82431M  0.0000
       b         0        953.6M   3.0        82431M  0.0347
    
    
       TARGET RATIO  EFFECTIVE RATIO    PG_NUM  NEW PG_NUM  AUTOSCALE
                                            8         128   warn
             0.2000     0.9884              1          64   warn
                                            8               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 になります。このシステムでは、計算に実際の比率と実効比率が大きい方を使用します。

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

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

3.4.4. 配置グループの自動スケーリングの設定

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

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

手順

  1. mon_target_pg_per_osd を調整するには、以下を実行します。

    ceph config set global mon_target_pg_per_osd number

    以下に例を示します。

    $ ceph config set global mon_target_pg_per_osd 150

3.4.5. ターゲットプールサイズの指定

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

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

3.4.5.1. プールの絶対サイズを使用したターゲットサイズの指定

手順

  1. プールの絶対サイズ (バイト単位) を使用して target size を設定します。

    ceph osd pool set pool-name target_size_bytes value

    たとえば、mypool が 100T の領域を消費することが予想されるようにシステムに指示します。

    $ ceph osd pool set mypool target_size_bytes 100T

また、任意の --target-size-bytes <bytes> 引数を ceph osd pool create コマンドに追加すると、作成時にプールのターゲットサイズを設定することもできます。

3.4.5.2. クラスター合計容量を使用したターゲットサイズの指定

手順

  1. クラスター容量の合計の比率を使用して target size を設定します。

    ceph osd pool set pool-name target_size_ratio ratio

    以下に例を示します。

    $ ceph osd pool set mypool target_size_ratio 1.0

    システムに、target_size_ratio が設定された他のプールと比較して、プール mypool が 1.0 を消費することが予想されることをシステムに指示します。mypool がクラスター内の唯一のプールである場合、これは、合計容量の 100% が予想される使用を意味します。target_size_ratio が 1.0 である 2 番目のプールがある場合、両方のプールはクラスター容量の 50% の使用を想定します。

また、任意の --target-size-ratio <ratio> 引数を ceph osd pool create コマンドに追加すると、作成時にプールのターゲットサイズを設定することもできます。

注記

不可能なターゲットサイズ値 (クラスターの合計よりも大きな容量、または 1.0 を超える合計の割合) を指定した場合、クラスターは POOL_TARGET_SIZE_RATIO_OVERCOMMITTED または POOL_TARGET_SIZE_BYTES_OVERCOMMITTED の警告を発生させます。

プールに target_size_ratiotarget_size_bytes の両方を指定すると、クラスターは比率のみを考慮し、POOL_HAS_TARGET_SIZE_BYTES_AND_RATIO 正常性の警告を出します。

3.5. PG コマンドラインのリファレンス

ceph CLI では、プールの配置グループ数の設定および取得、PG マップの表示、PG の統計の取得を行うことができます。

3.5.1. PG 数の設定

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

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

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

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

3.5.2. PG の数を取得します。

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

ceph osd pool get {pool-name} pg_num

3.5.3. クラスターの PG 統計の取得

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

ceph pg dump [--format {format}]

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

3.5.4. 安定した PG の統計取得

すべての配置グループの統計が指定された状態で停止するには、以下のコマンドを実行します。

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 秒)。

3.5.5. PG マップの取得

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

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]

3.5.6. PG の統計の取得

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

ceph pg {pg-id} query

3.5.7. 配置グループのスクラビング

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

ceph pg scrub {pg-id}

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

3.5.8. 初期状態に戻す

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

可能な場所をすべてクエリーしてもオブジェクトが失われた場合は、失われたオブジェクトで中止する必要がある場合があります。これは、書き込み自体が復旧する前に実行された書き込みについてクラスターが把握できるようにする障害の組み合わせは通常通りです。

現在サポートされているオプションは「迂回」のみです。これはオブジェクトの以前のバージョンにロールバックするか、(新規オブジェクトの場合)完全に保持します。「 unfound」オブジェクトを「lost」としてマークするには、以下を実行します。

ceph pg {pg-id} mark_unfound_lost revert|delete
重要

オブジェクトが存在することが予想されるアプリケーションが混乱する可能性があるため、この機能は注意してください。

第4章 プール

Ceph クライアントは、データをプールに保存します。プールを作成すると、クライアントにデータを保存する I/O インターフェースが作成されます。Ceph クライアント(ブロックデバイス、ゲートウェイなど)の観点から見ると、Ceph ストレージクラスターとの対話は非常に簡単です。クラスターハンドルを作成してクラスターに接続し、クラスターに接続し、その後にオブジェクトとその拡張属性を読み書きするための I/O コンテキストを作成します。

クラスター処理の作成およびクラスターへの接続

Ceph Storage クラスターに接続するには、Ceph クライアントにはクラスター名 (通常は ceph) と初期モニターアドレスが必要です。Ceph クライアントは通常、Ceph 設定ファイルのデフォルトパスを使用してこれらのパラメーターを取得し、ファイルから読み込みます。ただし、ユーザーはコマンドラインでもパラメーターを指定することもできます。Ceph クライアントは、ユーザー名および秘密鍵も提供します (デフォルトでは認証は on です)。その後、クライアントは Ceph monitor クラスターに連絡し、モニター、OSD、プールなどのクラスターマップの最近のコピーを取得します。

ハンドルの作成

プール I/O コンテキストの作成

データの読み取りと書き込みを行うために、Ceph クライアントは Ceph Storage クラスターの特定のプールに対して i/o コンテキストを作成します。指定したユーザーにプールのパーミッションがある場合、Ceph クライアントは指定されたプールからの読み取りと書き込みを行うことができます。

I/O コンテキスト

Ceph のアーキテクチャーにより、ストレージクラスターはこの非常にシンプルなインターフェースを Ceph クライアントに提供できます。これにより、クライアントはプール名を指定して I/O コンテキストを作成するだけで、お客様が定義する高度なストレージストラテジーのいずれかを選択できます。ストレージストラテジーは、容量とパフォーマンス以外のすべてにおいて、Ceph クライアントには表示されません。同様に、Ceph クライアントの複雑さ(ブロックデバイス表現へのマッピング、S3/Swift RESTful サービスの提供)は Ceph ストレージクラスターには表示されません。

プールは以下を提供します。

  • 耐障害性: データを損失せずに失敗した OSD の数を設定できます。複製されたプールでは、必要なオブジェクトのコピー/レプリカ数になります。通常の設定では、オブジェクトと 1 つの追加コピー (例: size = 2) が保存されますが、コピー/レプリカの数は決定できます。イレイジャーコード化されたプールでは、コーディングされたチャンク ((つまり イレイジャーコードプロファイルm=2) の数になります。
  • 配置グループ: プールの配置グループの数を設定できます。一般的な設定では、OSD ごとに約 50-100 の配置グループを使用して、過剰なコンピュートリソースを使用せずに最適なバランスを提供します。複数のプールを設定する場合は、プールとクラスター全体に対して適した配置グループ数を設定するようにしてください。
  • CRUSH ルール: プールにデータをプールに保存すると、CRUSH ルールがプールにマッピングされた CRUSH ルールにより、CRUSH が各オブジェクトとそのレプリカ (またはイレイジャーコード化されたプールのチャンク) の配置のルールを特定できます。プールのカスタム CRUSH ルールを作成できます。
  • Snapshots: ceph osd pool mksnap を使用してスナップショットを作成すると、特定のプールのスナップショットが効果的に作成されます。
  • Quotas:ceph osd pool set-quota を使用してプールにクォータを設定する場合は、オブジェクトの最大数または指定されたプールに格納される最大バイト数を制限できます。

4.1. プールとストレージストラテジー

プールを管理するには、プールの一覧を表示、作成、および削除できます。各プールの使用状況の統計を表示することもできます。

4.2. プールの一覧表示

クラスターのプールを一覧表示するには、以下を実行します。

ceph osd lspools

4.3. プールの作成

プールを作成する前に、Red Hat Ceph Storage 4 の『設定ガイド』「プール、PS、および CRUSH 設定リファレンス」を参照してください。

注記

Red Hat Ceph Storage 3 以降のリリースでは、システム管理者はプールが Ceph クライアントから I/O 操作を受信できるようにする必要があります。詳細は、「アプリケーションの有効化」を参照してください。プールを有効にしないと、HEALTH_WARN のステータスになります。

デフォルト値はニーズに適さないため、Ceph 設定ファイルの配置グループ数のデフォルト値の調整が推奨されます。以下に例を示します。

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

レプリケートされたプールを作成するには、次のコマンドを実行します。

ceph osd pool create <pool-name> <pg-num> <pgp-num> [replicated] \
         [crush-rule-name] [expected-num-objects]

イレイジャーコーディングされたプールを作成するには、以下を実行します。

ceph osd pool create <pool-name> <pg-num> <pgp-num> erasure \
         [erasure-code-profile] [crush-rule-name] [expected-num-objects]

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

pool-name
詳細
プールの名前。一意である必要があります。
文字列
必須
はい。指定されていない場合は、Ceph 設定ファイルまたはデフォルト値に一覧表示される値に設定されます。
デフォルト
ceph
pg-num
詳細
プールの配置グループの合計数。適切な数を計算する方法は、「配置グループ」セクションおよびおよび 「Ceph Placement Groups (PGs) per Pool Calculator」を参照してください。デフォルト値 8 は、ほとんどのシステムには適していません。
整数
必須
はい
デフォルト
8
pgp-num
詳細
配置の目的で配置グループの合計数。この値は、配置グループ分割シナリオを除き、配置グループの合計数と同じでなければなりません。
整数
必須
はい。指定されていない場合は、Ceph 設定ファイルまたはデフォルト値に一覧表示される値に設定されます。
デフォルト
8
レプリケートまたは消去
詳細
オブジェクトまたは erasure を複数維持することで失われた OSD から復旧するために 複製 することのできるプールタイプは、一般的な RAID5 機能を取得します。複製されたプールにはより多くの RAW ストレージが必要ですが、すべての Ceph 操作を実装します。イレイジャーコーディングされたプールで必要なストレージは少なくなりますが、利用可能な操作のサブセットのみを実装します。
文字列
必須
いいえ
デフォルト
replicated
crush-rule-name
詳細
プールのクリーンルールの名前。このルールが存在する 必要があります。レプリケートされたプールの場合、名前は osd_pool_default_crush_rule 設定で指定されたルールになります。イレイジャーコーディングされたプールの場合は、デフォルトのイレイジャーコードプロファイルまたは {pool-name} を指定すると、名前が erasure-code になります。ルールが存在しない場合、Ceph は指定された名前でこのルールを暗黙的に作成します。
文字列
必須
いいえ
デフォルト
イレイジャーコーディングされたプールに erasure-code を使用します。複製されたプールの場合は、Ceph 設定からの osd_pool_default_crush_rule 変数の値を使用します。
expected-num-objects
詳細
プールの予想されるオブジェクト数。この値を、負の filestore_merge_threshold 変数と共に設定すると、Ceph は配置グループをプールの作成時に分割し、ランタイムディレクトリー分割によるレイテンシーの影響を回避します。
整数
必須
いいえ
デフォルト
0 (プールの作成時に分割されない)
erasure-code-profile
詳細
イレイジャーコーディングされたプールのみの場合イレイジャーコードプロファイルを使用します。これは、Ceph 設定ファイルの osd erasure-code-profile set 変数で定義されている既存のプロファイルでなければなりません。詳細は「コードプロファイルの消去」セクションを参照してください。
文字列
必須
いいえ

プールの作成時に、配置グループの数を妥当な値に設定します (例: 100)。OSD ごとの配置グループの合計数も検討してください。配置グループは計算にコストがかかるため、多くの配置グループを持つプールが多数ある場合(たとえば、それぞれ 100 個の配置グループを持つ 50 プールなど)のパフォーマンスが低下します。縮小のポイントは、OSD ホストの電力により異なります。

プールの適切な配置グループ数を計算する方法は、「配置グループ」セクションおよび「Ceph Placement Groups (PGs) per Pool Calculator」を参照してください。

4.4. プールクォータの設定

プールクォータは、最大バイト数またはプールごとの最大オブジェクト数、またはその両方に設定することができます。

ceph osd pool set-quota <pool-name> [max_objects <obj-count>] [max_bytes <bytes>]

以下に例を示します。

ceph osd pool set-quota data max_objects 10000

クォータを削除するには、その値を 0 に設定します。

注記

インフライトの書き込み操作では、Ceph がクラスター全体でプールの使用状況を伝播するまで、プールクォータが短期間オーバーランされる可能性があります。これは通常の動作です。インフライトの書き込み操作でプールクォータを実施すると、パフォーマンスが大幅に低下します。

4.5. プールの削除

プールを削除するには、以下を実行します。

ceph osd pool delete <pool-name> [<pool-name> --yes-i-really-really-mean-it]
重要

RHCS 3 以降のリリースでは、デフォルトではデータを保護するため、管理者はプールを削除できません。プールを削除する前に mon_allow_pool_delete 設定オプションを設定します。

プールに独自のルールがある場合は、プールを削除した後に削除を検討してください。プールのユーザーに厳密にユーザーがある場合は、プールの削除後にそのユーザーを削除することを検討してください。

4.6. プールの名前変更

プールの名前を変更するには、以下を実行します。

ceph osd pool rename <current-pool-name> <new-pool-name>

プールの名前を変更し、認証されたユーザーのプール別機能がある場合は、ユーザーの機能(例: 上限)を新しいプール名で更新する必要があります。

4.7. プール統計の表示

プールの使用状況の統計を表示するには、以下を実行します。

rados df

4.8. プールのスナップショットの作成

プールのスナップショットを作成するには、以下のコマンドを実行します。

ceph osd pool mksnap <pool-name> <snap-name>
警告

プールのスナップショットを作成する場合、プール内で RBD イメージのスナップショットを作成することができなくなり、元に戻せません。

4.9. プールのスナップショットの削除

プールのスナップショットを削除するには、以下のコマンドを実行します。

ceph osd pool rmsnap <pool-name> <snap-name>

4.10. プール値の設定

値をプールに設定するには、以下のコマンドを実行します。

ceph osd pool set <pool-name> <key> <value>

Pool Values セクションでは、設定可能なキーと値のペアをすべて表示します。

4.11. プール値の取得

プールから値を取得するには、以下のコマンドを実行します。

ceph osd pool get <pool-name> <key>

Pool Values セクションでは、取得可能なキーと値のペアをすべて表示します。

4.12. アプリケーションの有効化

RHCS 3 以降のリリースでは、承認されていないタイプのクライアントがプールにデータを作成しないように、プールの保護機能が追加されました。つまり、システム管理者は、Ceph Block Device、Ceph Object Gateway、Ceph Filesystem、またはカスタムアプリケーションから I/O 操作をプールが受信できるようにする必要があります。

クライアントアプリケーションがプールの I/O 操作を実行できるようにするには、以下を実行します。

[root@host ~]# ceph osd pool application enable <poolname> <app> {--yes-i-really-mean-it}

<app> は次のとおりです。

  • Ceph Filesystem 用の cephfs
  • Ceph ブロックデバイス用の rbd
  • Ceph Object Gateway 用の rgw
注記

カスタムアプリケーションに別の <app> 値を指定します。

重要

有効ではないプールは、HEALTH_WARN ステータスを生成します。このシナリオでは、ceph health detail -f json-pretty の出力により、以下が出力されます。

{
    "checks": {
        "POOL_APP_NOT_ENABLED": {
            "severity": "HEALTH_WARN",
            "summary": {
                "message": "application not enabled on 1 pool(s)"
            },
            "detail": [
                {
                    "message": "application not enabled on pool '<pool-name>'"
                },
                {
                    "message": "use 'ceph osd pool application enable <pool-name> <app-name>', where <app-name> is 'cephfs', 'rbd', 'rgw', or freeform for custom applications."
                }
            ]
        }
    },
    "status": "HEALTH_WARN",
    "overall_status": "HEALTH_WARN",
    "detail": [
        "'ceph health' JSON format has changed in luminous. If you see this your monitoring system is scraping the wrong fields. Disable this with 'mon health preluminous compat warning = false'"
    ]
}
注記
rbd pool init <pool-name> を使用して、Ceph ブロックデバイスのプールを初期化します。

4.13. アプリケーションの無効化

クライアントアプリケーションでプールの I/O 操作を実行できないようにするには、以下を実行します。

[root@host ~]# ceph osd pool application disable <poolname> <app> {--yes-i-really-mean-it}

<app> は次のとおりです。

  • Ceph Filesystem 用の cephfs
  • Ceph ブロックデバイス用の rbd
  • Ceph Object Gateway 用の rgw
注記

カスタムアプリケーションに別の <app> 値を指定します。

4.14. アプリケーションメタデータの設定

RHCS 3 以降のリリースは、クライアントアプリケーションの属性を記述するキーと値のペアを設定する機能を提供します。

プールにクライアントアプリケーションのメタデータを設定するには、以下を実行します。

[root@host ~]# ceph osd pool application set <poolname> <app> <key> <value>

<app> は次のとおりです。

  • Ceph Filesystem 用の cephfs
  • Ceph ブロックデバイス用の rbd
  • Ceph Object Gateway 用の rgw
注記

カスタムアプリケーションに別の <app> 値を指定します。

4.15. アプリケーションメタデータの削除

プールでクライアントアプリケーションのメタデータを削除するには、以下を実行します。

[root@host ~]# ceph osd pool application set <poolname> <app> <key>

<app> は次のとおりです。

  • Ceph Filesystem 用の cephfs
  • Ceph ブロックデバイス用の rbd
  • Ceph Object Gateway 用の rgw
注記

カスタムアプリケーションに別の <app> 値を指定します。

4.16. オブジェクトレプリカ数の設定

レプリケートされたプールのオブジェクトレプリカ数を設定するには、以下のコマンドを実行します。

ceph osd pool set <poolname> size <num-replicas>
重要

<num-replicas> パラメーターにはオブジェクト自体が含まれます。オブジェクトの合計 3 つのインスタンスについて、オブジェクトとオブジェクトの 2 つのコピーを含める場合は、3 を指定します。

以下に例を示します。

ceph osd pool set data size 3

このコマンドは、各プールに対して実行できます。

注記

オブジェクトは、pool size 設定での指定よりも少ないレプリカを持つ低下モードで I/O 操作を受け入れることができます。I/O に必要なレプリカの最小数を設定するには、min_size 設定を使用します。以下に例を示します。

ceph osd pool set data min_size 2

これにより、データプール内のオブジェクトは、min_size 設定で指定されたよりも少ないレプリカを持つ I/O を受信しないようになります。

4.17. オブジェクトレプリカ数の取得

オブジェクトのレプリカ数を取得するには、以下のコマンドを実行します。

ceph osd dump | grep 'replicated size'

Ceph はプールを一覧表示し、replicated size 属性を強調表示します。デフォルトでは、Ceph はオブジェクトのレプリカを 2 つ (つまり合計 3 つ、またはサイズ 3) 作成します。

4.18. プール値

以下の一覧には、設定または取得できるキーと値のペアを記載します。詳細は、「プール値の設定」および「プール値の取得」を参照してください。

size
詳細
プール内のオブジェクトのレプリカ数を指定します。詳細は「オブジェクトレプリカ数の設定」セクションを参照してください。複製されたプールにのみ該当します。
整数
min_size
詳細
I/O に必要なレプリカの最小数を指定します。詳細は「オブジェクトレプリカ数の設定」セクションを参照してください。複製されたプールにのみ該当します。
整数
crash_replay_interval
詳細
クライアントが確認済みでもコミットされていないリクエストを再生できるようにする秒数を指定します。
整数
pg-num
詳細
プールの配置グループの合計数。適切な数を計算する方法は、Red Hat Ceph Storage 4 のConfiguration Guide「プール、PG、および CRUSH 設定リファレンス」セクションを参照してください。デフォルト値 8 は、ほとんどのシステムには適していません。
整数
必須
はい。
デフォルト
8
pgp-num
詳細
配置の目的で配置グループの合計数。これは、配置グループ分割シナリオを除き、配置グループの合計数と同じでなければなりません
整数
必須
はい。default または Ceph の設定値が指定されていない場合は、この値を選択します。
デフォルト
8
有効な範囲
pg_num 変数で指定された値以下。
crush_rule
詳細
クラスター内のマッピングオブジェクトの配置に使用するルール。
文字列
hashpspool
詳細
指定プールの HASHPSPOOL フラグを有効または無効にします。このオプションを有効にすると、プールハッシュと配置グループのマッピングが変更され、プールおよび配置グループが重複する方法が改善されます。
整数
有効な範囲
1 はフラグを有効にし、0 はフラグを無効にします。
重要

OSD およびデータの量が多いクラスターの実稼働プールでは、このオプションを有効にしないでください。プール内のすべての配置グループは再マッピングされ、データの移動が大きすぎます。

fast_read
詳細
イレイジャーコーディングを使用するプールで、このフラグが有効な場合、読み取りリクエストは、すべてのシャードに対して後続の読み取りを実行し、クライアントを提供するのに十分なシャードを受け取るまで待機します。jerasure プラグインおよび isa erasure プラグインの場合は、最初の K 応答が返されると、クライアントのリクエストは応答からデコードされたデータを即座に使用します。これにより、パフォーマンスを改善するために、一部のリソースを割り当てるのに役立ちます。現在、このフラグはイレイジャーコーディングプールにのみサポートされています。
ブール値
デフォルト
0
allow_ec_overwrites
詳細
イレイジャーコード化されたプールへの書き込みがオブジェクトの一部を更新できるかどうか。したがって、Ceph Filesystem および Ceph ブロックデバイスがこれを使用できるようにします。
ブール値
バージョン
RHCS 3 以降。
compression_algorithm
詳細
BlueStore ストレージバックエンドで使用するインライン圧縮アルゴリズムを設定します。この設定は、bluestore_compression_algorithm 設定を上書きします。
文字列
有効な設定
lz4snappyzlibzstd
compression_mode
詳細
BlueStore ストレージバックエンドのインライン圧縮アルゴリズムのポリシーを設定します。この設定は、bluestore_compression_mode 設定を上書きします。
文字列
有効な設定
nonepassiveaggressiveforce
compression_min_blob_size
詳細
BlueStore は、このサイズより小さいチャンクを圧縮しません。この設定は、bluestore_compression_min_blob_size 設定を上書きします。
署名なしの整数
compression_max_blob_size
詳細
BlueStore は、データを圧縮する前に、このサイズより大きいチャンクを compression_max_blob_size の小さなブロブに分割します。
署名なしの整数
nodelete
詳細
指定されたプールで NODELETE フラグを設定または解除します。
整数
有効な範囲
1 はフラグを設定します。0 はフラグの設定を解除します。
nopgchange
詳細
指定したプールに NOPGCHANGE フラグを設定または設定解除します。
整数
有効な範囲
1 はフラグを設定します。0 フラグの設定を解除します。
nosizechange
詳細
指定したプールに NOSIZECHANGE フラグを設定または設定解除します。
整数
有効な範囲
1 はフラグを設定します。0 フラグの設定を解除します。
write_fadvise_dontneed
詳細
特定のプールの WRITE_FADVISE_DONTNEED フラグを設定または解除します。
整数
有効な範囲
1 はフラグを設定します。0 フラグの設定を解除します。
noscrub
詳細
指定したプールに NOSCRUB フラグを設定または設定解除します。
整数
有効な範囲
1 はフラグを設定します。0 フラグの設定を解除します。

nodeep-scrub

詳細
指定したプールに NODEEP_SCRUB フラグを設定または設定解除します。
整数
有効な範囲

1 はフラグを設定します。0 フラグの設定を解除します。

scrub_min_interval
詳細
負荷が低い場合のプールスクラビングの最小間隔(秒単位)。0 の場合、Ceph は osd_scrub_min_interval の設定を使用します。
double
デフォルト

0

scrub_max_interval
詳細
クラスター負荷に関係なくプールのスクラビングの最大間隔(秒単位)。0 の場合、Ceph は osd_scrub_max_interval の設定を使用します。
double
デフォルト

0

deep_scrub_interval
詳細
プールの「deep」のスクラビングの間隔(秒単位)。0 の場合、Ceph は osd_deep_scrub_interval の設定を使用します。
double
デフォルト
0

第5章 イレイジャーコードプール

Ceph ストレージストラテジーには、データ永続性の要件を定義します。データ永続性とは、データを損失せずに 1 つまたは複数の OSD が失われることを持続できることを意味します。

Ceph はデータをプールに保存し、プールには 2 つのタイプがあります。

  • replicated
  • erasure-coded

Ceph はデフォルトで複製されたプールを使用します。つまり、Ceph はすべてのオブジェクトをプライマリー OSD ノードから 1 つまたは複数のセカンダリー OSD にコピーします。

イレイジャーコーディングされたプールは、データの永続性を確保するために必要なディスク容量を削減しますが、レプリケーションよりも若干コストが計算されています。

イレイジャーコーディングは、Ceph ストレージクラスターにオブジェクトを大幅に格納する方法であり、イレイジャーコードアルゴリズムによりオブジェクトがデータチャンク (k)、およびコーディングチャンク (m) に分割され、これらのチャンクを異なる OSD に保存します。

OSD に障害が発生すると、Ceph は他の OSD から残りのデータ (k) およびコーディング (m) チャンクを取得し、イレイジャーコードアルゴリズムはこれらのチャンクからオブジェクトを復元します。

注記

Red Hat では、書き込みやデータの損失を防ぐために、イレイジャーコーディングされたプールの min_sizeK+2 以上にすることが推奨します。

イレイジャーコーディングは、レプリケーションよりも効率的にストレージ容量を使用します。n 個のレプリケーションアプローチは、オブジェクトの n 個のコピーを維持するのに対し (Ceph のデフォルトは 3x)、イレイジャーコーディングは k + m チャンクのみを保持します。たとえば、3 つのデータと 2 つのコーディングチャンクは、元のオブジェクトのストレージ領域の 1.5x を使用します。

イレイジャーコーディングはレプリケーションよりもストレージのオーバーヘッドが少なくなりますが、イレイジャーコードアルゴリズムはオブジェクトのアクセスまたは復旧時にレプリケーションよりも多くの RAM と CPU を使用します。データストレージを永続性や耐障害性を確保しなければならないが、高速の読み取りパフォーマンスを必要としない場合(コールドストレージ、履歴レコードなど)は、イレイジャーコーディングに利点があります。

Ceph でのイレイジャーコードがどのように機能するかの詳細は、Red Hat Ceph Storage 4 の『アーキテクチャーガイド』「イレイジャーコード I/O」セクションを参照してください。

k=2 および m=1 を使用してクラスターを初期化する際に、Ceph は デフォルト のイレイジャーコードプロファイルを作成します。つまり、Ceph は 3 つの OSD (k+m == 3) にオブジェクトデータを分散し、Ceph がこれらの OSD のいずれかを、データを失うことなく失う可能性があることを意味します。イレイジャーコードのプロファイリングの詳細は、「イレイジャーコードのプロファイル」を参照してください。

重要

.rgw.buckets プールのみをイレイジャーコーディング済みとして設定し、その他のすべての Ceph Object Gateway プールをレプリケート済みとして設定すると、新しいバケットを作成しようとすると以下のエラーで失敗します。

set_req_state_err err_no=95 resorting to 500

このため、イレイジャーコーディングされたプールは omap 操作をサポートしません。特定の Ceph Object Gateway メタデータプールには omap サポートが必要です。

5.1. サンプル Erasure-code プールの作成

最もシンプルなイレイジャーコードプールは RAID5 と同等であり、少なくとも 3 つのホストを必要とします。

$ ceph osd pool create ecpool 50 50 erasure
pool 'ecpool' created
$ echo ABCDEFGHI | rados --pool ecpool put NYAN -
$ rados --pool ecpool get NYAN -
ABCDEFGHI
注記

pool create の 50 は配置グループの数を表します。

5.2. イレイジャーコードプロファイル

Ceph は、プロファイル でイレイジャーコーディングされたプールを定義します。Ceph は、イレイジャーコーディングされたプールと関連する CRUSH ルールの作成時にプロファイルを使用します。

Ceph は、クラスターを初期化する際にデフォルトのイレイジャーコードプロファイルを作成し、複製されたプール内の 2 つのコピーと同じレベルの冗長性を提供します。ただし、使用するストレージ容量は 25% 少なくなります。デフォルトのプロファイルは k=2 および m=1 を定義します。Ceph はオブジェクトデータを 3 つの OSD (k+m=3) に分散し、Ceph はデータを損失することなくこれらの OSD のいずれかを失う可能性があります。

デフォルトのイレイジャーコードプロファイルは、1 つの OSD が失われないようにすることができます。これはサイズ 2 の複製されたプールと同等ですが、1 TB のデータを保存するには 2 TB の代わりに 1.5 TB が必要です。デフォルトプロファイルを表示するには、以下のコマンドを使用します。

$ ceph osd erasure-code-profile get default
directory=.libs
k=2
m=1
plugin=jerasure
crush-failure-domain=host
technique=reed_sol_van

新しいプロファイルを作成して、raw ストレージ要件を増やさずに冗長性を改善できます。たとえば、k=8m=4 のプロファイルでは、12 個の (k+m=12) OSD オブジェクトを配布することで、4 個の (m=4) OSD が失われないようにすることができます。Ceph はオブジェクトを 8 つのチャンクに分割し、リカバリー用に 4 つのコーディングチャンクを計算します。たとえば、オブジェクトサイズが 8 MB の場合、各データチャンクは 1 MB で、コーディングチャンクはそれぞれ 1 MB のサイズと同じです。4 つの OSD が同時に失敗した場合でもオブジェクトが失われることはありません。

プロファイルで最も重要なパラメーターは、ストレージのオーバーヘッドとデータの永続性を定義するため、km、および crush-failure-domain です。

重要

プールの作成後にプロファイルを変更できないため、正しいプロファイルを選択することが重要になります。プロファイルを変更するには、異なるプロファイルで新しいプールを作成し、そのオブジェクトを古いプールから新しいプールに移行する必要があります。

たとえば、必要なアーキテクチャーがストレージオーバーヘッドの 50% オーバーヘッドがある 2 つのラックの損失を持続させる必要がある場合は、以下のプロファイルを定義できます。

$ ceph osd erasure-code-profile set myprofile \
   k=4 \
   m=2 \
   crush-failure-domain=rack
$ ceph osd pool create ecpool 12 12 erasure *myprofile*
$ echo ABCDEFGHIJKL | rados --pool ecpool put NYAN -
$ rados --pool ecpool get NYAN -
ABCDEFGHIJKL

プライマリー OSD は、NYAN オブジェクト を 4 つ (k=4) のデータチャンクに分割し、2 つの追加のチャンク (m=2) を作成します。m の値は、データを失うことなく同時に失われた OSD の数を定義します。crush-failure-domain=rack は、2 つのチャンクが同じラックに保存されないように CRUSH ルールを作成します。

イレイジャーコード
重要

Red Hat は、k および m に以下の jerasure コーディング値をサポートしています。

  • k=8 m=3
  • k=8 m=4
  • k=4 m=2
重要

失われた OSD の数がコーディングチャンクの数 (m) と同等である場合、イレイジャーコーディングプールの一部の配置グループは不完全な状態になります。失われた OSD の数が m 未満の場合、配置グループは不完全な状態になりません。いずれの場合でも、データの損失は発生しません。配置グループが不完全な状態の場合は、イレイジャーコード化されたプールの min_size を一時的に縮小することで復元が可能になります。

5.2.1. OSD erasure-code-profile Set

新しいイレイジャーコードプロファイルを作成するには、次のコマンドを実行します。

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

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

directory
詳細
イレイジャーコードプラグインが読み込まれた ディレクトリー 名を設定します。
文字列
必須
いいえ
デフォルト
/usr/lib/ceph/erasure-code
プラグイン
詳細
イレイジャーコードプラグインを使用して、コーディングチャンクを計算し、不足しているチャンクを復元します。詳細は「イレイジャーコードのプラグイン」セクションを参照してください。
文字列
必須
いいえ
デフォルト
jerasure
stripe_unit
詳細
ストライプごとのデータチャンクのデータ量。たとえば、2 つのデータチャンクと stripe_unit=4K のプロファイルでは、範囲 0 ~ 8,000 がチャンク 0 に設定され、4,000 ~ 8,000 がチャンク 1 に、8,000 ~ 12,000 がチャンク 0 に再び設定されます。パフォーマンスを最適化するには、4K の倍数にする必要があります。デフォルト値は、プールの作成時に監視設定オプション osd_pool_erasure_code_stripe_unit から取得されます。このプロファイルを使用するプールの stripe_width は、この stripe_unit で乗算したデータチャンクの数になります。
文字列
必須
いいえ
デフォルト
4K
crush-device-class
詳細
hddssd などのデバイスクラス。利用することができるのは、RHCS 3 以降のみです。
文字列
必須
いいえ
デフォルト
none (CRUSH がクラスに関係なくすべてのデバイスを使用することを意味します)。
crush-failure-domain
詳細
hostrack などの障害ドメイン。
文字列
必須
いいえ
デフォルト
host
key
詳細
残りのキーと値のペアのセマンティクスは、イレイジャーコードプラグインで定義されます。
文字列
必須
いいえ
--force
詳細
既存のプロファイルを同じ名前で上書きします。
文字列
必須
いいえ

5.2.2. OSD erasure-code-profile Remove

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

ceph osd erasure-code-profile rm <name>

プロファイルがプールによって参照されると、削除に失敗します。

5.2.3. OSD erasure-code-profile Get

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

ceph osd erasure-code-profile get <name>

5.2.4. OSD erasure-code-profile List

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

ceph osd erasure-code-profile ls

5.3. 上書きによるイレイジャーコーディング

デフォルトでは、イレイジャーのコード化されたプールは Ceph Object Gateway でのみ機能します。これは、完全なオブジェクトの書き込みと追加を実行します。Red Hat Ceph Storage 3.x の時点で、イレイジャーコード化されたプールへの部分的な書き込みは、プールごとに有効にできます。

上書きでイレイジャーコード化されたプールを使用すると、Ceph ブロックデバイスと CephFS はそれらのデータをイレイジャーコードプールに保存します。

構文

ceph osd pool set <erasure_coded_pool_name> allow_ec_overwrites true

$ ceph osd pool set ec_pool allow_ec_overwrites true

上書きでクレイジャーコード化されたプールを有効にすることは、BlueStore OSD を使用するプールにのみ存在します。BlueStore のチェックサムは、深いスクラビング中にビットロットやその他の破損を検出するために使用されます。イレイジャーコード化された上書きで FileStore を使用することは危険を伴うため、BlueStore と比較してパフォーマンスが低くなります。

イレイジャーコード化されたプールは omap をサポートしません。Ceph Block Device と CephFS でイレイジャーコード化されたプールを使用するには、データをイレイジャーコードされたプールに格納し、メタデータを複製されたプールに保存します。

Ceph ブロックデバイスの場合は、イメージの作成時に --data-pool オプションを使用します。

構文

rbd create --size <image_size>M|G|T --data-pool <erasure_coded_pool_name> <replicated_pool_name>/<image_name>

$ rbd create --size 1G --data-pool ec_pool rep_pool/image01

CephFS にイレイジャーコード化されたプールを使用する場合には、ファイルレイアウトで上書きを設定する必要があります。

5.4. イレイジャーコードプラグイン

Ceph は、プラグインアーキテクチャーを使用したイレイジャーコーディングをサポートします。つまり、異なる種別のアルゴリズムを使用して、イレイジャーコード化されたプールを作成することができます。Ceph は以下をサポートします。

  • Jerasure(デフォルト)
  • ローカルで使用できる
  • ISA(Intel のみ)

以下のセクションでは、これらのプラグインについて詳しく説明します。

5.4.1. Jerasure Erasure Code Plugin

jerasure プラグインは、最も汎用的で柔軟性のあるプラグインです。Ceph のイレイジャーコード化されたプールもデフォルトです。

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]

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

k
詳細
各オブジェクトは data-chunks の部分で分割され、それぞれが異なる OSD に保管されます。
整数
必須
はい。
4
m
詳細
各オブジェクトの コーディングチャンク を計算し、それらを異なる OSD に保存します。コーディングチャンクの数は、データを損失することなくダウンできる OSD 数でもあります。
整数
必須
はい。
2
技術
詳細
より柔軟な技術は reed_sol_van で、km を設定するだけで十分です。cauchy_good 技術は速くなりますが、慎重に packetsize を選択する必要があります。reed_sol_r6_opliberationblaum_rothliber8tion はすべて、m=2 でしか設定できない意味で RAID6 と同等です。
文字列
必須
いいえ
有効な設定
reed_sol_van reed_sol_r6_op cauchy_orig cauchy_good liberation blaum_roth liber8tion
デフォルト
reed_sol_van
packetsize
詳細
エンコーディングは、バイト サイズのパケットで一度に行われます。正しいパケットサイズを選択することは困難です。jerasure ドキュメントには、このトピックに関する詳細な情報が記載されています。
整数
必須
いいえ
デフォルト
2048
crush-root
詳細
ルールの最初のステップに使用される CRUSH バケットの名前。たとえば、step take default となります。
文字列
必須
いいえ
デフォルト
default
crush-failure-domain
詳細
同じ障害ドメインを持つバケットに 2 つのチャンクがないことを確認します。たとえば、障害ドメインが ホスト の場合、2 つのチャンクは同じホストに保存されません。これは、step chooseleaf host などのルールステップを作成するのに使用します。
文字列
必須
いいえ
デフォルト
host
directory
詳細
イレイジャーコードプラグインが読み込まれた ディレクトリー 名を設定します。
文字列
必須
いいえ
デフォルト
/usr/lib/ceph/erasure-code
--force
詳細
既存のプロファイルを同じ名前で上書きします。
文字列
必須
いいえ

5.4.2. Localingable Erasure Code(LRC)プラグイン

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

lrc イレイジャーコードプラグインは、少ない OSD を使用して復元できるようにローカルパリティーチャンクを作成します。たとえば、k=8m=4、および l=4lrc を設定する場合は、4 つの OSD ごとに追加のパリティーチャンクが作成されます。Ceph が 1 つの OSD を失うと、複数の OSD ではなく 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

5.4.2.1. LRC プロファイルの作成

新しい LRC イレイジャーコードプロファイルを作成するには、次のコマンドを実行します。

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]

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

k
詳細
各オブジェクトは data-chunks の部分で分割され、それぞれが異なる OSD に保管されます。
整数
必須
はい。
4
m
詳細
各オブジェクトの コーディングチャンク を計算し、それらを異なる OSD に保存します。コーディングチャンクの数は、データを損失することなくダウンできる OSD 数でもあります。
整数
必須
はい。
2
l
詳細
コーディングとデータチャンクをサイズの 局所性 のセットにグループ化します。たとえば、k=4 および m=2locality=3 の場合は、3 つのグループが 2 つ作成されます。各セットは、別のセットからチャンクを読み取りせずに復元できます。
整数
必須
はい。
3
crush-root
詳細
ルールの最初のステップに使用される crush バケットの名前。たとえば、step take default となります。
文字列
必須
いいえ
デフォルト
default
crush-locality
詳細
l で定義される各チャンクのセットの crush バケットのタイプが保存されます。たとえば、rack に設定すると、l チャンクの各グループは異なるラックに配置されます。これは、step choose rack などのルールステップを作成するために使用されます。設定されていない場合は、このようなグループ化は行われません。
文字列
必須
いいえ
crush-failure-domain
詳細
同じ障害ドメインを持つバケットに 2 つのチャンクがないことを確認します。たとえば、障害ドメインが ホスト の場合、2 つのチャンクは同じホストに保存されません。これは、step chooseleaf host などのルールステップを作成するのに使用します。
文字列
必須
いいえ
デフォルト
host
directory
詳細
イレイジャーコードプラグインが読み込まれた ディレクトリー 名を設定します。
文字列
必須
いいえ
デフォルト
/usr/lib/ceph/erasure-code
--force
詳細
既存のプロファイルを同じ名前で上書きします。
文字列
必須
いいえ

5.4.2.2. 低レベル LRC プロファイルの作成

k および m の合計は、l パラメーターの倍数でなければなりません。低レベルの設定パラメーターはこのような制限を課さないため、特定の目的で使用すると便利です。たとえば、4 つのチャンクを持つグループと、3 つのチャンクを持つ 2 つのグループを定義できます。データセンターやデータセンターへのラックなど、ローカリティーセットを再帰的に定義することもできます。k/m/l は、低レベルの設定を生成することで実装されます。

lrc イレイジャーコードプラグインは、イレイジャーコード技術を再帰的に適用し、一部のチャンクの失われた状態を回復するには、ほとんどの場合は、利用可能なチャンクのサブセットのみが必要になります。

たとえば、3 つのコーディング手順が以下のように記述されている場合などです。

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

c がデータチャンク D から計算したチャンクをコーディングする場合、チャンク 7 の損失は、最後の 4 つのチャンクを使用して復元できます。chun 2 チャンクが失われると、最初の 4 つのチャンクを使用して復元できます。

miminal テストシナリオは、デフォルトのイレイジャーコードプロファイルを使用することと厳密に同等です。DDK=2 を意味し、cM=1 を意味し、デフォルトで jerasure プラグインを使用します。

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

lrc プラグインは、ラック間の帯域幅の使用量を減らすのに特に便利です。すべてのホストが同じスイッチに接続されている場合は、おそらく関心のあるユースケースではありませんが、帯域幅の使用量が実際に確認することができます。チャンクのレイアウトは異なりますが、k=4m=2、および l=3 と同等です。

$ 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

Firefly では、プライマリー OSD が失われたチャンクと同じラックにある場合にのみ、帯域幅が低下することが確認されます。

$ 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

LRC は、デフォルトの EC バックエンドとして jerasure を使用するようになりました。低レベルの設定を使用して、レイヤーごとに EC バックエンドおよびアルゴリズムを指定することができます。layers='[ [ "DDc", "" ] ]' の 2 番目の引数は、実際にはこのレベルに使用されるイレイジャーコードプロファイルです。以下の例では、lrcpool で使用される Cauchy 手法を使用する ISA バックエンドを指定します。

$ 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

5.4.3. CRUSH 配置の制御

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

chunk nr    01234567

step 1      _cDD_cDD
step 2      cDDD____
step 3      ____cDDD

各チャンクに 1 つずつ、正確に 8 つの OSD が必要です。ホストが 2 つの近傍のラックにある場合、最初の 4 つのチャンクを最初のラックに、最後の 4 つを 2 番目のラックに配置することができます。1 つの OSD の失われた状態からの復旧では、2 つのラック間で帯域幅を使用する必要はありません。

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

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

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

ルールは、手動で作成して詳細な制御を行うこともできます。

5.5. ISA Erasure Code Plugin

isa プラグインは ISA ライブラリーをカプセル化します。Intel プロセッサーでのみ動作します。

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

ceph osd erasure-code-profile set <name> \
     plugin=isa \
     technique=<reed_sol_van|cauchy> \
     [k=<data-chunks>] \
     [m=<coding-chunks>] \
     [crush-root=<root>] \
     [crush-failure-domain=<bucket-type>] \
     [directory=<directory>] \
     [--force]

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

技術
詳細
ISA プラグインは 2 つの Reed Solomon フォームで構成されます。reed_sol_van を設定すると、Vandermonde になります。cauchy を設定すると、Cauchy になります。
文字列
必須
いいえ
有効な設定
reed_sol_van cauchy
デフォルト
reed_sol_van
k
詳細
各オブジェクトは data-chunks の部分で分割され、それぞれが異なる OSD に保管されます。
整数
必須
いいえ
デフォルト
7
m
詳細
各オブジェクトの コーディングチャンク を計算し、それらを異なる OSD に保存します。コーディングチャンクの数は、データを損失することなくダウンできる OSD 数でもあります。
整数
必須
いいえ
デフォルト
3
crush-root
詳細
ルールの最初のステップに使用される crush バケットの名前。たとえば、step take default となります。
文字列
必須
いいえ
デフォルト
default
crush-failure-domain
詳細
同じ障害ドメインを持つバケットに 2 つのチャンクがないことを確認します。たとえば、障害ドメインが ホスト の場合、2 つのチャンクは同じホストに保存されません。これは、step chooseleaf host などのルールステップを作成するのに使用します。
文字列
必須
いいえ
デフォルト
host
directory
詳細
イレイジャーコードプラグインが読み込まれた ディレクトリー 名を設定します。
文字列
必須
いいえ
デフォルト
/usr/lib/ceph/erasure-code
--force
詳細
既存のプロファイルを同じ名前で上書きします。
文字列
必須
いいえ

5.6. Pyramid Erasure Code

Pyramid イレイジャーコードは基本的に、データのアクセスと復旧を改善するための、元のイレイジャーコードに基づいた改良されたアルゴリズムです。これは単に、任意の (n, k) に対して Reed-Solomon のような既存の MDS (Maximum Curve Separable) コードを判別するだけです。ここで、k はデータチャンクの元の数で、n はコーディングプロセス後のデータチャンクの合計数です。Pyramid コードは標準の MDS コードをベースにしているため、同じエンコーディング/デコーディングのアプローチがあります。Pyramid コーディングされたデータプールには、通常のイレイジャーコード化されたプールなど、任意障害と同じ書き込みオーバーヘッドと同じリカバリー機能があります。pyramid コードの唯一の利点は、通常のイレイジャーコードと比べ、読み取りのオーバーヘッドが大幅に削減することです。

たとえば、(11, 8)のイレイジャープールをコード化し、その中に Pyramid コードアプローチを適用しましょう。(11, 8)イレイジャープールを(12 8)Pyramid coded pool に変換します。イレイジャーコード化されたプールには 8 個のデータチャンク、11 - 8 = 3 の冗長チャンクがあります。Pyramid Code は、8 データチャンクを P1 = {a1、a2、a3、a4}、および P2 = {a5, a6、a7、a8} などの 2 つの同等のサイズグループに分けます。イレイジャーコードからの冗長チャンクの 2 つが変更されていない状態です(b2 や b3)。この 2 つのチャンクは、8 つのデータチャンクをすべてカバーするため、グローバル冗長チャンクと呼ばれます。次に、グループ P1 に対して新しい冗長チャンクが計算され、グループ (またはローカル) の冗長チャンク b1,1 として表示されます。P2 のデータチャンクをすべて 0 に設定することを除き、計算は元のイレイジャーコードで b1 を計算するかのように行われます。同様に、グループの冗長チャンク b1,2 は P2 に対して計算されます。グループの冗長チャンクは、対応するグループのデータチャンクの影響を受けるだけで、他のグループは影響を受けません。グループの冗長チャンクは、イレイジャーコード内の元の冗長チャンクが各グループ(例: b1,1 + b1,2 = b1)に展開されるものとして解釈できます。したがって、このアプローチでは、1 つのデータチャンクが失敗した場合に、通常のクレイジャーコードされたプールに対して 8 ではなく、読み取りオーバーヘッド 4 を使用して復元できます。たとえば、P1a3 に障害が発生し、a1 がスクラビングの代表的な OSD である場合は P2 からの読み取りではなく、a1a2a4、および b1,1 を使用して a3 を回復できます。すべてのチャンクの読み取りは、同じグループに複数のチャンクが不足する場合にのみ必要です。

この Pyramid コードには、元のイレイジャーコードと同じ書き込みオーバーヘッドがあります。データチャンクが更新されるたびに、Pyramid Code は 3 つの冗長チャンク(b2、b3、および b1,1 または b1,2)を更新する必要がありますが、イレイジャーコードは 3 つの冗長チャンク(b1、b2、および b3)も更新します。また、通常のイレイジャーコードと同じ 3 つの任意のイレイジャーを回復できます。上記で説明したように、唯一の利点は、追加の冗長チャンクを 1 つ使用しても、読み取りのオーバーヘッドはより低くなります。そのため、Pyramid コードでは、アクセス効率を向上させるためにストレージ領域がトレードされます。

以下の図は、構築された Pyramid コードを示しています。

Pyramid イレイジャーコード

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.