多くの場合、一連のサーバーファイルをミラーリングしていることに気づき、これらのサーバーファイルに含まれるのは数千 1kb〜3kbの小さなファイルです。すべてのサーバーは1Gbpsポートに接続され、一般にさまざまなデータセンターに分散しています。
SCPはこれらの小さなファイルを1つずつ転送します。これには長い年月がかかり、私が持っている美しいネットワークリソースを浪費しているように感じます。
私にはアイデアがありました。ファイルを等量に分割し、5〜6 scpのスレッドを起動するスクリプトを作成すると、理論的には5〜6倍速く実行されます。しかし、私はLinuxスクリプトの経験はありません!
私はこのようにします:tar -cf - /manyfiles | ssh dest.server 'tar -xf - -C /manyfiles'
転送するファイルによっては、tar
コマンドで圧縮を有効にすることが理にかなっています。tar -czf - /manyfiles | ssh dest.server 'tar -xzf - -C /manyfiles'
ssh
コマンド(arcfourなど)にCPUにやさしい暗号を選択することも意味があります:tar -cf - /manyfiles | ssh -c arcfour dest.server 'tar -xf - -C /manyfiles'
または両方を組み合わせることができますが、それは実際にはボトルネックが何であるかに依存します。
明らかにインクリメンタル同期を行っている場合、rsync
の方がはるかに高速になります。
rsync
の代わりにscp
を使用してください。 rsync
ではなくssh
をscp
と同じくらい簡単に使用でき、「レイテンシコストを最小限に抑えるためのファイル転送のパイプライン処理」をサポートしています。
ヒント:データが圧縮可能な場合は、圧縮を有効にします。そうでない場合は、無効にしてください。
直接のscpではなく、マルチスレッド転送のオプション(単一ファイルであっても)はbbcpです- https://www2.cisl.ucar.edu/resources/storage-and-file-systems/bbcp 。
データを転送するスレッドの数に-sオプションを使用します。ラグによってTCPスレッドあたりのウィンドウサイズが制限されるため、高帯域幅で遅延のある接続に最適です。
おそらく無関係ですが、何かもっとリアルタイムが必要な場合は、 GlusterFS を試してみてください。うまく機能しますが、小さなファイルを効率的に読みたい場合は、調整が必要です。