DNSフェールオーバーが推奨されないのはなぜですか？

読んでみると、DNSがDNSフェイルオーバー用に設計されていないという理由だけで、DNSフェイルオーバーは推奨されないようです。しかし、冗長コンテンツをホストする異なるサブネット上に2つのWebサーバーがある場合、1つのサーバーがダウンした場合にすべてのトラフィックがライブサーバーにルーティングされるようにする他の方法はありますか？

私にとっては、DNSフェールオーバーがここでの唯一のフェールオーバーオプションのように思えますが、コンセンサスはそれが良いオプションではないということです。それでも、DNSmadeeasy.comのようなサービスはそれを提供するので、それにメリットがあるに違いありません。コメントはありますか？

「DNSフェールオーバー」とは、DNSラウンドロビンと監視の組み合わせを意味します。つまり、DNSホスト名の複数のIPアドレスを公開し、監視がサーバーのダウンを検出したときにデッドアドレスを削除します。これは、小規模でトラフィックの少ないWebサイトに有効です。

設計上、DNS要求に応答するとき、配布する応答の生存時間（TTL）も提供します。言い換えれば、他のDNSサーバーとキャッシュに「この回答を保存し、x分間使用してから確認してください」と言っているということです。欠点は次のとおりです。

• DNSフェールオーバーでは、ユーザーの不明な割合が、さまざまな量のTTLを使用してDNSデータをキャッシュします。TTLが期限切れになるまで、これらはデッドサーバーに接続する可能性があります。これよりも高速なフェイルオーバー方法があります。
• 上記の理由から、TTLを非常に低く、たとえば5〜10分に設定する傾向があります。しかし、それを高く設定すると（非常に小さな）パフォーマンス上の利点が得られ、ネットワークトラフィックに短いグリッチがある場合でもDNS伝播が確実に機能するのに役立ちます。したがって、DNSベースのフェールオーバーを使用すると、TTLが高くなりますが、TTLが高いとDNSの一部であり、役に立つ場合があります。

良好な稼働時間を得るためのより一般的な方法は次のとおりです。

• サーバーを同じLAN上に配置します。
• 高可用性の電源プレーンとネットワークプレーンを備えたデータセンターにLANを配置します。
• HTTPロードバランサーを使用して負荷を分散し、個々のサーバー障害でフェールオーバーします。
• ファイアウォール、ロードバランサー、およびスイッチに必要な冗長性/予想されるアップタイムのレベルを取得します。
• データセンター全体の障害、および簡単にミラー化できないスイッチ/データベースサーバー/その他のリソースの偶発的な障害に対して、通信戦略を実施します。

ごく一部のWebサイトでは、データセンター間で「ジオバランシング」を行いながら、複数のデータセンター設定を使用しています。

DNSフェイルオーバーは間違いなく素晴らしい機能を発揮します。私はこれを長年にわたって使用して、データセンター間でトラフィックを手動でシフトしたり、システムが停止、接続の問題、またはサーバーの過負荷を検出したときに自動的にトラフィックをシフトしていました。それが機能する速度と、簡単にシフトできる現実世界のトラフィックの量を見れば、決して振り返ることはないでしょう。私はすべてのシステムを監視するためにZabbixを使用し、DNSフェールオーバーの状況で何が起こるかを示す視覚的なグラフを使用して、疑問をすべて解消しました。TTLを無視するISPがいくつかあり、古いブラウザを使用しているユーザーもいます-しかし、2つのデータセンターの場所で1日に数百万のページビューからのトラフィックを見て、DNSトラフィックシフトを行う場合- TTLを無視する着信トラフィックの残りは笑えます。

DNSはフェイルオーバー用に設計されていませんが、TTLを使用して設計されており、堅牢な監視システムと組み合わせると、フェイルオーバーのニーズに驚くほど機能します。TTLは非常に短く設定できます。高速DNSフェールオーバーベースのソリューションを軽量化するために、運用環境で5秒のTTLを効果的に使用しました。余分な負荷を処理できるDNSサーバーが必要です-namedはそれを削減しません。ただし、powerdnsは、冗長ネームサーバー上のmysqlレプリケートされたデータベースでバックアップされた場合、請求に適合します。また、自動化されたフェイルオーバー統合のために信頼できる堅牢な分散監視システムも必要です。Zabbixは私のために機能します-複数の分散Zabbixシステムからの停止をほぼ即座に確認できます-powerdnsが使用するmysqlレコードをその場で更新し、停止およびトラフィックスパイク中にほぼ瞬時のフェイルオーバーを提供します。

しかし、ちょっと-私は大企業のために何年もそれを機能させた後にDNSフェイルオーバーサービスを提供する会社を作りました。だから一粒の塩と私の意見を取ります。停止中に大量のサイトのいくつかのzabbixトラフィックグラフを表示したい場合-DNSフェールオーバーがどのように機能するかを正確に確認するために-私にメールしてください。

DNSフェールオーバーの問題は、多くの場合、信頼できないことです。一部のISPはTTLを無視しますが、TTLを尊重してもすぐには発生しません。また、サイトが復旧したときに、ユーザーのDNSキャッシュがタイムアウトになり、最終的に見出しが表示される場合があります。他のサーバーへ。

残念ながら、独自の（外部）ルーティングを行うのに十分な大きさでない限り、これはほとんど唯一のオプションです。

一般的な意見では、DNS RRでは、IPがダウンしても、一部のクライアントは壊れたIPを数分間使用し続けます。これは、質問に対する以前の回答のいくつかで述べられており、ウィキペディアにも書かれています。

とにかく、

http://crypto.stanford.edu/dns/dns-rebinding.pdfは、現在のHTMLブラウザーのほとんどには当てはまらないと説明しています。次のIPを数秒で試行します。

http://www.tenereillo.com/GSLBPageOfShame.htmはさらに強力なようです：

複数のAレコードを使用することは、トレードのトリックではなく、負荷分散機器ベンダーが考案した機能でもありません。この理由から、DNSプロトコルは複数のAレコードをサポートするように設計されました。ブラウザやプロキシ、メールサーバーなどのアプリケーションは、DNSプロトコルのその部分を利用します。

たぶん、一部の専門家がコメントして、DNS RRが高可用性に適していない理由をより明確に説明できるかもしれません。

おかげで、

ヴァレンティノ

PS：リンクが切れてすみませんが、新しいユーザーとして1つ以上投稿できません

DNS RRフェールオーバーは、中程度のトラフィックであるがビジネスに不可欠なWebサイト（2つの地域）で長年にわたって実行しました。

それはうまく機能しますが、私が苦労して学んだ少なくとも3つの微妙な点があります。

1）クライアントが使用可能なキャッシュされたDNSで両方がアクティブであると見なされた場合、ブラウザは30秒（最後にチェックした時間）後に非動作IPから動作IPにフェイルオーバーします。これは基本的に良いことです。

ただし、ユーザーを30秒間「半分」待機させることは受け入れられないので、TTLレコードを数日または数週間ではなく数分に更新して、障害が発生した場合にダウンしたサーバーを迅速に削除できるようにします。 DNSから。他の人は、彼らの応答でこれをほのめかしています。

2）ネームサーバーの1つ（または2つの地域全体の1つ）がダウンしてラウンドロビンドメインにサービスを提供し、それらのプライマリサーバーがダウンした場合、それを削除しようとする他の問題に遭遇する可能性があることを漠然と思い出しますネームサーバーのSOA TTL /有効期限も十分に低い値に設定していない場合は、DNSからネームサーバーをダウンしました。ここでは技術的な詳細が間違っている可能性がありますが、単一障害点から実際に防御するために必要なTTL設定は複数あります。

3）Web API、RESTサービスなどを公開する場合、通常これらはブラウザーから呼び出されないため、DNSフェイルオーバーは実際の欠陥を示し始めます。これは、「お勧めしません」と言う人もいます。私がそう言う理由はここにあります。まず、これらのURLを使用するアプリは通常ブラウザーではないため、一般的なブラウザーの30秒のフェールオーバープロパティ/ロジックがありません。第二に、2番目のDNSエントリが呼び出されるか、DNSが再ポーリングされるかは、これらのAPI / RESTクライアントで使用されるプログラミング言語のネットワークライブラリの低レベルプログラミングの詳細と、それらの呼び出し方法に大きく依存しますAPI / RESTクライアントアプリ。（カバーの下で、ライブラリはget_addrを呼び出しますか？ソケットがハングまたはクローズした場合、アプリは新しいソケットを再度開きますか？何らかのタイムアウトロジックがありますか？など）

安価で、十分にテストされており、「ほぼ機能する」。そのため、ほとんどのものと同様に、走行距離は異なる場合があります。

フェイルオーバーのために私たち（Dyn）を使用する人々がたくさんいます。これは、サイトがダウンタイム（TwitterのFail Whaleなど）の場合にステータスページを表示できる理由と同じ理由です...または単にTTLに基づいてトラフィックを再ルーティングするだけです。DNSフェールオーバーはゲットーだと考える人もいるかもしれませんが、ハードウェアと同様に機能するように、最初からフェールオーバーを使用してネットワークを真剣に設計しました。DMEがどのようにそれを行うかはわかりませんが、最も近いエニーキャストPoPの17のうち3つが最も近い場所からサーバーを監視しています。3つのうちの2つがダウンしていることを検出すると、トラフィックを他のIPに再ルーティングします。唯一のダウンタイムは、そのTTLインターバルの残りの時間に要求されたダウンタイムです。

一部の人々は両方のサーバーを一度に使用することを好みます...そしてその場合、ラウンドロビン負荷分散のような何かをすることができます...または地理ベースの負荷分散。実際にパフォーマンスに関心がある場合は、リアルタイムトラフィックマネージャーが各サーバーを監視します...サーバーが遅い場合は、ホスト名でリンクするIPに基づいてトラフィックを最速のものに再ルーティングします。繰り返しますが、これはUI / API / Portalに設定した値に基づいて機能します。

私のポイントは...意図的にDNSフェイルオーバーを設計したと思います。DNSは、最初に作成されたときにフェールオーバー用に作成されていませんでしたが... DNSネットワークは、最初から実装するように設計されていました。通常、減価償却やハードウェアのコストなしで、ハードウェアと同じくらい効果的です。Dynをプラグインするのが不自由に聞こえないことを願っています...それを行う会社は他にもたくさんあります...私はチームの観点から話しているだけです。お役に立てれば...

別のオプションは、ロケーションAのネームサーバー1とロケーションBのネームサーバー2をセットアップしますが、NS1のすべてのAレコードがロケーションAのIPをポイントし、NS2のすべてのAレコードが場所B.次に、TTLを非常に小さい数値に設定し、レジストラのドメインレコードがNS1およびNS2に設定されていることを確認します。そのように、それは自動的に負荷分散し、1つのサーバーまたは場所への1つのリンクがダウンした場合にフェイルオーバーします。

私はこのアプローチをわずかに異なる方法で使用しました。2つのISPを持つ1つの場所があり、この方法を使用してトラフィックを各リンクに転送します。今、あなたがやろうとしているよりも少しメンテナンスが多いかもしれません...しかし、NS1レコードを自動的に引き出し、選択したゾーンのAレコードIPアドレスを更新し、それらのゾーンをプッシュする簡単なソフトウェアを作成することができましたNS2。

代替手段は、BGPベースのフェールオーバーシステムです。セットアップは簡単ではありませんが、防弾とする必要があります。サイトAを1つの場所に、サイトBをすべてローカルIPアドレスでセットアップし、クラスCまたはポータブルなIPの他のブロックを取得し、ポータブルIPからローカルIPへのリダイレクトをセットアップします。

落とし穴はありますが、そのレベルの制御が必要な場合は、DNSベースのソリューションよりも優れています。

複数のデータセンターのフェールオーバーの1つのオプションは、ユーザーをトレーニングすることです。複数の都市やサインアップメールで複数のサーバーを提供し、ユーザーが1つのサーバーがダウンした場合に他のサーバーへのリンクを使用できるように、各「サーバー」への直接リンクを含めることをお客様に広告します。

これにより、複数のドメイン名を維持するだけでDNSフェールオーバーの問題を完全に回避できます。www.company.comまたはcompany.comにアクセスしてログインしたユーザーは、server1.company.comまたはserver2.company.comに誘導され、どちらかを使用してパフォーマンスが向上したことに気付いた場合、それらのいずれかをブックマークすることができます。 。一方がダウンすると、ユーザーはもう一方のサーバーに移動するようにトレーニングされます。

私は過去10年間DNSベースのサイトバランシングとフェイルオーバーを使用してきましたが、いくつかの問題がありますが、それらは軽減できます。BGPは、いくつかの点で優れていますが、複雑さの増加、おそらく追加のハードウェアコスト、収束時間などを伴う100％ソリューションではありません。

ローカル（LANベース）の負荷分散、GSLB、クラウドベースのゾーンホスティングを組み合わせることは、DNS負荷分散に通常関連する問題のいくつかを解決するために非常にうまく機能していることがわかりました。

これらの答えはすべて妥当性がありますが、それはあなたが何をしていて、予算が何であるかに本当に依存すると思います。ここCloudfloorDNSでは、当社のビジネスの大部分がDNSであり、高速DNSだけでなく、低TTLオプションとDNSフェイルオーバーも提供しています。これがうまくいかず、うまく機能しなければ、私たちはビジネスになりません。

稼働時間に制限のない多国籍企業の場合、ハードウェアGSLBロードバランサーと第1層のデータセンターは優れていますが、DNSは高速で安定している必要があります。多くの人が知っているように、DNSはドメイン名自体を除き、あらゆるインフラストラクチャの重要な側面であり、オンラインプレゼンスの他のすべての部分が乗っている最低レベルのサービスです。堅実なドメインレジストラから始めて、DNSはドメインの有効期限が切れないようにすることと同じくらい重要です。DNSがダウンすると、組織のオンライン全体もダウンします！

DNSフェールオーバーを使用する場合、他の重要な側面は、サーバーモニタリング（常に複数のジオロケーションからチェックし、常に複数（少なくとも3つ）が誤検知を回避するためにチェックする必要がある）とDNSレコードを適切に管理することです。TTLが低く、フェイルオーバーを伴ういくつかのオプションにより、これがシームレスなプロセスになり、システム管理者である場合、深夜にポケットベルに目覚めるのに勝ります。

全体として、DNSフェールオーバーは実際に機能し、非常に手頃な価格です。ほとんどの場合、当社またはほとんどのマネージドDNSプロバイダーから、ハードウェアオプションの数分の1のコストで、エニーキャストDNSとサーバーモニタリングおよびフェイルオーバーを利用できます。

本当の答えはイエスです、それは動作しますが、それはすべての人とすべての予算のためですか？たぶんそうではないかもしれませんが、試して自分でテストを行うまで、可能な限り最高の稼働時間を望むIT予算が限られている中小企業の場合は無視するのは困難です。

「そして、ほとんどの実稼働環境でそれを使用するチャンスを取っている理由（それは何もないよりはましですが）」

実際、プレゼンスが地理的に多様である場合、「何もないよりはまし」は「唯一のオプション」としてより適切に表現されます。ハードウェアロードバランサーは、単一の存在ポイントに最適ですが、単一の存在ポイントは単一の障害ポイントでもあります。

DNSベースのトラフィック操作を使用して効果を発揮する大規模なサイトがたくさんあります。彼らは販売がオフになっている場合、時間単位で知っているサイトのタイプです。「ほとんどの本番環境でそれを使用してチャンスをつかむ」ために立ち上がったのは彼らであるように思えます。実際、彼らは選択肢を慎重に検討し、技術を選択し、それに対して十分な支払いをしました。彼らは何かが良いと思った場合、彼らはハートビートで去ります。彼らがいまだに留まることを選択しているという事実は、実世界での使用についての多くを語っています。

DNSベースのフェールオーバーには、ある程度の遅延が発生します。それを回避する方法はありません。ただし、マルチポップシナリオでのフェールオーバー管理への唯一の実行可能なアプローチです。唯一のオプションとして、それは「何もないよりはまし」よりもはるかに優れています。

現在、その技術を使用して機能し、非常に良好に機能する優れたグローバルロードバランサーです。たとえば、Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/を確認してください

詳細については、次のアプリケーションノートを参照してください。

http://edgedirector.com

それらは、フェイルオーバー、グローバル負荷分散、および関連事項のホストをカバーしています。

バックエンドアーキテクチャで許可されている場合、より良いオプションは、フェールオーバーオプションを使用したグローバルロードバランシングです。このようにして、すべてのサーバーと帯域幅が可能な限り機能します。このセットアップは、障害時に追加の使用可能なサーバーを挿入するのではなく、障害が発生したサーバーを回復するまでサービスから撤回します。

簡単な答え：動作しますが、制限を理解する必要があります。

フェイルオーバーのアイデアはクラスタリングを意図したものであると思いますが、単独でも実行できるため、1対1の可用性で動作することが可能になりました。

A、独自のASでマルチホームになっているデータセンターを選択するか、B、パブリッククラウドでネームサーバーをホストすることをお勧めします。EC2、HP、またはIBMがダウンする可能性はほとんどありません。ちょっとした考え。DNSは修正として機能しますが、この場合のネットワーク基盤の貧弱な設計に対する単なる修正です。

環境に応じて、IPSLA、PBR、およびFHRPと組み合わせて冗長性のニーズを満たすこともできます。