Recovery Kit for EC2™ には機能が 2 つあります。
- ルートテーブルシナリオ (バックエンドクラスタ) は、LifeKeeper が保護する IP リソースに Amazon VPC™ 内のクライアントから接続できるように、ルートテーブルを管理します。
- Elastic IP シナリオ (フロントエンドクラスタ) は、インターネットから使用できる Elastic IP を管理します。
ルートテーブルシナリオ (バックエンドクラスタ):
ルートテーブルの管理と運用について理解しやすいように、図 1 に示すシナリオについて考えてみましょう。
この設定例は、1 つの Amazon VPC™ と 2 つの Availability ゾーン (AZ) で構成されています。
各 AZ にサブネットが 2 つあります。
- 1 つ目のサブネット (以下「パブリックサブネット」) は、ルートテーブル別のインターネットゲートウェイを経由してインターネットに接続します (10.0.1.0/24 および 10.0.3.0/24 のルートテーブルを参照)。
- 2 つ目のサブネット (以下「プライベートサブネット」) は、ルートテーブル別のNATインスタンスを経由してインターネットに接続します (10.0.2.0/24 および 10.0.4.0/24 のルートテーブルを参照)。
各パブリックサブネットには、NAT の Elastic IP を割り当てる EC2 インスタンス (以下「NAT インスタンス」) が 1 つあります。
各プライベートサブネットには、LifeKeeper のアクティブ / スタンバイ (以下それぞれ「Node1」および「Node2」) の EC2 インスタンスが 1 つあり、Node1/Node2 により保護されたアプリケーションを使用するクライアントが複数あります。
Node1/Node2 はそれぞれ、Elastic Network Interface (ENI) を 2 つ持ちます。
各インスタンスと各ノードとの間で通信が可能なように、ネットワーク ACL とセキュリティグループを設定します。
図 1: ルートテーブルシナリオ
10.0.1.0/24 および 10.0.3.0/24 のルートテーブル
10.0.0.0/16 | ローカル | デフォルト |
0.0.0.0/0 | インターネットゲートウェイ | インターネットに接続するには、Elastic IP を割り当てる必要があります。 |
10.0.2.0/24 のルートテーブル
10.0.0.0/16 | ローカル | デフォルト |
10.1.0.10/32 (IP リソース) | LifeKeeper のアクティブなノード上の Elastic Network Interface (ENI) | このターゲットは、スイッチオーバ中に Recovery Kit for EC2™ により更新されます。 |
0.0.0.0/0 | NAT インスタンス (10.0.1.0) | NAT 経由でインターネットに接続 |
10.0.4.0/24 のルートテーブル
10.0.0.0/16 | ローカル | デフォルト |
10.1.0.10/32 (IP リソース) | LifeKeeper のアクティブなノード上の Elastic Network Interface (ENI) | このターゲットは、スイッチオーバ中に Recovery Kit for EC2™ により更新されます。 |
0.0.0.0/0 | NAT インスタンス (10.0.3.0) | NAT 経由でインターネットに接続 |
リソースのスイッチオーバが実行されると、LifeKeeper は Node1 の IP リソースを Out of Service にします。各プライベートサブネット内の 10.1.0.10/32 のターゲットエントリは、Node2 の ENI を反映するように更新されます。Node2 の IP リソースが In-Service になります。このため、IP アドレス 10.1.0.10 へのトラフィックは、プライベートサブネット内でのルートテーブル設定の変更により効果的に Node2 に転送されます。
パブリックサブネットを含む他のサブネットから IP アドレス 10.1.0.10 にアクセスする必要がある場合、それぞれのサブネットのルートテーブルのエントリに接続先 10.1.0.10/32 のルートを追加してください。LifeKeeperは、VPC内のルートテーブルで接続先が "10.1.0.10/32" になっている全てのエントリを制御します。
Elastic IP シナリオ (フロントエンドクラスタ):
Elastic IP の管理と運用について理解しやすいように、図 2 に示すシナリオについて考えてみましょう。
この設定例は、1 つの Amazon VPC™ と 2 つの Availability ゾーン (AZ) で構成されています。
各 AZ にサブネットが 1 つあります。
各サブネットは、ルートテーブル別のインターネットゲートウェイを経由して、インターネットに接続します。
サブネットには、LifeKeeper のアクティブ / スタンバイ (以下それぞれ「Node1」および「Node2」) の EC2 インスタンスが 1 つあります。
Node1/Node2 はそれぞれ、Elastic Network Interface (ENI) を 2 つ持ちます。
各ノード間で通信が可能なように、ネットワーク ACL とセキュリティグループを設定します。
図 2: Elastic IP シナリオ
システム管理者が、フロントエンドクラスタの Elastic IP アドレスを ENI に割り当てます。
Node1 をリソースのプライマリサーバと仮定すると、システム管理者はリソース階層の作成 セクションで説明しているウィザードを使用して、Node1 上に EC2 リソース階層を作成します。
リソースのスイッチオーバが実行されると、Recovery Kit for EC2™ は Node1 の ENI と Elastic IP との関連付けを解除します。Recovery Kit for EC2™ は、Elastic IP が Node2 の ENI と関連付けられているかどうかを調べ、関連付けられていない場合は、Elastic IP を ENI に関連付けます。このため、インターネット上のクライアントは、スイッチオーバ後に Elastic IP 経由で Node2 に接続できます。
注記 : EC2インスタンスを制御するために、スタンバイノードもエンドポイントにアクセスできる必要があります。即ち、VPC 外部への接続が必要ですので、ご注意ください。詳しくは「Recovery Kit for EC2™ の要件 」を参照してください。
なお、PrivateLink を利用すればエンドポイントへのアクセスにパブリック IP アドレスを必要としません。詳しくは「VPC エンドポイント 」を参照してください。
このトピックへフィードバック