FUJITSU Software

PRIMECLUSTER

RMS 導入運用手引書 4.5

Oracle Solaris / Linux

J2S2-1687-03Z0(00)
2018年8月
はじめに
本書では、RMSウィザードを使用したRMSの構成や、Cluster Admin GUI でRMSを管理するための、Reliant(R) Monitor Services (RMS)
の機能について説明します。RMSは、クラスタのノード上で動作するアプリケーションに対して、システムレベルの高可用性を保証する
ソフトウェアモニタです。

本書の読者
本書は、PRIMECLUSTER 4.5を使用して、クラスタシステムの導入・運用管理を行う、すべてのユーザを対象にしています。

本書について
本書の構成は以下のとおりです。

章タイトル 内容
第1章 概要 RMSの概要とPRIMECLUSTER製品について紹介しています。
第2章 RMSの詳細説明 RMSにおける状態検出と状態遷移の処理について説明します。
第3章 RMS Wizard Toolsインタフェース (hvw) の使用 RMSウィザードを使用してRMSを構成設定する方法について説明しま
方法 す。
第4章 構成変更の例 RMS ウィザードを使用してクラスタアプリケーションの構成を変更する手
順の例について説明します。
第5章 Cluster Admin GUIの使用方法 Cluster Adminの起動方法と、 Cluster Adminを使用したRMSの状態と
属性の表示方法について説明します。
第6章 その他の管理ツール Cluster Adminを使用した、RMSクラスタテーブル、RMSグラフ、ログ
ビューアについて説明します。
第7章 RMSの操作 Cluster Admin GUIから使用できる主なRMS管理機能と、そのCLIから
の使用手順について説明します。
付録A 事前準備 RMS操作に必要なネットワーク、およびファイル設定について説明しま
す。
付録B 状態 RMSで提供されるオブジェクトの状態を示します。
付録C オブジェクトタイプ RMSで提供されるすべてのオブジェクトタイプを示します。
付録D 属性 各オブジェクトタイプに対して指定する必要がある属性を示します。
付録E 環境変数 RMS環境変数について説明します。
付録F トラブルシューティング RMS のトラブルシューティングについて説明し、そのエラーメッセージ、
エラーの原因、および解決方法を示します。
付録G RMSコマンドラインインタフェース RMS管理CLIコマンドを示します。
付録H リリース情報 本マニュアルの主な変更内容について説明します。

関連マニュアル
以下のマニュアルは、クラスタ設定を行う際に必要に応じて参照してください。

・ PRIMECLUSTER コンセプトガイド
・ PRIMECLUSTER 導入運用手引書
・ PRIMECLUSTER 導入運用手引書＜FUJITSU Cloud Service K5環境編＞
・ PRIMECLUSTER Web-Based Admin View 操作手引書
・ PRIMECLUSTER Cluster Foundation 導入運用手引書
・ PRIMECLUSTER Global Disk Services 説明書
・ PRIMECLUSTER Global File Services 説明書

-i-
 ・ PRIMECLUSTER Global Link Services 説明書 (伝送路二重化機能編)
・ PRIMECLUSTER Global Link Services 説明書 (伝送路二重化機能 仮想NIC方式編)
・ PRIMECLUSTER Global Link Services 説明書 (マルチパス機能編)
・ PRIMECLUSTER DR/PCI Hot Plug ユーザーズガイド
・ PRIMECLUSTER 活用ガイド＜トラブルシューティング編＞
・ PRIMECLUSTER 活用ガイド＜メッセージ集＞
・ PRIMECLUSTER 活用ガイド＜コマンドリファレンス編＞
・ PRIMECLUSTER かんたん設計構築ガイド
・ FJQSS (資料採取ツール) ユーザーズガイド
・ PRIMECLUSTER Wizard for Oracle 導入運用手引書
・ PRIMECLUSTER Wizard for NAS 導入運用手引書
・ PRIMECLUSTER Wizard for NetWorker 導入運用手引書
・ PRIMECLUSTER Wizard for NetVault 導入運用手引書

注意
PRIMECLUSTERの関連ドキュメントには上記マニュアル以外に以下のドキュメントがあります。

・ PRIMECLUSTER ソフトウェア説明書/インストールガイド
PRIMECLUSTERの各製品に添付されるソフトウェア説明書およびインストールガイドです。
データは各製品の“DVD”に格納されています。また、ファイル名については、「製品のご案内」を参照ください。

本書の表記について
表記
以下の表記規則があります。
プロンプト
実行にシステム管理者 (ルート) 権限が必要なコマンドライン例の場合、先頭にシステム管理者プロンプトを示すハッシュ記号 (#) が付
いています。いくつかの例で、<nodename># という表記は、指定されたノードのrootプロンプトを表しています。たとえば、コマンド名
の前にfuji2#が記述されていると、そのコマンドがfuji2という名前のノード上で、rootユーザとして実行されたことを示しています。シ
ステム管理者権限を必要としないエントリの場合、先頭にドル記号 ($) が付いています。
マニュアルページのセクション番号
オペレーティングシステムコマンドの後ろにマニュアルページのセクション番号が括弧付きで示されています。
- 例: cp(1)
キーボード
印字されない文字のキーストロークは＜Enter＞や＜F1＞などのキーアイコンで表示されます。
たとえば、＜Enter＞はEnterというラベルの付いたキーを押すことを意味し、＜Ctrl＞+＜B＞はCtrlまたはControlというラベルの付
いたキーを押しながら＜B＞キーを押すことを意味します。
書体/記号
以下の書体は特定要素の強調に使用されます。

書体 / 記号 使用方法
均等幅 コンピュータ出力、およびプログラムリスト: テキスト本文中のコマンド、ファイル名、マニュ
アルページ名、他のリテラルプログラミング項目
斜体, <斜体> 具体的な数値/文字列に置き換える必要のある変数 ―入力値―

- ii -
 書体 / 記号 使用方法
<均等幅> 具体的な数値/文字列に置き換える必要のある変数 ―表示値―
太字 記述どおりに入力する必要のあるコマンドライン項目
“均等幅” 参照先のタイトル名、マニュアル名、画面名等
[均等幅] ツールバー名、メニュー名、コマンド名、アイコン名
＜均等幅＞ ボタン名

書体規則の例を以下に示します。
例1
以下に/etc/passwdファイルのエントリの一部を示します。

root:x:0:1:0000-Admin(0000):/:
sysadm:x:0:0:System Admin.:/usr/admin:/usr/sbin/sysadm
setup:x:0:0:System Setup:/usr/admin:/usr/sbin/setup
daemon:x:1:1:0000-Admin(0000):/:

例2
cat(1) コマンドでファイルの内容を表示するには、以下のコマンドラインを入力します。

$ cat ＜ファイル名＞

コマンド構文
コマンド構文には以下の規則があります。

記号 名前 意味
[] 角括弧 オプション項目を囲む。
{} 波括弧 択一選択の複数選択肢を囲む。各項目は縦線 (|) で区切られる。
| 縦線 波括弧で囲まれている場合は、択一選択の各選択肢の区切り。波括弧で囲ま
れていない場合は、1つのプログラムの出力が他のプログラムの入力にパイプさ
れることを示すリテラル要素。
() 丸括弧 繰り返しの際にグループ化される項目を囲む。
... 省略符号 項目の繰り返しを示す。1グループの項目を繰り返す場合には、項目グループを
丸括弧で囲む。

記号
特に注意すべき事項の前には以下の記号が付いています。

ポイント
ポイントとなる内容について説明します。

注意
注意する項目について説明します。

例
例題を用いて説明します。

- iii -
 参考
参考となる内容を説明します。

参照
参照するマニュアル名などを説明します。

略称
Oracle Solarisは、Solaris、Solaris Operating System、またはSolaris OSと記載することがあります。
参照するOracle Solaris ( 以降、Solaris) のマニュアル名称で"Solaris X" と書かれている部分は、Oracle Solaris 10 ( 以降、Solaris
10) 、またはOracle Solaris 11 ( 以降、Solaris 11)と読み替えてマニュアルを参照してください。
Red Hat Enterprise LinuxをRHELと略しています。
RHELをLinuxと表記しています。
PRIMEQUEST 3000/2000 シリーズを PRIMEQUEST と略しています。

輸出管理規制について
本ドキュメントを輸出または第三者へ提供する場合は、お客様が居住する国および米国輸出管理関連法規等の規制をご確認のうえ、必要
な手続きをおとりください。

商標について
UNIX は、米国およびその他の国におけるオープン・グループの登録商標です。
Red Hat は米国およびそのほかの国において登録されたRed Hat, Inc. の商標です。
Linuxは、Linus Torvalds氏の米国およびその他の国における登録商標あるいは商標です。
Oracle とJava は、Oracle Corporation およびその子会社、関連会社の米国およびその他の国における登録商標です。
文中の社名、商品名等は各社の商標または登録商標である場合があります。
VMware は、米国およびその他の地域における VMware,Inc の登録商標または商標です。
Symfoware および FUJITSU Software Enterprise Postgres は、富士通株式会社の商標または登録商標です。
PRIMECLUSTERは、富士通株式会社の登録商標です。その他各種製品名は、各社の製品名称、商標または登録商標です。
お願い

・ 本書を無断で他に転載しないようお願いします。
・ 本書は予告なしに変更されることがあります。

出版年月および版数

2017年 4月 初版
2018年 8月 第3版

著作権表示
All Rights Reserved, Copyright (C) 富士通株式会社 2017-2018

- iv -
目　次
第1章 概要................................................................................................................................................................................ 1
1.1 概要..................................................................................................................................................................................................... 1
1.2 RMSが高可用性を実現する仕組み...................................................................................................................................................1
1.2.1 ユーザ業務、資源、オブジェクト..................................................................................................................................................2
1.2.2 RMS構成と実システム................................................................................................................................................................. 3
1.2.3 ノードおよびユーザ業務のフェイルオーバ................................................................................................................................. 4
1.2.4 制御されるアプリケーションとコントローラオブジェクト................................................................................................................4
1.2.4.1 フォローコントローラ...............................................................................................................................................................5
1.2.4.2 スケーラブルコントローラ.......................................................................................................................................................6
1.2.4.3 コントローラに関する補足説明............................................................................................................................................. 7
1.3 RMS Wizard Toolsによる設定............................................................................................................................................................ 7
1.4 RMSウィザードのコンポーネント.........................................................................................................................................................8
1.4.1 RMS Wizard Tools....................................................................................................................................................................... 9
1.4.2 RMS Wizard Kit........................................................................................................................................................................... 9
1.5 Cluster Admin....................................................................................................................................................................................10
1.6 RMSコンポーネント........................................................................................................................................................................... 10
1.6.1 BM (ベースモニタ).....................................................................................................................................................................10
1.6.2 ディテクタ.................................................................................................................................................................................... 10
1.6.3 スクリプト......................................................................................................................................................................................11
1.6.4 RMS CLI.....................................................................................................................................................................................11
1.7 オブジェクトタイプ..............................................................................................................................................................................12
1.8 オブジェクト属性................................................................................................................................................................................13
1.9 環境変数........................................................................................................................................................................................... 13
1.9.1 環境変数の設定.........................................................................................................................................................................14
1.9.2 スクリプト実行環境変数..............................................................................................................................................................14
1.10 RMSディレクトリ構造....................................................................................................................................................................... 14

第2章 RMSの詳細説明........................................................................................................................................................... 16
2.1 状態遷移........................................................................................................................................................................................... 16
2.1.1 内部機構.................................................................................................................................................................................... 16
2.1.1.1 アプリケーションと資源の記述............................................................................................................................................ 16
2.1.1.2 メッセージ............................................................................................................................................................................ 16
2.1.2 初期化........................................................................................................................................................................................ 16
2.1.3 Online処理..................................................................................................................................................................................19
2.1.3.1 Online要求...........................................................................................................................................................................19
2.1.3.2 PreCheckScript.................................................................................................................................................................... 20
2.1.3.3 userApplicationのRMSグラフにおけるOnline処理............................................................................................................ 21
2.1.3.4 Online処理中の予期しないレポート...................................................................................................................................22
2.1.3.5 Online処理中のFault...........................................................................................................................................................22
2.1.3.6 アプリケーションがすでにOnline状態にある場合の初期化処理...................................................................................... 22
2.1.4 Offline処理.................................................................................................................................................................................23
2.1.4.1 Offline要求..........................................................................................................................................................................23
2.1.4.2 userApplicationのRMSグラフにおけるOffline処理............................................................................................................23
2.1.4.3 Offline処理中の予期しないレポート.................................................................................................................................. 24
2.1.4.4 Offline処理中のFault..........................................................................................................................................................24
2.1.4.5 グラフノードがすでにOffline状態である場合.................................................................................................................... 25
2.1.4.6 オブジェクトをOffline状態にすることができない................................................................................................................25
2.1.5 Fault処理.................................................................................................................................................................................... 25
2.1.5.1 Online状態または要求処理中のFault................................................................................................................................25
2.1.5.2 Offline Fault.........................................................................................................................................................................26
2.1.5.3 AutoRecover属性................................................................................................................................................................ 26
2.1.5.4 Offline処理中のFault..........................................................................................................................................................27
2.1.5.5 Fault処理の例..................................................................................................................................................................... 27
2.1.5.6 Faultクリア............................................................................................................................................................................ 28
2.1.5.7 SysNode異常....................................................................................................................................................................... 28

-v-
 2.1.6 切替え処理.................................................................................................................................................................................29
2.1.6.1 切替え要求..........................................................................................................................................................................29
2.1.7 特殊な状態.................................................................................................................................................................................30
2.1.7.1 保守モードの制限............................................................................................................................................................... 30
2.1.7.2 Inconsistent状態.................................................................................................................................................................. 31
2.2 RMSハートビート............................................................................................................................................................................... 32
2.2.1 動作の詳細.................................................................................................................................................................................33
2.2.1.1 ELMロックの管理................................................................................................................................................................ 33
2.2.1.2 最初のノードの起動............................................................................................................................................................ 33
2.2.1.3 2番目のノードの起動.......................................................................................................................................................... 33
2.2.1.4 3番目以降のノード.............................................................................................................................................................. 34
2.2.1.5 ノードまたはRMS停止の順序.............................................................................................................................................34
2.2.1.6 レスポンスの遅延.................................................................................................................................................................34
2.2.2 hvenvのデフォルトの初期化...................................................................................................................................................... 35
2.2.3 hvenv.localでのELMの手動制御.............................................................................................................................................. 35
2.3 スケーラブルコントローラ...................................................................................................................................................................35
2.3.1 コントローラの概要..................................................................................................................................................................... 35
2.3.2 スケーラブルコントローラとアプリケーション.............................................................................................................................. 36
2.3.2.1 スケーラブルアプリケーション............................................................................................................................................. 36
2.3.2.2 スケーラブルコントローラによる利点...................................................................................................................................36
2.3.2.3 スケーラブルコントローラの属性.........................................................................................................................................36
2.3.3 Online/Offline処理と状態遷移.................................................................................................................................................. 37
2.3.3.1 制御されるアプリケーションの状態とコントローラの状態................................................................................................... 37
2.3.3.2 アプリケーションが Online 状態になるノードについて.......................................................................................................38
2.3.3.3 制御されるアプリケーションへの要求の伝播..................................................................................................................... 38
2.3.3.4 コントローラのWarning状態................................................................................................................................................ 38
2.3.3.5 アプリケーションのWarning状態.........................................................................................................................................38
2.3.3.6 コントローラStateChangeScript............................................................................................................................................ 39
2.3.3.7 Online/Standby/Offline処理の順序制御とアプリケーショングループ............................................................................... 40
2.3.3.8 サブクラスタでの自動起動..................................................................................................................................................40
2.3.3.9 サブクラスタでの切替え...................................................................................................................................................... 41
2.3.3.10 子アプリケーションの手動切替え..................................................................................................................................... 41
2.3.3.11 保守モード時の操作......................................................................................................................................................... 41

第3章 RMS Wizard Toolsインタフェース (hvw) の使用方法..................................................................................................... 45

3.1 概要................................................................................................................................................................................................... 45
3.1.1 RMSウィザードのタイプ..............................................................................................................................................................45
3.1.1.1 ターンキーウィザード...........................................................................................................................................................46
3.1.1.2 リソースウィザード................................................................................................................................................................ 46
3.2 一般的な構成設定の手順................................................................................................................................................................ 46
3.3 RMS構成の作成および編集............................................................................................................................................................ 47
3.3.1 RMSウィザードメニューの使用.................................................................................................................................................. 47
3.3.2 メイン構成メニュー......................................................................................................................................................................48
3.3.2.1 RMS停止中のメイン構成メューウィンドウ...........................................................................................................................48
3.3.2.2 RMS実行中のメイン構成メニューウィンドウ....................................................................................................................... 51
3.3.3 セカンダリメニュー...................................................................................................................................................................... 51
3.3.4 必須設定と選択設定..................................................................................................................................................................52
3.4 RMS構成定義ファイルの作成と配布............................................................................................................................................... 53
3.5 RMS構成要素................................................................................................................................................................................... 55
3.5.1 スクリプト......................................................................................................................................................................................55
3.5.2 ディテクタ.................................................................................................................................................................................... 55
3.5.3 RMSオブジェクト........................................................................................................................................................................ 56

第4章 構成変更の例................................................................................................................................................................57
4.1 クラスタアプリケーションに PreCheckScriptを設定する....................................................................................................................57
4.2 コントローラのタイムアウト時間を変更する....................................................................................................................................... 63

第5章 Cluster Admin GUIの使用方法..................................................................................................................................... 69

- vi -
 5.1 概要................................................................................................................................................................................................... 69
5.2 Cluster Adminの起動........................................................................................................................................................................ 69
5.2.1 Web-Based Admin View............................................................................................................................................................ 69
5.2.2 ログイン....................................................................................................................................................................................... 69
5.2.3 Cluster Adminメイン画面 ...........................................................................................................................................................72
5.2.4 Cluster Adminメッセージの表示................................................................................................................................................ 73
5.3 RMSの状態と属性の表示.................................................................................................................................................................73
5.3.1 RMSツリー.................................................................................................................................................................................. 74
5.3.2 コマンドポップアップ...................................................................................................................................................................75
5.3.3 ポップアップ確認画面................................................................................................................................................................77
5.3.4 RMS環境変数の表示................................................................................................................................................................ 78
5.3.5 オブジェクトの状態の表示......................................................................................................................................................... 80
5.3.6 構成情報またはオブジェクト属性.............................................................................................................................................. 81

第6章 その他の管理ツール......................................................................................................................................................83
6.1 RMSクラスタテーブルの使用........................................................................................................................................................... 83
6.1.1 クラスタテーブルからのコマンドポップアップメニューの使用...................................................................................................85
6.2 RMSグラフの使用............................................................................................................................................................................. 85
6.2.1 RMSクラスタ全体のグラフ..........................................................................................................................................................86
6.2.2 RMSアプリケーショングラフ....................................................................................................................................................... 89
6.2.3 RMSサブアプリケーショングラフ................................................................................................................................................90
6.2.4 RMS合成サブアプリケーショングラフ........................................................................................................................................91
6.2.5 グラフからコマンドポップアップメニューの使用........................................................................................................................ 93
6.2.6 表示された詳細レベルの変更...................................................................................................................................................94
6.3 表示変更の意味................................................................................................................................................................................98
6.3.1 RMS構成変更時の表示............................................................................................................................................................ 98
6.3.2 RMS停止後のグラフの見方.................................................................................................................................................... 100
6.4 RMS ログメッセージの表示.............................................................................................................................................................101
6.4.1 switchlog およびアプリケーションログを表示する一般的な手順........................................................................................... 105
6.4.2 時刻フィルタ............................................................................................................................................................................. 105
6.4.3 キーワードフィルタ....................................................................................................................................................................106
6.4.3.1 リソース名...........................................................................................................................................................................106
6.4.3.2 重要度............................................................................................................................................................................... 107
6.4.3.3 0以外の終了コード............................................................................................................................................................108
6.4.3.4 キーワード..........................................................................................................................................................................108
6.4.4 テキスト検索..............................................................................................................................................................................109
6.4.5 フィルタの削除..........................................................................................................................................................................110

第7章 RMSの操作.................................................................................................................................................................111
7.1 RMS の操作について..................................................................................................................................................................... 111
7.1.1 RMSの起動.............................................................................................................................................................................. 111
7.1.2 システム起動時にRMSを自動起動する..................................................................................................................................114
7.1.3 RMSの停止.............................................................................................................................................................................. 116
7.1.4 SysNodeのWait状態のクリア....................................................................................................................................................121
7.2 RMSアプリケーションの管理.......................................................................................................................................................... 121
7.2.1 アプリケーションの自動起動のオーバーライド....................................................................................................................... 122
7.2.2 クラスタアプリケーションの切替え............................................................................................................................................124
7.2.3 クラスタアプリケーションの起動............................................................................................................................................... 125
7.2.4 クラスタアプリケーションの停止............................................................................................................................................... 126
7.2.5 クラスタアプリケーションのリセット............................................................................................................................................ 127
7.2.6 Faulted状態のクリア..................................................................................................................................................................129
7.2.7 クラスタアプリケーションの活性化........................................................................................................................................... 130
7.3 リソースの管理................................................................................................................................................................................. 130
7.3.1 リソースの切替え...................................................................................................................................................................... 130
7.3.2 リソースの起動.......................................................................................................................................................................... 132
7.3.3 リソースの停止.......................................................................................................................................................................... 133
7.3.4 リソースの起動停止に関する注意........................................................................................................................................... 134
7.3.5 リソースの故障形跡の表示...................................................................................................................................................... 134

- vii -
 7.4 保守モードの使用法....................................................................................................................................................................... 138
7.4.1 保守モードの開始.................................................................................................................................................................... 138
7.4.2 保守モードの動作に関する注意............................................................................................................................................. 140
7.4.2.1 保守モードにおけるクラスタ全体の制限.......................................................................................................................... 140
7.4.3 保守モードの終了.................................................................................................................................................................... 141
7.4.4 保守モードのコマンドラインインタフェース..............................................................................................................................142

付録A 事前準備.....................................................................................................................................................................144
A.1 ネットワークデータベースファイル..................................................................................................................................................144
A.1.1 /etc/hosts.................................................................................................................................................................................. 144
A.1.1.1 /etc/hosts内のネットワークインタフェース名.....................................................................................................................145
A.1.2 /.rhosts (Solaris)、/root/.rhosts (Linux) ................................................................................................................................... 145
A.2 構成資源の定義.............................................................................................................................................................................146
A.2.1 /opt/SMAW/SMAWRrms/etc/hvipalias.................................................................................................................................. 146
A.2.2 /opt/SMAW/SMAWRrms/etc/hvconsoles...............................................................................................................................147
A.3 ファイルシステム (Linux)................................................................................................................................................................ 147
A.3.1 /etc/fstab.pcl............................................................................................................................................................................. 147
A.3.1.1 アプリケーション用のファイルシステムの構成.................................................................................................................147
A.3.1.2 クラスタ全体に渡る構成の問題....................................................................................................................................... 148
A.4 ファイルシステム (Solaris).............................................................................................................................................................. 148
A.4.1 NFS ロックフェイルオーバ.......................................................................................................................................................149
A.5 NFSサーバ......................................................................................................................................................................................149
A.6 ログファイル.................................................................................................................................................................................... 149
A.6.1 /var/log/messages (Linux) または /var/adm/messages (Solaris)..............................................................................................149
A.7 他のシステムサービスおよびデータベース...................................................................................................................................149

付録B 状態............................................................................................................................................................................150
B.1 基本状態.........................................................................................................................................................................................150
B.2 状態の詳細..................................................................................................................................................................................... 150

付録C オブジェクトタイプ........................................................................................................................................................ 152

付録D 属性 ...........................................................................................................................................................................153
D.1 ユーザ設定属性............................................................................................................................................................................. 153
D.2 RMS構成ウィザード管理属性........................................................................................................................................................157

付録E 環境変数.....................................................................................................................................................................160
E.1 RMS環境変数の設定.....................................................................................................................................................................160
E.2 RMSグローバル環境変数.............................................................................................................................................................. 160
E.3 RMSローカル環境変数.................................................................................................................................................................. 163
E.4 RMSスクリプト実行環境変数..........................................................................................................................................................166

付録F トラブルシューティング................................................................................................................................................. 168

F.1 概要................................................................................................................................................................................................. 168
F.2 デバッグメッセージとエラーメッセージ........................................................................................................................................... 168
F.3 ログファイル..................................................................................................................................................................................... 169
F.4 RMS BM (ベースモニタ) ログ出力の管理.....................................................................................................................................170
F.4.1 RMS BM (ベースモニタ) ログレベルの管理.......................................................................................................................... 170
F.4.2 システムログへのBM (ベースモニタ) 出力の制御................................................................................................................. 171
F.5 アプリケーションログの出力の管理................................................................................................................................................ 171
F.5.1 標準スクリプトのデバッグメッセージの制御............................................................................................................................ 172
F.6 ディテクタログの出力の管理...........................................................................................................................................................172
F.6.1 デバッグメッセージとログレベル.............................................................................................................................................. 172
F.6.2 ディテクタのログレベルの設定................................................................................................................................................ 173
F.6.2.1 hvutil -Lによるディテクタのログレベルの設定................................................................................................................. 173
F.6.2.2 RMS Wizard Toolsによるログレベルの設定.................................................................................................................... 173
F.7 RMSログメッセージの意味............................................................................................................................................................. 174
F.7.1 switchlogメッセージの形式...................................................................................................................................................... 174
F.7.2 アプリケーションログメッセージの形式.................................................................................................................................... 175

- viii -
 F.7.3 プログラムログメッセージの形式..............................................................................................................................................175
F.8 RMSログファイルのクリーンアップ..................................................................................................................................................176
F.8.1 hvlogclean.................................................................................................................................................................................176
F.8.2 hvlogcontrol..............................................................................................................................................................................176
F.8.3 バックグラウンドスクリプトのログ採取....................................................................................................................................... 177
F.9 RMSトラブルシューティング............................................................................................................................................................177
F.10 高度なトラブルシューティングのための情報収集....................................................................................................................... 179
F.10.1 hvdumpコマンドの使用 (RMS).............................................................................................................................................. 179
F.11 SNMPリソース異常通知................................................................................................................................................................179

付録G RMSコマンドラインインタフェース.................................................................................................................................181
G.1 使用可能なRMS CLIコマンド........................................................................................................................................................181

付録H リリース情報............................................................................................................................................................... 183

用語集...................................................................................................................................................................................184

索引...................................................................................................................................................................................... 201

- ix -
第1章 概要
本章では、RMS (Reliant Monitor Services) の概要を説明します。具体的には、PRIMECLUSTER の各コンポーネントについて、高可
用性構成を実現するためにRMS、RMS Wizard Kit、およびRMS Wizard Toolsをどのように連携するかについて、またCluster Adminに
ついても説明します。

1.1 概要
PRIMECLUSTERは、導入運用サービス、高可用性、拡張性、パラレルアプリケーションのサポート、クラスタファイルシステム、クラスタ
ボリューム管理などの各種サービスを総合的に提供するコンポーネントの総称です。以下の図に、PRIMECLUSTERのコンポーネントが
提供する各種サービス間の関係およびオペレーティングシステム環境との関係を示します。

図1.1 PRIMECLUSTERコンポーネントの概要

本書は、高可用性運用に関連するPRIMECLUSTERの製品とサービス (上図のグレー部分) を中心に説明します。

・ RMS
高可用性マネージャ (RMS) は、クラスタ内のアプリケーションの高可用性 (HA) を実現するソフトウェアモニタです。RMSの役割は、
システムとアプリケーションリソースを監視して障害を検出し、障害発生時にサービスを中断しないでアプリケーションの可用性を仮想的
に維持することです。
RMSはさらに、各地域に固有なアプリケーションについても統合して管理することができます。サービスの詳細については当社技術員
(SE) にお問い合わせください。

・ RMS Wizard ToolsおよびRMS Wizard Kit

RMS によって制御されるクラスタアプリケーションを作成するツールです。

・ Cluster Admin
Cluster Admin GUIは、RMSの中心的な管理ツールです。

・ Cluster Foundation (CF)

ユーザアプリケーションやその他PRIMECLUSTERサービスのためのクラスタ管理サービスや通信サービスを提供する統合製品です。

その他のPRIMECLUSTER製品 (上図の薄いグレー部分) については、個別のマニュアルが用意されています。"関連マニュアル" を参照

してください。

1.2 RMSが高可用性を実現する仕組み
RMSはユーザ業務が使用する各資源の状態を制御および監視することによって、ユーザ業務の高可用性を実現します。資源とは、ネッ
トワークインタフェース、ローカルファイルシステム、リモートファイルシステム、およびSAN (Storage Area Network) などを意味します。RMS
はクラスタの各ノードの状態も監視します。

-1-
1.2.1 ユーザ業務、資源、オブジェクト
RMSは、実際のクラスタ構成を仮想化し、RMS構成で表現します。RMS構成では、各マシン、アプリケーション、システム資源がオブジェ
クトとして表され、オブジェクトおよびオブジェクトの集合はそれぞれの依存関係に従ってツリー構造で表示されます。たとえば、ユーザ
アプリケーションが、ネットワークインタフェースとファイルシステムに依存して動作している場合を考えてみます。ツリー構造では、対応す
るアプリケーションオブジェクトが親として表現され、ネットワークオブジェクトおよびファイルシステムオブジェクトが子として表現されます。
ツリー構造は通常、「RMSグラフ」と呼ばれます。
RMSグラフの各オブジェクトは、必須パラメタとともにそのオブジェクトの状態情報も持っています。オブジェクトの状態は主に Online (有効、
使用可能) かOffline (無効、使用不可) です。RMSが提供する状態の一覧は、"付録B 状態"を参照してください。
運用中、構成はRMSベースモニタによって管理されます。RMSベースモニタは、オブジェクトの状態に変化があった場合やタイムアウト、
（指定された一定時間オブジェクトの状態に変化がなかった場合）に対応する処理を開始します。

ノードとハートビート
クラスタを構成するマシンは、ノードと呼ばれます。RMSがノードの状態を監視する際に最も優先して検出するのは、ノードもしくはRMS
ベースモニタが障害によって完全に停止しているかどうかです。応答速度の低下は、システムの過負荷によって生じている可能性があ
りますが、最優先の検出項目ではありません。RMSは障害の検出にハートビートとELMの2種類の方法を採用しています。
詳細は"2.2 RMSハートビート"を参照してください。

ディテクタ
ディテクタは、RMS構成に定義された個々の物理的資源と論理的資源の状態を監視し、RMSベースモニタプロセスに通知するプロセ
スです。RMSは状態の通知を解釈して該当する仮想オブジェクトの状態を判断します。オブジェクトの状態に変化が生じた場合、RMSは
そのオブジェクトに指定されたパラメタに対応した処理を実行します。オブジェクトごとに個別のディテクタを対応づけることができます。
RMSがクラスタノード上で起動されると、RMS構成に定義されたディテクタを起動します。ディテクタは通常、RMSが停止されるまで動作を
継続します。RMSはシステムの異常が発生した場合にディテクタの再起動を行います。
ディテクタがベースモニタに通知する状態およびユーザインタフェースに表示される状態については、この章で後ほどまとめて説明します。

スクリプト
各オブジェクトには複数のスクリプトが関連付けられています。これらのスクリプトはシェルスクリプトです。それぞれのスクリプトは通常、ユー
ザアプリケーションや物理資源などに対して相互に作用するよう記載されます。
スクリプトにはリアクティブ型とプロアクティブ型があります。リアクティブ型のスクリプトは、発生した状態遷移に対応してRMSがどのような処理
を行うかを定義しています。一方、プロアクティブ型のスクリプトは、RMSが各オブジェクトを制御するために行うべき処理を定義しています。
たとえば、RMSは、OnlineからOfflineへ資源が状態遷移したことを通知されると、それに反応して、あるスクリプトを実行しますが、RMS側
からまずスクリプトを実行することによって、資源の状態を強制的にOfflineにすることもあります。
スクリプトは、指定された処理が完了すると動作を停止し、RMSベースモニタに終了コードを返します。
RMSオブジェクトに指定できるスクリプトについては、この章で後ほどまとめて説明します。

オブジェクトタイプ
RMS高可用性アプリケーションのほとんどは、ネットワークインタフェース、ファイルシステム、仮想ディスクなどの物理資源をgResourceオ
ブジェクトとして表します。gResourceオブジェクトのほとんどは、自らのOnline化、Offline化を制御するスクリプトを保持しています。
オペレーティングシステム環境で実行される実際のアプリケーションは、RMS内部では、userApplicationオブジェクトとして扱われます。実際
のアプリケーションが使用している一連のgResourceオブジェクトは、依存オブジェクトと呼ばれます。userApplicationとそのすべての依存
オブジェクトをOnlineにすることを、オンライン処理といいます。userApplicationとそのすべての依存オブジェクトをOfflineにすることを、オ
フライン処理といいます。
高可用性構成で、ユーザ業務を実行するノードは、 SysNodeオブジェクトとして表現されます。gResourceオブジェクトおよびuserApplication
オブジェクト同様、SysNodeオブジェクトもOnline化とOffline化が可能でディテクタとスクリプトを保持しています。しかし、対応する実際の
ノードの起動と停止は、スクリプト処理だけでは実行できません。
RMS Wizard ToolsがサポートするRMSオブジェクトタイプの一覧は"付録C オブジェクトタイプ" を参照してください。

-2-
シャットダウン機構 (SF)
シャットダウン機構は、クラスタ内の各ノードに対して強制停止指示を発します。SysNodeオブジェクトをOfflineにする必要が生じた場合、
RMSはSFを使用して対応するノードの強制停止を指示します。RMSはノードの停止処理が完了するのを待ってから、userApplicationを別
のSysNodeに切替えます。これにより、ユーザ業務が2つのノードで同時に実行されることを防止し、データの整合性を保証します。
シャットダウン機構の詳細については、ご使用のオペレーティングシステムの“PRIMECLUSTER Cluster Foundation導入運用手引書”を
参照してください。

1.2.2 RMS構成と実システム
RMSは、ノード、ユーザアプリケーション、システム資源に対して直接処理を行うのではなく、RMS構成で定義された仮想のオブジェクト間
でのみ通信を行います。以下の図は、オペレーティングシステム環境における実際のユーザアプリケーションと対応するRMS構成の
userApplicationオブジェクトとの関係を示しています。

図1.2 RMSとオペレーティングシステム間のインタフェース

RMS仮想オブジェクトと実システム間のインタフェースは、RMSウィザードの提供するスクリプトとディテクタがすべて行います。スクリプトは、
自らの処理が正しく終了したかどうかを復帰値によって通知し、RMSは、オブジェクトのディテクタから送られてきた状態コードと照らし合わ
せてオブジェクトの状態を判別します。RMSが、オペレーティングシステム環境 (図中点線より下の部分) でユーザアプリケーションに何が
発生したかを認識する方法はこれ以外にありません。
たとえば userApplicationオブジェクトのOnlineスクリプトから成功が通知されると、実際のユーザアプリケーションの状態に関係なくRMSは、
オブジェクトがOnline状態にあるものと判断します。逆に、リソースオブジェクトのディテクタからOffline状態の通知があっても、必ずしもその
物理資源が使用不可であるとは限りません。

ポイント
高可用性を確保するには、対応する現実の機器を正しく制御するスクリプトと、機器の状態を正確に通知するディテクタがRMSに必要です。

RMS構成で使用する用語
このマニュアルでは、RMS側 (図の点線から上部分) での構成手順について説明しています。厳密に言うと、本書の主目的はSysNodeオ
ブジェクト、userApplicationオブジェクト、およびその他のRMSエンティティの説明であり、それらが表している現実の機器の説明ではあ
りません。

-3-
しかしながら、「SysNodeオブジェクト」よりも「ノード」、「userApplicationオブジェクト」よりも「アプリケーション」という用語を使用するほうが、
直観的に分かりやすいと思われます。両者の関係は非常に密接で、かつ、われわれが常にRMSの概念を基に議論していることがはっ
きりしているからです。これにはさらに、技術的な議論の多くを単純化できるという利点もあります。このため、特にRMSオブジェクトとそれが
表す実体との区別が必要となる場面をのぞき、本書およびRMSウィザードでは、以下の各用語は同じ意味で使用します。

・ 「ノード」、「SysNodeオブジェクト」、「SysNode」
・ 「アプリケーション」、「userApplicationオブジェクト」、「userApplication」
・ 「リソース」、「gResourceオブジェクト」、「gResource」
オブジェクトの状態と属性の記述は同様に簡略化されます。たとえば、「マウントポイントxyzを監視するgResourceオブジェクトは、Offline
状態にある」という言い方は非常に正確ではありますが長々しいため、通常は、「xyzファイルシステムはOfflineである」といいます。また、
スクリプト名も、「PreOnlineScript属性で指定されたスクリプト」という代わりに、簡略化して「PreOnlineScript」と呼ぶのが普通です。
なお、RMSが扱う、すべてのオブジェクトを総称して、「RMSリソース」と記載します。

1.2.3 ノードおよびユーザ業務のフェイルオーバ
通常の運用では、クラスタの各ノードは、RMSのインスタンスが1つだけ実行されます。各インスタンスは、設定されている各userApplication
の動作を調整するために互いに通信します。ノードがクラッシュした場合や、他のクラスタとの通信ができなくなった場合、RMSは、そのノード
上のuserApplicationオブジェクトを、障害発生ノードからクラスタ内の正常なノードに切替えることができます。この処理はフェイルオーバと呼
ばれています。
フェイルオーバは個々のアプリケーションについても実行されます。userApplicationオブジェクトは、通常一度に1つのノードでのみオン
ラインになることができます(ただし、共有オブジェクトはこの限りではありません)。userApplicationオブジェクトが使用している資源に異常が
発生した場合、そのuserApplicationオブジェクトのみをクラスタ内の別のノードに切替えます。userApplicationのフェイルオーバでは、まず、
最初のノードでオブジェクトのオフライン処理を行い、その後、2番目のノードでオブジェクトのオンライン処理を行います。
また、RMSがノードの強制停止を要求することもあります。 いずれの場合にも、RMSは、userApplicationを他のノードに切替える前に、
PRIMECLUSTERシャットダウン機構を使用して反応のなくなったノードが実際に停止しているのかを確認します。これによって、データの
整合性が保護されます。
フェイルオーバ以外に、RMSには、資源をローカルに回復する機能もあります。これは、userApplication全体を別のクラスタノードに切替
えるのではなく、障害が発生した資源だけをOnline状態に戻す機能です。

1.2.4 制御されるアプリケーションとコントローラオブジェクト
場合によっては1つのアプリケーションが別のアプリケーションを制御するのが望ましい「親」と「子」の関係もあります。たとえば、以下の図の
構成のような銀行の現金自動支払機のユーザ業務 (現金自動支払アプリケーション) は、ローカルネットワーク (この場合はネットワーク資源
オブジェクト) とデータベースに依存しています。

図1.3 2つの依存オブジェクトを持つ親アプリケーション

たとえば、ネットワークまたはデータベースに何らかの異常が発生した場合、親である現金自動支払アプリケーションはトランザクションを完了
することができません。図中のオブジェクトを結ぶ線は、依存関係を示しています。RMSの観点からは、ネットワーク資源とデータベース
アプリケーションは同じ構成にする必要があります。すなわち、両者とも現金自動支払アプリケーションを正しく機能させるためにOnline状態
でなければならない依存資源として機能する必要があります。
しかしRMSでは、いかなるアプリケーションも他のアプリケーションが使用しているアプリケーションを直接の子として使用することは許さ
れません。RMSは、アプリケーション間の親子関係をコントローラオブジェクト (以降コントローラと記載) を使用して表現します。他の資源

-4-
 オブジェクトと異なり、コントローラにはスクリプトやディテクタがありません。代わりに、Online要求やOffline要求を親アプリケーションから子
アプリケーションに伝播させ、子アプリケーションの状態から、自らの状態を判定します。
以下の図は、RMSにおいて、銀行業務の現金自動支払アプリケーション、コントローラ、データベースアプリケーションのすべてがノード1上
で稼動している様子を表したものです。ここでの説明および以後の説明のため、図にはアプリケーションとコントローラのみが示されています。
ネットワークインタフェースを表す資源オブジェクトは示されていません。

図1.4 RMSにおける制御されるアプリケーションの概念図

注意

・ コントローラオブジェクトによるアプリケーションの制御は、コントローラオブジェクトを使用した運用形態をサポートするPRIMECLUSTER
の対応製品のマニュアルに従って使用してください。

・ 制御されるアプリケーションそれぞれに、親アプリケーションの子としてコントローラが必要となります。コントローラはRMSがアプリケー
ションを制御するために用意されているオブジェクトであり、実システムには対応するものはありません。

制御されるアプリケーションのフェイルオーバ
子 (制御されるアプリケーション) がOfflineまたはFaulted状態となった場合、RMSは親、または子、あるいはすべての依存する資源を他の
クラスタノードへ切替えます。実際に切替え時に行われる処理は、コントローラのモード (FollowモードとScalableモード) によって異なります。
FollowモードとScalableモードについては、以下に説明します。

1.2.4.1 フォローコントローラ
親 (制御する) アプリケーションと子 (制御される) アプリケーションが同じクラスタノードで動作する必要がある場合は、コントローラをFollow
モードに設定します。親が別のクラスタノードに切替えられた場合、Followモードで設定されているアプリケーションとその依存資源も親と同
じクラスタノードに切替わります。同様に、子アプリケーションでフェイルオーバが発生した場合、親アプリケーションも同様にフェイルオー
バを行います。上記、図1.4 RMSにおける制御されるアプリケーションの概念図のノード1で、現金支払アプリケーションツリーが最初Online
で、コントローラがFollowモードで稼動するように構成されている場合を考えます。親アプリケーションまたは子アプリケーションのいずれかが、
何らかの理由でノード2に切替えられる必要が生じた場合、ツリーの残りの部分は同じようにノード2に切替えられ、以下の図に示す状態に
なります。

-5-
図1.5 Followモード切替えの結果

上の図のフォローコントローラは、子アプリケーションと同じく、親アプリケーションと同じクラスタノードでのみOnline状態になります。フォ
ローコントローラにより、コントローラで制御されている複数のアプリケーションと、アプリケーションで使用されている資源が密に結合され、常
に同じノードで稼動することが保証されます。

注意
切替えはRMSグラフ内のオブジェクトの単なる移動ではありません。グラフのノード1に対応する部分のオブジェクトがまずOffline化され、
グラフのノード2に対応する部分のオブジェクトがOnline化されます。実際の構成においてRMSが正しいシーケンスを実行することが高
可用性運用には非常に重要です。詳細については、"付録A 事前準備"を参照してください。

1.2.4.2 スケーラブルコントローラ
一般的に拡張性とは、資源や負荷の変化にシステム全体が対応できる能力をいいます。RMSスケーラブルコントローラの主な特長の1つは、
親アプリケーションと子アプリケーションが別ノードで稼動できるという点です。この機能は、柔軟性に富んだ構成を構築できるようにす
るだけでなく、複数の資源で不具合が発生した場合に切替えの遅延や業務の停止を防ぐこともできます。
銀行業務の例で考えると、現金自動支払機のアプリケーションはネットワークとデータベースアプリケーションに依存しています。ノード1の
ファイルシステムに障害が発生し、Offline状態が発生した場合、フォローコントローラの場合はRMSは現金自動支払機およびデータベー
スをノード2に切替えようとします。しかし、ノード2のネットワークがFaulted状態であった場合、現金自動支払機をOnline状態にすること
はできません。これは極端な例ですが、フォローコントローラにのみ依存する構成に対して、高負荷や資源不足がいかに大きな影響を与
えるかを示しています。
スケーラブルコントローラを使用した場合は、このような状況にも動的に対応することができます。ネットワークがノード1でOnlineであり、ファ
イルシステムがノード2でOnlineであれば、以下の図に示すように、データベースは他の影響を受けずに切替えられます。

図1.6 Scalableモードにおける子 (制御される) アプリケーションの切替え

逆に、ネットワークの停止が原因となって、ノード1でデータベースがOnline状態のまま、RMSによって現金自動支払機がノード2に切替え
られた例が、以下の図の状態です。

-6-
図1.7 Scalableモードにおける親 (制御する) アプリケーションの切替え

1つのアプリケーションが複数のノードで実行できる場合、RMSでは、1つのアプリケーションにつき、クラスタ内では1つのインスタンスしか
Onlineになることができません。このため、userApplicationは一度に1つのノードでしか実行できません。ただし、Controllerオブジェクト
にはこのような制限がありません。
図1.6 Scalableモードにおける子 (制御される) アプリケーションの切替えと図1.7 Scalableモードにおける親 (制御する) アプリケーションの
切替えには、コントローラの状態は示していませんが、実際には、実行可能なノード上の各Scalableモードの子アプリケーションごとに、コ
ントローラのインスタンスがOnline状態になっています。

1.2.4.3 コントローラに関する補足説明
FollowモードとScalableモードは、排他関係にあり、子アプリケーションのコントローラは、FollowまたはScalableモードのいずれかで動作し、
両方で動作することはできません。RMS Wizard Toolsでは、各コントローラ構成に矛盾が生じるようなものを許していません。
1つの親アプリケーションは複数の子アプリケーションを持つことができますが、Wizard Tools では、すべての子で同じコントローラタイプ
にする必要があります。Followモードを使用している場合、子のそれぞれに個別のフォローコントローラが必要です。Scalableモードの場合
は、複数の子で1つのスケーラブルコントローラを使用します。たとえば、銀行業務の例だと、現金自動支払機アプリケーションがさらに現
金自動支払機 (ATM) に制御されるアプリケーションを持つ場合もあります。フォローグラフとスケーラブルグラフの違いを以下の図に示し
ます。

図1.8 複数の子を持つコントローラ構造

詳細については、"2.3 スケーラブルコントローラ"を参照してください。

1.3 RMS Wizard Toolsによる設定

RMSにはさまざまな機能やオプションが用意されています。RMS構成の開発、デバッグ、調整を正しく行うには、RMSの動作原理および
RMSの動作に必要な条件についての知識が必要です。実際に運用しようとするユーザ業務を、RMS構成内のクラスタアプリケーション
として設定するためには、以下の条件が必要です。

・ ユーザ業務が使用する以下の資源
－ ディスク

-7-
 － ボリュームマネージャ
－ ファイルシステム
－ 監視されるプロセス
－ IPアドレス
・ 各オブジェクトと依存オブジェクトの関係
どのファイルシステムがどの仮想ディスクまたは物理ディスクに依存し、どのプロセスがどのファイルシステムに依存しているか、などの
情報です。

・ 制御されるアプリケーションどうしの関係
どのアプリケーションを開始してから、他のアプリケーションを開始するか、などの情報です。

・ 各オブジェクトをOnlineおよびOfflineにするスクリプト
・ 各リソースの状態を調べるディテクタ
上記の構成作業を手動で行うと、非常に時間がかかり、エラー発生の原因となります。このため、RMS Wizard Toolsが開発されました。
PRIMECLUSTER RMSウィザードは、システム管理者の負荷を軽減し、柔軟性に富んだRMS構成設定が行えます。ユーザ業務と資源に
関する詳細情報は、RMSウィザードのユーザインタフェースに従って入力し、これらの詳細情報を使用して適切なスクリプトやディテクタを
選択し、事前に定義された構造に組み合わせて、RMS構成定義を完了します。
RMSウィザードを使用すると、Oracleなどの一般的なアプリケーションのRMSの構成を設定することができます。RMSウィザードは、あら
ゆるタイプのクラスタアプリケーションを制御するRMSの構成を設定することができます。

1.4 RMSウィザードのコンポーネント
RMSウィザードは以下のコンポーネントによって構成されています。

・ RMS Wizard Tools ユーザインタフェース、汎用アプリケーションウィザードおよび基本的なサブアプリケーションウィザードセット。RMS

の基本コンポーネントとして提供されます。

・ RMS Wizard Kit 特定のアプリケーションを構成するための専用ウィザード。追加コンポーネントです。

以下の図に、RMS、RMS Wizard Tools、およびRMS Wizard Kitの関係を示します。

-8-
 図1.9 RMSとRMSウィザードの関係

Solarisでは、これらのRMSの構成設定を行う手段として、Web-Based Admin Viewを利用したGUIであるuserApplication Configuration

Wizardを提供します。グラフィカルな画面でRMSの構成設定を行うことができます。

1.4.1 RMS Wizard Tools

RMS Wizard Toolsは、基本タイプのオブジェクト (ファイルシステムやIPアドレスなど) に対して、以下の機能を提供します。

・ Onlineスクリプト
・ Offlineスクリプト
・ ディテクタ
RMS Wizard Toolsパッケージにはhvwコマンドが用意されています。hvwインタフェースは、RMSの制御下にあるアプリケーションに固有の
情報を入力するための単純なメニュー式インタフェースです。hvwが提供するインタフェースを通じて、アプリケーション固有の情報を動的に
追加し、データセンターで一般に使用されるアプリケーションのターンキーソリューションを提供することもできます。これらのアプリケーション
固有のモジュールは、Wizard for OracleなどのRMS Wizard Kitコンポーネントによって用意されます。

1.4.2 RMS Wizard Kit

RMS Wizard Kitは、各アプリケーションがhvwコマンドを使用するように設定されたモジュールです。このモジュールは、一般的なアプ
リケーションの固有情報をhvwに提供します。これによって、構成設定作業は非常に簡単になります。特定のアプリケーションに対して、以下
の機能も提供されます。

・ Onlineスクリプト
・ Offlineスクリプト

-9-
 ・ ディテクタ

参照
RMS Wizard Kitの可用性の詳細については、Wizard for Oracle、Wizard for Networkerなどの各製品のマニュアルを参照してください。

1.5 Cluster Admin

Cluster Admin GUIは、RMSの中心的な管理ツールです。ユーザはCluster Admin GUIを通じて、以下に示すRMSのクラスタアプリケー
ション制御機能にアクセスできます。

・ クラスタアプリケーションの起動
・ クラスタアプリケーションの停止
・ クラスタアプリケーションの手動切替え
・ 資源とアプリケーションの障害 (Fault) を認識するための視覚情報
・ 故障 (Fault) 状態の回復
・ RMSの起動
・ RMSの停止
・ アプリケーションと資源のRMSグラフ

1.6 RMSコンポーネント
RMSコンポーネントは、クラスタの各ノード上で動作する以下のソフトウェアコンポーネントで構成されています。

・ ベースモニタ
・ ディテクタ
・ スクリプト
・ RMS CLI

1.6.1 BM (ベースモニタ)
BMプロセスは、RMSプロセスグループの意思決定セグメントです。BMには以下の機能があります。

・ オブジェクト、属性、および相互関係により示された現在の構成を保存する
・ Cluster Adminユーザインタフェース (GUI)、またはRMSコマンドラインインタフェース(CLI) からアクション実行要求を受ける
・ 状態の変化を通知するディテクタからの入力を受ける
・ クラスタアプリケーションおよびその依存オブジェクトをOnlineまたはOfflineにするスクリプトを実行する
・ オブジェクトとクラスタアプリケーションを正しい順序でOnlineまたはOfflineにするように、オブジェクト状態変化の順序を指示する
・ オブジェクトまたはノードに障害が発生した場合やユーザからの要求があった場合に、クラスタアプリケーションの自動切替えを、表示
および制御する

・ 各種管理機能を実行する

1.6.2 ディテクタ
ディテクタは、個々のオブジェクトの状態を監視してオブジェクトの状態をBMに返却します。
OSにより提供される機能を監視するディテクタは、RMS Wizard Toolsにより提供されます。その他のアプリケーション固有のディテクタは、
RMS Wizard ToolsおよびRMS Wizard Kitで提供されます。

- 10 -
 RMSの提供するオブジェクトの中には、コントローラオブジェクトなどのように、ディテクタを持たないものがあります。その代わりに、RMSは
遷移中のプロセスや依存資源の状態などの要素に基づいてオブジェクトの状態を計算します。

1.6.3 スクリプト
RMSは構成スクリプトを使用して、オブジェクトの状態変更 (たとえば、OfflineからOnlineへの変更) などのアクションを実行します。構成ス
クリプトには以下の2つがあります。

・ 要求トリガ・スクリプト
要求トリガ・スクリプトはオブジェクトの状態変更を行うスクリプトです。
要求トリガ・スクリプトには以下に示すものがあります。

－ InitScript - RMSの初回起動時に1度だけ実行されます。
－ PreCheckScript - Online処理やStandby処理が可能かを事前に判定します。
－ PreOfflineScript - Offline 状態への移行を準備します。
－ OfflineScript - オブジェクトをOffline状態にします。
－ PreOnlineScript - Online状態への移行を準備します。
－ OnlineScript - オブジェクトを Online状態にします。
・ 状態トリガ・スクリプト
状態トリガ・スクリプトは特定のイベントが発生した場合に実行されるスクリプトです。
状態トリガ・スクリプトには以下に示すものがあります。

－ PostOnlineScript - Online状態への移行に反応します。
－ PostOfflineScript - Offline状態への移行に反応します。
－ OfflineDoneScript - Offline状態に達する userApplicationに反応します。
－ FaultScript - Faulted状態に移行するオブジェクトに反応します。
－ WarningScript - Warning状態を通知するディテクタに反応します。
－ StateChangeScript - スケーラブルコントローラのuserApplicationまたはSysNodeに反応します。
OSにより提供される機能を制御するためのスクリプトは、RMS Wizard Toolsにより提供されます。

1.6.4 RMS CLI

RMS構成設定の中心的なインタフェースはRMS Wizard Toolsであり、RMS管理の中心的なインタフェースはCluster Admin GUIです。
RMS Wizard ToolsもCluster Adminも内部で RMS CLIを呼び出します。たとえば、userApplicationオブジェクトを手動でクラスタ内の他の
ノード (SysNode) に切替える場合、次のCLIコマンドを使用します。

# hvswitch userApplication SysNode

以下の表に管理者が使用可能なRMS CLIコマンドの一覧を示します。RMS CLIコマンドの詳細については、“PRIMECLUSTER 活用ガ

イド＜コマンドリファレンス編＞”を参照してください。

注意

・ 通常、RMS CLIコマンドの実行にはルート権限が必要です。ルート権限が不要な場合を以下の表に示します。

表1.1 使用可能なCLIコマンド
コマンド 機能
hvassert hvassertコマンドは特定のオブジェクト状態のRMSオブジェクトをテストします。このコマンドをスクリプトに
使用して、次のコマンドを発行する前に一定の状態を設定することができます。ルート権限は必要あ
りません。

- 11 -
 コマンド 機能
hvcm hvcmコマンドは、すべての監視オブジェクトに対するディテクタとベースモニタを起動します。通常、
hvcmコマンドのオプションを指定する必要はありません。

ベースモニタはRMSモジュールの意思決定の役割を果たします。ベースモニタはすべてのRMSオブ
ジェクトの設定およびアクセスを制御します。オブジェクトが失敗すると、ベースモニタは失敗を分析し、
構成定義ファイルに指定されているオブジェクト仕様に従って適切な措置をとります。
hvconfig hvconfigコマンドには、現在のRMS構成定義情報を表示する、または現在のRMS構成定義情報を出
力ファイルに出力する、という2つの機能があります。

hvconfigコマンドの出力内容は使用中のRMS構成定義ファイルの内容と基本的に同じですが、元の
ファイルに記述されているコメントは出力されません。また、リソース一覧の出力順序は構成定義ファ
イルと異なる場合があります。
hvdisp hvdispコマンドを実行すると、RMSオブジェクトの現在の RMS構成情報が表示されます。ルート権限は
必要ありません。
hvdispall hvdispallコマンドを実行すると、RMSの全ノードのリソース情報が表示されます。
hvdump hvdumpコマンドは、ローカルノードのRMSの調査情報を取得する場合に使用します。
hvlogclean hvlogcleanコマンドを実行すると、古いログファイルがサブディレクトリに保存されます。ログファイルの名
前はRMSを最後に起動した時刻です (-dオプションを指定すると、古いログファイルが削除されます)。
hvlogcleanを実行すると、RMSが稼動中であっても新しいログファイルが作成されます。
hvsetenv HV_RCSTARTおよびHV_AUTOSTARTUP環境変数を変更するインタフェースを提供します。これ
らの環境変数でRMSやアプリケーション全体の自動起動を個別に制御することができます。本コマン
ドによる変更は、コマンド実行ノードにだけ適用されます。

これらの変数は"付録E 環境変数"に説明されています。
hvshut hvshutコマンドは、1ノードまたは全ノードのRMSを停止します。ローカルノード上のベースモニタは、ど
のノードが停止されるかを伝えるメッセージを他のOnlineノードに送信します。
hvswitch hvswitchコマンドは、userApplication または gResourceの制御を RMS構成内のシステムノード
(SysNode) 間で手動で切替えます。
hvutil hvutilコマンドは、RMSに対する汎用のインタフェースです。以下の管理操作を実行します。
－ログレベルの動的設定
－userApplicationのOffline
－ gResourceのOffline
－障害が発生したリソースのクリア
－Wait状態にあるクラスタノードの停止
－ディテクタの監視間隔設定
－保守モードの設定、その他

・ いくつかの例外 (hvshutなど) を除き、RMSのhv_*コマンドは、ベースモニタに要求を送るのみで直ちに復帰し、要求が処理されるのを

待ち合わせることはしません。終了時の状態コード0 (成功) は、要求がベースモニタに正しく送信されたことを意味します。ただし、こ
れは要求が正しく処理されたことを保証するものではありません。

1.7 オブジェクトタイプ
オブジェクトタイプは、同じディテクタで監視される類似したリソース (すべてのディスクドライブなど) を示します。RMSウィザードで構成定義
ファイルを作成できます。構成定義ファイルにはRMSが監視するリソースを示す各種オブジェクトが含まれています。以下のオブジェク
トタイプがあります。

・ SysNode
ノードを示すオブジェクトです。

- 12 -
 ・ userApplication
クラスタアプリケーションを示すオブジェクトです。

・ gResource
汎用のオブジェクトです。

・ andOp
論理 AND演算子を示すオブジェクトです。

・ orOp
論理 OR演算子を示すオブジェクトです。

・ controller
複数のuserApplicationオブジェクトを制御するオブジェクトです。

使用可能なオブジェクトタイプ、必須属性、各オブジェクトの内容については、"付録C オブジェクトタイプ" を参照してください。

ポイント
上記のオブジェクトは構成設定の段階でRMS Wizard Toolsにより作成します。オブジェクトのタイプは、RMSのメッセージに表示されます。

1.8 オブジェクト属性
属性は、通常の処理におけるベースモニタの動作および特定のオブジェクトに対する反応を指定するオブジェクト定義の一部です。属性
には、デバイス名と構成スクリプトを含めることができます。ユーザはオブジェクト定義で属性を任意の順序で指定できます。
使用可能なタイプ、関連の値、各属性の内容については、"付録D 属性 " を参照してください。

ポイント
属性の値は構成設定の段階でRMS Wizard Toolsにより設定します。"第3章 RMS Wizard Toolsインタフェース (hvw) の使用方法"を参照
してください。

1.9 環境変数
RMSの環境変数には、グローバルとローカルの2つがあります。

・ RMSグローバル環境変数は、クラスタ内のすべてのノードで同じ設定にする必要があります。RMSは、RMSグローバル環境変数を
ENV オブジェクトに保存します。

・ RMSローカル環境変数はRMSグローバル環境変数に優先し、また、ノードごとに異なる可能性があります。RMSは、RMSローカル環
境変数をENVLオブジェクトに保存します。

RMSは、ベースモニタの起動時に、hvenvおよびhvenv.localの内容から、ENVオブジェクトやENVLオブジェクトを動的に生成します。
ENVLオブジェクトの値はENVオブジェクトの値より優先されます。詳細については、"E.1 RMS環境変数の設定" を参照してください。

注意

・ RMS グローバル環境変数 (ENV) の設定は、クラスタ共通の構成定義チェックサムによって検証されます。構成チェックサムは、ベー

スモニタの起動時に各ノードで検査されます。いずれかのノードでチェックサムが異なっていると、RMS の起動は失敗します。

・ RMS ローカル環境変数 (ENVL) の設定は、クラスタ共通の構成定義チェックサムでは検証されません。

RMSの実行中は、hvdisp コマンドでRMS環境変数を表示することができます。ルート権限は必要ありません。グローバルリストには、hvdisp
ENVを使用し、ローカルリストにはhvdisp ENVLを使用します。
すべてのRMSグローバル環境変数およびRMSローカル環境変数の内容については、"付録E 環境変数" を参照してください。

- 13 -
1.9.1 環境変数の設定
起動時に、RMSはhvenvおよびhvenv.localからRMS環境変数の値を読取り、それぞれのノードでENVオブジェクトとENVLオブジェクトを
初期化します。RMSを起動する前にRMS環境変数の値を設定するには、hvenv.localファイルでRMS環境変数を指定する必要があります。
これらの設定はインストール時の省略値に上書きされます。

注意
/tmpディレクトリは、hvenvがRMS環境変数のソートに使用しているため、この空き領域が少なくなるとRMSエラーが発生する場合があります。

RMSのグローバル環境変数を変更する場合は、すべてのノードのhvenv.localファイルに同一の値を設定します。変更を有効にするには、
すべてのノードのRMSを停止後に、RMSを再起動します。

注意
RMS環境変数をユーザ環境で明示的に設定することは避けてください。この操作を行うと、RMS環境変数の設定が失われる場合があります。

RMS環境変数の値は、各ファイルの中で、export文で指定します。export文の例を以下に示します。

export SCRIPTS_TIME_OUT=200

hvenv.localファイルの変更を有効にするには、RMSの再起動が必要です。RMSの稼動中は、次のコマンドを使用してRMS環境変数の値
を表示できます。

・ hvdisp ENV
・ hvdisp ENVL

1.9.2 スクリプト実行環境変数
RMSがスクリプトを起動する時には、実行する処理内容の決定に使用するRMS環境変数を設定します。これらのRMS環境変数はスク
リプトが処理を実行する間のみ存在するため、RMSのユーザ環境または管理者環境からは見えません。稀に、システムログやコンソールの
診断メッセージに含まれる場合があります。
"E.4 RMSスクリプト実行環境変数"では、これらすべての変数について説明しています。

1.10 RMSディレクトリ構造
RMSソフトウェアは、多くの実行可能ファイル、スクリプト、ファイル、およびコマンドで構成されています。これらはすべて、RMS環境変数
RELIANT_PATHで指定されたディレクトリ配下のディレクトリに格納されています。以下の表に、RMSソフトウェアを正しくインストールした後
のディレクトリ構造を示します。

表1.2 RMSの基本ディレクトリ構造
名前 格納されているファイル
RELIANT_PATH 基本ディレクトリ (デフォルト: /opt/SMAW/SMAWRrms)
<RELIANT_PATH>/bin 実行可能プログラム。ディテクタ、コマンド、スクリプトなど
<RELIANT_PATH>/build 構成定義ファイルの作業領域
<RELIANT_PATH>/etc RMSおよび構成ツールで使用するさまざまなファイル
<RELIANT_PATH>/include ディテクタと構成定義ファイルが使用するRMSインクルードファイル (ヘッダファイル)
<RELIANT_PATH>/lib RMS実行ライブラリ
<RELIANT_PATH>/tab ディテクタを再起動する際に使用するテーブル
<RELIANT_PATH>/us RMSソースファイル。RMSのソースファイル (このディレクトリに含まれるファイルの名前は予
約済みなので、ユーザが作成する構成定義ファイルの名前として使用できない。)

- 14 -
以下の表に示すとおり、RMSログファイルは、RMS環境変数RELIANT_LOG_PATHで指定されたディレクトリに保存されています。

表1.3 ログのディレクトリ構造
名前 格納されているファイル
RELIANT_LOG_PATH ログディレクトリ ( デフォルト: /var/opt/SMAWRrms/log)
このディレクトリにあるログファイルを利用してデバッグを行います。
同じディレクトリにRMSログファイルのバックアップコピーを保存するサブディレクトリがあります。
バックアップ用のサブディレクトリにはそれぞれ、yyyy-mm-dd_HH:MM:SS の形式で名前が付
けられ、バックアップが作成された日付と時刻が分かるようになっています。

- 15 -
第2章 RMSの詳細説明
本章では、RMSの詳細について説明します。

2.1 状態遷移
ここでは、RMS状態遷移機構について説明します。特に、各状態の判別はどのようにして行われるのか、RMSはどのようにして状態変化を
起こし、またどのようにして状態の変化に対応するのかについて説明します。
本章では、グラフ理論でいうノード (節点・頂点) のことをクラスタノードと区別するために、グラフノードと呼んでいます。

2.1.1 内部機構
RMSをより理解しやすくするため、オブジェクト指向の考え方に基づき、RMS BM (ベースモニタ) の内部機構を簡単に説明します。
個々のオブジェクトは、自らの状態およびディテクタ等の他のオブジェクトから受信したメッセージに基づき、定められた規則に従って動作
する (通常はシェルスクリプトで実装されています) 独立したインスタンスです。状態、ディテクタ、スクリプトについては、"第1章 概要"で説明
しています。以下のセクションでは、RMSの内部構造とオブジェクト間通信について詳しく説明します。

2.1.1.1 アプリケーションと資源の記述
RMSウィザード は、RMSの監視対象であるすべてのアプリケーションの記述を生成します。この記述では、RMS固有のメタ言語を使用し、
以下の特徴を持つ論理グラフによってすべてのアプリケーションを表現します。

・ アプリケーションが必要とする資源は、このグラフ中のオブジェクトで表す。
・ オブジェクト間の親子関係は、それを表す資源間の依存関係を表す。
・ オブジェクトの属性とは、各種資源の特性と、その資源にとって必要とされる動作を表す。
特定のオブジェクトをOnlineにしたり、Offlineにしたりする場合の事前の手順は、オブジェクトの属性として設定されたシェルスクリプトに記述
されます。また、他のオブジェクトからのメッセージを受けて、オブジェクトの状態遷移に対応して実行されるべき処理を記述するスクリプ
トもあります。
userApplicationオブジェクトにはディテクタがありません。また、 PCSRMS Wizard Toolsまたは、RMS Wizard Kitによって作成される場合
には、スクリプトも指定されません。しかし、子であるcmdlineリソースには適切なスクリプトが与えられます。オペレーティングシステム環境
において、実際のユーザ業務と通信を行うのはこのオブジェクトです。この場合、userApplicationはRMSグラフにおける資源の複合状態を
表す論理的なシンボルになります。

2.1.1.2 メッセージ
RMSオブジェクトは以下の目的でメッセージ通信を行います。

・ 他のオブジェクトへ要求を送信する。
・ オブジェクトの状態変化を通知する。
通常、オブジェクトは直接の親と子のみ通信を行います。
RMSは受信した外部要求を、まず親userApplicationオブジェクトへ送信し、それから子に転送します。userApplicationオブジェクトは、状態
の変化 (Faulted状態への状態の遷移など) に基づいて固有の要求を生成することもできます。userApplicationオブジェクトから発生する
要求は、親から子へ転送されます (トップダウン)。

2.1.2 初期化
RMSが起動すると、すべてのグラフノードの初期状態はUnknownとなります。RMSは、個々のグラフノードが自らの状態を判断するために
必要な情報を獲得してから、この状態を変更します。
グラフノードが自らの状態を判断するために必要な情報とは、以下のとおりです。

・ ディテクタを保持するグラフノードの場合－ディテクタからの最初の通知
・ 子を持つグラフノード－子の状態に関するメッセージ

- 16 -
上記より、以下の2つの結論が導き出されます。

・ ディテクタの存在しないリーフノードは、ディテクタからの通知を受けることがなく、かつ、グラフノードの状態を子の状態からも類推す
ることができないことになります。この場合、Unknownの状態が残ってしまうため、RMS構成としては認められない構成となります。

・ Unknownからの状態遷移は、リーフノードからuserApplicationオブジェクトへと続くボトムアップ形式で行われます。リーフノードの上位
グラフノードはすべて、自己の状態を識別するためには、まず、子の状態を取得する必要があります。

ポイント
SysNodeオブジェクトおよびuserApplicationオブジェクトには、対応するハードウェアのディテクタがありません。SysNodeオブジェク
トはベースモニタから直接ディテクタのレポートを受信します。 userApplicationオブジェクトの状態は、その子の状態から判断します。

userApplicationオブジェクトの状態がUnknownから変更された段階で、userApplicationの初期化処理が完了し、RMSの制御が開始さ
れます。
userApplicationオブジェクトの初期化プロセスは、互いのuserApplicationに対して無関係で行われます。したがって、あるuserApplication
オブジェクトがOnline、OfflineまたはStandbyの状態に変化しても、他のuserApplicationオブジェクトはUnknownの状態のままである場合
があります。
SysNodeオブジェクトの初期化プロセスもまた、他とは無関係に行われます。SysNodeオブジェクトは、ディテクタの通知を受信した後に初期
のUnknown状態から他の状態へ遷移します。
Unknown状態は初期状態のときのみ存在し、一度Unknown状態から他の状態へ変化したグラフノードが、Unkwnon状態に戻ることは
ありません。

構成例
以下にfuji2RMSおよびfuji3RMS上で実行するよう構成設定されたアプリケーションappを例にとってRMSの処理を説明します。

・ fuji2RMSおよびfuji3RMSの各ノードには、そのノードと同じ名前のSysNodeオブジェクトが1つ存在します。
・ アプリケーションが実行される各SysNodeでは、対応するuserApplicationオブジェクトがタイプandOpの子を持ち、これらの子にはこの
SysNodeの名前がHostName属性として与えられています。このアプリケーションでのノードの優先順位は、userApplicationオブジェ
クトでノードを定義した順序によって決定します。
ベースモニタはこのレベルのandOpオブジェクトについて、HostName属性の値がローカルノード名に対応すればローカルオブジェ
クトであると判断し、対応しなければリモートオブジェクトと判断します。 ベースモニタは、すべてのリモートオブジェクトを無視します。
このため、ローカルオブジェクトとその子だけが処理されます。

・ この論理ANDオブジェクトの子として、他の資源 (Cmdlineサブアプリケーションやローカルファイルシステム) がそれぞれの内部的な

依存関係に基づいて構成されます。

オブジェクト階層を以下の図に示します。

図2.1 初期化の例におけるオブジェクト階層

図の階層には、アプリケーションの親として、SysNodeオブジェクトが含まれています。慣例で記載されることがありますが、SysNodeオブ
ジェクトはいかなる形でもアプリケーションオブジェクトに依存していません。しかし、SysNodeオブジェクトを記載することにより、アプリケー
ションの子であるandOpオブジェクトがどのノードを表しているのかが明確になります。SysNodeオブジェクトはGUIが生成するグラフにも表示
されますが、その場合は、アプリケーションが現在実行されているノードを示すことが主目的です。

- 17 -
RMS Wizard Toolsによって作成されたこの構成のRMSグラフを以下に示します。

図2.2 初期化におけるシステムグラフの例－RMS Wizard Toolsの構成

タイトルバーにはグラフが描かれたノードの名前fuji2RMSが表示されます。fuji2RMSとappを結ぶ線は緑です。これはノードにOnlineの
アプリケーションがあることを示しています。
以下は、「hvdisp -a」による出力を示しています。

図2.3 初期化におけるhvdisp出力の例－RMS Wizard Toolsの構成

- 18 -
 hvdispの出力に対応させるため、実際のグラフにはリソース名のデータも含まれています。リソース名は、Cluster Adminの [rms] タブ表示
のグラフで [Preferences] メニューから [Show Resource Names] を選択することにより表示されます。
RMS Wizard Tools によって実際に生成されるオブジェクト名には、図2.1 初期化の例におけるオブジェクト階層のオブジェクト名よりも複雑
な名称が使われていることがあります。図2.1 初期化の例におけるオブジェクト階層は、一般的なオブジェクト名を使用した抽象化され
たグラフです。さらに実際のグラフには、正しい動作を保証するために、依存関係が自動的に挿入されています。 Cluster Adminの
[Preferences] メニューから別の項目を選択すると、さらに詳細な項目や追加のオブジェクトおよび依存関係が表示されます。
実際のグラフに出現する追加項目や複雑な名称についての知識は、RMSの動作の基本を理解する上では必要ありません。 説明を簡単
にするため、この章の例では主に抽象化されたグラフと一般的な名称を使います。

例1
図2.1 初期化の例におけるオブジェクト階層に示された構成では、以下のような処理が順に行われます。これはfuji2RMSで動作するモ
ニタの場合でも同じです。

1. RMSが起動します。
2. SysNodeオブジェクトのディテクタはクラスタノードの状態をベースモニタに通知します。
3. cmdおよびlfsリソースのディテクタは、それぞれの状態をOfflineと報告します。
4. lfsはリーフノードであるため、即座にOffline化して、その状態変化を親に通知します。
5. ディテクタの通知と子の通知を受信すると、cmdには、それぞれの状態を決定するために必要な情報が揃ったことになります。cmdは
Offline化し、その状態変化を親andOp1に通知します。

ポイント
andOp2は、fuji2RMSのベースモニタにより無視されるリモートノードです。

6. andOp1は、ディテクタを持たない論理オブジェクトです。このオブジェクトは子のメッセージを利用して自らのOffline状態を検出し、
その状態変化をappに通知します。

7. appも、ディテクタを持たないオブジェクトです。ローカルノードに対応する子andOpがOffline化すると、appもOffline化します。
8. appのローカル子オブジェクトすべてが、Unknown状態に遷移すると、初期化プロセスは完了します。

2.1.3 Online処理
userApplicationオブジェクトをOnline処理すると、通常userApplicationがOnline状態に遷移します。1つのuserApplicationオブジェクトの
Online処理は、他のuserApplicationオブジェクトのOnline処理とは無関係で独立に行われます。
以下のような状況が発生すると、userApplicationのOnline処理が正しく終了しない場合があります。

・ PreCheckScriptでuserApplicationをOnlineにすべきではないと判断された。
・ Online処理中に異常 (Fault) が発生した。
これらの場合について、以下のセクションで説明していきます。

2.1.3.1 Online要求
Online 要 求 を 生 成 す る こ と を userApplication の 切 替 え と 呼 び ま す 。 こ れ は 、 userApplication を Online に 切 替 え る こ と 、 ま た は
userApplicationを他のクラスタノードに切替えることを意味しています ("2.1.6 切替え処理"も参照してください)。
以下の操作でOnline要求を生成することができます。

・ GUIまたはCLI (hvswitch) を使った手動要求

・ GUIまたはCLI (hvcm) を使ったRMS起動時の自動要求
・ アプリケーションのAutoSwitchOver属性によって制御される自動要求:
－ AutoSwitchOverに、ResourceFailureを設定しており、障害 (Fault) が発生した場合
－ AutoSwitchOverに、ShutDownを設定しており、ノードが停止した場合

- 19 -
 － AutoSwitchOverに、HostFailureを設定しており、ノードが強制停止した場合

手動方式
手動方式を使用する場合でも、userApplicationには、以下の2つの切替方式があります。切替方式は以下のとおりです。

・ 優先切替え－RMSがuserApplicationをどのSysNode上でOnlineにするかを選択します。userApplicationはRMSによって最も優先順
位の高いSysNodeへ切替えられます。userApplicationオブジェクトのPriorityList属性の順序によって、SysNodeオブジェクトの優先
順位は決定します。

・ 指定切替え－ユーザがuserApplicationをどのSysNode上でOnlineにするかを選択します。userApplicationは指定されたSysNodeへ
切替えられます。

優先切替えの場合も、指定切替えの場合も、切替え先として指定できるSysNodeオブジェクトは、その状態がOnlineでなければなりません。
GUIを使った手動要求
GUIを使ってOnline要求を生成するには、以下の手順で行います。

1. RMSグラフ上で、userApplicationを右クリックします。ポップアップメニューが表示されます。
2. ポップアップメニューの [切替え] または [Online] を左クリックします。
CLIを使用した手動要求
各userApplicationへのOnline要求は、hvswitchを使用します。hvswitchコマンドの使用方法とオプションについては、hvswitchのマ
ニュアルページを参照してください。

自動方式
自動方式では、userApplicationは優先切替えのみで動作します。
RMS起動時の自動要求
クラスタシステムでRMSを最初に起動した時に、以下の条件すべてが満たされていると、RMSは最も優先順位の高いクラスタノード上で
userApplicationをOnlineに切替えます。

－ userApplicationに関連付けられた全SysNodeオブジェクトがOnlineになっている。
－ 他のクラスタノードでuserApplicationがOnlineおよび不整合 (Inconsistent) になっていない。
－ userApplicationのAutoStartUp属性が設定されている。
－ userApplicationのグラフにFaulted状態のオブジェクトがない。
これは、同時に複数のクラスタノードでuserApplicationがOnlineに遷移しないために必要な条件です。
userApplicationが起動後すでにOnline状態にあれば、AutoStartUpが設定されていない場合やすべてのSysNodeがOnline状態にな
い場合でも、userApplicationに対する自動起動要求が直ちに生成されます。これは、OnlineのuserApplicationのグラフを整合状態に
することを目的としています。そうでないと、Online状態のアプリケーションのグラフにOfflineのオブジェクトが存在する恐れがあります。
障害 (Fault) 発生時の自動切替え
userApplicationで異常 (Fault) を検出した場合、またはuserApplicationが動作中のSysNodeの異常 (Fault) を検出した場合、RMSは
優先切替えを起動します。自動切替えは、userApplicationのAutoSwitchOver属性によって、以下のとおり制御されます。

－ AutoSwitchOverに、ResourceFailureを設定しており、障害 (Fault) が発生した場合

－ AutoSwitchOverに、ShutDownを設定しており、ノードが停止した場合
－ AutoSwitchOverに、HostFailureを設定しており、ノードが強制停止した場合
AutoSwitchOverがNoに設定されていると、自動切替えは行われません。

2.1.3.2 PreCheckScript
Online処理を開始する前に、PreCheckScriptで、Online処理が必要かどうか、または可能かどうかが確認されます。この処理が必要な理由
は、一部のアプリケーションがOnline処理で起動できず、Faulted状態になることを避けるためです。

- 20 -
 PreCheckScriptは、Online処理が開始する前に起動され、Online処理が必要かどうかを判断します。その判断基準はPreCheckScriptが0で
終了 (正常終了) することです。PreCheckScriptが0以外の終了コードで終了した場合は、Online処理は破棄され、警告メッセージが
switchlogに記載されます。

PreCheckScriptの終了結果
PreCheckScriptが起動すると、userApplicationの状態はWait状態に遷移します。PreCheckScriptが失敗すると、userApplicationグラフノー
ドは以前の状態 (通常はOfflineまたはFaulted) に戻ります。

AutoSwitchOver
PreCheckScriptが失敗し、AutoSwitchOver属性にResourceFailureが設定されている場合は、指定切替え要求の場合を除き、Online要求
は自動的に次に優先順位の高いクラスタノードに転送されます。(指定切替え要求の場合を除く)

2.1.3.3 userApplicationのRMSグラフにおけるOnline処理
PreCheckScript が成功した場合、ベースモニタはPreOnline 要求を生成します。リソースグラフと比較して、 PreOnline 要求処理は以下の
とおりです。

1. 要求が親グラフノードから、子のグラフノードへ送信される。
2. 親のグラフノードはWait状態になる。ただし、スクリプトは起動されない。
3. 子グラフノードが要求を受け、リーフノードでPreOnlineScriptが起動される。
4. スクリプトが終了すると、親グラフノードへ確認を送信する。
5. すべての子が確認を送信し終ると、その親のグラフノードでPreOnlineScriptが実行される。
上記の手順は、RMSグラフに関連して、Online処理におけるスクリプトがボトムアップ方式で実行されることを示しています。
userApplicationグラフノードは、PreOnlineScriptを実行する最後のグラフノードであり、PreOnlineScriptの実行後にOnline要求を生成し、
その要求をリーフノードへ送ります。ただし、Online処理とPreOnline処理は異なる処理です。
RMSグラフに関するOnline処理は以下のとおりです。

1. RMSがOnlineScriptを実行する。
2. 個々のグラフノードのディテクタがOnline状態を通知するまでシステムは待ち続ける。グラフノードにディテクタが存在しない場合は、
OnlineScript終了後、Online状態の送信を待たずにPostOnlineScriptを実行する。

3. PostOnlineScriptが実行される。
4. Online処理の成功が親グラフノードへ転送される。
5. 親グラフノードがWait状態からOnline状態へ遷移する。
RMSでは、「userApplicationがOnline状態である」ということは、userApplicationを構成するすべてのグラフノードがOnline状態であるこ
とになります。ここでいうOnline状態とは、実際のアプリケーションの状態を示すものではありません。実際のアプリケーションはRMSで制御
されてはいないか、userApplicationオブジェクト (より一般的にはcmdlineの子オブジェクト) 用に構成設定されたOnlineScript
(PostOnlineScriptの場合もある) で起動されているかのいずれかになります。userApplicationオブジェクトがOnline状態であるということは、
スクリプトの実行が正常に終了したことを示しているだけです。

注意
スクリプトが実際のアプリケーションの状態にどのような影響を及ぼすのかは、アプリケーション自身によって決まります。RMSはユーザ業務
に対し直接の制御は何ら行いません。詳細については、"1.2.2 RMS構成と実システム"を参照してください。

例2
この例での処理の流れは次のとおりです。

・ AutoStartUp属性がyesに設定されている。
・ PreOnlineScript定義を持つリソースオブジェクトがない。

- 21 -
 ・ 起動時に、すべてのオブジェクトがOffline状態である。
Online処理は次のとおりです。

1. RMSが起動します。
2. AutoStartUp属性がyesに設定されているため、fuji2RMS上のuserApplicationオブジェクトappがPreOnline要求を生成します。
3. この要求は、lfsリーフノードに転送されます。この例ではPreOnlineScriptが構成設定されたオブジェクトが存在しないため、lfsは、app
に対してPreOnline処理が正常終了したことを示すメッセージを送信します。

4. appはPreOnline完了のメッセージを受信すると、Online要求を生成し、lfsリーフノードに送信します。
5. lfsオブジェクトがOnlineScriptを実行し、ディスクをOnline化します。
6. lfsのディテクタがOnlineの通知を行うと、Online処理の成功が直ちにcmdオブジェクトに向かって上方に通知されます (オブジェクトに
PostOnlineScriptが存在した場合は、成功メッセージが転送される前に実行されています)。

7. cmdオブジェクトが自らのOnlineScriptを起動します。
8. cmdのディテクタが成功の通知を行うと、そのメッセージは直ちにandOp1に転送されます。
9. andOp1オブジェクトはディテクタを持たないオブジェクトで、この例ではOnlineScriptも持っていません。ローカルの子からOnline 状態
の通知があると、直ちに自らの親オブジェクトに対してapp成功のメッセージを転送します。

10. appで成功メッセージを受信すると、RMSがOnlineScriptを実行し、アプリケーションが起動します。appにディテクタが存在せず、
PostOnlineScriptが設定されていないため、appはOnlineScriptの完了直後にOnline状態に変化します。

2.1.3.4 Online処理中の予期しないレポート
Online処理中の予期しないレポート（Unexpected report）とは、Online処理中に通知されるが、BM（ベースモニタ）により無視されるOnline
状態以外のレポートのことです。
BM（ベースモニタ）により無視されるOnline状態以外のレポートは、あるオブジェクトが属するユーザアプリケーションのOnline処理が開始
してから、そのオブジェクトのOnline処理が成功または失敗するまでの間に通知されることがあります。
なお、オブジェクトのOnline処理が失敗するケースについては、"2.1.3.5 Online処理中のFault"を参照してください。

2.1.3.5 Online処理中のFault
Online処理中にエラーが発生すると、影響するグラフノードはFault処理を開始し、親グラフノードにエラーを通知します （"2.1.5 Fault処理"も
参照してください）。Online処理中に異常が発生するのは、以下のような場合です。

a. Online処理終了時点で、あるリソースオブジェクトのディテクタから最後に報告された状態がOfflineまたはFaulted状態である場合。
b. スクリプトが0以外の値で終了した。
c. スクリプトが復帰せずタイムアウトになり実行に失敗した。
d. オブジェクトのOnlineScriptが完了し、ディテクタから一定時間内にOnline状態が通知されなかった。
条件 a の場合は、オブジェクトが属するuserApplicationのOnline処理が 完了した後にFault処理が開始されます。
反対に、条件 b、cおよびdの場合は、条件が満たされるとすぐにFault処理が開始されます。

2.1.3.6 アプリケーションがすでにOnline状態にある場合の初期化処理
RMSの初期化時にuserApplicationのRMSグラフ全体がOnlineになっている場合があります。この場合、PreCheckScriptは実行されず、関
連するグラフノードはUnknown状態からスクリプトを起動せずに直接Online状態に遷移します。

Online時の要求
userApplicationがすでにOnline状態である場合にOnline要求を受信すると、その要求は他のグラフノードに通常どおりに転送されま
す。"2.1.3 Online処理"での説明との相違点は、すでにOnline状態のグラフノードが要求や応答を転送する場合、スクリプトの実行もWait
状態への遷移も行われないということです。特にPreCheckScriptは実行されません。
RMSの初期化時に常にOnline状態になっているオブジェクトの典型例は、物理ディスクのgResourceオブジェクトです。物理ディスクは通常、
ソフトウェアインタフェースでは停止できないからです。

- 22 -
Online時の要求が存在しない場合
userApplicationがすでにOnline状態にあり、RMSが初期化済の場合に、Online要求が受信されないと、userApplicationはあたかも明示的
なOnline要求を受信したかのように、自らのグラフのOnline処理を実行します。この結果、ローカルグラフの状態は前の例とまったく同じ
になります。

アプリケーションがすでにOnline状態にある場合にデータの喪失を防止する
RMSの主な目的は、同じアプリケーションがクラスタ内の複数のノードに対して同時に処理を行った場合のデータ喪失を防止することに
あります。このため上記のいずれの例でも、アプリケーションのグラフのOnline処理が終わると、ローカルノードのベースモニタは
userApplicationオブジェクトがOnline状態にあることを他のノードのベースモニタに通知し、対応するアプリケーションがクラスタ内の他の
場所でOnline化するのを防止します。

注意

・ RMSの初期化直後に複数のクラスタノードでHA型であるuserApplicationがOnlineになっていると、重大な問題が発生する可能性が
あります。この場合、RMSはFATAL ERRORメッセージを生成して、以後のuserApplicationに対する要求を抑止します。これにより、
クラスタの不整合によって発生する障害の可能性を最小限に抑えます。

・ このセクションで説明した状況は、手動介入の結果です。手動介入の間にアプリケーションのインスタンスが完了していたり、ディスク
資源が複数ノードで実行されていたりすると、RMSが初期化される前にデータの不整合が生じている恐れがあります。

2.1.4 Offline処理
Offline処理の結果、userApplicationオブジェクトの状態はOffline状態へと遷移します。

2.1.4.1 Offline要求
Offline要求は、以下のいずれかの理由で生成されます。

・ GUIまたはCLI (hvutil -f) を使った手動Offline要求

・ GUIまたはCLI (hvswitch) を使った手動切替え要求
・ 障害 (Fault) 発生後の、自動またはGUIまたはCLI (hvutil -c) を使ったOffline処理
・ GUIまたはCLI (hvshut) を使ったRMSのシャットダウン
運用時では、RMSコマンドインタフェースのみがOffline要求を生成することができます。異常 (Fault) が発生した場合、userApplicationは自
らのOffline要求を生成し、問題のあるアプリケーションが動作し続けることを防止します （"2.1.5 Fault処理"も参照してください)。このOffline
要求は、その後に続く切替えが実施されるための前提条件としても必要な要求です。

注意
userApplicationオブジェクトのOffline処理は、RMSが「hvshut -L」または「hvshut -A」で停止された場合には実行されません。

2.1.4.2 userApplicationのRMSグラフにおけるOffline処理
Online処理と異なり、Offline処理はuserApplicationグラフノードからリーフノードへとトップダウン形式で行われます。ディテクタが存在し
ないグラフノードでは、OfflineScriptの実行直後にPostOfflineScriptが実行されます。Offline処理の流れを以下に示します。

1. userApplicationがWait状態に遷移する。
2. userApplicationはPreOfflineScriptを実行し、PreOfflineScriptの終了後、該当する要求を子へ送信する。
3. PreOffline要求の受信後、子のグラフノードはWait状態へ遷移し、自分のPreOfflineScriptを実行し、要求を転送する。
4. リーフノードでは、PreOfflineScriptの実行が完了すると、該当するメッセージ (PreOffline処理の完了通知) を親オブジェクトに転送
する。

5. メッセージはそれ以上の処理をすることなく、userApplicationへ到達するまで子から親へと転送される。

- 23 -
 6. PreOfflineScriptの処理が完了してから、userApplicationはOfflineScriptを実行し、その直後にPostOfflineScriptを実行する
(userApplication自体のグラフノードはディテクタを保持しないため)。

7. userApplicationが実際のOffline要求を生成する。
次に示すように、Offline要求の処理はOnline処理と同様に行われます。

・ はじめにOfflineScriptを実行する。
・ オブジェクトのディテクタによるOffline通知を受けた後、PostOfflineScriptを起動する。
・ PostOfflineScriptの完了後、Offline要求をオブジェクトの子それぞれに転送する。
・ すべての子からPostOfflineDoneメッセージを受信したら、オブジェクトはPostOfflineDoneメッセージを親に送信する。
前述したように、userApplicationは最後にOfflineとなるグラフノードです。最後の子からPostOfflineDoneメッセージを受信するとOffline処
理が完了します。OfflineDoneScriptが存在する場合は起動され、ベースモニタは他のノード上の対応するuserApplicationオブジェクトに、
アプリケーションがOfflineになったことを通知します。

例3
Offline処理についてさらに詳しく説明します。

1. 例ではPreOfflineScriptを持つノードが存在しないため対応するPreOffline要求はappからリーフノードに転送されます。
2. リーフノードは成功メッセージをuserApplicationに返します。
3. userApplicationはOfflineScriptを実行します。これは、この例ではアプリケーションappが停止したことを意味します。オブジェクトapp
がアプリケーションの監視を行っていないため、RMSは、OfflineScriptの完了によりOffline処理が成功したものと判断します。

4. PostOfflineScriptが構成設定されていないため、OfflineScriptが完了すると直ちにOffline要求がandOp1に送信されます。
5. andOp1オブジェクトにはディテクタもスクリプトも存在しません。Offline要求は転送可能です。
6. cmdオブジェクトは、OfflineScriptを実行し、オブジェクトのディテクタがOffline処理の完了を通知するとすぐに、要求を転送します。
7. lfsリーフノードもまた、OfflineScriptを実行し、ディテクタから対応した通知を受信した後に成功メッセージを転送します。
8. appが成功メッセージを受信すると、Offline処理は完了します。
9. Offline処理が完了すると、OfflineDoneScriptを実行します。このスクリプトはクリーンアップまたは情報送信を目的とするスクリプトです。
リターンコードがuserApplicationの状態に影響することはありません。

2.1.4.3 Offline処理中の予期しないレポート
Offline処理中の予期しないレポート（Unexpected report）とは、Offline処理中に通知されるが、BM（ベースモニタ）により無視されるOffline
状態以外のレポートのことです。
BM（ベースモニタ）により無視されるOffline状態以外のレポートは、あるオブジェクトが属するユーザアプリケーションのOffline処理が開始
してから、そのオブジェクトのOffline処理が成功または失敗するまでの間に通知されることがあります。
なお、オブジェクトのOffline処理が失敗するケースについては、"2.1.4.4 Offline処理中のFault"を参照してください。

2.1.4.4 Offline処理中のFault
Offline処理中にエラーが発生すると、影響するグラフノードはFault処理を開始し、親グラフノードにエラーを通知します （"2.1.5 Fault処理"も
参照してください）。Offline処理中に異常が発生するのは、以下のような場合です。

・ Offline処理終了時点で、あるリソースオブジェクトのディテクタから最後に報告された状態がOnline、StandbyまたはFaulted状態である
場合。

・ スクリプトが0以外の値で終了した。
・ スクリプトが復帰せずタイムアウトになり実行に失敗した。
・ オブジェクトのOfflineScriptが完了し、ディテクタから一定時間内にOffline状態が通知されなかった。

- 24 -
2.1.4.5 グラフノードがすでにOffline状態である場合
Offline処理の開始時に、グラフノードがすでにOffline状態になっている場合があります。これが発生するのは、通常、親userApplicationが
OfflineであるノードからOffline要求が出された場合です(親userApplicationがOnlineであれば、Offline状態のグラフノードはツリーでOR
グラフノードの下に表示されます)。 OfflineオブジェクトがOffline要求を受信すると、Online処理の時と同様に、その要求はそのまま転送
されます。スクリプトは実行されず、状態はWaitにはなりません。

2.1.4.6 オブジェクトをOffline状態にすることができない
RMSは、スクリプトがOffline状態にできない資源の監視にも対応することができます。たとえば物理ディスクは監視対象とすることはできても、
通常は物理的にシャットダウンできないオブジェクトとなります。このような例に対処するため、RMSでは真のOffline状態が存在しない資源を
LieOffline属性を使ってグラフノードとして表します。 RMS Wizard Toolsサブアプリケーションはこの属性を、物理ディスクを表すgResource
オブジェクトにデフォルトで設定するため、明示的に指定する必要はありません。
Offline処理中、LieOffline属性が設定されたグラフノードは、Pre-OfflineScript、OfflineScript、Post-OfflineScript実行時も他のオブジェ
クトと同じように動作します。親オブジェクトに関連するオブジェクトの反応もまた同じで、オブジェクトがOfflineになったものとして扱われます。
LieOffline属性が設定されたオブジェクトは、OfflineScriptの実行後、ディテクタのOffline通知を待たずにPostOfflineScriptが自動的に実
行されます。OfflineScriptも実行以後に予期しないディテクタのOnline通知が届いても、この場合はFaulted状態とはなりません。

2.1.5 Fault処理
異常 (Fault) 状態の対処は、RMSの最も重要な機能です。RMSの障害処理方法は、アプリケーションの状態によって異なります。たとえば、
実行中のアプリケーションのRMSグラフで発生した障害 (Fault) は、Offline状態のRMSグラフで発生した障害 (Fault) の対処とは異なります。

2.1.5.1 Online状態または要求処理中のFault
ディテクタがOnline状態のグラフノードの異常 (Fault) を検出し、かつ、そのグラフノード上のuserApplicationもOnline状態だった時は、RMS
はそのグラフノードのFaultScriptを実行します。Online状態だったグラフノードがOffline状態となったことがディテクタで検出された場合は、
要求が存在しなくても同じFaulted状態であるとして処理されます。
FaultScriptの完了後、RMSはFaultが発生したグラフノードの親に対してFault状態を通知します。親グラフノードでも同様にFaultScriptが
実行され、Faultメッセージを転送します。
orOpグラフノードの場合は特殊で、子の状態の論理ORを通知します。ORグラフノードがFaultメッセージに反応するのは、Online状態の子
グラフノードが存在しない場合のみです。orOpがOnline状態の子グラフノードが存在する場合は、RMSはこの段階でFault処理を終了し
ます。
orOpグラフノードによるFault処理中断がなければ、FaultメッセージはuserApplicationに到達します。ここで、userApplicationはFaultScript
を実行します。この処理では、以下のAutoSwitchOverとPreserveStateの属性の組合せに従って、3種類の設定が考えられます。

・ AutoSwitchOverにResourceFailureが設定されている
・ AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=1 である
・ AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=0 であるか設定されていない

AutoSwitchOverにResourceFailureが設定されている
AutoSwitchOver属性にResourceFailureが設定されていると、RMSはPreserveState属性を無視してAutoSwitchOver属性だけが設定され
ているものとして処理を行います。この場合の処理の流れを以下に示します。

1. userApplicationは切替え処理を実行しようと試みます。切替えを行うためには、そのクラスタノード上でuserApplicationがOffline状態
になっていなければならないため、Offline要求が発生します。

2. Offline処理が完了すると、Online要求がリモートクラスタノードの該当するuserApplicationに送信されます ("2.1.6 切替え処理"を参

照してください)。ただし、通常のOffline要求の場合と異なり、userApplicationはOffline状態ではなく、Faulted状態となります。これ
により、再度切替えが行われても、userApplicationが異常の発生したクラスタノードに戻る可能性がなくなります。

Offline処理中にさらに異常 (Fault) が発生した場合 (たとえば、Faulted状態として通知されたグラフノードに対応する資源を、RMSが正常に

非活性化 (Offline) できなかった場合など) は、切替え処理は実行されません。これは、対象資源が未定義状態 (使用されているかい
ないかが判断できない) と判断されるためです。userApplicationはこれ以上のアクションを起こさず、すべての非強制である外部要求を抑止
します。

- 25 -
 ポイント
Offline処理中に発生した故障 (Fault) は、Double Faultと呼ばれます。
RMSはこの状態 (Double Fault) を解決することができないため、システム管理者の介入が必要となります。この場合、「データ破壊防止は、
業務の可用性維持よりも重要」という方針で対処してください。
重要なユーザ業務である場合は、userApplication構成時に、HaltFlag属性を設定することができます。HaltFlag属性が設定されている場合
は、Double Faultが発生した場合、Double Faultが発生したクラスタノードは他ノードから強制停止され、RMSは他のノードへ
userApplicationの切替えを行います。

AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=1
この場合の処理の流れを以下に示します。

1. FaultScriptの実行後、userApplicationはそれ以上の処理を行わない。
2. 全グラフノードの状態は現在の状態を保持する。
このPreserveState属性は、オブジェクトが監視している対象資源を、アプリケーション自らが修復可能な場合に使用されます。

AutoSwitchOverにResourceFailureの設定がなく、かつPreserveState=0または設定なし
この場合、障害 (Fault) 発生時にOffline処理が実行されます。しかし、Offline処理が成功しても失敗しても切替えは行われません。

切替え要求保留中のFault
Offline処理中に切替え要求で障害 (Fault) が発生した場合は、AutoSwitchOver属性がNoに設定されていても障害 (Fault) 発生による
Offline処理の成功、かつ終了後に切替えが行われます。これは、システム管理者によって送信された切替え要求により、切替え要求自体
が発生しているためです。現在の切替え要求が指定切替え要求である場合は、切替え先は最も優先順位の高いノードではなく、指定切替
え要求で明示的に指定されたノードになります。

参照
AutoSwitchOverとPreserveState属性の詳細については、"付録D 属性 "を参照してください。

2.1.5.2 Offline Fault

ノード上のアプリケーションがOnline状態でない場合でも、RMSグラフ上でそのノードにアプリケーションが構成されていれば、RMSは監視
を継続します。このようなグラフノードの1つで異常 (Fault) が発生し、ディテクタが検出すると、Faultが表示されますが、Fault処理は行われず、
したがって、FaultScriptも実行されません。親グラフノードへのメッセージも送信されません。
この場合、1つの子オブジェクトがFaultedであっても、andOpオブジェクトはOffline状態となる可能性があります。
これは、userApplicationグラフ内のグラフノード間の必須依存関係は、userApplicationを実行する場合にのみ存在するためです。

2.1.5.3 AutoRecover属性
ローカルファイルシステムを表すgResourceオブジェクトは、復旧が簡単で、かつ、Faulted状態に陥りやすいオブジェクトの一例です。グ
ラフノード自体に発生する障害 (Fault) の原因は、ディスクのI/Oエラーを除けば、ほとんどの場合は管理者によるumount(1M) の誤操作が
原因です。この場合、userApplication全体を切替えることは、最善のリカバリ処理とは言えません。したがって、Fault処理が最適な解決策
でもありません。
このような場合の対処としては、管理者がオブジェクトのAutoRecover属性を設定する方法が考えられます。AutoRecover属性を設定し
たオブジェクトがOnline状態で異常 (Fault) が発生すると、FaultScriptの実行前にOnlineScriptが実行されます。OnlineScriptの実行後、
一定時間内にオブジェクトがOnline状態になれば、Fault処理は行われません。
障害 (Fault) の原因がグラフノード自身にある場合、つまり、子のグラフノードの障害 (Fault) が原因ではない場合は、RMSはAutoRecover
属性のみを評価します。したがって、RMSはディテクタが存在するグラフノードのAutoRecover属性のみを評価することになります。なお、
各種要求の処理中、または、グラフノードがOffline状態で障害 (Fault) が発生した場合は、AutoRecover属性による復旧は行われません。

- 26 -
2.1.5.4 Offline処理中のFault
Offline処理中に障害が発生しても、グラフノードのOffline処理が直ちに停止することはありません。その時点のツリーのFaulted状態が保存
され、リーフノードに到達するまで通常のOffline処理が継続します。しかし、成功または失敗のメッセージが上方のuserApplicationに向けて
伝播され、途中でそのグラフノードに到達した時点で、この障害は再現されて処理されます。この方法により、障害を発生直後に処理す
ることによって生じる競合状態の発生を回避することができます。

2.1.5.5 Fault処理の例
Fault処理の例を以下に示します。

例4
この例での処理の流れは次のとおりです。

・ アプリケーションappは、AutoSwitchOver属性がNoに設定され、ノードfuji2RMS上でOnline状態にあります。
・ 要求はありません。
・ lfsオブジェクトにはAutoRecover属性が設定されていません。
・ システム管理者の誤操作により、lfsファイルシステムがアンマウントされました。
Fault処理は次のとおりです。

1. lfsオブジェクトのgResourceディテクタは、そのオブジェクトがOffline状態であることを検出します。対応するuserApplicationがOnline
であり、かつOffline要求が存在しないため、RMSはこのOffline通知を障害 (Fault) であると判断し親cmdに通知します。

ポイント
メッセージ: 予期しないOffline状態は障害 (Fault) になります。

2. この例のcmdオブジェクトには、FaultScriptは存在しません。cmdオブジェクトは直ちにFaulted状態になり、その障害 (Fault) を親に

通知します。

3. andOp1にもFaultScriptがないため、直ちにFaulted状態に移行し、その障害 (Fault) を親appオブジェクトに通知します。

4. appオブジェクトは、Faulted状態になり、AutoSwitchOver属性がNo以外に設定されているため、切替えに備えてOffline処理を開始
します。

5. この例では、ローカルファイルシステムlfsマウントポイント/mntを使用し、OfflineScriptlfsは、単純命令umount /mntで構成されてい
るものとします。/mntは、すでにマウントされた状態にないため、OfflineScriptは終了コード0以外で終了します。

6. したがって、RMSのOffline処理は障害発生後に失敗します。ローカルの状態が依然明確でないため、切替えはできません。RMSは、
システム管理者の介入を待ちます。

lfs に、より複雑なOfflineScriptを使用すればオブジェクトがマウントされているかを確認して、終了コード0で終了することも可能です。この
場合、RMSは障害発生後fuji3RMSに切替えを行ってから、Offline処理を正しく終了することができます。fuji2RMS 上の全ノードはそ
れから、Online処理が成功した後にOffline状態になり、appだけが、Faulted状態のまま残ります。

例5
シナリオは、AutoRecover属性がlfsオブジェクトに設定されていることを除いて、と同じです。
Fault処理は次のとおりです。

1. lfsオブジェクトのgResourceディテクタは、そのオブジェクトがOffline状態であることを検出します。対応するuserApplicationがOnline
であり、かつOffline要求が存在しないため、RMSはこのOffline通知を障害 (Fault) であると判断し、通知を行います (上記を参照)。

2. AutoRecover属性が設定されているため、RMSが親cmdオブジェクトに直ちに障害 (Fault) を通知することはありません。RMSは、lfs

オブジェクトのOnlineScriptを実行し、アンマウント処理が行われる前の状態に戻します。

3. 数秒後にlfsオブジェクトのgResourceディテクタから、オブジェクトがOnlineの状態に戻ったことが通知されます。RMSは、オブジェ
クトをOnline状態に戻し、それ以上のFault処理は行いません。

- 27 -
例6
この例では、appがOnline要求を受信しますが、lfsで表されたファイルシステムは破損しています。
Fault処理は次のとおりです。

1. 要求によりOnline処理が開始します。
2. lfsオブジェクトはOnlineScriptを開始し、0以外の終了コードで処理が終了します。
3. 次に、lfsオブジェクトはFault処理を開始します。FaultScriptが用意されていればそれを実行したうえで、Faulted状態に移行し、RMS
に障害 (Fault) を通知します。

4. この他の処理は、上記で説明した方法と同様に行われます。

ポイント
AutoRecover属性が設定されていても、この場合のFault処理は同じです。この属性はアプリケーションが、安定したOnline状態にある
場合、すなわちアプリケーションがOnline状態で、かつ保留中の要求がない場合にのみ意味を持ちます。

2.1.5.6 Faultクリア
Fault処理が成功すると、userApplication配下の全グラフノードはOffline状態となり、userApplicationオブジェクトのみがFaulted状態とな
ります。障害によりOffline処理が失敗した場合や、アプリケーションのPreserveState属性が設定されている場合、グラフの少なくとも一部は
Offline以外の状態すなわちOnline、Standby、Faultedのいずれかになります。
このような状態では、userApplicationのノードへの切替え要求はすべて抑止されます。これは、RMS BM (ベースモニタ) からはWait状態で
制御不能であるグラフノードが存在するためです。システム管理者は、障害 (Fault) の原因を取り除いた後、RMSを通常の動作に戻すため
以下のいずれかの手順でベースモニタに通知します。

1. 次のコマンドを使用してuserApplicationオブジェクトとグラフノードのFaulted状態をクリアすることができます。

hvutil -c userApplication

このコマンドは親アプリケーションとそのグラフを矛盾のない状態に変更することによってFaultのクリアを行います。アプリケーショ
ンオブジェクトがOnline状態である場合は、Online処理が開始され、アプリケーションオブジェクトがOffline状態の場合は、Offline
処理が開始されます(ユーザにはどちらの処理が開始されるかが通知され、その時点で処理の中止を選択することができます)。ア
プリケーションにつながるすべてのブランチが、Online状態またはOffline状態に揃った時点でFaultのクリアは完了します。最終状態
がOfflineであれば、システム管理者は切替え要求を行い、userApplicationをOnline状態へ遷移させることができます。
userApplicationオブジェクトがOnline状態であった場合、「hvutil -c」を起動しても、ツリー内の一部のオブジェクトが処理されない場合
があります。ツリー全体をOffline状態にするには、以下で説明するように「hvutil -f」を使用します。

2. 次のコマンドは、Offline要求をuserApplicationオブジェクトに送信します。

hvutil -f userApplication

このコマンドを実行すると、アプリケーションのOffline処理が開始されます。コマンドの実行が完了すると、アプリケーションとグラ
フのすべてのオブジェクトがOffline状態に変更され、Faultはクリアされます。その後必要に応じて、システム管理者は切替え要求を
行い、userApplicationをOnline状態へ遷移させることができます。

2.1.5.7 SysNode異常
RMSは、SysNodeで発生した異常 (Fault) を、他のグラフノードで発生した異常 (Fault) とは別の方法で扱います。SysNode異常は以下の
場合に発生します。

・ SysNodeディテクタがRMS BM (ベースモニタ) と通信できなくなった場合。

・ CF LEFTCLUSTERイベントが発生した場合。
上記のいずれかの状態が発生した場合、RMSは、自動切替えを行う前に、まず通信不可となったクラスタノードが停止されていることを確認
します。この確認のために、RMSはシャットダウン機構 (SF) に対して該当クラスタノードの強制停止を依頼します。SFの詳細について
は、"PRIMECLUSTER Cluster Foundation導入運用手引書"を参照してください。

- 28 -
 SFにより、クラスタノードが停止されていることを確認されると、停止されていることが確認できたクラスタノード上でOnline状態であり、
AutoSwitchOver属性にHostFailureを含むすべてのuserApplicationオブジェクトが、正常に動作している切替え先ノードに対して優先切替
えを行います。

例7
この例での処理の流れは次のとおりです。

・ RMSは、それぞれが、SysNodeオブジェクトのfuji2RMSとfuji3RMSで表される2つのノード、fuji2とfuji3とで構成されるクラスタ上で実
行されています。

・ appは、fuji2RMS上でOnline状態にあり、AutoSwitchOver属性にはHostFailureが設定されています。
・ fuji2上でシステム障害が発生し、panicメッセージが表示されます。
RMSの反応は次のとおりです。

1. CFは、ノード障害が発生したと判断し、LEFTCLUSTERイベントを作成します。
2. ノードディテクタは、ノードがFaulted状態にあると通知し、SysNodeをWait状態に移行させます。RMSはLEFTCLUSTERイベントを
受信するとSFに停止要求を送信します。

3. SFがノードの停止に成功するとDOWNイベントが送信されます。
4. RMSは、DOWNイベントを受信しSysNodeをFaultedとマークします。
5. fuji2RMSオブジェクトはFaultScript (構成されているものとします) を実行します。
6. fuji2RMSオブジェクトは、userApplicationオブジェクトにfuji2RMSが失敗したことを通知します。appは、fuji2RMSに障害が発生した
時点でfuji2RMS上でOnlineであり、AutoSwitchOver属性にHostFailureが設定されているため、fuji3RMS上のオブジェクトappは
Online処理を開始します。

オペレータ介入
SFがノードの停止作業を行っている間に、SysNodeオブジェクトのWait状態の継続期間が、オブジェクトのScriptTimeoutを超過した場合、
RMSはその旨のERRORメッセージをswitchlogに記録します。
この時点で未定義の状態のクラスタノードが1つ生じたことになるため、RMSは他のすべてのノードでそれ以上の処理を停止します。この
状態を解決するには "PRIMECLUSTER Cluster Foundation導入運用手引書"で説明したように、通常、オペレータの介入が必要にな
ります。処理が完了すると、CF がDOWNイベントを送信し、RMSは処理の停止を解除し、通常の運用が再開されます。
ScriptTimeout属性の詳細については、"付録D 属性 " を参照してください。

2.1.6 切替え処理
切替え処理は、クラスタシステムを構成する他のノードへuserApplicationを切替えます。

2.1.6.1 切替え要求
切替え要求は、以下の種類に分類されます。

・ 優先切替え要求
RMSは、構成プロセス中に記載されたクラスタノードの優先順位リストに従って、切替え先ノードを特定します。

・ 指定切替え要求
ユーザが切替え先ノードを指定します。

切替え処理により実際に行われる「切替え」は、以下の種類に分類できます。

・ 切替え (Switchover)
あるクラスタノード上で実行されているuserApplicationを他のクラスタノードへ切替える場合です。

・ Online切替え (Switch-online)
userApplicationがどのクラスタノードでも実行されていない時、または、以前動作していたクラスタノードで異常が発生した時に
userApplicationを起動する場合です。

- 29 -
 ポイント
切替え処理中、RMSはクラスタシステムを構成する全ノードに対して切替え処理を行っていることを通知します。この処理により切替え要求
の競合を防いでいます。

例8
この例での処理の流れは次のとおりです。

・ appはfuji2RMS上でOnlineになっている。
・ システム管理者は、appをfuji3RMSに切替えるため、指定切替え要求をfuji3RMSで送信する。
切替え処理は次のとおりです。

1. fuji2RMSがuserApplicationオブジェクト上のOnlineノードであるため、RMSは切替え要求をfuji2RMSに転送します。
2. fuji2RMS上のappは、クラスタ内の対応するノード (この場合はfuji3RMS上のapp) に切替え処理が起動中であるとの通知を送ります。
これにより処理の競合が防止されます。

3. fuji2RMS上のappは、fuji3RMS上のappに対して、fuji3RMS上のローカルグラフで何らかの障害が検出されているかを確認するよう
要求します。この例では、fuji3RMS上のグラフでは検出された障害はありません。

4. fuji2RMS上のappはOffline処理を開始します。
5. RMSはfuji2RMS上でappの構成解除を完了すると、fuji2RMS上のappがクラスタ内の対応する全ノードに対して、アプリケーショ
ンがこれからfuji3RMS上で実行される旨の通知を行います。切替え要求の競合抑止も同時に停止されます。

6. fuji2RMS上のappは、明示的なOnline要求をfuji3RMS上のappに送信して動作を停止します。
7. fuji3RMS上のappは、Online処理を開始します。

2.1.7 特殊な状態

2.1.7.1 保守モードの制限
保守モードのアプリケーションが存在すると、同一グラフ内の他のオブジェクトは処理上の制限を受けます。この制限により、本章で前述し
たすべての処理が停止され、以下のオブジェクトに影響が生じます。

・ 保守モードにあるアプリケーションのすべての子オブジェクト
・ 保守モードのアプリケーションが存在するノードとその上位ノード
処理要求の種類によっては、制限があるためにエラーまたはタイムアウトのいずれかが発生する場合があります。
制限がどのように適用されるかを理解するため、2つのアプリケーション (app1およびapp2) が、それぞれ1つずつ依存資源 (Res1および
Res2) を持ち、2つのノード (NodeAおよびNodeB) のいずれでも実行されるような構成を使って説明します。以下の図は、app1が保守モー
ドになった場合の、オブジェクトの状態を示しています。

- 30 -
 図2.4 保守モード時の制限の例

この例は以下の機能について説明しています。

・ アプリケーションの保守モードは、アプリケーションがOnline化される可能性があるすべてのノード、すなわちPriorityList属性に記載さ
れたすべてのノードに適用されます。このため、app1は実行の可能性があるノードにおいては、そのノードでの以前の状態に関係なく、
すべてMaintenance状態にあります。
app1には各ノードにおける目標状態が設定されています。 これは、保守モード開始直前の状態です。目標状態は、GUIまたはCLIの
hvdispで、アプリケーションのStateDetailsパラメタによって確認できます。

・ Res1はapp1の子であるため、いかなる場所においても制限を受けます。
・ app1が、NodeAとNodeBのいずれのグラフにも現れるため、両者にも制限があります(いずれのノードでもRMSの停止処理を開始すると、
RMSがapp1の保守モードを停止するのを待ってから、停止処理を実行することを求められます)。

・ app1は、app2のグラフには表示されません。したがって、app2のOffline化やOnline化、別ノードへの切替えなど、app2とその資源に関
する通常の処理は許可されます。

・ クラスタアプリケーションが保守モードに入った状態で、RMSやシステムを停止しないでください。停止する場合は、必ずすべての
クラスタアプリケーションの保守モードを終了してから行ってください。
すべてのクラスタアプリケーションの保守モードを終了せずに、forceオプションを使用してRMS を停止すると、オフライン処理が実行
されない状態でOSが停止します。このため、RMS再起動時、GDS論理ボリュームのように、リソースの状態に影響がでる場合があります。

上記の内容は「hvutil -m on」または、各アプリケーションを右クリックしてから、GUIを使ってアプリケーションの保守モードを開始した場合の
制限です。これとは別に、「hvutil -M on」が使用された場合や、ノードを右クリックしてGUIを使って処理を開始した場合は、保守モード
がクラスタ全体に適用され、すべてのノードで処理が停止します。

2.1.7.2 Inconsistent状態
あるuserApplicationとそのグラフ内の1つ以上のリソースがOffline状態またはFaulted状態にあり、同時にグラフ内の他のリソースがOnline
状態またはFaulted状態にあるという状況が発生する場合があります。これは、管理者の手動操作による介入があった場合や、Faultクリア
処理の失敗により、オブジェクトのいくつかがOnline状態またはFaulted状態で残った場合に起こります。
そしてこの場合、これらのOnline状態またはFaulted状態のリソースオブジェクトにClusterExclusive属性が設定されていると、複数のノードで
同時にOnline状態になることはできません。userApplicationが単にOfflineまたはFaultedとマークされている場合であれば、その
userApplicationはリソースとともに他のノードに切替えられてOnline状態になることができます。しかしこれはClusterExclusive属性の意図
する動作とは矛盾し、その結果生じるリソースの競合によりデータの破損が生じる可能性があります。このような問題を回避するため、RMSは、
userApplicationにOfflineやFaultedではなく、Inconsistentとマークを付けることによってuserApplicationの切替えをすべて禁止しています。
正確な定義は以下のとおりです。

- 31 -
 ・ 実際にはOffline状態、Standby状態またはFaulted状態にあるuserApplicationにInconsistent状態のマークが付けられ、かつ、そのグ
ラフ内で1つ以上のオブジェクトがOnline状態またはFaulted状態にあり、そのオブジェクトのClusterExclusive属性が1に設定されている。

userApplicationは、Inconsistentの状態にあると表示または報告されますが、実際の状態は、Offline、StandbyまたはFaultedです。ほとん
どの処理においては、Inconsistent状態にあるuserApplicationの動作は、実際の状態に基づいて決定されます。たとえば、実際の状態が
Offlineの場合には、Offline要求が発行されてもOfflineスクリプトは起動されません ("2.1.4.5 グラフノードがすでにOffline状態である場
合"を参照してください)。
例外は不整合のuserApplicationをリモートノードに切替える要求が発行された場合で、この要求は拒否されます。これによって、
ClusterExclusiveリソースが、一度に1つのノードでのみOnlineになることが確保され、障害が発生する可能性が回避されます。
あるuserApplicationが、1つのノードでのみInconsistent状態にある場合は、そのノード上でOnline状態にすることは可能です。ただし、複数
のノードでInconsistent状態が生じていると切替えはできません。この場合、たとえば、hvutil -fまたはhvutil -cによって、すべてのリソースを
Offline状態にするなどして、まずInconsistent状態を解決する必要があります。
userApplicationが複数のノードでInconsistent状態にある場合、ClusterExclusiveリソースのいずれかが、複数のノードでOnline状態にある
可能性があります。この場合には、userApplicationに対してhvutilコマンドを実行する前に、各ノードでリソースを正常終了させるための適切
な処理を行ってください。リソースのタイプによっては、データの破損が生じていないかを確認する必要があります。

2.2 RMSハートビート
RMSはUDPハートビート信号を定期的に送信しています。最後のハートビート送信時からの応答時間が、設定された接続タイムアウト値を
超えた場合に、RMSはノードとの接続が失われたと判断します ("HV_CONNECT_TIMEOUT" を参照)。RMSはここでノードのリカバリ期間
に入ります。ノードのハートビートがリカバリ期間中に検出されれば、RMSはノードの機能が回復し、正常な状態に戻ったと判断します。し
かし、リカバリ期間終了時までにノードからのハートビートを受信しなかった場合は、そのノードとの間で他の通信が可能な場合でも、RMS
はノードがDOWN状態にあると判断します。
RMSはノードがDOWN状態にあると判断すると、アプリケーションとクラスタの整合性を保証するための処理を開始します。処理の最初に、
ノードが本当に停止しているかを確認する必要があります。停止していなかった場合には、後にノードとノードのアプリケーションが予期せず
回復し、競合やデータ破損が生じる恐れがあります。このような問題を避けるため、RMSはシャットダウン機構 (後述) を使用してノードの強
制停止を行います。これは通常、ノードの再起動や電源切断によって行われますが、正確にはどのシャットダウンエージェントがそのノードに
割り当てられているかによって決まります。ノードが強制停止されてはじめて、RMSはそのノードのアプリケーションをクラスタ内の別のノー
ドで安全に再起動できるようになります。障害が発生しているノードから正常なノードにアプリケーションを自動的に切替える処理を、ア
プリケーションのフェイルオーバと呼びます。
アプリケーションの切替えはクラスタの性能に影響を与えるため、ノード停止の検出を誤らないようにリカバリ期間の設定を適切に行うことが
重要です。最適なUDPリカバリ期間はクラスタの状態によって異なります。ノードやベースモニタの故障対応に重点を置くなら、リカバリ期間
が短いほうが適しています。しかし、過負荷が生じたノードからの応答は遅くなることを考えると、リカバリ期間を長くしておいたほうが不必要
なシャットダウンは避けられます。UDPを単独で使用すると、これらの相反する要求によって、大規模なクラスタや負荷の大きいクラスタでは、
リカバリ期間の調整が困難になります。
UDPでは障害発生の原因となりうる場合が3つあるため、信頼性に欠けるので注意が必要です。1つめは、応答を要求する送信がリモー
トノードに到達しない場合です。この場合当然応答は返されません。2つめはリモートノードの負荷が大きい場合です。この場合はリカバリ
時間内に応答できない可能性があります。応答時間が低い値に設定されている場合には、この危険はさらに大きくなります。3つめは応答
パケットがリモートノードからネットワークに送り出されても、何らかの理由でローカルノードに到達しない場合です。上記いずれの場合でも、
ローカルノードはリカバリ期間経過するまで処理ができなくなります。
クラスタの応答性を高めるために、RMSではマシンの状態と接続状況を確認する手段として、ELM (Enhanced Lock Manager) を使用します。
ELMはポーリングを行いません。ELMは、CFがカーネルレベルで管理するロックを基に判定を行います。ノードは、クラスタに参入する
とロックを作成し、ベースモニタの作動中はそのまま保持します。このロックは、ノードまたはベースモニタが停止した時点で解放されます。
ロックの状態はCFによってバックグラウンドで保持されるため、各ノードのRMSはローカルにロックの状態を参照できます。
ELMはノードまたはベースモニタの障害検出を優先するよう設計されています。このため、リカバリ時間を比較的大きな値に設定して、UDP
ハートビートをノードの応答速度低下の検出に最適化させることができます。UDPハートビートはELMを補完します。CPUまたはネットワー
クインタフェースに過負荷のかかったノードは応答が遅くなりますが、CFはノードのロックの状態を保持し続けます。この状態が続くと、最終的
にはUDPハートビートのリカバリ期間が経過し、RMSがノードの停止処理を開始します。ELMにより、RMSがノードの停止処理を開始する
確率は非常に低くなります。
ELMの手動停止は、システムに詳しい専門家により、ローリングアップデートまたはデバッグの場合にのみ行ってください
("HV_USE_ELM" を参照)。この場合はさらに、RMSが起動してから、hvcm -h <timeout>を使用してUDPハートビートリカバリのタイムアウト
時間をより小さな値に手動設定する必要があります。これは、ELMが停止している場合に、リモートのベースモニタとノードの停止を効率的に
検出するために必要です。

- 32 -
2.2.1 動作の詳細
ELMのメカニズムはいくつかの簡単な例を用いると理解が容易です。以下に、2つ以上のノードで構成されるクラスタ (ノードA、ノードB、
ノードC等) を例に説明します。

2.2.1.1 ELMロックの管理
各ノードのロック名はRMS<nnnnnn>の形式で命名されています。<nnnnnn>は6桁のCFノードIDです。このため、各ノード名とノードIDお
よびロック名との対応が簡単に分かります。ロックはCFによってクラスタごとに管理され、どのノードからどのロックに対してもアクセスを要求
することができます。
あるノードがロックに対してはじめてのアクセス要求を行った場合、要求は直ちに許可されます。これは、ノードが最初はNULL状態で要求を
受信するためです。これは特別な中立の状態であり、他のいかなるノードにおけるそのロックの状態とも競合しません。ローカルノードは
ここでELMに対し、ロックを別の状態に変更するよう要求できます。いったん要求が許可されると、ノードはその状態を維持することも、別の
状態に変更することもできます。ただし、可能な処理はこの2つのみです。
ELMがサポートする状態はNULL状態以外には以下の2つだけです。

・ concurrent read (CR)

複数のノードがロックをこの状態で保持できます。これは他のノードがロックをexclusive状態に変更することを防止します。

・ exclusive (EX)
クラスタ内で1つのノードのみがロックをこの状態で保持できます。これは他のノードがロックをconcurrent状態またはexclusive状態に
変更することを防止します。

変更の処理はELMの中心的な制御メカニズムです。他ノードとの競合が発生する変更を要求してもエラー状態は発生しません。その要求
はELMが要求を許可できるようになるまで、キューに入れられます。要求しているプロセスはWait状態に置かれ、再活性化されることにより、
その時点で、要求が許可されたことが分かります。
ノードがロックをNULL状態に戻すと、そのロックは解放されます。これにより、他のノードがロックを目的の状態に変更できるようになります。
要求はキューに入れられた順序で許可されます。
たとえば、AがロックをEX状態に変更したとします。BはAのロックにアクセスを要求することが可能です。Bは直ちにNULL状態のロックを
受信します。BがここでそのロックをCR状態に変更するように要求を発行すると、その要求はA (もしくはELM自身) がロックをNULLまたは
CR状態に変更するまで待ち状態になります。これは、どちらもBの要求と競合しないためです。このようにしてBがAのロックの変更を完了
すると、その時点で、BにはAがロックをEX状態に保っていないことが分かります。
他のノードのロックへのアクセス要求が直ちに許可され、ELMのロックメカニズムに影響を与えないため、このステップは以下の説明では
省略します。

2.2.1.2 最初のノードの起動
RMSを起動する最初のノードをAとします。以下の処理が行われます。

1. Aは自らのロックをEXモードに変更します。他のノードはこの時点ですでに起動処理を完了しているため、これは直ちに実行されます。
2. AはUDPハートビートを起動し、他ノードからの応答を待ちます。この時点ではまだ他ノードのロックの変更要求を出しません。

2.2.1.3 2番目のノードの起動
RMSを起動する2番目のノードをBとします。以下の処理が行われます。

1. Bは自らのロックをEXモードに変更します。Aはこの時点ではまだBのロックに対するアクセス要求をしていないため、モードの変更は
直ちに実行されます。

2. BはUDPハートビートを起動し、他ノードからの応答を待ちます。この時点ではまだ他ノードのロックの変更要求を出しません。
3. Aは最初のハートビートをBから受信します。AはBのロックをCR状態に変更するように要求を発行します。BはロックをEX状態に維持
しているため、Aの要求はELMキューに入って休眠します。

4. Aの要求が休眠状態にあるため、Bは自らのロックを保持しなければなりません。このため、BはOnline状態であることが必要で、AはB
にその状態のマークを付けます。Aは自らの要求が休眠状態を続ける限り、BのOnline状態のマークを維持します。

5. BはAからのハートビートを検出し、同じ処理を実行します。BはAのロックをCRモードに変更しようとします。しかしAはロックをEX状態
に維持しているため、Bの要求はELMキューに入って休眠します。

- 33 -
 6. Bの要求が休眠状態を続ける限り、BはAのOnline状態のマークを維持します。
この時点で、2つのノードとも自身のロックをEX状態に保ち、それぞれ相手方のロックをCR状態に変更するように要求を発行しています。
両者の要求とも休眠状態にありますが、このことは、両ノードが実行している処理以外に対しては何の影響も与えません。しかし、各ノードで
要求の処理が完了していないといういうことは、他方のベースモニタがOnlineであるということを示しています。

2.2.1.4 3番目以降のノード
RMSを起動する3番目のノードをCとします。AおよびBとの間で行われる処理は、上記2番目のノードの起動時と同様です。

1. Cは自らのロックをEX状態に変更し、ハートビートを開始し、他のノードからのハートビートを待ちます。
2. Cは、他ノードの1つから最初のハートビートを受け取った時点で、そのノードのロックをCR状態に変更しようとしますが、要求は休
眠状態に入ります。

3. 要求が休眠状態を続ける限り、Cは、他ノードのOnline状態のマークを維持します。
Cはあるノードから最初のハートビートを受け取ると、必ずステップ2と3を実行します。
同時に、Online状態にある他のノードはCの最初のハートビートを受信し、Cのロックについてステップ2と3を実行します。
クラスタ全体がOnline状態になった時点で、各ノードのロックは次の状態になっています。

・ ノードは自らのロックをEX状態に保っている。
・ ノードは、他のノードのロックをCR状態に変更する要求を発行済みであり、これらの要求はすべて休眠状態にある。

2.2.1.5 ノードまたはRMS停止の順序
CFがリモートノードのLEFTCLUSTERイベントを発行した場合、または、リモートノードのベースモニタが停止した場合、ELMは、そのノー
ドのロックをクラスタ内のすべてのノードでNULL状態に変更します。
たとえば、ノードBが停止したと仮定します。ノードA上では以下の処理が行われます。これは他のオンラインノードでも同様です。

1. BのロックをCR状態に変更するというAの要求が待機状態を脱します。その結果、AはそのロックをCR状態で維持します。
2. AはロックをNULL状態に変更し、BのマークをOffline状態にします。
3. AはBからハートビートを受信するまで、BのマークをOffline状態で維持します。ハートビートを受信した時点で、AはBのロックをCR
状態に変更する要求を発行してロックサイクルを再始動します。

ノードBのベースモニタが最初に停止した場合も、同様の処理が行われます。大きな違いは、ノードが停止した場合は、LEFTCLUSTER
イベントがELMロックのリリースに先行し、ベースモニタが停止した場合は、ELMロックのリリースがLEFTCLUSTERイベントに先行する点
です。いずれの場合にも、RMSはノードの強制停止を開始します。
クラスタ内で何らかの故障が発生した場合に、ELMは他のベースモニタに対して能動的に警告を発します。ハートビートのタイムアウト時間
が経過するのを待つ必要はありません。
ただし、通常終了の場合でも、ELMはほぼ同じような動作をしますが、その場合はノード自身がロックを解放します。また、RMSのレベ
ルでは、ノードの強制停止は必要ありません。

2.2.1.6 レスポンスの遅延
リモートノードがビジー状態にある場合、そのベースモニタの反応は非常に遅くなります。ELMは状態ベースの監視方法であり、この状態を
検出できません。このため、リモートノードの反応遅延が許容範囲を超えた場合は、RMSは時間ベースのUDPハートビートを使用します。
たとえば、ノードBは停止してはいませんが、ベースモニタの反応が非常に遅いとします。クラスタ内のあるノード (この例ではノードA) で次の
処理が行われます。

1. BのロックをCR状態に変更するよう求めるAの要求は、sleep状態を続けます。これはBが引き続き動作中のためです。
2. Bのハートビート期間 (デフォルトは30秒) が経過し、さらに、ハートビートリカバリ期間 (デフォルトは600秒) が経過します。
3. ハートビートが失われたため、AはSFにBを強制停止するよう指示します (ただし、ELMは依然として問題を検出していません)。
4. Bの強制停止が完了すると、ELMはすべてのノードでロックを解放します。
5. Aが発行したBのロックの変更要求は許可されます。Aは直ちにロックを解放し、BのマークをOffline状態にします。

- 34 -
 6. AはBのハートビートを待機し、ロックサイクルが再開します。
他のノードは、自らのロック要求が休眠状態を脱する前に、Bのハートビート喪失を検出する可能性があります。この場合にも、Bの強制停止
を開始します。
これが、ELMがUDPハートビートをバックアップとして必要とする理由です。UDPが稼動していない場合、ELMロック要求は、リモートノー
ドのサービス停止後もかなりの時間キューに残ることになります。

2.2.2 hvenvのデフォルトの初期化
hvenvのHV_USE_ELM環境変数はCFの状態に応じて自動的に初期化され、ELMを有効化または無効化します。

・ CFがインストールされていない場合は、HV_USE_ELMは0に設定され、デフォルトのUDPハートビートリカバリタイムアウトは45秒です。
・ CFがインストールされている場合は、HV_USE_ELMは1に設定され、デフォルトのUDPハートビートリカバリタイムアウトは600秒です。
デフォルトのリカバリタイムアウトはhvcm -hで変更できます。

ポイント
ハートビートリカバリタイムアウトが短すぎると、ELMが稼動中であってもノードが処理の途中で停止される場合があります。

2.2.3 hvenv.localでのELMの手動制御
ELMは手動で停止することができますが、これは上級ユーザまたはコンサルタントのみが行ってください。ELMは次のような場合に停止し
ます。

・ ローリングアップグレード
・ テストまたはデバッグ
ELMを停止するには、HV_USE_ELM変数を変更し、タイムアウトを適切な値に変更して起動します。

1. hvenv.localでHV_USE_ELM=0に設定します。
"HV_USE_ELM"を参照してください。

2. hvcm -h <timeout> ...でRMSを起動します。

ELM停止中の推奨タイムアウト時間は45秒です。hvcmのマニュアルページを参照してください。RMSの起動時にハートビートタ
イムアウトをCluster Admin GUIから指定する方法はありません。

ポイント
hvenv.localでHV_USE_ELM=1に設定することもできます。ただし、CFがインストールされていない場合は、この設定が有効になるとRMS
は起動できなくなります。RMSはswitchlog内のメッセージでこのことを通知します。

2.3 スケーラブルコントローラ
スケーラブルコントローラとスケーラブルアプリケーションの操作の詳細について説明します。

2.3.1 コントローラの概要
コントローラを使用することにより、アプリケーションで別のアプリケーションの監視および制御ができます。コントローラサブアプリケーションを
含むアプリケーションは「制御するアプリケーション」または「親アプリケーション」と呼ばれます。コントローラに定義されたアプリケーションは、
「制御されるアプリケーション」または「子アプリケーション」と呼ばれます。子アプリケーションは、親アプリケーションに定義されたリソー
スのように動作します。「制御するアプリケーション」をマスタアプリケーション、「制御されるアプリケーション」をスレーブアプリケーション
というように考えることもできます。

- 35 -
2.3.2 スケーラブルコントローラとアプリケーション
スケーラブルコントローラでは、複数のアプリケーションを集中的に管理、制御し、情報の表示ができます。スケーラブルコントローラで「制御
されるアプリケーション」は、スケーラブルアプリケーションと呼ばれます。
たとえば、スケーラブルコントローラを含む「制御するアプリケーション」をOnlineに切替えると、スケーラブルアプリケーションはコントローラの
ApplicationSequence属性に定義された順序でOnlineに切り替わります。制御するアプリケーションをOfflineに切替えると、スケーラブル
アプリケーションは逆の順序でOfflineに切り替わります。同時に、スケーラブルコントローラの状態はスケーラブルアプリケーションの組み合
わされた状態を反映し、この状態はGUIまたはhvdispコマンドによって表示することができます。
スケーラブルコントローラとスケーラブルアプリケーションは、複数の構成リソースを複合的に制御および管理する必要のある場合に便利
です。このような構成はこれまで、複数のフォロータイプのコントローラを使って実装されてきました。しかし、スケーラブルコントローラを使用
すると、非常に複雑で可用性の高い構成を構築し、1つの固まりとして扱うことが可能です。

2.3.2.1 スケーラブルアプリケーション
スケーラブルアプリケーションとは、スケーラブルコントローラで制御される任意のアプリケーションを意味します。さまざまなスケーラブル
アプリケーションが、同一ノードまたは異なるノード上で同時にOnlineの状態になる可能性があります。たとえば、Oracle RAC、Fujitsu
Symfoware(Native) およびIBM DB2 PE (Parallel Edition) などの並列データベースはすべて、個別のインスタンスをクラスタ内の異なる
ノードで同時に実行する可能性のあるデータベースサーバです。データベースインスタンスのそれぞれに個別のアプリケーションが構成
されます。最上位のアプリケーションが、すべてのアプリケーション (またはデータベースインスタンス) の監視および制御を行います。最上位
のアプリケーションは「制御するアプリケーション」と呼ばれます。「データベースインスタンス」のアプリケーションは、「制御されるアプリ
ケーション」と呼ばれます。このようなコンポーネントを、スケーラブルコントローラで「制御されるスケーラブルアプリケーション」として構成す
ることにより、このコントローラからクラスタ内のサーバ全体にアクセスすることが可能になります。たしかにこれは商用データ処理では最もよく
目にするスケーラブルアプリケーションです。ただし、同様の要件を持ついかなるアプリケーションでも同じように構成できます。

2.3.2.2 スケーラブルコントローラによる利点
スケーラブルコントローラの主な利点は、親アプリケーションが動作するノードとは別のノードで子アプリケーションを実行できる (または実行
しなければならない) 構成が可能な点です。さらに、並列データベースの場合など、アプリケーションが複数存在する場合の管理が簡単
になります。
たとえば、Oracle RACを構成する場合には、各ノードにそれぞれ別のユーザアプリケーションを使用させる方法があります。各ユーザア
プリケーションはノードごとに独立して管理されます。Oracle RACは共用アクセスデータベースであるため、クラスタ内で一部のインスタ
ンスが動作していれば、データベース全体にアクセスできます。このためこの構成はOracle RACでは問題なく動作します。
しかし、IBM DB2 PEなどの非共用データベースでは、データベース全体のアクセスを可能にするにはデータベースのすべてのインス
タンスをOnlineにする必要があります。従来のフォローコントローラを使用した場合、DB2 PEをサポートする構成は、複数のアプリケーショ
ンと依存関係が必要となります。スケーラブルコントローラを使用すれば、このような構成の構築はもっと単純になります。
複数のノードに跨る複数のアプリケーションや、アプリケーション間の依存関係をサポートするため、さまざまな構成オプションが用意さ
れています。以下のセクションでは、スケーラブルコントローラについてより詳しく説明します。

2.3.2.3 スケーラブルコントローラの属性
Scalableというコントローラの属性は、スケーラブルな子アプリケーションを制御します。コントローラのScalable属性が1に設定された場合、
Resource属性で指定されたすべてのアプリケーションは、スケーラブルアプリケーションと見なされます。
ある子アプリケーションを制御できるのは、1つのスケーラブルコントローラのみです。子アプリケーションが複数の親コントローラに関連付
けられることはできません。あるアプリケーションが複数のスケーラブルコントローラを含む場合があります。アプリケーションがスケーラブ
ルコントローラを複数もつことに制限はありません。ただし、使用するアプリケーションウィザードによっては、RMS Wizard Toolsでの構成時の
選択肢が制約される場合があります。
次の図は、一般的なスケーラブルコントローラの属性を示すCluster Admin Viewです。

- 36 -
 図2.5 スケーラブルコントローラの属性

上の図に示すスケーラブルコントローラの属性の一部は、RMS Wizard Toolsインタフェースで設定できます。これらの属性は、本例では次

のように設定されています (図中の上から下)。

・ MonitorOnly=0
・ Resource=<アプリケーションのリスト>
・ ApplicationSequence=<Resource属性に定義されたアプリケーションの起動順番>
・ ScriptTimeout=180
・ FaultScript=<スクリプト定義>
・ StateChangeScript=<スクリプト定義>
スケーラブル運用に影響する他の属性は、スケーラブルコントローラの構成時にRMS Wizard Toolsによって自動設定されます。
切替え処理および状態遷移における一部の属性の影響については、以下のセクションで説明します。

2.3.3 Online/Offline処理と状態遷移

2.3.3.1 制御されるアプリケーションの状態とコントローラの状態
以下の表に、「制御されるアプリケーション」の状態に応じたスケーラブルコントローラの状態を示します。

表2.1 子アプリケーションの状態とスケーラブルコントローラの状態の関係
コントローラの状態 子アプリケーションの状態
Online 任意のノード上で最低1つがOnline
Offline すべてのノード上ですべてがOffline
Faulted 任意のノード上で最低1つがFaulted、すべてのノード上で他のすべてがOffline
Standby 任意のノード上で最低1つがStandby、すべてのノード上でOnlineがない
Warning 任意のノード上で最低1つがOnline、すべてのノード上で他はOffline

- 37 -
 注意:異なるスケーラブルアプリケーションであれば、同一ノードまたは異なるノードで同時に2つ以上をOnlineにすることはできますが、個々
のスケーラブルアプリケーションは、1つのノードでしかOnlineにすることができません。たとえば、Oracle RACのRMS構成設定を行う場合、
Oracleデーモンプロセスは、複数のノードでOnlineにする必要があるため、単一のRMSアプリケーションではなく、複数の独立した制御さ
れるRMSアプリケーション (デーモンごとに1つの子アプリケーション) として表す必要があります。これら子アプリケーションはすべて、Oracle
RACの親スケーラブルコントローラから集中的に制御、管理および表示することができます。

2.3.3.2 アプリケーションが Online 状態になるノードについて

制御するアプリケーションと制御されるアプリケーションは、それぞれ異なるノード上でOnline 状態になる場合がありますが、アプリケー
ションの監視および制御に問題はありません。

注意
ノード故障などによりノードが異常停止し、その後、起動した場合、制御するアプリケーションが 複数ノード上でOnline 状態になる場合が
ありますが、運用上問題ないため、対処は必要ありません。

2.3.3.3 制御されるアプリケーションへの要求の伝播
コントローラからの優先Online要求は、制御されるすべてのアプリケーションに伝播され、それらの各アプリケーションはPriorityList属性に
定義されたノードの順序に従ってOnline状態に遷移します。OfflineおよびStandby要求はすべてのノード上で、すべての制御されるア
プリケーションに伝播されます。
IndependentSwitch属性は、スケーラブルコントローラオブジェクトでは1に設定されなければなりません。この属性により、制御される子ア
プリケーションに影響を与えずに、親アプリケーションをノード間で切替えることができるようになります。ただし、親アプリケーションが
「hvswitch -f」などの強制要求によって切替えられる場合は、IndependentSwitch属性の設定は無視されます。この場合、コントローラに
よって切替え処理の一部としてOffline要求がそれぞれの子アプリケーションに伝播されます。
RMS の停止や OS のシャットダウンによって親アプリケーションと子アプリケーションが同時に切替わり、子アプリケーションが次に優先度の
高いノード上で Online 状態になる前に RMS の再起動が完了した場合、子アプリケーションは、その PriorityList 属性に定義されたノードの
順序に従ってOnline 状態に遷移します。このため、子アプリケーションは、切替え前のノードで再び Online 状態となります。

2.3.3.4 コントローラのWarning状態
スケーラブルコントローラは、以下のいずれかの条件を満たした場合、GUI およびhvdispコマンドでWarning状態を表示します。これは、ス
ケーラブルを構成するクラスタアプリケーションの一部が動作していないことを管理者に警告するためです。

・ Online状態のコントローラに制御されるアプリケーションの少なくとも1 つがOnline状態 からOffline、StandbyまたはFaulted状態に遷移

した場合

・ Standby状態のコントローラに制御されるアプリケーションの少なくとも1 つがStandby状態 からOfflineまたはFaulted状態に遷移した場

合

注意
Online状態のコントローラに制御されるアプリケーションのうち、一部のアプリケーションが動作する、すべてのノードの RMS が停止している
場合、異常が検知できないため、コントローラの状態は、Online状態のままとなります。

2.3.3.5 アプリケーションのWarning状態
スケーラブルコントローラのうち少なくとも1つが Warning 状態になると、スケーラブルコントローラを含むアプリケーションは Warning 状態
になります。すべてのスケーラブルコントローラが送信されたWarning以外の状態になると、アプリケーションはそれぞれの状態に戻ります。
コントローラの場合と同様、GUIおよびhvdispコマンドではWarning状態が表示され、管理者に対してスケーラブルな親アプリケーションの
完全な機能が稼動していないことを警告します。
コントローラがOfflineまたはFaultedに遷移するか、制御されるすべてのアプリケーションがOnlineまたはStandbyに遷移すると、Warning状
態はそれぞれの状態に変わります。

- 38 -
2.3.3.6 コントローラStateChangeScript
コントローラのStateChangeScript属性には、制御される子アプリケーションがOnline、Offline、Faulted、またはStandby状態に遷移するた
びにスケーラブルコントローラで実行されるスクリプトを指定します。スクリプトは、制御する親アプリケーションが動作できるすべてのノードで
実行されます。これはコントローラ自身から出された要求に代わって実行される場合でも同じです。StateChangeScriptスクリプトは、子ア
プリケーションが実行されているノードの状態がOfflineまたはFaultedに遷移した場合にも実行されます。このスクリプトは、状態遷移には
影響しません。異常終了コードがswitchlogに記録されるだけです。
同時に複数の状態遷移イベントが送信された場合、それぞれのイベントに対してStateChangeScriptスクリプトが実行されます。イベントを
受信すると、即座 (遅延なし) にStateChangeScriptスクリプトがスケジューリングされます。同じノードから複数のイベントが送信された場合は、
必ずイベントを受信した順序に従ってStateChangeScriptが呼び出されます。

スクリプト実行時環境変数
StateChangeScriptの実行時には、以下のRMS環境変数が設定されています。各変数の名前と用途を以下に示します。各変数の内容お
よびフォーマットの詳細については、"E.2 RMSグローバル環境変数"、"E.4 RMSスクリプト実行環境変数"を参照してください。
RMSでは、状態変更スクリプトの呼び出しがアプリケーションの状態変化に起因するか、ノードの状態変化に起因するかに応じて、以下の2
つのRMS環境変数が使用できます。

・ HV_APPLICATION_STATE_CHANGE_INFO
StateChangeScriptスクリプトの呼び出しが、「制御されるアプリケーション」の状態変化に起因する場合に設定されます。コロンで区切
られた各文字列は以下の意味を持ちます。

－ ノード上のアプリケーションの前の状態 (ローカルノードに記録された状態と同一)
－ ノード上のアプリケーションの現在の状態 (ローカルノードに記録された状態と同一)
－ アプリケーションの状態が変化したノードの名前
－ 状態が変化したアプリケーションの名前
StateChangeScriptスクリプトの呼び出しがノードの状態変化に起因する場合、HV_APPLICATION_STATE_CHANGE_INFOは空
になります。

・ HV_HOST_STATE_CHANGE_INFO
「制御される子アプリケーション」を実行可能なSysNodeの状態がOfflineまたはFaultedに変化したために、スケーラブルコントローラの
StateChangeScriptスクリプトが呼び出された場合に設定されます。コロンで区切られた各文字列は以下の意味を持ちます。

－ 前のノードの状態
－ 現在のノードの状態
－ ノードの名前
－ ノードの状態変化の理由: シャットダウン機構、hvshutコマンド、または不明。
StateChangeScript ス ク リ プ ト の 呼 び 出 し が 「 制 御 さ れ る 子 ア プ リ ケ ー シ ョ ン 」 の 状 態 変 化 に 起 因 す る 場 合、
HV_HOST_STATE_CHANGE_INFOは空になります。

RMSが呼び出す他のスクリプトと同様に、StateChangeScriptでも以下のRMS環境変数を参照できます。

・ HV_APPLICATION
現在のオブジェクトを含む現在のサブツリーの最上位にあるuserApplicationオブジェクトの名前です。

・ HV_AUTORECOVER
1が設定されている場合、スクリプトの呼び出しがAutoRecoverの試行に起因することを示します。

・ HV_FORCED_REQUEST
1が設定されている場合、強制要求によるスクリプト呼び出しであることを示します。

・ HV_LAST_DET_REPORT
現在のオブジェクトに対して、ディテクタが検知した最新の状態です。

- 39 -
 ・ HV_OFFLINE_REASON
実行中のOffline処理の理由: 保守停止要求、手動切替え、リソース故障後のフォローアップ処理、またはアプリケーション停止要求

・ HV_NODENAME
現在のオブジェクトの名前です。

・ HV_SCRIPT_TYPE
スクリプトの種類です。

・ NODE_SCRIPTS_TIME_OUT
現在のオブジェクトおよびスクリプトの種類のタイムアウト値です。

スクリプト実行シーケンス
StateChangeScriptスクリプトは、イベントを受信すると即座に実行されます。その結果、他のRMSスクリプト (他のオブジェクトまたは現在の
オブジェクトのStateChangeScriptスクリプトを含む) と並列に実行されることがあります。複数のイベントがほぼ同時に送信される可能性が
あるため、適切な順序で実行されるようユーザスクリプト側で調整する必要があります。スクリプトの作成者は、ロックまたはOSの他の機能を
使用して、スクリプトから共有リソースへのアクセスが適切に行われるように配慮しなければなりません。

2.3.3.7 Online/Standby/Offline処理の順序制御とアプリケーショングループ
コントローラのApplicationSequence属性は、Online、Offline、およびStandby要求がどのように子アプリケーションに伝播されるかを制御し
ます。この属性では、コントローラのResource属性で指定されるコントローラのすべての子アプリケーションのリストが示されますが、並列処理
または順次処理であるかどうかでグループに分けられます。
スペースで区切られたアプリケーションのグループを、要求グループと呼びます。要求グループのアプリケーションはすべて並列処理さ
れます。
コロン (:) で区切られた要求グループは、順次処理されます。OnlineまたはStandby要求は、左から右へ順に処理されます。Offline要求は、
右から左へ順に処理されます。
たとえば、コントローラのApplicationSequence属性が以下のように指定されているとします。

A1 A2:B:C1 C2

コントローラによって、以下のようにOnline要求が発行されます。

1. A1およびA2 (最初の要求グループ) は並列処理され、一方が他方を待つことはありません。ただし、A1およびA2の両方からOnline

状態が送信されない限り、コントローラは次のグループには進みません。

2. B (2番目の要求グループ) が次に処理されます。BからOnline状態が送信されない限り、コントローラは次のグループには進みません。
3. C1およびC2 (3番目の要求グループ) が最後に並列処理されます。
Offline要求は、これと逆の順番で処理されます。つまり、C1およびC2が最初に処理され、次にB、最後にA1およびA2が処理されます。
処理順序が重要になるのは、スケーラブルコントローラからの要求が「制御されるアプリケーション」に伝播されている間のみです。手動切替
えおよび自動切替えを含む他の理由でアプリケーションの状態が変化した場合、ApplicationSequence属性は無視されます。
Offline処理の順序は、「hvshut -l」などのローカルのhvshutでも維持されます。ただし、「hvshut -a」などのクラスタ規模の要求では、順序が
無視されます。各ノードでは、アプリケーションのOffline処理が独立して行われます。
他のサブアプリケーションと同様に、「hvshut -L」および「hvshut -A」の処理時にはスケーラブルな要求グループは処理されません。
スケーラブルコントローラからの要求の伝播は、子アプリケーションが実行される可能性のあるノードの状態からも影響を受けます。同じ要求
グループのアプリケーションのノードが使用可能でない場合、その要求は伝播されません。該当するノードが使用可能になるまで遅延さ
れるか、ScriptTimeout属性に設定された時間が経過するまで遅延されます。

2.3.3.8 サブクラスタでの自動起動
一部のノードが停止している状態をサブクラスタと呼びます (以降「サブクラスタ」と記載)。この場合でも、「制御するアプリケーション」が自
動起動できるように設定することができます。これが必要とされるのは、「制御される子アプリケーション」が親コントローラの
ApplicationSequence属性で定義される順序に従ってクラスタシステムの一部でOnlineになる場合があるためです。

- 40 -
たとえば、はじめにすべてのクラスタノードが停止している状態から一部のノードが起動し、他のノードは依然メンテナンス中であったとします。
他のクラスタノードが現在OfflineまたはFaultedであるかどうかにかかわらず、起動中のサブクラスタで実行されるべき「制御されるアプリ
ケーション」は、スケーラブルコントローラの要求に従ってOnlineに切り替わる必要があります。管理者が不在な場合もあるため、この場合
「hvswitch -f」を使用するような設定は選択できません。クラスタ構成が自身で自動的に起動する必要があります。
上記の例は、userApplicationオブジェクトのPartialCluster属性により実現できます。1に設定すると、アプリケーションは自らのプライマリ
ノードを含む他のノードがOfflineまたはFaultedであっても、現在オンラインであるノード内でOnline要求の処理ができます。0に設定すると、
(現在の動作では) アプリケーションは実行が可能なすべてのノードがOnlineである場合にしか、Online要求の処理ができません。デフォルト
値は0です。
スケーラブルコントローラを含むアプリケーション(制御するアプリケーション) において、アプリケーショングラフに ClusterExclusive 属性が
設定されたリソースがない場合PartialCluster属性 を 1 に設定できます。それ以外の場合は、PartialCluster属性 を0 に設定する必要が
あります。
「制御するアプリケーション」にcontrollerオブジェクト以外のオブジェクトが含まれない場合は、PartialCluster属性を1に設定しても問題あ
りません。「制御するアプリケーション」が異なるサブクラスタで複数自動起動されても、排他リソースは共用されません。自動起動の一部と
して、それぞれの「制御されるアプリケーション」にOnline要求が伝播され、現在のサブクラスタからノードが要求された場合は、これらの
アプリケーションがOnlineになることもあります。
しかし、一部の「制御されるアプリケーション」が複数のサブクラスタからノードを要求した場合、これらのアプリケーションはOnlineにはな
りません (これが本来の動作です)。これらのアプリケーションのPartialCluster属性は0に設定されており、サブクラスタにまたがっている「制御
されるアプリケーション」がOnline処理を拒否するようになっています。
各アプリケーショングループの「制御されるアプリケーション」がOnlineになるまで、Online要求の伝播がスケーラブルコントローラによって
遅延するため、複数のノードが同じスケーラブルコントローラに対するOnline要求を同時に開始した場合でも、ApplicationSequence属性で
指定された順序は維持されます。

2.3.3.9 サブクラスタでの切替え
「制御するアプリケーション」のPartialCluster属性が設定されている場合、サブクラスタのノード間で自動または手動 (「-f」強制オプションの
有無による) でOnlineに切替えできます。これは、「制御するアプリケーション」自身については安全です。コントローラ以外には実際の
リソースがないからです。また、「制御されるアプリケーション」についても安全です。それぞれのPartialCluster属性が0に設定されており、
サブクラスタの境界をまたがった場合はOnlineにならないからです。

2.3.3.10 子アプリケーションの手動切替え
「hvutil -f」コマンドを使用して、Online状態の最後の子アプリケーションを手動でOfflineにしようとすると、親コントローラがFaulted状態に
なります。このような状況を回避するため、RMSではOnline状態にある最後の「制御されるアプリケーション」をOfflineにする「hvutil -f」コ
マンドが拒否され、以下のメッセージが生成されます。

ERROR: Application controlled from another online application - <application>.

2.3.3.11 保守モード時の操作
以下の例では、保守モード時のコントローラの動作について説明します。

・ ノードfuji2およびfuji3上にアプリケーションapp1、app2、およびapp3が構成されているとします。
・ app2はFollowモードコントローラでapp1を制御します。
・ app3はScalableモードコントローラでapp2を制御します。
以下は、この例のRMS構成ツリーおよび対応グラフを示しています。

- 41 -
 図2.6 保守モード時のコントローラの例

ノード間でのアプリケーションの切替え
グラフの観点から、これらを「横方向」の切替え操作として考えることができます。
以下の図のように、スケーラブルコントローラに制御された子アプリケーションが保守モードに切替えられた場合、その親はhvswitchコマ
ンドを使用してノード間で手動または自動で切替えることができます。app2を保守モードに切替えると、フォローコントローラに制御された子
アプリケーションであるapp1も自動で保守モードに切り替わります。

図2.7 子が保守モードの場合にスケーラブルな親アプリケーションを切替える

同様に、以下の図のようにスケーラブルコントローラの親アプリケーションが保守モードに切替えられた場合、その子はhvswitchコマンドを
使用してノード間で切替えることができます。ただし、保守モードでは親は処理要求を発行しないため、実際は手動コマンドによってのみ
実行できます。app2を異なるノードに切替えると、フォローコントローラに制御された子アプリケーションであるapp1も自動的にそのノードに切
り替わります。

- 42 -
 図2.8 親が保守モードの場合にスケーラブルな子アプリケーションを切替える

つまり、これらの「水平」のhvswitchコマンドは正しく処理されます。

Online、Offline、およびFault処理の制約
グラフの観点から、これらを「縦方向」の切替え操作として考えることができます。
以下の図のように、app2が保守モードのときにapp3をhvutilコマンドでOfflineにすることを考えます。

図2.9 子が保守モードの場合に親をOfflineにするよう試行する

前述のhvswitchコマンドと異なり、この「hvutil -f」操作では、処理の続行に子アプリケーションからの応答を必要とします。保守モードでapp2
が親からの通常の処理要求に応答できないため、Offline要求は最終的にタイムアウトになります。「hvutil -c」でFault処理を試行する場合も
同じです。
以下の図のように、親が保守モードの場合に子をOfflineにするよう試行しても、やはり失敗しますが、前の場合のような長い遅延があり
ません。Offline処理を開始できるのは親だけであるため、RMSがすぐにエラーを生成します。

- 43 -
 図2.10 親が保守モードの場合に子をOfflineにするよう試行する

親からの応答を必要としないため、Fault処理の「hvutil -c」要求を子に対して発行できます。
つまり、これらの「縦方向」のhvutilコマンド操作は、保守モードの子または親アプリケーションからの応答がアプリケーションで必要とされる
場合に失敗します。

スケーラブルコントローラで推奨される操作
保守モードの要求は制御階層の最上位アプリケーションに対して発行することを強く推奨します。これは、予期しない動作を回避するのに
役立ちます。

・ 子アプリケーションは他のノードへ切替えるための自動要求を親から受信しません。また、自動のOnline、Offline、またはFault処理要求
が親から伝播されることはありません。

・ リソース故障の場合、下位レベルオブジェクトからの切替え要求はすぐに失敗します。RMSはタイムアウト遅延を待機せずにFault処理を
開始できます。

- 44 -
第3章 RMS Wizard Toolsインタフェース (hvw) の使用方法
本章では、RMSウィザードを使用してクラスタアプリケーションの高可用性構成を設定する方法について説明します。

注意
Solaris では、RMSの構成設定を行う手段として、Web-Based Admin Viewを利用したGUIであるuserApplication Configuration Wizard を
使用します。そのため、hvw は指示がある場合のみ使用してください。
userApplication Configuration Wizard の詳細については、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris) " の "4.4.4
userApplication Configuration Wizardの機能" を参照してください。

以下の手順ではすべて、Cluster Foundation (CF) ソフトウェアが正しくインストールされ、構成され、起動されていることを前提としています。

詳細については、"PRIMECLUSTER Cluster Foundation導入運用手引書" を参照してください。

3.1 概要
"第1章 概要"では、高可用性アプリケーションを構成設定するために必要なコンポーネントについて説明しています。高可用性アプリ
ケーションを構成設定するには、アプリケーションおよびアプリケーションによって使用される資源としてのオブジェクトを定義することが非常
に重要です。資源とは、ディスク、ファイルシステム、プロセス、IPアドレスなどの実体を指します。
RMS構成定義を作成するためには、上記の情報だけでなく以下の情報も必要です。

・ アプリケーションと資源オブジェクトの関連性
・ 資源オブジェクトをOnlineおよびOfflineにするスクリプト
・ どのディテクタがどの資源オブジェクトの状態を監視するか
たとえば、ノードが使用不能になった場合に備えて、そのノードに代わる代替ノードを定義しておき、このノードに依存するユーザ業務が中断
するのを最小限に抑え、代替ノードで継続稼動できるようにする必要があります。これらの情報が定義できれば、RMS構成は設定できます。
しかし、これだけの情報を定義してRMS構成を設定するには、多くの専門知識が必要になります。
RMSウィザードは、高い柔軟性を提供するため、シンプル設計されたRMS構成設定のツールです。RMSウィザードでRMSの構成を設定
するには、メニュー形式のインタフェースから、アプリケーションの情報を入力します。RMSウィザードは、これらの情報を使用してRMSの
構成設定を作成します。
以下のセクションでは、RMSウィザードを使用して、高可用性クラスタアプリケーションを設定する方法を説明します。

3.1.1 RMSウィザードのタイプ
RMSウィザードは大きく2つに分類されます。

・ RMS Wizard Tools

以下のコンポーネントを含む汎用パッケージです。

－ hvw
RMS構成設定用のコマンドです。

－ SCALABLE アプリケーションウィザード
スケーラブルアプリケーションの設定を行います。

－ STANDBY アプリケーションウィザード
スタンバイアプリケーションの設定を行います。

－ リソースウィザード
ファイルシステム、ボリュームマネージャ、IPアドレスなどの基本的なリソース用のスクリプト、ディテクタを提供します。これらは、RMS
Wizard Kitのコンポーネントだけでなく、SCALABLE および STANDBYウィザードでも使用されます。

- 45 -
 ・ RMS Wizard Kit
上位アプリケーション用のウィザードです。あらゆるアプリケーションに対応し、ターンキーの概念に基づいてタスクを実行します。 こ
のタイプのウィザードには、ORACLEウィザードがあります。

参照
RMS Wizard Kitの可用性の詳細については、Wizard for Oracle、Wizard for Networkerなどの各ウィザード製品のマニュアルを参照
してください。

3.1.1.1 ターンキーウィザード
ターンキーウィザードは、クラスタアプリケーションをトップダウン形式で一括で設定するためのウィザードです。 このウィザードを使用す
ることによって、クラスタアプリケーションを設定する管理者は、クラスタアプリケーションに関連付けられている基本リソースの活性化や非
活性化の優先順位を気にする必要がなくなります。
ターンキーウィザードの多くは、特定の種類のアプリケーション専用に設計されています。
ターンキーウィザードには、SCALABLE ターンキーウィザードおよび STANDBY ターンキーウィザード、ORACLE ウィザードなどがあります。
ターンキーウィザードは、すべて大文字で表記します。

3.1.1.2 リソースウィザード
リソースウィザード (サブアプリケーションウィザードと呼ぶ場合もあります) はファイルシステムやIPアドレスなど、上位アプリケーションが動作
するために必要な資源に対する設定を行います。 これらはターンキーウィザードから起動されます。以下に、主要なリソースウィザードを示
します。

・ Cmdline
StartScript (リソースをOnlineにする)、StopScript (リソースをOfflineにする) および CheckScript (リソースの状態をチェックする) を指定
して汎用リソースタイプを 構成します。

・ Controller
他のクラスタアプリケーションどうしを関連付けて使用するための設定を行います。

・ Gds
GDSに管理されたディスククラスを設定します。

・ Gls
RMS環境を使用して GLSのリソースクラスを設定します。

・ Fsystem
ローカルファイルシステムまたはリモートファイルシステムを設定します。

・ Ipaddress
クラスタシステムで使用する切替えネットワークで必要な LAN、IPアドレスを設定します。

3.2 一般的な構成設定の手順
RMS の構成設定は、次の4つの段階で行います。

1. RMSを停止する
"7.1.3 RMSの停止"を参照してください。Cluster Admin GUIまたは、クラスタ内のいずれかのノードからコマンドラインインタフェース
(CLI) を使用します。

2. RMS構成を作成および編集する
"3.3 RMS構成の作成および編集"を参照してください。

- 46 -
 3. RMS構成を配布する
RMS構成の配布を行う場合は、上記で作成編集した情報からRMS構成定義を生成し、それを各ノードに送付するという2段階で行
います。"3.4 RMS構成定義ファイルの作成と配布"を参照してください。

4. RMSを起動する
"7.1.1 RMSの起動"を参照してください。Cluster Admin GUIまたは、クラスタ内のいずれかのノードからコマンドラインインタフェース
(CLI) を使用します。

3.3 RMS構成の作成および編集
事前準備が完了したら、RMSウィザードメニューを使用してRMS構成設定を開始します。クラスタのノード上で現在稼動している既存の
RMS Wizard Toolsを呼び出して、RMSが停止しているときにウィザードを使用して変更したり、新しいRMS構成を設定することもできます。
RMSウィザードを起動するコマンドは以下のとおりです。

・ hvw
前回配布されて有効になったRMS構成を使用して、RMS Wizard Toolsを実行します。このRMS構成は、RELIANT_PATH/etc/
CONFIG.rmsに格納されています。 このファイルが存在しない場合や初めてhvwを起動する場合、RMSはデフォルトの構成定義ファ
イルconfigを作成します。

・ hvw -n configname
既存のRMS構成を編集するか、指定した名前で新しいRMS構成を作成します。 RMS構成は、RELIANT_PATH/build/
configname.us 起動ファイルに格納されます。
本章のサンプル構成では、STANDBYターンキーウィザードを使用して、myconfigというRMS構成を新規に設定する方法を示して
います。 このサンプルRMS構成は、次のようにして呼び出します。

hvw -n myconfig

hvwコマンドの詳細については"PRIMECLUSTER 活用ガイド<コマンドリファレンス編>"を参照してください。

3.3.1 RMSウィザードメニューの使用
hvw コマンドは操作するメニューを文字列で表示します。以下によく使用される メニュー操作とメニュー項目について説明します。

・ 項目の選択
通常は、項目の番号を入力してから、＜Enter＞または＜Return＞キーを押します。 メニュー内のプロンプト行は、入力が必要であ
ることを示しています。 >> プロンプトは入力する文字列を示します。

・ メッセージへの応答
メニューには、数種類のメッセージが表示されます。 たとえば、RMSウィザードが実行したアクティビティに関する情報 (整合性チェックが
成功したことなど) を知らせるメッセージがあります。 RMS構成設定手順で特定のアクティビティの実行 (アプリケーション名の選択など)
を指示するメッセージもあります。

・ [HELP]
ユーザにヘルプ情報を提供します。すべてのRMSウィザードメニューの先頭項目です。

・ [QUIT]
RMSウィザードメニューシステムを終了します。

・ [RETURN]
メニューシステム内で1つ上のレベルに移動するための項目です。つまり、現在のメニューから、その前に使用していたメニューに移動
します。

・ [SAVE+EXIT] / [NOSAVE+EXIT]
入力を保存または破棄して終了するための項目です。[SAVE+EXIT] は読取専用モードでは選択できません。また、その時点の構
成設定に不整合がある場合には選択できないことがあります。

- 47 -
 ・ [NEXT] / [PREVIOUS]
選択する項目が多く一画面に表示できない場合、一部の項目は次画面に表示されます。[NEXT] は次画面に進み、[PREVIOUS] は
前画面に戻ります。

3.3.2 メイン構成メニュー
RMS構成を呼び出した直後に、メイン構成メニューが表示されます。 最上位のメニューは、RMSクラスタの状態を、以下のいずれかで示
します。

・ RMSが停止中の場合
・ RMSが実行中であるノードのリスト
メイン構成メニューは、RMSがクラスタで実行中であるか編集中のRMS構成定義ファイルが現在のRMS構成定義ファイルであるかにより、
動的に変化します。
RMSがクラスタ内のいずれかの場所で実行中である場合は、実行中のRMS構成を変更する可能性がある操作はすべて無効になり、使用
できません。 さらに、実行中のRMS構成に対する変更ができないように、メニュー項目が変更されます。
RMSが実行中で、かつ編集中のRMS構成が実行中のRMS構成と異なる場合は、メインメニューには[Configuration-Activate] メニュー
オプションが使用できないこと以外の制限はありません。

3.3.2.1 RMS停止中のメイン構成メューウィンドウ
RMSがシステムを構成するいずれのノードでも実行されていない場合、最上位のメニュー全体が、制限なしで表示されます。以下の図は、
RMS停止中のメイン構成メニューウィンドウを示しています。

図3.1 RMS停止中のメイン構成メニューウィンドウ

メニュー項目
メイン構成メニューでは、RMSがクラスタのいずれのノードでも実行されていない場合、以下の処理を行うことができます。

・ [Application-Create]
新規クラスタアプリケーションを作成します。このメニューでは、動作に必要な関連項目もすべて指定する必要があります。 最も重要な
指定項目は、クラスタアプリケーションの名前とノードのリスト (クラスタアプリケーションを実行するクラスタノード) です。
ユーザアプリケーションは、高可用性構成のため複数のノードで実行するように設定してください。
RMSウィザードは指定したオブジェクトに応じて、属性に値を割当て、必須設定の場合はプロンプトを表示します。
アプリケーションに適したターンキーウィザードを選択すると、スクリプトやディテクタなどの、対象となるアプリケーションの定義済みの
内容が自動的に設定されます。 これらの内容は特定のアプリケーション向けに開発されたものです。
不整合が発生することを防ぐため、RMSウィザードはRMS構成設定段階で文法チェックも実行します。

・ [Application-Edit]
既存のクラスタアプリケーションを変更します。
既存のクラスタアプリケーションはこのメニュー項目で変更できます。 変更では、以下のモードが使用できます。

- 48 -
 － ターンキーモード (推奨)
デフォルトのモードです。 クラスタアプリケーションを作成するために必要な各種の設定を簡単に行うことができるので、通常は
このモードを使用してください。

－ 非ターンキーモード
通常のRMS構成の作成および編集では使用しないでください。当社技術員 (SE) からの指示があった場合のみ使用してください。

・ [Application-Remove]
既存のクラスタアプリケーションを削除します。

・ [Application-Clone]
既存のクラスタアプリケーションの設定を流用して新たなクラスタアプリケーションを作成します。 この機能は、作成する新しいアプ
リケーションと現在のアプリケーションとの差異がごくわずかである場合に使用します。 この場合、アプリケーションのクローンを作成し
てから新しいアプリケーションに必要な部分のみを変更します。

注意
本バージョンでは [Application-Clone] は使用できません。

・ [Configuration-Generate]
以下を実行します。

－ RMS構成定義ファイルの文法チェックを行います。
－ RMS構成定義は、configname.us ファイルに保存します。 そのRMS構成で使用するノード、クラスタアプリケーション、および資源
がオブジェクトとして階層的に記録されます。

[Configuration-Generate]の進捗状況は、RMSウィザードによりドット (.) の並びで画面に表示されます。

通常は、[Configuration-Activate] (以下に説明) を使用して、RMS構成定義の作成と配布を同時に行えます。[Configuration-
Generate] では、クラスタ内の他のノードにRMS構成定義を送付せずにRMS構成の生成とチェックができます。これはテストやデバッ
グに使用してください (このリストの [Configuration-ScriptExecution] の説明も参照してください)。

注意
[Configuration-Generate]は、RMSが起動しているかどうかに関係なく常に使用可能です。

・ [Configuration-Activate]
RMS構成を生成して配布します。
この項目を選択すると、RMS構成定義ファイルの生成と配布を同時に行います。生成のフェーズについては、前の項目を参照して
ください。
配布のフェーズでは、各ノードにデータを送付する必要があるため、クラスタシステムの全ノードが動作していなければなりません。RMS
ウィザードは、RMS構成で指定された実行中のすべてのノードに構成データをコピーし、必要なファイルをコピーします。

注意

－ [Configuration-Activate] は、RMSが実行されているノードが1つでも存在する場合は使用できません。
－ [Configuration-Activate] は、クラスタを構成する複数のノードで同時に実行しないでください。

・ [Configuration-Copy]
既存のRMS構成定義ファイルのコピーを作成します。動作確認済の構成定義ファイルを更新する前に、バックアップを作成しておく
場合に使用します。

- 49 -
・ [Configuration-Remove]
既存のRMS構成定義ファイルを削除します。

・ [Configuration-Freeze]
RMS構成定義ファイルを変更不能にします。対象となるRMS構成定義ファイルには、読取専用のマークが付けられ、表示のみが可能
で変更はできないようになります。

ポイント
[Configuration-Freeze] はパスワードで保護されています。RMS構成をロックするには、まずパスワードの作成を求められます。

注意
本バージョンでは [Configuration-Freeze] は使用できません。

・ [Configuration-Thaw]
RMS構成定義の状態を変更不能 (読取専用) から変更可能にします。

ポイント
[Configuration-Thaw] はパスワードで保護されています。RMS構成をアンロックするには、正しいパスワードを入力する必要があります。

注意
本バージョンでは [Configuration-Thaw] は使用できません。

・ [Configuration-Edit-Global-Settings]
構成定義全体に影響する設定項目の変更を行います。例としては、ディテクタや、hvwコマンドの運用モードなどがあります。

・ [Configuration-Consistency-Report]
高可用性構成で実行しているアプリケーションが、各ウィザードで指定されたRMS構成データで実際に作成されているかどうかを調べる
整合性チェックを行います。
RMSウィザードでは、現在起動中のRMSウィザードのチェックサムを、RMSウィザードのデータベースのチェックサムと比較します。 一方
のチェックサムをLife-Infoといい、もう一方をBuildInfoといいます。 両方のチェックサムが一致している場合は、実行中のバージョンと、
RMSウィザードが構成したバージョンが一致していることを意味します。

注意
本バージョンでは [Configuration-Consistency-Report] は使用できません。

・ [Configuration-ScriptExecution]
RMSとは別に管理者が任意のスクリプトを実行できます。
アプリケーション用に設定されたリソースを選択して、リソースをOnlineまたはOfflineにするスクリプトを実行できます。実行中のオン
ラインスクリプトを表示するには、昇順で表示されるリソースリストを調べます。 復帰値で、各スクリプトが正しく機能しているかどうかを判断
します。

注意
本バージョンでは [Configuration-ScriptExecution] は使用できません。

- 50 -
 ・ [RMS-CreateMachine]
クラスタを構成するノードのリストを定義します。配布フェーズでは、RMS構成定義ファイルがこのリストに記載されたすべてのノードに
送付されます。
RMSによって管理されるクラスタアプリケーションは、このノードリストの中の1つ以上のノード上で実行されるように構成する必要が
あります。このため、クラスタアプリケーションを作成する場合は、まずこのステップを完了させておくことが必要です。

・ [RMS-RemoveMachine]
クラスタノードの一覧からノードを削除します。

3.3.2.2 RMS実行中のメイン構成メニューウィンドウ
RMS Wizard Toolsメニューの内容は、RMSが以下の場所で起動されているかどうかにより動的に変化します。

・ クラスタ内のいずれかのノード
・ RMS Wizard Toolsを実行しているローカルのノード上
RMSがクラスタノードのいずれかで動作している場合は、現在実行中の構成に変更を加える可能性のある操作はできません。
RMSがローカルノードで実行されていると、以下のようなメイン構成メニューウィンドウが表示されます。

図3.2 RMSが実行中のメイン構成メニューウィンドウ

RMSを起動している場合は、以下のようにエントリの表示や動作が変化します。

・ [Application-View]
既存のアプリケーションを読取専用モードで表示します。

・ [Configuration-Generate]
RMS停止中と機能は変わりません。

・ [Configuration-Copy]
既存のRMS構成定義ファイルのコピーを作成します。動作確認済のRMS構成定義ファイルを更新する前に、バックアップを作成し
ておく場合に使用します。

注意
[Configuration-Copy] は現在実行中のRMS構成定義ファイルを上書きすることはできません。

・ [Configuration-Remove]
現在実行中のRMS構成定義ファイルを除き、既存のRMS構成定義ファイルをすべて削除します。

・ [RMS-ViewMachine]
RMSが現在稼動中のノードの一覧を表示します。

3.3.3 セカンダリメニュー
メインメニューの各項目を選択すると次のメニュー (セカンダリメニュー) が出ます。 セカンダリメニューのサブメニューが存在する場合も
あります。

- 51 -
セカンダリメニューの例として、[Creation: Application type selection] メニュー があります。このメニューは、メインメニューで [Application-
Create] を選択した場合に表示されます。

図3.3 [Application type selection] メニュー

3.3.4 必須設定と選択設定
クラスタアプリケーションの設定にRMSウィザードを使用すると、必須設定と選択設定に分かれて設定されます。
必須設定の項目には、アプリケーション名とそのアプリケーションが実行可能なノード名があります。 たとえば、前のセクションで示した
アプリケーションタイプ選択メニューで、[8) STANDBY] を選択すると、以下に示すメニューが表示されます。

図3.4 必須設定の前のメニュー

[6) Machines+Basics] を選択すると、以下のメニューを使用した必須設定が完了できます。

図3.5 必須設定メニュー

メニューにはアプリケーションの現在の属性設定が表示されます。これらの属性にはRMSウィザードによって自動的に設定されたものも含
まれています。括弧で囲まれた属性はオプションの属性です。

- 52 -
必須設定が完了した後で、選択設定メニューが表示されます。選択設定では、ファイルシステム、IPアドレス、ディスクなど資源の指定も行
います。

図3.6 選択設定メニュー

ポイント
メニューに表示される使用可能なサブアプリケーションの一覧は、そのローカルのシステムにパッケージがインストールされているかどう
かによって変わります。例の中にあるサブアプリケーションの一部は、マーケットやプラットフォームによっては使用できない場合があります。

3.4 RMS構成定義ファイルの作成と配布
"3.2 一般的な構成設定の手順"で説明したように、RMS構成の配布はクラスタシステムを構成するのに必要な3番目の基本ステップです。
RMS構成を起動するステップは、いくつかの手順からなっています。これらの手順で、RMS構成を生成して配布します。

ポイント
RMS構成を配布するには、まずクラスタ内のすべてのノード上のRMSを停止する必要があります。

RMS構成の配布は、メイン構成メニューから行います (以下を参照)。

図3.7 メイン構成メニュー

1. 数字「8」を入力して [Configuration-Activate] を選択します。

作成、配布はRMSウィザードによって実行されます。ここでは、他の入力は必要ありません。

- 53 -
配布の実行中に、RMSウィザードは複数の作業を実行し、作業の状態を画面に表示します。 完了した作業にはそれぞれdone等の
文字が表示されます (以下を参照)。

図3.8 RMS構成定義ファイルの作成と配布

[Configuration-Activate] では、RMS構成定義ファイルの生成および配布が行われます。RMSウィザードは、RMS構成定義ファ
イルを構成内で指定されたすべてのノードに送付する前に、RMS構成定義ファイルの生成で作成されたグラフの整合性チェックを
実行します。
クラスタ内のいずれかのノードでRMSが稼動していると、[Configuration-Activate] を実行できません。 [Configuration-Activate] を
実行する前に、RMSを停止してください。

ポイント
[Configuration-Activate] を実行すると、クラスタアプリケーションが最後にOnline状態であったノードを示す情報 (OnlinePriority属性
が1に設定されている場合に使用される情報) や、クラスタアプリケーションがFaulted状態になったことを示す情報 (PersistentFault
属性が1に設定されている場合に使用される情報) が初期化され失われます。

RMS構成定義ファイルが正しく作成および配布されたら、メイン構成メニューに戻ります。 このメニューから、構成設定を終了できます。

- 54 -
 2. ＜Enter＞を押して [Main configuration menu] に戻ります (以下を参照)。

図3.9 メイン構成メニューの終了

3. 数字「2」を入力して [QUIT] を選択します。

これでRMS構成の配布フェーズが終了します。 通常次の段階では、RMSを起動して、新しく構成したクラスタアプリケーションの監視
を開始します。

4. GUIまたは以下のコマンドを使用して、RMSを起動します。

hvcm -a

3.5 RMS構成要素
このセクションでは、高可用性構成の一部である基本要素 (スクリプト、ディテクタ、RMSオブジェクト) について説明します。これらの要素の
大半については、前のセクションで説明しました。 ここでは、RMSウィザードがどのようにこれらの要素を使用するのかをより詳しく説明します。

注意
このセクションは、操作の説明ではなく、RMS構成の要素について理解を深めていただくために用意されています。

3.5.1 スクリプト
スクリプトを使用して、数種類の処理を実行します。この中で最も重要な処理を以下に示します。

・ オブジェクトをオンライン (Online) 状態にする

・ オブジェクトをオフライン (Offline) 状態にする
オブジェクトをOfflineにするスクリプトの例として、障害が発生したノードシステムからアンマウントする必要があるファイルシステムについて考
えてみます。 オフラインスクリプトはumountコマンドを使用してファイルシステムをアンマウントします。別のスクリプトはmountコマンドを使用
して、ファイルシステムを別のノードシステムにマウントします。
このようなOnlineスクリプトおよびOfflineスクリプトの他に、オンラインおよびオフラインへの移行を準備するPreOnlineスクリプトとPreOffline
スクリプトなど、多くのスクリプトがあります。

参照
hvexecコマンドは、RMSで監視される高可用性構成のスクリプトを実行します。hvexecコマンドの詳細については、RMSウィザードのマ
ニュアルパッケージに含まれているprimer.htmドキュメントを参照してください ("関連マニュアル" を参照)。

3.5.2 ディテクタ
ディテクタは、オブジェクトを監視するプロセスです。 オブジェクト (ディスクグループなど) の状態が変化すると、ディテクタが状態の変化を
RMS BM (ベースモニタ) に通知します。 BM (ベースモニタ) は、この状態変化に対してスクリプトを実行するかどうかを決定できます。

- 55 -
3.5.3 RMSオブジェクト
クラスタシステムは、相互に依存する一連のオブジェクトと見ることができます。 クラスタシステムの一部であるユーザ業務または資源は、オ
ブジェクトの1つで表されます。 RMSグラフでは、オブジェクトの相互依存性を表示できます。
RMS構成で使用される最も重要なオブジェクトを以下に示します。

・ userApplication
クラスタシステムで監視の対象となるユーザ業務です。

・ SysNode
クラスタ内でノードとして稼動するノードです。

・ gResource
ユーザ業務のニーズに従って定義される汎用オブジェクトです。

・ コントローラ
子アプリケーションが親アプリケーションのリソースとして動作できるよう、依存関係を管理します。

構成定義では通常、1つのディテクタが種類を同じくするすべてのオブジェクトに関連付けられています。

- 56 -
第4章 構成変更の例
この章では、Solaris 版 PRIMECLUSTER で、RMS ウィザードを使用して、構築済みのクラスタアプリケーションに対して構成変更を行う
手順の例について説明します。

注意

・ RMS 構成を編集する場合には必ず、RMS を停止してください。Cluster Admin GUI を使用する("7.1.3 RMSの停止"を参照) か、ク

ラスタ内のいずれかのノードから以下のコマンドを入力します。

# hvshut -a

・ 本手順を実施する場合、以下の点に注意してください。
－ userApplication Configuration Wizard でクラスタアプリケーションの設定がすべて完了してから手順を実施してください。
－ hvw コマンド実行時に -n オプションで指定する RMS Configuration 名は wgcnfclient コマンドで確認してください。wgcnfclient コ
マンドの詳細な使用方法については、 "PRIMECLUSTER 導入運用手引書 (Oracle Solaris) " の "6.7.6 RMS Configuration名の
変更" を参照してください。

－ hvw コマンドを実行する際、必ず -xj オプションを付けて実行する必要があります。

4.1 クラスタアプリケーションに PreCheckScriptを設定する

PreCheckScriptをクラスタアプリケーションに設定する手順を以下に示します。

注意
クラスタアプリケーションに対しリソースの追加・設定変更や削除を実施した場合、その手順として、一度 userApplication を削除するこ
とになります。この場合は、本手順による PreCheckScriptの再設定が必要になります。

1. RMS 構成のためのウィザードメニューを表示させるために、次のコマンドを入力します。

# hvw -xj -n configname

- 57 -
2. RMS ウィザードが起動し、メイン構成メニューが表示されます。
"Application-Edit"と入力して[Application-Edit] を選択します。

図4.1 メイン構成メニュー

3. "OPTIONS"と入力して[OPTIONS] を選択します。

図4.2 [Application selection] メニュー

4. "ShowAllAvailableWizards"と入力して[ShowAllAvailableWizards]を選択します。

図4.3 アプリケーションの設定オプションメニュー

- 58 -
5. 以下の画面で、PreCheckScriptを設定するアプリケーション名を入力し、リターンキーを押します。
ここでは、userApp_0 の PreCheckScriptを設定するため、"userApp_0"と入力しています。

図4.4 [Application selection] メニュー

6. "PreCheckScript"と入力して[(PreCheckScript=)] を選択します。

図4.5 アプリケーションの設定メニュー

- 59 -
7. "FREECHOICE"と入力して[FREECHOICE] を選択します。

図4.6 PreCheckScript の選択メニュー

8. PreCheckScriptのファイルパスを入力し、リターンキーを押します。
以下の画面の場合は、PreCheckScriptに /usr/local/app/PreCheck.sh を指定しています。

図4.7 PreCheckScript の入力

- 60 -
9. "SAVE+EXIT"と入力して[SAVE+EXIT] を選択します。

図4.8 アプリケーションの設定メニュー

10. "RETURN"と入力して[RETURN] を選択します。

図4.9 [Application selection] メニュー

- 61 -
11. "Configuration-Activate"と入力して[Configuration-Activate] を選択します。

図4.10 メイン構成メニュー

12. RMS 構成の生成と配布が行われます。

図4.11 RMS 構成定義ファイルの作成と配布

- 62 -
 13. "QUIT"と入力して[QUIT] を選択します。

図4.12 メイン構成メニューの終了

4.2 コントローラのタイムアウト時間を変更する
1. RMS 構成のためのウィザードメニューを表示させるために、次のコマンドを入力します。

# hvw -xj -n configname

2. "Application-Edit"と入力して [Application-Edit] を選択します。

図4.13 メイン構成メニュー

- 63 -
3. "OPTIONS"と入力して[OPTIONS] を選択します。

図4.14 [Application selection] メニュー

4. "ShowAllAvailableWizards"と入力して[ShowAllAvailableWizards] を選択します。

図4.15 アプリケーションの設定オプションメニュー

5. 以下の画面で、タイムアウト時間を変更したいControllerリソースのリソース名を入力し、リターンキーを押します。
ここでは、ScalableCtrl_0のタイムアウト時間を変更するため、"ScalableCtrl_0"と入力しています。

図4.16 [Application selection] メニュー

- 64 -
6. "Controllers"と入力して[Controllers] を選択します。

図4.17 コントローラの設定メニュー

7. "SELECTED:<userApplication名>"と入力して[SELECTED] を選択します。

図4.18 制御対象のアプリケーションの選択メニュー

8. "TIMEOUT"と入力して[TIMEOUT(T)] を選択します。

図4.19 コントローラの属性設定メニュー

- 65 -
9. "FREECHOICE"と入力して[FREECHOICE] を選択し、タイムアウト時間を入力します。
ここでは、タイムアウト時間を2340秒とするため、"2340"を入力しています。

図4.20 TIMEOUT の入力

10. "SAVE+RETURN"と入力して[SAVE+RETURN] を選択します。

図4.21 コントローラの属性設定メニュー

11. "SAVE+EXIT"と入力して[SAVE+EXIT] を選択します。

図4.22 コントローラの設定メニュー

- 66 -
12. "RETURN"と入力して[RETURN] を選択します。

図4.23 [Application selection] メニュー

13. "Configuration-Activate"と入力して[Configuration-Activate] を選択します。

図4.24 メイン構成メニュー

- 67 -
14. RMS 構成の生成と配布が行われます。

図4.25 RMS 構成定義ファイルの作成と配布

15. "QUIT"と入力して[QUIT] を選択します。

図4.26 メイン構成メニューの終了

- 68 -
第5章 Cluster Admin GUIの使用方法
本章では、Cluster Adminグラフィカルユーザインタフェース (GUI) を使用してPRIMECLUSTERを管理する手順について説明します。い
くつかのコマンドラインインタフェース (CLI) についても説明します。

5.1 概要
RMSの管理にはCluster Admin GUIまたはCLIを使用できますが、Cluster Admin GUIを使用することを推奨します。
参考のためCLIの手順が説明されている場合もありますが、CLIの使用は、専門のシステム管理者だけ、またはブラウザが使用できない場合
だけにしてください。

参照
CLI コマンドについては、"付録G RMSコマンドラインインタフェース"を参照してください。

5.2 Cluster Adminの起動

以下のセクションでは、GUIのRMS部分の起動方法を説明します。

注意
Windowsデスクトップシステムでは、"PRIMECLUSTER Web-Based Admin View操作手引書" で指定されたJavaプラグインを使用する必
要があります。

5.2.1 Web-Based Admin View

ブラウザを起動し、次のURLを入力します。

http://<hostname>:8081/Plugin.cgi

hostnameは、プライマリ管理サーバまたはセカンダリ管理サーバの名前またはIPアドレスです。たとえば、FUJIというクラスタのプライマリ管理
サーバおよびセカンダリ管理サーバとしてfuji2とfuji3が設定されている場合、URLは次のいずれかになります。

・ http://fuji2:8081/Plugin.cgi
・ http://fuji3:8081/Plugin.cgi
URLにPlugin.cgiを指定すると、まずプライマリ管理サーバが検索されます。ノードとの通信後、ブラウザはURLのサフィックスを「.cgi」から
「.html」に変更します。Plugin.html 形式を代わりに使用すると、Cluster Admin は URL で指定されたサーバに直接接続しようと試みます。
プライマリ管理サーバとセカンダリ管理サーバの詳細については、"PRIMECLUSTER Web-Based Admin View操作手引書" を参照し
てください。

5.2.2 ログイン
ログインには、適切な権限レベルを持つユーザの「ユーザ名」と「パスワード」が必要です。Cluster Adminには、以下の権限レベルがあります。

・ ルート権限
構成設定、管理、情報の表示など、すべてのアクションを実行できます。

・ 管理者権限
情報の表示および実行ができますが、構成を変更することはできません。

・ オペレータ権限
情報の表示だけを実行できます。

- 69 -
権限レベルの詳細については、"PRIMECLUSTER 導入運用手引書 (Oracle Solaris)" の "4.2.1 クラスタを管理するユーザの作成" または
"PRIMECLUSTER 導入運用手引書 (Linux)" の "4.3.1 クラスタを管理するユーザの作成" を参照してください。
Web-Based Admin Viewログイン画面が表示されたら、次のようにログインします。

1. 適切な権限レベルを持つユーザの「ユーザ名」と「パスワード」を入力します。
2. ＜確認＞ボタンをクリックします。

図5.1 Web-Based Admin Viewログイン画面

3. ログインすると、Web-Based Admin View画面が表示されます。

図5.2 Cluster Services GUIの起動

- 70 -
4. ＜Global Cluster Services＞ボタンをクリックすると、以下の画面が表示されます。

図5.3 Cluster Adminの起動

5. ＜Cluster Admin＞ボタンをクリックすると、ノード選択画面が表示されます。

図5.4 Cluster Admin初期接続メニュー

ノードはアルファベット順に表示され、最初のノードがあらかじめ選択されています。通常は、ユーザがどのノードを選択するかは管
理作業には大きな意味はありません。

6. 接続するノードを選択して＜確認＞ボタンをクリックします。
次に表示される画面は、Cluster Admin Javaアプレットの信頼レベルをどのように設定したかによって異なります。すべてのセッショ
ンで信頼されたアプレットを使用することを選択してある場合は、以下の説明を読む必要はありません。

- 71 -
信頼されたアプレット
プラットフォーム非依存性とセキュリティを確保するため、Cluster Admin GUIではJavaアプレットを使用しています。Javaアプレットは、信頼
されたモードで実行されると、クリップボードなど、クライアントのリソースの一部を使用することが許されます。ワークステーション上で、Java
ウィンドウと他のアプリケーションの間でコピーアンドペーストを使用するには、アプレットを信頼されたモードで実行しておく必要があります。

5.2.3 Cluster Adminメイン画面

Cluster Adminメイン画面の左側パネルに、以下のタブがあります。(以下の図を参照)

・ cf
・ crm
・ rms
・ sis
・ msg (メッセージウィンドウ)

図5.5 Cluster Admin メイン画面 - 初期画面表示

適切なタブを選択してコンポーネントに切替えます。最初は、 [cf] タブ が選択されています。

Cluster Admin GUIには、RMS、CF、SISおよびメッセージウィンドウに共通する以下の標準コンポーネントがあります。

・ プルダウンメニュー
Admin GUIの汎用機能とPRIMECLUSTER製品に固有の機能があります。

・ ツリーパネル
左側のパネルは通常ツリーパネルです。ツリーパネルには製品固有の設定情報が表示されます。ツリーコンポーネントを選択して、メ
インパネルに詳しい情報を表示します。

・ メインパネル
右側の大きいパネルは主な作業および情報領域です。管理する対象の製品およびメニューやツリーで選択した機能に応じて、表示
される内容が変わります。

- 72 -
 注意
本バージョンでは、SISは使用できません。

5.2.4 Cluster Adminメッセージの表示

Cluster Adminに関連するエラーメッセージやデバッグメッセージはCluster Admin上で表示できます。
前回表示した時から表示内容に変化があった場合、それに対応するタブの名前は赤色で表示されます。

図5.6 Cluster Adminメイン画面 - メッセージ画面表示

メッセージパネルは、画面下部のボタンによって別ウィンドウとして表示したり、メイン画面に再度組み込んだりできます。＜クリア＞ボタ
ンをクリックすると、画面上に表示されたすべてのメッセージがクリアされます。

5.3 RMSの状態と属性の表示
このセクションでは、個々のノード、アプリケーション、資源など、RMSクラスタについての情報を表示する手順を説明します。この操作では
情報の表示はできますが、RMS構成設定の内容は変更することができません。
RMSメインウィンドウを起動するには、[rms] タブをクリックします。以下の図のような画面が表示されます。

- 73 -
 図5.7 Cluster Adminメイン画面 - RMS 画面表示

メイン画面は、大きく2つの領域に分かれています。左のパネルにはRMSツリーが表示されます。右のパネルには、RMSツリーで選択した
項目に基づいて、ノード、ログ、またはその両方の設定情報やプロパティが表示されます。

5.3.1 RMSツリー
RMSツリーには、クラスタの構成情報が階層形式で表示されます。ツリーは以下に示すレベルで構成されています。

・ ツリーのルート
クラスタを表します。ルートにはクラスタ名が表示されます。その後ろには括弧付きの RMS 構成名が表示されています。 クラスタ名は、
CF の設定によって決まります。

・ 第1レベル
クラスタを形成するシステムノードを表します。

・ 第2レベル
各システムノードで動作するuserApplicationオブジェクトを表します。

・ 第3レベル
サブアプリケーションを表します。また、独立オブジェクト (andOp、orOp) のグループもここに含まれます (第4レベルの説明を参照)。

・ 第4レベル
各サブアプリケーションに必要な資源を表します。独立オブジェクト (andOp、orOp) も含まれます。

注意
独立オブジェクト (andOp、orOp) は上級者向けです。これらのオブジェクトはノード、アプリケーション、およびサブアプリケーション間の
論理的依存関係やグループとしての結合を示します。

クラスタアプリケーションにサブアプリケーションが存在する場合は、そのサブアプリケーションで使用する資源がオブジェクトとして第4レ
ベルに表示されます。クラスタアプリケーションにサブアプリケーションが存在しない場合は、userApplicationで使用するすべての資源が第3
レベルに表示されます。

- 74 -
クラスタアプリケーション間の依存性は、RMSツリー内でControllerオブジェクトによって表されます。RMSツリーとControllerオブジェクトの例
を以下の図に示します。

図5.8 RMSツリーとControllerオブジェクト

5.3.2 コマンドポップアップ
Cluster Admin の RMS構成ツリー内の各オブジェクトには ポップアップメニューが用意され、よく使われる操作がすぐ選択できるように
なっています。 ポップアップメニューを表示するには、オブジェクトを右クリックします。 メニュー項目の先頭には、選択されたオブジェクトの
名前がグレーアウト表示されます。 それ以外の項目は選択可能な操作です。表示される項目はオブジェクトのタイプと現在の状態により異
なります。

- 75 -
図5.9 コマンドポップアップ

オブジェクトの状態、ノードの状態、およびRMSの構成全体に影響する項目は、メニューの下部に表示されます。これらの操作については
本章の最後のセクションで説明します。

ポイント
操作を選択せずにポップアップメニューを閉じるには、グレーアウト表示されたオブジェクト名をクリックするか、＜Esc＞キーを押します。

たとえば、ノード オブジェクトを選択した場合と、アプリケーションオブジェクトを選択した場合では、メニューに表示される項目が異なります。
また、同じアプリケーションオブジェクトを選択した場合でも、Online状態とOffline状態では異なるメニュー項目が表示されます。

- 76 -
図5.10 Onlineアプリケーションに対するコマンドポップアップ

図5.11 Offlineアプリケーションに対するコマンドポップアップ

5.3.3 ポップアップ確認画面
オブジェクトのポップアップメニューで選択した項目が、そのオブジェクトの状態変更を生じさせるような項目であった場合には、確認の
ポップアップ画面が表示されます。警告メッセージに示された処理を実行する場合は、＜はい＞をクリックし、処理を取り消す場合は＜い
いえ＞をクリックします。

- 77 -
図5.12 確認ポップアップ画面

5.3.4 RMS環境変数の表示
以下の手順に従って、RMSグローバル環境変数を表示します。

1. RMSメインウィンドウのクラスタアイコン上で右クリックし、ポップアップメニューから [環境の表示] を選択します。

図5.13 RMSグローバル環境変数の表示

- 78 -
 2. RMSグローバル環境変数は、右パネルの [環境] タブに表示されます。

図5.14 RMSグローバル環境変数

ポイント
タブ画面を閉じるには、画面右上隅のボタンをクリックします。

以下の手順に従ってRMSローカル環境変数を表示します。

1. RMSメインウィンドウのノード上で右クリックし、ポップアップメニューから [環境の表示] を選択します。

図5.15 RMSローカル環境変数の表示

- 79 -
 2. RMSローカル環境変数とRMSグローバル環境変数は、右パネルの [環境] タブに表示されます。

図5.16 RMSローカル環境変数の表示画面

CLI
hvdisp コマンドで環境変数を表示します。ルート権限は必要ありません。

hvdisp ENV
hvdisp ENVL

5.3.5 オブジェクトの状態の表示
それぞれのRMSオブジェクトの状態は、円形の状態表示アイコンの色によって示されます。状態表示アイコンは、RMSツリーのオブジェクト
名のすぐ左に表示されます。クラスタアプリケーションの状態を示すアイコンの一覧は、RMSツリーの下に表示されます。

- 80 -
 図5.17 クラスタアプリケーションの状態の表示

上記の例では、アプリケーションapp2 は、ノードfuji2RMS上ではOnline (状態表示アイコンが緑) ですが、ノードfuji3RMS上ではOffline

(状態表示アイコンが青) です。

CLI
CLIの構文は次のとおりです。

hvdisp {-a | -c} [-o out_file]

オプションは以下のとおりです。

-a RMS構成内の各オブジェクトについて、オブジェクト名、オブジェクトタイプ、オブジェクトのSysNode名、
オブジェクトの状態を表示する (自動生成のコネクタは表示されない)。

-c 情報を簡潔に表示する。

-o 指定されたファイルに結果を出力する。

hvdispコマンドは、RMSが起動されている場合にのみ実行可能で、ルート権限は必要ありません。

5.3.6 構成情報またはオブジェクト属性
RMSツリーのオブジェクトをマウスで左クリックして、個々のオブジェクトに関する構成情報を表示します。プロパティは、RMSメインウィ
ンドウの右側パネルに一覧表形式で表示されます。

- 81 -
図5.18 構成情報またはオブジェクト属性

- 82 -
第6章 その他の管理ツール
Cluster Admin GUIには、これまでに説明した機能のほかにRMSの管理に役立つツールがいくつか用意されています。

6.1 RMSクラスタテーブルの使用
RMSクラスタテーブルには、アプリケーションオブジェクトに関する状態情報が簡潔な一覧表として表示されます。各システムノード上の各
アプリケーションの状態を確認できます。
クラスタテーブルを開くには、クラスタ名 (RMSツリーのルート) をクリックして、ポップアップメニューから[クラスタテーブルの表示] を選択し
ます。

図6.1 クラスタテーブルを開く

クラスタテーブルは別のウィンドウに表示されます。

図6.2 クラスタテーブル

それぞれの状態表示アイコンの隣に状態名を表示するには、ウィンドウ右下の [状態名の表示] チェックボックスをクリックします。

図6.3 状態名を表示したクラスタテーブル

マウスを使用して、クラスタテーブルウィンドウと列のサイズを調整することができます。ウィンドウ内にすべての項目が表示されている場合は、
サイズを拡大することはできません。
色分けされた円を囲む四角は、userApplicationのプライマリノード (デフォルトで起動時にuserApplicationがOnlineとなるノード) を示し
ています。"図6.3 状態名を表示したクラスタテーブル"は、fuji2がすべてのuserApplicationのプライマリノードであることを示しています。
クラスタテーブルには、通常、アプリケーションが上から下にアルファベット順で表示されます。ただし、Faulted状態のクラスタアプリケー
ションだけは特別に扱われます。クラスタのいずれかのノードで、アプリケーションがFaulted状態にある場合、そのクラスタアプリケーショ

- 83 -
ンはテーブルの一番上に表示され、クラスタアプリケーション名がピンクの背景で強調表示されます。これにより、システム管理者は簡単に
Faulted状態のクラスタアプリケーションを特定することができます。

図6.4 クラスタテーブルでFaulted状態のクラスタアプリケーション

また、クラスタシステムのどこかにOnlineでないクラスタアプリケーションが存在すると、テーブルの一番上に表示され、クラスタアプリケー
ション名が明るい青の背景で強調表示されます。これにより、システム管理者は、どこかに実行中でないクラスタアプリケーションがないか、
どこかのノードでOnlineにすべきノードがないかを把握することができます。

図6.5 クラスタテーブルのOfflineアプリケーション

さらに、Faulted状態のクラスタアプリケーションとOnlineでないクラスタアプリケーションが同時に見つかった場合、Faulted状態のクラスタ
アプリケーションはOnlineでないクラスタアプリケーションの上に表示されます。

図6.6 クラスタテーブルのFaultedアプリケーションとOfflineアプリケーション

クラスタテーブルとRMSツリーの両方に含まれるクラスタにクラスタパーティションの状態が発生すると、ノードの状態を表すアイコン (色付
きの円) の後ろに色付きの感嘆符 (!) が表示されます。この感嘆符は、SysNodeの実際の状態が別のSysNodeから見た状態と異なって
いることを示します。感嘆符の色は、他のノードから見たそのSysNodeの状態を示しています。1つのSysNodeが複数のノードから異なった
状態に見える場合は、色分けされたSysNodeの状態を表すアイコンの後ろに複数の感嘆符が表示されます。感嘆符は状態の重要度の順に
表示されます。
以下の図では、クラスタテーブルに、クラスタパーティション状態が生じたクラスタアプリケーションが表示されています。2番目のノード名の
先頭には、黄色の感嘆符が付けられています。

- 84 -
図6.7 クラスタパーティション状態を示すクラスタテーブル

注意
ノードの起動または停止処理の間、一時的にクラスタパーティション状態が表示される場合があります。

6.1.1 クラスタテーブルからのコマンドポップアップメニューの使用
クラスタ一覧表内の各オブジェクトにはポップアップメニューが用意され、よく使われる操作がすぐに選択できるようになっています。
ポップアップメニューを表示するには、状態表示アイコンが表示されたオブジェクトを右クリックします。列のヘッダはノード名を表し、セ
ルはアプリケーションを表しています。
メニュー項目の先頭には、選択されたオブジェクトの名前がグレーアウト表示されます。それ以外の項目は選択可能な操作です。表示される
項目はオブジェクトのタイプと現在の状態により異なります。

図6.8 クラスタテーブル内のコマンドポップアップの使用

オブジェクトの状態、ノードの状態、およびRMSの構成全体に影響する項目は、メニューの下部に表示されます。 これらの操作については
本章の最後のセクションで説明します。
操作を選択せずにコンテキストメニューを閉じるには、グレーアウト表示されたオブジェクト名をクリックするか、＜Esc＞キーを押します。

6.2 RMSグラフの使用
Cluster Adminでは、RMS構成の階層構造を表示する手段として、RMSグラフと呼ばれる形式も用意しています。RMSグラフは実際のRMS
構成をツリー構造として表現します。これまでに説明したRMS構成ツリーでは通常は表示されない依存関係も枝として表されます。RMS
グラフには次のようなタイプがあります。

・ RMSクラスタ全体のグラフ
現在RMSが動作しているRMSクラスタ構成全体が表示されます。

- 85 -
 ・ RMSアプリケーショングラフ
指定された1つのクラスタアプリケーションが使用するオブジェクトがすべて表示されます。このグラフを使用して、特定のオブジェクトの
詳細情報を調べることができます。

・ RMSサブアプリケーショングラフ
指定されたクラスタアプリケーションが使用するすべてのRMSサブアプリケーション、およびRMSサブアプリケーション間の関係が表示
されます。

・ RMS合成サブアプリケーショングラフ
直接または間接的に依存しているすべてのRMSサブアプリケーションが表示されます。

以下のセクションでは各モデルについて、グラフに関連した機能とともに詳しく説明します。

・ 構成情報の取得
・ ポップアップメニューの使用法
・ さまざまなレベルの詳細表示
・ クラスタテーブルおよびグラフにおける表示の変更の意味

6.2.1 RMSクラスタ全体のグラフ
システムノードのいずれかを右クリックし、ポップアップメニューから [グラフの表示] を選択するとRMSクラスタ全体のグラフが表示されます。

図6.9 ノード上でRMSクラスタ全体のグラフを表示

注意
[グラフの表示] メニュー項目は、そのノード上ですでにRMSグラフが開かれている場合でないと使用できません。

デフォルトでは、各グラフはCluster Admin Viewの右パネルに独立したタブとして表示されます。

- 86 -
図6.10 ノードのRMSクラスタ全体のグラフ - タブ画面

タブを別ウィンドウで表示するには、＜デタッチ＞ボタンをクリックします。＜デタッチ＞ボタンは、画面右上隅の＜閉じる＞ボタンの隣に
あります。

図6.11 タブ画面の＜デタッチ＞ボタン拡大図

別ウィンドウに表示された場合でも、内容はタブ表示と同じです。

- 87 -
図6.12 ノードのRMSクラスタ全体のグラフ - 別ウィンドウで表示

切り離したウィンドウをCluster Admin画面に戻すには、＜アタッチ＞ボタンをクリックします。＜アタッチ＞ボタンは、画面右上隅の＜閉じる＞
ボタンの隣にあります。標準のウィンドウ制御ボタンのすぐ下です。

図6.13 別ウィンドウの＜アタッチ＞ボタン拡大図

RMSクラスタ全体のグラフには、クラスタのRMS構成全体と以下の内容が表示されます。

・ アプリケーションがOnlineになっているノードでは、ノードとアプリケーションオブジェクト間が緑の線で結ばれている
・ オブジェクトタイプはオブジェクトのアイコンで表示
・ オブジェクトの現在の状態は、各アイコンの下の色付きのバーで表示
・ オブジェクト間の関係
・ オブジェクトの依存性
RMSグラフは、特定のシステムノードの観点から表示されます。つまり、各ノードの状態情報はすべて、特定のシステムノードから見た状態
として表示されます。RMSグラフのタイトルバーに表示されるノード名は、状態情報を提供するノードを示しています。ユーザは任意の
クラスタノードから見たRMSグラフを表示できます。
グラフの背景にはグレーの帯が表示されます。この帯は上から下に向かってだんだんと濃いグレーになります。 大きく複雑なグラフの場合は、
各オブジェクトがどの場所にあるか、依存レベルはどうか、を把握する際にこの帯が役立ちます。
RMSグラフ内のあるオブジェクトにマウスカーソルを合わせると、カーソルが十字線に変わり、オブジェクト名が表示されます。各オブジェ
クトから出ている結合線は、親子関係にある場合は黄色で表示されます。

- 88 -
図6.14 RMSクラスタ全体のグラフ - オブジェクト名の表示

オブジェクトをクリックすると、オブジェクトの属性をはじめとする詳細情報が記載されたウィンドウが表示されます。

図6.15 RMSクラスタ全体のグラフ - オブジェクトの詳細

6.2.2 RMSアプリケーショングラフ
クラスタアプリケーションを右クリックし、ポップアップメニューから [アプリケーショングラフの表示] を選択すると、1つのクラスタアプリケー
ションに対するRMSグラフを表示できます。

- 89 -
図6.16 RMSアプリケーショングラフの表示

RMSアプリケーショングラフには、選択されたアプリケーションとそのリソースだけが表示されますが、それ以外の点ではRMSクラスタ全体
のグラフと同様です。全体グラフと同様に、RMSアプリケーショングラフは、選択したノードの観点から表示され、アプリケーション名および
詳細情報も表示されます。

図6.17 RMSアプリケーショングラフの例

6.2.3 RMSサブアプリケーショングラフ
親のクラスタアプリケーションを右クリックし、ポップアップメニューから [サブアプリケーショングラフの表示] を選択すると、RMSサブアプ
リケーショングラフが表示できます。

- 90 -
図6.18 RMSサブアプリケーショングラフの表示

このグラフには、選択したアプリケーションが使用するすべてのサブアプリケーションと、それら相互の結合状態が表示されます。

図6.19 RMSサブアプリケーショングラフの例

図を見やすくするため、ここでは、オブジェクト名は実際の画面とは異なってラベルで表示しています。また、独立オブジェクトなどの抽
象概念も省略しています。他のグラフ同様、オブジェクトをクリックすると属性を表示する画面が表示されます。

6.2.4 RMS合成サブアプリケーショングラフ

注意
RMS合成サブアプリケーショングラフは、コントローラオブジェクトを持つアプリケーションでのみ使用できます。

構成にコントローラオブジェクトが含まれる場合、ノード (またはアプリケーション) のクラスタ全体のグラフでは、親アプリケーションと子ア

プリケーションは別々のブランチに表示されます。

- 91 -
図6.20 制御対象アプリケーションがある場合の構成の標準表示

場合によっては、子アプリケーションを親のリソースとして扱うことにより、同じブランチに表示したほうが便利です。 同じブランチに表示し
たグラフをRMS合成サブアプリケーショングラフと呼びます。
クラスタアプリケーションを右クリックし、ポップアップメニューから [合成サブアプリケーショングラフの表示] を選択すると、RMS合成サブ
アプリケーショングラフが表示できます。

図6.21 RMS合成サブアプリケーショングラフの表示

RMS合成サブアプリケーショングラフは、RMSサブアプリケーショングラフの一種で、制御されるアプリケーションが存在する場合に使用し
ます。RMSサブアプリケーショングラフ内のすべての「制御するオブジェクト」について、対応する「制御されるアプリケーション」のグラフが、
親アプリケーションと点線で結ばれた形で挿入されます。たとえば、app1が、以下の図内のRMS合成サブアプリケーショングラフ内に表示

- 92 -
される様子を、図6.20 制御対象アプリケーションがある場合の構成の標準表示の通常のRMSサブアプリケーショングラフと比較してみ
てください。

図6.22 RMS合成サブアプリケーショングラフの例

依存しているアプリケーションにコントローラオブジェクトがある場合は、このプロセスが繰り返されます。このため、選択したクラスタアプ
リケーションが直接または間接的に依存しているすべてのサブアプリケーションを合成表示することができます。

6.2.5 グラフからコマンドポップアップメニューの使用
RMSグラフ内の各オブジェクトにはポップアップのコンテキストメニューが用意され、よく使われる操作がすぐに選択できるようになっています。
コンテキストメニューを表示するには、グラフ内のオブジェクトを右クリックします。
メニュー項目の先頭には、選択されたオブジェクトの名前がグレーアウト表示されます。それ以外の項目は選択可能な操作です。表示される
項目はオブジェクトのタイプと現在の状態により異なります。

- 93 -
図6.23 RMSグラフからコマンドポップアップメニューを使用する

オブジェクトの状態、ノードの状態、およびRMSの構成全体に影響する項目は、メニューの下部に表示されます。 これらの操作については
本章の最後のセクションで説明します。
操作を選択せずにコンテキストメニューを閉じるには、グレーアウト表示されたオブジェクト名をクリックするか、＜Esc＞キーを押します。

6.2.6 表示された詳細レベルの変更
RMSクラスタ全体のグラフおよびRMSアプリケーショングラフのデフォルトの設定では、オブジェクト (リソース) 名が表示されません。特定
のオブジェクト上にマウスポインタを置くと、これらの名前を表示できます。
リソース名、Affiliation名、NoDisplayノードをグラフに追加するには、[設定] メニューでそれぞれのチェックボックスをオンにします。
以下の図は [設定] メニュー項目を選択した画面と、その選択に対応してリソース名が表示されたグラフを示しています。

- 94 -
図6.24 Affiliation名付きRMSグラフの表示

以下の図は、[設定] メニューで項目を選択した状態とそれに対応するリソース名を表示するグラフを示しています。

- 95 -
図6.25 リソース名付きRMSグラフ

以下の図は [設定] メニュー項目を選択した画面と、その選択によってNoDisplayオブジェクトが表示されたグラフを示しています。 これらは

通常、構成ツールで自動的に生成される論理AND/ORオブジェクトです。

- 96 -
図6.26 リソース付き RMSグラフ

以下の図のように、複数の表示オプションが選択されると、オブジェクト名やリソース名が画面に入りきらない場合があります。グラフがウィ
ンドウの幅より大きい場合は水平スクロールバーが表示されますが、グラフの見にくさは残ります。

- 97 -
図6.27 Affiliation名とリソース名付きRMSグラフ

複雑なグラフでは、リソース名をアルファベット順に並べると見やすくなる場合があります。

図6.28 グラフ内のオブジェクト名の並べ替え

6.3 表示変更の意味
Cluster Admin View、グラフ、およびクラスタテーブルのいずれにおいても構成全体だけでなくノード個々の状態を表示することができます。

6.3.1 RMS構成変更時の表示
RMSを停止して異なる構成で再起動すると、RMSツリー、クラスタテーブル、およびノードグラフも同じウィンドウに再作成されます。以下の図
はCluster Admin画面に2つのノードグラフとクラスタテーブルを重ねて表示しています。これらはすべて、app1とapp2を監視する実行中の
構成の状態を表しています。

- 98 -
図6.29 RMSを停止する前のクラスタの状態

以下の図は、 RMSが再起動した後の同じウィンドウです。前回とは異なり、app1とapp2を監視する構成で起動されています。

図6.30 異なる構成でRMSを再起動した後のクラスタの状態

グラフとクラスタテーブルは、再起動の前後で同一のSysNodeオブジェクト (fuji2 およびfuji3) の状態を表示しているため、ウィンドウは開

かれたままです。

- 99 -
6.3.2 RMS停止後のグラフの見方
RMSを停止すると、RMSのGUI (グラフやクラスタテーブルなど) は接続先ノードから情報を取得できないため暗い灰色になります。この場合、
すべての状態が白で表示されます。RMSが起動しているノードに接続すると、情報を再表示できます。
たとえば、サンプルクラスタでRMSが1つのノードでのみ停止した場合を考えてみます。 そのノードのグラフおよびクラスタテーブルの対応
する列は、背景が濃いグレーで表示されます。

図6.31 1つのノード停止後のRMSメイン画面、グラフ、クラスタテーブル

しかし、残りのノードfuji3上でRMSが稼動を続ける限り、RMSメイン画面、fuji3RMSグラフ、クラスタテーブルのfuji3の列には、Onlineの
オブジェクトが引き続き表示されます。

アプリケーショングラフおよびサブアプリケーショングラフ
ノードが停止すると、そのノード上のアプリケーションおよびサブアプリケーションもすべてShutdownの状態に変わります。

- 100 -
図6.32 シャットダウンノードのRMS アプリケーショングラフ

グラフの表示はノードが同じ構成で再起動されるまで変わりません。再起動されると、通常の表示に戻ります。
ノードが異なる構成で再起動された場合はグラフの内容は削除されます。これは、新しい構成内ではそのオブジェクトが存在しないた
めです。 ただし、空のグラフウィンドウは明示的に閉じない限り開いたままで残ります。

図6.33 削除したオブジェクトのグラフウィンドウ

6.4 RMS ログメッセージの表示

Cluster Adminインタフェースが持つログ表示機能により、任意のノードで、RMSのswitchlogおよびアプリケーションのログに含まれるエ
ントリを表示し、フィルタリングすることができます。

参考
すべてのRMSログファイル (通常は/var/opt/SMAWRrms/log/) は、viなどのUNIXの一般的なエディタを使用して表示することができます。

- 101 -
 参照
エラーメッセージの意味と、可能な対処方法については“PRIMECLUSTER 活用ガイド<メッセージ集>”を参照してください。

以下の手順に従って、システムノードのswitchlog を表示します。
システムノード上で右クリックし、ポップアップメニューから [switchlog の表示] を選択します。

図6.34 ポップアップメニューからRMS switchlog ファイルを表示

または、ノードを選択して [ ツール] - [switchlog の表示] を選択します。

図6.35 [ツール] メニューからRMS switchlog を表示

以下の手順に従ってアプリケーションログを表示します。
RMS ツリー内のアプリケーション上で右クリックし、ポップアップメニューから [ ログファイルの表示] を選択します。

- 102 -
図6.36 ポップアップメニューからアプリケーションログを表示

注意
オブジェクトに対応するポップアップメニューは、Cluster Admin画面、クラスタテーブル、オブジェクトを含む任意のRMSグラフのいずれ
からも起動することができます。

いずれの場合でも、ログは右側パネルの専用タブに表示されます。

図6.37 タブビューに表示された RMS switchlog

- 103 -
タブを別ウィンドウで表示するには、＜デタッチ＞ボタンをクリックします。 ＜デタッチ＞ボタンは、画面右上隅の＜ヘルプ＞ボタンと＜閉じる
＞ボタンとの間にあります。

図6.38 タブ画面の＜デタッチ＞ボタン拡大図

別ウィンドウに表示された場合でも、内容はタブ表示と同じです。

図6.39 別ウィンドウに表示されたRMS switchlog

切り離したウィンドウをCluster Admin画面に戻すには、＜アタッチ＞ボタンをクリックします。 ＜アタッチ＞ボタンは、＜ヘルプ＞ボタンと＜閉

じる＞ボタンとの間にあります。標準のウィンドウ制御ボタンのすぐ下です。

図6.40 別ウィンドウの＜アタッチ＞ボタン拡大図

- 104 -
 ポイント
別ウィンドウ表示では、画面の＜閉じる＞ボタンとウィンドウ標準の＜閉じる＞ボタンの機能は同じです。どちらをクリックしてもウィンドウは閉
じます。
メイン画面表示では、タブ表示画面の＜閉じる＞ボタンをクリックすると表示中のタブのみが閉じられます。他のタブ画面は開いたままです。

6.4.1 switchlog およびアプリケーションログを表示する一般的な手順

デフォルトでは、ウィンドウ下部のスクロール領域にログ全体が表示されます。表示されるログは、以下のフィルタで絞り込むことができます。

・ [時刻フィルタ]
対象となる時間範囲を指定します。

・ [キーワードフィルタ]
特定のリソース名 (アプリケーションの場合のみ)、エラーメッセージの重要度レベル、0以外の終了コード、またはキーワードを選択します。

参照
重要度レベルの詳細は"6.4.3.2 重要度"を、終了コードの詳細は、“PRIMECLUSTER 活用ガイド<メッセージ集>” を参照してください。

フィルタ項目の入力後、＜フィルタ＞ボタンをクリックすると、フィルタで絞り込んだログエントリが表示されます。

注意
[時刻フィルタ]と[キーワードフィルタ]の両方を設定すると、両方の条件を満たしたログエントリに絞り込むことができます。

switchlog のエントリは、ログビューアウィンドウの [昇順] チェックボックスをオンまたはオフにすることにより、時系列昇順または降順にい

つでも並べ替えることができます。

6.4.2 時刻フィルタ
[時刻フィルタ]に日付と時刻を指定して、ログウィンドウに表示するエントリを絞り込むことができます。

- 105 -
 図6.41 日付時刻による検索

入力ボックスのスピンボタンで[開始時刻]と[終了時刻]を選択し(値を直接入力することもできます)、[有効]チェックボックスをオンにします。
ここでの設定は、＜フィルタ＞ボタンをクリックしたときに有効になります。
時刻フィルタを削除するには、[有効]チェックボックスをオフにして、＜フィルタ＞ボタンをクリックします。

6.4.3 キーワードフィルタ
［キーワードフィルタ］パネルには、以下の項目があります。

6.4.3.1 リソース名

注意
［リソース名］コントロールを使用できるのは、アプリケーションログの場合のみです。

ドロップダウンリストからリソース名を選択し、＜フィルタ＞ボタンをクリックします。

- 106 -
 図6.42 リソース名による検索

リソース名のフィルタを削除するには、ドロップダウンリストで[選択なし]を選択し、＜フィルタ＞ボタンをクリックします。

6.4.3.2 重要度
ドロップダウンリストからメッセージの重要度レベルを選択します。

- 107 -
 図6.43 重要度による検索

以下の表にRMS の重要度レベルを説明します。

表6.1 RMS の重要度レベルの説明

重要度レベル 説明
Emergency システム使用不能
Alert 直ちに対処が必要
Critical 重要な状態（致命的なエラー）
Error エラー状態（致命的でないエラー）
Warning 注意状態
Notice 普通だが通告を要する状態
Info その他の情報
Debug デバッグメッセージ

重要度レベルのフィルタを削除するには、ドロップダウンリストで[選択なし]を選択し、＜フィルタ＞ボタンをクリックします。

6.4.3.3 0以外の終了コード
[0以外の終了コード]入力ボックスに終了コードを数値で入力し、＜フィルタ＞ボタンをクリックします。

6.4.3.4 キーワード
[キーワード]ボックスに文字列を入力し、＜フィルタ＞ボタンをクリックします。

- 108 -
図6.44 キーワードによる検索

注意
特殊文字および空白は使用できますが、ワイルドカードは使用できません。検索では大文字と小文字が区別されません。

キーワードのフィルタを削除するには、キーワードボックスの文字列をクリアし、＜フィルタ＞ボタンをクリックします。

6.4.4 テキスト検索
表示中のアプリケーションログの上で右クリックして、テキスト検索を行うことができます。[検索]ポップアップダイアログで文字列を入力すると、
指定した方向に向かって大文字と小文字を区別した検索が行われます。

- 109 -
図6.45 ログビューア上のポップアップ検索ダイアログ

注意
入力した文字列は、完全一致で検索されます。スペースや特殊文字を使用することができますが、ワイルドカードは無効です。

6.4.5 フィルタの削除
すべてのフィルタを削除するには、以下の手順を行います。

1. 時刻フィルタの [有効] チェックボックスをオフにします。

2. ドロップダウンリストで [選択なし] を選択します。
3. 入力ボックスのテキストを削除します。
4. ＜フィルタ＞ボタンをクリックします。
フィルタによる絞り込みのない検索結果が再度表示されます。

- 110 -
第7章 RMSの操作
本章では、RMSの操作について説明します。

7.1 RMS の操作について

このセクションでは、個々のノード上で動作するRMSやアプリケーションの操作等、基本的な手順について説明します。このセクションで説明
する手順を実行すると、実際にRMSクラスタの状態が変更され、データの処理に直接の影響が及びます。
"5.1 概要"で述べたように、クラスタの管理にはできるだけCluster Admin GUIを使用してください。ただし、このセクションで説明する各手順
は、必要に応じてCLIでも行うことができます。その場合には以下の点に注意してください。

・ コマンドは、<RELIANT_PATH>/binディレクトリに格納されています。
・ RMS CLIのすべてのコマンドでは、CFノード名およびRMSノード名が、RMSの命名規則に従っている場合 (<CF名>RMSの形の名前
である場合)、両方ともSysNodeオブジェクトとして扱います。

・ コマンドの説明では、使用頻度の高いオプションのみを記載しています。このため、それ以外にも使用できるオプションが存在する場合
があります。コマンドの詳細については、"PRIMECLUSTER 活用ガイド＜コマンドリファレンス編＞"を参照してください。

7.1.1 RMSの起動
GUIからは、直前に使用した構成しか起動できません。その他の構成を起動するには、まずRMS Wizard Tools を使用してその構成を配布
する必要があります。
GUIのデフォルトの設定では、クラスタ内のすべてのノードでRMSを起動するようになっています。この他に、選択したノードでのみRMSを
起動することもできます。

1. Cluster Adminを起動して [rms] タブをクリックしてRMSメインウィンドウを表示します。[ツール] メニューから [RMSの起動] を選択し

ます。

図7.1 メインメニューからRMSを起動

- 111 -
 2. [RMS起動メニュー] 画面が表示されます。すべてのノード上でRMSを起動するには、[利用可能なすべてのノード] ラジオボタン
をクリックして＜確認＞ボタンをクリックします。

図7.2 すべてのノードのRMS起動メニュー

3. 選択されたノード上でのみRMSを起動するには、[リストから1つを選択] ラジオボタンをクリックしてから、[選択] 列のチェックボックスで1

つまたは複数のノードを選択できます。選択するノードをチェックしたら、＜確認＞ボタンをクリックします。

図7.3 個々のノードでのRMS起動メニュー

この他に、[Cluster Admin] 画面から個々のノード上のRMSを直接起動することもできます。

- 112 -
 1. 左パネルの [rms] タブをクリックして、クラスタツリーを表示します。
2. ノードを選択した状態で右クリックし、ポップアップメニューから[RMSの起動]を選択します。

図7.4 各ノード上でRMSの起動

CLI: hvcm
hvcmコマンドは、すべての監視リソースに対するベースモニタとディテクタを起動します。hvcmのCLI構文では以下の2つの形式が可能で
す。
フォーマット 1

hvcm [-a | -s SysNode]

フォーマット 2

hvcm -c config_name [-a | -s SysNode] [-h timeout] [-l loglevels]

オプションは以下のとおりです。

-a RMS構成内のすべてのノード上でRMSを起動する。

-s 指定されたノード上でのみRMSを起動する。

-aと-sのいずれも指定されていない場合は、hvcmはローカルノード上でのみRMSを起動します。
フォーマット2でのみ使用できるオプションは以下のとおりです。

-c 指定された構成定義ファイルを使用する。

-h 指定されたハートビートリカバリタイムアウト値を使用する。

-l 診断出力を指定したレベルで起動する。

- 113 -
 注意
最後に起動した構成設定以外の起動、ハートビートリカバリタイムアウト値の変更、または、診断レベルの設定は、CLIから行う必要があ
ります。これらのパラメタはCluster Admin GUIから指定することはできません。

フォーマット1に関する注意
-cオプションが指定されていない場合、hvcmはデフォルトのCONFIG.rms起動ファイルを読込みます。hvcmは、デフォルトの起動ファイルを、
<RELIANT_PATH>/etc/CONFIG.rmsで検索します。環境変数RELIANT_PATHは、デフォルトの設定が変更されていなければ、/opt/
SMAW/SMAWRrms/etc/CONFIG.rmsです。なお、-aまたは-sオプションを指定してRMSをリモートで起動した場合でも、検索は常にロー
カルノードに限定されます。
CONFIG.rms ファイルには以下のいずれかが含まれています。

・ 構成名。サフィックス.usが付けられる場合もあります。
・ 最後に起動した構成で始まるフォーマット2で記述されたhvcmコマンド。
-h および-l オプションは、フォーマット1では使用できません。ただし、CONFIG.rmsファイルを編集し、フォーマット2のオプションを挿入す
ることはできます。

フォーマット2に関する注意
-c オプションが指定されている場合に、構成定義ファイルが絶対パスで指定されていないと、hvcmは<RELIANT_STARTUP_PATH>を
検索します。環境変数RELIANT_STARTUP_PATHは、デフォルトの設定が変更されていなければ、opt/SMAW/SMAWRrms/build/
<config_name>.us (構成定義ファイル名に.usが付けられていない場合はhvcmによって追加されます) です。絶対パスが指定されている
場合は、hvcmはそのファイルのみを読取り対象にします。なお、-aまたは-sオプションを指定してRMSをリモートで起動した場合でも、検索は
常にローカルノードに限定されます。
hvcmは、指定された構成定義ファイルを検出すると、デフォルトのCONFIG.rmsファイルも存在するかを確認します。存在する場合は、hvcm
は両方のファイルに記述された構成名が一致しているかを確認します。一致していない場合、hvcmは起動処理を中止します。タイムア
ウトのデフォルト値は、RMSがクラスタの監視にどちらの方法を使用するかによって決まります。
-hオプションはクラスタのUDPハートビートリカバリタイムアウト値を設定します。"ノードとハートビート"を参照してください。

・ デフォルトでは、RMSは各ノードの状態を、CFに実装されたELMを使用して監視します。ELMはポーリングを行いません。ELMでは、
各ノードに保持されノードまたはベースモニタが停止したときに解放されるロックを使用します。ELMが起動されると、UDPハートビー
トタイムアウトのデフォルト値は600秒に設定されます。

・ ローリングアップデートやデバッグのためにELMを停止する必要がある場合は、HV_USE_ELM環境変数を0に設定します。"E.2 RMS
グローバル環境変数" の"HV_USE_ELM" を参照してください。ELMが停止されると、UDPハートビートタイムアウトのデフォルト値は45
秒に設定されます。

注意
ハートビートタイムアウト値をデフォルト値より小さく設定すると、ノードがリカバリできる状態であるにもかかわらず処理途中で停止される
ことがあります。この場合、ノードの停止は通常終了で行われるため、データの破損は発生しません。しかし、アプリケーションの他ノードへの
切替えが発生するため、その遅延によってクラスタの性能が低下する場合があります。ハートビートタイムアウト値をあまり小さくし過ぎると、CF
イベントタイムアウトとの干渉が発生する場合があります。

-lオプションは、起動時の診断出力レベルを設定します。loglevelsの指定は、個々のレベルを数値で直接指定するか、ハイフンで区切った
範囲で指定します。複数指定する場合は、カンマで区切ります。

7.1.2 システム起動時にRMSを自動起動する

注意
この設定はシステムの再起動後に有効になります。

- 114 -
システム起動時にRMSが自動起動するように設定したり、その設定を解除したりするには、以下の手順で行います。
Cluster Adminを起動し、 [rms] タブをクリックしてRMSメインウィンドウを表示します。[ツール] メニューから [RMSの自動起動を設定] を選択
します。

図7.5 RMS自動起動の制御 - ステップ 1

ここで、全ノードまたは1つのノードについて、RMSの自動起動の開始 (または停止) を選択します。

図7.6 RMS自動起動の制御 - ステップ 2

注意
本設定を行う場合、クラスタを構成する全ノードの Web-Based Admin View と CF が動作している必要があります。
Web-Based Admin View サーバプロセスの状態確認と起動方法は、"PRIMECLUSTER 導入運用手引書"の"Web-Based Admin View の
初期設定" を参照してください。

- 115 -
 CF の状態確認と起動方法は、"PRIMECLUSTER Cluster Foundation 導入運用手引書"の"メインCFテーブル"と"CFの起動と停止"を参照
してください。

CLI: hvsetenv
システム起動時、RMS環境変数 HV_RCSTARTが1に設定されていると、RMS rcスクリプトはCONFIG.rmsファイルを使用してRMSを起動
します。RMS環境変数HV_RCSTARTは、以下のようにhvsetenvコマンドを使って変更できます。

hvsetenv HV_RCSTART [0|1]

設定値は以下のとおりです。

0 システム起動時にRMSを起動しない

1 システム起動時にRMSを起動する (デフォルト)

値を指定しないと、コマンドはRMS環境変数HV_RCSTARTの現在の値を通知します。

7.1.3 RMSの停止
RMSの停止は、すべてのノードまたは指定したノードで実行することができます。
[ツール] プルダウンメニューから [RMSの停止] を選択します。

図7.7 [ツール] メニューからRMSを停止

すべてのノード上でRMSを停止するには、[利用可能なすべてのノード] ラジオボタンをクリックして＜確認＞ボタンをクリックします。

- 116 -
図7.8 稼動中のすべてのノード上でRMSを停止

[利用可能なすべてのノード] を停止する場合は、2つのラジオボタンでアプリケーションの処理を指定できます。

・ 停止－ すべてのユーザアプリケーションを停止する
・ RMSのみ停止－ アプリケーションを稼動した状態に保つ

注意
RMS停止後もアプリケーションを稼動させた状態にしておくと、データの不整合や破損が生じる恐れがあります。

特定のノード上でRMSを停止するには、[リストから1つを選択] ラジオボタンを選択して、停止するノードのチェックボックスをオンにします。

- 117 -
図7.9 リストから選択したノード上でRMSを停止

各ノードには[オプション] 列にドロップダウンリストがあり、以下の処理が選択できます。

・ 停止 - 選択したノードですべてのユーザアプリケーションを停止
・ RMSのみ停止 - 選択したノード上でアプリケーションを継続稼動
・ 強制停止 - RMSの強制停止を実行

注意

・ [RMSのみ停止] または [強制停止] を選択すると、データの整合性が失われたりデータが破損する場合があります。

・ RMS の起動中は RMS の停止を実行しないでください。ノード間のハートビートが途切れ、RMS の停止を実行したノードが強制停止
する場合があります。

＜確認＞ボタンをクリックすると、停止の方法を選択する画面が表示されます。
すべてのノードまたは1つのノードにおけるRMSの停止について、デフォルトのオプションは、 [停止]です。デフォルト以外のオプションを
選択した場合は、確認メッセージが表示されます。

- 118 -
図7.10 アプリケーションを現状のままRMSを停止 - 確認

図7.11 RMSの強制終了 - 確認

RMSツリーのノードを右クリックして、ポップアップメニューから [RMSの停止] を選択すると、そのノード上のRMSを停止できます。

図7.12 ポップアップメニューを使用して1つのノード上でRMSを停止

確認画面にノードが1つだけ表示されます。

- 119 -
 図7.13 RMSを1つのノード上で停止

注意
スケーラブルコントローラを含む「制御するアプリケーション」を起動した場合、起動処理中(Wait状態)にRMSの停止操作をしないでください。
RMSの停止を行った場合、停止処理がタイムアウトすることがあります。

CLI: hvshut
CLIの構文は次のとおりです。

hvshut {-a | -A | -f | -l | -L | -s SysNode}

オプションは以下のとおりです。

-a すべてのノード上のRMSとアプリケーションを停止する。

-A アプリケーションを停止せずに、すべてのノード上のRMSを停止する。

-f ローカルノード上のRMSを強制 (緊急) 停止する。

-l ローカルノード上のRMSとアプリケーションを停止する。

-L アプリケーションを停止せずにローカルノード上のRMSを停止する。

-s 指定されたノード上のRMSのみを停止する。

- 120 -
 hvshutコマンドは、1つ以上のノード上でRMSを停止します。ローカルノード上のベースモニタは、どのノード上でRMSが停止されるかを伝
えるメッセージを他のOnlineノードに送信します。hvshutコマンドは、停止するノード上ですべてのエラー検出とエラー修復を無効にしますが、
オペレーティングシステムはシャットダウンしません。
userApplicationオブジェクトがOnlineのときに-Aオプション、-fオプション、または-Lオプションを使用すると、クラスタアプリケーションは稼動
し続けますが、RMSによって監視されなくなります。-fオプションと-Lオプションのいずれもローカルノードでのみ効力を持つ点は同じで
すが、-fオプションは緊急用です (他のhvshutオプションで効果がない場合にのみ使用してください)。
RMSを停止する場合は、監視されたアプリケーションを停止する前にRMSを停止しようとすると、操作の確認を求めるメッセージが表示さ
れます。

注意

・ -Aオプション、-fオプション、-Lオプションを使用すると、データの整合性が失われたり、データが破損したりする場合があるので、注意が
必要です。

・ 3ノード以上で動作可能な userApplication が存在する構成においてRMSを停止する場合、以下のいずれかの手順で実施してください。

－ すべてのノードの RMS を停止する場合
いずれか1つのノードで hvshut -a コマンドを実行してください。

－ 2ノード以上(すべてのノードは除く)の RMS を停止する場合

1ノードずつで hvshutコマンドを実行し、RMSを停止してください。このとき、あるノードのhvshutコマンドが復帰してから、次のノー
ドでhvshutコマンドを実行するようにしてください。

7.1.4 SysNodeのWait状態のクリア
以下の手順でノードの Wait 状態をクリアすることができます。

1. Wait状態のノードを手動で停止します。ノードが完全に停止されたことを確認してください。
2. CF メインウィンドウで CF の状態を確認します。
CF の状態が LEFTCLUSTER の場合は、CF メインウィンドウで LEFTCLUSTER を解消し、DOWN 状態にします。
LEFTCLUSTER状態については、"PRIMECLUSTER Cluster Foundation 導入運用手引書"を参照してください。

3. Wait状態が解消されない場合、RMS メインウィンドウに表示されるノード上で右クリックし、ポップアップメニューから [Wait状態を

クリアして停止(hvutil -u)] を選択し、Wait状態のノードをサブメニューから選択します。

注意
手順3.でWait状態を手動でクリアする場合、RMS および CF は、対象ノードが停止済みであるとみなします。そのため、ノードが実際に停止
していない状態で Wait状態のクリアを行うと、データが破損する可能性があります。

CLI: hvutil -u
上記の手順3.の操作をCLI で行う場合の構文は次のとおりです。

hvutil -u SysNode

7.2 RMSアプリケーションの管理
このセクションでは、各アプリケーションの起動、停止、および特定の状態をクリアするための基本的な手順について説明します。このセ
クションで説明する手順はRMSクラスタの状態を直ちに変更するため、データの処理に直接の影響を及ぼす可能性があります。
"5.1 概要"で述べたとおり、基本的な管理操作はCluster Admin GUIから行います。操作はできる限りこの方法で行ってください。ただし、
このセクションで説明する手順はそれぞれCLIでも実行することができます。

- 121 -
7.2.1 アプリケーションの自動起動のオーバーライド
RMS起動時のアプリケーションの自動起動は、それぞれのアプリケーションのAutoStartUp 属性によって制御されます。

・ AutoStartUp がyes に設定されている場合、RMS 起動時にそのアプリケーションは自動起動します。

・ AutoStartUp がno に設定されている場合、RMS起動時にそのアプリケーションは自動起動しません(手動で起動する必要があります)。
メンテナンス時やトラブルシューティング時などでは、RMS起動時にすべてのアプリケーションの自動起動を抑止したい場合があります。
そのような場合、RMS 環境変数HV_AUTOSTARTUPの値を変更することで、すべてのアプリケーションのAutoStartUp属性を一括して
無効にすることができます。HV_AUTOSTARTUP環境変数は、以下の手順で変更できます。

注意
HV_AUTOSTARTUPに加えた変更は次回RMSを起動するまで有効になりません。

1. Cluster Adminを起動し、[rms] タブをクリックしてRMSメインウィンドウを表示します。[ツール] メニューから [userApplicationの自動

起動を設定] を選択します。

図7.14 アプリケーションの自動起動の制御 - ステップ1

- 122 -
 2. 次にすべてのAutoStartUp設定の変更を指定します。指定を中止するには[取消] をクリックします。

図7.15 アプリケーションの自動起動の制御 - ステップ2

注意

・ userApplication の自動起動を有効にした場合でも、AutoStartUp がno に設定されている userApplication は手動で起動する必要が

あります。

・ userApplication の自動起動の設定は、RMS 起動時のStandby 処理の開始条件を設定するものではありません。RMS 起動時の

Standby 処理の開始条件は、AutoStartUP と StandbyTransition 属性に従います。
詳細については、"PRIMECLUSTER 導入運用手引書"の"6.10.1 クラスタアプリケーションの設定内容"の"立上げ、切替え、故障クリア
時に userApplicationを自動起動させたい"を参照してください。

・ 本設定を行う場合、クラスタを構成する全ノードの Web-Based Admin View と CF が動作している必要があります。

Web-Based Admin View サーバプロセスの状態確認と起動方法は、"PRIMECLUSTER 導入運用手引書"の"4.3.3 Web-Based
Admin View の初期設定" を参照してください。
CF の状態確認と起動方法は、"PRIMECLUSTER Cluster Foundation 導入運用手引書"の"4.2 メインCFテーブル"と"4.6 CFの起動と
停止"を参照してください。

CLI: hvsetenv
各アプリケーションのAutoStartUp属性の機能は、RMS環境変数 HV_AUTOSTARTUP によって制御されます ("E.3 RMSローカル環
境変数"の説明を参照)。このRMS環境変数は、以下のようにhvsetenvコマンドを使って変更できます。

hvsetenv HV_AUTOSTARTUP [0|1]

設定値は以下のとおりです。

- 123 -
 0 次回RMS起動時にアプリケーションの自動起動を行わない

1 次回RMS起動時にAutoStartUp 属性に従いアプリケーションの自動起動を行う

値を指定しないと、コマンドはRMS環境変数 HV_AUTOSTARTUPの現在の値を通知します。

7.2.2 クラスタアプリケーションの切替え
クラスタアプリケーションの切替えが行われると、RMSは以下の処理を行います。

・ クラスタアプリケーションがクラスタ内ですでに実行されている場合は、RMSによって停止されます。
・ クラスタアプリケーションが完全に停止した後、RMSは指定されたノードでそのクラスタアプリケーションを起動します。
以下の手順に従ってOnline状態のクラスタアプリケーションを切替えます。

1. userApplicationオブジェクト上で右クリックし、メニュー項目から [切替え] を選択します。切替え可能なノードがサブメニューに表示

されます。

2. プルダウンメニューからノード名を選択して、クラスタアプリケーションをそのノードに切替えます。

図7.16 クラスタアプリケーションの切替え

RMSは処理を開始する前に、操作の確認を求めるメッセージを表示します。
[優先切替え]は、クラスタアプリケーションのPriorityList属性に設定されたノードのリストの順序に従い、クラスタアプリケーションを対象の
ノードへ切替えます。
RMSは、クラスタアプリケーションの停止に失敗した場合、クラスタアプリケーションの起動処理は行いません。これは、同じアプリケーショ
ンの2つのインスタンスに競合が発生し、データ破損が生じる恐れがあるためです。この場合には、[強制切替え]を行うことでクラスタア
プリケーションを起動できます。

注意
ユーザ業務とデータの整合性および完全性が保たれるように、標準のクラスタアプリケーション切替方式を使用することを推奨します。標準
モードでクラスタアプリケーションを切替えられない場合は、強制切替方式を使用できます。ただし、強制切替えを実行すると、安全性チェッ
クがすべて無効になり、データが破損したり整合性が失われる場合があります。
そのため、クラスタアプリケーションの強制切替え時にデータが破損するリスクを低減するため、RMS が起動していないノードを強制停止
してからクラスタアプリケーションを強制起動する場合があります。

- 124 -
 クラスタアプリケーションがビジー状態の場合、クラスタアプリケーションを切替えるためのコマンドポップアップは表示されません。代わりに、
メニューには表示のみの操作が表示され、最後のメニュー項目によって、クラスタアプリケーションがWait状態にあることが示されます。

図7.17 userApplicationがWait状態のときの切替え

CLI: hvswitch userApplication

CLI の構文は次のとおりです。

hvswitch [-f] userApplication [SysNode]

hvswitchは、userApplicationまたは gResourceの制御をRMS構成内のシステムノード間で手動切替えするためのコマンドです。切替え
るリソースのタイプがuserApplication の場合、SysNodeが指定されていないと、クラスタアプリケーションは最優先ノードに切替えられます。-f
オプションは強制切替えオプションです。

注意
hvswitch -fの実行には注意が必要です。クラスタアプリケーションまたはリソースの強制切替えを行うと、安全性チェックがすべて無効になり、
データが破損したり整合性が失われる場合があります。
そのため、クラスタアプリケーションまたはリソースの強制切替え時にデータが破損するリスクを低減するため、RMS が起動していない
ノードを強制停止してからクラスタアプリケーションまたはリソースを強制起動する場合があります。

7.2.3 クラスタアプリケーションの起動
クラスタアプリケーションがクラスタ全域ですでにOfflineの場合は、以下のようにして単一ノードで起動 (Online化) することができます。
userApplicationオブジェクト上で右クリックし、ポップアップメニューから [Online] を選択します。

- 125 -
 図7.18 クラスタアプリケーションの起動

RMSは処理を開始する前に、操作の確認を求めるメッセージを表示します。

CLI
ローカルノードでクラスタアプリケーションを起動するには、クラスタアプリケーションを他のノードに切替える場合と同様に、hvswitchコマ
ンドを使用します。構文規則については、"CLI: hvswitch userApplication"を参照してください。

7.2.4 クラスタアプリケーションの停止
Online状態のクラスタアプリケーションを停止する (Offline状態にする) には以下のようにします。
Online状態のuserApplicationオブジェクトを右クリックし、ポップアップメニューから[Offline]を選択します。

- 126 -
 図7.19 クラスタアプリケーションの停止

RMSは処理を開始する前に、操作の確認を求めるメッセージを表示します。

CLI: hvutil -f
CLIの構文は次のとおりです。

hvutil -f userApplication

これは通常のOffline要求です。userApplicationに対する「強制」Offline要求はありません。

注意
Offline状態のuserApplicationをStandby状態にするには、hvutil -s userApplicationを使用してください。

7.2.5 クラスタアプリケーションのリセット
この操作は、実際のディテクタのレポートに基づいて、対象となるクラスタアプリケーションとそのリソースツリー内の全オブジェクト (つま
りアプリケーショングラフ全体) を完全に再初期化します。そのクラスタアプリケーションについて現在進行中のRMS処理はすべて中止され、
実行中のスクリプトも終了されます。

注意
クラスタアプリケーションをリセットすると、以前の障害に関する情報やその他の履歴は失われます。これにより多くの場合アプリケーションに
不整合の状態が発生します。
この操作はシステム管理者がテスト段階で使用することを想定しています。運用環境では絶対に実行しないでください。

以下の手順に従ってOnline状態のクラスタアプリケーションをリセット (再初期化) します。

Online状態のアプリケーションオブジェクトを右クリックし、ポップアップメニューから[Reset]を選択します。

- 127 -
 図7.20 クラスタアプリケーションのリセット

RMSは処理を開始する前に、リセットのタイムアウト値の入力を求めるメッセージを表示します。

図7.21 クラスタアプリケーションのリセットタイムアウト値の選択

設定したタイムアウト時間内にアプリケーショングラフ全体を再初期化できなかった場合、RMSはエラーメッセージを出力して終了します。
デフォルト: 10秒
必要に応じてタイムアウト値を変更し、＜はい＞ボタンをクリックしてクラスタアプリケーションのリセットを開始します。

CLI: hvreset -t
CLIの構文は次のとおりです。

- 128 -
 hvreset -t timeout userApplication

hvresetは結果についての警告メッセージを表示し、処理を開始してよいかの確認を求められます。
userApplicationがOnline、Offline、またはFault処理のいずれも行っていない場合、hvresetは直ちに、行うべき処理がない旨を表すメッ
セージを表示します。この場合はコマンドの実行が成功したものとして終了コード0が返されます。

7.2.6 Faulted状態のクリア
以下の手順に従って、クラスタアプリケーションのFaulted状態をクリアします。
userApplicationオブジェクト上で右クリックし、ポップアップメニューから [Faultのクリア] を選択します。

図7.22 クラスタアプリケーションFault状態のクリア

コマンドが実行される前に、その処理を実行してよいかの確認を求めるメッセージが表示されます。

図7.23 クラスタアプリケーションFault状態のクリア - 確認のダイアログ

CLI: hvutil -c
CLIの構文は次のとおりです。

hvutil -c userApplication

注意
userApplicationがOnline状態の場合にFaultをクリアすると、RMSではFaultが発生したオブジェクトをOnline状態に戻すように試行されます。
userApplicationがOfflineまたはFaulted状態の場合にFaultをクリアすると、オブジェクトがOffline状態にされます。コマンドが実行される前
に、操作の確認を求めるメッセージが表示されます。

- 129 -
7.2.7 クラスタアプリケーションの活性化
非活性状態 (Deact状態) のクラスタアプリケーションを活性化すると、その状態はDeactからOfflineに変化します。Onlineにはなりません。
userApplicationの活性化は、RMS構成の配布とは関係ありません。両者は全く別の操作です。以下の手順に従って非活性状態 (Deact
状態) のクラスタアプリケーションを活性化します。
userApplicationオブジェクト上で右クリックし、ポップアップメニューから [活性化] を選択します。

CLI: hvutil -a
CLIの構文は次のとおりです。

hvutil -a userApplication

注意
hvutil -d userApplicationコマンドにより明示的にアプリケーションが非活性化された場合以外は、アプリケーションの活性化は必要あり
ません。

7.3 リソースの管理
このセクションでは、各リソースを起動、停止するための基本的な手順について説明します。
このセクションで説明する手順はRMS クラスタの状態を直ちに変更するため、データの処理に直接の影響を及ぼす可能性があります。
"5.1 概要"で述べたとおり、基本的な管理操作はCluster Admin GUI から行います。操作はできる限りこの方法で行ってください。ただし、
このセクションで説明する手順は、それぞれCLI でも実行することができます。

注意
userApplication 配下の一部のリソースのみが起動した状態では、userApplicationはOnline状態となります。

7.3.1 リソースの切替え
リソースの切替えが行われると、RMS は以下の処理を行います。

・ リソースを制御するクラスタアプリケーションがクラスタ内ですでに実行されている場合は、RMS によって停止されます。
・ クラスタアプリケーションが完全に停止した後、RMS は指定されたノードでそのリソースを起動します。
以下の手順に従ってOnline 状態のリソースを切り替えます。
gResource オブジェクト上で右クリックし、メニュー項目から [リソースのOnline] を選択します。

- 130 -
 図7.24 リソースの切替え

RMS は処理を開始する前に、操作の確認を求めるメッセージを表示し、指定されたリソースが依存する、すべてのリソースを起動してから、
指定されたリソースを起動します。

図7.25 リソースの切替え確認

RMS は、クラスタアプリケーションの停止に失敗した場合、リソースの起動処理を行いません。これは、同じアプリケーションの2 つのイ

ンスタンスに競合が発生し、データ破損が生じる恐れがあるためです。この場合には、[リソースの強制Online] を選択することでリソースを
起動できます。

注意
ユーザ業務とデータの整合性および完全性が保たれるように、標準のリソース切替方式を使用することを推奨します。標準モードでリソー
スを切り替えられない場合は、強制切替方式を使用できます。ただし、強制切替えを実行すると、安全性チェックがすべて無効になり、デー
タが破損したり、整合性が失われたりする場合があります。
そのため、リソースの強制切替え時にデータが破損するリスクを低減させるよう、RMS が起動していないノードを強制停止してからリソースを
強制起動する場合があります。

CLI: hvswitch resource

CLI の構文は次のとおりです。

hvswitch [-f] resource SysNode

- 131 -
 hvswitchは、userApplicationまたは gResourceの制御をRMS構成内のシステムノード間で手動切替えするためのコマンドです。切替え
るリソースのタイプがgResourceの場合、SysNodeにはコマンドを実行するSysNode名を指定する必要があります。-f オプションは強制切替
えオプションです。

注意
リソースの切替えは、そのリソースを制御するアプリケーションがOnline/Offline/Standbyの場合のみ有効です。

7.3.2 リソースの起動
リソースがOfflineまたはStandbyの場合は、以下のようにして単一ノードで起動 (Online化)することができます。
gResource オブジェクト上で右クリックし、ポップアップメニューから [リソースのOnline]を選択します。

図7.26 リソースの起動

RMS は処理を開始する前に、操作の確認を求めるメッセージを表示し、指定されたリソースが依存するすべてのリソースを起動してから、
指定されたリソースを起動します。

図7.27 リソースの起動確認

CLI
ローカルノードでリソースを起動するには、リソースを他のノードに切替える場合と同様に、hvswitch コマンドを使用します。構文規則に
ついては、"CLI: hvswitch resource"を参照してください。

注意

・ リソースの起動は、そのリソースを制御するアプリケーションがOnline/Offline/ Standbyの場合のみ有効です。

- 132 -
 ・ userApplication配下の一部のリソースのみが起動している状態で、ユーザがクラスタ管理外から手動でリソースをOnlineにするなど
により、他のリソースが予期せずにOnlineとなった場合、そのノード上で他の未起動のリソースを指定して、リソースを起動することは
できません。

7.3.3 リソースの停止
Online 状態のリソースを停止する (Offline 状態にする) には以下のようにします。
Online状態のgResourceオブジェクトを右クリックし、ポップアップメニューから[リソースのOffline]を選択します。

図7.28 リソースの停止

RMS は処理を開始する前に、操作の確認を求めるメッセージを表示し、指定されたリソースに依存するすべてのリソースを停止してから、
指定されたリソースを停止します。

図7.29 リソースの停止確認

CLI: hvutil -f
CLI の構文は次のとおりです。

hvutil -f gResource

これは通常のOffline 要求です。gResource に対する「強制」Offline 要求はありません。

注意

・ リソースの停止は、そのリソースを制御するアプリケーションがOnlineの場合のみ有効です。
・ userApplication配下の一部のリソースのみが起動している状態で、他のリソースが予期せずにOnlineとなった場合、そのノード上で
リソースを停止することはできません。

- 133 -
 ・ リソースの停止に失敗した場合、停止対象でないリソースはOnline状態のままとなり、アプリケーションはInconsistent状態となります。
この状態から復旧するには、停止に失敗した要因を取り除いてから、hvutil -f によりクラスタプリケーションを停止した後、必要に応じ
てリソースを起動してください。

7.3.4 リソースの起動停止に関する注意
各リソースの起動、停止に関して、以下の点に注意してください。

・ userApplication配下の一部のリソースのみが起動しているという情報は、そのアプリケーションが動作可能な、すべてのノード上で同期
されます。このため、一部のリソースのみが起動している状態でアプリケーションの自動切替えが発生した場合、切替え先のノードでは、
切替え元で起動していたリソースのみが起動されます。

・ userApplication配下の一部のリソースのみが起動している状態で、他のリソースが予期せずにOnlineになった場合、userApplicationは
Online状態のままとなります(Inconsistent状態になりません)。この状態で、アプリケーションの自動切替えが発生した場合、予期せずに
起動したリソースは切替え先でOnlineになりません。

・ スケーラブルコントローラで制御される userApplication 配下のリソースに対して、リソースの起動停止を行う場合、制御する

userApplication は Offline である必要があります。

注意
予期せずに起動したリソースを停止するには、必ず該当のuserApplicationを保守モードに移行してから、該当のリソースを手動で停止し
てください(保守モードに移行せずにリソースを停止した場合は、リソース異常とみなされます)。

7.3.5 リソースの故障形跡の表示
リソースで故障が発生した場合に[Cluster Admin]画面のRMSメインウィンドウにてどのリソースが故障したかを確認できます。

クラスタツリーにて故障したリソースの状態アイコンの右に、故障した形跡として故障形跡アイコン( アイコン)が表示されます。

- 134 -
図7.30 故障したリソースの確認

注意

・ 故障形跡アイコンは、過去にそのリソースに故障が発生したことを表すものであり、現在のリソース状態を表すものではありません。現在
のリソース状態を確認する場合は、リソースオブジェクトの状態を確認してください。

・ 故障形跡アイコンは、RMSに異常が通知されたリソースに表示されます。また、通常は、異常が発生したリソースに故障形跡アイコンが
表示されますが、リソースの監視タイミングによっては、実際に異常となったリソースよりもグラフツリーの上位のリソースが先に異常を検出
する場合があります。例えば、ファイルシステム資源に異常が発生した場合、通常はFsystemリソースに異常が通知されますが、リソー
スを監視するタイミングによっては、グラフツリーのFsystemリソースより上位のリソースが先に異常を検出する場合があります。これは、
ファイルシステムにアクセスする業務アプリケーションがリソースとして登録されている場合に、その業務アプリケーションが先に異常を
検出するケースが該当します。この場合は、上位のリソースにのみ、故障形跡アイコンが表示されることがあります。

・ 状態遷移中にリソース異常が通知された場合は、そのリソースには故障形跡アイコンは表示されない場合があります。

故障したリソースのStateDetails属性にFault Occurredが表示されます。

- 135 -
 図7.31 StateDetails属性のFault Occurred表示

CLI：hvdisp -a
CLIの構文は次のとおりです。

hvdisp -a

故障したリソースのStateDetails属性にFault Occurredが表示されます。
以下の手順に従って、リソースの故障形跡をクリアします。

- 136 -
 1. 故障リソース上で右クリックし、ポップアップメニューから［Fault形跡のクリア（hvutil -c）］を選択します。

図7.32 Fault形跡のクリア

2. コマンドが実行される前に、その処理を実行してよいかの確認を求めるメッセージが表示されます。＜はい＞ボタンをクリックして故
障形跡のクリアを開始します。

図7.33 故障形跡のクリア確認

CLI：hvutil -c
CLIの構文は次のとおりです。

hvutil -c gResource

リソースの故障形跡のクリアは、上述のクリア手順を実施した場合の他に、そのリソースが次にOnlineになった場合にも自動でクリアされ
ます。
リソースの故障形跡がクリアされると故障リソースの状態アイコンの右の故障形跡アイコンは消えてStateDetails属性のFault Occurred表示も
消えます。

- 137 -
7.4 保守モードの使用法
保守モードは、アプリケーションを一時的に依存オブジェクトから切り離して動作させることのできる特殊なモードです。これにより、たと
えばバックアップを行う場合など、親アプリケーションのOnline状態に影響を与えることなく、ファイルシステムをOfflineにすることができます。

7.4.1 保守モードの開始
すべてのノード上ですべてのアプリケーションを保守モードにするには、次のようにします。
RMSツリーの最上部のクラスタを右クリックし、ポップアップメニューから [保守モードの開始] を選択します。

図7.34 すべてのアプリケーションで保守モードを開始

1つのアプリケーションのみを保守モードにするには以下のようにします。
RMSツリーでアプリケーションインスタンスを右クリックし、ポップアップメニューから [保守モードの開始] を選択します。

図7.35 1つのアプリケーションのみで保守モードを開始

いずれの場合でも、操作の確認を求めるメッセージが出力されます。

- 138 -
図7.36 すべてのアプリケーションについての保守モードの確認

図7.37 単一のアプリケーションについての保守モードの確認

注意
保守モードはクラスタ全体に適用されます。あるアプリケーションが1つのノードで保守モードに入ると、そのアプリケーションが実行可能な
すべてのノードで保守モードが開始されます。
クラスタアプリケーションは以下の状態の場合に開始できます。

・ Online状態
・ Standby状態
・ Offline状態
・ Warning状態
・ Inconsistent状態(Inconsistentになる直前のクラスタアプリケーションの状態が、Faulted状態の場合を除く)
RMSグラフの動的再構成の要求がある場合は、保守モードは開始できません。

以下は、1つのアプリケーションが保守モードに入った後のCluster Admin画面を示しています。

- 139 -
図7.38 保守モードに入ったクラスタの例

ここで、アプリケーションの状態アイコンの右半分は、目標状態 (保守モード開始直前の状態) を示すようになっています。目標状態は、ア

プリケーションのStateDetails属性によっても分かります。この属性は、右パネルの属性テーブルで最初の項目として表示されます。

7.4.2 保守モードの動作に関する注意
アプリケーションが保守モードに入ると、同じグラフを使用しているすべてのアプリケーションに影響を及ぼします。たとえば、2つのアプ
リケーションがコントローラでリンクされている場合に、片方のアプリケーションが保守モードに入ると他方のアプリケーションも保守モードに入
ります。この場合、どちらが親アプリケーションでどちらが子アプリケーションかは関係ありません。
逆に、2つのアプリケーションが同じグラフを使用していない場合、つまり、両者が1つ以上のコントローラでリンクされていない場合は、片方
のアプリケーションが保守モードに入っても、他方はRMSの通常の制御下で稼動を続けます。
たとえば、先の例のapp1とapp2を見ると、両者は独立しています。このため、app1は保守モードの状態にありますが、app2は通常の動作を
継続しており、下の図に示すように、あるノードから他のノードに切替えることができます。

図7.39 独立したアプリケーションの通常の動作

7.4.2.1 保守モードにおけるクラスタ全体の制限
保守モードが開始されても、通常のRMSの制御下で稼動を続けるアプリケーションも存在しますが、保守モードによる制限はクラスタ全体の
動作に及びます。特に以下の点に注意してください。

- 140 -
 ・ アプリケーションやリソースを起動/停止する場合には、まず保守モードを終了する必要があります。
・ RMS やシステムを停止するには、クラスタのすべてのノードで保守モードを終了する必要があります。

7.4.3 保守モードの終了
保守モードを終了するには以下のようにします。

1. アプリケーションのアイコンの右隣に が表示されていないことを確認します。表示されている場合、userApplication配下のすべ
てのリソースを保守モード開始直前の状態に戻す必要があります。
保守モード開始直前の状態はアプリケーションのアイコンの色により判断できます。アイコンの色の詳細について
は、"PRIMECLUSTER 導入運用手引書" の "7.1.3 RMSメインウィンドウ"を参照してください。

2. クラスタまたはアプリケーションを右クリックし、ポップアップメニューから [保守モードの終了] を選択します。

図7.40 すべてのアプリケーションで保守モードを通常終了

図7.41 単一のアプリケーションで保守モードを通常終了

いずれの場合でも、操作の確認を求めるメッセージが出力されます。

注意
クラスタ全体が保守モードに入っている場合でも、1つのアプリケーションのみで保守モードを終了することができます。
保守モードを終了する場合、以下の条件を満たす必要があります。

・ クラスタアプリケーションが Online、Offline、 Standby、Warning のいずれかの状態のときに保守モードを開始した場合、その保守モー

ドを終了するには、クラスタアプリケーションおよび各リソースの状態を、保守モードを開始する前の状態と同じ状態にする必要があ
ります。状態が異なる場合、保守モードを終了できません。

・ クラスタアプリケーションが Inconsistent 状態のときに保守モードを開始した場合、Inconsistent 状態となった原因を取り除いてください。

原因を取り除くまで保守モードを終了できません。

- 141 -
たとえば上記の例で、クラスタアプリケーションapp1にファイルシステムリソース Res1 があり、app1で保守モードを開始する時、Res1が
fuji2RMSでオンライン状態であったとします。この場合、app1の保守モードを終了するには、fuji2RMSで Res1がオンライン状態である必要
があります。
保守モードを開始した場合と異なる状態で、[保守モードの終了]で強制的に保守モードを終了すると、Inconsistent 状態となるため、[保守
モードの終了]の使用は推奨しません。

上記のクラスタのポップアップメニューとアプリケーションのポップアップメニューのいずれにも [Force Exit Maintenance Mode] メニュー項目

が含まれています。このコマンドを選択すると、適正な状態にないリソースが存在する場合でも、RMSは保守モードを強制的に終了します。
以下は、1つのアプリケーションを強制停止しようとした場合の確認メッセージです。すべてのアプリケーションを強制停止する場合も同様
のメッセージが表示されます。

図7.42 すべてのアプリケーションについての保守モード強制終了の確認

保守モードを開始する前のuserApplication の状態がOnline状態またはStandby状態の場合、保守モードの終了時にOnline処理または
Standby処理が実行されます。
これらの処理では、userApplication 配下のリソースが、保守モードを開始する前と同じ状態であれば、Onlineスクリプトは実行されず、リ
ソースの状態が変わることはありません。
ただし、例外として NULLDETECTOR 属性が設定された Cmdline リソースに対し Online処理が実行された場合は、実際のリソースの状態
にかかわらず、必ず Online スクリプトが実行されます。

7.4.4 保守モードのコマンドラインインタフェース
保守モードはhvutil コマンドで以下のように制御できます。

hvutil -M { on | off | forceoff }

hvutil -m { on | off | forceoff } userApplication

オプションは以下のとおりです。

-M 保守モードの操作をすべてのノードのすべてのアプリケーションに適用する。

-m 保守モードの操作をすべてのノードの指定したアプリケーションに適用する。

機能は以下のとおりです。

on 保守モードを開始する。

off すべての資源が適切な状態にあれば保守モードを停止する。

forceoff すべての資源が適切な状態になくても保守モードを強制停止する。

hvutilコマンドの保守モードは複数同時実行できます。したがって、複数のコマンドを実行した場合、すべてのコマンドが最終状態に到達
するか、エラーが発生するまでは復帰しません。不適切な状態にある資源が存在すると、「-m off」はエラーを返します。このような場合には、
問題のある資源を列挙したエラーメッセージが表示されます。

- 142 -
 注意
保守モードを停止する場合、対象となる userApplication 配下のすべてのリソースが保守モード開始直前の状態になっていることを確認し
てください。
hvdispコマンドの表示結果において、対象となるuserApplication のStateDetails列の表示が以下のいずれかの場合は、保守モード開始
直前の状態になっていないため、保守モード開始直前の状態に戻す必要があります。

・ "Online !!"が表示されている(開始直前の状態はOnline)。
・ "Standby !!"が表示されている(開始直前の状態はStandby)。
・ "Offline intended"が表示されており、userApplication 配下にOffline状態でもStandby状態でもないリソースが存在する(開始直前の
状態はOffline)。

- 143 -
付録A 事前準備
クラスタシステムにRMSを導入するためには事前準備が必要です。これらの準備作業の一部では、構成定義で使用されたノード、ファ
イルシステム、ネットワークインタフェースがRMSから識別できるように、システムファイルを変更する必要が生じます。これらの変更はRMS
のインストール前に行っておく必要があります。
ユーザ環境に変更があった場合は、RMS構成定義ファイルの作成または変更が必要になることがあります。ユーザ環境の変更内容に
よっては、事前にシステムファイルの検討や更新を行っておく必要があります。変更作業の例としては次のようなものがあります。

・ IPアドレスの変更
・ 冗長クラスタインタコネクトの追加
・ ノードの追加、削除、ノード名の変更
・ 2つ以上のクラスタシステムを1つに併合
・ ファイルシステムやSANの追加、削除
以下にノード、ファイルシステム、およびネットワークに関する事前準備の方法について説明します。RMS初期導入時から、これらの設定値
に変更があった場合は、以下の記載を参照して必要な構成設定の変更を行ってください。
修正の内容は主に、OS標準のシステムファイルへのRMS固有エントリの追加です。この場合、以前から存在しているエントリは影響を受
けません。 地域固有のアプリケーションが使用する資源にも同様のカスタマイズが必要な場合があります。

A.1 ネットワークデータベースファイル

A.1.1 /etc/hosts
クラスタの一部としてすべてのホストシステムのIPアドレスとRMS名を指定する必要があります。
RMSはクラスタ内のノードを管理するために、ノード名を保持しています。 クラスタを構成する場合、標準のノード名ではなく、RMSノード名を
使用します。 これらの名前は、DNSにアクセスできない場合の問題を避けるため、システムごとに/etc/hosts で指定する必要があります。
Cluster Adminを使用してRMSのCIPを設定した場合、/etc/hostsには、以下に説明する正しいRMSノード名がすでに設定されています。
デフォルトでは、以下の表のRMS命名規則に従います。

表A.1 /etc/hostsのRMS命名規則
エントリのタイプ RMS名のパターン 例
プライマリノード名 <hostname>RMS fuji2RMS
fuji3RMS

注意
RMSが使用するプライマリノード名は、そのマシンの RELIANT_HOSTNAMEに一致している必要があります。RELIANT_HOSTNAME
は、hvenv.local ファイルに記載されています。

例
以下の/etc/hostsのエントリは、ノードshasta1、shasta2で構成されたクラスタの設定です。インタフェース名は以下のように割当てられています。

・ パブリックネットワーク172.25.220上の標準ホスト名
・ プライベートネットワーク192.168.10上のRMSノード名

172.25.220.83 shasta1
172.25.220.84 shasta2
# node names for RMS

- 144 -
 192.168.10.83 shasta1RMS
192.168.10.84 shasta2RMS

A.1.1.1 /etc/hosts内のネットワークインタフェース名
Ip Addressサブアプリケーションとの切替えを行うためのネットワークインタフェースを構成設定するには、まず、インタフェースが設定可能
なすべてのノードで、/etc/hostsファイルにインタフェース名を入力する必要があります。各エントリは、インタフェースのIPアドレスと名前を
通常の形式で入力します。特別なコメントは必要ありません。

例
記述例を以下に示します。

・ IPv4 アドレス 172.25.222.223 を持つインタフェースshastavip を切り替える可能性がある場合

172.25.222.223 shastavip

・ IPv6 アドレス fd00:1::219:99ff:fe18:1b4e を持つインタフェース shastavip6 を切り替える可能性がある場合

fd00:1::219:99ff:fe18:1b4e shastavip6

注意

・ Ip Addressサブアプリケーションを構成する場合、指定が必要なものは/etc/hostsに記述されたインタフェース名であり、IPアドレスで
はありません。

・ IPv6 アドレスのリンクローカルアドレスは使用できません。
・ /etc/hosts ファイルにインタフェース名を定義する場合、IPv4 アドレスと IPv6 アドレスに同一のインタフェース名を割り当てないでください。

A.1.2 /.rhosts (Solaris)、/root/.rhosts (Linux)

信頼関係の設定されたリモートノードからのログインを制御するエントリが保存されます。
RMS Wizard Toolsは、各ノードに対するルートでの自動ログインを必要とします。このため、各ノードの.rhostsファイルを正しく変更する必要
があります。機能の説明やフォーマットについての詳細は、rhostsのマニュアルページを参照してください。

例
クラスタにノードshasta1、shasta2が存在する場合、各マシンの.rhostsファイルには以下の行が記載されている必要があります。

fuji2 root
fuji3 root

注意
cluster Foundation (CF) は、.rhostsと同等の機能 (CFシェル、CFCP) を提供しているため、Cluster Foundationのcfsh、cfcpの設定をして
いれば、.rhostsを設定しなくても、RMSの構成、管理、運用の作業すべてが可能です。

- 145 -
A.2 構成資源の定義

A.2.1 /opt/SMAW/SMAWRrms/etc/hvipalias
RMSの構成で資源として使用する全ネットワークインタフェースのエントリが指定されています。通常はこのエントリによって、論理インタ
フェース名すなわちIPエイリアスが、指定されたノードの物理インタフェースと関連付けられています。IPエイリアスは、他ノードへの切替え
があった場合や、実際の物理的なインタフェースの特性がノードごとに異なっていても、常に同じIPアドレスを表します。

注意
各IPエイリアスとそのIPアドレスは、/etc/hostsファイルに入力されている必要があります。IPアドレスはhvipaliasファイルには記載されてい
ません。

hvipaliasの各エントリには、次の必須フィールドがあります。
<Uname> <IfName> <IfDevice> <Netmask/Prefix>
フィールドは以下のように定義されます。

・ Uname － 論理インタフェースを割当てるノード名。これは通常uname -nコマンドで返される値です。

この値には、cftool -qlコマンドで返されるCFノード名を使用することもできます。同じuname -n設定で構成された2つのマシンが、CF構
成時に異なる名前を割当てられていた場合には、この値を使って両者を区別することができます。

・ IfName － 論理インタフェース名 (IPエイリアス)。この名前は、関連付けられたIPアドレスとともに、そのノードの/etc/hostsファイルに記述

されている必要があります。関連付けられたIPアドレスはすべてのノードで同じであることが必要です。

・ IfDevice － 指定されたノードへの切替えが発生した場合に、論理インタフェースに関連付けられる物理デバイス名。
・ Netmask/Prefix － インタフェース名に関連付けられた IP アドレスとともに使用する Netmask (IPv4の場合) または Prefix 長 (IPv6の場
合)。
Netmask の場合、標準の 16 進数 8 桁で指定します。Prefix 長の場合、10 進数 128 までの正数値で指定します。

注意
ネットワークの競合を防ぐため、IpAddressで監視されるネットワークのホスト名またはアドレスを有効にできるのは、クラスタ内で一度に1つ
のノードのみです。

構成が活性化されると、ローカルのhvipaliasファイルが構成内の全ノードにコピーされます。リモートノードに同じ名前やパスのファイル
があった場合には、新しい内容で上書きされます。このため、ファイルには、インタフェースとその切替え先ノード組み合わせをすべて記述
した行を、必ず含める必要があります。
たとえば、dbhost というインタフェースが2つのノード間で切替え可能であった場合、各ノードのhvipaliasには、ローカルとリモートの2つ
のインタフェースを記述した行が含まれている必要があります。

・ Linux

#Uname IfName IfDevice Netmask

shasta1 dbhost eth1 0xffffff00
shasta2 dbhost eth1 0xffffff00

・ Solaris

#Uname IfName IfDevice Netmask

fuji2 dbhost hme0 0xffffff00
fuji3 dbhost hme0 0xffffff00

- 146 -
A.2.2 /opt/SMAW/SMAWRrms/etc/hvconsoles
Faultメッセージの処理方法をカスタマイズできます。通常は、リモートコンソールや、ポケットベルなどの特殊なデバイスに出力する場合の
処理方法のカスタマイズに使用します。RMSやOSのログファイルに出力される標準メッセージには影響しません。
それぞれのエントリは、あるRMS資源オブジェクトでFaultが発生した場合に、どのプログラムを実行するかを指定しています。ファイルが存在
しない場合には、カスタマイズされたFaultの情報が表示されません。フォーマットの詳細については、hvconsolesのオンラインマニュア
ルまたはhvconsolesファイルのコメント部分を参照してください。

A.3 ファイルシステム (Linux)

RMSでLinuxファイルシステムを管理する場合は、/etc/fstab.pclに以下のセクションで説明するエントリを作成する必要があります。この
ファイルには以下の特徴があります。

・ 先頭の空白、および空白行は無視されます。
・ #RMS#または#RMS:<appname>#で始まる行はRMSのファイルシステムの指定です。指定全体が同じ行に含まれている必要があ
ります。複数行に渡る指定は許されません。

・ 上記以外のポンド記号 (#) で始まる行、またはアスタリスク (*) で始まる行はコメントとして扱われます。

・ 上記以外の行は現在のところ無視されます。ただし、RMSの今後のバージョンでは処理される可能性はあります。

A.3.1 /etc/fstab.pcl
このファイルは、クラスタアプリケーションの構成でリソースとして使用するすべてのローカルファイルシステムおよびリモートファイルシス
テムのエントリを含んでいます。RMSは、実行中の構成の要求にしたがってファイルシステムのOnline化、Offline化を行うため、これらの
マウントとアンマウントを行います。
各ファイルシステムをRMSに管理させるには、/etc/fstab.pclに標準fstabフィールドを含む行を作成し、先頭に#RMS#を挿入します。詳細
については、fstabのマニュアルページを参照してください。
/etc/fstab.pclの作成に関しては次の制限があります。

・ 標準の/etc/fstabエントリとRMSの/etc/fstab.pclエントリの両方に同じファイルシステムを指定しないでください。標準のエントリはシステム
起動時にファイルシステムをマウントします。このため、RMSが起動し、同じファイルシステムをマウントしようとした時点で競合が生じます。

・ リモートファイルシステムを、<server_name>:<server_path>の形式で指定する場合、<server_name>には/etc/hostsファイルに記載さ
れたホスト名を指定することはできません。また、IPアドレスを指定することもできません。DNSの名前解決を使用することもできません。

#RMS#/dev/sdb2 /fs2 ext2 defaults 1 2

#RMS#/dev/sda1 /mnt/data1 auto noauto,user 0 0
#RMS#/dev/sda2 /mnt/data2 auto noauto,user 0 0

A.3.1.1 アプリケーション用のファイルシステムの構成
#RMS:<appname>#の形式でRMSのコメントを記述すると、ファイルシステムのエントリは指定されたアプリケーションにのみ適用されます。
RMSから見た場合、あるアプリケーションに割当てられたファイルシステムは他のアプリケーションに割当てられたファイルシステムからは
独立しています。1つのファイルシステムを複数のアプリケーションに割当てることは可能です。ただしこの場合、複数のアプリケーションが
同時にOnlineになることはできません。

#RMS:app1#/dev/sdb2 /data3 auto noauto,user 0 0

#RMS:app2#/dev/sdb6 /data4 auto noauto,user 0 0

- 147 -
A.3.1.2 クラスタ全体に渡る構成の問題
1つのノード上で、リモートファイルシステムや共有ファイルのための制御エントリを/etc/fstab.pclに作成した場合は、クラスタ内でそのファ
イルシステムをマウントしないノードがあっても、通常はそのエントリをクラスタ内の全ノードに複製する必要があります。これにより、構成が
クラスタ内のどこでも常に同じ動作をすることが保証されます。
ローカルのファイルシステムやマウントポイントを指定するエントリについても同じ手順を実行します。すべてのノードが同じアーキテクチャを
採用している場合は、/etc/fstab.pcl制御ファイル全体をそのままコピーしてください。しかし、ノードによってローカルの物理ディスクデバ
イスが異なる場合は、同じマウントポイントについて個別にエントリを調整する必要があります。たとえば、node1とnode2のエントリ/mnt1と
はそれぞれ次のようになります。
node1:

#RMS#/dev/sda3 /mnt1 ...

node2:

#RMS#/dev/sdb5 /mnt1 ...

いずれの場合でも、/etc/fstab.pclに記載された各マウントポイントについて、クラスタ内の全ノードで必ずディレクトリを作成してください。

A.4 ファイルシステム (Solaris)

・ /etc/vfstab.pcl
RMS構成でリソースとして使用するすべてのローカルファイルシステムのエントリが格納されています。 つまり、ローカルにマウント
すべきファイルシステムを記載するのはこのファイルです。
RMSが管理する各ファイルシステムについては、標準のvfstabフィールドを含む行を作成し、先頭に#RMS#を挿入します。RMSが読取
るためのエントリはコメントとして表示され、PRIMECLUSTERコンポーネント以外のプロセスからは無視されます。詳細については、
vfstabのマニュアルページを参照してください。

#RMS#/dev/dsk/c0t0d0s0 /dev/rdk/c0t0d0s0 /testfs1 ufs 1 yes -

・ /etc/dfs/dfstab.pcl
高可用性構成で使用するすべてのNFSのエントリが格納されています。 つまり、このファイルには、他のノードからマウントできるファ
イルシステムを記載します。
RMSが管理する各ファイルシステムについては、標準のdfstabフィールドを含む行を作成し、先頭に#RMS#を挿入します。RMSが読取
るためのエントリはコメントとして表示され、PRIMECLUSTERコンポーネント以外のプロセスからは無視されます。 このため、システム
起動時にNFSデーモンを確実に起動するためには、このファイルにコメント以外の (RMS用でない) エントリが1つ以上存在する必要
があります。
RMS以外のエントリは、ローカルファイルシステム用に構成され、そのノードでのみ共用される疑似エントリでもかまいません。 リモー
トノードとの実際の共有を行わなくてもNFSデーモンを起動させるためにこのような条件を必要とします。詳細については、dfstabの
マニュアルページを参照してください。

例
以下には、RMS以外のエントリおよびRMSエントリの両方が示されています。

share -F nfs -o ro=localhost /var/opt/example

#RMS# share -F nfs -o rw, root=
fuji2RMS:fuji2:045nfs045dia1:045msg:fuji2RMS: /sapmnt/045

- 148 -
A.4.1 NFS ロックフェイルオーバ
NFSロックフェイルオーバ機能はローカルのファイルシステムで使用できます。あるファイルシステムについてNFSロックフェイルオーバを
構成設定した後に、そのファイルシステムで障害が発生すると、ファイルシステムとともにNFSロックもフェイルオーバされます。
この機能を使用するには、以下の事前準備が必要です。

・ クラスタ内のすべてのノードからアクセスできる共用ディスクを用意する必要があります。
・ NFS ロックフェイルオーバを動作させるには専用のディレクトリを用意する必要があります。 既存のディレクトリを指定しないでください。
このディレクトリはNFS ロックフェイルオーバにのみ使用されます。 このため、既存のディレクトリを指定すると、以後そのディレクトリは他
のアプリケーションで使用できなくなります。

・ NFSロックフェイルオーバを使用するアプリケーションそれぞれに1つIPアドレスを割当てます。ローカルのファイルシステムを構成する時
に、このIPアドレスをNFSロックフェイルオーバに指定します。このアドレスをIp Addressサブアプリケーションにも割り当て、ファイル
システムを含むアプリケーションとともに切替えられるようにします。

注意
NFS ロックフェイルオーバに選択できるファイルシステムは、userApplication ごとに1 つとしてください。

A.5 NFSサーバ
RMSなどの高可用性環境では、サーバノードがサービスを停止した場合には、エクスポートされたファイルシステムが透過的にフェイル
オーバされることが必要です。これによって、フェイルオーバの前にファイルシステムをマウントしたクライアントで、フェイルオーバ後の
アクセス障害が発生することを防止することができます。NFSファイルシステムにおいてこれを実現するには、特別な準備が必要です。
クライアントがリモートのNFSファイルシステムをマウントすると、その後のファイルシステム操作で使用するために、内部のファイルハンドルを
作成します。NFSのアーキテクチャに従い、クライアントのファイルハンドルには、そのファイルシステムにおけるサーバのメジャーデバイス
番号とマイナーデバイス番号が記録されています。RMS環境では、この設計が原因で問題が発生する可能性があります。システムが、あ
るサーバでOfflineになり、別のサーバでOnlineになった場合、そのサーバが最初のサーバとは異なるメジャーデバイス番号とマイナー
デバイス番号を割当てた場合、ファイルハンドルは無効になります。この状態を「ステイルファイルハンドル」と言います。この問題を回避す
るには、あるファイルシステムを宣言するすべてのNFSサーバで、そのファイルシステムに同じメジャーデバイス番号とマイナーデバイス番号
を割当てます。
上記の説明はファイルシステム一般を対象としたものですが、高可用性環境においては、ファイルシステムの実体はそのファイルシステ
ムをエクスポートする可能性があるすべてのノードからアクセスできる共有ディスクボリュームです。共有ディスクボリュームに同じメジャー
デバイス番号とマイナーデバイス番号を割当てるには、ハードウェア構成やソフトウェア構成の変更を必要とする場合があります。共有ディ
スクボリュームがボリューム管理ソフトウェアの最上位に構築されている場合、ボリュームマネージャがインストールされた時点で、追加の処理
が必要となることがあります。
このセクションでは、RMS環境でのNFSサーバとしてボリュームマネージャを使用するための準備のヒントを説明します。

A.6 ログファイル

A.6.1 /var/log/messages (Linux) または /var/adm/messages (Solaris)

デフォルト設定では、RMS が出力するすべてのメッセージはシステムログmessages、およびRMS switchlog ファイルの両方に記録されます。
システムログファイルにRMS メッセージを記録しないようにするには、hvenv.local ファイルにexport HV_SYSLOG_USE=0 を設定します。
デフォルトは1 です。

A.7 他のシステムサービスおよびデータベース
RMS を構成設定するには、以下のシステムサービスまたはデータベースを構成設定する必要があります。詳細については、当社技術員
(SE) にお問い合わせください。

・ PRIMECLUSTER Cluster Foundation (CF) - CIP が設定されていることが必須です。

・ /etc/nsswitch.conf システムサービス参照順位データベース

- 149 -
付録B 状態

B.1 基本状態
以下の表は、ディテクタがBM (ベースモニタ) に通知する状態の一覧です。

表B.1 RMSオブジェクトのディテクタが通知する状態
状態 説明
Faulted 監視しているオブジェクトが故障している状態。子のいずれかにおいて、またはスクリプトの実行中に、資
源のエラーが発生した可能性があります。
Offline 監視しているオブジェクトが停止している状態。スクリプトにより、資源の非活性化が正しく行われた場合
です。
Online 監視しているオブジェクトが起動している状態。必要なすべての子がOnlineで、かつ、スクリプトの実行中
にエラーが検出されなかった場合です。
Standby 監視しているオブジェクトの起動準備が完了している状態。

以下の表は、Cluster Admin GUIまたはhvdispコマンドで表示される資源の状態の一覧です。

表B.2 RMSオブジェクトのその他の状態
状態 説明
Deact 監視しているオブジェクトが保守などの目的で非活性の状態。
Inconsistent 監視しているオブジェクトに一貫性がない状態 (userApplicationのみ)。監視しているオブジェクトが
OfflineまたはFaultedだが、図表中の1つ以上のリソースオブジェクトがOnlineまたはFaultedの状態。
OfflineFault 監視しているオブジェクトの故障が回復していない状態。
Unknown オブジェクトに対する監視や制御が行われていない状態。オブジェクトに対する監視や制御が行われ
ていない状態。
Wait 監視しているオブジェクトが状態遷移中。
Warning 監視しているオブジェクトは起動しているが一部故障している状態。ただしこの状態は選択された資源
についてのみ表示されます。
Maintenance システム管理者の手動操作によって移行する一時的な保守用の状態。アプリケーションの状態は依存
オブジェクトと切り離された状態にあります。これにより、たとえばバックアップを行う場合など、親アプリ
ケーションの状態に影響を与えることなく、ファイルシステムをOfflineにすることができます。
保守モードのアプリケーションには、目標状態のマークが付けられます。目標状態とは、保守モード開
始直前の状態です。保守モードの目標状態は、Maintenance-Online、Maintenance-Offline、および
Maintenance-Standbyです。

OfflineおよびFaultedの意味は、資源によって異なる場合があります。たとえば、マウントポイントの資源の状態は、Online (マウントされ
ている) または Offline (マウントされていない) のいずれかです。この場合、ディテクタからFaulted状態が通知されることはありません。他方、
物理ディスクのディテクタからは、Online (正常動作) またはFaulted (入力または出力のエラー) が通知され、Offlineが通知されることは
ありません。

B.2 状態の詳細
上記の基本状態の他に、RMSは以下の場所に状態の詳細を報告する場合があります。

・ Cluster Admin GUIでは、オブジェクトのプロパティ画面で、リストの一番上に[State Details]項目が表示されます。ほとんどの属性は

RMS Wizard Toolsによる構成設定処理時で設定されますが、この通知フィールドはRMSの実行時に動的に設定されます。

・ hvdispユーティリティの出力では、StateDetails列が各行の最後に表示されます。
ほとんどの場合、[State Details]フィールドは空白です。RMSがこの追加情報を表示するのは、通常、アプリケーションが保守モードにある
場合か、オブジェクトが遷移、不整合、または待機の状態にある場合です。以下の表は、RMSオブジェクトのStateDetails値の一覧です。

- 150 -
表B.3 RMSオブジェクトのStateDetails値
状態 説明
Failed Over Offline処理が成功し切替えが開始された状態。
Faulted Faultedの通知を受信した。
Fault Occurred 過去にそのリソースに故障が発生したことを表す。
故障形跡がクリアされるまで表示し続ける。
Inconsistent on remote userApplicationが複数のノードでOnlineであるが、ローカルノード上ではOnlineでない状態。
Initial Fault RMSが起動された時点でuserApplicationがすでにFaultedである状態。
Joined クラスタに参入済みであるためSysNodeがOfflineである状態。
Killed killが成功したためSysNodeがFaultedの状態にある。
Not Joined クラスタに未参入なためSysNodeがOfflineの状態にある。
Offline Offlineの通知を受信した。
Offline Failed Offline処理が失敗した。
Offline Success Offline処理が成功した。
Offline intended 目標状態はOffline。
Online Onlineの通知を受信した。またはuserApplicationが複数のノードでOnlineである状態。
Online !! 目標状態はOnlineだが、userApplication配下の一部のリソースがOnlineでない。
Online intended 目標状態はOnline。
Partial userApplication配下の一部のリソースのみが起動されている状態
PreCheckScriptFailed PreCheckScriptが失敗した。
Preserved PreserveStateが設定され、Offline処理が開始されていない状態。
Shutdown 停止中であるため、SysNodeがFaultedの状態にある。
Standby Standbyの通知を受信した。
Standby !! 目標状態はStandbyだが、userApplication配下の一部のリソースがStandbyでない。
Standby intended 目標状態はStandby。
Remote Faulted 制御アプリケーションが少なくとも1つのノードでFaultedである状態。
Remote Offline 制御アプリケーションがすべてのノードでStandbyではない状態。

たとえば、あるノード上でアプリケーションがOnline状態から保守モードに切り替わった場合、保守モードが終了すると通常は以前のOnline
状態に復帰します。RMSはこのことを、そのノードの状態詳細フィールドにOnline intendedと表示することによって表します。アプリケー
ションがOfflineであったノードでは、RMSは状態詳細フィールドにOffline intendedを表示します。

- 151 -
付録C オブジェクトタイプ
この章ではRMSによって提供され、RMS Wizard Toolsによって構成されるすべてのオブジェクトタイプをアルファベット順に説明します。

表C.1 オブジェクトタイプ
タイプ 必須属性 説明
andOp HostName (userApplicationオブジェクトの 論理AND演算子で子と関連付けられるオブジェクト。 オ
直接の子に対する) ブジェクトタイプは、子がOnlineの場合Online、子が
Offlineの場合Offlineになります。
controller Resource属性 1つ以上のuserApplicationオブジェクトを制御するオブ
ジェクト。
ENV なし クラスタ (グローバル) 環境変数が入っているオブジェク
ト
ENVL なし ノード固有の (ローカル) 環境変数が入っているオブジェ
クト
gResource ・ rKind カスタム (汎用) オブジェクト。通常は、ファイルシステム、
ネットワークインタフェース、またはシステムプロセスなど
・ rName
のシステムリソースを示します。
orOp なし 論理OR演算子で子と関連付けられるオブジェクト。オブ
ジェクトタイプは、1つ以上の子がOnlineの場合はOnline
になります。
SysNode なし クラスタ内のノードを表します。最低1つ存在する必要が
あります。
userApplicationオブジェクトのみが子として認められます。
userApplication なし 監視対象のアプリケーションを表します。最低1つ存在す
る必要があります。親として最低1つのSysNodeオブジェ
クトが必要です。親SysNodeにはそれぞれ、そのSysNode
の名前をHostName属性に持つ子andOpが1つ必要です。

- 152 -
付録D 属性
RMSの属性には、ユーザがウィザードGUIを使用して設定できる属性と、ウィザードがプログラム内で設定する属性の2つがあります。以下
のセクションでは、すべての属性の設定値について説明します。初期値は各リソースにより異なります。

D.1 ユーザ設定属性
このセクションに記載された属性は、ユーザがウィザードGUIまたはhvwコマンドを使用して変更することができます。

・ AutoRecover
設定値 : 0、1
リソースオブジェクトに対して有効な属性。1に設定すると、Online状態のオブジェクトで障害が発生した場合に、そのオブジェクトに対
してOnlineスクリプトを実行します。オブジェクトがOnline状態に戻ることができる場合は、障害が復旧されます。
Controllerオブジェクトはこの属性を0に設定する必要があります。 RMSは、子アプリケーションの切替えを自動的に行います。

・ AutoStartUp
設定値 : yes、no
userApplicationオブジェクトに対して有効な属性。yesに設定すると、RMS起動時、アプリケーションが自動的にOnlineになります。
RMS環境変数 HV_AUTOSTARTUPを設定して、すべてのuserApplicationオブジェクトのAutoStartUp属性をオーバーライドできま
す。 HV_AUTOSTARTUPについては、"E.3 RMSローカル環境変数" を参照してください。

・ AutoSwitchOver
設定値 : 次のうちの1つ以上を含む文字列。No、HostFailure、ResourceFailure、ShutDown
userApplicationオブジェクトで障害が発生した場合に、自動的に切替えられるようにします。[|] を使用して、値を組み合わせること
ができます。Noを指定すると自動切替えは停止します。Noは他の値と組み合わせることができません。
下位互換性を確保するため、0および1を使用することができます。0はNoとして、1はHostFailure | ResourceFailure | ShutDownとして扱
われます。

・ ClusterExclusive
設定値 : 0、1
リソースオブジェクトに対して有効な属性。1に設定すると、クラスタ内で一度に1つのノード上だけでリソースがOnlineになります。0に
設定すると、一度に複数のノード上でリソースがOnlineになることができます。ここで言う Online とは、オンライン処理のすべてのフェー
ズを表します。たとえば、リソースがあるノード上でOnline状態にあり、同時にPreOnlineScriptが他のノードで実行中である場合、こ
れらのリソースオブジェクトは両方とも、オンラインであると見なされます。
この属性をユーザが変更できるのは、cmdlineサブアプリケーションについてのみです。他のサブアプリケーションに関しては、構成設定
ツールが制御します。

・ FaultScript
設定値 : 有効なスクリプト (文字)
すべてのオブジェクトタイプに対して有効な属性。関連するオブジェクトがFaulted状態になったときに実行するスクリプトを指定します。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ Fault処理では、本スクリプトの終了を待ち合わせます。
－ スクリプトの終了コードとして0 以外の値が戻ると、スクリプトの失敗を示すメッセージがswitchlog ファイルに記録されますが、Fault
処理は継続されます。

Fault処理の詳細については、"2.1.5 Fault処理"を参照してください。

・ HaltFlag (Halt)
設定値 : no(0)、yes(1)
userApplicationオブジェクトに対して有効な属性。 二重障害の発生時にローカルノードの強制停止を制御します。 二重障害とは、ア
プリケーションの初期障害処理の実行中に2つめの障害が発生した場合です。

- 153 -
 HaltFlagがyesに設定され、他のノードでアプリケーションの実行が可能な場合、二重障害が発生すると以下の処理が実行されます。

1. 最初に、ローカルノードのRMSが直ちに終了します。
2. 次に、別のノードのRMSがシャットダウン機構を呼び出してローカルノードを強制停止します。
3. 最後に、ローカルノードでOnlineだったすべてのアプリケーションと、AutoSwitchOverパラメタでHostFailureを設定したすべて
のアプリケーションが、使用できるノードに切替えられます。

注意
あるアプリケーションがHaltFlag属性のすべての条件を満たしている場合でも （AutoSwitchOverの設定、使用可能なノードの追加）、同
じノード上で実行されている別のアプリケーションの状態によりHaltFlagの動作が妨げられる場合があります。 例えば、別のアプリケー
ションに使用可能な別のノードがない場合や、AutoSwitchOverの設定が正しく行われていない場合などです。 どちらの場合でも、RMS
はローカルノードでの動作を継続します。 これを防ぐためには、別のアプリケーションに追加のノードを割当て、優先順位リストを調整
して、HaltFlag属性を設定したアプリケーションとのノードの競合を最小限に抑えるようにします。

・ LieOffline
設定値 : 0、1
すべてのリソースオブジェクトに対して有効な属性。1に設定すると、Offline処理中にリソースをOnlineに保つことができます。

・ MonitorOnly
設定値 : 0、1
リソースオブジェクトに対して有効な属性。1 に設定すると、そのリソースが Faulted になった場合でもuserApplication は Faulted にならず、
切替えが発生しません。
また、手動切替えなどに伴うOffline処理中に、そのリソースが Faulted になった場合、Offline処理は継続されますが、切替えは中断
されます。

・ OfflineDoneScript
設定値 : 有効なスクリプト (文字)
userApplicationオブジェクトに対して有効な属性。userApplicationのOffline処理が完了した後で実行するスクリプトを指定します。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ Offline処理では、本スクリプトの終了を待ち合わせません。
－ スクリプトの終了コードとして0 以外の値が戻ると、スクリプトの失敗を示すメッセージがswitchlog ファイルに記録されますが、Offline
処理は継続されます。

Offline処理の詳細については、"2.1.4 Offline処理"を参照してください。

・ OfflineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトタイプに対して有効な属性。関連するリソースをOffline状態にするときに実行するスクリプトを指定
します。

・ OnlinePriority
設定値 : 0、1
userApplicationオブジェクトに対して有効な属性。全クラスタを停止して再起動した場合に、RMSが、アプリケーションを、最後にOnline
であったノード上で起動するかどうかを指定します。0に設定された場合や何も設定されていない(デフォルト) 場合、アプリケーションは
属性PriorityListで最も優先順位の高いノードでOnlineになります。1に設定すると、アプリケーションは最後にOnlineであったノード上で
Onlineになります。AutoStartUpまたは優先切替えの場合、この最後のOnlineノードが、優先順位リスト内での位置に関係なく、最高の
優先順位になります。
RMSは、timestampを参照して、userApplicationが最後にOnlineであったのはどこかを追跡します。userApplicationについて最新の
timestampを持つノード上で、userApplicationがOnlineになります。異なるクラスタノード間では、通常時間の同期が実行されますが、
実行されない場合もあります。RMSは、クラスタ内のノード間の時間同期を確保する機構を備えていないため、システム管理者が管理
する必要があります。

- 154 -
 RMSによりクラスタ内のノード間で著しい時間の不一致が発見された場合は、switchlogにエラーメッセージが記録されます。NTPDま
たは CHRONYを使用して、クラスタ内のノードの同期をとることもできます。
詳細については、xntpdまたは chronyd のマニュアルページを参照してください。
OnlinePriority固定状態情報は、RMSが、最後にOnline状態にあったノードが構成から削除された状態で起動されるとクリアされます。

・ OnlineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトに対して有効な属性。関連するリソースをOnlineまたはStandby状態にするスクリプトを指定します。

・ PartialCluster
設定値: 0、1
userApplicationオブジェクトに設定できる属性です。userApplication の起動時に、userApplicationが動作できるすべてのノードに対し、
起動しようとするuserApplicationがすでに起動していないかをチェックする処理を実行するかどうかを定義します。
本属性値を0に設定すると、userApplicationが動作できるすべてのノードがOnline状態にならないと、userApplicationは起動しません。
本属性値を1に設定すると、userApplicationが動作できるすべてのノードがOnline状態にならなくても、Online状態であるノードで
userApplicationは起動します。

・ PersistentFault
設定値 : 0、1
userApplicationオブジェクトに対して有効な属性。1に設定すると、RMS 起動時に、前回RMSが停止した際の状態がチェックされます。
以下のいずれかに該当する場合、userApplication は RMS 起動直後に Faulted 状態(InitialFault)となります。

－ RMSの停止処理が行われなかった
－ RMS停止時に userApplication が Faulted 状態だった
userApplication が Faulted 状態になった場合は、その要因を取り除いてから、hvutil -c で Faulted 状態をクリアしてください。

注意
PersistentFault 属性が1 に設定されていない場合、ノード異常時などのOS のパニックリブート後のRMS 起動時に、クラスタアプリケー
ションはFaulted 状態になりません。この時、Faulted 状態ではないため、このノードはクラスタアプリケーションの切替え・切戻しが可能
なノードとして扱われます。このため、クラスタを構成する全ノードで、クラスタアプリケーションのOnline 処理中に必ず異常が発生し、OS
のパニックリブートが発生するようなケースでは、フェイルオーバが無限に繰り返されることがあります。

・ PostOfflineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトに対して有効な属性。関連するリソースの状態がOfflineに変化した後で実行するスクリプトを指定
します。

・ PostOnlineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトに対して有効な属性。関連するオブジェクトの状態がOnlineまたはStandby に変化した後で実行
するスクリプトを指定します。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ Online処理では、本スクリプトの終了を待ち合わせます。
－ スクリプトの終了コードとして0 以外の値が戻ると、スクリプトの失敗を示すメッセージがswitchlogファイルに記録され、Fault処理が
開始されます。

Online処理の詳細については、"2.1.3 Online処理"を参照してください。

・ PreCheckScript
設定値 : 有効なスクリプト (文字)

- 155 -
 userApplicationオブジェクトに対して有効な属性。OnlineまたはStandby処理を開始する前に実行するスクリプトを指定します。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ スクリプトの終了コードとして0が戻ると、OnlineまたはStandby処理が開始されます。スクリプトの終了コードとして0 以外の値が戻ると、
スクリプトの失敗を示すメッセージがswitchlogファイルに記録され、OnlineまたはStandby処理は開始されません。

詳細については、"2.1.3.2 PreCheckScript"を参照してください。

・ PreOfflineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトに対して有効な属性。関連するオブジェクトをOffline状態にする前に実行するスクリプトを指定し
ます。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ Offline処理では、本スクリプトの終了を待ち合わせます。
－ スクリプトの終了コードとして0 以外の値が戻ると、スクリプトの失敗を示すメッセージがswitchlog ファイルに記録されますが、Offline
処理は継続されます。Offline処理完了後に、Fault処理が開始されます。

Offline処理の詳細については、"2.1.4 Offline処理"を参照してください。

・ PreOnlineScript
設定値 : 有効なスクリプト (文字)
SysNodeを除くすべてのオブジェクトに対して有効な属性。関連するオブジェクトをOnlineまたはStandby状態にする前に実行する
スクリプトを指定します。

－ スクリプト登録時に指定した引数がそのままスクリプト実行時に指定されます。
－ Online処理では、本スクリプトの終了を待ち合わせます。
－ スクリプトの終了コードとして0 以外の値が戻ると、スクリプトの失敗を示すメッセージがswitchlog ファイルに記録され、Fault処理が
開始されます。

Online処理の詳細については、"2.1.3 Online処理"を参照してください。

・ PreserveState
設定値 : 0、1
userApplicationオブジェクトに対して有効な属性。1に設定すると、障害発生後にリソースをOffline にしません。AutoSwitchover に
ResourceFailure が設定されている場合、この属性は無視されます。

・ ScriptTimeout
設定値 : 0-MAXINT (秒数)または "timeout_value[:[offline_value][:online_value]]" 形式の有効な文字列
すべてのオブジェクトタイプに対して有効な属性。構成定義ファイルでノードに対して指定したすべてのスクリプトのタイムアウト値を指定
します。このタイムアウト時間が経過すると、RMSはスクリプトに対して停止信号を送信します。
offline_valueタイムアウト値とのonline_valueタイムアウト値は、それぞれこの文字列の形式で指定します。
・ ShutdownPriority
設定値 : 0-20
userApplicationオブジェクトに割当てられた重み係数。インタコネクト故障が発生した場合に生成されるサブクラスタの強制停止の優
先度を決定します。
インタコネクト故障が発生して、ノードの強制停止要求が生成されると、SFは各サブクラスタのSFノードの重みと、サブクラスタ内の全
OnlineアプリケーションのRMS ShutdownPriorityを合算して、各サブクラスタの優先順位を算出します。ノードがインタコネクトによって
相互に結合されているサブクラスタが、最も大きな重み係数を持ち、強制停止する優先順位が最も低くなります。各サブクラスタの重
みは、SFノードの重みに、サブクラスタ内でOnline状態にあるすべてのuserApplicationオブジェクトのRMS ShutdownPriorityの値を加
えた合計値です。

・ StandbyCapable
設定値 : 0、1

- 156 -
 リソースオブジェクトに対して有効な属性。1に設定すると、対応する親userApplicationがOfflineであるすべてのノード上で、Standby
処理が実行されます。
この属性をユーザが変更できるのは、cmdlineサブアプリケーションについてのみです。他のサブアプリケーションに関しては、構成設定
ツールが制御します。

・ StandbyTransitions
設定値 : StartUp、SwitchRequest、ClearFaultRequest、または、縦線(|) で結合される任意の組合せ
userApplicationオブジェクトに対して有効な属性。この値は、userApplicationオブジェクトについて、Standbyプロセスがいつ開始さ
れるかを指定します。

－ StartUpは、起動時を指定します。 この設定は、実際のアプリケーションがすでにオンラインになっている場合や、AutoStartUp 属性
が設定されているため、userApplicationオブジェクトが強制的にOnline化される場合には無視されます。

－ SwitchRequestは、切替えの後、切替え前にOnlineであったuserApplicationオブジェクトをStandby状態に移行させます。
－ ClearFaultRequestは、hvutil -cによりFaulted状態がクリアされたuserApplicationをStandby状態に移行させます。
・ WarningScript
設定値 : 有効なスクリプト (文字)
ディテクタを持つリソースオブジェクトに対して有効な属性。関連するリソースの状態がWarningになった後で実行するスクリプトを指定
します。

D.2 RMS構成ウィザード管理属性
このセクションに記載された属性は、RMS構成ウィザードによりプログラム内で設定されています。

・ AlternateIp
設定値 :任意のインタコネクト名
すべてのSysNodeオブジェクトに対して有効な属性。SysNode名に割当てられたインタコネクトが使用不能になった場合に、RMSが追
加のクラスタインタコネクトとして使用するスペース区切りリスト。これらのすべてのインタコネクトが/etc/hostsデータベースに登録され
ていなければなりません。RMS構成ウィザードはデフォルトで、ノード<nodename>への代替インタコネクトが、<nodename>rmsAI<nn>
の形式 (<nn>はゼロパディングされた2桁の数) の名前を持つことを前提としています。この設定はごく限られた構成に適用されます。CF
のクラスタでインタコネクトとして使用しないでください。

・ Affiliation
設定値 : 任意の文字列
リソースオブジェクトに対して有効な属性。RMS内では、機能的な意味はありません。

・ AutoRecoverCleanup
設定値 : 0、1
Controllerオブジェクトに対して有効な属性。 この属性を1に設定して、AutoRecoverを1にしたときは、子アプリケーションで障害が発生
した場合、そのアプリケーションはOfflineになってから回復します。 この属性を0に設定して、AutoRecoverを1にしたときは、子アプ
リケーションで障害が発生した場合、そのアプリケーションはOfflineにならずに回復します。

・ Class
設定値 : 任意の文字列
SysNodeを除くすべてのオブジェクトに対して有効な属性。リソースオブジェクトのクラスを示します。他のプログラム (SNMPエージェ
ントなど) によってさまざまな目的で使用されます。この値は、RMSウィザードによって指定されます。

・ Comment
設定値 : 任意の文字列
すべてのオブジェクトに対して有効な属性。RMSでは、機能的な意味はありません。

・ ControlledSwitch
設定値 : 0、1

- 157 -
 制御対象のuserApplicationオブジェクトに対して有効な属性。 0に設定すると、RMSはCLI またはGUIからの手動の切替え要求を受け
付けます。 1に設定すると、親コントローラのみがユーザアプリケーションに対する切替え要求を発行することができます。

・ DetectorStartScript
設定値 : 任意の有効なディテクタ
ディテクタを持つリソースオブジェクトに対して有効な属性。<configname>.usファイルでディテクタ起動コマンドを直接指定します。
なお、RMSは状態を内部的に決定するため、Controllerオブジェクトにはディテクタがありません。

・ HostName
設定値 : 任意のSysNode名
userApplicationオブジェクトの第1レベルの子であるandOpオブジェクトだけに設定する値です。これらのandOpオブジェクトは、
HostName属性で指定されたSysNodeに自分の親アプリケーションを関連付け、さらにアプリケーションに対するノードの優先順位も決
定します。

・ I_List
設定値 : スペース区切りのSysNode名リスト
すべてのSysNodeオブジェクトに対して有効な属性。RMSが追加のクラスタインタコネクトを監視する際に使用するスペース区切りリスト。
追加のクラスタインタコネクトはユーザアプリケーションでのみ使用され、PRIMECLUSTER製品では使用しません。監視されるすべ
てのインタコネクトが/etc/hostsデータベースに登録されていなければなりません。また、すべてのSysNodeオブジェクトが同数の追加イ
ンタコネクトを持っていなければなりません。デフォルト値はありません。

・ LastDetectorReport
設定値 : Online、Offline、Faulted、Standby
ディテクタを持つリソースオブジェクトに対して有効な属性。この属性には、ディテクタから通知された最新のオブジェクトの状態が含ま
れています。この値は通常、Cluster Admin GUI に表示されます。表示される値はオブジェクトが表している資源のタイプによって異な
ります。

・ MaxControllers
設定値 : 0-512
userApplicationオブジェクトに対して有効な属性。指定した子アプリケーションの親userApplicationオブジェクトの最大数。

・ NoDisplay
設定値 : 0、1
すべてのオブジェクトタイプに対して有効な属性。 1に設定したリソースオブジェクトは、hvdisp で -i オプションを指定した場合のみ表示
されます。

・ NullDetector
設定値 : on、off
ディテクタを持つリソースオブジェクトに対して有効な属性。NullDetectorをonに設定すると、ディテクタが実行時に無効になります。この
属性は動的再構成でのみ使用します。RMS構成定義ファイルで、NullDetectorをonにハードコード化してはいけません。

・ PriorityList
設定値 : 有効なSysNode名のリスト (文字)
userApplicationオブジェクトに対して有効な属性。アプリケーションがOnlineになることができるSysNodeオブジェクトのリストが入って
います。リスト内の順序によって、優先手動切替え時の次のアプリケーション切替え先ノードが決まり、Fault後の手動切替え順序が決
まります。リストは循環して適用されます。アプリケーションのノードを選択すると、それに伴ってこの属性が指定されます。RMSはノードが
選択された順序を採用して、PriorityListを自動的に作成します。ノードリスト内の各ノードを選択することにより、順序を変更するこ
とができます。
ローカルgControllerオブジェクトまたはcontrollerオブジェクトで制御されたアプリケーションでは、PriorityListのノードの順番は無視さ
れます。ただし、それぞれの制御対象アプリケーションは、controllerオブジェクトに指定されているノード上で実行できなければな
りません。

- 158 -
・ Resource
設定値 : 有効な名前 ( 文字)
Controllerオブジェクトに対して有効な属性。 子（制御対象）ユーザアプリケーションの名前を含みます。

・ rKind
設定値 : 0-2047
gResourceタイプのオブジェクトに対するディテクタの種類を指定します。

・ rName
設定値 : 有効な名前 (文字)
gResourceオブジェクトに対して有効な属性。汎用ディテクタに転送される文字列を指定します。

・ SplitRequest
設定値 : 0、1
controllerオブジェクトに対して有効な属性。1に設定すると、Offline要求およびOnline要求とは別に、PreOffline要求とPreonline要求
が、子userApplicationに伝播します。0に設定すると、子userApplicationに対してPreOffline要求またはPreOnline要求が発行されま
せん。

・ StateDetails
設定値 : 任意の文字列
すべてのオブジェクトに対して有効な属性。 Cluster Admin GUI またはhvdisp CLI ユーザインタフェース内に状態の詳細情報を追
加表示します。 ほとんどの場合、[StateDetails]フィールドは空白です。 RMSがこの追加情報を表示するのは、通常、アプリケーションが
保守モードにある場合か、オブジェクトが遷移、不整合、または待機の状態にある場合です。

- 159 -
付録E 環境変数
この章では、RMSのすべての環境変数を以下のグループに分けて説明します。

・ "E.2 RMSグローバル環境変数"では、"RMS グローバル環境変数"について説明しています。

・ "E.3 RMSローカル環境変数"では、RMS ローカル環境変数について説明しています。
・ "E.4 RMSスクリプト実行環境変数"では、RMS スクリプト実行環境変数について説明しています。

E.1 RMS環境変数の設定
注意
hvenv構成設定ファイルの変更は行わないでください。構成設定のRMS環境変数を変更する際には必ず、hvenv.localファイルに行っ
てください。

RMS環境変数の値は、hvenv.localファイルで指定されています。RMS環境変数の設定を変更するには、テキストエディタでhvenv.localを
開き、必要に応じて行の編集または追加を行います。
RMS環境変数の値は通常次のように記述されています。

export SCRIPTS_TIME_OUT=200

RMSは起動時に一度だけ、hvenvおよびhvenv.localからRMS環境変数の値を読取り、各ノードでENVオブジェクトとENVLオブジェクトを
初期化します。これ以降RMSは、ENVオブジェクトとENVLオブジェクトのファイルを参照しません。このためhvenv.localに加えた変更は、
RMSの次回起動時まで有効になりません。
ENVL (ローカル) オブジェクトの値はENV (グローバル) オブジェクトの値より優先されます。hvenv.localファイルにRMSグローバル環境
変数が設定された場合は、対応するhvenvファイルの設定は上書きされます。ただし、RMSグローバル環境変数の設定はクラスタ全体で同
じでなければならないため、1つのノードでhvenv.localファイルのRMSグローバル環境変数の設定を変更した場合は、残りの全ノードで同
じようにhvenv.localを変更してください。
RMSの実行中は、hvdispコマンドでRMS環境変数を表示することができます。ルート権限は必要ありません。

hvdisp ENV
hvdisp ENVL

E.2 RMSグローバル環境変数
注意

・ RMSグローバル環境変数 (ENV) の設定は、クラスタシステムで共通な構成定義のチェックサムでも検証されます。チェックサムは BM

(ベースモニタ) の起動時に各ノードで検証され、いずれかのノードでチェックサムが異なっていると、RMSの起動は失敗します。

・ RMS環境変数のデフォルト値は、<RELIANT_PATH>/bin/hvenvで調べることができます。hvenv.local構成設定ファイルでRMS環
境変数を再定義することができます。

このセクションでは、RMSグローバル環境変数について説明します。
HV_AUTOSTARTUP_IGNORE
設定値: RMSクラスタノードのリスト。RMSクラスタノードのリスト内のノード名は、RMS構成定義ファイルに記載されたSysNodeの名前
であることが必要です。リストにCF名を含めることはできません。
デフォルト : "" (未設定)
RMSの起動時に無視されるクラスタノードのリスト。デフォルトでは、RMS環境変数は設定されません。AutoStartUp属性を設定してあり、
ユーザアプリケーションで定義されているすべてのクラスタノードがOnlineを報告すると、ユーザアプリケーションが自動起動処理を開始
します。クラスタノードがこのリストに含まれている場合は、このノードがOnline状態を報告していなくても、自動起動処理が開始されます。

- 160 -
 1つ以上のクラスタノードを一定期間クラスタから削除する必要があり、削除されたクラスタノードを指定する構成定義ファイルをRMSが
使用し続ける場合に、RMS環境変数を使用します。この場合、RMS環境変数で使用不能なクラスタノードを指定すると、使用不能な
クラスタノードがOnlineを報告しなくても、すべてのユーザアプリケーションが自動的にオンラインになります。

注意
RMS環境変数を使用する場合は、すべてのクラスタノード上で正しく定義し、常に最新の値に設定する必要があります。ノードをク
ラスタに戻すときは、RMS環境変数からそのノードを削除します。ノードをRMS環境変数から削除しないと、RMSは起動処理中にこ
のノードを無視し、このリストで指定されているノードでアプリケーションが稼動しているかどうかをチェックしないので、データが失われる
場合があります。RMS環境変数を使用する場合は、システム管理者がこのリストを最新の状態に保つ必要があります。

HV_AUTOSTART_WAIT
設定値: 0 - MAXINT
デフォルト : 60 (秒)
RMSの起動時にクラスタノードがOnlineを報告するまでの待ち時間を (秒数で) 指定します。この時間が過ぎて、すべてのクラスタノー
ドがオンラインにならないと、Onlineを報告しないクラスタノード、およびユーザアプリケーションを自動的に起動できない理由が、
switchlogメッセージによって報告されます。

注意
この属性は警告メッセージです。AutoStartUpは、指定された時間の経過後も処理を継続します。

HV_CHECKSUM_INTERVAL
設定値: 0 - MAXINT
デフォルト : 120 (秒)
各Onlineノードのチェックサムとローカルチェックサムが同じであると確認されるまでRMS BM (ベースモニタ) が待つ時間 (秒数)。
この時間内にチェックサムが確認されると、ローカルノード上のRMSが通常どおり動作し続けます。一方、リモートノードのチェックサムが
確認されない場合、または異なるチェックサムが確認された場合、HV_CHECKSUM_INTERVALの今回の待機時間中に起動され
たローカルモニタはシャットダウンします。
また、リモートノードのチェックサムが確認されない場合、または異なるチェックサムが確認された場合、HV_CHECKSUM_INTERVAL
の今回の待機時間より前に起動されていたローカルモニタはこのリモートノードをOfflineと認識します。
HV_COM_PORT
設定値: 0 - 65535
デフォルト : 8000
RMSベースモニタがクラスタの全ノードと通信する場合に使用するポート。
HV_LOG_ACTION_THRESHOLD
設定値: 0 - 100
デフォルト : 98
hvlogcontrolがRMS ログファイルを消去する条件を指定します。 RELIANT_LOG_PATHが存在するファイルシステム上で、使用済み
容量のパーセントがこのしきい値以上になった場合は、RELIANT_LOG_PATHのサブディレクトリはすべて削除されます。 さらに
HV_LOG_ACTION がonに設定されている場合に、すべてのサブディレクトリの削除が完了すると、現在のログファイルも削除されます。
詳細については、"HV_LOG_ACTION"を参照してください。
HV_LOG_WARN_THRESHOLD
設定値: 0 - 100
デフォルト : 95
RMSログファイルの容量につき、hvlogcontrol がどの時点で警告を表示するかを指定します。 RELIANT_LOG_PATHが存在する
ファイルシステム上で、使用済み容量のパーセントがこのしきい値以上になった場合、hvlogcontrol がユーザに警告を発します。上記
HV_LOG_ACTION_THRESHOLDも参照してください。

- 161 -
HV_LOH_INTERVAL
設定値: 0 - MAXINT
デフォルト : 30
userApplication が最後にOnline 状態であったノード (LOH:Last Online Host) を特定するために、タイムスタンプを比較する際の、最
小時間差 (秒数) を指定します。本設定はOnlinePriority 属性に1が設定されている場合に使用されます。
2つのクラスタノードにおけるそれぞれの userApplication に記録された LOH タイムスタンプを比較して、その差がこの属性で指定する
時間よりも小さかった場合、RMS は自動起動せず、優先順位の変更は行われません。この場合はコンソールにメッセージを送信し、
オペレータ介入が必要になります。
この値を設定する場合は、そのクラスタ内部での時刻同期精度を考慮に入れる必要があります。クラスタノード間で発生しうる時間差よ
りも大きい値を指定してください。
HV_USE_ELM
設定値: 0、1
デフォルト : 1
RMSベースモニタによるハートビート監視モードを指定します。
0－リモートノードとベースモニタの状態は、ネットワークを通じてUDPハートビートパケットを定期的に送信することにより検出されます。
HV_CONNECT_TIMEOUTで定義した間隔内にリモートノードからのハートビートが受信されなかった場合、リカバリ期間の経過を待っ
てからノード停止処理を開始します。
1－ELM (Enhanced Lock Manager) とUDPハートビート方式を組み合わせて使用します。この設定は、CFがインストールされ構成設定
が完了している場合にのみ有効です。ELMのロックは、ローカルノードによって取得され、ELMがリモートノードまたはベースモニタの
DOWN状態を通知するまで、ローカルノードにより保存されます。リモートノードまたはベースモニタのDOWN状態が通知されたノードは
直ちに停止されます。ELMがリモートノードの状態に変化があったことを通知すると、RMSは各ノードのUDPハートビートの監視を開始
します。監視の方法は上記と同様ですが、リカバリタイムアウト時間はかなり長く設定されます。
ELMが起動されているかどうかにかかわらず、UDPハートビートが、ハートビートリカバリタイムアウト期間終了前に受信されなければ、
リモートノードは停止されます。CFが起動されていない場合、ELMは自動的に停止され、ハートビートリカバリタイムアウトのデフォルト値
が45秒に設定されます。CFが起動されている場合は、ELMがデフォルトで起動され、ハートビートリカバリタイムアウトのデフォルト値は、
600秒に設定されます。これにより、リモートノードの応答が遅い場合でも、ノードの途中停止を避けることができます。
ELMの手動停止は、専門知識がある場合にのみ行ってください。CFが起動された状態でELMが停止している場合、ハートビートタ
イムアウトをデフォルト値の600秒で使用すると、間隔が長すぎてリモートのRMSやノードの停止が効率的に検出できません。この場合
には、ローカルノードのリカバリタイムアウト値も手動で調整する必要があります。調整するには、hvcm -h <timeout> -c <config_file>コ
マンドでRMSを起動します。リカバリタイムアウトの設定値は、クラスタ内の全ノードで同じにする必要があります。ELMが停止されている
場合の推奨グローバル値は45秒です。
RELIANT_LOG_LIFE
設定値: 任意の日数
デフォルト : 7 (日)
RMSログ情報が保持される日数を指定します。RMSを起動するたびに、RMSを最後に起動した時刻に基づく名前のディレクトリが作成
されます。このディレクトリに、すべてのログファイルが入ります。すべてのRMSログファイルはこの方法で保持されます。
RELIANT_LOG_PATH 配下のサブディレクトリのうち、更新日時(ctime)がこのRMS環境変数で指定した日数より前のディレクトリは、
cronジョブで削除されます。
RELIANT_LOG_PATH
設定値: 任意の有効なパス
デフォルト : /var/opt/SMAWRrms/log
すべてのRMSログファイルとRMS Wizard Toolsログファイルが格納されるディレクトリを指定します。内部ログの格納場所は本設定値の
変更に影響されません。
RELIANT_PATH
設定値: 任意の有効なパス
デフォルト : /opt/SMAW/SMAWRrms
RMSディレクトリ階層のルートディレクトリを指定します。通常は、ユーザがデフォルト設定を変更する必要はありません。

- 162 -
RELIANT_SHUT_MIN_WAIT
設定値: 0 - MAXINT
デフォルト: MAXINT (秒)
hvshutコマンドがタイムアウトするまでの時間を秒数で指定します。
hvshutコマンドが-l、-s、-aのいずれかのオプションで実行されると、RMS は起動状態のクラスタアプリケーションのオフライン処理を行っ
た後、RMS の停止処理を行います。
そのため、RELIANT_SHUT_MIN_WAITには、以下を合計した時間を設定してください。

1. クラスタアプリケーションのオフライン処理が終了するのに必要な最大時間
2. BM(ベースモニタ) が停止するのに必要な最大時間（30秒）
1.の値には、クラスタアプリケーションに含まれる、すべてのリソースのスクリプトタイムアウト時間の合計値を使用してください。
各リソースのスクリプトタイムアウト時間は、リソース名を引数にした hvdispコマンドの実行により、OfflineScript属性が空でないリソースの
ScriptTimeout属性の設定値（秒数）で確認できます。
クラスタアプリケーションが複数存在する場合は、クラスタアプリケーションごとにリソースのスクリプトタイムアウト時間を合計した値のうち、
最も大きい値を使用してください。

注意
RELIANT_SHUT_MIN_WAITの値を大きくすることにより、クラスタアプリケーションのオフライン処理の遅延やハングが発生した場合
に、以下のような影響があります。

－ RMS の停止や OS シャットダウンの処理に、RELIANT_SHUT_MIN_WAITの設定値以上の時間がかかる可能性があります。

－ RMS の停止や OS シャットダウンによる、クラスタアプリケーションの自動切替えの処理に、RELIANT_SHUT_MIN_WAITの設
定値以上の時間がかかる可能性があります。

RELIANT_SHUT_MIN_WAITの値が大きすぎる場合は、前述の 1. の値には、想定されるクラスタアプリケーションのオフライン処理
がタイムアウトするケースのうち、タイムアウトまでにかかる時間が最も長いと見込まれるケースの処理時間を使用してください。
ただし、RELIANT_SHUT_MIN_WAITの値が小さすぎると、クラスタアプリケーションのオフライン処理が終了する前に hvshutコマ
ンドがタイムアウトする現象が頻発するおそれがあります。このため、RELIANT_SHUT_MIN_WAITのチューニングは慎重に行って
ください。

注意
hvshutコマンドのタイムアウト時に RMS は異常終了するため、リソースが停止せず起動したままになる場合があります。この状態にて、他
のノードで RMS を起動し、クラスタアプリケーションを強制的に起動すると、リソースが複数ノード上で同時に起動している状態となり、
リソースで共用ディスクの制御を行っている場合、データ破壊が発生するおそれがあります。このため、hvshutコマンドがタイムアウトした
場合は、 RMS が異常終了したノードの OS をシャットダウン、またはノードを強制停止することで確実にリソースを停止させてから、RMS
とクラスタアプリケーションを起動してください。

E.3 RMSローカル環境変数
ローカルのRMS環境変数の設定はノードごとに異なります。このセクションでは、RMSローカル環境変数について説明します。
HV_AUTOSTARTUP
設定値: 0、1
デフォルト : 1(AutoStartUp属性の通常の処理)
ローカルノード上にある全userApplicationオブジェクトのAutoStartUp属性を制御します。1 (デフォルト) に設定すると、各
userApplicationの自動起動は、それぞれのAutoStartUp属性によって決まります ("D.1 ユーザ設定属性" を参照)。0に設定すると、
userApplicationに設定されたAutoStartUp属性は無視され、自動起動は行われません。HV_AUTOSTARTUPは、hvsetenvコマンド、
またはCluster Adminの [ツール] メニューから設定します。いずれに設定した場合でも、変更結果はRMSの次回起動時まで反映さ
れません。

- 163 -
HV_CONNECT_TIMEOUT
設定値: 5- MAXINT
デフォルト : 30(秒)。通常は、ユーザがデフォルト設定を変更する必要はありません。
相手ノードからハートビートがない状態がこの時間 (秒数) だけ経過すると、ベースモニタはノードとの接続が切断されたと判断し、UDP
ハートビートリカバリタイマーを起動します。
5未満の数値を入力すると、システムによって5に変換されます。
HV_LOG_ACTION
設定値: on、off
デフォルト : off
RELIANT_LOG_PATHファイルシステム上の使用済み領域がHV_LOG_ACTION_THRESHOLD以上になった場合に、そのディ
レクトリにある現在のログファイルが削除されるかどうかを決定します。詳細については、"HV_LOG_ACTION_THRESHOLD"を参照
してください。
HV_MAX_HVDISP_FILE_SIZE
設定値: 0 - MAXINT
デフォルト : 20,000,000 (バイト)
RMSが構成データおよび構成変更と状態変化に関する情報をhvdispに提供するために使用する一時ファイルが、無限に大きくな
るのを防止します。このRMS環境変数の値は一時ファイル<RELIANT_PATH>/locks/.rms<hvdispプロセスのプロセスID>の最大サ
イズ (バイト数) です。
HV_MAXPROC
設定値: 0 - 99
デフォルト : 30
RMSが同時に実行できるスクリプトの最大数を定義します。ほとんどの場合は、デフォルト (30) で十分です。
HV_MLOCKALL
設定値: 0、1
デフォルト : 0
1に設定するとベースモニタプロセスおよび割当てたすべてのメモリは、メモリ内でロックされます。0 （デフォルト） に設定すると、ベー
スモニタはスワップアウトされる場合があります。
HV_RCSTART
設定値: 0、1
デフォルト : 1 (RMSをrcスクリプトで起動します)
RMSをrcスクリプトで起動するかどうかを決定します。1 (デフォルト) に設定すると、RMSはシステムの起動時に、rcスクリプトから自動で
起動されます。0に設定されていると、RMSは手動でhvcmコマンドによって起動する必要があります。HV_RCSTARTは、Cluster Admin
の [ツール] メニューまたはhvsetenvコマンドで設定できます (rc起動の前提条件: CONFIG.rmsが存在し、有効なエントリがあること)。
HV_REALTIME_PRIORITY
設定値: 0 - 99
デフォルト : 50
RMS BM (ベースモニタ) とそのディテクタのRTクラス内の優先順位を定義します。この値を設定する場合は注意が必要です。優先順位
を高く設定すると、他のOSのリアルタイムプロセスが、プロセッサのタイムスライスを取得できなくなる可能性があります。低く設定すると、
RMS BMがディテクタからの通知に反応できなくなったり、コマンドラインユーティリティからの要求を実行できなくなったりする可能性
があります。
この変数はSolaris でのみ有効です。 Linux プラットフォーム上では何の効力もありません。
HV_SCRIPTS_DEBUG
設定値:0、1
デフォルト : 0
RMSスクリプトによるデバッグ出力情報を制御します。この変数を1に設定すると、Wizard Toolsによって生成され管理されるスクリプトの
設定いかんにかかわらず、RMSファイルに対して実行されたコマンドに関する詳細な実行時情報が書き込まれます。 記録される情報の

- 164 -
 内容はスクリプトによって異なります。この設定は、PRIMECLUSTER製品提供のスクリプトにのみ適用されます。スクリプトによるデバッグ
情報の記録を停止するには、hvenv.localでHV_SCRIPTS_DEBUGエントリを削除するか、export HV_SCRIPTS_DEBUG=0を指定
してください。

注意
この変数がhvenv.localに設定された場合、RMSはこれをスクリプト環境に追加しますが、それ以外の処理はしません。 このため、Cluster
Admin GUI およびhvdisp ENVL出力には表示されません。

HV_SYSLOG_USE
設定値:0、1
デフォルト : 1 (hvenvにおける設定)
RMS BM (ベースモニタ) からシステムログへの出力を制御します。RMSは常に、ERROR、FATAL ERROR、WARNINGおよび
NOTICEの各メッセージをswitchlogファイルに記録しています。デフォルトでは、これらのメッセージはシステムログファイル (Solarisで
は/var/adm/messages、Linuxでは/var/log/messages) にも同時に出力される設定になっています。RMSメッセージのシステムログファ
イルへの出力を停止するには、hvenv.localでexport HV_SYSLOG_USE=0に設定します。

注意
Linuxではこの変数を0に設定することを推奨します。Linuxでこの変数が1に設定されている場合、システム高負荷時、OSのシステムログ
処理の性能限界により、システムログ出力がハングすることで、RMSが他ノードからのハートビートに応答できなくなることがあります。

HV_VM_ENABLE_IP_ADVERTISE
設定値:0、1
デフォルト : 0
I/Oフェンシング機能を使用するVMware環境で、I/Oフェンシングによる切替えが発生した場合に、切替え先のノードから定期的に引継
ぎIPアドレスのARPパケットを送信（通信機器に対して通信経路を通知）する機能の有効/無効を指定します。
1に設定すると機能が有効になります。本設定を行うと、切替え先のノードからARPパケットを60秒周期で送信します。また、以下の
いずれかの条件を満たすとARPパケットの送信を終了します。

－ RMS環境変数HV_VM_IP_ADVERTISE_COUNTで指定された回数ARPパケットを送信した（デフォルトで約4時間）。
－ I/Oフェンシング機能によりパニックした切替え元のノードが再起動し、CFが起動した。
－ 切替え先のノードでuserApplicationのOffline処理が行われた。
0に設定すると機能が無効になります。

注意

－ userApplicationの切替え時、Glsリソースまたは引継ぎネットワークリソースのOnline処理の過程で、引継ぎIPアドレスへの通信経路
は切替え先のノードに更新されますが、切替え元のノードのパニック処理がOSハングなどにより遅延した場合、通信経路が切替え元
のノードに戻る可能性があります。本機能を有効にすると、引継ぎIPアドレスの通信経路が切替え元のノードに戻った場合に、通
信経路を短時間で切替え先のノードに更新し直すことができます。

－ 以下のいずれかの場合、本機能を設定しても有効にはなりません。
- 引継ぎIPアドレスにIPv6アドレスを使用する場合
- userApplicationにGlsリソースまたは引継ぎネットワークリソースを登録しない場合

HV_VM_IP_ADVERTISE_COUNT
設定値:任意の回数
デフォルト : 240(回)

- 165 -
 I/Oフェンシング機能を使用するVMware環境で、切替え先のノードから引継ぎIPアドレスのARPパケットを送信する機能を使用する場
合、本RMS環境変数により60秒周期のARPパケットの送信回数を指定できます。
回数を0に設定すると、送信回数の制限がなくなりARPパケットを送信し続けるようになります。
RELIANT_HOSTNAME
設定値: 任意の有効な名前
デフォルト : <ノード名>RMS
RMSクラスタ内のローカルノードの名前。RMSサフィックスが付くCF名 (fuji2RMSなど) の出力をこのRMS環境変数に割当てて、この
RMS環境変数のデフォルト値を定義します。

export RELIANT_HOSTNAME=`cftool -l 2>/dev/null | tail -1 |

cut -f1 -d" "`RMS

この事前設定値が適切でない場合は、すべてのクラスタノード上で変更する必要があります。
指定したクラスタノード名は、<configname>.us構成定義ファイル内のSysNode名と一致していなければなりません。ノード名によって、
RMSがこのノードとの通信を確立する際に使用するIPアドレスが決まります。
RELIANT_INITSCRIPT
設定値: 任意の実行可能スクリプト
デフォルト : <RELIANT_PATH>/bin/InitScript
システム起動時にRMSが実行する初期化スクリプトを指定します。このスクリプトは、他のプロセスが起動する前に実行されます。こ
のスクリプトは、それが定義されているすべてのクラスタノード上で1度実行されるグローバルスクリプトです。
RELIANT_STARTUP_PATH
設定値: 任意の有効なパス
デフォルト : <RELIANT_PATH>/build
RMSの起動時に構成定義ファイルを探す場所を定義します。
SCRIPTS_TIME_OUT
設定値: 0 - MAXINT
デフォルト : 300 (秒)
すべてのRMSスクリプトが終了するまでのグローバル時間を (秒数で) 指定します。このRMS環境変数で定義した時間内に特定の
スクリプトを終了できない場合は、スクリプトが失敗したと想定され、RMSがスクリプト失敗に対する適切な処理を開始します。
この値が小さすぎると、エラーが不必要に生成されて、アプリケーションをオンラインまたはオフラインにできない場合があります。また、
この値が極端に大きいと、スクリプトの失敗を想定するまでの待ち時間が長くなりすぎます。
このグローバル設定値は、RMSが監視するすべてのオブジェクトについて適切であることが必要です。そうでない場合は、
ScriptTimeout属性のオブジェクト固有の値が代わりに使用されます。

E.4 RMSスクリプト実行環境変数
本セクションのRMS環境変数は、RMSベースモニタが該当オブジェクトのスクリプトを実行するときに、RMSによって自動的に設定されます。
これらのRMS環境変数はスクリプトの環境下にのみ存在し、かつ、スクリプト実行の間のみ存在します。また、明示的に設定されるため、デ
フォルト値はありません。
HV_APPLICATION
設定値: 任意のuserApplication名
現在のオブジェクトを含むサブツリーの最上位にあるuserApplicationオブジェクトの名前です。
HV_AUTORECOVER
設定値: 0、1
1に設定されている場合、スクリプトの呼び出しがAutoRecoverの試行に起因することを示します。
HV_FORCED_REQUEST
設定値: 0、1

- 166 -
 1に設定されている場合、現在スクリプトによって強制要求が処理されていることを示します。
HV_LAST_DET_REPORT
設定値: Online、Offline、Standby、Faultedのいずれか
ディテクタから通知された最新のオブジェクトの状態です。
HV_OFFLINE_REASON
設定値: DEACT、SWITCH、FAULT、STOP、SHUTのいずれか
リソースが Offline状態になる理由が設定されます。
SWITCH：userApplicationの切替え要求(hvswitch)でOfflineになった
STOP：userApplicationの停止要求(hvutil -f、hvutil -c)でOfflineになった
FAULT：リソース故障でOfflineになった
DEACT：userApplicationの非活性要求(hvutil -d)でOfflineになった
SHUT：RMSの停止要求(hvshut)でOfflineになった
HV_NODENAME
設定値: 任意のオブジェクト名
現在のオブジェクトを示すグラフノードの名前です。
HV_REQUESTING_CONTROLLER
設定値:コントローラ名およびノード名
空でない場合、現在のスクリプトの実行を要求したコントローラおよびノードの名前が格納されます。
HV_SCALABLE_CONTROLLER
設定値:スケーラブルコントローラ名
このアプリケーションを制御するスケーラブルコントローラの名前です。
HV_SCALABLE_INFO
設定値:スケーラブルアプリケーションのリスト
クラスタ内にあるすべてのスケーラブルアプリケーションのリストが格納されます。
HV_SCRIPT_TYPE
設 定 値 : PreCheckScript 、 PreOnlineScript 、 OnlineScript 、 PostOnlineScript 、 PreOfflineScript 、 OfflineScript 、 PostOfflineScript、
OfflineDoneScript、FaultScriptスクリプトタイプのいずれか
スクリプトの種類です。
NODE_SCRIPTS_TIME_OUT
設定値: 0 - MAXINT
現在のオブジェクトまたは、オブジェクトに対応する各スクリプトのタイムアウト値です。

注意
HV_REQUESTING_CONTROLLER、HV_SCALABLE_CONTROLLER、HV_SCALABLE_INFOはコントローラオブジェクトにより
制御されるアプリケーションのOnline/Offline処理でのみで使用できます。

- 167 -
付録F トラブルシューティング
本章では、コマンドラインインタフェース (CLI) およびCluster Adminグラフィカルユーザインタフェース (GUI) でRMSのトラブル発生時に
原因を特定する方法と対処方法、および、ログファイル、ログファイルの格納場所、ログレベルをオンにする方法、GUIでログを表示する方法、
CLIでログを表示する方法について詳しく説明します。

F.1 概要
Cluster Adminの以下のいずれかで、エラー状況または状態変更を検出した場合、RMSトラブルシューティングを開始します。

・ クラスタテーブル
・ RMSツリー
・ グラフ
クラスタテーブルには要約情報が入っています。エラーの状態を調査するには、このテーブルから始めると便利です。詳細情報については、
RMSツリーまたはグラフを参照します。switchlogやアプリケーションログの調査は、ログビューア機能を使用してログファイルを表示する
ことができます。
ログビューアには、以下の基準に基づく検索機能があります。

・ キーワード
・ 重要度
・ 0以外の終了コード
キーワードと日付範囲フィールドを使用して、エラーの原因を検索します。緊急な問題、警告、および重大な状態を重要度に基づいて検索
することができます。問題を未然に防ぐトラブルシューティングを行う場合、重要度コード (error、warning、notice、info) に基づいて検索す
ることができます。

注意

・ 定期的にログビューアを使用し、重要度レベルに基づいてログファイルを調べることによって、重大な問題が発生するのを回避する
ことを推奨します。問題の原因を診断できない場合は、クラスタ内の複数のノードからログビューアを調べてください。

・ 対処法については、"F.9 RMSトラブルシューティング"を参照してください。

以下の手順に従ってエラーを解決します。

1. Cluster Admin GUIを使用します。

2. 必要な場合は、ログファイルを表示します。
3. ログレベルを変更して詳細情報を取得します。
4. GUIでエラーを解決できない場合は、コマンドラインインタフェースを使用します。標準のUNIXコマンドを使用します。
5. 問題が続く場合は、RMS以外の問題かどうかを確認し、適切なマニュアルを参照します。
6. オペレーティングシステム、ハードウェア、ネットワークエラーのようなシステム関連の問題を調べます。
7. 自分で問題を解決できない場合は、当社技術員 (SE) に連絡してください。

F.2 デバッグメッセージとエラーメッセージ
RMSのコンポーネント (BM (ベースモニタ) やディテクタなど) が動作しているときは、デバッグメッセージとエラーメッセージがログファイルに
書込まれます。RMSのデフォルト設定では、これらのファイルが/var/opt/SMAWRrms/log ディレクトリに格納されます。hvenv.localファイ
ルで設定されているRELIANT_LOG_PATH環境変数で、このディレクトリを変更できます。
RMSを起動すると、ログへの書込みを開始します。デフォルト設定では、BMはすべてのエラーメッセージをログファイルまたはstderrに書込
みを行います。デフォルト設定ではデバッグ出力が詳細に制御されているため、通常はデフォルト設定を変更する必要はありません。

- 168 -
必要な場合は、BMで任意のノードの状態とメッセージをすべて記録することができます。しかし、ほとんどの場合、デバッグ出力を理解す
るには、RMS内部の操作に関する詳しい知識が必要です。このような情報は、当社技術員でなければ正しく評価できません。
RMSクラスタの管理者は、通常、switchlogファイルを調べるだけで十分です。このファイルには、着信切替要求やノードまたはリソースで
発生する障害など、RMSの重要なアクションがすべて記録されます。

注意
RMS構成に固有のログファイルもログディレクトリに格納されます。管理者は必要に応じてこれらのファイルを調べる必要があります。各ロ
グファイルの名前 (<userApplication>.log) は、RMS Wizard Toolsで設定したRMS構成によって異なります。詳細については、"F.5 アプ
リケーションログの出力の管理"を参照してください。

bmlogログファイルも、問題の解決に使用できます。

F.3 ログファイル
以下の表は、/var/opt/SMAWRrms/logに格納されているRMSログファイルについて説明しています。

表F.1 ログファイル
モジュール ファイル名 内容
BM tracelog オブジェクト間で送信されるすべてのメッセージ、およびすべて
の変更指示が記録されます。デフォルトでは、RMSはtracelogに
メッセージを出力しません。
BM abortstartlog 起動中に、以下のメッセージが出ると、このファイルが作成され
ます。
FATAL ERROR: RMS has failed to start!
詳細情報がさらにswitchlog に記録される場合もあります。
このファイルは、当社技術員(SE) がRMS起動失敗の原因を判
別するために作成されます。
BM bmlog 通常、一般的なRMSエラーログ情報とメッセージログ情報は、
メッセージ報告から詳細な情報まで、レベルによって分類され
ます。BMの起動時に指定するエラーログレベルによって、この
ファイルの内容が決まります。詳細については、 "F.4 RMS BM
(ベースモニタ) ログ出力の管理" を参照してください。
実行時にBMが受信したすべてのメッセージが記録されていま
す。
hvdumpによって生成された情報も含んでいます ( "F.10.1
hvdumpコマンドの使用 (RMS)" を参照してください)。
ログレベルフラグをオンにすると、大量のディスクスペースを消費
するため、このファイルの使用は管理者に限られています。デ
フォルトで、メッセージはbmlogに記録されません。
アプリケーションに関連する <application_name>.log アプリケーションに関連するすべてのメッセージが記録されます。
オブジェクトのディテクタとス アプリケーションが実行するすべてのスクリプトの出力もログファ
クリプト イルに書き込まれます。
すべて(BM、汎用ディテクタ、 switchlog 監視資源の切替えや異常に関する操作イベントが記録されます。
ノードディテクタ) 通常、ユーザは本ファイルを使用して調査してください。
汎用ディテクタ <program>log ディテクタが受け取ったすべてのメッセージとジョブ指示が記録
されます。また、対象資源の状態変化の情報とすべてのエラー
メッセージも含まれています。programはRELIANT_PATHの下
にあるディテクタの名前です。

- 169 -
F.4 RMS BM (ベースモニタ) ログ出力の管理
RMS BM (ベースモニタ) は実行時に、RELIANT_LOG_PATH/switchlogファイルとシステムログファイルに、ログメッセージを出力する
ことができます。このセクションでは、ログファイルのログレベル (詳細情報の程度) を制御する方法について説明します。各ログレベルとも、
上級ユーザのための内部機能に関する情報が記録されます。

注意
複数のログレベルを有効にしてRMSを実行すると、システムのパフォーマンスに影響します。この機能は、テストまたはデバッグ目的でのみ
使用してください。

F.4.1 RMS BM (ベースモニタ) ログレベルの管理

デフォルトでは、ベースモニタログ機能はRMS起動時に停止しています。ログレベルの初期値は、hvcmの-lオプションで指定することが
できます。

hvcm -l <level> -c <configuration_file> ...

RMSがすでに実行中の場合は、以下のコマンドでベースモニタのログレベルを管理します。

hvutil -l display
hvutil -l off
hvutil -l <level>

最初のhvutilコマンドで、ベースモニタの現在のログレベルを表示し、2番目のhvutilコマンドでベースモニタのログ機能を停止します。
hvcmまたはhvutilで-l <level>を指定すると、ベースモニタのログ機能が起動されます。<level>には、以下の形式で数値を1つ以上指定し
ます。

・ 数字1つ
・ カンマ区切りまたは空白区切りのリスト。空白区切りのリストの場合は、引用符で囲む。
例: 2,4,5,7 "2 4 5 7"

・ n1-n2のようにハイフンで区切った範囲指定。こうすると、n1からn2までのログレベルがすべて含まれます。-n2と指定した場合は1-n2と同
じ、n1-はn1を超えるすべてのログレベルを表します。n1の値は1以上であることが必要です。
例: 2-7 -7 2-

注意

・ ログレベルを0 (ゼロ) に指定するとすべてのログレベルが有効になります。ログ機能を停止するにはoffという特別なレベルを指定する

必要があります。

・ ベースモニタのログ機能を起動した状態で、RMS を 1 日以上連続して動作させる運用の場合、RMSのログによるディスク容量の圧迫を
避けるため、1日1回 hvlogclean コマンドが実行されるよう、cron の設定に hvlogclean コマンドを設定してください。これにより、1日ご
とにログファイルが退避され、RELIANT_LOG_LIFE の日数より古いログファイルは自動で削除されます。hvlogcleanの詳細につい
ては、"F.8.1 hvlogclean" を参照してください。

現在のログレベルは次回hvutil -l <level>またはhvutil -l offが実行されるか、RMSが停止されるまで有効です。

以下の表はベースモニタに指定できるレベルの一覧です。

表F.2 BM (ベースモニタ) のログレベル

ログレベル 意味
0 すべてのログレベルをオンにします
1 未使用
2 ディテクタ履歴をオンにします
3 hvdispレベル

- 170 -
 ログレベル 意味
4 mskx履歴 (BMのスタック履歴) をオンにします
5 エラーメッセージまたは注意メッセージ
6 ハートビートと通信デーモンのレベル
7 BMレベル
8 汎用コントローラメッセージ
9 管理コマンドメッセージ
10 基本タイプレベル
11 動的再構成コントラクトレベル
12 シャットダウンデバッグレベル
13 トークンレベル
14 ディテクタメッセージ
15 ローカルキューレベル
16 ローカルキューレベル
17 スクリプトレベル
18 userApplicationコントラクトレベル
19 一時的なデバッグ履歴
20 SysNode履歴
21 メッセージレベル
22 bmトレースログ
23 未使用

F.4.2 システムログへのBM (ベースモニタ) 出力の制御

デ フ ォ ル ト で は 、 RMS ベ ー ス モ ニ タ は 、 switchlog フ ァ イ ル と シ ス テ ム ロ グ フ ァ イ ル に 同 一 の 内 容 を 出 力 し ま す 。 こ の 設 定 は、
HV_SYSLOG_USE環境変数で制御します。
デフォルトではHV_SYSLOG_USE = 1に設定されています。この設定は、システムログとswitchlogに、RMSのNOTICEメッセージ、
WARNINGメッセージ、ERRORメッセージ、およびFATAL ERRORメッセージをすべて出力します。
RMSメッセージをシステムログに出力しないようにするには、hvenv.localファイルでHV_SYSLOG_USE=0に設定します。変更を有効に
するには、RMSを再起動する必要があります。

注意
Log3 RMSメッセージの場合、コンポーネント番号は1080023です。

F.5 アプリケーションログの出力の管理
RMS Wizard Tools で提供される実行時コンポーネントは、RMSベースモニタと同じログディレクトリ内のファイルにログメッセージを記録し
ます。このディレクトリは、RELIANT_LOG_PATH環境変数で定義されています。これらのコンポーネントが出力するメッセージは大きく2
つに分類できます。

・ リソースディテクタからのメッセージ
・ その他のメッセージ
ディテクタのログ機能は"F.6 ディテクタログの出力の管理"で説明されています。以下の記述はその他のメッセージについての説明です。

- 171 -
構成ツールで提供される実行時コンポーネントは、アプリケーションレベルのすべてのログを記録します。通常のユーザ向けのメッセージに
加え、さまざまなレベルのデバッグメッセージも生成します。ユーザ向けメッセージおよびデバッグメッセージはRELIANT_LOG_PATHの
以下のファイルに出力されます。

・ switchlog - RMS Wizard Toolsで提供される標準のサブアプリケーションは、障害やOffline遷移関連のディテクタレポートをswitchlog

ファイルに記録します。

・ <application_name>.log - アプリケーション固有のログファイルには、そのアプリケーションに関連するすべてのメッセージが記録さ
れます。アプリケーションが実行するすべてのスクリプトの出力もログファイルに書き込まれます。ファイルは、アプリケーションに対する
Offline処理またはOnline処理が開始された時点で作成されます。

・ hvdet_<xxx>.g<n>log - ディテクタが監視するリソース関連の情報 (すべての状態変化など) がすべて記録されるディテクタログファ

イルです。

アプリケーションの問題をデバッグするときは、switchlogファイル、アプリケーション固有のログファイル、および対応するディテクタログ
ファイルの内容をすべて調べる必要があります。

F.5.1 標準スクリプトのデバッグメッセージの制御
標準のRMS Wizard Toolsスクリプトのデバッグ出力は、hvenv.localファイルの環境変数HV_SCRIPTS_DEBUGの設定により制御する
ことができます。

・ デバッグ出力を開始するには次のエントリを作成します。

export HV_SCRIPTS_DEBUG=1

・ デバッグ出力を停止するには、HV_SCRIPTS_DEBUGエントリを削除するか、コメントアウトするか、値を0に設定します。

F.6 ディテクタログの出力の管理
すべてのRMSディテクタのインスタンスは、switchlogファイルと、そのインスタンス専用のログファイルに情報を記録します。ログファイルは
以下の形式で命名されています。

RELIANT_LOG_PATH/<detector_name>.g<n>log

<detector_name>はディテクタの名前、<n>はディテクタのインスタンス番号です。このようなファイルがディテクタの実行中のインスタンス
それぞれに1つ用意されています。なお、RMS Wizard Toolsディテクタの名前はhvdet_<xxx>です。<xxx>はリソースのタイプを表します。
たとえば、最初の (かつ唯一の) hvdet_systemディテクタのログファイルは<RELIANT_LOG_PATH>/hvdet_system.g1logです。
すべてのリソース状態変化が、switchlogファイルとディテクタの専用ログファイルの両方に記録されます。他のディテクタメッセージはすべて
専用ログファイルにのみ記録されます。

F.6.1 デバッグメッセージとログレベル
各ディテクタインスタンスは、デバッグメッセージを保存しておくために、10KBのメモリバッファを内部に持っています。この内容は、デバッ
グイベント (予期せぬリソース状態の報告) が発生した場合に専用のログファイルに書き込まれます。このバッファは循環バッファです。つまり、
新しいメッセージの発生により、バッファのオーバーフローが発生しそうになると、保存されているメッセージの最も古いものから1つまた
はそれ以上が上書きされます。この処理はデバッグイベントによってバッファ全体がログファイルに書き出されるまで続き、書き出された時点
でバッファはリセットされます。このため、もっとも新しいメッセージのみがログに記録されます。古いデータは、デバッグイベントが発生した
時点によっては失われている場合があります。
バッファの内容がログファイルに書き出される場合、メッセージは時系列に沿って書き込まれます。注意すべきことは、バッファ内の最新の
メッセージはそのデバッグイベントによって生成されたものですが、バッファ内のそれ以前のメッセージは必ずしも関連したメッセージで
あるとは限らないという点です。ディテクタのログを参照すると、一連の開始メッセージに続いて、デバッグイベントメッセージが現れ、次にまた
別の開始メッセージ、それに続いて別のデバッグイベントメッセージ、という形で記録されていることが分かります。このため、ディテクタ
のデバッグメッセージのすべてについて、検討中の問題と関連しているかどうかを、タイムスタンプと内容を見て確認する必要があります。
ディテクタが生成するメッセージにはすべて詳細レベルが割り当てられており、このレベルが高いとより多くのデバッグ情報が出力されます。
実行時には、ディテクタの現在のログレベルと同じかそれより低いレベルのメッセージのみが内部のバッファに保存されます。各ディテ
クタのログレベルの初期値は1に設定されています。

- 172 -
 注意
あるログレベルで生成される情報の量は、ディテクタのリソースタイプで決まります。高いログレベルが指定されたあるディテクタよりも、低い
レベルが指定された別のディテクタのほうが、出力が多い場合もあります。

F.6.2 ディテクタのログレベルの設定
各リソースディテクタにつき個別のログレベルを、コマンド行、およびRMS Wizard Toolsで設定することができます。

注意
ディテクタのログを開始するには、各ディテクタのログレベルの設定に関係なく、RMSベースモニタのログレベルにレベル2 (ディテクタ履歴)
が含まれている必要があります。デフォルトでは、ベースモニタのログレベルはoffに設定され、ディテクタのログは停止されています。"F.
4 RMS BM (ベースモニタ) ログ出力の管理"を参照してください。

F.6.2.1 hvutil -Lによるディテクタのログレベルの設定

RMSがすでに実行中の場合は、以下のコマンドでディテクタのログレベルを管理します。

hvutil -L display <resource>

hvutil -L <level> <resource>

最初のhvutilコマンドで、指定されたリソースの現在のディテクタログレベルを表示し、2番目のコマンドでログレベルを設定します。

・ <level>を0 (ゼロ) に設定するとリソースのログ採取が停止し、正の数に設定するとそのレベルでログが採取されます。

・ <resource>にはディテクタで監視するリソースの名前を指定します。これは汎用リソースであることが必要です。つまり、タイプが
gResourceであるオブジェクトです。これらのリソースはhvdisp -aで表示することができます。

現在のログレベルは次回hvutil -Lによってログレベルが変更されるか、またはhvutil -l offが発行されるか、RMSが停止されるまで有効です。

F.6.2.2 RMS Wizard Toolsによるログレベルの設定

指定できるログレベルは1から9です。デフォルト値は1です。ログレベルは以下のようにhvwコマンドで変更することができます。

1. [Configuration-Edit-Global-Settings] メニューを選択します
2. [DetectorDetails] サブメニューを選択します。以下の画面が表示されます。

図F.1 RMS Wizard Tools のディテクタ詳細メニュー

3. [MemoryLogLevel] を選択して値を希望するレベルに変更します。ログレベルはすべてのディテクタに適用されます

RMS稼動中のログレベル変更
hvwコマンドを使用して、RMS Wizardディテクタのデバッグレポート機能を動的にオンまたはオフに切替えることができます。

1. [Configuration-Edit-Global-Settings] を選択します。

- 173 -
 2. [DetectorDetails]サブメニューを選択します。
3. [DynamicDetectorLogging] メニュー項目を選択します。
デフォルト値は0 (デバッグ機能はオフ) です。1から9の範囲の値を指定するとデバッグ機能がオンになり、数字が大きいほど情報が詳細
になります。生成されるログメッセージの大きさは、ディテクタによって異なります。したがって、あるディテクタに大きな値を指定した場合でも、
それより小さな値を他のディテクタに指定した場合より生成されるメッセージの数が少ないこともあります。値の変更は、次回構成が活性化
されるまで有効になりません。
動的ログ機能を開始するためhvwを実行すると、実際には<RELIANT_PATH>/etc/wizardloglevelというファイルが作成されます。この
ファイルは、指定したログレベルをASCIIの数値で記録したファイルです。hvwコマンドを使用せずに、直接wizardloglevelファイルを手動で
作成 (削除) することもできます。その場合は以下のルールに従ってください。

・ ファイルが存在しない場合、または、ファイルに0 (ゼロ) が記載されている場合は、デバッグはオフにされます。

・ ファイルが存在しても内容が空の場合は、3が指定されたものと見なされます。
・ ファイルに1から9の数値が記載されている場合は、デバッグがオンになります。

注意
デバッグ機能を有効にするのは、問題が発生した場合に限定してください。問題が解決したらデバッグ機能は必ずオフにして、ファイル
システムに無用な情報が蓄積されるのを防いでください。

F.7 RMSログメッセージの意味
このセクションではRMSのさまざまなコンポーネントが生成するメッセージの形式について説明します。

F.7.1 switchlogメッセージの形式
RELIANT_LOG_PATH/switchlogファイルにはユーザに関係するRMSイベント (切替要求や障害の指摘など) が記録されます。次の5つ
の種類があります。

1. 情報メッセージ (通知)
2. 警告メッセージ
3. エラーメッセージ
4. 致命的エラーメッセージ
5. RMSが実行したスクリプトの出力

通知、警告、エラー、致命的エラー
最初の4つのカテゴリに属するメッセージは、次の形式をとります。

timestamp: (err_code, err_number): msg_type: msg_text: msg_end

メッセージの各フィールドは、後ろにスペースのついたコロン (: ) で区切られています。各フィールドは以下のとおりです。

1. timestampは次の形式です。

yyyy-mm-dd hh:mm:ss.xxx

2. (err_code、err_number) は、そのメッセージを生成した内部コンポーネントを表す2文字または3文字のコードに続けて、そのコン
ポーネントに関する一意のメッセージ番号が記されています。

3. msg_typeは、以下のいずれかです。
－ NOTICE
－ WARNING
－ ERROR

- 174 -
 － FATAL ERROR
4. msg_textはRMS製品が生成するテキストです。1行以上の文字列で構成され、各行の終わりには改行文字が付けられます。
5. msg_endは等号を4つ並べたもので (====) 最後に改行文字が付けられます。先行するmsg_textの最後にも改行文字が付き、その後
ろには区切り記号としてコロンとスペースがあるため、msg_endは、ログファイルでは、独立した1行にコロン、スペース、および4つの
等号が並んでいるように見えます(: ====) 。これにより、行数に関係なく、各メッセージの末尾が簡単に識別できます。

RMS ERRORおよびRMS FATAL ERRORメッセージの一覧 (先頭のtimestampおよびmsg_endフィールドは省略) は、“PRIMECLUSTER

活用ガイド<メッセージ集>”を参照してください。

スクリプトの出力
メッセージの5番目カテゴリであるスクリプトには、定まった形式はありません。これらのメッセージは、RMS構成で定義されたスクリプトによって
生成された標準出力および標準エラーストリームのリダイレクト出力です。先頭のtimestampフィールドおよび末尾のmsg_endフィールドは
通常ありません。
以下に短いスクリプトメッセージの例を示します。

Starting Reliant Monitor Services now

loadcount: 0
loadcount lt 3

F.7.2 アプリケーションログメッセージの形式
RMS Wizard Tools製品によって構成されたアプリケーションおよびリソースは、以下の形式のメッセージを出力します。

resource_name: state: timestamp: msg_type: msg_text: msg_end

メッセージの各フィールドは、後ろにスペースのついたコロン (: ) で区切られていす。各フィールドは以下のとおりです。

1. resource_nameは、スクリプトを実行しているリソースノードの名前です。メッセージと関連するリソースがない場合、このフィールドは空
です。

2. stateは、実行しているアクションのタイプを示します。このフィールドには、RMSによって環境変数HV_SCRIPT_TYPEの値が設定
されます。値は通常、onlineまたはofflineです。値はRMS構成ツールによっても設定されます。PreCheckScriptを実行しているとき
PreCheckになります。DEBUGタイプのメッセージでは、このフィールドが空になります。

3. timestampは、メッセージが生成された日付と時刻です。フィールドの形式はyyyy-mm-dd hh:mm:ss.xxxです。
4. msg_typeは、以下のいずれかです。
－ DEBUG
－ NOTICE
－ WARNING
－ ERROR
－ FATAL ERROR
5. msg_textはRMS Wizard製品が生成するテキストです。このテキストは複数行で構成されることがあるため、途中に改行文字が含ま
れる場合があります。通常このフィールドは改行文字では終了しません。

6. msg_endは等号を4つ並べたものです (====)。msg_textが改行文字で終わらないため、msg_endは同じ行に表示されます。

F.7.3 プログラムログメッセージの形式
RMSは、全体で高可用性管理を実現する多数の独立したプログラムから成り立っています。これらのプログラムはそれぞれ、専用のロ
グファイルにトレースメッセージやエラーメッセージを出力します。ログファイルは以下の場所に格納されています。

RELIANT_LOG_PATH/<program_name>log

たとえば、RMSベースモニタのプログラム名はbmであるため、専用ログファイルはRELIANT_LOG_PATH/bmlogが使用されます。

- 175 -
 プログラムのトレースメッセージやエラーメッセージは内部のトラブルシューティング専用です。ここでは、PRIMECLUSTERのコンサル
タントに情報提供を求められた場合に備え、メッセージの形式を説明します。
トレースメッセージには、以下のプリフィックスが付けられています。

timestamp: file: line:

エラーメッセージには、以下のプリフィックスが付けられています。

timestamp: file: line: ERROR

以下に簡単なトレースメッセージの例を示します。

2005-12-17 14:42:46.256: det_generic.C: 756: Return from GdCheck

2005-12-17 14:42:46.256: det_generic.C: 773: Call to GdGetAttribute
2005-12-17 14:42:46.257: det_generic.C: 775: Return from GdGetAttribute
2005-12-17 14:42:46.257: det_generic.C: 790: reporting state to bm

F.8 RMSログファイルのクリーンアップ
RMSでは、ログファイルの管理について以下の2つの方法を用意しています。

1. hvlogcleanは、経過時間を基準にしてログファイルの削除やバックアップを行います。
2. hvlogcontrolは、システムの空き容量を基準にして警告の表示やログファイルの削除を行います。
いずれのユーティリティも、RMSのインストール時に自動的にインストールされ、デフォルトの設定で構成されます。このセクションでは両者の
機能の概要と管理設定について説明します。

F.8.1 hvlogclean
hvlogcleanユーティリティは現在のログファイルをRELIANT_LOG_PATHのバックアップサブディレクトリに保存します。ディレクトリ名には
RMSが最後に起動した時刻が使用されます。-dオプションを指定して起動すると、現在のログファイルをコピーせずに削除します。いずれの
場合も、hvlogcleanを実行すると、RMSが稼動中であっても新しいログファイルが作成されます。
hvlogcleanはさらに、バックアップサブディレクトリ内の古いファイルを削除します。バックアップファイルが「古い」かどうかは、
RELIANT_LOG_LIFE環境変数の値を確認することによって判定します。バックアップファイル作成の日が変数の値よりも古ければファ
イルは削除されます。詳細については、"RELIANT_LOG_LIFE"を参照してください。

F.8.2 hvlogcontrol
hvlogcontrolユーティリティは、ログファイルによってRELIANT_LOG_PATHが置かれたファイルシステムの空き容量がすべて消費され
てしまうのを防止します。構成定義に設定された上限値に従って、hvlogcontrolは、ユーザへの警告、RELIANT_LOG_PATHのサブディ
レクトリのみの削除、または、すべてのRMSログファイルの削除ができます。詳細については、以下のRMS環境変数に関する説明を参照
してください。

・ "HV_LOG_ACTION_THRESHOLD" (グローバル)
・ "HV_LOG_WARN_THRESHOLD" (グローバル)
・ "HV_LOG_ACTION" (ローカル)
これらのコントロールを変更するには、hvenv.localファイルを編集し、RMSを再起動する必要があります。"E.1 RMS環境変数の設定" を参
照してください。

注意
hvlogcontrolはcrontabファイルから定期的に起動されます。マニュアルページはありません。

- 176 -
F.8.3 バックグラウンドスクリプトのログ採取
Command Lineサブアプリケーションは、バックグラウンドで動作する別のコマンドやスクリプトを実行するスクリプトを起動することができます。
バックグラウンドプロセスがstdoutまたはstderrに書き込みをする場合、その出力はログファイルにダイレクトされ、ログファイルはプロセスが
正常終了するか終了させられるまでオープンされたままです。これにより、そのログファイルはRMSログファイルがcronジョブまたは
hvlogcleanによってクリーンされる時とは異なる方法で処理されます。
hvlogcleanは、クリーンアップを行う際に古いログファイルをバックアップディレクトリに移動します。このバックアップディレクトリ名にはRMSが
最後に起動された時間が使用されています。バックグラウンドプロセス用のログファイルも、オープンされた状態でそこに移されます。バッ
クグラウンドのプロセスは、オープンされたファイルへの書き込みを継続するため、その後の出力はファイルの移動先であるバックアップ
ディレクトリに保存され、/var/opt/reliant/logには保存されません。RMSの残りのプロセスも同様です。
プロセスの実行中にバックグラウンドプロセスのログファイルが削除された場合(手動またはhvlogclean -dコマンドなど)、そのログファイル
はそれ以後参照することはできません。ただし、ファイルは引き続き存在しているため、バックグラウンドプロセスは、正常終了するか途中で
停止されるまで、表示ができなくなったファイルに書き込みを継続します。

F.9 RMSトラブルシューティング
問題が発生した場合、RMSはトラブルシューティングのための情報を含んだエラーメッセージを出力します。メッセージが何も出力されない
場合は、問題の診断と修正に以下の方法を試してください。

・ RMSが起動直後に停止する。
・ RMS BMは、起動時にリモートノード上の他のBMと構成チェックサムを交換します。BM起動時のチェックサムがリモートノードのチェッ
クサムと一致すれば、起動処理は続行します。チェックサムが不一致の場合、以下のすべての条件が当てはまるときにRMS BMは
シャットダウンします。

1. 初期起動時間 (HV_CHECKSUM_INTERVALに設定される) 内のBMのチェックサムがリモートモニタのチェックサムと異なる。

2. ノードにOnline、待機中、ビジー、またはロック中のアプリケーションが存在しない。
3. このBMがOnline状態のリモートBMを検出できない。
または、BMが稼動中であっても、チェックサムがローカル構成チェックサムと一致しないすべてのリモートモニタはOfflineと判断
されるため、これらのモニタとメッセージを交換することはできず、ローカルモニタとこれらのリモートモニタとを自動または手動に
より切替えることができません。

チェックサムが異なる場合、状況を説明するメッセージがswitchlogに出力されます。

注意
構成チェックサムの不一致は主に、手動でRMSグローバル環境変数を変更する際に、一部のノードについてだけ変更し、残りを変更
しなかった場合に発生します。

対処法:
構成チェックサムの不一致が発生している場合は、以下の手順に従ってすべてのノードの構成定義を正しく更新してください。

1. クラスタ内の全RMSを停止する。
2. どの構成定義ファイルを使用するかを決定する。構成定義ファイル名を確認するには、それぞれのノードで 'hvdisp -a' または
'hvdisp -T SysNode' を実行します(hvdispコマンドの実行には、ルート権限は必要ありません)。
以下のいずれかの場合は、構成定義ファイルの名前は同じでも、内容はそれぞれのノードで異なる場合がありますので、正しい
構成定義ファイルを選択してください。

- 前回のRMS構成定義の配布が失敗した場合
- RMS Wizards Toolsがクラスタ内の複数ノードで使用された場合
3. 正しい構成定義ファイルを、作成に使用したものと同じツール (RMS Wizard Tools) を使用して配布する。手順については "3.4
RMS構成定義ファイルの作成と配布" を参照してください。
または、既存の<configname>.usファイルを以下の方法で再配布します。

- 177 -
 - RMS Wizard Toolsの [Configuration Push]
すべてのノードへRMSの配布が成功したことを確認してください。

4. クラスタ全ノードでRMSを起動してください。
・ RMSが起動後にハングする (プロセスは実行中だが、hvdispがハングする) 。
ローカルノードがクラスタ内の1つ以上の他のノードから見てCFのLEFTCLUSTER状態の場合に、この問題が発生します。
対処法:
すべてのクラスタノード上で「cftool -n」を呼び出してLEFTCLUSTER状態をチェックすることにより、この問題を確認してください。
「cftool -k」を呼び出してLEFTCLUSTER状態をクリアしてください。ノードがクラスタに参入するとすぐに、RMSは稼動し続けます。再
起動する必要はありません。

・ RMSが起動直後にループする (停止する場合もある)。
CIP構成定義ファイル/etc/cip.cfにネットマスクのエントリが含まれている場合に、この問題が発生します。これらのエントリは必要あり
ません (CIPによって評価されません)。ネットマスクは、IPアドレスとフォーマットが同じためRMSからは区別できません。このため、ネッ
トマスクのエントリがあると、RMSはgethostbyaddr()の呼び出しを行います。通常は実害が発生することはありませんが、稀にOSが誤
動作する可能性があります。
対処法:
ネットマスクのエントリが/etc/cip.cfに存在することを調べてください。
ネットマスクのエントリを削除して、RMSを再起動してください。

・ 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 状態のノードを停止せずに本コマンドを実行した
場合、データが破損する可能性があります。

・ RMSベースモニタが、 クラスタのハートビートの喪失を検出しましたが、原因の手がかりがない。
この場合、システム管理者は以下のような情報採取を行ってください。

1. truss(1)、またはstrace(1) を使ってディテクタプロセスのログを採取する。
2. RMSとディテクタロギングを「l0 (小文字のエルとゼロ)」にする。
3. システム動作情報を採取する。
truss(1)/strace(1) の呼び出しとログレベルは、ScriptTimeout属性に指定された秒数が経過すると解除されます。すべての情報は、
switchlogファイルに保存されます。
ディテクタ履歴などのユーザの指定による操作は、ノードがクラスタを離脱したように見えていても、引き続き各ノードで実行されています。
履歴レベルを高く設定すると、ノードの性能に影響が生じ、ベースモニタのハートビートの遅れが発生する場合もあります。
対処法:
診断情報については、switchlogを参照してください。

- 178 -
F.10 高度なトラブルシューティングのための情報収集
このセクションで説明する手順は高度なデバッグ情報の収集の方法で、コンサルタントや開発者を対象にしています。

F.10.1 hvdumpコマンドの使用 (RMS)

hvdumpコマンドは、ローカルノードのRMSのデバッグ情報を取得する場合に使用します。RMSをインストールすると以下のファイルが作成
されます。

RELIANT_PATH/bin/hvdump

デフォルトでは、RELIANT_PATHは/opt/SMAW/SMAWRrmsに設定されています。このファイルのシンボリックリンクも/usr/bin/hvdump
(通常はデフォルトの検索パス) および/opt/SMAW/bin/hvdumpに作成されます。
hvdumpを実行すると、ログファイルと構成データを検索し、RELIANT_PATH ディレクトリの以下のアーカイブに保存します。

<nodename>RMS.<timestamp>.debug_information.tar.<suf>

サフィックス<suf>はLinuxプラットフォームではgz、SolarisプラットフォームではZです。
アーカイブファイルはRMSのサポート技術者が使用することを目的としています。hvdump(1M) のマニュアルページには、ファイル名と
アーカイブに含まれる情報の詳細なリストが記載されています。

F.11 SNMPリソース異常通知
リソース異常が発生した場合に、SNMPマネージャが動作するサーバへSNMP Trap を送信できます。
本機能を用いることで、SNMPマネージャによりクラスタシステムを監視できます。
本機能の設定方法の詳細については、"PRIMECLUSTER 導入運用手引書 (Linux)" の "6.10.1 クラスタアプリケーションの設定内容" を
参照してください。
SNMP Trap はバージョン2cが使用され、送信するSNMP Trapには以下の情報が含まれます。

・ リソース種別に応じたOID
・ リソース異常検出時のメッセージ
SNMP Trapの送信には、snmptrapコマンドが使用され、以下が実行されます。

snmptrap -v 2c -c <コミュニティ名> <送信先ホスト> .1.3.6.1.4.1.211.4.68.257 <OID> s <メッセージ本文>

SNMP Trapに設定されるOIDは以下の通りです。

表F.3 SNMP Trapに設定されるOID

No OID
1 .1.3.6.1.4.1.211.4.68.257.1
2 .1.3.6.1.4.1.211.4.68.257.2
3 .1.3.6.1.4.1.211.4.68.257.3
4 .1.3.6.1.4.1.211.4.68.257.4
説明
アプリケーションやミドルウェアのリソースで異常が発生した場合に設定されるOID
です。
Cmdline リソース、プロシジャリソース、または、ミドルウェアのリソースで異常を検出
した場合に設定されます。
ネットワークの異常が発生した場合に設定されるOIDです。Glsリソース、または、引
継ぎネットワークリソースで異常を検出した場合に設定されます。
ファイルシステムの異常を検出した場合に設定されるOIDです。Fsystemリソースで
異常を検出した場合に設定されます。
ディスクの異常を検出した場合に設定されるOIDです。Gdsリソースで異常を検出
した場合に設定されます。

「リソース異常検出時のメッセージ」には、リソース異常検出時にRMSがswitchlogへ出力したメッセージが格納されています。このメッセー
ジの内容から、どのリソースで、どのような異常を検出したのかを確認できます。
含まれるメッセージの例:

- 179 -
2014-07-28 17:07:09.254:(DET, 7): ERROR: FAULT REASON: Resource <ManageProgram000_Cmd_APP1> transitioned to a Faulted
state due to the resource unexpectedly becoming Offline.

また、メッセージ本文を“PRIMECLUSTER 活用ガイド<メッセージ集>” 内で探すことで、原因と対処方法を確認することができます。

注意

・ クラスタノードからSNMPマネージャが動作するホストまでの通信経路上で異常が発生した場合、SNMP Trapで異常を通知すること
はできません。

・ 1つのクラスタアプリケーションにて複数のリソースの異常を同時に検出して、クラスタアプリケーションの切替えが発生した場合、そのうち
1つのリソース異常のメッセージを通知します。このため、リソース異常の対処をクラスタノード上で実施後、他の異常が発生していな
いかをswitchlogで確認してください。

- 180 -
付録G RMSコマンドラインインタフェース
RMS構成設定の中心的なインタフェースはRMS Wizard Toolsであり、RMS管理の中心的なインタフェースはCluster Admin GUIです。
RMS Wizard ToolsとCluster Admin GUIのユーザインタフェースは、内部でRMS CLIを呼び出しています。条件によってはCLIを直接起動
するほうが便利なこともあります。
次のセクションでは、管理者が使用可能なRMS CLIコマンドの一覧を示します。これらのコマンドの使用法については、"第7章 RMSの操
作"でいくつか説明されています。RMS に関連するすべてのPRIMECLUSTERコマンドについては、"PRIMECLUSTER 活用ガイド＜コ
マンドリファレンス編＞" を参照してください。

注意
通常、RMS CLIコマンドの実行にはルート権限が必要です。ルート権限が不要な場合を以下の表に示します。

G.1 使用可能なRMS CLIコマンド

hvassert
hvassertコマンドは特定のオブジェクト状態のRMSオブジェクトをテストします。このコマンドをスクリプトに使用して、次のコマンドを発行
する前に一定の状態を設定することができます。ルート権限は必要ありません。
hvcm
hvcm コマンドは、すべての監視オブジェクトに対するディテクタとベースモニタを起動します。ほとんどの場合、hvcmコマンドのオプ
ションを指定する必要はありません。ベースモニタはRMSモジュールの意思決定の役割を果たします。ベースモニタはすべてのRMS
オブジェクトの設定およびアクセスを制御します。オブジェクトが失敗すると、ベースモニタは失敗を分析し、構成定義ファイルに指定
されているオブジェクト仕様に従って適切な措置をとります。
hvconfig
hvconfigコマンドには、現在のRMS構成定義情報を表示する、または現在のRMS構成定義情報を出力ファイルに出力する、という2
つの機能があります。hvconfigコマンドの出力内容は使用中のRMS構成定義ファイルの内容と基本的に同じですが、元のファイルに
記述されているコメントは出力されません。また、リソース一覧の出力順序は構成定義ファイルと異なる場合があります。
hvdisp
hvdispコマンドを実行すると、RMSオブジェクトの現在のRMS構成情報が表示されます。ルート権限は必要ありません。
hvdispall
hvdispallコマンドを実行すると、 RMSの全ノードのリソース情報が表示されます。
hvdump
hvdumpコマンドは、ローカルノードのRMSの調査情報を取得する場合に使用します。
hvlogclean
hvlogcleanコマンドを実行すると、古いログファイルがサブディレクトリに保存されます。ログファイルの名前はRMSを最後に起動した時刻
です (-dオプションを指定すると、古いログファイルが削除されます)。hvlogcleanを実行すると、RMSが稼動中であっても新しいログ
ファイルが作成されます。
hvreset
hvresetコマンドは、そのRMS構成におけるノード上のRMSユーザ業務のグラフを再初期化します。実行中のスクリプトは終了され、処
理中の要求はクリアされ、以前の障害情報は消去されます。プロセスが成功すると、グラフ全体が初期の整合状態に戻されますが、不
整合の状態になる場合もあります。このため、このコマンドはテスト目的でのみ使用し、本番のクラスタシステムでは実行しないでください。

注意
このコマンドは上級者向けです。

- 181 -
hvsetenv
ローカルノード上で以下のRMS環境変数を変更するインタフェースを提供します。

－ HV_RCSTART : RMSの自動起動を制御する
－ HV_AUTOSTARTUP : すべてのアプリケーションの自動起動を制御する
HV_RCSTARTとHV_AUTOSTARTUPの詳細については、"付録E 環境変数" を参照してください。
hvshut
hvshutコマンドは、1つ以上のノード上でRMSを停止します。ローカルノード上のベースモニタは、どのノードが停止されるかを伝え
るメッセージを他のOnlineノードに送信します。
hvswitch
hvswitchコマンドは、userApplication または gResourceの制御を RMS構成内のシステムノード (SysNode) 間で手動で切替えます。
hvutil
hvutilコマンドは、RMSに対する汎用のインタフェースです。以下の管理操作を実行します。

－ ログレベルの動的設定
－ userApplicationのOffline
－ 障害が発生したリソースのクリア
－ Wait状態にあるクラスタノードの停止
－ ディテクタの監視間隔設定
－ 保守モードの設定、その他

注意
vutil で高いログレベルを設定し、長期間ログを有効にしておくと、ディスク容量が足りなくなる場合があります。詳細については、 "F.
4.1 RMS BM (ベースモニタ) ログレベルの管理" を参照してください。

- 182 -
付録H リリース情報
本章では、本マニュアルの主な変更箇所について説明します。

項番 版数 変更箇所 内容
1 2版 3.3.2.1 RMS停止中のメイン構成メ メイン構成メニューについての注意事項を追加しました。
ニューウィンドウ
2 2版 7.1.3 RMSの停止 RMSを停止する場合の注意事項を追加しました。
3 2版 7.2.1 アプリケーションの自動起動の アプリケーションを自動起動する場合の説明を変更しました。
オーバーライド
4 2版 D.1 ユーザ設定属性 以下のユーザ設定属性の説明を変更しました。
・AutoStartUp
・OnlinePriority
・PartialCluster
5 2版 E.2 RMSグローバル環境変数 HV_AUTOSTART_WAITの説明を変更しました。
6 2版 付録F トラブルシューティング 「構成のトラブルシューティング」の説明を削除しました。
7 3版 2.3.2.1 スケーラブルアプリケーション データベースサーバの説明を変更しました。
8 3版 3.3.4 必須設定と選択設定 選択設定メニュー画面を変更しました。
9 3版 3.5.3 RMSオブジェクト コントローラの説明を変更しました。
10 3版 A.3 ファイルシステム (Linux) NFS に関する説明を削除しました。
11 3版 D.1 ユーザ設定属性 MonitorOnly 属性の説明を変更しました。
12 3版 E.3 RMS ローカル環境変数 以下のRMSローカル環境変数を追加しました。
・HV_VM_ENABLE_IP_ADVERTISE
・HV_VM_IP_ADVERTISE_COUNT

- 183 -
用語集
AC (アクセスクライアント (Access Client))
アクセスクライアントを参照。

API (アプリケーションプログラムインタフェース (application program interface))

アプリケーションプログラムインタフェースを参照。

BM (ベースモニタ (base monitor)) (RMS)

RMSの中心となるリソースの可用性を管理するモジュールプロセス。BM (ベースモニタ) はデーモンとディテクタから構成され、RMSが
管理するオブジェクトの状態変更の調整/制御を行う。監視中のRMSオブジェクトに異常が発生した場合には、構成定義に従ってリ
カバリ処理 (ローカルリカバリまたはリモートリカバリ) を実行する。

Cache Fusion
Oracle 9iで改良されたプロセス間通信インタフェース。論理ディスクブロック (バッファ) を更新する際、各ノードのローカルメモリ上に
キャッシュされているブロックをディスクにフラッシュするかわりに、インタコネクト経由で、ブロックを他のノードにコピーすることで、物理I/O
のオーバーヘッドをなくし、処理を高速化することができる。

CCBR (Solaris)
クラスタ構成のバックアップおよびリストア（Solarisのみ）を参照。

ccbr.conf
/opt/SMAW/ccbr ディレクトリに配置されるバックアップ/リストア用の環境設定ファイル。 $CCBRHOME 変数の設定などに使用する。
詳細は、cfbackup(1M)コマンドおよび cfrestore(1M)コマンドのマニュアルページおよび ccbr.conf ファイル内のコメントを参照。

ccbr.gen
/opt/SMAW/ccbr ディレクトリに配置される世代数を格納するためのファイル。 0 以上の値が格納される。 詳細は、cfbackup(1M)コ
マンドおよび cfrestore(1M)コマンドのマニュアルページを参照。

CCBRHOME変数
バックアップデータが格納されるディレクトリを示す。初期値は /var/spool/SMAW/SMAWccbr ディレクトリになる。 この変数は、ccbr.conf
ファイルでのみ設定可能。

CF (Cluster FoundationまたはCluster Framework)

Cluster Foundationを参照。

CIM
クラスタ整合性モニタ (Cluster Integrity Monitor)

CIP
クラスタインタコネクトプロトコル (Cluster Interconnect Protocol)

CLI
コマンドラインインタフェース (command-line interface)

CLM
Cluster Manager

Cluster Foundation
基本的なクラスタリング通信サービスを提供するPRIMECLUSTERモジュールの集まり。

- 184 -
 関連項目 クラスタ基盤 (CF)

CRM
クラスタリソース管理 (Cluster Resource Management)

DLPI
Data Link Provider Interface

DHCP
Dynamic Host Control Protocol。起動時にノードに対して情報を送信するための標準的な方法。典型的な用途は、ノードのIPアドレ
スおよびネットマスクの動的割り当てであるが、ドメイン名、DNSサーバ、およびタイムサーバなどのパラメタ割り当てもできる。

DOWN (CF)
ノードが使用不可であることを示すノード状態 (DOWN状態と呼ぶ)。LEFTCLUSTER状態のノードをクラスタに再参入させるためには、
事前にそのノードの状態をDOWNに変更する必要がある。
関連項目 UP (CF)、LEFTCLUSTER (CF)、ノード状態 (CF)

EE
Enterprise Edition

ELM (Enhanced Lock Manager) (CF)

軽量、高性能、高速応答のロックマネージャ。

ENS (イベント通知サービス (Event Notification Services)) (CF)

イベント通知サービス (CF)を参照。

GFS 共用ファイルシステム
GFS 共用ファイルシステムは、共用ディスク装置を接続した複数の Solarisから一貫性/整合性を保った同時アクセスが可能であり、一部
のノードがダウンしても、他のノードは処理を継続できることを特長とする共用ファイルシステムです。 GFS共用ファイルシステムは、複数
のノードから同時にマウントして使用できます。

GDS (Global Disk Services)

ディスク装置に格納されたデータの可用性と運用管理性を向上させるためのボリューム管理機能を提供するサービス。

GFS (Global File Services)

クラスタ内の2つ以上のノードから共有記憶ユニットのファイルシステムの直接、同時アクセス機能を提供するサービス。

GLS (Global Link Services)

ネットワーク伝送路を冗長化することにより、ネットワークの高可用性を実現するサービス。

GUI (グラフィカルユーザインタフェース (graphical user interface))

グラフィカルユーザインタフェースを参照。

HA
高可用性 (high availability)

ICF
ノード間通信機構 (Internode Communication Facility)

- 185 -
IPMI (Intelligent Platform Management Interface)
コンピュータの監視や管理を行うための共通インタフェースのファームウェアおよびハードウェア仕様。IPMIは、対象マシンにオンボー
ドで搭載されたBaseboard Management Controller(BMC)を通じて動作。OSとは別に動作するため、対象マシンの電源が入っていない
場合にも遠隔管理ができる。

I/F
インタフェース(Interface)

I/O
入出力 (input/output)

IPアドレス
インターネットプロトコルアドレスを参照。

IPエイリアス
1つの物理ネットワークインタフェースに複数のIPアドレス (エイリアス) を割り当てる機能。IPエイリアスにより、他のノードでアプリケー
ションを実行する場合にも同じIPアドレスで通信を続けることができる。
関連項目 インターネットプロトコルアドレス

iRMC (integrated Remote Management Controller)

PRIMEQUEST/PRIMERGYに搭載されるハードウェアの1つである integrated Remote Management Controllerの略称。

JOIN (クラスタ参入サービスモジュール (cluster join services module) (CF)

クラスタ参入サービス (CF)を参照。

LAN (ローカルエリアネットワーク (local area network))

業務LANを参照。

LEFTCLUSTER (CF)
ノードが同じクラスタにある他のノードと通信できないことを示すノード状態。ノードがクラスタを離れていることになる。LEFTCLUSTER
という中間状態は、ネットワークパーティションの問題を防ぐために設けられている。
関連項目 UP (CF)、DHCP、ネットワークパーティション (CF)、ノード状態 (CF)

MA
非同期監視 (Monitoring Agent)

MACアドレス
MAC address。ローカルエリアネットワーク (LAN) のMAC副層で用いられる局、あるいはノードを示すアドレス。

MDS (メタデータサーバ (Meta Data Server))

メタデータサーバを参照。

MIB (Management Information Base)

ローカルネットワークデバイスの情報を格納した階層データベース。このデータベースは、SNMPエージェントなどのネットワーク管理ソ
フトウェアで保守される。

MIPC
Mesh Interprocessor Communication

- 186 -
MMB (Management Board)
PRIMEQUESTに搭載されるハードウェアの1つであるManagement Boardの略称。

NIC
ネットワークインタフェースカード (network interface card)

NIC切替方式
GLSが提供するLAN二重化方式の1つ。二重化したNICを排他使用し、サーバとスイッチングHUB間のLAN監視と異常検出時の切替
えを実現する。

NSM
Node State Monitor

OPS (Oracleパラレルサーバ (Oracle Parallel Server))

Oracleパラレルサーバを参照。

Oracleパラレルサーバ
Oracleパラレルサーバは、クラスタ化されたプラットフォームまたはMPP (massively parallel processing) プラットフォームのユーザお
よびアプリケーションにデータベースのすべてのデータへのアクセス機能を提供する。

OSD (オペレーティングシステム依存 (operating system dependant)) (CF)

オペレーティングシステム依存 (CF)を参照。

PAS
Parallel Application Services

PRIMECLUSTERサービス (CF)
クラスタ化アプリケーションにサービス、および内部インタフェースを提供するサービスモジュール。

PS
パラレルサーバ (Parallel Server)

RAO
RMS-Add on

RCCU (リモートコンソール接続装置 (Remote Console Connection Unit))

リモートコンソール接続装置 (Remote Console Connection Unit) の略称。
関連項目 リモートコンソール接続装置

RCI
Remote Cabinet Interface

Reliant Monitor Services (RMS)

監視、および切替機能によりユーザが指定したリソースの高可用性を維持するサービス。

RMS (Reliant Monitor Services)

Reliant Monitor Services (RMS)を参照。

- 187 -
RMS Wizard Kit
RMS Wizard Kitの各コンポーネントは、特定のアプリケーション (Oracle, Networker) のRMSウィザードツールに新しいメニュー項目を
追加する。
関連項目 RMS Wizard Tools、 Reliant Monitor Services (RMS)、 RMSウィザード

RMS Wizard Tools

RMS構成のアプリケーションの作成および管理に使用する各種設定、および管理ツールで構成されるソフトウェアパッケージ。RMS
ウィザードの基盤および、BM (ベースモニタ) とのインタフェースを提供する。
関連項目 RMS Wizard Kit、RCCU (リモートコンソール接続装置 (Remote Console Connection Unit))

RMSウィザード
RMSが動作するための構成定義を作成するためのソフトウェアツール。RMSウィザードは、RMS Wizard ToolsとRMS Wizard Kitの2
つによって構成されている。
関連項目 RMS Wizard Tools、 RMS Wizard Kit

RMS構成
複数のノードを共用リソースに接続する構成。各ノードはオペレーティングシステム、RMSソフトウェア、固有アプリケーションのコピーを
固有に保持する。

RMSコマンド
RMSリソースをコマンドラインから管理するコマンド。

SA
シャットダウンエージェント (Shutdown Agent)

SAN (Storage Area Network)

Storage Area Networkを参照。

SC
拡張性クラスタ (Scalability Cluster)

Scalable Internet Services (SIS)

Scalable Internet ServicesのTCP接続は、各接続の通常のクライアント/サーバセッションを維持しながらクラスタノード間のネットワー
クアクセス負荷を動的に分散する。

SCF
システム監視機構 (System Control Facility)

SCON (シングルコンソールソフトウェア (single console software))

シングルコンソールを参照。

SD
シャットダウンデーモン (Shutdown Daemon)

SDXオブジェクト (GDS)
クラス、グループ、SDXディスク、ボリュームなど、GDSが管理する資源の総称。

- 188 -
SDXディスク (GDS)
GDSが管理しているディスクの総称。SDXディスクは、用途に応じてシングルディスク、キープディスク、スペアディスク、および未定義
ディスクと呼ばれる場合があります。SDXディスクを単に「ディスク」と呼ぶ場合もあります。

SF
シャットダウン機構 (Shutdown Facility)

SIS (Scalable Internet Services)

Scalable Internet Services (SIS)を参照。

SNMP(Simple Network Management Protocol)

管理対象ネットワークデバイス間で情報の通信を行うためのプロトコル。このプロトコルは、デバイスに常駐するソフトウェアエージェ
ントによって実装される。それぞれのエージェントは、ネットワーク上の他のデバイスからのSNMP要求に対応して、ローカルの
MIB(Management Information Base)データを読み書きすることができる。

Storage Area Network

複数の外部記憶装置どうしを接続し、複数のコンピュータに接続する高速ネットワーク。通常はファイバチャネルの接続。

UP (CF)
ノードが同じクラスタにある他のノードと通信できることを示すノード状態。
関連項目 DHCP、LEFTCLUSTER (CF)、ノード状態 (CF)

VIP
仮想インタフェース (Virtual Interface Provider)

Web-Based Admin View

PRIMECLUSTERのグラフィックユーザインタフェースを活用するための共通基盤。インタフェースはJavaで記述されている。

WK (Wizard Kit)
RMS Wizard Kitを参照。

WT
Wizard Tools

XSCF (eXtended System Control Facility)

eXtended System Control Facilityの略。本体装置のCPUとは独立した専用プロセッサで構成されているシステム監視機構。冷却部
(FANユニット)、電源ユニット、システム状態監視、周辺装置の電源投入／切断、異常監視を一括して制御する。さらに、遠隔地からの
本体装置の管理を可能にするためにシリアルポートまたはイーサネット接続経由で、本体装置をモニタする機能、故障情報をシステム
管理者に通報する機能、コンソール入出力機能を兼ね備えている。

アクセスクライアント
各ノード上のGFSカーネルモジュール。メタデータサーバと通信し、共用ファイルシステムへの同時アクセス機能を提供する。
関連項目 メタデータサーバ

アプリケーション (RMS)
RMSにおいて、アプリケーションオブジェクトとは、他のオブジェクトを論理集合にまとめるためのリソースのこと。通常は、実際のアプ
リケーションソフトウェアや、高可用性構成のアプリケーションスイートを表すために使用される。

- 189 -
アプリケーションテンプレート (RMS)
定義済みのオブジェクト定義の値の集まり。RMS Wizard Kitで特定タイプのクラスタアプリケーションのオブジェクト定義を作成する際に
使用される。

アプリケーションプログラムインタフェース
アプリケーションが、OSなどのサービスプロバイダが提供するサービスを利用する際に使うインタフェース。

イーサネット
IEEE802.3にて標準化されたLAN規格。現在、特殊な用途を除いて、ほとんどの LANはイーサネットである。なお、イーサネットという
表現は元々10メガバイト /秒タイプのLAN規格の名称であるが、現在は高速イーサネット/ギガバイトイーサネットをも含んだ総称としても
用いられる。

イベント通知サービス (CF)
クラスタ内で発生したイベントをノード間にブロードキャストする機能を提供するPRIMECLUSTERモジュール。

インストールサーバ
ネットワークを通じてクライアントマシンにオペレーティングシステムをインストールできるための設定を施したサーバ。

インターネットプロトコルアドレス
コンピュータまたはアプリケーションに割り当てられる数値アドレス。
関連項目 IPエイリアス

インタコネクト (CF)
クラスタインタコネクト (CF)を参照。

ウィザード (RMS)
テスト済みのオブジェクト定義を使って特定タイプのアプリケーションを作成するインタラクティブなソフトウェアツール。

ウォッチドックタイマ監視
OSハングやブート異常を監視するタイマ値。

エラー検出 (RMS)
エラーを検出するプロセス。RMSでは、ログの記録開始、ログファイルへのメッセージ送信、リカバリ処理の実行などを行う。

応答待ち時間 (レイテンシ)
データの送信要求を行ってから、実際に応答を受信するまでの時間間隔。

オブジェクト (RMS)
構成定義ファイルまたはシステムグラフでは、ノードは物理または仮想リソースを示す。
関連項目 リーフオブジェクト (RMS)、 オブジェクト定義 (RMS)、 ノード状態 (CF)、 オブジェクトタイプ (RMS)

オブジェクトタイプ (RMS)
ディスクドライブなど監視される同種のリソースをグループ化するカテゴリ。各オブジェクトタイプにはプロパティと呼ばれる固有の属性
があり、この属性により実行する監視またはアクションの種類を限定または定義する。リソースを特定のオブジェクトタイプに関連付けると、
関連付けたオブジェクトタイプの属性がリソースに適用される。
関連項目 汎用タイプ (RMS)

- 190 -
オブジェクト定義 (RMS)
RMSの監視対象となるリソースを識別する構成定義ファイルのエントリ。定義された属性により、関連するリソースのプロパティが指定さ
れる。オブジェクト定義に関連するキーワードにobjectがある。
関連項目 オブジェクト (RMS)、オブジェクトタイプ (RMS)

オペレーティングシステム依存 (CF)
オペレーティングシステム本体と、OS非依存のPRIMECLUSTERモジュールとの間のインタフェースを提供するモジュール。

オペレーティングシステム本体
オペレーティングシステムのうち、常にアクティブでシステムコールを実際の処理に変換している部分。

親 (RMS)
1つ以上の子オブジェクトを保持する、構成定義ファイルまたはシステムグラフのオブジェクト。
関連項目 子 (RMS)、 構成定義ファイル (RMS)、 サブアプリケーション (RMS)

オンラインメンテナンス
ホストのシャットダウンや電源オフの必要なく機器を追加、削除、または交換できる機能。

回線切替装置(Oracle Solaris 10環境のみ)

外部からの回線を複数ノードの間に接続して、RCIにより接続ノードの切替えを行う装置。

下位グループ (GDS)
他のグループに属しているグループ。下位グループにはボリュームを作成できません。

拡張性
作業負荷の増加に動的に対処するコンピューティングシステムの機能。拡張性は、特にインターネットベースのアプリケーションにおいて、
インターネットの使用量の増大に伴って重要になる。

カスタムタイプ (RMS)
汎用タイプ (RMS)を参照。

カスタムディテクタ (RMS)
ディテクタ (RMS)を参照。

仮想インタフェース (VIP)
クラスタの複数ノードをシングルシステムイメージとして見せるために、SISが使用する仮想的なIPアドレスまたはノード名。

仮想ディスク
仮想ディスクでは、Solaris論理I/Oシステムの最上位と物理デバイスドライバとの間に擬似デバイスドライバが追加される。擬似デバ
イスドライバはすべての論理I/O要求を物理ディスク上にマップする (富士通テクノロジー・ソリューションズ製品から移行のお客様のみ)。
関連項目 連結仮想ディスク、ミラー仮想ディスク(VM)、単独仮想ディスク、ストライプ化仮想ディスク

可用性
多くの企業が必要とする、インターネットによる24時間年中無休のアプリケーション稼動環境の達成度を示す指標。実際と計画の使
用時間の比較によってシステムの可用性が決まる。

環境変数 (RMS)
グローバルに定義された変数またはパラメタ。

- 191 -
管理LAN
PRIMECLUSTERの構成における、システムコンソールやクラスタコンソールなどが接続されたプライベートローカルエリアネットワーク
(LAN)。管理LANには、一般ユーザがアクセスできないため、非常に高いレベルのセキュリティを確保できる。管理LANを使用する
かどうかは選択可能。
関連項目 業務LAN

キーワード (予約語)
プログラミング言語において、ある特別な意味を持つ用語。たとえば、構成定義ファイルのnodeキーワードは、後に続く定義の種類を
指定する。

キュー
メッセージキューを参照。

業務LAN
一般ユーザがマシンにアクセスするためのローカルエリアネットワーク (LAN)。
関連項目 管理LAN

共用ディスク接続確認
ノード起動時に共用ディスク装置の電源投入漏れやケーブルの結線誤りがないことを確認する機能。

共用リソース
複数ノード間で共有されるディスクドライブなどのリソース。
関連項目 専用リソース (RMS)、 リソース (RMS)

切替え (RMS)
userApplicationの制御を監視対象の1つのノードから他のノードに切替えるRMSのプロセス。
関連項目 自動切替え (RMS)、指定切替え (RMS)、フェイルオーバ (RMS、SIS)、対称切替え (RMS)

切替方式
GLSが提供するLAN二重化の方式名。高速切替方式、NIC切替方式、GS/SURE連携方式 (Solaris)、GS連携方式 (Linux)、仮想NIC
方式、マルチパス方式 (Solaris)が存在する。

クラス (GDS)
ディスククラス (GDS)を参照。

クラスタ
1つのコンピューティングソースに統合されるコンピュータの集まり。クラスタは分散型のパラレルコンピューティングを実行する。
関連項目 RMS構成

クラスタアプリケーション (RMS)
RMSのリソース定義において、userApplicationに分類されるリソース。複数のリソースをアプリケーション単位にグループ化する際に使用
される。

クラスタインタコネクト (CF)
PRIMECLUSTERがノード間の通信処理で専用に使用するネットワーク接続。

クラスタ基盤 (CF)
基本OSの上位で動作するPRIMECLUSTERの基本モジュール。PRIMECLUSTERの上位サービスが使用する機能をCF(Cluster
Foundation)インタフェースとして提供する。

- 192 -
 関連項目 Cluster Foundation

クラスタ構成のバックアップおよびリストア（Solarisのみ）
CCBRを使用すると、あるクラスタノードについて現在のPRIMECLUSTER構成情報を簡単に保存することができる。また、構成情報を
リストアすることもできる。

クラスタ参入サービス (CF)
新規クラスタの作成およびクラスタへのノードの追加を処理するPRIMECLUSTERサービス。

クラスタ整合状態 (クォーラム)
クラスタシステムを構成するノード間の整合性が保たれている状態。具体的には、クラスタシステムを構成する、各ノードのCFの状態がUP
またはDOWNである状態 (LEFTCLUSTERとなっているノードが存在しない)。

クラスタリソース管理機構
複数のノード間で共用されるハードウェアを管理する機構。

グラフ (RMS)
サブアプリケーション (RMS)を参照。

グラフィカルユーザインタフェース
ウィンドウ、アイコン、ツールバー、プルダウンメニューを使った、コマンドラインインタフェースより使いやすいコンピュータインタフェース。

グループ (GDS)
ディスクグループ (GDS)を参照。

経路
"PRIMECLUSTERコンセプトガイド" では、ノードとノードの間を接続する冗長化されたクラスタインタコネクトの各々のネットワーク経路を
意味している。

ゲートウェイクラスタノード (SIS)
ゲートウェイクラスタノードは外部ネットワークインタフェースを有し、すべての受信パッケージはこのノードで受信され、サービスのス
ケジューリングアルゴリズムに従って選択したサービスノードに転送される。
関連項目 サービス提供ノード (SIS)、データベースノード (SIS)、Scalable Internet Services (SIS)

子 (RMS)
1つ以上の親に属し、構成定義ファイルに定義されるリソース。子は複数の親に属することが可能。また、子を保持して親ノードとな
ることも、子を持たずにリーフオブジェクトとなることも可能。
関連項目 リソース (RMS)、 オブジェクト (RMS)、 親 (RMS)、 リーフオブジェクト (RMS)

高可用性
冗長リソースにより一点故障箇所を排除する概念。

構成定義ファイル (RMS)
監視するリソースを定義し、リソース間の相互依存性を設定するRMS構成定義ファイル。デフォルトファイル名はconfig.us。

高速切替方式
GLSが提供するLAN二重化方式の1つ。多重化したLANを同時に使用し、サーバ間通信のスケーラビリティ向上と、LAN異常発生時の
高速な切替えを実現する。

- 193 -
コンカチネーション
複数の物理ディスクを連結すること。複数のディスクを仮想的に1つの大容量ディスクとして使用する仕組み。

コンソール
シングルコンソールを参照。

最上位グループ (GDS)
他のグループに属していないグループ。最上位グループには、ボリュームを作成できます。

サービス提供ノード (SIS)
FTP、Telnet、HTTPなど1つ以上のTCPサービスを提供し、ゲートウェイクラスタノードからクライアント要求を受信する。
関連項目 データベースノード (SIS)、ゲートウェイクラスタノード (SIS)、Scalable Internet Services (SIS)

サブアプリケーション (RMS)
高可用性の1つのリソースタイプを構成するために設計された構成用テンプレートの一部。RMS構成には各リソースタイプの複数の
インスタンスが含まれる場合がある。汎用テンプレートは、コマンド、アプリケーションコントローラ、IPアドレス、仮想ネットワークインタ
フェース、ローカルおよびリモートのファイルシステム、ボリュームマネージャ、およびストレージマネージャ用のサブアプリケーションを含
む。

システムグラフ (RMS)
構成定義ファイルの作成、または解釈に使用される監視対象リソースのビジュアル表示 (マップ)。
関連項目 構成定義ファイル (RMS)

システムディスク (GDS)
動作中のオペレーティングシステムがインストールされているディスク。次のいずれかのファイルシステム (またはスワップ域) として現
在動作しているスライスが存在するディスク全体を指します。
Solaris の場合: /、 /usr 、 /var 、またはスワップ域
Linux の場合: /、 /usr 、 /var 、/boot、/boot/efi、またはスワップ域

指定切替え (RMS)
管理者がRMSのuserApplicationを指定したノードに切替える処理。
関連項目 自動切替え (RMS)、フェイルオーバ (RMS、SIS)、切替え (RMS)、対称切替え (RMS)

自動切替え (RMS)
ある一定の条件が検出された際に、userApplicationの実行を他のノードへ自動的に切替えるRMSの処理。
関連項目 指定切替え (RMS)、フェイルオーバ (RMS、SIS)、切替え (RMS)、対称切替え (RMS)

自動電源制御
自動電源制御は、ESF (Enhanced Support Facility) で提供している機能で、サーバの電源投入および、切断を自動的に行うための機
能である。

シャットダウン機構
異常が発生したノードを強制停止させるための機構。PRIMECLUSTERは、クラスタ整合性 (クォーラム) が保てない状態になったと判断
した場合に、シャットダウン機構 (SF) を使用して、クラスタシステムをクラスタ整合状態 (クォーラム) に戻している。

状態
リソース状態 (RMS)を参照。

- 194 -
状態遷移プロシジャ
クラスタ制御からの状態遷移指示を受け取り、リソースの活性/非活性化を制御 (クラスタアプリケーションの起動/停止など) するもの。

冗長化
オブジェクトがクラスタ内の他のオブジェクトのリソース負荷を引継ぐ機能、およびRAIDハードウェア、またはソフトウェアにより2次記
憶装置に保存されているデータを複製する機能。

シングルコンソール
RMSの監視対象ノードを集中管理するワークステーション。シングルコンソールソフトウェアのSCONはシングルコンソールから実行さ
れる。

シングルディスク (GDS)
グループに属していないSDXディスクで、シングルボリュームを作成できるディスク。

シングルボリューム (GDS)
グループに属していないシングルディスク内に作成されたボリューム。データは冗長化されません。

スイッチオーバ
ユーザの要求によりユーザ業務が運用系から待機系へ処理やデータを引継ぐこと。

スクリプト (RMS)
リソースの状態遷移に対応してBM (ベースモニタ) から実行されるシェルプログラム。スクリプトによりリソースの状態が変更される場合
もある。

スコープ (GDS)
共用タイプのディスククラスにおいてオブジェクトを共用できるノード群の範囲を表します。

ストライピング
データを一定のサイズに分割して、複数のスライスに交互に振り分けて書込むこと。I/Oを複数の物理ディスクに分散して同時に発行する
仕組み。

ストライプ化仮想ディスク
ストライプ化仮想ディスクは複数の区画で構成されます。物理パーティションや複数の仮想ディスク (通常はミラーディスク) で構成す
ることもできます。このようにして仮想ディスク上の連続したI/O処理を複数の物理ディスク上のI/O処理に変換することができる。この機能
はRAIDレベル0 (RAID0) に該当する (富士通テクノロジー・ソリューションズ製品から移行のお客様のみ)。
関連項目 連結仮想ディスク、ミラー仮想ディスク(VM)、単独仮想ディスク、仮想ディスク

ストライプグループ (GDS)
ストライプ(stripe)タイプのディスクグループ。ストライピングの単位となるディスクおよび下位グループの集まり。

ストライプ幅 (GDS)
ストライピングする際の、データを分割するサイズ。

ストライプボリューム (GDS)
ストライプグループ内に作成されたボリューム。ストライピングによってI/O負荷を複数のディスクに分散させることができます。データは
冗長化されません。

スペアディスク (GDS)
故障したディスクの替わりにミラーリング状態を回復させるための予備ディスク。

- 195 -
世代数
PRIMECLUSTER のバックアップ/リストアは、データの世代管理が可能で、現在の世代数は、バックアップおよびリストアデータの名前
の一部として付加されます。なお世代数は0以上の整数が使用され、バックアップが成功するたびに1ずつ増加します。世代数は、
ccbr.gen ファイル、または、cfbackup(1M)コマンドおよび cfrestore(1M)コマンドのオプション引数にて指定することができます。 詳細は、
cfbackup(1M)コマンドおよびcfrestore(1M)コマンドのマニュアルページを参照してください。

専用ネットワークアドレス
RFC1918により指定された一定範囲の予約済IPアドレス。どの部門でも使用可能であるが、異なる部門が同時に同じアドレスを使用する
可能性があるため、インターネット経由で外部から参照できないようにする必要がある。

専用リソース (RMS)
1台のノードのみが使用可能で、他のRMSノードからは使用できないリソース。
関連項目 リソース (RMS)、共用リソース

属性 (RMS)
各オブジェクトタイプについて、BM (ベースモニタ) がどう処理するかを規定するオブジェクト。

対称切替え (RMS)
すべてのRMSノードが他の任意のRMSノードからリソースを引継ぐことのできる機能。
関連項目 自動切替え (RMS)、指定切替え (RMS)、フェイルオーバ (RMS、SIS)、切替え (RMS)

タイプ
オブジェクトタイプ (RMS)を参照。

多重ホスト
複数のコントローラ経由で同一のディスク (富士通テクノロジー・ソリューションズ製品から移行のお客様のみ)。

単独仮想ディスク
単独仮想ディスクは、物理ディスクパーティションの1領域、またはパーティション全体を定義します (富士通テクノロジー・ソリューションズ
製品から移行のお客様のみ)。
関連項目 連結仮想ディスク、ストライプ化仮想ディスク、仮想ディスク

通知メッセージ (RMS)
ディテクタがBM (ベースモニタ) に特定リソースの状態を通知するメッセージ。

停止要求
クラスタ整合状態 (クォーラム) を回復するために、指定したノードを強制停止させるための指示。

ディスククラス (GDS)
SDXオブジェクトの集まり。共用タイプのディスククラスは、PRIMECLUSTERシステムで利用可能なリソースの単位でもあります。ディ
スククラスを単に「クラス」と呼ぶ場合もあります。

ディスクグループ (GDS)
ミラーリング、ストライピング、またはコンカチネートされる単位となるディスクまたは下位グループの集まり。同じディスクグループに属し
ているディスクおよび下位グループは、そのディスクグループのタイプ属性(ミラー、ストライプ、またはコンカチネーション)に応じて、互
いに ミラーリング、ストライピング、またはコンカチネートされます。 ディスクグループを単に「グループ」と呼ぶ場合もあります。

ディテクタ (RMS)
特定のオブジェクトタイプの状態を監視して、リソースの状態変化をBM (ベースモニタ) に通知するプロセス。

- 196 -
データベースノード (SIS)
SIS構成の設定、動的データ、統計を管理するノード。
関連項目 ゲートウェイクラスタノード (SIS)、サービス提供ノード (SIS)、Scalable Internet Services (SIS)

デーモン
特定の機能を繰り返し実行する、システムに常駐するプロセス。

電源連動 (制御)
クラスタシステムにおいて、1ノードの電源を投入すると、電源切断状態にあるその他すべてのノードおよびノードとRCIケーブルで接続
されたディスクアレイ装置の電源が投入されること。

テンプレート
アプリケーション (RMS)を参照。

ネットワークアダプタ
LAN関連のネットワークアダプタ。

ネットワークインタフェースカード
ネットワークアダプタを参照。

ネットワークパーティション (CF)
クラスタ内の複数ノードのインタコネクトによる通信が不可能な場合に発生する状態。ネットワークパーティション状態でアプリケーションが
共用ディスクにアクセスし続けるとデータの整合性がとれなくなる恐れがある。

ノード
クラスタのメンバであるホスト。コンピュータノードとはコンピュータのことを指す。

ノード間通信機構
PRIMECLUSTER CFで使用されるクラスタノード間の通信機能。クラスタノード間通信専用に設計されているため、TCP/IPよりもオー
バヘッドが少なく、メッセージの到着順も保証したデータグラム通信サービスを行うことができる。

ノード状態 (CF)
クラスタ内のすべてのノードは、同じクラスタの他のすべてのノードのローカル状態を管理する。クラスタ内のノードは、すべてUP、
DOWN、またはLEFTCLUSTERのいずれかの状態にある。
関連項目 UP (CF)、DHCP、LEFTCLUSTER (CF)

パトロール診断
ハードウェアの故障を定期的に診断する機能。

ハブ
LANや、ファイバチャネルで使用されるスター型の結線装置。

汎用タイプ (RMS)
汎用プロパティを持つオブジェクトタイプ。汎用タイプは、既存のオブジェクトタイプに割り当てることのできない監視対象リソースがある
場合にRMSをカスタマイズするために使用される。
関連項目 オブジェクトタイプ (RMS)

非同期監視
SAの機能に加え、リモートクラスタノードの状態を監視し、そのノードのダウンを即時に検出するコンポーネント。

- 197 -
フェイルオーバ (RMS、SIS)
SISでは、このプロセスにより障害発生ノードのバックアップノードへの切替えを行う。RMSでは、このプロセスを切替えと呼ぶ。
関連項目 自動切替え (RMS)、指定切替え (RMS)、切替え (RMS)、対称切替え (RMS)

フォルトトレラントネットワーク (耐故障性を備えたネットワーク)
耐故障性 (フォルトトレラント) を備えたネットワーク。耐故障性 (フォルトトレラント) とは、コンピュータシステムの一部に何らかの障害が
発生した場合でも、正常な動作を保ち続ける能力のこと。よって、フォルトトレラントネットワークとはネットワークシステムの一部に異常が
発生した場合でも、正常に通信を継続できるネットワークのことを意味している。

物理IPアドレス
ネットワークインタフェースカードのインタフェース (たとえばhme0) に直接割り振られたIPアドレス。

プライマリノード (RMS)
RMSの起動時にユーザアプリケーションをオンラインにするデフォルトノード。userApplicationのオブジェクト定義中に最初に記述さ
れたノードがプライマリノードとなる。

ボリューム (GDS)
論理ボリューム (GDS) を参照。

マウントポイント
ディレクトリツリー上でファイルシステムが接続されるポイント。

ミラー仮想ディスク(VM)
ミラー仮想ディスクは複数の物理デバイスで構成され、すべての出力処理がすべてのデバイス上で同時実行される (富士通テクノ
ロジー・ソリューションズ製品から移行のお客様のみ)。
関連項目 連結仮想ディスク、単独仮想ディスク、ストライプ化仮想ディスク、仮想ディスク

ミラーグループ (GDS)
ミラー(mirror)タイプのディスクグループ。互いにミラーリングされるディスクおよび下位グループの集まり。

ミラーリング
同じデータを複数のスライスに書込むことによって、冗長性を維持すること。一部のスライスで障害が発生したとしても、正常なスライスが
残っていれば、ボリュームへのアクセスが継続できる仕組み。

メタデータサーバ
ファイルシステム (メタデータ) の制御情報を一括管理するGFSデーモン。

メッセージ
1つのソフトウェアプロセスから他のプロセス、デバイス、またはファイルに伝送されるデータの集まり。

メッセージキュー
メッセージの保存場所として使用される専用のメモリ領域。

ユーザグループ
Web-Based Admin ViewやCluster Admin GUIが提供する環境設定、運用管理などの操作範囲を限定するもので、wvroot、clroot、
cladmin、clmonの4種類がある。クラスタ管理サーバのオペレーションシステムの管理者に依頼して、個々のユーザIDを適切なユー
ザグループへ登録する。

- 198 -
リーフオブジェクト (RMS)
システムグラフの最下位オブジェクト。リーフオブジェクトは構成定義ファイルの最後に定義される。リーフオブジェクトはその配下に子
オブジェクトを持たない。

リソース (RMS)
ミラーディスク、ミラーディスク部品、データベースサーバなどの機能を提供する、専用または共用のハードウェアまたはソフトウェア要素。
ローカルリソースは、ローカルノード上でのみ監視対象となる。
関連項目 専用リソース (RMS)、共用リソース

リソース状態 (RMS)
リソースの現在の状態。

リソース定義 (RMS)
オブジェクト定義 (RMS)を参照。

リソースデータベース
複数のノード間で共用されるハードウェアの情報を管理するデータベース。リソースデータベースは、クラスタリソース管理機構により管理
される。

リソースラベル (RMS)
システムグラフに表示されるリソース名。

リモートコンソール接続装置
RS232CインタフェースとLANインタフェースを変換する装置。本装置により、LAN接続された他の装置 (パソコン) からTelnet機能により
TTYコンソール機能を利用可能とする。

リモートノード
リモートホストを参照。

リモートホスト
遠距離通信回線またはLANを使ってアクセスするホスト。
関連項目 ローカルホスト

リンク (RMS)
特定リソース間の親子関係を指定する。

連結仮想ディスク
1つ以上のディスクドライブ上の複数の区画で構成され、各部を合計したものに相当する。ディスクを細かく分割する単独仮想ディスクと
異なり、各ディスクまたはパーティションを連結して1つの大規模な論理ディスクを構成する (富士通テクノロジー・ソリューションズ製品から
移行のお客様のみ)。
関連項目 ミラー仮想ディスク(VM)、単独仮想ディスク、ストライプ化仮想ディスク、仮想ディスク

ローカルMACアドレス
ローカルエリアネットワーク (LAN) のシステムごとに、システム管理者がそのシステム内部での一意性を保証するMACアドレス。

ローカルエリアネットワーク
業務LANを参照。

- 199 -
ローカルホスト
コマンドまたはプロセスを開始するホスト
関連項目 リモートホスト

ログファイル
重要なシステムイベントやメッセージを記録したファイル。BM (ベースモニタ)、ウィザード、ディテクタにはそれぞれ固有のログファイ
ルがある。

ローリングアップデート
クラスタシステムにおいて、修正適用、保守時に使用されるアップデート手法。1ノードずつ順次修正適用を行うことで、業務を停止せ
ずに修正を適用することが可能となる。

論理ボリューム (GDS)
利用者が直接アクセスできる仮想ディスクデバイスの総称。利用者は、物理ディスクのスライス(パーティション)と同じように、論理ボ
リュームにアクセスできます。論理ボリュームを単に「ボリューム」と呼ぶ場合もあります。

- 200 -
索　引
[記号]
/etc/dfs/dfstab.pcl....................................................................148
/etc/vfstab.pcl..........................................................................148
/var/opt/SMAWRrms/log/...................................................... 101
[A]
Affiliation............................................................................... 157
AlternateIp.............................................................................. 157
AutoRecover...........................................................................153
AutoRecoverCleanup..............................................................157
AutoRecover属性.....................................................................26
AutoStartUp............................................................................153
AutoSwitchOver..................................................................... 153
[B]
BM............................................................................................ 10
[C]
Class........................................................................................157
Cluster Admin.............................................................................1
ClusterExclusive.....................................................................153
Comment................................................................................ 157
ControlledSwitch.................................................................... 157
[D]
DetectorStartScript................................................................. 158
[F]
Faulted状態のクリア............................................................... 129
FaultScript.............................................................................. 153
Faultクリア................................................................................. 28
[H]
HaltFlag.................................................................................. 153
HostName............................................................................... 158
hvlogclean...............................................................................176
hvlogcontrol............................................................................176
HV_APPLICATION.............................................................. 166
HV_AUTORECOVER...........................................................166
HV_AUTOSTARTUP............................................................163
HV_AUTOSTARTUP_IGNORE.......................................... 160
HV_AUTOSTART_WAIT.................................................... 161
HV_CHECKSUM_INTERVAL............................................ 161
HV_COM_PORT................................................................... 161
HV_CONNECT_TIMEOUT..................................................164
HV_FORCED_REQUEST.....................................................166
HV_LAST_DET_REPORT................................................... 167
HV_LOG_ACTION............................................................... 164
HV_LOG_ACTION_THRESHOLD..................................... 161
HV_LOG_WARN_THRESHOLD........................................ 161
HV_LOH_INTERVAL.......................................................... 162
HV_MAXPROC.....................................................................164
HV_MAX_HVDISP_FILE_SIZE..........................................164
HV_MLOCKALL.................................................................. 164
HV_NODENAME..................................................................167
HV_OFFLINE_REASON...................................................... 167
HV_RCSTART...................................................................... 164
- 201 -
HV_REALTIME_PRIORITY................................................164
HV_REQUESTING_CONTROLLER...................................167
HV_SCALABLE_CONTROLLER....................................... 167
HV_SCALABLE_INFO........................................................ 167
HV_SCRIPTS_DEBUG.........................................................164
HV_SCRIPT_TYPE...............................................................167
HV_SYSLOG_USE............................................................... 165
HV_USE_ELM...................................................................... 162
HV_VM_ENABLE_IP_ADVERTISE.................................. 165
HV_VM_IP_ADVERTISE_COUNT.................................... 165
[I]
Inconsistent状態.......................................................................31
I_List.......................................................................................158
[L]
LastDetectorReport.................................................................158
LieOffline............................................................................... 154
[M]
MaxControllers.......................................................................158
MonitorOnly........................................................................... 154
[N]
NODE_SCRIPTS_TIME_OUT............................................. 167
NoDisplay...............................................................................158
NullDetector........................................................................... 158
[O]
OfflineDoneScript.................................................................. 154
Offline Fault............................................................................. 26
OfflineScript........................................................................... 154
Offline処理...............................................................................23
Offline要求...............................................................................23
OnlinePriority......................................................................... 154
OnlineScript............................................................................155
Online処理............................................................................... 19
Online要求............................................................................... 19
[P]
PartialCluster.......................................................................... 155
PersistentFault........................................................................ 155
PostOfflineScript.................................................................... 155
PostOnlineScript.....................................................................155
PreCheckScript....................................................................... 155
PreCheckScript......................................................................... 20
PreOfflineScript......................................................................156
PreOnlineScript...................................................................... 156
PreserveState.......................................................................... 156
PriorityList..............................................................................158
[R]
RAID...................................................................................... 195
RELIANT_HOSTNAME.......................................................166
RELIANT_INITSCRIPT........................................................166
RELIANT_LOG_LIFE.......................................................... 162
RELIANT_LOG_PATH........................................................ 162
RELIANT_PATH...................................................................162
RELIANT_SHUT_MIN_WAIT............................................ 163
RELIANT_STARTUP_PATH...............................................166
Resource................................................................................. 159
rKind.......................................................................................159
RMS Wizard Tools..................................................................1,9
RMSオブジェクト...................................................................... 56
RMSグローバル環境変数..................................................... 160
RMS構成ウィザード管理属性............................................... 157
RMSスクリプト実行環境変数.................................................166
RMSツリー................................................................................74
RMSハートビート......................................................................32
RMSローカル環境変数......................................................... 163
rName..................................................................................... 159

[S]
SCRIPTS_TIME_OUT.......................................................... 166
ScriptTimeout......................................................................... 156
ShutdownPriority....................................................................156
SplitRequest............................................................................159
StandbyCapable...................................................................... 156
StandbyTransitions................................................................. 157
StateDetails.............................................................................159
SysNode異常............................................................................28

[W]
WarningScript.........................................................................157

[あ]
オブジェクト属性...................................................................... 13
オブジェクトタイプ.......................................................... 2,12,152
オペレータ介入........................................................................ 29

[か]
環境変数.................................................................................. 13
切替え要求...............................................................................29

[さ]
スクリプト................................................................................ 2,55
スクリプト実行環境変数........................................................... 14
スクリプト実行時環境変数....................................................... 39
スケーラブルアプリケーション..................................................36
スケーラブルコントローラ...................................................... 6,35

[た]
ディテクタ..........................................................................2,10,55

[は]
フォローコントローラ................................................................... 5

[や]
ユーザ設定属性.....................................................................153

[ら]
ログファイル............................................................................ 169

- 202 -