AWS で 100Gbps の帯域を使える c5n インスタンスがリリースされたので、100 Gbps 出せるか試してみた結果………

この記事は公開されてから半年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2019/1/25 追記
この記事の続きをかきました。
Amazon EC2 で何とか 約 100 Gbps 出たよ

昨日しれっと NW JAWS のパブリックビューイングを見ていたら、なんと新しいインスタンスタイプで 100 Gbps の通信速度をサポートするとのこと。
対応しているインスタンスタイプ c5n で最大サイズの 18xlarge が 100 Gbps の帯域割り当てがあります。お時間当たり $4 ちょいなので、100 G NIC を買うことを考えるとはるかにお手軽に試すことができます。
で早速確認してみたらすでに使えるようになっていたので、100 Gbps にチャレンジしてみました。

25 Gbps しかでない? なんで?

使ったツールは iperf3。 まずは 多重度 1 で見てみました。

$ iperf3 -c 172.16.2.xxxx
.....
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  11.0 GBytes  9.46 Gbits/sec    2             sender
[  4]   0.00-10.00  sec  11.0 GBytes  9.45 Gbits/sec                  receiver

多重度 1 でも 10 Gbps 近く出ています。これは期待が持てます。今どきは諸般の事情で、ソケット一つあたりだとこれぐらい出るのは大したものだと思います。
それでは早速 100 Gbps チャレンジしてみます。 1 多重で 10 Gbps ぐらい出ているので、16 多重ぐらいで 100 Gps 達成! やったね。

$ iperf3 -c 172.16.2.xxx -P 16
Connecting to host 172.16.2.xxx, port 5201
...........
[SUM]   0.00-10.00  sec  30.5 GBytes  26.2 Gbits/sec  3681             sender
[SUM]   0.00-10.00  sec  30.5 GBytes  26.2 Gbits/sec                  receiver

でない?なんで?? 俺なんかやらかしている?

実は制限があった。

AWS はパブリックサービスなのでそれぞれの利用者がリソースを過剰に使って、他の利用者の迷惑にならないように様々な制限事項があります。時々面倒くさいと思うときもありますが、保護されているという意味では必要な処置です。
そこで、こんな制限がありました。要はエンドツーエンドの通信は 25 Gbps に制限されているんですね。
水門は開いた-EC2 インスタンスのネットワーク帯域幅が増大

もう一つの落とし穴

もう一つうっかりしていた点としては AWS でのインスタンスに対する帯域の割り当てはインスタンス単位で、ENI (仮想NIC) 単位ではないのですね。なので全体として 100 Gbps というだけで、インターフェイス自体は上記の制限を受けるわけです。

でもやっぱり 100 Gbps 出したい。どうするか作戦を考えた

そこで、 1 ENI あたり 25 Gbps ならば、 ENI を 4 つつければいいのではないか?と考えた。あと Linux の制限があるので、4 つ VPC サブネットを作成して、それぞれにENI を配置する。この構成を 1 対向作ってテストしてみることにした。

その結果 ….

とりあえず UDP で 約 100 Gbps 達成。こんな感じのシェルを書いて、実行してみた。

PARAM="-O 10  -t 30 -l 16K -Z -u -b 1G -P 32"
iperf3 ${PARAM} -B 10.0.1.xxx -c 10.0.1.xxx --logfile client-a.log &
iperf3 ${PARAM} -B 10.0.2.xxx -c 10.0.2.xxx --logfile client-b.log &
iperf3 ${PARAM} -B 10.0.3.xxx -c 10.0.3.xxx --logfile client-c.log &
iperf3 ${PARAM} -B 10.0.4.xxx -c 10.0.4.xxx --logfile client-d.log &

4 つ一度に実行しないといけないので “&” をつけて平行動作するようにしてみた。多少実行時間差が出るけれどまぁ誤差の範囲で良しとした。パラメータは小一時間ほど試行錯誤した結果この辺りが一番成績が良かったというだけで特に根拠があるわけではない。

[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[SUM]   0.00-30.00  sec  86.2 GBytes  24.7 Gbits/sec  0.015 ms  215566/-1814450 (0%)
[SUM]   0.00-30.00  sec  85.6 GBytes  24.5 Gbits/sec  0.015 ms  202175/-1694238 (0%)
[SUM]   0.00-30.00  sec  86.3 GBytes  24.7 Gbits/sec  0.015 ms  198392/-1660873 (0%)
[SUM]   0.00-30.00  sec  83.6 GBytes  24.0 Gbits/sec  0.018 ms  191082/-1605056 (0%)

なんか値の表示が一部オーバーフローしているが良しとしよう。合計で 97.9 Gbps。なかなか良い値。

調子に乗って TCP にもトライしてみたが….

スピードが出ない。 1 インターフェイスあたり 15 Gbps 合計でも 60 Gbps ぐらい。
いくら何でも、遅すぎる。まぁさすがに 100 Gbps 位になるといろいろいじらないといけないだろう。

まずはメモリの割り当て

通信量が半端ないのでソケットのバッファ周りを増やしてみることにした。
いじったパラメータは以下の通り。

net.core.rmem_max = 2147483647
net.core.wmem_max = 2147483647
net.ipv4.tcp_wmem = 536870911 1073741823 2147483647
net.ipv4.tcp_rmem = 536870911 1073741823 2147483647

これを適当なファイルに書いて

sudo sysctl -p ファイル名

とかで読み込ませた。 2147483647 は設定できる最大値。
ただこれを設定しても、最初の1秒ぐらいは早くなるのだけれどすぐにあふれてしまうのかしばらくすると速度が低下してしまう。

輻輳制御アルゴリズムを変えてみる。

次に輻輳制御アルゴリズムを変えてみた。原因はわからないが、iperf3 を多重起動すると、何故か再送が増える。大きなインスタンスなので、72 コアとか謎の数の CPU コアが使えるので CPU が足りないということはないと思うけれど原因はわからない。
多分十分な速度が出ないのはこれが原因の一つ。
↓のPDFででやたら一押しだった、htcp を試してみた。
Recent Linux TCP Updates, and how to tune your 100G host
先ほどのファイルに以下の一行を書き足して再度 sudo sysctl -p を実行

net.ipv4.tcp_congestion_control=htcp

これで一割ほど速度が改善した。

キューイングアルゴリズムも変えてみる。

キューイングアルゴリズムも変えてみた。これも先ほどの PDF で一押しだった。

net.core.default_qdisc = fq

ただこれもそれほど効果がなかった。

で結局どれくらい出たの?

で今のところのベストはこれぐらい、結果行だけ掲載する。

[ ID] Interval           Transfer     Bandwidth       Retr

[SUM]   0.00-30.00  sec  77.0 GBytes  22.0 Gbits/sec  245883             sender
[SUM]   0.00-30.00  sec  77.3 GBytes  22.1 Gbits/sec                  receiver

[SUM]   0.00-30.00  sec  68.1 GBytes  19.5 Gbits/sec  138202             sender
[SUM]   0.00-30.00  sec  67.7 GBytes  19.4 Gbits/sec                  receiver

[SUM]   0.00-30.00  sec  66.6 GBytes  19.1 Gbits/sec  109986             sender
[SUM]   0.00-30.00  sec  65.4 GBytes  18.7 Gbits/sec                  receiver

[SUM]   0.00-30.00  sec  73.2 GBytes  20.9 Gbits/sec  178468             sender
[SUM]   0.00-30.00  sec  73.4 GBytes  21.0 Gbits/sec                  receiver

合計で 80 Gbps と大体ワイヤレートの8割ぐらい出ているので、TCP ということも考慮して良しとした。

でもやっぱり気になる。

TCP で 100 Gbps 達成できなかったのは残念だけれど、少なくともワイヤスピードで 100 Gbps 本当に出ることは分かった。
あとは、TCP でパケットロスが大量に発生するのは気になる。特に iperf3 を複数同時に起動した場合にパケットロスが多く発生する。これは -b オプションで帯域を制限しても発生しているので、量的な問題では無いような気がする。
どこかで資源競合でも発生しているような気がするのだが、今回の検証では予算的にも時間的な制約から見つけることはできなかった。機会があれば調べてみたい。
まぁ 100 Gbps って今まであまり経験のない世界なので、何かこれまで気づかなかった問題が出てきても不思議ではないとおもう。
まぁそのうち 25 G 制限も解除されるだろうし、 fabric という別の手段も提供される用のなので、気長に待つことにする。
C5 系列は学術計算系用なので、例えばメッシュ状のネットワークで相互にやり取りするような場合は 25 Gbps 制限があってもそんなに問題にならいないとおもう。
それではまた、お会いしましょう。

2019/1/25 追記
この記事の続きはこちらから
Amazon EC2 で何とか 約 100 Gbps 出たよ

コメントを残す

メールアドレスが公開されることはありません。

Time limit is exhausted. Please reload CAPTCHA.