ラウンドロビンDNSは、静的コンテンツの負荷分散に「十分」ですか？
http://sstatic.net のWebサイト間で提供される一連の共有静的コンテンツがあります。残念ながら、このコンテンツは現在、まったく負荷分散されていません。単一のサーバーから提供されています。そのサーバーに問題がある場合、共有リソースは重要な共有JavaScriptライブラリと画像であるため、そのサーバーに依存するすべてのサイトは事実上ダウンしています。
単一サーバーへの依存を回避するために、このサーバーの静的コンテンツを負荷分散する方法を検討しています。
私はラウンドロビンDNSがせいぜいローエンド（ghetto）とさえ言うかもしれませんが、私は-ラウンドロビンDNSは、静的コンテンツの基本的な負荷分散のための「十分な」ソリューションですか？
[dns] [load-balancing] タグでこれに関するいくつかの議論があり、そのトピックに関するいくつかの素晴らしい投稿を読みました。
複数のラウンドロビンAレコードによるDNSロードバランシングの一般的な欠点を知っています。
- 通常、DNSレコードによるハートビートや障害の検出は行われないため、ローテーション内の特定のサーバーがダウンした場合、そのAレコードをDNSエントリから手動で削除する必要があります
- dNSエントリはインターネット全体で積極的にキャッシュされるため、これが機能するには、存続時間（TTL）を必ずかなり低く設定する必要があります。
- クライアントコンピューターは、複数のAレコードがあることを確認し、正しいレコードを選択する責任があります。
しかし、ラウンドロビンDNSは、静的コンテンツの「より良い代替案を調査して実装している間」の形式のロードバランシングとして、何よりも優れています。または、DNSラウンドロビンは任意の状況でほとんど価値がありませんか？
ジェフ、私は同意しません。ロードバランシングは冗長性を意味するものではなく、実際にはまったく逆です。サーバーの数が多いほど、特定の瞬間に障害が発生する可能性が高くなります。そのため、冗長性IS負荷分散を行う場合は必須ですが、残念ながら、ヘルスチェックを実行せずに負荷分散のみを提供する多くのソリューションがあり、サービスの信頼性が低下します。
DNSラウンドロビンは、負荷を複数のポイント（地理的に分散されている可能性がある）に分散することにより、容量を増やすのに優れています。ただし、フェイルオーバーは提供されません。最初に、どのタイプの障害をカバーしようとしているのかを説明する必要があります。サーバーの障害は、標準のIPアドレステイクオーバーメカニズム（VRRP、CARPなど）を使用してローカルでカバーする必要があります。スイッチの障害は、サーバー上の2つのスイッチへの回復力のあるリンクによってカバーされます。 WANリンク障害は、ルーティングプロトコルまたはレイヤー2ソリューション（例：マルチリンクPPP）を使用して、プロバイダーとの間のマルチリンクセットアップでカバーできます。サイト障害はBGPの対象となる：IPアドレスは複数のサイトに複製され、利用可能な場所でのみネットにアナウンスします。
あなたの質問から、サーバーのフェールオーバーソリューションを提供するだけでよいようです。これは、ハードウェアを必要とせず、ISPとの契約もないため、最も簡単なソリューションです。サーバーに適切なソフトウェアをセットアップする必要があるだけで、これが最も安価で信頼性の高いソリューションです。
「haproxyマシンに障害が発生した場合はどうなりますか？」それは同じだ。負荷分散と高可用性にhaproxyを使用している私が知っているすべての人が2台のマシンを持ち、ucarp、keepalived、またはハートビートのいずれかを実行して、そのうちの1つが常に利用可能であることを確認します。
これが役立つことを願っています！
ロードバランシングとして、それはゲットーですが、多かれ少なかれ効果的です。負荷からフォールオーバーしているサーバーが1つあり、それを複数のサーバーに分散したい場合は、少なくとも一時的にこれを行うのが適切な理由かもしれません。
負荷の「バランシング」としてのラウンドロビンDNSの有効な批判は数多くありますが、短期的なバンドエイド以外の目的でそれを行うことはお勧めしません。
しかし、主な動機は、単一サーバーへの依存を回避することだとあなたは言います。死んだサーバーをローテーションから外す自動化された方法がなければ、ダウンタイムを防ぐ方法としてはあまり価値がありません。 （サーバーをローテーションから自動でプルする方法と短いTTLを使用すると、それはゲットーフェイルオーバーになります。手動では、それさえできません。）
2つのラウンドロビンサーバーの1つがダウンすると、顧客の50％が失敗します。これは、サーバーが1つだけの場合の100％の障害よりも優れていますが、実際のフェールオーバーを実行する他のほとんどすべてのソリューションは、これよりも優れています。
1つのサーバーで障害が発生する確率がNの場合、2つのサーバーでは、確率は2Nです。自動化されていない高速フェイルオーバーがない場合、このスキームは、確率が増加しますユーザーに障害が発生します。
停止したサーバーのローテーションを手動で解除する場合は、その速度とで制限されます。サーバーが午前4時に死んだ場合はどうなりますか？ 真のフェイルオーバーの最良の部分は、夜通しスリープ状態になることです。すでにHAProxyを使用しています ですので、それ。 HAProxyはまさにこの状況に対応するように設計されているため、使用することを強くお勧めします。
ラウンドロビンDNSは、人々がそう思っているものではありません。 DNSサーバーソフトウェア（つまり [〜＃〜] bind [〜＃〜] ）の作成者は、ラウンドロビンがなぜ計画どおりに動作しなくなるのか疑問に思うユーザーを獲得します。 TTLが0秒であっても、キャッシュによっては最小時間（多くの場合30〜300秒）がかかることがあるので、そこにはある程度のキャッシュが存在することを理解していません。
また、AUTHサーバーはラウンドロビンを実行する場合がありますが、気になるサーバー（ユーザーが通信するキャッシュ）が動作するという保証はありません。つまり、ラウンドロビンは、クライアントの観点からの順序付けを保証せず、認証サーバーがキャッシュに提供するものだけを保証します。
実際のフェイルオーバーが必要な場合、DNSは1つのステップにすぎません。 2つの異なるクラスターに複数のIPアドレスをリストするのは悪い考えではありませんが、実際のロードバランシングを行うには、他のテクノロジー（単純なエニーキャストなど）を使用します。私は個人的に、DNSが通常間違っているため、DNSと干渉するハードウェア負荷分散ハードウェアを軽視しています。 DNSSECが登場することを忘れないでください。この領域で何かを選択する場合は、ゾーンに署名したときに何が起こるかをベンダーに尋ねてください。
以前に何度か言ったことがありますが、もう一度言います-復元力が問題である場合、DNSのトリックはnot答えです。
最高のHAシステムにより、クライアントはすべての要求に対してまったく同じIPアドレスを使い続けることができます。これはonlyの方法であり、クライアントが失敗に気付かないようにします。
したがって、基本的なルールは、真の復元力にはIPルーティングレベルのトリックが必要であることです。ロードバランサアプライアンス、またはOSPFの「等コストマルチパス」、さらにはVRRPを使用します。
一方、DNSはアドレッシングテクノロジーです。あるネームスペースから別のネームスペースにマップするためだけに存在します。それはそのマッピングへの非常に短期間の動的変更を許可するように設計されていなかったため、そのような変更を行おうとすると、多くのクライアントはそれらに気付かないか、せいぜいそれらに気づくのに長い時間。
loadは問題ではないので、別のサーバーをホットスタンバイとして実行する準備をしておくこともできます。ダムラウンドロビンを使用する場合、何かが壊れたときにDNSレコードを積極的に変更する必要があるため、ホットスタンバイサーバーを積極的にフリップして、DNSを変更しない可能性があります 。
私はすべての回答を読みましたが、私が気づかなかったことの1つは、ほとんどの最新のWebブラウザーは、サーバーが応答しない場合に代替IPアドレスの1つを試すことです。私が正しく覚えていれば、Chromeは複数のIPアドレスを試し、最初に応答するサーバーを続行します。そのため、私の意見では、DNSラウンドロビンロードバランシングは常に何よりも優れています。
ところで、私はDNSラウンドロビンを単純な負荷分散ソリューションとして捉えています。
私はこのスレッドに遅れています。ですから、私の答えはおそらく、一番下に一人で浮かんでいるだけです。
まず、質問に対する正しい答えは、質問に答えることではなく、次のように言うことです：
- 「おそらくWindows Network Load Balancing が代わりに必要です。」 [〜＃〜]または[〜＃〜]
- 「時代に合わせて、静的コンテンツを Cloud FilesまたはS のようなものに配置し、CDNで世界中にミラーリングしてください。」
NLBは成熟しており、タスクに最適で、セットアップも非常に簡単です。クラウドソリューションには、この質問の範囲外である独自の長所と短所があります。
質問
ラウンドロビンDNSは、静的コンテンツのロードバランシングの最初の手段として十分に優れており、何よりも優れていますが、「より良い代替案を調査して実装している間」の形式ですか
たとえば、2つまたは3つの静的Webサーバーの間で？はい、何もないよりはましです。 DNSラウンドロビンを サーバーヘルスチェックと統合し、一時的に停止しているサーバーをDNSレコード。したがって、このようにしてまともな負荷分散とsome高可用性を実現します。設定にはすべて5分もかかりません。
ただし、このスレッドで他の人が概説している警告は当てはまります。
- 現在のMicrosoftブラウザーは 分 のDNSデータをキャッシュするため、初期DNSキャッシュの状態に応じて、ユーザーのサブセットのフェイルオーバー時間が30分を超えていると考えています。
- フェイルオーバー中に ユーザーに表示される は...奇妙なものになる可能性があります（静的コンテンツで認証を使用しておらず、フォーム認証ではありませんが、リンクには注意が必要です）。
その他のソリューション
HAProxyは素晴らしいですが、Stack OverflowはMicrosoftテクノロジースタック上にあるため、Microsoftの負荷分散と高可用性ツールを使用すると、管理オーバーヘッドが少なくなる可能性があります。ネットワーク負荷分散が問題の一部を処理し、Microsoftは実際に L7 HTTPリバースプロキシ/ロードバランサー を現在備えています。
私はARRを自分で使用したことはありませんが、その2番目のメジャーリリース、およびMicrosoftからのリリースであることを考えると、十分にテストされていると思います。 ドキュメントを理解しやすい があり、Webノードで 静的および動的コンテンツの配信 がどのように表示されるかを示し、使用方法を以下に示します NLBを使用したARR 負荷分散と高可用性の両方を実現します。
負荷分散と回復力のメカニズムとして、DNSラウンドロビンに関する情報の不正確な提供に貢献している貢献者の数は驚くほどです。それは通常は機能しますが、それがどのように機能するかを理解し、そのすべての偽情報によって引き起こされる間違いを回避する必要があります。
1）ラウンドロビンに使用されるDNSレコードのTTLは短くする必要がありますが、ゼロではありません。TTLをゼロにすると、回復力が提供される主な方法が失われます。 。
2）DNS RRは分散しますが、負荷を分散しません。大規模なクライアントベースでは、DNSサーバーに個別にクエリを送信する傾向があるため、分散して分散します。これらの異なる最初の選択肢は、クライアントが異なるサーバーによってサービスされ、負荷が分散されることを意味します。ただし、それはすべて、DNSクエリを実行しているデバイスと、そのデバイスが結果を保持する時間に依存します。一般的な例は、企業のプロキシの背後にあるすべてのクライアント（クライアントのDNSクエリを実行する）がすべて単一のサーバーをターゲットにすることです。負荷は分散されていますが、均等にバランスが取れていません。
3）クライアントソフトウェアが適切に実装している限り（およびTTLとユーザーのアテンションスパンが短すぎない限り）、DNS RRは回復力を提供します。これは、DNSラウンドロビンが順序付けされているためですサーバーIPアドレスのリスト。クライアントソフトウェアは、接続を受け入れるサーバーが見つかるまで、それぞれに順番に接続を試みます。
したがって、最初の選択肢のサーバーがダウンしている場合、クライアントのTCP/IP接続がタイムアウトし、TTLまたはアテンションスパンのいずれも期限が切れていない場合、クライアントソフトウェアは2番目のエントリに対して別の接続を試みます。リスト内-TTLが期限切れになるか、リストの最後に到達するまで（またはユーザーが嫌悪感にあきらめるまで）など。
壊れたサーバー（障害）の長いリストと大きなTCP/IP接続の再試行制限（クライアント構成の誤機能）は、クライアントが実際に動作中のサーバーを見つける前に長期間発生する可能性があります。短すぎるa TTLは、リストの最後までたどり着くことはなく、代わりに新しいDNSクエリを発行して、新しいリストが提供される（できれば異なる順序で）ことを意味します。
ときどきクライアントが不運になり、新しいリストが壊れたサーバーで始まる。システムにクライアントの回復力を提供する最良の機会を与えるには、TTLが通常のアテンションスパンよりも長く、クライアントがリストの一番下に到達できるようにする必要があります。
クライアントが動作中のサーバーを見つけたら、それを覚えておく必要があり、次の接続を確立する必要がある場合は、検索を繰り返さないでください（TTLの有効期限が切れていない場合）。より長いTTLは、クライアントが動作中のサーバーを検索している間にユーザーが遅延を経験する頻度を減らします-より良い経験を与えます。
4）DNS TTL独自のものになり、DNSレコードを手動で変更したい場合（たとえば、長期間壊れたサーバーを削除する場合）、次に短いTTL変更が迅速に反映されるようにします（実行に取り掛かった後）。問題について知るまでにかかる時間と、手動で変更する時間のバランスを考慮してください。通常のクライアントは、 TTLが期限切れになったときに、稼働中のサーバーを新たに検索します。
DNSラウンドロビンには2つの優れた機能があり、幅広いシナリオで非常にコスト効率が高くなります。1つ目は無料で、もう1つは地理的にクライアントベースと同じくらい分散しています。
他のすべての「賢い」システムが行う新しい「失敗の単位」を導入するものではありません。相互にリンクされた要素の負荷全体で共通の同時障害が発生する可能性のある追加コンポーネントはありません。
「賢い」システムは優れており、シームレスなバランシングとフェイルオーバーのメカニズムを調整して提供する素晴らしいメカニズムを導入していますが、最終的に、シームレスなエクスペリエンスを提供するために使用する方法は、アキレス腱です。それが行われると、障害システム全体のシームレスなエクスペリエンスが提供されます。
つまり、DNSラウンドロビンは、静的コンテンツをすべて1か所でホストする単一のサーバーを超えた最初のステップとして、間違いなく「十分」です。
Windows VistaとWindows 7 ラウンドロビンのクライアントサポートを別の方法で実装 IPv6アドレス選択をIPv4にバックポートしたため。 （ RFC 3484 ）
したがって、Vista、Windows 7、およびWindows 2008のユーザーが相当数いる場合は、ersatz負荷分散ソリューションでの計画された考え方と一致しない動作が見つかる可能性があります。
ロードバランサーとして、長いTTLを使用するラウンドロビンDNSを常に使用しました。 HTTP/HTTPSサービスブラウザを使用の場合、これは非常にうまく機能します。
私は本当にストレスを感じますwith browsersほとんどのブラウザはある種の"別のIPでの再試行"を実装しているので、私はしません他のライブラリやソフトウェアが複数のIPソリューションをどのように処理するかを知っている。
ブラウザーが1つのサーバーから応答を受信しない場合、ブラウザーは自動的に次のIPを呼び出し、それを使い続けます（ダウンするまで...その後、別のIPを試行します）。
2007年に、次のテストを実行しました。
http://roundrobin.test:10080/ping.phpなどの1つのラウンドロビンエントリを指すように、Webサイトにiframeを追加します- ページは3 PHPソケット、3種類のIPでリッスンするすべてポート10080で提供されていました（ウェブサイトが実行されているため、ポート80でテストする余裕がありませんでした）
- 1つのソケット（たとえば[〜＃〜] a [〜＃〜]）があり、ブラウザが10080ポート（企業は標準ポートのみを許可します）
- 他の2つのソケット（たとえば[〜＃〜] b [〜＃〜]および[〜＃〜] c [〜＃〜]）は、オンザフライで有効または無効にできます。
私はそれを1時間走らせ、たくさんのデータを持っていました。結果は、ソケットのヒットの99.5％[〜＃〜] a [〜＃〜]の場合、どちらかのソケット[〜＃〜] b [〜＃〜]または[〜＃〜] c [〜＃〜]（もちろん、両方を同時に無効にすることはしませんでした）。ブラウザーは、iPhone、Chrome、Opera、MSIE 6/7/8、BlackBerry、Firefox 3/3.5などでした。そのため、準拠していないブラウザーでも正しく処理されていました。
今日まで、二度とテストしませんでしたが、おそらく新しいテストをセットアップするか、他の人がテストできるようにgithubにコードをリリースするでしょう。
重要な注意：ほとんどの時間機能している場合でも、一部のリクエストが失敗するという事実は削除されませんwillが失敗します。 POSTリクエストにも使用します。アプリケーションが機能しない場合はエラーメッセージが返されるため、ユーザーはデータを再度送信でき、おそらくブラウザが使用します。この場合、別のIPと保存が機能します。静的コンテンツの場合、それは非常に機能します。
そのため、ブラウザで作業している場合は、静的コンテンツまたは動的コンテンツのいずれかにラウンドロビンDNSを使用してください。ほとんど問題ありません。サーバーはトランザクションの最中にダウンすることもあり、最高のロードバランサーを使用しても、そのようなケースを処理することはできません。動的コンテンツの場合は、セッション/データベース/ファイルを同期させる必要があります。そうしないと、これを処理できません（実際のロードバランサーでも同様です）。
追加メモ：iptablesを使用して、独自のIPで動作をテストできます。たとえば、HTTPトラフィックのファイアウォールルールの前に、次を追加します。
iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT
（12.34.56.78は明らかにあなたのIPです）
DROPを使用しないでください。ポートがフィルターされたままになるため、ブラウザーはタイムアウトになるまで待機します。これで、サーバーを有効または無効にできるようになりました。最も明白なテストは、サーバーAを無効にしてページを読み込み、次にサーバーAを有効にしてサーバーBを無効にすることです。ページを再度読み込むと、ブラウザーから少し待機し、サーバーから読み込まれます。再び。 Chromeでは、ネットワークパネルでリクエストを確認することで、サーバーのIPを確認できます。 Generalの[Headers]タブに、Remote Address:という名前の偽のヘッダーが表示されます。これは、回答を得たIPです。
したがって、1つのサーバーでメンテナンスモードにする必要がある場合は、iptablesREJECTルールを1つ使用してHTTP/HTTPSトラフィックを無効にするだけで、すべてのリクエストが他のサーバーに送信されます（少し待ってから、ユーザーにはほとんど目立ちません）。
各サーバーに（たとえば、sshに使用する静的IPに加えて）追加のIPアドレスを割り当て、それをDNSプールに取り込むことをお勧めします。そして、サーバーに障害が発生した場合に備えて、いくつかのソフトウェアを使用してこれらのIPアドレスを切り替えます。たとえば、HeartbeatまたはCARPはそれを実行できますが、他にも解決策があります。
これには、サービスのクライアントにとって、設定を変更する必要がなく、DNSキャッシングやTTLを心配する必要がないという利点がありますが、DNSラウンドロビン「ロードバランシング」を利用できます。 。
特に、静的なボックスに複数のIPを配置できる場合は、おそらくそれでうまくいきます。 1つの「静的コンテンツの提供」IPと1つの「管理マシン」IPがあります。その後、ボックスがダウンした場合、既存のHAソリューションまたは手動の介入を使用して、障害が発生したマシンのIPを、他の「クラスターメンバー」の1つまたは完全に新しいマシン（稼働速度に応じて）のいずれかに起動できます。それを稼働させるために）。
ただし、このようなソリューションにはいくつかの小さな問題があります。ロードバランシングは完璧に近いとは言えません。手動の介入に依存している場合、一部の訪問者が停止する可能性があります。
ハードウェアロードバランサーは、DNSラウンドロビンよりも、負荷を共有し、「クラスターの稼働時間」を提供するという点で、おそらくより優れた働きをします。裏側では、購入、電力、冷却が必要なハードウェアの1つ（または理想的にはHAクラスターにLBがあるため2つ）であり、（場合によっては）慣れるための時間が必要です（まだ理解していない場合）専用のロードバランサーを持っている）。
質問に簡潔に答えると（ラウンドロビンDNSは、最初から十分なものであり、何もないよりも、静的コンテンツのロードバランシングの「より良い代替案を調査して実装している間」の形式です）、それはis何もないよりはましですが、他の形式のロードバランシングについては引き続き調査する必要があります。
数年前にWindowsの負荷分散を調べたところ、MicrosoftのWebファームが複数の負荷分散グループとして構成され、その間にDNSラウンドロビンが設定されているというドキュメントを見つけました。各名前空間で複数のDNSサーバーが応答できるため、Microsoftの負荷分散は自己回復機能であるため、冗長性と負荷分散の両方が提供されます。
欠点：少なくとも4台のサーバー（2台のサーバーx 2グループ）が必要です。
Schofの回答に関するJeffのコメントに答えて、HAProxyサーバー間でDNSラウンドロビンを行う方法はありますか？
現在2つのサーバーがあり、各サーバーのIPアドレスにDNSを使用してラウンドロビンしているとしましょう。 1つのサーバーがダウンすると、DNSサーバーはダウンしたことを認識せず、RRプロセスの一部としてそのIPアドレスを引き続き提供します。次に、オーディエンスの50％が、JavaScriptや画像のない壊れたサイトを取得します。
おそらく、背後にある2台のサーバーを表すWindows NLBによって処理される共通のIPアドレスを指す方が簡単です。静的コンテンツにLinuxサーバーを使用しているのでない限り、どこかで読んだことを覚えていますか？
ラウンドロビン負荷分散は、DNSゾーンも制御している場合にのみ機能するため、サーバーのリストを変更して、タイムリーにゾーンマスターにプッシュできます。
他の回答の1つで述べたように、ラウンドロビンの隠された悪はDNSキャッシングであり、サーバーとクライアントの間のどこでも発生する可能性があり、このソリューションの小さな利点を完全に無効にします。 DNS TTLが非常に低い値に設定されている場合でも、ISPまたはクライアントのDNSキャッシュさえもが死んだIPアドレスをアクティブに保つ期間をほとんど制御できません。
それは確かにSPOFを超えた改善ですが、ほんのわずかです。私はあなたのサーバーをホストしている人を見て、彼らが何を提供しなければならないかを見ます、多くは彼らが提供できるある種の基本的なロードバランサーサービスを持っています。
静的コンテンツがS3に複製された単一のサーバーがあり、プライマリがダウンしたときにS3 CNAMEに切り替えることもできます。同じ遅延が発生しますが、複数サーバーのコストは発生しません。
これは、あなたが何を話しているのか、何台のサーバーをローテーションしているのかによります。以前は複数のサーバーで実行されているサイトがあり、当時は初心者のためにDNSラウンドロビンを使用していましたが、それほど大きな問題ではありませんでした。クラッシュしなかったので、大きな問題ではありませんでした。それは本当に愚かな非複雑なシステムだったので、それは持ちこたえ、かなり一定のトラフィックレベルを持っていました。それが交通からクラッシュした場合、それは日中であり、私が簡単に対処できる何かでした。あなたの静的コンテンツは、それ自体でクラッシュを引き起こさないほど単純であると言えます。
ハードウェア障害などを除いて、サーバーはどの程度安定していますか？このコンテンツへのトラフィックは「スパイキー」ですか？まっすぐにApacheまたは何かと比較的フラットなトラフィックを想定すると、それほどクラッシュすることはなく、ラウンドロビンで十分です。
私は100％HAソリューションを説教していないので、私は反対票を投じられますが、それはあなたが求めたものではありません。それは、解決策として受け入れることのできるものと費やされた労力の両方にかかっています。
負荷分散にRR DNSを使用している場合は問題ありませんが、そうではありません。冗長サーバーを有効にするために使用していますが、その場合は問題ありません。
以前の投稿で述べたように、ハートビートを検出し、それが戻るまで打つのをやめるために何かが必要です。
幸いなことに、ハートビートはスイッチでもWindowsでも非常に安価に入手できます。
Dunnoは他のOSについて説明していますが、それもあると思います。
実際のソリューションを導入している間、十分に活用できる十分な使用率があります。あなたが言うように、TTLはかなり低く設定する必要があります。ただし、これには、問題のあるマシンをDNSから引き出すという副次的な利点があります。たとえば、SvrA、SvrB、SvrCがコンテンツを渡していて、SvrAがダウンしたとします。 DNSからそれを引き出し、低いTTLによって定義された短い期間の後、リゾルバーは稼働している別のサーバー（SvrBまたはSvrC）を見つけ出します。 SvrAをオンラインに戻し、DNSに戻します。一部の人にとってはダウンタイムが短く、他の人にとってはダウンタイムはありません。素晴らしいとは言えませんが、実用的です。静的サーバーを追加するほど、多数のユーザーグループがダウンする可能性が低くなります。
インターネットのトポロジーのために、実際の負荷分散ソリューションが提供する真のバランスの取れた分散は確実に得られません。関係するすべてのサーバーの負荷を監視します。