Menu Close

第7章 ストレージストラテジーの開発

Ceph StorageクラスターとCeph Object Gatewaysを本番環境で使用するように設定する際に難しいのは、効果的なストレージ戦略を定義することです。ストレージ戦略には次のような要素があります。

ストレージストラテジーおよびコマンドラインの使用方法に関する一般的なガイダンスは、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドを参照してください。

7.1. CRUSH 階層の開発

CephクラスタとObject Gatewayを展開する場合、通常、Object Gatewayにはデフォルトのゾーングループとゾーンがあります。Cephストレージクラスタにはデフォルトのプールがあり、そのプールではデフォルトのCRUSH階層とデフォルトのCRUSHルールを持つCRUSHマップが使用されます。

重要

デフォルトの rbd プールはデフォルトの CRUSH ルールを使用できます。Ceph クライアントがデフォルトのルールまたは階層を使用してクライアントデータを保存している場合は、それらを削除 しないでください

CRUSH 階層に関する一般的な詳細は、『ストレージストラテジー』ガイドの「CRUSH 管理」セクションを参照してください。

実稼働ゲートウェイは通常、ゲートウェイの用途と地理的位置に応じて名前が付けられたカスタムの レルム、ゾーングループ、およびゾーン を使用します。さらに、Cephクラスターには、複数のCRUSH階層を持つCRUSHマップがあります。

  • サービスプール: 少なくとも 1 つの CRUSH 階層はサービスプール用であり、場合によってはデータ用になります。サービスプールには、.rgw.root と、ゾーンに関連付けられたサービスプールが含まれます。サービスプールは通常、単一のCRUSH階層に属し、データの耐久性のためにレプリケーションを使用します。データプールでもCRUSH階層を使用することができますが、通常はデータの耐久性を高めるために消去コードを使用して構成されます。
  • インデックス: 少なくとも 1 つの CRUSH 階層はインデックスプール用にある 必要があり、CRUSH 階層は SSD ドライブや NVMe ドライブなどの高パフォーマンスのメディアにマップされます。バケットインデックスは、パフォーマンスのボトルネックになることがあります。このCRUSH階層では、SSDまたはNVMeドライブを使用することを強く推奨します。経済性を高めるために、OSDジャーナルに使用するSSDやNVMeドライブにインデックス用のパーティションを作成します。また、インデックスにはバケットシャーディングを設定する必要があります。詳細は、「インデックスプールの作成」およびサポートリンクを参照してください。
  • 配置プール: 各配置ターゲットの配置プールには、バケットインデックス、データバケット、およびバケットの追加が含まれます。これらのプールは、別々のCRUSH階層の下に置かれることがあります。Ceph Object Gatewayは複数のストレージポリシーをサポートしているため、ストレージポリシーのバケットプールは、IOPS最適化、スループット最適化、容量最適化などの異なるユースケースを反映して、異なるCRUSH階層に関連付けられている場合があります。バケットインデックスプールには、SSD ドライブ、NVMe ドライブなどの高性能記憶媒体にバケットインデックスプールをマップするために、独自の CRUSH 階層を使用 すべきです

7.1.1. CRUSH ルートの作成

管理ノードのコマンドラインから、各CRUSH階層のCRUSHマップにCRUSHルートを作成します。また、潜在的にデータストレージプールを担うことができるサービスプールに、少なくとも 1 つの CRUSH 階層がある 必要があります。そのような SSD、NVMe ドライブなどの高性能ストレージメディアにマッピングされたバケットインデックスプールに、少なくとも 1 つの CRUSH 階層がある はずです

CRUSH階層の詳細については、『Red Hat Ceph Storage Strategies Guide 4』の CRUSHの階層のセクションを参照してください。

CRUSHマップを手動で編集するには、『Red Hat Ceph Storage Strategies Guide』の CRUSHマップの編集 Red Hat Ceph Storage Storage Strategies Guide 4』のセクションを参照してください。

以下の例では、data0data1、および data2 という名前のホストは、同じ物理ホストを参照する CRUSH の階層が複数存在するため、data0-sas-ssddata0-index などの拡張論理名を使用します。

典型的なCRUSHルートは、ジャーナル用のSASドライブとSSDを搭載したノードを表しています。以下に例を示します。

##
# SAS-SSD ROOT DECLARATION
##

root sas-ssd {
  id -1   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-sas-ssd weight 4.000
  item data1-sas-ssd weight 4.000
  item data0-sas-ssd weight 4.000
}

バケットインデックスの CRUSH ルートは、SSD や NVMe ドライブなどの高パフォーマンスメディアを表す はずです。SSD または NVMe メディアに OSD ジャーナルを保存するパーティションを作成することを検討してください。以下に例を示します。

##
# INDEX ROOT DECLARATION
##

root index {
  id -2    # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-index weight 1.000
  item data1-index weight 1.000
  item data0-index weight 1.000
}

7.1.2. CRUSH マップでの論理ホスト名の使用

RHCS 3以降のリリースでは、CRUSHはストレージデバイスの「クラス」という概念をサポートしていますが、これはRHCS 2以前のリリースではサポートされていません。NVMe、SSD、HDDなどの複数のクラスのストレージデバイスを含むホストまたはノードを持つRHCS 3クラスタでは、ストレージデバイスの異なるクラスを区別するために、デバイスクラスを持つ単一のCRUSH階層を使用します。これにより、論理的なホスト名を使用する必要がなくなります。RHCS 2およびそれ以前のリリースでは、複数のCRUSH階層を使用し、デバイスのクラスごとに1つずつ使用し、CRUSH階層内のホストまたはノードを区別するために論理ホスト名を使用します。

CRUSHマップでは、ホスト名はユニークで一度しか使用してはいけません。ホストが複数のCRUSH階層やユースケースに対応している場合、CRUSHマップでは、ホスト名が一度しか使用されないようにするため、実際のホスト名ではなく論理的なホスト名を使用することができます。例えば、ノードには、SSD、SSDジャーナルを備えたSASドライブ、同軸ジャーナルを備えたSATAドライブなど、複数のクラスのドライブが存在する場合があります。RHCS 2およびそれ以前のリリースで、同じホストに複数のCRUSH階層を作成する場合、その階層では実際のホスト名の代わりに論理ホスト名を使用し、CRUSH階層内でバケット名が一意になるようにする必要があります。たとえば、ホスト名が data2 の場合、CRUSH 階層は、data2-sas-ssddata2-index などの論理名を使用する可能性があります。以下に例を示します。

host data2-sas-ssd {
  id -11   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.0 weight 1.000
  item osd.1 weight 1.000
  item osd.2 weight 1.000
  item osd.3 weight 1.000
}

前述の例では、ホスト data2 は論理名 data2-sas-ssd を使用して、SSD にジャーナルのある SAS ドライブを 1 つの階層にマッピングします。上記の例の osd.0 から osd.3 の OSD ID は、高スループットのハードウェア構成で SSD ジャーナルを使用する SAS ドライブを表しています。これらのOSD IDは、以下の例のOSD IDとは異なります。

以下の例では、ホスト data2 は論理名 data2-index を使用してバケットインデックスの SSD ドライブを 2 つ目の階層にマッピングします。以下の例の OSD ID の osd.4 は、バケットインデックスプール専用に使用される SSD ドライブまたはその他の高速ストレージメディアを示しています。

host data2-index {
  id -21   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.4 weight 1.000
}
重要

論理的なホスト名を使用する場合、OSD起動スクリプトが起動時に実際のホスト名を使用してCRUSHマップ内のデータを見つけられなくなるのを防ぐために、Ceph構成ファイルに以下の設定のいずれかが存在することを確認してください。

前述の例のようにCRUSHマップが論理的なホスト名を使用している場合、初期化時にOSDの起動スクリプトが実際のホスト名に基づいてホストを識別しないようにします。Ceph 設定ファイルの [global] セクションに、以下の設定を追加します。

osd_crush_update_on_start = false

論理ホスト名を定義する別の方法は、Ceph 設定ファイルの [osd.<ID>] セクションで各 OSD の CRUSH マップの場所を定義することです。これにより、OSD起動スクリプトが定義した場所が上書きされます。前述の例から、エントリーは以下のようになります。

[osd.0]
osd crush location = "host=data2-sas-ssd"

[osd.1]
osd crush location = "host=data2-sas-ssd"

[osd.2]
osd crush location = "host=data2-sas-ssd"

[osd.3]
osd crush location = "host=data2-sas-ssd"

[osd.4]
osd crush location = "host=data2-index"
重要

CRUSHマップが実際のホスト名ではなく論理的なホスト名を使用している場合に前述のいずれかの方法を使用しないと、再起動時にCeph Storage ClusterはOSDが実際のホスト名にマッピングされていると判断し、実際のホスト名はCRUSHマップで見つからず、Ceph Storage ClusterクライアントはOSDとそのデータを見つけることができません。

7.1.3. CRUSH ルールの作成

デフォルトのCRUSH階層と同様に、CRUSHマップにもデフォルトのCRUSHルールが含まれています。

注記

デフォルトの rbd プールはこのルールを使用できます。他のプールが顧客データの保存にデフォルトルールを使用している場合は、削除しないでください。

CRUSH ルールの一般的な詳細は、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドの「CRUSH ルール」セクションを参照してください。CRUSH マップを手動で編集するには、Red Hat Ceph Storage 4 の『ストレージストラテジー』ガイドの「CRUSH マップ」セクションを参照してください。

CRUSH階層ごとに、CRUSHルールを作成します。以下の例は、.rgw.root を含むサービスプールを保存する CRUSH 階層のルールを示しています。この例では、ルート sas-ssd がメインの CRUSH 階層として機能します。デフォルトのルールと区別するために、rgw-service という名前を使用します。step take sas-ssd 行は、「CRUSH ルートの作成」で作成された sas-ssd ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア構成のジャーナルに対して SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaftype rack 部分が障害ドメインになります。次の例では、それはラックです。

##
# SERVICE RULE DECLARATION
##

rule rgw-service {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type rack
 step emit
}
注記

前述の例では、データが3回複製される場合、同数のOSDノードを搭載したラックがクラスタ内に少なくとも3つ存在する必要があります。

ヒント

type replicated 設定は、データ永続性、レプリカ数、またはイレイジャーコーディングとは 関係ありません複製 のみがサポートされます。

次の例は、データプールを保存するCRUSH階層のルールを示しています。この例では、ルートのsas-ssdがメインのCRUSH階層(サービスルールと同じCRUSH階層)として機能しています。rgw-throughput を使用して、デフォルトのルールと rgw-service と区別します。step take sas-ssd 行は、「CRUSH ルートの作成」で作成された sas-ssd ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア構成の SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaftype host 部分障害ドメインになります。次の例では、それはホストです。このルールでは、同じCRUSH階層を使用していますが、異なる障害ドメインを使用していることに注意してください。

##
# THROUGHPUT RULE DECLARATION
##

rule rgw-throughput {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type host
 step emit
}
注記

前述の例では、プールがデフォルトよりも多い数のデータおよびエンコーディング チャンクで消去コーディングを使用する場合、消去コーディング チャンクを容易にするために、同数のOSDノードを含むクラスタ内のラックを少なくとも同数用意する必要があります。小規模なクラスターの場合、これは実用的ではない可能性があるため、前述の例では host を CRUSH 障害ドメインとして使用します。

次の例は、インデックスプールを保存するCRUSH階層のルールを示しています。この例では、root の index は主な CRUSH 階層として機能します。rgw-index を使用して、rgw-servicergw-throughput と区別します。step take index 行は、「CRUSH ルートの作成」で作成された index root を使用するようにプールに指示します。その子バケットには、SSD ドライブ、NVMe ドライブなどの高性能ストレージメディア、またはOSD ジャーナルも格納する SSD ドライブまたは NVMe ドライブ上のパーティションが含まれます。step chooseleaftype rack 部分が障害ドメインになります。次の例では、それはラックです。

##
# INDEX RULE DECLARATION
##

rule rgw-index {
 type replicated
 min_size 1
 max_size 10
 step take index
 step chooseleaf firstn 0 type rack
 step emit
}