私がよく遭遇する内容は次のとおりです。
- 320GBのハードドライブと16GBのRAMを備えたソースサーバーがあります(正確な仕様はこちらでご確認いただけますしかし、これは他のコンピュータでも頻繁に発生する問題なので、答えが「合理的な」Linuxコンピュータで動作することを願っています。)
- 数テラバイトのハードドライブ容量を持つバックアップサーバーがあります(正確な仕様はこちら、上記の免責事項を参照)
ソースサーバーからターゲットサーバーに320GBのデータ(特にデータ)を転送したいと思います/dev/sda
。
- 2 台のコンピュータは物理的に隣接しているため、2 台のコンピュータ間にワイヤを接続できます。
- 私はLANにいます新しいルーターを使用しています。、これは私のネットワーク速度が「理想的に」1000Mbitでなければならないことを意味します。そうですか?
- 安全は問題になりません。私はローカルネットワークにいて信頼していますみんなルータを含むネットワーク上のコンピュータ。
- (任意に選択できる)データの署名付きチェックサムは必ずしも必要ではありませんが、出力から単に消えるのではなく、基本的なエラーチェック(パケット損失や読み取り不可能なドライブなど)を検出する必要があります。
この問題についてウェブを検索し、いくつかのコマンドをテストしました。最も一般的なものは次のとおりです。
ssh [email protected] 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz
このコマンドは遅すぎることがわかりました(1時間実行され、約80 GBのデータのみがインポートされました)。 1GBのテストパケットは約1分22秒かかりました。これは圧縮されていない場合は2倍の高速です。転送されるファイルがソースシステムのRAM容量より小さいため、結果が歪む可能性があります。
また、(1 GB テスト スニペットでテスト済み)gzip
コマンドを使用すると問題が発生し、dd
ターゲットから抽出したときに結果ファイルに直接パイプする場合とは異なるチェックサムがあります。私はまだなぜこのようなことが起こるのかを理解しようとしています。
答え1
サーバーは物理的に互いに隣り合い、あなたの意見から物理的にアクセスできると述べたので、最速最初のコンピュータからハードドライブを取り外し、2台目のコンピュータに挿入してから、SATA接続を介してファイルを転送します。
答え2
netcat
セキュリティが問題にならない状況に役立ちます。
# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile
# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999
GNU coreutilsを使用している場合はプロセスにdd
送信できSIGUSR1
、進行状況はstderrに送信されます。 BSDのdd
場合SIGINFO
。
PVコピー中に進行状況を報告する方がはるかに便利です。
# on destination
nc -l 9999 | pv > /path/to/outfile
# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999
答え3
する使用早く圧縮。
- どの伝送媒体(特にネットワークまたはUSB)を使用しても、データが使用されます。脱出する読み取り、キャッシュ、書き込みに使用され、完全に同期されません。
- ディスクファームウェア、ディスクキャッシュ、カーネル/RAMキャッシュに加えて、任意の方法でシステムのCPUを使用して、ディスクごとに交換されるデータ量を集中化できます。飛び出すだからあなたはこれをしなければならない。
- すべての圧縮アルゴリズムは自動的にスパース入力の実行をできるだけ早く処理しますが、ネットワークスループットで残りを処理できるアルゴリズムはほとんどありません。
lz4
最良の選択です:LZ4は、コアあたり400MB / sの圧縮速度を提供し、マルチコアCPUに拡張できる超高速ロスレス圧縮アルゴリズムです。また、コアあたり数GB /秒の速度で非常に高速なデコーダを備えており、多くの場合、マルチコアシステムではRAM速度制限に達します。
最高のこといいえ不必要に追求します。
- これは測定が難しい場合があります。
コピーするデバイスに空き容量が多く、デバイスが最近初期化されていないが、すべてのソースファイルシステムをコピーする必要がある場合は、まず次のように時間をかけてこれを行うことをお勧めします。
</dev/zero tee >empty empty1 empty2; sync; rm empty*
しかし、ソースコードをどのレベルまで読むべきかによって異なります。多くの場合、デバイスを最初から最後まで読み取る必要があります。
/dev/
some_disk
これは、ファイルシステムレベルで読み取る操作には、通常、ディスクを非順次に前後に見ることが含まれるためです。したがって、読み取りコマンドは次のようにする必要があります。</dev/source_device lz4 | ...
ただし、ソースファイルシステム全体を転送してはいけない場合は、ファイルシステムレベルで読み込むことは避けられないため、入力を単一のストリームに集中する必要があります。
pax
この場合、一般的にこれは最良かつ簡単な解決策ですが、考慮することもできますmksquashfs
。pax -r /source/tree[12] | lz4 | ... mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
するいいえ暗号化
ssh
対。- 信頼できるメディアに暗号化オーバーヘッドを追加することは不要で、転送速度を大幅に低下させる可能性があります。続く転送中に読み取ったデータを読み取る必要があります。二重。
- これPRNGランダム性を維持するには、データまたはその少なくとも一部を読み取る必要があります。
- もちろん、データも転送する必要があります。
- また、暗号化オーバーヘッド自体を送信する必要があります。これは、送信するデータが少なく、ジョブが多いことを意味します。バーストするたびに。
だからあなたは使用する必要があります
netcat
(または私の意思通り、nmap
より強力なプロジェクト能力ncat
)単純なWebコピーの場合は、他の場所で提案されているように:### on tgt machine... nc -l 9999 > out.lz4 ### then on src machine... ... lz4 | nc tgt.local 9999
答え4
私たちはこの問題を定期的に解決します。
私たちが主に使用する2つの主な方法は次のとおりです。
- SATA/eSATA/スニーカーネットワーク
- 直接NFSマウントを実行した後、ローカル
cp
またはrsync
1つ目は、ドライブを物理的に再配置できるかどうかによって異なります。いつもそうではありません。
2番目は驚くほどうまくいきました。通常、直接NFSマウントを使用すると、最大1 Gbps接続に簡単に到達できます。 scp、dd over sshなどを使用してこれを達成する方法はありません(疑わしいほど最大速度が100mpbsに近いことが多い)。非常に高速なマルチコアプロセッサでも、2つのシステムのうち最も遅いコアの最大暗号化スループットによりボトルネックが発生する。これは、暗号化されていないネットワークインストールのプールボアcpまたはrsyncと比較して非常に遅いです。人々は落ち込んでいます。時々、iopsの壁にぶつかり、より一般的な110 MB / sの代わりに約53 MB / sで停止することがありますが、ソースやターゲットがそうでない限り、通常寿命は短くなります。実際に1つのドライブを使用すると、ドライブ自体の持続速度によって制限される可能性があります(実際に試してみるまで、何らかの理由で速度が大きく異なるかどうかはわかりません)。うーん。
NFS は、おなじみのディストリビューションにある場合は設定が少し面倒になることがありますが、通常はパイプをできるだけ埋める最速の方法です。前回10Gbps以上でこれを行ったとき、実際には最大接続に達したかどうかはまったくわかりませんでした。コーヒーを飲んで帰る前に転送が終わったからです。したがって、自然な限界に達した可能性があります。ソースと宛先の間にいくつかのネットワーク機器がある場合、ネットワークリンクの影響により若干の遅延や中断が発生する可能性がありますが、通常、これはオフィス全体(他のトラフィックを中断することなく)またはデータの一方の端で行うことができます。 (内部的に一種のフィルタリング/確認を行わない限り、この場合、すべての賭けはキャンセルされます。)。
編集する
圧縮に関する議論があることがわかりました。いいえ圧縮接続。暗号化層のように遅くなります。接続を圧縮すると、ボトルネックは常にシングルコアになります(そしてそのコアのバスを特にうまく利用することはできません)。あなたの場合、最も遅い方法は、接続速度が1 Gbps以上の隣接する2台のコンピュータ間で暗号化され圧縮されたチャネルを使用することです。
未来に直面する
この勧告は2015年半ばから有効である。これはほとんど確かに今後数年間はそうではありません。したがって、すべてを軽く考え、この作業に定期的に直面する場合は、さまざまな方法を試してください。実際の負荷ネットワークトラフィックなどの理論的に最適な、または観察された一般的な圧縮/暗号化スループットに近いものを得ると想像しないでください。たくさんテキストとは何ですか?すでに圧縮済み他の圧縮ルーチンを実行することは利点がほとんどありません...)。
私はSCTPのような概念が将来より興味深い場所に移ると想像しています。ここでは、結合接続(またはスペクトルに従って内部的に結合されたチャネル化された光ファイバ接続)が一般的であり、各チャネルは他のチャネルとは無関係にストリームを受信することができ、各チャネルはストリームを受信することができる。 。ストリームは並列に圧縮/暗号化できます。素晴らしいです!しかし、2015年にはそうではありません。ファンタジーと理論化の両方が優れていますが、私たちのほとんどはWatsonへの答えを生成するためにBlue Gene / Qの組み込みに直接データを供給する冷凍庫でカスタムストレージクラスタを実行しません。それは現実ではありません。また、圧縮が良い考えかどうかを判断するためにデータペイロードを徹底的に分析する時間もありませんでした。方法を間違って選択しても、分析を完了する前に送信自体が終了します。
しかし...
変化する時代圧縮と暗号化に関する私の提案は受け入れられません。このアドバイスが反転できることを願っています。典型的なまもなく。それは私の人生をより簡単にします。