高信頼化システム監視機能 HAモニタ パブリッククラウド編

3000-9-204-90

前書き

著作権

All Rights Reserved. Copyright (C) 2019, 2025, Hitachi, Ltd.

輸出時の注意

本製品を輸出される場合には、外国為替及び外国貿易法の規制並びに米国輸出管理規則など外国の輸出関連法規をご確認の上、必要な手続きをお取りください。

なお、不明な場合は、弊社担当営業にお問い合わせください。

商標類

記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

発行

2025年11月　3000-9-204-90

変更内容

変更内容（3000-9-204-90）HAモニタ 01-80

追加・変更内容

変更個所

AWS環境下で，HVRDとの連携をサポートした。HVRDとの連携で使用するHAモニタエージェントのエージェントヘルスチェック機能について，説明を追加した。

1.3.1(3)，1.3.4，3.1，3.2，3.2.1，3.2.2，3.2.3，3.2.4，4.1.4，4.2.1(2)，4.2.1(2)(b)，4.3，5.1.1，5.6，5.12，5.14.1，5.16，6.1，6.3.2，6.3.3，7.2.1，7.2.1(1)(b)，7.2.1(1)(c)，7.2.1(2)(c)，7.2.2，7.2.3，7.3.2，7.4.1，7.4.1(4)，8.1，8.1.1，8.1.2，8.1.3，付録A

AWS CLIが実行可能かどうかのチェックに加え，コントロールプレーンに対して実行可能かどうかのチェックもできるようになった。

2.2.2(2)，5.17

次の構成をサポートした。

クライアントからの通信がAWS Network Firewallを経由する構成

4.2.2(4)，5.14.2，5.14.4，7.4.1，7.4.1(5)

マニュアル訂正の内容を反映した。

-

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

はじめに

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

このマニュアルとあわせて，マニュアル高信頼化システム監視機能 HA モニタ Linux(R)（x86）編も参照してください。

対象製品

●P-872C-E111 HAモニタ 01-80

適用OS：Red Hat Enterprise Linux Server 7(x86_64)，Red Hat Enterprise Linux Server 8(x86_64)，Red Hat Enterprise Linux Server 9(64-bit x86_64)，Oracle Linux 7(x86_64)※，Oracle Linux 8(x86_64)※，Oracle Linux 9(x86_64)※

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

適用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)

これらのプログラムプロダクトのほかにもこのマニュアルをご利用になれる場合があります。詳細は「リリースノート」でご確認ください。

注※

OCI環境の場合だけサポートします。

対象読者

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

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

該当するOSの知識

AWS（Amazon Web Services），Azure（Microsoft Azure），またはOCI（Oracle Cloud Infrastructure）の知識

DRBDの知識

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

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

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

このマニュアルで使用する図中の記号

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

1　パブリッククラウド環境下のHAモニタの概要

この章では，パブリッククラウド環境下のHAモニタの概要，系切り替えの方式，動作環境について説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタの概要」とあわせてお読みください。

1.1　このマニュアルの読み方

このマニュアルには，パブリッククラウド環境下のHAモニタとパブリッククラウド環境下でないHAモニタとで差異がある事項を記載しています。また，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編には共通する事項を記載しています。そのため，HAモニタを使用して系切り替え構成を設計・構築するには，このマニュアルとマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の両方を参照してください。

このマニュアルとマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の構成の対応表は次のとおりです。

表1‒1　このマニュアルとマニュアル『高信頼化システム監視機能 HAモニタ Linux(R)（x86）編』の構成の対応

このマニュアル

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編

章

タイトル

章

タイトル

1

パブリッククラウド環境下のHAモニタの概要

1

HAモニタの概要

2

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

2

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

3

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

3

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

4

システムの管理

4

システムの管理

-

-

5

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

5

システムの構築

6

システムの構築

6

システムの運用

7

システムの運用

7

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

8

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

8

コマンド

9

コマンド

-

-

10

API

（凡例）

-：該当マニュアルに存在しない章です。

このマニュアルでは，使用するパブリッククラウドごとに読むトピックが異なります。次のとおりに，目次に記載されているトピックから，読むトピックを選択してください。

タイトルの先頭に「【AWS】」がある場合

AWSのトピックです。AWSを使用する方はお読みください。

タイトルの先頭に「【Azure】」がある場合

Azureのトピックです。Azureを使用する方はお読みください。

タイトルの先頭に「【OCI】」がある場合

OCIのトピックです。OCIを使用する方はお読みください。

タイトルの先頭に「【AWS】」「【Azure】」「【OCI】」のどれもない場合

AWS，Azure，OCI共通のトピックです。使用するパブリッククラウドに関係なくお読みください。

1.2　パブリッククラウド環境下のHAモニタ

HAモニタは，システムの信頼性向上，稼働率向上を目的として，プログラムを含めたシステムの切り替えを実現します。このマニュアルでは，パブリッククラウド環境下でHAモニタを使用する場合の機能および設定方法について説明します。HAモニタの概要については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタの概要」の説明を参照してください。この節では，HAモニタの概要について，パブリッククラウド環境下で差異がある事項だけを記載します。

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

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタが検出する障害」を参照してください。ただし，パブリッククラウド環境下では次の点が異なります。

HAモニタが監視する範囲に，リセットパスはありません。

「系のハードウェア障害，または電源断」は「インスタンス障害」と読み替えてください。

1.2.2　系切り替えの方式

系切り替えの方式については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系切り替えの方式」の説明を参照してください。なお，パブリッククラウド環境下では，「系のリセットによる系切り替え」の方式で系切り替えを実施します。

1.3　HAモニタの動作環境

HAモニタを動作させるために必要なパブリッククラウド環境，およびソフトウェアについて説明します。

1.3.1　【AWS】必要な環境

HAモニタを動作させるために必要なAWS環境について説明します。

構成例では，各系にENIを複数個配置していますが，各系にENIを1個ずつ配置して，監視パス，業務LAN，レプリケーションパスを集約する構成にもできます。

遮断対象となるENIを少なくすることによって系切り替え時間を短縮できます。そのため，特に，ネットワーク遮断による系切り替えを使用する場合は，複数の業務LANの集約や，業務LAN，レプリケーションパス，およびEFSへのアクセス用パスの兼用を検討してください。ネットワーク遮断による系切り替えについては，「(2)　ネットワーク遮断による系切り替え」を参照してください。

なお，レプリケーション構成の場合，監視パスとディスクレプリケーションパスは，分けることを推奨します。理由は，次のとおりです。

HAモニタとレプリケーションソフトが相互に影響を及ぼさないようにするため。

運用を失敗した場合に，監視パスおよびディスクレプリケーションパスが同時に切断されないようにするため。

インスタンス，ENI，EBS，およびEFSの詳細については，AWSのドキュメントを参照してください。

(1)　1:1系切り替え構成

構成例を次に示します。

図1‒1　AWS環境構成例（レプリケーション構成）

図1‒2　AWS環境構成例（EBSマルチアタッチによる共有ディスク構成）

図1‒3　AWS環境構成例（EFSによる共有ディスク構成）

注

EFSによる共有ディスク構成の場合，1つのVPC内でのクラスタ構成にしてください。

(2)　複数スタンバイ構成

構成例を次に示します。

図1‒4　AWS環境構成例（レプリケーション構成）

図1‒5　AWS環境構成例（EBSマルチアタッチによる共有ディスク構成）

図1‒6　AWS環境構成例（EFSによる共有ディスク構成）

注

EFSによる共有ディスク構成の場合，1つのVPC内でのクラスタ構成にしてください。

(3)　HVRD連携構成

HVRDと連携する場合は，HAモニタエージェントを使用してエージェントヘルスチェックをします。詳細は，「3.2　【AWS】HAモニタエージェントを使用したエージェントヘルスチェック機能」を参照してください。

構成例を次に示します。

図1‒7　HVRD連携構成例

HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合，次の内容を前提としてください。

各インスタンスでは，次の2つのパスおよびそのパスのLANアダプタを共用する。

HAモニタのエージェントヘルスチェック用パス

HVRDのレプリケーションパス

次の2つのパスは，異なるLANアダプタにすることを推奨する。

監視パス

HAモニタのエージェントヘルスチェック用パス

次の2つのポート番号は，異なるポート番号を使用する。

系切り替え構成内の各HAモニタが監視パスに使用するポート番号（HAモニタの環境設定のlanportオペランドで指定）

HAモニタエージェントとの通信に使用するポート番号（HAモニタの環境設定のlanport_agentオペランドで指定）

HAモニタエージェント1台に対して，HAモニタの台数は32台までとする。

HAモニタエージェント1台に対して，系切り替え構成の数は16までとする。

1.3.2　【Azure】必要な環境

HAモニタを動作させるために必要なAzure環境について説明します。

なお，このマニュアルでは，Azureリソースのネットワークインターフェイスを「仮想NIC」と記載します。

構成例では，すべてのAzureリソースを同じリソースグループ内に配置し，すべての仮想マシンを同じサブネット内に配置していますが，次の構成にもできます。

Azureリソースを異なるリソースグループに分けて配置する構成

仮想マシンを異なるサブネットに分けて配置する構成

可用性ゾーン，可用性セット，Disk Storage，およびマネージドディスクの詳細については，Azureのドキュメントを参照してください。

(1)　1:1系切り替え構成

構成例を次に示します。

図1‒8　Azure環境構成例（レプリケーション構成で，異なる可用性ゾーンに仮想マシンを配置する場合）

図1‒9　Azure環境構成例（レプリケーション構成で，同じ可用性セット内に仮想マシンを配置する場合）

図1‒10　Azure環境構成例（共有ディスク構成で，同じ可用性ゾーン内に仮想マシンを配置する場合）

図1‒11　Azure環境構成例（共有ディスク構成で，同じ可用性セット内に仮想マシンを配置する場合）

(2)　複数スタンバイ構成

構成例を次に示します。

図1‒12　Azure環境構成例（レプリケーション構成で，異なる可用性ゾーンに仮想マシンを配置する場合）

図1‒13　Azure環境構成例（共有ディスク構成で，同じ可用性ゾーン内に仮想マシンを配置する場合）

1.3.3　【OCI】必要な環境

HAモニタを動作させるために必要なOCI環境について説明します。構成例を次に示します。

図1‒14　OCI環境構成例（1:1系切り替え構成）

図1‒15　OCI環境構成例（複数スタンバイ構成）

1つの可用性ドメインにつき，フォルト・ドメインは3つあります。可用性の確保のため，系が3つ以下の場合は，すべての系を異なるフォルト・ドメインに配置してください。系が4つ以上の場合は，3つのフォルト・ドメインに最低1つずつ系を配置したあと，4つ目以降の系をフォルト・ドメインのどれかに配置してください。この場合，同じフォルト・ドメイン内に複数の系を配置することになります。

構成例では，すべてのインスタンスおよびVNICを同じサブネットに格納していますが，インスタンスおよび監視パスに用いるVNICは，系ごとに異なるサブネットに分けて配置する構成にもできます。

なお，業務通信に用いるVNICは，すべての系で同じサブネットに格納してください。

可用性ドメイン，フォルト・ドメイン，インスタンス，VNIC，およびブロック・ボリュームの詳細については，OCIのドキュメントを参照してください。

1.3.4　必要なソフトウェア

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

図1‒16　必要なソフトウェア

ディスクをレプリケーションして実行系から待機系にデータを引き継ぐ場合に，レプリケーションソフトが必要です。レプリケーションソフトは，DRBDまたはHVRDを使用してください。

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

この章では，障害が発生したあとにHAモニタが行う系切り替えについて説明します。系切り替えという概念を理解している方に向けて，HAモニタではどのように系を切り替えるのか，を中心に説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタを使用した系切り替え」とあわせてお読みください。

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

障害検出から系切り替えまでの流れについては，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「障害検出から系切り替えまでの流れ」の説明を参照してください。この節では，障害検出から系切り替えまでの流れについて，パブリッククラウド環境下で差異がある事項だけを記載します。

2.1.1　【AWS】系障害時の系切り替え

HAモニタが系障害を検出した場合，次の2つの方法で系切り替えをします。

系のリセットによる系切り替え

ネットワーク遮断による系切り替え

AWS環境の場合，Linux Tough Dumpと連携することで，障害となった系のシステムダンプを取得できます。また，上記のどちらの方法で系切り替えをする場合でも，Linux Tough Dumpと連携できます。

なお，Linux Tough Dumpと連携する場合は，Linux Tough Dumpのインストールと，lanport_ltdオペランドの設定が必要です。詳細は，「7.2.1　パブリッククラウド環境固有のHAモニタの環境設定」の「(1)　environment定義文」の「(a)　lanport_ltd」を参照してください。また，Linux Tough Dumpについては，弊社担当営業にお問い合わせください。

ここでは，HAモニタのそれぞれの系切り替えについて説明します。

(1)　系のリセットによる系切り替え

AWS環境では，障害系のインスタンスを強制停止することによって系をリセットし，系切り替えをします。強制停止に失敗した場合は，系切り替え待ち状態となり，オペレータの対処が必要です。

メモ

Linux Tough Dumpと連携している場合は，障害系のLinux Tough Dumpがシステムダンプの取得を開始したあと，待機系のHAモニタが系切り替えをします。このとき，HAモニタは，障害系のインスタンスを強制停止しません。システムダンプが取得されたら，Linux Tough DumpによってOSが自動で再起動されます。

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

図2‒1　系障害時の系のリセットによる系切り替えの概要（AWS）

注※

エンドポイントには，VPCエンドポイントを使用しても問題ありません。ただし，DNS名制御によって業務通信を切り替える場合は，インターネットゲートウェイを介してエンドポイントにアクセスする必要があります。

系障害時の，HAモニタの系切り替えの概要について説明します。番号は，上記の図と対応しています。

待機系が実行系の系障害を検知する。

待機系が実行系の強制停止を要求する。

AWSによって実行系が強制停止される。

系切り替えによって待機系で実行サーバが起動して実行系になる。

AWSによって障害が発生した系が再起動される。

系の起動時にHAモニタおよびサーバを自動起動させる設定にしている場合，再起動した系で待機サーバが起動して待機系になる。

(2)　ネットワーク遮断による系切り替え

ネットワーク遮断による系切り替えは，障害系の入出力を閉塞させるため，障害系インスタンスのENI※をデタッチして，障害系をネットワークから切り離すことで通信を遮断させる機能です。これによって，障害系の入出力を確実に遮断して系切り替えをします。

注※

ENIはDRBDレプリケーション，EFSへのアクセス，および業務通信に使用し，プライマリENIを使用していないことを前提としています。

ネットワーク遮断による系切り替えは，系のリセットによる系切り替えよりも所要時間が短いというメリットがあります。

メモ

Linux Tough Dumpと連携している場合は，障害系のLinux Tough Dumpがシステムダンプの取得を開始したあと，待機系のHAモニタが系切り替えをします。このとき，HAモニタは，障害系のネットワーク遮断およびインスタンスの強制停止をしません。システムダンプが取得されたら，Linux Tough DumpによってOSが自動で再起動されます。

系障害時のHAモニタのネットワーク遮断による系切り替えの概要を，次の図に示します。

図2‒2　ネットワーク遮断による系切り替えの概要(AWS)

ネットワーク遮断による系切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

待機系が実行系の障害を検知する。

待機系が実行系のENIのデタッチを要求する。

実行系のENIがデタッチされ，実行系の実行サーバ用のネットワークが遮断される。

待機系が，ネットワークの遮断を確認後，実行サーバを系切り替えをする。

デタッチ対象のENIは次のとおりです。

実行サーバが業務通信に使用するネットワークのENI

レプリケーションに使用するネットワークのENI

EFSへのアクセスに使用するネットワークのENI

ネットワークの遮断に掛かる時間はデタッチ対象のENIの数に比例するため，業務用LAN，レプリケーションパス，およびEFSへのアクセス用パスでENIを兼用するなど，ENIの数を必要最小限にすることを推奨します。

監視パスだけで使用するネットワークのENIについてはデタッチの対象外です。

なお，実行系のネットワークが遮断されると，系切り替えと並行して，実行系インスタンスは強制停止されます。実行系インスタンスの強制停止を確認後，実行系インスタンスにENIを再度アタッチし，実行系インスタンスの再起動によって，復旧に備えます。実行系インスタンスの強制停止から待機サーバ再起動までの流れについて，次の図に示します。

図2‒3　実行系の強制停止

図2‒4　実行系インスタンスの再起動

図2‒5　待機系サーバの再起動

実行系インスタンスの強制停止から待機サーバ再起動までの動作は，次のとおりです。番号は，図中の番号と対応しています。

系切り替えと並行して，待機系のHAモニタはAWSのエンドポイントに対し，実行系の強制停止を要求する。

実行系が強制停止される。

待機系のHAモニタは実行系が停止したことを確認後，AWSのエンドポイントに対し，実行系のENIのアタッチを指示する。

実行系のインスタンスにENIがアタッチされる。

待機系のHAモニタはENIがアタッチされたことを確認後，AWSのエンドポイントに対し，実行系のインスタンスの再起動を指示する。

実行系のインスタンスが再起動する。

系の起動時にHAモニタおよびサーバを自動起動させる設定にしている場合，再起動した系で待機サーバが起動して待機系になる。

ネットワークの遮断に失敗した場合でも，インスタンスの強制停止に成功すれば，系切り替えができます。ネットワークの遮断とインスタンスの強制停止の両方に失敗した場合は，系切り替え待ちとなります。

ネットワーク遮断による系切り替えは，次の場合に動作します。

系障害による系切り替え時。

サーバ障害や計画系切り替え時に，切り替え元の系でリソースの切り離しに失敗したとき。

ペアダウン機能によって系切り替えをするとき。

monswap -fコマンドで強制的に系切り替えをするとき。

ネットワーク遮断による系切り替えの動作時，次の事象が発生した場合は，ユーザによる対処が必要になります。

障害系のネットワークの遮断，およびインスタンスの強制停止の両方に失敗したとき。

待機系で系切り替え待ちの状態になります。HAモニタのmonactコマンドの入力によって系切り替えを再開させるなど，系切り替え待ちになった場合の運用をしてください。

インスタンスが自動的に再起動しないとき。

AWSコンソールからインスタンスを再起動してください。

ENIの再アタッチができなかったとき。

該当する系のHAモニタを再起動したときに，KAMN766-Eメッセージが出力されます。必要なENIを該当する系のインスタンスにアタッチしてから，インスタンスを再起動してください。

HAモニタはアタッチするためのツールとして/opt/hitachi/HAmon/lib/aws_eni_attach_tool.shを提供しています。

このツールは，ツールを実行した系のネットワーク遮断設定ファイルに定義されたENIをインスタンスにアタッチします。

実行例を次に示します。

# /opt/hitachi/HAmon/lib/aws_eni_attach_tool.sh
Attach the following ENI to this instance(ID:i-007f3a3f424a2782e).
ENI ID:eni-00b5544856f6e1bed
ENI ID:eni-0456be17c65141837
Continue(hit enter key) or Cancel([CTRL]+[C]) ?※
Attaching ENI:eni-00b5544856f6e1bed ................. Attached.
Already attached :eni-0456be17c65141837
#

注※

ENI IDに表示されたENIをアタッチしたい場合はエンターキーを押してください。アタッチしない場合はコントロールキーを押しながら［C］キー（［CTRL］＋［C］）を押してください。

なお，このツールでは，AWS CLIを使用するため，AWSのエンドポイントと通信可能な状態で実行してください。

2.1.2　【Azure】系障害時の系切り替え

HAモニタが系障害を検出した場合，系のリセットによって系切り替えをします。Azure環境では，障害系の仮想マシンを強制停止することによって系をリセットし，系切り替えをします。強制停止に失敗した場合は，系切り替え待ち状態となり，オペレータの対処が必要です。

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

図2‒6　系障害時の系切り替えの概要（Azure）

系障害時の，HAモニタの系切り替えの概要について説明します。番号は，上記の図と対応しています。

待機系が実行系の系障害を検知する。

待機系が実行系の強制停止を要求する。

Azureによって実行系が強制停止される。

系切り替えによって待機系で実行サーバが起動して実行系になる。

Azureによって障害が発生した系が再起動される。

系の起動時にHAモニタおよびサーバを自動起動させる設定にしている場合，再起動した系で待機サーバが起動して待機系になる。

2.1.3　【OCI】系障害時の系切り替え

HAモニタが系障害を検出した場合，系のリセットによって系切り替えをします。OCI環境では，障害系のインスタンスを強制停止することによって系をリセットし，系切り替えをします。強制停止に失敗した場合は，系切り替え待ち状態となり，オペレータの対処が必要です。

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

図2‒7　系障害時の系切り替えの概要（OCI）

系障害時の，HAモニタの系切り替えの概要について説明します。番号は，上記の図と対応しています。

待機系が実行系の系障害を検知する。

待機系が実行系の強制停止を要求する。

OCIによって実行系が強制停止される。

系切り替えによって待機系で実行サーバが起動して実行系になる。

OCIによって障害が発生した系が再起動される。

系の起動時にHAモニタおよびサーバを自動起動させる設定にしている場合，再起動した系で待機サーバが起動して待機系になる。

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

HAモニタによる障害検出については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタによる障害検出」の説明を参照してください。この節では，HAモニタによる障害検出について，パブリッククラウド環境下で差異がある事項だけを記載します。

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

サーバ障害発生時に系切り替えをする条件については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタが系切り替えをする条件」の説明を参照してください。

なお，系障害発生時に系切り替えをする条件については，パブリッククラウド環境でない場合とは差異があります。パブリッククラウド環境下の系障害発生時に系切り替えをする条件を次に示します。

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

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

AWS CLI，Azure CLI，またはOCI CLIが実行できる状態であること

2.2.2　系障害の検出

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系障害の検出」の説明を参照してください。

ただし，パブリッククラウド環境下では，リセットパスのヘルスチェックをしません。代わりに，AWS CLIまたはAzure CLIの実行可否チェックをします。

(1)　AWS CLI，Azure CLI，またはOCI CLIの実行可否チェック

AWS CLI，Azure CLI，およびOCI CLIの実行可否チェックについて，説明します。

パブリッククラウド環境下では，インスタンスの強制停止や業務通信の切り替えなどをAWS CLI，Azure CLI，またはOCI CLIで実施します。CLIが実行できる状態でなければ，系切り替えはできません。そのため，HAモニタはCLIを実行できる状態かどうかを定期的にチェックします。

CLI実行可否チェックは，HAモニタを起動してから停止するまで，60秒間隔で実施します。

CLIを実行できない場合は，メッセージKAMN768-Eを出力します。メッセージに従って，対処してください。

次のどちらかの場合で，CLIを実行できない状態が継続している間は，1時間おきに繰り返しメッセージKAMN769-Wを出力します。

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

HAモニタの環境設定のnotswitch_notifyオペランドを省略した場合

CLIを実行できない状態から，実行できる状態に回復した場合は，CLI実行可否チェック時にメッセージKAMN770-Iを出力します。

CLI実行可否チェックは，シェルスクリプトからCLIを実行することによって実施します。このシェルスクリプトは，パブリッククラウド環境でHAモニタを使用するために必要なスクリプトを集めたシェルスクリプト群に含まれています。環境構築時にこのシェルスクリプト群を展開しておく必要があります。このシェルスクリプト群については，「5.8　【AWS】AWS用のシェルスクリプト群の展開」，「5.9　【Azure】Azure用のシェルスクリプト群の展開」，または「5.10　【OCI】OCI用のシェルスクリプト群の展開」を参照してください。

(2)　【AWS】コントロールプレーンのチェック

AWS環境では，AWS CLIが実行可能かどうかのチェックに加え，コントロールプレーンに対して実行可能かどうかのチェックもできます。HAモニタは系切り替え時に，コントロールプレーンと関連するAWS CLIを実行する場合があります。コントロールプレーンに対するチェックをすることで，早期に障害を検知し，ユーザ対処ができるようになります。

コントロールプレーンのチェックには次の2つの方法があります。

ENIの制御によるチェック

ルートテーブルの更新によるチェック

どちらか片方だけでもチェックできますが，両方でチェックすることを推奨します。

ENIの制御によるチェック

チェックするインスタンス上のHAモニタは，定期的に次の動作をします。

チェック専用のENIについて，デタッチをしたあと，再度アタッチする

チェックするには，次の準備が必要です。

チェック専用のENI

チェックするインスタンスごとにチェック専用のENIをアタッチしてください。

ルートテーブルの更新によるチェック

チェックするインスタンス上のHAモニタは，定期的に次の動作をします。

チェック専用のルートテーブルについて，エントリを削除したあと，再度登録する

チェックするには，次の準備が必要です。

チェック専用のルートテーブル

チェックするインスタンスごとにチェック専用のルートテーブルを作成してください。

エントリ登録のためのチェック専用のVIP

業務などの通信に影響を与えないように，業務通信には使用しない未使用のVIPを作成してください。

VIPは次の条件を満たしてください。

•VIPはVPCのCIDRの範囲外

•VIPのCIDRブロックは32

エントリ登録のためのターゲットとなるENIのID

チェックするインスタンスにアタッチされたENIのIDです。ENIの制御によるチェック専用のENIのIDでも問題ありません。

チェックが失敗した場合，syslogにメッセージKAMN558-Eを出力します。また，メッセージKAMN558-Eを出力後，実行した結果が正常だと確認できた場合は，syslogにメッセージKAMN559-Iを出力します。

2.3　【AWS】リソースの引き継ぎ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有リソースの引き継ぎ」を参照してください。ただし，AWS環境下では次の点が異なります。

どちらかの方式で業務ディスクを引き継ぐ。

実行系および待機系に業務ディスクを配置し，業務ディスク内のデータをレプリケーションソフトで常時同期する（レプリケーション構成）。※

EBSマルチアタッチ機能，またはEFSを使用して，実行系および待機系で業務ディスクを共有する（共有ディスク構成）。

LANの引き継ぎに加え，次の制御で通信を切り替える。

・VIP制御

・EIP制御

・DNS名制御

注※

実行系および待機系に業務ディスクを配置する構成であっても，LVMによるボリュームグループ単位の接続・切り離し，ファイルシステムのマウント・アンマウントは実施します。

詳細については，「4.2　リソースの管理」を参照してください。

2.4　【Azure】リソースの引き継ぎ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有リソースの引き継ぎ」を参照してください。ただし，Azure環境下では次の点が異なります。

どちらかの方式で業務ディスクを引き継ぐ。

実行系および待機系に業務ディスクを配置し，業務ディスク内のデータをレプリケーションソフトで常時同期する（レプリケーション構成）。※

マネージドディスクの共有をして，実行系および待機系で業務ディスクを共有する（共有ディスク構成）。

LANの引き継ぎに加え，次の制御で通信を切り替える。

・Azure ロードバランサーによる制御

・DNS名制御

注※

実行系および待機系に業務ディスクを配置する構成であっても，LVMによるボリュームグループ単位の接続・切り離し，ファイルシステムのマウント・アンマウントは実施します。

詳細については，「4.2　リソースの管理」を参照してください。

2.5　【OCI】リソースの引き継ぎ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有リソースの引き継ぎ」を参照してください。ただし，OCI環境下では次の点が異なります。

LANの引き継ぎに加え，次の制御で通信を切り替える。

・プライベートIPアドレスによる制御

詳細については，「4.2　リソースの管理」を参照してください。

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

この章では，パブリッククラウド環境下で使用できるHAモニタの機能について説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタで使用できる機能」とあわせてお読みください。

3.1　HAモニタで使用できる機能一覧

パブリッククラウド環境下で使用できるHAモニタの機能を，次の表に示します。

表3‒1　パブリッククラウド環境下のHAモニタで使用できる機能

機能

パブリッククラウド

分類

機能名

サーバの制御

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

○

モニタモードの待機系での監視

○

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

○

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

○

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

○※1

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

○

系切り替え時の起動リトライ

○

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

○

系の制御

系の同時リセットの防止

○

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

○

系の二重リセットの防止

−

系のリセットの抑止

○

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

○

他系のOSパニック検知

−※2

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

−

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

−

共有リソースの制御

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

○

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

○

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

○

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

○

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

○

共有リソースの動的変更

○※3

リソースの監視

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

○

ディスクの監視

○

プログラムの制御

UAPの監視

○

HAモニタ Extension

サーバの最大数の変更

○

系の最大数の変更

−

（凡例）

○：使用できます。

−：使用できません。

注※1

レプリケーションソフトがHVRDの場合，HVRDが複数のディスクにレプリケーションできないため，マルチスタンバイ機能は使用できません。

注※2

OSパニックになった場合，すぐに検知できませんが，系障害検知時間が経過すると検知します。

注※3

DRBDリソースの動的変更はできません。

3.2　【AWS】HAモニタエージェントを使用したエージェントヘルスチェック機能

HVRDとの連携で必要になるHAモニタエージェント（エージェントモードで動作しているHAモニタ）には，エージェントヘルスチェック機能があります。

この機能は，各AZの通信状況を俯瞰して監視するHAモニタエージェントと，各AZで稼働するHAモニタとの間で，定期的にヘルスチェック通信をします。HAモニタエージェントは，HVRDでレプリケーションしているAZとは異なる場所に配置し，各AZの通信状態を監視します。実行系HVRDで，AZ間でのレプリケーション通信ができなくなったとき，実行系HAモニタは，実行系と待機系のどちらのAZが不調であるかを判定します。判定には，「HAモニタからのヘルスチェックメッセージの受信数」を使用します。判定結果によって，実行系のAZのI/Oを停止するか，I/Oを継続します。

エージェントヘルスチェック機能の動作を次の図に示します。

図3‒1　エージェントヘルスチェック機能の動作

動作の詳細について，以降の項で説明します。

3.2.1　定常状態でのエージェントヘルスチェック

各AZの通信状況を俯瞰して監視するHAモニタエージェントと，各AZで稼働するHAモニタとの間で，定期的にヘルスチェック通信することで，各AZの通信状態を監視します。

以降，このヘルスチェックを「エージェントヘルスチェック」と定義します。

エージェントヘルスチェック（UDP通信）は，HAモニタエージェントとHAモニタでそれぞれ次の動作をします。

各HAモニタからHAモニタエージェントに対して，100ms間隔でヘルスチェックメッセージを送信します。

HAモニタエージェントから各HAモニタに対して，100ms間隔でヘルスチェックメッセージを送信します。ヘルスチェックメッセージの内容は，HAモニタエージェントが各HAモニタから受信したヘルスチェックメッセージの，直近1分間の受信数です。

各HAモニタから他系HAモニタに対して，100ms間隔でヘルスチェックメッセージを送信します。ヘルスチェックメッセージの内容は，HAモニタエージェントから受信したヘルスチェックメッセージ（HAモニタエージェントが各HAモニタから受信したヘルスチェックメッセージの，直近1分間の受信数）をそのまま送信します。これによって，自系とHAモニタエージェントが通信できない場合でも，他系HAモニタ経由で，HAモニタエージェントのヘルスチェックメッセージを受信できます。

3.2.2　HVRDのレプリケーション断発生時の判定

実行系でHVRDがレプリケーション通信断を検知した際，実行系のHAモニタは，レプリケーション通信ができなくなった原因が，実行系のAZと待機系のAZのどちらにあるかを判定します。この判定のために，次の1.と2.を順番に確認します。※1

注※1

HAモニタエージェントが未起動の場合（障害などによってHAモニタがHAモニタエージェントの異常終了を検知済みの場合を含む）は，1.と2.を確認しません。通信状態に関係なく，待機系のAZが不調と判定します。

実行系が孤立しているかの確認

実行系のHAモニタは，レプリケーション通信断とエージェントヘルスチェック送受信断が同時に発生していないかを確認します。レプリケーション通信が途絶えている期間（HVRDのI/Oタイムアウト時間）に，HAモニタエージェントまたは他系HAモニタからのエージェントヘルスチェックも受信できなかった場合は，実行系のネットワーク通信全体が不通で孤立状態となっています。この場合，実行系のAZが不調と判定します。

HAモニタエージェントから見た通信状況の確認

実行系のHAモニタは，次の2つのメッセージを確認します。

「HAモニタエージェントから受信済みのヘルスチェックメッセージ」の最新メッセージ

「待機系のHAモニタから受信済みのヘルスチェックメッセージ」の最新メッセージ

これらのメッセージから，「HAモニタエージェントから見た各HAモニタからのヘルスチェックメッセージの受信数」を比較します。※2

具体的には，次の2つを比較します。

実行系のAZにあるHAモニタのヘルスチェックメッセージの受信数

待機系のAZにある起動済みHAモニタのうち，一番多く受信しているヘルスチェックメッセージの受信数（待機系のAZにHAモニタが1台もない場合，受信数は0です）

この結果，受信数が少ない方のAZを不調と判定します。

注※2

直近1分間を比較します。ただし，HAモニタエージェントやHAモニタを起動してから間もないケースなどで，比較対象である系切り替え構成内の各HAモニタからの受信済みメッセージが1分に満たない場合は，秒数が一番短いHAモニタに合わせて受信数を比較します。次の表の例では，HAモニタ2に合わせて，全系25秒間の受信数を比較します。

表3‒2　受信済みメッセージが1分に満たない場合の例

AZ

HAモニタ

受信済みデータの秒数

AZ1

HAモニタ1

30秒

HAモニタ2

25秒

AZ2

HAモニタ3

240秒

HAモニタ4

250秒

3.2.3　AZが通信不調であると判定したあとの動作

AZが通信不調であると判定したあとの動作は，判定結果によって異なります。

実行系のAZが不調であると判定した場合

HVRDが実行系のAZのI/Oを停止します。これによって実行サーバが障害になれば，系切り替えをします。

待機系のAZが不調であると判定した場合

HVRDが待機系のAZを切り離してレプリケーションを中断します。実行系のAZのI/Oは継続します。これによって業務を継続します。詳細は「(2)　レプリケーションパス障害時の制御」の「(b)　レプリケーションソフトにHVRDを使用する場合」を参照してください。

3.2.4　事象ごとの動作

主な事象ごとの動作を説明します。なお，ここでは，系切り替え可能な状態での事象とします。

系障害

実行系障害

系切り替え後は，切り替え先のディスクが更新され，切り替え元のディスクのデータが古いままとなり，同期されていない状態になります。

待機系障害

強制停止された系がHVRDのレプリケーション先である場合，実行系のディスクだけが更新されます。

サーバ障害

実行サーバ障害

系および通信に問題がなければ，系切り替え後は，HVRDによるレプリケーションの方向が変わります。

待機サーバ障害

系および通信に問題がなければ，HVRDによるレプリケーションが継続されます。

HVRDのレプリケーションの通信断

HVRDのレプリケーション通信だけができなくなった場合，実行系（レプリケーション元）だけで業務（ディスクI/O）を継続します。

エージェントヘルスチェックの通信断

HAモニタエージェントとの間のヘルスチェック通信だけができなくなった場合，HAモニタがHAモニタエージェントの障害を検知して，エージェントヘルスチェックが停止します。

エージェントヘルスチェックが停止しても，各サーバ（業務）には影響なく，HAモニタは，サーバおよび系の監視を継続します。

ただし，エージェントヘルスチェックが停止している間に，HVRDのレプリケーションの通信断が発生した場合，HAモニタはどちらのAZ通信が不調かの判定ができません。この場合は，ネットワーク状態に関係なく，待機系のAZを通信不調と判定します。

なお，エージェントヘルスチェックの通信が回復したあと，HAモニタエージェントとHAモニタは自動的に再接続し，エージェントヘルスチェックも自動的に再開します。

HAモニタエージェント障害

HAモニタエージェントが稼働する系，またはHAモニタエージェントのプロセス障害が発生した場合，HAモニタがHAモニタエージェントの障害を検知して，エージェントヘルスチェックが停止します。そのあとの動作は「エージェントヘルスチェックの通信断」と同様です。

系の障害で，系が停止したままの場合は，原因を取り除いてから再起動が必要です。HAモニタエージェントのプロセス障害の場合，通常はsystemdのunitファイルの設定に従って，自動的に再起動します。何らかの理由によって再起動しない場合は，原因を取り除いてから再起動が必要です。

HAモニタエージェントが障害から回復したあと，HAモニタエージェントとHAモニタは自動的に再接続し，エージェントヘルスチェックも自動的に再開します。

4　システムの管理

この章では，HAモニタが系およびリソースをどのように管理しているかについて説明します。HAモニタの動作の詳細を知りたい場合にお読みください。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系の管理」とあわせてお読みください。

4.1　系の管理

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系の管理」を参照してください。この節では，系のリセットに関するHAモニタの動作について，パブリッククラウド環境下で差異がある事項だけを記載します。

なお，オペレータの操作については，「6.　システムの運用」を参照してください。

4.1.1　系のリセットまたはネットワーク遮断をする系の決定方法

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系のリセットをする系の決定方法」を参照してください。ただし，リセット完了またはネットワーク遮断連絡を待つ時間を次のとおりに読み替えてください。

AWS環境かつ系のリセットをする場合，またはAzure環境の場合：120秒

AWS環境かつ系のネットワーク遮断をする場合：30秒

OCI環境の場合：30秒

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

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「両系が障害を同時に検出した場合の系切り替え」を参照してください。ただし，リセット発行またはネットワーク遮断の待ち時間を次のとおりに読み替えてください。

AWS環境かつ系のリセットをする場合，またはAzure環境の場合：120秒

AWS環境かつ系のネットワーク遮断をする場合：30秒

OCI環境の場合：30秒

また，「ユーザがリセット優先系を指定しないときの系切り替え」はパブリッククラウド環境下では使用できません。

4.1.3　複数の待機系がある場合の系のリセットまたはネットワーク遮断

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「複数の待機系がある場合の系のリセット」を参照してください。ただし，リセット発行またはネットワーク遮断の待ち時間を次のとおりに読み替えてください。

AWS環境かつ系のリセットをする場合，またはAzure環境の場合：120秒

AWS環境かつ系のネットワーク遮断をする場合：30秒

OCI環境の場合：30秒

4.1.4　【AWS】HAモニタエージェントを使用する場合の系の孤立見なし

HAモニタが他系からのaliveメッセージの途絶を検知したとき，HAモニタエージェントとのヘルスチェックも途絶している場合は，自系のネットワークに問題があり自系が孤立していると見なします。

孤立した系からは他系のリセットやネットワーク遮断をしません。また，孤立した系で動作している待機サーバは系切り替え待ち状態になります。

これによって，孤立した系に業務を系切り替えしないようにします。

4.2　リソースの管理

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有リソースの管理」を参照してください。この節では，リソースの管理について，パブリッククラウド環境下で差異がある事項だけを記載します。

4.2.1　業務ディスクの管理

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有ディスクの管理」を参照してください。

AWS環境下およびAzure環境下では，業務ディスクをレプリケーションする構成の場合，加えて次の制御も実施します。

(1)　基本的な制御

HAモニタは，OSのコマンドによってボリュームグループ単位で接続・切り離しをします。HAモニタがボリュームグループに接続することで，レプリケーションソフトによって業務ディスクがプライマリに昇格します。HAモニタがボリュームグループを切り離すことで，レプリケーションソフトによって業務ディスクがセカンダリに降格します。

(2)　レプリケーションパス障害時の制御

レプリケーションパス障害時の制御は，使用するレプリケーションソフトによって異なります。

(a)　レプリケーションソフトにDRBDを使用する場合

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

セカンダリ側のHAモニタで次のコマンドを実行して，セカンダリ側の業務ディスクがプライマリに昇格することを抑止します。

drbdsetup outdate /dev/drbdX

drbdsetupコマンドの実行によって，レプリケーションパスの障害時に系切り替えをした場合でも，セカンダリ側の業務ディスクがプライマリに昇格できないため，古いデータを参照して業務を続行することを防止できます。セカンダリ側の業務ディスクがプライマリに昇格するのを抑止したあと，プライマリ側でI/Oを継続します。

レプリケーションパス障害時の制御の流れについて，次の図に示します。

図4‒1　レプリケーションパス障害時の制御の流れ

プライマリ昇格抑止に失敗した場合は，メッセージKAMN771-Eを出力し，待機サーバを停止させます。プライマリ昇格抑止をしたあとに，レプリケーションパスが回復した場合には，レプリケーションソフトによって再同期が実施され，プライマリ昇格抑止が自動的に解除されます。なお，再同期中に系障害による系切り替えが発生した場合，セカンダリ側は業務ディスクステータスが最新になっていないため，プライマリ昇格はできず，古いデータを参照して業務を継続することはありません。

レプリケーションパスと監視パスが同時に障害になった場合，待機系に連絡できずプライマリ昇格抑止設定ができません。そのため，実行系が待機系をリセットして，その後の系切り替えが発生しないようにします。ただし，リセット優先系の設定などによって実行系がリセットされて系切り替えをする場合もあります。DRBD用のシェルスクリプト群を展開している場合は，standbyresetオペランドの指定に関係なく待機系がリセットされます。詳細は，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「両系が障害を同時に検出した場合の系切り替え」を参照してください。

マルチスタンバイ機能を使用する場合

レプリケーションパスが切断したセカンダリの系で，メッセージKAMN771-Eを出力して待機サーバを停止します。レプリケーションパスを回復させたあと，待機サーバを再起動してください。

レプリケーションパスと監視パスが同時に障害になった場合は，リセット優先度に従って動作します。詳細は，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「複数の待機系がある場合の系のリセット」を参照してください。実行系がリセットされた場合は，系切り替えをします。レプリケーションパスが切断したセカンダリの系がリセットされた場合は，リセットされた系以外で業務を継続します。

(b)　レプリケーションソフトにHVRDを使用する場合

HVRDからの指示によって待機系側のHAモニタがHVRDと連携して，レプリケーション用疑似デバイスを同期が取れていない状態（stale）に変更します。また，待機系側の業務ディスクで，レプリケーション用疑似デバイスを同期が取れていない状態（stale）にしたあと，実行系側でI/Oを継続します。これによって，レプリケーションパスの障害時に系切り替えをした場合でも，待機系側のレプリケーション用疑似デバイスを"online-primary"にできないため，古いデータを参照して業務を続行することを防止できます。

レプリケーション用疑似デバイスを同期が取れていない状態（stale）に変更できなかった場合は，HVRDのメッセージに従って対処してください。

レプリケーションパスと監視パスが同時に障害になった場合，待機系に連絡できず，レプリケーション用疑似デバイスを同期が取れていない状態（stale）にできません。そのため，同期が取れていないまま待機系が稼働し続けることを防止するため，待機系の系障害を実行系が検出した場合に待機系をリセットする設定で使用してください。なお，監視パスが障害の場合は，リセット優先度に従って動作します。詳細は，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「両系が障害を同時に検出した場合の系切り替え」を参照してください。

4.2.2　【AWS】LANの管理

クライアントから実行サーバへの通信を実現するために，HAモニタは次の制御をします。

OSでのエイリアスIPの追加・削除（DNS名制御の場合を除く）

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「LANの管理」を参照してください。ただし，AWS環境下では次の点が異なります。

OSのarpingコマンドは実行不要※

エイリアスIPを割り当てるとき，ブロードキャストアドレスは指定不可

注※

AWSでの通信経路の制御によって，通信経路が定まるためです。

AWSでの通信経路の制御

1つのリージョン内または1つのVPC内で系切り替えをする構成の場合，AWS環境下では，次の通信制御の方式があります。

VIP制御による業務通信の切り替え

EIP制御による業務通信の切り替え

DNS名制御による業務通信の切り替え

複数のリージョン間，または複数のVPC間で系切り替えをする構成の場合，AWS環境下では，次の通信制御の方式があります。

VIP制御による業務通信の切り替え

DNS名制御による業務通信の切り替え

系切り替え対象のサーバと通信するクライアントの場所によって，業務通信の切り替え方法が決定します。次の表で，業務通信の切り替え方法を確認してください。

表4‒1　AWS環境下の業務通信の切り替え方法

切り替え対象のサーバと通信するクライアントの場所

業務通信の切り替え方法

VPC外

インターネット上

EIP制御による業務通信の切り替え

VPN内※

VIP制御による業務通信の切り替え

Direct Connect※

VPC Peering※

VPC内

VPC外（インターネット上）とVPC内の両方

EIP制御による業務通信の切り替え，またはDNS名制御による業務通信の切り替え

注※

トランジットゲートウェイによる接続が必要です。

次に，それぞれの通信経路の制御方式について説明します。

(1)　VIP制御による業務通信の切り替え（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）

1つのリージョン内または1つのVPC内で系切り替えをする構成での，VIP制御による業務通信の切り替えについて説明します。

AWS上での操作によるルートテーブルの書き換え，およびOSでのエイリアスIPの追加・削除によって，業務通信を切り替えます。

VIP制御による業務通信の切り替えの流れについて説明します。実行系インスタンスから待機系インスタンスにVIPを切り替える場合の動作例について次の図に示します。

図4‒2　VIP制御による業務通信の切り替えの動作例

業務通信を切り替える前の，実行系インスタンスのルートテーブルの例を次に示します。この時点では，VIPは，実行系インスタンスのENIを指しています。

表4‒2　業務通信の切り替え前のルートテーブル例

Destination

Target

備考

VPCのネットワーク

(例：10.0.0.0/16)

local

-

0.0.0.0/0

Internet gateway

-

VIP

(例：10.1.0.10/32)

eni-xxxxxxxx

(実行系インスタンスのENI ID)

-

（凡例）

-：特にありません。

VIP制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

HAモニタは，AWS CLIで，ルートテーブルから対象のVIPのエントリを削除する。

ルートテーブルの内容（エントリを削除後）：

Destination

Target

備考

VPCのネットワーク

(例：10.0.0.0/16)

local

-

0.0.0.0/0

Internet gateway

-

（空白）

（空白）

削除

（凡例）

-：特にありません。

HAモニタは，OSのipコマンドを実行することによって，ネットワークインタフェースから実行系インスタンスに対するVIPを削除する（1.の結果に関係なく削除する）。

HAモニタは，AWS CLIで，対象のVIPのエントリをルートテーブルに再登録する。対象VIPのターゲットは，待機系インスタンスのENIにする。

ルートテーブルの内容（エントリを再登録後）：

Destination

Target

備考

VPCのネットワーク

(例：10.0.0.0/16)

local

-

0.0.0.0/0

Internet gateway

-

VIP

(例：10.1.0.10/32)

eni-yyyyyyyy

(待機系インスタンスのENI ID)

追加

（凡例）

-：特にありません。

3.で1つ以上のルートテーブルに登録できた場合，HAモニタは，OSのipコマンドを実行することで，ネットワークインタフェースに待機系インスタンスに対するVIPを追加する。

例えば，上記の図中で，実行系インスタンスおよび待機系インスタンスにも，対象のVIPと通信するクライアントがある場合，実行系インスタンスおよび待機系インスタンスが持つルートテーブルも，操作対象となります。

これらの処理をするためには，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」を参照してください。

(2)　VIP制御による業務通信の切り替え（複数のリージョン間または複数のVPC間で系切り替えをする場合）

次の構成での，VIP制御による業務通信の切り替えについて説明します。

同一のリージョン内の，複数のVPC間で系切り替えをする構成

複数のリージョン間で系切り替えをする構成

同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成

これらの構成には，トランジットゲートウェイが必要です。トランジットゲートウェイの詳細については，AWSのドキュメントを参照してください。

重要

これらの構成で系切り替えをする場合は，次の前提条件を満たす必要があります。

リージョンが２つ以内の構成であること

系切り替え構成のリージョン内に，クライアントが配置されていること

次に，それぞれの構成について説明します。

同一のリージョン内の，複数のVPC間で系切り替えをする構成

同一のリージョン内の，複数のVPC間で系切り替えをする構成の例を次の図に示します。

図4‒3　同一のリージョン内の，複数のVPC間で系切り替えをする構成の例

同一のリージョン内の各VPC（VPC1およびVPC2）に，HAモニタを構成するインスタンス（インスタンス1およびインスタンス2）をそれぞれ配置します。また，複数のVPC間をトランジットゲートウェイで接続し，VIPの業務通信をルーティングします。

複数のリージョン間で系切り替えをする構成

複数のリージョン間で系切り替えをする構成の例を次の図に示します。

図4‒4　複数のリージョン間で系切り替えをする構成の例

各リージョン（リージョン1およびリージョン2）に，HAモニタを構成するインスタンス（インスタンス1およびインスタンス2）をそれぞれ配置します。

また，トランジットゲートウェイをリージョンごとに配置します。トランジットゲートウェイのリージョン間ピアリングの機能で，複数のリージョン間を接続し，VIPの業務通信をルーティングします。

同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成

同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成の例を次の図に示します。

図4‒5　同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成の例

上記の図は，複数スタンバイ構成です。リージョン1のVPC（VPC1）内に，HAモニタを構成するインスタンス（インスタンス1およびインスタンス2）をそれぞれ配置します。リージョン2のVPC（VPC2）内にも，HAモニタを構成するインスタンス（インスタンス3）を配置します。

また，トランジットゲートウェイをリージョンごとに配置します。トランジットゲートウェイのリージョン間ピアリングの機能で複数のリージョン間を接続し，VIPの業務通信をルーティングします。

(a)　VIPのルーティングの動作

VIPのルーティングの概要について説明します。

各トランジットゲートウェイには，VPCのルートテーブルとは別に，トランジットゲートウェイルートテーブルがあります。トランジットゲートウェイルートテーブルは，トランジットゲートウェイアタッチメント内のパケットをどこにルーティングするかを指定できます。

トランジットゲートウェイアタッチメントは，次のとおりネットワーク間を接続しています。

VPC用のトランジットゲートウェイアタッチメントで，VPCとトランジットゲートウェイとの間を接続

ピアリング用のトランジットゲートウェイアタッチメントで，トランジットゲートウェイ間を接続

なお，トランジットゲートウェイアタッチメントは，トランジットゲートウェイルートテーブルと関連づけることができます。

次に，VIPのルーティングの動作について説明します。

VIPによる業務通信を切り替える場合，HAモニタが次のルートテーブルの経路情報を追加します。

VPCのルートテーブル

トランジットゲートウェイルートテーブル

複数のリージョン間で系切り替えをする構成で，サーバーインスタンス1と，VIPによる業務通信をできるようにする例を次の図に示します。

図4‒6　複数のリージョン間で系切り替えをする構成でのVIPのルーティングの動作例

VIPのルーティングの動作は，次のとおりです。番号は，図中の番号と対応しています。

ルートテーブル（VPC2）に，VIPのエントリを追加する。

ターゲットをトランジットゲートウェイ2（tgw-R2）とするVIPのエントリを追加します。

表4‒3　ルートテーブル（VPC2）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-R2

これによって，VIP宛ての業務通信がトランジットゲートウェイ2（tgw-R2）に転送されます。

トランジットゲートウェイルートテーブル（tgw-R2）に，VIPのエントリを追加する。

ターゲットをピアリング用のトランジットゲートウェイアタッチメント（tgw-attach-P）とするVIPのエントリを追加します。

表4‒4　トランジットゲートウェイルートテーブル（tgw-R2）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-attach-P

これによって，VIP宛ての業務通信がピアリングしているトランジットゲートウェイ1（tgw-R1）に転送されます。

トランジットゲートウェイルートテーブル（tgw-R1）に，VIPのエントリを追加する。

ターゲットをVPC1のトランジットゲートウェイアタッチメント（tgw-attach-VPC1）とするVIPのエントリを追加します。

表4‒5　トランジットゲートウェイルートテーブル（tgw-R1）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-attach-VPC1

これによって，VIP宛ての業務通信がVPC1（tgw-attach-VPC1）に転送されます。

ルートテーブル（VPC1）に，VIPのエントリを追加する。

ターゲットをENI（eni-xxxx）とするVIPのエントリを追加します。

表4‒6　ルートテーブル（VPC1）の内容

Destination

Target

VIP（10.10.10.10/32）

eni-xxxx

これによって，VIP宛ての業務通信がENI1（eni-xxxx）に転送されます。

上記の一連の動作によって，クライアントインスタンス1およびクライアントインスタンス2からVIPアドレス（10.10.10.10/32）を使用して，サーバーインスタンス1にアクセスできるようになります。

(b)　系切り替え時の動作

HAモニタは，次の動作によって業務通信を切り替えます。

AWS上でのルートテーブルおよびトランジットゲートウェイルートテーブルの書き換え

OS上でのVIPの追加・削除

メモ

処理が完了するのに掛かる時間は，次の点によって変わります。

操作するVIPの数

操作するルートテーブルの数

操作するトランジットゲートウェイルートテーブルの数

VIPによる業務通信を実行系から待機系に切り替えるには，次の2段階の動作があります。

実行サーバ側のサーバーインスタンスを指すルーティング情報の削除，およびOS上でのVIPの削除

待機サーバ側のサーバーインスタンスを指すルーティング情報の追加，OS上でのVIPの追加，および系切り替え

これらの2つの段階に分けて，実行サーバ側のサーバーインスタンスから待機サーバ側のサーバーインスタンスに，VIPによる業務通信を切り替える動作を説明します。

実行サーバ側のサーバーインスタンスを指すルーティング情報の削除，およびOS上でのVIPの削除

実行サーバ側のサーバーインスタンスを指すルーティング情報を削除し，OS上でVIPを削除する動作を次の図に示します。

図4‒7　実行サーバ側のサーバーインスタンスを指すルーティング情報を削除し，OS上でVIPを削除する動作

実行サーバ側のサーバーインスタンスを指すルーティング情報を削除し，OS上でVIPを削除する動作は，次のとおりです。番号は，図中の番号と対応しています。

ルートテーブル（VPC1）から，VIPのエントリを削除する。

ターゲットをENI1（eni-xxxx）とするVIPのエントリを削除します。

表4‒7　ルートテーブル（VPC1）の内容

Destination

Target

（空白）

（空白）

トランジットゲートウェイルートテーブル（tgw-R1）から，VIPのエントリを削除する。

ターゲットをVPC1のトランジットゲートウェイアタッチメント（tgw-attach-VPC1）とするVIPのエントリを削除します。

表4‒8　トランジットゲートウェイルートテーブル（tgw-R1）の内容

Destination

Target

（空白）

（空白）

トランジットゲートウェイルートテーブル（tgw-R2）から，VIPのエントリを削除する。

ターゲットをピアリング用のトランジットゲートウェイアタッチメント（tgw-attach-P）とするVIPのエントリを削除します。

表4‒9　トランジットゲートウェイルートテーブル（tgw-R2）の内容

Destination

Target

（空白）

（空白）

ルートテーブル（VPC2）から，VIPのエントリを削除する。

ターゲットをトランジットゲートウェイ2（tgw-R2）とするVIPのエントリを削除します。

表4‒10　ルートテーブル（VPC2）の内容

Destination

Target

（空白）

（空白）

OSのネットワークインタフェースからVIPを削除する。

実行サーバ側のサーバーインスタンスでOSのipコマンドを使用して，VIPを削除します。

メモ

同一のVPC内の複数のAZ間で系切り替えをするときは，系切り替えをするVPC外のルーティング情報を変更しません。

待機サーバ側のサーバーインスタンスを指すルーティング情報の追加，OS上でのVIPの追加，および系切り替え

待機サーバ側のサーバーインスタンスを指すルーティング情報の追加，およびOS上でのVIPの追加をして，系切り替えをする動作を次の図に示します。

図4‒8　待機サーバ側のサーバーインスタンスを指すルーティング情報の追加，およびOS上でのVIPの追加をして，系切り替えをする動作

待機サーバ側のサーバーインスタンスを指すルーティング情報の追加，およびOS上でのVIPの追加をして，系切り替えをする動作は，次のとおりです。番号は，図中の番号と対応しています。

ルートテーブル（VPC2）に，VIPのエントリを追加する。

ターゲットをENI2（eni-yyyy）とするVIPのエントリを追加します。

表4‒11　ルートテーブル（VPC2）の内容

Destination

Target

VIP（10.10.10.10/32）

eni-yyyy

これによって，VIP宛ての業務通信がENI2（eni-yyyy）に転送されます。

トランジットゲートウェイルートテーブル（tgw-R2）に，VIPのエントリを追加する。

ターゲットをVPC2のトランジットゲートウェイアタッチメント（tgw-attach-VPC2）とするVIPのエントリを追加します。

表4‒12　トランジットゲートウェイルートテーブル（tgw-R2）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-attach-VPC2

これによって，VIP宛ての業務通信がVPC2に転送されます。

トランジットゲートウェイルートテーブル（tgw-R1）に，VIPのエントリを追加する。

ターゲットをピアリング用のトランジットゲートウェイアタッチメント（tgw-attach-P）とするVIPのエントリを追加します。

表4‒13　トランジットゲートウェイルートテーブル（tgw-R1）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-attach-P

これによって，VIP宛ての業務通信がピアリングしているトランジットゲートウェイ1（tgw-R1）に転送されます。

ルートテーブル（VPC1）に，VIPのエントリを追加する。

ターゲットをトランジットゲートウェイ1（tgw-R1）とするVIPのエントリを追加します。

表4‒14　ルートテーブル（VPC1）の内容

Destination

Target

VIP（10.10.10.10/32）

tgw-R1

これによって，VIP宛ての業務通信がトランジットゲートウェイ1（tgw-R1）に転送されます。

OSのネットワークインタフェースにVIPを追加する。

待機サーバ側のサーバーインスタンスでOSのipコマンドを使用して，VIPを追加します。

実行サーバが切り替わる。

上記の2段階の動作によって，VIPによる業務通信が実行サーバ側のサーバーインスタンスから，待機サーバ側のサーバーインスタンスに切り替わります。

(3)　VIP制御による業務通信の切り替え（クライアントからの通信がNLBを経由する構成の場合）

クライアントがNLBを経由してVIPに通信する構成での，VIP制御による業務通信の切り替えについて説明します。NLBの詳細については，AWSのドキュメントを参照してください。

クライアントがNLBを経由してVIPに通信する構成の例を次の図に示します。

図4‒9　クライアントがNLBを経由してVIPに通信する構成の例

この構成では，次の設定をしてください。

NLBによるトラフィックの転送先にVIPを設定してください。設定するVIPは，NLBの設定の「リスナー」タブにある転送先ターゲットグループで設定してください。

NLBのヘルスチェック関連のパラメタに任意の値を設定してください。

NLBのヘルスチェックを受け取るhttpdは，OS起動時または実行サーバ起動時に起動するように設定してください。

LANの状態設定ファイルを設定してください。設定方法の詳細は「5.14.5　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がNLBを経由する構成の場合）」を参照してください。

(4)　VIP制御による業務通信の切り替え（クライアントからの通信がAWS Network Firewallを経由する構成の場合）

クライアントがAWS Network Firewallを経由してVIPに通信する構成での，VIP制御による業務通信の切り替えについて説明します。AWS Network Firewallの詳細については，AWSのドキュメントを参照してください。

次のすべての条件を満たす構成をサポートします。

1つのVPC内のAZ間で系切り替えする構成で，それぞれのAZにファイアウォールエンドポイントがある。

クライアントからの通信を，実行系インスタンスが稼働するAZのファイアウォールエンドポイントに経由させる。

構成の例を次の図に示します。

図4‒10　クライアントからの通信がAWS Network Firewallを経由する構成の例

この構成での，VIP制御による業務通信の切り替えについて説明します。

AWS上での操作によるルートテーブルの書き換え，およびOSでのエイリアスIPの追加・削除によって，業務通信を切り替えます。

ルートテーブルについては，クライアントからの通信がファイアウォールエンドポイントを経由して，実行系インスタンスのENIに到達するように書き換えます。

VIP制御による業務通信の切り替えの流れについて説明します。

実行系インスタンスから待機系インスタンスにVIPを切り替える場合の動作例を，次の2つの図に示します。

図4‒11　実行系インスタンスから待機系インスタンスにVIPを切り替える場合の動作例（切り替え前）

図4‒12　実行系インスタンスから待機系インスタンスにVIPを切り替える場合の動作例（切り替え後）

業務通信を切り替える前の，各ルートテーブルの例を次に示します。この時点では，VIPは実行系インスタンスのENIを指しています。

表4‒15　ルートテーブル1，ルートテーブル2の例

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

VIP

（例：10.1.0.10/32）

vpce-XXXX

（実行系インスタンスが稼働するAZのファイアウォールエンドポイントID）

-

（凡例）

-：特にありません。

表4‒16　ルートテーブル3の例

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

VIP

（例：10.1.0.10/32）

eni-XXXX

（実行系インスタンスのENI ID）

-

（凡例）

-：特にありません。

表4‒17　ルートテーブル4の例

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

（空白）

（空白）

VIPに対応するエントリなし

（凡例）

-：特にありません。

VIP制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

HAモニタは，AWS CLIで，ルートテーブルから対象のVIPのエントリを削除する。

ルートテーブルの内容（エントリを削除後）：

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

（空白）

（空白）

削除

（凡例）

-：特にありません。

HAモニタは，AWS CLIで，ルートテーブルから対象のVIPのエントリを削除する（1.の結果に関係なく実施する）。

ルートテーブルの内容（エントリを削除後）：

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

（空白）

（空白）

削除

（凡例）

-：特にありません。

HAモニタは，OSのipコマンドを実行することで，ネットワークインタフェースから実行系インスタンスに対するVIPを削除する（1.と2.の結果に関係なく実施する）。

HAモニタは，AWS CLIで，対象のVIPのエントリをルートテーブルに登録する。対象VIPのターゲットは，待機系インスタンスのENIにする。

ルートテーブルの内容（エントリを登録後）：

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

VIP

（例：10.1.0.10/32）

eni-YYYY

（待機系インスタンスのENI ID）

追加

（凡例）

-：特にありません。

HAモニタは，AWS CLIで，対象のVIPのエントリをルートテーブルに登録する。対象VIPのターゲットは，待機系インスタンス側のAZのファイアウォールエンドポイントにする（4.の結果に関係なく実施する）。

ルートテーブルの内容（エントリを再登録後）：

Destination

Target

備考

VPCのネットワーク

（例：10.0.0.0/16）

local

-

VIP

（例：10.1.0.10/32）

vpce-YYYY

（待機系インスタンスが稼働するAZのファイアウォールエンドポイントID）

追加

（凡例）

-：特にありません。

4.で1つ以上のルートテーブルに登録できた場合，HAモニタは，OSのipコマンドを実行することで，ネットワークインタフェースに待機系インスタンスに対するVIPを追加する。

この構成で使用するためのLANの状態設定ファイルについては，「5.14.4　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がAWS Network Firewallを経由する構成の場合）」を参照してください。

(5)　EIP制御による業務通信の切り替え

EIP（Elastic IPアドレス）制御による業務通信の切り替えについて説明します。

AWS上での操作によるEIPの付け替え，およびOSでのEIPの付与・削除によって業務通信を切り替えます。

実行系インスタンスから待機系インスタンスにEIPを切り替える場合の動作例について次の図に示します。

図4‒13　EIP制御による業務通信の切り替えの動作例

切り替え前は，EIPは実行系インスタンスのENIに関連づけられています。

EIP制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

HAモニタは，AWS CLIで，EIPと実行系インスタンスのENIの関連づけを解除する。

HAモニタは，実行系インスタンスで，OSのipコマンドを実行することによって，ネットワークインタフェースからEIPを削除する。

HAモニタは，AWS CLIで，EIPと待機系インスタンスのENIの関連づけをする。

HAモニタは，待機系インスタンスで，OSのipコマンドを実行することによって，ネットワークインタフェースにEIPを付与する。

これらの処理をするために，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」を参照してください。

(6)　DNS名制御による業務通信の切り替え

DNS名制御による業務通信の切り替えについて説明します。

Amazon Route 53のホストゾーンに登録しているレコードを変更することによって，業務通信を切り替えます。

重要

ホストゾーンは，事前に作成する必要があります。関連づけたVPCにだけレコードを公開する場合は，プライベートホストゾーンを作成してください。インターネットにレコードを公開する場合は，パブリックホストゾーンを作成してください。

ホストゾーンの作成方法の詳細ついては，AWSのドキュメントを参照してください。

レコードの変更方法は，次のどちらかを選択してください。

レコードを更新する方法

レコードを削除したあとレコードを更新する方法

それぞれの方法の詳細について，次の表に示します。

表4‒18　Amazon Route 53のホストゾーンに登録しているレコードの変更方法

方法

系切り替え元による処理

系切り替え先による処理

実行サーバ停止時のレコードの状態

実行サーバ停止時のクライアントからの通信

レコードを更新する方法

なし

レコードの更新

残る

サーバが停止しているときもレコードが残っているため，クライアントからのDNS名を使用した通信がインスタンスまで到達します。

レコードを削除したあとレコードを更新する方法

レコードの削除

レコードの更新（追加）

残らない

サーバが停止しているときは，クライアントからDNS名を使用した通信はインスタンスまで到達しません。

「レコードを更新する方法」より「レコードを削除したあとレコードを更新する方法」の方が，処理に時間が掛かります。そのため，「レコードを更新する方法」を推奨します。「実行サーバ停止時のクライアントからの通信」がシステム要件に合わない場合は，「レコードを削除したあとレコードを更新する方法」を選択してください。

それぞれの方法の処理の流れについて説明します。

レコードを更新する方法

レコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。

図4‒14　レコードを更新する場合の動作例

変更前のレコードの例を次に示します。

表4‒19　変更前のレコード（レコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

実行系インスタンスのIPアドレス

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-

（凡例）

-：特にありません。

注※

この例では，IPv4アドレスを記録するAレコードタイプを使用しています。

業務通信を切り替える動作を次に示します。番号は，図中の番号と対応しています。

レコードの更新をAWS CLIで要求する。

レコードの更新が完了したことをAWS CLIで確認する。

変更後のレコードの例を次に示します。

表4‒20　変更後のレコード（レコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A）

実行系インスタンスのIPアドレス

（例：200.200.200.200）

キャッシュ生存期間

（例：60秒）

更新

レコードを削除したあとレコードを更新する方法

レコードを削除したあとレコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。

図4‒15　レコードを削除したあとレコードを更新する場合の動作例

変更前のレコードの例を次に示します。

表4‒21　変更前のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

実行系インスタンスのIPアドレス

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-

（凡例）

-：特にありません。

注※

この例では，IPv4アドレスを記録するAレコードタイプを使用しています。

業務通信を切り替える動作を次に示します。番号は，図中の番号と対応しています。

レコードの削除をAWS CLIで要求する。

レコードの削除が完了したことをAWS CLIで確認する。

削除後のレコードの例を次に示します。

表4‒22　削除後のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

（空白）

（空白）

（空白）

（空白）

削除

レコードの追加をAWS CLIで要求する。

レコードの追加が完了したことをAWS CLIで確認する。

追加後のレコードの例を次に示します。

表4‒23　追加後のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A）

実行系インスタンスのIPアドレス

（例：200.200.200.200）

キャッシュ生存期間

（例：60秒）

追加

重要

これらの処理をするために，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」を参照してください。

4.2.3　【Azure】LANの管理

クライアントから実行サーバへの通信を実現するために，HAモニタは次の制御をします。

OSでのエイリアスIPの追加・削除（DNS名制御の場合を除く）

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「LANの管理」を参照してください。ただし，Azure環境下では次の点が異なります。

OSのarpingコマンドは実行不要※

エイリアスIPを割り当てるとき，ブロードキャストアドレスは指定不可

注※

Azureでの通信経路の制御によって，通信経路が定まるためです。

Azureでの通信経路の制御

クライアントから実行サーバへ通信できるようにするために，HAモニタが業務通信経路の切り替えを制御します。次の表のとおり，クライアントからの通信方法によって，業務通信の切り替え方法を決定してください。

表4‒24　Azure環境下の業務通信の切り替え方法

クライアントからの通信方法

業務通信の切り替え方法

プライベートIPアドレスで通信する方法

Azure ロードバランサー制御による業務通信の切り替え

パブリックIPアドレスで通信する方法

DNS名で通信する方法

DNS名制御による業務通信の切り替え

次に，それぞれの通信経路の制御方式について説明します。

(1)　Azure ロードバランサー制御による業務通信の切り替え

Azure ロードバランサー制御による業務通信の切り替えについて説明します。

Azure ロードバランサーには，関連づけた複数の仮想マシンにトラフィックを分散させる機能があります。Azure ロードバランサーは，特定のプロトコルおよびポートを使用して，一定時間ごとに仮想マシンの正常性確認を実行します。正常性確認に応答があった仮想マシンにトラフィックを転送し，応答がなかった仮想マシンにはトラフィックを転送しません。

HAモニタでは，実行系仮想マシンだけが正常性確認に応答するように制御することで，クライアントが実行サーバと通信できるようにします。

Azure ロードバランサー制御によって，業務通信を切り替える流れを次の図に示します。

図4‒16　Azure ロードバランサー制御による業務通信の切り替えの流れ

上記の図の系切り替え前は，仮想マシン2だけがAzure ロードバランサーからの正常性確認に応答します。そのため，仮想マシン2だけにトラフィックが転送されます。系切り替え後は，仮想マシン3だけがAzure ロードバランサーからの正常性確認に応答します。そのため，仮想マシン3だけにトラフィックが転送されます。

Azure ロードバランサー制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

実行系仮想マシンで正常性確認を待ち受けるポートを閉塞する。

実行系仮想マシンのLinuxのループバックインターフェイスから，エイリアスIPアドレス（Azure ロードバランサーのIPアドレス）を削除する。

待機系仮想マシンのLinuxのループバックインターフェイスに，エイリアスIPアドレス（Azure ロードバランサーのIPアドレス）を付与する。

待機系仮想マシンで正常性確認を待ち受けるポートを開放する。

Azure ロードバランサー制御による業務通信の切り替えをするためには，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.6　【Azure】LANの状態設定ファイルの設定」を参照してください。

(2)　DNS名制御による業務通信の切り替え

DNS名制御による業務通信の切り替えについて説明します。

Azure DNSに登録しているレコードを変更することによって，業務通信を切り替えます。このレコードには，DNS名と実行系仮想マシンのIPアドレスの対応が記載されています。

レコードの変更方法は，次のどちらかを選択してください。

レコードを更新する方法

レコードを削除したあとレコードを更新する方法

それぞれの方法の詳細について，次の表に示します。

表4‒25　Azure DNSに登録しているレコードの変更方法

方法

系切り替え元による処理

系切り替え先による処理

実行サーバ停止時のレコードの状態

実行サーバ停止時のクライアントからの通信

レコードを更新する方法

なし

レコードの更新

残る

サーバが停止しているときもレコードが残っているため，クライアントからのDNS名を使用した通信がインスタンスまで到達します。

レコードを削除したあとレコードを更新する方法

レコードの削除

レコードの更新（追加）

残らない

サーバが停止しているときは，クライアントからDNS名を使用した通信はインスタンスまで到達しません。

「レコードを更新する方法」より「レコードを削除したあとレコードを更新する方法」の方が，処理に時間が掛かります。そのため，「レコードを更新する方法」を推奨します。「実行サーバ停止時のクライアントからの通信」がシステム要件に合わない場合は，「レコードを削除したあとレコードを更新する方法」を選択してください。

それぞれの方法の処理の流れについて説明します。

レコードを更新する方法

レコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。

図4‒17　レコードを更新する方法の動作例

図の例では，Azure DNSのDNSゾーンに，DNS名と仮想マシン2のIPアドレスとを対応させるレコードを登録します。これによって，クライアントから，DNS名を使用した通信ができます。系切り替え時は，このレコードを，DNS名と仮想マシン3のIPアドレスとを対応させるレコードに更新することによって，業務通信を切り替えます。

変更前のレコードの例を次に示します。

表4‒26　変更前のレコード（レコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

実行系仮想マシン2のIPアドレス

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-

（凡例）

-：特にありません。

注※

この例では，IPv4アドレスを記録するAレコードタイプを使用しています。

図中の仮想マシン2から，仮想マシン3に系切り替えをするときの動作を次に示します。番号は，図中の番号と対応しています。

新規のレコード追加を要求する。

新規（更新しようとしている内容）のレコード追加をAzure CLIで要求します。

新規のレコード追加を確認する。

新規（更新しようとしている内容）のレコード追加が完了したことをAzure CLIで確認します。

変更後のレコードの例を次に示します。

表4‒27　変更後のレコード（レコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A）

実行系仮想マシン3のIPアドレス

（例：200.200.200.200）

キャッシュ生存期間

（例：60秒）

更新

レコードを削除したあとレコードを更新する方法

レコードを削除したあとレコードを更新する方法によって，業務通信を切り替える流れを次の図に示します。

図4‒18　レコードを削除したあとレコードを更新する方法の動作例

変更前のレコードの例を次に示します。

表4‒28　変更前のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

実行系仮想マシン2のIPアドレス

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-

（凡例）

-：特にありません。

注※

この例では，IPv4アドレスを記録するAレコードタイプを使用しています。

図中の仮想マシン2から，仮想マシン3に系切り替えをするときの動作を次に示します。番号は，図中の番号と対応しています。

レコードの削除をAzure CLIで要求する。

レコードの削除が完了したことをAzure CLIで確認する。

削除後のレコードの例を次に示します。

表4‒29　削除後のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

（空白）

（空白）

（空白）

（空白）

削除

レコードの追加をAzure CLIで要求する。

レコードの追加が完了したことをAzure CLIで確認する。

変更後のレコードの例を次に示します。

表4‒30　変更後のレコード（レコードを削除したあとレコードを更新する方法）

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A）

実行系仮想マシン3のIPアドレス

（例：200.200.200.200）

キャッシュ生存期間

（例：60秒）

更新

重要

これらの処理をするために，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.6　【Azure】LANの状態設定ファイルの設定」を参照してください。

4.2.4　【OCI】LANの管理

クライアントから実行サーバへの通信を実現するために，HAモニタは次の制御をします。

OSでのエイリアスIPの追加・削除

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「LANの管理」を参照してください。ただし，OCI環境下では次の点が異なります。

OSのarpingコマンドは実行不要※

エイリアスIPを割り当てるとき，ブロードキャストアドレスは指定不可

注※

OCIでの通信経路の制御によって，通信経路が定まるためです。

OCIでの通信経路の制御

クライアントから実行サーバへ通信できるようにするために，プライベートIPアドレスの制御によって業務通信を切り替えます。

プライベートIPアドレス制御による業務通信の切り替えについて，次に説明します。

(1)　プライベートIPアドレス制御による業務通信の切り替え

OCI上での操作によるプライベートIPアドレスの付け替え，およびOS上でのプライベートIPアドレスの付与・削除によって，業務通信を切り替えます。

プライベートIPアドレス制御によって，業務通信を切り替える流れを次の図に示します。

図4‒19　プライベートIPアドレス制御による業務通信の切り替えの流れ

プライベートIPアドレス制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

HAモニタは，OCI CLIで，実行系インスタンスのVNICからプライベートIPアドレスの割り当てを解除する。

HAモニタは，実行系インスタンスで，OSのipコマンドを実行することによって，ネットワークインタフェースからプライベートIPアドレスを削除する。

HAモニタは，OCI CLIで，待機系インスタンスのVNICにプライベートIPアドレスを割り当てる。

HAモニタは，待機系インスタンスで，OSのipコマンドを実行することによって，ネットワークインタフェースにプライベートIPアドレスを付与する。

プライベートIPアドレス制御による業務通信の切り替えをするためには，LANの状態設定ファイルを設定する必要があります。LANの状態設定ファイルについては，「5.14.7　【OCI】LANの状態設定ファイルの設定」を参照してください。

4.3　【AWS】処理の流れ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「処理の流れ」を参照してください。ただし，AWS環境下では，次の点が異なります。

実行サーバの起動時（系切り替え時も含む）

ネットワークインタフェース状態設定前に，VIP制御，EIP制御またはDNS名制御によって業務の通信先を実行系にする。

レプリケーション構成でDRBDを使用している場合，業務ディスクを参照＋更新接続したあと，DRBDがディスクに対応するDRBDのリソースをプライマリに昇格させる。

レプリケーション構成でHVRDを使用している場合，制御グループを参照＋更新可能状態に設定したあと，制御グループに登録されているレプリケーション用疑似デバイスを，HVRDが"online-primary"にする。

実行サーバの停止時（サーバ障害などによる停止も含む）

ネットワークインタフェース状態設定前に，VIP制御，EIP制御またはDNS名制御によって業務の通信先を削除する。

レプリケーション構成でDRBDを使用している場合，業務ディスクを切り離したあと，DRBDがディスクに対応するDRBDのリソースをセカンダリに降格させる。

レプリケーション構成でHVRDを使用している場合，制御グループを更新不可＋参照専用状態に設定したあと，制御グループに登録されているレプリケーション用疑似デバイスを，HVRDが"online-standby"にする。系切り替え時は，レプリケーションが開始されると，制御グループに登録されているレプリケーション用疑似デバイスを，HVRDが"online-secondary"にする。

系のリセット

ネットワーク遮断をする場合は，ネットワーク遮断とリセットをします。

4.4　【Azure】処理の流れ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「処理の流れ」を参照してください。ただし，Azure環境下では，次の点が異なります。

実行サーバの起動時（系切り替え時も含む）

ネットワークインタフェース状態設定前に，Azure ロードバランサー制御またはDNS名制御によって業務の通信先を実行系にする。

レプリケーション構成の場合，業務ディスクを参照＋更新接続したあと，DRBDがディスクに対応するDRBDのリソースをプライマリに昇格させる。

実行サーバの停止時（サーバ障害などによる停止も含む）

ネットワークインタフェース状態設定前に，Azure ロードバランサー制御またはDNS名制御によって業務の通信先を削除する。

レプリケーション構成の場合，業務ディスクを切り離したあと，DRBDがディスクに対応するDRBDのリソースをセカンダリに降格させる。

4.5　【OCI】処理の流れ

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「処理の流れ」を参照してください。ただし，OCI環境下では，次の点が異なります。

実行サーバの起動時（系切り替え時も含む）

ネットワークインタフェース状態設定前に，プライベートIPアドレス制御によって業務の通信先を実行系にする。

実行サーバの停止時（サーバ障害などによる停止も含む）

ネットワークインタフェース状態設定前に，プライベートIPアドレス制御によって業務の通信先を削除する。

5　システムの構築

HAモニタを組み込んだシステムの構築手順，HAモニタのディレクトリ構成，およびHAモニタのシステムの構築に必要な各設定について説明します。システムの構築は，スーパユーザの権限で行ってください。この章では，システム構築の前提となるハードウェアはすでに構成されているものとして説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「システムの構築」とあわせてお読みください。

5.1　構築の流れ

構築の流れについては，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「構築の流れ」の説明を参照してください。この節では，構築の流れについて，パブリッククラウド環境下で差異がある事項だけを記載します。

5.1.1　系のリセットまたはネットワーク遮断をする場合

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系のリセットをする場合（BladeSymphonyまたはHA8000）」を参照してください。ただし，パブリッククラウド環境下では次の点が異なります。

「HAモニタで使用するためのVMware ESXiの設定」は不要です。代わりに，次を設定します。

AWSかつDRBDを使用する方

「5.2　【AWS】AWSの設定」および「5.5　【AWS】【Azure】レプリケーションソフト（DRBD）の設定」をしてください。

AWSかつHVRDを使用する方

「5.2　【AWS】AWSの設定」および「5.6　【AWS】レプリケーションソフト（HVRD）の設定」をしてください。

Azureを使用する方

「5.3　【Azure】Azureの設定」および「5.5　【AWS】【Azure】レプリケーションソフト（DRBD）の設定」をしてください。

OCIを使用する方

「5.4　【OCI】OCIの設定」をしてください。

「リセットパスの設定」は不要です。

5.2　【AWS】AWSの設定

AWS環境下でHAモニタを使用する場合に，AWSで設定する事項について説明します。

5.2.1　AWS CLIのインストール・設定

HAモニタは，AWS CLIを実行して，業務通信の切り替えやインスタンスの強制停止を実施します。AWS CLIのインストールおよび設定について説明します。

Linux OS上にAWS CLIをインストールします。HAモニタはAWS CLIを/usr/bin/awsで実行するため，インストールの際は，次のどちらかを実行してください。

インストールパスを/usr/binにする

インストールパス/bin/awsへのシンボリックリンクawsを/usr/bin配下に作成する

重要

インスタンスの設定で，インスタンスメタデータサービスのバージョン2（IMDSv2）だけを有効にする場合は，IMDSv2に対応したバージョン（1.16.287以降）をインストールしてください。

インスタンスメタデータサービス（IMDS）の設定についての詳細は，AWSのドキュメントを参照してください。

なお，各インスタンスでTCPポート443でのHTTPS通信ができるように設定してください。

また，インスタンスのrootユーザが次のアクションを実行できる必要があります。使用する通信制御の方式によって，必要なアクションは異なります。IAMポリシーを適切に設定してください。

通信制御の方式に関係なく，共通で必要なアクション

ec2:Describe*

ec2:StartInstances

ec2:StopInstances

VIP制御による業務通信の切り替えを使用する場合に必要なアクション

ec2:DeleteRoute

ec2:CreateRoute

ec2:CreateTransitGatewayRoute※

ec2:DeleteTransitGatewayRoute※

ec2:SearchTransitGatewayRoutes※

注※

複数のリージョン間または複数のVPC間で系切り替えをする場合に必要です。

EIP制御による業務通信の切り替えを使用する場合に必要なアクション

ec2:AssociateAddress

ec2:DisassociateAddress

DNS名制御による業務通信の切り替えを使用する場合に必要なアクション

Route 53:ListResourceRecordSets

Route 53:ChangeResourceRecordSets

Route 53:GetChange

ネットワーク遮断をする場合に必要なアクション

ec2:DetachNetworkInterface

ec2:AttachNetworkInterface

業務ディスクとしてEFSを使用する場合に必要なアクション

elasticfilesystem:DescribeFileSystems

Linux Tough Dumpと連携する場合に必要なアクション

ec2:SendDiagnosticInterrupt

AWS CLIのインストール方法および設定に関する詳細は，AWSのドキュメントを参照してください。

5.2.2　エンドポイントの設定

HAモニタをインストールしたインスタンスがEC2サービスのエンドポイントに接続できるようにしてください。エンドポイントの設定に関する詳細は，AWSのドキュメントを参照してください。

5.2.3　インスタンスのメタデータ取得のための設定

HAモニタがインスタンスのメタデータを取得するため，次のとおりに設定してください。

IPアドレス169.254.169.254にプロトコルHTTPでアクセスできるように設定する

iptablesなどで通信を制限する場合は，rootユーザのプロセスからIPアドレス169.254.169.254への通信を許可してください。

インスタンスの設定で，インスタンスメタデータサービス（IMDS）を有効にする

インスタンスメタデータサービス（IMDS）についての詳細は，AWSのドキュメントを参照してください。

5.2.4　プロキシを使用する場合の設定

HTTPおよびHTTPS通信をプロキシ経由で実施する場合，HAモニタがCLI通信およびメタデータの取得ができるように，次のように設定してください。

HAモニタのUnit設定ファイル/usr/lib/systemd/system/HAmon-powercontrol.serviceに，HTTP_PROXY，HTTPS_PROXYおよびNO_PROXY環境変数を設定する

プロキシおよび環境変数の詳細は，AWSのドキュメントを参照してください。なお，環境変数は小文字で指定する必要がある場合があります。環境に応じて適切に設定してください。

設定例を次に示します。太字部分を環境に応じて設定してください。

[Unit]
Description=HA Monitor(power control)
      :
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwon >/dev/null 2>&1'
ExecStop=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwoff >/dev/null 2>&1'
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=169.254.169.254"
      :（以降省略）

5.2.5　ENIの設定

業務通信の切り替えにVIP方式を使用する場合，ENIに付与されているプライベートIPアドレスとは異なるIPアドレスを宛先としたパケットがENIに届きます。ENIのデフォルト設定では，無関係の宛先IPアドレスのパケットは破棄されます。VIP宛のパケットを各インスタンスが受け取れるように，各インスタンスのENIの「送信元/送信先チェック」を無効化して，宛先が破棄されないようにしてください。

5.2.6　EBSマルチアタッチの設定

EBSマルチアタッチ機能を使用して現用系と待機系の間で業務ディスクを引き継ぐ構成（共有ディスク構成）にする場合，EBSマルチアタッチの設定をします。

EBSマルチアタッチを設定するには，EBSの作成画面で「ボリュームタイプ」に「Provisioned IOPS SSD (io2)」を選択し，「Multi-Attach」をチェックします。その後，作成したEBSを複数のインスタンスにアタッチします。

EBSマルチアタッチの設定に関する詳細は，AWSのドキュメントを参照してください。

5.2.7　EFSの設定

EFSを使用して現用系と待機系の間で業務ディスクを引き継ぐ構成（共有ディスク構成）にする場合，EFSの設定をします。

EFSを使用する場合に，必要な設定を次に示します。

ストレージクラス

複数のAZ間でのクラスタ構成にする場合，ストレージクラスを「標準」に設定してください。データを，複数のAZに，冗長化して保存できるようにするためです。

1つのAZ内でのクラスタ構成にする場合，任意の項目に設定してください。

インスタンスからのアクセス

インスタンスからファイルシステムに，DNS名でアクセスできるように設定してください。

ネットワーク遮断による系切り替えをする場合，ファイルシステムへのアクセスに，プライマリENIを使用しないでください。

アクセスするENI以外からの通信を許可しないように，EFSのセキュリティを設定してください。

5.3　【Azure】Azureの設定

Azure環境下でHAモニタを使用する場合に，Azureで設定する事項について説明します。

5.3.1　Azure CLIのインストール・設定

HAモニタは，Azure CLIを実行して，業務通信の切り替えやインスタンスの強制停止を実施します。Azure CLIのインストールおよび設定について，次に説明します。

Azure CLIのインストール

Linux OS上にAzure CLIをインストールします。Azure CLIのインストール方法に関する詳細は，Azureのドキュメントを参照してください。

Azure CLIの設定

Azure CLIの設定に関する詳細は，Azureのドキュメントを参照してください。

HAモニタでは，HAモニタ専用のサービスプリンシパルを使用して，Azureリソースにアクセスします。そのため，サービスプリンシパルを作成する必要があります。

次の手順でサービスプリンシパルを作成してください。

サービスプリンシパルに割り当てるカスタムロールの作成

Azureは，Azureリソースに対してロールベースのアクセス制御を実施します。ロールは，Azureリソースへのアクセス許可の集合体を指し，ユーザに割り当てられます。

Azureリソースにアクセスするために，次のパスのアクセスを許可してください。

・Microsoft.Compute/virtualMachines/read

・Microsoft.Compute/virtualMachines/start/action

・Microsoft.Compute/virtualMachines/powerOff/action

また，DNS名制御によって業務通信を切り替える場合，次のパスもアクセスを許可してください。

DNSゾーン

レコードタイプ

必要なアクセス許可

パブリックゾーン

A

Microsoft.Network/dnsZones/A/read

Microsoft.Network/dnsZones/A/write

Microsoft.Network/dnsZones/A/delete

Microsoft.Network/dnsZones/NS/read

CNAME

Microsoft.Network/dnsZones/CNAME/read

Microsoft.Network/dnsZones/CNAME/write

Microsoft.Network/dnsZones/CNAME/delete

Microsoft.Network/dnsZones/NS/read

プライベートゾーン

A

Microsoft.Network/privateDnsZones/A/read

Microsoft.Network/privateDnsZones/A/write

Microsoft.Network/privateDnsZones/A/delete

CNAME

Microsoft.Network/privateDnsZones/CNAME/read

Microsoft.Network/privateDnsZones/CNAME/write

Microsoft.Network/privateDnsZones/CNAME/delete

上記のアクセス許可を持つ既定のロールを割り当てても問題ありませんが，HAモニタに上記以外のアクセス許可を与えないように，HAモニタ専用のロールを作成してサービスプリンシパルに割り当てることを推奨します。上記のアクセス許可がない場合は，仮想マシンの強制停止および業務通信の切り替えがエラーとなり，失敗します。

ロールやアクセス許可などの設定に関する詳細は，Azureのドキュメントを参照してください。

サービスプリンシパルの作成

HAモニタ専用のサービスプリンシパルを作成し，ロールとして「1.」で作成したカスタムロールを割り当ててください。

サービスプリンシパルのログイン認証方法として，証明書を設定してください。業務の稼働中に有効期限が切れないようにするため，証明書の有効期限には，業務の稼働期間より十分に長い期間を設定してください。有効期限が切れた場合は，サーバの起動や系切り替えなどに失敗するおそれがあります。

サービスプリンシパルの作成に関する詳細は，Azureのドキュメントを参照してください。

なお，サービスプリンシパルのアプリケーションID，認証に使用する証明書の格納パス，およびテナントIDは，HAモニタの設定で使用します。HAモニタの設定については，「5.13.2　【Azure】サービスプリンシパル情報設定ファイルの設定」を参照してください。

5.3.2　インスタンスのメタデータ取得のための設定

HAモニタがインスタンスのメタデータを取得するため，次のとおりに設定してください。

IPアドレス169.254.169.254にプロトコルHTTPでアクセスできるように設定する

iptablesなどで通信を制限する場合は，rootユーザのプロセスからIPアドレス169.254.169.254への通信を許可してください。

5.3.3　プロキシを使用する場合の設定

HTTPおよびHTTPS通信をプロキシ経由で実施する場合，HAモニタがCLI通信およびメタデータの取得ができるように，次のように設定してください。

HAモニタのUnit設定ファイル/usr/lib/systemd/system/HAmon-powercontrol.serviceに，HTTP_PROXY，HTTPS_PROXYおよびNO_PROXY環境変数を設定する

プロキシおよび環境変数の詳細は，Azureのドキュメントを参照してください。なお，環境変数は小文字で指定する必要がある場合があります。環境に応じて適切に設定してください。

設定例を次に示します。太字部分を環境に応じて設定してください。

[Unit]
Description=HA Monitor(power control)
      :
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwon >/dev/null 2>&1'
ExecStop=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwoff >/dev/null 2>&1'
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=169.254.169.254"
      :（以降省略）

5.3.4　Azure ロードバランサーの作成・設定

Azure ロードバランサーの制御によって業務通信の切り替えをする場合，Azure ロードバランサーの作成および設定をします。Azure ロードバランサーの作成および設定に関する詳細は，Azureのドキュメントを参照してください。

ここでは，HAモニタで必要な設定について説明します。次の設定をしてください。

バックエンドプールの設定

バックエンドプールに実行系仮想マシンおよび待機系仮想マシンを設定します。

フロントエンドIPアドレス

業務通信に使用するIPアドレスをAzure ロードバランサーに設定します。

正常性プローブ

次の値を設定します。

・プロトコル：TCP

・ポート：ほかの用途で使用されていないポート番号

・間隔：5

・異常しきい値：2

なお，業務通信に使用するIPアドレスが複数ある場合は，ポート番号が重複しないように複数の正常性プローブを作成してください。

負荷分散規則

上記のフロントエンドIPアドレス，および正常性プローブで指定したポート番号を指定して作成します。業務通信が複数ある場合は，業務通信ごとに設定したフロントエンドIPアドレス，および正常性プローブで指定したポート番号を指定して，複数の規則を作成します。

各負荷分散規則では，フローティングIP（Direct Server Return）を有効に設定します。バックエンドの仮想マシンで稼働するサーバが，系切り替え前後で同じIPアドレスで通信できるようにするためです。

なお，フロントエンドIPアドレス，および正常性プローブで指定したポート番号は，HAモニタにも設定します。HAモニタの設定については，「5.14.6　【Azure】LANの状態設定ファイルの設定」を参照してください。

5.3.5　Azure DNSの設定

DNS名制御によって業務通信の切り替えをする場合，DNSゾーンの作成および設定をしてください。詳細は，Azureのドキュメントを参照してください。

DNSゾーン名，およびDNSゾーンを収容するリソースグループ名は，HAモニタの設定で使用します。HAモニタの設定については，「5.14.6　【Azure】LANの状態設定ファイルの設定」を参照してください。

5.3.6　マネージドディスクの共有

マネージドディスクを複数の仮想マシンにアタッチすることで共有ディスク構成にできます。

マネージドディスクの共有については，Azureのドキュメントを参照してください。

5.4　【OCI】OCIの設定

OCI環境下でHAモニタを使用する場合に，OCIで設定する事項について説明します。

5.4.1　OCI CLIのインストール・設定

HAモニタは，OCI CLIを実行して，業務通信の切り替えやインスタンスの強制停止を実施します。OCI CLIのインストールおよび設定について説明します。

Linux OS上にOCI CLIをインストールします。HAモニタはOCI CLIを/root/bin/ociで実行するため，OCI CLIは/root/bin/ociで実行できるように設定してください。

また，インスタンスのrootユーザが，系切り替え構成内のインスタンスおよびVNICにアクセスします。次のIAMポリシーを設定してください。

Allow <subject> to use instances in <location>

Allow <subject> to use vnics in <location>

Allow <subject> to use private-ips in <location>

Allow <subject> to use subnets in <location>

上記以外のIAMポリシーについては，ポリシー構文に従い，環境に合わせて適切に設定してください。

OCI CLIのインストール方法および設定に関する詳細は，OCIのドキュメントを参照してください。

5.4.2　インスタンスのメタデータ取得のための設定

HAモニタがインスタンスのメタデータを取得するため，次のとおりに設定してください。

IPアドレス169.254.169.254にプロトコルHTTPでアクセスできるように設定する

iptablesなどで通信を制限する場合は，rootユーザのプロセスからIPアドレス169.254.169.254への通信を許可してください。

インスタンスメタデータサービス（IMDS）のバージョン1を有効にする

インスタンスメタデータサービス（IMDS）についての詳細は，OCIのドキュメントを参照してください。

5.4.3　プロキシを使用する場合の設定

HTTPおよびHTTPS通信をプロキシ経由で実施する場合，HAモニタがCLI通信およびメタデータの取得ができるように，次のように設定してください。

HAモニタのUnit設定ファイル/usr/lib/systemd/system/HAmon-powercontrol.serviceに，HTTP_PROXY，HTTPS_PROXYおよびNO_PROXY環境変数を設定する

プロキシおよび環境変数の詳細は，OCIのドキュメントを参照してください。なお，環境変数は小文字で指定する必要がある場合があります。環境に応じて適切に設定してください。

設定例を次に示します。太字部分を環境に応じて設定してください。

[Unit]
Description=HA Monitor(power control)
      :
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwon >/dev/null 2>&1'
ExecStop=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwoff >/dev/null 2>&1'
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=169.254.169.254"
      :（以降省略）

5.4.4　エンドポイントの設定

HAモニタをインストールしたインスタンスがコア・サービスのエンドポイントに接続できるようにしてください。エンドポイントの設定に関する詳細は，OCIのドキュメントを参照してください。

5.4.5　ブロック・ボリュームの設定

共有ディスクとして使用するブロック・ボリュームを，系切り替え構成のインスタンスにマルチアタッチしてください。このとき，アタッチメント・タイプは「iSCSI」「準仮想化」のどちらかを選択し，アクセス・タイプは「読取り/書込み - 共有可能」を選択してください。ボリュームグループ，lvm.conf，およびファイルシステムなどの設定は，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有ディスクの設定」を参照してください。

5.4.6　/etc/hostsファイルの永続化

/etc/hostsファイルに加えた変更内容を永続化するため，次の行を/etc/oci-hostname.confに追加してください。

PRESERVE_HOSTINFO=2

詳細はOCIのドキュメントを参照してください。

5.5　【AWS】【Azure】レプリケーションソフト（DRBD）の設定

レプリケーションソフト（DRBD）を使用する場合に必要な設定について説明します。詳細については，DRBDのドキュメントを参照してください。

定義チェックコマンド（moncheckコマンド）による定義チェック前までに実施する設定

業務ディスクを構成するDRBD論理デバイスの作成

DRBD論理デバイスは，/dev配下のデバイス（/dev/nvme1n1p1など）を使用して作成する必要があります。なお，作成済みのLVMの論理ボリュームは，DRBD論理デバイスには使用できません。

作成したDRBD論理デバイスをLVMの物理ボリューム（Physical volume）として，LVMのボリュームグループを構成

OS起動時にレプリケーションソフト（DRBD）を自動起動する設定

OSのsystemctlコマンドを実行して，サービスを有効化してください。

サービスの有効化方法を，次に示します。

# systemctl enable drbd

リソースの設定

次に示す項目は必ず設定してください。次に示す項目以外は環境に合わせて設定してください。

ハンドラの設定

commonセクションのfence-peerハンドラに，/opt/hitachi/HAmon/bin/parts/monfence-peer.shを設定します。

自動プロモーション（auto-promoteオプション）

yesを指定します。

同期モード（protocolオプション）

系切り替え時のデータの欠損を防止するため，プロトコルCの設定を推奨します。

フェンシングの設定（fencingオプション）

resource-and-stonithを設定します。

レプリケーションパスの設定（addressオプション）

レプリケーションパスのIPアドレスを指定します。

対向ノード接続待ちの設定（wfc-timeoutオプション）

DRBD起動時に対向ノードと接続できるまで待機する時間を指定します。

レプリケーションソフト（DRBD）の設定例を次に示します。

/etc/drbd.d/global_common.conf

global {
  usage-count no;
}
common {
handlers {
    fence-peer "/opt/hitachi/HAmon/bin/parts/monfence-peer.sh";
　}
  options {
    auto-promote yes;
  }
net {
    protocol C;
    fencing resource-and-stonith;
  }
  startup {
    wfc-timeout 30;
  }
}

/etc/drbd.d/r0.res（リソース名:r0，複数ボリュームグループがある場合）

resource r0 {
  volume 0 {
    device    /dev/drbd1;
    disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_volXXXXX;※
    meta-disk internal;
  }
  volume 1 {
    device    /dev/drbd2;
    disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_volYYYYY;※
    meta-disk internal;
  }
  on host1 {
    address   10.1.1.31:7789;
  }
  on host2 {
    address   10.1.2.32:7789;
  }
}

注※

/dev配下のデバイス名（/dev/nvme1n1p1など）は，OSのデバイス認識順によって変わる場合があります。そのため，認識順に関係なく，デバイスを一意に特定できる/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/nvme1n1p1などへのシンボリックリンクファイル）を指定することをお勧めします。

設定方法の詳細については，レプリケーションソフト（DRBD）のドキュメントを参照してください。

DRBD用シェルスクリプト群の展開

DRBDのプライマリへの昇格を抑止するために，HAモニタはDRBD用のシェルスクリプト群を提供しています。「5.7　【AWS】【Azure】レプリケーションソフト（DRBD）用のシェルスクリプト群の展開」を参照し，シェルスクリプト群を展開してください。

サーバ対応の環境設定の定義

業務ディスクを構成するレプリケーションソフト（DRBD）のリソース名をサーバ対応の環境設定のrep_deviceオペランドに指定します。

rep_deviceオペランドの詳細については，「(a)　rep_device」を参照してください。

構成したボリュームグループをサーバ対応の環境設定のdiskオペランドに指定します。

diskオペランドの詳細は，マニュアル高信頼化システム監視機能 HA モニタ Linux(R)（x86）編の「サーバの環境設定」を参照してください。

リソース制限の変更

ディスクをレプリケーションする構成でHAモニタを使用する場合，次の計算式で求められる値によっては，リソース制限を変更する必要があります。

「サーバ対応の環境設定のrep_deviceオペランドに指定したリソースの合計（サーバ対応の環境設定全体のDRBDのリソース数）」×「接続する系の数－１」

上記の計算式の値に従って，次のとおりに対応してください。

計算式の値が512以下の場合：リソース制限の設定は変更不要です。

計算式の値が512を超える場合：計算式の値に1,024を加えた値を，HAモニタのUnit設定ファイルのServiceセクションの「LimitNOFILE」に指定します。

計算式の例を次に示します。

計算式の例

サーバ対応の環境設定のrep_deviceオペランドに指定したリソースの合計が250，接続する系の数が5の場合は，次のとおりになります。

250×（5－1）＝1,000
1,000＋1,024＝2,024

2,024をLimitNOFILEに設定します。

リソース制限の設定例を次に示します。次のファイルの太字部分を変更してください。

/usr/lib/systemd/system/HAmon-powercontrol.service

[Unit]
Description=HA Monitor(power control)
After= sysinit.target network.target sshd.service jp1_base.service HABooster.service ltd.service haconnd.service drbd.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwon >/dev/null 2>&1'
ExecStop=/bin/sh -c '/opt/hitachi/HAmon/bin/HApwoff >/dev/null 2>&1'
LimitNOFILE=2024

[Install]
WantedBy=multi-user.target

5.6　【AWS】レプリケーションソフト（HVRD）の設定

レプリケーションソフト（HVRD）を使用する場合の設定については，HVRDのドキュメントを参照してください。

5.7　【AWS】【Azure】レプリケーションソフト（DRBD）用のシェルスクリプト群の展開

レプリケーションソフト（DRBD）を使用するために，HAモニタがDRBD用のシェルスクリプト群を提供しています。DRBDのプライマリへの昇格を抑止するために，DRBD用のシェルスクリプト群を展開する必要があります。

DRBD用のシェルスクリプト群の展開イメージを次の図で示します。

図5‒1　DRBD用のシェルスクリプト群の展開イメージ

DRBD用のシェルスクリプト群を次の手順で展開してください。操作はrootユーザで実行してください。

tarコマンドでDRBD用のシェルスクリプト群を展開する。

tarコマンドを実行したカレントディレクトリにファイルが展開されます。

# tar -zxvf /opt/hitachi/HAmon/lib/rep/drbd_script.tar.gz
./script.tar
./setup.sh

setup.shを実行する。

必要なシェルスクリプト群が自動的に配置されます。なお，すでに展開されているレプリケーションソフト用のシェルスクリプト群がある場合は，自動的に削除されます。

# ./setup.sh

注意事項

レプリケーション構成を含めずに共有ディスク構成だけで業務ディスクを制御する場合，DRBD用のシェルスクリプト群を展開しないでください。

5.8　【AWS】AWS用のシェルスクリプト群の展開

AWS CLIを操作をするために，HAモニタがAWS用のシェルスクリプト群を提供しています。HAモニタのインストール後，「5.11　リセットパスの設定」から「5.15　リソースの監視のための設定」までの設定を実施する前に，AWS用のシェルスクリプト群を展開する必要があります。

AWS用のシェルスクリプト群の展開イメージを次の図で示します。

図5‒2　AWS用のシェルスクリプト群の展開イメージ

AWS用のシェルスクリプト群を次の手順で展開してください。操作はrootユーザで実行してください。

tarコマンドでAWS用のシェルスクリプト群を展開する。

tarコマンドを実行したカレントディレクトリにファイルが展開されます。

# tar -zxvf /opt/hitachi/HAmon/lib/cloud/aws_script.tar.gz
./script.tar
./setup.sh

setup.shを実行する。

必要なシェルスクリプト群が自動的に配置されます。なお，すでに展開されているパブリッククラウド用のシェルスクリプト群がある場合は，自動的に削除されます。

# ./setup.sh

5.9　【Azure】Azure用のシェルスクリプト群の展開

Azure CLIを操作するために，HAモニタがAzure用のシェルスクリプト群を提供しています。HAモニタのインストール後，「5.11　リセットパスの設定」から「5.15　リソースの監視のための設定」までの設定を実施する前に，Azure用のシェルスクリプト群を展開する必要があります。

Azure用のシェルスクリプト群の展開イメージを次の図で示します。

図5‒3　Azure用のシェルスクリプト群の展開イメージ

注※

このファイルが/etc下にない場合だけ展開されます。

Azure用のシェルスクリプト群を次の手順で展開してください。操作はrootユーザで実行してください。

tarコマンドでAzure用のシェルスクリプト群を展開する。

tarコマンドを実行したカレントディレクトリにファイルが展開されます。

# tar -zxvf /opt/hitachi/HAmon/lib/cloud/azure_script.tar.gz
./script.tar
./setup.sh

setup.shを実行する。

必要なシェルスクリプト群が自動的に配置されます。なお，すでに展開されているパブリッククラウド用のシェルスクリプト群がある場合は，自動的に削除されます。

# ./setup.sh

5.10　【OCI】OCI用のシェルスクリプト群の展開

OCI CLIを操作するために，HAモニタがOCI用のシェルスクリプト群を提供しています。HAモニタのインストール後，「5.11　リセットパスの設定」から「5.15　リソースの監視のための設定」までの設定を実施する前に，OCI用のシェルスクリプト群を展開する必要があります。

OCI用のシェルスクリプト群の展開イメージを次の図で示します。

図5‒4　OCI用のシェルスクリプト群の展開イメージ

OCI用のシェルスクリプト群を次の手順で展開してください。操作はrootユーザで実行してください。

tarコマンドでOCI用のシェルスクリプト群を展開する。

tarコマンドを実行したカレントディレクトリにファイルが展開されます。

# tar -zxvf /opt/hitachi/HAmon/lib/cloud/oci_script.tar.gz
./script.tar
./setup.sh

setup.shを実行する。

必要なシェルスクリプト群が自動的に配置されます。なお，すでに展開されているパブリッククラウド用のシェルスクリプト群がある場合は，自動的に削除されます。

# ./setup.sh

5.11　リセットパスの設定

パブリッククラウド環境下で使用する場合，リセットパスの設定は不要です。リセットパスの設定がされていても無効となります。

5.12　監視パスの設定

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「監視パスの設定」を参照してください。ただし，パブリッククラウド環境下では次の点が異なります。

監視パスは1つだけ配置する

HAモニタの接続構成設定ファイルは，必ず手動で作成する

また，HAモニタエージェントを使用した構成の場合は，次の点が異なります。

HAモニタエージェントの接続構成設定ファイルは，必ず手動で作成する

HAモニタエージェントの接続構成設定ファイルには，HAモニタエージェントおよび接続するHAモニタすべての系を記載する（pairは指定不要で，指定された場合は無視される）

HAモニタ側の接続構成設定ファイルには，HAモニタエージェントの情報は記載しない

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

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「定義ファイルの作成（HAモニタ）」を参照してください。この節では，パブリッククラウド環境下で差異がある事項だけを記載します。

5.13.1　HAモニタの環境設定

HAモニタの環境を設定する定義ファイルを作成します。

詳細は，「7.2　HAモニタの環境設定」を参照してください。

5.13.2　【Azure】サービスプリンシパル情報設定ファイルの設定

HAモニタがサービスプリンシパルを使用してAzureにログインするには，次の情報が必要です。

アプリケーションID※

認証に使用する証明書の格納パス

テナントID※

注※

Azureポータルから確認できます。

これらの情報をサービスプリンシパル情報設定ファイル（azure_serviceprincipal.env）に設定し，etc配下に配置する必要があります。Azure用のシェルスクリプト群を展開すると，サービスプリンシパル情報設定ファイルのサンプルファイルがlib配下に展開されます。また，サービスプリンシパル情報設定ファイルがetc配下に存在しない場合は，etc配下にも展開されます。

サンプルファイルの内容を次に示す記述形式で編集してください。

appId=aa....aa
fileWithCertAndPrivateKey=/bb....bb/cc....cc.pem
tenant=dd....dd

aa....aa：アプリケーションID

/bb....bb/cc....cc.pem：認証に使用する証明書の格納パス

dd....dd：テナントID

注意事項

上記以外の情報は入力しないでください。

イコール（=）の前後にスペースおよびタブを入力しないでください。

5.13.3　【AWS】ネットワーク遮断設定ファイルの設定

ここでは，パブリッククラウド環境固有のネットワーク遮断設定ファイルについて説明します。

ネットワーク遮断設定ファイル（定義ファイル：/opt/hitachi/HAmon/etc/fence_network.env）は，ネットワーク遮断の対象とするENIのIDを列挙します。

サンプルファイルは/opt/hitachi/HAmon/lib/fence_network.envにあります。サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーしてから設定します。系切り替え構成内の各系で設定してください。

サンプルからコピーしたとき，ネットワーク遮断設定ファイルの内容は，次のようにENIのIDとしては仮の値が列挙されています。

eni-aaaa
eni-bbbb

自系の次のENIのIDを列挙してください。なお，ENIのIDは系ごとに異なるため，ネットワーク遮断設定ファイルの内容は各系で異なります。

業務通信用のENI

レプリケーションパスに使用しているENI

EFSへのアクセス用パスに使用しているENI

HAモニタの監視パスだけで使用するENIについては列挙不要です。

HAモニタの監視パスのENIを業務通信，レプリケーションパス，およびEFSへのアクセス用パスで兼用する場合は，遮断対象のENIとして列挙してください。

ネットワーク遮断設定ファイルの記述ルールは次のとおりです。

1行当たりENI IDを1つ記述する。

ENI IDは1〜10まで指定できる。

同じENI IDを複数指定しないこと。

先頭が#の行はコメント行となる（無視される）。

空白行を指定できる（無視される）。

コメント行を除き，1行は50文字以内で記述する。

5.14　サーバが使用するリソースの設定

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「サーバが使用する共有リソースの設定」を参照してください。この節では，サーバが使用するリソースの設定について，パブリッククラウド環境下で差異がある事項だけを記載します。

5.14.1　業務ディスクの設定

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「共有ディスクの設定」を参照してください。

さらに，AWS環境下およびAzure環境下でレプリケーション構成にする場合，レプリケーションソフトの設定が必要です。レプリケーションソフトとしてDRBDを使用する場合は「5.5　【AWS】【Azure】レプリケーションソフト（DRBD）の設定」，HVRDを使用する場合は「5.6　【AWS】レプリケーションソフト（HVRD）の設定」を参照して，設定してください。

5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）

HAモニタでは，LANはサーバ単位に接続，切り離しをします。そのため，LANの状態設定ファイルを作成して設定する必要があります。この項では，1つのリージョン内または1つのVPC内で系切り替えをする構成での，LANの状態設定ファイルの設定方法について説明します。

LANの状態設定ファイルの種類を，次に示します。

サーバ識別名.upファイル

LANを接続する場合に使用します。業務通信の切り替えに関する情報を設定します。

サーバ識別名.downファイル

LANの切り離しをする場合に使用します。業務通信の切り替えに関する情報を設定します。

これらのファイルは，サーバごとにHAモニタの環境設定用ディレクトリの下に作成します。ファイル名のサーバ識別名の部分は，サーバ対応の環境設定のaliasオペランドで指定した値にしてください。

LANの状態設定ファイルには，OSのipコマンドの引数として，LANアダプタに追加・削除するエイリアスIPアドレスを指定します。OSのコマンドについては，OSのマニュアルを参照してください。

AWS用シェルスクリプト群を展開すると，AWS用のLANの状態設定ファイルのサンプルファイルが，/opt/hitachi/HAmon/lib配下に配置されます。AWS用シェルスクリプト群の展開については，「5.8　【AWS】AWS用のシェルスクリプト群の展開」を参照してください。サンプルファイルの名称は，server_aws.upおよびserver_aws.downです。

server_aws.upのファイル内容を次に示します。

#!/bin/bash
set -x

###############################################################################
# VIP_ADDRESS[0]=aa.bb.cc.dd
# VIP_RTB[0]="rtb-AAA rtb-BBB …"
# VIP_ENI[0]=eni-CCC
# VIP_LABEL[0]=lo:0
# VIP_RTB_TOFW[0]="rtb-NNN rtb-OOO …"
# VIP_FW[0]=vpce-PPP

# VIP_ADDRESS[1]=ee.ff.gg.hh
# VIP_RTB[1]="rtb-DDD rtb-EEE …"
# VIP_ENI[1]=eni-FFF
# VIP_LABEL[1]=lo:1
# VIP_RTB_TOFW[1]="rtb-QQQ rtb-RRR …"
# VIP_FW[1]=vpce-SSS

# EIP_ADDRESS[0]=ii.jj.kk.ll
# EIP_ENI[0]=eni-GGG
# EIP_LABEL[0]=eth0:0

# EIP_ADDRESS[1]=mm.nn.oo.pp
# EIP_ENI[1]=eni-HHH
# EIP_LABEL[1]=eth1:0

# DNS_ZONEID[0]=ZIII
# DNS_NAME[0]=JJJ.com.
# DNS_TYPE[0]=A
# DNS_VALUE[0]=qq.rr.ss.tt
# DNS_TTL[0]=uu

# DNS_ZONEID[1]=ZKKK
# DNS_NAME[1]=LLL.com.
# DNS_TYPE[1]=CNAME
# DNS_VALUE[1]=MMM.com.
# DNS_TTL[1]=vv

###############################################################################
function main() {
    VIP_RCD=0
    if [ ${#VIP_ADDRESS[@]} -gt 0 ]
    then
        add_vip
        rc=$?
        if [ $rc -ne 0 ]
        then
            VIP_RCD=1
        fi
    fi

    EIP_RCD=0
    if [ ${#EIP_ADDRESS[@]} -gt 0 ]
    then
        add_eip
        rc=$?
        if [ $rc -ne 0 ]
        then
            EIP_RCD=2
        fi
    fi

    DNS_RCD=0
    if [ ${#DNS_NAME[@]} -gt 0 ]
    then
        add_dns
        rc=$?
        if [ $rc -ne 0 ]
        then
            DNS_RCD=4
        fi
    fi

    RCD=$(($VIP_RCD|$EIP_RCD|$DNS_RCD))
    return $RCD
}

###############################################################################
：(以下を編集しないこと)

server_aws.downのファイル内容を次に示します。

#!/bin/bash
set -x

###############################################################################
# VIP_ADDRESS[0]=aa.bb.cc.dd
# VIP_RTB[0]="rtb-AAA rtb-BBB …"
# VIP_ENI[0]=eni-CCC
# VIP_LABEL[0]=lo:0
# VIP_RTB_TOFW[0]="rtb-NNN rtb-OOO …"
# VIP_FW[0]=vpce-PPP

# VIP_ADDRESS[1]=ee.ff.gg.hh
# VIP_RTB[1]="rtb-DDD rtb-EEE …"
# VIP_ENI[1]=eni-FFF
# VIP_LABEL[1]=lo:1
# VIP_RTB_TOFW[1]="rtb-QQQ rtb-RRR …"
# VIP_FW[1]=vpce-SSS

# EIP_ADDRESS[0]=ii.jj.kk.ll
# EIP_ENI[0]=eni-GGG
# EIP_LABEL[0]=eth0:0

# EIP_ADDRESS[1]=mm.nn.oo.pp
# EIP_ENI[1]=eni-HHH
# EIP_LABEL[1]=eth1:0

# DNS_ZONEID[0]=ZIII
# DNS_NAME[0]=JJJ.com.
# DNS_TYPE[0]=A
# DNS_VALUE[0]=qq.rr.ss.tt
# DNS_TTL[0]=uu

# DNS_ZONEID[1]=ZKKK
# DNS_NAME[1]=LLL.com.
# DNS_TYPE[1]=CNAME
# DNS_VALUE[1]=MMM.com.
# DNS_TTL[1]=vv

###############################################################################
function main() {
    VIP_RCD=0
    if [ ${#VIP_ADDRESS[@]} -gt 0 ]
    then
        delete_vip
        rc=$?
        if [ $rc -ne 0 ]
        then
            VIP_RCD=1
        fi
    fi

    EIP_RCD=0
    if [ ${#EIP_ADDRESS[@]} -gt 0 ]
    then
        delete_eip
        rc=$?
        if [ $rc -ne 0 ]
        then
            EIP_RCD=2
        fi
    fi

    DNS_RCD=0
    if [ ${#DNS_NAME[@]} -gt 0 ]
    then
        delete_dns
        rc=$?
        if [ $rc -ne 0 ]
        then
            DNS_RCD=4
        fi
    fi

    RCD=$(($VIP_RCD|$EIP_RCD|$DNS_RCD))
    return $RCD
}

###############################################################################
：(以下を編集しないこと)

サーバごとに，サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーして，server_aws.upをサーバ識別名.upに，server_aws.downをサーバ識別名.downにリネームしてください。

サーバ識別名.up/downで設定が必要なシェル変数について説明します。

メモ

ここで説明する[n]は配列の添え字です。VIP，EIP，または業務通信に使用するDNS名が1つの場合，[n]は0です。複数ある場合，1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

サンプルファイルからコピーした状態では，シェル変数部分はコメント行となっています。コメント行を表す先頭の"#"を削除してから，設定してください。例えば，VIPが1つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

VIP_ADDRESS[0]

VIP_RTB[0]

VIP_ENI[0]

VIP_LABEL[0]

VIP_RTB_TOFW[0]

VIP_FW[0]

2つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

VIP_ADDRESS[0]

VIP_RTB[0]

VIP_ENI[0]

VIP_LABEL[0]

VIP_RTB_TOFW[0]

VIP_FW[0]

VIP_ADDRESS[1]

VIP_RTB[1]

VIP_ENI[1]

VIP_LABEL[1]

VIP_RTB_TOFW[1]

VIP_FW[1]

3つ目以降については，シェル変数をコピーするなどの方法で，設定してください。

VIP制御によって業務通信を切り替える場合

"VIP_"から始まるシェル変数を次のとおりに設定してください。

VIP_ADDRESS[n]

業務IPアドレスとして使用するVIPを設定してください。すべての系切り替え構成内で同じ設定にしてください。

VIP_RTB[n]

VIP宛の通信をするインスタンスがあるサブネットに関連づけられた，ルートテーブルの固有IDを設定してください。複数設定する場合は，1つ以上の半角スペースまたはタブで区切り，全体をダブルクォーテーションで囲んで設定してください。すべての系切り替え構成内で同じ設定にしてください。

VIP_ENI[n]

VIP宛の通信を受信する自インスタンスに付与されているENIの固有IDを設定してください。系によって値が異なります。

VIP_LABEL[n]

VIPを付与するOS上のLANインタフェースを"LANインタフェース名:xxx"の形式で設定してください。すべての系切り替え構成内で同じ設定にしてください。

VIP_RTB_TOFW[n]

クライアントからの通信がAWS Network Firewallを経由する構成の場合だけ設定してください。詳細は「4.2.2　【AWS】LANの管理」の「(4)　VIP制御による業務通信の切り替え（クライアントからの通信がAWS Network Firewallを経由する構成の場合）」，および「5.14.4　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がAWS Network Firewallを経由する構成の場合）」を参照してください。

VIP_FW[n]

クライアントからの通信がAWS Network Firewallを経由する構成の場合だけ設定してください。詳細は「4.2.2　【AWS】LANの管理」の「(4)　VIP制御による業務通信の切り替え（クライアントからの通信がAWS Network Firewallを経由する構成の場合）」，および「5.14.4　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がAWS Network Firewallを経由する構成の場合）」を参照してください。

EIP制御によって業務通信を切り替える場合

"EIP_"から始まるシェル変数を次のとおりに設定してください。

EIP_ADDRESS[n]

業務IPアドレスとして使用するEIPを設定してください。すべての系切り替え構成内で同じ設定にしてください。

EIP_ENI[n]

EIPと関連づけるENIの固有IDを設定してください。系によって値が異なります。

EIP_LABEL[n]

EIPを付与するOS上のLANインタフェースを"LANインタフェース名:xxx"の形式で設定してください。すべての系切り替え構成内で同じ設定にしてください。

DNS名制御によって業務通信を切り替える場合

レコードの変更方法によって，LANの状態設定ファイルのシェル変数の設定方法が異なります。シェル変数の設定要否を次の表に示します。

表5‒1　LANの状態設定ファイルのシェル変数の設定要否

レコードの変更方法

シェル変数の設定要否

サーバ識別名.upファイル

サーバ識別名.downファイル

レコードを更新する方法

必要

不要※

レコードを削除したあとレコードを追加する方法

必要

必要

注※

シェル変数の設定は不要ですが，サーバ識別名.downファイルは/opt/hitachi/HAmon/etc配下に作成する必要があります。

"DNS_"から始まるシェル変数のコメントアウトを外し，次のとおりに設定してください。

DNS_NAME[n]

業務通信に使用するDNS名を設定してください。すべての系切り替え構成内で同じ設定にしてください。

DNS_ZONEID[n]

業務通信に使用するDNS名を管理対象に含む，ホストゾーンのIDを設定してください。すべての系切り替え構成内で同じ設定にしてください。

なお，ホストゾーンIDの確認方法は次のとおりです。

1. Amazon Route 53コンソール上で，「ホストゾーン」をクリックする。

2. ホストゾーンの一覧の中から，業務通信に使用するDNS名を管理対象に含むホストゾーンを選択する。

3. ホストゾーンの詳細情報から，ホストゾーンIDを確認する。

DNS_TYPE[n]

DNSレコードタイプ（AレコードタイプまたはCNAMEレコードタイプ）を設定してください。Aレコードタイプは，名前解決の結果であるIPv4アドレスを記録します。CNAMEレコードタイプは，名前解決を実行する別のDNS名を記録します。すべての系切り替え構成内で同じ設定にしてください。

DNS_VALUE[n]

DNSレコードタイプがAレコードタイプの場合はIPv4アドレス，CNAMEレコードタイプの場合はDNS名を設定してください。設定する値は系ごとに異なります。

DNS_TTL[n]

リゾルバがレコードをキャッシュしておく時間（秒）を設定してください。

DNS_TTLで設定された時間内は，キャッシュ内の値を使用して業務通信します。

DNS_TTLの値が大きすぎると，HAモニタが実行サーバを系切り替えしても，切り替え元の系で業務通信するおそれがあります。そのため，次の手順でDNS_TTLを決めてください。

1. DNS名制御を使用した計画系切り替えを実施し，系切り替え時間を計測※する。

2. 計測した系切り替え時間より小さい値をDNS_TTLに設定する。

注※　系切り替え元でメッセージKAMN290-Iを出力してから，系切り替え先でメッセージKAMN311-Iを出力するまでの時間を計測します。

5.14.3　【AWS】LANの状態設定ファイルの設定（複数のリージョン間または複数のVPC間で系切り替えをする構成の場合）

HAモニタでは，LANはサーバ単位に接続，切り離しをします。そのため，LANの状態設定ファイルを作成して設定する必要があります。この項では，複数のリージョン間または複数のVPC間で系切り替えをする構成での，LANの状態設定ファイルの設定方法について説明します。

LANの状態設定ファイルの種類を，次に示します。

サーバ識別名.upファイル

LANを接続する場合に使用します。業務通信の切り替えに関する情報を設定します。

サンプルファイルの名称は，server_aws_vpc.upです。サーバごとに，サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーします。server_aws_vpc.upをサーバ識別名.upにリネームして使用してください。

サーバ識別名.downファイル

LANの切り離しをする場合に使用します。業務通信の切り替えに関する情報を設定します。

サンプルファイルの名称は，server_aws_vpc.downです。サーバごとに，サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーします。server_aws_vpc.downをサーバ識別名.downにリネームして使用してください。

vip_tgw_defファイル

業務通信の切り替えに必要な情報として，次の情報を設定します。

複数のVPC間で系切り替えをする構成での，トランジットゲートウェイおよびルートテーブルに関する情報

すべての系のホストに関する情報

サンプルファイルの名称は，vip_tgw_defです。サンプルファイルは，サーバ識別名.upファイル，およびサーバ識別名.downファイルと同じフォルダにあります。サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーして，編集して使用してください。

なお，ファイル名はリネームしないでください。また，この定義ファイルはすべての系で同じ設定内容にしてください。

server_aws_vpc.up，およびserver_aws_vpc.downのファイルの内容を次に示します。

#!/bin/bash
set -x

###############################################################################
# HOSTNAME=hostA
# VIP[0]=bb.cc.dd.ee
# LABEL[0]=lo:0

# VIP[1]=ff.gg.hh.ii
# LABEL[1]=lo:0

# DNS_ZONEID[0]=ZIII
# DNS_NAME[0]=JJJ.com.
# DNS_TYPE[0]=A
# DNS_VALUE[0]=qq.rr.ss.tt
# DNS_TTL[0]=uu

# DNS_ZONEID[1]=ZKKK
# DNS_NAME[1]=LLL.com.
# DNS_TYPE[1]=CNAME
# DNS_VALUE[1]=MMM.com.
# DNS_TTL[1]=vv

###############################################################################
：(以下を編集しないこと)

vip_tgw_defのファイルの内容を次に示します。

# host information
host
{
host_name=hostA
host_region=ap-northeast-1
host_vpc=vpc-AAA
host_vip[0]=aa.bb.cc.dd
host_eni[0]=eni-AAA000
host_tgw_attachment[0]=tgw-attach-AAA
host_vip[1]=ee.ff.gg.hh
host_eni[1]=eni-AAA111
host_tgw_attachment[1]=tgw-attach-AAA
}
host
{
host_name=hostB
host_region=ap-southeast-1
host_vpc=vpc-BBB
host_vip[0]=aa.bb.cc.dd
host_eni[0]=eni-BBB000
host_tgw_attachment[0]=tgw-attach-BBB
host_vip[1]=ee.ff.gg.hh
host_eni[1]=eni-BBB111
host_tgw_attachment[1]=tgw-attach-BBB
}

# route table information
rtb
{
rtb_id=rtb-AAA
rtb_region=ap-northeast-1
rtb_vpc=vpc-AAA
rtb_vip[0]=aa.bb.cc.dd
rtb_tgw[0]=tgw-AAA
rtb_vip[1]=ee.ff.gg.hh
rtb_tgw[1]=tgw-AAA
}
rtb
{
rtb_id=rtb-BBB
rtb_region=ap-southeast-1
rtb_vpc=vpc-BBB
rtb_vip[0]=aa.bb.cc.dd
rtb_tgw[0]=tgw-BBB
rtb_vip[1]=ee.ff.gg.hh
rtb_tgw[1]=tgw-BBB
}

# transit gateway information
tgw
{
tgw_id=tgw-AAA
tgw_region=ap-northeast-1
tgw_vip[0]=aa.bb.cc.dd
tgw_route_table[0]=tgw-rtb-AAA
tgw_vip[1]=ee.ff.gg.hh
tgw_route_table[1]=tgw-rtb-AAA
tgw_attachment=tgw-attach-AAA
tgw_peering_attachment=tgw-attach-PPP
}
tgw
{
tgw_id=tgw-BBB
tgw_region=ap-southeast-1
tgw_vip[0]=aa.bb.cc.dd
tgw_route_table[0]=tgw-rtb-BBB
tgw_vip[1]=ee.ff.gg.hh
tgw_route_table[1]=tgw-rtb-AAA
tgw_attachment=tgw-attach-BBB
tgw_peering_attachment=tgw-attach-PPP
}

次の通信制御の方式で業務通信を切り替える場合の，LANの状態設定ファイルの設定方法について説明します。

VIP制御

DNS制御

(1)　VIP制御の場合

VIP制御で複数のリージョン間または複数のVPC間で系切り替えをする場合の，LANの状態設定ファイルの設定方法について説明します。

(a)　LANの状態設定ファイルの記述形式

LANの状態設定ファイルの記述形式について説明します。

サーバ識別名.upファイル，およびサーバ識別名.downファイルの記述形式

サーバ識別名.upファイル，およびサーバ識別名.downファイルの記述形式を次に示します。

#!/bin/bash
set -x

###############################################################################
# HOSTNAME=hosta
# VIP[0]=bb.cc.dd.ee
# LABEL[0]=lo:0

# VIP[1]=ff.gg.hh.ii
# LABEL[1]=lo:0
(以下略)

次に，サーバ識別名.upファイル，およびサーバ識別名.downファイルで設定が必要なシェル変数について説明します。

サンプルファイルからコピーした状態では，シェル変数部分はコメント行となっています。コメント行を表す先頭の"#"を削除してから，設定してください。例えば，VIPが1つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

重要

シェル変数を記述する際は，次の点に注意してください。

シェル変数を「シェル変数=値」の形式で，1行につき1つずつ記述する。

シェル変数および"="の前後に空白を記述しない。

先頭が"#"の場合は，コメント行になる。

表5‒2　サーバ識別名.upファイル，およびサーバ識別名.downファイルで設定が必要なシェル変数

パラメタ名

説明

HOSTNAME

自系のホスト名を指定します。

HAモニタの環境設定のnameオペランドに指定する名称と同じにしてください。系によって名称が異なります。

VIP[n]

業務IPアドレスとして使用するVIPを指定します。

すべての系切り替え構成内で，同じ指定にしてください。

"VIP[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

LABEL[n]

VIPを付与するOS上のLANインタフェースを"LANインタフェース名:xxx"の形式で指定します。

すべての系切り替え構成内で同じ指定にしてください。

VIP[n]ごとに関連づけるOS上のLANインタフェースを，"LABEL[n]"と記述します。"VIP[n]"の"[n]"と"LABEL[n]"の"[n]"は，同じ添え字にしてください。

VIPおよびLABELの設定例を次に示します。

（例）VIP（10.10.10.10，10.10.10.20）をLABEL（lo:0）に設定する場合

VIP[0]=10.10.10.10
LABEL[0]=lo:0
VIP[1]=10.10.10.20
LABEL[1]=lo:0

（例）VIP（10.10.10.10）をLABEL（lo:0）に，VIP（10.10.10.20）をLABEL（lo:1）に設定する場合

VIP[0]=10.10.10.10
LABEL[0]=lo:0
VIP[1]=10.10.10.20
LABEL[1]=lo:1

vip_tgw_defファイルの記述形式

次に，vip_tgw_defファイルの記述形式について説明します。

vip_tgw_defファイルは，次の3つの要素で構成されています。

tgw

系切り替え構成内のすべてのトランジットゲートウェイに関する情報を設定します。

rtb

系切り替え構成内のすべてのルートテーブルを関する情報を設定します。

host

系切り替え構成内のすべてのホストに関する情報を設定します。

次に，系切り替え構成例とそれに対応するvip_tgw_defファイルの記述形式の例を示します。

図5‒5　系切り替え構成例（複数のリージョン間で系切り替えをする構成の例）

上記の系切り替え構成例に対応する，vip_tgw_defファイルの記述形式は次のとおりです。記述形式中の"(n)"は，図中の"(n)"と対応しています。

tgwの記述形式

## トランジットゲートウェイ情報 ##
tgw
{
tgw_id=tgw-R1　　…（7）
tgw_region=ap-northeast-1　　…（1）
tgw_vip[0]=10.10.10.10　　…（A）
tgw_route_table[0]=tgw-rtb-R1　　…（5）
tgw_attachment=tgw-attach-VPC1　　…（4）
tgw_peering_attachment=tgw-attach-P　　…（10）
}

tgw
{
tgw_id=tgw-R2　　…（17）
tgw_region=ap-southeast-1　　…（11）
tgw_vip[0]=10.10.10.10　　…（A）
tgw_route_table[0]=tgw-rtb-R2　　…（15）
tgw_attachment=tgw-attach-VPC2　　…（14）
tgw_peering_attachment=tgw-attach-P　　…（10）
}

"tgw"を先頭に記載します。その下に，"{}"を追加し，"{}"内にトランジットゲートウェイの各パラメタを記述します。各パラメタについては，「表5‒3　tgwに設定するパラメタ」を参照してください。トランジットゲートウェイの数だけ，"tgw"およびトランジットゲートウェイの各パラメタの記述を追加してください。

rtbの記述形式

## ルートテーブル情報 ##
rtb
{
rtb_id=rtb-VPC1　　…（6）
rtb_region=ap-northeast-1　　…（1）
rtb_vpc=VPC1　　…（2）
rtb_vip[0]=10.10.10.10　　…（A）
rtb_tgw[0]=tgw-R1　　…（7）
}

rtb
{
rtb_id=rtb-VPC2　　…（16）
rtb_region=ap-southeast-1　　…（11）
rtb_vpc=VPC2　　…（12）
rtb_vip[0]=10.10.10.10　　…（A）
rtb_tgw[0]=tgw-R2　　…（17）
}

"rtb"を先頭に記載します。その下に，"{}"を追加し，"{}"内にルートテーブルの各パラメタを記述します。各パラメタについては，「表5‒4　rtbに設定するパラメタ」を参照してください。ルートテーブルの数だけ，"rtb"およびルートテーブルの各パラメタの記述を追加してください。

hostの記述形式

## ホスト情報 ##
host
{
host_name=hosta　　…（8）
host_region=ap-northeast-1　　…（1）
host_vpc=VPC1　　…（2）
host_vip[0]=10.10.10.10　　…（A）
host_eni[0]=eni-XXXX　　…（3）
host_tgw_attachment[0]=tgw-attach-VPC1　　…（4）
}

host
{
host_name=hostb　　…（18）
host_region=ap-southeast-1　　…（11）
host_vpc=VPC2　　…（12）
host_vip[0]=10.10.10.10　　…（A）
host_eni[0]=eni-yyyy　　…（13）
host_tgw_attachment[0]=tgw-attach-VPC2　　…（14）
}

"host"を先頭に記載します。その下に，"{}"を追加し，"{}"内にホストの各パラメタを記述します。各パラメタについては，「表5‒5　hostに設定するパラメタ」を参照してください。系切り替え構成内のホストの数だけ，"host"およびホストの各パラメタの記述を追加してください。

次に，vip_tgw_defファイルに設定するパラメタについて説明します。

すべてのパラメタをvip_tgw_defファイルに設定します。設定後，moncheckコマンドを実行し，フォーマットのエラーがないかを確認してください。フォーマットのエラーがある場合は，moncheckコマンドがメッセージKAMN773-Eを出力します。

重要

パラメタを記述する際は，次の点に注意してください。

パラメタを「パラメタ名=値」の形式で，1行につき1つずつ記述する。

パラメタおよび"="の前後に空白を記述しない。

先頭が"#"の場合は，コメント行になる。

tgwに記載するパラメタ名を次の表に示します。

表5‒3　tgwに設定するパラメタ

パラメタ名

説明

tgw_id

トランジットゲートウェイIDを指定します。

tgw_region

トランジットゲートウェイがあるリージョンのIDを指定します。

tgw_vip

トランジットゲートウェイで転送するVIPを指定します。

"tgw_vip[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

tgw_route_table

トランジットゲートウェイルートテーブルIDを指定します。

"tgw_route_table[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

tgw_vip[n]に指定したVIPの宛先をエントリする"tgw_route_table[n]"を記述します。"tgw_vip[n]"の"[n]"と"tgw_route_table[n]"の"[n]"は，同じ添え字にしてください。

tgw_attachment

VPC用のトランジットゲートウェイアタッチメントを指定します。

複数個指定する場合は，1つ以上の半角スペースまたはタブで区切り，全体をダブルクォーテーションで囲んで指定してください。

tgw_peering_attachment

複数のリージョン間で系切り替えをする構成の場合，接続先リージョンのトランジットゲートウェイとのピアリング用の，トランジットゲートウェイアタッチメントを指定します。

上記の構成以外の場合は，次のどちらかを実施してください。

パラメタを削除する

パラメタの先頭に"#"を追加し，コメント行にする

tgw_vipおよびtgw_route_tableの設定例を次に示します。

（例）VIP（10.10.10.10，10.10.10.20）をトランジットゲートウェイルートテーブル（tgw-rtb-R1）に追加する設定の場合

tgw_vip[0]=10.10.10.10
tgw_route_table[0]=tgw-rtb-R1
tgw_vip[1]=10.10.10.20
tgw_route_table[1]=tgw-rtb-R1

（例）VIP（10.10.10.10）をトランジットゲートウェイルートテーブル（tgw-rtb-R1）に，VIP（10.10.10.20）をトランジットゲートウェイルートテーブル（tgw-rtb-R2）に追加する設定の場合

tgw_vip[0]=10.10.10.10
tgw_route_table[0]=tgw-rtb-R1
tgw_vip[1]=10.10.10.20
tgw_route_table[1]=tgw-rtb-R2

（例）VIP（10.10.10.10，10.10.10.20）をトランジットゲートウェイルートテーブル（tgw-rtb-R1）に，VIP（10.10.10.30）をトランジットゲートウェイルートテーブル（tgw-rtb-R2）に追加する設定の場合

tgw_vip[0]=10.10.10.10
tgw_route_table[0]=tgw-rtb-R1
tgw_vip[1]=10.10.10.20
tgw_route_table[1]=tgw-rtb-R1
tgw_vip[2]=10.10.10.30
tgw_route_table[2]=tgw-rtb-R2

tgw_attachmentの設定例を次に示します。

（例）VPC用のトランジットゲートウェイアタッチメントに，tgw-attach-VPC1，tgw-attach-VPC2を設定する場合

tgw_attachment="tgw-attach-VPC1△tgw-attach-VPC2"

（凡例）△：1つ以上の半角スペースまたはタブ

rtbに記載するパラメタ名を次の表に示します。

表5‒4　rtbに設定するパラメタ

パラメタ名

説明

rtb_id

ルートテーブルのIDを指定します。

rtb_vpc

ルートテーブルがあるVPCのIDを指定します。

rtb_region

ルートテーブルがあるリージョンのIDを指定します。

rtb_vip

ルートテーブルで転送するVIPを指定します。

"rtb_vip[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

rtb_tgw

ルートテーブルがあるリージョンの，トランジットゲートウェイIDを指定します。

"rtb_tgw[n]"の形式で記述します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

rtb_vip[n]に指定したVIPの宛先をエントリする"rtb_tgw[n]"を指定します。"rtb_vip[n]"の"[n]"と"rtb_tgw[n]"の"[n]"は，同じ添え字にしてください。

rtb_vipおよびrtb_tgwの設定例を次に示します。

（例）ルートテーブルにVIP（10.10.10.10，10.10.10.20）の宛先をtgw-R1に設定する場合

rtb_vip[0]=10.10.10.10
rtb_tgw[0]=tgw-R1
rtb_vip[1]=10.10.10.20
rtb_tgw[1]=tgw-R1

hostに記載するパラメタ名を次の表に示します。

表5‒5　hostに設定するパラメタ

パラメタ名

説明

host_name

ホスト名称を指定します。

指定するホスト名称は，各系のHAモニタの環境設定のnameオペランドに指定する名称と同じ名称にしてください。

host_region

host_nameに指定したホストがあるリージョンを指定します。

host_vpc

host_nameに指定したホストがあるVPCを指定します。

host_vip

host_nameに指定したホストで稼働させるすべてのサーバが，業務通信で使用するすべてのVIPを指定します。

"host_vip[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

host_eni

host_nameに指定したホストで，VIP宛の業務通信を受信するENIのENI IDを指定します。

"host_eni[n]"の形式で記述します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

host_vip[n]に指定したVIPの宛先として，"host_eni[n]"を指定します。"host_vip[n]"の"[n]"と"host_eni[n]"の"[n]"は，同じ添え字にしてください。

host_tgw_attachment

host_nameに指定したホストが接続する，VPC用のトランジットゲートウェイアタッチメントを指定します。

"host_tgw_attachment[n]"の形式で記述します。[n]は添え字を表します。1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

host_vip[n]に指定したVIPの宛先として，"host_tgw_attachment[n]"を指定します。"host_vip[n]"の"[n]"と"host_tgw_attachment[n]"の"[n]"は，同じ添え字にしてください。

host_vip，host_eniおよびhost_tgw_attachmentの設定例を次に示します。

（例）VIP（10.10.10.10，10.10.10.20）の宛先をeni-xxxx，tgw-attach-VPC1に設定する場合

host_vip[0]=10.10.10.10
host_eni[0]=eni-xxxx
host_tgw_attachment[0]=tgw-attach-VPC1
host_vip[1]=10.10.10.20
host_eni[1]=eni-xxxx
host_tgw_attachment[1]=tgw-attach-VPC1

（例）VIP（10.10.10.10）の宛先をeni-xxxxおよびtgw-attach-VPC1に，VIP（10.10.10.20）の宛先をeni-yyyyおよびtgw-attach-VPC2に設定する場合

host_vip[0]=10.10.10.10
host_eni[0]=eni-xxxx
host_tgw_attachment[0]=tgw-attach-VPC1
host_vip[1]=10.10.10.20
host_eni[1]=eni-yyyy
host_tgw_attachment[1]=tgw-attach-VPC2

(b)　LANの状態設定ファイルの設定例

次の系切り替え構成と，それに対応するLANの状態設定ファイルの設定例について説明します。

同一のリージョン内の，複数のVPC間で系切り替えをする構成

複数のリージョン間で系切り替えをする構成

同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成

メモ

LANの状態設定ファイルの格納先は次のとおりです。

サーバ識別名.upファイルの格納先

/opt/hitachi/HAmon/etc/サーバ識別名.upファイル

サーバ識別名.downファイルの格納先

/opt/hitachi/HAmon/etc/サーバ識別名.downファイル

vip_tgw_defファイルの格納先

/opt/hitachi/HAmon/etc/vip_tgw_def

同一のリージョン内の，複数のVPC間で系切り替えをする構成の場合

図5‒6　同一のリージョン内の，複数のVPC間で系切り替えをする構成例

上記の図に対応する，LANの状態設定ファイルの設定例は次のとおりです。設定例中の"(n)"は，図中の"(n)"と対応しています。

現用系（インスタンス1）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x

#######################################################################
HOSTNAME=hosta　…（8）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（9）
#######################################################################

：(以下を編集しないこと)

予備系（インスタンス2）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x

######################################################################
HOSTNAME=hostb　…（18）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（19）
######################################################################

：(以下を編集しないこと)

vip_tgw_defファイル

## トランジットゲートウェイ情報 ##
tgw
{
tgw_id=tgw-R1　…（7）
tgw_region=ap-northeast-1　…（1）
tgw_vip[0]=10.10.10.10　…（A）
tgw_route_table[0]=tgw-rtb-R1　…（5）
tgw_attachment="tgw-attach-VPC1 tgw-attach-VPC2"　…（4）（14）
}

## ルートテーブル情報 ##
rtb
{
rtb_id=rtb-VPC1　…（6）
rtb_region=ap-northeast-1　…（1）
rtb_vpc=VPC1　…（2）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R1　…（7）
}

rtb
{
rtb_id=rtb-VPC2　…（16）
rtb_region=ap-northeast-1　…（1）
rtb_vpc=VPC2　…（12）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R1　…（7）
}

## ホスト情報 ##
host
{
host_name=hosta　…（8）
host_region=ap-northeast-1　…（1）
host_vpc=VPC1　…（2）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-xxxx　…（3）
host_tgw_attachment[0]=tgw-attach-VPC1　…（4）
}

host
{
host_name=hostb　…（18）
host_region=ap-northeast-1　…（1）
host_vpc=VPC2　…（12）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-yyyy　…（13）
host_tgw_attachment[0]=tgw-attach-VPC2　…（14）
}

複数のリージョン間で系切り替えをする構成の場合

図5‒7　複数のリージョン間で系切り替えをする構成例

上記の図に対応する，LANの状態設定ファイルの設定例は次のとおりです。設定例中の"(n)"は，図中の"(n)"と対応しています。

現用系（インスタンス1）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x
#########################################################################
HOSTNAME=hosta　…（8）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（9）
#########################################################################

：(以下を編集しないこと)

予備系（インスタンス2）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x
#######################################################################
HOSTNAME=hostb　…（18）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（19）
#######################################################################

：(以下を編集しないこと)

vip_tgw_defファイル

## トランジットゲートウェイ情報 ##
tgw
{
tgw_id=tgw-R1　…（7）
tgw_region=ap-northeast-1　…（1）
tgw_vip[0]=10.10.10.10　…（A）
tgw_route_table[0]=tgw-rtb-R1　…（5）
tgw_attachment=tgw-attach-VPC1　…（4）
tgw_peering_attachment=tgw-attach-P　…（10）
}

tgw
{
tgw_id=tgw-R2　…（17）
tgw_region=ap-southeast-1　…（11）
tgw_vip[0]=10.10.10.10　…（A）
tgw_route_table[0]=tgw-rtb-R2　…（15）
tgw_attachment=tgw-attach-VPC2　…（14）
tgw_peering_attachment=tgw-attach-P　…（10）
}

## ルートテーブル情報 ##
rtb
{
rtb_id=rtb-VPC1　…（6）
rtb_region=ap-northeast-1　…（1）
rtb_vpc=VPC1　…（2）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R1　…（7）
}

rtb
{
rtb_id=rtb-VPC2　…（16）
rtb_region=ap-southeast-1　…（11）
rtb_vpc=VPC2　…（12）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R2　…（17）
}

## ホスト情報 ##
host
{
host_name=hosta　…（8）
host_region=ap-northeast-1　…（1）
host_vpc=VPC1　…（2）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-xxxx　…（3）
host_tgw_attachment[0]=tgw-attach-VPC1　…（4）
}

host
{
host_name=hostb　…（18）
host_region=ap-southeast-1　…（11）
host_vpc=VPC2　…（12）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-yyyy　…（13）
host_tgw_attachment[0]=tgw-attach-VPC2　…（14）
}

同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成の場合

図5‒8　同一のVPC内の複数のAZ間，および複数のリージョン間で系切り替えをする構成例

上記の図に対応する，LANの状態設定ファイルの設定例は次のとおりです。設定例中の"(n)"は，図中の"(n)"と対応しています。

現用系（インスタンス1）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x
#########################################################################
HOSTNAME=hosta　…（8）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（9）
#########################################################################

：(以下を編集しないこと)

予備系（インスタンス2）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x
#######################################################################
HOSTNAME=hostb　…（20）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（22）
#######################################################################

：(以下を編集しないこと)

予備系（インスタンス3）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x
#######################################################################
HOSTNAME=hostc　…（18）
VIP[0]=10.10.10.10　…（A）
LABEL[0]=lo:0　…（19）
#######################################################################

：(以下を編集しないこと)

vip_tgw_defファイル

## トランジットゲートウェイ情報 ##
tgw
{
tgw_id=tgw-R1　…（7）
tgw_region=ap-northeast-1　…（1）
tgw_vip[0]=10.10.10.10　…（A）
tgw_route_table[0]=tgw-rtb-R1　…（5）
tgw_attachment=tgw-attach-VPC1　…（4）
tgw_peering_attachment=tgw-attach-P　…（10）
}

tgw
{
tgw_id=tgw-R2　…（17）
tgw_region=ap-southeast-1　…（11）
tgw_vip[0]=10.10.10.10　…（A）
tgw_route_table[0]=tgw-rtb-R2　…（15）
tgw_attachment=tgw-attach-VPC2　…（14）
tgw_peering_attachment=tgw-attach-P　…（10）
}

## ルートテーブル情報 ##
rtb
{
rtb_id=rtb-VPC1　…（6）
rtb_region=ap-northeast-1　…（1）
rtb_vpc=VPC1　…（2）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R1　…（7）
}

rtb
{
rtb_id=rtb-VPC2　…（16）
rtb_region=ap-southeast-1　…（11）
rtb_vpc=VPC2　…（12）
rtb_vip[0]=10.10.10.10　…（A）
rtb_tgw[0]=tgw-R2　…（17）
}

## ホスト情報 ##
host
{
host_name=hosta　…（8）
host_region=ap-northeast-1　…（1）
host_vpc=VPC1　…（2）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-XXXX　…（3）
host_tgw_attachment[0]=tgw-attach-VPC1　…（4）
}

host
{
host_name=hostb　…（20）
host_region=ap-northeast-1　…（1）
host_vpc=VPC1　…（2）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-YYYY　…（21）
host_tgw_attachment[0]=tgw-attach-VPC1　…（4）
}

host
{
host_name=hostc　…（18）
host_region=ap-southeast-1　…（11）
host_vpc=VPC2　…（12）
host_vip[0]=10.10.10.10　…（A）
host_eni[0]=eni-ZZZZ　…（13）
host_tgw_attachment[0]=tgw-attach-VPC2　…（14）
}

(2)　DNS制御の場合

DNS制御の場合，LANの状態設定ファイルは次のサンプルファイルを基に作成してください。

server_aws_vpc.up

server_aws_vpc.down

設定方法は，「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」を参照してください。

次のどちらの場合でも，設定方法は同じです。

DNS制御によって，1つのリージョン内または1つのVPC内で系切り替えをする場合

DNS制御によって，複数のリージョン間または複数のVPC間で系切り替えをする場合

ただし，説明中のサンプルファイル名は，次のとおりに読み替えてください。

「server_aws.up」を「server_aws_vpc.up」に読み替える。

「server_aws.down」を「server_aws_vpc.down」に読み替える。

5.14.4　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がAWS Network Firewallを経由する構成の場合）

クライアントからの通信がAWS Network Firewallを経由する構成の場合，LANの状態設定ファイルの設定が必要です。LANの状態設定ファイルの種類およびサンプルファイルについては，「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」と同じです。

ここでは，クライアントからの通信がAWS Network Firewallを経由する構成の場合の，LANの状態設定ファイルのシェル変数について説明します。

VIP_ADDRESS[n]

業務IPアドレスとして使用するVIPを設定してください。すべての系切り替え構成内で同じ設定にしてください。

VIP_RTB[n]

VIP宛の通信を自インスタンスのENIに転送するルートテーブルの固有IDを設定してください。複数設定する場合は，1つ以上の半角スペースまたはタブで区切り，全体をダブルクォーテーションで囲んで設定してください。

VIP_ENI[n]

VIP宛の通信を受信する自インスタンスに付与されているENIの固有IDを設定してください。系によって値が異なります。

VIP_LABEL[n]

VIPを付与するOS上のLANインタフェースを"LANインタフェース名:xxx"の形式で設定してください。すべての系切り替え構成内で同じ設定にしてください。

VIP_RTB_TOFW[n]

VIP宛の通信を自インスタンスのAZ側のファイアウォールエンドポイントに転送するルートテーブルの固有IDを設定してください。設定したいルートテーブルが複数ある場合は，1つ以上の半角スペースまたはタブで区切り，全体をダブルクォーテーションで囲んで設定してください。

VIP_FW[n]

VIP宛の通信を自インスタンスに転送するファイアウォールのファイアウォールエンドポイントIDを設定してください。系によって値が異なります。

5.14.5　【AWS】LANの状態設定ファイルの設定（クライアントからの通信がNLBを経由する構成の場合）

設定方法については，1つのリージョン内または1つのVPC内で系切り替えをする構成の場合と同じです。詳細は「5.14.2　【AWS】LANの状態設定ファイルの設定（1つのリージョン内または1つのVPC内で系切り替えをする構成の場合）」を参照してください。

5.14.6　【Azure】LANの状態設定ファイルの設定

HAモニタでは，LANはサーバ単位に接続，切り離しをします。そのため，LANの状態設定ファイルを作成して設定する必要があります。

LANの状態設定ファイルの種類を，次に示します。

サーバ識別名.upファイル

LANを接続する場合に使用します。業務通信の切り替えに関する情報を設定します。

サーバ識別名.downファイル

LANの切り離しをする場合に使用します。業務通信の切り替えに関する情報を設定します。

これらのファイルは，サーバごとにHAモニタの環境設定用ディレクトリの下に作成します。ファイル名のサーバ識別名の部分は，サーバ対応の環境設定のaliasオペランドで指定した値にしてください。

LANの状態設定ファイルには，OSのipコマンドの引数として，LANアダプタに追加・削除するエイリアスIPアドレスを指定します。OSのコマンドについては，OSのマニュアルを参照してください。

Azure用シェルスクリプト群を展開すると，Azure用のLANの状態設定ファイルのサンプルファイルが，/opt/hitachi/HAmon/lib配下に配置されます。Azure用シェルスクリプト群の展開については，「5.9　【Azure】Azure用のシェルスクリプト群の展開」を参照してください。サンプルファイルの名称は，server_azure.upおよびserver_azure.downです。

server_azure.upおよびserver_azure.downのファイル内容を次に示します。

#!/bin/bash
set -x

###############################################################################
# LB_IPADDR[0]=aa.aa.aa.aa
# LB_PORT[0]=bbbb

# LB_IPADDR[1]=cc.cc.cc.cc
# LB_PORT[1]=dddd

# DNS_PUBLICZONE[0]=eeee.com
# DNS_PRIVATEZONE[0]=ffff.com
# DNS_RECORDSET[0]=gggg
# DNS_RESOURCEGROUP[0]=hhhh
# DNS_TYPE[0]=A
# DNS_VALUE[0]=ii.ii.ii.ii
# DNS_TTL[0]=jj

# DNS_PUBLICZONE[1]=kkkk.com
# DNS_PRIVATEZONE[1]=llll.com
# DNS_RECORDSET[1]=mmmm
# DNS_RESOURCEGROUP[1]=nnnn
# DNS_TYPE[1]=CNAME
# DNS_VALUE[1]=oooo.com.
# DNS_TTL[1]=pp

###############################################################################
function main() {
：

サーバごとに，サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーして，server_azure.upをサーバ識別名.upに，server_azure.downをサーバ識別名.downにリネームしてください。

サーバ識別名.up/downで設定が必要なシェル変数について説明します。

メモ

ここで説明する[n]は配列の添え字です。業務通信に使用する仮想マシンのエイリアスIPアドレス，または業務通信に使用するDNS名が1つの場合，[n]は0です。複数ある場合，1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

サンプルファイルからコピーした状態では，シェル変数部分はコメント行となっています。コメント行を表す先頭の"#"を削除してから，設定してください。例えば，業務通信に使用する仮想マシンのエイリアスIPアドレスが1つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

LB_IPADDR[0]

LB_PORT[0]

2つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

LB_IPADDR[0]

LB_PORT[0]

LB_IPADDR[1]

LB_PORT[1]

3つ目以降については，シェル変数をコピーするなどの方法で，設定してください。

Azure ロードバランサー制御によって業務通信を切り替える場合

"LB_"から始まるシェル変数を次のとおりに設定してください。

LB_IPADDR[n]

仮想マシンに付与または削除するエイリアスIPアドレスを設定してください。エイリアスIPアドレスは，業務通信に使用するIPアドレスで，Azure ロードバランサーのフロントエンドに設定したIPアドレスと同じアドレスを指定します。すべての系切り替え構成内で同じ設定にしてください。

LB_PORT[n]

Azure ロードバランサーからの正常性確認を待ち受けるポート番号を設定してください。すべての系切り替え構成内で同じ設定にしてください。

LB_IPADDRおよびLB_PORTの値は，異なる添え字間で重複しないように設定してください。

LB_IPADDRおよびLB_PORTの値は，異なるサーバ間（異なるサーバ識別名.up間および異なるサーバ識別名.down間）で重複しないように設定してください。

DNS名制御によって業務通信を切り替える場合

レコードの変更方法によって，LANの状態設定ファイルのシェル変数の設定方法が異なります。シェル変数の設定要否を次の表に示します。

表5‒6　LANの状態設定ファイルのシェル変数の設定要否

レコードの変更方法

シェル変数の設定要否

サーバ識別名.upファイル

サーバ識別名.downファイル

レコードを更新する方法

必要

不要※

レコードを削除したあとレコードを追加する方法

必要

必要

注※

シェル変数の設定は不要ですが，サーバ識別名.downファイルは/opt/hitachi/HAmon/etc配下に作成する必要があります。

"DNS_"から始まるシェル変数のコメントアウトを外し，次のとおりに設定してください。

DNS_PUBLICZONE[n]

DNSゾーンがパブリックゾーンの場合に，業務通信に使用するDNS名を管理対象に含む，DNSゾーン名を設定してください。すべての系切り替え構成内で同じ設定にしてください。

DNS_PRIVATEZONE[n]

DNSゾーンがプライベートゾーンの場合に，業務通信に使用するDNS名を管理対象に含む，DNSゾーン名を設定してください。すべての系切り替え構成内で同じ設定にしてください。

DNS_RECORDSET[n]

レコードのレコードセット名を設定してください。すべての系切り替え構成内で同じ設定にしてください。

メモ

DNSゾーン名とレコードセット名によって，業務通信に使用するDNS名が決定します。例えば，DNS_PUBLICZONE[0]=hitachi.com，DNS_RECORDSET[0]=sampleの場合，業務通信に使用するDNS名はsample.hitachi.comとなります。

DNS_RESOURCEGROUP[n]

DNSゾーンを含むリソースグループ名を設定してください。すべての系切り替え構成内で同じ設定にしてください。

DNS_TYPE[n]

DNSレコードタイプ（AレコードタイプまたはCNAMEレコードタイプ）を設定してください。Aレコードタイプは，名前解決の結果であるIPv4アドレスを記録します。CNAMEレコードタイプは，名前解決を実行する別のDNS名を記録します。すべての系切り替え構成内で同じ設定にしてください。

DNS_VALUE[n]

DNSレコードタイプがAレコードタイプの場合はIPv4アドレス，CNAMEレコードタイプの場合はDNS名を設定してください。設定する値は系ごとに異なります。

DNS_TTL[n]

レコードがクライアントによってキャッシュされる時間（秒）を設定してください。

DNS_TTLで設定された時間内は，キャッシュ内の値を使用して業務通信します。

DNS_TTLの値が大きすぎると，HAモニタが実行サーバを系切り替えしても，切り替え元の系で業務通信するおそれがあります。そのため，次の手順でDNS_TTLを決めてください。

1. DNS名制御を使用した計画系切り替えを実施し，系切り替え時間を計測※する。

2. 計測した系切り替え時間より小さい値をDNS_TTLに設定する。

注※　系切り替え元でメッセージKAMN290-Iを出力してから，系切り替え先でメッセージKAMN311-Iを出力するまでの時間を計測します。

5.14.7　【OCI】LANの状態設定ファイルの設定

HAモニタでは，LANはサーバ単位に接続，切り離しをします。そのため，LANの状態設定ファイルを作成して設定する必要があります。

LANの状態設定ファイルの種類を，次に示します。

サーバ識別名.upファイル

LANを接続する場合に使用します。業務通信の切り替えに関する情報を設定します。

サーバ識別名.downファイル

LANの切り離しをする場合に使用します。業務通信の切り替えに関する情報を設定します。

これらのファイルは，サーバごとにHAモニタの環境設定用ディレクトリの下に作成します。ファイル名のサーバ識別名の部分は，サーバ対応の環境設定のaliasオペランドで指定した値にしてください。

LANの状態設定ファイルには，OSのipコマンドの引数として，LANアダプタに追加・削除するエイリアスIPアドレスを指定します。OSのコマンドについては，OSのマニュアルを参照してください。

OCI用シェルスクリプト群を展開すると，OCI用のLANの状態設定ファイルのサンプルファイルが，/opt/hitachi/HAmon/lib配下に配置されます。OCI用シェルスクリプト群の展開については，「5.10　【OCI】OCI用のシェルスクリプト群の展開」を参照してください。サンプルファイルの名称は，server_oci.upおよびserver_oci.downです。

server_oci.upおよびserver_oci.downのファイル内容を次に示します。

#!/bin/bash
set -x

###############################################################################
# PIP_ADDRESS[0]=aa.aa.aa.aa
# PIP_PREFIX[0]=bb
# PIP_VNIC[0]=cccc
# PIP_LABEL[0]=eth0:0

# PIP_ADDRESS[1]=dd.dd.dd.dd
# PIP_PREFIX[1]=ee
# PIP_VNIC[1]=ffff
# PIP_LABEL[1]=eth1:0

###############################################################################
function main() {
：

サーバごとに，サンプルファイルを/opt/hitachi/HAmon/etc配下にコピーして，server_oci.upをサーバ識別名.upに，server_oci.downをサーバ識別名.downにリネームしてください。

サーバ識別名.up/downで設定が必要なシェル変数について説明します。

メモ

ここで説明する[n]は配列の添え字です。業務IPアドレスとして使用するプライベートIPアドレスが1つの場合，[n]は0です。複数ある場合，1つ目の[n]は0，2つ目の[n]は1，のように，添え字が0から順に1ずつ増加するように設定してください。

サンプルファイルからコピーした状態では，シェル変数部分はコメント行となっています。コメント行を表す先頭の"#"を削除してから，設定してください。例えば，業務IPアドレスとして使用するプライベートIPアドレスが1つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

PIP_ADDRESS[0]

PIP_PREFIX[0]

PIP_VNIC[0]

PIP_LABEL[0]

2つの場合は，次のシェル変数について，コメント"#"を削除し，シェル変数を設定します。

PIP_ADDRESS[0]

PIP_PREFIX[0]

PIP_VNIC[0]

PIP_LABEL[0]

PIP_ADDRESS[1]

PIP_PREFIX[1]

PIP_VNIC[1]

PIP_LABEL[1]

3つ目以降については，シェル変数をコピーするなどの方法で，設定してください。

"PIP_"から始まるシェル変数を次のとおりに設定してください。

PIP_ADDRESS[n]

業務IPアドレスとして使用するプライベートIPアドレスを設定してください。すべての系切り替え構成内で同じ設定にしてください。

PIP_PREFIX[n]

業務IPアドレスのプリフィックスを設定してください。すべての系切り替え構成内で同じ設定にしてください。

PIP_VNIC[n]

プライベートIPアドレスを割り当てるVNICのOCIDを設定してください。設定ミスを防ぐため，コピー＆ペーストを使用して設定してください。系によって値が異なります。

PIP_LABEL[n]

プライベートIPアドレスを付与するOS上のLANインタフェースを"LANインタフェース名:xxx"の形式で設定してください。すべての系切り替え構成内で同じ設定にしてください。

5.15　リソースの監視のための設定

リソースの監視のための設定については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「リソースの監視のための設定」の説明を参照してください。この節では，リソースの監視のための設定について，パブリッククラウド環境下で差異がある事項だけを記載します。

リソースの監視のための設定について説明します。リソースには，LANおよびディスクがあります。

5.15.1　LANの監視に必要なファイルの設定

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「LANの監視に必要なファイルの設定」を参照してください。ただし，パブリッククラウド環境下では次の点が異なります。

LAN監視定義ファイル（LANインタフェース名称.conf）に指定する確認用パケット送出先としては，次のすべての条件を満たす送出先のIPアドレスを指定してください。

・HAモニタを起動する前に，送出先が起動していること。送出先よりHAモニタを先に起動すると，LAN障害を検知してしまいます。

・送出先は，HAモニタの稼働する系ではないこと。ペアとなるHAモニタがある系のIPアドレスは指定しないでください。

HAモニタの環境設定のlancheck_modeオペランドをrouteに設定してください。

必ずHAモニタ01-70以降で提供するLAN監視スクリプト（lanpatrol.sh）を使用してください。

LAN監視スクリプトには，次の条件を満たす送信元IPアドレスを指定してください。

・監視対象とするLANインタフェースに付与されたステーショナリIPアドレス。エイリアスIPアドレスを指定すると，LAN障害を検知してしまうおそれがあります。

LANの監視のスクリプトの修正例を次に示します。太字の個所を追記してください。

#!/bin/sh
#******************************************************************************
#*                                                                            *
#*    Linux(x86) HA Monitor                                                   *
#*    This is a sample of the LAN patrol command.                             *
#*                                                                            *
#*    [SYNOPSIS]                                                              *
#*        lanpatrol.sh interface [-r]                                         *
#*    [OPTIONS]                                                               *
#*        interface                                                           *
#*            The name of the LAN interface.                                  *
#*        -r                                                                  *
#*            Route monitoring method                                         *
#*    [DIAGNOSTICS]                                                           *
#*        0 : normal                                                          *
#*        1 : abnormal                                                        *
#*        2 : error                                                           *
#*                                                                            *
#*    All Rights Reserved. Copyright (C) 2011, 2019, Hitachi, Ltd.            *
#*                                                                            *
#******************************************************************************
#set -x

# retry interval(seconds) for receive packet number method. or
# return wait(seconds) of ping command for route monitoring method.
WAIT_TIME=3

# retry counter
RETRY=3

# check interface and source IP address
PATROL_IF[0]=eth0
SOURCE_IP[0]=192.168.0.1
PATROL_IF[1]=eth1
SOURCE_IP[1]=192.168.1.2

# environment variables
PATH=/usr/bin:/usr/sbin:/bin
export PATH

：
：
：

#******************************************************************************
#*    [NAME]                                                                  *
#*        exec_route_ping - execute ping command and wait return              *
#*    [SYNOPSIS]                                                              *
#*        exec_route_ping interface                                           *
#*    [OPTIONS]                                                               *
#*        interface                                                           *
#*            The name of the LAN interface.                                  *
#*    [RETURN VALUE]                                                          *
#*        none                                                                *
#******************************************************************************
exec_route_ping() {
    # specific source IP address
    SRCIP=""
    index=0
    while [ ${PATROL_IF[$index]} ]
    do
        if [ ${PATROL_IF[$index]} = "$1" ]; then
            SRCIP="-I ${SOURCE_IP[$index]}"
            break
        fi
        index=`expr $index + 1`
    done
    # send some ECHO_REQUESTs and wait returns
    unset ping_pid
    unset dest_ip
    index=0
    while read P_IPADDR
    do
        echo "`date` exec_route_ping read() DEST_IPADDR=`echo ${P_IPADDR}` WAIT=`echo ${WAIT_TIME}` SRC=`echo ¥'${SRCIP:-unspecified}¥'`"
        (time ping -c 1 -w ${WAIT_TIME} ${SRCIP} ${P_IPADDR}) &
        ping_pid[$index]=$!
        dest_ip[$index]=${P_IPADDR}
        index=`expr $index + 1`
    done < ./etc/$1.conf
    echo "`date` exec_route_ping wait() start"
    unset ping_rtcd
    index=0
    while [ ${ping_pid[$index]} ]
    do
        wait ${ping_pid[$index]}
        ping_rtcd[$index]=$?
        echo "`date` DEST_IPADDR=${dest_ip[$index]}, RESULT=${ping_rtcd[$index]}"
        index=`expr $index + 1`
    done
    echo "`date` exec_route_ping wait() end"
    return
}

：

・PATROL_IF[x]に監視対象のLANインタフェース名を指定します。

・SOURCE_IP[x]に送信元IPアドレスを指定します。

それぞれ[x]は配列の添え字です。監視対象のインタフェース名と送信元IPアドレスの組み合わせで添え字をそろえて指定してください。組み合わせが一つの場合でも添え字[0]を指定してください。

送信元IPアドレスには，ステーショナリIPアドレスが指定できます。エイリアスIPアドレスは指定できません。IPラベルも指定できますが，ホスト名の解決に時間が掛かることがあります。このため，IPアドレスを記述することを推奨します。

送信元にIPラベルを指定する場合であっても，変数名は"SOURCE_IP"とし，変更しないでください。

5.16　【AWS】エージェントヘルスチェック機能の設定

エージェントヘルスチェック機能を使用するには，次の設定が必要です。

表5‒7　エージェントヘルスチェック機能を使用するための設定

設定対象

設定項目

参照先

HAモニタエージェント

monsetupコマンド

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

HAモニタの環境設定

lan_agentオペランド

lanport_agentオペランド

HAモニタの環境設定

「(b)　lan_agent」

「(c)　lanport_agent」

接続構成設定ファイル

「5.12　監視パスの設定」

HAモニタ

HAモニタの環境設定

lan_agentオペランド

lanport_agentオペランド

agt_split_timeオペランド

HAモニタの環境設定

「(b)　lan_agent」

「(c)　lanport_agent」

「(c)　agt_split_time」

サーバ対応の環境設定

hab_gidオペランド

「7.3.2　パブリッククラウド環境で注意が必要なサーバ対応の環境設定のオペランド」

5.17　【AWS】AWS CLIの実行可否チェックの設定

ここでは，AWS CLIの実行可否チェックの設定について説明します。

コントロールプレーンに対するAWS CLIの実行可否チェックをする場合に，次の説明に従って，コントロールプレーン確認設定ファイルを作成，配置してください。

コントロールプレーン確認設定ファイル

ファイル名

ctrlplane_check.env

形式

# ENI used for ControlPlane check
#ENI_ID="eni-aaaa"

# Route table used for ControlPlane check
#RTB_ID="rtb-bbbb"
#RTB_IP_ADDRESS="10.10.10.10"
#RTB_TARGET_ENI_ID="eni-cccc"

ENI_ID：ENIのデタッチ/アタッチの確認に使用するENIのIDを指定してください。

RTB_ID：ルートテーブル書き換え確認に使用するroute tableのIDを指定してください。

RTB_IP_ADDRESS：ルートテーブル書き換え確認で使用するVIPを指定してください。

RTB_TARGET_ENI_ID：ルートテーブル書き換え確認で使用するENIのIDを指定してください。

ENI，ルートテーブル，VIPの詳細は「2.2.2　系障害の検出」の「(2)　【AWS】コントロールプレーンのチェック」を参照してください。

定義ルール

・先頭が#の行はコメント行とする

・ENI_ID，RTB_ID，RTB_IP_ADDRESS，RTB_TARGET_ENI_IDはそれぞれ1つずつ指定する（複数指定しない）

・空白行は記載可能とする

配置場所

/opt/hitachi/HAmon/etc配下

6　システムの運用

この章では，構築したシステムの運用について説明します。起動・停止方法，障害が発生した場合のオペレータの操作，障害発生を防ぐための運用，および運用を自動化する方法やシステムを変更する方法などについて説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「システムの運用」とあわせてお読みください。

6.1　起動・停止

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「起動・停止」を参照してください。ただし，AWS環境下およびAzure環境下では次の点が異なります。

HAモニタを起動する前に，レプリケーションソフトを起動する。

HAモニタを停止したあとに，レプリケーションソフトを停止する。

また，AWS環境下でHAモニタエージェントを使用する場合は，次の点が異なります。

HAモニタおよびサーバを起動する前に，HAモニタエージェントを起動する。

接続するHAモニタをすべて停止してから，HAモニタエージェントを停止する。

注意事項

HVRDによるレプリケーションを必要とするサーバが稼働中の場合は，HAモニタエージェントを停止しないでください。メンテナンスなどで停止する必要がある場合は，メンテナンスなどの終了後にHAモニタエージェントを速やかに起動してください。

HAモニタ起動時に，パブリッククラウド環境の情報取得が失敗している（メッセージKAMN766-Eが出力されている）場合，パブリッククラウド環境の情報取得が成功する（メッセージKAMN765-Iが出力される）まで，HAモニタエージェントとの接続はできません。HAモニタで，メッセージKAMN766-Eに従って対処してください。

6.2　システムの変更

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「システムの変更」を参照してください。この節では，システムの変更について，パブリッククラウド環境下で差異がある事項だけを記載します。

6.2.1　サーバを追加する

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「サーバを追加する」を参照してください。ただし，AWS環境下およびAzure環境下では加えて次の準備も必要になります。

サーバを追加する場合の準備として，DRBDのリソースを追加する。

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

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「系やサーバを稼働させたまま共有リソースの構成を変更する」を参照してください。ただし，AWS環境下およびAzure環境下では次の点が異なります。

DRBDリソースの動的変更はできない。

6.3　システム運用時の注意事項

ここでは，システム運用時の注意事項について説明します。

6.3.1　パブリッククラウド環境のコンソール操作（CLI発行含む）をする場合の注意事項

パブリッククラウド環境のコンソール操作（CLI発行含む）をする場合の注意事項について，説明します。

HAモニタでのエラーを回避するために，系切り替え構成内のインスタンス（Azureの仮想マシンも含む）に対するパブリッククラウド環境のコンソール操作（CLI発行含む）は，必要最低限にしてください。

HAモニタはCLIを実行して，強制停止などの操作を実施します。HAモニタ以外のアプリケーションやユーザによるインスタンスの操作と，HAモニタによるCLIの実行タイミングが重なると，HAモニタがエラーメッセージを出力したり，系切り替えに失敗したりするおそれがあります。

エラーメッセージが出力されたときは，内容を確認して対処してください。系切り替えに失敗したときは，マニュアル高信頼化システム監視機能 HA モニタ Linux(R)（x86）編の「系のリセット失敗に対処する」を参照してください。

6.3.2　【AWS】【Azure】レプリケーションソフトを使用する場合の注意事項

レプリケーションソフトを使用する場合の注意事項について，説明します。

<DRBD，HVRD共通の注意事項>

HAモニタのメッセージだけでなく，レプリケーションソフトが出力するメッセージにも従い，適切に対処してください。

<DRBDの注意事項>

レプリケーションソフトを使用する場合，系ごとに業務ディスクを配置する構成にします。これらの業務ディスクのデータをレプリケーションソフトによって同期します。業務ディスクのデータが同期できている場合は，最新の業務ディスクのデータにアクセスできている状態のため，問題ありません。しかし，次の状態の場合は，業務ディスクのデータが同期されていないため，どれかの系の業務ディスクのデータが古くなっています。

・系間のレプリケーションパスが接続できていない状態

セカンダリ側の系の業務ディスクのデータが古くなっています。

・系またはレプリケーションソフトが起動していない状態

起動していない系の業務ディスクのデータが古くなっています。

・業務ディスクに障害が発生した状態

障害が発生した業務ディスクのデータが古くなっています。

これらの状態になっている場合は，速やかに系間でレプリケーションできる状態に回復し，データを同期させてください。状態を回復させるまでは，業務ディスクのデータが古い系で，実行サーバを起動しないでください。状態が回復しないままシステムを停止し，業務ディスクのデータが古い系だけを起動した場合，業務ディスクのデータが古い系で実行サーバが起動するおそれがあります。業務ディスクのデータが古い系で実行サーバが起動してしまった場合は，速やかに実行サーバを停止してください。

なお，実行サーバが，データが古い業務ディスクを更新した場合は，その業務ディスクと最新のデータを持つ業務ディスクは同期できません。最新のデータを持つ業務ディスクを同期の元として生かすように，レプリケーションソフトの回復運用をしてください。詳細は，レプリケーションソフトのドキュメントを参照してください。

プライマリ側の系からセカンダリ側の系に業務ディスクのデータを同期中に，プライマリ側の系障害による系切り替えが発生した場合，セカンダリ側では業務ディスクにアクセスできません。このため，セカンダリ側の実行サーバの停止，およびプライマリ側の系と実行サーバを再起動してください。

プライマリ側の系からセカンダリ側の系に業務ディスクのデータを同期中に，プライマリ側の実行サーバ障害による系切り替え，または計画系切り替えが発生した場合は，ディスクにアクセスできるため，対処は不要です。

レプリケーションする別の系が障害で起動できない場合などに，系をスタンドアロンで運用するときは，次のことを確認してください。

・OSを起動したあと，サーバを起動する前に，DRBDリソースのdiskの状態がUpToDateになっていること

レプリケーションソフトは，別の系とレプリケーションパスで接続して互いに状態を確認するまで，diskの状態がConsistentになっている場合があります。この場合，auto-promoteによる自動プライマリ化ができないため，ディスクを使用できず，サーバの起動に失敗するおそれがあります。diskの状態がConsistentになっている場合は，次の操作をして，diskの状態がUpToDateになったことを確認してからサーバを起動してください。

手動でプライマリ化する

# drbdadm primary リソース名

diskの状態がUpToDateになったことを確認する

# drbdadm status リソース名

auto-promoteによる自動プライマリ化を有効にするため，セカンダリ化する

# drbdadm secondary リソース名

<HVRDの注意事項>

HVRDの注意事項については，HVRDの取扱説明書「Ｈｉｔａｃｈｉ　Ｖｏｌｕｍｅ　Ｒｅｐｌｉｃａｔｉｏｎ　Ｄｒｉｖｅｒ　ｆｏｒ　Ｌｉｎｕｘ」を参照してください。

6.3.3　【AWS】HVRD連携時の注意事項

HVRD連携時の注意事項について，説明します。

HVRDの通信障害でレプリケーションが中断した際は，次に従って対処してください。

<レプリケーション元でI/Oを継続している場合>

レプリケーションができなくなった原因を調査する

HAモニタエージェントが稼働している系で，monshow -agtコマンドを実行すると，各AZのHAモニタとの通信状況を確認できます。必要に応じて原因調査の手段として活用してください。

monshow -agtコマンドを実行すると，HAモニタエージェントが直近1分間に各HAモニタから受信したヘルスチェックメッセージの受信数がわかります。ヘルスチェックメッセージは100msごとに送信しているため，600個受信できている場合が正常です（コマンド実行とヘルスチェックメッセージ受信のタイミングによって599個の場合もあります）。例えば，レプリケーション先の系の受信数が0個となっていれば，レプリケーション先のOSやインスタンス，またはAZの通信不調や障害と判断できます。コマンドの詳細は，「8.1.3　monshow（サーバと系の状態表示）」を参照してください。

エラー原因を取り除いたあと，データを再同期してレプリケーションを再開させる

待機サーバが停止している場合は，待機サーバを再起動する

<レプリケーション元がI/Oを停止してディスクI/Oがエラーとなった場合>

AZ内で系切り替えして業務が継続しているとき

系切り替え元で発生したエラーの原因を取り除いたあと，待機サーバを起動します。必要に応じて切り戻しなどをしてください。

業務が停止しているとき

各AZの状態をAWSのコンソールなどを使用して確認し，業務を再開するAZを決めます。

HAモニタエージェントが稼働している系で，monshow -agtコマンドを実行すると，エージェントヘルスチェックによる通信状況が確認できます。各AZの各HAモニタからのヘルスチェックメッセージ受信数がわかるため，不調のないAZおよび系を確認できます。AZの状態確認でネットワーク状態を調査するときに，必要に応じて活用してください。各コマンドの詳細は，「8.1.3　monshow（サーバと系の状態表示）」を参照してください。

HVRDによるレプリケーションを必要とするサーバの稼働中は，HAモニタエージェントを停止しないでください。メンテナンスなどで停止する必要がある場合は，メンテナンスなどの終了後，速やかにHAモニタエージェントを起動してください。

HAモニタ起動時にメッセージKAMN766-Eが出力され，パブリッククラウド環境の情報取得が失敗している場合，パブリッククラウド環境の情報取得の成功を示すメッセージKAMN765-Iが出力されるまで，HAモニタエージェントとの接続はできません。HAモニタで，メッセージKAMN766-Eに従って対処してください。

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

HAモニタを使用するに当たって，ユーザはHAモニタおよびサーバの環境設定を定義ファイルにする必要があります。この章では，定義の記述規則，定義ファイルに指定するオペランド，および環境設定例について説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「環境設定で定義するファイル」とあわせてお読みください。

7.1　定義ファイルの概要

ここでは，ユーザが環境設定で定義するファイルについて説明します。定義する必要がある環境設定のファイルを，次に示します。

sysdefファイル

HAモニタが動作するための環境設定をします。詳細については，「7.2　HAモニタの環境設定」を参照してください。

serversファイル

サーバが動作するための環境設定をします。リソースサーバを使用する場合も，serversファイルで環境設定をします。詳細については，「7.3　サーバの環境設定」を参照してください。

系に定義ファイルを設定するに当たっての注意事項を，次に示します。

定義ファイルは，HAモニタがあるすべての系で設定してください。

定義ファイルの作成に当たって，定義ファイルのオペランドを現用・予備系で同じ値にする必要がある個所と，異なる値にする必要がある個所があります。

定義ファイルの作成が完了したら，必ずすべての系に配布した上で，定義チェックコマンド（moncheckコマンド）を実行してください。

7.2　HAモニタの環境設定

マニュアル高信頼化システム監視機能 HA モニタ Linux(R)（x86）編の「HAモニタの環境設定」の説明を参照してください。この節では，HAモニタの環境設定について，パブリッククラウド環境下で差異がある事項だけを記載します。

7.2.1　パブリッククラウド環境固有のHAモニタの環境設定

ここでは，パブリッククラウド環境固有のHAモニタの環境設定（sysdef）について説明します。

HAモニタの環境設定をする定義ファイルを，次に示します。太字部分は，系間で同じ値を指定してください。太字以外の部分は，系間で矛盾がないように設定してください。

/*    HAモニタの環境設定    */
  environment
       :
            〔,lanport_ltd
                     TCP/IPのサービス名〕
       :
            〔,lan_agent
                     TCP/IPのホスト名〕
            〔,lanport_agent
                     TCP/IPのサービス名〕
       :
〔function
       :
            〔,public_cloud
                   ｛use｜nouse｝〕
            〔,fence_network
                   ｛use｜nouse｝〕
       :
            〔,agt_split_time
                   ｛HVRD設定のwriteタイムアウト時間｜6｝〕
       :

(1)　environment定義文

HAモニタの動作環境を定義します。environment定義文のオペランドを，次に示します。

(a)　lanport_ltd

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

1〜32文字の英数字

--

（単位：--）

可

--

説明

AWS環境の場合に，Linux Tough Dumpとの連携に使用するTCP/IP LANのサービス名を指定します。系切り替え構成内のすべての系で同じ値を指定してください。

メモ

Linux Tough Dumpについては，弊社担当営業にお問い合わせください。

このオペランドには，/etc/servicesファイルに設定したサービス名と同じサービス名を指定してください。

/etc/servicesファイルにサービス名を登録する方法と設定例を次に示します。

サービス名の登録方法

/etc/servicesファイルに，TCP/IP LANのサービス名，ポート番号，およびプロトコル名を指定します。

TCP/IP LANのサービス名には，lanportオペランドに指定したサービス名とは異なるサービス名を指定してください。

ポート番号の値は，5001以上で，かつシステムで未使用の番号を指定してください。また，プロトコル名にはudpを指定してください。

系切り替え構成内のすべての系で同じサービス名，および同じポート番号を指定してください。

/etc/servicesファイルの設定例

# サービス名    ポート番号/プロトコル名
HAmon_ltd       7790/udp

(b)　lan_agent

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

1〜32文字のパス名

--

（単位：--）

可

lanオペランドに指定した値

説明

HAモニタエージェントを使用した構成の場合に，エージェントヘルスチェックに使用するTCP/IP LANのホスト名を指定します。HAモニタエージェントと接続するHAモニタに指定してください。

エージェントヘルスチェックに使用するパスを監視パスと分けたいときに，このオペランドで変更できます。

このオペランドには，/etc/hostsファイルに設定したホスト名と同じホスト名を指定してください。

(c)　lanport_agent

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

1〜32文字の英数字

--

（単位：--）

可

--

説明

HAモニタエージェントを使用した構成の場合に，エージェントヘルスチェックに使用するTCP/IP LANのサービス名を指定します。HAモニタエージェント，およびHAモニタエージェントと接続するHAモニタに指定してください。また，系切り替え構成内のすべての系で同じ値を指定してください。

このオペランドには，/etc/servicesファイルに設定したサービス名と同じサービス名を指定してください。

/etc/servicesファイルにサービス名を登録する方法と設定例を次に示します。

サービス名の登録方法

/etc/servicesファイルに，TCP/IP LANのサービス名を指定します。

TCP/IP LANのサービス名には，lanportオペランドに指定したサービス名とは異なるサービス名を指定してください。

ポート番号の値は，5001以上で，かつシステムで未使用の番号を指定してください。また，プロトコル名にはudpを指定してください。

系切り替え構成内のすべての系で同じサービス名，および同じポート番号を指定してください。

/etc/servicesファイルの設定例

# サービス名    ポート番号/プロトコル名
HAmon_agent     7890/udp

(2)　function定義文

HAモニタの動作オプションを定義します。定義は任意です。定義していない場合は，仮定値が設定されます。function定義文のオペランドを，次に示します。

(a)　public_cloud

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

use｜nouse

--

（単位：--）

可

nouse

説明

パブリッククラウド環境で，系切り替えをするかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。

use：パブリッククラウド環境で系切り替えをする

nouse：パブリッククラウド環境で系切り替えをしない

(b)　fence_network

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

use｜nouse

--

（単位：--）

可

nouse

説明

AWS環境の場合に，ネットワーク遮断による系切り替え機能を使用するかどうかを指定します。系切り替え構成内のすべての系で同じ値を指定してください。public_cloudオペランドにuseを指定していない場合は，このオペランドを指定しても無視されます。

use：ネットワーク遮断による系切り替え機能を使用する

nouse：ネットワーク遮断による系切り替え機能を使用しない

このオペランドにuseを指定した場合，次の点に注意してください。

clearwaitオペランドとclearcheckオペランドの値は30秒になります。

fence_networkオペランドにuseを指定した場合も系のリセットによって系切り替えをするため，パブリッククラウド環境でのリセットに関するオペランドが有効になります。詳細については，「7.2.2　パブリッククラウド環境で注意が必要なHAモニタの環境設定のオペランド」を参照してください。また，注意が必要なHAモニタの環境設定のオペランドとして記載されていないcpudownオペランドおよびreset_typeオペランドも有効になります。

HAモニタのネットワーク遮断設定ファイルを設定してください。

ネットワーク遮断設定ファイルの設定については，「5.13.3　【AWS】ネットワーク遮断設定ファイルの設定」を参照してください。

(c)　agt_split_time

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

符号なし整数

1～3600

（単位：秒）

可

6

説明

HAモニタエージェントを使用した構成の場合に，自系とHAモニタエージェント間の通信タイムアウト時間を指定します。指定した値は，HVRDがレプリケーション通信断となったとき，自系が孤立状態であるか判断するために使用します。

系切り替え構成内のすべての系で，HAモニタエージェントと接続するHAモニタに，HVRDで設定しているディスクのwriteのタイムアウト値と同じ値を指定してください。

7.2.2　パブリッククラウド環境で注意が必要なHAモニタの環境設定のオペランド

パブリッククラウド環境下でHAモニタを使用する場合に，注意が必要なオペランドについてだけ次の表で説明します。各オペランドの詳細については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタの環境設定」の説明を参照してください。

表7‒1　注意が必要なHAモニタの環境設定のオペランド

オペランド名

注意事項

lan

public_cloudオペランドにuseを指定した場合，監視パスは1つだけ指定してください。監視パスを複線にする必要がある場合は，Linuxでbondingを設定し，bondingデバイスを監視パスに指定してください。

hostmax

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

clearwait

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。なお，系リセット発行待ち時間は次のとおりになります。

AWS環境またはAzure環境のとき：120秒

OCI環境のとき：30秒

fence_networkオペランドにuseを指定したとき：30秒

resetpatrol

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

standbyreset

public_cloudオペランドにuseを指定した場合，次の点に注意してください。

レプリケーションソフトを使用するとき※1

このオペランドの指定値に関係なく，待機系をリセットします。ただし，HVRDを使用する場合で1対1構成のときは，必ずuseを指定してください。

レプリケーションソフトを使用しないとき※2

このオペランドの指定値が有効となります。

netmask

public_cloudオペランドにuseを指定した場合，このオペランドの指定値に関係なく，bitが仮定されます。

partition_reset

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

alive_multicast

public_cloudオペランドにuseを指定した場合，このオペランドにuseを指定しないでください。

multicast_lan

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

vmware_env

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

resetpatrol_mode

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

fence_reset

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

fence_scsi

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

fence_lan

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

scsi_check

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

scsi_pathcheck

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

scsi_timeout

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

scsi_retry

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

hbond_lacp

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

notswitch_notify

public_cloudオペランドにuseを指定した場合，次の状態でも警告メッセージを出力します。

パブリッククラウド環境の情報取得で異常を検知している場合：メッセージKAMN767-W

AWS CLI，Azure CLI，またはOCI CLIの実行可否チェックで異常を検知している場合：メッセージKAMN769-W

resetpath_retry

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

resetpath_inter

public_cloudオペランドにuseを指定した場合，このオペランドの指定は無視されます。

lancheck_mode

public_cloudオペランドにuseを指定し，lanfailswitchオペランドにuseを指定した場合，このオペランドには，routeを指定してください。

clearcheck

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。なお，系のリセット終了時間は次のとおりになります。

AWS環境またはAzure環境のとき：120秒

OCI環境のとき：30秒

fence_networkオペランドにuseを指定したとき：30秒

注※1

レプリケーションソフト用のシェルスクリプト群を展開しているとき。

なお，下記の構成との混在を含みます。

AWS環境での，EBSマルチアタッチ，またはEFSによる共有ディスク構成

Azure環境での，マネージドディスクによる共有ディスク構成

注※2

レプリケーションソフト用のシェルスクリプト群を展開していないとき。

下記の構成および環境が該当します。

AWS環境での，EBSマルチアタッチだけの構成，EFSによる共有ディスクだけの構成，またはHVRDを使用した構成

Azure環境での，マネージドディスクによる共有ディスクだけの構成

OCI環境

7.2.3　【AWS】HAモニタエージェントで指定可能なHAモニタの環境設定のオペランド

AWS環境下でHAモニタエージェントを使用した構成の場合に，HAモニタエージェントで指定可能なHAモニタの環境設定のオペランドを次の表で説明します。なお，表に記載がないオペランドは指定できません。各オペランドの詳細については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタの環境設定」の説明を参照してください。

表7‒2　【AWS】HAモニタエージェントで指定可能なHAモニタの環境設定のオペランド

オペランド名

注意事項

name

接続するすべてのHAモニタと異なる指定値にしてください。

address

接続するすべてのHAモニタと異なる指定値にしてください。

lan

HAモニタエージェントの監視パスの指定は1つとしてください。

lanport_agent

−

（凡例）

−：注意事項はありません。

7.3　サーバの環境設定

マニュアル高信頼化システム監視機能 HA モニタ Linux(R)（x86）編の「サーバの環境設定」の説明を参照してください。この節では，サーバの環境設定について，パブリッククラウド環境下で差異がある事項だけを記載します。

7.3.1　パブリッククラウド環境固有のサーバの環境設定

ここでは，パブリッククラウド環境固有のサーバの環境設定（servers）について説明します。

サーバ対応の環境設定をする定義ファイルを，次に示します。太字部分は，系間で同じ値を指定してください。太字以外の部分は，系間で矛盾がないように設定してください。

/*  サーバ対応の環境設定  */
  server
       :
           〔,rep_device
                     DRBDのリソース名〔:DRBDのリソース名…〕〕
       :
/*  リソースサーバ対応の環境設定  */
〔resource
       :
           〔,rep_device
                     DRBDのリソース名〔:DRBDのリソース名…〕〕
       :

(1)　server定義文

サーバの動作環境を定義します。server定義文のオペランドを，次に示します。

(a)　rep_device

ユーザ指定値

値の種別

数値の範囲

値の省略

指定を省略したときの仮定値

1～128文字のDRBDのリソース名

--

（単位：--）

可

--

説明

AWS環境またはAzure環境の場合に，ディスクをレプリケーションする構成を使用するときに指定します。

「5.5　【AWS】【Azure】レプリケーションソフト（DRBD）の設定」で設定したDRBDのリソース名を指定してください。ただし，DRBDのリソース名は，次の条件を満たす必要があります。

DRBDのリソース名は，1〜128文字の英字，数字，/，-，_，.で指定する。

最大256個指定できる。リソースサーバを含む全サーバの指定値の合計が256個以内となるようにする。

系切り替え構成内のすべての系で同じ値を指定する。

次の手順によって，業務で使用するVG名を基に，DRBDのリソース名を取得することもできます。

次のコマンドを実行して，PV名を確認します。

# vgdisplay -v VG名

実行例を次に示します。太字の部分がPV名です。

# vgdisplay -v Vol00
  --- Volume group ---
  VG Name               Vol00
  System ID
    ：(途中省略)
  --- Physical volumes ---
  PV Name               /dev/drbd5
  PV UUID
    ：(途中省略)

次のコマンドを実行して，対象のDRBDリソースが定義されたDRBDの設定ファイルを確認します。

# grep -rl PV名 /etc/drbd.d/

実行例を次に示します。太字の部分がDRBDの設定ファイルです。

# grep -rl /dev/drbd5 /etc/drbd.d/
/etc/drbd.d/r0.res

次のコマンドを実行して，DRBDの設定ファイルの内容を表示します。手順1.で確認したPVを使用しているresourceセクションを探し，DRBDのリソース名を取得します。

# cat DRBD設定ファイル

実行例を次に示します。1つ目の太字の部分がDRBDのリソース名，2つ目の太字の部分が手順1.で確認したPVです。

# cat /etc/drbd.d/r0.res
 resource r0 {
    volume 0 {
        device /dev/drbd5;
        disk /dev/xvdf1;
        meta-disk internal;
    }
    volume 1 {
      ：(以下省略)

以上の手順で取得したDRBDのリソース名をrep_deviceオペランドに指定してください。

(2)　resource定義文

リソースサーバを定義します。

各オペランドはサーバ対応の環境設定であるserver定義文と同様であるため，それらの説明については，「(1)　server定義文」の同一オペランドの説明を参照してください。

7.3.2　パブリッククラウド環境で注意が必要なサーバ対応の環境設定のオペランド

ここでは，パブリッククラウド環境下でHAモニタを使用する場合に，注意が必要なオペランドについてだけ記載します。各オペランドの詳細については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「サーバの環境設定」の説明を参照してください。

表7‒3　注意が必要なサーバ対応の環境設定のオペランド

オペランド名

注意事項

hab_gid

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

ただし，AWS環境でHVRDと連携する場合は，このオペランドを指定してください。

hab_discnt_atend

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

ただし，AWS環境でHVRDと連携する場合は，必要に応じてこのオペランドを指定してください。

scsi_device

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

dmmp_device

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

switch_judge

public_cloudオペランドにuseを指定した場合，このオペランドは指定しないでください。

fs_name

AWS環境でEFSを使用する場合，ファイルシステムのDNS名とマウントするディレクトリをダブルクォーテーションで囲み，"DNS名:/〔ディレクトリ〕"の形式で指定します。なお，"DNS名:/〔ディレクトリ〕"は，1〜256文字の文字列で指定してください。ファイルシステムのDNS名は，Amazon EFSコンソールから確認できます。

fs_mount_opt

AWS環境でEFSを使用する場合，amazon-efs-utilsツールを使用してマウントするときは，"-t efs"を指定します。amazon-efs-utilsツールを使用しないでマウントするときは，EFSのドキュメントを参照し，推奨されるマウントオプションを確認してください。

7.4　環境設定例

ここでは，パブリッククラウド環境での環境設定例について説明します。

7.4.1　【AWS】HAモニタを使用する場合の構成

AWSを使用する場合の，次の環境設定例について説明します。

系のリセットによる系切り替えをする場合の設定例（レプリケーション構成）

ネットワーク遮断による系切り替えをする場合の設定例（レプリケーション構成）

共有ディスク構成の場合の設定例

HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合の設定例

クライアントからの通信がAWS Network Firewallを経由する構成の場合の設定例

(1)　系のリセットによる系切り替えをする場合の設定例（レプリケーション構成）

AWSを使用して系のリセットによる系切り替えをする場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒1　AWSを使用して系のリセットによる系切り替えをする場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のサブネットの情報を次の表に示します。

表7‒4　サブネットの情報

サブネット名

サブネットアドレス

内容

サブネット1-1

10.0.11.0/24

現用系のサーバ1用のサブネット

サブネット1-2

10.0.12.0/24

現用系のHAモニタ監視パス/サーバ2用のサブネット

サブネット1-3

10.0.13.0/24

現用系のレプリケーションソフト用のサブネット

サブネット2-1

10.0.21.0/24

予備系のサーバ1用のサブネット

サブネット2-2

10.0.22.0/24

予備系のHAモニタ監視パス/サーバ2用のサブネット

サブネット2-3

10.0.23.0/24

予備系のレプリケーションソフト用のサブネット

サブネット3

10.0.30.0/24

クライアント（サーバ2用）が動作するサブネット

サブネット4

10.0.40.0/24

クライアント（サーバ2用）が動作するサブネット

このシステム構成のルートテーブルの情報を次の表に示します。

表7‒5　ルートテーブルの情報

ルートテーブル

ルートテーブルID

内容

ルートテーブル1

rtb-xxxxxxxx

host3からサーバ2向けのVIPの経路情報が登録されているルートテーブル

ルートテーブル2

rtb-yyyyyyyy

host4からサーバ2向けのVIPの経路情報が登録されているルートテーブル

このシステム構成のENIの情報を次の表に示します。

表7‒6　ENIの情報

ENI

ENI-ID

内容

ENI1-1

eni-1a11111

サブネット1-1で使用するENI

ENI1-2

eni-2a22222

サブネット1-2で使用するENI

ENI1-3

eni-3a33333

サブネット1-3で使用するENI

ENI2-1

eni-1b11111

サブネット2-1で使用するENI

ENI2-2

eni-2b22222

サブネット2-2で使用するENI

ENI2-3

eni-3b33333

サブネット2-3で使用するENI

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒7　サーバ用の仮想IPアドレス

仮想IPアドレス

種別

割り当てるNIC

割り当てるENI

説明

10.0.11.1

EIP

NIC1

ENI1-1 / ENI 2-1

サーバ1用の仮想IPアドレス。

host1が実行系の場合は，ENI1-1に仮想IPアドレスを割り当てます。

host2が実行系の場合は，ENI2-1に仮想IPアドレスを割り当てます。

10.2.12.101

VIP

lo

-

サーバ2用の仮想IPアドレス

AWSの仕様によって，VIPには次の特徴があります。

VIPはVPCのCIDRの範囲外

VIPのCIDRブロックは32

このシステム構成のHAモニタの情報を次の表に示します。

表7‒8　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

10.0.12.101

監視パスのサービス名

HAmon1

系障害監視時間

60

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

10.0.22.101

監視パスのサービス名

HAmon1

系障害監視時間

60

このシステム構成のサーバ1の情報を次の表に示します。

表7‒9　サーバ1の情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のサーバ2の情報を次の表に示します。

表7‒10　サーバ2の情報

系

項目

設定値

現用系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のEBSの情報を次の表に示します。

表7‒11　EBSの情報

リソース

レプリケーション用IPアドレス

レプリケーション用ポート番号

属性

EBS

項目

値

r1

（サーバ1用）

10.0.13.101

7789

プライマリ

EBS1

物理ボリューム名

/dev/drbd1

パーティション名

/dev/nvme0n1

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

10.0.23.101

7789

セカンダリ

EBS3

物理ボリューム名

/dev/drbd1

パーティション名

/dev/nvme0n1

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

r2

（サーバ2用）

10.0.13.101

7790

プライマリ

EBS2

物理ボリューム名

/dev/drbd2

パーティション名

/dev/nvme1n1

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

10.0.23.101

7790

セカンダリ

EBS4

物理ボリューム名

/dev/drbd2

パーティション名

/dev/nvme1n1

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

このシステム構成での環境設定例を，次に示します。

現用系のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系では，nameオペランド，addressオペランド，およびlanオペランドに，予備系側の値を設定してください。

/* HAモニタの環境設定 */
environment name             host1,
            address          101,
            patrol           60,
            lan              path11,
            lanport          HAmon1;
function    cpudown          standby,
            public_cloud     use;

現用系のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name           /users/server1,
       alias          server1,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol01,
       fs_name        /dev/Repvol01/lvol00,
       fs_mount_dir   /mnt/data1,
       rep_device     r1;

server name           /users/server2,
       alias          server2,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol02,
       fs_name        /dev/Repvol02/lvol00,
       fs_mount_dir   /mnt/data2,
       rep_device     r2;

現用系のserver1.upファイルの設定

予備系では，EIP_ENIにENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.11.1
EIP_ENI[0]=eni-1a11111
EIP_LABEL[0]=NIC1:0

（以降省略）

現用系のserver2.upファイルの設定

予備系では，VIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-2a22222
VIP_LABEL[0]=lo:0

（以降省略）

現用系のserver1.downファイルの設定

予備系では，EIP_ENIには，ENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.11.1
EIP_ENI[0]=eni-1a11111
EIP_LABEL[0]=NIC1:0

（以降省略）

現用系のserver2.downファイルの設定

予備系では，VIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-2a22222
VIP_LABEL[0]=lo:0

（以降省略）

現用系のレプリケーションソフト（DRBD）の設定

/etc/drbd.d/global_common.conf

現用系でも予備系でも同じ設定内容です。

global {
  usage-count no;
}
common {
    handlers {
        fence-peer "/opt/hitachi/HAmon/bin/parts/monfence-peer.sh";
  　}
    options {
        auto-promote yes;
    }
    net {
        protocol C;
        fencing resource-and-stonith;
    }
    startup {
        wfc-timeout 30;
    }
}

/etc/drbd.d/r1.res

現用系でも予備系でも同じ設定内容です。

環境によってOS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/nvme0n1などへのシンボリックリンクファイル）を指定することをお勧めします。

resource r1 {
    volume 0 {
        device    /dev/drbd1;
        disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol079fef9e1c70a8790;
        meta-disk internal;
    }
    on host1 {
        address   10.0.13.101:7789;
    }
    on host2 {
        address   10.0.23.101:7789;
    }
}

/etc/drbd.d/r2.res

現用系でも予備系でも同じ設定内容です。

環境によって，OS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/nvme1n1などへのシンボリックリンクファイル）を指定することをお勧めします。

resource r2 {
    volume 1 {
        device    /dev/drbd2;
        disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol02c8a3ab941d231f1;
        meta-disk internal;
    }
    on host1 {
        address   10.0.13.101:7790;
    }
    on host2 {
        address   10.0.23.101:7790;
    }
}

connectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

現用系でも予備系でも同じ設定内容です。

host1    LAN    10.0.12.101;
host2    LAN    10.0.22.101;

(2)　ネットワーク遮断による系切り替えをする場合の設定例（レプリケーション構成）

AWSを使用してネットワーク遮断による系切り替えをする場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒2　AWSを使用してネットワーク遮断による系切り替えをする場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のサブネットの情報を次の表に示します。

表7‒12　サブネットの情報

サブネット名

サブネットアドレス

内容

サブネット1-1

10.0.11.0/24

現用系のHAモニタ監視パス用のサブネット

サブネット1-2

10.0.12.0/24

現用系のサーバ1/サーバ2/レプリケーションソフト用のサブネット

サブネット2-1

10.0.21.0/24

予備系のHAモニタ監視パス用のサブネット

サブネット2-2

10.0.22.0/24

予備系のサーバ1/サーバ2/レプリケーションソフト用のサブネット

サブネット3

10.0.30.0/24

クライアント（サーバ2用）が動作するサブネット

サブネット4

10.0.40.0/24

クライアント（サーバ2用）が動作するサブネット

このシステム構成のルートテーブルの情報を次の表に示します。

表7‒13　ルートテーブルの情報

ルートテーブル

ルートテーブルID

内容

ルートテーブル1

rtb-xxxxxxxx

host3からサーバ2向けのVIPの経路情報が登録されているルートテーブル

ルートテーブル2

rtb-yyyyyyyy

host4からサーバ2向けのVIPの経路情報が登録されているルートテーブル

このシステム構成のENIの情報を次の表に示します。

表7‒14　ENIの情報

ENI

ENI-ID

内容

ENI1-1

eni-1a11111

サブネット1-1で使用するENI

ENI1-2

eni-2a22222

サブネット1-2で使用するENI

ENI2-1

eni-1b11111

サブネット2-1で使用するENI

ENI2-2

eni-2b22222

サブネット2-2で使用するENI

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒15　サーバ用の仮想IPアドレス

仮想IPアドレス

種別

割り当てるNIC

割り当てるENI

説明

10.0.12.1

EIP

NIC2

ENI1-2 / ENI 2-2

サーバ1用の仮想IPアドレス。

host1が実行系の場合は，ENI1-2に仮想IPアドレスを割り当てます。

host2が実行系の場合は，ENI2-2に仮想IPアドレスを割り当てます。

10.2.12.101

VIP

lo

-

サーバ2用の仮想IPアドレス

AWSの仕様によって，VIPには次の特徴があります。

VIPはVPCのCIDRの範囲外

VIPのCIDRブロックは32

このシステム構成のHAモニタの情報を次の表に示します。

表7‒16　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

10.0.11.101

監視パスのサービス名

HAmon1

系障害監視時間

60

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

10.0.21.101

監視パスのサービス名

HAmon1

系障害監視時間

60

このシステム構成のサーバ1の情報を次の表に示します。

表7‒17　サーバ1の情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のサーバ2の情報を次の表に示します。

表7‒18　サーバ2の情報

系

項目

設定値

現用系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のEBSの情報を次の表に示します。

表7‒19　EBSの情報

リソース

レプリケーション用IPアドレス

レプリケーション用ポート番号

属性

EBS

項目

値

r1

（サーバ1用）

10.0.12.101

7789

プライマリ

EBS1

物理ボリューム名

/dev/drbd1

パーティション名

/dev/nvme0n1

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

10.0.22.101

7789

セカンダリ

EBS3

物理ボリューム名

/dev/drbd1

パーティション名

/dev/nvme0n1

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

r2

（サーバ2用）

10.0.12.101

7790

プライマリ

EBS2

物理ボリューム名

/dev/drbd2

パーティション名

/dev/nvme1n1

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

10.0.22.101

7790

セカンダリ

EBS4

物理ボリューム名

/dev/drbd2

パーティション名

/dev/nvme1n1

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

このシステム構成での環境設定例を，次に示します。

現用系のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系では，nameオペランド，addressオペランド，およびlanオペランドに，予備系側の値を設定してください。

/* HAモニタの環境設定 */
environment name             host1,
            address          101,
            patrol           60,
            lan              path11,
            lanport          HAmon1;
function    cpudown          standby,
            public_cloud     use,
            fence_network    use;

現用系のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name           /users/server1,
       alias          server1,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol01,
       fs_name        /dev/Repvol01/lvol00,
       fs_mount_dir   /mnt/data1,
       rep_device     r1;

server name           /users/server2,
       alias          server2,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol02,
       fs_name        /dev/Repvol02/lvol00,
       fs_mount_dir   /mnt/data2,
       rep_device     r2;

現用系のネットワーク遮断設定ファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/fence_network.env）

予備系では，ENI2-2のENI IDを設定してください。

eni-2a22222

現用系のserver1.upファイルの設定

予備系では，EIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.12.1
EIP_ENI[0]=eni-2a22222
EIP_LABEL[0]=NIC2:0

（以降省略）

現用系のserver2.upファイルの設定

予備系では，VIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-2a22222
VIP_LABEL[0]=lo:0

（以降省略）

現用系のserver1.downファイルの設定

予備系では，EIP_ENIには，ENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.12.1
EIP_ENI[0]=eni-2a22222
EIP_LABEL[0]=NIC2:0

（以降省略）

現用系のserver2.downファイルの設定

予備系では，VIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-2a22222
VIP_LABEL[0]=lo:0

（以降省略）

現用系のレプリケーションソフト（DRBD）の設定

/etc/drbd.d/global_common.conf

現用系でも予備系でも同じ設定内容です。

global {
  usage-count no;
}
common {
    handlers {
        fence-peer "/opt/hitachi/HAmon/bin/parts/monfence-peer.sh";
  　}
    options {
        auto-promote yes;
    }
    net {
        protocol C;
        fencing resource-and-stonith;
    }
    startup {
        wfc-timeout 30;
    }
}

/etc/drbd.d/r1.res

現用系でも予備系でも同じ設定内容です。

環境によってOS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/nvme0n1などへのシンボリックリンクファイル）を指定することをお勧めします。

resource r1 {
    volume 0 {
        device    /dev/drbd1;
        disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol079fef9e1c70a8790;
        meta-disk internal;
    }
    on host1 {
        address   10.0.12.101:7789;
    }
    on host2 {
        address   10.0.22.101:7789;
    }
}

/etc/drbd.d/r2.res

現用系でも予備系でも同じ設定内容です。

環境によって，OS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/nvme1n1などへのシンボリックリンクファイル）を指定することをお勧めします。

resource r2 {
    volume 1 {
        device    /dev/drbd2;
        disk      /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol02c8a3ab941d231f1;
        meta-disk internal;
    }
    on host1 {
        address   10.0.12.101:7790;
    }
    on host2 {
        address   10.0.22.101:7790;
    }
}

connectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

現用系でも予備系でも同じ設定内容です。

host1    LAN    10.0.11.101;
host2    LAN    10.0.12.101;

(3)　共有ディスク構成の場合の設定例

AWSを使用して共有ディスク構成にする場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒3　AWSを使用して共有ディスク構成にする場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のサブネットの情報を次の表に示します。

表7‒20　サブネットの情報

サブネット名

サブネットアドレス

内容

サブネット1-1

10.0.11.0/24

現用系のサーバ1用のサブネット

サブネット1-2

10.0.12.0/24

現用系のHAモニタ監視パス/サーバ2用のサブネット

サブネット2-1

10.0.21.0/24

予備系のサーバ1用のサブネット

サブネット2-2

10.0.22.0/24

予備系のHAモニタ監視パス/サーバ2用のサブネット

サブネット3

10.0.30.0/24

クライアント（サーバ2用）が動作するサブネット

サブネット4

10.0.40.0/24

クライアント（サーバ2用）が動作するサブネット

このシステム構成のルートテーブルの情報を次の表に示します。

表7‒21　ルートテーブルの情報

ルートテーブル

ルートテーブルID

内容

ルートテーブル1

rtb-xxxxxxxx

host3からサーバ2向けのVIPの経路情報が登録されているルートテーブル

ルートテーブル2

rtb-yyyyyyyy

host4からサーバ2向けのVIPの経路情報が登録されているルートテーブル

このシステム構成のENIの情報を次の表に示します。

表7‒22　ENIの情報

ENI

ENI-ID

内容

ENI1-1

eni-1a11111

サブネット1-1で使用するENI

ENI1-2

eni-2a22222

サブネット1-2で使用するENI

ENI2-1

eni-1b11111

サブネット2-1で使用するENI

ENI2-2

eni-2b22222

サブネット2-2で使用するENI

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒23　サーバ用の仮想IPアドレス

仮想IPアドレス

種別

割り当てるNIC

割り当てるENI

説明

10.0.11.1

EIP

NIC1

ENI1-1 / ENI 2-1

サーバ1用の仮想IPアドレス。

host1が実行系の場合は，ENI1-1に仮想IPアドレスを割り当てます。

host2が実行系の場合は，ENI2-1に仮想IPアドレスを割り当てます。

10.2.12.101

VIP

lo

-

サーバ2用の仮想IPアドレス

AWSの仕様によって，VIPには次の特徴があります。

VIPはVPCのCIDRの範囲外

VIPのCIDRブロックは32

このシステム構成のHAモニタの情報を次の表に示します。

表7‒24　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

10.0.12.101

監視パスのサービス名

HAmon1

系障害監視時間

60

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

10.0.22.101

監視パスのサービス名

HAmon1

系障害監視時間

60

このシステム構成のサーバ1の情報を次の表に示します。

表7‒25　サーバ1の情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のサーバ2の情報を次の表に示します。

表7‒26　サーバ2の情報

系

項目

設定値

現用系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のEBSの情報を次の表に示します。

表7‒27　EBSの情報

EBS

項目

設定値

EBS1（サーバ1用）

パーティション

/dev/sdf1

物理ボリューム

/dev/sdf1

ボリュームグループ

vg01

ボリュームグループの絶対パス

/dev/vg01

論理ボリューム

lvol01

論理ボリュームの絶対パス

/dev/vg01/lvol01

マウントディレクトリ

/mnt/data1

EBS2（サーバ2用）

パーティション

/dev/sdg1

物理ボリューム

/dev/sdg1

ボリュームグループ

vg02

ボリュームグループの絶対パス

/dev/vg02

論理ボリューム

lvol01

論理ボリュームの絶対パス

/dev/vg02/lvol01

マウントディレクトリ

/mnt/data2

このシステム構成での環境設定例を，次に示します。

現用系のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系では，nameオペランド，addressオペランド，およびlanオペランドに，予備系側の値を設定してください。

/* HAモニタの環境設定 */
environment name             host1,
            address          101,
            patrol           60,
            lan              path11,
            lanport          HAmon1;
function    public_cloud     use;

現用系のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg01,
       fs_name      /dev/vg01/lvol01,
       fs_mount_dir /mnt/data1;

server name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg02,
       fs_name      /dev/vg02/lvol01,
       fs_mount_dir /mnt/data2;

現用系のネットワーク遮断設定ファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/fence_network.env）

ネットワーク遮断による系切り替えをする場合にだけ必要です。予備系では，ENI2-1，ENI2-2のENI IDを設定してください。

eni-1a11111
eni-2a22222

現用系のserver1.upファイルの設定

予備系では，EIP_ENIにENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.11.1
EIP_ENI[0]=eni-1a11111
EIP_LABEL[0]=NIC1:0

（以降省略）

現用系のserver2.upファイルの設定

予備系では，VIP_ENIにENI2-2のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-2a22222
VIP_LABEL[0]=lo:0

（以降省略）

現用系のserver1.downファイルの設定

予備系では，EIP_ENIには，ENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
EIP_ADDRESS[0]=10.0.11.1
EIP_ENI[0]=eni-1a11111
EIP_LABEL[0]=NIC1:0

（以降省略）

connectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

現用系でも予備系でも同じ設定内容です。

host1    LAN    10.0.12.101;
host2    LAN    10.0.22.101;

(4)　HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合の設定例

HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒4　HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のサブネットの情報を次の表に示します。

表7‒28　サブネットの情報

サブネット名

サブネットアドレス

内容

サブネット1-1

10.0.11.0/24

現用系のHAモニタ監視パス/サーバ用のサブネット

サブネット1-2

10.0.12.0/24

現用系のレプリケーション/エージェントヘルスチェック用のサブネット

サブネット2-1

10.0.21.0/24

予備系のHAモニタ監視パス/サーバ用のサブネット

サブネット2-2

10.0.22.0/24

予備系のレプリケーション/エージェントヘルスチェック用のサブネット

サブネット3

10.0.30.0/24

クライアント（サーバ用）が動作するサブネット

サブネット4

10.0.40.0/24

クライアント（サーバ用）が動作するサブネット

サブネット5

10.0.50.0/24

HAモニタエージェントのサブネット

このシステム構成のルートテーブルの情報を次の表に示します。

表7‒29　ルートテーブルの情報

ルートテーブル

ルートテーブルID

内容

ルートテーブル1

rtb-xxxxxxxx

host3からサーバ向けの仮想IPアドレスが登録されているルートテーブル

ルートテーブル2

rtb-yyyyyyyy

host4からサーバ向けの仮想IPアドレスが登録されているルートテーブル

このシステム構成のENIの情報を次の表に示します。

表7‒30　ENIの情報

ENI

ENI-ID

内容

ENI1-1

eni-1a11111

サブネット1-1で使用するENI

ENI1-2

eni-2a22222

サブネット1-2で使用するENI

ENI2-1

eni-1b11111

サブネット2-1で使用するENI

ENI2-2

eni-2b22222

サブネット2-2で使用するENI

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒31　サーバ用の仮想IPアドレス

仮想IPアドレス

種別

割り当てるNIC

割り当てるENI

説明

10.2.11.101

VIP

lo

-

サーバ用の仮想IPアドレス

このシステム構成のHAモニタエージェントの情報を次の表に示します。

表7‒32　HAモニタエージェントの情報

項目

設定値

ホスト名

agent

ホストアドレス

9999

エージェントヘルスチェックパスのホスト名

host_agt

エージェントヘルスチェックパスのIPアドレス

10.0.50.101

エージェントヘルスチェックパスのサービス名

HAmon_agt

このシステム構成のHAモニタの情報を次の表に示します。

表7‒33　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

10.0.11.101

監視パスのサービス名

HAmon1

系障害監視時間

60

エージェントヘルスチェックパスのホスト名

path11_agt

エージェントヘルスチェックパスのIPアドレス

10.0.12.101

エージェントヘルスチェックパスのサービス名

HAmon_agt

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

10.0.21.102

監視パスのサービス名

HAmon1

系障害監視時間

60

エージェントヘルスチェックパスのホスト名

path21_agt

エージェントヘルスチェックパスのIPアドレス

10.0.22.102

エージェントヘルスチェックパスのサービス名

HAmon_agt

このシステム構成のサーバの情報を次の表に示します。

表7‒34　サーバの情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

制御グループ※

1

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

制御グループ※

1

注※

HVRDの疑似デバイスを登録した制御グループです。

このシステム構成での環境設定例を，次に示します。

現用系のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系では，nameオペランド，addressオペランド，およびlanオペランドに，予備系側の値を設定してください。

/* HAモニタの環境設定 */
environment name             host1,
            address          101,
            patrol           60,
            lan              path11,
            lanport          HAmon1;
            lan_agent        path11_agt,
            lanport_agent    HAmon_agt;
function    cpudown          standby,
            public_cloud     use;

現用系のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name           /users/server1,
       alias          server1,
       acttype        server,
       patrol         60,
       initial        online,
       hab_gid        1;

現用系のserver1.upファイルの設定

予備系では，VIP_ENIにENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.11.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-1a11111
VIP_LABEL[0]=lo:0

（以降省略）

現用系のserver1.downファイルの設定

予備系では，VIP_ENIには，ENI2-1のENI IDを設定してください。

#!/bin/bash
set -x
　　　：
###############################################################################
VIP_ADDRESS[0]=10.2.12.101
VIP_RTB[0]="rtb-xxxxxxxx rtb-yyyyyyyy"
VIP_ENI[0]=eni-1a11111
VIP_LABEL[0]=lo:0

（以降省略）

HAモニタエージェントのconnectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

agent    LAN    10.0.50.101;
host1    LAN    10.0.12.101;
host2    LAN    10.0.22.102;

HAモニタのconnectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

現用系でも予備系でも同じ設定内容です。

host1    LAN    10.0.11.101;
host2    LAN    10.0.21.102;

(5)　クライアントからの通信がAWS Network Firewallを経由する構成の場合の設定例

クライアントからの通信がAWS Network Firewallを経由する構成の場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒5　クライアントからの通信がAWS Network Firewallを経由する場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のルートテーブルの情報を次の表に示します。

表7‒35　ルートテーブルの情報

ルートテーブル

ルートテーブルID

内容

ルートテーブル1

rtb-111111

トランジットゲートウェイアタッチメント1から，ファイアウォールエンドポイント向けのVIPの経路情報を登録するルートテーブル

ルートテーブル2

rtb-222222

トランジットゲートウェイアタッチメント2から，ファイアウォールエンドポイント向けのVIPの経路情報が登録されているルートテーブル

ルートテーブル3

rtb-333333

ファイアウォールエンドポイント1から，サーバ向けのVIPの経路情報を登録するルートテーブル

ルートテーブル4

rtb-444444

ファイアウォールエンドポイント2から，サーバ向けのVIPの経路情報を登録するルートテーブル

このシステム構成のENIの情報を次の表に示します。

表7‒36　ENIの情報

ENI

ENI-ID

内容

ENI1

eni-XXXX

サブネット5で使用するENI

ENI2

eni-YYYY

サブネット6で使用するENI

このシステム構成のファイアウォールエンドポイントの情報を次の表に示します。

表7‒37　ファイアウォールエンドポイントの情報

ファイアウォールエンドポイント

ファイアウォールエンドポイントID

内容

ファイアウォールエンドポイント1

vpce-XXXX

サブネット3で使用するファイアウォールエンドポイント

ファイアウォールエンドポイント2

vpce-YYYY

サブネット4で使用するファイアウォールエンドポイント

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒38　サーバ用の仮想IPアドレス

仮想IPアドレス

割り当てるENI

説明

10.10.10.10

ENI1/ENI2

サーバ用の仮想IPアドレス。

host1が実行系の場合は，ENI1に仮想IPアドレスを割り当てます。

host2が実行系の場合は，ENI2に仮想IPアドレスを割り当てます。

このシステム構成での環境設定例を，次に示します。

ここでは，LANの状態設定ファイルの例について示します。LANの状態設定ファイル以外の設定については，ほかの環境設定例を参考にしてください。

現用系（インスタンス1）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x

 VIP_ADDRESS[0]=10.10.10.10
 VIP_RTB[0]=rtb-333333
 VIP_ENI[0]=eni-XXXX
 VIP_LABEL[0]=lo:0
 VIP_RTB_TOFW[0]="rtb-111111 rtb-222222"
 VIP_FW[0]=vpce-XXXX

：(以下を編集しないこと)

予備系（インスタンス2）のサーバ識別名.upファイル，サーバ識別名.downファイル

#!/bin/bash
set -x

 VIP_ADDRESS[0]=10.10.10.10
 VIP_RTB[0]=rtb-444444
 VIP_ENI[0]=eni-YYYY
 VIP_LABEL[0]=lo:0
 VIP_RTB_TOFW[0]="rtb-111111 rtb-222222"
 VIP_FW[0]=vpce-YYYY

：(以下を編集しないこと)

7.4.2　【Azure】HAモニタを使用する場合の構成

Azureを使用する場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒6　Azureを使用する場合の構成

注※

loとは，ローカルループバックのことです。

このシステム構成のAzure ロードバランサーの情報を次の表に示します。

表7‒39　Azure ロードバランサーの情報

Azure ロードバランサー

フロントエンドIP

バックエンドIP

正常性プローブ

負荷分散規則

プロトコル

ポート番号

間隔

異常しきい値

フローティングIP（DSR）

パブリック

10.2.12.100

10.2.12.101

TCP

50000

5

2

有効

10.2.12.102

内部（プライベート）

172.16.10.100

172.16.10.101

TCP

50001

5

2

有効

172.16.10.102

このシステム構成のサーバ用の仮想IPアドレスを次の表に示します。

表7‒40　サーバ用の仮想IPアドレス

仮想IPアドレス

種別

割り当てるNIC

説明

10.2.12.100

パブリックIP

lo

サーバ1用の仮想IPアドレス。

パブリックロードバランサーのフロントエンドのIPアドレスと同じにしてください。

172.16.10.100

プライベートIP

lo

サーバ2用の仮想IPアドレス。

内部（プライベート）ロードバランサーのフロントエンドのIPアドレスと同じにしてください。

このシステム構成の仮想NICの情報を次の表に示します。

表7‒41　仮想NICの情報

リソース

種別

割り当てるNIC

仮想NIC1-1

10.2.12.101

サーバ1用のパブリックロードバランサーの仮想マシン1側のバックエンドIPです。

仮想NIC1-2

172.16.10.101

サーバ2用の内部（プライベート）ロードバランサーの仮想マシン1側のバックエンドIPです。

仮想NIC1-3

172.16.12.101

仮想マシン1側の監視パス用です。

仮想NIC1-4

172.16.11.101

仮想マシン1側のレプリケーション用です。

仮想NIC2-1

10.2.12.102

サーバ1用のパブリックロードバランサーの仮想マシン2側のバックエンドIPです。

仮想NIC2-2

172.16.10.102

サーバ2用の内部（プライベート）ロードバランサーの仮想マシン2側のバックエンドIPです。

仮想NIC2-3

172.16.12.102

仮想マシン2側の監視パス用です。

仮想NIC2-4

172.16.11.102

仮想マシン2側のレプリケーション用です。

このシステム構成のレプリケーションソフトで使用するIPアドレスとポート番号を次の表に示します。

表7‒42　レプリケーションソフトで使用するIPアドレスとポート番号の情報

リソース

系

IPアドレス

ポート番号

r1（サーバ1用）

プライマリ（host1）

172.16.11.101

7789

セカンダリ（host2）

172.16.11.102

7789

r2（サーバ2用）

プライマリ（host1）

172.16.11.101

7790

セカンダリ（host2）

172.16.11.102

7790

注

プレフィックスは24です。

このシステム構成のHAモニタの情報を次の表に示します。

表7‒43　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

172.16.12.101※

監視パスのサービス名

HAmon1

系障害監視時間

60

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

172.16.12.102※

監視パスのサービス名

HAmon1

系障害監視時間

60

注※

プレフィックスは24です。

このシステム構成のサーバ1の情報を次の表に示します。

表7‒44　サーバ1の情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のサーバ2の情報を次の表に示します。

表7‒45　サーバ2の情報

系

項目

設定値

現用系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のDisk Storageの情報を次の表に示します。

表7‒46　Disk Storageの情報

リソース

属性

Disk Storage

項目

値

r1

（サーバ1用）

プライマリ

Disk Storage1

物理ボリューム名

/dev/drbd1

パーティション名

/dev/sda

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

セカンダリ

Disk Storage3

物理ボリューム名

/dev/drbd1

パーティション名

/dev/sda

ボリュームグループ名

Repvol01

ボリュームグループの絶対パス

/dev/Repvol01

論理ボリュームの絶対パス

/dev/Repvol01/lvol00

マウントディレクトリ名

/mnt/data1

r2

（サーバ2用）

プライマリ

Disk Storage2

物理ボリューム名

/dev/drbd2

パーティション名

/dev/sdb

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

セカンダリ

Disk Storage4

物理ボリューム名

/dev/drbd2

パーティション名

/dev/sdb

ボリュームグループ名

Repvol02

ボリュームグループの絶対パス

/dev/Repvol02

論理ボリュームの絶対パス

/dev/Repvol02/lvol00

マウントディレクトリ名

/mnt/data2

このシステム構成での環境設定例を，次に示します。

可用性ゾーン1側のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系の可用性ゾーン2側では，nameオペランド，addressオペランド，およびlanオペランドに，可用性ゾーン2側の値を設定してください。

/* HAモニタの環境設定 */
environment name             host1,
            address          101,
            patrol           60,
            lan              path11,
            lanport          HAmon1;
function    cpudown          standby,
            public_cloud     use;

可用性ゾーン1側のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系の可用性ゾーン2側では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name           /users/server1,
       alias          server1,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol01,
       fs_name        /dev/Repvol01/lvol00,
       fs_mount_dir   /mnt/data1,
       rep_device     r1;

server name           /users/server2,
       alias          server2,
       acttype        server,
       patrol         60,
       initial        online,
       disk           /dev/Repvol02,
       fs_name        /dev/Repvol02/lvol00,
       fs_mount_dir   /mnt/data2,
       rep_device     r2;

可用性ゾーン1側のserver1.upファイルの設定

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

#!/bin/bash
set -x
　　　：
###############################################################################
LB_IPADDR[0]=10.2.12.100
LB_PORT[0]=50000

（以降省略）

可用性ゾーン1側のserver2.upファイルの設定

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

#!/bin/bash
set -x
　　　：
###############################################################################
LB_IPADDR[0]=172.16.10.100
LB_PORT[0]=50001

（以降省略）

可用性ゾーン1側のserver1.downファイルの設定

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

#!/bin/bash
set -x
　　　：
###############################################################################
LB_IPADDR[0]=10.2.12.100
LB_PORT[0]=50000

（以降省略）

可用性ゾーン1側のserver2.downファイルの設定

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

#!/bin/bash
set -x
　　　：
###############################################################################
LB_IPADDR[0]=172.16.10.100
LB_PORT[0]=50001

（以降省略）

可用性ゾーン1側のレプリケーションソフト（DRBD）の設定

/etc/drbd.d/global_common.conf

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

global {
  usage-count no;
}
common {
    handlers {
        fence-peer "/opt/hitachi/HAmon/bin/parts/monfence-peer.sh";
  　}
    options {
        auto-promote yes;
    }
    net {
        protocol C;
        fencing resource-and-stonith;
    }
    startup {
        wfc-timeout 30;
    }
}

/etc/drbd.d/r1.res

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

環境によってOS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/sdaなどへのシンボリックリンクファイル）を指定することをお勧めします。

resource r1 {
    volume 0 {
        device    /dev/drbd1;
        disk  /dev/disk/by-id/scsi-3600224809eb108af1253c92ea220a808;
        meta-disk internal;
    }
    on host1 {
        address   172.16.11.101:7789;
    }
    on host2 {
        address   172.16.11.102:7789;
    }
}

/etc/drbd.d/r2.res

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

環境によって，OS起動ごとにデバイス名が変わる場合があるため，常に同じディスクを示すように/dev/disk/by-id/下のシンボリックリンクファイル（実デバイス/dev/sdbなどへのシンボリックリンクファイル）を指定することをお勧めします。

resource r2 {
    volume 1 {
        device    /dev/drbd2;
        disk  /dev/disk/by-id/scsi-360022480a4bd74aa688769bacd682e04;
        meta-disk internal;
    }
    on host1 {
        address   172.16.11.101:7790;
    }
    on host2 {
        address   172.16.11.102:7790;
    }
}

connectionファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/connection）

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

host1    LAN    172.16.12.101;
host2    LAN    172.16.12.102;

サービスプリンシパル情報設定ファイルの設定（定義ファイル：/opt/hitachi/HAmon/etc/azure_serviceprincipal.env）

現用系の可用性ゾーン1側と予備系の可用性ゾーン2側は同じ内容になります。

appId=2450046d-a6d5-41b6-9d70-4970af56cc07
fileWithCertAndPrivateKey=/root/tmpnoh4k0r1.pem
tenant=f54277c9-dafe-44aa-85a4-73d5c7c52450

7.4.3　【OCI】HAモニタを使用する場合の構成

OCIを使用する場合の，環境設定例で示すシステム構成例を，次の図に示します。

図7‒7　OCIを使用する場合の構成

VCNのCIDRブロックは172.16.0.0/16です。

サブネットのCIDRブロックは172.16.12.0/24です。

このシステム構成のVNICの情報を次の表に示します。なお，host3およびhost4のVNICの情報については省略します。

表7‒47　VNICの情報

VNIC

プライベートIP

OCID

説明

VNIC1-1

172.16.12.101

ocid1.instance.oc1.ap-tokyo-1.aaaa

現用系 サーバ1用VNIC

VNIC1-2

172.16.12.102

ocid1.instance.oc1.ap-tokyo-1.bbbb

現用系 サーバ2用VNIC

VNIC1-3

172.16.12.103

ocid1.instance.oc1.ap-tokyo-1.cccc

現用系 監視パス用VNIC

VNIC2-1

172.16.12.201

ocid1.instance.oc1.ap-tokyo-1.dddd

予備系 サーバ1用VNIC

VNIC2-2

172.16.12.202

ocid1.instance.oc1.ap-tokyo-1.eeee

予備系 サーバ2用VNIC

VNIC2-3

172.16.12.203

ocid1.instance.oc1.ap-tokyo-1.ffff

予備系 監視パス用VNIC

このシステム構成の，サーバへの通信に用いる，現用系および予備系を制御するプライベートIPアドレスの情報を次の表に示します。

表7‒48　現用系および予備系を制御するプライベートIPアドレスの情報

プライベートIPアドレス

割り当てるNIC

割り当てるVNIC

説明

172.16.12.10

NIC1-1/NIC2-1

VNIC1-1/VNIC2-1

サーバ1への通信に用いるプライベートIPアドレス。

host1が実行系の場合は，NIC1-1とVNIC1-1に割り当てられています。

host2が実行系の場合は，NIC2-1とVNIC2-1に割り当てられています。

172.16.12.20

NIC1-2/NIC2-2

VNIC1-2/VNIC2-2

サーバ2への通信に用いるプライベートIPアドレス。

host1が実行系の場合は，NIC1-2とVNIC1-2に割り当てられています。

host2が実行系の場合は，NIC2-2とVNIC2-2に割り当てられています。

このシステム構成のHAモニタの情報を次の表に示します。

表7‒49　HAモニタの情報

系

項目

設定値

現用系

ホスト名

host1

ホストアドレス

101

監視パスのホスト名

path11

監視パスのIPアドレス

172.16.12.103

監視パスのサービス名

HAmon1

系障害監視時間

60

予備系

ホスト名

host2

ホストアドレス

102

監視パスのホスト名

path21

監視パスのIPアドレス

172.16.12.203

監視パスのサービス名

HAmon1

系障害監視時間

60

このシステム構成のサーバ1の情報を次の表に示します。

表7‒50　サーバ1の情報

系

項目

設定値

現用系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server1

サーバ識別名

server1

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のサーバ2の情報を次の表に示します。

表7‒51　サーバ2の情報

系

項目

設定値

現用系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

online

予備系

プログラム名

/users/server2

サーバ識別名

server2

サーバ障害監視時間

60

起動方法

server

起動種別

standby

このシステム構成のブロック・ボリュームの情報を次の表に示します。

表7‒52　ブロック・ボリュームの情報

ブロック・ボリューム

項目

設定値

ブロック・ボリューム1（サーバ1用）

パーティション

/dev/sdf1

物理ボリューム

/dev/sdf1

ボリュームグループ

vg01

ボリュームグループの絶対パス

/dev/vg01

論理ボリューム

lvol01

論理ボリュームの絶対パス

/dev/vg01/lvol01

マウントディレクトリ

/mnt/data1

ブロック・ボリューム2（サーバ2用）

パーティション

/dev/sdg1

物理ボリューム

/dev/sdg1

ボリュームグループ

vg02

ボリュームグループの絶対パス

/dev/vg02

論理ボリューム

lvol01

論理ボリュームの絶対パス

/dev/vg02/lvol01

マウントディレクトリ

/mnt/data2

このシステム構成での環境設定例を次に示します。

現用系のHAモニタの環境設定（定義ファイル：/opt/hitachi/HAmon/etc/sysdef）

予備系では，nameオペランド，addressオペランド，およびlanオペランドに，予備系側の値を設定してください。

/* HAモニタの環境設定 */
environment name         host1,
            address      101,
            patrol       60,
            lan          path11,
            lanport      HAmon1;
function    cpudown      standby,
            public_cloud use;

現用系のサーバ対応の環境設定（定義ファイル：/opt/hitachi/HAmon/etc/servers）

予備系では，initialオペランドにstandbyを設定してください。

/* サーバ対応の環境設定 */
server name         /users/server1,
       alias        server1,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg01,
       fs_name      /dev/vg01/lvol01,
       fs_mount_dir /mnt/data1;

server name         /users/server2,
       alias        server2,
       acttype      server,
       patrol       60,
       initial      online,
       disk         /dev/vg02,
       fs_name      /dev/vg02/lvol01,
       fs_mount_dir /mnt/data2;

現用系のserver1.upファイルの設定

予備系では，PIP_VNIC[0]にVNIC2-1のOCID，PIP_LABEL[0]にNIC2-1のラベルを設定してください。

#!/bin/bash
set -x
      :(省略)
##############################################################################
PIP_ADDRESS[0]=172.16.12.10
PIP_VNIC[0]=ocid1.instance.oc1.ap-tokyo-1.aaaa
PIP_LABEL[0]=NIC1-1:0
      :(以降省略)

現用系のserver2.upファイルの設定

予備系では，PIP_VNIC[0]にVNIC2-2のOCID，PIP_LABEL[0]にNIC2-2のラベルを設定してください。

#!/bin/bash
set -x
      :(省略)
##############################################################################
PIP_ADDRESS[0]=172.16.12.20
PIP_VNIC[0]=ocid1.instance.oc1.ap-tokyo-1.bbbb
PIP_LABEL[0]=NIC1-2:0
      :(以降省略)

現用系のserver1.downファイルの設定

予備系では，PIP_VNIC[0]にVNIC2-1のOCID，PIP_LABEL[0]にNIC2-1のラベルを設定してください。

#!/bin/bash
set -x
      :(省略)
##############################################################################
PIP_ADDRESS[0]=172.16.12.10
PIP_VNIC[0]=ocid1.instance.oc1.ap-tokyo-1.aaaa
PIP_LABEL[0]=NIC1-1:0
      :(以降省略)

現用系のserver2.downファイルの設定

予備系では，PIP_VNIC[0]にVNIC2-2のOCID，PIP_LABEL[0]にNIC2-2のラベルを設定してください。

#!/bin/bash
set -x
      :(省略)
##############################################################################
PIP_ADDRESS[0]=172.16.12.20
PIP_VNIC[0]=ocid1.instance.oc1.ap-tokyo-1.bbbb
PIP_LABEL[0]=NIC1-2:0
      :(以降省略)

8　コマンド

この章では，パブリッククラウド環境下のHAモニタで使用するコマンドについて説明します。なお，この章はマニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「コマンド」とあわせてお読みください。

8.1　パブリッククラウド環境で注意が必要なコマンド

ここでは，パブリッククラウド環境下でHAモニタを使用する場合に，注意が必要なコマンドについてだけ記載します。各コマンドの詳細については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「コマンド」の説明を参照してください。

パブリッククラウド環境で注意が必要なコマンドについて，次の表に示します。

表8‒1　パブリッククラウド環境で注意が必要なコマンド

コマンド名

注意事項

monchange

HAモニタエージェントを使用した構成の場合，次の点に注意してください。

HAモニタエージェントでは実行できません。実行しようとすると，メッセージKAMN129-Eが出力されて失敗します。

HAモニタエージェントと接続したHAモニタでは-m patrolオプションは実行できません。実行しようとすると，メッセージKAMN282-Eが出力されて失敗します。

moncheck

パブリッククラウドでない環境でチェックする定義に加え，次の定義もチェックします。

public_cloudオペランド

rep_deviceオペランド

詳細は，「8.1.1　moncheck（定義チェック）」を参照してください。

monlink

HAモニタエージェントを使用した構成の場合，HAモニタエージェントでは実行できません。実行しようとすると，メッセージKAMN129-Eが出力されて失敗します。

monlistip

パブリッククラウド環境下では，このコマンドを使用しないでください。

monpath

HAモニタエージェントを使用した構成の場合，次の点に注意してください。

HAモニタエージェントの監視パスの状態は表示しません。

HAモニタエージェントでは実行できません。実行しようとすると，メッセージKAMN129-Eが出力されて失敗します。

HAモニタエージェントは監視パスを複線化できないため，このコマンドで複数の監視パスの状態を確認する必要はありません。HAモニタエージェントとHAモニタ間の接続を確認したい場合は，monshow -cコマンドを使用してください。

monrp

パブリッククラウド環境下では，このコマンドを使用しないでください。

monscsiclr

パブリッククラウド環境下では，このコマンドを使用しないでください。

monsetup

パブリッククラウド環境下では，このコマンドでリセットパスの設定を実施しないでください。また，HAモニタエージェントを使用する構成の場合，どのHAモニタをHAモニタエージェントとして動作させるかを設定します。詳細は「8.1.2　monsetup（HAモニタの環境設定）」を参照してください。

monshow

パブリッククラウドでない環境で表示する項目に加え，次の項目も表示します。

レプリケーションデバイス名

また，HAモニタエージェントを使用した構成の場合，次の点が異なります。

系の状態表示では，HAモニタエージェントはホスト名の後ろに「AGT」が付与され，最初の行に表示されます。

–agtオプションでHAモニタエージェントの通信状態を表示します。

詳細は，「8.1.3　monshow（サーバと系の状態表示）」を参照してください。

8.1.1　moncheck（定義チェック）

パブリッククラウド環境下のmoncheckコマンドでは，パブリッククラウドでない環境でチェックする定義に加え，次の項目もチェックします。

必要なシェルスクリプト群を展開しているかどうか。

HAモニタの環境設定のpublic_cloudオペランドにuseが指定されていて，かつ必要なシェルスクリプト群が展開されていない場合には，メッセージKAMN764-Eを出力します。

サーバ対応の環境設定のrep_deviceオペランドにリソースが指定されていて，かつ必要なシェルスクリプト群が展開されていない場合には，メッセージKAMN764-Eを出力します。

シェルスクリプト群については，「5.8　【AWS】AWS用のシェルスクリプト群の展開」，「5.9　【Azure】Azure用のシェルスクリプト群の展開」，または「5.10　【OCI】OCI用のシェルスクリプト群の展開」を参照してください。

次のリソースがあるかどうか。

サーバ対応の環境設定のrep_deviceオペランドに指定したリソース

AWS環境の場合で，サーバ対応の環境設定のfs_nameオペランドに指定したEFSリソース

このリソースがない場合は，" not available "が表示されます。

moncheckコマンドで有無をチェックするリソースとnot availableが表示された場合の意味を，次に示します。

表8‒2　moncheckコマンドで有無をチェックするリソースとnot availableが表示された場合の意味

有無をチェックするリソース

not availableが表示された場合の意味

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

lan_agentオペランド

指定したホスト名称が/etc/hostsファイルに定義されていない。

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

rep_deviceオペランド

指定されたリソースが存在しない。

DRBDがインストールされていない。

DRBDが起動されていない。

fs_nameオペランド

AWS環境下でEFSのDNS名を指定した場合に，次のどれかに該当している。

指定したDNS名のEFSが存在しない。

DNSサーバに問い合わせできない。

bind-utilsパッケージがインストールされていない。

AWS CLIがインストール・設定されていない。

なお，moncheckコマンドの詳細およびその他のチェック項目については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「moncheck（定義チェック）」の説明を参照してください。

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

AWS環境下でHAモニタエージェントを使用する構成の場合，HAモニタエージェントを動作させたい系でmonsetupコマンドを実行して，次の設定をしてください。HAモニタを動作させる系では設定不要です。

エージェントモードの設定

形式，機能，オプション，注意事項，および使用例について以降に示します。

形式

monsetup -agent [{on|off} [noreload]]

機能

HAモニタをエージェントモードとして動作させるかを設定します。デフォルトでは，エージェントモードとして動作しません。

また，エージェントモードの設定状態を表示します。

オプション

-agent

HAモニタエージェントを使用する構成の場合，HAモニタエージェントとして動作させる系を指定します。デフォルトでは，エージェントモードとして動作しません。

また，以降に説明する引数のon，offを省略した場合，エージェントモードの設定状態を表示します。

on

エージェントモードをオンにします。エージェントモードをオンにすると，HAモニタエージェントとして動作します。

エージェントモードがオフの場合にmonsetup -agent onコマンドを実行すると，次のことが実施されます。すでにエージェントモードがオンの場合は実施されません。

・Unit設定ファイルがHAモニタエージェント用のファイルに置き換えられます。

・Unit設定ファイルが置き換えられたあと，systemctl enableコマンドによるサービス有効化，およびsystemctl daemon-reloadコマンドによるUnit設定ファイルが再読み込みされます。再読み込みしたくない場合は，以降に説明するnoreloadオプションを指定してください。

off

エージェントモードをオンからオフに戻します。エージェントモードをオフにすると，HAモニタとして動作します。

エージェントモードがオンの場合にmonsetup -agent offコマンドを実行すると，次のことが実施されます。すでにエージェントモードがオフの場合は実施しません。

・Unit設定ファイルがHAモニタ用のファイルに置き換えられます。

・Unit設定ファイルが置き換えられたあと，systemctl enableコマンドによるサービス有効化，およびsystemctl daemon-reloadコマンドによるUnit設定ファイルが再読み込みされます。再読み込みしたくない場合は，以降に説明するnoreloadオプションを指定してください。

noreload

systemctl daemon-reloadコマンドを実行しません。

注意事項

Unit設定ファイルを/etc/systemd/system配下にコピーして編集する場合は，このコマンド実行後に実施してください。

/etc/systemd/system配下にHAmon-powercontrol.serviceファイルが存在する場合は，メッセージKAMN456-Eが出力され，コマンドの実行に失敗します。

使用例

エージェントモードの設定状態の表示

> monsetup -agent
agent : off

（凡例）　>：ユーザの操作を示します。

エージェントモードの有効化の設定

> monsetup -agent on
agent : on

（凡例）　>：ユーザの操作を示します。

エージェントモードの無効化の設定

> monsetup -agent off
agent : off

（凡例）　>：ユーザの操作を示します。

なお，monsetupコマンドの詳細およびその他の設定については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「monsetup（HAモニタの環境設定）」の説明を参照してください。

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

パブリッククラウド環境のmonshowコマンドでは，パブリッククラウドでない環境で表示する項目に加え，次の項目も表示します。

レプリケーションデバイス名

使用例について，次に示します。

共有リソース情報の表示

> monshow -d
KAMN213-I Own host name : host1
 Server  :  server1
    ***   DISK   information   ***
    -NAME----------------------------
      /dev/sharedvg
        neck
        on_opt="-u -n"
        forced varyon
     ***   LA     information   ***
     -NAME----------------------------
     LADP01
     ***   Line Switch information  ***
     -NAME---------------id----port---
      /dev/tty2         001   A
     ***   File system information  ***
     -NAME----------------------------
      /dev/sharedlv1
       mount dir=/test01
       mount opt=-o rw,log=/dev/jfsloglv
     ***   HABST  information   ***
     -NAME----------------------------
      0
     ***   SCSI device information  ***
     -NAME----------------------------
      /dev/hdisk1
      /dev/hdisk2
      /dev/dlmfdrv1
     *** replication device information ***
     -NAME----------------------------
      r0
      r1

（凡例）　>：ユーザの操作を示します。

また，HAモニタエージェントを使用した構成の場合，次の項目も変更があります。

「系の状態表示」にHAモニタエージェントの情報が追加

「HAモニタエージェントの通信状態の表示」の追加

それぞれの項目について説明します。

「系の状態表示」にHAモニタエージェントの情報が追加

HAモニタエージェントを使用した構成の場合に，monshow -cで「系の状態表示」を実行したときは，HAモニタエージェントにはホスト名の後ろに「(AGT)」を付与して最初の行に表示されます。

使用例を次に示します。

系の状態表示（HAモニタエージェントがある場合）

> monshow -c
KAMN335-I Connected host information
     Host name                           Host address     Patrol time
     Hostagt(AGT)                             9999             60
     host1                                     100             60
     host2                                     200             60

「HAモニタエージェントの通信状態の表示」の追加

–agtオプションを使用して，「HAモニタエージェントの通信状態の表示」が実行できます。このオプションは，HAモニタエージェントだけで実行できます。形式は次のとおりです。

monshow –agt

このコマンドでは，HAモニタエージェントがHAモニタから受信するヘルスチェックメッセージの受信数を表示します。表示する項目は次のとおりです。

ポート番号（HA）

系切り替え構成を識別するポート番号です。HAモニタの環境設定のlanportオペランドに指定したサービス名に対応したポート番号※です。

注※　/etc/servicesファイルに指定したサービス名のポート番号

AZ名（AZ:）

HAモニタが配置されているAWS VPCのアベイラビリティーゾーンの名称です。

HAモニタのアドレス（Address）

HAモニタの環境設定のaddressオペランドで指定したアドレスです。

ヘルスチェックメッセージの受信数（recv）

HAモニタエージェントがHAモニタから受信したヘルスチェックメッセージの受信数を表示します。受信数は，コマンド実行時からさかのぼって1分間の受信数を表示します。

使用例を次に示します。

HAモニタエージェントの通信状態の表示

> monshow -agt
KAMN551-I Health Check HA to Agent
      HA    AZ:ap-northeast-1a   AZ:ap-northeast-1c
            Address    recv      Address    recv
    15001     1001      600        1003      600
              1002      600        1004      600
    15002     2001      600        2003      420
              2002      600        2004      420
    15003     3001      600        3003      300
              3002      600        3004      300
    15004     4001      600        4003        0
              4002      600        4004        0

なお，monshowコマンドの詳細およびその他の表示項目については，マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「monshow（サーバと系の状態表示）」の説明を参照してください。

付録

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

マニュアル高信頼化システム監視機能 HAモニタ Linux(R)（x86）編の「HAモニタが出力するファイル一覧」を参照してください。ここでは，HAモニタが出力するファイル一覧について，パブリッククラウド環境下で差異がある事項だけを記載します。

HAモニタが出力するファイルの一覧を，次の表に示します。

なお，ファイルパス名に記載している，history，etc，またはspoolで始まるパスは，/opt/hitachi/HAmon配下を表しています。

表A‒1　HAモニタが出力するファイルの一覧

項番

名称

ファイルパス名

生成・削除タイミング

管理方法

サポートバージョン

形式

最大ファイルサイズ（バイト）

運用による削除可能なspoolファイル※1

1

インスタンスID取得ログ

spool/cloud/moncld_getinf.log

HAモニタ起動時，または起動時取得失敗後の定期実行（60秒間隔）時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

2

spool/cloud/moncld_getinf.log_err

○

3

インスタンス強制停止実行ログ

AWSの場合

spool/cloud/moncld_fstop_強制停止対象インスタンスID.log

Azureの場合

spool/cloud/moncld_fstop_強制停止対象仮想マシンのリソースID.log

OCIの場合

spool/cloud/moncld_fstop_強制停止対象インスタンスのOCID.log

系のリセット（インスタンス強制停止）時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

4

インスタンス起動実行ログ

AWSの場合

spool/cloud/moncld_start_起動対象インスタンスID.log

Azureの場合

spool/cloud/moncld_start_起動対象仮想マシンのリソースID.log

OCIの場合

spool/cloud/moncld_start_起動対象インスタンスのOCID.log

系のリセット（インスタンス強制停止）後の起動時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

5

クラウド操作定期確認ログ

spool/cloud/moncld_polling_.log

HAモニタ起動時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

6

spool/cloud/moncld_polling_.log_err

AWS CLI，Azure CLI，またはOCI CLI実行可否チェックの定期実行で正常だったあとに，異常が検出された場合

1世代管理

○

7

spool/cloud/moncld_polling_.log_recover

AWS CLI，Azure CLI，またはOCI CLI実行可否チェックの定期実行で異常が検出されたあとに，正常だった場合

○

8

レプリケーションパス切断時のフェンシング実行ログ

spool/rep/monfence-peer_rep_device名,IPアドレス.log

レプリケーションパス切断検知時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

9

プライマリ化抑止ログ

spool/rep/monrep_ctl_rep_device名.log

待機サーバ起動時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

10

spool/rep/monrep_ctl_rep_device名,IPアドレス.log

レプリケーションパス切断検知時

○

11

rep_device定義チェックログ

spool/rep/monrep_chk_rep_device名.log

定義チェックコマンド（moncheckコマンド）実行時，およびサーバ起動時

_oldの2世代管理

01-70

以降

テキスト

10,485,760

○

12

【Azure】

クラウド後処理実行ログ

spool/cloud/moncld_endproc.log

HAモニタ停止時

_oldの2世代管理

01-71

以降

テキスト

10,485,760

○

13

vip_tgw_defファイルのフォーマットチェックログ

spool/cloud/moncld_defchk.log

moncheckコマンド実行時に，vip_tgw_defファイルのフォーマットが正常だった場合

_oldの2世代管理

01-73

以降

テキスト

10,485,760

○

spool/cloud/moncld_defchk.log_err

moncheckコマンド実行時に，vip_tgw_defファイルのフォーマットがエラーだった場合

1世代管理

spool/cloud/サーバ識別名_moncld_defchk.log

サーバの起動時および停止時に，vip_tgw_defファイルのフォーマットが正常だった場合

_oldの2世代管理

spool/cloud/サーバ識別名_moncld_defchk.log_err

サーバの起動時および停止時に，vip_tgw_defファイルのフォーマットがエラーだった場合

1世代管理

14

ネットワーク遮断実行ログ

spool/cloud/moncld_fencectl_ネットワーク遮断対象インスタンスID.log

系切り替え時

_oldの2世代管理

01-75

以降

テキスト

10,485,760

○

spool/cloud/moncld_fencenw_ネットワーク遮断対象インスタンスID.log

spool/cloud/moncld_unfencenw_ネットワーク遮断対象インスタンスID.log

15

ネットワーク遮断設定ファイルチェックログ

spool/cloud/moncld_nwdefchk.log

moncheckコマンド実行時

montsコマンド実行時

HAモニタ起動時

_oldの2世代管理

01-75

以降

テキスト

10,485,760

○

spool/cloud/moncld_nwdefchk.log_err

16

ENI情報ファイル

spool/cloud/.awseniinf

HAモニタ起動時

1世代管理

01-75

以降

テキスト

570

×

17

ENIアタッチツールログ

spool/cloud/awseniattchtool.log

ENIアタッチツール実行時

_oldの2世代管理

01-75

以降

テキスト

変動値※2

○

18

EFS存在チェックログ

spool/cloud/moncld_fsdefchk.log

ファイルシステムにEFSを使用する場合の，moncheck/montsコマンド実行時

_oldの2世代管理

01-78

以降

テキスト

10,485,760

○

spool/cloud/moncld_fsdefchk.log_err

ファイルシステムにEFSを使用する場合の，moncheck/montsコマンド実行時

（異常検出時）

_oldの2世代管理

01-78

以降

テキスト

10,485,760

○

19

NMI発行ログ

spool/cloud/moncld_nmi_NMI発行対象インスタンスID.log

Linux Tough Dumpと連携している場合に系障害を検知したときの，障害系へのNMI発行時

_oldの2世代管理

01-79

以降

テキスト

10,485,760

○

spool/cloud/moncld_nmi_NMI発行対象インスタンスID.log_err

Linux Tough Dumpと連携している場合に系障害を検知したときの，障害系へのNMI発行時

（異常検出時）

1世代管理

01-79

以降

テキスト

10,485,760

○

20

HVRDネットワークチェックログ

spool/HVRD_checklog

HVRDのレプリケーション中断時

.bakの2世代管理

01-80

以降

テキスト

変動値

○

（凡例）

○：削除できます。

×：削除できません。

注※1

HAモニタを停止してから削除してください。また，ディレクトリは削除しないでください。

注※2

処理対象のENIの数によって最大ファイルサイズは変化します。

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

各バージョンの変更内容を示します。

付録B.1　HAモニタ 01-79の変更内容（3000-9-204-80）

HAモニタ 01-79の変更内容（3000-9-204-80）を次の表に示します。

追加・変更内容

AWS環境の場合に，Linux Tough Dumpと連携できるようにした。

これに伴い，次のオペランドを追加した。

HAモニタの環境設定

lanport_ltd

適用OSにOracle Linux 9(x86_64)を追加した。

付録B.2　HAモニタ 01-78の変更内容（3000-9-204-70）

HAモニタ 01-78の変更内容（3000-9-204-70）を次の表に示します。

追加・変更内容

AWS環境の場合に，EFSを使用した共有ディスク構成にできるようにした。

適用OSにRHEL9を追加した。

付録B.3　HAモニタ 01-77の変更内容（3000-9-204-60）

HAモニタ 01-77の変更内容（3000-9-204-60）を次の表に示します。

追加・変更内容

Azureの場合に，マネージドディスクの共有による共有ディスク構成をサポートした。

Amazon EC2のインスタンスメタデータサービスバージョン2（IMDSv2）をサポートした。

インスタンスのメタデータ取得のための設定について，説明を変更した。

付録B.4　HAモニタ 01-76，HAモニタ 01-75の変更内容（3000-9-204-50）

HAモニタ 01-76の変更内容（3000-9-204-50）を次の表に示します。

追加・変更内容

AWSの場合に，EBSマルチアタッチ機能を使用した共有ディスク構成をサポートした。

HAモニタ 01-75の変更内容（3000-9-204-50）を次の表に示します。

追加・変更内容

AWSの場合に，系切り替えの方法としてネットワーク遮断による系切り替えをサポートした。

付録B.5　HAモニタ 01-74の変更内容（3000-9-204-40）

HAモニタ 01-74の変更内容（3000-9-204-40）を次の表に示します。

追加・変更内容

適用OSにOracle Linux 7(x86_64)，Oracle Linux 8(x86_64)を追加した。

使用できるパブリッククラウドとしてOCIをサポートした。

付録B.6　HAモニタ 01-73の変更内容（3000-9-204-30）

HAモニタ 01-73の変更内容（3000-9-204-30）を次の表に示します。

追加・変更内容

AWS環境下で，複数のリージョン間や複数のVPC間での系切り替えをできるようにした。

付録B.7　HAモニタ 01-72の変更内容（3000-9-204-20）

HAモニタ 01-72の変更内容（3000-9-204-20）を次の表に示します。

追加・変更内容

HAモニタの環境設定のpublic_cloudオペランドにuseを指定した場合の，次のオペランドの注意事項を追記した。

HAモニタの環境設定のclearwaitオペランド

HAモニタの環境設定のclearcheckオペランド

付録B.8　HAモニタ 01-71の変更内容（3000-9-204-10）

HAモニタ 01-71の変更内容（3000-9-204-10）を次の表に示します。

追加・変更内容

適用OSを追加・削除した。

RHEL8を追加した。

RHEL5を削除した。

使用できるパブリッククラウドとしてAzureをサポートした。

AWS環境下の通信制御の方式に，DNS名制御による業務通信の切り替えを追加した。

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

このマニュアルを読むに当たっての参考情報を示します。

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

HAモニタのマニュアル体系を次に示します。

HAモニタのマニュアル以外で，このマニュアルと関連するマニュアルを次に示します。必要に応じてお読みください。

プログラムにOpenTP1を使用する場合

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 9 解説（3020-6-450）

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 10 解説（3020-6-551）

HiRDB Version 10 システム導入・設計ガイド（UNIX(R)用）（3020-6-552）

HiRDB Version 10 システム定義（UNIX(R)用）（3020-6-554）

HiRDB Version 10 システム運用ガイド（UNIX(R)用）（3020-6-556）

HiRDB Version 10 コマンドリファレンス（UNIX(R)用）（3020-6-558）

HiRDB Version 10 メッセージ（3020-6-562）

イベント管理によってシステムの運用を自動化する場合

JP1 Version 11 JP1/Base 運用ガイド（3021-3-A01）

JP1 Version 11 JP1/Base メッセージ（3021-3-A02）

JP1 Version 12 JP1/Base 運用ガイド（3021-3-D65）

JP1 Version 12 JP1/Base メッセージ（3021-3-D66）

JP1 Version 13 JP1/Base 運用ガイド（3021-3-L09）

JP1 Version 13 JP1/Base メッセージ（3021-3-L10）

ディスクパスを冗長化する場合

Hitachi Dynamic Link Manager Software ユーザーズガイド（Linux(R)用）（3000-3-F04）

N+Mコールドスタンバイ構成で系切り替えをする場合

Hitachi Command Suite Compute Systems Manager Software ユーザーズガイド（3020-3-V91）

Hitachi Command Suite Compute Systems Manager ユーザーズガイド（3021-9-096）

なお，このマニュアルでは，次のマニュアルを省略して表記しています。マニュアルの正式名称とこのマニュアルでの表記を次の表に示します。

このマニュアルでの表記

マニュアルの正式名称

JP1/Base 運用ガイド

JP1 Version 11 JP1/Base 運用ガイド

JP1 Version 12 JP1/Base 運用ガイド

JP1 Version 13 JP1/Base 運用ガイド

分散トランザクション処理機能 OpenTP1 システム定義

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 システム定義

分散トランザクション処理機能 OpenTP1 運用と操作

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 運用と操作

分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引

OpenTP1 Version 7 分散トランザクション処理機能 TP1/Server Base Enterprise Option 使用の手引

HiRDB システム定義

HiRDB Version 9 システム定義（UNIX(R)用）

HiRDB Version 10 システム定義（UNIX(R)用）

HiRDB システム運用ガイド

HiRDB Version 9 システム運用ガイド（UNIX(R)用）

HiRDB Version 10 システム運用ガイド（UNIX(R)用）

付録C.2　このマニュアルで使用する製品名・機能名

このマニュアルでは，製品名を次のように表記しています。

表記

製品名

AWS

Amazon Web Services

Azure

Microsoft Azure

HiRDB

HiRDB Version 9

HiRDB Accelerator Version 9

HiRDB Advanced High Availability Version 9

HiRDB Server Version 9

HiRDB Server with Additional Function Version 9

HiRDB Version 10

HiRDB Accelerator Version 10

HiRDB Advanced High Availability Version 10

HiRDB Server Version 10

HVRD

Hitachi Volume Replication Driver for Linux

Linux

Linux

Linux

Linux（x86）

Oracle Linux 7(x86_64)

Oracle Linux 8(x86_64)

Oracle Linux 9(x86_64)

Red Hat Enterprise Linux server 7(x86_64)

Red Hat Enterprise Linux server 8(x86_64)

Red Hat Enterprise Linux server 9(64-bit x86_64)

RHEL7

Red Hat Enterprise Linux server 7(x86_64)

RHEL8

Red Hat Enterprise Linux server 8(x86_64)

RHEL9

Red Hat Enterprise Linux server 9(64-bit x86_64)

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/XTC

TP1/EE/Extended Transaction Controller

UNIX

UNIX

VMware ESXi

VMware ESXi(TM)

VMware vSphere(R) ESXi(TM)

付録C.3　このマニュアルで使用する英略語

このマニュアルで使用する英略語を，次に示します。

英略語

英字での表記

CLI

Command Line Interface

DNS

Domain Name System

DRBD

Distributed Replicated Block Device

I/O

Input/Output

LAN

Local Area Network

LVM

Logical Volume Manager

NLB

Network Load Balancer

OCI

Oracle Cloud Infrastructure

OS

Operating System

PC

Personal Computer

SCSI

Small Computer System Interface

TCP/IP

Transmission Control Protocol/Internet Protocol

UAP

User Application Program

付録C.4　このマニュアルで使用するKB（キロバイト）などの単位表記

1KB（キロバイト），1MB（メガバイト），1GB（ギガバイト），1TB（テラバイト）はそれぞれ1,024バイト，1,024²バイト，1,024³バイト，1,024⁴バイトです。

索引

記号

/etc/hostsファイルの永続化[1]

数字

1:1系切り替え構成（AWS）[1]

1:1系切り替え構成（Azure）[1]

A

agt_split_time[1]

AWS CLIのインストール・設定[1]

AWS CLIの実行可否チェックの設定[1]

AWS環境でHAモニタを使用する場合の構成[1]

AWSでの通信経路の制御

DNS名制御[1]

EIP制御[1]

VIP制御[1], [2], [3], [4], [5]

AWSの設定[1]

EBSマルチアタッチの設定[1]

EFSの設定[1]

ENIの設定[1]

インスタンスのメタデータ取得のための設定[1]

エンドポイントの設定[1]

プロキシを使用する場合の設定[1]

Azure CLIのインストール・設定[1]

Azure DNSの設定[1]

Azure ロードバランサー制御[1]

Azure ロードバランサーの作成・設定[1]

Azure環境でHAモニタを使用する場合の構成[1]

Azureでの通信経路の制御

Azure ロードバランサー制御[1]

DNS名制御による業務通信の切り替え[1]

Azureの設定[1]

Azure CLIのインストール・設定[1]

Azure DNSの設定[1]

Azure ロードバランサーの作成・設定[1]

インスタンスのメタデータ取得のための設定[1]

プロキシを使用する場合の設定[1]

AZが通信不調であると判定したあとの動作[1]

C

CLI実行可否チェック[1]

D

DNS名制御[1]

DRBD[1]

E

EBSマルチアタッチの設定[1]

EFSの設定[1]

EIP制御[1]

ENIの設定[1]

environment定義文[1]

F

fence_network[1]

function定義文[1]

H

HAモニタエージェントで指定可能なHAモニタの環境設定のオペランド（AWS）[1]

HAモニタエージェントを使用したエージェントヘルスチェック機能（AWS）[1]

HAモニタエージェントを使用したエージェントヘルスチェック機能を使用する場合の環境設定例[1]

HAモニタエージェントを使用する場合の系の孤立見なし（AWS）[1]

HAモニタが系切り替えをする条件[1]

HAモニタが検出する障害[1]

HAモニタで使用できる機能一覧[1]

HAモニタによる障害検出[1]

HAモニタの環境設定[1]

agt_split_time[1]

fence_network[1]

HAモニタエージェントで指定可能なHAモニタの環境設定のオペランド（AWS）[1]

lan_agent[1]

lanport_agent[1]

lanport_ltd[1]

public_cloud[1]

パブリッククラウド環境固有のHAモニタの環境設定[1]

パブリッククラウド環境で注意が必要なHAモニタの環境設定のオペランド[1]

HAモニタの環境設定〔コマンド〕[1]

HAモニタの動作環境[1]

HVRD[1]

HVRDのレプリケーション断発生時の判定[1]

HVRD連携構成[1]

HVRD連携時の注意事項[1]

L

lan_agent[1]

lanport_agent[1]

lanport_ltd[1]

LANの監視に必要なファイルの設定[1]

LANの管理（AWS）[1], [2]

LANの管理（Azure）[1]

LANの状態設定ファイルの設定（AWS）

1つのVPC内で系切り替えをする場合の設定[1]

1つのリージョン内で系切り替えをする場合の設定[1]

クライアントからの通信がAWS Network Firewallを経由する場合の設定[1]

クライアントからの通信がNLBを経由する構成の場合の設定[1]

複数のVPC間で系切り替えをする場合の設定[1]

複数のVPC間で系切り替えをする場合の設定（DNS制御の場合）[1]

複数のVPC間で系切り替えをする場合の設定（VIP制御の場合）[1], [2], [3]

複数のリージョン間で系切り替えをする場合の設定[1]

複数のリージョン間で系切り替えをする場合の設定（DNS制御の場合）[1]

複数のリージョン間で系切り替えをする場合の設定（VIP制御の場合）[1], [2], [3]

LANの状態設定ファイルの設定（Azure）[1]

LANの状態設定ファイルの設定（OCI）[1]

M

moncheck[1]

monsetup[1]

monshow[1]

O

OCI CLIのインストール・設定[1]

OCI環境でHAモニタを使用する場合の構成[1]

OCIでの通信経路の制御

プライベートIPアドレス制御[1]

OCIの設定[1]

/etc/hostsファイルの永続化[1]

OCI CLIのインストール・設定[1]

インスタンスのメタデータ取得のための設定[1]

エンドポイントの設定[1]

プロキシを使用する場合の設定[1]

ブロック・ボリュームの設定[1]

P

public_cloud[1]

R

rep_device[1]

resource定義文[1]

S

server_aws_vpc.down[1], [2], [3], [4], [5]

server_aws_vpc.up[1], [2], [3], [4], [5]

server_aws.down[1], [2]

server_aws.up[1], [2]

server_azure.down[1]

server_azure.up[1]

server_oci.down[1]

server_oci.up[1]

server定義文[1]

V

vip_tgw_def[1], [2], [3], [4]

VIP制御[1], [2], [3], [4], [5]

1つのVPC内での系切り替え[1]

1つのリージョン内での系切り替え[1]

クライアントからの通信がAWS Network Firewallを経由[1]

クライアントからの通信がNLBを経由する構成[1]

複数のVPC間での系切り替え[1], [2], [3]

複数のリージョン間での系切り替え[1], [2], [3]

い

インスタンスのメタデータ取得のための設定[1], [2], [3]

え

エージェントヘルスチェック機能の設定[1]

エンドポイントの設定[1], [2]

か

環境構成例

AWS環境でHAモニタを使用する場合の構成[1], [2], [3], [4], [5]

Azure環境でHAモニタを使用する場合の構成[1]

OCI環境でHAモニタを使用する場合の構成[1]

クライアントからの通信がAWS Network Firewallを経由する場合の構成[1]

監視パスの設定[1]

き

起動・停止[1]

機能一覧[1]

業務ディスクの管理[1]

基本的な制御[1]

レプリケーションパス障害時の制御[1]

業務ディスクの設定[1]

共有ディスク構成の場合の環境設定例[1]

く

クライアントからの通信がAWS Network Firewallを経由する構成の場合の環境設定例[1]

け

系切り替え（AWS）[1]

系切り替え（Azure）[1]

系切り替え（OCI）[1]

系切り替えの方式[1]

系障害時の系切り替え（AWS）[1]

系障害時の系切り替え（Azure）[1]

系障害時の系切り替え（OCI）[1]

系障害の検出[1]

系の管理[1]

系のリセットによる系切り替え[1]

系のリセットによる系切り替えをする場合（レプリケーション構成）の環境設定例[1]

系のリセットまたはネットワーク遮断をする系の決定方法[1]

系のリセットまたはネットワーク遮断をする場合[1]

系やサーバを稼働させたままリソースの構成を変更する[1]

こ

構築の流れ[1]

このマニュアルの読み方[1]

コントロールプレーンのチェック[1]

さ

サーバが使用するリソースの設定[1]

サーバと系の状態表示〔コマンド〕[1]

サーバの環境設定[1], [2]

パブリッククラウド環境固有のサーバの環境設定[1]

パブリッククラウド環境で注意が必要なサーバ対応の環境設定のオペランド[1]

サーバを追加する[1]

サービスプリンシパル情報設定ファイルの設定（Azure）[1]

し

シェルスクリプト群の展開（AWS）[1]

シェルスクリプト群の展開（Azure）[1]

シェルスクリプト群の展開（DRBD）[1]

シェルスクリプト群の展開（OCI）[1]

事象ごとの動作[1]

システム運用時の注意事項[1]

システムの変更[1]

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

処理の流れ（AWS）[1]

処理の流れ（Azure）[1]

処理の流れ（OCI）[1]

て

定義チェック〔コマンド〕[1]

定義ファイルの概要[1]

定義ファイルの作成（HAモニタ）[1]

定常状態でのエージェントヘルスチェック[1]

ディスクをレプリケーションする構成[1]

ね

ネットワーク遮断設定ファイルの設定[1]

ネットワーク遮断による系切り替え[1]

ネットワーク遮断による系切り替えをする場合（レプリケーション構成）の環境設定例[1]

は

パブリッククラウド環境下のHAモニタ[1]

パブリッククラウド環境固有のHAモニタの環境設定[1]

パブリッククラウド環境固有のサーバの環境設定[1]

パブリッククラウド環境で注意が必要なHAモニタの環境設定のオペランド[1]

パブリッククラウド環境で注意が必要なコマンド[1]

パブリッククラウド環境で注意が必要なサーバ対応の環境設定のオペランド[1]

パブリッククラウド環境のコンソール操作（CLI発行含む）をする場合の注意事項[1]

ひ

必要なAWS環境[1]

必要なAzure環境[1]

必要なOCI環境[1]

必要なソフトウェア[1]

ふ

複数スタンバイ構成（AWS）[1]

複数スタンバイ構成（Azure）[1]

複数のVPC間での系切り替え

系切り替え時の動作[1]

ルーティングの動作[1]

複数の待機系がある場合の系のリセットまたはネットワーク遮断[1]

複数のリージョン間での系切り替え

系切り替え時の動作[1]

ルーティングの動作[1]

プライベートIPアドレス制御[1]

プロキシを使用する場合の設定[1], [2], [3]

ブロック・ボリュームの設定[1]

ま

マネージドディスクの共有[1]

り

リセットパスの設定[1]

リソースの監視のための設定[1]

リソースの管理[1]

リソースの引き継ぎ[1], [2], [3]

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

れ

レプリケーションソフト[1]

DRBD[1]

HVRD[1]

レプリケーションソフト（DRBD）の設定[1]

レプリケーションソフト（HVRD）の設定[1]

レプリケーションソフトにDRBDを使用する場合[1]

レプリケーションソフトにHVRDを使用する場合[1]

レプリケーションソフトを使用する場合の注意事項[1]

レプリケーションパス障害時の制御[1]

レプリケーションソフトにDRBDを使用する場合[1]

レプリケーションソフトにHVRDを使用する場合[1]

マニュアル発行元

株式会社 日立製作所

〒 100-8280 　東京都千代田区丸の内一丁目 6 番 6 号