DNSフェイルオーバーが推奨されないのはなぜですか？
読んでみると、DNSフェールオーバーは、DNSがそのために設計されていないだけでは推奨されないようです。しかし、冗長コンテンツをホストする異なるサブネット上に2つのWebサーバーがある場合、1つのサーバーがダウンした場合にすべてのトラフィックがライブサーバーに確実にルーティングされるようにするには、他にどのような方法がありますか？
ここではDNSフェイルオーバーが唯一のフェイルオーバーオプションであるように見えますが、コンセンサスはそれが良いオプションではないということです。しかし、DNSmadeeasy.comのようなサービスがそれを提供するので、それにはメリットがあるはずです。コメントは？
「DNSフェイルオーバー」とは、DNSラウンドロビンといくつかのモニタリングを組み合わせたもの、つまり、DNSホスト名の複数のIPアドレスを公開し、モニタリングによってサーバーのダウンが検出されたときに無効なアドレスを削除することを意味します。これは、トラフィックが少ない小規模なWebサイトで機能します。
設計上、DNS要求に応答するときは、配布する応答にTime To Live（TTL）も提供します。言い換えると、他のDNSサーバーとキャッシュに「この回答を保存してx分間使用してから確認する前に」と伝えていることになります。欠点は次のとおりです。
- DNSフェイルオーバーを使用すると、不明な割合のユーザーがさまざまな量のDNSデータをキャッシュしますTTL残ります。TTLが期限切れになるまで、これらはデッドサーバーフェイルオーバーを完了するには、これよりも高速な方法があります。
- 上記の理由から、TTLを5〜10分とかなり低く設定する傾向があります。ただし、これを高く設定すると、（非常に小さい）パフォーマンス上の利点が得られ、DNSの伝播に役立つ場合がありますネットワークトラフィックに短い不具合があっても確実に機能するため、DNSベースのフェイルオーバーを使用すると、高TTLに反することになりますが、高TTLはDNSの一部であり、役立ちます。
良好な稼働時間を得る一般的な方法は次のとおりです。
- サーバーを同じLANに配置する。
- 可用性の高い電源プレーンとネットワークプレーンのあるデータセンターにLANを配置します。
- HTTPロードバランサーを使用して負荷を分散し、個々のサーバーの障害時にフェイルオーバーします。
- ファイアウォール、ロードバランサー、スイッチに必要な冗長性のレベルと予想される稼働時間を取得します。
- データセンター全体の障害、およびスイッチ/データベースサーバー/ミラーリングが困難なその他のリソースに時々障害が発生した場合の通信戦略を用意します。
ごく少数のWebサイトが複数のデータセンター設定を使用し、データセンター間の「地理的バランス」をとっています。
DNSフェイルオーバーは確実に機能します。データセンター間でトラフィックを手動でシフトするために、または監視システムが停止、接続の問題、または過負荷のサーバーを検出したときに自動的にそれを長年使用しています。それが機能する速度と、簡単にシフトできる実際のトラフィックの量を見ると、決して後戻りすることはありません。私はすべてのシステムを監視するためにZabbixを使用しており、DNSフェールオーバーの状況で何が起こっているかを示す視覚的なグラフによって、すべての疑問が解消されます。 TTLを無視するISPがいくつかあり、古いブラウザを使用しているユーザーもいますが、2つのデータセンターの場所で1日に何百万ものページビューからのトラフィックを見ていて、DNSトラフィックシフトを行う場合- TTLを無視して入ってくる残りのトラフィックは笑える。 DNSフェイルオーバーは確かな手法です。
DNSはフェイルオーバー用に設計されていませんが、堅固な監視システムと組み合わせるとフェイルオーバーのニーズに驚くほど機能するTTLで設計されました。 TTLは非常に短く設定できます。高速DNSフェイルオーバーベースのソリューションを軽量化するために、本番環境では5秒のTTLを効果的に使用しています。あなたは余分な負荷を処理することができるDNSサーバーを持っている必要があります-そしてnamedはそれをカットしません。ただし、冗長ネームサーバー上のmysqlで複製されたデータベースを利用する場合、powerdnsは適切な方法です。また、自動フェイルオーバー統合のために信頼できる堅牢な分散監視システムも必要です。 Zabbixは私にとってはうまくいきます-複数の分散Zabbixシステムからの停止をほぼ瞬時に確認できます-powerdnsによってオンザフライで使用されるmysqlレコードを更新し、停止およびトラフィックの急上昇中にほぼ瞬時のフェイルオーバーを提供します。
でもねえ-私は何年にもわたって大企業でDNSフェイルオーバーサービスを機能させた後、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 DNS RRが高可用性に適さない理由をより明確に説明できるでしょう。
おかげで、
ヴァレンティノ
PS：リンク切れのため申し訳ありませんが、新しいユーザーとして、1つ以上投稿することはできません
私は、長年トラフィックが運用されているがビジネス上重要なWebサイト（2つの地域）でDNS RRフェイルオーバーを実行していました。
それはうまく機能しますが、私が難しい方法を学んだ少なくとも3つの機微があります。
1）クライアントが利用できるキャッシュされたDNSでブラウザーがアクティブであると見なされた場合、ブラウザーは30秒（前回チェック）後に非稼働IPから稼働IPにフェイルオーバーします。これは基本的に良いことです。
ただし、ユーザーが30秒待つ "半分"は受け入れられないので、おそらくTTLレコードを数日または数週間ではなく数分に更新して、停止した場合、ダウンしているサーバーをDNSからすばやく削除できます。
2）ネームサーバーの1つ（または2つの地域の1つ）がダウンしてラウンドロビンドメインにサービスを提供している場合、プライマリサーバーの1つがダウンすると、それを削除しようとする他の問題が発生する可能性があります。 SOAネームサーバーのTTL /有効期限も十分に低い値に設定していない場合、DNSからネームサーバーがダウンしました。ここでは技術的な詳細が間違っている可能性がありますが、1つだけではありません= TTL単一障害点から実際に防御するために正しく取得する必要がある設定。
3）RESTサービスなどのWeb APIを公開する場合、これらは通常ブラウザによって呼び出されないため、私の意見ではDNSフェイルオーバーが実際の欠陥を示し始めます。 「お勧めしません」と言います。これが私がそう言う理由です。まず、これらのURLを使用するアプリは通常ブラウザではないため、一般的なブラウザの30秒のフェイルオーバープロパティ/ロジックがありません。次に、 2番目のDNSエントリが呼び出されるか、DNSが再ポーリングされる場合でも、これらのAPI/RESTクライアントで使用されるプログラミング言語でのネットワークライブラリの低レベルのプログラミングの詳細に加えて、API/RESTクライアントによる呼び出し方法に完全に依存します。 app（それらがカバーするところで、ライブラリはget_addrを呼び出しますか、そしていつですか？ソケットがハングまたはクローズした場合、アプリは新しいソケットを再度開きますか？なんらかのタイムアウトロジックがありますか？など）
安く、十分にテストされており、「ほぼ機能する」。ほとんどの場合と同様に、走行距離は異なる場合があります。
フェイルオーバーに私たち（Dyn）を使用する人はたくさんいます。サイトがダウンタイムのあるときにステータスページを表示できるのも同じ理由です（Twitterのフェイルクジラのようなものを考えてください）...または単に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レコードがのIPをポイントするようにします。場所B.次に、TTLを非常に低い数に設定し、レジストラのドメインレコードがNS1とNS2に対して設定されていることを確認します。そうすることで、自動的に負荷が分散され、1つのサーバーまたは1つの場所への1つのリンクがダウンした場合にフェールオーバーされます。
私はこのアプローチを少し異なる方法で使用しました。 2つのISPを持つ1つの場所があり、この方法を使用して各リンクにトラフィックを転送します。今、それはあなたがやるよりも少しメンテナンスかもしれません...しかし、私はNS1レコードを自動的にプルし、選択したゾーンのAレコードIPアドレスを更新し、それらのゾーンをにプッシュする簡単なソフトウェアを作成することができましたNS2。
代替は、BGPベースのフェイルオーバーシステムです。設定は簡単ではありませんが、防弾対策が必要です。サイトAを1つの場所に、サイトBをもう1つの場所にすべてローカルIPアドレスで設定し、クラスCまたは他のIPブロックを取得して、ポータブルIPからローカルIPへのリダイレクトを設定します。
落とし穴がありますが、そのレベルの制御が必要な場合はDNSベースのソリューションよりも優れています。
マルチデータセンターのフェイルオーバーの1つのオプションは、ユーザーをトレーニングすることです。私たちは、複数の都市に複数のサーバーを提供し、登録メールに複数のサーバーを提供することをお客様に宣伝します。これには、各「サーバー」への直接リンクが含まれるため、ユーザーは一方のサーバーがダウンしているかどうかを、もう一方のサーバーへのリンクを使用できることをユーザーに知らせます。
これは、複数のドメイン名を維持するだけで、DNSフェイルオーバーの問題を完全に回避します。 www.company.comまたはcompany.comにアクセスしてログインするユーザーは、server1.company.comまたはserver2.company.comに誘導され、どちらか一方を使用するとパフォーマンスが向上することに気付いた場合、どちらかをブックマークするかを選択できます。 。 1つがダウンした場合、ユーザーは他のサーバーに移動するようにトレーニングされます。
私は過去10年間、DNSベースのサイトバランシングとフェイルオーバーを使用してきましたが、いくつか問題がありますが、それらは軽減できます。 BGPは、いくつかの点で優れていますが、複雑さが増し、おそらく追加のハードウェアコスト、収束時間なども100％ソリューションではありません...
ローカル（LANベース）のロードバランシング、GSLB、およびクラウドベースのゾーンホスティングを組み合わせると、DNSロードバランシングに通常関連するいくつかの問題を解決できることがわかりました。
これらすべての回答にはある程度の妥当性がありますが、それは本当にあなたが何をしているか、そしてあなたの予算が何であるかに依存すると思います。ここCloudfloorDNSでは、私たちのビジネスの大部分がDNSであり、高速DNSだけでなく、低TTL=オプションとDNSフェイルオーバーを提供しています。これが機能しなかった場合、私たちは事業に従事しません。うまくいきます。
稼働時間に無制限の予算がある多国籍企業の場合、ええと、ハードウェアGSLBロードバランサーとティア1データセンターは優れていますが、DNSは高速で安定している必要があります。ご存知のように、DNSはドメイン名自体以外のインフラストラクチャの重要な側面であり、オンラインプレゼンスの他のすべての部分が利用する最低レベルのサービスです。堅実なドメインレジストラーから始めて、DNSはドメインを期限切れにしないことと同じくらい重要です。 DNSがダウンします。これは、組織のオンライン全体もダウンしていることを意味します。
DNSフェイルオーバーを使用する場合、他の重要な側面はサーバーの監視（常に確認する複数の地理的位置であり、常に複数（少なくとも3つ）は誤検知を回避するために確認する必要があります）とDNSレコードを適切に管理して障害が検出されます。 TTLが低く、フェイルオーバーのオプションがいくつかあるため、これはシームレスなプロセスになり、システム管理者であれば、真夜中にポケットベルに目を覚ます必要がなくなります。
全体として、DNSフェイルオーバーは実際に機能し、非常に手頃な価格である可能性があります。ほとんどの場合、弊社またはほとんどのマネージドDNSプロバイダーから、サーバーの監視とフェールオーバーと共にAnycast DNSを入手し、ハードウェアオプションのわずかなコストで提供します。
ですから、本当の答えは「はい」です。それは機能しますが、それは誰にとってもすべての予算にとっても同じでしょうか。たぶんそうではないかもしれませんが、実際に試して自分でテストを行うまでは、IT予算が限られていて、稼働時間をできるだけ長くしたい中小企業の場合は無視するのが難しいでしょう。
今日、そのテクニックを使用して機能し、かなりうまく機能する優れたグローバルロードバランサー。たとえば、Azure Traffic Managerを確認します https://Azure.Microsoft.com/en-us/services/traffic-manager/
「そして、なぜそれをほとんどの本番環境で使用する可能性があるのか（何もないよりはましですが。）
実際には、存在が地理的に異なる場合、「何もないよりはまし」は「唯一の選択肢」としてよりよく表現されます。ハードウェアロードバランサーは単一の拠点に最適ですが、単一の拠点も単一の障害ポイントです。
DNSベースのトラフィック操作を使用して効果を上げる大規模なサイトがたくさんあります。これらは、売上がオフかどうかを1時間ごとに把握するタイプのサイトです。 「ほとんどの本番環境で使用するチャンス」を得るのは最後のようです。実際、彼らはオプションを注意深く検討し、テクノロジーを選択し、それに対して十分に支払いをしました。彼らは何かがより良いと思った場合、彼らは鼓動に残るでしょう。彼らがまだ留まることを選択しているという事実は、現実の世界の使用法について多くを語っています。
DNSベースのフェイルオーバーには、ある程度の遅延があります。それを回避する方法はありません。ただし、それでもマルチポップシナリオでフェイルオーバー管理を行うための唯一の実行可能なアプローチです。唯一の選択肢として、それは「何もないよりはまし」をはるかに超えています。
フェイルオーバーのアイデアはクラスタリングを意図したものだと思いますが、単独で実行することもできるため、1対1の可用性での運用が可能になりました。
詳細については、次のアプリケーションノートをご覧ください。
フェイルオーバー、グローバルロードバランシング、および関連する問題のホストについて説明します。
バックエンドアーキテクチャで許可されている場合は、フェイルオーバーオプションを使用したグローバルロードバランシングがより良いオプションです。このようにして、すべてのサーバーと帯域幅が可能な限り機能します。このセットアップでは、障害時に利用可能なサーバーを追加するのではなく、障害が発生したサーバーを復旧するまでサービスから撤退させます。
短い答え：それは機能しますが、制限を理解する必要があります。