web-dev-qa-db-ja.com

DNSフェイルオーバーが推奨されない場合、何をしますか？

彼の非常に人気のある質問のフォローアップ質問として： DNSフェイルオーバーが推奨されないのはなぜですか？ 、DNSフェイルオーバーはキャッシングのために100％信頼できないことが合意されたと思います。

ただし、投票数が最も多かった回答では、2つの異なるデータセンター間でフェイルオーバーを実現するためのより良いソリューションは何であるかについては実際には議論されていませんでした。提示された唯一のソリューションは、ローカルロードバランシング（単一のデータセンター）でした。

だから私の質問は、データセンター間のフェイルオーバーの実際の解決策は何ですか？

domain-name-systemfailoverhigh-availabilitydisaster-recoverydatacenter
7
IMB

これを適用するには、データセンター全体がダウンするか、到達不能になる必要があります。次に、IPアドレスを他のデータセンターにルーティングすることで、別のデータセンターのバックアップにアクセスします。これは、プライマリデータセンターからのBGPルートアナウンスが提供されなくなったことにより発生します。次に、セカンダリデータセンターからのセカンダリアナウンスが使用されます。

中小企業は一般に、ポータブルIPアドレスの割り当てと、BGPルートをアナウンスするための独自の自律システム番号の費用を正当化するほど大きくはありません。この場合、プロバイダーは複数の場所に行く方法です。

元のIPアドレスを介して、またはDNSによって行われたIPアドレスの変更を介して到達する必要があります。 DNSは、「フェイルオーバー」の意味で必要な方法でこれを行うように設計されていないため（ユーザーが少なくともTTLの間、またはTTLキャッシングによって課されている限り）サーバー）、同じIPでバックアップサイトにアクセスするのが最善の解決策です。

5
Skaperen

これはコメントとして始まりました...しかし、それは長くなりすぎています。

悲しいことに、 前の質問 に対する答えのほとんどは間違っています：彼らはフェイルオーバーがTTLと関係があると想定しています。上位に投票された回答は見事に間違っており、特に情報源を引用していません。 TTLはゾーンレコード全体に適用され、ラウンドロビンとは関係ありません。

RFC 1794から（これはラウンドロビンDNSservingに関するすべてです）

There is no use in handing out information with TTLs of an hour [or less]

（IME完全な伝播が得られるまでの時間は3時間近くです）。

RFC 1035から

When several RRs of the same type are available for a
 particular owner name, the resolver should either cache them
 all or none at all

RFC 1034は、ネガティブキャッシングの要件を定めています-すべてのリクエストが権威あるDNSサーバーから新鮮に提供される必要があることを示す方法（この場合、TTLはフェイルオーバーを制御します）-私のエクスペリエンスサポートこれはさまざまです。

フェイルオーバーはクライアントスタックの上位に実装する必要があるため、TCP/IPまたはDNSの一部ではないことは間違いありません。実際、SIP、SMTP、RADIUSおよび実行中の他のプロトコルTCP/IPの上部は、クライアントがラウンドロビンでどのように動作するかを定義します-RFC 2616（HTTP/1.1）は、それがどのように動作するかについて言及していない点で注目に値します。

ただし、私の経験では、過去10年間に作成されたすべてのブラウザと他のほとんどのHTTPクライアントは、接続に予想よりも時間がかかっているように見える場合、追加のARRを透過的にチェックします。そしてそれは私だけではありません：

フェイルオーバー時間は実装によって異なりますが、ほんの数秒です。 （DNSの制限により）障害が発生したノードの公開にはDNS TTL-その間、クライアント側の検出に依存する必要があるため、これは理想的なソリューションではありません。

ラウンドロビンは、サイト内の他のHAメカニズムの代わりにはなりません。しかし、それはそれを補完します（HAProxyを書いた人は、ラウンドロビンDNSを介してアクセスされるインストールのペアを使用することをお勧めします）。これは、複数のサイトにHAを実装するためにサポートされている最良のメカニズムです。確かに、私が判断できる限り、これは、標準クライアントで使用可能なフェイルオーバー用にサポートされている唯一のメカニズムです。

10
symcbean

デュアルへの最も簡単なアプローチDC=冗長性は、2つのサイト間のBGPセッションを維持しながら、2つのサイト間のL2 MPLS VPNになります。

基本的には、サーバーごとの物理IPと、2つのサーバー（HSRP/VRRP/CARPなど）の間でフロートする仮想IPを使用できます。 DNSはこの特定のIPにルーティングされ、それに応じて送信されます。

次の考慮事項はスプリットブレインですが、それは別の問題です。

ジュニパーは、デュアルDC MPLSによる管理について、優れたホワイトペーパーを作成しました。PDFここで http://www.juniper.net /us/en/local/pdf/whitepapers/2000407-en.pdf

2
Ben Lessani - Sonassi