手順

1. インベントリーファイルを作成したら、そのファイルを stack ユーザーのホームディレクトリーに保存します (/home/stack/instackenv.json)。

2. stack ユーザーを初期化し、続いて instackenv.json インベントリーファイルを director にインポートします。

   $ source ~/stackrc
   $ openstack overcloud node import ~/instackenv.json

   openstack overcloud node import コマンドは、インベントリーファイルをインポートし、各ノードを director に登録します。

3. カーネルと ramdisk イメージを各ノードに割り当てます。

   $ openstack overcloud node configure <node>

   結果

   director でのノードの登録、設定が完了しました。

手順

1. ハードウェアのイントロスペクションをトリガーして、各ノードのハードウェア属性を取得します。

   $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。

   • --provide オプションは、イントロスペクション後に全ノードを active の状態にリセットします。

     重要

     このプロセスが正常に完了したことを確認します。ベアメタルノードの場合には、通常 15 分ほどかかります。

2. ノードリストを取得して UUID を把握します。

   $ openstack baremetal node list

3. 各ノードの properties/capabilities パラメーターに profile オプションを追加して、ノードを特定のプロファイルに手動でタグ付けします。profile オプションを追加すると、適切なプロファイルにノードをタグ付けします。

   注記

   手動でのタグ付けの代わりに、Automated Health Check (AHC) ツールを使用し、ベンチマークデータに基づいて、多数のノードに自動でタグ付けします。

   たとえば、標準的なデプロイメントには、control、compute、および ceph-storage の 3 つのプロファイルが含まれます。以下のコマンドを実行して、3 つのノードを各プロファイルにタグ付けします。

   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 484587b2-b3b3-40d5-925b-a26a2fa3036f
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d010460b-38f2-4800-9cc4-d69f0d067efe
   $ openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' d930e613-3e14-44b9-8240-4f3559801ea6

手順

1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。

   (undercloud)$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

   たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

   [
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sda",
       "wwn_vendor_extension": "0x1ea4dcc412a9632b",
       "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380700",
       "serial": "61866da04f3807001ea4dcc412a9632b"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdb",
       "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
       "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f380d00",
       "serial": "61866da04f380d001ea4e13c12e36ad6"
     }
     {
       "size": 299439751168,
       "rotational": true,
       "vendor": "DELL",
       "name": "/dev/sdc",
       "wwn_vendor_extension": "0x1ea4e31e121cfb45",
       "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
       "model": "PERC H330 Mini",
       "wwn": "0x61866da04f37fc00",
       "serial": "61866da04f37fc001ea4e31e121cfb45"
     }
   ]

2. openstack baremetal node set --property root_device= を入力して、ノードのルートディスクを設定します。ルートディスクを定義するのに最も適切なハードウェア属性値を指定します。

   (undercloud)$ openstack baremetal node set --property root_device='{"serial":"<serial_number>"}' <node-uuid>

   たとえば、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 の disk 2 に設定するには、以下のコマンドを実行します。

   (undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

   注記

   各ノードの BIOS を設定して、選択したルートディスクからの起動を含めるようにします。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるように、ブート順序を設定します。

   director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud deploy コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。

手順

1. overcloud-minimal イメージを使用するように director を設定するには、以下のイメージ定義を含む環境ファイルを作成します。

   parameter_defaults:
     <roleName>Image: overcloud-minimal

2. <roleName> をロール名に置き換え、ロール名に Image を追加します。Ceph Storage ノードの overcloud-minimal イメージの例を以下に示します。

   parameter_defaults:
     CephStorageImage: overcloud-minimal

3. roles_data.yaml ロール定義ファイルで、rhsm_enforce パラメーターを False に設定します。

   rhsm_enforce: False

4. この環境ファイルを openstack overcloud deploy コマンドに渡します。

手順

1. カスタムロールを追加できるように、/home/stack/templates/ の roles_data.yaml ファイルのコピーを作成します。

   $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data_custom.yaml

2. openstack overcloud deploy コマンドに新しいカスタムロールファイルを追加します。

手順

1. /home/stack/templates/roles_data_custom.yaml ファイルを開きます。
2. Ceph MON サービスのサービスエントリー OS::TripleO::Services::CephMon を Controller ロールから削除します。

3. OS::TripleO::Services::CephClient サービスを Controller ロールに追加します。

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

4. roles_data_custom.yaml ファイルの末尾に、Ceph MON サービスおよびその他すべての必要なノードサービスを含むカスタムの CephMon ロールを追加します。

   - name: CephMon
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMon

5. openstack flavor create コマンドを入力し、CephMon ロール用に ceph-mon という名前の新規フレーバーを定義します。

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mon

   注記

   このコマンドの詳細については、openstack flavor create --help と入力します。

6. このフレーバーを新規プロファイルにマッピングします。このプロファイルも ceph-mon という名前です。

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mon" ceph-mon

   注記

   このコマンドの詳細については、openstack flavor set --help と入力します。

7. ノードを新しい ceph-mon プロファイルにタグ付けします。

   $ openstack baremetal node set --property capabilities='profile:ceph-mon,boot_option:local' UUID

8. ceph-mon フレーバーを CephMon ロールに関連付けるには、以下の設定を node-info.yaml ファイルに追加します。

   parameter_defaults:
     OvercloudCephMonFlavor: CephMon
     CephMonCount: 3

手順

1. /home/stack/templates/roles_data_custom.yaml ファイルを開きます。

2. Ceph MDS サービスのサービスエントリー OS::TripleO::Services::CephMds を Controller ロールから削除します。

   [...]
   - name: Controller # the 'primary' role goes first
     CountDefault: 1
     ServicesDefault:
       - OS::TripleO::Services::CACerts
       # - OS::TripleO::Services::CephMds 1
       - OS::TripleO::Services::CephMon
       - OS::TripleO::Services::CephExternal
       - OS::TripleO::Services::CephRbdMirror
       - OS::TripleO::Services::CephRgw
       - OS::TripleO::Services::CinderApi
   [...]

   1

   この行をコメントアウトします。次のステップで、このサービスを新しいカスタムロールに追加します。

3. roles_data_custom.yaml ファイルの末尾に、Ceph MDS サービスおよびその他すべての必要なノードサービスを含むカスタムの CephMDS ロールを追加します。

   - name: CephMDS
     ServicesDefault:
       # Common Services
       - OS::TripleO::Services::AuditD
       - OS::TripleO::Services::CACerts
       - OS::TripleO::Services::CertmongerUser
       - OS::TripleO::Services::Collectd
       - OS::TripleO::Services::Docker
       - OS::TripleO::Services::FluentdClient
       - OS::TripleO::Services::Kernel
       - OS::TripleO::Services::Ntp
       - OS::TripleO::Services::ContainersLogrotateCrond
       - OS::TripleO::Services::SensuClient
       - OS::TripleO::Services::Snmp
       - OS::TripleO::Services::Timezone
       - OS::TripleO::Services::TripleoFirewall
       - OS::TripleO::Services::TripleoPackages
       - OS::TripleO::Services::Tuned
       # Role-Specific Services
       - OS::TripleO::Services::CephMds
       - OS::TripleO::Services::CephClient 1

   1

   Ceph MDS サービスには、Ceph MON サービスまたは Ceph Client サービスのいずれかで設定できる管理キーリングが必要です。Ceph MON サービスがない専用のノードに Ceph MDS をデプロイする場合には、新しい CephMDS ロールに Ceph クライアントサービスも追加する必要があります。

4. openstack flavor create コマンドを入力し、このロール用に ceph-mds という名前の新規フレーバーを定義します。

   $ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 ceph-mds

   注記

   このコマンドの詳細については、openstack flavor create --help と入力します。

5. 新規の ceph-mds フレーバーを新規プロファイルにマッピングします。このプロファイルも、ceph-mds という名前になります。

   $ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="ceph-mds" ceph-mds

   注記

   このコマンドの詳細については、openstack flavor set --help と入力します。

6. ノードを新しい ceph-mds プロファイルにタグ付けします。

   $ openstack baremetal node set --property capabilities='profile:ceph-mds,boot_option:local' UUID

手順

1. カスタム環境ファイル (swift-external-params.yaml 等) に以下の parameter_defaults を追加し、実際のデプロイメントに合わせて値を調整します。

   parameter_defaults:
      ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
      ExternalSwiftUserTenant: 'service'
      SwiftPassword: 'choose_a_random_password'

   注記

   サンプルコードスニペットには、お使いの環境で使用する値とは異なるパラメーター値が含まれる場合があります。

   • リモート RGW インスタンスがリッスンするデフォルトのポートは 8080 です。外部 RGW の設定方法によっては、ポートが異なる場合があります。
   • オーバークラウドで作成した swift ユーザーは、SwiftPassword パラメーターで定義したパスワードを使用します。rgw_keystone_admin_password を使用し、Identity サービスに対する認証に同じパスワードを使用するように外部 RGW インスタンスを設定する必要があります。

2. Ceph 設定ファイルに以下のコードを追加して、Identity サービスを使用するように RGW を設定します。変数の値を実際の環境に応じて置き換えます。

       rgw_keystone_api_version = 3
       rgw_keystone_url = http://<public Keystone endpoint>:5000/
       rgw_keystone_accepted_roles = member, Member, admin
       rgw_keystone_accepted_admin_roles = ResellerAdmin, swiftoperator
       rgw_keystone_admin_domain = default
       rgw_keystone_admin_project = service
       rgw_keystone_admin_user = swift
       rgw_keystone_admin_password = <password_as_defined_in_the_environment_parameters>
       rgw_keystone_implicit_tenants = true
       rgw_keystone_revocation_interval = 0
       rgw_s3_auth_use_keystone = true
       rgw_swift_versioning_enabled = true
       rgw_swift_account_in_url = true

   注記

   デフォルトでは、director は Identity サービスに以下のロールとユーザーを作成します。

   • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
   • rgw_keystone_admin_domain: default
   • rgw_keystone_admin_project: service
   • rgw_keystone_admin_user: swift

3. デプロイメントに該当するその他の環境ファイルと共に、追加の環境ファイルを指定して、オーバークラウドをデプロイします。

   openstack overcloud deploy --templates \
   -e <your_environment_files>
   -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
   -e swift-external-params.yaml

検証

1. アンダークラウドに stack ユーザーとしてログインします。

2. source コマンドで overcloudrc ファイルを読み込みます。

   $ source ~/stackrc

3. エンドポイントが Identity サービス (keystone) に存在することを確認します。

   $ openstack endpoint list --service object-store
   
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | ID | Region    | Service Name | Service Type | Enabled | Interface | URL |
   +---------+-----------+-------+-------+---------+-----------+---------------+
   | 233b7ea32aaf40c1ad782c696128aa0e | regionOne | swift | object-store | True    | admin     | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   | 4ccde35ac76444d7bb82c5816a97abd8 | regionOne | swift | object-store | True    | public    | https://192.168.24.2:13808/v1/AUTH_%(project_id)s |
   | b4ff283f445348639864f560aa2b2b41 | regionOne | swift | object-store | True    | internal  | http://192.168.24.3:8080/v1/AUTH_%(project_id)s |
   +---------+-----------+-------+-------+---------+-----------+---------------+

4. テストコンテナーを作成します。

   $ openstack container create <testcontainer>
   +----------------+---------------+------------------------------------+
   | account | container | x-trans-id |
   +----------------+---------------+------------------------------------+
   | AUTH_2852da3cf2fc490081114c434d1fc157 | testcontainer | tx6f5253e710a2449b8ef7e-005f2d29e8 |
   +----------------+---------------+------------------------------------+

5. 設定ファイルを作成し、データをコンテナーにアップロードできることを確認します。

   $ openstack object create testcontainer undercloud.conf
   +-----------------+---------------+----------------------------------+
   | object          | container     | etag                             |
   +-----------------+---------------+----------------------------------+
   | undercloud.conf | testcontainer | 09fcffe126cac1dbac7b89b8fd7a3e4b |
   +-----------------+---------------+----------------------------------+

6. テストコンテナーを削除します。

   $ openstack container delete -r <testcontainer>

手順

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

   parameter_defaults:
     CephPools:
       - name: POOL

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

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

     parameter_defaults:
       CephPools:
         - name: POOL
           pg_num: 128
           application: rbd

   • あるいは、配置グループを自動的にスケーリングするには、pg_autoscale_mode を True に設定し、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

手順

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 ファイルを渡します。

手順

1. アンダークラウドノードに stack ユーザーとしてログインします。
2. Ceph config パラメーターおよびデバイスクラス変数を含む環境ファイル (/home/stack/templates/ceph-config.yaml 等) を作成します。あるいは、既存の環境ファイルに以下の設定を追加することができます。

3. 環境ファイルで CephAnsibleDisksConfig パラメーターを使用して、Ceph OSD として使用するブロックデバイスをリスト表示します。

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

4. オプション: Ceph はディスクの種別を自動的に検出して、対応するデバイスクラスに割り当てます。ただし、crush_device_class プロパティーを使用して、特定のデバイスを特定のクラスに属するように強制したり、独自のカスタムクラスを作成したりすることもできます。以下の例は、指定したクラスを持つ OSD のリストと同じです。

   CephAnsibleDisksConfig:
       lvm_volumes:
         - data: '/dev/sdb'
           crush_device_class: 'hdd'
         - data: '/dev/sdc'
           crush_device_class: 'hdd'
         - data: '/dev/sdd'
           crush_device_class: 'ssd'
       osd_scenario: lvm
       osd_objectstore: bluestore

5. CephAnsibleExtraVars パラメーターを追加します。crush_rules パラメーターには、定義した各クラスまたは Ceph が自動検出する各クラスにルールが含まれている必要があります。新しいプールを作成する際にルールが指定されていない場合は、Ceph が使用するルールがデフォルトとして選択されます。

   CephAnsibleExtraConfig:
       crush_rule_config: true
       create_crush_tree: true
       crush_rules:
         - name: HDD
           root: default
           type: host
           class: hdd
           default: true
         - name: SSD
           root: default
           type: host
           class: ssd
           default: false

6. CephPools パラメーターを追加します。

   • rule_name パラメーターを使用して、デフォルトのルールを使用しない各プールの層を指定します。以下の例では、fastpool プールは、fast tier として設定された SSD デバイスクラスを使用して Block Storage ボリュームを管理します。

   • <appropriate_PG_num> を配置グループ (PG) の適切な数に置き換えます。あるいは、配置グループの自動スケーラーを使用して、Ceph プールの PG の数を計算します。

     詳細は、異なる Ceph プールへのカスタム属性の割り当て を参照してください。

   • CinderRbdExtraPools パラメーターを使用して、fastpool を Block Storage バックエンドとして設定します。

     CephPools:
       - name: fastpool
         pg_num: <appropraiate_PG_num>
         rule_name: SSD
         application: rbd
     CinderRbdExtraPools: fastpool

7. 以下の例を使用して、環境ファイルに正しい値が含まれることを確認します。

   parameter_defaults:
       CephAnsibleDisksConfig:
           devices:
               - '/dev/sdb'
               - '/dev/sdc'
               - '/dev/sdd'
           osd_scenario: lvm
           osd_objectstore: bluestore
       CephAnsibleExtraConfig:
           crush_rule_config: true
           create_crush_tree: true
           crush_rules:
               - name: HDD
                 root: default
                 type: host
                 class: hdd
                 default: true
               - name: SSD
                 root: default
                 type: host
                 class: ssd
                 default: false
       CinderRbdExtraPools: fastpool
       CephPools:
           - name: fastpool
             pg_num: <appropriate_PG_num>
             rule_name: SSD
             application: rbd

8. openstack overcloud deploy コマンドで新規の環境ファイルを指定します。

   $ openstack overcloud deploy \
   --templates \
   …
   -e <other_overcloud_environment_files> \
   -e /home/stack/templates/ceph-config.yaml  \
   …

   <other_overcloud_environment_files> をデプロイメントに追加する環境ファイルのリストに置き換えます。

手順

1. アンダークラウドノードに stack ユーザーとしてログインします。

2. source コマンドで overcloudrc ファイルを読み込みます。

   $ source overcloudrc

3. Block Storage ボリュームの既存種別を確認します。

   $ cinder type-list

4. 新規の Block Storage ボリューム fast_tier を作成します。

   $ cinder type-create fast_tier

5. Block Storage 種別が作成されていることを確認します。

   $ cinder type-list

6. fast_tier Block Storage 種別が利用可能な場合は、作成した新しい層の Block Storage ボリュームバックエンドとして fastpool を設定します。

   $ cinder type-key fast_tier set volume_backend_name=tripleo_ceph_fastpool

7. 新しい層を使用して、新しいボリュームを作成します。

   $ cinder create 1 --volume-type fast_tier --name fastdisk

手順

1. オーバークラウドコントローラーノードに heat-admin ユーザーとしてログインします。

2. OSD 層が正常に設定されていることを確認するには、以下のコマンドを入力します。<controller_hostname> を、ホストコントローラーノードの名前に置き換えます。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd tree

3. 作成されるツリービューで、各 OSD に設定したデバイスクラスが CLASS コラムに正しく表示されることを確認します。

4. また、以下のコマンドで、OSD がデバイスクラスに正しく割り当てられていることを確認します。<controller_hostname> を、ホストコントローラーノードの名前に置き換えます。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd crush tree --show-shadow

5. 作成された階層を以下のコマンドによる結果と比較し、ルールごとに同じ値が適用されることを確認します。

   • <controller_hostname> を、ホストコントローラーノードの名前に置き換えます。

   • <rule_name> を、チェックするルールの名前に置き換えます。

     $ sudo podman exec <controller_hostname> ceph osd crush rule dump <rule_name>

6. 作成したルール名と ID が、デプロイメント中に使用した crush_rules パラメーターに準じて正しいことを確認します。<controller_hostname> を、ホストコントローラーノードの名前に置き換えます。

   $ sudo podman exec -it ceph-mon-<controller_hostname>  ceph osd crush rule dump | grep -E "rule_(id|name)"

7. Ceph プールが、ステップ 3 で取得した正しい CRUSH ルール ID に関連付けられていることを確認します。<controller_hostname> を、ホストコントローラーノードの名前に置き換えます。

   $ sudo podman exec -it ceph-mon-<controller_hostname> ceph osd dump | grep pool

8. 各プールについて、ルール ID が想定するルール名と一致することを確認してください。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. デフォルトのコンテナーイメージ準備ファイルを生成します。

   $ sudo openstack tripleo container image prepare default \
     --local-push-destination \
     --output-env-file containers-prepare-parameter.yaml

3. containers-prepare-parameter.yaml ファイルを編集し、要件に合わせて変更を加えます。以下の containers-prepare-parameter.yaml ファイルのサンプルには、Grafana、Prometheus、Alertmanager、および Node Exporter などの Dashboard サービスに関連するイメージの場所およびタグが含まれます。特定のシナリオに応じて値を編集します。

   parameter_defaults:
       ContainerImagePrepare:
       - push_destination: true
           set:
               ceph_alertmanager_image: ose-prometheus-alertmanager
               ceph_alertmanager_namespace: registry.redhat.io/openshift4
               ceph_alertmanager_tag: v4.1
               ceph_grafana_image: rhceph-4-dashboard-rhel8
               ceph_grafana_namespace: registry.redhat.io/rhceph
               ceph_grafana_tag: 4
               ceph_image: rhceph-4-rhel8
               ceph_namespace: registry.redhat.io/rhceph
               ceph_node_exporter_image: ose-prometheus-node-exporter
               ceph_node_exporter_namespace: registry.redhat.io/openshift4
               ceph_node_exporter_tag: v4.1
               ceph_prometheus_image: ose-prometheus
               ceph_prometheus_namespace: registry.redhat.io/openshift4
               ceph_prometheus_tag: v4.1
               ceph_tag: latest

手順

1. アンダークラウドノードに stack ユーザーとしてログインします。

2. openstack overcloud deploy コマンドに、デプロイメントに含まれるすべての環境ファイルと共に以下の環境ファイルを追加します。

   $ openstack overcloud deploy \
    --templates \
    -e <overcloud_environment_files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml

   <overcloud_environment_files> をデプロイメントに追加する環境ファイルのリストに置き換えます。

   結果

   これにより、デプロイメントは grafana、prometheus、alertmanager、および node-exporter コンテナーが含まれる外部スタックを設定します。Ceph Dashboard Manager モジュールは、このスタックのバックエンドで、grafana レイアウトを組み込むことで、Ceph クラスター固有のメトリックをエンドユーザーに提供します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. Controller 固有のロールを生成して、Dashboard コンポーザブルネットワークを追加します。

   $ openstack overcloud roles generate -o /home/stack/roles_data_dashboard.yaml ControllerStorageDashboard Compute BlockStorage ObjectStorage CephStorage

   結果

   • 新しい ControllerStorageDashboard ロールは、コマンドの出力として定義される roles_data.yaml 内に生成されます。overcloud deploy コマンドを使用する場合には、このファイルをテンプレートリストに含める必要があります。

     注: ControllerStorageDashboard ロールには、CephNFS も network_data_dashboard.yaml も含まれていません。

   • director は、コンポーザブルネットワークを定義するネットワーク環境ファイルを提供します。このファイルのデフォルトの場所は、/usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml です。overcloud deploy コマンドを使用する場合には、このファイルをオーバークラウドのテンプレートリストに含める必要があります。

3. openstack overcloud deploy コマンドに、デプロイメントに含まれるすべての環境ファイルと共に以下の環境ファイルを追加します。

   $ openstack overcloud deploy \
     --templates \
     -r /home/stack/roles_data.yaml \
     -n /usr/share/openstack-tripleo-heat-templates/network_data_dashboard.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
     -e <overcloud_environment_files> \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-dashboard.yaml

   <overcloud_environment_files> をデプロイメントに追加する環境ファイルのリストに置き換えます。

   結果

   これにより、デプロイメントは grafana、prometheus、alertmanager、および node-exporter コンテナーが含まれる外部スタックを設定します。Ceph Dashboard Manager モジュールは、このスタックのバックエンドで、grafana レイアウトを組み込むことで、Ceph クラスター固有のメトリックをエンドユーザーに提供します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. 以下の ceph_dashboard_admin.yaml 環境ファイルを作成します。

     parameter_defaults:
        CephDashboardAdminRO: false

3. overcloud deploy コマンドを実行して、既存のスタックを更新し、既存のデプロイメントに含まれるその他すべての環境ファイルと共に作成した環境ファイルを追加します。

   $ openstack overcloud deploy \
   --templates \
   -e <existing_overcloud_environment_files> \
   -e ceph_dashboard_admin.yml

   <existing_overcloud_environment_files> を既存のデプロイメントに含まれる環境ファイルのリストに置き換えます。

手順

1. アンダークラウドノードに stack ユーザーとしてログインします。

2. Dashboard の管理ログイン認証情報を取得します。

   [stack@undercloud ~]$ grep dashboard_admin_password /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

3. Ceph Dashboard にアクセスするための仮想 IP アドレスを取得します。

   [stack@undercloud-0 ~]$ grep dashboard_frontend_vip /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml

4. Web ブラウザーを使用してフロントエンドの仮想 IP をポイントし、Dashboard にアクセスします。director はプロビジョニングネットワーク上で Dashboard を設定して公開するので、取得した仮想 IP を使用して、TCP ポート 8444 の Dashboard に直接アクセスできます。以下の条件を満たしていることを確認します。

   • Web クライアントホストは、プロビジョニングネットワークに接続されたレイヤー 2 です。

   • プロビジョニングネットワークは適切にルーティングまたはプロキシーされ、Web クライアントホストからアクセスできます。これらの条件が満たされていない場合は、SSH トンネルを開いて、オーバークラウド上の Dashboard の仮想 IP に到達することができます。

     client_host$ ssh -L 8444:<dashboard_vip>:8444 stack@<your undercloud>

     <dashboard_vip> を取得したコントロールプレーンの仮想 IP の IP アドレスに置き換えます。

5. Dashboard にアクセスするには、Web ブラウザーで http://localhost:8444 にアクセスし、以下の詳細でログインします。

   • ceph-ansible が作成するデフォルトのユーザー: admin

   • /var/lib/mistral/overcloud/ceph-ansible/group_vars/all.yml のパスワード

     結果

   • Ceph Dashboard にアクセスできます。
   • Dashboard に表示される数字およびグラフには、CLI コマンドの ceph -s が返すのと同じクラスターステータスが反映されます。

手順

1. コントローラーノードに heat-admin ユーザーとしてログインします。

   $ nova list
   $ ssh heat-admin@192.168.0.25

2. クラスターの正常性を確認します。

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph health

   クラスターに問題がない場合は、上記のコマンドにより、HEALTH_OK というレポートが返されます。これは、クラスターを安全に使用できることを意味します。

3. Ceph monitor サービスを実行するオーバークラウドノードにログインし、クラスター内の全 OSD のステータスを確認します。

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd tree

4. Ceph Monitor クォーラムのステータスを確認します。

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph quorum_status

   これにより、クォーラムに参加するモニターとどれがリーダーであるかが表示されます。

5. すべての Ceph OSD が動作中であることを確認します。

   $ sudo podman exec ceph-mon-<HOSTNAME> ceph osd stat

手順

1. ceph-mon サービスを実行している Ceph Monitor または Controller ノードにログインし、Ceph Storage クラスターのリバランスを一時的に無効にします。

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance

   注記

   マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、 nooutフラグとnorebalanceフラグの設定時にクラスター名を指定する必要があります。例: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

2. 再起動する最初の Ceph Storage ノードを選択し、そのノードにログインします。

3. ノードを再起動します。

   $ sudo reboot

4. ノードがブートするまで待ちます。

5. ノードにログインして、クラスターのステータスを確認します。

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

   pgmap により、すべての pgs が正常な状態 (active+clean) として報告されることを確認します。

6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。

7. 完了したら、ceph-mon サービスを実行している Ceph Monitor または Controller ノードにログインし、クラスターの再調整を再度有効にします。

   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
   $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance

   注記

   マルチスタックまたは分散コンピュートノード (DCN) アーキテクチャーを使用している場合は、 nooutフラグとnorebalanceフラグの設定解除時にクラスター名を指定する必要があります。例: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster <cluster_name>

8. 最終のステータスチェックを実行して、クラスターが HEALTH_OK を報告していることを確認します。

   $ sudo podman exec -it ceph-mon-controller-0 ceph status

手順

1. アンダークラウドに stack ユーザーとしてログインし、director の設定を初期化します。

   $ source ~/stackrc

2. 新規ノードの定義テンプレート (例: instackenv-scale.json) で、新しいノードのハードウェアと電源管理の詳細を定義します。

3. このファイルを director にインポートします。

   $ openstack overcloud node import ~/instackenv-scale.json

   ノードの定義テンプレートをインポートすると、そのテンプレートで定義されている各ノードが director に登録されます。

4. カーネルと ramdisk イメージを全ノードに割り当てます。

   $ openstack overcloud node configure

手順

1. ハードウェアのイントロスペクションをトリガーして、各ノードのハードウェア属性を取得します。

   $ openstack overcloud node introspect --all-manageable --provide

   • --all-manageable オプションを使用して、管理状態にあるノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。

   • --provide オプションは、イントロスペクション後に全ノードを active の状態にリセットします。

     重要

     このプロセスが正常に完了したことを確認します。ベアメタルノードの場合には、通常 15 分ほどかかります。

2. ノードリストを取得して UUID を把握します。

   $ openstack baremetal node list

3. 各ノードの properties/capabilities パラメーターに profile オプションを追加して、ノードを特定のプロファイルに手動でタグ付けします。profile オプションを追加すると、適切なプロファイルにノードをタグ付けします。

   注記

   手動でのタグ付けの代わりに、Automated Health Check (AHC) ツールを使用し、ベンチマークデータに基づいて、多数のノードに自動でタグ付けします。たとえば、以下のコマンドは、3 つの追加のノードを ceph-storage プロファイルでタグ付けします。

   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 551d81f5-4df2-4e0f-93da-6c5de0b868f7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 5e735154-bd6b-42dd-9cc2-b6195c4196d7
   $ openstack baremetal node set --property capabilities='profile:baremetal,boot_option:local' 1a2b090c-299d-4c20-a25d-57dd21a7085b

手順

1. オーバークラウドを再デプロイする前に、環境ファイル (ここでは ~/templates/storage-config.yaml) の parameter_defaults にある CephStorageCount パラメーターを設定します。「ロールへのノードとフレーバーの割り当て」では、オーバークラウドは 3 つの Ceph Storage ノードでデプロイするように設定されています。以下の例では、オーバークラウドを 6 つのノードにスケーリングしています。

   parameter_defaults:
     ControllerCount: 3
     OvercloudControlFlavor: control
     ComputeCount: 3
     OvercloudComputeFlavor: compute
     CephStorageCount: 6
     OvercloudCephStorageFlavor: ceph-storage
     CephMonCount: 3
     OvercloudCephMonFlavor: ceph-mon

2. オーバークラウドを再デプロイします。オーバークラウドには、3 つの Ceph Storage ノードではなく 6 つの Ceph Storage ノードが含まれるようになりました。

手順

1. コントローラーノードに heat-admin ユーザーとしてログインします。director の stack ユーザーには、heat-admin ユーザーにアクセスするための SSH キーがあります。

2. OSD ツリーをリスト表示して、お使いのノードの OSD を検索します。たとえば、削除するノードには、以下の OSD が含まれる場合があります。

   -2 0.09998     host overcloud-cephstorage-0
   0 0.04999         osd.0                         up  1.00000          1.00000
   1 0.04999         osd.1                         up  1.00000          1.00000

3. Ceph Storage ノードの OSD を無効化します。今回は、OSD ID は 0 と 1 です。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd out 1

4. Ceph Storage クラスターがリバランスを開始します。このプロセスが完了するまで待機してください。以下のコマンドを使用して、ステータスを確認できます。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph -w

5. Ceph クラスターのリバランスが完了したら、削除する Ceph Storage ノード (ここでは overcloud-cephstorage-0) に heat-admin ユーザーとしてログインし、ノードを停止し無効にします。

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl disable ceph-osd@1

6. OSD を停止します。

   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@0
   [heat-admin@overcloud-cephstorage-0 ~]$ sudo systemctl stop ceph-osd@1

7. コントローラーノードにログインしたら、CRUSH マップから OSD を削除して、データを受信しないようにします。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush remove osd.1

8. OSD 認証キーを削除します。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph auth del osd.1

9. クラスターから OSD を削除します。

   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 0
   [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd rm 1

10. CRUSH マップからストレージノードを削除します。

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec ceph-mon-<HOSTNAME> ceph osd crush rm <NODE>
    [heat-admin@overcloud-controller-0 ~]$ sudo ceph osd crush remove <NODE>

    CRUSH ツリーを検索して、CRUSH マップに定義されている <NODE> の名前を確認できます。

    [heat-admin@overcloud-controller-0 ~]$ sudo podman exec ceph-mon-<HOSTNAME> ceph osd crush tree | grep overcloud-osd-compute-3 -A 4
                    "name": "overcloud-osd-compute-3",
                    "type": "host",
                    "type_id": 1,
                    "items": []
                },
    [heat-admin@overcloud-controller-0 ~]$

    CRUSH ツリーで、アイテムリストが空であることを確認します。リストが空でない場合は、ステップ 7 を再度実施してください。

11. ノードからログアウトして、stack ユーザーとしてアンダークラウドに戻ります。

    [heat-admin@overcloud-controller-0 ~]$ exit
    [stack@director ~]$

12. director が再度プロビジョニングしないように、Ceph Storage ノードを無効にします。

    [stack@director ~]$ openstack baremetal node list
    [stack@director ~]$ openstack baremetal node maintenance set UUID

13. Ceph Storage ノードを削除するには、ローカルのテンプレートファイルを使用して、director の overcloud スタックへの更新が必要です。最初にオーバークラウドスタックの UUID を特定します。

    $ openstack stack list

14. 削除する Ceph Storage ノードの UUID を特定します。

    $ openstack server list

15. スタックからノードを削除し、それに応じてプランを更新します。

    重要

    オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e オプションを使用して環境ファイルを再度渡します。詳しい情報は、director のインストールと使用方法ガイドの オーバークラウド環境の変更 を参照してください。

    $ openstack overcloud node delete /
    --stack <stack-name> /
    --templates /
    -e <other-environment-files> /
    <node_UUID>

16. stack が更新を完了するまで待機します。heat stack-list --show-nested コマンドを使用して、stack の更新を監視します。

17. 新規ノードを director のノードプールに追加して、Ceph Storage ノードとしてデプロイします。環境ファイル (ここでは ~/templates/storage-config.yaml) の parameter_defaults の CephStorageCount パラメーターを使用して、オーバークラウド内の Ceph Storage ノードの合計数を定義します。

    parameter_defaults:
      ControllerCount: 3
      OvercloudControlFlavor: control
      ComputeCount: 3
      OvercloudComputeFlavor: compute
      CephStorageCount: 3
      OvercloudCephStorageFlavor: ceph-storage
      CephMonCount: 3
      OvercloudCephMonFlavor: ceph-mon

    注記

    ロールごとのノード数を定義する方法の詳細は、「ロールへのノードとフレーバーの割り当て」を参照してください。

18. 環境ファイルを更新したら、オーバークラウドを再デプロイします。

    $ openstack overcloud deploy --templates -e <ENVIRONMENT_FILE>

    director は、新しいノードをプロビジョニングし、新しいノードの詳細を用いて stack 全体を更新します。

19. heat-admin ユーザーとしてコントローラーノードにログインし、Ceph Storage ノードのステータスを確認します。

    [heat-admin@overcloud-controller-0 ~]$ sudo ceph status

20. osdmap セクションの値がクラスターで必要なノード数と一致していることを確認します。削除した Ceph Storage ノードは新規ノードに置き換えられます。

1. 以下の heat テンプレートは、OSD デバイスを 3 つ持つ Ceph Storage をデプロイします。

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

2. OSD を追加するには、「Ceph Storage ノードのディスクレイアウトのマッピング」の説明に従って、ノードのディスクレイアウトを更新します。以下の例では、/dev/sde をテンプレートに追加します。

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

3. openstack overcloud deploy を実行してオーバークラウドを更新します。

1. ceph-storage0 に SSH 接続し、root でログインします。

2. OSD サービスを無効にし、停止します。

   [root@ceph-storage0 ~]# systemctl disable ceph-osd@4
   [root@ceph-stoarge0 ~]# systemctl stop ceph-osd@4

3. ceph-storage0 からの接続を切断します。
4. controller0 に SSH 接続し、root でログインします。

5. Ceph monitor コンテナーの名前を特定します。

   [root@controller0 ~]# podman ps | grep ceph-mon
   ceph-mon-controller0
   [root@controller0 ~]#

6. Ceph monitor コンテナーを有効にして、望ましくない OSD を out とマークします。

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd out 4

   注記

   このコマンドにより、Ceph はストレージクラスターをリバランスし、データをクラスター内の他の OSD にコピーします。クラスターは、リバランスが完了するまで、一時的に active+clean 状態から離れます。

7. 以下のコマンドを実行し、ストレージクラスターの状態が active+clean になるまで待機します。

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph -w

8. CRUSH マップから OSD を削除して、データを受信しないようにします。

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd crush remove osd.4

9. OSD 認証キーを削除します。

   [root@controller0 ~]# podman exec ceph-mon-controller0 ceph auth del osd.4

10. OSD を削除します。

    [root@controller0 ~]# podman exec ceph-mon-controller0 ceph osd rm 4

11. controller0 から接続を解除します。
12. stack ユーザーとしてアンダークラウドに SSH 接続し、CephAnsibleDisksConfig パラメーターを定義した heat 環境ファイルを見つけます。

13. heat テンプレートに OSD が 4 つ含まれています。

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

14. テンプレートを変更して /dev/sde を削除します。

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

15. openstack overcloud deploy を実行してオーバークラウドを更新します。

    注記

    この例では、OSD を持つすべてのホストから /dev/sde デバイスを削除します。すべてのノードから同じデバイスを削除しない場合には、heat テンプレートを更新します。異なる devices 一覧を持つホストを定義する方法は、「異なる Ceph Storage ノードのパラメーターのオーバーライド」 を参照してください。

手順

1. 実行中の Ceph モニターコンテナーの名前を特定し、これを MON という環境変数に保存します。

   MON=$(podman ps | grep ceph-mon | awk {'print $1'})

2. ceph コマンドにエイリアスを設定し、これが実行中の Ceph モニターコンテナー内で実行されるようにします。

   alias ceph="podman exec $MON ceph"

3. 新規エイリアスを使用して、置き換える OSD が停止していることを確認します。

   [root@overcloud-controller-0 ~]# ceph osd tree | grep 27
   27   hdd 0.04790         osd.27                    down  1.00000 1.00000

4. OSD を破棄します。以下のコマンド例は OSD 27 を破棄します。

   [root@overcloud-controller-0 ~]# ceph osd destroy 27 --yes-i-really-mean-it
   destroyed osd.27

手順

1. 障害のある OSD が実行されていないことを確認します。

   systemctl stop ceph-osd@27

2. ceph コンテナーイメージのイメージ ID を特定して、これを IMG という環境変数に保存します。

   IMG=$(podman images | grep ceph | awk {'print $3'})

3. ceph-volume コマンドにエイリアスを設定し、これが ceph-volume エントリーポイントおよび関連するディレクトリーを使用して $IMG Ceph コンテナー内で実行されるようにします。

   alias ceph-volume="podman run --rm --privileged --net=host --ipc=host -v /run/lock/lvm:/run/lock/lvm:z -v /var/run/udev/:/var/run/udev/:z -v /dev:/dev -v /etc/ceph:/etc/ceph:z -v /var/lib/ceph/:/var/lib/ceph/:z -v /var/log/ceph/:/var/log/ceph/:z --entrypoint=ceph-volume $IMG --cluster ceph"

4. aliased コマンドが正常に実行されていることを確認します。

   ceph-volume lvm list

5. 新規 OSD デバイスが LVM に含まれていないことを確認します。pvdisplay コマンドを使用してデバイスを検査し、VG Name フィールドが空であることを確認します。<NEW_DEVICE> を新規 OSD デバイスの /dev/* パスに置き換えます。

   [root@overcloud-computehci-2 ~]# pvdisplay <NEW_DEVICE>
     --- Physical volume ---
     PV Name               /dev/sdj
     VG Name               ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
     PV Size               50.00 GiB / not usable 1.00 GiB
     Allocatable           yes (but full)
     PE Size               1.00 GiB
     Total PE              49
     Free PE               0
     Allocated PE          49
     PV UUID               kOO0If-ge2F-UH44-6S1z-9tAv-7ypT-7by4cp
   [root@overcloud-computehci-2 ~]#

   この VG Name フィールドが空でない場合は、デバイスは削除する必要のあるボリュームグループに属します。

6. デバイスがボリュームグループに属する場合は、lvdisplay コマンドを使用して、ボリュームグループに論理ボリュームがあるかどうかを確認します。<VOLUME_GROUP> を、pvdisplay コマンドから取得した VG Name フィールドの値に置き換えます。

   [root@overcloud-computehci-2 ~]# lvdisplay | grep <VOLUME_GROUP>
     LV Path                /dev/ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2/osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6
     VG Name                ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2
   [root@overcloud-computehci-2 ~]#

   この LV Path フィールドが空でない場合は、デバイスには、削除する必要のある論理ボリュームが含まれます。

7. 新規デバイスが論理ボリュームまたはボリュームグループの一部である場合、論理ボリューム、ボリュームグループ、および LVM システム内の物理ボリュームとしてのデバイスの関連付けを削除します。

   • <LV_PATH> を LV Path フィールドの値に置き換えます。
   • <VOLUME_GROUP> を VG Name フィールドの値に置き換えます。

   • <NEW_DEVICE> を新規 OSD デバイスの /dev/* パスに置き換えます。

     [root@overcloud-computehci-2 ~]# lvremove --force <LV_PATH>
       Logical volume "osd-data-a0810722-7673-43c7-8511-2fd9db1dbbc6" successfully removed

     [root@overcloud-computehci-2 ~]# vgremove --force <VOLUME_GROUP>
       Volume group "ceph-0fb0de13-fc8e-44c8-99ea-911e343191d2" successfully removed

     [root@overcloud-computehci-2 ~]# pvremove <NEW_DEVICE>
       Labels on physical volume "/dev/sdj" successfully wiped.

8. 新しい OSD デバイスがクリーンであることを確認します。以下の例では、デバイスは /dev/sdj になります。

   [root@overcloud-computehci-2 ~]# ceph-volume lvm zap /dev/sdj
   --> Zapping: /dev/sdj
   --> --destroy was not specified, but zapping a whole device will remove the partition table
   Running command: /usr/sbin/wipefs --all /dev/sdj
   Running command: /bin/dd if=/dev/zero of=/dev/sdj bs=1M count=10
    stderr: 10+0 records in
   10+0 records out
   10485760 bytes (10 MB, 10 MiB) copied, 0.010618 s, 988 MB/s
   --> Zapping successful for: <Raw Device: /dev/sdj>
   [root@overcloud-computehci-2 ~]#

9. 新しいデバイスを使用して既存の OSD ID で新しい OSD を作成しますが、ceph-volume が OSD の起動を試行しないように --no-systemd を渡します。これはコンテナー内からは実行できません。

   ceph-volume lvm create --osd-id 27 --data /dev/sdj --no-systemd

10. コンテナー外で OSD を起動します。

    systemctl start ceph-osd@27

手順

1. デバイス名が変更されたかどうかを確認し、Ceph のデプロイに使用した命名方法に従ってデバイスリストを更新します。詳細は、「デバイス名の変更の有無についての確認」 を参照してください。
2. 変更に不整合が生じないようにするには、overcloud deploy コマンドを再実行して、スタックの更新を実行します。

3. 異なるデバイスリストを持つホストがある場合は、例外を定義する必要がある場合があります。たとえば、以下に示す heat 環境ファイルのサンプルを使用して、3 つの OSD デバイスを持つノードをデプロイできます。

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

   CephAnsibleDisksConfig パラメーターは OSD をホストするすべてのノードに適用されるため、devices パラメーターを新しいデバイスリストで更新することはできません。代わりに、別のデバイスリストを持つ新規ホストの例外を定義する必要があります。例外の定義に関する詳細は、「異なる Ceph Storage ノードのパラメーターのオーバーライド」 および 「Ceph Storage ノードのディスクレイアウトの変更」 を参照してください。