第2章 Ceph Storage ノードでのオーバークラウドの作成


このシナリオでは、director を使用して、独自の Ceph Storage Cluster が含まれるオーバークラウドを作成する方法を確認します。このシナリオでは、オーバークラウドは 9 台のノードで構成されます。

  • 高可用性のコントローラーノード 3 台。各ノードに Ceph Monitor サービスが含まれます。
  • クラスター内に Red Hat Ceph Storage ノード 3 台。これらのノードには、Ceph OSD が含まれ、実際のストレージとしての役割を果たします。
  • コンピュートノード 3 台

すべてのマシンは、電源管理に IPMI を使用したベアメタルマシンです。director により Red Hat Enterprise Linux 7 のイメージが各ノードにコピーされるため、これらのノードではオペレーティングシステムは必要ありません。

director は、イントロスペクションおよびプロビジョニングプロセス中に、プロビジョニングネットワークを使用して各ノードと通信します。すべてのノードは、ネイティブの VLAN 経由でネットワークに接続します。この例では、以下の IP アドレスの割り当てで、プロビジョニングサブネットとして 192.0.2.0/24 を使用します。

Expand
ノード名IP アドレスMAC アドレスIPMI IP アドレス

director

192.0.2.1

aa:aa:aa:aa:aa:aa

 

コントローラー 1

定義済みの DHCP

b1:b1:b1:b1:b1:b1

192.0.2.205

コントローラー 2

定義済みの DHCP

b2:b2:b2:b2:b2:b2

192.0.2.206

コントローラー 3

定義済みの DHCP

b3:b3:b3:b3:b3:b3

192.0.2.207

コンピュート 1

定義済みの DHCP

c1:c1:c1:c1:c1:c1

192.0.2.208

コンピュート 2

定義済みの DHCP

c2:c2:c2:c2:c2:c2

192.0.2.209

コンピュート 3

定義済みの DHCP

c3:c3:c3:c3:c3:c3

192.0.2.210

Ceph 1

定義済みの DHCP

d1:d1:d1:d1:d1:d1

192.0.2.211

Ceph 2

定義済みの DHCP

d2:d2:d2:d2:d2:d2

192.0.2.212

Ceph 3

定義済みの DHCP

d3:d3:d3:d3:d3:d3

192.0.2.213

2.1. stack ユーザーの初期化

stack ユーザーとして director ホストにログインし、以下のコマンドを実行して director の設定を初期化します。

$ source ~/stackrc

このコマンドでは、director の CLI ツールにアクセスする認証情報が含まれる環境変数を設定します。

2.2. ノードの登録

ノード定義のテンプレート (instackenv.json) は JSON ファイル形式で、ノード登録用のハードウェアおよび電源管理の情報が含まれています。以下に例を示します。

{
    "nodes":[
        {
            "mac":[
                "b1:b1:b1:b1:b1:b1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.205"
        },
        {
            "mac":[
                "b2:b2:b2:b2:b2:b2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.206"
        },
        {
            "mac":[
                "b3:b3:b3:b3:b3:b3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.207"
        },
        {
            "mac":[
                "c1:c1:c1:c1:c1:c1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.208"
        },
        {
            "mac":[
                "c2:c2:c2:c2:c2:c2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.209"
        },
        {
            "mac":[
                "c3:c3:c3:c3:c3:c3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.210"
        },
        {
            "mac":[
                "d1:d1:d1:d1:d1:d1"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.211"
        },
        {
            "mac":[
                "d2:d2:d2:d2:d2:d2"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.212"
        },
        {
            "mac":[
                "d3:d3:d3:d3:d3:d3"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.0.2.213"
        }
    ]
}

テンプレートの作成後に、stack ユーザーのホームディレクトリー (/home/stack/instackenv.json) にファイルを保存してから、director にインポートします。これには、以下のコマンドを実行します。

$ openstack baremetal import --json ~/instackenv.json

このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。

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

$ openstack baremetal configure boot

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

2.3. ノードのハードウェアの検査

ノードの登録後には、各ノードのハードウェア属性を検査します。各ノードのハードウェア属性を検査するには、以下のコマンドを実行します。

$ openstack baremetal introspection bulk start
重要

このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルの場合には、通常 15 分ほどかかります。

2.4. ノードの手動でのタグ付け

各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。これらのプロファイルタグによりノードとフレーバーが照合され、フレーバーがデプロイメントロールに割り当てられます。

ノード一覧を取得して UUID を識別します。

$ ironic node-list

特定のプロファイルにノードを手動でタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 台のノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。

$ ironic node-update 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 add properties/capabilities='profile:control,boot_option:local'
$ ironic node-update 6faba1a9-e2d8-4b7c-95a2-c7fbdc12129a add properties/capabilities='profile:control,boot_option:local'
$ ironic node-update 5e3b2f50-fcd9-4404-b0a2-59d79924b38e add properties/capabilities='profile:control,boot_option:local'
$ ironic node-update 484587b2-b3b3-40d5-925b-a26a2fa3036f add properties/capabilities='profile:compute,boot_option:local'
$ ironic node-update d010460b-38f2-4800-9cc4-d69f0d067efe add properties/capabilities='profile:compute,boot_option:local'
$ ironic node-update d930e613-3e14-44b9-8240-4f3559801ea6 add properties/capabilities='profile:compute,boot_option:local'
$ ironic node-update da0cc61b-4882-45e0-9f43-fab65cf4e52b add properties/capabilities='profile:ceph-storage,boot_option:local'
$ ironic node-update b9f70722-e124-4650-a9b1-aade8121b5ed add properties/capabilities='profile:ceph-storage,boot_option:local'
$ ironic node-update 68bf8f29-7731-4148-ba16-efb31ab8d34f add properties/capabilities='profile:ceph-storage,boot_option:local'

profile オプションを追加すると、適切なプロファイルにノードをタグ付けします。

注記

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

2.5. Ceph Storage ノードの root ディスクの定義

Ceph Storage ノードの大半では、複数のディスクを使用します。つまり、Ceph Storage ノードをプロビジョニングする際に、director は root ディスクに使用するディスクを特定する必要があるという意味です。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • wwn (文字列): 一意のストレージ ID
  • hctl (文字列): SCSI のホスト:チャネル:ターゲット:Lun
  • size (整数):デバイスのサイズ (GB)

以下の例では、root デバイスを特定するディスクのシリアル番号を使用して、オーバークラウドイメージをデプロイするドライブを指定します。

まず、各ノードに使用予定の root ドライブのシリアル番号を検索します。ノードごとに ironic node-show コマンドを使用して、extra セクションから利用可能なブロックデバイスを特定します。たとえば、以下を使用して、全ノードとそのブロックデバイスを一覧表示します。

$ for uuid in `ironic node-list | awk '{print $2}'`; do echo "Node ID: $uuid"; ironic node-show $uuid | grep 'properties\|extra ' -A3; done

この例では、出力には以下が含まれます。

...
Node ID: 97e3f7b3-5629-473e-a187-2193ebe0b5c7
| extra       | {u'newly_discovered': u'true', u'block_devices':      |
|             | {u'serials': [u'100000000', u'100000001',             |
|             | u'100000002', u'100000003', u'100000004',             |
|             | u'100000005', u'100000006', u'100000007',             |
--
| properties  | {u'cpu_arch': u'x86_64', u'root_device': {u'serial':  |
|             | u'100000005'}, u'cpus': u'16', u'capabilities':       |
|             | u'profile:ceph-storage,boot_option:local',            |
|             | u'memory_mb': u'65536', u'local_gb': u'3725'}         |
...

propertiescapabilities セクションには、profile:ceph-storage が含まれており、UUID が 97e3f7b3-5629-473e-a187-2193ebe0b5c7 のノードは Ceph Storage ノードということが分かります。block_devices のパラメーターや各デバイスのシリアル番号の一覧で示されているように、このノードには、複数のブロックデバイスも含まれています。

現在、root_device のシリアル番号は 100000005 に指定されています。この例で、root デバイスのシリアル番号を 100000000 に指定しましょう。これにより、ノードの定義の root_device パラメーターに変更を加える必要があります。

$ ironic node-update 97e3f7b3-5629-473e-a187-2193ebe0b5c7 add properties/root_device='{"serial": "100000000"}'

これにより、director が root ディスクとして使用する特定のディスクを識別しやすくなります。オーバークラウドの作成の開始時には、director はこのノードをプロビジョニングして、オーバークラウドのイメージをこのディスクに書き込みます。

2.6. オーバークラウドでの Ceph Storage の有効化

オーバークラウドのイメージにはすでに、Ceph サービスと必要な Puppet モジュールが含まれており、自動的に Ceph OSD ノードと Ceph Monitor をコントローラークラスター上に設定します。オーバークラウドの heat テンプレートコレクションには、Ceph Storage 設定を有効化するのに必要な手順も含まれていますが、director では Ceph Storage を有効化して、対象の設定に指定するための情報が必要です。この情報を指定するには、storage-environment.yaml の環境ファイルを stack ユーザーの templates ディレクトリーにコピーします。

$ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.

storage-environment.yaml のコピーで以下のオプションを変更します。

CinderEnableIscsiBackend は iSCSI バックエンドを有効化します。この値は false に設定します。CinderEnableRbdBackend は Ceph Storage バックエンドを有効化します。この値は true に設定します。CinderEnableNfsBackend は NFS バックエンドを有効化します。この値は false に設定します。NovaEnableRbdBackend は Nova の一時ストレージ用の Ceph Storage を有効化します。この値は true に設定します。GlanceBackend はバックエンドで Glance を使用するように定義します。この値は、rbd に設定して、イメージに Ceph Storage を使用するようにします。

注記

storage-environment.yaml には、Heat を直接使用して Ceph Storage を設定するためのオプションも含まれています。ただし、director はこれらのノードを作成して、このシナリオでは、自動的に設定値を定義するので、これらのオプションは必要ありません。

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

デフォルトマッピングは、Ceph Storage に root ディスクを使用しますが、実稼動環境の多くは、ストレージやジャーナリング用のパーティションに別個のディスクを複数使用します。このような状況では、以前にコピーした storage-environment.yaml ファイルの一部として、ストレージマップを定義します。

storage-environment.yaml ファイルを編集してセクションを追加し、以下の内容を記載します。

parameter_defaults:
  ExtraConfig:
    ceph::profile::params::osds:

このセクションにより、オーバークラウドに Hiera データが追加されます。Puppet は、設定時にこのデータをカスタムのパラメーターとして使用します。ceph::profile::params::osds パラメーターを使用して、適切なディスクとジャーナルパーティションをマッピングします。たとえば、4 つのディスクがある Ceph ノードでは以下のように割り当てられます。

  • /dev/sda: オーバークラウドのイメージを含む root ディスク
  • /dev/sdb: ジャーナルのパーティションが含まれディスク。これは通常、システムパフォーマンスをソリッドステートドライブ (SSD) です。
  • /dev/sdc および /dev/sdd: OSD のディスク

この例では、以下のような内容が含まれるマッピングとなります。

    ceph::profile::params::osds:
        '/dev/sdc':
          journal: '/dev/sdb'
        '/dev/sdd':
          journal: '/dev/sdb'

ジャーナル用に別のディスクを使用しない場合には、OSD ディスクに併置されているジャーナルを使用します。journal パラメーターには空の値を渡します。

    ceph::profile::params::osds:
        '/dev/sdb': {}
        '/dev/sdc': {}
        '/dev/sdd': {}

変更が完了したら、オーバークラウドのデプロイ時に Ceph Storage ノードにディスクマッピングが使用されるように storage-environment.yaml を保存します。ストレージで必要な設定が開始されるように、デプロイメント内にこのファイルを追加します。

2.8. Ceph Storage ノードディスクの GPT への変換

Ceph Storage OSD およびジャーナルのパーティションには、GPT ディスクラベルが必要です。これは、Ceph Storage にディスクを追加すると、Ceph OSD をインストールする前に GPT ラベルへ変換する必要があります。これには、ノードでスクリプトを実行して、初回起動時にこの操作が実行されるようにする必要があります。このスクリプトは、オーバークラウドの作成時に Heat テンプレートの一部として追加します。たとえば、以下の heat テンプレート (wipe-disks.yaml) は、Ceph Storage ノードの全ディスクをチェックして、全ノード (root ファイルシステムを含むディスク以外) を GPT に変換します。

heat_template_version: 2014-10-16

description: >
  Wipe and convert all disks to GPT (except the disk containing the root file system)

resources:
  userdata:
    type: OS::Heat::MultipartMime
    properties:
      parts:
      - config: {get_resource: wipe_disk}

  wipe_disk:
    type: OS::Heat::SoftwareConfig
    properties:
      config: {get_file: wipe-disk.sh}

outputs:
  OS::stack_id:
    value: {get_resource: userdata}
````

This Heat template makes reference to a Bash script called `wipe-disk.sh`. This script contains your procedure to wipe the non-root disks. The following script is an example of `wipe-disk.sh` that wipes all disks except for the root disk:
````
#!/bin/bash
if [[ `hostname` = *"ceph"* ]]
then
  echo "Number of disks detected: $(lsblk -no NAME,TYPE,MOUNTPOINT | grep "disk" | awk '{print $1}' | wc -l)"
  for DEVICE in `lsblk -no NAME,TYPE,MOUNTPOINT | grep "disk" | awk '{print $1}'`
  do
    ROOTFOUND=0
    echo "Checking /dev/$DEVICE..."
    echo "Number of partitions on /dev/$DEVICE: $(expr $(lsblk -n /dev/$DEVICE | awk '{print $7}' | wc -l) - 1)"
    for MOUNTS in `lsblk -n /dev/$DEVICE | awk '{print $7}'`
    do
      if [ "$MOUNTS" = "/" ]
      then
        ROOTFOUND=1
      fi
    done
    if [ $ROOTFOUND = 0 ]
    then
      echo "Root not found in /dev/${DEVICE}"
      echo "Wiping disk /dev/${DEVICE}"
      sgdisk -Z /dev/${DEVICE}
      sgdisk -g /dev/${DEVICE}
    else
      echo "Root found in /dev/${DEVICE}"
    fi
  done
fi

環境内に Heat テンプレートを追加するには、storage-environment.yaml ファイルにテンプレートを NodeUserData リソースとして登録します。

resource_registry:
  OS::TripleO::NodeUserData: /home/stack/templates/firstboot/wipe-disks.yaml
重要

このセクションは、専用のジャーナルを使用した Ceph Storage ノードには適用されません。

2.9. オーバークラウドの作成

オーバークラウドの作成には、openstack overcloud deploy コマンドに追加の引数を指定する必要があります。以下に例を示します。

$ openstack overcloud deploy --templates -e /home/stack/templates/storage-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --neutron-network-type vxlan --ntp-server clock.redhat.com

上記のコマンドは、以下のオプションを使用します。

  • --templates: デフォルトの Heat テンプレートコレクションからオーバークラウドを作成します。
  • -e /home/stack/templates/storage-environment.yaml: 別の環境ファイルをオーバークラウドデプロイメントに追加します。この場合は、Ceph Storage の設定を含むストレージ環境ファイルです。
  • --control-scale 3 : コントローラーノードを 3 台にスケーリングします。
  • --compute-scale 3: コンピュートノードを 3 台にスケーリングします。
  • --ceph-storage-scale 3: Ceph Storage ノードを 3 台にスケーリングします。
  • --control-flavor control: 対象のコントローラーノードに特定のフレーバーを使用します。
  • --compute-flavor compute: コンピュートノードに特定のフレーバーを使用します。
  • --ceph-storage-flavor ceph-storage: コンピュートノードに特定のフレーバーを使用します。
  • --neutron-network-type vxlan: ネットワーク種別を neutron に設定します。
  • --ntp-server clock.redhat.com: NTP サーバーを設定します。
注記

オプションの完全な一覧を表示するには、以下を実行します。

$ openstack help overcloud deploy

パラメーターの例については、『Red Hat OpenStack Platform 7 director インストールと使用方法』ガイドの「付録 H. デプロイメントのパラメーター」も参照してください。

オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下を実行します。

$ source ~/stackrc
$ heat stack-list --show-nested

2.10. オーバークラウドへのアクセス

director は、director ホストがオーバークラウドと対話するための設定と認証を行うスクリプトを生成します。このファイル (overcloudrc) は、stack ユーザーのホームディレクトリーに保存されます。このファイルを使用するには、以下のコマンドを実行します。

$ source ~/overcloudrc

これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director ホストとの対話に戻るには、以下のコマンドを実行します。

$ source ~/stackrc

2.11. Ceph Storage ノードの監視

オーバークラウドの作成が完了したら、正しく機能していることを確認するため、Ceph Storage Cluster のステータスをチェックすることを推奨します。これには、director から heat-admin ユーザーとしてコントローラーノードにログインします。

$ nova list
$ ssh heat-admin@192.168.0.25

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

$ sudo ceph health

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

Ceph モニタークォーラムのステータスを確認します。

$ sudo ceph quorum_status

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

全 Ceph OSD が実行中であるかどうかを確認します。

$ ceph osd stat

Ceph Storage Cluster の監視に関する詳しい情報は、『Red Hat Ceph Storage Administration Guide』「Chapter 3. Monitoring」を参照してください。

2.12. Ceph Storage ノードの置き換え

Ceph Storage ノードに障害が発生する可能性があります。このような状況では、データが失われないように、問題のあるノードを無効化してリバランスしてから、オーバークラウドから削除するようにしてください。以下の手順では、Ceph Storage ノードを置き換えるプロセスについて説明します。

注記

以下の手順では、『Red Hat Ceph Storage Administration Guide』からの手順を使用して、手動で Ceph Storage ノードを削除します。Ceph Storage ノードの手動での削除に関する詳しい情報は、『Red Hat Ceph Storage Administration Guide』の「Chapter 15. Removing OSDs (Manual)」を参照してください。

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

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

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

[heat-admin@overcloud-controller-0 ~]$ sudo ceph osd out 0
[heat-admin@overcloud-controller-0 ~]$ sudo ceph osd out 1

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

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

Ceph クラスターのリバランスが完了したら、heat-admin ユーザーとして、問題のある Ceph Storage ノードにログインして、このノードを停止します。

[heat-admin@overcloud-cephstorage-0 ~]$ sudo /etc/init.d/ceph stop osd.0
[heat-admin@overcloud-cephstorage-0 ~]$ sudo /etc/init.d/ceph stop osd.1

これ以上データを受信しないように、CRUSH マップからこの Ceph Storage ノードを削除します。

[heat-admin@overcloud-cephstorage-0 ~]$ sudo ceph osd crush remove osd.0
[heat-admin@overcloud-cephstorage-0 ~]$ sudo ceph osd crush remove osd.1

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

[heat-admin@overcloud-cephstorage-0 ~]$ sudo ceph auth del osd.0
[heat-admin@overcloud-cephstorage-0 ~]$ sudo ceph auth del osd.1

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

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

ノードからログアウトして、stack ユーザーとして director ホストに戻ります。

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

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

[stack@director ~]$ ironic node-list
[stack@director ~]$ ironic node-set-maintenance [UUID] true

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

$ heat stack-list

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

$ nova list

以下のコマンドを実行してスタックからノードを削除し、それに応じてプランを更新します。

$ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE_UUID]
重要

オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e または --environment-file オプションを使用して環境ファイルを再度渡します。

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

director のノードプールに新しいノードを追加して、Ceph Storage ノードとしてデプロイします。--ceph-storage-scale を使用して、オーバークラウド内の合計 Ceph Storage ノード数を定義します。たとえば、3 つのノードから構成されるクラスターから問題のあるノードを削除して置き換える場合は、--ceph-storage-scale 3 を使用して、Ceph Storage ノードの数を元の値に戻します。

$ openstack overcloud deploy --templates --ceph-storage-scale 3 -e [ENVIRONMENT_FILES]
重要

オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで -e または --environment-file オプションを使用して環境ファイルを再度渡します。

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

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

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

osdmap セクションの値が、クラスターに設定するノード数と一致していることを確認します。

エラーの発生した Ceph Storage ノードが新規ノードに置き換えられました。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る