大量のファイルを転送する最も速くて最も信頼できる方法は何ですか?


10

合計100 GBのファイルを合計90 GB転送しようとしています。現在、私はrsyncデーモンを使用していますが、3.4mb / sと遅いため、これを何度も実行する必要があります。インターネットを介して100メガビットの接続を最大化し、非常に信頼性の高いものは何でしょうか。


2
接続の3分の1近くを取得している-それは立派ですが、素晴らしいことではありません。ファイルが転送されるのは、電子が飛ぶのにどのくらいかかりますか
シェーンマッデン

2つのサーバー間の50ミリ秒のレイテンシ。
incognito2


rsyncデーモンを使用している場合、sshは必要ありません。次に、説明はおそらくホスト間のインフラストラクチャです。ホスト間の速度をテストするために、netperf、iperf、flowgrindを試すことができます。このテストはあなたに高い転送速度を与える場合は、rsyncは遅いものを作っている方法を見てみなければならない:I / Oをサーバ上で遅く、書き込み、読み出しI / Oのクライアント上で、多数の小さなファイル、ファイルシステムなど。
AndreasM

回答:


11

あなたはスニーカーネットを検討しましたか?大規模なデータセットを使用すると、インターネット経由で転送するよりも、夜間に発送する方が速くて安価になることがよくあります。


10
「高速道路を駆け巡るテープでいっぱいのステーションワゴンの帯域幅を過小評価しないでください。」- AST
voretaq7

1
まあ、ギガビットLANハードウェアの手頃な価格を考えると、LAN転送の場合、eSATA経由で単一のスピンドルに書き込むのに費やす時間はそれほど魅力的ではありません。
memnoch_proxy 2013年

10

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

私が見つけた最速の方法は、以下の組み合わせであるtarmbufferssh

例えば:

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}?bufferplus something を使用することは、それ自体を使用するよりも優れています。ほぼ文字通り、遅いネットワークファイル転送の万能薬です。

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

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


SSHをトランスポートとして使用すると、暗号化のオーバーヘッドが発生する場合があります。参照:暗号化なしの強力な認証を使用してLinuxマシン間でファイルをコピーする
ewwhite

2
必要に応じて、より高速な暗号化メカニズムを使用できます。ただし、これをssh経由でパイプする必要はありません。私は、両側のmbufferに-Oおよび-Iポートを設定することを好みます。これが2つのコマンドになったとしても、暗号化をスキップして、両端をバッファリングすることでネットワーク帯域幅を最大化します。ローカルLANで720 + Mbpsのtarストリームを送信します。これはtar -cf - .|mbuffer -m128k -s 256M -I 9090 & mbuffer -m128k -s 256M -O host:9090 | tar -xf -
memnoch_proxy

2
@memnoch_proxy:それは良い提案です(私が賛成票を投じました)が、NSAが暗号化(IMO)を使用してデータセンター(たとえば、GoogleとYahoo)の間でプライベートデータラインを盗聴している時代でも、常に良い習慣があります。を使用sshすると、それが簡単になります。またはを使用stunnelしてsocatopenssl機能しますが、単純な転送を設定するのはより複雑です。
バハマ

1
@bahamatもう一度質問を見ていただきありがとうございます。私の提案は、VPN経由で転送が行われる場合にのみ適切と思われます。インターネット転送の場合は、確かにsshも使用します。
memnoch_proxy 2013年

8

「rsync」について言及しているので、Linuxを使用していると思います。

tarまたはtar.gzファイルを作成しないのはなぜですか?1つの大きなファイルのネットワーク転送時間は、多くの小さなファイルよりも高速です。必要に応じて圧縮することもできます...

圧縮なしのタール:

ソースサーバー:

tar -cf file.tar /path/to/files/

次に、受信側で:

cd /path/to/files/
tar -xf /path/to/file.tar

圧縮されたタール:

ソースサーバー:

tar -czf file.tar.gz /path/to/files/

次に、受信側で:

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

rsyncを使用して(tar | tar.gz)ファイルを実際に転送するだけです。


アーカイブを保存するために利用可能な場所があった場合にのみ、...
Tebe

5

あなたは試みることができるtarsshトリックを説明ここに

tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

これ次のように書き換え可能である必要があります

tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"

ただし、その過程での--partial機能が失わrsyncれます。ファイルが頻繁に変更されない場合、遅いイニシャルを使用rsyncすることは、将来的にはるかに速くなるため、非常に価値があります。


2

rsyncのさまざまな圧縮オプションを使用できます。

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

バイナリファイルの圧縮率は非常に低いため、-skip-compressを使用してそれらのファイルをスキップできます(例:iso、既にアーカイブおよび圧縮されたtarballなど)。


-6

私はSFTPの大ファンです。SFTPを使用して、メインコンピューターからサーバーにメディアを転送します。私はLAN経由で良い速度を得ています。

SFTPは信頼性が高く、簡単に設定でき、場合によっては高速になる可能性があるため、試してみます。


5
FTPは死ぬ必要があります。それは暗号化されておらず、中断をうまく処理できません。完全に吸い込まない、少なくとも6通りの実行可能な代替手段があります。
MDMarra

1
SFTPをご存知ですか?
Tillman32

8
はい、ありますか?これは、名前とそれがファイルを移動するという事実を除いて、FTPプロトコルとはまったく関係がありません。
MDMarra

5
また、ファイアウォールを通過するときのFTPの信頼性は非常に低いです(クライアントがランダムなポートを開いてバック接続を受け入れるようにしたときのファイアウォールの前の日付はクールで、その制限を回避するためのパッシブおよび拡張パッシブFTPのハッカーは次のとおりです:
Hackery
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.