第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_size2 の各データセンターにコピーを配置するとします。PG は、サイト A に 2 つのコピーがあり、サイト B にコピーがない状態でアクティブになる場合があります。つまり、サイト A を失うと、データが失われ、Ceph は、そのデータを操作できなくなります。この状況は、標準の CRUSH ルールでは、回避が困難です。

4.1. ストレージクラスターのストレッチモード

ストレッチクラスターを設定するには、ストレッチモードに入る必要があります。ストレッチモードが有効になっている場合、Ceph OSD は、PG がデータセンター間でピア接続している場合、または指定した他の CRUSH バケットタイプが両方ともアクティブであると仮定して、PG のみをアクティブと見なします。プールのサイズはデフォルトの 3 から 4 に増加し、各サイトに 2 つのコピーがあります。

ストレッチモードでは、Ceph OSD は同じデータセンター内のモニターのみに接続できます。新しいモニターは、場所を指定しないと、クラスターに参加できません。

データセンターのすべての OSD とモニターが一度にアクセスできなくなった場合、存続しているデータセンターは degraded ストレッチモードに入ります。これにより、警告が発行され、min_size1 に減少し、クラスターが残りのサイトからのデータで 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 レベルのアクセス。

手順

  1. 新しいストレージクラスターをブートストラップする場合は、ノードを 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

  2. --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 オプションを常に含めてください。

関連情報

方法 2: デプロイメント後に場所を設定する

前提条件

  • ノードへの root レベルのアクセス。

手順

  1. 非タイブレーカーモニターの場所を設定する予定の 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

  2. 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

  3. 必要な 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 の場所はホストに設定されます。

手順

  1. 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. 各データセンターに 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

    1. 逆コンパイルされた 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
      }

      1
      ルール id は一意である必要があります。この例では、ID 0 のルールがもう 1 つしかないため、ID 1 が使用されますが、既存のルールの数に応じて、別のルール ID を使用する必要がある場合があります。
      2 3
      この例では、DC1 および DC2 という名前の 2 つのデータセンターバケットがあります。
      注記

      このルールにより、クラスターはデータセンター 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 ルール を参照してください。

  3. 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

  4. 接続モードでモニターを実行しない場合は、選択戦略を connectivity に設定します。

    [ceph: root@host01 /]# ceph mon set election_strategy connectivity

  5. タイブレーカーモニターの場所をデータセンター間で分割するように設定して、ストレッチモードに入ります。

    構文

    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 コマンドの実行時に指定したバケットタイプに一致する必要があります。

  6. ストレッチモードが正常に有効になっていることを確認します。

    [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_enabledtrue に設定する必要があります。また、ストレッチバケット、ストレッチモードバケットの数、およびストレッチモードが低下しているか回復しているかを確認することもできます。

  7. モニターが適切な場所にあることを確認します。

    [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 レベルのアクセス。

手順

  1. OSD をデプロイするために利用可能なデバイスをリスト表示します。

    構文

    ceph orch device ls [--hostname=HOST_1 HOST_2] [--wide] [--refresh]

    [ceph: root@host01 /]# ceph orch device ls

  2. 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

  3. 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 の追加 を参照してください。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.