11
複数のデータセンターとHTTPトラフィック：DNSラウンドロビンは、インスタントフェールオーバーを保証する唯一の方法ですか？
同じドメインを指す複数のAレコードは、安価な負荷分散技術としてDNSラウンドロビンを実装するためにほぼ排他的に使用されるようです。 DNS RRに対する通常の警告は、高可用性には向いていないということです。1つのIPがダウンすると、クライアントはそれを数分間使用し続けます。 多くの場合、ロードバランサーがより良い選択肢として提案されています。 両方の主張は完全に真実ではありません： トラフィックがHTTPの場合、HTMLブラウザーのほとんどは、前のレコードがダウンしている場合、新しいDNSルックアップなしで、次のAレコードを自動的に試行できます。ここ3.1章とこちらをお読みください。 複数のデータセンターが関係する場合、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を提供できるのか戸惑っています。