PRIMECLUSTER の運用全般に関するトラブルシューティングについて説明します。
■トラブル一覧
No. | 現象 | Solaris | Linux |
|---|---|---|---|
RMS 起動時、クラスタアプリケーションが自動的に Online 状態にならず、Inconsistent 状態 となる | ○ | ○ | |
クラスタアプリケーションが Faulted 状態となった後、故障原因を解決し、Faulted 状態となったノードを再起動しても、クラスタアプリケーションが Faulted 状態のまま起動されない | ○ | ○ | |
NFS サーバをクラスタ化しているシステムにおいて、hvdet_ckshare プロセスが大量に動作している | ○ | － | |
クラスタアプリケーションを構成するすべてのノードを起動しても、クラスタアプリケーションが自動起動されない | ○ | ○ | |
クラスタアプリケーションにダブルフォルト（二重故障）が発生した場合に、クラスタアプリケーションがフェイルオーバしない | ○ | ○ | |
クラスタアプリケーション起動時に、一部のリソースが起動されない | ○ | ○ | |
フェイルオーバが発生すると、共用ディスクへのアクセスを行うプロセスが強制停止される | ○ | ○ | |
クラスタアプリケーションを Online へ状態遷移させたとき、Fsystem リソースで異常が発生するまた、クラスタアプリケーションを起動すると、以下の Fsystem リソースのメッセージが表示される | － | ○ | |
リソース故障が発生した後、フェイルオーバ処理に異常が発生すると強制停止が発生する | ○ | ○ | |
クラスタアプリケーションの状態遷移に失敗した後、RCI により強制停止された形跡がある | ○ | － | |
クラスタパーティション発生時にリブートが行われない | ○ | ○ | |
クラスタパーティション発生時に全ノードが同時にリブートされた | ○ | ○ | |
運用中のアプリケーションが動作するノードが突然再起動される | ○ | ○ | |
再起動後に Faulted 状態になった RMS のクラスタアプリケーションおよびリソースの故障が通知されない | ○ | ○ | |
再起動後に RMS のクラスタアプリケーションが Faulted 状態になる | ○ | ○ | |
運用ノードのリブート時間が遅い | ○ | ○ | |
RSB によるノードの強制電源断が行えない | － | ○ | |
Java 関連のコアダンプが採取される | ○ | ○ | |
4.1A20 パッチ913381-04 適用前または、4.1A30 パッチ913897-01 適用前の環境で、コンソールに XSCF を使用した PRIMEPOWER 250,450 のクラスタシステムの運用中、「FJSVcluster: エラー: DEV: 7040: コンソールへの接続ができなくなりました。」とコンソールに表示され、コンソール非同期監視が停止した。また、シャットダウンエージェント SA_xscfp.so, SA_rccu.so, SA_xscfr.so のテスト状態(Test State)が TestFailed になった | ○ | － | |
以下のメッセージが表示され、リソース故障となる | ○ | ○ | |
Scalable コントローラを使用した環境にて、クラスタアプリケーションの OnlinePriority 属性を設定しているにもかかわらず、有効にならない | ○ | ○ | |
運用中に以下のメッセージが出力される | ○ | ○ | |
userApplication の起動および切替えができない | ○ | ○ | |
引継ぎネットワークリソースを作成し、業務 LAN に引継ぎ IP アドレスを 設定した環境で、業務 LAN ケーブルを抜いてもリソース故障が発生しない | ○ | － | |
Online/Standby 運用時、Cmdline リソースのスクリプトが実行されると HV_LAST_DET_REPORT 環境変数が standby ではなく、Offline となる | ○ | ○ | |
userApplication Configuration Wizard で引継ぎネットワークリソースを作成中に「0880 未分類のエラーが発生しました。」のメッセージが表示される | ○ | － | |
"255.255.254.0"と設定されたネットマスク値が "255.255.0.0" に変わってしまった | ○ | ○ | |
マウントポイント名をリネームすると、Fsystem リソースでリソース故障が発生しクラスタが切り替わった | ○ | ○ | |
リソース故障が発生した後、ノードがパニックする場合としない場合がある | ○ | ○ | |
クラスタアプリケーションに登録している Oracle リソースを削除すると、共用ディスクのファイルシステムがマウントできなくなった | ○ | － | |
切替え動作中に強制的なファイルシステムチェックの ERROR メッセージが出力され、切替えが失敗する | － | ○ | |
IO 負荷の WARNING が出力される | － | ○ | |
ユーザ独自のアプリケーションを起動しようとすると、ノードがパニックしてしまう | ○ | ○ | |
GUI 画面にて、1422 番のオペレータ介入要求メッセージに応答した際に /var/adm/messages ファイルに出力される 2621 番のメッセージが文字化けする | ○ | － | |
運用系において telnet も受け付けられず、DB にもアクセスできない状態にもかかわらず、系切替えが行われない | － | ○ | |
シャットダウン機構に関する以下のメッセージが出力された | ○ | ○ | |
クラスタ運用中に /etc/vfstab.pcl を修正して共用ディスクをアンマウントしたら、パニックが発生した | ○ | ○ | |
/tmp 配下に巨大なファイルを作成したノードで パニックが発生した | ○ | ○ | |
定期保守実施後、システムを起動して RMS を自動起動させたが、Gls リソースが Standby に遷移できなかったために、RMS が正常に起動できなかった | ○ | ○ | |
hostname コマンドを実行すると、クラスタアプリケーションを構成するすべてのノードで同じ結果が出力される | ○ | － | |
引継ぎネットワークリソースが異常となり、切替えが発生したが、切替え先でも同様となり、システムが停止した | ○ | － | |
クラスタインタコネクトが全パス切断された場合に、ダンプが採取できないノードがある | － | ○ | |
Gds リソースを使用しているクラスタアプリケーションがエラーで停止した。復旧作業のため、共用ディスク上のファイルシステムをマウントしたい | ○ | ○ | |
共用ディスクとサーバを接続する FC カードが故障し、フェイルオーバが発生した | ○ | ○ | |
Cmdline リソースに登録したシェルスクリプトの出力がコンソールに出力されない | ○ | ○ | |
クラスタアプリケーションの Maintenance モードを解除した際に、Cmdline リソースが Online にもかかわらず、再度起動処理が行われる | ○ | ○ | |
PRIMECLUSTER を使用したシステムでアプリケーションを一切動作させていない状況で 10 分間隔で sar の %wio 値が高くなる | ○ | ○ | |
フェイルオーバを発生させると、Standby 型の userApplication が 2 回 Online となり、Cmdline リソースから呼ばれるアプリケーションが二重起動でエラーとなる | ○ | ○ | |
クラスタの RMS 起動処理後に Fsystem に異常が発生し、待機系へ状態遷移した | ○ | ○ | |
運用中に RMS の (SYS, 88) のメッセージが表示される | ○ | ○ | |
サブシステムハングによって業務が停止した | ○ | ○ | |
クラスタノードが起動しているにもかかわらず、Cluster Admin の CRM メインウィンドウでクラスタノードが起動状態 (緑色のアイコン) にならない | ○ | ○ | |
運用中に 7210 のメッセージが表示される | － | ○ | |
クラスタアプリケーションを Online へ遷移させたとき、以下のメッセージが表示され状態遷移プロシジャリソースで異常が発生する | ○ | ○ | |
現象 1：シャットダウン時に「clonltrc: ERROR: Module clonltrc is in use」のメッセージが出力される | － | ○ | |
ノード故障が発生していないにもかかわらず、ノード故障を通知する以下のメッセージが表示される | ○ | － | |
PersistentFault 属性を 1(Yes) に設定しているにもかかわらず、userApplication が起動時 Faulted にならない | ○ | － | |
hvlogcleanコマンドを実行した際に以下のメッセージがsyslog、およびCluster Adminに出力される | ○ | ○ | |
状態遷移中にリソース故障が発生した場合、Faultedのクリア操作を行っていなくても以下のメッセージが出力されることがある | ○ | ○ | |
ネットワークカード交換後、ネットワークがアップしない | － | ○ | |
富士通 MW の PRIMECLUSTER 対応製品において、状態遷移プロシジャからプロセス監視を使用せずにプロセスを起動する場合、そのプロセスのファイルディスクリプタ（fd）がハード/ソフトリミット共に 1024 となる | ○ | ○ | |
運用系でシステム停止中に、以下のエラーメッセージが出力された | ○ | ○ | |
RMSが起動していない状態でhvdumpコマンドを実行すると、以下のメッセージを出力し、終了ステータス 3 で異常終了する hvdump: message queue is not ready yet! | ○ | ○ | |
/var/log/secure や /var/log/messages に以下のメッセージが出力される java: Deprecated pam_stack module called from service "fjsvwvbs" | － | ○ | |
root(/)ディレクトリにclprtotrのcoreが存在することがあります | ○ | － | |
ノード起動時、PRIMECLUSTERが起動しない | ○ | － | |
クラスタノードにアクセスできない、または、業務が停止しているにもかかわらず、クラスタが異常を検出しない | ○ | ○ | |
ノード起動時に以下のメッセージが出力される | － | ○ | |
SA_icmpシャットダウンエージェントの“Init State”が“InitFailed”で表示される | － | ○ | |
/var/log/messagesファイルに出力されるFJSVcluster形式のメッセージが文字化けする。 | － | ○ | |
Solaris ゾーンをクラスタアプリケーションから制御している環境において、サーバの強制停止などによりグローバルゾーンが再起動された後にクラスタアプリケーションが Inconsistent 状態となった。 | ○ | － | |
I/O フェンシング機能を使用する VMware 環境において、ストレージへのマルチパス接続で片パス故障発生時、または、片パス故障からの復旧時に、クラスタアプリケーションのフェイルオーバが発生した。 | － | ○ | |
SPARC M10、M12 環境において、誤ってclrccumonctl コマンドを実行した時に、以下のエラーメッセージが出力された。 | ○ | － | |
SPARC M10、M12 環境において、誤って clrcimonctl コマンドを実行した。 | ○ | － |
RMS 起動時に、クラスタアプリケーションを構成するリソースが複数ノードで Online 状態になっている場合、RMS は Inconsistent 状態に遷移し、AutoStartUp 属性を設定していても自動起動を行いません。
Gds リソース、Fsystem リソースおよび CmdLine リソースで、この現象が多く発生します。
または、CUI により Gds リソースを作成した際に、Gds リソースを RMS で制御させるための hvgdsetup コマンドが実行されていないため、クラスタアプリケーションが Inconsistent 状態になっている可能性があります。
RMS 起動前にすでにリソースが Online 状態になっているのであれば、運用状態に問題(人為的なミス)がある可能性があります。運用状態に問題が無かったのかを確認してください。
hvgdsetup コマンドを実行していない場合は、以下の手順を行ってください。
Inconsistent 状態のクラスタアプリケーションの Fault のクリア
すべてのノードの RMS を停止
任意のノードで以下のコマンドを Gds リソースが登録してあるクラスごとに実行
# /usr/opt/reliant/bin/hvgdsetup -a "classname" <Return>
例) # /usr/opt/reliant/bin/hvgdsetup -a class0001 <Return>
すべてのノードの RMS を起動
確認のため再度すべてのノードの RMS を停止後、ノードの再起動を実施して本現象が回避されているかを確認してください。
userApplication の状態が、Offline または Faulted の状態のときに、配下のリソースが、Online または Faulted になった可能性があります。その原因として、以下のことが考えられます。
Cmdline リソースの check スクリプトは、正常復帰 (0復帰) しかしないようになっている (exit 0 しか記載していない)。そのため、Cmdline リソースは必ず Online になる。
Cmdline リソースの check スクリプトを見直してください。
"PRIMECLUSTER 導入運用手引書" の "Faulted 状態のクラスタアプリケーションを運用可能な状態にする" を参照し、Faulted 状態をクリアしてください。
再起動により、Faulted 状態がクリアされるようにしたい場合、PersistentFault 属性に "0" を設定してください。
PRIMECLUSTER の仕様です。NFS サーバ上では、リモートファイルシステムごとに Fsystem リソースを設定し、そのリソース数分ディテクタ (hvdet_ckshare) が起動されます。これにともない、hvdet_ckshare プロセスが複数動作することがあります。
対処は不要です。
一部のノードの RMS が起動していない可能性があります。
クラスタアプリケーションの AutoStartUp 属性に1を定義することで、クラスタアプリケーションは RMS の起動を契機に自動起動します。しかし、クラスタアプリケーションを構成するすべてのノードで RMS が起動しないと、クラスタアプリケーションは自動起動しません。RMS の HV_AUTOSTART_WAIT 環境変数の値(デフォルト 60 秒)以内にクラスタアプリケーションを構成するすべてのノードの RMS が起動しないと、/var/adm/messages(Solaris)、あるいは /var/log/messages(Linux) に以下の警告メッセージが出力されます。
[/var/adm/messages] または [/var/log/messages]
(SWT, 27): NOTICE: Cluster host <SysNode> is not yet online for application <userApplication>.
(SWT, 1): WARNING: The 'AutoStartUp' attribute is set and the HV_AUTOSTART_WAIT time for the user application <userApplication> has expired, without an automatic start up having yet taken place. Reason: not all necessary cluster hosts are online!
本メッセージが出力された後もクラスタアプリケーションを構成するすべてのノードで RMS の起動の待合せ処理は継続されます。残りのノードで RMS が起動した時点で、クラスタアプリケーションは自動起動します。
クラスタアプリケーションを構成するすべてのノードの RMS を起動してください。
RMS を起動できない場合は、以下のいずれかの方法により対処してください。
保守停止などの理由により、クラスタアプリケーションを構成するノードの一部を一定期間起動できない場合、RMS の HV_AUTOSTARTUP_IGNORE 環境変数に、起動できないノードを設定しておくことで、クラスタアプリケーションを構成するすべてのノードで RMS が起動しなくても、クラスタアプリケーションを自動起動させることができます。詳細は、"PRIMECLUSTER RMS 導入運用手引書" を参照してください。
なお、保守停止完了後は、必ず HV_AUTOSTARTUP_IGNORE 環境変数を削除してください。この属性に設定されているノードに対しては、RMS はクラスタアプリケーションが Online 状態になっていないかの確認をしないため、一つのクラスタアプリケーションが複数のノードで Online 状態になってしまうことを RMS が抑止することができません。
syslog(/var/adm/messages(Solaris)、あるいは /var/log/messages(Linux))にRMSの(SWT, 1)の警告メッセージが出力されます。
(SWT, 1): WARNING: The 'AutoStartUp' attribute is set and the
HV_AUTOSTART_WAIT time for the user application <userApplication> has
expired, without an automatic start up having yet taken place.
Reason: not all necessary cluster hosts are online!
この場合は、<userApplication> に示すクラスタアプリケーションが、クラスタ内のいずれのノードでも Online 状態になっていないことを確認した上で、hvswitch -f を使用してクラスタアプリケーションを起動してください。
1421 番または1423番のオペレータ介入メッセージが syslog (コンソールと var/adm/messages(Solaris)、あるいは /var/log/messages(Linux)) に表示されます。
該当するクラスタアプリケーションがいずれのノードでも Online 状態になっていないことを確認した上でオペレータ介入メッセージに "Yes" と応答し、クラスタアプリケーションを起動してください。1423 番の場合、オペレータ介入メッセージに "Yes" と応答する前に、表示されているリソースの故障が回復しているかどうかも確認してください。
注意
Solaris版 PRIMECLUSTER 4.3A10以降、またはLinux版 PRIMECLUSTER 4.3A30以降では、クラスタアプリケーションを強制起動する際に、RMS が起動していないノードが存在していた場合、RMS はそのノードを強制停止させた後、クラスタアプリケーションの強制起動を開始します。
ダブルフォルト（二重故障）発生時、フェイルオーバさせたい場合は、"PRIMECLUSTER 導入運用手引書"を参照して、HaltFlag 属性を有効にしてください。
ダブルフォルト（二重故障）が発生している可能性があります。ダブルフォルトが発生した場合、クラスタアプリケーションの属性である "HaltFlag" 属性が No(無効)と設定されている場合、もう一方のノードからの強制停止処理が実施されないため、クラスタアプリケーションのフェイルオーバは発生しません。
ダブルフォルトが発生した原因を確認し、対処を行ってください。例えば、リソース故障が発生した場合の Offline 処理でタイムアウトが発生した場合は、タイムアウト値の見直しを行ってください。
また、ダブルフォルト発生時、フェイルオーバさせたい場合は、"PRIMECLUSTER 導入運用手引書" を参照して、HaltFlag 属性を有効にしてください。
リソースのダブルフォルト（二重故障）発生後、シャットダウン機構によるノード強制停止が失敗している可能性があります。
シャットダウン機構によるノード強制停止が失敗した原因は、シャットダウンエージェントにSCON が設定されている可能性があります。
シャットダウンエージェントに SCON が設定されていないかどうかなど、シャットダウン機構の設定を見直して、ノード強制停止が行えるようにしてください。
別のクラスタアプリケーションに設定された依存関係のあるリソースが先に起動していなかったため、リソースの起動に失敗した可能性があります。
依存関係のあるリソースが別々のクラスタアプリケーションに設定されている場合は、それらのクラスタアプリケーションをスケーラブル運用とするクラスタアプリケーションを作成し、起動順番を設定してください。
Oracle を使用した環境では、Oracle リソース起動前に Gls リソースが起動するよう設定が必要です。Oracle リソースと Gls リソースが別々のクラスタアプリケーションに設定されている場合は、それらのクラスタアプリケーションをスケーラブル運用するクラスタアプリケーションを作成し、起動順番を設定してください。
PRIMECLUSTER の仕様です。
Fsystem リソースを含むクラスタアプリケーションのフェイルオーバが発生した際、Fsystem リソースで設定したマウントポイントにアクセスしているプロセスがあると、このプロセスが強制的に停止されます。
対処は不要です。
CUI により Fsystem リソースを作成し、NFS マウントしているマウントポイントを指定した場合、必ず表示されますがマウントが正常に行えていれば問題はありません。
システム運用管理ソフトウェアなどで、メッセージ監視を行っている場合は、WARNING で表示されるメッセージのうち、本メッセージを無視するように設定してください。
クラスタアプリケーションの HaltFlag 属性を有効にした環境で、ダブルフォルト（二重故障）が発生したため、シャットダウン機構により強制停止(パニックなど) が行われています。
システムの動作としては正常です。
ダブルフォルト（二重故障）発生時に強制停止させたくない場合は、クラスタアプリケーションのHaltFlag 属性を無効にしてください。ただし、その場合はダブルフォルト（二重故障）発生後のフェイルオーバが行われなくなります。
なお、二重故障が発生した場合、switchlog に以下のようなメッセージが表示されます。
(UAP, 36): FATAL ERROR: <userApplicationname>: double fault occurred,
but Halt attribute is set. RMS will exit immediately in order to
allow a failover!
(BM, 47): NOTICE: RMS monitor has exited with the exit code <96>.
また、強制停止を行ったノードの switchlog に以下のようなメッセージが表示されます。
(SYS, 9): NOTICE: Attempting to shut down the cluster host
<hostname> by invoking a Shutdown Facility via (sdtool -k <nodename>).
クラスタアプリケーションの状態遷移中にダブルフォルト（二重故障）が発生したため、RCI により強制停止されています。システムの動作としては正常です。
ダブルフォルト（二重故障）発生時に強制停止させたくない場合は、クラスタアプリケーションの HaltFlag 属性を無効にしてください。ただし、その場合はダブルフォルト（二重故障）発生後のフェイルオーバが行われなくなります。
なお、二重故障が発生した場合、switchlog に以下のようなメッセージが表示されます。
(UAP, 36): FATAL ERROR: <userApplicationname>: double fault occurred,
but Halt attribute is set. RMS will exit immediately in order to
allow a failover!
(BM, 47): NOTICE: RMS monitor has exited with the exit code <96>.
(SYS, 9): NOTICE: Attempting to shut down the cluster host
<hostname> by invoking a Shutdown Facility via (sdtool -k <nodename>).
/etc/opt/SMAW/SMAWsf/SA_rccu.cfg の設定内容が誤っている可能性があります。
RCCU の IP アドレス、ユーザ名、パスワードの設定に誤りがないことを確認してください。
また、RCCU の IP アドレスに Ping が成功することも確認してください。
設定の詳細は、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)" の "シャットダウン機構の設定" を参照してください。
/etc/opt/SMAW/SMAWsf/SA_rccu.cfg の設定内容に誤りはありませんか?
RSB の接続が行われていない可能性があります。
RSB の接続方法が誤っていませんか?
シャットダウン機構の設定が誤っている可能性があります。
シャットダウンエージェントの構成定義ファイルに指定した、IP アドレス、user/Password の設定値に誤りがないことを確認してください。
特に Password は、暗号化された Password を記載しているか確認してください。
また、指定された IP アドレスに Ping が成功することも確認してください。
設定の詳細は、"PRIMECLUSTER 導入運用手引書 (Linux)" の "シャットダウン機構の設定" を参照してください。
VMware 環境の場合は、"PRIMECLUSTER 導入運用手引書 (Linux)" の "シャットダウン機構の設定（VMware vCenter Server連携機能を使用する場合）" または "シャットダウン機構の設定（I/Oフェンシング機能を使用する場合）" を参照してください。
以下のシャットダウンエージェントの設定内容に誤りはありませんか?
PRIMERGY RX シリーズ / TX シリーズの場合
/etc/opt/SMAW/SMAWsf/SA_rsb.cfg
/etc/opt/SMAW/SMAWsf/SA_ipmi.cfg
PRIMERGY BX シリーズで ServerView Resource Orchestrator Virtual Edition と組み合わせる場合
/etc/opt/SMAW/SMAWsf/SA_ipmi.cfg
PRIMERGY BX シリーズで ServerView Resource Orchestrator Virtual Edition と組み合わせない場合
/etc/opt/SMAW/SMAWsf/SA_blade.cfg
仮想マシン環境 (KVM) のゲスト OS の場合
/etc/opt/SMAW/SMAWsf/SA_libvirtgp.cfg
/etc/opt/SMAW/SMAWsf/SA_libvirtgr.cfg
/etc/opt/SMAW/SMAWsf/SA_vmchkhost.cfg
VMware 環境の場合
/etc/opt/SMAW/SMAWsf/SA_vwvmr.cfg
/etc/opt/SMAW/SMAWsf/SA_icmp.cfg
SSH 初回時のユーザ問合せ ( RSA 鍵の生成) が完了していない可能性があります。
管理 OS や XSCF に対して SSH で接続し、初回時のユーザ問合せ ( RSA 鍵の生成) を完了させてください。
CF ノード名の変更時に、シャットダウン機構の設定変更手順を実施していない可能性があります。
CF ノード名の変更の手順に記載されている、シャットダウン機構の設定手順を実施してください。
設定の詳細は、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)" の "シャットダウン機構の設定" を参照してください。
SF のノードの重みと RMS の ShutdownPriority の設定により、生存優先度が同じになっている可能性があります。
SF 設定におけるノードの重み、および RMS Wizard で設定している ShutdownPriority の設定を確認してください。
生存優先度 (SF のノードの重み + ShutdownPriority) の値が一致していると、全ノードが互いに相手ノードを異常と認識し、同時にリブート処理を行う場合があります。
SF のノードの重みおよび RMS の ShutdownPriority の設定を変更することで、クラスタパーティションが発生した場合に生存させるノードと強制停止させるノードを特定できます。
詳細は、"PRIMECLUSTER 導入運用手引書" の "シャットダウン機構の設定" を参照してください。
SF のノードの重みと RMS の ShutdownPriority の設定を行っていますか?
ノード/アプリケーションの優先度付けが適切ではない状態で、クラスタインタコネクトに異常などが発生し、クラスタパーティションが発生した可能性があります。
クラスタパーティションが発生した場合、優先度が低いノードが再起動されます。ノード/アプリケーションの優先度付けを適切に設定してください。
詳細は、"PRIMECLUSTER 導入運用手引書" の "シャットダウン機構の設定" を参照してください。
クラスタインタコネクトに異常がありませんか?
クラスタアプリケーションのリソース状態で矛盾が発生している可能性があります。
Inconsistent 状態のクラスタアプリケーションが存在するノードに切り替えられた場合、矛盾を解消するためノードが再起動されます。
矛盾が解消されない場合、事象ログを参照し、Inconsistent 状態のアプリケーションを正常な状態としてください。
Inconsistent 状態のクラスタアプリケーションはありませんか?
userApplication オブジェクトの PersistentFault 属性を "yes" に変更している可能性があります。
PersistentFault 属性が "yes" の場合、システム再起動後のクラスタアプリケーションおよびRMS リソースは再起動前の状態のまま起動されるため、リソースの故障は通知されません。
PersistentFault 属性を "No" にしてください。
userApplication オブジェクトの PersistentFault 属性を "yes" に設定していませんか?
userApplication オブジェクトの PersistentFault 属性を "yes" に変更している可能性があります。
PersistentFault 属性が "yes" の場合、クラスタアプリケーションが Faulted 状態で RMS を再起動すると、再起動後のクラスタアプリケーションは、 Faulted 状態となります。
クラスタアプリケーションに対して Fault のクリア (hvutil -c コマンド)を実施し、Faulted 状態から Offline 状態へ遷移させてください。
userApplication オブジェクトの PersistentFault 属性を "yes" に設定していませんか?
RMS を停止させずにリブート処理を行ったため、リブート時間が遅くなる可能性があります。
本機能は制限事項です。運用ノードを停止する場合は、必ず事前に hvswitch コマンドでクラスタアプリケーションを切り替えるか、hvshut -l または hvshut -a コマンドで停止してください。
リブート前に RMS を停止していますか?
RSB シャットダウンエージェント (/etc/opt/SMAW/SMAWsf/SA_rsb.cfg) の設定値が誤っており、RSB によるノードの強制電源断が行われない可能性があります。
RSB シャットダウンエージェントの設定を修正してください。詳細は、"PRIMECLUSTER 導入運用手引書 (Linux)" の "シャットダウン機構の設定" を参照してください。
RSB の IP アドレスと RSB シャットダウンエージェントの設定値 (/etc/opt/SMAW/SMAWsf/SA_rsb.cfg) に不整合はありませんか?
RSB の電源が OFF では RSB によるノードの強制電源断が行われない可能性があります。
RSB の電源を ON にして再度強制停止を行ってください。なお、RSB の電源断を防止するため、UPS (無停電電源装置)の導入をおすすめします。
RSB の電源が ON になっていますか?
RSB の IP に Ping が送れない場合、RSB によるノードの強制電源断が行われない可能性があります。
各ノードから全ノードの RSB に接続できるように LAN を設計してください。
全ノードから RSB の IP に Ping が送れますか?
JavaVM の問題や JavaVM で使用するテンポラリ領域の不足によりコアダンプが採取される可能性があります。
サポートする JRE よりも古いバージョンの JRE を使用するとコアダンプが発生しやすい場合があります。
適切なバージョンの JRE がインストールされているか確認し、PRIMECLUSTERのインストールガイドを参照して、適切なバージョンの JRE をインストールしてください。
Web-Based Admin View が動作していない場合には "Web-Based Admin View 操作手引書" を参照して Web-Based Admin View を再起動してください。
適切なバージョンの JRE がインストールされていますか?
コンソールに XSCF を使用した PRIMEPOWER 250,450 のクラスタシステムでは、RCI を使用したシャットダウンエージェント 2 つ RCI(Panic, Reset) と、XSCF を使用したシャットダウンエージェント XSCF(Console Break) の、合計 3 つだけを設定してください。設定方法は以下のとおりです。
シャットダウン構成ウィザードを起動し、「簡単な設定(推奨)」からシャットダウン機構を設定してください。その際、使用するシャットダウンエージェントとして以下を選択してください。
RCI Panic
Console Break
RCI Reset
また、Console Break エージェントとして以下を選択してください。
XSCF Break
シャットダウン構成ウィザードの操作方法については、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)" の "シャットダウン機構の設定" を参照してください。その際、使用するシャットダウンエージェントについては、上記のように読み替えてください。
4.1A20 パッチ913381-04 以降または4.1A30 パッチ913897-01 以降が適用されている、または、4.1A40以降では、本現象は発生しません。
シャットダウンエージェントの設定は正しいですか？
マウントポイントを使用しているアプリケーションを特定し、アプリケーションからマウントポイントを使用しないようにするなどの対処を検討してください。
参照
Fsystem リソース異常の原因と対処については、Q3-2-50 も参照してください。
GDS で管理しているディスクに対して、Fsystem リソースを作成し、Fsystem リソースで使用している共用ディスクに対して、ファイルシステムを作成していない。
"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)"、または、 "PRIMECLUSTER 導入運用手引書 (Linux)" を参照し、ファイルシステムの設定を行ってください。
Scalable コントローラを使用してクラスタアプリケーションを構築した場合は、OnlinePriority 属性は有効になりません。PRIMECLUSTER の仕様動作となります。(PRIMECLUSTER 4.2A00以降は対象外)
以下の 3 通りの変更にて WARNING メッセージの出力を抑止、または、WARNING メッセージが出力し続けることでの切替えを抑止することが可能です。(必ずしも WARNING メッセージが出力されなくなるわけではありません。)
また、すべてが変更可能ですが、必ずしもすべてを変更する必要はありません。
各種内容を踏まえて変更を実施してください。
RMS 環境変数 HV_GMOUNTMAXLOOP の値を変更する。
RMS 環境変数 HV_GMOUNTMAXRETRY の値を変更する。
Fsystem リソースが行っているマウントポイントへの監視間隔を変更する。
各種設定値を変更する場合は、以下の手順で行います。
※手順 2、3 に関しては、すべてのノードで実施してください。
すべてのノードの RMS を停止します。
RMS の停止方法は、"PRIMECLUSTER 導入運用手引書" の "RMS の運用操作"を参照してください。
/usr/opt/reliant/bin/hvenv.local に "HV_GMOUNTMAXLOOP= 値" または、"HV_GMOUNTMAXRETRY= 値" を設定します。
HV_GMOUNTMAXLOOP のデフォルト値は、"4" です。また、
HV_GMOUNTMAXRETRY のデフォルト値は、"7" です。
hvenv.local は、/usr/opt/reliant/bin フォルダ配下のファイルです。
hvenv.local ファイルがない場合は作成してください。
hvenv.local ファイルへの記載例
例)
export HV_GMOUNTMAXLOOP=10 export HV_GMOUNTMAXRETRY=10
hvenv コマンドで "HV_GMOUNTMAXLOOP= 値" , "HV_GMOUNTMAXRETRY= 値" が表示されることを確認します。
例)
# hvenv | grep HV_GMOUNTMAXLOOPHV_GMOUNTMAXLOOP='10' export HV_GMOUNTMAXLOOP;
# hvenv | grep HV_GMOUNTMAXRETRYHV_GMOUNTMAXRETRY='10' export HV_GMOUNTMAXRETRY;
"HV_GMOUNTMAXLOOP= 値" , "HV_GMOUNTMAXRETRY= 値" が表示されない場合、手順 2 の作業に誤りがある可能性がありますので、手順 2 の作業を見直してください。
すべてのノードの RMS を起動します
RMS の起動方法は、"PRIMECLUSTER 導入運用手引書" の "RMS の運用操作" を参照してください。
すべてのノードの RMS を停止します。
RMS の停止方法は、"PRIMECLUSTER 導入運用手引書" の "RMS の運用操作" を参照してください。
Web-Based Admin View から "Global Cluster Services" - "userApplication Configuration Wizard" を選択します。
"Configuration 内の共通情報を設定" を選択します。
"Detector の詳細設定" を選択します。
"hvdet_gmount のリソース監視間隔 =10" を選択します。
"情報の入力"を選択し、変更する監視間隔を入力します。
hvdet_gmount のリソース監視間隔が変更した値になっていることを確認し、"戻る" を選択します。
"保存して登録" を選択し、"登録" を実行します。
※その後メッセージがポップアップされますが、すべて"はい"を選択してください。
すべてのノードの RMS を起動します。
RMSの起動方法は、"PRIMECLUSTER 導入運用手引書" の "RMS の運用操作" を参照してください。
なお、各種設定値変更に関して、以下の点に注意してください。
該当のファイルシステムに対して I/O 負荷がかかっている現象自体が回避されているわけではありません。(メッセージや切替え処理に対する抑止がされているだけです。)
実際に該当のディスクに障害が発生した場合に、障害内容によっては、現在の切替え発生時間よりも時間がかかってしまう可能性があります。
(ERROR の種類やデバイスの種類によっては、即時 ERROR を返さない可能性があり、今回のような一連の処理ができなくなって初めて切替え処理が発生する場合があります。)
Cmdline リソースの Online スクリプト、Offline スクリプト、Check スクリプトを見直し、正常に動作できるか確認してください。また実行するコマンドの実行権限やグループ権限もあわせて確認してください。
iptables、ip6tables、または nftables の設定で、クラスタのノード間通信を行うインタフェース(cip0)の通信またはクラスタリソース管理機構で使用するポートを送信先のみ許可し、送信元を許可していない可能性があります。
インタフェース(cip0)の通信およびクラスタリソース管理機構で使用するポートの通信を許可するように iptables、ip6tables、または nftables の設定を見直してください。
iptables、ip6tables、または nftables で state モジュールを使用している場合、iptables サービス、ip6tables サービス、または nftables サービスを再起動した可能性があります。
iptables、ip6tables、または nftables で state モジュールを使用している場合、iptables サービス、ip6tables サービス、または nftables サービスを再起動すると、通信状態の情報が初期化され、それ以降の通信が正常にできなくなります。
iptables の設定を変更した場合は、iptables サービスではなく、クラスタノードを再起動してください。
ip6tables の設定を変更した場合は、ip6tables サービスではなく、クラスタノードを再起動してください。
nftables の設定を変更した場合は、nftables サービスではなく、クラスタノードを再起動してください。
引継ぎネットワークリソースを作成した際に、PingHost を設定していない場合、ケーブルを抜いても引継ぎネットワークリソースは異常になりません。
業務 LAN の監視を行いたい場合は、GLS を使用してください。
GLS を使用しない場合は、引継ぎネットワークリソースを作成した際に、PingHost の設定を行ってください。
Standby 状態とする場合は、Cmdline リソースの属性 "STANDBYCAPABLE 属性" と "ALLEXITCODES 属性" を有効にしてください。
仮想インタフェースに設定したネットワークインタフェースに対してのネットマスク値の設定がなかったために、IP アドレスのデフォルトのサブネットマスク値に設定変更が行われたと考えられます。
PRIMECLUSTER Global Link Service のサブネットマスクの設定において、仮想インタフェースの作成で設定した仮想インタフェースに対するサブネットマスクの設定を行ってください。
リソース故障が発生すると、フェイルオーバ処理が行われます。そのフェイルオーバ処理でエラーが発生した場合は、ダブルフォルト（二重故障）となり、ノードがパニックします。
フェイルオーバ処理でエラーが発生していないかどうか確認してください。
ノードがパニックする場合、Q3-2-11 を参照してください。
Oracle リソースを削除する際に、Oracle リソース配下のリソースも削除するかを確認する 0808 番のメッセージで "はい" を選択したため、Fsystem リソースも削除されています。
Fsystem リソースを再作成してください。
切替ファイルシステムに ext3 を使用している場合、Online 処理時に強制的なファイルシステムチェック (fsck) が実行されることがあります。クラスタアプリケーション起動時や切替え時などに強制的な fsck が実行されると、切替ファイルシステムのオンライン処理でタイムアウトが発生し、PRIMECLUSTER の起動や切替えに失敗することがあります。PRIMECLUSTER の仕様です。（Linux のみ）
すべての ext3 切替ファイルシステムで、強制ファイルシステムチェックが実行されないように設定してください。設定方法の詳細については、PRIMECLUSTER 4.3A30以降の場合、"PRIMECLUSTER導入運用手引書 (Linux)"、PRIMECLUSTER 4.3A20以前の場合、"PRIMECLUSTER 活用ガイド＜クラスタ構築・運用時の留意点＞"を参照してください。ただし、強制ファイルシステムチェックを回避すると、ファイルシステム破壊が発生した場合に、発見が遅れるため、データ損失の危険性が高まります。
そのため、手動でファイルシステムの強制チェック (fsck -f) を実行して、データ損失の危険性を回避する必要があります。
RMS の構成定義に登録したマウントポイントに対する、マウントポイント監視時間のチューニングを実施してください。詳細は”Linux PRIMECLUSTER 構築ガイド”を参照してください。
アプリケーション起動時に、RMS で使用しているメッセージキューを削除している可能性があります。
RMS で使用しているメッセージキューを削除しないようにアプリケーション側で調整してください。
Web-Based Admin View が動作する言語環境が（syslang）が "ja" になっており、/var/adm/messages ファイルに EUC で出力されるが、表示させる端末の言語設定が EUC 以外になっているためです。
表示させる端末の言語設定を EUC に設定してください。
運用系の RSB の IP アドレスが変更されていて、運用系をシャットダウンできなかったために、系切替えが行えない可能性があります。
運用系の RSB の IP アドレスと、RSB シャットダウンエージェントの設定で行った値を一致させてください。
シャットダウン機構の admIP 設定時に存在しない IP アドレスが設定されています。
admIP には管理 LAN の IP アドレスを設定してください。
/etc/vfstab.pcl (Solaris)、または /etc/fstab.pcl(Linux) から Fsystem リソースが使用しているマウントポイントを削除したため、リソース故障が発生し、パニックが発生した可能性があります。
運用中に/etc/vfstab.pcl (Solaris),または /etc/fstab.pcl(Linux) の MountPoint***_Fsystem* リソースが使用するマウントポイントを修正しないでください。
メモリ資源、およびスワップ資源を圧迫し、他ノードからのハートビートに応答できなかった可能性があります。
メモリ枯渇となる可能性がありますので、/tmp に巨大なファイルを作成しないでください。
DNS サーバと通信することができなかったために、GLS 内部の名前－アドレス変換処理に時間がかかり、Gls リソースをタイムアウト時間内に、"STANDBY" に遷移させることができなかった可能性があります。
Gls リソースのタイムアウト時間を変更するか、HUB 監視先ホストの指定を IP アドレスに変更してください。または HUB 監視先ホストの変更に加えて、引継ぎホストの設定も IP アドレスに変更してください。
引継ぎネットワークリソースにて、ノード名引継ぎの設定が行われているため、hostname コマンドの出力結果がクラスタアプリケーションを構成するすべてのノードで同一となります。
ノード名引継ぎが不要であれば、IP アドレス引継ぎのみに設定を変更してください。
引継ぎネットワークリソースにて指定されている PingHost 先のホストが ping 応答を返せない状態である可能性があります。
PingHost 先のホスト状態を確認してください。
SA_rsb の状態が TestFailed になっており、RSB が正常動作していないことからダンプ採取命令が行われても RSB が命令を受信できなかったためにダンプが採取されていない可能性があります。
RSB を再設定し、ping または telnet できることを確認してください。また、SA_rsb.cfg の設定についても同様の設定にしてください。
GDS のボリュームは非活性状態となっておりアクセスできません。GDS のボリュームを起動後、ファイルシステムをマウントし、復旧作業を行ってください。手順は以下のとおりです。
全ノード RMS の停止
以下のコマンドを、クラスタを構成するいずれかのノードで実行し、全ノードの RMS を停止します。
# hvshut -aGDS ボリュームの起動
復旧作業が必要なデータが格納されている、GDS のボリュームを起動してください。
Global Disk Services 画面より該当のボリュームを選択し、ボリューム起動を実行してください。
ファイルシステムのマウント
手順 2. で起動した GDS ボリュームのファイルシステムをマウントします。
GFS ファイルシステムを使用している場合は、以下のようにマウントを行ってください。
# mount -F sfxfs /dev/sfdsk/class0001/dsk/volume0001 マウントポイントデータの復旧作業を行ってください。
手順 3. でマウントしたファイルシステムをアンマウントしてください。
GDS ボリュームの停止
手順 2. で起動した GDS ボリュームの停止を行ってください。
Global Disk Services 画面より該当のボリュームを選択し、ボリューム停止を実行してください。
以下のコマンドを、クラスタを構成するいずれかのノードで実行し、全ノードの RMS を起動します。
# hvcm -a
以下の手順で復旧を行ってください。
[全ノード停止が必要な場合]
クラスタを構成する全ノードの RMS を停止します。
# hvshut -a全ノードを停止します。
# shutdown -h nowFC カードを交換します。
交換が終わったら、起動します。
userApplication の状態が Faulted になっているノードで以下のコマンドを実行してください。
# hvutil -c アプリケーション名[該当ノードの停止で十分な場合]
該当ノードにて RMS を停止します。
# hvshut -l該当ノードを停止します。
# shutdown -h nowFC カードを交換します。
交換が終わったら、起動します。
起動したノードにて、Faulted になった userApplication に対して以下のコマンドを実行してください。
# hvutil -c アプリケーション名Cmdline リソースに登録した StartCommand および StopCommand の標準出力、標準エラー出力は、RELIANT_LOG_PATH (デフォルト :/var/opt/SMAWRrms/log) 配下の userApplication 名.log ファイルに書き出されるため、コンソールに出力されません。CheckCommand については、標準出力、標準エラーともにどこにも書き出されないため、コンソールに出力されません。
PRIMECLUSTER では、Cmdline リソースに登録されたシェルスクリプトの出力をコンソールに出力する設定はないため、コンソールに実行結果を出力するようなシェルスクリプトを作成してください。
該当する Cmdline リソースには NULLDETECTOR が設定されている可能性があります。NULLDETECTOR が設定されている Cmdline リソースがクラスタアプリケーションの Maintenance モード解除時に再度起動処理が行われる動作は仕様動作です。
Cmdline リソースが Online 状態で、再度起動処理が行われた場合に、二重起動とならないよう該当する Cmdline リソースに登録されているスクリプトを修正してください。
Scalable Controller を含む userApplication と、その配下にある Standby 型のuserApplication を同時にフェイルオーバさせると、Standby 型の userApplicationが 2 回 Online となります。(PRIMECLUSTER の正常な動作です。)
NULLDETECTOR フラグを設定した Cmdline リソースは Check スクリプトを持たず、実際のリソース状態を RMS 側で判断できないため、二重起動となる場合があります。
NULLDETECTOR フラグを設定した Cmdline リソースの二重起動による Online 処理の失敗を避けるには、Online スクリプトを改造することで対応できます。
具体的には、以下の処理を追加します。
対象プログラムを起動する前に、すでに対象プログラムが動作中でないかを Online スクリプト内でチェックする。
すでに対象プログラムが動作中の場合は、直ちに Online スクリプトを正常終了させる。
mount コマンドや fsck コマンドが失敗する原因で現象が発生しますが、特によく発生する原因は以下のとおりです。
マウント情報のファイル (Solaris は /etc/vfstab.pcl, Linux は /etc/fstab.pcl) に誤りがある。
ファイルシステムが GDS のボリューム上にあるにもかかわらず、ボリュームが起動されていないため、ファイルシステムにアクセスできず mount コマンドがエラーとなっている。
ファイルシステムが作成されていない場合。
fsck コマンドによりファイルシステムの復旧を試みたが、fsck コマンドは復旧不可能と判断し、エラー復帰した場合。
fsck コマンドの復旧処理に時間を要したために Fsystem リソースの Online 処理のタイムアウトにより fsck が中断した場合。
/etc/dfs/dfstab.pcl の設定に誤りがある場合。(Solaris のみ)
他のアプリケーションがマウントポイントを使用している場合。
各原因に対する対処方法は以下のとおりです。
以下の観点でマウント情報のファイルを見直ししてください。
クラスタアプリケーションにより制御されるファイルシステムの定義において先頭行に #RMS# が記述されてるか？
デバイス名に間違いがないか？
マウントポイントに間違いはないか？
ノード間で設定が一致しているか？
以下の観点で Gds リソースに関する設定を見直ししてください。
クラスタアプリケーションに当該ファイルシステムを含む GDS のディスククラスが登録されているか？
登録されているディスククラスに誤りがないか？
マウントするデバイス上にファイルシステムを作成してください。
手動で fsck コマンドを実行し、ファイルシステムの復旧が可能かを確認します。復旧できない場合は、ファイルシステムを再作成し、データを復旧します。
fsck コマンドでファイルシステムの復旧を手動で行い、実際に要した時間計測します。その後、Fsystem リソースの Timeout 時間に計測した時間を追加してください。
以下の観点でマウント情報のファイルを見直ししてください。
クラスタアプリケーションにより制御されるマウントポイントの定義において先頭行に #RMS# が記述されてるか？
share を実行するマウントポイントの定義に間違いはないか？
ノード間で設定が一致しているか？
他のアプリケーションがマウントポイントを使用している場合は、そのアプリケーションでマウントポイントを使用するのをやめるか、アプリケーションを終了してください。
以下のいずれかの原因で、<time> 秒以上たっても応答がないためメッセージか表示されています。
クラスタインタコネクトがハード故障により通信ができない
RMS がハートビート処理をできないほど、システムの CPU 負荷が長時間発生している
NTP で急激な時刻戻しが行われたため、RMS 間のハートビートが途切れた
要因に従って以下の対処を行ってください。
LAN カード交換、ケーブル交換などを行い、ハード故障の要因を取り除いてください。
<SysNode> のホストが高負荷となっている処理を見直してください。
NTP でゆっくりとした時刻合わせを行ってください。
運用ノード内の一部の I/O だけが異常になっているために、業務が停止している可能性があります。
一部の I/O だけが異常でその他の I/O が正常のため、クラスタシステムが異常事象を検知していない場合（クラスタシステムの監視からは正常に見えている場合）を、サブシステムハングと呼びます。
待機ノードに切り替わることによって業務再開の見込みがあるため、以下の対処を実施してください。
PRIMERGY または PRIMEQUEST で待機ノードにログインできる場合
sdtool コマンドを使用して、運用ノードを停止業務に切り替えてください。
# sdtool -k node-namenode-name ： 停止するノードの CF ノード名を指定します。
sdtool -k コマンドで運用ノードの強制停止に失敗した場合は、「いずれのノードにもログインできない場合」の対処を実施してください。
参照
sdtool コマンドの詳細は、"PRIMECLUSTER 活用ガイド＜コマンドリファレンス編＞"の sdtool(1M) を参照してください。
いずれのノードにもログインできない場合
[Solaris の場合]
物理環境または制御ドメインを強制停止する場合
本体装置の取扱説明書を参照してください。
ゲストドメインを強制停止する場合
制御ドメインで ldm panic-domain コマンドなどを使用してください。
# ldm panic-domain <強制停止するゲストドメイン名>
カーネルゾーンを強制停止する場合
グローバルゾーンで zoneadm halt コマンドなどを使用してください。
# zoneadm -z <強制停止するカーネルゾーン名> halt
[Linux の場合]
PRIMERGY の物理環境または PRIMERGY の管理 OS を強制停止する場合
本体装置の NMI ボタンを押すか、キー操作によって運用ノードをパニックさせてください。
PRIMEQUEST の物理環境または PRIMEQUEST の管理 OS を強制停止する場合
Web-UI を使用して運用ノードを停止してください。
管理 OS が RHEL6.3 以前の環境でゲスト OS を強制停止する場合
管理 OS で virsh コマンドなどを使用してください。
# virsh suspend <強制停止するゲスト OS 名>
# virsh dump --crash <強制停止するゲスト OS 名> <ダンプファイル>
管理 OS が RHEL6.4 以降、RHEL7、および RHEL8 環境でゲスト OS を強制停止する場合
管理 OS で virsh コマンドなどを使用してください。
# virsh suspend <強制停止するゲスト OS 名>
# virsh dump --crash --memory-only <強制停止するゲスト OS 名> <ダンプファイル>
VMware 環境の場合
ESXi ホストまたは VMware vCenter Server から仮想マシンを停止してください。
Cluster Admin を終了し、Web-Based Admin View 画面の Global Cluster Services メニューから、再度 Cluster Admin を起動してください。
Cluster Admin が起動した後、CRM ウィンドウを表示しクラスタノードの起動状態を確認してください。
Cluster Admin を再起動しても同様の現象が頻繁に発生する場合は、当社技術員 (SE) に連絡してください。
Cluster Admin の CF ウィンドウで、該当のクラスタノードが起動状態 (緑色のアイコン)で表示されていますか？
MMB からの応答がないためメッセージか表示されていると考えられます。
以下の要因が考えられます。要因に従って対処を行ってください。
MMB が故障している
ハード故障の要因を取り除いてください。
システムの CPU 負荷が長時間発生している
メッセージが表示されたノードで高負荷となっている処理を見直してください。
状態遷移プロシジャ内で標準出力または標準エラーにメッセージを出力しようとしたため、状態遷移プロシジャが異常終了した可能性があります。
状態遷移プロシジャ内では echo(1) コマンドなどで標準出力および標準エラー出力にメッセージを出力することはできません。
状態遷移プロシジャの動作状態を確認する場合は、リダイレクションを使用して自製品のログファイルに出力してください。
現象1の原因
シャットダウン時に、カーネルモジュール(clonltrc)が使用する特殊ファイルをオープンしたままのプロセスが存在するため、カーネルモジュール(clonltrc)の停止時にモジュールのアンロードに失敗するメッセージが出力されます。
現象2の原因
シングルユーザモードに移行した場合、現象1の原因によりカーネルモジュール(clonltrc)がロードされたままになることがあります。その状態でマルチユーザモードに移行した場合、すでにカーネルモジュール(clonltrc)がロード済みであるため、カーネルモジュール(clonltrc)のロードで失敗するメッセージが出力されます。
現象1と現象2が発生した場合
シングルユーザモードからマルチユーザモードに移行した場合、必ずシステム再起動の操作 (例: shutdown -r now) によりマルチユーザモードに移行するようにしてください。
現象1のみ発生した場合（シングルユーザモードに移行した場合）
本メッセージが出力されるだけで動作に問題ありません。マルチユーザモードに移行する場合は、必ずシステム再起動の操作 (例: shutdown -r now) によりマルチユーザモードに移行するようにしてください。
現象1のみ発生した場合（通常のシャットダウンまたはシステム再起動の場合）
対処の必要はありません。本メッセージが出力されるだけで動作に問題ありません。
上記以外が発生する場合は、当社技術員に連絡してください。
全ノードが停止した状態から1ノードのみ起動させた場合に、本メッセージが表示される場合があります。
オペレータに他ノードが停止しているという注意を喚起するために表示されるメッセージであり、実際にノード故障が発生していないのであれば、特に対処を行う必要はありません。
以下の条件をすべて満たす場合、PersistentFault 属性に 1 が設定されていても、userApplication は起動時 Faulted になりません。
ノードの FC ケーブルをすべて抜く。
I/O エラー検出後 Faulted に遷移する前に、PRIMECLUSTER 以外の製品の処理でノードがパニックしリブートする。
共有ディスク接続確認 (*1) により RMS の起動が抑止される(FC ケーブルは抜けたままの状態)。
FC ケーブルを差し戻し、再度リブートする。
FC ケーブル抜けなど共有ディスク接続確認において故障が検出された場合、PersistentFault 属性が機能し userApplication を Faulted にするより前に、共用ディスク接続確認が故障を通知し、RMS の起動を抑止します。
このため、故障から復旧し RMS が起動できる状態になった後に、あらためて故障を通知し、userApplication 起動の抑止を行う必要がないため、userApplication を Faulted にしていません。
(*1)共有ディスク装置接続確認の設定については、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)"の、"共用ディスク装置接続確認の設定"を参照してください。
対処は不要です。
hvlogcleanコマンドを実行した際に、RMSのログファイルが一時的に参照できなくなった可能性があります。
対処は不要です。
hvdispコマンド、または ClusterAdminのRMSタブでリソースの状態を確認し、Faultedのクリア操作を行ってください。
ネットワーク定義ファイル (ifcfg-ethx)のMACアドレスを修正していないことが考えられます。
ifcfg-ethxのMACアドレスを修正してください。
PRIMECLUSTERの状態遷移プロシジャでは、PRIMECLUSTERの資源を引き継いでプロセスが起動されるため、ファイルディスクリプタ（fd）のハード/ソフトリミットが共に1024となります。
以下の手順で対処を行ってください。
注意
本手順はApplicationクラスの状態遷移プロシジャproc.shを変更する場合の手順です。クラスや状態遷移プロシジャ名は環境に合わせて変更し実施してください。
すべてのノードのRMSを停止します。
以下のコマンドを、クラスタを構成するいずれかのノードで実行し、すべてのノードのRMSを停止します。
# hvshut -a
一時ディレクトリに移動し、状態遷移プロシジャを取り出します。
例）一時ディレクトリ/var/tmpに状態遷移プロシジャproc.shを取り出す場合
# cd /var/tmp
# /etc/opt/FJSVcluster/bin/clgetproc -c Application proc.sh
取り出した状態遷移プロシジャを編集します。
状態遷移プロシジャの処理の先頭に"ulimit"の定義を追加し、ファイルディスクリプタの最大値を指定します。"ulimit"で指定する値は、その環境で必要な値を設定してください。
例) ファイルディスクリプタの最大値を4096に設定する場合
# vi proc.sh
#!/bin/sh ulimit -n 4096 ・・・ |
編集した状態遷移プロシジャを登録します。
# /etc/opt/FJSVcluster/bin/clsetproc -c Application -o proc.sh
状態遷移プロシジャを登録しているすべてのノードで 2.～4.の手順を実施します。
RMSを起動します。
以下のコマンドを、クラスタを構成するいずれかのノードで実行し、すべてのノードのRMSを起動します。
# hvcm -a
クラスタシステム全体としての切替処理が完了する前に、相手ノードでシャットダウン処理が開始された可能性があります。
切替処理が完了してから shutdown を実施してください。
hvdump(1M) コマンドを実行したノードにおいて、パニックなどにより RMS が強制終了したため、RMS の構成情報に不整合が発生しています。
RMS の構成情報の不整合は RMS の起動により解消されるため、RMS の起動後に再度 hvdump(1M) コマンドを実行してください。
メッセージが出力されるだけでシステムに影響はないため、対処の必要はありません。
ノード起動時にcoreが採取されることがありますが、PRIMECLUSTERの動作には影響はありませんので削除してください。
PRIMECLUSTERのSMFサービスが起動不可になっている可能性があります。
以下のコマンドを実行し、SMFサービスがdisabledになっていないかを確認してください。
# svcs "SMFサービス名"
例) # svcs svc:/milestone/smawcf:default
STATE STIME FMRI
disabled 15:25:30 svc:/milestone/smawcf:default[確認対象SMFサービス名]
svc:/milestone/smawcf:default
svc:/milestone/fjsvcldev:default
svc:/milestone/smawsf:default
svc:/milestone/fjsvclapi:default
svc:/milestone/fjsvclrms:default
svc:/milestone/fjsvcldbm:default
svc:/milestone/fjsvclrmgr:default
svc:/milestone/fjsvclctrl:default
svc:/milestone/fjsvclrwz:default
svc:/milestone/fjsvclprmd:default
svc:/milestone/fjsvclrmgr2:default
svc:/milestone/fjsvclautoconfig:default
svc:/milestone/fjsvclwaitprobe:default
svc:/milestone/smawrrms:default
disabledになっていた場合、以下のコマンドを実行し、SMFサービスを起動してください。
# svcadm enable "SMFサービス名"
例) # svcadm enable svc:/milestone/smawcf:default
該当ノードにおいて、ディスク装置のシステムボリュームを参照できない可能性があります。
システムボリュームを参照できないノードは動作が不定のため、以下の方法でノードをパニックさせてください。
PRIMERGY または PRIMEQUEST で該当ノード以外のクラスタノードにログインできる場合
sdtoolコマンドを使用して、該当ノードを停止させてください。
# sdtool -k node-namenode-name ： 停止するノードの CF ノード名を指定します。
sdtool -k コマンドで運用ノードの強制停止に失敗した場合は、「いずれのノードにもログインできない場合」の対処を実施してください。
参照
sdtool コマンドの詳細は、"PRIMECLUSTER 活用ガイド ＜コマンドリファレンス編＞"の sdtool(1M) を参照してください。
いずれのノードにもログインできない場合
[Solaris の場合]
物理環境または制御ドメインを強制停止する場合
本体装置の取扱説明書を参照してください。
ゲストドメインを強制停止する場合
制御ドメインで ldm panic-domain コマンドなどを使用してください。
# ldm panic-domain <強制停止するゲストドメイン名>
カーネルゾーンを強制停止する場合
グローバルゾーンで zoneadm halt コマンドなどを使用してください。
# zoneadm -z <強制停止するカーネルゾーン名> halt
[Linux の場合]
PRIMERGY の物理環境または PRIMERGY の管理 OS を強制停止する場合
本体装置の NMI ボタンを押すか、キー操作によって運用ノードをパニックさせてください。
PRIMEQUEST の物理環境または PRIMEQUEST の管理 OS を強制停止する場合
Web-UI を使用して運用ノードを停止してください。
管理 OS が RHEL6.3 以前の環境でゲスト OS を強制停止する場合
管理 OS で virsh コマンドなどを使用してください。
# virsh suspend <強制停止するゲスト OS 名>
# virsh dump --crash <強制停止するゲスト OS 名> <ダンプファイル>
管理 OS が RHEL6.4 以降、RHEL7、および RHEL8 環境でゲスト OS を強制停止する場合
管理 OS で virsh コマンドなどを使用してください。
# virsh suspend <強制停止するゲスト OS 名>
# virsh dump --crash --memory-only <強制停止するゲスト OS 名> <ダンプファイル>
VMware 環境の場合
ESXi ホストまたは VMware vCenter Server から仮想マシンを停止してください。
以下の要因が考えられます。
１ノードの単独起動を行った場合
ノード起動時にクラスタを構成するいずれかのノードが停止していた場合
クラスタを構成するすべてのノードを起動してください。すでに起動済であれば、対処は不要です。
以下の要因が考えられます。
１ノードの単独起動を行った場合
ノード起動時にクラスタを構成するいずれかのノードが停止していた場合
クラスタを構成するすべてのノードを起動してください。すでに起動済であれば、手順2から行ってください。
現象発生ノードで以下のコマンドを実行してください。
# sdtool -e # sdtool -b
以下のコマンドを実行して、“Test State”が “TestWorked”、“Init State”が“InitWorked”と表示されていることを確認してください。
# sdtool -s■実行例
# sdtool -s Cluster Host Agent SA State Shut State Test State Init State ------------ ----- -------- ---------- ---------- ---------- node1 SA_icmp Idle Unknown TestWorked InitWorked node2 SA_icmp Idle Unknown TestWorked InitWorked
以下のいずれかの条件の場合、シャットダウン機構起動時の言語設定が、OSの言語設定と異なるため、文字化けすることがあります。
Cluster Admin GUIでCFの起動を行った場合
OSの言語設定と異なる言語設定がされた端末上で、sdtool -bコマンドによりシャットダウン機構を起動した場合
以下の手順で、シャットダウン機構を再起動します。
以下のコマンドを実行し、シャットダウン機構を停止してください。
# sdtool -e文字化けが発生した端末の言語設定をOSと同じ設定にしてください。
以下のコマンドを実行し、シャットダウン機構を起動してください。
# sdtool -bグローバルゾーンの OS パニック後の RMS 起動時において、Cmdline リソースのノングローバルゾーンの状態確認のタイミングにより、ノングローバルゾーンを制御する Cmdline リソースが Faulted 状態のまま RMS が起動する場合があります。それにより、userApplication が Inconsistent 状態になります。
userApplication が Inconsistent 状態になった場合の一般的な対処方法で対処できます。
グローバルゾーンにて、Inconsistent 状態になった userApplication に hvutil -f コマンドまたは hvutil -c コマンドを実行し、Inconsistent 状態を解消してください。
VMware の KB2147535 に記載の事象が原因で共用ディスクへの I/O でエラーが発生し、クラスタアプリケーションのフェイルオーバが発生しました。
片パス故障からの復旧後、共用ディスクへの I/O エラーが発生したノードで、Faulted になった userApplication に対して以下のコマンドを実行してください。
# hvutil -c userApplication名userApplication の Faulted 状態が解消したら、必要に応じてクラスタアプリケーションの起動や切替えを行ってください。
クラスタアプリケーションのフェイルオーバの発生を未然に防止するには、KB2147535 に記載されている VMWare ESXi のパッチを適用してください。
SPARC M10、M12 環境では、コンソール非同期監視は使用しないため、clrccumonctl コマンドは使用できません。
以下の手順で対処してください。
コンソール非同期監視のデーモンが起動しているかを確認します。
# /etc/opt/FJSVcluster/bin/clrccumonctl"The devrccud daemon does not exist."が表示された場合、対処は不要です。
"The devrccud daemon exists."が表示された場合、次の手順を行ってください。
コンソール非同期監視のデーモンを停止します。
# /etc/opt/FJSVcluster/bin/clrccumonctl stopコンソール非同期監視のデーモンが停止したことを確認します。
# /etc/opt/FJSVcluster/bin/clrccumonctl"The devrccud daemon does not exist."が表示されることを確認してください。
"The devrccud daemon exists."が表示された場合は、再度、手順2を行ってください。
SPARC M10、M12 環境では、RCI非同期監視は使用しないため、clrcimonctl コマンドは使用できません。
以下の手順で対処を行ってください。
RCI非同期監視のデーモンが起動しているかを確認します。
# /etc/opt/FJSVcluster/bin/clrcimonctl"The devscfd daemon does not exist."が表示された場合、対処は不要です。
"The devscfd daemon exists."が表示された場合、次の手順を行ってください。
RCI非同期監視のデーモンを停止します。
# /etc/opt/FJSVcluster/bin/clrcimonctl stopコンソール非同期監視のデーモンが停止したことを確認します。
# /etc/opt/FJSVcluster/bin/clrcimonctl"The devscfd daemon does not exist."が表示されることを確認してください。
"The devscfd daemon exists."が表示された場合は、再度、手順2を行ってください。