写真：PC Watch

　今回は、あまりあって欲しくなった【第31回】中年Ubuntu野郎はファンレスPCの夢を見ないの続編である。 【画像】Clonezillaの多彩なリモートリソース(バックアップ先) 　ここで組み立てたPCはNASとして使用している。通常3.5インチHDDは1台しか入らないが、N100DC-ITXのように電源ユニットが不要なマザーボードであれば、HDDブラケットが2つ取り付けられることが分かった。HDDブラケットだけ入手するのは現実的ではないと考えたので、ケースをもう1つ購入した。 　PCIeスロットにはGBE2.5-PCIEを接続し、2系統ある宅内LANの両方に接続している。 　話は変わるが、SSD換装+OS丸ごとデータ移行を無料ソフト「Clonezilla」でやろうで紹介されているClonezillaは筆者も愛用している。主に検証用PCで使用しているSSDをバックアップしている。バックアップ先の選択肢がかなり多いので助かっている。すでにお気づきかもしれないが、バックアップ置き場は上記のNASにしている。ファイルサーバーとしては第27回で紹介した定番中の定番、Sambaを使用している。 　検証用PCのSSDなのでさほど使用量が大きいわけではないが、それでも2桁から3桁GBの転送量となり、それなりに時間がかかる。 　ここでまた話は変わるが、以前より10Gigabit Ethernet(GbE)関連機器を少しずつ買い集めていた。きっかけになったのは僚紙Internet Watchに掲載された「2.5GbpsにSFP+、PoEも付いて脅威の実売6,980円！ 話題の爆安スイッチに落とし穴はないか、実際に買って試してみた」であった。SFP+ポートが2つついたスイッチングハブがこんな値段で買えるのであれば、一式揃えてもそれほど大した金額にならないのではないか、と考えたのだ。実際には結構かかったが、考えないものとする。 　いろいろテストはしていて、充分に速いことは分かっていたが、実環境で使用することはあまり考えていなかった。しかしNASを10GbEにして、バックアップにかかる時間が短縮されたとすれば大きなメリットとなる。 　というわけで、今回はNASと検証用PCを10GbEで接続する話だが、タイトルから推測できるように思ったようにはいかなかった。 ■ ハードウェア構成 　NASのハードウェア構成は次の通りだ。ネットワーク機器は除く。 　SSDはUbuntuブート用、8TB HDDはデータ置き場で16TB HDDはバックアップ用という構成だ。 　検証用PCのハードウェア構成は次の通りだ。 　ビデオカードがパワーアップしたので600Wの電源ユニットでは心許ない感があるが、本題とは関係ないのでよしとする。 　Ubuntuのバージョンはあまり関係ないが、NASはUbuntu Server 22.04 LTS、検証用PCはUbuntu 24.04 LTSだ。 ■ ネットワーク機器 　ネットワーク機器はすべてAmazonで購入したものだ。価格を重視して怪しいものばかりだが、すべて意図した通りに動作しているので助かった。 □NIC 　当初は「Intel 82599EN」搭載のネットワークカードを2枚購入した。 　PCIe 2.0 x8スロットだと接続できるPCが制限されるため、PCIe 3.0 x4接続のAQC113Cを搭載したネットワークカードも追加で購入した。 □SFP+モジュール 　SFP+モジュールとしては2本で3,699円のTwinaxケーブルを購入した。値段重視だ。 　AQC113C搭載NICは普通のLANケーブルを使用するため、手持ちのケーブルを使用している。スイッチングハブに取り付けるためのSFP+モジュールとして10GBASE-Tに変換するSFP+モジュールも購入している。発熱がものすごいが、今のところはこれといったトラブルには遭遇していない。 □スイッチングハブ 　スイッチングハブは、BinardatブランドでSFP+ポートが2つ、2.5GbEポート4つで6,999円のもの。ハードウェアレベルでVLAN機能があって興味深いが、使用していない。よって10GbEネットワークは2.5GbEネットワークに乗っている。 ■ N100DC-ITXの制限 　N100DC-ITXにはPCIe 3.0 x4スロットがあるが、x2という速度制限がある。実際にdmesgコマンドで確認すると、 0000:03:00.0: 15.752 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x2 link at 0000:00:1d.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) 　というログがあった。これがボトルネックになるかどうかは注目すべき点の1つだ。 ■ iperf3 　まずは定番のiperf3の結果を見ていこう。 Accepted connection from 192.168.13.103, port 37884 [5] local 192.168.13.10 port 5201 connected to 192.168.13.103 port 37898 [ ID] IntervalTransferBitrate [5]0.00-1.00sec1.05 GBytes9.01 Gbits/sec [5]1.00-2.00sec1.10 GBytes9.41 Gbits/sec [5]2.00-3.00sec1.10 GBytes9.41 Gbits/sec [5]3.00-4.00sec1.10 GBytes9.41 Gbits/sec [5]4.00-5.00sec1.09 GBytes9.40 Gbits/sec [5]5.00-6.00sec1.10 GBytes9.41 Gbits/sec [5]6.00-7.00sec1.09 GBytes9.37 Gbits/sec [5]7.00-8.00sec1.09 GBytes9.41 Gbits/sec [5]8.00-9.00sec1.10 GBytes9.41 Gbits/sec [5]9.00-10.00sec1.10 GBytes9.41 Gbits/sec [5]10.00-10.04sec43.5 MBytes9.40 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] IntervalTransferBitrate [5]0.00-10.04sec10.9 GBytes9.37 Gbits/secreceiver 　クライアントが検証用PC、サーバーがNASで、こちらはサーバー側の結果である。おおむねスペック通りの速度が出ており、PCIeスロットの速度制限は問題になっていないことが分かる。ホッとした瞬間だ。 ■ Samba 　iperf3は極めて理想的な場合のベンチマークで、実環境とは異なる。実際にどのぐらいの速度が出るのかはやってみないと分からない。 　というわけで、次はSambaのベンチマークを実行する。SambaサーバーはNASですでに動作しているので、クライアントでの準備を進める。 　まずは次のコマンドで10GBのファイルを作成する。 $ fallocate -l 10G 10Gdummiyfile 　実際にこのファイルをコピーして速度を計測する。 　Sambaクライアントは、smbclientというパッケージに含まれるsmbclientコマンドを使用する。というわけでsmbclientパッケージをインストールしよう。 　smbclientコマンドでSambaサーバーに接続するには、次のコマンドを実行する。 $ smbclient //192.168.13.10/public/ 　今回はユーザー名とパスワードが不要な共有フォルダを使用しているが、ユーザー名とパスワードが必要な場合は次のようなコマンドを実行する。 $ smbclient //192.168.13.10/public/ -U username%password 　というちょっと変わったオプションをつける。要するにユーザー名とパスワードを”%”でつなげるのだ。 　ローカルのカレントフォルダーは接続時のフォルダーとなり、サーバーのカレントフォルダーは起動オプションのところとなる。 　ローカルのカレントフォルダーはこのままでいいが、サーバーのカレントフォルダーを“tmp”に変更した上で先ほど作成した10GBのファイルをコピーする。具体的には次のようなコマンドを実行する。 Password for [WORKGROUP\ikuya]: Anonymous login successful Try "help" to get a list of possible commands. smb: \＞ cd tmp smb: \＞ put 10Gdummiyfile 　ファイルの転送後、速度が表示される。今回は次のようになった。 putting file 10Gdummiyfile as \10Gdummiyfile (266887.9 kb/s) (average 266887.9 kb/s) smb: \＞ 　266887.9KB/sをGbpsに変換すると2.1351032とのことだ。2.5GbEであれば納得の速度だが、10GbEの速度は全く出ていないことが分かった。 　この原因をいろいろと推測してみたが、正直お手上げであった。買い物からの帰り道にも考えていると、N100のCPU性能が足りていないのでは？とふと思った。PCの前から離れて考えることは重要だ。 　実際にファイル転送中のCPU負荷状況を見てみると、Sambaを構成する1つであるsmbdプロセスが数秒間に渡ってコア1つをほぼ使い切っていた。 　さらに高速なCPUであればこのようなことは起こらないはずだ。というわけでRyzen 5 5600Gを搭載したDeskMeet X300にSFP+モジュールが刺さる方の10GbE NICを接続し、計測してみるとこのようになった。 smb: \＞ put 10Gdummiyfile putting file 10Gdummiyfile as \10Gdummiyfile (975328.8 kb/s) (average 1028419.0 kb/s) 　975328.8KB/sとのことで、これをGbpsに変換すると7.8026304であった。7.8Gbpsは、iperf3の結果とSMBプロトコルのオーバーヘッドを考えると妥当な速度と思われる。 ■ 結論 　現在使用しているNASのNICを10GbEのものに交換しても、少なくともSambaではN100のCPU性能がボトルネックになり速度が出ないことが分かった。これを解消するにはマザーボードを交換するしかないが、前述の通り電源ユニットが必要なマザーボードであれば搭載できる3.5インチHDDが1台だけになり、ケースの交換も必要となって、全く受け入れられない。また消費電力の増加も看過できない。 　現状、ほかのプロトコルで実験するような余裕はなく、またほかに10GbEを生かす方法も思いつかないので、当面10GbEは夢のままにしておくこととする。