ここで問題があります。
私たちは、クラウド プロバイダーの 2 つの異なるクラウド リージョンにコンピューティング インスタンスを設定していますが、これについては言及しませんが、作業が面倒です。
これらのインスタンスは（明らかに）プライベートを使用しています。
このクラウド プロバイダーはリージョン間のプライベート IP を許可していないため、VIP に基づく負荷分散ソリューションを使用することはできません。そのため、NLB は使用できません。
必要なのは、A レコードのヘルス チェック機能を備えた DNS サーバー (実際には少なくとも 2 つ) です。例を挙げてみましょう。
- サービス：
- サーバー A - リージョン 1 - IP 10.1.1.100
- サーバー B - リージョン 2 - IP 172.26.1.100
- DNS バランサー (同じレコードと構成データベースを共有):
- DNS A - リージョン 1 - IP 10.1.1.50
- DNS B - リージョン 2 - IP 172.26.1.50
- DNS レコード 1: whatever.local - 10.1.1.50
- DNS レコード 2: whatever.local - 172.26.1.50
- クライアント:
- クライアント A - 任意の地域 - 任意の IP
- シナリオA:
- クライアント A には DNS A と DNS B の両方が DNS サーバーとして構成されています。
- クライアントAはDNSサーバーAにwhatever.localを要求する
- サーバーAはオフラインです
- DNSサーバーAはバックエンドのヘルスチェックを行っており、それを検出してサーバーBのIP（172.26.1.50）で応答します。
- キャッシュを回避するために、TTL は 0 (ゼロ) またはそれと同等に低い値に設定されます。
- シナリオ B:
- クライアント A には DNS A と DNS B の両方が DNS サーバーとして構成されています。
- クライアントAがwhatever.localを要求し、DNSサーバーAがダウンしているためDNSサーバーBが応答します。
- サーバーBはオフラインです
- DNSサーバーBはバックエンドのヘルスチェックを行っており、それを検出してサーバーAのIP（10.1.1.100）で応答します。
- キャッシュを回避するために、TTL は 0 (ゼロ) またはそれと同等に低い値に設定されます。
本質的には、DNS レコードの IP の健全性をチェックする DNS サーバーです。
よろしくお願いいたします。
答え1
クライアント A には DNS A と DNS B の両方が DNS サーバーとして構成されています。
えーっと、異なる分割データで構成された複数の DNS サーバーをマシンで使用すると、大変なことになります。予測可能な動作を得るには、監視ホスト上に独自の解決済みスタックを構築する必要があります。
このサービスを監視する方法は、DNS を分割しないことです。
service.example.com. CNAME region1_service.example.com.
service.example.com. CNAME region2_service.example.com.
region1_service.example.com. A 10.1.1.50
region2_service.example.com. A 172.26.1.50
以下のそれぞれを監視します。
- サービス
- 地域1サービス.example.com
- 地域2サービス.example.com
あるいは監視エージェント5月明示的なアドレスの設定をサポートしているため、各インスタンスを個別に監視できます。ただし、両方のノードの停止をフラグ付けするという複雑な問題があり、これはいずれかのノードの停止よりもはるかに深刻です。
監視クライアントが rrDNS をどのように実装しているかも確認する必要があります。ルールに従ったフェイルオーバー検出時間は約 5 分ですが、ブラウザは最初の接続に約 10 秒、後続のリクエストに 1 秒未満のしきい値を適用します。
答え2
結局のところ、これに対する解決策はあります。これは基本的に GSLB が提供するもので、市販のソリューションが多数あります。
ある程度シンプルかつオープンソースで実行したい場合は、PowerDNS クラスターで LUA レコードを備えた PowerDNS を使用できます。