格安10GBASE-Tでファイルサーバと直結してみた（２）

前回の記事
[■格安10GBASE-Tでファイルサーバと直結してみた（１）](https://qiita.com/nabe2030/items/9bd6e1180beceab0f0ad "格安10GBASE-Tでファイルサーバと直結してみた（１）")
の続きになります。今回は、ジャンボフレームの導入で10Gのパフォーマンスがアップするかどうか試してみます。
##Windows7 PCのジャンボフレーム設定
Windows7 PCのデバイスマネージャーから前回導入した10G NICのプロパティを開きます。
![Win7-JumboFlame1.png](https://qiita-image-store.s3.amazonaws.com/0/276550/1702b448-662a-bcf9-9223-6f9edd9cc0f2.png)
詳細設定タグで「Jumbo Frames」を選択し、値を「9014」に設定します。
##Linuxサーバのジャンボフレーム設定
ファイルサーバのLinuxサーバ側のジャンボフレーム設定は、10G NICがeth3の場合は

```
ifconfig eth3 mtu 9014
```
で設定できます。ifconfig eth3 で確認。

```
# ifconfig eth3
eth3      Link encap:Ethernet  HWaddr **:**:**:**:**:**
          inet addr:10.10.10.86  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: ****::****:****:****:****/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9014 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3000
          RX bytes:0 (0.0 TiB)  TX bytes:0 (0.0 GiB)
          Interrupt:32 Memory:d0000000-d0010000
```
MTUが9014になっています。
先に設定したWindows7 PCにpingを打って確認します。ジャンボフレームで通信を行うにはネットワーク上の全ての通信機器が対応している必要があるので、双方が同じ値で設定できてなければ通信できません。pingが正常なら、MTUの設定を保存します。

```
# vi /etc/sysconfig/network-scripts/ifcfg-eth3
MTU=9014
```
前回と同じように、Windows7のPCからファイルサーバをマウントして、Crystal Benchmarkで比較してみました。
##Jumbo Frame有効・無効のパフォーマンス比較
|10GBASE-T Jumbo Frameあり|10GBASE-T Jumbo Frameなし|
|---|---|
|![CD-M64-U-20180829-1.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/22185f39-6d61-d0e0-a28c-d1d8244cc68c.jpeg)|![CD-M64-U-20180827-2.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/37b1b78e-da93-6dff-62fa-21db807e1520.jpeg)|
シーケンシャルリードが3倍、シーケンシャルライトが2倍以上速くなっています。これは凄い。
##eSATA接続の外付HDDとのパフォーマンス比較
今まで動画データなどの大きなデータの保存は Windows7 PC にeSATA接続で外付HDDを付けて、動画編集などを行っていました。外付HDDと10GBASE-T接続のファイルサーバとのパフォーマンス比較も行ってみました。
HDDは少し古いもので、Western DigitalのWD Green WD25EZRSです。

■ WD Green WD25EZRS
- 容量: 2.5TB
- インターフェース： SATA 3Gb/s
- 回転数: 5400rpm

|eSATA接続HDD(WD25EZRS)|10GBASE-T Jumbo Frameあり|
|---|---|
|![CD-N64-K-20180902-2.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/85b2e631-3424-8e76-fc5b-7bb3579422e4.jpeg)|![CD-M64-U-20180829-1.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/22185f39-6d61-d0e0-a28c-d1d8244cc68c.jpeg)|
ローカル接続とほとんど同じeSATA外付HDDと比べてもこれだけ速い！
##ファイルサーバ側をSSDにしたらどうなる？
これまでLinuxサーバ側でRAID-1のストレージで測定していましたが、KVM用ストレージとして240GBのSSDを搭載しているのでここにテスト用のディレクトリを作り、Windows7 PCからSAMBAマウントして、同じように Crystal Benchmark で測定してみました。RAID-1よりリード・ライト共に速くなり、10GBASE-Tの真の実力がわかるのではないか？と期待してました。SSDは Samsung SSD 840 EVO です。

|SSD + 10GBASE-T|RAID-1 + 10GBASE-T|
|---|---|
|![CD-N64-T-20180902-1.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/eb12fc0a-aac6-1b2e-ccfa-fbf56a644b09.jpeg)|![CD-M64-U-20180829-1.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/22185f39-6d61-d0e0-a28c-d1d8244cc68c.jpeg)|
意外や意外、SSDよりRAID-1の方がシーケンシャル・リード、ライトともにいい結果となっていました。

当初の目的がeSATA接続の外付HDDだと大量の動画データのバックアップ取るのが大変だったことと、同時に動画編集のパフォーマンスを確保することの２つを1万円を切った10GBASE-TのNIC 2枚で実現できました。
##（追記）再測定してみました。
シーケンシャル・ライト 600MB/s越えって、いくらなんでも速すぎると思って、Crystal Benchmarkの再測定を行いました。前回と同じ 1GiB に加えて 32GiB でも測定みてました。

|RAID-1 + 10GBASE-T(1GiB)|RAID-1 + 10GBASE-T(32GiB)|
|---|---|
|![CD-N64-U-20180902-2.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/6435d6ba-f9ad-65c5-e113-eda990b10b42.jpeg)|![CD-N64-U-20180902-1.JPG](https://qiita-image-store.s3.amazonaws.com/0/276550/f01d0ca6-f330-a390-52aa-dfd292957a1b.jpeg)|
前回の測定の時はほとんどまっさらな状態での試験で、今回は既にRAID-1領域に3TB以上のデータを書き込んだ後になります。上記は大体納得の結果で、 32GiB でこのパフォーマンスなら動画編集の素材ストレージとしては申し分ない性能と言えると思います。