複数のデータセンターとHTTPトラフィック：DNSラウンドロビンは、瞬時のフェイルオーバーを保証する唯一の方法ですか？
同じドメインを指す複数のAレコードは、安価な負荷分散手法としてDNSラウンドロビンを実装するためにほぼ排他的に使用されているようです。
DNS RRに対する通常の警告は、高可用性には適さないということです。 1つのIPがダウンすると、クライアントは数分間それを使用し続けます。
ロードバランサーは、多くの場合、より良い選択として提案されています。
両方の主張は完全に真実ではありません：
トラフィックがHTTPの場合、ほとんどのHTMLブラウザは、前のレコードがダウンしている場合、新しいDNSルックアップなしで、自動的に次のAレコードを試すことができます。 ここ3.1章およびここ。
複数のデータセンターが関係する場合、DNS RRはそれらにトラフィックを分散させる唯一のオプションです。
では、複数のデータセンターとHTTPトラフィックがある場合、1つのデータセンターがダウンしたときにインスタントフェールオーバーを保証する唯一の方法はDNS RRの使用であることは本当ですか？
おかげで、
ヴァレンティノ
編集：
- もちろん、各データセンターには、ホットスペアを備えたローカルロードバランサーがあります。
- インスタントフェイルオーバーのためにセッションアフィニティを犠牲にしてもかまいません。
- AFAIKが、DNSが別のデータセンターではなくデータセンターを提案する唯一の方法は、そのデータセンターに関連付けられているIPのみを返信することです。データセンターが到達不能になると、それらのIPもすべて到達不能になります。つまり、スマートHTMLブラウザーがすぐに別のAレコードを試すことができたとしても、ローカルキャッシュエントリの有効期限が切れて新しいDNSルックアップが行われ、新しい有効なIPがフェッチされるまで、すべての試行は失敗します（DNSは自動的に障害発生時の新しいデータセンター）。そのため、「スマートDNS」は即時のフェイルオーバーを保証できません。
- 逆に、DNSラウンドロビンはそれを許可します。 1つのデータセンターに障害が発生すると、スマートHTMLブラウザー（それらのほとんど）は、キャッシュされた他のAレコードを即座に試し、別の（稼働中の）データセンターにジャンプします。したがって、DNSラウンドロビンは、セッションアフィニティまたは最低のRTTを保証しませんが、クライアントが「スマート」なHTMLブラウザーである場合に瞬時のフェイルオーバーを保証する唯一の方法のようです。
編集2：
- 一部の人々はTCP決定的な解決策としてのエニーキャストを提案します。this論文（第6章）は、AnycastフェイルオーバーがBGPコンバージェンスに関連していると説明されています。このため、Anycastは、完了までに15分から20秒を使用できます。トポロジが最適化されたネットワークでは、20秒が可能です。おそらくCDNオペレーターだけがそのように許可できます。高速フェイルオーバー。
編集3：*
- 私はいくつかのDNSルックアップとtracerouteを行いました（多分一部の専門家は再確認できます）と：
- TCPエニーキャストを使用する唯一のCDNはCacheFlyのようですが、CDNネットワークやBitGravityなどの他のオペレーターはCacheFlyを使用しています。そのエッジはリバースプロキシとして使用できないようです。したがって、インスタントを付与するために使用することはできません。フェイルオーバー。
- AkamaiとLimeLightは地理認識DNSを使用しているようです。だが！それらは複数のAレコードを返します。 traceroutesから、返されたIPは同じデータセンターにあるようです。したがって、1つのデータセンターがダウンした場合に100％を提供する方法に困惑していますSLA.
「DNSラウンドロビン」という用語を使用する場合、OPで説明されているように、一般に「安価な負荷分散手法」という意味で使用します。
しかし、DNSをグローバルな高可用性に使用できる唯一の方法ではありません。ほとんどの場合、さまざまな（テクノロジー）背景を持つ人々がうまくコミュニケーションをとることは困難です。
最良のロードバランシング手法（お金が問題にならない場合）は、一般的に次のように考えられています。
- エニーキャストの「インテリジェント」DNSサーバーのグローバルネットワーク
- 世界中に広がるデータセンターのセット、
- 各DNSノードはスプリットホライズンDNSを実装し、
- 可用性とトラフィックフローの監視は、「インテリジェント」DNSノードで何らかの方法で利用できます。
- user DNSリクエストがIP Anycastを介して最も近いDNSサーバーに流れるように、
- そして、このDNSサーバーは、nearest/bestdatacenter「インテリジェントな」スプリットホライズンDNSを介したこのエンドユーザーの場合。
DNSへのエニーキャストの使用は、DNS応答がステートレスでほとんど非常に短いため、通常は問題ありません。したがって、BGPルートが変更された場合、DNSクエリを中断する可能性はほとんどありません。
エニーキャストは、長くてステートフルなHTTP会話にはあまり適していないため、このシステムではスプリットホライズンDNSを使用します。クライアントとサーバー間のHTTPセッションは1つのデータセンターに保持されます。通常、セッションを中断せずに別のデータセンターにフェイルオーバーすることはできません。
「Aレコードのセット」で示したように、「DNSラウンドロビン」と呼ばれるものは、上記のセットアップと共に使用できます。これは通常、各データセンターの複数の高可用性ロードバランサーにトラフィックの負荷を分散するために使用されます（より良い冗長性を得ることができるように、単一のホストサーバーのUnixネットワークバッファーを圧迫するのではなく、より小さな/より安いロードバランサーを使用します）。
では、複数のデータセンターとHTTPトラフィックがある場合、DNS RRの使用が高可用性を保証する唯一の方法であることは本当ですか？
いいえ、それは真実ではありません。「DNSラウンドロビン」によってドメインの複数のAレコードを渡すことを単に意味するのではありません。しかし、DNSの巧妙な使用は、グローバルな高可用性システムの重要なコンポーネントであることは事実です。上記は、一般的な（多くの場合最良の）方法の1つを示しています。
編集：Googleペーパー "CDNパフォーマンスを最適化するためのエンドツーエンドパス情報を超えて移動する" のようです最高のエンドユーザーパフォーマンスを実現する、最先端のグローバル負荷分散。
編集2：記事を読みました "DNSベースの理由.. GSLB ..機能しません" OPがリンクしている、そしてそれは良い概観です-私はそれを見るのをお勧めします。上から読んでください。
「ブラウザキャッシュの問題の解決策」セクションでは、瞬時のフェイルオーバーのための唯一の可能な解決策として、複数のAレコードが複数のデータセンターを指すDNS応答を提唱しています。
下部にある「Watring it down」のセクションでは、クライアントがランダムに接続するため、複数のAレコードを送信することは、複数の大陸のデータセンターを指す場合に不快であることが明らかです。 DC別の大陸にあるため、これが本当にうまく機能するためには、各大陸に複数のデータセンターが必要です。
これは私のステップ1〜6とは異なるソリューションです。これについて完璧な答えを提供することはできません。AkamaiやGoogleなどのDNSスペシャリストが必要だと思います。これの多くは今日配備されているDNSキャッシュとブラウザの制限に関する実用的なノウハウ。 AFAIK、私のステップ1〜6は、AkamaiがDNSで行うことです（誰でもこれを確認できますか？）。
私の感想-PMモバイルブラウザポータル（携帯電話）として働いたことから来た）-total brokeness信じられないほど多くのブラウザーがあります。個人的には、エンドユーザー端末が「正しいこと」を行うことを要求するHAソリューションを信頼しません。そのため、セッションを中断せずにグローバルに瞬時にフェイルオーバーすることは、今日では不可能だと思います。
上記のステップ1〜6は、商品テクノロジーで利用できる最良のステップだと思います。このソリューションには、瞬時のフェイルオーバーはありません。
AkamaiやGoogleなどのDNSスペシャリストの1人が来て、私が間違っていることを証明したいと思っています。 :-)
あなたの質問は次のとおりです。「DNSラウンドロビンは、即時フェイルオーバーを保証する唯一の方法ですか？」
答えは、「DNSラウンドロビンは[〜＃〜] never [〜＃〜]瞬時のフェイルオーバーを保証する正しい方法です」です。
（少なくともそれだけでは）
インスタントフェイルオーバーを実現する正しい方法は、両方のサイトが同じIPアドレスを使用するようにBGP4ルーティングを使用することです。これを使用して、インターネットのコアルーティングテクノロジーを使用して、要求をルーティングインターネットのコアアドレッシングテクノロジーを使用する代わりに、適切なデータセンター。
最も単純な構成では、これonlyがフェイルオーバーを提供します。また、TCPベースのプロトコルは、ルーティングに不安定がある場合、切り替え時に失敗します。）というエニーキャストを提供するためにも使用できます。
では、複数のデータセンターとHTTPトラフィックがある場合、DNS RRの使用が高可用性を保証する唯一の方法であることは本当ですか？
明らかにそれは誤った主張です。Google、Akamai、Yahooを見て、ラウンドロビン[*]応答を唯一のソリューションとして使用していないことを確認するだけです（他のアプローチとともに一部で使用している場合もあります） 。）
可能なオプションは多数ありますが、それは実際には、他の制約、つまり選択するサービス/アプリケーションによって異なります。
IPアドレスの「フェイルオーバー」も準備すれば、単純な同じ場所に配置されたサーバーアプローチでラウンドロビンテクニックを使用でき、サーバーの障害を心配する必要がありません。 （しかし、ほとんどの場合、ロードバランシング技術、単一のIPアドレス、およびロードバランサー間のフェイルオーバーが選択されます。）
たぶん、同じサーバーに行くために単一のセッションのすべての要求が必要ですが、要求を異なる地域のサーバークラスタに分散させたいですか？そのため、ラウンドロビンは適切ではありません。特定のクライアントが毎回同じ物理サーバークラスターにアクセスできるようにする必要があります（サーバー障害などの「例外」が発生した場合を除く）。 DNSクエリから一貫したIPアドレスを受け取るか、同じ物理サーバークラスターにルーティングされます。そのためのソリューションには、さまざまな商用および非商用のDNS "ロードバランサー"、または（ネットワークをより詳細に制御できる場合）BGPネットワークアドバタイズが含まれます。独自のドメインのネームサーバーがまったく異なる応答を返すように調整することもできます（ただし、DNS要求はあちこちに送信される可能性があるため、そのアプローチでは場所の類似性を実現できません）。
[* DNS用語の「RR」は「リソースレコード」を意味するため、「ラウンドロビン」を使用します。]
とても素敵な観察vmiazzo +1 for !!これらのCDNが魔法をかける方法に困惑しています。
以下は、CDNがネットワークを実行する方法に関する私の推測です。
- Anycast DNS（Jesper Mortensenが言及）を使用して最も近いデータセンターを取得する
- 彼らはlocal networkを実行し、さまざまなデータセンターにまたがって [〜＃〜] carp [ 〜＃〜] 異なるデータセンターのホスト上
または
- ルーターに Gateway Load Balancing Protocol または Hot Standby Router Protocol（HSRP） を採用しています。データセンターの停止に対処します。
- それらに複数の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年間オープンしました!!!それは商業ロードバランサーの業界の終わりになるので???私はそれについて非常に失望しています。
これらの質問に答える何人の人が実際に世界規模の大規模なサーバーネットワークを運用しているのでしょうか。 Googleはラウンドロビンを使用しており、私の会社はこれを何年も使用しています。それはいくつかの制限付きでかなりうまくいくことができます。はい、それは他の手段で増強される必要があります。
本当の鍵は、サーバーがダウンした場合に一時的または2つの問題を受け入れる用意があることです。サーバーのプラグを抜いたときに、ブラウザーがそのサーバーにアクセスしようとすると、ブラウザーがIPアドレスがダウンしていることを学習する間、1分程度の遅延があります。しかし、それは別のサーバーに非常に速く行きます。
それは素晴らしい働きをし、それが多くの問題を引き起こすと主張する人々は彼らが何を話しているのか分からない。適切な設計が必要です。
フェイルオーバーはひどい。最高のHAは、常にすべてのリソースを使用します。
私は1986年からHAで働いています。フェイルオーバーシステムを作成するために広範なトレーニングを受けましたが、フェイルオーバーのファンではありません。
また、RRは、アクティブではなくパッシブであっても、負荷を分散するように機能します。私たちのサーバーログは、各サーバー上のトラフィックの適切な割合を明確に示しています。
TCP Anycastは実際には非常に安定しており、少なくともCacheFly（2002年以降）、Prolexic、およびBitGravityで使用されています。 TCPエニーキャストはNANOG 37で行われました： http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf
作業中のスパナの1つは、設定された間隔でレコードをキャッシュし、TTL設定を完全に無視する、不適切に構成されたリゾルバを多数のISPが持っていることです。そうすべきではなく、そのための言い訳はありません。が、残念ながら、多くのWebサイトとサービスを移行した経験から、それは実現しています。
他の非常に簡単な選択は、DNS AまたはCNAMEレコードで低（必要に応じて低）TTLを使用し、このレコードを更新して、使用するIPを選択することです。
私たちは2つのISPといくつかの公共サービスを利用しており、3年間の高可用性のためにこの方法をうまく使用しています。