Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

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

15.7.1. オーバークラウドスタックの変更

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

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

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

第一段階として、「デプロイメント後の設定」に記載したアドバイスに従います。この手順と同じステップを、overcloud Heat スタック更新の問題の診断に役立てることができます。特に、以下のコマンドを使用して問題のあるリソースを特定します。

openstack stack list --show-nested
全スタックを一覧表示します。--show-nested はすべての子スタックとそれぞれの親スタックを表示します。このコマンドは、スタックでエラーが発生した時点を特定するのに役立ちます。
openstack stack resource list overcloud
overcloud スタック内の全リソースと現在の状態を一覧表示します。このコマンドは、スタック内でどのリソースが原因でエラーが発生しているかを特定するのに役立ちます。このリソースのエラーの原因となっている Heat テンプレートコレクションと Puppet モジュール内のパラメーターと設定を特定することができます。
openstack stack event list overcloud
overcloud スタックに関連するすべてのイベントを時系列で一覧表示します。これには、スタック内の全リソースのイベント開始/完了時間とエラーが含まれます。この情報は、リソースの障害点を特定するのに役立ちます。

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

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

15.7.3. コンテナー化されたサービスのエラー

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

注記

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

コンテナーログの確認

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

$ sudo docker logs keystone

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

コンテナーの検査

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

$ sudo docker inspect keystone

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

$ sudo docker inspect keystone | jq .[0].Mounts

--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
注記

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

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

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

$ sudo docker exec -ti keystone <COMMAND>
注記

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

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

$ sudo docker exec -ti keystone /openstack/healthcheck

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

$ sudo docker exec -ti keystone /bin/bash

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

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

$ sudo docker export keystone -o keystone.tar

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

15.7.4. Compute サービスのエラー

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

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

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

15.7.5. Ceph Storage サービスのエラー

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