ネットワークプロトコルについての楽しい話-講義27 |クラウドでのネットワークQoS：隣人のクレイジー映画、どうしたらいいですか？

関連するブログ、参照この一連のオタクの時間-ネットワークプロトコルについての何か

コミュニティでは、テナントが気付かないうちに公共の通路を占めることがよくありますか？理論上彼を探すと、彼の言葉は「道路」というクロストークのようなものです：「公共および公共、あなたは私を使用し、誰もが私を使用しますなぜ使えないの？」

さらに、家を借りたときに、そのような状況に遭遇しましたか？元々共有WIFI、オンラインにアクセスできないように小さな映画を狂って作成している人、それは迷惑ですか？

この現象はクラウドプラットフォームにも存在しますが、幸いなことに、QoS（Quality of Service）を実装してほとんどのユーザーのサービス品質を保証できるフロー制御テクノロジがあります。

マシンのネットワークのQoSを制御するには、2つの方向があります。1つはインバウンド方向で、もう1つはアウトバウンド方向です。

実際には、出力方向のみを制御できます。シェーピングを使用すると、出力フローを希望どおりに制御できます。方向を入力するように制御することができず、ポリシーによって廃棄されたパケットのみを。

ネットワークのQoSを制御する方法は何ですか？

Linuxでは、主にキューを介して、TCを介してネットワークのQoSを制御できます。

クラスレスキューイングルール

クラスレスキューイングの分野

最初のカテゴリはClassless Queuing Disciplinesと呼ばれます。ip addrについて説明したときに説明したpfifo_fastを思い出してください。これは、ネットワークパケットを分類しないテクノロジーです。

pfifo_fastは、3つのバンドと呼ばれる3つの先入れ先出しキューに分割されます。ネットワークパケットのTOSに従って、このパケットが入るキューを確認します。TOSは合計4桁で、各T桁の意味は異なり、合計16種類あります。

コマンドラインtc qdisc show dev eth0から、結果も出力できますpriomap。これも16の数値です。16種類のTOSに対応する0と2の間で、異なるTOSに対応する異なるキューを示します。その中でも、Band 0が最も優先度が高く、送信後にBand 1が送信する番で、Band 2が最後です。

確率的フェアキューイング

別の種類のクラスレスキュールールは、ストキャスティックフェアキューイングと呼ばれます。

多くのFIFOキューが確立され、TCPセッションはハッシュ値を計算し、ハッシュ値を通じて特定のキューに割り当てます。キューの反対側では、ネットワークパケットが各キューから取り出され、ポーリング戦略を介して送信されます。このようにして、単一のセッションがすべてのトラフィックを占有することはありません。

もちろん、2つのセッションのハッシュが同じである場合、それはキューを共有し、相互に影響する可能性もあります。ハッシュ関数は頻繁に変更されるため、セッションが互いに影響し合うとは限りません。

トークンバケットルール（TBF、トークンバケットフィルテ）

TBF（Token Bucket Filte）と呼ばれるクラスレスキュールールもあります。 

すべてのネットワークパケットは送信するためにキューに入れられますが、送信するキューの先頭ではありませんが、送信するトークンを取得する必要があります。

トークンは設定された速度で生成されるため、キューが非常に長くても、特定の速度で送信されます。

キューにパケットがない場合でも、トークンは所定のレートで生成されますが、バケットがいっぱいになるまで無期限に蓄積されません。バケットのサイズは、次の状況を回避するように設定されています。ネットワークパケットが長時間送信されない場合、大量のトークンが蓄積され、突然大量のネットワークパケットが到着し、それぞれがトークンを取得して、トラフィックが瞬間的に増加します。

クラスベースのキュールール

別の大きなカテゴリはClassful Queuing Disciplines（Classful Queuing Disciplines）であり、通常は階層型トークンバケット（HTB）です。

階層型トークンバケット（HTB）

HTBは多くの場合ツリーです。次に、TCによってHTBツリーを構築する方法を示す具体的な例を示します。

TCを使用してネットワークカードeth0のHTBキュールールを作成します。（1 :)のハンドルを支払う必要があります。

これはツリー全体のルートノードであり、次にブランチがあります。たとえば、図には3つのブランチがあり、ハンドルは（：10）、（：11）、（：12）です。最後のパラメータであるデフォルト12は、デフォルトで1:12に、つまり3番目のブランチに送信されることを意味します。

tc qdisc add dev eth0 root handle 1: htb default 12

このネットワークカードでは、送信速度を指定する必要があります。一般に、設定できる速度は2つあります。1つは通常の状態での速度を意味するrateであり、もう1つは最大状態での速度を意味するceilです。ルートノードの場合、2つの速度は同じであるため、（rate = 100kbps、ceil = 100kbps）の速度でルートクラスを作成します。

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps	

次のステップは、ブランチを作成することです。つまり、いくつかのサブクラスを作成します。各サブクラスには2つの速度があります。3つのブランチは、（レート= 30kbps、ceil = 100kbps）、（レート= 10kbps、ceil = 100kbps）、（レート= 60kbps、ceil = 100kbps）です。

tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

3つの速度を合計すると、ネットワークカード全体で許可されている最大速度になることがわかります。

HTBには非常に優れた機能があります。同じルートクラスの下のサブクラスは相互にトラフィックを借りることができます。キュールールの下に直接ルートクラスを作成せずに、3つのクラスを直接作成する場合、それらの間のトラフィックを借りることはできません。 。トラフィックを借用する方法では、このブランチのトラフィックが現在使用されていないときに別のブランチに貸し出すことができるため、帯域幅が無駄にならず、帯域幅が最大化されます。

最後に、リーフキュールールfifoとsfqをそれぞれ作成します。

tc qdisc add dev eth0 parent 1:10 handle 20: pfifo	limit	5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo	limit	5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10

このキュールールに基づいて、TCを介して送信ルールを設定することもできます。1.2.3.4からのパケットはポート80に送信され、最初のブランチは1:10になり、他のパケットは1.2.3.4から送信されます。 2つのブランチは1:11を取り、もう1つのブランチはデフォルトのブランチを取ります。

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src 1.2.3.4 flowid 1:11

QoSを制御するには？

OpenvSwitchを使用してクラウド内のネットワークカードを接続する方法、QoSを制御する方法について説明しました。

上記で述べたように、OpenvSwitchは2つのタイプをサポートします。

• 着信トラフィックの場合、ポリシーIngressポリシーを設定できます。

ovs-vsctl set Interface tap0 ingress_policing_rate=100000
ovs-vsctl set Interface tap0 ingress_policing_burst=10000

• 発信トラフィックの場合、HTBをサポートするようにQoSルールの出力シェーピングを設定できます。

トポロジー図を作成して、OpenvSwitchのQoSがどのように機能するかを見てみましょう。 

最初に、QoSルールをポートで作成でき、QoSルールは複数のキューを持つことができます。 

ovs-vsctl set port first_br qos=@newqos -- --id=@newqos create qos type=linux-htb other-config:max-rate=10000000 queues=0=@q0,1=@q1,2=@q2 -- --id=@q0 create queue
other-config:min-rate=3000000 other-config:max-rate=10000000 -- --id=@q1 create queue other-config:min-rate=1000000 other-config:max-rate=10000000 -- --id=@q2
create queue other-config:min-rate=6000000 other-config:max-rate=10000000

上記のコマンドは、3つのキューに対応するQoSルールを作成します。min-rateは上記のレート、max-rateは上記のセルです。スイッチを通過するネットワークパケットは、フローテーブルルールを通過し、照合後に別のキューに入る必要があります。次に、フローテーブルルールFlow（first_brはbr0のポート5）を追加できます。

ovs-ofctl add-flow br0 "in_port=6 nw_src=192.168.100.100 actions=enqueue:5:0"
ovs-ofctl add-flow br0 "in_port=7 nw_src=192.168.100.101 actions=enqueue:5:1"
ovs-ofctl add-flow br0 "in_port=8 nw_src=192.168.100.102 actions=enqueue:5:2"

次に、192.168.100.100、192.168.100.101、192.168.100.102から192.168.100.103までの帯域幅を個別にテストすると、それぞれが帯域幅を埋めることができます。

3つが一緒にテストされ、ネットワークパケットが一緒に送信される場合、3：1：6の比率に従って実行されることがわかります。これは、キューの構成された帯域幅比率に従って割り当てられます。

192.168.100.100と192.168.100.101を一緒にテストすると、帯域幅占有率は3：1であることがわかりますが、トラフィックの合計を占めています。つまり、パケットを送信しなかった192.168.100.102は、帯域幅の60％を借りています。

192.168.100.100と192.168.100.102を一緒にテストした場合、帯域幅占有率は1：2です。192.168.100.101と192.168.100.102を一緒にテストすると、帯域幅占有率は1：6になります。

まとめ

このセクションではこれですべてです。まとめましょう。

• クラウド内のフロー制御は主にキューを介して実行されます。キューは、クラスレスキュールールとカテゴリベースのキュールールの2つのカテゴリに分類されます。
• クラウドネットワークのOpenvswitchでは、主な用途は階層トークンバケットルール（HTB）です。これは、構成された比率に従ってツリーに合計帯域幅を割り当て、ブランチが使用されていない場合は別のブランチに貸し出すことができます。分岐により、帯域幅の使用率が向上します。

最後に、私はあなたに2つの思考質問を残しておきます。

1. このセクションで説明したように、実際には入力トラフィックを制御する方法はなく、出力トラフィックを適切に制御できます。クラウド内の仮想マシンの入力トラフィックを制御する方法を考えられますか？
2. セキュリティとフロー制御はおそらく解決されますが、物理ネットワーク内のさまざまなユーザーの分離はまだ解決されていません。解決方法を知っていますか？