Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第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
    Copy to Clipboard Toggle word wrap
  • ironic-inspector は、/var/log/ironic-inspector/ramdisk/ に ramdisk ログを gz 圧縮の tar ファイルとして保存します。ファイル名には、日付、時間、ノードの IPMI アドレスが含まれます。イントロスペクションの問題を診断するには、これらのログを使用します。

11.1. ノード登録のトラブルシューティング
リンクのコピー

ノード登録における問題は通常、ノードの情報が間違っていることが原因で発生します。このような場合には、ironic を使用して、登録したノードデータの問題を修正します。以下にいくつか例を示します。

割り当てられたポートの UUID を確認します。 

$ ironic node-port-list [NODE UUID]
Copy to Clipboard Toggle word wrap

MAC アドレスを更新します。 

$ ironic port-update [PORT UUID] replace address=[NEW MAC]
Copy to Clipboard Toggle word wrap

次のコマンドを実行します。 

$ ironic node-update [NODE UUID] replace driver_info/ipmi_address=[NEW IPMI ADDRESS]
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

検出が完了したら、状態を「AVAILABLE」に戻してからプロビジョニングを行います。 

$ ironic node-set-provision-state [NODE UUID] provide
Copy to Clipboard Toggle word wrap

イントロスペクション済みのノードが PXE でブートできない

ノードがリブートする前に、ironic-inspector はアンダークラウドのファイアウォールの ironic-inspector チェーンにノードの MAC アドレスを追加します。これにより、ノードが PXE 経由でブートできるようになります。設定が正しいことを確認するには、以下のコマンドを実行します。 

$ `sudo iptables -L`
Copy to Clipboard Toggle word wrap

出力されるチェーンテーブルに、以下の 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
Copy to Clipboard Toggle word wrap

MAC アドレスが表示されない場合、最も一般的な原因は、SQLite データベース内にある ironic-inspector キャッシュの破損です。この問題を修正するには、以下のコマンドで SQLite ファイルを削除します。 

$ sudo rm /var/lib/ironic-inspector/inspector.sqlite
Copy to Clipboard Toggle word wrap

次に、以下のコマンドでこのファイルを再度作成します。 

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
Copy to Clipboard Toggle word wrap

検出プロセスの停止

現在 ironic-inspector では、直接検出プロセスを停止する方法はありません推奨されるパスは、プロセスがタイムアウトするまで待つことです。必要であれば、/etc/ironic-inspector/inspector.conf の timeout 設定を異なるタイムアウト時間 (分単位) に変更します。

最悪の場合、以下のプロセスを使用して全ノードの検出プロセスを停止することができます。

各ノードの電源状態をオフに変更します。 

$ ironic node-set-power-state [NODE UUID] off
Copy to Clipboard Toggle word wrap

ironic-inspector キャッシュを削除し、再起動します。 

$ rm /var/lib/ironic-inspector/inspector.sqlite
Copy to Clipboard Toggle word wrap

ironic-inspector キャッシュを再同期します。 

$ sudo ironic-inspector-dbsync --config-file /etc/ironic-inspector/inspector.conf upgrade
$ sudo systemctl restart openstack-ironic-inspector
Copy to Clipboard Toggle word wrap

introspection ramdisk へのアクセス

introspection ramdisk は、動的なログイン要素を使用します。これは、イントロスペクションのデバッグ中にノードにアクセスするための一時パスワードまたは SSH キーのいずれかを提供できることを意味します。以下のプロセスを使用して、ramdisk アクセスを設定します。

  1. openssl passwd -1 コマンドに一時パスワードを指定して MD5 ハッシュを生成します。以下に例を示します。 

    $ openssl passwd -1 mytestpassword
$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/
    Copy to Clipboard Toggle word wrap

  2. /httpboot/inspector.ipxe ファイルを編集して、kernel で開始する行を特定し、rootpwd パラメーターと MD5 ハッシュを追記します。以下に例を示します。 

    kernel http://192.2.0.1:8088/agent.kernel ipa-inspection-callback-url=http://192.168.0.1:5050/v1/continue ipa-inspection-collectors=default,extra-hardware,logs systemd.journald.forward_to_console=yes BOOTIF=${mac} ipa-debug=1 ipa-inspection-benchmarks=cpu,mem,disk rootpwd="$1$enjRSyIw$/fYUpJwr6abFy/d.koRgQ/" selinux=0
    Copy to Clipboard Toggle word wrap

    または、sshkey パラメーターに SSH 公開キーを追記します。

    注記

    rootpwd および sshkey のパラメーターにはいずれも二重引用符が必要です。

  3. イントロスペクションを開始し、arp コマンドまたは DHCP のログから IP アドレスを特定します。 

    $ arp
$ sudo journalctl -u openstack-ironic-inspector-dnsmasq
    Copy to Clipboard Toggle word wrap

  4. 一時パスワードまたは SSH キーを使用して、root ユーザーとして SSH 接続します。 

    $ ssh root@192.0.2.105
    Copy to Clipboard Toggle word wrap

イントロスペクションストレージのチェック

director は OpenStack Object Storage (swift) を使用して、イントロスペクションプロセス中に取得したハードウェアデータを保存します。このサービスが稼働していない場合には、イントロスペクションは失敗する場合があります。以下のコマンドを実行して、OpenStack Object Storage に関連したサービスをすべてチェックし、このサービスが稼働中であることを確認します。 

$ sudo systemctl list-units openstack-swift*
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

2 つ目のワークフローは、オーバークラウドのデプロイメントを開始します。 

Deploying templates in the directory /tmp/tripleoclient-LhRlHX/tripleo-heat-templates
Started Mistral Workflow. Execution ID: 97b64abe-d8fc-414a-837a-1380631c764d
2016-11-28 06:29:26Z [overcloud]: CREATE_IN_PROGRESS  Stack CREATE started
2016-11-28 06:29:26Z [overcloud.Networks]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.HeatAuthEncryptionKey]: CREATE_IN_PROGRESS  state changed
2016-11-28 06:29:26Z [overcloud.ServiceNetMap]: CREATE_IN_PROGRESS  state changed
...
Copy to Clipboard Toggle word wrap

Workflow オブジェクト

OpenStack Workflow では、以下のオブジェクトを使用してワークフローを追跡します。

アクション
関連タスクが実行される際に OpenStack が実施する特定の指示。これには、シェルスクリプトの実行や HTTP リクエストの実行などが含まれます。OpenStack の一部のコンポーネントには、OpenStack Workflow が使用するアクションが組み込まれています。
タスク
実行するアクションと、アクションの実行後の結果を定義します。これらのタスクには通常、アクションまたはアクションに関連付けられたワークフローが含まれます。タスクが完了したら、ワークフローは、タスクが成功したか否かによって、別のタスクに指示を出します。
ワークフロー
グループ化されて特定の順番で実行されるタスクのセット
実行
実行する特定のアクション、タスク、またはワークフローを定義します。

Workflow のエラー診断

OpenStack Workflow では、実行に関して着実にログを取ることもできるので、特定のコマンドが失敗した場合に問題を特定しやすくなります。たとえば、ワークフローの実行に失敗した場合には、どの部分で失敗したかを特定することができます。失敗した状態 (ERROR) のワークフローの実行を一覧表示します。 

$ mistral execution-list | grep "ERROR"
Copy to Clipboard Toggle word wrap

失敗したワークフロー実行の UUID を取得して (例: 3c87a885-0d37-4af8-a471-1b392264a7f5)、実行とその出力を表示します。 

$ mistral execution-get 3c87a885-0d37-4af8-a471-1b392264a7f5
$ mistral execution-get-output 3c87a885-0d37-4af8-a471-1b392264a7f5
Copy to Clipboard Toggle word wrap

これにより、実行で失敗したタスクに関する情報を取得できます。mistral execution-get は、実行に使用したワークフローも表示します (例: tripleo.plan_management.v1.update_deployment_plan)。以下のコマンドを使用して完全なワークフロー定義を表示することができます。 

$ mistral execution-get-definition tripleo.plan_management.v1.update_deployment_plan
Copy to Clipboard Toggle word wrap

これは、特定のタスクがワークフローのどの部分で発生するかを特定する際に便利です。

同様のコマンド構文を使用して、アクションの実行と、その結果を表示することもできます。 

$ mistral action-execution-list
$ mistral action-execution-get b59245bf-7183-4fcf-9508-c83ec1a26908
$ mistral action-execution-get-output b59245bf-7183-4fcf-9508-c83ec1a26908
Copy to Clipboard Toggle word wrap

これは、問題を引き起こす固有のアクションを特定する際に便利です。

11.4. オーバークラウドの作成に関するトラブルシューティング
リンクのコピー

デプロイメントが失敗する可能性のあるレイヤーは 3 つあります。

  • オーケストレーション (Heat および Nova サービス)
  • ベアメタルプロビジョニング (Ironic サービス)
  • デプロイメント後の設定 (Puppet)

オーバークラウドのデプロイメントがこれらのレベルのいずれかで失敗した場合には、OpenStack クライアントおよびサービスログファイルを使用して、失敗したデプロイメントの診断を行います。

11.4.1. Orchestration
リンクのコピー

多くの場合は、オーバークラウドの作成に失敗した後に、Heat により失敗したオーバークラウドスタックが表示されます。 

$ heat stack-list
+-----------------------+------------+--------------------+----------------------+
| id                    | stack_name | stack_status       | creation_time        |
+-----------------------+------------+--------------------+----------------------+
| 7e88af95-535c-4a55... | overcloud  | CREATE_FAILED      | 2015-04-06T17:57:16Z |
+-----------------------+------------+--------------------+----------------------+
Copy to Clipboard Toggle word wrap

スタック一覧が空の場合には、初期の Heat 設定に問題があることが分かります。Heat テンプレートと設定オプションをチェックし、さらに openstack overcloud deploy を実行後のエラーメッセージを確認してください。

11.4.2. ベアメタルプロビジョニング
リンクのコピー

ironic をチェックして、全登録ノードと現在の状態を表示します。 

$ ironic node-list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+
Copy to Clipboard Toggle word wrap

プロビジョニングプロセスでよく発生する問題を以下に示します。

  • 結果の表の「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]
    Copy to Clipboard Toggle word wrap

    エラーの説明が含まれる last_error フィールドがないか確認します。エラーメッセージが曖昧な場合、ログを使用して明確にすることができます。 

    $ sudo journalctl -u openstack-ironic-conductor -u openstack-ironic-api
    Copy to Clipboard Toggle word wrap
  • wait timeout error が表示されており、「Power State」が power on の場合には、問題のあるノードの仮想コンソールに接続して、出力を確認します。

11.4.3. デプロイメント後の設定
リンクのコピー

設定ステージでは多くの事象が発生する可能性があります。たとえば、設定に問題があるために、特定の Puppet モジュールの完了に失敗する可能性があります。本項では、これらの問題を診断するプロセスを説明します。

オーバークラウドスタックからのリソースをすべて表示して、どのスタックに問題があるのかを確認します。 

$ heat resource-list overcloud
Copy to Clipboard Toggle word wrap

このコマンドにより、すべてのリソースとその状態が表形式で表示されます。状態が CREATE_FAILED のリソースを探します。

問題のあるリソースを表示します。 

$ heat resource-show overcloud [FAILED RESOURCE]
Copy to Clipboard Toggle word wrap

resource_status_reason フィールドで、診断に役立つ可能性のある情報がないか確認します。

nova コマンドを使用して、オーバークラウドノードの IP アドレスを表示します。 

$ nova list
Copy to Clipboard Toggle word wrap

デプロイされたノードの 1 つに heat-admin ユーザーとしてログインします。たとえば、スタックのリソース一覧から、コントローラーノード上にエラーが発生していることが判明した場合には、コントローラーノードにログインします。heat-admin ユーザーには、sudo アクセスが設定されています。 

$ ssh heat-admin@192.0.2.14
Copy to Clipboard Toggle word wrap

os-collect-config ログを確認して、考えられる失敗の原因をチェックします。 

$ sudo journalctl -u os-collect-config
Copy to Clipboard Toggle word wrap

場合によっては、Nova によるノードのデプロイメントが完全に失敗する可能性があります。このような場合には、オーバークラウドのロール種別の 1 つの OS::Heat::ResourceGroup が失敗しているはずです。その際には、nova を使用して問題を確認します。 

$ nova list
$ nova show [SERVER ID]
Copy to Clipboard Toggle word wrap

最もよく表示されるエラーは、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
Copy to Clipboard Toggle word wrap

レポートを生成します。 

$ sudo sosreport --all-logs
Copy to Clipboard Toggle word wrap

コントローラーノードのデプロイ後のプロセスは、5 つの主なステップで構成されます。そのステップは以下のとおりです。

Expand
表11.1 コントローラーノードの設定ステップ

ステップ

説明

ControllerDeployment_Step1

Pacemaker、RabbitMQ、Memcached、Redis、および Galera を含むロードバランシング用のソフトウェアの初期設定

ControllerDeployment_Step2

Pacemaker の設定、HAProxy、MongoDB、Galera、Ceph Monitor、OpenStack Platform の各種サービス用のデータベースの初期化を含む、クラスターの初期設定

ControllerDeployment_Step3

OpenStack Object Storage (swift) の初期リング構築。OpenStack Platform の全サービス (nova、neutron、cinder、sahara、ceilometer、heat、horizon、aodh、gnocchi) の設定

ControllerDeployment_Step4

サービス起動順序やサービス起動パラメーターを決定するための制約事項を含む、Pacemaker でのサービスの起動設定値の設定

ControllerDeployment_Step5

OpenStack Identity (keystone) のプロジェクト、ロール、およびユーザーの初期設定

宛先のホストに、すでに使用中の IP アドレスが割り当てられている場合には、検出およびデプロイメントのタスクは失敗します。この問題を回避するには、プロビジョニングネットワークのポートスキャンを実行して、検出の IP アドレス範囲とホストの IP アドレス範囲が解放されているかどうかを確認することができます。

アンダークラウドホストで以下のステップを実行します。

nmap をインストールします。 

# yum install nmap
Copy to Clipboard Toggle word wrap

nmap を使用して、アクティブなアドレスの IP アドレス範囲をスキャンします。この例では、192.0.2.0/24 の範囲をスキャンします。この値は、プロビジョニングネットワークの IP サブネットに置き換えてください (CIDR 表記のビットマスク)。 

# nmap -sn 192.0.2.0/24
Copy to Clipboard Toggle word wrap

nmap スキャンの出力を確認します。

たとえば、アンダークラウドおよびサブネット上に存在するその他のホストの IP アドレスを確認する必要があります。アクティブな IP アドレスが undercloud.conf の IP アドレス範囲と競合している場合には、オーバークラウドノードのイントロスペクションまたはデプロイを実行する前に、IP アドレスの範囲を変更するか、IP アドレスを解放するかのいずれかを行う必要があります。 

# nmap -sn 192.0.2.0/24

Starting Nmap 6.40 ( http://nmap.org ) at 2015-10-02 15:14 EDT
Nmap scan report for 192.0.2.1
Host is up (0.00057s latency).
Nmap scan report for 192.0.2.2
Host is up (0.00048s latency).
Nmap scan report for 192.0.2.3
Host is up (0.00045s latency).
Nmap scan report for 192.0.2.5
Host is up (0.00040s latency).
Nmap scan report for 192.0.2.9
Host is up (0.00019s latency).
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.45 seconds
Copy to Clipboard Toggle word wrap

11.6. "No Valid Host Found" エラーのトラブルシューティング
リンクのコピー

/var/log/nova/nova-conductor.log に、以下のエラーが含まれる場合があります。 

NoValidHost: No valid host was found. There are not enough hosts available.
Copy to Clipboard Toggle word wrap

これは、Nova Scheduler が新規インスタンスをブートするのに適したベアメタルノードを検出できなかったことを意味します。このような場合、通常は、Nova が検出を想定しているリソースと Ironic が Nova に通知するリソースが一致しなくなります。その際には、以下の点をチェックしてください。

  1. イントロスペクションが正常に完了することを確認してください。または、各ノードに必要な Ironic ノードのプロパティーが含まれていることをチェックしてください。各ノードに以下のコマンドを実行します。 

    $ ironic node-show [NODE UUID]
    Copy to Clipboard Toggle word wrap

    properties JSON フィールドの cpus、cpu_arch、memory_mb、および local_gb キーに有効な値が指定されていることを確認してください。

  2. 使用する Nova フレーバーが、必要なノード数において、上記の Ironic ノードプロパティーを超えていないかどうかを確認します。 

    $ nova flavor-show [FLAVOR NAME]
    Copy to Clipboard Toggle word wrap
  3. ironic node-list の出力で、available の状態のノードの数が十分かどうかを確認します。ノードの状態が manageable の場合は通常、イントロスペクションに失敗しています。

  4. また、ノードがメンテナンスモードではないことを確認します。ironic node-list を使用してチェックしてください。通常、自動でメンテナンスモードに切り替わるノードは、電源の認証情報が間違っています。認証情報を確認して、メンテナンスモードをオフにします。 

    $ ironic node-set-maintenance [NODE UUID] off
    Copy to Clipboard Toggle word wrap
  5. Automated Health Check (AHC) ツールを使用して、自動でノードのタグ付けを行う場合には、各フレーバー/プロファイルに対応するノードが十分に存在することを確認します。ironic node-show の出力で、properties フィールドの capabilities キーを確認します。たとえば、Compute ロールのタグを付けられたノードには、profile:compute が含まれているはずです。

  6. イントロスペクションの後に Ironic から Nova にノードの情報が反映されるには若干時間がかかります。これは通常、director のツールが原因です。ただし、一部のステップを手動で実行した場合には、短時間ですが、Nova でノードが利用できなくなる場合があります。以下のコマンドを使用して、システム内の合計リソースをチェックします。 

    $ nova hypervisor-stats
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

    同様に、以下のコマンドを使用して、サービスの systemd ジャーナルを表示します。 

    $ sudo journalctl -u openstack-nova-compute.service
    Copy to Clipboard Toggle word wrap
  • コンピュートノードの主なログファイルは /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
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

  • directorには、同時にノードをプロビジョニングするリソースが十分にない場合があります。同時にプロビジョニングできるノード数はデフォルトで 10 個となっています。同時にプロビジョニングするノード数を減らすには、/etc/nova/nova.conf の max_concurrent_builds パラメーターを 10 未満に設定して Nova サービスを再起動します。 

    $ sudo systemctl restart openstack-nova-api openstack-nova-scheduler
    Copy to Clipboard Toggle word wrap

  • /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
    Copy to Clipboard Toggle word wrap

11.9. アンダークラウドとオーバークラウドの重要なログ
リンクのコピー

以下のログを使用して、トラブルシューティングの際にアンダークラウドとオーバークラウドの情報を割り出します。

Expand
表11.2 アンダークラウドの重要なログ
情報ログの場所

OpenStack Compute のログ

/var/log/nova/nova-compute.log

OpenStack Compute API の対話

/var/log/nova/nova-api.log

OpenStack Compute コンダクターのログ

/var/log/nova/nova-conductor.log

OpenStack Orchestration ログ

heat-engine.log

OpenStack Orchestration API の対話

heat-api.log

OpenStack Orchestration CloudFormations ログ

/var/log/heat/heat-api-cfn.log

OpenStack Bare Metal コンダクターのログ

ironic-conductor.log

OpenStack Bare Metal API の対話

ironic-api.log

イントロスペクション

/var/log/ironic-inspector/ironic-inspector.log

OpenStack Workflow Engine ログ

/var/log/mistral/engine.log

OpenStack Workflow Executor のログ

/var/log/mistral/executor.log

OpenStack Workflow API の対話

/var/log/mistral/api.log

Expand
表11.3 オーバークラウドの重要なログ
情報ログの場所

cloud-init に関するログ

/var/log/cloud-init.log

オーバークラウドの設定 (最後に実行した Puppet のサマリー)

/var/lib/puppet/state/last_run_summary.yaml

オーバークラウドの設定 (最後に実行した Puppet からのレポート)

/var/lib/puppet/state/last_run_report.yaml

オーバークラウドの設定 (全 Puppet レポート)

/var/lib/puppet/reports/overcloud-*/*

オーバークラウドの設定 (実行した Puppet 毎の標準出力)

/var/run/heat-config/deployed/*-stdout.log

オーバークラウドの設定 (実行した Puppet 毎の標準エラー出力)

/var/run/heat-config/deployed/*-stderr.log

高可用性に関するログ

/var/log/pacemaker.log

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat