高信頼化システム監視機能 HAモニタ Linux(R)編

解説・手引・操作書

3000-9-132-G0

目　　次

前書き

変更内容

はじめに

第1編　概要

1.　HAモニタの概要

1.1　HAモニタの目的

1.2　系切り替え

1.2.1　系

1.2.2　系切り替えの流れ

1.2.3　サーバ

1.2.4　HAモニタが検出する障害

1.3　系切り替えの種類

1.3.1　自動系切り替え

1.3.2　計画系切り替え

1.4　HAモニタを適用したシステム形態

1.4.1　C/Sシステム形態

1.4.2　FEP形態

1.4.3　分散処理システム形態

1.5　HAモニタの動作環境

1.5.1　必要なハードウェア

1.5.2　必要なソフトウェア

2.　HAモニタを使用した系切り替え

2.1　系切り替え構成

2.1.1　1:1系切り替え構成

2.1.2　相互系切り替え構成

2.1.3　2:1系切り替え構成

2.1.4　複数スタンバイ構成

2.1.5　クラスタ型系切り替え構成

2.2　障害検出から系切り替えまでの流れ

2.2.1　サーバ障害時の系切り替え

2.2.2　系障害時の系切り替え

2.3　HAモニタによる障害検出

2.3.1　HAモニタが系切り替えをする条件

2.3.2　サーバ障害の検出（サーバモードの場合）

2.3.3　サーバ障害の検出（モニタモードの場合）

2.3.4　系障害の検出

2.3.5　系のリセット

2.4　共有リソースの引き継ぎ

2.4.1　引き継げるリソースと単位

2.4.2　共有ディスクの引き継ぎ

2.4.3　ファイルシステムの引き継ぎ

2.4.4　LANの引き継ぎ

第2編　解説

3.　HAモニタで使用できる機能

3.1　サーバの制御のための機能

3.1.1　モニタモードのサーバの監視

3.1.2　サーバのグループ化による連動系切り替え

3.1.3　サーバの切り替え順序制御

3.1.4　複数の待機系を配置するマルチスタンバイ

3.1.5　系切り替え後の負荷集中を避けるサーバの排他制御

3.1.6　JP1と連携したシステム運用

3.2　系の制御のための機能

3.2.1　系の同時リセットの防止

3.2.2　複数系間の同時リセットの防止

3.2.3　系の二重リセットの防止

3.2.4　系のリセットの抑止

3.2.5　サーバ障害時に系ごと切り替える系のペアダウン

3.2.6　LANの監視および障害時の自動系切り替え

3.2.7　他系のOSパニック検知

3.2.8　仮想化環境での物理パーティションリセット機能

3.2.9　N+Mコールドスタンバイ構成での系切り替え

3.3　共有リソースの制御のための機能

3.3.1　リソースサーバを使用した共有リソースの共用

3.3.2　サーバやHAモニタの状態変化時のコマンド発行

3.3.3　共有リソース接続失敗時のサーバの起動中止

3.3.4　共有リソース引き継ぎのタイムアウト

3.3.5　共有リソースの切り離し順序指定

3.3.6　共有リソースの動的変更

3.4　プログラムの制御のための機能（モニタモード）

3.4.1　UAPの監視

3.5　HAモニタ Extensionの機能

3.5.1　サーバの最大数の変更

3.5.2　系の最大数の変更

4.　システムの管理

4.1　サーバの管理

4.1.1　HAモニタによるサーバの起動制御

4.1.2　HAモニタによるサーバの停止制御

4.1.3　サーバの状態遷移

4.1.4　サーバの監視コマンドの制御

4.1.5　サーバの切り替え順序制御をする場合の処理の流れ

4.2　系の管理

4.2.1　系のリセットをする系の決定方法

4.2.2　両系が障害を同時に検出した場合の系切り替え

4.2.3　複数の待機系がある場合の系のリセット

4.2.4　系のリセットに失敗した場合の動作

4.3　共有リソースの管理

4.3.1　共有ディスクの管理

4.3.2　共有ディスクの管理（HA Boosterを使用する場合）

4.3.3　ファイルシステムの管理

4.3.4　LANの管理

4.3.5　共有リソースの状態一覧

4.4　サーバをグループ化する場合のサーバの管理

4.4.1　連動系切り替え時のサーバの切り替え種別

4.4.2　グループ化したサーバの系切り替え制御

4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理

4.5.1　系障害の検出と系のリセット（マルチスタンバイ）

4.5.2　系のリセットに失敗した場合の動作（マルチスタンバイ）

4.5.3　サーバの起動制御・停止制御（マルチスタンバイ）

4.6　リソースサーバの管理

4.6.1　リソースサーバを使用した系切り替え

4.6.2　リソースサーバを使用した共有リソースとの接続・切り離しの流れ

4.6.3　リソースサーバの状態の決定方法

4.7　プログラムの管理（モニタモード）

4.7.1　UAPの監視制御

4.7.2　プログラムの再起動制御

4.7.3　プログラムの状態遷移

4.7.4　UAP監視時の処理の流れ

4.8　処理の流れ

4.8.1　サーバの起動処理の流れ

4.8.2　サーバの停止処理の流れ

4.8.3　サーバ障害時の系切り替え処理の流れ

4.8.4　系障害時の系切り替え処理の流れ

4.8.5　サーバ障害時の系切り替え失敗処理の流れ

4.8.6　系障害時の系切り替え失敗処理の流れ

4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ

第3編　導入・運用

5.　HAモニタの導入とシステムの設計

5.1　導入と設計の流れ

5.2　系切り替え構成の検討

5.2.1　系切り替え構成の違い

5.2.2　構成設計時の考慮点

5.2.3　系の最大数を変更する場合の考慮点（HAモニタ Extension使用時）

5.2.4　仮想化環境を系切り替え構成にする場合の考慮点（日立サーバ仮想化機構（Virtage）使用時）

5.2.5　仮想化環境を系切り替え構成にする場合の考慮点（VMware ESXi使用時）

5.3　サーバ構成の検討

5.3.1　系切り替えをする単位（サーバ）の決定

5.3.2　複数のサーバを使用する場合の考慮点

5.4　リソース構成の検討

5.4.1　必要なリソースとリソース数

5.4.2　必要なIPアドレス

5.4.3　リソースの共用方法の考え方

5.4.4　リソースサーバを使用する場合の構成

5.5　ハードウェア構成の検討

5.5.1　共有ディスクの構成

5.5.2　LANの構成

5.5.3　監視パスの構成

5.5.4　リセットパスの構成

5.5.5　ハードウェア構成例（BladeSymphony（Basicモード））

5.5.6　ハードウェア構成例（BladeSymphony（LPARモード））

5.5.7　ハードウェア構成例（HA8000）

5.5.8　ハードウェア構成例（HA8500）

6.　システムの構築

6.1　構築の流れ

6.2　ディレクトリ構成

6.3　OSの設定

6.3.1　環境変数の設定

6.3.2　システムファイルの設定

6.3.3　システムクロックの設定

6.3.4　DNSの設定

6.3.5　システムログファイルの設定

6.3.6　カーネルのパラメタの設定

6.3.7　出力言語種別の設定

6.3.8　セキュリティレベルの設定

6.3.9　ファイルシステムの設定

6.4　リセットパスの設定（BladeSymphony）

6.4.1　設定に必要な情報（BladeSymphony）

6.4.2　設定値の例（BladeSymphony）

6.5　リセットパスの設定（HA8000）

6.5.1　設定に必要な情報（HA8000）

6.5.2　設定値の例（HA8000）

6.6　障害管理プロセサの設定（HA8500）

6.6.1　LANポートの設定（HA8500）

6.6.2　障害管理プロセサのIPアドレスの登録（HA8500）

6.6.3　HAモニタのリセット手順ファイルの設定（HA8500）

6.7　HAモニタで使用するためのVMware ESXiの設定

6.8　監視パスの設定

6.8.1　ホスト名とサービス名の登録

6.8.2　HAモニタの接続構成設定ファイルの作成

6.9　定義ファイルの作成（HAモニタ）

6.10　サーバが使用する共有リソースの設定

6.10.1　共有ディスクの設定

6.10.2　LANの状態設定ファイルの設定

6.10.3　LANの監視設定ファイルの設定

6.11　サーバの起動・停止・監視コマンドの作成

6.11.1　サーバの起動コマンドの作成

6.11.2　サーバの停止コマンドの作成

6.11.3　サーバの監視コマンドの作成

6.12　プログラムの再起動コマンドの作成（プログラム管理機能使用時）

6.13　UAPの作成と設定

6.13.1　UAPへのAPIの組み込み

6.13.2　UAPの環境変数の設定

6.14　定義ファイルの作成（サーバ）

6.15　定義ファイルの作成（モニタモードのプログラム）

6.16　ユーザコマンドの作成

6.16.1　ユーザコマンドが発行されるタイミング（サーバの状態変化時）

6.16.2　ユーザコマンドが発行されるタイミング（HAモニタの状態変化時）

6.16.3　ユーザコマンドの発行形式（サーバの状態変化時）

6.16.4　ユーザコマンドの発行形式（HAモニタの状態変化時）

6.16.5　ユーザコマンドの作成方法

6.16.6　ユーザコマンドのコーディング例

6.17　HAモニタ Extensionの設定

6.18　構築したシステムの設定・定義のチェック

6.18.1　複数系切り替え構成間での設定・定義のチェック

6.18.2　定義チェック

6.19　障害情報を収集するための設定

6.20　構築したシステムの動作確認

6.20.1　HAモニタの動作確認

6.20.2　サーバの動作確認

6.20.3　系切り替えのテスト

6.20.4　システムに掛かる負荷のテスト

6.21　系の最大数を変更する場合の動作確認（HAモニタ Extension使用時）

7.　システムの運用

7.1　運用の流れ

7.1.1　運用前の準備

7.2　起動・停止

7.2.1　起動する

7.2.2　停止する

7.2.3　共有リソースをメンテナンスするときの注意事項

7.3　障害発生による系切り替え時の運用

7.3.1　待ち状態のサーバを起動して業務を再開する

7.3.2　障害情報を収集する

7.3.3　障害が発生した系を再起動する

7.3.4　障害対処後にサーバや系の状態を確認する

7.4　障害への対処

7.4.1　系の起動失敗に対処する

7.4.2　サーバの再起動失敗に対処する

7.4.3　系のリセット失敗に対処する

7.4.4　共有リソースの接続失敗に対処する

7.4.5　共有リソースの切り離し失敗に対処する

7.4.6　UAP障害に対処する

7.5　高負荷による障害発生を防止するための運用

7.5.1　サーバの監視履歴を取得する

7.5.2　系の監視履歴を取得する

7.5.3　取得した監視履歴を解析する

7.5.4　サーバのスローダウンの原因を調査する

7.6　運用の自動化

7.6.1　システムの起動からサーバの起動までを自動化する

7.6.2　サーバやHAモニタの状態変化時の運用を自動化する

7.6.3　系切り替え後の運用を自動化する

7.7　計画的な系切り替え

7.7.1　計画的に系切り替えをする

7.8　システムの変更

7.8.1　系を追加する

7.8.2　サーバを追加する

7.8.3　共有リソースを変更する

7.8.4　系やサーバを稼働させたまま共有リソースの構成を変更する

7.8.5　HAモニタやサーバの環境設定を変更する

7.8.6　稼働しているHAモニタやサーバの設定を変更する

7.8.7　ハードウェアの設定を変更する

第4編　リファレンス

8.　環境設定で定義するファイル

8.1　定義ファイルの概要

8.2　定義の規則

8.2.1　定義の記述形式

8.2.2　定義で使用する記号

8.3　HAモニタの環境設定

8.3.1　HAモニタの環境設定（sysdef）

8.4　サーバの環境設定

8.4.1　サーバ対応の環境設定（servers）

8.4.2　排他サーバの環境設定（servers_opt）

8.5　モニタモードのプログラムの環境設定

8.5.1　モニタモードのプログラム対応の環境設定（programs）

8.6　環境設定例

8.6.1　1:1系切り替え構成時の環境設定例

8.6.2　複数系切り替え構成時の環境設定例

8.6.3　排他サーバ指定時の環境設定例

9.　コマンド

コマンド一覧

コマンドの説明で使用する見出し

文法記述記号

monact（待ち状態のサーバを実行サーバとして起動）

monbegin（モニタモードのサーバの起動）

monchange（HAモニタ・サーバ稼働中の設定変更）

moncheck（定義チェック）

mondeact（待ち状態のサーバの停止）

mondevice（実行サーバ稼働中の共有リソースの変更）

monend（モニタモードのサーバの停止）

moninfo（実行系でのサーバ引き継ぎ情報の設定／待機系でのサーバ引き継ぎ情報の参照・表示）

monlink（HAモニタ間の手動接続）

monlistip（IPアドレスの検出）

monmp（MPの状態表示）

monodrshw（サーバ順序制御の状態表示）

monpath（監視パスの状態表示）

monresbgn（リソースサーバの起動）

monresend（実行中のリソースサーバの停止）

monressbystp（待機中のリソースサーバの停止）

monrp（リセットパスの状態表示）

monsbystp（待機サーバの停止）

monsetup（HAモニタの環境設定）

monshow（サーバと系の状態表示）

monstart（HAモニタの起動）

monstop（HAモニタの停止）

monswap（計画系切り替え）

monts（HAモニタのトラブルシュート情報の収集）

10.　API

APIの一覧

APIの説明で使用する見出し

hamon_patrolstart（UAPの監視開始）

hamon_patrolstop（UAPの監視終了）

詳細コードの一覧

コーディング例

付録

付録A　HAモニタのイベントID

付録B　監視履歴として出力されるメッセージ

付録C　HAモニタが出力するファイル一覧

付録D　HAモニタのプロセス一覧

付録E　各バージョンの変更内容

付録F　このマニュアルの参考情報

付録F.1　関連マニュアル

付録F.2　このマニュアルでの表記

付録F.3　英略語

付録F.4　KB（キロバイト）などの単位表記について

付録G　用語解説

索引

[他社商品名称に関する表示]

All Rights Reserved. Copyright (C) 2005, 2012, Hitachi, Ltd.

前書き

■ 対象製品

・適用OS：Red Hat Enterprise Linux AS 3(x86)，Red Hat Enterprise Linux AS 4(x86)，Red Hat Enterprise Linux ES 3(x86)，Red Hat Enterprise Linux ES 4(x86)，Red Hat Enterprise Linux AS 3(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux 5(x86)，Red Hat Enterprise Linux 5(AMD/Intel 64)※，Red Hat Enterprise Linux 5 Advanced Platform(x86)，Red Hat Enterprise Linux 5 Advanced Platform(AMD/Intel 64)※

P-9S2C-E111　 HAモニタ　 01-42

・適用OS：Red Hat Enterprise Linux AS 4(x86)，Red Hat Enterprise Linux ES 4(x86)，Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux 5(x86)，Red Hat Enterprise Linux 5(AMD/Intel 64)※，Red Hat Enterprise Linux 5 Advanced Platform(x86)，Red Hat Enterprise Linux 5 Advanced Platform(AMD/Intel 64)※，Red Hat Enterprise Linux server 6(x86)，Red Hat Enterprise Linux server 6(x86_64)

P-812C-E111　 HAモニタ　 01-51

・適用OS：Red Hat Enterprise Linux AS 3(x86)，Red Hat Enterprise Linux AS 4(x86)，Red Hat Enterprise Linux ES 3(x86)，Red Hat Enterprise Linux ES 4(x86)，Red Hat Enterprise Linux AS 3(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)※，Red Hat Enterprise Linux 5(x86)，Red Hat Enterprise Linux 5(AMD/Intel 64)※，Red Hat Enterprise Linux 5 Advanced Platform(x86)，Red Hat Enterprise Linux 5 Advanced Platform(AMD/Intel 64)※，Red Hat Enterprise Linux server 6(x86)，Red Hat Enterprise Linux server 6(x86_64)

P-9S2C-E211　 HAモニタ Extension　 01-00

・適用OS：Red Hat Enterprise Linux AS 3(IPF)，Red Hat Enterprise Linux AS 4(IPF)，Red Hat Enterprise Linux 5 Advanced Platform(Intel Itanium)

P-9V2C-E111　 HAモニタ　 01-31

これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。
注※　動作環境としては，Intel EM64Tにだけ対応しています。

■ 輸出時の注意

本製品を輸出される場合には，外国為替および外国貿易法ならびに米国の輸出管理関連法規などの規制をご確認の上，必要な手続きをお取りください。
なお，ご不明な場合は，弊社担当営業にお問い合わせください。

■ 商標類

AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Ethernetは，富士ゼロックス株式会社の登録商標です。
HP-UXは，Hewlett-Packard Development Company, L.P.のオペレーティングシステムの名称です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
VERITASおよびVERITASロゴは，Symantec Corporation の米国およびその他の国における商標または登録商標です。
VMwareは，VMware, Inc.の米国および各国での登録商標または商標です。
VMware vSphereは，VMware, Inc.の米国および各国での登録商標または商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
その他記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。

■ 発行

2012年4月　3000-9-132-G0

■ 著作権

All Rights Reserved. Copyright (C) 2005, 2012, Hitachi, Ltd.

変更内容

変更内容（3000-9-132-G0）HAモニタ 01-51

追加・変更内容
変更個所

マシンの機種がBladeSymphonyの場合，SVPの保守作業などによってSVPが一時的に通信できないときに，リセットパスの障害を検知しないようにした。
これに伴い，次のオペランドを追加した。

HAモニタの環境設定

resetpatrol_mode

2.3.4(2)，8.3.1，8.3.1(2)

HAモニタの系間が接続している状態の場合に，系を監視できるようにした。これによって，マルチスタンバイ構成ではない場合にも，系のリセットの抑止機能を使用できるようにした。
これに伴い，次のオペランドを追加した。

HAモニタの環境設定

patrol_type

また，次のオペランドの説明を変更した。

HAモニタの環境設定

suppress_reset

3.2.4，8.3.1，8.3.1(2)

VMware ESXiによる仮想化環境に関する注意事項を追加した。
5.2.5，6.7(3)

hbondingのステータスだけを監視する場合，HAモニタの環境設定のlancheck_patrolオペランドは指定不要である旨を追加した。
8.3.1(2)

次のオペランドのタイムアウトの監視対象について，説明を追加した。

サーバ対応の環境設定

start_timeout

stop_timeout

8.4.1(2)

単なる誤字・脱字などはお断りなく訂正しました。

はじめに

このマニュアルは，HAモニタの機能，設定，および運用方法について説明したものです。このマニュアルを読むことで，ユーザが，HAモニタを使用して系切り替え構成を設計・構築できること，および適切に運用できることを目的としています。

このマニュアルでは，HAモニタ，およびHAモニタ Extensionについて説明しています。HAモニタは，システムの可用性を高めるために，系切り替えを実現する製品です。HAモニタ Extensionは，HAモニタのオプション製品です。

＜はじめにの構成＞

対象読者

読書手順

前提機種の違いによる相違点の表記

図中で使用している記号

対象読者

システム管理者，オペレータ，およびプログラマの方を対象としています。システム管理者は，システムの導入，設計，構築をすることを想定しています。オペレータは，構築されたシステムで日々の運用をすることを想定しています。プログラマは，ユーザプログラムの作成をすることを想定しています。

また，次の知識をお持ちの方を前提としています。

該当するハードウェアの知識

該当するOSの知識

系切り替え構成にするプログラムの知識

ユーザプログラムのコーディングに使用するC言語の文法の知識

系切り替え構成にするプログラムとして，OpenTP1またはHiRDBを使用する場合は，あらかじめOpenTP1またはHiRDBのマニュアルをお読みいただくことをお勧めします。

読書手順

このマニュアルは，利用目的に合わせて章を選択して読めます。利用目的別に，次の流れに従ってお読みいただくことをお勧めします。

前提機種の違いによる相違点の表記

HAモニタは前提機種が複数あります。前提機種によって，ハードウェアの構成や名称が異なります。このマニュアルでは，次に示す表記を使用して，機種によって説明の異なる部分を示しています。また，説明が同じ場合は，ハードウェア名称に総称を使用しています。使用している機種のハードウェア名称に読み替えてください。

表記
意味
ハードウェア名称

BladeSymphonyの場合，または（BladeSymphony）
マシンの機種が統合サービスプラットフォームBladeSymphonyの場合に該当します。
SVP
障害管理プロセサ（総称）

HA8000の場合，または（HA8000）
マシンの機種が日立アドバンストサーバHA8000シリーズの場合に該当します。
SVP

HA8500の場合，または（HA8500）
マシンの機種が日立アドバンストサーバHA8500シリーズの場合に該当します。
MPまたはBMC
（まとめてMPと呼びます）

図中で使用している記号

このマニュアルの図中で使用している記号を，次のように定義します。

1.　HAモニタの概要

この章では，HAモニタの目的，主な機能である系切り替えの概要と種類，HAモニタを適用したシステム形態，および動作環境について説明します。

＜この章の構成＞

1.1　HAモニタの目的

1.2　系切り替え

1.3　系切り替えの種類

1.4　HAモニタを適用したシステム形態

1.5　HAモニタの動作環境

1.1　HAモニタの目的

HAモニタは，システムの信頼性向上，稼働率向上を目的として，プログラムを含めたシステムの切り替えを実現します。

UNIXシステムを基幹業務に適用する場合，システムの信頼性や稼働率が重要になります。従来のシステムでは，ディスク装置やLANなどの個々の資源（リソース）を二重化して，信頼性を確保しています。HAモニタを使用することで，リソースの二重化に加えて，サーバシステムの二重化も実現できます。

HAモニタを使用すると，業務処理を実行中のサーバシステムに障害が発生した場合，事前に待機しているサーバシステムに，直ちに自動で切り替えることができます。そのため，オペレータが特に意識することなく，システムの信頼性や稼働率を高められます。

HAモニタの概要を次の図に示します。

図1-1　HAモニタの概要

この図では，サーバシステム1とサーバシステム2を系切り替え構成にしています。サーバシステム1で稼働するプログラムに障害が発生した場合，HAモニタがサーバシステム2のプログラムに系切り替えをします。その結果，障害のために業務を中断していた時間を短縮できます。

HAモニタを使用するシステムには，監視パスおよびリセットパスというハードウェアが必要です。HAモニタに必要なハードウェアやソフトウェアについては，「1.5　HAモニタの動作環境」を参照してください。

1.2　系切り替え

HAモニタでは，システムの障害に備えて二つのシステムを用意し，一つで業務処理を実行させ，もう一つを待機させておきます。用意したこれらのシステムを系といいます。また，システム（系）で業務を実行するプログラムのことをサーバといいます。系切り替えとは，業務を実行している系やサーバに障害が発生した場合に，待機している系やサーバに業務を引き継ぐ機能のことです。

＜この節の構成＞

1.2.1　系

1.2.2　系切り替えの流れ

1.2.3　サーバ

1.2.4　HAモニタが検出する障害

1.2.1　系

系とは，業務処理に必要なハードウェアのほか，実行するプログラムや通信機器も含めたシステム全体の総称です。

系には，実行系と待機系という組み合わせ，または現用系と予備系という組み合わせがあります。

＜この項の構成＞

(1)　実行系と待機系

(2)　現用系と予備系

(1)　実行系と待機系

サーバに業務処理を実行させる系（実行中のサーバがある系）をそのサーバの実行系，障害に備えて待機させる系（待機中のサーバがある系）をそのサーバの待機系と呼びます。

また，現在業務処理を実行しているサーバを実行サーバ，障害に備えて待機しているサーバを待機サーバと呼びます。

(2)　現用系と予備系

システム構築時や環境設定時に二つの系を区別するため，最初に実行系としてサーバを起動する系を，そのサーバの現用系，待機系として起動する系をそのサーバの予備系と呼びます。システム起動後に実行系と待機系の交代を繰り返しても，現用系と予備系の関係は変わりません。

1.2.2　系切り替えの流れ

HAモニタが障害を検出してから，系切り替えをして業務を再開するまでの流れについて説明します。

障害発生時に系切り替えをすると，待機系は業務処理を引き継いで実行系になります。障害が発生した実行系は，さらに障害が発生した場合に備えて待機系になります。以降，障害発生のたびに系切り替えで業務処理の実行と待機とを交代して，どちらかの系で常に業務処理を実行します。

系切り替えの流れを次の図に示します。

図1-2　系切り替えの流れ

1.2.3　サーバ

HAモニタは，サーバというまとまりで系切り替えをします。サーバとは，プログラムのことです。

＜この項の構成＞

(1)　サーバの分類

(2)　サーバの運用方法

(1)　サーバの分類

サーバは，プログラムの種類によって次のどちらかに分けられます。

HAモニタとのインタフェースを持つプログラム
OpenTP1（TP1/Server BaseまたはTP1/EE），およびHiRDBがあります。
なお，HiRDB Version 8以前のサーバ，およびHiRDB Version 9以降のXDS以外のサーバを，プライマリ機能提供サーバと呼びます。

HAモニタとのインタフェースを持たないプログラム
インタフェースを持つプログラム以外すべてを指します。例えば，JP1，Cosminexus，Oracle，ユーザが作成するUAPなどがあります。

(2)　サーバの運用方法

サーバの運用方法には，サーバモードとモニタモードがあります。

サーバモードとモニタモードの比較を次の表に示します。

表1-1　サーバモードとモニタモードの比較

比較項目
サーバモード
モニタモード

OpenTP1（TP1/Server Base）およびHiRDB（プライマリ機能提供サーバ）
OpenTP1（TP1/EE）およびHiRDB（XDS）

HAモニタが検出する障害

サーバ障害

系障害

サーバ障害※1

系障害

UAP障害※2

サーバの監視
HAモニタがする
ユーザがする※1

使用できないHAモニタの機能
なし

サーバのスローダウン検出

サーバがスローダウンしたときの，系のペアダウン

連動系切り替えでサーバがスローダウンしたときの，切り替え種別の指定

サーバの監視履歴取得

サーバのスローダウン検出

系のペアダウン

連動系切り替え時の切り替え種別の指定

ユーザコマンドの一部

サーバの監視履歴取得

待機系のサーバを事前に起動させておくこと

など

必要な設定項目
サーバ対応の環境設定

サーバ対応の環境設定

モニタモードのプログラム対応の環境設定※2

サーバの起動コマンドの作成

（必要に応じて）サーバの停止コマンド・サーバの監視コマンドの作成

（必要に応じて）プログラムの再起動コマンドの作成※2

UAPへのAPIの組み込み※2

1サーバの単位
1プログラム
1プログラムまたは複数プログラム

注※1　ユーザがあらかじめサーバの監視コマンドを作成することで，モニタモードのサーバを監視し，サーバ障害を検出できます。また，モニタモードのプログラム管理機能を使用すれば，UAPの監視はHAモニタがします。プログラム管理機能については，「3.4　プログラムの制御のための機能（モニタモード）」を参照してください。

注※2　モニタモードのプログラム管理機能を使用するプログラムにだけ該当します。

HAモニタとのインタフェースを持つプログラムの場合

サーバの運用方法として，サーバモードまたはモニタモードを選択できます。HAモニタとのインタフェースを持つプログラムの場合，サーバモードでの運用を推奨します。

サーバモードで運用するサーバのことを，HAモニタとのインタフェースを持つサーバと呼ぶこともありますが，このマニュアルでは，サーバモードのサーバと呼びます。

HAモニタとのインタフェースを持たないプログラムの場合

モニタモードで運用します。HAモニタとのインタフェースを持たないプログラムの場合，サーバの運用方法は選択できません。

モニタモードで運用するサーバのことを，HAモニタとのインタフェースを持たないサーバと呼ぶこともありますが，このマニュアルでは，モニタモードのサーバと呼びます。

1.2.4　HAモニタが検出する障害

ここでは，HAモニタが検出する障害について説明します。

HAモニタは，サーバに発生するサーバ障害と，系に発生する系障害を検出して，系切り替えをします。

＜この項の構成＞

(1)　サーバ障害

(2)　系障害

(3)　サーバの運用方法による，検出できる障害の違い

(4)　HAモニタが監視する範囲

(1)　サーバ障害

サーバ障害は，サーバ自身が検知できる障害と，サーバ自身が検知できない障害に分けられます。

(a)　サーバ自身が検知できる障害

サーバ自身が検知できる障害を次に示します。

サーバの論理エラー

リソース（ディスク装置など）の障害が原因で，サーバの運転が続行できない状態

サーバ自身が検知できる障害が発生すると，サーバはHAモニタに障害の発生を連絡して異常終了します。障害連絡を受けたHAモニタは系切り替えを実行します。系切り替え時には，待機していたサーバは引き継ぎ情報からサーバ自身が持つ回復機能で再開始し，業務処理を引き継ぎます。

(b)　サーバ自身が検知できない障害

サーバ自身が検知できない障害には，サーバのスローダウンがあります。

サーバ自身が検知できない障害は，HAモニタが検出します。障害を検出すると，HAモニタは障害が発生したサーバを停止させて系切り替えをします。

(2)　系障害

系障害とは，サーバを除いた系に発生する障害です。系障害を次に示します。

系のハードウェア障害，または電源断
OSなどの機能を使用してハードウェア（プロセサやディスクなど）を冗長化している場合，一つのハードウェアが縮退稼働している間は系障害とは判断しません。

カーネルの障害

HAモニタの障害

すべての監視パスの障害

系のスローダウン

系障害が発生すると，HAモニタは障害が発生した系を停止させて，系切り替えをします。

(3)　サーバの運用方法による，検出できる障害の違い

サーバをサーバモードで運用するか，モニタモードで運用するかによって，検出できる障害が異なります。障害の分類，検出方法，およびサーバの運用方法での検出可否を次の表に示します。

表1-2　障害の分類，検出方法，およびサーバの運用方法での検出可否

障害の分類
検出方法
サーバモード
モニタモード

サーバ障害
サーバが検知してHAモニタに連絡する
○
○
（サーバの監視コマンドの作成が必要※1）

HAモニタがサーバを監視して検出する
○
×※2

系障害
HAモニタが系を監視して検出する
○
○

（凡例）

○：検出できます。

×：検出できません。

注※1

モニタモードの場合，サーバ自身が検知できる障害が発生したときに，HAモニタで自動的に系切り替えをするには，サーバの監視コマンドを作成する必要があります。詳細については，「3.1.1　モニタモードのサーバの監視」を参照してください。ただし，モニタモードのプログラム管理機能でUAPを監視すれば，サーバの監視コマンドにUAPの監視処理を組み込む必要がなくなります。詳細については，「3.4.1　UAPの監視」を参照してください。

注※2

モニタモードのプログラム管理機能を使用すれば，UAPを監視できます。

(4)　HAモニタが監視する範囲

HAモニタは，サーバ障害および系障害を検出するために，サーバや系を監視しています。

システム構成のうち，HAモニタが監視する範囲を次の図に示します。

図1-3　HAモニタが監視する範囲

HAモニタは，共有ディスクなどのリソースに発生した障害は検出しません。ただし，リソースに発生した障害が原因で，サーバ障害が発生した場合は，サーバ障害を検出します。

1.3　系切り替えの種類

HAモニタで使用できる系切り替えの種類には，HAモニタが自動的に系切り替えをする自動系切り替えと，オペレータが意図的に系切り替えをする計画系切り替えがあります。

＜この節の構成＞

1.3.1　自動系切り替え

1.3.2　計画系切り替え

1.3.1　自動系切り替え

実行系に障害が発生した場合，HAモニタが自動的に系を切り替える機能を自動系切り替えといいます。

ユーザは，自動系切り替えに必要な，サーバの名称や共有リソースの名称などの動作環境を，事前に系ごとに設定しておきます。HAモニタはこの環境設定の情報を基に，障害発生時にサーバや共有リソースを制御して，自動的に系切り替えをします。

自動系切り替えの概要を，次の図に示します。

図1-4　自動系切り替えの概要

1.3.2　計画系切り替え

オペレータが，系のメンテナンスなどをする際に計画的に系を切り替える機能を計画系切り替えといいます。計画系切り替えは，実行系から計画系切り替えコマンド（monswapコマンド）を実行します。

計画系切り替えをする場合も，HAモニタは自動系切り替えと同じ環境設定の情報を基に，系切り替えをします。

計画系切り替えの概要を，次の図に示します。

図1-5　計画系切り替えの概要

1.4　HAモニタを適用したシステム形態

HAモニタを適用したシステム形態について説明します。HAモニタを使用することで，信頼性の向上や稼働率の向上を実現できます。

＜この節の構成＞

1.4.1　C/Sシステム形態

1.4.2　FEP形態

1.4.3　分散処理システム形態

1.4.1　C/Sシステム形態

ホストコンピュータを使用しないで，クライアント/サーバシステムだけで構成するシステム形態です。複数のシステムをLANで接続することで，各システムが互いに連動し合って，全体で一つの業務処理システムとして動作します。

サーバシステムにHAモニタを導入すると，サーバ障害による不稼働時間を短縮でき，クライアントの業務処理への影響を減らせます。

C/Sシステム形態の例を次の図に示します。

図1-6　C/Sシステム形態例

1.4.2　FEP形態

ホストコンピュータと，分散機および端末との間に，FEPと呼ばれるサーバシステムを置いたシステム形態です。通常，ホストコンピュータとFEPとは高速LANで接続します。FEPは，ホストコンピュータで処理していた通信プロトコル処理や業務処理の一部を，ホストコンピュータに代わって実行します。

FEPにHAモニタを導入すると，障害によるFEPの不稼働時間を短縮でき，ホストコンピュータの高信頼化とあわせて，センタの業務処理の中断を最小限に抑えられます。

FEP形態の例を次の図に示します。

図1-7　FEP形態例

1.4.3　分散処理システム形態

営業店や支店などの拠点に設置した，分散システムと呼ばれるサーバシステムをホストコンピュータに接続する形態です。分散システムは，ホストコンピュータの業務の分散処理や，分散されたデータの管理などをします。

分散システムにHAモニタを導入すると，障害による分散システムの不稼働時間を短縮でき，拠点の業務処理の中断を最小限に抑えられます。

分散処理システム形態の例を次の図に示します。

図1-8　分散処理システム形態例

1.5　HAモニタの動作環境

HAモニタを動作させるために必要なハードウェア，およびソフトウェアについて説明します。

＜この節の構成＞

1.5.1　必要なハードウェア

1.5.2　必要なソフトウェア

1.5.1　必要なハードウェア

HAモニタを動作させるために必要なハードウェアについて説明します。ハードウェアの構成については，「5.5　ハードウェア構成の検討」を参照してください。

ハードウェア構成例を次の図に示します。

図1-9　ハードウェア構成例

＜この項の構成＞

(1)　プロセサ

(2)　監視パス

(3)　リセットパス

(4)　共有ディスク

(5)　ローカルディスク

(6)　コンソール

(7)　LAN

(1)　プロセサ

実際に業務を処理するサーバマシンを，実行系と待機系とで1台ずつ使用します。

HAモニタを使用する前提機種を次に示します。

統合サービスプラットフォームBladeSymphony
BladeSymphonyを使用する場合，一つの筐体（シャーシ）に複数のプロセサを搭載できます。HAモニタでは，一つのシャーシ内にあるプロセサ同士を系切り替え構成にできます。

日立アドバンストサーバHA8000シリーズ（OSがLinux（x86）の場合）

日立アドバンストサーバHA8500シリーズ（OSがLinux（IPF）の場合）

参考

BladeSymphonyを使用する場合，日立サーバ仮想化機構（Virtage）を利用すると，プロセサ内の論理パーティション（LPAR）を系切り替え構成の単位にできます。

また，BladeSymphonyまたはHA8000を使用する場合，VMware ESXiを利用して一つのプロセサ上で複数の仮想マシンを稼働させ，仮想マシンを系切り替え構成の単位にできます。

(2)　監視パス

実行系と待機系のプロセサ間を接続して，実行系と待機系との間で，互いの系を監視したり，系切り替えのための情報を交換したりするために使用します。

監視パスには，監視パス専用のLAN（監視専用LAN）として，TCP/IP LANを使用できます。HAモニタは，TCP/IP LANでブロードキャストで通信するため，ブロードキャストで通信できるLANを使用してください。TCP/IP LANは，どの系切り替え構成でも使用できますが，専用のIPアドレスとポート番号が必要です。

また，HAモニタ Extensionを使用して，一つの系切り替え構成での系の最大数を変更する場合は，マルチキャストで通信できるLANを使用してください。HAモニタ Extensionについては，「3.5　HAモニタ Extensionの機能」を参照してください。

(3)　リセットパス

実行系と待機系の障害管理プロセサ間を接続※して，実行系で障害が発生した場合に，系の入出力のリセットを指示するために使用します。障害管理プロセサとは，システム構成の設定やCPUの制御などができるハードウェアです。CPUとは独立したハードウェアとして，マシンに搭載されています。使用するマシンの機種によって，SVP，MP，またはBMCのように名称が異なりますが，機能は同じであるため，このマニュアルでは総称して，障害管理プロセサと呼びます。

リセットパスには，リセット専用のLAN（リセット専用LAN）として，TCP/IP LANを使用します。

リセットパスに関する注意事項については，「5.5.4　リセットパスの構成」を参照してください。

注※

VMware ESXiで仮想化する場合は，障害管理プロセサ（SVP）に加えてVMware ESXiとも接続します。

(4)　共有ディスク

共有ディスクは，サーバが実行系と待機系とで共有するデータを格納するために使用します。必須ではありません。系切り替え時には，共有ディスク上の情報が引き継がれます。共有ディスクには格納したデータを使用するすべての系を接続し，LVMまたはHA Boosterを使用して制御します。

使用できる共有ディスクには，日立ディスクアレイシステムなどがあります。

HAモニタは，ディスク障害やI/Oパス障害に対応していません。これらの障害に対しては，HAモニタ以外の方法を使用して共有ディスクの単一点障害を防止する構成にしてください。単一点障害の防止については，「5.5.1　共有ディスクの構成」を参照してください。

(5)　ローカルディスク

系間で共有しない，系固有のディスク装置として使用します。OSのファイルや，HAモニタの各種ファイルをインストールしておきます。HAモニタは，共有ディスクではなく，ローカルディスクから起動します。

また，ローカルディスクについても共有ディスクと同様に単一点障害を防止する構成にすることを推奨します。

(6)　コンソール

HAモニタのコマンドを実行したり，出力されるメッセージを確認したりするために使用します。

(7)　LAN

LANは，実行系と待機系を接続したり，クライアントとなるWSやPCと接続したりするために使用します。必須ではありません。TCP/IP通信ができるLANのうち，OSがサポートするEthernet LANを使用できます。

HAモニタは，HUBやLANアダプタなどのLAN障害を直接処理するものではありません。これらの障害に対しては，HAモニタ以外の方法を使用して，LANの単一点障害を防止する構成にしてください。単一点障害の防止については，「5.5.2　LANの構成」を参照してください。

1.5.2　必要なソフトウェア

HAモニタを動作させるために必要なソフトウェアについて説明します。ソフトウェア構成例を，次の図に示します。

図1-10　ソフトウェア構成例

＜この項の構成＞

(1)　カーネル

(2)　系切り替え制御

(3)　運用管理

(4)　プログラム

(1)　カーネル

Linux（x86）またはLinux（IPF）

システムの基盤となるオペレーティングシステムです。

HA Booster

共有ディスクの切り替えを高速にしたり，他系でのOSパニックを検知したりするための製品です。

(2)　系切り替え制御

HAモニタ

系切り替えを制御します。

HAモニタ Extension

HAモニタのオプション製品です。HAモニタ Extensionを使用すると，大規模なシステム構成での系切り替えの制御に対応できます。

HAモニタ Extensionは，OSがLinux（x86）の場合に使用できます。

HAモニタ Extensionについては，「3.5　HAモニタ Extensionの機能」を参照してください。

(3)　運用管理

JP1

システム内で発生したイベントを管理します。

(4)　プログラム

HAモニタを使用した系切り替え構成では，HAモニタとのインタフェースを持つか，持たないかによって，HAモニタで使用できる機能の範囲が異なります。HAモニタで使用できるプログラムを次に示します。

(a)　HAモニタとのインタフェースを持つプログラム

OpenTP1

分散トランザクション処理を実現する，トランザクション処理モニタです。

HiRDB

スケーラブルなシステム構築を実現する，リレーショナルデータベース管理システムです。

(b)　HAモニタとのインタフェースを持たないプログラム

Cosminexus

ビジネスを具現化する，アプリケーション基盤です。アプリケーションサーバ，SOA基盤製品，OLTP製品，帳票関連製品などがあります。

JP1

ITシステムの安定した運用を支える，統合システム運用管理製品です。統合管理製品，ジョブ管理製品，資産・配布管理製品，ネットワーク管理製品などがあります。

その他のサーバ

UAPなど，前述以外のサーバを示します。

2.　HAモニタを使用した系切り替え

この章では，障害が発生したあとにHAモニタが行う系切り替えについて説明します。系切り替えという概念を理解している方に向けて，HAモニタではどのように系を切り替えるのか，を中心に説明します。

HAモニタで実現できる系切り替え構成，障害検出から系切り替えまでのおおまかな流れ，HAモニタがサーバや系をどのように監視しているか，およびサーバが使用している共有リソースをどのように待機系に引き継ぐのか，について説明します。

＜この章の構成＞

2.1　系切り替え構成

2.2　障害検出から系切り替えまでの流れ

2.3　HAモニタによる障害検出

2.4　共有リソースの引き継ぎ

2.1　系切り替え構成

HAモニタでは，次の系切り替え構成を実現できます。ここでは，構成例について説明します。各構成の特徴については，「5.2　系切り替え構成の検討」を参照してください。

＜この節の構成＞

2.1.1　1:1系切り替え構成

2.1.2　相互系切り替え構成

2.1.3　2:1系切り替え構成

2.1.4　複数スタンバイ構成

2.1.5　クラスタ型系切り替え構成

2.1.1　1:1系切り替え構成

現用系と予備系が1:1に対応している構成です。現用系に障害が発生すると，予備系に切り替えます。

1:1系切り替え構成の例を次の図に示します。

図2-1　1:1系切り替え構成例

2.1.2　相互系切り替え構成

各サーバシステムが現用系として動作しながら互いの予備系になる構成です。どちらか一方の系に障害が発生すると，他方の系に切り替えます。

相互系切り替え構成の例を次の図に示します。

図2-2　相互系切り替え構成例

2.1.3　2:1系切り替え構成

二つの現用系に一つの予備系を準備する構成です。予備系には二つのサーバを待機させておきます。どちらか一方の現用系に障害が発生すると，障害が発生した方を予備系に切り替えます。

2:1系切り替え構成の例を次の図に示します。

図2-3　2:1系切り替え構成例

2.1.4　複数スタンバイ構成

一つの現用系に複数の予備系を準備して，ある業務処理を実行するサーバに対して，複数のサーバを待機させる構成です。複数のサーバを待機させておくため，現用系の障害が復旧するまでに，予備系で障害が発生しても，別の予備系に系切り替えができます。システムの障害に備えることができるため，システムの稼働率を高められます。

複数スタンバイ構成の例を次の図に示します。

図2-4　複数スタンバイ構成例

この構成にする場合には，マルチスタンバイ機能を使用します。マルチスタンバイ機能の詳細については，「4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理」を参照してください。

2.1.5　クラスタ型系切り替え構成

1:1系切り替え構成などの複数の系切り替え構成を組み合わせた，クラスタ型系切り替え構成について説明します。

クラスタ型系切り替え構成は，クラスタ型に接続した複数のサーバシステムが，現用系として動作しながら互いの予備系になる構成です。クラスタ型系切り替え構成でのサーバシステムは，最大で32台接続できます。

クラスタ型系切り替え構成は，一つのサーバシステムで，業務処理を実行するサーバや待機するサーバなど，複数のサーバを起動させることで実現できます。また，ある業務処理を実行するサーバに対して，複数のサーバを待機させることもできます。

＜この項の構成＞

(1)　業務処理を実行するサーバと待機するサーバが1:1に対応する例

(2)　業務処理を実行するサーバに対して，複数のサーバが待機する例

(1)　業務処理を実行するサーバと待機するサーバが1:1に対応する例

クラスタ型系切り替え構成のうち，業務処理を実行するサーバと待機するサーバが1:1に対応する例を次の図に示します。

図2-5　クラスタ型系切り替え構成例（実行するサーバと待機するサーバが1:1の場合）

(2)　業務処理を実行するサーバに対して，複数のサーバが待機する例

クラスタ型系切り替え構成のうち，業務処理を実行するサーバに対して，複数のサーバが待機する例を次の図に示します。この例では，ある業務処理を実行するサーバに対して，複数のサーバをすべての系で待機させておくため，現用系の障害が復旧するまでの間も，システムの障害に備えることができます。

図2-6　クラスタ型系切り替え構成例（実行するサーバに対して複数のサーバが待機する場合）

この構成にする場合には，マルチスタンバイ機能を使用します。マルチスタンバイ機能の詳細については，「4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理」を参照してください。

2.2　障害検出から系切り替えまでの流れ

HAモニタが検出する障害には，大きく分けてサーバ障害と，系障害があります。障害の種類によって，系切り替えの処理や流れが異なります。

サーバ障害発生時には，障害が発生したサーバを共有リソースから切り離し，待機系のサーバに切り替えます。系障害発生時には，系のリセットをして，待機系のサーバに切り替えます。ここでは，障害検出から系切り替えまでの流れの概要について説明します。詳細な処理の流れについては，「4.8　処理の流れ」を参照してください。

＜この節の構成＞

2.2.1　サーバ障害時の系切り替え

2.2.2　系障害時の系切り替え

2.2.1　サーバ障害時の系切り替え

サーバ障害時には，障害が発生した実行系のHAモニタは，系切り替え準備処理として，実行系の共有リソースの切り離しをします。共有ディスクのアクセス禁止や，LANの切り離しなどの系切り替え準備処理が完了すると，待機系にその旨を連絡します。待機系では，連絡を受けたあと，系切り替え処理を開始します。

サーバ障害時の，HAモニタの系切り替えの概要を，次の図に示します。

図2-7　サーバ障害時の系切り替えの概要

2.2.2　系障害時の系切り替え

系障害時には，待機系のHAモニタがリセットパスを介して障害が発生した系の障害管理プロセサに実行系のリセットを要求します。障害が発生した系の障害管理プロセサは，入出力の停止などのリセット処理をします。障害が発生した系は，リセット処理が完了すると，待機系にその旨を連絡します。待機系では，連絡を受けたあと，系切り替え処理を開始します。

系障害時の，HAモニタの系切り替えの概要を，次の図に示します。

図2-8　系障害時の系切り替えの概要

2.3　HAモニタによる障害検出

HAモニタを使用したシステムに障害が発生したら，HAモニタが障害を検出します。HAモニタが障害を検出した時点で系切り替えができる状態だった場合は，HAモニタが系切り替えをします。系切り替えができる状態ではなかった場合，系切り替えはされません。

システムに発生する障害にはサーバ障害と系障害があり，障害の種類によって検出方法が異なります。ここでは，障害の検出方法を障害の種類別に説明します。また，HAモニタが系切り替えをする条件，および系切り替えを実現する方法である系のリセットの仕組みについても説明します。

＜この節の構成＞

2.3.1　HAモニタが系切り替えをする条件

2.3.2　サーバ障害の検出（サーバモードの場合）

2.3.3　サーバ障害の検出（モニタモードの場合）

2.3.4　系障害の検出

2.3.5　系のリセット

2.3.1　HAモニタが系切り替えをする条件

HAモニタが系切り替えをするには，幾つかの条件が前提になります。前提となる条件がそろった状態を，系切り替えができる状態と呼びます。

＜この項の構成＞

(1)　サーバ障害発生時に系切り替えをする条件

(2)　系障害発生時に系切り替えをする条件

(1)　サーバ障害発生時に系切り替えをする条件

サーバ障害発生時に系切り替えをする条件を次に示します。

待機系のHAモニタと，監視パスで通信できる状態であること。

実行サーバに対応する待機サーバが待機中であること。

(2)　系障害発生時に系切り替えをする条件

系障害発生時に系切り替えをする条件を次に示します。

待機系のHAモニタと，監視パスで通信できる状態であること。

実行サーバに対応する待機サーバが待機中であること。

リセットパスが使用できる状態であること。

2.3.2　サーバ障害の検出（サーバモードの場合）

サーバがサーバモードの場合，HAモニタがサーバを監視し，サーバ障害が発生したら，系切り替えをします。ここでは，HAモニタが行うサーバ障害の検出方法と，障害を検出したあとのHAモニタの動作について説明します。

＜この項の構成＞

(1)　サーバ障害の検出方法

(2)　サーバ障害を検出したあとのHAモニタの動作

(1)　サーバ障害の検出方法

サーバ障害は，サーバ自身が検知できる障害と，検知できない障害とに分けられます。

サーバ自身が検知できる障害が発生した場合

HAモニタはサーバから障害連絡を受けて，サーバ障害を検出します。

サーバ自身が検知できない障害が発生した場合

実行サーバでは，HAモニタが障害を検出します。サーバの監視方法は，使用するプログラムによって異なります。

TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）を使用するとき

サーバの稼働報告をHAモニタが監視する方法によって，障害を検出します。サーバの稼働報告を監視するためには，サーバ対応の環境設定のpatrolオペランドでサーバ障害監視時間を指定します。指定したサーバ障害監視時間を超えてもサーバからの稼働報告がなかった場合，HAモニタはサーバ障害が発生したと判断します。サーバの稼働報告を監視するには，サーバ対応の環境設定のserver_typeオペランドに"A"を指定するか，またはserver_typeオペランドの指定を省略します。

TP1/EEまたはHiRDB（XDS）を使用するとき

サーバのプロセスをHAモニタが監視する方法によって，障害を検出します。この方法では，HAモニタはサーバのスローダウンを障害として検出しません。サーバのプロセスを監視するには，サーバ対応の環境設定のserver_typeオペランドに"B"を指定します。

なお，待機サーバでは，HAモニタは障害を検出しません。ユーザが必要に応じて待機サーバを再起動したり，停止したりします。

(2)　サーバ障害を検出したあとのHAモニタの動作

HAモニタが実行サーバに発生したサーバ障害を検出すると，系切り替えができる状態の場合，次のどれかの動作をします。この動作は，サーバ対応の環境設定のswitchtypeオペランドでユーザがあらかじめ指定します。

系切り替えをする。
障害が発生した実行サーバを強制停止したあとに，系切り替えをして，待機系の待機サーバに業務を切り替えます。

実行サーバの再起動を待ち，再起動できなければ系切り替えをする。
障害が発生した実行サーバをいったん停止させ，再起動するのを待ちます。実行サーバの再起動に失敗したままの場合，HAモニタが待機系に系切り替えをします。

実行サーバの再起動を待ち，再起動できなければオペレータの操作を待つ。
障害が発生した実行サーバをいったん停止させ，再起動するのを待ちます。実行サーバの再起動に失敗したままの場合，HAモニタは実行サーバを停止させて，オペレータの操作を待ちます。
ただし，この設定にした場合，HAモニタは実行サーバのスローダウンをサーバ障害と認識しません。実行サーバのスローダウンを検出したときは，HAモニタはメッセージを出力してサーバの監視を続けます。

それぞれの動作について，詳細を説明します。

(a)　系切り替えをする場合

サーバ障害を検出すると，実行系のHAモニタが実行サーバを強制停止して，待機系に系切り替えをします。稼働報告がなかったケースを例にして，サーバ障害検出時のHAモニタの動作を，次の図に示します。

図2-9　サーバ障害検出時のHAモニタの動作（系切り替えをする場合）

(b)　実行サーバの再起動を待ち，再起動できなければ系切り替えをする場合

サーバ障害を検出すると，HAモニタは，サーバ障害が発生した実行サーバの再起動を待ちます。この実行サーバが再起動するまでの実行サーバの状態を，再起動待ち状態と呼びます。

実行サーバが再起動できた場合は，HAモニタは系切り替えをしないため，障害発生後も業務を実行する系は変わりません。実行サーバが再起動に失敗した場合，サーバに対応するプログラムは，プログラムのリトライ回数だけ，再起動を試みます。実行サーバが再起動に失敗し，HAモニタが実行サーバの再起動限界を検出した場合は，HAモニタが待機系に系切り替えをします。系切り替え時のHAモニタの動作は「(a)　系切り替えをする場合」と同様です。

実行サーバの再起動限界とは，実行サーバを再起動させる上限のことです。実行サーバの再起動限界としてHAモニタが検出するのは，次のとおりです。

プログラムのリトライ回数の限界
再起動をリトライする回数の上限のことです。プログラムに指定します。

実行サーバの再起動監視時間の限界
実行サーバに発生したサーバ障害を検出してから，実行サーバが再起動するまでの監視時間のことです。サーバ対応の環境設定に指定します。

(c)　実行サーバの再起動を待ち，再起動できなければオペレータの操作を待つ場合

サーバ障害を検出したあと，実行サーバの再起動を待ち，再起動できなければオペレータの操作を待つ場合について説明します。

実行サーバの再起動を実施する動作は，「(b)　実行サーバの再起動を待ち，再起動できなければ系切り替えをする場合」と同様です。しかし，オペレータの操作を待つ場合は，実行サーバの再起動限界として，プログラムのリトライ回数だけを指定できます。

実行サーバが再起動に失敗し，HAモニタが実行サーバの再起動限界を検出すると，HAモニタは，実行系の実行サーバを停止させます。また，待機系では，障害が発生した実行サーバに対応する待機サーバを，いったん停止させたあとに再起動して，実行サーバの起動待ち状態にします。このとき，ユーザは，実行サーバの起動待ち状態になっている待機サーバを，実行サーバとして起動するか，または停止する必要があります。待ち状態のサーバを操作する方法については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

2.3.3　サーバ障害の検出（モニタモードの場合）

サーバがモニタモードの場合，サーバ障害の検出方法は，APIを発行するかどうかで異なります。

＜この項の構成＞

(1)　APIを発行しない場合

(2)　APIを発行する場合

(1)　APIを発行しない場合

HAモニタはサーバを監視しないため，サーバ障害を検出しません。系障害だけを検出します。

モニタモードのサーバにサーバ障害が発生した場合，ユーザは次のように対処します。

待機系への系切り替えが必要な場合
実行サーバを停止させ，実行系から計画系切り替えコマンド（monswapコマンド）を実行して，系切り替えをします。

待機系への系切り替えが不要な場合
実行系でサーバを再起動します。

ユーザがあらかじめサーバの監視コマンドで，サーバ障害を監視する処理を作成しておくと，サーバ障害が発生した場合にHAモニタが系切り替えを実行できます。サーバの監視コマンドの詳細については，「3.1.1　モニタモードのサーバの監視」を参照してください。

(2)　APIを発行する場合

モニタモードのプログラム管理機能を使用してUAPからAPIを発行すれば，HAモニタがUAPを監視し，サーバのスローダウンを検出できます。

UAPのプロセス，およびUAPの稼働報告を監視することで，HAモニタはUAPに起因するサーバ障害を検出します。UAPのプロセスと稼働報告の両方を監視するか，UAPのプロセスだけを監視するかは選択できます。

また，UAP障害を検出すると，HAモニタはプログラムの再起動コマンドでUAPを再起動することもできます。プログラムの再起動コマンドは，ユーザがあらかじめ作成しておくコマンドです。

UAPの監視については，「3.4.1　UAPの監視」を参照してください。

2.3.4　系障害の検出

系間の監視，リセットパスや監視パスの監視などについて説明します。

＜この項の構成＞

(1)　系間の監視

(2)　リセットパスのヘルスチェック

(3)　監視パスのヘルスチェック

(4)　問い合わせ応答メッセージのリトライ

(5)　自系のスローダウン認識

(1)　系間の監視

実行系と待機系のHAモニタは，互いに一定時間ごとに報告するaliveメッセージを確認し合う方法で，系を監視します。ここでは，aliveメッセージによる系間の監視について説明します。

(a)　aliveメッセージによる系障害の検出

HAモニタは，aliveメッセージの途絶によって系障害を検出します。そのため，aliveメッセージを最後に受信してから系障害と判断するまでの時間（系障害監視時間）を，HAモニタの環境設定のpatrolオペランドに指定しておきます。なお，aliveメッセージの送信間隔は，HAモニタの環境設定のalive_intervalオペランドで指定できます。系障害監視時間を短く設定する場合は，aliveメッセージの送信間隔の設定をデフォルトから変更することを強く推奨します。

aliveメッセージの送信は，他系のHAモニタと連絡が取れ，系切り替えができる状態になった時点で開始されます。aliveメッセージの送受信は，監視パスを介して行われます。指定した系障害監視時間を超えても他系からaliveメッセージが送信されなかった場合，HAモニタは他系に系障害が発生したと判断します。

実行系と待機系のHAモニタは，デフォルトでは，互いに1秒間隔でaliveメッセージを確認し合っています。HAモニタの環境設定のpatrol_100msオペランドを指定すると，aliveメッセージの確認間隔を100ミリ秒に変更できます。系障害監視時間を短く設定する場合は，100ミリ秒間隔でaliveメッセージを確認することを推奨します。

(b)　aliveメッセージの通信方式

HAモニタは，ユニキャストでaliveメッセージを送受信します。ユニキャストでは，監視パス当たり接続ホスト台数分のaliveメッセージを送受信します。

ただし，HAモニタ Extensionを使用して系の最大数を33以上に設定する場合，HAモニタは，マルチキャストでaliveメッセージを送受信します。マルチキャストでは，監視パス当たり一つのaliveメッセージを送受信します。送受信するメッセージの量および送受信に掛かる処理量を削減できるため，マシンのCPU利用率の上昇が抑えられ，監視パスに使用するLANへの負荷を軽減できます。系の最大数の変更については，「3.5.2　系の最大数の変更」を参照してください。

(2)　リセットパスのヘルスチェック

系障害時に系リセットができるかどうかを判断するために，HAモニタでは接続するすべての他系の障害管理プロセサの状態をヘルスチェックしています。

ヘルスチェックは，自系と接続した他系が実行サーバと待機サーバの起動完了によって系切り替えができる状態になった時点で開始します。それ以降は，2分ごとにチェックします。この間隔はHAモニタの環境設定のresetpatrolオペランドで設定できます。

マシンの機種がHA8500の場合は，系間が接続されたときにも一度ヘルスチェックを実施します。

ヘルスチェックは待機系から実行しますが，次のどれかの場合は実行系からも実行します。

HAモニタの環境設定のstandbyresetオペランドにuseを指定している場合

マルチスタンバイ機能を使用している場合※

HAモニタの環境設定のreset_typeオペランドでhostを指定している場合※

注※

これらの場合は，系間が接続された時点でヘルスチェックを開始します。系間が接続されている間は，ヘルスチェックを続けます。

障害管理プロセサ，またはリセットパスの障害を検出すると，HAモニタは障害検出のメッセージを出力し，該当する系に対するリセットパスのヘルスチェックを中断します。メッセージが出力された場合の処置は，マニュアル「高信頼化システム監視機能 HAモニタ メッセージ」を参照してください。また，ユーザはHAモニタのコマンドを使用して，障害管理プロセサの状態を表示できます。障害管理プロセサの状態を表示するコマンドは，使用するマシンの機種によって異なります。それぞれ機種に応じたコマンドを使用してください。コマンドの詳細については，「9.　コマンド」を参照してください。なお，障害からの回復後，次のコマンドを使用することで，中断していたヘルスチェックを再開できます。

BladeSymphonyまたはHA8000の場合：リセットパス状態表示コマンド（monrpコマンド）

HA8500の場合：MP状態表示コマンド（monmpコマンド）

参考

マシンの機種がBladeSymphonyの場合，HAモニタの環境設定のresetpatrol_modeオペランドを指定する必要があります。詳細については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

(3)　監視パスのヘルスチェック

HAモニタでは，監視パスの状態を一定間隔でヘルスチェックできます。ヘルスチェックの間隔は，HAモニタの環境設定のpathpatrolオペランドで指定します。監視パスに障害が発生すると，HAモニタは通信障害のメッセージを出力します。

監視パスの状態は，HAモニタを起動してから，環境設定でヘルスチェック間隔に指定した時間が経過した時点でチェックします。それ以降は，指定したヘルスチェック間隔でチェックします。ヘルスチェックは，系に接続しているすべての監視パスについて実行し，HAモニタの停止時に終了します。また，自系と他系に監視パスが接続されていて，HAモニタが稼働している場合にだけチェックします。

監視パスの障害を検出した場合，HAモニタの環境設定のpathpatrol_retryオペランドを指定していれば，監視パスの状態を再チェックできます。再チェックしても障害を検出した場合，HAモニタは次に示すメッセージのどれかを出力します。

KAMN609-W

KAMN635-E

KAMN640-E

KAMN641-W
メッセージKAMN641-Wは，一度出力するか，または監視パス状態表示コマンド（monpathコマンド）で障害を検出すると，以降は障害が回復するまで出力しません。

メッセージが出力された場合の処置は，マニュアル「高信頼化システム監視機能 HAモニタ メッセージ」で示す説明に従ってください。また，ユーザは監視パス状態表示コマンド（monpathコマンド）で監視パスの状態を表示できます。

(4)　問い合わせ応答メッセージのリトライ

HAモニタでは，aliveメッセージ以外にも，監視パスを使用して他系とメッセージをやり取りしています。例えば，サーバの起動時に，同じサーバが他系ですでに起動していないかどうかを確認するための問い合わせ応答メッセージなども，監視パスを使用して送受信しています。

これらの問い合わせ応答メッセージの送信に失敗した場合は，HAモニタが3秒間隔でメッセージ送信をリトライし，送信が成功するまでリトライを続けます。HAモニタの環境設定のmessage_retryオペランドを指定しておくと，ユーザがメッセージ送信のリトライ間隔を指定できます。

aliveメッセージの送信が開始される前など，系間の監視中でない場合，問い合わせ応答メッセージの送信が60秒※を超えても成功しないと，HAモニタは系障害が発生したと判断します。

注※

HAモニタの環境設定のmessage_retryオペランドの指定が60秒以上の場合は，その時間を超えても送信が成功しないときにHAモニタは系障害が発生したと判断します。

(5)　自系のスローダウン認識

システムの高負荷などの理由から，HAモニタの環境設定のpatrolオペランドに指定した系障害監視時間以上動作できなかった場合（系のスローダウン）のHAモニタの動作について説明します。

実行系にスローダウンが発生した場合，HAモニタは，待機系に系切り替えをします。

一方，待機系にスローダウンが発生した場合は，実行系のHAモニタは待機系の系障害が発生したと判断します。この場合，待機系がスローダウンから回復すると，待機系のHAモニタは待機系に系障害が発生したとは判断していないため，系間で状態が不一致となります。

このため，待機系のHAモニタは，待機系がスローダウンから回復した時点で系間を再接続し，待機サーバを再起動します。これによって，自動的に系間の状態を一致させ，実行系と待機系の両方の系の監視を再開させます。

2.3.5　系のリセット

系のリセットとは，障害が発生した系の入出力を閉塞させるため，システムを強制停止させることです。系のリセットによって，同じ実行サーバが複数の系で稼働することを防ぎます。

系のリセットは，HAモニタと障害管理プロセサが連携することで実現しています。VMware ESXiで仮想化する場合は，VMware ESXiと連携します。

HAモニタは系障害を監視し，系障害を検出した時点で系切り替えができる状態だった場合は，系のリセットを要求します。通常は，待機系が，障害が発生した実行系をリセットします（実行系のリセット）。系切り替え構成の種類によっては，実行系が待機系をリセットすることもできます（待機系のリセット）。

＜この項の構成＞

(1)　実行系のリセット

(2)　待機系のリセット

(1)　実行系のリセット

実行系の系障害を待機系で検出すると，HAモニタはリセットパスを介してリセットコマンドを発行し，実行系の障害管理プロセサに実行系のリセットを要求します。リセット時には，システムダンプが取得できる状態であれば，OSの機能によって，リセットされた系のシステムダンプが取得されます。リセットが完了すると，HAモニタが系切り替えを開始します。リセットが失敗した場合は，ユーザが手動でリセットして，システムダンプを取得する必要があります。

システムダンプを正常に取得するには，Linux Tough Dumpが必要です。Linux Tough Dumpについては，弊社担当営業にお問い合わせください。

HAモニタが行う系の状態監視と系のリセットを，次の図に示します。

図2-10　系の状態監視と系のリセット

HAモニタは，aliveメッセージを送信し合って，他系の状態監視をします。実行系で系障害が発生すると，待機系のHAモニタは実行系からのaliveメッセージを受信できないため，待機系のHAモニタは障害管理プロセサ※にリセットを要求します。要求を受けた障害管理プロセサ※は，系のリセットを指示します。

注※

VMware ESXiで仮想化する場合は，障害管理プロセサではなくVMware ESXiになります。

系のリセットはハードウェアとの連携で実現しているので，系ごとに固有のホストアドレスをHAモニタの環境設定のaddressオペランドで指定しておきます。指定するホストアドレスは，TCP/IPのIPアドレスやOSIのMACアドレスではなく，HAモニタの管理者が任意に指定するアドレスです。マシンの機種がHA8500の場合，系ごとに設定した障害管理プロセサのIPアドレスに対応するホスト名を，HAモニタの環境設定で指定しておきます。

マシンの機種がBladeSymphonyの場合，系障害が発生した実行系と，リセット指示を出す待機系が同じシャーシ内にあることもありますが，HAモニタおよび障害管理プロセサの動作は変わりません。

VMware ESXiで仮想化する場合，実行系のHAモニタが動作する仮想マシンに障害が発生すると，待機系のHAモニタは障害が発生した仮想マシンだけをリセットします。待機系のHAモニタが実行系のHAモニタの仮想マシンを管理するVMware ESXiにリセットを要求し，障害となった仮想マシンがリセットされます。そのため，VMware ESXiで仮想化する場合，通常の設定に加え，VMware ESXiのIPアドレスおよび仮想マシン名をHAモニタの環境設定コマンド（monsetupコマンド）で設定しておく必要があります。

なお，日立サーバ仮想化機構（Virtage）またはVMware ESXiによる仮想化環境で系のリセットに失敗した場合，物理パーティションリセット機能を使用してプロセサ全体をリセットすることもできます。物理パーティションリセット機能については，「3.2.8　仮想化環境での物理パーティションリセット機能」を参照してください。

(2)　待機系のリセット

系切り替え構成の種類によっては，実行系やほかの待機系が，待機系をリセットすることがあります。

(a)　1:1系切り替え構成の場合

HAモニタの環境設定のpatrolオペランドに指定した系障害監視時間を超えても待機系からaliveメッセージが送信されなかった場合，実行系のHAモニタは，待機系に系障害が発生したと判断します。この場合，実行サーバでは業務を継続できるため，実行系のHAモニタは何もしません。

ただし，待機系に系障害が発生した状態では，実行系に障害が発生した場合に待機系に系切り替えができません。そのため，待機系の系障害を検出した時点で，実行系のHAモニタに待機系をリセットさせることもできます。系障害時に待機系をリセットするかどうかは，HAモニタの環境設定のstandbyresetオペランドで指定します。なお，待機系のリセットは，1:1系切り替え構成以外では使用しないでください。

待機系の系障害時に待機系がリセットされた場合，オペレータは系障害が発生した原因を調査し，対策を取る必要があります。

(b)　複数スタンバイ構成の場合

複数スタンバイ構成では，一つの実行系に対して複数の待機系があります。待機系に系障害が発生した場合，別の待機系が，障害が発生した待機系をリセットすることがあります。複数スタンバイ構成での系のリセットについては，「4.2.3　複数の待機系がある場合の系のリセット」を参照してください。

2.4　共有リソースの引き継ぎ

ここでは，HAモニタを使用した系切り替えでの，共有リソースの引き継ぎについて説明します。

共有リソースとは，実行系と待機系で共有するリソース（資源）のことです。系切り替え時には，共有リソースを障害が発生した系から切り離し，待機系に接続します。この切り離しと接続をまとめて引き継ぎと呼びます。共有リソースの接続時や切り離し時にHAモニタが行う処理の詳細については，「4.3　共有リソースの管理」を参照してください。

＜この節の構成＞

2.4.1　引き継げるリソースと単位

2.4.2　共有ディスクの引き継ぎ

2.4.3　ファイルシステムの引き継ぎ

2.4.4　LANの引き継ぎ

2.4.1　引き継げるリソースと単位

HAモニタでは，次のリソースを引き継げます。

共有ディスク

ファイルシステム

LAN

また，上記以外のリソースも，あらかじめユーザコマンドを作成しておけば，HAモニタで引き継げます。

引き継ぐ単位

共有リソースは，サーバ単位に引き継がれます。複数のサーバで一つの共有リソースを共用するには，リソースサーバというリソース専用のサーバを用意します。

共有リソースの競合防止

系切り替えの途中で，実行系で共有リソースの切り離しが失敗した場合，両系で共有リソースに対するアクセスが競合し，共有リソースが破壊されたり，システムがダウンしたりするおそれがあります。両系で共有リソースの競合を防止するため，系切り替えの途中で共有リソースの切り離しが失敗した場合，または切り離し処理がサーバ対応の環境設定のdev_timelimitオペランドに指定した時間でタイムアウトした場合，HAモニタは系をリセットする方法で系切り替えをします。

サーバ障害の場合，サーバ障害発生という現象は同じでも，共有リソースの切り離しに成功したかどうかでHAモニタの動作が変わります。サーバ障害が原因で系切り替えをする場合，共有リソースの切り離しに成功したときは，HAモニタは系のリセットをしないでサーバだけを切り替えます。しかし，上記の理由から，系切り替えの途中で共有リソースの切り離しに失敗したとき，または切り離し処理がサーバ対応の環境設定のdev_timelimitオペランドに指定した時間でタイムアウトしたときは，系のリセットをします。

2.4.2　共有ディスクの引き継ぎ

HAモニタは，LVMまたはHA Boosterを使用して共有ディスクを引き継ぎます。このとき，HAモニタは，実行サーバが共有ディスクを使用しているときに待機サーバからアクセスできないように，論理的に排他制御をします。

LVMを使用する場合は，ボリュームグループ単位で共有ディスクを引き継ぎます。HAモニタと共有ディスクとの接続は，LVMが制御します。

HA Boosterを使用すると，より高速に共有ディスクを引き継げます。この場合，共有ディスクへのアクセスは，HA Boosterが制御します。HA Boosterは，共有ディスクをボリュームグループ単位ではなく，制御グループ単位で排他制御をして切り替えます。HA Boosterを使用すると，LVMを介さないで共有ディスクを切り替えるため，より高速に系切り替えができます。制御グループには，ディスクデバイスを登録します。

HA Boosterを使用した共有ディスクの接続の詳細については，「4.3.2　共有ディスクの管理（HA Boosterを使用する場合）」を参照してください。HA Boosterを使用した共有ディスクの高速引き継ぎ機能の詳細については，HA Booster関連のドキュメントを参照してください。

2.4.3　ファイルシステムの引き継ぎ

HAモニタは，共有ディスク上のファイルシステムをマウント・アンマウントすることによって引き継ぎます。マウント・アンマウントは，HAモニタが制御します。

ファイルシステムとの接続

HAモニタは，共有ディスクと接続したあと，ファイルシステムに接続します。実行サーバがファイルシステムを使用できるよう，実行サーバ起動時にマウントします。マウント時には，OSのfsckコマンドによってファイルシステムの一貫性をチェックします。

ファイルシステムとの切り離し

障害が発生した場合，共有ディスクを切り離す前に，障害が発生した系からアンマウントし，業務処理を引き継ぐ系からマウントすることで，ファイルシステムを引き継ぎます。アンマウント時には，OSのfuserコマンドによってファイルシステムを使用しているすべてのプロセスを強制停止します。

2.4.4　LANの引き継ぎ

HAモニタは，エイリアスIPアドレスを引き継ぎます。

エイリアスIPアドレスとは，あるインタフェースに，すでにあるIPアドレスとは別に付けたIPアドレスのことです。エイリアスIPアドレスを使用すると，一つのインタフェースに複数のIPアドレスを設定できます。HAモニタは，系切り替え時にこのエイリアスIPアドレスを実行系から待機系に引き継ぐことでLANを切り替えます。

ステーショナリIPアドレスとエイリアスIPアドレス

各系には，LANインタフェースごとにそれぞれ固有のIPアドレスをあらかじめ設定する必要があります。このIPアドレスをステーショナリIPアドレスといいます。ステーショナリIPアドレスは系切り替えによって他系に移動しません。そのため，IPアドレスを引き継がないサーバ，系切り替えをしないプログラムの通信，および監視パスにステーショナリIPアドレスを使用します。

ステーショナリIPアドレスとは別に，一つまたは複数のIPアドレスをサーバに割り当てます。このIPアドレスをエイリアスIPアドレスといいます。HAモニタではエイリアスIPアドレスを引き継ぐため，IPアドレスを引き継ぐサーバや系切り替えをするプログラムの通信にエイリアスIPアドレスを使用します。エイリアスIPアドレスを使用することによって，系切り替えが発生してもクライアントからは同一のIPアドレスで通信できます。ただし，TCPベースのアプリケーションの場合にはコネクションが一度切断されるため，再接続などのリカバリー処理は必要になります。

エイリアスIPアドレスは，ステーショナリIPアドレスがすでに設定されているインタフェースにだけ登録できます。

エイリアスIPアドレスの引き継ぎ

サーバに割り当てたエイリアスIPアドレスは，実行サーバの起動時にLANインタフェースに追加され，実行サーバの停止時にLANインタフェースから削除されます。系切り替え時は，実行系でエイリアスIPアドレスを削除し，待機系でエイリアスIPアドレスを追加することで，エイリアスIPアドレスを引き継ぎます。

HAモニタでは，MACアドレスは引き継ぎませんが，エイリアスIPアドレスを引き継ぐときに，HAモニタがARPリクエストをブロードキャストするコマンドを実行し，IPアドレスとMACアドレスの新しいマッピングが通知されます。

エイリアスIPアドレスの引き継ぎ例を，次の図に示します。

図2-11　エイリアスIPアドレスの引き継ぎ例

この例では，LANアダプタ（eth1）に割り当てたIPアドレス（a.b.c.dおよびe.f.g.h）はステーショナリIPアドレスです。サーバに割り当てたIPアドレス（s.t.u.vおよびw.x.y.z）はエイリアスIPアドレスです。系1から系2に系切り替えがされた場合，エイリアスIPアドレスも系2に引き継がれます。

3.　HAモニタで使用できる機能

この章では，HAモニタで使用できる系切り替えの機能について説明します。機能の概要と必要な環境設定を，サーバ，系，共有リソースの分類で説明します。

＜この章の構成＞

3.1　サーバの制御のための機能

3.2　系の制御のための機能

3.3　共有リソースの制御のための機能

3.4　プログラムの制御のための機能（モニタモード）

3.5　HAモニタ Extensionの機能

3.1　サーバの制御のための機能

系切り替え構成にするサーバに対して使用できる機能について説明します。

＜この節の構成＞

3.1.1　モニタモードのサーバの監視

3.1.2　サーバのグループ化による連動系切り替え

3.1.3　サーバの切り替え順序制御

3.1.4　複数の待機系を配置するマルチスタンバイ

3.1.5　系切り替え後の負荷集中を避けるサーバの排他制御

3.1.6　JP1と連携したシステム運用

3.1.1　モニタモードのサーバの監視

モニタモードのサーバを監視する機能について説明します。この機能を使用すると，モニタモードのサーバにサーバ障害が発生した場合に，自動的に系切り替えができます。

なお，モニタモードのプログラム管理機能でUAPを監視する場合は，「3.4　プログラムの制御のための機能（モニタモード）」も参照してください。

＜この項の構成＞

(1)　サーバの監視方法

(2)　サーバ障害を検出したあとのHAモニタの動作

(3)　必要な環境設定

(1)　サーバの監視方法

モニタモードのサーバでは，プログラムの障害を検出する方法は，それぞれのプログラムの仕様によって異なります。そのため，プログラムが障害になったことをHAモニタに通知するためには，サーバの監視コマンドをユーザが作成する必要があります。

HAモニタはサーバの監視コマンドを自動起動し，サーバの監視コマンド自身のプロセスを監視します。HAモニタはサーバの監視コマンドの終了を検知することによって，モニタモードのサーバにサーバ障害が発生したと判断します。モニタモードのサーバの障害監視を，次の図に示します。

図3-1　モニタモードのサーバの障害監視

HAモニタによるサーバの監視コマンドの制御についての詳細は，「4.1.4　サーバの監視コマンドの制御」を参照してください。

(2)　サーバ障害を検出したあとのHAモニタの動作

HAモニタは，サーバ障害を検出すると，次のどちらかを実行します。

実行サーバを再起動する。
サーバ障害が発生した系で実行サーバを再起動します。実行サーバの再起動が失敗した場合は，指定した回数だけリトライします。ただし，サーバ対応の環境設定のservexec_retryオペランドに0を指定した場合は，再起動しないで系切り替えをします。

系切り替えをする。
サーバ対応の環境設定のservexec_retryオペランドに0を指定した場合，または，指定した回数だけリトライしても再起動できなかった場合は，実行サーバを停止させ，待機サーバへの系切り替えを開始します。

また，サーバ対応の環境設定のretry_stableオペランドで，実行サーバの起動完了監視時間を指定しておくと，実行サーバの再起動が完了するまでの時間を監視できます。時間内にサーバが起動完了しない場合，再起動をリトライします。この場合も，再起動回数がサーバ対応の環境設定のservexec_retryオペランドに指定した回数を超えたときは，実行サーバを停止させ，待機サーバへの系切り替えを開始します。

サーバの監視コマンドの起動，停止方法，および監視処理の流れについては，「4.1.4　サーバの監視コマンドの制御」を参照してください。

(3)　必要な環境設定

サーバの監視コマンドの作成が必要です。また，作成したサーバの監視コマンドを，サーバ対応の環境設定のpatrolcommandオペランドに指定します。

プログラムによっては，あらかじめプログラムを監視するためのコマンドを製品に同梱して提供しているものもあります。サーバの監視コマンドの作成方法については，「6.11.3　サーバの監視コマンドの作成」を参照してください。

3.1.2　サーバのグループ化による連動系切り替え

実行系で複数のサーバが稼働している場合，障害発生時に複数サーバを一括して切り替える機能を連動系切り替えといいます。連動系切り替えは，複数サーバをグループ化することで実現します。サーバをグループ化したものをサーバグループといいます。複数のサーバを使用する業務で，すべてのサーバをグループ化しておくと，あるサーバに障害が発生した場合に，サーバグループ内のすべてのサーバを一度に系切り替えできます。一つの系でグループ化できるサーバの最大数は，128です。

＜この項の構成＞

(1)　連動系切り替えの概要

(2)　必要な環境設定

(1)　連動系切り替えの概要

グループ化したサーバは，実行系でそのうちの一つに障害が発生すると，サーバグループ単位で待機系に切り替えられます。

連動系切り替えでは，障害時に自動で系切り替えをする自動系切り替えのほか，計画系切り替えコマンド（monswap -gコマンド）を実行して切り替える計画系切り替えもできます。

連動系切り替えの概要を次の図に示します。

図3-2　連動系切り替えの概要

実行系に系障害が発生したり，サーバグループ内のあるサーバにサーバ障害が発生したり，またはオペレータが計画系切り替えを実行したりすると，HAモニタはサーバグループ内のすべてのサーバを待機系に切り替えます。また，サーバモードのサーバでは，サーバグループ内のサーバごとに「そのサーバに障害が発生したら連動系切り替えをする」か「そのサーバに障害が発生しても系切り替えはしないでサーバグループの業務を継続する」かを指定できます。サーバの重要度によってサーバグループ単位で切り替えるかどうかを決定できるため，不要な系切り替えを避けられます。この機能を使用するための設定については，「4.4.1　連動系切り替え時のサーバの切り替え種別」を参照してください。

グループ化された複数のサーバは，通常，それぞれ独立して系切り替えをします。グループ内の各サーバの系切り替え順序を制御する方法については，「3.1.3　サーバの切り替え順序制御」を参照してください。

複数のサーバで共有リソースを共用したい場合は，サーバグループ内でリソースサーバを使用します。一つの系でグループ化できるリソースサーバの最大数は，64です。リソースサーバについては，「3.3.1　リソースサーバを使用した共有リソースの共用」を参照してください。

(2)　必要な環境設定

サーバをグループ化するには，サーバ対応の環境設定のgroupオペランドを指定します。同じグループ内で稼働するすべてのサーバに必要です。

サーバグループ内のサーバをモニタモードで運用する場合，groupオペランドの指定に加えて，サーバの停止コマンドを作成し，サーバ対応の環境設定のtermcommandオペランドに指定しておく必要があります。また，サーバの監視コマンドを作成し，サーバ対応の環境設定のpatrolcommandオペランドに指定しておくと，モニタモードのサーバにサーバ障害が発生した場合に連動系切り替えができます。

HAモニタが連動系切り替えを実行するには，次に示す条件があります。システム構築時および環境設定時にはこれらの条件を満たすように設定してください。

実行サーバとそれに対応する待機サーバに，同じグループ名が設定されていること。

サーバグループにあるすべてのサーバの，系切り替え先のサーバがすべて同じ系にあること。

サーバグループにあるすべてのサーバに同じ起動種別が設定されていること。

サーバグループにあるすべてのサーバで，ペアが成り立っている（実行サーバに対応する待機サーバが起動完了している）こと。

なお，サーバのグループ化は，サーバ起動時に決定されます。一つの系に実行サーバと待機サーバの両方がある場合，グループ化の対象となるのは実行サーバだけです。また，すでにサーバをグループ化した系で，新たに条件に合わないサーバが起動されても，グループ化の対象にはなりません。

3.1.3　サーバの切り替え順序制御

系切り替えの際に，サーバグループ内のサーバの停止順序，および切り替え先の系でのサーバの起動順序を制御できます。順序制御をするには，複数のサーバをグループ化し，起動したい順序に合わせてサーバの親子関係を定義しておきます。

サーバの切り替え順序制御は，サーバ障害発生時，系障害発生時，および計画系切り替え時の連動系切り替え時だけ制御できます。通常の，サーバの起動・停止時にはサーバの切り替え順序を制御できません。サーバの起動・停止時には，指定した順序とは関係なく，起動・停止されます。

なお，プログラム管理機能を使用しているモニタモードのサーバの場合，サーバの管理対象となるUAPやプログラムについての切り替え順序制御はできません。

＜この項の構成＞

(1)　サーバの起動順序と親子関係の対応

(2)　必要な環境設定

(1)　サーバの起動順序と親子関係の対応

サーバの起動順序に合わせて，親子関係を定義する方法について説明します。

あるサーバを起動するための前提となるサーバを，親サーバといいます。親サーバのあとに起動するサーバを子サーバといいます。

サーバの起動時には，親サーバから順番に起動されます。親サーバの起動が完了したら，子サーバを起動します。停止順序は起動順序の逆となります。すべての子サーバの停止が完了してから，親サーバの停止処理が開始されます。

サーバグループの親子関係と起動順序の関係について，図に示します。例えば，「サーバ1，サーバ2，サーバ3およびサーバ4」の順序で起動したい場合，親子関係は次の図のとおりになります。

図3-3　サーバグループの親子関係と起動順序

この例では，サーバ2の親サーバはサーバ1，サーバ3およびサーバ4の親サーバはサーバ2となります。

サーバの親子関係は，次の点を考慮してください。

子サーバは，親サーバを一つだけ持ちます。そのため，子サーバには，親サーバを一つだけ定義できます。複数の親サーバを定義できません。一方，親サーバは，複数の子サーバを持てます。そのため，親サーバには，複数の子サーバを定義できます。

グループ内に順序関係を持たないサーバも定義できます。

サーバグループ内にリソースサーバが含まれる場合，リソースサーバが最も上位の親サーバとなります。

起動・停止順序は，同一グループ内のサーバ間で制御できます。複数グループにわたる順序制御はできません。

サーバの切り替え順序制御をする場合の処理の流れについては，「4.1.5　サーバの切り替え順序制御をする場合の処理の流れ」を参照してください。

(2)　必要な環境設定

前提として，サーバのグループ化の設定を，サーバ対応の環境設定のgroupオペランドに定義しておく必要があります。

さらに，サーバの起動順序を考慮して，グループ内の複数のサーバに親子関係を定義する必要があります。親子関係の定義は，サーバ対応の環境設定のparentオペランドに指定します。parentオペランドは，すべてのサーバに対して指定する必要はありません。

定義済みの起動順序を確認するには，サーバ順序制御状態表示コマンド（monodrshwコマンド）を使用します。グループ内の親子関係が確認できます。

3.1.4　複数の待機系を配置するマルチスタンバイ

マルチスタンバイ機能とは，一つの実行サーバに対して，複数の待機サーバを準備するための機能です。複数の待機サーバを準備することで，実行系の障害が復旧するまでの間も，システムの障害に備えることができます。例えば，系切り替え中に待機系で障害が発生した場合にも別の待機系に系切り替えができます。

系切り替え構成のうち，複数スタンバイ構成にする場合は，マルチスタンバイ機能を必ず使用します。ここでは，マルチスタンバイ機能を使用した場合の系切り替えについて説明します。

＜この項の構成＞

(1)　系切り替え先の決定方法

(2)　実行系で障害が発生した場合

(3)　系切り替え中に，切り替え先の待機系で障害が発生した場合

(4)　計画系切り替えをした場合

(5)　連動系切り替えをした場合

(6)　必要な環境設定

(7)　ハードウェア構成

(1)　系切り替え先の決定方法

マルチスタンバイ機能を使用する場合，複数の待機系があるため，どの系に切り替えるかを示す優先度を，あらかじめ決定しておく必要があります。障害発生時には，指定された優先度に従ってHAモニタが系切り替え先を決定します。

(2)　実行系で障害が発生した場合

マルチスタンバイ機能を使用する場合，実行サーバに障害が発生すると，指定された優先度に従って，HAモニタが自動的に系切り替えをします。マルチスタンバイ機能を使用する場合で，実行系に障害が発生したときの系切り替えを，次の図に示します。

図3-4　マルチスタンバイ機能を使用した場合の系切り替え

実行サーバで障害が発生したら，待機系のうち，いちばん高い優先度を持つ待機サーバに系切り替えされます。待機サーバが持つ優先度は，サーバ対応の環境設定にあらかじめ指定しておきます。

(3)　系切り替え中に，切り替え先の待機系で障害が発生した場合

系切り替え中に切り替え先の待機系で障害が発生した場合，ほかの待機系で起動完了している待機サーバがあれば，その待機系に系切り替えをします。

系切り替え中に，切り替え先の待機系で障害が発生した場合の動作を次の図に示します。

図3-5　系切り替え中に切り替え先の待機系で障害が発生した場合の動作

待機系1に系切り替えをしている最中に待機系1に障害が発生した場合も，HAモニタが，次に高い優先度を持つ待機系2に系切り替えをします。その結果，待機系での障害時にも，業務を継続できます。

(4)　計画系切り替えをした場合

オペレータがHAモニタのコマンドを実行して系切り替えをすると，複数の待機系の中でいちばん優先度が高い系に系切り替えされます。

任意の系の待機サーバを実行サーバとして起動するには，いったん実行サーバを停止して別の系で待機サーバを起動するか，切り替え先の待機サーバより優先度の高い待機サーバをいったん停止させたあとで計画系切り替えをしてください。

(5)　連動系切り替えをした場合

マルチスタンバイ機能を使用する場合も，複数サーバを一括して切り替える連動系切り替えができます。サーバごとに，複数の待機系の中でいちばん優先度が高い系に対して系切り替えをします。

マルチスタンバイ機能を使用する場合は，系切り替え先が複数あるため，次の点に注意してください。

サーバの起動種別および待機サーバの優先度は，系内で一致させておく必要があります。

すべての待機サーバを起動し，起動完了させておく必要があります。起動していない待機サーバがあると，連動系切り替え時に，サーバグループ内のサーバの切り替え先が統一されません。

切り替え種別にno_exchangeを指定した場合は，複数の待機系の中でいちばん優先度が高い待機サーバだけが連動系切り替え待ち状態になります。

連動系切り替えをする場合のサーバの起動種別や連動系切り替え待ち状態については，「4.4.1　連動系切り替え時のサーバの切り替え種別」を参照してください。

(6)　必要な環境設定

マルチスタンバイ機能を使用するには，HAモニタの環境設定のmultistandbyオペランドを指定します。また，優先度は，サーバ対応の環境設定のstandbypriオペランドで指定します。待機サーバの優先度には，各系で異なる値を指定してください。実行サーバの優先度は，いちばん高い優先度0が自動的に設定されます。

(7)　ハードウェア構成

マルチスタンバイ機能を使用する系切り替え構成では，次の条件を満たすハードウェア構成にしてください。

監視パスは，すべての系が接続する構成にする必要があります。

リセットパスは，すべての系が接続する構成にする必要があります。

共有ディスクおよびLANは，使用するすべての系からアクセスできる構成にする必要があります。

3.1.5　系切り替え後の負荷集中を避けるサーバの排他制御

HAモニタには，ある系に配置した複数の待機サーバのうち，どれか一つが実行サーバになった場合，ほかの待機サーバを停止させる機能があります。この停止するサーバを排他サーバと呼びます。この機能は，1:1系切り替え構成でも使用できますが，n:1系切り替え構成での使用をお勧めします（nは2以上）。

2:1系切り替え構成のように，一つの予備系に複数の待機サーバを配置する構成では，系切り替え後には，一つの系で複数の業務を実行します。メモリ量やサーバのパフォーマンスなど，系切り替え後の処理性能を考慮する場合に，このサーバの排他制御機能を使用すれば，一つの系で複数の実行サーバが稼働するのを抑止できます。

なお，同じグループ内のサーバ同士には，排他サーバを指定できません。連動系切り替えと排他制御は同時にできないため，排他サーバの指定が無効になります。

＜この項の構成＞

(1)　サーバの排他制御の概要

(2)　必要な環境設定

(1)　サーバの排他制御の概要

サーバの排他制御機能を使用するには，あらかじめ，排他サーバを環境設定に指定しておきます。HAモニタは，系で実行サーバが起動した場合，同じ系で稼働しているほかの待機サーバを停止します。ただし，実行サーバとして起動したサーバと同じグループに属する待機サーバは停止しません。同じグループに指定されているため，連動系切り替えをします。

ユーザによって停止されている排他サーバを起動するには，同じ系で稼働している実行サーバを停止させるか，または他系に系切り替えをする必要があります。

サーバの排他制御をする場合の系切り替えの流れを，次の図に示します。この図では，2:1系切り替え構成で，待機サーバ2を排他サーバとして定義しています。

図3-6　サーバの排他制御をする場合の系切り替えの流れ

(2)　必要な環境設定

サーバの排他制御機能を使用するには，排他サーバの環境設定が必要です。排他サーバの環境設定については，「8.4.2　排他サーバの環境設定（servers_opt）」を参照してください。

3.1.6　JP1と連携したシステム運用

HAモニタはJP1と連携して，系切り替え構成にしたシステムの運用を一元管理できます。HAモニタが稼働する系切り替え構成にしたシステムに何らかの変化が発生した場合に，HAモニタはJP1のイベントを発行します。発行されたイベントは，JP1統合管理画面などから参照できます。

系切り替え構成にしたシステム以外の業務システムも同様にJP1と連携させると，お使いのシステム全体の運用を，JP1から一元管理できるようになります。

＜この項の構成＞

(1)　ユーザコマンドとJP1イベントとの使い分け

(2)　必要な環境設定

(1)　ユーザコマンドとJP1イベントとの使い分け

HAモニタが稼働するシステムでの運用方法には，JP1のイベントとHAモニタのユーザコマンドがあります。用途に応じて次のように使い分けてください。

メッセージ出力のタイミングで，何らかの処理・操作を自動運用したい場合

JP1のイベントを使用します。JP1のイベントは，エラー発生時にパトロールランプを鳴動させるなど，サーバの状態変化と同期を取る必要がない処理の場合に有効です。

JP1のイベントを使用すると，次のメリットがあります。

メッセージと同じタイミングで発行するので，ユーザコマンドと比べて発行タイミングが豊富である

あらかじめ用意されたイベントを使用するため，ユーザが新規で作成する必要がない

発生した障害の情報を，メッセージよりも詳細に知ることができる

HAモニタが発行するJP1のイベントIDの詳細については，「付録A　HAモニタのイベントID」を参照してください。

サーバやHAモニタの状態変化のタイミングで，何らかの処理・操作を自動運用したい場合

ユーザコマンドを作成します。サーバやHAモニタに状態変化が発生すると，HAモニタはユーザが作成したユーザコマンドを発行します。ユーザコマンドは共有リソースの起動・終了，および引き継ぎ処理時に発行されます。このため，HAモニタがサポートしていないリソースの処理などを自動運用したい場合に有効です。

ユーザコマンドの詳細については，「3.3.2　サーバやHAモニタの状態変化時のコマンド発行」を参照してください。

(2)　必要な環境設定

JP1と連携してシステムの運用をするには，JP1のインストールおよび環境設定が必要です。HAモニタとJP1が連携するには，HAモニタが稼働する系で，JP1/Baseの物理ホストが稼働している必要があります。HAモニタの起動前に，JP1/Baseを起動してください。

また，HAモニタの環境設定のjp1_eventオペランドを指定します。

3.2　系の制御のための機能

HAモニタは，系障害が発生すると，系切り替えをして待機系に業務を引き継ぎます。ここでは，系切り替えを問題なく完了させるための機能について説明します。系のリセットに関係する機能は，特に環境設定をしなくてもデフォルトのままで系切り替えができます。デフォルトの動作を変更したい場合に，お読みください。

＜この節の構成＞

3.2.1　系の同時リセットの防止

3.2.2　複数系間の同時リセットの防止

3.2.3　系の二重リセットの防止

3.2.4　系のリセットの抑止

3.2.5　サーバ障害時に系ごと切り替える系のペアダウン

3.2.6　LANの監視および障害時の自動系切り替え

3.2.7　他系のOSパニック検知

3.2.8　仮想化環境での物理パーティションリセット機能

3.2.9　N+Mコールドスタンバイ構成での系切り替え

3.2.1　系の同時リセットの防止

系の同時リセットとは，実行系と待機系の両方が同時に系のリセットをすることです。系の同時リセットが発生すると，両方の系が停止してしまい業務を継続できなくなるため，HAモニタは系の同時リセットを防止します。ここでは，系の同時リセットを防止する方法について説明します。

＜この項の構成＞

(1)　系の同時リセットが起こるおそれがある構成

(2)　必要な環境設定

(1)　系の同時リセットが起こるおそれがある構成

系切り替え構成や使用する機能によっては，実行系と待機系が同時にリセットをし合い，業務が停止してしまうおそれがあります。

特に，次の系切り替え構成では，実行系と待機系が同時にリセットされるおそれがあるため，どちらの系のリセットを優先させるかを決めておく必要があります。二つの系が同時に系障害を検出したとき，優先的にリセット要求を発行する系のことをリセット優先系といいます。

相互系切り替え構成の場合
両方の系が実行系であると同時に，お互いの待機系であるため，リセット優先系を決めておく必要があります。ただし，マシンの機種がBladeSymphonyでSVPがクラスタ管理機能に対応している場合，リセット優先系を決めないで系の同時リセットを防ぐ方法も選択できます。クラスタ管理機能については，ハードウェア関連のドキュメントを参照してください。

1:1系切り替え構成の場合で，待機系のリセットをするとき
待機系の障害時に，待機系のリセットをする場合は，両方の系が同時にリセットを発行するおそれがあります。そのため，リセット優先系を決めておく必要があります。待機系のリセットについては，「2.3.5(2)　待機系のリセット」を参照してください。

系の同時リセットが起こるおそれがある構成を，次の図に示します。

図3-7　系の同時リセットが起こるおそれがある構成

図で示す構成では，二つの系が同時に系障害を検出した場合，両方の系から同時にリセット要求を発行し，系を同時にリセットするおそれがあります。

(2)　必要な環境設定

系の同時リセットを防ぐためには，リセット優先系を事前に決定しておきます。リセット優先系は，HAモニタの環境設定のcpudownオペランドに指定された内容に従って，自動的にHAモニタが決定します。デフォルトでは，実行系からのリセットを優先する設定になっています。

リセット優先系を決めないで系の同時リセットを防ぐためには，HAモニタの環境設定のcpudownオペランドに"system"を指定してください。この指定は，相互系切り替え構成の場合で，かつマシンの機種がBladeSymphonyでSVPがクラスタ管理機能に対応している場合だけ有効です。また，VMware ESXiで仮想化する場合は"system"を指定できません。

HAモニタが系の同時リセットを防止するときの動作の詳細については，「4.2.2　両系が障害を同時に検出した場合の系切り替え」を参照してください。

3.2.2　複数系間の同時リセットの防止

複数スタンバイ構成またはクラスタ型系切り替え構成の場合に，系の同時リセットを防止する方法について説明します。

マルチスタンバイ機能を使用して，一つの実行サーバに対して複数の待機サーバを配置する構成では，複数系間の同時リセットを防止する必要があります。

＜この項の構成＞

(1)　複数系間で，系の同時リセットが起こるおそれがある構成

(2)　必要な環境設定

(1)　複数系間で，系の同時リセットが起こるおそれがある構成

3台以上の系がある構成では，監視パスのネットワーク構成機器の障害などで系が分断されると，分断された個々のネットワーク間で別々に系障害を検出し，結果としてすべての系がリセットされてしまうおそれがあります。

この問題を回避するために，系切り替え構成全体に属するすべての系でリセット発行順序を一意に定める必要があります。このリセット発行順序をリセット優先度といいます。リセット優先度は，HAモニタの環境設定で指定します。

複数系間で系の同時リセットが起こるおそれがある構成を，次に示します。

すべての系がリセットし合う構成
監視パスの障害によってすべての系が同時に系障害を検出した場合，すべての系から同時にリセット要求を発行し，系を同時にリセットするおそれがあります。

マルチスタンバイ機能を使用する構成
マルチスタンバイ機能を使用して，一つの実行サーバに対して複数の待機サーバを配置する構成では，複数の系で稼働するすべての待機サーバが，実行系の系障害を検出するため，複数系間でリセットし合うおそれがあります。

すべての系がリセットし合う構成を次の図に示します。

図3-8　すべての系がリセットし合う構成

この図では，監視パスのすべてに障害が発生した場合，すべての系がリセットされる構成になっています。この場合，リセット優先度を指定しておくと，リセット優先度に従って，HAモニタがリセットする系とその順番を決定します。

(2)　必要な環境設定

HAモニタの環境設定のreset_typeオペランドで「host」を指定します。なお，マルチスタンバイ機能を使用する場合は，このオペランドの指定に関係なく，リセット優先度を基に系の同時リセットを防止します。

リセット優先度の詳細については，「4.2.3　複数の待機系がある場合の系のリセット」を参照してください。

3.2.3　系の二重リセットの防止

系の二重リセットとは，ある系に対して，2度以上系のリセットをすることです。ここでは，系の二重リセットを防止する方法について説明します。

＜この項の構成＞

(1)　系の二重リセットが起こるおそれがある構成

(2)　必要な環境設定

(1)　系の二重リセットが起こるおそれがある構成

系障害が発生して系切り替えをする場合，系切り替え構成によっては，複数の待機系が系のリセットを発行するため，実行系の回復が遅くなるおそれがあります。

系の二重リセットが起こるおそれがある構成を，次の図に示します。

図3-9　系の二重リセットが起こるおそれがある構成

上記の図で示す構成では，実行系の系障害時に待機系1および待機系2の両方がそれぞれリセット要求を発行し，実行系の回復を遅らせるおそれがあります。

(2)　必要な環境設定

必要な環境設定はありません。

系の二重リセットを防ぐためには，実行系をリセットする待機系を，事前に一つに決めておく必要があります。この待機系を，リセット発行系といいます。リセット発行系は，HAモニタによってサーバの起動時に自動的に決定されます。

リセット発行系の動作の詳細については，「4.2.1　系のリセットをする系の決定方法」を参照してください。

3.2.4　系のリセットの抑止

稼働する系の総数が三つ以上で互いに監視し合う構成の場合，監視パス障害などで一つの系が残りの系の系障害を検知すると，次の図の例のように，残りのすべての系をリセットして一つの系に系切り替えをすることがあります。この場合，一定数以上の系が稼働している必要があるシステムでは，業務が停止してしまいます。

図3-10　残りのすべての系をリセットして一つの系に系切り替えをする場合の例

この例は，メモリ容量などの理由によって一つの系で実行サーバを3台以上稼働させられないシステムとしています。このシステムでは，系1で実行サーバが5台稼働しようとすると，システムが動作できないため，業務が停止してしまいます。

HAモニタでは，このような一定数以上の系が稼働している必要があるシステムで系がリセットされるのを抑止し，業務が停止するのを防止できます。システムが業務を継続するために必要な系の数のことを，最少稼働ホスト数と呼びます。ここでは，系のリセット抑止時の動作や環境設定などについて説明します。

＜この項の構成＞

(1)　系のリセット抑止時の動作

(2)　系のリセットを抑止できる障害

(3)　系のリセットを抑止するための条件と例

(4)　必要な環境設定

(1)　系のリセット抑止時の動作

次に示す場合別に，系のリセット抑止時のHAモニタの動作について説明します。

一つの系で系障害が発生して系をリセットし，業務が継続する場合

一つの系で監視パス障害が発生して系のリセットを抑止し，業務が継続する場合

N：2構成で系障害が発生して系をリセットし，業務が継続する場合

三つの系での縮退運用中に系障害が発生してリセットを抑止し，業務が停止する場合

ここでは，最少稼働ホスト数が3で，かつ一つの系で稼働できる実行サーバの数が2台までの場合を例に説明します。

(a)　一つの系で系障害が発生して系をリセットし，業務が継続する場合

一つの系で系障害が発生して系をリセットし，業務が継続する場合の動作について，次の図に示します。

図3-11　一つの系で系障害が発生して系をリセットし，業務が継続する場合の動作

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

系4で系障害が発生し，aliveメッセージが途絶します。aliveメッセージの途絶によって，系1～系3，および系5は系4の障害を検出します。

系1～系3，および系5は，障害検知通知を送受信し合います。

系1～系3，および系5は，それぞれ受信した障害検知通知の数をカウントし，最少稼働ホスト数を満たしていることを確認します。このため，最もリセット優先度が高い系1が，系4をリセットします。

系4で稼働していた実行サーバが系切り替えをします。この図では，系5の待機サーバに系切り替えをする場合を例にしています。

この例の場合，系切り替え後も最少稼働ホスト数を満たしていて，かつ一つの系で実行サーバが最大で2台しか稼働していないため，業務が継続します。

(b)　一つの系で監視パス障害が発生して系のリセットを抑止し，業務が継続する場合

一つの系で監視パス障害が発生して系のリセットを抑止し，業務が継続する場合の動作について，次の図に示します。

図3-12　一つの系で監視パス障害が発生して系のリセットを抑止し，業務が継続する場合の動作

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

系1で監視パス障害が発生し，aliveメッセージが途絶します。aliveメッセージの途絶によって孤立した系1は，系2～系5の障害を検出します。一方，系2～系5は，系1の障害を検出します。

系1は監視パス障害で障害検知通知を送信できないため，受信待ちとなります。一方，系2～系5は，障害検知通知を送受信し合います。

系1は障害検知通知を受信できないため，最少稼働ホスト数以上の系が稼働していることを確認できません。このため，系2～系5のリセットを抑止します。

系2～系5は，それぞれ受信した障害検知通知の数をカウントし，最少稼働ホスト数を満たしていることを確認します。このため，リセット優先度の高い系2が，10秒後に系1をリセットします。

系1で稼働していた実行サーバが系切り替えをします。この図では，系2の待機サーバに系切り替えをする場合を例にしています。

この例の場合，系切り替え後も最少稼働ホスト数を満たしていて，かつ一つの系で実行サーバが最大で2台しか稼働していないため，業務が継続します。

(c)　N：2構成で系障害が発生して系をリセットし，業務が継続する場合

N：2構成で系障害が発生して系をリセットし，業務が継続する場合の動作について，次の図に示します。

図3-13　N：2構成で系障害が発生して系をリセットし，業務が継続する場合の動作

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

系1で系障害が発生し，aliveメッセージが途絶します。aliveメッセージの途絶によって，系2～系5は系1の障害を検出します。

系2～系5は，障害検知通知を送受信し合います。

系2～系5は，それぞれ受信した障害検知通知の数をカウントし，最少稼働ホスト数を満たしていることを確認します。このため，最もリセット優先度が高い系2が，系1をリセットします。

系1で稼働していた実行サーバが系切り替えをします。この図では，系4のサーバに系切り替えをする場合を例にしています。

この例の場合，系切り替え後も最少稼働ホスト数を満たしていて，かつ一つの系で実行サーバが1台しか稼働していないため，業務が継続します。

(d)　三つの系での縮退運用中に系障害が発生してリセットを抑止し，業務が停止する場合

三つの系での縮退運用中に系障害が発生してリセットを抑止し，業務が停止する場合の動作について，次の図に示します。

図3-14　三つの系での縮退運用中に系障害が発生してリセットを抑止し，業務が停止する場合の動作

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

系3で系障害が発生し，aliveメッセージが途絶します。aliveメッセージの途絶によって，系1および系2は系3の障害を検出します。

系1および系2は，障害検知通知を送受信し合います。

系1および系2は，受信した障害検知通知の数が最少稼働ホスト数を満たしていないため，系3のリセットを抑止します。

すべての系でリセットが抑止される※と，系1および系2では系3の状態を確認できなくなります。実行サーバが複数起動することを防止するため，次のようにサーバが状態遷移します。

系3上の待機サーバよりもサーバ優先度が低い待機サーバ：停止します（"SBY"→"停止"）。
系1または系2に障害が発生した場合に，系3上の待機サーバの状態が変化することがあるためです。

系間で最もサーバ優先度の高い待機サーバ：系切り替え待ち状態になります（"SBY"→"ONL??"）。
系3上で実行サーバが稼働し続けている可能性があるためです。

注※

すべての系でリセットが抑止されるまでの時間は，「10秒（機種によって異なる）×グループを構成する系の総数」で求められます。例えば，系の数が32の場合，次の計算式のようになります。

10×32＝320秒＝5分20秒

この例の場合，系3で稼働していた実行サーバがなくなり，最少稼働ホスト数である3を満たさなくなるため，業務が停止します。

なお，他系に系切り替えできる待機サーバの有無によって，待ち状態のサーバ起動コマンド（monactコマンド）の実行などの操作が必要です。詳細については，サーバが停止した場合は「7.2.1　起動する」を，サーバが系切り替え待ち状態（ONL??）になった場合は「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

(2)　系のリセットを抑止できる障害

系のリセットを抑止できるのは，aliveメッセージの途絶によって検出できる系障害の場合だけです。

他系のHAモニタからペアダウンを通知された場合や，系切り替え時に共有ディスクの切り離しに失敗した場合は，他系からの障害検知通知を待たないで他系をリセットして系切り替えをします。また，ハードウェアやLinux Tough Dumpから障害通知を受信した場合，他系のOSパニックを検知した場合，およびサーバ障害が発生した場合は，障害検知通知を待たないで系切り替えをします。

(3)　系のリセットを抑止するための条件と例

次の条件をすべて満たす場合にだけ，系のリセットを抑止できます。

最少稼働ホスト数が，接続する系の総数の半数以上となる構成である。

マルチスタンバイ機能を使用している（HAモニタの環境設定のmultistandbyオペランドにuseを指定している）か，またはreset_typeオペランドにhostを指定している。

全系で次の条件を満たしているか，またはpatrol_typeオペランドにhostを指定している。

サーバが起動完了している。

自系と接続するすべての系に，自系のサーバとペアになるサーバがある。

系のリセットを抑止できる例を，それぞれ次の図に示します。

図3-15　系のリセットを抑止できる例1

この例では，次の条件を満たしているためリセットを抑止できます。

最少稼働ホスト数が，接続する系の総数の半数以上となる構成である。

マルチスタンバイ機能を使用している。

サーバが起動完了していて，かつ自系と接続するすべての系に，自系のサーバとペアになるサーバがある。

図3-16　系のリセットを抑止できる例2

この例では，次の条件を満たしているためリセットを抑止できます。

最少稼働ホスト数が，接続する系の総数の半数以上となる構成である。

reset_typeオペランドにhostを指定している。

patrol_typeオペランドにhostを指定している。

参考

最少稼働ホスト数として接続する系の総数の半数よりも小さい値が設定されている場合，ネットワークの分断（スプリットブレイン）が発生すると，分断された構成内で最少稼働ホスト数を超えてしまい，リセットし合ってしまうおそれがあります。このため，最少稼働ホスト数には，接続する系の総数の半数以上の値を設定してください。

(4)　必要な環境設定

系のリセットを抑止するには，HAモニタの環境設定のsuppress_resetオペランドを指定します。

3.2.5　サーバ障害時に系ごと切り替える系のペアダウン

HAモニタでは，実行サーバの障害を実行系の障害として扱うことで，サーバ障害時に，系をリセットする方法で系切り替えができます。これを，系のペアダウンといいます。

通常HAモニタは，サーバ障害が発生した場合に，障害が発生した系をリセットしないで待機系に切り替えますが，系のペアダウン機能を使用すると，障害が発生した系をリセットして待機系に切り替えられます。この機能は，サーバモードのサーバだけが使用できます。

＜この項の構成＞

(1)　ペアダウン時の動作

(2)　必要な環境設定

(1)　ペアダウン時の動作

ペアダウン機能は，実行サーバの障害時，実行サーバを停止させると同時に，HAモニタも停止させることで実現します。実行系のHAモニタの停止は系障害として扱われ，待機系からリセットされたあとに系切り替えが開始されます。

ペアダウンの契機となる実行サーバの障害には，サーバ自身が検出した障害およびサーバのスローダウンがあります。また，TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）をサーバモードのサーバとして使用する場合，サーバのスローダウンを検出したときだけペアダウンをするオプションも指定できます。

実行系のリセットは，停止するHAモニタからの連絡を，待機系のHAモニタが受けて実行します。このとき，リセット優先系の判断や，リセット発行系の決定には従わないで，即時リセットを実行します。

(2)　必要な環境設定

ペアダウン機能を使用するかどうかは，サーバ対応の環境設定のpairdownオペランドで指定します。

3.2.6　LANの監視および障害時の自動系切り替え

HAモニタでは，実行サーバが使用するLANの通信状態を監視して，障害が発生したときに自動的に系切り替えをすることができます。ここでは，LAN監視時の動作などについて説明します。

なお，LANを監視できるのは，次のOSの場合だけです。

Red Hat Enterprise Linux 5(x86)

Red Hat Enterprise Linux 5 Advanced Platform(x86)

Red Hat Enterprise Linux 5(AMD/Intel 64)

Red Hat Enterprise Linux 5 Advanced Platform(AMD/Intel 64)

Red Hat Enterprise Linux server 6(x86)

Red Hat Enterprise Linux server 6(x86_64)

＜この項の構成＞

(1)　LAN監視時の動作

(2)　動作環境

(3)　必要な環境設定

(4)　LANを監視するときの注意事項

(1)　LAN監視時の動作

HAモニタは，送受信されるパケット数を監視することでLANを監視します。実行系のLANアダプタが受信するパケット数を定期的に監視し，前回監視したときから受信パケット数に変化がない場合は，LANに異常が発生したと見なして系切り替えをします。

LAN監視時の動作を次の図に示します。

図3-17　LAN監視時の動作

LANの障害を検出すると，HAモニタは系切り替え先として設定してあるサーバを検索し，そのサーバが系切り替え可能であれば系切り替えをします。該当するサーバがグループ化されている場合は，グループごとに系切り替えをします。切り替え先のサーバで系切り替えができる状態でない場合は，系切り替えができる状態になった時点で系切り替えをします。監視対象のLANが複数存在する場合は，各LANの監視はインタフェースごとに独立して非同期に実行します。

HAモニタが監視対象とするのは，hbonding，bonding，ethernetの3種類のデバイスです。監視対象は，LAN監視定義ファイルの設定で選択します。

なお，hbondingを監視するときは，パケット数に加え，hbondingのステータスも監視できます。hbondingを監視する場合，hbondingのステータスだけを監視するか，パケット数とhbondingのステータスの監視を併用するかを選択できます。通常は，hbondingのステータスだけを監視する方法を選択します。ただし，hbondingの設定で指定する監視対象とは別に，複数の監視対象を指定したい場合は，パケット数とhbondingのステータスの監視を併用してください。

(2)　動作環境

送受信パケット数の監視をする場合は，次の動作環境を満たしている必要があります。

LANの状態を確認するために指定する他ノードに，監視対象となるLANと同一ネットワークで通信するためのIPアドレスがあり，ICMPエコーパケットに対する応答ができる。

LANの状態を確認するために指定する他ノードが，HAモニタを起動する前にすでに起動している。

(3)　必要な環境設定

次の設定が必要です。

LANを監視するための環境設定

LANを監視して，障害時に自動的に系切り替えをするかどうかをHAモニタの環境設定のlanfailswitchオペランドに指定します。

LANの監視間隔をHAモニタの環境設定のlancheck_patrolオペランドに指定します。

監視するLANインタフェース名称をサーバ対応の環境設定のswitchbyfailオペランドに指定します。

LANを監視するためのファイルの設定

LAN監視定義ファイル，およびLAN監視スクリプトを設定します。監視対象がhbondingの場合は，パケット数とhbondingのステータスの監視を併用するか，hbondingのステータスの監視だけを実施するかをこのファイルの設定で決められます。

詳細については，「6.10.3　LANの監視設定ファイルの設定」を参照してください。

(4)　LANを監視するときの注意事項

次に示す場合別に，LANを監視するときの注意事項を示します。

hbondingを監視する場合

LANの監視中（HAモニタの稼働中）は，hbondingインタフェースに結合されているスレーブインタフェースの解除，またはhbondingインタフェースの削除はしないでください。

連動系切り替えをする場合

サーバ対応の環境設定のswitchbyfailオペランドに，グループ化したすべてのサーバで同じLANインタフェース名称を指定してください。

サーバの切り替え順序制御をする構成の場合

サーバの切り替え順序制御をするサーバのうち，運用上，必ず最後に起動するサーバにサーバ対応の環境設定のswitchbyfailオペランドを指定することをお勧めします。サーバ対応の環境設定のswitchbyfailオペランドを最後に起動するサーバ以外に指定した場合，switchbyfailオペランドを指定したサーバが起動した時点で連動系切り替えを実施してしまい，より下位のサーバで系切り替えができないことがあります。

3.2.7　他系のOSパニック検知

HAモニタが動作している系でOSパニックが発生したときに，その系の障害を瞬時に検知して他系のHAモニタに通知することで高速に系切り替えができます。これを，他系のOSパニック検知機能といいます。

他系のOSパニック検知機能を使用するには，すべての系がこの機能を使用できるシステム環境である必要があります。定義チェックコマンド（moncheckコマンド）を実行して，すべての系でこの機能が使用できるシステム環境かどうかを事前に確認してください。

他系のOSパニック検知機能は，HA BoosterとHAモニタが連携することで実現しています。なお，必要なソフトウェアは，OSのバージョンによって異なります。

＜この項の構成＞

(1)　他系のOSパニック検知機能使用時の動作

(2)　動作環境

(1)　他系のOSパニック検知機能使用時の動作

実行系でOSパニックが発生したときに，実行系のHA Boosterが瞬時にOSパニックを検知し，待機系のHAモニタに障害通知をします。通知を受けた待機系のHAモニタは待機サーバを実行サーバに切り替えます。他系のOSパニック検知機能使用時の動作を次の図に示します。

図3-18　他系のOSパニック検知機能使用時の動作

(2)　動作環境

他系のOSパニック検知機能を使用できる動作環境について説明します。

他系のOSパニック検知機能は，OSパニックが発生した系と他系のシステムが次に示すすべての条件を満たす場合に動作します。システムがここで説明する動作環境でない場合は，実行系にOSパニックが発生しても瞬時に系切り替えをするのではなく，HAモニタの環境設定のpatrolオペランドで指定した系障害監視時間が経過してから系切り替えをします。

すべての系で，Linux Tough Dumpがインストールされている。

すべての系で，HA Boosterがインストールされている。

すべての系で，Linux Tough Dumpが起動している。
通常は，HAモニタ起動前にLinux Tough Dumpが起動されます。

HAモニタ起動時に，他系のOSパニック検知機能が有効化されている。

これらの条件を満たしているかどうかは，出力されるメッセージによって確認できます。他系のOSパニック検知機能の使用条件を満たしていることを確認する方法として，確認するタイミング，メッセージID，およびメッセージの出力先を次に示します。

表3-1　他系のOSパニック検知機能の使用条件を満たしていることを確認する方法

条件
確認するタイミング
確認する
メッセージID
メッセージ
の出力先

Linux Tough Dump，およびHA Boosterがインストールされている。
定義チェックコマンド（moncheckコマンド）実行時
KAMN180-I
標準出力

Linux Tough Dumpが起動している。また，HA Boosterがインストールされている。
HAモニタ起動時※
KAMN695-IまたはKAMN699-I
syslog

他系のOSパニック検知機能が有効化されている。
HAモニタ起動時※
KAMN695-IまたはKAMN699-I
syslog

注※　HAモニタ起動時にメッセージKAMN696-WまたはKAMN651-Eがsyslogに出力された場合は，該当する条件を満たしていないおそれがあるため，出力されたメッセージの説明に従って対処をしてください。

Linux Tough Dump，およびHA Boosterについては，弊社担当営業にお問い合わせください。

3.2.8　仮想化環境での物理パーティションリセット機能

HAモニタでは，日立サーバ仮想化機構（Virtage）またはVMware ESXiを利用して，仮想化環境での系切り替えができます。

日立サーバ仮想化機構（Virtage）を搭載したBladeSymphonyの場合，プロセサを論理パーティション（LPAR）で分割し，LPARを系切り替えの単位にできます。日立サーバ仮想化機構を利用してLPARを稼働させる環境をLPARモード，日立サーバ仮想化機構を利用しない環境をBasicモードといいます。なお，このマニュアルでは，日立サーバ仮想化機構を搭載していないBladeSymphonyの環境をBasicモードと呼ぶことがあります。

VMware ESXiを利用する場合，一つのプロセサで複数の仮想マシンを稼働させ，仮想マシンを系切り替えの単位にできます。

ここでは，これらの仮想化環境の場合にオプションとして使用できる物理パーティションリセット機能について，通常の系切り替えの動作と比較して説明します。

＜この項の構成＞

(1)　通常の系切り替えの動作

(2)　物理パーティションリセット機能使用時の動作

(3)　必要な環境設定

(1)　通常の系切り替えの動作

HAモニタは，LPARモード時はLPAR単位で，VMware ESXi使用時は仮想マシン単位で系障害を検出します。デフォルトの設定では，実行系に系障害が発生した場合，待機系のHAモニタは実行系のHAモニタが動作するLPARまたは仮想マシンだけをリセットします。LPARモードの実行系に系障害が発生した場合の，通常の系切り替えの動作を，次の図に示します。VMware ESXi使用時に，実行系に系障害が発生した場合の通常の系切り替えの動作は，LPARモード時と同じです。LPARを仮想マシンに読み替えてください。

図3-19　LPARモードでの系切り替えの動作

(2)　物理パーティションリセット機能使用時の動作

通常，HAモニタが系のリセットに失敗すると，切り替え先の系はユーザの操作を待つ状態になります。

物理パーティションリセット機能とは，系（LPAR・仮想マシン）のリセットに失敗した場合に次に示す障害が発生したと見なし，障害が発生した系（LPAR・仮想マシン）があるプロセサ全体をリセットする機能です。

HVMシステム障害（日立サーバ仮想化機構の障害で，系障害の一種）

VMware ESXiの障害

プロセサの障害

ネットワーク障害などによるVMware ESXiとの通信不可

この機能を使用すると，HAモニタは，プロセサ内にほかのLPARや仮想マシンが稼働しているかどうかに関係なく，リセットを実行します。

プロセサ全体をリセットするのは，障害が発生した系と障害を検知した系とが異なるプロセサにある場合です。障害が発生した系と障害を検知した系とが同一プロセサ内にある場合は，プロセサ全体をリセットしないで，系切り替え先の系でユーザの操作を待つ状態になります。

物理パーティションリセット機能を使用すると，HAモニタは，プロセサ内のほかのLPARや仮想マシンを稼働させ続けることよりも，障害が発生したLPARや仮想マシンに対して系切り替えをすることを優先します。したがって，切り替え先の系にある待機サーバはユーザの操作を待つことなく，実行サーバとして起動します。

LPARモード時の，物理パーティションリセット機能を使用したときの動作を次の図に示します。VMware ESXi使用時に，物理パーティションリセット機能を使用したときの動作は，LPARモード時の動作と同じです。LPARを仮想マシンに読み替えてください。

図3-20　物理パーティションリセット機能使用時の動作

物理パーティションリセット機能を使用して系切り替えをするとプロセサ全体がリセットされるため，リセット対象のプロセサ内にあるほかのLPAR（仮想マシン）も同時にリセットされます。

したがって，リセット対象のプロセサ内に，系切り替えよりも優先したい業務上重要なLPARや仮想マシンが稼働していないことを確認した上で，この機能を使用してください。系切り替えよりも重要なLPARや仮想マシンが稼働している場合は，この機能は使用しないでください。物理パーティションリセット機能を使用しない場合で，系のリセットに失敗したときのHAモニタの動作については，「4.2.4　系のリセットに失敗した場合の動作」を参照してください。

(3)　必要な環境設定

物理パーティションリセット機能を使用するかどうかは，HAモニタの環境設定のpartition_resetオペランドで指定します。

3.2.9　N+Mコールドスタンバイ構成での系切り替え

HAモニタでは，JP1/ServerConductorのN+Mコールドスタンバイ構成で系切り替えができます。N+Mコールドスタンバイ構成の現用のサーバモジュールに障害が発生すると，HAモニタによる系切り替えのあと，JP1/ServerConductorが現用のサーバモジュールの各種設定，ローカルディスクなどを予備のサーバモジュールに引き継ぎます。このため，予備のサーバモジュールを待機系として使用できます。

なお，VMware ESXiで仮想化する場合は，N+Mコールドスタンバイ構成での系切り替えはできません。

＜この項の構成＞

(1)　N+Mコールドスタンバイ構成での系切り替えの動作

(2)　必要な環境設定

(1)　N+Mコールドスタンバイ構成での系切り替えの動作

N+Mコールドスタンバイ構成での系切り替えの動作を次の図に示します。

図3-21　N+Mコールドスタンバイ構成での系切り替えの動作

現用のサーバモジュール1に系障害が発生した場合，HAモニタは系障害を検出して現用のサーバモジュール2に系切り替えをします。系切り替えによって，現用のサーバモジュール2が実行系になります。

その後，JP1/ServerConductorが現用のサーバモジュール1の各種設定，ローカルディスクなどを予備のサーバモジュールに引き継ぎます。これによって，予備のサーバモジュールが待機系になります。

同様に，現用のサーバモジュール2に系障害が発生した場合も，予備のサーバモジュールが待機系になります。

(2)　必要な環境設定

N+Mコールドスタンバイ構成での系切り替えをするには，リセットパスの設定，およびSVPコマンドモードのHAコマンドでの設定が必要です。詳細については，「6.4.1　設定に必要な情報（BladeSymphony）」および「6.4.2(6)　N+Mコールドスタンバイ構成」を参照してください。

N+Mコールドスタンバイ構成については，マニュアル「JP1/ServerConductor/Blade Server Manager系 システム管理者ガイド」を参照してください。

3.3　共有リソースの制御のための機能

サーバが使用する共有リソースを切り離したり，接続したりするときに使用できる機能について説明します。

HAモニタでは，共有リソースとして，共有ディスク，およびLANの自動系切り替えができます。これ以外の共有リソースを切り替えるためには，ユーザがコマンドを作成する必要があります。詳細については，「3.3.2　サーバやHAモニタの状態変化時のコマンド発行」を参照してください。

＜この節の構成＞

3.3.1　リソースサーバを使用した共有リソースの共用

3.3.2　サーバやHAモニタの状態変化時のコマンド発行

3.3.3　共有リソース接続失敗時のサーバの起動中止

3.3.4　共有リソース引き継ぎのタイムアウト

3.3.5　共有リソースの切り離し順序指定

3.3.6　共有リソースの動的変更

3.3.1　リソースサーバを使用した共有リソースの共用

通常，共有リソースは，サーバごとに準備する必要があります。リソースサーバを使用すると，共有リソースを複数のサーバで共用できます。準備できる共有リソースが限られている場合などにリソースサーバを使用してください。

＜この項の構成＞

(1)　リソースサーバを使用した構成

(2)　必要な環境設定

(1)　リソースサーバを使用した構成

リソースサーバとは，共有リソースを制御するサーバです。リソースサーバではプログラムを実行しません。リソースサーバは，常にサーバとグループ化して使用します。リソースサーバを使用すると，サーバグループ単位で共有リソースを制御できます。

リソースサーバを使用した構成例を次の図に示します。この構成例の場合，サーバ1およびサーバ2が，同じ共有ディスク，およびエイリアスIPアドレスを共用しています。

図3-22　リソースサーバを使用した構成例

なお，リソースサーバを使用しないと，サーバをグループ化して連動系切り替えをする場合も，共有リソースの制御はサーバ単位に行うため，複数のサーバで同一の共有リソースを共用することはできません。

(2)　必要な環境設定

リソースサーバを使用するには，次の環境設定が必要です。

リソースサーバの設定を，サーバ対応の環境設定のresource定義文で定義する。
リソースサーバを系に追加するため，リソースサーバの環境設定が必要です。

サーバのグループ化の設定を，サーバ対応の環境設定のgroupオペランドに指定する。
同じグループで稼働する，すべてのサーバで指定が必要です。

サーバの順序制御の設定を，サーバ対応の環境設定のparentオペランドに指定する。
同じグループ内で稼働するリソースサーバ以外のサーバで，リソースサーバを親サーバとして指定します。

3.3.2　サーバやHAモニタの状態変化時のコマンド発行

HAモニタでは，サーバの状態変化やHAモニタの状態変化時に，ユーザが作成したコマンドを自動発行できます。このコマンドをユーザコマンドと呼びます。ユーザコマンドの作成は任意です。

＜この項の構成＞

(1)　ユーザコマンドを使用するメリット

(2)　必要な環境設定

(1)　ユーザコマンドを使用するメリット

ユーザコマンドを作成しておくと，サーバの起動や系切り替え，サーバ障害発生時などのHAモニタの処理を契機に，HAモニタにユーザ任意の処理を自動で実行させることができます。

ユーザコマンド内に，HAモニタが対応していない共有リソースの処理を記載しておくことで，任意のリソースを系間で共有することもできます。

ユーザコマンドが発行されるタイミングの詳細や，HAモニタからユーザコマンドに渡されるパラメタについては，「6.16　ユーザコマンドの作成」を参照してください。

(2)　必要な環境設定

ユーザコマンドを作成し，HAモニタの環境設定のusrcommandオペランドに，作成したユーザコマンドを指定します。ユーザコマンドの作成方法，およびコーディング例については，「6.16　ユーザコマンドの作成」を参照してください。

3.3.3　共有リソース接続失敗時のサーバの起動中止

共有リソースの接続失敗時やユーザコマンドの失敗時に，実行サーバの起動や系切り替えを中止できます。リソースごとに，サーバの起動を中止するかどうかを指定できます。

共有リソースの接続に失敗した場合は，残りの共有リソースに関する接続処理を続行したあと，実行サーバの起動を中止し，最終的にすべての共有リソースの切り離しをします。系切り替えを中止する場合は，待機サーバを強制停止します。

＜この項の構成＞

(1)　対象となる共有リソース

(2)　必要な環境設定

(1)　対象となる共有リソース

対象となる共有リソースは次のとおりです。

共有ディスク

ファイルシステム

LAN（サーバ識別名.upファイルによるIPアドレス設定）

ユーザコマンド

(2)　必要な環境設定

設定方法を次に示します。

(a)　共有ディスクの設定方法

サーバ対応の環境設定のvg_neckオペランドにuseを指定します。なお，HAモニタのサーバの共有リソース動的変更コマンド（mondeviceコマンド）によって，vg_neckオペランドの指定の変更もできます。

(b)　ファイルシステムの設定方法

サーバ対応の環境設定のfs_neckオペランドにuseを指定します。

(c)　LANの設定方法

サーバ対応の環境設定のip_neckオペランドにuseを指定します。

また，HAモニタでのLANの状態設定ファイルである，サーバ識別名.upファイルについて，LAN接続失敗時に，サーバ識別名.upファイルの実行結果（終了コード）が0以外になるように作成してください。

なお，サーバ識別名.downファイルの実行結果については，HAモニタの動作に影響を与えません。

実行サーバの起動や系切り替えを中止する場合の，サーバ識別名.upファイルの例を次に示します。これらのファイルのサンプルは，HAモニタサンプルファイル用ディレクトリの下に，server_on_neckIP.upのファイル名で格納されています。

#!/bin/sh

set -x

INTERFACE=ethX:Y                        # LAN interface name
IPADDR=aaa.bbb.ccc.ddd                  # alias IP address
NETMASK=eee.fff.ggg.hhh                 # netmask address
BROADCAST=iii.jjj.kkk.lll               # broadcast address

# The alias IP address is added to the LAN interface.
/sbin/ifconfig $INTERFACE inet $IPADDR netmask $NETMASK broadcast $BROADCAST
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

# The ARP caches are updated.
IFNAME=`echo $INTERFACE | /bin/sed -e 's/:[0-9]*$//'`
/sbin/arping -U -c 2 -I $IFNAME $IPADDR

# Was the alias IP address registered to the system ?
RCD=`/sbin/ifconfig -a | /bin/grep ":$IPADDR "`
if [ "$RCD" = "" ]
then
   # When it is not registered, "1" is returned as the termination code.
   exit 1
fi

#  When it is registered, "0" is returned as the termination code.
exit 0

(d)　ユーザコマンドの設定方法

サーバ対応の環境設定のuoc_neckオペランドにuseを指定することによって，ユーザコマンドの実行結果が0以外の場合に，サーバの起動を中止できます。

なお，HAモニタがエラーの確認をするのは，「サーバの起動開始」および「サーバの系切り替え開始」時に実行するユーザコマンドだけです。このほかのタイミングでのユーザコマンド実行結果は無視されます。

ユーザコマンドの詳細については，「6.16　ユーザコマンドの作成」を参照してください。

3.3.4　共有リソース引き継ぎのタイムアウト

系切り替え時に，共有リソースの引き継ぎ（切り離しおよび接続）が制限時間内に終了するかを監視する機能について説明します。タイムアウトは，系切り替え時だけ監視します。サーバの起動・停止時は監視しません。

＜この項の構成＞

(1)　タイムアウト検出時の動作

(2)　監視できる範囲

(3)　必要な環境設定

(1)　タイムアウト検出時の動作

共有リソースの切り離し処理全体，または接続処理全体に制限時間を設け，制限時間以内に処理が完了しなかった場合に，共有リソースに対する処理を中止します。

共有リソース接続失敗時にサーバの起動を中止する機能を使用している場合，共有リソースの接続処理がタイムアウトすると，サーバの起動を中止します。

(2)　監視できる範囲

制限時間を監視できる範囲は，次のどちらかです。指定した制限時間内にそれぞれの処理が完了するかを，別々に監視します。

切り替え元の系で，共有リソースの切り離し開始から「サーバ障害処理開始」のユーザコマンド実行完了までの間。

切り替え先の系で，共有リソースの接続開始から「サーバ系切り替え開始」のユーザコマンド実行完了までの間。

(3)　必要な環境設定

制限時間を，サーバ対応の環境設定のdev_timelimitオペランドに指定します。

3.3.5　共有リソースの切り離し順序指定

ここでは，共有リソースの切り離し時の処理順序の指定について説明します。共有リソースの切り離しは，サーバの停止時や系切り替え時などに自動的に実行されます。

共有リソースの切り離しには，次のどちらかを指定できます。

接続時と同じ順序で共有リソースの切り離しをする

接続時とは逆の順序で共有リソースの切り離しをする

接続時とは逆の順序で切り離しをする場合，ユーザコマンドを発行したあとに共有リソースの切り離しが行われるため，ユーザコマンドのユーザ独自の停止処理の中に，共有リソースに依存した処理を実装できます。共有リソースとの接続時には，共有リソースを接続したあとに，ユーザコマンドが発行されます。

逆順に切り離しをする場合の詳細な処理の流れについては，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

＜この項の構成＞

(1)　必要な環境設定

(1)　必要な環境設定

deviceoff_orderオペランドに指定します。デフォルトでは，接続時と同じ順でHAモニタが共有リソースの切り離しをします。

逆順での切り離しを適用したい範囲によって，定義する環境設定が異なります。HAモニタの環境設定およびサーバ対応の環境設定の両方に定義した場合は，HAモニタの環境設定が優先されます。

HAモニタに登録されているすべてのサーバに適用する場合
HAモニタの環境設定に指定します。

ある特定のサーバだけに適用する場合
サーバ対応の環境設定に指定します。

3.3.6　共有リソースの動的変更

系切り替えの対象となる共有リソースは，24時間連続稼働などで実行サーバを停止できない場合でも，動的に変更できます。

＜この項の構成＞

(1)　動的に変更できる共有リソース

(2)　動的変更の方法

(1)　動的に変更できる共有リソース

変更できる共有リソースを次に示します。

共有ディスク

LAN

(2)　動的変更の方法

リソースの種類によって動的変更の方法が異なります。

(a)　共有ディスク

サーバの共有リソース動的変更コマンド（mondeviceコマンド）を使用します。サーバの共有リソース動的変更コマンド（mondeviceコマンド）では，共有リソースを，サーバ対応の環境設定で指定した単位で追加・削除できます。

サーバの共有リソース動的変更コマンド（mondeviceコマンド）を使用した共有リソースの動的変更の概要を，次の図に示します。この図では，共有ディスクの追加を実行しています。

図3-23　HAモニタのmondeviceコマンドを使用した共有リソースの動的変更の概要

ユーザがサーバの共有リソース動的変更コマンド（mondeviceコマンド）を使用すると，HAモニタは次の処理を実行します。

共有リソースの状態を制御し，サーバへの接続や切り離しを実行します（共有リソースの追加をする場合）。

共有リソースの変更結果に合わせて，そのリソースを共有している実行サーバと待機サーバのサーバ対応の環境設定を自動で書き換えます（共有リソースの追加・変更・削除をする場合）。

(b)　LAN

ユーザがLANの状態設定ファイルに，追加・削除するLANの情報を追加・削除することで行います。

3.4　プログラムの制御のための機能（モニタモード）

モニタモードでは，Cosminexus，JP1，UAPなどの複数のプログラムを一つのサーバに対応させることができます。このとき，UAP単位で起動，監視，および停止することもできます。UAP単位で動作を制御する機能のことを，モニタモードのプログラム管理機能といいます。

プログラム管理機能でUAPを監視する場合は，UAPからAPIを発行する必要があります。

ここでは，プログラム管理機能について説明します。

＜この節の構成＞

3.4.1　UAPの監視

3.4.1　UAPの監視

モニタモードのサーバのプログラムの場合，通常は，サーバの監視コマンドを作成して監視します。ただし，UAPを監視する場合は，モニタモードのプログラム管理機能を使用すれば，サーバの監視コマンドにUAPの監視処理を作り込まなくても，HAモニタがUAPを監視できます。UAPからUAP監視用のAPIを発行することで，HAモニタがUAPを監視し，UAPに起因するサーバ障害を検出できます。

プログラム管理機能使用時のUAPの監視を，次の図に示します。

図3-24　プログラム管理機能使用時のUAPの監視

プログラム管理機能でUAPを監視するためには，ユーザがUAPにAPIを組み込む必要があります。このため，APIを組み込んでUAPを修正できる場合だけ，UAPを監視できます。UAPへのAPIの組み込み，および組み込みができるUAPの条件については，「6.13.1　UAPへのAPIの組み込み」を参照してください。

＜この項の構成＞

(1)　UAPの監視方法

(2)　必要な環境設定

(1)　UAPの監視方法

HAモニタは，次の2種類の方法でUAPを監視し，UAP障害を検出します。それぞれの監視方法の詳細については，「4.7.1　UAPの監視制御」を参照してください。

UAPのプロセスの監視
HAモニタがUAPのプロセスの存在を監視する方法です。

UAPの稼働報告の監視
HAモニタがUAPから送られてくる稼働報告を監視する方法です。

HAモニタは，UAP障害を検出すると，UAPやサーバの再起動を実施します。UAP障害を検出したあとのHAモニタの動作については，「4.7.1(3)　UAP障害を検出したあとのHAモニタの動作」を参照してください。UAPの再起動時の動作については，「4.7.2　プログラムの再起動制御」を参照してください。

(2)　必要な環境設定

UAPを監視するには，次の環境設定が必要です。

プログラム管理機能を使用するための環境設定

プログラム管理機能の使用の有無
サーバ対応の環境設定のprogramオペランドにyesを指定します。

プログラムの最大数
HAモニタの環境設定のpgmmaxオペランドに，一つの系で同時に稼働できる，プログラム管理機能を使用するプログラムの最大数を指定します。デフォルト値は0であるため，pgmmaxオペランドの値を必ず指定してください。

プログラム管理機能の設定
モニタモードのプログラム対応の環境設定を定義します。モニタモードのプログラム対応の環境設定については，「8.5.1　モニタモードのプログラム対応の環境設定（programs）」を参照してください。

プログラムの再起動コマンドの作成

UAP障害発生時に，サーバ単位ではなく，UAP単位で自動で再起動する場合は，プログラムの再起動コマンドをユーザが作成する必要があります。作成したプログラムの再起動コマンドは，モニタモードのプログラム対応の環境設定のrestartcommandオペランドに指定します。プログラムの再起動コマンドの作成については，「6.12　プログラムの再起動コマンドの作成（プログラム管理機能使用時）」を参照してください。

UAPの環境変数の設定

UAPの実行に必要な環境変数を設定します。UAPの環境変数の設定については，「6.13.2　UAPの環境変数の設定」を参照してください。

3.5　HAモニタ Extensionの機能

ここでは，HAモニタ Extensionを導入した場合に使用できる機能について説明します。

HAモニタ Extensionは，HAモニタが制御する系の最大数を増やすなど，大規模なシステムでの系切り替え制御に対応するために使用する，HAモニタのオプション製品です。

HAモニタ Extensionは，OSがLinux（x86）の場合に使用できます。

HAモニタ Extensionの機能の一覧を次の表に示します。

表3-2　HAモニタ Extensionの機能の一覧

機能
HAモニタ Extensionを
使用した場合
HAモニタ Extensionを
使用しない場合

サーバの最大数の変更
一つの系で同時に稼働できるサーバの最大数を129以上に変更できます。
一つの系で同時に稼働できるサーバの最大数は128までです。

系の最大数の変更
一つの系切り替え構成での系の最大数を33以上に変更できます。
一つの系切り替え構成での系の最大数は32です。

それぞれの機能について，以降で説明します。

注意

HAモニタ Extensionを使用する場合は，系切り替え構成内のすべての系で，次の作業が必要です。

HAモニタ Extensionをインストールします。

定義ファイルで，HAモニタ Extensionの機能の環境設定をします。

HAモニタの環境設定コマンド（monsetup -exコマンド）を実行して，HAモニタ Extensionの機能を使用できるように設定します。

＜この節の構成＞

3.5.1　サーバの最大数の変更

3.5.2　系の最大数の変更

3.5.1　サーバの最大数の変更

一つの系で同時に稼働できるサーバの最大数は，デフォルトでは128までです。HAモニタ Extensionを使用すると，一つの系で同時に稼働できるサーバの最大数を129以上に変更できます。稼働するサーバの数が129以上の大規模なシステムでも，系切り替え構成を一つに集約できるようになります。

＜この項の構成＞

(1)　指定できるサーバの最大数

(2)　必要な環境設定

(1)　指定できるサーバの最大数

HAモニタ Extensionを使用すると，一つの系で同時に稼働できるサーバの最大数として，128～512を指定できます。

(2)　必要な環境設定

一つの系で同時に稼働できるサーバの最大数は，HAモニタの環境設定のservmaxオペランドに指定します。

また，HAモニタの環境設定コマンド（monsetup -exコマンド）を実行して，HAモニタ Extensionの機能を使用できるように設定してください。

3.5.2　系の最大数の変更

一つの系切り替え構成での系の最大数は，デフォルトでは32です。HAモニタ Extensionを使用すると，一つの系切り替え構成での系の最大数を33以上に変更できます。稼働する系の数が33以上の大規模なシステムでも，系切り替え構成を一つに集約できるようになります。

＜この項の構成＞

(1)　指定できる系の最大数

(2)　系の最大数を33以上に設定した場合の動作

(3)　必要な環境設定

(1)　指定できる系の最大数

HAモニタ Extensionを使用すると，一つの系切り替え構成での系の最大数として，32～256を指定できます。

(2)　系の最大数を33以上に設定した場合の動作

系の最大数を33以上に設定した場合，すべての監視パスでaliveメッセージがマルチキャストで送受信されます。マルチキャストで一つのaliveメッセージを送信すると，自系を除くすべてのHAモニタがaliveメッセージを受信します。aliveメッセージについては，「2.3.4(1)　系間の監視」を参照してください。

(3)　必要な環境設定

系の最大数を変更するには，次の環境設定が必要です。

一つの系切り替え構成での系の最大数を，HAモニタの環境設定のhostmaxオペランドに指定します。
系切り替え構成の中に，系の最大数を変更した系が含まれる場合は，系切り替え構成内のすべての系でこのオペランドを指定する必要があります。
なお，系の最大数を33以上に設定すると，aliveメッセージの通信方式が，自動的にマルチキャストになります。マルチキャストでの通信は，HAモニタの環境設定のalive_multicastオペランドでも指定できます。

マルチキャストグループIDを任意に指定したい場合は，マルチキャストグループID，およびマルチキャストグループIDに対応するホスト名を，/etc/hostsファイルに指定します。また，/etc/hostsファイルに指定したホスト名を，HAモニタの環境設定のmulticast_lanオペランドに指定します。
multicast_lanオペランドの指定を省略した場合は，マルチキャストグループIDとして，"239.0.0.1"を使用します。

HAモニタの環境設定コマンド（monsetup -exコマンド）を実行して，HAモニタ Extensionの機能を使用できるように設定します。

系の最大数を変更する場合の環境設定例を次の図に示します。

図3-25　系の最大数を変更する場合の環境設定例

この例では，系1～系32を現用系，系33を予備系とします。系1～系32では，それぞれ系33と接続するため，接続する系の数は自系を含めて2になります。系33では，系1～系32と接続するため，接続する系の数は自系を含めて33になります。このため，系33はhostmaxオペランドに33を指定します。系1～系32が接続する系の数は2ですが，系の最大数を33以上に指定した系33と接続しているため，系1～系32でもhostmaxオペランドに33を指定します。

4.　システムの管理

この章では，HAモニタがサーバ，系，および共有リソースをどのように管理しているかについて説明します。HAモニタの動作の詳細を知りたい場合にお読みください。

＜この章の構成＞

4.1　サーバの管理

4.2　系の管理

4.3　共有リソースの管理

4.4　サーバをグループ化する場合のサーバの管理

4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理

4.6　リソースサーバの管理

4.7　プログラムの管理（モニタモード）

4.8　処理の流れ

4.1　サーバの管理

HAモニタは，実行系と待機系で稼働し，実行サーバや待機サーバの起動・停止状態について連絡を取り合って，サーバの状態を制御しています。ここでは，HAモニタがどのようにサーバを制御しているかについて説明します。

なお，モニタモードのサーバでは，プログラム管理機能を使用することで，プログラム単位での制御ができます。プログラムの管理については，「4.7　プログラムの管理（モニタモード）」を参照してください。

＜この節の構成＞

4.1.1　HAモニタによるサーバの起動制御

4.1.2　HAモニタによるサーバの停止制御

4.1.3　サーバの状態遷移

4.1.4　サーバの監視コマンドの制御

4.1.5　サーバの切り替え順序制御をする場合の処理の流れ

4.1.1　HAモニタによるサーバの起動制御

ユーザは，サーバモードのサーバを，プログラムが提供する起動コマンドを実行することで起動します。また，モニタモードのサーバを，モニタモードのサーバ起動コマンド（monbeginコマンド）を実行することで起動します。

サーバ起動時には，HAモニタはサーバ対応の環境設定および他系のサーバの状態を確認した上で，サーバを実行サーバとして起動するか，待機サーバとして起動するかを決定します。ここでは，実行サーバと待機サーバの決定方法，および監視パスの障害などの理由で他系のサーバの状態が確認できない場合のHAモニタの動作について説明します。

＜この項の構成＞

(1)　通常時の実行サーバと待機サーバの決定方法

(2)　サーバの再起動時の起動種別

(1)　通常時の実行サーバと待機サーバの決定方法

通常，実行サーバと待機サーバの決定は，サーバ対応の環境設定のinitialオペランドで指定した起動種別および他系の状態を基にしてHAモニタが行います。実行サーバと待機サーバの決定方法を次の表に示します。

表4-1　実行サーバと待機サーバの決定方法

他系の状態 | サーバ対応の環境設定
実行サーバとして定義 | 待機サーバとして定義
実行サーバあり | 起動処理中 | 待機サーバとして起動 | 待機サーバとして起動
実行処理中 | 待機サーバとして起動 | 待機サーバとして起動
停止処理中 | 起動不可※1 | 起動不可※1
待機サーバあり | 起動処理中 | 実行サーバとして起動 | 起動不可※1
実行処理中 | 実行サーバとして起動 | 起動不可※1
停止処理中 | 実行サーバとして起動 | 実行サーバの起動待ち※2
連動系切り替え待ち状態※3 | 実行サーバとして起動 | 実行サーバとして起動
待機サーバから実行サーバへ系切り替え処理中 | 待機サーバとして起動 | 待機サーバとして起動
サーバなし（またはHAモニタ停止中） | 実行サーバとして起動 | 実行サーバの起動待ち※2
サーバの状態確認不可 | リトライ処理※4 | 実行サーバの起動待ち※2

注※1　サーバの起動を中止します。

注※2　他系の実行サーバの起動が確認できるまで待機サーバの起動を待たせます（実行サーバの起動待ち状態）。実行サーバの起動開始を確認できたら，待機サーバとして起動させます。

注※3　連動系切り替え待ち状態の詳細は，「4.4.1　連動系切り替え時のサーバの切り替え種別」を参照してください。

注※4　他系や監視パスの障害によって，他系で起動しているサーバの状態を確認できない場合は，1分間だけリトライします。リトライしてもさらに確認できない場合は，他系の障害でサーバがないものと判断し，実行サーバの起動待ち状態にします。

なお，障害発生によって，実行サーバとして定義されたサーバが再起動した場合は，実行サーバと待機サーバの決定方法が異なります。この場合については，「4.1.1(2)　サーバの再起動時の起動種別」を参照してください。

待ち状態のサーバを実行サーバとして起動したり，停止したりする方法については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

(2)　サーバの再起動時の起動種別

障害が発生した場合などにオペレータがコマンドを実行してサーバを再起動すると，HAモニタは，そのサーバが実行サーバとして定義されていても，他系のサーバの状態が確認できるまでは自動的に待機サーバとして待機させます。これは，他系のサーバの状態が確認できない間は，他系ですでに実行サーバが稼働しているおそれがあるためです。実行サーバが複数起動しないようHAモニタが制御します。

他系のサーバの状態が確認できたら，HAモニタがサーバを実行サーバとして起動するか，待機サーバとして起動するかを決定します。

実行サーバとして定義されたサーバを再起動する際の起動種別の決定方法を，次の表に示します。

表4-2　サーバ再起動時の起動種別の決定方法

他系の状態 | サーバの起動種別※1
実行サーバあり | 起動処理中 | 待機サーバとして起動
実行処理中 | 待機サーバとして起動
停止処理中 | 起動不可※2
待機サーバあり | 起動処理中 | 実行サーバとして起動
実行処理中 | 起動不可※2
停止処理中 | 実行サーバの起動待ち※3
連動系切り替え待ち状態 | 実行サーバとして起動
待機サーバから実行サーバへ系切り替え処理中 | 待機サーバとして起動
サーバなし（またはHAモニタ停止中） | 実行サーバの起動待ち※3
サーバの状態確認不可 | 実行サーバの起動待ち※3

注※1　サーバ対応の環境設定のinitialオペランドで指定した起動種別は，無視されます。

注※2　サーバの起動を中止します。

注※3　他系の実行サーバの起動が確認できるまで待機サーバの起動を待たせます（実行サーバの起動待ち状態）。実行サーバの起動開始を確認できたら，待機サーバとして起動させます。

待ち状態のサーバを実行サーバとして起動したり，停止したりする方法については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

4.1.2　HAモニタによるサーバの停止制御

HAモニタは，障害が発生した場合，およびオペレータがコマンドを実行した場合に，サーバを停止します。HAモニタがサーバを停止させる条件は，サーバがサーバモードかモニタモードかによって異なります。

＜この項の構成＞

(1)　サーバモードのサーバの場合

(2)　モニタモードのサーバの場合

(1)　サーバモードのサーバの場合

HAモニタがサーバを停止させる条件は，大きく分けて，次の場合があります。

オペレータがコマンドを実行した場合

プログラムが提供するコマンドなどで，オペレータが実行サーバを正常終了したり，サーバを計画停止または強制停止したりした場合は，HAモニタは実行サーバに対応している待機系の待機サーバを停止させます。

オペレータが，実行サーバに対してプログラムが提供する強制停止コマンドを実行した場合，HAモニタは計画停止と同様に処理します。オペレータが，待機サーバに対してプログラムが提供する強制停止コマンドを実行した場合，異常終了と同様に処理します。

オペレータが計画系切り替えコマンド（monswapコマンド）を実行した場合，HAモニタは系切り替えの前に実行サーバを停止させます。

オペレータが待機サーバ停止コマンド（monsbystpコマンド）を実行した場合，HAモニタは指定された待機サーバを停止させます。

障害が発生した場合

HAモニタがサーバ障害を検出した場合は，サーバ対応の環境設定に指定された内容に従って，次のどちらかの動作をします。

系切り替えをするように指定していれば，HAモニタは系切り替えの前に実行サーバを停止させます。

実行サーバを再起動するように指定していれば，実行サーバの状態を実行サーバの再起動待ち状態に変更して，実行サーバが再起動するのを待ちます。

HAモニタがサーバを停止させる事象と停止後の処理を，次の表に示します。

表4-3　サーバを停止させる事象と停止後の処理（サーバモード）

事象 | HAモニタが停止させるサーバ | 停止後のHAモニタの処理
サーバでの事象 | 実行サーバ正常終了※1 | 待機サーバ | －
実行サーバ異常終了※2 | － | 自動系切り替え※3
待機サーバ正常終了 | － | －
待機サーバ異常終了※4 | － | －
HAモニタでの事象 | 実行サーバ障害検出 | 実行サーバ※3 | 自動系切り替え※3
待機サーバ停止コマンド（monsbystpコマンド） | 待機サーバ | －
計画系切り替えコマンド※5（monswapコマンド） | 実行サーバ | 計画系切り替え

（凡例）－：何もしません。

注※1　サーバの計画停止，強制停止を含みます。

注※2　サーバ自身が障害を検知した場合です。

注※3　系切り替えをする待機サーバがない場合は，HAモニタは何もしません。また，サーバ対応の環境設定のswitchtypeオペランドにrestartまたはmanualを指定した場合は，実行サーバを停止させないで実行サーバを再起動待ち状態にします。HAモニタは，系切り替えをしないで実行サーバの再起動を待ちます。

注※4　サーバの強制停止，およびサーバ自身が障害を検知した場合です。

注※5　系切り替えをする待機サーバがない場合は，HAモニタは何もしません。

(2)　モニタモードのサーバの場合

サーバがモニタモードの場合，サーバの切り替えおよび停止は，ユーザがHAモニタのコマンドで指示します。

サーバを停止させる事象と停止後の処理を，次の表に示します。

表4-4　サーバを停止させる事象と停止後の処理（モニタモード）

事象 | HAモニタが停止させるサーバ | 停止後のHAモニタの処理
サーバでの事象 | 実行サーバ正常終了 | － | －
実行サーバ異常終了 | － | 計画系切り替えまたは自動系切り替え※1，※2
待機サーバ正常終了 | － | －
待機サーバ異常終了 | － | －
HAモニタでの事象 | モニタモードのサーバ停止コマンド（monendコマンド） | 実行サーバ※1および待機サーバ | －
待機サーバ停止コマンド（monsbystpコマンド） | 待機サーバ | －
計画系切り替えコマンド（monswapコマンド） | 実行サーバ※3 | 計画系切り替え※3

（凡例）－：何もしません。

注※1　サーバ対応の環境設定で，termcommandオペランドにサーバの停止コマンドを指定している場合は，HAモニタがサーバの停止コマンドを実行し，サーバの停止コマンド内に記述されている実行サーバも停止させます。

注※2　オペレータが実行系から計画系切り替えコマンド（monswapコマンド）を実行して指示します。サーバ対応の環境設定で，patrolcommandオペランドにサーバの監視コマンドを指定している場合は，HAモニタが再起動，または自動系切り替えをします。系切り替えをする待機サーバがない場合は，HAモニタは何もしません。

注※3　オペレータが，実行サーバを計画停止したあとに，実行系から計画系切り替えコマンド（monswapコマンド）を実行します。ただし，サーバ対応の環境設定のtermcommandオペランドにサーバの停止コマンドを指定している場合は，monswapコマンドで実行サーバを停止できます。なお，系切り替えをする待機サーバがない場合は，HAモニタは何もしません。

4.1.3　サーバの状態遷移

HAモニタは，サーバの状態を制御しています。ここでは，サーバモードのサーバの状態遷移について説明します。

サーバは，実行サーバとして起動した場合と，待機サーバとして起動した場合とで状態遷移が異なります。

＜この項の構成＞

(1)　実行サーバとして起動した場合のサーバの状態遷移

(2)　待機サーバとして起動した場合のサーバの状態遷移

(1)　実行サーバとして起動した場合のサーバの状態遷移

サーバモードで運用するサーバを実行サーバとして起動した場合の，サーバの状態遷移を次の図に示します。

図4-1　実行サーバの状態遷移（サーバモード）

注※1　サーバの切り替え順序制御を適用したサーバグループに所属している場合だけ，状態が遷移します。

注※2　ボリュームグループやLAN，ファイルシステムなど，サーバが使用する共有リソースへの接続失敗を表します。サーバ対応の環境設定で，vg_neckオペランド，ip_neckオペランドなどを指定した場合だけ，状態が遷移します。

注※3　サーバの起動開始時，または系切り替え開始時に発行されるユーザコマンドが失敗した場合を表します。サーバ対応の環境設定で，uoc_neckオペランドを指定した場合だけ，状態が遷移します。

(2)　待機サーバとして起動した場合のサーバの状態遷移

サーバモードで運用するサーバを待機サーバとして起動した場合の，サーバの状態遷移を次の図に示します。

図4-2　待機サーバの状態遷移（サーバモード）

注※1　サーバの起動開始時または系切り替え開始時に発行されるユーザコマンドの失敗を表します。サーバ対応の環境設定のuoc_neckオペランドを指定した場合だけ，状態が遷移します。

注※2　サーバの切り替え順序制御を適用したサーバグループに所属している場合だけ，状態が遷移します。

注※3　複数スタンバイ構成の場合だけ，状態が遷移することがあります。

注※4　自系よりも優先度が高い待機サーバがない場合だけ，状態が遷移します。

注※5　マルチスタンバイ機能使用時に系のリセットを抑止する場合だけ，状態が遷移します。

4.1.4　サーバの監視コマンドの制御

サーバの監視コマンドはモニタモードのサーバを監視するためのコマンドで，ユーザが作成します。ここでは，サーバの監視コマンドの起動，停止，および監視処理の流れについて説明します。

＜この項の構成＞

(1)　サーバの監視コマンドの起動

(2)　サーバの監視コマンドの停止

(3)　処理の流れ

(1)　サーバの監視コマンドの起動

サーバの監視コマンドの起動はHAモニタがします。ユーザが手動で起動する必要はありません。サーバの監視コマンドが起動されるタイミングは，実行系でサーバを起動し，実行サーバが起動完了したあとです。サーバの監視コマンド起動後，HAモニタはサーバの監視コマンドのプロセスの監視を開始します。HAモニタがサーバの監視コマンドの起動に失敗した場合，監視処理は実行されませんがサーバ処理は正常に続行されます。

(2)　サーバの監視コマンドの停止

サーバの監視コマンドは，サーバ障害を検出して自身が終了する以外に，HAモニタが停止させることもあります。HAモニタがサーバの監視コマンドを停止させるタイミングは，実行サーバを正常終了させた場合，または計画系切り替えをさせた場合です。これらの場合，HAモニタはサーバの監視コマンドを停止させます。

(3)　処理の流れ

サーバの監視コマンドを使用してモニタモードのサーバを監視した場合の，処理の流れを次の図に示します。

図4-3　モニタモードのサーバの監視の流れ

4.1.5　サーバの切り替え順序制御をする場合の処理の流れ

複数のサーバをグループ化する場合に，グループ内のサーバの切り替え順序を制御できます。ここでは，計画系切り替え，サーバ障害発生時，および系障害発生時のサーバの切り替え順序制御処理の流れと，系切り替えが失敗した場合の動作について説明します。

＜この項の構成＞

(1)　計画系切り替え，およびモニタモードのサーバ障害時の順序制御の流れ

(2)　サーバモードのサーバ障害時の順序制御の流れ

(3)　系障害時の順序制御の流れ

(4)　系切り替えが失敗した場合の動作

(5)　切り替え元の系のサーバについて

(1)　計画系切り替え，およびモニタモードのサーバ障害時の順序制御の流れ

計画系切り替え時の，サーバの停止順序，および切り替え先の系でのサーバの起動順序の流れを次の図に示します。この図で示すサーバの親子関係については，「3.1.3(1)　サーバの起動順序と親子関係の対応」を参照してください。

図4-4　計画系切り替え時の順序制御の流れ

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

実行系に実行サーバ1～4，待機系に待機サーバ1～4が起動完了していて，連動系切り替えができる状態です。

計画系切り替えコマンド（monswapコマンド）を実行して，計画系切り替えを開始します。

親子関係上，最も下位のサーバであるサーバ3とサーバ4の停止処理を開始します。サーバ1とサーバ2は停止待ちになります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ1およびサーバ2の状態は「ONL」と表示されます。「ONL」は実行サーバの起動完了という意味ですが，実際サーバは停止待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ3とサーバ4は，それぞれ並行して停止処理を実施します。停止処理は「サーバの停止」，「共有リソースの切り離し」の順に処理されます。共有リソースの切り離しが完了すると，待機系に系切り替えのための連絡をします。その後，サーバ3およびサーバ4は親サーバであるサーバ2の系切り替え完了を待つため，サーバ3およびサーバ4が前提サーバの起動待ち状態になります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ3およびサーバ4の状態は「(ONL)」と表示されます。「(ONL)」は実行サーバの起動中という意味ですが，実際，サーバは前提サーバの起動待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ3とサーバ4の両方の停止処理が完了すると，続けてそれらの親サーバであるサーバ2の停止処理を開始します。

サーバ2の停止処理が完了すると，その親サーバであるサーバ1の停止処理を開始します。

最も上位のサーバであるサーバ1の停止処理が完了すると，待機系へ連絡し，まず，サーバ1の系切り替えを開始します。

サーバ1が系切り替えによって実行サーバとして起動完了すると，続けて，その子サーバであるサーバ2の系切り替えを開始します。

サーバ2の系切り替えが完了すると，その子サーバであるサーバ3，およびサーバ4の系切り替えを並行して開始します。サーバ3およびサーバ4の系切り替えが完了すると，連動系切り替えが完了します。

(2)　サーバモードのサーバ障害時の順序制御の流れ

サーバ障害が発生した場合の，サーバの停止順序，および切り替え先の系でのサーバの起動順序の流れを次の二つに分けて説明します。

親サーバと子サーバの両方を持つサーバに障害が発生した場合

サーバの親子関係で最下位のサーバに障害が発生した場合

これらの図で示すサーバの親子関係については，「3.1.3(1)　サーバの起動順序と親子関係の対応」を参照してください。

(a)　親サーバと子サーバの両方を持つサーバに障害が発生した場合

ここでは，親サーバと子サーバの両方を持つサーバに障害が発生した場合の順序制御の流れを図で示します。

図4-5　サーバ障害時の順序制御の流れ（親サーバと子サーバの両方を持つサーバに障害が発生した場合）

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

実行系に実行サーバ1～4，待機系に待機サーバ1～4が起動完了していて，連動系切り替えができる状態です。

実行サーバ2に障害が発生すると，連動系切り替えを開始します。

障害が発生した実行サーバ2と，親子関係上，最も下位のサーバであるサーバ3とサーバ4の停止処理を開始します。サーバ1は停止待ちになります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ1の状態は「ONL」と表示されます。「ONL」は実行サーバの起動完了という意味ですが，実際サーバは停止待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ2～4は，それぞれ並行して停止処理を実施します。停止処理は「サーバの停止」，「共有リソースの切り離し」の順に処理されます。共有リソースの切り離しが完了すると，待機系に系切り替えのための連絡をします。その後，サーバ2～4は前提サーバの起動待ち状態になります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ2～4の状態は「(ONL)」と表示されます。「(ONL)」は実行サーバの起動中という意味ですが，実際，サーバは前提サーバの起動待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ2～4のすべての停止処理が完了すると，最も上位のサーバであるサーバ1の停止処理を開始します。

サーバ1の停止処理が完了すると，待機系へ連絡し，まず，サーバ1の系切り替えを開始します。

サーバ1の系切り替えが完了すると，その子サーバであるサーバ2の系切り替えを開始します。

サーバ2の系切り替えが完了すると，その子サーバであるサーバ3，およびサーバ4の系切り替えを並行して開始します。サーバ3およびサーバ4の系切り替えが完了すると，連動系切り替えが完了します。

(b)　サーバの親子関係で最下位のサーバに障害が発生した場合

ここでは，サーバの親子関係で最下位のサーバに障害が発生した場合の起動順序制御の流れを図で示します。

図4-6　サーバ障害時の順序制御の流れ（サーバの親子関係で最下位のサーバに障害が発生した場合）

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

実行系に実行サーバ1～4，待機系に待機サーバ1～4が起動完了していて，連動系切り替えができる状態です。

実行サーバ3に障害が発生すると，連動系切り替えを開始します。

親子関係上，最も下位のサーバであるサーバ3とサーバ4の停止処理を開始します。サーバ1とサーバ2は停止待ちになります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ1およびサーバ2の状態は「ONL」と表示されます。「ONL」は実行サーバの起動完了という意味ですが，実際サーバは停止待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ3とサーバ4は，それぞれ並行して停止処理を実施します。停止処理は「サーバの停止」，「共有リソースの切り離し」の順に処理されます。共有リソースの切り離しが完了すると，待機系に系切り替えのための連絡をします。その後，サーバ3およびサーバ4は親サーバであるサーバ2の系切り替え完了を待つため，サーバ3およびサーバ4が前提サーバの起動待ち状態になります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ3およびサーバ4の状態は「(ONL)」と表示されます。「(ONL)」は実行サーバの起動中という意味ですが，実際，サーバは前提サーバの起動待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

サーバ3およびサーバ4両方の停止処理が完了すると，続けて，それらの親サーバであるサーバ2の停止処理を開始します。

サーバ2の停止処理が完了すると，その親サーバであるサーバ1の停止処理を開始します。

最も上位のサーバであるサーバ1の停止処理が完了すると，待機系へ連絡し，まず，サーバ1の系切り替えを開始します。

サーバ1の系切り替えが完了すると，その子サーバであるサーバ2の系切り替えを開始します。

サーバ2の系切り替えが完了すると，その子サーバであるサーバ3，およびサーバ4の系切り替えを並行して開始します。サーバ3およびサーバ4の系切り替えが完了すると，連動系切り替えが完了します。

(3)　系障害時の順序制御の流れ

系障害が発生した場合の，サーバの停止順序，および切り替え先の系でのサーバの起動順序の流れを次の図に示します。この図で示すサーバの親子関係については，「3.1.3(1)　サーバの起動順序と親子関係の対応」を参照してください。

図4-7　系障害発生時の順序制御の流れ

次に，図に示した流れの詳細について説明します。番号は，図中の番号と対応しています。

実行系に実行サーバ1～4，待機系に待機サーバ1～4が起動完了していて，連動系切り替えができる状態です。

実行系に系障害が発生すると，実行系をリセットし，系切り替えを開始します。

親子関係上，最も上位のサーバであるサーバ1の系切り替えを開始します。

サーバ1の系切り替えが完了すると，その子サーバであるサーバ2の系切り替えを開始します。

サーバ2の系切り替えが完了すると，その子サーバであるサーバ3，およびサーバ4の系切り替えを並行して開始します。サーバ3およびサーバ4の系切り替えが完了すると，連動系切り替えが完了となります。

(4)　系切り替えが失敗した場合の動作

親サーバの系切り替え失敗時には，それ以降の子サーバも系切り替え失敗となり，対応する子サーバの待機サーバも強制停止されます。また，親サーバが切り替え先に存在しない場合は，無視して系切り替えを続行します。

(5)　切り替え元の系のサーバについて

順序制御機能を使用しているサーバグループで連動系切り替えをする場合，起動途中などで連動系切り替えができない状態のサーバは強制停止します。

切り替え元の系では，連動系切り替えで停止するサーバがすべて停止するまで，連動系切り替え中のサーバグループに所属するサーバは起動できません。

連動系切り替え中に系切り替え先のサーバが起動に失敗した場合，同一グループのサーバに一つも系切り替えができる待機サーバがなければ，実行サーバ起動失敗による連動系切り替えはしません。

TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）をサーバモードのサーバとして使用する場合，TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）が異常終了時に自動的に再起動しない設定にしてください。

参考

TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）が異常終了時に自動的に再起動しない設定にするには，次のオペランドの指定値に"MANUAL2"を指定します。

TP1/Server Baseの場合：システム環境定義のmode_confオペランド

HiRDB（プライマリ機能提供サーバ）の場合：システム共通定義のpd_mode_confオペランド

それぞれのオペランドについては，マニュアル「分散トランザクション処理機能 OpenTP1 システム定義」，またはマニュアル「HiRDB システム定義」を参照してください。

4.2　系の管理

HAモニタは，系障害が発生すると，系のリセットをしたあとに系切り替えをします。

ここでは，系のリセットに関するHAモニタの動作について説明します。オペレータの操作については，「7.　システムの運用」を参照してください。

＜この節の構成＞

4.2.1　系のリセットをする系の決定方法

4.2.2　両系が障害を同時に検出した場合の系切り替え

4.2.3　複数の待機系がある場合の系のリセット

4.2.4　系のリセットに失敗した場合の動作

4.2.1　系のリセットをする系の決定方法

HAモニタでは，実行系に系障害が発生すると，待機系が実行系に対して系のリセットをしたあとに，系切り替えをします。系切り替え構成によっては，複数の待機系が系のリセットを発行するため，実行系の回復が遅くなる場合があります。そのため，あらかじめ系のリセットをする待機系を決めておきます。この系のリセットをする待機系をリセット発行系と呼びます。複数の待機系が系のリセットを発行するおそれがある構成については，「3.2.3　系の二重リセットの防止」を参照してください。

ここでは，リセット発行系の決定方法，および系障害時のリセット発行系の動作について説明します。

＜この項の構成＞

(1)　リセット発行系の決定方法

(2)　系障害発生時のリセット発行系の動作

(1)　リセット発行系の決定方法

システム起動時に，オペレータは実行系で実行サーバを起動し，待機系では，実行サーバに対応する待機サーバを起動します。最初に実行系と待機系の組み合わせ（ペア）が成り立つと，その待機系が，実行系に対するリセット発行系になります。実行系で系障害が発生すると，最初にその実行系とペアになった待機系（リセット発行系）が実行系をリセットします。そのあとにほかの系との間でペアが成り立っても，実行系をリセットする系は，最初にペアになったリセット発行系だけです。

サーバが停止して，実行系と，最初にリセット発行系になった待機系とのペアが成り立たなくなった場合，リセット発行系はあとからペアになった待機系に変更されます。あとからペアになった待機系が複数ある場合は，その中でホストアドレスの最も小さい待機系が，以降のリセット発行系になります。

HAモニタがリセット発行系を決定する方法を，次の図に示します。

図4-8　HAモニタがリセット発行系を決定する方法

この図では，実行サーバ1が停止して実行系と待機系1とのペアが成り立たなくなったため，リセット発行系は，あとからペアになった待機系2または待機系3に変更されます。待機系2と待機系3とでは，待機系2のホストアドレスが小さいので，待機系2がリセット発行系になります。

(2)　系障害発生時のリセット発行系の動作

リセット発行系は，実行系をリセットすると，ほかの待機系に対してリセットの完了を連絡します。リセット発行系でない待機系は，リセット完了連絡を受けると，リセットされた実行系の実行サーバを，自系にある待機サーバに切り替えます。

リセット発行系でない待機系が実行系の系障害を検出した場合は，リセット発行系のリセット完了連絡があるまで，何もしないで待ちます。監視専用LANの障害などで，40秒（VMware ESXiで仮想化する場合は80秒）待ってもリセット完了連絡がない場合は，リセット発行系からのリセットが失敗したと見なし，実行系の系障害を検出した待機系が実行系をリセットします。

系障害発生時のリセット発行系の動作を，次の図に示します。

図4-9　系障害発生時のリセット発行系の動作

次に，系障害発生時のリセット発行系の動作の詳細を説明します。番号は，上記の図と対応しています。

リセット指示
待機系（リセット発行系）は，実行系の系障害を検出すると，実行系をリセットします。

リセット完了連絡
リセット完了後，ほかの待機系にリセット完了を連絡します。

系切り替え
リセット完了の連絡を受け取ると，実行系の実行サーバをそれぞれの待機サーバに系切り替えをします。

リセット発行系でない待機系が実行系の系障害を検出した場合の動作を，次の図に示します。

図4-10　リセット発行系でない待機系が実行系の系障害を検出した場合の動作

次に，リセット発行系でない待機系が実行系の系障害を検出した場合の動作の詳細を説明します。番号は，上記の図と対応しています。

リセット完了連絡未受信
リセット発行系以外の系が実行系の系障害を検出した場合は，リセット発行系のリセット完了の連絡を待ちます。

リセット指示
監視専用LANの障害などでリセット完了の連絡がない場合，障害を検出した系が実行系をリセットします。

リセットの完了連絡を待つ時間は40秒です。ただし，VMware ESXiで仮想化する場合は，80秒になります。

4.2.2　両系が障害を同時に検出した場合の系切り替え

実行系と待機系の両方が障害を同時に検出した場合，同時に系のリセットを発行し，実行系と待機系の両方が停止してしまうおそれがあります。そのため，HAモニタでは，優先して系のリセットをする系（リセット優先系）を決定しておく機能があります。実行系と待機系の両方が停止してしまうおそれがある構成については，「3.2.1　系の同時リセットの防止」を参照してください。

ここでは，実行系と待機系の両方が障害を同時に検出した場合に，HAモニタがどのように系切り替えをするか，について説明します。両系が同時に系障害を検出した場合の，HAモニタの処理の流れを，次の図に示します。

図4-11　両系が障害を同時に検出した場合の処理の流れ

注※

VMware ESXiで仮想化する場合は，40秒になります。

以降，図に示した「ユーザがリセット優先系を指定する設定か」どうかによる，系切り替え処理の違いについて説明します。

＜この項の構成＞

(1)　ユーザがリセット優先系を指定するときの系切り替え

(2)　ユーザがリセット優先系を指定しないときの系切り替え

(1)　ユーザがリセット優先系を指定するときの系切り替え

ユーザがHAモニタの環境設定でリセット優先系を指定しておくと，両方の系が同時に障害を検出した場合，リセット優先系が優先的に他系をリセットします。リセット優先系ではない系は，障害を検出してから20秒間（VMware ESXiで仮想化する場合は40秒間）待ったあと，リセット要求を発行します。ただし，リセット優先系に指定されていても，起動中のサーバが他系より多いか少ないかによって，リセット優先系が変わる場合があります。

(2)　ユーザがリセット優先系を指定しないときの系切り替え

ユーザがHAモニタの環境設定でリセット優先系を指定しない設定にしておくと，両方の系が同時に障害を検出した場合，HAモニタは両系から同時にリセット要求を発行します。このとき，SVPが先に受け付けたリセット要求だけを処理することで，同時リセットを防止します。リセット優先系を指定しない運用の場合，どちらの系もリセット発行を待たないため，系切り替えに掛かる時間が短縮されます。

この運用は，相互系切り替え構成で，かつマシンの機種がBladeSymphonyでSVPがクラスタ管理機能に対応している場合に選べます。クラスタ管理機能については，ハードウェア関連のドキュメントを参照してください。ただし，すべての監視パスに障害が発生した場合に，どちらかの系に系切り替えをしたいときは，ユーザがリセット優先系を指定してください。

ユーザがリセット優先系を指定しない場合，リセットパスの設定，およびSVPコマンドモードのHAコマンドでの設定が必要です。詳細については，「6.4.1　設定に必要な情報（BladeSymphony）」および「6.4.2(7)　相互系切り替え構成（リセット優先系を指定しない）」を参照してください。

4.2.3　複数の待機系がある場合の系のリセット

ここでは，複数スタンバイ構成のように，複数の待機系がある場合の系のリセットについて説明します。

＜この項の構成＞

(1)　リセット優先度の決定方法

(2)　リセット優先度を指定した場合の系のリセット

(3)　ある待機系からの系のリセットが失敗した場合の動作

(1)　リセット優先度の決定方法

複数の待機系がある場合，系切り替え構成全体に属するすべての系でリセット発行順序を一意に定めるため，リセット優先度を指定します。

HAモニタは，起動時に他系と接続した際，自系のリセット優先度を決定します。リセット優先度は，接続された系の中で，ホストアドレスの小さい系から順に優先度が高くなります。リセット優先度には0から31まであり，0がいちばん高い優先度と見なされます。

ホストアドレスとリセット優先度の関係を次の図に示します。この例では，系3に障害が発生した場合，ホストアドレスのいちばん小さい系1がリセットを発行します。

図4-12　ホストアドレスとリセット優先度の関係

系障害を検出した場合，リセット優先度が最も高い系がリセットを発行します。他系は，リセット優先度に従ってリセットの発行を一定時間待ちます。このリセット発行の待ち時間は，「各系のリセット優先度×10（秒）」で計算できます。

なお，計算式で示す10秒は，機種によって異なります。

(2)　リセット優先度を指定した場合の系のリセット

リセット優先度を指定した場合，系のリセット時に，各系がどう動作するかについて説明します。

系障害を検出した系は，自系のリセット優先度に従って，障害が発生した系にリセットを発行します。さらに接続しているすべての系にリセット発行を依頼します。リセット発行の依頼を受けた系は，自系のリセット優先度に従って，障害系のリセットを発行します。

リセットが成功した場合

リセットが成功した場合，リセットを発行した系は，すべての系に対してリセットの成功を通知します（リセット成功通知）。系切り替えをする待機サーバがあれば，系切り替えをします。

リセット成功通知を受信した系は，障害が発生した系に対してリセット発行待ちの状態であればリセット発行待ちを中断します。系切り替えをする待機サーバがあれば，系切り替えをします。

リセットが失敗した場合

リセットが失敗した場合，リセットを発行した系は他系からのリセット成功通知を待ちます。

(3)　ある待機系からの系のリセットが失敗した場合の動作

待機系からの系のリセットが失敗した場合，複数の待機系があるため，自動的に系切り替えができます。ここでは，ある待機系からの系のリセットが失敗した場合のリセットについて，例を用いて説明します。この例では，系2で障害が発生した場合で，系1からのリセットが失敗し，リセット発行待ち時間が過ぎたら系3がリセットを発行する流れを説明します。複数の待機系がある系切り替え構成で，系のリセットが失敗した場合の系のリセットを次の図に示します。

図4-13　複数の待機系がある系切り替え構成で，系のリセットが失敗した場合の系のリセット

次に，リセット優先度を指定した場合のリセットの発行の流れの詳細を説明します。番号は，上記の図と対応しています。

リセット指示とリセット依頼
いちばん高いリセット優先度を持つ系1は，系2の系障害を検出すると，系2にリセットを指示します。また，他系に対してリセットを依頼します。
系3は，系2の系障害を検出すると，系2のリセット発行を待ちます。

リセット失敗
系1からのリセット指示が失敗した場合，系1は他系からのリセット成功通知を待ちます。

リセット指示
系1からのリセット成功通知がなく，リセット優先度に応じたリセット待ち時間が過ぎると，系3は系2にリセットを指示します。

リセット成功通知と系切り替え
リセットが成功した場合，系3は，他系にリセット成功を通知し，系切り替えができる待機サーバがあれば，系切り替えをします。

4.2.4　系のリセットに失敗した場合の動作

系のリセットが失敗すると，実行系がリセットされていなくても，HAモニタは待機系の待機サーバを実行サーバとして起動させます。その際に，実行系と待機系とで同じ実行サーバが複数稼働するおそれがあります。実行サーバの複数起動を防ぐために待機系の待機サーバを異常終了させると，障害時に直ちに系切り替えができなくなります。このため，HAモニタは，待機系の待機サーバを実行サーバに切り替えたあと，実際に実行サーバとして起動する前に，いったん系切り替え待ち状態にします。

系のリセットに失敗した場合の動作を，次の図に示します。

図4-14　系のリセットに失敗した場合の動作

系切り替え待ち状態のサーバを実行サーバとして起動したり，停止したりする方法については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

参考

LPARモードの系や仮想マシンの系のリセットに失敗した場合，系切り替え待ち状態になることを防ぐ，物理パーティションリセット機能を使用できます。物理パーティションリセット機能については「3.2.8(2)　物理パーティションリセット機能使用時の動作」を参照してください。

4.3　共有リソースの管理

ここでは，サーバが使用するリソースをHAモニタがどう管理するかについて説明します。

ここで説明する共有リソース以外のリソースを，サーバで使用できます。その場合は，共有リソースを制御するためのユーザコマンドを作成しておく必要があります。ユーザコマンドの作成方法については，「6.16　ユーザコマンドの作成」を参照してください。

＜この節の構成＞

4.3.1　共有ディスクの管理

4.3.2　共有ディスクの管理（HA Boosterを使用する場合）

4.3.3　ファイルシステムの管理

4.3.4　LANの管理

4.3.5　共有リソースの状態一覧

4.3.1　共有ディスクの管理

サーバが共有ディスクを使用する場合，HAモニタはOSのコマンドを使用して，共有ディスクとの接続および切り替えを制御します。HAモニタは，ボリュームグループ単位で切り替えを制御します。

共有ディスクの制御方法とHAモニタが実行するコマンド形式を次の表に示します。

表4-5　共有ディスクの制御方法とHAモニタが実行するコマンドの形式

制御方法 | 実行するコマンドの形式
参照＋更新接続 | vgchange -a y ボリュームグループのパス名
切り離し | vgchange -a n ボリュームグループのパス名

参照＋更新接続時に，vgchangeコマンドにオプションを付けて実行するには，サーバ対応の環境設定のvg_on_optオペランドに指定します。

＜この項の構成＞

(1)　接続

(2)　切り替え

(3)　ログファイル

(1)　接続

共有ディスクとの接続は，カーネルがします。

HAモニタと共有ディスクとの接続時には，実行サーバが共有ディスクを使用しているときに待機サーバから共有ディスクにアクセスできないように，ボリュームグループ単位に，論理的に排他制御をします。

共有ディスクとの接続の流れを，次に示します。

図4-15　共有ディスクとの接続の流れ

(2)　切り替え

共有ディスクの切り替え時には，障害が発生した系のサーバからは共有ディスクにアクセスできないようにし，業務処理を引き継ぐ系のサーバからは共有ディスクにアクセスできるように排他制御をします。また，ボリュームグループの切り離し時には，OSのfuserコマンドによって，共有ディスクを使用しているすべてのプロセスを強制停止します。

共有ディスクの切り替えの流れは，サーバ障害時と系障害時とで異なります。サーバ障害時の共有ディスクの切り替えの流れを，次の図に示します。

図4-16　サーバ障害時の共有ディスクの切り替えの流れ

系障害時の共有ディスクの切り替えの流れを，次の図に示します。

図4-17　系障害時の共有ディスクの切り替えの流れ

(3)　ログファイル

ボリュームグループの接続時および切り離し時に，その実行結果が/opt/hitachi/HAmon/spool/の下に「ボリュームグループ名.vglog」というファイル名で，ボリュームグループごとに出力されます。エラーが発生した場合，このログファイルを参照し，エラー要因を調査してください。

ログ取得時にログファイルが65,535バイトを超える場合，HAモニタは，「ボリュームグループ名.vglog_old」というファイル名でバックアップファイルを作成しクリアしてから，再度ログを取得します。

4.3.2　共有ディスクの管理（HA Boosterを使用する場合）

HA Boosterを使用する場合，HA Boosterがアクセス制御をするため，共有ディスクの切り替えを高速にできます。このとき，HAモニタは，HA Boosterが管理する制御グループ単位で切り替えをします。HA Boosterを使用する場合は，共有ディスクのディスクデバイスを，HA Boosterの制御グループに登録する必要があります。

ここでは，HA Boosterを使用した場合の，共有ディスクの接続，および切り替えの処理について説明します。HA Boosterの詳細については，HA Booster関連のドキュメントを参照してください。

＜この項の構成＞

(1)　接続

(2)　切り替え

(3)　ログファイル

(4)　注意事項

(1)　接続

HA Boosterを使用した共有ディスクとの接続の流れを，次の図に示します。

図4-18　HA Boosterを使用した共有ディスクとの接続の流れ

(2)　切り替え

共有ディスクの切り替えの流れは，サーバ障害時と系障害時とで異なります。HA Boosterを使用したサーバ障害時の共有ディスクの切り替えの流れを，次の図に示します。

図4-19　HA Boosterを使用したサーバ障害時の共有ディスクの切り替えの流れ

HA Boosterを使用した系障害時の共有ディスクの切り替えの流れを，次の図に示します。

図4-20　HA Boosterを使用した系障害時の共有ディスクの切り替えの流れ

(3)　ログファイル

エラーメッセージはsyslogに出力されます。

(4)　注意事項

HA Boosterを使用する場合の注意事項を次に示します。

排他制御は，HA Boosterが管理する制御グループ単位で実施します。そのため，異なるサーバに同じ制御グループを指定しないでください。

サーバの共有リソース動的変更コマンド（mondeviceコマンド）による制御グループの追加・削除はサポートしていません。ディスクデバイスの追加・削除をする場合は，定義済みの制御グループに対してディスクデバイスの追加・削除をしてください。

4.3.3　ファイルシステムの管理

HAモニタは，共有ディスク上のファイルシステムをマウントおよびアンマウントによって切り替えます。ファイルシステムの切り替えの制御方法と，HAモニタの処理内容を，次の表に示します。

表4-6　ファイルシステムの切り替えの制御方法とHAモニタの処理内容

制御方法
HAモニタの処理内容

マウント
共有ディスクの接続後，次の処理によって接続します。

OSのfsckコマンドでファイルシステムをチェックしたあと，マウントします。

接続に失敗した場合は，エラーメッセージを出力し処理を続行します。

マウントは，サーバ対応の環境設定のfs_nameオペランドに指定された順番で実行されます。

アンマウント
共有ディスクの切り離し前に，次の処理によって切り離します。なお，実行サーバが停止した場合は，停止の原因に関係なく，必ずアンマウントします。

OSのfuserコマンドでファイルシステムにアクセスしているすべてのプロセスを強制停止したあと，アンマウントします。

アンマウントに失敗した場合は，サーバ対応の環境設定に指定したリトライ回数分，1秒おきにリトライします。リトライ回数の限界に達した場合，エラーメッセージを出力し，処理を続行します。

アンマウントは，サーバ対応の環境設定のfs_nameオペランドの指定と逆の順番で実行されます。

ファイルシステムのマウントは，サーバ対応の環境設定のfs_nameオペランドに指定した順で実行されます。また，アンマウントは逆順に実行されます。

＜この項の構成＞

(1)　接続

(2)　切り替え

(3)　ログファイル

(1)　接続

HAモニタは，実行サーバがファイルシステムを使用できるよう，実行サーバ起動時に，待機系からアンマウントしたあと，実行系からマウントします。アンマウントする際は，OSのfuserコマンドによって，ファイルシステムを使用しているすべてのプロセスを強制停止します。また，マウントする際は，OSのfsckコマンドによってファイルシステムの一貫性をチェックします。

ファイルシステムとの接続の流れを，次の図に示します。

図4-21　ファイルシステムとの接続の流れ

(2)　切り替え

HAモニタは，障害が発生した系からアンマウントし，業務処理を引き継ぐ系からはマウントすることで，ファイルシステムを切り替えます。アンマウントする際は，OSのfuserコマンドによって，ファイルシステムを使用しているすべてのプロセスを強制停止します。ファイルシステムの切り替えの流れは，サーバ障害時と系障害時とで異なります。

サーバ障害時のファイルシステムの切り替えの流れを，次の図に示します。

図4-22　サーバ障害時のファイルシステムの切り替えの流れ

系障害時のファイルシステムの切り替えの流れを，次の図に示します。

図4-23　系障害時のファイルシステムの切り替えの流れ

(3)　ログファイル

ファイルシステムの切り替え実施時，サーバごとに/opt/hitachi/HAmon/spool/サーバ識別名.fslogというファイルに実行結果を出力します。切り替えエラーが発生した場合などに，このログファイルを参照することによって，エラー要因を調査できます。

ログファイルの最大サイズはHAモニタの環境設定のfs_log_sizeオペランドで設定できます。ログ取得時にログファイルのサイズが最大を超えている場合，ファイルを「サーバ識別名.fslog_old」という名称でバックアップし，クリアしてからログを再取得します。

4.3.4　LANの管理

HAモニタは，サーバにエイリアスIPアドレスを割り当て，そのエイリアスIPアドレスをLANアダプタに追加したり削除したりすることで，LANの切り替えをします。

＜この項の構成＞

(1)　接続

(2)　切り替え

(1)　接続

HAモニタは，ネットワークインタフェースの状態を設定する際に，LANアダプタにエイリアスIPアドレスを追加します。LANとの接続の流れを，次に示します。

図4-24　LANとの接続の流れ

(2)　切り替え

HAモニタは，ネットワークインタフェースの状態設定の際に，エイリアスIPアドレスを削除します。

サーバ障害時の，LANの切り替えの流れを次の図に示します。

図4-25　サーバ障害時のLANの切り替えの流れ

系障害時の，LANの切り替えの流れを次の図に示します。

図4-26　系障害時のLANの切り替えの流れ

4.3.5　共有リソースの状態一覧

HAモニタやサーバに発生した事象と，事象発生時にHAモニタが共有リソースの状態をどう制御するかについて説明します。

HAモニタが制御する共有リソースの状態を次の表に示します。

表4-7　HAモニタが制御する共有リソースの状態

事象
共有リソース

共有ディスク
ファイルシステム
LAN

ボリュームグループ
制御グループ

サーバでの事象
実行サーバ起動開始
参照＋更新接続
参照＋更新接続
マウント
接続

実行サーバ起動完了
－
－
－
－

実行サーバ起動失敗
切り離し
－※1
アンマウント
切り離し

実行サーバ起動失敗（複数スタンバイ構成で系切り替えをする場合）
切り離し
切り離し
アンマウント
切り離し

実行サーバ再起動限界検出
切り離し
切り離し
アンマウント
切り離し

実行サーバ正常終了※2
切り離し
－※1
アンマウント
切り離し

実行サーバ異常終了
※3，※4
切り離し
切り離し※5
アンマウント
切り離し

待機サーバ起動開始
切り離し
切り離し
アンマウント
切り離し

待機サーバ起動完了
－
－
－
－

待機サーバ起動失敗
－
－
－
－

待機サーバ正常終了※2
－
－
－
－

待機サーバ異常終了
－
－
－
－

HAモニタでの事象
実行サーバ障害検出
※4，※6
切り離し
切り離し※5
アンマウント
切り離し

実行系障害検出
入出力リセット
入出力リセット
入出力リセット
入出力リセット

待機系障害検出
－
－
－
－

待機系に系切り替え完了
参照＋更新接続
参照＋更新接続
マウント
接続

待機系に系切り替え失敗
切り離し
－※1
アンマウント
切り離し

モニタモードのサーバ起動コマンド
（monbeginコマンド）※7
実行系
参照＋更新接続
参照＋更新接続
マウント
接続

待機系
切り離し
切り離し
アンマウント
切り離し

モニタモードのサーバ停止コマンド
（monendコマンド）
実行系
切り離し
切り離し
アンマウント
切り離し

待機系
－
－
－
－

待機サーバ停止コマンド
（monsbystpコマンド）
－
－
－
－

計画系切り替えコマンド
（monswapコマンド）
実行系
切り離し
切り離し
アンマウント
切り離し

待機系
参照＋更新接続
参照＋更新接続
マウント
接続

共有リソース追加コマンド
（mondevice -aコマンド）
実行系
参照＋更新接続
×
×
×

待機系
切り離し
×
×
×

共有リソース削除コマンド
（mondevice -dコマンド）
実行系
－
×
×
×

待機系
－
×
×
×

（凡例）

－：変化しません。

×：コマンドの処理対象ではありません。

注※1　サーバ対応の環境設定のhab_discnt_atendオペランドにyesを指定した場合，切り離しをします。

注※2　サーバの計画停止，強制停止を含みます。

注※3　サーバ自身が障害を検知した場合です。

注※4　実行サーバが再起動待ち状態になるときは変化しません。

注※5　系切り替えをする待機サーバがない場合は，サーバ対応の環境設定のhab_discnt_atendオペランドにyesを指定したときだけ切り離しをします。

注※6　系切り替えをする待機サーバがない場合は変化しません。

注※7　サーバ起動完了時や起動失敗時は，サーバでの事象と同じになります。

4.4　サーバをグループ化する場合のサーバの管理

複数のサーバをグループ化することで，サーバグループ内のサーバに障害が発生した場合に，サーバグループごと系切り替えをする連動系切り替えができます。ここでは，連動系切り替えをするときのHAモニタの動作について説明します。

＜この節の構成＞

4.4.1　連動系切り替え時のサーバの切り替え種別

4.4.2　グループ化したサーバの系切り替え制御

4.4.1　連動系切り替え時のサーバの切り替え種別

サーバモードのサーバの場合，サーバグループ内の各サーバに，そのサーバに障害が発生したときに連動系切り替えをするかどうかを指定できます。この指定をサーバの切り替え種別と呼びます。ここでは，サーバの切り替え種別の指定と，HAモニタの動作の関係について説明します。

サーバの切り替え種別として，そのサーバにサーバ障害が発生したときに連動系切り替えをすると指定した場合，そのサーバにサーバ障害が発生するとHAモニタは連動系切り替えをします。連動系切り替えをしない指定にした場合，HAモニタはサーバ障害が発生したサーバを異常終了させ，対応した待機サーバを連動系切り替え待ち状態にします。

また，TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）をサーバモードのサーバとして使用する場合で，サーバにサーバ障害が発生しても連動系切り替えをしない設定にするときは，サーバのスローダウンが発生したときサーバを異常終了させて連動系切り替え待ち状態にするか，またはスローダウンが発生してもサーバを異常終了させないでそのままサーバの監視を続けるかを指定できます。

サーバの切り替え種別は，サーバ対応の環境設定のgroupオペランドに指定します。サーバに障害が発生したときに連動系切り替えをする場合はexchangeを，連動系切り替えをしない場合はno_exchangeを指定します。また，連動系切り替えをしない場合で，サーバのスローダウンを検出したときにサーバを異常終了するにはcancelを，検出してもそのまま監視を続けるにはno_cancelを指定します。

サーバの切り替え種別の指定と連動系切り替えの関係を，次の図に示します。この図では，サーバグループAとサーバグループBの二つを例に挙げて説明します。

図4-27　サーバの切り替え種別の指定と連動系切り替えの関係

groupAのサーバグループでは，exchangeが指定されている実行サーバ1に障害が発生したため，HAモニタは連動系切り替えをします。実行サーバ1および実行サーバ2は，待機系で業務を継続します。

groupBのサーバグループでは，no_exchangeが指定されている実行サーバ4に障害が発生したため，HAモニタは系切り替えをしません。実行サーバ3はそのまま実行系で業務を継続します。

4.4.2　グループ化したサーバの系切り替え制御

サーバをグループ化している場合，サーバグループ内のサーバに指定されているサーバの切り替え種別の組み合わせによって，系切り替え制御が異なります。

なお，モニタモードのサーバには，サーバの切り替え種別を指定できません。サーバグループ内にモニタモードのサーバがある場合，モニタモードのサーバは，サーバの切り替え種別にexchangeを指定したサーバに該当します。また，モニタモードのサーバに発生したサーバ障害やスローダウンを契機に系切り替えをするには，サーバの監視コマンドの作成が必要です。

系切り替えの契機となる事象ごとに，サーバの切り替え種別の組み合わせとHAモニタの系切り替え制御の関係を次の表に示します。

表4-8　サーバの切り替え種別の組み合わせとHAモニタの系切り替え制御の関係

系切り替えの契機となる事象 | サーバの切り替え種別の組み合わせ
事象の分類 | 事象が発生したサーバ | exchangeだけ | exchangeとno_exchange | no_exchangeだけ
グループ内で稼働中のサーバ | グループ内で稼働中のサーバ
あり | なし | あり | なし
サーバ障害発生時 | exchange指定のサーバ | 連動系切り替え | 連動系切り替え | 単独で系切り替え※1 | － | －
no_exchange指定のサーバ | － | 連動系切り替え待ち※2 | 単独で系切り替え※1 | 連動系切り替え待ち※2，※3 | 単独で系切り替え※1
サーバスローダウン発生時 | exchange指定のサーバ | 連動系切り替え | 連動系切り替え | 単独で系切り替え※1 | － | －
no_exchange指定のサーバ | － | 以降の指定に従う※4 | 単独で系切り替え※1 | 以降の指定に従う※4 | 単独で系切り替え※1
系障害発生時 | exchange指定のサーバ | 連動系切り替え | 連動系切り替え | 単独で系切り替え※1 | － | －
no_exchange指定のサーバ | － | 連動系切り替え | 単独で系切り替え※1 | 連動系切り替え | 単独で系切り替え※1
計画系切り替え時 | exchange指定のサーバ | 連動系切り替え | 連動系切り替え | 単独で系切り替え※1 | － | －
no_exchange指定のサーバ | － | 連動系切り替え | 単独で系切り替え※1 | 連動系切り替え | 単独で系切り替え※1

（凡例）－：組み合わせとしてあり得ません。

注※1　待機系に，同じサーバグループに属する連動系切り替え待ち状態の待機サーバがあれば，同時に実行サーバとして起動させます。

注※2　待機サーバが，待機系で起動を完了した状態でサーバグループの連動系切り替えを待つ状態です。連動系切り替え待ち状態の詳細については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

注※3　すべてのサーバに障害が発生した場合には連動系切り替えします。

注※4　cancelを指定している場合は，サーバを異常終了させます。待機サーバは連動系切り替え待ち状態になります。no_cancelを指定している場合は，サーバの状態監視を続けます。待機サーバは連動系切り替え待ち状態にはなりません。

4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理

マルチスタンバイ機能とは，一つの実行サーバに対して，複数の待機サーバを準備するための機能です。複数の待機サーバを準備することで，現用系の障害が復旧するまでの間も，システムの障害に備えることができます。

マルチスタンバイ機能を使用する場合は，マルチスタンバイ機能を使用しない場合と比べて，サーバを起動・停止させる条件や系のリセットが異なります。ここでは，マルチスタンバイ機能を使用しない場合と比べて異なる点について説明します。

＜この節の構成＞

4.5.1　系障害の検出と系のリセット（マルチスタンバイ）

4.5.2　系のリセットに失敗した場合の動作（マルチスタンバイ）

4.5.3　サーバの起動制御・停止制御（マルチスタンバイ）

4.5.1　系障害の検出と系のリセット（マルチスタンバイ）

ここでは，系障害の検出および系のリセットについて，マルチスタンバイ機能を使用しない場合と比べて異なる点だけについて説明します。

マルチスタンバイ機能を使用する系切り替え構成では，複数の待機系で待機サーバが稼働するため，監視パスの障害時などには複数の待機系が同時に系切り替えをするおそれがあります。同時に系切り替えをするのを防ぐために，マルチスタンバイ機能を使用する場合，HAモニタは待機系間でも系の監視をします。

待機系の系障害を検出した場合，系障害を検出した系は，自系の待機サーバより高い優先度を持つ待機サーバが稼働している系をリセットします。マルチスタンバイ機能を使用する場合の，系の状態監視と系のリセットを次の図に示します。

図4-28　系の状態監視と系のリセット（マルチスタンバイ機能使用時）

上記の図では，障害が発生した待機サーバの優先度は1なので，優先度2の待機サーバを持つ待機系2が待機系1をリセットします。

待機系2からのリセットが失敗した場合や，リセットができなかった場合は，実際にリセットを発行する系が異なります。ある待機系からのリセットが失敗した場合の，リセット発行の流れについては，「4.2.3　複数の待機系がある場合の系のリセット」を参照してください。

4.5.2　系のリセットに失敗した場合の動作（マルチスタンバイ）

マルチスタンバイ機能を使用する系切り替え構成で，系リセットが失敗した場合の動作について説明します。

＜この項の構成＞

(1)　実行系のリセットが失敗した場合

(2)　待機系のリセットが失敗した場合

(1)　実行系のリセットが失敗した場合

実行系で障害が発生し，その実行系のリセットが失敗した場合，HAモニタは，複数の待機系の中でいちばん優先度が高い待機サーバだけを系切り替え待ち状態にします。

マルチスタンバイ機能を使用する系切り替え構成で，実行系のリセットが失敗した場合の流れを次の図に示します。

図4-29　実行系のリセットが失敗した場合の流れ（マルチスタンバイ機能使用時）

この場合は，オペレータの対処が必要です。系切り替え待ち状態のサーバを実行サーバとして起動する方法については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

(2)　待機系のリセットが失敗した場合

待機系のリセットが失敗した場合，複数の待機系がある構成ではHAモニタが優先度の判断ができなくなり，複数の実行サーバが稼働するおそれがあります。複数の実行サーバ稼働を防ぐため，HAモニタは，障害が発生した待機系で稼働する待機サーバより優先度の低い待機サーバを停止します。

マルチスタンバイ機能を使用する系切り替え構成で，待機系のリセットが失敗した場合の流れを次の図に示します。

図4-30　待機系のリセットが失敗した場合の流れ（マルチスタンバイ機能使用時）

この場合は，オペレータの対処が必要です。待機サーバを起動する方法については，「7.2.1　起動する」を参照してください。

4.5.3　サーバの起動制御・停止制御（マルチスタンバイ）

ここでは，マルチスタンバイ機能を使用する場合，どういうときにHAモニタがサーバを起動または停止させるかについて説明します。

マルチスタンバイ機能を使用しない場合と比べて異なる点だけについて説明します。

＜この項の構成＞

(1)　HAモニタによるサーバの起動制御

(2)　HAモニタによるサーバの停止制御

(1)　HAモニタによるサーバの起動制御

マルチスタンバイ機能を使用した場合は，複数の待機系がある点が異なります。そのため，実行サーバと待機サーバの決定方法，およびサーバの再起動時の起動種別の決定方法が異なります。

(a)　実行サーバと待機サーバの決定方法

マルチスタンバイ機能を使用した場合，他系の実行サーバの状態だけでなく，実行サーバの状態と待機サーバの状態との組み合わせに従って，起動種別を決定します。マルチスタンバイ機能を使用した場合の，実行サーバと待機サーバの決定方法を次の表に示します。

表4-9　実行サーバと待機サーバの決定方法（マルチスタンバイ機能使用時）

他系の状態 | サーバ対応の環境設定
実行サーバとして定義 | 待機サーバとして定義
実行サーバあり | 起動処理中 | 待機サーバとして起動 | 待機サーバとして起動
実行処理中 | 待機サーバとして起動 | 待機サーバとして起動
停止処理中 | 起動不可※1 | 起動不可※1
系切り替え処理中 | 実行サーバの起動待ち※2 | 実行サーバの起動待ち※2
実行サーバなし | 実行サーバとして起動 | 実行サーバの起動待ち※2
サーバなし（またはHAモニタ停止中） | 実行サーバとして起動 | 実行サーバの起動待ち※2
サーバの状態確認不可 | リトライ処理※3 | 実行サーバの起動待ち※2

注※1　サーバの起動を中止します。

注※2　他系の実行サーバの起動が確認できるまで待機サーバの起動を待たせます。実行サーバの起動開始を確認できたら，待機サーバとして起動させます（実行サーバの起動待ち状態）。

注※3　他系や監視パスの障害によって，他系で起動しているサーバの状態を確認できない場合は，1分間だけリトライします。リトライしてもさらに確認できない場合は，他系の障害でサーバがないものと判断し，実行サーバの起動待ち状態にします。

実行サーバの起動待ち状態になった場合のオペレータの操作については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

(b)　サーバの再起動時の起動種別

障害が発生したあとにサーバを再起動した場合，他系ではすでに実行サーバが稼働している可能性があります。そのため，サーバ対応の環境設定で指定した起動種別は，無視されます。例えば，自系で再起動させたサーバは，実行サーバとして定義しても他系で実行サーバの状態が確認できるまでは自動的に待機サーバになります。

マルチスタンバイ機能を使用する場合で，実行サーバとして定義したサーバを再起動するときの起動種別の決定方法を次の表に示します。

表4-10　サーバの再起動時の起動種別の決定方法（マルチスタンバイ機能使用時）

他系の状態 | サーバの起動種別
実行サーバあり | 起動処理中 | 待機サーバとして起動
実行処理中 | 待機サーバとして起動
停止処理中 | 起動不可※1
待機サーバから実行サーバへ系切り替え処理中 | 待機サーバとして起動
サーバなし（またはHAモニタ停止中） | 実行サーバの起動待ち※2
サーバの状態確認不可 | 実行サーバの起動待ち※2

注※1　サーバの起動を中止します。

注※2　他系の実行サーバの起動が確認できるまで待機サーバの起動を待たせます（実行サーバの起動待ち状態）。実行サーバの起動開始を確認できたら，待機サーバとして起動させます。

実行サーバの起動待ち状態になった場合のオペレータの操作については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

(2)　HAモニタによるサーバの停止制御

マルチスタンバイ機能を使用した場合は，複数の待機系があるため，実行サーバが停止すると，HAモニタは対応する待機サーバをすべて停止させます。

オペレータが待機サーバ停止コマンド（monsbystpコマンド）を使用して，待機サーバを停止させると，HAモニタはコマンドが実行された系の待機サーバだけを停止させます。

4.6　リソースサーバの管理

リソースサーバとは，共有リソースを制御するためのサーバです。リソースサーバを使用しない場合は，サーバごとに一つの共有リソースを使用しますが，リソースサーバを使用すると，複数のサーバで一つの共有リソースを使用できます。使用できる共有リソースの数が限られている場合に，リソースサーバを使用すると便利です。

ここでは，HAモニタがリソースサーバをどのように制御しているか，について説明します。リソースサーバを使用した場合の系切り替え，共有リソースとの接続・切り離しの流れ，およびリソースサーバの状態の決定方法について説明します。

＜この節の構成＞

4.6.1　リソースサーバを使用した系切り替え

4.6.2　リソースサーバを使用した共有リソースとの接続・切り離しの流れ

4.6.3　リソースサーバの状態の決定方法

4.6.1　リソースサーバを使用した系切り替え

リソースサーバは，複数のサーバが一つの共有リソースを共用するために使用します。そのため，リソースサーバは，常にサーバとグループ化して使用します。リソースサーバを使用した場合，リソースサーバは，サーバグループ内でほかのサーバと連動して，系切り替えをします。

リソースサーバを使用した場合の系切り替えを次の図に示します。

図4-31　リソースサーバを使用した場合の系切り替え

リソースサーバは，サーバグループ内でリソースサーバを使用するほかのサーバの障害などを契機に，連動して切り替えをします。

4.6.2　リソースサーバを使用した共有リソースとの接続・切り離しの流れ

リソースサーバを使用する場合，共有リソースとの接続は，リソースサーバの起動と同時に行います。また，共有リソースとの切り離しは，リソースサーバの停止と同時に行います。そのため，HAモニタは，サーバが共有リソースを使用できるように，グループ内に定義されたサーバおよびリソースサーバの起動順序を制御します。

ここでは，リソースサーバを使用する場合の，サーバとリソースサーバの起動順序，共有リソースとの接続および切り離しの流れ，およびサーバとリソースサーバの停止順序について説明します。

なお，リソースサーバを起動するときの実行サーバと待機サーバの決定方法は，ほかのサーバを起動するときと同様です。実行サーバと待機サーバの決定方法については，「4.1.1　HAモニタによるサーバの起動制御」を参照してください。

＜この項の構成＞

(1)　サーバとリソースサーバの起動順序

(2)　共有リソースとの接続・切り離しの流れ

(3)　サーバとリソースサーバの停止順序

(1)　サーバとリソースサーバの起動順序

HAモニタは，サーバとリソースサーバにグループ内で親子関係を持たせ，親から順番に起動します。サーバグループの例として，サーバ1，サーバ2，およびリソースサーバを含むサーバグループの，親子関係と起動順序を次の図に示します。

図4-32　リソースサーバを含むサーバグループの親子関係と起動順序

リソースサーバを使用するには，ユーザが環境設定で，リソースサーバをサーバ1およびサーバ2の親サーバとして指定します。リソースサーバは必ず最上位の親サーバとして指定します。HAモニタは，指定された親子関係に基づいて，最上位の親サーバから順に起動するように制御します。

(2)　共有リソースとの接続・切り離しの流れ

リソースサーバを使用した場合の，サーバが起動してから障害発生時に系切り替えをするまでの共有リソースとの接続・切り離しの流れについて説明します。ここで説明するサーバグループの親子関係については，「4.6.2(1)　サーバとリソースサーバの起動順序」を参照してください。HAモニタおよびサーバの処理の詳細については，「4.8　処理の流れ」を参照してください。

リソースサーバ使用時の，共有リソースとの接続および切り離しの流れを，次の図に示します。

図4-33　共有リソースとの接続および切り離しの流れ（リソースサーバ使用時）

図で示した接続の流れについて，詳細を説明します。番号は，図中の番号と対応しています。

オペレータがサーバ1またはサーバ2を起動すると，リソースサーバを起動します。リソースサーバの起動と同時に共有リソースとの接続をします。HAモニタは，リソースサーバの起動が完了するまでは，実行系のサーバ1，およびサーバ2を「リソースサーバの起動待ち状態」にして，起動を待たせます。

実行系で共有リソースとの接続が完了したあと，HAモニタは，サーバ1，およびサーバ2の起動を完了させます。
また，待機系で，オペレータがサーバ1，またはサーバ2を起動すると，HAモニタは，リソースサーバを起動します。

サーバ障害が発生すると，HAモニタは連動系切り替えをします。サーバ1にサーバ障害が発生したため，HAモニタは，リソースサーバの停止前にサーバ1およびサーバ2を停止します。

実行系のサーバ1およびサーバ2の停止が完了すると，HAモニタはリソースサーバを停止します。リソースサーバの停止と同時に共有リソースの切り離しをします。
実行系で，共有リソースの切り離しが完了すると，待機系のリソースサーバが系切り替えを開始します。系切り替えの開始と同時に，共有リソースと接続します。このとき，待機系のサーバ1およびサーバ2は，リソースサーバの系切り替え完了を待つため，「系切り替え完了待ち状態」になります。
なお，サーバ・系の状態表示コマンド（monshowコマンド）を使用すると，サーバ1およびサーバ2の状態は「(ONL)」と表示されます。「(ONL)」は実行サーバの起動中という意味ですが，実際，サーバはリソースサーバの系切り替え完了待ち状態であり，コマンドの表示と実際のサーバの状態が異なります。

共有リソースとの接続が完了したあと，HAモニタは，待機系のサーバ1，およびサーバ2は実行サーバとして起動させます。このとき，オペレータが実行系のサーバ1またはサーバ2を再起動すると，リソースサーバ，サーバ1およびサーバ2が待機サーバとして起動されます。

(3)　サーバとリソースサーバの停止順序

リソースサーバは，リソースサーバを親サーバに指定したサーバがすべて停止すると，自動停止されます。リソースサーバを親サーバに指定していない同一グループ内のサーバが停止しても，リソースサーバは自動停止されません。また，実行中のリソースサーバが停止した場合，対応する待機中のリソースサーバも自動停止されます。

4.6.3　リソースサーバの状態の決定方法

ここでは，HAモニタがリソースサーバの状態をどう決定するかについて説明します。

リソースサーバは，共有リソースを制御するためだけのサーバです。リソースサーバは，常にサーバとグループ化して使用します。そのため，HAモニタは，同じグループ内のサーバと同様の方法で，リソースサーバの状態を決定します。

リソースサーバの状態には，実行中または待機中があります。同じグループ内に実行サーバとして稼働しているサーバがある場合は実行中のリソースサーバ，待機サーバとして稼働しているサーバがある場合は待機中のリソースサーバになります。

サーバの状態の決定方法については，「4.1.1　HAモニタによるサーバの起動制御」を参照してください。

4.7　プログラムの管理（モニタモード）

ここでは，サーバの運用方法がモニタモードで，かつモニタモードのプログラム管理機能を使用する場合の，プログラムの管理について説明します。

モニタモードのプログラム管理機能の概要や必要な環境設定については，「3.4　プログラムの制御のための機能（モニタモード）」を参照してください。

なお，モニタモードのプログラム管理機能を使用するためには，モニタモードのプログラム対応の環境設定，およびAPIの発行が必要です。

＜この節の構成＞

4.7.1　UAPの監視制御

4.7.2　プログラムの再起動制御

4.7.3　プログラムの状態遷移

4.7.4　UAP監視時の処理の流れ

4.7.1　UAPの監視制御

HAモニタのAPIを発行できるようにUAPを修正することで，サーバの監視コマンドにUAPの監視処理を作り込むことなく，HAモニタでUAPを監視できます。

発行するAPIは，UAPの監視開始（hamon_patrolstart関数）とUAPの監視停止（hamon_patrolstop関数）の2種類です。APIについては，「10.　API」を参照してください。

HAモニタは，UAPのプロセスおよび稼働報告を監視することで，UAPを監視します。UAPのプロセスと稼働報告の両方を監視するか，UAPのプロセスだけを監視するかを選択できます。監視方法は，モニタモードのプログラム対応の環境設定のpatrolオペランド，およびhamon_patrolstart関数で指定します。検出したい障害に応じて，監視方法を選択してください。

検出できる障害と監視方法の対応を，次の表に示します。

表4-11　検出できる障害と監視方法の対応

検出できる障害 | プロセスの監視 | 稼働報告の監視
UAPの異常終了 | ○ | ○
UAPのスローダウン | システムコールのハングアップ | × | ○
ページイン待ち | × | ○
スケジューリング待ち | × | ○

（凡例）

○：検出できます。

×：検出できません。

UAPのプロセスと稼働報告の監視時の動作について，以降で説明します。

＜この項の構成＞

(1)　UAPのプロセスの監視

(2)　UAPの稼働報告の監視

(3)　UAP障害を検出したあとのHAモニタの動作

(4)　複数プロセス構成のUAPの監視

(1)　UAPのプロセスの監視

HAモニタは，hamon_patrolstart関数の受け付け時にUAPと接続し，その接続を監視することでUAPのプロセスの存在をチェックできます。接続が切れた場合に，HAモニタはプロセスの消滅を検知し，UAP障害が発生したと判断します。HAモニタがUAPとの接続を監視する間隔は1秒です。

UAP障害を検出すると，HAモニタはプログラムの再起動コマンドを作成している場合はUAPの再起動を，作成していない場合はサーバの再起動や系切り替えなどをします。UAP障害を検出したあとのHAモニタの動作については，「(3)　UAP障害を検出したあとのHAモニタの動作」を参照してください。

UAPのプロセスの監視時の動作について，次の図に示します。

図4-34　UAPのプロセスの監視時の動作

UAPのプロセスの監視は，HAモニタがUAPから発行されたhamon_patrolstart関数を受け付けてから開始します。UAPから監視要求がない（hamon_patrolstart関数の発行がない）場合，HAモニタはUAP障害を検出しません。サーバ対応の環境設定のstart_timeoutオペランドを指定している場合は，モニタモードのサーバ起動時のタイムアウトとなります。

(2)　UAPの稼働報告の監視

HAモニタは，UAPが発行したAPIが一定間隔でHAモニタに送信する稼働報告を監視することで，次の要因によるUAPのスローダウンなど，UAP自身が検知できない障害を検出できます。

システムコールのハングアップ

ページイン待ち

スケジューリング待ち

UAPの稼働報告を監視する時間（プログラムのスローダウン監視時間）は，モニタモードのプログラム対応の環境設定の，patrolオペランドで指定します。指定したプログラムのスローダウン監視時間を超えてもUAPからの稼働報告がなかった場合，HAモニタはUAP障害が発生したと判断します。

UAP障害を検出すると，HAモニタはhamon_patrolstart関数を発行したプロセスを強制的に停止します。HAモニタはプログラムの再起動コマンドを作成している場合はUAPの再起動を，作成していない場合はサーバの再起動や系切り替えなどをします。UAP障害を検出したあとのHAモニタの動作については，「(3)　UAP障害を検出したあとのHAモニタの動作」を参照してください。

なお，UAPがプロセスを生成する場合は，プログラムの再起動コマンドやサーバの停止コマンドに，生成したプロセスを停止するため処理を記述する必要があります。

UAPの稼働報告の監視時の動作について，次の図に示します。

図4-35　UAPの稼働報告の監視時の動作

UAPの稼働報告の監視は，HAモニタがUAPから発行されたhamon_patrolstart関数を受け付けてから開始します。UAPから監視要求がない（hamon_patrolstart関数の発行がない）場合，HAモニタはUAP障害を検出しません。サーバ対応の環境設定のstart_timeoutオペランドを指定している場合は，モニタモードのサーバ起動時のタイムアウトとなります。

(3)　UAP障害を検出したあとのHAモニタの動作

UAP障害を検出したあとのHAモニタの動作は，プログラムやサーバに設定した定義，およびサーバの状態によって異なります。

UAP障害を検出したあとのHAモニタの動作を，次の図に示します。

図4-36　UAP障害を検出したあとのHAモニタの動作

(4)　複数プロセス構成のUAPの監視

一つのUAPが複数のプロセスで構成されている場合，複数のプロセスをまとめて一つのUAP（モニタモードのプログラム対応の環境設定に定義されている一つのUAP）として監視することもできます。HAモニタは，hamon_patrolstart関数を発行した，それぞれのプロセスを監視します。監視している複数のプロセスのうち，一つ以上のプロセスで障害が発生すると，UAPが障害になったものと判断します。

なお，hamon_patrolstart関数を発行する複数のプロセスのHAMON_UAPNAME環境変数の値は，同一のプログラム名である必要があります。

複数プロセス構成のUAPで，UAPの稼働報告を監視する場合の例を，次の図に示します。

図4-37　複数プロセス構成のUAPで，UAPの稼働報告を監視する場合の例

4.7.2　プログラムの再起動制御

モニタモードのプログラム管理機能を使用する場合，プログラムの障害検出後にプログラムの再起動コマンドを実行することで，プログラム単位で再起動ができます。プログラムの再起動コマンドはユーザが作成します。作成したプログラムの再起動コマンドは，モニタモードのプログラム対応の環境設定のrestartcommandオペランドに指定します。

プログラムの再起動コマンドの作成方法については，「6.12　プログラムの再起動コマンドの作成（プログラム管理機能使用時）」を参照してください。

＜この項の構成＞

(1)　再起動する単位

(2)　プログラムの再起動時の処理の流れ

(3)　再起動失敗時の対処

(1)　再起動する単位

プログラムを再起動する単位は，サーバ単位かプログラム単位かを選択できます。例えば，UAP障害が発生したときに，障害が発生したUAPだけを再起動するか，障害が発生したUAPを含むサーバを再起動するかを選択できます。

再起動する単位は，モニタモードのプログラム対応の環境設定のrestartcommandオペランドで指定します。このオペランドを指定するとプログラム単位で再起動し，省略するとサーバ単位で再起動します。

(2)　プログラムの再起動時の処理の流れ

ここでは，プログラム単位で再起動する場合の処理の流れについて説明します。

プログラムに障害が発生すると，HAモニタはプログラムの再起動限界に指定された回数だけプログラムの再起動を試みます。プログラムの再起動限界とは，プログラムを再起動させる上限のことです。プログラムの再起動限界は，モニタモードのプログラム対応の環境設定のexec_retryオペランドに指定します。また，プログラム再起動時のタイムアウト時間も指定できます。プログラムの再起動コマンドがタイムアウトすると，プログラムの再起動コマンドは再実行されます。プログラム再起動時のタイムアウト時間は，モニタモードのプログラム対応の環境設定のrestart_timeoutオペランドに指定します。

プログラムの障害発生時に，HAモニタはプログラムの再起動限界まで，次の処理を繰り返します。

すでにプログラムの再起動コマンドが実行中の場合は，プログラムの再起動コマンドを強制停止する。

複数のプロセスで構成されているUAPを監視している場合は，APIを発行したすべてのプロセスを強制停止する。

プログラムの再起動コマンドを実行する。

(3)　再起動失敗時の対処

HAモニタが再起動限界を検出し，プログラムが停止した場合，系切り替えできる状態であれば系切り替えをし，系切り替えができない状態であればユーザが手動でプログラムを再起動します。

4.7.3　プログラムの状態遷移

サーバ・系の状態表示コマンド（monshowコマンド）で-uオプションを指定すると，モニタモードのプログラム管理機能を使用しているプログラムの状態を確認できます。サーバ・系の状態表示コマンド（monshowコマンド），およびプログラムの状態については，「9.　コマンド」の「monshow（サーバと系の状態表示）」を参照してください。

モニタモードのプログラム管理機能を使用しているプログラムの状態遷移を，次の図に示します。この状態遷移図で示すプログラムは，実行サーバのプログラムです。待機サーバのプログラムは停止中です。

図4-38　プログラムの状態遷移

注※　サーバの起動コマンドの戻り値が0以外の場合を示します。

4.7.4　UAP監視時の処理の流れ

UAPを監視する場合，サーバの起動・停止時，およびサーバ障害時の処理の流れが通常と異なります。ここでは，UAPからAPIを発行する場合で，「4.8　処理の流れ」で説明する処理の流れと異なる部分についてだけ説明します。また，UAP障害が発生した場合の処理の流れについても説明します。

＜この項の構成＞

(1)　サーバの起動処理の流れ（UAP監視時）

(2)　サーバの停止処理の流れ（UAP監視時）

(3)　サーバ障害時の系切り替え処理の流れ（UAP監視時）

(4)　UAP障害時の系切り替え処理の流れ（UAP監視時）

(1)　サーバの起動処理の流れ（UAP監視時）

UAPを監視する場合，「4.8.1(2)　サーバの起動処理の流れ（モニタモード）」と，実行サーバの起動から実行サーバの起動完了までの流れに差異があります。UAPを監視する場合のサーバの起動処理の流れについて，次の図に示します。

図4-39　サーバの起動処理の流れ（モニタモード：UAP監視）

(2)　サーバの停止処理の流れ（UAP監視時）

UAPを監視する場合，「4.8.2(2)　サーバの停止処理の流れ（モニタモード）」と，実行サーバ停止から実行サーバの正常終了処理完了までの流れに差異があります。UAPを監視する場合のサーバの停止処理の流れについて，次の図に示します。

図4-40　サーバの停止処理の流れ（モニタモード：UAP監視）

(3)　サーバ障害時の系切り替え処理の流れ（UAP監視時）

UAPを監視する場合，「4.8.3(2)　サーバ障害時の系切り替え処理の流れ（モニタモード）」と，サーバ障害の発生から実行サーバの系切り替え完了までの流れに差異があります。UAPを監視する場合のサーバ障害時の系切り替え処理の流れについて，次の図に示します。

図4-41　サーバ障害時の系切り替え処理の流れ（モニタモード：UAP監視）

(4)　UAP障害時の系切り替え処理の流れ（UAP監視時）

UAP障害発生時の系切り替え処理の流れについて，次の図に示します。この図では，UAP2で障害が発生したため現用系のサーバを停止し，予備系のサーバに系切り替えをする場合を説明しています。

図4-42　UAP障害時の処理の流れ（モニタモード：UAP監視）

4.8　処理の流れ

「4.3　共有リソースの管理」では，ある特定の共有リソースの接続および切り替えだけについて説明しました。ここでは，HAモニタがする処理の流れについて，すべての共有リソースを含めて説明します。

この節で説明する処理の流れでは，HAモニタが出力するメッセージID，および発行するイベントIDを記載しているため，どのタイミングでメッセージIDやイベントが発行されるかを調べるときにお読みください。また，ユーザコマンドを実行するタイミング，およびユーザコマンドに渡される引数も記載しています。ユーザコマンド作成時の参考にしてください。

系切り替え構成での運用の流れと，処理の流れで説明する内容との対応を次の図に示します。

図4-43　系切り替え構成での運用の流れと，処理の流れで説明する内容との対応

＜この節の構成＞

4.8.1　サーバの起動処理の流れ

4.8.2　サーバの停止処理の流れ

4.8.3　サーバ障害時の系切り替え処理の流れ

4.8.4　系障害時の系切り替え処理の流れ

4.8.5　サーバ障害時の系切り替え失敗処理の流れ

4.8.6　系障害時の系切り替え失敗処理の流れ

4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ

4.8.1　サーバの起動処理の流れ

サーバの起動時に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

＜この項の構成＞

(1)　サーバの起動処理の流れ（サーバモード）

(2)　サーバの起動処理の流れ（モニタモード）

(1)　サーバの起動処理の流れ（サーバモード）

サーバモードの場合に，サーバ起動時にHAモニタがする処理の流れを次の図に示します。

図4-44　サーバの起動処理の流れ（サーバモード）

(2)　サーバの起動処理の流れ（モニタモード）

モニタモードの場合に，サーバ起動時にHAモニタがする処理の流れを次の図に示します。

図4-45　サーバの起動処理の流れ（モニタモード）

参考

UAPでAPIを発行する（モニタモードのプログラム管理機能使用時）場合は，実行サーバの起動から実行サーバの起動完了までの流れに差異があります。詳細については，「4.7.4(1)　サーバの起動処理の流れ（UAP監視時）」を参照してください。

4.8.2　サーバの停止処理の流れ

サーバの停止時に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

なお，ここでは，共有リソースの切り離し順が接続時と同じ場合の処理の流れを示します。共有リソースの切り離しを接続時と逆順にする場合にHAモニタがする処理の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

参考

ユーザコマンドで共有リソースにアクセスしたい場合は，共有リソースの切り離しを接続時と逆順にします。指定方法については，「3.3.5　共有リソースの切り離し順序指定」を参照してください。

＜この項の構成＞

(1)　サーバの停止処理の流れ（サーバモード）

(2)　サーバの停止処理の流れ（モニタモード）

(1)　サーバの停止処理の流れ（サーバモード）

サーバモードの場合，サーバの停止処理には次の2種類があります。

実行サーバの停止処理終了時に待機サーバを停止する

実行サーバの停止処理開始時に待機サーバを停止する

サーバモードの場合に，サーバ停止時にHAモニタがする処理の流れを説明します。

(a)　実行サーバの停止処理終了時に待機サーバを停止する場合

実行サーバの停止処理終了時に待機サーバを停止する場合に，HAモニタがする処理の流れを次の図に示します。

図4-46　サーバの停止処理の流れ（サーバモード：実行サーバの停止処理終了時に待機サーバを停止する）

(b)　実行サーバの停止処理開始時に待機サーバを停止する場合

実行サーバの停止処理開始時に待機サーバを停止する場合に，HAモニタがする処理の流れを次の図に示します。

図4-47　サーバの停止処理の流れ（サーバモード：実行サーバの停止処理開始時に待機サーバを停止する）

(2)　サーバの停止処理の流れ（モニタモード）

モニタモードの場合に，サーバ停止時にHAモニタがする処理の流れを次の図に示します。

図4-48　サーバの停止処理の流れ（モニタモード）

参考

UAPでAPIを発行する（モニタモードのプログラム管理機能使用時）場合は，実行サーバ停止から実行サーバの正常終了処理完了までの流れに差異があります。詳細については，「4.7.4(2)　サーバの停止処理の流れ（UAP監視時）」を参照してください。

4.8.3　サーバ障害時の系切り替え処理の流れ

サーバの障害が発生した場合に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

なお，ここでは，共有リソースの切り離し順が接続時と同じ場合の処理の流れを示します。共有リソースの切り離しを接続時と逆順にする場合にHAモニタがする処理の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

参考

ユーザコマンドで共有リソースにアクセスしたい場合は，共有リソースの切り離しを接続時と逆順にします。指定方法については，「3.3.5　共有リソースの切り離し順序指定」を参照してください。

＜この項の構成＞

(1)　サーバ障害時の系切り替え処理の流れ（サーバモード）

(2)　サーバ障害時の系切り替え処理の流れ（モニタモード）

(1)　サーバ障害時の系切り替え処理の流れ（サーバモード）

サーバモードの場合に，サーバ障害時にHAモニタがする系切り替え処理の流れを次の図に示します。

図4-49　サーバ障害時の系切り替え処理の流れ（サーバモード）

(2)　サーバ障害時の系切り替え処理の流れ（モニタモード）

モニタモードの場合に，サーバ障害時にHAモニタがする系切り替え処理の流れを次の図に示します。

図4-50　サーバ障害時の系切り替え処理の流れ（モニタモード）

参考

UAPでAPIを発行する（モニタモードのプログラム管理機能使用時）場合は，サーバ障害の発生から実行サーバの系切り替え完了までの流れに差異があります。詳細については，「4.7.4(3)　サーバ障害時の系切り替え処理の流れ（UAP監視時）」を参照してください。

4.8.4　系障害時の系切り替え処理の流れ

系障害が発生した場合に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

＜この項の構成＞

(1)　系障害時の系切り替え処理の流れ（サーバモード）

(2)　系障害時の系切り替え処理の流れ（モニタモード）

(1)　系障害時の系切り替え処理の流れ（サーバモード）

サーバモードの場合に，系障害時にHAモニタがする系切り替え処理の流れを次の図に示します。

図4-51　系障害時の系切り替えの流れ（サーバモード）

(2)　系障害時の系切り替え処理の流れ（モニタモード）

モニタモードの場合に，系障害時にHAモニタがする系切り替え処理の流れを次の図に示します。

図4-52　系障害時の系切り替えの流れ（モニタモード）

4.8.5　サーバ障害時の系切り替え失敗処理の流れ

サーバに障害が発生し待機系に系切り替えしようとして失敗した場合に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

なお，ここでは，共有リソースの切り離し順が接続時と同じ場合の処理の流れを示します。共有リソースの切り離しを接続時と逆順にする場合にHAモニタがする処理の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

＜この項の構成＞

(1)　サーバ障害時の系切り替え失敗処理の流れ（サーバモード）

(2)　サーバ障害時の系切り替え失敗処理の流れ（モニタモード）

(1)　サーバ障害時の系切り替え失敗処理の流れ（サーバモード）

サーバモードの場合で，系切り替えに失敗したときにHAモニタがする処理の流れを次の図に示します。

図4-53　サーバ障害時の系切り替え失敗処理の流れ（サーバモード）

(2)　サーバ障害時の系切り替え失敗処理の流れ（モニタモード）

モニタモードの場合で，系切り替えに失敗したときにHAモニタがする処理の流れを次の図に示します。

図4-54　サーバ障害時の系切り替え失敗処理の流れ（モニタモード）

4.8.6　系障害時の系切り替え失敗処理の流れ

系障害が発生し待機系に系切り替えしようとして失敗した場合に，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

なお，ここでは，共有リソースの切り離し順が接続時と同じ場合の処理の流れを示します。共有リソースの切り離しを接続時と逆順にする場合にHAモニタがする処理の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

＜この項の構成＞

(1)　系障害時の系切り替え失敗処理の流れ（サーバモード）

(2)　系障害時の系切り替え失敗処理の流れ（モニタモード）

(1)　系障害時の系切り替え失敗処理の流れ（サーバモード）

サーバモードの場合で，系切り替えに失敗したときにHAモニタがする処理の流れを次の図に示します。

図4-55　系障害時の系切り替え失敗処理の流れ（サーバモード）

(2)　系障害時の系切り替え失敗処理の流れ（モニタモード）

モニタモードの場合で，系切り替えに失敗したときにHAモニタがする処理の流れを次の図に示します。

図4-56　系障害時の系切り替え失敗処理の流れ（モニタモード）

4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ

実行サーバの停止時には，HAモニタが共有リソースの切り離しをします。共有リソースの切り離しをする順番を，接続時と逆順にすることもできます。逆順で切り離しをすることで，共有ディスクやLANの切り離しをする前に，ユーザコマンドを実行でき，ユーザ独自の停止処理の中に共有ディスクやLANに依存した処理を実装できます。

＜この項の構成＞

(1)　サーバの停止処理

(2)　サーバ障害時の系切り替え処理

(3)　サーバ障害時の系切り替え失敗処理

(4)　系障害時の系切り替え失敗処理

(1)　サーバの停止処理

共有リソースの切り離しを接続時と逆順にする場合の，HAモニタがするサーバの停止処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

(a)　サーバの停止（サーバモード）

サーバモードの場合，サーバの停止処理には次の2種類があります。

実行サーバの停止処理終了時に待機サーバを停止する

実行サーバの停止処理開始時に待機サーバを停止する

共有リソースの切り離しを接続時と逆順にする場合の，サーバモードのサーバを停止するときにHAモニタがする処理の流れを説明します。

実行サーバの停止処理終了時に待機サーバを停止する場合
共有リソースの切り離しが接続時と逆順で，実行サーバの停止処理終了時に待機サーバを停止する場合にHAモニタがする処理の流れを次の図に示します。

図4-57　共有リソースの切り離しを接続時と逆順にする場合の，サーバの停止処理の流れ（サーバモード：実行サーバの停止処理終了時に待機サーバを停止する）

実行サーバの停止処理開始時に待機サーバを停止する場合
共有リソースの切り離しが接続時と逆順で，実行サーバの停止処理開始時に待機サーバを停止する場合にHAモニタがする処理の流れを次の図に示します。

図4-58　共有リソースの切り離しを接続時と逆順にする場合の，サーバの停止処理の流れ（サーバモード：実行サーバの停止処理開始時に待機サーバを停止する）

(b)　サーバの停止（モニタモード）

共有リソースの切り離しが接続時と逆順の場合の，モニタモードのサーバを停止するときにHAモニタがする処理の流れを次の図に示します。

図4-59　共有リソースの切り離しを接続時と逆順にする場合の，サーバの停止処理の流れ（モニタモード）

(2)　サーバ障害時の系切り替え処理

共有リソースの切り離しを接続時と逆順にする場合の，サーバ障害時にHAモニタがする系切り替え処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

(a)　サーバ障害時の系切り替え（サーバモード）

共有リソースの切り離しを接続時と逆順にする場合の，サーバモードのサーバに障害が発生したときにHAモニタがする系切り替え処理の流れを次の図に示します。

図4-60　共有リソースの切り離しを接続時と逆順にする場合の，サーバ障害時の系切り替え処理の流れ（サーバモード）

(b)　サーバ障害時の系切り替え（モニタモード）

共有リソースの切り離しを接続時と逆順にする場合の，モニタモードのサーバに障害が発生したときにHAモニタがする系切り替え処理の流れを次の図に示します。

図4-61　共有リソースの切り離しを接続時と逆順にする場合の，サーバ障害時の系切り替え処理の流れ（モニタモード）

(3)　サーバ障害時の系切り替え失敗処理

共有リソースの切り離しを接続時と逆順にする場合で，サーバに障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

(a)　サーバ障害時の系切り替え失敗（サーバモード）

共有リソースの切り離しを接続時と逆順にする場合で，サーバモードのサーバに障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする処理の流れを次の図に示します。

図4-62　共有リソースの切り離しを接続時と逆順にする場合の，サーバ障害時の系切り替え失敗処理の流れ（サーバモード）

(b)　サーバ障害時の系切り替え失敗（モニタモード）

共有リソースの切り離しを接続時と逆順にする場合で，モニタモードのサーバに障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする処理の流れを次の図に示します。

図4-63　共有リソースの切り離しを接続時と逆順にする場合の，サーバ障害時の系切り替え失敗処理の流れ（モニタモード）

(4)　系障害時の系切り替え失敗処理

共有リソースの切り離しを接続時と逆順にする場合で，系障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする処理の流れについて説明します。処理の流れの詳細は，サーバをサーバモードで使用するか，モニタモードで使用するかによって異なります。

(a)　系障害時の系切り替え失敗（サーバモード）

共有リソースの切り離しを接続時と逆順にする場合で，系障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする処理の流れを次の図に示します。ここでは，サーバモードの場合について説明します。

図4-64　共有リソースの切り離しを接続時と逆順にする場合の，系障害時の系切り替え失敗処理の流れ（サーバモード）

(b)　系障害時の系切り替え失敗（モニタモード）

共有リソースの切り離しを接続時と逆順にする場合の，系障害が発生し待機系に系切り替えしようとして失敗したときの，HAモニタがする系切り替え処理の流れを次の図に示します。ここでは，モニタモードの場合について説明します。

図4-65　共有リソースの切り離しを接続時と逆順にする場合の，系障害時の系切り替え失敗処理の流れ（モニタモード）

5.　HAモニタの導入とシステムの設計

この章では，HAモニタを業務システムに導入するに当たり，検討することについて説明します。

このマニュアルでは，業務システムの設計は終了していることを前提としています。HAモニタを導入して，系切り替え構成を設計する場合に必要な検討事項だけを説明します。

＜この章の構成＞

5.1　導入と設計の流れ

5.2　系切り替え構成の検討

5.3　サーバ構成の検討

5.4　リソース構成の検討

5.5　ハードウェア構成の検討

5.1　導入と設計の流れ

HAモニタの導入を検討する前に，業務に応じて決めておくことについて説明します。

あらかじめ，次の内容を決めてください。

どの業務を系切り替え構成にするか
系切り替え構成にする業務の数によって，系切り替え構成が決まります。

どの程度の信頼性と性能が必要か

業務で使用するプログラムは何か
プログラムの種類によって，HAモニタでの監視方法が異なります。

プログラムがどんなリソースを使用するか

これらの情報を基に，HAモニタを導入する前に検討する内容，および決定する内容を次に示します。

系切り替え構成の検討
業務の数，どの程度の信頼性と性能が必要か，という情報を基に，次を決定します。詳細については，「5.2　系切り替え構成の検討」を参照してください。

系切り替え構成

マシンの数

系の数

LPARの有無

仮想マシンの有無

サーバ構成の検討
業務で使用するプログラムを基に，次を決定します。詳細については，「5.3　サーバ構成の検討」を参照してください。

系切り替えをする単位（サーバ）

サーバの運用方法（サーバモード，モニタモード）

サーバの配置

サーバの数

プログラムの数（プログラム管理機能使用時）

リソース構成の検討
プログラムが使用するリソースを基に，次を決定します。詳細については，「5.4　リソース構成の検討」を参照してください。

必要なリソース

リソースの数

リソースの共用方法

ハードウェア構成の検討
サーバとリソースが決定したので，ハードウェアの構成を決定します。詳細については，「5.5　ハードウェア構成の検討」を参照してください。

5.2　系切り替え構成の検討

HAモニタを導入すると，幾つかの系切り替え構成を実現できます。ここでは，系切り替え構成の違い，および構成設計時に考慮する点について説明します。

系切り替え構成の検討では，次の点を決定します。

系切り替え構成

マシンの数

系の数（HAモニタ Extension使用時）

LPARの有無

仮想マシンの有無

＜この節の構成＞

5.2.1　系切り替え構成の違い

5.2.2　構成設計時の考慮点

5.2.3　系の最大数を変更する場合の考慮点（HAモニタ Extension使用時）

5.2.4　仮想化環境を系切り替え構成にする場合の考慮点（日立サーバ仮想化機構（Virtage）使用時）

5.2.5　仮想化環境を系切り替え構成にする場合の考慮点（VMware ESXi使用時）

5.2.1　系切り替え構成の違い

ここでは，系切り替え構成の違いについて説明します。

各系切り替え構成の特徴を踏まえた上で，コストや系切り替え後の処理性能などを考慮して，業務システムに適切な系切り替え構成を選択してください。系切り替え構成の種類と特徴を次の表に示します。

表5-1　系切り替え構成の種類と特徴

項番
系切り替え構成の種類
特徴

1
1:1系切り替え構成
専用の予備系を用意する系切り替え構成です。
コストは高くなりますが，系切り替え構成後も同等の性能で処理できます。

2
相互系切り替え構成
複数の実行サーバを異なる二つの系で稼働させ，それぞれの待機サーバを互いの系に配置して，業務を実行する系切り替え構成です。資源を有効に活用できますが，系切り替え後には，一つの系で両方の業務を実行するため，負荷が掛かります。

3
2:1系切り替え構成
二つの現用系に，一つの予備系を用意するため，複数の1:1系切り替え構成に比べると，資源を有効に活用できます。
片方の系だけに障害が発生した場合は，系切り替え後の処理性能は劣化しませんが，両方の現用系に障害が発生した場合，一つの予備系に業務が集中するため，負荷が掛かります。

4
複数スタンバイ構成
一つの現用系に，複数の予備系を用意するため，コストは高くなりますが，系切り替え後も同等の性能で処理できます。また，系切り替え後，さらに予備系に障害が発生した場合でも，別の予備系へ系切り替えができるため，業務を継続できます。

5
クラスタ型系切り替え構成
項番1から項番4までの系切り替え構成を組み合わせて，負荷分散をするための系切り替え構成です。
複数の系が実行系と待機系を兼ねることで，一つの業務を異なる系の複数のサーバで並列実行できるため，一つの系に掛かる処理を分散できます。

各系切り替え構成の構成例については，「2.1　系切り替え構成」を参照してください。

5.2.2　構成設計時の考慮点

系切り替え構成を設計するときは，監視パスとリセットパスの信頼性を確保してください。

系障害の検出には，監視パスおよびリセットパスの信頼性が重要です。すべての監視パスおよびリセットパスが同時に障害になった場合，HAモニタはヘルスチェックを使用したリセットパスの障害検出ができなくなり，実行系と待機系とで同じサーバが複数稼働するおそれがあります。そのため，次に示すとおりに，監視パスとリセットパスの信頼性を確保してください。

監視パスは必ず複線化し，一つ以上は専用のパスにします。

監視パスおよびリセットパスは，必ずヘルスチェックをします。

監視パスおよびリセットパスの障害時には，速やかに障害要因を取り除きます。

5.2.3　系の最大数を変更する場合の考慮点（HAモニタ Extension使用時）

HAモニタ Extensionを使用する場合，一つの系切り替え構成での系の最大数を33以上に変更できます。系の最大数を33以上にする場合は，次の条件を満たすマシン環境を用意してください。

監視パスは，ギガビットイーサネットで構成します。

監視パスには，マルチキャストで通信できるLANを使用します。

監視パスのスループットは，100メガbps以上になるようにします。

系切り替え構成内のすべての系のサーバで系切り替えができる状態のときに，監視パスのパケットが漏れなく送受信できるようにします。

監視パスのパケットが漏れなく送受信できているか確認する方法については，「6.21　系の最大数を変更する場合の動作確認（HAモニタ Extension使用時）」を参照してください。

5.2.4　仮想化環境を系切り替え構成にする場合の考慮点（日立サーバ仮想化機構（Virtage）使用時）

日立サーバ仮想化機構を搭載したBladeSymphonyの場合，プロセサを論理パーティション（LPAR）で分割し，LPARを系切り替えの単位にできます（LPARモード）。LPAR単位での系切り替えについては，「3.2.8　仮想化環境での物理パーティションリセット機能」を参照してください。また，日立サーバ仮想化機構を利用してLPARを稼働させるための設定方法については，BladeSymphonyのマニュアルを参照してください。

ここでは，LPARを系切り替えの単位にする場合の考慮点について説明します。

＜この項の構成＞

(1)　系切り替え構成にしたいLPAR，プロセサを検討する

(2)　HAモニタのバージョンを確認する

(3)　ハードウェアの制約に対処する

(1)　系切り替え構成にしたいLPAR，プロセサを検討する

LPARモードとBasicモードとでは，リセットの対象がLPARかプロセサか，ということ以外は，HAモニタの動作に差異はありません。LPAR・LPAR間，LPAR・プロセサ間のどちらでも系切り替え構成にできます。

系切り替え構成にする系同士が同一シャーシ内にあっても問題ありません。ただし，信頼性確保の観点から，系切り替え構成にする系同士は別プロセサにすることを推奨します。

(2)　HAモニタのバージョンを確認する

LPARモードに対応しているHAモニタのバージョンを次に示します。

Linux（x86）の場合：01-22以降

Linux（IPF）の場合：01-13以降

LPARモードに対応していないバージョンのHAモニタをLPARモードの系で稼働させた場合，リセットパス異常になるため系のリセットができません。

LPARモードに対応していないバージョンのHAモニタをBasicモードの系で稼働させ，LPARモードの系と接続することはできます。ただし，LPARモードの系と接続している場合，物理パーティションリセット機能は使用できません。

(3)　ハードウェアの制約に対処する

BladeSymphonyの場合，一つのシャーシに増設できる周辺機器の数に制限があります。そのためLPARモードによってシャーシ当たりの系の数を増やすと，通常と同じハードウェア構成にできないことがあります。

ハードウェアの制約の詳細については，ハードウェアのマニュアルを参照してください。

5.2.5　仮想化環境を系切り替え構成にする場合の考慮点（VMware ESXi使用時）

VMware ESXiで仮想化する場合，一つの物理パーティションを複数の論理パーティション（仮想マシン）で分割し，仮想マシンを系切り替えの単位にできます。仮想マシン単位での系切り替えについては，「3.2.8　仮想化環境での物理パーティションリセット機能」を参照してください。また，VMware ESXiを利用して仮想マシンを稼働させるための設定方法については，VMware ESXiのマニュアルを参照してください。

ここでは，仮想マシンを系切り替えの単位にする場合の考慮点について説明します。

注意

VMware ESXiの仮想化環境で使用する場合，HAモニタの稼働中に仮想マシンをサスペンドしないでください。詳細については，リリースノートを参照してください。

＜この項の構成＞

(1)　系切り替え構成にしたい仮想マシンを検討する

(2)　HAモニタのバージョンを確認する

(3)　マシン環境を確認する

(4)　使用する機能を確認する

(1)　系切り替え構成にしたい仮想マシンを検討する

VMware ESXiによる仮想化環境と通常の環境とでは，リセットの対象が仮想マシンかプロセサか，ということ以外は，HAモニタの動作に差異はありません。仮想マシン・仮想マシン間，仮想マシン・プロセサ間のどちらでも系切り替え構成にできます。

ただし，信頼性確保の観点から，系切り替え構成にする系同士は別プロセサにすることを推奨します。

(2)　HAモニタのバージョンを確認する

VMware ESXiによる仮想化環境を含む系切り替え構成の場合，系切り替え構成内のすべてのHAモニタのバージョンを01-50以降にしてください。01-50より前のバージョンのHAモニタがあると，仮想化環境の系をリセットできません。

既存システムと同一の監視パスを使用する場合は，既存システムのHAモニタのバージョンを01-50にするか，既存システムのHAモニタと接続しないように監視パスを設定してください。

(3)　マシン環境を確認する

VMware ESXiで仮想化する場合，次のマシン環境であることを確認してください。

/usr/bin/sshコマンドがインストールされている。
仮想マシン上の系をリセットするため，HAモニタは/usr/bin/sshコマンドを使用してVMware ESXiに接続します。このため，このコマンドがインストールされていない場合は，Linuxに同梱されているopenssh-clientsパッケージをインストールしてください。

VMware ESXiにSSHで接続できる環境である。
rootユーザがSSHでVMware ESXiに接続できる必要があります。

また，物理パーティション上で動作する仮想マシンの数と仮想マシンのプロセサ数の関係が，次の条件を満たすことを推奨します。

仮想マシンの数＞仮想マシンのプロセサ数の合計

この条件を満たさない場合，仮想マシンにコアが割り当てられない時間帯ができてしまうため，一時的にHAモニタが動作できなくなります。この結果，系障害の検知の遅延や，aliveメッセージの通知の遅延が発生します。

(4)　使用する機能を確認する

VMware ESXiによる仮想化環境では，相互系切り替え構成での系切り替え時間の短縮（HAモニタの環境設定のcpudownオペランドでsystemを指定）はできません。

5.3　サーバ構成の検討

系切り替え構成を検討したあと，サーバ構成を検討します。サーバ構成によって，必要なリソース数が決定するため，リソース構成を検討する前に，サーバ構成を決定しておく必要があります。

サーバとは系切り替えをする単位のことです。一つのプログラムを一つのサーバに対応させたり，複数のプログラムを一つのサーバに対応させたりできます。

サーバ構成の検討では，次を決定します。

系切り替えをする単位（サーバ）

サーバの運用方法（サーバモードまたはモニタモード）

サーバの配置

サーバの数

プログラムの数（プログラム管理機能使用時）

＜この節の構成＞

5.3.1　系切り替えをする単位（サーバ）の決定

5.3.2　複数のサーバを使用する場合の考慮点

5.3.1　系切り替えをする単位（サーバ）の決定

HAモニタはサーバという単位で系切り替えをします。ここでは，サーバについて説明します。

サーバとは，業務を実行するプログラムのことです。一つのプログラムを一つのサーバとして扱うか，または複数のプログラムをまとめて一つのサーバとして扱うかは，系切り替え構成にする業務によって異なります。

＜この項の構成＞

(1)　サーバとプログラムの関係

(2)　サーバの数

(3)　プログラムの数（プログラム管理機能使用時）

(4)　サーバの運用方法（サーバモードとモニタモード）が異なる場合の考慮点

(1)　サーバとプログラムの関係

一つのプログラムを一つのサーバに対応させる方法と，複数のプログラムを一つのサーバに対応させる方法があります。

サーバをサーバモードで運用する場合は，一つのプログラムを一つのサーバに対応させてください。

サーバをモニタモードで運用する場合は，上記のどちらかの方法を選択できます。業務を実行するプログラムが共有リソースを使用する場合，サーバ単位で共有リソースを切り離したり，接続したりするため，サーバごとに共有リソースを用意する必要があります。また，モニタモードで運用する場合は，サーバごとにサーバの起動コマンドを作成する必要があります。これらの点を考慮して，決定してください。

(2)　サーバの数

HAモニタで一つの系に配置できるサーバの最大数は，128です。デフォルトの設定は16です。17以上のサーバを配置する場合，HAモニタの環境設定のservmaxオペランドで，サーバの最大数を指定する必要があります。

ただし，HAモニタ Extensionを使用する場合，サーバの最大数を変更できます。詳細については，「3.5.1　サーバの最大数の変更」を参照してください。

(3)　プログラムの数（プログラム管理機能使用時）

サーバをモニタモードで運用し，かつプログラム管理機能を使用している場合，一つの系で同時に稼働できる，プログラム管理機能を使用するプログラムの数を指定できます。HAモニタで一つの系で同時に稼働できる，プログラム管理機能を使用するプログラムの最大数は，256です。

プログラムの最大数は，HAモニタの環境設定のpgmmaxオペランドで指定します。pgmmaxオペランドのデフォルト値は0であるため，pgmmaxオペランドの値を必ず指定してください。

プログラム管理機能については，「3.4　プログラムの制御のための機能（モニタモード）」を参照してください。

(4)　サーバの運用方法（サーバモードとモニタモード）が異なる場合の考慮点

系にサーバを配置するときには，そのサーバをサーバモードで運用するか，モニタモードで運用するかを意識する必要はありません。サーバモードのサーバとモニタモードのサーバを同じ系に配置できます。また，同じグループとしてグループ化することもできます。

5.3.2　複数のサーバを使用する場合の考慮点

複数のサーバを系切り替え構成にする場合，次の点を考慮してください。

＜この項の構成＞

(1)　複数のサーバで一つの業務を実行しているかどうか

(2)　サーバの起動順序を決める必要があるかどうか

(3)　系切り替え後に，特定の系に負荷が掛かり過ぎないか

(1)　複数のサーバで一つの業務を実行しているかどうか

複数のサーバが連携して一つの業務を処理している場合などは，複数のサーバを一まとまりにして系切り替えをする連動系切り替え機能の使用を検討してください。

サーバをグループ化すると，複数のサーバが一つのグループとして扱われ，グループ内のどれか一つのサーバに障害発生した場合にグループ単位で系切り替えをします。また，サーバの重要度によって，系切り替えをするかどうかを指定できるので，不要な系切り替えが避けられます。

サーバのグループ化の詳細，および必要な環境設定については，「3.1.2　サーバのグループ化による連動系切り替え」を参照してください。

(2)　サーバの起動順序を決める必要があるかどうか

複数のサーバ間で，サーバの起動順序を決める必要がある場合，サーバの切り替え順序制御機能の使用を検討してください。

サーバをグループ化しておき，グループ内で，障害発生時の系切り替え時に起動・停止する順序をあらかじめ決めることができます。例えば，配置するサーバのうち，前提となるサーバがある場合，前提となるサーバを起動したあとに残りのサーバを起動できます。

サーバの切り替え順序制御機能では，サーバの起動時には起動順序を制御できません。制御できるのは系切り替え時だけです。そのため，サーバの起動時には，オペレータが決められた起動順序でサーバを手動起動する必要があります。サーバの起動時の起動順序を自動制御するには，サーバをモニタモードで運用して複数のプログラムを一つのサーバとして扱うことを検討してください。

サーバの切り替え順序制御の詳細，および必要な環境設定については，「3.1.3　サーバの切り替え順序制御」を参照してください。

(3)　系切り替え後に，特定の系に負荷が掛かり過ぎないか

2:1系切り替え構成の場合など，予備系を共有する構成では，系切り替え後に一つの系に業務が集中するおそれがあります。HAモニタでは，予備系で実行サーバが起動されると，その予備系にある別の待機サーバを停止する排他制御機能があります。使用するマシンの性能のため，特定の系に負荷を掛けたくない場合，この排他制御機能を使用します。一つの系で実行するサーバを制限できるので，負荷の集中が避けられます。

この排他制御機能は，予備系に負荷が掛かりやすいn:1系切り替え構成（nは2以上）で使用することを推奨します。排他制御機能については，「3.1.5　系切り替え後の負荷集中を避けるサーバの排他制御」を参照してください。

5.4　リソース構成の検討

リソース構成の検討には，系切り替え構成，サーバの数，サーバに必要な共有リソースの種類などが影響します。リソース構成を検討する前に，系切り替え構成やサーバの構成を検討しておいてください。

リソース構成の検討では，次を決定します。

必要なリソース

リソースの数

リソースの共用方法

＜この節の構成＞

5.4.1　必要なリソースとリソース数

5.4.2　必要なIPアドレス

5.4.3　リソースの共用方法の考え方

5.4.4　リソースサーバを使用する場合の構成

5.4.1　必要なリソースとリソース数

系切り替え構成で必要なリソース，およびリソース数について説明します。必要なリソースには，HAモニタに必要なリソースと，サーバに必要なリソースがあります。必要なリソースの種類を決めたあとに，系やサーバの数を基に各リソースに必要な数を導き出します。

＜この項の構成＞

(1)　HAモニタに必要なリソース

(2)　サーバに必要なリソース

(3)　リソースの最大構成・最小構成

(1)　HAモニタに必要なリソース

HAモニタには，次のリソースが必要です。

監視パス

リセットパス

(2)　サーバに必要なリソース

サーバに必要なリソースは，業務内容に応じて決定してください。HAモニタが自動的に系切り替えをするリソースは，次のとおりです。

共有ディスク

ファイルシステム

LAN

上記以外の共有リソースをサーバで使用するには，あらかじめ共有リソースの接続・切り離しの処理を，ユーザコマンドとして作成しておく必要があります。

(3)　リソースの最大構成・最小構成

HAモニタのハードウェアとソフトウェアに対する，最大構成と最小構成を次の表に示します。

なお，この表の値は論理的なものです。実際にシステムを構築する際には，プロセサの性能や使用環境に合わせて構成を決定してください。また，この表の最大構成はHAモニタの論理値であるため，実際は適用するOSやマシンの構成によって値が制限される場合があります。実際の値は，製品のマニュアルなどで確認してください。

表5-2　HAモニタで使用できるリソースの最大構成と最小構成

分類 | 項目 | 最大構成 | 最小構成
ハードウェア | 一つの系切り替え構成での系の数 | 32※1 | 2
一つの系での監視パスの数 | 6 | 2
一つの系でのリセットパスの数 | 1 | 1
一つのサーバでの共有ディスク上のボリュームグループの数 | 3,000 | 0
一つのサーバでの制御グループの数 | 20 | 0
一つのサーバでの共有ディスク上のファイルシステムの数 | 3,000 | 0
ソフトウェア | 一つの系でのHAモニタの数 | 1 | 1
一つの系でのサーバの数（リソースサーバは含みません） | 128※1，※2 | 1
一つのサーバでのプログラム管理機能を使用するプログラムの数※3 | 256 | 1
一つの系でのエイリアスIPアドレスの数 | － | 0　
一つの系でのリソースサーバの数 | 64※4 | 0

（凡例）－：制限はありません。

注※1　HAモニタ Extensionを使用する場合は，値が異なります。詳細については，「3.5.2(1)　指定できる系の最大数」を参照してください。

注※2　最大稼働サーバ数を設定した場合の値です。設定しない場合は16になります。

注※3　モニタモードのプログラム管理機能使用時にだけ該当する項目です。

注※4　最大稼働サーバ数を設定した場合の値です。設定しない場合は8になります。

5.4.2　必要なIPアドレス

系切り替え構成の導入に当たり，IPアドレスを確保する必要があります。ここでは，IPアドレスを割り当てる対象およびIPアドレスの数について説明します。IPアドレスを割り当てる対象を次の図に示します。

図5-1　IPアドレスを割り当てる対象

図で示した，IPアドレスを割り当てる対象と指定するIPアドレスの数を次の表に示します。

表5-3　IPアドレスを割り当てる対象と指定するIPアドレスの数

図中の番号
割り当てる対象
IPアドレスの数
単位
説明
設定個所

1
監視パス
6
1系につき
監視パスは複線化する必要があります。6本まで複線化できます。
各監視パスに異なるIPアドレスとポート番号を指定する必要があります。
IPアドレスについては，「5.5.3(3)　複線化した監視パスに割り当てるIPアドレス」を参照してください。
ポート番号には，システムで未使用の5001以上の番号を指定します。実行系と待機系とでペアになっている監視パスには，同じポート番号を指定してください。
HAモニタ Extensionを使用して系の最大数を変更する場合の，IPアドレスとホスト名については，「3.5.2　系の最大数の変更」もあわせて参照してください。

HAモニタの環境設定のlanオペランド（ホスト名）

HAモニタの環境設定のlanportオペランド（サービス名）

HAモニタの環境設定のnetmaskオペランド（ネットマスク）

HAモニタの環境設定のmulticast_lanオペランド（ホスト名）

/etc/hostsファイル（IPアドレス，ホスト名）

/etc/servicesファイル（ポート番号，サービス名）

HAモニタの接続構成設定ファイル

2
リセットパス※1
1
1系につき
専用のIPアドレスとポート番号が必要です。
ポート番号には，各系で同じ番号，かつ未使用の番号を5001から65535の範囲で指定します。
システム内に互いに監視し合わない系切り替え構成が複数ある場合で，かつリセットパスを共用する場合は，設定時に注意が必要です。詳細は「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

リセットパスの設定
（HAモニタの環境設定コマンド（monsetupコマンド）を使用した設定）

3
SVP※1
1
1系につき
専用のIPアドレスとポート番号が必要です。
IPアドレスには，リセットパスと同じネットワークアドレスを持つIPアドレスを指定します。
ポート番号には，リセットパスとは異なる番号，かつ未使用の番号を5001から65535の範囲で指定します。

リセットパスの設定
（HAモニタの環境設定コマンド（monsetupコマンド）を使用した設定）

MP※2
1
1系につき
専用のIPアドレスが必要です。
IPアドレスには，リセットパスと同じネットワークアドレスを持つIPアドレスを指定します。

/etc/hostsファイル（IPアドレス，ホスト名）

LANポートの設定（IPアドレス，ネットマスク）

HAモニタの環境設定のnameオペランド（ホスト名）

4
LAN
0以上
1系につき
サーバがLANを使用する場合は1個以上必要です。上限はありません。LANを使用しない場合は，不要です。

OSの設定
設定方法については，OSのマニュアルを参照してください。

5
サーバ
0以上
1サーバにつき
サーバがLANを使用する場合は1個以上必要です。
エイリアスIPアドレスを指定します。実行系と待機系とで同じ値を指定してください。エイリアスIPアドレスの詳細については，「5.5.2(2)　サーバに割り当てるIPアドレス」を参照してください。

LANの状態設定ファイル

6
VMware ESXi※3
1
プロセサまたは筺体
HAモニタが接続するためのIPアドレスとSSH接続用のポート番号が必要です。
HAモニタが使用するIPアドレスは，DHCPを使用しないで，スタティックに設定してください。
SSH接続用のポート番号には，デフォルトで22が割り当てられていますが，新たに別のポート番号を割り当てても問題ありません。この場合，HAモニタにVMware ESXiのSSH接続用ポート番号を指定してください。

リセットパスの設定
（HAモニタの環境設定コマンド（monsetupコマンド）を使用した設定）

注※1　マシンの機種がBladeSymphonyまたはHA8000の場合に必要な設定です。

注※2　マシンの機種がHA8500の場合に必要な設定です。

注※3　VMware ESXiで仮想化する構成の場合に必要な設定です。

5.4.3　リソースの共用方法の考え方

ここでは，リソースをどのように共用するかを検討するときの考え方について説明します。

各共有リソースは，サーバごとに準備する必要があります。ただし，リソースサーバを使用すれば，複数のサーバで一つの共有リソースを共用できます。LANの場合は，複数のIPアドレスをLANアダプタに設定する方法もあります。

共有リソースを複数に分けると，共有リソースの障害による影響範囲を局所化できます。しかし，リソースの数に比例して系切り替え時間が長くなります。両面を考慮して，リソース構成を検討してください。

サーバごとに準備する共有リソースの単位を次に示します。

表5-4　準備する共有リソースの単位

共有リソースの種類
サーバごとに必要な単位

共有ディスク

共有ディスクの接続にLVMを使用する場合

ボリュームグループ

共有ディスクの接続にHA Boosterを使用する場合

制御グループ

ファイルシステム
論理ボリューム

LAN
IPアドレス

5.4.4　リソースサーバを使用する場合の構成

リソースサーバを使用して，複数のサーバで共有リソースを共用する場合の構成について説明します。

＜この項の構成＞

(1)　リソースサーバの数

(2)　リソースサーバの構成の考え方

(1)　リソースサーバの数

リソースサーバは，グループに対して一つだけ指定できます。一つの系に配置できるリソースサーバの最大数は，HAモニタの環境設定のservmaxオペランドで指定する一つの系で稼働するサーバの最大数によって変わります。

servmaxオペランドで指定するサーバの最大数別に，配置できるリソースサーバの最大数を次に示します。

サーバの最大数が16のとき：8

サーバの最大数が64のとき：32

サーバの最大数が128以上のとき：64

HAモニタ Extensionを使用してサーバの最大数を変更する場合には，配置できるリソースサーバの最大数が異なります。詳細については，「3.5.1(1)　指定できるサーバの最大数」を参照してください。

(2)　リソースサーバの構成の考え方

リソースには，共有ディスク，ファイルシステム，およびLANがあります。このうち，一つのリソースを複数のサーバで共用し，ほかのリソースは共用しないで各サーバで使用したり，逆に，複数のリソースを一つのリソースサーバを介して共用したりできます。

(a)　実現できる構成

リソースサーバを使用して，次の構成が実現できます。

一つのリソースサーバから，複数の共有リソースを共用する

複数の共有リソースのうち，一つをリソースサーバで共用し，残りはサーバ単位で分けて使用する

一つのリソースサーバから，複数の共有リソースを共用する構成を次の図に示します。この構成では，サーバAおよびサーバBが，共有ディスクおよびエイリアスIPアドレスを共用しています。

図5-2　一つのリソースサーバから，複数の共有リソースを共用する構成

複数の共有リソースのうち，一つをリソースサーバで共用し，残りはサーバ単位で分けて使用する構成を次の図に示します。この構成では，サーバAおよびサーバBが共有ディスクを共用し，エイリアスIPアドレスはサーバごとに使用しています。

図5-3　複数の共有リソースのうち一つを共用し，残りはサーバ単位で使用する構成

(b)　実現できない構成

複数のサーバ，またはリソースサーバで一つの共有リソースを共用できません。共有リソースを共用するサーバは，リソースサーバと同じグループに属する必要があります。

例えば次に示す構成では，リソースサーバと，サーバグループに属さないサーバCが一つの共有ディスクを使用する構成になっています。この構成では，リソースサーバを使用した共有リソースの共用を実現できません。

図5-4　リソースサーバを使用して共有リソースの共用を実現できない構成

5.5　ハードウェア構成の検討

HAモニタに必要なハードウェアの構成について説明します。

ここでは，HAモニタを使用した系切り替え構成を設計するときに異なる点について説明します。このマニュアルで説明していない設定については，ご使用のハードウェアのマニュアルを参照してください。

＜この節の構成＞

5.5.1　共有ディスクの構成

5.5.2　LANの構成

5.5.3　監視パスの構成

5.5.4　リセットパスの構成

5.5.5　ハードウェア構成例（BladeSymphony（Basicモード））

5.5.6　ハードウェア構成例（BladeSymphony（LPARモード））

5.5.7　ハードウェア構成例（HA8000）

5.5.8　ハードウェア構成例（HA8500）

5.5.1　共有ディスクの構成

共有ディスクは，ボリュームグループ単位，または制御グループ単位で制御します。

ボリュームグループ単位で制御する場合，共有ディスクは，共有ディスクを使用するすべての系から接続し，LVMを使用して制御します。各サーバが使用するデータは異なるボリュームグループに配置し，ボリュームグループをサーバごとに独立させてください。ただし，リソースサーバを使用すれば，一つの共有ディスクを複数のサーバで共用できます。

制御グループ単位で制御する場合，共有ディスクは，HA Boosterを使用して，HA Boosterが管理する制御グループ単位で共有ディスクを制御します。各サーバが使用するデータは異なる制御グループに配置し，制御グループをサーバごとに独立させてください。ただし，リソースサーバを使用すれば，一つの制御グループを複数のサーバで共用できます。

単一点障害の防止

HAモニタは，ディスク障害，およびディスクアダプタなどのI/Oパスの障害を直接処理するものではありません。次の両方の方法を使用して共有ディスクの単一点障害を防止する構成にしてください。

RAIDによるデータの冗長化
日立ディスクアレイシステムなどの，RAIDデバイスを使用して実現します。

I/Oパスの冗長化
HDLMなどのディスクパス切り替えソフトウェアを使用して実現します。

共有ディスクの接続方法

共有ディスクに使用するディスク装置は，FC（Fibre Channel）接続で構成することを推奨します。

5.5.2　LANの構成

LANは，実行系と待機系を接続したり，クライアントとなるWSやPCと接続したりするために使用します。実行系と待機系は，同じLAN上にLANアダプタで接続します。

＜この項の構成＞

(1)　単一点障害の防止

(2)　サーバに割り当てるIPアドレス

(3)　IPアドレスの構成

(4)　VMware ESXiで仮想化する場合の構成

(1)　単一点障害の防止

HAモニタは，HUBやLANアダプタなどのLAN障害を直接処理しません。これらの障害に対しては，次の方法でLANの単一点障害を防止する構成にしてください。

HUBの冗長化

Linuxのカーネル拡張パッケージであるbondingパッケージなどを使用したLANアダプタの冗長化

(2)　サーバに割り当てるIPアドレス

サーバにはエイリアスIPアドレスを指定します。エイリアスIPアドレスを指定することで，一つのサーバに複数のエイリアスIPアドレスを指定できます。サーバにエイリアスIPアドレスを指定する場合，次の点に注意してください。

系切り替えをするプログラムの送信元アドレスをエイリアスIPアドレスにしておく必要があります。

エイリアスIPアドレスを持つホスト名を，hostname(1)コマンドで設定するローカルホスト名として使用してはいけません。系切り替えで別ホストに移動した場合，ホスト名からIPアドレスを取得するプログラムが元のホスト上で動作できなくなります。

(3)　IPアドレスの構成

HAモニタは，サーバに割り当てたエイリアスIPアドレス単位に，LANの切り替えをします。したがって，複数の異なるサーバで系切り替え構成にする場合，各サーバが使用するエイリアスIPアドレスは異なるIPアドレスとなるように，ネットワークアドレスを構成してください。ただし，リソースサーバを使用すれば，一つのエイリアスIPアドレスを複数のサーバで共用できます。

(4)　VMware ESXiで仮想化する場合の構成

VMware ESXiで仮想化する構成の場合，LANアダプタ，およびホストバスアダプタ（HBA）は仮想マシン間で共有しても，また占有しても問題ありません。

また，信頼性確保のため，VMware ESXiの機能を使用して次のように冗長化することを推奨します。

LANアダプタをそれぞれ二つずつ用意して，リセットパス，またはVMware ESXi接続用リセットパスを冗長化する。

ホストバスアダプタを二つ用意して冗長化する。

5.5.3　監視パスの構成

監視パスは，実行系と待機系との間で，互いの系を監視したり，系切り替えのための情報を交換したりするために使用します。

なお，HAモニタ Extensionを使用して，一つの系切り替え構成での系の最大数を33以上に設定する場合には，監視パスに必要な条件が異なります。詳細については，「5.2.3　系の最大数を変更する場合の考慮点（HAモニタ Extension使用時）」を参照してください。

＜この項の構成＞

(1)　監視パスの接続方法

(2)　監視パスの複線化

(3)　複線化した監視パスに割り当てるIPアドレス

(1)　監視パスの接続方法

監視パス専用のTCP/IP LANを用意します。TCP/IP LANは，どの系切り替え構成でも使用できますが，専用のIPアドレスとポート番号が必要です。

監視パスは，LANアダプタを介して，監視し合う系同士（実行系と待機系）のプロセサ間を接続します。実行系と待機系，およびそれらを接続する監視パスは，同じネットワーク上に構成してください。一つの実行系に対して複数の待機系がある場合，実行系とすべての待機系を監視パスで接続し，同じネットワーク上に構成します。

(2)　監視パスの複線化

監視パスが1本の場合，監視パスに障害が発生すると，HAモニタが監視パスの障害を系障害と判断して，系切り替えを実行するおそれがあります。このような単一点障害での系切り替えを避けるために，監視パスを必ず複線化してください。また，1本以上は監視専用のパスにしてください。監視パスが1本の場合，系切り替え続行可否の判定が確実に行えない場合があります。

使用しているマシンの機種がBladeSymphonyの場合は，増設できるLANアダプタの数は限られます。そのため，監視パスを複線化するに当たって，監視パスと業務用LAN，および監視パスとリセットパスの兼用を考慮する必要がある場合があります。

監視パスは6本まで複線化できます。監視パスを複線化しておくと，1本の監視パスに障害が発生しても，ほかのパスで系の監視を続行できます。また，次のどちらかの運用を選択できます。

監視パス1本当たりの情報量の負荷を減らせます。
系間の通信のたびに異なる監視パスを使用するため，監視パス1本当たりの情報量の負荷を減らせます。優先して使用する監視パスを指定しない場合は，この運用になります。

優先して使用する監視パスを指定できます。
HAモニタの環境設定のlanオペランドで，優先して使用する監視パスを指定しておくと，系間の通信には設定した監視パスを優先して使用します。その監視パスに障害が発生すると，ほかの監視パスと交代して通信を続けます。
ただし，HAモニタの環境設定のalive_intervalオペランドでaliveメッセージの送信間隔を設定する場合，すべての監視パスにaliveメッセージを送信します。そのため，優先して使用する監視パスを指定できません。

なお，Linuxのカーネル拡張パッケージであるbondingパッケージやVMware ESXiの機能などを使用してLANアダプタを冗長化すれば，監視パスの複線化をしなくても単一点障害での系切り替えを避けることができます。ただし，LANアダプタの切り替えに時間が掛かるため，HAモニタの環境設定のpatrolオペランドに設定する値はLANアダプタの切り替え時間よりも大きくする必要があります。

(3)　複線化した監視パスに割り当てるIPアドレス

監視パスには，専用のIPアドレスとポート番号が必要です。監視パスを複線化するため，次のことに注意してください。

使用するLANセグメントは，監視パス間で異なるものを使用してください。

ネットワークアドレスは，監視パス間で異なるものを使用してください。

ネットワークアドレスは，ネットワーク番号とサブネット番号で構成されます。

ネットワーク番号を監視パスごとに分ける場合
指定できるIPアドレスに，制約はありません。IPアドレスの組み合わせの例を次に示します。

表5-5　IPアドレスの組み合わせの例（ネットワーク番号を監視パスごとに分ける場合）

LAN | IPアドレス | ネットマスク | ネットワーク番号 | サブネット番号 | ホスト番号
LAN1 | 100.2.1.130 | 255.255.255.0 | 100 | 2.1 | 130
LAN2 | 101.2.1.130 | 255.0.0.0 | 101 | なし | 2.1.130

同じネットワーク番号を割り当て，サブネットを監視パスごとに分ける場合
同じネットマスクを指定する必要があります。
すべての監視パスに同じネットワーク番号を割り当て，監視パスごとに異なるサブネットで構成するネットワークでは，異なるネットマスクを設定しないでください。例えば，次に示すIPアドレスの組み合わせは，ネットワーク番号が同じであり，かつネットマスクが異なるため，監視パスを複線化できません。

表5-6　監視パスを複線化できない例

LAN | IPアドレス | ネットマスク | ネットワーク番号 | サブネット番号 | ホスト番号
LAN1 | 100.2.1.130 | 255.255.255.0 | 100 | 2.1 | 130
LAN2 | 100.2.2.130 | 255.255.0.0 | 100 | 2 | 2.130

次に示すIPアドレスの組み合わせは，ネットワーク番号およびネットマスクが同じであるため，監視パスを複線化できます。

表5-7　監視パスを複線化できる例

LAN | IPアドレス | ネットマスク | ネットワーク番号 | サブネット番号 | ホスト番号
LAN1 | 100.2.1.130 | 255.255.255.0 | 100 | 2.1 | 130
LAN2 | 100.2.2.130 | 255.255.255.0 | 100 | 2.2 | 130

同じネットワーク番号を割り当て，サブネットを監視パスごとに分けて複線化したネットワーク構成を次の図に示します。

図5-5　監視パスを複線化したネットワーク構成

5.5.4　リセットパスの構成

リセットパスは，実行系と待機系の障害管理プロセサ間を接続して，実行系で障害が発生した場合に，系の入出力のリセットを指示するために使用します。

リセットパスには，リセット専用のTCP/IP LANを使用します。各系の障害管理プロセサをリセット専用LANに接続します。また，待機系のHAモニタから実行系の障害管理プロセサへリセットを指示するため，さらに別のLANアダプタでリセット専用LANに接続します。

リセット専用LANは，トラフィック増加による系リセットの遅延や失敗を防止するため，ほかの業務で使用するLANとは分け，専用のLANにしてください。これによって，障害管理プロセサへの不当なアクセスも防止できます。

注意

監視パスとリセットパスを共用しないでください。単一点障害で両機能が使用できなくなるおそれがあります。

ただし，BladeSymphonyの場合，使用できるLANアダプタの数に制限があります。運用上しかたがないときは，監視パスを複線化する目的に限って共用してください。

ここでは，リセットパスの構成について検討する内容，および系切り替え構成間でリセットパスを共用する場合の注意事項について説明します。

＜この項の構成＞

(1)　リセットパスの構成について検討する内容

(2)　系切り替え構成間でリセットパスを共用する場合の注意事項

(1)　リセットパスの構成について検討する内容

リセットパスの構成は，使用するマシンの機種や系切り替え構成によって異なります。ここでは，リセットパスの構成について説明します。マシンの機種については「1.5.1(1)　プロセサ」を，系切り替え構成の種類については「2.1　系切り替え構成」を参照してください。

リセットパスの構成について検討する内容を次の表に示します。

表5-8　リセットパスの構成について検討する内容

検討する内容
説明

障害管理プロセサとリセットパスの接続方法
障害管理プロセサには，システムのLANポートとは別のLANポートがあります。そのLANポートをリセットパスに接続することで，障害管理プロセサをリセットパスに接続します。
LANポートの搭載位置は機種によって異なります。詳細については，ハードウェアのマニュアルを参照してください。

リセットパスの二重化
リセットパスそのものは二重化できません。Linuxのカーネル拡張パッケージであるbondingパッケージなどを使用して，リセットパスが接続されているLANアダプタを二重化してください。
LANアダプタを二重化することで，LANアダプタに障害が発生した場合にもう一方のLANアダプタを使用して系切り替えができます。
なお，VMware ESXiで仮想化する場合，VMware ESXiの機能で，LANアダプタを冗長化することを推奨します。

日立サーバ仮想化機構の利用有無（BladeSymphony）
日立サーバ仮想化機構を利用してLPAR間で系切り替え構成にする場合，一つのLPARが一つの系になります。したがって，各LPARからそれぞれリセットパスに接続する必要があります。

リセットパスの接続構成の例を次に示します。

1:1系切り替え構成の場合

図5-6　リセットパスの接続構成（1:1系切り替え構成の場合）

同一シャーシ内で1:1系切り替え構成にする場合（BladeSymphony）

図5-7　リセットパスの接続構成（同一シャーシ内での1:1系切り替え構成の場合）（BladeSymphony）

使用しているマシンの機種がBladeSymphonyの場合は，同一シャーシ内で系切り替え構成にできます。また，日立サーバ仮想化機構を利用してLPAR間で系切り替え構成にするときも，同一シャーシ内で系切り替え構成にできます。

相互に直接接続する場合（HA8500）

図5-8　リセットパスの接続構成（相互に直接接続する場合）

使用するマシンの機種がHA8500の場合，1:1系切り替え構成のときは障害管理プロセサとLANアダプタをクロスケーブルで相互に直接接続できます。この場合，監視パスとして使用するTCP/IP LANと共用することはできません。

(2)　系切り替え構成間でリセットパスを共用する場合の注意事項

マシンの機種がBladeSymphony，またはHA8000の場合，システム内で互いに監視し合わない系切り替え構成を複数構築すると，ハードウェアの制約上，複数の系切り替え構成間でリセットパスを共用することがあります。

このようなネットワーク構成で環境設定を誤ると，HAモニタは系同士を正しく識別できません。そのため，系障害時に障害と無関係な系がリセットされたり，HAモニタが異常終了したりするおそれがあります。ここでは，HAモニタが系同士を正しく識別するための設定時の注意事項を，次の場合に分けて説明します。

SVPを共用する場合（BladeSymphony）

SVPを共用しない場合（BladeSymphonyまたはHA8000）

N+Mコールドスタンバイ構成で予備のサーバモジュールを共用する場合（BladeSymphony）

なお，システム構築時には，ここで設定したIPアドレスが重複していないかどうかを確認する必要があります。IPアドレスの重複チェックについては，「6.18.1　複数系切り替え構成間での設定・定義のチェック」を参照してください。

参考

次に示す，HAモニタのほかの適用OS，およびマシンの機種での系切り替え構成も対象です。

AIX（EP8000）

HP-UX（IPF）（BladeSymphony）

(a)　SVPを共用する場合（BladeSymphony）

複数の系切り替え構成間でリセットパスを共用したネットワーク構成で，系切り替え構成間でSVPを共用する場合の例を次に示します。

図5-9　系切り替え構成間でリセットパスを共用したネットワーク構成（SVPを共用する場合）

このような構成で，系1・系3間で一組，系2・系4間で一組，合計二組の系切り替え構成を構築する場合，各シャーシのSVPは，異なる系切り替え構成にある系二つと接続されているため，系切り替え構成間でSVPを共用する構成となります。このような場合は，次の設定をしてください。

自系のホストアドレスは，全系で異なる値を設定してください。別シャーシにある系でも，ホストアドレスによって系を識別できるよう，異なる値にします。
ホストアドレスは，HAモニタの環境設定のaddressオペランドで設定してください。

リセットパスのポート番号は，全系で同じ値を設定してください。別シャーシにあっても，SVPを共用する系にはすべて同じ値を設定します。

SVPのポート番号は，すべて同じ値を設定してください。ただし，SVPがSVPコマンドモードのHAコマンドによるクラスタ番号の設定に対応している場合，系切り替え構成ごとに，異なるクラスタ番号とポート番号を設定してください。

リセットパスのポート番号とSVPのポート番号が重複しないように設定してください。

設定例については，「6.4.2(3)　2シャーシ／4系（Basicモード）の構成」を参照してください。

なお，N+Mコールドスタンバイ構成の場合は，これまでに説明してきた注意事項に加えて，パーティション名は全系で異なる値を設定してください。設定例については，「6.4.2(6)　N+Mコールドスタンバイ構成」を参照してください。

(b)　SVPを共用しない場合（BladeSymphonyまたはHA8000）

複数の系切り替え構成間でリセットパスを共用したネットワーク構成で，系切り替え構成間でSVPを共用しない場合の例を次に示します。

図5-10　系切り替え構成間でリセットパスを共用したネットワーク構成（SVPを共用しない場合）

このような構成で，系1・系3間で一組，系2・系4間で一組，合計二組の系切り替え構成を構築する場合，異なる系切り替え構成間でSVPは共用されません。このような場合は，次のどちらかの設定をしてください（両方の設定をしても問題ありません）。

自系のホストアドレスは，全系で異なる値を設定してください。別シャーシにある系でも，ホストアドレスによって系を識別できるよう，異なる値にします。
ホストアドレスは，HAモニタの環境設定のaddressオペランドで設定してください。

リセットパスのポート番号は，系切り替え構成ごとに異なる値を設定してください。一組の系切り替え構成内の系間には同じ値を設定します。また，SVPのポート番号も，系切り替え構成ごとに異なる値を設定してください。
リセットパスのポート番号とSVPのポート番号が重複しないように設定してください。

設定例については，BladeSymphonyの場合は「6.4.2(4)　4シャーシ／4系（Basicモード）の構成」を，HA8000の場合は「6.5.2(2)　系切り替え構成が二組の場合」を参照してください。

なお，N+Mコールドスタンバイ構成の場合は，これまでに説明してきた注意事項に加えて，パーティション名は全系で異なる値を設定してください。設定例については，「6.4.2(6)　N+Mコールドスタンバイ構成」を参照してください。

(c)　N+Mコールドスタンバイ構成で予備のサーバモジュールを共用する場合（BladeSymphony）

ここでは，次のすべての場合に当てはまるネットワーク構成について説明します。

複数の系切り替え構成間でリセットパスを共用する場合

N+Mコールドスタンバイ構成で予備のサーバモジュールを共用する場合

このようなネットワーク構成の例を次に示します。

図5-11　系切り替え構成間でリセットパスを共用したネットワーク構成（N+Mコールドスタンバイ構成で予備のサーバモジュールを共用する場合）

このような構成で，系1・系3間で一組，系2・系4間で一組，合計二組の系切り替え構成を構築する場合は，次の設定をしてください。

自系のホストアドレスは，全系で異なる値を設定してください。別シャーシにある系でも，ホストアドレスによって系を識別できるよう，異なる値にします。

リセットパスのポート番号は，全系で同じ値を設定してください。また，SVPのポート番号も，全系で同じ値を設定してください。

パーティション名は，全系で異なる値を設定してください。

設定例については，「6.4.2(6)　N+Mコールドスタンバイ構成」を参照してください。

5.5.5　ハードウェア構成例（BladeSymphony（Basicモード））

マシンの機種がBladeSymphonyの場合の，各系切り替え構成でのハードウェア構成例について説明します。

BladeSymphonyでは一つのシャーシに複数の系を持てるため，系と同じ数だけシャーシを増やす必要はありません。例として1:1系切り替え構成の場合で，シャーシが一つのときと二つのときの構成例を示します。ほかの構成例では，シャーシを二つ使用した場合のハードウェア構成を示します。

LPARモードで動作させる場合のハードウェア構成例については「5.5.6　ハードウェア構成例（BladeSymphony（LPARモード））」を参照してください。

＜この項の構成＞

(1)　1:1系切り替え構成

(2)　2:1系切り替え構成

(3)　複数スタンバイ構成

(4)　クラスタ型系切り替え構成

(5)　VMware ESXiで仮想化する構成

(1)　1:1系切り替え構成

シャーシが一つで，同じシャーシ内にあるプロセサ同士を1:1系切り替え構成にしたときのハードウェア構成例を，次の図に示します。

図5-12　同一シャーシ内での1:1系切り替え構成時のハードウェア構成例（BladeSymphony（Basicモード））

シャーシが二つのときの1:1系切り替え構成時のハードウェア構成例を，次の図に示します。

図5-13　二つのシャーシ間での1:1系切り替え構成時のハードウェア構成例（BladeSymphony（Basicモード））

(2)　2:1系切り替え構成

2:1系切り替え構成時のハードウェア構成例を次の図に示します。

図5-14　2:1系切り替え構成時のハードウェア構成例（BladeSymphony（Basicモード））

(3)　複数スタンバイ構成

複数スタンバイ構成時のハードウェア構成は，2:1系切り替え構成時と同じ構成になります。2:1系切り替え構成時のハードウェア構成例については，「5.5.5(2)　2:1系切り替え構成」を参照してください。

(4)　クラスタ型系切り替え構成

クラスタ型系切り替え構成時のハードウェア構成例を次の図に示します。

図5-15　クラスタ型系切り替え構成時のハードウェア構成例（BladeSymphony（Basicモード））

(5)　VMware ESXiで仮想化する構成

VMware ESXiによる仮想化構成時のハードウェア構成例を次の図に示します。

図5-16　VMware ESXiによる仮想化構成時のハードウェア構成例（BladeSymphony（Basicモード））

5.5.6　ハードウェア構成例（BladeSymphony（LPARモード））

日立サーバ仮想化機構を搭載したBladeSymphonyをLPARモードで動作させる場合の，各系切り替え構成でのハードウェア構成例について説明します。

Basicモードで動作させる場合のハードウェア構成例については「5.5.5　ハードウェア構成例（BladeSymphony（Basicモード））」を参照してください。

＜この項の構成＞

(1)　1:1系切り替え構成

(2)　2:1系切り替え構成

(3)　複数スタンバイ構成

(4)　クラスタ型系切り替え構成

(1)　1:1系切り替え構成

シャーシが一つで，同じシャーシ内にあるLPAR同士を1:1系切り替え構成にしたときのハードウェア構成を，次の図に示します。この例では，LPAR2・LPAR3間で系切り替え構成にしています。

図5-17　同一シャーシ内での1:1系切り替え構成時のハードウェア構成例（BladeSymphony（LPARモード））

シャーシが二つのときの1:1系切り替え構成時のハードウェア構成例を，次の図に示します。この例では，LPAR1・LPAR3間で系切り替え構成にしています。

図5-18　二つのシャーシ間での1:1系切り替え構成時のハードウェア構成例（BladeSymphony（LPARモード））

(2)　2:1系切り替え構成

2:1系切り替え構成時のハードウェア構成例を次の図に示します。この例では，LPAR2・LPAR3・LPAR6間で系切り替え構成にしています。

図5-19　2:1系切り替え構成時のハードウェア構成例（BladeSymphony（LPARモード））

(3)　複数スタンバイ構成

複数スタンバイ構成時のハードウェア構成は，2:1系切り替え構成時と同じ構成になります。2:1系切り替え構成時のハードウェア構成例については，「5.5.6(2)　2:1系切り替え構成」を参照してください。

(4)　クラスタ型系切り替え構成

クラスタ型系切り替え構成時のハードウェア構成例を次の図に示します。この例では，LPAR2・LPAR3・LPAR6・LPAR7間で系切り替え構成にしています。

図5-20　クラスタ型系切り替え構成時のハードウェア構成例（BladeSymphony（LPARモード））

5.5.7　ハードウェア構成例（HA8000）

マシンの機種がHA8000の場合の，各系切り替え構成でのハードウェア構成例について説明します。

＜この項の構成＞

(1)　1:1系切り替え構成

(2)　2:1系切り替え構成

(3)　複数スタンバイ構成

(4)　クラスタ型系切り替え構成

(5)　VMware ESXiで仮想化する構成

(1)　1:1系切り替え構成

1:1系切り替え構成時のハードウェア構成例を次の図に示します。

図5-21　1:1系切り替え構成時のハードウェア構成例（HA8000）

(2)　2:1系切り替え構成

2:1系切り替え構成時のハードウェア構成例を次の図に示します。

図5-22　2:1系切り替え構成時のハードウェア構成例（HA8000）

(3)　複数スタンバイ構成

複数スタンバイ構成時のハードウェア構成例を次の図に示します。

図5-23　複数スタンバイ構成時のハードウェア構成例（HA8000）

(4)　クラスタ型系切り替え構成

クラスタ型系切り替え構成時のハードウェア構成例を次の図に示します。

図5-24　クラスタ型系切り替え構成時のハードウェア構成例（HA8000）

(5)　VMware ESXiで仮想化する構成

VMware ESXiによる仮想化構成時のハードウェア構成例を次の図に示します。

図5-25　VMware ESXiによる仮想化構成時のハードウェア構成例（HA8000）

5.5.8　ハードウェア構成例（HA8500）

マシンの機種がHA8500の場合の，各系切り替え構成でのハードウェア構成例について説明します。

＜この項の構成＞

(1)　1:1系切り替え構成

(2)　2:1系切り替え構成

(3)　複数スタンバイ構成

(4)　クラスタ型系切り替え構成

(1)　1:1系切り替え構成

1:1系切り替え構成時のハードウェア構成例を次の図に示します。

図5-26　1:1系切り替え構成時のハードウェア構成例（HA8500）

(2)　2:1系切り替え構成

2:1系切り替え構成時のハードウェア構成例を次の図に示します。

図5-27　2:1系切り替え構成時のハードウェア構成例（HA8500）

(3)　複数スタンバイ構成

複数スタンバイ構成時のハードウェア構成例を次の図に示します。

図5-28　複数スタンバイ構成時のハードウェア構成例（HA8500）

(4)　クラスタ型系切り替え構成

クラスタ型系切り替え構成時のハードウェア構成例を次の図に示します。

図5-29　クラスタ型系切り替え構成時のハードウェア構成例（HA8500）

6.　システムの構築

HAモニタを組み込んだシステムの構築手順，HAモニタのディレクトリ構成，およびHAモニタのシステムの構築に必要な各設定について説明します。システムの構築は，スーパユーザの権限で行ってください。

この章では，システム構築の前提となるハードウェアはすでに構成されているものとして説明します。

＜この章の構成＞

6.1　構築の流れ

6.2　ディレクトリ構成

6.3　OSの設定

6.4　リセットパスの設定（BladeSymphony）

6.5　リセットパスの設定（HA8000）

6.6　障害管理プロセサの設定（HA8500）

6.7　HAモニタで使用するためのVMware ESXiの設定

6.8　監視パスの設定

6.9　定義ファイルの作成（HAモニタ）

6.10　サーバが使用する共有リソースの設定

6.11　サーバの起動・停止・監視コマンドの作成

6.12　プログラムの再起動コマンドの作成（プログラム管理機能使用時）

6.13　UAPの作成と設定

6.14　定義ファイルの作成（サーバ）

6.15　定義ファイルの作成（モニタモードのプログラム）

6.16　ユーザコマンドの作成

6.17　HAモニタ Extensionの設定

6.18　構築したシステムの設定・定義のチェック

6.19　障害情報を収集するための設定

6.20　構築したシステムの動作確認

6.21　系の最大数を変更する場合の動作確認（HAモニタ Extension使用時）

6.1　構築の流れ

HAモニタのインストールが完了したあと，システム管理者はスーパユーザの権限でシステムを構築します。

HAモニタのインストールから，各設定を終えてシステムの動作確認ができる状態になるまでのシステム構築の流れについて説明します。

＜この節の構成＞

(1)　システム構築の流れ

(2)　システム構築の流れ（HAモニタ Extension使用時）

(1)　システム構築の流れ

システム構築の流れを次の図に示します。なお，HAモニタ Extensionを使用する場合のシステム構築の流れについては，「(2)　システム構築の流れ（HAモニタ Extension使用時）」を参照してください。

図6-1　システム構築の流れ

システム構築の目的と，システム構築の流れで必要な手順との対応について説明します。

初めてHAモニタを導入してシステムを構築する場合
図中に示すすべての設定をします。

系を追加する場合
構築済みの系切り替え構成に系を追加する場合，図中に示すすべての設定をします。HAモニタは，各系に一つ必要です。
ただし，"HAモニタで使用するためのVMware ESXiの設定"という項目は，VMware ESXiで仮想化する場合にだけ設定する項目です。

サーバを追加する場合
構築済みの系切り替え構成にサーバを追加する場合，図中に示す"サーバを追加する場合の設定"をします。"系を追加する場合の設定"は必要ありません。
また，"サーバの起動・停止・監視コマンドの作成"という項目は，追加するサーバがモニタモードのときだけに設定する項目です。サーバの起動コマンドの作成は必須で，サーバの停止・監視コマンドの作成は任意です。
"プログラムの再起動コマンドの作成"，"UAPの作成と設定"，および"定義ファイルの作成（モニタモードのプログラム）"という項目は，追加するサーバがモニタモードで，かつプログラム管理機能を使用するときだけに設定する項目です。

HAモニタのインストール方法，およびインストール時の注意事項については，リリースノートを参照してください。

また，構築済みのシステムで系やサーバを追加する手順については，「7.8.1　系を追加する」，または「7.8.2　サーバを追加する」を参照してください。

(2)　システム構築の流れ（HAモニタ Extension使用時）

HAモニタ Extensionを使用する場合のシステム構築の流れを次の図に示します。

図6-2　システム構築の流れ（HAモニタ Extension使用時）

システム構築の目的と，システム構築の流れで必要な手順との対応について説明します。

初めてHAモニタおよびHAモニタ Extensionを導入してシステムを構築する場合
図中に示すすべての設定をします。

系を追加する場合
HAモニタ Extensionを導入して，構築済みの系切り替え構成に系を追加する場合，系切り替え構成内のすべての系で，必要に応じて図中に示すすべての設定をします。
HAモニタおよびHAモニタ Extensionは，各系に一つずつ必要です。
ただし，"HAモニタで使用するためのVMware ESXiの設定"という項目は，VMware ESXiで仮想化する場合にだけ設定する項目です。

サーバを追加する場合
HAモニタ Extensionを導入して，構築済みの系切り替え構成にサーバを追加する場合，系切り替え構成内のすべての系で，図中に示す"サーバを追加する場合の設定"をします。"系を追加する場合の設定"は必要ありません。
また，"サーバの起動・停止・監視コマンドの作成"という項目は，追加するサーバがモニタモードのときだけに設定する項目です。サーバの起動コマンドの作成は必須で，サーバの停止・監視コマンドの作成は任意です。
"プログラムの再起動コマンドの作成"，"UAPの作成と設定"，および"定義ファイルの作成（モニタモードのプログラム）"という項目は，追加するサーバがモニタモードで，かつプログラム管理機能を使用するときだけに設定する項目です。

HAモニタおよびHAモニタ Extensionのインストール方法，ならびにインストール時の注意事項については，リリースノートを参照してください。

また，構築済みのシステムで系やサーバを追加する手順については，「7.8.1　系を追加する」，または「7.8.2　サーバを追加する」を参照してください。

6.2　ディレクトリ構成

HAモニタをインストールすると，/opt/hitachiの下にHAモニタのディレクトリHAmonが作成されます。

HAモニタをインストールしたあとのディレクトリ構成を，次の図に示します。

図6-3　ディレクトリ構成

HAモニタのディレクトリのうち，ユーザがファイルを作成，編集できるのは環境設定用ディレクトリだけです。ほかのディレクトリにあるファイルは編集しないでください。

6.3　OSの設定

HAモニタのインストールが完了したら，システム管理者はOSに対して，HAモニタを使用するために必要な設定をします。

＜この節の構成＞

6.3.1　環境変数の設定

6.3.2　システムファイルの設定

6.3.3　システムクロックの設定

6.3.4　DNSの設定

6.3.5　システムログファイルの設定

6.3.6　カーネルのパラメタの設定

6.3.7　出力言語種別の設定

6.3.8　セキュリティレベルの設定

6.3.9　ファイルシステムの設定

6.3.1　環境変数の設定

システム管理者の環境変数を設定します。設定する必要があるのは次の環境変数です。

PATH環境変数
HAモニタのコマンドを使用するために，PATH環境変数の設定をします。HAモニタのコマンドは，ディレクトリ/opt/hitachi/HAmon/bin/の下にあります。次のパスを追加してください。

/opt/hitachi/HAmon/bin

6.3.2　システムファイルの設定

システムファイルに，HAモニタがカーネルの起動後に自動起動し，カーネルの停止前に自動停止するように設定します。

HAモニタでは，HAモニタが自動起動・停止するために必要なスクリプト/etc/rc.d/init.d/HAmonを提供しています。OSのchkconfigコマンドを実行して，スクリプトを登録してください。

スクリプトの登録方法を，次に示します。

# /sbin/chkconfig --add HAmon

HAモニタの自動起動・停止の順番を変更するには，/etc/rc.d/init.d/HAmonファイルの先頭にある，chkconfig用制御文を修正します。制御文の詳細については，OSのchkconfigコマンドのオンラインヘルプを参照してください。

6.3.3　システムクロックの設定

システムクロックを設定して，すべてのマシンの時刻を合わせます。このとき，システムクロックは秒単位で戻さないようにしてください。HAモニタは，システムクロックを基に系間通信の起動通知パケットの整合性を判定します。

システムクロックは，必ずHAモニタの稼働前に設定してください。HAモニタの稼働中にシステムクロックを変更すると，HAモニタは，障害が発生したと誤って判定し，HAモニタ間の接続ができなくなったりするおそれがあります。

6.3.4　DNSの設定

DNSを使用する場合，ホスト名の優先度の設定が/etc/hostsファイルよりDNSの方が高いと，HAモニタの起動に時間が掛かるおそれがあります。そのため，ホスト名の優先度の設定は，DNSより/etc/hostsファイルの方を高くすることを推奨します。

6.3.5　システムログファイルの設定

HAモニタを使用する場合，障害調査のためsyslogファイルを出力するよう設定してください。

6.3.6　カーネルのパラメタの設定

同時に稼働できるサーバの最大数をデフォルトの16から変更する場合，またはHAモニタ Extensionを使用して系の最大数を33以上にする場合に，カーネルパラメタを変更する必要があります。カーネルパラメタの表示はOSのsysctlコマンドで，カーネルパラメタの変更は/etc/sysctl.confファイルを修正することでできます。

変更する必要があるカーネルパラメタ，および指定する値を，次に示します。カーネルパラメタのデフォルト値が，表に示す値を上回っている場合は，変更する必要はありません。二つのカーネルパラメタには，同じ値を指定してください。

表6-1　カーネルのパラメタの設定（サーバの最大数，または系の最大数をデフォルトから変更する場合）

変更する
カーネルパラメタ
指定する値

サーバの最大数を
64にする場合
サーバの最大数を
128以上にする場合
系の最大数を
33以上にする場合

net.core.rmem_max
303200以上

Linux（x86）の場合

1048576​以上

Linux（IPF）の場合

4194304​以上

Linux（x86）の場合

1048576​以上

Linux（IPF）の場合

該当しません。

net.core.wmem_max
303200以上

Linux（x86）の場合

1048576​以上

Linux（IPF）の場合

4194304​以上

Linux（x86）の場合

1048576​以上

Linux（IPF）の場合

該当しません。

6.3.7　出力言語種別の設定

メッセージの出力言語種別（英語または日本語）を設定します。

HAモニタのメッセージの出力言語種別は，カーネルのLANG環境変数に設定してある値に従います。

英語と日本語を切り替えたい場合，LANG環境変数を次のように設定し直してください。

英語出力の場合：LANG=C

日本語出力（EUC）の場合：LANG=ja_JP.eucJP

日本語出力（UTF-8）の場合：LANG=ja_JP.UTF-8

6.3.8　セキュリティレベルの設定

HAモニタの監視パスとリセットパスではUDP通信が行われます。HAモニタのUDP通信がファイアウォールによって阻害されないようにセキュリティレベルを設定してください。

6.3.9　ファイルシステムの設定

HAモニタをインストールしているファイルシステム（/opt/hitachi/HAmon）に対して，/etc/fstabファイルやmountコマンドでnosuidオプションを指定しないようにしてください。

6.4　リセットパスの設定（BladeSymphony）

使用するマシンの機種がBladeSymphonyの場合，系障害発生時にHAモニタが系のリセットをするためには，リセットパスを設定しておく必要があります。

設定には，HAモニタの環境設定コマンド（monsetupコマンド）を使用します。HAモニタの環境設定コマンド（monsetupコマンド）については，「9.　コマンド」の「monsetup（HAモニタの環境設定）」を参照してください。

＜この節の構成＞

6.4.1　設定に必要な情報（BladeSymphony）

6.4.2　設定値の例（BladeSymphony）

6.4.1　設定に必要な情報（BladeSymphony）

設定対象の系，およびSVPについて，次に示す情報が必要です。

図6-4　リセットパスの設定に必要な情報（BladeSymphony：VMware ESXiで仮想化しない場合）

図6-5　リセットパスの設定に必要な情報（BladeSymphony：VMware ESXiで仮想化する場合）

図中の各項目について説明します。

表6-2　リセットパスの設定に必要な情報（BladeSymphony）

図中の番号
設定に必要な情報
説明
備考

1
パーティション名
HAモニタの管理システム名を指定します。
パーティションを構成したときに設定した情報です。
SVPコマンドモードのHAコマンド※1で設定した，プロセサのパーティション名と同じ名称を設定してください。
N+Mコールドスタンバイ構成の場合は，リセットパスを共用する全系で異なる値を設定してください。

2
LPAR名※2
HAモニタが稼働するLPARのLPAR名を指定します。
LPARを構成したときに設定した情報です。
HVM制御スクリーンで設定したLPAR名称と同じ名称を指定してください。

3
リセットパスのIPアドレス
設定対象の系に割り当てたリセットパスのIPアドレスを指定します。
IPアドレス，およびポート番号の割り当て方については，「5.4.2　必要なIPアドレス」を参照してください。
SVPのIPアドレスに"auto"を指定する場合は，N+Mコールドスタンバイ機能に対応したシステム構成で稼働するための設定として，SVPコマンドモードのHAコマンド※1で"Enable"を設定してください。

4
リセットパスのポート番号
設定対象の系に割り当てたリセットパスのポート番号を指定します。

5
SVPのIPアドレス
SVPに割り当てたリセットパスのIPアドレスを指定します。
N+Mコールドスタンバイ構成の場合は，"auto"を指定します。

6
SVPのポート番号
SVPに割り当てたリセットパスのポート番号を指定します。

7
マシンアドレス※3
HAモニタが稼働する物理パーティション（プロセサ）を示す任意の番号を指定します。
同じ物理パーティション上の系と同じ値で，かつ異なる物理パーティション上の系とは異なる値を指定してください。
リセットパスを共用する全物理パーティション間で重複しないよう，値を設定してください。

8
VMware ESXiのIPアドレス※3
VMware ESXiの管理用IPアドレスを指定します。
IPアドレスおよびポート番号の割り当て方については，「5.4.2　必要なIPアドレス」を参照してください。

9
VMware ESXiのポート番号※3
VMware ESXiにSSH接続用に割り当てたポート番号を指定します。

10
パスワード※3，※4
自系のVMware ESXiにSSH接続する際の認証に必要なパスワードを指定します。
系切り替え構成内では，同じパスワードを指定してください。

11
仮想マシン名※3
VMware ESXiで管理する，仮想マシン名を指定します。
VMware ESXiで仮想マシンを作成したときに設定した情報です。VMware vSphere ClientまたはvCenterで確認した名称と同じ名称を指定してください。
また，仮想マシン名は，HAモニタが接続できるすべてのVMware ESXi内で一意にしてください。
仮想マシン名の確認方法を次に示します。

仮想マシンのゲストOS上でifconfigコマンドを実行し，MACアドレスなど仮想マシン固有の情報をメモします。

VMware vSphere ClientでVMware ESXiに接続します。

仮想マシンの設定を編集する画面を開き，手順1.でメモした仮想マシン固有の情報が一致する仮想マシンを探します。

注※1

SVPコマンドモードのHAコマンドについては，SVP関連のドキュメントを参照してください。

注※2

日立サーバ仮想化機構を利用してLPARモードで系切り替え構成にする場合だけに必要な情報です。

注※3

VMware ESXiで仮想化する場合だけに必要な情報です。

注※4

HAモニタは，自系のVMware ESXiにSSH接続するためのパスワードを，独自の形式でローカルディスクに保持します。パスワードはroot以外のユーザが参照できないよう保持していますが，必要に応じて外部ネットワークからローカルディスクを物理的に切り離すなどのセキュリティ対策を検討してください。

構成によっては，ホストアドレスの設定（HAモニタの環境設定のaddressオペランド）に注意が必要です。詳細については「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

また，相互系切り替え構成でリセット優先系を指定しない場合は，SVPコマンドモードのHAコマンドでクラスタ管理機能の設定が必要です。SVPコマンドモードのHAコマンドについては，SVP関連のドキュメントを参照してください。

6.4.2　設定値の例（BladeSymphony）

マシンの機種がBladeSymphonyの場合の，リセットパスの設定値の例を説明します。ここで示す表にある「設定項目」は，表6-2の「設定に必要な情報」と対応しています。

＜この項の構成＞

(1)　2シャーシ／2系（Basicモード）の構成

(2)　1シャーシ／2系（LPARモード）の構成

(3)　2シャーシ／4系（Basicモード）の構成

(4)　4シャーシ／4系（Basicモード）の構成

(5)　VMware ESXiで仮想化する構成

(6)　N+Mコールドスタンバイ構成

(7)　相互系切り替え構成（リセット優先系を指定しない）

(1)　2シャーシ／2系（Basicモード）の構成

次のような構成（系1・系2間で系切り替え）の場合に，monsetupコマンドで設定する値の例を示します。

図6-6　リセットパスの設定例1（BladeSymphony）

設定項目 | 系ごとの設定値
系1 | 系2
パーティション名 | MS0001 | MS0002
リセットパスのIPアドレス | x.x.x.a | x.x.x.b
リセットパスのポート番号 | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.d
SVPのポート番号 | qqqqq | qqqqq

(2)　1シャーシ／2系（LPARモード）の構成

次のような構成（系1・系2間で系切り替え）の場合に，monsetupコマンドで設定する値の例を示します。

図6-7　リセットパスの設定例2（BladeSymphony）

設定項目 | 系ごとの設定値
系1 | 系2
パーティション名 | MS0001 | MS0001
LPAR名 | LPAR1 | LPAR2
リセットパスのIPアドレス | x.x.x.a | x.x.x.b
リセットパスのポート番号 | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.c
SVPのポート番号 | qqqqq | qqqqq

(3)　2シャーシ／4系（Basicモード）の構成

ここでは，次の条件で運用するシステムでのリセットパスの設定値の例について説明します。

システム内に，互いに監視し合わない1:1系切り替え構成が二組ある。

二組の系切り替え構成がリセットパスを共用している。

二組の系切り替え構成がSVPを共用している。

注意

ここで説明する系切り替え構成の場合，ホストアドレスの設定（HAモニタの環境設定のaddressオペランド）に注意が必要です。詳細は「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

これらの条件を満たす，次のような構成（系1・系3間，系2・系4間で系切り替え）の場合に，monsetupコマンドで設定する値の例を次に示します。

図6-8　リセットパスの設定例3（BladeSymphony）

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
パーティション名 | MS0001 | MS0002 | MS0003 | MS0004
リセットパスのIPアドレス | x.x.x.a | x.x.x.b | x.x.x.d | x.x.x.e
リセットパスのポート番号 | ppppp | ppppp | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.c | x.x.x.f | x.x.x.f
SVPのポート番号 | qqqqq | qqqqq | qqqqq | qqqqq

この系切り替え構成の場合に，HAモニタの環境設定のaddressオペランドに設定する値の例を次に示します。

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
自系のホストアドレス | 1 | 2 | 3 | 4

(4)　4シャーシ／4系（Basicモード）の構成

ここでは，次の条件で運用するシステムでのリセットパスの設定値の例について説明します。

システム内に，互いに監視し合わない1:1系切り替え構成が二組ある。

二組の系切り替え構成がリセットパスを共用している。

二組の系切り替え構成がSVPを共用していない。

注意

ここで説明する系切り替え構成の場合，ホストアドレスの設定（HAモニタの環境設定のaddressオペランド）に注意が必要です。詳細は「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

これらの条件を満たす，次のような構成（系1・系3間，系2・系4間で系切り替え）の場合に，monsetupコマンドで設定する値の例を次に示します。

図6-9　リセットパスの設定例4（BladeSymphony）

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
パーティション名 | MS0001 | MS0002 | MS0003 | MS0004
リセットパスのIPアドレス | x.x.x.a | x.x.x.c | x.x.x.e | x.x.x.g
リセットパスのポート番号 | ppppp | rrrrr | ppppp | rrrrrr
SVPのIPアドレス | x.x.x.b | x.x.x.d | x.x.x.f | x.x.x.h
SVPのポート番号 | qqqqq | sssss | qqqqq | sssss

この系切り替え構成の場合に，HAモニタの環境設定のaddressオペランドに設定する値の例を次に示します。

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
自系のホストアドレス | 1 | 2 | 3 | 4

(5)　VMware ESXiで仮想化する構成

ここでは，次の条件で運用するシステムのリセットパスの設定値の例について説明します。

VMware ESXiで仮想化する構成である。

システムに，互いに監視し合わない1:1系切り替え構成が二組ある。

二組の系切り替え構成がリセットパスを共用している。

二組の系切り替え構成がSVPを共用している。

これらの条件を満たす，次のような構成（系1・系3間，系2・系4間で系切り替え，系1・系2・系3がVMware ESXiの管理上にある）の場合に，monsetupコマンドで設定する値の例を次に示します。

図6-10　リセットパスの設定例5（BladeSymphony）

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
パーティション名 | MS0001 | MS0001 | MS0002 | MS0003
リセットパスのIPアドレス | x.x.x.a | x.x.x.b | x.x.x.d | x.x.x.e
リセットパスのポート番号 | ppppp | ppppp | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.c | x.x.x.f | x.x.x.f
SVPのポート番号 | qqqqq | qqqqq | qqqqq | qqqqq
マシンアドレス | 1 | 1 | 2 | －
VMware ESXiのIPアドレス | y.y.y.a | y.y.y.a | y.y.y.b | －
VMware ESXiのポート番号 | default※ | default※ | rrrrr | －
仮想マシン名 | VM0001 | VM0002 | VM0003 | －

（凡例）－：設定は不要です。

注※　SSH接続用ポート番号（22）を使用する場合，"default"と設定してください。

この構成の場合は，系切り替え構成内のすべての系で，HAモニタの環境設定（sysdef）のvmware_envオペランドにuseを設定してください。

また，系切り替え構成内のすべての系で，monsetup -resetpath sshコマンドで，接続維持パケットの送信間隔に20を設定してください。

(6)　N+Mコールドスタンバイ構成

ここでは，次の条件で運用するシステムのリセットパスの設定値の例について説明します。

N+Mコールドスタンバイ構成である。

1:1系切り替え構成である。

系3として，予備のサーバモジュールが存在する。

注意

ここで説明する系切り替え構成の場合，ホストアドレスの設定（HAモニタの環境設定のaddressオペランド）に注意が必要です。詳細は「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

これらの条件を満たす，次のような構成（系1・系2間で系切り替え，系3が予備のサーバモジュール）の場合に，システムに設定される値の例を次に示します。

図6-11　リセットパスの設定例6（BladeSymphony）

上記のような設定をするために，monsetupコマンドで指定する値の例を次に示します。

設定項目 | 系ごとの設定値
系1 | 系2 | 系3
パーティション名 | MS0001 | MS0002 | －
リセットパスのIPアドレス | x.x.x.a | x.x.x.b | －
リセットパスのポート番号 | ppppp | ppppp | －
SVPのIPアドレス | auto | auto | －
SVPのポート番号 | qqqqq | qqqqq | －

（凡例）－：設定は不要です。

この系切り替え構成の場合に，SVPコマンドモードのHAコマンドで設定する値の例を次に示します。

設定項目 | SVPごとの設定値
系1のSVP | 系2のSVP | 系3のSVP
SVPのポート番号 | qqqqq | qqqqq | qqqqq
パーティション名 | MS0001 | MS0002 | －
N+Mコールドスタンバイ機能に対応したシステム構成で稼働するための設定 | Enable | Enable | Enable

（凡例）－：設定は不要です。

(7)　相互系切り替え構成（リセット優先系を指定しない）

ここでは，次の条件で運用するシステムのリセットパスの設定値の例について説明します。

相互系切り替え構成である。

リセット優先系を指定しない（HAモニタの環境設定のcpudownオペランドでsystemを指定している）。

これらの条件を満たす，次のような構成（系1・系2間で系切り替え）の場合に，システムに設定される値の例を次に示します。

図6-12　リセットパスの設定例7（BladeSymphony）

上記のような設定をするために，monsetupコマンドで指定する値の例を次に示します。

設定項目 | 系ごとの設定値
系1 | 系2
パーティション名 | MS0001 | MS0002
リセットパスのIPアドレス | x.x.x.a | x.x.x.b
リセットパスのポート番号 | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.d
SVPのポート番号 | qqqqq | qqqqq

この系切り替え構成の場合に，SVPコマンドモードのHAコマンドで設定する値の例を次に示します。

設定項目 | SVPごとの設定値
系1のSVP | 系2のSVP
クラスタ管理機能 | 有効 | 有効
クラスタマネージャ | 有効※ | 無効

注※　システム内のSVPの，どれか一つだけに「有効」を設定します。

6.5　リセットパスの設定（HA8000）

使用するマシンの機種がHA8000の場合，系障害発生時にHAモニタが系のリセットをするためには，リセットパスを設定しておく必要があります。

設定には，HAモニタの環境設定コマンド（monsetupコマンド）を使用します。HAモニタの環境設定コマンド（monsetupコマンド）については，「9.　コマンド」の「monsetup（HAモニタの環境設定）」を参照してください。

＜この節の構成＞

6.5.1　設定に必要な情報（HA8000）

6.5.2　設定値の例（HA8000）

6.5.1　設定に必要な情報（HA8000）

設定対象の系，およびSVPについて，次に示す情報が必要です。

図6-13　リセットパスの設定に必要な情報（HA8000：VMware ESXiで仮想化しない場合）

図6-14　リセットパスの設定に必要な情報（HA8000：VMware ESXiで仮想化する場合）

図中の各項目について説明します。

表6-3　リセットパスの設定に必要な情報（HA8000）

図中の番号
設定に必要な情報
説明
備考

1
パーティション名
HAモニタが稼働するパーティションの管理システム名を指定します。
任意の名称を1～31文字の英数字で指定してください。
－

2
リセットパスのIPアドレス
設定対象の系に割り当てたリセットパスのIPアドレスを指定します。
IPアドレス，およびポート番号の割り当て方については，「5.4.2　必要なIPアドレス」を参照してください。

3
リセットパスのポート番号
設定対象の系に割り当てたリセットパスのポート番号を指定します。

4
SVPのIPアドレス
SVPに割り当てたリセットパスのIPアドレスを指定します。

5
SVPのポート番号
SVPに割り当てたリセットパスのポート番号を指定します。

6
マシンアドレス※1
HAモニタが稼働する物理パーティション（プロセサ）を示す任意の番号を指定します。
同じ物理パーティション上の系と同じ値で，かつ異なる物理パーティション上の系とは異なる値を設定してください。
リセットパスを共用する全物理パーティション間で重複しないよう，値を設定してください。

7
VMware ESXiのIPアドレス※1
VMware ESXiの管理用IPアドレスを指定します。
IPアドレスおよびポート番号の割り当て方については，「5.4.2　必要なIPアドレス」を参照してください。

8
VMware ESXiのポート番号※1，※2
VMware ESXiにSSH接続用に割り当てたポート番号を指定します。

9
パスワード※1
自系のVMware ESXiにSSH接続する際の認証に必要なパスワードを指定します。
系切り替え構成内では，同じパスワードを指定してください。

10
仮想マシン名※1
VMware ESXiで管理する，仮想マシンの名を指定します。
VMware ESXiで仮想マシンを作成したときに設定した情報です。VMware ClientまたはvCenterで確認した名称と同じ名称を指定してください。
また，仮想マシン名は，HAモニタが接続できるすべてのVMware ESXi内で一意にしてください。
仮想マシン名の確認方法を次に示します。

仮想マシンのゲストOS上でifconfigコマンドを実行し，MACアドレスなど仮想マシン固有の情報をメモします。

VMware vSphere ClientでVMware ESXiに接続します。

仮想マシンの設定を編集する画面を開き，手順1.でメモした仮想マシン固有の情報が一致する仮想マシンを探します。

（凡例）

－：備考はありません。

注※1

VMware ESXiで仮想化する場合だけに必要な情報です。

注※2

パスワードはroot以外のユーザが参照できないよう保持していますが，必要に応じて外部ネットワークからローカルディスクを物理的に切り離すなどのセキュリティ対策を検討してください。

6.5.2　設定値の例（HA8000）

マシンの機種がHA8000の場合の，リセットパスの設定値の例を示します。ここで示す表にある「設定項目」は，表6-3の「設定に必要な情報」と対応しています。

＜この項の構成＞

(1)　系切り替え構成が一組の場合

(2)　系切り替え構成が二組の場合

(3)　VMware ESXiで仮想化する構成

(1)　系切り替え構成が一組の場合

次のような構成（系1・系2間で系切り替え）の場合に，monsetupコマンドで設定する値の例を示します。

図6-15　リセットパスの設定例1（HA8000）

設定項目 | 系ごとの設定値
系1 | 系2
パーティション名 | MS0001 | MS0002
リセットパスのIPアドレス | x.x.x.a | x.x.x.b
リセットパスのポート番号 | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.d
SVPのポート番号 | qqqqq | qqqqq

(2)　系切り替え構成が二組の場合

ここでは，次の条件で運用するシステムでのリセットパスの設定値の例について説明します。

システム内に，互いに監視し合わない1:1系切り替え構成が二組ある。

二組の系切り替え構成がリセットパスを共用している。

二組の系切り替え構成がSVPを共用していない。

注意

ここで説明する系切り替え構成の場合，ホストアドレスの設定（HAモニタの環境設定のaddressオペランド）に注意が必要です。詳細は「5.5.4(2)　系切り替え構成間でリセットパスを共用する場合の注意事項」を参照してください。

これらの条件を満たす，次のような構成（系1・系3間，系2・系4間で系切り替え）の場合に，monsetupコマンドで設定する値の例を次に示します。

図6-16　リセットパスの設定例2（HA8000）

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
パーティション名 | MS0001 | MS0002 | MS0003 | MS0004
リセットパスのIPアドレス | x.x.x.a | x.x.x.c | x.x.x.e | x.x.x.g
リセットパスのポート番号 | ppppp | rrrrr | ppppp | rrrrrr
SVPのIPアドレス | x.x.x.b | x.x.x.d | x.x.x.f | x.x.x.h
SVPのポート番号 | qqqqq | sssss | qqqqq | sssss

この系切り替え構成の場合に，HAモニタの環境設定のaddressオペランドに設定する値の例を次に示します。

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
自系のホストアドレス | 1 | 2 | 3 | 4

(3)　VMware ESXiで仮想化する構成

ここでは，次の条件で運用するシステムのリセットパスの設定値の例について説明します。

VMware ESXiで仮想化する構成である。

システムに，互いに監視し合わない1:1系切り替え構成が二組ある。

二組の系切り替え構成がリセットパスを共用している。

一組の系切り替え構成がSVPを共用している。

これらの条件を満たす，次のような構成（系1・系3間，系2・系4間で系切り替え，系1・系2・系3がVMware ESXiの管理上にある）の場合に，monsetupコマンドで設定する値の例を次に示します。

図6-17　リセットパスの設定例3（HA8000）

設定項目 | 系ごとの設定値
系1 | 系2 | 系3 | 系4
パーティション名 | MS0001 | MS0001 | MS0002 | MS0003
リセットパスのIPアドレス | x.x.x.a | x.x.x.b | x.x.x.d | x.x.x.f
リセットパスのポート番号 | ppppp | ppppp | ppppp | ppppp
SVPのIPアドレス | x.x.x.c | x.x.x.c | x.x.x.e | x.x.x.g
SVPのポート番号 | qqqqq | qqqqq | qqqqq | qqqqq
マシンアドレス | 1 | 1 | 2 | －
VMware ESXiのIPアドレス | y.y.y.a | y.y.y.a | y.y.y.b | －
VMware ESXiのポート番号 | default※ | default※ | rrrrr | －
仮想マシン名 | VM0001 | VM0002 | VM0003 | －

（凡例）－：設定は不要です。

注※　SSH接続用ポート番号（22）を使用する場合，"default"と設定してください。

この構成の場合は，系切り替え構成内のすべての系でHAモニタの環境設定（sysdef）のvmware_envオペランドにuseを設定してください。

また，系切り替え構成内のすべての系で，monsetup -resetpath sshコマンドで，接続維持パケットの送信間隔に20を設定してください。

6.6　障害管理プロセサの設定（HA8500）

使用するマシンの機種がHA8500の場合，系障害発生時にHAモニタが系のリセットをするためには，障害管理プロセサを設定しておく必要があります。

系障害が発生すると，HAモニタは，LANを経由して障害が発生した系の障害管理プロセサに接続して，リセットを指示します。ここでは，使用するマシンの機種がHA8500の場合の，HAモニタが障害管理プロセサに接続して系のリセットをするために必要な設定について説明します。すべての系の障害管理プロセサに対してこれらの設定をしてください。

＜この節の構成＞

6.6.1　LANポートの設定（HA8500）

6.6.2　障害管理プロセサのIPアドレスの登録（HA8500）

6.6.3　HAモニタのリセット手順ファイルの設定（HA8500）

6.6.1　LANポートの設定（HA8500）

系障害が発生すると，HAモニタは，LANを経由して障害が発生した系の障害管理プロセサに接続し，リセットを指示します。このとき，HAモニタは，LANポートを使用して障害管理プロセサに接続します。そのため，HAモニタが障害管理プロセサ用のLANポートを使用できるように，次の設定をしてください。障害管理プロセサの設定方法の詳細については，ハードウェアのマニュアルまたはオンラインヘルプを参照してください。

障害管理プロセサ用のLANポートを使用できるように設定する。
デフォルトでは，LANポートは使用できない設定になっているため，使用できる設定になっていることを事前に確認してください。

障害管理プロセサに，LANポートを使用するための情報を設定する。
HAモニタが障害管理プロセサのLANポートを使用できるように，障害管理プロセサに次の情報を設定します。

表6-4　LANポートを使用するための障害管理プロセサの設定情報（HA8500）

項目 | 設定値 | 備考
IPアドレス | リセットパスと同じネットワークアドレスを持つIPアドレス | この指定値に対応するホスト名をHAモニタの環境設定のnameオペランドに設定してください。
サブネットマスク | リセットパスのサブネットマスク | －
ゲートウェイアドレス | 指定しない（推奨） | リセットパスは，専用LANにすることを推奨します。
ホスト名 | 任意 | －
ログイン名 | デフォルト値※（推奨） | 変更する場合は，リセット手順ファイルを書き換える必要があります。
パスワード | デフォルト値※（推奨） | 変更する場合は，リセット手順ファイルを書き換える必要があります。

（凡例）－：備考はありません。

注※　デフォルト値は，機種によって異なります。

注意

HAモニタの稼働中に障害管理プロセサの構成を変更しないでください。HAモニタの稼働中にローカルコンソール，リモートコンソール，または障害管理プロセサを操作すると，リセット処理が遅延または失敗することがあります。ローカルコンソール，リモートコンソール，または障害管理プロセサを不用意に操作しないでください。

6.6.2　障害管理プロセサのIPアドレスの登録（HA8500）

HAモニタの環境設定のnameオペランドに指定したホスト名と，それに対応する障害管理プロセサのIPアドレスを/etc/hostsファイルに登録する必要があります。/etc/hostsファイルには自系のホストだけではなく，システムリセット対象となるホストをすべて登録してください。

自系を含めた，接続するすべてのHAモニタのホストを登録しておくことを推奨します。

6.6.3　HAモニタのリセット手順ファイルの設定（HA8500）

HAモニタでは，系のリセットをするために，リセット手順を記述したリセット手順ファイルを作成する必要があります。リセット手順ファイルは，リセットする相手の系が使用しているマシンのモデルごとに異なります。

HAモニタは，ホスト名.rspというリセット手順ファイルがある場合はホスト名.rspに示された手順を，ホスト名.rspがない場合はdefault.rspに示された手順を使用して，リセットを実行します。

＜この項の構成＞

(1)　HAモニタのリセット手順ファイルの作成方法

(2)　HAモニタのリセット手順ファイルの編集

(1)　HAモニタのリセット手順ファイルの作成方法

HAモニタのサンプルファイル用ディレクトリの下に，マシンのモデルに対応したリセット手順ファイル（拡張子は「.rsp」）が用意されています。

自系のマシンのモデルに合ったリセット手順ファイルを，HAモニタ環境設定用ディレクトリの下にコピーして，ファイル名をdefault.rspに変更してください。リセット手順ファイルのサンプルファイルをコピーするときは，自系で使用しているマシンのモデルを確認の上，正しいサンプルファイルを使用してください。

他系に，自系と異なるモデルの系がある場合，default.rspのほかにリセット手順ファイルを用意する必要があります。他系で使用しているモデルに合ったリセット手順ファイルをHAモニタ環境設定用ディレクトリの下にコピーして，ファイル名をホスト名.rspに変更してください。

リセット手順ファイルの作成例を次に示します。この構成例では，三つの系を準備し，各系が他系をリセットすることを想定しています。また，host1およびhost2のマシンのモデルは同じで，host3のマシンのモデルが異なります。

図6-18　リセット手順ファイルの作成例（HA8500）

host1およびhost2では，自系で使用しているマシンのモデルに合ったMP.rspをコピーして，default.rspに変更します。この系切り替え構成では，host1/host2とhost3のマシンのモデルが異なるため，host3のマシンのモデルに合ったBMC.rspをコピーして，host3.rspに変更します。

host3では，自系のマシンのモデルに合ったBMC.rspをコピーして，default.rspに変更します。この系切り替え構成では，host3とhost1/host2のマシンのモデルが異なるため，host1およびhost2のマシンのモデルに合ったMP.rspをコピーして，それぞれhost1.rspおよびhost2.rspに変更します。

(2)　HAモニタのリセット手順ファイルの編集

通常はリセット手順ファイルを編集する必要はありません。ただし，MPのログイン名，パスワード，またはホスト名を変更する場合，リセット手順ファイルを編集する必要があります。なお，MPのホスト名は，リセット手順ファイルがBMC.rspの場合だけ変更できます。

HAモニタでは，MPに対してシステム管理者権限のアクセスレベルが必要です。リセット手順ファイルには，MPに対してシステム管理者権限を持つユーザのログイン名とパスワードを設定してください。MPのアクセスレベルについては，ハードウェアのマニュアルを参照してください。

次にリセット手順ファイルの編集方法を示します。

ログイン名，パスワードを変更する場合

「ログイン名」「パスワード」と記載されている部分を変更してください。設定するログイン名，およびパスワードの最後に"¥n"を必ず定義してください。

:
# The reception of login prompt
R:login:
S:ログイン名¥n

# The reception of password prompt
R:password:
S:パスワード¥n
:

ホスト名を変更する場合

「MPホスト名」と記載されている部分を変更してください。設定するMPホスト名の最後に">"を必ず定義してください。

:
# The definition of the BMC prompt strings
PROMPT:MPホスト名>
:
# The reception of BMC command prompt
R: MPホスト名>
S:RS¥n
:

6.7　HAモニタで使用するためのVMware ESXiの設定

HAモニタで使用するためのVMware ESXiの設定をします。

＜この節の構成＞

(1)　VMware ESXiのパスワードの設定

(2)　VMware ESXiへのSSH接続のための設定

(3)　vCenterで管理する場合の設定

(1)　VMware ESXiのパスワードの設定

系切り替え構成内で，rootユーザのパスワードが，他系のVMware ESXiと一致するように設定してください。

(2)　VMware ESXiへのSSH接続のための設定

VMware ESXiにSSH接続するのための設定が必要です。設定方法を次に示します。

VMware ESXiのコンソール画面を起動し，ログインする。

"Troubleshooting Options"を選択し，[Enter]キーを押す。

"Troubleshooting Mode Options"のメニューから，"Enable Remote Tech Support (SSH)"を選択し，[Enter]キーを押す。

VMware ESXiからログアウトする。

(3)　vCenterで管理する場合の設定

vCenterで管理する場合，vCenterのロール設定でサスペンド操作をできない設定にすることを推奨します。

注意

VMware ESXiの仮想化環境で使用する場合，HAモニタの稼働中に仮想マシンをサスペンドしないでください。詳細については，リリースノートを参照してください。

6.8　監視パスの設定

HAモニタが系間の監視をしたり，系切り替えのための情報を交換したりするために，監視パスの設定をします。

＜この節の構成＞

6.8.1　ホスト名とサービス名の登録

6.8.2　HAモニタの接続構成設定ファイルの作成

6.8.1　ホスト名とサービス名の登録

監視パスに使用するTCP/IP LANのホスト名とサービス名を登録します。登録する必要があるのは，次のファイルです。

/etc/hostsファイル

/etc/servicesファイル

登録するホスト名とサービス名は，HAモニタの環境設定でも同じ名称を設定します。ここでは，登録する内容，およびファイルの設定例について説明します。/etc/hostsファイルおよび/etc/servicesファイルへの指定の追加方法については，OSのマニュアルを参照してください。

＜この項の構成＞

(1)　ホスト名の登録

(2)　サービス名の登録

(3)　ファイルの設定例

(4)　ファイルの設定例（HAモニタ Extensionを使用し，マルチキャストでaliveメッセージを送受信する場合）

(1)　ホスト名の登録

/etc/hostsファイルに，すべての監視パスに使用するTCP/IP LANのホスト名を指定します。ホスト名は，系ごとに固有にしてください。また，IPアドレスには，エイリアスIPアドレスを指定しないでください。

/etc/hostsファイルには，監視パスで接続されている他系のHAモニタのIPアドレスおよびホスト名も指定してください。指定しないと，監視パス状態表示コマンド（monpath -iコマンド）を実行したときに，IPアドレスに対応するホスト名が表示されません。

HAモニタ Extensionを使用して系の最大数を変更し，マルチキャストでaliveメッセージを送受信する場合に，任意のマルチキャストグループIDを指定するときは，マルチキャストグループID，およびマルチキャストグループIDに対応するホスト名を/etc/hostsファイルに指定してください。

(2)　サービス名の登録

/etc/servicesファイルに，すべての監視パスに使用するTCP/IP LANのサービス名を指定します。系切り替え構成内のすべての系で同じ名称にしてください。

また，ポート番号の値は5001以上のシステムで未使用の番号とし，すべての系で同じポート番号を指定してください。プロトコル名にはudpを指定してください。

(3)　ファイルの設定例

次に示すファイルの設定例について説明します。

/etc/hostsファイル

/etc/servicesファイル

HAモニタの環境設定（sysdef）

HAモニタ Extensionを使用して系の最大数を変更し，マルチキャストでaliveメッセージを送受信する場合のファイルの設定例については，「(4)　ファイルの設定例（HAモニタ Extensionを使用し，マルチキャストでaliveメッセージを送受信する場合）」を参照してください。

(a)　設定例で示す監視パスの構成

この設定例では，監視パスは次の図のように構成されていることを想定しています。

図6-19　監視パスの構成例

(b)　/etc/hostsファイルの設定例

/etc/hostsファイルの設定例を，次に示します。系1と系2で同じ内容を設定します。

# IPアドレス       ホスト名
192.168.0.11        path11
192.168.1.11        path12
192.168.0.12        path21
192.168.1.12        path22

系1で使用している監視パスとしてpath11とpath12を指定します。また，系2で使用している監視パスとしてpath21とpath21を指定します。

(c)　/etc/servicesファイルの設定例

/etc/servicesファイルの設定例を，次に示します。系1と系2で同じ内容を設定します。

# サービス名     ポート番号/プロトコル名
HAmon1           7777/udp
HAmon2           7778/udp

監視パスを二重化するため，HAmon1およびHAmon2の二つのサービスを指定します。

(d)　HAモニタの環境設定例

HAモニタの環境設定（/opt/hitachi/HAmon/etc/sysdef）の設定例を次に示します。系1と系2で設定する内容は異なります。なお，この例では，ホスト名とサービス名の登録に関係する部分だけを抜き出して記載しています。

系1の設定例

environment
  lan     path11:path12,
  lanport HAmon1:HAmon2
;

系2の設定例

environment
  lan     path21:path22,
  lanport HAmon1:HAmon2
;

lanオペランドには/etc/hostsファイルに指定した監視パス名を，lanportオペランドには/etc/servicesファイルに指定したサービス名を指定します。lanオペランドおよびlanportオペランドに指定する値は，順番をそろえてください。この構成例では，path11やpath21の監視パスがHAmon1というサービスと対応しているため，両オペランドの最初に指定します。

lanオペランドやlanportオペランドの詳細については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

(4)　ファイルの設定例（HAモニタ Extensionを使用し，マルチキャストでaliveメッセージを送受信する場合）

HAモニタ Extensionを使用して系の最大数を変更し，マルチキャストでaliveメッセージを送受信する場合の，次に示すファイルの設定例について説明します。

/etc/hostsファイル

/etc/servicesファイル

HAモニタの環境設定（sysdef）

(a)　設定例で示す監視パスの構成

この設定例では，監視パスは次の図のように構成されていることを想定しています。

図6-20　監視パスの構成例

(b)　/etc/hostsファイルの設定例

/etc/hostsファイルの設定例を，次に示します。系1と系2で同じ内容を設定します。

# IPアドレス       ホスト名
192.168.0.11        path11
192.168.1.11        path12
192.168.0.12        path21
192.168.1.12        path22
239.1.1.1           alive_id

系1で使用している監視パスとしてpath11とpath12を指定します。系2で使用している監視パスとしてpath21とpath22を指定します。

また，この設定例では任意のマルチキャストグループIDを指定するため，マルチキャストグループIDとして239.1.1.1を，マルチキャストグループIDに対応するホスト名としてalive_idを指定します。

(c)　/etc/servicesファイルの設定例

/etc/servicesファイルの設定例を，次に示します。系1と系2で同じ内容を設定します。

# サービス名     ポート番号/プロトコル名
HAmon1           7777/udp
HAmon2           7778/udp

監視パスを二重化するため，HAmon1およびHAmon2の二つのサービスを指定します。

(d)　HAモニタの環境設定例

HAモニタの環境設定（/opt/hitachi/HAmon/etc/sysdef）の設定例を次に示します。系1と系2で設定する内容は異なります。なお，この例では，HAモニタ Extensionを使用し，マルチキャストでaliveメッセージを送受信する場合の，ホスト名とサービス名の登録に関係する部分だけを抜き出して記載しています。

系1の設定例

environment
  lan               path11:path12,
  lanport           HAmon1:HAmon2,
  hostmax           33,
  alive_multicast   use,
  multicast_lan     alive_id
;

系2の設定例

environment
  lan               path21:path22,
  lanport           HAmon1:HAmon2,
  hostmax           33,
  alive_multicast   use,
  multicast_lan     alive_id
;

lanオペランドには/etc/hostsファイルに指定した監視パス名を，lanportオペランドには/etc/servicesファイルに指定したサービス名を指定します。lanオペランドおよびlanportオペランドに指定する値は，順番をそろえてください。この構成例では，path11やpath21の監視パスがHAmon1というサービスと対応しているため，両オペランドの最初に指定します。

hostmaxオペランドには，一つの系切り替え構成での系の最大数を指定します。この設定例では系の最大数として33以上を指定するため，alive_multicastオペランドにuseを指定しなくても，aliveメッセージはマルチキャストで送受信されます。

また，multicast_lanオペランドには，マルチキャストグループIDに対応するホスト名として，alive_idを指定します。

各オペランドの詳細については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

6.8.2　HAモニタの接続構成設定ファイルの作成

HAモニタは系に一つ存在し，系間で連絡を取ります。システム構築時には，HAモニタの接続構成を，定義ファイルに定義する必要があります。この定義ファイルをHAモニタの接続構成設定ファイルと呼びます。

HAモニタの接続構成設定ファイルは，HAモニタの起動時に参照され，HAモニタの接続構成設定ファイルの内容に基づいて，HAモニタ同士が接続されます。また，HAモニタの起動時，および定義チェックコマンド（moncheckコマンド）実行時に，HAモニタの接続構成設定ファイルの内容がチェックされます。

＜この項の構成＞

(1)　HAモニタの接続構成設定ファイルの作成方法

(2)　手動作成する方法

(3)　作成例

(1)　HAモニタの接続構成設定ファイルの作成方法

HAモニタの接続構成設定ファイルを作成するには，自動作成する方法と，手動作成する方法があります。通常は，自動作成することをお勧めします。ただし，次のどちらかの場合は，手動作成してください。

自系と特定の系とを監視し合うように，監視パスを設定したい場合
ユーザがHAモニタの接続構成設定ファイルにpairオプションを指定する必要があるためです。

HAモニタの接続構成を変更・削除する場合
HAモニタを追加する場合は，自動作成できます。

ここでは，HAモニタの接続構成設定ファイルを手動作成する方法についてだけ説明します。自動作成の場合，システムの構築が完了して動作確認をするときに同時にHAモニタの接続構成設定ファイルを作成できるため，ここでは説明しません。HAモニタの接続構成設定ファイルを自動作成する方法については，「6.20.1(3)　HAモニタの停止確認および接続構成設定ファイルの確認（自動作成の場合）」を参照してください。

(2)　手動作成する方法

HAモニタの接続構成設定ファイルは，HAモニタの環境設定用ディレクトリの下にconnectionというファイル名で作成します。connectionファイルを一つの系で作成し，他系に複写する方法をお勧めします。

HAモニタの接続構成設定ファイルで設定する各パラメタの記述形式を，次に示します。

△₀ホスト名△₁LAN△₁IPアドレス△₁pair;↓

（凡例）

△₀：0個以上の空白またはタブを示します。

△₁：1個以上の空白またはタブを示します。

↓：改行コードを示します。

行の最後には，";"を記述してください。1行で系一つ分の設定項目を記述できます。系が四つある場合には，4行記述する必要があります。

なお，"#"を記述すると，"#"から改行コードまでがコメント行になります。

注意

pairを指定している接続構成設定ファイルの内容に誤りがあると，系間の接続構成を認識できなくなるため，正しく系切り替えができなくなります。

pairを指定している接続構成設定ファイルを使用すると，サーバ同士のペア関係を変えられなくなるため，サーバを別の系に移動できません。サーバを別の系に移動する場合は，接続構成設定ファイルを作成し直し，HAモニタを再起動してください。

接続構成設定ファイルで設定する各項目について，次に示します。

# HAモニタ接続構成の設定
ホスト名 LAN IPアドレス [pair];
        ：

ホスト名

自系を含めた，系切り替え構成内のすべての系のホスト名を指定します。ホスト名の指定順序は任意です。ホスト名は，HAモニタの環境設定のnameオペランドで指定したホスト名を指定してください（/etc/hostsファイルに指定したホスト名ではありません）。

LAN IPアドレス

"LAN"のあとに，監視パスに使用しているTCP/IP LANのIPアドレスを指定します。複線化している監視パスすべてのLANのIPアドレスを指定してください。

また，pairを指定する場合は，実際に監視に使用しているすべての監視パスを指定してください。

pair

HAモニタの接続構成設定ファイルにホスト名を設定した系の中で，実際には自系と監視し合わない系がある場合があります。この場合，自系および自系と監視し合う系にだけpairを指定します。

pairの指定は任意です。ただし，pairを指定する場合は，系切り替え構成内のすべての系で，すべての監視パスに指定してください。また，pairの指定は自動作成では指定できません。必ず手動作成してください。

pairを指定すると，指定した系間でだけ監視パスのヘルスチェックやHAモニタのコマンドを実行できます。そのため，pairを指定しない場合と比較して，ヘルスチェックやHAモニタのコマンドの実行に掛かる時間が短縮されます。

pairを指定した系間だけで実行されるHAモニタのコマンドを，次に示します。

サーバ・系の状態表示コマンド（monshowコマンド）

リセットパス状態表示コマンド（monrpコマンド）
使用しているマシンの機種がBladeSymphonyまたはHA8000の場合に使用します。

MP状態表示コマンド（monmpコマンド）
使用しているマシンの機種がHA8500の場合に使用します。

監視パス状態表示コマンド（monpathコマンド）

HAモニタ間の手動接続コマンド（monlinkコマンド）

(3)　作成例

HAモニタの接続構成設定ファイルの作成例を次に示します。

(a)　すべての系が互いに監視し合う場合

すべての系が互いに監視し合う場合の，HAモニタの接続構成設定ファイルの作成例を，次の図に示します。

図6-21　すべての系が互いに監視し合う場合のHAモニタの接続構成設定ファイルの作成例

(b)　監視し合わない系がある場合

監視パスに監視し合わない系がある場合の，HAモニタの接続構成設定ファイルの作成例を，次の図に示します。この例では，監視し合う系にpairを指定しています。

図6-22　監視し合わない系がある場合のHAモニタの接続構成設定ファイルの作成例

監視し合う系にpairを指定しているため，pairを指定しない場合と比較して，ヘルスチェックやコマンドの実行に掛かる時間が短縮されます。

監視し合わないのは，系1・系3間です。

6.9　定義ファイルの作成（HAモニタ）

HAモニタの環境を設定する定義ファイルを作成します。

詳細は，「8.3　HAモニタの環境設定」を参照してください。

なお，HAモニタ Extensionを使用する場合，系切り替え構成内のすべての系で，HAモニタ Extensionの機能の環境設定が必要です。HAモニタ Extensionの機能の環境設定については，「3.5　HAモニタ Extensionの機能」を参照してください。

6.10　サーバが使用する共有リソースの設定

サーバが共有リソースを使用するために，共有リソースの設定をします。この設定は，サーバが共有リソースを使用する場合だけ必要です。

＜この節の構成＞

6.10.1　共有ディスクの設定

6.10.2　LANの状態設定ファイルの設定

6.10.3　LANの監視設定ファイルの設定

6.10.1　共有ディスクの設定

共有ディスクの設定は，共有ディスクをLVMで切り替えるか，HA Boosterで切り替えるかによって異なります。次に，設定の概要を示します。

表6-5　共有ディスクの設定の概要

必要な設定
共有ディスクの切り替え方法
備考

LVMまたはLVM2
HA Booster

ボリュームグループの設定
ボリュームグループの作成
切り替えるボリュームグループを作成します。
制御グループを構成するボリュームグループを作成します。※
「(1)　ボリュームグループの設定」を参照してください。

/etc/rc.sysinitファイルの編集
システム起動時に自動的に参照＋更新接続しないように設定します。
システム起動時に自動的に参照＋更新接続するように設定します。※

HA Boosterの制御グループの設定
設定は不要です。
設定します。
「(2)　HA Boosterの制御グループの設定」を参照してください。

ファイルシステムの設定
設定します。
設定します。
ファイルシステムを切り替える場合に必要です。
「(3)　ファイルシステムの設定」を参照してください。

キャラクタ型スペシャルファイルの設定

LVMの場合

システム起動時にバインドするように設定します。

LVM2の場合

HAモニタのユーザコマンドを作成し，サーバ起動時にバインド，サーバ停止時にアンバインドするように設定します。

システム起動時にバインドするように設定します。
キャラクタ型スペシャルファイルを切り替える場合に必要です。
「(4)　キャラクタ型スペシャルファイルの設定」を参照してください。

注※　LVMまたはLVM2と併用する場合に該当します。

＜この項の構成＞

(1)　ボリュームグループの設定

(2)　HA Boosterの制御グループの設定

(3)　ファイルシステムの設定

(4)　キャラクタ型スペシャルファイルの設定

(1)　ボリュームグループの設定

(a)　ボリュームグループの作成

LVMまたはLVM2で切り替えるボリュームグループの作成

共有ディスクの切り替えは，ボリュームグループ単位で実行されるため，システム管理者はOSのコマンドでボリュームグループを作成する必要があります。

ボリュームグループを作成するときは，次の事項に従ってください。

複数の異なるサーバで系切り替え構成にする場合，各サーバが使用するデータは異なるボリュームグループに配置するよう，共有ディスクを構成してください。
ただし，同じサーバグループ内でリソースサーバを使用する場合は，各サーバが使用するデータを同じボリュームグループに配置できます。

共有ディスク上に作成するボリュームグループの名称を両方の系で同じにしてください。

共有ディスク上に作成するボリュームグループは，HAモニタが制御します。このため，システム起動時，ボリュームグループに自動的に参照＋更新接続をしない設定にする必要があります。/etc/rc.sysinitファイルを編集してください。

HA Boosterで切り替えるボリュームグループの作成

HA Boosterを使用する場合，制御グループ単位で共有ディスクを切り替えます。LVMまたはLVM2と併用する場合，この制御グループを構成するボリュームグループを作成します。HA Boosterが管理するボリュームグループについては，システム起動時，自動的に参照＋更新接続する設定にする必要があります。/etc/rc.sysinitファイルを編集してください。

(b)　/etc/rc.sysinitファイルの編集

/etc/rc.sysinitファイルの編集について，それぞれ次に示します。

LVMによる切り替えを使用する場合
ファイル中の"/sbin/vgscan && /sbin/vgchange -a y"を含むすべての行を検索し，" && /sbin/vgchange -a y"の部分を削除します。
共有ディスク以外で，システム起動時，ボリュームグループに自動的に参照＋更新接続をしたいリソースがあるとき，およびHA Boosterで切り替えるボリュームグループについては，削除した行の次の行に"/sbin/vgchange -a y 接続するボリュームグループ名"を追加します。

LVM2による切り替えを使用する場合
ファイル中の"/sbin/lvm.static vgchange -a y"を含むすべての行を検索し，"/sbin/lvm.static vgchange -a y --ignorelockingfailure "を削除します（Red Hat Enterprise Linux 6.1の場合は"/sbin/lvm vgchange -a y"で検索してください）。
削除することによってactionで実行するコマンドがなくなる場合は，該当するaction自体を削除するか，またはコメントアウトしてください。また，actionを削除することによって，ifコマンドのthen節などで実行するコマンドがなくなる場合は，shellの構文エラーとならないよう，":"（コロン）による空行を挿入してください。
"&& /sbin/lvm.static vgchange -a y"を含むすべての行を検索し，"&& /sbin/lvm.static vgchange -a y --ignorelockingfailure "を削除します（Red Hat Enterprise Linux 6.1の場合は，"&& /sbin/lvm vgchange -a y"で検索してください）。
共有ディスク以外で，システム起動時，ボリュームグループに自動的に参照＋更新接続をしたいリソースがあるとき，およびボリュームグループをHA Boosterで切り替えるときは，削除した行の次の行に"/sbin/lvm.static vgchange -a y 接続するボリュームグループ名 --ignorelockingfailure"を追加します。

HA Boosterによる切り替えだけを使用する場合
HA Boosterによる切り替えだけを使用し，LVMまたはLVM2だけによる切り替えを使用しない場合は，/etc/rc.sysinitファイルの編集は不要です。

注意

/etc/rc.sysinitファイルの編集を誤り，shellの構文エラーになると，システムが起動できなくなるおそれがあります。編集の際には十分注意してください。

以降に，/etc/rc.sysinitファイルの編集例を示します。

(c)　/etc/rc.sysinitファイルの編集例（LVMを使用する場合）

LVMを使用する場合の/etc/rc.sysinitファイルの編集例を示します。

OSがRed Hat Enterprise Linux AS 3.5の場合の例を次に示します。

編集前

・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange ]; then
 action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
 fi
・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then
   action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
 fi
・
・

編集後（ボリュームグループを自動的に参照＋更新接続しない場合）

・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange ]; then
# action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
 action $"Setting up Logical Volume Management:" /sbin/vgscan
 fi
・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then
#     action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
     action $"Setting up Logical Volume Management:" /sbin/vgscan
 fi
・
・

編集後（vg01とvg02を自動的に参照＋更新接続する場合）

・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange ]; then
# action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
 action $"Setting up Logical Volume Management:" /sbin/vgscan
 /sbin/vgchange -a y vg01
 /sbin/vgchange -a y vg02
 fi
・
・
 if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then
#     action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y
     action $"Setting up Logical Volume Management:" /sbin/vgscan
     /sbin/vgchange -a y vg01
     /sbin/vgchange -a y vg02
 fi
・
・

(d)　/etc/rc.sysinitファイルの編集例（LVM2を使用する場合）

LVM2を使用する場合の/etc/rc.sysinitファイルの編集例を示します。

OSがRed Hat Enterprise Linux AS 4.7の場合の例を次に示します。

編集前

・
・
 if [ -x /sbin/lvm.static ]; then
     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
 fi
・
・
     if [ -x /sbin/lvm.static ]; then
         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
     fi
・
・
     if [ -x /sbin/lvm.static ]; then
         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
     fi
・
・

編集後（ボリュームグループを自動的に参照＋更新接続しない場合）

・
・
 if [ -x /sbin/lvm.static ]; then
#     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
     :
 fi
・
・
     if [ -x /sbin/lvm.static ]; then
#         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
         :
     fi
・
・
     if [ -x /sbin/lvm.static ]; then
#         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
         :
     fi
・
・

編集後（vg01とvg02を自動的に参照＋更新接続する場合）

・
・
 if [ -x /sbin/lvm.static ]; then
#     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
     /sbin/lvm.static vgchange -a y vg01 --ignorelockingfailure
     /sbin/lvm.static vgchange -a y vg02 --ignorelockingfailure
 fi
・
・
     if [ -x /sbin/lvm.static ]; then
#         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
         /sbin/lvm.static vgchange -a y vg01 --ignorelockingfailure
         /sbin/lvm.static vgchange -a y vg02 --ignorelockingfailure
     fi
・
・
     if [ -x /sbin/lvm.static ]; then
#         action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
         /sbin/lvm.static vgchange -a y vg01 --ignorelockingfailure
         /sbin/lvm.static vgchange -a y vg02 --ignorelockingfailure
     fi
・
・

OSがRed Hat Enterprise Linux 5.3の場合の例を次に示します。

編集前

・
・
 if [ -x /sbin/lvm.static ]; then
     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
 fi
・
・

編集後（ボリュームグループを自動的に参照＋更新接続しない場合）

・
・
 if [ -x /sbin/lvm.static ]; then
#     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
    :
 fi
・
・

編集後（vg01とvg02を自動的に参照＋更新接続する場合）

・
・
 if [ -x /sbin/lvm.static ]; then
#     action $"Setting up Logical Volume Management:" /sbin/lvm.static vgchange -a y --ignorelockingfailure
     /sbin/lvm.static vgchange -a y vg01 --ignorelockingfailure
     /sbin/lvm.static vgchange -a y vg02 --ignorelockingfailure
 fi
・
・

OSがRed Hat Enterprise Linux 6.1の場合の例を次に示します。

編集前

・
・
if [ -x /sbin/lvm ]; then
   action $"Setting up Logical Volume Management:" /sbin/lvm vgchange -a y --sysinit
   :
fi
・
・

編集後（ボリュームグループを自動的に参照＋更新接続しない場合）

・
・
if [ -x /sbin/lvm ]; then
#    action $"Setting up Logical Volume Management:" /sbin/lvm vgchange -a y --sysinit
   :
fi
・
・

編集後（vg01とvg02を自動的に参照＋更新接続する場合）

・
・
if [ -x /sbin/lvm ]; then
#    action $"Setting up Logical Volume Management:" /sbin/lvm vgchange -a y --sysinit
    /sbin/lvm vgchange -a y vg01 --sysinit
    /sbin/lvm vgchange -a y vg02 --sysinit
   :
fi
・
・

(2)　HA Boosterの制御グループの設定

HA Boosterを使用する場合，制御グループ単位で共有ディスクを切り替えます。HAモニタは，制御グループのアクセス権限をサーバ単位で変更することで，共有ディスクを制御します。

HA Boosterの制御グループには，ディスクデバイスを登録します。サーバごとに，制御グループを独立させてください。制御グループへの登録方法については，HA Booster関連のドキュメントを参照してください。

なお，LVMまたはLVM2による切り替えだけを使用し，HA Boosterによる切り替えを使用しない場合は，この設定は不要です。

(3)　ファイルシステムの設定

共有ディスク上のファイルシステムを使用する場合，OSに対してファイルシステムの設定をする必要があります。

ファイルシステムの切り替え制御では，HAモニタがマウント・アンマウントします。したがって，システム起動時に自動的にマウントしないように設定してください。設定方法は，OSのマニュアルを参照してください。

HAモニタが制御するファイルシステムを/etc/fstabファイルに指定する場合，第3フィールド（ファイルシステムタイプ）には，"ignore"を指定しないでください。"ignore"を指定した場合，HAモニタが実行するfsckコマンドが失敗し，ファイルシステムを使用できないことがあります。

(4)　キャラクタ型スペシャルファイルの設定

キャラクタ型スペシャルファイルは，使用する条件によってバインド・アンバインドの要否やタイミングが異なります。

キャラクタ型スペシャルファイルを使用する条件と，バインド・アンバインドの要否を，次の表に示します。

表6-6　キャラクタ型スペシャルファイルを使用する条件と，バインドまたはアンバインドの要否

キャラクタ型スペシャルファイルを
使用する条件
バインド・アンバインドの要否

HA Boosterが管理する制御グループにない共有ディスク上
LVM
システム起動時にキャラクタ型スペシャルファイルをバインドします。アンバインドは不要です。

LVM2
システム起動時ではなく，ボリュームグループに参照＋更新接続をした時点でバインドし，ボリューブムグループの切り離しをした時点でアンバインドします。HAモニタのユーザコマンドで設定します。
また，ボリュームグループを切り離す前にアンバインドする必要があるため，HAモニタの環境設定，およびサーバ対応の環境設定のdeviceoff_orderオペランド※にreverseを設定する必要があります。
キャラクタ型スペシャルファイルを使用するすべてのサーバに対して設定してください。

HA Boosterが管理する制御グループにある共有ディスク上
システム起動時に，次のファイルなどを用いてキャラクタ型スペシャルファイルをバインドします。アンバインドは不要です。

/etc/sysconfig/rawdevices

/etc/udev/rules.d配下のudevのruleファイル

HA Boosterの起動スクリプト

注※

HAモニタの環境設定のdeviceoff_orderオペランドについては，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。また，サーバ対応の環境設定のdeviceoff_orderオペランドについては，「8.4.1　サーバ対応の環境設定（servers）」を参照してください。

以降に，キャラクタ型スペシャルファイルの設定に関するユーザコマンドについて説明します。ユーザコマンドの作成方法についての詳細は，「6.16　ユーザコマンドの作成」を参照してください。

(a)　ユーザコマンドの発行タイミング

次のタイミングでOSのrawコマンドが発行されるよう，ユーザコマンドを設定します。

キャラクタ型スペシャルファイルのバインド

実行サーバの起動時

待機サーバの系切り替え処理開始時

実行サーバでサーバ障害が発生

実行系で系障害が発生

実行系から待機系に計画系切り替えを実行

キャラクタ型スペシャルファイルのアンバインド

実行サーバの終了時

実行サーバでサーバ障害が発生

実行系から待機系に計画切り替えを実行

実行サーバでサーバ障害が発生（系切り替え不可）

実行サーバが正常終了

実行サーバが計画終了

待機サーバの起動時

待機サーバの系切り替え失敗時

(b)　ユーザコマンドのコーディング例

サーバ（LinuxTP1）に対して，共有ディスク上（/dev/vg10）でキャラクタ型スペシャルファイル（/dev/raw/raw1）を論理ボリューム（lvol0）にバインドする場合の，ユーザコマンドのコーディング例を次に示します。

このコーディング例は，サンプルファイルとしてHAモニタのサンプルファイル用ディレクトリの下に，usrcommand_raw_bindのファイル名で格納されています。

# サーバ識別名の定義
SERV="LinuxTP1"                        # サーバ識別名：LinuxTP1
# デバイス名称の定義
RAW_NAME="/dev/raw/raw1"               # rawデバイス名称
DEV_NAME="/dev/vg10/lvol0"             # 共有ディスク上の論理ボリューム名称

# rawデバイスをアンバインドする
func_unbind(){
# デバイスが存在しなくなるまで待つ
COUNT=0
while [ ¥( ${COUNT} -lt 10 ¥) -a ¥( -e "$1" ¥)]
do
  # rawデバイスを使用中のプロセスを強制終了する
  fuser -k "$1" >/dev/null 2>&1
  # コマンドの処理が完了するのを1秒待つ
  sleep 1
  # デバイスのアンバインド
  raw "$1" 0 0
  COUNT=`expr ${COUNT} + 1`
done
}

# rawデバイスをバインドする
func_bind(){
# デバイスのバインド
raw "$1" "$2"
# デバイスが使用可能になるまで待つ
COUNT=0
while [ ${COUNT} -lt 10 ]
do
  # デバイスへのアクセスを試行し，アクセスできればバインド完了
  dd of=/dev/null if="$1" bs=1 count=0 >/dev/null 2>&1
  if [ "$?" = 0 ]
  then
    break
  fi
  # 1秒sleepしリトライする
  sleep 1
  COUNT=`expr ${COUNT} + 1`
done
}

# Main
# 実行サーバの起動開始時，または待機サーバの系切り替え開始時に
# rawデバイスをバインドする
# 実行サーバの終了開始時，待機サーバの起動開始時，または待機サーバの
# 系切り替え失敗時にrawデバイスをアンバインドする
PATH=/bin:/usr/bin:/sbin
export PATH
if [ "$2" = "${SERV}" ]
then
  if [ "$4" = "online" ]
  then
    case "$5" in
    "-s" )                      # 実行サーバの起動
      if [ "$6" = "start" ]     # 状態変化の開始
      then
        func_bind ${RAW_NAME} ${DEV_NAME}
      fi
    ;;
    "-a" | "-w" | "-o" | "-e" | "-p" )  # 実行サーバの終了
                                # (サーバ障害，計画系切り替え，
                                # サーバ障害(系切り替え不可能)，
                                # 正常終了，計画終了)
      if [ "$6" = "start" ]     # 状態変化の開始
      then
        func_unbind ${RAW_NAME} ${DEV_NAME}
      fi
    ;;
    esac
  else
    case "$5" in
    "-a" | "-h" | "-w" )        # 待機サーバ系切り替え
                                # (サーバ障害，系障害，計画切り替え)
      if [ "$6" = "start" ]     # 状態変化の開始
      then
        func_bind ${RAW_NAME} ${DEV_NAME}
      fi
    ;;
    "-s" | "-f" )               # 待機サーバ起動，または系切り替え失敗
      if [ "$6" = "start" ]     # 状態変化の開始
      then
        func_unbind ${RAW_NAME} ${DEV_NAME}
      fi
    ;;
    esac
  fi
fi

このコーディング例では，実行サーバ起動時の実行系，または系切り替え時の系切り替え先の系でfunc_bindを実行し，キャラクタ型スペシャルファイルのバインドをしています。また，実行サーバ終了時の実行系，待機サーバ起動時の待機系，または系切り替え失敗時の系切り替えに失敗した待機系でfunc_unbindを実行し，キャラクタ型スペシャルファイルのアンバインドをしています。

func_bindでは，rawコマンドでキャラクタ型スペシャルファイルのバインドを実行します。そのあとに，キャラクタ型スペシャルファイルがアクセス可能になるまで，次の処理を1秒間隔で10回リトライしています。

ddコマンド
キャラクタ型スペシャルファイルがアクセス可能になったか調べます。

sleepコマンド
キャラクタ型スペシャルファイルがバインドされるのを待ちます。

func_unbindでは，キャラクタ型スペシャルファイルがアンバインドするまで，次の処理を1秒間隔で10回リトライしています。

fuserコマンド
系切り替え時に，キャラクタ型スペシャルファイルを使用するプロセスが存在するとアンバインドできないため，共有ディスクの切り離しに失敗します。このため，fuserコマンドでキャラクタ型スペシャルファイルを使用しているすべてのプロセスを強制停止します。

sleepコマンド
キャラクタ型スペシャルファイルがアンバインドされるのを待ちます。

rawコマンド
キャラクタ型スペシャルファイルをアンバインドします。

6.10.2　LANの状態設定ファイルの設定

HAモニタの場合，LANはサーバ単位に接続，切り離しをします。HAモニタでは，LANの状態設定ファイルを作成して設定する必要があります。

LANの状態設定ファイルの種類を，次に示します。

サーバ識別名.upファイル
LANを接続する場合に使用します。サーバが使用するIPアドレスをLANアダプタに割り当てるための情報を指定します。

サーバ識別名.downファイル
LANの切り離しをする場合に使用します。サーバが使用するIPアドレスをLANアダプタから削除するための情報を指定します。

これらのファイルは，サーバごとにHAモニタの環境設定用ディレクトリの下に作成します。ファイル名のサーバ識別名の部分は，サーバ対応の環境設定のaliasオペランドで指定した値にしてください。

HAモニタには，HAモニタサンプルファイル用ディレクトリの下に，server.upおよびserver.downというファイル名で，LANの状態設定ファイルのサンプルファイルが用意されています。これらのファイルをHAモニタ環境設定用ディレクトリの下にコピーして書き換えることで，LANの状態設定ファイルを最初から作成する手間が省けます。また，ファイルには実行権限を与えてください。

HAモニタでのLANの切り替えは，エイリアスIPアドレスを使用します。LANの状態設定ファイルには，OSのifconfigコマンドおよびarpingコマンドの引数として，LANアダプタに追加・削除するエイリアスIPアドレスを指定します。OSのコマンドについては，OSのマニュアルを参照してください。

ここでは，エイリアスIPアドレスを使用した場合の，LANの状態設定ファイルの設定方法について説明します。

＜この項の構成＞

(1)　サーバ識別名.upファイルの設定

(2)　サーバ識別名.downファイルの設定

(1)　サーバ識別名.upファイルの設定

サーバ識別名.upファイルには，系ごとに割り当てられたLANアダプタのインタフェース名，IPインデックス番号，およびエイリアスIPアドレスを設定します。必要に応じてネットマスクおよびブロードキャストアドレスを設定してください。また，エイリアスIPアドレスを追加したあと，echoコマンドおよびarpingコマンドを実行します。echoコマンドの実行によって，ルーティングキャッシュをクリアし，arpingコマンドの実行によって，ARPリクエストがブロードキャストされ，IPアドレスとMACアドレスのマッピングが更新されます。

サーバ識別名.upファイルの内容を，次に示します。

/sbin/ifconfig  xxx:y inet n.n.n.n netmask nn.nn.nn.nn broadcast nnn.nnn.nnn.nnn
/bin/echo 0 > /proc/sys/net/ipv4/route/flush
/sbin/arping -U -c 2 -I xxx n.n.n.n

（凡例）

xxx：インタフェース名

y：IPインデックス番号

n.n.n.n：エイリアスIPアドレス

nn.nn.nn.nn：ネットマスク

nnn.nnn.nnn.nnn：ブロードキャストアドレス

一つのインタフェースで複数のエイリアスIPアドレスを使用する場合は，各エイリアスIPアドレスに対応して異なるIPインデックス番号を設定します。

なお，サーバ対応の環境設定でip_neckオペランドにuseを指定したサーバについては，「3.3.3　共有リソース接続失敗時のサーバの起動中止」にある，サーバ識別名.upファイルの例を参考に，LANの状態設定ファイルを設定してください。

(2)　サーバ識別名.downファイルの設定

サーバ識別名.downファイルには，系ごとに割り当てられたLANアダプタのインタフェース名，およびIPインデックス番号を設定します。

サーバ識別名.downファイルの内容を，次に示します。

/sbin/ifconfig   xxx:y down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

（凡例）

xxx：インタフェース名

y：IPインデックス番号

6.10.3　LANの監視設定ファイルの設定

LANを監視して障害時に自動的に系切り替えをする場合，LANの監視設定ファイルを作成して設定する必要があります。LANの監視設定ファイルの種類を，次に示します。

LAN監視定義ファイル（LANインタフェース名称.conf）
監視対象ごとに設定し，LANを監視するための確認用パケット送出先のIPアドレスを指定します。

LAN監視スクリプト（lanpatrol.sh）
パケット数を監視する方法で，LANを監視する場合に設定します。監視対象がhbondingで，hbondingのステータスだけを監視する場合には設定不要です。

これらのファイルは，サーバごとにHAモニタの環境設定用ディレクトリの下に作成します。ここでは，LANの監視設定ファイルの設定方法について説明します。

LANの監視については，「3.2.6　LANの監視および障害時の自動系切り替え」を参照してください。

＜この項の構成＞

(1)　LAN監視定義ファイルの設定

(2)　LAN監視スクリプトの設定

(1)　LAN監視定義ファイルの設定

LAN監視定義ファイルには，LANを監視するための確認用パケット送出先のIPアドレスを設定します。hbondingのステータスだけを監視する場合，LAN監視定義ファイルは空（0バイト）にします。

このファイルは監視対象ごとに，HAモニタを起動する前に設定しておく必要があります。HAモニタの稼働中に追加・変更・削除はできません。

設定するファイル名は，"LANインタフェース名称.conf"です。ファイル名の"LANインタフェース名称"の部分には，サーバ対応の環境設定のswitchbyfailオペランドの指定値と同じ値を指定します。また，先頭に"."（ピリオド）を指定すると，ファイルが無効になります。

LAN監視定義ファイルの作成規則を，次に示します。

1行につき，一つのIPアドレスまたはIPラベルを記述します。
IPアドレスには，監視対象のLANインタフェースと同じネットワーク上にある，リモートホストのIPアドレスを指定します。自ノードで使用するIPアドレスは指定できません。IPラベルを指定した場合，ホスト名の解決に時間が掛かることがあります。このため，IPアドレスを記述することをお勧めします。

ペアとなるHAモニタがある系のIPアドレスは，必ず記述します。

ファイル内にコメントは記述できません。

同一IPアドレス，またはIPラベルを重複して記述できません。

タブ，スペース，改行文字がIPアドレスまたはIPラベルの前後に指定されている場合は，タブ，スペース，改行文字を無視します。

指定できるIPアドレスまたはIPラベルの数は，2～1,024個です。

LAN監視定義ファイルにIPラベルを設定する場合は，各IPアドレスとそれに対応するIPラベルを，/etc/hostsファイルに指定してください。

なお，HAモニタの環境設定用ディレクトリには，LAN監視定義ファイル以外に，拡張子が".conf"のファイルを作成しないでください。

LAN監視定義ファイルの例を，次に示します。この例では，LANインタフェース名称が"eth0"，物理IPアドレスが"192.168.0.1"，ネットワークが"192.168.0"です。

ファイル名：eth0.conf

192.168.0.2
192.168.0.3
192.168.0.4

(2)　LAN監視スクリプトの設定

パケット数を監視する方法でLANを監視する場合に設定します。設定するファイル名は，"lanpatrol.sh"です。監視対象がhbondingで，hbondingのステータスだけを監視する場合には設定不要です。

このファイルは，HAモニタのサンプルファイル用ディレクトリの下に，サンプルファイルが用意されています。HAモニタ環境設定用ディレクトリの下にコピーして使用してください。サンプルファイルの内容を，次に示します。

#!/bin/sh
#*****************************************************************************
#*                                                                            *
#*    P-812C-E111 Linux(x86) HAmonitor                                        *
#*    This is a sample of the LAN patrol command.                             *
#*                                                                            *
#*    [SYNOPSIS]                                                              *
#*        lanpatrol.sh interface                                              *
#*    [OPTIONS]                                                               *
#*        interface                                                           *
#*            The name of the LAN interface.                                  *
#*    [DIAGNOSTICS]                                                           *
#*        0 : normal                                                          *
#*        1 : abnormal                                                        *
#*        2 : error                                                           *
#*                                                                            *
#*    All Rights Reserved. Copyright (C) 2009, Hitachi, Ltd.                  *
#*                                                                            *
#*****************************************************************************
#set -x

# retry interval(seconds)
WAIT_TIME=3

# retry counter
RETRY=3

# environment variables
PATH=/usr/bin:/usr/sbin:/bin
export PATH
・
・
（以降省略）

このファイルで設定するスクリプトは，次のように動作します。

LAN監視定義ファイルに設定されたIPアドレスに対して，pingコマンドを発行します。

監視対象のLANインタフェースの受信パケット数を複数回取得し，前回取得したときの結果と比較します。
比較した結果が一致していなければLANが正常であると判断し，一致していればpingコマンド発行と受信パケットを取得する処理をリトライします。リトライ回数は，スクリプト内で任意の値に設定できます。リトライした結果，パケット数が変化しなければ異常と判断します。

LAN監視スクリプトのコマンドラインを次に示します。

lanpatrol.sh△LANインタフェース名称

（凡例）

△：半角スペースを示します。

サンプルファイルは，必要に応じて修正することもできます。サンプルファイルをそのまま使用する場合とサンプルファイルを修正する場合とに分けて，注意事項を以降に説明します。

(a)　サンプルファイルをそのまま使用する場合

サンプルファイルをそのまま使用し，かつHAモニタの環境設定のlancheck_patrolオペランドの値をデフォルト（15）よりも小さくする場合，LAN監視スクリプトの実行時間を短くする必要があります。LAN監視スクリプトの実行時間は，次の計算式を満たすように設定します。

lancheck_patrolオペランドの指定値＞LAN監視スクリプトの実行時間＋2

LAN監視スクリプトの実行時間は，次の計算式で求めます。

（WAIT_TIME変数の値＋1）×RETRY変数の値

サンプルファイルでは，LAN監視スクリプトの実行時間は，（3＋1）×3＝12秒となります。LAN監視スクリプトの実行時間を短くする場合は，WAIT_TIME変数，またはRETRY変数の値を小さくしてください。WAIT_TIME変数の最小値は0，RETRY変数の最小値は1です。

参考

LAN監視スクリプト中で実行するpingコマンドに掛かる時間は1秒です。これにWAIT_TIME変数で指定した時間を加えた時間が，受信パケットの監視に掛かる時間となります。受信パケットの監視は，RETRY変数で指定した回数分繰り返されます。したがって，受信パケットの監視時間にRETRY変数の回数を掛けた値が，LAN監視スクリプトの実行時間になります。

(b)　サンプルファイルを修正する場合

サンプルファイルを修正する場合の注意事項を，次に示します。

LAN監視スクリプトは，root権限で実行されます。

LAN監視スクリプトには，実行権限を付与してください。

LAN監視スクリプト内で，必要な環境変数があれば設定してください。

LAN監視スクリプトは，監視対象のLANの状態に応じて，次の表に示すEXITコードで終了するように作成してください。

表6-7　LANの状態に応じて返すEXITコード

監視対象のLANの状態 | EXITコード | 説明
正常 | 0 | LANを正常に使用できると判断した場合は，EXITコード0を返します。HAモニタは，LANが正常，または復旧したと判断します。
障害 | 1 | LANを使用できないと判断した場合は，EXITコード1を返します。HAモニタは，LANに異常が発生したと判断します。サーバ対応の環境設定のswitchbyfailオペランドに該当するLANインタフェースを指定している場合，実行サーバの系切り替えをします。
監視不可 | 2 | LANの状態が判断できない場合は，0または1以外のEXITコードを返します。HAモニタは，LANの監視ができないため，サーバ対応の環境設定のswitchbyfailオペランドに該当するLANインタフェース名称を指定していても実行サーバの系切り替えをしません。

HAモニタの正常終了時には，実行中のLAN監視スクリプトにSIGTERMを送信します。

6.11　サーバの起動・停止・監視コマンドの作成

サーバがモニタモードの場合，サーバの起動コマンド，停止コマンドおよび監視コマンドを作成します。サーバの起動コマンドの作成は必須です。サーバの停止・監視コマンドの作成は任意です。ただし，モニタモードのプログラム管理機能を使用して監視するUAPについては，サーバの監視コマンドへの作り込みは不要です。

なお，複数のプログラムの処理をサーバの起動コマンド，停止コマンドおよび監視コマンドに記述すると，複数のプログラムを一つのサーバとして使用できます。

各コマンドは，C言語やシェル言語などで，サーバ単位に作成してください。

注意

作成したコマンド内の処理については，必要に応じてログを出力するなど，障害解析できるようにしておくことをお勧めします。

＜この節の構成＞

6.11.1　サーバの起動コマンドの作成

6.11.2　サーバの停止コマンドの作成

6.11.3　サーバの監視コマンドの作成

6.11.1　サーバの起動コマンドの作成

サーバの起動コマンドは，プログラムを起動するためのコマンドです。サーバがモニタモードの場合，HAモニタがサーバの起動完了を確認できるようにするために，サーバの起動コマンドを作成する必要があります。

ここでは，サーバの起動コマンドが呼び出されるタイミング，およびサーバの起動コマンドの作成方法について説明します。

＜この項の構成＞

(1)　サーバの起動コマンドが呼び出されるタイミング

(2)　サーバの起動コマンドの作成方法

(1)　サーバの起動コマンドが呼び出されるタイミング

作成したサーバの起動コマンドは，HAモニタがスーパユーザの権限で実行します。

サーバの起動コマンドは，次の場合に，共有リソースを接続したあと呼び出されます。

モニタモードのサーバ起動コマンド（monbeginコマンド）を実行して，実行サーバを起動する場合

サーバ障害時に実行サーバを再起動する設定で，実行サーバを再起動する場合

(2)　サーバの起動コマンドの作成方法

サーバの起動コマンドは，プログラムを直接指定することも，プログラムの起動処理を記述したシェルなどを指定することもできます。必要に応じて，シェルの中でプログラムの起動に必要な動作環境を設定してください。

モニタモードのプログラム管理機能使用時に，APIを発行するUAPをサーバの起動コマンドで起動する場合は，UAPの環境変数にプログラム名を設定する必要があります。サーバの起動コマンドには，対象となるすべてのUAPの起動処理を記述してください。UAPの環境変数については，「6.13.2　UAPの環境変数の設定」を参照してください。また，UAP障害時にcoreファイルを取得し，調査できるようにするため， UAPを起動する処理の前に「ulimit -c unlimited」を追加してください。カーネルパラメタのデフォルト値では，coreファイルを取得しない設定となっています。

作成したサーバの起動コマンドは，サーバ対応の環境設定のnameオペランドに指定します。サーバの起動コマンドに引数を指定する場合は，サーバ対応の環境設定のactcommandオペランドにも指定してください。

サーバの起動コマンドを作成する場合，プログラムのタイプによって，サーバ対応の環境設定のwaitserv_execオペランドに次の設定をしてください。

表6-8　プログラムのタイプによるwaitserv_execオペランド設定値

プログラムのタイプ | サーバの監視をする場合の設定値 | サーバの監視をしない場合の設定値
直接サーバプロセスとして動作するプログラム | no | no
直接サーバプロセスとして動作しないプログラム | yes | どちらでも良い

直接サーバプロセスとして動作するプログラムの場合

サーバ対応の環境設定のwaitserv_execオペランドにnoを指定します。なお，この設定はデフォルトです。直接サーバプロセスとして動作するプログラムの場合，起動完了を待たないため，必ずnoを指定してください。

直接サーバプロセスとして動作しないプログラムの場合

モニタモードのサーバを監視する場合は，サーバ対応の環境設定のwaitserv_execオペランドに必ずyesを指定してください。

モニタモードのサーバを監視する場合にyesを指定しないと，プログラムが起動完了する前にHAモニタでの実行サーバの起動処理が完了し，サーバの監視が開始される場合があります。プログラムの起動が完了しないままサーバの監視が開始されると，プログラムの起動が完了していない状態がサーバ障害として検出され，実行サーバの再起動や系切り替えがされるおそれがあります。

また，モニタモードのサーバを監視しない場合は，yes，noのどちらでも指定できます。ただし，次の場合はyesを指定してください。

モニタモードのサーバ間でサーバの切り替え順序を制御する。

サーバの起動コマンドのEXITコードで処理を分ける。

サーバ対応の環境設定のwaitserv_execオペランドにyesを指定すると，HAモニタはサーバ対応の環境設定のnameオペランドまたはactcommandオペランドに指定したサーバの起動コマンドの戻り値を評価します。戻り値ごとのHAモニタの処理を，次に示します。

戻り値が0
プログラムが起動に成功したとして，実行サーバの起動完了処理をします。

戻り値が0以外
プログラムが起動に失敗したとして，実行サーバの起動を停止します。サーバの再起動時はサーバの再起動に失敗します。再起動に失敗した場合，サーバ対応の環境設定のtermcommandオペランドに指定したサーバの停止コマンドを実行しません。再起動に失敗した場合の対処については，「7.4.2　サーバの再起動失敗に対処する」を参照してください。

また，サーバ対応の環境設定のwaitserv_execオペランドにyesを指定した場合は，サーバの起動コマンドが起動してから終了するまでのタイムアウト時間を，サーバ対応の環境設定のstart_timeoutオペランドで指定できます。

サーバ対応の環境設定のwaitserv_execオペランドにnoを指定すると，HAモニタはサーバの起動コマンドの戻り値に関係なく，実行サーバの起動完了処理をします。

6.11.2　サーバの停止コマンドの作成

サーバの停止コマンドは，プログラムを自動停止するためのコマンドです。サーバの停止コマンドの作成は任意です。連動系切り替えなどでプログラムを自動停止したい場合に作成してください。

ここでは，サーバの停止コマンドが呼び出されるタイミング，およびサーバの停止コマンドの作成方法について説明します。

＜この項の構成＞

(1)　サーバの停止コマンドが呼び出されるタイミング

(2)　サーバの停止コマンドの作成方法

(1)　サーバの停止コマンドが呼び出されるタイミング

作成したサーバの停止コマンドは，HAモニタがスーパユーザの権限で実行します。

サーバの停止コマンドは，次の場合に，共有リソースの切り離しをする前に呼び出されます。

計画系切り替えコマンド（monswapコマンド）を実行して，実行サーバを計画停止する場合

モニタモードのサーバ停止コマンド（monendコマンド）を実行して，実行サーバを正常終了する場合

サーバ障害時にサーバを再起動する設定で，サーバの障害を検出した場合（実行サーバを再起動する前）

サーバ障害時の系切り替えに伴って実行サーバを停止する場合

連動系切り替えに伴って実行サーバを計画停止する場合

HAモニタは，サーバの停止コマンドに，呼び出される場合に応じた引数を渡します。引数には，"-e"，"-w"，および"-c"があります。それぞれの引数に対応する次のような処理を記述してください。

表6-9　サーバの停止コマンドの引数と記述する処理

引数 | 引数が渡された時に記述する処理
-e | サーバの正常停止。
-w | サーバを計画切り替えするための計画停止。
-c | 異常終了したサーバを再起動できるようにするための処理。

サーバの停止コマンドの起動条件と引数の関係を，次の表に示します。

表6-10　サーバの停止コマンドの起動条件と渡される引数

サーバの停止コマンドの起動条件 | 渡される引数※
termcmd_at_abort＝nouseの場合 | termcmd_at_abort＝useの場合
モニタモードのサーバ停止コマンド（monendコマンド）でサーバを停止。 | -e | -e
サーバ障害時，モニタモードのサーバ停止コマンド（monendコマンド）で待機サーバがない実行サーバを停止。 | -e | -c
サーバ障害によるサーバの系切り替え処理。 | -w | -c
計画系切り替えコマンド（monswapコマンドまたはmonswap -gコマンド）を実行。 | -w | -w
待機サーバがない実行サーバの障害時，待機サーバを起動したあと計画系切り替えコマンド（monswapコマンドまたはmonswap -gコマンド）を実行。 | -w | -c
連動系切り替えに伴って，実行サーバを強制停止・系切り替え。 | -w | -w
サーバ障害時，連動系切り替えに伴って，待機サーバがない実行サーバを強制停止。 | -w | -c
待機サーバがない実行サーバの障害時，連動系切り替えに伴って，待機サーバを起動したあと，系切り替え。 | -w | -c
サーバ障害時の実行サーバ再起動前処理。 | -c | -c
サーバの起動コマンド失敗による，サーバの起動中止。 | － | -c

（凡例）

－：サーバの停止コマンドを発行しません。

注※

渡される引数は，サーバ対応の環境設定のtermcmd_at_abortオペランドに何を指定するかによって異なります。termcmd_at_abortオペランドについては，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

(2)　サーバの停止コマンドの作成方法

サーバの停止コマンドは，プログラムの停止処理を記述したシェルなどを指定します。必要に応じて，シェルの中でプログラムの終了に必要な動作環境を設定してください。

モニタモードのプログラム管理機能使用時に，APIを発行するUAPをサーバの停止コマンドで停止する場合は，UAPの環境変数にプログラム名を設定する必要があります。また，サーバの停止コマンドには，対象となるすべてのUAPの停止処理を記述してください。UAPがプロセスを生成する場合は，生成したプロセスの停止処理も記述してください。UAPの環境変数については，「6.13.2　UAPの環境変数の設定」を参照してください。

作成したサーバの停止コマンドは，サーバ対応の環境設定のtermcommandオペランドに指定します。また，サーバの停止コマンドが起動してから終了するまでのタイムアウト時間を，サーバ対応の環境設定のstop_timeoutオペランドで指定できます。

実行サーバの正常終了時，計画停止時に呼び出されるサーバの停止コマンドの戻り値によって，HAモニタの動作が変わることはありません。一方，サーバの再起動時に呼び出されるサーバの停止コマンドでは，処理が正常終了した場合は戻り値として0を必ず返すように，処理を記述してください。戻り値が0以外の場合，サーバの再起動に失敗します。再起動に失敗した場合の対処については，「7.4.2　サーバの再起動失敗に対処する」を参照してください。

また，複数のプログラムの停止処理をサーバの停止コマンドに記述することで，複数のプログラムを一つのサーバとして使用できます。

6.11.3　サーバの監視コマンドの作成

サーバの監視コマンドは，プログラムの状態を監視するコマンドです。HAモニタでは，サーバの監視コマンドを作成することによって，サーバ障害時にサーバの再起動や自動系切り替えができます。なお，モニタモードのプログラム管理機能で監視するUAPだけでサーバを構成する場合は，作成不要です。

ここでは，サーバの監視コマンドが呼び出されるタイミング，およびサーバの監視コマンドの作成方法について説明します。サーバの監視方法の説明については，「3.1.1　モニタモードのサーバの監視」を参照してください。

＜この項の構成＞

(1)　サーバの監視コマンドが呼び出されるタイミング

(2)　サーバの監視コマンドの作成方法

(1)　サーバの監視コマンドが呼び出されるタイミング

作成したサーバの監視コマンドは，HAモニタがスーパユーザの権限で実行します。

サーバの監視コマンドは，実行系で実行サーバが起動完了したあとに起動されます。

(2)　サーバの監視コマンドの作成方法

サーバの監視コマンドのサンプルファイルを，HAモニタサンプルファイル用ディレクトリの下にpatrol.sh というファイル名で格納していますので，必要に応じて利用してください。作成したサーバの監視コマンドは，サーバ対応の環境設定のpatrolcommandオペランドに指定します。

サーバの監視コマンドは，次の点を考慮して作成してください。

プログラムが異常終了した場合は，サーバの監視コマンドはループを抜け，自身をexitします。
サーバの監視コマンドの終了を検知しても，ペアになる待機サーバが起動完了していない場合は，実行サーバは停止しません。そのため，系切り替えや実行サーバの再起動をしたいときは，オペレータが次の操作をする必要があります。

系切り替えをしたい場合

モニタモードのサーバ停止コマンド（monendコマンド）で実行サーバを停止する。

待機系のサーバを実行サーバとして起動するか，または待機系で待機サーバを起動したあと計画系切り替えコマンド（monswapコマンド）で系切り替えをする。

実行サーバ再起動をしたい場合

モニタモードのサーバ停止コマンド（monendコマンド）で実行サーバを停止する。

モニタモードのサーバ起動コマンド（monbeginコマンド）で実行サーバを起動したあと，待機系で待機サーバを起動する。

HAモニタは，サーバの監視コマンドに対してSIGTERMシグナルを送信することで監視コマンドを停止させます。
SIGTERMシグナルを受信しない設定にはしないでください。

なお，モニタモードのプログラム管理機能で監視するUAPについては，サーバの監視コマンドでの監視は不要です。

次に，Bシェルによる監視コマンドの作成例を示します。

#!/bin/sh
# The object program to monitor
PROGRAM=/home/xxxx/yyyy

# The definition of command
PS=/bin/ps
GREP=/bin/grep

# Main loop
while true
do
   # Is the object program to monitor operating ?
   EXIST=`$PS -efl | $GREP $PROGRAM | $GREP -v grep`

   # When the object program to monitor is not operating,
   # the variable EXIST is empty.
   if [ "$EXIST" = "" ]
   then
       # This patrol command terminates, because the object program
       # to monitor is not operating.
       exit
   fi

   # The monitoring is continued, because the object program
   # to monitor is operating.
   sleep 5
done

前述のコーディング例では，サーバの監視コマンド内でループを持ち，そのループ内でプログラムのプロセスがあるかどうかを確認します。プロセスの確認には，OSのpsコマンドの出力などを使用します。プログラムのプロセスがあればループを継続し，プロセス生存の確認を続行します。

6.12　プログラムの再起動コマンドの作成（プログラム管理機能使用時）

プログラムの再起動コマンドは，モニタモードのプログラム管理機能で監視するUAPの障害時に，UAPを再起動するためのコマンドです。

ここでは，プログラムの再起動コマンドが呼び出されるタイミング，およびプログラムの再起動コマンドの作成方法について説明します。

＜この節の構成＞

(1)　プログラムの再起動コマンドが呼び出されるタイミング

(2)　プログラムの再起動コマンドの作成方法

(1)　プログラムの再起動コマンドが呼び出されるタイミング

作成したプログラムの再起動コマンドは，HAモニタがスーパユーザの権限で実行します。

プログラムの再起動コマンドは，次の場合に呼び出されます。

プログラム管理機能で監視するUAPの障害を検出した場合

サーバの起動コマンドが終了したが，UAPの監視用API（hamon_patrolstart関数）が発行されない場合

(2)　プログラムの再起動コマンドの作成方法

プログラムの再起動コマンドには，UAPを停止したあとにUAPを起動する処理を記述したシェルなどを指定します。必要に応じて，シェルの中でプログラムの再起動に必要な動作環境を設定してください。また，UAP障害時にcoreファイルを取得し，調査できるようにするため， UAPを起動する処理の前に「ulimit -c unlimited」を追加してください。カーネルパラメタのデフォルト値では，coreファイルを取得しない設定となっています。

なお，UAPを停止する処理では，UAPがプロセスを生成する場合は，生成したプロセスの停止処理も記述してください。UAPを起動する処理では，HAモニタがプログラムの再起動コマンドに指定されたシェルの完了を待つため，UAPを起動する処理の実行後に，シェルがリターンするようにしてください。

プログラムの再起動コマンドでAPIを発行するUAPを再起動する場合は，UAPの環境変数にプログラム名を設定する必要があります。UAPの環境変数については，「6.13.2　UAPの環境変数の設定」を参照してください。

作成したプログラムの再起動コマンドは，モニタモードのプログラム対応の環境設定のrestartcommandオペランドに指定します。また，プログラムの再起動コマンドが起動してから終了するまで，およびhamon_patrolstart関数の発行までのタイムアウト時間を，モニタモードのプログラム対応の環境設定のrestart_timeoutオペランドで指定できます。

HAモニタはrestartcommandオペランドに指定したプログラムの再起動コマンドの戻り値を評価します。戻り値ごとのHAモニタの処理を，次に示します。

戻り値が0
プログラムが再起動に成功したとして，プログラムの再起動完了とします。UAPの場合，APIが発行されるのを待ちます。

戻り値が0以外
プログラムが再起動に失敗したとして，プログラムの再起動を停止します。

6.13　UAPの作成と設定

モニタモードのプログラム管理機能を使用してUAPを監視する場合，UAPへのAPIの組み込みと，UAPの環境変数の設定が必要です。

プログラム管理機能については，「3.4　プログラムの制御のための機能（モニタモード）」を参照してください。

＜この節の構成＞

6.13.1　UAPへのAPIの組み込み

6.13.2　UAPの環境変数の設定

6.13.1　UAPへのAPIの組み込み

モニタモードのプログラム管理機能を使用してUAPを監視する場合，HAモニタが提供するAPIをUAPから発行するために，UAPのソースコードを編集する必要があります。ここでは，UAPへのAPIの組み込みについて説明します。

＜この項の構成＞

(1)　APIを組み込めるUAP

(2)　HAモニタが提供するファイル

(3)　UAPの作成

(4)　コンパイルとリンケージ

(1)　APIを組み込めるUAP

次に示すすべての項目に該当するUAPでAPIを使用できます。

C言語（ANSI C）でプログラミングされている。

HAモニタが提供するAPIで使用する，次の関数名称，領域名称を使用していない。

hamon_patrolstart

hamon_patrolstop

hamon_upapi_env

hamon_upapi_inf

HAモニタが提供するAPIで使用する，次の環境変数を使用していない。

HAMON_UAPNAME

HAMON_API_PATROL

UAP内にプロセスの全ファイルディスクリプタを解放する処理がない。
APIを発行すると，APIはUNIXドメイン通信でHAモニタと接続し，ファイルディスクリプタを一つ保持します。このため，UAP内にプロセスの全ファイルディスクリプタを解放する処理がある場合は，APIを使用できません。

HAモニタ以外の製品に監視されていない。
例えば，OpenTP1のSPPなどからはAPIを発行できません。

APIがスレッドを一つ生成し，APIの引数に指定したシグナルの送受信をスレッドで実行するため，次に示すすべての条件を満たしている。

スレッドを生成できる。

シグナルを使用できる。

APIで使用するためのシグナルが一つ以上ある。また，該当するシグナルについては，シグナルハンドラが未設定で，かつブロックされていない。

システムコールがシグナルの割り込みでリターン（エラー番号：EINTR）した場合を想定して，UAPが作成されている。
例えば，割り込みからリターンしたあとに，システムコール（sleep，usleep，およびnanosleep）が残り時間でリトライする，システムコール（readおよびwrite）が処理リトライする，などがシグナルの割り込みでリターン（エラー番号：EINTR）した場合に該当します。

(2)　HAモニタが提供するファイル

HAモニタでは，UAPがAPIを発行するために次のファイルを提供します。

表6-11　APIを発行するためにHAモニタが提供するファイル

名称
ファイルの格納パス
説明

ヘッダファイル

/opt/hitachi/HAmon/api/include/HA_mon_uap.h

APIを使用するために必要なヘッダファイルです。

APIのオブジェクトファイル

/opt/hitachi/HAmon/api/lib/hamon_api32.a

APIを使用するためにUAPに静的にリンクが必要なオブジェクトファイルです。32ビット環境で動作するUAP用です。

/opt/hitachi/HAmon/api/lib/hamon_api64.a

APIを使用するためにUAPに静的にリンクが必要なオブジェクトファイルです。64ビット環境で動作するUAP用です。

APIの共有ライブラリファイル※

/opt/hitachi/HAmon/api/lib/hamon_api32.so

UAPの実行時に動的に使用するAPIライブラリファイルです。32ビット環境で動作するUAP用です。

/opt/hitachi/HAmon/api/lib/hamon_api64.so

UAPの実行時に動的に使用するAPIライブラリファイルです。64ビット環境で動作するUAP用です。

注※

UAP実行時にAPIのオブジェクトファイルから動的にロードするライブラリです。UAPにリンケージできません。

(3)　UAPの作成

C言語を使用してUAPを作成します。UAPには，HAモニタが提供するAPIを記述します。

また，UAPのスローダウン時に実行するシェルで解析できるように，システムコールやSQLなどの関数の発行前後にトレース情報を取得する処理を記述してください。メモリ上にトレース情報を取得し，coreから解析する方法やメッセージを出力する方法が有効です。

(4)　コンパイルとリンケージ

APIを記述したUAPのソースファイルは，gccコマンドでコンパイルします。

コンパイル時に必須のオプションを，次の表に示します。

表6-12　コンパイル時に必須のオプション

オプション | 意味
-o | 作成するバイナリのファイル名を指定します。
-I/opt/hitachi/HAmon/api/include | ヘッダファイルのパスを指定します。
-L/opt/hitachi/HAmon/api/lib | 共有ライブラリのパスを指定します。
-Wl,-Bdynamic | リンカに「動的ライブラリに対してリンクする」ことを伝えます（デフォルト値であるため，指定しなくても指定時と同じ結果になります）。
-ldl | dlopen関数などのライブラリを使用します。

次に，コンパイル時の例について，64ビット環境と32ビット環境に分けて示します。

64ビット環境の例

C言語で作成したUAPのソースプログラム名

sample.c（メイン関数）

UAPコンパイル時のコマンドラインの例

gcc△-o△sample△-I/opt/hitachi/HAmon/api/include△-L/opt/hitachi/HAmon/api/lib△sample.c△/opt/hitachi/HAmon/api/lib/hamon_api64.a△-Wl,-Bdynamic△-ldl

（凡例）　△：半角スペースを示します。

32ビット環境の例

C言語で作成したUAPのソースプログラム名

sample.c（メイン関数）

UAPコンパイル時のコマンドラインの例

gcc△-o△sample△-I/opt/hitachi/HAmon/api/include△-L/opt/hitachi/HAmon/api/lib△sample.c△/opt/hitachi/HAmon/api/lib/hamon_api32.a△-Wl,-Bdynamic△-ldl

（凡例）　△：半角スペースを示します。

6.13.2　UAPの環境変数の設定

APIを組み込んだUAPを起動するために，UAPの環境変数を設定する必要があります。UAPを起動する場合は，サーバの起動コマンドを実行するシェルなどで，次の環境変数を設定します。

HAMON_UAPNAME環境変数
モニタモードのプログラム対応の環境設定のnameオペランドに指定したプログラム名を指定します。必ず設定してください。
HAモニタは，APIから監視開始要求または監視終了要求を受信したときに，この環境変数で指定したプログラム名でAPI発行元のUAPを特定します。

HAMON_API_PATROL環境変数
HAモニタをインストールしていない，またはHAモニタを起動していないテスト環境などでUAPを動作させる場合だけ，この環境変数にnouseを指定してください。nouseを指定すると，hamon_patrolstart関数，およびhamon_patrolstop関数は，リターンコード0でリターンします。

6.14　定義ファイルの作成（サーバ）

系で稼働させる実行サーバや待機サーバの環境を設定するために，2種類の定義ファイルを作成します。

詳細は，「8.4　サーバの環境設定」を参照してください。

6.15　定義ファイルの作成（モニタモードのプログラム）

モニタモードのサーバで，プログラム管理機能を使用するプログラムの環境を設定する定義ファイルを作成します。

詳細は，「8.5　モニタモードのプログラムの環境設定」を参照してください。

6.16　ユーザコマンドの作成

ユーザコマンドとは，ユーザがあらかじめ作成しておいて，HAモニタに自動的に実行させるコマンドのことです。ユーザコマンドを作成しておくと，サーバやHAモニタの状態変化を契機に，HAモニタにユーザコマンドを自動発行させることができます。このため，ユーザ任意の処理を，サーバやHAモニタの状態変化に合わせてHAモニタに自動で実行させるなどの運用ができます。

ユーザコマンドの作成は任意です。必要に応じて作成してください。

注意

作成したコマンド内の処理については，必要に応じてログを出力するなど，障害解析できるようにしておくことをお勧めします。

＜この節の構成＞

6.16.1　ユーザコマンドが発行されるタイミング（サーバの状態変化時）

6.16.2　ユーザコマンドが発行されるタイミング（HAモニタの状態変化時）

6.16.3　ユーザコマンドの発行形式（サーバの状態変化時）

6.16.4　ユーザコマンドの発行形式（HAモニタの状態変化時）

6.16.5　ユーザコマンドの作成方法

6.16.6　ユーザコマンドのコーディング例

6.16.1　ユーザコマンドが発行されるタイミング（サーバの状態変化時）

HAモニタは，サーバの状態変化やHAモニタの状態変化に合わせてユーザコマンドを自動発行します。状態変化には複数のタイミングがあります。HAモニタは，状態変化の各タイミングに対応したパラメタを引数に指定して，ユーザコマンドを発行します。また，状態が変化したサーバがサーバモードの場合は，各処理の開始時点でHAモニタにユーザコマンドを発行させるか，終了時点で発行させるかを選べます。モニタモードのサーバおよびリソースサーバの場合は，各処理の開始時点だけで発行できます。

ここでは，サーバの状態変化を契機としたユーザコマンド発行時にHAモニタから渡されるパラメタと，ユーザコマンドが発行されるタイミングの詳細について説明します。

＜この項の構成＞

(1)　サーバの状態変化によって渡されるパラメタ

(2)　ユーザコマンドの発行タイミング（サーバの状態変化時）

(1)　サーバの状態変化によって渡されるパラメタ

サーバの状態変化によってユーザコマンドに渡されるパラメタの一覧を，次に示します。

表6-13　サーバの状態変化によってユーザコマンドに渡されるパラメタの一覧

サーバの状態 | サーバ状態パラメタ | 実行サーバでの開始/終了パラメタ※ | 待機サーバでの開始/終了パラメタ※
サーバ起動 | -s | start（起動処理開始） | start（起動処理開始）
end（起動処理終了） | end（起動処理終了）
サーバ正常終了 | -e | start（正常終了処理開始） | start（正常終了処理開始）
－ | end（正常終了処理終了）
サーバ計画終了 | -p | start（計画終了処理開始） | start（計画終了処理開始）
－ | end（計画終了処理終了）
待機サーバ終了 | -e | － | sbyend（コマンド処理開始）
－ | －
実行サーバ障害 | 系切り替えができる場合 | -a | start（障害処理開始） | start（系切り替え処理開始）
end（障害処理終了） | end（系切り替え処理終了）
系切り替えができない場合 | -o | start（障害処理開始） | －
end（障害処理終了） | －
実行サーバの再起動を待つ場合 | -r | start（再起動待ち開始） | －
－ | －
実行サーバの再起動限界を検出した場合 | -n | start（再起動限界検出） | start（再起動限界検出）
－ | －
待機サーバ障害 | -a | － | sbyend（障害処理開始）
－ | －
系障害 | -h | － | start（系切り替え処理開始）
－ | end（系切り替え処理終了）
計画系切り替え | -w | start（コマンド処理開始） | start（系切り替え処理開始）
end（コマンド処理終了） | end（系切り替え処理終了）
系切り替え失敗 | -f | － | start（系切り替え失敗）
－ | －

（凡例）

－：ユーザコマンドは発行されません。

太字：状態変化したサーバがモニタモードのサーバまたはリソースサーバの場合，パラメタは渡されません。そのため，このタイミングでユーザコマンドは発行されません。

注※

上段は開始パラメタ，下段は終了パラメタを記載しています。

(2)　ユーザコマンドの発行タイミング（サーバの状態変化時）

ユーザコマンドの発行タイミングについて説明します。

サーバ起動時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-23　サーバ起動時に渡されるパラメタと発行タイミング

サーバ正常終了時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-24　サーバ正常終了時に渡されるパラメタと発行タイミング

サーバ計画終了時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-25　サーバ計画終了時に渡されるパラメタと発行タイミング

待機サーバ終了時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-26　待機サーバ終了時に渡されるパラメタと発行タイミング

実行サーバ障害時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-27　実行サーバ障害時に渡されるパラメタと発行タイミング

系切り替え不可能時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-28　系切り替え不可能時に渡されるパラメタと発行タイミング

実行サーバ再起動待ち時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-29　実行サーバ再起動待ち時に渡されるパラメタと発行タイミング

実行サーバの再起動待ち限界時間経過時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-30　実行サーバの再起動待ち限界時間経過時に渡されるパラメタと発行タイミング

待機サーバ障害時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-31　待機サーバ障害時に渡されるパラメタと発行タイミング

系障害時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-32　系障害時に渡されるパラメタと発行タイミング

計画系切り替え時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-33　計画系切り替え時に渡されるパラメタと発行タイミング

実行サーバ障害が発生し，系切り替えに失敗した場合に渡されるパラメタと発行タイミングを，次の図に示します。

図6-34　実行サーバ障害が発生し，系切り替えに失敗した場合に渡されるパラメタと発行タイミング

複数スタンバイ構成で，実行サーバ障害が発生して系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミングを次の図に示します。

図6-35　複数スタンバイ構成で，実行サーバ障害が発生して系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミング

系障害が発生し，系切り替えに失敗した場合に渡されるパラメタと発行タイミングを，次の図に示します。

図6-36　系障害が発生し，系切り替えに失敗した場合に渡されるパラメタと発行タイミング

複数スタンバイ構成で，系障害が発生して系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミングを次の図に示します。

図6-37　複数スタンバイ構成で，系障害が発生して系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミング

計画系切り替えで，系切り替えに失敗した場合に渡されるパラメタと発行タイミングを，次の図に示します。

図6-38　計画系切り替えで，系切り替えに失敗した場合に渡されるパラメタと発行タイミング

複数スタンバイ構成で，計画系切り替えで系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミングを次の図に示します。

図6-39　複数スタンバイ構成で，計画系切り替えで系切り替えに失敗し，ほかの待機サーバに系切り替えする場合に渡されるパラメタと発行タイミング

6.16.2　ユーザコマンドが発行されるタイミング（HAモニタの状態変化時）

HAモニタは，サーバの状態変化やHAモニタの状態変化に合わせてユーザコマンドを自動発行します。状態変化には複数のタイミングがあります。HAモニタは，状態変化の各タイミングに対応したパラメタを引数に指定して，ユーザコマンドを発行します。

ここでは，HAモニタの状態変化を契機としたユーザコマンド発行時にHAモニタから渡されるパラメタと，ユーザコマンドが発行されるタイミングの詳細について説明します。

＜この項の構成＞

(1)　HAモニタの状態変化によって渡されるパラメタ

(2)　ユーザコマンドの発行タイミング（HAモニタの状態変化時）

(1)　HAモニタの状態変化によって渡されるパラメタ

HAモニタの状態変化によってユーザコマンドに渡されるパラメタの一覧を，次の表に示します。

表6-14　HAモニタの状態変化によってユーザコマンドに渡されるパラメタの一覧

HAモニタの状態 | HAモニタ状態パラメタ | 自系での開始/終了パラメタ | 他系についての詳細情報パラメタ
自系のHAモニタ開始 | -m | start（開始処理開始） | －
自系のHAモニタ終了 | end（終了処理終了） | －
他系のHAモニタ障害検出 | － | -d ホスト名（ホスト名で示す他系のHAモニタ障害検出）

（凡例）－：パラメタは渡されません。

(2)　ユーザコマンドの発行タイミング（HAモニタの状態変化時）

ユーザコマンドの発行タイミングについて説明します。

HAモニタ開始・終了時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-40　HAモニタ開始・終了時に渡されるパラメタと発行タイミング

他系のHAモニタ障害検出時に渡されるパラメタと発行タイミングを，次の図に示します。

図6-41　他系のHAモニタ障害検出時に渡されるパラメタと発行タイミング

他系のHAモニタ障害検出時（-m -d ホスト名）には，障害が発生した系とペアで，かつ系切り替えを実施する系だけでユーザコマンドが発行されます。

6.16.3　ユーザコマンドの発行形式（サーバの状態変化時）

サーバの状態変化時にHAモニタが発行するユーザコマンドの形式について説明します。

＜この項の構成＞

(1)　HAモニタが発行するユーザコマンドの形式

(2)　パラメタ

(3)　HAモニタが発行するユーザコマンドの形式例

(1)　HAモニタが発行するユーザコマンドの形式

サーバの状態変化時，HAモニタは，ユーザが作成したユーザコマンドを次の形式で発行します。

コマンド名 -n サーバ識別名 -k サーバ種別 サーバ状態パラメタ 開始/終了パラメタ

(2)　パラメタ

コマンド名

ユーザが作成しHAモニタの環境設定で指定した，ユーザコマンドのコマンド名を示します。

-n サーバ識別名

状態が変化しユーザコマンドを発行する契機となった，サーバの識別名を示します。

-k サーバ種別

サーバ識別名で示したサーバの種別を示します。次のどちらかが渡されます。

online：実行サーバの場合

standby：待機サーバの場合

サーバ状態パラメタ

サーバ識別名で示したサーバの状態を示します。次のどれかが渡されます。

-s：サーバ起動状態

-e：サーバ正常終了状態

-p：サーバ計画終了状態

-a：サーバ障害状態（障害処理終了後，系切り替え処理ができる場合）

-o：サーバ障害状態（障害処理終了後，系切り替え処理ができない場合）

-f：サーバ障害状態（障害処理終了後，系切り替え処理が途中で失敗した場合）

-r：サーバ障害状態（障害処理終了後，実行サーバの再起動を待つ場合）

-n：サーバ障害状態（障害処理終了後，実行サーバの再起動監視時間が経過した場合）

-h：系障害状態

-w：計画系切り替え状態

開始/終了パラメタ

サーバ識別名で示したサーバの状態変化（HAモニタの処理）の開始時点か終了時点かを示します。次のどれかが渡されます。

start：サーバの状態変化（HAモニタの処理）の開始時点

end：サーバの状態変化（HAモニタの処理）の終了時点

sbyend：待機サーバだけの状態変化（HAモニタの処理）の開始時点

なお，モニタモードのサーバおよびリソースサーバの場合，次に示すサーバ状態パラメタと開始/終了パラメタの組み合わせだけが渡されます。

サーバ起動状態：-s start

サーバ正常終了状態：-e start，-e sbyend

サーバ障害状態（系切り替え不可能）※：-o start，-o end

系障害状態：-h start

計画系切り替え状態：-w start

注※　このパラメタは，モニタモードのサーバに対してサーバ対応の環境設定のwaitserv_execオペランドにyesを指定した場合で，サーバ対応の環境設定のnameオペランドに指定したサーバの起動コマンドの実行結果（終了コード）が0以外のときに渡されます。

(3)　HAモニタが発行するユーザコマンドの形式例

ユーザコマンド（/usr/bin/usrcmd）を実行サーバ（server）の起動時に発行した場合

/usr/bin/usrcmd -n server -k online -s start

ユーザコマンド（/usr/bin/usrcmd）を実行サーバ（server）のサーバ障害時（実行サーバの障害処理開始時）に発行した場合

/usr/bin/usrcmd -n server -k online -a start

ユーザコマンド（/usr/bin/usrcmd）を実行サーバ（server）のサーバ障害時（実行サーバの障害処理終了時）に発行した場合

/usr/bin/usrcmd -n server -k online -a end

ユーザコマンド（/usr/bin/usrcmd）を実行サーバ（server）のサーバ障害時（待機サーバの系切り替え処理開始時）に発行した場合

/usr/bin/usrcmd -n server -k standby -a start

ユーザコマンド（/usr/bin/usrcmd）を実行サーバ（server）のサーバ障害時（待機サーバの系切り替え処理終了時）に発行した場合

/usr/bin/usrcmd -n server -k standby -a end

6.16.4　ユーザコマンドの発行形式（HAモニタの状態変化時）

HAモニタの状態変化時にHAモニタが発行するユーザコマンドの形式について説明します。

＜この項の構成＞

(1)　HAモニタが発行するユーザコマンドの形式

(2)　パラメタ

(3)　HAモニタが発行するユーザコマンドの形式例

(1)　HAモニタが発行するユーザコマンドの形式

HAモニタの状態変化時，HAモニタは，ユーザが作成したユーザコマンドを次の形式で発行します。

コマンド名 HAモニタ状態パラメタ [開始/終了パラメタ] [詳細情報パラメタ]

(2)　パラメタ

コマンド名

ユーザが作成しHAモニタの環境設定で指定した，ユーザコマンドのコマンド名を示します。

HAモニタ状態パラメタ

HAモニタの状態を示します。次のパラメタが渡されます。

-m：HAモニタ開始・終了状態，または他系のHAモニタ障害状態

開始/終了パラメタ

HAモニタの状態変化（HAモニタの処理）の開始時点か終了時点かを示します。次のどちらかが渡されます。

start：HAモニタの状態変化（HAモニタの処理）の開始時点

end：HAモニタの状態変化（HAモニタの処理）の終了時点

詳細情報パラメタ

HAモニタ状態パラメタで示された状態が「他系のHAモニタ障害状態」だった場合に，どの系のHAモニタの状態なのかを示します。次のパラメタが渡されます。

-d ホスト名：HAモニタが障害状態となったホスト名

他系のHAモニタ障害検出時（-m -d ホスト名）には，障害が発生した系とペアで，かつ系切り替えを実施する系だけでユーザコマンドが発行されます。

(3)　HAモニタが発行するユーザコマンドの形式例

ユーザコマンド（/usr/bin/usrcmd）を，自系のHAモニタの開始時に発行した場合

/usr/bin/usrcmd -m start

ユーザコマンド（/usr/bin/usrcmd）を，ホスト名 hostにあるHAモニタの障害検出時に発行した場合

/usr/bin/usrcmd -m -d host

6.16.5　ユーザコマンドの作成方法

ここでは，ユーザコマンドの作成方法について説明します。作成したユーザコマンドは，HAモニタの環境設定のusrcommandオペランドに設定してください。

ユーザコマンドは，系で一つ作成します。ユーザコマンドの作成には，C言語やシェル言語などを使用できます。

ユーザコマンド発行時には，HAモニタは，状態が変化したサーバやHAモニタの情報を引数としてユーザコマンドに渡します。そのため一つのファイル内で，HAモニタから渡される引数を使用してサーバの状態変化やHAモニタの状態変化の条件分けをして，各状態変化時にユーザが実行したい処理を記述します。

サーバの状態変化を契機にユーザコマンドを発行する場合，次の点を考慮します。

実行サーバと待機サーバとで異なる処理を実行するには，サーバ種別を判定する処理を記述します。

一つの系で複数のサーバを実行する場合，サーバによって異なる処理を実行させるには，サーバ識別名を判定する処理を記述します。

サーバ種別やサーバ識別名は，ユーザコマンド実行時にHAモニタから引数として渡されます。HAモニタから渡される引数については，「6.16.3　ユーザコマンドの発行形式（サーバの状態変化時）」を参照してください。

注意

ユーザコマンドはHAモニタの処理中に発行されるため，ユーザコマンド内で無限ループなどが発生した場合は，HAモニタの処理を保証できません。ユーザコマンドは，無限ループなどが発生しないように注意して作成してください。ユーザコマンドが無限ループすると，サーバが起動または停止処理中のままになるおそれがあります。

ユーザコマンド内に記述できるコマンド

HAモニタのコマンドを，ユーザコマンドから実行できます。
ただし，HAモニタの開始・終了時（-m start，-m end）に発行されるユーザコマンドからは実行できません。

実行サーバと待機サーバ間で，情報を引き継ぐためのコマンドがあります。
サーバ引き継ぎ情報設定・表示コマンド（moninfoコマンド）を使用すると，任意の情報を実行サーバから待機サーバに引き継げます。また，引き継ぐ情報を参照できます。

これらのコマンドについては，「9.　コマンド」を参照してください。

ユーザコマンドの戻り値判定

HAモニタでは，ユーザコマンドの実行結果をチェックしません。HAモニタは，ユーザコマンドの実行結果に関係なく動作します。

ただし，ユーザコマンドの実行結果を判定して，サーバの起動や系切り替えを中止する機能もあります。サーバの起動開始時（-s start）および系切り替え開始時（-w start，-a start，-h start）に実行されるユーザコマンドについては，サーバ対応の環境設定のuoc_neckオペランドを使用することによって，ユーザコマンドの実行結果（終了コード）が0以外の場合，サーバの起動または系切り替えを中止できます。

HAモニタの処理とユーザコマンドの処理との同期・非同期

HAモニタの処理とユーザコマンドの処理は同期を取って行われます。ただし，次の場合はHAモニタの処理終了とユーザコマンドの終了とが非同期になります。

実行サーバの起動処理終了時（-k online -s end）

実行サーバ障害による系切り替え処理終了時（-k standby -a end）

計画系切り替えによる系切り替え処理終了時（-k standby -w end）

系障害による系切り替え処理終了時（-h end）

実行サーバ障害で実行サーバの再起動を待つ場合（-r）

実行サーバ障害で再起動限界を検出した場合（-n）

共有リソースを制御するためのユーザコマンド作成

共有リソースを制御するためのユーザコマンド作成時には，次の点を考慮してください。

実行サーバが起動する前に，共有リソースに接続する。
実行サーバが共有リソースを使えるようにするため，起動前に共有リソースに接続します。

系間で排他制御が必要なリソースは，実行サーバが停止したあとに切り離す。
両方の系から同時に接続しないようにするため，実行サーバが停止したあとに切り離します。

必要に応じて，実行サーバから待機サーバに共有リソースの情報を引き継ぐ。
実行サーバから待機サーバに共有リソースの情報を引き継ぐには，サーバ引き継ぎ情報設定・表示コマンド（moninfoコマンド）を使用できます。

6.16.6　ユーザコマンドのコーディング例

ユーザコマンドのコーディング例として，サーバのIPアドレスを切り替える処理の例について説明します。(1)では，コーディング例の一部分を取り上げて，ユーザコマンドのコーディング方法を説明します。(2)では，コーディング例全体を示します。

なお，サーバのIPアドレスを切り替える処理は，LANの状態設定ファイルを設定する方法でも実現できます。LANの状態設定ファイルを設定する場合，ユーザコマンドの作成は不要です。

＜この項の構成＞

(1)　コーディング例で示すユーザコマンドの説明

(2)　コーディング例

(1)　コーディング例で示すユーザコマンドの説明

サーバが使用するIPアドレスを，次のタイミングで追加・削除する場合について説明します。

サーバ起動時（サーバ起動処理の開始時点）には実行サーバでIPアドレスを追加し，待機サーバでは何も実行しない。

実行サーバ障害時（障害処理の開始時点）には実行サーバでIPアドレスを削除し，待機サーバでIPアドレスを追加する。

これらのタイミングを次に示します。図中で示す番号は，コーディング例の一部分と対応しています。

図6-42　ユーザコマンドのコーディング例で示す発行タイミング

ユーザコマンドのコーディング例と発行タイミングの対応を次に示します。

図6-43　ユーザコマンドのコーディング例と発行タイミングの対応

（1）では，サーバ起動時（サーバ起動処理の開始時点）に実行サーバで実行したい処理を記述します。この例では，IPアドレスを追加するコマンドとしてipaddr_addを記述しています。

（2）では，サーバ起動時（サーバ起動処理の開始時点）に待機サーバで実行したい処理を記述します。この例では何も実行しないため，何も記述していません。

（3）では，実行サーバ障害時（障害処理の開始時点）に実行サーバで実行したい処理を記述します。この例では，IPアドレスを削除するコマンドとしてipaddr_deleteを記述しています。

（4）では，実行サーバ障害時（障害処理の開始時点）に待機サーバで実行したい処理を記述します。この例では，IPアドレスを追加するコマンドとしてipaddr_addを記述しています。

（1）から（4）の発行タイミングごとに，HAモニタから渡される変数とHAモニタが発行するユーザコマンドの対応を次に示します。

表6-15　HAモニタから渡される変数とHAモニタが発行するユーザコマンドの対応

発行タイミングの番号 | $4 | $5 | $6 | HAモニタが発行するユーザコマンド※
（1） | online | -s | start | /usr/bin/usrcmd -n server -k online -s start
（2） | standby | -s | start | /usr/bin/usrcmd -n server -k standby -s start
（3） | online | -a | start | /usr/bin/usrcmd -n server -k online -a start
（4） | standby | -a | start | /usr/bin/usrcmd -n server -k standby -a start

注※　ユーザコマンド名およびサーバ識別名はそれぞれ次を仮定しています。

ユーザコマンド名：/usr/bin/usrcmd

サーバ識別名：server

(2)　コーディング例

このコーディング例は，サンプルファイルとしてHAモニタのサンプルファイル用ディレクトリの下に格納されています。

#!/bin/sh

# The definition of the 1st server
SERV1="server1"
IPADDR_SERV1="a.b.c.d"
BROADCAST_SERV1="e.f.g.h"
IFNAME_SERV1="ethX:Y1"

# The definition of the 2nd server
SERV2="server2"
IPADDR_SERV2="i.j.k.l"
BROADCAST_SERV2="m.n.o.p"
IFNAME_SERV2="ethX:Y2"

# The alias IP address is added to the LAN interface.
# The ARP caches are updated.
ipaddr_add()
{
       /sbin/ifconfig $WIFNAME inet $WIPADDR netmask 255.255.255.0 broadcast $WBROADCAST
       ARPIFNAME=`echo $WIFNAME | /bin/sed -e 's/:[0-9]*$//'`
       /sbin/arping -U -c 2 -I $ARPIFNAME $WIPADDR
       /bin/echo 0 > /proc/sys/net/ipv4/route/flush
       return 0
}

# The alias IP address is deleted from the LAN interface.
ipaddr_delete()
{
       /sbin/ifconfig $WIFNAME down
       /bin/echo 0 > /proc/sys/net/ipv4/route/flush
       return 0
}

#  Main
KIND_ONLINE="online"
KIND_STANDBY="standby"
SERV_START="-s"
SERV_END="-e"
SERV_PLANEND="-p"
SERV_ABORT="-a"
SERV_ABORT_NS="-o"
SERV_FAULT="-f"
SERV_HOSTDOWN="-h"
SERV_PLANSWAP="-w"
STATUS_START="start"
STATUS_END="end"
STATUS_SBYEND="sbyend"

# This user command terminates, when the state of HAmonitor has changed.
if [ "$1" = "-m" ]
then
       exit  1
fi

# Processing of the server
for serv in $SERV1 $SERV2
do
       if [ "$2" = "$serv" ]
       then
               case "$serv" in
               "$SERV1" )
                       WIPADDR="$IPADDR_SERV1"
                       WBROADCAST="$BROADCAST_SERV1"
                       WIFNAME="$IFNAME_SERV1"
                       ;;
               "$SERV2" )
                       WIPADDR="$IPADDR_SERV2"
                       WBROADCAST="$BROADCAST_SERV2"
                       WIFNAME="$IFNAME_SERV2"
                       ;;
               esac

               if [ "$4" = "$KIND_ONLINE" ]
               then
                       case "$5" in
                       "$SERV_START" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_add
                               ;;
                       "$SERV_END" )
                               ipaddr_delete
                               ;;
                       "$SERV_PLANEND" )
                               ipaddr_delete
                               ;;
                       "$SERV_ABORT" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_delete
                               ;;
                       "$SERV_ABORT_NS" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_delete
                               ;;
                       "$SERV_PLANSWAP" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_delete
                               ;;
                       esac

               else
                       case "$5" in
                       "$SERV_START" )
                               ;;
                       "$SERV_END" )
                               ;;
                       "$SERV_PLANEND" )
                               ;;
                       "$SERV_ABORT" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_add
                               ;;
                       "$SERV_FAULT" )
                               ipaddr_delete
                               ;;
                       "$SERV_HOSTDOWN" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_add
                               ;;
                       "$SERV_PLANSWAP" )
                               [ "$6" = "$STATUS_START" ] && ipaddr_add
                               ;;
                       esac
               fi
       fi
done

exit 0

6.17　HAモニタ Extensionの設定

HAモニタ Extensionを使用する場合には，HAモニタの環境設定コマンド（monsetup -exコマンド）を実行して，HAモニタ Extensionの機能を使用するための設定をします。HAモニタの環境設定コマンド（monsetup -exコマンド）については，「9.　コマンド」の「monsetup（HAモニタの環境設定）」を参照してください。

6.18　構築したシステムの設定・定義のチェック

リセットパスの設定，および定義ファイルの作成が完了したら，それぞれ設定に誤りがないかをチェックします。ここでは，複数系切り替え構成間での設定・定義のチェックと，定義ファイルのチェックについて説明します。

＜この節の構成＞

6.18.1　複数系切り替え構成間での設定・定義のチェック

6.18.2　定義チェック

6.18.1　複数系切り替え構成間での設定・定義のチェック

使用するOSに関係なく，系切り替え構成が複数存在するシステムでは，HAモニタの環境設定のaddressオペランドの値やHAモニタのリセットパスに設定したIPアドレスに重複がある場合は，系切り替え構成間で次のような事象が発生するおそれがあります。

系の障害時に，無関係な別の系切り替え構成の系も障害になってしまう。

系のリブート時に，無関係な別の系切り替え構成の系も障害になってしまう。

これらの事象を事前に回避するため，系切り替え構成が複数存在するシステムの場合は，addressオペランドの値に重複がないか，およびHAモニタのリセットパスに設定したIPアドレスに重複がないかをチェックします。リセットパスに設定したIPアドレスのチェックには，IPアドレス検出コマンド（monlistipコマンド）を使用できます。IPアドレス検出コマンド（monlistipコマンド）については，「9.　コマンド」の「monlistip（IPアドレスの検出）」を参照してください。

複数系切り替え構成間での設定・定義のチェック手順を，次の図に示します。

図6-44　複数系切り替え構成間での設定・定義のチェック手順

チェック手順の詳細について説明します。番号は，図中の番号と対応しています。

リセットパスのネットワーク内にある機器をリストアップする。
次のどちらかの方法でリストアップできます。リストアップの漏れがないようにしてください。

IPアドレス検出コマンド（monlistipコマンド）を実行する。
このコマンドは，どれか一つの系から実行します。実行結果は，csvファイルで出力されます。このファイルをWindows OSのマシンに転送すれば，表計算ソフトで編集できます。以降の手順の調査結果の入力などに利用できます。

ネットワーク管理者に問い合わせる。

HAモニタを適用できる機器かどうかを調査する。
手順1.でリストアップした機器の中から，マシンの機種，およびOSを確認し，HAモニタを使用している可能性がある機器かどうかを調査します。HAモニタを適用できるマシンの機種については，リリースノートを参照してください。HAモニタを適用できるOSは，AIX，HP-UX，およびLinuxです。OSの調査方法の例を次に示します。

telnetでログイン時のプロンプトから判断する。

リモートシェル（rsh）でunameコマンドを実行し，その結果から判断する。

HAモニタの使用有無を調査する。
手順2.でHAモニタを使用している可能性があると判断した機器に，HAモニタのディレクトリが存在するかどうかでHAモニタを使用しているかどうかを判断します。手順2.で調査したマシンにログインして次のコマンドを実行します。

ls /opt/hitachi/HAmon

bin，etc，lib，spoolの四つのディレクトリが見つかった場合，HAモニタを使用していると判断できます。

HAモニタを使用しているすべての機器に設定されている，HAモニタの環境設定のaddressオペランドの値を調査する。
複数の機器で使用しているHAモニタで，addressオペランドの値が重複していないかを確認します。
addressオペランドの値が重複している場合は，手順5.に進みます。重複していない場合，チェックはこれで完了です。

HAモニタを使用しているすべての機器で，HAモニタの環境設定コマンド（monsetupコマンド）を実行して，リセットパスの設定を調査する。
HAモニタの環境設定コマンド（monsetupコマンド）に-ttyオプション（OSがAIXの場合）または-resetpathオプション（OSがHP-UXまたはLinuxの場合）を指定して，リセットパスの設定内容を調査します。
調査項目を次に示します。

リセットパスのポート番号

SVPのポート番号，または接続先の系切替機構のポート番号

交代用リセットパスのポート番号

接続先の交代用系切替機構のポート番号

IPアドレスの重複がないかを確認する。
手順4.で調査したaddressオペランドの指定値が重複しているそれぞれの系で，手順5.で調査した項目のどれか二つ以上が重複している場合，手順1.でリストアップしたIPアドレスが重複しています。
IPアドレスが重複している場合は，手順7.に進みます。重複していない場合，チェックはこれで完了です。

IPアドレスの重複に対処する。
次のどちらかの対処を実施します。

手順4.および手順5.で重複していた値が，重複しないように変更する。
リセットパスの設定を修正する場合は，HAモニタの環境設定，SVP，および接続先の系切替機構の修正漏れがないように注意してください。

IPアドレスが重複している系同士が通信できないように，ネットワークを分ける。

6.18.2　定義チェック

HAモニタの環境設定，サーバの環境設定，およびモニタモードのプログラムの環境設定での定義内容をチェックし，誤りがないことを確認します。定義チェックを実行するためには，定義チェックコマンド（moncheckコマンド）を実行します。

HAモニタの起動時，およびサーバの起動時には，自動的に定義チェックが実行されます。定義が誤ったままHAモニタを起動すると，HAモニタを正しく起動できません。そのため，HAモニタの起動前に定義チェックをして，定義ファイルに誤りがないことを確認してください。定義チェックは，構築時だけでなく，定義ファイルを修正したあとにも実行できます。定義チェックコマンド（moncheckコマンド）については，「9.　コマンド」の「moncheck（定義チェック）」を参照してください。

定義チェックでチェックする項目は，次のとおりです。

基本規則のチェック

定義の基本規則で示したとおりの内容か。

記述形式のチェック

定義の記述形式で示したとおりの形式か。

定義文のチェック

定義文は正しいか。

定義文の形式は正しいか。

必要な定義文が指定されているか。

HAモニタの環境設定が複数設定されていないか。

オペランドチェック

オペランドは正しいか。

オペランドの形式は正しいか。

必要なオペランドが指定されているか。

値のチェック

必要な値が指定されているか。

文字の指定方法は正しいか。

値の有効範囲は正しいか。

値の複数指定の場合，指定数は正しいか。

複数のサーバで，共有リソースのオペランドに同じ値が指定されていないか。

文字のチェック

文字の構成要素記号は正しいか。

6.19　障害情報を収集するための設定

HAモニタでは，シェルを実行させて，サーバのスローダウンの原因を調査するための情報を収集できます。シェルは，HAモニタを起動する前に作成しておきます。

詳細については，「7.5.4　サーバのスローダウンの原因を調査する」を参照してください。

6.20　構築したシステムの動作確認

システムの構築が完了して設定と定義のチェックに問題がなかったら，構築システムの動作確認をしてください。動作確認では，実際にHAモニタの起動・停止，サーバの起動・停止，および系切り替えを実行することで，正常に動作するかどうかを確認します。

次の項目に注意して，システムの動作確認をしてください。

HAモニタやサーバを正常に起動・停止できるか。

エラーメッセージは出力されていないか。

サーバとクライアント間で通信できるか。

サーバを使用した業務処理ができるか。

系切り替えをした場合，共有リソースを系切り替え後の系から使用できるか。

システムの動作確認の流れを，次に示します。

図6-45　システムの動作確認の流れ

注※1　HAモニタの停止時には，HAモニタの接続構成設定ファイルの確認もします。

注※2　モニタモードのプログラム管理機能を使用している場合にだけ実施します。

＜この節の構成＞

6.20.1　HAモニタの動作確認

6.20.2　サーバの動作確認

6.20.3　系切り替えのテスト

6.20.4　システムに掛かる負荷のテスト

6.20.1　HAモニタの動作確認

設定と定義のチェックが完了したら，HAモニタの動作確認として，起動確認，状態確認，および停止確認をします。HAモニタの停止確認時に，HAモニタの接続構成設定ファイルを自動作成できます。次に示すHAモニタの状態確認の手順は，接続構成設定ファイルを自動作成することを前提に説明しています。

注意

使用しているマシンの機種がHA8500の場合，障害管理プロセサ用のLANポートを使用できない設定のまま，HAモニタを稼働させないでください。系障害が発生して系のリセットが実行された場合に，実行・待機系の両方がオンライン状態になるおそれがあります。オンライン状態になった両系が共有ディスクに同時にアクセスすると，共有ディスクの内容が破損します。

HAモニタを起動するときは，リセットパスが正しく構築されているかどうか，およびLANポートが使用できる設定になっているかどうかを，必ず確認してください。

＜この項の構成＞

(1)　HAモニタの起動確認

(2)　HAモニタの状態確認

(3)　HAモニタの停止確認および接続構成設定ファイルの確認（自動作成の場合）

(1)　HAモニタの起動確認

現用系と予備系の両方で，接続するすべてのHAモニタを起動します。HAモニタの起動コマンド（monstartコマンド）を実行して，すべてのHAモニタを手動で起動してください。メッセージKAMN002-Iが出力されれば，HAモニタの起動が完了したことを示しています。

(2)　HAモニタの状態確認

起動したHAモニタすべてが，正しく接続されたかどうかを確認します。ここでは次の項目について，正常な状態かどうかを確認します。

系
サーバ・系の状態表示コマンド（monshow -cコマンド）を実行します。
HAモニタが系を認識できたときの，コマンドの実行結果の例を次に示します。HAモニタと接続した系がすべて設定したとおりに表示されていれば，正しく認識できたことを示しています。

KAMN335-I  Connected host information
      Host name     Host address Patrol time
      host1              100          10
      host2              200          10

監視パス
監視パス状態表示コマンド（monpathコマンド）を実行します。
HAモニタが監視パスを認識できたときの，コマンドの実行結果の例を次に示します。"status"に表示される監視パスの状態がすべて"OK"になっていれば，正しく認識できたことを示しています。

KAMN390-I Path status Display
device name host name status
path11      host2     OK  *
path12      host2     OK

リセットパス
実行するコマンドは，使用しているマシンの機種によって次のとおり異なります。

BladeSymphonyまたはHA8000の場合，リセットパス状態表示コマンド（monrpコマンド）を実行します。

HA8500の場合，MP状態表示コマンド（monmpコマンド）を実行します。

HAモニタがリセットパスを認識できたときの，コマンドの実行結果の例を次に示します。"status"に表示されるリセットパスの状態がすべて"OK"になっていれば，正しく認識できたことを示しています。

KAMN395-I Reset Path status Display
host name                         status
host2                             OK

(3)　HAモニタの停止確認および接続構成設定ファイルの確認（自動作成の場合）

起動したHAモニタがすべて正しく接続されていることを確認したら，HAモニタの停止ができることを確認します。HAモニタを停止すると，HAモニタの接続構成設定ファイルが自動で作成されるため，HAモニタの接続構成設定ファイルの内容もあわせて確認します。次に手順を示します。

接続するHAモニタをすべて停止させる。
接続するHAモニタをすべて，手動で停止します。HAモニタの停止コマンド（monstopコマンド）を実行することで停止できます。メッセージKAMN050-Iが出力されれば，HAモニタの停止が完了したことを示しています。
このとき，HAモニタの接続構成設定ファイルが停止した系に作成されます。

自動作成された接続構成設定ファイルの内容を確認する。
自動作成された接続構成設定ファイルの内容が正しいかどうかを確認します。自動で作成された接続構成ファイルは，すべての系で同じ内容です。

接続構成設定ファイルを自動作成した場合，構成を変更したり，削除したりすることはできません。また，自系および自系と監視し合う系にだけ直接監視パスを設定したい場合や，構成を変更したり削除したりする場合は，手動で作成してください。

接続するHAモニタの数を増やしたい場合は，HAモニタの起動から停止までの操作手順を，再び行ってください。新しいHAモニタの接続情報が，接続構成設定ファイルに自動で追加されます。自動でHAモニタを追加した場合，それ以前に設定していた接続構成設定ファイルのコメント行以外の項目が自動で変更されます。

6.20.2　サーバの動作確認

サーバの動作確認は，HAモニタを起動してから実施してください。

＜この項の構成＞

(1)　サーバの起動確認

(2)　サーバの状態確認

(3)　プログラムの再起動確認

(4)　サーバの停止確認

(1)　サーバの起動確認

サーバを起動できることを確認します。メッセージKAMN252-Iが出力されれば，サーバの起動が完了し，系切り替えができる状態になったことを示しています。

サーバの起動方法を，次に示します。

サーバモードのサーバの場合

該当するプログラムの起動方法で起動してください。サーバを実行サーバとして起動するか，待機サーバとして起動するかはHAモニタが決定します。HAモニタは，サーバ対応の環境設定および他系の状態を基に決定します。

モニタモードのサーバの場合

ユーザがモニタモードのサーバ起動コマンド（monbeginコマンド）を実行して起動してください。サーバを実行サーバとして起動するか，待機サーバとして起動するかはHAモニタが決定します。HAモニタは，サーバ対応の環境設定および他系の状態を基に決定します。

(2)　サーバの状態確認

サーバの起動確認が完了したら，HAモニタがサーバの起動を認識したかどうかを調べるために，サーバの状態を確認します。サーバの状態を確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を実行してください。

HAモニタがサーバの起動を認識できたときの，コマンドの実行結果の例を次に示します。実行サーバの状態が"ONL"，待機サーバの状態が"SBY"ならば，正しく認識できたことを示しています。

#/opt/hitachi/HAmon/bin/monshow
KAMN213-I Own host name : host1
   Own servers               Pair servers
   Alias     Status          Status     Host name
   server1   ONL             SBY        host2

なお，サーバがモニタモードで，かつプログラム管理機能を使用している場合は，プログラムの状態も確認します。プログラムの状態を確認するには，サーバ・系の状態表示コマンド（monshowコマンド）に-uオプションを指定して実行してください。

HAモニタがプログラムの起動を認識できたときの，コマンドの実行結果の例を次に示します。プログラムの状態が"ACT"ならば，正しく認識できたことを示しています。

#/opt/hitachi/HAmon/bin/monshow -u
KAMN213-I Own host name : host1
    Alias     Program Alias  Status   Patrol time
    server1   UAP1            ACT        3600

(3)　プログラムの再起動確認

モニタモードのプログラム管理機能を使用し，プログラムの再起動コマンドを作成した場合は，プログラムが再起動できることを確認します。

サーバの起動確認が完了したら，意図的にプログラム障害を発生させて，プログラムの状態を確認します。これによって，HAモニタがプログラムの再起動を実行したかどうかを調べます。プログラムの状態を確認するには，サーバ・系の状態表示コマンド（monshowコマンド）に-uオプションを指定して実行してください。

HAモニタがプログラムの再起動を認識できたときの，コマンドの実行結果の例を次に示します。プログラムの状態が"ACT"ならば，正しく認識できたことを示しています。

#/opt/hitachi/HAmon/bin/monshow -u
KAMN213-I Own host name : host1
    Alias     Program Alias  Status   Patrol time
    server1   UAP1            ACT        3600

(4)　サーバの停止確認

サーバを停止できることを確認します。サーバ・系の状態表示コマンド（monshowコマンド）を実行し，サーバが表示されなければ，サーバの停止処理は完了です。

サーバの停止方法を，次に示します。

サーバモードでサーバを起動している場合

該当するプログラムの停止方法で停止してください。このとき，対応する待機サーバが起動している場合は，HAモニタが停止させます。

モニタモードでサーバを起動している場合

ユーザがモニタモードのサーバ停止コマンド（monendコマンド）を実行して，すべてのサーバを手動で停止してください。

6.20.3　系切り替えのテスト

HAモニタの動作確認およびサーバの動作確認が完了したら，系切り替えのテストをします。系切り替えのテストは，HAモニタおよびサーバを起動してから実施してください。

＜この項の構成＞

(1)　計画系切り替えの確認

(2)　サーバ障害時の自動系切り替えの確認

(3)　プログラム障害時の自動系切り替えの確認

(4)　系障害時の自動系切り替えの確認

(1)　計画系切り替えの確認

計画系切り替えコマンド（monswapコマンド）を実行して，計画系切り替えのテストを実行してください。計画系切り替えを実行したら，サーバ・系の状態表示コマンド（monshowコマンド）を実行してください。

系1から系2に計画系切り替えのテストを実行した場合でテストに成功したときの，サーバ・系の状態表示コマンド（monshowコマンド）の実行結果の例を次に示します。切り替え先のサーバの状態が"ONL"ならば，計画系切り替えに成功したことを示しています。

#/opt/hitachi/HAmon/bin/monshow
KAMN213-I Own host name : host2
   Own servers               Pair servers
   Alias     Status          Status     Host name
   server2   ONL

(2)　サーバ障害時の自動系切り替えの確認

ユーザがサーバ障害を発生させ，HAモニタが自動系切り替えを実行するかどうかを確認してください。障害が回復したら，サーバ・系の状態表示コマンド（monshowコマンド）を実行してください。

系1から系2への自動系切り替えが成功したときの，サーバ・系の状態表示コマンド（monshowコマンド）の実行結果の例を示します。切り替え先のサーバの状態が"ONL"ならば，自動系切り替えに成功したことを示しています。

#/opt/hitachi/HAmon/bin/monshow
KAMN213-I Own host name : host2
   Own servers               Pair servers
   Alias     Status          Status     Host name
   server2   ONL

(3)　プログラム障害時の自動系切り替えの確認

サーバがモニタモードで，かつプログラム管理機能を使用している場合は，ユーザがプログラム障害を発生させ，HAモニタが自動系切り替えを実行するかどうかを確認してください。障害が回復したら，サーバ・系の状態表示コマンド（monshowコマンド）に-uオプションを指定して実行してください。

プログラム障害時の自動系切り替えが成功したときの，サーバ・系の状態表示コマンド（monshowコマンド）の実行結果の例を次に示します。プログラムの状態が"ACT"ならば，自動系切り替えに成功したことを示しています。

#/opt/hitachi/HAmon/bin/monshow -u
KAMN213-I Own host name : host2
    Alias     Program Alias  Status   Patrol time
    server2   UAP1            ACT        3600

(4)　系障害時の自動系切り替えの確認

ユーザが系障害を発生させ，HAモニタが自動系切り替えを実行するかどうかを確認してください。リセットパスの設定で，VMware ESXiで仮想化する設定をした場合は，リセットパスが正しく設定されているかを確認するため，自系に系障害を発生させて仮想マシンがリセットされることを確認してください。

障害が回復したら，サーバ・系の状態表示コマンド（monshowコマンド）を実行してください。

対象となる系を強制停止させることで，系障害を発生させることができます。

系1から系2への自動系切り替えが成功したときの，サーバ・系の状態表示コマンド（monshowコマンド）の実行結果の例を示します。切り替え先のサーバの状態が"ONL"ならば，自動系切り替えに成功したことを示しています。

#/opt/hitachi/HAmon/bin/monshow
KAMN213-I Own host name : host2
   Own servers               Pair servers
   Alias     Status          Status     Host name
   server2   ONL

6.20.4　システムに掛かる負荷のテスト

系切り替えのテストが完了したら，システムに掛かる負荷のテストをします。実際の運用と同じようにシステムを稼働させ，定義ファイルに指定した系障害監視時間またはサーバ障害監視時間に問題がないかをテストしてください。

システムに掛かる負荷のテストは，監視履歴を使用して行います。監視履歴については，「7.5　高負荷による障害発生を防止するための運用」を参照してください。

システムに掛かる負荷のテストが完了したら，構築したシステムの動作確認は終了です。

6.21　系の最大数を変更する場合の動作確認（HAモニタ Extension使用時）

HAモニタ Extensionを使用して系の最大数を変更する場合，監視パスのパケットが漏れなく送受信できているかどうかを確認する必要があります。確認は，系切り替え構成内のすべての系で実施します。

確認手順を，次の図に示します。

図6-46　系の最大数を変更する場合の動作の確認手順

次に，図に示した手順の詳細について説明します。

系切り替え構成内のすべての系でHAモニタを起動する。
HAモニタが起動できたかどうかは，サーバ・系の状態表示コマンド（monshow -cコマンド）で確認します。
HAモニタの起動については，「7.2.1(1)　HAモニタの起動」を参照してください。

系切り替え構成内のすべての系でサーバを起動し，系切り替えができる状態にする。
系切り替えができる状態かどうかは，サーバ・系の状態表示コマンド（monshowコマンド），またはメッセージで確認します。
サーバの起動については，「7.2.1(3)　サーバの起動」を参照してください。

UDPの統計情報から，UDPパケットの受信エラーの変化を確認する。
netstat -s -uコマンドを実行し，UDPの統計情報の"packet receive errors"の数値を取得します。これを系障害監視時間（HAモニタの環境設定のpatrolオペランド）の間隔で数回実行し，値の変化を確認します。
確認の結果，UDPパケットの受信エラーの値に変化がない場合は，パケットが漏れなく受信できているため，動作確認は終了です。
確認の結果，UDPパケットの受信エラーの値が増加していく場合は，手順4.に進んでください。

aliveメッセージの送信間隔を調整する。
すべてのパケットが漏れなく送受信できるかどうかは，マシン性能や環境に依存し，かつHAモニタが必要とする性能は送受信するaliveメッセージの量に依存します。このため，HAモニタの環境設定のalive_intervalオペランドでaliveメッセージの送信間隔を調整し，送受信するaliveメッセージの量を調整します。
alive_intervalオペランドの指定値は，次のように調整してください。

alive_intervalオペランドの指定値に余裕がある場合

alive_intervalオペランドの指定値を大きくしてください。

alive_intervalオペランドの指定値が最大の場合

alive_intervalオペランドを，HAモニタの環境設定から削除してください。

再度，動作の確認を実施する。
手順1.～4.を繰り返してください。手順3.の確認でUDPパケットの受信エラーの値に変化がなくなれば，系の最大数を変更する場合の動作確認は終了です。

注意

alive_intervalオペランドには，系切り替え構成内のすべての系で同じ値を指定します。どれか一つの系でalive_intervalオペランドの指定値を変更した場合は，系切り替え構成内のすべての系で指定値を変更してください。

7.　システムの運用

この章では，構築したシステムの運用について説明します。

起動・停止方法，障害が発生した場合のオペレータの操作，障害発生を防ぐための運用，および運用を自動化する方法やシステムを変更する方法などについて説明します。

＜この章の構成＞

7.1　運用の流れ

7.2　起動・停止

7.3　障害発生による系切り替え時の運用

7.4　障害への対処

7.5　高負荷による障害発生を防止するための運用

7.6　運用の自動化

7.7　計画的な系切り替え

7.8　システムの変更

7.1　運用の流れ

HAモニタを使用した系切り替え構成での運用の流れを次の図に示します。

図7-1　系切り替え構成での運用の流れ

＜この節の構成＞

7.1.1　運用前の準備

7.1.1　運用前の準備

運用時にはHAモニタのコマンドを実行するため，システムを運用する前にPATH環境変数の設定をします。オペレータのPATH環境変数に/opt/hitachi/HAmon/binを追加してください。

HAモニタのコマンドは，スーパユーザだけが実行できるもの，スーパユーザおよび一般ユーザが実行できるものに分かれます。詳細については，「9.　コマンド」を参照してください。

7.2　起動・停止

ここでは，HAモニタを使用したシステムの起動，および停止について説明します。システムの起動を自動化することもできます。自動化の方法については，「7.6.1　システムの起動からサーバの起動までを自動化する」を参照してください。

＜この節の構成＞

7.2.1　起動する

7.2.2　停止する

7.2.3　共有リソースをメンテナンスするときの注意事項

7.2.1　起動する

ここでは，マシンの電源を入れてから，サーバの系切り替えができる状態になるまでの流れと，起動方法について説明します。

システムを起動するには，実行系と待機系の両方を起動します。システムの起動の流れを次の図に示します。

図7-2　システムの起動の流れ

各系で電源を入れてサーバの起動が完了すると，HAモニタは，他系のHAモニタと連絡を取り合い，系切り替えができる状態になったことを確認します。このときに，メッセージKAMN252-Iが出力されます。

図7-2のうち，HAモニタ，リソースサーバ，およびサーバを起動する方法について説明します。

＜この項の構成＞

(1)　HAモニタの起動

(2)　リソースサーバの起動

(3)　サーバの起動

(1)　HAモニタの起動

HAモニタを手動起動する場合，HAモニタの起動コマンド（monstartコマンド）を実行します。HAモニタ起動後には，HAモニタの起動が完了していることを示すメッセージKAMN002-Iが出力されていることを確認してください。

HAモニタを自動起動する場合，HAモニタは，カーネルの起動後にOSによって自動的に起動されます。

HAモニタをインストールした時点では，自動起動するように設定されています。HAモニタの起動方法を変更するには，HAモニタの環境設定コマンド（monsetupコマンド）を実行します。HAモニタの環境設定コマンド（monsetupコマンド）については，「9.　コマンド」の「monsetup（HAモニタの環境設定）」を参照してください。

(2)　リソースサーバの起動

リソースサーバは，リソースサーバを親サーバに指定したサーバのうちどれかが起動すると，自動起動します。親サーバは，サーバ対応の環境設定で指定します。

共有リソースの接続に失敗したなどの理由からリソースサーバを手動で起動する場合，HAモニタの起動が完了していることを示すメッセージKAMN002-Iが出力されていることを確認したあとに，リソースサーバ起動コマンド（monresbgnコマンド）を実行します。

(3)　サーバの起動

実行系と待機系の両方でサーバを起動します。サーバを手動で起動する前に，HAモニタの起動が完了していることを示すメッセージKAMN002-Iが出力されていることを確認してください。

サーバモードのサーバの場合，サーバを起動するには，プログラムが提供する起動コマンドを実行します。サーバを起動すると，サーバの初期設定時にサーバがHAモニタと連絡し合い，系切り替えの環境を作ります。待機系で起動したサーバは待機サーバとなり，実行系の障害に備えます。

モニタモードのサーバの場合，モニタモードのサーバ起動コマンド（monbeginコマンド）でサーバを起動します。待機系で起動したサーバは待機サーバとなり，実行系の障害に備えます。

サーバ起動後には，サーバの起動が完了していることを示すメッセージKAMN251-Iが出力されていることを確認してください。メッセージKAMN251-Iは，サーバ単位で出力されます。同じ系に複数のサーバが稼働している場合，サーバごとに出力されます。

(a)　サーバをグループ化している場合に異なる点

グループ化している場合は，グループ内のすべてのサーバを起動する点が異なります。オペレータがサーバを起動した順で，サーバが起動されます。サーバ起動後には，グループ内の全サーバに対して，メッセージKAMN251-Iが出力されたことを確認してください。

7.2.2　停止する

システムを停止する流れと操作方法について説明します。システムを停止する場合，サーバを停止したあとに，カーネルをシャットダウンします。HAモニタはカーネルのシャットダウン時に自動的に停止します。

ここでは，サーバ，リソースサーバ，およびHAモニタの停止方法について説明します。

＜この項の構成＞

(1)　サーバの停止

(2)　リソースサーバの停止

(3)　HAモニタの停止

(1)　サーバの停止

実行サーバおよび待機サーバの両方を停止するには，次の方法があります。

サーバモードの場合
実行系でプログラムが提供する停止コマンドを実行します。
対応する待機サーバが待機系で起動している場合は，HAモニタが待機サーバを停止します。

モニタモードの場合
実行系でモニタモードのサーバ停止コマンド（monendコマンド）を実行します。
対応する待機サーバが待機系で起動している場合は，HAモニタが待機サーバを停止します。

待機サーバだけを停止するには，待機サーバ停止コマンド（monsbystpコマンド）を実行します。

サーバの停止を確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を実行します。

なお，モニタモードの場合でサーバの停止コマンドを作成しないときは，次の手順でサーバを停止します。

プログラムが提供する停止コマンドで，サーバを停止する。

モニタモードのサーバ停止コマンド（monendコマンド）を実行する。

(2)　リソースサーバの停止

リソースサーバは，リソースサーバを使用しているサーバがすべて停止すると，HAモニタによって自動的に停止されます。

共有リソースの切り離し失敗などの理由からリソースサーバを手動で停止するには，次の手順で行います。必要に応じて実行してください。

リソースサーバを使用しているサーバがすべて停止したことを確認する。
実行中のリソースサーバは共有リソースと接続しているため，実行中のリソースサーバを使用しているサーバが，共有リソースを使用できなくなります。サーバがすべて停止したことを確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を実行して，リソースサーバを親サーバに指定したサーバが停止していることを確認してください。

リソースサーバを停止する。
リソースサーバの停止方法は，実行中（実行系で稼働している）のリソースサーバおよび待機中（待機系で稼働している）のリソースサーバを停止するか，待機中のリソースサーバだけを停止するかによって異なります。

実行中および待機中のリソースサーバを停止する場合
実行中のリソースサーバ停止コマンド（monresendコマンド）を実行します。

待機中のリソースサーバだけを停止する場合
待機中のリソースサーバ停止コマンド（monressbystpコマンド）を実行します。

(3)　HAモニタの停止

HAモニタを手動で停止する場合，HAモニタの停止コマンド（monstopコマンド）を実行します。HAモニタ停止後には，HAモニタが停止したことを示すメッセージKAMN050-Iが出力されていることを確認してください。なお，サーバが稼働中の場合，HAモニタを停止できません。サーバを停止させてからHAモニタを停止してください。サーバの停止を確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を使用してください。

HAモニタを自動停止する設定にしている場合，カーネルのシャットダウン時に自動的に停止されます。HAモニタの停止方法を変更するには，HAモニタの環境設定コマンド（monsetupコマンド）を実行します。HAモニタの環境設定コマンド（monsetupコマンド）については，「9.　コマンド」の「monsetup（HAモニタの環境設定）」を参照してください。

7.2.3　共有リソースをメンテナンスするときの注意事項

運用後に共有ディスクのメンテナンスをする場合などに，共有リソースを手動で接続・切り離しをするときの注意事項について説明します。具体的な操作方法については，OSのマニュアルを参照してください。

注意

共有リソースを操作するときは，ここで示す注意事項に必ず従ってください。これらの注意事項に従わない場合，共有リソースが破壊されたり，系切り替えができなかったりするおそれがあります。

＜この項の構成＞

(1)　共有リソースを操作する前に

(2)　ボリュームグループの運用

(3)　ファイルシステムの運用

(4)　OS移行後の共有ディスクの運用

(1)　共有リソースを操作する前に

共有リソースの接続や切り離しは，HAモニタが制御します。そのため，次のことに注意してください。

サーバの稼働中は，共有リソースに対してコマンドなどによる外部からの操作をしないでください。
ユーザの操作とHAモニタの制御が競合すると，HAモニタによる制御が正しくできません。

メンテナンスなどでユーザが共有リソースを操作する場合は，サーバを停止させてください。

HAモニタによる共有リソースの制御については，「4.3.5　共有リソースの状態一覧」を参照してください。

(2)　ボリュームグループの運用

共有ディスク上に作成したボリュームグループを両方の系から同時に参照＋更新接続をすると動作が保証されません。したがって，次のことに注意してください。

サーバ起動前は，両方の系とも必ず切り離し状態にしてください。
HAモニタは，サーバ起動時にボリュームグループに参照＋更新接続をします。サーバ起動時にボリュームグループが接続状態だった場合，ボリュームグループが両方の系から参照＋更新され，破壊されるおそれがあります。

サーバ停止後は，HAモニタが切り離し状態にします。ほかの業務でボリュームグループを使用する場合は，vgchangeコマンドを実行して接続してください。
このとき，両方の系から参照＋更新接続をしないよう注意してください。

コマンドの実行形式を次に示します。

参照＋更新接続
vgchange -a y ボリュームグループのパス名

切り離し
vgchange -a n ボリュームグループのパス名

(3)　ファイルシステムの運用

ここでは，ファイルシステムの運用に関して注意が必要なことについて説明します。

サーバ起動前は，両方の系ともファイルシステムをアンマウントの状態にしてください。

HAモニタがファイルシステムをマウントする前に，マウントポイント（マウント先ディレクトリ）にアクセス中のプロセスがあるとマウントに失敗する場合があります。
このような運用は避けてください。

オペレータがほかの業務でファイルシステムを使用する場合には，両方の系からマウントしないように注意してください。
共有ディスク上に作成したファイルシステムを両方の系から同時にマウント状態にするとファイルシステム自体が破壊されます。
HAモニタが，マウントおよびアンマウントをするタイミングについては，「4.3.3　ファイルシステムの管理」を参照してください。

(4)　OS移行後の共有ディスクの運用

Linuxの場合，共有ディスクの状態がHI-UX/WE2およびAIXの場合の状態と異なります。そのため，HI-UX/WE2やAIXからLinuxに移行したあとには，共有ディスクの運用を見直し，注意して共有ディスクを使用してください。

例えば，HI-UX/WE2およびAIXの場合は，実行サーバ停止後は，共有ディスクにアクセスできる状態になっていますが，Linuxの場合は，実行サーバ停止後は共有ディスクにアクセスできません。Linuxの場合，バックアップなどの目的で共有ディスクにアクセスするには，共有ディスクをまずアクセスできる状態にしてから，アクセスしてください。

7.3　障害発生による系切り替え時の運用

HAモニタが障害を検出したあとのオペレータの対処について説明します。

障害発生から業務回復までの流れを次に示します。運用中は，syslogに出力されるメッセージから，システムが正常に動作しているかを確認できます。エラーメッセージが出力された場合，次の流れに従って，対処してください。

エラーメッセージの内容を確認する。
syslogに出力されたエラーメッセージの内容を確認します。

系の状態およびサーバの状態を確認する。
HAモニタによって，系切り替えが完了したかどうかを確認します。サーバ・系の状態表示コマンド（monshowコマンド）を実行して，次の点を確認します。

実行系で実行サーバが再起動しているかを確認する。
サーバ対応の環境設定のswitchtypeオペランドに"restart"または"manual"を指定した場合に，確認してください。

待機系の待機サーバが，実行サーバに切り替わったかを確認する。

実行サーバが起動していなくて，待ち状態になっている場合は，業務が停止している状態です。業務を再開するには，オペレータの対処が必要です。オペレータの対処については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

業務が問題なく継続できていることを確認する。
業務自体に問題がないことを確認します。確認する内容や方法は，業務内容によって異なります。例えば，次の点を確認します。

サーバ，クライアント間の通信ができているか。

業務を実行するプログラムが正しく動作しているか。

障害が発生した系で，障害を取り除く。
出力されたメッセージと対処を参考にして，障害を取り除きます。共有リソースを操作する必要がある場合は，「7.2.3　共有リソースをメンテナンスするときの注意事項」に記載されている注意事項に従って操作してください。また必要に応じて，HAモニタの障害情報を収集してください。詳細については，「7.3.2　障害情報を収集する」を参照してください。
主な障害については，対処方法を説明しています。障害への対処方法については，「7.4　障害への対処」を参照してください。

障害が発生した系を再起動する。
現用系で障害が発生した場合は，予備系で業務を実行しているため，障害が発生した系を待機系として再起動しておくと，現在業務を実行している予備系の障害に備えることができます。詳細については，「7.3.3　障害が発生した系を再起動する」を参照してください。

サーバや系の状態を確認する。
障害が発生したサーバまたは系が問題なく再起動できたかを，HAモニタのコマンドを使用して確認します。詳細については，「7.3.4　障害対処後にサーバや系の状態を確認する」を参照してください。

＜この節の構成＞

7.3.1　待ち状態のサーバを起動して業務を再開する

7.3.2　障害情報を収集する

7.3.3　障害が発生した系を再起動する

7.3.4　障害対処後にサーバや系の状態を確認する

7.3.1　待ち状態のサーバを起動して業務を再開する

HAモニタは，他系のHAモニタと連絡を取り合っています。実行系と待機系とで，サーバの状態を監視し，他系のサーバの状態に合わせて，自系のサーバの状態を決定します。そのため，起動したサーバが，起動完了しないで待ち状態になることがあります。ここでは，待ち状態になったサーバを，起動したり停止したりする方法について説明します。

サーバの待ち状態には複数の種類があり，それぞれ起動方法および停止方法が異なります。サーバが待ち状態になった場合，待ち状態であることを通知するメッセージが一定間隔で出力されます。サーバの待ち状態の種類と操作方法を次の表に示します。

表7-1　サーバの待ち状態の種類と操作方法

種類
monshowコマンドでの表示
説明
メッセージ
起動・停止方法

再起動待ち状態
*ONL*
実行サーバに障害が発生したあと，実行サーバを再起動させることができます。障害が発生してから再起動が完了するまでの間を，再起動待ち状態と呼びます。
KAMN258-D
起動：プログラムが提供する起動コマンド
停止：mondeact

系切り替え待ち状態
ONL??
系切り替えが発生すると，HAモニタは，待機系の待機サーバを実行サーバに切り替えます。実行サーバに切り替える際，HAモニタは，実行系（障害が発生した系）の実行サーバが停止したかどうかを確認します。
停止を確認できた場合，待機系の待機サーバは実際に実行サーバとして起動されます。
停止を確認できなかった場合，待機系の待機サーバは実行サーバとして実際に起動する前に，いったん待ち状態になります。この待機系の実行サーバが，実行サーバとして実際に起動するのを待っている状態を，系切り替え待ち状態と呼びます。
KAMN368-D
起動：monact
停止：mondeact

実行サーバの起動待ち状態
*SBY*
監視パスの障害などの理由で，実行サーバの状態が確認できない場合，待機サーバは，実行サーバが起動するのを待ちます。実行サーバの起動を待っている状態を，実行サーバの起動待ち状態と呼びます。
KAMN238-D
起動：monact
停止：mondeact

リソースサーバの起動待ち状態
リソースサーバが起動を完了していない場合，子サーバはリソースサーバの起動を待ちます。リソースサーバの起動を待っている状態を，リソースサーバの起動待ち状態と呼びます。
なし
起動：リソースサーバの起動後に，monact
停止：リソースサーバの停止後，または起動後に，mondeact

連動系切り替え待ち状態
SBY??
複数のサーバをグループ化している場合，あるサーバに，障害が発生しても連動系切り替えをしない設定ができます。連動系切り替えをしない設定にしているサーバに障害が発生した場合，対応する待機サーバは連動系切り替え待ち状態になります。
なお，そのホスト以外で実行サーバまたは待機サーバが起動した場合は，系切り替え可能状態に戻ります。
なし
起動：monact
停止：monsbystp

表中の「起動・停止方法」に記載されているのは，HAモニタのコマンド名です。また，表中の「monshowコマンドでの表示」は，サーバ・系の状態表示コマンド（monshowコマンド）を実行したときに表示されるサーバの状態を示しています。HAモニタのコマンドの詳細については，「9.　コマンド」を参照してください。サーバの状態遷移については，「4.1.3　サーバの状態遷移」を参照してください。

7.3.2　障害情報を収集する

障害が発生した場合に，収集する障害情報と収集方法について説明します。

HAモニタの障害情報
トラブルシュート情報収集コマンド（montsコマンド）で，収集します。

OSの障害情報，および統計情報
OSのコマンドで収集します。

ここでは，HAモニタの障害情報，およびトラブルシュート情報収集コマンド（montsコマンド）について説明します。OSの障害情報，および統計情報については，OSのマニュアルを参照してください。

＜この項の構成＞

(1)　HAモニタの障害情報

(2)　HAモニタのmontsコマンドを使用した障害情報の収集

(1)　HAモニタの障害情報

HAモニタには，次の障害情報があります。これらの情報はすべて，トラブルシュート情報収集コマンド（montsコマンド）で収集できます。

定義情報
定義ファイル（/opt/hitachi/HAmon/etc下のすべてのファイル）

モジュールトレース情報
コアファイル（/opt/hitachi/HAmon/coreで始まるすべてのファイル）

メッセージログ情報
システムログファイル（/var/log/messagesで始まるすべてのファイル）

メモリ情報
HAモニタが稼働している場合，そのメモリ情報を取得します。

トレース情報
トレースファイル（/opt/hitachi/HAmon/spool下のすべてのファイル）
HAモニタの動作履歴や発行したコマンドの実行結果を保存したファイルです。
障害調査には，次のトレースファイルを使用できます。なお，/opt/hitachi/HAmon/spool下には，HAモニタの稼働に必要なファイルが格納されているため，ファイルの変更・削除，およびディレクトリへの操作は行わないでください。

表7-2　HAモニタの障害調査に使用するファイル

ファイル名
説明
調査目的

sms

oldsms

系およびサーバの障害情報やスローダウン情報を収集するファイルです。
ファイル内のトレース情報が100KBに達すると，「oldsms」という名称のバックアップファイルにラップアラウンドされます。このとき，smsファイルの内容はクリアされ，oldsmsファイルに書き換えられます。
系障害，サーバ障害の調査

サーバ識別名.fslog

サーバ識別名.fslog_old

HAモニタがファイルシステムの切り替え時に実行するOSのコマンド（fsck，mount，fuser，umountコマンド）の実行結果を収集するファイルです。
トレース取得時にファイルがHAモニタの環境設定のfs_log_sizeオペランドに指定したサイズを超えた場合，「サーバ識別名.fslog_old」という名称のバックアップファイルが作成されます。
ファイルシステムの切り替えエラー要因調査

ボリュームグループ名.vglog

ボリュームグループ名.vglog_old

HAモニタがボリュームグループの接続時または切り離し時に実行するOSのコマンド（vgchangeコマンド）の実行結果を収集するファイルです。
トレース取得時にファイルが65,535バイトを超えた場合，「ボリュームグループ名.vglog_old」という名称のバックアップファイルが作成されます。
共有ディスクの接続エラー要因調査

監視履歴
監視履歴ファイル（/opt/hitachi/HAmon/history/patrol_history）
系およびサーバのスローダウン情報を収集するファイルです。トレース情報のsmsファイルよりも詳細に，スローダウンしていた期間を取得できます。
監視履歴は，高負荷による障害発生を防止するために定義ファイルやシステム構成を見直す場合に有効な情報です。監視履歴を使用して障害発生を軽減する運用方法については，「7.5　高負荷による障害発生を防止するための運用」を参照してください。

(2)　HAモニタのmontsコマンドを使用した障害情報の収集

障害発生時にトラブルシュート情報収集コマンド（montsコマンド）を実行することで，取得した障害情報を，アーカイブファイルとして保存したり，可搬媒体に移送したりできます。

トラブルシュート情報収集コマンド（montsコマンド）は，スーパユーザの権限で実行してください。トラブルシュート情報収集コマンド（montsコマンド）を使用した障害情報の収集を次の図に示します。

図7-3　トラブルシュート情報収集コマンド（montsコマンド）を使用した障害情報の収集

アーカイブファイルを保存するか，可搬媒体に移送するかは，トラブルシュート情報収集コマンド（montsコマンド）実行時に指定します。

7.3.3　障害が発生した系を再起動する

系切り替え後には，障害が発生した系はリセットされ，停止した状態になっています。オペレータは，障害が発生した原因を取り除き，現在業務を実行している予備系の障害に備えて，障害が発生した系を起動します。マシンが起動したあとは，通常の運用どおりに，HAモニタ，サーバの順で起動します。

障害が発生した系の障害原因を取り除く。
出力されたメッセージと対処を参考にして，障害を取り除きます。

系を再起動する。
業務を実行している予備系の障害に備えて，障害が発生した系を起動します。再起動した系は待機系となり，現在業務を実行している系の障害に備えます。

HAモニタを起動する。
HAモニタを手動で起動するように設定している場合，HAモニタの起動コマンド（monstartコマンド）を実行します。
HAモニタがカーネルの起動と同時に自動起動する設定にしている場合は，この操作は不要です。

HAモニタの起動が完了したことを確認する。
HAモニタの起動が完了すると，メッセージKAMN002-Iが出力されます。

サーバを起動する。
障害が発生した系のサーバを起動します。

サーバモードのサーバの場合

プログラムが提供する起動コマンドを実行します。

モニタモードのサーバの場合

モニタモードのサーバ起動コマンド（monbeginコマンド）を実行します。

モニタモードのサーバの場合，サーバの起動を自動的にすることもできます。設定方法の詳細については，「7.6.3　系切り替え後の運用を自動化する」を参照してください。

系が正しく起動されたことを確認する。
確認方法の詳細については，「7.3.4　障害対処後にサーバや系の状態を確認する」を参照してください。

サーバの起動が完了し，系切り替えができる状態になったことを確認する。
系切り替えができる状態になると，メッセージKAMN252-Iが出力されます。

7.3.4　障害対処後にサーバや系の状態を確認する

ここでは，障害対処後にサーバや共有リソースの状態を確認する方法について説明します。ここで説明するコマンドの詳細については，「9.　コマンド」を参照してください。

＜この項の構成＞

(1)　システムの状態確認

(2)　サーバの状態確認

(3)　リソースサーバの状態確認

(1)　システムの状態確認

システムの状態確認では，監視パス，リセットパス，および系の状態を調査し，実行系と待機系とが連絡を取り合えることを確認します。

監視パスの状態確認
監視パス状態表示コマンド（monpathコマンド）を使用して，監視パスの状態を確認したり，監視パスのIPアドレスを基に，障害が発生した個所を調査したりできます。監視パスの障害発生時，または障害回復時に使用します。

リセットパスの状態確認
実行するコマンドは，使用しているマシンの機種によって次のとおり異なります。これらのコマンドは，障害管理プロセサやリセットパスの障害発生時，または障害回復時に使用します。

BladeSymphonyまたはHA8000の場合，リセットパス状態表示コマンド（monrpコマンド）を実行します。

HA8500の場合，MP状態表示コマンド（monmpコマンド）を実行します。

系の状態確認
サーバ・系の状態表示コマンド（monshow -cコマンド）を使用して，自ホスト（コマンドを実行した系）の状態，および自ホストが接続している他ホストの状態を確認できます。

(2)　サーバの状態確認

サーバ・系の状態表示コマンド（monshowコマンド）を使用して，コマンドを実行した系で稼働しているサーバの状態，およびそのサーバと対になっているサーバの状態を確認できます。

(3)　リソースサーバの状態確認

サーバ・系の状態表示コマンド（monshow -rコマンド）を使用して，リソースサーバの状態を確認します。同時にリソースサーバを使用するサーバの状態も確認できます。

7.4　障害への対処

障害が発生したあと，オペレータがメッセージを基に障害に対処する方法について説明します。ここでは，代表的な例を挙げて説明します。ここで説明していない障害が発生した場合は，出力されるメッセージ，およびメッセージの対処を基に，対処をしてください。メッセージの対処については，マニュアル「高信頼化システム監視機能 HAモニタ メッセージ」を参照してください。

＜この節の構成＞

7.4.1　系の起動失敗に対処する

7.4.2　サーバの再起動失敗に対処する

7.4.3　系のリセット失敗に対処する

7.4.4　共有リソースの接続失敗に対処する

7.4.5　共有リソースの切り離し失敗に対処する

7.4.6　UAP障害に対処する

7.4.1　系の起動失敗に対処する

系の起動に失敗した場合の対処について説明します。

＜この項の構成＞

(1)　現用系の起動に失敗した場合

(2)　予備系の起動に失敗した場合

(1)　現用系の起動に失敗した場合

現用系の起動に失敗した場合，オペレータは予備系を実行系として起動します。予備系では，サーバが待機サーバとして起動され，実行サーバの起動待ち状態になります。オペレータは，待ち状態のサーバ起動コマンド（monactコマンド）を実行して，予備系の待機サーバを実行サーバとして起動します。予備系で実行サーバが起動するため，予備系が実行系になります。

実行系が起動して業務が開始したあとに，オペレータは現用系の起動失敗の要因を調査して，現用系を待機系として起動します。

(2)　予備系の起動に失敗した場合

予備系の起動に失敗した場合，実行系での業務には影響がありません。ただし，待機系がないため，実行系に障害が発生した場合には系切り替えができません。予備系の障害を取り除いて，待機系として起動することを推奨します。

7.4.2　サーバの再起動失敗に対処する

サーバ障害発生時にサーバを自動的に再起動する設定にしている場合で，サーバが自動的に起動しなかったときの対処について説明します。サーバの運用方法によって，対処をするタイミングが異なります。

サーバモードのサーバの場合

サーバの再起動をリトライ分繰り返したあとに再起動限界を検出したとき

モニタモードのサーバの場合

サーバの再起動に失敗したとき

プログラムの再起動に失敗したとき

＜この項の構成＞

(1)　サーバモードのサーバの場合

(2)　モニタモードのサーバの場合

(1)　サーバモードのサーバの場合

ここでは，次の両方に当てはまる場合の対処方法について説明します。サーバ対応の環境設定のswitchtypeオペランドに"switch"または"restart"を指定している場合はHAモニタが系切り替えをするため，オペレータの操作は不要です。

サーバ対応の環境設定のswitchtypeオペランドに"manual"を指定している。

メッセージKAMN316-Eが出力された。

上記に当てはまる場合，実行系（障害が発生した系）の実行サーバは停止し，待機系の待機サーバは実行サーバの起動待ち状態になっています。

対処

待機サーバが実行サーバの起動待ち状態になっているため，業務を再開するために，起動待ち状態の待機サーバを実行サーバとして起動します。

実行系の状態を確認する。
次のことを確認します。

実行サーバが停止していること

サーバが使用する共有リソースが切り離されていること

待機系の待機サーバを，実行サーバとして起動する。
待ち状態のサーバ起動コマンド（monactコマンド）を実行して，実行サーバの起動待ち状態になっている待機サーバを，実行サーバとして起動します。

実行サーバが起動したことを確認する。
メッセージKAMN251-Iが出力されることを確認します。

実行系（障害が発生した系）で，サーバの障害を取り除く。

実行系で，待機サーバを起動する。
プログラムが提供する起動コマンドを実行します。

対処後の確認方法

系切り替えができる状態になったことを確認する。
次のどちらかの方法で確認します。

メッセージKAMN252-Iが出力された。

サーバ・系の状態表示コマンド（monshowコマンド）を実行し，実行サーバの状態が"ONL"，待機サーバの状態が"SBY"と表示された。

(2)　モニタモードのサーバの場合

モニタモードのサーバの場合に再起動に失敗したときの対処方法を，それぞれ説明します。

(a)　サーバの再起動に失敗したとき

サーバをモニタモードで運用する場合，サーバの再起動失敗には，次の原因が考えられます。

HAモニタがサーバの起動コマンドの実行に失敗した。

HAモニタがサーバの停止コマンドの実行に失敗した。

ここでは，次に当てはまる場合の，対処方法について説明します。異なるメッセージが出力されている場合は，異なる原因が考えられます。出力されているメッセージを基に対処してください。

サーバ障害時にサーバを再起動する設定にしている。

メッセージKAMN273-Eが出力されている。

なお，サーバの再起動時に，サーバ対応の環境設定のnameオペランド，またはactcommandオペランドに指定したサーバの起動コマンドの戻り値が0以外だった場合，サーバ対応の環境設定のtermcommandオペランドに指定したサーバの停止コマンドは実行しないで処理を中断します。

対処

サーバの起動・停止コマンド，またはサーバ対応の環境設定を修正して，サーバを再起動させます。

障害の原因を取り除く。
メッセージKAMN273-Eに表示されるエラーコードに基づいて，原因を取り除きます。エラーコードの詳細については，「表7-3　メッセージKAMN273-Eに表示されるエラーコード一覧」を参照してください。

待機系で，実行サーバを起動する。
次のどちらかの方法があります。

実行系（障害が発生した系）でモニタモードのサーバ停止コマンド（monendコマンド）を実行していったん実行サーバを停止したあとに，待機系でモニタモードのサーバ起動コマンド（monbeginコマンド）を実行して，実行サーバを起動します。

待機系でモニタモードのサーバ起動コマンド（monbeginコマンド）を実行して待機サーバを起動したあと，実行系で計画系切り替えコマンド（monswapコマンド）を実行して待機系に計画系切り替えをします。

実行系で，待機サーバを起動する。
モニタモードのサーバ起動コマンド（monbeginコマンド）を実行して待機サーバを起動します。

対処後の確認方法

系切り替えができる状態になったことを確認する。
次のどちらかの方法で確認します。

メッセージKAMN252-Iが出力された。

サーバ・系の状態表示コマンド（monshowコマンド）を実行し，実行サーバの状態が"ONL"，待機サーバの状態が"SBY"と表示された。

メッセージKAMN273-Eに表示されるエラーコードの一覧と対処を次の表に示します。

表7-3　メッセージKAMN273-Eに表示されるエラーコード一覧

原因コード | 詳細コード | コードの説明 | 対処
1 | システムコールのerrno | サーバの起動コマンド実行時にシステムエラーが発生しました。 | システムコールのエラー要因を取り除いてください。
2 | コマンド戻り値 | サーバの起動コマンドが戻り値として0以外を返しました。 | サーバの起動コマンドの内容を確認し，修正してください。
126 | nameオペランド，またはactcommandオペランドに指定したファイルに実行権限がありません。 | サーバの起動コマンドに実行権限を与えてください。
127 | nameオペランド，またはactcommandオペランドに指定したファイルがありません。 | サーバ対応の環境設定のnameオペランド，またはactcommandオペランドに指定した値とサーバの起動コマンドの格納場所が一致しているかを確認してください。
3 | システムコールのerrno | サーバの停止コマンド実行時にシステムエラーが発生しました。 | システムコールのエラー要因を取り除いてください。
4 | コマンド戻り値 | サーバの停止コマンドが戻り値として0以外を返しました。 | サーバの停止コマンドの内容を確認し，修正してください。
126 | termcommandオペランドに指定したファイルに実行権限がありません。 | サーバ対応の環境設定のtermcommandオペランドに指定したサーバの停止コマンドに，実行権限を与えてください。
127 | termcommandオペランドに指定したファイルがありません。 | サーバ対応の環境設定のtermcommandオペランドに指定した値とサーバの停止コマンドの格納場所が一致しているかを確認してください。

(b)　プログラムの再起動に失敗したとき

モニタモードのプログラム管理機能使用時に，プログラムの再起動コマンドを作成すれば，プログラム単体で再起動できます。

プログラムの再起動失敗には，次の原因が考えられます。

HAモニタがプログラムの再起動コマンドの実行に失敗した。

プログラムの再起動コマンドがタイムアウト時間内に完了しなかった。

UAPがタイムアウト時間内にhamon_patrolstart関数を発行しなかった。

ここでは，次に当てはまる場合の，対処方法について説明します。異なるメッセージが出力されている場合は，異なる原因が考えられます。出力されているメッセージを基に対処してください。

プログラム障害時にプログラムを再起動する設定にしている。

メッセージKAMN285-Eが出力されている。

対処

モニタモードのプログラム対応の環境設定を修正してサーバを再起動させます。またはプログラムの再起動コマンドを修正して，プログラムを再起動させます。

障害の原因を取り除く。
メッセージKAMN285-Eに表示されるエラーコードに基づいて，原因を取り除きます。エラーコードの詳細については，「表7-4　メッセージKAMN285-Eに表示されるエラーコード一覧」を参照してください。

実行系で，プログラムを再起動する。
次のどちらかの方法で再起動します。

サーバを再起動させます。モニタモードのサーバ停止コマンド（monendコマンド）を実行していったん実行サーバを停止したあとに，モニタモードのサーバ起動コマンド（monbeginコマンド）を実行して，実行サーバを起動します。

障害が発生したUAPを手動で再起動します。

対処後の確認方法

プログラムが起動完了したことを確認する。
次のどちらかの方法で確認します。

メッセージKAMN284-Iが出力された。

サーバと系の状態表示コマンド（monshow -uコマンド）を実行し，プログラムの状態が"ACT"と表示された。

メッセージKAMN285-Eに表示されるエラーコードの一覧と対処を次の表に示します。

表7-4　メッセージKAMN285-Eに表示されるエラーコード一覧

原因コード | 詳細コード | コードの説明 | 対処
1 | 1 | タイムアウト時間内に，プログラムの再起動コマンドが完了しませんでした。 | プログラムの再起動コマンドが完了しなかった原因を取り除いてください。
2 | タイムアウト時間内にUAPがhamon_patrolstart関数を発行しませんでした。 | UAPがhamon_patrolstart関数を発行しなかった原因を取り除いてください。
3 | タイムアウト時間内にプログラムの再起動コマンドが未完了で，かつUAPがhamon_patrolstart関数を発行しませんでした。 | プログラムの再起動コマンドが完了しなかった原因，およびUAPがhamon_patrolstart関数を発行しなかった原因を取り除いてください。
2 | コマンド戻り値 | プログラムの再起動コマンドが戻り値として0以外を返しました。 | プログラムの再起動コマンドの内容を確認し，修正してください。
126 | restartcommandオペランドに指定したファイルに実行権限がありません。 | モニタモードのプログラム対応の環境設定のrestartcommandオペランドに指定したプログラムの再起動コマンドに，実行権限を与えてください。
127 | restartcommandオペランドに指定したファイルがありません。 | モニタモードのプログラム対応の環境設定のrestartcommandオペランドに指定した値とプログラムの再起動コマンドの格納場所が一致しているかを確認してください。
256 | プログラムの再起動コマンド実行時のシステムエラーが発生しました。 | システムコールエラーの要因を取り除いてください。

7.4.3　系のリセット失敗に対処する

系のリセットに失敗した場合，待機系のサーバが系切り替え待ち状態になり，業務が停止したままになります。ここでは，次の両方に当てはまる場合の，対処方法を説明します。

系障害が発生し，かつ，何らかの原因で系のリセットに失敗した。

メッセージKAMN368-Dが出力された。

対処

系切り替え待ち状態になっているサーバを，実行サーバとして起動します。

どのサーバが，系切り替え待ち状態になっているかを確認する。
待機系で，サーバ・系の状態表示コマンド（monshowコマンド）を実行し，サーバの状態が"ONL??"と表示されているサーバのサーバ識別名を調べます。

障害が発生した系で，サーバが稼働していないことを確認する。
障害が発生した系で，サーバ・系の状態表示コマンド（monshowコマンド）を実行し，システム内のほかの系すべてで，実行サーバが稼働していないことを確認してください。

待ち状態のサーバを，実行サーバとして起動する。
待機系で，待ち状態のサーバ起動コマンド（monactコマンド）を実行します。オプションには，系切り替え待ち状態になっているサーバのサーバ識別名を指定します。

対処後の確認方法

実行サーバの起動が完了したことを確認する。
サーバ・系の状態表示コマンド（monshowコマンド）を実行し，該当するサーバの状態が"ONL"と表示されていることを確認します。

サーバの業務が正常に行われていることを確認する。

7.4.4　共有リソースの接続失敗に対処する

共有リソースの接続に失敗した場合の対処について説明します。共有リソースの接続は，通常HAモニタが行います。障害が発生した場合は，オペレータが手動で共有リソースを接続する必要があります。ここでは，手動で共有リソースを接続する方法について説明します。

共有リソースを操作するときの注意については，「7.2.3　共有リソースをメンテナンスするときの注意事項」を参照してください。これらの注意に従わないと，共有リソースが破壊されたり，系切り替えができなかったりするおそれがあります。

共有ディスク
次のコマンドを実行します。その際，両方の系から参照＋更新接続をしないように注意してください。
vgchange -a y ボリュームグループのパス名

ファイルシステム
次の手順で操作します。

OSのfsckコマンドで，ファイルシステムをチェックします。

OSのmountコマンドで，マウントをします。

LAN
LANを手動で接続するには，LANの状態設定ファイルを修正し，実行します。
修正するファイルは，/opt/hitachi/HAmon/etc/サーバ識別名.upです。

HA Boosterの制御グループ
HA Boosterが提供する，制御グループのアクセス制御状態を変更するためのコマンドを実行し，アクセス制御状態を参照＋更新可能に設定します。その際，両方の系から参照＋更新接続をしないように注意してください。

7.4.5　共有リソースの切り離し失敗に対処する

共有リソースの切り離しに失敗した場合の対処について説明します。共有リソースの切り離しは，通常HAモニタが行います。障害が発生した場合は，オペレータが手動で共有リソースの切り離しをする必要があります。どのタイミングで共有リソースの切り離しが失敗したかによって，対処が異なります。

注意

共有リソースの制御処理中にサーバの異常終了，サーバの強制停止，または共有リソース引き継ぎのタイムアウトを検出した場合，共有リソースの状態が不定になります。このため，共有リソースの状態を必ず確認したあとにサーバを再起動してください。このほかの共有リソースを操作するときの注意については，「7.2.3　共有リソースをメンテナンスするときの注意事項」を参照してください。これらの注意に従わないと，共有リソースが破壊されたり，系切り替えができなかったりするおそれがあります。

＜この項の構成＞

(1)　系切り替え時

(2)　サーバの停止時

(1)　系切り替え時

系切り替え時に，実行系で共有リソースの切り離しに失敗すると，HAモニタが系のリセットをして，待機系に系切り替えをします。オペレータの対処は必要ありません。

系切り替え時に，実行系で共有リソースの切り離しに失敗すると，両系で共有リソースが競合し，共有リソースが破壊されたり，システムが停止したりするおそれがあります。両系での共有リソースの競合を防止するため，HAモニタは系のリセットをします。

(2)　サーバの停止時

サーバの停止時に共有リソースの切り離しに失敗した場合，共有リソースの切り離しが失敗した旨のメッセージが出力されます。オペレータは，出力されたメッセージの内容を確認し，各共有リソースに対応した切り離し操作をしてください。

共有ディスク
次のコマンドを実行します。
vgchange -a n ボリュームグループのパス名

ファイルシステム
次の手順で操作します。

OSのfuserコマンドで，ファイルシステムを使用しているすべてのプロセスを強制停止します。

OSのumountコマンドで，アンマウントをします。

LAN
手動でLANの切り離しをするには，LANの状態設定ファイルを修正し，実行します。
修正するファイルは，/opt/hitachi/HAmon/etc/サーバ識別名.downです。
OSのifconfigコマンドを使って切り離しをすることもできます。

HA Boosterの制御グループ
HA Boosterが提供する，制御グループのアクセス制御状態を変更するためのコマンドを実行し，アクセス制御状態をアクセス禁止に設定します。

7.4.6　UAP障害に対処する

モニタモードのプログラム管理機能で監視するUAPで，UAPのプロセスダウンやスローダウンが発生した場合，UAPのcoreファイルのスタックトレースなどの情報から，障害の原因を調査してください。

なお，スタックトレースに次に示す関数名がある場合，HAモニタが提供するAPIの内部で障害が発生しています。この場合，システム管理者に連絡してください。

hamon_patrolstart

hamon_patrolstop

7.5　高負荷による障害発生を防止するための運用

高負荷によるサーバや系のスローダウンを防止するために，ユーザは次の情報を基に，定義ファイルの設定やシステム構成が適切かどうかを調査します。

OSの情報

HAモニタとのインタフェースを持つプログラムの情報

監視履歴で取得したスローダウンの情報

監視履歴とは，サーバや系に発生したスローダウンの履歴のことです。

監視履歴を取得する対象となるのは，自系で稼働しているサーバモードのサーバ，および自系・他系です。これらの監視履歴は，監視履歴ファイルに出力されます。監視履歴ファイルには，サーバ障害監視時間や系障害監視時間を超えたスローダウンだけでなく，サーバ障害監視時間や系障害監視時間に達しないスローダウン，つまりHAモニタが障害として検出しないスローダウンも記録されます。障害として検出されなかったスローダウンの履歴を解析することで，次のことができます。

定義ファイルに設定したサーバ障害監視時間，および系障害監視時間の見直し

システムの負荷状況の把握による，システム構成の見直し

また，事前にシェルを作成しておくことで，サーバのスローダウンが発生した場合に原因を調査することもできます。

ここでは，監視履歴を取得，解析する方法，およびサーバのスローダウンの原因を調査する方法について説明します。

注意

次の場合は，サーバの監視履歴を取得できません。

待機サーバの場合

また，次の場合は，サーバの監視履歴の取得，およびサーバのスローダウンの検出ができません。

サーバモードのサーバとしてTP1/EEまたはHiRDB（XDS）を使用する場合

サーバをモニタモードで使用する場合

＜この節の構成＞

7.5.1　サーバの監視履歴を取得する

7.5.2　系の監視履歴を取得する

7.5.3　取得した監視履歴を解析する

7.5.4　サーバのスローダウンの原因を調査する

7.5.1　サーバの監視履歴を取得する

ここでは，サーバの監視履歴で取得できる内容，およびサーバの監視履歴を取得する方法について説明します。

サーバの監視履歴を取得する場合，障害が発生したかどうかに関係なく，サーバのスローダウンが発生していたことを監視履歴ファイルに記録します。つまり，サーバの稼働報告がない期間がサーバ障害監視時間を超えない場合でも，ユーザが設定したしきい値（サーバ監視履歴取得時間）以上であれば，サーバのスローダウンを記録します。

ユーザはあらかじめ，定義ファイルに次のオペランドを設定しておきます。

HAモニタの環境設定のph_log_sizeオペランド
監視履歴ファイルのサイズを指定します。監視履歴ファイルのサイズを見積もる方法や指定方法については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

サーバ対応の環境設定のph_thresholdオペランド
サーバ監視履歴取得時間を指定します。

7.5.2　系の監視履歴を取得する

ここでは，系の監視履歴で取得する内容，および監視履歴を取得する方法について説明します。

系の監視履歴を取得する場合，障害が発生したかどうかに関係なく，系のスローダウンが発生していたことを監視履歴ファイルに記録します。つまり，自系がスローダウンした期間，または他系からのaliveメッセージが途絶した期間が系障害監視時間を超えない場合でも，ユーザが設定したしきい値（系監視履歴取得時間）以上であれば，系のスローダウンを監視履歴ファイルに記録します。

ユーザはあらかじめ，HAモニタの環境設定に次のオペランドを設定しておきます。

HAモニタの環境設定のph_log_sizeオペランド
監視履歴ファイルのサイズを指定します。監視履歴ファイルのサイズを見積もる方法や指定方法については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

HAモニタの環境設定のph_thresholdオペランド
系監視履歴取得時間を指定します。自系と他系で異なる値は設定できません。

7.5.3　取得した監視履歴を解析する

取得した監視履歴は，次に示す監視履歴ファイルに出力されます。

/opt/hitachi/HAmon/history/patrol_history

監視履歴ファイルは，HAモニタの環境設定のph_log_sizeオペランドで指定したサイズを超えると，次の名称のバックアップファイルに書き換えられます。

/opt/hitachi/HAmon/history/patrol_history_old

監視履歴を解析するときは，監視履歴ファイル，およびバックアップファイルを使用してください。なお，解析に当たって監視履歴ファイルおよびバックアップファイルは常時参照できますが，ファイルやファイルが格納されているディレクトリを直接編集しないでください。

＜この項の構成＞

(1)　監視履歴ファイルの出力形式

(2)　バックアップファイルの退避

(1)　監視履歴ファイルの出力形式

監視履歴は，一つの履歴につき1行ずつ監視履歴ファイルに蓄積されます。監視履歴ファイルの出力形式を，次に示します。

西暦/月/日 時刻;ID;種別;サーバの識別名またはホスト名;秒数;メッセージ

西暦/月/日 時刻
監視履歴を取得した日時です。

ID
監視履歴として出力されるメッセージごとに一意に割り当てられたIDです。

種別
監視履歴を取得した対象の種別を表す記号です。記号と種別の対応を次に示します。

S：自系で稼働する実行サーバ

H：他系

O：自系

サーバの識別名またはホスト名
監視履歴を取得した対象のサーバの識別名，またはホスト名です。

秒数
スローダウンが発生していた秒数です。監視履歴として出力されるメッセージの内容によっては，出力されません。

メッセージ
監視履歴として出力されるメッセージ本文です。出力されるメッセージ本文の詳細については，「付録B　監視履歴として出力されるメッセージ」を参照してください。

HAモニタは監視履歴ファイルの作成時，ファイルを空白で埋めることでサイズを固定します。このため監視履歴が追加されたあとファイル内に空白行が残っている場合もありますが，解析のときは空白行を無視してかまいません。

(2)　バックアップファイルの退避

監視履歴ファイルのサイズが指定値を超えたとき，メッセージKAMN740-Iが出力されます。ユーザは，メッセージが出力されたタイミングでバックアップファイルを退避してください。退避したバックアップファイルは，監視履歴を解析するときに使用できます。

7.5.4　サーバのスローダウンの原因を調査する

HAモニタでは，サーバモードのサーバのスローダウン，およびモニタモードのサーバのUAPのスローダウンが発生した場合，シェルを実行させて原因を調査するための情報を取得できます。

ここでは，作成するシェルの名称と実行時の形式について説明します。なお，ここで説明するシェルは，HAモニタの処理とは非同期に実行されます。

＜この項の構成＞

(1)　サーバのスローダウン時に実行するシェル

(2)　UAPのスローダウン時に実行するシェル

(3)　注意事項

(1)　サーバのスローダウン時に実行するシェル

サーバのスローダウンの原因を調査するための情報を取得するシェルについて説明します。作成するシェルの名称と実行時の形式を，次に示します。

作成するシェルの名称

/opt/hitachi/HAmon/etc/servdown.sh

このシェル内に，実行したい処理を記述します。シェルには，実行権限を設定してください。

シェルの実行時の形式

servdown.sh△サーバ識別名

（凡例）

△：半角スペースを示します。

サーバ識別名：スローダウンを検出した，実行サーバの識別名を示します。

(2)　UAPのスローダウン時に実行するシェル

UAPのスローダウンの原因を調査するための情報を取得するシェルについて説明します。UAPのスローダウンは，UAPの稼働報告を監視しているときにだけ検出できます。作成するシェルの名称と実行時の形式を，次に示します。

作成するシェルの名称

/opt/hitachi/HAmon/etc/uapslowdown.sh

このシェル内に，実行したい処理を記述します。シェルには，実行権限を設定してください。

シェルの実行時の形式

uapslowdown.sh△プログラム識別名△プロセスID

（凡例）

△：半角スペースを示します。

プログラム識別名：スローダウンを検出した，実行サーバのUAPのプログラム識別名を示します。

プロセスID：スローダウンしたUAPのプロセスIDを示します。

(3)　注意事項

サーバのスローダウンは，サーバモードのサーバとしてTP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）を使用する場合だけ検出できます。

サーバのスローダウンの検出時に待機サーバが存在しない場合は，系切り替えができないため，このサーバの状態監視を続けます。このため，サーバのスローダウンから回復しない場合は，スローダウン検出のたびに，このシェルが実行されます。

システム全体のリソースが不足している場合，スローダウンを検出しても，シェルが実行されないことがあります。この結果，HAモニタがスローダウンを検出してサーバまたはUAPを異常終了させてからシェルを実行するため，情報を取得できないことがあります。

7.6　運用の自動化

HAモニタを使用したシステムで運用を自動化するための方法について説明します。この節で説明する以外の運用を自動化するには，JP1などの運用管理ソフトウェアを使用してください。HAモニタは，HAモニタやサーバの起動，系切り替え開始などの主要なタイミングでイベントを発生させます。イベントの詳細については，「付録A　HAモニタのイベントID」を参照してください。

＜この節の構成＞

7.6.1　システムの起動からサーバの起動までを自動化する

7.6.2　サーバやHAモニタの状態変化時の運用を自動化する

7.6.3　系切り替え後の運用を自動化する

7.6.1　システムの起動からサーバの起動までを自動化する

マシンの電源を入れてから，サーバの起動までを自動化する方法について説明します。使用するサーバの種類によって，サーバの起動を自動化できるかどうかが異なります。

HAモニタ，リソースサーバ，およびサーバの起動を自動化する方法について説明します。

＜この項の構成＞

(1)　HAモニタの起動を自動化する

(2)　リソースサーバの起動を自動化する

(3)　サーバの起動を自動化する

(1)　HAモニタの起動を自動化する

通常HAモニタは，カーネル起動後に自動起動されます。自動起動しない設定もできます。設定を変更するには，HAモニタの環境設定コマンド（monsetupコマンド）を使用します。

(2)　リソースサーバの起動を自動化する

リソースサーバは，HAモニタによって自動的に起動されます。自動化するための設定は不要です。

(3)　サーバの起動を自動化する

サーバモードのサーバの場合，プログラムが提供する方法でサーバの起動を自動化できます。詳細については，プログラムのマニュアルを参照してください。

モニタモードのサーバの場合，サーバの起動を自動化できません。モニタモードのサーバ起動コマンド（monbeginコマンド）を使用して手動で起動してください。

7.6.2　サーバやHAモニタの状態変化時の運用を自動化する

サーバやHAモニタの状態変化に合わせて，コマンドを自動的に実行できます。

サーバ起動時や計画系切り替え時などにオペレータが実行している操作が定型化している場合，オペレータの操作をユーザコマンドとして作成しておくことで，オペレータの操作を自動化できます。HAモニタのコマンドをユーザコマンド内で発行することもできます。ただし，HAモニタの開始・終了時には，HAモニタのコマンドを発行できません。

HAモニタがユーザコマンドを発行するタイミングについては，「3.3.2　サーバやHAモニタの状態変化時のコマンド発行」を参照してください。

7.6.3　系切り替え後の運用を自動化する

＜この項の構成＞

(1)　サーバ障害時の系切り替え後の運用を自動化する

(2)　系障害時の系切り替え後の運用を自動化する

(1)　サーバ障害時の系切り替え後の運用を自動化する

サーバモードのサーバの場合，プログラムが提供する機能を使用して，系切り替え後の運用を自動化できます。詳細については，ご使用のプログラムのマニュアルを参照してください。

モニタモードのサーバの場合，自動化できません。

(2)　系障害時の系切り替え後の運用を自動化する

系障害が原因で系切り替えが発生した場合，系障害が発生した系で，オペレータが系およびサーバの起動を手動で行う必要があります。この操作を自動化する方法が，サーバをサーバモードで運用するかモニタモードで運用するかによって異なります。

サーバモードのサーバの場合は，プログラムの機能を使用して自動化できます。詳細については，ご使用のプログラムのマニュアルを参照してください。

モニタモードのサーバの場合は，HAモニタの機能を使用して自動化できます。系障害後に障害が発生した系でサーバを再起動する場合，サーバの起動を自動化するには，HAモニタの環境設定のmonbegin_restartオペランドを指定します。デフォルトでは，自動化する設定になっています。

なお，サーバモード，モニタモードに関係なく，監視パスが使用できないなどの系障害の場合は，系切り替え先の系で待機サーバが系切り替え待ち状態になる場合があります。系切り替え待ち状態になった場合の操作については，自動化できません。この場合の操作の詳細については，「7.3.1　待ち状態のサーバを起動して業務を再開する」を参照してください。

7.7　計画的な系切り替え

ここでは，系のメンテナンスや負荷分散などの目的で，意図的に系切り替えをする方法について説明します。

＜この節の構成＞

7.7.1　計画的に系切り替えをする

7.7.1　計画的に系切り替えをする

障害の発生に関係なく，任意のタイミングで系切り替えをすることを，計画系切り替えと呼びます。計画系切り替えの方法は，サーバをサーバモードで運用するかモニタモードで運用するか，またはサーバがグループ化されているかによって異なります。

＜この項の構成＞

(1)　サーバモードのサーバの場合

(2)　モニタモードのサーバの場合

(3)　サーバをグループ化している場合

(1)　サーバモードのサーバの場合

計画系切り替えをするには，実行系で計画系切り替えコマンド（monswapコマンド）を実行します。HAモニタが実行系のサーバを計画的に停止させ，待機系のサーバに業務処理を引き継ぎます。

(2)　モニタモードのサーバの場合

計画系切り替えをするには，実行系で計画系切り替えコマンド（monswapコマンド）を実行します。

サーバの停止コマンドを作成していない場合は，次の方法で計画系切り替えをします。

実行系で稼働している実行サーバを計画停止する。
プログラムが提供する計画停止コマンドを実行します。

実行系で計画系切り替えをする。
計画系切り替えコマンド（monswapコマンド）を実行します。

(3)　サーバをグループ化している場合

サーバをグループ化している場合，計画系切り替えをするには，実行系で計画系切り替えコマンド（monswap -gコマンド）を実行します。HAモニタが実行系で稼働しているグループ内のすべてのサーバを計画的に停止させ，待機系のサーバに業務処理を引き継ぎます。

7.8　システムの変更

ここでは，システムを変更したときに必要な設定，および注意事項について説明します。

＜この節の構成＞

7.8.1　系を追加する

7.8.2　サーバを追加する

7.8.3　共有リソースを変更する

7.8.4　系やサーバを稼働させたまま共有リソースの構成を変更する

7.8.5　HAモニタやサーバの環境設定を変更する

7.8.6　稼働しているHAモニタやサーバの設定を変更する

7.8.7　ハードウェアの設定を変更する

7.8.1　系を追加する

系切り替え構成に系を追加する手順について，追加後の系の数別に説明します。

なお，一つのシステムで同時に実行できる系の最大数には上限があります。系を追加する前に，系の数が上限値を超えないことを確認してください。系の最大数は，デフォルトでは32です。ただし，HAモニタ Extensionを使用することで，上限値は変更できます。

＜この項の構成＞

(1)　追加後の系の数が32以内の場合

(2)　追加後の系の数が33以上の場合

(1)　追加後の系の数が32以内の場合

追加後の系の数が32以内の場合について説明します。系を追加する場合，追加する系にHAモニタをインストールします。インストール以降の構築の流れについては，「6.1(1)　システム構築の流れ」を参照してください。ここでは，システム全体を新しく構築する場合と比べて，系を追加する場合で異なる点について説明します。

監視パスの設定
新しい系を追加する場合，HAモニタの接続構成設定ファイルを変更する必要があります。HAモニタの接続構成設定ファイルには，接続されているすべての系のホスト名を記載します。
自動作成の場合は，定義チェックをしたあと，すべての系でHAモニタを起動してください。HAモニタの接続構成設定ファイルが自動的に作成されます。
手動作成の場合は，HAモニタの接続構成設定ファイルを編集したあと，すべての系で同じ内容にしてください。
HAモニタの接続構成設定ファイルの作成方法については，「6.8.2　HAモニタの接続構成設定ファイルの作成」を参照してください。

(2)　追加後の系の数が33以上の場合

追加後の系の数が33以上の場合について説明します。HAモニタ Extensionを使用すると，系の最大数を33以上に設定できます。HAモニタ Extensionを使用した系の最大数の変更については，「3.5.2　系の最大数の変更」を参照してください。

ここでは，構築時に設定した系の最大数（上限）の範囲内で系を追加する場合と，系の最大数（上限値）そのものを変更する場合に分けて手順を説明します。

(a)　上限の範囲内で系を追加する場合

構築時に設定した上限の範囲内で系を追加する場合，「6.1(2)　システム構築の流れ（HAモニタ Extension使用時）」の図中に示すすべての設定をしてください。

"監視パスの設定"については，「(1)　追加後の系の数が32以内の場合」を参照してください。

(b)　上限値を変更する場合

構築時に設定した上限値を変更する場合は，次の流れで設定してください。

系切り替え構成内のすべての系で稼働しているすべてのサーバを停止する。
サーバが停止されたことを確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を実行して，その系ですべてのサーバが停止していることを確認します。

系切り替え構成内のすべての系のHAモニタを停止する。
HAモニタが停止されたことを確認するには，両系のHAモニタに対してメッセージKAMN050-Iが出力されていることをsyslogで調べます。

系切り替え構成内のすべての系で，系を追加する場合の設定をする。
「6.1(2)　システム構築の流れ（HAモニタ Extension使用時）」の図中に示すすべての設定をしてください。
"監視パスの設定"については，「(1)　追加後の系の数が32以内の場合」を参照してください。
"定義ファイルの作成（HAモニタ）"では，HAモニタの動作環境を設定する定義ファイルで，hostmaxオペランドを修正します。hostmaxオペランドについては，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

7.8.2　サーバを追加する

すでに構築された系切り替え構成に，サーバを追加する手順について説明します。

サーバを追加する場合，実行系，待機系の両方にサーバをインストールし，環境設定をします。

＜この項の構成＞

(1)　準備

(2)　サーバを追加する場合の設定

(1)　準備

HAモニタを使用して，サーバが使用する共有ディスクやLANを引き継ぐ場合，次の準備が必要です。実行系と待機系間で，HAモニタを使用して共有ディスクやLANを引き継がない場合は，これらの準備は必要ありません。

共有ディスクにボリュームグループを追加する。
HAモニタを使用した系切り替え構成では，サーバ単位で一つのボリュームグループを切り替えるため，必要に応じて追加するサーバ用のボリュームグループを作成しておきます。

HA Boosterの制御グループにディスクデバイスを登録する。
HA Boosterを使用する場合，ボリュームグループではなく，制御グループ単位で切り替えます。必要に応じて，追加するサーバで使用する制御グループにディスクデバイスを登録してください。

サーバが使用するエイリアスIPアドレスを確保する。
HAモニタは，エイリアスIPアドレスを引き継ぎます。サーバは，現用系と予備系とで同じエイリアスIPアドレスを使用するため，一つのサーバにつき最低1個のエイリアスIPアドレスが必要です。一つのサーバで複数のエイリアスIPアドレスを使用することもできます。

(2)　サーバを追加する場合の設定

ここでは，系にサーバを追加する場合の設定と，システム全体を新規に構築する場合とを比べて，異なる点について説明します。

一つの系で同時に実行できるサーバの最大数には上限があります。サーバを追加する前に，サーバの数が上限値を超えないことを確認してください。一つの系で稼働するサーバの最大数は，デフォルトでは16です。HAモニタの環境設定のservmaxオペランドの値を変更することで，上限値を変更できます。

(a)　上限の範囲内でサーバを追加する場合

上限の範囲内でサーバを追加する場合，「6.1　構築の流れ」で示す"サーバを追加する場合の設定"の流れに従って設定してください。HAモニタを停止する必要はありません。

(b)　上限値を変更する場合

上限値を変更する場合は，「6.1　構築の流れ」で示す"サーバを追加する場合の設定"の流れに加えて，HAモニタの環境設定が必要です。次の流れで設定してください。

実行系および待機系で稼働しているすべてのサーバを停止する。
サーバが停止されたことを確認するには，サーバ・系の状態表示コマンド（monshowコマンド）を実行して，その系ですべてのサーバが停止していることを確認します。

実行系および待機系のHAモニタを停止する。
HAモニタが停止されたことを確認するには，両系のHAモニタに対してメッセージKAMN050-Iが出力されていることをsyslogで調べます。

サーバを追加する場合の設定，およびHAモニタの環境設定をする。
「6.1　構築の流れ」で示す"サーバを追加する場合の設定"の流れに従って，設定してください。
なお，"定義ファイルの作成（サーバ）"と同時に，"定義ファイルの作成（HAモニタ）"もする必要があります。"定義ファイルの作成（HAモニタ）"では，HAモニタの動作環境を設定する定義ファイルで，servmaxオペランドを修正します。servmaxオペランドについては，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

7.8.3　共有リソースを変更する

共有リソースを変更する場合の手順について説明します。系やサーバを稼働させたまま動的に変更できる共有リソースもあります。共有リソースの動的変更の詳細については，「7.8.4　系やサーバを稼働させたまま共有リソースの構成を変更する」を参照してください。

共有リソースを変更する手順を次に示します。この手順を，実行系および待機系でしてください。

サーバを停止する。
共有リソースを使用しているサーバだけを停止します。HAモニタは起動させたままで問題ありません。

共有リソースの設定をする。
使用する共有リソースの設定をします。詳細については，「6.10　サーバが使用する共有リソースの設定」を参照してください。

環境設定の定義ファイルを変更する。
共有リソースの種類に応じて，サーバ対応の環境設定，またはその他の定義を変更します。
共有リソースの種類と，変更する設定内容を次の表に示します。サーバ対応の環境設定については，「8.4.1　サーバ対応の環境設定（servers）」を参照してください。

表7-5　共有リソースの種類と変更する設定内容

リソースの種類
変更するオペランド（サーバ対応の環境設定）
変更する環境設定（サーバ対応の環境設定以外）
変更する環境設定の参照先

共有ディスク

disk

vg_on_opt

vg_neck

－
－

制御グループ

hab_gid

HA Boosterのstartスクリプト

HA Booster関連のドキュメント

ファイルシステム

fs_name

fs_mount_dir

fs_mount_opt

fs_umount_retry

fs_neck

－
－

LAN

lan_updown

ip_neck

サーバ識別名.up

サーバ識別名.down

「6.10.2　LANの状態設定ファイルの設定」

そのほかのリソース

uoc_neck

ユーザコマンド

「6.16　ユーザコマンドの作成」

すべてのリソース

dev_timelimit

deviceoff_order

－
－

（凡例）

－：該当しません。

定義チェックをする。
定義チェックコマンド（moncheckコマンド）を実行します。

サーバを起動する。
サーバモードのサーバの場合は，プログラムが提供する起動コマンドを実行します。モニタモードのサーバの場合は，モニタモードのサーバ起動コマンド（monbeginコマンド）を実行します。

サーバの状態を確認する。
サーバ・系の状態表示コマンド（monshowコマンド）を実行します。

7.8.4　系やサーバを稼働させたまま共有リソースの構成を変更する

系やサーバを稼働させたまま，共有リソースの追加・削除をすることを共有リソースの動的変更と呼びます。ここでは，共有リソースの動的変更をする方法について説明します。

共有リソースの種類によって，動的変更をする方法が異なります。共有ディスクを動的に追加・削除するには，サーバの共有リソース動的変更コマンド（mondeviceコマンド）を使用します。LANを追加・削除するには，LANの状態設定ファイルを編集してください。

サーバの共有リソース動的変更コマンド（mondeviceコマンド）を使用する場合，次の手順で共有リソースの追加・削除をします。サーバの共有リソース動的変更コマンド（mondeviceコマンド）は，実行系，待機系のどちらでも実行できます。

実行サーバおよび待機サーバが起動完了していることを確認する。
サーバ・系の状態表示コマンド（monshowコマンド）を実行して，実行サーバには"ONL"，待機サーバには"SBY"と表示されていることを確認します。

共有リソースの接続または切り離しをする。
サーバの共有リソース動的変更コマンド（mondeviceコマンド）を実行して，共有リソースの接続または切り離しをします。共有リソースの変更結果に合わせて，リソースを共用している実行サーバおよび待機サーバのサーバ対応の環境設定が書き替えられます。

変更内容を確認する。
共有リソースが指定どおり変更されたかどうかを，サーバ・系の状態表示コマンド（monshow -dコマンド）で確認します。

サーバの共有リソース動的変更コマンド（mondeviceコマンド）を実行すると，共有リソースの変更結果に合わせて，そのリソースを共有している実行サーバと待機サーバのサーバ対応の環境設定が自動で書き換えられます。共有リソースの動的変更後は，サーバ対応の環境設定が正しく書き換えられたかどうかも確認してください。

HAモニタは，実行サーバの共有リソースが変更できない場合は，待機サーバの共有リソースも変更しません。また，待機サーバの共有リソースが変更できない場合は，実行サーバの共有リソースだけを変更します。この場合，実行サーバと待機サーバとで，共用するリソースの設定が異なる状態になっています。共用するリソースの設定を一致させるには，待機サーバを一度停止させ，サーバ対応の環境設定の内容を実行サーバと合わせてから，待機サーバを再起動してください。

サーバの共有リソース動的変更コマンド（mondeviceコマンド）で共有リソースが変更できない場合，HAモニタの障害やコマンドの指定に矛盾がある原因のほかに，次の原因が考えられます。

実行サーバに対してサーバの共有リソース動的変更コマンド（mondeviceコマンド）を実行した場合

実行サーバが起動完了していません。

実行サーバにサーバ障害が発生しています。

待機サーバへの変更連絡の際に通信障害が発生しました（待機サーバの共有リソースは変更できません）。

待機サーバに対してサーバの共有リソース動的変更コマンド（mondeviceコマンド）を実行した場合

実行サーバまたは待機サーバが起動完了していません。

実行サーバまたは待機サーバにサーバ障害が発生しています。

実行サーバへの共有リソース変更連絡，または実行サーバからの共有リソース変更完了連絡の際に通信障害が発生しました（実行サーバの共有リソースは変更できません）。

7.8.5　HAモニタやサーバの環境設定を変更する

環境設定の内容を変更する手順について説明します。

HAモニタの環境設定（sysdef）

HAモニタの環境設定を変更する場合，HAモニタを停止してください。このとき，HAモニタが正常終了していることを確認してください。系切り替え時にリセットされた系で，HAモニタの環境設定を変更して再起動すると，正常に動作しないおそれがあります。定義ファイルの編集が終わったら，HAモニタおよびサーバを起動します。

サーバの環境設定（servers，およびservers_opt）

サーバの環境設定を変更する場合，サーバを停止してください。また，グループ化されているサーバの環境設定を変更する場合，またはグループに対してサーバの追加・削除をする場合は，グループ内のすべてのサーバを停止してください。HAモニタは起動したままで問題ありません。定義ファイルの編集が終わったら，サーバを起動します。

モニタモードのプログラムの環境設定（programs）

モニタモードのプログラムの環境設定を変更する場合，モニタモードのプログラム対応の環境設定のaliasオペランドに指定したサーバを停止してください。HAモニタは起動したままで問題ありません。定義ファイルの編集が終わったら，モニタモードのプログラム対応の環境設定のserver_aliasオペランドに指定したサーバを起動します。

なお，稼働しているHAモニタ，サーバ，およびモニタモードのプログラム管理機能を使用するプログラムの設定を変更することもできます。変更する方法の詳細については，「7.8.6　稼働しているHAモニタやサーバの設定を変更する」を参照してください。

7.8.6　稼働しているHAモニタやサーバの設定を変更する

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）を実行すると，稼働しているHAモニタやサーバの次の設定を変更できます。

系障害監視時間（HAモニタの環境設定のpatrolオペランド）

サーバ障害監視時間（サーバ対応の環境設定のpatrolオペランド）

プログラムのスローダウン監視時間（モニタモードのプログラム対応の環境設定のpatrolオペランド）

ここでは，各設定の変更について説明します。

注意

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）では，実行サーバ稼働中の共有リソースの変更コマンド（mondeviceコマンド）と異なり，HAモニタおよびサーバの環境を設定する定義ファイルの内容は変更されません。設定を変更したあとに系やサーバを再起動すると，変更した設定は定義ファイルで指定している設定に戻ります。

＜この項の構成＞

(1)　系障害監視時間の変更

(2)　サーバ障害監視時間の変更

(3)　プログラムのスローダウン監視時間の変更（プログラム管理機能使用時）

(1)　系障害監視時間の変更

HAモニタの環境設定のpatrolオペランドに指定した系障害監視時間を変更できます。HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）はどの系からも実行でき，一つの系で実行すれば接続しているすべての系の系障害監視時間を変更できます。

コマンドの実行中に他系の障害や監視パスの障害など，系間通信ができない状態になった場合は，コマンドの処理は中断されます。

系障害監視時間を変更する場合は，次のことに注意してください。

変更するすべての系が接続中であることを確認してください。

複数の系から同時にコマンドを実行しないでください。

系障害監視時間を変更したあとに系を再起動した場合や，通信障害などで系間での監視時間が不一致になった場合は，HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）を再度実行し，系間での系障害監視時間を一致させてください。

系の監視履歴を取得している場合，変更後の系障害監視時間に系の監視履歴取得時間より短い値を指定すると，監視履歴が取得されません。

(2)　サーバ障害監視時間の変更

サーバ対応の環境設定のpatrolオペランドに指定したサーバ障害監視時間を変更できます。

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）を実行した場合，コマンドを実行した時点から変更後のサーバ障害監視時間でサーバを監視し直します。

サーバ障害監視時間を変更する場合は，次のことに注意してください。

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）では，コマンドを実行した系のサーバ障害監視時間だけを変更します。待機サーバが稼働する系でもコマンドを実行してください。

サーバの監視履歴を取得している場合，変更後のサーバ障害監視時間にサーバの監視履歴取得時間より短い値を指定すると，監視履歴は取得されません。

(3)　プログラムのスローダウン監視時間の変更（プログラム管理機能使用時）

モニタモードのプログラム対応の環境設定のpatrolオペランドに指定した，プログラムのスローダウン監視時間を変更できます。

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）を実行した場合，コマンドを実行した時点から変更後のプログラムのスローダウン監視時間でプログラムを監視し直します。

プログラムのスローダウン監視時間を変更する場合は，次のことに注意してください。

HAモニタ・サーバ稼働中の設定変更コマンド（monchangeコマンド）では，コマンドを実行した系のプログラムのスローダウン監視時間だけを変更します。待機サーバが稼働する系でもコマンドを実行してください。

同一のプログラム識別名で稼働する複数プロセス構成の場合は，すべてのプロセスのプログラムのスローダウン監視時間を変更します。

7.8.7　ハードウェアの設定を変更する

ハードウェアの設定を変更する場合，あわせてHAモニタの設定変更が必要となる場合があります。

使用しているマシンの機種がHA8500の場合，障害管理プロセサのログイン名およびパスワードを変更するときには，HAモニタのリセット手順ファイルを編集する必要があります。リセット手順ファイルがBMC.rspの場合は，障害管理プロセサのホスト名を変更するときも，HAモニタのリセット手順ファイルを編集する必要があります。

リセット手順ファイルの編集方法については，「6.6.3　HAモニタのリセット手順ファイルの設定（HA8500）」を参照してください。

8.　環境設定で定義するファイル

HAモニタを使用するに当たって，ユーザはHAモニタおよびサーバの環境設定を定義ファイルにする必要があります。

この章では，定義の記述規則，定義ファイルに指定するオペランド，および環境設定例について説明します。

＜この章の構成＞

8.1　定義ファイルの概要

8.2　定義の規則

8.3　HAモニタの環境設定

8.4　サーバの環境設定

8.5　モニタモードのプログラムの環境設定

8.6　環境設定例

8.1　定義ファイルの概要

ここでは，ユーザが環境設定で定義するファイルについて説明します。定義する必要がある環境設定のファイルを，次に示します。

sysdefファイル
HAモニタが動作するための環境設定をします。詳細については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

serversファイル
サーバが動作するための環境設定をします。リソースサーバを使用する場合も，serversファイルで環境設定をします。詳細については，「8.4.1　サーバ対応の環境設定（servers）」を参照してください。

servers_optファイル
排他サーバが動作するための環境設定をします。設定は任意ですが，一つの系で複数の実行サーバを起動させたくない場合は設定することをお勧めします。排他サーバを使用する場合，serversファイルとservers_optファイルの両方で環境設定をする必要があります。詳細については，「8.4.2　排他サーバの環境設定（servers_opt）」を参照してください。

programsファイル
モニタモードのプログラム管理機能を使用するプログラムが動作するための定義をします。詳細については，「8.5.1　モニタモードのプログラム対応の環境設定（programs）」を参照してください。

系に定義ファイルを設定するに当たっての注意事項を，次に示します。

定義ファイルは，HAモニタがあるすべての系で設定してください。

定義ファイルの作成に当たって，定義ファイルのオペランドを現用・予備系で同じ値にする必要がある個所と，異なる値にする必要がある個所があります。

定義ファイルの作成が完了したら，必ずすべての系に配布した上で，定義チェックコマンド（moncheckコマンド）を実行してください。

8.2　定義の規則

定義を記述するに当たって，次の基本的な規則があります。

定義文は，";"（セミコロン）で区切ります。

オペランドは，","（コンマ）で区切ります。

値は，":"（コロン）で区切ります。

コメントは，"/*…*/"で囲みます。"/*…*/"の中に，"/*"，または"*/"が入っている場合には，最初に正しい規則で囲まれている部分をコメントと見なし，それ以外は定義文の一部と見なします。

ここでは，基本的な規則を踏まえた上で，環境設定で記述する定義の記述形式，および定義で使用する記号について説明します。

＜この節の構成＞

8.2.1　定義の記述形式

8.2.2　定義で使用する記号

8.2.1　定義の記述形式

定義の記述形式を，次に示します。

△₀定義文△₁オペランド△₁値△₀：△₀…△₀;△₀

（凡例）

△₀：0個以上の空白，タブ，または改行コード

△₁：1個以上の空白，タブ，または改行コード

注

△₀，△₁で示す場所以外では，空白，タブ，または改行コードで文字列を区切らないでください。

8.2.2　定義で使用する記号

定義の説明に使用する，各種の記号を説明します。

ここで述べる文法記述記号，属性表示記号および構文要素記号は，実際の定義には記述しません。

＜この項の構成＞

(1)　文法記述記号

(2)　属性表示記号

(3)　構文要素記号

(1)　文法記述記号

定義文およびオペランドの文法を説明する記号です。各記号の意味を，次の表に示します。

表8-1　定義文の文法記述記号一覧

文法記述記号
意　味

〔　　〕
この記号で囲まれている項目は，省略してもよいことを示します。
（例）〔:TCP/IP LANのホスト名〕
TCP/IP LANのホスト名を指定するか，または何も指定しないことを示します。

…
この記号で示す直前の項目を，繰り返して指定できることを示します。
（例）:TCP/IP LANのホスト名…
TCP/IP LANのホスト名を，複数個指定できることを示します。

｜
複数の項目間の区切りを示します。
（例）online｜standby
項目として，onlineまたはstandbyがあることを示します。

｛　　｝
この記号で囲まれている項目の中から，一つを選択して指定することを示します。項目が"｜"で区切られている場合は，そのうちの一つを選択して指定します。
（例）｛online｜standby｝
onlineとstandbyのどちらかを選択して指定することを示します。

下線
この記号で示す項目は，該当オペランドを省略した場合の，仮定値を示します。
（例）〔｛online｜standby｝〕
オペランドを省略した場合，onlineを仮定値とすることを示します。

太字
この記号で示す項目は，系切り替え構成内のすべての系で，同じ指定にする値を示します。
（例）:TCP/IP LANのサービス名
TCP/IP LANのサービス名を，系切り替え構成内のすべての系で同じ値にすることを示します。

(2)　属性表示記号

ユーザ指定値の範囲などを説明する記号です。各記号の意味を，次の表に示します。

表8-2　属性表示記号一覧

属性表示記号
意　味

～
この記号のあとに，ユーザ指定値の属性（仮定値，記述内容，指定範囲）を示します。
（例）name～<1～32文字の英数字>
nameオペランドのユーザ指定値の属性が<1～32文字の英数字>であることを示します。

<　>
ユーザ指定値の記述内容を示します。
（例）～<1～32文字の英数字>
ユーザ指定値が1～32文字の英数字であることを示します。

((　))
ユーザ指定値の指定範囲を示します。
（例）～((16または64))
ユーザ指定値の指定範囲が16または64であることを示します。

《　》
ユーザが指定を省略したときの仮定値を示します。
（例）～《16》
指定を省略したときの仮定値は16であることを示します。

(3)　構文要素記号

属性表示記号のうち，ユーザ指定値の記述内容を説明する記号です。HAモニタでは不正文字（制御コードなど）は使用できません。各記号の意味を，次の表に示します。

表8-3　構文要素記号一覧

構成要素記号 | 意　味
<英数字> | アルファベット（A～Z，a～z）および数字（0～9）※
<符号なし整数> | 数字（0～9）
<パス名> | アルファベット（A～Z，a～z），数字（0～9），"/"（スラント），"-"（ハイフン），"_"（アンダーライン），および"."（ピリオド）
<サーバパス名> | ":"（コロン），";"（セミコロン），","（コンマ），空白，タブ，および改行コード以外の，任意の文字

注※　先頭の文字はアルファベットを指定してください。

8.3　HAモニタの環境設定

HAモニタの環境設定では，HAモニタが動作するための定義をします。

＜この節の構成＞

8.3.1　HAモニタの環境設定（sysdef）

8.3.1　HAモニタの環境設定（sysdef）

HAモニタの環境を設定する定義ファイルは，HAモニタの環境設定用ディレクトリの下にsysdefというファイル名で作成します。

また，HAモニタのサンプルファイル用ディレクトリの下に，sysdefファイルのサンプルが用意されています。このファイルをHAモニタの環境設定用ディレクトリにコピーし，書き換えて使用すると，定義ファイルを最初から作成する手間が省けます。

なお，この定義ファイルは系ごとに作成します。太字部分は，系間で同じ値を指定してください。太字以外の部分は，系間で矛盾がないように設定してください。

HAモニタの環境設定をする定義ファイルを，次に示します。

/*    HAモニタの環境設定    */
 environment  name  自系のホスト名
             ,address
                    自系のホストアドレス
             ,patrol
                    系障害監視時間
             ,lan   TCP/IPのホスト名〔:TCP/IPのホスト名…〕
             ,lanport
                    TCP/IPのサービス名〔:TCP/IPのサービス名…〕
           〔,fs_log_size
                  ｛ファイルシステム切り替えログファイルのサイズ
                  ｜65536｝〕
           〔,servmax
                  ｛16｜64｜128｜129～512※｝〕
           〔,hostmax※
                  ｛接続する系の最大数｜32｝〕
           〔,pgmmax
                  ｛同時稼働プログラムの最大数｜0｝〕;
〔function  〔 cpudown
                  ｛online｜standby｜system｝｛,｜;｝〕
           〔 standbyreset
                  ｛use｜nouse｝｛,｜;｝〕
           〔 pathpatrol
                    監視パスのヘルスチェック間隔｛,｜;｝〕
           〔 pathpatrol_retry
                  ｛再チェック間隔｜30｝:｛再チェック回数｜5｝｛,｜;｝〕
           〔 message_retry
                  ｛リトライ間隔｜3｝｛,｜;｝〕
           〔 connect_retry
                  ｛接続間隔｜5｝:｛接続回数｜200｝｛,｜;｝〕
           〔 monbegin_restart
                  ｛use｜nouse｝｛,｜;｝〕
           〔 netmask
                  ｛byte｜bit｝｛,｜;｝〕
           〔 usrcommand
                    ユーザコマンドの絶対パス名｛,｜;｝〕
           〔 resetpatrol
                  ｛リセットパスのヘルスチェック間隔｜2｝｛,｜;｝〕
           〔 multistandby
                  ｛use｜nouse｝｛,｜;｝〕
           〔 deviceoff_order
                  ｛order｜reverse｝｛,｜;｝〕
           〔 reset_type
                  ｛server｜host｝｛,｜;｝〕
           〔 partition_reset
                  ｛use｜nouse｝｛,｜;｝〕
           〔 jp1_event
                  ｛use｜nouse｝｛,｜;｝〕
           〔 ph_log_size
                    監視履歴ファイルのサイズ｛,｜;｝〕
           〔 ph_threshold
                    系監視履歴取得時間｛,｜;｝〕
           〔 termcmd_at_abort
                  ｛use｜nouse｝｛,｜;｝〕
           〔 alive_interval
                    aliveメッセージの送信間隔｛,｜;｝〕
           〔 alive_multicast
                  ｛use｜nouse｝｛,｜;｝〕
           〔 multicast_lan
                    マルチキャストグループのホスト名｛,｜;｝〕
           〔 lanfailswitch
                  ｛use｜nouse｝｛,｜;｝〕
           〔 lancheck_patrol
                  ｛LANの監視間隔｜15｝｛,｜;｝〕
           〔 patrol_100ms
                  ｛use｜nouse｝｛,｜;｝〕
           〔 suppress_reset
                    最少稼働ホスト数｛,｜;｝〕
           〔 exitcode
                  ｛type1｜type2｝｛,｜;｝〕
           〔 vg_off
                  ｛sequential｜parallel｝｛,｜;｝〕
           〔 vmware_env
                   ｛use｜nouse｝｛,｜;｝〕
           〔 patrol_type
                  ｛server｜host｝｛,｜;｝〕
           〔 resetpatrol_mode
                  ｛mode1｜mode2｝;〕〕

注※　HAモニタ Extensionを使用する場合だけ指定できます。

＜この項の構成＞

(1)　environment定義文

(2)　function定義文

(1)　environment定義文

HAモニタの動作環境を定義します。environment定義文のオペランドを，次に示します。

name～<1～32文字の英数字>

HAモニタで複数の系を識別するために使用する名称です。使用するマシンの機種によって，指定する名称が異なります。nameオペランドに指定した名称は，HAモニタのコマンド実行時にホスト名（host name）として表示されます。

使用するマシンの機種がBladeSymphonyまたはHA8000の場合，系ごとに固有となる任意の名称を指定します。

使用するマシンの機種がHA8500の場合，自系の障害管理プロセサに指定したIPアドレスに対応するホスト名を指定します。

address～<1～8桁の符号なし整数>((0～99999999))

CPUのリセット時に系を特定するために，自系のホストアドレスを任意の値で指定します。ハードウェアへの設定はHAモニタがします。

監視パスまたはリセットパスでつながるすべての系で，それぞれ固有のアドレスを指定してください。なお，システム内に互いに監視し合わない系切り替え構成が複数あり，かつ，それらがリセットパスを共用する場合，すべての系でそれぞれ固有となるように指定してください。

複数の系で同じアドレスを設定すると，HAモニタが誤動作するおそれがあります。

使用するマシンの機種がBladeSymphonyまたはHA8000の場合は，ハードウェアの制約上，0～9999の範囲で指定してください。

patrol～<符号なし整数>((3～600))（単位：秒）

系障害の判断基準となる，他系からのaliveメッセージを監視する時間（系障害監視時間）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。patrolオペランドに指定した時間を超えても他系からaliveメッセージが送信されない場合，HAモニタは系障害と判断します。

lan～<1～32文字の英数字>

監視パスに使用するTCP/IP LANのホスト名を指定します。系ごとに固有の名称にしてください。

lanオペランドに指定するホスト名は，/etc/hostsファイルに設定したホスト名と同じにしてください。/etc/hostsファイルについては，「6.8.1　ホスト名とサービス名の登録」を参照してください。

TCP/IP LANのホスト名は，":"で区切って指定します。6個まで指定できます。複線化した監視パスの中で優先して使用したいパスがある場合は，そのパスのホスト名の前に，"#"を付けて指定します。優先して使用したいパスは，一つだけ指定できます。次に指定の例を示します。

lan  #path11:path12,

例で示す指定では，監視パスが"path11"と"path12"の2本に複線化され，"path11"の監視パスが優先して使用されます。

lanport～<1～32文字の英数字>

監視パスに使用するTCP/IP LANのサービス名を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

lanportオペランドに指定するサービス名は，/etc/servicesファイルに設定したサービス名と同じにしてください。/etc/servicesファイルについては，「6.8.1　ホスト名とサービス名の登録」を参照してください。

lanportオペランドでは，lanオペランドで指定したホスト名に対応するサービス名を，同じ位置の引数に指定します。サービス名の指定数はlanオペランドのホスト名の指定数と同じにしてください。次に指定の例を示します。

　　　lan　　　path11 :path12,
　　　　　　　　　↓　　　↓
　　　lanport　HAmon1 :HAmon2,

例の場合，lanオペランドの"path11"はlanportオペランドの"HAmon1"に，lanオペランドの"path12"はlanportオペランドの"HAmon2"に対応します。

fs_log_size～<符号なし整数>((0～2147483647))《65536》（単位：バイト）

ファイルシステム切り替え時のログファイルの最大サイズをバイト数で指定します。系切り替え構成内のすべての系で同じ値を指定してください。ファイルサイズが最大を超えた場合，次のログ取得時点でファイルが自動的にバックアップされ，クリアされます。

servmax～((16，64，128，または129～512))《16》

一つの系で同時に稼働できるサーバの最大数を指定します。系切り替え構成内のすべての系で同じ値を指定してください。次に示す以外の数値は指定できません。

16：同時に稼働できるサーバの最大数を16に設定します。

64：同時に稼働できるサーバの最大数を64に設定します。

128：同時に稼働できるサーバの最大数を128に設定します。

129～512：同時に稼働できるサーバの最大数を129～512に設定します。HAモニタ Extensionを使用する場合にだけ指定できる値です。

同時に稼働できるサーバの最大数をデフォルトの16以外に設定した場合，カーネルのパラメタの設定も変更する必要があります。カーネルのパラメタの設定の詳細については，「6.3.6　カーネルのパラメタの設定」を参照してください。

hostmax～((32～256))《32》

自系を含む，接続する系の最大数を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドは，HAモニタ Extensionを使用する場合だけ指定できます。

HAモニタ Extensionについては，「3.5　HAモニタ Extensionの機能」を参照してください。

また，系の最大数を変更した場合，カーネルのパラメタの設定も変更する必要があります。カーネルのパラメタの設定の詳細については，「6.3.6　カーネルのパラメタの設定」を参照してください。

pgmmax～((0～256))《0》

モニタモードのプログラム管理機能を使用する場合に，一つの系でhamon_patrolstart関数を発行するプロセスの最大数を指定します。プログラム管理機能を使用する場合は，必ずデフォルト値から変更してください。系切り替え構成内のすべての系で同じ値を指定してください。

(2)　function定義文

HAモニタの動作オプションを定義します。定義は任意です。定義していない場合は，仮定値が設定されます。function定義文のオペランドを，次に示します。

cpudown～《online》

実行系と待機系のどちらをリセット優先系にするかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。リセット優先系に指定すると，実行系と待機系とで同時に系障害を検出した場合に，リセット優先系に指定した系が優先的に相手の系をリセットします。

online：実行系をリセット優先系にします。

standby：待機系をリセット優先系にします。

system：リセット優先系を決めないで，系の同時リセットを防止します。相互系切り替え構成で，かつマシンの機種がBladeSymphonyでSVPがクラスタ管理機能に対応している場合以外は，systemを指定しないでください。
また，次のようにオペランドを指定する場合，systemは指定できません。
・ reset_typeオペランドにhostを指定
・ multistandbyオペランドにuseを指定
・ standbyresetオペランドにuseを指定
・ vmware_envオペランドにuseを指定

standbyreset～《nouse》

待機系の系障害を実行系が検出した場合に，待機系をリセットするかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。multistandbyオペランドにuseを指定した場合は，指定しても無視されます。

use：待機系をリセットします。1:1系切り替え構成以外では，useを指定しないでください。

nouse：待機系をリセットしません。

pathpatrol～<符号なし整数>((1～240))（単位：分）

監視パスのヘルスチェック間隔を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを指定すると，ヘルスチェックが実行され，複線化した監視パスの一部に障害が発生した場合に障害を早期に検知できます。指定を省略した場合は，監視パスのヘルスチェックを実施しません。必ず設定してください。

pathpatrol_retry

監視パスの障害検出時に，監視パスの状態を再チェックする間隔と回数を，":"で区切って指定します。系切り替え構成内のすべての系で同じ値を指定してください。pathpatrolオペランドの指定を省略した場合は，監視パスの再チェックはしません。

再チェック間隔～<符号なし整数>((3～600))《30》（単位：秒）
監視パスの再チェックの間隔を指定します。

再チェック回数～<符号なし整数>((0～20))《5》（単位：回）
監視パスの再チェックの回数を指定します。0を指定すると，監視パスの再チェックはしません。

再チェック間隔と再チェック回数には，それぞれの積がpathpatrolオペランドで指定した監視パスのヘルスチェック間隔を超えない値を指定してください。指定する値は，次に示す計算式で確認してください。

監視パスのヘルスチェック間隔×60 ≧ 再チェック間隔×（再チェック回数＋1）＋a

（凡例）　a：30～60秒

message_retry～<符号なし整数>((3～600))《3》（単位：秒）

監視パスを使用する問い合わせ応答メッセージの送信失敗時に，メッセージ送信をリトライする間隔を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

message_retryオペランドの指定を省略した場合は，HAモニタが3秒間隔でメッセージ送信をリトライします。

リトライは，送信が成功するまで続けます。系間の監視中（aliveメッセージの監視中）でない場合，HAモニタは，60秒を超えても問い合わせ応答メッセージの送信が成功しなければ系障害が発生したと判断します。なお，message_retryオペランドに60秒以上を指定した場合は，指定した時間までメッセージの受信を待ってから系障害と判断します。

connect_retry

HAモニタ間で接続処理をする間隔と回数を，":"で区切って指定します。系切り替え構成内のすべての系で同じ値を指定してください。

接続されているHAモニタが多い場合は，HAモニタ間が接続しなくなることがあるため，必ず指定してください。このオペランドはHAモニタの接続構成設定ファイルが作成されている場合に有効となります。

接続間隔～<符号なし整数>((5～60))《5》（単位：秒）
HAモニタ間での接続処理の間隔を指定します。間隔が短いとHAモニタの性能に影響し，長いとHAモニタ間の接続が遅れる場合があります。目安として，接続されているHAモニタの数が10以上の場合は，10秒以上を指定してください。

接続回数～<符号なし整数>((1～9999))《200》（単位：回）
HAモニタ間での接続処理のリトライ回数を指定します。9999を指定すると，すべてのHAモニタと接続するまで接続処理を繰り返します。
回数が少ないとHAモニタ間の接続ができない場合があり，多いとHAモニタの性能に影響します。したがって，通常はデフォルト値を指定しておき，HAモニタ間の接続ができないことがある場合だけ，回数を増やして指定してください。
なお，この回数を超えても接続できなかった場合は，メッセージKAMN176-Eを出力します。

monbegin_restart～《use》

系障害で実行系がリセットされた際に，実行系のHAモニタの再起動後，自動でモニタモードのサーバ起動コマンド（monbeginコマンド）を実行して，モニタモードのサーバを起動するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：モニタモードのサーバを自動で起動します。JP1などの運用管理ソフトウェアを使用して自動でサーバを起動しない場合は，useを指定することをお勧めします。

nouse：モニタモードのサーバを自動で起動しません。JP1などの運用管理を使用して自動でサーバを起動する場合は，nouseを指定してください。

netmask～《byte》

監視パスとして使用するLANインタフェースに設定したネットマスクを指定します。系切り替え構成内のすべての系で同じ値を指定してください。また，LANが同一ネットワーク番号で複数のサブネットとして構成されているネットワークでは，同じネットマスクを設定してください。ネットマスクの設定については，「5.4.2　必要なIPアドレス」を参照してください。

netmaskオペランドの設定およびネットマスクの設定を誤ると，他系のHAモニタと通信ができないなど，HAモニタが誤動作します。

byte：ネットマスクが10進表現で255，0の値の場合にだけ指定します。次に例を示します。

255.255.0.0

bit：ネットマスクが10進表現で255，0以外の値がある場合に指定します。次に例を示します。

255.255.255.192

netmaskオペランドにbitを指定する場合，ネットマスクの設定では，次の制限があります。
IPアドレスとネットマスクの組み合わせによって認識されるネットワークアドレスの部分（ネットワーク番号の部分とサブネット番号の部分）は，各クラスで決められているネットワーク番号の部分をすべて含んでいる必要があります。例えば，クラスBのネットワークに対して"255.254.0.0"というネットマスクは設定できません。

ネットマスクの値は，OSのifconfigコマンドで確認できます。ネットマスクおよびifconfigコマンドの詳細については，OSのマニュアルを参照してください。

usrcommand～<1～1000文字のパス名>

HAモニタに自動発行させるユーザコマンドの絶対パス名を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

ユーザコマンドの作成方法やコーディング例については，「6.16　ユーザコマンドの作成」を参照してください。

resetpatrol～<符号なし整数>((1～60))《2》（単位：分）

リセットパスのヘルスチェック間隔を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

リセットパスのヘルスチェック間隔は，接続するHAモニタの数によって異なります。指定する値は，次の計算式を満たすようにしてください。

リセットパスのヘルスチェック間隔×60 ＞ ホスト数×10

multistandby～《nouse》

一つの実行サーバに対して複数の待機サーバを定義できる，マルチスタンバイ機能を使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。マルチスタンバイ機能の詳細については，「4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理」を参照してください。

use：マルチスタンバイ機能を使用します。

nouse：マルチスタンバイ機能を使用しません。

deviceoff_order～《order》

共有リソースの切り離しをする順序を指定します。系切り替え構成内のすべての系で同じ値を指定してください。このオペランドの指定は，HAモニタに定義されているサーバすべてに適用されます。

また，サーバごとに共有リソースの切り離しをする順序を指定することもできます。サーバごとに指定する方法については，「8.4.1　サーバ対応の環境設定（servers）」を参照してください。また，共有リソースの切り離しをする順序の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

order：接続時と同じ順番で共有リソースの切り離しをします。

reverse：接続時と逆の順番で共有リソースの切り離しをします。

reset_type～《server》

リセット発行系の決定方法を指定します。系切り替え構成内のすべての系で同じ値を指定してください。HAモニタの環境設定のmultistandbyオペランドにuseを指定した場合は，このオペランドの設定に関係なく，hostが仮定されます。

server：リセット発行系とリセット優先系の決定手順に従い，リセット発行系を決定します。

host：リセット発行系決定時のリセット優先系を，リセット優先度に基づいて決定します。リセット優先度は，HAモニタの環境設定のaddressオペランドに指定したホストアドレスが小さい系ほど，高くなります。

partition_reset～《nouse》

物理パーティションリセット機能を使用するかどうかを指定します。

このオペランドは，自系がBladeSymphonyのLPARモードである場合に有効です。LPARモードの系とBasicモードの系を系切り替え構成にする場合，Basicモードの系に指定する必要はありません。LPARモードの系だけに指定してください。

use：物理パーティションリセット機能を使用します。LPARモードの系のリセット失敗時にプロセサごとリセットして系切り替えする場合はuseを指定してください。

nouse：物理パーティションリセット機能を使用しません。LPARモードの系のリセット失敗時に系切り替え待ち状態にする場合はnouseを指定してください。

jp1_event～《nouse》

JP1のイベント通知機能を使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。JP1のイベント通知機能を使用するには，システムに物理ホスト環境のJP1/Baseが必要です。

jp1_eventオペランドにuseを指定すると，HAモニタがJP1のイベントを発行します。jp1_eventオペランドを省略した場合，HAモニタではJP1のイベントを発行しません。

use：JP1のイベント通知機能を使用します。

nouse：JP1のイベント通知機能を使用しません。

ph_log_size～<符号なし整数>((1024～10485760))（単位：バイト）

サーバや系に発生したスローダウンの情報を監視履歴として記録する監視履歴ファイルのサイズを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを指定しておくと，HAモニタ起動時に指定したサイズで監視履歴ファイルが作成され，サーバや系の監視履歴を取得できます。監視履歴ファイル内の空白がなくなると監視履歴ファイルの内容はラップアラウンドされ，バックアップファイルに書き換えられます。監視履歴ファイルのサイズを見積もるための計算式を，次に示します。

監視履歴を取得するサーバや系の起動回数×180＋監視履歴ファイルに記録させたいスローダウンの回数×90

ph_threshold～<符号なし整数>((5～559))（単位：秒）

自系・他系に発生したスローダウンの情報を監視履歴として取得する場合に，aliveメッセージが途絶してから監視履歴を取得するまでの時間（系監視履歴取得時間）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。系監視履歴取得時間は，HAモニタの環境設定のpatrolオペランドで指定した系障害監視時間よりも小さい値になるように指定する必要があります。

このオペランドを省略した場合，系の監視履歴は取得しません。また，このオペランドを指定して系の監視履歴を取得する場合，必ずph_log_sizeオペランドも指定してください。

termcmd_at_abort～《nouse》

サーバの起動コマンドの失敗によるサーバの起動中止，およびサーバ障害時に系切り替えまたは連動系切り替えをする場合に，サーバの停止コマンドであと処理ができるようにするかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：サーバの停止コマンドによるあと処理をできるようにします。
サーバの起動コマンドの失敗によるサーバの起動中止の場合，およびサーバ障害時に系切り替えまたは連動系切り替えをする場合，サーバの停止コマンドを引数"-c"で実行します。
サーバの停止コマンドが引数"-c"で実行された場合にあと処理をするように，サーバの停止コマンドを作成してください。

nouse：サーバの停止コマンドによるあと処理はできません。
サーバの起動コマンドの失敗によるサーバの起動中止の場合，サーバの停止コマンドを実行しません。
サーバ障害時に系切り替えまたは連動系切り替えをする場合，サーバの停止コマンドを実行しますが，サーバの正常停止などと同様に引数"-w"または"-e"で実行します。

サーバの停止コマンドについては，「6.11.2　サーバの停止コマンドの作成」を参照してください。

alive_interval～<符号なし整数>((1～10))（単位：100ミリ秒）

aliveメッセージの送信間隔を，デフォルトから変更する場合に指定します。aliveメッセージの送信間隔は，デフォルトでは1,000ミリ秒です。系障害監視時間を短く設定する場合は，aliveメッセージの送信間隔の設定を変更することを推奨します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを省略した場合，aliveメッセージの送信間隔はデフォルト値が仮定されます。aliveメッセージの送信間隔がデフォルト値のままで問題ない場合は，オペランドに10を指定するのではなく，オペランドを省略することを推奨します。

なお，このオペランドを指定した場合，すべての監視パスにaliveメッセージを送信するため，優先して使用する監視パスを指定できません。

alive_multicast～《nouse》

aliveメッセージをマルチキャストで送受信するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：aliveメッセージをマルチキャストで送受信します。

nouse：aliveメッセージをマルチキャストで送受信しません（ユニキャストで送受信します）。

このオペランドを指定すると，すべての監視パスでaliveメッセージが同じ通信方式で送受信されます。このオペランドを省略した場合はnouseが仮定されますが，hostmaxオペランドで33以上を指定した場合だけはuseが仮定されます。

aliveメッセージをマルチキャストで送受信する場合，マルチキャストグループIDとして"239.0.0.1"を使用します。マルチキャストグループIDを任意に指定したい場合は，multicast_lanオペランドを指定してください。

multicast_lan～<1～32文字の英数字>

aliveメッセージをマルチキャストで送受信するときに使用する，マルチキャストグループIDに対応するホスト名を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドに指定するホスト名は，/etc/hostsファイルに設定したホスト名と同じ値を指定してください。/etc/hostsファイルに指定するIPアドレスは，クラスDのマルチキャストアドレスを指定します。

このオペランドを省略すると，/etc/hostsファイルのマルチキャストグループIDは"239.0.0.1"が仮定されます。また，aliveメッセージをマルチキャストで送受信しない場合，指定しても無視されます。

lanfailswitch～《nouse》

LANを監視して，障害時に自動的に系切り替えをするかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：LANを監視して，障害時に自動的に系切り替えをします。

nouse：LANを監視しません。

このオペランドを指定する場合は，サーバ対応の環境設定のswitchbyfailオペランドに，監視対象のLANインタフェース名称を必ず指定してください。なお，switchbyfailオペランドを指定したサーバがグループ化されている場合，指定したLANインタフェースに障害が発生すると，グループ化されているすべてのサーバの系切り替えをします。

lancheck_patrol～<符号なし整数>((1～180))《15》（単位：秒）

LANを監視する場合の，LANの監視間隔を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

lanfailswitchオペランドを指定しなかった場合，指定しても無視されます。

なお，このオペランドには，LAN監視スクリプトの実行時間よりも長い値を指定してください。LAN監視スクリプトについては，「6.10.3(2)　LAN監視スクリプトの設定」を参照してください。

なお，hbondingのステータスだけを監視する場合，監視間隔は1秒固定であるため，このオペランドを指定する必要はありません。

patrol_100ms～《nouse》

aliveメッセージの確認間隔を，デフォルトから変更する場合に指定します。aliveメッセージの確認間隔は，デフォルトでは1秒です。このオペランドを指定すると，100ミリ秒間隔で確認します。系障害監視時間を短く設定する場合は，100ミリ秒間隔でaliveメッセージを確認することを推奨します。系切り替え構成内のすべての系で同じ値を指定してください。

use：aliveメッセージを，100ミリ秒間隔で確認します。

nouse：aliveメッセージを，1秒間隔で確認します。

suppress_reset～<符号なし整数>((1～32))

系のリセットを抑止する場合に，リセットを抑止する基準となる最少稼働ホスト数を指定します。最少稼働ホスト数は，システムを構成する系の総数の半数よりも大きい値（最少稼働ホスト数>システム全体の系の数/2）で，かつhostmaxオペランドの指定値以下の値を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

系のリセットの抑止については，「3.2.4　系のリセットの抑止」を参照してください。

このオペランドを省略した場合は，系のリセットを抑止しません。

exitcode～《type1》

HAモニタのコマンドが返すリターンコードを指定します。

type1：「9.　コマンド」に記載されているリターンコードを返します。

type2：01-41以前のバージョンのリターンコードを返します。

vg_off～《parallel》

複数サーバを同時に停止するなど，ボリュームグループの切り離し処理が複数実行される場合に，切り離し処理をボリュームグループごとにシーケンシャルに実行するかパラレルに実行するかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

sequential：ボリュームグループの切り離し処理を，ボリュームグループごとにシーケンシャルに実行します。
複数のボリュームグループを同時に（パラレルに）切り離すと失敗するおそれがあるため，diskオペランドを指定しているサーバ対応の環境設定のserver定義文およびresource定義文が複数ある場合は，sequentialの指定を推奨します。

parallel：ボリュームグループの切り離し処理を，パラレルに実行します。

vmware_env～《nouse》

VMware ESXiによる仮想化環境で，系切り替えをするかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：VMware ESXiによる仮想化環境で系切り替えをします。

nouse：VMware ESXiによる仮想化環境で系切り替えをしません。

monsetup -resetpathコマンドによるリセットパスの設定で，VMware ESXiの仮想マシンを使用する設定を行った場合は，useが仮定されます。

patrol_type～《server》

系を監視するタイミングを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

server：系切り替えができる状態のときに系を監視します。

host：HAモニタの系間が接続している状態のときに系を監視します。

次の条件を満たす場合に，hostを指定してください。

suppress_resetオペランドを指定

系切り替え構成内のすべての系でサーバが監視し合っていない構成

これ以外の場合は，serverを指定するか，このオペランドを省略してください。このオペランドを省略した場合はserverが仮定されます。

resetpatrol_mode～《mode1》

マシンの機種がBladeSymphonyの場合，SVPが一時的にリセットパスのヘルスチェックに応答できないときにリセットパスの障害を検知しないようにするかどうかを指定します。BladeSymphonyの場合は，mode2を指定してください。HA8000の場合は，このオペランドを省略するかmode1を指定してください。このオペランドを省略した場合は，mode1が仮定されます。

このオペランドは，リセットパスのヘルスチェックに対してだけ有効です。

mode1：SVPが一時的にリセットパスのヘルスチェックに応答できない状態※を，リセットパスの障害として検知します。

mode2：SVPが一時的にリセットパスのヘルスチェックに応答できない状態※を，リセットパスの障害として検知しません。

注※

BladeSymphonyのSVPは，保守作業などでSVP交代を行う場合に，リセットパスのヘルスチェックに対して一時的に（最大2分間）応答できないことがあります。

8.4　サーバの環境設定

サーバの環境設定では，系で稼働させる実行サーバや待機サーバの環境を定義します。

また，排他サーバの環境設定もできます。排他サーバを定義すると，待機サーバが実行サーバとして稼働したときに，同じ系にあるほかの待機サーバを停止できます。この停止させるサーバを排他サーバといいます。この結果，同じ系で複数の実行サーバが稼働することを防げます。

＜この節の構成＞

8.4.1　サーバ対応の環境設定（servers）

8.4.2　排他サーバの環境設定（servers_opt）

8.4.1　サーバ対応の環境設定（servers）

サーバ対応の環境を設定する定義ファイルは，HAモニタの環境設定用ディレクトリの下にserversというファイル名で作成します。

また，HAモニタサンプルファイル用ディレクトリの下に，serversファイルのサンプルが用意されています。このファイルをHAモニタの環境設定用ディレクトリにコピーし，書き換えて使用すると，定義ファイルを最初から作成する手間が省けます。

なお，この定義ファイルは系ごとに作成します。太字部分は，系間で同じ値を指定してください。太字以外の部分は，系間で矛盾がないように設定してください。

サーバ対応の環境設定をする定義ファイルを，次に示します。

/*  サーバ対応の環境設定  */
server  name  
            プログラム名
      ,alias
            サーバの識別名
    〔,acttype
          ｛server｜monitor｝〕
    〔,server_type
          ｛A｜B｝〕
    〔,patrol
            サーバ障害監視時間〕
    〔,termcommand
            サーバの停止コマンドの絶対パス名〕
    〔,initial
          ｛online｜standby｝〕
    〔,pairdown
          ｛use〔:serv_slow〕｜nouse｝〕
    〔,group
            グループ名〔:｛exchange｜no_exchange〔: ｛cancel｜no_cancel｝〕｝〕〕
    〔,switchtype
          ｛switch｜restart〔:再起動監視時間〕｜manual｝〕
    〔,disk
            ボリュームグループの絶対パス名〔:ボリュームグループの絶対パス名…〕〕
    〔,lan_updown
          ｛use｜nouse｝〕
    〔,fs_name
            論理ボリュームの絶対パス名〔:論理ボリュームの絶対パス名…〕〕
    〔,fs_mount_dir
            ディレクトリ名〔:ディレクトリ名…〕〕
    〔,fs_mount_opt
            オプション〔:オプション…〕〕
    〔,fs_umount_retry
          ｛リトライ回数｜10｝〕
    〔,patrolcommand
            サーバの監視コマンドの絶対パス名〕
    〔,servexec_retry
          ｛サーバ起動処理の再試行回数｜2｝〕
    〔,waitserv_exec
          ｛yes｜no｝〕
    〔,retry_stable
          ｛起動完了監視時間｜60｝〕
    〔,parent
            親サーバの識別名称〕
    〔,dev_timelimit
            共有リソース切り替えタイムアウト値〕
    〔,vg_on_opt
            ボリュームグループの接続オプション〔:オプション…〕〕
    〔,ip_neck
          ｛use｜nouse｝〕
    〔,uoc_neck
          ｛use｜nouse｝〕
    〔,vg_neck
          ｛use｜nouse｝〔: ｛use｜nouse｝…〕〕
    〔,fs_neck
          ｛use｜nouse｝〔: ｛use｜nouse｝…〕〕
    〔,actcommand
            サーバの起動コマンドの絶対パス名〕
    〔,standbypri
          ｛各待機サーバの優先度｜1｝〕
    〔,deviceoff_order
          ｛order｜reverse｝〕
    〔,ph_threshold
            サーバ監視履歴取得時間〕
    〔,hab_gid
            制御グループID〔:制御グループID…〕〕
    〔,hab_discnt_atend
          ｛yes｜no｝〕
    〔,switchbyfail
            LANインタフェース名称〔:LANインタフェース名称…〕〕
    〔,program
          ｛use｜nouse｝〕
    〔,start_timeout
          ｛サーバ起動時のタイムアウト値｝〕
    〔,stop_timeout
          ｛サーバ停止時のタイムアウト値｝〕;
/*  リソースサーバ対応の環境設定  */
〔resource    alias
                リソースサーバの識別名
            ,group
                グループ名
          〔,initial
              ｛online｜standby｝〕
          〔,disk
                ボリュームグループの絶対パス名〔:ボリュームグループの絶対パス名…〕〕
          〔,lan_updown
              ｛use｜nouse｝〕
          〔,fs_name
                論理ボリュームの絶対パス名〔:論理ボリュームの絶対パス名…〕〕
          〔,fs_mount_dir
                ディレクトリ名〔:ディレクトリ名…〕〕
          〔,fs_mount_opt
                オプション〔:オプション…〕〕
          〔,fs_umount_retry
              ｛リトライ回数｜10｝〕
          〔,dev_timelimit
                共有リソース切り替えタイムアウト値〕
          〔,vg_on_opt
                ボリュームグループの接続オプション〔:オプション…〕〕
          〔,ip_neck
              ｛use｜nouse｝〕
          〔,uoc_neck
              ｛use｜nouse｝〕
          〔,vg_neck
              ｛use｜nouse｝〔: ｛use｜nouse｝…〕〕
          〔,fs_neck
              ｛use｜nouse｝〔: ｛use｜nouse｝…〕〕
          〔,standbypri
              ｛各待機サーバの優先度｜1｝〕
          〔,deviceoff_order
              ｛order｜reverse｝〕
          〔,hab_gid
                制御グループID〔:制御グループID…〕〕
          〔,hab_discnt_atend
              ｛yes｜no｝〕
          〔,switchbyfail
                LANインタフェース名称〔:LANインタフェース名称…〕〕；〕

＜この項の構成＞

(1)　サーバの種類と定義するオペランド一覧

(2)　server定義文

(3)　resource定義文

(1)　サーバの種類と定義するオペランド一覧

サーバ対応の環境設定では，次の場合でそれぞれ定義するオペランドが異なります。

サーバがサーバモードの場合

サーバがモニタモードの場合

リソースサーバの場合

サーバの種類によるオペランドの組み合わせを次の表に示します。

表8-4　サーバの種類によるオペランドの組み合わせ

オペランド | サーバモードの場合 | モニタモードの場合 | リソースサーバの場合
TP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）のとき | TP1/EEまたはHiRDB（XDS）のとき
name | ◎ | ◎ | －
alias | ◎ | ◎ | ◎
acttype | ○ | ◎ | －
server_type | ○ | ◎ | － | －
patrol | ◎ | － | － | －
termcommand | － | △ | －
initial | ○ | ○ | ○
pairdown | ○ | － | －
group | △ | △ | ◎
switchtype | ○ | － | －
disk | △ | △ | △
lan_updown | ○ | ○ | ○
fs_name | △ | △ | △
fs_mount_dir | △ | △ | △
fs_mount_opt | △ | △ | △
fs_umount_retry | ○ | ○ | ○
patrolcommand | － | △ | －
servexec_retry | － | ○ | －
waitserv_exec | － | ○ | －
retry_stable | － | ○ | －
parent | △ | △ | －
dev_timelimit | △ | △ | △
vg_on_opt | ○ | ○ | ○
ip_neck | ○ | ○ | ○
uoc_neck | ○ | ○ | ○
vg_neck | ○ | ○ | ○
fs_neck | ○ | ○ | ○
actcommand | － | △ | －
standbypri | ○ | ○ | ○
deviceoff_order | ○ | ○ | ○
ph_threshold | △ | － | － | －
hab_gid | △ | △ | △
hab_discnt_atend | ○ | ○ | ○
switchbyfail | △ | △ | △
program | － | ○ | －
start_timeout | － | ○ | －
stop_timeout | － | ○ | －

（凡例）

◎：定義します（省略できません）。

○：定義します（省略した場合，仮定値が設定されます）。

△：定義します（省略した場合，設定されません）。

－：定義しません（定義しても無視されます）。

(2)　server定義文

サーバの動作環境を定義します。server定義文のオペランドを，次に示します。

name～<1～1000文字のサーバパス名>

プログラムを特定するための名称を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

サーバモードのサーバの場合

TP1/Server Baseを使用するとき
OpenTP1ディレクトリの絶対パス名を指定してください。OpenTP1ディレクトリについては，マニュアル「分散トランザクション処理機能 OpenTP1 運用と操作」を参照してください。

TP1/EEを使用するとき
TP1/EEのクラスタ識別子を指定してください。TP1/EEのクラスタ識別子については，マニュアル「分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引」を参照してください。

HiRDBを使用するとき
使用するHiRDBの系切り替え機能によって指定する内容が異なります。指定する値の詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。

モニタモードのサーバの場合

サーバの起動コマンドの絶対パス名を指定します。

alias～<1～8文字の英数字>

HAモニタで使用するコマンドや，出力するメッセージのための，サーバの識別名（サーバの別名）を指定します。すべての系の中で一意となる名称を指定してください。また，系切り替え構成内のすべての系で同じ値を指定してください。

acttype～《server》

サーバの起動方法を指定します。サーバモードのサーバの場合はserverを，モニタモードのサーバの場合はmonitorを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

server：サーバの起動コマンドでサーバを起動します。

monitor：HAモニタのコマンドでサーバを起動します。

server_type～《A》

サーバモードのサーバの場合に，サーバの監視方法を指定します。系切り替え構成内のすべての系で同じ値を指定してください。モニタモードのサーバの場合は，指定しても無視されます。

A：稼働報告を監視します。サーバがTP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）の場合に指定してください。

B：サーバのプロセスを監視します。サーバがTP1/EEまたはHiRDB（XDS）の場合に指定してください。

HiRDB（XDS）を使用する場合，指定する値の詳細については，マニュアル「HiRDB システム運用ガイド」を参照してください。

patrol～<符号なし整数>((5～600))（単位：秒）

サーバモードのサーバの場合に，サーバ障害の判断基準となる，サーバからの稼働報告を確認する時間（サーバ障害監視時間）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。patrolオペランドに指定した時間を超えてもサーバからの稼働報告がなかった場合，HAモニタはサーバ障害と判断します。

サーバモードのサーバとしてTP1/EEまたはHiRDB（XDS）を使用する場合，またはモニタモードのサーバを使用する場合は，指定しても無視されます。

termcommand～<1～1000文字のパス名>

シェルなどで作成したサーバの停止コマンドを絶対パス名で指定します。系切り替え構成内のすべての系で同じ値を指定してください。

モニタモードのサーバの場合にこのオペランドを指定しておくと，計画系切り替えをしたいときに計画系切り替えコマンド（monswapコマンド）を実行するだけで，自動的に実行サーバを計画停止できます。また，実行サーバを正常終了させたいときにモニタモードのサーバ停止コマンド（monendコマンド）を実行するだけで，自動的に実行サーバを正常終了できます。

サーバモードのサーバの場合は，指定しても無視されます。

なお，"（引用符）で囲んで指定することで，空白を使用できます。空白を使用することで，コマンドに引数を指定できます。"（引用符）は文字数にカウントされません。空白を含む指定をした場合，一つ以上の空白で区切られた最初の文字列が，サーバの停止コマンドのパス名として認識されます。最初の空白より後ろの文字列は引数として認識されます。HAモニタが渡す引数（"-e"，"-w"，"-c"）は，サーバの停止コマンドの，最後の引数として追加して実行されます。HAモニタが渡す引数については，「6.11.2　サーバの停止コマンドの作成」を参照してください。

initial～《online》

サーバの起動種別として，サーバ起動時の状態を指定します。現用系ではonlineを，予備系ではstandbyを指定してください。

online：サーバを実行サーバとして起動します。

standby：サーバを待機サーバとして起動します。

pairdown～《nouse》

サーバ障害を検出したときにHAモニタも障害として停止する，ペアダウン機能を使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。モニタモードのサーバの場合は，指定しても無視されます。

use：ペアダウン機能を使用します。実行サーバの障害時にペアダウンをします。サーバにTP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）を使用する場合，useのあとに次の値を指定できます。":"で区切って指定してください。
serv_slow
実行サーバの障害のうち，サーバのスローダウン検出時だけペアダウンをします。サーバ自身が検出した障害の場合はペアダウンをしないで，switchtypeオペランドの定義に従って動作します。

nouse：ペアダウン機能を使用しません。

group～<1～8文字の英数字>

連動系切り替え時に一括して切り替えるサーバグループの名称と，各サーバの切り替え種別を指定します。系切り替え構成内のすべての系で同じ値を指定してください。groupオペランドを指定する場合，グループ化されたサーバのinitialオペランド値は，系内で同じ値にしてください。

サーバグループの名称には，"exchange"，"no_exchange"，"cancel"，"no_cancel"以外の名称を指定してください。

サーバの切り替え種別には，そのサーバにサーバ障害が発生した場合に連動系切り替えをするかどうかを指定します。サーバの切り替え種別は，サーバモードのサーバの場合だけ指定できます。モニタモードの場合は指定できません。モニタモードのサーバにサーバ障害が発生した場合，サーバの監視コマンドを作成しているときは連動系切り替えをします。サーバの監視コマンドを作成していないときは連動系切り替えをしません。

サーバの切り替え種別の指定は任意です。指定する場合は，グループ名もあわせて指定してください。グループ名の指定を省略すると，各サーバの切り替え種別の指定は無視されます。サーバの切り替え種別として指定できる値を次に示します。

exchange：この値を指定したサーバにサーバ障害が発生すると，サーバグループ内のすべてのサーバを一括して，連動系切り替えをします。この値と，"cancel"または"no_cancel"は，同時に指定できません。

no_exchange：この値を指定したサーバにサーバ障害が発生しても，連動系切り替えはしません。対応する待機サーバは連動系切り替え待ち状態になります。ただし，サーバグループ内のすべてのサーバにno_exchangeを指定していても，すべてのサーバでサーバ障害が発生すると，連動系切り替えをします。
なお，サーバの切り替え順序制御を使用している場合，親サーバには，no_exchangeを指定できません。
サーバにTP1/Server BaseまたはHiRDB（プライマリ機能提供サーバ）を使用する場合，no_exchangeのあとに次の値を指定できます。":"で区切って指定してください。
cancel
この値を指定したサーバのスローダウンを検出すると，HAモニタはこのサーバを異常終了させます。対応する待機サーバは連動系切り替え待ち状態になります。
no_cancel
この値を指定したサーバのスローダウンを検出しても，HAモニタはこのサーバの状態監視を続けます。対応する待機サーバは連動系切り替え待ち状態にはなりません。
サーバグループ内のすべてのサーバで"no_exchange:no_cancel"を指定すると，すべてのサーバのスローダウンを検出しても，系切り替えをしないでサーバの状態監視を続けます。

switchtype～《switch》

サーバモードのサーバのサーバ障害を検出した場合の動作を指定します。系切り替え構成内のすべての系で同じ値を指定してください。モニタモードのサーバの場合は，指定しても無視されます。

switch：実行サーバを停止させ，系切り替えをします。

restart：実行サーバを実行サーバの再起動待ち状態にし，実行サーバが自動で再起動するのを待ちます。系切り替えはしません。実行サーバの再起動が失敗した場合は，サーバ自身のリトライ回数だけ再起動をリトライします。リトライ回数が限界に達すると，系切り替えを開始します。
restartを指定した場合は，":"で区切って実行サーバの再起動監視時間を指定できます。再起動監視時間を超えて実行サーバが再起動しない場合は，系切り替えを開始します。再起動監視時間は60秒から3,600秒の範囲で指定できます。再起動監視時間の指定を省略した場合は，実行サーバの再起動は監視しません。

manual：実行サーバを実行サーバの再起動待ち状態にし，実行サーバが自動で再起動するのを待ちます。系切り替えはしません。実行サーバの再起動が失敗した場合は，サーバ自身のリトライ回数だけ再起動をリトライします。リトライ回数が限界に達すると，実行サーバを停止させ，対応する待機サーバをいったん停止させたあとに再起動して実行サーバの起動待ち状態にします。
なお，manualを指定したサーバのスローダウンを検出した場合，HAモニタは何もしないでサーバの監視を続けます。

disk～<1～256文字のパス名>

共有ディスクを使用する場合に，切り替える共有ディスク上に定義したボリュームグループの絶対パス名を指定します。3,000個まで指定できます。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを省略した場合は，HAモニタは共有ディスクの切り替えをしません。

lan_updown

LANの状態設定ファイルを使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：LANの状態設定ファイル（サーバ識別名.upファイルおよびサーバ識別名.downファイル）を使用します。

nouse：LANの状態設定ファイルを使用しません。

lan_updownオペランドの指定を省略した場合は，HAモニタの環境設定用ディレクトリの下にサーバ識別名.upファイルおよびサーバ識別名.downファイルがあれば，そのファイルをLANの状態設定ファイルとして使用します。

fs_name～<1～256文字のパス名>

共有ディスク上のファイルシステムを使用する場合に，切り替えるファイルシステムに対応する論理ボリュームの絶対パス名を指定します。3,000個まで指定できます。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを省略した場合は，HAモニタは共有ディスク上のファイルシステムの切り替えをしません。

fs_nameオペランドを指定した場合には，必ずfs_mount_dirオペランドを指定してください。

fs_mount_dir～<1～256文字のパス名>

共有ディスク上のファイルシステムを使用する場合に，切り替えるファイルシステムのマウント先ディレクトリの絶対パス名を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドは，fs_nameオペランドを指定した場合は省略できません。

fs_mount_dirオペランドでは，fs_nameオペランドで指定した論理ボリュームに対応するマウント先ディレクトリを，同じ位置の引数に指定します。また，マウント先ディレクトリの指定数はfs_nameオペランドと同じにしてください。fs_nameおよびfs_mount_dirオペランドの指定方法の例を，次の例に示します。

　　　fs_name　　/dev/vg01/lvol1:/dev/vg02/lvol1,
　　　　　　　　　　　　↓　　　　　　↓
　　　fs_mount_dir　/home1　　　:/home2,

例の場合，fs_nameオペランドの"/dev/vg01/lvol1"はfs_mount_dirオペランドの"/home1"に，fs_nameオペランドの"/dev/vg02/lvol1"はfs_mount_dirオペランドの"/home2"に対応します。

なお，このオペランドに指定するファイルシステムについてはシステム起動時に自動的にマウントする設定をしないでください。

fs_mount_opt～<1～256文字の文字列>

共有ディスク上のファイルシステムを使用する場合に，切り替えるファイルシステムに対するmountコマンド実行時のオプションを指定します。系切り替え構成内のすべての系で同じ値を指定してください。オプション中に空白，コンマ，コロン，セミコロン，スラント，またはアスタリスクが含まれる場合は，それぞれを"（引用符）で囲んで指定します。

fs_mount_optオペランドでは，fs_nameオペランドおよびfs_mount_dirオペランドで指定したファイルシステムに対応するオプションを，同じ位置の引数に指定します。オプションの指定数はfs_nameオペランドおよびfs_mount_dirオペランドと同じにしてください。途中のオプションを省略する場合は値を指定しないでコロンで区切って指定します。fs_name，fs_mount_dir，およびfs_mount_optオペランドの指定方法の例を，次の例に示します。

　　　fs_name　　　/dev/vg01/lvol1:/dev/vg02/lvol1,
　　　　　　　　　　　　↓　　　　　　　↓
　　　fs_mount_dir　/home1　　　　:/home2,
　　　　　　　　　　　　↓　　　　　　　↓
　　　fs_mount_opt　"-o rw"　　　　:,

例の場合，fs_nameオペランドの"/dev/vg01/lvol1"とfs_mount_dirオペランドの"/home1"はfs_mount_optオペランドの"-o rw"に対応し，fs_nameオペランドの"/dev/vg02/lvol1"とfs_mount_dirオペランドの"/home2"はfs_mount_optオペランドを省略しています。

fs_mount_optオペランドの指定を省略した場合，すべてのファイルシステムに対するmountコマンド実行時オプションを省略します。

fs_umount_retry～<符号なし整数>((0～9999))《10》（単位：回）

ファイルシステムの切り離し時，アンマウントに失敗した場合のリトライ回数を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

0を指定した場合はリトライしません。9999を指定した場合はアンマウントが成功するまで無制限にリトライします。なお，リトライの間隔は1秒です。

patrolcommand～<1～1000文字のパス名>

モニタモードのサーバを監視するためのサーバの監視コマンドを絶対パス名で指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを省略した場合は，実行サーバの監視はしません。なお，サーバモードのサーバでは，指定しても無視されます。

なお，termcommandオペランドと同様に，オペランドの指定値を"（引用符）で囲むことで，引数を指定できます。

servexec_retry～<符号なし整数>((0～9999))《2》（単位：回）

モニタモードの実行サーバのサーバ障害を検出した場合にサーバの起動処理を再実行させる回数を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

HAモニタが実行サーバのサーバ障害を検出した場合，指定した回数分だけnameオペランドに指定したサーバの起動コマンドの再実行を試みます。指定回数内でサーバの起動処理が完了した場合は，そのまま正常動作として処理が続行されます。指定回数内にサーバの起動処理が完了しない場合は，HAモニタはサーバ障害と判断し，自動計画系切り替えを実行します。

このオペランドを省略した場合は，値として2を仮定します。このオペランドに0を指定した場合は，サーバの再起動はしないで，サーバの監視コマンドの終了を検出すると即時に自動計画系切り替えを実行します。

このオペランドに9999を指定した場合は，サーバの起動処理が完了するまで，または実行サーバを停止させるまで無制限にサーバを再起動します。この場合，サーバ対応の環境設定のnameオペランドに指定したパスが見つからない，実行権限が付けられていないなどの理由から，再起動してもサーバの起動に成功しないことがあります。そのため，環境設定の定義およびサーバの起動コマンドが正しいかを確認してください。

なお，サーバモードのサーバの場合，またはpatrolcommandオペランドが指定されていない場合，指定しても無視されます。

waitserv_exec～《no》

モニタモードのサーバを実行サーバとして起動する場合，HAモニタが実行サーバの起動完了処理をする前にnameオペランドに指定したサーバの起動コマンドの実行完了を待つかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

yes：サーバの起動コマンドの実行完了を待って，実行サーバの起動完了処理をします。

no：サーバの起動コマンドの実行完了を待たないで，実行サーバの起動完了処理をします。

モニタモードのサーバを監視する場合は，「6.11.1(2)　サーバの起動コマンドの作成方法」の説明に従ってこのオペランドの値を決定してください。

このオペランドを省略した場合はnoを仮定します。なお，サーバモードのサーバの場合，指定しても無視されます。

retry_stable～<符号なし整数>((60～3600))《60》（単位：秒）

モニタモードでのサーバの再起動に成功した場合，そのサーバの動作が安定したと判断するための監視時間を秒数で指定します。系切り替え構成内のすべての系で同じ値を指定してください。

サーバが再起動したあと，このオペランドに指定した時間内に障害が検出されなかった場合，HAモニタはサーバが安定して稼働したと判断し，再起動回数を0にリセットします。再起動成功後，再び0秒から安定稼働のために経過が監視されます。

サーバが再起動したあと，このオペランドに指定した時間が経過する前に再度障害が発生すると，再起動回数が更新され，サーバが再起動されます。更新された再起動回数がサーバ対応の環境設定のservexec_retryオペランドに指定した値を超えた場合は，サーバの再起動はされないで，系切り替え動作をします。

parent～<1～8文字の英数字>

サーバの切り替え順序制御をする場合，自サーバ起動のために必要な，親サーバを指定します。系切り替え構成内のすべての系で同じ値を指定してください。指定する値は親サーバのサーバ識別名（alias）に指定した名称を記述します。このオペランドを指定した場合，系切り替え時に，親サーバの起動が完了するまで，自サーバを起動しないように順序制御をします。このオペランドはgroupオペランドが指定されている場合だけ指定できます。

なお，正しく順序制御ができなくなるため，サーバグループ内のサーバが稼働中に，このオペランドを変更しないでください。

dev_timelimit～<符号なし整数>((60～3600))（単位：秒）

系切り替え時のサーバの共有リソース接続・切り離し処理に対するタイムアウト値を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

タイムアウトした場合は，共有リソースに関する処理を処理失敗として中断し，サーバの起動・停止処理を続行します。省略時はタイマ監視をしないで，接続・切り離しが完了するまで，サーバの起動・停止を待ちます。

vg_on_opt～<1～256文字の文字列>

切り替えるボリュームグループに対する接続時のvgchangeコマンド実行時のオプションを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

省略時は，"-a△y"オプションを仮定します。

オプション中に△（空白）が含まれる場合は"（引用符）で囲んで指定してください。

vg_on_optオペランドは，diskオペランドで指定したボリュームグループに対応するオプションを同じ位置の引数に指定します。よって，オプションの指定数はdiskオペランドと同じにしてください。途中のオプションを省略する場合は値を指定しないでコロンで区切って指定します。

vgchangeコマンド実行時のオプションを指定する例を，次に示します。

   disk               /dev/vg01      :/dev/vg02  ,
                      ↓             ↓
   vg_on_opt          "-a△y△-q△n" :  ,

例の場合，diskオペランドの"/dev/vg01"については，vgchangeコマンドのオプションに"-a △y△-q△n"を使用して実行され， "/dev/vg02"については，vgchangeコマンドのオプションにデフォルト値である"-a△y"を使用して実行されます。

vg_on_optオペランドの指定を省略した場合，すべてのボリュームグループに対するオプションにデフォルト値が仮定されます。

ip_neck～《nouse》

サーバの起動，および系切り替え時に実行するサーバ識別名.upファイルについて，その終了コードを確認するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：サーバ識別名.upファイルの終了コードが0以外の場合に，サーバの起動を中止します。この指定の場合，「3.3.3　共有リソース接続失敗時のサーバの起動中止」に記載されている，サーバ識別名.upファイルの例を参考に，LANの状態設定ファイルを設定してください。

nouse：サーバ識別名.upファイルの終了コードを確認しないで，サーバの起動処理を続行します。この指定の場合，「6.10.2　LANの状態設定ファイルの設定」に記載されている，サーバ識別名.upファイルの例を参考に，LANの状態設定ファイルを設定してください。

uoc_neck～《nouse》

サーバの起動開始，および系切り替え開始時に実行するユーザコマンドについて，その終了コードを確認するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：ユーザコマンドの終了コードが0以外の場合に，サーバの起動を中止します。

nouse：ユーザコマンドの終了コードを確認しないで，サーバの起動処理を続行します。

なお，サーバの起動開始，および系切り替え開始時以外に実行されるユーザコマンドについては，終了コードを確認しません。

vg_neck～《nouse》

サーバの起動，および系切り替え時のボリュームグループの接続に失敗した場合に，サーバ起動を中止するかどうかを，ボリュームグループごとに指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：接続に失敗した場合に，サーバの起動を中止します。

nouse：接続に失敗しても，サーバの起動処理を続行します。

vg_neckオペランドは，vg_on_optオペランドのように，diskオペランドで指定したボリュームグループに対応するオプションを同じ位置の引数に指定してください。よって，オプションの指定数はdiskオペランドと同じにしてください。途中のオプションを省略する場合は，値を指定しないで":"（コロン）で区切り"vg_neck use::nouse,"のように定義してください。このオペランドを省略した場合，すべてのボリュームグループに対してnouseを仮定します。

fs_neck～《nouse》

サーバの起動，および系切り替え時のファイルシステムの接続に失敗した場合に，サーバ起動を中止するかどうかを，ファイルシステムごとに指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：接続に失敗した場合に，サーバの起動を中止します。

nouse：接続に失敗しても，サーバの起動処理を続行します。

fs_neckオペランドは，fs_mount_optオペランドと同様に，fs_nameオペランドで指定したファイルシステムに対応するオプションを同じ位置の引数に指定してください。よって，オプションの指定数はfs_nameオペランドと同じにしてください。途中のオプションを省略する場合は値を指定しないで":"（コロン）で区切り"fs_neck use::nouse,"のように定義してください。fs_neckオペランドを省略した場合，すべてのファイルシステムに対してnouseを仮定します。

actcommand～<1～1000文字のパス名>

サーバの起動コマンドの絶対パス名を指定します。termcommandオペランドと同様に，オペランドの指定値を"（引用符）で囲むことで，引数を指定できます。"（引用符）は文字数にカウントされません。系切り替え構成内のすべての系で同じ値を指定してください。

モニタモードのサーバで，サーバの起動コマンドに引数を指定したい場合に，このオペランドを指定します。このオペランドを指定した場合，nameオペランドにはサーバの起動コマンドの絶対パス名を指定する必要はありません。nameオペランドにはプログラムを特定するための一意となる名称を指定してください。

サーバモードのサーバの場合は，指定しても無視されます。

standbypri～<符号なし整数>((1～9999))《1》

マルチスタンバイ機能を使用する場合に，各待機サーバの優先度を指定します。数値が小さいほど，その系の優先度が高いことを示します。各系で異なる値を指定してください。このオペランドは，HAモニタの環境設定のmultistandbyオペランドにuseを指定し，サーバ対応の環境設定のinitialオペランドにstandbyを指定した場合にだけ有効です。initialオペランドにonlineを指定した場合は，優先度がいちばん高くなります。マルチスタンバイ機能の詳細については，「4.5　マルチスタンバイ機能を使用する場合のサーバと系の管理」を参照してください。

deviceoff_order～《order》

共有リソースの切り離しをする順序を指定します。系切り替え構成内のすべての系で同じ値を指定してください。このオペランドはHAモニタの環境設定のdeviceoff_orderオペランドとは異なり，指定されたサーバにだけ適用されます。

HAモニタの環境設定のdeviceoff_orderオペランドを指定した場合は，このオペランドの指定は無視され，HAモニタの環境設定の定義に従います。サーバごとに共有リソースの切り離しをする順序を変更したい場合は，HAモニタの環境設定にはdeviceoff_orderオペランドを定義しないで，このオペランドで指定してください。

共有リソースの切り離しをする順序の詳細については，「4.8.7　共有リソースの切り離しを接続時と逆順にする場合の処理の流れ」を参照してください。

order：接続時と同じ順番で共有リソースの切り離しをします。

reverse：接続時と逆の順番で共有リソースの切り離しをします。

ph_threshold～<符号なし整数>((5～559))（単位：秒）

自系で稼働する実行サーバに発生したスローダウンの情報を監視履歴として取得する場合に，実行サーバの稼働報告がなくなってから監視履歴を取得するまでの時間（サーバ監視履歴取得時間）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

サーバ監視履歴取得時間は，サーバ対応の環境設定のpatrolオペランドで指定したサーバ障害監視時間よりも小さい値になるように指定する必要があります。

このオペランドを省略した場合，サーバの監視履歴は取得しません。また，サーバモードのサーバとしてTP1/EEまたはHiRDB（XDS）を使用する場合，またはモニタモードのサーバを使用する場合は，指定しても無視されます。

このオペランドを指定してサーバの監視履歴を取得する場合，必ずHAモニタの環境設定のph_log_sizeオペランドも指定してください。

hab_gid～<制御グループID>((0～1023))

HA Boosterを使用して共有ディスクの切り替えをする場合に，HA Boosterに定義した制御グループIDを指定します。制御グループIDとして指定できる値は，0～1023です。系切り替え構成内のすべての系で同じ値を指定してください。制御グループIDは，最大で20個指定できます。

hab_discnt_atend～《no》

実行サーバの終了時に，制御グループを切り離すか，接続したままにするかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

yes：切り離します。

no：接続したままにします。

このオペランドを省略した場合はnoを仮定します。

switchbyfail～<1～32文字の英数字>

監視するLANインタフェース名称を指定します。このオペランドに指定したLANインタフェースのどれか一つに障害が発生した場合，実行サーバを系切り替えします。監視対象のLANインタフェースにエイリアスIPアドレスが付与されている場合，エイリアスIPアドレスのインデックス番号を含めないインタフェース名称を指定してください。

LANインタフェース名称は，コロンで区切って最大32個指定できます。このオペランドを指定する場合は，それぞれのLANインタフェースに対応したLAN監視定義ファイルを作成してください。また，このオペランドを指定したサーバがグループ化されている場合，指定したLANインタフェースに障害が発生すると，グループ化されているすべてのサーバを切り替えます。

LAN監視定義ファイルについては，「6.10.3　LANの監視設定ファイルの設定」を参照してください。

program～《nouse》

モニタモードのプログラム管理機能を使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：モニタモードのプログラム管理機能を使用します。

nouse：モニタモードのプログラム管理機能を使用しません。

このオペランドにuseを指定した場合，次の定義もしてください。

HAモニタの環境設定のpgmmaxオペランド

モニタモードのプログラム対応の環境設定

モニタモードのプログラム対応の環境設定については，「8.5.1　モニタモードのプログラム対応の環境設定（programs）」を参照してください。

なお，サーバモードのサーバの場合は，指定しても無視されます。

start_timeout～<60～3600>（単位：秒）

モニタモードのサーバ起動時のタイムアウト値を指定します。系切り替え構成内のすべての系で同じ値を指定してください。このオペランドを指定すると，切り替え先のサーバの起動も，タイムアウトの監視対象となります。なお，servexec_retryオペランドの指定によってサーバの起動処理を再実行した場合は，タイムアウトの監視対象ではありません。

このオペランドを省略した場合は，モニタモードのサーバ起動時のタイムアウトを監視しません。

タイムアウトした場合は，サーバの起動コマンドを強制停止し，サーバの起動を中止します。タイムアウトしたあと，サーバの停止コマンドを起動したい場合は，HAモニタの環境設定のtermcmd_at_abortオペランドにuseを指定してください。

waitserv_execオペランドにyesを指定した場合，タイムアウト値には，サーバの起動コマンドの起動から終了までの時間を指定します。programオペランドにuseを指定した場合は，タイムアウト値に，hamon_patrolstart関数の発行までの時間を含めてください。hamon_patrolstart関数が1回発行されるまでの時間を監視します。UAPが複数プロセスで構成されている場合でも，hamon_patrolstart関数が1回発行されるまでの時間を監視します。

サーバモードのサーバの場合，またはwaitserv_execオペランドにnoを指定し，かつprogramオペランドにnouseを指定した場合は，指定しても無視されます。

waitserv_execオペランドとprogramオペランドの指定値と指定する監視範囲の対応を，次の表に示します。

表8-5　waitserv_execオペランドとprogramオペランドの指定値と指定する監視範囲の対応

オペランドの指定値 | 指定する監視範囲
waitserv_exec | program
yes | use | サーバの起動コマンドの起動から終了まで，およびhamon_patrolstart関数の発行までの両方を監視する。
nouse | サーバの起動コマンドの起動から終了までを監視する。
no | use | hamon_patrolstart関数が発行されるまでを監視する。
nouse | タイムアウトを監視しない（指定しても無視する）。

stop_timeout～<60～3600>（単位：秒）

モニタモードのサーバ停止時のタイムアウト値を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドを省略した場合は，モニタモードのサーバ停止時のタイムアウトを監視しません。なお，servexec_retryオペランドの指定によってサーバの起動処理を再実行した場合は，タイムアウトの監視対象ではありません。

タイムアウト値には，サーバの停止コマンドの起動から終了までの時間を指定します。programオペランドにuseを指定した場合は，タイムアウト値に，hamon_patrolstop関数の発行までの時間を含めてください。hamon_patrolstart関数を発行したすべてのプログラムから，hamon_patrolstop関数の発行までの時間を監視します。

タイムアウトした場合は，サーバの停止コマンドを強制停止します。UAPのプロセスが存在する場合は，あわせて停止します。

なお，サーバモードのサーバの場合は，指定しても無視されます。

(3)　resource定義文

リソースサーバを定義します。resource定義文のオペランドを，次に示します。リソースサーバについては，「4.6　リソースサーバの管理」を参照してください。

各オペランドはサーバ対応の環境設定であるserver定義文と同様であるため，それらの説明については，server定義文の同一オペランドの説明を参照してください。ここでは，server定義文と違いのあるオペランドについて説明します。

alias～<1～8文字の英数字>

HAモニタで使用するコマンドや，出力するメッセージのための，リソースサーバの識別名（サーバの別名）を指定します。server定義文のaliasオペランドと同様です。

group～<1～8文字の英数字>

連動系切り替え時に一括して切り替えるサーバグループの名称を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

リソースサーバの場合，このオペランドは必須です。exchange，no_exchange，cancel，no_cancelを指定しても内容は無視されます。その他の事項については，server定義文のgroupオペランドと同様です。

なお，一つのグループに複数のリソースサーバは定義できません。

8.4.2　排他サーバの環境設定（servers_opt）

ここでは，排他サーバの環境設定ファイルの記述形式，および定義方法について説明します。

＜この項の構成＞

(1)　定義の記述形式

(2)　定義方法

(1)　定義の記述形式

定義の記述形式を，次に示します。

△₀exclusive_servers△₀：△₀サーバ識別名△₀：△₀サーバ識別名△₀↓

（凡例）

△₀：0個以上の空白またはタブを示します。

↓：改行コードを示します。

注意

行の先頭に"#"を記述すると，"#"以降，改行コードまでがコメント行になります。

各オペランドを1行に記述します。1行の文字数は2,048文字までです。

定義のチェックは，HAモニタ起動時，サーバ起動時，および定義チェックコマンド（moncheckコマンド）実行時にします。定義不正があった場合は，起動を終了します。

一つのexclusive_serversオペランドで指定した複数のサーバが同一グループとなるように定義しても定義不正とはしません。

この定義ファイルがない，またはファイルがあってもファイルの内容がコメントだけで有効な情報がない場合でも定義不正とはしません。

(2)　定義方法

排他サーバの環境を設定する定義ファイルは，HAモニタの環境設定用ディレクトリの下にservers_optというファイル名で作成します。

排他サーバの環境設定ファイルは，待機サーバだけがある系に作成することをお勧めします。

排他サーバの環境設定をする定義ファイルを，次に示します。

# 排他サーバの環境設定 : server alias : server alias
 exclusive_servers    :サーバ識別名  :サーバ識別名〔:サーバ識別名…〕

排他サーバを定義するオペランドを，次に示します。

exclusive_servers

排他をしたいすべてのサーバを，サーバ対応の環境設定のaliasオペランドに指定したサーバ識別名で指定します。指定したサーバ識別名の一つのサーバが実行サーバになると，指定されているサーバのうち，次の条件を満たしているサーバが停止します。

サーバの状態が，待機サーバとして起動中，待機中，実行サーバの再起動待ち中，実行サーバ起動待ち中，系切り替え待ち中，または連動系切り替え待ち中です。

サーバ対応の環境設定のgroupオペランドに，実行サーバになるサーバと同一グループ名で定義されていないサーバです。

指定できるサーバ識別名の数には，一つの系で稼働するサーバの最大数によって異なります。一つの系で稼働するサーバの最大数別に，指定できるサーバ識別名の数を次に示します。なお，指定できるサーバ識別名の数には，リソースサーバも含みます。

サーバの最大数が16のとき：2～24

サーバの最大数が64のとき：2～96

サーバの最大数が128以上のとき：2～192

exclusive_serversオペランドは複数指定できます。

また，指定したサーバ識別名の一つのサーバが，すでに実行サーバである場合は，指定されているそれ以外のサーバが起動できなくなります。そのサーバを起動させたい場合は，次のどちらかの対策をして起動してください。

実行サーバを停止したあと，サーバを起動します。

実行サーバを他系に計画系切り替えをしたあと，サーバを起動します。

8.5　モニタモードのプログラムの環境設定

モニタモードのプログラムの環境設定では，モニタモードのプログラム管理機能を使用するプログラムが動作するための定義をします。

この環境設定は，モニタモードのプログラム管理機能使用時だけに定義します。

＜この節の構成＞

8.5.1　モニタモードのプログラム対応の環境設定（programs）

8.5.1　モニタモードのプログラム対応の環境設定（programs）

モニタモードのプログラム対応の環境を設定する定義ファイルは，HAモニタの環境設定用ディレクトリの下にprogramsというファイル名で作成します。

また，HAモニタのサンプルファイル用ディレクトリの下に，programsファイルのサンプルが用意されています。このファイルをHAモニタの環境設定用ディレクトリにコピーし，書き換えて使用すると，定義ファイルを最初から作成する手間が省けます。

なお，この定義ファイルは系ごとに作成します。太字部分は，系間で同じ値を指定してください。太字以外の部分は，系間で矛盾がないように設定してください。

モニタモードのプログラム対応の環境設定をする定義ファイルを，次に示します。

/*    モニタモードのプログラム対応の環境設定    */
program  name  モニタモードのプログラム名
       ,alias モニタモードのプログラム識別名
       ,server_alias
              モニタモードのサーバ識別名
     〔,restartcommand
              プログラムの再起動コマンドの絶対パス名〕
     〔,patrol
              プログラムのスローダウン監視時間〕
     〔,restart_timeout
              プログラムの再起動監視時間〕
     〔,exec_retry
            ｛プログラムの再起動リトライ数｜2｝〕
     〔,retry_stable
            ｛プログラムの安定稼働経過時間｜60｝〕;

＜この項の構成＞

(1)　program定義文

(1)　program定義文

プログラム管理機能を使用するプログラムの動作環境を定義します。program定義文のオペランドを，次に示します。

name～<1～1,000文字のパス名>

モニタモードのプログラムを識別するために使用する名称を指定します。パス名でも指定できます。すべての系の中で一意となる名称を指定してください。使用するプログラムがUAPの場合，ここに指定した名称をHAMON_UAPNAME環境変数に指定します。

また，系切り替え構成内のすべての系で同じ値を指定してください。

alias～<1～8文字の英数字>

HAモニタで使用するコマンドや，出力するメッセージのための，モニタモードのプログラム識別名（プログラムの別名）を指定します。すべての系の中で一意となる名称を指定してください。また，系切り替え構成内のすべての系で同じ値を指定してください。

server_alias～<1～8文字の英数字>

このプログラムが管理するモニタモードのサーバ識別名（サーバ対応の環境設定のaliasオペランドの指定値）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

restartcommand～<1～1,000文字のパス名>

シェルなどで作成したプログラムの再起動コマンドを絶対パス名で指定します。系切り替え構成内のすべての系で同じ値を指定してください。

オペランドの指定値を"（引用符）で囲むことで，タブと改行コード以外の文字を含めて指定できます。"（引用符）は文字数にカウントされません。

このオペランドを省略した場合は，プログラムの障害時にサーバ単位で再起動または系切り替えをします。

patrol～<符号なし整数>((60～3600))（単位：秒）

UAPからの稼働報告を監視する時間（プログラムのスローダウン監視時間）を指定します。系切り替え構成内のすべての系で同じ値を指定してください。patrolオペランドに指定した時間を超えてもUAPからの稼働報告がなかった場合，HAモニタはUAP障害と判断します。

このオペランドを省略した場合，HAモニタはUAPの稼働報告を監視しません。

restart_timeout～<符号なし整数>((60～3600))（単位：秒）

プログラム再起動時のタイムアウト値を指定します。プログラムの再起動コマンドの起動から終了，およびhamon_patrolstart関数の発行までの時間を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

タイムアウトした場合，プログラムの再起動コマンドが再実行されます。

なお，restartcommandオペランドを省略した場合は，指定しても無視されます。

exec_retry～<符号なし整数>((0～9999))《2》（単位：回）

実行サーバのプログラムの障害を検出した場合にプログラムの再起動コマンドを再実行する回数を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

HAモニタが実行サーバのプログラム障害を検出した場合，指定した回数分だけrestartcommandオペランドに指定したプログラムの再起動コマンドの再実行を試みます。指定回数内でプログラムの再起動処理が完了した場合は，そのまま正常動作として処理が続行されます。指定回数内にプログラムの再起動処理が完了しない場合は，HAモニタはプログラム障害と判断し，プログラムの再起動を中止し，系切り替えをします。

このオペランドに9999を指定した場合は，プログラムの再起動処理が完了するまで，または実行サーバを停止させるまで無制限にプログラムを再起動します。

このオペランドを省略した場合は，サーバ対応の環境設定のservexec_retryオペランドの指定値に従ってサーバを再起動します。また，このオペランドに0を指定した場合は，プログラムの再起動はしないで，すぐに系切り替えを実行します。

なお，restartcommandオペランドを省略した場合は，指定しても無視されます。

retry_stable～<符号なし整数>((60～9999))《60》（単位：秒）

プログラムの再起動に成功した場合，そのプログラムの動作が安定したと判断するための監視時間を秒数で指定します。系切り替え構成内のすべての系で同じ値を指定してください。

プログラムが再起動したあと，このオペランドに指定した時間内に障害が検出されなかった場合，HAモニタはプログラムが安定して稼働したと判断し，再起動回数を0にリセットします。再起動成功後，再び0秒から安定稼働のために経過が監視されます。

このオペランドに9999を指定した場合，プログラムが正常終了するか，系切り替えによって終了するまで，再起動回数を0にリセットしません。

プログラムが再起動したあと，このオペランドに指定した時間が経過する前に再度障害が発生すると，再起動回数が更新され，プログラムが再起動されます。更新された再起動回数がモニタモードのプログラム対応の環境設定のexec_retryオペランドに指定した値を超えた場合は，プログラムの再起動はされないで系切り替え動作をします。

8.6　環境設定例

ここでは，次の場合の環境設定例を示します。

1:1系切り替え構成

複数系切り替え構成

排他サーバを指定した系切り替え構成

＜この節の構成＞

8.6.1　1:1系切り替え構成時の環境設定例

8.6.2　複数系切り替え構成時の環境設定例

8.6.3　排他サーバ指定時の環境設定例

8.6.1　1:1系切り替え構成時の環境設定例

1:1系切り替え構成では，使用するリソースや機能によって定義ファイルの設定内容が異なります。ここでは，1:1系切り替えの代表的なシステム構成を示し，各システム構成での定義ファイルの設定例を示します。

＜この項の構成＞

(1)　単独のサーバ使用時の環境設定例

(2)　サーバをグループ化する場合の環境設定例

(3)　相互系切り替え構成時の環境設定例

(4)　LANを監視する場合の環境設定例

(5)　ファイルシステム使用時の環境設定例

(6)　HA Booster使用時の環境設定例

(7)　サーバの切り替え順序を制御する場合の環境設定例

(8)　複数サーバで共有リソースを共用する場合の環境設定例

(9)　モニタモードのプログラム管理機能を使用する場合の環境設定例

(1)　単独のサーバ使用時の環境設定例

単独のサーバを使用する場合の，環境設定例で示すシステム構成を，次の図に示します。

図8-1　単独のサーバ使用時のシステム構成

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（単独のサーバ使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  online,
       disk     /dev/vg01;

予備系の環境設定（単独のサーバ使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  standby,
       disk     /dev/vg01;

(2)　サーバをグループ化する場合の環境設定例

サーバをグループ化する場合の，環境設定例で示すシステム構成を，次の図に示します。

図8-2　サーバをグループ化する場合のシステム構成

このシステム構成での現用系と予備系の環境設定例を次に示します。

現用系の環境設定（サーバをグループ化する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定(サーバ1)  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  online,
       group    groupA:exchange,
       disk     /dev/vg01;

/*  サーバ対応の環境設定(サーバ2)  */
server  name     /users/server2,
       alias    server2,
       acttype  server,
       patrol   60,
       initial  online,
       group    groupA:no_exchange:cancel,
       disk     /dev/vg02;

予備系の環境設定（サーバをグループ化する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定(サーバ1)  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  standby,
       group    groupA:exchange,
       disk     /dev/vg01;

/*  サーバ対応の環境設定(サーバ2)  */
server  name     /users/server2,
       alias    server2,
       acttype  server,
       patrol   60,
       initial  standby,
       group    groupA:no_exchange:cancel,
       disk     /dev/vg02;

(3)　相互系切り替え構成時の環境設定例

相互系切り替え構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-3　相互系切り替え構成時のシステム構成

このシステム構成での現用系と予備系の環境設定例を次に示します。

現用系の環境設定（相互系切り替え構成時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定(サーバ1)  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  online,
       disk     /dev/vg01;

/*  サーバ対応の環境設定(サーバ2)  */
server  name     /users/server2,
       alias    server2,
       acttype  server,
       patrol   60,
       initial  standby,
       disk     /dev/vg02;

予備系の環境設定（相互系切り替え構成時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定(サーバ1)  */
server  name     /users/server1,
       alias    server1,
       acttype  server,
       patrol   60,
       initial  standby,
       disk     /dev/vg01;

/*  サーバ対応の環境設定(サーバ2)  */
server  name     /users/server2,
       alias    server2,
       acttype  server,
       patrol   60,
       initial  online,
       disk     /dev/vg02;

(4)　LANを監視する場合の環境設定例

LANを監視する場合の，環境設定例で示すシステム構成を，次の図に示します。

図8-4　LANを監視する場合のシステム構成

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（LANを監視する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            lanfailswitch    use,
            lancheck_patrol  20;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name          /users/server1,
       alias         server1,
       acttype       server,
       patrol        60,
       initial       online,
       switchbyfail  hbond0;

LANの監視設定ファイル

LAN監視定義ファイル（定義ファイル：/opt/hitachi/HAmon/etc/hbond0.conf）

192.168.0.110
192.168.0.101
192.168.0.102
192.168.0.103
nodeD

予備系の環境設定（LANを監視する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            lanfailswitch    use,
            lancheck_patrol  20;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name          /users/server1,
       alias         server1,
       acttype       server,
       patrol        60,
       initial       standby,
       switchbyfail  hbond0;

LANの監視設定ファイル

LAN監視定義ファイル（定義ファイル：/opt/hitachi/HAmon/etc/hbond0.conf）

192.168.0.100
192.168.0.101
192.168.0.102
192.168.0.103
nodeD

(5)　ファイルシステム使用時の環境設定例

ファイルシステム使用時の，環境設定例で示すシステム構成を，次の図に示します。

図8-5　ファイルシステム使用時のシステム構成

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（ファイルシステム使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name         /users/server1,
       alias        server1,
       acttype      monitor,
       initial      online,
       disk         /dev/vg01,
       fs_name      /dev/lvol1:/dev/lvol2,
       fs_mount_dir /mnt/fs1:/mnt/fs2;

予備系の環境設定（ファイルシステム使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name         /users/server1,
       alias        server1,
       acttype      monitor,
       initial      standby,
       disk         /dev/vg01,
       fs_name      /dev/lvol1:/dev/lvol2,
       fs_mount_dir /mnt/fs1:/mnt/fs2;

(6)　HA Booster使用時の環境設定例

HA Boosterを使用した共有ディスク構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-6　HA Booster使用時のシステム構成

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（HA Booster使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name               host1,
            address            1,
            patrol             60,
            lan                path11:path12,
            lanport            HAmon1:HAmon2;
function     pathpatrol         1,
            pathpatrol_retry   3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server       name         /users/server1,
            alias        server1,
            acttype      server,
            patrol       60,
            initial      online,
            hab_gid      0;

予備系の環境設定（HA Booster使用時）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name               host2,
            address            2,
            patrol             60,
            lan                path21:path22,
            lanport            HAmon1:HAmon2;
function     pathpatrol         1,
            pathpatrol_retry   3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server       name         /users/server1,
            alias        server1,
            acttype      server,
            patrol       60,
            initial      standby,
            hab_gid      0;

(7)　サーバの切り替え順序を制御する場合の環境設定例

サーバの切り替え順序を制御する場合の，環境設定例で示すシステム構成例を，次の図に示します。

図8-7　サーバの切り替え順序を制御する場合のシステム構成

この例では，次の構成を前提としています。

server1およびserver2をグループ化します。

系切り替え時のサーバの起動順序について，server1はserver2の親サーバとします。

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（サーバの切り替え順序を制御する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       group        groupA:exchange,
       disk         /dev/vg01,
       lan_updown   use;

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      monitor,
       initial      online,
       group        groupA,
       disk         /dev/vg02,
       lan_updown   use,
       parent       server1;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server1.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server1.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server2.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:2 inet 1.2.3.5 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.5
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server2.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:2 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

予備系の環境設定（サーバの切り替え順序を制御する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      standby,
       group        groupA:exchange,
       disk         /dev/vg01,
       lan_updown   use;

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      monitor,
       initial      standby,
       group        groupA,
       disk         /dev/vg02,
       lan_updown   use,
       parent       server1;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server1.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server1.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server2.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:2 inet 1.2.3.5 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.5
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server2.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:2 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

(8)　複数サーバで共有リソースを共用する場合の環境設定例

複数サーバで共有リソースを共用する場合の，環境設定例で示すシステム構成例を，次の図に示します。

図8-8　複数サーバで共有リソースを共用する場合のシステム構成

この例では，次の構成を前提としています。

リソースサーバ，server1，およびserver2をグループ化します。

server1，およびserver2は，共有ディスクの/dev/vg01およびエイリアスIPアドレスの1.2.3.4を共通で使用します。

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（複数サーバで共有リソースを共用する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       group        groupA:exchange,
       parent       rc0;

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      monitor,
       initial      online,
       group        groupA,
       parent       rc0;

/*  リソースサーバ対応の環境設定  */
resource  alias        rc0,
         initial      online,
         group        groupA,
         disk         /dev/vg01,
         lan_updown   use;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/rc0.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/rc0.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

予備系の環境設定（複数サーバで共有リソースを共用する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      standby,
       group        groupA:exchange,
       parent       rc0;

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      monitor,
       initial      standby,
       group        groupA,
       parent       rc0;

/*  リソースサーバ対応の環境設定  */
resource  alias        rc0,
         initial      standby,
         group        groupA,
         disk         /dev/vg01,
         lan_updown   use;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/rc0.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/rc0.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

(9)　モニタモードのプログラム管理機能を使用する場合の環境設定例

モニタモードのプログラム管理機能を使用する場合の，環境設定例で示すシステム構成を，次の図に示します。

図8-9　モニタモードのプログラム管理機能を使用する場合のシステム構成

このシステム構成での現用系と予備系の環境設定例を，次に示します。

現用系の環境設定（モニタモードのプログラム管理機能を使用する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2,
            pgmmax           10;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name     /users/server1,
       alias    server1,
       acttype  monitor,
       initial  online,
       disk     /dev/vg01,
       program  use;

モニタモードのプログラム対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/programs）

/*  モニタモードのプログラム対応の環境設定  */
program  name           UAP1,
        alias          UAP1,
        server_alias   server1,
        patrol         180;
program  name           UAP2,
        alias          UAP2,
        server_alias   server1,
        patrol         180;

予備系の環境設定（モニタモードのプログラム管理機能を使用する場合）

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2,
            pgmmax           10;
function     pathpatrol       1,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name     /users/server1,
       alias    server1,
       acttype  monitor,
       initial  standby,
       disk     /dev/vg01,
       program  use;

モニタモードのプログラム対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/programs）

/*  モニタモードのプログラム対応の環境設定  */
program  name           UAP1,
        alias          UAP1,
        server_alias   server1,
        patrol         180;
program  name           UAP2,
        alias          UAP2,
        server_alias   server1,
        patrol         180;

8.6.2　複数系切り替え構成時の環境設定例

複数系切り替え構成では，2:1系切り替えやクラスタ型系切り替えなどの構成ごとに定義ファイルの設定内容が異なります。ここでは，複数系切り替えの代表的なシステム構成を示し，各システム構成での定義ファイルの設定例を示します。

2:1系切り替え構成やクラスタ型系切り替え構成など，複数の系がある構成では，HAモニタの環境設定は系ごとに，サーバ対応の環境設定はサーバごとに設定します。

HAモニタの環境設定は，すべての系で整合性を取る必要があります。

また，サーバ対応の環境設定も，ペアになるサーバ（実行サーバと待機サーバ）の間で，整合性を取る必要があります。

ペアになる実行・待機サーバ間で使用する共有ディスクは，サーバ間で同じスペシャルファイル名のボリュームグループに接続します。そのため，ペアになる実行・待機サーバ間では，同じスペシャルファイル名を指定してください。

なお，ペアにならない実行・待機サーバ間で同じスペシャルファイル名を指定すると，系切り替えが正しく実行されないことがあります。共有リソースについての指定では，ペアになる実行・待機サーバ間以外で同じ値を指定しないでください。

＜この項の構成＞

(1)　2:1系切り替え構成時の環境設定例

(2)　複数スタンバイ構成時の環境設定例（TP1/Server BaseまたはHiRDB）

(3)　複数スタンバイ構成時の環境設定例（TP1/EE）

(4)　クラスタ型系切り替え構成時の環境設定例

(1)　2:1系切り替え構成時の環境設定例

2:1系切り替え構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-10　2:1系切り替え構成時のシステム構成

また，このシステム構成例での前提条件を次に示します。

表8-6　環境設定例の前提条件（2:1系切り替え構成時－HAモニタ）

前提条件 | 現用系1 | 予備系 | 現用系2
ホスト名 | host1 | host2 | host3
ホストアドレス | 1 | 2 | 3
系障害監視時間 | 60秒 | 60秒 | 60秒
サーバ障害監視時間 | 60秒 | 60秒 | 60秒
リセット優先系 | online | online | online
監視パスのヘルスチェック間隔 | 120分 | 120分 | 120分
リセットパスのヘルスチェック間隔 | 2分 | 2分 | 2分

表8-7　環境設定例の前提条件（2:1系切り替え構成時－サーバ）

前提条件 | サーバ1 | サーバ2
現用系1 | 予備系 | 予備系 | 現用系2
プログラム名 | /users/server1 | /users/server1 | /users/server2 | /users/server2
サーバ識別名 | server1 | server1 | server2 | server2
サーバの起動方法 | server | server | server | server
起動種別 | online | standby | standby | online

このシステム構成での環境設定例を，次に示します。なお，太字は，すべての系のHAモニタやペアになるサーバ間で，同じ値を指定することを表します。

現用系1の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg01;

予備系の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      standby,
       disk         /dev/vg01;

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      standby,
       disk         /dev/vg02;

現用系2の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host3,
            address          3,
            patrol           60,
            lan              path31:path32,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120,
            pathpatrol_retry 3:3;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg02;

(2)　複数スタンバイ構成時の環境設定例（TP1/Server BaseまたはHiRDB）

サーバモードのサーバとしてTP1/Server BaseまたはHiRDBを使用する場合で，複数スタンバイ構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-11　複数スタンバイ構成時のシステム構成（TP1/Server BaseまたはHiRDB）

また，このシステム構成例での前提条件を次に示します。

表8-8　環境設定例の前提条件（TP1/Server BaseまたはHiRDBでの複数スタンバイ構成時－HAモニタ）

前提条件 | 現用系 | 予備系1 | 予備系2
ホスト名 | host1 | host2 | host3
ホストアドレス | 1 | 2 | 3
系障害監視時間 | 60秒 | 60秒 | 60秒
サーバ障害監視時間 | 60秒 | 60秒 | 60秒
リセット優先系 | online | online | online
監視パスのヘルスチェック間隔 | 1分 | 1分 | 1分
監視パスの再チェック間隔 | 3秒 | 3秒 | 3秒
監視パスの再チェック回数 | 3回 | 3回 | 3回
マルチスタンバイ機能使用の有無 | 有 | 有 | 有

表8-9　環境設定例の前提条件（TP1/Server BaseまたはHiRDBでの複数スタンバイ構成時－サーバ）

前提条件 | 現用系 | 予備系1 | 予備系2
プログラム名 | /users/server1 | /users/server1 | /users/server1
サーバ識別名 | server1 | server1 | server1
サーバの起動方法 | server | server | server
起動種別 | online | standby | standby
LANの状態設定ファイル使用の有無 | 有 | 有 | 有
待機サーバ優先度 | 指定なし | 1 | 2

このシステム構成での環境設定例を，次に示します。なお，太字は，すべての系のHAモニタやペアになるサーバ間で，同じ値を指定することを表します。

現用系の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            /users/server1,
       alias           server1,
       acttype         server,
       patrol          60,
       initial         online,
       disk            /dev/vg01,
       lan_updown      use;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server1.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0 broadcast 1.2.3.255
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server1.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

予備系1の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            /users/server1,
       alias           server1,
       acttype         server,
       patrol          60,
       initial         standby,
       disk            /dev/vg01,
       lan_updown      use,
       standbypri      1;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server1.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0 broadcast 1.2.3.255
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server1.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

予備系2の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host3,
            address          3,
            patrol           60,
            lan              path31:path32,
            lanport          HAmon1:HAmon2;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            /users/server1,
       alias           server1,
       acttype         server,
       patrol          60,
       initial         standby,
       disk            /dev/vg01,
       lan_updown      use,
       standbypri      2;

LANの状態設定ファイル

サーバ識別名.up（定義ファイル：/opt/hitachi/HAmon/etc/server1.up）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 inet 1.2.3.4 netmask 255.255.255.0 broadcast 1.2.3.255
/sbin/arping -U -c 2 -I eth1 1.2.3.4
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

サーバ識別名.down（定義ファイル：/opt/hitachi/HAmon/etc/server1.down）

#!/bin/sh
set -x
/sbin/ifconfig eth1:1 down
/bin/echo 0 > /proc/sys/net/ipv4/route/flush

(3)　複数スタンバイ構成時の環境設定例（TP1/EE）

サーバモードのサーバとしてTP1/EEを使用する場合で，複数スタンバイ構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-12　複数スタンバイ構成時のシステム構成（TP1/EE）

また，このシステム構成例での前提条件を次に示します。

表8-10　環境設定例の前提条件（TP1/EEでの複数スタンバイ構成時－HAモニタ）

前提条件 | 現用系 | 予備系1 | 予備系2
ホスト名 | host1 | host2 | host3
ホストアドレス | 1 | 2 | 3
系障害監視時間 | 3秒 | 3秒 | 3秒
監視パスのヘルスチェック間隔 | 1分 | 1分 | 1分
監視パスの再チェック間隔 | 3秒 | 3秒 | 3秒
監視パスの再チェック回数 | 3回 | 3回 | 3回
マルチスタンバイ機能使用の有無 | 有 | 有 | 有
aliveメッセージの送信間隔 | 500ミリ秒 | 500ミリ秒 | 500ミリ秒

表8-11　環境設定例の前提条件（TP1/EEでの複数スタンバイ構成時－サーバ）

前提条件 | 現用系 | 予備系1 | 予備系2
プログラム名 | a001 | a001 | a001
サーバ識別名 | server1 | server1 | server1
サーバの起動方法 | server | server | server
サーバの監視方法 | B | B | B
起動種別 | online | standby | standby
LANの状態設定ファイル使用の有無 | 無 | 無 | 無
待機サーバ優先度 | 指定なし | 1 | 2

このシステム構成での環境設定例を，次に示します。なお，太字は，すべての系のHAモニタやペアになるサーバ間で，同じ値を指定することを表します。

現用系の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           3,
            lan              path11:path12:path13:path14,
            lanport          HAmon1:HAmon2:HAmon3:HAmon4;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use,
            alive_interval   5;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            a001,
       alias           server1,
       acttype         server,
       server_type     B,
       initial         online,
       lan_updown      nouse;

予備系1の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           3,
            lan              path21:path22:path23:path24,
            lanport          HAmon1:HAmon2:HAmon3:HAmon4;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use,
            alive_interval   5;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            a001,
       alias           server1,
       acttype         server,
       server_type     B,
       initial         standby,
       lan_updown      nouse,
       standbypri      1;

予備系2の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host3,
            address          3,
            patrol           60,
            lan              path31:path32:path33:path34,
            lanport          HAmon1:HAmon2:HAmon3:HAmon4;
function     pathpatrol       1,
            pathpatrol_retry 3:3,
            multistandby     use,
            alive_interval   5;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定  */
server  name            a001,
       alias           server1,
       acttype         server,
       server_type     B,
       initial         standby,
       lan_updown      nouse,
       standbypri      2;

(4)　クラスタ型系切り替え構成時の環境設定例

クラスタ型系切り替え構成時の，環境設定例で示すシステム構成を，次の図に示します。

図8-13　クラスタ型系切り替え構成時のシステム構成

また，このシステム構成例での前提条件を次に示します。

表8-12　環境設定例の前提条件（クラスタ型系切り替え構成時－HAモニタ）

前提条件
現用系1
予備系1
現用系2
（予備系3）
現用系3
（予備系2）

ホスト名
host1
host2
host3
host4

ホストアドレス
1
2
3
4

系障害監視時間
60秒
60秒
60秒
60秒

サーバ障害監視時間
60秒
60秒
60秒
60秒

リセット優先系
online
online
online
online

監視パスのヘルスチェック間隔
120分
120分
120分
120分

リセットパスのヘルスチェック間隔
2分
2分
2分
2分

表8-13　環境設定例の前提条件（クラスタ型系切り替え構成時－サーバ）

前提条件
サーバ1
サーバ2
サーバ3

現用系1
予備系1
現用系2
（予備系3）
現用系3
（予備系2）
現用系2
（予備系3）
現用系3
（予備系2）

プログラム名
/users/server1
/users/server1
/users/server2
/users/server2
/users/server3
/users/server3

サーバ識別名
server1
server1
server2
server2
server3
server3

サーバの起動方法
server
server
server
server
server
server

起動種別
online
standby
online
standby
standby
online

このシステム構成での環境設定例を，次に示します。なお，太字は，すべての系のHAモニタやペアになるサーバ間で，同じ値を指定することを表します。

現用系1の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host1,
            address          1,
            patrol           60,
            lan              path11:path12,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg01;

予備系1の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host2,
            address          2,
            patrol           60,
            lan              path21:path22,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ1）  */
server  name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      standby,
       disk         /dev/vg01;

現用系2（予備系3）の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host3,
            address          3,
            patrol           60,
            lan              path31:path32,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg02;

/*  サーバ対応の環境設定（サーバ3）  */
server  name         /users/server3,
       alias        server3,
       acttype      server,
       patrol       60,
       initial      standby,
       disk         /dev/vg03;

現用系3（予備系2）の環境設定

HAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

/*  HAモニタの環境設定  */
environment  name             host4,
            address          4,
            patrol           60,
            lan              path41:path42,
            lanport          HAmon1:HAmon2;
function     cpudown          online,
            pathpatrol       120;

サーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

/*  サーバ対応の環境設定（サーバ2）  */
server  name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      standby,
       disk         /dev/vg02;

/*  サーバ対応の環境設定（サーバ3）  */
server  name         /users/server3,
       alias        server3,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg03;

8.6.3　排他サーバ指定時の環境設定例

ここでは，排他サーバを指定する場合の定義ファイルの設定例を，排他サーバ内の排他関係ごとに示します。

＜この項の構成＞

(1)　サーバ単位に排他関係にある場合の定義例

(2)　グループ単位に排他関係にある場合の定義例

(3)　グループ内の一部のサーバで排他関係にある場合の定義例

(4)　サーバ単位に排他関係（複数）にある場合の定義例

(5)　グループ単位に排他関係（複数）にある場合の定義例

(6)　グループとサーバ単体で排他関係にある場合の定義例

(1)　サーバ単位に排他関係にある場合の定義例

サーバ単位に排他関係にある場合の環境設定の定義例を，次の図に示します。

図8-14　サーバ単位に排他関係にある場合の環境設定の定義例

(2)　グループ単位に排他関係にある場合の定義例

サーバグループ同士が排他関係にある場合の環境設定の定義例を，次の図に示します。

図8-15　グループ単位に排他関係にある場合の環境設定の定義例

(3)　グループ内の一部のサーバで排他関係にある場合の定義例

サーバグループ内の一部のサーバで排他関係にある場合の環境設定の定義例を，次の図に示します。

図8-16　グループ内の一部のサーバで排他関係にある場合の環境設定の定義例

(4)　サーバ単位に排他関係（複数）にある場合の定義例

サーバ単位に排他関係（複数）にある場合の環境設定の定義例を，次の図に示します。

図8-17　サーバ単位に排他関係（複数）にある場合の環境設定の定義例

(5)　グループ単位に排他関係（複数）にある場合の定義例

サーバグループ同士が排他関係（複数）にある場合の環境設定の定義例を，次の図に示します。

図8-18　グループ単位に排他関係（複数）にある場合の環境設定の定義例

(6)　グループとサーバ単体で排他関係にある場合の定義例

サーバグループとサーバ単体で排他関係にある場合の環境設定の定義例を，次の図に示します。

図8-19　グループとサーバ単体で排他関係にある場合の環境設定の定義例

9.　コマンド

この章では，HAモニタで使用するコマンドについて説明します。

＜この章の構成＞

コマンド一覧

コマンドの説明で使用する見出し

文法記述記号

monact（待ち状態のサーバを実行サーバとして起動）

monbegin（モニタモードのサーバの起動）

monchange（HAモニタ・サーバ稼働中の設定変更）

moncheck（定義チェック）

mondeact（待ち状態のサーバの停止）

mondevice（実行サーバ稼働中の共有リソースの変更）

monend（モニタモードのサーバの停止）

moninfo（実行系でのサーバ引き継ぎ情報の設定／待機系でのサーバ引き継ぎ情報の参照・表示）

monlink（HAモニタ間の手動接続）

monlistip（IPアドレスの検出）

monmp（MPの状態表示）

monodrshw（サーバ順序制御の状態表示）

monpath（監視パスの状態表示）

monresbgn（リソースサーバの起動）

monresend（実行中のリソースサーバの停止）

monressbystp（待機中のリソースサーバの停止）

monrp（リセットパスの状態表示）

monsbystp（待機サーバの停止）

monsetup（HAモニタの環境設定）

monshow（サーバと系の状態表示）

monstart（HAモニタの起動）

monstop（HAモニタの停止）

monswap（計画系切り替え）

monts（HAモニタのトラブルシュート情報の収集）

コマンド一覧

HAモニタで使用するコマンドの一覧を次の表に示します。

表9-1　HAモニタのコマンド一覧

コマンド名 | 機能 | 実行できるユーザ
スーパユーザ | 一般ユーザ
環境の構築・変更で使用するコマンド | monsetup | HAモニタの環境設定をします。 | ○ | ×
monlistip | IPアドレスを検出します。 | ○ | ×
moncheck | 定義チェックを実施します。 | ○ | ○
mondevice | 実行サーバ稼働中に共有リソースを変更します。 | ○ | ×
monchange | HAモニタやサーバの稼働中に設定を変更します。 | ○ | ×
HAモニタに対する運用コマンド | monstart | HAモニタを起動します。 | ○ | ○
monstop | HAモニタを停止します。 | ○ | ○
monlink | HAモニタ間を手動接続します。 | ○ | ○
サーバに対する運用コマンド | monbegin | モニタモードのサーバを起動します。 | ○ | ○
monend | モニタモードの実行サーバを停止します。 | ○ | ○
monsbystp | 待機サーバを停止します。 | ○ | ×
monresbgn | リソースサーバを起動します。 | ○ | ○
monresend | 実行中のリソースサーバを停止します。 | ○ | ○
monressbystp | 待機中のリソースサーバを停止します。 | ○ | ×
monact | 待ち状態のサーバを実行サーバとして起動します。 | ○ | ×
mondeact | 待ち状態のサーバを停止します。 | ○ | ×
状態を確認するためのコマンド | monshow | サーバと系の状態を表示します。 | ○ | ○
monrp | リセットパスの状態を表示します。 | ○ | ×
monmp | MPの状態を表示します。 | ○ | ×
monpath | 監視パスの状態を表示します。 | ○ | ×
monodrshw | サーバの切り替え順序制御の状態を表示します。 | ○ | ○
系切り替えをするためのコマンド | monswap | 計画系切り替えをします。 | ○ | ×
ユーザコマンド内で発行するコマンド | moninfo | サーバ引き継ぎ情報を，実行系で設定または待機系で参照・表示します。 | ○ | ○
トラブル発生時の情報収集コマンド | monts | HAモニタのトラブルシュート情報を収集します。 | ○ | ×

（凡例）

○：実行できます。

×：実行できません。

コマンドの説明で使用する見出し

コマンドの説明で使用する，各見出しについて説明します。なお，各コマンドの説明では，次の項目のうち必要な項目についてだけ説明しています。また，次の項目以外に，各コマンドの固有情報を記載している場合があります。

形式

文法記述記号を使用して，コマンドの記述形式について説明しています。文法記述記号については，「9.　コマンド」の「文法記述記号」を参照してください。

実行できるユーザ

コマンドを実行する権限を持つユーザを示します。

機能

コマンドの機能について説明します。

オプション

オプションの指定内容や，オプションを指定するときの注意事項などを説明します。

リターンコード

コマンドのリターンコードについて説明します。

注意事項

コマンドを実行するときの注意事項を説明します。

使用例

コマンドの実行例を示します。

コマンドを実行したあとに表示される結果には，メッセージIDが付けられています。表示される結果の見方については，メッセージIDを基に，マニュアル「高信頼化システム監視機能 HAモニタ メッセージ」を参照してください。

文法記述記号

コマンドの説明で使用する文法記述記号を説明します。各文法記述記号の意味を，次の表に示します。

表9-2　コマンドの文法記述記号一覧

文法記述記号
意味

[　]
この記号で囲まれている項目は，省略してもよいことを示します。
（例）
monshow [サーバ識別名]
monshowコマンドでは，サーバ識別名を指定するか，または何も指定しないことを示します。

{　}
この記号で囲まれている項目の中から，一つを選択して指定することを示します。複数の項目が記述されている場合に，そのうちの一つを選択して指定します。
（例）
monodrshw { -s サーバ識別名 | -g グループ名 }
monodrshwコマンドでは，-s サーバ識別名または-g グループ名のどちらかを選択して指定することを示します。

|
{　}で囲まれている複数の項目間の区切りを示します。
（例）
moninfo サーバ識別名 { -p サーバ引き継ぎ情報 | -g }
moninfoコマンドでは，サーバ識別名に続き，-p サーバ引き継ぎ情報または-gのどちらかを選択して指定することを示します。

monact（待ち状態のサーバを実行サーバとして起動）

形式

monact サーバ識別名

実行できるユーザ

スーパユーザ

機能

次のサーバを実行サーバとして起動させます。

実行サーバの起動待ち状態になった待機サーバ
サーバ対応の環境設定で待機サーバとして定義したサーバは，起動時に通信障害などで実行系の状態が確認できないと，実行系の実行サーバの起動待ち状態になります。この待ち状態になった待機サーバを，強制的に実行サーバとして起動させます。

連動系切り替え待ち状態になった待機サーバ
サーバ対応の環境設定のgroupオペランドでno_exchangeを指定したサーバに障害が発生した場合，待機系の待機サーバは連動系切り替え待ち状態になります。この待ち状態になった待機サーバを，強制的に実行サーバとして起動させます。

系切り替え待ち状態になった実行サーバ
系のリセット失敗時，待機系の待機サーバは実行サーバに切り替わったあと，系切り替え待ち状態になります。この待ち状態になった実行サーバを，強制的に実行サーバとして起動させます。

オプション

サーバ識別名
実行サーバとして起動させるサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（待ち状態のサーバを実行サーバとして起動完了しました）
0以外 | 異常終了

注意事項

monactコマンドを実行する前に，他系で実行サーバが稼働していないことを確認してください。確認しないでmonactコマンドを実行すると，二つの実行サーバが稼働するおそれがあります。

monactコマンドは，次の状態のサーバにだけ使用できます。

実行サーバの起動待ち状態になった待機サーバ

連動系切り替え待ち状態になった待機サーバ

系切り替え待ち状態になった実行サーバ

リソースサーバの起動待ち状態になったサーバに対しては，monactコマンドを実行できません。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN227-E，KAMN322-E，KAMN339-E，KAMN456-E，KAMN465-E

monbegin（モニタモードのサーバの起動）

形式

monbegin サーバ識別名

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

モニタモードのサーバを起動します。

オプション

サーバ識別名
起動するサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（モニタモードのサーバ起動要求の受け付けが完了しました）
0以外 | 異常終了

注意事項

monbeginコマンドは，モニタモードのサーバにだけ使用できます。

monchange（HAモニタ・サーバ稼働中の設定変更）

形式

HAモニタの設定変更

monchange -m オペランド名 指定値

サーバの設定変更

monchange -s サーバ識別名 オペランド名 指定値

モニタモードのプログラムの設定変更

monchange -p モニタモードのプログラム識別名 オペランド名 指定値

実行できるユーザ

スーパユーザ

機能

HAモニタやサーバの稼働中に，次の設定を変更できます。

HAモニタの設定変更

HAモニタの環境設定のpatrolオペランドに指定した系障害監視時間。

サーバの設定変更

サーバ対応の環境設定のpatrolオペランドに指定したサーバ障害監視時間。

モニタモードのプログラムの設定変更

モニタモードのプログラム対応の環境設定のpatrolオペランドに指定した，プログラムのスローダウン監視時間。

オプション

HAモニタの設定変更

-m
HAモニタの設定を変更する場合に指定します。

オペランド名
変更したいHAモニタの設定に該当するオペランド名として，"patrol"を指定します。

指定値
変更後のpatrolオペランドの指定値を設定します。patrolオペランドの指定値については，「8.3.1　HAモニタの環境設定（sysdef）」を参照してください。

サーバの設定変更

-s
サーバの設定を変更する場合に指定します。

サーバ識別名
設定を変更したいサーバのサーバ識別名を指定します。

オペランド名
変更したいサーバの設定に該当するオペランド名として，"patrol"を指定します。

指定値
変更後のpatrolオペランドの指定値を設定します。patrolオペランドの指定値については，「8.4.1　サーバ対応の環境設定（servers）」を参照してください。

モニタモードのプログラムの設定変更

-p
プログラム管理機能を使用するモニタモードのプログラムの設定を変更する場合に指定します。

モニタモードのプログラム識別名
設定を変更したいモニタモードのプログラムのプログラム識別名を指定します。

オペランド名
変更したいモニタモードのプログラムの設定に該当するオペランド名として，"patrol"を指定します。

指定値
変更後のpatrolオペランドの指定値を設定します。patrolオペランドの指定値については，「8.5.1　モニタモードのプログラム対応の環境設定（programs）」を参照してください。

リターンコード

値 | 意味
0 | 正常終了（HAモニタ・サーバ稼働中の設定変更が完了しました）
0以外 | 異常終了

注意事項

monchangeコマンドでは，定義ファイルの内容を書き換えません。設定を変更したあとにサーバやHAモニタを再起動すると，変更した値は各定義ファイルに設定した値に戻ります。必要に応じて環境設定を変更し，再起動してください。

HAモニタの設定を変更する場合の注意事項を次に示します。

変更するすべての系が接続中であることを確認してからコマンドを実行してください。

一つの系でmonchangeコマンドを実行すれば，接続しているすべての系の系障害監視時間を変更できます。

複数の系から同時にコマンドを実行しないでください。

系障害監視時間を変更したあとに系を再起動した場合や，通信障害などで系間での監視時間が不一致になった場合は，monchangeコマンドを再度実行し，系間での系障害監視時間を一致させてください。

系の監視履歴を取得している場合，変更後の系障害監視時間を系の監視履歴取得時間より長い値に設定してください。短い値を指定すると，監視履歴は取得されません。

サーバの設定を変更する場合の注意事項を次に示します。

monchangeコマンドでは，コマンドを実行した系のサーバ障害監視時間だけを変更します。待機サーバが稼働する系でもコマンドを実行してください。

サーバの監視履歴を取得している場合，変更後のサーバ障害監視時間をサーバの監視履歴取得時間より長い値に設定してください。短い値を指定すると，監視履歴は取得されません。

モニタモードのプログラムの設定を変更する場合の注意事項を次に示します。

monchangeコマンドでは，コマンドを実行した系のプログラムのスローダウン監視時間だけを変更します。待機サーバが稼働する系でもコマンドを実行してください。

同一のプログラム識別名で稼働する複数プロセス構成の場合は，すべてのプロセスのプログラムのスローダウン監視時間を変更します。

使用例

HAモニタの設定変更

monchange -m patrol 60

サーバの設定変更

monchange -s server1 patrol 5

モニタモードのプログラムの設定変更

monchange -p program1 patrol 600

moncheck（定義チェック）

形式

moncheck

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

定義をチェックします。moncheckコマンドでチェックする項目を次に示します。

定義ファイルの定義内容が規則に合っているかどうか。

環境設定ファイルのオペランドに指定したリソースがあるかどうか。
moncheckコマンドでリソースの有無をチェックする環境設定ファイルのオペランドを次に示します。

表9-3　moncheckコマンドでリソースの有無をチェックする環境設定ファイルのオペランド

環境設定ファイルの種類
チェックするオペランド

HAモニタの環境設定（sysdef）

lanオペランド

usrcommandオペランド

multicast_lanオペランド

サーバ対応の環境設定（servers）

diskオペランド

fs_nameオペランド

fs_mount_dirオペランド

hab_gidオペランド

patrolcommandオペランド

モニタモードのプログラム対応の環境設定（programs）

restartcommandオペランド

LANの状態設定ファイルが存在するかどうか。

サーバ対応の環境設定のswitchbyfailオペランドに指定したLANインタフェースに対応する，LAN監視定義ファイルが存在するかどうか。

他系のOSパニック検知機能を使用する場合，動作環境が整っているかどうか。

HAモニタ Extensionの機能の設定をしている場合に，monsetup -exコマンドが実行されているかどうか。

オプション

なし。

リターンコード

値 | 意味
0 | 正常終了（定義チェックが完了しました）
0以外 | 異常終了

mondeact（待ち状態のサーバの停止）

形式

mondeact サーバ識別名

実行できるユーザ

スーパユーザ

機能

次のサーバを停止させます。

実行サーバの起動待ち状態になった待機サーバ
サーバ対応の環境設定で待機サーバとして定義したサーバは，起動時に通信障害などで実行系の状態が確認できないと，実行系の実行サーバの起動待ち状態になります。この状態の待機サーバを，強制的に停止させます。

再起動待ち状態になった実行サーバ
サーバ対応の環境設定のswitchtypeオペランドでrestartまたはmanualを指定した実行サーバは，サーバ障害時に系切り替えをしないで，再起動待ち状態になります。この待ち状態の実行サーバを，強制的に停止させます。再起動待ち状態になった実行サーバをmondeactコマンドで停止させた場合は，対応する待機サーバも自動で停止させます。

系切り替え待ち状態になった実行サーバ
系のリセット失敗時，待機系の待機サーバは実行サーバに切り替わったあと，系切り替え待ち状態になります。この待ち状態の実行サーバを，強制的に停止させます。
マルチスタンバイ機能を使用する場合で，系切り替え待ち状態になった実行サーバをmondeactコマンドで停止させたときは，対応するすべての系の待機サーバも自動で停止させます。

オプション

サーバ識別名
停止させるサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（待ち状態のサーバの停止が完了しました）
0以外 | 異常終了

注意事項

mondeactコマンドは，次の状態のサーバにだけ使用できます。

実行サーバの起動待ち状態になった待機サーバ

再起動待ち状態になった実行サーバ

系切り替え待ち状態になった実行サーバ

リソースサーバの起動待ち状態になったサーバに対しては，mondeactコマンドを実行できません。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN322-E，KAMN337-E，KAMN339-E，KAMN465-E

mondevice（実行サーバ稼働中の共有リソースの変更）

形式

共有リソースの追加

mondevice サーバ識別名 -a デバイス種別 リソース名

共有リソースの削除

mondevice サーバ識別名 -d デバイス種別 リソース名

共有リソースの変更

mondevice サーバ識別名 -c デバイス種別 リソース名 変更種別 属性

コマンドを対話形式で実行

mondevice -Q

実行できるユーザ

スーパユーザ

機能

実行サーバ稼働中に，共有リソースを追加・削除します。また，共有リソースの属性も変更します。サーバ対応の環境設定も自動で変更します。

オプション

共有リソースの追加

サーバ識別名
共有リソースを追加するサーバの識別名を指定します。

-a
共有リソースを追加する場合に指定します。

デバイス種別
追加の対象となる共有リソースの種別を指定します。

disk：共有ディスクを追加の対象とします。

リソース名
追加する自系の共有リソースの名称を指定します。

共有リソースの削除

サーバ識別名
共有リソースを削除するサーバの識別名を指定します。

-d
共有リソースを削除する場合に指定します。

デバイス種別
削除の対象となる共有リソースの種別を指定します。

disk：共有ディスクを削除の対象とします。

リソース名
削除の対象となる自系の共有リソースの名称を指定します。

共有リソースの変更

サーバ識別名
共有リソースを変更するサーバの識別名を指定します。

-c
共有リソースの属性を変更する場合に指定します。

デバイス種別
変更の対象となる共有リソースの種別を指定します。

disk：共有ディスクを変更の対象とします。

リソース名
変更の対象となる自系の共有リソースの名称を指定します。

変更種別
変更の対象となる自系の共有リソースに対する変更種別を次から選んで指定します。このオプションは-cオプションを使用している場合だけ指定します。また，このオプションを指定した場合は，続けて，属性オプションを指定してください。

vg_neck
ボリュームグループのオンラインに失敗した場合にサーバの起動を中止するかどうかを変更します。サーバ対応の環境設定のvg_neckオペランドに相当しています。

vg_on_opt
ボリュームグループのオンライン化コマンド実行時のオプションを変更します。サーバ対応の環境設定のvg_on_optオペランドに相当しています。

属性
変更の対象となる自系の共有リソースの属性を次のように指定します。このオプションは-cオプションを使用している場合だけ指定します。

変更種別オプションがvg_neckの場合

use：ディスクリソースのオンライン失敗時にサーバの起動を中止させます。

nouse：ディスクリソースのオンライン失敗時にサーバの起動を中止させないで，処理を続行します。

変更種別オプションがvg_on_optの場合

ディスクリソースのオンライン化コマンド実行時のオプションを指定します。オプションをなしに変更するには属性に「""」（二つの引用符）を指定します。デフォルトのオプションに変更する場合には「,」（コンマ）を指定します。複数のオプションを指定する場合は，属性全体を"（引用符）で囲んで指定します。

コマンドを対話形式で実行

-Q
mondeviceコマンドを，対話形式で実行します。

リターンコード

値 | 意味
0 | 正常終了（実行サーバ稼働中の共有リソースの変更が完了しました）
0以外 | 異常終了

注意事項

mondeviceコマンドは，実行サーバと待機サーバの両方が起動完了してから，または実行サーバだけが起動完了してから実行できます。実行サーバだけが起動完了した時点（待機サーバが起動完了していない時点）で実行した場合，待機サーバ側のサーバ対応の環境設定は自動で変更されません。待機サーバを一度停止させ，実行サーバと環境設定の内容を合わせてから，待機サーバを再起動してください。

変更前のサーバ対応の環境設定の内容は，servers.bacファイルに退避されます。

コマンド実行時にサーバ対応の環境設定の内容が正しくないと，定義ファイルは更新されません。その場合は，テキストエディタなどでファイルの内容を更新してください。

mondeviceコマンドでは，LANの追加・削除はしません。次の方法でLANの追加・削除をしてください。

LANの追加
該当する実行系のLANをネットワークに接続し，両方の系のLANの状態設定ファイルに接続したLANの情報を追加してください。

LANの削除
該当する実行系のLANをネットワークから切り離し，両方の系のLANの状態設定ファイルから切り離しをしたLANの情報を削除してください。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN320-E，KAMN322-E，KAMN451-E，KAMN452-E，KAMN453-E，KAMN454-E，KAMN455-E，KAMN456-E，KAMN460-E，KAMN465-E

使用例

共有リソースの追加

共有リソースを追加する場合，サーバ対応の環境設定には「xxx_add」というオペランドで追加されます。xxxには，追加したリソースのデバイス種別が入ります。

mondevice server1 -a disk /dev/vg01を実行した場合の，サーバ対応の環境設定の内容を，次の例に示します。

/*  サーバ対応の環境設定  */
server    name       /users/server1,
          alias      server1,
            :
            :
            :
            :
          disk_add   /dev/vg01;

共有リソースの削除

共有リソースを削除する場合，サーバ対応の環境設定には「xxx_del」というオペランドで追加されます。xxxには，削除したリソースのデバイス種別が入ります。

mondevice server1 -d disk /dev/vg01を実行した場合の，サーバ対応の環境設定の内容を，次の例に示します。

/*  サーバ対応の環境設定  */
server    name       /users/server1,
          alias      server1,
            :
            :
            :
            :
          disk_del   /dev/vg01;

共有リソースの追加・削除

xxx_addオペランドで追加，xxx_delオペランドで削除した共有リソースは，次のサーバの起動時にも自動的に追加・削除されますが，ユーザは必要な時期にサーバ対応の環境設定の内容を修正してください。

diskを追加・削除した場合の，サーバ対応の環境設定の内容を次の例に示します。

修正前

       disk         /dev/vg:/dev/vg2,
       disk_add     /dev/vg3,
       disk_del     /dev/vg2;

修正後

       disk         /dev/vg:/dev/vg3;

共有リソースの変更

共有リソースの属性を変更する場合，サーバ対応の環境設定には「xxx_chg」というオペランドで追加されます。xxxには，変更した属性を持つリソースのデバイス種別が入ります。

mondevice server1 -c disk /dev/vg01 vg_neck use を実行した場合の，サーバ対応の環境設定の内容を，次の例に示します。

/*  サーバ対応の環境設定  */
server    name       /users/server1,
          alias      server1,
            :
            :
            :
            :
          disk       /dev/vg01,
          disk_chg   /dev/vg01:vg_neck:use;

共有リソースの追加・変更・削除

xxx_addオペランドで追加，xxx_delオペランドで削除，またはxxx_chgオペランドで属性値を変更した共有リソースは，次のサーバの起動時にも自動的に追加，変更，削除されますが，ユーザは必要な時期にサーバ対応の環境設定の内容を修正してください。

diskオペランドに/dev/vg04を追加し，/dev/vg03に対応するvg_neckオペランドの値をuseに指定してから/dev/vg01を削除した場合の，サーバ対応の環境設定の内容を，次の例に示します。

修正前

       disk       /dev/vg01:/dev/vg02:/dev/vg03,
       vg_neck    use:nouse:nouse,
       disk_add   /dev/vg04,
       disk_chg   /dev/vg03:vg_neck:use,
       disk_del   /dev/vg01;

修正後

       disk       /dev/vg02:/dev/vg03:/dev/vg04,
       vg_neck    nouse:use:nouse;

diskオペランドの指定値を変更する場合には，変更種別に指定されたオペランドの値も同時に変更してください。

コマンドを対話形式で実行

-Qオプションを指定することで，対話形式でコマンドを実行できます。実行中に指定を誤ったなどの理由でコマンドの実行を取りやめたい場合は，コントロールキーを押しながらCキー（CTRL＋C）を押してください。使用例の詳細を次に示します。ここでは，サーバ識別名がserver1のサーバのdiskを追加する場合を例に示します。

> mondevice -Q
このコマンドでは，共有リソースを変更します。
処理を中断する場合は，[CTRL]+[C]キーを押してください。
Q．処理の対象となるサーバ識別名を指定してください。
［サーバ識別名］：
> server1
Q．実行する処理を次の番号から選択してください。
(1)デバイスの追加
(2)デバイスの削除
(3)デバイスの属性変更
［追加(1)／削除(2)／変更(3)］：
> 1
Q．処理の対象となるデバイスの種別を次の番号から選択してください。
(1)disk　　（共有ディスク装置）
［デバイス種別］：
> 1
Q．追加／削除／変更するデバイスの名称を指定してください。
［デバイス名称］：
>/dev/vg01
コマンドを作成しました。：mondevice server1 -a disk /dev/vg01
Q．コマンドを実行しますか？
実行する場合は，［送信］キーを押してください。
>
コマンドを実行します。

（凡例）　>：ユーザの操作を示します。

monend（モニタモードのサーバの停止）

形式

monend サーバ識別名

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

モニタモードの実行サーバが停止した場合，その旨をHAモニタに連絡して系の監視を終了させ，対応する待機サーバを停止します。

オプション

サーバ識別名
停止する実行サーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（モニタモードのサーバの停止が完了しました）
0以外 | 異常終了

注意事項

monendコマンドはモニタモードのサーバにだけ有効です。

monendコマンドは実行系だけから実行できます。

moninfo（実行系でのサーバ引き継ぎ情報の設定／待機系でのサーバ引き継ぎ情報の参照・表示）

形式

moninfo サーバ識別名 {-p サーバ引き継ぎ情報|-g}

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

実行サーバと待機サーバとの間にペアが成立した際，ペアになる待機サーバに引き継がれるサーバ引き継ぎ情報を設定します。また，設定されているサーバ引き継ぎ情報を参照・表示します。

moninfoコマンドは，ユーザコマンド内でだけ発行できます。

オプション

サーバ識別名
ペアになる待機サーバに引き継がせたいサーバ引き継ぎ情報を設定する，実行サーバの識別名を指定します。または，設定されているサーバ引き継ぎ情報を参照・表示したい，サーバの識別名を指定します。

-p サーバ引き継ぎ情報
ペアになる待機サーバに引き継がせたいサーバ引き継ぎ情報を指定します。サーバ引き継ぎ情報は，半角のパス名で80文字まで指定できます。パス名の指定値については，「8.2.2(3)　構文要素記号」を参照してください。
-pオプションを指定した場合，サーバ引き継ぎ情報は省略できません。

-g
設定されているサーバ引き継ぎ情報を，参照または標準出力に表示します。

リターンコード

値 | 意味
0 | 正常終了（サーバ引き継ぎ情報の設定・参照・表示が完了しました）
0以外 | 異常終了

注意事項

設定したサーバ引き継ぎ情報は，実行サーバと待機サーバとの間にペアが成立した時点で引き継がれます。

サーバ引き継ぎ情報を半角で81文字以上指定した場合は，設定・引き継ぎは実行しません。

サーバ識別名で指定したサーバが待機サーバの場合は，設定・引き継ぎは実行しません。

サーバ引き継ぎ情報はサーバ単位で設定します。一つのサーバに設定できるサーバ引き継ぎ情報は，一つだけです。

サーバ引き継ぎ情報の設定は，実行サーバの起動処理開始時（online -s start）に実行してください。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN021-E，KAMN322-E，KAMN372-E，KAMN465-E

使用例

ユーザコマンド内でのmoninfoコマンドの使用例を示します。

例1

moninfo -pコマンドで，共有リソースとして使用したいエイリアスIPアドレスを設定します。

対象となるサーバの識別名：server1

エイリアスIPアドレス：1.2.3.4

サーバ引き継ぎ情報を設定するタイミング：実行サーバの起動処理開始時（online -s start）

ユーザコマンドの一部分を次に示します。この例では，実行サーバと待機サーバとの間にペアが成立した際，設定されたエイリアスIPアドレスが待機サーバに引き継がれます。

case "$2" in
"server1")
   case "$4" in
   "online")
       case "$5" in
       "-s")
       if [ "$6" = "start" ]
       then
#server1 online start!!
             moninfo server1 -p 1.2.3.4
       fi

（凡例）　太字：サーバ引き継ぎ情報の設定部分

例2

moninfo -gコマンドで，サーバ引き継ぎ情報を参照し，エイリアスIPアドレスを設定するコマンドに引き渡します。

対象となるサーバの識別名：server1

エイリアスIPアドレスを設定するコマンド名：/sbin/ifconfig

サーバ引き継ぎ情報を引き渡すタイミング：待機サーバの系切り替え処理開始時（standby -a start）

ユーザコマンドの一部分を次に示します。

case "$2" in
"server1")
   case "$4" in
   "standby")
       case "$5" in
       "-a")
       if [ "$6" = "start" ]
       then
#server1 system exchange start!!
              IPADDR='moninfo server1 -g'
              /sbin/ifconfig eth1:1 inet $IPADDR netmask 255.255.255.0 broadcast 1.2.3.255
              /sbin/arping -U -c 2 -I eth1 $IPADDR
              /bin/echo 0 > /proc/sys/net/ipv4/route/flush
       fi

（凡例）　太字：サーバ引き継ぎ情報の参照部分

monlink（HAモニタ間の手動接続）

形式

monlink

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

通常，HAモニタは起動時に自動で他系のHAモニタと接続します。

monlinkコマンドは，HAモニタが自動で他系のHAモニタと接続できなかった場合に，手動でHAモニタ間を接続します。

オプション

なし。

リターンコード

値 | 意味
0 | 正常終了（HAモニタ間の手動接続要求の受け付けが完了しました）
0以外 | 異常終了

注意事項

monlinkコマンド実行後は，monshow -cコマンドまたはmonpathコマンドで，他系と接続できたかどうかを確認してください。

monlistip（IPアドレスの検出）

形式

monlistip 出力ファイル名

実行できるユーザ

スーパユーザ

機能

コマンドを実行した系のHAモニタの，リセットパスのネットワーク上にある機器を検出し，そのIPアドレスの一覧を出力します。出力するIPアドレスは，このコマンドが送信したICMPエコーパケットに対し，応答のあったIPアドレスです。

このコマンドを実行する前に，カーネルパラメタがリセットパスのネットワークでのホスト部の数以上の値に設定されているかどうかを確認してください。詳細については，このコマンドの注意事項を参照してください。

オプション

出力ファイル名
IPアドレスの一覧を出力する，csvファイルの名称を指定します。指定した名称のファイルがすでに存在する場合は，ファイルの出力処理を中止します。ファイル名は必ず一意になるようにしてください。
csvファイルの出力例を次に示します。出力ファイル名に「IP_list.csv」を指定した場合の例を示します。

Search IP address in a range from 1.1.2.1 to 1.1.2.254
IP address,machine,HAmon,address,resetpath,SVP(or HRL),resetpath(2nd),HRL(2nd)
1.1.2.131
1.1.2.141
1.1.2.111
1.1.2.151
1.1.2.161
1.1.2.121
1.1.2.171
1.1.2.172

リターンコード

値 | 意味
0 | 正常終了（IPアドレスの検出が完了しました）
0以外 | 異常終了

メッセージ

コマンド実行時に標準エラー出力に出力されるメッセージを次の表に示します。

表9-4　monlistipコマンド実行時に標準エラー出力に出力されるメッセージ

メッセージ
意味
対策

Usage :aa....aa outfile
monlistipコマンドのオプションの指定に誤りがあります。
aa....aa：monlistipコマンド実行時のパス
指定したオプションを確認し，コマンドを再実行してください。

The specified file (aa....aa) already exists.
monlistipコマンドのオプションに指定した出力ファイル名のファイルがすでに存在します。
aa....aa：出力ファイル名
オプションに指定する出力ファイル名を変更するか，またはすでに存在する出力ファイル名のファイルを削除してください。

Settings of the reset path have not been configured.
リセットパスの設定が完了していません。
monlistipコマンドを実行した系のリセットパスの設定を完了させてください。
なお，マシンの機種がBladeSymphonyまたはHA8000以外の系でmonlistipコマンドを実行した場合にも，このメッセージが出力されます。その場合には，機種がBladeSymphonyまたはHA8000のマシンでmonlistipコマンドを実行してください。

An error occurred in the aa....aa system call.
Errno : bb....bb.
Information : cc....cc.
monlistipコマンド実行中にシステムコールのエラーが発生しました。
aa....aa：システムコール名
bb....bb：システムコールのerrno
cc....cc：詳細情報
システムコール名（aa....aa）がsendtoでシステムコールのerrno（bb....bb）が105の場合は，カーネルパラメタの設定に誤りがあることがあります。このコマンドの注意事項を参照してください。
このほかのエラーが発生した場合は，保守員に連絡してください。

The netmask cannot be acquired.
リセットパスのネットマスクの設定が取得できません。
このメッセージの前に出力されるエラーメッセージに従って，エラーの要因を取り除いてください。
このメッセージの前にエラーメッセージが出力されない場合は，monsetup -resetpathコマンドで指定したリセットパスのIPアドレスを確認し，誤りがあれば修正してください。

Processing will now stop.
エラーのため処理を中止しました。
このメッセージの前に出力されるエラーメッセージに従って，エラーの要因を取り除いたあと，monlistipコマンドを再実行してください。

注意事項

monlistipコマンドは，コマンドを実行するマシンの機種がBladeSymphonyまたはHA8000の場合に実行できます。

monlistipコマンドは，HAモニタの環境構築が完了している系で実行してください。

monlistipコマンドを実行すると，ネットワークに秒間20キロバイト程度の負荷が掛かります。トラフィックの少ない時間帯などに実行してください。

monlistipコマンドを実行する前に，次のカーネルパラメタがリセットパスのネットワークでのホスト部の数以上の値に設定されているかどうかを確認してください。カーネルパラメタの表示・変更は，OSのsysctlコマンドでできます。

変更するカーネルパラメタ

net.ipv4.neigh.default.gc_thresh3

指定値

リセットパスのネットワークでのホスト部の数以上の値を指定します。リセットパスのネットワークでのホスト部の数は，monlistipコマンド実行時に表示される，「調査対象のIPアドレスの総数」でも確認できます。

sysctlコマンドの実行例（アドレスクラスがクラスBの場合）

/sbin/sysctl -w net.ipv4.neigh.default.gc_thresh3= 65536

IPアドレスの検出には，最大で次の秒数が掛かります。

リセットパスのネットワークでのホスト部の数÷100×3（小数点以下切り上げ）

使用例

出力ファイル名に「IP_list.csv」を指定した場合の使用例を次に示します。

> monlistip IP_list.csv
Now processing.
100/254 39% complete.
200/254 78% complete.
254/254 100% complete.
Processing ended.

コマンド実行時に表示される項目とその意味を，次の表に示します。

表9-5　monlistipコマンド実行時に表示される項目

表示される項目
意味

Now processing.
コマンド処理の開始を示します。

aa....aa / bb....bb cc....cc% complete.
コマンド処理の進ちょくを示します。
aa....aa：調査が完了したIPアドレスの数
bb....bb：調査対象のIPアドレスの総数
cc....cc：調査が完了したIPアドレスの数の割合

Processing ended.
コマンド処理の終了を示します。

monmp（MPの状態表示）

形式

monmp [他系ホスト名]

実行できるユーザ

スーパユーザ

機能

MPの状態をチェックし，結果を表示します。MPやリセットパスの障害発生時および障害回復時に使用します。

表示される項目は次のとおりです。

host name：ホスト名

status：MPの状態

これらの項目で表示される内容とその意味を，次の表に示します。

表9-6　monmpコマンドで表示される項目の内容と意味

内容 | 意味
host name | status
ホスト名 | OK | 正常
NG | 異常（MPの異常やMP間を接続するパスの異常）
**nothing** | 他系と未接続

オプション

他系ホスト名
MPをチェックする，自ホストに接続された他ホストの名称を指定します。指定を省略した場合は，自ホストに接続しているすべてのホストをチェックします。

注意事項

MPのチェックには，最大で（ホスト数×45）秒掛かります。また，monmpコマンドの実行中は，HAモニタでの系のリセットが待たされるため，障害発生時の系切り替えが遅れます。コマンドは必要なときにだけ実行してください。

monmpコマンドは，コマンドを実行するマシンの機種がHA8500の場合に実行できます。

使用例

他系と接続している場合

> monmp
KAMN395-I MP Status Display
host name                         status
host1                             OK
host2                             NG

（凡例）　>：ユーザの操作を示します。

他系と接続していない場合

> monmp
KAMN395-I MP Status Display
host name                         status
**nothing**

（凡例）　>：ユーザの操作を示します。

monodrshw（サーバ順序制御の状態表示）

形式

monodrshw { -s サーバ識別名 | -g グループ名 }

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

親サーバを表示します。親サーバが定義されていないサーバには，"none"を表示します。

オプション

-s サーバ識別名
指定したサーバが稼働中の場合に，そのサーバの親サーバを表示します。指定したサーバが未稼働の場合は，メッセージKAMN322-Eを付加して表示します。また，指定したサーバがグループ化されていない場合は，メッセージKAMN944-Eを付加して表示します。

-g グループ名
指定したグループ内で稼働しているすべてのサーバについて，親サーバを表示します。指定したグループで，稼働中のサーバがない場合は，メッセージKAMN428-Eを付加して表示します。

リターンコード

値 | 意味
0 | 正常終了（サーバ順序制御の状態表示が完了しました）
0以外 | 異常終了

使用例

サーバ識別名を指定した場合で，サーバが稼働中のとき

> monodrshw -s server2
KAMN950-I Order Information
group name:groupA
alias:server2             parent:server1

（凡例）　>：ユーザの操作を示します。

グループ名を指定した場合

> monodrshw -g groupA
KAMN950-I Order Information
group name:groupA
alias:server1             parent:none
alias:server2             parent:server1
alias:server3             parent:server2
alias:server4             parent:server2
alias:server5             parent:none

（凡例）　>：ユーザの操作を示します。

monpath（監視パスの状態表示）

形式

monpath [-i] [チェック時間]

実行できるユーザ

スーパユーザ

機能

監視パスの状態をチェックし，その結果を表示します。monpathコマンドは，監視パスの障害発生時および障害回復時に使用します。

表示される項目は次のとおりです。

device name：監視パスのTCP/IPのホスト名

host name：他系のホスト名

status：他系との通信状態

現在使用している監視パスには，他系との通信状態のあとに「*」が表示されます。監視パスに異常がある場合，host nameとstatusの列に監視パスの状態が表示されます。

これらの項目で表示される内容とその意味を，次の表に示します。

表9-7　monpathコマンドで表示される項目の内容と意味

内容
意味

device name
host name
status

監視パスのTCP/IPのホスト名
他系のホスト名
OK
正常

NO RESPONSE
次のような理由による応答なし

系のスローダウン

他系のHAモニタがない

監視パスの障害や切断

**not connect**
他系のHAモニタと未接続

**open err**
オープンエラー

**LAN err**
送信エラー

オプション

-i
-iオプションを指定しない場合の情報に加えて，他系のTCP/IP LANの情報を表示します。
加えて表示される項目は次のとおりです。

host：他系の監視パスのTCP/IPのホスト名
/etc/hostsファイルに指定した，他系の監視パスのTCP/IPのホスト名が表示されます。TCP/IPのホスト名を指定していない場合は，"----"が表示されます。

(IP_address)：他系の監視パスのIPアドレス
/etc/hostsファイルに指定した他系の監視パスのTCP/IPのホスト名に対応するIPアドレスが表示されます。

チェック時間
監視パスをチェックする時間を指定します。指定の単位は「秒」で，3から30秒の範囲で指定できます。指定を省略した場合は，3秒を仮定します。
チェック時に監視パスに1本でも障害があった場合は，指定したチェック時間の間隔で監視パスを再チェックします。再チェックの回数は，HAモニタの環境設定のpathpatrol_retryオペランドに指定した回数になります。
通常のチェック時間は3秒で十分ですが，（ホスト数×監視パス数）が多い場合や複数のサーバの開始処理中はチェック時間を大きくしてください。

リターンコード

値 | 意味
0 | 正常終了（監視パスの状態表示が完了しました）
0以外 | 異常終了

注意事項

チェックの対象となる監視パスの範囲は，自系のTCP/IPのLANアダプタから他系のTCP/IPのLANアダプタまでです。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN206-E，KAMN320-E，KAMN393-E

使用例

次に示す系切り替え構成で，系1（host1）でmonpathコマンドを実行した例を示します。

図9-1　monpathコマンドを使用する系切り替え構成例

-iオプションを指定しない場合で，系3（ホスト名がhost3）の監視パス（path32）に障害が発生しているとき

> monpath
KAMN390-I Path status Display
device name  host name  status
path11       host2      OK  *
            host3      OK  *
path12       host2      OK
            host3      NO RESPONSE

（凡例）　>：ユーザの操作を示します。

-iオプションを指定した場合で，系3（ホスト名がhost3）の監視パス（path32）が/etc/hostsファイルに指定されていないとき

> monpath -i
KAMN390-I Path status Display
device name  host name  host   (IP_address)  status
path11       host2      path21 (100.2.1.132) OK  *
            host3      path31 (100.2.1.133) OK  *
path12       host2      path22 (100.2.2.132) OK
            host3      ----   (100.2.2.133) OK

（凡例）　>：ユーザの操作を示します。

monresbgn（リソースサーバの起動）

形式

monresbgn リソースサーバ識別名

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

リソースサーバを起動します。

オプション

リソースサーバ識別名
起動するリソースサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（リソースサーバの起動要求の受け付けが完了しました）
0以外 | 異常終了

注意事項

monresbgnコマンドは，リソースサーバにだけ使用できます。

通常，リソースサーバは，リソースサーバを親指定しているサーバの起動時に自動起動されます。monresbgnコマンドは，必要に応じて実行してください。

monresend（実行中のリソースサーバの停止）

形式

monresend リソースサーバ識別名

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

実行中のリソースサーバを停止します。実行中のリソースサーバが停止した場合，対応する待機中のリソースサーバがあれば自動的に停止します。

オプション

リソースサーバ識別名
停止する実行中のリソースサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（実行中のリソースサーバの停止が完了しました）
0以外 | 異常終了

注意事項

monresendコマンドは，実行中のリソースサーバにだけ使用できます。また，monresendコマンドは，実行系だけから実行できます。

通常，リソースサーバは，リソースサーバを親指定しているすべてのサーバが停止した際に自動停止されるため，monresendコマンドを使用する必要はありません。

monresendコマンドによってリソースサーバが停止すると，リソースが切り離されます。このため，リソースを使用するサーバが起動していないことを十分確認の上，コマンドを実行してください。なお，リソースサーバを親指定しているサーバが稼働している場合，monresendコマンドは失敗します。

monressbystp（待機中のリソースサーバの停止）

形式

monressbystp リソースサーバ識別名

実行できるユーザ

スーパユーザ

機能

待機中のリソースサーバ，または連動系切り替え待ち状態になった待機中のリソースサーバを停止します。

オプション

リソースサーバ識別名
停止する待機中のリソースサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（待機中のリソースサーバの停止が完了しました）
0以外 | 異常終了

注意事項

monressbystpコマンドは，待機中のリソースサーバにだけ使用できます。また，monressbystpコマンドは，待機系だけから実行できます。

通常，待機中のリソースサーバは，待機中のリソースサーバを親指定しているすべての待機サーバが停止した際に自動停止されるため，monressbystpコマンドを使用する必要はありません。

リソースサーバでだけ系切り替えができる状態になっている場合で，待機中のリソースサーバだけを停止したいときなどに使用します。なお，待機中のリソースサーバを親指定している待機サーバが稼働している場合，monressbystpコマンドは失敗します。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN221-E，KAMN322-E，KAMN329-E，KAMN465-E，KAMN958-E，KAMN963-E

monrp（リセットパスの状態表示）

形式

monrp [他系ホスト名]

実行できるユーザ

スーパユーザ

機能

SVPと通信することでリセットパスの状態をチェックし，結果を表示します。SVPやリセットパスの障害発生時および障害回復時に使用します。

表示される項目は次のとおりです。

host name：ホスト名

status：リセットパスの状態

これらの項目で表示される内容とその意味を，次の表に示します。

表9-8　monrpコマンドで表示される項目の内容と意味

内容 | 意味
host name | status
ホスト名 | OK | 正常
NG | 異常（SVPの異常やSVP間を接続するパスの異常）
OK(Partition) | 物理パーティションをリセット可能
NG(Partition) | 物理パーティションをリセット不可能
**nothing** | 他系と未接続

オプション

他系ホスト名
リセットパスをチェックする，自ホストに接続された他ホストの名称を指定します。指定を省略した場合は，自ホストに接続しているすべてのホストをチェックします。

リターンコード

値 | 意味
0 | 正常終了（リセットパスの状態表示が完了しました）
0以外 | 異常終了

注意事項

リセットパスのチェックには，最大で（ホスト数×15）秒掛かります。また，monrpコマンドの実行中は，HAモニタでの系のリセットが待たされるため，障害発生時の系切り替えが遅れます。コマンドは必要なときにだけ実行してください。

monrpコマンドは，コマンドを実行するマシンの機種がBladeSymphonyまたはHA8000の場合に実行できます。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN320-E，KAMN392-E，KAMN397-E，KAMN398-E，KAMN399-E，KAMN460-E

使用例

他系と接続している場合

> monrp
KAMN395-I Reset Path Status Display
host name                         status
host1                             OK          
host2                             NG          

（凡例）　>：ユーザの操作を示します。

他系と接続していない場合

> monrp
KAMN395-I Reset Path Status Display
host name                         status
**nothing**

（凡例）　>：ユーザの操作を示します。

他系と接続している場合（物理パーティションリセット機能使用時）

> monrp
KAMN395-I Reset Path Status Display
host name                         status
host1                             OK
                                 OK(Partition)
host2                             NG
                                 OK(Partition)

（凡例）　>：ユーザの操作を示します。

monsbystp（待機サーバの停止）

形式

monsbystp サーバ識別名

実行できるユーザ

スーパユーザ

機能

待機中の待機サーバ，または連動系切り替え待ち状態になった待機サーバを停止します。再起動待ち状態の実行サーバに対応している待機サーバをmonsbystpコマンドで停止させた場合は，再起動待ち状態の実行サーバも自動で停止させます。

マルチスタンバイ機能を使用する場合は，コマンドを実行した系の待機サーバだけを停止させます。また，待機サーバの状態によって，次のとおり動作が異なります。

連動系切り替え待ち状態の待機サーバをmonsbystpコマンドで停止させたときは，対応しているすべての系の待機サーバも自動で停止させます。

再起動待ち状態の実行サーバに対応している待機サーバをmonsbystpコマンドで停止させたときは，ほかに待機中の待機サーバがなければ，再起動待ち状態の実行サーバも自動で停止させます。

オプション

サーバ識別名
停止するサーバの識別名を指定します。

リターンコード

値 | 意味
0 | 正常終了（待機サーバの停止が完了しました）
0以外 | 異常終了

注意事項

monsbystpコマンドは待機系だけから実行できます。

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。
KAMN323-E，KAMN329-E，KAMN465-E，KAMN957-E

monsetup（HAモニタの環境設定）

形式

HAモニタの起動・停止方法の設定変更

monsetup [{-start|-stop}]

リセットパスの設定

monsetup -resetpath

SSH接続の詳細設定

monsetup -resetpath ssh

HAモニタ Extensionの機能の設定・設定状態の表示

monsetup -ex [sysmax {on|off}]

実行できるユーザ

スーパユーザ

機能

HAモニタの起動・停止方法の設定変更

通常，HAモニタはシステム起動時に自動起動され，システム停止時に自動停止されるよう設定されています。

monsetupコマンドは，monstartコマンドやmonstopコマンドで起動・停止できるよう，HAモニタの起動・停止方法の設定を変更します。また，オプションの指定を省略した場合は，起動・停止方法の設定情報を表示します。

表示される項目を次に示します。

Start mode：起動方法の設定

Stop mode：停止方法の設定

リセットパスの設定

リセットパスで使用するIPアドレスなどを対話形式で設定するか，または現在の設定を表示します。リセットパスの設定は，マシンの機種がBladeSymphonyまたはHA8000の場合に実行できます。

SSH接続の詳細設定

VMware ESXiで仮想化する場合は，VMware ESXiに対するSSH接続の詳細を設定します。VMware ESXi接続用のリセットパス上に，無通信監視時間を設定している機器が存在する場合は，この設定が必要です。

HAモニタ Extensionの機能の設定・設定状態の表示

HAモニタ Extensionの機能を使用するかどうか設定します。また，HAモニタ Extensionの機能の設定状態も表示できます。

オプション

HAモニタの起動・停止方法の設定変更

起動方法の設定と停止方法の設定の，どちらを変更するかを指定します。指定を省略した場合は，起動・停止方法の設定情報を表示します。

-start
起動方法の設定を変更します。設定が「auto（自動起動）」の場合は「manual（monstartコマンドによる起動）」に，「manual」の場合は「auto」に変更します。

-stop
停止方法の設定を変更します。設定が「auto（自動停止）」の場合は「manual（monstopコマンドによる停止）」に，「manual」の場合は「auto」に変更します。

リセットパスの設定

-resetpath
対話形式で，リセットパスを使用するのに必要な設定をします。使用しているマシンの機種によって，設定内容が異なります。
使用しているマシンの機種がBladeSymphonyの場合，設定時に表示される「スイッチ＆マネジメントモジュール」とは，SVPおよびSVPを管理するハードウェアのことです。詳細はハードウェアのマニュアルを参照してください。BladeSymphonyの場合に設定する内容を次に示します。

システムのパーティション名
スイッチ＆マネジメントモジュールのSVPコマンドモードのHAコマンドで設定した，システム内のCPUモジュールのパーティション名と同じ名称を設定してください。

LPAR名称
日立サーバ仮想化機構を利用して，LPARを稼働させる場合だけ設定します。HVM制御スクリーンで設定したLPAR名称と同じ名称を指定してください。
なおLPAR名称に"FullSystemPartition"は指定しないでください。

リセットパスのIPアドレスおよびポート番号
リセットパスのネットワークに属する任意のIPアドレスを設定してください。ポート番号は各系で同じ値とし，未使用の番号を5001から65535の範囲で設定します。ただし，スイッチ＆マネジメントモジュールのIPアドレスおよびポート番号とは異なる値にしてください。

スイッチ＆マネジメントモジュールのIPアドレス
スイッチ＆マネジメントモジュールのSVPコマンドモードのLCコマンドで設定した，"SVP IP address"と同じ値を設定してください。N+Mコールドスタンバイ構成の場合は，"auto"を設定してください。

スイッチ＆マネジメントモジュールのポート番号
ポート番号には，未使用の番号を5001から65535の範囲で設定します。スイッチ＆マネジメントモジュールのSVPコマンドモードのHAコマンドで設定した，"Port no"と同じ値を設定してください。

使用しているマシンの機種がHA8000の場合，設定時に表示される「スイッチ＆マネジメントモジュール」とは，SVPのことです。HA8000の場合に設定する内容を次に示します。

システムのパーティション名
任意の名称を1から31文字の英数字で指定してください。ここで指定した値は，HAモニタとSVPで系を識別するためのインタフェースとして使用されます。

リセットパスのIPアドレスおよびポート番号
リセットパスのネットワークに属する任意のIPアドレスを設定してください。ポート番号には，未使用の番号を5001から65535の範囲で設定します。ただし，スイッチ＆マネジメントモジュールのIPアドレスおよびポート番号とは異なる値にしてください。

スイッチ＆マネジメントモジュールのIPアドレス
SVPマイクロプログラム付属のHAモニタ用設定ユーティリティで設定した，"SVP IP Address"と同じ値を設定してください。

スイッチ＆マネジメントモジュールのポート番号
ポート番号には，未使用の番号を5001から65535の範囲で設定します。SVPマイクロプログラム付属のHAモニタ用設定ユーティリティで設定した，"Port no"と同じ値を設定してください。

また，VMware ESXiで仮想化する場合にだけ設定する内容を次に示します。

仮想マシン名
VMware ESXiで管理する，仮想マシン名を設定してください。VMware ESXiで仮想マシンを作成したときに設定した情報です。

VMware ESXiのIPアドレス
VMware ESXiの管理用IPアドレスを設定してください。

VMware ESXiのSSH接続用のポート番号
HAモニタがVMware ESXiにSSH接続をするときに使用するポート番号を設定してください。"default"と設定すると，22が使用されます。

VMware ESXiのSSH接続用の認証パスワード
自系のVMware ESXiにSSH接続する際の認証に必要なパスワードを設定してください。VMware ESXi上に設定した，rootユーザのパスワードを設定します。
なお，設定および設定の表示の際は，パスワードは表示されません。

マシンアドレス
物理パーティションを特定するための任意の数値を設定してください。0～9999の範囲で設定します。
同一物理パーティション上の系には，すべて同じマシンアドレスを設定してください。異なる物理パーティション上の系には，物理パーティションごとに固有のマシンアドレスを設定してください。なお，システム内に互いに監視し合わない系切り替え構成が複数あり，かつそれらがリセットパスを共用する場合，すべての物理パーティションでマシンアドレスがそれぞれ固有となるように設定してください。複数の物理パーティションで同じマシンアドレスを設定すると，HAモニタが誤動作するおそれがあります。

SSH接続の詳細設定

-resetpath ssh
対話形式で，HAモニタがVMware ESXiにSSH接続するための詳細な設定をします。VMware ESXiで仮想化する場合にだけ設定してください。
VMware ESXi接続用のリセットパスにファイアウォールまたはルータを使用している場合，HAモニタとVMware ESXi間の無通信状態が続くと，ファイアウォールまたはルータの機能でVMware ESXiへのSSH接続が切断されることがあります。HAモニタがVMware ESXiに対して行うSSH接続では，一定期間以上無通信状態が続かないように，VMware ESXiに対して応答を要求するパケット（接続維持パケット）を送信します。VMware ESXiからの応答がない場合は，SSH接続を切断します。
設定する内容を次に示します。

接続維持パケットの送信間隔
接続維持パケットを送信する間隔を設定してください。ファイアウォールまたはルータの無通信監視時間の設定よりも短くなるように，0～2147483647の範囲で設定します。単位は秒です。設定しない場合は，デフォルト値（60）で動作します。
0を設定すると，接続維持パケットは送信しません。

接続維持パケットの送信回数
接続維持パケットを送信する回数を設定してください。0～2147483647の範囲で設定します。設定しない場合は，デフォルト値（3）で動作します。
0を設定すると，接続維持パケットは送信しません。
なお，設定した回数分の接続維持パケットを送信しても，VMware ESXiからの応答がない場合，SSH接続が切断されます。

HAモニタ Extensionの機能の設定・設定状態の表示

-ex
HAモニタ Extensionの機能を使用する場合に指定します。以降に説明するオペランドを省略した場合，HAモニタ Extensionの機能の設定状態を表示します。

sysmax
HAモニタ Extensionの機能の設定，および解除をします。以降に示すオプションとあわせて使用します。

on
HAモニタ Extensionの機能を使用できるようにします。具体的には，次の設定ができるようになります。

HAモニタの環境設定で，hostmaxオペランドが指定できるようになります。これに伴い，系の最大数を33以上に設定できます。

HAモニタの環境設定で，servmaxオペランドに129以上の値を指定できるようになります。

off
HAモニタ Extensionの機能の設定を解除します。

HAモニタの環境設定で，hostmaxオペランドを指定できなくなります。

HAモニタの環境設定で，servmaxオペランドに129以上の値を指定できなくなります。

リターンコード

値 | 意味
0 | 正常終了（HAモニタの環境設定が完了しました）
0以外 | 異常終了

注意事項

HAモニタが稼働中の場合，リセットパスの設定，およびHAモニタ Extensionの機能の設定はできません。HAモニタが稼働している場合は，停止してから再度monsetupコマンドを実行してください。

HAモニタ Extensionの機能の設定・設定状態の表示をするには，HAモニタ Extensionをインストールしてください。

使用例

HAモニタの起動・停止方法の設定情報の表示

>monsetup
Start mode : auto   Stop mode : auto

（凡例）　>：ユーザの操作を示します。

HAモニタの起動方法の設定変更情報の表示

>monsetup -start
Start mode : manual

（凡例）　>：ユーザの操作を示します。

HAモニタの停止方法の設定変更情報の表示

>monsetup -stop
Stop  mode : auto

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（x86）の場合で，HA8000のとき，またはBladeSymphonyでLPARを稼働させないとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
---> 1
機種を選択してください。
1. HA8000または，BladeSymphony
2. BladeSymphony(LPAR)
3. VMware ESXi上の仮想マシン
---> 1
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
N+Mコールドスタンバイ連携機能を使用する場合は，autoと入力してください。
現在の設定：未設定
--->192.168.0.2
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->2
スイッチ＆マネジメントモジュールを使用しています。
パーティション名...............................: MS0001
リセットパスのIPアドレス.......................: 192.168.0.1
リセットパスのポート番号.......................: 10000
スイッチ＆マネジメントモジュールのIPアドレス...: 192.168.0.2
スイッチ＆マネジメントモジュールのポート番号...: 15000

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（IPF）の場合で，BladeSymphonyでLPARを稼働させないとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
---> 1
機種を選択してください。
1. BladeSymphony
2. BladeSymphony(LPAR)
9. 上記以外
---> 1
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.2
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（x86）の場合で，BladeSymphonyでLPARを稼働させるとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
---> 1
機種を選択してください。
1. HA8000または，BladeSymphony
2. BladeSymphony(LPAR)
3. VMware ESXi上の仮想マシン
---> 2
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタが稼動するシステムのLPAR名称を入力してください。
現在の設定：未設定
--->LPAR1
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
N+Mコールドスタンバイ連携機能を使用する場合は，autoと入力してください。
現在の設定：未設定
--->192.168.0.2
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->2
スイッチ＆マネジメントモジュールを使用しています。
パーティション名...............................: MS0001
LPAR名.........................................: LPAR1
リセットパスのIPアドレス.......................: 192.168.0.1
リセットパスのポート番号.......................: 10000
スイッチ＆マネジメントモジュールのIPアドレス...: 192.168.0.2
スイッチ＆マネジメントモジュールのポート番号...: 15000

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（IPF）の場合で，BladeSymphonyでLPARを稼働させるとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
---> 1
機種を選択してください。
1. BladeSymphony
2. BladeSymphony(LPAR)
9. 上記以外
---> 2
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタが稼動するシステムのLPAR名称を入力してください。
現在の設定：未設定
--->LPAR1
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.2
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（x86）の場合で，VMware ESXiで仮想化するとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
---> 1
機種を選択してください。
1. HA8000または，BladeSymphony
2. BladeSymphony(LPAR)
3. VMware ESXi上の仮想マシン
---> 3
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.2
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
HAモニタが稼動する仮想マシンの名称を入力してください。
現在の設定：未設定
--->VM0001
VMware ESXiのIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.3
VMware ESXiのSSH接続用のポート番号を入力してください。
SSH接続用ポート番号(22)を使用する場合は，"default"を入力してください。
値を入力しなかった場合は現在の設定を使用します。現在の設定：default
--->
VMware ESXiのSSH接続用の認証パスワードを入力してください。
現在の設定：未設定
--->
再度パスワードを入力してください。
--->
HAモニタが稼動するマシンのマシンアドレスを入力してください。
現在の設定：未設定
--->1
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->2
スイッチ＆マネジメントモジュールを使用しています。
パーティション名...............................: MS0001
リセットパスのIPアドレス.......................: 192.168.0.1
リセットパスのポート番号.......................: 10000
スイッチ＆マネジメントモジュールのIPアドレス...: 192.168.0.2
スイッチ＆マネジメントモジュールのポート番号...: 15000
仮想マシン名...................................: VM0001
VMware ESXiのIPアドレス........................: 192.168.0.3
VMware ESXiのポート番号........................: default
VMware ESXiのパスワード........................: 設定済み
マシンアドレス.................................: 1

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

SSH接続の詳細設定（OSがLinux（x86）の場合で，VMware ESXiで仮想化するとき）

> monsetup -resetpath ssh
 SSH接続関連の設定を行います。
設定を中断したい場合は，[CTRL]+[D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->1
接続維持パケットの送信間隔を入力してください。（単位：秒）
デフォルト設定値 (60)を使用する場合は，"default"を指定してください。
値を入力しなかった場合は現在の設定を使用します。現在の設定：default
--->30
接続維持パケットの送信回数を入力してください。（単位：回）
デフォルト設定値 (3)を使用する場合は，"default"を指定してください。
値を入力しなかった場合は現在の設定を使用します。現在の設定：default
--->2
設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->2
接続維持パケットの送信間隔（単位：秒）.........: 30
接続維持パケットの送信回数（単位：回）.........: 2

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

リセットパスの設定（OSがLinux（x86）の場合で，N+Mコールドスタンバイ構成のとき）

> monsetup -resetpath
 システムリセットのためのリセットパスの設定を行います。
設定を中断したい場合は，[CTRL] + [D]キーを押してください。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->1
機種を選択してください。
1. HA8000または，BladeSymphony
2. BladeSymphony(LPAR)
3. VMware ESXi上の仮想マシン
--->1
HAモニタが稼動するシステムのパーティション名を入力してください。
現在の設定：未設定
--->MS0001
HAモニタがリセットパスに使用するIPアドレスを入力してください。
現在の設定：未設定
--->192.168.0.1
HAモニタがリセットパスに使用するポート番号を入力してください。
現在の設定：未設定
--->10000
スイッチ＆マネジメントモジュールのIPアドレスを入力してください。
N+Mコールドスタンバイ連携機能を使用する場合は，autoと入力してください。
現在の設定：未設定
--->auto
スイッチ＆マネジメントモジュールのポート番号を入力してください。
現在の設定：未設定
--->15000
リセットパスの設定が完了しました。

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->2
スイッチ＆マネジメントモジュールを使用しています。
パーティション名...............................: MS0001
リセットパスのIPアドレス.......................: 192.168.0.1
リセットパスのポート番号.......................: 10000
スイッチ＆マネジメントモジュールのIPアドレス...: auto
スイッチ＆マネジメントモジュールのポート番号...: 15000

実行する処理を番号で選択してください。
1. 設定を行う
2. 現在の設定を表示する
3. 終了
--->3
コマンドを終了します。

（凡例）　>：ユーザの操作を示します。

HAモニタ Extensionの機能の設定

> monsetup -ex sysmax on
sysmax : on

（凡例）　>：ユーザの操作を示します。

HAモニタ Extensionの機能の設定解除

> monsetup -ex sysmax off
sysmax : off

（凡例）　>：ユーザの操作を示します。

HAモニタ Extensionの機能の設定状態の表示

> monsetup -ex
sysmax : on

（凡例）　>：ユーザの操作を示します。

monshow（サーバと系の状態表示）

形式

サーバの状態表示

monshow [サーバ識別名]

系の状態表示

monshow -c

サーバグループの状態表示

monshow -g [グループ名]

共有リソース情報の表示

monshow -d [サーバ識別名]

リソースサーバの状態表示

monshow -r

マルチスタンバイ機能使用時のサーバの優先度表示

monshow -p [サーバ識別名]

サーバ障害監視時間表示

monshow -t [サーバ識別名]

モニタモードのプログラムの状態表示

monshow -u [サーバ識別名]

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

サーバの状態表示

コマンドを実行した系（自系）で稼働中のサーバと，そのサーバと対になっている系（他系）のサーバの状態が表示されます。停止しているサーバは，表示されません。マルチスタンバイ機能を使用している場合は，他系で稼働中のサーバがすべて表示されます。表示される項目は次のとおりです。

Own host name：自系のホスト名

Own Server：自系のサーバの情報
自系のサーバの情報として，次の情報が表示されます。

Alias：自系のサーバの識別名

Status：自系のサーバの状態
表示される自系のサーバの状態を，次の表に示します。

表9-9　自系のサーバの状態

状態 | 意味
ONL | 実行処理中
SBY | 待機処理中
(ONL) | 実行サーバとして起動処理中
(SBY) | 待機サーバとして起動処理中
*ONL* | 再起動待ち状態
*SBY* | 実行サーバの起動待ち状態，またはリソースサーバの起動待ち状態
ONL?? | 系切り替え待ち状態
SBY?? | 連動系切り替え待ち状態
ONL>> | 実行サーバの停止処理中
SBY>> | 待機サーバの停止処理中

Pair Server：他系のサーバの情報
他系のサーバの情報として，次の情報が表示されます。

Status：他系のサーバの状態
表示される他系のサーバの状態を，次の表に示します。

表9-10　他系のサーバの状態

状態 | 意味
ONL | 実行処理中
SBY | 待機処理中
(ONL) | 実行サーバとして起動処理中
(SBY) | 待機サーバとして起動処理中
*ONL* | 再起動待ち状態
ONL?? | 系切り替え待ち状態
SBY?? | 連動系切り替え待ち状態

Host name：他系のホスト名

KAMN360-I ---------------- Detailed Information ----------------：詳細情報メッセージ
次のメッセージの幾つかがコマンドの詳細情報として表示されます。
KAMN242-D，KAMN243-D，KAMN244-D，KAMN364-D，KAMN423-E，KAMN931-I，KAMN932-I，KAMN936-I

系の状態表示

自系（自ホスト）と，接続中の他系（他ホスト）の状態が表示されます。表示される項目は次のとおりです。

Host name：ホスト名

Host address：ホストアドレス

Patrol time：系障害監視時間

サーバグループの状態表示

コマンドを実行した系（自系）で稼働中のグループ化したサーバ（サーバグループ）の状態が表示されます。表示される項目は次のとおりです。

Own host name：自系のホスト名

Group name：サーバグループのグループ名

また，サーバグループ内のサーバごとに，次の項目が表示されます。グループ内にリソースサーバがある場合は，リソースサーバについても表示されます。

Alias：サーバ識別名

Status：次の情報が表示されます。

サーバが連動系切り替えができる状態かどうか
possible：できる
impossible：できない

切り替え種別
exchange：切り替え可能
no_exchange cancel：切り替え不可

実行サーバだけを表示する場合には切り替え種別が表示されますが，待機サーバを表示する場合には切り替え種別は表示されません。

共有リソース情報の表示

コマンドを実行した系（自系）で稼働中のサーバが使用している，共有リソースの情報が表示されます。表示される項目は次のとおりです。

Own host name：自系のホスト名

Server：自系のサーバ識別名

***　　DISK　information　　***：共有ディスクの情報
表示される共有ディスクの情報を次に示します。

ボリュームグループのスペシャルファイル名

共有リソースの接続失敗時にサーバの起動を中止する機能の使用有無

ボリュームグループのオンライン化時のオプション

***　File　system　information　***：ファイルシステムの情報
表示されるファイルシステムの情報を次に示します。

ファイルシステムの名称

マウント先ディレクトリ

マウントオプション

***　　HABST　information　　***：制御グループID

リソースサーバの状態表示

「サーバの状態表示」に加えて，リソースサーバの状態が表示されます。

マルチスタンバイ機能使用時のサーバの優先度表示

マルチスタンバイ機能を使用している場合，「サーバの状態表示」に加えて，すべてのサーバまたは指定したサーバの，系別の優先度が表示されます。"status"のあとに，次の項目が表示されます。

pri：各系の優先度

サーバ障害監視時間表示

コマンドを実行した系で稼働しているサーバの，サーバ障害監視時間が表示されます。

表示される項目は次のとおりです。

Own host name：自系のホスト名

Alias：サーバ識別名

Patrol time：サーバ障害監視時間
サーバ障害監視時間を指定していないサーバでは，"---"が表示されます。

モニタモードのプログラムの状態表示

コマンドを実行した系（自系）で稼働中の，モニタモードのプログラム管理機能を使用するプログラムの状態が表示されます。

Alias：サーバ識別名

Program Alias：モニタモードのプログラム識別名

Status：モニタモードのプログラムの状態
表示されるモニタモードのプログラムの状態を，次の表に示します。

表9-11　モニタモードのプログラムの状態

状態 | 意味
(ACT) | プログラムの起動処理中
ACT | プログラムの起動完了
ACT>> | プログラムの停止処理中

なお，停止しているプログラムの状態は表示されません。

Patrol time：プログラムのスローダウン監視時間
プログラムのスローダウン監視時間を指定していないUAPでは，"---"が表示されます。

オプション

オプションに何も指定しない場合は，サーバの状態が表示されます。

サーバの状態表示

サーバ識別名
状態が表示されるサーバの識別名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのサーバの状態が表示されます。

系の状態表示

-c
系の状態が表示されます。

サーバグループの状態表示

-g
サーバグループの状態が表示されます。
グループ内にリソースサーバがある場合は，リソースサーバについても表示されます。

グループ名
状態を表示するサーバグループのグループ名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのサーバグループの状態が表示されます。

共有リソース情報の表示

-d
共有リソースの情報が表示されます。

サーバ識別名
共有リソースの情報を表示するサーバの識別名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのサーバの共有リソース情報が表示されます。

リソースサーバの状態表示

-r
「サーバの状態表示」に加えて，リソースサーバの状態が表示されます。

マルチスタンバイ機能使用時のサーバの優先度表示

-p
マルチスタンバイ機能を使用している場合，すべてのサーバまたは指定したサーバの，系別の優先度が表示されます。

サーバ識別名
状態および優先度を表示するサーバの識別名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのサーバの状態および優先度が表示されます。他系のサーバの情報が表示される順番は，系やサーバの起動順で決定されます。常に同じ順番では表示されません。

サーバ障害監視時間表示

-t
monshowコマンドを実行した系で稼働しているサーバの，サーバ障害監視時間が表示されます。

サーバ識別名
監視時間を表示するサーバの識別名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのサーバのサーバ障害監視時間が表示されます。

モニタモードのプログラムの状態表示

-u
monshowコマンドを実行した系で稼働しているモニタモードのプログラム管理機能を使用するプログラムの状態が表示されます。

サーバ識別名
プログラムの状態を表示するサーバの識別名を指定します。省略時は，コマンドを実行した系で稼働中の，すべてのプログラムの状態が表示されます。

リターンコード

値 | 意味
0 | 正常終了（サーバと系の状態表示が完了しました）
0以外 | 異常終了

注意事項

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。

KAMN320-E，KAMN322-E，KAMN428-E

使用例

サーバの状態表示

> monshow
KAMN213-I Own host name : host1
    Own servers           Pair servers
    Alias     Status      Status    Host name
    server1    ONL         SBY      host2
    server2    SBY        (ONL)     host2
    server3   *SBY*
    server4    ONL??
    server5   *ONL*        SBY      host2
KAMN360-I ---------------- Detailed Information ----------------
KAMN243-D 自ホスト：host1でシステムリセットができないか，又は異常終了したサーバがあります。実行サーバ：server3は他ホストで起動している可能性があります。起動種別を待機サーバに変更し起動待ち状態にしました。
KAMN364-D サーバ：server4はシステムリセットができないため系切り替え待ち状態にします。

（凡例）　>：ユーザの操作を示します。

サーバの状態表示（マルチスタンバイ機能使用時）

> monshow
KAMN213-I Own host name : host1
    Own servers           Pair servers
    Alias     Status      Status    Host name
    server1    ONL         SBY      host3
                           SBY      host2
                           SBY      host4
    server2    ONL         SBY      host2
    server3   *SBY*
    server4    SBY        (SBY)     host4
                          (ONL)     host2
                           SBY      host3

（凡例）　>：ユーザの操作を示します。

他系のサーバの情報が表示される順番は，系やサーバの起動順で決定されます。常に同じ順番では表示されません。

系の状態表示

> monshow -c
KAMN335-I Connected host information
    Host name                           Host address     Patrol time
    host1                                     100             10
    host2                                     200             10

（凡例）　>：ユーザの操作を示します。

サーバグループの状態表示

> monshow -g
KAMN213-I Own host name : host1
     Group name : groupA
        Alias : server1   Status :   possible       exchange
        Alias : server2   Status :   possible    no_exchange       cancel
     Group name : groupB
        Alias : server3   Status : impossible       exchange
        Alias : server4   Status : impossible    no_exchange       cancel

（凡例）　>：ユーザの操作を示します。

共有リソース情報の表示

> monshow -d
KAMN213-I Own host name : host1
Server  :  server1
    ***   DISK   information   ***
    -NAME----------------------------
     /dev/vg01
       neck
       on_opt="-a y -q n"
    ***   File system information  ***
    -NAME----------------------------
     /dev/vg01/lv_vxfs1
       mount dir=/vxfs1
       mount opt=-o log
    ***   HABST  information   ***
    -NAME----------------------------
     0

（凡例）　>：ユーザの操作を示します。

リソースサーバの状態表示（"ressrv0"がリソースサーバ識別名称の場合）

> monshow -r
KAMN213-I Own host name : host1
    Own servers           Pair servers
    Alias     Status      Status    Host name
    ressrv0    ONL
    server1    ONL
    server2    ONL

（凡例）　>：ユーザの操作を示します。

マルチスタンバイ機能使用時のサーバの優先度表示

> monshow -p
KAMN213-I Own host name : host1
    Own servers               Pair servers
    Alias     Status   pri    Status   pri   Host name
    server1    ONL     0       SBY     2     host3
                               SBY     1     host2
                               SBY     3     host4
    server2    ONL     0       SBY     1     host2
    server3    SBY     1       ONL     0     host3
    server4    SBY     1       SBY     3     host4
                               ONL     0     host2
                               SBY     2     host3

（凡例）　>：ユーザの操作を示します。

他系のサーバの情報が表示される順番は，系やサーバの起動順で決定されます。常に同じ順番では表示されません。

サーバ障害監視時間表示

> monshow -t
KAMN213-I   Own host name : host1
    Alias     Patrol time
    server1        60
    server2         5
    server3       600
    server4       ---

（凡例）　>：ユーザの操作を示します。

モニタモードのプログラムの状態表示

> monshow -u
KAMN213-I Own host name : host1
    Alias     Program Alias  Status   Patrol time
    server1   UAP1            ACT        3600
              UAP2           (ACT)         60
    server2   UAP3            ACT>>      ----

（凡例）　>：ユーザの操作を示します。

monstart（HAモニタの起動）

形式

monstart

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

HAモニタを起動します。

オプション

なし。

リターンコード

値 | 意味
0 | 正常終了（HAモニタの起動が完了しました）
0以外 | 異常終了

monstop（HAモニタの停止）

形式

monstop

実行できるユーザ

スーパユーザ，および一般ユーザ

機能

HAモニタを停止します。

オプション

なし。

リターンコード

値 | 意味
0 | 正常終了（HAモニタの停止が完了しました）
0以外 | 異常終了

注意事項

monstopコマンドは，サーバが稼働している場合は受け付けられません。

monswap（計画系切り替え）

形式

monswap {サーバ識別名|-gグループ名}

実行できるユーザ

スーパユーザ

機能

計画系切り替えを実行します。

monswap -gコマンドを実行すると，連動系切り替えでグループ化したサーバグループ全体の計画系切り替えをします。待機系のサーバグループ内に連動系切り替え待ち状態の待機サーバがある場合は，monswap -gコマンドを実行してサーバグループ全体の系切り替えをすることで，実行サーバとして起動できます。

マルチスタンバイ機能を使用している場合，monswapコマンドを実行したときに最も優先度が高い待機サーバに計画系切り替えをします。なお，現用系で待機サーバが稼働している場合（サーバ対応の環境設定のinitialオペランドにonlineが指定されているサーバが，待機サーバとして稼働している場合），この待機サーバを最も優先度が高い待機サーバと判断されます。

なお，このコマンドは，計画系切り替えの対象となる実行サーバが稼働している系で実行できます。

オプション

サーバ識別名
計画系切り替えをするサーバの識別名を指定します。ただし，グループ化されていないサーバに対して有効です。

-g グループ名
計画系切り替えをするサーバグループのグループ名を指定します。

リターンコード

値 | 意味
0 | 正常終了（計画系切り替えの要求を受け付けました）
0以外 | 異常終了

注意事項

HAモニタの環境設定のexitcodeオペランドにtype2を指定した場合，次のメッセージ出力時にもリターンコードが0となります。

KAMN212-E，KAMN215-E，KAMN216-E，KAMN322-E，KAMN323-E，KAMN330-E，KAMN426-E

monts（HAモニタのトラブルシュート情報の収集）

形式

monts

実行できるユーザ

スーパユーザ

機能

HAモニタのトラブルシュートに必要な情報を通常のファイルに収集します。

オプション

なし。

リターンコード

値 | 意味
0 | 正常終了（HAモニタのトラブルシュート情報の収集が完了しました）
0以外 | 異常終了

使用例

>monts

  ＊＊＊ HAモニタ障害情報採取ツール DATE: 2004/02/12 13:57:50＊＊＊

  HAモニタの障害情報をファイルに出力します。
  ファイル名を入力してください。
  （リターンキーで /tmp/monts.tar を仮定します）
  =>
>/tmp/monts.tar
  リターンキーを押してください。
  =>
>
  障害情報をファイルに出力しています。しばらくお待ちください。
  障害情報の採取が終了しました。

（凡例）　>：ユーザの操作を示します。

注意事項

このコマンドは対話形式で実行します。対話形式で実行したくない（非対話形式で実行する）場合は，次のようなシェルを作成して実行してください。

#!/bin/sh
# syntax : monts.sh outputfile-pathname

TARFILE="$1"

MONTS_CMD="/opt/hitachi/HAmon/bin/monts"

echo "
 ${TARFILE}

" | ${MONTS_CMD}

exit 0

この例では，シェルの実行時に，第1引数に出力先のファイル名を絶対パスで指定します。

10.　API

この章では，UAPに組み込むAPIについて説明します。

＜この章の構成＞

APIの一覧

APIの説明で使用する見出し

hamon_patrolstart（UAPの監視開始）

hamon_patrolstop（UAPの監視終了）

詳細コードの一覧

コーディング例

APIの一覧

HAモニタで使用するAPIの一覧を，次の表に示します。

表10-1　HAモニタのAPIの一覧

API | 機能
hamon_patrolstart | UAPの監視開始をHAモニタに要求します。
hamon_patrolstop | UAPの監視終了をHAモニタに要求します。

APIの説明で使用する見出し

APIの説明で使用する，各見出しについて説明します。

形式

APIに必要なヘッダファイル，およびAPIの形式を示します。

機能

APIの機能を説明します。

UAPで値を設定する引数

UAPで値を設定する引数について説明します。

HAモニタから値が返される引数

HAモニタから値が返される引数について説明します。

リターンコード

APIのリターンコードについて説明します。

注意事項

APIを使用するときの注意事項を説明します。

hamon_patrolstart（UAPの監視開始）

形式

#include <HA_mon_uap.h>
long hamon_patrolstart(int signum,int *inf,void *opt);

機能

UAPの監視開始をHAモニタに要求します。

UAPの起動時には，あらかじめHAMON_UAPNAME環境変数に，モニタモードのプログラム対応の環境設定のnameオペランドに指定したプログラム名を設定しておく必要があります。

なお，HAMON_API_PATROL環境変数にnouseを指定した場合は，HAモニタへの要求は行わないでリターンコード0でリターンします。

UAPの環境変数については，「6.13.2　UAPの環境変数の設定」を参照してください。

UAPで値を設定する引数

signum
シグナル番号を指定します。0または捕捉できるシグナル番号を指定してください。UAPのプロセスに加えてUAPの稼働報告を監視したい場合は，0以外を指定します。UAPのプロセスだけを監視したい場合は，0を指定します。
なお，0以外を指定した場合でも，モニタモードのプログラム対応の環境設定のpatrolオペランドを省略したときは，UAPのプロセスの監視だけを行います。

opt
予備領域です。NULLを指定します。

HAモニタから値が返される引数

inf
エラー時の詳細コードを返却するための領域です。詳細コードについては，「詳細コードの一覧」を参照してください。

リターンコード

値 | 意味
0 | HAモニタは，この関数を発行したUAPの監視を開始します。
-1 | エラーが発生しました。HAモニタは，この関数を発行したUAPの監視を開始しません。ただし，すでに監視を開始している場合は，監視が継続されます。詳細については，「詳細コードの一覧」を参照してください。

注意事項

この関数は，同一プロセスから連続して複数回発行しないでください。

1プロセスでAPIを発行できるのは1スレッドだけです。

hamon_patrolstop（UAPの監視終了）

形式

#include <HA_mon_uap.h>
long hamon_patrolstop(int *inf, void *opt);

機能

UAPの監視終了をHAモニタに要求します。UAPを監視したままUAPを終了すると，HAモニタがUAP障害を検出してしまうため，UAPを終了する前に必ずこの関数を発行してください。

UAPの起動時には，あらかじめHAMON_UAPNAME環境変数に，モニタモードのプログラム対応の環境設定のnameオペランドに指定したプログラム名を設定しておく必要があります。

なお，HAMON_API_PATROL環境変数にnouseを指定した場合は，HAモニタへの要求は行わないでリターンコード0でリターンします。

UAPの環境変数については，「6.13.2　UAPの環境変数の設定」を参照してください。

UAPで値を設定する引数

opt
予備領域です。NULLを指定します。

HAモニタから値が返される引数

inf
エラー時の詳細コードを返却するための領域です。詳細コードについては，「詳細コードの一覧」を参照してください。

リターンコード

値 | 意味
0 | HAモニタは，この関数を発行したUAPの監視を終了します。
-1 | エラーが発生しました。詳細については，「詳細コードの一覧」を参照してください。

注意事項

この関数は，hamon_patrolstart関数を発行したプロセス（スレッド）から発行してください。

この関数は，同一プロセスから連続して複数回発行しないでください。

1プロセスでAPIを発行できるのは1スレッドだけです。

詳細コードの一覧

APIがinf引数に返す詳細コードの一覧を，次の表に示します。

なお，詳細コードはinf引数に指定したポインタがNULLではなく，かつリターンコードが-1のときだけ設定されます。

表10-2　詳細コードの一覧

詳細コード（数値）
意味
メッセージ出力

1
次のどちらかに該当します。

HAモニタが起動していません。

使用しているHAモニタのバージョンが誤っています。

○

2
hamon_patrolstart関数のsignum引数に無効なシグナル番号を指定しました。
○

3
HAモニタは，すでにAPIを発行したUAPの監視を開始しています。
×

4
次のどれかに該当します。

HAMON_UAPNAME環境変数が設定されていません。

HAMON_UAPNAME環境変数に指定されたプログラム名が空，または1,001文字以上です。

HAMON_UAPNAME環境変数に指定されたプログラム名に対応するUAPが，モニタモードのプログラム対応の環境設定に定義されていません。

HAMON_UAPNAME環境変数に指定されたプログラム名に対応するUAPを管理するサーバが，実行サーバとして起動していません。

○

5
次のどちらかに該当します。

HAモニタが，APIを発行したUAPを監視していません。

プログラムの稼働数が，HAモニタの環境設定のpgmmaxオペランドに指定した数にすでに達しています。

×

6
システムコールエラーです。
○

（凡例）

○：APIがsyslogにメッセージを出力します。

×：APIがsyslogにメッセージを出力しません。

コーディング例

UAPのコーディング例を，示します。

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include "HA_mon_uap.h"

int main(int argc, char *argv[])
{

/*  変数の定義  */
   int     rt = 0;
   long    rc1 = 1;
   long    rc2 = 1;
   int     signum;
   int     inf;

/*  hamon_patrolstart関数の発行  */
   signum = SIGUSR2;
   rc1 = hamon_patrolstart(signum, &inf, NULL);
   if(rc1 != 0){
           rt = rc1;
           goto END_OF_FUNC;
   }
   else;

   while (1) {

           ：
           ：
        業務処理
           ：
           ：
   }

/*  hamon_patrolstop関数の発行  */
   rc2 = hamon_patrolstop(&inf, NULL);
   if(rc2 != 0){
               rt = rc2;
               goto END_OF_FUNC;
   }
   else;

   return(rt);
}

付録

＜この付録の構成＞

付録A　HAモニタのイベントID

付録B　監視履歴として出力されるメッセージ

付録C　HAモニタが出力するファイル一覧

付録D　HAモニタのプロセス一覧

付録E　各バージョンの変更内容

付録F　このマニュアルの参考情報

付録G　用語解説

付録A　HAモニタのイベントID

JP1と連携して，システムの自動化を実現できます。HAモニタは，HAモニタの起動時やサーバの異常終了時などにイベントを発行し，JP1に通知します。

HAモニタが発行するイベントは，JP1/Baseが管理します。イベント管理については，マニュアル「JP1/Base 運用ガイド」を参照してください。

HAモニタが発行するJP1イベントの項目について説明します。ユーザは次に示す項目について，JP1統合管理画面などから確認できます。

図A-1　HAモニタが発行するJP1イベントの項目一覧

イベントID

HAモニタに割り当てられたJP1のイベントIDが表示されます。

対応するHAモニタメッセージ

イベントに対応する，HAモニタのメッセージIDおよびメッセージテキストが表示されます。

重大度

該当するイベントのJP1での重大度が表示されます。次のどれかが表示されます。

Error
エラーを意味します。

Warning
警告を意味します。

Information
情報を意味します。

ユーザ名

スーパユーザ名が表示されます。

プロダクト名

/HITACHI/HAmonが表示されます。

オブジェクトタイプ

JP1のイベントを発行する原因となった，HAモニタのオブジェクトの種類が表示されます。次のどれかが表示されます。

HAHOST
HAモニタ本体に関するイベントです。

HASERV
サーバに関するイベントです。

HARESET
リセットパスに関するイベントです。

HAPATH
監視パスに関するイベントです。

HASERVPATH
サーバパスのエラーに関するイベントです。

オブジェクト名

オブジェクトタイプに対応したオブジェクト名が表示されます。次のどれかが表示されます。

HAモニタのホスト名
HAHOSTに対応します。

サーバ識別名，またはサーバパス名
HASERVに対応します。

リセット先のHAモニタのホスト名
HARESETに対応します。

監視パスのホスト名
HAPATHに対応します。

サーバパス名
HASERVPATHに対応します。

登録名タイプ

HAmonが表示されます。

登録名

イベント発行元のHAモニタのホスト名が表示されます。

事象種別

オブジェクトタイプで設定したオブジェクトがどのような状態の場合にイベントを発行するかが表示されます。次のどれかが表示されます。

START
開始しました。

END
終了しました。

NOTSTART
開始できませんでした。

RESTART
再実行を開始しました。

SWITCH
系切り替えが発生しました。

NOTICE
ユーザに通知します。

EXCEPTION
そのほかのエラーが発生しました。

開始時刻

イベントの発生時刻が表示されます。

HAモニタが発行するイベントの項目のうち，イベントごとに内容が異なる項目を次に示します。

表A-1　HAモニタが発行するイベントの内容

イベント発行契機 | イベントID | 対応するHAモニタメッセージ | 重大度 | オブジェクトタイプ | オブジェクト名 | 事象種別
HAモニタ開始 | 00010200​ | KAMN002-I | Information | HAHOST | HAモニタのホスト名 | START
HAモニタ正常終了 | 00010201​ | KAMN050-I | Information | END
KAMN056-I
HAモニタ異常終了 | 00010202​ | KAMN003-E※1 | Error | NOTSTART
KAMN205-E
KAMN207-E
KAMN208-E
KAMN617-E | EXCEPTION
サーバ起動 | 00010203​ | KAMN241-I | Information | HASERV | サーバ識別名 | START
KAMN251-I
KAMN254-I | RESTART
KAMN274-I
KAMN310-I | SWITCH
KAMN311-I
サーバ正常終了 | 00010204​ | KAMN280-I | Information | END
KAMN281-I
KAMN290-I
サーバ異常，または異常終了 | 00010205​ | KAMN253-E | Error | EXCEPTION
KAMN266-I
KAMN272-E
KAMN273-E※2
KAMN275-E
KAMN276-E
KAMN295-I
KAMN300-E
KAMN301-E
KAMN305-E | NOTSTART
KAMN306-E
KAMN307-E
KAMN312-E
KAMN315-E
KAMN316-E
KAMN384-E
KAMN423-E
KAMN237-E | HASERVPATH | サーバパス名
他系の障害を検出 | 00010206​ | KAMN340-E | Error | HAHOST | 障害となった系のHAモニタのホスト名 | EXCEPTION
リセットパス障害，およびリセット失敗 | 00010207​ | KAMN347-E | Error | HARESET | リセット先のHAモニタのホスト名
KAMN399-E
監視パス障害 | 00010208​ | KAMN177-E | Error | HAPATH | 監視パスのホスト名
KAMN607-E
KAMN640-E
KAMN174-W | Warning
KAMN641-W
オペレータ介入待ち※3 | 00010209​ | KAMN238-D | Warning | HASERV | サーバ識別名 | WAIT
KAMN258-D
KAMN368-D

注※1　HAモニタ起動時，メッセージKAMN001-Iの出力前，またはHAモニタの定義ファイル解析失敗によってHAモニタが起動失敗した場合，イベントは発行されません。

注※2　メッセージKAMN273-EがメッセージKAMN300-E，KAMN305-E，KAMN312-E，KAMN315-Eのどれかと一緒に出力された場合は，メッセージKAMN273-Eはイベントとして発行されません。一緒に出力されたメッセージだけがイベントとして発行されます。

注※3　オペレータ介入待ちイベントは，複数回発生することがあります。複数回発生した場合は，最初に発生したイベントだけが発行されます。

＜この節の構成＞

(1)　HAモニタ開始時のイベント発行タイミング

(2)　HAモニタ正常終了時のイベント発行タイミング

(3)　HAモニタ異常終了時のイベント発行タイミング

(4)　サーバ起動時のイベント発行タイミング

(5)　サーバ正常終了時のイベント発行タイミング

(6)　サーバ起動失敗時のイベント発行タイミング

(7)　サーバ障害時のイベント発行タイミング

(8)　他系の障害検出時のイベント発行タイミング

(9)　リセットパス障害時のイベント発行タイミング

(10)　系のリセット失敗時のイベント発行タイミング

(11)　監視パス障害時のイベント発行タイミング

(12)　オペレータ介入待ち時のイベント発行タイミング

(1)　HAモニタ開始時のイベント発行タイミング

HAモニタ開始時のイベント発行タイミングを，次の図に示します。

図A-2　HAモニタ開始時のイベント発行タイミング

(2)　HAモニタ正常終了時のイベント発行タイミング

HAモニタ正常終了時のイベント発行タイミングを，次の図に示します。

図A-3　HAモニタ正常終了時のイベント発行タイミング

HAモニタのシャットダウンによる，自動停止時のイベント発行タイミングを，次の図に示します。

図A-4　HAモニタのシャットダウンによる自動停止時のイベント発行タイミング

(3)　HAモニタ異常終了時のイベント発行タイミング

HAモニタ異常終了時のイベント発行タイミングを，次の図に示します。

図A-5　HAモニタ異常終了時のイベント発行タイミング

HAモニタ起動失敗時のイベント発行タイミングを，次の図に示します。

図A-6　HAモニタ起動失敗時のイベント発行タイミング

複数のHAモニタ起動失敗時のイベント発行タイミングを，次の図に示します。

図A-7　複数のHAモニタ起動失敗時のイベント発行タイミング

(4)　サーバ起動時のイベント発行タイミング

サーバ起動時のイベント発行タイミングを，次の図に示します。

図A-8　サーバ起動時のイベント発行タイミング

(5)　サーバ正常終了時のイベント発行タイミング

サーバ正常終了時のイベント発行タイミングを，次の図に示します。

図A-9　サーバ正常終了時のイベント発行タイミング

サーバ計画停止時のイベント発行タイミングを，次の図に示します。

図A-10　サーバ計画停止時のイベント発行タイミング

(6)　サーバ起動失敗時のイベント発行タイミング

サーバ起動失敗時のイベント発行タイミングを，次の図に示します。

図A-11　サーバ起動失敗時のイベント発行タイミング

(7)　サーバ障害時のイベント発行タイミング

サーバ対応の環境設定のswitchtypeオペランドにswitchを指定している場合の，サーバ障害時のイベント発行タイミングを，次の図に示します。

図A-12　サーバ障害時（switchtype＝switch）のイベント発行タイミング

サーバ対応の環境設定のswitchtypeオペランドにrestartを指定している場合の，サーバ障害時のイベント発行タイミングを，次の図に示します。

図A-13　サーバ障害時（switchtype＝restart）のイベント発行タイミング

サーバ対応の環境設定のswitchtypeオペランドにmanualを指定している場合の，サーバ障害時のイベント発行タイミングを，次の図に示します。

図A-14　サーバ障害時（switchtype＝manual）のイベント発行タイミング

サーバ対応の環境設定のswitchtypeオペランドにrestartを指定している場合の，サーバ再起動限界時のイベント発行タイミングを，次の図に示します。

図A-15　サーバ再起動限界時（switchtype＝restart）のイベント発行タイミング

サーバ対応の環境設定のswitchtypeオペランドにmanualを指定している場合の，サーバ再起動限界時のイベント発行タイミングを，次の図に示します。

図A-16　サーバ再起動限界時（switchtype＝manual）のイベント発行タイミング

待機サーバ異常終了時のイベント発行タイミングを，次の図に示します。

図A-17　待機サーバ異常終了時のイベント発行タイミング

サーバの監視コマンドでサーバプロセスを監視している場合で，モニタモードのサーバの障害を検出したときのイベント発行タイミングを，次の図に示します。

図A-18　モニタモードのサーバでの障害検出時のイベント発行タイミング

実行サーバを重複して起動した場合のイベント発行タイミングを，次の図に示します。

図A-19　実行サーバ重複起動時のイベント発行タイミング

モニタモードのサーバが待機サーバの自動起動要求に失敗した場合のイベント発行タイミングを，次の図に示します。

図A-20　モニタモードのサーバでの待機サーバ自動起動要求失敗時のイベント発行タイミング

サーバ対応の環境設定のgroupオペランドにno_exchangeを指定している場合で，サーバグループの連動系切り替え待ち状態になったときのイベント発行タイミングを，次の図に示します。

図A-21　サーバ障害時（group＝no_exchange）のイベント発行タイミング

(8)　他系の障害検出時のイベント発行タイミング

系障害時のイベント発行タイミングを，次の図に示します。

図A-22　系障害時のイベント発行タイミング

(9)　リセットパス障害時のイベント発行タイミング

リセットパス障害時のイベント発行タイミングを，次の図に示します。

図A-23　リセットパス障害時のイベント発行タイミング

(10)　系のリセット失敗時のイベント発行タイミング

系に障害が発生して，系のリセットに失敗した場合のイベント発行タイミングを，次の図に示します。

図A-24　系のリセット失敗時のイベント発行タイミング

(11)　監視パス障害時のイベント発行タイミング

HAモニタ開始時に監視パス障害が発生した場合のイベント発行タイミングを，次の図に示します。

図A-25　監視パス障害発生時のイベント発行タイミング（HAモニタ開始時）

HAモニタ稼働中に監視パス障害が発生した場合のイベント発行タイミングを，次の図に示します。

図A-26　監視パス障害発生時のイベント発行タイミング（HAモニタ稼働中）

(12)　オペレータ介入待ち時のイベント発行タイミング

実行サーバ未起動によるオペレータ介入待ち時のイベント発行タイミングを，次の図に示します。

図A-27　実行サーバ未起動によるオペレータ介入待ち時のイベント発行タイミング

付録B　監視履歴として出力されるメッセージ

サーバや系に発生したスローダウンの情報を監視履歴として取得する場合，監視履歴ファイルに監視履歴が出力されます。ここでは，監視履歴として出力されるメッセージの内容，および監視履歴が出力されるタイミングについて説明します。監視履歴ファイルの出力形式については，「7.5.3(1)　監視履歴ファイルの出力形式」を参照してください。

監視履歴として出力されるメッセージの一覧を次に示します。

表B-1　監視履歴として出力されるメッセージ一覧

ID | 種別 | メッセージ本文 | メッセージの説明
0101 | H | Acquisition of the patrol history has started. | ホスト名で示す他系の監視履歴の取得を開始しました。
0102 | H | Acquisition of the patrol history has ended. | ホスト名で示す他系の監視履歴の取得を終了しました。
0103 | H | The alive message was not received from the other system. | ホスト名で示す他系から，秒数で示す期間aliveメッセージを受信できませんでした。
0201 | S | Acquisition of the patrol history has started. | サーバ識別名で示す実行サーバの監視履歴の取得を開始しました。
0202 | S | Acquisition of the patrol history has ended. | サーバ識別名で示す実行サーバの監視履歴の取得を終了しました。
0203 | S | Slowdown of Online server was detected. | サーバ識別名で示す実行サーバから，秒数で示す期間稼働報告がありませんでした。
0301 | O | Acquisition of the patrol history has started. | 自系の監視履歴の取得を開始しました。
0302 | O | Acquisition of the patrol history has ended. | 自系の監視履歴の取得を終了しました。
0303 | O | Slowdown of HAmonitor in the own host was detected. | 自系が秒数で示す期間スローダウンしていました。

（凡例）

H：他系

S：自系で稼働する実行サーバ

O：自系

＜この節の構成＞

(1)　サーバの監視履歴が出力されるタイミング

(2)　他系の監視履歴が出力されるタイミング

(3)　自系の監視履歴が出力されるタイミング

(1)　サーバの監視履歴が出力されるタイミング

HAモニタが自系の実行サーバの監視履歴を出力するタイミングを次に示します。

自系で実行サーバが起動したとき
サーバの監視履歴の取得を開始したというメッセージが出力されます。

サーバ監視履歴取得時間を超えた間隔で，実行サーバの稼働報告を受けたとき
スローダウンが発生したというメッセージが出力されます。

実行サーバに障害が発生したとき
スローダウンが発生したというメッセージ，および監視履歴の取得を終了したというメッセージが出力されます。

自系で実行サーバ，またはHAモニタが停止したとき
監視履歴の取得を終了したというメッセージが出力されます。

サーバの監視履歴が出力されるタイミングの例を，次に示します。

図B-1　サーバの監視履歴が出力されるタイミング

次に，図中の番号で示す時点でのサーバの状態を説明します。

自系で実行サーバが起動しました。
HAモニタは実行サーバの監視を開始し，監視履歴（ID：0201）を取得します。

サーバ監視履歴取得時間を超えたスローダウンが発生しました。

サーバ障害監視時間に到達する前にスローダウン状態を脱しました。
HAモニタはサーバの稼働報告を受けたタイミングで監視履歴（ID：0203）を取得します。

実行サーバが停止しました。
HAモニタは実行サーバの監視を終了し，監視履歴（ID：0202）を取得します。

(2)　他系の監視履歴が出力されるタイミング

HAモニタが他系の監視履歴を出力するタイミングを次に示します。

自系のHAモニタが系間の監視を開始したとき
監視履歴の取得を開始したというメッセージが出力されます。

系監視履歴取得時間を超えた間隔で，他系からaliveメッセージを受信したとき
スローダウンが発生したというメッセージが出力されます。

他系に障害が発生し，異常終了したとき
監視履歴の取得を終了したというメッセージが出力されます。障害の原因がスローダウンの場合，スローダウンが発生したというメッセージも出力されます。

自系または他系のサーバが終了して，系切り替えができるサーバがなくなったとき
監視履歴の取得を終了したというメッセージが出力されます。

自系または他系のHAモニタが終了したとき
監視履歴の取得を終了したというメッセージが出力されます。

他系の監視履歴が出力されるタイミングの例を，次に示します。

図B-2　他系の監視履歴が出力されるタイミング

次に，図中の番号で示す時点での他系の状態を説明します。

待機サーバが起動しました。
系切り替えができる状態になったため，自系のHAモニタは系間の監視を開始し，監視履歴（ID：0101）を取得します。

系監視履歴取得時間を超えたスローダウンが発生しました。

系障害監視時間に到達する前にスローダウン状態を脱しました。
自系のHAモニタはaliveメッセージを受信したタイミングで監視履歴（ID：0103）を取得します。

実行サーバが停止しました。
系切り替えができる状態でなくなったため，自系のHAモニタは系間の監視を終了し，監視履歴（ID：0102）を取得します。

(3)　自系の監視履歴が出力されるタイミング

HAモニタが自系の監視履歴を出力するタイミングを次に示します。

自系のHAモニタが起動したとき
監視履歴の取得を開始したというメッセージが出力されます。

自系が系監視履歴取得時間を超えたスローダウンから回復したとき
スローダウンが発生したというメッセージが出力されます。

自系にスローダウンが発生して系切り替えをしたあと，再起動したとき
スローダウンが発生したというメッセージが出力されます。

自系のHAモニタが終了したとき
監視履歴の取得が終了したというメッセージが出力されます。

自系の監視履歴が出力されるタイミングの例を，次に示します。

図B-3　自系の監視履歴が出力されるタイミング

次に，図中の番号で示す時点での自系の状態を説明します。

自系のHAモニタが起動しました。
自系のHAモニタは自系の監視を開始し，監視履歴（ID：0301）を取得します。

系監視履歴取得時間を超えたスローダウンが発生しました。

系障害監視時間に到達する前にスローダウン状態を脱しました。
自系のHAモニタは自系がスローダウンから脱したタイミングで監視履歴（ID：0303）を取得します。

自系のHAモニタが停止しました。
自系のHAモニタは自系の監視を終了し，監視履歴（ID：0302）を取得します。

付録C　HAモニタが出力するファイル一覧

HAモニタが出力するファイルの一覧を，次の表に示します。

なお，ファイルパス名に記載している，history，etc，またはspoolで始まるパスは，/opt/hitachi/HAmon配下を表しています。

表C-1　HAモニタが出力するファイル一覧

項番
名称
ファイルパス名
生成・削除
タイミング
管理方法
サポートバージョン
形式

1
障害情報の移送
任意
（montsコマンド実行時のデフォルトは/tmp配下）
montsコマンド実行時
－
01-10以降
バイナリ

2
モジュールトレース
/opt/hitachi/HAmon/coreで始まるすべてのファイル
HAモニタの異常終了時
－
01-10以降
バイナリ

3
リセットパス設定ファイル
etc/.CPSS_RESET
monsetupコマンドによるリセットパス設定時
1世代管理
01-10以降
テキスト

4
HAモニタ起動情報制御ファイル
etc/.CTLFILE
HAモニタ起動時
1世代管理
01-10以降
バイナリ

5
HAモニタの起動／停止方法の設定判定ファイル
etc/.HApwon_manual
monsetupコマンドによる自動起動／停止設定時
1世代管理
01-30以降
テキスト

6
etc/.HApwoff_manual

7
リセットパスオプション設定ファイル
etc/.RSTDENV
monsetupコマンドによるリセットパス設定時
1世代管理
01-10以降
テキスト

8
接続設定
etc/connection
HAモニタ停止時
1世代管理
01-10以降
テキスト

9
サーバ対応の環境設定ファイルのバックアップ
etc/servers.bac
mondeviceコマンド実行時（-cオプション指定時を除く）
1世代管理
01-10以降
テキスト

10
監視履歴
history/patrol_history
サーバの監視履歴を取得する場合（ph_log_sizeオペランドを指定）に，系およびサーバのスローダウン回復時
oldの2世代管理
（ラップアラウンド方式，およびラウンドロビン方式）
01-12以降
テキスト

11
HAモニタ開始メッセージ読み捨て情報
spool/.dup_start
他系から古いHAモニタの開始メッセージ受信時
bakの2世代管理
01-10以降
バイナリ

12
fuser実行結果
spool/.ERRdisk_で始まるすべてのファイル
ディスク切り離しの障害時
デバイス数×bakの2世代管理
01-10以降
テキスト

13
イベントトレース※1
spool/.event_trace
HAモニタ内での事象発生時
1世代管理
（ラップアラウンド方式）
01-10以降
テキスト

14
haiodのトラブルシュート情報
spool/.haiod_trace
スローダウンなどの障害発生時※2
spool/下とspool/haiod_trace/下に21世代管理
01-11以降
テキスト

15
hcmaliveのトラブルシュート情報
spool/.hcmalive_trace
スローダウンなどの障害発生時※2
spool/下とspool/hcmalive_trace/下に21世代管理
01-32以降
テキスト

16
hcmreadのトラブルシュート情報
spool/.hcmr_trace
スローダウンなどの障害発生時※2
spool/下とspool/hcmr_trace/下に21世代管理
01-10以降
テキスト

17
JP1エラー情報
spool/.jp1log
JP1のイベント通知機能を使用する場合（jp1_eventオペランドを指定）に，JP1イベントの登録処理の異常時
1世代管理
01-10以降
テキスト

18
HAモニタ内部メッセージログ
spool/.msglog
HAモニタのメッセージ出力時
1世代管理
（ラップアラウンド方式）
01-10以降
テキスト

19
hcmaliveプロセス制御用ソケットファイル
spool/.s_alive
HAモニタ起動／停止時
1世代管理
01-30以降
バイナリ

20
hcmaliveのコマンド処理用ソケットファイル
spool/.s_alivecmd
HAモニタ起動／停止時
1世代管理
01-31以降
バイナリ

21
コマンド用ソケットファイル
spool/.s_cmnd
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

22
内部イベント制御用ソケットファイル
spool/.s_event
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

23
halrstdプロセス制御用ソケットファイル
spool/.s_halrstd
HAモニタ起動／停止時
1世代管理
01-50以降
バイナリ

24
hcmreadのコマンド処理用ソケットファイル
spool/.s_hcmrcmd
HAモニタ起動／停止時
1世代管理
01-31以降
バイナリ

25
haiodプロセス制御用ソケットファイル
spool/.s_iod
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

26
spool/.s_iod2

27
spool/.s_iodother

28
spool/.s_iodcmd

29
haiodのUAP用APIインタフェースソケット
spool/.s_iod_up
HAモニタ起動／停止時
1世代管理
01-42以降
バイナリ

30
prcmainプロセス外部イベント制御用ソケットファイル
spool/.s_other
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

31
サーバ制御用ソケットファイル
spool/.s_path
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

32
haresetdプロセス制御用ソケットファイル
spool/.s_resetd
HAモニタ起動／停止時
1世代管理
01-10以降
バイナリ

33
SVPレスポンス情報
spool/.sphralog
HAモニタ起動時，リセットパス障害時，またはSVPコマンド送受信時
1世代管理
（ラップアラウンド方式）
01-10以降
テキスト

34
コマンドログ
spool/cmdlog/.cmdlog1
HAモニタのコマンド，およびユーザコマンドの実行／終了時
1世代管理
（ラップアラウンド方式）
01-11以降
テキスト

35
spool/cmdlog/.cmdlog2

36
spool/cmdlog/.uoclog

37
トラブルシュート拡張情報
spool/DUPSTART_EX
他系から古いHAモニタの開始メッセージ受信時
bakの2世代管理
01-11以降
テキスト

38
spool/DUPSTART_EX_TOP※3

39
spool/ERRPATH_*_EX
監視パス障害時

40
spool/ERRPATH_*_EX_TOP※3

41
spool/HOSTSLOW_相手ホスト名_EX
他系の7割沈み込み時

42
spool/HOSTSLOW_相手ホスト名_EX_TOP※3

43
spool/HOSTSLOW_自ホスト名_EX
自系のスローダウン回復時

44
spool/HOSTSLOW_自ホスト名_EX_TOP※3

45
spool/MONTS_EX
montsコマンド実行時

46
spool/MONTS_EX_TOP※3

47
spool/RESET_EX
システムリセット時

48
spool/RESET_EX_TOP※3

49
spool/SERVSLOW_サーバ名_EX
サーバの7割沈み込み時

50
spool/SERVSLOW_サーバ名_EX_TOP※3

51
監視パス障害情報
spool/ERRPATH_で始まるすべてのファイル
監視パス障害時
監視パス数×bakの2世代管理
01-10以降
バイナリ

52
スローダウン時のデバッグ情報
spool/HOSTSLOW_相手ホスト名
他系の7割沈み込み時
ホスト数×bakの2世代管理
01-10以降
バイナリ

53
spool/HOSTSLOW_自ホスト名
自系のスローダウン回復時
bakの2世代管理

54
spool/SERVSLOW_サーバ名
サーバの7割沈み込み時
サーバ数×bakの2世代管理

55
spool/UAPSLOW_UAP識別名
UAPの7割沈み込み時
プログラム数×1世代管理
01-42以降

56
LAN監視の監視状況
spool/lanpatrol/IF名称.log
LANの監視機能使用時
bakの2世代管理
（ラップアラウンド方式）
01-40以降
テキスト

57
spool/lanpatrol/IF名称_stat.log

58
システムリセット時の障害情報
spool/RESET
システムリセット時
bakの2世代管理
01-10以降
バイナリ

59
統計情報
spool/sms
（spool/oldsms）
系およびサーバのスローダウン時
01-10以前：
oldの2世代管理
（単調増加方式）
01-11以降：
oldの2世代管理
（ラップアラウンド方式，およびラウンドロビン方式）
01-10以降
テキスト

60
使用可能なリソースの制限情報
spool/ulimit.log
HAモニタ起動時
1世代管理
01-22以降
テキスト

61
ファイルシステム切り替え情報
spool/サーバ識別名.fslog
ファイルシステムの切り替え時
サーバ数×oldの2世代管理
01-10以降
テキスト

62
LANの状態設定ファイル実行結果
spool/サーバ識別名.up.log
サーバの起動／停止時
サーバ数×bakの2世代管理
01-12以降
テキスト

63
spool/サーバ識別名.down.log

64
ボリュームグループの接続，および切り離し実行情報
spool/ボリュームグループ名.vglog
vgchange -a yコマンド実行時
ボリュームグループ数×oldの2世代管理
01-10以降
テキスト

65
メッセージログ
/var/log/messagesで始まるすべてのファイル
HAモニタのメッセージ出力時
－
01-10以降
テキスト

（凡例）

－：該当しません。

注※1

debugオプション指定時にしか取得されないトレースログです。

注※2

次のどれかのタイミングでファイルが出力されます。

・HAモニタのトラブルシュート情報収集コマンド（montsコマンド）を実行したとき（表の項番1に該当）

・監視パスの障害を検知したとき（表の項番51に該当）

・他系のスローダウンを検知したとき（表の項番52～55に該当）

・自系のスローダウンを検知したとき（表の項番52～55に該当）

・自系のサーバのスローダウンを検知したとき（表の項番52～55に該当）

・他系をリセットするとき（表の項番58に該当）

注※3

"xxx_EX_TOP"には，topコマンドの結果が取得されます。

付録D　HAモニタのプロセス一覧

HAモニタのプロセス一覧を，次の表に示します。

表D-1　HAモニタのプロセス一覧

項番
プロセス名称
機能
稼働数
備考

1
haiod
デバイス処理，ログ出力，およびファイル入出力
≧1
－

2
halrstd
（01-50以降）
他社仮想化ソフトウェアによるリセット処理
0または1
vmware_envオペランドにuseを指定した場合だけ稼働します。

3
haresetd
SVPによるリセット処理
≧1
通常1プロセスです。受信メッセージのログ出力時だけ，forkしてプロセス数が増加します。

4
hcmalive
（01-30以降）
aliveメッセージの送信
0または1
alive_intervalオペランドを指定した場合だけ稼働します。

5
hcmread
系間通信メッセージの受信
1
－

6
mon_lanpt
（01-40以降）
LAN監視処理
≧0
LAN監視機能を使用しない場合は，稼働しません。

7
prcmain
系とサーバの監視，およびaliveメッセージの送信
1
－

（凡例）－：該当しません。

付録E　各バージョンの変更内容

各バージョンの変更内容を示します。

＜この節の構成＞

(1)　HAモニタ 01-50の変更内容（3000-9-132-F0）

(2)　HAモニタ 01-42の変更内容（3000-9-132-E0）

(3)　HAモニタ 01-42の変更内容（3000-9-132-C0）

(4)　HAモニタ 01-41の変更内容（3000-9-132-B0）

(5)　HAモニタ 01-40，HAモニタExtension 01-00，HAモニタ 01-33の変更内容（3000-9-132-A0）

(6)　HAモニタ 01-32の変更内容（3000-9-132-90）

(7)　HAモニタ 01-31，HAモニタ 01-30の変更内容（3000-9-132-80）

(8)　HAモニタ 01-22の変更内容（3000-9-132-60）

(9)　HAモニタ 01-20の変更内容（3000-9-132-40）

(10)　HAモニタ 01-13の変更内容（3000-9-132-30）

(11)　HAモニタ 01-12の変更内容（3000-9-132-20）

(12)　HAモニタ 01-11の変更内容（3000-9-132-10）

(13)　HAモニタ 01-10の変更内容（3000-9-132）

(1)　HAモニタ 01-50の変更内容（3000-9-132-F0）

HAモニタ 01-50の変更内容（3000-9-132-F0）を次の表に示します。

追加・変更内容

VMware ESXiを利用して，仮想化できるようにした。
これに伴い，次のオペランドを追加した。

HAモニタの環境設定

vmware_env

次のオペランドの説明を変更した。

HAモニタの環境設定

cpudown

次のコマンドの説明を変更した。

monsetup

ファイルシステムの設定について，説明を追加した。

共有ディスクの設定の概要を追加した。また，/etc/rc.sysinitファイルの編集時の注意事項，ファイルシステムを/etc/fstabファイルに指定する場合の注意事項，およびキャラクタ型スペシャルファイルのバインド・アンバインドの要否の説明を追加した。

APIの共有ライブラリファイルはUAP実行時にAPIのオブジェクトファイルから動的にロードするライブラリである旨を記載した。

HAモニタが出力するファイルの一覧を追加した。

HAモニタのプロセス一覧を追加した。

(2)　HAモニタ 01-42の変更内容（3000-9-132-E0）

HAモニタ 01-42の変更内容（3000-9-132-E0）を次の表に示します。

追加・変更内容

適用OSにRed Hat Enterprise Linux server 6(x86)，およびRed Hat Enterprise Linux server 6(x86_64)を追加した。
また，これらのOSに対応したHAモニタの形名として，P-812C-E111を追加した。

LANの状態設定ファイルについて，「/bin/echo 0」の実行個所を，arpingコマンドの直後からifconfigコマンドの直後に変更した。

プログラム管理機能に関する説明を改善した。

HA Boosterが管理するボリュームグループについては，システム起動時，自動的に参照＋更新接続する必要があることを明記した。

HA Boosterが管理する制御グループにある共有ディスク上で，キャラクタ型スペシャルファイルを使用する場合の設定について記載した。

プログラム管理機能を使用する場合の，UAP障害時の対処について記載した。

サーバ対応の環境設定のtermcmd_at_abortオペランドの説明を改善した。

サーバ対応の環境設定のactcommandオペランドの説明を改善した。

次のコマンドの説明を改善した。

monswap

monts

(3)　HAモニタ 01-42の変更内容（3000-9-132-C0）

HAモニタ 01-42の変更内容（3000-9-132-C0）を次の表に示します。

追加・変更内容

モニタモードのプログラムをプログラム単位で管理できる，プログラム管理機能に対応した。この機能によって，APIを発行してUAPを監視できるようになった。
これに伴い，次の内容を追加した。

プログラムの再起動コマンドを追加して，プログラムを再起動できるようにした。

シェルを実行して，プログラムのスローダウンの原因を調査するための情報を収集できるようにした。

UAP障害発生時に，イベントID「00010205​」を発行できるようにした。

また，次のオペランドを追加した。

HAモニタの環境設定

pgmmax

サーバ対応の環境設定

program

モニタモードのプログラム対応の環境設定

name

alias

server_alias

restartcommand

patrol

restart_timeout

exec_retry

retry_stable

次のコマンドにオプションを追加した。

monchange（-pオプション）

monshow（-uオプション）

次のコマンドでチェックするオペランドを追加した。

moncheck

次のAPIを追加した。

hamon_patrolstart

hamon_patrolstop

ヘルスチェックの中断と再開について，説明を追加した。

サーバ識別名.upファイル，およびサーバ識別名.downファイルの例を修正した。

連動系切り替え中に系切り替え先のサーバが起動に失敗した場合の説明を追加した。

系切り替え構成が複数存在するシステムで，リセットパスに設定したIPアドレスに重複がないかをチェックできるようにした。
これに伴い，次のコマンドを追加した。

monlistip

サーバの起動コマンドまたはサーバの停止コマンドが，起動してから終了するまでのタイムアウト時間を指定できるようになった。
これに伴い，次のオペランドを追加した。

サーバ対応の環境設定

start_timeout

stop_timeout

次のコマンドのリターンコードを公開した。

monact

monbegin

monchange

moncheck

mondeact

mondevice

monend

moninfo

monlink

monodrshw

monpath

monresbgn

monresend

monressbystp

monrp

monsbystp

monsetup

monshow

monstart

monstop

monswap

monts

これに伴い，HAモニタの環境設定の次のオペランドを追加した。

exitcode

(4)　HAモニタ 01-41の変更内容（3000-9-132-B0）

HAモニタ 01-41の変更内容（3000-9-132-B0）を次の表に示します。

追加・変更内容

サーバモードで使用できるプログラムとして，HiRDB（XDS）を追加した。

相互系切り替え構成の場合で，かつマシンの機種がBladeSymphonyでSVPがクラスタ管理機能に対応している場合に，リセット優先系を決めないで，系の同時リセットを防止する機能を追加した。
これに伴い，HAモニタの環境設定の，次のオペランドに設定できる値を追加した。

cpudown

マルチスタンバイ機能使用時に，系のリセットを抑止できるようにした。
これに伴い，HAモニタの環境設定に次のオペランドを追加した。

suppress_reset

OSのコマンド（vgchangeコマンド）の実行結果をボリュームグループの切り離し時にも取得できるようにした。

SVPを共用する場合の設定について，説明を追加した。

メッセージカタログの設定について，説明を追加した。

サーバの再起動時に戻り値が0以外の場合は，サーバ対応の環境設定のtermcommandオペランドに指定したサーバの停止コマンドを実行しない旨を記載した。

共有リソースの種類と変更する設定内容の説明に，サーバ対応の環境設定の次のオペランドを追加した。

deviceoff_order

(5)　HAモニタ 01-40，HAモニタExtension 01-00，HAモニタ 01-33の変更内容（3000-9-132-A0）

HAモニタ 01-40およびHAモニタExtension 01-00の変更内容（3000-9-132-A0）を次の表に示します。

追加・変更内容

HAモニタ Extensionを使用して，サーバの最大数の変更，および系の最大数の変更ができるようにした。
これに伴い，次のオペランドを追加した。

HAモニタの環境設定

hostmax

alive_multicast

multicast_lan

次のオペランドの説明を変更した。

HAモニタの環境設定

servmax

次のコマンドの説明を変更した。

moncheck

また，次のコマンドにオプションを追加した。

monsetup

aliveメッセージの確認間隔を変更できるようにした。
これに伴い，HAモニタの環境設定のファイルに，次のオペランドを追加した。

patrol_100ms

HAモニタが系のリセットをする場合として，サーバ対応の環境設定のdev_timelimitオペランドに指定した時間でタイムアウトした場合の説明を追加した。

LANを監視して，障害時に自動的に系切り替えができるようにした。
これに伴い，次のオペランドを追加した。

HAモニタの環境設定

lanfailswitch

lancheck_patrol

サーバ対応の環境設定

switchbyfail

また，次のコマンドの説明を変更した。

moncheck

サーバ識別名.upファイルの例を変更した。

サーバの切り替え順序制御の説明に，サーバモードのサーバとしてTP1/Server BaseまたはHiRDBを使用する場合の注意事項を追加した。

シェルを実行して，サーバのスローダウンの原因を調査するための情報を収集できるようにした。

SVPのIPアドレスに"auto"を指定する場合は，N+Mコールドスタンバイ機能に対応したシステム構成で稼働するための設定として，"Enable"を設定する旨を記載した。

サーバの停止確認について，説明を変更した。

HAモニタの環境設定のresetpatrolオペランドの説明に，リセットパスのヘルスチェック間隔を指定するときの見積もり式を追加した。

HAモニタ 01-33の変更内容（3000-9-132-A0）を次の表に示します。

追加・変更内容

etc/rc.sysinitファイルの編集でLVM2を使用する場合について，説明を変更した。

/etc/rc.sysinitファイルの編集例を追加した。

キャラクタ型スペシャルファイルの設定の説明に，アンバインドに関する説明を追加した。

キャラクタ型スペシャルファイルを論理ボリュームにバインドする場合の，ユーザコマンドのコーディング例のを変更した。

(6)　HAモニタ 01-32の変更内容（3000-9-132-90）

HAモニタ 01-32の変更内容（3000-9-132-90）を次の表に示します。

追加・変更内容

aliveメッセージは監視パスを介して行う旨を追加した。

マシンの機種がHA8500の場合のヘルスチェックについて，説明を追加した。

N+Mコールドスタンバイ構成での系切り替えに対応した。

HAモニタによるサーバの起動制御での，通常時およびマルチスタンバイ機能使用時の実行サーバと待機サーバの決定方法について，説明を変更した。

システムクロックの設定について，説明を変更した。

サーバの起動コマンド，およびサーバの停止コマンドの戻り値が0以外の場合に，サーバの再起動が失敗した場合の対処について追加した。

グループ化されているサーバの環境設定を変更する場合，またはグループに対してサーバの追加・削除をする場合について，説明を追加した。

系の監視履歴を取得している場合の注意事項を追加した。

(7)　HAモニタ 01-31，HAモニタ 01-30の変更内容（3000-9-132-80）

HAモニタ 01-31の変更内容（3000-9-132-80）を次の表に示します。

追加・変更内容

Hitachi HA Booster Pack for Linuxを使用した，共有ディスクの高速系切り替え，および他系のOSパニック検知機能に対応した。
また，これに伴い，サーバ対応の環境設定のファイルに，次のオペランドを追加した。

hab_gid

hab_discnt_atend

カーネル信頼性強化ツールキット for Linuxの名称を，Linux Tough Dumpに変更した。

系障害時に待機系に系切り替えしようとして失敗した場合の処理の流れについて，説明を追加した。

系障害時，および計画系切り替え時に系切り替えに失敗した場合の説明を追加した。また，複数スタンバイ構成時に，系切り替えに失敗し，ほかの待機サーバに系切り替えする場合の説明を追加した。

HAモニタ 01-30の変更内容（3000-9-132-80）を次の表に示します。

追加・変更内容

サーバモードで使用できるプログラムとして，uCosminexus TP1/Server Base Enterprise Optionを追加した。
また，これに伴い，サーバ対応の環境設定のファイルに，次のオペランドを追加した。

server_type

系障害監視時間を短縮できる機能を追加した。
これに伴い，HAモニタの環境設定のファイルに，次のオペランドを追加した。

alive_interval

適用OSに，Red Hat Enterprise Linux 5 Advanced Platform (Intel Itanium)を追加した。

適用OSがLinux（IPF）の場合に，一つの系で同時に稼働できるサーバの最大数を64から128に変更した。
また，これに伴い，HAモニタの環境設定のservmaxオペランドで指定できる値を追加した。

適用OSがLinux（IPF）の場合に，一つの系での監視パスの最大数を3から6に変更した。
また，これに伴い，HAモニタの環境設定のlanオペランドで指定できる値を変更した。

適用OSがLinux（IPF）の場合に，稼働しているHAモニタやサーバの設定を変更する機能を追加した。
これに伴い，次のコマンドを追加した。

monchange

また，次のコマンドにサーバの監視時間を表示するオプションを追加した。

monshow

次に示すmondeviceコマンドを実行する際の制限を解除した。

マルチスタンバイ機能を使用する場合は実行系からコマンドを実行すること

(8)　HAモニタ 01-22の変更内容（3000-9-132-60）

HAモニタ 01-22の変更内容（3000-9-132-60）を次の表に示します。

追加・変更内容

適用OSがLinux（x86）の場合で前提機種がBladeSymphonyのときに，日立サーバ仮想化機構を使用したLPAR単位での系切り替え構成をサポートした。

サーバ障害が発生し待機系に系切り替えしようとして失敗した場合の処理の流れについて，説明を追加した。

適用OSがLinux（x86）の場合に，一つの系で同時に稼働できるサーバの最大数を64から128に変更した。
また，これに伴い，HAモニタの環境設定のservmaxオペランドで指定できる値を追加した。

システムに掛かる負荷のテストについての説明を追加した。

適用OSがLinux（x86）の場合に，稼働しているHAモニタやサーバの設定を変更する機能を追加した。
これに伴い，次のコマンドを追加した。

monchange

また，次のコマンドにサーバの監視時間を表示するオプションを追加した。

monshow

(9)　HAモニタ 01-20の変更内容（3000-9-132-40）

HAモニタ 01-20の変更内容（3000-9-132-40）を次の表に示します。

追加・変更内容

LANの状態設定ファイルのサンプルファイルを英文化した。

サーバの切り替え順序制御をする場合の処理を変更した。

サーバモードの待機サーバの停止について，処理方法を追加した。

コマンドヘルプ，およびメッセージヘルプを廃止した。

セキュリティレベルの設定について説明を追加した。

サーバの停止コマンドの起動条件を追加した。
また，これに伴い，HAモニタの環境設定のファイルに次のオペランドを追加した。

termcmd_at_abort

次の場合にユーザコマンドに渡されるパラメタの説明を変更した。

実行サーバ障害（系切り替えができない場合）

実行サーバ障害（系切り替えに失敗した場合）

待機サーバ障害

HAモニタのユーザコマンドのサンプルファイルを英文化した。

定義チェックの項目に，共有リソースのオペランドの値に関するチェックを追加した。

(10)　HAモニタ 01-13の変更内容（3000-9-132-30）

HAモニタ 01-13の変更内容（3000-9-132-30）を次の表に示します。

追加・変更内容

適用OSがLinux（IPF）の場合で前提機種がBladeSymphonyのときに，日立サーバ仮想化機構を使用したLPAR単位での系切り替え構成をサポートした。
これに伴い，物理パーティションリセット機能を追加した。また，HAモニタの環境設定のpartition_resetオペランドを追加した。また，monrpコマンドおよびmonsetupコマンドに機能を追加した。

次の条件でサーバを起動した場合の起動種別を変更した。

実行サーバがない

他系で同じ名前の待機サーバが停止処理中である

HAモニタのリセット手順ファイルのサンプルファイルを英文化した。

(11)　HAモニタ 01-12の変更内容（3000-9-132-20）

HAモニタ 01-12の変更内容（3000-9-132-20）を次の表に示します。

追加・変更内容

監視履歴機能を追加した。
また，これに伴い，環境設定ファイルに次のオペランドを追加した。

HAモニタの環境設定：ph_log_sizeオペランド，ph_thresholdオペランド

サーバ対応の環境設定：ph_thresholdオペランド

適用OSにRed Hat Enterprise Linux AS 4(x86)，Red Hat Enterprise Linux AS 4(IPF)を追加した。
また，これに伴い，次の機能に対応した。

UTF-8（出力言語種別）

LVM2

HAモニタの障害情報のうち，smsファイルの出力方式を変更した。

HAモニタの環境設定のpathpatrol_retryオペランドに記載された見積もり式を変更した。

リセット専用LANを相互に直接接続できるのはマシンの機種がHA8500の場合だけであることを追加した。

(12)　HAモニタ 01-11の変更内容（3000-9-132-10）

HAモニタ 01-11の変更内容（3000-9-132-10）を次の表に示します。

追加・変更内容

適用OSがLinux（x86）の場合に，前提機種として日立アドバンストサーバHA8000シリーズをサポートした。
また，これに伴い，次のコマンドに機能を追加した。

機能追加：monrp，monsetup

カーネル信頼性強化ツールキットfor Linuxと連携して，システムダンプの取得ができるようになった。

他系のOSパニック検知機能をサポートした。
また，これに伴い，次のコマンドに機能を追加した。

機能追加：moncheck

patrolオペランドに指定する系障害監視時間およびサーバ障害監視時間の上限を，60秒から600秒に拡大した。

(13)　HAモニタ 01-10の変更内容（3000-9-132）

HAモニタ 01-10の変更内容（3000-9-132）を次の表に示します。

追加・変更内容

適用OSとしてLinux（x86）をサポートした。
また，これに伴い，次のコマンドを新規に追加，および機能を追加した。

新規追加：monrp

機能追加：monsetup

JP1のイベント通知機能をサポートした。

付録F　このマニュアルの参考情報

このマニュアルを読むに当たっての参考情報を示します。

＜この節の構成＞

付録F.1　関連マニュアル

付録F.2　このマニュアルでの表記

付録F.3　英略語

付録F.4　KB（キロバイト）などの単位表記について

付録F.1　関連マニュアル

HAモニタのマニュアル体系を次に示します。

HAモニタのマニュアル以外で，このマニュアルと関連するマニュアルを次に示します。必要に応じてお読みください。

プログラムにOpenTP1を使用する場合

OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 解説（3000-3-360）

OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 システム定義（3000-3-362）

OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 運用と操作（3000-3-363）

OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 クライアント使用の手引（3000-3-364）

OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 メッセージ（3000-3-368）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 解説（3000-3-941）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 システム定義（3000-3-943）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 運用と操作（3000-3-944）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 メッセージ（3000-3-947）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 クライアント使用の手引 TP1/Client/W，TP1/Client/P編（3000-3-949）

OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 クライアント使用の手引 TP1/Client/J編（3000-3-950）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 解説（3000-3-D50）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 システム定義（3000-3-D52）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 運用と操作（3000-3-D53）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 メッセージ（3000-3-D56）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 クライアント使用の手引 TP1/Client/W，TP1/Client/P編（3000-3-D58）

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 クライアント使用の手引 TP1/Client/J編（3000-3-D59）

OpenTP1 Version 7 分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引（3000-3-F51）

OpenTP1 Version 7 高速トランザクション処理基盤 TP1/EE/Extended Transaction Controller 使用の手引（3000-3-F54）

プログラムにHiRDBを使用する場合

スケーラブルデータベースサーバ HiRDB Version 6 解説（UNIX(R)用）（3000-6-231）

スケーラブルデータベースサーバ HiRDB Version 6 システム導入・設計ガイド（UNIX(R)用）（3000-6-232）

スケーラブルデータベースサーバ HiRDB Version 6 システム定義（UNIX(R)用）（3000-6-233）

スケーラブルデータベースサーバ HiRDB Version 6 システム運用ガイド（UNIX(R)用）（3000-6-234）

スケーラブルデータベースサーバ HiRDB Version 6 コマンドリファレンス（UNIX(R)用）（3000-6-235）

スケーラブルデータベースサーバ HiRDB Version 6 メッセージ（UNIX(R)/Windows(R)用）（3000-6-238）

スケーラブルデータベースサーバ HiRDB Version 7 解説（UNIX(R)用）（3000-6-271）

スケーラブルデータベースサーバ HiRDB Version 7 システム導入・設計ガイド（UNIX(R)用）（3000-6-272）

スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）（3000-6-273）

スケーラブルデータベースサーバ HiRDB Version 7 システム運用ガイド（UNIX(R)用）（3000-6-274）

スケーラブルデータベースサーバ HiRDB Version 7 コマンドリファレンス（UNIX(R)用）（3000-6-275）

スケーラブルデータベースサーバ HiRDB Version 7 メッセージ（UNIX(R)/Windows(R)用）（3000-6-278）

スケーラブルデータベースサーバ HiRDB Version 8 解説（UNIX(R)用）（3000-6-351）

スケーラブルデータベースサーバ HiRDB Version 8 システム導入・設計ガイド（UNIX(R)用）（3000-6-352）

スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用）（3000-6-353）

スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（UNIX(R)用）（3000-6-354）

スケーラブルデータベースサーバ HiRDB Version 8 コマンドリファレンス（UNIX(R)用）（3000-6-355）

スケーラブルデータベースサーバ HiRDB Version 8 メッセージ（3020-6-358）

HiRDB Version 9 解説（UNIX(R)用）（3000-6-451）

HiRDB Version 9 システム導入・設計ガイド（UNIX(R)用）（3000-6-452）

HiRDB Version 9 システム定義（UNIX(R)用）（3000-6-453）

HiRDB Version 9 システム運用ガイド（UNIX(R)用）（3000-6-454）

HiRDB Version 9 コマンドリファレンス（UNIX(R)用）（3000-6-455）

HiRDB Version 9 メッセージ（3020-6-458）

HiRDB Version 9 メモリDB　構築・運用ガイド（3020-6-469）

イベント管理によってシステムの運用を自動化する場合

JP1 Version 7i JP1/Base（3020-3-F04）

JP1 Version 8 JP1/Base 運用ガイド（3020-3-K06）

JP1 Version 8 JP1/Base メッセージ（3020-3-K07）

JP1 Version 9 JP1/Base 運用ガイド（3020-3-R71）

JP1 Version 9 JP1/Base メッセージ（3020-3-R72）

他系のOSパニック検知機能を使用する場合

注文方法については，弊社担当営業にお問い合わせください。

カーネル信頼性強化ツールキット for Linux（3000-7-283）

ディスクパスを冗長化する場合

Hitachi Dynamic Link Manager Software ユーザーズガイド（Linux(R)用）（3000-3-F04）

N+Mコールドスタンバイ構成で系切り替えをする場合

JP1 Version 8 JP1/ServerConductor/Blade Server Manager系 システム管理者ガイド（3020-3-L52）

なお，このマニュアルでは，次のマニュアルを省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

このマニュアルでの表記 | マニュアルの正式名称
JP1/Base 運用ガイド | JP1 Version 7i JP1/Base
JP1 Version 8 JP1/Base 運用ガイド
JP1 Version 9 JP1/Base 運用ガイド
分散トランザクション処理機能 OpenTP1 システム定義 | OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 システム定義
OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 システム定義
OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 システム定義
分散トランザクション処理機能 OpenTP1 運用と操作 | OpenTP1 Version 5 分散トランザクション処理機能 OpenTP1 運用と操作
OpenTP1 Version 6 分散トランザクション処理機能 OpenTP1 運用と操作
OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 運用と操作
分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引 | OpenTP1 Version 7 分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引
HiRDB システム定義 | スケーラブルデータベースサーバ HiRDB Version 6 システム定義（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム定義（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 システム定義（UNIX(R)用）
HiRDB Version 9 システム定義（UNIX(R)用）
HiRDB システム運用ガイド | スケーラブルデータベースサーバ HiRDB Version 6 システム運用ガイド（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 7 システム運用ガイド（UNIX(R)用）
スケーラブルデータベースサーバ HiRDB Version 8 システム運用ガイド（UNIX(R)用）
HiRDB Version 9 システム運用ガイド（UNIX(R)用）
JP1/ServerConductor/Blade Server Manager系 システム管理者ガイド | JP1 Version 8 JP1/ServerConductor/Blade Server Manager系 システム管理者ガイド

付録F.2　このマニュアルでの表記

このマニュアルでは，製品名を次のように表記しています。

表記 | 製品名
AIX | AIX 5L V5.1
AIX 5L V5.2
AIX 5L V5.3
AIX V6.1
AIX V7.1
HA Booster | Hitachi HA Booster Pack for Linux
HDLM | Hitachi Dynamic Link Manager Software
HI-UX/WE2 | HI-UX/workstation Extended Version 2
HiRDB | HiRDB Version 6 | HiRDB/Parallel Server Version 6
HiRDB/Parallel Server Version 6(32)
HiRDB/Parallel Server Version 6(64)
HiRDB/Single Server Version 6
HiRDB/Single Server Version 6(32)
HiRDB/Single Server Version 6(64)
HiRDB Version 7 | HiRDB Advanced High Availability Version 7
HiRDB/Parallel Server Version 7
HiRDB/Parallel Server Version 7(64)
HiRDB/Single Server Version 7
HiRDB/Single Server Version 7(64)
HiRDB Version 8 | HiRDB Advanced High Availability Version 8
HiRDB/Parallel Server Version 8
HiRDB/Parallel Server Version 8(64)
HiRDB/Single Server Version 8
HiRDB/Single Server Version 8(64)
HiRDB Version 9 | HiRDB Accelerator Version 9
HiRDB Advanced High Availability Version 9
HiRDB Server Version 9
HiRDB Server with Additional Function Version 9
JP1/ServerConductor | JP1/ServerConductor/Advanced Agent
JP1/ServerConductor/Agent
JP1/ServerConductor/Blade Server Manager
JP1/ServerConductor/Blade Server Manager Plus
JP1/ServerConductor/Server Manager
Linux | Linux(R)
Linux | Linux（x86） | Red Hat Enterprise Linux AS 3(AMD64 & Intel EM64T)
Red Hat Enterprise Linux AS 3(x86)
Red Hat Enterprise Linux AS 4(AMD64 & Intel EM64T)
Red Hat Enterprise Linux AS 4(x86)
Red Hat Enterprise Linux ES 3(x86)
Red Hat Enterprise Linux ES 4(AMD64 & Intel EM64T)
Red Hat Enterprise Linux ES 4(x86)
Red Hat Enterprise Linux 5(x86)
Red Hat Enterprise Linux 5 Advanced Platform(x86)
Red Hat Enterprise Linux 5(AMD/Intel 64)
Red Hat Enterprise Linux 5 Advanced Platform(AMD/Intel 64)
Red Hat Enterprise Linux server 6(x86)
Red Hat Enterprise Linux server 6(x86_64)
Linux（IPF） | Red Hat Enterprise Linux AS 3(IPF)
Red Hat Enterprise Linux AS 4(IPF)
Red Hat Enterprise Linux 5 Advanced Platform(Intel Itanium)
OpenTP1 | TP1/High Availability | TP1/High Availability
uCosminexus TP1/High Availability
uCosminexus TP1/High Availability(64)
TP1/Message Control | TP1/Message Control
uCosminexus TP1/Message Control
uCosminexus TP1/Message Control(64)
TP1/NET/High Availability | TP1/NET/High Availability
uCosminexus TP1/NET/High Availability
uCosminexus TP1/NET/High Availability(64)
TP1/NET/Library | TP1/NET/Library
uCosminexus TP1/NET/Library
uCosminexus TP1/NET/Library(64)
TP1/NET/TCP/IP | TP1/NET/TCP/IP
uCosminexus TP1/NET/TCP/IP
uCosminexus TP1/NET/TCP/IP(64)
TP1/Server Base | TP1/Server Base
uCosminexus TP1/Server Base
uCosminexus TP1/Server Base(64)
TP1/EE | uCosminexus TP1/Server Base Enterprise Option
uCosminexus TP1/Server Base Enterprise Option(64)
TP1/EE/XTC | uCosminexus TP1/EE/Extended Transaction Controller
UNIX | UNIX(R)
vCenter | VMware vCenter(TM) Server
VMware ESXi | VMware ESXi 4.1
VMware vSphere Client | VMware vSphere(R) Client
VxFS | VERITAS File System

付録F.3　英略語

このマニュアルで使用する英略語を，次に示します。

英略語 | 英字での表記
API | Application Programming Interface
ARP | Address Resolution Protocol
BMC | Baseboard Management Controller
C/S | Client/Server
CPU | Central Processing Unit
DB | Database
DHCP | Dynamic Host Configuration Protocol
DNS | Domain Name System
EUC | Extended UNIX Code
FEP | Front-End Processor
FS | File System
HA | High Availability
HBA | Host Bus Adapter
HVM | Hitachi Virtage Manage
I/O | Input/Output
ICMP | Internet Control Message Protocol
IPF | Itanium(R) Processor Family
LAN | Local Area Network
LPAR | Logical Partition
LVM | Logical Volume Manager
MAC | Media Access Control
MP | Management Processor
OLTP | Online Transaction Processing
OS | Operating System
OSI | Open Systems Interconnection
PC | Personal Computer
RAID | Redundant Arrays of Inexpensive Disks
SOA | Service Oriented Architecture
SPP | Service Providing Program
SSH | Secure SHell
SVP | Service Processor
TCP/IP | Transmission Control Protocol/Internet Protocol
UAP | User Application Program
UTF-8 | 8-bit UCS Transformation Format
WS | Workstation
XDS | Extended Data Server
XNF | Extended Hitachi Network Architecture Based Communication Networking Facility

付録F.4　KB（キロバイト）などの単位表記について

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

付録G　用語解説

英字｜ア行｜カ行｜サ行｜タ行｜ハ行｜マ行｜ヤ行｜ラ行

英字

aliveメッセージ

系と系との間で相手が正常であるかどうかを知るために，一定の周期で発行するメッセージです。

HAモニタ Extension

HAモニタのオプション製品です。HAモニタ Extensionを導入することによって，大規模なシステム構成での系切り替え制御に対応できるようになります。HAモニタ Extensionは，OSがLinux（x86）の場合に使用できます。

HAモニタとのインタフェースを持たないプログラム

HAモニタと専用のインタフェースを持たないプログラムのことです。待機系のプログラムを事前に起動させておいたり，サーバ障害を監視したりするなどのHAモニタの機能を一部使用できません。

HAモニタでは，HAモニタとのインタフェースを持つプログラムをモニタモードで運用する場合と，HAモニタとのインタフェースを持たないプログラムを使用する場合とで，制限される機能に差はありません。

HAモニタとのインタフェースを持つプログラム

HAモニタと専用のインタフェースを持つプログラムのことです。HAモニタとのインタフェースを持つプログラムをサーバモードで運用すると，系障害とサーバ障害の両方をHAモニタが監視します。

HAモニタは，HAモニタとのインタフェースを持つプログラムを監視して，プログラム自身が検知できない障害が発生した場合，系切り替えをします。

IPアドレス

IPプロトコルで使われるアドレスを，IPアドレスといいます。IPプロトコルとは，OSI基本参照モデルでいうネットワーク層に当たるプロトコルです。ネットワーク層では，データを転送するための経路を確立したり，経路を決めたりするアドレスを管理しています。

LANアダプタ

コンピュータとLANを接続するためのデータ変換用のハードウェアです。

LVM

カーネルの機能の一つで，Logical Volume Managerの略です。LVMを使用すると，幾つかの物理ディスク装置をボリュームグループとしてグループ化し，任意の数とサイズの論理ボリュームに割り当てられます。

N+Mコールドスタンバイ構成

BladeSymphonyの場合で，業務を運用中のサーバモジュールでハードウェア障害が発生したときに，JP1/ServerConductorを利用して予備のサーバモジュールに切り替えられるシステム構成のことです。1台または複数台の予備のサーバモジュールを用意するため，障害に対する信頼性が向上します。

OSパニック

OSのカーネルパニックのことです。

TCP/IP

UNIXを使用したコンピュータ間の接続などに用いられる，標準的な通信プロトコルです。「TCP」と「IP」の，二つのプロトコルに対応しています。

UAP

ユーザの業務をプログラムとして作成したものです。モニタモードのサーバの場合に，プログラムとして使用できます。HAモニタでは，UAPからAPIを発行することで，UAPを監視できます。

UDP

UNIXを使用したコンピュータ間の接続などに用いられる，標準的な通信プロトコルです。このようなプロトコルとしてはTCPも利用されますが，UDPはTCPに比べ転送速度が速く信頼性が低いという特徴があります。

ア行

イベントID

UNIXシステム内で発生した特定の事象（イベント）を管理するために，イベントに付ける番号です。

エイリアスIPアドレス機能

一つのLANアダプタに複数のIPアドレスを割り当てることで，異なるIPアドレスで一つのLANアダプタを共用できる機能です。

親サーバ

あるサーバを起動，または系切り替えを開始するために，あらかじめ起動完了している必要のあるサーバです。サーバグループの親子関係では親に該当します。サーバ対応の環境設定で指定します。

カ行

カーネル

OSの中核部分のプログラムです。タスク管理，メモリ管理，入出力管理などをします。

稼働報告

サーバが一定時間ごとにHAモニタに送信する情報です。HAモニタはこの情報を基にサーバを監視します。

可搬媒体

プログラムやデータを記憶させて持ち運べる，DATなどの記憶媒体です。

筐体

コンピュータ本体や周辺機器を収納するケースです。使用しているマシンの機種がBladeSymphonyの場合，筐体を「シャーシ」と呼びます。一つのシャーシには複数の系を構成できます。

共有リソース

共有ディスクやLANなど，実行系および待機系の系間で共有するリソースのことです。HAモニタが制御する共有リソースには，共有ディスク，ファイルシステム，およびLANがあります。共有リソースは，サーバ単位で制御します。

また，リソースサーバを使用し，サーバグループ間で共有リソースを共用することもできます。

クライアント

プログラムが提供する各種のサービスを利用するマシン（ノード）です。

クラスタ型構成

1台のサーバシステムの限界を超えるシステムを構築するための構成です。複数のサーバシステムを高速LANで接続し，個々のサーバシステムに処理を分散させます。クライアントからは，一つのサーバシステムとして処理できます。

系

CPU単位でサーバが稼働するシステムの単位を示します。システムを構成するハードウェア，およびシステム上で稼働するプログラムを総称して「系」といいます。

系切り替え

業務を実行しているシステム（系）やサーバに障害が発生した場合に，待機しているシステム（系）やサーバに業務を引き継ぐ機能のことです。

系切り替え待ち状態

実行系の障害時に待機系が実行系のリセットに失敗し，何らかの原因で実行系のサーバの状態が確認できない場合，待機系で実行サーバを起動すると実行サーバの二重起動が発生することがあります。これを防ぐために，待機系での実行サーバの起動をいったん待たせます。この状態の実行サーバを系切り替え待ち状態であるといいます。系切り替え待ち状態のサーバは，ユーザが操作するまでは実行サーバとして起動されません。

系のスローダウン

系全体の実行処理時間が通常以上に長くなることです。限度を超えたプログラム数の実行や，プログラム間の通信不良などが原因で起こります。

現用系

起動してから最初に業務処理を実行するシステム（系）です。

コアファイル

プログラムが異常終了時に，そのプロセスのメモリ情報（モジュールトレース情報）が格納されるOS特定のファイルです。なお，コアファイルは，場合によっては作成されません。コアファイルがあると，ユーザ作成のプログラムに異常が起きた場合などに，OSのコマンドを使ってプログラムのデバッグができます。

子サーバ

親サーバの起動完了後に，起動開始するサーバです。サーバグループの親子関係では子に該当します。

サ行

サーバ

要求に応じて業務を処理するサービスです。このマニュアルでは，系切り替えの単位としてのプログラムを「サーバ」といいます。

サーバには大きく分けて，サーバモードのサーバと，モニタモードのサーバがあります。

サーバシステムの二重化

サーバが稼働するシステムのマシン，プログラム，およびリソースなどを二つ用意する（または二重化できるものを共有させる）ことによって，システム全体の信頼性や稼働率を高めることです。

サーバのスローダウン

サーバの実行処理時間が通常以上に長くなることです。プログラムの無限ループ，リソースの競合などが原因で起こります。

サーバ引き継ぎ情報

実行サーバと待機サーバの間にペアが成立した際，実行サーバから待機サーバに引き継がれる情報です。ユーザコマンド内でサーバ間のやり取りが必要な場合に，HAモニタのサーバ引き継ぎ情報設定・表示コマンド（moninfo -pコマンド）で設定しておき，サーバ引き継ぎ情報設定・表示コマンド（moninfo -gコマンド）で参照・表示します。

サーバモード

サーバの運用方法の一つで，プログラムがHAモニタとのインタフェースを持つ場合だけ選択できます。サーバをサーバモードで運用すると，系障害とサーバ障害の両方をHAモニタが監視します。

再起動待ち状態

サーバ対応の環境設定のswitchtypeオペランドで，restartまたはmanualを指定した実行サーバにサーバ障害が発生した場合，実行サーバを停止させないで，実行サーバが再起動するのを待たせます。この状態の実行サーバを再起動待ち状態であるといいます。

システムダンプ

特定のプログラムに限定できない障害情報を，可搬媒体に格納するOSの機能です。システムダンプでは，メモリ情報，スワップ領域（仮想メモリ）の情報，および処理装置固有の情報を取得できます。一般に，システムのどこに原因があるのかわからない障害時にシステムダンプを使います。

実行系

実行サーバを稼働させて，業務処理を実行しているシステム（系）です。

実行サーバ

現在，業務処理を実行しているサーバです。

実行サーバの起動待ち状態

待機サーバの起動時，何らかの原因で他系の実行サーバの起動が確認できない場合があります。このとき，実行サーバの状態が確認できるまで待機サーバの起動を待たせます。このような待機サーバを，実行サーバの起動待ち状態であるといいます。起動待ち状態の待機サーバはユーザの操作待ちになり，実行サーバの起動開始が確認できるようになったら，待機サーバとして起動させます。

制御グループID

HA Boosterが管理する，個々の制御グループに割り当てた値です。制御グループは，HA Boosterがアクセス制御の対象とするディスクデバイスの集まりです。HA Boosterを使用する場合，サーバ対応の環境設定に設定する必要があります。

タ行

待機系

待機サーバを稼働させて，障害に備えて待機しているシステム（系）です。

待機サーバ

現在，実行サーバの障害に備えて待機しているサーバです。

ハ行

パーティション

サーバマシンを複数の区画に分割し，それぞれを一つの仮想的なサーバマシンとして動作させる機能を，パーティショニングといいます。また，この区画をパーティションといいます。

BladeSymphonyの場合，一つの筐体（シャーシ）に複数のプロセサを搭載できることから，個々のプロセサをパーティションと呼ぶことがあります。また，日立サーバ仮想化機構（Virtage）を利用すると，プロセサ内に論理パーティション（LPAR）を構成できます。

排他サーバ

待機系に別のサービスを提供する待機サーバが複数ある場合，系切り替えによって複数の実行サーバが同時に稼働するのを避けることができます。

ある待機サーバが実行サーバとして稼働すると，同じ系で稼働しているほかの待機サーバをHAモニタが停止します。この停止される待機サーバのことを排他サーバと呼びます。

排他制御

システムのリソースに対して複数の要求が競合した場合，同時更新やデッドロックを防ぐための制御のことです。HAモニタでは，共有ディスクが，実行サーバと待機サーバの両方から同時に更新されるのを防ぐ機能を，「排他制御機能」といいます。

プログラム

業務を実際に実行するプログラム（アプリケーション）のことです。HAモニタは，プログラムを系切り替え構成にすることで冗長化し，システムの信頼性を向上します。

プログラムは，HAモニタとのインタフェースを持つプログラムと持たないプログラムに分けられます。

マ行

マルチスタンバイ機能

一つの実行サーバに対して，複数の待機サーバを準備するための機能のことです。

一つの実行サーバに対して一つの待機サーバを準備する場合に比べると，現用系の障害が復旧するまでの間も，システムの障害に備えることができるという特長があります。

メッセージログ

出力されるメッセージを特定のファイル（メッセージログファイル）に格納するOSの機能です。

モジュールトレース情報

HAモニタ内のモジュール処理の流れを，モジュールトレースバッファ（コアファイル）に取得したものです。モジュールトレース情報は，可搬媒体に移送して解析します。

モニタモード

サーバの運用方法の一つです。サーバをモニタモードで運用する場合，待機系のサーバを事前に起動させておいたり，サーバ障害を監視したりするなどの，HAモニタの機能の一部を使用できません。ただし，モニタモードのプログラム管理機能を使用すれば，使用できない機能の一部を使用することもできます。

ヤ行

ユーザコマンド

ユーザが作成するコマンドです。HAモニタでは，事前にユーザコマンドを登録しておくことで，サーバの状態変化に対するHAモニタの処理を契機に，ユーザコマンドを自動発行できます。ユーザコマンドを使用すると，HAモニタが制御しないリソースを共有リソースとして使用できます。

予備系

起動時に最初に稼働状態で待機するシステム（系）です。

ラ行

リソースサーバ

複数サーバで共有リソースを共用するためだけに使用するサーバです。そのため，サーバとしての機能は持ちません。

リソースサーバを使用しない場合，サーバ単位で共有リソースを制御するのに対し，リソースサーバを使用する場合はサーバグループ単位で共有リソースを制御します。

連動系切り替え

サーバをあらかじめグループ化しておくことで，そのグループ（サーバグループ）内の実行サーバのどれかに障害が発生した場合に，グループ単位で待機サーバに切り替える機能です。HAモニタでは，サーバグループ内でも，サーバ単位に系切り替え時の動作を指定できます。

連動系切り替え待ち状態

サーバ対応の環境設定のgroupオペランドで，no_exchangeを指定した実行サーバにサーバ障害が発生した場合，待機系の待機サーバの系切り替えをいったん待たせます。この状態の待機サーバを連動系切り替え待ち状態であるといいます。連動系切り替え待ち状態の待機サーバは，ユーザの操作待ちになりますが，グループ内のexchange指定の実行サーバにサーバ障害が発生すると，一緒に連動系切り替えをします。

索引

[数字]
[Ａ][Ｂ][Ｃ][Ｄ][Ｅ][Ｆ][Ｇ][Ｈ][Ｉ][Ｊ][Ｌ][Ｍ][Ｎ][Ｏ][Ｐ][Ｒ][Ｓ][Ｔ][Ｕ][Ｖ][Ｗ]
[ア行][カ行][サ行][タ行][ナ行][ハ行][マ行][ヤ行][ラ行]

(数字)

1:1系切り替え構成

環境設定例

ハードウェア構成例（BladeSymphony（Basicモード））〔1シャーシ構成〕

ハードウェア構成例（BladeSymphony（Basicモード））〔2シャーシ構成〕

ハードウェア構成例（BladeSymphony（LPARモード））〔1シャーシ構成〕

ハードウェア構成例（BladeSymphony（LPARモード））〔2シャーシ構成〕

ハードウェア構成例（HA8000）

ハードウェア構成例（HA8500）

2:1系切り替え構成

環境設定例

ハードウェア構成例（BladeSymphony（Basicモード））

ハードウェア構成例（BladeSymphony（LPARモード））

ハードウェア構成例（HA8000）

ハードウェア構成例（HA8500）

(英字)

(Ａ)

actcommand

acttype

address

alias〔program定義文〕

alias〔resource定義文〕

alias〔server定義文〕

alive_interval

alive_multicast

aliveメッセージ

alive_interval〔送信間隔〕

alive_multicast〔マルチキャストでの送受信〕

multicast_lan〔マルチキャストでの送受信〕

suppress_reset〔系のリセットの抑止〕

aliveメッセージ〔用語解説〕

aliveメッセージによる系障害の検出

aliveメッセージの通信方式

API

コーディング例

詳細コードの一覧

APIの一覧

ARPリクエスト

(Ｂ)

BMC

(Ｃ)

cancel

connect_retry

connection

cpudown

(Ｄ)

dev_timelimit

deviceoff_order〔function定義文〕

deviceoff_order〔server定義文〕

disk

(Ｅ)

environment定義文

exchange

exclusive_servers

exec_retry

exitcode

(Ｆ)

fs_log_size

fs_mount_dir

fs_mount_opt

fs_name

fs_neck

fs_umount_retry

fsckコマンド

function定義文

fuserコマンド

(Ｇ)

group〔resource定義文〕

group〔server定義文〕

(Ｈ)

hab_discnt_atend

hab_gid

HA Booster

hab_discnt_atend

hab_gid

環境設定例

共有ディスク

共有ディスクの管理

制御グループの設定

他系のOSパニック検知機能

HAMON_API_PATROL環境変数

hamon_patrolstart

hamon_patrolstop

HAMON_UAPNAME環境変数

HAモニタ

監視する範囲

起動

起動を自動化する

検出する障害

停止

動作確認

必要なソフトウェア

必要なハードウェア

目的

HAモニタ・サーバ稼働中の設定変更

HAモニタ・サーバ稼働中の設定変更〔コマンド〕

HAモニタ Extension

hostmax〔系の最大数の変更〕

servmax〔サーバの最大数の変更〕

機能

系の最大数の変更

系の最大数を変更する場合の考慮点

系の最大数を変更する場合の動作確認

サーバの最大数の変更

システム構築の流れ

設定

ファイルの設定例

HAモニタ Extension〔用語解説〕

HAモニタ間の手動接続〔コマンド〕

HAモニタとのインタフェースを持たないサーバ

HAモニタとのインタフェースを持たないプログラム

HAモニタとのインタフェースを持たないプログラム〔用語解説〕

HAモニタとのインタフェースを持つサーバ

HAモニタとのインタフェースを持つプログラム

HAモニタとのインタフェースを持つプログラム〔用語解説〕

HAモニタの環境設定

変更

HAモニタの環境設定〔コマンド〕

HAモニタの起動〔コマンド〕

HAモニタの接続構成設定ファイル

作成例

HAモニタの停止〔コマンド〕

HAモニタのトラブルシュート情報の収集〔コマンド〕

HiRDB

hostmax

HUBの冗長化

(Ｉ)

I/Oパスの冗長化

initial

ip_neck

IPアドレス

IPアドレスの数

IPアドレスを割り当てる対象

エイリアスIPアドレス

監視パス

サーバに割り当てるIPアドレス

ステーショナリIPアドレス

IPアドレス〔用語解説〕

IPアドレスの検出〔コマンド〕

(Ｊ)

JP1

jp1_event

JP1のイベント

jp1_event

(Ｌ)

LAN

lan

LAN

ip_neck〔サーバ識別名.upファイル〕

切り替え

サーバ識別名.downファイル

サーバ識別名.upファイル

接続

引き継ぎ

lan_updown

lancheck_patrol

lanfailswitch

LANG環境変数

lanport

LANアダプタ〔用語解説〕

LANアダプタの冗長化

LAN監視スクリプトの設定

LAN監視定義ファイルの設定

LANの監視

lancheck_patrol〔LANの監視間隔〕

lanfailswitch

lanpatrol.sh

LANインタフェース名称.conf

LAN監視スクリプト

LAN監視定義ファイル

patrol_100ms〔LANインタフェース名称〕

switchbyfail

環境設定例

LANの監視設定ファイル

LANの状態設定ファイル

lan_updown

LPAR

partition_reset〔物理パーティションリセット機能〕

考慮点

物理パーティションリセット機能

LVM〔用語解説〕

(Ｍ)

MACアドレス

manual

message_retry

monact

monbegin

monbegin_restart

monchange

moncheck

mondeact

mondevice

mondeviceコマンドを使用した共有リソースの動的変更

monend

moninfo

monlink

monlistip

monmp

monodrshw

monpath

monresbgn

monresend

monressbystp

monrp

monsbystp

monsetup

monshow

monstart

monstop

monswap

monts

montsコマンドを使用した障害情報の収集

MP

IPアドレス

MPの状態表示〔コマンド〕

multicast_lan

multistandby

(Ｎ)

N+Mコールドスタンバイ構成

N+Mコールドスタンバイ構成〔用語解説〕

N+Mコールドスタンバイ構成での系切り替え

name〔environment定義文〕

name〔program定義文〕

name〔server定義文〕

netmask

no_cancel

no_exchange

(Ｏ)

oldsms

OpenTP1

OSパニック〔用語解説〕

(Ｐ)

pairdown

parent

partition_reset

pathpatrol

pathpatrol_retry

PATH環境変数

patrol〔environment定義文〕

patrol〔program定義文〕

patrol〔server定義文〕

patrol_100ms

patrol_typ

patrolcommand

pgmmax

ph_log_size

ph_threshold〔function定義文〕

ph_threshold〔server定義文〕

program

programs

program定義文

(Ｒ)

RAIDによるデータの冗長化

reset_type

resetpatrol

resetpatrol_mode

resource定義文

restart

restart_timeout

restartcommand

retry_stable〔program定義文〕

retry_stable〔server定義文〕

(Ｓ)

server_alias

server_type

servers

servers_opt

server定義文

servexec_retry

servmax

sms

standbypri

standbyreset

start_timeout

stop_timeout

suppress_reset

SVP

IPアドレス

ポート番号

switch

switchbyfail

switchtype

sysdef

(Ｔ)

TCP/IP〔用語解説〕

termcmd_at_abort

termcommand

(Ｕ)

UAP

APIの組み込み

HAモニタが提供するファイル

稼働報告の監視

環境変数の設定

監視

コンパイルとリンケージ

障害に対処する

処理の流れ

プロセスの監視

UAP〔用語解説〕

UAPの監視開始〔API〕

UAPの監視終了〔API〕

UAPへのAPIの組み込み

UDP〔用語解説〕

uoc_neck

usrcommand

(Ｖ)

vg_neck

vg_off

vg_on_opt

vgchangeコマンド

vg_on_opt

Virtage

vmware_env

VMware ESXi

IPアドレス

partition_reset〔物理パーティションリセット機能〕

vmware_env

考慮点

設定

ハードウェア構成例（BladeSymphony（Basicモード））

ハードウェア構成例（HA8000）

物理パーティションリセット機能

(Ｗ)

waitserv_exec

(ア行)

(あ)

アンマウント

(い)

イベントID

イベントID〔用語解説〕

(え)

エイリアスIPアドレス機能〔用語解説〕

(お)

親子関係

parent

親サーバ

親サーバ〔用語解説〕

(カ行)

(か)

カーネル〔用語解説〕

仮想マシン

partition_reset〔物理パーティションリセット機能〕

物理パーティションリセット機能

稼働報告〔用語解説〕

可搬媒体〔用語解説〕

監視パス

/etc/hostsファイル

/etc/servicesファイル

IPアドレス

lan

pathpatrol〔ヘルスチェック〕

pathpatrol_retry〔状態の再チェック〕

接続方法

設定

複線化

ヘルスチェック

ポート番号

ホスト名

優先して使用する監視パス

監視パスの状態表示〔コマンド〕

監視履歴

ph_log_size

ph_threshold〔サーバ監視履歴取得時間〕〔function定義文〕

ph_threshold〔サーバ監視履歴取得時間〕〔servers定義文〕

監視履歴ファイル

出力されるメッセージ

(き)

起動

HAモニタによるサーバの起動

サーバの監視コマンド

システムの起動からサーバの起動までを自動化する

システムを起動する

起動・停止

筐体〔用語解説〕

共有ディスク

/etc/rc.sysinitファイルの編集例（LVM2を使用する場合）

/etc/rc.sysinitファイルの編集例（LVMを使用する場合）

disk

OS移行後の共有ディスクの運用

切り替え

切り替え〔HA Booster使用時〕

構成

接続

接続〔HA Booster使用時〕

設定

引き継ぎ

ボリュームグループの作成

共有リソース

dev_timelimit〔タイムアウト〕

deviceoff_order〔切り離し順序〕〔function定義文〕

deviceoff_order〔切り離し順序〕〔servers定義文〕

disk

fs_mount_dir

fs_mount_opt

fs_name

fs_neck

fs_umount_retry

hab_discnt_atend

hab_gid

ip_neck

uoc_neck

vg_neck

vg_on_opt

競合防止

切り離し失敗に対処する

切り離し順序指定

構成を変更する

サーバが使用する共有リソースの設定

状態

制御するためのユーザコマンド

接続失敗時のサーバの起動中止

接続失敗に対処する

タイムアウト

動的変更

変更する

メンテナンスする

共有リソース〔用語解説〕

切り替え元の系のサーバについて

(く)

クライアント〔用語解説〕

クラスタ型系切り替え構成

環境設定例

ハードウェア構成例（BladeSymphony（Basicモード））

ハードウェア構成例（BladeSymphony（LPARモード））

ハードウェア構成例（HA8000）

ハードウェア構成例（HA8500）

クラスタ型構成〔用語解説〕

(け)

系

address

cpudown

name〔environment定義文〕

pairdown〔系のペアダウン〕

patrol〔系障害監視時間〕〔environment定義文〕

reset_type

standbyreset

監視履歴を取得する

系監視履歴取得時間

系障害監視時間

系の起動失敗に対処する

系のペアダウン

系のリセット失敗に対処する

障害が発生した系を再起動する

状態確認

追加する

リセット

リセットの抑止

系〔用語解説〕

計画系切り替え〔コマンド〕

計画系切り替え，およびモニタモードのサーバ障害時の順序制御

系切り替え

計画系切り替え〔運用〕

計画系切り替え〔概要〕

系切り替えができる状態

自動系切り替え

障害発生による系切り替え時の運用

テスト

連動系切り替え

系切り替え〔用語解説〕

系切り替え構成

系切り替え構成の違い

構成設計時の考慮点

種類と特徴

リセットパスを共用する場合の注意事項

系切り替えの流れ

系障害時の系切り替え

サーバ障害時の系切り替え

サーバの排他制御をする場合の系切り替え

マルチスタンバイ機能を使用した場合の系切り替え

ユーザがリセット優先系を指定しないときの系切り替え

ユーザがリセット優先系を指定するときの系切り替え

リソースサーバを使用した場合の系切り替え

系切り替え待ち状態

系切り替え待ち状態〔用語解説〕

系障害

monbegin_restart〔系切り替え後の運用の自動化〕

系切り替え後の運用を自動化する

系切り替えをする条件

系のスローダウン〔用語解説〕

現用系

現用系〔用語解説〕

(こ)

コアファイル〔用語解説〕

子サーバ

子サーバ〔用語解説〕

コマンド一覧

コンソール

(サ行)

(さ)

サーバ

actcommand〔サーバの起動コマンド〕

acttype〔起動方法〕

group〔グループ化〕〔resource定義文〕

group〔グループ化〕〔server定義文〕

initial〔起動種別〕

parent〔起動順序と親子関係の対応〕

patrol〔サーバ障害監視時間〕〔server定義文〕

ph_threshold〔サーバ監視履歴取得時間〕〔servers定義文〕

server_type〔監視方法〕

termcommand〔サーバの停止コマンド〕

運用方法

エイリアスIPアドレス

環境設定例

監視履歴を取得する

起動

起動順序と親子関係の対応

起動を自動化する

切り替え順序制御

グループ化

サーバ監視履歴取得時間

サーバ障害監視時間

サーバとプログラムの関係

サーバの数

サーバの監視コマンド

サーバの監視方法〔モニタモード〕

サーバの起動コマンド

サーバの再起動失敗に対処する

サーバの停止コマンド

実行サーバと待機サーバの決定方法

実行サーバと待機サーバの決定方法〔マルチスタンバイ機能使用時〕

状態遷移

追加する

定義するオペランド一覧

停止

動作確認

排他制御

複数のサーバを使用する場合の考慮点

分類

待ち状態

サーバ〔用語解説〕

サーバ識別名

alias〔resource定義文〕

alias〔server定義文〕

サーバ識別名.downファイルの設定

サーバ識別名.upファイルの設定

サーバシステムの二重化

サーバシステムの二重化〔用語解説〕

サーバ順序制御の状態表示〔コマンド〕

サーバ障害

pairdown

switchtype〔サーバ障害検出時の動作〕

系切り替え後の運用を自動化する

系切り替えをする条件

サーバ障害の検出（サーバモードの場合）

サーバ障害の検出（モニタモードの場合）

サーバ障害の検出方法〔サーバモード〕

サーバ障害を検出したあとのHAモニタの動作〔サーバモード〕

サーバ障害を検出したあとのHAモニタの動作〔モニタモード〕

サーバ対応の環境設定

変更

サーバと系の状態表示〔コマンド〕

サーバの監視コマンド

patrolcommand

起動

停止

サーバの起動コマンド

actcommand

name〔server定義文〕

サーバの切り替え順序制御

環境設定例

系切り替えが失敗した場合の動作

処理の流れ

サーバのスローダウン〔用語解説〕

サーバの停止コマンド

termcommand

サーバの排他制御

環境設定例

排他サーバの環境設定

サーバ引き継ぎ情報〔用語解説〕

サーバモード

サーバモード〔用語解説〕

サーバモードのサーバ障害時の順序制御の流れ

サービス名

lanport

再起動待ち状態〔用語解説〕

(し)

自系のスローダウン認識

システム構築の流れ

システムダンプ〔用語解説〕

システムの起動の流れ

システムの自動化

システムの動作確認

実行系

実行系〔用語解説〕

実行系でのサーバ引き継ぎ情報の設定〔コマンド〕

実行サーバ

系切り替え待ち状態

再起動監視時間

再起動限界

再起動待ち状態〔運用〕

再起動待ち状態〔解説〕

実行サーバ〔用語解説〕

実行サーバ稼働中の共有リソースの変更〔コマンド〕

実行サーバの起動待ち状態〔用語解説〕

実行中のリソースサーバの停止〔コマンド〕

障害

系障害

高負荷によるサーバや系のスローダウンを防止する

サーバ障害

障害情報を収集する

他系のOSパニック

障害管理プロセサ

IPアドレスの登録〔HA8500〕

LANポート

障害管理プロセサとリセットパスの接続方法

障害管理プロセサのログイン名およびパスワード

状態

サーバ

プログラム

リソースサーバ

処理の流れ

UAP障害時の系切り替え〔モニタモード〕〔UAP監視時〕

共有リソースとの接続・切り離し〔リソースサーバ〕

系障害時の系切り替え〔サーバモード〕

系障害時の系切り替え〔モニタモード〕

系障害時の系切り替え失敗〔サーバモード〕

系障害時の系切り替え失敗〔サーバモード〕〔逆順に切り離す場合〕

系障害時の系切り替え失敗〔モニタモード〕

系障害時の系切り替え失敗〔モニタモード〕〔逆順に切り離す場合〕

系障害時の順序制御

サーバ障害時の系切り替え〔サーバモード〕

サーバ障害時の系切り替え〔サーバモード〕〔逆順に切り離す場合〕

サーバ障害時の系切り替え〔モニタモード〕

サーバ障害時の系切り替え〔モニタモード〕〔UAP監視時〕

サーバ障害時の系切り替え〔モニタモード〕〔逆順に切り離す場合〕

サーバ障害時の系切り替え失敗〔サーバモード〕

サーバ障害時の系切り替え失敗〔サーバモード〕〔逆順に切り離す場合〕

サーバ障害時の系切り替え失敗〔モニタモード〕

サーバ障害時の系切り替え失敗〔モニタモード〕〔逆順に切り離す場合〕

サーバの起動〔サーバモード〕

サーバの起動〔モニタモード〕

サーバの起動〔モニタモード〕〔UAP監視時〕

サーバの停止〔サーバモード〕

サーバの停止〔サーバモード〕〔逆順に切り離す場合〕

サーバの停止〔モニタモード〕

サーバの停止〔モニタモード〕〔UAP監視時〕

サーバの停止〔モニタモード〕〔逆順に切り離す場合〕

モニタモードのサーバの監視

(す)

スローダウン

系のスローダウン

原因を調査する

サーバのスローダウン

(せ)

制御グループ

制御グループID〔用語解説〕

接続処理の間隔・回数

connect_retry

設定

DNS

HAモニタの接続構成

LAN

カーネルのパラメタ

監視パス

キャラクタ型スペシャルファイル

共有ディスク

システムクロック

システムファイル

システムログファイル

出力言語種別

障害管理プロセサ〔HA8500〕

セキュリティレベル

ファイルシステム

リセット手順ファイル〔HA8500〕

リセットパス〔BladeSymphony〕

リセットパス〔HA8000〕

(そ)

相互系切り替え構成

環境設定例

(タ行)

(た)

待機系

standbyreset〔待機系のリセット〕

待機系〔用語解説〕

待機系でのサーバ引き継ぎ情報の参照・表示〔コマンド〕

待機サーバ

実行サーバの起動待ち状態

排他サーバ

連動系切り替え待ち状態

待機サーバ〔用語解説〕

待機サーバの停止〔コマンド〕

待機中のリソースサーバの停止〔コマンド〕

他系のOSパニック検知機能

(て)

定義チェック

定義チェック〔コマンド〕

定義ファイル

停止

HAモニタによるサーバの停止

サーバの監視コマンド

システムを停止する

ディレクトリ構成

(と)

問い合わせ応答メッセージのリトライ

message_retry

(ナ行)

(ね)

ネットマスク

netmask

ネットワークアドレス

(ハ行)

(は)

パーティション〔用語解説〕

排他サーバ〔用語解説〕

排他制御〔用語解説〕

(ひ)

引き継ぎ

日立サーバ仮想化機構

partition_reset〔物理パーティションリセット機能〕

物理パーティションリセット機能

(ふ)

ファイルシステム

fs_log_size

fs_mount_dir

fs_mount_opt

fs_name

fs_neck

fs_umount_retry

運用

環境設定例

切り替え

サーバ識別名.fslog

サーバ識別名.fslog_old

接続

設定

引き継ぎ

負荷

高負荷による障害発生を防止するための運用

テスト

複数系切り替え構成間での設定・定義のチェック

複数スタンバイ構成

multistandby

standbypri〔優先度〕

環境設定例（TP1/EE）

環境設定例（TP1/Server BaseまたはHiRDB）

ハードウェア構成例（HA8000）

ハードウェア構成例（HA8500）

複線化した監視パスに割り当てるIPアドレス

物理パーティションリセット機能

partition_reset

プライマリ機能提供サーバ

プログラム〔用語解説〕

プロセサ

(ほ)

ホスト名

lan

name〔environment定義文〕

ボリュームグループ

vg_neck

vg_off

切り離し

参照＋更新接続

ボリュームグループ名.vglog

ボリュームグループ名.vglog_old

(マ行)

(ま)

マウント

待ち状態

待ち状態のサーバの停止〔コマンド〕

待ち状態のサーバを実行サーバとして起動〔コマンド〕

マルチスタンバイ機能

multistandby

standbypri〔優先度〕

マルチスタンバイ機能〔用語解説〕

(め)

メッセージログ〔用語解説〕

(も)

モジュールトレース情報〔用語解説〕

モニタモード

actcommand

patrolcommand

retry_stable〔server定義文〕

servexec_retry

start_timeout〔サーバ起動時のタイムアウト〕

stop_timeout〔サーバ停止時のタイムアウト〕

termcmd_at_abort〔サーバの停止コマンド〕

waitserv_exec

サーバの監視

プログラム管理機能

モニタモード〔用語解説〕

モニタモードのサーバの起動〔コマンド〕

モニタモードのサーバの停止〔コマンド〕

モニタモードのプログラム

pgmmax〔プログラムの最大数の変更〕

再起動

再起動確認

状態遷移

プログラムの数

プログラムの再起動限界

プログラムの再起動コマンド

プログラムのスローダウン監視時間

モニタモードのプログラム管理機能

alias

exec_retry

name〔program定義文〕

patrol〔program定義文〕

pgmmax

program

restart_timeout

restartcommand

retry_stable〔program定義文〕

server_alias

UAPの監視

環境設定例

モニタモードのプログラム対応の環境設定

変更

(ヤ行)

(ゆ)

ユーザコマンド

JP1イベントとの使い分け

uoc_neck

usrcommand

コーディング例

作成方法

発行形式（HAモニタの状態変化時）

発行形式（サーバの状態変化時）

発行タイミング（HAモニタの状態変化時）

発行タイミング（サーバの状態変化時）

戻り値判定

ユーザコマンド〔用語解説〕

(よ)

予備系

予備系〔用語解説〕

(ラ行)

(り)

リセット

cpudown〔同時リセットの防止〕

patrol〔environment定義文〕

reset_type〔複数系間の同時リセットの防止〕

suppress_reset〔系のリセットの抑止〕

系のリセットに失敗した場合の動作

系のリセットに失敗した場合の動作〔マルチスタンバイ機能使用時〕

実行系のリセット

待機系のリセット

同時リセットの防止

二重リセットの防止

複数系間の同時リセットの防止

抑止

リセット発行系

リセット優先系

リセット優先度

リセットの抑止

patrol_type

リセットパス

IPアドレス

resetpatrol〔ヘルスチェック間隔〕

resetpatrol_mode〔ヘルスチェック〕

構成

設定〔BladeSymphony〕

設定〔HA8000〕

二重化

ヘルスチェック

ポート番号

リセットパスの状態表示〔コマンド〕

リソース

HAモニタに必要なリソース

LAN

共有ディスク

サーバに必要なリソース

最小構成

最大構成

ファイルシステム

リソースの共用

リソースの共用方法の考え方

リソースサーバ

環境設定例

起動

起動を自動化する

実現できない構成

実現できる構成

状態確認

状態の決定方法

停止

リソースサーバの数

リソースサーバ〔用語解説〕

リソースサーバの起動〔コマンド〕

リソースサーバの起動待ち状態

(れ)

連動系切り替え

group〔resource定義文〕

group〔server定義文〕

環境設定例

計画系切り替え

サーバグループ

サーバの切り替え種別

サーバの切り替え種別の指定と連動系切り替えの関係

連動系切り替え〔用語解説〕

連動系切り替え待ち状態〔用語解説〕

(ろ)

ローカルディスク

■ 商標類

AIXは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AIX 5Lは，米国およびその他の国におけるInternational Business Machines Corporationの商標です。
AMDは，Advanced Micro Devices, Inc.の商標です。
Ethernetは，富士ゼロックス株式会社の登録商標です。
HP-UXは，Hewlett-Packard Development Company, L.P.のオペレーティングシステムの名称です。
Itaniumは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及びその他の国における登録商標です。
Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標もしくは商標です。
UNIXは，The Open Groupの米国ならびに他の国における登録商標です。
VERITASおよびVERITASロゴは，Symantec Corporation の米国およびその他の国における商標または登録商標です。
VMwareは，VMware, Inc.の米国および各国での登録商標または商標です。
VMware vSphereは，VMware, Inc.の米国および各国での登録商標または商標です。
Windowsは，米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
その他記載の会社名，製品名は，それぞれの会社の商標もしくは登録商標です。