TTL-可能ですか？
私は現在、負荷分散にDNSラウンドロビンを使用しています。レコードは次のようになります（TTLは120秒です）。
;; ANSWER SECTION:
orion.2x.to. 116 IN A 80.237.201.41
orion.2x.to. 116 IN A 87.230.54.12
orion.2x.to. 116 IN A 87.230.100.10
orion.2x.to. 116 IN A 87.230.51.65
すべてのISP /デバイスがそのような応答を同じ方法で扱うわけではないことを学びました。たとえば、一部のDNSサーバーは、アドレスをランダムにローテーションさせるか、常に循環させます。最初のエントリを伝播するだけのものもあれば、IPアドレスを調べてどちらが最適か（地域的に近い）かを判断しようとするものもあります。
ただし、ユーザーベースが十分に大きい場合（複数のISPに分散している場合など）、バランスはかなり良好です。負荷の高いサーバーから低いサーバーへの差異は、15％を超えることはほとんどありません。
ただし、システムにサーバーを追加しているという問題があり、すべてが同じ容量であるとは限りません。
現在、1 Gbpsサーバーしかないのですが、100 Mbpsサーバーと10 Gbpsサーバーも使用したいと考えています。
だから私が欲しいのは、重みが100の10 Gbpsのサーバー、重みが10の1 Gbpsサーバー、重みが1の100 Mbpsサーバーを紹介したいということです。
以前にサーバーを2回追加して、より多くのトラフィックをサーバーにもたらしました（これでニースは機能しました。帯域幅はほぼ2倍になりました）。しかし、DNSに10 Gbpsサーバーを100回追加するのは少しおかしいです。
そこでTTLの使用を考えました。
サーバーAに240秒TTLを与え、サーバーBに120秒（ラウンドロビンに使用するのに最低限必要な時間）を与えた場合、より低いTTLが指定されている場合、多くのDNSサーバーが120に設定されます。 （私は聞いたので））。私はこのようなことが理想的なシナリオで起こるべきだと思います：
First 120 seconds
50% of requests get server A -> keep it for 240 seconds.
50% of requests get server B -> keep it for 120 seconds
Second 120 seconds
50% of requests still have server A cached -> keep it for another 120 seconds.
25% of requests get server A -> keep it for 240 seconds
25% of requests get server B -> keep it for 120 seconds
Third 120 seconds
25% will get server A (from the 50% of Server A that now expired) -> cache 240 sec
25% will get server B (from the 50% of Server A that now expired) -> cache 120 sec
25% will have server A cached for another 120 seconds
12.5% will get server B (from the 25% of server B that now expired) -> cache 120sec
12.5% will get server A (from the 25% of server B that now expired) -> cache 240 sec
Fourth 120 seconds
25% will have server A cached -> cache for another 120 secs
12.5% will get server A (from the 25% of b that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of b that now expired) -> cache 120 secs
12.5% will get server A (from the 25% of a that now expired) -> cache 240 secs
12.5% will get server B (from the 25% of a that now expired) -> cache 120 secs
6.25% will get server A (from the 12.5% of b that now expired) -> cache 240 secs
6.25% will get server B (from the 12.5% of b that now expired) -> cache 120 secs
12.5% will have server A cached -> cache another 120 secs
... I think I lost something at this point, but I think you get the idea...
ご覧のとおり、これは予測がかなり複雑になり、実際にはこのように機能しないことは確かです。しかし、それは間違いなくディストリビューションに影響を与えるはずです！
加重ラウンドロビンが存在し、ルートサーバーによって制御されるだけであることは知っています。応答時にDNSレコードを循環し、重み付けに対応する設定された確率でDNSレコードを返します。私のDNSサーバーはこれをサポートしておらず、私の要件はそれほど正確ではありません。重量が完全にかからない場合は問題ありませんが、正しい方向に進む必要があります。
TTLフィールドを使用すると、よりエレガントで簡単なソリューションになると思います。これは、これを動的に制御するDNSサーバーを必要とせず、リソースを節約します。これは、DNS負荷分散とハードウェアロードバランサー。
私の質問は次のとおりです。DNSレコードのTTL属性を使用してラウンドロビン分散を重み付けするためのベストプラクティス/方法/経験則はありますか？
編集：
システムはフォワードプロキシサーバーシステムです。帯域幅の量（要求ではない）が、イーサネットを備えた1台のサーバーで処理できる量を超えています。そのため、帯域幅を複数のサーバーに分散するバランスソリューションが必要です。 DNSを使用する以外の方法はありますか？もちろん、ファイバーチャネルなどを備えたロードバランサーを使用することもできますが、コストはばかげており、ボトルネックの幅のみを増やし、それを排除することはできません。私が考えることができるのはエニーキャスト（エニーキャストかマルチキャストか）のIPアドレスだけですが、そのようなシステムをセットアップする手段がありません。
まず、私は@Alnitakに完全に同意します。DNSはこのようなもののために設計されていません。ベストプラクティスは、DNSを貧しい人のロードバランサーとして（乱用）しないことです。
私の質問は次のとおりです... DNSレコードのTTL属性を使用してラウンドロビン分散に重みを付けるための最善の方法/方法/経験則はありますか？
質問の前提で回答するには、DNSを使用してbasix加重ラウンドロビンを実行するために使用されるアプローチは次のとおりです。
- 信頼できるDNS応答のレコードの相対発生を調整します。つまりもし
Server Aはトラフィックの1/3であり、Server Bは2/3を持ち、DNSプロキシへの権威あるDNS応答の1/3はonlyAのIPと2/3の応答のみを含みますBのIP。 （2つ以上のサーバーが同じ「重み」を共有する場合、それらを1つの応答にまとめることができます。） - 低いDNSを維持するTTLこれにより、不均衡な負荷が比較的迅速に均等化されます。ダウンストリームDNSプロキシの背後には非常に偶数のクライアントが存在するため、再シャッフルする必要があります頻繁に記録します。
Amazonの Route 53 DNSサービスはこの方法を使用しています 。
（リクエストではなく）帯域幅の量が、イーサネットを備えた単一のサーバーが処理できる量を超えています。そのため、帯域幅を複数のサーバーに分散するバランスソリューションが必要です。
正しい。私が理解しているように、サービスのビットレートの合計が1 GBitを超える、ある種の「安価な」ダウンロード/ビデオ配信/大きなファイルのダウンロードサービスがあります。
サービスとサーバーのレイアウトの正確な詳細を知らなければ、正確にするのは困難です。しかし、この場合のa一般的な解決策は次のとおりです。
- 2つ以上のTCP/IPまたはHTTPレベルのロードバランサーインスタンスへのDNSラウンドロビン。
- 各ロードバランサーインスタンスの可用性が高い（2つの同一のロードバランサーが1つのIPアドレスを常にオンに保つために協力している）。
- バックエンドサーバーへの加重ラウンドロビンまたは加重ランダム接続処理を使用する各ロードバランサーインスタンス。
この種のセットアップは、オープンソースソフトウェア、または多くのベンダーの専用アプライアンスで構築できます。 負荷分散タグ ここが素晴らしい出発点です。または、これを行ったシステム管理者を雇って相談することもできます...
私の質問は次のとおりです... DNSレコードのTTL属性を使用してラウンドロビン分散に重みを付けるための最善の方法/方法/経験則はありますか？
はい、ベストプラクティスはしないでください !!
私の後で繰り返してください
- DNSは負荷分散用ではありません
- DNSは回復力を提供しません
- DNSはフェイルオーバー機能を提供しません
DNSは、名前を1つ以上のIPアドレスにマッピングするためのものです。その後のバランス調整は、設計ではなく運によるものです。
PowerDNS を見てください。カスタムパイプバックエンドを作成できます。 Perlで作成されたロードバランサーDNSバックエンドの例を、Algorithm :: ConsistentHash :: Ketamaモジュールを使用するように変更しました。これにより、次のように任意の重みを設定できます。
my $ketamahe = Algorithm::ConsistentHash::Ketama->new();
# Configure servers and weights
$ketamahe->add_bucket("192.168.1.2", 50);
$ketamahe->add_bucket("192.168.1.25", 50);
そしてもう一つ：
# multi-colo hash
my $ketamamc = Algorithm::ConsistentHash::Ketama->new();
# Configure servers and weights
$ketamamc->add_bucket("192.168.1.2", 33);
$ketamamc->add_bucket("192.168.1.25", 33);
$ketamamc->add_bucket("192.168.2.2", 17);
$ketamamc->add_bucket("192.168.2.2", 17);
希望するトップレベルドメインのcnameを、gslbまたはGlobal Server Load Balancingと呼ぶサブドマンに追加しました。そこから、このカスタムDNSサーバーを呼び出して、希望する重みに従ってAレコードを送信します。
チャンピオンのように機能します。 ketamaハッシュには、サーバーを追加したり、重みを調整したりするときの既存の構成への影響を最小限に抑えるという素晴らしい特性があります。
Jan-Piet Mensによる代替DNSサーバーを読むことをお勧めします。彼はそこに多くの良いアイデアとサンプルコードを持っています。
TTL変調を放棄することもお勧めします。すでにかなり遠くまで進んでいるため、別のクラッジを上に追加すると、トラブルシューティングと文書化が非常に困難になります。
PowerDNSを使用して加重ラウンドロビンを実行できますが、負荷をこのような不均衡な方法（100：1？）で分散することは、少なくとも各ソリューションに使用したアルゴリズムで非常に興味深い場合があります。 、1〜100の範囲で、ランダムな値を使用してレコードを含めたり除外したりします。
PowerDNSでMySQLバックエンドを使用して重み付けされたRR DNSを実行することについて私が書いた記事は次のとおりです。 http://www.mccartney.ie/wordpress/2008/08/wrr-dns-with-powerdns/
RIPienaarにもいくつかのRubyベースの例（PowerDNSパイプバックエンドを使用））： http://code.google.com/p/Ruby-pdns/wiki/RecipeWeightedRoundRobin =
この種のセットアップに対処するには、実際の負荷分散ソリューションを検討する必要があります。 Linux Virtual Server および HAProxy をお読みください。サーバーに障害が発生し、その影響がはるかに容易に理解された場合、サーバーがプールから自動的に削除されるという追加の利点があります。重み付けは、単に調整する設定です。