第5章 Ceph Storage クラスターのカスタマイズ

director は、デフォルト設定を使用してコンテナー化された Red Hat Ceph Storage をデプロイします。Ceph Storage をカスタマイズするには、デフォルト設定を上書きします。

前提条件

コンテナー化された Ceph Storage をデプロイするには、オーバークラウドのデプロイメント時に /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml ファイルを追加します。この環境ファイルは、以下のリソースを定義します。

  • CephAnsibleDisksConfig: このリソースは Ceph Storage ノードのディスクレイアウトをマッピングします。詳細は、「Ceph Storage ノードのディスクレイアウトのマッピング」を参照してください。
  • CephConfigOverrides: このリソースは、その他のすべてのカスタム設定を Ceph Storage クラスターに適用します。

これらのリソースを使用して、director がコンテナー化された Ceph Storage に設定するすべてのデフォルトを上書きします。

手順

  1. Red Hat Ceph Storage 4 Tools リポジトリーを有効にします。

    $ sudo subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms
  2. ceph-ansible パッケージをアンダークラウドにインストールします。

    $ sudo dnf install ceph-ansible
  3. Ceph Storage クラスターをカスタマイズするには、新しい環境ファイル (/home/stack/templates/ceph-config.yaml など) でカスタムのパラメーターを定義します。お使いの環境ファイルの parameter_defaults セクションで以下の構文を使用して、Ceph Storage クラスターの設定を適用することができます。

    parameter_defaults:
      CephConfigOverrides:
        section:
          KEY:VALUE
    注記

    CephConfigOverrides パラメーターは、ceph.conf ファイルの [global] セクションのほか、[osd][mon]、および [client] などの他のセクションにも適用できます。セクションを指定すると、key:value データは指定されたセクションに送信されます。セクションを指定しないと、データはデフォルトで [global] セクションに送信されます。Ceph Storage の設定、カスタマイズ、およびサポートされるパラメーターに関する詳細は、『Red Hat Ceph Storage 設定ガイド』を参照してください。

  4. KEY および VALUE を適用する Ceph クラスター設定に置き換えてください。たとえば、global セクションでは max_open_filesKEY で、131072 が対応する VALUE になります。

    parameter_defaults:
      CephConfigOverrides:
        global:
          max_open_files: 131072
        osd:
          osd_scrub_during_recovery: false

    この設定は、Ceph クラスターの設定ファイルで定義された以下のような設定となります。

    [global]
    max_open_files = 131072
    [osd]
    osd_scrub_during_recovery = false

5.1. ceph-ansible グループ変数の設定

ceph-ansible ツールは、Ceph Storage クラスターをインストールおよび管理するために使用される Playbook です。

ceph-ansible ツールには group_vars ディレクトリーがあり、設定オプションとこれらのオプションのデフォルト設定を定義します。group_vars ディレクトリーを使用して Ceph Storage パラメーターを設定します。

group_vars ディレクトリーの詳細は、『Red Hat Ceph Storage インストールガイド』「Red Hat Ceph Storage クラスターのインストール」を参照してください。

director の変数デフォルトを変更するには、CephAnsibleExtraConfig パラメーターを使用して heat 環境ファイルの新しい値を渡します。たとえば、ceph-ansible のグループ変数 journal_size を 40960 に設定するには、journal_size を以下のように定義した環境ファイルを作成します。

parameter_defaults:
  CephAnsibleExtraConfig:
    journal_size: 40960
重要

ceph-ansible のグループ変数を変更するには、オーバーライドパラメーターを使用します。アンダークラウドの /usr/share/ceph-ansible ディレクトリーのグループ変数を直接編集しないでください。

5.2. Ceph Storage を使用する Red Hat OpenStack Platform 向けの Ceph コンテナー

OpenStack Platform が Ceph を使用するように設定するには、Ceph コンテナーが必要です。これは、外部の Ceph クラスターの場合でも同じです。Red Hat Enterprise Linux 8 と互換性を持たせるには、Red Hat OpenStack Platform (RHOSP) 15 には Red Hat Ceph Storage 4 が必要です。Ceph Storage 4 コンテナーは、registry.redhat.io (認証が必要なレジストリー) でホストされます。

heat 環境パラメーター ContainerImageRegistryCredentials を使用して registry.redhat.io で認証することができます。詳細は、「コンテナーイメージ準備のパラメーター」を参照してください。

5.3. Ceph Storage ノードのディスクレイアウトのマッピング

コンテナー化された Ceph Storage をデプロイする場合には、ディスクレイアウトをマッピングし、Ceph OSD サービス用に専用のブロックデバイスを指定する必要があります。カスタム Ceph パラメーターを定義するために作成した環境ファイル (/home/stack/templates/ceph-config.yaml) で、このマッピングを行うことができます。

parameter_defaultsCephAnsibleDisksConfig リソースを使用して、ディスクレイアウトをマッピングします。このリソースでは、以下の変数が使用されます。

変数必須/オプションデフォルト値 (未設定の場合)説明

osd_scenario

必須

lvm

注記: デフォルト値は lvm です。

lvm の値により、ceph-ansible は ceph-volume を使用して OSD および BlueStore WAL デバイスを設定することができます。

devices

必須

なし。変数を設定する必要があります。

ノード上の OSD に使用するブロックデバイスの一覧。

dedicated_devices

必須 (ただし osd_scenarionon-collocated の場合のみ)

devices

devices パラメーターの各エントリーを専用のジャーナル用ブロックデバイスにマッピングするブロックデバイスの一覧。この変数は、osd_scenario=non-collocated の場合にのみ使用できます。

dmcrypt

オプション

false

OSD に保存されるデータが暗号化されているか (true)、暗号化されていないか (false) を設定します。

osd_objectstore

オプション

bluestore

注記: デフォルト値は bluestore です。

Ceph の使用するストレージバックエンドを設定します。

5.3.1. BlueStore の使用

手順

  1. Ceph OSD として使用するブロックデバイスを指定するには、以下のスニペットのバリエーションを使用します。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
          - /dev/nvme0n1
        osd_scenario: lvm
        osd_objectstore: bluestore
  2. /dev/nvme0n1 は高パフォーマンスのデバイスクラスであるため、例に示すパラメーターのデフォルトでは、/dev/sdb/dev/sdc、および /dev/sdd 上で動作する 3 つの OSD が作成されます。この 3 つの OSD は、BlueStore WAL デバイスに /dev/nvme0n1 を使用します。ceph-volume ツールは、batch サブコマンドを使用してこれを実施します。Ceph Storage ノードごとに同じ設定が複製され、ハードウェアが統一されていることを前提とします。BlueStore WAL データが OSD と同じディスクに存在する場合は、以下に示すようにパラメーターのデフォルトを変更します。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
          - /dev/sdb
          - /dev/sdc
          - /dev/sdd
        osd_scenario: lvm
        osd_objectstore: bluestore

5.3.2. 永続デバイス名が付いたデバイスの参照

手順

  1. 一部のノードでは、/dev/sdb および /dev/sdc 等のディスクパスが、リブート中に同じブロックデバイスをポイントしない場合があります。このようなケースが CephStorage ノードで見られる場合は、各ディスクに /dev/disk/by-path/ シンボリックリンクを指定して、ブロックデバイスのマッピングがデプロイメント全体で一貫性を保つようにします。

    parameter_defaults:
      CephAnsibleDisksConfig:
        devices:
    
          - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:10:0
          - /dev/disk/by-path/pci-0000:03:00.0-scsi-0:0:11:0
    
    
        dedicated_devices:
          - /dev/nvme0n1
          - /dev/nvme0n1
  2. (オプション) オーバークラウドのデプロイメント前に OSD デバイスの一覧を設定しなければならないので、ディスクデバイスの PCI パスを把握/設定できない場合があります。このような場合には、イントロスペクション中にブロックデバイスの /dev/disk/by-path/symlink データを収集します。

    以下の例の最初のコマンドを実行して、サーバー b08-h03-r620-hci のアンダークラウド Object Storage サービス (swift) からイントロスペクションデータをダウンロードし、そのデータを b08-h03-r620-hci.json と呼ばれるファイルに保存します。2 番目のコマンドを実行して、"by-path" を grep します。このコマンドの出力には、ディスクの特定に使用できる一意の /dev/disk/by-path 値が含まれます。

    (undercloud) [stack@b08-h02-r620 ironic]$ openstack baremetal introspection data save b08-h03-r620-hci | jq . > b08-h03-r620-hci.json
    (undercloud) [stack@b08-h02-r620 ironic]$ grep by-path b08-h03-r620-hci.json
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:0:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:1:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:3:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:4:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:5:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:6:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:7:0",
            "by_path": "/dev/disk/by-path/pci-0000:02:00.0-scsi-0:2:0:0",

ストレージデバイスの命名規則の詳細は、『ストレージデバイスの管理』ガイドの「永続的な命名属性の概要」を参照してください。

コンテナー化された Ceph Storage の各ジャーナリングシナリオおよびディスクのマッピングに関する詳細は、ceph-ansible のプロジェクトドキュメント「OSD Scenario」を参照してください。

5.4. 異なる Ceph プールへのカスタムの属性の割り当て

デフォルトでは、director で作成した Ceph Storage プールには、同じ配置グループの数 (pg_num および pgp_num) とサイズが設定されます。「5章Ceph Storage クラスターのカスタマイズ」に記載のいずれかの方法を使用して、これらの設定をグローバルに上書きすることが可能です。これを行うと、すべてのプールに同じ値が適用されます。

CephPools パラメーターを使用して各 Ceph Storage プールに異なる属性を適用するか、または新しいカスタムプールを作成します。

手順

  1. POOL を、設定するプールの名前に置き換えます。

    parameter_defaults:
      CephPools:
        - name: POOL
  2. 以下のいずれかを実行して配置グループを設定します。

    • デフォルト設定を手動で上書きするには、pg_num を配置グループの数に設定します。

      parameter_defaults:
        CephPools:
          - name: POOL
            pg_num: 128
            application: rbd
    • あるいは、配置グループを自動的にスケーリングするには、pg_autoscale_modeTrue に設定し、target_size_ratio を予想される Ceph Storage 要件の割合に設定します。

      parameter_defaults:
        CephPools:
          - name: POOL
            pg_autoscale_mode: True
            target_size_ratio: PERCENTAGE
            application: rbd

      PERCENTAGE を小数に置き換えます。たとえば、0.5 は 50 パーセントです。割合の合計は 1.0 または 100 パーセントと同じでなければなりません。

      以下の値は例としてのみ例示します。

      paramter_defaults:
        CephPools:
          - {"name": backups, "target_size_ratio": 0.1, "pg_autoscale_mode": True, "application": rbd}
          - {"name": volumes, "target_size_ratio": 0.5, "pg_autoscale_mode": True, "application": rbd}
          - {"name": vms,     "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}
          - {"name": images,  "target_size_ratio": 0.2, "pg_autoscale_mode": True, "application": rbd}

      詳細は、『Red Hat Ceph Storage インストールガイド』「配置グループ autoscaler」参照してください。

  3. アプリケーション種別を指定します。

    Compute、Block Storage、および Image Storage のアプリケーション種別は、「rbd」です。ただし、プールを使用する対象に応じて、異なるアプリケーション種別を指定できます。

    たとえば、gnocchi メトリックプールのアプリケーション種別は openstack_gnocchi です。詳細は、『Storage Strategies Guide』「Enable Application」を参照してください。

    注記

    CephPools パラメーターを使用しない場合には、director により適切なアプリケーションの種別が自動的に設定されます。ただし、デフォルトのプールの一覧だけが対象です。

  4. オプション: カスタムプールを作成するために custompool というプールを追加し、お使いの環境の要件に固有のパラメーターを設定します。

    parameter_defaults:
      CephPools:
        - name: custompool
          pg_num: 128
          application: rbd
ヒント

一般的な Ceph ユースケースの標準的なプール設定は、Ceph Placement Groups (PGs) per Pool Calculator を参照してください。この計算ツールは通常、Ceph プールを手動で設定するためのコマンドの生成に使用されます。このデプロイメントでは、仕様に基づいて director がプールを設定します。

警告

Red Hat Ceph Storage 3 (Luminous) では、OSD に設定可能な最大 PG 数 (デフォルトは 200) にハード制限が追加されました。このパラメーターは 200 を超える値に上書きしないでください。Ceph PG の数が最大値を超えたことで問題が発生した場合には、mon_max_pg_per_osd ではなく、pg_num をプールごとに調整して問題に対処します。

5.5. 異なる構成の Ceph Storage ノードへのディスクレイアウトのマッピング

重要

非同種の Ceph Storage ノードは、予測不能なパフォーマンス損失のリスクなど、パフォーマンスの問題を引き起こす可能性があります。Red Hat OpenStack Platform 環境では非同種の Ceph Storage ノードを構成できますが、Red Hat は推奨しません。

デフォルトでは、(roles_data.yamlOS::TripleO::Services::CephOSD サービスとして指定される) Ceph OSD をホストするロールのすべてのノード (例: CephStorage または ComputeHCI ノード) で、「Ceph Storage ノードのディスクレイアウトのマッピング」で設定したグローバルの devices および dedicated_devices 一覧が使用されます。この場合、これらすべてのサーバーが同一のハードウェア構成であることを前提としています。これらのサーバーのサブセットが同一のハードウェア構成ではない場合には、director はこれらの各サーバーが異なる devices および dedicated_devices 一覧を持つことを把握する必要があります。このような状況は、ノード固有のディスク構成 と呼ばれます。

ノード固有のディスク構成を director に渡すには、node-spec-overrides.yaml 等の Heat 環境ファイルを openstack overcloud deploy コマンドに渡す必要があります。そして、この環境ファイルの内容で、それぞれのサーバーをマシン固有の UUID およびグローバル変数を上書きするローカル変数の一覧で識別する必要があります。

マシン固有の UUID は、個々のサーバー向けに、または Ironic データベースから抽出することができます。

手順

  1. 個々のサーバーの UUID を把握するには、そのサーバーにログインして以下のコマンドを入力します。

    dmidecode -s system-uuid
  2. Ironic データベースから UUID を抽出するには、アンダークラウドで以下のコマンドを入力します。

    openstack baremetal introspection data save NODE-ID | jq .extra.system.product.uuid
    警告

    アンダークラウドのインストールまたはアップグレードおよびイントロスペクションの前に、undercloud.confinspection_extras = true がない場合には、マシン固有の UUID は Ironic データベースには含まれません。

    重要

    マシン固有の UUID は、Ironic UUID とは異なります。

    有効な node-spec-overrides.yaml ファイルは、以下のようになる可能性があります。

    parameter_defaults:
      NodeDataLookup: {"32E87B4C-C4A7-418E-865B-191684A6883B": {"devices": ["/dev/sdc"]}}
  3. 最初の 2 行以降は、すべて有効な JSON でなければなりません。jq コマンドを使用して、JSON が有効であることを確認できます。

    1. 最初の 2 行 (parameter_defaults: および NodeDataLookup:) を一時的にファイルから削除します。
    2. cat node-spec-overrides.yaml | jq . を実行します。
  4. node-spec-overrides.yaml ファイルが大きくなるにつれ、jq を使用して組み込まれた JSON が有効であることを確認することもできます。たとえば、devices および dedicated_devices の一覧は同じ長さでなければならないので、以下のコマンドを使用して、デプロイメントを開始する前に両者が同じ長さであることを確認します。

    (undercloud) [stack@b08-h02-r620 tht]$ cat node-spec-c05-h17-h21-h25-6048r.yaml | jq '.[] | .devices | length'
    33
    30
    33
    (undercloud) [stack@b08-h02-r620 tht]$ cat node-spec-c05-h17-h21-h25-6048r.yaml | jq '.[] | .dedicated_devices | length'
    33
    30
    33
    (undercloud) [stack@b08-h02-r620 tht]$

    上記の例では、node-spec-c05-h17-h21-h25-6048r.yaml にはラック c05 に 3 つのサーバーがあります。ラック c05 のスロット h17、h21、および h25 にはディスクがありません。より複雑な例が、本セクションの最後に記載されています。

  5. JSON を検証した後に、有効な環境 YAML ファイルとなるように 2 つの行 (parameter_defaults: および NodeDataLookup:) を戻し、-e を使用してこの環境ファイルをデプロイメントに追加します。以下の例では、更新した Heat 環境ファイルは Ceph デプロイメントの NodeDataLookup を使用しています。すべてのサーバーのデバイス一覧は 35 のディスクで構成されていましたが、1 つのサーバーだけ 1 つのディスクがありませんでした。この環境ファイルは、その 1 つのノードについてのみデフォルトのデバイス一覧を上書きし、グローバル一覧の代わりに使用する必要のある 34 のディスクの一覧を提供します。

    parameter_defaults:
      # c05-h01-6048r is missing scsi-0:2:35:0 (00000000-0000-0000-0000-0CC47A6EFD0C)
      NodeDataLookup: {
        "00000000-0000-0000-0000-0CC47A6EFD0C": {
          "devices": [
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:1:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:32:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:2:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:3:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:4:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:5:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:6:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:33:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:7:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:8:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:34:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:9:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:10:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:11:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:12:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:13:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:14:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:15:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:16:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:17:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:18:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:19:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:20:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:21:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:22:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:23:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:24:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:25:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:26:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:27:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:28:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:29:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:30:0",
        "/dev/disk/by-path/pci-0000:03:00.0-scsi-0:2:31:0"
            ],
          "dedicated_devices": [
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:81:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1",
        "/dev/disk/by-path/pci-0000:84:00.0-nvme-1"
            ]
          }
        }

5.6. 大規模 Ceph クラスターでの再開待機時間の延長

デプロイメント時に、OSD やモニターなどの Ceph サービスは再起動され、サービスが再度実行されるまでデプロイメントは続行されません。Ansible は 15 秒間待って (待機) サービスの開始を確認する行為を 5 回繰り返します (リトライ)。サービスが再開されない場合には、オペレーターが操作できるようにデプロイメントは停止します。

Ceph クラスターのサイズによっては、リトライまたは待機の値を増加しなければならない場合があります。これらのパラメーターの正確な名前およびそのデフォルト値は以下のとおりです。

 health_mon_check_retries: 5
 health_mon_check_delay: 15
 health_osd_check_retries: 5
 health_osd_check_delay: 15

手順

  1. CephAnsibleExtraConfig パラメーターを更新して、待機およびリトライのデフォルト値を変更します。

    parameter_defaults:
      CephAnsibleExtraConfig:
        health_osd_check_delay: 40
        health_osd_check_retries: 30
        health_mon_check_delay: 20
        health_mon_check_retries: 10

    この例でのクラスターは、Ceph OSD の場合は 30 回確認 (確認ごとに40 秒間待機) し、Ceph MON の場合は 20 回確認 (確認ごとに10 秒間待機) します。

  2. 変更を反映するには、openstack overcloud deploy を使用して -e を指定し、更新された yaml ファイルを渡します。

5.7. Ansible 環境変数のオーバーライド

Red Hat OpenStack Platform Workflow サービス (mistral) は Ansible を使用して Ceph Storage を設定しますが、Ansible 環境変数を使用して Ansible 環境をカスタマイズすることができます。

手順

ANSIBLE_* 環境変数をオーバーライドするには、CephAnsibleEnvironmentVariables heat テンプレートパラメーターを使用します。

以下に示す設定例では、フォークおよび SSH のリトライ回数を増やします。

parameter_defaults:
  CephAnsibleEnvironmentVariables:
    ANSIBLE_SSH_RETRIES: '6'
    DEFAULT_FORKS: '35'

Ansible 環境変数の詳細は、「Ansible Configuration Settings」を参照してください。

Ceph Storage クラスターのカスタマイズ方法に関する詳細は、「Ceph Storage Cluster のカスタマイズ」を参照してください。

5.8. Ceph 伝送時暗号化の有効化

Red Hat Ceph Storage 4 以降、messenger バージョン 2 プロトコルの導入により、ネットワーク上のすべての Ceph トラフィックの暗号化を有効にすることができます。messenger v2 の secure mode 設定は、Ceph デーモンと Ceph クライアント間の通信を暗号化するため、エンドツーエンドの暗号化を行います。

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

注記

この機能は現在テクノロジープレビューとして提供されていますが、Red Hat OpenStack Platform (RHOSP) バージョン 16.1 以降で使用することが意図されています。外部の Red Hat Ceph Storage バージョン 4 を使用する RHOSP バージョン 13 デプロイメントではサポートされません。詳しい情報は、『Red Hat Ceph Storage アーキテクチャーガイド』「Ceph on-wire 暗号化」を参照してください。

RHOSP で Ceph 伝送時暗号化を有効にするには、お使いの環境オーバーライドファイルで以下のパラメーターを設定します。

parameter_defaults:
  CephConfigOverrides:
    global:
      ms_cluster_mode: secure
      ms_service_mode: secure
      ms_client_mode: secure

Ceph 伝送時暗号化に関する詳しい情報は、『アーキテクチャーガイド』「Ceph on-wire 暗号化」を参照してください。