第4章 保守
4.3 トラブルシューティング
ここでは、トラブルシューティングについて説明します。
4.3.1 管理サーバ(コントローラーVM1とコントローラーVM2)のトラブルシューティング
ここでは、管理サーバ(コントローラーVM1とコントローラーVM2)に対するトラブルシューティングについて説明します。
運用中に、管理サーバ(コントローラーVM1とコントローラーVM2)がダウンした場合、本項の記事を参照して復旧してください。
本項の記事を参照しても復旧できなかった場合、調査資料を採取し、当社技術員に連絡してください。
4.3.1.1 レスポンスで "ERROR:/etc/opt/FJSVrorcpf/availability_zone/nova:read failed" が 返却される場合
nova、cinder、glance、neutron、autoscaleのAPI実行時に、レスポンスのメッセージが以下の場合、再度実行してください。
"ERROR:/etc/opt/FJSVrorcpf/availability_zone/nova:read failed"
4.3.1.2 インスタンスにポートを追加する Nova API のレスポンスで "ERROR:communication error" が返却される場合
"POST /v2/{tenant_id}/servers/{server_id}/os-interface"のAPIにおいて、レスポンスメッセージが"ERROR:communication error"の場 合、しばらく時間をおいてから再度実行してください。
再度実行後、ポートの追加に失敗した場合、調査資料を採取し、当社技術員に連絡してください。
4.3.1.3 Nova API でインスタンスからポートを削除したが、正しく削除されない場合
Nova APIでインスタンスからポートを削除したが、正しく削除されない場合、該当する業務サーバ(コンピュートノード)の/var/log/nova/
compute.logのログメッセージを確認してください。以下のメッセージが出力されていた場合、処理を再度実行してください。
"PortNotFound: Port 削除したいポートのID is not attached"
4.3.1.4 ライブマイグレーションが失敗した場合
ライブマイグレーションが失敗した場合、調査資料を採取し、当社技術員に連絡してください。
4.3.1.5 インスタンスの作成 / 削除中に、管理サーバ ( コントローラー VM2) のサービスが停止
し、インスタンスの Status が "ERROR" になった場合
インスタンスの作成/削除中に、管理サーバ(コントローラーVM2)のサービスが停止した場合、インスタンスのStatusが"ERROR"になる 場合があります。
以下の手順で削除してください。
# . /root/openrc <RETURN>
# nova reset-state --active インスタンスID <RETURN>
# nova delete インスタンスID <RETURN>
4.3.1.6 インスタンスの起動 / 停止処理実行後、インスタンスの Task State が "powering-on" ま たは"powering-off"のままになった場合
インスタンスの起動処理実行後に、インスタンスのTask Stateが"powering-on"のままになった場合、以下の手順で復旧してください。
# . /root/openrc <RETURN>
# nova reset-state --active インスタンスID <RETURN>
# nova reboot インスタンスID <RETURN>
インスタンスの停止処理実行後に、インスタンスのTask Stateが"powering-off"のままになった場合、以下の手順で復旧してください。
# . /root/openrc <RETURN>
# nova reset-state --active インスタンスID <RETURN>
# nova stop インスタンスID <RETURN>
4.3.1.7 ceilometerコマンド、APIが正常に動作しなくなった場合
ceilometerコマンド、APIが正常に動作しなくなった場合、管理サーバ(コントローラーVM2)の/var/log/ceilometer/alarm-evaluator.logの ログメッセージを確認してください。
"CommunicationError: Error communicating with http://サービスLANのIPアドレス:8777 timed out"のメッセージが出力されていた場 合、以下のコマンドを実行してください。
# service openstack-ceilometer-alarm-evaluator stop <RETURN>
# service openstack-ceilometer-api stop <RETURN>
# service openstack-ceilometer-api start <RETURN>
# service openstack-ceilometer-alarm-evaluator start <RETURN>
再度、ceilometerコマンドおよびAPIを実行し、正常に動作しない場合、調査資料を採取し、当社技術員に連絡してください。
4.3.2 業務サーバ(コンピュートノード)のトラブルシューティング
ここでは、業務サーバ(コンピュートノード) に対するトラブルシューティングについて説明します。
運用中に、業務サーバ(コンピュートノード)がダウンした場合、本項の記事を参照して復旧してください。
本項の記事を参照しても復旧できなかった場合、調査資料を採取し、当社技術員に連絡してください。
4.3.2.1 本製品で配備したインスタンスが自動起動しない場合
業務サーバ(コンピュートノード)を停止状態から起動させた場合、本製品で配備したインスタンスは自動起動しません。
また、インスタンスのステータスが起動状態のままで、インスタンスは起動していない場合、以下の手順で復旧してください。
1.
管理サーバ(コントローラーVM2)にrootでログインしてください。2.
以下のコマンドを実行し、インスタンスを再起動します。# . /root/openrc <RETURN>
# nova reboot インスタンスのID <RETURN>
4.3.2.2 業務サーバ ( コンピュートノード ) 再起動後に、本製品で配備したインスタンスの task_state 値が "deleting" になる場合
インスタンスを削除中に、削除中のインスタンスが配備されている業務サーバ(コンピュートノード)を停止させた際、インスタンスの実態 が削除された状態で、インスタンスのtask_state値が"deleting"になる場合があります。
以下の手順で削除してください。
1.
管理サーバ(コントローラーVM2)にrootでログインしてください。2.
以下のコマンドを実行します。# . /root/openrc <RETURN>
# nova reset-state --active インスタンスのID <RETURN>
# nova delete インスタンスのID <RETURN>
4.3.2.3 libvirt-guestsが自動起動に失敗する場合
業務サーバ(コンピュートノード)でlibvirt-guestsが自動起動に失敗する場合があります。
以下の手順を実行して、復旧してください。
# /opt/FJSVpf4c/bin/rcx_service stop <return>
# /opt/FJSVpf4c/bin/rcx_service start <return>
以下のコマンドを実行して、サービスの状態を確認してください。
# /opt/FJSVpf4c/bin/rcx_service status <return>
4.3.2.4 業務サーバ ( コンピュートノード ) 切替え後、または切替え中に、インスタンスに対する
リクエストがエラーとなる場合【HA構成】
業務サーバ(コンピュートノード)がクラスタ環境の場合、業務サーバ(コンピュートノード)故障時に、自動で業務サーバ(コンピュートノー ド)の切替えを実施します。
切替え後、または切替え中に、インスタンスに対するリクエストがエラーとなる場合があります。
インスタンスに対するリクエストがエラーとなった場合は、以下を確認してください。
1.
管理サーバ(コントローラーVM2)にroot権限でログインします。2.
インスタンスの状態が"ERROR"、または"REBUILD"ではないことを確認します。# . /root/openrc <RETURN>
# nova show インスタンスID | grep status <RETURN>
3.
インスタンスの状態が"ERROR"、または"REBUILD"の場合、以下を実施します。"ERROR"の場合
当社技術員に連絡してください。
"REBUILD"の場合
移動中のため、5分ほど待ってから再確認してください。
再度確認後、インスタンスの状態が変わらない場合は、当社技術員に連絡してください。
4.3.2.5 システムログにmultipathdのエラーが出力された場合
システムログに以下のmultipathdのエラーが出力される場合があります。
"sdxx - tur checker reports path is down"
上記メッセージが表示された場合、以下のコマンドを実行し、 multipathd サービスを再起動してください。
# systemctl restart multipathd <RETURN>
現象が頻発する場合には、当社技術員に連絡してください。
4.3.2.6 システムログに libvirt のエラーが出力された場合
システムログに以下のどちらかのlibvirtのエラーが出力される場合があります。
journal: internal error: End of file from monitor
journal: internal error: unable to execute QEMU command '__com.redhat_drive_del': An undefined error has occurred 出力されても問題のないメッセージですので、対処は必要ありません。
4.3.2.7 インスタンスに対してボリュームのアタッチ処理実行後、インスタンスにボリュームが
アタッチされない場合
インスタンスに対して、ボリュームのアタッチを行った際、操作は成功するが、実際にアタッチされない場合があります。
アタッチ処理を再度実行してください。
4.3.2.8 インスタンス起動時にボリューム作成が失敗した場合
以下のインスタンスのブートソースを選択してインスタンスを起動した際に、ボリューム作成が失敗する場合があります。
・
イメージから起動(新しいボリュームを作成)・
ボリュームのスナップショットから起動(新しいボリュームを作成)/var/log/nova/nova-compute.log に以下のメッセージが出力されていた場合、該当インスタンスを削除し、処理を再度実行してください。
"Build of instance インスタンスID aborted: Block Device Mapping is Invalid"
処理を再実施後も同じメッセージが表示された場合には、「4.3.4.1 システムログにmultipathdのエラーが出力された場合」を参照して 対処してください。
4.3.3 ダッシュボード(Horizon)のトラブルシューティング
ここでは、ダッシュボード(Horizon)のトラブルシューティングについて説明します。
4.3.3.1 ダッシュボード (Horizon) の [ 管理 ] タブにおいて、 [ リソース使用状況 ] -[ 統計情報 ] をク リックした際にエラーが発生する場合
ダッシュボード(Horizon)の[管理]タブにおいて、[リソース使用状況] -[統計情報]をクリックした際にエラーが発生する場合があります。
エラーが発生した場合には、以下の手順でリソース使用情報を取得してください。
環境変数の読み込み
以下のコマンドを管理サーバ(コントローラーVM2)で実行します。
# . /root/openrc <RETURN>
測定項目の取得
cpu_utilの測定項目の取得例は以下のとおりです。
ceilometerの詳細は、「2.3.4 ceilometer」を参照してください。
他の項目を取得する場合は-mオプションの指定内容を変更してください。
project_id、resource_idはダッシュボード(Horizon)の各リソース項目から取得してください。
・
cpu_utilの統計情報を、計測間隔10分で取得する場合# ceilometer statistics -m cpu_util -p 600 <RETURN>
・
cpu_utilの統計情報を、計測間隔10分で、プロジェクトごとにグルーピングして取得する場合# ceilometer statistics -m cpu_util -p 600 -g project_id <RETURN>
タイムアウトした場合、以下の方法で検索対象を絞ります。
・
cpu_utilの統計情報を以下の条件に基づいて取得する場合－
条件1: 計測間隔は10分－
条件2: 2016-02-05T03:00:00以降# ceilometer statistics -m cpu_util -p 600 -q 'timestamp>2016-02-05T03:00:00' <RETURN>
・
cpu_utilの統計情報を以下の条件に基づいて取得する場合－
条件1: 計測間隔は10分－
条件2: 2016-02-05T03:00:00以降－
条件3: 2016-02-05T04:00:00以前# ceilometer statistics -m cpu_util -p 600 -q 'timestamp>2016-02-05T03:00:00;timestamp<2016-02-05T04:00:00'
<RETURN>
・
cpu_utilの統計情報を、計測間隔10分で、プロジェクトを指定して取得する場合# ceilometer statistics -m cpu_util -p 600 -q 'project_id=bdcd0f7818e947b2841a2dc860d549cf' <RETURN>
・
cpu_utilの統計情報を、計測間隔10分で、リソースを指定して取得する場合# ceilometer statistics -m cpu_util -p 600 -q 'resource_id=bdcd0f7818e947b2841a2dc860d549cf' <RETURN>
または、--timeoutオプションでタイムアウト時間を伸ばしてください。
・
cpu_utilの統計情報を、計測間隔10分で、タイムアウト時間1時間で取得する場合# ceilometer --timeout 3600 statistics -m cpu_util -p 600 <RETURN>