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

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

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

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

以下の例では、data0、data1、および data2 という名前のホストは、同じ物理ホストを参照する CRUSH の階層が複数存在するため、data0-sas-ssd、data0-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 ドライブなどの高パフォーマンスメディアを表す はずです。OSD ジャーナルを格納する SSD または NVMe メディアにパーティションを作成することを検討してください。以下に例を示します。

##
# 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
}

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

CRUSH マップでは、ホスト名は一意で、1 回のみ使用する必要があります。ホストが複数の CRUSH 階層とユースケースに対応する場合、CRUSH マップは実際のホスト名の代わりに論理ホスト名を使用して、ホスト名が一度だけ使用されるようにします。たとえば、ノードには、SSD などの複数のドライブ、SSD ジャーナルを備えた SAS ドライブ、および同一ジャーナルを持つ SATA ドライブが複数ある場合があります。RHCS 2 以前のリリースでは、同じホストに複数の CRUSH 階層を作成するには、階層は実際のホスト名の代わりに論理ホスト名を使用する必要があります。そのため、バケット名は CRUSH 階層内で一意となるようにします。たとえば、ホスト名が data2 の場合、CRUSH 階層は、data2-sas-ssd、data2-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
}

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 階層と同様に、CRUSH マップにはデフォルトの CRUSH ルールも含まれます。

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 chooseleaf の type 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
}

以下の例は、データプールを保存する CRUSH 階層のルールを示しています。この例では、root sas-ssd は、サービスルールと同じ CRUSH 階層としてメインの CRUSH 階層として機能します。rgw-throughput を使用して、デフォルトのルールと rgw-service と区別します。step take sas-ssd 行は、「CRUSH ルートの作成」で作成された sas-ssd ルートを使用するようにプールに指示します。このルートの子バケットには、SAS ドライブを備えた OSD と、高スループットハードウェア構成の SSD または NVMe ドライブなどの高性能ストレージメディアが含まれます。step chooseleaf の type 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
}

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