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倍になりました）。しかし、10 Gbpsサーバーを100回DNSに追加するのは少しおかしいです。

そこでTTLの使用を考えました。

サーバーAにTTLを240秒、サーバー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属性を使用してラウンドロビン分散を重み付けするためのベストプラクティス/方法/経験則はありますか？

編集：

システムはフォワードプロキシサーバーシステムです。帯域幅の量（要求ではない）は、イーサネットを備えた単一のサーバーが処理できる量を超えています。そのため、帯域幅を複数のサーバーに分散するバランスソリューションが必要です。DNSを使用する以外の方法はありますか？もちろん、ファイバーチャネルなどを備えたロードバランサーを使用することもできますが、コストはばかげており、ボトルネックの幅のみを増やし、それを排除することもできません。私が考えることができるのはエニーキャスト（エニーキャストかマルチキャストか）IPアドレスだけですが、そのようなシステムをセットアップする手段がありません。

まず、私はDNSがこの種の目的のために設計されていないという@Alnitakに完全に同意します。ベストプラクティスはDNSを貧乏人のロードバランサーとして（乱用）しないことです。

私の質問は次のとおりです... DNSレコードのTTL属性を使用してラウンドロビン分散を重み付けするための最善の方法/方法/経験則はありますか？

質問の前提で答えるために、 DNSを使用してbasix加重ラウンドロビンを実行するために使用されるアプローチは次のとおりです。

• 信頼できるDNS応答でのレコードの相対的出現を調整します。つまりServer A、トラフィックの1/3とServer B2/3がある場合、DNSプロキシへの信頼できるDNS応答の1/3にはのIP のみ が含まれA、応答の2/3にはのIP のみが含まれBます。（2つ以上のサーバーが同じ「重み」を共有する場合、それらを1つの応答にまとめることができます。）
• 不均衡な負荷が比較的迅速に均等化されるように、DNS TTLを低く保ちます。ダウンストリームDNSプロキシの背後には非常に偶数のクライアントがあるため、レコードを頻繁に再シャッフルする必要があります。

AmazonのRoute 53 DNSサービスはこの方法を使用します。

（リクエストではなく）帯域幅の量が、イーサネットを備えた単一のサーバーが処理できる量を超えています。そのため、帯域幅を複数のサーバーに分散するバランスソリューションが必要です。

正しい。私が理解しているように、サービスのビットレートの合計が1 GBitを超える、ある種の「安価な」ダウンロード/ビデオ配信/大きなファイルのダウンロードサービスがあります。

サービスとサーバーのレイアウトの正確な詳細を知らなければ、正確にするのは困難です。しかし、この場合の一般的な解決策は次のとおりです。

• 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を読んでください。サーバーに障害が発生し、その影響がはるかに簡単に理解された場合、サーバーがプールから自動的に削除されるという追加の利点があります。重み付けは、単に調整する設定です。