Hitachi

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

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制御による業務通信の切り替えの動作は，次のとおりです。番号は，図中の番号と対応しています。

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

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

    Destination

    Target

    備考

    VPCのネットワーク

    (例：10.0.0.0/16)

    local

    -

    0.0.0.0/0

    Internet gateway

    -

    （空白）

    （空白）

    削除
    （凡例）

    -：特にありません。

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

  3. 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)

    追加
    （凡例）

    -：特にありません。

  4. HAモニタは，OSのipコマンドを実行することによって，ネットワークインタフェースに待機系インスタンスに対するVIPを追加する。

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

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

ページの先頭へ

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

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

これらの構成には，トランジットゲートウェイが必要です。トランジットゲートウェイの詳細については，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のルーティングの動作は，次のとおりです。番号は，図中の番号と対応しています。

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

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

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

    Destination

    Target

    VIP（10.10.10.10/32）

    tgw-R2

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

  2. トランジットゲートウェイルートテーブル（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）に転送されます。

  3. トランジットゲートウェイルートテーブル（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）に転送されます。

  4. ルートテーブル（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を削除する動作は，次のとおりです。番号は，図中の番号と対応しています。

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

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

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

    Destination

    Target

    （空白）

    （空白）

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

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

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

    Destination

    Target

    （空白）

    （空白）

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

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

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

    Destination

    Target

    （空白）

    （空白）

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

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

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

    Destination

    Target

    （空白）

    （空白）

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

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

メモ

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

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

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

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

[図データ]

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

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

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

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

    Destination

    Target

    VIP（10.10.10.10/32）

    eni-yyyy

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

  2. トランジットゲートウェイルートテーブル（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に転送されます。

  3. トランジットゲートウェイルートテーブル（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）に転送されます。

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

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

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

    Destination

    Target

    VIP（10.10.10.10/32）

    tgw-R1

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

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

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

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

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

ページの先頭へ

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

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

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

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

[図データ]

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

ページの先頭へ

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

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

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

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

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

[図データ]

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

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

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

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

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

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

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

ページの先頭へ

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

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

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

重要

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

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

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

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

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

方法

系切り替え元による処理

系切り替え先による処理

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

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

レコードを更新する方法

なし

レコードの更新

残る

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

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

レコードの削除

レコードの更新（追加）

残らない

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

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

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

レコードを更新する方法

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

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

[図データ]

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

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

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

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

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-
（凡例）

-：特にありません。

注※

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

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

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

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

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

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

    Name

    Type

    Value

    TTL

    備考

    DNS名

    （例：hitachi.co.jp）

    DNSレコードタイプ

    （例：A）

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

    （例：200.200.200.200）

    キャッシュ生存期間

    （例：60秒）

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

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

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

[図データ]

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

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

Name

Type

Value

TTL

備考

DNS名

（例：hitachi.co.jp）

DNSレコードタイプ

（例：A※）

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

（例：100.100.100.100）

キャッシュ生存期間

（例：60秒）

-
（凡例）

-：特にありません。

注※

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

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

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

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

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

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

    Name

    Type

    Value

    TTL

    備考

    （空白）

    （空白）

    （空白）

    （空白）

    削除

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

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

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

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

    Name

    Type

    Value

    TTL

    備考

    DNS名

    （例：hitachi.co.jp）

    DNSレコードタイプ

    （例：A）

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

    （例：200.200.200.200）

    キャッシュ生存期間

    （例：60秒）

    追加
重要

ページの先頭へ

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