クイックメソッド

クイックメソッド

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(このファイルの構文を使用して)最初のネットブックから。

上記の方法はうまくいきますが、ファイルとディレクトリが大きいです。各ファイルの平均サイズは約0.5GB、ディレクトリサイズはすべて15〜50GBです。

rsync送信に使用するコマンドは次のとおり192.168.1.2です。

$ rsync -avxS /mnt/network1 ~/somedir

大容量ファイルをよりよく処理するためにNFS設定を調整する方法があるかどうかはわかりませんが、通常のrsync既存のTCPを介してデーモンを実行する方がrsyncNFSより優れていることを確認したかったです。

では、言い換えれば、TCPを使用して同様のネットワークをどのように構築しますか?

修正する:

それで、無知の泥沼から自分自身を引き出そうと数時間努力した最後に(または私が思うように最善を尽くして努力した最後に)いくつかの有用な事実を思い出しました。

しかし、まず、単に現在の最善の答えを受け入れるのではなく、私をこのウサギの道に導いたのはこれでした。これはnc信じられないほど素晴らしいプログラムですが、確かに私には適していません。私は試して梱包netcat-openbsdnetcat-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

しかし、良いニュースは次のとおりです。 .netで静的IPアドレスを設定すると/etc/network/interfacesnc起動しようとしたときに開始)、すべてのNFSの問題が解決され、NFSへの愛が再発しました。

私が使用した正確な設定(192.168.1.1もちろん最初のネットブック)は次のとおりです。

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0

これらの設定を使用すると、両方のネットブックは起動後に直接pingを実行することなく互いにpingを送信できますifup

それにもかかわらず、私はこれが実際に動作しているのを見たいncので、誰かがこのプロセスをデバッグするのを手伝ってくれることを願っています。

ベストアンサー1

クイックメソッド

これ最速マイナーな変更がない限り、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の生のTCP接続を介してtarを送信します。暗号化、真偽確認などがないので、非常に高速です。クロス接続がギガビット以下で実行されるとネットワークに接続し、それ以上の場合はディスクに接続します(ストレージアレイや高速ディスクがない場合)。v実行時にファイル名を印刷するtarにフラグを付けます(詳細モード)。大容量ファイルの場合、オーバーヘッドはほとんどありません。小さなファイルがたくさんある場合は、この機能をオフにできます。あるいは、pvパイプラインに次の項目を挿入して進行状況インジケータを取得することもできます。

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

もちろん、他の項目も挿入できます(そしてgzip -1受信側にフラグを追加します。もちろん、GZIP環境変数を設定しない限り、送信側のフラグは1より高い圧縮レベルを使用します)。データがないとgzipが実際に遅くなることがありますが、zz本物圧縮。

本当にrsyncが必要な場合

変更されたデータの一部のみを転送する場合は、rsync が高速になる可能性があります。非常に高速なネットワーク(クロスコネクトなど)がはるかに高速になる可能性があるため、-W/オプションを確認することをお勧めします。--whole-file

rsyncを実行する最も簡単な方法はsshを使用することです。どちらが最速であるかを確認するには、SSH暗号化を試みる必要があります。チップにIntel AES-NIがあるかどうかに応じて、AES、ChaCha20、またはBlowfish(Blowfishの64ビットブロックサイズにいくつかのセキュリティ上の問題がある)があります。指示(そしてOpenSSLはそれを使用します)。新しいSSHでは、rsync-over-sshは次のようになります。

user@source:~$ rsync -e 'ssh -c [email protected]' -avP /source/ user@dest-ip:/target

以前のssh / sshdの場合は、代わりにまたはaes128-ctrを使用してみてください。aes128-cbc[email protected]

ChaCha20は[email protected](十分な新しい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

これを反対方向に実行することもできます(もちろん読み取り専用をいいえに設定する必要があります)。認証などのオプションがあります。詳しくはマンページをご覧ください。

おすすめ記事