アプリケーションをセットアップする必要があるのは、ダウンタイムがほぼ0になるような方法です。私のデータセンターの1つはテキサス州にあり、もう1つはラスベガスにあります。これで、PRと見なされるTXのサーバーがダウンした場合、すべてのトラフィックは、私の場合はDR(災害復旧)であるVegasサーバーに転送されます。
HAProxyやNginXなどのソフトウェアロードバランサーを使用し、Keepalivedを使用して(DRサイトロードバランサーとPRサイトロードバランサー間のハートビートをチェックするため)、フェイルオーバーを克服するためのアクティブ-パッシブ負荷分散のセットアップが行われます。ここでは、アプリケーションはアクティブ-アクティブモードになります。
上の図は、すべての着信トラフィックがロードバランサーの仮想IPに到達することを示しています(アクティブPRロードバランサーとパッシブDRロードバランサー、それらの間でハートビートが有効になっています)。 PRサイトロードバランサーがアクティブな場合、負荷をPRサイトポータルアプリケーションインスタンスとDRサイトポータルインスタンス(両方のサイトがアクティブであるため)にルーティングします。そのとき、DRサイトロードバランサーはアイドル状態になり、のパフォーマンスを常に監視します。アクティブロードバランサー。 PRサイトがダウンすると、DRサイトがアクティブになり、DRサイトのポータルアプリケーションインスタンスを自動的にポイントします。
しかし、Keepalivedを使用したアクティブ-パッシブロードバランサーのセットアップの問題は、LANでは機能するが、WANセットアップでは機能しないことです。この場合のように、アクティブPRロードバランサーは次のようになります。 TXとパッシブDRロードバランサーはベガスにあります。
では、フェイルオーバーセットアップでHAを実現するには、ソフトウェアロードバランサーをどのように使用できますか?
あなたはそれをすることができなくなります。同じLANで機能する理由は、2つの間でフロートする共有IPのためです。複雑なBPGルーティングを実行し、IPスペースを所有する必要があります。
あなたは物事をあまりにも複雑にしようとしています。物事をできるだけ単純にし、すぐに失敗し、ダウンタイムを気にしないほうがよいでしょう。
あなたがしなければならないことは、トラフィックを管理するためにDNSサービスを使用することです。 AWSまたはdyn.comセットアップヘルスチェックからのroute53のようなDNSサービスがあります。そのため、ヘルスチェックを介して両方のサイトを常にチェックし、稼働していることを確認しています。すべてのトラフィックをプライマリに送信します。プライマリのヘルスチェックが失敗すると、フェイルオーバーサイトにDNS応答を提供し始めます。
プライマリがフェイルオーバーと完全に同期していることを確認できるまでフェイルオーバーサイトをアクティブにしておく必要があるため、これも非常に簡単なことではありません。
ヘルスチェックモジュールでNginxPlusを使用できます。プロキシ/ロードバランサーのように背後にアドレスのプールがあり、それらがアクティブであるかどうかを確認し、エンドユーザーをにルーティングする必要があります。 AWSまたはAzureが提供する特定のDNSAPIを使用することもできます。たとえば、Keepalivedと連携します。そのため、フェイルオーバーが発生すると、DNSレコードが新しいLBサーバーに更新されます。