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 ノードは、Compute サービスを使用して、ハイパーバイザーベースの操作を実行します。これは、このサービスを中心にコンピュートノードのメインの診断が行われていることを意味します。以下に例を示します。
  • 以下の systemd 機能を使用してサービスのステータスを確認します。 
    $ sudo systemctl status openstack-nova-compute.service
    同様に、以下のコマンドを使用して、サービスの systemd ジャーナルを確認します。 
    $ sudo journalctl -u openstack-nova-compute.service
  • コンピュートノードのプライマリーログファイルは /var/log/nova/nova-compute.log です。コンピュートノードの通信で問題が発生した場合には、このログファイルは診断を開始するのに適した場所です。
  • コンピュートノードでメンテナンスを実行する場合には、既存のインスタンスをホストから稼働中のコンピュートノードに移行し、ノードを無効にします。ノードの移行についての詳しい情報は、「オーバークラウドのコンピュートノードからの仮想マシンの移行」 を参照してください。

⁠11.7.4. Ceph Storage サービスのエラー

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