第4章 保守
4.2 トラブル発生時の対処
4.2.4 クラスタ構成の業務サーバ(コンピュートノード)の復旧 【HA構成】
4.2.4.3 OS 再起動による業務サーバ ( コンピュートノード ) の復旧
ログの格納場所
業務サーバ(コンピュートノード)のフェイルオーバが実行されると、代表ノードに以下の情報が出力されます。
代表ノードの確認は、「代表ノードの確認方法」を参照してください。
・
スクリプトログ業務サーバ(コンピュートノード)のフェイルオーバで発生したログのことです。
－
スクリプトログの格納場所 /var/opt/FJSVpf4c/logs/rcx_ha.log・
システムログ－
システムログの格納場所 /var/log/messages－
システムログの表示内容システムログの表示内容は、「4.4.5 業務サーバ(コンピュートノード)のフェイルオーバでエラーが発生した場合のメッセージ
【HA構成】」を参照してください。
・
evacuated_list.logインスタンスが移動した時の情報です。
－
evacuated_list.logの格納場所/var/opt/FJSVpf4c/logs/evacuated_list.log
－
evacuated_list.logの表示内容以下のフォーマットで表示されます。
移行開始時刻 [Success | Failure] インスタンスID 移行元ノード名 移行先ノード名 移行元ノード
移行元の業務サーバ(コンピュートノード) 移行先ノード
移行先の業務サーバ(コンピュートノード)
例
20160615-10:37:24 Success 60adcde4-7d77-4007-95ce-9f06283887fe compute2 compute1 20160615-10:40:56 Success 1c9436ec-9897-4cc2-b1d6-4d30d33b7fb5 compute2 compute1 20160615-10:40:58 Success 4fdc0061-db68-4ab6-bb13-64d07e2b4f68 compute2 compute1 20160615-10:40:59 Success f366d83e-7c8b-4bcf-80e4-1401683cac84 compute2 compute1
代表ノードの確認方法
1.
管理サーバ(コントローラーVM2)にroot権限でログインします。2.
以下のコマンドを実行します。稼働ノード名には、任意の稼働ノード名を指定してください。
# ssh 稼働ノード名 "hvdisp -a |grep -w leaderapp" <RETURN>
3.
出力結果から代表ノードを確認します。－
指定した稼働ノードが代表ノードの場合 以下の内容が出力されます。leaderapp userApp Online
－
指定した稼働ノード以外のノードが代表ノードの場合コマンドの実行結果の赤文字、かつ下線部が代表ノード名を示しています。
leaderapp userApp Offline leaderapp userApp 代表ノード名RMS Online
業務サーバ(コンピュートノード)のノード名の例
業務サーバ(コンピュートノード)のノード名が以下の場合の例を示します。
図4.7 稼動ノードが故障した場合の例
稼動ノード
compute2、compute3 故障した稼動ノード
compute1 待機ノード
compute4
図4.8 待機ノードが故障した場合の例
稼動ノード
compute1、compute2、compute3 待機ノード
compute4
4.2.4.1 PRIMECLUSTER の状態確認
1.
待機ノードにroot権限でログインします。2.
異常が発生した業務サーバ(コンピュートノード)の状態を確認します。以下のコマンドを実行します。
# cftool -n <RETURN>
Node Number State Os Cpu Compute1 1 DOWN Linux EM64T Compute2 2 UP Linux EM64T Compute3 3 UP Linux EM64T Compute4 4 UP Linux EM64T
異常が発生した業務サーバ(コンピュートノード)のStateが"LEFTCLUSTER"状態になっている場合は、シャットダウン機構(SF)による強 制停止処理が失敗し、クラスタパーティションが発生していることを意味します。
その場合は、以下の手順にしたがって手動で回復してください。
1.
停止していた業務サーバ(コンピュートノード)を再起動します。2.
業務サーバ(コンピュートノード)がクラスタに参入したことを確認します。以下のコマンドを実行し、各業務サーバ(コンピュートノード)のStateが"UP"になっていることを確認します。
# cftool -n <RETURN>
Node Number State Os Cpu compute1 1 UP Linux EM64T compute2 2 UP Linux EM64T compute3 3 UP Linux EM64T compute4 4 UP Linux EM64T
参考
詳細は、「PRIMECLUSTER Cluster Foundation 導入運用手引書」を参照してください。
待機ノードで異常が発生した場合
待機ノードで異常が発生した場合は、以下の手順を実施してください。
1.
稼働ノードにroot権限でログインします2.
以下のコマンドを実行し、leaderappが稼働ノード上で起動したことを確認します。leaderappのStateが"Online"になっていることを確認します。
以下のコマンドの実行例はどちらも、compute1上でleaderappが起動している場合の出力結果です。
－
ログインした稼働ノード上でleaderappが起動している場合# hvdisp -a <RETURN>
Local System: compute1RMS
Configuration: /opt/SMAW/SMAWRrms/build/openstack.us
Resource Type HostName State StateDetails ---compute4RMS SysNode Online
compute3RMS SysNode Online compute2RMS SysNode Online compute1RMS SysNode Online leaderapp userApp Online Machine003_leaderapp andOp compute4RMS
Machine002_leaderapp andOp compute3RMS Machine001_leaderapp andOp compute2RMS
Machine000_leaderapp andOp compute1RMS Online
ManageProgram000_Cmd_LEADERAPP gRes Online
－
他の稼働ノード上でleaderappが起動している場合# hvdisp -a <RETURN>
Local System: compute1RMS
Configuration: /opt/SMAW/SMAWRrms/build/openstack.us
Resource Type HostName State StateDetails ---compute4RMS SysNode Online
compute3RMS SysNode Online compute2RMS SysNode Online compute1RMS SysNode Online leaderapp userApp Offline leaderapp userApp compute1RMS Online Machine003_leaderapp andOp compute4RMS
Machine002_leaderapp andOp compute3RMS
Machine001_leaderapp andOp compute2RMS Offline Machine000_leaderapp andOp compute1RMS
ManageProgram000_Cmd_LEADERAPP gRes Online
4.2.4.2 ストレージの復旧
ここでは、ストレージの復旧について説明します。
ストレージシステム内のLUNグループに残っているインスタンスのボリューム情報を削除する手順を説明します。
4.2.4.2.1 業務サーバ(コンピュートノード)上での作業
移動したインスタンスに接続されているボリュームのETERNUS上での登録名と業務サーバ(コンピュートノード)のWWNを調査します。
調査の流れ、および操作手順は、以下のとおりです。
調査の流れ
1.
evacuated_list.logから移動したインスタンスの情報を確認2.
インスタンスにアタッチされているボリューム情報を確認3.
インスタンスにアタッチされているボリュームのETERNUS上の登録名を確認4.
業務サーバ(コンピュートノード)のWWN情報を確認操作手順
1.
待機ノードにroot権限でログインします。2.
evacuated_list.logから移動したインスタンスのuuidを確認します。以下のコマンドを実行します。
# cat /var/opt/FJSVpf4c/logs/evacuated_list.log <RETURN>
20160701-14:04:15 Success c70368a4-66f2-4041-8b94-f1186d231ab0 compute1 compute4 20160701-14:04:16 Success a3038c12-fa9c-495d-9351-5c3b0ddc019b compute1 compute4 20160701-14:04:18 Success dcdb4fd4-643c-4ba6-a54c-e5aa4c502560 compute1 compute4
以降の手順では、削除対象のボリュームを持つインスタンスのuuidがc70368a4-66f2-4041-8b94-f1186d231ab0だった場合を説 明します。
3.
管理サーバ(コントローラーVM2)にroot権限でログインします。4.
移動したインスタンスのボリュームの情報を取得します。以下のコマンドを実行します。
# . /root/openrc <RETURN>
# cinder list --all | grep c70368a4-66f2-4041-8b94-f1186d231ab0 <RETURN>
+---+---+---+
| ID | 略 | Attached to | +---+---+---+
| fe8d93eb-c1f9-4cb9-a787-b3ea22d7d55f | 略 | c70368a4-66f2-4041-8b94-f1186d231ab0 | +---+---+---+
| 略 | +---+---+---+
5.
ボリュームの詳細情報を確認します以下のコマンドを実行し、コマンドの実行結果のFJ_Volume_Nameを控えておきます。
# cinder show fe8d93eb-c1f9-4cb9-a787-b3ea22d7d55f |grep -w metadata <RETURN>
| metadata | { u'FJ_Volume_Name': u'FJosv_2QbyOnrOm2Ce_h7lQ9HlNg==', (略) } |
6.
故障した業務サーバ(コンピュートノード)以外のすべての業務サーバ(コンピュートノード)にroot権限でログインします。7.
業務サーバ(コンピュートノード)のWWN情報を取得します。以下のコマンドを実行し、コマンドの実行結果を業務サーバ(コンピュートノード)のWWNとして控えておきます。
# systool -c fc_host -A port_name | awk '/ port_name / {print $3}' | cut -c4-19 <RETURN>
10000000c9d5eb68 10000000c9d5eb69
注意
cinderコマンドを実行した際、以下のようなメッセージが数行表示されますが問題ありません。
WARNING:keystoneclient.auth.identity.base:Failed to contact the endpoint at http://管理サーバ(コントローラーVM1)のサービスLAN のIPアドレス:8776/v2/462f0910891f467e9a7de796cbcf7420 for discovery. Fallback to using that endpoint as the base url.
4.2.4.2.2 ETERNUS 上の作業
「4.2.4.2.1 業務サーバ(コンピュートノード)上での作業」で確認したボリュームが登録されているLUNグループから、不要なボリューム の"ホストLUNとボリュームNo.の割り当て情報"を削除します。
1.
ETERNUS Web GUIにログインします。2.
[ 接続性 ]ナビの"ホストグループ" の"FC/FCoE"から以下の条件を満たすホストグループを検索し、名前を記録します。－
"HOST_NAME#XX"という名前 (XXは整数) かつ－
「4.2.4.2.1 業務サーバ(コンピュートノード)上での作業」の手順7.で記録したWWNと一致しないWWNである3.
[ 接続性 ]ナビから手順2. のホストグループに接続されているLUNグループを確認します。4.
[ 接続性 ]ナビの"LUNグループ"で、手順3.のLUNグループを選択します。5.
"LUNグループ変更"で、不要なボリュームの"ホストLUNとボリュームNo.の割り当て情報"を削除します。詳細は、「ETERNUS Web GUI ユーザーズガイド(設定編)」を参照してください。
注意
LUNグループ内のすべてのボリュームが不要な場合は、LUNグループの属するホストアフィニティを削除してからLUNグループを削 除してください。
4.2.4.3 OS 再起動による業務サーバ ( コンピュートノード ) の復旧
異常の発生した業務サーバ(コンピュートノード)を再起動した際、OSが起動した場合の復旧手順を説明します。
以下の手順にしたがって、業務サーバ(コンピュートノード)が正常に動作していることを確認してください。
業務サーバ(コンピュートノード)のサービスの確認
1.
異常が発生した業務サーバ（コンピュートノード)にroot権限でログインします。2.
異常が発生した業務サーバ（コンピュートノード)のサービスが起動していることを確認します。以下のコマンドを実行します。コマンドの詳細は、「2.3.3 rcx_service」を参照してください。
# /opt/FJSVpf4c/bin/rcx_service status <RETURN>
3.
異常が発生した業務サーバ（コンピュートノード)のサービスが起動していない場合には、サービスを起動します。以下のコマンドを実行します。
# /opt/FJSVpf4c/bin/rcx_service start <RETURN>
Faulted状態のクリア
OSが正常に起動したあと、PRIMECLUSTERのuserApplicationの状態を確認し、Faulted状態となっている場合には状態をクリアしま す。
1.
異常が発生した業務サーバ（コンピュートノード)にroot権限でログインします。2.
以下のコマンドを実行し、userApplicationの状態を確認します。userAppのStateが"Faulted"であることを確認します。
コマンドの実行結果の赤文字、かつ下線部がuserAppのStateを示しています。
# hvdisp -T userApplication <RETURN>
Local System: compute1RMS
Configuration: /opt/SMAW/SMAWRrms/build/config.us
Resource Type HostName State StateDetails ---leaderapp userApp Faulted
3.
Faulted状態をクリアします。手順2.で"Faulted"が表示された場合は、Faulted状態をクリアします。
a.
以下のコマンドを実行し、userAppのFaulted状態をクリアします。# hvutil -c leaderapp <RETURN>
b.
以下のコマンドを実行し、userApplicationの状態を確認します。userAppのStateが"Offline"であることを確認します。
コマンドの実行結果の赤文字、かつ下線部がuserAppのStateを示しています。
# hvdisp -T userApplication <RETURN>
Local System: compute1RMS
Configuration: /opt/SMAW/SMAWRrms/build/config.us
Resource Type HostName State StateDetails ---app1 userApp Offline
userAppのStateが"Faulted"から変化しない場合、当社技術員に連絡してください。
稼動ノードで異常が発生した場合
マルチパスデバイス情報の更新1.
復旧した業務サーバ(コンピュートノード)にroot権限でログインします。2.
以下のコマンドを実行し、マルチパスデバイス情報を更新します。# multipath -F <RETURN>
注意
以下のようなメッセージが表示される場合がありますが、問題ありません。
Aug 02 15:39:00 | 3600000e00d11000000110072001b0000: map in use
Aug 02 15:39:00 | failed to remove multipath map 3600000e00d11000000110072001b0000
# multipath -v2 <RETURN>
注意
以下のようなメッセージが表示される場合がありますが、問題ありません。
Aug 02 15:41:31 | 360030057023cffa01f1684c828b6202f: ignoring map create: 3600000e00d11000000110072002c0000 undef FUJITSU ,ETERNUS_DXL size=20G features='0' hwhandler='0' wp=undef
|-+- policy='round-robin 0' prio=50 status=undef
| `- 5:0:0:24 sdc 8:32 undef ready running
`-+- policy='round-robin 0' prio=10 status=undef `- 12:0:0:24 sde 8:64 undef ready running
復旧した業務サーバ(コンピュートノード)を代表ノードに設定
1.
復旧した業務サーバ(コンピュートノード)にroot権限でログインします。2.
以下のコマンドを実行し、UserApplicationを起動します。# hvswitch leaderapp compute1RMS <RETURN>
Novaのサービスを"enabled"に変更