web-dev-qa-db-ja.com

DNSラウンドロビン:複数のネームサーバーと複数のAレコード?

注:これは DNSフェイルオーバーに関する以前の質問 のフォローアップです。

目標:クライアントのWebブラウザーに、サーバーがすぐにダウンした場合に次に使用可能なサーバーを選択させること。

私はどこかで、複数のAレコード(最良のソリューションではありませんが)がHTTP /ブラウザーベースのアプリケーションで可能な唯一の「インスタントフェイルオーバー」ソリューションであることを読みました。

シナリオ/例は次のとおりです。

まったく同じコンテンツを含む2つのサーバーAとBがあります。サーバーAのIPアドレスは1.1.1.1と1.1.1.2ですサーバーBのIPアドレスは2.2.2.1と2.2.2.2ですGodaddyにドメインを登録しています。 DNSラウンドロビンを使用する場合、どの方法が最適ですか?

方法1:ネームサーバーエントリをGodaddyにこのように設定しますか?

  1. ns1.serverA.com
  2. ns2.serverA.com
  3. ns1.serverB.com
  4. ns2.serverB.com

方法2:または、私はネームサーバーとしてGodaddyを作成し、次のようにAレコードを追加します。

  1. A 1.1.1.1
  2. A @ 1.1.1.2
  3. A @ 2.2.2.1
  4. A @ 2.2.2.2

私の質問は、DNSラウンドロビンは2つの方法のいずれかで機能しますか?そうでない場合、目標を達成するための最良の方法は何ですか?

4
IMB

目標:クライアントのWebブラウザーに、サーバーがすぐにダウンした場合に次に使用可能なサーバーを選択させること。

これは通常、ロードバランサーと呼ばれる3番目のサーバーを導入することによって行われます。ロードバランサー:

  1. トラフィックを2つのWebサーバーに転送します。
  2. 2つのWebサーバーの状態を監視します。
  3. 1つに障害が発生した場合、残りのWebサーバーにトラフィックを切り替えます。

ロードバランサー自体は、2つのロードバランサー(LB)、つまり合計で少なくとも4つのサーバー(2つのLB、2つのwebappサーバー)を使用することで高可用性を実現できます。ただし、多くの小規模なショップは、比較的単純なシステムであり、多くの場合非常に信頼性が高いため、1つのロードバランサーのみで実行されます。

方法1:ネームサーバーエントリをGodaddyにこのように設定しますか? 1. ns1.serverA.com 2. ns2.serverA.com 3. ns1.serverB.com 4. ns2.serverB.com

絶対違う。ネームサーバーは、WebサーバーのIPアドレスの解決にのみ使用されます。ドメインのネームサーバーは、レジストラ/ DNSホスト(GoDaddy)のデフォルトのままにします。

方法2:または、ネームサーバーとしてGodaddyを作成し、次のようなAレコードを追加しますか?1。A@ 1.1.1.1 2. A @ 1.1.1.2 3. A @ 2.2.2.1 4. A @ 2.2.2.2

DNSラウンドロビン(DNS RR)がハイエンドフェイルオーバー/高可用性セットアップの一部として使用される場合、DNS RR ポイントのIPアドレスは非常に利用可能です。つまり、各IPアドレスは、2つのデバイスによって処理される仮想IPです。純粋な高可用性ソリューションとして、高度に利用可能なサーバーIPがない場合、DNS RR あまりうまく機能しません 。基本的な問題は、一部のクライアントが 「デッド」IPアドレスを使用し続ける であり、クライアントが「正しいこと」を実行することに依存しており、すべてのクライアントがそうするわけではないということです。実際のHTTPロードバランサーを使用することをお勧めします。

とは言うものの、多くの小さなWebサイトはDNSRRを負荷分散のみに使用しており、良好な結果が得られています。それは私が推測するあなたの期待についてのすべてです。

DNS RRの場合、物理サーバーごとに2つのIPアドレスを使用しても何も得られず、さらに複雑になります。したがって、表記では、サーバーごとに1つのIPを使用するだけです。

A @ 1.1.1.1
A @ 2.2.2.1
8
Jesper M

Method1として説明するものは、DNSを破壊し、フェイルオーバーを提供しません。 DNSレコードにも信頼できるソースが必要です-2つの競合する信頼できるソースが存在することはできません(ただし、同じconfの複数のコピーが存在する可能性があります)。

2
symcbean

私はあなたの提案があなたがしたいことを完全に実行するとは思わない。

あなたが文書化したAレコードアプローチは、コンテンツの取得に適したIPアドレスのallを提供するため、ユーザーのWebブラウザーは自由に使用できますanyそれらの。実際に選択される特定のサーバーがダウンしている場合、ユーザーのブラウザーmayは別のIPアドレスを試すことを選択しますが、それはどこにも近くありませんインスタント

また、1つのサーバーに複数のIPをリストすることにも疑問があります。サーバーAがダウンしているとします。ブラウザが1.1.1.1への接続を試みた場合、(タイムアウト後)1.1.1.2への接続を試みた場合、コンテンツの到着をさらに長く待機します。

Webサーバー間の信頼性の高い高速フェイルオーバーが本当に必要な場合は、 HAProxy のようなものを調べたいと思うでしょう。

編集:具体的には、HAProxyを実行しているボックスのペアで、それらの間で共有される「フローティング」IPアドレスが必要です。次に、これらのボックスで Heartbeat のようなものを実行して、一方が失敗した場合、もう一方がそれを検出し、「フローティング」IPアドレスを自動的に引き継ぐようにします。最後に、1つのAレコードをフローティングIPにポイントします(これは常にHAProxyインスタンスのいずれかを指します)。

あなたはおそらく Stack Overflow Network Configuration 興味深い/参考になるでしょう。

2
nickgrim

通常は「Aレコード」アプローチを採用します。一部のICANNレジストラがNSレコードで無視する可能性があるAレコードでも、TTLを制御できます。

ラウンドロビンDNSは優れていますが、一部のブラウザ(たとえば、古いIE)はレコードを長時間キャッシュする可能性があるため、Webサーバーの1つに障害が発生し、公開されたDNSからIPを削除した場合でも、そのIPにアクセスする訪問者が数人いる可能性があります。 (かなり小さな割合ですが、1つか2つの苦情を受けるには十分です)。ただし、負荷分散には非常に適しています。

2
Jonathan Ross