RMS の使用中に発生する問題の解決方法について説明します。
以下の現象が発生した場合は、該当する問題の対処方法を試してください。
RMS で異常が発生した場合、トラブルシューティングのための情報を含んだエラーメッセージが出力されます。メッセージの内容を確認し、その内容に従った対処を行ってください。
■トラブル一覧
No. | 現象 | Solaris | Linux |
|---|---|---|---|
ユーザアプリケーションを削除したにもかかわらず、削除前の情報が表示される | ○ | ○ | |
RMS 起動時に毎回ファイルシステムの fsck が行われる | ○ | － | |
RMS が起動後にハングする ( プロセスは実行中だが、hvdisp がハングする) | ○ | ○ | |
RMS が起動直後にループする ( 停止する場合もある) | ○ | ○ | |
RMS が他ノードの障害を検出しても、そのノードが強制停止されない | ○ | ○ | |
hvcm コマンドを使用してRMS を起動した場合に、クラスタアプリケーションに登録しているアプリケーションの機能がパーミッションエラーとなる | ○ | ○ | |
RMS のログ格納ディレクトリ (/var/opt/SMAWRrms/log) に格納されている RMS ログファイルが削除される | ○ | ○ | |
RMS 間のハートビートが切断されてから、相手ノードを強制停止するまでの時間を変更したい | ○ | ○ | |
RMS を起動させると、RMS(BM, 82) のメッセージが出力され RMS が停止し、他ノードより強制停止 (panic/sendbreak/reset) される | ○ | ○ | |
運用中に以下のメッセージが表示され、ノードがパニックした | ○ | ○ | |
RMS を起動すると、RMS (WRP, 34) のメッセージが表示されてハートビートが切断し、ノードが強制停止 (panic/sendbreak/reset) される | ○ | ○ | |
スケーラブル運用のクラスタアプリケーションの状態が Wait 後、Faulted となる | ○ | ○ | |
スケーラブル運用のクラスタアプリケーションが複数ノードで Online になる | ○ | ○ | |
hvshut コマンドを実行すると、以下のエラーメッセージが出力された | ○ | ○ | |
hvipalias ファイルに定義されていない IP アドレスが引継ぎIPアドレスとして活性化された | ○ | － | |
RMS 停止処理時に、RMS でタイムアウトが発生し、Offline 処理が行われなかった | ○ | ○ | |
RMS を起動すると以下のメッセージが出力され、RMS の起動に失敗する | ○ | ○ | |
"hvswitch -f" コマンドを実行した際に、"Command aborted" のメッセージが出力される | ○ | ○ | |
運用中に RMS(WRP,34)、(WRP,35) のメッセージが表示される | ○ | ○ | |
RMS の停止を行うとノードがパニックした | ○ | ○ | |
PRIMECLUSTER 起動時に RMS の起動に失敗し、Cluster Admin の msg タブに以下が出力される | ○ | ○ | |
ノードを停止すると以下のメッセージが表示された | ○ | ○ | |
RMS が起動されない | ○ | ○ | |
運用中以下のメッセージが表示され、ノードが強制停止された | ○ | ○ | |
運用中以下のメッセージが表示され、クラスタノードが Online から Offline に遷移した | ○ | ○ | |
RMSを起動すると以下のメッセージが出力される | ○ | － | |
RMS の停止処理中にシステムが異常停止しても、業務が待機系に切り替わらない | ○ | ○ | |
以下の条件の時、他ノードから強制停止のアクションが実行される 出力されるメッセージ: | ○ | ○ | |
MAC アドレス引継ぎを設定したリソースが定義されている userApplication を起動すると、引継ぎネットワークリソースの活性化に失敗する。MAC アドレスの設定を表記しないと、正常に引継ぎネットワークリソースを活性化できる | ○ | － | |
Cmdline リソースが Online 状態にもかかわらず Start スクリプトが実行され、Cmdline リソースから呼ばれるアプリケーションが二重起動される | ○ | ○ | |
Fsystem リソースに異常が発生し、フェイルオーバが発生する | ○ | ○ | |
RMS 起動時に以下のメッセージが出力される | ○ | ○ | |
hvswitch コマンドを実行しても、userApplication の切替えができない | ○ | ○ | |
PRIMECLUSTER 動作中、/var 領域が 100% になった | ○ | ○ | |
userApplication の切替えを行うとパトロール診断リソースが Fault になる | ○ | － | |
userApplication の排他設定が行われているにもかかわらず、同一ノードで優先度の高い userApplication と優先度の低い userApplication が Standby -Online 状態で混在する | ○ | ○ | |
手動切替時、自ノードの userApplication の Offline 処理が完了する前に、相手ノードが停止した。このため自ノードで再度userApplication が Onlineになることを期待したが、自動的に Online にならなかった | ○ | ○ | |
hvshut コマンドがハングし、RMS が停止しない | ○ | ○ | |
OS のシャットダウン処理がハングした | ○ | ○ | |
クラスタアプリケーションの強制起動 (hvswitch -f) を実行し、確認メッセージに yes と応答したにもかかわらず、以下のメッセージが出力され、クラスタアプリケーションが強制起動されなかった【Solaris版 PRIMECLUSTER 4.3A10以降、またはLinux版 PRIMECLUSTER 4.3A30以降】 | ○ | ○ | |
クラスタアプリケーションの強制起動(hvswitch -f)を実行し、確認メッセージにyesと応答したにもかかわらず、以下のメッセージが出力され、クラスタアプリケーションが強制起動されなかった【Solaris版 PRIMECLUSTER 4.3A10以降、またはLinux版 PRIMECLUSTER 4.3A30以降】 ERROR: Forcibly switch request denied, the following node(s) are in LEFTCLUSTER state: nodes | ○ | ○ | |
ノングローバルゾーン内の RMS を起動したところ、以下のメッセージが表示された RMSWT TouchOnlineFile_XXXXXXX_1: WARNING: PC_GETPARMS fails, set system default class name to TS | ○ | － | |
userApplication が Offline 状態に遷移した直後に、同じ userApplication に対して hvswitch コマンドを実行したが、userApplication が起動しない | ○ | ○ | |
userApplication が Offline 状態に遷移した直後に、同じ userApplication に対して hvutil -m/-M on コマンドを実行したが、保守モードが開始されない | ○ | ○ | |
Fsystem リソースを含む userApplication や RMS を停止すると、コンソールがハングアップする | ○ | ○ | |
userApplication の自動切替えが発生したが、切替え先ですべてのリソースがOnlineにならない 【PRIMECLUSTER 4.3A40 以降】 | ○ | ○ | |
スケーラブルコントローラが Faulted になった場合に、スケーラブルコントローラを含むクラスタアプリケーションの状態が Online となる | － | ○ | |
非レガシー ZFS ファイルシステムがマウントされたディレクトリに対して unshare コマンドを実行したところ、Fsystem リソースが Online 状態にならなくなった | ○ | － | |
非レガシー ZFS ファイルシステムがマウントされているデータセットに対して zfs set -c コマンドを実行し、ZFS 共有を削除したところ、Fsystem リソースが Online 状態にならなくなった | ○ | － | |
保守モードを終了できない | ○ | ○ | |
userApplication の切替え時に、(UAP, 2)のメッセージがsyslogやswitchlogに出力される | ○ | ○ | |
Followコントローラを含むクラスタアプリケーション配下のリソースが保守モード開始直前の状態に戻っているにも関わらず、以下が表示されたままとなる | ○ | ○ | |
hvdisp コマンドの表示結果に一部のリソースのみ表示された | ○ | ○ | |
Azure 環境で、クライアントから運用ノードに対し、引継ぎ IP アドレスによる通信ができない | － | ○ | |
AWS 環境で、クライアントから運用ノードに対し、引継ぎ IP アドレスによる通信ができない | － | ○ |
ユーザアプリケーションに登録されていないリソースが存在する場合、RMS は動作できません。
このため、ユーザアプリケーションのみ削除し、ユーザアプリケーションに登録されていないリソースがある場合、削除前の構成情報が表示されます。
userApplication Configuration Wizard で作成したすべてのリソースをユーザアプリケーションに登録してください。
使用しないリソースは削除してください。
上記対処を行った後、userApplication Configuration Wizard 画面左の config のアイコンの背景が白色になっていることを確認してください。
クラスタアプリケーションに含まれるファイルシステムリソースをネットワークで共有 (NFS) する場合は、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)" の"Fsystemリソースの作成" の "事前設定" の "■ファイルシステムをネットワークで共有 (NFS) する場合の準備" に従い、事前設定してください。
すべてのクラスタノード上で cftool -n を実行し、ローカルノードの状態が LEFTCLUSTER 状態となっているか確認してください。
LEFTCLUSTER 状態となっている場合は、ローカルノードで cftool -k を実行し、LEFTCLUSTER 状態をクリアしてください。ノードがクラスタに参入したあとも、RMS は稼動し続けます。RMS を再起動する必要はありません
CIP 構成定義ファイル（/etc/cip.cf）にネットマスクのエントリが含まれている可能性があります。
RMS では、ネットマスクのエントリがあると、ネットマスクを IP アドレスと判断してホスト名を検索する処理を行うため処理が停止します。
ネットマスクのエントリが /etc/cip.cf に存在することを調べてください。
ネットマスクのエントリを削除して、RMS を再起動してください。
SysNode が Wait 状態の場合に、この問題が発生します。
cftool -n を使用して CF の状態を確認してください。
CF の状態が LEFTCLUSTER の場合、LEFTCLUSTER のノードを手動で停止した後、cftool -k を使用して LEFTCLUSTER を解消してください。
CF の状態が DOWN となっていることを確認したら、hvdisp -T SysNode を使用してすべての SysNode オブジェクトの状態を確認してください。
SysNode が Wait 状態の場合、hvutil -u SysNode を実行してください。
注意
cftool -k コマンド、および hvutil -u コマンドを使用する場合は、必ず Wait 状態のノードを手動で停止してから実行してください。本コマンドを実行すると、アプリケーションの切替え(フェイルオーバ)が行われるため、Wait 状態のノードを停止せずに本コマンドを実行した場合、データが破損する可能性があります。
hvcm コマンドを使用して RMS を起動すると、クラスタが起動するプロセスの実グループID と実効グループ ID は 1(other) になります。よって、起動するクラスタサービスの実効グループID が 0(root) でなければならない場合は、hvcm(1M) コマンドで RMS を起動する際に、スーパーユーザ権限で、以下を実行して実効グループを変更してください。
# newgrp root # /opt/SMAW/bin/hvcm hvcm(1M)コマンドのオプション # newgrp |
hvcm(1M) コマンドのオプション：hvcm(1M) コマンドに指定するオプションを指定します。
hvcm(1M) コマンドのオプションの指定方法については、hvcm(1M) コマンドのオンラインマニュアルを参照してください。
InterAPLINK を使用している場合は、グループ ID が 0(root) でなければならないため RMS の起動を Cluster Admin GUI から行うか、上記方法で hvcm コマンドを実行してください。
RMS ログファイルは、RMS の環境変数 HV_LOG_ACTION、HV_LOG_ACTION_THRESHOLD、HV_LOG_WARN_THRESHOLD、RELIANT_LOG_LIFE の設定内容に従って、保持日数、サイズがチェックされ、古いログは自動的に削除されます。
RMS の環境変数 HV_LOG_ACTION、HV_LOG_ACTION_THRESHOLD、HV_LOG_WARN_THRESHOLD、RELIANT_LOG_LIFE の設定内容を確認し、運用に合わせて変更してください。
RMS を起動する hvcm コマンドにおいて、-h オプションと変更したい時間(秒)を指定して実行することで変更できます。なお、本オプションを指定しない場合のデフォルトは 45 秒です。
例）相手ノードを強制停止するまでの時間を 100 秒に変更する場合
# hvcm -c config -h 100 -a <Return>なお、本オプションを指定しない場合のデフォルトはバージョンにより異なり、以下のとおりです。
4.0Axx, 4.1Axx の場合: 45 秒
4.2A00 以降の場合 : 600 秒
クラスタインタコネクトを使用したノード間の通信ができていません。その原因として、OS 起動時に、クラスタインタコネクトが使用する NIC が、half-duplex で起動している可能性があります。
ノード間の通信が確実に行われるようにしてください。
Switching Hub の Port の設定、またはノードの NIC の negotiation の設定を見直してください。
その後、ローカルの RMS モニタを再起動してください。
RMS のハートビートが切れたため相手ノードを強制停止したと考えられます。
RMS ではハートビート切れを検出すると、45 秒間ハートビートの復旧を待ちますが、45 秒間経過しても、復旧しなかった場合、相手ノードを強制停止します。
システムの負荷など、ハートビート切れとなる要因が発生していないか確認し、その原因の対処を行ってください。
RMS のハートビート監視時間を変更したい場合は、RMS を起動する際、-hオプションで監視時間を指定してください。
なお、ハートビートの復旧を待つ時間のデフォルト値はバージョンにより、以下のとおり異なります。
4.0Axx, 4.1Axx の場合: 45 秒
4.2A00 以降の場合 : 600 秒
クラスタインタコネクトを使用したノード間の通信ができていません。
ノード間通信が失敗した原因として、RMS(WRP, 39) のメッセージが表示されている場合は、メモリ不足などの I/O 負荷やシステム負荷が発生している可能性があります。
I/O 負荷やシステム負荷がないか確認し、負荷を取り除いてください。
また、/tmp の空き領域が少ない場合、メモリ不足が発生したり、RMS がエラーとなりますので、/tmp の使用状況を確認し、/tmp の領域を空けてください。
排他関係を設定したスタンバイ運用で構成するスケーラブル運用のクラスタアプリケーションにおいて、スケーラブル運用のクラスタアプリケーションの状態が Wait 後、Faulted となる場合があります。
以下の条件の場合、スケーラブル運用のクラスタアプリケーションの状態が Wait 後、Faulted となります。
排他関係を設定したスタンバイ運用で構成するスケーラブル運用のクラスタアプリケーションが存在している。かつ、
ノード異常やリソース故障などの要因により、1 つ以上のスタンバイ運用のクラスタアプリケーションの運用となれるノードが存在しない。
例）
ノード 1 とノード 2 で異常が発生し、スタンバイ運用のクラスタアプリケーション 2 で運用となれるノードが存在しないため、スケーラブル運用のクラスタアプリケーションが Wait 後、Faulted となります。
"説明" に記載した条件にあてはまる場合、すべてのスタンバイ運用のクラスタアプリケーションが運用状態になるまでの間、スケーラブル運用のクラスタアプリケーションの状態は Wait となり、タイムアウト時間が経過すると Faulted となります。
タイムアウト時間はスケーラブル運用のクラスタアプリケーションの ScriptTimeout 属性値です。
スケーラブル運用のクラスタアプリケーションが Faulted となった後にスケーラブル運用のクラスタアプリケーションの Faulted をクリアしてください。
例)
# hvutil -c スケーラブル運用のuserApplication名
また、ノード異常やリソース故障を解消した後、スタンバイ運用のクラスタアプリケーションが Online となるように切替えを行ってください。"説明" に記載した例の場合、ノード 1 またはノード 2 の異常を解消し、起動した後、スタンバイ運用のクラスタアプリケーション2をノード1またはノード 2 が Online となるよう切替えを行ってください。
例)
# hvswitch スタンバイ運用のuserApplication名 ノード1のSysNode名
スケーラブル運用のクラスタアプリケーションが Online となっているノードがパニックなどの要因で異常停止後の再起動時において、OS 起動中に hvcm コマンドの実行または ClusterAdmin で RMS を起動した場合に発生します。
OS 起動中に RMS を起動してしまった場合には、RMSを起動してしまったノードで Online となっているスケーラブル運用のクラスタアプリケーションを Offline に切り替えてください。
例)
# hvutil -f RMSを起動したOnlineとなっているスケーラブルのuserApplication名
また、RMS の起動は OS 起動完了(通常運用している OS ランレベルの最後の起動スクリプトの実行が完了)を管理者が確認したあとに実施することで回避できます。
なお、hvshut コマンドを -l/-s/-a のいずれかのオプションで実行した場合、クラスタアプリケーションに含まれるリソースの一部が停止に失敗した可能性があります。
hvshut コマンドをタイムアウトさせないようにするためには、使用している環境にあわせてRMS グローバル環境変数 RELIANT_SHUT_MIN_WAIT を大きい値に変更してください。
参照
RELIANT_SHUT_MIN_WAIT の詳細については、以下のマニュアルの“グローバル環境変数”の“RELIANT_SHUT_MIN_WAIT”を参照してください。
PRIMECLUSTER 4.3A30 以降 :“PRIMECLUSTER RMS 導入運用手引書”
PRIMECLUSTER 4.3A20 以前 :“PRIMECLUSTER 活用ガイド＜クラスタ構築・運用時の留意点＞”
RMS 環境変数の参照/変更方法については、“PRIMECLUSTER RMS 導入運用手引書”を参照してください。
また、hvshut コマンドを実行した際のオプションに応じて、以下の対処を行ってください。
コマンド実行ノードの OS をシャットダウンするか、ノードを強制停止してください。
コマンド対象ノードの OS をシャットダウンするか、ノードを強制停止してください。
RMS が正常終了したノード以外の全ノードの OS をシャットダウンするか、ノードを強制停止してください。
コマンド実行ノードの BM（ベースモニタ）プロセスが停止していない場合は、hvshut -f コマンドを実行し、RMS を強制停止してください。BM プロセスが停止している場合は、対処は必要ありません。
BM プロセスが停止していないノードが存在する場合は、それらのノードで hvshut -f コマンドを実行し、RMS を強制停止してください。すべてのノードで BM プロセスが停止している場合、対処は必要ありません。
引継ぎ IP アドレスを定義するためのファイルである、/etc/hosts が /etc/inet/hosts に正常にシンボリックリンクが張られていないことが原因です。
シンボリックリンクを張り直してください。
RMS の停止処理は、クラスタアプリケーションの Offline 処理が実行途中であっても、RMS グローバル環境変数 RELIANT_SHUT_MIN_WAIT の設定値に従ってタイムアウトします。
hvshut コマンドをタイムアウトさせないようにするためには、使用している環境にあわせてRELIANT_SHUT_MIN_WAIT を大きい値に変更してください。
参照
RELIANT_SHUT_MIN_WAIT の詳細については、以下のマニュアルの“グローバル環境変数”の“RELIANT_SHUT_MIN_WAIT”を参照してください。
PRIMECLUSTER 4.3A30 以降 :“PRIMECLUSTER RMS 導入運用手引書”
PRIMECLUSTER 4.3A20 以前 :“PRIMECLUSTER 活用ガイド＜クラスタ構築・運用時の留意点＞”
RMS 環境変数の参照/変更方法については、“PRIMECLUSTER RMS 導入運用手引書”を参照してください。
クラスタアプリケーションに登録されてないリソースが残っている可能性があります。
または、クラスタアプリケーションを作成していない可能性があります。
必要に応じて、該当するリソースをクラスタアプリケーションに登録するか、リソースを削除してください。
または、クラスタアプリケーションを作成してください。クラスタアプリケーションの概要と作成方法については、"PRIMECLUSTER 導入運用手引書" を参照してください。
"hvswitch -f" コマンドを実行後の応答メッセージに対して、オペレータの入力誤りがあったと考えられます。
"Do you wish to proceed ? (default: no) [yes, no]: "のメッセージが出力後、正しい入力を行ってください。
NTP サーバとネットワーク接続されていない可能性があります。
NTP サーバとネットワーク接続してください。また、NTP の設定が正しく行われているか確認してください。
クラスタアプリケーションの HaltFlag 属性を有効に設定した環境で、リソースの異常によるダブルフォルト（二重故障）が発生した場合、RMS が停止処理中でも、ノードが強制停止（パニックなど）される場合があります。
注意
hvshut -a コマンドなどですべてのノードの RMS が停止処理中でも、他のノードで RMS が停止する前であれば、ダブルフォルトが発生したノードは強制停止されます。
ダブルフォルトのエラーメッセージが出力されていないかを、switchlog ($RELIANT_LOG_PATH/switchlog) で確認してください。
ダブルフォルトが発生していた場合は、その原因となったリソースの異常について調査し、正常に動作するように対処してください。
クラスタインタコネクトで使用しているインタフェースにおいて、OS 起動時に IP アドレスを活性化する設定がされている場合、CF の起動に時間がかかり、RMS やクラスタリソース管理機構が正常に動作できないことがあります。
クラスタインタコネクトで使用しているインタフェースにおいて、OS 起動時に IP アドレスを活性化しないように、OS の設定を変更してください。
RMS を停止しないで、ノードを shutdown させた場合、RMS の停止処理を実行する旨のメッセージが出力されます。
対処は不要です。ノードを停止する場合は、事前に RMS を停止させてください。
リソース作成後、クラスタアプリケーションを作成していない可能性があります。
あるいは、userApplication に登録していないリソースが存在する可能性があります。
クラスタアプリケーションを作成してください。
あるいは、userApplication に登録していないリソースがある場合は、登録してください。リソースを RMS で使用しない場合は、削除してください。
【Solaris 版 4.3A10以降】
RMS の SMF サービス(svc:/milestone/smawrrms)の状態が online または degraded ではありません。
PRIMECLUSTER のサービスは SMF により管理されるため、RMS の SMF サービスの状態が online または degraded の場合のみ、そのノードの RMS は起動できます。
RMS の SMF サービスの状態が online または degraded でない原因を取り除いた後、サービスの状態が online または degraded になったことを確認してください。それでも復旧できない場合は、調査資料を採取した後、当社技術員(SE)に連絡してください。
RMS の環境変数 HV_RCSTART が 0 に設定されている可能性があります。
OS 起動時に RMS を自動起動する場合は、RMS の環境変数 HV_RCSTART を1に設定してください。
HV_RCSTART については、“PRIMECLUSTER RMS 導入運用手引書”を参照してください。
【Linux版 4.3A40 以降】
RMS の systemd サービス(smawrrms.service)の状態が active ではありません。
PRIMECLUSTER のサービスは systemd により管理されるため、RMS の systemd サービスの状態が active の場合のみ、そのノードの RMS は起動できます。
RMS の systemd サービスの状態が active でない原因を取り除いた後、systemctl コマンドによりサービスを起動して、サービスの状態が active になったことを確認してください。それでも復旧できない場合は、調査資料を採取した後、当社技術員(SE)に連絡してください。
RMS 間のハートビートが途切れ、<time> 秒以上たっても応答がないため、相手ノードを強制停止したと考えられます。
以下の要因が考えられます。要因に従って対処を行ってください。
クラスタインタコネクトがハード故障により通信ができない。
LAN カード交換、ケーブル交換などを行い、ハード故障の要因を取り除いてください。
RMS がハートビート処理できないほど、システムの CPU 負荷が長時間発生している。
<SysNode> のホストが高負荷となっている処理を見直してください。
クラスタホスト <hostname> で異常が発生したか、<hostname> が高負荷状態で 3 秒以上ハートビートをやり取りできないことが考えられます。
強制停止が実行される前に表示される警告です。頻繁に出力されてもノードが強制停止されない場合は、ノード間通信や業務負荷が高いと考えられます。システムの状態を調査分析し、問題を取り除いてください。
注意
SYS,88 が定期的に発生する場合はその時刻に cron などの自動的な処理により CPU に負荷がかかっている可能性があります。
sar コマンドなどで CPU の負荷を調べた上、CPU 負荷の原因を取り除いてください。
例えば以下の手順のように CPU 負荷の原因を調査してください。
switchlog に SYS, 88 が検出されている時刻を調べます。
#grep "SYS, 88" /var/opt/SMAWRrms/log/switchlog を実行。SYS, 88 は以下のように表示されます。
下記の例の場合、13 時に発生し、その後 1 時間おきに表示されています。
2005-11-17 13:00:00.000:(SYS, 88): WARNING: No heartbeat from cluster host fuji2RMS within the last 10 seconds. This may be a temporary problem caused by high system load. RMS will react if this problem persists for 35 seconds more. :==== 2005-11-17 14:00:00.000:(SYS, 88): WARNING: No heartbeat from cluster host fuji2RMS within the last 10 seconds. This may be a temporary problem caused by high system load. RMS will react if this problem persists for 35 seconds more. :==== 2005-11-17 15:00:00.000:(SYS, 88): WARNING: No heartbeat from cluster host fuji2RMS within the last 10 seconds. This may be a temporary problem caused by high system load. RMS will react if this problem persists for 35 seconds more. :====
SYS, 88 が 00 分に発生し、1 時間ごとに出力されています。1 時間ごとに起動される処理が本システムで動作している可能性があります。
手順 1.で特定した時刻で #sar -u <時間> <回数> を実行し、CPU 使用率を調べます。
00 分で1時間ごとに起動される処理があると考えられるので、00 分前後（下記例の場合は10 時）の CPU 使用率を調べます。（Solaris,Linux 共通）
例）Solaris の場合
# sar -u 1 5 09:59:56 %usr %sys %wio %idle
09:59:57 5 2 1 93
09:59:58 5 2 1 92
09:59:59 5 3 13 80
10:00:00 5 3 34 57
10:00:01 5 2 1 92
Average 5 2 10 83例）Linux の場合
# sar -u 1 5 09:59:56 AM CPU %user %nice %system %idle
09:59:57 AM all 5.00 2.00 1.00 93.00
09:59:58 AM all 5.00 2.00 1.00 92.00
09:59:59 AM all 5.00 3.00 13.00 80.00
10:00:00 AM all 5.00 3.00 34.00 57.00
10:00:01 AM all 5.00 2.00 1.00 92.00
Average: all 5.00 2.40 10.00 82.80CPU 使用率が SYS, 88 が表示されなかった時刻と比べて著しく高かった場合、その時間の処理が CPU 負荷の原因と考えられます。
この場合、10:00:00 の wio (Solaris の場合)、system (Linux の場合) の CPU 使用率が高いので、この時間の処理が CPU 負荷の原因と考えます。
userApplication Configuration Wizard で Symfoware Server(Native) のスケーラブルアプリケーションを作成する時、Symfoware より上位の階層に 2 つ以上のリソースが存在すると、userApplication Configuration Wizard が作成するファイルの値に誤りがあることがあります。このため、userApplication 起動時に (SCR, 25) のメッセージが出力されます。
メッセージが出力されるだけで動作に影響ありませんが、userApplication Configuration Wizard で作成した設定ファイルに誤りがあります。
以下の手順で変更してください。
すべてのクラスタノードで RMS を停止します。
すべてのクラスタノードで /opt/FJSVclsfw/etc/RDBnet/ 配下でリソース名が重複定義されたファイルを編集します。
例：DB_Symfo ファイルにリソース名 ("symfoDB") が重複定義されている場合"symfoDB.symfoDB" を 1 つにします。
[修正前]
SFW_RDBSYSLIST=nodeARMS:DB_Symfo:symfoDB.symfoDB
nodeBRMS:DB_Symfo:symfoDB.symfoDB (1 行で設定されています）
[修正後]
SFW_RDBSYSLIST=nodeARMS:DB_Symfo:symfoDB nodeBRMS:DB_Symfo:symfoDB
すべてのノードの /opt/FJSVclsfw/etc/RDBnet/ 配下のファイルについて、同様にリソース名の重複設定が行われていないか確認し、重複定義されているものについては修正を行ってください。
すべてのノードの RMS を起動します。
以下の条件の時、PRIMECLUSTER の仕様により業務は待機系に切り替わりません。
PRIMECLUSTER 4.0Axxを使用しており、かつ、
運用ノードで shutdown や RMS の hvshut コマンドを実行し、かつ、
RMS の停止処理が完了する前に halt コマンドなどが実行されてシステムが異常停止した場合
PRIMECLUSTER 4.1Axx以降では上記と同一条件のもと、業務が待機系に切り替わるように仕様改善されています。
運用ノードの RMS 停止操作を行う前に、業務を待機系に切り替えてください。
以下の条件の時、PRIMECLUSTER の仕様により業務は待機系に切り替わりません。
PRIMECLUSTER 4.0Axxを使用しており、かつ、
運用ノードで shutdown や RMS の hvshut コマンドを実行し、かつ、
RMS の停止処理が完了する前に halt コマンドなどが実行されてシステムが異常停止した場合
PRIMECLUSTER 4.1Axx以降では上記と同一条件のもと、業務が待機系に切り替わるように仕様改善されています。
運用ノードの RMS 停止操作を行う前に、業務を待機系に切り替えてください。
/opt/SMAW/SMAWRrms/etc/hvipalias ファイルの MAC アドレスの指定が規定のフォーマットに従っていない場合に本現象が発生する場合があります。MAC アドレスは、コロン ':' で区切られたそれぞれの数値を必ず 2 桁で表記する必要があります。
以下の例の場合、* の部分において 1 となっている箇所は 01 と記載する必要があります。
(誤)
*
node01 hikitugi_ip hme0 0xffffff00 02:1:22:33:34:40
node02 hikitugi_ip hme0 0xffffff00 02:1:22:33:34:40(正)
node01 hikitugi_ip hme0 0xffffff00 02:01:12:23:34:40 node02 hikitugi_ip hme0 0xffffff00 02:01:12:23:34:40
Cmdline リソースに NULLDETECTOR フラグが設定されている場合、すでに Online状態であっても、userApplication の Online 処理が行われると Start スクリプトが実行されます。
アプリケーションの二重起動を防止する場合は、NULLDETECTOR フラグの使用をやめ、Cmdline リソースに Check スクリプトを設定してください。
Check スクリプトには、最低限以下の処理が必要です。
アプリケーションがすでに起動している場合、0 (Online) を返す。
上記以外の場合、1 (Online 以外) を返す。
Fsystem リソースの活性化時にファイルシステムのマウントが失敗し、かつ、マウント再施行の前処理として実施した fsck の実行時にタイムアウトが発生した可能性があります。
環境によって fsck が完了するまでに必要な時間が異なります。
その環境に合った fsck が完了するまでに必要な時間を見積もり、Fsystem リソースの Timeout の設定値の見直しをしてください。
設定の変更方法については“PRIMECLUSTER 導入運用手引書 (Oracle Solaris)”、または、“PRIMECLUSTER 導入運用手引書 (Linux)”を参照してください。
リソースの活性化による userApplication の初期化に時間が掛かっている可能性があります。
その後、以下のメッセージが確認できればクラスタシステムとしては問題はないので対処は不要です。
(US, 16): NOTICE: Online processing finished!
(US, 9): NOTICE: Cluster host XXXXXXXXRMS has become online.
以下のすべての条件を満たす場合、hvswitch コマンドを実行しても SysNode の優先度が高いノードへ切り替えることができません。
優先度が低い userApplication が Online 状態である
userApplication の属性に OnlinePriority が設定されている
hvswitch コマンドで SysNode を指定しない場合
OnlinePriority が設定されている userApplication の切替えを行う場合は、hvswitch コマンドに SysNode 名も指定してください。
RMS 関連のログファイルの肥大化により /var 領域が 100% になったと考えられます。
RMS 関連のログファイルは、/var 領域が 98% 以上になると定期的に削除されます。
しかし、RMS から起動されたアプリケーションプログラムが標準出力と標準エラー出力に大量にログを出力した場合は、/var 領域が 100% になります。
以下の手順で RMS ログのバックアップ、削除を実施してください。
ログをバックアップする場合
/var/opt/SMAWRrms/log 配下のログを対象に cp(1) でコピーしてください。
mv(1) は使用しないでください。
ログファイルを削除する場合
削除対象のログに対して /dev/null で上書きし初期化してください。
例：cat /dev/null > /var/opt/SMAWRrms/log/userApp0.log
パトロール診断のディスク診断処理に時間がかかり、リソースの ScriptTimeout 以内に処理が完了しなかった可能性があります。
パトロール診断のリソースに設定されている ScriptTimeout を変更してください。
ScriptTimeout に設定する値は、以下の計算式で算出してください。
パトロール診断の監視対象となるデバイス(ディスク)が 300 個未満の場合は 300 秒を設定してください。
デバイスが 300 個以上の場合は "デバイス(ディスク)数 × 1秒" を設定してください。
ただし、パトロール診断の監視間隔は、この ScriptTimeout より大きな時間であることを確認してください。
userApplication の排他設定を行っている場合、同一ノードで 2つ以上の userApplication が同時に Online 状態にはなりません。
ただし優先度の高い userApplication が Standby 状態に遷移可能な設定の場合は、待機ノードで Offline ではなく Standby 状態になります。
例）以下のように、node1 で優先度高の userApp_0 と優先度低の userApp_1 が、Standby - Online 状態で混在する
| node0 | node1 |
|---|---|---|
userApp_0(優先度高) | Online | Standby |
userApp_1(優先度低) | Offline | Online |
対処は不要です。
RMS は、userApplication の Offline 処理が完了した後に、切替え先を選択します。切替え先には自ノードを含まないため、自ノード以外に切替可能なノードが生存していない場合、切替処理を行いません。
hvswitch コマンドを使用し、手動で userApplication を Online にしてください。
hvshut コマンドによってクラスタアプリケーションの停止処理を行う場合にリソースの Offline 処理がハングすると、以下のいずれかの条件を満たすまで、RMS は停止しません。
hvshut コマンドのタイムアウト時間を指定する環境変数 RELIANT_SHUT_MIN_WAIT で設定された時間（秒）が経過する。
リソースの Offline 処理がタイムアウトすることで二重故障（Double Fault）が発生する。
そのため、RELIANT_SHUT_MIN_WAIT の設定値と、リソースの Offline 処理のタイムアウト時間の設定値がいずれも長い場合にリソースの Offline 処理がハングすると、hvshut コマンドがハングしたように見えます。
hvshut -f コマンドを実行して RMS を強制停止してください。
ただし、RMS が停止しても、クラスタアプリケーションやその配下のリソースが起動状態のまま残っている可能性があります。そのため、続けて OS を再起動してください。
OS 再起動後、リソースの Offline 処理がハングした原因を取り除いてください。
また、RELIANT_SHUT_MIN_WAIT を環境に応じた適切な値に設定するか、リソースの Offline 処理のタイムアウト時間を短くするよう設定を見直してください。
OS のシャットダウン処理では、rc スクリプトにより hvshut コマンドが実行されます。
そのため、RMS およびリソースが起動した状態で OS のシャットダウンを行うと、前述の Q-3-4-39 の事象が発生する可能性があります。このとき、OS のシャットダウン処理がハングしたように見えます。
OS を手動でパニックさせるか、ノードを強制停止してください。
OS 再起動後、リソースの Offline 処理がハングした原因を取り除いてください。
また、RELIANT_SHUT_MIN_WAIT を環境に応じた適切な値に設定するか、リソースのOffline 処理のタイムアウト時間を短くするよう設定を見直してください。
クラスタアプリケーションを強制起動する際に、RMS が起動していないノードが存在していた場合、RMS はそのノードを強制停止させた後、クラスタアプリケーションの強制起動を開始します。
ノードの強制停止に失敗した場合、RMS はクラスタアプリケーションの強制起動を中止します。
<node> の OS を手動で停止してから、再度クラスタアプリケーションの強制起動を実行してください。
また、ノード強制停止が行えるよう、シャットダウン機構の設定を見直してください。
クラスタアプリケーションの強制起動を行った時に、CFがLEFTCLUSTER状態のノードが存在していた場合、RMSはクラスタアプリケーションの強制起動を中止します。
nodesのノードをすべて、以下のいずれかの状態にしてから、クラスタアプリケーションの強制起動を行ってください。
CFがDOWN状態、かつ、RMSがOffline状態
CFがUP状態、かつ、RMSがOnline状態
CFをLEFTCLUSTER状態から回復させる方法については、“PRIMECLUSTER Cluster Foundation 導入運用手引書”を参照してください。
内部リソースの監視プロセスにおいて、スケジューリングクラスを取得する処理で出力されます。動作に影響はありません。
XXXXXXX は ノングローバルゾーン内のクラスタアプリケーション名です。
対処は不要です。
userApplication が Offline 状態に遷移すると、userApplication の状態をノード間で同期する処理が実行され、同期が完了するまでに実行された hvswitch コマンドの要求は取り消されます。
この場合、以下のメッセージが switchlog に出力されます。
(SWT, 12) object is busy or locked. Switch request skipped.
コマンドの要求が取り消された場合は、再度 hvswitch コマンドを実行してください。
ポイント
userApplication が Offline 状態に遷移した後に実行される同期処理は短時間 (環境に依存しますが、通常数十ミリ秒程度) で終了するため、再度コマンドを実行することで状態遷移処理を開始できます。
userApplication が Offline 状態に遷移すると、userApplication の状態をノード間で同期する処理が実行され、同期が完了するまでに実行された hvutil -m/-M on コマンドの要求は取り消されます。
この場合、以下のメッセージが switchlog に出力されます。
(SWT, 74) Maintenance Mode request for application userApplication discarded. Reason: Application is busy or locked.
コマンドの要求が取り消された場合は、再度 hvutil -m/-M on コマンドを実行してください。
ポイント
userApplication が Offline 状態に遷移した後に実行される同期処理は短時間 (環境に依存しますが、通常数十ミリ秒程度) で終了するため、再度コマンドを実行することで状態遷移処理を開始できます。
Fsystemリソースの Offline 処理では、マウントポイント上のプロセスに SIGHUP/SIGTERM/SIGKILL が送信されるため、ユーザが使用するコンソールのカレントディレクトリが Fsystem リソース管理下のマウントポイント上に存在する場合、コンソールが停止します。これは PRIMECLUSTER の仕様です。
Fsystem リソースを含む userApplication や RMS を停止する場合、コンソールのカレントディレクトリを Fsystem リソース管理下のマウントポイント以外のディレクトリ上に移動してから実行してください。
userApplication 配下の一部のリソースのみが起動している状態では、切替え先でもリソースの起動状態が維持されます。
(参考: "RMS 導入運用手引書 4.3"の"8.3.4 リソースの起動状態の同期")
必要に応じて、userApplication配下のすべてのリソースを起動してください。
注意
userApplication配下の一部のリソースのみが起動している状態で、他のリソースが予期せずにOnlineになった場合、userApplication は Online状態のままになります (Inconsistent状態になりません) 。
この状態で、アプリケーションの自動切替えが発生した場合、予期せずに起動したリソースは切替え先でOnlineになりません。
スケーラブルコントローラに制御されるクラスタアプリケーションがすべてFaulted状態となった場合、スケーラブルコントローラの状態はWarning状態となります。
この状態でスケーラブルコントローラのScriptTimeout時間が経過しても、スケーラブルコントローラに制御されるクラスタアプリケーションがFaulted状態のままの場合、スケーラブルコントローラはFaulted状態になります。このとき、スケーラブルコントローラを含むクラスタアプリケーションの状態が Warning 状態から、元の Online状態 となる場合があります。
スケーラブルコントローラに制御されるクラスタアプリケーションの故障状態を復旧してから、スケーラブルコントローラを含むクラスタアプリケーションをOfflineにしてください。
例)
# hvutil -f <スケーラブルコントローラを含むuserApplication名>必要に応じて、スケーラブルコントローラを含むクラスタアプリケーションを起動してください。
例)
# hvswitch <スケーラブルコントローラを含むuserApplication名>非レガシー ZFS ファイルシステムがマウントされたディレクトリに対して unshare コマンドを実行した場合、非レガシー ZFS ファイルシステムのデータセットの sharenfs プロパティー または share.nfs プロパティーに on が設定されている状態であっても、OS の仕様により、非レガシー ZFS ファイルシステムの import 時に自動的に nfs として公開されません。
PRIMECLUSTER では、sharenfs プロパティー または share.nfs プロパティー が on である場合、nfs として公開される状態になるまで Fsystem リソースが、Online 状態にならないため、本事象が発生します。
unshare コマンドを誤って実行した場合は、すべてのノードの RMS を停止後、手動で 非レガシー ZFS ファイルシステムの import を実行し、unshare コマンドを実行したディレクトリに対して share コマンドを実行してください。
その後、ZFS 共有を削除し、非レガシー ZFS ファイルシステムを export してください。
非レガシー ZFS ファイルシステムがマウントされているデータセットに対して zfs set -c コマンドを実行し、ZFS 共有を削除した場合、共有を削除したデータセットの sharenfs プロパティー または share.nfs プロパティー は、on が設定されている状態になります。
PRIMECLUSTER では、sharenfs プロパティー または share.nfs プロパティー が on である場合、nfs として公開される状態になるまで Fsystem リソースが、Online 状態にならないため、本事象が発生します。
zfs set -c コマンドにより ZFS 共有を誤って削除した場合は、すべてのノードの RMS を停止後、手動で非レガシー ZFS ファイルシステムのimport を実行し、ZFS 共有を削除したいデータセット に対して sharenfs プロパティー または share.nfs プロパティーを、off に設定してください。
その後、非レガシー ZFS ファイルシステムを export してください。
いずれかのノードで、userApplication の状態が、保守モードを開始する前の状態と異なっている可能性があります。
userApplication の状態を、保守モード開始前の状態に戻してから、保守モードを終了してください。
StandbyTransitions属性にSwitchRequestを含むuserApplicationを切り替えた場合、切替え元にてStandby処理が2回実施されることがあります(userApplicationを確実にStandby状態に遷移させるため)。これらのStandby処理が競合した場合、(UAP, 2)のメッセージが出力されます。
対処は不要です。
Q3-4-52 Followコントローラを含むクラスタアプリケーション配下のリソースが保守モード開始直前の状態に戻っているにも関わらず、以下が表示されたままとなる。
CLI: hvdispコマンドの表示結果における、StateDetails列の"Online !!" または "Standby !!"
GUI: userApplicationアイコンの右隣の
Followコントローラを含むクラスタアプリケーション配下のリソースを保守モード開始直前の状態に戻してから、Followコントローラで制御されるアプリケーション配下のリソースを保守モード開始直前の状態に戻した場合、状態表示は更新されません。PRIMECLUSTER の仕様動作となります。
対処は不要です。表示は更新されませんが、そのまま保守モードを終了することができます。
RMS 起動直後に hvdisp コマンドを実行した場合、一部のリソースのみ表示される場合があります。
RMS を起動して数秒待ってから hvdisp コマンドを再実行してください。
以下の設定誤りの可能性があります。
業務 LAN サブネットのセキュリティグループの設定で、クライアントからクラスタノードへのアクセス許可がされていない。
ルートテーブルのサブネットの関連付けが正しく行われていない。
引継ぎ IP アドレスで使用する業務 LAN のネットワークインタフェースに対して、Azure 上で IP 転送を有効にしていない。
Azure ポータルから上記の設定を確認し、修正してください。
各設定の確認方法や設定手順については、Azure の公式ドキュメントを参照してください。
ルートテーブルの関連付けについては、"PRIMECLUSTER導入運用手引書＜Cloud Services 編＞"の"第5部 Azure 環境編"の"ネットワーク引継ぎの設定"を参照してください。
以下の設定誤りの可能性があります。
業務 LAN サブネットのセキュリティグループの設定で、クライアントからクラスタノードへのアクセス許可がされていない。
AWS マネジメントコンソールから上記の設定を確認し、修正してください。
各設定の確認方法や設定手順については、AWS の公式ドキュメントを参照してください。