director のインストールと使用方法
Red Hat OpenStack Platform 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 つの主要な概念を採用しています。アンダークラウドがオーバークラウドのインストールおよび設定を行います。以降の数セクションで、それぞれの概念について説明します。
1.1. アンダークラウド リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドは、director の主要ノードです。OpenStack をインストールした単一システムで、OpenStack 環境 (オーバークラウド) を構成する OpenStack ノードをプロビジョニング/管理するためのコンポーネントが含まれます。アンダークラウドを形成するコンポーネントは、複数の機能を提供します。
- 環境のプランニング
- アンダークラウドは、ユーザーが特定のノードロールを作成するためのプランニング機能を提供します。アンダークラウドには、コンピュート、コントローラー、さまざまなストレージロールなどのデフォルトのノードセットが含まれるだけでなく、カスタムロールを使用する機能も提供されています。さらに、各ノードロールにどの OpenStack Platform サービスを含めるかを選択でき、新しいノード種別をモデル化するか、独自のホストで特定のコンポーネントを分離する方法を提供します。
- ベアメタルシステムの制御
- アンダークラウドは、各ノードの帯域外管理インターフェース (通常 Intelligent Platform Management Interface (IPMI)) を使用して電源管理機能を制御し、PXE ベースのサービスを使用してハードウェア属性を検出し、各ノードに OpenStack をインストールします。この機能により、ベアメタルシステムを OpenStack ノードとしてプロビジョニングする方法が提供されます。電源管理ドライバーの全一覧については、「付録B 電源管理ドライバー」を参照してください。
- オーケストレーション
- アンダークラウドでは、環境のプランとして機能する YAML テンプレートセットが提供されています。アンダークラウドは、これらのプランをインポートして、その指示に従い、目的の OpenStack 環境を作成します。このプランには、環境作成プロセスの途中にある特定のポイントで、カスタマイズを組み込めるようにするフックも含まれます。
- コマンドラインツールおよび Web UI
- Red Hat OpenStack Platform director は、ターミナルベースのコマンドラインインターフェースまたは Web ベースのユーザーインターフェースで、これらのアンダークラウド機能を実行します。
- アンダークラウドのコンポーネント
アンダークラウドは、OpenStack のコンポーネントをベースのツールセットとして使用します。これには、以下のコンポーネントが含まれます。
- OpenStack Identity (keystone): director のコンポーネントの認証および承認
- OpenStack Bare Metal (Ironic) および OpenStack Compute (Nova): ベアメタルノードの管理
- OpenStack Networking (Neutron) および Open vSwitch: ベアメタルノードのネットワークの制御
- OpenStack Image サービス (Glance): ベアメタルマシンへ書き込むイメージの格納
- OpenStack Orchestation (Heat) および Puppet: director がオーバークラウドイメージをディスクに書き込んだ後のノードのオーケストレーションおよび設定
OpenStack Telemetry (Ceilometer): 監視とデータの収集。これには、以下が含まれます。
- OpenStack Telemetry Metrics (gnocchi): メトリック向けの時系列データベース
- OpenStack Telemetry Alarming (aodh): モニタリング向けのアラームコンポーネント
- 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 環境に管理、ネットワーク、高可用性の機能を提供するノード。理想的な OpenStack 環境には、このノード 3 台で高可用性クラスターを構成することを推奨します。
デフォルトのコントローラーノードには、以下のコンポーネントが含まれます。
- 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 (ceilometer)
- OpenStack Telemetry Metrics (gnocchi)
- OpenStack Telemetry Alarming (aodh)
- 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 環境にストレージを提供するノード。これには、以下のストレージ用のノードが含まれます。
- Ceph Storage ノード: ストレージクラスターを構成するために使用します。それぞれのノードには、Ceph Object Storage Daemon (OSD) が含まれます。また、Ceph Storage ノードをデプロイする場合には、director により Ceph Monitor がコントローラーノードにインストールされます。
Block storage (Cinder): HA コントローラーノードの外部ブロックストレージとして使用します。このノードには、以下のコンポーネントが含まれます。
- OpenStack Block Storage (cinder) ボリューム
- OpenStack Telemetry (ceilometer) エージェント
- Open vSwitch
Object Storage (swift): これらのノードは、OpenStack Swift の外部ストレージ層を提供します。コントローラーノードは、Swift プロキシーを介してこれらのノードにアクセスします。このノードには、以下のコンポーネントが含まれます。
- OpenStack Object Storage (swift) のストレージ
- OpenStack Telemetry (ceilometer) エージェント
- 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: データベースのキャッシュを提供します。
Red Hat OpenStack Platform director は複数のコントローラーノードの高可用性を一括に自動設定します。ただし、フェンシングおよび電源管理制御を有効にするには、ノードを手動で設定する必要があります。本ガイドでは、これらの手順を記載しています。
1.4. 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」を参照してください。
第2章 要件 リンクのコピーリンクがクリップボードにコピーされました!
本章では、director を使用して Red Hat OpenStack Platform をプロビジョニングする環境をセットアップするための主要な要件を記載します。これには、director のセットアップ/アクセス要件や OpenStack サービス用に director がプロビジョニングするホストのハードウェア要件が含まれます。
Red Hat OpenStack Platform をデプロイする前には、利用可能なデプロイメントメソッドの特性を考慮することが重要です。詳しくは、「Installing and Managing Red Hat OpenStack Platform」のアーティクルを参照してください。
2.1. 環境要件 リンクのコピーリンクがクリップボードにコピーされました!
最小要件
- Red Hat OpenStack Platform director 用のホストマシン 1 台
- Red Hat OpenStack Platform コンピュートノード用のホストマシン 1 台
- Red Hat OpenStack Platform コントローラーノード用のホストマシン 1 台
推奨要件
- Red Hat OpenStack Platform director 用のホストマシン 1 台
- Red Hat OpenStack Platform コンピュートノード用のホストマシン 3 台
- クラスター内に Red Hat OpenStack Platform コントローラーノード用のホストマシン 3 台
- クラスター内に Red Hat Ceph Storage ノード用のホストマシン 3 台
以下の点に注意してください。
- 全ノードにはベアメタルシステムを使用することを推奨します。最低でも、コンピュートノードにはベアメタルシステムが必要です。
- すべてのオーバークラウドベアメタルシステムには、Intelligent Platform Management Interface (IPMI) が必要です。これは、director が電源管理を制御するためです。
-
各ノードの内部 BIOS クロックを UTC に設定します。これにより、タイムゾーンオフセットを適用する前に
hwclockが BIOS クロックを同期するとファイルのタイムスタンプに未来の日時が設定される問題を防ぐことができます。
Red Hat Enterprise Linux 7.3 カーネルにアップグレードするには、Open vSwitch (OVS) 2.4.0 も OVS 2.5.0 にアップグレードする必要があります。カーネルだけアップグレードすると、OVS は機能しなくなります。
2.2. アンダークラウドの要件 リンクのコピーリンクがクリップボードにコピーされました!
director をホストするアンダークラウドシステムは、オーバークラウド内の全ノードのプロビジョニングおよび管理を行います。
- Intel 64 または AMD64 CPU 拡張機能をサポートする、8 コア 64 ビット x86 プロセッサー
- 最小 16 GB の RAM
- ルートディスク上に最小 40 GB の空きディスク領域。オーバークラウドのデプロイメントまたは更新を試みる前に、少なくとも 10 GB の空き領域を確保するようにしてください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。
- 最小 2 枚の 1 Gbps ネットワークインターフェースカード。ただし、特にオーバークラウド環境で多数のノードをプロビジョニングする場合には、ネットワークトラフィックのプロビジョニング用に 10 Gbps インターフェースを使用することを推奨します。
- ホストオペレーティングシステムとして、Red Hat Enterprise Linux 7.7 がインストール済みであること。
- ホスト上で SELinux が Enforcing モードで有効化されていること。
2.2.1. 仮想化サポート リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、以下のプラットフォームでのみ仮想アンダークラウドをサポートします。
| プラットフォーム | 説明 |
|---|---|
| Kernel-based Virtual Machine (KVM) | 認定済みのハイパーバイザーとしてリストされている Red Hat Enterprise Linux 7 でホストされていること |
| Red Hat Virtualization | 認定済みのハイパーバイザーとしてリストされている Red Hat Virtualization 4.x でホストされていること |
| Microsoft Hyper-V | Red Hat Customer Portal Certification Catalogue に記載の Hyper-V のバージョンでホストされていること |
| VMware ESX および ESXi | Red Hat Customer Portal Certification Catalogue に記載の ESX および ESXi のバージョンでホストされていること |
Red Hat OpenStack Platform director 10 には、ホストオペレーティングシステムとして最新バージョンの Red Hat Enterprise Linux が必要です。このため、仮想化プラットフォームは下層の Red Hat Enterprise Linux バージョンもサポートする必要があります。
仮想マシンの要件
仮想アンダークラウドのリソース要件は、ベアメタルのアンダークラウドの要件と似ています。ネットワークモデル、ゲスト CPU 機能、ストレージのバックエンド、ストレージのフォーマット、キャッシュモードなどプロビジョニングの際には、さまざまなチューニングオプションを考慮する必要があります。
ネットワークの考慮事項
仮想アンダークラウドの場合は、以下にあげるネットワークの考慮事項に注意してください。
- 電源管理
-
アンダークラウドの仮想マシンには、オーバークラウドのノードにある電源管理のデバイスへのアクセスが必要です。これには、ノードの登録の際に、
pm_addrパラメーターに IP アドレスを設定してください。 - プロビジョニングネットワーク
-
プロビジョニング (
ctlplane) ネットワークに使用する NIC には、オーバークラウドのベアメタルノードの NIC に対する DHCP 要求をブロードキャストして、対応する機能が必要です。仮想マシンの NIC をベアメタルの NIC と同じネットワークに接続するブリッジを作成することを推奨します。
一般的に、ハイパーバイザーのテクノロジーにより、アンダークラウドが不明なアドレスのトラフィックを伝送できない場合に問題が発生します。Red Hat Enterprise Virtualization を使用する場合には、anti-mac-spoofing を無効にしてこれを回避してください。VMware ESX または ESXi を使用している場合は、偽装転送を承諾してこれを回避します。
アーキテクチャーの例
これは、KVM サーバーを使用した基本的なアンダークラウドの仮想化アーキテクチャー例です。これは、ネットワークやリソースの要件に合わせてビルド可能な基盤としての使用を目的としています。
KVM ホストは Linux ブリッジを 2 つ使用します。
- br-ex (eth0)
- アンダークラウドへの外部アクセスを提供します。
- 外部ネットワークの DHCP サーバーは、仮想 NIC (eth0) を使用してアンダークラウドにネットワーク設定を割り当てます。
- アンダークラウドがベアメタルサーバーの電源管理インターフェースにアクセスできるようにします。
- br-ctlplane (eth1)
- ベアメタルのオーバークラウドノードと同じネットワークに接続します。
- アンダークラウドは、仮想 NIC (eth1) を使用して DHCP および PXE ブートの要求に対応します。
- オーバークラウドのベアメタルサーバーは、このネットワークの PXE 経由でブートします。
KVM ホストには、以下のパッケージが必要です。
yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync
$ yum install libvirt-client libvirt-daemon qemu-kvm libvirt-daemon-driver-qemu libvirt-daemon-kvm virt-install bridge-utils rsync
以下のコマンドは、KVM ホストにアンダークラウドの仮想マシンして、適切なブリッジに接続するための仮想 NIC を 2 つ作成します。
virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.3-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7
$ virt-install --name undercloud --memory=16384 --vcpus=4 --location /var/lib/libvirt/images/rhel-server-7.3-x86_64-dvd.iso --disk size=100 --network bridge=br-ex --network bridge=br-ctlplane --graphics=vnc --hvm --os-variant=rhel7
このコマンドにより、libvirt ドメインが起動します。virt-manager に接続し、段階を追ってインストールプロセスが進められます。または、以下のオプションを使用してキックスタートファイルを指定し、無人インストールを実行することもできます。
--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"
--initrd-inject=/root/ks.cfg --extra-args "ks=file:/ks.cfg"
インストールが完了したら、root ユーザーとしてインスタンスに SSH 接続して、「4章アンダークラウドのインストール」の手順に従います。
バックアップ
以下のように、仮想アンダークラウドをバックアップするためのソリューションは複数あります。
- オプション 1:『director のアンダークラウドのバックアップと復元』の説明に従います。
- オプション 2: アンダークラウドをシャットダウンして、アンダークラウドの仮想マシンストレージのバックアップのコピーを取ります。
- オプション 3: ハイパーバイザーがライブまたはアトミックのスナップショットをサポートする場合は、アンダークラウドの仮想マシンのスナップショットを作成します。
KVM サーバーを使用する場合は、以下の手順でスナップショットを作成してください。
-
qemu-guest-agentがアンダークラウドのゲスト仮想マシンで実行していることを確認してください。 - 実行中の仮想マシンのライブスナップショットを作成します。
virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce
$ virsh snapshot-create-as --domain undercloud --disk-only --atomic --quiesce
- QCOW バッキングファイルのコピー (読み取り専用) を作成します。
rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2
$ rsync --sparse -avh --progress /var/lib/libvirt/images/undercloud.qcow2 1.qcow2
- QCOW オーバーレイファイルをバッキングファイルにマージして、アンダークラウドの仮想マシンが元のファイルを使用するように切り替えます。
virsh blockcommit undercloud vda --active --verbose --pivot
$ virsh blockcommit undercloud vda --active --verbose --pivot
2.3. ネットワーク要件 リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドのホストには、最低でも 2 つのネットワークが必要です。
- プロビジョニングネットワーク: オーバークラウドで使用するベアメタルシステムの検出がしやすくなるように、DHCP および PXE ブート機能を提供します。このネットワークは通常、director が PXE ブートおよび DHCP の要求に対応できるように、トランキングされたインターフェースでネイティブ VLAN を使用する必要があります。一部のサーバーのハードウェアの BIOS は、VLAN からの PXE ブートをサポートしていますが、その BIOS が、ブート後に VLAN をネイティブ VLAN に変換する機能もサポートする必要があります。この機能がサポートされていない場合には、アンダークラウドに到達できません。現在この機能を完全にサポートしているサーバーハードウェアはごく一部です。プロビジョニングネットワークは、オーバークラウドノード上で Intelligent Platform Management Interface (IPMI) により電源管理を制御するのに使用するネットワークでもあります。
- 外部ネットワーク: オーバークラウドおよびアンダーグラウンドへの外部アクセスに使用する別個のネットワーク。このネットワークに接続するこのインターフェースには、静的または外部の DHCP サービス経由で動的に定義された、ルーティング可能な IP アドレスが必要です。
これは、必要なネットワークの最小数を示します。ただし、director は他の Red Hat OpenStack Platform ネットワークトラフィックをその他のネットワーク内に分離することができます。Red Hat OpenStack Platform は、ネットワークの分離に物理インターフェースとタグ付けされた VLAN の両方をサポートしています。
以下の点に注意してください。
標準的な最小限のオーバークラウドのネットワーク構成には、以下が含まれます。
- シングル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1つ。
- デュアル NIC 構成: プロビジョニングネットワーク用の NIC を 1 つと、外部ネットワーク用の NIC を 1 つ。
- デュアル NIC 構成: ネイティブの VLAN 上にプロビジョニングネットワーク用の NIC を 1 つと、異なる種別のオーバークラウドネットワークのサブネットを使用するタグ付けされた VLAN 用の NIC を 1 つ。
- 複数 NIC 構成: 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用します。
- 追加の物理 NIC は、個別のネットワークの分離、ボンディングインターフェースの作成、タグ付された VLAN トラフィックの委譲に使用することができます。
- ネットワークトラフィックの種別を分離するのに VLAN を使用している場合には、802.1Q 標準をサポートするスイッチを使用してタグ付けされた VLAN を提供します。
- オーバークラウドの作成時には、全オーバークラウドマシンで 1 つの名前を使用して NIC を参照します。理想としては、混乱を避けるため、対象のネットワークごとに、各オーバークラウドノードで同じ NIC を使用してください。たとえば、プロビジョニングネットワークにはプライマリー NIC を使用して、OpenStack サービスにはセカンダリー NIC を使用します。
- プロビジョニングネットワークの NIC は director マシン上でリモート接続に使用する NIC とは異なります。director のインストールでは、プロビジョニング NIC を使用してブリッジが作成され、リモート接続はドロップされます。director システムへリモート接続する場合には、外部 NIC を使用します。
プロビジョニングネットワークには、環境のサイズに適した IP 範囲が必要です。以下のガイドラインを使用して、この範囲に含めるべき IP アドレスの総数を決定してください。
- プロビジョニングネットワークに接続されているノード 1 台につき最小で 1 IP アドレスを含めます。
- 高可用性を設定する予定がある場合には、クラスターの仮想 IP 用に追加の IP アドレスを含めます。
環境のスケーリング用の追加の IP アドレスを範囲に追加します。
注記プロビジョニングネットワーク上で IP アドレスが重複するのを避ける必要があります。詳しい情報は、「ネットワークのプランニング」を参照してください。
注記ストレージ、プロバイダー、テナントネットワークの IP アドレスの使用範囲をプランニングすることに関する情報は、『ネットワークガイド』を参照してください。
- すべてのオーバークラウドシステムをプロビジョニング NIC から PXE ブートするように設定して、同システム上の外部 NIC およびその他の NIC の PXE ブートを無効にします。また、プロビジョニング NIC の PXE ブートは、ハードディスクや CD/DVD ドライブよりも優先されるように、ブート順序の最上位に指定するようにします。
- すべてのオーバークラウドベアメタルシステムには、Intelligent Platform Management Interface (IPMI) などのサポート対象の電源管理インターフェースが必要です。このインターフェースにより、director は各ノードの電源管理機能を制御することが可能となります。
- 各オーバークラウドシステムの詳細 (プロビジョニング NIC の MAC アドレス、IPMI NIC の IP アドレス、IPMI ユーザー名、IPMI パスワード) をメモしてください。この情報は、後でオーバークラウドノードを設定する際に役立ちます。
- Red Hat のサポートには、フェンシンが必須です。コントローラーから OOB IPMI へのネットワークフローを追加する必要があります。
- インスタンスが外部のインターネットからアクセス可能である必要がある場合には、パブリックネットワークから Floating IP アドレスを割り当てて、そのアドレスをインスタンスに関連付けます。インスタンスは、引き続きプライベートの IP アドレスを確保しますが、ネットワークトラフィックは NAT を使用して、Floating IP アドレスに到達します。Floating IP アドレスは、複数のプライベート IP アドレスではなく、単一のインスタンスにのみ割り当て可能である点に注意してください。ただし、Floating IP アドレスは、単一のテナントでのみ使用するように確保され、そのテナントは必要に応じて特定のインスタンスに関連付け/関連付け解除することができます。この設定では、お使いのインフラストラクチャーが外部のインターネットに公開されます。したがって、適切なセキュリティープラクティスを順守しているかどうかを確認しなければならない場合があります。
- 1 つのブリッジには単一のインターフェースまたは単一のボンディングのみをメンバーにすると、Open vSwitch でネットワークループが発生するリスクを緩和することができます。複数のボンディングまたはインターフェースが必要な場合には、複数のブリッジを設定することが可能です。
- オーバークラウドノードが Red Hat Content Delivery Network やネットワークタイムサーバーなどの外部のサービスに接続できるようにするには、DNS によるホスト名解決を使用することを推奨します。
OpenStack Platform の実装のセキュリティーレベルは、その環境のセキュリティーレベルと同等です。ネットワーク環境内の適切なセキュリティー原則に従って、ネットワークアクセスが正しく制御されるようにします。以下に例を示します。
- ネットワークのセグメント化を使用して、ネットワークトラフィックを軽減し、機密データを分離します。フラットなネットワークはセキュリティーレベルがはるかに低くなります。
- サービスアクセスとポートを最小限に制限します。
- 適切なファイアウォールルールとパスワードが使用されるようにします。
- SELinux が有効化されていることを確認します。
システムのセキュリティー保護については、以下のドキュメントを参照してください。
2.4. オーバークラウドの要件 リンクのコピーリンクがクリップボードにコピーされました!
以下の項では、オーバークラウドのインストール内の個別システムおよびノードの要件について詳しく説明します。
SAN (FC-AL、FCoE、iSCSI) からのオーバークラウドノードのブートは、まだサポートされていません。
2.4.1. コンピュートノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
コンピュートノードは、仮想マシンインスタンスが起動した後にそれらを稼働させる役割を果たします。コンピュートノードは、ハードウェアの仮想化をサポートしている必要があります。また、ホストする仮想マシンインスタンスの要件をサポートするのに十分なメモリーとディスク容量も必要です。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーで、Intel VT または AMD-V のハードウェア仮想化拡張機能が有効化されていること。このプロセッサーには最小でも 4 つのコアが搭載されていることを推奨しています。
- メモリー容量
- 最小で 6 GB のメモリー。仮想マシンインスタンスに割り当てるメモリー容量に基づいて、この最低要求に追加の RAM を加算します。
- ディスク容量
- 最小 40 GB の空きディスク領域
- ネットワークインターフェースカード
- 最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
- 電源管理
- 各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。
2.4.2. コントローラーノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
コントローラーノードは、RHEL OpenStack Platform 環境の中核となるサービス (例: Horizon Dashboard、バックエンドのデータベースサーバー、Keystone 認証、高可用性サービスなど) をホストする役割を果たします。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
- メモリー容量
最小のメモリー容量は 32 GB です。ただし、推奨のメモリー容量は、仮想 CPU の数によって異なります (CPU コアをハイパースレッディングの値で乗算した数値に基づいています)。以下の計算を参考にしてください。
コントローラーの最小メモリー容量の算出:
- 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」のアーティクルを参照してください。
- ディスクストレージとレイアウト
デフォルトでは、Telemetry (
gnocchi) および Object Storage (swift) サービスはいずれもコントローラーにインストールされ、ルートディスクを使用するように設定されます。これらのデフォルトは、コモディティーハードウェア上に構築される小型のオーバークラウドのデプロイに適しています。これは、概念検証およびテストの標準的な環境です。これらのデフォルトにより、最小限のプランニングでオーバークラウドをデプロイすることができますが、ワークロードキャパシティーとパフォーマンスの面ではあまり優れていません。ただし、Telemetry がストレージに絶えずアクセスするため、エンタープライズ環境では、これによって大きなボトルネックが生じる可能性があります。これにより、ディスク I/O が過度に使用されて、その他すべてのコントローラーサービスに深刻な影響をもたらします。このタイプの環境では、オーバークラウドのプランニングを行って、適切に設定する必要があります。
Red Hat は、Telemetry と Object Storage の両方の推奨設定をいくつか提供しています。詳しくは、『Deployment Recommendations for Specific Red Hat OpenStack Platform Services』を参照してください。
- ディスク容量
- Object Storage サービス (swift) がコントローラーノード上で実行されていない場合には、最低でも 40 GB のディスク容量が利用可能であること。
- ネットワークインターフェースカード
- 最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
- 電源管理
- 各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。
2.4.3. Ceph Storage ノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
Ceph Storage ノードは、RHEL OpenStack Platform 環境でオブジェクトストレージを提供する役割を果たします。
- 配置グループ
- デプロイメントの規模によらず、動的で効率的なオブジェクトの追跡を容易に実施するために、Ceph では配置グループが使用されています。OSD の障害やクラスターのリバランスの際には、Ceph は配置グループおよびその内容を移動または複製することができるので、Ceph クラスターは効率的にリバランスおよび復旧を行うことができます。director が作成するデフォルトの配置グループ数が常に最適とは限らないので、実際の要件に応じて正しい配置グループ数を計算することが重要です。配置グループの計算ツールを使用して、正しい数を計算することができます (Ceph Placement Groups (PGs) per Pool Calculator を参照)。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
- メモリー容量
- メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。
- ディスク容量
- ストレージ要件は、メモリーの容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。
- ディスクのレイアウト
推奨される Red Hat Ceph Storage ノードの構成には、少なくとも以下のようなレイアウトの 3 つのディスクが必要です。
-
/dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。 -
/dev/sdb: ジャーナルディスク。このディスクは、Ceph OSD ジャーナル向けにパーティションに分割されます。たとえば、/dev/sdb1、/dev/sdb2、/dev/sdb3(以下同様) のように分割されます。ジャーナルディスクは、通常システムパフォーマンスの向上に役立つソリッドステートドライブ (SSD) です。 -
/dev/sdc以降: OSD ディスク。ストレージ要件で必要な数のディスクを使用します。
-
- ネットワークインターフェースカード
- 最小 1 枚の 1 Gbps ネットワークインターフェースカード (実稼働環境では最低でも NIC を 2 枚使用することを推奨)。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースカードを使用します。特に大量のトラフィックにサービスを提供する OpenStack Platform 環境を構築する場合には、ストレージノードには 10 Gbps インターフェースを使用することを推奨します。
- 電源管理
- 各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。
Ceph Storage クラスターを使用するオーバークラウドのインストールについての詳しい情報は、『オーバークラウド向けの Red Hat Ceph Storage』を参照してください。
2.4.4. Object Storage ノードの要件 リンクのコピーリンクがクリップボードにコピーされました!
オブジェクトストレージノードは、オーバークラウドのオブジェクトストレージ層を提供します。オブジェクトストレージプロキシーは、コントローラーノードにインストールされます。ストレージ層には、ノードごとに複数のディスクを持つベアメタルノードが必要です。
- プロセッサー
- Intel 64 または AMD64 CPU 拡張機能をサポートする 64 ビット x86 プロセッサーです。
- メモリー容量
- メモリー要件はストレージ容量によって異なります。ハードディスク容量 1 TB あたり最小で 1 GB のメモリーを使用するのが理想的です。最適なパフォーマンスを得るには、特にワークロードが小さいファイル (100 GB 未満) の場合にはハードディスク容量 1 TB あたり 2 GB のメモリーを使用することを推奨します。
- ディスク容量
ストレージ要件は、ワークロードに必要とされる容量により異なります。アカウントとコンテナーのデータを保存するには SSD ドライブを使用することを推奨します。アカウントおよびコンテナーデータとオブジェクトの容量比率は、約 1 % です。たとえば、ハードドライブの容量 100 TB ごとに、アカウントおよびコンテナーデータの SSD 容量は 1 TB 用意するようにします。
ただし、これは保存したデータの種類により異なります。保存するオブジェクトサイズの大半が小さい場合には、SSD の容量がさらに必要です。オブジェクトが大きい場合には (ビデオ、バックアップなど)、SSD の容量を減らします。
- ディスクのレイアウト
推奨のノード設定には、以下のようなディスクレイアウトが必要です。
-
/dev/sda: ルートディスク。director は、主なオーバークラウドイメージをディスクにコピーします。 -
/dev/sdb: アカウントデータに使用します。 -
/dev/sdc: コンテナーデータに使用します。 -
/dev/sdd以降: オブジェクトサーバーディスク。ストレージ要件で必要な数のディスクを使用します。
-
- ネットワークインターフェースカード
- 最小 2 枚の 1 Gbps ネットワークインターフェースカード。タグ付けされた VLAN トラフィックを委譲する場合や、ボンディングインターフェース向けの場合には追加のネットワークインターフェースを使用します。
- 電源管理
- 各コントローラーノードには、Intelligent Platform Management Interface (IPMI) 機能などのサポート対象の電源管理インターフェースがサーバーのマザーボードに搭載されている必要があります。
2.5. リポジトリーの要件 リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドおよびオーバークラウドにはいずれも、Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite 5 もしくは 6 のいずれかを使用した Red Hat リポジトリーへのアクセスが必要です。Red Hat Satellite Server を使用する場合は、必要なリポジトリーをお使いの OpenStack Platform 環境に同期します。以下の CDN チャネル名一覧を参考にしてください。
Red Hat Enterprise Linux 7.3 カーネルにアップグレードするには、Open vSwitch (OVS) 2.4.0 も OVS 2.5.0 にアップグレードする必要があります。カーネルだけアップグレードすると、OVS は機能しなくなります。
| 名前 | リポジトリー | 要件の説明 |
| Red Hat Enterprise Linux 7 Server (RPMs) |
| ベースオペレーティングシステムのリポジトリー |
| Red Hat Enterprise Linux 7 Server - Extras (RPMs) |
| Red Hat OpenStack Platform の依存関係が含まれます。 |
| Red Hat Enterprise Linux 7 Server - RH Common (RPMs) |
| Red Hat OpenStack Platform のデプロイと設定用のツールが含まれます。 |
| Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64 |
| Red Hat Satellite 6 でのホスト管理ツール |
| Red Hat Enterprise Linux High Availability (for RHEL 7 Server) (RPMs) |
| Red Hat Enterprise Linux の高可用性ツール。コントローラーノードの高可用性に使用します。 |
| Red Hat Enterprise Linux OpenStack Platform 10 for RHEL 7 (RPMs) |
| Red Hat OpenStack Platform のコアリポジトリーRed Hat OpenStack Platform director のパッケージも含まれます。 |
| Red Hat Ceph Storage OSD 2 for Red Hat Enterprise Linux 7 Server (RPMs) |
| (Ceph Storage ノード向け) Ceph Storage Object Storage デーモンのリポジトリー。Ceph Storage ノードにインストールします。 |
| Red Hat Ceph Storage MON 2 for Red Hat Enterprise Linux 7 Server (RPMs) |
| (Ceph Storage ノード向け) Ceph Storage Monitor デーモンのリポジトリー。Ceph Storage ノードを使用して OpenStack 環境にあるコントローラーノードにインストールします。 |
| Red Hat Ceph Storage Tools 2 for Red Hat Enterprise Linux 7 Server (RPMs) |
| Ceph Storage クラスターと通信するためのノード用のツールを提供します。このリポジトリーは、Ceph Storage クラスターを使用するオーバークラウドをデプロイする際に、すべてのオーバークラウドノードで有効にする必要があります。 |
ネットワークがオフラインの Red Hat OpenStack Platform 環境用リポジトリーを設定するには、Red Hat カスタマーポータルで「オフライン環境で Red Hat OpenStack Platform Director を設定する」のアーティクルを参照してください。
第3章 オーバークラウドのプランニング リンクのコピーリンクがクリップボードにコピーされました!
以下の項で、Red Hat OpenStack Platform 環境のさまざまな要素をプランニングする際のガイドラインを説明します。これには、ノードロールの定義、ネットワークトポロジーのプランニング、ストレージなどが含まれます。
3.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 の Swift サービスに外部オブジェクトストレージを提供するホスト。このデプロイメントロールはオプションです。
以下の表には、オーバークラウドの構成例と各シナリオで使用するノード種別の定義をまとめています。
| コントローラー | コンピュート | Ceph Storage | Swift Storage | 合計 | |
| 小規模のオーバークラウド | 3 | 1 | - | - | 4 |
| 中規模のオーバークラウド | 3 | 3 | - | - | 6 |
| 追加のオブジェクトストレージがある中規模のオーバークラウド | 3 | 3 | - | 3 | 9 |
| Ceph Storage クラスターがある中規模のオーバークラウド | 3 | 3 | 3 | - | 9 |
さらに、個別のサービスをカスタムのロールに分割するかどうかを検討します。コンポーザブルロールのアーキテクチャーに関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照してください。
3.2. ネットワークのプランニング リンクのコピーリンクがクリップボードにコピーされました!
ロールとサービスを適切にマッピングして相互に正しく通信できるように、環境のネットワークトポロジーおよびサブネットのプランニングを行うことが重要です。Red Hat OpenStack Platform では、自律的に動作してソフトウェアベースのネットワーク、静的/Floating IP アドレス、DHCP を管理する Neutron ネットワークサービスを使用します。director は、オーバークラウド環境の各コントローラーノードに、このサービスをデプロイします。
Red Hat OpenStack Platform は、さまざまなサービスをマッピングして、お使いの環境の各種サブネットに割り当てられたネットワークトラフィックの種別を分類します。このネットワークトラフィック種別には以下が含まれます。
| ネットワーク種別 | 説明 | そのネットワーク種別を使用するノード |
| IPMI | ノードの電源管理に使用するネットワーク。このネットワークは、アンダークラウドのインストール前に事前定義されます。 | 全ノード |
| プロビジョニング | director は、このネットワークトラフィック種別を使用して、PXE ブートで新規ノードをデプロイし、オーバークラウドベアメタルサーバーに OpenStack Platform のインストールをオーケストレーションします。 このネットワークは、アンダークラウドのインストール前に事前定義されます。 | 全ノード |
| 内部 API | 内部 API ネットワークは、API 通信、RPC メッセージ、データベース通信経由で OpenStack のサービス間の通信を行う際に使用します。 | コントローラー、コンピュート、Cinder Storage、Swift Storage |
| テナント | Neutron は、VLAN 分離 (各テナントネットワークがネットワーク VLAN) または VXLAN か GRE 経由のトンネリングを使用した独自のネットワークを各テナントに提供します。ネットワークトラフィックは、テナントのネットワークごとに分割されます。テナントネットワークにはそれぞれ IP サブネットが割り当てられています。また、ネットワーク名前空間が複数あると、複数のテナントネットワークが同じアドレスを使用できるので、競合は発生しません。 | コントローラー、コンピュート |
| ストレージ | Block Storage、NFS、iSCSI など。理想的には、これはパフォーマンス上の理由から、完全に別のスイッチファブリックに分離した方がよいでしょう。 | 全ノード |
| ストレージ管理 | OpenStack Object Storage (swift) は、このネットワークを使用して、参加するレプリカノード間でデータオブジェクトを同期します。プロキシーサービスは、ユーザー要求と下層のストレージレイヤーの間の仲介インターフェースとして機能します。プロキシーは、受信要求を受け取り、必要なレプリカの位置を特定して要求データを取得します。Ceph バックエンドを使用するサービスは、Ceph と直接対話せずにフロントエンドのサービスを使用するため、ストレージ管理ネットワーク経由で接続を確立します。RBD ドライバーは例外で、このトラフィックは直接 Ceph に接続する点に注意してください。 | コントローラー、Ceph Storage、Cinder Storage、Swift Storage |
| 外部 | グラフィカルシステム管理用の OpenStack Dashboard (Horizon)、OpenStack サービス用のパブリック API をホストして、インスタンスへの受信トラフィック向けに SNAT を実行します。外部ネットワークがプライベート IP アドレスを使用する場合には (RFC-1918 に準拠)、インターネットからのトラフィックに対して、さらに NAT を実行する必要があります。 | コントローラーとアンダークラウド |
| Floating IP | 受信トラフィックが Floating IP アドレスとテナントネットワーク内のインスタンスに実際に割り当てられた IP アドレスとの間の 1 対 1 の IP アドレスマッピングを使用してインスタンスに到達できるようにします。外部ネットワークからは分離した VLAN 上で Floating IP をホストする場合には、Floating IP VLAN をコントローラーノードにトランキングして、オーバークラウドの作成後に Neutron を介して VLAN を追加します。これにより、複数のブリッジに接続された複数の Floating IP ネットワークを作成する手段が提供されます。VLAN は、トランキングされますが、インターフェースとしては設定されません。その代わりに、Neutron は各 Floating IP ネットワークに選択したブリッジ上の VLAN セグメンテーション ID を使用して、OVS ポートを作成します。 | コントローラー |
| 管理 | SSH アクセス、DNS トラフィック、NTP トラフィックなどのシステム管理機能を提供します。このネットワークは、コントローラー以外のノード用のゲートウェイとしても機能します。 | 全ノード |
一般的な Red Hat OpenStack Platform のシステム環境では通常、ネットワーク種別の数は物理ネットワークのリンク数を超えます。全ネットワークを正しいホストに接続するには、オーバークラウドは VLAN タグ付けを使用して、1 つのインターフェースに複数のネットワークを提供します。ネットワークの多くは、サブネットが分離されていますが、インターネットアクセスまたはインフラストラクチャーにネットワーク接続ができるようにルーティングを提供するレイヤー 3 のゲートウェイが必要です。
デプロイ時に neutron VLAN モード (トンネリングは無効) を使用する場合でも、プロジェクトネットワーク (GRE または VXLAN でトンネリング) をデプロイすることを推奨します。これには、デプロイ時にマイナーなカスタマイズを行う必要があり、将来ユーティリティーネットワークまたは仮想化ネットワークとしてトンネルネットワークを使用するためのオプションが利用可能な状態になります。VLAN を使用してテナントネットワークを作成することは変わりませんが、テナントの VLAN を消費せずに特別な用途のネットワーク用に VXLAN トンネルを作成することも可能です。また、テナント VLAN を使用するデプロイメントに VXLAN 機能を追加することは可能ですが、サービスを中断せずにテナント VLAN を既存のオーバークラウドに追加することはできません。
director は、トラフィック種別の中から 6 つを特定のサブネットまたは VLAN にマッピングする方法を提供します。このようなトラフィック種別には、以下が含まれます。
- 内部 API
- Storage
- ストレージ管理
- テナントネットワーク
- 外部
- 管理 (オプション)
未割り当てのネットワークは、プロビジョニングネットワークと同じサブネットに自動的に割り当てられます。
下図では、ネットワークが個別の VLAN に分離されたネットワークトポロジーの例を紹介しています。各オーバークラウドノードは、ボンディングで 2 つ (nic2 および nic3) のインターフェースを使用して、対象の VLAN 経由でこれらのネットワークを提供します。また、各オーバークラウドのノードは、ネイティブの VLAN (nic1) を使用するプロビジョニングネットワークでアンダークラウドと通信します。
以下の表は、異なるネットワークのレイアウトをマッピングするネットワークトラフィック例が記載されています。
| マッピング | インターフェースの総数 | VLAN の総数 | |
| 外部アクセスのあるフラットネットワーク | ネットワーク 1: プロビジョニング、内部 API、ストレージ、ストレージ管理、テナントネットワーク ネットワーク 2: 外部、Floating IP (オーバークラウドの作成後にマッピング) | 2 | 2 |
| 分離ネットワーク | ネットワーク 1: プロビジョニング ネットワーク 2: 内部 API ネットワーク 3: テナントネットワーク ネットワーク 4: ストレージ ネットワーク 5: ストレージ管理 ネットワーク 6: 管理 (オプション) ネットワーク 7: 外部、Floating IP (オーバークラウドの作成後にマッピング) | 3 (ボンディングインターフェース 2 つを含む) | 7 |
3.3. ストレージのプランニング リンクのコピーリンクがクリップボードにコピーされました!
任意のドライバーまたはバックエンド種別のバックエンド cinder ボリュームを使用するゲストインスタンスで LVM を使用すると、パフォーマンス、ボリュームの可視性/可用性、およびデータ破損の問題が生じます。このような問題は、LVM フィルターを使用すると緩和することができます。詳しくは、『ストレージガイド』の「バックエンド」および 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 により仮想マシンをブートすることができます。
ゲストディスク: ゲストディスクは、ゲストオペレーティングシステムのディスクです。デフォルトでは、Nova で仮想マシンをブートすると、ディスクは、ハイパーバイザーのファイルシステム上のファイルとして表示されます (通常
/var/lib/nova/instances/<uuid>/の配下)。Ceph 内にあるすべての仮想マシンを cinder を使用せずに直接ブートすることができます。これにより、ライブマイグレーションのプロセスを使用して、簡単にメンテナンス操作を実行することができるので便利です。また、ハイパーバイザーが停止した場合には、nova evacuateをトリガーして、ほぼシームレスに仮想マシンを別の場所で実行することもできるので便利です。重要Ceph 内で仮想マシンをブートする場合は (一時バックエンドまたはボリュームからのブート)、glance イメージの形式を
RAW形式にする必要があります。Ceph では、仮想マシンディスクをホストするのに、QCOW2 または VMDK 等の他のイメージ形式はサポートされません。
その他の情報については、『Red Hat Ceph Storage Architecture Guide』を参照してください。
- Swift Storage ノード
- director は、外部オブジェクトストレージノードを作成します。これは、オーバークラウド環境でコントローラーノードをスケーリングまたは置き換える必要があるが、高可用性クラスター外にオブジェクトストレージを保持する必要がある場合に便利です。
第4章 アンダークラウドのインストール リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform 環境の構築では、最初にアンダークラウドシステムに director をインストールします。これには、必要なサブスクリプションやリポジトリーを有効化するために複数の手順を実行する必要があります。
4.1. director のインストールユーザーの作成 リンクのコピーリンクがクリップボードにコピーされました!
director のインストールプロセスでは、root 以外のユーザーがコマンドを実行する必要があります。以下のコマンドを使用して、stack という名前のユーザーを作成して、パスワードを設定します。
useradd stack passwd stack # specify a password
[root@director ~]# useradd stack
[root@director ~]# passwd stack # specify a password
sudo を使用する際に、このユーザーがパスワードを要求されないようにします。
echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack chmod 0440 /etc/sudoers.d/stack
[root@director ~]# echo "stack ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/stack
[root@director ~]# chmod 0440 /etc/sudoers.d/stack
新規作成した stack ユーザーに切り替えます。
su - stack
[root@director ~]# su - stack
[stack@director ~]$
stack ユーザーで director のインストールを続行します。
4.2. テンプレートとイメージ用のディレクトリーの作成 リンクのコピーリンクがクリップボードにコピーされました!
director はシステムのイメージと Heat テンプレートを使用して、オーバークラウド環境を構築します。これらのファイルを整理するには、イメージとテンプレート用にディレクトリーを作成するように推奨します。
mkdir ~/images mkdir ~/templates
$ mkdir ~/images
$ mkdir ~/templates
本ガイドのその他のセクションでは、この 2 つのディレクトリーを使用して特定のファイルを保存します。
4.3. システムのホスト名の設定 リンクのコピーリンクがクリップボードにコピーされました!
director には、インストールと設定プロセス用に完全修飾ドメイン名が必要です。これは、director のホストのホスト名を設定する必要がある場合があることを意味します。ホストのホスト名を確認します。
hostname # Checks the base hostname hostname -f # Checks the long hostname (FQDN)
$ hostname # Checks the base hostname
$ hostname -f # Checks the long hostname (FQDN)
どちらかのコマンドで正しいホスト名が出力されない、またはエラーが表示される場合には、hostnamectl でホスト名を設定します。
sudo hostnamectl set-hostname manager.example.com sudo hostnamectl set-hostname --transient manager.example.com
$ sudo hostnamectl set-hostname manager.example.com
$ sudo hostnamectl set-hostname --transient manager.example.com
director では、/etc/hosts にシステムのホスト名とベース名も入力する必要があります。たとえば、システムの名前が manager.example.com の場合は、/etc/hosts に以下のように入力する必要があります。
127.0.0.1 manager.example.com manager localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1 manager.example.com manager localhost localhost.localdomain localhost4 localhost4.localdomain4
4.4. システムの登録 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenStack Platform director をインストールするには、まず Red Hat Subscription Manager を使用してホストシステムを登録し、必要なチャンネルをサブスクライブします。
コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
sudo subscription-manager register
$ sudo subscription-manager register
Red Hat OpenStack Platform director のエンタイトルメントプール ID を検索します。以下に例を示します。
Pool ID の値を特定して、Red Hat OpenStack Platform 10 のエンタイトルメントをアタッチします。
sudo subscription-manager attach --pool=Valid-Pool-Number-123456
$ sudo subscription-manager attach --pool=Valid-Pool-Number-123456
デフォルトのリポジトリーをすべて無効にしてから、必要な Red Hat Enterprise Linux リポジトリーを有効にします。
sudo subscription-manager repos --disable=* sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-10-rpms
$ sudo subscription-manager repos --disable=*
$ sudo subscription-manager repos --enable=rhel-7-server-rpms --enable=rhel-7-server-extras-rpms --enable=rhel-7-server-rh-common-rpms --enable=rhel-ha-for-rhel-7-server-rpms --enable=rhel-7-server-openstack-10-rpms
これらのリポジトリーには、director のインストールに必要なパッケージが含まれます。
「リポジトリーの要件」でリストしたリポジトリーのみを有効にします。追加のリポジトリーを使用すると、パッケージとソフトウェアの競合が発生する場合があります。他のリポジトリーは有効にしないでください。
RHEL のバージョンを RHEL 7.7 に設定します。
sudo subscription-manager release --set=7.7
$ sudo subscription-manager release --set=7.7
システムで更新を実行して、ベースシステムパッケージを最新の状態にします。
sudo yum update -y sudo reboot
$ sudo yum update -y
$ sudo reboot
システムは、director をインストールできる状態になりました。
4.5. director パッケージのインストール リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドを使用して、director のインストールと設定に必要なコマンドラインツールをインストールします。
sudo yum install -y python-tripleoclient
$ sudo yum install -y python-tripleoclient
これにより、director のインストールに必要なパッケージがすべてインストールされます。
4.6. director の設定 リンクのコピーリンクがクリップボードにコピーされました!
director のインストールプロセスには、ネットワーク設定を判断する特定の設定が必要です。この設定は、stack ユーザーのホームディレクトリーに undercloud.conf として配置されているテンプレートに保存されています。
Red Hat は、インストールに必要な設定を判断しやすいように、基本テンプレートを提供しています。このテンプレートを stack ユーザーのホームディレクトリーにコピーします。
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
undercloud.conf ファイルには、アンダークラウドを設定するための設定値が含まれています。パラメーターを省略したり、コメントアウトした場合には、アンダークラウドのインストールでデフォルト値が使用されます。
テンプレートには [DEFAULT] および [auth] の 2 つのセクションが含まれます。[DEFAULT] セクションには以下のパラメーターが含まれます。
- undercloud_hostname
- アンダークラウドの完全修飾ホスト名を定義します。設定すると、アンダークラウドのインストールで全システムのホスト名が設定されます。未設定のままにすると、アンダークラウドは現在のホスト名を使用しますが、ユーザーは適切に全システムのホスト名の設定を行う必要があります。
- local_ip
-
director のプロビジョニング NIC 用に定義する IP アドレス。これは、director が DHCP および PXE ブートサービスに使用する IP アドレスでもあります。環境内の既存の IP アドレスまたはサブネットと競合するなど、プロビジョニングネットワークに別のサブネットを使用する場合以外は、この値はデフォルトの
192.0.2.1/24のままにします。 - network_gateway
オーバークラウドインスタンスのゲートウェイ。外部ネットワークにトラフィックを転送するアンダークラウドのホストです。director に別の IP アドレスを使用する場合または外部ゲートウェイを直接使用する場合以外は、この値はデフォルト (
192.0.2.1) のままにします。注記director の設定スクリプトは、適切な
sysctlカーネルパラメーターを使用して IP フォワーディングを自動的に有効にする操作も行います。- undercloud_public_vip
-
SSL/TLS 経由の director のパブリック API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは
/32ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。 - undercloud_admin_vip
-
SSL/TLS 経由の director の管理 API エンドポイントに定義する IP アドレスまたはホスト名。director の設定により、IP アドレスは
/32ネットマスクを使用するルーティングされた IP アドレスとして director のソフトウェアブリッジに接続されます。 - undercloud_service_certificate
- OpenStack SSL 通信の証明書の場所とファイル名。理想的には、信頼できる認証局から、この証明書を取得します。それ以外の場合は、「付録A SSL/TLS 証明書の設定」のガイドラインを使用して独自の自己署名の証明書を作成します。これらのガイドラインには、自己署名の証明書か認証局からの証明書に拘らず、証明書の SELinux コンテキストを設定する方法が含まれています。
- generate_service_certificate
-
アンダークラウドのインストール時に SSL 証明書を生成するかどうかを定義します。これは
undercloud_service_certificateパラメーターに使用します。アンダークラウドのインストールで、作成された証明書/etc/pki/tls/certs/undercloud-[undercloud_public_vip].pemを保存します。certificate_generation_caパラメーターで定義される CA はこの証明書に署名します。 - certificate_generation_ca
-
要求した証明書に署名する CA の
certmongerのニックネーム。generate_service_certificateパラメーターを設定した場合のみこのオプションを使用します。localCA を選択する場合は、certmonger はローカルの CA 証明書を/etc/pki/ca-trust/source/anchors/cm-local-ca.pemに抽出して、トラストチェーンに追加します。 - service_principal
- この証明書を使用するサービスの Kerberos プリンシパル。CA で FreeIPA などの Kerberos プリンシパルが必要な場合にのみ使用します。
- local_interface
director のプロビジョニング NIC 用に選択するインターフェース。これは、director が DHCP および PXE ブートサービスに使用するデバイスでもあります。この値を選択したデバイスに変更します。接続されているデバイスを確認するには、
ip addrコマンドを使用します。ip addrコマンドの出力結果の例を、以下に示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、外部 NIC は
eth0を、プロビジョニング NIC は未設定のeth1を使用します。今回は、local_interfaceをeth1に設定します。この設定スクリプトにより、このインターフェースがinspection_interfaceパラメーターで定義したカスタムのブリッジにアタッチされます。- local_mtu
-
local_interfaceに使用する MTU。 - network_cidr
-
オーバークラウドインスタンスの管理に director が使用するネットワーク。これは、アンダークラウドの
neutronサービスが管理するプロビジョニングネットワークです。プロビジョニングネットワークに別のサブネットを使用しない限り、この値はデフォルト (192.0.2.0/24) のままにします。 - masquerade_network
-
外部アクセスのためにマスカレードするネットワークを定義します。このパラメーターにより、director 経由で外部ネットワークにアクセスすることができるように、プロビジョニングネットワークにネットワークアドレス変換 (NAT) の一部メカニズムが提供されます。プロビジョニングネットワークに別のサブネットを使用しない限り、この値はデフォルト (
192.0.2.0/24) のままにします。 - dhcp_start、dhcp_end
- オーバークラウドノードの DHCP 割り当て範囲 (開始アドレスと終了アドレス)。ノードを割り当てるのに十分な IP アドレスがこの範囲に含まれるようにします。
- hieradata_override
-
hieradataオーバーライドファイルへのパス。設定すると、アンダークラウドのインストールでこのファイルが/etc/puppet/hieradataにコピーされ、階層の最初のファイルに設定されます。これを使用して、undercloud.confパラメーター以外のカスタム設定をサービスに指定します。 - net_config_override
-
ネットワーク設定のオーバーライドテンプレートへのパス。これを設定すると、アンダークラウドは JSON 形式のテンプレートを使用して
os-net-configでネットワークを設定します。これは、undercloud.confに設定されているネットワークパラメーターを無視します。/usr/share/instack-undercloud/templates/net-config.json.templateの例を参照してください。 - inspection_interface
-
ノードのイントロスペクションに director が使用するブリッジ。これは、director の設定により作成されるカスタムのブリッジです。
LOCAL_INTERFACEでこのブリッジをアタッチします。これは、デフォルトのbr-ctlplaneのままにします。 - inspection_iprange
-
director のイントロスペクションサービスが PXE ブートとプロビジョニングプロセスの際に使用する IP アドレス範囲。コンマ区切りの値を使用して、開始アドレスと終了アドレスを定義します。たとえば、
192.0.2.100,192.0.2.120のように指定します。この範囲には、使用するノードに十分な数の IP アドレスが含まれるようにし、dhcp_startとdhcp_endの範囲とは競合しないように設定してください。 - inspection_extras
-
イントロスペクション時に追加のハードウェアコレクションを有効化するかどうかを定義します。イントロスペクションイメージでは
python-hardwareまたはpython-hardware-detectパッケージが必要です。 - inspection_runbench
-
ノードイントロスペクション時に一連のベンチマークを実行します。有効にするには、
trueに設定します。このオプションは、登録ノードのハードウェアを検査する際にベンチマーク分析を実行する場合に必要です。詳しくは、「ノードのハードウェアの検査」を参照してください。 - inspection_enable_uefi
- UEFI のみのファームウェアを使用するノードのイントロスペクションをサポートするかどうかを定義します。詳しい情報は、「付録D 代替ブートモード」を参照してください。
- undercloud_debug
-
アンダークラウドサービスのログレベルを
DEBUGに設定します。この値をtrueに設定して有効にします。 - enable_tempest
-
検証ツールをインストールするかどうかを定義します。デフォルトは、
falseに設定されていますが、trueで有効化することができます。 - enable_mistral
- アンダークラウドに OpenStack Workflow サービス (mistral) をインストールするかどうかを定義します。
- enable_zaqar
- アンダークラウドに OpenStack Messaging サービス (zaqar) をインストールするかどうかを定義します。
- ipxe_enabled
-
iPXE か標準の PXE のいずれを使用するか定義します。デフォルトは
trueで iPXE を有効化します。falseに指定すると、標準の PXE に設定されます。詳しい情報は、「付録D 代替ブートモード」を参照してください。 - enable_telemetry
-
アンダークラウドに OpenStack Telemetry (ceilometer、aodh) サービスをインストールするかどうかを定義します。デフォルト値は
falseで、アンダークラウド上の telemetry が無効になります。このパラメーターは、Red Hat CloudForms などのメトリックデータを消費する他の製品を使用している場合に必要です。 - enable_ui
-
director の Web UI をインストールするかどうかを定義します。これにより、グラフィカル Web インターフェースを使用して、オーバークラウドのプランニングやデプロイメントが可能になります。詳しい情報は、「6章Web UI を使用した基本的なオーバークラウド要件の設定」を参照してください。UI は、
undercloud_service_certificateまたはgenerate_service_certificateのいずれかを使用して SSL/TLS を有効化している場合にのみ使用できる点にご注意ください。 - enable_validations
- 検証の実行に必要なアイテムをインストールするかどうかを定義します。
- store_events
- アンダークラウドに OpenStack Telemetry (ceilomete) のイベントを保管するかどうかを定義します。
- scheduler_max_attempts
- スケジューラーがインスタンスのデプロイを試行する最大回数。これは、スケジューリング時に競合状態にならないように、1 度にデプロイする予定のベアメタルノードの数以上に指定するようにしてください。
[auth] セクションには以下のパラメーターが含まれます。
- undercloud_db_password、undercloud_admin_token、undercloud_admin_password、undercloud_glance_passwm など
残りのパラメーターは、全 director サービスのアクセス詳細を指定します。値を変更する必要はありません。
undercloud.confで空欄になっている場合には、これらの値は director の設定スクリプトによって自動的に生成されます。設定スクリプトの完了後には、すべての値を取得することができます。重要これらのパラメーターの設定ファイルの例では、プレースホルダーの値に
<None>を使用しています。これらの値を<None>に設定すると、デプロイメントでエラーが発生します。
これらのパラメーターの値は、ネットワークに応じて変更してください。完了したら、ファイルを保存して以下のコマンドを実行します。
openstack undercloud install
$ openstack undercloud install
このコマンドで、director の設定スクリプトを起動します。director により、追加のパッケージがインストールされ、undercloud.conf の設定に合わせてサービスを設定します。このスクリプトは、完了までに数分かかります。
設定スクリプトにより、完了時には 2 つのファイルが生成されます。
-
undercloud-passwords.conf: director サービスの全パスワード一覧 -
stackrc: director のコマンドラインツールへアクセスできるようにする初期化変数セット
この設定により、OpenStack Platform のすべてのサービスも自動的に起動します。以下のコマンドを使用して、有効化されたサービスを確認してください。
sudo systemctl list-units openstack-*
$ sudo systemctl list-units openstack-*
stack ユーザーを初期化してコマンドラインツールを使用するには、以下のコマンドを実行します。
source ~/stackrc
$ source ~/stackrc
これで、director のコマンドラインツールが使用できるようになりました。
4.7. オーバークラウドノードのイメージの取得 リンクのコピーリンクがクリップボードにコピーされました!
director では、オーバークラウドのノードをプロビジョニングする際に、複数のディスクが必要です。必要なディスクは以下のとおりです。
- イントロスペクションのカーネルおよび ramdisk: PXE ブートでベアメタルシステムのイントロスペクションに使用
- デプロイメントカーネルおよび ramdisk: システムのプロビジョニングおよびデプロイメントに使用
- オーバークラウドカーネル、ramdisk、完全なイメージ: ノードのハードディスクに書き込まれるベースのオーバークラウドシステム
rhosp-director-images および rhosp-director-images-ipa パッケージからこれらのイメージを取得します。
sudo yum install rhosp-director-images rhosp-director-images-ipa
$ sudo yum install rhosp-director-images rhosp-director-images-ipa
stack ユーザーのホーム (/home/stack/images) の images ディレクトリーにアーカイブを展開します。
cd ~/images for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done
$ cd ~/images
$ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done
これらのイメージを director にインポートします。
openstack overcloud image upload --image-path /home/stack/images/
$ openstack overcloud image upload --image-path /home/stack/images/
このコマンドにより、bm-deploy-kernel、bm-deploy-ramdisk、overcloud-full、overcloud-full-initrd、overcloud-full-vmlinuz のイメージが director にアップロードされますこれらは、デプロイメントとオーバークラウド用のイメージです。スクリプトにより、director の PXE サーバー上にイントロスペクションイメージもインストールされます。
CLI でイメージ一覧を表示します。
この一覧には、イントロスペクションの PXE イメージは表示されません。director は、これらのファイルを /httpboot にコピーします。
ls -l /httpboot
[stack@host1 ~]$ ls -l /httpboot
total 341460
-rwxr-xr-x. 1 root root 5153184 Mar 31 06:58 agent.kernel
-rw-r--r--. 1 root root 344491465 Mar 31 06:59 agent.ramdisk
-rw-r--r--. 1 root root 337 Mar 31 06:23 inspector.ipxe
デフォルトの overcloud-full.qcow2 イメージは、フラットなパーティションイメージです。ただし、完全なディスクイメージをインポートして使用することも可能です。詳しくは、「付録C 完全なディスクイメージ」を参照してください。
4.8. アンダークラウドの Neutron サブネットでのネームサーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドで cdn.redhat.com などの外部のホスト名を解決する予定の場合は、オーバークラウドノード上にネームサーバーを設定することを推奨します。ネットワークを分離していない標準のオーバークラウドの場合には、ネームサーバーはアンダークラウドの neutron サブネットを使用して定義されます。環境でネームサーバーを定義するには、以下のコマンドを使用します。
openstack subnet list openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] [subnet-uuid]
$ openstack subnet list
$ openstack subnet set --dns-nameserver [nameserver1-ip] --dns-nameserver [nameserver2-ip] [subnet-uuid]
サブネットを表示してネームサーバーを確認します。
サービストラフィックを別のネットワークに分離する場合は、オーバークラウドのノードはネットワーク環境ファイルの DnsServer パラメーターを使用します。
4.9. アンダークラウドのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
Red Hat では、アンダークラウドホストおよび Red Hat OpenStack Platform director から重要なデータのバックアップを作成するプロセスを提供しています。アンダークラウドのバックアップについての詳しい情報は、『director のアンダークラウドのバックアップと復元』を参照してください。
4.10. アンダークラウド設定の完了 リンクのコピーリンクがクリップボードにコピーされました!
これで アンダークラウドの設定が完了しました。次の章では、ノードの登録、検査、さまざまなノードロールのタグ付けなど、オーバークラウドの基本的な設定について説明します。
第5章 CLI ツールを使用した基本的なオーバークラウド要件の設定 リンクのコピーリンクがクリップボードにコピーされました!
本章では、CLI ツールを使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタム機能は含まれません。ただし、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加し、仕様に合わせてカスタマイズすることができます。
本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。これ以外のサポート対象電源管理ドライバーおよびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。
ワークフロー
- ノード定義のテンプレートを作成して director で空のノードを登録します。
- 全ノードのハードウェアを検査します。
- ロールにノードをタグ付けします。
- 追加のノードプロパティーを定義します。
要件
- 「4章アンダークラウドのインストール」で作成した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。本章の例では、プロビジョニングサブネットを 192.0.2.0/24 とし、以下の IP アドレス割り当てを使用しています。
Expand 表5.1 プロビジョニングネットワークの IP 割り当て ノード名
IP アドレス
MAC アドレス
IPMI IP アドレス
director
192.0.2.1
aa:aa:aa:aa:aa:aa
不要
コントローラー
定義済みの DHCP
bb:bb:bb:bb:bb:bb
192.0.2.205
Compute
定義済みの DHCP
cc:cc:cc:cc:cc:cc
192.0.2.206
- その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用します。ただし、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
5.1. オーバークラウドノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
director では、手動で作成したノード定義のテンプレートが必要です。このファイル (instackenv.json) は、JSON 形式のファイルを使用して、ノードのハードウェアおよび電源管理の情報が含まれます。たとえば、2 つのノードを登録するテンプレートは、以下のようになります。
このテンプレートでは、以下の属性を使用します。
- name
- ノードの論理名
- pm_type
-
使用する電源管理ドライバー。この例で使用しているのは IPMI ドライバー (
pxe_ipmitool) で、電源管理の推奨ドライバーです。 - pm_user、pm_password
- IPMI のユーザー名およびパスワード
- pm_addr
- IPMI デバイスの IP アドレス
- mac
- (オプション) ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
- cpu
- (オプション) ノード上の CPU 数
- memory
- (オプション) メモリーサイズ (MB 単位)
- disk
- (オプション) ハードディスクのサイズ (GB 単位)
- arch
- (オプション) システムアーキテクチャー
IPMI が推奨されるサポート対象電源管理ドライバーです。これ以外のサポート対象電源管理ドライバーおよびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。それらの電源管理ドライバーが想定どおりに機能しない場合には、電源管理に IPMI を使用してください。
テンプレートを作成したら、以下のコマンドを実行してフォーマットおよび構文を検証します。
openstack baremetal instackenv validate --file instackenv.json
$ openstack baremetal instackenv validate --file instackenv.json
stack ユーザーのホームディレクトリーにファイルを保存し (/home/stack/instackenv.json)、続いて以下のコマンドを実行してテンプレートを director にインポートします。
openstack overcloud node import ~/instackenv.json
$ openstack overcloud node import ~/instackenv.json
このコマンドでテンプレートをインポートして、テンプレートから director に各ノードを登録します。
ノードを登録して設定が完了した後に、CLI でこれらのノードの一覧を表示します。
openstack baremetal node list
$ openstack baremetal node list
5.2. ノードのハードウェアの検査 リンクのコピーリンクがクリップボードにコピーされました!
director は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントをブートします。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。
ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、「プロファイルへのノードのタグ付け」に記載の手順に従って、ノードをプロファイルに手動でタグ付けすることもできます。
すべてのノードを管理状態に設定します。
for node in $(openstack baremetal node list -c UUID -f value) ; do openstack baremetal node manage $node ; done
$ for node in $(openstack baremetal node list -c UUID -f value) ; do openstack baremetal node manage $node ; done
以下のコマンドを実行して、各ノードのハードウェア属性を検証します。
openstack overcloud node introspect --all-manageable --provide
$ openstack overcloud node introspect --all-manageable --provide
-
--all-manageableオプションは、管理状態のノードのみをイントロスペクションします。上記の例では、すべてのノードが対象です。 -
--provideオプションは、イントロスペクション後に全ノードを active の状態にリセットします。
別のターミナルウィンドウで以下のコマンドを使用してイントロスペクションの進捗状況をモニタリングします。
sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
$ sudo journalctl -l -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq -u openstack-ironic-conductor -f
このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルノードの場合には、通常 15 分ほどかかります。
あるいは、それぞれのノードで個別にイントロスペクションを実施します。ノードを管理モードに設定してイントロスペクションを実施し、続いてノードの管理モードを終了します。
openstack baremetal node manage [NODE UUID] openstack overcloud node introspect [NODE UUID] --provide
$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide
5.3. プロファイルへのノードのタグ付け リンクのコピーリンクがクリップボードにコピーされました!
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。このプロファイルタグにより、ノードがフレーバーに照合され、次にそのフレーバーがデプロイメントロールに割り当てられます。以下の例では、コントローラーノードのロール、フレーバー、プロファイル、ノード間の関係を示しています。
| タイプ | 説明 |
|---|---|
| ロール |
|
| フレーバー |
|
| プロファイル |
|
| ノード |
また、各ノードに |
アンダークラウドのインストール時に、デフォルトプロファイルのフレーバー compute、control、swift-storage、ceph-storage、block-storage が作成され、大半の環境で変更なしに使用することができます。
多くのノードでは、プロファイルの自動タグ付けを使用します。詳しくは、「付録E プロファイルの自動タグ付け」を参照してください。
特定のプロファイルにノードをタグ付けする場合には、各ノードの properties/capabilities パラメーターに profile オプションを追加します。たとえば、2 つのノードをタグ付けしてコントローラープロファイルとコンピュートプロファイルをそれぞれ使用するには、以下のコマンドを実行します。
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
profile:compute と profile:control オプションを追加することで、この 2 つのノードがそれぞれのプロファイルにタグ付けされます。
これらのコマンドは、各ノードのブート方法を定義する boot_option:local パラメーターも設定します。お使いのハードウェアによっては、boot_mode パラメーターを uefi に追加して、ノードが BIOS モードの代わりに UEFI を使用してブートするようにする必要がある場合もあります。詳しい情報は、「UEFI ブートモード」を参照してください。
ノードのタグ付けが完了した後には、割り当てたプロファイルまたはプロファイルの候補を確認します。
openstack overcloud profiles list
$ openstack overcloud profiles list
カスタムロールのプロファイル
カスタムロールを使用する場合には、これらの新規ロールに対応するために追加のフレーバーやプロファイルを作成する必要があるかもしれません。たとえば、Networker ロールの新規フレーバーを作成するには、以下のコマンドを実行します。
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker
$ openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 networker
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="networker" networker
この新規プロファイルにノードを割り当てます。
openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d
$ openstack baremetal node set --property capabilities='profile:networker,boot_option:local' dad05b82-0c74-40bf-9d12-193184bfc72d
5.4. ノードのルートディスクの定義 リンクのコピーリンクがクリップボードにコピーされました!
一部のノードでは、複数のディスクが使用される場合があります。したがって、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)。これは、永続デバイス名が付いたデバイスのみに使用してください。
以下の例は、ディスクのシリアル番号を使用して、オーバークラウドイメージをデプロイするルートディスクを指定する方法を示しています。
各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドにより、ノードのディスク情報を表示します。
openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
$ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"
たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。
以下の例では、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 のディスク 2 に設定します。そのためには、ノード定義の root_device パラメーターに変更を加える必要があります。
openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
この操作は、director がルートディスクとして使用する特定のディスクを把握するのに役立ちます。オーバークラウドの作成を開始すると、director はこのノードをプロビジョニングし、オーバークラウドイメージをこのディスクに書き込みます。
各ノードの BIOS を設定して、選択したルートディスクからのブートを含めるようにしてください。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるブート順序を推奨します。
ルートディスクを設定するのに 名前 を使用しないでください。この値は、ノードのブート時に変更される可能性があります。
5.5. オーバークラウドのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドには、オーバークラウドの作成プランとして機能するさまざまな Heat テンプレートが含まれます。『オーバークラウドの高度なカスタマイズ』を使用して、オーバークラウドの詳細機能をカスタマイズすることができます。
カスタマイズを行わない場合は、基本的なオーバークラウドのデプロイを続行することができます。詳しくは、「「CLI ツールを使用したオーバークラウドの作成」」を参照してください。
基本的なオーバークラウドでは、ブロックストレージにローカルの LVM ストレージを使用しますが、この設定はサポートされません。ブロックストレージには、外部のトレージソリューションを使用することを推奨します。
5.6. CLI ツールを使用したオーバークラウドの作成 リンクのコピーリンクがクリップボードにコピーされました!
OpenStack 環境作成における最後の段階では、openstack overcloud deploy コマンドを実行して OpenStack 環境を作成します。このコマンドを実行する前に、キーオプションやカスタムの環境ファイルの追加方法を十分に理解しておく必要があります。以下のセクションでは、openstack overcloud deploy コマンドとそれに関連するオプションについて説明します。
バックグラウンドプロセスとして openstack overcloud deploy を実行しないでください。バックグラウンドのプロセスとして開始された場合にはオーバークラウドの作成は途中で停止してしまう可能性があります。
オーバークラウドのパラメーター設定
以下の表では、openstack overcloud deploy コマンドを使用する際の追加パラメーターを一覧表示します。
| パラメーター | 説明 |
|---|---|
|
|
デプロイする Heat テンプレートが格納されているディレクトリー。空欄にした場合には、コマンドはデフォルトのテンプレートの場所である |
|
| 作成または更新するスタックの名前 |
|
| デプロイメントのタイムアウト (分単位) |
|
| ハイパーバイザーに使用する仮想化タイプ |
|
|
時刻の同期に使用する Network Time Protocol (NTP) サーバー。コンマ区切りリストで複数の NTP サーバーを指定することも可能です (例: |
|
| 環境変数 no_proxy のカスタム値を定義します。これにより、プロキシー通信から特定のドメイン拡張子が除外されます。 |
|
|
オーバークラウドノードにアクセスする SSH ユーザーを定義します。通常、SSH アクセスは |
|
|
オーバークラウドデプロイメントに渡す追加の環境ファイル。複数回指定することが可能です。 |
|
| デプロイメントに追加する環境ファイルが格納されているディレクトリー。このコマンドは、これらの環境ファイルを最初に番号順、その後にアルファベット順で処理します。 |
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的でないエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 |
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかのクリティカルではない警告が発生した場合に終了します。 |
|
| オーバークラウドに対する検証チェックを実行しますが、オーバークラウドを実際には作成しません。 |
|
| オーバークラウドのデプロイ後の設定を省略します。 |
|
| オーバークラウドのデプロイ後の設定を強制的に行います。 |
|
| 引数とパラメーターが記載された YAML ファイルへのパス |
|
| カスタマーポータルまたは Satellite 6 にオーバークラウドノードを登録します。 |
|
|
オーバークラウドノードに使用する登録方法。Red Hat Satellite 6 または Red Hat Satellite 5 の場合は |
|
| 登録に使用する組織 |
|
| すでに登録済みでもシステムを登録します。 |
|
|
オーバークラウドノードを登録する 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 サーバーの場合は、オーバークラウドは |
|
| 登録に使用するアクティベーションキー |
環境ファイルの parameter_defaults セクションに追加する Heat テンプレートのパラメーターの使用が優先されるため、一部のコマンドラインパラメーターは古いか非推奨となっています。以下の表では、非推奨となったパラメーターと、それに相当する Heat テンプレートのパラメーターを対照しています。
| パラメーター | 説明 | Heat テンプレートのパラメーター |
|---|---|---|
|
| スケールアウトするコントローラーノードの数 |
|
|
| スケールアウトするコンピュートノードの数 |
|
|
| スケールアウトする Ceph Storage ノードの数 |
|
|
| スケールアウトする Cinder ノード数 |
|
|
| スケールアウトする Swift ノード数 |
|
|
| コントローラーノードに使用するフレーバー |
|
|
| コンピュートノードに使用するフレーバー |
|
|
| Ceph Storage ノードに使用するフレーバー |
|
|
| Cinder ノードに使用するフレーバー |
|
|
| Swift Storage ノードに使用するフレーバー |
|
|
| フラットなネットワークが neutron プラグインで設定されるように定義します。外部ネットワークを作成ができるようにデフォルトは「datacentre」に設定されています。 |
|
|
| 各ハイパーバイザーで作成する Open vSwitch ブリッジ。デフォルトは「br-ex」です。通常、このパラメーターを変更する必要はありません。 |
|
|
| 使用する論理ブリッジから物理ブリッジへのマッピング。ホストの外部ブリッジ (br-ex) を物理名 (datacentre) にマッピングするようにデフォルト設定されています。これは、デフォルトの Floating ネットワークに使用されます。 |
|
|
| ネットワークノード向けに br-ex にブリッジするインターフェースを定義します。 |
|
|
| Neutron のテナントネットワーク種別 |
|
|
| neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します。 |
|
|
| テナントネットワークを割り当てに使用できる GRE トンネリングの ID 範囲 |
|
|
| テナントネットワークを割り当てに使用できる VXLAN VNI の ID 範囲 |
|
|
| サポートされる Neutron ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク datacentre 上の任意の VLAN を許可するように設定されています。 |
|
|
| neutron テナントネットワークのメカニズムドライバー。デフォルトは「openvswitch」です。複数の値を指定するには、コンマ区切りの文字列を使用します。 |
|
|
| VLAN で区切られたネットワークまたは neutron でのフラットネットワークを使用するためにトンネリングを無効化します。 | パラメーターのマッピングなし |
|
| オーバークラウドの作成プロセスでは、デプロイメントの前に一連のチェックが行われます。このオプションは、デプロイメント前のチェックで何らかの致命的なエラーが発生した場合に終了します。どのようなエラーが発生してもデプロイメントが失敗するので、このオプションを使用することを推奨します。 | パラメーターのマッピングなし |
これらのパラメーターは、Red Hat OpenStack Platform の今後のリリースで廃止される予定です。
オプションの完全一覧については、以下のコマンドを実行します。
openstack help overcloud deploy
$ openstack help overcloud deploy
5.7. オーバークラウド作成時の環境ファイルの追加 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドをカスタマイズするには、-e を指定して、環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。以下の一覧は、環境ファイルの順序の例です。
- 各ロールおよびそのフレーバーごとのノード数。オーバークラウドを作成するには、この情報の追加は不可欠です。
-
任意のネットワーク分離ファイル。heat テンプレートコレクションの初期化ファイル (
environments/network-isolation.yaml) から開始して、次にカスタムの NIC 設定ファイル、最後に追加のネットワーク設定の順番です。 - 外部のロードバランシングの環境ファイル
- Ceph Storage、NFS、iSCSI などのストレージ環境ファイル
- Red Hat CDN または Satellite 登録用の環境ファイル
- その他のカスタム環境ファイル
-e オプションを使用してオーバークラウドに追加した環境ファイルはいずれも、オーバークラウドのスタック定義の一部となります。以下のコマンドは、追加するカスタム環境ファイルを使用してオーバークラウドの作成を開始する方法の一例です。
上記のコマンドでは、以下の追加オプションも使用できます。
-
--templates:/usr/share/openstack-tripleo-heat-templatesの Heat テンプレートコレクションを使用してオーバークラウドを作成します。 -e ~/templates/node-info.yaml:-eオプションにより、オーバークラウドのデプロイメントに別の環境ファイルを追加します。ここでは、各ロールのノード数および使用するフレーバーを定義するカスタム環境ファイルを追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml:-eオプションにより、オーバークラウドのデプロイメントに別の環境ファイルを追加します。ここでは、ネットワーク分離の設定を初期化する環境ファイルを追加します。 -
-e ~/templates/network-environment.yaml:-eオプションにより、オーバークラウドのデプロイメントに別の環境ファイルを追加します。ここでは、ネットワーク分離のカスタマイズが含まれるネットワーク環境ファイルを追加します。 -
-e ~/templates/storage-environment.yaml:-eオプションにより、オーバークラウドのデプロイメントに別の環境ファイルを追加します。ここでは、ストレージ設定を初期化するカスタム環境ファイルを追加します。 -
--ntp-server pool.ntp.org: 時刻の同期に NTP サーバーを使用します。コントローラーノードクラスターの同期を保つのに、このオプションが役立ちます。
director は、「7章オーバークラウド作成後のタスクの実行」に記載の再デプロイおよびデプロイ後の機能にこれらの環境ファイルを必要とします。これらのファイルが含まれていない場合には、オーバークラウドが破損する可能性があります。
オーバークラウド設定を後で変更する予定の場合には、以下の作業を行う必要があります。
- カスタムの環境ファイルおよび Heat テンプレートのパラメーターを変更します。
-
同じ環境ファイルを指定して
openstack overcloud deployコマンドを再度実行します。
オーバークラウドの設定は直接編集しないでください。手動で設定しても、director でオーバークラウドスタックの更新を行う際に、director の設定で上書きされてしまいます。
環境ファイルディレクトリーの追加
--environment-directory オプションを使用して、環境ファイルを格納しているディレクトリー全体を追加することも可能です。デプロイメントコマンドにより、このディレクトリー内の環境ファイルは、最初に番号順、その後にアルファベット順で処理されます。この方法を使用する場合には、ファイルの処理順を制御するために、ファイル名に数字のプレフィックスを使用することを推奨します。以下に例を示します。
以下のデプロイメントコマンドを実行してディレクトリーを追加します。
openstack overcloud deploy --templates --environment-directory ~/templates
$ openstack overcloud deploy --templates --environment-directory ~/templates
回答ファイルの使用
回答ファイルは、テンプレートおよび環境ファイルの追加を簡素化する YAML ファイルです。回答ファイルでは、以下のパラメーターを使用します。
- templates
-
使用するコア Heat テンプレートコレクション。これは、
--templatesのコマンドラインオプションの代わりとして機能します。 - environments
-
追加する環境ファイルの一覧。これは、
--environment-file(-e) のコマンドラインオプションの代わりとして機能します。
たとえば、回答ファイルには以下の内容を含めることができます。
以下のデプロイメントコマンドを実行して回答ファイルを追加します。
openstack overcloud deploy --answers-file ~/answers.yaml
$ openstack overcloud deploy --answers-file ~/answers.yaml
5.8. オーバークラウドプランの管理 リンクのコピーリンクがクリップボードにコピーされました!
openstack overcloud deploy コマンドを使用する代わりに、director を使用してインポートしたプランを管理することもできます。
新規プランを作成するには、以下のコマンドを stack ユーザーとして実行します。
openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud
$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates my-overcloud
このコマンドは、/usr/share/openstack-tripleo-heat-templates 内のコア Heat テンプレートコレクションからプランを作成します。director は、入力内容に基づいてプランに名前を指定します。この例では、my-overcloud という名前です。director は、この名前をオブジェクトストレージコンテナー、ワークフロー環境、オーバークラウドスタック名のラベルとして使用します。
以下のコマンドを使用して環境ファイルからパラメーターを追加します。
openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml
$ openstack overcloud parameters set my-overcloud ~/templates/my-environment.yaml
以下のコマンドを使用してプランをデプロイします。
openstack overcloud plan deploy my-overcloud
$ openstack overcloud plan deploy my-overcloud
以下のコマンドを使用して既存のプランを削除します。
openstack overcloud plan delete my-overcloud
$ openstack overcloud plan delete my-overcloud
openstack overcloud deploy コマンドは基本的に、これらのコマンドをすべて使用して既存のプランの削除、環境ファイルを使用した新規プランのアップロード、プランのデプロイを行います。
5.9. オーバークラウドのテンプレートおよびプランの検証 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドの作成またはスタックの更新を実行する前に、Heat テンプレートと環境ファイルにエラーがないかどうかを検証します。
レンダリングされたテンプレートの作成
オーバークラウドのコア Heat テンプレートは、Jinja2 形式となっています。テンプレートを検証するには、以下のコマンドを使用して Jinja 2 のフォーマットなしでバージョンをレンダリングします。
openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation mkdir ~/overcloud-validation cd ~/overcloud-validation swift download overcloud-validation
$ openstack overcloud plan create --templates /usr/share/openstack-tripleo-heat-templates overcloud-validation
$ mkdir ~/overcloud-validation
$ cd ~/overcloud-validation
$ swift download overcloud-validation
その後の検証テストには ~/overcloud-validation のレンダリング済みテンプレートを使用します。
テンプレート構文の検証
以下のコマンドを使用して、テンプレート構文を検証します。
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]
$ 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 オプションを追加して、ネストされたテンプレートからパラメーターを解決します。
このコマンドは、テンプレート内の構文エラーを特定します。テンプレートの構文の検証が正常に行われた場合には、出力には、作成されるオーバークラウドのテンプレートのプレビューが表示されます。
5.10. オーバークラウド作成の監視 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドの作成プロセスが開始され、director によりノードがプロビジョニングされます。このプロセスは完了するまで多少時間がかかります。オーバークラウドの作成のステータスを確認するには、stack ユーザーとして別のターミナルを開き、以下のコマンドを実行します。
source ~/stackrc openstack stack list --nested
$ source ~/stackrc
$ openstack stack list --nested
openstack stack list --nested コマンドは、オーバークラウド作成の現在の段階を表示します。
5.11. オーバークラウドへのアクセス リンクのコピーリンクがクリップボードにコピーされました!
director は、director ホストからオーバークラウドに対話するための設定を行い、認証をサポートするスクリプトを作成します。director は、このファイル overcloudrc を stack ユーザーのホームディレクトリーに保存します。このファイルを使用するには、以下のコマンドを実行します。
source ~/overcloudrc
$ source ~/overcloudrc
これにより、director ホストの CLI からオーバークラウドと対話するために必要な環境変数が読み込まれます。director のホストとの対話に戻るには、以下のコマンドを実行します。
source ~/stackrc
$ source ~/stackrc
オーバークラウドの各ノードには、heat-admin と呼ばれるユーザーも含まれます。stack ユーザーには、各ノードに存在するこのユーザーに SSH 経由でアクセスすることができます。SSH でノードにアクセスするには、希望のノードの IP アドレスを特定します。
nova list
$ nova list
次に、heat-admin ユーザーとノードの IP アドレスを使用して、ノードに接続します。
ssh heat-admin@192.0.2.23
$ ssh heat-admin@192.0.2.23
5.12. オーバークラウド作成の完了 リンクのコピーリンクがクリップボードにコピーされました!
これで、コマンドラインツールを使用したオーバークラウドの作成が完了しました。作成後の機能については、「7章オーバークラウド作成後のタスクの実行」を参照してください。
第6章 Web UI を使用した基本的なオーバークラウド要件の設定 リンクのコピーリンクがクリップボードにコピーされました!
本章では、Web UI を使用した OpenStack Platform 環境の基本的な設定手順を説明します。基本設定のオーバークラウドには、カスタム機能は含まれません。ただし、『オーバークラウドの高度なカスタマイズ』に記載の手順に従って、この基本的なオーバークラウドに高度な設定オプションを追加し、仕様に合わせてカスタマイズすることができます。
本章の例では、すべてのノードが電源管理に IPMI を使用したベアメタルシステムとなっています。これ以外のサポート対象電源管理ドライバーおよびそのオプションに関する詳細は、「付録B 電源管理ドライバー」を参照してください。
ワークフロー
- ノードの定義テンプレートと手動の登録を使用して、空のノードを登録します。
- 全ノードのハードウェアを検査します。
- director にオーバークラウドプランをアップロードします。
- ノードをロールに割り当てます。
要件
- 「4章アンダークラウドのインストール」で作成して UI を有効化した director ノード
- ノードに使用するベアメタルマシンのセット。必要なノード数は、作成予定のオーバークラウドのタイプにより異なります (オーバークラウドロールに関する情報は「ノードのデプロイメントロールのプランニング」を参照してください)。これらのマシンは、各ノード種別に設定された要件に従う必要があります。これらの要件については、「オーバークラウドの要件」を参照してください。これらのノードにはオペレーティングシステムは必要ありません。director が Red Hat Enterprise Linux 7 のイメージを各ノードにコピーします。
- ネイティブ VLAN として設定したプロビジョニングネットワーク用のネットワーク接続 1 つ。全ノードは、このネイティブに接続して、「ネットワーク要件」で設定した要件に準拠する必要があります。
- その他のネットワーク種別はすべて、OpenStack サービスにプロビジョニングネットワークを使用します。ただし、ネットワークトラフィックの他のタイプに追加でネットワークを作成することができます。
6.1. Web UI へのアクセス リンクのコピーリンクがクリップボードにコピーされました!
UI は、ブラウザーでスタンドアロンのアプリケーションとして実行されます。ただし、クライアントシステムは、アンダークラウド上の以下のコンポーネントのパブリック API エンドポイントにアクセスできる必要があります。
| コンポーネント | UI の目的 |
|---|---|
|
OpenStack Identity ( | UI への認証と他のサービスのエンドポイント検出 |
|
OpenStack Orchestration ( | デプロイメントのステータス |
|
OpenStack Bare Metal ( | ノードの制御 |
|
OpenStack Object Storage ( | Heat テンプレートコレクションまたはオーバークラウドの作成に使用したプランのストレージ |
|
OpenStack Workflow ( | director タスクのアクセスおよび実行 |
|
OpenStack Messaging ( | 特定のタスクのステータスを検索する Websocket ベースのサービス |
UI はこれらのパブリック API と直接対話します。クライアントシステムがエンドポイントへのアクセスを必要とするのはそのためです。
Mozilla Firefox を使用して director の Web UI にアクセスするには、これらの OpenStack Platform パブリック API について特定サーバーのアイデンティティー例外が必要です。これらの例外の実装に関する詳細は、「付録F UI アクセスの際の Firefox サーバーの例外」を参照してください。
director の Web UI には SSL 経由でアクセスします。たとえば、アンダークラウドの IP アドレスが 192.0.2.1 の場合には、UI にアクセスするためのアドレスは https://192.0.2.1 です。Web UI はまず、以下のフィールドが含まれるログイン画面を表示します。
-
Username: director の管理ユーザー。デフォルトは
adminです。 -
Password: 管理ユーザーのパスワード。アンダークラウドホストのターミナルで
stackユーザーとしてsudo hiera admin_passwordを実行してパスワードを確認してください。
UI へのログイン時に、UI は OpenStack Identity のパブリック API にアクセスして、他のパブリック API サービスのエンドポイントを取得します。ただし、エンドポイントを変更する場合や、エンドポイントへのアクセスに別の IP を使用する場合は、director UI は /var/www/openstack-tripleo-ui/dist/tripleo_ui_config.js ファイルから設定を読み取ります。このファイルでは、以下のパラメーターが使用されます。
| パラメーター | 説明 |
|---|---|
|
|
OpenStack Identity ( |
|
|
OpenStack Orchestration ( |
|
|
OpenStack Bare Metal ( |
|
|
OpenStack Object Storage ( |
|
|
OpenStack Workflow ( |
|
|
OpenStack Messaging ( |
|
|
OpenStack Messaging ( |
tripleo_ui_config.js ファイルの例を以下に示します。
6.2. Web UI のナビゲーション リンクのコピーリンクがクリップボードにコピーされました!
UI は主に 3 つのセクションで構成されています。
- デプロイメントプラン
UI 上部のメニューアイテム。このページは UI のメインセクションとして機能し、オーバークラウドの作成に使用するプラン、各ロールに割り当てるノード、現在のオーバークラウドのステータスを定義できます。このセクションでは、デプロイメントワークフローが提供され、デプロイメントのパラメーターの設定やロールへのノードの割り当てなどオーバークラウドの作成プロセスをステップごとにガイドします。
- ノード
UI 上部のメニューアイテム。このページはノードの設定セクションとして機能し、新規ノードの登録や登録したノードのイントロスペクションの手段を提供します。このセクションでは、デプロイメントに使用することのできるノード、現在デプロイされているノード、およびメンテナンス状態のノードも定義されます。
- 検証
ページの右側のサイドパネル。このセクションでは、オーバークラウドの作成プロセスが正常に実行されるように、一連のデプロイメント前およびデプロイ後のシステムチェックが提供されます。これらの検証タスクは、デプロイメントの特定の時点で自動的に実行されます。ただし、手動で実行することもできます。実行する検証タスクの 再生 ボタンをクリックします。各検証タスクのタイトルをクリックして実行するか、検証タイトルをクリックして詳細情報を表示します。
6.3. Web UI を使用したオーバークラウドプランのインポート リンクのコピーリンクがクリップボードにコピーされました!
director UI には、オーバークラウドの設定の前にプランが必要です。このプランは通常、/usr/share/openstack-tripleo-heat-templates にあるアンダークラウド上のテンプレートなど、Heat テンプレートコレクションです。さらに、ハードウェアや環境の要件に合わせてプランをカスタマイズすることができます。オーバークラウドのカスタマイズに関する詳しい情報は『オーバークラウドの高度なカスタマイズ』を参照してください。
プランには、オーバークラウドの設定に関する 4 つの主要な手順が表示されます。
- ハードウェアの準備: ノードの登録およびイントロスペクション
- デプロイメントの設定の指定: オーバークラウドのパラメーターの設定と追加する環境ファイルの定義
- ロールの設定とノードの割り当て: ロールへのノード割り当てと、ロール固有のパラメーターの変更
- デプロイ: オーバークラウド作成の開始
アンダークラウドのインストールと設定を実行すると、プランが自動的にアップロードされます。Web UI に複数のプランをインポートすることも可能です。Deployment Plan 画面で Manage Deployments をクリックします。これにより、現在の プラン の表が表示されます。
Create New Plan をクリックすると、以下の情報の入力を求めるウィンドウが表示されます。
-
プラン名: プランのプレーンテキスト名。たとえば、
overcloud。 - アップロードの種別: Tar アーカイブ (tar.gz)、全 ローカルフォルダー (Google Chrome のみ) のいずれをアップロードするかを選択します。
- プランファイル: ブラウザーをクリックして、ローカルのファイルシステム上のプランを選択します。
director の Heat テンプレートコレクションをクライアントのマシンにコピーする必要がある場合には、ファイルをアーカイブしてコピーします。
cd /usr/share/openstack-tripleo-heat-templates/ tar -cf ~/overcloud.tar * scp ~/overcloud.tar user@10.0.0.55:~/.
$ cd /usr/share/openstack-tripleo-heat-templates/
$ tar -cf ~/overcloud.tar *
$ scp ~/overcloud.tar user@10.0.0.55:~/.
director UI がプランをアップロードしたら、プランが プラン の表に表示され、設定を行うことができます。Deployment Plan をクリックします。
6.4. Web UI を使用したノードの登録 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウド設定の最初の手順は、ノードの登録です。以下のいずれかで、ノードの登録プロセスを開始します。
- Deployment Plan 画面の 1 ハードウェアの準備 にある ノードの登録 をクリックします。
- ノード 画面の ノードの登録 をクリックします。
ノードの登録 ウィンドウが表示されます。
director には、登録するノードの一覧が必要です。以下のいずれかの方法でリストを取得できます。
- ノード定義テンプレートのアップロード: これには、ファイルからアップロード ボタンをクリックして、ファイルを選択してください。ノードの定義テンプレートの構文については、「オーバークラウドノードの登録」を参照してください。
- 各ノードの手動登録: これには、新規追加 をクリックして、ノードの詳細を提供します。
手動登録に必要な情報は以下のとおりです。
- 名前
- ノードのプレーンテキスト名。RFC3986 の非予約文字のみを使用するようにしてください。
- ドライバー
-
使用する電源管理ドライバー。この例では IPMI ドライバー (
pxe_ipmitool) を使用しています。 - IPMI IP アドレス
- IPMI デバイスの IP アドレス
- IPMI のユーザー名、IPMI のパスワード
- IPMI のユーザー名およびパスワード
- アーキテクチャー
- (オプション) システムアーキテクチャー
- CPU 数
- (オプション) ノード上の CPU 数
- メモリー (MB)
- (オプション) メモリーサイズ (MB 単位)
- ディスク (GB)
- (オプション) ハードディスクのサイズ (GB 単位)
- NIC の MAC アドレス
- ノード上のネットワークインターフェースの MAC アドレス一覧。各システムのプロビジョニング NIC の MAC アドレスのみを使用します。
UI では、pxe_ssh ドライバーを使用する KVM ホストからのノードの登録を行うこともできます。このオプションは、テストおよび評価の目的でしか使用することができない点に注意してください。Red Hat OpenStack Platform のエンタープライズ環境には推奨していません。詳細は、「SSH と virsh」を参照してください。
ノードの情報を入力した後に、ウィンドウの下の ノードの登録 をクリックします。
director によりノードが登録されます。登録が完了すると、UI を使用してノードのイントロスペクションを実行できるようになります。
6.5. Web UI を使用したノードのハードウェアのイントロスペクション リンクのコピーリンクがクリップボードにコピーされました!
director UI は各ノードでイントロスペクションプロセスを実行することができます。このプロセスを実行すると、各ノードが PXE を介してイントロスペクションエージェントをブートします。このエージェントは、ノードからハードウェアのデータを収集して、director に送り返します。次に director は、director 上で実行中の OpenStack Object Storage (swift) サービスにこのイントロスペクションデータを保管します。director は、プロファイルのタグ付け、ベンチマーキング、ルートディスクの手動割り当てなど、さまざまな目的でハードウェア情報を使用します。
ポリシーファイルを作成して、イントロスペクションの直後にノードをプロファイルに自動でタグ付けすることも可能です。ポリシーファイルを作成してイントロスペクションプロセスに組み入れる方法に関する詳しい情報は、「付録E プロファイルの自動タグ付け」を参照してください。または、UI を使用してプロファイルにノードをタグ付けすることもできます。手動でのノードのタグ付けに関する情報は、「Web UI でのロールへのノードのタグ付け」を参照してください。
イントロスペクションのプロセスを開始するには、以下のステップを実行します。
- ノード 画面に移動します。
- イントロスペクションを行うノードをすべて選択します。
- イントロスペクション をクリックします。
このプロセスが最後まで実行されて正常に終了したことを確認してください。ベアメタルノードの場合には、通常 15 分ほどかかります。
イントロスペクションのプロセスを完了したら、プロビジョニングの状態 が manageable に設定されているノードをすべて選択して、プロビジョン ボタンをクリックします。プロビジョニングの状態 が available になるまで待ちます。
ノードのプロビジョニングの準備ができました。
6.6. Web UI を使用したオーバークラウドプランのパラメーターの編集 リンクのコピーリンクがクリップボードにコピーされました!
Deployment Plan 画面では、アップロードしたプランをカスタマイズすることができます。2 デプロイメントの設定の指定 で、設定の編集 リンクをクリックして、ベースのオーバークラウドの設定を変更します。
ウィンドウには、2 つの主要なタブが表示されます。
- 全体の設定
このタブでは、オーバークラウドからの異なる機能を追加する方法を提供します。これらの機能は、プランの
capabilities-map.yamlファイルに定義されており、機能毎に異なる環境ファイルを使用します。たとえば、Storage で Storage Environment を選択すると、プランはenvironments/storage-environment.yamlファイルにマッピングされ、オーバークラウドの NFS、iSCSI、Ceph の設定を行うことができます。Other タブには、プランで検出されているが、プランに含まれるカスタムの環境ファイルを追加するのに役立つcapabilities-map.yamlには記載されていない環境ファイルが一覧表示されます。追加する機能を選択したら、Save をクリックしてください。
- パラメーター
このタブには、オーバークラウドのさまざまなベースレベルパラメーターおよび環境ファイルパラメーターが含まれます。たとえば、本セクションで各ロールのノード数を変更することができます。3 台のコントローラーノードを使用する場合は、
ControllerCountを 3 に変更します。ベースレベルのパラメーターを変更したら、Save をクリックします。
6.7. Web UI でのロールへのノードのタグ付け リンクのコピーリンクがクリップボードにコピーされました!
各ノードのハードウェアを登録、検査した後には、特定のプロファイルにノードをタグ付けします。これらのプロファイルにより、ノードを特定のフレーバーおよびデプロイメントロールと照合します。
ロールにノードを割り当てるには、Deployment Plan 画面で 3 ロールの設定とノードの割り当て セクションまでスクロールします。選択したロールの Assign Nodes をクリックします。ロールに割り当てるノードを選択することのできるウィンドウが表示されます。ロールのノードを選択したら、Assign/Unassign Selected Nodes をクリックします。
これらのノードがロールに割り当てられたら、Done をクリックして Deployment Plan 画面に戻ります。
オーバークラウドで必要なロールごとに、このタスクを完了します。
6.8. Web UI を使用したノードの編集 リンクのコピーリンクがクリップボードにコピーされました!
各ノードのロールにより、ロール固有のパラメーターを設定する手段が提供されます。Deployment Plan 画面で 3 ロールの設定とノードの割り当て セクションまでスクロールします。ロール名の横にある Edit Role Parameters アイコン (鉛筆アイコン) をクリックします。
ウィンドウには、2 つの主要なタブが表示されます。
- パラメーター
これには、さまざまなロール固有のパラメーターが含まれます。たとえば、コントローラーロールを編集する場合には、
OvercloudControlFlavorパラメーターを使用して、そのロールのデフォルトのフレーバーを変更することができます。ロール固有のパラメーターを変更したら、変更の保存 をクリックします。
- サービス
これにより、選択したロールのサービス固有のパラメーターが定義されます。左のパネルでは、選択して変更したサービス一覧が表示されます。たとえば、タイムゾーンを変更するには、
OS::TripleO:Services:TimezoneサービスをクリックしてTimeZoneパラメーターを希望のタイムゾーンに変更します。サービス固有のパラメーターを変更したら、変更の保存 をクリックしてください。
- ネットワーク設定
ネットワーク設定では、オーバークラウドのさまざまなネットワークに対して IP アドレスまたはサブネットの範囲を定義できます。
ロールのサービスパラメーターは UI に表示されますが、デフォルトではサービスは無効になっている場合があります。「Web UI を使用したオーバークラウドプランのパラメーターの編集」の説明に沿って、これらのサービスを有効化することができます。これらのサービスの有効化に関する情報は、『オーバークラウドの高度なカスタマイズ』の コンポーザブルロール のセクションも参照してください。
6.9. Web UI を使用したオーバークラウドの作成開始 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドプランが設定されたら、オーバークラウドのデプロイメントを開始することができます。そのためには、4 デプロイ セクションまでスクロールして、検証とデプロイ をクリックしてください。
アンダークラウドの検証をすべて実行しなかった場合や、すべての検証に合格しなかった場合には、警告メッセージが表示されます。アンダークラウドのホストが要件を満たしていることを確認してから、デプロイメントを実行してください。
デプロイメントの準備ができたら デプロイ をクリックしてください。
UI では、定期的に オーバークラウド作成の進捗がモニタリングされ、現在の進捗の割合を示すプログレスバーが表示されます。詳細情報の表示 リンクでは、オーバークラウドにおける現在の OpenStack Orchestration スタックのログが表示されます。
オーバークラウドのデプロイメントが完了するまで待ちます。
オーバークラウドの作成プロセスが完了したら、4 デプロイ セクションに、現在のオーバークラウドの状況と以下の詳細が表示されます。
- オーバークラウドの IP アドレス: オーバークラウドにアクセスするための IP アドレス
-
パスワード: オーバークラウドの
adminユーザーのパスワード
この情報を使用してオーバークラウドにアクセスします。
6.10. オーバークラウド作成の完了 リンクのコピーリンクがクリップボードにコピーされました!
これで director の UI を使用したオーバークラウドの作成が完了しました。作成後の機能については、「7章オーバークラウド作成後のタスクの実行」を参照してください。
第7章 オーバークラウド作成後のタスクの実行 リンクのコピーリンクがクリップボードにコピーされました!
本章では、任意のオーバークラウドを作成後に実行するタスクについて考察します。
7.1. オーバークラウドのテナントネットワークの作成 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドには、インスタンス用のテナントネットワークが必要です。source コマンドで overcloud を読み込んで、Neutron で初期テナントネットワークを作成します。以下に例を示します。
source ~/overcloudrc openstack network create default openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
$ source ~/overcloudrc
$ openstack network create default
$ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
上記のステップにより、default という名前の基本的な Neutron ネットワークが作成されます。オーバークラウドは、内部 DHCP メカニズムを使用したこのネットワークから、IP アドレスを自動的に割り当てます。
neutron net-list により、作成したネットワークを確認します。
7.2. オーバークラウドの外部ネットワークの作成 リンクのコピーリンクがクリップボードにコピーされました!
インスタンスに Floating IP を割り当てることができるように、オーバークラウドで外部ネットワークを作成する必要があります。
ネイティブ VLAN の使用
以下の手順では、外部ネットワーク向けの専用インターフェースまたはネイティブの VLAN が設定されていることが前提です。
source コマンドで overcloud を読み込み、Neutron で外部ネットワークを作成します。以下に例を示します。
source ~/overcloudrc openstack network create public --external --provider-network-type flat --provider-physical-network datacentre 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
$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
$ 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
以下の例では、public という名前のネットワークを作成します。オーバークラウドでは、デフォルトの Floating IP プールにこの特定の名前が必要です。このネットワークは、「オーバークラウドの検証」の検証テストでも重要となります。
このコマンドにより、ネットワークと datacentre の物理ネットワークのマッピングも行われます。デフォルトでは、datacentre は br-ex ブリッジにマッピングされます。オーバークラウドの作成時にカスタムの Neutron の設定を使用していない限りは、このオプションはデフォルトのままにしてください。
非ネイティブ VLAN の使用
ネイティブ VLAN を使用しない場合には、以下のコマンドでネットワークを VLAN に割り当てます。
source ~/overcloudrc openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104 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
$ source ~/overcloudrc
$ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 104
$ 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
provider:segmentation_id の値は、使用する VLAN を定義します。この場合は、104 を使用します。
neutron net-list により、作成したネットワークを確認します。
7.3. 追加の Floating IP ネットワークの作成 リンクのコピーリンクがクリップボードにコピーされました!
Floating IP ネットワークは、以下の条件を満たす限りは、br-ex だけでなく、どのブリッジにも使用することができます。
-
ネットワーク環境ファイルで、
NeutronExternalNetworkBridgeが"''"に設定されている。 デプロイ中に追加のブリッジをマッピングしている。たとえば、
br-floatingという新規ブリッジをfloatingという物理ネットワークにマッピングするには、以下のコマンドを実行します。openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --neutron-bridge-mappings datacentre:br-ex,floating:br-floating
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml --neutron-bridge-mappings datacentre:br-ex,floating:br-floatingCopy to Clipboard Copied! Toggle word wrap Toggle overflow
オーバークラウドの作成後に Floating IP ネットワークを作成します。
openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105 openstack subnet create ext-subnet --network ext-net --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
$ openstack network create ext-net --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
$ openstack subnet create ext-subnet --network ext-net --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
7.4. オーバークラウドのプロバイダーネットワークの作成 リンクのコピーリンクがクリップボードにコピーされました!
プロバイダーネットワークは、デプロイしたオーバークラウドの外部に存在するネットワークに物理的に接続されたネットワークです。これは、既存のインフラストラクチャーネットワークや、Floating IP の代わりにルーティングによって直接インスタンスに外部アクセスを提供するネットワークを使用することができます。
プロバイダーネットワークを作成する際には、ブリッジマッピングを使用する物理ネットワークに関連付けます。これは、Floating IP ネットワークの作成と同様です。コンピュートノードは、仮想マシンの仮想ネットワークインターフェースをアタッチされているネットワークインターフェースに直接接続するため、プロバイダーネットワークはコントローラーとコンピュートの両ノードに追加します。
たとえば、使用するプロバイダーネットワークが br-ex ブリッジ上の VLAN の場合には、以下のコマンドを使用してプロバイダーネットワークを VLAN 201 上に追加します。
openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share
$ openstack network create provider_network --provider-physical-network datacentre --provider-network-type vlan --provider-segment 201 --share
このコマンドにより、共有ネットワークが作成されます。また、--share と指定する代わりにテナントを指定することも可能です。そのネットワークは、指定されたテナントに対してのみ提供されます。プロバイダーネットワークを外部としてマークした場合には、そのネットワークでポートを作成できるのはオペレーターのみとなります。
Neutron が DHCP サービスをテナントのインスタンスに提供するように設定するには、プロバイダーネットワークにサブネットを追加します。
openstack subnet create provider-subnet --network provider_network --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
$ openstack subnet create provider-subnet --network provider_network --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
他のネットワークがプロバイダーネットワークを介して外部にアクセスする必要がある場合があります。このような場合には、新規ルーターを作成して、他のネットワークがプロバイダーネットワークを介してトラフィックをルーティングできるようにします。
openstack router create external openstack router set --external-gateway provider_network external
$ openstack router create external
$ openstack router set --external-gateway provider_network external
このルーターに他のネットワークを接続します。たとえば、subnet1 という名前のサブネットがある場合には、以下のコマンドを実行してルーターに接続することができます。
openstack router add subnet external subnet1
$ openstack router add subnet external subnet1
これにより、subnet1 がルーティングテーブルに追加され、subnet1 を使用するトラフィックをプロバイダーネットワークにルーティングできるようになります。
7.5. 基本的なオーバークラウドフレーバーの作成 リンクのコピーリンクがクリップボードにコピーされました!
本ガイドの検証ステップは、インストール環境にフレーバーが含まれていることを前提としてます。まだ 1 つのフレーバーも作成していない場合には、以下のコマンドを使用してさまざまなストレージおよび処理能力に対応する基本的なデフォルトフレーバーセットを作成してください。
コマンドオプション
- ram
-
フレーバーの最大 RAM を定義するには、
ramオプションを使用します。 - disk
-
フレーバーのハードディスク容量を定義するには、
diskオプションを使用します。 - vcpus
-
フレーバーの仮想 CPU 数を定義するには、
vcpusオプションを使用します。
openstack flavor create コマンドについての詳しい情報は、$ openstack flavor create --help で確認してください。
7.6. オーバークラウドの検証 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドは、OpenStack Integration Test Suite (tempest) ツールセットを使用して、一連の統合テストを行います。本項には、統合テストの実行準備に関する情報を記載します。OpenStack Integration Test Suite の使用方法に関する詳しい説明は、『OpenStack Integration Test Suite ガイド』を参照してください。
Integration Test Suite の実行前
アンダークラウドからこのテストを実行する場合は、アンダークラウドのホストがオーバークラウドの内部 API ネットワークにアクセスできるようにします。たとえば、172.16.0.201/24 のアドレスを使用して内部 API ネットワーク (ID: 201) にアクセスするにはアンダークラウドホストに一時的な VLAN を追加します。
source ~/stackrc sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
$ source ~/stackrc
$ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal
$ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201
OpenStack Validation を実行する前に、heat_stack_owner ロールがオーバークラウドに存在することを確認してください。
このロールが存在しない場合は、作成します。
openstack role create heat_stack_owner
$ openstack role create heat_stack_owner
Integration Test Suite の実行後
検証が完了したら、オーバークラウドの内部 API への一時接続を削除します。この例では、以下のコマンドを使用して、以前にアンダークラウドで作成した VLAN を削除します。
source ~/stackrc sudo ovs-vsctl del-port vlan201
$ source ~/stackrc
$ sudo ovs-vsctl del-port vlan201
7.7. コントローラーノードのフェンシング リンクのコピーリンクがクリップボードにコピーされました!
フェンシングとは、クラスターとそのリソースを保護するために、ノードを分離するプロセスのことです。フェンシングがないと、異常が発生したノードが原因でクラスター内のデータが破損する可能性があります。
director は、Pacemaker を使用して、高可用性のコントローラーノードクラスターを提供します。Pacemaker は、異常が発生したノードをフェンシングするのに STONITH (Shoot-The-Other-Node-In-The-Head) というプロセスを使用します。デフォルトでは、クラスターの STONITH は無効化されているため、Pacemaker がクラスター内の各ノードの電源管理を制御できるように手動で設定する必要があります。
director 上の stack ユーザーから、heat-admin ユーザーとして各ノードにログインします。オーバークラウドを作成すると自動的に stack ユーザーの SSH キーが各ノードの heat-admin にコピーされます。
pcs status コマンドで、実行中のクラスターがあることを確認します。
pcs property show コマンドで、stonith が無効になっていることを確認します。
コントローラーノードには、director がサポートするさまざまな電源管理デバイスのフェンシングエージェントのセットが含まれます。これには、以下の項目が含まれます。
| デバイス | タイプ |
|
| Intelligent Platform Management Interface (IPMI) |
|
| Dell Remote Access Controller (DRAC) |
|
| Integrated Lights-Out (iLO) |
|
| Cisco UCS: 詳細は、「Configuring Cisco Unified Computing System (UCS) Fencing on an OpenStack High Availability Environment」を参照してください。 |
|
| libvirt および SSH |
本セクションの後半部分では、例として IPMI エージェント (fence_ipmilan) を取り上げます。
Pacemaker がサポートする IPMI オプションの全一覧を表示します。
sudo pcs stonith describe fence_ipmilan
$ sudo pcs stonith describe fence_ipmilan
各ノードに、電源管理を制御するための IPMI デバイスを設定する必要があります。そのためには、各ノードの Pacemaker に stonith デバイスを追加する必要があります。クラスターで以下のコマンドを使用します。
それぞれの例の 2 番目のコマンドは、ノードが自分自身のフェンシングを要求しないようにするためのものです。
コントローラーノード 0 の場合:
sudo pcs stonith create my-ipmilan-for-controller-0 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s sudo pcs constraint location my-ipmilan-for-controller-0 avoids overcloud-controller-0
$ sudo pcs stonith create my-ipmilan-for-controller-0 fence_ipmilan pcmk_host_list=overcloud-controller-0 ipaddr=192.0.2.205 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-0 avoids overcloud-controller-0
コントローラーノード 1 の場合:
sudo pcs stonith create my-ipmilan-for-controller-1 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s sudo pcs constraint location my-ipmilan-for-controller-1 avoids overcloud-controller-1
$ sudo pcs stonith create my-ipmilan-for-controller-1 fence_ipmilan pcmk_host_list=overcloud-controller-1 ipaddr=192.0.2.206 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-1 avoids overcloud-controller-1
コントローラーノード 2 の場合:
sudo pcs stonith create my-ipmilan-for-controller-2 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.207 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s sudo pcs constraint location my-ipmilan-for-controller-2 avoids overcloud-controller-2
$ sudo pcs stonith create my-ipmilan-for-controller-2 fence_ipmilan pcmk_host_list=overcloud-controller-2 ipaddr=192.0.2.207 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
$ sudo pcs constraint location my-ipmilan-for-controller-2 avoids overcloud-controller-2
すべての stonith リソースを表示するには、以下のコマンドを実行します。
sudo pcs stonith show
$ sudo pcs stonith show
特定の stonith リソースを表示するには、以下のコマンドを実行します。
sudo pcs stonith show [stonith-name]
$ sudo pcs stonith show [stonith-name]
最後に、stonith 属性を true に設定してフェンシングを有効にします。
sudo pcs property set stonith-enabled=true
$ sudo pcs property set stonith-enabled=true
属性を確認します。
sudo pcs property show
$ sudo pcs property show
7.8. オーバークラウド環境の変更 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドを変更して、別機能を追加したり、操作の方法を変更したりする場合があります。オーバークラウドを変更するには、カスタムの環境ファイルと Heat テンプレートに変更を加えて、最初に作成したオーバークラウドから openstack overcloud deploy コマンドをもう 1 度実行します。たとえば、「CLI ツールを使用したオーバークラウドの作成」の方法を使用してオーバークラウドを作成した場合には、以下のコマンドを再度実行します。
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
director は Heat 内の overcloud スタックを確認してから、環境ファイルと Heat テンプレートのあるスタックで各アイテムを更新します。オーバークラウドは再度作成されずに、既存のオーバークラウドに変更が加えられます。
新しい環境ファイルを追加する場合は、-e オプションを使用して openstack overcloud deploy コマンドにそのファイルを追加します。以下に例を示します。
openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/new-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e ~/templates/network-environment.yaml -e ~/templates/storage-environment.yaml -e ~/templates/new-environment.yaml --control-scale 3 --compute-scale 3 --ceph-storage-scale 3 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --ntp-server pool.ntp.org --neutron-network-type vxlan --neutron-tunnel-types vxlan
これにより、環境ファイルからの新規パラメーターやリソースがスタックに追加されます。
director により後で上書きされてしまう可能性があるので、オーバークラウドの設定には手動で変更を加えないことを推奨します。
7.9. オーバークラウドへの仮想マシンのインポート リンクのコピーリンクがクリップボードにコピーされました!
既存の OpenStack 環境があり、仮想マシンを Red Hat OpenStack Platform 環境に移行する予定がある場合には、以下の手順を使用します。
実行中のサーバーのスナップショットを作成して新規イメージを作成し、そのイメージをダウンロードします。
openstack server image create instance_name --name image_name openstack image save image_name --file exported_vm.qcow2
$ openstack server image create instance_name --name image_name
$ openstack image save image_name --file exported_vm.qcow2
エクスポートしたイメージをオーバークラウドにアップロードして、新しいインスタンスを起動します。
openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare openstack server create imported_instance --key-name default --flavor m1.demo --image imported_image --nic net-id=net_id
$ openstack image create imported_image --file exported_vm.qcow2 --disk-format qcow2 --container-format bare
$ 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 を使用したスナップショットでは、元の階層化システムが失われます。
7.10. Ansible による自動化の実行 リンクのコピーリンクがクリップボードにコピーされました!
director を使用すると、Ansible ベースの自動化を OpenStack Platform 環境で実行することができます。director は、tripleo-ansible-inventory コマンドを使用して、環境内にノードの動的インベントリーを生成します。
動的インベントリーツールには、アンダークラウドならびにデフォルトの コントローラー および コンピュート オーバークラウドノードだけが含まれます。その他のロールはサポートされていません。
ノードの動的インベントリーを表示するには、stackrc を読み込んだ後に tripleo-ansible-inventory コマンドを実行します。
souce ~/stackrc tripleo-ansible-inventory --list
$ souce ~/stackrc
$ tripleo-ansible-inventory --list
--list オプションを指定すると、全ホストの詳細が表示されます。
これにより、動的インベントリーが JSON 形式で出力されます。
{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.0.2.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.0.2.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.0.2.3"]}
{"overcloud": {"children": ["controller", "compute"], "vars": {"ansible_ssh_user": "heat-admin"}}, "controller": ["192.0.2.2"], "undercloud": {"hosts": ["localhost"], "vars": {"overcloud_horizon_url": "http://192.0.2.4:80/dashboard", "overcloud_admin_password": "abcdefghijklm12345678", "ansible_connection": "local"}}, "compute": ["192.0.2.3"]}
お使いの環境で Ansible による自動化を実行するには、-i オプションを使用して動的インベントリーツールの完全パスを指定して ansible コマンドを実行します。以下に例を示します。
ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
ansible [HOSTS] -i /bin/tripleo-ansible-inventory [OTHER OPTIONS]
[HOSTS]は使用するホストの種別に置き換えます。以下に例を示します。-
全コントローラーノードの場合には
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 ベースの設定を上書きする可能性があります。
7.11. オーバークラウドの削除防止 リンクのコピーリンクがクリップボードにコピーされました!
heat stack-delete overcloud コマンドでオーバークラウドが誤って削除されるのを防ぐために、Heat には特定のアクションを制限するポリシーセットが含まれています。/etc/heat/policy.json を編集して、以下のパラメーターを探します。
"stacks:delete": "rule:deny_stack_user"
"stacks:delete": "rule:deny_stack_user"
これを以下のように変更します。
"stacks:delete": "rule:deny_everybody"
"stacks:delete": "rule:deny_everybody"
ファイルを保存します。
これにより heat クライアントによるオーバークラウドの削除が阻止されます。オーバークラウドを削除できるようにするには、ポリシーを元の値に戻します。
7.12. オーバークラウドの削除 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドはすべて、必要に応じて削除することができます。
既存のオーバークラウドを削除します。
openstack stack delete overcloud
$ openstack stack delete overcloud
director からオーバークラウドプランを削除します。
openstack overcloud plan delete overcloud
$ openstack overcloud plan delete overcloud
オーバークラウドが削除されていることを確認します。
openstack stack list
$ openstack stack list
削除には、数分かかります。
削除が完了したら、デプロイメントシナリオの標準ステップに従って、オーバークラウドを再度作成します。
第8章 コンピュートノード間の仮想マシンの移行 リンクのコピーリンクがクリップボードにコピーされました!
特定の状況では、仮想マシンをオーバークラウド上のあるコンピュートノードから別のコンピュートノードに移行しなければならない場合があります。以下に例を示します。
- コンピュートノードのメンテナンス: コンピュートノードを一時的に停止しなければならない場合には、コンピュートノード上で実行中の仮想マシンを別のコンピュートノードに一時的に移行することができます。一般的なシナリオとしては、ハードウェアのメンテナンス、ハードウェアの修理、カーネルのアップグレード、およびソフトウェアの更新などが挙げられます。
- コンピュートノードの障害: コンピュートノードで障害の発生が予想され、保守または置き換えが必要な場合には、仮想マシンを障害のあるコンピュートノードから正常なコンピュートノードに移行する必要があります。すでに障害が発生しているコンピュートノードについては、『インスタンス&イメージガイド』の「インスタンスの退避」を参照してください。
- 負荷の再分散: 負荷を再度分散するために、1 つまたは複数の仮想マシンを別のコンピュートノードに移行することを検討できます。たとえば、コンピュートノード上の仮想マシンを 1 つにまとめて電力を節約する、ネットワーク上のリソースに物理的に近いコンピュートノードに仮想マシンを移行してレイテンシーを低減する、全コンピュートノードに仮想マシンを分散してホットスポットをなくし復元力を向上させる、等が可能です。
director は、すべての コンピュートノードがセキュアな移行を提供するように設定します。全コンピュートノードには、各ホストの nova ユーザーが移行プロセス中に他のコンピュートノードにアクセスすることができるようにするための共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、全 Compute ロールにデフォルトで含まれているメインのサービスの 1 つです (『オーバークラウドの高度なカスタマイズ』の「コンポーザブルサービスとカスタムロール」を参照)。
Red Hat OpenStack Platform 10 の最新アップデートには、ライブマイグレーション機能に必要な OS::TripleO::Services::Sshd コンポーザブルサービスが含まれています。初期リリースの director のコアテンプレートコレクションには、このサービスは含まれませんでしたが、openstack-tripleo-heat-templates-5.2.0-12 パッケージおよびそれ以降のバージョンに含まれるようになりました。
-
デフォルトのロールを使用している場合は、
openstack-tripleo-heat-templates-5.2.0-12パッケージまたはそれ以降のバージョンからの Heat テンプレートを使用するように環境を更新してください。 -
カスタムロールデータファイルを使用している場合は、
openstack-tripleo-heat-templates-5.2.0-12パッケージまたはそれ以降のバージョンからの Heat テンプレートを使用するように環境を更新し、それぞれのオーバークラウドロールにOS::TripleO::Services::Sshdサービスを含め、続いて新しいサービスが含まれるようにオーバークラウドスタックを更新してください。
詳しくは、「Red Hat OpenStack Platform director (TripleO) CVE-2017-2637 bug and Red Hat OpenStack Platform」を参照してください。
2018 年 2 月 27 日付けの RHSA-2018:0369: セキュリティーアドバイザリー および 2019 年 1 月 16 日付けの RHBA-2019:0074: バグ修正アドバイザリー は、仮想マシンの移行に影響します。
RHSA-2018:0369: セキュリティーアドバイザリー は、ドメイン XML で定義された CPU がすでに使用されているコンピュートノードへの仮想マシンのライブマイグレーションを妨ぎます。RHSA-2018:0369: セキュリティーアドバイザリー は、コールドマイグレーション、退避、サイズ変更、および復元などの操作に同じ制約を不必要に適用します。RHBA-2019:0074: バグ修正アドバイザリー は、これらをオプションにして制約を緩和します。詳細は、このアドバイザリーで導入された新たな cpu_pinning_migration_quick_fail 設定オプションを参照してください。
Red Hat では、両方のアドバイザリーを適用することを推奨します。
移行の制約についてのより詳しい情報は、「移行の制約」を参照してください。
8.1. 移行の種別 リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Platform では、以下の 2 つの移行種別がサポートされます。
ライブマイグレーション
ライブマイグレーションでは、移行先ノードの仮想マシンを起動して移行元ノードの仮想マシンをシャットダウンする操作を、仮想マシンの動作状態を維持しながらシームレスに実施します。
ライブマイグレーションでは、ほぼゼロダウンタイムで仮想マシンの移行が行われます。状況によっては、仮想マシンがライブマイグレーションを使用 できない 場合があります。移行の制約に関する詳細は、「移行の制約」を参照してください。
コールドマイグレーション
コールドマイグレーション (あるいは、非ライブマイグレーション) では、移行元コンピュートノードから移行先コンピュートノードに仮想マシンを移行する前に、nova が仮想マシンをシャットダウンします。
コールドマイグレーションでは、仮想マシンに多少のダウンタイムが発生します。ただし、コールドマイグレーションにより移行した仮想マシンは、引き続き同じボリュームおよび IP アドレスにアクセスすることができます。
移行元コンピュートノードですでに障害が発生している場合には、『インスタンス&イメージガイド』の「インスタンスの退避」を参照してください。移行を行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。
8.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 コアが使用される点です。詳細は、「NUMA ノードを使用する CPU ピニングの設定」を参照してください。
-
Data Plane Development Kit (DPDK): 仮想マシンが DPDK を使用する場合 (Open vSwitch と
dpdk-netdevを組み合わせて実行する仮想マシンなど)、仮想マシンはヒュージページも使用し、novaが仮想マシンを NUMA ノードに固定するような NUMA トポロジーが適用されます。
nova では、NUMA、CPU ピニング、または DPDK を使用する仮想マシンのライブマイグレーションが可能です。ただし、移行先コンピュートノードには、仮想マシンが移行元コンピュートノードで使用するのと同じ NUMA ノードに十分な容量がなければなりません。たとえば、仮想マシンが overcloud-compute-0 で NUMA 0 を使用している場合、仮想マシンを overcloud-compute-1 にライブマイグレーションするには、overcloud-compute-1 の NUMA 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 10 では、novaは SR-IOV を使用する仮想マシンのライブマイグレーションを行うことができません。SR-IOV を使用する仮想マシンでは、コールドマイグレーションを行う必要があります。 -
PCI パススルー: QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスを仮想マシンにアタッチすることができます。PCI パススルーを使用すると、仮想マシンは PCI デバイスに排他的にアクセスすることができ、これらのデバイスが仮想マシンのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理アドレスが必要なため、OpenStack Platform 10 では、
novaは PCI パススルーを使用する仮想マシンのライブマイグレーションをサポートしません。
8.3. 移行前の操作 リンクのコピーリンクがクリップボードにコピーされました!
1 つまたは複数の仮想マシンを移行する前に、以下の手順を実施します。
手順
アンダークラウドから、移行元コンピュートノードのホスト名および移行先コンピュートノードのホスト名を特定します。
source ~/overcloudrc openstack compute service list
$ source ~/overcloudrc $ openstack compute service listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 移行元コンピュートノード上の仮想マシンを一覧表示し、移行する仮想マシンの ID を探します。
openstack server list --host [source] --all-projects
$ openstack server list --host [source] --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow [source]を移行元コンピュートノードのホスト名に置き換えてください。
コンピュートノードをメンテナンスするための移行前の操作
メンテナンスのために移行元となるコンピュートノードを停止する場合には、メンテナンス中にスケジューラーが新しい仮想マシンを割り当てないように、アンダークラウドからそのコンピュートノードを無効にします。
openstack compute service set [source] nova-compute --disable
$ 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 設定には、AggregateInstanceExtraSpecFilter および NUMATopologyFilter 等の適切な値を設定する必要があります。そのためには、環境ファイルの NovaSchedulerDefaultFilters heat パラメーターを設定します。
NUMA、CPU ピニング、または DPDK 仮想マシンの移行先コンピュートノードが無効ではない場合には、これを無効にしてスケジューラーがそのノードに仮想マシンを割り当てるのを防ぎます。
openstack compute service set [dest] nova-compute --disable
$ openstack compute service set [dest] nova-compute --disableCopy to Clipboard Copied! Toggle word wrap Toggle overflow [dest]を移行先コンピュートノードのホスト名に置き換えてください。複数の DPDK または NUMA 仮想マシンを移行する場合に移行元コンピュートノードから先に移行していた仮想マシンを除き、移行先コンピュートノードには仮想マシンが存在しないようにしてください。
openstack server list --host [dest] --all-projects
$ openstack server list --host [dest] --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow [dest]を移行先コンピュートノードのホスト名に置き換えてください。移行先コンピュートノードに、NUMA、CPU ピニング、または DPDK 仮想マシンを実行するのに十分なリソースを確保するようにしてください。
openstack host show overcloud-compute-n ssh overcloud-compute-n numactl --hardware exit
$ openstack host show overcloud-compute-n $ ssh overcloud-compute-n $ numactl --hardware $ exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow overcloud-compute-nを移行先コンピュートノードのホスト名に置き換えてください。移行元または移行先コンピュートノードの NUMA 情報を検出するには、必要に応じて以下のコマンドを実行します。
ssh root@overcloud-compute-n lscpu && lscpu | grep NUMA virsh nodeinfo virsh capabilities exit
$ ssh root@overcloud-compute-n # lscpu && lscpu | grep NUMA # virsh nodeinfo # virsh capabilities # exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow sshを使用して、overcloud-compute-nに接続します。ここで、overcloud-compute-nは移行元または移行先コンピュートノードです。仮想マシンが NUMA を使用しているかどうか不明な場合は、仮想マシンのフレーバーを確認してください。
openstack server list -c Name -c Flavor --name [vm]
$ openstack server list -c Name -c Flavor --name [vm]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。続いてフレーバーを確認します。
openstack flavor show [flavor]
$ openstack flavor show [flavor]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [flavor]をフレーバーの名前または ID に置き換えてください。表示されるpropertiesフィールドのhw:mem_page_sizeの値がany以外 (2MB、2048、または1GB) の場合、仮想マシンは NUMA トポロジーを持ちます。propertiesフィールドにaggregate_instance_extra_specs:pinned='true'が含まれる場合、仮想マシンは CPU ピニングを使用しています。propertiesフィールドにhw:numa_nodesが含まれる場合、novaは仮想マシンを特定の NUMA ノードに制限します。NUMA を使用する各仮想マシンについて、移行完了後に移行先コンピュートノードの NUMA トポロジーが移行元コンピュートノードの NUMA トポロジーを反映していることを確認できるように、ベースとなるコンピュートノードから NUMA トポロジーに関する情報を取得することを検討してください。
ssh root@overcloud-compute-n virsh vcpuinfo [vm] virsh numatune [vm] exit
$ ssh root@overcloud-compute-n # virsh vcpuinfo [vm] # virsh numatune [vm] # exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前に置き換えてください。vcpuinfoコマンドにより、NUMA および CPU ピニングに関する詳細が表示されます。numatuneコマンドにより、仮想マシンが使用している NUMA ノードが表示されます。
8.4. 仮想マシンのライブマイグレーション リンクのコピーリンクがクリップボードにコピーされました!
ライブマイグレーションでは、ダウンタイムを最小限に抑えて、仮想マシンを移行元コンピュートノードから移行先コンピュートノードに移動します。ただし、ライブマイグレーションがすべての仮想マシンに適しているとは限りません。補足情報は、「移行の制約」を参照してください。
手順
仮想マシンのライブマイグレーションを行うには、仮想マシンおよび移行先コンピュートノードを指定します。
openstack server migrate [vm] --live [dest] --wait
$ openstack server migrate [vm] --live [dest] --waitCopy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。[dest]を移行先コンピュートノードのホスト名に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migrationフラグを指定します。- 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
正常に移行したことを確認します。
openstack server list --host [dest] --all-projects
$ openstack server list --host [dest] --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow [dest]を移行先コンピュートノードのホスト名に置き換えてください。NUMA、CPU ピニング、または DPDK を使用する仮想マシンについて、コンピュートノードから NUMA トポロジーに関する情報を取得して、移行前の操作中に取得した NUMA トポロジーと比較することを検討してください。
ssh root@overcloud-compute-n virsh vcpuinfo [vm] virsh numatune [vm] exit
$ ssh root@overcloud-compute-n # virsh vcpuinfo [vm] # virsh numatune [vm] # exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow overcloud-compute-nをコンピュートノードのホスト名に置き換えてください。[vm]を仮想マシンの名前に置き換えてください。移行元および移行先コンピュートノードの NUMA トポロジーを比較すると、移行元および移行先コンピュートノードが同じ NUMA トポロジーを使用することを確認するのに役立ちます。- 移行するその他の仮想マシンごとに、この手順を繰り返します。
仮想マシンの移行が終了したら、「移行後の操作」に進んでください。
8.5. 仮想マシンのコールドマイグレーション リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンのコールドマイグレーションでは、仮想マシンを停止して、別のコンピュートノードに移動します。コールドマイグレーションは、PCI パススルーまたは Single-Root Input/Output Virtualization (SR-IOV) を使用する仮想マシンの移行など、ライブマイグレーションでは対応することのできない移行シナリオに対応します。移行先コンピュートノードは、スケジューラーにより自動的に選択されます。補足情報は、「移行の制約」を参照してください。
手順
仮想マシンを移行するには、仮想マシンを指定します。
openstack server migrate [vm] --wait
$ openstack server migrate [vm] --waitCopy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの ID に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migrationフラグを指定します。- 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
移行が正常に完了したことを確認します。
openstack server list --all-projects
$ openstack server list --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
仮想マシンの移行が終了したら、「移行後の操作」に進んでください。
8.6. 移行ステータスの確認 リンクのコピーリンクがクリップボードにコピーされました!
移行が完了するまでに、さまざまな移行状態を遷移します。正常な移行では、通常、移行状態は以下のように遷移します。
-
Queued:
novaは仮想マシン移行の要求を受け入れ、移行は保留中です。 -
Preparing:
novaは仮想マシン移行の準備中です。 -
Running:
novaは仮想マシンの移行プロセスを実行中です。 -
Post-migrating:
novaは仮想マシンを移行先コンピュートノードにビルドし、移行元コンピュートノードのリソースを解放しています。 -
Completed:
novaは仮想マシンの移行を完了し、移行元コンピュートノードのリソース解放を終了しています。
手順
仮想マシンの移行の一覧を取得します。
nova server-migration-list [vm]
$ nova server-migration-list [vm]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。移行のステータスを表示します。
nova server-migration-show [vm] [migration]
$ nova server-migration-show [vm] [migration]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。[migration]を移行の ID に置き換えてください。
仮想マシンの移行に長い時間がかったり、エラーが発生したりする場合があります。詳しくは、「移行に関するトラブルシューティング」を参照してください。
8.7. 移行後の操作 リンクのコピーリンクがクリップボードにコピーされました!
1 つまたは複数の仮想マシンを移行したら以下の手順を確認し、必要に応じてそれらの手順を実施します。
コンピュートノードのメンテナンスに関する移行後の操作
メンテナンスのために移行元コンピュートノードを停止し、メンテナンスが完了したら、スケジューラーが新しい仮想マシンを移行元コンピュートノードに割り当てられるように、アンダークラウドから移行元コンピュートノードを再度有効にすることができます。
source ~/overcloudrc openstack compute service set [source] nova-compute --enable
$ 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
$ source ~/overcloudrc
$ openstack compute service set [dest] nova-compute --enable
[dest] を移行先コンピュートノードのホスト名に置き換えてください。
8.8. 移行に関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンの移行時には、さまざまな問題が発生する可能性があります。
- 移行プロセスでエラーが生じる。
- 移行プロセスが終了しない。
- 移行後に仮想マシンのパフォーマンスが低下する。
移行中のエラー
以下の問題が発生すると、移行操作が error 状態に遷移します。
- 異なるバージョンの OpenStack が存在するクラスターを実行する。
- 指定した仮想マシン ID が見つからない。
-
移行を試みている仮想マシンが
error状態にある。 - Compute サービスが停止している。
- 競合状態が発生する。
-
ライブマイグレーションが
failed状態に移行する。
ライブマイグレーションが failed 状態に移行すると、通常は error 状態になります。failed 状態の原因となる可能性のある典型的な問題を以下に示します。
- 移行先コンピュートホストが利用可能な状態にない。
- スケジューラーの例外が発生する。
- コンピューティングリソースが不十分なため、再ビルドプロセスに失敗する。
- サーバーグループの確認に失敗する。
- 移行先コンピュートノードへの移行が完了する前に、移行元コンピュートノードの仮想マシンが削除される。
ライブマイグレーションのスタック
ライブマイグレーションが時間どおりに完了せず、永久に running 状態のままになる可能性があります。ライブマイグレーションが永久に完了しない一般的な理由は、nova が仮想マシンの変更を移行先コンピュートノードに複製するより早く、クライアントのリクエストにより移行元コンピュートノード上で実行中の仮想マシンに変更が生じることです。
この状況に対処する方法はいくつかあります。
- ライブマイグレーションを中止する。
- ライブマイグレーションを強制的に完了させる。
ライブマイグレーションの中止
移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断したくない場合には、ライブマイグレーションの手順を中止することができます。
仮想マシンの移行の一覧を取得します。
nova server-migration-list [vm]
$ nova server-migration-list [vm]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。ライブマイグレーションを中止します。
nova live-migration-abort [vm] [migration]
$ nova live-migration-abort [vm] [migration]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に、[migration]を移行の ID に、それぞれ置き換えてください。
ライブマイグレーション完了の強制
移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断して移行を強制的に完了させたい場合には、ライブマイグレーションの手順を強制的に完了させることができます。
ライブマイグレーションを強制的に完了させると、かなりのダウンタイムが発生する可能性があります。
仮想マシンの移行の一覧を取得します。
nova server-migration-list [vm]
$ nova server-migration-list [vm]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。ライブマイグレーションを強制的に完了させます。
nova live-migration-force-complete [vm] [migration]
$ nova live-migration-force-complete [vm] [migration]Copy to Clipboard Copied! Toggle word wrap Toggle overflow [vm]を仮想マシンの名前または ID に置き換えてください。[migration]を移行の ID に置き換えてください。
移行後の仮想マシンのパフォーマンス低下
NUMA トポロジーを使用する仮想マシンの場合、移行元および移行先コンピュートノードの NUMA トポロジーおよび設定は同一でなければなりません。移行先コンピュートノードの NUMA トポロジーでは、十分なリソースが利用可能でなければなりません。移行元および移行先コンピュートノード間で NUMA 設定が同一でない場合、ライブマイグレーションは成功するが仮想マシンのパフォーマンスが低下する可能性があります。たとえば、移行元コンピュートノードは NIC 1 を NUMA ノード 0 にマッピングするが、移行先コンピュートノードは NIC 1 を NUMA ノード 5 にマッピングする場合、移行後に仮想マシンはバス内の最初の CPU からのネットワークトラフィックを NUMA ノード 5 の別の CPU にルーティングし、トラフィックを NIC 1 にルーティングする可能性があります。その結果、予想されたとおりに動作はしますが、パフォーマンスが低下します。同様に、移行元コンピュートノードの NUMA ノード 0 では十分な CPU および RAM が利用可能だが、移行先コンピュートノードの NUMA ノード 0 にリソースの一部を使用する仮想マシンがすでに存在する場合、仮想マシンは正常に動作するがパフォーマンスが低下する可能性があります。補足情報は、「移行の制約」を参照してください。
第9章 オーバークラウドのスケーリング リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドからノードを削除する場合は、openstack server delete を使用しないでください。本項で説明する手順をよく読み、適切にノードの削除/置き換えを行ってください。
オーバークラウドの作成後に、ノードを追加または削除する必要がある場合があります。たとえば、オーバークラウドのコンピュートノードを追加する場合などです。このような状況では、オーバークラウドの更新が必要です。
以下の表を使用して、各ノード種別のスケーリングに対するサポートを判断してください。
| ノード種別 | スケールアップ | スケールダウン | 説明 |
| コントローラー | 非対応 | 非対応 | |
| コンピュート | 対応 | 対応 | |
| Ceph Storage ノード | 対応 | 非対応 | オーバークラウドを最初に作成する際に Ceph Storage ノードを 1 つ以上設定する必要があります。 |
| ブロックストレージノード | 非対応 | 非対応 | |
| オブジェクトストレージノード | 対応 | 対応 | 「オブジェクトストレージノードの置き換え」で説明するように、手動でリングを管理する必要があります。 |
オーバークラウドをスケーリングする前には、少なくとも 10 GB の空き領域を確保するようにしてください。この空き領域は、イメージの変換やノードのプロビジョニングプロセスのキャッシュに使用されます。
9.1. 新たなノードの追加 リンクのコピーリンクがクリップボードにコピーされました!
director のノードプールにさらにノードを追加するには、登録する新規ノードの詳細を記載した新しい JSON ファイル (例: newnodes.json) を作成します。
これらのパラメーターについての説明は、「オーバークラウドノードの登録」を参照してください。
以下のコマンドを実行して、これらのノードを登録します。
openstack baremetal import --json newnodes.json
$ openstack baremetal import --json newnodes.json
新規ノードを登録したら、これらのノードのイントロスペクションプロセスを起動します。それぞれの新規ノードに対して、以下のコマンドを使用します。
openstack baremetal node manage [NODE UUID] openstack overcloud node introspect [NODE UUID] --provide
$ openstack baremetal node manage [NODE UUID]
$ openstack overcloud node introspect [NODE UUID] --provide
これにより、ノードのハードウェアプロパティーの検出とベンチマークが実行されます。
イントロスペクションプロセスが完了したら、各新規ノードを目的のロールにタグ付けします。たとえば、コンピュートノードの場合は、以下のコマンドを使用します。
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]
$ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]
オーバークラウドをスケーリングするには、ロールに必要なノード数を指定して openstack overcloud deploy を再度実行する必要があります。たとえば、コンピュートノードを 5 台にスケーリングするには、以下のコマンドを実行します。
openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]
$ openstack overcloud deploy --templates --compute-scale 5 [OTHER_OPTIONS]
これにより、オーバークラウドのスタック全体が更新されます。これにより更新されるのはスタックだけである点に注意してください。オーバークラウドの削除や、スタックの置き換えは行われません。
最初に作成したオーバークラウドからの環境ファイルおよびオプションをすべて追加するようにしてください。これには、コンピュート以外のノードに対する同様のスケジューリングパラメーターが含まれます。
9.2. コンピュートノードの削除 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドからコンピュートノードを削除する必要がある状況が出てくる可能性があります。たとえば、問題のあるコンピュートノードを置き換える必要がある場合などです。
オーバークラウドからコンピュートノードを削除する前に、負荷をそのノードから別のコンピュートノードに移行してください。詳しくは、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
次に、オーバークラウド上でノードの Compute サービスを無効にします。これにより、ノードで新規インスタンスがスケジューリングされないようになります。
source ~/overcloudrc openstack compute service list openstack compute service set [hostname] nova-compute --disable source ~/stackrc
$ source ~/overcloudrc
$ openstack compute service list
$ openstack compute service set [hostname] nova-compute --disable
$ source ~/stackrc
オーバークラウドノードを削除するには、ローカルのテンプレートファイルを使用して、director の overcloud スタックへの更新が必要です。最初にオーバークラウドスタックの UUID を特定します。
openstack stack list
$ openstack stack list
削除するノードの UUID を特定します。
openstack server list
$ openstack server list
以下のコマンドを実行して、オーバークラウドのプランを更新し、スタックからノードを削除します。
オーバークラウドの作成時に追加の環境ファイルを渡した場合には、予定外の手動変更がオーバークラウドに加えられないように、ここで -e または --environment-file オプションを使用して環境ファイルを再度渡します。
操作を続行する前に、openstack overcloud node delete コマンドが完全に終了したことを確認します。openstack stack list コマンドを使用して、overcloud スタックが UPDATE_COMPLETE のステータスに切り替わっていることを確認してください。
最後に、ノードの Compute サービスを削除します。
source ~/overcloudrc openstack compute service list openstack compute service delete [service-id] source ~/stackrc
$ source ~/overcloudrc
$ openstack compute service list
$ openstack compute service delete [service-id]
$ source ~/stackrc
さらに、ノードの Open vSwitch エージェントを削除します。
source ~/overcloudrc openstack network agent list openstack network agent delete [openvswitch-agent-id] source ~/stackrc
$ source ~/overcloudrc
$ openstack network agent list
$ openstack network agent delete [openvswitch-agent-id]
$ source ~/stackrc
オーバークラウドから自由にノードを削除して、別の目的でそのノードを再プロビジョニングできるようになりました。
9.3. コンピュートノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
コンピュートノードに障害が発生した場合に、そのノードを機能しているノードに置き換えることができます。コンピュートノードを置き換えるには、以下のプロセスを使用します。
- 既存のコンピュートノードから負荷を移行して、ノードをシャットダウンする。このプロセスについては、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
- オーバークラウドからコンピュートノードを削除する。このプロセスについては、「コンピュートノードの削除」を参照してください。
- 新しいコンピュートノードでオーバークラウドをスケールアウトする。このプロセスについては、「新たなノードの追加」を参照してください。
このプロセスにより、インスタンスの可用性に影響を与えずにノードを置き換えることができます。
9.4. コントローラーノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
特定の状況では、高可用性クラスター内のコントローラーノードに障害が発生することがあります。その場合は、そのコントローラーノードをクラスターから削除して新しいコントローラーノードに置き換える必要があります。この操作には、ノードがクラスター内の他のノードに接続できるようにする手順も含まれます。
本項では、コントローラーノードを置き換える手順について説明します。このプロセスでは、openstack overcloud deploy コマンドを実行し、コントローラーノードを置き換えるリクエストでオーバークラウドを更新します。このプロセスは完全には自動的に行われないことに注意してください。オーバークラウドスタックの更新プロセス中、ある時点で openstack overcloud deploy コマンドが異常を報告し、オーバークラウドスタックの更新が停止します。この時点で、プロセスに手動で介入する必要あります。その後、openstack overcloud deploy プロセスを続行することができます。
以下の手順は、高可用性環境にのみ適用されます。コントローラーノードを 1 台しか使用していない場合は、この手順を使用しないでください。
9.4.1. 事前確認 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドコントローラーノードの置き換えを試みる前に、Red Hat OpenStack Platform 環境の現在の状態をチェックしておくことが重要です。このチェックしておくと、コントローラーの置き換えプロセス中に複雑な事態が発生するのを防ぐことができます。以下の事前チェックリストを使用して、コントローラーノードの置き換えを実行しても安全かどうかを確認してください。チェックのためのコマンドはすべてアンダークラウドで実行します。
アンダークラウドで、
overcloudスタックの現在の状態をチェックします。source stackrc openstack stack list --nested
$ source stackrc $ openstack stack list --nestedCopy to Clipboard Copied! Toggle word wrap Toggle overflow overcloudスタックと後続の子スタックは、CREATE_COMPLETEまたはUPDATE_COMPLETEのステータスである必要があります。アンダークラウドデータベースのバックアップを実行します。
mkdir /home/stack/backup sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz sudo systemctl stop openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service sudo cp /var/lib/ironic-inspector/inspector.sqlite /home/stack/backup sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service
$ mkdir /home/stack/backup $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz $ sudo systemctl stop openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.service $ sudo cp /var/lib/ironic-inspector/inspector.sqlite /home/stack/backup $ sudo systemctl start openstack-ironic-api.service openstack-ironic-conductor.service openstack-ironic-inspector.service openstack-ironic-inspector-dnsmasq.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - アンダークラウドに、新規ノードプロビジョニング時のイメージのキャッシュと変換に対応できる 10 GB の空きストレージ領域があることを確認します。
コントローラーノードで実行中の Pacemaker の状態をチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドで Pacemaker のステータス情報を取得します。
ssh heat-admin@192.168.0.47 'sudo pcs status'
$ ssh heat-admin@192.168.0.47 'sudo pcs status'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力には、既存のノードで実行中のサービスと、障害が発生しているノードで停止中のサービスがすべて表示されるはずです。
オーバークラウドの MariaDB クラスターの各ノードで、以下のパラメーターを確認します。
-
wsrep_local_state_comment: Synced wsrep_cluster_size: 2実行中の各コントローラーノード (IP アドレスは、それぞれ 192.168.0.47 および 192.168.0.46 を使用します) で以下のコマンドを使用して、これらのパラメーターを確認します。
for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done
$ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
RabbitMQ のステータスをチェックします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してステータスを取得します。
ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"
$ ssh heat-admin@192.168.0.47 "sudo rabbitmqctl cluster_status"Copy to Clipboard Copied! Toggle word wrap Toggle overflow running_nodesキーには、障害が発生しているノードは表示されず、稼働中のノード 2 台のみが表示されるはずです。フェンシングが有効化されている場合には無効にします。たとえば、実行中のコントローラーノードの IP アドレスが 192.168.0.47 の場合には、以下のコマンドを実行してフェンシングを無効にします。
ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"
$ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してフェンシングのステータスを確認します。
ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
$ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"Copy to Clipboard Copied! Toggle word wrap Toggle overflow director ノードで
nova-computeサービスをチェックします。sudo systemctl status openstack-nova-compute openstack hypervisor list
$ sudo systemctl status openstack-nova-compute $ openstack hypervisor listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力では、メンテナンスモードに入っていないすべてのノードが
upのステータスで表示されるはずです。アンダークラウドサービスがすべて実行中であることを確認します。
sudo systemctl -t service
$ sudo systemctl -t serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4.2. Ceph monitor デーモンの削除 リンクのコピーリンクがクリップボードにコピーされました!
本手順では、ストレージクラスターから ceph-mon デーモンを削除します。コントローラーノードが Ceph monitor サービスを実行している場合には、以下のステップを完了して、ceph-mon デーモンを削除してください。この手順は、コントローラーが到達可能であることを前提としています。
新しい Ceph monitor デーモンは、クラスターに新しいコントローラーが追加された後に追加されます。
置き換えるコントローラーに接続して、root になります。
ssh heat-admin@192.168.0.47 sudo su -
# ssh heat-admin@192.168.0.47 # sudo su -Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記コントローラーが到達不可能な場合には、ステップ 1 と 2 をスキップして、稼働している任意のコントローラーノードでステップ 3 から手順を続行してください。
root として monitor を停止します。
systemctl stop ceph-mon@<monitor_hostname>
# systemctl stop ceph-mon@<monitor_hostname>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
systemctl stop ceph-mon@overcloud-controller-2
# systemctl stop ceph-mon@overcloud-controller-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターから monitor を削除します。
ceph mon remove <mon_id>
# ceph mon remove <mon_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ceph monitor ノード上で、
/etc/ceph/ceph.confから monitor のエントリーを削除します。たとえば、controller-2 を削除した場合には、controller-2 の IP アドレスとホスト名を削除します。編集前:
mon host = 172.18.0.21,172.18.0.22,172.18.0.24 mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0
mon host = 172.18.0.21,172.18.0.22,172.18.0.24 mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 編集後:
mon host = 172.18.0.22,172.18.0.24 mon initial members = overcloud-controller-1,overcloud-controller-0
mon host = 172.18.0.22,172.18.0.24 mon initial members = overcloud-controller-1,overcloud-controller-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow オーバークラウドノードの
/etc/ceph/ceph.confに同じ変更を適用します。注記置き換え用のコントローラーノードが追加されると、director によって該当するオーバークラウドノード上の
ceph.confファイルが更新されます。通常、この設定ファイルは director によってのみ管理され、手動で編集する必要はありませんが、このステップでは、新規ノードが追加される前に他のノードが再起動してしまった場合に一貫性を保つために、ファイルを編集しています。オプションとして、monitor データをアーカイブして、別のサーバーに保存します。
mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>
# mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4.3. ノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
削除するノードのインデックスを特定します。ノードのインデックスは、nova list の出力に表示されるインスタンス名のサフィックスです。
以下の例では、overcloud-controller-1 ノードを削除し、それを overcloud-controller-3 に置き換えます。まず、ノードをメンテナンスモードに切り替えて、director が障害の発生したノードを再プロビジョニングしないようにします。nova list で表示されるインスタンスの ID を openstack baremetal node list で表示されるノード ID に関連付けます。
ノードをメンテナンスモードに切り替えます。
openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284
[stack@director ~]$ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284
新規ノードを control プロファイルにタグ付けします。
openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf
[stack@director ~]$ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf
オーバークラウドのデータベースは、置き換え手順の実行中に稼働し続ける必要があります。この手順の実行中に Pacemaker が Galera を停止しないようにするには、実行中のコントローラーノードを選択して、そのコントローラーノードの IP アドレスを使用して、アンダークラウドで以下のコマンドを実行します。
ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"
[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"
削除するノードのインデックスを定義する YAML ファイルを作成します (~/templates/remove-controller.yaml)。
parameters:
ControllerRemovalPolicies:
[{'resource_list': ['1']}]
parameters:
ControllerRemovalPolicies:
[{'resource_list': ['1']}]
Corosync での処理の試行回数を減らすことによって、置き換えプロセスを迅速化することができます。~/templates/remove-controller.yaml 環境ファイルに CorosyncSettleTries パラメーターを追加します。
parameter_defaults: CorosyncSettleTries: 5
parameter_defaults:
CorosyncSettleTries: 5
ノードのインデックスを特定したら、remove-controller.yaml 環境ファイルを追加してオーバークラウドを再デプロイします。
openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]
オーバークラウドの作成時に追加の環境ファイルまたはオプションを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで再度それらを渡します。
ただし、-e ~/templates/remove-controller.yaml が必要なのは、この 1 回だけである点に注意してください。
director は古いノードを削除して、新しいノードを作成してから、オーバークラウドスタックを更新します。以下のコマンドを使用すると、オーバークラウドスタックのステータスをチェックすることができます。
openstack stack list --nested
[stack@director ~]$ openstack stack list --nested
9.4.4. 手動による介入 リンクのコピーリンクがクリップボードにコピーされました!
ControllerNodesPostDeployment 段階の ControllerDeployment_Step1 で、オーバークラウドスタックの更新が UPDATE_FAILED エラーにより停止します。これは、一部の Puppet モジュールがノードの置き換えをサポートしていないためです。プロセスのこの時点で手動による介入が必要です。以下の設定手順に従ってください。
コントローラーノードの IP アドレスの一覧を取得します。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存のノードの
/etc/corosync/corosync.confファイルで、削除されたノードのnodeid値を確認します。たとえば、既存のノードが 192.168.0.47 のovercloud-controller-0の場合には、以下のコマンドを実行します。ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"
[stack@director ~]$ ssh heat-admin@192.168.0.47 "sudo cat /etc/corosync/corosync.conf"Copy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより、削除されたノード (
overcloud-controller-1) の ID が含まれるnodelistが表示されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 後で使用するために、削除されたノードの
nodeidの値を書き留めておいてください。上記の例では、2 がその値です。各ノードの Corosync 設定から障害の発生したノードを削除して、Corosync を再起動します。この例では、
overcloud-controller-0およびovercloud-controller-2にログインし、以下のコマンドを実行します。[stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster reload corosync" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster reload corosync"
[stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.47 "sudo pcs cluster reload corosync" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster localnode remove overcloud-controller-1" [stack@director] ssh heat-admin@192.168.0.46 "sudo pcs cluster reload corosync"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 残りのノードの中の 1 台にログインして、
crm_nodeコマンドで対象のノードをクラスターから削除します。sudo crm_node -R overcloud-controller-1 --force
[stack@director] ssh heat-admin@192.168.0.47 [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --forceCopy to Clipboard Copied! Toggle word wrap Toggle overflow このノードにログインした状態を維持します。
障害が発生したノードを RabbitMQ クラスターから削除します。
sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
[heat-admin@overcloud-controller-0 ~]$ sudo rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 障害が発生したノードを MongoDB から削除します。まず、ノードの内部 API 接続のための IP アドレスを特定します。
sudo netstat -tulnp | grep 27017
[heat-admin@overcloud-controller-0 ~]$ sudo netstat -tulnp | grep 27017 tcp 0 0 192.168.0.47:27017 0.0.0.0:* LISTEN 13415/mongodCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードが
primaryレプリカセットであることを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow これで、現在のノードがプライマリーかどうかが表示されるはずです。プライマリーでなければ、
primaryキーで示されているノードの IP アドレスを使用します。プライマリーノードで MongoDB に接続します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MongoDB クラスターのステータスを確認します。
tripleo:PRIMARY> rs.status()
tripleo:PRIMARY> rs.status()Copy to Clipboard Copied! Toggle word wrap Toggle overflow _idキーを使用してノードを特定し、nameキーを使用して障害が発生したノードを削除します。この例では、nameが192.168.0.45:27017の Node 1 を削除します。tripleo:PRIMARY> rs.remove('192.168.0.45:27017')tripleo:PRIMARY> rs.remove('192.168.0.45:27017')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要PRIMARYレプリカセットに対してコマンドを実行する必要があります。以下のメッセージが表示される場合は、"replSetReconfig command must be sent to the current replica set primary."
"replSetReconfig command must be sent to the current replica set primary."Copy to Clipboard Copied! Toggle word wrap Toggle overflow PRIMARYに指定されているノード上の MongoDB に再ログインします。注記障害の発生したノードのレプリカセットを削除する際に、通常以下のような出力が表示されます。
2016-05-07T03:57:19.541+0000 DBClientCursor::init call() failed 2016-05-07T03:57:19.543+0000 Error: error doing query: failed at src/mongo/shell/query.js:81 2016-05-07T03:57:19.545+0000 trying reconnect to 192.168.0.47:27017 (192.168.0.47) failed 2016-05-07T03:57:19.547+0000 reconnect 192.168.0.47:27017 (192.168.0.47) ok
2016-05-07T03:57:19.541+0000 DBClientCursor::init call() failed 2016-05-07T03:57:19.543+0000 Error: error doing query: failed at src/mongo/shell/query.js:81 2016-05-07T03:57:19.545+0000 trying reconnect to 192.168.0.47:27017 (192.168.0.47) failed 2016-05-07T03:57:19.547+0000 reconnect 192.168.0.47:27017 (192.168.0.47) okCopy to Clipboard Copied! Toggle word wrap Toggle overflow MongoDB を終了します。
tripleo:PRIMARY> exit
tripleo:PRIMARY> exitCopy to Clipboard Copied! Toggle word wrap Toggle overflow Galera クラスターのノード一覧を更新します。
sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-3,overcloud-controller-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
新規ノードで Galera クラスターの確認を設定します。既存のノードから新規ノード上の同じ場所に
/etc/sysconfig/clustercheckをコピーします。 -
rootユーザーが新規ノードの Gelera にアクセスできるように設定します。既存のノードから新規ノード上の同じ場所に/root/.my.cnfをコピーします。 新規ノードをクラスターに追加します。
sudo pcs cluster node add overcloud-controller-3
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ノードの
/etc/corosync/corosync.confファイルを確認します。新規ノードのnodeidが削除したノードと同じ場合は、その値を新しい nodeid の値に更新します。たとえば、/etc/corosync/corosync.confファイルに新規ノード (overcloud-controller-3) のエントリーが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、新規ノードは削除されたノードと同じ
nodeidを使用していることに注意してください。この値を使用していないノードの ID 値に更新します。以下に例を示します。node { ring0_addr: overcloud-controller-3 nodeid: 4 }node { ring0_addr: overcloud-controller-3 nodeid: 4 }Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規ノードを含め、各コントローラーノードの
/etc/corosync/corosync.confファイルでこのnodeidの値を更新します。既存ノードでのみ Corosync サービスを再起動します。たとえば、
overcloud-controller-0で以下のコマンドを実行します。sudo pcs cluster reload corosync
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster reload corosyncCopy to Clipboard Copied! Toggle word wrap Toggle overflow また、
overcloud-controller-2で以下のコマンドを実行します。sudo pcs cluster reload corosync
[heat-admin@overcloud-controller-2 ~]$ sudo pcs cluster reload corosyncCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規ノードでこのコマンドを実行しないでください。
新規コントローラーノードを起動します。
sudo pcs cluster start overcloud-controller-3
[heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3Copy to Clipboard Copied! Toggle word wrap Toggle overflow Galera クラスターを再起動して Pacemaker の管理に戻します。
sudo pcs resource cleanup galera sudo pcs resource manage galera
[heat-admin@overcloud-controller-0 ~]$ sudo pcs resource cleanup galera [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galeraCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pacemaker を使用して、一部のサービスを有効にすると共に再起動します。クラスターはこの時点でメンテナンスモードに設定されていますが、サービスを有効にするには、このモードを一時的に無効にする必要があります。以下に例を示します。
sudo pcs property set maintenance-mode=false --wait
[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=false --waitCopy to Clipboard Copied! Toggle word wrap Toggle overflow 全ノードで Galera サービスが起動するまで待ちます。
sudo pcs status | grep galera -A1
[heat-admin@overcloud-controller-3 ~]$ sudo pcs status | grep galera -A1 Master/Slave Set: galera-master [galera] Masters: [ overcloud-controller-0 overcloud-controller-2 overcloud-controller-3 ]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要な場合には、新規ノードで
cleanupを実行します。sudo pcs resource cleanup galera --node overcloud-controller-3
[heat-admin@overcloud-controller-3 ~]$ sudo pcs resource cleanup galera --node overcloud-controller-3Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターをメンテナンスモードに戻します。
sudo pcs property set maintenance-mode=true --wait
[heat-admin@overcloud-controller-3 ~]$ sudo pcs property set maintenance-mode=true --waitCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手動の設定が完了しました。オーバークラウドのデプロイメントコマンドを再度実行して、スタックの更新を続行します。
openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
[stack@director ~]$ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
オーバークラウドの作成時に追加の環境ファイルまたはオプションを渡した場合には、予定外の変更がオーバークラウドに加えられないように、ここで再度それらを渡します。ただし、remove-controller.yaml ファイルは必要なくなった点に注意してください。
9.4.5. オーバークラウドサービスの最終処理 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドスタックの更新が完了したら、最終の設定が必要です。コントローラーノードのいずれかにログインして、Pacemaker で停止しているサービスを更新します。
for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done
[heat-admin@overcloud-controller-0 ~]$ for i in `sudo pcs status|grep -B2 Stop |grep -v "Stop\|Start"|awk -F"[" '/\[/ {print substr($NF,0,length($NF)-1)}'`; do echo $i; sudo pcs resource cleanup $i; done
最終のステータスチェックを実行して、サービスが正しく実行されていることを確認します。
sudo pcs status
[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
エラーが発生したサービスがある場合には、問題の解決後に pcs resource cleanup コマンドを使用してそのサービスを再起動します。
コントローラーノードでフェンシングが使用されている場合は、古いフェンシングレコードを削除して、新しいフェンシングレコードを作成します。
sudo pcs stonith show sudo pcs stonish delete my-ipmilan-for-controller-1 sudo pcs stonith create my-ipmilan-for-controller-3 fence_ipmilan pcmk_host_list=overcloud-controller-3 ipaddr=192.0.2.208 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s sudo pcs constraint location my-ipmilan-for-controller-3 avoids overcloud-controller-3
[heat-admin@overcloud-controller-0 ~]$ sudo pcs stonith show
[heat-admin@overcloud-controller-0 ~]$ sudo pcs stonish delete my-ipmilan-for-controller-1
[heat-admin@overcloud-controller-0 ~]$ sudo pcs stonith create my-ipmilan-for-controller-3 fence_ipmilan pcmk_host_list=overcloud-controller-3 ipaddr=192.0.2.208 login=admin passwd=p@55w0rd! lanplus=1 cipher=1 op monitor interval=60s
[heat-admin@overcloud-controller-0 ~]$ sudo pcs constraint location my-ipmilan-for-controller-3 avoids overcloud-controller-3
フェンシングの再有効化
sudo pcs property set stonith-enabled=true
[heat-admin@overcloud-controller-0 ~]$ sudo pcs property set stonith-enabled=true
フェンシングの設定に関する詳しい情報は、「コントローラーノードのフェンシング」を参照してください。
director に戻ります。
exit
[heat-admin@overcloud-controller-0 ~]$ exit
9.4.6. L3 エージェントのルーターホスティングの最終処理 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。ルーターを確認して、L3 エージェントがオーバークラウド環境でルーターを適切にホストしていることを確認します。以下の例では、r1 という名前のルーターを使用します。
source ~/overcloudrc neutron l3-agent-list-hosting-router r1
[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ neutron l3-agent-list-hosting-router r1
この一覧に、新規ノードではなく古いノードが引き続き表示される場合があります。これを置き換えるには、環境内の L3 ネットワークエージェントを一覧表示します。
neutron agent-list | grep "neutron-l3-agent"
[stack@director ~]$ neutron agent-list | grep "neutron-l3-agent"
新規ノードおよび古いノード上のエージェントの UUID を特定します。新しいノードのエージェントにルーターを追加し、古いノードからルーターを削除します。以下に例を示します。
neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1 neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1
[stack@director ~]$ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
[stack@director ~]$ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1
ルーターに対して最終の確認を実行し、すべてがアクティブであることを確認します。
neutron l3-agent-list-hosting-router r1
[stack@director ~]$ neutron l3-agent-list-hosting-router r1
古いコントローラーノードをポイントしている既存の Neutron エージェントを削除します。以下に例を示します。
neutron agent-list -F id -F host | grep overcloud-controller-1 neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb
[stack@director ~]$ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
[stack@director ~]$ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb
9.4.7. Compute サービスの最終処理 リンクのコピーリンクがクリップボードにコピーされました!
削除されたノードの Compute サービスはオーバークラウドにまだ存在しているので、削除する必要があります。オーバークラウドと対話できるようにするために、source コマンドで overcloudrc ファイルを読み込みます。削除したノードの Compute サービスをチェックします。
source ~/overcloudrc nova service-list | grep "overcloud-controller-1.localdomain"
[stack@director ~]$ source ~/overcloudrc
[stack@director ~]$ nova service-list | grep "overcloud-controller-1.localdomain"
ノードの Compute サービスを削除します。たとえば、overcloud-controller-1.localdomain の nova-scheduler サービスの ID が 5 の場合には、以下のコマンドを実行します。
nova service-delete 5
[stack@director ~]$ nova service-delete 5
削除されたノードの各サービスについて、このタスクを実行します。
新規ノードで openstack-nova-consoleauth サービスを確認します。
nova service-list | grep consoleauth
[stack@director ~]$ nova service-list | grep consoleauth
サービスが稼働していない場合には、コントローラーノードにログインしてサービスを再起動します。
pcs resource restart openstack-nova-consoleauth
[stack@director] ssh heat-admin@192.168.0.47
[heat-admin@overcloud-controller-0 ~]$ pcs resource restart openstack-nova-consoleauth
9.4.8. 結果 リンクのコピーリンクがクリップボードにコピーされました!
これで、障害が発生したコントローラーノードと関連サービスが、新規ノードに置き換えられました。
「オブジェクトストレージノードの置き換え」に示すように、オブジェクトストレージの自動リング構築を無効にしている場合は、新規ノード用にオブジェクトストレージのリングファイルを手動で構築する必要があります。リングファイルを手動で構築する方法は、「オブジェクトストレージノードの置き換え」を参照してください。
9.5. Ceph Storage ノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
director を使用して、director で作成したクラスター内の Ceph Storage ノードを置き換えることができます。その手順は、『オーバークラウド向けの Red Hat Ceph Storage』を参照してください。
9.6. オブジェクトストレージノードの置き換え リンクのコピーリンクがクリップボードにコピーされました!
本項では、クラスターの整合性を保ちながらオブジェクトストレージノードを置き換える方法を説明します。以下の例では、2 台のノードで構成されるオブジェクトストレージクラスターで、ノード overcloud-objectstorage-1 を置き換える必要があります。目的は、ノードをあと 1 台追加して、overcloud-objectstorage-1 を削除することです (結果的に、置き換えることになります)。
以下の内容で、~/templates/swift-upscale.yaml という名前の環境ファイルを作成します。
parameter_defaults: ObjectStorageCount: 3
parameter_defaults: ObjectStorageCount: 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow ObjectStorageCountは、環境内のオブジェクトストレージノード数を定義します。今回の例では、ノードを 2 つから 3 つにスケーリングします。openstack overcloud deployの一部として、オーバークラウドの残りの環境ファイル (ENVIRONMENT_FILES) と共にswift-upscale.yamlファイルを追加します。openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記swift-upscale.yamlファイルのパラメーターがそれより前の環境ファイルのパラメーターよりも優先されるように、このファイルを環境ファイルの一覧の最後に追加します。再デプロイメントが完了したら、オーバークラウドには新たなオブジェクトストレージノードが含まれます。
ここで、データを新しいノードに複製する必要があります。ノードを削除する前に (この場合は
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
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 OVERCopy to Clipboard Copied! Toggle word wrap Toggle overflow リングから不要になったノードを削除するには、
swift-upscale.yamlのObjectStorageCountの数を減らして不要になったリングを削除します。今回は 2 に減らします。parameter_defaults: ObjectStorageCount: 2
parameter_defaults: ObjectStorageCount: 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規環境ファイル (
remove-object-node.yaml) を作成します。このファイルは、指定したオブジェクトストレージノードを特定し、削除します。以下の内容ではovercloud-objectstorage-1の削除を指定します。parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]parameter_defaults: ObjectStorageRemovalPolicies: [{'resource_list': ['1']}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントコマンドに両方の環境ファイルを含めます。
openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...
$ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
director は、オーバークラウドからオブジェクトストレージノードを削除して、オーバークラウド上の残りのノードを更新し、ノードの削除に対応します。
第10章 ノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドおよびオーバークラウドで、ノードをリブートしなければならない場合があります。以下の手順では、異なるノード種別をリブートする方法を説明します。以下の点に注意してください。
- 1 つのロールで全ノードをリブートする場合には、各ノードを個別にリブートすることを推奨しています。この方法は、リブート中にそのロールのサービスを保持するのに役立ちます。
- OpenStack Platform 環境の全ノードをリブートする場合、リブートの順序は以下のリストを参考にしてください。
推奨されるノードリブート順
- director のリブート
- コントローラーノードのリブート
- スタンドアロンの Ceph MON ノードのリブート
- Ceph Storage ノードのリブート
- コンピュートノードのリブート
- オブジェクトストレージノードのリブート
10.1. director のリブート リンクのコピーリンクがクリップボードにコピーされました!
director ノードをリブートするには、以下のプロセスに従います。
ノードをリブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートするまで待ちます。
ノードがブートしたら、全サービスのステータスを確認します。
sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記リブート後に
openstack-nova-computeが有効になるまでに約 10 分かかる場合があります。オーバークラウドとそのノードが存在することを確認します。
source ~/stackrc openstack server list openstack baremetal node list openstack stack list
$ source ~/stackrc $ openstack server list $ openstack baremetal node list $ openstack stack listCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.2. コントローラーノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
コントローラーノードをリブートするには、以下のプロセスに従います。
リブートするノードを選択します。リブートする前に、そのノードにログインしてクラスターを停止します。
sudo pcs cluster stop
$ sudo pcs cluster stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターをリブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow リブート中、クラスターの残りのコントローラーノードは高可用性サービスを維持します。
- ノードがブートするまで待ちます。
ノードのクラスターを再度有効化します。
sudo pcs cluster start
$ sudo pcs cluster startCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードにログインして、クラスターのステータスを確認します。
sudo pcs status
$ sudo pcs statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow ノードは、クラスターに再度参加します。
注記リブート後にエラーの生じるサービスがあった場合には、
sudo pcs resource cleanupを実行し、エラーを消去して各リソースの状態をStartedに設定します。引き続きエラーが発生する場合は、Red Hat に連絡してアドバイス/サポートをリクエストしてください。コントローラーノード上の
systemdサービスがすべてアクティブであることを確認します。sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"
$ sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードからログアウトして、次にリブートするコントローラーノードを選択し、すべてのコントローラーノードをリブートするまでこの手順を繰り返します。
10.3. スタンドアロンの Ceph MON ノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
Ceph MON ノードをリブートするには、以下のプロセスに従います。
- Ceph MON ノードにログインします。
ノードをリブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートして MON クラスターに再度加わるまで待ちます。
クラスター内の各 MON ノードで、この手順を繰り返します。
10.4. Ceph Storage ノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
Ceph Storage ノードをリブートするには、以下のプロセスに従います。
Ceph MON またはコントローラーノードにログインして、Ceph Storage クラスターのリバランスを一時的に無効にします。
sudo ceph osd set noout sudo ceph osd set norebalance
$ sudo ceph osd set noout $ sudo ceph osd set norebalanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - リブートする最初の Ceph Storage ノードを選択して、ログインします。
ノードをリブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートするまで待ちます。
ノードにログインして、クラスターのステータスを確認します。
sudo ceph -s
$ sudo ceph -sCopy to Clipboard Copied! Toggle word wrap Toggle overflow pgmapにより、すべてのpgsが正常な状態 (active+clean) として報告されることを確認します。- ノードからログアウトして、次のノードをリブートし、ステータスを確認します。全 Ceph Storage ノードがリブートされるまで、このプロセスを繰り返します。
完了したら、Ceph MON またはコントローラーノードにログインして、クラスターのリバランスを再度有効にします。
sudo ceph osd unset noout sudo ceph osd unset norebalance
$ sudo ceph osd unset noout $ sudo ceph osd unset norebalanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 最終のステータスチェックを実行して、クラスターが
HEALTH_OKを報告していることを確認します。sudo ceph status
$ sudo ceph statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
10.5. コンピュートノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
各コンピュートノードを個別にリブートして、OpenStack Platform 環境のインスタンスのダウンタイムがゼロになるようにします。これは、以下のワークフローを伴います。
- リブートするコンピュートノードを選択する。
- そのノードのインスタンスを別のコンピュートノードに移行する。
- 空のコンピュートノードをリブートする
全コンピュートノードとその UUID を一覧表示します。
nova list | grep "compute"
$ nova list | grep "compute"
リブートするコンピュートノードを選択し、まず以下のプロセスに従ってそのノードのインスタンスを移行します。
アンダークラウドから、リブートするコンピュートノードを選択し、そのノードを無効にします。
source ~/overcloudrc openstack compute service list openstack compute service set [hostname] nova-compute --disable
$ source ~/overcloudrc $ openstack compute service list $ openstack compute service set [hostname] nova-compute --disableCopy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートノード上の全インスタンスを一覧表示します。
openstack server list --host [hostname] --all-projects
$ openstack server list --host [hostname] --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 無効にしたホストから各インスタンスを移行します以下のコマンドの 1 つを使用します。
選択した特定のホストにインスタンスを移行する。
openstack server migrate [instance-id] --live [target-host]--wait
$ openstack server migrate [instance-id] --live [target-host]--waitCopy to Clipboard Copied! Toggle word wrap Toggle overflow nova-schedulerにより対象のホストが自動的に選択されるようにする。nova live-migration [instance-id]
$ nova live-migration [instance-id]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記novaコマンドで非推奨の警告が表示される可能性がありますが、無視して問題ありません。
- 移行が完了するまで待ちます。
インスタンスがコンピュートノードから移行されたことを確認します。
openstack server list --host [hostname] --all-projects
$ openstack server list --host [hostname] --all-projectsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - コンピュートノードから全インスタンスを移行するまで、このステップを繰り返します。
インスタンスの設定および移行に関する詳しい説明は、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
以下の手順に従ってコンピュートノードをリブートします。
コンピュートノードにログインして、リブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートするまで待ちます。
コンピュートノードを再度有効化します。
source ~/overcloudrc openstack compute service set [hostname] nova-compute --enable
$ source ~/overcloudrc $ openstack compute service set [hostname] nova-compute --enableCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 次にリブートするノードを選択します。
10.6. オブジェクトストレージノードのリブート リンクのコピーリンクがクリップボードにコピーされました!
オブジェクトストレージノードをリブートするには、以下のプロセスに従います。
リブートするオブジェクトストレージノードを選択します。そのノードにログインしてリブートします。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードがブートするまで待ちます。
ノードにログインしてステータスを確認します。
sudo systemctl list-units "openstack-swift*"
$ sudo systemctl list-units "openstack-swift*"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - ノードからログアウトし、次のオブジェクトストレージノードでこのプロセスを繰り返します。
第11章 director の問題のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
director プロセスの特定の段階で、エラーが発生する可能性があります。本項では、一般的な問題の診断に関する情報を提供します。
director のコンポーネントの共通ログを確認してください。
-
/var/logディレクトリーには、多数の OpenStack Platform の共通コンポーネントのログや、標準の Red Hat Enterprise Linux アプリケーションのログが含まれています。 journaldサービスは、さまざまなコンポーネントのログを提供します。Ironic はopenstack-ironic-apiとopenstack-ironic-conductorの 2 つのユニットを使用する点に注意してください。同様に、ironic-inspectorもopenstack-ironic-inspectorとopenstack-ironic-inspector-dnsmasqの 2 つのユニットを使用します。該当するコンポーネントごとに両ユニットを使用します。以下に例を示します。sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasq
$ sudo journalctl -u openstack-ironic-inspector -u openstack-ironic-inspector-dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ironic-inspectorは、/var/log/ironic-inspector/ramdisk/に ramdisk ログを gz 圧縮の tar ファイルとして保存します。ファイル名には、日付、時間、ノードの IPMI アドレスが含まれます。イントロスペクションの問題を診断するには、これらのログを使用します。
11.1. ノード登録のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
ノード登録における問題は通常、ノードの情報が間違っていることが原因で発生します。このような場合には、ironic を使用して、登録したノードデータの問題を修正します。以下にいくつか例を示します。
割り当てられたポートの UUID を確認します。
ironic node-port-list [NODE UUID]
$ ironic node-port-list [NODE UUID]
MAC アドレスを更新します。
ironic port-update [PORT UUID] replace address=[NEW MAC]
$ ironic port-update [PORT UUID] replace address=[NEW MAC]
次のコマンドを実行します。
ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
11.2. ハードウェアイントロスペクションのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
イントロスペクションのプロセスは最後まで実行する必要があります。ただし、Ironic の Discovery Daemon (ironic-inspector) は、discovery ramdisk が応答しない場合にはデフォルトの 1 時間が経過するとタイムアウトします。discovery ramdisk のバグが原因とされる場合もありますが、通常は特に BIOS のブート設定などの環境の誤設定が原因で発生します。
以下には、環境設定が間違っている場合の一般的なシナリオと、診断/解決方法に関するアドバイスを示します。
ノードのイントロスペクション開始におけるエラー
通常、イントロスペクションプロセスには、Ironic サービス全体に対するコマンドとして機能する baremetal introspection を使用します。ただし、ironic-inspector で直接イントロスペクションを実行している場合には、「AVAILABLE」の状態のノードの検出に失敗する可能性があります。これはデプロイメント用であり、検出用ではないためです。検出前に、ノードのステータスを「MANAGEABLE」の状態に変更します。
ironic node-set-provision-state [NODE UUID] manage
$ ironic node-set-provision-state [NODE UUID] manage
検出が完了したら、状態を「AVAILABLE」に戻してからプロビジョニングを行います。
ironic node-set-provision-state [NODE UUID] provide
$ ironic node-set-provision-state [NODE UUID] provide
イントロスペクション済みのノードが PXE でブートできない
ノードがリブートする前に、ironic-inspector はアンダークラウドのファイアウォールの ironic-inspector チェーンにノードの MAC アドレスを追加します。これにより、ノードが PXE 経由でブートできるようになります。設定が正しいことを確認するには、以下のコマンドを実行します。
`sudo iptables -L`
$ `sudo iptables -L`
出力されるチェーンテーブルに、以下の MAC アドレスが表示されるはずです。
Chain ironic-inspector (1 references) target prot opt source destination DROP all -- anywhere anywhere MAC xx:xx:xx:xx:xx:xx ACCEPT all -- anywhere anywhere
Chain ironic-inspector (1 references)
target prot opt source destination
DROP all -- anywhere anywhere MAC xx:xx:xx:xx:xx:xx
ACCEPT all -- anywhere anywhere
MAC アドレスが表示されない場合、最も一般的な原因は、SQLite データベース内にある ironic-inspector キャッシュの破損です。この問題を修正するには、以下のコマンドで SQLite ファイルを削除します。
sudo rm /var/lib/ironic-inspector/inspector.sqlite
$ sudo rm /var/lib/ironic-inspector/inspector.sqlite
次に、以下のコマンドでこのファイルを再度作成します。
sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade sudo systemctl restart openstack-ironic-inspector
$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
検出プロセスの停止
現在 ironic-inspector では、直接検出プロセスを停止する方法はありません推奨されるパスは、プロセスがタイムアウトするまで待つことです。必要であれば、/etc/ironic-inspector/inspector.conf の timeout 設定を異なるタイムアウト時間 (分単位) に変更します。
最悪の場合、以下のプロセスを使用して全ノードの検出プロセスを停止することができます。
各ノードの電源状態をオフに変更します。
ironic node-set-power-state [NODE UUID] off
$ ironic node-set-power-state [NODE UUID] off
ironic-inspector キャッシュを削除し、再起動します。
rm /var/lib/ironic-inspector/inspector.sqlite
$ rm /var/lib/ironic-inspector/inspector.sqlite
ironic-inspector キャッシュを再同期します。
sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade sudo systemctl restart openstack-ironic-inspector
$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
introspection ramdisk へのアクセス
introspection ramdisk は、動的なログイン要素を使用します。これは、イントロスペクションのデバッグ中にノードにアクセスするための一時パスワードまたは SSH キーのいずれかを提供できることを意味します。以下のプロセスを使用して、ramdisk アクセスを設定します。
openssl passwd -1コマンドに一時パスワードを指定して MD5 ハッシュを生成します。以下に例を示します。openssl passwd -1 mytestpassword
$ openssl passwd -1 mytestpassword $1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/Copy to Clipboard Copied! Toggle word wrap Toggle overflow /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=0kernel 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=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow または、
sshkeyパラメーターに SSH 公開キーを追記します。注記rootpwdおよびsshkeyのパラメーターにはいずれも二重引用符が必要です。イントロスペクションを開始し、
arpコマンドまたは DHCP のログから IP アドレスを特定します。arp sudo journalctl -u openstack-ironic-inspector-dnsmasq
$ arp $ sudo journalctl -u openstack-ironic-inspector-dnsmasqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 一時パスワードまたは SSH キーを使用して、root ユーザーとして SSH 接続します。
ssh root@192.0.2.105
$ ssh root@192.0.2.105Copy to Clipboard Copied! Toggle word wrap Toggle overflow
イントロスペクションストレージのチェック
director は OpenStack Object Storage (swift) を使用して、イントロスペクションプロセス中に取得したハードウェアデータを保存します。このサービスが稼働していない場合には、イントロスペクションは失敗する場合があります。以下のコマンドを実行して、OpenStack Object Storage に関連したサービスをすべてチェックし、このサービスが稼働中であることを確認します。
sudo systemctl list-units openstack-swift*
$ sudo systemctl list-units openstack-swift*
11.3. ワークフローおよび実行に関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
OpenStack Workflow (mistral) サービスは、複数の OpenStack タスクをワークフローにグループ化します。Red Hat OpenStack Platform は、これらのワークフローセットを使用して、CLI と Web UI で共通の機能を実行します。これには、ベアメタルノードの制御、検証、プラン管理、オーバークラウドのデプロイメントが含まれます。
たとえば 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
Removing the current plan files
Uploading new plan files
Started Mistral Workflow. Execution ID: aef1e8c6-a862-42de-8bce-073744ed5e6b
Plan updated
2 つ目のワークフローは、オーバークラウドのデプロイメントを開始します。
Workflow オブジェクト
OpenStack Workflow では、以下のオブジェクトを使用してワークフローを追跡します。
- アクション
- 関連タスクが実行される際に OpenStack が実施する特定の指示。これには、シェルスクリプトの実行や HTTP リクエストの実行などが含まれます。OpenStack の一部のコンポーネントには、OpenStack Workflow が使用するアクションが組み込まれています。
- タスク
- 実行するアクションと、アクションの実行後の結果を定義します。これらのタスクには通常、アクションまたはアクションに関連付けられたワークフローが含まれます。タスクが完了したら、ワークフローは、タスクが成功したか否かによって、別のタスクに指示を出します。
- ワークフロー
- グループ化されて特定の順番で実行されるタスクのセット
- 実行
- 実行する特定のアクション、タスク、またはワークフローを定義します。
Workflow のエラー診断
OpenStack Workflow では、実行に関して着実にログを取ることもできるので、特定のコマンドが失敗した場合に問題を特定しやすくなります。たとえば、ワークフローの実行に失敗した場合には、どの部分で失敗したかを特定することができます。失敗した状態 (ERROR) のワークフローの実行を一覧表示します。
mistral execution-list | grep "ERROR"
$ mistral execution-list | grep "ERROR"
失敗したワークフロー実行の UUID を取得して (例: 3c87a885-0d37-4af8-a471-1b392264a7f5)、実行とその出力を表示します。
mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5 mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5
これにより、実行で失敗したタスクに関する情報を取得できます。mistral execution-get は、実行に使用したワークフローも表示します (例: tripleo.plan_management.v1.update_deployment_plan)。以下のコマンドを使用して完全なワークフロー定義を表示することができます。
mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan
$ mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan
これは、特定のタスクがワークフローのどの部分で発生するかを特定する際に便利です。
同様のコマンド構文を使用して、アクションの実行と、その結果を表示することもできます。
mistral action-execution-list mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908 mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-list
$ mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908
これは、問題を引き起こす固有のアクションを特定する際に便利です。
11.4. オーバークラウドの作成に関するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
デプロイメントが失敗する可能性のあるレイヤーは 3 つあります。
- オーケストレーション (Heat および Nova サービス)
- ベアメタルプロビジョニング (Ironic サービス)
- デプロイメント後の設定 (Puppet)
オーバークラウドのデプロイメントがこれらのレベルのいずれかで失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。
11.4.1. Orchestration リンクのコピーリンクがクリップボードにコピーされました!
多くの場合は、オーバークラウドの作成に失敗した後に、Heat により失敗したオーバークラウドスタックが表示されます。
スタック一覧が空の場合には、初期の Heat 設定に問題があることが分かります。Heat テンプレートと設定オプションをチェックし、さらに openstack overcloud deploy を実行後のエラーメッセージを確認してください。
11.4.2. ベアメタルプロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
ironic をチェックして、全登録ノードと現在の状態を表示します。
プロビジョニングプロセスでよく発生する問題を以下に示します。
結果の表の「Provision State」および「Maintenance」の列を確認します。以下の点をチェックしてください。
- 表にノードが表示されない、または必要なノード数よりも少ない
- 「Maintenance」が True に設定されている
-
プロビジョニングの状態が
manageableに設定されている。これにより、登録または検出プロセスに問題があることが分かります。たとえば、「Maintenance」が True に自動的に設定された場合は通常、ノードの電源管理の認証情報が間違っています。
-
「Provision State」が
availableの場合には、ベアメタルのデプロイメントが開始される前に問題が発生しています。 -
「Provision State」が
activeで、「Power State」がpower onの場合、ベアメタルのデプロイメントは正常に完了しています。これは、デプロイメント後の設定ステップで問題が発生したことを意味します。 -
ノードの「Provision State」が
wait call-backの場合には、このノードではまだ Bare Metal Provisioning プロセスが完了していません。このステータスが変わるまで待ってください。ステータスが変わらない場合には、問題のあるノードの仮想コンソールに接続して、出力を確認します。 「Provision State」が
errorまたはdeploy failedの場合には、このノードでのベアメタルプロビジョニングは失敗しています。ベアメタルノードの詳細を確認してください。ironic node-show [NODE UUID]
$ ironic node-show [NODE UUID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow エラーの説明が含まれる
last_errorフィールドがないか確認します。エラーメッセージが曖昧な場合、ログを使用して明確にすることができます。sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
$ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
wait timeout errorが表示されており、「Power State」がpower onの場合には、問題のあるノードの仮想コンソールに接続して、出力を確認します。
11.4.3. デプロイメント後の設定 リンクのコピーリンクがクリップボードにコピーされました!
設定ステージでは多くの事象が発生する可能性があります。たとえば、設定に問題があるために、特定の Puppet モジュールの完了に失敗する可能性があります。本項では、これらの問題を診断するプロセスを説明します。
オーバークラウドスタックからのリソースをすべて表示して、どのスタックに問題があるのかを確認します。
heat resource-list overcloud
$ heat resource-list overcloud
このコマンドにより、すべてのリソースとその状態が表形式で表示されます。状態が CREATE_FAILED のリソースを探します。
問題のあるリソースを表示します。
heat resource-show overcloud [FAILED RESOURCE]
$ heat resource-show overcloud [FAILED RESOURCE]
resource_status_reason フィールドで、診断に役立つ可能性のある情報がないか確認します。
nova コマンドを使用して、オーバークラウドノードの IP アドレスを表示します。
nova list
$ nova list
デプロイされたノードの 1 つに heat-admin ユーザーとしてログインします。たとえば、スタックのリソース一覧から、コントローラーノード上にエラーが発生していることが判明した場合には、コントローラーノードにログインします。heat-admin ユーザーには、sudo アクセスが設定されています。
ssh heat-admin@192.0.2.14
$ ssh heat-admin@192.0.2.14
os-collect-config ログを確認して、考えられる失敗の原因をチェックします。
sudo journalctl -u os-collect-config
$ sudo journalctl -u os-collect-config
場合によっては、Nova によるノードのデプロイメントが完全に失敗する可能性があります。このような場合には、オーバークラウドのロール種別の 1 つの OS::Heat::ResourceGroup が失敗しているはずです。その際には、nova を使用して問題を確認します。
nova list nova show [SERVER ID]
$ nova list
$ nova show [SERVER ID]
最もよく表示されるエラーは、No valid host was found のエラーメッセージです。このエラーのトラブルシューティングについては、「"No Valid Host Found" エラーのトラブルシューティング」を参照してください。その他の場合は、以下のログファイルを参照してトラブルシューティングを実施してください。
-
/var/log/nova/* -
/var/log/heat/* -
/var/log/ironic/*
システムのハードウェアおよび設定に関する情報を収集する SOS ツールセットを使用します。この情報は、診断目的とデバッグに使用されます。SOS は、一般的にサポート技術者および開発者を支援するために使用されます。SOS は、アンダークラウドとオーバークラウドの両方で役立ちます。sos パッケージをインストールします。
sudo yum install sos
$ sudo yum install sos
レポートを生成します。
sudo sosreport --all-logs
$ sudo sosreport --all-logs
コントローラーノードのデプロイ後のプロセスは、5 つの主なステップで構成されます。そのステップは以下のとおりです。
| ステップ | 説明 |
|
| Pacemaker、RabbitMQ、Memcached、Redis、および Galera を含むロードバランシング用のソフトウェアの初期設定 |
|
| Pacemaker の設定、HAProxy、MongoDB、Galera、Ceph Monitor、OpenStack Platform の各種サービス用のデータベースの初期化を含む、クラスターの初期設定 |
|
|
OpenStack Object Storage ( |
|
| サービス起動順序やサービス起動パラメーターを決定するための制約事項を含む、Pacemaker でのサービスの起動設定値の設定 |
|
|
OpenStack Identity ( |
11.5. プロビジョニングネットワークでの IP アドレスの競合に対するトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
宛先のホストに、すでに使用中の IP アドレスが割り当てられている場合には、検出およびデプロイメントのタスクは失敗します。この問題を回避するには、プロビジョニングネットワークのポートスキャンを実行して、検出の IP アドレス範囲とホストの IP アドレス範囲が解放されているかどうかを確認することができます。
アンダークラウドホストで以下のステップを実行します。
nmap をインストールします。
yum install nmap
# yum install nmap
nmap を使用して、アクティブなアドレスの IP アドレス範囲をスキャンします。この例では、192.0.2.0/24 の範囲をスキャンします。この値は、プロビジョニングネットワークの IP サブネットに置き換えてください (CIDR 表記のビットマスク)。
nmap -sn 192.0.2.0/24
# nmap -sn 192.0.2.0/24
nmap スキャンの出力を確認します。
たとえば、アンダークラウドおよびサブネット上に存在するその他のホストの IP アドレスを確認する必要があります。アクティブな IP アドレスが undercloud.conf の IP アドレス範囲と競合している場合には、オーバークラウドノードのイントロスペクションまたはデプロイを実行する前に、IP アドレスの範囲を変更するか、IP アドレスを解放するかのいずれかを行う必要があります。
11.6. "No Valid Host Found" エラーのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
/var/log/nova/nova-conductor.log に、以下のエラーが含まれる場合があります。
NoValidHost: No valid host was found. There are not enough hosts available.
NoValidHost: No valid host was found. There are not enough hosts available.
これは、Nova Scheduler が新規インスタンスをブートするのに適したベアメタルノードを検出できなかったことを意味します。このような場合、通常は、Nova が検出を想定しているリソースと Ironic が Nova に通知するリソースが一致しなくなります。その際には、以下の点をチェックしてください。
イントロスペクションが正常に完了することを確認してください。または、各ノードに必要な Ironic ノードのプロパティーが含まれていることをチェックしてください。各ノードに以下のコマンドを実行します。
ironic node-show [NODE UUID]
$ ironic node-show [NODE UUID]Copy to Clipboard Copied! Toggle word wrap Toggle overflow propertiesJSON フィールドのcpus、cpu_arch、memory_mb、およびlocal_gbキーに有効な値が指定されていることを確認してください。使用する Nova フレーバーが、必要なノード数において、上記の Ironic ノードプロパティーを超えていないかどうかを確認します。
nova flavor-show [FLAVOR NAME]
$ nova flavor-show [FLAVOR NAME]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ironic node-listの出力で、availableの状態のノードの数が十分かどうかを確認します。ノードの状態がmanageableの場合は通常、イントロスペクションに失敗しています。 また、ノードがメンテナンスモードではないことを確認します。
ironic node-listを使用してチェックしてください。通常、自動でメンテナンスモードに切り替わるノードは、電源の認証情報が間違っています。認証情報を確認して、メンテナンスモードをオフにします。ironic node-set-maintenance [NODE UUID] off
$ ironic node-set-maintenance [NODE UUID] offCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Automated Health Check (AHC) ツールを使用して、自動でノードのタグ付けを行う場合には、各フレーバー/プロファイルに対応するノードが十分に存在することを確認します。
ironic node-showの出力で、propertiesフィールドのcapabilitiesキーを確認します。たとえば、Compute ロールのタグを付けられたノードには、profile:computeが含まれているはずです。 イントロスペクションの後に Ironic から Nova にノードの情報が反映されるには若干時間がかかります。これは通常、director のツールが原因です。ただし、一部のステップを手動で実行した場合には、短時間ですが、Nova でノードが利用できなくなる場合があります。以下のコマンドを使用して、システム内の合計リソースをチェックします。
nova hypervisor-stats
$ nova hypervisor-statsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7. オーバークラウド作成後のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドを作成した後には、将来そのオーバークラウドで特定の操作を行うようにすることができます。たとえば、利用可能なノードをスケーリングしたり、障害の発生したノードを置き換えたりすることができます。このような操作を行うと、特定の問題が発生する場合があります。本項には、オーバークラウド作成後の操作が失敗した場合の診断とトラブルシューティングに関するアドバイスを記載します。
11.7.1. オーバークラウドスタックの変更 リンクのコピーリンクがクリップボードにコピーされました!
director を使用して overcloud スタックを変更する際に問題が発生する場合があります。スタックの変更例には、以下のような操作が含まれます。
- ノードのスケーリング
- ノードの削除
- ノードの置き換え
スタックの変更は、スタックの作成と似ており、director は要求されたノード数が利用可能かどうかをチェックして追加のノードをプロビジョニングしたり、既存のノードを削除したりしてから、Puppet の設定を適用します。overcloud スタックを変更する場合に従うべきガイドラインを以下に記載します。
第一段階として、「デプロイメント後の設定」に記載したアドバイスに従います。この手順と同じステップを、overcloud Heat スタック更新の問題の診断に役立てることができます。特に、以下のコマンドを使用して問題のあるリソースを特定します。
heat stack-list --show-nested-
全スタックを一覧表示します。
--show-nestedはすべての子スタックとそれぞれの親スタックを表示します。このコマンドは、スタックでエラーが発生した時点を特定するのに役立ちます。 heat resource-list overcloud-
overcloudスタック内の全リソースと現在の状態を一覧表示します。このコマンドは、スタック内でどのリソースが原因でエラーが発生しているかを特定するのに役立ちます。このリソースのエラーの原因となっている Heat テンプレートコレクションと Puppet モジュール内のパラメーターと設定を特定することができます。 heat event-list overcloud-
overcloudスタックに関連するすべてのイベントを時系列で一覧表示します。これには、スタック内の全リソースのイベント開始/完了時間とエラーが含まれます。この情報は、リソースの障害点を特定するのに役立ちます。
以下のセクションには、特定の種別のノード上の問題診断に関するアドバイスを記載します。
11.7.2. コントローラーサービスのエラー リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウドコントローラーノードには、Red Hat OpenStack Platform のサービスの大部分が含まれます。同様に、高可用性のクラスターで複数のコントローラーノードを使用することができます。ノード上の特定のサービスに障害が発生すると、高可用性のクラスターは一定レベルのフェイルオーバーを提供します。ただし、オーバークラウドをフル稼働させるには、障害のあるサービスの診断が必要となります。
コントローラーノードは、Pacemaker を使用して高可用性クラスター内のリソースとサービスを管理します。Pacemaker Configuration System (pcs) コマンドは、Pacemaker クラスターを管理するツールです。クラスター内のコントローラーノードでこのコマンドを実行して、設定およびモニタリングの機能を実行します。高可用性クラスター上のオーバークラウドサービスのトラブルシューティングに役立つコマンドを以下にいくつか記載します。
pcs status- 有効なリソース、エラーが発生したリソース、オンラインのノードなど、クラスター全体のステータス概要を提供します。
pcs resource show- リソースおよびそれに対応するノードの一覧を表示します。
pcs resource disable [resource]- 特定のリソースを停止します。
pcs resource enable [resource]- 特定のリソースを起動します。
pcs cluster standby [node]- ノードをスタンバイモードに切り替えます。そのノードはクラスターで利用できなくなります。このコマンドは、クラスターに影響を及ぼさずに特定のノードメンテナンスを実行するのに役立ちます。
pcs cluster unstandby [node]- ノードをスタンバイモードから解除します。ノードはクラスター内で再度利用可能となります。
これらの Pacemaker コマンドを使用して障害のあるコンポーネントおよびノードを特定します。コンポーネントを特定した後には、/var/log/ でそれぞれのコンポーネントのログファイルを確認します。
11.7.3. Compute サービスのエラー リンクのコピーリンクがクリップボードにコピーされました!
コンピュートノードは、Compute サービスを使用して、ハイパーバイザーベースの操作を実行します。これは、このサービスを中心にコンピュートノードのメインの診断が行われていることを意味します。以下に例を示します。
以下の
systemd機能を使用して、サービスのステータスを表示します。sudo systemctl status openstack-nova-compute.service
$ sudo systemctl status openstack-nova-compute.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 同様に、以下のコマンドを使用して、サービスの
systemdジャーナルを表示します。sudo journalctl -u openstack-nova-compute.service
$ sudo journalctl -u openstack-nova-compute.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
コンピュートノードの主なログファイルは
/var/log/nova/nova-compute.logです。コンピュートノードの通信で問題が発生した場合に、通常はこのログが診断を開始するのに適した場所です。 - コンピュートノードでメンテナンスを実行する場合には、既存のインスタンスをホストから稼働中のコンピュートノードに移行し、ノードを無効にします。ノードの移行についての詳しい情報は、「8章コンピュートノード間の仮想マシンの移行」を参照してください。
11.7.4. Ceph Storage サービスのエラー リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Ceph Storage クラスターで発生した問題については、『Configuration Guide』の「Logging Configuration Reference」を参照してください。この項には、全 Ceph Storage サービスのログ診断についての情報が記載されています。
11.8. アンダークラウドの調整 リンクのコピーリンクがクリップボードにコピーされました!
このセクションでのアドバイスは、アンダークラウドのパフォーマンスを向上に役立たせることが目的です。必要に応じて、推奨事項を実行してください。
-
Identity サービス (keystone) は、他の OpenStack サービスに対するアクセス制御にトークンベースのシステムを使用します。ある程度の期間が過ぎた後には、データベースに未使用のトークンが多数蓄積されます。デフォルトの cronjob は毎日トークンをフラッシュします。環境をモニタリングして、必要に応じてトークンのフラッシュ間隔を調節することを推奨します。アンダークラウドの場合は、
crontab -u keystone -eコマンドで間隔を調整することができます。この変更は一時的で、openstack undercloud updateを実行すると、この cronjob の設定はデフォルトに戻ってしまう点に注意してください。 openstack overcloud deployを実行するたびに、Heat はデータベースのraw_templateテーブルにあるすべての一時ファイルのコピーを保存します。raw_templateテーブルは、過去のテンプレートをすべて保持し、サイズが増加します。raw_templatesテーブルにある未使用のテンプレートを削除するには、以下のように、日次の cron ジョブを作成して、未使用のまま 1 日以上データベースに存在するテンプレートを消去してください。0 04 * * * /bin/heat-manage purge_deleted -g days 1
0 04 * * * /bin/heat-manage purge_deleted -g days 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow openstack-heat-engineおよびopenstack-heat-apiサービスは、過剰なリソースを消費する場合があります。そのような場合は/etc/heat/heat.confでmax_resources_per_stack=-1を設定して、Heat サービスを再起動します。sudo systemctl restart openstack-heat-engine openstack-heat-api
$ sudo systemctl restart openstack-heat-engine openstack-heat-apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow directorには、同時にノードをプロビジョニングするリソースが十分にない場合があります。同時にプロビジョニングできるノード数はデフォルトで 10 個となっています。同時にプロビジョニングするノード数を減らすには、
/etc/nova/nova.confのmax_concurrent_buildsパラメーターを 10 未満に設定して Nova サービスを再起動します。sudo systemctl restart openstack-nova-api openstack-nova-scheduler
$ sudo systemctl restart openstack-nova-api openstack-nova-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/my.cnf.d/server.cnfファイルを編集します。調整項目の推奨値は、以下のとおりです。- max_connections
- データベースに同時接続できる数。推奨の値は 4096 です。
- innodb_additional_mem_pool_size
- データベースがデータのディクショナリーの情報や他の内部データ構造を保存するのに使用するメモリープールサイズ (バイト単位)。デフォルトは通常 8 M ですが、アンダークラウドの理想の値は 20 M です。
- innodb_buffer_pool_size
- データベースがテーブルやインデックスデータをキャッシュするメモリー領域つまり、バッファープールのサイズ (バイト単位)。通常デフォルトは 128 M で、アンダークラウドの理想の値は 1000 M です。
- innodb_flush_log_at_trx_commit
- コミット操作の厳密な ACID 準拠と、コミット関連の I/O 操作を再編成してバッチで実行することによって実現可能なパフォーマンス向上の間のバランスを制御します。1 に設定します。
- innodb_lock_wait_timeout
- データベースのトランザクションが、行のロック待ちを中断するまでの時間 (秒単位)。50 に設定します。
- innodb_max_purge_lag
- この変数は、パージ操作が遅れている場合に INSERT、UPDATE、DELETE 操作を遅延させる方法を制御します。10000 に設定します。
- innodb_thread_concurrency
- 同時に実行するオペレーティングシステムのスレッド数の上限。理想的には、各 CPU およびディスクリソースに対して少なくとも 2 つのスレッドを提供します。たとえば、クワッドコア CPU と単一のディスクを使用する場合は、スレッドを 10 個使用します。
オーバークラウドを作成する際には、Heat に十分なワーカーが配置されているようにします。通常、アンダークラウドに CPU がいくつあるかにより左右されます。ワーカーの数を手動で設定するには、
/etc/heat/heat.confファイルを編集してnum_engine_workersパラメーターを必要なワーカー数 (理想は 4) に設定し、Heat エンジンを再起動します。sudo systemctl restart openstack-heat-engine
$ sudo systemctl restart openstack-heat-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.9. アンダークラウドとオーバークラウドの重要なログ リンクのコピーリンクがクリップボードにコピーされました!
以下のログを使用して、トラブルシューティングの際にアンダークラウドとオーバークラウドの情報を割り出します。
| 情報 | ログの場所 |
|---|---|
| OpenStack Compute のログ |
|
| OpenStack Compute API の対話 |
|
| OpenStack Compute コンダクターのログ |
|
| OpenStack Orchestration ログ |
|
| OpenStack Orchestration API の対話 |
|
| OpenStack Orchestration CloudFormations ログ |
|
| OpenStack Bare Metal コンダクターのログ |
|
| OpenStack Bare Metal API の対話 |
|
| イントロスペクション |
|
| OpenStack Workflow Engine ログ |
|
| OpenStack Workflow Executor のログ |
|
| OpenStack Workflow API の対話 |
|
| 情報 | ログの場所 |
|---|---|
| cloud-init に関するログ |
|
| オーバークラウドの設定 (最後に実行した Puppet のサマリー) |
|
| オーバークラウドの設定 (最後に実行した Puppet からのレポート) |
|
| オーバークラウドの設定 (全 Puppet レポート) |
|
| オーバークラウドの設定 (実行した Puppet 毎の標準出力) |
|
| オーバークラウドの設定 (実行した Puppet 毎の標準エラー出力) |
|
| 高可用性に関するログ |
|
付録A SSL/TLS 証明書の設定 リンクのコピーリンクがクリップボードにコピーされました!
アンダークラウドがパブリックエンドポイントの通信に SSL/TLS を使用するように設定できます。ただし、独自の認証局で発行した SSL 証明書を使用する場合には、その証明書には以下の項に記載する設定のステップが必要です。
オーバークラウドの SSL/TLS 証明書作成については、『オーバークラウドの高度なカスタマイズ』の「オーバークラウドの SSL/TLS の有効化」を参照してください。
A.1. 署名ホストの初期化 リンクのコピーリンクがクリップボードにコピーされました!
署名ホストとは、新規証明書を生成し、認証局を使用して署名するホストです。選択した署名ホスト上で SSL 証明書を作成したことがない場合には、ホストを初期化して新規証明書に署名できるようにする必要がある可能性があります。
/etc/pki/CA/index.txt ファイルは、すべての署名済み証明書の記録を保管します。このファイルが存在しているかどうかを確認してください。存在していない場合には、空のファイルを作成します。
sudo touch /etc/pki/CA/index.txt
$ sudo touch /etc/pki/CA/index.txt
/etc/pki/CA/serial ファイルは、次に署名する証明書に使用する次のシリアル番号を特定します。このファイルが存在しているかどうかを確認してください。ファイルが存在しない場合には、新規ファイルを作成して新しい開始値を指定します。
echo '1000' | sudo tee /etc/pki/CA/serial
$ echo '1000' | sudo tee /etc/pki/CA/serial
A.2. 認証局の作成 リンクのコピーリンクがクリップボードにコピーされました!
通常、SSL/TLS 証明書の署名には、外部の認証局を使用します。場合によっては、独自の認証局を使用する場合もあります。たとえば、内部のみの認証局を使用するように設定する場合などです。
たとえば、キーと証明書のペアを生成して、認証局として機能するようにします。
openssl genrsa -out ca.key.pem 4096 openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
$ openssl genrsa -out ca.key.pem 4096
$ openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
openssl req コマンドは、認証局に関する特定の情報を要求します。それらの情報を指定してください。
これで、ca.crt.pem という名前の認証局ファイルが作成されます。
A.3. クライアントへの認証局の追加 リンクのコピーリンクがクリップボードにコピーされました!
SSL/TLS を使用して通信することを目的としている外部のクライアントの場合は、Red Hat OpenStack Platform 環境にアクセスする必要のある各クライアントに認証局ファイルをコピーします。クライアントへのコピーが完了したら、そのクライアントで以下のコマンドを実行して、認証局のトラストバンドルに追加します。
sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract
A.4. SSL/TLS 鍵の作成 リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドを実行して、SSL/TLS キー (server.key.pem) を生成します。このキーは、さまざまな段階で、アンダークラウドとオーバークラウドの証明書を生成するのに使用します。
openssl genrsa -out server.key.pem 2048
$ openssl genrsa -out server.key.pem 2048
A.5. SSL/TLS 証明書署名要求の作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順では、アンダークラウドおよびオーバークラウドのいずれかの証明書署名要求を作成します。
カスタマイズするデフォルトの OpenSSL 設定ファイルをコピーします。
cp /etc/pki/tls/openssl.cnf .
$ cp /etc/pki/tls/openssl.cnf .
カスタムの openssl.cnf ファイルを編集して、director に使用する SSL パラメーターを設定します。変更するパラメーターの種別には以下のような例が含まれます。
commonName_default は以下のいずれか 1 つに設定します。
-
IP アドレスを使用して SSL/TLS 経由でアクセスする場合には、
undercloud.confでundercloud_public_vipパラメーターを使用します。 - 完全修飾ドメイン名を使用して SSL/TLS でアクセスする場合には、代わりにドメイン名を使用します。
alt_names セクションを編集して、以下のエントリーを追加します。
-
IP: SSL 経由で director にアクセスするためのクライアントの IP アドレス一覧 -
DNS: SSL 経由で director にアクセスするためのクライアントのドメイン名一覧。alt_namesセクションの最後に DNS エントリーとしてパブリック API の IP アドレスも追加します。
openssl.cnf に関する詳しい情報については、man openssl.cnf を実行します。
次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します (server.csr.pem)。
openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
「SSL/TLS 鍵の作成」で作成した SSL/TLS 鍵を -key オプションで必ず指定してください。
次の項では、この server.csr.pem ファイルを使用して SSL/TLS 証明書を作成します。
A.6. SSL/TLS 証明書の作成 リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドで、アンダークラウドまたはオーバークラウドの証明書を作成します。
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
$ 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
上記のコマンドでは、以下のオプションを使用しています。
-
v3 拡張機能を指定する設定ファイル。このファイルは
-configオプションとして追加します。 -
認証局を介して証明書を生成し、署名するために、「SSL/TLS 証明書署名要求の作成」で設定した証明書署名要求。この値は
-inオプションとして追加します。 -
証明書への署名を行う、「認証局の作成」で作成した認証局。この値は
-certオプションとして追加します。 -
「認証局の作成」で作成した認証局の秘密鍵。この値は
-keyfileオプションとして追加します。
このコマンドを実行すると、server.crt.pem という名前の証明書が作成されます。この証明書は、「SSL/TLS 鍵の作成」で作成した SSL/TLS キーと共に使用して SSL/TLS を有効にします。
A.7. アンダークラウドで証明書を使用する場合 リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドを実行して、証明書とキーを統合します。
cat server.crt.pem server.key.pem > undercloud.pem
$ cat server.crt.pem server.key.pem > undercloud.pem
このコマンドにより、undercloud.pem が作成されます。undercloud.conf ファイルの undercloud_service_certificate オプションにこのファイルの場所を指定します。このファイルには、HAProxy ツールが読み取ることができるように、特別な SELinux コンテキストも必要です。以下の例を目安にしてください。
sudo mkdir /etc/pki/instack-certs sudo cp ~/undercloud.pem /etc/pki/instack-certs/. sudo semanage fcontext -a -t etc_t "/etc/pki/instack-certs(/.*)?" sudo restorecon -R /etc/pki/instack-certs
$ sudo mkdir /etc/pki/instack-certs
$ sudo cp ~/undercloud.pem /etc/pki/instack-certs/.
$ sudo semanage fcontext -a -t etc_t "/etc/pki/instack-certs(/.*)?"
$ sudo restorecon -R /etc/pki/instack-certs
undercloud.conf ファイルの undercloud_service_certificate オプションに undercloud.pem ファイルの場所を追加します。以下に例を示します。
undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem
undercloud_service_certificate = /etc/pki/instack-certs/undercloud.pem
また、「認証局の作成」で作成した認証局をアンダークラウドの信頼済み認証局の一覧に認証局を追加して、アンダークラウド内の異なるサービスが認証局にアクセスできるようにします。
sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract
「director の設定」の手順に従ってアンダークラウドのインストールを続行します。
付録B 電源管理ドライバー リンクのコピーリンクがクリップボードにコピーされました!
IPMI は、director が電源管理制御に使用する主要な手法ですが、director は他の電源管理タイプもサポートします。この付録では、サポートされる電源管理機能の一覧を提供します。「オーバークラウドノードの登録」には、以下の電源管理設定を使用します。
B.1. Dell Remote Access Controller (DRAC) リンクのコピーリンクがクリップボードにコピーされました!
DRAC は、電源管理やサーバー監視などの帯域外 (OOB) リモート管理機能を提供するインターフェースです。
- pm_type
-
このオプションを
pxe_dracに設定します。 - pm_user、pm_password
- DRAC のユーザー名およびパスワード
- pm_addr
- DRAC ホストの IP アドレス
B.2. Integrated Lights-Out (iLO) リンクのコピーリンクがクリップボードにコピーされました!
Hewlett-Packard の iLO は、電源管理やサーバー監視などの帯域外 (OOB) リモート管理機能を提供するインターフェースです。
- pm_type
-
このオプションを
pxe_iloに設定します。 - pm_user、pm_password
- iLO のユーザー名およびパスワード
- pm_addr
iLO インターフェースの IP アドレス
-
/etc/ironic/ironic.confファイルを編集し、enabled_driversオプションにpxe_iloを追加して、このドライバーを有効にします。 また director では、iLO 向けに追加のユーティリティーセットが必要です。
python-proliantutilsパッケージをインストールしてopenstack-ironic-conductorサービスを再起動します。sudo yum install python-proliantutils sudo systemctl restart openstack-ironic-conductor.service
$ sudo yum install python-proliantutils $ sudo systemctl restart openstack-ironic-conductor.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow - イントロスペクションが正常に実行されるには、HP ノードは 2015 年のファームウェアバージョンでなければなりません。ファームウェアバージョン 1.85 (2015 年 5 月 13 日) を使用するノードで、director は正常にテストされています。
- 共有 iLO ポートの使用はサポートされません。
-
B.3. Cisco Unified Computing System (UCS) リンクのコピーリンクがクリップボードにコピーされました!
Cisco の UCS は、コンピュート、ネットワーク、ストレージのアクセス、仮想化リソースを統合するデータセンタープラットフォームです。このドライバーは、UCS に接続されたベアメタルシステムの電源管理を重視しています。
- pm_type
-
このオプションを
pxe_ucsに設定します。 - 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"
"pm_service_profile": "org-root/ls-Nova-1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
/etc/ironic/ironic.confファイルを編集し、enabled_driversオプションにpxe_ucsを追加して、このドライバーを有効にします。 また director では、UCS 向けに追加のユーティリティーセットが必要です。
python-UcsSdkパッケージをインストールしてopenstack-ironic-conductorサービスを再起動します。sudo yum install python-UcsSdk sudo systemctl restart openstack-ironic-conductor.service
$ sudo yum install python-UcsSdk $ sudo systemctl restart openstack-ironic-conductor.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
B.4. Fujitsu Integrated Remote Management Controller (iRMC) リンクのコピーリンクがクリップボードにコピーされました!
Fujitsu の iRMC は、LAN 接続と拡張された機能を統合した Baseboard Management Controller (BMC) です。このドライバーは、iRMC に接続されたベアメタルシステムの電源管理にフォーカスしています。
iRMC S4 以降のバージョンが必要です。
- pm_type
-
このオプションを
pxe_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です。-
/etc/ironic/ironic.confファイルを編集し、enabled_driversオプションにpxe_irmcを追加して、このドライバーを有効にします。 センサーの方法として SCCI を有効にした場合には、director には、追加のユーティリティーセットも必要です。
python-scciclientパッケージをインストールして、openstack-ironic-conductorサービスを再起動します。yum install python-scciclient sudo systemctl restart openstack-ironic-conductor.service
$ yum install python-scciclient $ sudo systemctl restart openstack-ironic-conductor.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
B.5. SSH と virsh リンクのコピーリンクがクリップボードにコピーされました!
director は、libvirt を実行中のホストに SSH 経由でアクセスして、仮想マシンをノードとして使用することができます。director は、virsh を使用してこれらのノードの電源管理の制御を行います。
このオプションは、テストおよび評価の目的でのみ利用することができます。Red Hat OpenStack Platform のエンタープライズ環境には推奨していません。
- pm_type
-
このオプションを
pxe_sshに設定します。 - pm_user、pm_password
SSH ユーザー名および SSH 秘密鍵の内容。CLI ツールを使用してノードを登録する場合、秘密鍵は一行に記載する必要があり、\n改行はエスケープ文字 (
\n) に置き換えます。以下に例を示します。-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA .... kk+WXt9Y=\n-----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----\nMIIEogIBAAKCAQEA .... kk+WXt9Y=\n-----END RSA PRIVATE KEY-----Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH 公開鍵を libvirt サーバーの
authorized_keysコレクションに追加します。- pm_addr
virsh ホストの IP アドレス
-
libvirt をホストするサーバーには、
pm_password属性として設定された公開鍵を持つ SSH キーペアが必要です。 -
選択した
pm_userには、libvirt 環境への完全なアクセス権限が設定されるようにします。
-
libvirt をホストするサーバーには、
B.6. フェイク PXE ドライバー リンクのコピーリンクがクリップボードにコピーされました!
このドライバーは、電源管理なしにベアメタルデバイスを使用する方法を提供します。これは、director が登録されたベアメタルデバイスを制御しないので、イントロスペクションとデプロイプロセスの特定の時点に手動で電源をコントロールする必要があることを意味します。
このオプションは、テストおよび評価の目的でのみ利用することができます。Red Hat OpenStack Platform のエンタープライズ環境には推奨していません。
- pm_type
このオプションを
fake_pxeに設定します。- このドライバーは、電源管理を制御しないので、認証情報は使用しません。
/etc/ironic/ironic.confファイルを編集し、enabled_driversオプションにfake_pxeを追加して、このドライバーを有効にします。ファイルを編集したら、Bare Metal サービスを再起動します。sudo systemctl restart openstack-ironic-api openstack-ironic-conductor
$ sudo systemctl restart openstack-ironic-api openstack-ironic-conductorCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ノードのイントロスペクションを実行する際には、
openstack baremetal introspection bulk startコマンドを実行した後にノードの電源を手動でオフにします。 -
オーバークラウドのデプロイ実行時には、
ironic node-listコマンドでノードのステータスを確認します。ノードのステータスがdeployingからdeploy wait-callbackに変わるまで待ってから、手動でノードの電源をオンにします。 -
オーバークラウドのプロビジョニングプロセスが完了したら、ノードをリブートします。プロビジョニングが完了したかどうかをチェックするには、
ironic node-listコマンドでノードのステータスをチェックし、ノードのステータスがactiveに変わるのを待ってから、すべてのオーバークラウドノードを手動でリブートします。
付録C 完全なディスクイメージ リンクのコピーリンクがクリップボードにコピーされました!
メインのオーバークラウドイメージは、フラットパーティションイメージです。これは、パーティション情報またはブートローダーがイメージ自体に含まれていないことを意味します。director は、ブート時には別のカーネルおよび ramdisk を使用し、オーバークラウドイメージをディスクに書き込む際に基本的なパーティションレイアウトを作成します。ただし、パーティションレイアウトおよびブートローダーが含まれる完全なディスクイメージを作成することができます。
C.1. 完全なディスクイメージの作成 リンクのコピーリンクがクリップボードにコピーされました!
overcloud-full.qcow2 フラットパーティションイメージから完全なディスクイメージを作成するには、以下のステップを実行します。
-
overcloud-fullフラットパーティションを完全なディスクイメージのベースとして開きます。 - 希望のサイズで完全なディスクイメージを新規作成します。以下の例では、10 GB のイメージを使用します。
-
完全なディスクイメージにパーティションおよびボリュームを作成します。目的の完全なディスクイメージに必要な数だけ、パーティションおよびボリュームを作成します。以下の例では、
boot用のパーティションおよびファイルシステム内の他のコンテンツ用の論理ボリュームを、それぞれ独立に作成します。 - パーティションおよびボリュームに初期ファイルシステムを作成します。
- フラットパーティションのファイルシステムをマウントして、完全なディスクイメージの適切なパーティションにコンテンツをコピーします。
-
fstabのコンテンツを生成し、完全なディスクイメージの/etc/fstabに保存します。 - すべてのファイルシステムをアンマウントします。
-
完全なディスクイメージのパーティションだけをマウントします。
/にマウントするルートパーティションから始めて、他のパーティションをそれぞれのディレクトリーにマウントします。 -
シェルコマンドを使用してブートローダーをインストールし、完全なディスクイメージに対して
grub2-installおよびgrub2-mkconfigを実行します。これにより、完全なディスクイメージにgrub2ブートローダーがインストールされます。 -
dracutを更新して、論理ボリューム管理のサポートを提供します。 - すべてのファイルシステムをアンマウントし、イメージを終了します。
完全なディスクイメージの手動作成
イメージ作成の推奨ツールである guestfish は、以下のコマンドを使用してインストールします。
sudo yum install -y guestfish
$ sudo yum install -y guestfish
インストールが完了したら、guestfish の対話シェルを実行します。
guestfish の使用に関する詳細は、Red Hat Enterprise Linux 7『仮想化の導入および管理ガイド』の「guestfish シェル」を参照してください。
C.2. 完全なディスクイメージの自動作成 リンクのコピーリンクがクリップボードにコピーされました!
以下の Python スクリプトは、guestfish ライブラリーを使用して完全なディスクイメージを自動的に生成します。
このスクリプトを実行可能ファイルとしてアンダークラウドに保存して、stack ユーザーとして実行します。
./whole-disk-image.py
$ ./whole-disk-image.py
これにより、フラットなパーティションイメージから完全なディスクイメージが自動的に作成されます。完全なディスクイメージの作成が完了したら、以前の overcloud-full.qcow2 イメージを置き換えます。
mv ~/images/overcloud-full.qcow2 ~/images/overcloud-full-old.qcow2 cp ~/images/overcloud-full-partitioned.qcow2 ~/images/overcloud-full.qcow2
$ mv ~/images/overcloud-full.qcow2 ~/images/overcloud-full-old.qcow2
$ cp ~/images/overcloud-full-partitioned.qcow2 ~/images/overcloud-full.qcow2
これで、完全なディスクイメージを他のイメージと共にアップロードできるようになりました。
C.3. 完全なディスクイメージ上のボリュームの暗号化 リンクのコピーリンクがクリップボードにコピーされました!
guestfish を使用して、完全なディスクイメージ上のボリュームを暗号化することもできます。これには、現在のボリュームを消去して暗号化されたボリュームを作成する luks-format サブコマンドを使用する必要があります。
以下の Python スクリプトは、以前に作成した overcloud-full-partitioned.qcow2 イメージを開き、現在の空の home ボリュームを削除して、暗号化された home ボリュームに置き換えます。
このスクリプトは以下の操作も実施します。
-
キー (
random_content) を作成する。 -
新しい暗号化されたボリュームで
/etc/fstabファイルを再生成する。 -
/root/home_keyfileに暗号鍵を保存する。 -
/root/home_keyfileを使用してボリュームを自動的に復号するcrypttabファイルを生成する。
このスクリプトを例として使用し、完全なディスクイメージの作成プロセスの一部として暗号化されたボリュームを作成します。
C.4. 完全なディスクイメージのアップロード リンクのコピーリンクがクリップボードにコピーされました!
完全なディスクイメージをアップロードするには、イメージのアップロードコマンドで --whole-disk-image オプションを使用します。以下に例を示します。
openstack overcloud image upload --whole-disk --image-path /home/stack/images
$ openstack overcloud image upload --whole-disk --image-path /home/stack/images
このコマンドは /home/stack/images からイメージをアップロードしますが、overcloud-full.qcow2 ファイルを完全なディスクイメージとして扱います。このため、イメージのアップロードコマンドを実行する前に、アップロードする完全なディスクイメージの名前を overcloud-full.qcow2 に変更する必要があります。
付録D 代替ブートモード リンクのコピーリンクがクリップボードにコピーされました!
ノードのデフォルトブートモードは、iPXE を使用した BIOS です。以下の項では、ノードのプロビジョニングおよび検査の際に director が使用する代替ブートモードについて説明します。
D.1. 標準の PXE リンクのコピーリンクがクリップボードにコピーされました!
iPXE ブートプロセスは、HTTP を使用してイントロスペクションおよびデプロイメントのイメージをブートします。旧システムは、TFTP を介してブートする標準の PXE ブートのみをサポートしている場合があります。
iPXE から PXE に変更するには、director ホスト上の undercloud.conf ファイルを編集して、ipxe_enabled を False に設定します。
ipxe_enabled = False
ipxe_enabled = False
このファイルを保存して、アンダークラウドのインストールを実行します。
openstack undercloud install
$ openstack undercloud install
このプロセスに関する詳しい情報は、「Changing from iPXE to PXE in Red Hat OpenStack Platform director」のアーティクルを参照してください。
D.2. UEFI ブートモード リンクのコピーリンクがクリップボードにコピーされました!
デフォルトのブートモードは、レガシー BIOS モードです。新しいシステムでは、レガシー BIOS モードの代わりに UEFI ブートモードが必要な可能性があります。その場合には、undercloud.conf ファイルで以下のように設定します。
ipxe_enabled = True inspection_enable_uefi = True
ipxe_enabled = True
inspection_enable_uefi = True
このファイルを保存して、アンダークラウドのインストールを実行します。
openstack undercloud install
$ openstack undercloud install
登録済みの各ノードのブートモードを 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
$ 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 のケイパビリティーが保持されていることを確認してください
また、各フレーバーのブートモードを uefi に設定します。以下に例を示します。
openstack flavor set --property capabilities:boot_mode='uefi' control
$ openstack flavor set --property capabilities:boot_mode='uefi' control
付録E プロファイルの自動タグ付け リンクのコピーリンクがクリップボードにコピーされました!
イントロスペクションプロセスでは、一連のベンチマークテストを実行します。director は、これらのテストからデータを保存します。このデータをさまざまな方法で使用するポリシーセットを作成することができます。以下に例を示します。
- ポリシーにより、パフォーマンスの低いノードまたは不安定なノードを特定して、オーバークラウドで使用されないように隔離することができます。
- ポリシーにより、ノードを自動的に特定のプロファイルにタグ付けするかどうかを定義することができます。
E.1. ポリシーファイルの構文 リンクのコピーリンクがクリップボードにコピーされました!
ポリシーファイルは JSON 形式で、ルールセットが記載されます。各ルールでは、説明、条件、および アクション が定義されます。
description
これは、プレーンテキストで記述されたルールの説明です。
以下に例を示します。
"description": "A new rule for my node tagging policy"
"description": "A new rule for my node tagging policy"
conditions
ここでは、以下のキー/値のパターンを使用して評価を定義します。
- field
- 評価するフィールドを定義します。フィールドの種別については、「プロファイルの自動タグ付けのプロパティー」を参照してください。
- op
評価に使用する演算を定義します。これには、以下の属性が含まれます。
-
eq: 等しい -
ne: 等しくない -
lt: より小さい -
gt: より大きい -
le: より小さいか等しい -
ge: より大きいか等しい -
in-net: IP アドレスが指定のネットワーク内にあることを確認します。 -
matches: 指定の正規表現と完全に一致する必要があります。 -
contains: 値には、指定の正規表現が含まれる必要があります。 -
is-empty: フィールドが空欄であることをチェックします。
-
- invert
- 評価の結果をインバージョン (反転) するかどうかを定義するブール値
- multiple
複数の結果が存在する場合に、使用する評価を定義します。これには、以下の属性が含まれます。
-
any: いずれかの結果が一致する必要があります。 -
all: すべての結果が一致する必要があります。 -
first: 最初の結果が一致する必要があります。
-
- value
- 評価する値を定義します。フィールド、演算、および値の条件が満たされる場合には、true の結果を返します。そうでない場合には、条件は false の結果を返します。
以下に例を示します。
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 に設定すると、対象の値がすでに一覧に含まれている場合には何も追加しません。
以下に例を示します。
E.2. ポリシーファイルの例 リンクのコピーリンクがクリップボードにコピーされました!
適用するイントロスペクションルールを記載した JSON ファイル (rules.json) の例を以下に示します。
上記の例は、3 つのルールで構成されています。
- メモリーが 4096 MiB 未満の場合には、イントロスペクションに失敗する。このようなルールを適用して、クラウドに含まれるべきではないノードを除外することができます。
- ハードドライブのサイズが 1 TiB 以上のノードの場合、swift-storage プロファイルが無条件で割り当てられる。
-
ハードドライブが 1 TiB 未満だが 40 GiB を超えているノードは、コンピュートノードまたはコントローラーノードのいずれかに割り当てることができる。
openstack overcloud profiles matchコマンドを使用して後で最終選択できるように、2 つのケイパビリティー (compute_profileとcontrol_profile) を割り当てています。この設定が機能するように、既存のプロファイルのケイパビリティーは削除しています。削除しなかった場合には、そのケイパビリティーが優先されてしまいます。
他のノードは変更されません。
イントロスペクションルールを使用して profile 機能を割り当てる場合は常に、既存の値よりこの割り当てた値が優先されます。ただし、既存のプロファイル機能があるノードについては、[PROFILE]_profile 機能は無視されます。
E.3. ポリシーファイルのインポート リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドで、ポリシーファイルを director にインポートします。
openstack baremetal introspection rule import rules.json
$ openstack baremetal introspection rule import rules.json
次にイントロスペクションプロセスを実行します。
openstack baremetal introspection bulk start
$ openstack baremetal introspection bulk start
イントロスペクションが完了したら、ノードとノードに割り当てられたプロファイルを確認します。
openstack overcloud profiles list
$ openstack overcloud profiles list
イントロスペクションルールで間違いがあった場合には、すべてを削除できます。
openstack baremetal introspection rule purge
$ openstack baremetal introspection rule purge
E.4. プロファイルの自動タグ付けのプロパティー リンクのコピーリンクがクリップボードにコピーされました!
プロファイルの自動タグ付けは、各条件の field の属性に対する以下のノードプロパティーを評価します。
| 属性 | 説明 |
|---|---|
| memory_mb | ノードのメモリーサイズ (MB) |
| cpus | ノードの CPU の合計コア数 |
| cpu_arch | ノードの CPU のアーキテクチャー |
| local_gb | ノードのルートディスクのストレージの合計容量。ノードのルートディスクの設定についての詳しい説明は、「ノードのルートディスクの定義」を参照してください。 |
付録F UI アクセスの際の Firefox サーバーの例外 リンクのコピーリンクがクリップボードにコピーされました!
Firefox を使用して director の Web UI にアクセスするには、OpenStack Platform サービスを許可するために、特定サーバーのアイデンティティー例外を設定する必要があります。これには、以下のサービスの URL が含まれます。
| URL | サービス |
|---|---|
|
| OpenStack Identity (keystone) |
|
| OpenStack Orchestration (heat) |
|
| OpenStack Bare Metal (ironic) |
|
| OpenStack Workflow サービス (mistral) |
|
| OpenStack Object Storage (swift) |
|
| OpenStack Messaging サービス (zaqar) |
<undercloud> は、アンダークラウドのパブリック API の IP アドレスに置き換えます。
Firefox で URL のサーバーアイデンティティーの例外を追加するには、以下の手順を実施します。
- 設定 に移動します。
- 証明書 > 証明書を表示 の順に移動します。
- サーバー証明書 タブをクリックして 例外を追加 をクリックします。
- サーバーの URL の入力を求めるウィンドウが表示されます。上記の一覧からサービスの URL およびポートを入力し、証明書を取得 をクリックします。
- セキュリティー例外を承認 をクリックします。
すべてのサービスの URL について、例外の追加を続けます。
付録G セキュリティーの強化 リンクのコピーリンクがクリップボードにコピーされました!
以下の項では、アンダークラウドのセキュリティーを強化するための推奨事項について説明します。
G.1. 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
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 ...
[DEFAULT]
...
hieradata_override = haproxy-hiera-overrides.yaml
...