Language:
Format:

デプロイメントガイド

Red Hat Hyperconverged Infrastructure for Cloud 13

Red Hat Hyperconverged Infrastructure for Cloud Solution のデプロイ

概要

このドキュメントでは、Red Hat OpenStack Platform 13 および Red Hat Ceph Storage 3 を使用して、AMD64 および Intel 64 のアーキテクチャーで実行している Red Hat Hyperconverged Infrastructure for Cloud ソリューションをデプロイする手順について説明します。

第1章 Red Hat Hyperconverged Infrastructure for Cloud ソリューションの紹介

Red Hat Hyperconverged Infrastructure (RHHI) for Cloud ソリューションは、幅広いソフトウェア定義の RHHI ソリューションの一部です。RHHI Cloud ソリューションは、Red Hat OpenStack Platform (RHOSP) 13 および Red Hat Ceph Storage (RHCS) 3 テクノロジーを 1 つの製品に統合し、3 つの目的を達成します。

RHOSP および RHCS のデプロイメントを簡素化します。
より予測可能なパフォーマンスエクスペリエンスを提供します。
それぞれのサービスを同じノードにコロケートすることで、RHOSP と RHCS のエントリーのコストを軽減します。

RHHI Cloud のコロケーションシナリオは以下のとおりです。

同じノード上の RHOSP コントローラーと RHCS Monitor サービス。
同じノード上の RHOSP Nova Compute および RHCS Object Storage Daemon (OSD)サービス。

デプロイメントワークフローの選択

Red Hat Hyperconverged Infrastructure for Cloud のデプロイには、Red Hat OpenStack Platform Director Web インターフェイスまたはコマンドラインインターフェイスのいずれかを選択できます。これは基本的なデプロイメントワークフローです。

RHHI Cloud Deployment Guide Workflow 459706 1017 JCS

関連情報

詳細は、Red Hat OpenStack Director を使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイメントセクションを参照してください。
詳細は、コマンドラインインターフェイスを使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイセクションを参照してください。

第2章 Red Hat Hyperconverged Infrastructure for Cloud 要件の確認

技術的には、Red Hat Hyperconverged Infrastructure for Cloud ソリューションをデプロイする前に、3 つの中核となる要件を確認する必要があります。

2.1. 前提条件

ハードウェア要件を確認します。
ソフトウェア要件を確認します。
ネットワーク設定を確認します。

2.2. Red Hat Hyperconverged Infrastructure for Cloud ハードウェア要件

ハイパーコンバージドインフラストラクチャーの実装は、さまざまなハードウェア設定を反映します。Red Hat は、ハードウェアを検討する際に、以下の最小値を推奨します。

CPU: コントローラーノード/モニターノードの場合は、デュアルソケット、8 コア CPU を使用します。コンピュート/OSD ノードの場合は、NVMe ストレージメディアを使用するノードにデュアルソケット、14 コア CPU、SAS/SATA SSD を使用するノードにデュアルソケット 10 コア CPU を使用します。
RAM: 常駐 Nova 仮想マシンのワークロードに必要な 2 倍の RAM を設定します。
OSD ディスク: 汎用ワークロードには 7200 RPM のエンタープライズ HDD を使用し、IOPS 集約型ワークロードには NVMe SSD を使用します。
ジャーナルディスク: 汎用ワークロードには SAS/SATA SSD、IOPS 集約型ワークロードには NVMe SSD を使用します。
ネットワーク: Red Hat Ceph Storage (RHCS)ノードに 2 つの 10GbE NIC を使用します。また、Nova 仮想マシンのワークロード要件を満たすには、専用の NIC を使用します。詳細は、ネットワーク要件 を参照してください。

表2.1 ノードの最小数量

Qty.	Role	物理/仮想
1	Red Hat OpenStack Platform director (RHOSP-d)	次のいずれかになります*
3	RHOSP コントローラーと RHCS Monitor	物理的
3	RHOSP Compute & RHCS OSD	物理的

注記

RHOSP-d ノードは、小規模なデプロイメント用に仮想化できます。つまり、合計容量は 20TB 未満です。ソリューションのデプロイメントが容量 20TB を超える場合、Red Hat では RHOSP-d ノードが物理ノードであることを推奨しています。ハイパーコンバージドのコンピュートノード/ストレージノードを最初にデプロイしたり、後で追加したりできます。

重要

Red Hat は、複数のデータセンターラック(30 ノード)にまたがるデプロイメントに、スタンドアロンのコンピュートノードおよびストレージノードを使用することを推奨します。

2.3. Red Hat Hyperconverged Infrastructure for Cloud ネットワーク要件

Red Hat は、さまざまなトラフィックロールを提供するために、少なくとも 5 つのネットワークを使用することを推奨します。

Red Hat Ceph Storage: Ceph Monitor ノードはパブリックネットワークを使用します。プライベートストレージクラスターネットワークが存在しない場合、Ceph OSD はパブリックネットワークを使用します。必要に応じて、OSD はプライベートストレージクラスターネットワークを使用して、レプリケーション、ハートビート、およびバックフィルに関連付けられたトラフィックを処理し、パブリックネットワークを I/O 専用にしておくことができます。Red Hat は、大規模なデプロイメントにクラスターネットワークを使用することを推奨します。Compute ロールには、このネットワークへのアクセスが必要です。
外部: Red Hat OpenStack Platform director (RHOSP-d)は、外部ネットワークを使用してオーバークラウドのソフトウェア更新をダウンロードし、オーバークラウドの Operator はこれを使用して RHOSP-d を使用してオーバークラウドを管理します。テナントサービスが予約済みの Floating IP アドレス経由で接続を確立する場合、コントローラーは外部ネットワークを使用してトラフィックをインターネットにルーティングします。オーバークラウドユーザーは、外部ネットワークを使用してオーバークラウドにアクセスします。
OpenStack Internal API: OpenStack は、パブリック向け API エンドポイントとプライベート API エンドポイントの両方を提供します。これは、プライベートエンドポイント用の分離ネットワークです。
OpenStack テナントネットワーク: OpenStack テナントは、このネットワーク上に VLAN または VXLAN により実装されるプライベートネットワークを作成します。
Red Hat OpenStack Platform Director のプロビジョニング: Red Hat OpenStack Platform director は、このネットワークから DHCP および PXE サービスを提供し、ベアメタルからオーバークラウドノードにオペレーティングシステムやその他のソフトウェアをインストールします。Red Hat OpenStack Platform director はこのネットワークを使用してオーバークラウドノードを管理し、クラウドオペレーターは必要に応じて ssh でオーバークラウドノードに直接アクセスするためにこのネットワークを使用します。このネットワークプロビジョニングから PXE ブートするようにオーバークラウドノードを設定する必要があります。

図2.1 ネットワークの分離図

注記

NIC は、2 つの物理 NIC の論理ボンディングになります。各ネットワークを同じインターフェイスにトランク接続する必要はありません。

2.4. Red Hat Hyperconverged Infrastructure for Cloud ソフトウェア要件の確認

ノードが必要なソフトウェアリポジトリーにアクセスできることを確認します。Red Hat Hyperconverged Infrastructure (RHHI) for Cloud ソリューションでは、適切に機能させるには、特定のソフトウェアパッケージをインストールする必要があります。

前提条件

有効な Red Hat Hyperconverged Infrastructure for Cloud サブスクリプションがある。
ノードへの root レベルのアクセス。

手順

任意のノードで、利用可能なサブスクリプションを確認します。
```
# subscription-manager list --available --all --matches="*OpenStack*"
```

関連情報

必要なソフトウェアリポジトリーについては、Red Hat Hyperconverged Infrastructure for Cloud 必須リポジトリーセクションを参照してください。

2.5. 関連情報

詳細は、Red Hat Ceph Storage ハードウェアガイドを参照してください。

第3章アンダークラウドのデプロイ

管理者としてアンダークラウドをデプロイすることができます。これにより、ユーザーは Red Hat OpenStack Platform director インターフェイスを使用してオーバークラウドをデプロイし、管理することができます。

3.1. 前提条件

有効な Red Hat Hyperconverged Infrastructure for Cloud サブスクリプションがある。
Red Hat のコンテンツ配信ネットワーク(CDN)から Red Hat のソフトウェアリポジトリーにアクセスできる。

3.2. デプロイメント間の Ironic のディスククリーニングについて

Ironic のディスククリーニング機能を有効にすると、そのノードがデプロイメントで再び利用可能になる前に、ノード上の全ディスクからすべてのデータが完全に削除されます。

Ironic のディスククリーニング機能を有効にする前に考慮すべき 2 つのファクトがあります。

director が Ceph をデプロイすると、ceph-disk コマンドを使用して各 OSD を準備します。ceph-disk が OSD を準備する前に、新規 OSD をホストするディスクに古い OSD からのデータがあるかどうかを確認し、存在する場合は、そのデータを上書きしないようにディスクの準備に失敗します。これは安全機能として動作し、データが失われないようにします。
director でデプロイメントに失敗し、オーバークラウドが削除された後に繰り返されると、デフォルトでは以前のデプロイメントからのデータはサーバーディスク上に置かれます。このデータにより、ceph-disk コマンドがどのように動作するかにより、繰り返されるデプロイメントが失敗する可能性があります。

注記

オーバークラウドノードが誤って削除され、ディスクのクリーニングが有効になっている場合は、データが削除され、Red Hat OpenStack Platform director でノードを再構築して環境に戻すことしかできません。

3.3. アンダークラウドのインストール

アンダークラウドをインストールするには、いくつかのステップを完了する必要があります。以下の手順では、アンダークラウドとして Red Hat OpenStack Platform director (RHOSP-d) をインストールします。インストール手順の概要を以下に示します。

インストールユーザーを作成します。
テンプレートとイメージのディレクトリーを作成する
RHOSP-d ノード名を確認/設定します。
RHOSP-d ノードを登録します。
RHOSP-d ソフトウェアをインストールします。
RHOSP-d ソフトウェアを設定します。
オーバークラウドのディスクイメージを取得してインポートします。
アンダークラウドのサブネットに DNS サーバーを設定します。

前提条件

Red Hat のコンテンツ配信ネットワーク(CDN)から Red Hat のソフトウェアリポジトリーにアクセスできる。
Red Hat OpenStack Platform director (RHOSP-d)ノードへの root アクセスがある。

手順

RHOSP-d のインストールには、インストールを行うために sudo 権限を持つ root 以外のユーザーが必要です。
1. stack という名前のユーザーを作成します。
```
[root@director ~]# useradd stack
```
2. stack のパスワードを設定します。プロンプトが表示されたら、新しいパスワードを入力します。
```
[root@director ~]# passwd stack
```
3. stack ユーザーの sudo アクセスを設定します。
```
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@director ~]# chmod 0440 /etc/sudoers.d/stack
```
4. stack ユーザーに切り替えます。
```
[root@director ~]# su - stack
```
  RHOSP-d のインストールは stack ユーザーとして行われます。
stack ユーザーのホームディレクトリーに、2 つの新規ディレクトリーを作成します。1 つは templates と、もう 1 つの名前付き images です。
```
[stack@director ~]$ mkdir ~/images
[stack@director ~]$ mkdir ~/templates
```
これらのディレクトリーは、後でオーバークラウド環境を作成するのに使用するシステムイメージファイルと Heat テンプレートファイルを整理します。
インストールおよび設定プロセスには、/etc/hosts ファイルのエントリーとともに完全修飾ドメイン名 (FQDN) が必要です。
1. RHOSP-d ノードのホスト名を確認します。
```
[stack@director ~]$ hostname -f
```
2. 必要に応じてホスト名を設定します。
```
sudo hostnamectl set-hostname FQDN_HOST_NAME
sudo hostnamectl set-hostname --transient FQDN_HOST_NAME
```
  以下を置き換えます。
  FQDN_HOST_NAME は、RHOSP-d ノードの完全修飾ドメイン名 (FQDN) に置き換えます。
  例
  
  [stack@director ~]$ sudo hostnamectl set-hostname director.example.com [stack@director ~]$ sudo hostnamectl set-hostname --transient director.example.com
3. RHOSP-d ノード名のエントリーを /etc/hosts ファイルに追加します。/etc/hosts ファイルに以下の行を追加します。
```
sudo echo "127.0.0.1 FQDN_HOST_NAME SHORT_HOST_NAME localhost localhost.localdomain localhost4 localhost4.localdomain4" >> /etc/hosts
```
  以下を置き換えます。
  FQDN_HOST_NAME は、RHOSP-d ノードの完全修飾ドメイン名に置き換えます。
  SHORT_HOST_NAME は、RHOSP-d ノードの短いドメイン名に置き換えます。
  例
  
  [stack@director ~]$ sudo echo "127.0.0.1 director.example.com director localhost localhost.localdomain localhost4 localhost4.localdomain4" >> /etc/hosts

Red Hat コンテンツ配信ネットワーク (CDN) に RHOSP-d ノードを登録し、Red Hat Subscription Manager を使用して必要な Red Hat ソフトウェアリポジトリーを有効にします。

RHOSP-d ノードを登録します。
```
[stack@director ~]$ sudo subscription-manager register
```
プロンプトが表示されたら、承認されたカスタマーポータルのユーザー名とパスワードを入力します。

RHOSP エンタイトルメントの有効な Pool ID を検索します。

[stack@director ~]$ sudo subscription-manager list --available --all --matches="*Hyperconverged*"

出力例

Subscription Name:   Red Hat Hyperconverged Infrastructure for Cloud
Provides:            Red Hat OpenStack
                     Red Hat Ceph Storage
SKU:                 RS00160
Contract:            1111111
Pool ID:             a1b2c3d4e5f6g7h8i9
Provides Management: Yes
Available:           1
Suggested:           1
Service Level:       Self-Support
Service Type:        L1-L3
Subscription Type:   Standard
Ends:                05/27/2018
System Type:         Virtual

前の手順の Pool ID を使用して、RHOSP のエンタイトルメントをアタッチします。
```
[stack@director ~]$ sudo subscription-manager attach --pool=POOL_ID
```
以下を置き換えます。
POOL_ID は、直前の手順の有効なプール ID に置き換えます。
例

[stack@director ~]$ sudo subscription-manager attach --pool=a1b2c3d4e5f6g7h8i9

デフォルトのソフトウェアリポジトリーを無効にし、必要なソフトウェアリポジトリーを有効にします。

[stack@director ~]$ sudo subscription-manager repos --disable=*
[stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-13-rpms

必要に応じて、ベースシステムソフトウェアを最新のパッケージバージョンに更新し、RHOSP-d ノードを再起動します。
```
[stack@director ~]$ sudo yum update
[stack@director ~]$ sudo reboot
```
ノードが完全に起動し、実行されるのを待ってから次のステップに進みます。

すべての RHOSP-d ソフトウェアパッケージをインストールします。
```
[stack@director ~]$ sudo yum install python-tripleoclient ceph-ansible
```

RHOSP-d ソフトウェアを設定します。

Red Hat は、使用する基本的なアンダークラウド設定テンプレートを提供しています。undercloud.conf.sample ファイルを undercloud.conf という名前の stack ユーザーのホームディレクトリーにコピーします。
```
[stack@director ~]$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
```

アンダークラウド設定テンプレートには、[DEFAULT] と [auth] の 2 つのセクションが含まれます。undercloud.conf ファイルを開いて編集します。undercloud_hostname を RHOSP-d ノード名で編集します。パラメーターの前に # を削除して、undercloud.conf ファイルの [DEFAULT] セクションの下にある以下のパラメーターのコメントを解除します。このソリューションのネットワーク設定に必要な適切な値でパラメーター値を編集します。

パラメーター	ネットワーク	値の編集	値の例
`local_ip`	プロビジョニング	はい	`192.0.2.1/24`
`network_gateway`	プロビジョニング	はい	`192.0.2.1`
`undercloud_public_vip`	プロビジョニング	はい	`192.0.2.2`
`undercloud_admin_vip`	プロビジョニング	はい	`192.0.2.3`
`local_interface`	プロビジョニング	はい	`eth1`
`network_cidr`	プロビジョニング	はい	`192.0.2.0/24`
`masquerade_network`	プロビジョニング	はい	`192.0.2.0/24`
`dhcp_start`	プロビジョニング	はい	`192.0.2.5`
`dhcp_end`	プロビジョニング	はい	`192.0.2.24`
`inspection_interface`	プロビジョニング	いいえ	`br-ctlplane`
`inspection_iprange`	プロビジョニング	はい	`192.0.2.100,192.0.2.120`
`inspection_extras`	該当なし	はい	`true`
`inspection_runbench`	該当なし	はい	`false`
`inspection_enable_uefi`	該当なし	はい	`true`

undercloud.conf ファイルの編集後に変更を保存します。これらの設定パラメーターの詳細は、アンダークラウド設定パラメーターを参照してください。

注記

オーバークラウドノードを再び目的にする場合には、Ironic のディスククリーニング機能を有効にすることを検討してください。詳細は、デプロイメント間の Ironic ディスククリーニングを理解するセクションを参照してください。

RHOSP-d 設定スクリプトを実行します。
```
[stack@director ~]$ openstack undercloud install
```
注記
このスクリプトが完了するまで数分かかります。このスクリプトは、追加のソフトウェアパッケージをインストールし、2 つのファイルを生成します。
undercloud-passwords.conf
director サービスの全パスワード一覧
stackrc
director のコマンドラインツールへアクセスできるようにする初期化変数セット
設定スクリプトがすべての RHOSP サービスを開始および有効化していることを確認します。
```
[stack@director ~]$ sudo systemctl list-units openstack-*
```
設定スクリプトにより、stack ユーザーにすべてのコンテナー管理コマンドにアクセスできます。stack ユーザーの権限をリフレッシュします。
```
[stack@director ~]$ exec su -l stack
```
RHOSP-d コマンドラインツールを使用するように stack ユーザーの環境を初期化します。
```
[stack@director ~]$ source ~/stackrc
```
コマンドプロンプトが変更されます。これは、OpenStack コマンドが認証してアンダークラウドに対して実行されることを示します。
例
```
(undercloud) [stack@director ~]$
```

RHOSP-d では、オーバークラウドノードをプロビジョニングするために複数のディスクイメージが必要です。

rhosp-director-images および rhosp-director-images-ipa ソフトウェアパッケージをインストールして、これらのディスクイメージを取得します。
```
(undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa
```

アーカイブファイルを stack ユーザーのホームディレクトリー内の images ディレクトリーに展開します。

(undercloud) [stack@director ~]$ cd ~/images
(undercloud) [stack@director ~]$ for x in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar ; do tar -xvf $x ; done

ディスクイメージを RHOSP-d にインポートします。

(undercloud) [stack@director ~]$ openstack overcloud image upload --image-path /home/stack/images/

インポートしたディスクイメージの一覧を表示するには、以下のコマンドを実行します。

(undercloud) [stack@director ~]$ openstack image list

Image Name	イメージタイプ	Image Description
`bm-deploy-kernel`	デプロイメント	システムのプロビジョニングとデプロイに使用されるカーネルファイル。
`bm-deploy-ramdisk`	デプロイメント	システムのプロビジョニングとデプロイに使用する ramdisk ファイル。
`overcloud-full-vmlinuz`	オーバークラウド	ノードのディスクに書き込まれるベースシステムに使用されるカーネルファイル。
`overcloud-full-initrd`	オーバークラウド	ノードのディスクに書き込まれるベースシステムに使用する ramdisk ファイル。
`overcloud-full`	オーバークラウド	ノードのディスクに書き込まれるベースシステムに必要な残りのソフトウェア。

注記

openstack image list コマンドは、イントロスペクション PXE ディスクイメージを表示しません。イントロスペクション PXE ディスクイメージが /httpboot/ ディレクトリーにコピーされます。

(undercloud) [stack@director images]$ ls -l /httpboot
total 341460
-rwxr-xr-x. 1 root              root                5153184 Mar 31 06:58 agent.kernel
-rw-r--r--. 1 root              root              344491465 Mar 31 06:59 agent.ramdisk
-rw-r--r--. 1 ironic-inspector  ironic-inspector        337 Mar 31 06:23 inspector.ipxe

オーバークラウドノードのホスト名が解決されるように DNS サーバーを設定します。

サブネットを一覧表示します。

(undercloud) [stack@director ~]$ openstack subnet list

アンダークラウドの neutron サブネットを使用してネームサーバーを定義します。
```
openstack subnet set --dns-nameserver DNS_NAMESERVER_IP SUBNET_NAME_or_ID
```
以下を置き換えます。
DNS_NAMESERVER_IP は、DNS サーバーの IP アドレスに置き換えます。
SUBNET_NAME_or_ID は、neutron サブネット名または ID に置き換えます。
例

(undercloud) [stack@director ~]$ openstack subnet set --dns-nameserver 192.0.2.4 local-subnet

注記
各ネームサーバーに --dns-nameserver DNS_NAMESERVER_IP オプションを再利用します。

サブネットの詳細を表示して、DNS サーバーを確認します。

(undercloud) [stack@director ~]$ openstack subnet show SUBNET_NAME_or_ID

以下を置き換えます。

SUBNET_NAME_or_ID は、neutron サブネット名または ID に置き換えます。

例

(undercloud) [stack@director ~]$ openstack subnet show local-subnet
+-------------------+-----------------------------------------------+
| Field             | Value                                         |
+-------------------+-----------------------------------------------+
| ...               |                                               |
| dns_nameservers   | 192.0.2.4                                     |
| ...               |                                               |
+-------------------+-----------------------------------------------+

関連情報

undercloud.conf ファイルにあるすべてのアンダークラウド設定パラメーターについての詳しい情報は、RHOSP director のインストールと使用方法の Director の設定セクションを参照してください。

3.4. オーバークラウドをデプロイする前にディスクをクリーンアップするためのアンダークラウド設定

オーバークラウドをデプロイする前に、アンダークラウド設定ファイルを更新してディスクをクリーンアップします。

警告

この機能を有効にすると、オーバークラウドのデプロイメントでプロビジョニングされる前に、すべてのディスクのすべてのデータが破棄されます。

前提条件

アンダークラウドのインストール

手順

オーバークラウドをデプロイする前にディスクをクリーニングする方法には、自動または手動の 2 つのオプションがあります。
1. 最初のオプションは、undercloud.conf ファイルを編集してディスクを自動的にクリーニングし、以下の行を追加します。
```
clean_nodes = True
```
  注記
  ベアメタルプロビジョニングサービスは、wipefs --force --all コマンドを実行してクリーニングを実行します。
警告
この機能を有効にすると、オーバークラウドのデプロイメントでプロビジョニングされる前に、すべてのディスクのすべてのデータが破棄されます。また、これにより、初回のイントロスペクション後および各デプロイメントの前に追加の電源サイクルが実行されます。
1. 2 つ目のオプションは、自動クリーニングをオフにして、各 Ceph ノードに対して以下のコマンドを実行します。
```
[stack@director ~]$ openstack baremetal node manage NODE
[stack@director ~]$ openstack baremetal node clean NODE --clean-steps '[{"interface": "deploy", "step": "erase_devices_metadata"}]'
[stack@director ~]$ openstack baremetal node provide NODE
```
  以下を置き換えます。
  NODE は、Ceph ホスト名に置き換えます。

第4章 Red Hat OpenStack Platform Director を使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイメント

技術者として、Red Hat OpenStack Platform director インターフェイスを使用して、Red Hat Hyperconverged Infrastructure for Cloud ソリューションをデプロイして管理できます。また、Red Hat OpenStack Platform と Red Hat Ceph Storage との間でリソースの競合が発生しないように、リソースの分離について基本的に理解しておく必要があります。

4.1. 前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

4.2. Red Hat OpenStack Platform director を使用したオーバークラウドプランのエクスポート

以下の手順では、OpenStack Platform director を使用してデプロイメントプランをエクスポートします。デフォルトのデプロイメントプランには、一般的かつエクスポート可能なオーバークラウド設定が含まれています。

前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

手順

アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーに入力します。
注記
SSL を使用していない場合は、アンダークラウドの URL はポート 3000 を使用する必要があります。例: http://192.168.0.4:3000
正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェイスにログインします。
注記
デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。
```
[stack@director ~]$ sudo hiera admin_password
```
Plans タブで、オーバークラウド プランからドロップダウンメニューを選択し、Export を選択します。
Downloadボタンをクリックします
これにより、圧縮された tarball ファイルがローカルのハードドライブにダウンロードされます。これには、すべてのプランファイルが含まれます。
重要
tarball ファイルに含まれるファイルを追加または変更する必要がある場合は、tarball ファイルをインポートする前に、以下のように tarball ファイルを再作成する必要があります。
例
```
tar -czf my-deployment-plan.tar.gz -C my-deployment-plan-local-files/ .
```
注記
現在、OpenStack Platform director インターフェイスでは、カスタムネットワーク設定などのプランの事前設定をサポートしていません。ファイルを直接編集して事前に設定を手動で行う必要があります。

4.3. Red Hat OpenStack Platform director を使用したオーバークラウドプランのインポート

以下の手順では、以前にエクスポートされた OpenStack Platform director を使用してデプロイメントプランをインポートします。

前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

手順

アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーに入力します。
注記
SSL を使用していない場合は、アンダークラウドの URL はポート 3000 を使用する必要があります。例: http://192.168.0.4:3000
正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェイスにログインします。
注記
デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。
```
[stack@director ~]$ sudo hiera admin_password
```
Plans タブで、Import Plan ボタンを選択します。
Plan Name と入力し、Choose File ボタンをクリックします。tarball ファイルの場所を参照し、インポート用に選択します。ファイルを選択したら、Upload Files and Create Plan ボタンをクリックします。

4.4. Red Hat OpenStack Platform director を使用したオーバークラウドのデプロイ

以下の手順では、Red Hat OpenStack Platform director を使用してオーバークラウドをデプロイします。

前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

手順

アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーに入力します。
注記
SSL を使用していない場合は、アンダークラウドの URL にポート 3000 を含める必要があります。例: http://192.168.0.4:3000
正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェイスにログインします。
注記
デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。
```
[stack@director ~]$ sudo hiera admin_password
```
デフォルトの overcloud プランを選択するか、Import Plan を選択します。
プランのインポートに関する詳細は、「Red Hat OpenStack Platform director を使用したオーバークラウドプランのインポート」を参照してください。
プラン設定ページから、登録したノードを追加してハードウェアを準備します。
図4.1 プラン設定ページの例
1. ノードの登録には、Register Nodesボタンをクリックします。
2. Add New Node ボタンをクリックします。
  または、instackenv.json ホスト定義ファイルをカスタマイズし、アップロードしてノードを準備することができます。カスタムの instackenv.json ホスト定義ファイルを作成するには、「ハードウェアの登録およびイントロスペクション」および「ルートデバイスの設定」を参照してノードを準備します。
3. 登録ノードページで、小規模な赤いアスタリスクで表示されるすべての必須フィールドに入力します。
4. すべての必須フィールドを入力したら、Register Node ボタンをクリックします。
5. ノードが登録されたら、ノードを選択し、Introspect Nodes ボタンをクリックします。
6. イントロスペクションが完了したら、ノードを選択し、Provide Nodes ボタンをクリックします。
プラン設定ページから、デプロイメント設定を編集します。
1. Edit Configuration ボタンをクリックします。
2. Overall Settings タブで、General Deployment Options セクションをクリックし、Docker を介して HA サービス、Containerized Deployment、および Default Container Images を有効にします。
3. Overall Settings タブで、Storage セクションをクリックし、Ceph Storage Backend を有効にします。
  Save Changes ボタンをクリックします。
4. Parameters タブをクリックします。 Ceph Storage Backend セクションをクリックし、追加の Ceph パラメーターを編集します。
  CephAnsibleExtraConfig フィールドを以下の値で更新します。
```
{"ceph_osd_docker_memory_limit": "5g", "ceph_osd_docker_cpu_limit": 1, "ceph_mds_docker_memory_limit": "4g", "ceph_mds_docker_cpu_limit": 1}
```
  CephConfigOverrides フィールドを以下の値で更新します。
```
{"osd_recovery_op_priority": 3, "osd_recovery_max_active": 3, "osd_max_backfills": 1}
```
  CephConfigOverrides フィールドを以下の値で更新します。
```
{"osd_recovery_op_priority": 3, "osd_recovery_max_active": 3, "osd_max_backfills": 1}
```
  CephPoolDefaultSize の値を 3 に設定します。
  CephAnsibleDisksConfig フィールドをディスクリストで更新します。
  例
```
{"devices":["/dev/sda","/dev/sdb","/dev/sdc","/dev/sdd","/dev/sde","/dev/sdf","/dev/sdg","/dev/sdh","/dev/sdi","/dev/sdj","/dev/sdk","/dev/sdl"],"dedicated_devices":["/dev/sdm","/dev/sdm","/dev/sdm","/dev/sdm","/dev/sdn","/dev/sdn","/dev/sdn","/dev/sdn","/dev/sdo","/dev/sdo","/dev/sdo","/dev/sdo"],"journal_size":5120}
```
  注記
  このディスクリストは、OSD として使用されているブロックデバイス (devices) と、OSD ジャーナルとして専用のブロックデバイス (dedicated_devices) 用です。詳細は、「Red Hat Ceph Storage パラメーターの設定」を参照してください。
5. Save And Close ボタンをクリックします。
6. プラン設定ページに戻ると、保存された設定変更は Specify Deployment Configuration のステップの下に表示されます。
Manage Roles リンクをクリックして、ハイパーコンバージドノードのロールを設定します。
1. 、CephStorage 、および コンピュート ロールをクリックして BlockStorage の選択を解除します
2. ComputeHCI ロールをクリックして選択します。
3. プラン設定ページに戻り、逆引きアイコンをクリックして Compute HCI ロールを設定します。
4. パラメーター タブで、次のパラメーターを更新します。
  - 計算されたリソース割り当て値を含む ExtraConfig フィールド。
    適切な値を計算する方法は、付録E Nova 確保メモリーと CPU 割り当ての手動チューニング を参照してください。
  - ComputeHCIIPs フィールドには、環境に関連するすべての IP アドレスが含まれます。
    例
    
    {"storage_mgmt":["172.16.2.203","172.16.2.204","172.16.2.205"],"storage":["172.16.1.203","172.16.1.204","172.16.1.205"],"tenant":["192.168.3.203","192.168.3.204","192.168.3.205"],"internal_api":["192.168.2.203","192.168.2.204","192.168.2.205"]}
  - OvercloudComputeHCIFlavor フィールドに、以下の値を指定します。
    osd-compute
  - ComputeHCISchedulerHints フィールドには、以下の値を指定します。
    {"capabilities:node":"hci-%index%"}
5. Save And Close ボタンをクリックします。
6. プラン設定ページに戻り、逆引きアイコンをクリックして Controller ロールを設定します。
7. Parameters タブで、ControllerIPs フィールドを関連する IP アドレスで更新します。
  例
```
{"storage_mgmt":["172.16.2.200","172.16.2.201","172.16.2.202"],"storage":["172.16.1.200","172.16.1.201","172.16.1.202"],"tenant":["192.168.3.200","192.168.3.201","192.168.3.202"],"internal_api":["192.168.2.200","192.168.2.201","192.168.2.202"]}
```
8. Services タブの Ntp セクションの NtpServer フィールドを該当する NTP サーバー名で更新します。
9. Save And Close ボタンをクリックします。
各ロールに、環境に必要なノード数を割り当てます。
図4.2 例
プラン設定ページから、Edit Configuration ボタンをクリックします。
ネットワーク設定セクションをクリックして Network Configuration を編集し、Network Isolation を選択します。
1. NIC 設定テンプレートの 1 つを選択するか、カスタムプランを使用します。
  
  環境内で NIC をカスタマイズするには、まずプランをエクスポートする必要があります。
  プランのエクスポート方法については、「Red Hat OpenStack Platform director を使用したオーバークラウドプランのエクスポート」を参照してください。
  1. プランの tarball ファイルをダウンロードし、必要な追加または変更をローカルで行います。
    例
  2. プランの tarball ファイルを更新したら、ドロップダウンメニューをクリックし、Edit を選択します。
  3. プランをインポートします。Plan Name と入力し、Choose File ボタンをクリックします。tarball ファイルの場所を参照し、インポート用に選択します。ファイルを選択したら、Upload Files and Create Plan ボタンをクリックします。
  4. Edit Configuration ボタンをクリックします。
  5. Overall Settings タブで、Other セクションをクリックします。
  6. Others セクションを選択し、カスタムテンプレートを追加します。
  7. ファイルリストから新規ファイルまたは変更されたファイルを選択します。
    例
  8. Parameters タブをクリックして、適切な値を更新します。
これでプランをデプロイします。プラン設定ページから Validate and Deploy ボタンをクリックして、オーバークラウドプランをデプロイします。
オーバークラウドのデプロイメントが完了するまで待ちます。

4.5. 関連情報

リソース分離の詳細は、付録E Nova 確保メモリーと CPU 割り当ての手動チューニング を参照してください。

第5章コマンドラインインターフェイスを使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイ

コマンドラインインターフェイスを使用して、Red Hat Hyperconverged Infrastructure for Cloud ソリューションをデプロイして管理できます。

5.1. 前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

5.2. コマンドラインインターフェイスを使用したオーバークラウドのデプロイ前のノードの準備

技術的には、オーバークラウドをデプロイする前に、アンダークラウドが環境で使用されているハードウェアを理解する必要があります。

注記

Red Hat OpenStack Platform director (RHOSP-d)は、アンダークラウドとしても知られています。

5.2.1. 前提条件

すべての要件を満たしていることを確認します。
アンダークラウドのインストール

5.2.2. ハードウェアの登録およびイントロスペクション

Red Hat OpenStack Platform director (RHOSP-d) は、各ノードでイントロスペクションプロセスを実行し、ノードのハードウェアに関するデータを収集します。このイントロスペクションデータは RHOSP-d ノードに保存され、ベンチマークやルートディスクの割り当てなどのさまざまな目的で使用されます。

前提条件

RHOSP-d ノードのソフトウェアインストールを完了します。
ネットワークインターフェイスカード (NIC) の MAC アドレス。
IPMI ユーザー名およびパスワード

手順

RHOSP-d ノードで、stack ユーザーとして以下の手順を実行します。

osd-compute フレーバーを作成します。

[stack@director ~]$ openstack flavor create --id auto --ram 2048 --disk 40 --vcpus 2 osd-compute
[stack@director ~]$ openstack flavor set --property "capabilities:boot_option"="local" --property "capabilities:profile"="osd-compute" osd-compute

ノードを管理するために Ironic サービスのホスト定義ファイルを作成し、設定します。

instackenv.json ホスト定義ファイルを作成します。
```
[stack@director ~]$ touch ~/instackenv.json
```

以下のテンプレートを使用して、ノード スタンザの角括弧 ({"nodes": []}) の間に各ノードの定義ブロックを追加します。

{
  "pm_password": "IPMI_USER_PASSWORD",
  "name": "NODE_NAME",
  "pm_user": "IPMI_USER_NAME",
  "pm_addr": "IPMI_IP_ADDR",
  "pm_type": "pxe_ipmitool",
  "mac": [
          "NIC_MAC_ADDR"
         ],
  "arch": "x86_64",
  "capabilities": "node:_NODE_ROLE-INSTANCE_NUM_,boot_option:local"
},

以下を置き換えます。

IPMI_USER_PASSWORD と IPMI パスワード。
ノードのわかりやすい名前を持つ NODE_NAME。これはオプションのパラメーターです。
IPMI_USER_NAME は、ノードの電源をオンまたはオフにすることのできる IPMI ユーザー名に置き換えます。
IPMI_IP_ADDR は、IPMI IP アドレスに置き換えます。
PXE ブートを処理するネットワークカードの MAC アドレスを持つ NIC_MAC_ADDR。

NODE_ROLE-INSTANCE_NUM とノードのロール、およびノード番号。このソリューションは、control と osd-compute の 2 つのロールを使用します。

例

{
  "nodes": [
     {
         "pm_password": "AbC1234",
         "name": "m630_slot1",
         "pm_user": "ipmiadmin",
         "pm_addr": "10.19.143.61",
         "pm_type": "pxe_ipmitool",
         "mac": [
             "c8:1f:66:65:33:41"
         ],
         "arch": "x86_64",
          "capabilities": "node:control-0,boot_option:local"
     },
     {
         "pm_password": "AbC1234",
         "name": "m630_slot2",
         "pm_user": "ipmiadmin",
         "pm_addr": "10.19.143.62",
         "pm_type": "pxe_ipmitool",
         "mac": [
             "c8:1f:66:65:33:42"
         ],
         "arch": "x86_64",
          "capabilities": "node:osd-compute-0,boot_option:local"
     },
     ... Continue adding node definition blocks for each node in the initial deployment here.
  ]
}

注記

osd-compute ロールは、後のステップで作成されたカスタムロールです。ノードの配置を予測どおりに制御するには、これらのノードを順番に追加します。以下に例を示します。

[stack@director ~]$ grep capabilities ~/instackenv.json
	 "capabilities": "node:control-0,boot_option:local"
	 "capabilities": "node:control-1,boot_option:local"
	 "capabilities": "node:control-2,boot_option:local"
	 "capabilities": "node:osd-compute-0,boot_option:local"
	 "capabilities": "node:osd-compute-1,boot_option:local"
	 "capabilities": "node:osd-compute-2,boot_option:local"

ノードを Ironic データベースにインポートします。
```
[stack@director ~]$ openstack baremetal import ~/instackenv.json
```
1. openstack baremetal import コマンドが、全ノードで Ironic データベースに投入されていることを確認します。
```
[stack@director ~]$ openstack baremetal node list
```
ベアメタルブートカーネルと RAMdisk イメージをすべてのノードに割り当てます。
```
[stack@director ~]$ openstack baremetal configure boot
```
ノードを起動してハードウェアデータを収集し、その情報を Ironic データベースに保存するには、次のコマンドを実行します。
```
[stack@director ~]$ openstack baremetal introspection bulk start
```
注記
インポートされたノードの数によっては、一括イントロスペクションが完了するまでに時間がかかる場合があります。~/undercloud.conf ファイルで inspection_runbench の値を false に設定すると、一括イントロスペクションプロセスが高速化されますが、sysbench および fio ベンチマークデータを収集しません。これは RHOSP-d に役立つデータになります。
1. すべてのノードでエラーなしにイントロスペクションプロセスが完了したことを確認します。
```
[stack@director ~]$ openstack baremetal introspection bulk status
```

関連情報

ノード識別パラメーターの割り当てについての詳細は、RHOSP Advanced Overcloud カスタマイズガイドのノードの配置を制御するの章を参照してください。

5.2.3. ルートデバイスの設定

Red Hat OpenStack Platform director (RHOSP-d) は、ノードをプロビジョニングするルートディスクを識別する必要があります。デフォルトでは、Ironic は最初のブロックデバイスをイメージ化します。通常、このブロックデバイスは /dev/sda になります。以下の手順に従って、Compute/OSD ノードのディスク設定に従ってルートディスクデバイスを変更します。

以下の手順では、例として以下の Compute/OSD ノードのディスク設定を使用します。

OSD: /dev/[sda, sdb, …, sdl] ブロックデバイスとして表示される 12 x 1TB SAS ディスク
OSD ジャーナル: /dev/[sdm, sdn, sdo] ブロックデバイスとして表示される 3 x 400GB SATA SSD ディスク
オペレーティングシステム: /dev/sdp ブロックデバイスとして提示される RAID1 で設定された 2 x 250GB SAS ディスク

OSD は /dev/sda を使用するため、Ironic は /dev/sdp、RAID 1 ディスクを代わりにルートディスクとして使用します。ハードウェアイントロスペクションプロセス中に、Ironic は World-wide number (WWN) および各ブロックデバイスのサイズを保存します。

前提条件

ハードウェアイントロスペクションの手順を完了します。

手順

RHOSP-d ノードで以下のコマンドのいずれかを実行します。

smallest のルートデバイスを使用するようにルートディスクデバイスを設定します。
```
[stack@director ~]$ openstack baremetal configure boot --root-device=smallest
```

または

ディスクの by-path 名を使用するようにルートディスクデバイスを設定します。

[stack@director ~]$ openstack baremetal configure boot --root-device=disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0

注記

Ironic は、このルートデバイスディレクティブを Ironic のデータベース内のすべてのノードに適用します。

正しいルートディスクデバイスが設定されていることを確認します。
```
openstack baremetal introspection data save NODE_NAME_or_UUID | jq .
```
以下を置き換えます。
NODE_NAME_or_UUID をノードのホスト名または UUID に置き換えます。

関連情報

ノードのルートディスクの定義に関する詳細については、RHOSP Director インストールおよび使用ガイドのセクションを参照してください。

5.2.4. Ironic のディスククリーニングが機能していることの確認

Ironic のディスククリーニング機能が動作しているかどうかを確認するには、ノードの状態を切り替えてから、ノードの状態がクリーニング状態になるかどうかを観察します。

前提条件

アンダークラウドのインストール

手順

ノードの状態を manage に設定します。

openstack baremetal node manage $NODE_NAME

例

[stack@director ~]$ openstack baremetal node manage osdcompute-0

ノードの状態を以下を提供するように設定します。

openstack baremetal node provide NODE_NAME

例

[stack@director ~]$ openstack baremetal node provide osdcompute-0

ノードのステータスを確認します。
```
openstack node list
```

5.2.5. 関連情報

詳細は、RHOSP-d インストールおよび使用ガイドを参照してください。

5.3. コンテナーイメージのソースの設定

技術者はオーバークラウドをコンテナー化できますが、これにはまず、必要なコンテナーイメージを含むレジストリーにアクセスする必要があります。ここでは、レジストリーの準備方法および Red Hat OpenStack Platform 用のコンテナーイメージを使用するためのオーバークラウド設定について説明します。

ユースケースに基づいて、オーバークラウドがレジストリーを使用するように設定する方法は複数あります。

5.3.1. レジストリーメソッド

Red Hat Hyperconverged Infrastructure for Cloud は、以下のレジストリータイプをサポートします。以下のいずれかの方法を選択します。

リモートレジストリー: オーバークラウドは、registry.access.redhat.com から直接コンテナーイメージをプルします。これは、初期設定を生成するための最も簡単な方法です。ただし、それぞれのオーバークラウドノードが Red Hat Container Catalog から各イメージを直接プルするので、ネットワークの輻輳が生じてデプロイメントが遅くなる可能性があります。また、Red Hat Container Catalog にアクセスするためのインターネットアクセスが全オーバークラウドノードに必要です。
ローカルレジストリー: アンダークラウド上にローカルレジストリーを作成し、registry.access.redhat.com からイメージを同期し、オーバークラウドはアンダークラウドからコンテナーイメージをプルします。この方法では、内部にレジストリーを保管することが可能なので、デプロイメントを迅速化してネットワークの輻輳を軽減することができます。ただし、アンダークラウドは基本的なレジストリーとしてのみ機能し、コンテナーイメージのライフサイクル管理は限定されます。

5.3.2. Red Hat OpenStack Platform サービス用の追加のコンテナーイメージの追加

Red Hat Hyperconverged Infrastructure for Cloud は、コアの Red Hat OpenStack Platform サービス以外の追加のサービスを使用します。これらの追加サービスには追加のコンテナーイメージが必要で、対応する環境ファイルでこれらのサービスを有効にします。これらの環境ファイルは、オーバークラウドのコンポーザブルサービスを有効化します。director はこれらのサービスが有効化されていることを認識して、イメージを準備する必要があります。

前提条件

動作中のアンダークラウド

手順

アンダークラウドノードで stack ユーザーとして、openstack overcloud container image prepare コマンドを使用して追加のサービスを追加します。
1. -e オプションを使用して、以下の環境ファイルを追加します。
  - Ceph Storage クラスター: /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
2. Red Hat Ceph Storage の以下の --set オプションを含めます。
  --set ceph_namespace
  Red Hat Ceph Storage コンテナーイメージの名前空間を定義します。
  --set ceph_image
  Red Hat Ceph Storage コンテナーイメージの名前を定義します。イメージ名 rhceph-3-rhel7 を使用します。
  --set ceph_tag
  Red Hat Ceph Storage コンテナーイメージに使用するタグを定義します。--tag-from-label が指定されている場合には、バージョンタグはこのタグから検出が開始されます。

image prepare コマンドを実行します。

例

[stack@director ~]$ openstack overcloud container image prepare \
  ...
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  --set ceph_namespace=registry.access.redhat.com/rhceph \
  --set ceph_image=rhceph-3-rhel7 \
  --tag-from-label {version}-{release} \
  ...

注記

これらのオプションは、openstack overcloud container image prepare コマンドに渡す必要があるその他のオプション (…) に加えて渡されます。

5.3.3. Red Hat レジストリーをリモートレジストリーソースとして使用する方法

Red Hat では、オーバークラウドのコンテナーイメージを registry.access.redhat.com でホストしています。リモートレジストリーからイメージをプルするのは最も簡単な方法です。レジストリーはすでにセットアップされており、プルするイメージの URL と名前空間が必要であるためです。

前提条件

実行中の Red Hat Hyperconverged Infrastructure for Cloud 10 環境。
インターネットへのアクセス。

手順

イメージを直接 registry.access.redhat.com からオーバークラウドデプロイメントにプルするには、イメージパラメーターを指定するための環境ファイルが必要となります。以下のコマンドにより、この環境ファイルが自動的に作成されます。
```
(undercloud) [stack@director ~]$ openstack overcloud container image prepare \
  --namespace=registry.access.redhat.com/rhosp13 \
  --prefix=openstack- \
  --tag-from-label {version}-{release} \
  --output-env-file=/home/stack/templates/overcloud_images.yaml
```
注記
任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
これで、イメージの場所が記載された overcloud_images.yaml 環境ファイルがアンダークラウド上に作成されます。今後のアップグレードとデプロイメントの操作ではすべてこのファイルを追加してください。

関連情報

詳細は、Red Hat Hyperconverged Infrastructure for Cloud 開発ガイド の Red Hat OpenStack Platform サービス用コンテナイメージの追加 セクションを参照してください。

5.3.4. ローカルレジストリーとしてアンダークラウドを使用する方法

アンダークラウド上でローカルレジストリーを設定して、オーバークラウドのコンテナーイメージを保管することができます。この方法は、以下の操作を伴います。

director が registry.access.redhat.com から各イメージをプルする
director がオーバークラウドを作成する
- オーバークラウドの作成中に、ノードが適切なイメージをアンダークラウドからプルする

前提条件

実行中の Red Hat Hyperconverged Infrastructure for Cloud 環境。
インターネットへのアクセス。

手順

イメージをローカルレジストリーにプルするためのテンプレートを作成します。
```
(undercloud) [stack@director ~]$ openstack overcloud container image prepare \
  --namespace=registry.access.redhat.com/rhosp13 \
  --prefix=openstack- \
  --tag-from-label {version}-{release} \
  --output-images-file /home/stack/local_registry_images.yaml
```
- 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
  注記
  上記の openstack overcloud container image prepare コマンドは、registry.access.redhat.com のレジストリーをターゲットにしてイメージの一覧を生成します。この後のステップでは、openstack overcloud container image prepare コマンドで別の値を使用します。
これにより、コンテナーイメージ情報と共に local_registry_images.yaml というファイルが作成されます。local_registry_images.yaml ファイルを使用してイメージをプルします。
```
(undercloud) [stack@director ~]$ sudo openstack overcloud container image upload \
  --config-file  /home/stack/local_registry_images.yaml \
  --verbose
```
注記
コンテナーイメージは、およそ 10 GB のディスク領域を使用します。
ローカルイメージの名前空間を検索します。名前空間は以下のパターンを使用します。
```
<REGISTRY_IP_ADDRESS>:8787/rhosp13
```
アンダークラウドの IP アドレスを使用します。これは undercloud.conf ファイルの local_ip パラメーターで以前に設定していました。または、以下のコマンドで完全な名前空間を取得することもできます。
```
(undercloud) [stack@director ~]$ docker images | grep -v redhat.com | grep -o '^.*rhosp13' | sort -u
```
アンダークラウド上のローカルレジストリーでイメージを使用するためのテンプレートを作成します。以下に例を示します。
```
(undercloud) [stack@director ~]$ openstack overcloud container image prepare \
  --namespace=192.168.24.1:8787/rhosp13 \
  --prefix=openstack- \
  --tag-from-label {version}-{release} \
  --output-env-file=/home/stack/templates/overcloud_images.yaml
```
- 任意のサービス用の環境ファイルを指定するには、-e オプションを使用します。
- Ceph Storage を使用している場合には、Ceph Storage 用のコンテナーイメージの場所を定義する追加のパラメーターを指定します: --set ceph_namespace、--set ceph_image、--set ceph_tag
注記
このステップの openstack overcloud container image prepare コマンドは、Red Hat Satellite サーバーをターゲットにします。ここでは、前のステップで使用した openstack overcloud container image prepare コマンドとは異なる値を指定します。
これで、イメージの場所が記載された overcloud_images.yaml 環境ファイルがアンダークラウド上に作成されます。今後のアップグレードとデプロイメントの操作ではすべてこのファイルを追加してください。

関連情報

詳細は、Red Hat Hyperconverged Infrastructure for Cloud 開発ガイド の Red Hat OpenStack Platformサービス用コンテナイメージの追加 セクションを参照してください。

次のステップ

アップグレードに向けてオーバークラウドを準備する。

5.3.5. 関連情報

詳細は、Red Hat OpenStack Platform Fast Forward アップグレードガイド のセクション 4.2 を参照してください。

5.4. コマンドラインインターフェイスを使用したリソースの分離およびオーバークラウドのチューニング

Red Hat OpenStack Platform (RHOSP)と Red Hat Ceph Storage (RHCS)との間のリソースの競合により、いずれかのサービスのパフォーマンスが低下する可能性があります。そのため、Red Hat Hyperconverged Infrastructure Cloud ソリューションでは、システムリソースを分離することが重要です。

同様に、特定のワークロードに対するより予測可能なパフォーマンスの結果については、オーバークラウドを調整することが重要になります。

リソースを分離してオーバークラウドを調整するには、以前に作成したカスタムテンプレートを引き続き改良します。

5.4.1. 前提条件

オーバークラウドを定義して、オーバークラウドの基盤を構築します。

5.4.2. ハイパーコンバージドノード向けの CPU およびメモリーリソースの確保

デフォルトでは、Nova Compute サービスのパラメーターは Ceph OSD サービスが同じノード上に配置されていることは考慮に入れません。安定性を維持し、可能なインスタンスの数を最大化するには、ハイパーコンバージドノードを調整する必要があります。プラン環境ファイルを使用すると、ハイパーコンバージドノード上の Nova コンピュートサービスのリソース制約を設定することができます。プラン環境ファイルはワークフローを定義し、Red Hat OpenStack Platform director (RHOSP-d)は OpenStack Workflow (Mistral)サービスでプランファイルを実行します。

RHOSP-d は、ハイパーコンバージドノード上のリソース制約を設定するためのデフォルトのプラン環境ファイルも提供します。

/usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml

-p パラメーターを使用すると、オーバークラウドのデプロイメント中にプラン環境ファイルが呼び出されます。

このプラン環境ファイルは、OpenStack Workflow に以下の操作を指示します。

ハードウェアイントロスペクションデータを取得します。
そのデータに基づいた、ハイパーコンバージドノード上の Compute に最適な CPU とメモリーの制約の算出
それらの制約を設定するために必要なパラメーターの自動生成

plan-environment-derived-params.yaml プラン環境ファイルでは、hci_profile_config オプションは、複数の CPU およびメモリーの割り当てワークロードプロファイルを定義します。hci_profile パラメーターは、有効にするワークロードプロファイルを設定します。

以下は、デフォルトの hci_profile です。

デフォルトの例

hci_profile: default
    hci_profile_config:
      default:
        average_guest_memory_size_in_mb: 2048
        average_guest_cpu_utilization_percentage: 50
      many_small_vms:
        average_guest_memory_size_in_mb: 1024
        average_guest_cpu_utilization_percentage: 20
      few_large_vms:
        average_guest_memory_size_in_mb: 4096
        average_guest_cpu_utilization_percentage: 80
      nfv_default:
        average_guest_memory_size_in_mb: 8192
        average_guest_cpu_utilization_percentage: 90

上記の例では、平均ゲストが CPU の 2 GB のメモリーと 50% を使用することを前提としています。

新しいプロファイルを hci_profile_config セクションに追加することで、環境用のカスタムワークロードプロファイルを作成できます。hci_profile パラメーターをプロファイルの名前に設定して、このカスタムワークロードプロファイルを有効にすることができます。

カスタムの例

hci_profile: my_workload
    hci_profile_config:
      default:
        average_guest_memory_size_in_mb: 2048
        average_guest_cpu_utilization_percentage: 50
      many_small_vms:
        average_guest_memory_size_in_mb: 1024
        average_guest_cpu_utilization_percentage: 20
      few_large_vms:
        average_guest_memory_size_in_mb: 4096
        average_guest_cpu_utilization_percentage: 80
      nfv_default:
        average_guest_memory_size_in_mb: 8192
        average_guest_cpu_utilization_percentage: 90
      my_workload:
        average_guest_memory_size_in_mb: 131072
        average_guest_cpu_utilization_percentage: 100

my_workload プロファイルは、平均ゲストが 128 GB の RAM と、ゲストに割り当てられた CPU の 100% を使用することを前提としています。

関連情報

詳細は、Red Hat OpenStack Platform ハイパーコンバージドインフラストラクチャーガイドを参照してください。

5.4.3. Ceph 用 CPU リソースの確保

ハイパーコンバージドデプロイメントでは、CPU リソースの Nova コンピュートプロセスと Ceph プロセス間で競合が発生する可能性があります。デフォルトでは、ceph-ansible は docker run コマンドで --cpu-quota オプションを使用して各 OSD を 1 つの仮想 CPU に制限します。ceph_osd_docker_cpu_limit オプションは、このデフォルト制限を上書きし、各 Ceph OSD プロセスにより多くの vCPU を使用できるようにします。以下に例を示します。

CephAnsibleExtraConfig:
  ceph_osd_docker_cpu_limit: 2

Red Hat は、ceph_osd_docker_cpu_limit の値を開始点として 2 に設定し、使用されているハードウェアとこのハイパーコンバージド環境で実行されるワークロードに基づいてこの値を調節することを推奨します。この設定オプションは、~/templates/ceph.yaml ファイルで設定できます。

重要

実稼働環境で実行する前に、ワークロードを常にテストしてください。

関連情報

~/templates/ceph.yaml ファイルの詳細は、Red Hat Ceph Storage パラメーターの設定 セクションを参照してください。
詳細は、Red Hat Ceph Storage ハードウェア選択ガイド の コンテナ型 Ceph クラスターに推奨される最小限のハードウェア セクションを参照してください。
詳細は、Red Hat Ceph ストレージコンテナガイド の コロケートされたデーモンのための専用リソースの設定 を参照してください。

5.4.4. Ceph 用メモリーリソースの確保

ハイパーコンバージドデプロイメントでは、Nova のコンピュートと Ceph プロセスがメモリーリソースで競合する可能性があります。Red Hat Hyperconverged Infrastructure for Cloud ソリューションのデプロイメントでは、ceph-ansible を使用して Ceph のメモリー設定を自動的にチューニングし、コロケートされたプロセス間のメモリー競合を軽減します。BlueStore オブジェクトストアは、メモリー処理機能が高いため、ハイパーコンバージドデプロイメントに推奨されるバックエンドです。

ceph_osd_docker_memory_limit オプションは、FileStore または BlueStore のいずれかで使用される Ceph オブジェクトストアバックエンドに関係なく、Ansible が検出したノードの最大メモリーサイズに自動的に設定されます。

警告

Red Hat は、ceph_osd_docker_memory_limit オプションを上書きしないことを推奨します。

osd_memory_target オプションは、Ceph OSD プロセスによるメモリーの増加を抑えるための推奨される方法です。is_hci オプションが true に設定されている場合、osd_memory_target オプションは自動的に設定されます。以下に例を示します。

CephAnsibleExtraConfig:
  is_hci: true

これらの設定オプションは ~/templates/ceph.yaml ファイルで設定できます。

注記

osd_memory_target オプションは、Red Hat Ceph Storage 3.2 以降の BlueStore オブジェクトストア機能で導入されました。

関連情報

~/templates/ceph.yaml ファイルの詳細は、Red Hat Ceph Storage パラメーターの設定 セクションを参照してください。
詳細は、Red Hat Ceph Storage ハードウェア選択ガイド の コンテナ型 Ceph クラスターに推奨される最小限のハードウェア セクションを参照してください。
詳細は、Red Hat Ceph ストレージコンテナガイド の コロケートされたデーモンのための専用リソースの設定 を参照してください。

5.4.5. Ceph のバックフィルおよびリカバリー操作のチューニング

Ceph はバックフィルおよびリカバリープロセスを使用して、OSD が削除されるたびにストレージクラスターのリバランスを行います。これは、配置グループポリシーに従って、データの複数のコピーを保持するために行われます。これらの 2 つの操作はシステムリソースを使用するため、Ceph ストレージクラスターが負荷がかかっている場合、Ceph はリソースをバックフィルおよびリカバリープロセスに迂回するため、Ceph のパフォーマンスが低下します。OSD の削除時に Ceph ストレージの許容可能なパフォーマンスを維持するには、バックフィルおよびリカバリー操作の優先度を下げます。優先度を減らすためのトレードオフは、長期間のデータレプリカが少なく、データを若干リスクにさらすことです。

変更する 3 つの変数は以下のとおりです。

osd_recovery_max_active: OSD ごとに一度のアクティブな復旧要求の数。リクエストが増えれば復旧も早くなりますが、その分クラスターへの負荷も大きくなります。
osd_max_backfills: 単一の OSD との間で許容されるバックフィルの最大数。
osd_recovery_op_priority: 復元の操作に設定されている優先順位。これは、osd client op priority と相対的になります。

osd_recovery_max_active パラメーターおよび osd_max_backfills パラメーターはすでに正しい値に設定されているため、ceph.yaml ファイルに追加する必要はありません。デフォルト値である 3 と 1 をそれぞれ上書きする場合は、それらを ceph.yaml ファイルに追加します。

関連情報

OSD の設定可能なパラメーターの詳細は、Red Hat Ceph Storage 設定ガイドを参照してください。

5.4.6. 関連情報

オーバークラウドパラメーターの詳細については、Red Hat OpenStack Platform 10 Director インストールおよび使用ガイドの表 5.2 デプロメントパラメーターを参照してください。
詳細は、仮想マシンの設定のカスタマイズを参照してください。
openstack overcloud deploy コマンドの実行に関する詳細は、「deploy コマンドの実行」を参照してください。
Ceph OSD を非同種のノードのディスクレイアウトにマッピングする方法については、コンテナー化された Red Hat Ceph によるオーバークラウドのデプロイ ガイドのディスクレイアウトを非同種の Ceph ストレージノードにマッピングするを参照してください。

5.5. コマンドラインインターフェイスを使用したオーバークラウドの定義

管理者として、オーバークラウドを定義する TripleO Heat テンプレートのカスタマイズ可能なセットを作成することができます。

5.5.1. 前提条件

すべての要件を満たしていることを確認します。
アンダークラウドとも呼ばれる Red Hat OpenStack Platform director をデプロイします。

Red Hat Hyperconverged Infrastructure for Cloud オーバークラウドを定義するための高度な手順：

カスタムテンプレートのディレクトリーの作成
オーバークラウドネットワークの設定
コントローラーおよび ComputeHCI ロールの作成
オーバークラウド用の Red Hat Ceph Storageの設定
オーバークラウドノードのプロファイルレイアウトの設定

5.5.2. カスタムテンプレートのディレクトリーの作成

Red Hat OpenStack Platform director (RHOSP-d) をインストールすると、TripleO Heat テンプレートのセットが作成されます。これらの TripleO Heat テンプレートは /usr/share/openstack-tripleo-heat-templates/ ディレクトリーにあります。Red Hat は、これらのテンプレートをカスタマイズする前にこれらのテンプレートをコピーすることを推奨します。

前提条件

アンダークラウドをデプロイします。

手順

RHOSP-d ノードのコマンドラインインターフェイスで以下の手順を実行します。

カスタムテンプレートの新規ディレクトリーを作成します。
```
[stack@director ~]$ mkdir -p ~/templates/nic-configs
```

5.5.3. オーバークラウドネットワークの設定

以下の手順では、分離ネットワークのネットワーク設定ファイルをカスタマイズし、それらを Red Hat OpenStack Platform (RHOSP) サービスに割り当てます。

前提条件

すべてのネットワーク要件を満たしていることを確認します。

手順

RHOSP director ノードで、stack ユーザーとして以下の手順を実施します。

環境に適用されるコンピュート NIC 設定テンプレートを選択します。
- /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-vlans/compute.yaml
- /usr/share/openstack-tripleo-heat-templates/network/config/single-nic-linux-bridge-vlans/compute.yaml
- /usr/share/openstack-tripleo-heat-templates/network/config/multiple-nics/compute.yaml
- /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/compute.yaml
  注記
  NIC の設定に関する詳しい情報は、各テンプレートの個々のディレクトリーで README.md を参照してください。
~/templates/ ディレクトリーに新規ディレクトリーを作成します。
```
[stack@director ~]$ touch ~/templates/nic-configs
```

選択したテンプレートを ~/templates/nic-configs/ ディレクトリーにコピーし、その名前を compute-hci.yaml に変更します。

例

[stack@director ~]$ cp /usr/share/openstack-tripleo-heat-templates/network/config/bond-with-vlans/compute.yaml ~/templates/nic-configs/compute-hci.yaml

~/templates/nic-configs/compute-hci.yaml ファイルの parameters: セクションに、以下の定義がすでに存在する場合は追加します。
```
StorageMgmtNetworkVlanID:
    default: 40
    description: Vlan ID for the storage mgmt network traffic.
    type: number
```
各ノードで StorageMgmtNetworkVlanID を特定の NIC にマッピングします。たとえば、VLAN を単一の NIC にトランク接続する場合(single-nic-vlans/compute.yaml)、以下のエントリーを ~/templates/nic-configs/compute-hci.yaml の network_config: セクションに追加します。
```
type: vlan
device: em2
mtu: 9000
use_dhcp: false
vlan_id: {get_param: StorageMgmtNetworkVlanID}
addresses:
  -
    ip_netmask: {get_param: StorageMgmtIpSubnet}
```
重要
Red Hat は、NIC を StorageMgmtNetworkVlanID にマッピングする際に、mtu を 9000 に設定することを推奨します。この MTU 設定により、Red Hat Ceph Storage のパフォーマンスが大幅に向上します。詳細は、Red Hat OpenStack Platform Advanced Overcloud カスタマイゼーションの Jumbo Frames の設定を参照してください。
カスタムテンプレートディレクトリーに新規ファイルを作成します。
```
[stack@director ~]$ touch ~/templates/network.yaml
```

network.yaml ファイルを開いて編集します。

resource_registry セクションを追加します。
```
resource_registry:
```
resource_registry: セクションに次の 2 つの行を追加します。
```
OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller-nics.yaml
OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute-nics.yaml
```
これら 2 行は、RHOSP サービスが Controller/Monitor ノードおよび Compute/OSD ノードのネットワーク設定をそれぞれ指します。
parameter_defaults セクションを追加します。
```
parameter_defaults:
```
テナントネットワークの Neutron ブリッジマッピング用に、以下のデフォルトパラメーターを追加します。
```
NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-tenant'
NeutronNetworkType: 'vxlan'
NeutronTunnelType: 'vxlan'
NeutronExternalNetworkBridge: "''"
```
これは、論理ネットワークに割り当てられたブリッジマッピングを定義し、テナントが vxlan を使用できるようにします。

ステップ 2b で参照されている 2 つの TripleO Heat テンプレートは、各ネットワークを定義するパラメーターを必要とします。parameter_defaults セクションに以下の行を追加します。

# Internal API used for private OpenStack Traffic
InternalApiNetCidr: IP_ADDR_CIDR
InternalApiAllocationPools: [{'start': 'IP_ADDR_START', 'end': 'IP_ADDR_END'}]
InternalApiNetworkVlanID: VLAN_ID

# Tenant Network Traffic - will be used for VXLAN over VLAN
TenantNetCidr: IP_ADDR_CIDR
TenantAllocationPools: [{'start': 'IP_ADDR_START', 'end': 'IP_ADDR_END'}]
TenantNetworkVlanID: VLAN_ID

# Public Storage Access - Nova/Glance <--> Ceph
StorageNetCidr: IP_ADDR_CIDR
StorageAllocationPools: [{'start': 'IP_ADDR_START', 'end': 'IP_ADDR_END'}]
StorageNetworkVlanID: VLAN_ID

# Private Storage Access - Ceph cluster/replication
StorageMgmtNetCidr: IP_ADDR_CIDR
StorageMgmtAllocationPools: [{'start': 'IP_ADDR_START', 'end': 'IP_ADDR_END'}]
StorageMgmtNetworkVlanID: VLAN_ID

# External Networking Access - Public API Access
ExternalNetCidr: IP_ADDR_CIDR

# Leave room for floating IPs in the External allocation pool (if required)
ExternalAllocationPools: [{'start': 'IP_ADDR_START', 'end': 'IP_ADDR_END'}]

# Set to the router gateway on the external network
ExternalInterfaceDefaultRoute: IP_ADDRESS

# Gateway router for the provisioning network (or undercloud IP)
ControlPlaneDefaultRoute: IP_ADDRESS

# The IP address of the EC2 metadata server, this is typically the IP of the undercloud
EC2MetadataIp: IP_ADDRESS

# Define the DNS servers (maximum 2) for the Overcloud nodes
DnsServers: ["DNS_SERVER_IP","DNS_SERVER_IP"]

以下を置き換えます。

適切な IP アドレスとネットマスク (CIDR) を持つ IP_ADDR_CIDR。
IP_ADDR_START を適切な開始 IP アドレスに置き換えます。
IP_ADDR_END を適切な終了 IP アドレスに置き換えます。
IP_ADDRESS を適切な IP アドレスに置き換えます。
対応するネットワークの適切な VLAN 識別番号を持つ VLAN_ID。
DNS_SERVER_IP をコンマ (,) で区切って、2 つの DNS サーバーを定義するための適切な IP アドレスに置き換えます。
network.yaml ファイルのサンプルについては、付録を参照してください。

関連情報

ネットワーク分離に関する詳しい情報は、Red Hat OpenStack Platform Advance Overcloud カスタマイズガイドを参照してください。

5.5.4. Controller ロールおよび ComputeHCI ロールの作成

オーバークラウドには、Controller、Compute、BlockStorage、ObjectStorage、および CephStorage の 5 つのデフォルトロールがあります。これらのロールには、サービスの一覧が含まれます。これらのサービスを組み合わせて、カスタムの deployable ロールを作成できます。

前提条件

アンダークラウドとも呼ばれる Red Hat OpenStack Platform director をデプロイします。
カスタムテンプレートのディレクトリーを作成します。

手順

Red Hat OpenStack Platform director ノードで、stack ユーザーとして以下の手順を実施します。

Controller および ComputeHCI が含まれるカスタムの roles_data_custom.yaml ファイルを生成します。

[stack@director ~]$ openstack overcloud roles generate -o ~/custom-templates/roles_data_custom.yaml Controller ComputeHCI

関連情報

これらのカスタムロールの使用に関する詳細は、Red Hat Hyperconverged Infrastructure for Cloud デプロイメントガイド のコマンドラインを使用したオーバークラウドのデプロイを参照してください。

5.5.5. Red Hat Ceph Storage パラメーターの設定

この手順では、使用する Red Hat Ceph Storage (RHCS) OSD パラメーターを定義します。

前提条件

アンダークラウドとも呼ばれる Red Hat OpenStack Platform director をデプロイします。
カスタムテンプレートのディレクトリーを作成します。

手順

Red Hat OpenStack Platform director ノードで、stack ユーザーとして以下の手順を実施します。

~/templates/ceph.yaml ファイルを編集するために開きます。
1. BlueStore オブジェクトストアバックエンドを使用するには、CephAnsibleExtraConfig セクションの下にある以下の行を更新します。
  例
```
CephAnsibleExtraConfig:
  osd_scenario: lvm
  osd_objectstore: bluestore
```
2. parameter_defaults セクションで以下のオプションを更新します。
  例
```
parameter_defaults:
    CephPoolDefaultSize: 3
    CephPoolDefaultPgNum: NUM
    CephAnsibleDisksConfig:
      osd_scenario: lvm
      osd_objectstore: bluestore
      devices:
        - /dev/sda
        - /dev/sdb
        - /dev/sdc
        - /dev/sdd
        - /dev/nvme0n1
        - /dev/sde
        - /dev/sdf
        - /dev/sdg
        - /dev/nvme1n1
    CephAnsibleExtraConfig:
      osd_scenario: lvm
      osd_objectstore: bluestore
      ceph_osd_docker_cpu_limit: 2
      is_hci: true

    CephConfigOverrides:
      osd_recovery_op_priority: 3
      osd_recovery_max_active: 3
      osd_max_backfills: 1
```
  以下を置き換えます。
  NUM は、Ceph PG calculator から計算された値に置き換えます。
  以下の例では、以下の Compute/OSD ノードのディスク設定が使用されています。
  OSD : /dev/[sda, sdb, …, sdg] ブロックデバイスとして表示される 12 x 1TB SAS ディスク
  OSD WAL および DB デバイス: /dev/[nvme0n1, nvme1n1] ブロックデバイスとして提示される 2 x 400GB NVMe SSD ディスク

関連情報

Ceph OSD パラメーターのチューニングに関する詳細は、Red Hat Ceph Storage ストレージストラテジーガイドを参照してください。
BlueStore オブジェクトストアの使用に関する詳細は、Red Hat Ceph Storage 管理ガイドを参照してください。
LVM シナリオの例については、Red Hat Ceph Storage インストールガイドの LVM simple and LVM advance セクションを参照してください。

5.5.6. オーバークラウドノードのレイアウトの設定

ノードのオーバークラウドレイアウトは、種別、割り当てる IP アドレスのプール、およびその他のパラメーターに基づいてデプロイするノード数を定義します。

前提条件

アンダークラウドとも呼ばれる Red Hat OpenStack Platform director をデプロイします。
カスタムテンプレートのディレクトリーを作成します。

手順

Red Hat OpenStack Platform director ノードで、stack ユーザーとして以下の手順を実施します。

カスタムテンプレートディレクトリーに layout.yaml ファイルを作成します。
```
[stack@director ~]$ touch ~/templates/layout.yaml
```

layout.yaml ファイルを開いて編集します。

以下の行を追加してリソースレジストリーセクションを追加します。
```
resource_registry:
```

IP アドレスのプールを使用するように Controller ロールおよび ComputeHCI ロールを設定するには、resource_registry セクションに以下の行を追加します。

  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml

  OS::TripleO::ComputeHCI::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
  OS::TripleO::ComputeHCI::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml
  OS::TripleO::ComputeHCI::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
  OS::TripleO::ComputeHCI::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml

parameter_defaults という名前のパラメーターのデフォルトに新しいセクションを追加し、このセクションの下に以下のパラメーターを追加します。
```
parameter_defaults:
  NtpServer: NTP_IP_ADDR
  ControllerHostnameFormat: 'controller-%index%'
  ComputeHCIHostnameFormat: 'compute-hci-%index%'
  ControllerCount: 3
  ComputeHCICount: 3
  OvercloudComputeFlavor: compute
  OvercloudComputeHCIFlavor: osd-compute
```
以下を置き換えます。
NTP_IP_ADDR は、NTP ソースの IP アドレスに置き換えます。時間同期は非常に重要になります。
例

parameter_defaults: NtpServer: 10.5.26.10 ControllerHostnameFormat: 'controller-%index%' ComputeHCIHostnameFormat: 'compute-hci-%index%' ControllerCount: 3 ComputeHCICount: 3 OvercloudComputeFlavor: compute OvercloudComputeHCIFlavor: osd-compute
ControllerCount および ComputeHCICount パラメーターの 3 の値は、3 つのコントローラー/モニターノードと 3 つの Compute/OSD ノードがデプロイされることを意味します。
parameter_defaults セクションで、ControllerSchedulerHints と呼ばれるスケジューラーヒントと、ComputeHCISchedulerHints と呼ばれる 2 つのスケジューラーヒントを追加します。各スケジューラーヒントの下に、予測可能なノード配置用のノード名の形式を以下のように追加します。
```
  ControllerSchedulerHints:
    'capabilities:node': 'control-%index%'
  ComputeHCISchedulerHints:
    'capabilities:node': 'osd-compute-%index%'
```

parameter_defaults セクションで、各ノードプロファイルに必要な IP アドレスを追加します。以下に例を示します。

例

  ControllerIPs:
    internal_api:
      - 192.168.2.200
      - 192.168.2.201
      - 192.168.2.202
    tenant:
      - 192.168.3.200
      - 192.168.3.201
      - 192.168.3.202
    storage:
      - 172.16.1.200
      - 172.16.1.201
      - 172.16.1.202
    storage_mgmt:
      - 172.16.2.200
      - 172.16.2.201
      - 172.16.2.202

  ComputeHCIIPs:
    internal_api:
      - 192.168.2.203
      - 192.168.2.204
      - 192.168.2.205
    tenant:
      - 192.168.3.203
      - 192.168.3.204
      - 192.168.3.205
    storage:
      - 172.16.1.203
      - 172.16.1.204
      - 172.16.1.205
    storage_mgmt:
      - 172.16.2.203
      - 172.16.2.204
      - 172.16.2.205

この例では、ノード control-0 には次の IP アドレスがあります: 192.168.2.200、192.168.3.200、172.16.1.200 および 172.16.2.200。

5.5.7. 関連情報

詳細は、Red Hat OpenStack Platform Advanced Overcloud カスタマイゼーションガイドを参照してください。

5.6. コマンドラインインターフェイスを使用したオーバークラウドのデプロイ

技術者として、Nova Compute と Ceph OSD サービスが同じノードにコロケーションされるようにオーバークラウドノードをデプロイメントすることができます。

5.6.2. Ironic で利用可能なノードの確認

オーバークラウドノードをデプロイする前に、ノードの電源がオフになり、利用可能であることを確認します。

警告

ノードがメンテナンスモードであることはできません。

前提条件

Red Hat OpenStack Platform director ノードで stack ユーザーが利用できる。

手順

以下のコマンドを実行して、全ノードの電源がオフになり、利用可能であることを確認します。
```
[stack@director ~]$ openstack baremetal node list
```

5.6.3. Pacemaker フェンシング用のコントローラーの設定

データの破損が発生しないようにクラスター内のノードを分離することは、フェンシングと呼ばれます。フェンシングは、クラスターおよびクラスターリソースの整合性を保護します。

前提条件

IPMI ユーザーおよびパスワード
Red Hat OpenStack Platform director ノードで stack ユーザーが利用できる。

手順

フェンシング Heat 環境ファイルを生成します。

[stack@director ~]$ openstack overcloud generate fencing --ipmi-lanplus instackenv.json --output fencing.yaml

openstack overcloud deploy コマンドに fencing.yaml ファイルを追加します。

関連情報

詳細は、Deploying Red Hat Enterprise Linux OpenStack Platform 7 with Red Hat OpenStack Platform director を参照してください。

5.6.4. deploy コマンドの実行

すべてのカスタマイズとチューニング後に、オーバークラウドをデプロイします。

注記

デプロイメントのサイズに応じて、オーバークラウドのデプロイメントが完了するまでに時間がかかる場合があります。

前提条件

ノードの準備
コンテナーイメージのソースの設定
オーバークラウドの定義
リソースの分離とチューニング
Red Hat OpenStack Platform director ノードで stack ユーザーが利用できる。

手順

以下のコマンドを実行します。
```
[stack@director ~]$ time openstack overcloud deploy \
--templates /usr/share/openstack-tripleo-heat-templates \
--stack overcloud \
-p /usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml
-r /home/stack/templates/roles_data_custom.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
-e /home/stack/templates/overcloud_images.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
-e ~/templates/network.yaml \
-e ~/templates/ceph.yaml \
-e ~/templates/layout.yaml
-e /home/stack/fencing.yaml
```
コマンドの詳細
time コマンドは、デプロイメントにかかる時間を示すために使用されます。
openstack overcloud deploy コマンドは実際のデプロイメントを実行します。
$NTP_IP_ADDR は、NTP ソースの IP アドレスに置き換えます。時間同期は非常に重要になります。
--templates 引数は、デプロイする TripleO Heat テンプレートが含まれるデフォルトのディレクトリー(/usr/share/openstack-tripleo-heat-templates/)を使用します。
-p 引数は、HCI デプロイメントのプラン環境ファイルを参照します。詳細は、ハイパーコンバージドノード向けの CPU およびメモリーリソースの確保セクションを参照してください。
-r 引数はロールファイルを参照し、デフォルトの role_data.yaml ファイルをオーバーライドします。
-e 引数は、デプロイメント時に使用する明示的なテンプレートファイルを参照します。
puppet-pacemaker.yaml ファイルは、高可用性の Pacemaker クラスターでコントローラーノードサービスを設定します。
storage-environment.yaml ファイルは、Ceph をストレージバックエンドとして設定します。parameter_defaults はカスタムテンプレート ceph.yaml によって渡されます。
network-isolation.yaml ファイルは、異なるサービスのネットワーク分離を設定します。このサービスは、カスタムテンプレート network.yaml によって渡されます。このファイルは、デプロイメントの開始時に自動的に作成されます。
network.yaml ファイルについては、オーバークラウドネットワークの設定セクションを参照してください。
ceph.yaml ファイルについては、Red Hat Ceph Storage パラメーターの設定セクションで説明されています。
compute.yaml ファイルについては、Nova 予約メモリーと CPU 割り当ての変更セクションで詳しく説明しています。
layout.yaml ファイルについては、オーバークラウドノードのプロファイルレイアウトの設定セクションを参照してください。
fencing.yaml ファイルについては、Pacemaker フェンシング用のコントローラーの設定セクションを参照してください。
重要
引数の順序は重要です。カスタムテンプレートファイルは、デフォルトのテンプレートファイルをオーバーライドします。
注記
パッケージインストール用のソフトウェアリポジトリーとして Red Hat OpenStack Platform director (RHOSP-d) ノードを使用する場合は、--rhel-reg、--reg-method、--reg-org オプションを追加します。
オーバークラウドのデプロイメントが完了するまで待ちます。

関連情報

オーバークラウドパラメーターに関する詳しい情報は、Red Hat OpenStack Platform 13 Director インストールおよび使用ガイドの表 5.2 デプロイメントパラメーターを参照してください。

5.6.5. オーバークラウドのデプロイメントが正常に行われたことの確認

オーバークラウドのデプロイメントが成功したかどうかを確認することが重要です。

前提条件

Red Hat OpenStack Platform director ノードで stack ユーザーが利用できる。

手順

デプロイメントプロセスを監視し、エラーを探します。

[stack@director ~]$ heat resource-list -n5 overcloud | egrep -i 'fail|progress'

オーバークラウドのデプロイメントに成功した出力例:

2016-12-20 23:25:04Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE

Started Mistral Workflow. Execution ID: aeca4d71-56b4-4c72-a980-022623487c05
/home/stack/.ssh/known_hosts updated.
Original contents retained as /home/stack/.ssh/known_hosts.old
Overcloud Endpoint: http://10.19.139.46:5000/v2.0
Overcloud Deployed

デプロイメントが完了したら、オーバークラウドノードの IP アドレスを表示します。
```
[stack@director ~]$ openstack server list
```

第6章 Red Hat Hyperconverged Infrastructure for Cloud ソリューションの最新バージョンへの更新

技術者として、Red HatHyperconverged Infrastructure for Cloud ソリューションを最新バージョンの Red Hat OpenStack Platform 13、および Red Hat Ceph Storage 3 に更新することができます。Red Hat Hyperconverged Infrastructure for Cloud ソフトウェアセットを最新バージョンに更新するには、Red Hat OpenStack Platform 13 ドキュメントの手順に従います。

Red Hat OpenStack Platform の最新状態の維持

付録A Red Hat Hyperconverged Infrastructure for Cloud に必要なリポジトリー

表A.1 必要なリポジトリー

名前	リポジトリー	要件の説明
Red Hat Enterprise Linux 7 Server (RPM)	`rhel-7-server-rpms`	ベースオペレーティングシステムのリポジトリー
Red Hat Enterprise Linux 7 Server - Extras (RPM)	`rhel-7-server-extras-rpms`	Red Hat OpenStack Platform の依存関係が含まれます。
Red Hat Enterprise Linux 7 Server - RH Common (RPMs)	`rhel-7-server-rh-common-rpms`	Red Hat OpenStack Platform のデプロイと設定用のツールが含まれます。
Red Hat Enterprise Linux High Availability (for RHEL 7 Server) (RPMs)	`rhel-ha-for-rhel-7-server-rpms`	Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。
Red Hat Enterprise Linux OpenStack Platform 13 for RHEL 7 (RPMs)	`rhel-7-server-openstack-13-rpms`	Red Hat OpenStack Platform のコアリポジトリー。Red Hat OpenStack Platform director のパッケージも含まれます。
Red Hat Ceph Storage 3 OSD for Red Hat Enterprise Linux 7 Server (RPMs)	`rhel-7-server-rhceph-3-osd-rpms`	RHCS Object Storage Daemon (OSD) のリポジトリー。コンピュートノードで有効化されている。
Red Hat Ceph Storage 3 MON for Red Hat Enterprise Linux 7 Server (RPMs)	`rhel-7-server-rhceph-3-mon-rpms`	RHCS Monitor デーモンのリポジトリー。コントローラーノードで有効化されている。
Red Hat Ceph Storage 3 Tools for Red Hat Enterprise Linux 7 Workstation (RPMs)	`rhel-7-server-rhceph-3-tools-rpms`	Ceph Object Gateway などの RHCS ツールおよびクライアントのリポジトリー。

付録B Red Hat Hyper-converaged Infrastructure for Cloud undercloud configuration parameters

local_ip: director のプロビジョニングネットワーク用に定義する IP アドレス。これは、director が DHCP および PXE ブートサービスに使用する IP アドレスでもあります。
network_gateway: オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのノードです。
undercloud_public_vip: director のパブリック API 用に定義する IP アドレス他の IP アドレスまたはアドレス範囲と競合しないプロビジョニングネットワークで IP アドレスを使用します。director の設定により、この IP アドレスは、/32 ネットマスクを使用するルーティングされた IP アドレスとしてソフトウェアブリッジにアタッチされます。
undercloud_admin_vip: director の管理 API 用に定義する IP アドレス。他の IP アドレスまたはアドレス範囲と競合しないプロビジョニングネットワークで IP アドレスを使用します。director の設定により、この IP アドレスは、/32 ネットマスクを使用するルーティングされた IP アドレスとしてソフトウェアブリッジにアタッチされます。
local_interface: director のプロビジョニング NIC 用に選択するインターフェイス。これは、director が DHCP および PXE ブートサービスに使用するデバイスでもあります。この設定スクリプトにより、このインターフェイスが inspection_interface パラメーターで定義したカスタムのブリッジにアタッチされます。
network_cidr: オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの neutron サービスが管理するプロビジョニングネットワークです。
masquerade_network: 外部アクセスのためにマスカレードするネットワークを定義します。このパラメーターにより、director 経由で外部ネットワークにアクセスすることができるように、プロビジョニングネットワークにネットワークアドレス変換 (NAT) の一部メカニズムが提供されます。
dhcp_start: オーバークラウドノードの DHCP 割り当て範囲の開始。この範囲には、すべてのノードに割り当てるのに十分な IP アドレスが含まれていることを確認してください。
dhcp_end: オーバークラウドノードの DHCP 割り当て範囲の最後。この範囲には、すべてのノードに割り当てるのに十分な IP アドレスが含まれていることを確認してください。
inspection_interface: ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。local_interface でこのブリッジをアタッチします。これは、デフォルトの br-ctlplane のままにします。
inspection_iprange: director のイントロスペクションサービスが PXE ブートとプロビジョニングプロセスの際に使用する IP アドレス範囲。コンマ区切りの値を使用して、開始アドレスと終了アドレスを定義します。この範囲には、使用するノードに十分な数の IP アドレスが含まれるようにし、dhcp_start と dhcp_end の範囲とは競合しないように設定してください。
inspection_extras: イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。イントロスペクションイメージでは python-hardware または python-hardware-detect パッケージが必要です。
inspection_runbench: ノードイントロスペクション時に一連のベンチマークを実行します。有効にするには、true に設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。
inspection_enable_uefi: UEFI のみのファームウェアを使用するノードのイントロスペクションをサポートするかどうかを定義します。

付録C Red Hat Hyperconverged Infrastructure for Cloud - Nova メモリーおよび CPU calculator スクリプトソース

これは、nova_mem_cpu_calc.py スクリプトの Python ソースコードです。

#!/usr/bin/env python
# Filename:                nova_mem_cpu_calc.py
# Supported Langauge(s):   Python 2.7.x
# Time-stamp:              <2017-03-10 20:31:18 jfulton>
# -------------------------------------------------------
# This program was originally written by Ben England
# -------------------------------------------------------
# Calculates cpu_allocation_ratio and reserved_host_memory
# for nova.conf based on on the following inputs:
#
# input command line parameters:
# 1 - total host RAM in GB
# 2 - total host cores
# 3 - Ceph OSDs per server
# 4 - average guest size in GB
# 5 - average guest CPU utilization (0.0 to 1.0)
#
# It assumes that we want to allow 3 GB per OSD
# (based on prior Ceph Hammer testing)
# and that we want to allow an extra 1/2 GB per Nova (KVM guest)
# based on test observations that KVM guests' virtual memory footprint
# was actually significantly bigger than the declared guest memory size
# This is more of a factor for small guests than for large guests.
# -------------------------------------------------------
import sys
from sys import argv

NOTOK = 1  # process exit status signifying failure
MB_per_GB = 1000

GB_per_OSD = 3
GB_overhead_per_guest = 0.5  # based on measurement in test environment
cores_per_OSD = 1.0  # may be a little low in I/O intensive workloads

def usage(msg):
  print msg
  print(
    ("Usage: %s Total-host-RAM-GB Total-host-cores OSDs-per-server " +
     "Avg-guest-size-GB Avg-guest-CPU-util") % sys.argv[0])
  sys.exit(NOTOK)

if len(argv) < 5: usage("Too few command line params")
try:
  mem = int(argv[1])
  cores = int(argv[2])
  osds = int(argv[3])
  average_guest_size = int(argv[4])
  average_guest_util = float(argv[5])
except ValueError:
  usage("Non-integer input parameter")

average_guest_util_percent = 100 * average_guest_util

# print inputs
print "Inputs:"
print "- Total host RAM in GB: %d" % mem
print "- Total host cores: %d" % cores
print "- Ceph OSDs per host: %d" % osds
print "- Average guest memory size in GB: %d" % average_guest_size
print "- Average guest CPU utilization: %.0f%%" % average_guest_util_percent

# calculate operating parameters based on memory constraints only
left_over_mem = mem - (GB_per_OSD * osds)
number_of_guests = int(left_over_mem /
                       (average_guest_size + GB_overhead_per_guest))
nova_reserved_mem_MB = MB_per_GB * (
                        (GB_per_OSD * osds) +
                        (number_of_guests * GB_overhead_per_guest))
nonceph_cores = cores - (cores_per_OSD * osds)
guest_vCPUs = nonceph_cores / average_guest_util
cpu_allocation_ratio = guest_vCPUs / cores

# display outputs including how to tune Nova reserved mem

print "\nResults:"
print "- number of guests allowed based on memory = %d" % number_of_guests
print "- number of guest vCPUs allowed = %d" % int(guest_vCPUs)
print "- nova.conf reserved_host_memory = %d MB" % nova_reserved_mem_MB
print "- nova.conf cpu_allocation_ratio = %f" % cpu_allocation_ratio

if nova_reserved_mem_MB > (MB_per_GB * mem * 0.8):
    print "ERROR: you do not have enough memory to run hyperconverged!"
    sys.exit(NOTOK)

if cpu_allocation_ratio < 0.5:
    print "WARNING: you may not have enough CPU to run hyperconverged!"

if cpu_allocation_ratio > 16.0:
    print(
        "WARNING: do not increase VCPU overcommit ratio " +
        "beyond OSP8 default of 16:1")
    sys.exit(NOTOK)

print "\nCompare \"guest vCPUs allowed\" to \"guests allowed based on memory\" for actual guest count"

付録D Red Hat Hyperconverged Infrastructure for Cloud - example `network.yaml` file

例

resource_registry:
  OS::TripleO::OsdCompute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute-nics.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller-nics.yaml

parameter_defaults:
  NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-tenant'
  NeutronNetworkType: 'vxlan'
  NeutronTunnelType: 'vxlan'
  NeutronExternalNetworkBridge: "''"

  # Internal API used for private OpenStack Traffic
  InternalApiNetCidr: 192.168.2.0/24
  InternalApiAllocationPools: [{'start': '192.168.2.10', 'end': '192.168.2.200'}]
  InternalApiNetworkVlanID: 4049

  # Tenant Network Traffic - will be used for VXLAN over VLAN
  TenantNetCidr: 192.168.3.0/24
  TenantAllocationPools: [{'start': '192.168.3.10', 'end': '192.168.3.200'}]
  TenantNetworkVlanID: 4050

  # Public Storage Access - Nova/Glance <--> Ceph
  StorageNetCidr: 172.16.1.0/24
  StorageAllocationPools: [{'start': '172.16.1.10', 'end': '172.16.1.200'}]
  StorageNetworkVlanID: 4046

  # Private Storage Access - Ceph background cluster/replication
  StorageMgmtNetCidr: 172.16.2.0/24
  StorageMgmtAllocationPools: [{'start': '172.16.2.10', 'end': '172.16.2.200'}]
  StorageMgmtNetworkVlanID: 4047

  # External Networking Access - Public API Access

  ExternalNetCidr: 10.19.137.0/21
  # Leave room for floating IPs in the External allocation pool (if required)
  ExternalAllocationPools: [{'start': '10.19.139.37', 'end': '10.19.139.48'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 10.19.143.254

  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.168.1.1
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.168.1.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.19.143.247","10.19.143.248"]

付録E Nova 確保メモリーと CPU 割り当ての手動チューニング

計画された作業負荷に対して Nova 環境をチューニングすることは、試行錯誤の連続です。Red Hat は、起動後にデフォルトのベースセットを計算し、そこからチューニングすることを推奨します。

reserved_host_memory_mb パラメーターおよび cpu_allocation_ratio パラメーターを調整することで、ワークロードで可能なゲストの数を最大化できます。また、これらの値を微調整することで、ワークロードの決定性とゲストホスティング能力の間の望ましいトレードオフを見つけることができます。

Nova 確保メモリーのチューニング

Nova の reserved_host_memory_mb パラメーターは、ノード用に確保するメモリー容量 (メガバイト(MB)単位) です。ハイパーコンバージド Compute/OSD ノードでは、必要なリソースのサービスが不足しないように、2 つのサービス間でメモリーを共有する必要があることに注意してください。

以下は、ハイパーコンバージドノードの reserved_host_memory_mb 値を決定する方法の例になります。RAM が 256 GB、10 の OSD を持つノードで、各 OSD が 3 GB の RAM を消費し、Ceph 用に 30GB の RAM を消費し、Nova Compute 用に 226GB の RAM を残していることを前提とします。平均ゲストがそれぞれ 2 GB の RAM を使用する場合は、システム全体のゲストマシンが 113 個のゲストマシンをホストする可能性があります。ただし、考慮する必要のあるハイパーバイザーで実行している各ゲストマシンには、追加のオーバーヘッドがあります。このオーバーヘッドを 500MB と仮定すると、2GB のゲストマシンの最大稼働数は約 90 台となります。

以下は数式です。

ゲストマシンの概算数 = (Nova で使用可能なメモリー (GB) / (ゲストマシンごとのメモリー (GB) + ハイパーバイザーのメモリーオーバーヘッド (GB))

例

90.4 = ( 226 / ( 2 + .5 ) )

ゲストマシンの概算数と OSD 数については、Nova 用に確保するメモリー量を計算することができます。

Nova の予約メモリー (MB) = 1000 * (OSD メモリーサイズ (GB) * OSD の数) + (ゲストマシンの概算数 * ハイパーバイザーのメモリーオーバーヘッド (GB))

例

75000 = 1000 * ( ( 3 * 10 ) + ( 90 * .5 ) )

したがって、reserved_host_memory_mb は 75000 と等しくなります。パラメーターの値はメガバイト (MB) でなければなりません。

CPU 割り当て率のチューニング

Nova の cpu_allocation_ratio パラメーターは、ゲストマシンを実行するコンピュートノードを選択する際に Nova スケジューラーによって使用されます。ゲストマシンとコンピュートノードとの比率が 16:1 で、ノード上のコア(vCPU)の数が 56 の場合、Nova スケジューラーは 896 コアを消費するのに十分なゲストをスケジュールしてから、ノードが追加のゲストマシンを処理できないとみなすことができます。理由は、Nova スケジューラーが Nova スケジューラーと同じノードで実行されている Ceph OSD サービスの CPU ニーズを考慮しないためです。cpu_allocation_ratio パラメーターを変更すると、Ceph は、CPU リソースを Nova Compute に指定せずに効果的に動作する必要がある CPU リソースを持つことができます。

ハイパーコンバージドノードの cpu_allocation_ratio 値を決定する方法の例を以下に示します。ノードに 56 コアおよび 10 OSD があり、1 つのコアが各 OSD で使用されることを前提とし、Nova 用に 46 コアを残します。各ゲストマシンがコアの 100% を使用する場合、ゲストマシンで利用可能なコア数はノード上のコアの合計数で除算されます。このシナリオでは、cpu_allocation_ratio の値は 0.821429 です。

ただし、ゲストマシンはコアの 100% を使用しないため、この比率はゲストマシンごとのコア数を決定する際に予想される使用率率を考慮する必要があります。ゲストマシンごとに平均 10% のコア使用率が予想されるシナリオでは、cpu_allocation_ratio の値は 8.214286 である必要があります。

以下は数式です。

非 Ceph コア数 = ノード上の総コア数 - (OSD あたりのコア数 * OSD の数)
ゲストマシンの vCPU 数 = Ceph 以外のコア数/ゲストマシンの平均 CPU 使用率
CPU 割当率 ＝ ゲストマシンの vCPU 数/ノード上の総コア数

例

46 = 56 - ( 1 * 10 )
460 = 46 / .1
8.214286 = 460 / 56

Nova メモリーおよび CPU の計算

Red Hat は、これらすべての計算を行うための calculator スクリプトを提供しています。スクリプト名は nova_mem_cpu_calc.py で、5 つの入力パラメーターを取ります。

nova_mem_cpu_calc.py TOTAL_NODE_RAM_GB TOTAL_NODE_CORES NUM_OSDs_PER_NODE AVG_GUEST_MEM_SIZE_GB AVG_GUEST_CPU_UTIL

以下を置き換えます。

TOTAL_NODE_RAM_GB に、ノード上の RAM の合計サイズ (GB) を指定します。
TOTAL_NODE_CORES ノード上のコアの総数を表します。
NUM_OSDs_PER_NODE にノードあたりの Ceph OSD の数を指定します。
AVG_GUEST_MEM_SIZE_GB に、ゲストマシンの平均メモリーサイズ (GB) を指定します。
AVG_GUEST_CPU_UTIL に、ゲストマシンの平均 CPU 使用率 (10 進数で表示) を指定します。

例

[stack@director ~]$ ./nova_mem_cpu_calc.py 256 56 10 2 0.1

関連情報

nova_mem_cpu_calc.py スクリプトの完全なソースコードは、付録を参照してください。

付録F Nova 確保メモリーと CPU 割り当ての手動変更

reserved_host_memory_mb および cpu_allocation_ratio のデフォルト値を上書きするカスタムテンプレートを作成します。

前提条件

アンダークラウドとも呼ばれる Red Hat OpenStack Platform director (RHOSP-d)をデプロイします。
カスタムテンプレートのディレクトリーを作成します。

手順

RHOSP-d ノードで、stack ユーザーとして以下の手順を実行します。

カスタムテンプレートディレクトリーに compute.yaml ファイルを作成します。
```
[stack@director ~]$ touch ~/templates/compute.yaml
```
compute.yaml ファイルを開いて編集します。
1. パラメーター defaults セクションで、reserved_host_memory および cpu_allocation_ratio 設定パラメーターを ExtraConfig セクションに追加します。
```
parameter_defaults:
  ExtraConfig:
    nova::compute::reserved_host_memory: MEMORY_SIZE_IN_MB
    nova::cpu_allocation_ratio: CPU_RATIO
```
  以下を置き換えます。
  メモリーサイズがメガバイト (MB) の MEMORY_SIZE_IN_MB。
  CPU_RATIO の比率 (10 進数)
  例
  
  nova::compute::reserved_host_memory: 75000 nova::cpu_allocation_ratio: 8.2
  
  注記
  Red Hat OpenStack Platform director は、Nova が reserved_host_memory パラメーターとして使用する reserved_host_memory_mb パラメーターを参照します。

Language and Page Formatting Options

デプロイメントガイド

Red Hat Hyperconverged Infrastructure for Cloud Solution のデプロイ

第1章 Red Hat Hyperconverged Infrastructure for Cloud ソリューションの紹介

第2章 Red Hat Hyperconverged Infrastructure for Cloud 要件の確認

2.1. 前提条件

2.2. Red Hat Hyperconverged Infrastructure for Cloud ハードウェア要件

2.3. Red Hat Hyperconverged Infrastructure for Cloud ネットワーク要件

2.4. Red Hat Hyperconverged Infrastructure for Cloud ソフトウェア要件の確認

2.5. 関連情報

第3章 アンダークラウドのデプロイ

3.1. 前提条件

3.2. デプロイメント間の Ironic のディスククリーニングについて

3.3. アンダークラウドのインストール

3.4. オーバークラウドをデプロイする前にディスクをクリーンアップするためのアンダークラウド設定

第4章 Red Hat OpenStack Platform Director を使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイメント

4.1. 前提条件

4.2. Red Hat OpenStack Platform director を使用したオーバークラウドプランのエクスポート

4.3. Red Hat OpenStack Platform director を使用したオーバークラウドプランのインポート

4.4. Red Hat OpenStack Platform director を使用したオーバークラウドのデプロイ

4.5. 関連情報

第5章 コマンドラインインターフェイスを使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイ

5.1. 前提条件

5.2. コマンドラインインターフェイスを使用したオーバークラウドのデプロイ前のノードの準備

5.2.1. 前提条件

5.2.2. ハードウェアの登録およびイントロスペクション

5.2.3. ルートデバイスの設定

5.2.4. Ironic のディスククリーニングが機能していることの確認

5.2.5. 関連情報

5.3. コンテナーイメージのソースの設定

5.3.1. レジストリーメソッド

5.3.2. Red Hat OpenStack Platform サービス用の追加のコンテナーイメージの追加

5.3.3. Red Hat レジストリーをリモートレジストリーソースとして使用する方法

5.3.4. ローカルレジストリーとしてアンダークラウドを使用する方法

次のステップ

5.3.5. 関連情報

5.4. コマンドラインインターフェイスを使用したリソースの分離およびオーバークラウドのチューニング

5.4.1. 前提条件

5.4.2. ハイパーコンバージドノード向けの CPU およびメモリーリソースの確保

5.4.3. Ceph 用 CPU リソースの確保

5.4.4. Ceph 用メモリーリソースの確保

5.4.5. Ceph のバックフィルおよびリカバリー操作のチューニング

5.4.6. 関連情報

5.5. コマンドラインインターフェイスを使用したオーバークラウドの定義

5.5.1. 前提条件

5.5.2. カスタムテンプレートのディレクトリーの作成

5.5.3. オーバークラウドネットワークの設定

5.5.4. Controller ロールおよび ComputeHCI ロールの作成

5.5.5. Red Hat Ceph Storage パラメーターの設定

5.5.6. オーバークラウドノードのレイアウトの設定

5.5.7. 関連情報

5.6. コマンドラインインターフェイスを使用したオーバークラウドのデプロイ

5.6.1. 前提条件

5.6.2. Ironic で利用可能なノードの確認

5.6.3. Pacemaker フェンシング用のコントローラーの設定

5.6.4. deploy コマンドの実行

5.6.5. オーバークラウドのデプロイメントが正常に行われたことの確認

第6章 Red Hat Hyperconverged Infrastructure for Cloud ソリューションの最新バージョンへの更新

付録A Red Hat Hyperconverged Infrastructure for Cloud に必要なリポジトリー

付録B Red Hat Hyper-converaged Infrastructure for Cloud undercloud configuration parameters

付録C Red Hat Hyperconverged Infrastructure for Cloud - Nova メモリーおよび CPU calculator スクリプトソース

付録D Red Hat Hyperconverged Infrastructure for Cloud - example network.yaml file

付録E Nova 確保メモリーと CPU 割り当ての手動チューニング

付録F Nova 確保メモリーと CPU 割り当ての手動変更

Quick Links

Help

Site Info

Related Sites

Systems Status

About

Red Hat legal and privacy links

Red Hat legal and privacy links

第3章アンダークラウドのデプロイ

第5章コマンドラインインターフェイスを使用した Red Hat Hyperconverged Infrastructure for Cloud のデプロイ

付録D Red Hat Hyperconverged Infrastructure for Cloud - example `network.yaml` file