Menu Close
Settings Close

Language and Page Formatting Options

デプロイメントガイド

Red Hat Hyperconverged Infrastructure for Cloud 13

『Deploying a Red Hat Hyperconverged Infrastructure for Cloud Solution』

概要

本書では、Red Hat OpenStack Platform 13 および Red Hat Ceph Storage 3 を使用した Red Hat Hyperconverged Infrastructure for Cloud ソリューションのデプロイ方法について説明します。これらはすべて、AMD64 および Intel 64 のアーキテクチャーで稼働します。

第1章 Introducing the Red Hat Hyperconverged Infrastructure for Cloud solution

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 OpenStack Platform director の Web インターフェースまたはコマンドラインインターフェースを使用して、Red Hat Hyperconverged Infrastructure for Cloud をデプロイすることができます。以下は、基本的なデプロイメントワークフローです。

『RHHI Cloud Deployment Guide Workflow 459706 1017 JCS』

その他のリソース

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

表2.1 ノードの最小数

QTY。ロール物理/仮想

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 ロールはこのネットワークにアクセスする必要があります。
External
Red Hat OpenStack Platform director(RHOSP-d)は、外部ネットワークを使用してオーバークラウドのソフトウェア更新をダウンロードし、オーバークラウドオペレーターは RHOSP-d にアクセスしてオーバークラウドを管理します。テナントサービスが予約済みの Floating IP アドレスを介して接続を確立する場合、コントローラーは外部ネットワークを使用してトラフィックをインターネットにルーティングします。オーバークラウドユーザーは外部ネットワークを使用してオーバークラウドにアクセスします。
OpenStack Internal API
OpenStack は、パブリック向けの API エンドポイントとプライベート API エンドポイントの両方を提供します。これは、プライベートエンドポイントの分離ネットワークです。
OpenStack Tenant ネットワーク
OpenStack テナントは、このネットワーク上に VLAN または VXLAN により実装されたプライベートネットワークを作成します。
Red Hat OpenStack Platform director のプロビジョニング
Red Hat OpenStack Platform director は、このネットワークから DHCP および PXE サービスを提供し、ベアメタルからオーバークラウドノードにオペレーティングシステムおよびその他のソフトウェアをインストールします。Red Hat OpenStack Platform director は、このネットワークを使用してオーバークラウドノードを管理します。クラウドオペレーターは、必要に応じて ssh によりオーバークラウドノードに直接アクセスできます。このネットワークプロビジョニングから PXE ブートするようにオーバークラウドノードを設定する必要があります。

図2.1 ネットワーク分離図

rhhi cloud network layout
注記

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

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

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

前提条件

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

手順

  1. 任意のノードで、利用可能なサブスクリプションを確認します。

    # subscription-manager list --available --all --matches="*OpenStack*"

その他のリソース

2.5. その他のリソース

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

technician としてアンダークラウドをデプロイすることができます。これにより、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)をアンダークラウドとしてインストールします。インストール手順の概要を以下に示します。

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

前提条件

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

手順

  1. RHOSP-d インストールには、インストールを行うための sudo 権限を持つ root 以外のユーザーが必要です。

    1. stack という名前のユーザーを作成します。

      [root@director ~]# useradd stack
    2. スタック のパスワードを設定します。プロンプトが表示されたら、新しいパスワードを入力します。

      [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 ユーザーとして行われます。

  2. stack ユーザーのホームディレクトリーに、2 つの新規ディレクトリーを作成します。このディレクトリーには、1 つの名前付き テンプレート と、もう 1 つの名前付き イメージ が含まれます。

    [stack@director ~]$ mkdir ~/images
    [stack@director ~]$ mkdir ~/templates

    これらのディレクトリーは、後でオーバークラウド環境を作成するのに使用するシステムイメージファイルと Heat テンプレートファイルを整理します。

  3. プロセスのインストールおよび設定には、/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
      replace…​
      • RHOSP-d ノードの完全修飾ドメイン名(FQDN)を持つ FQDN_HOST_NAME

        [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
      replace…​
      • 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

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

    1. RHOSP-d ノードを登録します。

      [stack@director ~]$ sudo subscription-manager register

      要求されたら、承認されたカスタマーポータルのユーザー名とパスワードを入力します。

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

    3. 直前の手順の Pool ID を使用して、RHOSP のエンタイトルメントをアタッチします。

      [stack@director ~]$ sudo subscription-manager attach --pool=POOL_ID
      replace…​
      • 前の手順の有効なプールID を持つ pool_ID

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

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

      [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
    5. 必要に応じて、ベースシステムソフトウェアを最新のパッケージバージョンに更新し、RHOSP-d ノードを再起動します。

      [stack@director ~]$ sudo yum update
      [stack@director ~]$ sudo reboot

      ノードが完全に稼働するのを待ってから次の手順に進みます。

  5. RHOSP-d ソフトウェアパッケージをすべてインストールします。

    [stack@director ~]$ sudo yum install python-tripleoclient ceph-ansible
  6. RHOSP-d ソフトウェアを設定します。

    1. Red Hat は、使用する基本的なアンダークラウド設定テンプレートを提供します。undercloud.conf.sample ファイルを stack ユーザーのホームディレクトリー( undercloud.conf )にコピーします。

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

      パラメーター

      network

      値の編集

      値の例

      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 ディスククリーニングについて 」セクションを参照してください。

    3. RHOSP-d 設定スクリプトを実行します。

      [stack@director ~]$ openstack undercloud install
      注記

      このスクリプトが完了するまで数分かかります。このスクリプトにより、追加のソフトウェアパッケージがインストールされ、2 つのファイルが生成されます。

      undercloud-passwords.conf
      director サービスの全パスワード一覧
      stackrc
      director のコマンドラインツールへのアクセスに役立つ初期化変数のセット。
    4. 設定スクリプトがすべての RHOSP サービスを起動し、有効にされていることを確認します。

      [stack@director ~]$ sudo systemctl list-units openstack-*
    5. 設定スクリプトにより、stack ユーザーがすべてのコンテナー管理コマンドにアクセスできます。stack ユーザーのパーミッションを更新します。

      [stack@director ~]$ exec su -l stack
    6. RHOSP-d コマンドラインツールを使用するように stack ユーザーの環境を初期化します。

      [stack@director ~]$ source ~/stackrc

      コマンドラインプロンプトは変更されます。これは、OpenStack コマンドがアンダークラウドに対して認証および実行されることを示しています。

      (undercloud) [stack@director ~]$

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

    1. rhosp-director-images および rhosp-director-images- ipa ソフトウェアパッケージをインストールして、このディスクイメージ を取得します。

      (undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa
    2. 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
    3. ディスクイメージを RHOSP-d にインポートします。

      (undercloud) [stack@director ~]$ openstack overcloud image upload --image-path /home/stack/images/
    4. インポートされたディスクイメージの一覧を表示するには、以下のコマンドを実行します。

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

      イメージ名

      イメージタイプ

      Image Description

      bm-deploy-kernel

      deployment

      システムのプロビジョニングおよびデプロイに使用するカーネルファイル。

      bm-deploy-ramdisk

      deployment

      システムのプロビジョニングおよびデプロイに使用する ramdisk ファイル。

      overcloud-full-vmlinuz

      overcloud

      ノードのディスクに書き込まれるベースシステムに使用されるカーネルファイル。

      overcloud-full-initrd

      overcloud

      ノードのディスクに書き込まれるベースシステムに使用される ramdisk ファイル。

      overcloud-full

      overcloud

      ノードのディスクに書き込まれるベースシステムに必要な残りのソフトウェア。

      注記

      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
  8. オーバークラウドノードのホスト名を解決するように DNS サーバーを設定します。

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

      (undercloud) [stack@director ~]$ openstack subnet list
    2. アンダークラウドの neutron サブネットを使用してネームサーバーを定義します。

      openstack subnet set --dns-nameserver DNS_NAMESERVER_IP SUBNET_NAME_or_ID
      replace…​
      • DNS_NAMESERVER_IP と DNS サーバーの IP アドレス。
      • neutron サブネット名または ID の subnet_NAME _or_ID

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

        注記

        各ネームサーバーで --dns-nameserver DNS_NAMESERVER_IP オプションを再利用できます。

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

      (undercloud) [stack@director ~]$ openstack subnet show SUBNET_NAME_or_ID
      replace…​
      • neutron サブネット名または ID の subnet_NAME _or_ID

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

その他のリソース

3.4. オーバークラウドをデプロイする前にディスクをクリーニングするようにアンダークラウドを設定

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

警告

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

手順

  1. オーバークラウドをデプロイする前に、ディスクを消去する自動または手動の方法の 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
      replace…​
      • Ceph ホスト名を持つ ノード。

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

technician として、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 を使用してデプロイメントプランをエクスポートします。デフォルトのデプロイメントプランには、共通の、エクスポート可能なオーバークラウド設定が含まれています。

前提条件

手順

  1. アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーで入力します。

    注記

    SSL を使用しない場合には、アンダークラウドの URL は 3000 ポートを使用する必要があります。例: http://192.168.0.4:3000

  2. 正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェースにログインします。

    OSP Director Web UI ログイン画面モード
    注記

    デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。

    [stack@director ~]$ sudo hiera admin_password
  3. Plans タブで、ドロップダウンメニューを選択します。 1 オーバークラウド のプランから、Exportを選択します。 2 .

    OSP Director Export Plan Menu mod
  4. Download ボタンをクリックします。

    RH OSP Director Export Plan Download mod

    これにより、圧縮された 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 を使用してデプロイメントプランをインポートします。

前提条件

手順

  1. アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーで入力します。

    注記

    SSL を使用しない場合には、アンダークラウドの URL は 3000 ポートを使用する必要があります。例: http://192.168.0.4:3000

  2. 正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェースにログインします。

    OSP Director Web UI ログイン画面モード
    注記

    デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。

    [stack@director ~]$ sudo hiera admin_password
  3. Plans タブで、Import Plan ボタンを選択します。

    RH OSP Director Import Plan"," mod

  4. プラン名の入力 1 をクリックして、ファイルの選択 ボタンをクリックします。 2 .tarball ファイルの場所を参照し、インポートする場所を選択します。ファイルを選択したら、ファイルの アップロードおよびプランの作成 ボタンをクリックします。 3 .

    OSP Director Import Plan Screen mod

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

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

前提条件

手順

  1. アンダークラウドの IP アドレスまたはホスト名を Web ブラウザーで入力します。

    注記

    SSL を使用しない場合は、アンダークラウドの URL にポート 3000 を追加する必要があります。例: http://192.168.0.4:3000

  2. 正しい認証情報を使用して、Red Hat OpenStack Platform director ユーザーインターフェースにログインします。

    OSP Director Web UI ログイン画面モード
    注記

    デフォルトのユーザー名は admin です。以下のコマンドを実行して admin パスワードを取得できます。

    [stack@director ~]$ sudo hiera admin_password
  3. デフォルトの オーバークラウドプラン の選択 1 あるいは、Import Planを選択します。 2 .

    OSP Director Manage Plans Screen Import or Overcloud Plan mod

    プランのインポートに関する詳細は、を参照してください。 「Red Hat OpenStack Platform director を使用したオーバークラウドプランのインポート」

  4. プランの設定ページから、登録済みノードを追加してハードウェアを準備します。

    図4.1 プラン設定ページの例

    RH OSP Director Default Plan Main Page mod
    1. ノードの登録 ボタンをクリックします。 1 ノードの登録。

      OSP Director Overcloud Plan Workflow Screen Step1 mod
    2. 新規ノードの追加 ボタンをクリックします。 1 .

      RH OSP Director Adding Node─ mod

      ここでは、instackenv.json ホスト定義ファイルをカスタマイズし、アップロードすることでノードを準備できます。カスタムの instackenv.json ホスト定義ファイルを作成します。ノードは、「ハードウェアの登録およびイントロスペクション」 および 「ルートデバイスの設定」 を参照してください。

    3. レジスターノードのページで、小さい赤いアスタリスクで示される、すべての必須フィールドに入力します。
    4. 必要なフィールドがすべて入力されたら、ノードの登録 ボタンをクリックします。 1 .

      RH OSP Director Register node─ mod

    5. ノードが登録されたら、ノードを選択します。 1 イントロスペクションノードをクリックし て、 2 ボタンをクリックします。

      RH OSP Director Introspection─ mod1

    6. イントロスペクションが完了したら、ノードを選択します。 1指定して、プロビジョニングノードをクリックします。 2 ボタンをクリックします。

      RH OSP Director Introspection─ mod2

  5. プラン設定ページから、デプロイメント設定を編集します。

    1. Edit Configuration ボタンをクリックします。 1 .

      OSP Director Overcloud Plan Workflow Screen Step2 mod
    2. 全体の設定 タブで 1General Deployment Options」 セクションをクリックします。 2 「」で、Docker、コンテナー化されたデプロイメント、および デフォルトのコンテナー イメージを介して HA サービス を有効にし ます。

      RH OSP Director Configure the General Deployment Options mod
    3. 全体の設定 タブで 1 ストレージ セクションをクリックします。 2 Ceph Storage バックエンドの有効化 3 .

      RH OSP Director Overall Settings Storage セクション Ceph mod

      Save Changes ボタンをクリックします。

      OSP Director Overall Settings Save Cancel Set mod
    4. Parameters タブをクリックします。 1 次に、Ceph Storage Backend セクションをクリックします。 2 追加の Ceph パラメーターを編集するには、以下を実行します。

      RH OSP Director Parameters Tab Ceph Storage Backend mod

      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 として使用されるブロックデバイス(デバイス)と、OSD ジャーナルとして専用のブロックデバイス(dedicated_devices)に使用されます。詳細は 「Red Hat Ceph Storage パラメーターの設定」 を参照してください。

    5. Save and Close ボタンを クリックします。

      OSP Director Overall Settings Save Cancel Set mod
    6. プラン設定ページに戻ると、保存された設定変更は、デプロイメント設定の指定 ステップの下に表示されます。

      OSP Director Overcloud Plan Workflow Screen Complete Config Step2 mod
  6. Manage Roles リンクをクリックして、ハイパーコンバージドノードのロールを設定します。 1 .

    RH OSP Director Manage Roles mod
    1. BlockStorageの選択を解除します。 1 , CephStorage 2 および Compute 3 ロールをクリックして、そのロールをクリックします。

      RH OSP Director Manage Roles uncheck Default Roles mod
    2. ComputeHCIを選択します。 1 ロールをクリックして行います。

      RH OSP Director Manage Roles Check ComputeHCI Role mod
    3. プラン設定ページに戻り、レバースアイコンをクリックして Compute HCI ロールを設定します。 1 .

      OSP director による ComputeHCI ロールの設定
    4. Parameters タブで、以下のパラメーターを更新します。

      • 計算されたリソース割り当ての値を持つ ExtraConfig フィールド。

        適切な値を計算する 付録E Nova 予約メモリーおよび CPU 割り当てを手動で調整する 方法についてはを参照してください。

      • 環境 関連するすべての IP アドレスを持つ ComputeHCIIPs フィールド

        {"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 ボタンを クリックします。

      OSP Director Overall Settings Save Cancel Set mod
    6. プラン設定ページに戻り、レバーアイコンをクリックして Controller ロールを設定します。 1 .

      OSP director でのコントローラーロールの設定
    7. Parameters タブで 1 に、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 タブで 1 , Ntp セクション2NtpServer フィールドを更新します。 3 関連する NTP サーバー名

      RH OSP Director NtpServer Field mod
    9. Save and Close ボタンを クリックします。

      OSP Director Overall Settings Save Cancel Set mod
  7. 各ロールに必要なノード数を割り当てます。

    図4.2 例

    OSP director の各ノードへの完全な割り当て
  8. プラン設定ページから、設定の 編集ボタン をクリックします。 1 .

    OSP Director Overcloud Plan Workflow Screen Step2 mod

    Network Configuration セクションをクリックして、ネットワーク設定を編集します。 1 で、ネットワーク分離を選択します。 2 .

    OSP director の Overall Settings ネットワーク設定モード

    1. NIC 設定テンプレートのいずれかを選択するか、カスタムプランを使用します。

      RH OSP Director Select NIC Configuration mod

      環境内の NIC をカスタマイズするには、まずプランをエクスポートする必要があります。

      プランのエクスポート 「Red Hat OpenStack Platform director を使用したオーバークラウドプランのエクスポート」 方法を参照してください。

      1. プラン tarball ファイルをダウンロードし、ローカルに必要な追加または変更を行います。

        RH OSP Director Export Plan Download mod

      2. プラン tarball ファイルを更新したら、ドロップダウンメニューをクリックして 編集 を選択します。

        RH OSP Director Edit Custom Plan mod

      3. プランをインポートします。プラン名の入力 1 をクリックして、ファイルの選択 ボタンをクリックします。 2 .tarball ファイルの場所を参照し、インポートする場所を選択します。ファイルを選択したら、ファイルの アップロードおよびプランの作成 ボタンをクリックします。 3 .

        OSP Director Import Plan Screen mod

      4. Edit Configuration ボタンをクリックします。

        OSP Director Overcloud Plan Workflow Screen Step2 mod

      5. 全体の設定 タブで 1 他の セクションをクリックします。 2 .
      6. Others セクションを選択し、カスタムテンプレートを追加します。
      7. ファイルリストから新規または変更されたファイルを選択します。

        OSP Director Include Custom Config File mod

      8. Parameters タブをクリックし、それに応じて値を更新します。
  9. 今回のリリースにより、プランのデプロイがタイミングで済みます。プランの設定ページから、検証とデプロイボタンをクリックして、 オーバークラウドプランをデプロイします。

    RH OSP Director Validate and Deploy mod
  10. オーバークラウドのデプロイメントが完了するまで待ちます。

4.5. その他のリソース

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

テクニカルユーザーは、コマンドラインインターフェースを使用して、Red Hat Hyperconverged Infrastructure for Cloud ソリューションをデプロイおよび管理することができます。

5.1. 前提条件

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

オーバークラウドをデプロイする前に、technician として、環境で使用されるハードウェアを理解する必要があります。

注記

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 ユーザーとして以下の手順を実行します。

  1. 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
  2. Ironic サービスがノードを管理するホスト定義ファイルを作成して設定します。

    1. instackenv.json ホスト定義ファイルを作成します。

      [stack@director ~]$ touch ~/instackenv.json
    2. 以下のテンプレートを使用して、各ノードの定義ブロックを スタンザ 角括弧({"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"
      },
      replace…​
      • IPMI_USER_PASSWORD は、IPMI パスワードに置き換えます。
      • ノードの説明的な名前を持つ node_NAME。これはオプションのパラメーターです。
      • IPMI_USER_NAME は、ノードの電源のオン/オフにアクセスできる IPMI ユーザー名に置き換えます。
      • IPMI_IP_ADDR と IPMI IP アドレス
      • PXE ブートを処理するネットワークカード MAC アドレスを含むNIC_MAC_ADDR
      • NODE_ROLE-INSTANCE_NUM は、ノードのロールとノード番号に置き換えます。このソリューションでは、controlosd-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"
  3. ノードを Ironic データベースにインポートします。

    [stack@director ~]$ openstack baremetal import ~/instackenv.json
    1. openstack baremetal import コマンドにより、全ノードで Ironic データベースが設定されていることを確認します。

      [stack@director ~]$ openstack baremetal node list
  4. ベアメタルブートカーネルおよび RAMdisk イメージをすべてのノードに割り当てます。

    [stack@director ~]$ openstack baremetal configure boot
  5. ノードを起動するには、ハードウェアデータを収集し、その情報を 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 Customization』の「 Controlling Node Placement 」の章を参照してください。

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

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

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

  • OSD : /dev/[sda, sdb, …​、SDL] ブロックデバイス
  • OSD ジャーナル : 3 x 400GB SATA SSD ディスクが /dev/[sdm, sdn, sdo] ブロックデバイスとして表示される
  • オペレーティングシステム : RAID 1 で設定された 2 x 250GB SAS ディスクが /dev/sdp ブロックデバイスとして示されて います。

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

手順

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

  1. 最小 のルートデバイスを使用するように、root ディスクデバイスを設定します。

    [stack@director ~]$ openstack baremetal configure boot --root-device=smallest

または

  1. ディスクの by-path 名を使用するように、root ディスクデバイスを設定します。

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

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

  1. 正しいルートディスクデバイスが設定されていることを確認します。

    openstack baremetal introspection data save NODE_NAME_or_UUID | jq .
    replace…​
    ノードのホスト名または UUID を持つ node_NAME _or_UUID。

その他のリソース

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

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

前提条件

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

手順

  1. ノードの状態を管理するように設定します。

    openstack baremetal node manage $NODE_NAME

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

  2. ノードの状態を以下のように設定します。

    openstack baremetal node provide NODE_NAME

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

  3. ノードのステータスを確認します。

    openstack node list

5.2.5. その他のリソース

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

technician として、オーバークラウドのコンテナー化が可能ですが、まず必要なコンテナーイメージを持つレジストリーへのアクセスが必要になります。ここでは、レジストリーおよびオーバークラウドの設定を準備して 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 はこれらのサービスが有効化されていることを確認してイメージを準備する必要があります。

前提条件

  • 実行中のアンダークラウド

手順

  1. stack ユーザーとして、アンダークラウドノードで openstack overcloud container image prepare コマンドを使用して追加のサービスを追加します。

    1. -e オプションを使用して以下の環境ファイルを追加します。

      • Ceph Storage クラスター: /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
    2. 以下の --set オプションを Red Hat Ceph Storage に追加します。

      --set ceph_namespace
      Red Hat Ceph Storage コンテナーイメージ用の名前空間を定義します。
      --set ceph_image
      Red Hat Ceph Storage コンテナーイメージの名前を定義します。image name: rhceph-3-rhel7 を使用します。
      --set ceph_tag
      Red Hat Ceph Storage コンテナーイメージに使用するタグを定義します。--tag-from-label を指定すると、バージョンタグはこのタグから検出されます。
  2. 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 と名前空間のみであるため、最も簡単な方法です。

前提条件

  • Cloud 10 環境向けの稼働中の Red Hat Hyperconverged Infrastructure。
  • インターネットへのアクセス

手順

  1. オーバークラウドのデプロイメントで 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 オプションを使用して、オプションのサービス用の環境ファイルを追加します。

  2. これで、イメージの場所が記載された overcloud_images.yaml 環境ファイルがアンダークラウド上に作成されます。今後のアップグレード操作およびデプロイメント操作ではすべてこのファイルを追加してください。

その他のリソース

  • 詳細は、『Red Hat Hyperconverged Infrastructure for Cloud Deployment Guide』の「 Including additional container images for Red Hat OpenStack Platform servicesセクション を参照してください

5.3.4. ローカルレジストリーとしてのアンダークラウドの使用

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

  • director は、registry.access.redhat.com から各イメージをプルします。
  • director はオーバークラウドを作成します。

    • オーバークラウドの作成時に、ノードは適切なイメージをアンダークラウドからプルします。

前提条件

  • 稼働中の Red Hat Hyperconverged Infrastructure for Cloud 環境
  • インターネットへのアクセス

手順

  1. イメージをローカルレジストリーにプルするためのテンプレートを作成します。

    (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 コマンドとは異なる値を使用します。

  2. これにより、コンテナーイメージの情報を含む 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 のディスク領域を使用します。

  3. ローカルイメージの namespace を検索します。namespace は以下のパターンを使用します。

    <REGISTRY_IP_ADDRESS>:8787/rhosp13

    undercloud .conf ファイルの local_ip パラメーターで以前に設定したアンダークラウド の IP アドレスを使用します。以下のコマンドを使用すると、完全な名前空間を取得することもできます。

    (undercloud) [stack@director ~]$ docker images | grep -v redhat.com | grep -o '^.*rhosp13' | sort -u
  4. アンダークラウドのローカルレジストリーでイメージを使用するためのテンプレートを作成します。以下に例を示します。

    (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 コマンドとは異なる値を使用します。

  5. これにより、アンダークラウド上のイメージの場所が記載された overcloud_images.yaml 環境ファイルが作成されます。今後のアップグレード操作およびデプロイメント操作ではすべてこのファイルを追加してください。

その他のリソース

  • 詳細は、『 Red Hat Hyperconverged Infrastructure for Cloud Deployment Guide』の「 Including additional container images for Red Hat OpenStack Platform servicesセクション を参照してください。

次のステップ

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

5.3.5. その他のリソース

  • 詳細は、『 Red Hat OpenStack Platform Fast Forward Upgrades Guide』 の「 セクション 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 Compute サービスにリソースの制約を設定することができます。プランの環境ファイルはワークフローを定義し、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 に以下を指示します。

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

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

上記の例では、平均ゲストは 2 GB のメモリーと、その CPU の 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% を使用することを前提としています。

その他のリソース

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

ハイパーコンバージドのデプロイメントでは、CPU リソースに対する Nova Compute プロセスと Ceph プロセスの間で競合が生じる可能性があります。デフォルトでは、ceph-ansibledocker run コマンドで --cpu-quota オプションを使用して、OSD を 1 つの vCPU に制限します。ceph_osd_docker_cpu_limit オプションはこのデフォルトの制限をオーバーライドするため、Ceph OSD プロセスごとに追加の vCPU を使用できます。以下に例を示します。

CephAnsibleExtraConfig:
  ceph_osd_docker_cpu_limit: 2

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

重要

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

その他のリソース

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

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

ceph_osd_docker_memory_limit オプションは、使用される Ceph オブジェクトストアバックエンド(FileStore または BlueStore のいずれか)にかかわらず、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 オブジェクトストア機能で導入されました。

その他のリソース

5.4.5. Ceph のバックフィルおよびリカバリー操作の調整

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

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

osd_recovery_max_active
1 OSD あたりのアクティブなリカバリー要求の数。要求がこの値を超えるとリカバリーが加速されますが、要求によりクラスターに負荷が増大します。
osd_max_backfills
1 つの OSD との間で許可されるバックフィルの最大数。
osd_recovery_op_priority
リカバリー操作の優先度セット。これは、osd クライアント op の優先度と相対的です。

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

その他のリソース

5.4.6. その他のリソース

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

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

5.5.1. 前提条件

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

Red Hat Hyperconverged Infrastructure for Cloud オーバークラウドを定義する手順の概要は次のとおりです。

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

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

前提条件

手順

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

  1. カスタムテンプレート用に新規ディレクトリーを作成します。

    [stack@director ~]$ mkdir -p ~/templates/nic-configs

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

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

前提条件

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

手順

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

  1. 環境に適した Compute 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 を参照してください。

  2. ~/templates/ ディレクトリーに新規ディレクトリーを作成します。

    [stack@director ~]$ touch ~/templates/nic-configs
  3. 選択したテンプレートを ~/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

  4. すでに注記されている場合は、~/templates/nic-configs/compute-hci.yaml ファイルの parameters: セクションに以下の定義を追加します。

    StorageMgmtNetworkVlanID:
        default: 40
        description: Vlan ID for the storage mgmt network traffic.
        type: number
  5. StorageMgmtNetworkVlanID を各ノードの特定の NIC にマッピングします。たとえば、単一の NIC(single-nic-vlans/compute.yaml)へのトランク VLAN を選択する場合には、以下のエントリーを ~/templates/nic-configs/compute-hci.yamlnetwork_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 にマッピングする際に mtu9000 に設定することを推奨します。この MTU 設定により、Red Hat Ceph Storage のパフォーマンスが大幅に向上します。詳細は、『Red Hat OpenStack Platform Advanced Overcloud Customization』ガイドの「 ジャンボフレームの設定 」を参照してください。

  6. カスタム templates ディレクトリーに新規ファイルを作成します。

    [stack@director ~]$ touch ~/templates/network.yaml
  7. network.yaml ファイルを開いて編集します。

    1. resource_registry セクションを追加します。

      resource_registry:
    2. 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 ノードのネットワーク設定にそれぞれポイントします。

    3. parameter_defaults セクションを追加します。

      parameter_defaults:
    4. テナントネットワークの Neutron ブリッジマッピングに、以下のデフォルトパラメーターを追加します。

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

      これにより、論理ネットワークに割り当てられるブリッジマッピングを定義し、テナントが vxlan を使用できるようにします。

    5. ステップ 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"]
      replace…​
      • 適切なIP アドレスとネットマスク(CIDR)のある IP_ADDR_ CIDR。
      • IP_ADDR_START は、適切な開始 IP アドレスに置き換えます。
      • 適切な終了IP アドレスを持つ IP_ADDR_END
      • 適切なIP アドレスの IP_ADDRESS
      • vlan_ID に対応するネットワークに適した VLAN 識別番号。
      • DNS_SERVER_IP は、コンマ(,)で区切られた 2 つの DNS サーバーを定義する適切な IP アドレスに置き換えます。

        network.yaml ファイルの例については、付録 を参照してください。

その他のリソース

  • ネットワーク分離 に関する詳しい情報は、『Red Hat OpenStack Platform Advance Overcloud Customization』を参照してください。

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

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

前提条件

手順

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

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

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

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

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

前提条件

手順

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

  1. ~/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

      replace…​

      Ceph PG 計算関数から計算さ た値を持つ num

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

      • OSD : /dev/[sda, sdb, …​、sdg] ブロックデバイス
      • OSD WAL および DB デバイス : 2 x 400GB NVMe SSD ディスクが /dev/[nvme0n1, nvme1n1] ブロックデバイスとして提示されます。

その他のリソース

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

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

前提条件

手順

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

  1. カスタム templates ディレクトリーに layout.yaml ファイルを作成します。

    [stack@director ~]$ touch ~/templates/layout.yaml
  2. 編集する layout.yaml ファイルを開きます。

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

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

        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
    3. parameter _defaults というパラメーター のデフォルトに新しいセクションを追加し、本セクションの下に以下のパラメーターを追加します。

      parameter_defaults:
        NtpServer: NTP_IP_ADDR
        ControllerHostnameFormat: 'controller-%index%'
        ComputeHCIHostnameFormat: 'compute-hci-%index%'
        ControllerCount: 3
        ComputeHCICount: 3
        OvercloudComputeFlavor: compute
        OvercloudComputeHCIFlavor: osd-compute
      replace…​

      NTP ソースの IP アドレスを持つ NTP_IP_ADDR。時間同期は非常に重要です。

      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 つのコンピュート/OSD ノードをデプロイします。

    4. parameter_defaults セクションで、2 つのスケジューラーヒント( ControllerSchedulerHints ともう 1 つは ComputeHCISchedulerHints)を追加し ます。それぞれのスケジューラーヒントに、以下のように予測可能なノード配置用のノード名の形式を追加します。

        ControllerSchedulerHints:
          'capabilities:node': 'control-%index%'
        ComputeHCISchedulerHints:
          'capabilities:node': 'osd-compute-%index%'
    5. 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 には 192.168.2.200、192.168.3.200、172.16.1.200 および 172.16.2.200 の IP アドレスがあり ます

5.5.7. その他のリソース

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

technician として、オーバークラウドノードをデプロイして、Nova Compute サービスと Ceph OSD サービスが同じノードに配置されるようにすることができます。

5.6.1. 前提条件

5.6.2. Ironic で利用可能なノードの検証

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

警告

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

前提条件

  • Red Hat OpenStack Platform director ノードで stack ユーザーが利用可能になる

手順

  1. 以下のコマンドを実行して、全ノードの電源がオフになっていることを確認します。

    [stack@director ~]$ openstack baremetal node list

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

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

前提条件

  • IPMI のユーザーおよびパスワード
  • Red Hat OpenStack Platform director ノードで stack ユーザーが利用可能になる

手順

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

    [stack@director ~]$ openstack overcloud generate fencing --ipmi-lanplus instackenv.json --output fencing.yaml
  2. openstack overcloud deploy コマンドで fencing.yaml ファイルを指定します。

その他のリソース

5.6.4. デプロイコマンドの実行

すべてのカスタマイズとチューニングが完了したら、オーバークラウドをデプロイすることになります。

注記

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

前提条件

手順

  1. 以下のコマンドを実行します。

    [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 オプションを追加します。

  2. オーバークラウドのデプロイメントが完了するまで待ちます。

その他のリソース

5.6.5. オーバークラウドのデプロイメントが成功したことの確認

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

前提条件

  • Red Hat OpenStack Platform director ノードで stack ユーザーが利用可能になる

手順

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

    [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
  2. デプロイメントが完了したら、オーバークラウドノードの IP アドレスを表示します。

    [stack@director ~]$ openstack server list

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

エンジニアとして、Red Hat Hyperconverged Infrastructure for Cloud ソリューションを最新バージョンの Red Hat OpenStack Platform 13 および Red Hat Ceph Storage 3 に更新できます。Red Hat Hyperconverged Infrastructure for Cloud ソフトウェアセットを最新バージョンに更新するには、Red Hat OpenStack Platform 13 のドキュメントを参照してください。

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

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

name

リポジトリー

要件の説明

Red Hat Enterprise Linux 7 Server(RPMs)

rhel-7-server-rpms

ベースオペレーティングシステムのリポジトリー。

Red Hat Enterprise Linux 7 Server - Extras(RPMs)

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 アドレスをルーティングされた IP アドレスとして、/32 ネットマスクを使用します。
undercloud_admin_vip
director の Admin API 用に定義する IP アドレス。他の IP アドレスまたはアドレス範囲と競合しないプロビジョニングネットワーク上の IP アドレスを使用します。director の設定では、この IP アドレスをルーティングされた IP アドレスとして、/32 ネットマスクを使用します。
local_interface
director のプロビジョニング NIC 用に選択するインターフェース。これは、director が DHCP および PXE ブートサービスに使用するデバイスでもあります。設定スクリプトにより、このインターフェースを inspection_interface パラメーターで定義したカスタムブリッジにアタッチします。
network_cidr
オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの neutron サービスが管理するプロビジョニングネットワークです。
masquerade_network
外部アクセス用にマスカレードするネットワークを定義します。これにより、プロビジョニングネットワークにネットワークアドレス変換(NAT)の一部が提供されるため、director 経由で外部アクセスが可能になります。
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 計算用スクリプトソース

これは、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 ファイル

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)です。ハイパーコンバージドコンピュート/OSD ノードでは、必要なリソースのいずれかのサービスが不足しないように、2 つのサービス間でメモリーを共有する必要があります。

以下は、ハイパーコンバージドノードの reserved_host_memory_mb 値を決定する方法の例になります。256GB の RAM と 10 OSD のノードがあり、各 OSD は 3GB の RAM(Ceph では 30GB の RAM)を消費し、Nova Compute 用に 226GB の RAM を残すことを前提とします。平均ゲストが 2 GB の RAM を使用する場合には、システム全体が 113 ゲストマシンをホストできます。ただし、対応する必要のあるハイパーバイザーで実行中の各ゲストマシンには追加のオーバーヘッドがあります。このオーバーヘッドが 500MB であるとすると、実行できる 2 GB のゲストマシンの最大数は約 90 になります。

数値式を以下に示します。

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

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

概算のゲストマシン数と OSD 数を指定すると、Nova 用に確保するメモリー量は算出できます。

novareservationd Memory in MB = 1000 *( OSD のメモリーサイズ(GB * OSD 数 )+(約数 のゲストマシン * ハイパーバイザーメモリーオーバーヘッド(GB 単位 ))

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

そのため、reserved_host_memory_mb75000 になります。パラメーターの値はメガバイト(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 コアと OSD があり、1 つのコアが各 OSD によって使用されていることを前提として、Nova 用に 46 コアを残すことになります。各ゲストマシンがコアの 100% を使用している場合、ゲストマシンで利用可能なコアの数は、ノード上のコアの合計数で除算されます。このシナリオでは、cpu_allocation_ratio の値は 0.821429 です

ただし、ゲストマシンは通常、コアの使用率を 100% 使用していないため、ゲストマシンごとのコア数を決定する際に、予想される使用率のパーセンテージを考慮する必要があります。平均的に想定されるのは、ゲストマシンごとの 10% コア使用率のみで、cpu_allocation_ratio の値は 8.214286 である必要があり ます

数値式を以下に示します。

  1. Non Ceph Cores = ノード 上のコア数の合計数 :(OSD あたりのコア 数 * OSD
  2. ゲスト仮想マシンの vCPU 数 = Ceph コア / 平均ゲスト仮想マシンの CPU 使用率の数
  3. CPU 割り当て Ratio = ノード上 のゲストマシンの vCPU 数/コア数の合計数

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

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

Red Hat は、これらの計算を行う計算スクリプトを提供しています。スクリプト名は 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
replace…​
  • Total_NODE_RAM_GB: ノードの合計サイズ(GB 単位)。
  • Total_NODE_CORES (ノードの合計コア数)
  • num_OSDs_PER_NODE (ノードあたりの Ceph OSD の数)。
  • ゲストマシンの平均メモリーサイズ(GB 単位)の Avg_GUEST_MEM_SIZE_ 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 予約済みメモリーと CPU の手動割り当ての変更

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

前提条件

手順

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

  1. カスタム templates ディレクトリーに compute.yaml ファイルを作成します。

    [stack@director ~]$ touch ~/templates/compute.yaml
  2. 編集する compute.yaml ファイルを開きます。

    1. reserved_host_memory および cpu_ allocation_ratio 設定パラメーターを、パラメーター defaults セクションの下に ExtraConfig セクションに追加します。

      parameter_defaults:
        ExtraConfig:
          nova::compute::reserved_host_memory: MEMORY_SIZE_IN_MB
          nova::cpu_allocation_ratio: CPU_RATIO
      replace…​
      • メモリーサイズがメガバイト(MB)の memory_SIZE_IN_ MB。
      • 比率の 10 進数の値を持つCPU_RATIO

            nova::compute::reserved_host_memory: 75000
            nova::cpu_allocation_ratio: 8.2

        注記

        Red Hat OpenStack Platform director は、reserved_host_memory パラメーターとして Nova が使用する reserved_host_memory_ mb パラメーターを参照します。