複数のデータセンターとHTTPトラフィック：DNSラウンドロビンは、インスタントフェールオーバーを保証する唯一の方法ですか？

同じドメインを指す複数のAレコードは、安価な負荷分散技術としてDNSラウンドロビンを実装するためにほぼ排他的に使用されるようです。

DNS RRに対する通常の警告は、高可用性には向いていないということです。1つのIPがダウンすると、クライアントはそれを数分間使用し続けます。

多くの場合、ロードバランサーがより良い選択肢として提案されています。

両方の主張は完全に真実ではありません：

1. トラフィックがHTTPの場合、HTMLブラウザーのほとんどは、前のレコードがダウンしている場合、新しいDNSルックアップなしで、次のAレコードを自動的に試行できます。ここ3.1章とこちらをお読みください。

2. 複数のデータセンターが関係する場合、DNS RRがトラフィックをそれらに分散する唯一のオプションです。

それでは、複数のデータセンターとHTTPトラフィックがある場合、DNS RRを使用するのは、1つのデータセンターがダウンしたときに即座にフェイルオーバーを保証する唯一の方法ですか？

おかげで、

ヴァレンティノ

編集：

• もちろん、各データセンターにはホットスペアを備えたローカルロードバランサーがあります。
• インスタントフェールオーバーのためにセッションアフィニティを犠牲にしてもかまいません。
• 知る限り、DNSが別のデータセンターではなくデータセンターを提案する唯一の方法は、そのデータセンターに関連付けられたIPのみで返信することです。データセンターが到達不能になると、それらのIPもすべて到達不能になります。これは、スマートHTMLブラウザーが別のAレコードをすぐに試すことができる場合でも、ローカルキャッシュエントリが期限切れになり、新しいDNSルックアップが行われ、新しい作業IPを取得するまですべての試行が失敗することを意味します（DNSは自動的に1つの障害が発生した場合の新しいデータセンター）。そのため、「スマートDNS」では、即時のフェイルオーバーを保証できません。
• 逆に、DNSラウンドロビンはそれを許可します。1つのデータセンターに障害が発生すると、スマートHTMLブラウザー（そのほとんど）は、別の（稼働中の）データセンターにジャンプする他のキャッシュされたAレコードを即座に試行します。そのため、DNSラウンドロビンはセッションアフィニティまたは最低のRTTを保証しませんが、クライアントが「スマート」HTMLブラウザーである場合に即座にフェールオーバーを保証する唯一の方法のようです。

編集2：

• 一部の人々は、TCP Anycastを決定的なソリューションとして提案しています。この論文（第6章）エニーキャストは、フェイルオーバーがあると説明されているBGPコンバージェンスに関連しています。このため、エニーキャストは完了するのに15分から20秒かかります。トポロジーがこのために最適化されたネットワークでは20秒が可能です。おそらく、CDNオペレーターだけがこのような高速フェールオーバーを許可できます。

編集3：*

• 私はいくつかのDNSルックアップとtracerouteを行いました（専門家によっては二重にチェックできるかもしれません）そして：
  • TCP Anycastを使用する唯一のCDNはCacheFlyのようです。CDNネットワークやBitGravityなどの他のオペレーターはCacheFlyを使用します。エッジをリバースプロキシとして使用できないようです。したがって、インスタントフェールオーバーを許可するために使用することはできません。
  • AkamaiとLimeLightは、地理認識DNSを使用しているようです。しかし！複数のAレコードを返します。tracerouteから、返されたIPは同じデータセンターにあるようです。そのため、あるデータセンターがダウンしたときに、どのように100％SLAを提供できるのか戸惑っています。

「DNSラウンドロビン」という用語を使用する場合、通常、OPで説明されている「安価な負荷分散技術」という意味で使用します。

しかし、グローバルな高可用性のためにDNSを使用できる唯一の方法ではありません。ほとんどの場合、異なる（技術）バックグラウンドを持つ人々がうまくコミュニケーションをとることは困難です。

最適な負荷分散手法（お金に問題がない場合）は、一般的に次のように考えられています。

1. 「インテリジェントな」DNSサーバーのエニーキャストされたグローバルネットワーク、
2. そして、世界中に広がるデータセンターのセット、
3. 各DNSノードがSplit Horizo​​n DNSを実装している場合、
4. 可用性とトラフィックフローの監視は、何らかの方法で「インテリジェントな」DNSノードで利用できます。
5. ように、ユーザーのDNS要求は、IPエニーキャストを経由して最寄りのDNSサーバに流れ、
6. このDNSサーバーは、「インテリジェントな」スプリットホライズンDNSを介して、このエンドユーザーに最も近い/最適なデータセンターの低TTL Aレコード/ Aレコードセットを配布します。

DNS応答はステートレスであり、ほとんど非常に短いため、DNSにエニーキャストを使用することは一般に問題ありません。したがって、BGPルートが変更された場合、DNSクエリを中断することはほとんどありません。

エニーキャストは、長くてステートフルなHTTP会話にはあまり適していないため、このシステムはスプリットホライズンDNSを使用します。クライアントとサーバー間のHTTPセッションは1つのデータセンターに保持されます。通常、セッションを中断せずに別のデータセンターにフェイルオーバーすることはできません。

「Aレコードのセット」で示したように、「DNSラウンドロビン」と呼ぶものは、上記の設定と一緒に使用できます。通常、各データセンターの複数の高可用性ロードバランサーにトラフィック負荷を分散するために使用されます（したがって、冗長性を向上させ、単一のホストサーバーのUnixネットワークバッファーを圧倒することなく、より小さく/安価なロードバランサーを使用できます）。

それでは、複数のデータセンターとHTTPトラフィックで、DNS RRを使用することが高可用性を保証する唯一の方法であるというのは本当ですか？

いいえ、それは真実ではありません。「DNSラウンドロビン」によって、1つのドメインに対して複数のAレコードを配布することを単に意味するのではありません。しかし、DNSの巧妙な使用は、あらゆるグローバルな高可用性システムにおいて重要なコンポーネントであることは事実です。上記は、一般的な（多くの場合最良の）方法を示しています。

編集： Googleの論文「エンドツーエンドパス情報を超えてCDNパフォーマンスを最適化する」は、最高のエンドユーザーパフォーマンスを実現するためのグローバルな負荷分散の最先端のようです。

編集2： OPがリンクしている記事「なぜDNSベース.. GSLB ..が機能しない」を読んで、それは良い概要です-私はそれを見ることをお勧めします。上から読んでください。

「ブラウザのキャッシュ問題の解決策」のセクションでは、複数のAレコードが複数のデータセンターを指しているDNS応答を、瞬時のフェイルオーバーの唯一の可能な解決策として提唱しています。

下部の「Watering it down」セクションでは、クライアントが複数の大陸のデータセンターを指す場合、複数のAレコードを送信することはクールではないことが明らかです。別の大陸のDC。したがって、これが本当にうまく機能するためには、各大陸に複数のデータセンターが必要です。

これの多くはつまるところので、私は、私がアカマイやGoogleの同類からのDNSの専門家が必要になると思いますが、この上の完璧な答えを提供することはできません6. -これは、1私のステップとは異なるソリューションです実用的なノウハウについて現在配備されているDNSキャッシュとブラウザの制限。私のステップ1〜6は、AkamaiがDNSで行うことです（これを確認できる人はいますか？）。

モバイルブラウザポータル（携帯電話）でPMとして働いたことから生まれた私の気持ちは、そこにあるブラウザの多様性と全体的な破損のレベルが信じられないほどであるということです。個人的には、エンドユーザー端末が「正しいことをする」ことを必要とするHAソリューションを信頼しません。したがって、セッションを中断せずにグローバルに瞬時にフェールオーバーすることは、今日では不可能だと考えています。

上記のステップ1〜6は、コモディティテクノロジーで利用できる最高のステップだと思います。このソリューションには、瞬時のフェイルオーバーはありません。

アカマイやGoogleなどのDNSスペシャリストの1人が来て、間違っていることを証明してほしいです。:-)

あなたの質問は次のとおりです。「DNSラウンドロビンは、即時のフェールオーバーを保証する唯一の方法ですか？」

答えは：「DNSラウンドロビンはありません決してフェイルオーバ瞬間を保証する正しい方法」。

（少なくともそれ自体ではありません）

インスタントフェールオーバーを実現する正しい方法は、両方のサイトが同じIPアドレスを使用するようにBGP4ルーティングを使用することです。これを使用してインターネットのコアルーティング技術がために使用されているルートの代わりに、インターネットのコアを使用しての、右のデータセンターへの要求のアドレッシング技術を。

最も単純な構成では、これはフェイルオーバーのみを提供します。また、エニーキャストを提供するために使用することもできます。ルーティングに不安定性がある場合、スイッチオーバー時にTCPベースのプロトコルが失敗するという警告があります。

それでは、複数のデータセンターとHTTPトラフィックで、DNS RRを使用することが高可用性を保証する唯一の方法であるというのは本当ですか？

明らかにそれは虚偽の主張です-Google、Akamai、Yahooを見て、ラウンドロビン[*]応答を唯一の解決策として使用していないことを確認するだけです（一部は他のアプローチとともにそれを使用する場合があります）

考えられる多くのオプションがありますが、実際には、選択するサービス/アプリケーションに関して、他にどのような制約があるかによって異なります。

IPアドレスの「フェールオーバー」も手配すれば、単純な共存サーバーアプローチでラウンドロビン技術を使用でき、サーバー障害を心配する必要はありません。（ただし、ほとんどの場合、ロードバランシング手法、単一のIPアドレス、およびロードバランサー間のフェールオーバーを選択します。）

1つのセッションのすべての要求が同じサーバーに送られる必要があるかもしれませんが、要求を異なる地域のサーバークラスターに分散させたいですか？そのためには、ラウンドロビンは適切ではありません。特定のクライアントが毎回同じ物理サーバークラスターにアクセスするようにする必要があります（サーバー障害などの「例外」が発生する場合を除く）。DNSクエリから一貫したIPアドレスを受け取るか、同じ物理サーバークラスターにルーティングされます。そのためのソリューションには、さまざまな商用および非商用DNS「ロードバランサー」、または（ネットワークをさらに制御できる場合）BGPネットワークアドバタイズメントが含まれます。独自のドメインのネームサーバーがまったく異なる応答を提供するように単純に調整することができます（ただし、DNS要求はあらゆる場所に送信される可能性があるため、

[* DNS用語で「RR」は「リソースレコード」を意味するため、「ラウンドロビン」を使用します。]

あなたのための非常に素晴らしい観測vmiazzo +1！私はあなたがどこにいるのか正確に突き刺さっています。これらのCDNがどのように魔法を使うかに困惑しています。

以下は、CDNがネットワークを実行する方法に関する私の推測です。

• エニーキャストDNS（Jesper Mortensenによる）を使用して、最も近いデータセンターを取得する
• 彼らは異なるデータセンターにまたがるローカルネットワークを運営しており、異なるデータセンターのホストでCARPのようなことをすることができます

または

• 彼らは、ルーターまたはHot Standby Router Protocol（HSRP）でGateway Load Balancing Protocolを採用しています。データセンターの停止に対処します。
• 複数のIPが含まれる理由は、クライアントが再試行するためであり、クライアントが再試行するまでにルーティングパスが変更されている可能性があります。

現時点では、次のソリューションが私のために働いています：-DNSが複数のIPを返します。例：

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Amazonクラウドのリバースプロキシへの最後のエントリポイント。利用可能なサーバーにインテリジェントに渡されます（またはメンテナンスページで提供されます）

リバースプロキシはヒットしますが、ボットはメインプロキシと同じくらい重いです。

RFC 2782（http、imapなどのサービスにMX / priorityと同じものを適用する）がどの種類のブラウザーにも実装されていないのはなぜですか？物事は簡単になります... Mozillaで10年間公開されているバグがあります。それは商用ロードバランサーの産業の終わりになるからです??? 私はそれについて非常に失望しています。

2- Quaggaを使用してエニーキャストでこれを行うことができます

（TCPでエニーキャストが悪いという情報があったとしても、CacheFlyのようにそれを使用しているいくつかの大企業があります）

これらの質問に答えている人が実際に世界中のサーバーの大規模なネットワークを実行しているのだろうか？Googleはラウンドロビンを使用しており、私の会社は何年もそれを使用しています。いくつかの制限はありますが、かなりうまく機能します。はい、他の手段で補強する必要があります。

本当の鍵は、サーバーがダウンした場合にしゃっくりを1つか2つ受け入れることです。サーバーのプラグを抜くとき、ブラウザーがそのサーバーにアクセスしようとすると、ブラウザーがIPアドレスがダウンしていることを知るまで1分程度の遅延があります。しかし、その後すぐに別のサーバーに送信されます。

それはうまく機能し、それが多くの問題を引き起こすと主張する人々は彼らが何について話しているのか知らない。適切なデザインが必要です。

フェイルオーバーは最悪です。最高のHAは常にすべてのリソースを使用します。

私は1986年からHAに取り組んでいます。フェイルオーバーシステムを作成するために広範なトレーニングを受けましたが、フェイルオーバーのファンではありません。

また、RRは、能動的ではなく受動的であっても、負荷を分散する働きをします。サーバーログには、各サーバーのトラフィックの適切な割合が明確に示されています-合理的な範囲内です。

他の非常に簡単な選択は、DNS AまたはCNAMEレコードで低い（必要に応じて低い）TTLを使用し、このレコードを更新して、使用するIPを選択することです。

2つのISPといくつかの公共サービスがあり、3年から高可用性のためにこの方法を使用しています。

動作中のスパナの1つは、多くのISPが、設定された間隔でレコードをキャッシュし、TTL設定を完全に無視するリゾルバを適切に構成していないことです。そうではなく、言い訳はできませんが、悲しいことに、多数のWebサイトやサービスを移行した経験から、それは起こります。

TCP Anycastは実際には非常に安定しており、少なくともCacheFly（2002年以降）、Prolexic、およびBitGravityで使用されています。TCP Anycastに関する優れたプレゼンテーションがNANOG 37で行われました：http : //198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

複数のAレコードが、単一障害点を排除する唯一の方法です。他のソリューションでは、すべての着信要求がサーバーとクライアントの間のどこかの単一のデバイスを経由するように強制されます。

したがって、絶対的な冗長性を確保するには、これが必要です。それが、Googleがそれを行う理由、または継続的なサービスの可用性を保証したい他の誰かです。

なぜそうなのかは明らかです。リクエストがクライアントブラウザにルーティングされるポイントを移動する唯一の方法は、複数のAレコードです。他の方法では、クライアントブラウザーと障害が発生する可能性のあるサーバーとの間の単一ポイントに依存するため、サービスが停止します。Aレコードを使用することにより、クライアントからサーバーへの唯一の単一障害点はクライアント自体になります。

複数のAレコードを設定していない場合、ダウンタイムを求めています...

ただし、この方法は明らかに負荷分散に頼ることはできません。