さて，NAS を含め，ファイルサーバに求められる要件はいくつかあります． ざっと代表的なものをいくつか挙げるとすると，

• 充分なディスク容量
• 安定性と耐障害性
• 高速なファイル共有

　さて，私の場合，Terminator TU (以下，TU1号機)に Linux をインストールし， TV録画サーバ機能やネットワークメディアプレイヤーのサーバ機能 etc，様々な 機能を持たせた24時間運転のサーバとして活用しているわけですが，その中でも 最も重要視しているのは，ファイルサーバとしての機能です．

　上記３つの要件に照らし合わせてみますと，まずディスク容量に関しては 750GBのディスク容量を持たせ，耐障害性に 対しては外付けディスクを使用したバックアップを 行うことによって実現（を目指）しています．

　そして３番目ですが，これま ではオンボードの 100Mbps の速度の出る NIC を使用し，Ethernet Switch を 介して各クライアント PC に接続していました．クライアントマシンが Windows の場合，samba 経由で実測でも 100Mbps を使い切る程度のスループットでファイル 共有が出来ていた他，ユーザー数も多くないため，一般的な利用であればそれ程 不満を感じることはありませんでした． しかし，大容量の動画データを扱うようになると， この 100Mbps というスピードが遅く感じられるようになり ます．また，クライアントマシン全てが 100BASE-TX で接続されていますので，サーバと 1対1の通信でもその帯域を食いつぶしてしまい，複数同時にアクセス した場合は，その限られた帯域を食い合うというネットワーク構成かつ状況でした．

　そこで 1GByte クラスのファイルを『あっと言う間に』転送するということは 無理とは思いますが，現在技術的に可能な選択肢の中で，少しでもこの状況を改善 しようと言うのが今回の試行の狙いです．

　1GbEと言っても，メディアや伝送方式の違いにより，主要なものを挙げた だけでも以下のように複数の規格が存在します．

　企業内 LAN で使用する場合は， 1000BASE-SX や 1000BASE-LX を Ethernet Switch 間で使用することが多いと思いますが，端末と Ethernet Switch 間や家庭内への導入 の場合，1000BASE-T を使うことが多いでしょう．以下，特に断りがない場合， 1GbEと記述した場合，1000BASE-T を指すことにします．

　最近は 1GbE の NIC も安くなり，最も安い物であれば 1000円 を切っています． また，M/B にオンボードで搭載されている場合もあります．一方 Switching Hub に関してもポート単価は急激に下がっており，2004年7月現在，千円弱 にまで落ちてきています．100Mbps Ethernet が急激に普及したときと同程度， もしくは，『やや高め』程度のレベルにあるように思います．2年ほど前までは高嶺の 花であったものが，今や容易に家庭内に導入可能になろうとは…良い時代になった ものです．

　さて，ネットワーク系の方はよくご存じのことと思いますが，1GbE の 通信帯域をフルに使用しようとした場合，現在の一般的な PC の場合は非常に 厳しい状況にあります．例えばごく普通の PC で使用されている PCI バスは 32bit/33MHz であり，帯域は 133[MByte/sec] でしかありません．1GbE で 1[Gbit/sec]の通信を行おうとした場合，必要な帯域は 125[MByte/sec] になり， 全二重通信（送信・受信が同時に行える）の場合はその倍の 250[MByte/sec] にも上ります．そのため，PCI バスは他のデバイス(例えばディスク等)等と 共用していることもあり，帯域の狭さが大きなボトルネックとなります．

　これを解決するために，サーバ系の M/B では，64bit PCI （64bit/66MHz． 帯域は 533[MByte/sec]）や PCI-X （最大 1066[Mbytes/sec])のスロットを 搭載するのが一般的です．また最近は， PCI Express (x16 の場合は 4[GByte/sec]*2，x1の場合は 250[MByte/sec]*2)を搭載した M/B も 出てきています．そのため， 1GbE のパフォーマンスをフルに発揮させる ためには，最低限 64bit PCI カードを使用しなければならないと言えます．

　話をに戻すと，当然ながら Terminator は 32bit PCI スロットしか装備して おらず，64bit PCI カードは利用できません．つまり，1GbE を使用したとして も，充分なパフォーマンスを発揮できないことは使用する前から明らかです． しかし，100Mbps Ethernet よりも帯域が向上することこそあれ，低下すること はまず無いでしょう．

　また，1GbE では，通信に使用可能なパケットサイズを大幅に大きくすることが 可能です．この機能はジャンボフレーム(Jumbo Frame)と呼ばれます．これまでの 通信では，通信を行うデータは 1518[byte] 毎のパケットに分割して転送される ことが一般的（明示的に MTU を変更した場合は別．また，通信経路によって適切な パケットサイズは異なります）ですが，この分割に起因するオーバーヘッドは 大容量なデータを転送しようとした場合に無視できません．そのため，分割単位 をより大きなものにしようというものがこれです．しかし，NIC，Ethernet Hub/Switch 等， 相手ホストまでの通信経路上の全ての機器類が対応していない場合，パケットが 再分割されたり，正常に通信できないなどの不具合を来たす場合があります．

　1GbE を使用し，充分にその性能を引き出すためにはジャンボフレームに対応 する機器類を使用する必要があると言われていますが，このような点を理解した 上で使用する方が良いでしょう．別の言い方をすると，Jumbo Frame を使用するか 否かは，性能を取るか互換性を取るかということに言い換えることが出来ると思います．

　なお，Reltek製のチップは古くから『高発熱』であることにかけては定評があります ので :-)，高負荷が想定される場合は何らかの冷却対策を施した方が良いでしょう． 製品によってはチップヒートシンクが取り付けられている場合がありますが，GIU2-PCI には取り 付けられていません．そこで私はメモリチップ用のヒートシンクを貼り付けることに しました．

	メモリ用ヒートシンク．２個入り．近所の電器屋で580円也
	熱伝導両面テープでそのまま貼り付ける形になります． 貼り付けるという意味では長さが長すぎますが，小型のチップヒートシンクが殆ど 店頭で売られていなかったため（高発熱のVGA用は売られていたが，固定金具が特殊 であったり，大きすぎる物が多かった），ヨシとしました．脱落が怖いため，２つの チップを冷却するような形でブリッジ状に貼り付けました．

　ちなみに私の所では，TU1号機，K7DDRに取り付けて現在運用中であり，TU2号機用に も１枚確保済みです．運用期間は一ヶ月程ですが，今のところ動作上の不具合はなく， 安定性して動作しています．

• ファンレスで騒音が発生しない
• メタル筐体で放熱，耐久性の面でメリットがある
• 発熱源となる電源を内蔵せず，ACアダプタを使用
• 8ポート全て 1GbE 対応する
• 9KbyteまでのJumbo Frame対応する
• 全ポートAuto-MDIXである

	箱は小さく，ごく普通の Hub のような感じです．大きく書かれた『Giga 1000BASE-T』 の文字が光ります．
	箱裏側の商品説明． Jumbo Frame の解説が印刷されています
	内容物一式．Switch 本体，ACアダプタ，貼り付け用のゴム足
	LAN ケーブルは正面からパッチする形．8ポート全部ギガ，全部Auto-MDIX(*)です． (*)上位ルータ/スイッチと接続する際に，ケーブルがクロスかストレートかを 意識しなくても良く，刺せば自動認識する．少し前のスイッチの場合，特定の １ポートがカスケード接続用に用意されており，スライドスイッチで ストレートかクロスかを選択する形になっているのが一般的であった．
	ステータスランプは正面左側．リンク状態や認識された通信速度，通信状態を これらLEDで確認できます．
	サイド通風用の穴． LSW-GT-8C はファンレスであり，利用時に静粛性が保たれるのですが，気になるのは その発熱．筐体が金属製のため，放熱の役に立つ＆高温になっても溶けないという点 では安心材料ではあるのですが，その分，設置場所には気を配った方が良さそうです．
	背面はACアダプタ用のコネクタのみ．
	ACアダプタ．12[V] 1.25[A]．コンセント差し込み口に箱が来るタイプで ないため，コンセント周りがスッキリします．しかしその反面，本体のコンセントから の距離に よっては，箱が中途半端な位置に来るかもしれません．
	とりあえず仮設置． 外来ノイズ混入による速度の低下を避けるため，今回 1GbE のマシンに対しては CAT6のシールド付きケーブルを使用してみました．このケーブル，当然のこととは 言え，やや固いために取り回しがしにくくなりました…（写真の向かって左側に 伸びている青い２本のケーブルがそれ）．以前は磁石で貼り付くタイプの Switch を使用しており，机裏側に貼り付けていた関係もあり，ケーブルの取り回しが スマートに行えたのですが…本体そのものは小さいんですけどね…

　なお，高負荷時にはかなり熱くなるという話も聞きますので，設置場所には注意した 方が良いでしょう．特に上に物を直接重ねて置いたり，開口部を塞いだりしないように しましょう．

　Linux 用のドライバでは， こちらのページ からダウンロード可能ですが，私が試した限りでは，kernel 2.4.26 で安定して 動作しませんでした（オプションで通信速度を 1Gbps に指定したり，大きな負荷 をかけるとハングしたりした）．kernel 2.6.x や 2.4.26 以降のバージョンからは r8169 ドライバが同梱されていますので，こちらを使用するようにしましょう．

　なお，2.4.26 で使用した場合， オプションで通信速度を指定すると不安定になりました．何らかの理由がない限り， 自動認識させる方が良いでしょう．2.4.27-rcX用のパッチを適用しても同様 でした．

['04/09/01]追記
いつの間にか Realtek製ドライバ が 2004/08/20 版としてアップデートされていました．version は 2.2.0 です． 早速試したところ，2.4.26/2.4.27 に含まれている r8169 ドライバよりも安定し ているようです．また，Jumbo Frame に対応しているほか，ハードウエアフロー 制御にも対応しています．私は現在，こちらのドライバに移行しました．

　なお，kernel 2.4.26 で make する際には，若干ソースをいじる必要があります． 改行コードが DOS (CR,LF)になっているので UNIX (LF)に直すと共に，irqreturn_t， IRQ_NONE，IRQ_HANDLED をそれぞれ irqreturn_t_R8169，IRQ_NONE_R8169， IRQ_HANDLED_R8169に置き換えて下さい(最近の 2.4.x kernel では，2.6.x と互換性 を取るために，ヘッダでこれら値を定義している．でも，型が違うのでエラーになる)．

　また，Jumbo Frame，ハードウエアフロー制御を有効にする場合は，それぞれ RTL8169_JUMBO_FRAME_SUPPORT，RTL8169_HW_FLOW_CONTROL_SUPPORT が undef され ていますので，define に置き換えて下さい．

　ちなみに RTL8169用のドライバは，RTL8110S と共用となっています．これまで オンボードの SiS900 を eth0 で使用していたけれども RTL8110S を eth0 で 使用するのであれば，/etc/modules.conf の設定を以下のように書き換える必要があります．当然ながら，Kernel設定で r8169 を利用にし，make したモジュールをインストールしておく必要があります．

　調査環境は，GIU2-PCIを内蔵した TU1号機および K7DDR を BUFFALO LSW-GT-8Cで介して CAT6 ケーブルで接続し，以下の３つの方法で 通信速度/スループットを計測しました． なお，TU1号機は Pentium3-S/1.26MHz を搭載しており，ディスクは WesternDigital WD2500JB-GV をIDE接続しています．ドライバはKernel 2.4.26 のものを使用しました． K7DDR は AthlonXP-M 2600+ を定格で使用し，ディスクは Maxtor 4R120J0 をIDE 接続しています．ドライバは CD に入っていたものを使用しました．

1. Linux (TU1号機)側で samga 2.2.9 を使用してファイル共有した際のスループットをHDBench 3.30(100MB)で計測
2. ftpを使用し，スループットを計測
3. Netperfを使用して通信速度を計測

　ちなみに Netperfのダウンロードは こちら から行えます．

　HDBenchの結果を見ると，えらく WRITE 時のスループットが低いように見えます． ちなみに Copy は 4796.67[KB/sec]でした．この値をどう解釈したら良いか微妙 ですが，Explorer でファイルを Drag&Drop した際の rrdtool+HotSaNIC のグラフ で観察すると，READ/WRITE 共に 150〜200[Mbps]は出ているようです． ベンチマークソフトの結果は，ある側面から見た場合の指標とのみ 考えた方が良いのかもしれません（自己矛盾を孕みそうですが…）．

　さて，100Mbps で接続していた際には，何れのケースでも，ほぼ帯域をフルに使い切って 利用できていたことが分かっています．これらの結果を合わせて考えますと，以下の 事柄が言えると思われます．

• 一般的な PC であっても，NIC を 100BASE-TX から 1000BASE-T のものに変更することにより，高速化を計ることが可能である
• samba 経由でファイル共有する場合，1.5倍〜2倍程度の高速化が計られる
• ディスクアクセスを伴う場合も，ftp のような軽い実装の物の場合，1.8〜2倍の高速化が計られる
• 純粋なネットワークスループットでは，4倍の高速化が計られる

['04/09/01]追記
　RealTek製の v2.2.0 ドライバは Jumbo Frame に対応しています．これを使用し，Jumbo Frame の効果を netpref 測定してみました．なお，ハードウエアフロー制御の影響を 実際に見てみた所，転送速度に殆ど影響を与えていないようでしたので，ドライバ 側でRTL8169_HW_FLOW_CONTROL_SUPPORTはundefしています．その他の条件は前述 の実験と同じです．

　ちなみに MTU を変更する際には，ifconfig eth0 mtu 5000のように ifconfig コマンドを実行します．

　K7DDR 側の Frame size を 7[KB]にすると（Winのドライバで2KB〜7KBまでの1KB 刻みで設定できます），TU側の MTU を 6000[Byte] 以上にすると逆に速度が落ちる 現象が確認できました．そこで K7DDR 側の Frame Size は 3[KB] に固定し，TU側の MTU のサイズのみ変化させて送受信の速度を確認したところ，MTU を大きくすると 転送速度も向上する傾向が見られましたが，5000 [Byte] 以上はほぼ頭打ちになり ました．また，MTU を 9000[Byte] にすると K7DDR->TU 間で通信が行えませんでした．

　その他，MTUが 7000[Byte] の場合は問題無いのですが，8000[byte]以上にすると， インターネット経由のWebアクセスが TU で出来なくなりました．なお，ネットワーク 構成は『TU->Gbit EtherSW(Jumbo Frame対応)->100Base EtherSW(JumboFrame非対応)->Router->Internet』 という構成になっています．100Base EtherSW に 100Base で直結しているBKi810と TU間は，TUの MTU が 9000[Byte] でも問題なく通信できていますので，ルータ， もしくはその上流で何らかの制限があるのかもしれません．

（一般に MTU が異なるネットワークを接続するルータでは，相手先のMTU/MSS/MRUに 合わせてパケットを分割（フラグメント化）して送信します（最近のブロードバンド ルータの多くにも，このような機能は搭載されているはずです）．ただし， 『分割不可ビット』が立っているパケットを送信/受信した場合はルータで分割できま せんので，『当該パケットが破棄される→通信が行えない』といったことが起きます． このような問題もあるため， Jumbo Frame を使用するネットワークとそうでないネットワークは物理的に分割する 方が良いと言われています．

　ただし，TCP プロトコルを用いた通信の場合，ノード間で通信セッションを確立する 前にお互いの MSS を通知し合い，小さい方の MSS で通信を開始します．そのため， Jumbo Frame 対応・非対応の機器類が混在しているネットワークでも，殆どの場合は 問題無いでしょう．しかし，UDP プロトコルのようなハンドシェイクを行わない通信 の場合は問題が出る場合があります．しかし，これらの プロトコルの場合，一般に小さなサイズのパケットを使うことが多いので，問題が 表面化することは少ないと思います）

　このような結果を踏まえ，最終的に TU は MTU 7000[Byte]，K7DDR は 3[KB] 固定で動かしています．

　改めて Jumbo Frame の効果を考察しますと，フレームサイズを大きくすることにより 転送速度が向上する傾向が見られました．しかし，環境や通信相手によっては， サイズによって転送速度が落ちたり，通信が出来なくなったりする可能性がある と言えそうです．

　実際に使用形態でのパフォーマンスを調べるために，ftp を使用して転送速度を 確認してみた所，MTU サイズを大きくしても，1500 [Byte]のときから殆ど変化が 見られませんでした．ディスクアクセスのオーバーヘッドが，全体の スループットのボトルネックになっている印象を受けます．あとは CPU 利用率も かなり高いので，CPU を高速な物にすれば改善する可能性もあります．

　また，NIC に使用されている chip によって CPU 負荷は大きく変ることは広く知られています． RTL8169/RTL8110S はどちらかと言いますと，性能よりもコストパフォーマンスを重視 した 1GbE 用チップであると言えます．そのため，性能を少しでも高めたい場合には， 多少高価にはなりますが，例えば Intel製 82540を使用した方が良いかもしれません． また，以前は『極力避けるべし』とまで言われていた VIA製チップですが，VT6122 は とても評判が良く，82540 よりも優秀なパフォーマンスを示す場合もあるようです．

　なお，Jumbo Frame を利用した場合，CPU 負荷が低減する場合もあるようです． スループットも向上しますので，利用可能な場合は積極的に利用した方が良いでしょう．

['04/09/01]追記
　新しいドライバで Jumbo Frame を使用してみたところ，割り込みが少なくなり， 若干負荷が下がっているのかもという気がします．しかし，元々 CPU 利用率が高い NIC であり，劇的にこれが改善されたという程でもありませんでした．

のように修正してあります．rrdtool が原因かと思い，最新版(1.0.48)にアップデート したり等試してみたのですが，症状は解決せず．HotSaNIC をアップデートしよう…と， 思いましたが，HotSaNIC 0.5.0 はstableではなく，また，過去のデータがある場合は 一部手動でコンバートしないといけないという話も書かれていたために中止．腰を落ち 着け，まずはデータを見てみようということで，rrdtool でデータをダンプしてみる ことにしました．

　まず，eth0 のトラフィックデータは data-traffic/rrd/eth0.rrd に格納されてい ますので，これを XML 形式でダンプします．

　以下は 100Mbps の NIC で設定した場合のダンプ結果(eth0.xml)の一部です．

　ここで注目すべきことは，In, Out 共に 100Mbps(=1.2500000000e+07 = 12500000 byte) となっていることです．eth0.xml に書き出されたデータから，100Mbps 以上のトラフィックが 発生しているであろう箇所を 確認した所，

　と，なっていました．この"NaN"がくせ者で，『設定されているMax以上の値を DBに記録しようとした→イリーガルな値であると認識され，NaNに置き換え→ データ無し扱い』と，なっていたようです．つまり，このときのデータは既に 失われているということです．

　そこで eth0.xml を編集し，

の部分を

に書き換え（In, Out の２カ所），

と，コマンドを実行し，eth0 のDBをアップデートしました．ついでにと言っては何ですが， これまで [byte/sec] で見ていたものを，より直感的に見るために [bps] で表示する よう， data-traffic/settings を下記のように編集しました．

　以下はその出力例です(かなり圧縮率を高めているため，画像が汚くなっています)． グラフはTU1号機とK7DDRとの間でファイルコピーを行ったときの様子です．

表：RRDTOOL+HotSaNICで監視した 1GbE 利用時の CPU 使用率とトラフィック

CPU使用率	トラフィック

　とは言え，従来の環境よりも高速化が図られたという意味では目的を達成し ており，おまけに今回使用したカードは 1GbE だけでなく，IEEE1394a および USB2.0 インターフェイス付きで 5,000円以下という意味では， コストパフォーマンスは絶大．価格相応以上の性能が出ているようにも 思えます．

　まとめとしては，Terminator のような PCI スロット数が少ないマシンを 利用している場合，この手のマルチインターフェイスカードの利用は非常に 魅力的な選択肢であり，1GbE も搭載したタイプも一考の価値有りといった 所でしょうか．PCI スロットが余っているのであれば，VIA製チップを使用した 単機能カードを使用した方が，さらに幸せになれるかもしれません．

　当初不安であった『安定して動くか』や『Linux で動作するか』という 点もクリアでき，かつ，体感速度が２倍程向上したため， 現在非常に満足 しています．