NFSで問題が発生しているので、単純に古いTCPを使用してみたい

しかし、どこから始めればいいのかわかりません。

ハードウェアに関しては、イーサネットクロスオーバーケーブルを使用して2つのネットブックをネットワークに接続しています。

それらをネットワーク化するために、私はタイプします

$ sudo ifconfig eth0 192.168.1.1 up && ping -c 10 -s 10 192.168.1.2 && sudo /etc/init.d/nfs-kernel-server start

最初のネットブックで

$ sudo ifconfig eth0 192.168.1.2 up
$ ping -c 10 -s 10 192.168.1.1
$ mount /mnt/network1

第二に

どこ/mnt/network1ように/ etc / fstabに指定されています

192.168.1.1:/home /mnt/network1 nfs noauto,user,exec,soft,nfsvers=2 0 0

同様に/etc/exports（そのファイルの構文を使用して）、最初のネットブックで。

上記は正常に機能しますが、ファイルとディレクトリは巨大です。ファイルは平均して1ピースあたり約半分のギガバイトで、ディレクトリはすべて15〜50ギガバイトです。

私はrsyncそれらを転送するために使用していますが、コマンド（上192.168.1.2）は

$ rsync -avxS /mnt/network1 ~/somedir

NFS設定を微調整して巨大なファイルをより適切に処理する方法があるかどうかはわかりませんが、NFS rsyncよりも単純な古いTCPでデーモンを実行する方がうまく機能するかどうかを確認したいと思いrsyncます。

繰り返しになりますが、TCPで同様のネットワークを設定するにはどうすればよいですか？

更新：

だから、数時間で自分の無知の泥沼から抜け出そうと試みた（または、私が考えているように、自分のブートストラップで自分を引き上げようと試みた）後、いくつかの有用な事実を思いつきました。

しかし、まず第一に、単に現在のベストアンサーを受け入れるのではなく、このウサギトレイルで私を導いたのncは、次のとおりでした。netcat-openbsdとnetcat-traditionalパッケージを試してみましたが、まったく運がありません。

受信側のマシン（192.168.1.2）で表示されるエラーは次のとおりです。

me@netbook:~$ nc -q 1 -l -p 32934 | tar xv
Can't grab 0.0.0.0:32934 with bind
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

route 与える：

me@netbook:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         dir-615         0.0.0.0         UG    0      0        0 wlan0
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.0.0     *               255.255.255.0   U     2      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

しかし、ここで良いニュースがあります。静的IPアドレスをに設定し/etc/network/interfacesておくと、nc作業を始めながら作業を開始し、NFSの問題をすべて修正し、NFSに対する愛を再燃させました。

私が使用した正確な構成（192.168.1.1もちろん、最初のネットブック用）は次のとおりです。

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

これらの設定により、2つのネットブックは起動せずに直接pingを実行できますifup。

とにかく、私はまだ実際ncに動作を見たいので、誰かがこのプロセスのデバッグを手伝ってくれることを望んでいます。

簡単な方法

最速のいくつかの変更がない限り、LAN経由でファイルを転送する方法は、rsyncの可能性ではありません。rsyncは、チェックサムの実行、差分の計算などにかなりの時間を費やします。とにかくほとんどのデータを転送することがわかっている場合は、次のようにします（注：netcatのマニュアルは複数あります。正しいオプション。特に、あなたのものは望まないかもしれません-p）：

user@dest:/target$ nc -q 1 -l -p 1234 | tar xv

user@source:/source$ tar cv . | nc -q 1 dest-ip 1234

これはnetcat（nc）を使用して、ポート1234のraw TCP接続でtarを送信します。暗号化、信頼性チェックなどがないため、非常に高速です。クロスコネクトがギガビット以下で実行されている場合、ネットワークを固定します。それ以上であれば、ディスクをペグします（ストレージアレイまたは高速ディスクがない場合）。vtar のフラグにより​​、ファイル名がそのまま出力されます（詳細モード）。大きなファイルの場合、オーバーヘッドはほとんどありません。大量の小さなファイルを実行している場合は、それをオフにします。また、次のようなものpvをパイプラインに挿入して、進行状況インジケーターを取得できます。

user@dest:/target$ nc -q 1 -l -p 1234 | pv -pterb -s 100G | tar xv

もちろん、他のものも挿入できますgzip -1（z受信側にフラグを追加zします。送信側のフラグは、もちろんGZIP環境変数を設定しない限り、1より高い圧縮レベルを使用します）。データが実際に圧縮されない限り、gzipはおそらく実際には低速になりますが。

本当にrsyncが必要な場合

実際に変更されたデータのほんの一部を転送するだけであれば、rsyncの方が高速になる可能性があります。また、より高速なネットワーク（クロスコネクトなど）のように、-W/ --whole-fileオプションを確認することもできます。

rsyncを実行する最も簡単な方法は、sshを使用することです。チップにIntelのAESが搭載されているかどうかに応じて、AES、ChaCha20、またはBlowfish（Blowfishの64ビットブロックサイズにはセキュリティ上の懸念がありますが） -NI命令（およびOpenSSLがそれらを使用します）。十分に新しいsshでは、rsync-over-sshは次のようになります。

user@source:~$ rsync -e 'ssh -c aes128-gcm@openssh.com' -avP /source/ user@dest-ip:/target

古いssh / sshdの場合は、aes128-ctrまたはのaes128-cbc代わりに試してくださいaes128-gcm@openssh.com。

ChaCha20はchacha20-poly1305@openssh.com（新しいssh / sshdも必要です）、Blowfishはblowfish-cbcになります。OpenSSHでは、暗号なしで実行することはできません。もちろん、の代わりに好きなrsyncオプションを使用できます-avP。そしてもちろん、別の方向に進み、ソースマシン（プッシュ）の代わりにデスティネーションマシン（プル）からrsyncを実行できます。

rsyncを高速化する

rsyncデーモンを実行すると、暗号化のオーバーヘッドを取り除くことができます。最初に、/etc/rsyncd.confたとえばソースマシン上にデーモン構成ファイル（）を作成します（詳細については、rsyncd.confのマンページを参照してください）。

[big-archive]
    path = /source
    read only = yes
    uid = someuser
    gid = somegroup

次に、宛先マシンで、次を実行します。

user@dest:~$ rsync -avP source-ip::big-archive/ /target

これは他の方法でも実行できます（ただし、もちろん読み取り専用をnoに設定する必要があります）。認証などのオプションがあります。詳細についてはマンページを確認してください。

どうやって？またはTL; DR

私が見つけた最速の方法は、以下の組み合わせであるtar、mbufferとssh。

例えば：

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

これを使用して、1 Gbリンクで950 Mb / sを超えるローカルネットワークの持続的な転送を実現しました。転送する内容に合わせて、各tarコマンドのパスを置き換えます。

どうして？mbuffer！

ネットワーク経由で大きなファイルを転送する際の最大のボトルネックは、ディスクI / Oです。それに対する答えはmbufferまたはbufferです。これらはほとんど似ていmbufferますが、いくつかの利点があります。デフォルトのバッファサイズは、2MBでmbuffer1MBですbuffer。大きなバッファは空になることはほとんどありません。ターゲットと宛先の両方のファイルシステムでネイティブブロックサイズの最小公倍数であるブロックサイズを選択すると、最高のパフォーマンスが得られます。

バッファリングはすべての違いを生むものです！お持ちの場合は使用してください！お持ちでない場合は入手してください！(m}?bufferプラス記号を使用することは、それ自体が何よりも優れています。これは、文字通り、遅いネットワークファイル転送の万能薬です。

複数のファイルを転送する場合はtar、それらを「まとめて」単一のデータストリームにまとめます。使用できる単一ファイルの場合、catまたはI / Oリダイレクト。tarvs. のオーバーヘッドcatは統計的に取るに足らないものなので、すでにtarballでない限り、常にtar（またはzfs -send可能な場合は）使用します。どちらもメタデータを提供することを保証しません（特に提供しません）。メタデータが必要な場合は、演習として残しておきます。cat

最後に、sshトランスポートメカニズムの使用は安全であり、オーバーヘッドはほとんどありません。繰り返しますが、sshvs nc。のオーバーヘッドは統計的には重要ではありません。

TCPを使用する必要さえありません。AoEはイーサネット経由のATA実装であり、レイヤー2であるため、TCP / IPスタックに関する知識のないオーバーヘッドの少ないアプローチです。最小限のオーバーヘッドで可能な限り高速の転送を提供します。***

https://en.wikipedia.org/wiki/ATA_over_Ethernet

***ネットワークがボトルネックの場合は、圧縮データを送信していることを確認してください。