1. はじめに

1.1. 対象読者と目的

本書は、クラスタシステムに関して、システムを構築する管理者、およびユーザサポートを行うシステムエンジニア、保守員を対象にしています。また、Amazon Web Services のうち、最低限 Amazon EC2、Amazon VPC、IAM に関する知識を保有していることが前提となります。

1.2. 適用範囲

動作環境については 「スタートアップガイド」-「CLUSTERPRO の動作環境」を参照してください。
本書に記載した各製品・サービスのスクリーンショット等は執筆時点のものであり、それ以降に変更されている可能性があります。最新の情報はそれぞれの Web サイトやマニュアルを参照してください。

1.3. 本書の構成

1.4. CLUSTERPRO マニュアル体系

CLUSTERPRO のマニュアルは、以下の 4 つに分類されます。各ガイドのタイトルと役割を以下に示します。

『CLUSTERPRO X スタートアップガイド』 (Getting Started Guide)

すべてのユーザを対象読者とし、製品概要、動作環境、アップデート情報、既知の問題などについて記載します。

『CLUSTERPRO X インストール&設定ガイド』 (Install and Configuration Guide)

CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアと、クラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO を使用したクラスタシステム導入から運用開始前までに必須の事項について説明します。実際にクラスタシステムを導入する際の順番に則して、CLUSTERPRO を使用したクラスタシステムの設計方法、CLUSTERPRO のインストールと設定手順、設定後の確認、運用開始前の評価方法について説明します。

『CLUSTERPRO X リファレンスガイド』 (Reference Guide)

管理者、および CLUSTERPRO を使用したクラスタシステムの導入を行うシステムエンジニアを対象とし、CLUSTERPRO の運用手順、各モジュールの機能説明およびトラブルシューティング情報等を記載します。『インストール&設定ガイド』を補完する役割を持ちます。

『CLUSTERPRO X メンテナンスガイド』 (Maintenance Guide)

管理者、および CLUSTERPRO を使用したクラスタシステム導入後の保守・運用を行うシステム管理者を対象読者とし、CLUSTERPRO のメンテナンス関連情報を記載します。

1.5. 本書の表記規則

本書では、注意すべき事項、重要な事項および関連情報を以下のように表記します。

注釈

この表記は、重要ではあるがデータ損失やシステムおよび機器の損傷には関連しない情報を表します。

重要

この表記は、データ損失やシステムおよび機器の損傷を回避するために必要な情報を表します。

参考

この表記は、参照先の情報の場所を表します。

また、本書では以下の表記法を使用します。

表記

使用方法

例

[ ] 角かっこ
コマンド名の前後
画面に表示される語 (ダイアログボックス、メニューなど) の前後
[スタート] をクリックします。
[プロパティ] ダイアログボックス

コマンドライン中の [ ] 角かっこ

かっこ内の値の指定が省略可能であることを示します。

clpstat -s [-h host_name]

>

Windows ユーザが、コマンドプロンプトでコマンドを実行することを示すプロンプト

> clpstat

モノスペースフォント

パス名、コマンドライン、システムからの出力 (メッセージ、プロンプトなど)、ディレクトリ、ファイル名、関数、パラメータ

C:\Program Files

太字

ユーザが実際にコマンドラインから入力する値を示します。
以下を入力します。
> clpcl -s -a

斜体

ユーザが有効な値に置き換えて入力する項目

> ping <IPアドレス>

CLUSTERPRO X 本書の図では、CLUSTERPRO を表すために このアイコンを使用します。

1.6. 最新情報の入手先

最新の製品情報については、以下のWebサイトを参照ください。

2. 概要

2.1. 機能概要

本書の設定を行うことで、Amazon Web Services(以下、AWS) の Amazon Virtual Private Cloud（以下、VPC） 環境において CLUSTERPRO による HA クラスタを構築できます。

HA クラスタを構築することで、より重要な業務を行うことが可能となり AWS 環境におけるシステム構成の選択肢が広がります。AWS 環境は地域（リージョン）ごとに複数の Availability Zone(以下、AZ) で堅牢に構成されており、利用者は必要に応じて AZ を選択して使用できます。CLUSTERPRO は複数の AZ 間 (以下、Multi-AZ) においても HA クラスタを可能とするため、業務の高可用性を実現します。

2つの Availability Zone とそれぞれの中のServer Instance

図 2.1 Multi-AZ 構成のミラー型 HA クラスタ

AWS 環境においては仮想的な IP アドレスを使用してクラスタサーバに接続することが可能です。AWS 仮想 IP リソースや AWS Elastic IP リソースや AWS セカンダリ IP リソースや AWS DNS リソースを利用することで、"フェイルオーバ" または、"グループの移動" が発生した場合でも、クライアントは接続先サーバの切り替えを意識する必要がありません。

2.2. HA クラスタ構成

本構築ガイドでは、「仮想 IP （以下、VIP） 制御による HA クラスタ」、「Elastic IP （以下、EIP） 制御による HA クラスタ」、「セカンダリ IP （以下、SIP） 制御による HA クラスタ」、「DNS 名制御による HA クラスタ」、「Network Load Balancer （以下、NLB） を利用した HA クラスタ」 の 5 種類の HA クラスタを想定しています。本節では Single-AZ 構成にて説明しています。Multi-AZ については「2.3. Multi-AZ」を参照してください。

HA クラスタにアクセスする
クライアントの場所

選択するリソース

本章の参照箇所

同じ VPC 内
AWS 仮想 IP リソース
LB プローブポートリソース
VIP 制御による HA クラスタ
NLB を利用した HA クラスタ [1]

インターネット

AWS Elastic IP リソース

EIP 制御による HA クラスタ

同じサブネット内

AWS セカンダリ IP リソース

SIP 制御による HA クラスタ

任意の場所

AWS DNS リソース

DNS 名制御による HA クラスタ

2.2.1. VIP 制御による HA クラスタ

同じVPC内のクライアントから、VIP アドレスを通じて HA クラスタにアクセスさせる構成を想定しています。たとえば DB サーバをクラスタ化し、Web サーバから VIP アドレス経由で DB サーバにアクセスするなどの用途が考えられます。

Public subnet 内の NAT Gateway と Client Instance、Private subnet 内の2つの Server Instance、および VIP

図 2.2 VIP 制御による HA クラスタ

図の例では、Private なサブネット上にクラスタ化されたサーバ用のインスタンスが配置されています。CLUSTERPRO の AWS 仮想 IP リソースは、現用系側サーバ用のインスタンスに対して VIP アドレスの設定および VPC のルートテーブルの書き換えを行います。これにより、VPC 内の任意のサブネット上に配置されたクライアント用のインスタンスから VIP アドレスを通じて現用系側サーバ用のインスタンスにアクセスできるようになります。VIP アドレスは、VPC の CIDR の範囲外である必要があります。

VPC 外のクライアントからアクセスする場合は、何らかの方法で VPC 内のルートテーブルを使用して通信を行うようにする必要があります。例えば、AWS Transit Gateway を使用すると VPC 外からの通信を Transit Gateway ルートテーブルで VPC 内に転送後、VPC 内のルートテーブルを使用して通信することができます。

サーバ用の各インスタンスは、AWS CLI の実行や、DNS 参照などで必要な時は、Public なサブネットに配置された NAT ゲートウェイ を経由してリージョンのエンドポイントやインターネットへアクセスします。
※AWS CLI の実行時は、各インスタンスがリージョンのエンドポイントに接続する必要があります。
リージョンのエンドポイントに接続する方法として Proxy サーバ / NAT / Public IP / EIP / VPC エンドポイントなどを使用する方法がありますが、本書では VIP 制御による HA クラスタ構成の場合、NAT ゲートウェイを使用する方法を採用しています。

VIP 制御による HA クラスタ構成において必要なリソース、監視リソースは以下のとおりです。

リソース種別

説明

設定

AWS 仮想 IP リソース

現用系側のインスタンスへの VIP アドレスの付与、および、その IP アドレスに対するルートテーブルの変更を行い、業務を 同じ VPC 内に公開します。

必須

AWS 仮想 IP 監視リソース
AWS 仮想 IP リソースが付与した VIP アドレスが自サーバに存在するか、および VPC のルートテーブルが不正に変更されていないかを定期的に監視します。
（AWS 仮想 IP リソースを追加すると自動的に追加されます。）

必須

AWS AZ 監視リソース

Multi-AZ を利用し、自サーバが属する AZ の健全性を定期的に監視します。

推奨

その他のリソース、監視リソース

ミラーディスクなど、HA クラスタで運用するアプリケーションの構成に従います。

任意

2.2.2. EIP 制御による HA クラスタ

クライアントから、インターネット経由で EIP に割り当てられたグローバル IP アドレスを通じて HA クラスタにアクセスさせる構成を想定しています。

クラスタ化するインスタンスは Public なサブネット上に配置されており、各インスタンスは、インターネットゲートウェイを経由してインターネットへアクセスすることが可能です。

2つの Server Instance、および Elastic IP Address

図 2.3 EIP 制御による HA クラスタ

図の例では、クラスタ化するサーバ用のインスタンスは Public なサブネット上に配置されています。CLUSTERPRO の AWS Elastic IP リソースは、EIP を現用系側サーバ用のインスタンスにアタッチします。これによりインターネット側の任意のクライアントは EIP アドレスを通じて現用系側サーバ用のインスタンスにアクセスできるようになります。

※AWS CLI の実行時は、各インスタンスがリージョンのエンドポイントに接続する必要があります。
リージョンのエンドポイントに接続する方法として Proxy サーバ / NAT / Public IP / EIP / VPC エンドポイントなどを使用する方法がありますが、本書では EIP 制御による HA クラスタ構成の場合、インスタンスに割り当てられた Public IP を経由する方法を採用しています。

EIP 制御による HA クラスタ構成において必要なリソース、監視リソースは以下のとおりです。

リソース種別

説明

設定

AWS Elastic IP リソース

現用系側のインスタンスに EIP アドレスを付与し、業務をインターネットに公開します。

必須

AWS Elastic IP 監視リソース
AWS Elastic IP リソースが付与した EIP アドレスが自サーバに存在するか定期的に監視します。
（AWS Elastic IP リソースを追加すると自動的に追加されます）

必須

AWS AZ 監視リソース

Multi-AZ を利用し、自サーバが属する AZ の健全性を定期的に監視します。

推奨

その他のリソース、監視リソース

ミラーディスクなど、HA クラスタで運用するアプリケーションの構成に従います。

任意

2.2.3. SIP 制御による HA クラスタ

同じ VPC 内のクライアントから、SIP アドレスを通じて HA クラスタにアクセスさせる構成を想定しています。

パブリックサブネット内にある NAT ゲートウェイとクライアントインスタンス、プライベートサブネット内にある 2 つのサーバインスタンス

図 2.4 SIP 制御による HA クラスタ

図の例では、Private なサブネット上にクラスタ化されたサーバ用のインスタンスが配置されています。CLUSTERPRO の AWS セカンダリ IP リソースは、現用系側サーバ用のインスタンスに対して SIP アドレスの設定を行います。これにより、クライアント用のインスタンスから SIP アドレスを通じて現用系側サーバ用のインスタンスにアクセスできるようになります。クラスタ化するインスタンスは同一 Availability Zone 上に配置する必要があります。

サーバ用の各インスタンスは、AWS CLI の実行や、DNS 参照などで必要な時は、Public なサブネットに配置された NAT ゲートウェイ を経由してリージョンのエンドポイントやインターネットへアクセスします。
※AWS CLI の実行時は、各インスタンスがリージョンのエンドポイントに接続する必要があります。
リージョンのエンドポイントに接続する方法として Proxy サーバ / NAT / Public IP / EIP / VPC エンドポイントなどを使用する方法がありますが、本書では SIP 制御による HA クラスタ構成の場合、NAT ゲートウェイを使用する方法を採用しています。

SIP 制御による HA クラスタ構成において必要なリソース、監視リソースは以下のとおりです。

リソース種別

説明

設定

AWS セカンダリ IP リソース

現用系側のインスタンスに SIP アドレスを付与します。

必須

AWS セカンダリ IP 監視リソース

AWS セカンダリ IP リソースが付与した SIP アドレスが自サーバに存在するか定期的に監視します。

必須

AWS AZ 監視リソース

自サーバが属する AZ の健全性を定期的に監視します。

推奨

その他のリソース、監視リソース

ミラーディスクなど、HA クラスタで運用するアプリケーションの構成に従います。

任意

2.2.4. DNS 名制御による HA クラスタ

クライアントから、同一の DNS 名を使って HA クラスタにアクセスさせる構成を想定しています。たとえば DB サーバをクラスタ化し、Web サーバから DNS 名経由で DB サーバにアクセスするなどの用途が考えられます。

Public subnet 内の NAT Gateway と Client Instance、Private subnet 内の 2 つの Server Instance、および Domain Name

図 2.5 DNS 名制御による HA クラスタ

図の例では、Private なサブネット上にクラスタ化されたサーバ用のインスタンスが配置されています。CLUSTERPRO の AWS DNS リソースは、 DNS 名と現用系側サーバの IP アドレスを含むリソースレコードセットを Amazon Route 53 の Private ホストゾーンに登録します。これにより、VPC 内の任意のサブネット上に配置されたクライアント用のインスタンスから DNS 名を通じて現用系側サーバ用の インスタンスにアクセスできるようになります。

本書では、クラスタ化するサーバ用のインスタンスを Private なサブネット上に配置する構成を採用していますが、Public なサブネット上に配置することも可能です。この場合、AWS DNS リソースで DNS 名と現用系側サーバの Public IP アドレスを含むリソースレコードセットを Amazon Route 53 の Public ホストゾーンに登録することで、インターネット側の任意のクライアントから DNS 名を通じて現用系側サーバ用のインスタンスにアクセスできるようになります。なお、Public ホストゾーンのドメインへのクエリが Amazon Route 53 ネームサーバを参照するように、事前にレジストラのネームサーバ(NS) レコードを設定しておく必要があります。

また、クラスタとクライアントがそれぞれ異なる VPC 上に存在する構成とする場合は、VPC ピアリング接続を使用します。事前に、ピアリング接続した各 VPC を Amazon Route 53 の Private ホストゾーンに関連付けしておき、AWS DNS リソースでその Private ホストゾーンに DNS 名と現用系側サーバの IP アドレスを含むリソースレコードセットを登録します。これにより、異なる VPC 上のクライアントから DNS 名を通じて現用系側サーバ用のインスタンスにアクセスできるようになります。

※AWS CLI の実行時は、各インスタンスがリージョンのエンドポイントに接続する必要があります。
リージョンのエンドポイントに接続する方法として Proxy サーバ / NAT / Public IP / EIP などを使用する方法がありますが、本書では DNS 名制御による HA クラスタ構成の場合、NAT ゲートウェイを使用する方法を採用しています。

DNS 名制御による HA クラスタ構成において必要なリソース、監視リソースは以下のとおりです。

リソース種別

説明

設定

AWS DNS リソース

DNS 名と現用系側のインスタンスの IP アドレスを含むリソースレコードセットを Amazon Route 53 のホストゾーンに登録し、業務を同じ VPC 内、または、インターネットに公開します。

必須

AWS DNS 監視リソース
AWS DNS リソースが 登録したリソースレコードセットが、 Amazon Route 53 のホストゾーンに存在するか、およびその DNS 名の名前解決が可能かを定期的に監視します。
（AWS DNS リソースを追加すると自動的に追加されます。）

必須

AWS AZ 監視リソース

Multi-AZ を利用し、自サーバが属する AZ の健全性を定期的に監視します。

推奨

その他のリソース、監視リソース

ミラーディスクなど、 HA クラスタで運用するアプリケーションの構成に従います。

任意

2.2.5. NLB を利用した HA クラスタ

同じ VPC 内のクライアントから、NLB のドメイン名を通じて HA クラスタにアクセスさせる構成を想定しています。

Public subnet 内の Client Instance、Private subnet 内の NLB、および 2 つの Server Instance

図 2.6 NLB を利用した HA クラスタ

図の例では、Private なサブネット上にクラスタ化されたサーバ用のインスタンスが配置されています。LB プローブポートリソースは、活性時にロードバランサからのヘルスチェックを待ち受けるための制御プロセスを起動し、[ポート番号] で指定したポートをオープンします。また、非活性時にはヘルスチェックを待ち受けるための制御プロセスを停止し、[ポート番号] で指定したポートをクローズします。これにより、クライアントアプリケーションは、NLB のドメイン名 (または IP アドレス) を使用して現用系のクラスタサーバに接続することができます。ドメイン名を使用することにより、フェイルオーバまたは、グループの移動が発生しても、クライアントは、仮想マシンの切り替えを意識する必要がありません。

この構成では、AWS CLI は不要です。
NLB を利用した HA クラスタ構成において必要なリソース、監視リソースは以下のとおりです。

リソース種別

説明

設定

LB プローブポートリソース

ポート制御プロセスによるヘルスチェック用ポートの制御を行います。

必須

LB プローブポート監視リソース
LB プローブポートリソースが起動しているクラスタサーバに対して、ポート制御プロセスの死活監視を行います。
（LB プローブポートリソースを追加すると自動的に追加されます。）

必須

AWS AZ 監視リソース

Multi-AZ を利用し、自サーバが属する AZ の健全性を定期的に監視します。

推奨

その他のリソース、監視リソース

ミラーディスクなど、 HA クラスタで運用するアプリケーションの構成に従います。

任意

2.3. Multi-AZ

AWS 環境では、HA クラスタを構成するインスタンスをアベイラビリティーゾーン単位で分散させることで、アベイラビリティーゾーン単位の障害に対する冗長性を持たせ、可用性を高めることが可能です。
AWS AZ 監視リソースは、各アベイラビリティーゾーンの健全性を監視し、もし障害が発生していた場合は警告や回復動作を行わせることができます。
詳細は 『リファレンスガイド』-「AWS AZ 監視リソースを理解する」を 参照してください。
2 つの Availability Zone とそれぞれの中の NAT Gateway、Client Instance、Server Instance、および VIP

図 2.7 Multi-AZ を使用した HA クラスタの例

2.4. ネットワークパーティション解決

ネットワークパーティション解決 (NP 解決) では、各サーバが共通の装置に対するアクセス可否を確認することで、他サーバがダウンしたか自サーバがネットワークから孤立したかを判断します。

以下はNP解決の構成例です。

  • 構成 1 : HTTP NP 解決リソース + Witness サーバサービス (Amazon EC2 インスタンス)

  • 構成 2 : HTTP NP 解決リソース + Amazon S3 (静的サイトホスティング)

  • 構成 3 : PING NP 解決リソース + ICMP 応答サーバ (Amazon EC2 インスタンス)

以下にそれぞれのメリットとデメリットを記載しています。

以降、本書では構成 1 を元に説明します。

メリット

デメリット

構成 1

ハートビートと NP 解決リソースが使用する通信経路が同じため、NP 解決の信頼性が高い
・追加でインスタンスを用意する必要がある
・Witness サーバサービスをセットアップする必要がある

構成 2

追加でインスタンスを用意する必要がない

ハートビートと NP 解決リソースが使用する通信経路が同じとは限らないため、構成 1 に比べて NP 解決の信頼性が低い

構成 3

Witness サーバサービスをセットアップする必要がない

追加でインスタンスを用意する必要がある

NP 解決の詳細については以下のドキュメントを参照してください。

2.5. 強制停止

ハートビートの途絶によりサーバのダウンを認識したときに、残りのサーバ (正常なサーバ) からダウンしたサーバを強制的に停止させる機能です。
サーバがダウンしたと認識されたとき、実際にはサーバのストールにより一時的に動作不能になっている場合等があります。
このような場合に、ダウンしたサーバから健全なサーバに業務アプリケーションをフェイルオーバする前に、
ダウンしたサーバを確実に停止状態に移行させることにより、同一資源を複数のサーバからアクセスしデータ破壊を引き起こす危険性を減らすことができます。
強制停止については、以下を参照してください。

2.6. オンプレミスと AWS の違い

オンプレミスと AWS における CLUSTERPRO の機能差分は以下の通りです。

  • ✓：可

  • n/a：不可

機能

オンプレミス

AWS

共有ディスク型クラスタの構築可否

✓

✓

ミラーディスク型クラスタの構築可否

✓

✓

管理用グループの使用可否

✓

n/a

フローティング IP リソースの使用可否

✓

n/a

仮想 IP リソースの使用可否

✓

n/a

仮想コンピュータ名リソースの使用可否

✓

n/a

AWS Elastic IP リソースの使用可否

n/a

✓

AWS 仮想 IP リソースの使用可否

n/a

✓

AWS セカンダリ IP リソースの使用可否

n/a

✓

AWS DNS リソースの使用可否

n/a

✓

LB プローブポートリソースの使用可否

✓

✓

オンプレミスと AWS におけるミラーディスクと各種リソースを使用した2ノードクラスタの構築手順の流れは以下を参照してください。

3. 動作環境

以下のマニュアルを参照してください。

4. VIP 制御による HA クラスタの設定

本章では、VIP 制御による HA クラスタの構築手順を説明します。

図中の Server Instance (Active) は現用系サーバ、Server Instance (Standby) は待機系サーバのインスタンスです。

Public subnet 内の NAT Gateway、Private subnet 内の 2 つの Server Instance、および VIP

図 4.1 システム構成 VIP 制御による HA クラスタ

CIDR (VPC)

10.0.0.0/16

VIP

10.1.0.20

Public subnet (Subnet-1A)

10.0.10.0/24

Public subnet (Subnet-1B)

10.0.20.0/24

Private subnet (Subnet-2A)

10.0.110.0/24

Private subnet (Subnet-2B)

10.0.120.0/24

4.1. VPC 環境の設定

VPC Management Console、および、EC2 Management Console 上で VPC の構築を行います。
図中および説明中の IP アドレスは一例であり、実際の設定時は VPC に割り当てられている IP アドレスに読み替えてください。既存の VPC に CLUSTERPRO を適用する場合は、不足しているサブネットを追加するなど適切に読み替えてください。

  1. VPC およびサブネットを設定する

    最初に VPC およびサブネットを作成します。

    [1] VPC

    VPC ID （vpc-xxxxxxxx） は後で AWS 仮想 IP リソース の設定時に必要となるため、 別途控えておきます。

  2. Internet Gateway を設定する。

    VPC からインターネットにアクセスするための Internet Gateway を追加します。

  3. Network ACL/Security Group を設定する

    VPC 内外からの不正なネットワークアクセスを防ぐために、Network ACL、および、Security Group を適切に設定します。
    Private ネットワーク （Subnet-2A、および、Subnet-2B）内に配置予定の HA クラスタノード用のインスタンスから、HTTPS で Internet Gateway と通信可能となるように、また、Cluster WebUI やインスタンス同士の通信も可能となるよう各経路について Network ACL や Security Group の設定を変更します。

    CLUSTERPRO 関連コンポーネントが使用するポート番号については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」を参照し、設定してください。

  4. HA クラスタ用のインスタンスを追加する

    HA クラスタノード用のインスタンスを Private ネットワーク（Subnet-2A、および、Subnet-2B）に作成します。
    IAM ロールをインスタンスに割り当てて使用する場合は、IAM ロールを指定してください。

    ⇒ IAM の設定については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照し、設定してください。

    作成した各インスタンスに割り当てられている Elastic Network Interface (以下、ENI) の Source/Dest. Check を disabled に変更します。
    AWS 仮想 IP リソースが VIP 制御を可能にするためには、VIP アドレス（図では 10.1.0.20） への通信をインスタンスの ENI にルーティングさせる必要があります。各インスタンスの ENI は、Private IP アドレス と VIP アドレス からの通信を受け取るために、Source/Dest. Check を disabled にする必要があります。
    [7] Server Instance (Active), [8] Server Instance (Standby)
    現用系側インスタンスに割り当てられた ENI、待機系側インスタンスに割り当てられた ENI は、いずれも ENI ID で識別できます。
    各インスタンスの ENI ID （eni-xxxxxxxx） は後で AWS 仮想 IP リソース の設定時に必要となるため、 別途控えておきます。

  5. NAT を追加する

    AWS CLI による VIP 制御処理を実行するために、HA クラスタノード用のインスタンスからリージョンのエンドポイントに対して HTTPS による通信が可能な状態にする必要があります。
    そのために Public ネットワーク（Subnet-1A、および、Subnet-1B）上に NAT ゲートウェイを作成します。
    NAT ゲートウェイの詳細については AWS のドキュメントを参照してください。

  6. ルートテーブルを設定する。

    AWS CLI が NAT 経由でリージョンのエンドポイントと通信可能にするための Internet Gateway へのルーティングと、VPC 内のクライアントが VIP アドレスにアクセス可能にするためのルーティングを追加します。VIP アドレスの CIDR ブロックは必ず 32 にする必要があります。

    Public ネットワーク （図では Subnet-1A、および、Subnet-1B）のルートテーブル（Public-AB）には、以下のルーティングが必要となります。

    • Route Table (Public-AB)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      Internet Gateway

      追加（必須）
      VIP アドレス
      （例では 10.1.0.20/32）
      eni-xxxxxxxx
      （現用系側のインスタンス [7] Server Instance (Active) の ENI ID）

      追加（必須）
      Private ネットワーク （図では Subnet-2A、および、Subnet-2B）のルートテーブル（Private-A、および、Private-B）には、以下のルーティングが必要となります。

    • Route Table (Private-A)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      NAT Gateway1

      追加（必須）
      VIP アドレス
      （例では 10.1.0.20/32）
      eni-xxxxxxxx
      （現用系側のインスタンス [7] Server Instance (Active) の ENI ID）

      追加（必須）

    • Route Table (Private-B)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      NAT Gateway2

      追加（必須）
      VIP アドレス
      （例では 10.1.0.20/32）
      eni-xxxxxxxx
      （現用系側のインスタンス [7] Server Instance (Active) の ENI ID）

      追加（必須）
    フェイルオーバ時に AWS 仮想 IP リソースが AWS CLI を使用して これらのルートテーブルに設定されている VIP アドレスへのルーティングをすべて 待機系側のインスタンスの ENI に切り替えます。
    [6] VIP
    VIP アドレスは、VPC の CIDR の範囲外である必要があります。
    ルートテーブルに設定した VIP アドレスは、後で AWS 仮想 IP リソース の設定時にも必要となるため、 別途控えておきます。

    その他のルーティングは、環境にあわせて設定してください。

  7. ミラーディスク（Amazon EBS）を追加する

    必要に応じてミラーディスク（クラスタパーティション、データパーティション）に使用する Amazon EBS を追加します。

4.2. インスタンスの設定

HA クラスタ用の各インスタンスにログインして以下の設定を実施します。
CLUSTERPRO がサポートしている AWS CLI のバージョンについては、『スタートアップガイド』-「CLUSTERPRO の動作環境」-「AWS 仮想 IP リソース、AWS 仮想 IP 監視リソースの動作環境」を参照してください。

  1. CLUSTERPRO のサービス起動時間を調整、ネットワーク設定の確認、ファイアウォールの設定を確認、サーバの時刻を同期、 パワーセービング機能を確認

    各手順は以下を参照してください。
    『スタートアップガイド』の「システム構成を決定する」-「ハードウェア構成後の設定」を参照し、設定してください。

  2. AWS CLI のインストール

    AWS CLI をダウンロードして、インストールします。
    システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWS のドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。
    AWS CLI のインストールを行った時点ですでに CLUSTERPRO がインストール済の場合は、OS を再起動してから CLUSTERPRO の操作を行ってください。

  3. AWS アクセスキー ID の登録

    Administrator ユーザでコマンドプロンプトを起動し、以下のコマンドを実行します。

    > aws configure

    質問に対して、AWS アクセスキー ID などの情報を入力します。

    インスタンスに IAM ロールを割り当てているか否かで 2 通りの設定に分かれます。

    ◇ IAM ロールを割り当てているインスタンスの場合

    AWS Access Key ID [None]: （Enter のみ）
AWS Secret Access Key [None]: （Enter のみ）
Default region name [None]: <既定のリージョン名>
Default output format [None]: text

    ◇ IAM ロールを割り当てていないインスタンスの場合

    AWS Access Key ID [None]: <AWS アクセスキー ID>
AWS Secret Access Key [None]: <AWS シークレットアクセスキー>
Default region name [None]: <既定のリージョン名>
Default output format [None]: text
    "Default output format" は、"text" 以外を指定することも可能です。
    もし誤った内容を設定してしまった場合は、%SystemDrive%\Users\Administrator\.aws をフォルダごと消去してから上記操作をやり直してください。

  4. ミラーディスクの準備

    ミラーディスク用に Amazon EBS を追加していた場合は、Amazon EBS をパーティション分割し、それぞれクラスタパーティション、データパーティションに使用します。
    ミラーディスク用のパーティションについては、『インストール&設定ガイド』の「システム構成を決定する」-「ミラー用パーティションを設定する (ミラーディスク使用時は必須)」を参照してください。

  5. CLUSTERPRO のインストール

    インストール手順は『インストール&設定ガイド』を参照してください。
    CLUSTERPRO のインストール媒体を導入環境に格納します。
    （データの転送に関しては Remote Desktop、Amazon S3 経由など任意です。）

    インストール完了後、OS の再起動を行ってください。

4.3. CLUSTERPRO の設定

Cluster WebUI のセットアップ、および、接続方法は『インストール&設定ガイド』の「クラスタ構成情報を作成する」を参照してください。

ここでは以下のリソースを追加する手順を記述します。

  • 共通設定

    • Witness ハートビート

    • NP 解決リソース (HTTP NP 方式)

    • AWS 強制停止リソース

    • ミラーディスクリソース

    • AWS AZ 監視リソース

  • 固有設定

    • AWS 仮想 IP リソース

    • AWS 仮想 IP 監視リソース

上記以外の設定は、『インストール&設定ガイド』を参照してください。

  1. クラスタの構築

最初に、クラスタ生成ウィザードを開始し、クラスタを構築します。

  • クラスタの構築

    【手順】

    1. Cluster WebUI にアクセスし、[クラスタ生成ウィザード] をクリックします。

    2. [クラスタ生成ウィザード] 画面の [クラスタ] 画面が表示されます。
      [クラスタ名] に任意のクラスタ名を入力します。
      [言語] を適切に選択します。[次へ] をクリックします。
    3. Cluster WebUI に接続したインスタンスがマスタサーバとして登録済みの状態で表示されます。
      [追加] をクリックし、残りのインスタンスを追加します（インスタンスの Private IP アドレスを指定します）。[次へ] をクリックします。
    4. [インタコネクト] 画面が表示されます。
      1. インタコネクトのために使用する IP アドレス（各インスタンスの Private IP アドレス）を指定します。また、後で作成するミラーディスクリソースの通信経路として [MDC] に mdc1 を選択します。
      2. [追加] をクリックし、 [種別] に Witness を選択します。
        [プロパティ] をクリックします。
      3. [ターゲットホスト] を設定します。[OK] をクリックし、[次へ] をクリックします。
    5. [フェンシング] 画面が表示されます。
      1. HTTP NP 解決リソースが自動追加されていることを確認します。
      2. 強制停止のタイプを AWS に設定します。
        [プロパティ] をクリックします。
      3. 利用可能なサーバからサーバを選択して [追加] をクリックします。
      4. [インスタンスの入力] ダイアログボックスが表示されます。
        [インスタンスID] に 各サーバの AWS のインスタンス ID を設定し、 [OK] をクリックします。
        強制停止の設定が完了したら [OK] をクリックし、 [次へ] をクリックします。

  1. グループリソースの追加

  • グループの定義

    フェイルオーバグループを作成します。

    【手順】

    1. [グループ一覧] 画面が表示されます。
      [追加] をクリックします。
    2. [グループの定義] 画面が表示されます。
      [名前] にフェイルオーバグループ名（failover1）を設定します。[次へ] をクリックします。
    3. [起動可能サーバ] 画面が表示されます。
      何も指定せず [次へ] をクリックします。
    4. [グループ属性] 画面が表示されます。
      何も指定せず [次へ] をクリックします。
    5. [グループリソース一覧] 画面が表示されます。
      以降の手順で、この画面でグループリソースを追加していきます。

  • ミラーディスクリソース

    必要に応じてミラーディスク（Amazon EBS）にあわせたミラーディスクリソース を作成します。

    詳細は『リファレンスガイド』-「ミラーディスクリソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。

    2. [グループのリソース定義 | failover1] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (ミラーディスクリソース)を選択して、[名前] ボックスにグループリソース名 (md) を入力します。[次へ] をクリックします。
    3. [依存関係] 画面が表示されます。
      何も指定せず [次へ] をクリックします。

    4. [復旧動作] 画面が表示されます。[次へ] をクリックします。

    5. [詳細] 画面が表示されます。
      [データパーティションのドライブ文字] と [クラスタパーティションのドライブ文字] に「 4.2. インスタンスの設定 」-「5. ミラーディスクの準備」で作成したパーティションに対応するドライブ文字を入力します。

    6. [起動可能サーバ]で[名前]列中のサーバ名を選択し[追加]をクリックします。

    7. [パーティションの選択] ダイアログボックスが表示されます。[接続] をクリックし、データパーティションと、クラスタパーティションを選択し、[OK] をクリックします。

    8. 6～7の手順をもう一方のノードでも実施します。

    9. [詳細設定] 画面に戻り、[完了] をクリックして設定を終了します。

  • AWS 仮想 IP リソース

    AWS CLI を利用して、VIP の制御を行う AWS 仮想 IP リソースを追加します。

    詳細は『リファレンスガイド』-「AWS 仮想 IP リソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。

    2. [グループのリソース定義 | failover1] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (AWS 仮想 IP リソース) を選択して、[名前] ボックスにグループリソース名 (awsvip1) を入力します。[次へ] をクリックします。

    3. [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。

    4. [復旧動作] 画面が表示されます。[次へ] をクリックします。

    5. [詳細] 画面が表示されます。
      [共通] タブの[IP アドレス] ボックスに、付与したい VIP アドレスを設定します(図 4.1 システム構成 VIP 制御による HA クラスタ の [6] が該当)。
      [VPC ID] ボックスに、インスタンスが所属する VPC の ID を設定します(図 4.1 システム構成 VIP 制御による HA クラスタ の [1] が該当)。
      サーバ個別設定を行う場合、[共通]タブでは、任意のサーバの VPC ID を記載し、他のサーバは個別設定を行うようにしてください。
      [ENI ID] ボックスに、VIP アドレスのルーティング先となる現用系側のインスタンスの ENI ID を設定します(図 4.1 システム構成 VIP 制御による HA クラスタ の [7] が該当)。
      サーバ別設定が必須です。[共通]タブでは、任意のサーバの ENI ID を記載し、他のサーバは個別設定を行うようにしてください。
    6. 各ノードのタブをクリックし、ノード別設定を行います。
      [個別に設定する] をチェックします。
      [VPC ID] ボックスに[共通]タブで設定した VPC ID と同じものが設定されていることを確認します(図 4.1 システム構成 VIP 制御による HA クラスタ の [1] が該当)。
      [ENI ID] ボックスに、そのノードに対応するインスタンスの ENI ID を設定します(図 4.1 システム構成 VIP 制御による HA クラスタ の [7] [8] が該当)。

    7. [完了] をクリックして設定を終了します。

  1. モニタリソースの追加

  • AWS AZ 監視リソース

    監視 コマンドを利用して、指定した AZ が利用可能かどうかを確認する AWS AZ 監視リソースを作成します。
    詳細は『リファレンスガイド』-「AWS AZ 監視リソースを理解する」を参照してください。

    【手順】

    1. [モニタリソース一覧] で [追加] をクリックします。

    2. [タイプ] ボックスで監視リソースのタイプ (AWS AZ 監視) を選択し、[名前] ボックスに監視リソース名 (awsazw1) を入力します。[次へ] をクリックします。
    3. [監視(共通)] 画面が表示されます。
      何も指定せず [次へ] をクリックします。
    4. [監視(固有)] 画面が表示されます。
      [共通] タブの[アベイラビリティーゾーン] ボックスに監視するアベイラビリティーゾーンを入力します（現用系側のインスタンスのアベイラビリティーゾーンを設定します）(図 4.1 システム構成 VIP 制御による HA クラスタ の [2] が該当)。
    5. 各ノードのタブをクリックし、ノード別設定を行います。
      [個別に設定する]をチェックします。
      [アベイラビリティーゾーン] ボックスに、そのノードに対応するインスタンスのアベイラビリティーゾーンを設定します(図 4.1 システム構成 VIP 制御による HA クラスタ の [2] [3] が該当)。[次へ] をクリックします。
    6. [回復動作] 画面が表示されます。
      [回復対象] に [LocalServer]を設定します。

    7. [完了] をクリックして設定を終了します。

  • AWS 仮想 IP 監視リソース

    AWS 仮想 IP リソース追加時に、自動的に追加されます。
    VIP アドレスの存在及びルートテーブルの健全性を確認します。
    詳細は『リファレンスガイド』-「AWS 仮想 IP 監視リソースを理解する」を参照してください。

  1. 設定の反映とクラスタの起動

詳細は『インストール&設定ガイド』-「クラスタを生成するには」を参照してください。

  1. Cluster WebUI の設定モード から、[設定の反映] をクリックします。
    [設定を反映しますか。] というポップアップメッセージが表示されますので、[OK] をクリックします。
    アップロードに成功すると、[反映に成功しました。] のメッセージが表示されますので、[OK] をクリックします。
    アップロードに失敗した場合は、表示されるメッセージに従って操作を行ってください。

  2. Cluster WebUI の ツールバーのドロップダウンメニューで [操作モード] を選択して、操作モードに切り替えます。

  3. Cluster WebUI の [ステータス] タブから [クラスタ開始] をクリックし、確認画面で [開始] をクリックします。

5. EIP 制御による HA クラスタの設定

本章では、EIP 制御による HA クラスタの構築手順を説明します。

図中の Server Instance (Active) は現用系サーバ、Server Instance (Standby) は待機系サーバのインスタンスです。

2つの Availability Zone とそれぞれの中の Server Instance、および Elastic IP Address

図 5.1 システム構成 EIP 制御による HA クラスタ

CIDR (VPC)

10.0.0.0/16

Public subnet (Subnet-1A)

10.0.10.0/24

Public subnet (Subnet-1B)

10.0.20.0/24

5.1. VPC 環境の設定

VPC Management Console、および、EC2 Management Console 上で VPC の構築を行います。
図中および説明中の IP アドレスは一例であり、実際の設定時は VPC に割り当てられている IP アドレスに読み替えてください。既存の VPC に CLUSTERPRO を適用する場合は、不足しているサブネットを追加するなど適切に読み替えてください。

  1. VPC およびサブネットを設定する

    最初に VPC およびサブネットを作成します。

  2. Internet Gateway を設定する。

    VPC からインターネットにアクセスするための Internet Gatewayを追加します。

  3. Network ACL/Security Group を設定する

    VPC 内外からの不正なネットワークアクセスを防ぐために、Network ACL、および、Security Group を適切に設定します。
    Public ネットワーク （Subnet-1A、および、Subnet-1B）内に配置予定の HA クラスタノード用のインスタンスから、HTTPS で Internet Gateway と通信可能となるように、また、Cluster WebUI やインスタンス同士の通信も可能となるよう各経路について Network ACL や Security Group の設定を変更します。

    CLUSTERPRO 関連コンポーネントが使用するポート番号については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」を参照し、設定してください。

  4. HA クラスタ用のインスタンスを追加する

    HA クラスタノード用のインスタンスを Public ネットワーク（Subnet-1A、および、Subnet-1B）に作成します。

    作成時には Public IP を有効となるように設定してください。Public IP を使用しないで作成した場合は、後から EIP を追加するか、NAT を用意する必要があります（本書ではこのケースの説明は割愛します）。

    IAM ロールをインスタンスに割り当てて使用する場合は、IAM ロールを指定してください。

    ⇒ IAM の設定については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照し、設定してください。

    作成した各インスタンスに割り当てられている Elastic Network Interface (以下、ENI) のIDを確認します。

    [4] Server Instance (Active), [5] Server Instance (Standby)

    ここで各インスタンスの ENI ID （eni-xxxxxxxx） は後で AWS Elastic IP リソース の設定時に必要となるため、 別途控えておきます。

  5. EIP を追加する

    インターネット側から VPC 内のインスタンスにアクセスするための EIP を追加します。

    [3] Elastic IP Address

    ここで追加した EIP の Allocation ID （eipalloc-xxxxxxxx） は後で AWS Elastic IP リソース の設定時に必要となるため、 別途控えておきます。

  6. ルートテーブルを設定する。

    AWS CLI が NAT 経由でリージョンのエンドポイントと通信可能にするための Internet Gateway へのルーティングを追加します。

    Public ネットワーク （図では Subnet-1A、および、Subnet-1B）のルートテーブル（Public-AB）には、以下のルーティングが必要となります。

    • Route Table (Public-AB)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      Internet Gateway

      追加（必須）
    フェイルオーバ時に AWS Elastic IP リソースが AWS CLI を使用して、現用系側のインスタンスに割り当てられている EIP の切り離しを行い、 待機系側のインスタンスの ENI に EIP を割り当てます。
    その他のルーティングは、環境にあわせて設定してください。

  7. ミラーディスク（Amazon EBS）を追加する

    必要に応じてミラーディスク（クラスタパーティション、データパーティション）に使用する Amazon EBS を追加します。

5.2. インスタンスの設定

HA クラスタ用の各インスタンスにログインして以下の設定を実施します。
CLUSTERPRO がサポートしている AWS CLI のバージョンについては、『スタートアップガイド』-「CLUSTERPRO の動作環境」-「AWS Elastic IP リソース、AWS Elastic IP 監視リソース、AWS AZ 監視リソースの動作環境」を参照してください。

  1. CLUSTERPRO のサービス起動時間を調整、ネットワーク設定の確認、ファイアウォールの設定を確認、サーバの時刻を同期、 パワーセービング機能を確認

    各手順は以下を参照してください。
    『スタートアップガイド』の「システム構成を決定する」-「ハードウェア構成後の設定」を参照し、設定してください。

  2. AWS CLI のインストール

    AWS CLI をダウンロードして、インストールします。
    システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWS のドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。
    AWS CLI のインストールを行った時点ですでに CLUSTERPRO がインストール済の場合は、OS を再起動してから CLUSTERPRO の操作を行ってください。

  3. AWS アクセスキー ID の登録

    コマンドプロンプトを起動し、以下のコマンドを実行します。

    > aws configure
    質問に対して、AWS アクセスキー ID などの情報を入力します。
    インスタンスに IAM ロールを割り当てているか否かで 2 通りの設定に分かれます。

    ◇ IAM ロールを割り当てているインスタンスの場合

    AWS Access Key ID [None]: （Enter のみ）
AWS Secret Access Key [None]: （Enter のみ）
Default region name [None]: <既定のリージョン名>
Default output format [None]: text

    ◇ IAM ロールを割り当てていないインスタンスの場合

    AWS Access Key ID [None]: <AWS アクセスキー ID>
AWS Secret Access Key [None]: <AWS シークレットアクセスキー>
Default region name [None]: <既定のリージョン名>
Default output format [None]: text
    "Default output format" は、"text" 以外を指定することも可能です。
    もし誤った内容を設定してしまった場合は、%SystemDrive%\Users\Administrator\.aws をフォルダごと消去してから上記操作をやり直してください。

  4. ミラーディスクの準備

    ミラーディスク用に Amazon EBS を追加していた場合は、Amazon EBS をパーティション分割し、それぞれクラスタパーティション、データパーティションに使用します。
    ミラーディスク用のパーティションについては、『インストール&設定ガイド』の「システム構成を決定する」-「ミラー用パーティションを設定する (ミラーディスク使用時は必須)」を参照してください。

  5. CLUSTERPRO のインストール

    インストール手順は『インストール&設定ガイド』を参照してください。
    CLUSTERPRO のインストール媒体を導入環境に格納します。
    （データの転送に関しては Remote Desktop、Amazon S3 経由など任意です。）

    インストール完了後、OS の再起動を行ってください。

5.3. CLUSTERPRO の設定

Cluster WebUI のセットアップ、および、接続方法は『インストール&設定ガイド』の「クラスタ構成情報を作成する」を参照してください。

ここでは以下のリソースを追加する手順を記述します。

  • 共通設定

    • Witness ハートビート

    • NP 解決リソース (HTTP NP 方式)

    • AWS 強制停止リソース

    • ミラーディスクリソース

    • AWS AZ 監視リソース

  • 固有設定

    • AWS EIP リソース

    • AWS EIP 監視リソース

共通設定は『4.3. CLUSTERPRO の設定』、上記以外の設定は『インストール&設定ガイド』を参照してください。

  1. グループリソースの追加

  • AWS Elastic IP リソース

    AWS CLI を利用して、EIP の制御を行う AWS Elastic IP リソースを追加します。

    詳細は『リファレンスガイド』-「AWS Elastic IP リソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。

    2. [グループのリソース定義 | failover1] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (AWS Elastic IP リソース) を選択して、[名前] ボックスにグループリソース名 (awseip1) を入力します。[次へ] をクリックします。

    3. [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。

    4. [復旧動作] 画面が表示されます。[次へ] をクリックします。

    5. [詳細] 画面が表示されます。
      [共通] タブの[EIP ALLOCATION ID] ボックスに、付与したい EIP の Allocation ID を設定します(図 5.1 システム構成 EIP 制御による HA クラスタ の [3] [4] が該当)。
      [ENI ID] ボックスに、EIP を割り当てる現用系側のインスタンスの ENI ID を設定します。
    6. 各ノードのタブをクリックし、ノード別設定を行います。
      [個別に設定する] をチェックします。
      [ENI ID] ボックスに、そのノードに対応するインスタンスの ENI ID を設定します(図 5.1 システム構成 EIP 制御による HA クラスタ の [4] [5] が該当)。

    7. [完了] をクリックして設定を終了します。

  1. モニタリソースの追加

  • AWS Elastic IP 監視リソース

    AWS Elastic IP リソース追加時に、自動的に追加されます。
    現用系側のインスタンスに割り当てられている EIP アドレスへの通信を監視することで、EIP アドレスの健全性を確認します。
    詳細は『リファレンスガイド』-「AWS Elastic IP 監視リソースを理解する」を参照してください。

  1. 設定の反映とクラスタの起動

詳細は『インストール&設定ガイド』-「クラスタを生成するには」を参照してください。

  1. Cluster WebUI の設定モード から、[設定の反映] をクリックします。
    [設定を反映しますか。] というポップアップメッセージが表示されますので、[OK] をクリックします。
    アップロードに成功すると、[反映に成功しました。] のメッセージが表示されますので、[OK] をクリックします。
    アップロードに失敗した場合は、表示されるメッセージに従って操作を行ってください。

  2. Cluster WebUI の ツールバーのドロップダウンメニューで [操作モード] を選択して、操作モードに切り替えます。

  3. Cluster WebUI の [ステータス] タブから [クラスタ開始] をクリックし、確認画面で [開始] をクリックします。

6. SIP 制御による HA クラスタの設定

本章では、SIP 制御による HA クラスタの構築手順を説明します。

図中の Server Instance (Active) は現用系サーバ、Server Instance (Standby) は待機系サーバのインスタンスです。

1 つの Availability Zone とそれぞれの中の Server Instance、およびセカンダリ IP アドレス

図 6.1 システム構成 SIP 制御による HA クラスタ

CIDR (VPC)

10.0.0.0/16

Public subnet (Subnet-1)

10.0.10.0/24

Private subnet (Subnet-2)

10.0.20.0/24

6.1. VPC 環境の設定

VPC Management Console、および、EC2 Management Console 上で VPC の構築を行います。
図中および説明中の IP アドレスは一例であり、実際の設定時は VPC に割り当てられている IP アドレスに読み替えてください。既存の VPC に CLUSTERPRO を適用する場合は、不足しているサブネットを追加するなど適切に読み替えてください。

  1. VPC およびサブネットを設定する

    最初に VPC およびサブネットを作成します。

  2. Internet Gateway を設定する。

    VPC からインターネットにアクセスするための Internet Gateway を追加します。

  3. Network ACL/Security Group を設定する

    VPC 内外からの不正なネットワークアクセスを防ぐために、Network ACL、および、Security Group を適切に設定します。
    Private ネットワーク （Subnet-2）内に配置予定の HA クラスタノード用のインスタンスから、HTTPS で Internet Gateway と通信可能となるように、また、Cluster WebUI やインスタンス同士の通信も可能となるよう各経路について Network ACL や Security Group の設定を変更します。

    CLUSTERPRO 関連コンポーネントが使用するポート番号については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」を参照し、設定してください。

  4. HA クラスタ用のインスタンスを追加する

    HA クラスタノード用のインスタンスを Private ネットワーク（Subnet-2）に作成します。
    IAM ロールをインスタンスに割り当てて使用する場合は、IAM ロールを指定してください。

    ⇒ IAM の設定については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照し、設定してください。

    [2] Server Instance (Active), [3] Server Instance (Standby)
    現用系側インスタンスに割り当てられた ENI、待機系側インスタンスに割り当てられた ENI は、いずれも ENI ID で識別できます。
    各インスタンスの ENI ID （eni-xxxxxxxx） は後で AWS セカンダリ IP リソース の設定時に必要となるため、 別途控えておきます。

  5. NAT を追加する

    AWS CLI による SIP 制御処理を実行するために、HA クラスタノード用のインスタンスからリージョンのエンドポイントに対して HTTPS による通信が可能な状態にする必要があります。
    そのために Public ネットワーク（Subnet-1）上に NAT ゲートウェイを作成します。
    NAT ゲートウェイの詳細については AWS のドキュメントを参照してください。

  6. ルートテーブルを設定する。

    AWS CLI が NAT 経由でリージョンのエンドポイントと通信可能にするための Internet Gateway へのルーティングを追加します。

    各サブネットのルートテーブルは、以下のルーティングが必要となります。

    • Route Table (Public-A)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      Internet Gateway

      追加（必須）

    • Route Table (Private-A)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      NAT Gateway

      追加（必須）
    その他のルーティングは、環境にあわせて設定してください。

  7. ミラーディスク（Amazon EBS）を追加する

    必要に応じてミラーディスク（クラスタパーティション、データパーティション）に使用する Amazon EBS を追加します。

6.2. インスタンスの設定

HA クラスタ用の各インスタンスにログインして以下の設定を実施します。
CLUSTERPRO がサポートしている AWS CLI のバージョンについては、『スタートアップガイド』-「CLUSTERPRO の動作環境」-「AWS セカンダリ IP リソース、AWS セカンダリ IP 監視リソースの動作環境」を参照してください。

  1. CLUSTERPRO のサービス起動時間を調整、ネットワーク設定の確認、ファイアウォールの設定を確認、サーバの時刻を同期、 パワーセービング機能を確認

    各手順は以下を参照してください。
    『スタートアップガイド』の「システム構成を決定する」-「ハードウェア構成後の設定」を参照し、設定してください。

  2. 静的 IP アドレスを設定する

    AWS セカンダリ IP リソースでセカンダリ IP アドレスを割り当てるネットワークアダプタのプライベート IP アドレスを静的に登録してください。
    詳細は下記のステップ 1 を参照してください。
    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/config-windows-multiple-ip.html#step1

  3. AWS CLI のインストール

    AWS CLI をダウンロードして、インストールします。
    システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWS のドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。
    AWS CLI のインストールを行った時点ですでに CLUSTERPRO がインストール済の場合は、OS を再起動してから CLUSTERPRO の操作を行ってください。

  4. AWS アクセスキー ID の登録

    コマンドプロンプトを起動し、以下のコマンドを実行します。

    > aws configure
    質問に対して、AWS アクセスキー ID などの情報を入力します。
    インスタンスに IAM ロールを割り当てているか否かで 2 通りの設定に分かれます。

    ◇ IAM ロールを割り当てているインスタンスの場合

    AWS Access Key ID [None]: （Enter のみ）
AWS Secret Access Key [None]: （Enter のみ）
Default region name [None]: <既定のリージョン名>
Default output format [None]: text

    ◇ IAM ロールを割り当てていないインスタンスの場合

    AWS Access Key ID [None]: <AWS アクセスキー ID>
AWS Secret Access Key [None]: <AWS シークレットアクセスキー>
Default region name [None]: <既定のリージョン名>
Default output format [None]: text
    "Default output format" は、"text" 以外を指定することも可能です。
    もし誤った内容を設定してしまった場合は、%SystemDrive%\Users\Administrator\.aws をフォルダごと消去してから上記操作をやり直してください。

  5. ミラーディスクの準備

    ミラーディスク用に Amazon EBS を追加していた場合は、Amazon EBS をパーティション分割し、それぞれクラスタパーティション、データパーティションに使用します。
    ミラーディスク用のパーティションについては、『インストール&設定ガイド』の「システム構成を決定する」-「ミラー用パーティションを設定する (ミラーディスク使用時は必須)」を参照してください。

  6. CLUSTERPRO のインストール

    インストール手順は『インストール&設定ガイド』を参照してください。
    CLUSTERPRO のインストール媒体を導入環境に格納します。
    （データの転送に関しては Remote Desktop、Amazon S3 経由など任意です。）

    インストール完了後、OS の再起動を行ってください。

6.3. CLUSTERPRO の設定

Cluster WebUI のセットアップ、および、接続方法は『インストール&設定ガイド』の「クラスタ構成情報を作成する」を参照してください。

ここでは以下のリソースを追加する手順を記述します。

  • 共通設定

    • Witness ハートビート

    • NP 解決リソース (HTTP NP 方式)

    • AWS 強制停止リソース

    • ミラーディスクリソース

    • AWS AZ 監視リソース

  • 固有設定

    • AWS セカンダリ IP リソース

    • AWS セカンダリ IP 監視リソース

共通設定は『4.3. CLUSTERPRO の設定』、上記以外の設定は『インストール&設定ガイド』を参照してください。

  1. グループリソースの追加

  • AWS セカンダリ IP リソース

    AWS CLI を利用して、SIP の制御を行う AWS セカンダリ IP リソースを追加します。

    詳細は『リファレンスガイド』-「AWS セカンダリ IP リソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。

    2. [グループのリソース定義 | failover1] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (AWS セカンダリ IP リソース) を選択して、[名前] ボックスにグループリソース名 (awssip1) を入力します。[次へ] をクリックします。

    3. [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。

    4. [復旧動作] 画面が表示されます。何も指定せず [次へ] をクリックします。

    5. [詳細] 画面が表示されます。
      [共通] タブの[IP アドレス] ボックスに、付与したい SIP の IP アドレスを設定します(図 6.1 システム構成 SIP 制御による HA クラスタ の [1] が該当)。
      [ENI ID] ボックスに、SIP を割り当てる現用系側のインスタンスの ENI ID を設定します(図 6.1 システム構成 SIP 制御による HA クラスタ の [2] が該当)。
    6. 各ノードのタブをクリックし、ノード別設定を行います。
      [個別に設定する] をチェックします。
      [ENI ID] ボックスに、そのノードに対応するインスタンスの ENI ID を設定します(図 6.1 システム構成 SIP 制御による HA クラスタ の [2] [3] が該当)。
      残りのノードの ENI ID の設定も行います。

    7. [完了] をクリックして設定を終了します。

  1. モニタリソースの追加

  • AWS セカンダリ IP 監視リソース

    現用系側のインスタンスに割り当てられている SIP アドレスへの通信を監視することで、SIP アドレスの健全性を確認します。
    詳細は『リファレンスガイド』-「AWS セカンダリ IP 監視リソースを理解する」を参照してください。

    1. Cluster WebUI の設定モード から [モニタリソースの追加] をクリックします。

    2. [モニタリソースの定義] 画面が開きます。
      [タイプ] ボックスでモニタリソースのタイプ (AWS セカンダリ IP 監視リソース) を選択して、[名前] ボックスにリソース名を入力します。
      [次へ] をクリックします。
    3. 監視 (共通) の画面が表示されます。
      対象リソースの [参照] をクリックして、AWS セカンダリ IP リソースのリソース名を選択して、[OK] をクリックします。
      [次へ] をクリックします。
    4. 監視 (固有) の画面が表示されます。
      AWS CLI コマンド応答取得失敗時操作を設定して、[次へ] をクリックします。
    5. 回復動作の画面が表示されます。
      [回復動作] と [回復対象] を設定します。
      詳細は 『リファレンスガイド』-「回復動作タブ」を参照してください。
      [完了] をクリックします。

  1. 設定の反映とクラスタの起動

詳細は『インストール&設定ガイド』-「クラスタを生成するには」を参照してください。

  1. Cluster WebUI の設定モード から、[設定の反映] をクリックします。
    [設定を反映しますか。] というポップアップメッセージが表示されますので、[OK] をクリックします。
    アップロードに成功すると、[反映に成功しました。] のメッセージが表示されますので、[OK] をクリックします。
    アップロードに失敗した場合は、表示されるメッセージに従って操作を行ってください。

  2. Cluster WebUI の ツールバーのドロップダウンメニューで [操作モード] を選択して、操作モードに切り替えます。

  3. Cluster WebUI の [ステータス] タブから [クラスタ開始] をクリックし、確認画面で [開始] をクリックします。

7. DNS 名制御による HA クラスタの設定

本章では、DNS 名制御による HA クラスタの構築手順を説明します。

図中の Server Instance (Active) は現用系サーバ、Server Instance (Standby) は待機系サーバのインスタンスです。

2 つの Availability Zone とそれぞれの中の Server Instance、および Domain Name

図 7.1 システム構成 DNS 名制御による HA クラスタ

CIDR (VPC)

10.0.0.0/16

Domain Name

srv.hz1.local

Public subnet (Subnet-1A)

10.0.10.0/24

Public subnet (Subnet-1B)

10.0.20.0/24

Private subnet (Subnet-2A)

10.0.110.0/24

Private subnet (Subnet-2B)

10.0.120.0/24

7.1. VPC 環境の設定

VPC Management Console、および、EC2 Management Console 上で VPC の構築を行います。

図中および説明中の IP アドレスは一例であり、実際の設定時は VPC に割り当てられている IP アドレスに読み替えてください。既存の VPC に CLUSTERPRO を適用する場合は、不足しているサブネットを追加するなど適切に読み替えてください。

  1. VPC およびサブネットを設定する

    最初に VPC およびサブネットを作成します。

    [1] VPC

    VPC ID （vpc-xxxxxxxx） は後でホストゾーンの追加時に必要となるため、別途控えておきます。

  2. Internet Gateway を設定する。

    VPC からインターネットにアクセスするための Internet Gateway を追加します。

  3. Network ACL/Security Group を設定する

    VPC 内外からの不正なネットワークアクセスを防ぐために、Network ACL、および、Security Group を適切に設定します。

    Private ネットワーク（Subnet-2AおよびSubnet-2B）内に配置予定の HA クラスタノード用のインスタンスから、HTTPS で Internet Gateway と通信可能となるように、また、Cluster WebUI やインスタンス同士の通信も可能となるよう各経路について Network ACL や Security Group の設定を変更します。

    CLUSTERPRO 関連コンポーネントが使用するポート番号については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」を参照し、設定してください。

  4. HA クラスタ用のインスタンスを追加する

    HA クラスタノード用のインスタンスを Private ネットワーク（Subnet-2A、および、Subnet-2B）に作成します。

    IAM ロールをインスタンスに割り当てて使用する場合は、IAM ロールを指定してください。

    ⇒ IAM の設定については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照し、設定してください。

  5. NAT を追加する

    AWS CLI による DNS 名制御処理を実行するために、HA クラスタノード用のインスタンスからリージョンのエンドポイントに対して HTTPS による通信が可能な状態にする必要があります。

    そのために Public ネットワーク（Subnet-1A、および、Subnet-1B）上に NAT ゲートウェイを作成します。

    NAT ゲートウェイの詳細については AWS のドキュメントを参照してください。

  6. ルートテーブルを設定する。

    AWS CLIが NAT 経由でリージョンのエンドポイントと通信可能にするための Internet Gateway へのルーティングを追加します。 Public ネットワーク（図では Subnet-1A、および、Subnet-1B）のルートテーブル（Public-AB）には、以下のルーティングが必要となります。

    • Route Table (Public-AB)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では 10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      Internet Gateway

      追加（必須）
      Private ネットワーク（図では Subnet-2A、および、Subnet-2B）のルートテーブル（Private-A、および Private-B）には、以下のルーティングが必要となります。

    • Route Table (Private-A)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      NAT Gateway1

      追加（必須）

    • Route Table (Private-B)

      Destination

      Target

      備考
      VPC のネットワーク
      （例では10.0.0.0/16)

      local

      最初から存在

      0.0.0.0/0

      NAT Gateway2

      追加（必須）

    その他のルーティングは、環境にあわせて設定してください。

  7. ホストゾーンを追加する

    Amazon Route 53 にホストゾーンを追加します。

    [7] Amazon Route 53 (Hosted Zone)

    Hosted Zone ID は後で AWS DNS リソースの設定時に必要となるため、別途控えておきます。

    なお、本書では、クラスタを Private なサブネット上に配置して VPC 内のクライアントからアクセスする構成を採用しているために Private ホストゾーンを追加していますが、Public なサブネット上に配置してインターネット側の任意のクライアントからアクセスする構成の場合は、Public ホストゾーンを追加してください。

  8. ミラーディスク（Amazon EBS）を追加する 必要に応じてミラーディスク（クラスタパーティション、データパーティション）に使用する Amazon EBS を追加します。

7.2. インスタンスの設定

HA クラスタ用の各インスタンスにログインして以下の設定を実施します。
CLUSTERPRO がサポートしている AWS CLI のバージョンについては、『スタートアップガイド』-「CLUSTERPRO の動作環境」-「AWS DNS リソース、AWS DNS 監視リソースの動作環境」を参照してください。

  1. CLUSTERPRO のサービス起動時間を調整、ネットワーク設定の確認、ファイアウォールの設定を確認、サーバの時刻を同期、 パワーセービング機能を確認

    各手順は以下を参照してください。
    『スタートアップガイド』の「システム構成を決定する」-「ハードウェア構成後の設定」を参照し、設定してください。

  2. AWS CLI のインストール

    AWS CLI をダウンロードして、インストールします。
    システム環境変数 PATH にはインストーラが自動的に追加します。自動的に追加されない場合は、AWS のドキュメント「AWS コマンドラインインターフェイス」を参照して追加してください。
    AWS CLI のインストールを行った時点ですでに CLUSTERPRO がインストール済の場合は、OS を再起動してから CLUSTERPRO の操作を行ってください。

  3. AWS アクセスキー IDの登録

    Administrator ユーザでコマンドプロンプトを起動し、以下のコマンドを実行します。

    > aws configure
    質問に対して、AWS アクセスキー ID などの情報を入力します。
    インスタンスに IAM ロールを割り当てているか否かで 2 通りの設定に分かれます。

    ◇ IAM ロールを割り当てているインスタンスの場合

    AWS Access Key ID [None]: （Enter のみ）
AWS Secret Access Key [None]: （Enter のみ）
Default region name [None]: <既定のリージョン名>
Default output format [None]: text

    ◇ IAM ロールを割り当てていないインスタンスの場合

    AWS Access Key ID [None]: <AWS アクセスキー ID>
AWS Secret Access Key [None]: <AWS シークレットアクセスキー>
Default region name [None]: <既定のリージョン名>
Default output format [None]: text
    "Default output format" は、"text" 以外を指定することも可能です。
    もし誤った内容を設定してしまった場合は、 %SystemDrive%\Users\Administrator\.aws をフォルダごと消去してから上記操作をやり直してください。

  4. ミラーディスクの準備

    ミラーディスク用に Amazon EBS を追加していた場合は、Amazon EBS をパーティション分割し、それぞれクラスタパーティション、データパーティションに使用します。
    ミラーディスク用のパーティションについては、『インストール&設定ガイド』の「システム構成を決定する」-「ミラー用パーティションを設定する (ミラーディスク使用時は必須)」を参照してください。

  5. CLUSTERPRO のインストール

    インストール手順は『インストール&設定ガイド』を参照してください。
    CLUSTERPRO のインストール媒体を導入環境に格納します。
    （データの転送に関しては Remote Desktop、Amazon S3 経由など任意です。）

    インストール完了後、OS の再起動を行ってください。

7.3. CLUSTERPRO の設定

Cluster WebUI のセットアップ、および、接続方法は『インストール&設定ガイド』の「クラスタ構成情報を作成する」を参照してください。

ここでは以下のリソースを追加する手順を記述します。

  • 共通設定

    • Witness ハートビート

    • NP 解決リソース (HTTP NP 方式)

    • AWS 強制停止リソース

    • ミラーディスクリソース

    • AWS AZ 監視リソース

  • 固有設定

    • AWS DNS リソース

    • AWS DNS 監視リソース

共通設定は『4.3. CLUSTERPRO の設定』、上記以外の設定は『インストール&設定ガイド』を参照してください。

  1. グループリソースの追加

  • AWS DNS リソース

    AWS CLI を利用して、DNS 名の制御を行う AWS DNS リソースを追加します。
    詳細は『リファレンスガイド』-「AWS DNS リソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。

    2. [グループのリソース定義 | failover1] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (AWS DNS リソース) を選択して、 [名前] ボックスにグループリソース名 (awsdns1) を入力します。[次へ] をクリックします。

    3. [依存関係] 画面が表示されます。何も指定せず [次へ] をクリックします。

    4. [復旧動作] 画面が表示されます。[次へ] をクリックします。

    5. [詳細] 画面が表示されます。
      [共通] タブの [ホストゾーン ID] ボックスに、ホストゾーンの ID を設定します(図 7.1 システム構成 DNS 名制御による HA クラスタ の [7] が該当)。
      [リソースレコードセット名] ボックスに、付与したい DNS 名を設定します(図 7.1 システム構成 DNS 名制御による HA クラスタ の [5] が該当)。DNS 名は FQDN で、末尾にドット (.) を付けた形式で設定してください。
      [IP アドレス] ボックスに、DNS 名に対応する IP アドレスを設定します(図 7.1 システム構成 DNS 名制御による HA クラスタ の [4] が該当)。
      [共通]タブでは、任意のサーバの IP アドレスを記載し、他のサーバは個別設定を行うようにしてください。
      なお、本書では各サーバの IP アドレスをリソースレコードセットに含める構成を採用しているために上記の手順となっていますが、VIP や EIP をリソースレコードセットに含める場合は、[共通]タブでその IP アドレスを記載し、個別設定は不要です。
      [TTL] ボックスに、キャッシュの生存期間(TTL = Time To Live の略)を設定します。
      TTL の秒数を設定してください。
      [非活性時にリソースレコードセットを削除する]チェックボックスを設定します。
      AWS DNS リソースの非活性時にホストゾーンからリソースレコードセットを削除しない場合、チェックを外してください。
      なお、削除しない場合、残存した DNS 名にクライアントからアクセスされる可能性があります。
    6. 各ノードのタブをクリックし、ノード別設定を行います。
      [個別に設定する] をチェックします。
      [IP アドレス] ボックスに、そのノードに対応するインスタンスの IP アドレスを設定します(図 7.1 システム構成 DNS 名制御による HA クラスタ の [4] [6] が該当)。
      なお、本書では各サーバの IP アドレスをリソースレコードセットに含める構成を採用しているために上記の手順となっていますが、VIP や EIP をリソースレコードセットに含める場合は、本手順は不要です。

    7. [完了] をクリックして設定を終了します。

  1. モニタリソースの追加

  • AWS DNS 監視リソース

    AWS DNS リソース追加時に、自動的に追加されます。
    AWS CLI コマンドを利用してリソースレコードセットの存在と登録した IP アドレスが DNS 名の名前解決によって得られるかを確認します。
    詳細は『リファレンスガイド』-「AWS DNS 監視リソースを理解する」を参照してください。

  1. 設定の反映とクラスタの起動

詳細は『インストール&設定ガイド』-「クラスタを生成するには」を参照してください。

  1. Cluster WebUI の設定モード から、[設定の反映] をクリックします。
    [設定を反映しますか。] というポップアップメッセージが表示されますので、[OK] をクリックします。
    アップロードに成功すると、[反映に成功しました。] のメッセージが表示されますので、[OK] をクリックします。
    アップロードに失敗した場合は、表示されるメッセージに従って操作を行ってください。

  2. Cluster WebUI の ツールバーのドロップダウンメニューで [操作モード] を選択して、操作モードに切り替えます。

  3. Cluster WebUI の [ステータス] タブから [クラスタ開始] をクリックし、確認画面で [開始] をクリックします。

8. NLB を利用した HA クラスタの設定

本章では、Network Load Balancer (以降、NLB) を利用した HA クラスタの構築手順を説明します。

図中の Server Instance (Active) は現用系サーバ、Server Instance (Standby) は待機系サーバのインスタンスです。

2つの Availability Zone とそれぞれの中の Server Instance、および NLB の構成

図 8.1 システム構成 NLB を利用した HA クラスタ

CIDR (VPC)

10.0.0.0/16

Public subnet (Subnet-1A)

10.0.20.0/24

Private subnet (Subnet-2A)

10.0.110.0/24

Private subnet (Subnet-2B)

10.0.120.0/24

Private subnet (Subnet-3A)

10.0.111.0/24

Private subnet (Subnet-3B)

10.0.121.0/24

8.1. VPC 環境の設定

VPC Management Console、および、EC2 Management Console 上で VPC の構築を行います。

図中および説明中の IP アドレスは一例であり、実際の設定時は VPC に割り当てられている IP アドレスに読み替えてください。既存の VPC に CLUSTERPRO を適用する場合は、不足しているサブネットを追加するなど適切に読み替えてください。

  1. VPC およびサブネットを設定する

    最初に VPC およびサブネットを作成します。

  2. Network ACL/Security Group を設定する

    VPC 内外からの不正なネットワークアクセスを防ぐために、Network ACL、および、Security Group を適切に設定します。

    Private ネットワーク (Subnet-3A、Subnet-3B) 内に配置予定の HA クラスタノード用のインスタンスから、Cluster WebUI やインスタンス同士の通信も可能となるよう各経路について Network ACL や Security Group の設定を変更します。

    CLUSTERPRO 関連コンポーネントが使用するポート番号については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」を参照し、設定してください。

  3. HA クラスタ用のインスタンスを追加する

    HA クラスタノード用のインスタンスを Private ネットワーク (Subnet-3A、Subnet-3B) に作成します。

    IAM ロールをインスタンスに割り当てて使用する場合は、IAM ロールを指定してください。

    ⇒ IAM の設定については、『スタートアップガイド』の「注意制限事項」-「CLUSTERPRO インストール前」-「AWS 環境における IAM の設定について」を参照し、設定してください。

  4. ターゲットグループを追加する

    HA クラスタノード用のインスタンスをターゲットとするターゲットグループを作成します。

    設定項目

    設定値

    ヘルスチェックポート

    12345

    間隔

    30 秒

    ターゲット
    HA クラスタノード用のインスタンスを指定
    (図 8.1 システム構成 NLB を利用した HA クラスタ の [1] [2] が該当)

    ヘルスチェックのポート番号には業務で利用しない任意のポートを指定します。 設定したポート番号は後で LB プローブポートリソースの設定時に必要となるため、別途控えておきます。

  5. ロードバランサーを追加する

    作成したターゲットグループをターゲットとする NLB を「内部ロードバランサー」で作成します。

    設定項目

    設定値

    ロードバランサータイプ

    Network Load Balancer

    スキーム

    内部

    ターゲットグループ

    「4. ターゲットグループを追加する」で作成したターゲットグループを指定

    作成後に、NLB の [Attributes] から [Cross-zone load balancing] を有効にします。

8.2. インスタンスの設定

HA クラスタ用の各インスタンスにログインして以下の設定を実施します。

  1. CLUSTERPRO のサービス起動時間を調整、ネットワーク設定の確認、ファイアウォールの設定を確認、サーバの時刻を同期、 パワーセービング機能を確認

    各手順は以下を参照してください。
    『スタートアップガイド』の「システム構成を決定する」-「ハードウェア構成後の設定」を参照し、設定してください。

  2. CLUSTERPRO のインストール

    インストール手順は『インストール&設定ガイド』を参照してください。
    CLUSTERPRO のインストール媒体を導入環境に格納します。
    （データの転送に関しては Remote Desktop、Amazon S3 経由など任意です。）

    インストール完了後、OS の再起動を行ってください。

8.3. CLUSTERPRO の設定

Cluster WebUI のセットアップ、および、接続方法は『インストール&設定ガイド』の「クラスタ構成情報を作成する」を参照してください。

ここでは以下のリソースを追加する手順を記述します。

  • 共通設定

    • Witness ハートビート

    • NP 解決リソース (HTTP NP 方式)

    • AWS 強制停止リソース

    • ミラーディスクリソース

    • AWS AZ 監視リソース

  • 固有設定

    • LB プローブポートリソース

    • LB プローブポート監視リソース

共通設定は『4.3. CLUSTERPRO の設定』、上記以外の設定は『インストール&設定ガイド』を参照してください。

  1. グループリソースの追加

  • LB プローブポートリソース

    ヘルスチェック用のポートを制御する LB プローブポートリソースを追加します。

    詳細は『リファレンスガイド』-「LB プローブポートリソースを理解する」を参照してください。

    【手順】

    1. [グループリソース一覧] で [追加] をクリックします。
    2. [グループのリソース定義 | failover1]] 画面が開きます。
      [タイプ] ボックスでグループリソースのタイプ (LBプローブポートリソース) を選択して、 [名前] ボックスにグループリソース名 (lbpp1) を入力します。[次へ] をクリックします。
    3. [依存関係] 画面が表示されます。
      何も指定せず [次へ] をクリックします。
    4. [復旧動作] 画面が表示されます。
      [次へ] をクリックします。
    5. [詳細] 画面が表示されます。
      [ポート番号] ボックスに、ヘルスチェック用のポート番号を設定します。
    6. [調整] をクリックすると、[LBプローブポートリソース調整プロパティ] 画面が表示されます。
      [ヘルスチェックのタイムアウト] ボックスに、ヘルスチェックのタイムアウトの待ち時間 (秒) を設定します。
      [ヘルスチェックのタイムアウト] は、NLB のヘルスチェックの間隔より長く設定する必要があります。
      本書では、NLB のヘルスチェックの間隔を 30 秒で設定しているため、[ヘルスチェックのタイムアウト] は 31 秒以上に設定します。

    7. [完了] をクリックして設定を終了します。

  1. モニタリソースの追加

  • LB プローブポート監視リソース

    LB プローブポートリソース追加時に、自動的に追加されます。
    LB プローブポートリソースが起動しているノードに対して、LB プローブポートリソース活性時に起動する制御プロセスの死活監視を行います。
    詳細は 『リファレンスガイド』 -「LB プローブポート監視リソースを理解する」を参照してください。

  1. 設定の反映とクラスタの起動

  1. Cluster WebUI の設定モードから、[設定の反映] をクリックします。
    「設定を反映しますか。」 というポップアップメッセージが表示されるので、[OK] をクリックします。
    アップロードに成功すると、[反映に成功しました。] のメッセージが表示されますので、[OK] をクリックします。
    アップロードに失敗した場合は、表示されるメッセージに従って操作を行ってください。

  2. Cluster WebUI のツールバーのドロップダウンメニューで [操作モード] を選択して、操作モードに切り替えます。

  3. Cluster WebUI の [ステータス] タブから [クラスタ開始] をクリックし、確認画面で [開始] をクリックします。

9. トラブルシューティング

本章では、AWS 環境において CLUSTERPRO の設定が上手くいかない時の確認事項と対処方法について説明します。

◆ AWS 関連リソースおよび監視リソース起動に失敗する。

まず OS が再起動済であること、AWS CLI がインストールされていること、AWS CLI の設定が正しく完了していることを確認してください。
CLUSTERPRO のインストール時に再起動を行っていた場合でも、その後に AWS CLI のインストールに伴いシステム環境変数の設定変更が発生する場合は OS の再起動を行ってください。

◆ AWS 仮想 IP リソースの起動に失敗する。

Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(51 : AWS CLI コマンドが見つかりませんでした。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI が未インストール、またはパスが通っていない。

対処方法
以下を確認します。

  • AWS CLI がインストールされていることを確認します。

  • システム環境変数 PATHに、aws.exe へのパスが設定されていることを確認します。

Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(50 : AWS CLI コマンドに失敗しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI 設定が未設定（aws configure 未実行）。

  • AWS CLI 設定（%SystemDrive%\Users\Administrator\.aws 配下のファイル）が見つからない（aws configure を Administrator 以外で実行した）。

  • AWS CLI 設定の入力内容誤り（リージョン、アクセスキー ID、シークレットキー入力誤り）。

  • （IAM ロールを使用した運用の場合）インスタンスへの IAM ロール未設定。
    IAM ロールを使用する方針の場合、該当インスタンスから以下へアクセスし、設定している IAM ロール名が表示されるか確認してください。「404 Not Found」になった場合は IAM ロールが設定されていません。
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

  • 指定した VPC ID、または、ENI ID が不正。

  • リージョンのエンドポイントがメンテナンスや障害のため停止している。

  • リージョンのエンドポイントまでの通信路の問題。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • AWS CLI の設定を正しい内容に修正し、AWS CLI が正常に動作することを確認します。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

  • （IAM ロールを使用した運用の場合）AWS 管理コンソールで設定を確認してください。

Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(50 : The vpc ID 'vpc-xxxxxxxx' does not exist)
考えられる原因
指定した VPC ID が誤っているか、または存在しない可能性が考えられます。
対処方法
正しい VPC ID を指定します。
Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(50 : The networkInterface ID 'eni-xxxxxxxx' does not exist)
考えられる原因
指定した ENI ID が誤っているか、または存在しない可能性が考えられます。
対処方法
正しい ENI ID を指定します。
Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(50 : You are not authorized to perform this operation.)
考えられる原因
IAM ロールの ReplaceRoute 権限について実行できるルートテーブルを制限している場合、IAM ポリシーの Resource に指定したルートテーブルに誤り、または不足がある可能性があります。
対処方法
AWS 仮想 IP リソースはルートテーブル更新時、指定された VPC 配下のすべてのルートテーブルのうち、指定された仮想 IP アドレスのエントリが存在するルートテーブルについて更新を行います。
そのため IAM ポリシーの Resource には、該当する(更新対象となる)ルートテーブルすべてについて許可を設定してください。
Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(9 : タイムアウトが発生しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI コマンドがルートテーブルや NAT の設定ミスやプロキシサーバーなどの理由でリージョンのエンドポイントと通信できない状態である可能性が考えられます。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • NAT ゲートウェイへのルーティングが設定済みであること。

  • パケットがフィルタリングで落とされていないこと。

  • ルートテーブル、NAT、プロキシサーバーの設定を確認してください。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

Cluster WebUI のメッセージ
リソース awsvip1 の起動に失敗しました。(53 : VIP アドレスが VPC のサブネットに属しています。)
考えられる原因
指定した VIP アドレスが VPC CIDR 範囲内のため不適切です。
対処方法
VIP アドレスに VPC CIDR の範囲外となる IP アドレスを指定します。

◆ AWS 仮想 IP リソースは正常に起動しているが、VIP アドレスに対する ping が通らない。

Cluster WebUI のメッセージ
-
考えられる原因

AWS 仮想 IP リソースに設定した ENI の Source/Dest. Check が有効になっています。

対処方法

AWS 仮想 IP リソースに設定した ENI の Source/Dest. Check を無効に設定します。

◆ AWS 仮想 IP 監視リソースが異常になる。

Cluster WebUI のメッセージ
監視 awsvipw1 は異常を検出しました。 (56 : VIP のルーティングが変更されました。)
考えられる原因

ルートテーブルにおいて、AWS 仮想 IP リソースに対応する VIP アドレスのターゲットがなんらかの理由で別の ENI ID に変更されている。

対処方法
異常を検知した時点で AWS 仮想 IP リソースが自動的に再起動され、ターゲットが正しい ENI ID に更新されます。
別の ENI ID に変更された原因として、他の HA クラスタで同じ VIP アドレスを誤って使用していないかなどを確認します。

◆ AWS Elastic IP リソースの起動に失敗する。

Cluster WebUI のメッセージ
リソース awseip1 の起動に失敗しました。(51 : AWS CLI コマンドが見つかりませんでした。)
考えられる原因
AWS CLI が未インストール、またはパスが通っていない。
対処方法
以下を確認します。

  • AWS CLI がインストールされていることを確認します。

  • システム環境変数 PATH に、aws.exe へのパスが設定されていることを確認します。

Cluster WebUI のメッセージ
リソース awseip1 の起動に失敗しました。(50 : AWS CLI コマンドに失敗しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI 設定が未設定（aws configure 未実行）。

  • AWS CLI 設定（%SystemDrive%\Users\Administrator\.aws 配下のファイル）が見つからない（aws configure を Administrator 以外で実行した）。

  • AWS CLI 設定の入力内容誤り（リージョン、アクセスキー ID、シークレットキー入力誤り）。

  • （IAM ロールを使用した運用の場合）インスタンスへの IAM ロール未設定。
    IAM ロールを使用する方針の場合、該当インスタンスから以下へアクセスし、設定している IAM ロール名が表示されるか確認してください。「404 Not Found」になった場合は IAM ロールが設定されていません。
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

  • 指定した EIP Allocation ID、または、ENI ID が不正。

  • リージョンのエンドポイントがメンテナンスや障害のため停止している。

  • リージョンのエンドポイントまでの通信路の問題。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • AWS CLI の設定を正しい内容に修正し、AWS CLI が正常に動作することを確認します。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

  • （IAM ロールを使用した運用の場合）AWS 管理コンソールで設定を確認してください。

Cluster WebUI のメッセージ
リソース awseip1 の起動に失敗しました。(50 : The allocation ID 'eipalloc-xxxxxxxx' does not exist )
考えられる原因
指定した EIP Allocation ID が誤っているか、または存在しない可能性が考えられます。
対処方法
正しい EIP Allocation ID を指定します。
Cluster WebUI のメッセージ
リソース awseip1 の起動に失敗しました。(50 : The networkInterface ID 'eni-xxxxxxxx' does not exist )
考えられる原因
指定した ENI ID が誤っているか、または存在しない可能性が考えられます。
対処方法
正しい ENI ID を指定します。
Cluster WebUI のメッセージ
リソース awseip1 の起動に失敗しました。(53 : タイムアウトが発生しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI コマンドがルートテーブルや NAT の設定ミスやプロキシサーバーなどの理由でリージョンのエンドポイントと通信できない状態である可能性が考えられます。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • 各インスタンスに Public IP が割り当てられていることを確認します。

  • 各インスタンスで AWS CLI が正常に動作することを確認します。

  • ルートテーブル、NAT、プロキシサーバーの設定を確認してください。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

◆ AWS Elastic IP 監視リソースが異常になる。

Cluster WebUI のメッセージ
監視 awseipw1 は異常を検出しました。 (52 : EIP アドレスが存在しません。)
考えられる原因
指定した ENI ID と Elastic IP の関連付けが何らかの理由で解除されている。
対処方法
異常を検知した時点で AWS Elastic IP リソースが自動的に再起動され、指定した ENI ID と Elastic IP の関連付けが行われます。
Elastic IP との関連付けが変更された原因として、他の HA クラスタで同じ EIP Allocation ID を誤って使用していないかなどを確認します。

◆ AWS セカンダリ IP リソースの起動に失敗する。

Cluster WebUI のメッセージ
リソース awssip1 の起動に失敗しました。 (50 : AWS CLI コマンドが見つかりませんでした。)
考えられる原因
AWS CLI が未インストール、またはパスが通っていない。
対処方法
以下を確認します。

  • AWS CLI がインストールされていることを確認します。

  • システム環境変数 PATH に、aws.exe へのパスが設定されていることを確認します。

Cluster WebUI のメッセージ
リソース awssip1 の起動に失敗しました。 (54 : DHCP の確認処理に失敗しました。)
考えられる原因
ネットワークアダプタのプライベート IP アドレスを静的に設定していない。
対処方法
ネットワークアダプタのプライベート IP アドレスを静的に設定してください。
Cluster WebUI のメッセージ
リソース awssip1 の起動に失敗しました。 (55 : AWS 側のセカンダリ IP アドレスの割り当てに失敗しました。(Address does not fall within the subnet's address range))
考えられる原因
設定したセカンダリ IP アドレスが不正。
対処方法
正しいセカンダリ IP アドレスを指定します。
Cluster WebUI のメッセージ
リソース awssip1 の起動に失敗しました。 (68 : プライマリプライベート IP アドレスの取得に失敗しました。(The AWS CLI command failed.) )
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI 設定が未設定（aws configure 未実行）。

  • AWS CLI 設定（%SystemDrive%\Users\Administrator\.aws 配下のファイル）が見つからない（aws configure を Administrator 以外で実行した）。

  • AWS CLI 設定の入力内容誤り（リージョン、アクセスキー ID、シークレットキー入力誤り）。

  • （IAM ロールを使用した運用の場合）インスタンスへの IAM ロール未設定。
    IAM ロールを使用する方針の場合、該当インスタンスから以下へアクセスし、設定している IAM ロール名が表示されるか確認してください。「404 Not Found」になった場合は IAM ロールが設定されていません。
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

  • 指定した ENI ID が不正。

  • リージョンのエンドポイントがメンテナンスや障害のため停止している。

  • リージョンのエンドポイントまでの通信路の問題。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • AWS CLI の設定を正しい内容に修正し、AWS CLI が正常に動作することを確認します。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

  • （IAM ロールを使用した運用の場合）AWS 管理コンソールで設定を確認してください。

Cluster WebUI のメッセージ
リソース awssip1 の起動に失敗しました。 (68 : プライマリプライベート IP アドレスの取得に失敗しました。(The networkInterface ID 'eni-xxxxxxxx' does not exist) )
考えられる原因
指定した ENI ID が誤っているか、または存在しない可能性が考えられます。
対処方法
正しい ENI ID を指定します。

◆ AWS セカンダリ IP 監視リソースが異常になる。

Cluster WebUI のメッセージ
監視 awssipw1 は異常を検出しました。 (58 : OS 側のセカンダリ IP アドレスの確認処理に失敗しました。)
考えられる原因
指定したセカンダリ IP アドレスが何らかの理由で削除されている。
対処方法
異常を検知した時点で AWS セカンダリ IP リソースが自動的に再起動され、指定したセカンダリ IP アドレスを付与します。
セカンダリ IP アドレスが削除された原因として、セカンダリ IP アドレスを他で使用していないかなどを確認します。

◆ AWS DNS リソースの起動に失敗する。

Cluster WebUI のメッセージ
リソース awsdns1 の起動に失敗しました。(52 : AWS CLI コマンドが見つかりませんでした。)
考えられる原因

AWS CLI が未インストール、またはパスが通っていない。

対処方法
以下を確認します。

  • AWS CLI がインストールされていることを確認します。

  • システム環境変数 PATH に、aws.exe へのパスが設定されていることを確認します。

Cluster WebUI のメッセージ
リソース awsdns1 の起動に失敗しました。(50 : AWS CLI コマンドに失敗しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI 設定が未設定（aws configure 未実行）。

  • AWS CLI 設定（%SystemDrive%\Users\Administrator\.aws 配下のファイル）が見つからない（aws configure を Administrator 以外で実行した）。

  • AWS CLI 設定の入力内容誤り（リージョン、アクセスキー ID 、シークレットキー入力誤り）。

  • （IAM ロールを使用した運用の場合）インスタンスへの IAM ロール未設定。
    IAM ロールを使用する方針の場合、該当インスタンスから以下へアクセスし、設定している IAM ロール名が表示されるか確認してください。「404 Not Found」になった場合は IAM ロールが設定されていません。
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

  • 指定したリソースレコードセットが不正。

  • リージョンのエンドポイントがメンテナンスや障害のため停止している。

  • リージョンのエンドポイントまでの通信路の問題。

  • ノードの高負荷による遅延。

  • Route 53 にアクセスできない状態もしくは Route 53 が応答しない状態。

  • Route 53 の当該ホストゾーンが対象とする VPC に、HA インスタンスが所属する VPC を追加していない。

  • HA インスタンスが所属する VPC で DNS 名前解決を有効にしていない。

  • [リソースレコードセット名] が大文字で指定されている。

  • 該当ネットワークのインターネットプロトコルバージョン4 (TCP/IPv4) のプロパティにおいて優先 DNS サーバの設定が不正。

  • 以下のコマンドをノード (インスタンス) 上の端末から手動で実行してください。
    > aws route53 list-resource-record-sets --hosted-zone-id <ホストゾーンID>
    「Could not connect to the endpoint URL」エラーが表示される場合、以下のいずれかが考えられます。
    - VPC エンドポイントを使用している場合、VPC エンドポイントは Route 53 のサービスには未対応のため、VPC エンドポイントを使用している場合は AWS DNS リソース/監視リソースは利用できません。
    - VPC エンドポイントを使用していない場合、AWS 上の設定の問題が考えられます。
対処方法
以下を確認します。

  • AWS CLI の設定を正しい内容に修正し、AWS CLI が正常に動作することを確認します。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

  • Route 53 マネジメントコンソールの「当該ホストゾーン」について、「関連付けられた VPC」に必要な VPC が追加されていることを確認してください。

  • VPC マネジメントコンソールにおいて、使用している VPC のプロパティで「DNS 解決」が有効になっていることを確認してください。意図的に「DNS 解決」を無効にしている場合は、インスタンスが AWS DNS リソースで追加したレコードセットを名前解決できるように適切なリゾルバを設定してください。

  • [リソースレコードセット名] は小文字で指定してください。

  • 優先 DNS サーバの設定を正しい内容に修正します。

  • VPC エンドポイントを使用している場合、NAT ゲートウェイ、Proxy サーバのいずれかの方法に変更することを検討してください。VPC エンドポイントを使用していない場合、AWS へ確認してください。

  • （IAM ロールを使用した運用の場合）AWS 管理コンソールで設定を確認してください。

Cluster WebUI のメッセージ
リソース awsdns1 の起動に失敗しました。(50 : No hosted zone found with ID: %1)
考えられる原因
指定したホストゾーンIDが誤っているか、または存在しない可能性が考えられます。
対処方法
正しいホストゾーンIDを指定します。
Cluster WebUI のメッセージ
リソース awsdns1 の起動に失敗しました。(51 : タイムアウトが発生しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI コマンドがルートテーブルや NAT の設定ミスやプロキシサーバーなどの理由でリージョンのエンドポイントと通信できない状態である可能性が考えられます。

  • ノードの高負荷による遅延。

  • Route 53 エンドポイント側の処理遅延。

  • AWS CLI 内部で実行されるインスタンスメタデータに対するアクセスが遅延。

対処方法
以下を確認します。

  • NAT ゲートウェイへのルーティングが設定済みであること。

  • パケットがフィルタリングで落とされていないこと。

  • ルートテーブル、NAT、プロキシサーバーの設定を確認してください。

  • AWS 環境において監視 (共通) の [タイムアウト] が AWS CLI 実行に必要な時間以上の値を設定していること。AWS DNS 監視リソースは以下の AWS CLI を実行しています。手動にて AWS CLI を実行し、必要な時間を計測してください。

    > aws route53 list-resource-record-sets
  • （IAM ロールを使用した運用の場合）CLUSTERPRO の AWS DNS リソースおよび監視リソースが AWS CLI を実行する際に、インスタンスメタデータからアクセスキー ID などの認証情報を取得します。
    インスタンスメタデータに対するアクセスに遅延がないか、手動で以下のコマンドを実行に必要な時間を確認してください。
    どちらかひとつでも遅延がある場合はアクセスの遅延が発生しています。
    遅延がある場合は、aws configure コマンドにより、各クラスタノードにアクセスキー ID およびシークレットアクセスキーの設定を追加し、IAM ユーザで実行されるようにすることで、タイムアウトの発生確率が減少する可能性があります。
    - 各クラスタノードから http://169.254.169.254/latest/meta-data/ にブラウザまたは curl コマンドなどでアクセス。
    - クラスタノードのいずれかにおいて aws configure list を実行。

◆ AWS DNS リソースは正常に起動しているが、クライアントから名前解決できるようになるまでに時間が掛かる。

Cluster WebUI のメッセージ
－
考えられる原因
以下のいずれかが考えられます。
  • Route 53 の仕様により、Route 53 の設定が権威サーバすべてに反映されるまでに最大60秒掛かります。以下を参照してください。
    https://aws.amazon.com/jp/route53/faqs/
    Amazon Route 53 のよくある質問
    Q:Amazon Route 53 での DNS 設定の変更が全体に適用されるには、どのくらいの時間がかかりますか。

  • OS 側のリゾルバにより時間が掛かっている。

  • フェイルオーバー時に AWS DNS リソースによるリソースレコードセットの削除と作成に時間が掛かっている。
    [非活性時にリソースレコードセットを削除する] がチェックが ON の場合、フェイルオーバー元で AWS DNS リソース非活性時にリソースレコードセットを削除後、フェイルオーバー先で AWS DNS リソース活性時にリソースレコードセットを作成となるため、名前解決可能になるまでの時間が遅くなる可能性があります。
    チェックが OFF の場合、非活性時にもリソースレコードセットが削除されなくなり、該当リソースレコードセットの IP アドレス更新のみとなるため、名前解決可能になるまでの時間が短縮される可能性があります。
    チェックを OFF にした場合は、通常の AWS DNS リソース非活性時やクラスタ停止後にもリソースレコードセットは削除されずに残りますので、ご留意ください。AWS DNS リソース非活性後やクラスタ停止後でも名前解決されます。

  • AWS DNS リソースの [TTL] の値が大きい。

  • AWS DNS 監視リソースの [監視開始待ち時間] の値が小さい。
    もし Route 53 の変更が反映完了する前に名前解決を試みてしまうと DNS からは NXDOMAIN (存在しないドメイン) が返りますが、その場合はネガティブキャッシュの有効期間 (例. Windows の既定値は 900 秒)が経過するまでは名前解決に失敗します。
    そのため、[監視開始待ち時間]を小さい値に設定していると、名前解決可能になるまでに長時間を要する結果となる可能性があります。
対処方法
以下を確認します。

  • OS 側のリゾルバの設定を見直してください。

  • AWS DNS リソースの [非活性時にリソースレコードセットを削除する] を OFF にします。

  • AWS DNS リソースの [TTL] の値を小さい値に設定します。

  • AWS DNS 監視リソースの [監視開始待ち時間] の値を許容できる大きな値に設定します。

◆ AWS DNS 監視リソースが異常になる。

Cluster WebUI のメッセージ
監視 awsdnsw1 は異常を検出しました。 (52 : Amazon Route 53 にリソースレコードセットが存在しません。)
考えられる原因
以下のいずれかが考えられます。

  • ホストゾーンにおいて、 AWS DNS リソースに対応するリソース レコードセットがなんらかの理由で削除されている。

  • AWS DNS リソースの活性直後、Route 53 における DNS 設定の変更が反映される前に、AWS DNS 監視リソースが監視を実行すると名前解決ができないため監視に失敗します。『スタートアップガイド』-「注意制限事項」-「AWS DNS 監視リソースの設定について」を参照してください。

  • IAM ポリシーの route53:ChangeResourceRecordSets、route53:ListResourceRecordSets が未設定。

  • Route 53 の当該ホストゾーンが対象とするVPCに、HA インスタンスが所属するVPCを追加していない。

  • [リソースレコードセット名] に設定した DNS 名の末尾にドット (.) が付与されていない。

対処方法
以下を確認します。

  • リソースレコードセットが削除された原因として、他の HA クラスタで同じリソースレコードセットを誤って使用していないこと。

  • AWS DNS 監視リソースの [監視開始待ち時間] が Route 53 における DNS 設定の変更が反映される時間より長く設定されていること。

  • IAM ポリシーに route53:ChangeResourceRecordSets、route53:ListResourceRecordSets が設定されていること。

  • Route 53 マネジメントコンソールの「当該ホストゾーン」について、「関連付けられた VPC」に必要な VPC が追加されていること。

  • [リソースレコードセット名] に設定した DNS 名が FQDN で、末尾にドット (.) を付けた形式で設定されていること。

Cluster WebUI のメッセージ
監視 awsdnsw1 は異常を検出しました。 (53 : 設定とは異なる IP アドレスが Amazon Route 53 のリソースレコードセットに登録されています。)
考えられる原因
ホストゾーンにおいて、 AWS DNS リソースに対応するリソース レコードセットの IP アドレスがなんらかの理由で変更されている。
対処方法
リソースレコードセットが変更された原因として、他の HA クラスタで同じリソースレコードセットを誤って使用していないかなどを確認します。
Cluster WebUI のメッセージ
監視 awsdnsw1 は異常を検出しました。 (54 : 名前解決確認に失敗しました。)
考えられる原因
リソースレコードセットとしてホストゾーンに登録した DNS 名での名前解決確認がなんらかの理由で失敗した。
対処方法
以下を確認します。

  • リゾルバの設定に誤りがないこと。

  • ネットワークの設定に誤りがないこと。

  • Public ホストゾーンを使用している場合は、レジストラのネームサーバ (NS) レコードの設定で、ドメインへのクエリが Amazon Route 53 ネームサーバを参照するようになっていること。

Cluster WebUI のメッセージ
監視 awsdnsw1 は異常を検出しました。 (55 : 名前解決結果が設定と異なる IP アドレスです。)
考えられる原因
リソースレコードセットとしてホストゾーンに登録した DNS 名での名前解決確認で得られた IP アドレスが正しくない。
対処方法
以下を確認します。

  • リゾルバの設定に誤りがないこと。

  • hosts ファイル中に DNS 名に関するエントリが存在しないこと。

◆ AWS DNS 監視リソースが警告または異常になる。

Cluster WebUI のメッセージ
[警告時]
監視 awsdnsw1 は警告の状態です。 (151 : タイムアウトが発生しました。)
[異常時]
監視 awsdnsw1 は異常を検出しました。 (51 : タイムアウトが発生しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI コマンドがルートテーブルや NAT の設定ミスやプロキシサーバーなどの理由でリージョンのエンドポイントと通信できない状態である可能性が考えられます。

  • ノードの高負荷による遅延。

  • Route 53 エンドポイント側の処理遅延。

  • AWS CLI 内部で実行されるインスタンスメタデータに対するアクセスが遅延。

対処方法
以下を確認します。

  • NAT ゲートウェイへのルーティングが設定済みであること。

  • パケットがフィルタリングで落とされていないこと。

  • ルートテーブル、NAT、プロキシサーバーの設定を確認してください。

  • AWS 環境において監視 (共通) の [タイムアウト] が AWS CLI 実行に必要な時間以上の値を設定していること。AWS DNS 監視リソースは以下の AWS CLI を実行しています。手動にて AWS CLI を実行し、必要な時間を計測してください。
    > aws route53 list-resource-record-sets
  • （IAM ロールを使用した運用の場合）CLUSTERPRO の AWS DNS リソースおよび監視リソースが AWS CLI を実行する際に、インスタンスメタデータからアクセスキー ID などの認証情報を取得します。
    インスタンスメタデータに対するアクセスに遅延がないか、手動で以下のコマンドを実行に必要な時間を確認してください。
    どちらかひとつでも遅延がある場合はアクセスの遅延が発生しています。
    遅延がある場合は、aws configure コマンドにより、各クラスタノードにアクセスキー ID およびシークレットアクセスキーの設定を追加し、IAM ユーザで実行されるようにすることで、タイムアウトの発生確率が減少する可能性があります。
    - 各クラスタノードから http://169.254.169.254/latest/meta-data/ にブラウザまたは curl コマンドなどでアクセス。
    - クラスタノードのいずれかにおいて aws configure list を実行。

◆ LB プローブポートリソースが異常になる。

Cluster WebUI のメッセージ
[異常時]
Port <ポート番号> is already used.
考えられる原因
ポートが既に使用されている。
対処方法
指定したポートが他のプロセスによって使用されていないか確認してください。

◆ LB プローブポートモニタリソースが異常になる。

Cluster WebUI のメッセージ
[異常時]
Port <ポート番号> is closed.
考えられる原因
ポートが既に使用されている。
対処方法
指定したポートが他のプロセスによって使用されていないか確認してください。

◆ LB プローブポートモニタリソースが警告または異常になる。

Cluster WebUI のメッセージ
[異常時]
Timeout of waiting port <ポート番号> occurred.
考えられる原因
ヘルスチェックのタイムアウト内にロードバランサーからのヘルスチェックを受信できなかった。
対処方法
以下を確認します。

  • ネットワークの設定に誤りがないこと

  • ロードバランサーの設定に誤りがないこと

◆ AWS AZ 監視リソースが警告または異常になる。

Cluster WebUI のメッセージ
[警告時]
監視 awsazw1 は警告の状態です。 (105 : AWS CLI コマンドに失敗しました。)
[異常時]
監視 awsazw1 は異常を検出しました。 (5 : AWS CLI コマンドに失敗しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI 設定が未設定（aws configure 未実行）。

  • AWS CLI 設定（%SystemDrive%\Users\Administrator\.aws 配下のファイル）が見つからない（aws configure を Administrator 以外で実行した）。

  • AWS CLI 設定の入力内容誤り（リージョン、アクセスキー ID、シークレットキー入力誤り）。

  • （IAM ロールを使用した運用の場合）インスタンスへの IAM ロール未設定。
    IAM ロールを使用する方針の場合、該当インスタンスから以下へアクセスし、設定している IAM ロール名が表示されるか確認してください。「404 Not Found」になった場合は IAM ロールが設定されていません。
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

  • 指定した アベイラビリティーゾーンが不正。

  • リージョンのエンドポイントがメンテナンスや障害のため停止している。

  • リージョンのエンドポイントまでの通信路の問題。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • AWS CLI の設定を正しい内容に修正し、AWS CLI が正常に動作することを確認します。

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

  • 頻繁に警告が表示される場合は、「回復動作を実行しない (警告を表示しない)」へ変更することを推奨します。この場合でも、監視リソースから実行する AWS CLI の実行失敗や応答遅延以外のエラーは検知可能です。

  • （IAM ロールを使用した運用の場合）AWS 管理コンソールで設定を確認してください。

Cluster WebUI のメッセージ
[警告時]
監視 awsazw1 は警告の状態です。 (105 : Invalid availability zone: [ap-northeast-1x] )
[異常時]
監視 awsazw1 は異常を検出しました。 (5 : Invalid availability zone: [ap-northeast-1x])
考えられる原因
指定したアベイラビリティーゾーンが誤っているか、または存在しない可能性が考えられます。
対処方法
正しいアベイラビリティーゾーンを指定します。
Cluster WebUI のメッセージ
[警告時]
監視 awsazw1 は警告の状態です。 (106 : タイムアウトが発生しました。)
[異常時]
監視 awsazw1 は異常を検出しました。 (6 : タイムアウトが発生しました。)
考えられる原因
以下のいずれかが考えられます。

  • AWS CLI コマンドがルートテーブルや NAT の設定ミスやプロキシサーバーなどの理由でリージョンのエンドポイントと通信できない状態である可能性が考えられます。

  • ノードの高負荷による遅延。

対処方法
以下を確認します。

  • NAT ゲートウェイへのルーティングが設定済みであること。

  • パケットがフィルタリングで落とされていないこと。

  • ルートテーブル、NAT、プロキシサーバーの設定を確認してください。

  • AWS 環境において監視 (共通) の [タイムアウト] が AWS CLI 実行に必要な時間以上の値を設定していること。AWS AZ 監視リソースは以下の AWS CLI を実行しています。手動にて AWS CLI を実行し、必要な時間を計測してください。
    > aws ec2 describe-availability-zones

  • ノードの高負荷の場合は、負荷要因を取り除いてください。

10. 注意・制限事項

10.1. VPC で CLUSTERPRO を利用する場合の注意事項

VPC 環境で CLUSTERPRO を利用する際に、以下のような注意事項があります。

インターネットまたは異なる VPC からのアクセス

AWS 側の仕様により、インターネットまたは異なる VPC 上のクライアントから、AWS 仮想 IP リソースで付与した VIP アドレスを指定してアクセスすることはできないことを確認しています。インターネット上の クライアントからアクセスする場合は、AWS Elastic IP リソースで付与した EIP アドレスを指定してアクセスしてください。異なる VPC 上のクライアントからアクセスする場合は、AWS DNS リソースによって Amazon Route 53 に登録した DNS 名を指定して、VPC ピアリング接続経由でアクセスしてください。

また、以下の CLUSTERPRO オフィシャルブログも参考にしてください。
https://jpn.nec.com/clusterpro/blog/20190610.html

異なる VPC からの VPC ピアリング接続経由でのアクセス

AWS 仮想 IP リソースは、 VPC ピアリング接続を経由してのアクセスが必要な場合では利用することができません。これは、 VIP として使用する IP アドレスが VPC の範囲外であることを前提としており、このような IP アドレスは VPC ピアリング接続では無効とみなされるためです。 VPC ピアリング接続を経由してのアクセスが必要な場合は、 Amazon Route 53 を利用する AWS DNS リソースを使用してください。

VPC エンドポイントの使用

VPC エンドポイントを使用することで、プライベートネットワークでも NAT やプロキシサーバを用意することなく AWS CLI による Amazon EC2 のサービス制御が可能です。そのため「VIP 制御による HA クラスタ」構成において NAT の代わりに VPC エンドポイントを使用することが可能となります。なお、VPC エンドポイントは作成時にサービス名が ".ec2" で終わるものを選択する必要があります。

また、VPC エンドポイントを使用する場合でも、インスタンスのオンラインアップデートやモジュールダウンロードのためのインターネットアクセス、および、VPC エンドポイントが対応していない AWS のクラウドサービスに対するアクセスを行う場合は、別途 NAT ゲートウェイなどが必要になります。

CLUSTERPRO では VPC エンドポイントを明示的に指定することはできません。
AWS CLI が自動で選択した VPC エンドポイントを使用します。

グループリソースおよびモニタリソースの機能制限

ミラーディスクの性能

Multi-AZ 間で HA クラスタを構築すると、インスタンス間の距離が離れることによる TCP/IP の応答遅延が発生し、ミラーリングに影響を受ける可能性があります。
また、マルチテナントのため、他のシステムの使用状況がミラーリングの性能に影響を与えます。上記の理由から クラウド環境では、物理環境や一般的な仮想化環境(非クラウド環境)に比べてミラーディスクの性能の差が大きくなる(ミラーディスクの性能の劣化率が大きくなる)傾向にあります。
書き込み性能を重視するシステムの場合には、設計のフェーズにおいて、この点をご留意ください。

クラスタ外からの OS シャットダウン

AWS 環境では EC2 Management Console や CLI などによるクラスタ外からの OS のシャットダウン (インスタンスの停止) が可能です。
クラスタ外からの OS シャットダウンが実行されると、クラスタ停止処理を適切に行えない場合があります。
この事象を回避するために、clpstdncnf を使用してください。clpstdncnf コマンドの詳細については『リファレンスガイド』-「CLUSTERPRO コマンドリファレンス」-「クラスタ外からの操作による OS シャットダウン時の動作を設定する (clpstdncnf コマンド)」を参照してください。
ただし、AWS 環境では EC2 Management Console、AWS CLI などから OS シャットダウンを行った場合、OS シャットダウンに時間を要すると AWS 側からインスタンスを強制的に停止することがあります。
インスタンスを強制的に停止するまでの時間は AWS では非公開であり、変更できません。

AWS エンドポイント停止の影響

AWS DNS 監視リソースは、リソースレコードセットの存在確認のために AWS CLI を利用しています。
そのため AWS エンドポイントのメンテナンスや障害およびネットワーク経路の障害や遅延の影響によるフェイルオーバを発生させないためには、AWS DNS 監視リソースの [AWS CLI コマンド応答取得失敗時動作] の設定は、「回復動作を実行しない (警告を表示する) 」「回復動作を実行しない (警告を表示しない) 」のいずれかとしてください。
頻繁に警告が表示される場合は、「回復動作を実行しない (警告を表示しない) 」を推奨します。