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

第16章 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 つのユニットを使用します。該当するコンポーネントごとに両ユニットを使用します。以下に例を示します。 

    $ source ~/stackrc
(undercloud) $ 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 アドレスが含まれます。イントロスペクションの問題を診断するには、これらのログを使用します。

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

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

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

$ source ~/stackrc
(undercloud) $ openstack baremetal port list --node [NODE UUID]
Copy to Clipboard Toggle word wrap

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

(undercloud) $ openstack baremetal port set --address=[NEW MAC] [PORT UUID]
Copy to Clipboard Toggle word wrap

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

(undercloud) $ openstack baremetal node set --driver-info ipmi_address=[NEW IPMI ADDRESS] [NODE UUID]
Copy to Clipboard Toggle word wrap

16.2. ハードウェアイントロスペクションのトラブルシューティング
リンクのコピー

イントロスペクションのプロセスは最後まで実行する必要があります。ただし、Ironic の Discovery Daemon (ironic-inspector) は、検出する ramdisk が応答しない場合にはデフォルトの 1 時間が経過するとタイムアウトします。検出する ramdisk のバグが原因とされる場合もありますが、通常は特に BIOS の起動設定などの環境の誤設定が原因で発生します。

以下には、環境設定が間違っている場合の一般的なシナリオと、診断/解決方法に関するアドバイスを示します。

ノードのイントロスペクション開始におけるエラー

通常、イントロスペクションプロセスは、openstack overcloud node introspect コマンドを使用します。ただし、ironic-inspector で直接イントロスペクションを実行している場合には、「AVAILABLE」の状態のノードの検出に失敗する可能性があります。このコマンドは、デプロイメント用であり、検出用ではないためです。検出前に、ノードのステータスを「MANAGEABLE」に変更します。 

$ source ~/stackrc
(undercloud) $ openstack baremetal node manage [NODE UUID]
Copy to Clipboard Toggle word wrap

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

(undercloud) $ openstack baremetal node provide [NODE UUID]
Copy to Clipboard Toggle word wrap

検出プロセスの停止

イントロスペクションのプロセスを停止します。 

$ source ~/stackrc
(undercloud) $ openstack baremetal introspection abort [NODE UUID]
Copy to Clipboard Toggle word wrap

プロセスがタイムアウトするまで待つことも可能です。必要であれば、/etc/ironic-inspector/inspector.conf の timeout 設定を別の時間 (分単位) に変更します。

イントロスペクション ramdisk へのアクセス

イントロスペクションの 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.168.24.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

16.3. workflow および execution のトラブルシューティング
リンクのコピー

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 では、以下のオブジェクトを使用して、ワークフローを記録します。

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

Workflow のエラー診断

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

$ source ~/stackrc
(undercloud) $ openstack workflow execution list | grep "ERROR"
Copy to Clipboard Toggle word wrap

失敗したワークフローの実行の UUID を取得して (例: dffa96b0-f679-4cd2-a490-4769a3825262)、実行とその出力を表示します。 

(undercloud) $ openstack workflow execution show dffa96b0-f679-4cd2-a490-4769a3825262
(undercloud) $ openstack workflow execution output show dffa96b0-f679-4cd2-a490-4769a3825262
Copy to Clipboard Toggle word wrap

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

(undercloud) $ openstack workflow definition show tripleo.plan_management.v1.publish_ui_logs_to_swift
Copy to Clipboard Toggle word wrap

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

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

(undercloud) $ openstack action execution list
(undercloud) $ openstack action execution show 8a68eba3-0fec-4b2a-adc9-5561b007e886
(undercloud) $ openstack action execution output show 8a68eba3-0fec-4b2a-adc9-5561b007e886
Copy to Clipboard Toggle word wrap

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

16.4. オーバークラウドの作成のトラブルシューティング
リンクのコピー

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

  • Orchestration (Heat および Nova サービス)
  • Bare Metal Provisioning (Ironic サービス)
  • デプロイメント後の設定 (Ansible および Puppet)

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

16.4.1. デプロイメントコマンド履歴へのアクセス
リンクのコピー

director のデプロイメントコマンドおよび引数の履歴を把握することは、トラブルシューティングおよびサポートに役立ちます。/home/stack/.tripleo/history で、これらの情報を確認することができます。

16.4.2. Orchestration
リンクのコピー

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

$ source ~/stackrc
(undercloud) $ openstack stack list --nested --property status=FAILED
+-----------------------+------------+--------------------+----------------------+
| 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 を実行後のエラーメッセージを確認してください。

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

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

$ source ~/stackrc
(undercloud) $ openstack baremetal node list

+----------+------+---------------+-------------+-----------------+-------------+
| UUID     | Name | Instance UUID | Power State | Provision State | Maintenance |
+----------+------+---------------+-------------+-----------------+-------------+
| f1e261...| None | None          | power off   | available       | False       |
| f0b8c1...| None | None          | power off   | available       | False       |
+----------+------+---------------+-------------+-----------------+-------------+
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 の場合には、このノードの Bare Metal Provisioning は失敗しています。ベアメタルノードの詳細を確認してください。 

    (undercloud) $ openstack baremetal node show [NODE UUID]
    Copy to Clipboard Toggle word wrap

    エラーの説明が含まれる last_error フィールドがないか確認します。エラーメッセージは曖昧なため、ログを使用して解明します。 

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

16.4.4. オーバークラウド設定エラーの確認
リンクのコピー

オーバークラウドのデプロイメント操作が Ansible の設定ステージで失敗する場合には、openstack overcloud failures コマンドを使用してエラーの発生した設定ステップを表示します。

手順

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

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap

  2. デプロイメントのエラー発生ステップ確認コマンドを実行します。 

    $ openstack overcloud failures
    Copy to Clipboard Toggle word wrap

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

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

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

$ sudo yum install nmap
Copy to Clipboard Toggle word wrap

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

$ sudo nmap -sn 192.168.24.0/24
Copy to Clipboard Toggle word wrap

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

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

$ sudo nmap -sn 192.168.24.0/24

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

16.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 ノードのプロパティーが含まれていることをチェックしてください。各ノードに以下のコマンドを実行します。 

    $ source ~/stackrc
(undercloud) $ openstack baremetal node show [NODE UUID]
    Copy to Clipboard Toggle word wrap

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

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

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

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

    (undercloud) $ openstack baremetal node maintenance unset [NODE UUID]
    Copy to Clipboard Toggle word wrap
  5. Automated Health Check (AHC) ツールを使用して、自動でノードのタグ付けを行う場合には、各フレーバー/フレーバーに対応するノードが十分に存在することを確認します。properties フィールドの capabilities キーに openstack baremetal node show がないか確認します。たとえば、コンピュートロールのタグを付けられたノードには、profile:compute が含まれているはずです。

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

    (undercloud) $ openstack hypervisor stats show
    Copy to Clipboard Toggle word wrap

16.7. オーバークラウド作成後のトラブルシューティング
リンクのコピー

オーバークラウドを作成した後には、将来そのオーバークラウドで特定の操作を行うようにすることができます。たとえば、利用可能なノードをスケーリングしたり、障害の発生したノードを置き換えたりすることができます。このような操作を行うと、特定の問題が発生する場合があります。本項には、オーバークラウド作成後の操作が失敗した場合の診断とトラブルシューティングに関するアドバイスを記載します。

16.7.1. オーバークラウドスタックの変更
リンクのコピー

director を使用して overcloud スタックを変更する際に問題が発生する場合があります。スタックの変更例には、以下のような操作が含まれます。

  • ノードのスケーリング
  • ノードの削除
  • ノードの置き換え

スタックの変更は、スタックの作成と似ており、director は要求されたノード数が利用可能かどうかをチェックして追加のノードをプロビジョニングしたり、既存のノードを削除したりしてから、Puppet の設定を適用します。overcloud スタックを変更する場合に従うべきガイドラインを以下に記載します。

以下のセクションには、特定の種別のノード上の問題診断に関するアドバイスを記載します。

16.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/ でそれぞれのコンポーネントのログファイルを確認します。

16.7.3. コンテナー化されたサービスのエラー
リンクのコピー

オーバークラウドのデプロイメント中またはデプロイメント後にコンテナー化されたサービスでエラーが発生した場合には、以下の推奨事項に従って、エラーの根本的な原因を特定してください。

注記

これらのコマンドを実行する前には、オーバークラウドノードにログイン済みであることを確認し、これらのコマンドをアンダークラウドで実行しないようにしてください。

コンテナーログの確認

各コンテナーは、主要プロセスからの標準出力を保持します。この出力はログとして機能し、コンテナー実行時に実際に何が発生したのかを特定するのに役立ちます。たとえば、keystone コンテナーのログを確認するには、以下のコマンドを使用します。 

$ sudo docker logs keystone
Copy to Clipboard Toggle word wrap

大半の場合は、このログにコンテナーのエラーの原因が記載されています。

コンテナーの検査

状況によっては、コンテナーに関する情報を検証する必要がある場合があります。たとえば、以下のコマンドを使用して keystone コンテナーのデータを確認します。 

$ sudo docker inspect keystone
Copy to Clipboard Toggle word wrap

これにより、ローレベルの設定データが含まれた JSON オブジェクトが提供されます。その出力を jq コマンドにパイプして、特定のデータを解析することが可能です。たとえば、keystone コンテナーのマウントを確認するには、以下のコマンドを実行します。 

$ sudo docker inspect keystone | jq .[0].Mounts
Copy to Clipboard Toggle word wrap

--format オプションを使用して、データを単一行に解析することができます。これは、コンテナーデータのセットに対してコマンドを実行する場合に役立ちます。たとえば、keystone コンテナーを実行するのに使用するオプションを再生成するには、以下のように inspect コマンドに --format オプションを指定して実行します。 

$ sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone
Copy to Clipboard Toggle word wrap
注記

--format オプションは、Go 構文を使用してクエリーを作成します。

これらのオプションを docker run コマンドとともに使用して、トラブルシューティング目的のコンテナーを再度作成します。 

$ OPTIONS=$( sudo docker inspect --format='{{range .Config.Env}} -e "{{.}}" {{end}} {{range .Mounts}} -v {{.Source}}:{{.Destination}}{{if .Mode}}:{{.Mode}}{{end}}{{end}} -ti {{.Config.Image}}' keystone )
$ sudo docker run --rm $OPTIONS /bin/bash
Copy to Clipboard Toggle word wrap

コンテナー内でのコマンドの実行

状況によっては、特定の Bash コマンドでコンテナー内の情報を取得する必要がある場合があります。このような場合には、以下の docker コマンドを使用して、稼働中のコンテナー内でコマンドを実行します。たとえば、keystone コンテナーで次のコマンドを実行します。 

$ sudo docker exec -ti keystone <COMMAND>
Copy to Clipboard Toggle word wrap
注記

-ti オプションを指定すると、コマンドは対話式の擬似ターミナルで実行されます。

<COMMAND> は必要なコマンドに置き換えます。たとえば、各コンテナーには、サービスの接続を確認するためのヘルスチェックスクリプトがあります。keystone にヘルスチェックスクリプトを実行するには、以下のコマンドを実行します。 

$ sudo docker exec -ti keystone /openstack/healthcheck
Copy to Clipboard Toggle word wrap

コンテナーのシェルにアクセスするには、/bin/bash をコマンドとして使用する docker exec を実行します。 

$ sudo docker exec -ti keystone /bin/bash
Copy to Clipboard Toggle word wrap

コンテナーのエクスポート

コンテナーが失敗した場合には、ファイルの詳細を調べる必要があります。この場合は、コンテナーの全ファイルシステムを tar アーカイブとしてエクスポートすることができます。たとえば、keystone コンテナーのファイルシステムをエクスポートするには、以下のコマンドを実行します。 

$ sudo docker export keystone -o keystone.tar
Copy to Clipboard Toggle word wrap

このコマンドにより keystone.tar アーカイブが作成されます。これを抽出して、調べることができます。

16.7.4. Compute サービスのエラー
リンクのコピー

コンピュートノードは、Compute サービスを使用して、ハイパーバイザーベースの操作を実行します。これは、このサービスを中心にコンピュートノードのメインの診断が行われていることを意味します。以下に例を示します。

  • コンテナーのステータスを表示します。 

    $ sudo docker ps -f name=nova_compute
    Copy to Clipboard Toggle word wrap
  • コンピュートノードの主なログファイルは /var/log/containers/nova/nova-compute.log です。コンピュートノードの通信で問題が発生した場合に、通常はこのログが診断を開始するのに適した場所です。
  • コンピュートノードでメンテナンスを実行する場合には、既存のインスタンスをホストから稼働中のコンピュートノードに移行し、ノードを無効にします。ノードの移行についての詳しい情報は、「コンピュートノードからのインスタンスの移行」を参照してください。

16.7.5. Ceph Storage サービスのエラー
リンクのコピー

Red Hat Ceph Storage クラスターで発生した問題については、『Red Hat Ceph Storage Configuration Guide』の「Logging Configuration Reference」を参照してください。この項には、全 Ceph Storage サービスのログ診断についての情報が記載されています。

16.8. アンダークラウドの調整
リンクのコピー

このセクションでのアドバイスは、アンダークラウドのパフォーマンスを向上に役立たせることが目的です。必要に応じて、推奨事項を実行してください。

  • Identity Service (keystone) は、他の OpenStack サービスに対するアクセス制御にトークンベースのシステムを使用します。ある程度の期間が過ぎた後には、データベースに未使用のトークンが多数蓄積されます。デフォルトの cronjob は毎日トークンをフラッシュします。環境をモニタリングして、トークンのフラッシュ間隔を調節することを推奨します。アンダークラウドの場合は、crontab -u keystone -e のコマンドで間隔を調整することができます。この変更は一時的で、openstack undercloud update を実行すると、この cronjob の設定はデフォルトに戻ってしまう点に注意してください。

  • Heat は、openstack overcloud deploy を実行するたびにデータベースの 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
    データベースのトランザクションが、行のロック待ちを中断するまでの時間 (秒単位)。
    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

16.9. SOS レポートの作成
リンクのコピー

Red Hat に連絡して OpenStack Platform に関するサポートを受ける必要がある場合は、SOS レポート を生成する必要がある場合があります。SOS レポート の作成方法についての詳しい説明は、以下のナレッジベースの記事を参照してください。

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

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

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

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
表16.2 オーバークラウドの重要なログ
情報ログの場所

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