director のインストールと使用方法

Red Hat OpenStack Platform 15

Red Hat OpenStack Platform director を使用した OpenStack クラウド作成のエンドツーエンドシナリオ

OpenStack Documentation Team

概要

本ガイドでは、エンタープライズ環境で Red Hat OpenStack Platform director を使用して Red Hat OpenStack Platform 15 をインストールする方法について説明します。これには、director のインストール、環境のプランニング、director を使用した OpenStack 環境の構築などが含まれます。

第1章 はじめに

Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (「OpenStack-On-OpenStack」の略語) をベースとしています。このプロジェクトは OpenStack のコンポーネンで構成され、これらのコンポーネントを使用して完全に機能する OpenStack 環境をインストールすることができます。これには、OpenStack ノードとして使用するベアメタルシステムのプロビジョニングや制御を行う OpenStack のコンポーネントが含まれます。director により、効率的で堅牢性の高い、完全な Red Hat OpenStack Platform 環境を簡単にインストールできます。

Red Hat OpenStack Platform director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を採用しています。アンダークラウドがオーバークラウドのインストールおよび設定を行います。以降の数セクションで、それぞれの概念について説明します。

Basic Layout of undercloud and overcloud

1.1. アンダークラウド

アンダークラウドは、OpenStack Platform director ツールセットが含まれる主要管理ノードです。OpenStack をインストールした単一システムで、OpenStack 環境 (オーバークラウド) を構成する OpenStack ノードをプロビジョニング/管理するためのコンポーネントが含まれます。アンダークラウドを構成するコンポーネントは、さまざまな機能を持ちます。

環境のプランニング
アンダークラウドには、ユーザーが特定のノードロールを作成して割り当てるためのプランニング機能が含まれます。アンダークラウドには、コンピュート、コントローラー、さまざまなストレージロールなど、デフォルトのノードセットが含まれます。また、カスタムロールを設定することもできます。さらに、各ノードロールにどの OpenStack Platform サービスを含めるかを選択でき、新しいノード種別をモデル化するか、独自のホストで特定のコンポーネントを分離する方法を提供します。
ベアメタルシステムの制御
アンダークラウドは、各ノードの Intelligent Platform Management Interface (IPMI) などのアウトバンド管理インターフェースを使用して電源管理機能を制御し、PXE ベースのサービスを使用してハードウェア属性を検出し、各ノードに OpenStack をインストールします。この機能を使用して、ベアメタルシステムを OpenStack ノードとしてプロビジョニングすることができます。電源管理ドライバーの全一覧については、「付録A 電源管理ドライバー」を参照してください。
オーケストレーション
アンダークラウドには、環境のプランのセットに対応する YAML テンプレートセットが含まれます。アンダークラウドは、これらのプランをインポートして、その指示に従い、目的の OpenStack 環境を作成します。このプランに含まれるフックを使用して、環境作成プロセスの特定のポイントとして、カスタマイズを組み込むこともできます。
アンダークラウドのコンポーネント

アンダークラウドは、OpenStack のコンポーネントをベースのツールセットとして使用します。各コンポーネントは、アンダークラウドの個別のコンテナー内で動作します。

  • OpenStack Identity (keystone): director のコンポーネントの認証および承認
  • OpenStack Bare Metal (Ironic) および OpenStack Compute (Nova): ベアメタルノードの管理
  • OpenStack Networking (Neutron) および Open vSwitch: ベアメタルノードのネットワークの制御
  • OpenStack Image サービス (glance): director がベアメタルマシンに書き込むイメージの格納
  • OpenStack Orchestation (Heat) および Puppet: director がオーバークラウドイメージをディスクに書き込んだ後のノードのオーケストレーションおよび設定
  • OpenStack Telemetry (Ceilometer): 監視とデータの収集。これには、以下が含まれます。

    • OpenStack Telemetry Metrics (gnocchi): メトリック向けの時系列データベース
    • OpenStack Telemetry Alarming (aodh): モニタリング向けのアラームコンポーネント
    • OpenStack Telemetry Event Storage (panko): モニタリング向けのイベントストレージ
  • OpenStack Workflow サービス (mistral): プランのインポートやデプロイなど、特定の director 固有のアクションに対してワークフローセットを提供します。
  • OpenStack Messaging Service (zaqar): OpenStack Workflow サービスのメッセージサービスを提供します。
  • OpenStack Object Storage (swift): 以下のさまざまな OpenStack Platform のコンポーネントに対してオブジェクトストレージを提供します。

    • OpenStack Image サービスのイメージストレージ
    • OpenStack Bare Metal のイントロスペクションデータ
    • OpenStack Workflow サービスのデプロイメントプラン

1.2. オーバークラウド

オーバークラウドは、アンダークラウドが構築することで得られる Red Hat OpenStack Platform 環境です。オーバークラウドは、さまざまなロールを持つ複数のノードで構成されます。このノード構成は、希望する OpenStack Platform 環境をベースに定義されます。アンダークラウドには、以下に示すオーバークラウドのデフォルトノードロールセットが含まれます。

コントローラー

コントローラーノードは、OpenStack 環境に管理、ネットワーク、高可用性の機能を提供します。コントローラーノード 3 台で高可用性クラスターを構成する OpenStack 環境が推奨されます。

デフォルトのコントローラーノードには、以下のコンポーネントが含まれます。

  • OpenStack Dashboard (horizon)
  • OpenStack Identity (keystone)
  • OpenStack Compute (nova) API
  • OpenStack Networking (neutron)
  • OpenStack Image サービス (glance)
  • OpenStack Block Storage (cinder)
  • OpenStack Object Storage (swift)
  • OpenStack Orchestration (heat)
  • OpenStack Telemetry Metrics (gnocchi)
  • OpenStack Telemetry Alarming (aodh)
  • OpenStack Telemetry Event Storage (panko)
  • OpenStack Clustering (sahara)
  • OpenStack Shared File Systems (manila)
  • OpenStack Bare Metal (ironic)
  • MariaDB
  • Open vSwitch
  • 高可用性サービス向けの Pacemaker および Galera
コンピュート

コンピュートノードは OpenStack 環境にコンピュートリソースを提供します。コンピュートノードをさらに追加して、環境を徐々にスケールアウトすることができます。デフォルトのコンピュートノードには、以下のコンポーネントが含まれます。

  • OpenStack Compute (nova)
  • KVM/QEMU
  • OpenStack Telemetry (ceilometer) エージェント
  • Open vSwitch
ストレージ

ストレージノードは OpenStack 環境にストレージを提供します。以下の一覧で、Red Hat OpenStack Platform のさまざまなストレージノード種別について説明します。

  • Ceph Storage ノード: ストレージクラスターを構成するために使用します。それぞれのノードには、Ceph Object Storage Daemon (OSD) が含まれます。また、環境の一部として Ceph Storage ノードをデプロイする場合には、director により Ceph Monitor がコントローラーノードにインストールされます。
  • Block storage (cinder): 高可用性コントローラーノードの外部ブロックストレージとして使用します。このノードには、以下のコンポーネントが含まれます。

    • OpenStack Block Storage (cinder) ボリューム
    • OpenStack Telemetry エージェント
    • Open vSwitch
  • Object Storage (swift): これらのノードは、OpenStack Swift の外部ストレージ層を提供します。コントローラーノードは、Swift プロキシーを介してオブジェクトストレージノードにアクセスします。オブジェクトストレージノードには、以下のコンポーネントが含まれます。

    • OpenStack Object Storage (swift) のストレージ
    • OpenStack Telemetry エージェント
    • Open vSwitch

1.3. 高可用性

Red Hat OpenStack Platform director は、OpenStack Platform 環境に高可用性サービスを提供するためにコントローラーノードクラスターを使用します。それぞれのサービスについて、director はすべてのコントローラーノードに同じコンポーネントをインストールし、コントローラーノードをまとめて単一のサービスとして管理します。このタイプのクラスター構成では、1 つのコントローラーノードが機能しなくなった場合にフォールバックが可能です。これにより、OpenStack のユーザーには一定レベルの運用継続性が提供されます。

OpenStack Platform director は、複数の主要なソフトウェアを使用して、コントローラーノード上のコンポーネントを管理します。

  • Pacemaker: Pacemaker は、クラスターのリソースを管理します。Pacemaker は、クラスター内の全ノードにわたって OpenStack コンポーネントの可用性を管理および監視します。
  • HA Proxy: クラスターに負荷分散およびプロキシーサービスを提供します。
  • Galera: クラスター全体の OpenStack Platform データベースを複製します。
  • Memcached: データベースのキャッシュを提供します。
注記
  • バージョン 13 から、director を使用してコンピュートインスタンスの高可用性 (インスタンス HA) をデプロイできるようになりました。インスタンス HA により、コンピュートノードで障害が発生した際にコンピュートノードからインスタンスを自動的に退避させることができます。

1.4. コンテナー化

アンダークラウドおよびオーバークラウド上の各 OpenStack Platform サービスは、対応するノード上の個別の Linux コンテナー内で実行されます。このコンテナー化により、サービスを分離し、環境を維持し、OpenStack Platform をアップグレードすることができます。

Red Hat OpenStack Platform 15 では、Red Hat Enterprise Linux 8 オペレーティングシステムへのインストールがサポートされます。Red Hat Enterprise Linux 8 には Docker が含まれなくなり、Docker エコシステムに代わる新たなツールセットが用意されています。したがって、OpenStack Platform 15 では、Docker に代わるこれらの新しいツールにより、OpenStack Platform のデプロイメントおよびアップグレードを行います。

Podman

Pod Manager (Podman) はコンテナー管理用のツールです。このツールには、ほとんどすべての Docker CLI コマンドが実装されています。ただし、Docker Swarm に関連するコマンドは含まれません。Podman は、ポッド、コンテナー、およびコンテナーイメージを管理します。Podman と Docker の主な違いの 1 つは、Podman がバックグラウンドでデーモンを実行せずにリソースを管理できることです。

Podman についての詳しい情報は、Podman の Web サイト を参照してください。

Buildah

Buildah は Open Containers Initiative (OCI) イメージのビルドに特化したツールで、Podman と共に使用します。Buildah コマンドは、Dockerfile のコマンドと等価です。Buildah は、コンテナーイメージをビルドするための低レベル coreutils インターフェースも提供します。これは、Dockerfile を使用せずにコンテナーをビルドするのに役立ちます。また、Buildah は他のスクリプト言語を使用してコンテナーイメージをビルドしますが、その際にデーモンは必要ありません。

Buildah についての詳しい情報は、Buildah の Web サイト を参照してください。

Skopeo
Skopeo により、運用者はリモートコンテナーイメージを検査することができます。これは、director がイメージをプルする際にデータを収集するのに役立ちます。この機能に加えて、コンテナーイメージをあるレジストリーから別のレジストリーにコピーしたり、イメージをレジストリーから削除したりすることもできます。

以下に示すように、Red Hat では、オーバークラウド用コンテナーイメージを取得するためのさまざまな方法をサポートしています。

  • Red Hat Container Catalog から直接コンテナーイメージをプルする
  • アンダークラウドでコンテナーイメージをホストする
  • Satellite 6 サーバーでコンテナーイメージをホストする

本ガイドでは、コンテナーイメージレジストリー情報の設定および基本的なコンテナー操作の実施について説明します。

1.5. Ceph Storage

通常、OpenStack を使用する大規模な組織では、数千単位またはそれ以上のクライアントにサービスを提供します。ブロックストレージリソースの消費に関して、それぞれの OpenStack クライアントは固有のニーズを持つのが一般的です。glance (イメージ)、cinder (ボリューム)、nova (コンピュート) を単一ノードにデプロイすると、数千単位のクライアントがある大規模なデプロイメントでの管理ができなくなる可能性があります。このような課題は、OpenStack をスケールアウトすることによって解決できます。

ただし、実際には、Red Hat Ceph Storage などのソリューションを活用して、ストレージ層を仮想化する必要もでてきます。ストレージ層の仮想化により、Red Hat OpenStack Platform のストレージ層を数十テラバイト規模からペタバイトさらにはエクサバイトのストレージにスケーリングすることが可能です。Red Hat Ceph Storage は、市販のハードウェアを使用しながらも、高可用性/高パフォーマンスのストレージ仮想化層を提供します。仮想化によってパフォーマンスが低下するというイメージがありますが、Ceph はブロックデバイスイメージをクラスター全体でオブジェクトとしてストライプ化するため、大きな Ceph のブロックデバイスイメージはスタンドアロンのディスクよりも優れたパフォーマンスを示します。Ceph ブロックデバイスでは、パフォーマンスを強化するために、キャッシュ、Copy On Write クローン、Copy On Read クローンもサポートされています。

Red Hat Ceph Storage に関する情報は、「Red Hat Ceph Storage」を参照してください。

注記

マルチアーキテクチャークラウドでは、Red Hat は事前にインストール済みの Ceph 実装または外部の Ceph 実装のみをサポートします。詳細は、『Integrating an Overcloud with an Existing Red Hat Ceph Cluster』および「付録B Red Hat OpenStack Platform for POWER」を参照してください。

パート I. director のインストールと設定

第2章 アンダークラウドのプランニング

2.1. コンテナー化されたアンダークラウド

アンダークラウド は、最終的な OpenStack Platform 環境 (オーバークラウド と呼ばれる) の設定、インストール、および管理をコントロールするノードです。アンダークラウド自体は、コンテナー化された OpenStack Platform コンポーネントを使用して、OpenStack Platform director と呼ばれるツールセットを作成します。この場合、アンダークラウドはレジストリーソースからコンテナーイメージのセットをプルし、コンテナーの設定を生成し、各 OpenStack Platform サービスをコンテナーとして実行します。その結果、アンダークラウドによりコンテナー化されたサービスのセットが提供され、このサービスをオーバークラウドの作成および管理用ツールセットとして使用することができます。

アンダークラウドおよびオーバークラウドの両方でコンテナーが使用されているので、どちらも同じアーキテクチャーを使用してコンテナーをプル、設定、および実行します。このアーキテクチャーは、OpenStack Orchestration サービス (heat) をベースにノードをプロビジョニングし、Ansible を使用してサービスおよびコンテナーを設定します。Heat および Ansible に関する知識を習得していると、異常発生時のトラブルシューティングに役立ちます。

2.2. アンダークラウドネットワークの準備

アンダークラウドでは、2 つの主要ネットワークへのアクセスが必要です。

  • プロビジョニングまたはコントロールプレーンネットワーク: director は、このネットワークを使用してノードをプロビジョニングし、Ansible 設定の実行時に SSH 経由でこれらのノードにアクセスします。このネットワークでは、アンダークラウドからオーバークラウドノードへの SSH アクセスも可能です。アンダークラウドには、このネットワーク上の他のノードのイントロスペクションおよびプロビジョニング用 DHCP サービスが含まれます。つまり、このネットワーク上にその他の DHCP サービスは必要ありません。director がこのネットワークのインターフェースを設定します。
  • 外部ネットワーク: このネットワークにより、OpenStack Platform リポジトリー、コンテナーイメージソース、および DNS サーバーや NTP サーバー等の他のサーバーにアクセスすることができます。ご自分のワークステーションからアンダークラウドへの標準アクセスには、このネットワークを使用します。外部ネットワークにアクセスするためには、アンダークラウド上でインターフェースを手動で設定する必要があります。

アンダークラウドには、少なくとも 2 枚の 1 Gbps ネットワークインターフェースカードが必要です。1 枚は プロビジョニングまたはコントロールプレーンネットワーク 用で、残りの 1 枚は 外部ネットワーク 用です。ただし、特にオーバークラウド環境で多数のノードをプロビジョニングする場合には、ネットワークトラフィックのプロビジョニング用に 10 Gbps インターフェースを使用することを推奨します。

以下の点に注意してください。

  • プロビジョニング/コントロールプレーン用には、ワークステーションから director マシンへのアクセスに使用する NIC とは別の NIC を使用するようにしてください。director のインストールでは、プロビジョニング NIC を使用してブリッジが作成され、リモート接続はドロップされます。director システムへリモート接続する場合には、外部 NIC を使用します。
  • プロビジョニングネットワークには、環境のサイズに適した IP 範囲が必要です。以下のガイドラインを使用して、この範囲に含めるべき IP アドレスの総数を決定してください。

    • イントロスペクション中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの一時 IP アドレスを含めます。
    • デプロイメント中は、プロビジョニングネットワークに接続されているノードごとに少なくとも 1 つの永続的な IP アドレスを含めます。
    • プロビジョニングネットワーク上のオーバークラウド高可用性クラスターの仮想 IP 用に、追加の IP アドレスを含めます。
    • 環境のスケーリング用に、この範囲にさらに IP アドレスを追加します。

2.3. 環境規模の判断

アンダークラウドをインストールする前に、環境の規模を判断することを推奨します。環境をプランニングする際には、以下の要素を考慮してください。

  • オーバークラウド内のノードの数: アンダークラウドは、オーバークラウド内の各ノードを管理します。オーバークラウドノードのプロビジョニングには、アンダークラウドのリソースが使用されます。オーバークラウドノードを適切にプロビジョニングし管理するには、アンダークラウドに十分なリソースを提供する必要があります。
  • アンダークラウドで実行する同時操作の数: アンダークラウド上の OpenStack サービスの多くは、ワーカー のセットを使用します。それぞれのワーカーは、そのサービスに固有の操作を実行します。複数のワーカーを用いると、同時に操作を実行することができます。アンダークラウドのワーカー数のデフォルト値は、アンダークラウドの合計 CPU スレッド数の半分です[1]。たとえば、アンダークラウドが 16 スレッドの CPU を持つ場合、デフォルトでは director のサービス は 8 つのワーカーを提供します。デフォルトでは、director のサービスに最小および最大のワーカー数も適用されます。
サービス最小値最大値

OpenStack Orchestration (heat)

4

24

その他すべてのサービス

2

12

アンダークラウドの CPU およびメモリーの最低要件を以下に示します。

  • Intel 64 または AMD64 CPU 拡張機能をサポートする、8 スレッド 64 ビット x86 プロセッサー。これにより、各アンダークラウドサービスに 4 つのワーカーが提供されます。
  • 最小 24 GB の RAM。

    • ceph-ansible Playbook は、アンダークラウドによりデプロイされたホスト 10 台につき 1 GB の常駐セットサイズ (RSS) を消費します。デプロイされたオーバークラウドが既存の Ceph クラスターを使用する、または新たな Ceph クラスターをデプロイする場合には、それに応じてアンダークラウド用 RAM をプロビジョニングしてください。

多数のワーカーを使用するには、以下の推奨事項に従ってアンダークラウドの vCPU 数およびメモリー容量を増やします。

  • 最小値: 1 スレッドあたり 1.5 GB のメモリーを使用します。たとえば、48 スレッドのマシンには 72 GB の RAM が必要です。これは、Heat 用 24 ワーカーとその他のサービス用 12 ワーカーを提供するのに最低限必要なリソースです。
  • 推奨値: 1 スレッドあたり 3 GB のメモリーを使用します。たとえば、48 スレッドのマシンには 144 GB の RAM が必要です。これは、Heat 用 24 ワーカーとその他のサービス用 12 ワーカーを提供するのに推奨されるリソースです。


[1] ここでは、スレッド数とは CPU コア数にハイパースレッディングの値を掛けたものを指します

2.4. アンダークラウドのディスクサイズ

アンダークラウドのディスクサイズとして、ルートディスク上に少なくとも 100 GB の空きディスク領域があることが推奨されます。

  • コンテナーイメージ用に 20 GB
  • QCOW2 イメージの変換とノードのプロビジョニングプロセスのキャッシュ用に 10 GB
  • 一般用途、ログの記録、メトリック、および将来の拡張用に 70 GB 以上

2.5. アンダークラウドのリポジトリー

アンダークラウドをインストールおよび設定するには、以下のリポジトリーを有効にします。

コアリポジトリー

以下の表には、アンダークラウドをインストールするためのコアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

rhel-8-for-x86_64-baseos-rpms

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

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs)

rhel-8-for-x86_64-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 x86_64 (RPMs)

ansible-2.8-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Advanced Virtualization for RHEL 8 x86_64 (RPMs)

advanced-virt-for-rhel-8-x86_64-rpm

OpenStack Platform 用仮想化パッケージを提供します。

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-6.5-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat OpenStack Platform 15 for RHEL 8 (RPMs)

openstack-15-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー。Red Hat OpenStack Platform director のパッケージが含まれます。

Ceph 用リポジトリー

以下の表には、アンダークラウド用の Ceph Storage 関連リポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Ceph Storage Tools 4 for RHEL 8 x86_64 (RPMs)

rhceph-4-tools-for-rhel-8-x86_64-rpms

Ceph Storage クラスターと通信するためのノード用のツールを提供します。オーバークラウドで Ceph Storage を使用する場合には、アンダークラウドにこのリポジトリーからの ceph-ansible パッケージが必要です。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で OpenStack Platform を構築するためのリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

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

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.8-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 15 for RHEL 8 (RPMs)

openstack-15-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

第3章 director インストールの準備

3.1. アンダークラウドの準備

director のインストールには、以下の項目が必要です。

  • コマンドを実行するための非 root ユーザー
  • イメージとテンプレートを管理するためのディレクトリー
  • 解決可能なホスト名
  • Red Hat サブスクリプション
  • イメージの準備および director のインストールを行うためのコマンドラインツール

以下の手順で、これらの項目を作成する方法について説明します。

手順

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

    [root@director ~]# useradd stack
  3. そのユーザーのパスワードを設定します。

    [root@director ~]# passwd stack
  4. sudo を使用する場合にパスワードを要求されないようにします。

    [root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@director ~]# chmod 0440 /etc/sudoers.d/stack
  5. 新規作成した stack ユーザーに切り替えます。

    [root@director ~]# su - stack
    [stack@director ~]$
  6. システムイメージおよび heat テンプレート用のディレクトリーを作成します。

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

    director はシステムのイメージと Heat テンプレートを使用して、オーバークラウド環境を構築します。ローカルファイルシステムの管理を容易にするために、Red Hat ではこれらのディレクトリーを作成することを推奨します。

  7. アンダークラウドのベースおよび完全なホスト名を確認します。

    [stack@director ~]$ hostname
    [stack@director ~]$ hostname -f

    上記のコマンドのいずれかで正しい完全修飾ホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。

    [stack@director ~]$ sudo hostnamectl set-hostname manager.example.com
    [stack@director ~]$ sudo hostnamectl set-hostname --transient manager.example.com
  8. /etc/hosts を編集して、システムのホスト名のエントリーを追加します。/etc/hosts の IP アドレスは、アンダークラウドのパブリック API に使用する予定のアドレスと一致する必要があります。たとえば、システムの名前が manager.example.com で、IP アドレスに 10.0.0.1 を使用する場合には、/etc/hosts に以下のように入力する必要があります。

    10.0.0.1  manager.example.com manager
  9. Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite のどちらかにシステムを登録します。たとえば、システムをコンテンツ配信ネットワークに登録するには、以下のコマンドを実行します。要求されたら、カスタマーポータルのユーザー名およびパスワードを入力します。

    [stack@director ~]$ sudo subscription-manager register
  10. Red Hat OpenStack Platform director のエンタイトルメントプール ID を検索します。以下に例を示します。

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Subscription Name:   Name of SKU
    Provides:            Red Hat Single Sign-On
                         Red Hat Enterprise Linux Workstation
                         Red Hat CloudForms
                         Red Hat OpenStack
                         Red Hat Software Collections (for RHEL Workstation)
                         Red Hat Virtualization
    SKU:                 SKU-Number
    Contract:            Contract-Number
    Pool ID:             Valid-Pool-Number-123456
    Provides Management: Yes
    Available:           1
    Suggested:           1
    Service Level:       Support-level
    Service Type:        Service-Type
    Subscription Type:   Sub-type
    Ends:                End-date
    System Type:         Physical
  11. Pool ID の値を特定して、Red Hat OpenStack Platform 15 のエンタイトルメントをアタッチします。

    [stack@director ~]$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
  12. デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    [stack@director ~]$ sudo subscription-manager repos --disable=*
    [stack@director ~]$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-15-for-rhel-8-x86_64-rpms --enable=fast-datapath-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-rpm

    これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。

  13. システムで更新を実行して、ベースシステムパッケージが最新の状態になるようにします。

    [stack@director ~]$ sudo yum update -y
    [stack@director ~]$ sudo reboot
  14. director のインストールと設定を行うためのコマンドラインツールをインストールします。

    [stack@director ~]$ sudo yum install -y python3-tripleoclient

3.2. ceph-ansible のインストール

Ceph Storage ノードを持つオーバークラウドを作成する場合には、以下の手順により ceph-ansible パッケージをインストールします。オーバークラウドで Ceph Storage ノードを作成しない場合には、このパッケージは必要ありません。

手順

ceph-ansible パッケージをインストールします。

[stack@director ~]$ sudo yum install -y ceph-ansible
注記

Red Hat Ceph Storage バージョン 4 が一般提供になるまで、更新バージョンの ceph-ansible バージョン 4 は openstack-15-for-rhel-8-x86_64-rpms リポジトリーから利用可能です。Red Hat Ceph Storage バージョン 4 が一般提供になったら、rhceph-4-tools-for-rhel-8-x86_64-rpms リポジトリーから ceph-ansible をインストールします。

3.3. コンテナーイメージの準備

アンダークラウドの設定には、イメージの取得先およびその保存方法を定義するための初期レジストリーの設定が必要です。コンテナーイメージを準備するための環境ファイルを生成およびカスタマイズするには、以下の手順を実施します。

手順

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. デフォルトのコンテナーイメージ準備ファイルを生成します。

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

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

    • --local-push-destination: コンテナーイメージの保管場所として、アンダークラウド上のレジストリーを設定します。つまり、director は必要なイメージを Red Hat Container Catalog からプルし、それをアンダークラウド上のレジストリーにプッシュします。director はこのレジストリーをコンテナーイメージのソースとして使用します。Red Hat Container Catalog から直接プルする場合には、このオプションを省略します。
    • --output-env-file: 環境ファイルの名前です。このファイルには、コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。

      注記

      アンダークラウドとオーバークラウド両方のコンテナーイメージのソースを定義するのに、同じ containers-prepare-parameter.yaml ファイルを使用することができます。

  3. containers-prepare-parameter.yaml を編集し、要求に合わせて変更を加えます。

3.4. コンテナーイメージ準備のパラメーター

コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare Heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare の各設定で使用することのできるサブパラメーターの情報をまとめています。

パラメーター説明

excludes

設定から除外するイメージの名前に含まれる文字列のリスト

includes

設定に含めるイメージの名前に含まれる文字列のリスト。少なくとも 1 つのイメージ名が既存のイメージと一致している必要があります。includes パラメーターを指定すると、excludes の設定はすべて無視されます。

modify_append_tag

対象となるイメージのタグに追加する文字列。たとえば、14.0-89 のタグが付けられたイメージをプルし、modify_append_tag-hotfix に設定すると、director は最終イメージを 14.0-89-hotfix とタグ付けします。

modify_only_with_labels

変更するイメージを絞り込むイメージラベルのディクショナリー。イメージが定義したラベルと一致する場合には、director はそのイメージを変更プロセスに含めます。

modify_role

イメージのアップロード中 (ただし目的のレジストリーにプッシュする前) に実行する Ansible ロール名の文字列

modify_vars

modify_role に渡す変数のディクショナリー

push_destination

アップロードプロセス中にイメージをプッシュするレジストリーの名前空間。このパラメーターで名前空間を指定すると、すべてのイメージパラメーターでもこの名前空間が使用されます。true に設定すると、push_destination はアンダークラウドレジストリーの名前空間に設定されます。実稼働環境では、このパラメーターを false に設定することは推奨されません。

pull_source

元のコンテナーイメージをプルするソースレジストリー

set

初期イメージの取得場所を定義する、キー:値 定義のディクショナリー

tag_from_label

得られたイメージをタグ付けするラベルパターンを定義します。通常は、{version}-{release} に設定します。

set パラメーターには、複数の キー:値 定義を設定することができます。以下の表には、キーの情報をまとめています。

キー説明

ceph_image

Ceph Storage コンテナーイメージの名前

ceph_namespace

Ceph Storage コンテナーイメージの名前空間

ceph_tag

Ceph Storage コンテナーイメージのタグ

name_prefix

各 OpenStack サービスイメージの接頭辞

name_suffix

各 OpenStack サービスイメージの接尾辞

namespace

各 OpenStack サービスイメージの名前空間

neutron_driver

使用する OpenStack Networking (neutron) コンテナーを定義するのに使用するドライバー。標準の neutron-server コンテナーに設定するには、null 値を使用します。OVN ベースのコンテナーを使用するには、ovn に設定します。OpenDaylight ベースのコンテナーを使用するには、odl に設定します。

tag

ソースレジストリーからプルするイメージを識別するために director が使用するタグ。通常、このキーは latest に設定したままにします。

ContainerImageRegistryCredentials パラメーターは、コンテナーレジストリーをそのレジストリーに対して認証を行うためのユーザー名とパスワードにマッピングします。

コンテナーレジストリーでユーザー名およびパスワードが必要な場合には、ContainerImageRegistryCredentials を使用して以下の構文でその値を設定することができます。

  ContainerImagePrepare:
  - push_destination: 192.168.24.1:8787
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

上記の例の my_username および my_password を、ご自分の認証情報に置き換えてください。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。詳しくは、「Red Hat コンテナーレジストリーの認証」を参照してください。

3.5. イメージ準備エントリーの階層化

ContainerImagePrepare パラメーターの値は YAML リストです。したがって、複数のエントリーを指定することができます。以下の例で、2 つのエントリーを指定するケースを説明します。この場合、director はすべてのイメージの最新バージョンを使用しますが、nova-api イメージについてのみ、15.0-44 とタグ付けされたバージョンを使用します。

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp15-rhel8
    name_prefix: openstack-
    name_suffix: ''
    tag: latest
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp15-rhel8
    tag: 15.0-44

includes および excludes のエントリーで、それぞれのエントリーでのイメージの絞り込みをコントロールします。includes 設定と一致するイメージが、excludes と一致するイメージに優先します。一致するとみなされるためには、イメージ名に includes または excludes の設定値が含まれていなければなりません。

3.6. プライベートレジストリーからのコンテナーイメージの取得

一部のコンテナーイメージレジストリーでは、イメージにアクセスするのに認証が必要になる場合があります。そのような場合には、containers-prepare-parameter.yaml 環境ファイルの ContainerImageRegistryCredentials パラメーターを使用します。

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ContainerImageRegistryCredentials:
    registry.example.com:
      username: "p@55w0rd!"
重要

プライベートレジストリーでは、ContainerImagePrepareの該当する設定について、push_destinationtrue に設定する必要があります。

ContainerImageRegistryCredentials パラメーターは、プライベートレジストリーの URL に基づくキーのセットを使用します。それぞれのプライベートレジストリーの URL は、独自のキーと値のペアを使用して、ユーザー名 (キー) およびパスワード (値) を定義します。これにより、複数のプライベートレジストリーに対して認証情報を指定することができます。

parameter_defaults:
  ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      myuser: 'p@55w0rd!'
    registry.internalsite.com:
      myuser2: '0th3rp@55w0rd!'
    '192.0.2.1:8787':
      myuser3: '@n0th3rp@55w0rd!'
重要

デフォルトの ContainerImagePrepare パラメーターは、認証が必要な registry.redhat.io から Ceph Storage コンテナーイメージをプルします。

3.7. 準備プロセスにおけるイメージの変更

イメージの準備中にイメージを変更し、変更したイメージで直ちにデプロイすることが可能です。イメージを変更するシナリオを以下に示します。

  • デプロイメント前にテスト中の修正でイメージが変更される、連続した統合パイプラインの一部として。
  • ローカルの変更をテストおよび開発のためにデプロイしなければならない、開発ワークフローの一部として。
  • 変更をデプロイしなければならないが、イメージビルドパイプラインでは利用することができない場合。たとえば、プロプライエタリーアドオンの追加または緊急の修正など。

準備プロセス中にイメージを変更するには、変更する各イメージで Ansible ロールを呼び出します。ロールはソースイメージを取得して必要な変更を行い、その結果をタグ付けします。prepare コマンドでイメージを目的のレジストリーにプッシュし、変更したイメージを参照するように heat パラメーターを設定することができます。

Ansible ロール tripleo-modify-image は要求されたロールインターフェースに従い、変更のユースケースに必要な処理を行います。変更は、ContainerImagePrepare パラメーターの変更固有のキーを使用してコントロールします。

  • modify_role では、変更する各イメージについて呼び出す Ansible ロールを指定します。
  • modify_append_tag は、ソースイメージタグの最後に文字列を追加します。これにより、そのイメージが変更されていることが明確になります。すでに push_destination レジストリーに変更されたイメージが含まれている場合には、このパラメーターを使用して変更を省略します。イメージを変更する場合には、必ず modify_append_tag を変更することを推奨します。
  • modify_vars は、ロールに渡す Ansible 変数のディクショナリーです。

tripleo-modify-image ロールが処理するユースケースを選択するには、tasks_from 変数をそのロールで必要なファイルに設定します。

イメージを変更する ContainerImagePrepare エントリーを開発およびテストする場合には、イメージが想定どおりに変更されることを確認するために、追加のオプションを指定せずにイメージの準備コマンドを実行することを推奨します。

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

3.8. コンテナーイメージの既存パッケージの更新

以下の ContainerImagePrepare エントリーは、アンダークラウドホストの yum リポジトリー設定を使用してイメージのパッケージをすべて更新する例です。

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

3.9. コンテナーイメージへの追加 RPM ファイルのインストール

RPM ファイルのディレクトリーをコンテナーイメージにインストールすることができます。この機能は、ホットフィックス、ローカルパッケージビルド、またはパッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。たとえば、以下の ContainerImagePrepare エントリーにより、nova-compute イメージだけにホットフィックスパッケージがインストールされます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

3.10. カスタム Dockerfile を使用したコンテナーイメージの変更

柔軟性を高めるために、Dockerfile を含むディレクトリーを指定して必要な変更を加えることが可能です。tripleo-modify-image ロールを呼び出すと、ロールは Dockerfile.modified ファイルを生成し、これにより FROM ディレクティブが変更され新たな LABEL ディレクティブが追加されます。以下の例では、nova-compute イメージでカスタム Dockerfile が実行されます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

/home/stack/nova-custom/Dockerfile の例を以下に示します。USER root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。

FROM registry.redhat.io/rhosp15-rhel8/openstack-nova-compute:latest

USER "root"

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"

3.11. コンテナーイメージ管理用 Satellite サーバーの準備

Red Hat Satellite 6 には、レジストリーの同期機能が備わっています。これにより、複数のイメージを Satellite サーバーにプルし、アプリケーションライフサイクルの一環として管理することができます。また、他のコンテナー対応システムも Satellite をレジストリーとして使うことができます。コンテナーイメージ管理の詳細は、『Red Hat Satellite 6 コンテンツ管理ガイド』「コンテナーイメージの管理」を参照してください。

以下の手順は、Red Hat Satellite 6 の hammer コマンドラインツールを使用した例を示しています。組織には、例として ACME という名称を使用しています。この組織は、実際に使用する Satellite 6 の組織に置き換えてください。

注記

この手順では、registry.redhat.io のコンテナーイメージにアクセスするために認証情報が必要です。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。詳しくは、「Red Hat コンテナーレジストリーの認証」を参照してください。

手順

  1. すべてのコンテナーイメージの一覧を作成します。

    $ sudo podman search --limit 1000 "registry.redhat.io/rhosp15-rhel8" | awk '{ print $2 }' | grep -v beta | sed "s/registry.redhat.io\///g" | tail -n+2 > satellite_images
  2. Satellite 6 の hammer ツールがインストールされているシステムに satellite_images_names ファイルをコピーします。あるいは、『Red Hat Satellite Hammer CLI ガイド』に記載の手順に従って、アンダークラウドに hammer ツールをインストールします。
  3. 以下の hammer コマンドを実行して、実際の Satellite 組織に新規製品 (OSP15 Containers) を作成します。

    $ hammer product create \
      --organization "ACME" \
      --name "OSP15 Containers"

    このカスタム製品に、イメージを保管します。

  4. 製品にベースコンテナーイメージを追加します。

    $ hammer repository create \
      --organization "ACME" \
      --product "OSP15 Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name rhosp15-rhel8/openstack-base \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name base
  5. satellite_images ファイルからオーバークラウドのコンテナーイメージを追加します。

    $ while read IMAGE; do \
      IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
      hammer repository create \
      --organization "ACME" \
      --product "OSP15 Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name $IMAGE \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name $IMAGENAME ; done < satellite_images_names
  6. Ceph Storage 4 コンテナーイメージを追加します。

    $ hammer repository create \
      --organization "ACME" \
      --product "OSP15 Containers" \
      --content-type docker \
      --url https://registry.redhat.io \
      --docker-upstream-name rhceph-beta/rhceph-4-rhel8 \
      --upstream-username USERNAME \
      --upstream-password PASSWORD \
      --name rhceph-4-rhel8
  7. コンテナーイメージを同期します。

    $ hammer product synchronize \
      --organization "ACME" \
      --name "OSP15 Containers"

    Satellite サーバーが同期を完了するまで待ちます。

    注記

    設定によっては、hammer から Satellite サーバーのユーザー名およびパスワードが要求される場合があります。設定ファイルを使って自動的にログインするように hammer を設定することができます。詳しくは、『Red Hat Satellite Hammer CLI ガイド』「認証」セクションを参照してください。

  8. お使いの Satellite 6 サーバーでコンテンツビューが使われている場合には、新たなバージョンのコンテンツビューを作成してイメージを反映し、アプリケーションライフサイクルの環境に従ってプロモートします。この作業は、アプリケーションライフサイクルをどのように構成するかに大きく依存します。たとえば、ライフサイクルに production という名称の環境があり、その環境でコンテナーイメージを利用可能にする場合には、コンテナーイメージを含むコンテンツビューを作成し、そのコンテンツビューを production 環境にプロモートします。詳しくは、『Red Hat Satellite コンテンツ管理ガイド』の「コンテンツビューによるコンテナーイメージの管理」を参照してください。
  9. base イメージに使用可能なタグを確認します。

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --environment "production" \
      --content-view "myosp15" \
      --product "OSP15 Containers"

    このコマンドにより、特定環境のコンテンツビューでの OpenStack Platform コンテナーイメージのタグが表示されます。

  10. アンダークラウドに戻り、Satellite サーバーをソースとして使用して、イメージ準備用のデフォルト環境ファイルを生成します。以下のサンプルコマンドを実行して環境ファイルを生成します。

    (undercloud) $ openstack tripleo container image prepare default \
      --output-env-file containers-prepare-parameter.yaml
    • --output-env-file: 環境ファイルの名前です。このファイルには、アンダークラウド用コンテナーイメージを準備するためのパラメーターが含まれます。ここでは、ファイル名は containers-prepare-parameter.yaml です。
  11. containers-prepare-parameter.yaml ファイルを編集して以下のパラメーターを変更します。

    • namespace: Satellite サーバー上のレジストリーの URL およびポート。Red Hat Satellite のデフォルトのレジストリーポートは 5000 です。
    • name_prefix: プレフィックスは Satellite 6 の命名規則に基づきます。これは、コンテンツビューを使用するかどうかによって異なります。

      • コンテンツビューを使用する場合、構成は [org]-[environment]-[content view]-[product]- となります。たとえば、acme-production-myosp15-osp15_containers- 等。
      • コンテンツビューを使用しない場合、構成は [org]-[product]- となります。たとえば、acme-osp15_containers- 等。
    • ceph_namespaceceph_imageceph_tag: Ceph Storage を使用する場合には、Ceph Storage のコンテナーイメージの場所を定義する追加のパラメーターを指定します。ceph_image に Satellite 固有のプレフィックスが追加された点に注意してください。このプレフィックスは、name_prefix オプションと同じ値です。

Satellite 固有のパラメーターが含まれる環境ファイルの例を、以下に示します。

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      ceph_image: acme-production-myosp15-osp15_containers-rhceph-4
      ceph_namespace: satellite.example.com:5000
      ceph_tag: latest
      name_prefix: acme-production-myosp15-osp15_containers-
      name_suffix: ''
      namespace: satellite.example.com:5000
      neutron_driver: null
      tag: latest
      ...
    tag_from_label: '{version}-{release}'

アンダークラウドおよびオーバークラウドの両方を作成する際に、この環境ファイルを使用します。

第4章 director のインストール

4.1. director の設定

director のインストールプロセスでは、director が stack ユーザーのホームディレクトリーから読み取る undercloud.conf 設定ファイルに、特定の設定が必要になります。以下の手順では、デフォルトのテンプレートをベースに使用して設定を行う方法についてを説明します。

手順

  1. デフォルトのテンプレートを stack ユーザーのホームディレクトリーにコピーします。

    [stack@director ~]$ cp \
      /usr/share/python-tripleoclient/undercloud.conf.sample \
      ~/undercloud.conf
  2. undercloud.conf ファイルを編集します。このファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。

4.2. director の設定パラメーター

以下の一覧で、undercloud.conf ファイルを設定するパラメーターについて説明します。エラーを避けるために、パラメーターは決して該当するセクションから削除しないでください。

デフォルト値

undercloud.conf ファイルの [DEFAULT] セクションで定義されているパラメーターを以下に示します。

additional_architectures

オーバークラウドがサポートする追加の (カーネル) アーキテクチャーの一覧。現在、オーバークラウドは ppc64le アーキテクチャーをサポートしています。

注記

ppc64le のサポートを有効にする場合には、ipxe_enabledFalse に設定する必要もあります。

certificate_generation_ca
要求した証明書を署名する CA の certmonger のニックネーム。generate_service_certificate パラメーターを設定した場合に限り、このオプションを使用します。local CA を選択する場合は、certmonger はローカルの CA 証明書を /etc/pki/ca-trust/source/anchors/cm-local-ca.pem に抽出し、証明書をトラストチェーンに追加します。
clean_nodes
デプロイメントを再実行する前とイントロスペクションの後にハードドライブを消去するかどうかを定義します。
cleanup
一時ファイルをクリーンナップします。デプロイメント時に使用した一時ファイルをコマンド実行後もそのまま残すには、このパラメーターを False に設定します。ファイルを残すと、生成されたファイルのデバッグを行う場合やエラーが発生した場合に役に立ちます。
container_cli
コンテナー管理用の CLI ツール。Red Hat Enterprise Linux 8 は podman のみをサポートするため、このパラメーターは podman に設定したままにしてください。
container_healthcheck_disabled
コンテナー化されたサービスのヘルスチェックを無効にします。このオプションは false に設定したままにして、ヘルスチェックを有効な状態に維持することを推奨します。
container_images_file

コンテナーイメージ情報が含まれる Heat 環境ファイル。このパラメーターは、以下のいずれかに設定します。

  • 必要なすべてのコンテナーイメージのパラメーター。
  • 必要なイメージの準備を実施する ContainerImagePrepare パラメーター。このパラメーターが含まれるファイルの名前は、通常 containers-prepare-parameter.yaml です。
container_insecure_registries
podman が使用するセキュアではないレジストリーの一覧。プライベートコンテナーレジストリー等の別のソースからイメージをプルする場合には、このパラメーターを使用します。多くの場合、podman は Red Hat Container Catalog または Satellite サーバー (アンダークラウドが Satellite に登録されている場合) のいずれかからコンテナーイメージをプルするための証明書を持ちます。
container_registry_mirror
設定により podman が使用するオプションの registry-mirror
custom_env_files
アンダークラウドのインストールに追加する新たな環境ファイル。
deployment_user
アンダークラウドをインストールするユーザー。現在のデフォルトユーザー (stack) を使用する場合には、このパラメーターを未設定のままにします。
discovery_default_driver
自動的に登録されたノードのデフォルトドライバーを設定します。enable_node_discovery を有効にし、enabled_hardware_types ファイルにドライバーを含める必要があります。
enable_ironic、enable_ironic_inspector、enable_mistral、enable_tempest、enable_validations、enable_zaqar
director で有効にするコアサービスを定義します。これらのパラメーターは true に設定されたままにします。
enable_node_discovery
イントロスペクションの ramdisk を PXE ブートする不明なノードを自動的に登録します。新規ノードは、fake_pxe ドライバーをデフォルトとして使用しますが、discovery_default_driver を設定して上書きすることもできます。また、イントロスペクションルールを使用して、新しく登録したノードにドライバーの情報を指定することもできます。
enable_novajoin
アンダークラウドの novajoin メタデータサービスをインストールするかどうかを定義します。
enable_routed_networks
ルーティングされたコントロールプレーンネットワークのサポートを有効にするかどうかを定義します。
enable_swift_encryption
保存データの Swift 暗号化を有効にするかどうかを定義します。
enable_telemetry
アンダークラウドに OpenStack Telemetry サービス (gnocchi、aodh、panko) をインストールするかどうかを定義します。Telemetry サービスを自動的にインストール/設定するには、enable_telemetry パラメーターを true に設定します。デフォルト値は false で、アンダークラウド上の telemetry が無効になります。このパラメーターは、Red Hat CloudForms などのメトリックデータを消費する他の製品を使用している場合に必要です。
enabled_hardware_types
アンダークラウドで有効にするハードウェアタイプの一覧。
generate_service_certificate
アンダークラウドのインストール時に SSL/TLS 証明書を生成するかどうかを定義します。これは undercloud_service_certificate パラメーターに使用します。アンダークラウドのインストールで、作成された証明書 /etc/pki/tls/certs/undercloud-[undercloud_public_vip].pem を保存します。certificate_generation_ca パラメーターで定義される CA はこの証明書に署名します。
heat_container_image
使用する heat コンテナーイメージの URL。未設定のままにします。
heat_native
ネイティブの heat テンプレートを使用します。true のままにします。
hieradata_override
director に Puppet hieradata を設定するための hieradata オーバーライドファイルへのパス。これにより、サービスに対して undercloud.conf パラメーター以外のカスタム設定を行うことができます。設定すると、アンダークラウドのインストールでこのファイルが /etc/puppet/hieradata ディレクトリーにコピーされ、階層の最初のファイルに設定されます。この機能の使用方法の詳細は、「アンダークラウドへの hieradata の設定」を参照してください。
inspection_extras
イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。このパラメーターを使用するには、イントロスペクションイメージに python-hardware または python-hardware-detect パッケージが必要です。
inspection_interface
ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。LOCAL_INTERFACE でこのブリッジをアタッチします。これは、デフォルトの br-ctlplane のままにします。
inspection_runbench
ノードイントロスペクション時に一連のベンチマークを実行します。ベンチマークを有効にするには、このパラメーターを true に設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。
ipa_otp
IPA サーバーにアンダークラウドノードを登録するためのワンタイムパスワードを定義します。これは、enable_novajoin が有効な場合に必要です。
ipxe_enabled
iPXE か標準の PXE のいずれを使用するか定義します。デフォルトは true で iPXE を有効化します。false に指定すると、標準の PXE に設定されます。
local_interface

director のプロビジョニング NIC 用に選択するインターフェース。director は、DHCP および PXE ブートサービスにもこのデバイスを使用します。この値を選択したデバイスに変更します。接続されているデバイスを確認するには、ip addr コマンドを使用します。ip addr コマンドの出力結果の例を、以下に示します。

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:75:24:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.178/24 brd 192.168.122.255 scope global dynamic eth0
       valid_lft 3462sec preferred_lft 3462sec
    inet6 fe80::5054:ff:fe75:2409/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state DOWN
    link/ether 42:0b:c2:a5:c1:26 brd ff:ff:ff:ff:ff:ff

この例では、外部 NIC は eth0 を、プロビジョニング NIC は未設定の eth1 を使用します。今回は、local_interfaceeth1 に設定します。この設定スクリプトにより、このインターフェースが inspection_interface パラメーターで定義したカスタムのブリッジにアタッチされます。

local_ip
director のプロビジョニング NIC 用に定義する IP アドレス。director は、DHCP および PXE ブートサービスにもこの IP アドレスを使用します。環境内の既存の IP アドレスまたはサブネットと競合するなどの理由により、プロビジョニングネットワークに別のサブネットを使用する場合以外は、この値はデフォルトの 192.168.24.1/24 のままにします。
local_mtu
local_interface に使用する MTU。
local_subnet
PXE ブートと DHCP インターフェースに使用するローカルサブネット。local_ip アドレスがこのサブネットに含まれている必要があります。デフォルトは ctlplane-subnet です。
net_config_override
ネットワーク設定のオーバーライドテンプレートへのパス。このパラメーターを設定すると、アンダークラウドは JSON 形式のテンプレートを使用して os-net-config でネットワークを設定します。アンダークラウドは、undercloud.conf に設定されているネットワークパラメーターを無視します。/usr/share/python-tripleoclient/undercloud.conf.sample の例を参照してください。
networks_file
heat をオーバーライドするネットワークファイル。
output_dir
状態、処理された heat テンプレート、および Ansible デプロイメントファイルを出力するディレクトリー。
overcloud_domain_name

オーバークラウドのデプロイ時に使用する DNS ドメイン名。

注記

オーバークラウドを設定する際に、CloudDomain パラメーターに overcloud_domain_name と同じ値を設定する必要があります。オーバークラウドを設定する際に、環境ファイルでこのパラメーターを設定します。

roles_file
アンダークラウドのインストールを上書きするロールファイル。director のインストールにデフォルトのロールファイルが使用されるように、未設定のままにすることを強く推奨します。
scheduler_max_attempts
スケジューラーがインスタンスのデプロイを試行する最大回数。スケジューリング時に競合状態にならないように、この値を 1 度にデプロイする予定のベアメタルノードの数以上に指定する必要があります。
service_principal
この証明書を使用するサービスの Kerberos プリンシパル。FreeIPA など CA で Kerberos プリンシパルが必要な場合に限り、このパラメーターを使用します。
subnets
プロビジョニングおよびイントロスペクション用のルーティングネットワークのサブネットの一覧。詳しくは、「サブネット」を参照してください。デフォルト値に含まれるのは、ctlplane-subnet サブネットのみです。
templates
上書きするヒートテンプレートファイル。
undercloud_admin_host
SSL/TLS 経由の director の管理 API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは /32 ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。
undercloud_debug
アンダークラウドサービスのログレベルを DEBUG に設定します。この値は true に設定して有効化します。
undercloud_enable_selinux
デプロイメント時に、SELinux を有効または無効にします。問題をデバッグする場合以外は、この値を true に設定したままにすることを強く推奨します。
undercloud_hostname
アンダークラウドの完全修飾ホスト名を定義します。設定されている場合には、アンダークラウドのインストールで全システムのホスト名が設定されます。設定されていない場合には、アンダークラウドは現在のホスト名を使用しますが、ユーザーは適切に全システムのホスト名の設定を行う必要があります。
undercloud_log_file
アンダークラウドのインストール/アップグレードログを保管するログファイルへのパス。デフォルトでは、ログファイルはホームディレクトリー内の install-undercloud.log です。たとえば、/home/stack/install-undercloud.log です。
undercloud_nameservers
アンダークラウドのホスト名解決に使用する DNS ネームサーバーの一覧
undercloud_ntp_servers
アンダークラウドの日付けと時刻を同期できるようにする Network Time Protocol サーバーの一覧。
undercloud_public_host
SSL/TLS 経由の director のパブリック API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは /32 ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。
undercloud_service_certificate
OpenStack SSL/TLS 通信の証明書の場所とファイル名。理想的には、信頼できる認証局から、この証明書を取得します。それ以外の場合は、独自の自己署名の証明書を生成します。
undercloud_timezone
アンダークラウド用ホストのタイムゾーン。タイムゾーンを指定しなければ、director は既存のタイムゾーン設定を使用します。
undercloud_update_packages
アンダークラウドのインストール時にパッケージを更新するかどうかを定義します。

サブネット

undercloud.conf ファイルには、各プロビジョニングサブネットの名前が付いたセクションがあります。たとえば、ctlplane-subnet という名前のサブネットを作成するには、undercloud.conf ファイルで以下のような設定を使用します。

[ctlplane-subnet]
cidr = 192.168.24.0/24
dhcp_start = 192.168.24.5
dhcp_end = 192.168.24.24
inspection_iprange = 192.168.24.100,192.168.24.120
gateway = 192.168.24.1
masquerade = true

プロビジョニングネットワークは、環境に応じて、必要なだけ指定することができます。

gateway
オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または直接外部ゲートウェイを使用する場合以外は、この値はデフォルト (192.168.24.1) のままにします。
注記

director 設定は、適切な sysctl カーネルパラメーターを使用して IP フォワーディングも自動的に有効にします。

cidr
オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの neutron サービスが管理するプロビジョニングネットワークです。プロビジョニングネットワークに別のサブネットを使用しない限り、この値はデフォルト (192.168.24.0/24) のままにします。
masquerade
外部ネットワークへのアクセスのために、cidr で定義したネットワークをマスカレードするかどうかを定義します。このパラメーターにより、director 経由で外部ネットワークにアクセスすることができるように、プロビジョニングネットワークにネットワークアドレス変換 (NAT) の一部メカニズムが提供されます。
dhcp_start; dhcp_end
オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。
dhcp_exclude
DHCP 割り当て範囲で除外する IP アドレス。
host_routes
このネットワーク上のオーバークラウドインスタンス用の Neutron が管理するサブネットのホストルート。このパラメーターにより、アンダークラウド上の local_subnet のホストルートも設定されます。

ご自分の構成に応じて、これらのパラメーターの値を変更してください。完了したら、ファイルを保存します。

4.3. 環境ファイルを使用したアンダークラウドの設定

undercloud.conf ファイルを使用して、アンダークラウドの主要なパラメーターを設定します。アンダークラウドのインストールに固有の heat パラメーターを設定することもできます。そのためには、heat パラメーターが含まれる環境ファイルを使用します。

手順

  1. 環境ファイル /home/stack/templates/custom-undercloud-params.yaml を作成します。
  2. このファイルを編集して、必要な heat パラメーターを追加します。以下の例は、特定の OpenStack Platform サービスのデバッグを有効にする方法を示しています。

    parameter_defaults:
      Debug: True

    完了したら、このファイルを保存します。

  3. undercloud.conf ファイルを編集し、custom_env_files パラメーターまでスクロールします。作成した環境ファイルをポイントするようにパラメーターを編集します。

    custom_env_files = /home/stack/templates/custom-undercloud-params.yaml
    注記

    コンマ区切りリストを使用して、複数の環境ファイルを指定することができます。

アンダークラウドの次回インストールまたはアップグレード操作時に、この環境ファイルが director のインストールに追加されます。

4.4. アンダークラウド設定用の標準 Heat パラメーター

以下の表には、アンダークラウド用のカスタム環境ファイルで設定する標準の Heat パラメーターをまとめています。

パラメーター説明

AdminPassword

アンダークラウドの admin ユーザーのパスワードを設定します。

AdminEmail

アンダークラウドの admin ユーザーの電子メールアドレスを設定します。

Debug

デバッグモードを有効にします。

カスタム環境ファイルの parameter_defaults セクションで、これらのパラメーターを設定します。

parameter_defaults:
  Debug: True
  AdminPassword: "myp@ssw0rd!"
  AdminEmail: "admin@example.com"

4.5. アンダークラウドへの hieradata の設定

director に Puppet hieradata を設定して、サービスに対して利用可能な undercloud.conf パラメーター以外のカスタム設定を行うことができます。この機能を使用するには、以下の手順を実施します。

手順

  1. hieradata オーバーライドファイルを作成します (例: /home/stack/hieradata.yaml)。
  2. カスタマイズした hieradata をファイルに追加します。たとえば、Compute (nova) サービスのパラメーター force_raw_images をデフォルト値の「True」から「False」に変更するには、以下の設定を追加します。

    nova::compute::force_raw_images: False

    設定するパラメーターに Puppet 実装がない場合には、以下の手段によりパラメーターを設定します。

    nova::config::nova_config:
      DEFAULT/<parameter_name>:
        value: <parameter_value>

    以下に例を示します。

    nova::config::nova_config:
      DEFAULT/network_allocate_retries:
        value: 20
      ironic/serial_console_state_timeout:
        value: 15
  3. undercloud.conf で、hieradata_override パラメーターを hieradata ファイルのパスに設定します。

    hieradata_override = /home/stack/hieradata.yaml

4.6. director のインストール

director をインストールして基本的なインストール後タスクを行うには、以下の手順を実施します。

手順

  1. 以下のコマンドを実行して、アンダークラウドに director をインストールします。

    [stack@director ~]$ openstack undercloud install

    このコマンドで、director の設定スクリプトを起動します。director により追加のパッケージがインストールされ、undercloud.conf の設定に応じてサービスが設定されます。このスクリプトは、完了までに数分かかります。

    スクリプトにより、完了時には 2 つのファイルが生成されます。

    • undercloud-passwords.conf: director サービスの全パスワード一覧
    • stackrc: director のコマンドラインツールへアクセスできるようにする初期化変数セット
  2. このスクリプトは、全 OpenStack Platform サービスのコンテナーも自動的に起動します。以下のコマンドを使用して、有効化されたコンテナーを確認してください。

    [stack@director ~]$ sudo podman ps
  3. stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。

    [stack@director ~]$ source ~/stackrc

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

    (undercloud) [stack@director ~]$

director のインストールが完了しました。これで、director のコマンドラインツールが使用できるようになりました。

4.7. オーバークラウドノードのイメージの取得

director では、オーバークラウドのノードをプロビジョニングする際に、複数のディスクが必要です。以下のステップが含まれます。

  • イントロスペクションのカーネルおよび ramdisk: PXE ブートでベアメタルシステムのイントロスペクションに使用
  • デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメントに使用
  • オーバークラウドカーネル、ramdisk、完全なイメージ: ノードのハードディスクに書き込まれるベースのオーバークラウドシステム

以下の手順は、これらのイメージの取得およびインストールの方法について説明します。

4.7.1. 単一 CPU アーキテクチャーのオーバークラウド

CPU アーキテクチャーがデフォルトの x86-64 の場合には、オーバークラウドのデプロイメントに以下のイメージおよび手順が必要です。

手順

  1. source コマンドで stackrc ファイルを読み込み、director のコマンドラインツールを有効にします。

    [stack@director ~]$ source ~/stackrc
  2. rhosp-director-images および rhosp-director-images-ipa パッケージをインストールします。

    (undercloud) [stack@director ~]$ sudo yum install rhosp-director-images rhosp-director-images-ipa
  3. イメージのアーカイブを stack ユーザーの images ディレクトリー (/home/stack/images) に抽出します。

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-15.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-15.0.tar; do tar -xvf $i; done
  4. これらのイメージを director にインポートします。

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

    このスクリプトにより、以下のイメージが director にアップロードされます。

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • overcloud-full
    • overcloud-full-initrd
    • overcloud-full-vmlinuz

    スクリプトにより、director の PXE サーバー上にイントロスペクションイメージもインストールされます。

  5. これらのイメージが正常にアップロードされたことを確認するには、以下のコマンドを実行します。

    (undercloud) [stack@director images]$ openstack image list
    +--------------------------------------+------------------------+
    | ID                                   | Name                   |
    +--------------------------------------+------------------------+
    | 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
    | 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
    | ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
    | 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
    | 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
    +--------------------------------------+------------------------+

    この一覧には、イントロスペクションの PXE イメージは表示されません。director は、これらのファイルを /var/lib/ironic/httpboot にコピーします。

    (undercloud) [stack@director images]$ ls -l /var/lib/ironic/httpboot
    total 417296
    -rwxr-xr-x. 1 root  root    6639920 Jan 29 14:48 agent.kernel
    -rw-r--r--. 1 root  root  420656424 Jan 29 14:48 agent.ramdisk
    -rw-r--r--. 1 42422 42422       758 Jan 29 14:29 boot.ipxe
    -rw-r--r--. 1 42422 42422       488 Jan 29 14:16 inspector.ipxe

4.7.2. 複数 CPU アーキテクチャーのオーバークラウド

追加の CPU アーキテクチャーのサポートを有効にしてオーバークラウドをデプロイするには、以下のイメージおよび手順が必要です。

以下に示す手順の例では、ppc64le イメージが使われています。

手順

  1. source コマンドで stackrc ファイルを読み込み、director のコマンドラインツールを有効にします。

    [stack@director ~]$ source ~/stackrc
  2. rhosp-director-images-all パッケージをインストールします。

    (undercloud) [stack@director ~]$ sudo yum install rhosp-director-images-all
  3. アーキテクチャー個別のディレクトリーにアーカイブを展開します。このディレクトリーは、stack ユーザーのホームの images ディレクトリー (/home/stack/images) 下に作成します。

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do mkdir $arch ; done
    (undercloud) [stack@director images]$ for arch in x86_64 ppc64le ; do for i in /usr/share/rhosp-director-images/overcloud-full-latest-15.0-${arch}.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-15.0-${arch}.tar ; do tar -C $arch -xf $i ; done ; done
  4. これらのイメージを director にインポートします。

    (undercloud) [stack@director ~]$ cd ~/images
    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/ppc64le --architecture ppc64le --whole-disk --http-boot /tftpboot/ppc64le
    (undercloud) [stack@director images]$ openstack overcloud image upload --image-path ~/images/x86_64/ --http-boot /tftpboot

    このコマンドにより、以下のイメージが director にアップロードされます。

    • bm-deploy-kernel
    • bm-deploy-ramdisk
    • overcloud-full
    • overcloud-full-initrd
    • overcloud-full-vmlinuz
    • ppc64le-bm-deploy-kernel
    • ppc64le-bm-deploy-ramdisk
    • ppc64le-overcloud-full

      スクリプトにより、director の PXE サーバー上にイントロスペクションイメージもインストールされます。

  5. これらのイメージが正常にアップロードされたことを確認するには、以下のコマンドを実行します。

    (undercloud) [stack@director images]$ openstack image list
    +--------------------------------------+---------------------------+--------+
    | ID                                   | Name                      | Status |
    +--------------------------------------+---------------------------+--------+
    | 6d1005ba-ec82-473b-8e33-88aadb5b6792 | bm-deploy-kernel          | active |
    | fb723b33-9f11-45f5-b25b-c008bf509290 | bm-deploy-ramdisk         | active |
    | 6a6096ba-8f79-4343-b77c-4349f7b94960 | overcloud-full            | active |
    | de2a1bde-9351-40d2-bbd7-7ce9d6eb50d8 | overcloud-full-initrd     | active |
    | 67073533-dd2a-4a95-8e8b-0f108f031092 | overcloud-full-vmlinuz    | active |
    | 69a9ffe5-06dc-4d81-a122-e5d56ed46c98 | ppc64le-bm-deploy-kernel  | active |
    | 464dd809-f130-4055-9a39-cf6b63c1944e | ppc64le-bm-deploy-ramdisk | active |
    | f0fedcd0-3f28-4b44-9c88-619419007a03 | ppc64le-overcloud-full    | active |
    +--------------------------------------+---------------------------+--------+

    この一覧には、イントロスペクションの PXE イメージは表示されません。director は、これらのファイルを /tftpboot にコピーします。

    (undercloud) [stack@director images]$ ls -l /tftpboot /tftpboot/ppc64le/
    /tftpboot:
    total 422624
    -rwxr-xr-x. 1 root   root     6385968 Aug  8 19:35 agent.kernel
    -rw-r--r--. 1 root   root   425530268 Aug  8 19:35 agent.ramdisk
    -rwxr--r--. 1 ironic ironic     20832 Aug  8 02:08 chain.c32
    -rwxr--r--. 1 ironic ironic    715584 Aug  8 02:06 ipxe.efi
    -rw-r--r--. 1 root   root          22 Aug  8 02:06 map-file
    drwxr-xr-x. 2 ironic ironic        62 Aug  8 19:34 ppc64le
    -rwxr--r--. 1 ironic ironic     26826 Aug  8 02:08 pxelinux.0
    drwxr-xr-x. 2 ironic ironic        21 Aug  8 02:06 pxelinux.cfg
    -rwxr--r--. 1 ironic ironic     69631 Aug  8 02:06 undionly.kpxe
    
    /tftpboot/ppc64le/:
    total 457204
    -rwxr-xr-x. 1 root             root              19858896 Aug  8 19:34 agent.kernel
    -rw-r--r--. 1 root             root             448311235 Aug  8 19:34 agent.ramdisk
    -rw-r--r--. 1 ironic-inspector ironic-inspector       336 Aug  8 02:06 default
注記

デフォルトの overcloud-full.qcow2 イメージは、フラットなパーティションイメージです。ただし、完全なディスクイメージをインポートして使用することも可能です。詳しくは、「20章完全なディスクイメージの作成」を参照してください。

4.8. コントロールプレーン用のネームサーバーの設定

オーバークラウドで cdn.redhat.com などの外部のホスト名を解決する予定の場合は、オーバークラウドノード上にネームサーバーを設定することを推奨します。ネットワークを分離していない標準のオーバークラウドの場合には、ネームサーバーはアンダークラウドのコントロールプレーンのサブネットを使用して定義されます。環境でネームサーバーを定義するには、以下の手順を実施します。

手順

  1. source コマンドで stackrc ファイルを読み込み、director のコマンドラインツールを有効にします。

    [stack@director ~]$ source ~/stackrc
  2. ctlplane-subnet サブネット用のネームサーバーを設定します。

    (undercloud) [stack@director images]$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] ctlplane-subnet

    各ネームサーバーに --dns-nameserver オプションを使用します。

  3. サブネットを表示してネームサーバーを確認します。

    (undercloud) [stack@director images]$ openstack subnet show ctlplane-subnet
    +-------------------+-----------------------------------------------+
    | Field             | Value                                         |
    +-------------------+-----------------------------------------------+
    | ...               |                                               |
    | dns_nameservers   | 8.8.8.8                                       |
    | ...               |                                               |
    +-------------------+-----------------------------------------------+
重要

サービストラフィックを別のネットワークに分離する場合は、オーバークラウドのノードはネットワーク環境ファイルの DnsServers パラメーターを使用します。

4.9. アンダークラウド設定の更新

今後、新たな要件に合わせて、アンダークラウドの設定を変更しなければならない場合があります。インストール後にアンダークラウド設定に変更を加えるには、該当する設定ファイルを編集して、openstack undercloud install コマンドを再度実行します。

手順

  1. アンダークラウドの設定ファイルを変更します。以下の例では、undercloud.conf ファイルを編集して、有効なハードウェア種別の一覧に idrac ハードウェア種別を追加しています。

    enabled_hardware_types = ipmi,redfish,idrac
  2. openstack undercloud install コマンドを実行し、新たな変更を反映させてアンダークラウドを更新します。

    [stack@director ~]$ openstack undercloud install

    コマンドの実行が完了するまで待ちます。

  3. stack ユーザーを初期化し、コマンドラインツールを使用します。

    [stack@director ~]$ source ~/stackrc

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

    (undercloud) [stack@director ~]$
  4. director が新しい設定を適用していることを確認します。この例では、有効なハードウェア種別の一覧を確認しています。

    (undercloud) [stack@director ~]$ openstack baremetal driver list
    +---------------------+----------------+
    | Supported driver(s) | Active host(s) |
    +---------------------+----------------+
    | idrac               | unused         |
    | ipmi                | unused         |
    | redfish             | unused         |
    +---------------------+----------------+

アンダークラウドの再設定が完了しました。

4.10. アンダークラウドのコンテナーレジストリー

Red Hat Enterprise Linux 8 には、Docker Registry v2 をインストールするための docker-distribution パッケージが含まれなくなりました。互換性および同じ機能レベルを維持するために、director のインストールでは Apache Web サーバーおよび image-serve という仮想ホストが作成され、これによりレジストリーが提供されます。このレジストリーでも、SSL を無効にしたポート 8787/TCP が使用されます。Apache ベースのレジストリーはコンテナー化されていません。したがって、以下のコマンドを実行してレジストリーを再起動します。

コンテナーレジストリーのログは、以下の場所に保存されます。

  • /var/log/httpd/image_serve_access.log
  • /var/log/httpd/image_serve_error.log.
$ sudo systemctl restart httpd

イメージのコンテンツは、/var/lib/image-serve から提供されます。この場所では、レジストリー REST API のプル機能を実装するために、特定のディレクトリーレイアウトおよび apache 設定が使用されています。

注記

Apache ベースのレジストリーは読み取り専用コンテナーレジストリーで、podman push および buildah push コマンドはサポートされません。つまり、レジストリーでは director または OpenStack Platform 以外のコンテナーをプッシュすることはできません。ただし、ContainerImagePrepare パラメーターを使用する director のコンテナー準備ワークフローにより、OpenStack Platform イメージを変更することができます。

4.11. 次のステップ

これで director の設定およびインストールが完了しました。次の章では、ノードの登録、検査、さまざまなノードロールのタグ付けなど、オーバークラウドの基本的な設定について説明します。

パート II. 基本的なオーバークラウドのデプロイメント

第5章 オーバークラウドのプランニング

以下の項で、Red Hat OpenStack Platform 環境のさまざまな要素をプランニングする際のガイドラインを説明します。これには、ノードロールの定義、ネットワークトポロジーのプランニング、ストレージなどが含まれます。

5.1. ノードロール

director には、オーバークラウドを構築するための、さまざまなデフォルトノード種別が含まれます。これらのノード種別は以下のとおりです。

コントローラー

環境を制御するための主要なサービスを提供します。これには、Dashboard (Horizon)、認証 (Keystone)、イメージストレージ (Glance)、ネットワーク (Neutron)、オーケストレーション (Heat)、高可用性サービスが含まれます。高可用性に対応した実稼働レベルの環境の場合は、Red Hat OpenStack Platform 環境にコントローラーノードが 3 台必要です。

注記

1 台のノードで構成される環境は実稼働用ではなく、テスト目的でしか使用することができません。2 台のノードまたは 4 台以上のノードで構成される環境はサポートされません。

コンピュート
ハイパーバイザーとして機能し、環境内で仮想マシンを実行するのに必要な処理機能を持つ物理サーバー。基本的な Red Hat OpenStack Platform 環境には少なくとも 1 つのコンピュートノードが必要です。
Ceph Storage
Red Hat Ceph Storage を提供するホスト。Ceph Storage ホストはクラスターに追加され、クラスターをスケーリングします。このデプロイメントロールはオプションです。
Swift Storage
OpenStack Object Storage (swift) サービスに外部オブジェクトストレージを提供するホスト。このデプロイメントロールはオプションです。

以下の表には、オーバークラウドの構成例と各シナリオで使用するノード種別の定義をまとめています。

表5.1 各種シナリオに使用するノードデプロイメントロール

 

コントローラー

コンピュート

Ceph Storage

Swift Storage

合計

小規模のオーバークラウド

3

1

-

-

4

中規模のオーバークラウド

3

3

-

-

6

追加のオブジェクトストレージがある中規模のオーバークラウド

3

3

-

3

9

Ceph Storage クラスターがある中規模のオーバークラウド

3

3

3

-

9

さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーに関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』「コンポーザブルサービスとカスタムロール」を参照してください。

5.2. オーバークラウドネットワーク

ロールとサービスを適切にマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Openstack Networking (neutron) サービスを使用します。

デフォルトでは、director は接続に プロビジョニング / コントロールプレーン を使用するようにノードを設定します。ただし、ネットワークトラフィックを一連の コンポーザブルネットワーク に分離し、カスタマイズしてサービスを割り当てることができます。

一般的な Red Hat OpenStack Platform のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するには、オーバークラウドは VLAN タグ付けを使用して、1 つのインターフェースに複数のネットワークを提供します。ネットワークの多くは独立したサブネットですが、一部のネットワークには、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供するレイヤー 3 のゲートウェイが必要です。ネットワークトラフィックの種別を分離するのに VLAN を使用している場合には、802.1Q 標準をサポートするスイッチを使用してタグ付けされた VLAN を提供します。

注記

デプロイ時に neutron VLAN モード (トンネリングは無効) を使用する場合でも、プロジェクトネットワーク (GRE または VXLAN でトンネリング) をデプロイすることを推奨します。これには、デプロイ時にマイナーなカスタマイズを行う必要があり、将来ユーティリティーネットワークまたは仮想化ネットワークとしてトンネルネットワークを使用するためのオプションが利用可能な状態になります。VLAN を使用してテナントネットワークを作成することは変わりませんが、テナントの VLAN を消費せずに特別な用途のネットワーク用に VXLAN トンネルを作成することも可能です。また、テナント VLAN を使用するデプロイメントに VXLAN 機能を追加することは可能ですが、サービスを中断せずにテナント VLAN を既存のオーバークラウドに追加することはできません。

director には、NIC を分離コンポーザブルネットワークと連携させるためのテンプレートセットも含まれています。デフォルトの構成は以下のとおりです。

  • シングル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1つ。
  • ボンディングされた NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワーク用に NIC を 1 つと、オーバークラウドネットワークの種別ごとのタグ付けされた VLAN 用にボンディング構成の 2 つの NIC。
  • 複数 NIC 構成: 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用します。

専用のテンプレートを作成して、特定の NIC 構成をマッピングすることもできます。

ネットワーク構成を検討する上で、以下の点を考慮することも重要です。

  • オーバークラウドの作成時には、全オーバークラウドマシンで 1 つの名前を使用して NIC を参照します。理想としては、混乱を避けるため、対象のネットワークごとに、各オーバークラウドノードで同じ NIC を使用してください。たとえば、プロビジョニングネットワークにはプライマリー NIC を使用して、OpenStack サービスにはセカンダリー NIC を使用します。
  • すべてのオーバークラウドシステムをプロビジョニング NIC から PXE ブートするように設定して、同システム上の外部 NIC およびその他の NIC の PXE ブートを無効にします。また、プロビジョニング NIC の PXE ブートは、ハードディスクや CD/DVD ドライブよりも優先されるように、起動順序の最上位に指定するようにします。
  • オーバークラウドのベアメタルシステムにはすべて、Intelligent Platform Management Interface (IPMI) などのサポート対象の電源管理インターフェースが必要です。このインターフェースにより、director は各ノードの電源管理を制御することが可能となります。
  • 各オーバークラウドシステムの詳細 (プロビジョニング NIC の MAC アドレス、IPMI NIC の IP アドレス、IPMI ユーザー名、IPMI パスワード) をメモしてください。この情報は、後でオーバークラウドノードを設定する際に役立ちます。
  • インスタンスが外部のインターネットからアクセス可能である必要がある場合には、パブリックネットワークから Floating IP アドレスを割り当てて、そのアドレスをインスタンスに関連付けます。インスタンスは、引き続きプライベートの IP アドレスを確保しますが、ネットワークトラフィックは NAT を使用して、Floating IP アドレスに到達します。Floating IP アドレスは、複数のプライベート IP アドレスではなく、単一のインスタンスにのみ割り当て可能である点に注意してください。ただし、Floating IP アドレスは、単一のテナントでのみ使用するように確保され、そのテナントは必要に応じて特定のインスタンスに関連付け/関連付け解除することができます。この設定では、お使いのインフラストラクチャーが外部のインターネットに公開されます。したがって、適切なセキュリティープラクティスを順守しているかどうかを確認しなければならない場合があります。
  • 1 つのブリッジには単一のインターフェースまたは単一のボンディングのみをメンバーにすると、Open vSwitch でネットワークループが発生するリスクを緩和することができます。複数のボンディングまたはインターフェースが必要な場合には、複数のブリッジを設定することが可能です。
  • Red Hat では、オーバークラウドノードが Red Hat コンテンツ配信ネットワークやネットワークタイムサーバーなどの外部のサービスに接続できるように、DNS によるホスト名解決を使用することを推奨します。
注記

Red Hat Virtualization (RHV) を使用している場合には、オーバークラウドのコントロールプレーンを仮想化することができます。詳細は、「仮想コントロールプレーンの作成」を参照してください。

5.3. オーバークラウドのストレージ

注記

任意のドライバーまたはバックエンド種別のバックエンド cinder ボリュームを使用するゲストインスタンスで LVM を使用すると、パフォーマンス、ボリュームの可視性/可用性、およびデータ破損の問題が生じます。このような問題を軽減するには、LVM フィルターを使用します。詳しくは、『Storage Guide』「Back Ends」および KCS アーティクル「Using LVM on a cinder volume exposes the data to the host」を参照してください。

director には、オーバークラウド環境用にさまざまなストレージオプションが含まれています。

Ceph Storage ノード

director は、Red Hat Ceph Storage を使用して拡張可能なストレージノードセットを作成します。オーバークラウドは、以下のストレージ種別にこのノードを使用します。

  • イメージ: glance は仮想マシンのイメージを管理します。イメージを変更することはできません。OpenStack はイメージバイナリーブロブとして処理し、それに応じてイメージをダウンロードします。glance を使用して、Ceph ブロックデバイスにイメージを保管することができます。
  • ボリューム: cinder ボリュームはブロックデバイスです。OpenStack では、ボリュームを使用して仮想マシンをブートしたり、ボリュームを実行中の仮想マシンにアタッチしたりします。OpenStack は cinder サービスを使用してボリュームを管理します。イメージの CoW (Copy-on-Write) クローンを使用して、cinder により仮想マシンをブートすることができます。
  • ファイルシステム: manila 共有はファイルシステムによりバッキングされます。OpenStack ユーザーは、manila サービスを使用して共有を管理します。manila を使用して、Ceph Storage ノードにデータを保管する CephFS ファイルシステムにバッキングされる共有を管理することができます。
  • ゲストディスク: ゲストディスクは、ゲストオペレーティングシステムのディスクです。デフォルトでは、nova で仮想マシンをブートすると、仮想マシンのディスクはハイパーバイザーのファイルシステム上のファイルとして表示されます (通常 /var/lib/nova/instances/<uuid>/ 内)。Ceph 内にあるすべての仮想マシンは、cinder を使用せずにブートすることができます。これにより、ライブマイグレーションのプロセスを使用して、簡単にメンテナンス操作を実施することができます。また、ハイパーバイザーが停止した場合には、nova evacuate をトリガーして仮想マシンを別の場所で実行することもできるので便利です。

    重要

    サポートされるイメージフォーマットの情報については、『Instances and Images Guide』「Image Service」の章を参照してください。

    その他の情報については、『Red Hat Ceph Storage Architecture Guide』を参照してください。

Swift Storage ノード
director は、外部オブジェクトストレージノードを作成します。これは、オーバークラウド環境でコントローラーノードをスケーリングまたは置き換える必要があるが、高可用性クラスター外にオブジェクトストレージを保持する必要がある場合に便利です。

5.4. オーバークラウドのセキュリティー

OpenStack Platform の実装のセキュリティーレベルは、その環境のセキュリティーレベルと同等です。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスが正しく制御されるようにします。

  • ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークは、セキュリティーレベルがはるかに低くなります。
  • サービスアクセスとポートを最小限に制限します。
  • 適切なファイアウォールルールおよびパスワードの使用を徹底してください。
  • SELinux が有効化されていることを確認します。

システムのセキュリティー保護の詳細は、以下の Red Hat ガイドを参照してください。

5.5. オーバークラウドの高可用性

高可用性なオーバークラウドをデプロイするために、director は複数のコントローラー、コンピュート、およびストレージノードを単一のクラスターとして連携するように設定します。ノードで障害が発生すると、障害が発生したノードのタイプに応じて、自動フェンシングおよび再起動プロセスがトリガーされます。オーバークラウド高可用性アーキテクチャーおよびサービスに関する情報は、『Understanding Red Hat OpenStack Platform High Availability』を参照してください。

director を使用して、コンピュートインスタンスの高可用性 (インスタンス HA) を設定することもできます。この高可用性のメカニズムにより、ノードで障害が発生するとコンピュートノード上のインスタンスが自動的に退避および再起動されます。インスタンス HA に対する要件は通常のオーバークラウドの要件と同じですが、環境をデプロイメント用に準備するために追加のステップを実施する必要があります。インスタンス HA の仕組みおよびインストール手順に関する情報は、『High Availability for Compute Instances』を参照してください。

5.6. コントローラーノードの要件

コントローラーノードは、Red Hat OpenStack Platform 環境の中核となるサービス (例: horizon Dashboard、バックエンドのデータベースサーバー、Keystone 認証、高可用性サービスなど) をホストします。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能のサポートがある 64 ビットの x86 プロセッサー。
メモリー

最小のメモリー容量は 32 GB です。ただし、推奨のメモリー容量は、仮想 CPU の数によって異なります (CPU コアをハイパースレッディングの値で乗算した数値に基づいています)。以下の計算により、RAM の要件を決定します。

  • コントローラーの最小メモリー容量の算出:

    • 1 仮想 CPU あたり 1.5 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 72 GB 必要です。
  • コントローラーの推奨メモリー容量の算出:

    • 1 仮想 CPU あたり 3 GB のメモリーを使用します。たとえば、仮想 CPU が 48 個あるマシンにはメモリーは 144 GB 必要です。

メモリーの要件に関する詳しい情報は、Red Hat カスタマーポータルで「Red Hat OpenStack Platform Hardware Requirements for Highly Available Controllers」を参照してください。

ディスクストレージとレイアウト

Object Storage サービス (swift) がコントローラーノード上で実行されていない場合には、最小で 40 GB のストレージが必要です。ただし、Telemetry (gnocchi) および Object Storage サービスはいずれもコントローラーにインストールされ、ルートディスクを使用するように設定されます。これらのデフォルトは、市販のハードウェア上に構築される小型のオーバークラウドのデプロイに適しています。これらの環境は、概念検証およびテストの標準的な環境です。これらのデフォルトにより、最小限のプランニングでオーバークラウドをデプロイすることができますが、ワークロードキャパシティーとパフォーマンスの面ではあまり優れていません。

ただし、Telemetry がストレージに絶えずアクセスするため、エンタープライズ環境では、これによって大きなボトルネックが生じる可能性があります。これにより、ディスク I/O が過度に使用されて、その他すべてのコントローラーサービスに深刻な影響をもたらします。このタイプの環境では、オーバークラウドのプランニングを行って、適切に設定する必要があります。

Red Hat は、Telemetry と Object Storage の両方の推奨設定をいくつか提供しています。詳しくは、『Deployment Recommendations for Specific Red Hat OpenStack Platform Services』を参照してください。

ネットワークインターフェースカード
最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。
仮想化サポート
Red Hat では、Red Hat Virtualization プラットフォーム上の仮想コントローラーノードのみをサポートします。詳細は、「仮想コントローラーノード」を参照してください。

5.7. コンピュートノードの要件

コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させる役割を果たします。コンピュートノードは、ハードウェアの仮想化をサポートしている必要があります。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。

プロセッサー
  • Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーで Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されていること。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。
  • IBM POWER 8 プロセッサー
メモリー
最小で 6 GB のメモリー。仮想マシンインスタンスに割り当てるメモリー容量に基づいて、この最低要求に追加の RAM を加算します。
ディスク領域
最小 40 GB の空きディスク領域
ネットワークインターフェースカード
最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コンピュートノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

5.8. Ceph Storage ノードの要件

Ceph Storage ノードは、Red Hat OpenStack Platform 環境でオブジェクトストレージを提供する役割を果たします。

配置グループ
デプロイメントの規模によらず、動的で効率的なオブジェクトの追跡を容易に実施するために、Ceph では配置グループが使用されています。OSD の障害やクラスターのリバランスの際には、Ceph は配置グループおよびその内容を移動または複製することができるので、Ceph クラスターは効率的にリバランスおよび復旧を行うことができます。Director が作成するデフォルトの配置グループ数が常に最適とは限らないので、ご自分の要求に応じて正しい配置グループ数を計算することが重要です。配置グループの計算ツールを使用して、正しい配置グループ数を計算することができます (Ceph Placement Groups (PGs) per Pool Calculator を参照)。
プロセッサー
Intel 64 または AMD64 CPU 拡張機能のサポートがある 64 ビットの x86 プロセッサー。
メモリー
Red Hat では、OSD ホスト 1 台につき 16 GB の RAM をベースラインとし、これに OSD デーモンごとに 2 GB の RAM を追加する構成を推奨します。
ディスクのレイアウト

ディスクサイズは、ストレージのニーズに依存します。推奨される Red Hat Ceph Storage ノードの構成には、少なくとも以下のレイアウト例に示すの 3 つのディスクが必要です。

  • /dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。このディスクには、少なくとも 40 GB の空きディスク領域が必要です。
  • /dev/sdb: ジャーナルディスク。このディスクは、Ceph OSD ジャーナル向けにパーティションに分割されます。たとえば、/dev/sdb1/dev/sdb2/dev/sdb3 … となります。ジャーナルディスクは、通常システムパフォーマンスの向上に役立つ Solid State Drive (SSD) です。
  • /dev/sdc 以降: OSD ディスク。ストレージ要件で必要な数のディスクを使用します。

    注記

    Red Hat OpenStack Platform director は ceph-ansible を使用しますが、Ceph Storage ノードのルートディスクへの OSD インストールには対応しません。したがって、サポートされる Ceph Storage ノードには少なくとも 2 つのディスクが必要になります。

ネットワークインターフェースカード
最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。特に大量のトラフィックにサービスを提供する OpenStack Platform 環境を構築する場合には、ストレージノードには 10 Gbps インターフェースを使用することを推奨します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

Ceph Storage クラスターを使用するオーバークラウドのインストールについては、『Deploying an Overcloud with Containerized Red Hat Ceph』を参照してください。

5.9. オブジェクトストレージノードの要件

オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。Object Storage プロキシーは、コントローラーノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。

プロセッサー
Intel 64 または AMD64 CPU 拡張機能のサポートがある 64 ビットの x86 プロセッサー。
メモリー
メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。最適なパフォーマンスを得るには、ハードディスク容量 1 TB あたり 2 GB のメモリーを使用することを推奨します (特に、ワークロードが 100 GB に満たないファイルの場合)。
ディスク領域

ストレージ要件は、ワークロードに必要とされる容量により異なります。アカウントとコンテナーのデータを保存するには SSD ドライブを使用することを推奨します。アカウントおよびコンテナーデータとオブジェクトの容量比率は、約 1% です。たとえば、ハードドライブの容量 100 TB ごとに、アカウントおよびコンテナーデータの SSD 容量は 1 TB 用意するようにします。

ただし、これは保存したデータの種類により異なります。保存するオブジェクトの大半が小さい場合には、SSD の容量がさらに必要です。オブジェクトが大きい場合には (ビデオ、バックアップなど)、SSD の容量を減らします。

ディスクのレイアウト

推奨されるノード構成には、以下の例に示すようなディスクレイアウトが必要です。

  • /dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。
  • /dev/sdb: アカウントデータに使用します。
  • /dev/sdc: コンテナーデータに使用します。
  • /dev/sdc 以降: オブジェクトサーバーディスク。ストレージ要件で必要な数のディスクを使用します。
ネットワークインターフェースカード
最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
電源管理
各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。

5.10. オーバークラウドのリポジトリー

オーバークラウドをインストールおよび設定するには、以下のリポジトリーを有効にする必要があります。

コアリポジトリー

以下の表には、オーバークラウドをインストールするためのコアリポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

rhel-8-for-x86_64-baseos-rpms

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

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

rhel-8-for-x86_64-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for x86_64 - High Availability (RPMs)

rhel-8-for-x86_64-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 x86_64 (RPMs)

ansible-2.8-for-rhel-8-x86_64-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Advanced Virtualization for RHEL 8 x86_64 (RPMs)

advanced-virt-for-rhel-8-x86_64-rpm

OpenStack Platform 用仮想化パッケージを提供します。

Red Hat Satellite Tools for RHEL 8 Server RPMs x86_64

satellite-tools-6.5-for-rhel-8-x86_64-rpms

Red Hat Satellite 6 でのホスト管理ツール

Red Hat OpenStack Platform 15 for RHEL 8 (RPMs)

openstack-15-for-rhel-8-x86_64-rpms

Red Hat OpenStack Platform のコアリポジトリー

リアルタイムリポジトリー

以下の表には、リアルタイムコンピュート (RTC) 機能用リポジトリーをまとめています。

名前リポジトリー要件の説明

Red Hat Enterprise Linux 8 for x86_64 - Real Time (RPMs)

rhel-8-for-x86_64-rt-rpms

リアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。このリポジトリーは、RT-KVM 対象の全コンピュートノードで有効化する必要があります。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

Red Hat Enterprise Linux 8 for x86_64 - Real Time for NFV (RPMs)

rhel-8-for-x86_64-nfv-rpms

NFV 向けのリアルタイム KVM (RT-KVM) のリポジトリー。リアルタイムカーネルを有効化するためのパッケージが含まれています。このリポジトリーは、RT-KVM 対象の全 NFV コンピュートノードで有効にする必要があります。注記: このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

IBM POWER 用リポジトリー

以下の表には、POWER PC アーキテクチャー上で OpenStack Platform を構築するためのリポジトリーをまとめています。コアリポジトリーの該当リポジトリーの代わりに、これらのリポジトリーを使用してください。

名前リポジトリー要件の説明

Red Hat Enterprise Linux for IBM Power, little endian - BaseOS (RPMs)

rhel-8-for-ppc64le-baseos-rpms

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

Red Hat Enterprise Linux 8 for IBM Power, little endian - AppStream (RPMs)

rhel-8-for-ppc64le-appstream-rpms

Red Hat OpenStack Platform の依存関係が含まれます。

Red Hat Enterprise Linux 8 for IBM Power, little endian - High Availability (RPMs)

rhel-8-for-ppc64le-highavailability-rpms

Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。

Red Hat Ansible Engine 2.8 for RHEL 8 IBM Power, little endian (RPMs)

ansible-2.8-for-rhel-8-ppc64le-rpms

Red Hat Enterprise Linux 用 Ansible エンジン。最新バージョンの Ansible を提供するために使用されます。

Red Hat OpenStack Platform 15 for RHEL 8 (RPMs)

openstack-15-for-rhel-8-ppc64le-rpms

ppc64le システム用 Red Hat OpenStack Platform のコアリポジトリー

第6章 CLI ツールを使用した基本的なオーバークラウドの設定

本章では、CLI ツールを使用して OpenStack Platform 環境をデプロイするための基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタム機能は含まれません。ただし、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。

6.1. オーバークラウドノードの登録

director では、手動で作成したノード定義のテンプレートが必要です。このテンプレートは JSON または YAML 形式を使用し、ノードのハードウェアおよび電源管理の情報が含まれます。

手順

  1. ノードの一覧が含まれるテンプレートを作成します。以下の例に示す JSON および YAML テンプレートを使用して、ノード定義のテンプレートを構成する方法を説明します。

    JSON テンプレートの例

    {
        "nodes":[
            {
                "mac":[
                    "bb:bb:bb:bb:bb:bb"
                ],
                "name":"node01",
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"ipmi",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.168.24.205"
            },
            {
                "mac":[
                    "cc:cc:cc:cc:cc:cc"
                ],
                "name":"node02",
                "cpu":"4",
                "memory":"6144",
                "disk":"40",
                "arch":"x86_64",
                "pm_type":"ipmi",
                "pm_user":"admin",
                "pm_password":"p@55w0rd!",
                "pm_addr":"192.168.24.206"
            }
        ]
    }

    YAML テンプレートの例

    nodes:
      - mac:
          - "bb:bb:bb:bb:bb:bb"
        name: "node01"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.205"
      - mac:
          - cc:cc:cc:cc:cc:cc
        name: "node02"
        cpu: 4
        memory: 6144
        disk: 40
        arch: "x86_64"
        pm_type: "ipmi"
        pm_user: "admin"
        pm_password: "p@55w0rd!"
        pm_addr: "192.168.24.206"

    このテンプレートには、以下の属性が含まれます。

    name
    ノードの論理名
    pm_type

    使用する電源管理ドライバー。この例では IPMI ドライバー (ipmi) を使用しています。

    注記

    IPMI が推奨されるサポート対象電源管理ドライバーです。これ以外のサポート対象電源管理ドライバーおよびそのオプションに関する詳細は、「付録A 電源管理ドライバー」を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。

    pm_user; pm_password
    IPMI のユーザー名およびパスワード
    pm_addr
    IPMI デバイスの IP アドレス
    pm_port (オプション)
    特定の IPMI デバイスにアクセスするためのポート
    mac
    (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
    cpu
    (オプション) ノード上の CPU 数
    memory
    (オプション) メモリーサイズ (MB 単位)
    disk
    (オプション) ハードディスクのサイズ (GB 単位)
    arch

    (オプション) システムアーキテクチャー

    重要

    マルチアーキテクチャークラウドをビルドする場合には、x86_64 アーキテクチャーを使用するノードと ppc64le アーキテクチャーを使用するノードを区別するために arch キーが必須です。

  2. テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。

    (undercloud) $ openstack overcloud node import --validate-only ~/nodes.json
  3. stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/nodes.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。

    $ source ~/stackrc
    (undercloud) $ openstack overcloud node import ~/nodes.json

    このコマンドにより、それぞれのノードがテンプレートから director に登録されます。

  4. ノードの登録および設定が完了するまで待ちます。完了したら、ノードが director に正しく登録されていることを確認します。

    (undercloud) $ openstack baremetal node list

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

director は各ノードでイントロスペクションプロセスを実行することができます。以下の手順では、PXE を通じて各ノードでイントロスペクションエージェントをブートします。イントロスペクションエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。

手順

  1. 以下のコマンドを実行して、各ノードのハードウェア属性を検証します。

    (undercloud) $ openstack overcloud node introspect --all-manageable --provide
    • --all-manageable オプションは、管理状態のノードのみをイントロスペクションします。ここでは、すべてのノードが管理状態にあります。
    • --provide オプションは、イントロスペクション後に全ノードを available の状態にします。
  2. 別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。

    (undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/*.log
    重要

    このプロセスを必ず完了させてください。ベアメタルの場合には、通常 15 分ほどかかります。

  3. イントロスペクション完了後には、すべてのノードが available の状態に変わります。

6.3. プロファイルへのノードのタグ付け

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

タイプ説明

ロール

Controller ロールは、director がコントローラーノードをどのように設定するかを定義します。

フレーバー

control フレーバーは、ノードをコントローラーとして使用するためのハードウェアプロファイルを定義します。使用するノードを director が決定できるように、このフレーバーを Controller ロールに割り当てます。

プロファイル

control プロファイルは、control フレーバーに適用するタグです。これにより、フレーバーに属するノードが定義されます。

ノード

また、各ノードに control プロファイルタグを適用して、control フレーバーにグループ化します。これにより、director が Controller ロールを使用してノードを設定します。

アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー computecontrolswift-storageceph-storageblock-storage が作成され、大半の環境で変更なしに使用することができます。

手順

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

    (undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
    (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0

    profile:computeprofile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。

    これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。

  2. ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。

    (undercloud) $ openstack overcloud profiles list

6.4. UEFI ブートモードの設定

デフォルトのブートモードは、レガシー BIOS モードです。新しいシステムでは、レガシー BIOS モードの代わりに UEFI ブートモードが必要な可能性があります。ブートモードを UEFI モードに変更するには、以下の手順を実施します。

手順

  1. undercloud.conf ファイルで以下のパラメーターを設定します。

    ipxe_enabled = True
    inspection_enable_uefi = True
  2. undercloud.conf ファイルを保存して、アンダークラウドのインストールを実行します。

    $ openstack undercloud install

    インストールスクリプトが完了するまで待ちます。

  3. 登録済みの各ノードのブートモードを uefi に設定します。たとえば、capabilities プロパティーに boot_mode パラメーターを追加する場合や既存のパラメーターを置き換える場合には、以下のコマンドを実行します。

    $ NODE=<NODE NAME OR ID> ; openstack baremetal node set --property capabilities="boot_mode:uefi,$(openstack baremetal node show $NODE -f json -c properties | jq -r .properties.capabilities | sed "s/boot_mode:[^,]*,//g")" $NODE
    注記

    profile および boot_option のケイパビリティーが保持されていることを確認してください。

    $ openstack baremetal node show r530-12 -f json -c properties | jq -r .properties.capabilities
  4. 各フレーバーのブートモードを uefi に設定します。

    $ openstack flavor set --property capabilities:boot_mode='uefi' control

6.5. ルートディスクの定義

ノードで複数のディスクが使用されている場合には、director はプロビジョニング時にルートディスクを特定する必要があります。たとえば、ほとんどの Ceph Storage ノードでは、複数のディスクが使用されます。デフォルトのプロビジョニングプロセスでは、director はルートディスクにオーバークラウドイメージを書き込みます。

以下のプロパティーを定義すると、director がルートディスクを特定するのに役立ちます。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • hctl (文字列): SCSI のホスト、チャンネル、ターゲット、Lun
  • size (整数):デバイスのサイズ (GB 単位)
  • wwn (文字列): 一意のストレージ ID
  • wwn_with_extension (文字列): ベンダー拡張子を追加した一意のストレージ ID
  • wwn_vendor_extension (文字列): 一意のベンダーストレージ ID
  • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。
  • name (文字列): デバイス名 (例: /dev/sdb1)。
重要

name プロパティーは、永続デバイス名が付いたデバイスにのみ使用します。name で他のデバイスのルートディスクを設定しないでください。この値は、ノードのブート時に変更される可能性があります。

シリアル番号を使用してルートデバイスを指定するには、以下の手順を実施します。

手順

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

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

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

    [
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sda",
        "wwn_vendor_extension": "0x1ea4dcc412a9632b",
        "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380700",
        "serial": "61866da04f3807001ea4dcc412a9632b"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdb",
        "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
        "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380d00",
        "serial": "61866da04f380d001ea4e13c12e36ad6"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdc",
        "wwn_vendor_extension": "0x1ea4e31e121cfb45",
        "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f37fc00",
        "serial": "61866da04f37fc001ea4e31e121cfb45"
      }
    ]
  2. 以下の例では、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 のディスク 2 に設定する方法を説明します。そのためには、ノード定義の root_device パラメーターに変更を加える必要があります。

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

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

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

6.6. オーバークラウドの最小イメージの使用

デフォルトでは、プロビジョニングプロセス中 director はルートディスクに QCOW2 overcloud-full イメージを書き込みます。overcloud-full イメージには、有効な Red Hat サブスクリプションが使用されます。ただし、ノード上でその他の OpenStack サービスが必要なく、Red Hat OpenStack Platform サブスクリプションエンタイトルメントの 1 つを使用したくない場合には、overcloud-minimal イメージを使用することもできます。有償の Red Hat サブスクリプションが限度に達するのを避けるためには、overcloud-minimal イメージのオプションを使用してください。

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

parameter_defaults:
  <roleName>Image: overcloud-minimal

<roleName> をロール名に置き換え、ロール名に Image を追加し、続いて環境ファイルをデプロイコマンドに渡します。

たとえば、Ceph ストレージノードに overcloud-minimal イメージを使用する場合には、以下の例に示す環境ファイルのスニペットを openstack overcloud deploy コマンドに含めます。

parameter_defaults:
  CephStorageImage: overcloud-minimal
注記

OVS は OpenStack サブスクリプションエンタイトルメントが必要な OpenStack サービスです。したがって、overcloud-minimal イメージでサポートされるのは標準の Linux ブリッジだけで、OVS はサポートされません。

6.7. アーキテクチャーに固有なロールの作成

マルチアーキテクチャークラウドを構築する場合には、roles_data.yaml ファイルにアーキテクチャー固有のロールを追加する必要があります。以下に示す例では、デフォルトのロールに加えて ComputePPC64LE ロールを追加しています。

openstack overcloud roles generate \
    --roles-path /usr/share/openstack-tripleo-heat-templates/roles -o ~/templates/roles_data.yaml \
    Controller Compute ComputePPC64LE BlockStorage ObjectStorage CephStorage

『オーバークラウドの高度なカスタマイズ』の「roles_data ファイルの作成」セクションには、ロールについての情報が記載されています。

6.8. 環境ファイル

アンダークラウドには、オーバークラウドの作成プランを形作るさまざまな Heat テンプレートが含まれます。YAML フォーマットの環境ファイルを使って、オーバークラウドの特性をカスタマイズすることができます。このファイルで、コア Heat テンプレートコレクションのパラメーターおよびリソースを上書きします。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

  • 各ロールのノード数およびフレーバー。オーバークラウドを作成するには、この情報の追加は不可欠です。
  • コンテナー化された OpenStack サービスのコンテナーイメージの場所。
  • 任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。詳しい情報は、『オーバークラウドの高度なカスタマイズ』の以下の章を参照してください。

  • 外部のロードバランサーを使用している場合には、外部の負荷分散機能の環境ファイル。詳細情報は、『External Load Balancing for the Overcloud』を参照してください。
  • Ceph Storage、NFS、iSCSI などのストレージ環境ファイル。
  • Red Hat CDN または Satellite 登録用の環境ファイル。
  • その他のカスタム環境ファイル。

カスタム環境ファイルは、別のディレクトリーで管理することを推奨します (たとえば、templates ディレクトリー)。

『オーバークラウドの高度なカスタマイズ』を使用して、オーバークラウドの詳細機能をカスタマイズすることができます。

重要

基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部ストレージソリューション (Red Hat Ceph Storage 等) を使用することを推奨します。

注記

環境ファイルの拡張子は、.yaml または.template にする必要があります。そうでないと、カスタムテンプレートリソースとして処理されません。

これ以降の数セクションで、オーバークラウドに必要な環境ファイルの作成について説明します。

6.9. ノード数とフレーバーを定義する環境ファイルの作成

デフォルトでは、director は baremetal フレーバーを使用して 1 つのコントローラーノードとコンピュートノードを持つオーバークラウドをデプロイします。ただし、この設定は概念検証のためのデプロイメントにしか適しません。異なるノード数およびフレーバーを指定して、デフォルトの設定をオーバーライドすることができます。小規模な実稼働環境では、少なくとも 3 つのコントローラーノードおよびコンピュートノードを作成し、特定のフレーバーを割り当ててノードが適切なリソース仕様を持つようにします。ノード数およびフレーバーの割り当てを定義する環境ファイル node-info.yaml を作成するには、以下の手順を実施します。

手順

  1. /home/stack/templates/ ディレクトリーに node-info.yaml ファイルを作成します。

    (undercloud) $ touch /home/stack/templates/node-info.yaml
  2. ファイルを編集し、必要なノード数およびフレーバーを設定します。以下の例には、3 台のコントローラーノードおよび 3 台のコンピュートノードが含まれます。

    parameter_defaults:
      OvercloudControllerFlavor: control
      OvercloudComputeFlavor: compute
      ControllerCount: 3
      ComputeCount: 3

6.10. アンダークラウド CA を信頼するための環境ファイルの作成

アンダークラウドで TLS を使用され認証局 (CA) が一般に信頼できない場合には、SSL エンドポイント暗号化にアンダークラウドが運用する CA を使用することができます。デプロイメントの他の要素からアンダークラウドのエンドポイントにアクセスできるようにするには、アンダークラウドの CA を信頼するようにオーバークラウドノードを設定します。

注記

この手法が機能するためには、オーバークラウドノードにアンダークラウドの公開エンドポイントへのネットワークルートが必要です。スパイン/リーフ型ネットワークに依存するデプロイメントでは、この設定を適用する必要があります。

アンダークラウドで使用することのできるカスタム証明書には、2 つのタイプがあります。

  • ユーザーの提供する証明書: 自己の証明書を提供している場合がこれに該当します。自己の CA からの証明書、または自己署名の証明書がその例です。この証明書は undercloud_service_certificate オプションを使用して渡されます。この場合、自己署名の証明書または CA のどちらかを信頼する必要があります (デプロイメントによります)。
  • 自動生成される証明書: certmonger により自己のローカル CA を使用して証明書を生成する場合がこれに該当します。このプロセスは、undercloud.conf ファイルの generate_service_certificate オプションを使用して有効にします。この場合、director は CA 証明書 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem を生成し、アンダークラウドの HAProxy インスタンスがサーバー証明書を使用するように設定します。この CA 証明書を OpenStack Platform に提示するには、証明書を inject-trust-anchor-hiera.yaml ファイルに追加します。

以下の例では、/home/stack/ca.crt.pem に保存された自己署名の証明書が使われています。自動生成される証明書を使用する場合には、代わりに /etc/pki/ca-trust/source/anchors/cm-local-ca.pem を使用してください。

手順

  1. 証明書ファイルを開き、証明書部分だけをコピーします。鍵を含めないでください。

    $ vi /home/stack/ca.crt.pem

    必要となる証明書部分の例を、以下に示します。

    -----BEGIN CERTIFICATE-----
    MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
    BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
    UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
    -----END CERTIFICATE-----
  2. 以下に示す内容で /home/stack/inject-trust-anchor-hiera.yaml という名称の新たな YAML ファイルを作成し、PEM ファイルからコピーした証明書を追加します。

    parameter_defaults:
      CAMap:
        ...
        undercloud-ca:
          content: |
            -----BEGIN CERTIFICATE-----
            MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCSqGSIb3DQEBCwUAMGExCzAJBgNV
            BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBwwHUmFsZWlnaDEQMA4GA1UECgwH
            UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBAMMCzE5Mi4xNjguMC4yMB4XDTE3
            -----END CERTIFICATE-----
    注記

    証明書の文字列は、PEM の形式に従う必要があります。

オーバークラウドのデプロイメント時に CA 証明書がそれぞれのオーバークラウドノードにコピーされます。これにより、それぞれのノードはアンダークラウドの SSL エンドポイントが提示する暗号化を信頼するようになります。環境ファイルに関する詳しい情報は、「オーバークラウドデプロイメントへの環境ファイルの追加」を参照してください。

6.11. デプロイメントコマンド

OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行してオーバークラウドを作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。

警告

バックグラウンドプロセスとして openstack overcloud deploy を実行しないでください。バックグラウンドのプロセスとして実行された場合には、オーバークラウドの作成は途中で停止してしまう可能性があります。

6.12. デプロイメントコマンドのオプション

以下の表には、openstack overcloud deploy コマンドの追加パラメーターをまとめています。

表6.1 デプロイメントコマンドのオプション

パラメーター説明

--templates [TEMPLATES]

デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である /usr/share/openstack-tripleo-heat-templates/ を使用します。

--stack STACK

作成または更新するスタックの名前

-t [TIMEOUT], --timeout [TIMEOUT]

デプロイメントのタイムアウト (分単位)

--libvirt-type [LIBVIRT_TYPE]

ハイパーバイザーに使用する仮想化タイプ

--ntp-server [NTP_SERVER]

時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: --ntp-server 0.centos.pool.org,1.centos.pool.org)。高可用性クラスターのデプロイメントの場合には、コントローラーが一貫して同じタイムソースを参照することが必須となります。標準的な環境には、確立された慣行によって、NTP タイムソースがすでに指定されている可能性がある点に注意してください。

--no-proxy [NO_PROXY]

環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のホスト名は除外されます。

--overcloud-ssh-user OVERCLOUD_SSH_USER

オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは heat-admin ユーザーで実行されます。

-e [EXTRA HEAT TEMPLATE], --extra-template [EXTRA HEAT TEMPLATE]

オーバークラウドデプロイメントに渡す追加の環境ファイル。このオプションは複数回指定することができます。openstack overcloud deploy コマンドに渡す環境ファイルの順序が重要である点に注意してください。たとえば、逐次的に渡される各環境ファイルは、前の環境ファイルのパラメーターを上書きします。

--environment-directory

デプロイメントに追加する環境ファイルが格納されているディレクトリー。デプロイコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。

--validation-errors-nonfatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

--validation-warnings-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。

--dry-run

オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。

--skip-postconfig

オーバークラウドのデプロイ後の設定を省略します。

--force-postconfig

オーバークラウドのデプロイ後の設定を強制的に行います。

--skip-deploy-identifier

DeployIdentifier パラメーターの一意の ID 生成を省略します。ソフトウェア設定のデプロイメントステップは、実際に設定が変更された場合にしか実行されません。このオプションの使用には注意が必要です。特定のロールをスケールアウトする時など、ソフトウェア設定の実行が明らかに不要な場合にしか使用しないでください。

--answers-file ANSWERS_FILE

引数とパラメーターが記載された YAML ファイルへのパス

--rhel-reg

カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。

--reg-method

オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 は satellite、カスタマーポータルは portal

--reg-org [REG_ORG]

登録に使用する組織

--reg-force

すでに登録済みでもシステムを登録します。

--reg-sat-url [REG_SAT_URL]

オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。オーバークラウドの作成プロセスではこの URL を使用して、どのサーバーが Red Hat Satellite 5 または Red Hat Satellite 6 サーバーであるかを判断します。サーバーが Red Hat Satellite 6 サーバーの場合は、オーバークラウドは katello-ca-consumer-latest.noarch.rpm ファイルを取得して subscription-manager に登録し、katello-agent をインストールします。サーバーが Red Hat Satellite 5 サーバーの場合にはオーバークラウドは RHN-ORG-TRUSTED-SSL-CERT ファイルを取得して rhnreg_ks に登録します。

--reg-activation-key [REG_ACTIVATION_KEY]

登録に使用するアクティベーションキー

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

(undercloud) $ openstack help overcloud deploy

環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。

表6.2 非推奨の CLI パラメーターと Heat テンプレートのパラメーターの対照表

パラメーター説明Heat テンプレートのパラメーター

--control-scale

スケールアウトするコントローラーノード数

ControllerCount

--compute-scale

スケールアウトするコンピュートノード数

ComputeCount

--ceph-storage-scale

スケールアウトする Ceph Storage ノードの数

CephStorageCount

--block-storage-scale

スケールアウトする Cinder ノード数

BlockStorageCount

--swift-storage-scale

スケールアウトする Swift ノード数

ObjectStorageCount

--control-flavor

コントローラーノードに使用するフレーバー

OvercloudControllerFlavor

--compute-flavor

コンピュートノードに使用するフレーバー

OvercloudComputeFlavor

--ceph-storage-flavor

Ceph Storage ノードに使用するフレーバー

OvercloudCephStorageFlavor

--block-storage-flavor

Cinder ノードに使用するフレーバー

OvercloudBlockStorageFlavor

--swift-storage-flavor

Swift Storage ノードに使用するフレーバー

OvercloudSwiftStorageFlavor

--neutron-flat-networks

フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。

NeutronFlatNetworks

--neutron-physical-bridge

各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルト値は「br-ex」です。通常この値を変更する必要はないはずです。

HypervisorNeutronPhysicalBridge

--neutron-bridge-mappings

使用する論理ブリッジから物理ブリッジへのマッピング。ホストの外部ブリッジ (br-ex) を物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。

NeutronBridgeMappings

--neutron-public-interface

ネットワークノード向けに br-ex にブリッジするインターフェースを定義します。

NeutronPublicInterface

--neutron-network-type

Neutron のテナントネットワーク種別

NeutronNetworkType

--neutron-tunnel-types

neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronTunnelTypes

--neutron-tunnel-id-ranges

テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲

NeutronTunnelIdRanges

--neutron-vni-ranges

テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲

NeutronVniRanges

--neutron-network-vlan-ranges

サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク「datacentre」上の VLAN を許可するように設定されています。

NeutronNetworkVLANRanges

--neutron-mechanism-drivers

neutron テナントネットワークのメカニズムドライバー。デフォルトは「openvswitch」です。複数の値を指定するには、コンマ区切りの文字列を使用します。

NeutronMechanismDrivers

--neutron-disable-tunneling

VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。

パラメーターのマッピングなし

--validation-errors-fatal

オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。

パラメーターのマッピングなし

これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで削除される予定です。

6.13. オーバークラウドデプロイメントへの環境ファイルの追加

オーバークラウドをカスタマイズするための環境ファイルを追加するには、-e オプションを使用します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。

  • 各ロールのノード数およびフレーバー。オーバークラウドを作成するには、この情報の追加は不可欠です。
  • コンテナー化された OpenStack サービスのコンテナーイメージの場所。
  • 任意のネットワーク分離ファイル。Heat テンプレートコレクションの初期化ファイル (environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。詳しい情報は、『オーバークラウドの高度なカスタマイズ』の以下の章を参照してください。

  • 外部のロードバランサーを使用している場合には、外部の負荷分散機能の環境ファイル。詳細情報は、『External Load Balancing for the Overcloud』を参照してください。
  • Ceph Storage、NFS、iSCSI などのストレージ環境ファイル。
  • Red Hat CDN または Satellite 登録用の環境ファイル。
  • その他のカスタム環境ファイル。

-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。

以下のコマンドは、本シナリオの初期に定義した環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。

(undercloud) $ openstack overcloud deploy --templates \
  -e /home/stack/templates/node-info.yaml\
  -e /home/stack/containers-prepare-parameter.yaml \
  -e /home/stack/inject-trust-anchor-hiera.yaml
  -r /home/stack/templates/roles_data.yaml \

上記のコマンドでは、以下の追加オプションも使用できます。

--templates
/usr/share/openstack-tripleo-heat-templates の Heat テンプレートコレクションをベースとして使用し、オーバークラウドを作成します。
-e /home/stack/templates/node-info.yaml
各ロールに使用するノード数とフレーバーを定義する環境ファイルを追加します。
-e /home/stack/containers-prepare-parameter.yaml
コンテナーイメージ準備の環境ファイルを追加します。このファイルはアンダークラウドのインストール時に生成したもので、オーバークラウドの作成に同じファイルを使用することができます。
-e /home/stack/inject-trust-anchor-hiera.yaml
アンダークラウドにカスタム証明書をインストールする環境ファイルを追加します。
-r /home/stack/templates/roles_data.yaml
(オプション) カスタムロールを使用する、またはマルチアーキテクチャークラウドを有効にする場合に生成されるロールデータ。詳しくは、「アーキテクチャーに固有なロールの作成」を参照してください。

director は、再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。

これ以降の段階でオーバークラウド設定を変更するには、以下の操作を実施します。

  1. カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
  2. 同じ環境ファイルを指定してopenstack overcloud deploy コマンドを再度実行します。

オーバークラウドを手動で編集しても、director を使用してオーバークラウドスタックの更新を行う際に director の設定で上書きされてしまうので、設定は直接編集しないでください。

6.14. デプロイメント操作を行う前のオーバークラウド設定の検証

オーバークラウドのデプロイメント操作を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。

手順

  1. オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/overcloud-validation
  2. 以下のコマンドを使用して、テンプレート構文を検証します。

    (undercloud) $ openstack orchestration template validate --show-nested \
      --template ~/overcloud-validation/overcloud.yaml
      -e ~/overcloud-validation/overcloud-resource-registry-puppet.yaml \
      -e [ENVIRONMENT FILE] \
      -e [ENVIRONMENT FILE]

    検証には、overcloud-resource-registry-puppet.yaml の環境ファイルにオーバークラウド固有のリソースを含める必要があります。環境ファイルをさらに追加するには、このコマンドに -e オプションを使用してください。また、--show-nested オプションを追加して、ネストされたテンプレートからパラメーターを解決します。

  3. この検証コマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、作成されるオーバークラウドのテンプレートのプレビューがコマンド出力として返されます。

6.15. オーバークラウドデプロイメントの出力

オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director により、オーバークラウドへのアクセス情報も提供されます。

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

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

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrcstack ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。

(undercloud) $ source ~/overcloudrc

これで、director のホストの CLI からオーバークラウドに対話するのに必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。

(overcloud) $

director のホストとの対話に戻るには、以下のコマンドを実行します。

(overcloud) $ source ~/stackrc
(undercloud) $

オーバークラウドの各ノードには、heat-admin ユーザーも含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。

(undercloud) $ openstack server list

次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。

(undercloud) $ ssh heat-admin@192.168.24.23

6.17. 次のステップ

これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウドのインストール後タスクの実施」を参照してください。

第7章 事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定

本章では、事前にプロビジョニングされたノードを使用して OpenStack Platform 環境を設定する基本的な手順を説明します。以下のシナリオは、標準のオーバークラウド作成のシナリオとはさまざまな点で異なります。

  • 外部ツールを使用してノードをプロビジョニングしてから、director でオーバークラウドの設定のみを制御することができます。
  • director のプロビジョニングの方法に依存せずにノードを使用することができます。これは、電源管理制御なしでオーバークラウドを作成する場合や、DHCP/PXE ブートの制限があるネットワークを使用する場合に便利です。
  • director は、ノードの管理に OpenStack Compute (nova)、OpenStack Bare Betal (ironic) または OpenStack Image (glance) を使用しません。
  • 事前にプロビジョニングされたノードでは、QCOW2 overcloud-full イメージに依存しないカスタムパーティショニングレイアウトを使用することができます。

このシナリオには、カスタム機能を持たない基本的な設定のみが含まれています。ただし、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加して、仕様に合わせてカスタマイズすることができます。

重要

事前にプロビジョニングされたノードと director がプロビジョニングしたノードが混在するオーバークラウド環境はサポートされていません。

7.1. 事前にプロビジョニングされたノードの要件

  • 4章director のインストール」で作成した director ノード。
  • ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらのノードには、ホストオペレーティングシステムとして Red Hat Enterprise Linux 7.6 以降をインストールする必要があります。Red Hat では、利用可能な最新バージョンの使用を推奨します。
  • 事前にプロビジョニングされたノードを管理するためのネットワーク接続 1 つ。このシナリオでは、オーケストレーションエージェントの設定のために、ノードへの SSH アクセスが中断されないようにする必要があります。
  • コントロールプレーンネットワーク用のネットワーク接続 1 つ。このネットワークには、主に 2 つのシナリオがあります。

    • プロビジョニングネットワークをコントロールプレーンとして使用するデフォルトのシナリオ。このネットワークは通常、事前にプロビジョニングされたノードから director への Layer 3 (L3) を使用したルーティング可能なネットワーク接続です。このシナリオの例では、以下の IP アドレスの割り当てを使用します。

      表7.1 プロビジョニングネットワークの IP 割り当て

      ノード名IP アドレス

      director

      192.168.24.1

      Controller 0

      192.168.24.2

      Compute 0

      192.168.24.3

    • 別のネットワークを使用するシナリオ。director のプロビジョニングネットワークがプライベートのルーティング不可能なネットワークの場合には、サブネットからノードの IP アドレスを定義して、パブリック API エンドポイント経由で director と通信することができます。このシナリオには特定の注意事項があります。これについては、本章の後半の「事前にプロビジョニングされたノードへの別ネットワークの使用」で考察します。
  • この例で使用するその他すべてのネットワーク種別も、OpenStack サービス用のコントロールプレーンネットワークを使用します。ただし、他のネットワークトラフィック種別用に追加のネットワークを作成することができます。

7.2. 事前にプロビジョニングされたノードでのユーザーの作成

事前にプロビジョニングされたノードを使用してオーバークラウドを設定するには、director がオーバークラウドノードに stack ユーザーとして SSH アクセスする必要があります。stack ユーザーを作成するには、以下の手順を実施します。

手順

  1. 各オーバークラウドノードで、stack ユーザーを作成して、それぞれにパスワードを設定します。コントローラーノードで、以下の例に示すコマンドを実行します。

    [root@controller-0 ~]# useradd stack
    [root@controller-0 ~]# passwd stack  # specify a password
  2. sudo を使用する際に、このユーザーがパスワードを要求されないようにします。

    [root@controller-0 ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
    [root@controller-0 ~]# chmod 0440 /etc/sudoers.d/stack
  3. 事前にプロビジョニングされた全ノードで stack ユーザーの作成と設定を行った後に、director ノードから各オーバークラウドノードに stack ユーザーの公開 SSH 鍵をコピーします。director の公開 SSH 鍵をコントローラーノードにコピーするには、以下の例に示すコマンドを実行します。

    [stack@director ~]$ ssh-copy-id stack@192.168.24.2

7.3. 事前にプロビジョニングされたノードのオペレーティングシステムの登録

それぞれのノードには、Red Hat サブスクリプションへのアクセスが必要です。該当ノードを Red Hat コンテンツ配信ネットワークに登録するには、各ノードで以下の手順を実施します。

手順

  1. 登録コマンドを実行して、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。

    [root@controller-0 ~]# sudo subscription-manager register
  2. Red Hat OpenStack Platform 15 のエンタイトルメントプールを検索します。

    [root@controller-0 ~]# sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
  3. 上記のステップで特定したプール ID を使用して、Red Hat OpenStack Platform 15 のエンタイトルメントをアタッチします。

    [root@controller-0 ~]# sudo subscription-manager attach --pool=pool_id
  4. デフォルトのリポジトリーをすべて無効にします。

    [root@controller-0 ~]# sudo subscription-manager repos --disable=*
  5. 必要な Red Hat Enterprise Linux リポジトリーを有効にします。

    1. x86_64 システムの場合には、以下のコマンドを実行します。

      [root@controller-0 ~]# sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms --enable=rhel-8-for-x86_64-appstream-rpms --enable=rhel-8-for-x86_64-highavailability-rpms --enable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=openstack-15-for-rhel-8-x86_64-rpms --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms--enable=rhceph-4-mon-for-rhel-8-x86_64-rpms --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms --enable=advanced-virt-for-rhel-8-x86_64-rpms
    2. POWER システムの場合には、以下のコマンドを実行します。

      [root@controller-0 ~]# sudo subscription-manager repos --enable=rhel-8-for-ppc64le-baseos-rpms --enable=rhel-8-for-ppc64le-appstream-rpms --enable=rhel-8-for-ppc64le-highavailability-rpms --enable=ansible-2.8-for-rhel-8-ppc64le-rpms --enable=openstack-15-for-rhel-8-ppc64le-rpms --enable=advanced-virt-for-rhel-8-ppc64le-rpms
    重要

    記載されたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。

  6. システムを更新して、ベースシステムパッケージが最新の状態になるようにします。

    [root@controller-0 ~]# sudo yum update -y
    [root@controller-0 ~]# sudo reboot

このノードをオーバークラウドに使用する準備ができました。

7.4. director への SSL/TLS アクセスの設定

director が SSL/TLS を使用する場合は、事前にプロビジョニングされたノードには、director の SSL/TLS 証明書の署名に使用する認証局ファイルが必要です。独自の認証局を使用する場合には、各オーバークラウドノード上で以下の操作を実施します。

手順

  1. 事前にプロビジョニングされた各ノードの /etc/pki/ca-trust/source/anchors/ ディレクトリーに認証局ファイルをコピーします。
  2. 各オーバークラウドノード上で以下のコマンドを実行します。

    [root@controller-0 ~]#  sudo update-ca-trust extract

この手順により、オーバークラウドノードが director のパブリック API に SSL/TLS 経由でアクセスできるようになります。

7.5. コントロールプレーンのネットワークの設定

事前にプロビジョニングされたオーバークラウドノードは、標準の HTTP 要求を使用して director からメタデータを取得します。これは、オーバークラウドノードでは以下のいずれかに対して L3 アクセスが必要であることを意味します。

  • director のコントロールプレーンネットワーク。これは、undercloud.conf ファイルの network_cidr パラメーターで定義されたサブネットです。オーバークラウドノードには、このサブネットへの直接アクセスまたはルーティング可能なアクセスのいずれかが必要です。
  • undercloud.conf ファイルの undercloud_public_host パラメーターで指定された director のパブリック API エンドポイント。コントロールプレーンへの L3 ルートがない場合や、SSL/TLS 通信を使用する場合に、このオプションを利用することができます。パブリック API エンドポイントを使用するオーバークラウドノードの設定に関する補足情報は、「事前にプロビジョニングされたノードへの別ネットワークの使用」を参照してください。

director は、コントロールプレーンネットワークを使用して標準のオーバークラウドを管理、設定します。事前にプロビジョニングされたノードを使用したオーバークラウドの場合には、director と事前にプロビジョニングされたノード間の通信に対応するために、ネットワーク設定を変更しなければならない場合があります。

ネットワーク分離の使用

ネットワーク分離を使用することで、サービスをグループ化してコントロールプレーンなど特定のネットワークを使用することができます。『オーバークラウドの高度なカスタマイズ』には、ネットワーク分離の設定が複数記載されています。コントロールプレーン上のノードに特定の IP アドレスを定義することも可能です。ネットワーク分離や予測可能なノード配置方法の策定に関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』の以下のセクションを参照してください。

注記

ネットワーク分離を使用する場合には、NIC テンプレートに、アンダークラウドのアクセスに使用する NIC を含めないようにしてください。これらのテンプレートにより NIC が再構成され、デプロイメント時に接続性や設定の問題が発生する可能性があります。

IP アドレスの割り当て

ネットワーク分離を使用しない場合には、単一のコントロールプレーンを使用して全サービスを管理することができます。これには、各ノード上のコントロールプレーンの NIC を手動で設定して、コントロールプレーンネットワークの範囲内の IP アドレスを使用するようにする必要があります。director のプロビジョニングネットワークをコントロールプレーンとして使用する場合には、選択したオーバークラウドの IP アドレスが、プロビジョニング (dhcp_start および dhcp_end) とイントロスペクション (inspection_iprange) 両方の DHCP 範囲外になるようにしてください。

標準のオーバークラウド作成中には、director は OpenStack Networking (neutron) ポートを作成し、プロビジョニング/コントロールプレーンネットワークのオーバークラウドノードに IP アドレスを自動的に割り当てます。ただし、これにより、各ノードに手動で設定する IP アドレスとは異なるアドレスを director が割り当ててしまう可能性があります。このような場合には、予測可能な IP アドレス割り当て方法を使用して、director がコントロールプレーン上で事前にプロビジョニングされた IP の割り当てを強制的に使用するようにしてください。

たとえば、予測可能な IP アドレス設定を実装するために、以下の IP アドレスを割り当てた環境ファイル ctlplane-assignments.yaml を使用することができます。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml

parameter_defaults:
  DeployedServerPortMap:
    controller-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.2
      subnets:
        - cidr: 24
    compute-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.24.3
      subnets:
        - cidr: 24

この例では、OS::TripleO::DeployedServer::ControlPlanePort リソースはパラメーターセットを director に渡して、事前にプロビジョニングされたノードの IP 割り当てを定義します。DeployedServerPortMap パラメーターは、各オーバークラウドノードに対応する IP アドレスおよびサブネット CIDR を定義します。マッピングにより、以下の属性が定義されます。

  1. 割り当ての名前。形式は <node_hostname>-<network> です。ここで、<node_hostname> の値はノードの短いホスト名で、<network> はネットワークの小文字を使った名前です。たとえば、controller-0.example.com であれば controller-0-ctlplane となり、compute-0.example.com の場合は compute-0-ctlplane となります。
  2. 以下のパラメーターパターンを使用する IP 割り当て

    • fixed_ips/ip_address: コントロールプレーンの固定 IP アドレスを定義します。複数の IP アドレスを定義する場合には、複数の ip_address パラメーターを一覧で指定してください。
    • subnets/cidr: サブネットの CIDR 値を定義します。

本章のこの後のセクションで、作成された環境ファイル (ctlplane-assignments.yaml) を openstack overcloud deploy コマンドの一部として使用します。

7.6. 事前にプロビジョニングされたノードへの別ネットワークの使用

デフォルトでは、director はオーバークラウドのコントロールプレーンとしてプロビジョニングネットワークを使用します。ただし、このネットワークが分離されてルーティング不可能な場合には、ノードは設定中に director の内部 API と通信することができません。このような状況では、ノードに別のネットワークを定義して、パブリック API 経由で director と通信するように設定しなければならない場合があります。

このシナリオには、以下のような複数の要件があります。

  • オーバークラウドノードは、「コントロールプレーンのネットワークの設定」からの基本的なネットワーク設定に対応する必要があります。
  • パブリック API エンドポイントを使用できるように director 上で SSL/TLS を有効化する必要があります。詳しい情報は、「director の設定パラメーター」と「16章カスタム SSL/TLS 証明書の設定」を参照してください。
  • director 向けにアクセス可能な完全修飾ドメイン名 (FQDN) を定義する必要があります。この FQDN は、director にルーティング可能な IP アドレスを解決する必要があります。undercloud.conf ファイルの undercloud_public_host パラメーターを使用して、この FQDN を設定します。

本項に記載する例では、主要なシナリオとは異なる IP アドレスの割り当てを使用します。

表7.2 プロビジョニングネットワークの IP 割り当て

ノード名IP アドレスまたは FQDN

director (内部 API)

192.168.24.1 (プロビジョニングネットワークおよびコントロールプレーン)

director (パブリック API)

10.1.1.1 / director.example.com

オーバークラウドの仮想 IP

192.168.100.1

Controller 0

192.168.100.2

Compute 0

192.168.100.3

以下の項では、オーバークラウドノードに別のネットワークが必要な場合の追加の設定について説明します。

IP アドレスの割り当て

IP の割り当て方法は、「コントロールプレーンのネットワークの設定」に記載の手順と類似しています。ただし、コントロールプレーンはデプロイしたサーバーからルーティング可能ではないので、DeployedServerPortMap パラメーターを使用して、コントロールプレーンにアクセスする仮想 IP アドレスを含め、選択したオーバークラウドノードのサブネットから IP アドレスを割り当てる必要があります。以下の例は、「コントロールプレーンのネットワークの設定」からの ctlplane-assignments.yaml 環境ファイルを修正したもので、このネットワークアーキテクチャーに対応します。

resource_registry:
  OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
  OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml 1

parameter_defaults:
  NeutronPublicInterface: eth1
  EC2MetadataIp: 192.168.100.1 2
  ControlPlaneDefaultRoute: 192.168.100.1
  DeployedServerPortMap:
    control_virtual_ip:
      fixed_ips:
        - ip_address: 192.168.100.1
      subnets:
        - cidr: 24
    controller-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.2
      subnets:
        - cidr: 24
    compute-0-ctlplane:
      fixed_ips:
        - ip_address: 192.168.100.3
      subnets:
        - cidr: 24
1
RedisVipPort リソースは、network/ports/noop.yaml にマッピングされます。デフォルトの Redis 仮想 IP アドレスがコントロールプレーンから割り当てられているので、このマッピングが必要です。このような場合には、noop を使用して、このコントロールプレーンマッピングを無効化します。
2
EC2MetadataIpControlPlaneDefaultRoute パラメーターは、コントロールプレーンの仮想 IP アドレスの値に設定されます。デフォルトの NIC 設定テンプレートでは、これらのパラメーターが必須で、デプロイメント中に実行される検証に合格するには、ping 可能な IP アドレスを使用するように設定する必要があります。または、これらのパラメーターが必要ないように NIC 設定をカスタマイズします。

7.7. 事前にプロビジョニングされたノードのホスト名のマッピング

事前にプロビジョニングされたノードを設定する場合には、Heat ベースのホスト名をそれらの実際のホスト名にマッピングして、ansible-playbook が解決されたホストに到達できるようにする必要があります。それらの値は、HostnameMap を使用してマッピングします。

手順

  1. 環境ファイル (たとえば hostname-map.yaml) を作成して、HostnameMap パラメーターとホスト名のマッピングを指定します。以下の構文を使用してください。

    parameter_defaults:
      HostnameMap:
        [HEAT HOSTNAME]: [ACTUAL HOSTNAME]
        [HEAT HOSTNAME]: [ACTUAL HOSTNAME]

    [HEAT HOSTNAME] は通常 [STACK NAME]-[ROLE]-[INDEX] の表記法に従います。

    parameter_defaults:
      HostnameMap:
        overcloud-controller-0: controller-00-rack01
        overcloud-controller-1: controller-01-rack02
        overcloud-controller-2: controller-02-rack03
        overcloud-novacompute-0: compute-00-rack01
        overcloud-novacompute-1: compute-01-rack01
        overcloud-novacompute-2: compute-02-rack01
  2. hostname-map.yaml ファイルを保存します。

7.8. 事前にプロビジョニングされたノード向けの Ceph Storage の設定

すでにデプロイされているノードに ceph-ansible を設定するには、アンダークラウドホストで以下の手順を実施します。

手順

  1. アンダークラウドホストで環境変数 OVERCLOUD_HOSTS を作成し、変数に Ceph クライアントとして使用するオーバークラウドホストの IP アドレスのスペース区切りリストを設定します。

    export OVERCLOUD_HOSTS="192.168.1.8 192.168.1.42"
  2. enable-ssh-admin.sh スクリプトを実行して、Ansible が Ceph クライアントの設定に使用することのできるオーバークラウドノードのユーザーを設定します。

    bash /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

openstack overcloud deploy コマンドを実行すると、Ansible は OVERCLOUD_HOSTS 変数で Ceph クライアントとして定義したホストを設定します。

7.9. 事前にプロビジョニングされたノードを使用したオーバークラウドの作成

オーバークラウドのデプロイメントには、「デプロイメントコマンド」に記載された標準の CLI の方法を使用します。事前にプロビジョニングされたノードの場合は、デプロイメントコマンドに追加のオプションと、コア Heat テンプレートコレクションからの環境ファイルが必要です。

  • --disable-validations: 事前にプロビジョニングされたインフラストラクチャーで使用しないサービスに対する基本的な CLI 検証を無効化します。無効化しないと、デプロイメントに失敗します。
  • environments/deployed-server-environment.yaml: 事前にプロビジョニングされたインフラストラクチャーを作成、設定するための基本環境ファイル。この環境ファイルは、OS::Nova::Server リソースを OS::Heat::DeployedServer リソースに置き換えます。
  • environments/deployed-server-bootstrap-environment-rhel.yaml: 事前にプロビジョニングされたサーバー上でブートストラップのスクリプトを実行する環境ファイル。このスクリプトは追加パッケージをインストールし、オーバークラウドノードの基本設定を提供します。
  • environments/deployed-server-pacemaker-environment.yaml: 事前にプロビジョニングされたコントローラーノードで Pacemaker の設定を行う環境ファイル。このファイルに登録されるリソースの名前空間は、deployed-server/deployed-server-roles-data.yaml からのコントローラーのロール名を使用します。デフォルトでは、ControllerDeployedServer となっています。
  • deployed-server/deployed-server-roles-data.yaml: カスタムロールのサンプルファイル。これは、デフォルトの roles_data.yaml が複製されたファイルですが、各ロールの disable_constraints: True パラメーターも含まれています。このパラメーターは、生成されたロールテンプレートのオーケストレーションの制約を無効にします。これらの制約は、事前にプロビジョニングされたインフラストラクチャーが使用しないサービスが対象です。

    カスタムロールファイルを使用する場合には、それぞれのロールに disable_constraints: True パラメーターを追加するようにしてください。

    - name: ControllerDeployedServer
      disable_constraints: True
      CountDefault: 1
      ServicesDefault:
        - OS::TripleO::Services::CACerts
        - OS::TripleO::Services::CephMon
        - OS::TripleO::Services::CephExternal
        - OS::TripleO::Services::CephRgw
        ...

以下のコマンドは、事前にプロビジョニングされたアーキテクチャー固有の環境ファイルを使用したオーバークラウドデプロイメントコマンドの例です。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy \
  [other arguments] \
  --disable-validations \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-bootstrap-environment-rhel.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-pacemaker-environment.yaml \
  -e /home/stack/templates/hostname-map.yaml /
  -r /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-server-roles-data.yaml
  --overcloud-ssh-user stack \
  --overcloud-ssh-key ~/.ssh/id_rsa \
  [OTHER OPTIONS]

--overcloud-ssh-user および --overcloud-ssh-key オプションは、設定ステージ中に各オーバークラウドノードに SSH 接続して、初期 tripleo-admin ユーザーを作成し、SSH キーを /home/tripleo-admin/.ssh/authorized_keys に挿入するのに使用します。SSH キーを挿入するには、--overcloud-ssh-user および --overcloud-ssh-key (~/.ssh/id_rsa がデフォルト) を使用して、初回 SSH 接続用の認証情報を指定します。--overcloud-ssh-key オプションで指定する秘密鍵の公開を制限するために、director は Heat や Mistral などのどの API サービスにもこの鍵を渡さず、director の openstack overcloud deploy コマンドだけがこの鍵を使用して tripleo-admin ユーザーのアクセスを有効化します。

7.10. オーバークラウドデプロイメントの出力

オーバークラウドの作成が完了すると、オーバークラウドを設定するために実施された Ansible のプレイの概要が director により提示されます。

PLAY RECAP *************************************************************
overcloud-compute-0     : ok=160  changed=67   unreachable=0    failed=0
overcloud-controller-0  : ok=210  changed=93   unreachable=0    failed=0
undercloud              : ok=10   changed=7    unreachable=0    failed=0

Tuesday 15 October 2018  18:30:57 +1000 (0:00:00.107) 1:06:37.514 ******
========================================================================

director により、オーバークラウドへのアクセス情報も提供されます。

Ansible passed.
Overcloud configuration completed.
Overcloud Endpoint: http://192.168.24.113:5000
Overcloud Horizon Dashboard URL: http://192.168.24.113:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed

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

director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrcstack ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。

(undercloud) $ source ~/overcloudrc

これで、director のホストの CLI からオーバークラウドに対話するのに必要な環境変数が読み込まれます。コマンドプロンプトが変わり、オーバークラウドと対話していることが示されます。

(overcloud) $

director のホストとの対話に戻るには、以下のコマンドを実行します。

(overcloud) $ source ~/stackrc
(undercloud) $

オーバークラウドの各ノードには、heat-admin ユーザーも含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。

(undercloud) $ openstack server list

次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。

(undercloud) $ ssh heat-admin@192.168.24.23

7.12. 事前にプロビジョニングされたノードのスケーリング

事前にプロビジョニングされたノードをスケーリングするプロセスは、「13章オーバークラウドノードのスケーリング」に記載する標準のスケーリング手順と類似しています。ただし、事前にプロビジョニングされたノードを新たに追加するプロセスは異なります。これは、事前にプロビジョニングされたノードが OpenStack Bare Metal (ironic) および OpenStack Compute (nova) からの標準の登録および管理プロセスを使用しないためです。

事前にプロビジョニングされたノードのスケールアップ

事前にプロビジョニングされたノードでオーバークラウドをスケールアップする際には、各ノードで director のノード数に対応するようにオーケストレーションエージェントを設定する必要があります。

オーバークラウドノードをスケールアップするには、以下の操作を実施します。

  1. 「事前にプロビジョニングされたノードの要件」の説明に従って、事前にプロビジョニングされたノードを新たに準備します。
  2. ノードをスケールアップします。手順については「13章オーバークラウドノードのスケーリング」を参照してください。
  3. デプロイメントコマンドを実行した後に、director が新しいノードリソースを作成して設定を開始するまで待ちます。

事前にプロビジョニングされたノードのスケールダウン

事前にプロビジョニングされたノードを持つオーバークラウドをスケールダウンするには、「13章オーバークラウドノードのスケーリング」に記載する通常のスケールダウン手順に従います。

ほとんどのスケーリング操作では、削除するノードの UUID 値を取得し、その値を openstack overcloud node delete コマンドに渡す必要があります。この UUID を取得するには、ロールを指定してリソースの一覧を表示します。

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::<RoleName>Server

<RoleName> を、スケールダウンするロールの実際の名前に置き換えます。たとえば、ComputeDeployedServer ロールの場合には、以下のコマンドを実行します。

$ openstack stack resource list overcloud -c physical_resource_id -c stack_name -n5 --filter type=OS::TripleO::ComputeDeployedServerServer

コマンド出力の stack_name 列から、各ノードに関連付けられた UUID を確認します。stack_name には、Heat リソースグループ内のノードインデックスの整数値が含まれます。

+------------------------------------+----------------------------------+
| physical_resource_id               | stack_name                       |
+------------------------------------+----------------------------------+
| 294d4e4d-66a6-4e4e-9a8b-           | overcloud-ComputeDeployedServer- |
| 03ec80beda41                       | no7yfgnh3z7e-1-ytfqdeclwvcg      |
| d8de016d-                          | overcloud-ComputeDeployedServer- |
| 8ff9-4f29-bc63-21884619abe5        | no7yfgnh3z7e-0-p4vb3meacxwn      |
| 8c59f7b1-2675-42a9-ae2c-           | overcloud-ComputeDeployedServer- |
| 2de4a066f2a9                       | no7yfgnh3z7e-2-mmmaayxqnf3o      |
+------------------------------------+----------------------------------+

stack_name 列のインデックス 0、1、または 2 は、Heat リソースグループ内のノード順に対応します。physical_resource_id 列の該当する UUID 値を、openstack overcloud node delete コマンドに渡します。

スタックからオーバークラウドノードを削除したら、それらのノードの電源をオフにします。標準のデプロイメントでは、director のベアメタルサービスがこの機能を制御します。ただし、事前にプロビジョニングされたノードでは、これらのノードを手動でシャットダウンするか、物理システムごとに電源管理制御を使用する必要があります。スタックからノードを削除した後にノードの電源をオフにしないと、稼動状態が続き、オーバークラウド環境の一部として再接続されてしまう可能性があります。

削除したノードの電源をオフにした後に、それらのノードをベースオペレーティングシステムの構成に再プロビジョニングし、意図せずにオーバークラウドに加わらないようにします。

注記

オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールしてからでなければ、再利用しないようにしてください。スケールダウンのプロセスでは、オーバークラウドスタックからノードを削除するだけで、パッケージはアンインストールされません。

7.13. 事前にプロビジョニングされたオーバークラウドの削除

事前にプロビジョニングされたノードを使用するオーバークラウド全体を削除するには、「オーバークラウドの削除」で標準のオーバークラウド削除手順を参照してください。オーバークラウドを削除した後に、全ノードの電源をオフにしてからベースオペレーティングシステムの構成に再プロビジョニングします。

注記

オーバークラウドから以前に削除したノードは、再プロビジョニングしてベースオペレーティングシステムを新規インストールしてからでなければ、再利用しないようにしてください。削除のプロセスでは、オーバークラウドスタックを削除するだけで、パッケージはアンインストールされません。

7.14. 次のステップ

これで、事前にプロビジョニングされたノードを使用したオーバークラウドの作成が完了しました。作成後の機能については、「9章オーバークラウドのインストール後タスクの実施」を参照してください。

第8章 複数のオーバークラウドのデプロイ

重要

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

1 つのアンダークラウドノードを使用して、複数のオーバークラウドをデプロイおよび管理することができます。それぞれのオーバークラウドは、スタックリソースを共有しない個別の heat スタックです。この構成は、アンダークラウドとオーバークラウドの比率が 1 : 1 の環境で、無視できない程度のオーバーヘッドが発生する場合に有用です。たとえば、エッジサイト、複数サイト、および複数製品にまたがる環境などです。

複数オーバークラウドのシナリオにおけるオーバークラウド環境は完全に独立し、source コマンドを使用して環境間の切り替えを行うことができます。ベアメタルのプロビジョニングに Ironic を使用する場合には、すべてのオーバークラウドが同じプロビジョニングネットワーク上に存在している必要があります。同じプロビジョニングネットワークを使用することができない場合には、デプロイされたサーバー法を使用してルーティングされたネットワークで複数のオーバークラウドをデプロイすることができます。これにより、HostnameMap パラメーターの値が各オーバークラウドのスタック名と一致するようになります。

以下のワークフローを使用して、基本的なプロセスについて説明します。

アンダークラウドのデプロイ
通常どおりにアンダークラウドをデプロイします。詳細な情報は、パートI「director のインストールと設定」を参照してください。
最初のオーバークラウドのデプロイ
通常どおりに最初のアンダークラウドをデプロイします。詳細な情報は、パートII「基本的なオーバークラウドのデプロイメント」を参照してください。
追加のオーバークラウドのデプロイ
新しいオーバークラウド用に新たな環境ファイルのセットを作成します。コアの heat テンプレートと共に新たな設定ファイルおよび新しい stack 名を指定して、デプロイコマンドを実行します。

8.1. 追加のオーバークラウドのデプロイ

以下の例では、既存のオーバークラウドを overcloud-one としています。新たなオーバークラウド overcloud-two をデプロイするには、以下の手順を実施します。

前提条件

追加のオーバークラウドのデプロイを開始する前に、ご自分の環境に以下の構成が含まれるようにします。

  • 正常にデプロイされたアンダークラウドおよびオーバークラウド。
  • 追加のオーバークラウドで利用可能なノード。
  • それぞれのオーバークラウドが作成されるスタックで固有のネットワークを持つように、追加のオーバークラウド用のカスタムネットワーク。

手順

  1. デプロイする追加のオーバークラウド用に、新たなディレクトリーを作成します。

    $ mkdir ~/overcloud-two
  2. 新しいディレクトリーにおいて、追加のオーバークラウドの要件に固有な新しい環境ファイルを作成し、該当するすべての環境ファイルを既存のオーバークラウドからコピーします。

    $ cp network-data.yaml ~/overcloud-two/network-data.yaml
    $ cp network-environment.yaml ~/overcloud-two/network-environment.yaml
  3. 新たなオーバークラウドの仕様に従って、環境ファイルを変更します。たとえば、既存のオーバークラウドの名前が overcloud-one で、network-data.yaml 環境ファイルで定義する VLAN を使用する場合、環境ファイルは以下のようになります。

    - name: InternalApi
      name_lower: internal_api_cloud_1
      service_net_map_replace: internal_api
      vip: true
      vlan: 20
      ip_subnet: '172.17.0.0/24'
      allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
      ipv6_subnet: 'fd00:fd00:fd00:2000::/64'
      ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
      mtu: 1500
    - name: Storage
      ...

    新たなオーバークラウドは overcloud-two という名前で、異なる VLAN を使用します。~/overcloud-two/network-data.yaml 環境ファイルを編集し、各サブネット用の新たな VLAN ID を追加します。また、固有の name_lower 値を定義し、service_net_map_replace 属性を、置き換えるネットワークの名前に設定する必要があります。

    - name: InternalApi
      name_lower: internal_api_cloud_2
      service_net_map_replace: internal_api
      vip: true
      vlan: 21
      ip_subnet: '172.21.0.0/24'
      allocation_pools: [{'start': '172.21.0.4', 'end': '172.21.0.250'}]
      ipv6_subnet: 'fd00:fd00:fd00:2001::/64'
      ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2001::10', 'end': 'fd00:fd00:fd00:2001:ffff:ffff:ffff:fffe'}]
      mtu: 1500
    - name: Storage
      ...
  4. ~/overcloud-two/network-environment.yaml ファイルの以下のパラメーターを変更します。

    • overcloud-two に固有の外部ネットワークが設定されるように、ExternalNetValueSpecs パラメーターの {'provider:physical_network'} 属性に固有の値を入力し、'provider:network_type' 属性でネットワーク種別を定義します。
    • オーバークラウドの外部アクセスが可能になるように、ExternalInterfaceDefaultRoute パラメーターを外部ネットワークのゲートウェイの IP アドレスに設定します。
    • オーバークラウドが DNS サーバーにアクセスできるように、DnsServers パラメーターを DNS サーバーの IP アドレスに設定します。

      parameter_defaults:
        ...
        ExternalNetValueSpecs: {'provider:physical_network': 'external_2', 'provider:network_type': 'flat'}
        ExternalInterfaceDefaultRoute: 10.0.10.1
        DnsServers:
          - 10.0.10.2
        ...
  5. openstack overcloud deploy コマンドを実行します。--templates オプションおよび --stack オプションを使用して、それぞれコアの heat テンプレートコレクションおよび新たな stack 名を指定します。また、~/overcloud-two ディレクトリーからの新規環境ファイルをすべて指定します。

    $ openstack overcloud deploy --templates \
        --stack overcloud-two \
        ...
        -n ~/overcloud-two/network-data.yaml \
        -e ~/overcloud-two/network-environment.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
        ...

それぞれのオーバークラウドには、固有の認証情報ファイルが設定されます。ここでの例では、デプロイメントプロセスにより overcloud-one 用に overcloud-onerc が、overcloud-two 用に overcloud-tworc が、それぞれ作成されます。いずれかのオーバークラウドに関する操作を行うには、source コマンドで適切な認証情報ファイルを読み込む必要があります。たとえば、source コマンドを使用して最初のオーバークラウドの認証情報を読み込むには、以下のコマンドを実行します。

$ source overcloud-onerc

8.2. 複数のオーバークラウドの管理

デプロイするそれぞれのオーバークラウドでは、同じコア heat テンプレートセット /usr/share/openstack-tripleo-heat-templates が使用されます。非標準のコアテンプレートセットを使用すると、更新およびアップグレード時に問題が発生する可能性があるので、Red Hat では、これらのテンプレートを変更したり複製したりしないことを推奨します。

その代わりに、複数のオーバークラウドをデプロイまたは維持する際の管理を容易にするため、各クラウドに固有の環境ファイル用ディレクトリーを個別に作成します。各クラウドのデプロイコマンドを実行する際に、コア heat テンプレートと共に個別に作成したクラウド固有の環境ファイルを含めます。たとえば、アンダークラウドおよび 2 つのオーバークラウド用に以下のディレクトリーを作成します。

~stack/undercloud
アンダークラウドに固有の環境ファイルを保管します。
~stack/overcloud-one
最初のオーバークラウドに固有の環境ファイルを保管します。
~stack/overcloud-two
2 番目のオーバークラウドに固有の環境ファイルを保管します。

overcloud-one または overcloud-two をデプロイまたは再デプロイする場合には、--templates オプションでデプロイコマンドにコア heat テンプレートを追加し、続いてクラウド固有の環境ファイルディレクトリーからの追加環境ファイルをすべて指定します。

あるいは、バージョン管理システムにリポジトリーを作成し、デプロイメントごとにブランチを使用します。詳しくは、『オーバークラウドの高度なカスタマイズ』「カスタムのコア Heat テンプレートの使用」セクションを参照してください。

利用可能なオーバークラウドプランの一覧を表示するには、以下のコマンドを使用します。

$ openstack overcloud plan list

現在デプロイされているオーバークラウドの一覧を表示するには、以下のコマンドを使用します。

$ openstack stack list

パート III. デプロイメント後操作

第9章 オーバークラウドのインストール後タスクの実施

本章では、オーバークラウド作成のすぐ後に実施するタスクについて説明します。これらのタスクにより、オーバークラウドを使用可能な状態にすることができます。

9.1. オーバークラウドデプロイメントステータスの確認

オーバークラウドのデプロイメントステータスを確認するには、openstack overcloud status コマンドを使用します。このコマンドにより、すべてのデプロイメントステップの結果が返されます。

手順

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

    $ source ~/stackrc
  2. デプロイメントステータスの確認コマンドを実行します。

    $ openstack overcloud status

    このコマンドの出力に、オーバークラウドのステータスが表示されます。

    +-----------+---------------------+---------------------+-------------------+
    | Plan Name |       Created       |       Updated       | Deployment Status |
    +-----------+---------------------+---------------------+-------------------+
    | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 |   DEPLOY_SUCCESS  |
    +-----------+---------------------+---------------------+-------------------+

    ご自分のオーバークラウドに別の名前が使用されている場合には、--plan 引数を使用してその名前のオーバークラウドを選択します。

    $ openstack overcloud status --plan my-deployment

9.2. 基本的なオーバークラウドフレーバーの作成

本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 1 つのフレーバーも作成していない場合には、以下のコマンドを使用して、さまざまなストレージおよび処理能力に対応する基本的なデフォルトフレーバーセットを作成してください。

手順

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

    $ source ~/overcloudrc
  2. openstack flavor create コマンドを実行してフレーバーを作成します。以下のオプションにより、各フレーバーのハードウェア要件を指定します。

    --disk
    仮想マシンのボリュームのハードディスク容量を定義します。
    --ram
    仮想マシンに必要な RAM を定義します。
    --vcpus
    仮想マシンの仮想 CPU 数を定義します。
  3. デフォルトのオーバークラウドフレーバー作成の例を以下に示します。

    $ openstack flavor create m1.tiny --ram 512 --disk 0 --vcpus 1
    $ openstack flavor create m1.smaller --ram 1024 --disk 0 --vcpus 1
    $ openstack flavor create m1.small --ram 2048 --disk 10 --vcpus 1
    $ openstack flavor create m1.medium --ram 3072 --disk 10 --vcpus 2
    $ openstack flavor create m1.large --ram 8192 --disk 10 --vcpus 4
    $ openstack flavor create m1.xlarge --ram 8192 --disk 10 --vcpus 8
注記

openstack flavor create コマンドについての詳しい情報は、$ openstack flavor create --help で確認してください。

9.3. デフォルトのテナントネットワークの作成

仮想マシンが内部で通信できるように、オーバークラウドにはデフォルトのテナントネットワークが必要です。

手順

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

    $ source ~/overcloudrc
  2. デフォルトのテナントネットワークを作成します。

    (overcloud) $ openstack network create default
  3. ネットワーク上にサブネットを作成します。

    (overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
  4. 作成したネットワークを確認します。

    (overcloud) $ openstack network list
    +-----------------------+-------------+--------------------------------------+
    | id                    | name        | subnets                              |
    +-----------------------+-------------+--------------------------------------+
    | 95fadaa1-5dda-4777... | default     | 7e060813-35c5-462c-a56a-1c6f8f4f332f |
    +-----------------------+-------------+--------------------------------------+

これらのコマンドにより、defaultという名前の基本的な Neutron ネットワークが作成されます。オーバークラウドは内部 DHCP メカニズムを使用して、このネットワークから仮想マシンに IP アドレスを自動的に割り当てます。

9.4. デフォルトの Floating IP ネットワークの作成

この手順では、オーバークラウド上に外部ネットワークを作成する方法について説明します。オーバークラウド外部の仮想マシンにアクセスできるように、このネットワークは Floating IP アドレスを提供します。

この手順では、2 つの例を説明します。

  • ネイティブ VLAN (フラットネットワーク)
  • 非ネイティブ VLAN (VLAN ネットワーク)

ご自分の環境に最も適した例を使用してください。

これらの例の両方で、public という名前のネットワークを作成します。オーバークラウドでは、デフォルトの Floating IP プールにこの特定の名前が必要です。この名前は、「オーバークラウドの検証」の検証テストでも重要となります。

デフォルトでは、OpenStack Networking (neutron) は、datacentre という物理ネットワーク名をホストノード上の br-ex ブリッジにマッピングします。public オーバークラウドネットワークを物理ネットワーク datacentre に接続し、これにより br-ex ブリッジを通じてゲートウェイが提供されます。

以下の手順では、Floating IP ネットワーク向けの専用インターフェースまたはネイティブ VLAN が設定されていることを前提としています。

手順

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

    $ source ~/overcloudrc
  2. public ネットワークを作成します。

    • ネイティブ VLAN 接続用に flat ネットワークを作成します。

      (overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
    • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

      (overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201

      --provider-segment の値で、使用する VLAN を定義します。ここでは、201 です。

  3. Floating IP アドレスの割り当てプールを使用してサブネットを作成します。ここでは、IP 範囲は 10.1.1.51 から 10.1.1.250 です。

    (overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24

    この範囲が、外部ネットワークの他の IP アドレスと競合しないようにしてください。

9.5. デフォルトのプロバイダーネットワークの作成

プロバイダーネットワークは別の種別の外部ネットワーク接続で、トラフィックをプライベートテナントネットワークから外部インフラストラクチャーネットワークにルーティングします。このネットワークは Floating IP ネットワークと類似していますが、プライベートネットワークをプロバイダーネットワークに接続するのに、論理ルーターが使用されます。

この手順では、2 つの例を説明します。

  • ネイティブ VLAN (フラットネットワーク)
  • 非ネイティブ VLAN (VLAN ネットワーク)

ご自分の環境に最も適した例を使用してください。

デフォルトでは、OpenStack Networking (neutron) は、datacentre という物理ネットワーク名をホストノード上の br-ex ブリッジにマッピングします。public オーバークラウドネットワークを物理ネットワーク datacentre に接続し、これにより br-ex ブリッジを通じてゲートウェイが提供されます。

手順

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

    $ source ~/overcloudrc
  2. provider ネットワークを作成します。

    • ネイティブ VLAN 接続用に flat ネットワークを作成します。

      (overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share
    • 非ネイティブ VLAN 接続用に vlan ネットワークを作成します。

      (overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share

      --provider-segment の値で、使用する VLAN を定義します。ここでは、201 です。

    例に示すこれらのコマンドにより、共有ネットワークが作成されます。テナントだけが新しいネットワークにアクセスするように、--share を指定する代わりにテナントを指定することも可能です。

    プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。

  3. provider ネットワークにサブネットを追加して、DHCP サービスを提供します。

    (overcloud) $ openstack subnet create provider-subnet --network  provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24
  4. 他のネットワークがプロバイダーネットワークを通じてトラフィックをルーティングできるように、ルーターを作成します。

    (overcloud) $ openstack router create external
  5. ルーターの外部ゲートウェイを provider ネットワークに設定します。

    (overcloud) $ openstack router set --external-gateway provider external
  6. このルーターに他のネットワークを接続します。たとえば、以下のコマンドを実行してサブネット「subnet1」をルーターに割り当てます。

    (overcloud) $ openstack router add subnet external subnet1

    このコマンドにより、subnet1 がルーティングテーブルに追加され、subnet1 を使用する仮想マシンからのトラフィックをプロバイダーネットワークにルーティングできるようになります。

9.6. 新たなブリッジマッピングの作成

Floating IP ネットワークは、以下の条件を満たす限りは、br-ex だけでなく、どのブリッジにも使用することができます。

  • ネットワーク環境ファイルで、NeutronExternalNetworkBridge"''" に設定されている。
  • デプロイ中に追加のブリッジをマッピングしている。たとえば、br-floating という新規ブリッジを floating という物理ネットワークにマッピングするには、環境ファイルに NeutronBridgeMappings パラメーターを追加します。

    parameter_defaults:
      NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"

この手法により、オーバークラウドの作成後に独立した外部ネットワークを作成することができます。たとえば、floating 物理ネットワークにマッピングする Floating IP ネットワークを作成するには、以下のコマンドを実行します。

$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24

9.7. オーバークラウドの検証

オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項では、統合テストを実施するための準備について説明します。OpenStack Integration Test Suite の使用方法に関する詳しい説明は、『OpenStack Integration Test Suite Guide』を参照してください。

Integration Test Suite では、テストを成功させるために、いくつかのインストール後手順が必要になります。

手順

  1. アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して内部 API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。

    $ source ~/stackrc
    (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
    (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
  2. OpenStack Integration Test Suite を実行する前に、heat_stack_owner ロールがオーバークラウドに存在することを確認してください。

    $ source ~/overcloudrc
    (overcloud) $ openstack role list
    +----------------------------------+------------------+
    | ID                               | Name             |
    +----------------------------------+------------------+
    | 6226a517204846d1a26d15aae1af208f | swiftoperator    |
    | 7c7eb03955e545dd86bbfeb73692738b | heat_stack_owner |
    +----------------------------------+------------------+
  3. このロールが存在しない場合は、作成します。

    (overcloud) $ openstack role create heat_stack_owner
  4. 『OpenStack Integration Test Suite Guide』の説明に従って、統合テストを実施します。
  5. 検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。

    $ source ~/stackrc
    (undercloud) $ sudo ovs-vsctl del-port vlan201

9.8. オーバークラウドの削除防止

Heat に含まれるコードベースのデフォルトポリシーセットは、/etc/heat/policy.json を作成してカスタムルールを追加することでオーバーライドすることができます。全員 のオーバークラウド削除権限を無効にするには、以下のポリシーを追加します。

{"stacks:delete": "rule:deny_everybody"}

これにより heat クライアントによるオーバークラウドの削除が阻止されます。オーバークラウドを削除できるように設定するには、カスタムポリシーを削除して /etc/heat/policy.json を保存します。

第10章 基本的なオーバークラウド管理タスクの実施

本章では、オーバークラウドのライフサイクル期間中に実行しなければならない可能性がある、基本的なタスクについて説明します。

10.1. コンテナー化されたサービスの管理

OpenStack Platform では、アンダークラウドおよびオーバークラウドノード上のコンテナー内でサービスが実行されます。特定の状況では、1 つのホスト上で個別のサービスを制御する必要がある場合があります。本項では、コンテナー化されたサービスを管理するためにノード上で実行することのできる、一般的なコマンドについて説明します。

コンテナーとイメージの一覧表示

実行中のコンテナーを一覧表示するには、以下のコマンドを実行します。

$ sudo podman ps

コマンド出力に停止中またはエラーの発生したコンテナーを含めるには、コマンドに --all オプションを追加します。

$ sudo podman ps --all

コンテナーイメージを一覧表示するには、以下のコマンドを実行します。

$ sudo podman images

コンテナーのプロパティーの確認

コンテナーまたはコンテナーイメージのプロパティーを表示するには、podman inspect コマンドを使用します。たとえば、keystone コンテナーを検査するには、以下のコマンドを実行します。

$ sudo podman inspect keystone

Systemd サービスを使用したコンテナーの管理

以前のバージョンの OpenStack Platform では、コンテナーは Docker およびそのデーモンで管理されていました。OpenStack Platform 15 では、Systemd サービスインターフェースでコンテナーのライフサイクルが管理されます。それぞれのコンテナーはサービスであり、以下のコマンドを実行して各コンテナーに関する特定の操作を実施します。

注記

Systemd は再起動ポリシーを適用するため、Podman CLI を使用してコンテナーを停止、起動、および再起動することは推奨されません。その代わりに、Systemd サービスコマンドを使用してください。

コンテナーのステータスを確認するには、systemctl status コマンドを実行します。

$ sudo systemctl status tripleo_keystone
● tripleo_keystone.service - keystone container
   Loaded: loaded (/etc/systemd/system/tripleo_keystone.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-02-15 23:53:18 UTC; 2 days ago
 Main PID: 29012 (podman)
   CGroup: /system.slice/tripleo_keystone.service
           └─29012 /usr/bin/podman start -a keystone

コンテナーを停止するには、systemctl stop コマンドを実行します。

$ sudo systemctl stop tripleo_keystone

コンテナーを起動するには、systemctl start コマンドを実行します。

$ sudo systemctl start tripleo_keystone

コンテナーを再起動するには、systemctl restart コマンドを実行します。

$ sudo systemctl restart tripleo_keystone

コンテナーステータスを監視するデーモンはないので、以下の状況では Systemd はほとんどのコンテナーを自動的に再起動します。

  • podman stop コマンドの実行など、明瞭な終了コードまたはシグナル。
  • 起動後に podman コンテナーがクラッシュするなど、不明瞭な終了コード。
  • 不明瞭なシグナル。
  • コンテナーの起動に 1 分 30 秒以上かかった場合のタイムアウト。

Systemd サービスに関する詳しい情報は、systemd.service のドキュメント を参照してください。

注記

コンテナー内のサービス設定ファイルに加えた変更は、コンテナーの再起動後には元に戻ります。これは、コンテナーがノードのローカルファイルシステム上の /var/lib/config-data/puppet-generated/ にあるファイルに基づいてサービス設定を再生成するためです。たとえば、keystone コンテナー内の /etc/keystone/keystone.conf を編集してコンテナーを再起動すると、そのコンテナーはノードのローカルシステム上にある /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf を使用して設定を再生成します。再起動前にコンテナー内で加えられた変更は、この設定によって上書きされます。

Systemd タイマーを使用した podman コンテナーの監視

Systemd タイマーインターフェースは、コンテナーのヘルスチェックを管理します。各コンテナーのタイマーがサービスユニットを実行し、そのユニットがヘルスチェックスクリプトを実行します。

すべての OpenStack Platform コンテナーのタイマーを一覧表示するには、systemctl list-timers コマンドを実行し、出力を tripleo が含まれる行に限定します。

$ sudo systemctl list-timers | grep tripleo
Mon 2019-02-18 20:18:30 UTC  1s left       Mon 2019-02-18 20:17:26 UTC  1min 2s ago  tripleo_nova_metadata_healthcheck.timer            tripleo_nova_metadata_healthcheck.service
Mon 2019-02-18 20:18:33 UTC  4s left       Mon 2019-02-18 20:17:03 UTC  1min 25s ago tripleo_mistral_engine_healthcheck.timer           tripleo_mistral_engine_healthcheck.service
Mon 2019-02-18 20:18:34 UTC  5s left       Mon 2019-02-18 20:17:23 UTC  1min 5s ago  tripleo_keystone_healthcheck.timer                 tripleo_keystone_healthcheck.service
Mon 2019-02-18 20:18:35 UTC  6s left       Mon 2019-02-18 20:17:13 UTC  1min 15s ago tripleo_memcached_healthcheck.timer                tripleo_memcached_healthcheck.service
(...)

特定のコンテナータイマーのステータスを確認するには、healthcheck サービスに対して systemctl status コマンドを実行します。

$ sudo systemctl status tripleo_keystone_healthcheck.service
● tripleo_keystone_healthcheck.service - keystone healthcheck
   Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.service; disabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2019-02-18 20:22:46 UTC; 22s ago
  Process: 115581 ExecStart=/usr/bin/podman exec keystone /openstack/healthcheck (code=exited, status=0/SUCCESS)
 Main PID: 115581 (code=exited, status=0/SUCCESS)

Feb 18 20:22:46 undercloud.localdomain systemd[1]: Starting keystone healthcheck...
Feb 18 20:22:46 undercloud.localdomain podman[115581]: {"versions": {"values": [{"status": "stable", "updated": "2019-01-22T00:00:00Z", "..."}]}]}}
Feb 18 20:22:46 undercloud.localdomain podman[115581]: 300 192.168.24.1:35357 0.012 seconds
Feb 18 20:22:46 undercloud.localdomain systemd[1]: Started keystone healthcheck.

コンテナータイマーを停止、起動、再起動、およびコンテナータイマーのステータスを表示するには、.timer Systemd リソースに対して該当する systemctl コマンドを実行します。たとえば、tripleo_keystone_healthcheck.timer リソースのステータスを確認するには、以下のコマンドを実行します。

$ sudo systemctl status tripleo_keystone_healthcheck.timer
● tripleo_keystone_healthcheck.timer - keystone container healthcheck
   Loaded: loaded (/etc/systemd/system/tripleo_keystone_healthcheck.timer; enabled; vendor preset: disabled)
   Active: active (waiting) since Fri 2019-02-15 23:53:18 UTC; 2 days ago

healthcheck サービスは無効だが、そのサービスのタイマーが存在し有効になっている場合には、チェックは現在タイムアウトしているが、タイマーに従って実行されることを意味します。いつでもチェックを手動で開始することができます。

注記

podman ps コマンドは、コンテナーのヘルスステータスを表示しません。

コンテナーログの確認

OpenStack Platform 15 では、新たなロギングディレクトリー /var/log/containers/stdout が導入されています。ここには、すべてのコンテナーの標準出力 (stdout) と標準エラー (stderr) が、コンテナーごとに 1 つのファイルに統合されて保存されます。

paunch および container-puppet.py スクリプトは、出力を /var/log/containers/stdout ディレクトリーにプッシュするように podman コンテナーを設定します。これにより、container-puppet-* コンテナー等の削除されたコンテナーを含め、すべてのログのコレクションが作成されます。

また、ホストはこのディレクトリーにログローテーションを適用し、大きな容量のファイルがディスク容量を消費する問題を防ぎます。

コンテナーが置き換えられた場合には、新しいコンテナーは同じログファイルにログを出力します。podman はコンテナー ID ではなくコンテナー名を使用するよう設定されているためです。

podman logs コマンドを使用して、コンテナー化されたサービスのログを確認することもできます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを実行します。

$ sudo podman logs keystone

コンテナーへのアクセス

コンテナー化されたサービスのシェルに入るには、podman exec コマンドを使用して /bin/bash を起動します。たとえば、keystone コンテナーのシェルに入るには、以下のコマンドを実行します。

$ sudo podman exec -it keystone /bin/bash

root ユーザーとして keystone コンテナーのシェルに入るには、以下のコマンドを実行します。

$ sudo podman exec --user 0 -it <NAME OR ID> /bin/bash

コンテナーから出るには、以下のコマンドを実行します。

# exit

10.2. オーバークラウド環境の変更

オーバークラウドを変更して、別機能を追加したり、操作の方法を変更したりする場合があります。オーバークラウドを変更するには、カスタムの環境ファイルと Heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy コマンドをもう 1 度実行します。たとえば、「デプロイメントコマンド」に記載の手順を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e ~/templates/node-info.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  --ntp-server pool.ntp.org

director は Heat 内の overcloud スタックを確認してから、環境ファイルと Heat テンプレートのあるスタックで各アイテムを更新します。director はオーバークラウドを再度作成せずに、既存のオーバークラウドに変更を加えます。

新規環境ファイルを追加する場合には、-e オプションを使用して openstack overcloud deploy コマンドにそのファイルを追加します。以下に例を示します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e ~/templates/new-environment.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/network-environment.yaml \
  -e ~/templates/storage-environment.yaml \
  -e ~/templates/node-info.yaml \
  --ntp-server pool.ntp.org

このコマンドにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。

重要

オーバークラウドの設定に手動で変更を加えることは推奨されません。director によりこれらの変更が後で上書きされてしまう可能性があるためです。

10.3. オーバークラウドへの仮想マシンのインポート

この手順で、既存の OpenStack 環境からご自分の Red Hat OpenStack Platform 環境に仮想マシンを移行する方法について説明します。

手順

  1. 既存の OpenStack 環境において、実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。

    $ openstack server image create instance_name --name image_name
    $ openstack image save image_name --file exported_vm.qcow2
  2. エクスポートしたイメージをアンダークラウドノードにコピーします。

    $ scp exported_vm.qcow2 stack@192.168.0.2:~/.
  3. アンダークラウドに stack ユーザーとしてログインします。
  4. source コマンドで overcloudrc ファイルを読み込みます。

    $ source ~/overcloudrc
  5. エクスポートしたイメージをオーバークラウドにアップロードします。

    (overcloud) $ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
  6. 新規インスタンスを起動します。

    (overcloud) $ openstack server create  imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id
重要

これらのコマンドにより、各仮想マシンのディスクが既存の OpenStack 環境から新たな Red Hat OpenStack Platform にコピーされます。QCOW を使用したスナップショットでは、元の階層化システムが失われます。

このプロファイルにより、コンピュートノードからすべてのインスタンスが移行されます。インスタンスのダウンタイムなしにノードでメンテナンスを実行できるようになります。コンピュートノードを有効な状態に戻すには、以下のコマンドを実行します。

$ source ~/overcloudrc
(overcloud) $ openstack compute service set [hostname] nova-compute --enable

10.4. 動的インベントリースクリプトの実行

director を使用すると、Ansible ベースの自動化をご自分の OpenStack Platform 環境で実行することができます。director は、tripleo-ansible-inventory コマンドを使用して、環境内にノードの動的インベントリーを生成します。

手順

  1. ノードの動的インベントリーを表示するには、stackrc を読み込んだ後に tripleo-ansible-inventory コマンドを実行します。

    $ source ~/stackrc
    (undercloud) $ tripleo-ansible-inventory --list

    --list オプションを指定すると、全ホストの詳細が返されます。このコマンドにより、動的インベントリーが JSON 形式で出力されます。

    {"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.168.24.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.168.24.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.168.24.3"]}
  2. お使いの環境で Ansible のプレイブックを実行するには、ansible コマンドを実行し、-i オプションを使用して動的インベントリーツールの完全パスを追加します。以下に例を示します。

    (undercloud) $ ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
    • [HOSTS] を使用するホストの種別に置き換えてください。以下に例を示します。

      • 全コントローラーノードの場合には controller
      • 全コンピュートノードの場合には compute
      • controller および compute など、オーバークラウドの全子ノードの場合には overcloud
      • アンダークラウドの場合には undercloud
      • 全ノードの場合には "*"
    • [OTHER OPTIONS] を追加の Ansible オプションに置き換えてください。役立つオプションには以下が含まれます。

      • --ssh-extra-args='-o StrictHostKeyChecking=no' は、ホストキーのチェックを省略します。
      • -u [USER] は、Ansible の自動化を実行する SSH ユーザーを変更します。オーバークラウドのデフォルトの SSH ユーザーは、動的インベントリーの ansible_ssh_user パラメーターで自動的に定義されます。-u オプションは、このパラメーターより優先されます。
      • -m [MODULE] は、特定の Ansible モジュールを使用します。デフォルトは command で Linux コマンドを実行します。
      • -a [MODULE_ARGS] は選択したモジュールの引数を定義します。
重要

オーバークラウドのカスタム Ansible 自動化は、標準のオーバークラウドスタックの一部ではありません。この後に openstack overcloud deploy コマンドを実行すると、オーバークラウドノード上の OpenStack Platform サービスに対する Ansible ベースの設定を上書きする可能性があります。

10.5. オーバークラウドの削除

既存のオーバークラウドを削除します。

$ source ~/stackrc
(undercloud) $ openstack overcloud delete overcloud

オーバークラウドが削除されていることを確認します。

(undercloud) $ openstack stack list

削除には、数分かかります。

削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。

第11章 コンピュートノード間の仮想マシンの移行

特定の状況では、仮想マシンをオーバークラウド上のあるコンピュートノードから別のコンピュートノードに移行しなければならない場合があります。以下に例を示します。

  • コンピュートノードのメンテナンス: コンピュートノードを一時的に停止しなければならない場合には、コンピュートノード上で実行中の仮想マシンを別のコンピュートノードに一時的に移行することができます。一般的なシナリオとしては、ハードウェアのメンテナンス、ハードウェアの修理、カーネルのアップグレード、およびソフトウェアの更新などが挙げられます。
  • コンピュートノードの障害: コンピュートノードで障害の発生が予想され、保守または置き換えが必要な場合には、仮想マシンを障害のあるコンピュートノードから正常なコンピュートノードに移行する必要があります。すでに障害が発生しているコンピュートノードについては、『Instances and Images Guide』の「Evacuate Instances」を参照してください。
  • 負荷の再分散: 負荷を再度分散するために、1 つまたは複数の仮想マシンを別のコンピュートノードに移行することを検討できます。たとえば、コンピュートノード上の仮想マシンを 1 つにまとめて電力を節約する、ネットワーク上のリソースに物理的に近いコンピュートノードに仮想マシンを移行してレイテンシーを低減する、全コンピュートノードに仮想マシンを分散してホットスポットをなくし復元力を向上させる、等が可能です。

director は、すべての コンピュートノードがセキュアな移行を提供するように設定します。全コンピュートノードには、各ホストの nova ユーザーが移行プロセス中に他のコンピュートノードにアクセスすることができるようにするための共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、全 Compute ロールにデフォルトで含まれているメインのサービスの 1 つです (『オーバークラウドの高度なカスタマイズ』「コンポーザブルサービスとカスタムロール」を参照)。

11.1. 移行の種別

OpenStack Platform では、以下の 2 つの移行種別がサポートされます。

ライブマイグレーション

ライブマイグレーションでは、移行先ノードの仮想マシンを起動して移行元ノードの仮想マシンをシャットダウンする操作を、仮想マシンの動作状態を維持しながらシームレスに実施します。

ライブマイグレーション

ライブマイグレーションでは、ほぼゼロダウンタイムで仮想マシンの移行が行われます。状況によっては、仮想マシンがライブマイグレーションを使用 できない 場合があります。移行の制約に関する詳細は、「移行の制約」を参照してください。

コールドマイグレーション

コールドマイグレーション (あるいは、非ライブマイグレーション) では、移行元コンピュートノードから移行先コンピュートノードに仮想マシンを移行する前に、nova が仮想マシンをシャットダウンします。

コールドマイグレーション

コールドマイグレーションでは、仮想マシンに多少のダウンタイムが発生します。ただし、コールドマイグレーションにより移行した仮想マシンは、引き続き同じボリュームおよび IP アドレスにアクセスすることができます。

重要

移行元コンピュートノードですでに障害が発生している場合には、『Instances and Images Guide』の「Evacuate Instances」を参照してください。移行を行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。

11.2. 移行の制約

状況によっては、仮想マシンの移行に追加の制約が生じる場合があります。移行の制約や、通常ブロックマイグレーション、設定ディスク、またはいずれかの仮想マシンがコンピュートノード上の物理ハードウェアにアクセスする場合に生じます。

CPU に関する制約

移行元および移行先コンピュートノードの CPU アーキテクチャーは、同一であることが 必須です。たとえば、Red Hat では、x86_64 CPU から ppc64le CPU への仮想マシンの移行を サポートしません。CPU ホストパススルーを使用する仮想マシン等の場合には、移行元および移行先コンピュートノードの CPU は、完全に同一である 必要があります。すべてのケースで、移行先ノードの CPU 機能は、移行元ノードの CPU 機能の上位セットであることが 必須です。また、仮想マシンが CPU ピニングを使用する場合には、移行元ノードで使用される NUMA ノードは、移行先コンピュートノード上の同じ NUMA ノードをターゲットにし、さらに NUMA ノードは空でなければなりません。

メモリーに関する制約

移行先コンピュートノードは、利用可能な RAM を十分に持つことが 求められます。メモリーのオーバーサブスクリプションが、移行失敗の 原因となります。また、NUMA トポロジーを使用する仮想マシンは、移行先コンピュートノード上の同じ NUMA ノードに利用可能な RAM を十分に持つ必要があります。

ブロックマイグレーションに関する制約

仮想マシンの使用するディスクがコンピュートノード上にローカルに確保されている場合、その移行には、共有ストレージ (Red Hat Ceph Storage 等) を使用するボリュームベースの仮想マシンよりもはるかに長い時間がかかります。このレイテンシーは、nova がコンピュートノード間でローカルディスクをブロックごとに移行するために発生します。この処理は、デフォルトではコントロールプレーンネットワークを通じて行われます。これとは対照的に、Red Hat Ceph Storage 等の共有ストレージを使用するボリュームベースのインスタンスでは、ボリュームを移行する必要がありません。それぞれのコンピュートノードが、共有ストレージにアクセスできるためです。

注記

大量の RAM を消費するローカルディスクまたは仮想マシンの移行により、コントロールプレーンネットワークに輻輳が生じ、これによりコントロールプレーンネットワークを使用する他のシステム (RabbitMQ 等) のパフォーマンスに悪影響を及ぼす場合があります。

読み取り専用ドライブの移行に関する制約

ドライブの移行は、ドライブに読み取り および 書き込み両方の機能がある場合に 限り サポートされます。たとえば、nova は CD-ROM ドライブまたは読み取り専用のコンフィグドライブを移行することはできません。ただし、nova は、vfat 等のドライブ形式を持つコンフィグドライブなど、読み取りおよび書き込み 両方の 機能を持つドライブを移行することができます。

ライブマイグレーションに関する制約

Red Hat OpenStack Platform のライブマイグレーションには、さらにいくつかの制約があります。

  • 移行中は新規操作ができない: 移行元および移行先ノードの仮想マシンのコピー間で状態の整合性を確保するために、Red Hat OpenStack Platform ではライブマイグレーション時の新規操作を拒否する必要があります。拒否しないと、ライブマイグレーションでメモリーの状態を複製するより早くメモリーへの書き込みが行われた場合に、ライブマイグレーションに長い時間がかかる状況や、永久に完了しない状況が発生する可能性があります。
  • Non-Uniform Memory Access (NUMA): 以前のリリースでは、NUMA トポロジーが設定された仮想マシンを移行することは推奨されませんでした。現時点では、特定の条件を満たせば、nova は NUMA トポロジーが設定された仮想マシンを正常に移行することができます。
  • CPU ピニング: フレーバーが CPU ピニングを使用する場合には、フレーバーは暗黙的に NUMA トポロジーを仮想マシンに適用し、その CPU およびメモリーを特定ホストの CPU およびメモリーにマッピングします。単純な NUMA トポロジーとCPU ピニングの違いは、NUMA が CPU コアの 範囲 を使用するのに対して、CPU ピニングは特定の CPU コアを使用する点です。補足情報は、『Instances and Images Guide』の「Configure CPU Pinning with NUMA」を参照してください。
  • Data Plane Development Kit (DPDK): 仮想マシンが DPDK を使用する場合には (たとえば、Open vSwitch と dpdk-netdev の組み合わせを実行する仮想マシン)、仮想マシンはヒュージページも使用し、nova が仮想マシンをNUMA ノードに固定するように NUMA トポロジーが適用されます。

nova は、NUMA、CPU ピニング、または DPDK を使用する仮想マシンのライブマイグレーションを行うことができます。ただし、移行先コンピュートノードは、仮想マシンが移行元コンピュートノードで使用するのと 同じ NUMA ノード上に 十分な空き容量を持つことが 必須です。たとえば、仮想マシンが overcloud-compute-0NUMA 0 を使用している場合に、ライブマイグレーションにより仮想マシンを overcloud-compute-1 に移行するには、overcloud-compute-1NUMA 0 に仮想マシンをサポートするのに十分な空き容量が必要です。

ライブマイグレーションの妨げとなる制約

Red Hat OpenStack Platform では、仮想マシンの設定によってライブマイグレーションが妨げられる場合があります。

  • Single-root Input/Output Virtualization (SR-IOV): 仮想マシンに SR-IOV Virtual Function (VF) を割り当てることができます。ただし、これがライブマイグレーションの妨げとなります。通常のネットワークデバイスとは異なり、SR-IOV VF ネットワークデバイスには永続的な一意の MAC アドレスがありません。コンピュートノードがリブートするたびに、または nova-scheduler が仮想マシンを新たなコンピュートノードに移行すると、VF ネットワークデバイスは新たな MAC アドレスを取得します。したがって、OpenStack Platform 15 では、nova は SR-IOV を使用する仮想マシンのライブマイグレーションを行うことができません。SR-IOV を使用する仮想マシンの場合には、コールドマイグレーションを行う必要があります。
  • PCI パススルー: QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスを仮想マシンにアタッチすることができます。PCI パススルーを使用すると、仮想マシンは PCI デバイスに排他的にアクセスすることができ、これらのデバイスが仮想マシンのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理アドレスが必要なため、OpenStack Platform 15 では、nova は PCI パススルーを使用する仮想マシンのライブマイグレーションをサポートしません。

11.3. 移行前の操作

1 つまたは複数の仮想マシンを移行する前に、以下の手順を実施します。

手順

  1. アンダークラウドから、移行元コンピュートノードのホスト名および移行先コンピュートノードのホスト名を特定します。

    $ source ~/overcloudrc
    $ openstack compute service list
  2. 移行元コンピュートノード上の仮想マシンを一覧表示し、移行する仮想マシンの ID を探します。

    $ openstack server list --host [source] --all-projects

    [source] を移行元コンピュートノードのホスト名に置き換えてください。

コンピュートノードをメンテナンスするための移行前の操作

メンテナンスのために移行元となるコンピュートノードを停止する場合には、メンテナンス中にスケジューラーが新しい仮想マシンを割り当てないように、アンダークラウドからそのコンピュートノードを無効にします。

$ openstack compute service set [source] nova-compute --disable

[source] を移行元コンピュートノードのホスト名に置き換えてください。

NUMA、CPU ピニング、および DPDK を使用するインスタンス向けの移行前の操作

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行する場合には、移行先コンピュートノードには移行元コンピュートノードと同じハードウェア仕様および設定が必要です。また、移行元コンピュートノードの NUMA トポロジーが維持されるように、移行先コンピュートノードには実行中の仮想マシンがあってはいけません。

注記

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行する場合には、/etc/nova/nova.conf ファイルの scheduler_default_filters 構成設定には、AggregateInstanceExtraSpecsFilter および NUMATopologyFilter 等の適切な値を設定する必要があります。そのためには、環境ファイルの NovaSchedulerDefaultFilters heat パラメーターを設定します。

  1. NUMA、CPU ピニング、または DPDK を使用する仮想マシンの移行先コンピュートノードが無効にされて いない 場合には、これを無効にしてスケジューラーがノードに仮想マシンを割り当てるのを防ぎます。

    $ openstack compute service set [dest] nova-compute --disable

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  2. DPDK または NUMA を使用する仮想マシンを複数移行する際の、移行元コンピュートノードから移行済みの仮想マシンを除き、移行先コンピュートノードには仮想マシンがあってはいけません。

    $ openstack server list --host [dest] --all-projects

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  3. 移行先コンピュートノードには、NUMA、CPU ピニング、または DPDK を使用する仮想マシンを実行するのに十分なリソースを確保してください。

    $ openstack host show overcloud-compute-n
    $ ssh overcloud-compute-n
    $ numactl --hardware
    $ exit

    overcloud-compute-n を移行先コンピュートノードのホスト名に置き換えてください。

  4. 移行元または移行先コンピュートノードの NUMA 情報を把握するには、必要に応じて以下のコマンドを実行します。

    $ ssh root@overcloud-compute-n
    # lscpu && lscpu | grep NUMA
    # virsh nodeinfo
    # virsh capabilities
    # exit

    ssh を使用して overcloud-compute-n に接続します。ここで、overcloud-compute-n は移行元または移行先コンピュートノードです。

  5. 仮想マシンが NUMA を使用しているかどうか不明な場合には、仮想マシンのフレーバーを確認します。

    $ openstack server list -c Name -c Flavor --name [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

    続いてフレーバーを確認します。

    $ openstack flavor show [flavor]

    [flavor] をフレーバーの名前または ID に置き換えてください。properties フィールドの結果に hw:mem_page_size が含まれ、その値が any 以外であれば (例: 2MB2048、または 1GB)、仮想マシンには NUMA トポロジーが設定されています。properties フィールドに aggregate_instance_extra_specs:pinned='true' が含まれる場合には、仮想マシンは CPU ピニングを使用しています。properties フィールドに hw:numa_nodes が含まれる場合には、nova は仮想マシンを特定の NUMA ノードに制限します。

  6. 移行完了後に、移行先コンピュートノードの NUMA トポロジーが移行元コンピュートノードの NUMA トポロジーを反映していることを確認できるように、NUMA を使用するそれぞれの仮想マシンについて、ベースのコンピュートノードから NUMA トポロジーに関する情報を取得することを検討してください。

    $ ssh root@overcloud-compute-n
    # virsh vcpuinfo [vm]
    # virsh numatune [vm]
    # exit

    [vm] を仮想マシンの名前に置き換えてください。vcpuinfo コマンドにより、NUMA および CPU ピニングに関する詳細が得られます。numatune コマンドにより、仮想マシンが使用している NUMA ノードが表示されます。

11.4. 仮想マシンのライブマイグレーション

ライブマイグレーションでは、ダウンタイムを最小限に抑えて、仮想マシンを移行元コンピュートノードから移行先コンピュートノードに移動します。ただし、ライブマイグレーションがすべての仮想マシンに適しているとは限りません。補足情報は、「移行の制約」を参照してください。

手順

  1. 仮想マシンのライブマイグレーションを行うには、仮想マシンおよび移行先コンピュートノードを指定します。

    $ openstack server migrate [vm] --live [dest] --wait

    [vm] を仮想マシンの名前または ID に置き換えてください。[dest] を移行先コンピュートノードのホスト名に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。

  2. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  3. 正常に移行したことを確認します。

    $ openstack server list --host [dest] --all-projects

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  4. NUMA、CPU ピニング、または DPDK を使用する仮想マシンについて、移行準備のプロセス中に取得した NUMA トポロジーと比較するために、コンピュートノードからの NUMA トポロジーについての情報を取得することを考慮してください。

    $ ssh root@overcloud-compute-n
    # virsh vcpuinfo [vm]
    # virsh numatune [vm]
    # exit

    overcloud-compute- をコンピュートノードのホスト名に置き換えてください。[vm] を仮想マシンの名前に置き換えてください。移行元と移行先コンピュートノードの NUMA トポロジーを比較することは、移行元と移行先コンピュートノードが同じ NUMA トポロジーを使用していることを確認するのに役立ちます。

  5. 移行するその他の仮想マシンごとに、この手順を繰り返します。

仮想マシンの移行が終了したら、「移行後の操作」に進んでください。

11.5. 仮想マシンのコールドマイグレーション

仮想マシンのコールドマイグレーションでは、仮想マシンを停止して、別のコンピュートノードに移動します。コールドマイグレーションは、PCI パススルーまたは Single-Root Input/Output Virtualization (SR-IOV) を使用する仮想マシンの移行など、ライブマイグレーションでは対応することのできない移行シナリオに対応します。移行先コンピュートノードは、スケジューラーにより自動的に選択されます。補足情報は、「移行の制約」を参照してください。

手順

  1. 仮想マシンを移行するには、仮想マシンを指定します。

    $ openstack server migrate [vm] --wait

    [vm] を仮想マシンの ID に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。

  2. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  3. 移行が正常に完了したことを確認します。

    $ openstack server list --all-projects

仮想マシンの移行が終了したら、「移行後の操作」に進んでください。

11.6. 移行ステータスの確認

移行が完了するまでに、さまざまな移行状態を遷移します。正常な移行では、通常、移行状態は以下のように遷移します。

  1. Queued: nova は仮想マシン移行の要求を受け入れ、移行は保留中です。
  2. Preparing: nova は仮想マシン移行の準備中です。
  3. Running: nova は仮想マシンの移行プロセスを実行中です。
  4. Post-migrating: nova は仮想マシンを移行先コンピュートノードにビルドし、移行元コンピュートノードのリソースを解放しています。
  5. Completed: nova は仮想マシンの移行を完了し、移行元コンピュートノードのリソース解放を終了しています。

手順

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. 移行のステータスを表示します。

    $ nova server-migration-show [vm] [migration]

    [vm] を仮想マシンの名前または ID に置き換えてください。[migration] を移行の ID に置き換えてください。

仮想マシンの移行に長い時間がかったり、エラーが発生したりする場合があります。詳しくは、「移行に関するトラブルシューティング」を参照してください。

11.7. 移行後の操作

1 つまたは複数の仮想マシンを移行したら以下の手順を確認し、必要に応じてそれらの手順を実施します。

コンピュートノードのメンテナンスに関する移行後の操作

メンテナンスのために移行元コンピュートノードを停止し、メンテナンスが完了したら、スケジューラーが新しい仮想マシンを移行元コンピュートノードに割り当てられるように、アンダークラウドから移行元コンピュートノードを再度有効にすることができます。

$ source ~/overcloudrc
$ openstack compute service set [source] nova-compute --enable

[source] を移行元コンピュートノードのホスト名に置き換えてください。

NUMA、CPU ピニング、または DPDK を使用するインスタンス向けの移行後の操作

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行した後に、アンダークラウドから移行先コンピュートノードを再度有効にすることができます。

$ source ~/overcloudrc
$ openstack compute service set [dest] nova-compute --enable

[dest] を移行先コンピュートノードのホスト名に置き換えてください。

11.8. 移行に関するトラブルシューティング

仮想マシンの移行時には、さまざまな問題が発生する可能性があります。

  1. 移行プロセスでエラーが生じる。
  2. 移行プロセスが終了しない。
  3. 移行後に仮想マシンのパフォーマンスが低下する。

移行中のエラー

以下の問題が発生すると、移行操作が error 状態に遷移します。

  1. 異なるバージョンの OpenStack が存在するクラスターを実行する。
  2. 指定した仮想マシン ID が見つからない。
  3. 移行を試みている仮想マシンが error 状態にある。
  4. Compute サービスが停止している。
  5. 競合状態が発生している。
  6. ライブマイグレーションが failed 状態に移行する。

ライブマイグレーションが failed 状態に移行すると、通常は error 状態になります。failed 状態の原因となる可能性のある典型的な問題を、以下に示します。

  1. 移行先コンピュートホストが利用可能な状態にない。
  2. スケジューラーの例外が発生する。
  3. コンピューティングリソースが不十分なため、再ビルドプロセスに失敗する。
  4. サーバーグループの確認に失敗する。
  5. 移行先コンピュートノードへの移行が完了する前に、移行元コンピュートノードの仮想マシンが削除される。

ライブマイグレーションのスタック

ライブマイグレーションが時間どおりに完了せず、永久に runnin 状態のままになる可能性があります。ライブマイグレーションが永久に完了しない一般的な理由は、nova が仮想マシンの変更を移行先コンピュートノードに複製するより早く、クライアントのリクエストにより移行元コンピュートノード上で実行中の仮想マシンに変更が生じることです。

この状況に対処する方法はいくつかあります。

  1. ライブマイグレーションを中止する。
  2. ライブマイグレーションを強制的に完了させる。

ライブマイグレーションの中止

移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断したくない場合には、ライブマイグレーションの手順を中止することができます。

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. ライブマイグレーションを中止します。

    $ nova live-migration-abort [vm] [migration]

    [vm] を仮想マシンの名前または ID に、[migration] を移行の ID に、それぞれ置き換えてください。

ライブマイグレーション完了の強制

移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断して移行を強制的に完了させたい場合には、ライブマイグレーションの手順を強制的に完了させることができます。

重要

ライブマイグレーションを強制的に完了させると、かなりのダウンタイムが発生する可能性があります。

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. ライブマイグレーションを強制的に完了させます。

    $ nova live-migration-force-complete [vm] [migration]

    [vm] を仮想マシンの名前または ID に置き換えてください。[migration] を移行の ID に置き換えてください。

移行後の仮想マシンのパフォーマンス低下

NUMA トポロジーを使用する仮想マシンの場合には、移行元および移行先コンピュートノードの NUMA トポロジーおよび構成は、同じでなければなりません。移行先コンピュートノードの NUMA トポロジーには、利用可能なリソースが十分になければなりません。移行元と移行先コンピュートノード間で NUMA の構成が同一ではない場合、ライブマイグレーションは正常に完了するものの、仮想マシンのパフォーマンスが低下する可能性があります。たとえば、移行元コンピュートノードでは NIC 1 が NUMA ノード 0 にマッピングされるが、移行先コンピュートノードでは NIC 1 が NUMA ノード 5 にマッピングされると、移行後にはネットワークトラフィックを NIC 1 にルーティングするのに、仮想マシンはトラフィックを第 1 の CPU から NUMA ノード 5 の第 2 の CPU にルーティングします。その結果、想定どおりに動作はしますがパフォーマンスは低下します。同様に、移行元コンピュートノード上の NUMA ノード 0 には利用可能な CPU および RAM が十分にあるが、移行先コンピュートノード上の NUMA ノード 0 にはすでに仮想マシンが存在しリソースの一部が使用されている場合には、仮想マシンは適切に動作しますが、パフォーマンスが低下する可能性があります。詳細な情報は、「移行の制約」を参照してください。

第12章 Ansible を使用したオーバークラウドの設定

Ansible は、オーバークラウドの設定を適用する主要な方法です。本章では、オーバークラウドの Ansible 設定を操作する手順を説明します。

director は Ansible Playbook を自動生成しますが、Ansible の構文を十分に理解しておくと役立ちます。Ansible の使用方法については、Ansible のドキュメント を参照してください。

注記

Ansible では、roles の概念も使用します。これは、OpenStack Platform director のロールとは異なります。

12.1. Ansible ベースのオーバークラウド設定 (config-download)

config-download の機能により、director はオーバークラウドを設定します。director は、OpenStack Orchestration サービス (heat) および OpenStack Workflow サービス (mistral) と共に config-download を使用してソフトウェア設定を生成し、その設定を各オーバークラウドノードに適用します。Heat は SoftwareDeployment リソースから全デプロイメントデータを作成して、オーバークラウドのインストールと設定を行いますが、設定の適用は一切行いません。Heat は、Heat API から設定データの提供のみを行います。director がスタックを作成する場合には、Mistral ワークフローが Heat API に対して設定データ取得のクエリーを実行し、Ansible Playbook のセットを生成してオーバークラウドに適用します。

結果として、openstack overcloud deploy コマンドを実行すると、以下のプロセスが実行されます。

  • director は openstack-tripleo-heat-templates を元に新たなデプロイメントプランを作成し、プランをカスタマイズするための環境ファイルおよびパラメーターをすべて追加します。
  • director は Heat を使用してデプロイメントプランを翻訳し、オーバークラウドスタックとすべての子リソースを作成します。これには、OpenStack Bare Metal (ironic) を使用したノードのプロビジョニングも含まれます。
  • Heat はデプロイメントプランからソフトウェア設定も作成します。director はこのソフトウェア設定から Ansible Playbook をコンパイルします。
  • director は、特に Ansible SSH アクセス用としてオーバークラウドノードに一時ユーザー (tripleo-admin1) を生成します。
  • director は Heat ソフトウェア設定をダウンロードし、Heat の出力を使用して Ansible Playbook のセットを生成します。
  • director は、ansible-playbook を使用してオーバークラウドノードに Ansible Playbook を適用します。

12.2. config-download の作業ディレクトリー

director により、config-download プロセス用に Ansible Playbook のセットが生成されます。これらの Playbook は /var/lib/mistral/ 内の作業ディレクトリーに保管されます。このディレクトリーには、オーバークラウドの名前が付けられます。したがって、デフォルトでは overcloud です。

作業ディレクトリーには、各オーバークラウドロールの名前が付けられた複数のサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのノードの設定に関連するすべてのタスクが含まれます。さらに、これらのサブディレクトリーには、特定のノードの名前が付けられたサブディレクトリーが存在します。これらのサブディレクトリーには、オーバークラウドロールのタスクに適用するノード固有の変数が含まれます。したがって、作業ディレクトリー内のオーバークラウドロールは、以下のような構成になります。

─ /var/lib/mistral/overcloud
  │
  ├── Controller
  │  ├── overcloud-controller-0
  │  ├── overcloud-controller-1
  │  └── overcloud-controller-2
  ├── Compute
  │  ├── overcloud-compute-0
  │  ├── overcloud-compute-1
  │  └── overcloud-compute-2
  ...

それぞれの作業ディレクトリーは、各デプロイメント操作後の変更を記録するローカルの Git リポジトリーです。このことは、各デプロイメント間の設定変更を追跡するのに役立ちます。

12.3. config-download の作業ディレクトリーへのアクセスの有効化

/var/lib/mistral/ にある作業ディレクトリー内の全ファイルの所有者は、OpenStack Workflow サービス (mistral) コンテナーの mistral ユーザーです。アンダークラウドの stack ユーザーに、このディレクトリー内の全ファイルへのアクセス権限を付与することができます。この設定は、ディレクトリー内の特定操作を実施するのに役立ちます。

手順

  1. アンダークラウドの stack ユーザーに /var/lib/mistral ディレクトリーのファイルへのアクセス権限を付与するには、setfacl コマンドを使用します。

    $ sudo setfacl -R -m u:stack:rwx /var/lib/mistral

    このコマンドを実行しても、mistral ユーザーのディレクトリーへのアクセス権限は維持されます。

12.4. config-download ログの確認

config-download プロセス中、Ansible によりアンダークラウド内の config-download の作業ディレクトリーにログファイルが作成されます。

手順

  1. less コマンドを使用して、config-download の作業ディレクトリー内のログを表示します。以下の例では、overcloud 作業ディレクトリーが使われています。

    $ less /var/lib/mistral/overcloud/ansible.log

12.5. 手動での config-download の実行

/var/lib/mistral/overcloud 内の作業ディレクトリーには、ansible-playbook と直接対話するために必要な Playbook とスクリプトが含まれています。以下の手順では、これらのファイルとの対話方法について説明します。

手順

  1. Ansible Playbook のディレクトリーに移動します。

    $ cd /var/lib/mistral/overcloud/
  2. ansible-playbook-command.sh コマンドを実行して、デプロイメントを再現します。

    $ ./ansible-playbook-command.sh

    このスクリプトには追加の Ansible 引数を渡すことができ、それらの引数は、そのまま ansible-playbook コマンドに渡されます。これにより、チェックモード (--check)、ホストの限定 (--limit)、変数のオーバーライド (-e) など、Ansible の機能を更に活用することが可能となります。以下に例を示します。

    $ ./ansible-playbook-command.sh --limit Controller
  3. 作業ディレクトリーには、オーバークラウドの設定を実行する deploy_steps_playbook.yaml という名前の Playbook が含まれています。この Playbook を表示するには、以下のコマンドを実行します。

    $ less deploy_steps_playbook.yaml

    Playbook は、作業ディレクトリーに含まれているさまざまなタスクファイルを使用します。タスクファイルには、OpenStack Platform の全ロールに共通するものと、特定の OpenStack Platform ロールおよびサーバー固有のものがあります。

  4. 作業ディレクトリーには、オーバークラウドの roles_data ファイルで定義されている各ロールに対応するサブディレクトリーも含まれます。以下に例を示します。

    $ ls Controller/

    各 OpenStack Platform ロールにディレクトリーには、そのロール種別の個々のサーバー用のサブディレクトリーも含まれます。これらのディレクトリーには、コンポーザブルロールのホスト名の形式を使用します。以下に例を示します。

    $ ls Controller/overcloud-controller-0
  5. Ansible のタスクはタグ付けられます。タグの全一覧を確認するには、ansible-playbook で CLI の引数 --list-tags を使用します。

    $ ansible-playbook -i tripleo-ansible-inventory.yaml --list-tags deploy_steps_playbook.yaml

    次に、ansible-playbook-command.sh スクリプトで --tags--skip-tags--start-at-task のいずれかを使用して、タグ付けした設定を適用します。以下に例を示します。

    $ ./ansible-playbook-command.sh --tags overcloud
  6. config-download を使用して Ceph を設定する際に、Ansible は config-download external_deploy_steps_tasks Playbook 内から ceph-ansible を実行します。config-download を手動で実行する場合、2 回目の Ansible の実行では ssh_args 引数は継承されません。この実行に Ansible 環境変数を渡すには、heat 環境ファイルを使用します。以下に例を示します。

    parameter_defaults:
      CephAnsibleEnvironmentVariables:
        ANSIBLE_HOST_KEY_CHECKING: 'False'
        ANSIBLE_PRIVATE_KEY_FILE: '/home/stack/.ssh/id_rsa'
警告

--tags--skip-tags--start-at-task などの ansible-playbook CLI 引数を使用する場合には、デプロイメントの設定は、間違った順序で実行したり適用したりしないでください。これらの CLI 引数は、以前に失敗したタスクを再度実行する場合や、初回のデプロイメントを繰り返す場合に便利な方法です。ただし、デプロイメントの一貫性を保証するには、deploy_steps_playbook.yaml の全タスクを順番どおりに実行する必要があります。

12.6. 作業ディレクトリーでの Git 操作の実施

config-download の作業ディレクトリーは、ローカルの Git リポジトリーです。デプロイメント操作を実行するたびに、director は該当する変更に関する Git コミットを作業ディレクトリーに追加します。Git 操作を実施して、さまざまなステージでのデプロイメント設定を表示したり、異なるデプロイメント間で設定を比較したりすることができます。

作業ディレクトリーには制限がある点に注意してください。たとえば、Git を使用して config-download の作業ディレクトリーを前のバージョンに戻しても、作業ディレクトリー内の設定が影響を受けるだけです。したがって、以下の設定には影響を及ぼしません。

  • オーバークラウドデータスキーマ: 作業ディレクトリーのソフトウェア設定の前のバージョンを適用しても、データ移行およびスキーマ変更は取り消されません。
  • オーバークラウドのハードウェアレイアウト: 以前のソフトウェア設定に戻しても、スケールアップ/ダウン等のオーバークラウドハードウェアに関する変更は取り消されません。
  • Heat スタック: 作業ディレクトリーを前のバージョンに戻しても、Heat スタックに保管された設定は影響を受けません。Heat スタックは新たなバージョンのソフトウェア設定を作成し、それがオーバークラウドに適用されます。オーバークラウドに永続的な変更を加えるには、openstack overcloud deploy を再度実行する前に、オーバークラウドスタックに適用する環境ファイルを変更します。

config-download の作業ディレクトリー内の異なるコミットを比較するには、以下の手順を実施します。

手順

  1. オーバークラウドに関する config-download の作業ディレクトリーに移動します。この例の作業ディレクトリーは、overcloud という名前のオーバークラウド用です。

    $ cd /var/lib/mistral/overcloud
  2. git log コマンドを実行して、作業ディレクトリー内のコミットの一覧を表示します。ログの出力に日付が表示されるようにフォーマットを設定することもできます。

    $ git log --format=format:"%h%x09%cd%x09"
    a7e9063 Mon Oct 8 21:17:52 2018 +1000
    dfb9d12 Fri Oct 5 20:23:44 2018 +1000
    d0a910b Wed Oct 3 19:30:16 2018 +1000
    ...

    デフォルトでは、最新のコミットから順に表示されます。

  3. 2 つのコミットのハッシュに対して git diff コマンドを実行し、デプロイメント間の違いをすべて表示します。

    $ git diff a7e9063 dfb9d12

12.7. 手動での config-download ファイルの作成

特定の状況では、標準のワークフローとは別に専用の config-download ファイルを生成する場合があります。たとえば、個別に設定を適用できるように、openstack overcloud deploy コマンドに --stack-only オプションを設定して、オーバークラウド Heat スタックを生成することができます。専用の config-download ファイルを手動で作成するには、以下の手順を実施します。

手順

  1. config-download ファイルを生成します。

    $ openstack overcloud config download \
      --name overcloud \
      --config-dir ~/config-download
    • --name は、Ansible ファイルのエクスポートに使用するオーバークラウドです。
    • --config-dir は、config-download ファイルを保存する場所です。
  2. config-download ファイルが含まれるディレクトリーに移動します。

    $ cd ~/config-download
  3. 静的なインベントリーファイルを生成します。

    $ tripleo-ansible-inventory \
      --ansible_ssh_user heat-admin \
      --static-yaml-inventory inventory.yaml

config-download ファイルおよび静的なインベントリーファイルを使用して、設定を実施します。デプロイメント用の Playbook を実行するには、ansible-playbook コマンドを実行します。

$ ansible-playbook \
  -i inventory.yaml \
  --private-key ~/.ssh/id_rsa \
  --become \
  ~/config-download/deploy_steps_playbook.yaml

この設定から手動で overcloudrc ファイルを生成するには、以下のコマンドを実行します。

$ openstack action execution run \
  --save-result \
  --run-sync \
  tripleo.deployment.overcloudrc \
  '{"container":"overcloud"}' \
  | jq -r '.["result"]["overcloudrc.v3"]' > overcloudrc.v3

12.8. config-download の主要ファイル

config-download の作業ディレクトリー内の主要なファイルを以下に示します。

Ansible の設定および実行

config-download の作業ディレクトリー内の以下のファイルは、Ansible を設定/実行するための専用ファイルです。

ansible.cfg
ansible-playbook 実行時に使用する設定ファイル。
ansible.log
最後に実行した ansible-playbook に関するログファイル。
ansible-errors.json
デプロイメントエラーが含まれる JSON 構造のファイル。
ansible-playbook-command.sh
最後のデプロイメント操作の ansible-playbook コマンドを再実行するための実行可能スクリプト。
ssh_private_key
Ansible がオーバークラウドノードにアクセスする際に使用する SSH 秘密鍵。
tripleo-ansible-inventory.yaml
すべてのオーバークラウドノードのホストおよび変数が含まれる Ansible インベントリーファイル。
overcloud-config.tar.gz
作業ディレクトリーのアーカイブ。

Playbook

以下のファイルは、config-download の作業ディレクトリー内の Playbook です。

deploy_steps_playbook.yaml
デプロイメントのメインステップ。この Playbook により、オーバークラウド設定の主要な操作が実施されます。
pre_upgrade_rolling_steps_playbook.yaml
メジャーアップグレードのための事前アップグレードステップ。
upgrade_steps_playbook.yaml
メジャーアップグレードのステップ。
post_upgrade_steps_playbook.yaml
メジャーアップグレードに関するアップグレード後ステップ。
update_steps_playbook.yaml
マイナーアップデートのステップ。
fast_forward_upgrade_playbook.yaml
Fast Forward Upgrade のタスク。OpenStack Platform のロングライフバージョンから次のロングライフバージョンにアップグレードする場合にのみ、この Playbook 使用します。この Playbook を OpenStack Platform の本リリースに使用しないでください。

12.9. config-download のタグ

Playbook では、オーバークラウドに適用されるタスクを管理するのにタグ付けされたタスクを使用します。ansible-playbook CLI の引数 --tags または --skip-tags でタグを使用して、実行するタスクを管理します。デフォルトで有効なタグに関する情報を、以下の一覧に示します。

facts
ファクト収集操作。
common_roles
すべてのノードに共通な Ansible ロール。
overcloud
オーバークラウドデプロイメント用のすべてのプレイ。
pre_deploy_steps
deploy_steps の操作の前に実施されるデプロイメント。
host_prep_steps
ホスト準備のステップ。
deploy_steps
デプロイメントのステップ。
post_deploy_steps
deploy_steps の操作の後に実施される手順。
external
すべての外部デプロイメントタスク。
external_deploy_steps
アンダークラウドでのみ実行される外部デプロイメントタスク。

12.10. config-download のデプロイメントステップ

オーバークラウドの設定には、deploy_steps_playbook.yaml Playbook が使用されます。この Playbook により、オーバークラウドデプロイメントプランに基づき完全なオーバークラウドをデプロイするのに必要なすべてのソフトウェア設定が適用されます。

本項では、この Playbook で使用されるさまざまな Ansible プレイの概要について説明します。本項のプレイと同じ名前が、Playbook 内で使用され ansible-playbook の出力にも表示されます。本項では、それぞれのプレイに設定される Ansible タグについても説明します。

Gather facts from undercloud

アンダークラウドノードからファクトを収集します。

タグ: facts

Gather facts from overcloud

オーバークラウドノードからファクトを収集します。

タグ: facts

Load global variables

global_vars.yaml からすべての変数を読み込みます。

タグ: always

Common roles for TripleO servers

共通の Ansible ロールをすべてのオーバークラウドノードに適用します。これには、ブートストラップパッケージをインストールする tripleo-bootstrap および ssh の既知のホストを設定する tripleo-ssh-known-hosts が含まれます。

タグ: common_roles

Overcloud deploy step tasks for step 0

deploy_steps_tasks テンプレートインターフェースからのタスクを適用します。

タグ: overclouddeploy_steps

Server deployments

ネットワーク設定や hieradata 等の設定に、サーバー固有の Heat デプロイメントを適用します。これには、NetworkDeployment、<Role>Deployment、<Role>AllNodesDeployment 等が含まれます。

タグ: overcloudpre_deploy_steps

Host prep steps

host_prep_steps テンプレートインターフェースからのタスクを適用します。

タグ: overcloudhost_prep_steps

External deployment step [1,2,3,4,5]

external_deploy_steps_tasks テンプレートインターフェースからのタスクを適用します。Ansible は、アンダークラウドノードに対してのみこれらのタスクを実行します。

タグ: externalexternal_deploy_steps

Overcloud deploy step tasks for [1,2,3,4,5]

deploy_steps_tasks テンプレートインターフェースからのタスクを適用します。

タグ: overclouddeploy_steps

Overcloud common deploy step tasks [1,2,3,4,5]

各ステップで実施される共通タスクを適用します。これには、puppet ホストの設定、container-puppet.py、および paunch (コンテナー設定) が含まれます。

タグ: overclouddeploy_steps

Server Post Deployments

5 ステップのデプロイメントプロセス後に実施される設定に、サーバー固有の Heat デプロイメントを適用します。

タグ: overcloudpost_deploy_steps

External deployment Post Deploy tasks

external_post_deploy_steps_tasks テンプレートインターフェースからのタスクを適用します。Ansible は、アンダークラウドノードに対してのみこれらのタスクを実行します。

タグ: externalexternal_deploy_steps

12.11. 次のステップ

これで、通常のオーバークラウドの操作を続行できるようになりました。

第13章 オーバークラウドノードのスケーリング

警告

オーバークラウドからノードを削除する場合は、openstack server delete を使用しないでください。本項で説明する手順をよく読み、適切にノードの削除/置き換えを行ってください。

オーバークラウドの作成後に、ノードを追加または削除する必要がある場合があります。たとえば、オーバークラウドのコンピュートノードを追加する場合などです。このような状況では、オーバークラウドの更新が必要です。

以下の表を使用して、各ノード種別のスケーリングに対するサポートを判断してください。

表13.1 各ノード種別のスケーリングサポート

ノード種別

スケールアップ

スケールダウン

説明

コントローラー

非対応

非対応

14章コントローラーノードの置き換え」に記載の手順を使用して、コントローラーノードを置き換えることができます。

コンピュート

対応

対応

 

Ceph Storage ノード

対応

非対応

オーバークラウドを最初に作成する際に Ceph Storage ノードを 1 つ以上設定する必要があります。

オブジェクトストレージノード

対応

対応

 
重要

オーバークラウドをスケーリングする前には、空き領域が少なくとも 10 GB あることを確認してください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。

13.1. オーバークラウドへのノード追加

director のノードプールにさらにノードを追加するには、以下の手順を実施します。

手順

  1. 登録する新規ノードの詳細を記載した新しい JSON ファイル (newnodes.json) を作成します。

    {
      "nodes":[
        {
            "mac":[
                "dd:dd:dd:dd:dd:dd"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"ipmi",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.207"
        },
        {
            "mac":[
                "ee:ee:ee:ee:ee:ee"
            ],
            "cpu":"4",
            "memory":"6144",
            "disk":"40",
            "arch":"x86_64",
            "pm_type":"ipmi",
            "pm_user":"admin",
            "pm_password":"p@55w0rd!",
            "pm_addr":"192.168.24.208"
        }
      ]
    }
  2. 以下のコマンドを実行して、新規ノードを登録します。

    $ source ~/stackrc
    (undercloud) $ openstack overcloud node import newnodes.json
  3. 新規ノードを追加したら、各新規ノードごとに以下のコマンドを実行してイントロスペクションプロセスを起動します。

    (undercloud) $ openstack baremetal node manage [NODE UUID]
    (undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

    このプロセスにより、ノードのハードウェアプロパティーの検出とベンチマークが実行されます。

  4. ノードのイメージプロパティーを設定します。

    (undercloud) $ openstack overcloud node configure [NODE UUID]

13.2. ロールのノード数の追加

特定ロールのオーバークラウドノード (たとえばコンピュートノード) をスケーリングするには、以下の手順を実施します。

手順

  1. それぞれの新規ノードを希望するロールにタグ付けします。たとえば、ノードをコンピュートロールにタグ付けするには、以下のコマンドを実行します。

    (undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]
  2. オーバークラウドをスケーリングするには、ノード数が含まれる環境ファイルを編集してオーバークラウドを再デプロイする必要があります。たとえば、オーバークラウドをコンピュートノード 5 台にスケーリングするには、ComputeCount パラメーターを編集します。

    parameter_defaults:
      ...
      ComputeCount: 5
      ...
  3. 更新したファイルを使用して、デプロイメントのコマンドを再度実行します。このファイルは、以下の例では、node-info.yaml という名前です。

    (undercloud) $ openstack overcloud deploy --templates -e /home/stack/templates/node-info.yaml [OTHER_OPTIONS]

    最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。

  4. デプロイメント操作が完了するまで待ちます。

13.3. コンピュートノードの削除

オーバークラウドからコンピュートノードを削除する必要がある状況が出てくる可能性があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。

重要

オーバークラウドからコンピュートノードを削除する前に、インスタンスをそのノードから別のコンピュートノードに移行してください。詳しくは、「11章コンピュートノード間の仮想マシンの移行」を参照してください。

手順

  1. source コマンドでオーバークラウド設定を読み込みます。

    $ source ~/stack/overcloudrc
  2. オーバークラウド上で削除するノードの Compute サービスを無効にし、ノードで新規インスタンスがスケジューリングされないようにします。

    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service set [hostname] nova-compute --disable
    ヒント

    --disable-reason オプションを使用して、サービスを無効にする理由を簡単に説明します。これは、Compute サービスを後で再デプロイする場合に役立ちます。

  3. source コマンドでアンダークラウド設定を読み込みます。

    (overcloud) $ source ~/stack/stackrc
  4. オーバークラウドノードを削除するには、ローカルのテンプレートファイルを使用して director のオーバークラウドスタックを更新する必要があります。まず、オーバークラウドスタックの UUID を特定します。

    (undercloud) $ openstack stack list
  5. 削除するノードの UUID を特定します。

    (undercloud) $ openstack server list
  6. 以下のコマンドを実行してスタックからノードを削除し、それに応じてプランを更新します。

    (undercloud) $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
    重要

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

  7. 操作を続行する前に、openstack overcloud node delete コマンドが完全に終了したことを確認します。openstack stack list コマンドを使用して、overcloud スタックが UPDATE_COMPLETE のステータスに切り替わっているかどうかをチェックしてください。

    重要

    同じホスト名を使用して Compute サービスを再デプロイする場合は、再デプロイするノードに既存のサービスレコードを使用する必要があります。その場合は、この手順の残りのステップを省略して、「同じホスト名を使用した Compute サービスの再デプロイ」の手順に進んでください。

  8. ノードから Compute サービスを削除します。

    (undercloud) $ source ~/stack/overcloudrc
    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service delete [service-id]
  9. ノードから Open vSwitch エージェントを削除します。

    (overcloud) $ openstack network agent list
    (overcloud) $ openstack network agent delete [openvswitch-agent-id]
  10. 削除した Compute サービスを、配置サービスのリソースプロバイダーから除外します。

    (overcloud) $ openstack resource provider list
    (overcloud) $ openstack resource provider delete [uuid]
    注記

    配置サービスを使用するには、python2-osc-placement パッケージをインストールします。

オーバークラウドから自由にノードを削除して、別の目的でそのノードを再プロビジョニングすることができます。

同じホスト名を使用した Compute サービスの再デプロイ

無効にした Compute サービスを再デプロイするには、同じホスト名を持つノードを動作状態にした後に、Compute サービスを再度有効にします。例を以下に示します。

(overcloud) $ openstack compute service set compute-1.localdomain nova-compute --disable --disable-reason "gets re-provisioned"
(overcloud) $ openstack compute service list --long
...
| 80 | nova-compute | compute-1.localdomain | nova  | disabled | up | 2018-07-13T14:35:04.000000 | gets re-provisioned |
...
(overcloud) $ openstack compute service set compute-1.localdomain nova-compute --enable

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

director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。手順については、『Deploying an Overcloud with Containerized Red Hat Ceph』を参照してください。

13.5. オブジェクトストレージノードの置き換え

本項の手順で、クラスターの整合性を保ちながらオブジェクトストレージノードを置き換える方法を説明します。以下の例では、3 台のノードで構成されるオブジェクトストレージクラスターで、ノード overcloud-objectstorage-1 を置き換えます。この手順の目的は、ノードを 1 台追加し、その後 overcloud-objectstorage-1 を削除することです (結果的に、置き換えることになります)。

手順

  1. ObjectStorageCount パラメーターを使用してオブジェクトストレージ数を増やします。このパラメーターは、通常ノード数を指定する環境ファイルの node-info.yaml に含まれています。

    parameter_defaults:
      ObjectStorageCount: 4

    ObjectStorageCount パラメーターで、環境内のオブジェクトストレージノードの数を定義します。今回の例では、ノードを 3 つから 4 つにスケーリングします。

  2. 更新した ObjectStorageCount パラメーターを使用して、デプロイメントコマンドを実行します。

    $ source ~/stackrc
    (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml ENVIRONMENT_FILES
  3. デプロイメントコマンドの実行が完了すると、オーバークラウドには追加のオブジェクトストレージノードが含まれるようになります。
  4. 新しいノードにデータを複製します。ノードを削除する前に (この場合は overcloud-objectstorage-1)、複製のパス が新規ノードで完了するのを待ちます。/var/log/swift/swift.log ファイルで複製パスの進捗を確認することができます。パスが完了すると、Object Storage サービスは以下の例のようなエントリーをログに残します。

    Mar 29 08:49:05 localhost object-server: Object replication complete.
    Mar 29 08:49:11 localhost container-server: Replication run OVER
    Mar 29 08:49:13 localhost account-server: Replication run OVER
  5. リングから不要になったノードを削除するには、ObjectStorageCount パラメーターの数を減らして不要になったノードを削除します。今回は 3 に減らします。

    parameter_defaults:
      ObjectStorageCount: 3
  6. 新規環境ファイル (remove-object-node.yaml) を作成します。このファイルでオブジェクトストレージノードを特定し、そのノードを削除します。以下の内容では overcloud-objectstorage-1 の削除を指定します。

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  7. デプロイメントコマンドに node-info.yaml ファイルと remove-object-node.yaml ファイルの両方を含めます。

    (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml ENVIRONMENT_FILES -e remove-object-node.yaml

director は、オーバークラウドからオブジェクトストレージノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。

重要

最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。

13.6. ノードのブラックリスト登録

オーバークラウドノードがデプロイメントの更新を受け取らないように除外することができます。これは、既存のノードがコア Heat テンプレートコレクションから更新されたパラメーターセットやリソースを受け取らないように除外した状態で、新規ノードをスケーリングする場合に役立ちます。つまり、ブラックリストに登録されているノードは、スタック操作の影響を受けなくなります。

ブラックリストを作成するには、環境ファイルの DeploymentServerBlacklist パラメーターを使います。

ブラックリストの設定

DeploymentServerBlacklist パラメーターは、サーバー名のリストです。新たな環境ファイルを作成するか、既存のカスタム環境ファイルにパラメーター値を追加して、ファイルをデプロイメントコマンドに渡します。

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2
注記

パラメーター値のサーバー名には、実際のサーバーホスト名ではなく、OpenStack Orchestation (Heat) で定義されている名前を使用します。

openstack overcloud deploy コマンドで、この環境ファイルを指定します。

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heat はリスト内のサーバーをすべてブラックリストし、Heat デプロイメントの更新を受け取らないようにします。スタック操作が完了した後には、ブラックリストに登録されたサーバーは以前の状態のままとなります。操作中に os-collect-config エージェントの電源をオフにしたり、停止したりすることもできます。

警告
  • ノードをブラックリストに登録する場合には、注意が必要です。ブラックリストを有効にした状態で要求された変更を適用する方法を十分に理解していない限り、ブラックリストは使用しないでください。ブラックリスト機能を使うと、スタックがハングしたり、オーバークラウドが誤って設定されたりする場合があります。たとえば、クラスター設定の変更が Pacemaker クラスターの全メンバーに適用される場合には、この変更の間に Pacemaker クラスターのメンバーをブラックリストに登録すると、クラスターが機能しなくなる場合があります。
  • 更新またはアップグレードの操作中にブラックリストを使わないでください。これらの操作には、特定のサーバーに対する変更を分離するための独自の方法があります。詳細は、『Upgrading Red Hat OpenStack Platform』のドキュメントを参照してください。
  • サーバーをブラックリストに追加すると、そのサーバーをブラックリストから削除するまでは、それらのノードにはさらなる変更は適用されません。これには、更新、アップグレード、スケールアップ、スケールダウン、およびノードの置き換えが含まれます。

ブラックリストのクリア

その後のスタック操作のためにブラックリストをクリアするには、DeploymentServerBlacklist を編集して空の配列を使用します。

parameter_defaults:
  DeploymentServerBlacklist: []
警告

DeploymentServerBlacklist パラメーターを単に削除しないでください。パラメーターを削除しただけの場合には、オーバークラウドデプロイメントには、前回保存された値が使用されます。

第14章 コントローラーノードの置き換え

特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあります。その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。

以下のシナリオの手順を実施して、コントローラーノードを置き換えます。コントローラーノードを置き換えるプロセスでは、openstack overcloud deploy コマンドを実行し、コントローラーノードを置き換えるリクエストでオーバークラウドを更新します。

重要

以下の手順は、高可用性環境にのみ適用されます。コントローラーノード 1 台の場合には、この手順は使用しないでください。

14.1. コントローラー置き換えの準備

オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。

手順

  1. アンダークラウドで、overcloud スタックの現在の状態をチェックします。

    $ source stackrc
    (undercloud) $ openstack stack list --nested

    overcloud スタックと後続の子スタックは、CREATE_COMPLETE または UPDATE_COMPLETE のステータスである必要があります。

  2. データベースクライアントツールをインストールします。

    (undercloud) $ sudo yum -y install mariadb
  3. root ユーザーのデータベースへのアクセス権限を設定します。

    (undercloud) $ sudo cp /var/lib/config-data/puppet-generated/mysql/root/.my.cnf /root/.
  4. アンダークラウドデータベースのバックアップを実行します。

    (undercloud) $ mkdir /home/stack/backup
    (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
  5. アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。

    (undercloud) $ df -h
  6. コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。

    (undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'

    出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。

  7. オーバークラウド MariaDB クラスターの各ノードで以下のパラメーターをチェックします。

    • wsrep_local_state_comment: Synced
    • wsrep_cluster_size: 2

      実行中のコントローラーノードで以下のコマンドを使用して、パラメーターをチェックします。以下の例では、コントローラーノードの IP アドレスは、それぞれ 192.168.0.47 と 192.168.0.46 です。

      (undercloud) $ for i in 192.168.24.6 192.168.24.7 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo podman exec \$(sudo podman ps --filter name=galera-bundle -q) mysql -e \"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
  8. RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo podman exec \$(sudo podman ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

    running_nodes キーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。

  9. フェンシングが有効化されている場合には無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングのステータスを確認します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"

    フェンシングを無効にするには、以下のコマンドを実行します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"
  10. director ノードで Compute サービスがアクティブであることを確認します。

    (undercloud) $ openstack hypervisor list

    出力では、メンテナンスモードに入っていないすべてのノードが up のステータスで表示されるはずです。

  11. アンダークラウドコンテナーがすべて実行中であることを確認します。

    (undercloud) $ sudo podman ps

14.2. Ceph monitor デーモンの削除

ストレージクラスターから ceph-mon デーモンを削除するには、以下の手順に従います。コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。この手順は、コントローラーが到達可能であることを前提としています。

注記

クラスターに新しいコントローラーを追加すると、新しい Ceph monitor デーモンも自動的に追加されます。

手順

  1. 置き換えるコントローラーに接続して、root になります。

    # ssh heat-admin@192.168.0.47
    # sudo su -
    注記

    コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。

  2. root として monitor を停止します。

    # systemctl stop ceph-mon@<monitor_hostname>

    以下に例を示します。

    # systemctl stop ceph-mon@overcloud-controller-1
  3. 置き換えるコントローラーとの接続を終了します。
  4. 既存のコントローラーのいずれかに接続します。

    # ssh heat-admin@192.168.0.46
    # sudo su -
  5. クラスターから monitor を削除します。

    # sudo podman exec -it ceph-mon-controller-0 ceph mon remove overcloud-controller-1
  6. すべてのコントローラーノード上で、/etc/ceph/ceph.conf から v1 および v2 monitor のエントリーを削除します。たとえば、controller-1 を削除する場合には、controller-1 の IP アドレスとホスト名を削除します。

    編集前:

    mon host = [v2:172.18.0.21:3300,v1:172.18.0.21:6789],[v2:172.18.0.22:3300,v1:172.18.0.22:6789],[v2:172.18.0.24:3300,v1:172.18.0.24:6789]
    mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

    編集後:

    mon host = [v2:172.18.0.21:3300,v1:172.18.0.21:6789],[v2:172.18.0.24:3300,v1:172.18.0.24:6789]
    mon initial members = overcloud-controller-2,overcloud-controller-0
    注記

    置き換え用のコントローラーノードが追加されると、director によって該当するオーバークラウドノード上の ceph.conf ファイルが更新されます。通常は、director がこの設定ファイルを管理するだけで、手動でファイルを編集する必要はありません。ただし、新規ノードが追加される前に他のノードが再起動してしまった場合には、一貫性を保つために手動でファイルを編集することができます。

  7. オプションとして、monitor データをアーカイブし、アーカイブを別のサーバーに保存します。

    # mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>

14.3. コントローラーを置き換えるためのクラスター準備

古いノードを置き換える場合には、Pacemaker がノード上で実行されていないことを確認してからそのノードを Pacemaker クラスターから削除する必要があります。

手順

  1. コントローラーノードの IP アドレスの一覧を取得します。

    (undercloud) $ openstack server list -c Name -c Networks
    +------------------------+-----------------------+
    | Name                   | Networks              |
    +------------------------+-----------------------+
    | overcloud-compute-0    | ctlplane=192.168.0.44 |
    | overcloud-controller-0 | ctlplane=192.168.0.47 |
    | overcloud-controller-1 | ctlplane=192.168.0.45 |
    | overcloud-controller-2 | ctlplane=192.168.0.46 |
    +------------------------+-----------------------+
  2. まだ古いノードにアクセスできる場合は、残りのノードのいずれかにログインし、古いノード上の Pacemaker を停止します。以下の例では、overcloud-controller-1 上の Pacemaker を停止しています。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs status | grep -w Online | grep -w overcloud-controller-1"
    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster stop overcloud-controller-1"
    注記

    古いノードが物理的に利用できない、または停止している場合には、そのノードでは Pacemaker はすでに停止しているので、この操作を実施する必要はありません。

  3. 古いノード上の Pacemaker を停止したら、Pacemaker クラスターから古いノードを削除します。以下に示すコマンドの例では、overcloud-controller-0 にログインし、overcloud-controller-1 を削除しています。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster node remove overcloud-controller-1"

    置き換えるノードにアクセスすることができない場合には (ハードウェア障害などの理由により)、pcs コマンドを実行する際にさらに --skip-offline および --force オプションを指定して、ノードをクラスターから強制的に削除します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs cluster node remove overcloud-controller-1 --skip-offline --force"
  4. Pacemaker クラスターから古いノードを削除したら、Pacemaker の既知のホスト一覧からノードを削除します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs host deauth overcloud-controller-1"

    ノードにアクセス可能かどうかにかかわらず、このコマンドを実行することができます。

  5. オーバークラウドデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera-bundle"

14.4. コントローラーノードの置き換え

コントローラーノードを置き換えるには、置き換えるノードのインデックスを特定します。

  • ノードが仮想ノードの場合には、障害の発生したディスクが含まれるノードを特定し、バックアップからそのディスクをリストアします。障害の発生したサーバー上での PXE ブートに使用する NIC の MAC アドレスは、ディスク置き換え後も同じアドレスにしてください。
  • ノードがベアメタルノードの場合には、ディスクを置き換え、オーバークラウド設定で新しいディスクを準備し、新しいハードウェア上でノードのイントロスペクションを実施します。

overcloud-controller-1 ノードを overcloud-controller-3 ノードに置き換えるには、以下の手順例を実施します。overcloud-controller-3 ノードの ID は 75b25e9a-948d-424a-9b3b-f0ef70a6eacf です。

重要

ノードを既存の ironic ノードに置き換えるには、director がノードを自動的に再プロビジョニングしないように、削除するノードをメンテナンスモードに切り替える必要があります。

手順

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

    $ source ~/stackrc
  2. overcloud-controller-1 ノードのインデックスを特定します。

    $ INSTANCE=$(openstack server list --name overcloud-controller-1 -f value -c ID)
  3. インスタンスに関連付けられたベアメタルノードを特定します。

    $ NODE=$(openstack baremetal node list -f csv --quote minimal | grep $INSTANCE | cut -f1 -d,)
  4. ノードをメンテナンスモードに切り替えます。

    $ openstack baremetal node maintenance set $NODE
  5. コントローラーノードが仮想ノードの場合には、コントローラーホストで以下のコマンドを実行し、障害の発生した仮想ディスクをバックアップからの仮想ディスクに置き換えます。

    $ cp <VIRTUAL_DISK_BACKUP> /var/lib/libvirt/images/<VIRTUAL_DISK>

    <VIRTUAL_DISK_BACKUP> を障害の発生した仮想ディスクのバックアップへのパスに、<VIRTUAL_DISK> を置き換える仮想ディスクの名前にそれぞれ置き換えます。

    削除するノードのバックアップがない場合には、新しい仮想ノードを使用する必要があります。

    コントローラーノードがベアメタルノードの場合には、以下の手順を実施してディスクを新しいベアメタルディスクに置き換えます。

    1. 物理ハードドライブまたはソリッドステートドライブを置き換えます。
    2. 障害が発生したノードと同じ設定のノードを準備します。
  6. 関連付けられていないノードの一覧を表示し、新規ノードの ID を特定します。

    $ openstack baremetal node list --unassociated
  7. 新規ノードを control プロファイルにタグ付けします。

    (undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

14.5. コントローラーノード置き換えのトリガー

古いコントローラーノードを削除して新規コントローラーノードに置き換えるには、以下の手順を実施します。

手順

  1. 削除するノードのインデックスを定義する環境ファイルを作成します (~/templates/remove-controller.yaml)。

    parameters:
      ControllerRemovalPolicies:
        [{'resource_list': ['1']}]
  2. ご自分の環境に該当するその他の環境ファイルと共に remove-controller.yaml 環境ファイルを指定して、オーバークラウドデプロイメントコマンドを実行します。

    (undercloud) $ openstack overcloud deploy --templates \
        -e /home/stack/templates/remove-controller.yaml \
        -e /home/stack/templates/node-info.yaml \
        [OTHER OPTIONS]
    注記

    -e ~/templates/remove-controller.yaml は、デプロイメントコマンドのこのインスタンスに対してのみ指定します。これ以降のデプロイメント操作からは、この環境ファイルを削除してください。

  3. director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。

    (undercloud) $ openstack stack list --nested
  4. デプロイメントコマンドの実行が完了すると、director の出力には古いノードが新規ノードに置き換えられたことが表示されます。

    (undercloud) $ openstack server list -c Name -c Networks
    +------------------------+-----------------------+
    | Name                   | Networks              |
    +------------------------+-----------------------+
    | overcloud-compute-0    | ctlplane=192.168.0.44 |
    | overcloud-controller-0 | ctlplane=192.168.0.47 |
    | overcloud-controller-2 | ctlplane=192.168.0.46 |
    | overcloud-controller-3 | ctlplane=192.168.0.48 |
    +------------------------+-----------------------+

    これで、新規ノードが稼動状態のコントロールプレーンサービスをホストするようになります。

14.6. コントローラーノード置き換え後のクリーンアップ

ノードの置き換えが完了したら、以下の手順を実施してコントローラークラスターの最終処理を行います。

手順

  1. コントローラーノードにログインします。
  2. Galera クラスターの Pacemaker 管理を有効にし、新規ノード上で Galera を起動します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera-bundle
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera-bundle
  3. 最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
    注記

    エラーが発生したサービスがある場合には、pcs resource refresh コマンドを使用して問題を解決し、そのサービスを再起動します。

  4. director を終了します。

    [heat-admin@overcloud-controller-0 ~]$ exit
  5. オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。

    $ source ~/overcloudrc
  6. オーバークラウド環境のネットワークエージェントを確認します。

    (overcloud) $ openstack network agent list
  7. 古いノードにエージェントが表示される場合には、そのエージェントを削除します。

    (overcloud) $ for AGENT in $(openstack network agent list --host overcloud-controller-1.localdomain -c ID -f value) ; do openstack network agent delete $AGENT ; done
  8. 必要に応じて、新規ノード上の L3 エージェントホストにルーターを追加します。以下のコマンド例では、UUID に 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 を使用して L3 エージェントに r1 という名称のルーターを追加しています。

    (overcloud) $ openstack network agent add router --l3 2d1c1dc1-d9d4-4fa9-b2c8-f29cd1a649d4 r1
  9. 削除されたノードの Compute サービスはオーバークラウドにまだ存在しているので、削除する必要があります。削除したノードの Compute サービスをチェックします。

    [stack@director ~]$ source ~/overcloudrc
    (overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain
  10. 削除したノードのコンピュートサービスを削除します。

    (overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -c ID -f value ) ; do openstack compute service delete $SERVICE ; done

第15章 ノードのリブート

アンダークラウドおよびオーバークラウドで、ノードをリブートしなければならない場合があります。以下の手順を使用して、さまざまなノード種別をリブートする方法を説明します。以下の点に注意してください。

  • 1 つのロールで全ノードをリブートする場合には、各ノードを個別にリブートすることを推奨しています。ロールの全ノードを同時にリブートすると、リブート操作中にサービスにダウンタイムが生じる場合があります。
  • OpenStack Platform 環境の全ノードをリブートする場合には、以下の順序でノードをリブートします。

推奨されるノードリブート順

  1. アンダークラウドノードのリブート
  2. コントローラーノードおよびその他のコンポーザブルノードのリブート
  3. スタンドアロンの Ceph MON ノードのリブート
  4. Ceph Storage ノードのリブート
  5. コンピュートノードのリブート

15.1. アンダークラウドノードのリブート

アンダークラウドノードをリブートするには、以下の手順を実施します。

手順

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

    $ sudo reboot
  3. ノードが起動するまで待ちます。

15.2. コントローラーノードおよびコンポーザブルノードのリブート

コントローラーノードおよびコンポーザブルロールに基づくスタンドアロンのノードをリブートするには、以下の手順を実施します。ただし、これにはコンピュートノードおよび Ceph Storage ノードは含まれません。

手順

  1. リブートするノードを選択します。そのノードにログインし、リブートする前にクラスターを停止します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
  2. ノードをリブートします。

    [heat-admin@overcloud-controller-0 ~]$ sudo reboot
  3. ノードが起動するまで待ちます。
  4. ノードのクラスターを再度有効化します。

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start
  5. ノードにログインしてサービスをチェックします。

    1. ノードが Pacemaker サービスを使用している場合には、ノードがクラスターに再度加わったかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
    2. ノードが Systemd サービスを使用している場合には、全サービスが有効化されているかどうかを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status
    3. ノードがコンテナー化されたサービスを使用している場合には、ノード上の全コンテナーがアクティブであることを確認します。

      [heat-admin@overcloud-controller-0 ~]$ sudo podman ps

15.3. スタンドアロンの Ceph MON ノードのリブート

スタンドアロンの Ceph MON ノードをリブートするには、以下の手順を実施します。

手順

  1. Ceph MON ノードにログインします。
  2. ノードをリブートします。

    $ sudo reboot
  3. ノードがブートして MON クラスターに再度加わるまで待ちます。

クラスター内の各 MON ノードで、この手順を繰り返します。

15.4. Ceph Storage (OSD) クラスターのリブート

Ceph Storage (OSD) ノードのクラスターをリブートするには、以下の手順を実施します。

手順

  1. Ceph MON またはコントローラーノードにログインして、Ceph Storage クラスターのリバランスを一時的に無効にします。

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
  2. リブートする最初の Ceph Storage ノードを選択し、そのノードにログインします。
  3. ノードをリブートします。

    $ sudo reboot
  4. ノードが起動するまで待ちます。
  5. ノードにログインして、クラスターのステータスを確認します。

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

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

  6. ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
  7. 完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
  8. 最終のステータスチェックを実行して、クラスターが HEALTH_OK を報告していることを確認します。

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

15.5. コンピュートノードのリブート

コンピュートノードをリブートするには、以下の手順を実施します。OpenStack Platform 環境内のインスタンスのダウンタイムを最小限に抑えるために、この手順には、リブートするコンピュートノードからインスタンスを移行するステップも含まれています。これは、以下のワークフローを伴います。

  • コンピュートノードをリブートする前に、インスタンスを別のノードに移行するかどうかを決定する
  • リブートするコンピュートノードを選択して無効にし、新規インスタンスをプロビジョニングしないようにする
  • インスタンスを別のコンピュートノードに移行する
  • 空のコンピュートノードをリブートする
  • 空のコンピュートノードを有効にする

前提条件

コンピュートノードをリブートする前に、ノードをリブートする間インスタンスを別のコンピュートノードに移行するかどうかを決定する必要があります。

何らかの理由でインスタンスを移行することができない、または移行を希望しない場合には、以下のコアテンプレートパラメーターを設定して、コンピュートノードリブート後のインスタンスの状態を制御することができます。

NovaResumeGuestsStateOnHostBoot
リブート後のコンピュートノードで、インスタンスを同じ状態に戻すかどうかを定義します。False に設定すると、インスタンスは停止した状態を維持し、手動で起動する必要があります。デフォルト値は False です。
NovaResumeGuestsShutdownTimeout
リブートする前に、インスタンスのシャットダウンを待つ秒数。この値を 0 に設定することは推奨されません。デフォルト値は 300 です。

オーバークラウドパラメーターおよびその使用方法に関する全般的な情報は、『オーバークラウドのパラメーター』を参照してください。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. 全コンピュートノードとその UUID を一覧表示します。

    $ source ~/stackrc
    (undercloud) $ openstack server list --name compute

    リブートするコンピュートノードの UUID を特定します。

  3. アンダークラウドから、コンピュートノードを選択します。そのノードを無効にします。

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service list
    (overcloud) $ openstack compute service set [hostname] nova-compute --disable
  4. コンピュートノード上の全インスタンスを一覧表示します。

    (overcloud) $ openstack server list --host [hostname] --all-projects
  5. インスタンスを移行しない場合は、このステップ に進みます。
  6. インスタンスを別のコンピュートノードに移行する場合には、以下のコマンドのいずれかを使用します。

    1. インスタンスを別のホストに移行する。

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait
    2. nova-scheduler により対象のホストが自動的に選択されるようにする。

      (overcloud) $ nova live-migration [instance-id]
    3. 一度にすべてのインスタンスのライブマイグレーションを行う。

      $ nova host-evacuate-live [hostname]
      注記

      nova コマンドで非推奨の警告が表示される可能性がありますが、無視して問題ありません。

  7. 移行が完了するまで待ちます。
  8. 正常に移行したことを確認します。

    (overcloud) $ openstack server list --host [hostname] --all-projects
  9. 選択したコンピュートノードのインスタンスがなくなるまで、移行を続けます。
  10. コンピュートノードにログインします。ノードをリブートします。

    [heat-admin@overcloud-compute-0 ~]$ sudo reboot
  11. ノードが起動するまで待ちます。
  12. コンピュートノードを再度有効化します。

    $ source ~/overcloudrc
    (overcloud) $ openstack compute service set [hostname] nova-compute --enable
  13. コンピュートノードが有効化されているかどうかを確認します。

    (overcloud) $ openstack compute service list

パート IV. director に関するその他の操作および設定

第16章 カスタム SSL/TLS 証明書の設定

アンダークラウドがパブリックエンドポイントの通信に SSL/TLS を使用するように設定できます。ただし、独自の認証局で発行した SSL 証明書を使用する場合には、以下の設定手順を実施する必要があります。

16.1. 署名ホストの初期化

署名ホストとは、認証局を使用して新規証明書を生成し署名するホストです。選択した署名ホスト上で SSL 証明書を作成したことがない場合には、ホストを初期化して新規証明書に署名できるようにする必要がある可能性があります。

手順

  1. すべての署名済み証明書の記録は、/etc/pki/CA/index.txt ファイルに含まれます。このファイルが存在しているかどうかを確認してください。存在していない場合には、空のファイルを作成します。

    $ sudo touch /etc/pki/CA/index.txt
  2. /etc/pki/CA/serial ファイルは、次に署名する証明書に使用する次のシリアル番号を特定します。このファイルが存在しているかどうかを確認してください。ファイルが存在しない場合には、新規ファイルを作成して新しい開始値を指定します。

    $ echo '1000' | sudo tee /etc/pki/CA/serial

16.2. 認証局の作成

通常、SSL/TLS 証明書の署名には、外部の認証局を使用します。場合によっては、独自の認証局を使用する場合もあります。たとえば、内部のみの認証局を使用するように設定する場合などです。

手順

  1. 鍵と証明書のペアを生成して、認証局として機能するようにします。
$ openssl genrsa -out ca.key.pem 4096
$ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
  1. openssl req コマンドは、認証局に関する特定の情報を要求します。要求されたら、それらの情報を入力してください。

これらのコマンドにより、ca.crt.pem という名前の認証局ファイルが作成されます。

16.3. クライアントへの認証局の追加

SSL/TLS を使用して通信する外部クライアントについては、Red Hat OpenStack Platform 環境にアクセスする必要のある各クライアントに認証局ファイルをコピーします。

手順

  1. 認証局をクライアントシステムにコピーします。

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
  2. 各クライアントに認証局ファイルをコピーしたら、それぞれのクライアントで以下のコマンドを実行し、証明書を認証局のトラストバンドルに追加します。

    $ sudo update-ca-trust extract

16.4. SSL/TLS 鍵の作成

OpenStack 環境で SSL/TLS を有効にするには、証明書を生成するための SSL/TLS 鍵が必要です。以下の手順で、この鍵の生成方法を説明します。

手順

  1. 以下のコマンドを実行し、SSL/TLS 鍵 (server.key.pem) を生成します。

    $ openssl genrsa -out server.key.pem 2048

16.5. SSL/TLS 証明書署名要求の作成

証明書署名要求を作成するには、以下の手順を実施します。

手順

  1. デフォルトの OpenSSL 設定ファイルをコピーします。

    $ cp /etc/pki/tls/openssl.cnf .
  2. 新しい openssl.cnf ファイルを編集して、director に使用する SSL パラメーターを設定します。変更するパラメーターの種別には以下のような例が含まれます。

    [req]
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    
    [req_distinguished_name]
    countryName = Country Name (2 letter code)
    countryName_default = AU
    stateOrProvinceName = State or Province Name (full name)
    stateOrProvinceName_default = Queensland
    localityName = Locality Name (eg, city)
    localityName_default = Brisbane
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = Red Hat
    commonName = Common Name
    commonName_default = 192.168.0.1
    commonName_max = 64
    
    [ v3_req ]
    # Extensions to add to a certificate request
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    
    [alt_names]
    IP.1 = 192.168.0.1
    DNS.1 = instack.localdomain
    DNS.2 = vip.localdomain
    DNS.3 = 192.168.0.1

    commonName_default を、以下のエントリーのいずれかに設定します。

    • IP アドレスを使用して SSL/TLS 経由で director にアクセスする場合には、undercloud.confundercloud_public_host パラメーターを使用します。
    • 完全修飾ドメイン名を使用して SSL/TLS 経由で director にアクセスする場合には、ドメイン名を使用します。

      alt_names セクションを編集して、以下のエントリーを追加します。

    • IP: SSL 経由で director にアクセスするためにクライアントが使用する IP アドレス一覧。
    • DNS: SSL 経由で director にアクセスするためにクライアントが使用するドメイン名一覧。alt_names セクションの最後に DNS エントリーとしてパブリック API の IP アドレスも追加します。
    注記

    openssl.cnf に関する詳しい情報については、man openssl.cnf コマンドを実行してください。

  3. 以下のコマンドを実行し、証明書署名要求 (server.csr.pem) を生成します。

    $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

    -key オプションを使用して、OpenStack SSL/TLS 鍵を指定するようにしてください。

このコマンドにより、証明書署名要求として server.csr.pem ファイルが生成されます。このファイルを使用して OpenStack SSL/TLS 証明書を作成します。

16.6. SSL/TLS 証明書の作成

以下の手順で、OpenStack 環境の証明書を生成する方法を説明します。ここで説明する手順には、以下のファイルが必要です。

openssl.cnf
v3 拡張機能を指定するカスタム設定ファイル。
server.csr.pem
証明書を生成して認証局を使用して署名するための証明書署名要求。
ca.crt.pem
証明書への署名を行う認証局。
ca.key.pem
認証局の秘密鍵。

手順

  1. 以下のコマンドを実行し、アンダークラウドまたはオーバークラウドの証明書を作成します。

    $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

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

    -config
    カスタム設定ファイルを使用します (ここでは、v3 拡張機能を指定した openssl.cnf ファイル)。
    -extensions v3_req
    v3 拡張機能を有効にします。
    -days
    証明書の有効期限が切れるまでの日数を定義します。
    -in
    証明書署名要求。
    -out
    作成される署名済み証明書。
    -cert
    認証局ファイル。
    -keyfile
    認証局の秘密鍵。

上記のコマンドにより、server.crt.pem という名前の新規証明書が作成されます。OpenStack SSL/TLS 鍵と共にこの証明書を使用します。

16.7. アンダークラウドへの証明書の追加

OpenStack SSL/TLS 証明書をアンダークラウドのトラストバンドルに追加するには、以下の手順を実施します。

手順

  1. 以下のコマンドを実行して、証明書と鍵を統合します。

    $ cat server.crt.pem server.key.pem > undercloud.pem

    このコマンドにより、undercloud.pem ファイルが作成されます。

  2. undercloud.pem ファイルを /etc/pki ディレクトリー内の場所にコピーし、HAProxy が読み取ることができるように必要な SELinux コンテキストを設定します。

    $ sudo mkdir /etc/pki/undercloud-certs
    $ sudo cp ~/undercloud.pem /etc/pki/undercloud-certs/.
    $ sudo semanage fcontext -a -t etc_t "/etc/pki/undercloud-certs(/.*)?"
    $ sudo restorecon -R /etc/pki/undercloud-certs
  3. undercloud.conf ファイルの undercloud_service_certificate オプションに undercloud.pem ファイルの場所を追加します。

    undercloud_service_certificate = /etc/pki/undercloud-certs/undercloud.pem
  4. 証明書に署名した認証局をアンダークラウドの信頼済み認証局の一覧に追加して、アンダークラウド内の別のサービスが認証局にアクセスできるようにします。

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
    $ sudo update-ca-trust extract

アンダークラウドのインストールを続行します。

第17章 その他のイントロスペクション操作

17.1. ノードイントロスペクションの個別実行

available 状態のノードで個別にイントロスペクションを実施するには、以下のコマンドを実行してノードを管理モードに設定し、イントロスペクションを実施します。

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

イントロスペクションが完了すると、ノードの状態が available に変わります。

17.2. 初回のイントロスペクション後のノードイントロスペクションの実行

--provide オプションを指定したので、初回のイントロスペクションの後には、全ノードが available の状態に入るはずです。初回のイントロスペクション後に全ノードにイントロスペクションを実行するには、すべてのノードを manageable の状態にして、一括のイントロスペクションコマンドを実行します。

(undercloud) $ for node in $(openstack baremetal node list --fields uuid -f value) ; do openstack baremetal node manage $node ; done
(undercloud) $ openstack overcloud node introspect --all-manageable --provide

イントロスペクション完了後には、すべてのノードが available の状態に変わります。

17.3. ネットワークイントロスペクションの実行によるインターフェース情報の取得

ネットワークイントロスペクションにより、Link Layer Discovery Protocol (LLDP) データがネットワークスイッチから取得されます。以下のコマンドにより、ノード上の全インターフェースに関する LLDP 情報のサブセット、または特定のノードおよびインターフェースに関するすべての情報が表示されます。この情報は、トラブルシューティングに役立ちます。director では、デフォルトで LLDP データ収集が有効になっています。

ノード上のインターフェースを一覧表示するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface list [NODE UUID]

以下に例を示します。

(undercloud) $ openstack baremetal introspection interface list c89397b7-a326-41a0-907d-79f8b86c7cd9
+-----------+-------------------+------------------------+-------------------+----------------+
| Interface | MAC Address       | Switch Port VLAN IDs   | Switch Chassis ID | Switch Port ID |
+-----------+-------------------+------------------------+-------------------+----------------+
| p2p2      | 00:0a:f7:79:93:19 | [103, 102, 18, 20, 42] | 64:64:9b:31:12:00 | 510            |
| p2p1      | 00:0a:f7:79:93:18 | [101]                  | 64:64:9b:31:12:00 | 507            |
| em1       | c8:1f:66:c7:e8:2f | [162]                  | 08:81:f4:a6:b3:80 | 515            |
| em2       | c8:1f:66:c7:e8:30 | [182, 183]             | 08:81:f4:a6:b3:80 | 559            |
+-----------+-------------------+------------------------+-------------------+----------------+

インターフェースのデータおよびスイッチポートの情報を表示するには、以下のコマンドを実行します。

(undercloud) $ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]

以下に例を示します。

(undercloud) $ openstack baremetal introspection interface show c89397b7-a326-41a0-907d-79f8b86c7cd9 p2p1
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| Field                                | Value                                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+
| interface                            | p2p1                                                                                                                   |
| mac                                  | 00:0a:f7:79:93:18                                                                                                      |
| node_ident                           | c89397b7-a326-41a0-907d-79f8b86c7cd9                                                                                   |
| switch_capabilities_enabled          | [u'Bridge', u'Router']                                                                                                 |
| switch_capabilities_support          | [u'Bridge', u'Router']                                                                                                 |
| switch_chassis_id                    | 64:64:9b:31:12:00                                                                                                      |
| switch_port_autonegotiation_enabled  | True                                                                                                                   |
| switch_port_autonegotiation_support  | True                                                                                                                   |
| switch_port_description              | ge-0/0/2.0                                                                                                             |
| switch_port_id                       | 507                                                                                                                    |
| switch_port_link_aggregation_enabled | False                                                                                                                  |
| switch_port_link_aggregation_id      | 0                                                                                                                      |
| switch_port_link_aggregation_support | True                                                                                                                   |
| switch_port_management_vlan_id       | None                                                                                                                   |
| switch_port_mau_type                 | Unknown                                                                                                                |
| switch_port_mtu                      | 1514                                                                                                                   |
| switch_port_physical_capabilities    | [u'1000BASE-T fdx', u'100BASE-TX fdx', u'100BASE-TX hdx', u'10BASE-T fdx', u'10BASE-T hdx', u'Asym and Sym PAUSE fdx'] |
| switch_port_protocol_vlan_enabled    | None                                                                                                                   |
| switch_port_protocol_vlan_ids        | None                                                                                                                   |
| switch_port_protocol_vlan_support    | None                                                                                                                   |
| switch_port_untagged_vlan_id         | 101                                                                                                                    |
| switch_port_vlan_ids                 | [101]                                                                                                                  |
| switch_port_vlans                    | [{u'name': u'RHOS13-PXE', u'id': 101}]                                                                                 |
| switch_protocol_identities           | None                                                                                                                   |
| switch_system_name                   | rhos-compute-node-sw1                                                                                                  |
+--------------------------------------+------------------------------------------------------------------------------------------------------------------------+

ハードウェアイントロスペクション情報の取得

Bare Metal サービスでは、ハードウェア検査時に追加のハードウェア情報を取得するためのパラメーター (inspection_extras) がデフォルトで有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf ファイルの inspection_extras パラメーターに関する詳細は、「director の設定」を参照してください。

たとえば、numa_topology コレクターは、このハードウェア inspection_extras の一部で、各 NUMA ノードに関する以下の情報が含まれます。

  • RAM (キロバイト単位)
  • 物理 CPU コアおよびそのシブリングスレッド
  • NUMA ノードに関連付けられた NIC

この情報を取得するには、ベアメタルノードの UUID を指定して openstack baremetal introspection data save _UUID_ | jq .numa_topology コマンドを使用します。

取得されるベアメタルノードの NUMA 情報の例を、以下に示します。

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

第18章 ベアメタルノードの自動検出

auto-discovery を使用すると、最初に instackenv.json ファイルを作成せずに、アンダークラウドノードを登録してそのメタデータを生成することができます。この改善により、最初にノードに関する情報を取得するのに費す時間を短縮できます。たとえば、IPMI IP アドレスを照合し、その後に instackenv.json ファイルを作成する必要がなくなります。

18.1. 要件

  • IPMI を通じて director がアクセスできるように、すべてのオーバークラウドノードの BMC が設定されていること
  • すべてのオーバークラウドノードが、アンダークラウドのコントロールプレーンネットワークに接続された NIC から PXE ブートするように設定されていること

18.2. 自動検出の有効化

  1. undercloud.conf でベアメタルの自動検出を有効にします。

    enable_node_discovery = True
    discovery_default_driver = ipmi
    • enable_node_discovery: 有効にすると、PXE を使ってイントロスペクション ramdisk をブートするすべてのノードが Ironic に登録されます。
    • discovery_default_driver: 検出されたノードに使用するドライバーを設定します。例: ipmi
  2. IPMI の認証情報を Ironic に追加します。

    1. IPMI の認証情報を ipmi-credentials.json という名前のファイルに追加します。この例で使用しているユーザー名およびパスワードの値は、お使いの環境に応じて置き換える必要があります。

      [
          {
              "description": "Set default IPMI credentials",
              "conditions": [
                  {"op": "eq", "field": "data://auto_discovered", "value": true}
              ],
              "actions": [
                  {"action": "set-attribute", "path": "driver_info/ipmi_username",
                   "value": "SampleUsername"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_password",
                   "value": "RedactedSecurePassword"},
                  {"action": "set-attribute", "path": "driver_info/ipmi_address",
                   "value": "{data[inventory][bmc_address]}"}
              ]
          }
      ]
  3. IPMI の認証情報ファイルを Ironic にインポートします。

    $ openstack baremetal introspection rule import ipmi-credentials.json

18.3. 自動検出のテスト

  1. 必要なノードの電源をオンにします。
  2. openstack baremetal node list コマンドを実行します。新しいノードが enroll の状態でリストに表示されるはずです。

    $ openstack baremetal node list
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | UUID                                 | Name | Instance UUID | Power State | Provisioning State | Maintenance |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
    | c6e63aec-e5ba-4d63-8d37-bd57628258e8 | None | None          | power off   | enroll             | False       |
    | 0362b7b2-5b9c-4113-92e1-0b34a2535d9b | None | None          | power off   | enroll             | False       |
    +--------------------------------------+------+---------------+-------------+--------------------+-------------+
  3. 各ノードにリソースクラスを設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node set $NODE --resource-class baremetal ; done
  4. 各ノードにカーネルと ramdisk を設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node manage $NODE ; done
    $ openstack overcloud node configure --all-manageable
  5. 全ノードを利用可能な状態に設定します。

    $ for NODE in `openstack baremetal node list -c UUID -f value` ; do openstack baremetal node provide $NODE ; done

18.4. ルールを使用して異なるベンダーのハードウェアを検出する方法

異種のハードウェアが混在する環境では、イントロスペクションルールを使って、認証情報の割り当てやリモート管理を行うことができます。たとえば、DRAC を使用する Dell ノードを処理するには、別の検出ルールが必要になる場合があります。

  1. 以下の内容で、dell-drac-rules.json という名前のファイルを作成します。

    [
        {
            "description": "Set default IPMI credentials",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "ne", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver_info/ipmi_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/ipmi_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/ipmi_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        },
        {
            "description": "Set the vendor driver for Dell hardware",
            "conditions": [
                {"op": "eq", "field": "data://auto_discovered", "value": true},
                {"op": "eq", "field": "data://inventory.system_vendor.manufacturer",
                 "value": "Dell Inc."}
            ],
            "actions": [
                {"action": "set-attribute", "path": "driver", "value": "idrac"},
                {"action": "set-attribute", "path": "driver_info/drac_username",
                 "value": "SampleUsername"},
                {"action": "set-attribute", "path": "driver_info/drac_password",
                 "value": "RedactedSecurePassword"},
                {"action": "set-attribute", "path": "driver_info/drac_address",
                 "value": "{data[inventory][bmc_address]}"}
            ]
        }
    ]

    この例で使用しているユーザー名およびパスワードの値は、お使いの環境に応じて置き換える必要があります。

  2. ルールを Ironic にインポートします。

    $ openstack baremetal introspection rule import dell-drac-rules.json

第19章 プロファイルの自動タグ付けの設定

イントロスペクションプロセスでは、一連のベンチマークテストを実行します。director は、これらのテストからデータを保存します。このデータをさまざまな方法で使用するポリシーセットを作成することができます。

  • ポリシーにより、パフォーマンスの低いノードまたは不安定なノードを特定して、これらのノードがオーバークラウドで使用されないように隔離することができます。
  • ポリシーにより、ノードを自動的に特定のプロファイルにタグ付けするかどうかを定義することができます。

19.1. ポリシーファイルの構文

ポリシーファイルは JSON 形式で、ルールセットが記載されます。各ルールでは、説明条件、および アクション が定義されます。

description

これは、プレーンテキストで記述されたルールの説明です。

以下に例を示します。

"description": "A new rule for my node tagging policy"

conditions

ここでは、以下のキー/値のパターンを使用して評価を定義します。

field

評価するフィールドを定義します。

  • memory_mb: ノードのメモリーサイズ (MB 単位)
  • cpus: ノードの CPU の合計スレッド数
  • cpu_arch: ノードの CPU のアーキテクチャー
  • local_gb: ノードのルートディスクの合計ストレージ容量
op

評価に使用する演算を定義します。これには、以下の属性が含まれます。

  • eq: 等しい
  • ne: 等しくない
  • lt: より小さい
  • gt: より大きい
  • le: より小さいか等しい
  • ge: より大きいか等しい
  • in-net: IP アドレスが指定のネットワーク内にあることをチェックします。
  • matches: 指定の正規表現と完全に一致する必要があります。
  • contains: 値には、指定の正規表現が含まれる必要があります。
  • is-empty: フィールドが空欄であることをチェックします。
invert
評価の結果をインバージョン (反転) するかどうかを定義するブール値
multiple

複数の結果が存在する場合に、使用する評価を定義します。このパラメーターには以下の属性が含まれます。

  • any: いずれかの結果が一致する必要があります。
  • all: すべての結果が一致する必要があります。
  • first: 最初の結果が一致する必要があります。
value
評価する値を定義します。フィールド、演算、および値の条件が満たされる場合には、true の結果を返します。そうでない場合には、条件は false の結果を返します。

以下に例を示します。

"conditions": [
  {
    "field": "local_gb",
    "op": "ge",
    "value": 1024
  }
],

actions

条件が「true」の場合には、ポリシーはアクションを実行します。アクションでは、action キーおよび action の値に応じた追加のキーが使用されます。

  • fail: イントロスペクションが失敗します。失敗のメッセージには、message パラメーターが必要です。
  • set-attribute: Ironic ノードの属性を設定します。Ironic の属性へのパス (例: /driver_info/ipmi_address) を指定する path フィールドおよび設定する value が必要です。
  • set-capability: Ironic ノードのケイパビリティーを設定します。新しいケイパビリティーの名前と値を指定する name および value フィールドが必要です。同じケイパビリティーの既存の値は置き換えられます。たとえば、これを使用してノードのプロファイルを定義します。
  • extend-attribute: set-attribute と同じですが、既存の値を一覧として扱い、その一覧に値を追記します。オプションの unique パラメーターを True に設定すると、対象の値がすでに一覧に含まれている場合には何も追加しません。

以下に例を示します。

"actions": [
  {
    "action": "set-capability",
    "name": "profile",
    "value": "swift-storage"
  }
]

19.2. ポリシーファイルの例

以下は、適用するイントロスペクションルールを記載した JSON ファイル (rules.json) の一例です。

[
  {
    "description": "Fail introspection for unexpected nodes",
    "conditions": [
      {
        "op": "lt",
        "field": "memory_mb",
        "value": 4096
      }
    ],
    "actions": [
      {
        "action": "fail",
        "message": "Memory too low, expected at least 4 GiB"
      }
    ]
  },
  {
    "description": "Assign profile for object storage",
    "conditions": [
      {
        "op": "ge",
        "field": "local_gb",
        "value": 1024
      }
    ],
    "actions": [
      {
        "action": "set-capability",
        "name": "profile",
        "value": "swift-storage"
      }
    ]
  },
  {
    "description": "Assign possible profiles for compute and controller",
    "conditions": [
      {
        "op": "lt",
        "field": "local_gb",
        "value": 1024
      },
      {
        "op": "ge",
        "field": "local_gb",
        "value": 40
      }
    ],
    "actions": [
      {
        "action": "set-capability",
        "name": "compute_profile",
        "value": "1"
      },
      {
        "action": "set-capability",
        "name": "control_profile",
        "value": "1"
      },
      {
        "action": "set-capability",
        "name": "profile",
        "value": null
      }
    ]
  }
]

上記の例は、3 つのルールで構成されています。

  • メモリーが 4096 MiB 未満の場合には、イントロスペクションが失敗します。クラウドから特定のノードを除外する場合は、このルール種別を適用することができます。
  • ハードドライブのサイズが 1 TiB 以上のノードの場合は swift-storage プロファイルが無条件で割り当てられます。
  • ハードドライブが 1 TiB 未満だが 40 GiB を超えているノードは、コンピュートノードまたはコントロールノードのいずれかに割り当てることができます。openstack overcloud profiles match コマンドを使用して後で最終選択できるように、2 つのケイパビリティー (compute_profile および control_profile) を割り当てています。このプロセスが機能するためには、既存のプロファイルケイパビリティーを削除する必要があります。削除しないと、既存のプロファイルケイパビリティーが優先されます。

プロファイルマッチングルールは、他のノードを変更しません。

注記

イントロスペクションルールを使用して profile 機能を割り当てる場合は常に、既存の値よりこの割り当てた値が優先されます。ただし、すでにプロファイルケイパビリティーを持つノードについては、[PROFILE]_profile ケイパビリティーは無視されます。

19.3. ポリシーファイルのインポート

ポリシーファイルを director にインポートするには、以下の手順を実施します。

手順

  1. ポリシーファイルを director にインポートします。

    $ openstack baremetal introspection rule import rules.json
  2. イントロスペクションのプロセスを実行します。

    $ openstack overcloud node introspect --all-manageable
  3. イントロスペクションが完了したら、ノードとノードに割り当てられたプロファイルを確認します。

    $ openstack overcloud profiles list
  4. イントロスペクションルールに間違いがあった場合には、以下のコマンドを実行してすべてのルールを削除します。

    $ openstack baremetal introspection rule purge

第20章 完全なディスクイメージの作成

メインのオーバークラウドイメージは、イメージ自体にパーティション情報またはブートローダーが含まれないフラットパーティションイメージです。director は、ノードのブート時には別のカーネルおよび ramdisk を使用し、オーバークラウドイメージをディスクに書き込む際に基本的なパーティションレイアウトを作成します。ただし、パーティションレイアウト、ブートローダー、および強化されたセキュリティー機能が含まれる完全なディスクイメージを作成することができます。

重要

以下のプロセスでは、director のイメージビルド機能を使用します。Red Hat では、本項に記載の指針に従ってビルドされたイメージのみをサポートしています。これらとは異なる仕様でビルドされたカスタムイメージはサポートされていません。

20.1. セキュリティー強化手段

完全なディスクイメージには、セキュリティーが重要な機能となる Red Hat OpenStack Platform のデプロイメントに必要な、追加のセキュリティー強化手段が含まれます。イメージを作成する際には、以下の一覧に示す推奨事項を検討してください。

  • /tmp ディレクトリーを別のボリュームまたはパーティションにマウントし、rwnosuidnodevnoexec、および relatime のフラグを付ける。
  • /var/var/log、および /var/log/audit ディレクトリーを別のボリュームまたはパーティションにマウントし、rw および relatime のフラグを付ける。
  • /home ディレクトリーを別のパーティションまたはボリュームにマウントし、rwnodev、および relatime のフラグを付ける。
  • GRUB_CMDLINE_LINUX の設定に以下の変更を加える。

    • 監査を有効にするには、audit=1 カーネルブートフラグを追加する。
    • ブートローダー設定を使用した USB のカーネルサポートを無効にするには、nousb を追加する。
    • セキュアでないブートフラグを削除するには、crashkernel=auto を設定する。
  • セキュアでないモジュール (usb-storagecramfsfreevxfsjffs2hfshfsplussquashfsudfvfat) をブラックリストに登録して、読み込まれないようにする。
  • セキュアでないパッケージ (kexec-tools によりインストールされた kdump および telnet) がデフォルトでインストールされるので、それらをイメージから削除する。

20.2. 完全なディスクイメージに関するワークフロー

完全なディスクイメージをビルドするには、以下のワークフローに従います。

  1. ベースの Red Hat Enterprise Linux 8 イメージをダウンロードする
  2. 登録固有の環境変数を設定する
  3. パーティションスキーマとサイズを変更してイメージをカスタマイズする
  4. イメージを作成する
  5. イメージを director にアップロードする

20.3. ベースのクラウドイメージのダウンロード

完全なディスクイメージをビルドする前に、ベースとして使用する Red Hat Enterprise Linux の既存のクラウドイメージをダウンロードする必要があります。

手順

  1. Red Hat カスタマーポータルにアクセスします。

  2. トップメニューの ダウンロード をクリックします。
  3. Red Hat Enterprise Linux をクリックします。

    注記

    要求されたら、カスタマーポータルのログイン情報を入力します。

  4. ダウンロードする KVM ゲストイメージを選択します。たとえば、最新の Red Hat Enterprise Linux の KVM ゲストイメージは以下のページにあります。

20.4. ディスクイメージの環境変数

ディスクイメージのビルドプロセスとして、director にはベースイメージと、新規オーバークラウドイメージのパッケージを取得するための登録情報が必要です。これらの属性は、以下に示す Linux の環境変数を使用して定義します。

注記

イメージのビルドプロセスにより、イメージは一時的に Red Hat サブスクリプションに登録され、システムがイメージのビルドプロセスを完了すると登録を解除します。

ディスクイメージをビルドするには、Linux の環境変数をお使いの環境と要件に応じて設定します。

DIB_LOCAL_IMAGE
完全なディスクイメージのベースに使用するローカルイメージを設定します。
REG_ACTIVATION_KEY
登録プロセスにおいて、ログイン情報の代わりにアクティベーションキーを使用します。
REG_AUTO_ATTACH
最も互換性のあるサブスクリプションを自動的にアタッチするかどうかを定義します。
REG_BASE_URL
イメージのパッケージが含まれるコンテンツ配信サーバーのベース URL。カスタマーポータル Subscription Management のデフォルトプロセスでは https://cdn.redhat.com を使用します。Red Hat Satellite 6 サーバーを使用している場合は、このパラメーターをお使いの Satellite サーバーのベース URL に設定します。
REG_ENVIRONMENT
組織内の環境に登録します。
REG_METHOD
登録の方法を設定します。Red Hat カスタマーポータルに登録するには portal を使用します。Red Hat Satellite 6 で登録するには、satellite を使用します。
REG_ORG
イメージを登録する組織
REG_POOL_ID
製品のサブスクリプション情報のプール ID
REG_PASSWORD
イメージを登録するユーザーアカウントのパスワードを指定します。
REG_REPOS

リポジトリー名のコンマ区切り文字列。この文字列の各リポジトリーは subscription-manager で有効化されます。

以下に示すセキュリティー強化された完全なディスクイメージのリポジトリーを使用します。

  • rhel-8-for-x86_64-baseos-rpms
  • rhel-8-for-x86_64-appstream-rpms
  • rhel-8-for-x86_64-highavailability-rpms
  • ansible-2.8-for-rhel-8-x86_64-rpms
  • openstack-15-for-rhel-8-x86_64-rpms
REG_SAT_URL
オーバークラウドノードを登録する Satellite サーバーのベース URL。このパラメーターには、HTTPS URL ではなく、Satellite の HTTP URL を使用します。たとえば、https://satellite.example.com ではなく http://satellite.example.com を使用します。
REG_SERVER_URL
使用するサブスクリプションサービスのホスト名を指定します。Red Hat カスタマーポータルの場合のデフォルトは subscription.rhn.redhat.com です。Red Hat Satellite 6 サーバーを使用する場合は、このパラメーターをお使いの Satellite サーバーのホスト名に設定します。
REG_USER
イメージを登録するアカウントのユーザー名を指定します。

環境変数のセットをエクスポートし、ローカルの QCOW2 イメージを一時的に Red Hat カスタマーポータルに登録するには、以下の例に示すコマンドのセットを使用します。

$ export DIB_LOCAL_IMAGE=./rhel-8.0-x86_64-kvm.qcow2
$ export REG_METHOD=portal
$ export REG_USER="[your username]"
$ export REG_PASSWORD="[your password]"
$ export REG_REPOS="rhel-8-for-x86_64-baseos-rpms \
    rhel-8-for-x86_64-appstream-rpms \
    rhel-8-for-x86_64-highavailability-rpms \
    ansible-2.8-for-rhel-8-x86_64-rpms \
    openstack-15-for-rhel-8-x86_64-rpms"

20.5. ディスクレイアウトのカスタマイズ

デフォルトでは、セキュリティーが強化されたイメージのサイズは 20 GB で、事前定義されたパーティショニングサイズを使用します。ただし、オーバークラウドのコンテナーイメージを収容するには、パーティショニングレイアウトを変更する必要があります。以降のセクションで説明する手順を実施して、イメージのサイズを 40 GB に増やします。より厳密にご自分のニーズに合わせるために、パーティショニングレイアウトやディスクのサイズを変更することができます。

パーティショニングレイアウトとディスクサイズを変更するには、以下の手順に従ってください。

  • DIB_BLOCK_DEVICE_CONFIG 環境変数を使用してパーティショニングスキーマを変更します。
  • DIB_IMAGE_SIZE 環境変数を更新して、イメージのグローバルサイズを変更します。

20.6. パーティショニングスキーマの変更

パーティショニングスキーマを編集して、パーティショニングサイズを変更したり、新規パーティションの作成や既存のパーティションの削除を行うことができます。新規パーティショニングスキーマは以下の環境変数で定義することができます。

$ export DIB_BLOCK_DEVICE_CONFIG='<yaml_schema_with_partitions>'

以下の YAML 構成は、オーバークラウドのコンテナーイメージをプルするのに十分なスペースを提供する、論理ボリュームの変更後のパーティショニングレイアウトを示しています。

export DIB_BLOCK_DEVICE_CONFIG='''
- local_loop:
    name: image0
- partitioning:
    base: image0
    label: mbr
    partitions:
      - name: root
        flags: [ boot,primary ]
        size: 40G
- lvm:
    name: lvm
    base: [ root ]
    pvs:
        - name: pv
          base: root
          options: [ "--force" ]
    vgs:
        - name: vg
          base: [ "pv" ]
          options: [ "--force" ]
    lvs:
        - name: lv_root
          base: vg
          extents: 23%VG
        - name: lv_tmp
          base: vg
          extents: 4%VG
        - name: lv_var
          base: vg
          extents: 45%VG
        - name: lv_log
          base: vg
          extents: 23%VG
        - name: lv_audit
          base: vg
          extents: 4%VG
        - name: lv_home
          base: vg
          extents: 1%VG
- mkfs:
    name: fs_root
    base: lv_root
    type: xfs
    label: "img-rootfs"
    mount:
        mount_point: /
        fstab:
            options: "rw,relatime"
            fsck-passno: 1
- mkfs:
    name: fs_tmp
    base: lv_tmp
    type: xfs
    mount:
        mount_point: /tmp
        fstab:
            options: "rw,nosuid,nodev,noexec,relatime"
            fsck-passno: 2
- mkfs:
    name: fs_var
    base: lv_var
    type: xfs
    mount:
        mount_point: /var
        fstab:
            options: "rw,relatime"
            fsck-passno: 2
- mkfs:
    name: fs_log
    base: lv_log
    type: xfs
    mount:
        mount_point: /var/log
        fstab:
            options: "rw,relatime"
            fsck-passno: 3
- mkfs:
    name: fs_audit
    base: lv_audit
    type: xfs
    mount:
        mount_point: /var/log/audit
        fstab:
            options: "rw,relatime"
            fsck-passno: 4
- mkfs:
    name: fs_home
    base: lv_home
    type: xfs
    mount:
        mount_point: /home
        fstab:
            options: "rw,nodev,relatime"
            fsck-passno: 2
'''

サンプルの YAML コンテンツをイメージのパーティションスキーマのベースとして使用します。パーティションサイズとレイアウトを必要に応じて変更します。

注記

デプロイメント後にパーティションサイズを 変更することはできない ので、イメージ用に正しいパーティションサイズを定義する必要があります。

20.7. イメージサイズの変更

変更後のパーティショニングスキーマの合計は、デフォルトのディスクサイズ (20 GB) を超える可能性があります。そのような場合には、イメージサイズを変更しなければならない場合があります。イメージサイズを変更するには、イメージを作成する設定ファイルを編集します。

/usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-python3.yaml のコピーを作成します。

# cp /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-python3.yaml \
/home/stack/overcloud-hardened-images-python3-custom.yaml

設定ファイルで DIB_IMAGE_SIZE を編集して、必要な値に調整します。

...

environment:
DIB_PYTHON_VERSION: '3'
DIB_MODPROBE_BLACKLIST: 'usb-storage cramfs freevxfs jffs2 hfs hfsplus squashfs udf vfat bluetooth'
DIB_BOOTLOADER_DEFAULT_CMDLINE: 'nofb nomodeset vga=normal console=tty0 console=ttyS0,115200 audit=1 nousb'
DIB_IMAGE_SIZE: '40' 1
COMPRESS_IMAGE: '1'
1
この値は、新しいディスクサイズの合計に応じて調整してください。

このファイルを保存します。

重要

オーバークラウドをデプロイする際に、director はオーバークラウドイメージの RAW バージョンを作成します。これは、アンダークラウドに、その RAW イメージを収容するのに十分な空き容量がなければならないことを意味します。たとえば、セキュリティーが強化されたイメージのサイズを 40 GB に設定した場合には、アンダークラウドのハードディスクに 40 GB の空き容量が必要となります。

重要

director が物理ディスクにイメージを書き込む際に、ディスクの最後に 64 MB のコンフィグドライブ一次パーティションが作成されます。完全なディスクイメージを作成する場合には、物理ディスクをこの追加パーティションを収容することのできるサイズにしてください。

20.8. 完全なディスクイメージのビルド

環境変数を設定してイメージをカスタマイズした後には、openstack overcloud image build コマンドを使用してイメージを作成します。

手順

  1. 必要なすべての設定ファイルを指定して、openstack overcloud image build コマンドを実行します。

    # openstack overcloud image build \
    --image-name overcloud-hardened-full \
    --config-file /home/stack/overcloud-hardened-images-python3-custom.yaml \ 1
    --config-file /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-rhel8.yaml
    1
    これが、新しいディスクサイズを指定したカスタムの設定ファイルです。異なるカスタムディスクサイズを 使用していない 場合には、代わりに元の /usr/share/openstack-tripleo-common/image-yaml/overcloud-hardened-images-python3.yaml ファイルを使用してください。

    このコマンドにより、必要なセキュリティー機能がすべて含まれた、overcloud-hardened-full.qcow2 という名前のイメージが作成されます。

20.9. 完全なディスクイメージのアップロード

OpenStack Image (glance) サービスにイメージをアップロードして、Red Hat OpenStack Platform director から使用を開始します。セキュリティーが強化されたイメージをアップロードするには、以下の手順を実施してください。

  1. 新たに生成したイメージの名前を変更し、images ディレクトリーに移動します。

    # mv overcloud-hardened-full.qcow2 ~/images/overcloud-full.qcow2
  2. オーバークラウドの古いイメージをすべて削除します。

    # openstack image delete overcloud-full
    # openstack image delete overcloud-full-initrd
    # openstack image delete overcloud-full-vmlinuz
  3. 新規オーバークラウドイメージをアップロードします。

    # openstack overcloud image upload --image-path /home/stack/images --whole-disk

既存のイメージをセキュリティーが強化されたイメージに置き換える場合は、--update-existing フラグを使用します。このフラグを使用することで、元の overcloud-full イメージがセキュリティーの強化された新しいイメージに書き換えられます。

第21章 直接デプロイの設定

ノードをプロビジョニングする場合、director は iSCSI マウントにオーバークラウドのベースオペレーティングシステムのイメージをマウントし、そのイメージを各ノードのディスクにコピーします。直接デプロイ とは、ディスクイメージを HTTP の場所から直接ベアメタルノード上のディスクに書き込む代替方法です。

21.1. アンダークラウドへの直接デプロイインターフェースの設定

iSCSI デプロイインターフェースがデフォルトのデプロイインターフェースです。ただし、直接デプロイインターフェースを有効にして、イメージを HTTP の保管場所からターゲットディスクにダウンロードすることができます。

注記

オーバークラウドノードのメモリー tmpfs には、少なくとも 6 GB の RAM が必要です。

手順

  1. カスタム環境ファイル /home/stack/undercloud_custom_env.yaml を作成または変更して、IronicDefaultDeployInterface を指定します。

    parameter_defaults:
      IronicDefaultDeployInterface: direct
  2. デフォルトでは、各ノードの Bare Metal サービス (ironic) エージェントは、HTTP リンク経由で Object Storage サービス (swift) に保管されているイメージを取得します。なお、Ironic は、ironic-conductor HTTP サーバーを使用して、このイメージを直接ノードにストリーミングすることもできます。イメージを提供するサービスを変更するには、/home/stack/undercloud_custom_env.yaml ファイルの IronicImageDownloadSourcehttp に設定します。

    parameter_defaults:
      IronicDefaultDeployInterface: direct
      IronicImageDownloadSource: http
  3. カスタム環境ファイルを undercloud.conf ファイルの DEFAULT セクションに追加します。

    custom_env_files = /home/stack/undercloud_custom_env.yaml
  4. アンダークラウドのインストールを実施します。

    $ openstack undercloud install

第22章 仮想コントロールプレーンの作成

本章では、Red Hat OpenStack Platform および Red Hat Virtualization を使用してコントロールプレーンを仮想化する方法について説明します。

22.1. 仮想コントロールプレーン

仮想コントロールプレーンは、ベアメタルではなく仮想マシン (VM) 上にあるコントロールプレーンです。仮想コントロールプレーンを使用することで、コントロールプレーンに必要なベアメタルマシンの数を減らすことができます。

Red Hat Virtualization を使用して、オーバークラウドの Red Hat OpenStack Platform コントロールプレーンを仮想化することができますできます。そのためには、コントロールプレーンノードとして仮想コントローラーをデプロイします。OpenStack Platform director は、Red Hat Virtualization のクラスターにデプロイされたコントローラーノードを使用したオーバークラウドのプロビジョニングをサポートします。

注記

仮想コントローラーノードは、Red Hat Virtualization 上でのみサポートされます。

仮想コントロールプレーンをデプロイするには、Red Hat Virtualization 上の仮想マシンで実行されているコントローラーノードならびにベアメタル上のコンピュートおよびストレージノードにより、オーバークラウドを構築します。以下に示すアーキテクチャーの概念図を参照してください。

注記

Red Hat は、Red Hat Virtualization 上の仮想アンダークラウドをサポートします。アンダークラウドも Red Hat Virtualization 上にインストールすることを推奨します。

仮想コントロールプレーンのアーキテクチャー

仮想コントロールプレーンのアーキテクチャー

OpenStack Bare Metal Provisioning (ironic) サービスには、Red Hat Virtualization の仮想マシン用ドライバー staging-ovirt が含まれています。このドライバーにより、Red Hat Virtualization 環境内の仮想ノードを管理することができます。このドライバーを使用して、Red Hat Virtualization 環境内の仮想マシンとしてオーバークラウドのコントローラーをデプロイします。

Red Hat OpenStack Platform オーバークラウドのコントロールプレーンを仮想化するメリット

  • ホットプラグおよびホットアンプラグを使用して動的に仮想コントローラーにリソースを割り当てて、必要に応じて CPU およびメモリーをスケーリングすることができます。これにより、ダウンタイムを防ぎ、プラットフォームの規模が拡大するのに合わせて容易に能力を増大することができます。
  • 同じ Red Hat Virtualization のクラスターに追加のインフラストラクチャー仮想マシンをデプロイすることができるので、データセンターのサーバーフットプリントを最小限に抑え、物理ノードの効率を最大限に引き出すことができます。
  • コンポーザブルロールを使用してより複雑な Red Hat OpenStack Platform コントロールプレーンを定義することができるので、コントロールプレーンの特定コンポーネントにリソースを割り当てることができます。
  • 仮想マシンのライブマイグレーション機能を活用し、サービスを中断せずにシステムをメンテナンスすることができます。
  • Red Hat Virtualization がサポートするサードパーティーまたはカスタムツールを統合することができます。

Red Hat OpenStack Platform オーバークラウドのコントロールプレーンを仮想化する際の制限

  • 仮想 Ceph Storage ノードおよびコンピュートノードはサポートされません。
  • ファイバーチャネルを使用するバックエンドについては、Block Storage (cinder) の image-to-volume はサポートされません。Red Hat Virtualization は N_Port ID の仮想化 (NPIV) をサポートしません。したがって、LUN をストレージバックエンドからコントローラー (cinder-volume がデフォルトで実行される) にマッピングする必要のある Block Storage (cinder) ドライバーは機能しません。Red Hat では、cinder-volume のロールを仮想コントローラーに含めるのではなく、専用のロールとして作成することを推奨します。そのための詳細な手順は、『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照してください。

22.2. Red Hat Virtualization ドライバーを使用した仮想コントローラーのプロビジョニング

前提条件

  • Intel 64 または AMD64 CPU 拡張機能のサポートがある 64 ビットの x86 プロセッサー。
  • Red Hat Virtualization がインストールされている。詳しくは Red Hat Virtualization ドキュメントスイート を参照してください。
  • director を使用して Red Hat OpenStack Platform がインストールされ、設定されている。詳しくは、パートI「director のインストールと設定」を参照してください。
  • 仮想コントローラーノードが用意されている。仮想コントローラーノードの要件は、ベアメタルのコントローラーノードの場合と同じです。詳しい情報は、「コントローラーノードの要件」を参照してください。
  • オーバークラウドのコンピュートノードおよびストレージノードとして使用するベアメタルノードが用意されている。ハードウェアの仕様については、「コンピュートノードの要件」および「Ceph Storage ノードの要件」を参照してください。
  • 論理ネットワークが作成され、クラスターまたはホストネットワークで複数ネットワークによるネットワーク分離を使用する用意ができている。詳しくは、『Red Hat Virtualization Administration Guide』の「Logical Networks」を参照してください。

推奨事項

  • パフォーマンスのボトルネックを防ぐために、コンポーザブルロールを使用しデータプレーンサービスをベアメタルのコントローラーノード上に維持します。
  • 各ノードの内部 BIOS クロックを UTC に設定します。タイムゾーンオフセットを適用する前に hwclock が BIOS クロックを同期すると、ファイルのタイムスタンプに未来の日時が設定されていました。この設定により、この問題を防ぐことができます。
  • POWER (ppc64le) ハードウェアにオーバークラウドのコンピュートノードをデプロイするには、「Red Hat OpenStack Platform for POWER」を参照してください。

手順

  1. undercloud .conf 設定ファイルの enabled_hardware_typesstaging-ovirt ドライバーを追加して、director アンダークラウドでこのドライバーを有効にします。

    enabled_hardware_types = ipmi,redfish,ilo,idrac,staging-ovirt
  2. アンダークラウドに staging-ovirt ドライバーが含まれることを確認します。

    (undercloud) [stack@undercloud ~]$ openstack baremetal driver list

    以下の結果が表示されるはずです。

     +---------------------+-----------------------+
     | Supported driver(s) | Active host(s)        |
     +---------------------+-----------------------+
     | idrac               | localhost.localdomain |
     | ilo                 | localhost.localdomain |
     | ipmi                | localhost.localdomain |
     | pxe_drac            | localhost.localdomain |
     | pxe_ilo             | localhost.localdomain |
     | pxe_ipmitool        | localhost.localdomain |
     | redfish             | localhost.localdomain |
     | staging-ovirt       | localhost.localdomain |
  3. オーバークラウドノードの定義テンプレート (例: nodes.json) で Red Hat Virtualization がホストする仮想マシンを指定して、それらの仮想マシンを director に登録します。詳しくは、「オーバークラウドノードの登録」を参照してください。以下のキー:値のペアを使用して、オーバークラウドでデプロイする仮想マシンの特性を定義します。

    キー

    pm_type

    oVirt/RHV 仮想マシン用の OpenStack Bare Metal Provisioning (ironic) サービスドライバー staging-ovirt に設定します。

    pm_user

    Red Hat Virtualization Manager のユーザー名に設定します。

    pm_password

    Red Hat Virtualization Manager のパスワードに設定します。

    pm_addr

    Red Hat Virtualization Manager サーバーのホスト名または IP に設定します。

    pm_vm_name

    コントローラーが作成される Red Hat Virtualization Manager の仮想マシンの名前に設定します。

    以下に例を示します。

    {
          "nodes": [
              {
                  "name":"osp13-controller-0",
                  "pm_type":"staging-ovirt",
                  "mac":[
                      "00:1a:4a:16:01:56"
                  ],
                  "cpu":"2",
                  "memory":"4096",
                  "disk":"40",
                  "arch":"x86_64",
                  "pm_user":"admin@internal",
                  "pm_password":"password",
                  "pm_addr":"rhvm.example.com",
                  "pm_vm_name":"{vernum}-controller-0",
                  "capabilities": "profile:control,boot_option:local"
              },
      }

    Red Hat Virtualization Host ごとに 1 つのコントローラーを設定します。

  4. Red Hat Virtualization でアフィニティーグループを「ソフトネガティブアフィニティー」に設定し、高可用性がコントローラー用仮想マシンに実装されるようにします。詳しくは、『Red Hat Virtualization Virtual Machine Management Guide』の「Affinity Groups」を参照してください。
  5. Red Hat Virtualization Manager のインターフェースを使用して、それぞれの VLAN をコントローラー用仮想マシンの個別の論理仮想 NIC にマッピングします。
  6. コントローラー用仮想マシンにアタッチされたネットワークで、MAC スプーフィングフィルターを無効にします。そのためには、director およびコントローラー用仮想マシンの仮想 NIC で no_filter を設定し、仮想マシンを再起動します。詳細な情報は、『Red Hat Virtualization Administration Guide』の「Virtual Network Interface Cards」を参照してください。
  7. オーバークラウドをデプロイして、新しい仮想コントローラーノードを環境に追加します。

    (undercloud) [stack@undercloud ~]$ openstack overcloud deploy --templates

パート V. トラブルシューティングとヒント

第23章 director のエラーに関するトラブルシューティング

director プロセスの特定の段階で、エラーが発生する可能性があります。本項では、典型的な問題の診断について説明します。

23.1. ノードの登録に関するトラブルシューティング

ノード登録における問題は、通常ノードの情報が間違っていることが原因で発生します。このような場合には、ノードの情報が含まれるテンプレートファイルを検証して、インポートされたノードの情報を修正します。

手順

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

    $ source ~/stackrc
  2. --validate-only オプションを指定して、ノードのインポートコマンドを実行します。このオプションを指定した場合には、インポートを実施せずにノードのテンプレートを検証します。

    (undercloud) $ openstack overcloud node import --validate-only ~/nodes.json
    Waiting for messages on queue 'tripleo' with no timeout.
    
    Successfully validated environment file
  3. インポートしたノードの誤った情報を修正するには、openstack baremetal コマンドを実行してノードの情報を更新します。ネットワーク設定の詳細を変更する方法を、以下の例に示します。

    1. インポートしたノードに割り当てられたポートの UUID を特定します。

      $ source ~/stackrc
      (undercloud) $ openstack baremetal port list --node [NODE UUID]
    2. MAC アドレスを更新します。

      (undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]
    3. ノードの新しい IPMI アドレスを設定します。

      (undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]

23.2. ハードウェアのイントロスペクションに関するトラブルシューティング

イントロスペクションのプロセスは最後まで実行する必要があります。ただし、イントロスペクション ramdisk が応答しない場合には、ironic-inspector がデフォルトの 1 時間が経過した後にタイムアウトします。イントロスペクション ramdisk にバグがあることを示している可能性もありますが、通常は環境の設定ミス (特に、BIOS のブート設定) によりこのタイムアウトが発生します。

以下の手順で、環境設定が間違っている場合の典型的なシナリオ、および診断/解決方法に関するアドバイスについて説明します。

手順

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

    $ source ~/stackrc
  2. director は OpenStack Object Storage (swift) を使用して、イントロスペクションプロセス中に取得したハードウェアデータを保存します。このサービスが稼働していない場合には、イントロスペクションは失敗する場合があります。以下のコマンドを実行して、OpenStack Object Storage に関連したサービスをすべてチェックし、このサービスが稼働中であることを確認します。

    (undercloud) $ sudo systemctl list-units tripleo_swift*
  3. ノードが manageable の状態であることを確認します。イントロスペクションは、デプロイメント用を意味する available の状態のノードを検査しません。その場合には、イントロスペクションの前にノードの状態を manageable に変更します。

    (undercloud) $ openstack baremetal node manage [NODE UUID]
  4. イントロスペクション ramdisk への一時的なアクセスを設定します。一時パスワードまたは SSH 鍵のいずれかを指定して、イントロスペクションのデバッグ中にノードにアクセスすることができます。ramdisk へのアクセスを設定するには、以下の手順を実施します。

    1. 一時パスワードを指定して openssl passwd -1 コマンドを実行し、MD5 ハッシュを生成します。

      (undercloud) $ openssl passwd -1 mytestpassword
      $1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/
    2. /var/lib/ironic/httpboot/inspector.ipxe ファイルを編集し、kernel で始まる行を特定し、rootpwd パラメーターおよび MD5 ハッシュを追記します。以下に例を示します。

      kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk rootpwd="$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/" selinux=0

      あるいは、sshkey パラメーターに公開 SSH 鍵 を追加します。

      注記

      rootpwd および sshkey パラメーターには、いずれも引用符を含めます。

  5. ノード上でイントロスペクションを実行します。

    (undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

    --provide オプションを使用すると、イントロスペクションの完了時にノードの状態が available に変わります。

  6. dnsmasq ログでノードの IP アドレスを特定します。

    (undercloud) $ sudo tail -f /var/log/containers/ironic-inspector/dnsmasq.log
  7. エラーが発生する場合には、root ユーザーおよび一時アクセス用の詳細を使用してノードにアクセスします。

    $ ssh root@192.168.24.105

    イントロスペクション中にノードにアクセスすると、診断コマンドを実行してイントロスペクションの失敗に関するトラブルシューティングを行うことができます。

  8. イントロスペクションのプロセスを停止するには、以下のコマンドを実行します。

    (undercloud) $ openstack baremetal introspection abort [NODE UUID]

    プロセスがタイムアウトするまで待つことも可能です。

    注記

    イントロスペクションの最初の中止後、OpenStack Platform director は実行を 3 回試みます。イントロスペクションを完全に中止するには、それぞれの試行時に openstack baremetal introspection abort コマンドを実行します。

23.3. ワークフローおよび実行に関するトラブルシューティング

OpenStack Workflow (mistral) サービスは、複数の OpenStack タスクをワークフローにグループ化します。Red Hat OpenStack Platform は、これらのワークフローセットを使用して、director 全体を通じて共通の機能を実行します。これには、ベアメタルノードの制御、検証、プラン管理、およびオーバークラウドのデプロイメントが含まれます。

たとえば openstack overcloud deploy コマンドを実行すると、OpenStack Workflow サービスは 2 つのワークフローを実行します。最初のワークフローは、デプロイメントプランをアップロードします。

Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated

2 つ目のワークフローは、オーバークラウドのデプロイメントを開始します。

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...

OpenStack Workflow サービスは、以下のオブジェクトを使用してワークフローを追跡します。

アクション
関連タスクが実行される際に OpenStack が実施する特定の指示。これには、シェルスクリプトの実行や HTTP リクエストの実行などが含まれます。OpenStack の一部のコンポーネントには、OpenStack Workflow が使用するアクションが組み込まれています。
タスク
実行するアクションと、アクションの実行後の結果を定義します。これらのタスクには通常、アクションまたはアクションに関連付けられたワークフローが含まれます。タスクが完了したら、ワークフローは、タスクが成功したか否かによって、別のタスクに指示を出します。
ワークフロー
グループ化されて特定の順番で実行されるタスクのセット。
実行
実行する特定のアクション、タスク、またはワークフローを定義します。

また、OpenStack Workflow では、実行が確実にログとして記録されるので、特定のコマンドが失敗した場合に問題を特定しやすくなります。たとえば、ワークフローの実行に失敗した場合には、どの部分で失敗したかを特定することができます。

手順

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

    $ source ~/stackrc
  2. 失敗した状態 (ERROR) のワークフローの実行を一覧表示します。

    (undercloud) $ openstack workflow execution list | grep "ERROR"
  3. 失敗したワークフロー実行の UUID を取得して (例: dffa96b0-f679-4cd2-a490-4769a3825262)、実行とその出力を表示します。

    (undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
    (undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262
  4. これらのコマンドにより、実行に失敗したタスクに関する情報が返されます。openstack workflow execution show コマンドは、実行に使用したワークフローも表示します (例: tripleo.plan_management.v1.publish_ui_logs_to_swift)。以下のコマンドを使用して完全なワークフロー定義を表示することができます。

    (undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift

    これは、特定のタスクがワークフローのどの部分で発生するかを特定する際に便利です。

  5. 同様のコマンド構文を使用して、アクションの実行とその結果を表示します。

    (undercloud) $ openstack action execution list
    (undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
    (undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886

    これは、問題を引き起こす具体的なアクションを特定する際に便利です。

23.4. オーバークラウドの作成およびデプロイメントに関するトラブルシューティング

オーバークラウドの初回作成は、OpenStack Orchestration (heat) サービスにより実行されます。オーバークラウドのデプロイメントに失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。

手順

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

    $ source ~/stackrc
  2. デプロイメントのエラー発生ステップ確認コマンドを実行します。

    $ openstack overcloud failures
  3. 以下のコマンドを実行して、エラーの詳細を表示します。

    (undercloud) $ openstack stack failures list <OVERCLOUD_NAME> --long

    <OVERCLOUD_NAME> をご自分のオーバークラウドの名前に置き換えてください。

  4. 以下のコマンドを実行し、エラーが発生したスタックを特定します。

    (undercloud) $ openstack stack list --nested --property status=FAILED

23.5. ノードのプロビジョニングに関するトラブルシューティング

OpenStack Orchestration (heat) サービスは、プロビジョニングプロセスを制御します。ノードのプロビジョニングに失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、問題の診断を行います。

手順

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

    $ source ~/stackrc
  2. Bare Metal サービスをチェックして、全登録ノードおよびそれらの現在の状態を表示します。

    (undercloud) $ openstack baremetal node list
    
    +----------+------+---------------+-------------+-----------------+-------------+
    | UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
    +----------+------+---------------+-------------+-----------------+-------------+
    | f1e261...| None | None          | power off   | available       | False       |
    | f0b8c1...| None | None          | power off   | available       | False       |
    +----------+------+---------------+-------------+-----------------+-------------+

    プロビジョニングに使用できるすべてのノードは、以下の状態でなければなりません。

    • Maintenance: False に設定。
    • Provision State: プロビジョニングの前に available に設定。

    プロビジョニングに失敗する典型的なシナリオの概要を、以下の表に示します。

問題原因ソリューション

Maintenance が自動的に True に設定される。

director がノードの電源管理にアクセスすることができない。

ノードの電源管理の認証情報を確認します。

Provision Stateavailable に設定されているが、ノードがプロビジョニングされない。

ベアメタルのデプロイメントが開始される前に問題が生じた。

プロファイルおよびフレーバーのマッピングを含め、ノードの詳細を確認します。ノードのハードウェア詳細がフレーバーの要件を満たしていることを確認します。

Provision State がノードの wait call-back に設定される。

このノードのプロビジョニングプロセスがまだ終了していない。

このステータスが変わるまで待ちます。あるいは、ノードの仮想コンソールに接続し、出力を確認します。

Provision State および Power State はそれぞれ active および power on だが、ノードが応答しない。

ノードのプロビジョニングは正常に終了したが、デプロイメント後の設定ステップで問題が生じている。

ノード設定のプロセスを診断します。ノードの仮想コンソールに接続し、出力を確認します。

Provision Stateerror または deploy failed である。

ノードのプロビジョニングに失敗している。

openstack baremetal node show コマンドを使用してベアメタルノードの詳細を表示し、エラーに関する説明が含まれる last_error フィールドを確認します。

23.6. プロビジョニング時の IP アドレス競合に関するトラブルシューティング

対象のホストにすでに使用中の IP アドレスが割り当てられている場合には、イントロスペクションおよびデプロイメントのタスクは失敗します。このタスク失敗を防ぐには、プロビジョニングネットワークのポートスキャンを実行して、検出の IP アドレス範囲とホストの IP アドレス範囲が解放されているかどうかを確認します。

手順

  1. nmap をインストールします。

    $ sudo yum install nmap
  2. nmap を使用して、アクティブなアドレスの IP アドレス範囲をスキャンします。この例では、192.168.24.0/24 の範囲をスキャンします。この値は、プロビジョニングネットワークの IP サブネットに置き換えてください (CIDR 表記のビットマスク)。

    $ sudo nmap -sn 192.168.24.0/24
  3. nmap スキャンの出力を確認します。たとえば、アンダークラウドおよびサブネット上に存在するその他のホストの IP アドレスを確認する必要があります。

    $ sudo nmap -sn 192.168.24.0/24
    
    Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
    Nmap scan report for 192.168.24.1
    Host is up (0.00057s latency).
    Nmap scan report for 192.168.24.2
    Host is up (0.00048s latency).
    Nmap scan report for 192.168.24.3
    Host is up (0.00045s latency).
    Nmap scan report for 192.168.24.5
    Host is up (0.00040s latency).
    Nmap scan report for 192.168.24.9
    Host is up (0.00019s latency).
    Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds

    アクティブな IP アドレスが undercloud.conf の IP アドレス範囲と競合している場合には、オーバークラウドノードのイントロスペクションまたはデプロイを実行する前に、IP アドレスの範囲を変更するか、IP アドレスを解放するかのいずれかを行う必要があります。

23.7. 「No Valid Host Found」エラーに関するトラブルシューティング

/var/log/nova/nova-conductor.log に、以下のエラーが含まれる場合があります。

NoValidHost: No valid host was found. There are not enough hosts available.

このエラーは、Compute Scheduler が新規インスタンスをブートするのに適したベアメタルノードを検出できない場合に発生します。通常これは、Compute サービスが検出を想定しているリソースと、Bare Metal サービスが Compute に通知するリソースが、一致していないことを意味します。以下の手順で、その確認方法を説明します。

手順

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

    $ source ~/stackrc
  2. ノードのイントロスペクションが成功したことを確認します。イントロスペクションが失敗する場合には、各ノードに必要な Ironic ノードのプロパティーが含まれていることを確認してください。

    (undercloud) $ openstack baremetal node show [NODE UUID]

    properties JSON フィールドの cpuscpu_archmemory_mblocal_gb キーに有効な値が指定されていることを確認してください。

  3. ノードにマッピングされた Compute フレーバーを確認します。

    (undercloud) $ openstack flavor show [FLAVOR NAME]

    必要なノード数のノードプロパティーを超えないようにしてください。

  4. openstack baremetal node list コマンドを実行して、available 状態のノードが十分にあることを確認します。ノードの状態が manageable の場合には、通常イントロスペクションに失敗します。
  5. openstack baremetal node list コマンドを実行し、ノードがメンテナンスモードに設定されていないことを確認します。ノードが自動的にメンテナンスモードに切り替わる場合には、電源管理の認証情報が間違っていることが一般的な原因として考えられます。電源管理の認証情報を確認し、メンテナンスモードを解除します。

    (undercloud) $ openstack baremetal node maintenance unset [NODE UUID]
  6. プロファイルの自動タグ付けを使用している場合には、各フレーバー/プロファイルに対応するノードが十分に存在することを確認します。ノードで openstack baremetal node show コマンドを実行し、properties フィールドの capabilities キーを確認します。たとえば、Compute ロールのタグを付けられたノードには、profile:compute が含まれているはずです。
  7. イントロスペクションの後に Bare Metal から Compute にノードの情報が反映されるには、若干時間がかかります。ただし、一部のステップを手動で実行した場合には、短時間ですが、Nova でノードが利用できなくなる場合があります。以下のコマンドを使用して、システム内の合計リソースをチェックします。

    (undercloud) $ openstack hypervisor stats show

23.8. オーバークラウドの設定に関するトラブルシューティング

OpenStack Platform director は、Ansible を使用してオーバークラウドを設定します。以下の手順で、エラーが発生した際にオーバークラウドの Ansible Playbook (config-download) を診断する方法について説明します。

手順

  1. stack ユーザーが アンダークラウド 上の /var/lib/mistral ディレクトリー内のファイルにアクセスできるようにします。

    $ sudo setfacl -R -m u:stack:rwx /var/lib/mistral

    このコマンドを実行しても、mistral ユーザーのディレクトリーへのアクセス権限は維持されます。

  2. config-download ファイルの作業ディレクトリーに移動します。通常これは /var/lib/mistral/overcloud/ です。

    $ cd /var/lib/mistral/overcloud/
  3. ansible.log ファイルを確認し、異常のあった場所を探します。

    $ less ansible.log

    異常のあったステップを書き留めます。

  4. 作業ディレクトリー内の config-download Playbook で異常のあったステップを探し、実行していたアクションを特定します。

23.9. コンテナーの設定に関するトラブルシューティング

OpenStack Platform director は、paunch を使用してコンテナーを起動し、podman を使用してコンテナーを管理し、また puppet を使用してコンテナー設定を作成します。以下の手順で、エラーが発生した場合にコンテナーを診断する方法について説明します。

ホストへのアクセス

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

    $ source ~/stackrc
  2. 障害の発生したコンテナーがあるノードの IP アドレスを取得します。

    (undercloud) $ openstack server list
  3. ノードにログインします。

    (undercloud) $ ssh heat-admin@192.168.24.60
  4. root ユーザーに変更します。

    $ sudo -i

障害が発生したコンテナーの識別

  1. すべてのコンテナーを表示します。

    $ podman ps --all

    障害の発生したコンテナーを特定します。障害の発生したコンテナーは、通常ゼロ以外のステータスで終了します。

コンテナーログの確認

  1. 各コンテナーは、主要プロセスからの標準出力を保持します。この出力をログとして使用し、コンテナー実行時に実際に何が発生したのかを特定するのに役立てます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを使用します。

    $ sudo podman logs keystone

    多くの場合、このログにコンテナー障害の原因に関する情報が含まれます。

  2. ホストには、失敗したサービスの stdout ログも保持されます。stdout ログは、/var/log/containers/stdouts/ に保存されます。たとえば、障害の発生した keystone コンテナーのログを確認するには、以下のコマンドを使用します。

    $ cat /var/log/containers/stdouts/keystone.log

コンテナーの検査

状況によっては、コンテナーに関する情報を検証する必要がある場合があります。たとえば、以下のコマンドを使用して keystone コンテナーのデータを確認します。

$ sudo podman inspect keystone

このコマンドにより、ローレベルの設定データが含まれた JSON オブジェクトが返されます。その出力を jq コマンドにパイプして、特定のデータを解析することが可能です。たとえば、keystone コンテナーのマウントを確認するには、以下のコマンドを実行します。

$ sudo podman inspect keystone | jq .[0].Mounts

--format オプションを使用して、データを単一行に解析することもできます。これは、コンテナーデータのセットに対してコマンドを実行する場合に役立ちます。たとえば、keystone コンテナーを実行するのに使用するオプションを再生成するには、以下のように inspect コマンドに --format オプションを指定して実行します。

$ sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}:{{ join .Options "," }}{{end}} -ti {{.Config.Image}}' keystone
注記

--format オプションは、Go 構文を使用してクエリーを作成します。

これらのオプションを podman run コマンドと共に使用して、トラブルシューティング目的のコンテナーを再度作成します。

$ OPTIONS=$( sudo podman inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo podman run --rm $OPTIONS /bin/bash

コンテナー内でのコマンドの実行

状況によっては、特定の Bash コマンドでコンテナー内の情報を取得する必要がある場合があります。このような場合には、以下の podman コマンドを使用して、稼働中のコンテナー内でコマンドを実行します。たとえば、podman exec コマンドを実行して、keystone コンテナー内でコマンドを実行します。

$ sudo podman exec -ti keystone <COMMAND>
注記

-ti オプションを指定すると、コマンドは対話式の擬似ターミナルで実行されます。

<COMMAND> を実行するコマンドに置き換えてください。たとえば、各コンテナーには、サービスの接続を確認するためのヘルスチェックスクリプトがあります。keystone にヘルスチェックスクリプトを実行するには、以下のコマンドを実行します。

$ sudo podman exec -ti keystone /openstack/healthcheck

コンテナーのシェルにアクセスするには、コンテナー内で実行するコマンドとして /bin/bash を使用して podman exec を実行します。

$ sudo podman exec -ti keystone /bin/bash

コンテナーファイルシステムの確認

  1. 障害の発生したコンテナーのファイルシステムを確認するには、podman mount コマンドを実行します。たとえば、障害の発生した keystone コンテナーのファイルシステムを確認するには、以下のコマンドを実行します。

    $ podman mount keystone

    これによりマウント位置が表示され、ファイルシステムの内容を確認することができます。

    /var/lib/containers/storage/overlay/78946a109085aeb8b3a350fc20bd8049a08918d74f573396d7358270e711c610/merged

    これは、コンテナー内の Puppet レポートを確認する際に役立ちます。これらのレポートは、コンテナーのマウント内の var/lib/puppet/ ディレクトリーにあります。

コンテナーのエクスポート

コンテナーに障害が発生した場合には、ファイルの内容を詳細に調べる必要があります。この場合は、コンテナーの全ファイルシステムを tar アーカイブとしてエクスポートすることができます。たとえば、keystone コンテナーのファイルシステムをエクスポートするには、以下のコマンドを実行します。

$ sudo podman export keystone -o keystone.tar

このコマンドにより keystone.tar アーカイブが作成されます。これを抽出して、調べることができます。

23.10. コンピュートノードの異常に関するトラブルシューティング

コンピュートノードは、Compute サービスを使用して、ハイパーバイザーベースの操作を実行します。これは、このサービスを中心にコンピュートノードのメインの診断が行われていることを意味します。

手順

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

    $ source ~/stackrc
  2. 障害が発生したコンピュートノードの IP アドレスを取得します。

    (undercloud) $ openstack server list
  3. ノードにログインします。

    (undercloud) $ ssh heat-admin@192.168.24.60
  4. root ユーザーに変更します。

    $ sudo -i
  5. コンテナーのステータスを表示します。

    $ sudo podman ps -f name=nova_compute
  6. コンピュートノードの主なログファイルは /var/log/containers/nova/nova-compute.log です。コンピュートノードの通信で問題が発生した場合に、通常はこのログが診断を開始するのに適した場所です。
  7. コンピュートノードでメンテナンスを実行する場合には、既存のインスタンスをホストから稼働中のコンピュートノードに移行し、ノードを無効にします。

23.11. SOS レポートの作成

Red Hat に連絡して OpenStack Platform に関するサポートを受ける必要がある場合は、SOS レポート を生成する必要がある場合があります。SOS レポート の作成に関する詳しい説明は、以下のナレッジベースのアーティクルを参照してください。

23.12. ログの場所

以下のログを使用して、トラブルシューティングの際にアンダークラウドとオーバークラウドの情報を割り出します。

表23.1 アンダークラウドおよびオーバークラウドノード両方に関するログ

情報ログの場所

コンテナー化されたサービスに関するログ

/var/log/containers/

コンテナー化されたサービスからの標準出力

/var/log/containers/stdouts

Ansible の設定に関するログ

/var/lib/mistral/overcloud/ansible.log

表23.2 アンダークラウドノードに関する追加のログ

情報ログの場所

openstack overcloud deploy のコマンド履歴

/home/stack/.tripleo/history

アンダークラウドのインストールに関するログ

/home/stack/install-undercloud.log

表23.3 オーバークラウドノードに関する追加のログ

情報ログの場所

cloud-init に関するログ

/var/log/cloud-init.log

高可用性に関するログ

/var/log/pacemaker.log

第24章 アンダークラウドおよびオーバークラウドサービスについてのヒント

本項では、アンダークラウド上の特定の OpenStack サービスのチューニングと管理についてアドバイスを行います。

24.1. データベースのフラッシュ間隔の見直し

一部のサービスは、cron コンテナーを使用してデータベースから古いコンテンツをフラッシュします。

  • OpenStack Identity (keystone): 有効期限が切れたトークンのフラッシュ
  • OpenStack Orchestration (heat): 有効期限が切れて削除されたテンプレートデータのフラッシュ
  • OpenStack Compute (nova): 有効期限が切れて削除されたインスタンスデータのフラッシュ

各サービスのデフォルトのフラッシュ間隔は、以下の表に記載のとおりです。

サービスフラッシュされるデータベースコンテンツデフォルトのフラッシュ間隔

OpenStack Identity (keystone)

有効期限が切れたトークン

1 時間ごと

OpenStack Orchestration (heat)

有効期限が切れて削除されてから 30 日以上経過したテンプレートデータ

毎日

OpenStack Compute (nova)

削除されたインスタンスデータをアーカイブします

毎日

OpenStack Compute (nova)

14 日以上経過したアーカイブデータをフラッシュします

毎日

以下の表には、これらの cron ジョブを制御するパラメーターの概要をまとめています。

表24.1 OpenStack Identity (keystone) の cron パラメーター

パラメーター説明

KeystoneCronTokenFlushMinute

cron ジョブが有効期限の切れたトークンをパージする (Minute)。デフォルト値は 1 です。

KeystoneCronTokenFlushHour

cron ジョブが有効期限の切れたトークンをパージする (Hour)。デフォルト値は * です。

KeystoneCronTokenFlushMonthday

cron ジョブが有効期限の切れたトークンをパージする (Month Day)。デフォルト値は * です。

KeystoneCronTokenFlushMonth

cron ジョブが有効期限の切れたトークンをパージする (Month)。デフォルト値は * です。

KeystoneCronTokenFlushWeekday

cron ジョブが有効期限の切れたトークンをパージする (Week Day)。デフォルト値は * です。

表24.2 OpenStack Orchestration (heat) の cron パラメーター

パラメーター説明

HeatCronPurgeDeletedAge

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Age)。デフォルト値は 30 です。

HeatCronPurgeDeletedAgeType

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Age type)。デフォルト値は days です。

HeatCronPurgeDeletedMinute

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Minute)。デフォルト値は 1 です。

HeatCronPurgeDeletedHour

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Hour)。デフォルト値は 0 です。

HeatCronPurgeDeletedMonthday

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Month Day)。デフォルト値は * です。

HeatCronPurgeDeletedMonth

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Month)。デフォルト値は * です。

HeatCronPurgeDeletedWeekday

cron ジョブが削除済みとマークされかつ $age よりも古いデータベースのエントリーをパージする (Week Day)。デフォルト値は * です。

表24.3 OpenStack Compute (nova) の cron パラメーター

パラメーター

説明

NovaCronArchiveDeleteRowsMaxRows

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Max Rows)。デフォルト値は 100 です。

NovaCronArchiveDeleteRowsPurge

スケジュールされたアーカイブの直後にシャドウテーブルをパージします。デフォルト値は False です。

NovaCronArchiveDeleteRowsMinute

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Minute)。デフォルト値は 1 です。

NovaCronArchiveDeleteRowsHour

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Hour)。デフォルト値は 0 です。

NovaCronArchiveDeleteRowsMonthday

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Month Day)。デフォルト値は * です。

NovaCronArchiveDeleteRowsMonth

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Month)。デフォルト値は * です。

NovaCronArchiveDeleteRowsWeekday

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Week Day)。デフォルト値は * です。

NovaCronArchiveDeleteRowsUntilComplete

cron ジョブが削除されたインスタンスを別のテーブルに移動する (Until complete)。デフォルト値は True です。

NovaCronPurgeShadowTablesAge

cron ジョブがシャドウテーブルをパージする (Age)。シャドウテーブルをパージする際の保持ポリシーを、日数単位で定義します。0 は、シャドウテーブル内のその日以前のデータがパージされることを意味します。デフォルト値は 14 です。

NovaCronPurgeShadowTablesMinute

cron ジョブがシャドウテーブルをパージする (Minute)。デフォルト値は 0 です。

NovaCronPurgeShadowTablesHour

cron ジョブがシャドウテーブルをパージする (Hour)。デフォルト値は 5 です。

NovaCronPurgeShadowTablesMonthday

cron ジョブがシャドウテーブルをパージする (Month Day)。デフォルト値は * です。

NovaCronPurgeShadowTablesMonth

cron ジョブがシャドウテーブルをパージする (Month)。デフォルト値は * です。

NovaCronPurgeShadowTablesWeekday

cron ジョブがシャドウテーブルをパージする (Week Day)。デフォルト値は * です。

これらの間隔を調整するには、該当するサービスの新たなトークンフラッシュ間隔を含む環境ファイルを作成し、そのファイルを undercloud.conf ファイルの custom_env_files パラメーターに追加します。たとえば、OpenStack Identity (keystone) のトークンフラッシュ間隔を 30 分ごとに変更するには、以下のスニペットを使用します。

keystone-cron.yaml

parameter_defaults:
  KeystoneCronTokenFlushMinute: '0/30'

undercloud.yaml

custom_env_files: keystone-cron.yaml

続いて、openstack undercloud install コマンドを再度実行します。

$ openstack undercloud install
注記

これらのパラメーターをオーバークラウドに使用することもできます。詳しい情報は、『オーバークラウドのパラメーター』を参照してください。

24.2. デプロイメントパフォーマンスのチューニング

OpenStack Platform director は、OpenStack Orchestration (heat) を使用してメインのデプロイメントおよびプロビジョニング機能を処理します。heat は一連のワーカーを使用してデプロイメントタスクを実施します。デフォルトのワーカー数を計算する場合、director の heat 設定ではアンダークラウドの合計 CPU スレッド数を 2 で割ります[2]。たとえば、アンダークラウドの CPU のスレッド数が 16 の場合には、デフォルトでは heat は 8 つのワーカーを提供します。デフォルトでは、director の設定に最小および最大のワーカー数も適用されます。

サービス最小値最大値

OpenStack Orchestration (heat)

4

24

ただし、環境ファイルの HeatWorkers パラメーターを使用して、手動でワーカー数を設定することができます。

heat-workers.yaml

parameter_defaults:
  HeatWorkers: 16

undercloud.yaml

custom_env_files: heat-workers.yaml



[2] ここでは、スレッド数とは CPU コア数にハイパースレッディングの値を掛けたものを指します

24.3. コンテナーでの swift-ring-builder の実行

Object Storage (swift) リングを管理するには、サーバーコンテナー内で swift-ring-builder コマンドを使用します。

  • swift_object_server
  • swift_container_server
  • swift_account_server

たとえば、swift オブジェクトリングの情報を表示するには、以下のコマンドを実行します。

$ sudo podman exec -ti -u swift swift_object_server swift-ring-builder /etc/swift/object.builder

アンダークラウドおよびオーバークラウドノードの両方で、このコマンドを実行することができます。

24.4. HAProxy の SSL/TLS 暗号ルールの変更

アンダークラウドで SSL/TLS を有効にした場合には (「director の設定パラメーター」を参照)、HAProxy 設定で使用する SSL/TLS の暗号とルールを強化することをお勧めします。この強化により、POODLE TLS 脆弱性 などの SSL/TLS の脆弱性を回避することができます。

hieradata_override のアンダークラウド設定オプションを使用して、以下の hieradata を設定します。

tripleo::haproxy::ssl_cipher_suite
HAProxy で使用する暗号スイート
tripleo::haproxy::ssl_options
HAProxy で使用する SSL/TLS ルール

たとえば、以下のような暗号およびルールを使用することができます。

  • 暗号: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
  • ルール: no-sslv3 no-tls-tickets

hieradata オーバーライドファイル (haproxy-hiera-overrides.yaml) を作成して、以下の内容を記載します。

tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets
注記

暗号のコレクションは、改行なしで 1 行に記述します。

undercloud.conf ファイルで先程作成した hierradata オーバーライドファイルを使用するように hieradata_override パラメーターを設定してから openstack undercloud install を実行します。

[DEFAULT]
...
hieradata_override = haproxy-hiera-overrides.yaml
...

パート VI. 付録

付録A 電源管理ドライバー

IPMI は、director が電源管理制御に使用する主要な手法ですが、director は他の電源管理タイプもサポートします。この付録には、director がサポートする電源管理機能の一覧が記載されています。ノードを登録する際に (「オーバークラウドノードの登録」を参照)、以下の電源管理設定を使用します。

A.1. Intelligent Platform Management Interface (IPMI)

Baseboard Management Controller (BMC) を使用した標準的な電源管理手法。

pm_type
このオプションを ipmi に設定します。
pm_user; pm_password
IPMI のユーザー名およびパスワード
pm_addr
IPMI コントローラーの IP アドレス
pm_port (オプション)
IPMI コントローラーに接続するためのポート。

A.2. Redfish

Distributed Management Task Force (DMTF) の開発した、IT インフラストラクチャー向け標準 RESTful API。

pm_type
このオプションを redfish に設定します。
pm_user; pm_password
Redfish のユーザー名およびパスワード
pm_addr
Redfish コントローラーの IP アドレス
pm_system_id
システムリソースの正規のパス。このパスには、そのシステムの root サービス、バージョン、パス/一意 ID を含める必要があります。たとえば、/redfish/v1/Systems/CX34R87

A.3. Dell Remote Access Controller (DRAC)

DRAC は、電源管理やサーバー監視などの帯域外 (OOB) リモート管理機能を提供するインターフェースです。

pm_type
このオプションを idrac に設定します。
pm_user; pm_password
DRAC のユーザー名およびパスワード
pm_addr
DRAC ホストの IP アドレス

A.4. Integrated Lights-Out (iLO)

iLO は、電源管理やサーバーのモニタリングを含む帯域外 (OOB) リモート管理機能を提供するインターフェースです。

pm_type
このオプションを ilo に設定します。
pm_user; pm_password
iLO のユーザー名およびパスワード
pm_addr

iLO インターフェースの IP アドレス

  • このドライバーを有効化するには、undercloud.confenabled_hardware_types オプションに ilo を追加してから、openstack undercloud install を再実行します。
  • また director では、iLO 向けに追加のユーティリティーセットが必要です。python-proliantutils パッケージをインストールして openstack-ironic-conductor サービスを再起動します。

    $ sudo yum install python-proliantutils
    $ sudo systemctl restart openstack-ironic-conductor.service
  • 正常にイントロスペクションを実施するためには、HP ノードの ILO ファームウェアバージョンは、最低でも 1.85 (2015 年 5 月 13 日版) でなければなりません。この ILO ファームウェアバージョンを使用するノードで、director は正常にテストされています。
  • 共有 iLO ポートの使用はサポートされません。

A.5. Cisco Unified Computing System (UCS)

Cisco の UCS は、コンピュート、ネットワーク、ストレージのアクセス、仮想化リソースを統合するデータセンタープラットフォームです。このドライバーは、UCS に接続されたベアメタルシステムの電源管理を重視しています。

pm_type
このオプションを cisco-ucs-managed に設定します。
pm_user; pm_password
UCS のユーザー名およびパスワード
pm_addr
UCS インターフェースの IP アドレス
pm_service_profile

使用する UCS サービスプロファイル。通常 org-root/ls-[service_profile_name] の形式を取ります。以下に例を示します。

"pm_service_profile": "org-root/ls-Nova-1"
  • このドライバーを有効にするには、undercloud.confenabled_hardware_types オプションに cisco-ucs-managed を追加してから、openstack undercloud install コマンドを再実行します。
  • また director では、iLO 向けに追加のユーティリティーセットが必要です。python-UcsSdk パッケージをインストールして openstack-ironic-conductor サービスを再起動します。

    $ sudo yum install python-UcsSdk
    $ sudo systemctl restart openstack-ironic-conductor.service

A.6. Fujitsu Integrated Remote Management Controller (iRMC)

Fujitsu の iRMC は、LAN 接続と拡張された機能を統合した Baseboard Management Controller (BMC) です。このドライバーは、iRMC に接続されたベアメタルシステムの電源管理にフォーカスしています。

重要

iRMC S4 以降のバージョンが必要です。

pm_type
このオプションを irmc に設定します。
pm_user; pm_password
iRMC インターフェースのユーザー名とパスワード
pm_addr
iRMC インターフェースの IP アドレス
pm_port (オプション)
iRMC の操作に使用するポート。デフォルトは 443 です。
pm_auth_method (オプション)
iRMC 操作の認証方法。basic または digest を使用します。デフォルトは basic です。
pm_client_timeout (オプション)
iRMC 操作のタイムアウト (秒単位)。デフォルトは 60 秒です。
pm_sensor_method (オプション)

センサーデータの取得方法。ipmitool または scci です。デフォルトは ipmitool です。

  • このドライバーを有効にするには、undercloud.confenabled_hardware_types オプションに irmc を追加してから、openstack undercloud install コマンドを再実行します。
  • センサーデータの取得方法として SCCI を有効にする場合には、追加のユーティリティーセットもインストールする必要があります。python-scciclient パッケージをインストールして、openstack-ironic-conductor サービスを再起動します。

    $ yum install python-scciclient
    $ sudo systemctl restart openstack-ironic-conductor.service

A.7. Red Hat Virtualization

このドライバーにより、RESTful API を介して、Red Hat Virtualization 内の仮想マシンを制御することができるようになります。

pm_type
このオプションを staging-ovirt に設定します。
pm_user; pm_password
Red Hat Virtualization 環境のユーザー名とパスワード。ユーザー名には、認証プロバイダーも含めます。たとえば、admin@internal
pm_addr
Red Hat Virtualization REST API の IP アドレス
pm_vm_name
制御する仮想マシンの名前
mac

ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。

  • このドライバーを有効にするには、undercloud.confenabled_hardware_types オプションに staging-ovirt を追加してから、openstack undercloud install コマンドを再実行します。

A.8. フェイクドライバー

電源管理を持たないベアメタルデバイスを制御するには、「フェイク」ドライバーを使用します。director は登録されたベアメタルデバイスを制御しないので、イントロスペクションおよびデプロイメントの特定の時点で、手動で電源管理操作を実施する必要があります。

重要

このオプションは、テストおよび評価の目的でのみ利用いただけます。Red Hat OpenStack Platform のエンタープライズ環境には推奨していません。

pm_type

このオプションを fake-hardware に設定します。

  • このドライバーは、電源管理を制御しないので、認証情報は使用しません。
  • このドライバーを有効にするには、undercloud.confenabled_hardware_types オプションに fake を追加してから、openstack undercloud install コマンドを再実行します。
  • ノードのイントロスペクションを実行する際には、openstack overcloud node introspect コマンドを実行した後に手動でノードを起動します。
  • オーバークラウドのデプロイ実行時には、ironic node-list コマンドでノードのステータスを確認します。ノードのステータスが deploying から deploy wait-callback に変わるまで待ってから、手動でノードを起動します。
  • オーバークラウドのプロビジョニングプロセスが完了したら、ノードをリブートします。プロビジョニングが完了したかどうかをチェックするには、ironic node-list コマンドでノードのステータスをチェックし、active に変わるのを待ってから、すべてのオーバークラウドノードを手動でリブートします。

付録B Red Hat OpenStack Platform for POWER

Red Hat OpenStack Platform を新規にインストールする際に、オーバークラウドのコンピュートノードを POWER (ppc64le) ハードウェアにデプロイできるようになりました。コンピュートノードのクラスターには、同じアーキテクチャーのシステムを使用するか、x86_64 と ppc64le のシステムを混在させることができます。アンダークラウド、コントローラーノード、Ceph Storage ノード、およびその他のシステムはすべて x86_64 ハードウェアでのみサポートされています。各システムのインストール詳細は、本ガイドのこれまでのセクションで説明しています。

B.1. Ceph Storage

マルチアーキテクチャークラウドにおいて外部 Ceph へのアクセスを設定する場合には、クライアントキーおよびその他の Ceph 固有パラメーターと共に CephAnsiblePlaybook パラメーターを /usr/share/ceph-ansible/site.yml.sample に設定します。

以下に例を示します。

parameter_defaults:
  CephAnsiblePlaybook: /usr/share/ceph-ansible/site.yml.sample
  CephClientKey: AQDLOh1VgEp6FRAAFzT7Zw+Y9V6JJExQAsRnRQ==
  CephClusterFSID: 4b5c8c0a-ff60-454b-a1b4-9747aa737d19
  CephExternalMonHost: 172.16.1.7, 172.16.1.8

B.2. コンポーザブルサービス

一般にコントローラーノードの一部となる以下のサービスは、テクノロジープレビューとしてカスタムロールでの使用が可能です。

  • Cinder
  • Glance
  • Keystone
  • Neutron
  • Swift
注記

Red Hat は、テクノロジープレビューの機能をサポートしていません。

詳しい情報は、『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照してください。以下の例を使用して、上記のサービスをコントローラーノードから専用の ppc64le ノードに移動する方法を説明します。

(undercloud) [stack@director ~]$ rsync -a /usr/share/openstack-tripleo-heat-templates/. ~/templates
(undercloud) [stack@director ~]$ cd ~/templates/roles
(undercloud) [stack@director roles]$ cat <<EO_TEMPLATE >ControllerPPC64LE.yaml
###############################################################################
# Role: ControllerPPC64LE                                                     #
###############################################################################
- name: ControllerPPC64LE
  description: |
    Controller role that has all the controller services loaded and handles
    Database, Messaging and Network functions.
  CountDefault: 1
  tags:
    - primary
    - controller
  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant
  # For systems with both IPv4 and IPv6, you may specify a gateway network for
  # each, such as ['ControlPlane', 'External']
  default_route_networks: ['External']
  HostnameFormatDefault: '%stackname%-controllerppc64le-%index%'
  ImageDefault: ppc64le-overcloud-full
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackendDellPs
    - OS::TripleO::Services::CinderBackendDellSc
    - OS::TripleO::Services::CinderBackendDellEMCUnity
    - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI
    - OS::TripleO::Services::CinderBackendDellEMCVNX
    - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI
    - OS::TripleO::Services::CinderBackendNetApp
    - OS::TripleO::Services::CinderBackendScaleIO
    - OS::TripleO::Services::CinderBackendVRTSHyperScale
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderHPELeftHandISCSI
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronBgpVpnApi
    - OS::TripleO::Services::NeutronSfcApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL2gwAgent
    - OS::TripleO::Services::NeutronL2gwApi
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronLbaasv2Agent
    - OS::TripleO::Services::NeutronLbaasv2Api
    - OS::TripleO::Services::NeutronLinuxbridgeAgent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronML2FujitsuCfab
    - OS::TripleO::Services::NeutronML2FujitsuFossw
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::NeutronVppAgent
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::SkydiveAgent
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftDispersion
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::SwiftStorage
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::OVNMetadataAgent
    - OS::TripleO::Services::Ptp
EO_TEMPLATE
(undercloud) [stack@director roles]$ sed -i~ -e '/OS::TripleO::Services::\(Cinder\|Glance\|Swift\|Keystone\|Neutron\)/d' Controller.yaml
(undercloud) [stack@director roles]$ cd ../
(undercloud) [stack@director templates]$ openstack overcloud roles generate \
    --roles-path roles -o roles_data.yaml \
    Controller Compute ComputePPC64LE ControllerPPC64LE BlockStorage ObjectStorage CephStorage

法律上の通知

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.