[ English | Indonesia | Deutsch | 日本語 ]

故障しているコンポーネントの特定

OpenStack は、異なるコンポーネント同士が互いに強く連携して動作しています。たとえば、イメージのアップロードでは、 nova-api, glance-api, glance-registry, keystone が連携する必要があります。 swift-proxy も関係する場合があります。その結果、時として問題が発生している箇所を正確に特定することが難しくなります。これを支援することがこのセクションの目的です。

最新ログの確認

最初に確認する場所は、実行しようとしているコマンドに関連するログファイルです。たとえば、openstack server list が失敗していれば、nova ログファイルを tail 表示しながら、次のコマンドを再実行してください。

端末 1:

# tail -f /var/log/nova/nova-api.log

端末 2:

# openstack server list

何らかのエラーまたはトレースをログファイルで探します。詳細は ロギングと監視 を参照してください。

エラーから問題が他のコンポーネントにあることが分かる場合には、そのコンポーネントのログファイルに表示を切り替えます。nova が glance にアクセスできなければ、 glance-api ログを確認します:

端末 1:

# tail -f /var/log/glance/api.log

端末 2:

# openstack server list

問題の根本となる原因を見つけるまで、洗い出し、精査し、繰り返します。

コマンドラインでのデーモンの実行

残念ながら、ときどきエラーがログファイルに表れない場合があります。このような場合、作戦を変更し、違うコマンドを使用します。おそらくコマンドラインにおいて直接サービスを実行することです。たとえば、glance-api サービスが起動しなかったり、実行状態にとどまらない場合は、コマンドラインからデーモンを起動してみます。

# sudo -u glance -H glance-api

これにより、エラーと問題の原因が表示されるかもしれません。

注釈

sudo を用いてデーモンを実行するとき、 -H フラグが必要です。いくつかのデーモンは、ユーザーのホームディレクトリーからの相対パスのファイルに書き込みを行うため、 -H がないと、この書き込みが失敗してしまいます。

Tip

複雑さの例

ある朝、あるノードでインスタンスの実行がすべて失敗するようになりました。ログファイルがすこしあいまいでした。特定のインスタンスが起動できなかったことを示していました。これは最終的に偽の手掛かりであることがわかりました。単にそのインスタンスがアルファベット順で最初のインスタンスだったので、 nova-compute が最初に操作したのがそのインスタンスだったというだけでした。

さらなるトラブルシューティングにより、libvirt がまったく動作していないことがわかりました。これは大きな手がかりです。libvirt が動作していないと、KVM によるインスタンスの仮想化ができません。libvirt を開始させようとしても、libvirt は何も表示せずすぐに停止しました。libvirt のログでは理由がわかりませんでした。

次に、 libvirtd デーモンをコマンドラインにおいて実行しました。最終的に次のような役に立つエラーメッセージが得られました。d-bus に接続できませんでした。このため、滑稽に聞こえるかもしれませんが、libvirt 、その結果として nova-compute も D-Bus に依存していて、どういう訳か D-Bus がクラッシュしました。単に D-Bus を開始するだけで、一連のプログラムがうまく動くようになり、すぐに全部が元に戻り動作状態になりました。