この記事の続きをかきました。
Amazon EC2 で何とか 約 100 Gbps 出たよ
目次
昨日しれっと NW JAWS のパブリックビューイングを見ていたら、なんと新しいインスタンスタイプで 100 Gbps の通信速度をサポートするとのこと。
対応しているインスタンスタイプ c5n で最大サイズの 18xlarge が 100 Gbps の帯域割り当てがあります。お時間当たり $4 ちょいなので、100 G NIC を買うことを考えるとはるかにお手軽に試すことができます。
で早速確認してみたらすでに使えるようになっていたので、100 Gbps にチャレンジしてみました。
25 Gbps しかでない? なんで?¶
使ったツールは iperf3。 まずは 多重度 1 で見てみました。
1 2 3 4 5 |
<span></span>$ iperf3 -c <span class="m">172</span>.16.2.xxxx ..... <span class="o">[</span> ID<span class="o">]</span> Interval Transfer Bandwidth Retr <span class="o">[</span> <span class="m">4</span><span class="o">]</span> <span class="m">0</span>.00-10.00 sec <span class="m">11</span>.0 GBytes <span class="m">9</span>.46 Gbits/sec <span class="m">2</span> sender <span class="o">[</span> <span class="m">4</span><span class="o">]</span> <span class="m">0</span>.00-10.00 sec <span class="m">11</span>.0 GBytes <span class="m">9</span>.45 Gbits/sec receiver |
多重度 1 でも 10 Gbps 近く出ています。これは期待が持てます。今どきは諸般の事情で、ソケット一つあたりだとこれぐらい出るのは大したものだと思います。
それでは早速 100 Gbps チャレンジしてみます。 1 多重で 10 Gbps ぐらい出ているので、16 多重ぐらいで 100 Gps 達成! やったね。
1 2 3 4 5 |
<span></span>$ iperf3 -c <span class="m">172</span>.16.2.xxx -P <span class="m">16</span> Connecting to host <span class="m">172</span>.16.2.xxx, port <span class="m">5201</span> ........... <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-10.00 sec <span class="m">30</span>.5 GBytes <span class="m">26</span>.2 Gbits/sec <span class="m">3681</span> sender <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-10.00 sec <span class="m">30</span>.5 GBytes <span class="m">26</span>.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 達成。こんな感じのシェルを書いて、実行してみた。
1 2 3 4 5 |
<span></span><span class="nv">PARAM</span><span class="o">=</span><span class="s2">"-O 10 -t 30 -l 16K -Z -u -b 1G -P 32"</span> iperf3 <span class="si">${</span><span class="nv">PARAM</span><span class="si">}</span> -B <span class="m">10</span>.0.1.xxx -c <span class="m">10</span>.0.1.xxx --logfile client-a.log <span class="p">&</span> iperf3 <span class="si">${</span><span class="nv">PARAM</span><span class="si">}</span> -B <span class="m">10</span>.0.2.xxx -c <span class="m">10</span>.0.2.xxx --logfile client-b.log <span class="p">&</span> iperf3 <span class="si">${</span><span class="nv">PARAM</span><span class="si">}</span> -B <span class="m">10</span>.0.3.xxx -c <span class="m">10</span>.0.3.xxx --logfile client-c.log <span class="p">&</span> iperf3 <span class="si">${</span><span class="nv">PARAM</span><span class="si">}</span> -B <span class="m">10</span>.0.4.xxx -c <span class="m">10</span>.0.4.xxx --logfile client-d.log <span class="p">&</span> |
4 つ一度に実行しないといけないので "&" をつけて平行動作するようにしてみた。多少実行時間差が出るけれどまぁ誤差の範囲で良しとした。パラメータは小一時間ほど試行錯誤した結果この辺りが一番成績が良かったというだけで特に根拠があるわけではない。
1 2 3 4 5 |
<span></span><span class="o">[</span> ID<span class="o">]</span> Interval Transfer Bandwidth Jitter Lost/Total Datagrams <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">86</span>.2 GBytes <span class="m">24</span>.7 Gbits/sec <span class="m">0</span>.015 ms <span class="m">215566</span>/-1814450 <span class="o">(</span><span class="m">0</span>%<span class="o">)</span> <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">85</span>.6 GBytes <span class="m">24</span>.5 Gbits/sec <span class="m">0</span>.015 ms <span class="m">202175</span>/-1694238 <span class="o">(</span><span class="m">0</span>%<span class="o">)</span> <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">86</span>.3 GBytes <span class="m">24</span>.7 Gbits/sec <span class="m">0</span>.015 ms <span class="m">198392</span>/-1660873 <span class="o">(</span><span class="m">0</span>%<span class="o">)</span> <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">83</span>.6 GBytes <span class="m">24</span>.0 Gbits/sec <span class="m">0</span>.018 ms <span class="m">191082</span>/-1605056 <span class="o">(</span><span class="m">0</span>%<span class="o">)</span> |
なんか値の表示が一部オーバーフローしているが良しとしよう。合計で 97.9 Gbps。なかなか良い値。
調子に乗って TCP にもトライしてみたが....¶
スピードが出ない。 1 インターフェイスあたり 15 Gbps 合計でも 60 Gbps ぐらい。
いくら何でも、遅すぎる。まぁさすがに 100 Gbps 位になるといろいろいじらないといけないだろう。
まずはメモリの割り当て¶
通信量が半端ないのでソケットのバッファ周りを増やしてみることにした。
いじったパラメータは以下の通り。
1 2 3 4 |
<span></span>net.core.rmem_max <span class="o">=</span> <span class="m">2147483647</span> net.core.wmem_max <span class="o">=</span> <span class="m">2147483647</span> net.ipv4.tcp_wmem <span class="o">=</span> <span class="m">536870911</span> <span class="m">1073741823</span> <span class="m">2147483647</span> net.ipv4.tcp_rmem <span class="o">=</span> <span class="m">536870911</span> <span class="m">1073741823</span> <span class="m">2147483647</span> |
これを適当なファイルに書いて
1 |
<span></span>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 を実行
1 |
<span></span>net.ipv4.tcp_congestion_control<span class="o">=</span>htcp |
これで一割ほど速度が改善した。
キューイングアルゴリズムも変えてみる。¶
キューイングアルゴリズムも変えてみた。これも先ほどの PDF で一押しだった。
1 |
<span></span>net.core.default_qdisc <span class="o">=</span> fq |
ただこれもそれほど効果がなかった。
で結局どれくらい出たの?¶
で今のところのベストはこれぐらい、結果行だけ掲載する。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<span></span><span class="o">[</span> ID<span class="o">]</span> Interval Transfer Bandwidth Retr <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">77</span>.0 GBytes <span class="m">22</span>.0 Gbits/sec <span class="m">245883</span> sender <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">77</span>.3 GBytes <span class="m">22</span>.1 Gbits/sec receiver <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">68</span>.1 GBytes <span class="m">19</span>.5 Gbits/sec <span class="m">138202</span> sender <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">67</span>.7 GBytes <span class="m">19</span>.4 Gbits/sec receiver <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">66</span>.6 GBytes <span class="m">19</span>.1 Gbits/sec <span class="m">109986</span> sender <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">65</span>.4 GBytes <span class="m">18</span>.7 Gbits/sec receiver <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">73</span>.2 GBytes <span class="m">20</span>.9 Gbits/sec <span class="m">178468</span> sender <span class="o">[</span>SUM<span class="o">]</span> <span class="m">0</span>.00-30.00 sec <span class="m">73</span>.4 GBytes <span class="m">21</span>.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 出たよ