web-dev-qa-db-ja.com

帯域幅を共有し、HTBを介してリアルタイムトラフィックに優先順位を付ける、どちらのシナリオがより効果的ですか？

私たちのインターネット回線に何らかのトラフィック管理を追加したいと思います。多くのドキュメントを読んだ後、HFSCは私には複雑すぎると思います（私はすべての曲線を理解していません、私はそれを正しく理解できないのではないかと思います）、CBQはお勧めしません、そして基本的にHTBはほとんどの人のために行きます。

私たちの内部ネットワークには3つの「セグメント」があり、帯域幅をそれらの間でほぼ均等に共有したいと思います（少なくとも最初は）。さらに、少なくとも3種類のトラフィック（リアルタイムトラフィック、標準トラフィック、バルクトラフィック）に従ってトラフィックに優先順位を付ける必要があります。帯域幅の共有は、リアルタイムトラフィックを可能な限り常にプレミアムトラフィックとして扱う必要があるという事実ほど重要ではありませんが、もちろん、他のトラフィッククラスも飢えている可能性はありません。

問題は、何がより理にかなっており、より良いリアルタイムスループットを保証するかということです。

  1. セグメントごとに1つのクラスを作成し、それぞれが同じレートを持ち（HTB開発者によると、リーフがないクラスでは優先度は重要ではありません）、これらの各クラスには、3つの優先度レベル（異なる優先度）に対して3つのサブクラス（リーフ）があります。と異なるレート）。

  2. 優先度レベルごとに1つのクラスがあり、それぞれが異なるレートを持ち（ここでも優先度は重要ではありません）、セグメントごとに1つずつ、3つのサブクラスがありますが、リアルタイムクラスの3つすべてが、バルクで最高の優先度と最低の優先度を持っていますクラスなど。

次のASCIIアートイメージ：

Case 1:

root --+--> Segment A
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment B
       |       +--> High Prio
       |       +--> Normal Prio
       |       +--> Low Prio
       |
       +--> Segment C
               +--> High Prio
               +--> Normal Prio
               +--> Low Prio

Case 2:

root --+--> High Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Normal Prio
       |        +--> Segment A
       |        +--> Segment B
       |        +--> Segment C
       |
       +--> Low Prio
                +--> Segment A
                +--> Segment B
                +--> Segment C

ケース1ほとんどの人がそうするように思えますが、HTB実装の詳細を正しく読まない限り、ケース2の方が優先順位が高くなる可能性があります。

HTBマニュアルによると、クラスがそのレートに達した場合、そのクラスは親から借用する可能性があり、借用する場合、優先度の高いクラスが常に最初に提供される帯域幅を取得します。ただし、低いツリーレベルで利用可能な帯域幅を持つクラスは、高いツリーレベルのクラスよりも常に優先されるとも言われています優先度に関係なく。

次の状況を想定します。セグメントCがトラフィックを送信していません。セグメントAはリアルタイムトラフィックのみを可能な限り高速に送信し（リンクのみを飽和させるのに十分）、セグメントBはバルクトラフィックのみを可能な限り高速に送信します（ここでも、リンク全体を飽和させるのに十分です）。何が起こるか？

ケース1：
セグメントA->高優先度とセグメントB->低優先度の両方に送信するパケットがあります。A->高優先度の方が優先度が高いため、レートに達するまで常に最初にスケジュールされます。現在、セグメントAから借用しようとしていますが、セグメントAのレベルが高く、セグメントB->低プリオがまだレートに達していないため、このクラスもレートに到達して借用するまで、最初に提供されます。セグメントB。両方がレートに達すると、両方が再び同じレベルになり、セグメントAのレートに達するまでセグメントA->ハイプリオが再び勝ちます。ルートから借用しようとします（セグメントCは保証されたトラフィックを使用していないため、十分なトラフィックスペアがあります）が、セグメントB-> LowPrioもルートレベルに到達するまで待機する必要があります。それが発生すると、優先順位が再び考慮され、今回はセグメントA->高優先度がセグメントCから残っているすべての帯域幅を取得します。

ケース2：
高優先度->セグメントAと低優先度->セグメントBの両方に送信するパケットがあります。ここでも、優先度が高いため、高優先度->セグメントAが優先されます。レートに達すると、帯域幅に余裕のあるHigh Prioから借用しようとしますが、レベルが高いため、Low Prio-> SegmentBが再びレートに達するまで待機する必要があります。両方がレートに達し、両方が借りなければならない場合、ハイプリオ->セグメントAは、ハイプリオクラスのレートに達するまで再び勝ちます。それが発生すると、ルートから借用しようとしますが、ルートには十分な帯域幅が残っています（現在、通常のプリオのすべての帯域幅は使用されていません）が、低プリオ->セグメントBがレート制限に達するまで再度待機する必要があります。低プリオクラスであり、ルートから借用しようとします。最後に、両方のクラスがルートから借用しようとし、優先度が考慮され、高優先度->セグメントAがルートに残っているすべての帯域幅を取得します。

どちらの場合も、借りることができる帯域幅が十分に残っていても、リアルタイムトラフィックはバルクトラフィックを待たなければならないことがあるため、どちらの場合も最適ではないようです。ただし、ケース2の場合、リアルタイムトラフィックはケース1の場合よりも待機する必要がないようです。これは、バルクトラフィックのレートに達するまで待機するだけでよく、セグメント全体のレートよりも少ない可能性が高いためです（ 1は、待機する必要のあるレートです）。それとも私はここで完全に間違っていますか？

優先度qdiscを使用して、さらに簡単なセットアップを考えました。しかし、優先キューには、何らかの形で制限されていない場合に飢餓を引き起こすという大きな問題があります。飢餓は受け入れられません。もちろん、TBF（Token Bucket Filter）を各優先度クラスに入れてレートを制限し、飢餓を回避することもできますが、そうすると、他のすべての優先度クラスであっても、単一の優先度クラスがそれ自体でリンクを飽和させることはできなくなります。空の場合、TBFはそれが発生するのを防ぎます。また、これも最適ではありません。現時点で他のクラスが必要としない場合、クラスが回線の帯域幅の100％を取得しないのはなぜですか。

この設定に関するコメントやアイデアはありますか？標準のtcqdiscsを使用して行うのは非常に難しいようです。プログラマーとして、私が自分のスケジューラーを単に書くことができれば、それはとても簡単な仕事でした（私はそれをすることは許されていません）。

linuxqostraffic-shapingtraffic-managementhtb
10
Mecki

Htbを正しく理解していれば、レートは「保証」されています。これはあなたが持っている「リアルタイム」トラフィックの速度についての考えを意味します。このレートを超えた場合にのみ、借り入れます。複数のクラスが借りたい場合は、prioを開始する必要があります。保証レートは物理的な制限を合計する必要があります。そうでなければ、それはあまりにも面倒です。

私見、ケースAは、ルートレベルで優先度またはレート制限を設定する必要があるため、実際には機能しません。異なるセグメントの優先順位/レートはお互いに何も知らず、平等に処理されます。

おそらく必要なのは、低プリオと通常のプリオの「レート」を0またはそれに近い値にし、残りの帯域幅に「上限」を追加することです。高プリオの場合、物理の100％のレートを保証します。

1
AndreasM