冗長性と遅延を削減するためにDNSプライマリ/セカンダリ/ ...を設定する正しい方法？
冗長性を目的としたDNSプライマリ/セカンダリは簡単だと思いました。私の理解では、プライマリとセカンダリが少なくとも1つ必要であり、セカンダリを地理的に異なる場所に設定する必要がありますが、別のルーターの背後にも設定する必要があります（たとえば、 https://serverfault.comを参照）。/questions/48087/why-are-there-several-nameservers-for-my-domain ）
現在、メインデータセンターには2つのネームサーバーがあります。最近、さまざまな理由でいくつかの機能停止が発生し、両方のネームサーバーが使用できなくなったため、DNSを数時間使用しなかったため、私たちとお客様の両方が離れました。私のシステム管理者チームに、別のデータセンターでのDNSサーバーのセットアップを完了し、それをセカンダリネームサーバーとして構成するように依頼しました。
ただし、私たちのシステム管理者は、他のデータセンターが少なくともプライマリデータセンターほど信頼性がない場合、これはあまり役に立たないと主張しています。彼らは、プライマリデータセンターがダウンしても、ほとんどのクライアントは適切に検索できないか、タイムアウトが長すぎると主張しています。
個人的には、この種の問題を抱えているのは私たちだけではないことと確信しており、すでに問題が解決されている可能性が高いです。これらのインターネット企業すべてが私たちの種類の問題の影響を受けているとは思えません。ただし、失敗した場合に何が発生するか（たとえば、クライアントのタイムアウト）とそれらを回避する方法を説明する適切なオンラインドキュメントが見つかりません。
私たちのシステム管理者の推論に穴をあけるためにどのような議論を使うことができますか？彼らが存在すると主張する問題をよりよく理解するために私が相談できるオンラインリソースはありますか？
返信を読んだ後のいくつかの追加メモ：
- 私たちはLinux上にいます
- さらに複雑なDNSニーズがあります。私たちのDNSエントリはいくつかのカスタムソフトウェアによって管理されており、BINDは現在Twisted DNS実装に依存しており、いくつかのビューもミックスされています。ただし、別のデータセンターに独自のDNSサーバーを設定することは完全に可能です。
- ローカルクライアントの再帰的なDNSサーバーではなく、部外者がサーバーを見つけるための信頼できるDNSについて話しています。
非常に技術的ではありますが、システム管理者との闘いに役立つ可能性がある、非常に優れた「ベストプラクティス」ドキュメントがあります。 http://www.Cisco.com/web/about/security/intelligence/dns-bcp.html
彼/彼女がシスコによって書かれた記事の正当性を認識していない場合は、システム管理者との議論をやめることもできます-管理レベルを上げる。
他の多くの「ベストプラクティス」ドキュメントでは、プライマリネームサーバーとセカンダリネームサーバーをIPブロックだけでなく、物理的な場所で分離することを推奨しています。実際、RFC 2182では、セカンダリDNSサービスを地理的に分離することを推奨しています。多くの企業にとって、これは別のデータセンターのサーバーを借りるか、または ZoneEdit や ltraDNS などのホストされたDNSプロバイダーに加入することを意味します。
残念ながら、Linux DNSリゾルバーはDNSサーバーのフェイルオーバーの検出と実行を直接サポートしているようには見えません。プライマリ解決ネームサーバーにリクエストを送り続け、設定されたタイムアウトを待ち、再試行などを行います。
これは多くの場合、すべてのリクエストで最大30秒の遅延を意味します。プライマリがダウンしている限り、最初にセカンダリを試行することなく。
私たちのAmazon EC2解決ネームサーバーが多くの従業員に到達できないため、私はこれを解決したかったのです。これにより、プロセスに大きな遅延が生じ、場合によっては解決に依存しているためにダウンタイムが発生することもあります。 Amazonが再びダウンした場合に備えて、Google/Level3ネームサーバーへの適切なフェイルオーバーが必要でした。そして、できるだけ早くフォールバックします。それは、Amazonがホスト名をローカルアドレスに解決し、インスタンス間通信のレイテンシを短縮するためです。
ただし、どのようなユースケースでも、フェイルオーバーを改善する必要があります。これを解決したかった。プロキシ処理のデーモンやサービスなどに近づかないようにしたいと考えました。そのため、単一障害点が増えるだけです。できるだけ古くて堅牢なテクノロジーを使いたかったのです。
私はcrontabとbashを使うことにし、 nsfailover.sh と書きました。お役に立てれば。
ただし、私たちのシステム管理者は、他のデータセンターが少なくともプライマリデータセンターと比べて依存可能でなければ、これはあまり役に立たないと主張しています。彼らは、プライマリデータセンターがダウンしても、ほとんどのクライアントは適切に検索できないか、タイムアウトが長すぎると主張しています。
ああ、フォーカスはdependableです。セカンダリDNSを設定するのではなく、外部へのリンクを妨害しているようです。すべて同じように、セカンダリDNSを設定し、そこから続行します。それは負荷に役立ち、ピンチで物事を支えます...しかし、彼らが他の場所が依存可能ではないと考える理由について尋ねてください。
個人的には、この種の問題を抱えているのは私たちだけではなく、すでに解決済みの問題である可能性が高いと私は確信しています。これらのインターネット会社すべてが私たちの種類の問題の影響を受けているとは想像できません。
あなたは唯一の会社ではありません、そしてこれはおそらく世界中の会社で何百万回も再ハッシュされています。
ただし、失敗した場合に何が発生するか（たとえば、クライアントのタイムアウト）とそれらを回避する方法を説明する適切なオンラインドキュメントが見つかりません。
私たちのシステム管理者の推論に穴をあけるためにどのような議論を使うことができますか？彼らが存在すると主張する問題をよりよく理解するために私が相談できるオンラインリソースはありますか？
- ローカルクライアントの再帰的なDNSサーバーではなく、部外者がサーバーを見つけるための信頼できるDNSについて話しています。
ゾーンの権限として登録されている外部DNSサービスの設定を含め、あらゆる種類のことを実行できますが、（外部の）権威サーバーを独自の（内部の）DNSサーバーのセカンダリに密かに作成します。 この設定は恐ろしく、間違っており、私が本当に悪質なシステム管理者であり、推奨するたびに子猫が死ぬことを示しています。しかし、次の2つのことを行います。
- DNSサービスを利用して負荷の大きな部分を処理し、独自の（内部）DNSの容量に関する質問を疑わしいものにします。
- 社内のDNSサーバーがダウンしている間もDNSサービスが稼働し続けるため、リンクの信頼性は問題ではありません-重要なのは、DNSサービスプロバイダーの信頼性ですです。
これが間違ったである理由：
- 「ステルスネームサーバー」と呼ばれるものを設定します。これは、ゾーンレコードに表示され、サーバーの名前をIPに照会できる一方で、外部からはアクセスされないためです。クライアントのクエリが到達することはありません。
- DNSは引き続き正常に動作しますが（ホストされたサービスが問題に対処するため）、インターネット接続がダウンしている場合、つまりそれが機能しているWebサイトがあるという意味ではありません問題の半分のみに対処します。管理者が懸念している他の問題があるようです。
問題はclients —だれでもどこでも可能です— 2つのDNSサーバーを参照し、1つが失敗した場合、セカンダリサーバーにフェールオーバーしないか、タイムアウトするまでに長いタイムアウトが発生するようです。 。
プライマリDNSサーバーとセカンダリDNSサーバーをベストプラクティスとして別の施設に配置する必要があることに同意しますが、それによってこの特定の問題がどのように解決されるかはわかりません。
クライアントが特定のIPアドレスのクエリを要求し、セカンダリのIPアドレスを無視する（またはタイムアウトするのにしばらく時間がかかる）場合は、たとえそのIPアドレスが機能し続けていても、そのIPアドレスを維持し続けるソリューションを考え出す必要があります。プライマリサーバーがダウンしています。
調査するいくつかの方向は、単一のIPアドレスのトラフィックを異なるデータセンターの複数のサーバーにリダイレクトできるロードバランサーです。またはおそらくエニーキャストルーティング。
各データセンターが異なる回路上にある限り（理想的には、クラウドまでのアップストリームプロバイダーが異なる場合）、2つのデータセンターだけで非常に信頼性の高いDNSを設定できます。選択したレジストラが適切なグルーレコードを空の大きなサーバーに入力することを確認するだけです。
私たちのセットアップは：
- 2つの物理データセンター（個別の回路、ISP、および上流プロバイダー）
- 各施設のSLBの背後にあるクラスター内の2つの物理クエリサーバー
- 2つのデータセット間のバランスを管理したい特定のレコードを提供する2つの負荷分散デバイス
- 両方のサーバークラスターから内部的にアクセス可能な隠しマスター（セキュリティのための隠しマスターのセットアップを非常に強く信じています）
このセットアップは、更新などのサーバーのダウンタイムが時々発生する場合でも、過去6年間または7年間でおよそ5秒間のアップタイムを与えるのに十分効果的です。 ultradnsのような誰かとのゾーンのホスティング...
KPWINCが言及したロードカンバセーションに関しては、100％正しいです。最小のデータセンターが負荷の100％を処理できない場合は、少なくとも必要なときに停止が発生するため、とにかく骨が折れる可能性があります=）
すべてのエッジルーターから最大負荷を取得し、それらをすべて追加してから、0.65で割ります...これは、各データセンターで必要な最小帯域幅です。私はそのルールを約5年前に導入しました。CCOとインターネットについて収集した、それを正当化するためのいくつかの文書を使用して、私たちが失敗したことはありません。ただし、これらの統計少なくともを四半期ごとに確認する必要があります。昨年の11月から2月のトラフィックは3倍近く増加しましたが、準備ができていませんでした。その明るい面は、この状況により、WAN回路の72％の負荷でパケットをドロップし始めるという非常に明確なハードデータを生成できるようになったことです。これ以上の正当化は必要ありませんでした。より多くの帯域幅のために私。
トーマス、
更新を読んだ後、私の投稿を改訂しました（以前の投稿にはWindowsソフトウェアへの参照が含まれていました）。
Sysadminがフルロケーションを処理するために必要なハードウェアがセカンダリの場所にないことを言っているように、私にはほとんど聞こえますか？
「こんにちは。プライマリロケーション（プライマリDNSを含む）がダウンした場合、COLO1がダウンしているとCOLO2がロードを処理できないので、DNSは心配する必要がありません。」と言っているように聞こえます。
それが事実である場合、私はあなたがあなたのインフラストラクチャーを調べて、より良いデザインを思いつくことを提案するでしょう。これは言うより簡単です。特に、本番環境にいるためです。
それはさておき、完璧な世界では、COLO1とCOLO2は独立して負荷を処理できます。
いったんそれが整ったら... DNSは実際には十分な速さのリフレッシュを備えた十分なDNSサーバーを持つことであり、一方が失敗した場合、稼働中のサーバーを指すようにDNSを書き換えることができます。
私はこの方法を小規模から妥当なサイズの環境で使用してきました。フェイルオーバーは通常、10分未満で完了します。
DNSサーバーが短いTTL（存続時間））の追加の負荷を処理できることを確認する必要があります。
お役に立てれば。
説明を読んだところ、部外者がサーバーを見つけるための信頼できるDNSなのか、それともローカルクライアント用の再帰的なDNSサーバーなのかが明確ではないことに気付きました。これら2つの動作は大きく異なります。
信頼できるDNSサーバーの場合、「クライアント」は、キャッシングと十分なインテリジェンスを備えた他のDNSサーバーになります。最初のサーバーがまったく遅い場合は、一度に複数のサーバーを試す傾向があり、応答が速いサーバーを優先する傾向があります。その場合の1つのデータセンターのダウンタイムは、パフォーマンスに非常にわずかな影響を与えます。
再帰DNSサーバーの場合、クライアントはローカルクライアントであり、おそらくDHCPにDNSサーバーがリストされています。最初のサーバーから2番目のサーバーに移動する前に、非常に長い（数秒）タイムアウトを設定して、毎回リストされている順序でサーバーを試します。
プライマリデータセンターがダウンした場合、いずれの場合もこれらのサーバーに到達できなくなりますが、多くの場合、そのサーバーからのエラーは到達不能なDNSサーバーからのエラーよりもわかりやすくなります。 「サーバーが見つかりませんでした」または「そのようなサーバーはありません」ではなく、「サーバーに接続できませんでした」または「接続がタイムアウトしました」。たとえば、ほとんどのSMTPサーバーは、DNSでサーバーを見つけたが到達できない場合、メールを1週間待ちます。 DNSでまったく見つからない場合は、ドメインへの配信を直ちに拒否することもあります。
セカンダリDNSが地理的にネットワークで分離されているのは良いことです。あなたは友好的な会社と二次DNSを取引できるかもしれません、そしてあなたのためにそれをするためにあなたが支払うことができる多くのDNSプロバイダーがあります。一部のレジストラは、サービスとしてセカンダリDNSも持っています。
セカンダリDNSサーバーは、ホストされている場所に応じて、機能を損なうことはありません。
プライマリホストに障害が発生した場合、セカンダリホストがホストの隣にあるかリモートロケーションにあるかに関係なく、セカンダリが引き継ぐことができます。ただし、データセンターのアップリンクが失敗した場合でも、別のデータセンターのサーバーからDNS応答が返される可能性がありますが、サーバーにアクセスできなくなります。そのため、エンドユーザーがリモートロケーションのセカンダリDNSを直接利用することはありません。
さまざまなクライアントは、DNSサーバーが利用できないことに対して他の方法で反応するため、タイムアウトするクライアントにはいくつかの真実がありますが、すべてではありません。
ただし、リモートデータセンターのセカンダリDNSは、到達するサーバーのIPアドレスを解決できるため、ルーティングをデバッグして、いつ再起動するかを確認できます。また、セカンダリMXサーバーを正しく設定すれば、メールを失うことすらありません。
あなたのシステム管理者は（ほとんど）間違っています。
権限のあるサーバーにクエリを実行する再帰サーバーは、どちらかのサイトが応答しない場合、非常に迅速に通知されます。
はい、停電時にクライアントでDNS解決の遅延がごくわずかに発生する可能性がありますが、わずか1〜2秒で、クライアントの独自のDNSサーバーがサーバーの1つがダウンしていることを認識したら、使用します。障害が発生したサーバーよりも優先される残りのサーバー。
必要に応じて（sysadminを緩和するため）、プライマリデータセンターで引き続き2台のサーバーを実行しますが、少なくとももう1台は外部に置きます。