AmazonEC2でhaproxyとkeepalived
新しいAmazonOpsworksサービスは、Amazon独自の非常に限定されたエラスティックロードバランサーではなくhaproxyを使用するため、Webアプリサーバーの負荷分散、セッションフェイルオーバーの提供などのより良いオプションとしてhaproxyの調査を開始しました。haproxyは問題なく動作しました。 1つのhaproxyサーバーと複数のWebアプリサーバーがありますが、SPOFは避けたいと思います。
私の質問は、おそらく同じ内部IPアドレス10.0.0.xを持つ各haproxyサーバーに2番目のNICを設定する必要がありますか？外部アドレス（弾性IP）を割り当ててトラフィックを転送するため内部IPへの接続はAmazonによって行われます。これを構成する方法がわかりません。
私はそれを理解したと思います、そして私は今テストしています-あなたは両方のサーバーでkeepalivedのためにメインサーバーの内部IPを使用します。
設計時にAmazonのElasticLoad Balancing（ELB）はVPC内のサーバーをサポートしていなかったため、負荷分散にもhaproxyを使用しています。彼らは今その機能を持っています（haproxyが私たちのためにうまく機能しているので、私はそれを使用していないと思います）。
次の2つの理由から、keepalivedをまったく試しませんでした。
- AWS（コンソールまたはAPI）を経由せずに、サーバー上のプライベートIPを変更できるかどうか疑問でした。また、AWSでは、同じVPC内の2つのサーバーが同じ内部IPアドレスを持つことは許可されていません。
- 高可用性を実現するには、マルチAZセットアップが必要でした。 VPC内のサーバーの内部IPはVPCサブネットに基づいており、各サブネットは1つのVPCにのみ属することができます。したがって、2つの異なるAZ上の2つのホストを同じサブネット内に置くことはできません。
したがって、実装したソリューションは次のとおりです。
- 2つのサーバー（各AZに1つ）にhaproxyをセットアップします
- また、バックエンド（Webなど）サーバーを2つ以上のAZに分割します
- Elastic IPをhaproxyサーバーの1つに設定します（選択した「プライマリ」AZ内）。これは、WebクライアントがアクセスするVIPです。
- VIP（そのAWSリージョン外）からのVIP $ ===を監視します。障害（インスタンスまたはAZ全体）が発生した場合は、Elastic IPをセカンダリhaproxyサーバーに再マッピングします（テストがそのホストを渡します。
- EIP参照： http://aws.Amazon.com/articles/1346
- 注：今のところ手動でこれを行っています（ほとんど必要ありません-AZの停止の場合は年に1〜2回）が、これはAWS APIを使用して簡単にスクリプト化でき、障害状態時にモニタリングサーバーにスイッチオーバーをトリガーさせることができます。
- また、EIPリマップにはコストがかかることに注意してください（1か月あたり100回の無料リマップに対して1リマップあたり$ 0.10）。 AZの停止は比較的まれなので、これが問題になることはないと思います。
潜在的なリスクの1つは、AWSの大規模な停止時に、AWSコンソールとAPIが（完全にまたは通常より頻繁に）失敗し始めることに気付く場合があることです。これは、エラスティックIPを再マップする試みに影響を与える可能性があります。