PRIMECLUSTER 活用ガイド <トラブルシューティング編> (Solaris(TM)オペレーティングシステム/Linux版)
目次 索引 前ページ次ページ

第1部 事象別トラブル> 第3章 運用時のトラブル

3.2 運用全般に関するトラブル

PRIMECLUSTER の運用全般に関するトラブルシューティングについて説明します。

■トラブル一覧

No.

現象

Solaris

Linux

Q3-2-1

RMS 起動時、クラスタアプリケーションが自動的に Online 状態にならず、Inconsistency 状態 となる

Q3-2-2

クラスタアプリケーションが Faulted 状態となった後、故障原因を解決し、Faulted 状態となったノードを再起動しても、クラスタアプリケーションが Faulted 状態のまま起動されない

Q3-2-3

NFS サーバをクラスタ化しているシステムにおいて、hvdet_system プロセスが大量に動作している

Q3-2-4

全ノード同時に起動または再起動を行っても、クラスタアプリケーションが起動されない

Q3-2-5

クラスタアプリケーションにダブルフォルト(二重故障)が発生した場合に、クラスタアプリケーションがフェイルオーバしない

Q3-2-6

クラスタアプリケーション起動時に、一部のリソースが起動されない

Q3-2-7

フェイルオーバが発生すると、共用ディスクへのアクセスを行なうプロセスが強制停止される

Q3-2-8

クラスタアプリケーションを Online へ状態遷移させたとき、Fsystem リソースで異常が発生するまた、クラスタアプリケーションを起動すると、以下の Fsystem リソースのメッセージが表示される
RMSWT <ResourceName>: WARNING: If the major/minor device numbers are not the same on all cluster hosts, clients will be required to remount the file systems

Q3-2-9

リソース故障が発生した後、フェイルオーバ処理に異常が発生すると強制停止が発生する

Q3-2-10

クラスタアプリケーションの状態遷移に失敗した後、RCI により強制停止された形跡がある

Q3-2-11

クラスタパーティション発生時にリブートが行われない

Q3-2-12

クラスタパーティション発生時に全ノードが同時にリブートされた

Q3-2-13

運用中のアプリケーションが動作するノードが突然再起動される

Q3-2-14

再起動後に Faulted 状態になった RMS のクラスタアプリケーションおよびリソースの故障が通知されない

Q3-2-15

再起動後に RMS のクラスタアプリケーション およびリソースがすべて Faulted 状態になる

Q3-2-16

運用ノードのリブート時間が遅い

Q3-2-17

RSB によるノードの強制電源断が行えない

Q3-2-18

Java 関連のコアダンプが採取される

Q3-2-19

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 になった

Q3-2-20

以下のメッセージが表示され、リソース故障となる
NOTICE: failed to open device "<DeviceName>" with errno 6

Q3-2-21

Scalable コントローラを使用した環境にて、クラスタアプリケーションの OnlinePriority 属性を設定しているにもかかわらず、有効にならない

Q3-2-22

運用中に以下のメッセージが出力される
WARNING: doopenread of "/dev/sfdsk/class0001/rdsk/smaf01-AP" (pid 5970), counter=1 not done yet reporting status, waiting ...

Q3-2-23

userApplication の起動および切替えができない

Q3-2-24

引継ぎネットワークリソースを作成し、業務 LAN に引継ぎ IP アドレスを 設定した環境で、業務 LAN ケーブルを抜いてもリソース故障が発生しない

Q3-2-25

Online/Standby 運用時、Cmdline リソースのスクリプトが実行されると HV_LAST_DET_REPORT 環境変数が standby ではなく、Offline となる

Q3-2-26

userApplication Configuration Wizard で引継ぎネットワークリソースを作成中に「0880 未分類のエラーが発生しました。」のメッセージが表示される

Q3-2-27

"255.255.254.0"と設定されたネットマスク値が "255.255.0.0" に変わってしまった

Q3-2-28

リソース故障が発生しましたというメッセージが出力され、クラスタが切り替わった

Q3-2-29

リソース故障が発生した後、ノードがパニックする場合としない場合がある

Q3-2-30

クラスタアプリケーションに登録している Oracle リソースを削除すると、共用ディスクのファイルシステムがマウントできなくなった

Q3-2-31

切替え動作中に強制的なファイルシステムチェックの ERROR メッセージが出力され、切替えが失敗する

Q3-2-32

IO 負荷の WARNING が出力される

Q3-2-33

ユーザ独自のアプリケーションを起動しようとすると、ノードがパニックしてしまう

Q3-2-34

GUI 画面にて、1422 番のオペレータ介入要求メッセージに応答した際に /var/adm/messages ファイルに出力される 2621 番のメッセージが文字化けする

Q3-2-35

運用系において telnet も受け付けられず、DB にもアクセスできない状態にも関わらず、系切替えが行われない

Q3-2-36

シャットダウン機構に関する以下のメッセージが出力された
   can't bind local address, errno 126

Q3-2-37

クラスタ運用中に /etc/vfstab を修正して共用ディスクをアンマウントしたら、パニックが発生した

Q3-2-38

/tmp 配下に巨大なファイルを作成したノードで パニックが発生した

Q3-2-39

定期保守実施後、システムを起動して RMS を自動起動させたが、Gls リソースが Standby に遷移できなかったために、RMS が正常に起動できなかった

Q3-2-40

hostname コマンドを実行すると、両ノードで同じ結果が出力される

Q3-2-41

引継ぎネットワークリソースが異常となり、切替えが発生したが、切替え先でも同様となり、システムが停止した

Q3-2-42

クラスタインタコネクトが全パス切断された場合に、ダンプが採取できないノードがある

Q3-2-43

GDS リソースを使用しているクラスタアプリケーションがエラーで停止した。復旧作業のため、共用ディスク上のファイルシステムをマウントしたい

Q3-2-44

共用ディスクとサーバを接続する FC カードが故障し、フェイルオーバが発生した

Q3-2-45

Cmdline リソースに登録したシェルスクリプトの出力がコンソールに出力されない

Q3-2-46

クラスタアプリケーションの Maintenance モードを解除した際に、Cmdline リソースが Online にもかかわらず、再度起動処理が行われる

Q3-2-47

PRIMECLUSTER を使用したシステムでアプリケーションを一切動作させていない状況で 10 分間隔で sar の %wio 値が高くなる

Q3-2-48

フェイルオーバを発生させると、Standby 型の userApplication が 2 回 Online となり、Cmdline リソースから呼ばれるアプリケーションが二重起動でエラーとなる

Q3-2-49

クラスタの RMS 起動処理後に Fsystem に異常が発生し、待機系へ状態遷移した

Q3-2-50

運用中に RMS の (SYS, 88) のメッセージが表示される

Q3-2-51

サブシステムハングによって業務が停止した

Q3-2-52

クラスタノードが起動しているにもかかわらず、Cluster Admin の CRM メインウィンドウでクラスタノードが起動状態 (緑色のアイコン) にならない

Q3-2-53

運用中に 7210 のメッセージが表示される
An error was detected in MMB. (node:nodename mmb_ipaddress1:mmb_ipaddress1 mmb_ipaddress2:mmb_ipaddress2 node_ipaddress1:node_ipaddress1
node_ipaddress2:node_ipaddress2 status:status detail:detail)

Q3-2-54

クラスタアプリケーションを Online へ遷移させたとき、以下のメッセージが表示され状態遷移プロシジャリソースで異常が発生する
FJSVcluster: ERROR: clexecproc: 6817: An error occurred during state transition procedure execution.(error procedure:procedure detail:code1-code2-code3-code4-code5-code6-code7)

Q3-2-55

現象 1:シャットダウン時に「clonltrc: ERROR: Module clonltrc is in use」のメッセージが出力される
現象 2:システム起動時に「rc: Starting clonltrc: failed」のメッセージが出力される

Q3-2-56

ノード故障が発生していないにもかかわらず、ノード故障を通知する以下のメッセージが表示される
"FJSVcluster: エラー: claddfaultrsc: 6751: SysNode 故障が発生しました。"

Q3-2-57

PersistentFault 属性を 1(Yes) に設定しているにもかかわらず、userApplication が起動時 Faulted にならない

Q3-2-58

hvlogcleanコマンドを実行した際に以下のメッセージがsyslog、およびCluster Adminに出力される
clwatchlogd: FJSVcluster: ERROR: exec_chg_line: 6000: An internal error occurred. (function:fopen detail:0x30000071-0x2-0-0xffff)

Q3-2-59

状態遷移中にリソース故障が発生した場合、Faultedのクリア操作を行っていなくても以下のメッセージが出力されることがある
cldelfaultrsc: FJSVcluster: INFO: cldelfaultrsc: 2700: The resource fail has recovered.SysNode:SysNode userApplication:userApplication Resorce:resource

Q3-2-60

ネットワークカード交換後、ネットワークがアップしない

Q3-2-61

富士通 MW の PRIMECLUSTER 対応製品において、状態遷移プロシジャからプロセス監視を使用せずにプロセスを起動する場合、そのプロセスのファイルディスクリプタ(fd)がハード/ソフトリミット共に 1024 となる

Q3-2-62

運用系でシステム停止中に、以下のエラーメッセージが出力された
cldelmsg: FJSVcluster: ERROR: cldelmsg: 6000: An internal error occurred. (function:_ClExecGetNode detail:0x300a0006-0xfffffff4-0-0)


 

Q3-2-1 RMS 起動時、クラスタアプリケーショが自動的にOnline 状態にならず、Inconsistency 状態となる

原因1

RMS 起動時に、クラスタアプリケーションを構成するリソースが両ノードで Online 状態になっている場合、RMS は Inconsistency 状態に遷移し、AutoStartup 属性を設定していても自動起動を行ないません。
GDS リソース、Fsystem リソースおよび CmdLine リソースで、この現象が多く発生します。

または、CUI により GDS リソースを作成した際に、GDS リソースを RMS で制御させるための hvgdsetup コマンドが実行されていないため、クラスタアプリケーションが Inconsistency 状態になっている可能性があります。

対処1

RMS 起動前にすでにリソースが Online 状態になっているのであれば、運用状態に問題(人為的なミス)がある可能性があります。運用状態に問題が無かったのかを確認してください。

hvgdsetup コマンドを実行していない場合は、以下の手順を行ってください。

  1. Inconsistency 状態のクラスタアプリケーションの Fault のクリア
  2. すべてのノードの RMS を停止
  3. 任意のノードで以下のコマンドを Gds リソースが登録してあるクラスごとに実行
    # /usr/opt/reliant/bin/hvgdsetup -a "classname" <Return>
    例)# /usr/opt/reliant/bin/hvgdsetup -a de_cls01 <Return>
  4. すべてのノードの RMS を起動
  5. 確認のため再度すべてのノードの RMS を停止後、ノードの再起動を実施して本現象が回避されているかを確認してください。

原因2

userApplication の状態が、Offline または Faulted の状態のときに、配下のリソースが、Online または Faulted になった可能性があります。その原因として、以下のことが考えられます。

対処2

Cmdline リソースの check スクリプトを見直してください。


 

Q3-2-2 クラスタアプリケーショが Faulted 状態となった後、故障原因を解決し、Faulted 状態となったノードを再起動しても、クラスタアプリケーションが Faulted 状態のまま起動されない

原因

クラスタアプリケーションの PersistentFault 属が "1" に設定されているため、再起動後にFaulted 状態のままとなっている可能性があります。

対処

"PRIMECLUSTER 導入運用手引書" の "7.2.2.4 Faulted 状態のクラスタアプリケーションを運用状態にする" を参照し、Faulted 状態をクリアしてください。

再起動により、Faulted 状態がクリアされるようにしたい場合、PersistentFault 属性に "0" を設定してください。


 

Q3-2-3 NFS サーをクラスタ化しているシステムにおいて、hvdet_system プロセが大量に動作している

原因

PRIMECLUSTER の仕様です。NFS サーバ上では、リモートファイルシステムごとに Fsystem リソーを設定し、そのリソース数分ディテクタ (hvdet_system) が起動されます。これにともない、hvdet_system プロセスが複数動作することがあります。

対処

対処は不要です。


 

Q3-2-4 全ノード同時に起動または再起動を行っても、クラスタアプリケーショが起動されない

原因

RMS は、クラスタアプリケーションが1ノードでのみ Online 状態になることを保証します。

このため、RMS 起動時に、クラスタアプリケーションが動作可能なノードの RMS 同士が互いに通信しあい、起動しようとするクラスタアプリケーションがいずれのノードでも Online 状態になっていないことを確認します。

よって、クラスタアプリケーションが動作可能なノードのうち 1 つでも RMS が停止している場合は、そのノードで RMS の起動が行われても、クラスタアプリケーションがいずれのノードにおいても Online 状態になっていないことが確認されるまでは、自動起動されません。

対処

以下のいずれかの方法により対処してください。

「故障リソース特定とオペレータ介入要求」機能が設定されていない場合

syslog(/var/adm/messages)に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 番のオペレータ介入メッセージが ClusterAdmin および syslog (コンソールと /var/adm/messages) に表示されますので、該当するクラスタアプリケーションがいずれのノードでも Online 状態になっていないことを確認した上でオペレータ介入メッセージに "Yes" と応答し、クラスタアプリケーションを起動してください。

また、1423 番のオペレータ介入メッセージが表示された場合、表示されているリソースの故障が回復しているかどうかを確認の上、オペレータ介入メッセージに "Yes" と応答し、クラスタアプリケーションを起動してください。

なお、これらのメッセージに "Yes" と応答する場合は、他ノードでクラスタアプリケーションが Online となっていないことを確認の上、実施してください。

保守停止などの理由により、クラスタアプリケーションが動作可能なノードの一部を一定期間起動できない場合

RMS の HV_AUTOSTARTUP_IGNORE 環境変数に、保守停止などにより起動できないノードを設定しておくことで、クラスタアプリケーションを構成するすべてのノードで RMS が起動しなくても、クラスタアプリケーションを自動起動させることができます。詳細は、"PRIMECLUSTER RMS 導入運用手引書" を参照してください。

なお、保守停止完了後は、必ず HV_AUTOSTARTUP_IGNORE 環境変数を削除してください。この属性に設定されているノードに対しては、RMS はクラスタアプリケーションが Online 状態になっていないかの確認をしないため、一つのクラスタアプリケーションが複数のノードで Online 状態になってしまうことを RMS が抑止することができません。


 

Q3-2-5 クラスタアプリケーショにダブルフォル(二重故障)が発生した場合に、クラスタアプリケーションがフェイルオーバしない

原因1

クラスタアプリケーションの Halt 属が有効になっていない場合、ダブルフォルト(二重故障)が発生してもフェイルオーバは行いません。

対処1

ダブルフォルト(二重故障)発生時、フェイルオーバさせたい場合は、"PRIMECLUSTER 導入運用手引書"を参照して、Halt 属性を有効にしてください。

原因2

ダブルフォルト(二重故障)が発生している可能性があります。ダブルフォルトが発生した場合、クラスタアプリケーションの属性である "Halt" 属性が 0(無効)と設定されている場合、もう一方のノードからの強制停止処理が実施されないため、クラスタアプリケーションのフェイルオーバは発生ません。

対処2

ダブルフォルトが発生した原因を確認し、対処を行ってください。例えば、リソース故障が発生した場合の Offline 処理でタイムアウトが発生した場合は、タイムアウト値の見直しを行ってください。

また、ダブルフォルト発生時、フェイルオーバさせたい場合は、"PRIMECLUSTER 導入運用手引書" を参照して、Halt 属性を有効にしてください。

原因3

リソースのダブルフォルト(二重故障)発生後、シャットダウン機構によるノード強制停止が失敗している可能性があります。

シャットダウン機構によるノード強制停止が失敗した原因は、シャットダウンエージェントにSCON が設定されている可能性があります。

対処3

シャットダウンエージェントに SCON が設定されていないかどうかなど、シャットダウン機構の設定を見直して、ノード強制停止が行なえるようにしてください。


 

Q3-2-6 クラスタアプリケーショ起動時に、一部のリソースが起動されない

原因

別のクラスタアプリケーションに設定された依存関係のあるリソースが先に起動していなかったため、リソースの起動に失敗した可能性があります。

対処

依存関係のあるリソースが別々のクラスタアプリケーションに設定されている場合は、それらのクラスタアプリケーションをスケーラブル運用とするクラスタアプリケーションを作成し、起動順番を設定してください。

Oracle を使用した環境では、Oracle リソース起動前に Gls リソースが起動するよう設定が必要です。Oracle リソースと Gls リソースが別々のクラスタアプリケーションに設定されている場合は、それらのクラスタアプリケーションをスケーラブル運用するクラスタアプリケーションを作成し、起動順番を設定してください。


 

Q3-2-7 フェイルオーが発生すると、共用ディスへのアクセスを行なうプロセが強制停止される

原因

PRIMECLUSTER の仕様です。

Fsystem リソーを含むクラスタアプリケーションのフェイルオーバが発生した際、Fsystem リソースで設定したマウントポイントにアクセスしているプロセスがあると、このプロセスが強制的に停止されます。

対処

対処は不要です。


 

Q3-2-8 クラスタアプリケーショを Online へ状態遷移させたとき、Fsystem リソーで異常が発生する
また、クラスタアプリケーションを起動すると、以下の Fsystem リソースのメッセージが表示される
RMSWT <ResourceName>: WARNING: If the major/minor device numbers are not the same on all cluster hosts, clients will be required to remount the file systems

原因

CUI により Fsystem リソースを作成し、NFS マウントしているマウントポイントを指定した場合、必ず表示されますがマウントが正常に行えていれば問題はありません。

対処

システム運用管理ソフトウェアなどで、メッセージ監視を行っている場合は、WARNING で表示されるメッセージのうち、本メッセージを無視するように設定してください。


 

Q3-2-9 リソース故が発生した後、フェイルオーバ処理に異常が発生すると強制停が発生する

原因

クラスタアプリケーションの Halt 属性を有効にした環境で、ダブルフォルト(二重故障)が発生したため、シャットダウン機構により強制停止(パニックなど) が行われています。
システムの動作としては正常です。

対処

ダブルフォルト(二重故障発生時に強制停止させたくない場合は、クラスタアプリケーションのHalt 属性を無効にしてください。ただし、その場合はダブルフォルト(二重故障)発生後のフェイルオーバが行われなくなります。

なお、二重故障が発生した場合、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>).

 

Q3-2-10 クラスタアプリケーショの状態遷移に失敗した後、RCI により強制停止された形跡がある

原因

クラスタアプリケーションの状態遷移中にダブルフォルト(二重故障)が発生したため、RCI により強制停止されています。システムの動作としては正常です。

対処

ダブルフォルト(二重故障発生時に強制停止させたくない場合は、クラスタアプリケーションの Halt 属性を無効にしてください。ただし、その場合はダブルフォルト(二重故障)発生後のフェイルオーバが行われなくなります。

なお、二重故障が発生した場合、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>).

 

Q3-2-11 クラスタパーティショ発生時にリブーが行われない

原因1(Solaris の場合)

/etc/opt/SMAW/SMAWsf/SA_rccu.cfg の設定内容が誤っている可能性があります。

対処1

RCCU の IP アドレス、ユーザ名、パスワードの設定に誤りがないことを確認してください。

また、RCCU の IP アドレスに Ping が成功することも確認してください。

設定の詳細は、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。

確認事項1

/etc/opt/SMAW/SMAWsf/SA_rccu.cfg の設定内容に誤りはありませんか?

原因2(Linux の場合)

RSB の接続が行われていない可能性があります。

対処2

GLS で使用する切替方式によって RSB の接続方法が異なります。

確認事項2

RSB の接続方法が誤っていませんか?

原因3(Linux の場合)

シャットダウン機構の設定が誤っている可能性があります。

対処3

RSB の IP アドレス、ID/Password の設定値に誤りがないことを確認してください。また、RSB のIP アドレスに Ping コマンドが成功することも確認してください。

設定の詳細は、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。

確認事項3

/etc/opt/SMAW/SMAWsf/SA_rsb.cfg の設定内容に誤りはありませんか?


 

Q3-2-12 クラスタパーティショ発生時に全ノードが同時にリブーされた

原因

SF のノードの重みと RMS の shutdown priority の設定により、生存優先度が同じになっている可能性があります。

対処

SF 設定におけるノードの重み、および RMS Wizard で設定している shutdown priority の設定を確認してください。

生存優先度(SF のノードの重み +shutdown priority) の値が一致していると、両ノードが互いに相手ノードを異常と認識し、同時にリブート処理を行う場合があります。

SF のノードの重みおよび RMS の shutdown priority の設定を変更することで、クラスタパーティションが発生した場合に生存させるノードと強制停止させるノードを特定できます。

詳細は、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。

確認事項

SF のノードの重みと RMS の shutdown priority の設定を行っていますか?


 

Q3-2-13 運用中のアプリケーションが動作するノードが突然再起動される

原因1

ノード/アプリケーションの優先度付けが適切ではない状態で、クラスタインタコネクトに異常などが発生し、クラスタパーティションが発生した可能性があります。

対処1

クラスタパーティションが発生した場合、優先度が低いノードが再起動されます。ノード/アプリケーションの優先度付けを適切に設定してください。

詳細は、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。

確認事項1

クラスタインタコネクトに異常がありませんか?

原因2

クラスタアプリケーションのリソース状態で矛盾が発生している可能性があります。

対処2

Inconsistent 状態のクラスタアプリケーションが存在するノードに切替えられた場合、矛盾を解消するためノードが再起動されます。

矛盾が解消されない場合、事象ログを参照し、Inconsistent 状態のアプリケーションを正常な状態としてください。

確認事項2

Inconsistent 状態のクラスタアプリケーションはありませんか?


 

Q3-2-14 再起動後に Faulted 状態になったRMS のクラスタアプリケーションおよびリソースの故が通知されない

原因

userApplication オブジェクトの PersistentFault 属性を "yes" に変更している可能性があります。

対処

PersistentFault 属性が "yes" の場合、システム再起動後のクラスタアプリケーションおよびRMS リソースは再起動前の状態のまま起動されるため、リソースの故障は通知されません。

PersistenFault 属性を "No" にしてください。

確認事項

userApplication オブジェクトの PersistentFault 属性を "yes" に設定していませんか?


 

Q3-2-15 再起動後にRMS のクラスタアプリケーショおよびリソースがすべてFaulted状態になる

原因

userApplication オブジェクトの PersistentFault 属性を "yes" に変更している可能性があります。

対処

PersistentFault 属性が "yes" の場合、システム再起動後のクライアントアプリケーションおよび RMS リソースは、再起動前の状態のまま起動されます。

クラスタアプリケーションおよびリソースに対して Fault のクリア (hvutil -c コマンド)を実施し、Faulted 状態から Offline 状態へ遷移させてください。

確認事項

userApplication オブジェクトの PersistentFault 属性を "yes" に設定していませんか?


 

Q3-2-16 運用ノードのリブー時間が遅い

原因

RMS を停止させずにリブート処理を行ったため、リブート時間が遅くなる可能性があります。

対処

本機能は制限事項です。運用ノードを停止する場合は、必ず事前に hvswitch コマンドでクラスタアプリケーションを切替えるか、hvshut -l または hvshut -a コマンドで停止してください。

確認事項

リブート前に RMS を停止していますか?


 

Q3-2-17 RSB によるノードの強制電源が行えない

原因 1

RSB シャットダウンエージェント (/etc/opt/SMAW/SMAWsf/SA_rsb.cfg) の設定値が誤っており、RSB によるノードの強制電源断が行われない可能性があります。

対処1

RSB シャットダウンエージェントの設定を修正してください。詳細は、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。

確認事項1

RSB の IP アドレスと RSB シャットダウンエージェントの設定値 (/etc/opt/SMAW/SMAWsf/SA_rsb.cfg) に不整合はありませんか?

原因 2

RSB の電源が OFF では RSB によるノードの強制電源断が行われない可能性があります。

対処2

RSB の電源を ON にして再度強制停止を行ってください。なお、RSB の電源断を防止するため、UPS (無停電電源装置)の導入をおすすめします。

確認事項2

RSB の電源が ON になっていますか?

原因 3

RSB の IP に Ping が送れない場合、RSB によるノードの強制電源断が行われない可能性があります。

対処3

各ノードから全ノードの RSB に接続できるように LAN を設計してください。

確認事項3

全ノードから RSB の IP に Ping が送れますか?


 

Q3-2-18 Java 関 のコアダンプが採取される

原因

JavaVM の問題や JavaVM で使用するテンポラリ領域の不足によりコアダンプが採取される可能性があります。

サポートする JRE よりも古いバージョンの JRE を使用するとコアダンプが発生しやすい場合があります。

対処

適切なバージョンの JRE がインストールされているか確認し、"PRIMECLUSTER インストールガイド" を参照して、適切なバージョンの JRE をインストールしてください。

Web-Based Admin View が動作していない場合には "Web-Based Admin View 操作手引書" を参照して Web-Based Admin View を再起動してください。

確認事項

適切なバージョンの JRE がインストールされていますか?


 

Q3-2-19 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 になった

対処

コンソールに XSCF を使用した PRIMEPOWER 250,450 のクラスタシステムでは、RCI を使用したシャットダウンエージェント 2 つ RCI(Panic, Reset) と、XSCF を使用したシャットダウンエージェント XSCF(Console Break) の、合計 3 つだけを設定してください。設定方法は以下のとおりです。

シャットダウン構成ウィザードを起動し、「簡単な設定(推奨)」からシャットダウン機構を設定してください。その際、使用するシャットダウンエージェントとして以下を選択してください。

また、Console Break エージェントとして以下を選択してください。

シャットダウン構成ウィザードの操作方法については、"PRIMECLUSTER 導入運用手引書" の "5.1.2 シャットダウン機構の設定" を参照してください。その際、使用するシャットダウンエージェントについては、上記のように読み替えてください。

4.1A20 パッチ913381-04 以降または4.1A30 パッチ913897-01 以降が適用されている、または、4.1A40以降では、本現象は発生しません。

確認事項

シャットダウンエージェントの設定は正しいですか?


 

Q3-2-20 以下のメッセージが表示され、リソース故となる
NOTICE: failed to open device "<DeviceName>" with errno 6

原因 1

Fsystem リソーで設定しているマウントポイントが、他のアプリケーションで使用されている。

対処 1

マウントポイントを使用しているアプリケーションを特定し、アプリケーションからマウントポイントを使用しないようにするなどの対処を検討してください。

Fsystem リソース異常の原因と対処については、Q3-2-50 も参照してください。

原因 2

GDS で管理しているディスクに対して、Fsystem リソースを作成し、Fsystem リソースで使用している共用ディスクに対して、ファイルシステムを作成していない。

対処 2

"PRIMECLUSTER 導入運用手引書" を参照し、ファイルシステムの設定を行ってください。


 

Q3-2-21 Scalable コントローを使用した環境にて、クラスタアプリケーションの OnlinePriority 属を設定しているにもかかわらず、有効にならない

説明

Scalable コントローラを使用してクラスタアプリケーションを構築した場合は、OnlinePriority 属性は有効になりません。PRIMECLUSTER の仕様動作となります。


 

Q3-2-22 運用中に以下のメッセージが出力される
WARNING: doopenread of"/dev/sfdsk/class0001/rdsk/smaf01-AP" (pid 5970), counter=1 not done yet reporting status, waiting ...

対処

以下の 3 通りの変更にて WARNING メッセージの出力を抑止、または、WARNING メッセージが出力し続けることでの切替えを抑止することが可能です。(必ずしも WARNING メッセージが出力されなくなるわけではありません。)

また、すべてが変更可能ですが、必ずしもすべてを変更する必要はありません。

各種内容を踏まえて変更を実施してください。

  1. RMS 環境変数 HV_GMOUNTMAXLOOP の値を変更する。
  2. RMS 環境変数 HV_GMOUNTMAXRETRY の値を変更する。
  3. Fsystem リソースが行っているマウントポイントへの監視間隔を変更する。

各種設定値を変更する場合は、以下の手順で行います。

1. HV_GMOUNTMAXLOOP, HV_GMOUNTMAXRETRY の変更方法

※手順 2、3 に関しては、すべてのノードで実施してください。

  1. すべてのノードの RMS を停止します。

    RMS の停止方法は、"PRIMECLUSTER 導入運用手引書" の "7.2.1 RMS の運用操作"を参照してください。

  2. /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
  3. hvenv コマンドで "HV_GMOUNTMAXLOOP= 値" , "HV_GMOUNTMAXRETRY= 値" が表示されることを確認します。

    例)

    # hvenv | grep HV_GMOUNTMAXLOOP
    HV_GMOUNTMAXLOOP='10' export HV_GMOUNTMAXLOOP;
    # hvenv | grep HV_GMOUNTMAXRETRY
    HV_GMOUNTMAXRETRY='10' export HV_GMOUNTMAXRETRY;

    "HV_GMOUNTMAXLOOP= 値" , "HV_GMOUNTMAXRETRY= 値" が表示されない場合、手順 2 の作業に誤りがある可能性がありますので、手順 2 の作業を見直してください。

  4. すべてのノードの RMS を起動します

    RMS の起動方法は、"PRIMECLUSTER 導入運用手引書" の "RMS の運用操作" を参照してください。

2. Fsystem リソーの監視間隔の変更方法

  1. すべてのノードの RMS を停止します。

    RMS の停止方法は、"PRIMECLUSTER 導入運用手引書" の "7.2.1 RMS の運用操作" を参照してください。

  2. Web-Based Admin View から "Global Cluster Services" - "userApplication Configuration Wizard" を選択します。
  3. "Configuration 内の共通情報を設定" を選択します。
  4. "Detector の詳細設定" を選択します。
  5. "hvdet_gmount のリソース監視間隔 =10" を選択します。
  6. "情報の入力"を選択し、変更する監視間隔を入力します。
  7. hvdet_gmount のリソース監視間隔が変更した値になっていることを確認し、"戻る" を選択します。
  8. "保存して登録" を選択し、"登録" を実行します。

    ※その後メッセージがポップアップされますが、すべて"はい"を選択してください。

  9. すべてのノードの RMS を起動します。

    RMSの起動方法は、"PRIMECLUSTER 導入運用手引書" の "7.2.1 RMS の運用操作" を参照してください。

なお、各種設定値変更に関して、以下の点に注意してください。


 

Q3-2-23 userApplication の起動および切替えができない

原因 1

Cmdline リソースの Online スクリプト、Offline スクリプト、Check スクリプに誤りがある可能性があります。

対処 1

Cmdline リソースの Online スクリプト、Offline スクリプト、Check スクリプトを見直し、正常に動作できるか確認してください。また実行するコマンドの実行権限やグループ権限もあわせて確認してください。

原因 2

iptablesの設定で、クラスタのノード間通信を行うインタフェース(cip0)の通信または、クラスタリソース管理機構で使用するポートを送信先のみ許可し、送信元を許可していない可能性があります。

対処 2

インタフェース(cip0)の通信およびクラスタリソース管理機構で使用するポートの通信を許可するように iptablesの設定を見直してください。


 

Q3-2-24 引継ぎネットワークリソーを作成し、業務 LAN に引継ぎ IP アドレを 設定した環境で、業務 LAN ケーブルを抜いてもリソース故障が発生しない

原因

引継ぎネットワークリソースを作成した際に、PingHost を設定していない場合、ケーブルを抜いても引継ぎネットワークリソースは異常になりません。

対処

業務 LAN の監視を行いたい場合は、GLS を使用してください。

GLS を使用しない場合は、引継ぎネットワークリソースを作成した際に、PingHost の設定を行ってください。


 

Q3-2-25 Online/Standby 運用時、Cmdline リソーのスクリプが実行されると HV_LAST_DET_REPORT 環境変数が standby ではなく、Offline となる

原因

Cmdline リソースの属性 "STANDBYCAPABLE 属"、"ALLEXITCODES 属" が有効になっていない可能性があります。

対処

Standby 状態とする場合は、Cmdline リソースの属性 "STANDBYCAPABLE 属性" と "ALLEXITCODES 属性" を有効にしてください。


 

Q3-2-26 userApplication Configuration Wizard で引継ぎネットワークリソーを作成中に「0880 未分類のエラーが発生しました。」のメッセージが表示される

対処

全クラスタノードの /etc/inet/hosts ファイルの IP アドレやホスト名の記述に誤りがないか確認してください。記述に誤りがある場合は修正してください。

/etc/inet/hosts ファイルの修正後、userApplication Configuration Wizard を一旦終了し、再度 userApplication Configuration Wizard を起動して、引継ぎネットワークリソースを作成してください。


 

Q3-2-27 "255.255.254.0" と設定されたネットマスクが "255.255.0.0" に変わってしまった

意味

仮想インタフェースに設定したネットワークインタフェースに対してのネットマスク値の設定がなかったために、IP アドレスのデフォルトのサブネットマスク値に設定変更が行われたと考えられます。

対処

PRIMECLUSTER Global Link Service のサブネットマスクの設定において、仮想インタフェースの作成で設定した仮想インタフェースに対するサブネットマスクの設定を行ってください。


 

Q3-2-28 リソース故が発生しましたというメッセージが出力され、クラスタが切り替わった

原因

Fsystem リソーで監視しているマウントポイント名が、リネームされた可能性があります。

対処

Fsystem リソースで監視しているマウントポイント名が正しいか確認してください。


 

Q3-2-29 リソース故が発生した後、ノードがパニッする場合としない場合がある

原因

リソース故障が発生すると、フェイルオーバ処理が行なわれます。そのフェイルオーバ処理でエラーが発生した場合は、ダブルフォルト(二重故障)となり、ノードがパニックします。

対処

フェイルオーバ処理でエラーが発生していないかどうか確認してください。

ノードがパニックする場合、Q3-2-11 を参照してください。


 

Q3-2-30 クラスタアプリケーションに登録している Oracle リソースを削除すると、共用ディスのファイルシステムがマウントできなくなった

原因

Oracle リソースを削除する際に、Oracle リソース配下のリソースも削除するかを確認する 0808 番のメッセージで "はい" を選択したため、Fsystem リソーも削除されています。

対処

Fsystem リソースを再作成してください。


 

Q3-2-31 切替え動作中に強制的なファイルシステムチェックの ERROR メッセージが出力され、切替えが失敗する

原因

切替ファイルシステに ext3 を使用している場合、Online 処理時に強制的なファイルシステムチェック (fsck) が実行されることがあります。両ノード起動時や切替え時などに強制的な fsck が実行されると、切替ファイルシステムのオンライン処理でタイムアウトが発生し、PRIMECLUSTER の起動や切替えに失敗することがあります。PRIMECLUSTER の仕様です。(Linux のみ)

対処

すべての ext3 切替ファイルシステムで、強制ファイルシステムチェックが実行されないように設定してください。設定方法の詳細については、"PRIMECLUSTER 活用ガイド<クラスタ構築・運用時の留意点>を参照してください。ただし、強制ファイルシステムチェックを回避すると、ファイルシステム破壊が発生した場合に、発見が遅れるため、データ損失の危険性が高まります。

そのため、手動でファイルシステムの強制チェック (fsck -f) を実行して、データ損失の危険性を回避する必要があります。


 

Q3-2-32 IO 負の WARNING が出力される

原因

Fsystem リソーのマウントポイントに対するチェックが監視時間内に完了しなかったため、メッセージが表示されています。

対処

RMS の構成定義に登録したマウントポイントに対する、マウントポイント監視時間のチューニングを実施してください。詳細は"Linux PRIMECLUSTER 構築ガイド"を参照してください。


 

Q3-2-33 ユーザ独自のアプリケーションを起動しようとすると、ノードがパニッしてしまう

原因

アプリケーション起動時に、RMS で使用しているメッセージキューを削除している可能性があります。

対処

RMS で使用しているメッセージキューを削除しないようにアプリケーション側で調整してください。


 

Q3-2-34 GUI 画面にて、1422 番のオペレータ介入要求メッセージに応答した際に/var/adm/messages ファイルに出力される 2621 番のメッセージが文字化けする

原因

Web-Based Admin View が動作する言語環境が(syslang)が "ja" になっており、/var/adm/messages ファイルに EUC で出力されるが、表示させる端末の言語設定が EUC 以外になっているためです。

対処

表示させる端末の言語設定を EUC に設定してください。


 

Q3-2-35 運用系において telnet も受け付けられず、DB にもアクセスできない状態にも関わらず、系切替えが行われない

原因

運用系の RSB の IP アドレスが変更されていて、運用系をシャットダウンできなかったために、系切替えが行なえない可能性があります。

対処

運用系の RSB の IP アドレスと、RSB シャットダウンエージェントの設定で行った値を一致させてください。


 

Q3-2-36 シャットダウン機に関する以下のメッセージが出力された
    can't bind local address, errno 126

原因

シャットダウン機構の admIP 設定時に存在しない IP アドレスが設定されています。

対処

admIP には業務 LAN の IP アドレスを設定してください。


 

Q3-2-37 クラスタ運用中に /etc/vfstab を修正して共用ディスクをアンマウントしたら、パニッ が発生した

原因

/etc/vfstabを/etc/vfstab(Solaris)、または /etc/fstab(Linux) から Fsystem リソースが使用しているマウントポイントを削除したため、リソース故障が発生し、パニックが発生した可能性があります。

対処

運用中に /etc/vfstab を /etc/vfstab(Solaris),または /etc/fstab(Linux) の MountPoint***_Fsystem* リソースが使用するマウントポイントを修正しないでください。


 

Q3-2-38 /tmp 配下に巨大なファイルを作成したノードで パニッが発生した

原因

メモリ資源、およびスワップ資源を圧迫し、他ノードからのハートビートに応答できなかった可能性があります。

対処

メモリ枯渇となる可能性がありますので、/tmp に巨大なファイルを作成しないでください。


 

Q3-2-39 定期保守実施後、システムを起動してRMSを自動起動させたが、Gls リソーが Standby に遷移できなかったために、RMS が正常に起動できなかった

原因

DNS サーバと通信することができなかったために、GLS 内部の名前-アドレス変換処理に時間がかかり、Gls リソースをタイムアウ時間内に、"STANDBY" に遷移させることができなかった可能性があります。

対処

Gls リソースのタイムアウト時間を変更するか、HUB 監視先ホストの指定を IP アドレスに変更してください。または HUB 監視先ホストの変更に加えて、引継ぎホストの設定も IP アドレスに変更してください。


 

Q3-2-40 hostname コマンを実行すると、両ノードで同じ結果が出力される

原因

引継ぎネットワークリソースにて、ノード名引継ぎの設定が行われているため、hostname コマンドの出力結果が両ノード同一となります。

対処

ノード名引継ぎが不要であれば、IP アドレス引継ぎのみに設定を変更してください。


 

Q3-2-41 引継ぎネットワークリソーが異常となり、切替えが発生したが、切替え先でも同様となり、システムが停止した

原因

引継ぎネットワークリソースにて指定されている PingHost 先のホストが ping 応答を返せない状態である可能性があります。

対処

PingHost 先のホスト状態を確認してください。


 

Q3-2-42 クラスタインタコネクが全パス切断された場合に、ダンプが採取できないノードがある

原因

SA_rsb の状態が TestFailed になっており、RSB が正常動作していないことからダンプ採取命令が行われても RSB が命令を受信できなかったためにダンプが採取されていない可能性があります。

対処

RSB を再設定し、ping または telnet できることを確認してください。また、SA_rsb.cfg の設定についても同様の設定にしてください。


 

Q3-2-43 Gds リソーを使用しているクラスタアプリケーションがエラーで停止した。復旧作業のため、共用ディス上のファイルシステムをマウントしたい

対処

GDS のボリュームは非活性状態となっておりアクセスできません。GDS のボリュームを起動後、ファイルシステムをマウントし、復旧作業を行ってください。手順は以下のとおりです。

  1. 全ノード RMS の停止

    以下のコマンドをクラスタを構成するいずれかのノードで実行し、全ノードの RMS を停止します。

     # hvshut -a
  2. GDS ボリュームの起動

    復旧作業が必要なデータが格納されている、GDS のボリュームを起動してください。

    GDS 運用管理画面より該当のボリュームを選択し、ボリューム起動を実行してください。

  3. ファイルシステムのマウント

    手順 2. で起動した GDS ボリュームのファイルシステムをマウントします。

    GFS ファイルシステムを使用している場合は、以下のようにマウントを行ってください。

     # mount -F sfxfs /dev/sfdsk/class0001/dsk/volume0001 マウントポイント
  4. データの復旧作業を行ってください。
  5. 手順 3. でマウントしたファイルシステムをアンマウントしてください。
  6. GDS ボリュームの停止

    手順 2. で起動した GDS ボリュームの停止を行ってください。

    GDS 運用管理画面より該当のボリュームを選択し、ボリューム停止を実行してください。

  7. 以下のコマンドをクラスタを構成するいずれかのノードで実行し、全ノードの RMS を起動します。

    # hvcm -a


 

Q3-2-44 共用ディスとサーバを接続する FC カーが故障し、フェイルオーバが発生した

対処

以下の手順で復旧を行なってください。

[全ノード停止が必要な場合]

  1. クラスタを構成する全ノードの RMS を停止します。
      # hvshut -a
  2. 全ノードを停止します。
      # shutdown -h now
  3. FC カードを交換します。
  4. 交換が終わったら、起動します。
  5. userApplication の状態が Faulted になっているノードで以下のコマンドを実行してください。
      # hvutil -c アプリケーション名

[該当ノードの停止で十分な場合]

  1. 該当ノードにて RMS を停止します。
      # hvshut -l
  2. 該当ノードを停止します。
      # shutdown -h now
  3. FC カードを交換します。
  4. 交換が終わったら、起動します。
  5. 起動したノードにて、Faulted になった userApplication に対して以下のコマンドを実行してください。
      # hvutil -c アプリケーション名

 

Q3-2-45 Cmdline リソーに登録したシェルスクリプの出力がコンソーに出力されない

原因

Cmdline リソースに登録した StartCommand および StopCommand の標準出力、標準エラー出力は、RELIANT_LOG_PATH (デフォルト :/var/opt/SMAWRrms/log) 配下の userAplication 名.log ファイルに書き出されるため、コンソールに出力されません。CheckCommand については、標準出力、標準エラーともにどこにも書き出されないため、コンソールに出力されません。

対処

PRMECLUSTER では、Cmdline リソースに登録されたシェルスクリプトの出力をコンソールに出力する設定はないため、コンソールに実行結果を出力するようなシェルスクリプトを作成してください。


 

Q3-2-46 クラスタアプリケーションの Maintenance モーを解除した際に、Cmdline リソースが Online にもかかわらず、再度起動処理が行われる

原因

該当する Cmdline リソースには NULLDETECTOR が設定されている可能性があります。NULLDETECTOR が設定されている Cmdline リソースがクラスタアプリケーションの Maintenance モード解除時に再度起動処理が行われる動作は仕様動作です。

対処

Cmdline リソースが Online 状態で、再度起動処理が行われた場合に、二重起動とならないよう該当する Cmdline リソースに登録されているスクリプトを修正してください。


 

Q3-2-47 PRIMECLUSTER を使用したシステムでアプリケーションを一切動作させていない状況で 10 分間隔で sar の %wio 値が高くなる

原因

シャットダウン機構が定期的にログを出力しているため、sar コマンの %wio の値が高く表示されています。

対処

現行のノード監視を行ったまま、ログを削減/抑止する方法はありません。


 

Q3-2-48 フェイルオーを発生させると、Standby 型の userApplication が 2 回 Online となり、Cmdline リソースから呼ばれるアプリケーションが二重起動でエラーとなる

原因

Scalable Controller を含む userApplication と、その配下にある Standby 型のuserApplication を同時にフェイルオーバさせると、Standby 型の userApplicationが 2 回 Online となります。(PRIMECLUSTER の正常な動作です。)

NULLDETECTOR フラグを設定した Cmdline リソースは Check スクリプを持たず、実際のリソース状態を RMS 側で判断できないため、二重起動となる場合があります。

対処

NULLDETECTOR フラグを設定した Cmdline リソースの二重起動による Online 処理の失敗を避けるには、Online スクリプトを改造することで対応できます。

具体的には、以下の処理を追加します。

  1. 対象プログラムを起動する前に、すでに対象プログラムが動作中でないかを Online スクリプト内でチェックする。
  2. すでに対象プログラムが動作中の場合は、直ちに Online スクリプトを正常終了させる。

 

Q3-2-49 クラスタのRMS起動処理後に Fsystem に異常が発生し、待機系へ状態遷移した

原因

mount コマンドや fsck コマンドが失敗する原因で現象が発生しますが、特によく発生する原因は以下のとおりです。

  1. マウント情報のファイル (Solaris は /etc/vfstab, Linux は /etc/fstab) に誤りがある。
  2. ファイルシステムが GDS のボリューム上にあるにもかかわらず、ボリュームが起動されていないため、ファイルシステムにアクセスでず mount コマンドがエラーとなっている。
  3. ファイルシステムが作成されていない場合。
  4. fsck コマンドによりファイルシステムの復旧を試みたが、fsck コマンドは復旧不可能と判断し、エラー復帰した場合。
  5. fsck コマンドの復旧処理に時間を要したために Fsystem リソースの Online 処理のタイムアウトにより fsck が中断した場合。
  6. /etc/dfs/dfstab の設定に誤りがある場合。(Solaris のみ)
  7. 他のアプリケーションがマウントポイントを使用している場合。

対処

各原因に対する対処方法は以下のとおりです。

  1. 以下の観点でマウント情報のファイルを見直ししてください。
  2. 以下の観点で GDS リソースに関する設定を見直ししてください。
  3. マウントするデバイス上にファイルシステムを作成してください。
  4. 手動で fsck コマンドを実行し、ファイルシステムの復旧が可能かを確認します。復旧できない場合は、ファイルシステムを再作成し、データを復旧します。
  5. fsck コマンドでファイルシステムの復旧を手動で行い、実際に要した時間計測します。その後、Fsystem リソースの Timeout 時間に計測した時間を追加してください。
  6. 以下の観点でマウント情報のファイルを見直ししてください。
  7. 他のアプリケーションがマウントポイントを使用している場合は、そのアプリケーションでマウントポイントを使用するのをやめるか、アプリケーションを終了してください。

 

Q3-2-50 運用中に RMS の (SYS, 88) のメッセージが表示される

原因

以下のいずれかの原因で、<time> 秒以上たっても応答がないためメッセージか表示されています。

対処

要因に従って以下の対処を行ってください。


 

Q3-2-51 サブシステムハンによって業務が停止した

原因

運用ノード内の一部の I/O だけが異常になっているために、業務が停止している可能性があります。

一部の I/O だけが異常でその他の I/O が正常のため、クラスタシステムが異常事象を検知していない場合(クラスタシステムの監視からは正常に見えている場合)を、サブシステムハングと呼びます。

対処

待機ノードに切り替わることによって業務再開の見込みがあるため、以下の対処を実施してください。


 

Q3-2-52 クラスタノードが起動しているにもかかわらず、Cluster Admin の CRM メインウィンドでクラスタノードが 起動状態 (緑色のアイコン)にならない

対処

Cluster Admin を終了し、Web-Based Admin View 画面の Global Cluster Services メニューから、再度 Cluster Admin を起動してください。

Cluster Admin が起動した後、CRM ウィンドウを表示しクラスタノードの起動状態を確認してください。

Cluster Admin を再起動しても同様の現象が頻繁に発生する場合は、当社技術員 (SE) に連絡してください。

確認事項

Cluster Admin の CF ウィンドウで、該当のクラスタノードが起動状態 (緑色のアイコン)で表示されていますか?


 

Q3-2-53 運用中に 7210 のメッセージが表示される
An error was detected in MMB. (node:nodename mmb_ipaddress1:mmb_ipaddress1
mmb_ipaddress2:mmb_ipaddress2 node_ipaddress1:node_ipaddress1
node_ipaddress2:node_ipaddress2 status:status detail:detail)

原因

MMB からの応答がないためメッセージか表示されていると考えられます。

対処

以下の要因が考えられます。要因に従って対処を行ってください。


 

Q3-2-54 クラスタアプリケーションを Online へ遷移させたとき、以下のメッセージが表示され状態遷移プロシジャリソースで異常が発生する。
FJSVcluster: ERROR: clexecproc: 6817: An error occurred during state transition procedure execution.(error procedure:procedure detail:code1-code2-code3-code4-code5-code6-code7)

原因

状態遷移プロシジャ内で標準出力または標準エラーにメッセージを出力しようとしたため、状態遷移プロシジャが異常終了した可能性があります。

状態遷移プロシジャ内では echo(1) コマンドなどで標準出力および標準エラー出力にメッセージを出力することはできません。

対処

状態遷移プロシジャの動作状態を確認する場合は、リダイレクションを使用して自製品のログファイルに出力してください。


 

Q3-2-55 現象1:シャットダウン時に「clonltrc: ERROR: Module clonltrc is in use」のメッセージが出力される
現象2:システム起動時に「rc: Starting clonltrc: failed」のメッセージが出力される

原因

対処

  1. 現象1と現象2が発生した場合

    シングルユーザモードからマルチユーザモードに移行した場合、必ずシステム再起動の操作 (例: shutdown -r now) によりマルチユーザモードに移行するようにしてください。

  2. 現象1のみ発生した場合(シングルユーザモードに移行した場合)

    本メッセージが出力されるだけで動作に問題ありません。マルチユーザモードに移行する場合は、必ずシステム再起動の操作 (例: shutdown -r now) によりマルチユーザモードに移行するようにしてください。

  3. 現象1のみ発生した場合(通常のシャットダウンまたはシステム再起動の場合)

    対処の必要はありません。本メッセージが出力されるだけで動作に問題ありません。

  4. 上記以外が発生する場合は、当社技術員に連絡してください。

 

Q3-2-56 ノード故障が発生していないにもかかわらず、ノード故障を通知する以下のメッセージが表示される
"FJSVcluster: エラー: claddfaultrsc: 6751: SysNode 故障が発生しました"

原因

全ノードが停止した状態から1ノードのみ起動させた場合に、本メッセージが表示される場合があります。

対処

オペレータに他ノードが停止しているという注意を喚起するために表示されるメッセージであり、実際にノード故障が発生していないのであれば、特に対処を行う必要はありません。


 

Q3-2-57 PersistentFault 属性を 1(Yes) に設定しているにもかかわらず、userApplication が起動時 Faulted にならない

原因

以下の条件をすべて満たす場合、PersistentFault 属性に 1 が設定されていても、userApplication は起動時 Faulted になりません。

  1. ノードの FC ケーブルをすべて抜く。
  2. I/O エラー検出後 Faulted に遷移する前に、PRIMECLUSTER 以外の製品の処理でノードがパニックしリブートする。
  3. 共有ディスク接続確認 (*1) により RMS の起動が抑止される(FC ケーブルは抜けたままの状態)。
  4. FC ケーブルを差し戻し、再度リブートする。

FC ケーブル抜けなど共有ディスク接続確認において故障が検出された場合、PersistentFault 属性が機能し userApplication を Faulted にするより前に、共用ディスク接続確認が故障を通知し、RMS の起動を抑止します。
このため、故障から復旧し RMS が起動できる状態になった後に、あらためて故障を通知し、userApplication 起動の抑止を行う必要がないため、userApplication を Faulted にしていません。

(*1)共有ディスク装置接続確認の設定については、PRIMECLUSTER 導入運用手引書(Solaris(TM) オペレーティングシステム版)の、「5.3 共用ディスク装置接続確認の設定」を参照してください。

対処

不要です。


 

Q3-2-58 hvlogcleanコマンドを実行した際に以下のメッセージがsyslog、およびCluster Adminに出力される
clwatchlogd: FJSVcluster: ERROR: exec_chg_line: 6000: An internal error occurred. (function:fopen detail:0x30000071-0x2-0-0xffff)

原因

hvlogcleanコマンドを実行した際に、RMSのログファイルが一時的に参照できなくなった可能性があります。

対処

不要です。


 

Q3-2-59 状態遷移中にリソース故障が発生した場合、Faultedのクリア操作を行っていなくても以下のメッセージが出力されることがある
cldelfaultrsc: FJSVcluster: INFO: cldelfaultrsc: 2700: The resource fail has recovered.SysNode:SysNode userApplication:userApplication Resorce:resource

対処

hvdispコマンド、または ClusterAdminのRMSタブでリソースの状態を確認し、Faultedのクリア操作を行ってください。


 

Q3-2-60 ネットワークカード交換後、ネットワークがアップしない

原因

ネットワーク定義ファイル (ifcfg-ethx)のMACアドレスを修正していないことが考えられます。

対処

ifcfg-ethxのMACアドレスを修正してください。


 

Q3-2-61 富士通 MW の PRIMECLUSTER 対応製品において、状態遷移プロシジャからプロセス監視を使用せずにプロセスを起動する場合、そのプロセスのファイルディスクリプタ(fd)がハード/ソフトリミット共に 1024 となる

原因

PRIMECLUSTERの状態遷移プロシジャでは、PRIMECLUSTERの資源を引き継いでプロセスが起動されるため、ファイルディスクリプタ(fd)のハード/ソフトリミットが共に1024となります。

対処

以下の手順で対処を行なってください。

本手順はApplicationクラスの状態遷移プロシジャproc.shを変更する場合の手順です。クラスや状態遷移プロシジャ名は環境に合わせて変更し実施してください。
  1. すべてのノードのRMSを停止します。
    以下のコマンドをクラスタを構成するいずれかのノードで実行し、すべてのノードのRMSを停止します。
    # hvshut -a
    
  2. 一時ディレクトリに移動し、状態遷移プロシジャを取り出します。

    例)一時ディレクトリ/tmpに状態遷移プロシジャproc.shを取り出す場合

    # cd /tmp
    # /etc/opt/FJSVcluster/bin/clgetproc -c Application proc.sh
    
  3. 取り出した状態遷移プロシジャを編集します。
    状態遷移プロシジャの処理の先頭に"ulimit"の定義を追加し、ファイルディスクリプタの最大値を指定します。"ulimit"で指定する値は、その環境で必要な値を設定してください。

    例) ファイルディスクリプタの最大値を4096に設定する場合

    # vi proc.sh

    #!/bin/sh

    ulimit -n 4096

    ・・・


  4. 編集した状態遷移プロシジャを登録します。
    # /etc/opt/FJSVcluster/bin/clsetproc -c Application -o proc.sh
    
  5. 状態遷移プロシジャを登録しているすべてのノードで 2.~4.の手順を実施します。
  6. RMSを起動します。
    以下のコマンドをクラスタを構成するいずれかのノードで実行し、すべてのノードのRMSを起動します。
    # hvcm -a

 

Q3-2-62 運用系でシステム停止中に、以下のエラーメッセージが出力された
cldelmsg: FJSVcluster: ERROR: cldelmsg: 6000: An internal error occurred. (function:_ClExecGetNode detail:0x300a0006-0xfffffff4-0-0)

原因

クラスタシステム全体としての切替処理が完了する前に、相手ノードでシャットダウン処理が開始された可能性があります。

対処

切替処理が完了してから shutdown を実施してください。


目次 索引 前ページ次ページ

All Rights Reserved, Copyright(C) 富士通株式会社 2009