第4章 Ceph Storage のストレッチクラスター
ストレージ管理者は、2 サイトクラスターでストレッチモードを開始することにより、ストレッチクラスターを設定できます。
Red Hat Ceph Storage は、CRUSH マップ全体にランダムに分散された障害に対して同等に信頼できるネットワークとクラスターにより、Ceph OSD の損失に耐えることができます。多くの OSD がシャットダウンされても、残りの OSD とモニターは引き続き動作します。
ただし、これは、Ceph クラスターの大部分が 1 つのネットワークコンポーネントしか使用できない一部のストレッチクラスター設定では最適なソリューションではない可能性があります。この例は、複数のデータセンターに配置された 1 つのクラスターについて、ユーザーがデータセンター全体の損失に耐えたいと考えている場合です。
標準設定は 2 つのデータセンターです。その他の設定は、クラウドまたは可用性ゾーンにあります。各サイトはデータのコピーを 2 つ保持するため、レプリケーションサイズは 4 です。3 番目のサイトには、タイブレーカーモニターが必要です。これは、メインサイトと比較して、仮想マシンまたは高レイテンシーである可能性があります。このモニターは、ネットワーク接続に障害が発生し、両方のデータセンターがアクティブなままである場合、データを復元するサイトの 1 つを選択します。
標準の Ceph 設定は、ネットワークまたはデータセンターの多くの障害に耐え、データの一貫性を損なうことはありません。障害後に十分な数の Ceph サーバーを復元すると、回復します。Ceph は、データセンターを失った場合も、可用性を維持しますが、モニターの定足数を形成し、プールの min_size
を満たすために十分なコピー、またはサイズを満たすために再度複製する CRUSH ルールで、すべてのデータを利用可能にすることができます。
ストレッチクラスターの電源を切るために追加の手順はありません。詳細は、Red Hat Ceph Storage クラスターの電源切断と再起動 を参照してください。
ストレッチクラスターの障害
Red Hat Ceph Storage は、データの整合性と一貫性について決して妥協しません。ネットワーク障害またはノードの損失があり、サービスを復元できる場合、Ceph は単独で通常の機能に戻ります。
ただし、Ceph の一貫性とサイジングの制約を満たすために十分な数のサーバーを使用できる場合も、データの可用性が失われる状況や、予想外に制約を満たさない状況があります。
最初の重要なタイプの障害は、一貫性のないネットワークによって引き起こされます。ネットワークが分割されている場合は、プライマリー OSD がデータをレプリケーションできないにもかかわらず、Ceph が OSD を down
とマークして、代理配置グループ (PG) セットから削除できない場合があります。これが発生すると、Ceph が耐久性の保証を満たすことができないため、I/O は許可されません。
失敗の 2 番目の重要なカテゴリーは、データ入力間でデータがレプリケーションされているように見えるが、制約がこれを保証するには不十分な場合です。たとえば、データセンター A と B があり、CRUSH ルールは 3 つのコピーを対象とし、min_size
が 2
の各データセンターにコピーを配置するとします。PG は、サイト A に 2 つのコピーがあり、サイト B にコピーがない状態でアクティブになる場合があります。つまり、サイト A を失うと、データが失われ、Ceph は、そのデータを操作できなくなります。この状況は、標準の CRUSH ルールでは、回避が困難です。
4.1. ストレージクラスターのストレッチモード
ストレッチクラスターを設定するには、ストレッチモードに入る必要があります。ストレッチモードが有効になっている場合、Ceph OSD は、PG がデータセンター間でピア接続している場合、または指定した他の CRUSH バケットタイプが両方ともアクティブであると仮定して、PG のみをアクティブと見なします。プールのサイズはデフォルトの 3 から 4 に増加し、各サイトに 2 つのコピーがあります。
ストレッチモードでは、Ceph OSD は同じデータセンター内のモニターのみに接続できます。新しいモニターは、場所を指定しないと、クラスターに参加できません。
データセンターのすべての OSD とモニターが一度にアクセスできなくなった場合、存続しているデータセンターは degraded
ストレッチモードに入ります。これにより、警告が発行され、min_size
が 1
に減少し、クラスターが残りのサイトからのデータで active
状態に到達できるようになります。
プールサイズが変更されないため、degraded
状態でも、プールが小さすぎるという警告がトリガーされます。ただし、特別なストレッチモードフラグにより、OSD が残りのデータセンターに余分なコピーを作成することが防止されるため、2 つのコピーが保持されます。
欠落しているデータセンターが再びアクセス可能になると、クラスターは recovery
ストレッチモードに入ります。これにより、警告が変更され、ピアリングが許可されますが、必要なものは、データセンターからの OSD のみであり、ずっと稼働していました。
すべての PG が既知の状態にあり、劣化でも不完全でもない場合、クラスターは通常のストレッチモードに戻り、警告を終了し、min_size
を開始値 2
に戻します。クラスターは、常に稼働していたサイトだけでなく、両方のサイトをピアリングする必要があるため、必要に応じて、他のサイトにフェイルオーバーできます。
ストレッチモードの制限
- 一度ストレッチモードに入ると、解除できません。
- ストレッチモードのクラスターでイレイジャーコーディングされたプールを使用することはできません。イレイジャーコーディングされたプールでストレッチモードに入ることも、ストレッチモードがアクティブな場合にイレイジャーコーディングされたプールを作成することもできません。
- 2 サイト以下のストレッチモードがサポートされています。
2 つのサイトの重みは同じである必要があります。そうでない場合は、次のエラーが表示されます。
例
[ceph: root@host01 /]# ceph mon enable_stretch_mode host05 stretch_rule datacenter Error EINVAL: the 2 datacenter instances in the cluster have differing weights 25947 and 15728 but stretch mode currently requires they be the same!
両方のサイトで同じ重みを実現するには、2 つのサイトにデプロイされた Ceph OSD のサイズが同じである必要があります。つまり、最初のサイトのストレージ容量は 2 番目のサイトのストレージ容量と同じです。
- 強制ではありませんが、各サイトで 2 つの Ceph モニターを実行し、タイブレーカーを 1 つ、合計 5 つ実行する必要があります。これは、ストレッチモードの場合、OSD が自分のサイトのモニターにしか接続できないためです。
- 独自の CRUSH ルールを作成する必要があります。これにより、各サイトに 2 つのコピーが提供され、両方のサイトで合計 4 つになります。
-
デフォルト以外のサイズまたは
min_size
の既存のプールがある場合は、ストレッチモードを有効にすることはできません。 -
クラスターは劣化時に
min_size 1
で実行されるため、オールフラッシュ OSD ではストレッチモードのみを使用する必要があります。これにより、接続が復元された後の回復に必要な時間が最小限に抑えられ、データ損失の可能性が最小限に抑えられます。
関連情報
- トラブルシューティングの手順は、ストレッチモードでのクラスターのトラブルシューティング を参照してください。
4.1.1. CRUSH の場所をデーモンに設定する
ストレッチモードに入る前に、CRUSH の場所を Red Hat Ceph Storage クラスターのデーモンに設定して、クラスターを準備する必要があります。これには 2 つの方法があります。
- サービス設定ファイルを介してクラスターをブートストラップします。このファイルでは、配置の一部として場所がホストに追加されます。
-
クラスターがデプロイされた後、
ceph osd crush add-bucket
およびceph osd crush move
コマンドを使用して、場所を手動で設定します。
方法 1: クラスターのブートストラップ
前提条件
- ノードへの root レベルのアクセス。
手順
新しいストレージクラスターをブートストラップする場合は、ノードを Red Hat Ceph Storage クラスターに追加し、サービスを実行する場所に特定のラベルを設定するサービス設定
.yaml
ファイルを作成できます。例
service_type: host addr: host01 hostname: host01 location: root: default datacenter: DC1 labels: - osd - mon - mgr --- service_type: host addr: host02 hostname: host02 location: datacenter: DC1 labels: - osd - mon --- service_type: host addr: host03 hostname: host03 location: datacenter: DC1 labels: - osd - mds - rgw --- service_type: host addr: host04 hostname: host04 location: root: default datacenter: DC2 labels: - osd - mon - mgr --- service_type: host addr: host05 hostname: host05 location: datacenter: DC2 labels: - osd - mon --- service_type: host addr: host06 hostname: host06 location: datacenter: DC2 labels: - osd - mds - rgw --- service_type: host addr: host07 hostname: host07 labels: - mon --- service_type: mon placement: label: "mon" --- service_id: cephfs placement: label: "mds" --- service_type: mgr service_name: mgr placement: label: "mgr" --- service_type: osd service_id: all-available-devices service_name: osd.all-available-devices placement: label: "osd" spec: data_devices: all: true --- service_type: rgw service_id: objectgw service_name: rgw.objectgw placement: count: 2 label: "rgw" spec: rgw_frontend_port: 8080
--apply-spec
オプションを使用してストレージクラスターをブートストラップします。構文
cephadm bootstrap --apply-spec CONFIGURATION_FILE_NAME --mon-ip MONITOR_IP_ADDRESS --ssh-private-key PRIVATE_KEY --ssh-public-key PUBLIC_KEY --registry-url REGISTRY_URL --registry-username USER_NAME --registry-password PASSWORD
例
[root@host01 ~]# cephadm bootstrap --apply-spec initial-config.yaml --mon-ip 10.10.128.68 --ssh-private-key /home/ceph/.ssh/id_rsa --ssh-public-key /home/ceph/.ssh/id_rsa.pub --registry-url registry.redhat.io --registry-username myuser1 --registry-password mypassword1
重要cephadm bootstrap
コマンドでは、さまざまなコマンドオプションを使用できます。ただし、サービス設定ファイルを使用して、ホストの場所を設定するには、--apply-spec
オプションを常に含めてください。
関連情報
-
Ceph ブートストラップおよびさまざまな
cephadm bootstrap
コマンドオプションの詳細は、新しいストレージクラスターのブートストラップ を参照してください。
方法 2: デプロイメント後に場所を設定する
前提条件
- ノードへの root レベルのアクセス。
手順
非タイブレーカーモニターの場所を設定する予定の 2 つのバケットを CRUSH マップに追加し、バケットタイプを
datacenter
として指定します。構文
ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE
例
[ceph: root@host01 /]# ceph osd crush add-bucket DC1 datacenter [ceph: root@host01 /]# ceph osd crush add-bucket DC2 datacenter
root=default
の下にバケットを移動します。構文
ceph osd crush move BUCKET_NAME root=default
例
[ceph: root@host01 /]# ceph osd crush move DC1 root=default [ceph: root@host01 /]# ceph osd crush move DC2 root=default
必要な CRUSH 配置に従って、OSD ホストを移動します。
構文
ceph osd crush move HOST datacenter=DATACENTER
例
[ceph: root@host01 /]# ceph osd crush move host01 datacenter=DC1
4.1.2. ストレッチモードに入る
新しいストレッチモードは、2 つのサイトを処理するように、設計されています。2 サイトクラスターでは、コンポーネントの可用性が失われるリスクが低くなります。
前提条件
- ノードへの root レベルのアクセス。
- CRUSH の場所はホストに設定されます。
手順
CRUSH マップに合わせて、各モニターの位置を設定します。
構文
ceph mon set_location HOST datacenter=DATACENTER
例
[ceph: root@host01 /]# ceph mon set_location host01 datacenter=DC1 [ceph: root@host01 /]# ceph mon set_location host02 datacenter=DC1 [ceph: root@host01 /]# ceph mon set_location host04 datacenter=DC2 [ceph: root@host01 /]# ceph mon set_location host05 datacenter=DC2 [ceph: root@host01 /]# ceph mon set_location host07 datacenter=DC3
各データセンターに 2 つのコピーを配置する CRUSH ルールを生成します。
構文
ceph osd getcrushmap > COMPILED_CRUSHMAP_FILENAME crushtool -d COMPILED_CRUSHMAP_FILENAME -o DECOMPILED_CRUSHMAP_FILENAME
例
[ceph: root@host01 /]# ceph osd getcrushmap > crush.map.bin [ceph: root@host01 /]# crushtool -d crush.map.bin -o crush.map.txt
逆コンパイルされた CRUSH マップファイルを編集して、新しいルールを追加します。
例
rule stretch_rule { id 1 1 type replicated min_size 1 max_size 10 step take DC1 2 step chooseleaf firstn 2 type host step emit step take DC2 3 step chooseleaf firstn 2 type host step emit }
注記このルールにより、クラスターはデータセンター
DC1
に対して読み取りアフィニティーを持ちます。したがって、すべての読み取りまたは書き込みは、DC1
に配置された Ceph OSD を介して行われます。これが望ましくなく、読み取りまたは書き込みがゾーン全体に均等に分散される場合、CRUSH ルールは次のようになります。
例
rule stretch_rule { id 1 type replicated min_size 1 max_size 10 step take default step choose firstn 0 type datacenter step chooseleaf firstn 2 type host step emit }
このルールでは、データセンターはランダムかつ自動的に選択されます。
firstn
およびindep
オプションの詳細は、CRUSH ルール を参照してください。
CRUSH マップを挿入して、クラスターでルールを使用できるようにします。
構文
crushtool -c DECOMPILED_CRUSHMAP_FILENAME -o COMPILED_CRUSHMAP_FILENAME ceph osd setcrushmap -i COMPILED_CRUSHMAP_FILENAME
例
[ceph: root@host01 /]# crushtool -c crush.map.txt -o crush2.map.bin [ceph: root@host01 /]# ceph osd setcrushmap -i crush2.map.bin
接続モードでモニターを実行しない場合は、選択戦略を
connectivity
に設定します。例
[ceph: root@host01 /]# ceph mon set election_strategy connectivity
タイブレーカーモニターの場所をデータセンター間で分割するように設定して、ストレッチモードに入ります。
構文
ceph mon set_location HOST datacenter=DATACENTER ceph mon enable_stretch_mode HOST stretch_rule datacenter
例
[ceph: root@host01 /]# ceph mon set_location host07 datacenter=DC3 [ceph: root@host01 /]# ceph mon enable_stretch_mode host07 stretch_rule datacenter
この例では、モニター
mon.host07
がタイブレーカーです。重要タイブレーカーモニターの場所は、以前に非タイブレーカーモニターを設定したデータセンターとは異なる必要があります。上記の例では、データセンター
DC3
です。重要ストレッチモードに入ろうとすると、次のエラーが発生するため、このデータセンターを CRUSH マップに追加しないでください。
Error EINVAL: there are 3 datacenters in the cluster but stretch mode currently only works with 2!
注記Ceph をデプロイするための独自のツールを作成している場合、
ceph mon set_location
コマンドを実行する代わりに、モニターの起動時に新しい--set-crush-location
オプションを使用できます。このオプションは、ceph-mon --set-crush-location 'datacenter=DC1'
など、1 つのbucket=location
ペアのみを受け入れます。これは、enable_stretch_mode
コマンドの実行時に指定したバケットタイプに一致する必要があります。ストレッチモードが正常に有効になっていることを確認します。
例
[ceph: root@host01 /]# ceph osd dump epoch 361 fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d created 2023-01-16T05:47:28.482717+0000 modified 2023-01-17T17:36:50.066183+0000 flags sortbitwise,recovery_deletes,purged_snapdirs,pglog_hardlimit crush_version 31 full_ratio 0.95 backfillfull_ratio 0.92 nearfull_ratio 0.85 require_min_compat_client luminous min_compat_client luminous require_osd_release quincy stretch_mode_enabled true stretch_bucket_count 2 degraded_stretch_mode 0 recovering_stretch_mode 0 stretch_mode_bucket 8
Stretch_mode_enabled
はtrue
に設定する必要があります。また、ストレッチバケット、ストレッチモードバケットの数、およびストレッチモードが低下しているか回復しているかを確認することもできます。モニターが適切な場所にあることを確認します。
例
[ceph: root@host01 /]# ceph mon dump epoch 19 fsid 1234ab78-1234-11ed-b1b1-de456ef0a89d last_changed 2023-01-17T04:12:05.709475+0000 created 2023-01-16T05:47:25.631684+0000 min_mon_release 16 (pacific) election_strategy: 3 stretch_mode_enabled 1 tiebreaker_mon host07 disallowed_leaders host07 0: [v2:132.224.169.63:3300/0,v1:132.224.169.63:6789/0] mon.host07; crush_location {datacenter=DC3} 1: [v2:220.141.179.34:3300/0,v1:220.141.179.34:6789/0] mon.host04; crush_location {datacenter=DC2} 2: [v2:40.90.220.224:3300/0,v1:40.90.220.224:6789/0] mon.host01; crush_location {datacenter=DC1} 3: [v2:60.140.141.144:3300/0,v1:60.140.141.144:6789/0] mon.host02; crush_location {datacenter=DC1} 4: [v2:186.184.61.92:3300/0,v1:186.184.61.92:6789/0] mon.host05; crush_location {datacenter=DC2} dumped monmap epoch 19
また、どのモニターがタイブレーカーであるか、およびモニターの選択戦略も確認できます。
関連情報
- モニターの選択戦略の詳細は、モニターの選択戦略の設定 を参照してください。
4.1.3. ストレッチモードでの OSD ホストの追加
ストレッチモードで Ceph OSD を追加できます。この手順は、ストレッチモードが有効になっていないクラスターに OSD ホストを追加する場合に類似しています。
前提条件
- 稼働中の Red Hat Ceph Storage クラスターがある。
- クラスターでストレッチモードが有効になっている。
- ノードへの root レベルのアクセス。
手順
OSD をデプロイするために利用可能なデバイスをリスト表示します。
構文
ceph orch device ls [--hostname=HOST_1 HOST_2] [--wide] [--refresh]
例
[ceph: root@host01 /]# ceph orch device ls
OSD を特定のホストまたは使用可能なすべてのデバイスにデプロイします。
特定のホスト上の特定のデバイスから OSD を作成します。
構文
ceph orch daemon add osd HOST:DEVICE_PATH
例
[ceph: root@host01 /]# ceph orch daemon add osd host03:/dev/sdb
使用可能なデバイスと未使用のデバイスに OSD をデプロイします。
重要このコマンドは、コロケーションされた WAL および DB デバイスを作成します。コロケーションされていないデバイスを作成する場合は、このコマンドを使用しないでください。
例
[ceph: root@host01 /]# ceph orch apply osd --all-available-devices
OSD ホストを CRUSH バケットの下に移動します。
構文
ceph osd crush move HOST datacenter=DATACENTER
例
[ceph: root@host01 /]# ceph osd crush move host03 datacenter=DC1 [ceph: root@host01 /]# ceph osd crush move host06 datacenter=DC2
注記両方のサイトに同じトポロジーノードを追加してください。ホストが 1 つのサイトのみに追加されると、問題が発生する可能性があります。
関連情報
- Ceph OSD の追加の詳細は、OSD の追加 を参照してください。