以前から気になっていたTCP BBR。Youtubeではかなりのパフォーマンスが向上したらしい。
しかし、テストをしていたが全然効果がない。全く。どうやらホームラボで確認する限りは効果がない。
効果がわかる検証ができたのでご紹介。
まず、BBRって何？ネットワークの輻輳制御アルゴリズムである。これを制御することでネットワーク通信が効率よくできる。
何も設定をしない場合は、CUBICというモードになる。
CUBICは，パケット廃棄数をネットワークの輻輳状態の指標とする
以下のように表示されていればCUBIC
# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
BBRは，RTTをネットワークの輻輳状態の指標とする
以下のように表示されていればBBR
# cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
まとめると、このBBRは、そこそこ遠いサイトへの通信で効果がでてくるのではと。。。
というわけでオブジェクトストレージで確認をしてみる。それも遠目のもの。今回はbackblaze B2を利用することに
オブジェクトストレージにいきなりベンチマークをとっても、「試してガッテン」になるのである程度、予備試験をする。
環境は、NURO光でUbuntu Server 20.04のvSphere 7.0U2のVM (2vcpu 4GB RAM)
まずは 経路の確認。16ホップで到達する様子
# traceroute -I s3.us-west-002.backblazeb2.com
traceroute to s3.us-west-002.backblazeb2.com (206.190.215.254), 30 hops max, 60 byte packets
1 <ホームラボのルータ> (192.168.X.1) 0.184 ms 0.255 ms 0.252 ms
2 <家のONUルータ> (192.168.Y.1) 0.616 ms 0.667 ms 0.725 ms
3 <プロバイダーのルータ> (PPP.QQQ.RRR.SSS) 6.685 ms 6.692 ms 6.692 ms
〜略〜
16 s3.us-west-002.backblazeb2.com (206.190.215.254) 115.159 ms 115.142 ms 115.180 ms
次にPingでの確認。別に疎通確認をしているのではなく、ざっくりの帯域確認をするため。
# ping -s 1426 s3.us-west-002.backblazeb2.com -c 10
PING s3.us-west-002.backblazeb2.com (206.190.215.254) 1426(1454) bytes of data.
1434 bytes from s3.us-west-002.backblazeb2.com (206.190.215.254): icmp_seq=1 ttl=49 time=115 ms
〜略〜
1434 bytes from s3.us-west-002.backblazeb2.com (206.190.215.254): icmp_seq=10 ttl=49 time=115 ms
--- s3.us-west-002.backblazeb2.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 114.255/115.531/118.309/0.999 ms
もっと大きいパケットでテストしたかったのだが、先方のセキュリティの制限でこれが限界だった。なので、帯域はあくまでも目安
たまに大きいパケットを送信できるのだが、それによると4Mbpsしか取れない。
BBRの設定は以下のsysctlのパラメータを設定して、再起動をする。再起動をしないとBBRが有効にならない。
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
再起動後、以下を確認する
# cat /proc/sys/net/ipv4/tcp_congestion_control
bbr
systctlの設定を外すとCUBICに戻る。
テスト方法
s3testerを利用。Goが必要だが、Linux x86_64の単体バイナリも置いてあるのでそれを利用。
https://github.com/s3tester/s3tester
クレデンシャルが出ちゃうのであくまでもサンプル。事前にAWSコマンドにプロファイルを設定しておくこと。
# s3tester -bucket=＜バケット名＞ -concurrency=16 -size=16777216 -operation=put -requests=200 -prefix=testdata1 --profile=＜awsコマンドのプロファイル＞ --endpoint=＜エンドポイントURL＞ -region=＜リージョン＞
まずはCUBICでの確認
Size=1M 同時16接続で200リクエスト (PUT)
Content throughput: 7.738037 MB/s
Size=16M 同時16接続で200リクエスト (PUT)
Content throughput: 35.019121 MB/s
Size=16M 同時32接続で200リクエスト (PUT)
Content throughput: 38.083356 MB/s
次にBBRでの確認
Size=1M 同時16接続で200リクエスト (PUT)
Content throughput: 10.320328 MB/s
Size=16M 同時16接続で200リクエスト (PUT)
Content throughput: 63.878509 MB/s
Size=16M 同時32接続で200リクエスト (PUT)
Content throughput: 85.140798 MB/s
BBRの効果が結構でている。
注意点としては
- 全てのLinuxディストリビューションやカーネルバージョンでサポートされているわけではない。(Linux Kernel 4.9以降。Ubuntu 20.04やRHEL8/CentOS8では使えると思われる。CentOS7だとepelカーネルが必要）
- 言うまでもないが、ネットワーク的に近い環境の場合は、効果はほぼない。効果が出るか出ないかは、実測したほうがいい。効果が出ても薄い場合がある。なので、いきなりベンチマークを取るのではなく、Linuxのtracerouteとpingでも確認。
- これって、大丈夫なの？何か言われて説明に困るのであれば、使わない方が身のためかもしれない。これって使えますか？どこに書いてありましたと言われても。。。。