背景・環境
背景
Proxmox VE 上に VM を立てて使っている中で、 NAS との転送速度や待ちがネックになってきて（いると感じて）いました。
それを少しでも軽減するため、以下の対応を実施しました。
- 有線 LAN 環境の 2.5Gbps 化
- Jumbo Frame ( MTU 9000 ) 化
環境
- サーバー
- ThinkPad (各種) 3台 (※ USB 3.0 サポート）
- 2.5G Ethernet Adapter ( USB-Type A - RJ45 )
- Proxmox VE 8.2
- ネットワーク
- I-O Data ETQG-ESH08 ( 2.5Gbps対応 8ポートスイッチングハブ )
- Cat 6a ケーブル
- ストレージ
- TerraMaster F2-223 ( NAS : 2.5Gbps ポート x 2 )
自宅の環境は ノートPC を Proxmox VE で仮想化しています。
ノートPC はすべて 1Gbps ポートしかないため、 追加で 2.5Gbps Ethernet Adapter を購入しました。
USB-Type A 接続ですが、 USB 2.0 では理論値で 480Mbps までしかでないため、USB 3.0 ポート ( 理論値 5 Gbps ) を利用しています。
NAS, NW スイッチは以前購入済みのものを利用しています。
2.5Gbps 化
Proxmox VE で利用している IP アドレスを 1Gbps ポートから 2.5Gbps ポートに移動させる方式で対応しました。 NW 切断時間が発生するため、あらかじめ Proxmox VE 上で稼働する VM は 別 HW 上に Migration して実施しています。
作業ステップは以下の通りです
- VM の Migration
- 1Gbps ケーブル抜線
- 2.5Gbps アダプター・ケーブル接続
- Proxmox VE 上での 2.5Gbps 利用設定
2.5 Gbps 利用設定
Proxmox VE 上のコンソールから、 ip a コマンドを実行し、 2.5Gbps のアダプター名を確認しました。（ 今回は enxc84d4435a2a7 ）
次に /etc/network/interfaces ファイルに以下を追記しました。
iface enxc84d4435a2a7 inet manualbridge-ports enxc84d4435a2a7
auto lo
iface lo inet loopback
iface enp0s31f6 inet manual
iface enxc84d4435a2a7 inet manual ### 追記
auto vmbr0
iface vmbr0 inet static
address 192.168.x.1/24
gateway 192.168.x.254
bridge-ports enxc84d4435a2a7 ### 修正 ( enp0s31f6 -> enxc84d4435a2a7 )
bridge-stp off
bridge-fd 0
iface wlp3s0 inet manual
設定後、 再起動を実施し、疎通できることを確認しました。 （再起動ではなく、 ifreload -a でも変更できると思います。）
なお、 ethtool でインターフェースを確認してみると以下の通りとなっており、 2.5Gbps でリンクしていることが確認できました。
（下記コマンド結果 Speed: 2500Mb/s 部分 )
# ethtool enxc84d4435a2a7
Settings for enxc84d4435a2a7:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
2500baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 32
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: yes
ブリッジインターフェースも 2.5Gbps となっています。
# ethtool vmbr0
Settings for vmbr0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Unknown! (255)
Auto-negotiation: off
Port: Other
PHYAD: 0
Transceiver: internal
Link detected: yes
MTU 9000 化 ( Jumbo Frame )
NAS に対しては、比較的大容量のデータのやり取りを行うことが多いため、 同じ機会に Jumbo Frame (MTU 9000) 対応も実施しました。
Jumbo Frame 対応のためには、 NW 経路上の各機器が同じ MTU に対応している必要があります。
今回は下表のとおり、上限は異なるものの Jumbo Frame 対応しているため、全て共通で指定できる 9000 を設定します。
| 種別 | 機器 | MTU上限 | 参考情報 |
|---|---|---|---|
| NAS | Terramaster F2-223 | 9000 | FAQ |
| NWスイッチ | ETQG-ESH08 | 12288 | 仕様 |
| Ethernet Adapter | 2.5G Ethernet Adapter | 16384 | RTL8156B General Description |
| Hypervisor | Proxmox VE (v8) | 65520 | Proxmox VE - QEMU/KVM Virtual Machines |
| Linux | Fedora 40 | 65535 | ip -d link show コマンドの maxmtu |
まず、 NAS に関しては NAS の OS 上で MTU を 9000 に変更 （下図は MTU 9000 に変更後）
こちらは NAS によって手順が異なるため具体的な手順は割愛します。
（ Terramaster では、 コントロールパネル ＞ ネットワーク ＞ インターフェイス 画面から指定可能）
Proxmox VE 側設定
Proxmox VE 側では、 2.5Gbps 化と同じファイル ( /etc/network/interfaces ) で指定します。
以下の２行を追記
pre-up ip link set enxc84d4435a2a7 mtu 9000（※ 物理NIC の MTU 設定を 9000 に設定）mtu 9000（※ ブリッジ vmbr0 の MTU を 9000 に設定）
auto lo
iface lo inet loopback
iface enp0s31f6 inet manual
iface enxc84d4435a2a7 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.199.1/24
gateway 192.168.199.254
bridge-ports enxc84d4435a2a7
bridge-stp off
bridge-fd 0
pre-up ip link set enxc84d4435a2a7 mtu 9000 ## 追記
mtu 9000 ## 追記
iface wlp3s0 inet manual
設定後、再起動で反映します。（もしくは ifreload -a ）
VM 側の MTU 設定変更
当環境では、Fedora Linux が多く稼働しているため、 以下は Fedora Linux の例です。
Fedora Linux では、NetworkManager の設定変更で MTU を設定します。
まず事前確認。 ens18 の NIC の MTU が 1500 に設定されています。
[root@sumire ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether de:5c:d1:a4:31:d4 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 192.168.x.5/24 brd 192.168.x.255 scope global noprefixroute ens18
valid_lft forever preferred_lft forever
それを nmcli コマンドで修正します。
nmcli con mod <IP名> 802-3-ethernet.mtu 9000 で修正可能です。
まず、事前確認です。
# nmcli con show NAME UUID TYPE DEVICE ens18 fc89c9d6-cf53-3740-aa68-313e61d06cd1 ethernet ens18 lo 1691b843-dd55-40e7-8745-1b044215ed27 loopback lo # nmcli con show ens18 | grep mtu 802-3-ethernet.mtu: 自動 ipv6.mtu: 自動
MTU を修正します。
# nmcli con mod ens18 802-3-ethernet.mtu 9000 # nmcli con show ens18 | grep mtu 802-3-ethernet.mtu: 9000 ipv6.mtu: 自動
再起動後、 MTU が 9000 になっていることが確認できました。（ mtu 9000 部分 ）
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000
link/ether de:5c:d1:a4:31:d4 brd ff:ff:ff:ff:ff:ff
altname enp0s18
inet 192.168.x.5/24 brd 192.168.x.255 scope global noprefixroute ens18
valid_lft forever preferred_lft forever
MTU 確認
MTU の確認は、 ping を用いて実施します。
ping では、 ICMP ヘッダー ( 8 byte ) と IP ヘッダー ( 20 byte ) が付加されるため
指定サイズとしては、 8972 byte までフラグメント無しで送信可能です。
まず 8972 byte 指定で ping 実施します。
( -s がサイズ、 -M do がフラグメント禁止）
# ping -c 5 -s 8972 -M do 192.168.x.248 PING 192.168.x.248 (192.168.x.248) 8972(9000) bytes of data. 8980 bytes from 192.168.x.248: icmp_seq=1 ttl=64 time=0.832 ms 8980 bytes from 192.168.x.248: icmp_seq=2 ttl=64 time=0.956 ms 8980 bytes from 192.168.x.248: icmp_seq=3 ttl=64 time=0.843 ms 8980 bytes from 192.168.x.248: icmp_seq=4 ttl=64 time=0.973 ms 8980 bytes from 192.168.x.248: icmp_seq=5 ttl=64 time=1.09 ms --- 192.168.x.248 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4082ms rtt min/avg/max/mdev = 0.832/0.939/1.094/0.096 ms
次に、 8973 byte 指定で ping 実施したところ、 メッセージが長すぎる (MTU=9000) というエラーとなり 想定通りの動作となりました。
# ping -c 5 -s 8973 -M do 192.168.x.248 PING 192.168.x.248 (192.168.x..248) 8973(9001) bytes of data. ping: local error: message too long, mtu=9000 ping: local error: message too long, mtu=9000 ping: local error: message too long, mtu=9000 ping: local error: message too long, mtu=9000 ping: local error: message too long, mtu=9000 --- 192.168.x.248 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4106ms
終わりに
できる範囲でパフォーマンス向上を目指しましたが、やっているうちに NAS の CPU 負荷が気にになってきました。 CPU (Intel® Celeron® N4505) はそんなにすごい CPU というわけでもないようなので、新しい NAS が欲しいような欲しいような欲しいです。
