ZFSがLANを介して大量のデータを送信/受信するのはなぜですか？
ちょうど先週末、メインのFreeNASマシン用に新しい（クリーンインストール）バックアップサーバーをセットアップし、それらの間で手動の完全なプールバックアップを開始しました。どちらのマシンもエンタープライズハードウェアで高速に動作し、リンクは直接10GオプティックLAN（Chelsio）です。どちらのマシンにも、Xeonv4とSupermicroベースボードを備えた高速NVMeZIL /キャッシュと128GB高速ddr4がたくさんあります。私が複製/コピーしているプールは14GBの実際のデータであり、35GBの参照データで重複排除されています（2.5倍の重複排除）。プールは、RaidZではなくストライプミラー（エンタープライズ6 + TB 7200ディスクを備えた3ウェイミラーの4セット）であるため、それらを遅くするパリティさえありません。転送用のSSH接続を除いて、サーバーまたはその接続で実行されているものは他にありません。 _zfs send_コマンドには、重複排除されたデータを送信するために必要な引数が含まれています（ただし、監視によるものであり、圧縮されていません）。
送信者へのコマンド：
_zfs send -vvDRLe mypool@latest_snapshot | nc -N BACKUP_IP BACKUP_PORT
_受信者へのコマンド：
_nc -l PORT | zfs receive -vvFsd my_pool
_14TBを送信して終了するか、35TBを送信するが、すでに送信されている21TB（重複データ）は非常に高速で、14ビットとわずかTB）のいずれかが発生することを期待していました。 =送信する必要がありますが、代わりに35TBをすべて送信することを意図しているようで、その時点で非常にゆっくりです-何か間違ったことをしたか、誤解しましたか？
私が得られないのは、スナップショット/データセットをシリアル化しても、バックアップサーバーのディスクはgstatによるとほぼ100％で実行されており、4日間稼働しているということです。データは正しく到着しています（完了したスナップ/データセットをマウントできます）。ただし、プール全体を送信するには、オールインで約7日かかり、常にほぼ100％のディスクアクティビティが発生するようです。
2台の高速サーバー間の10Gリンクで14TBまたは35TBを転送する-コンソールに表示されるステータス情報が何であれ-信じられないほどでない限り、それほど長くはかからないはずです。 ）非効率的で、ありそうもないようです。
どちらのシステムも、HDDスピナーでも約500 MB/sで読み取り/書き込みが可能であり、ZFSはディスクアクセスを最適化し、データはすでに重複排除されて送信されるため、データを再重複排除する必要はありません。
なんでこんなに時間がかかるの？プール内の生のブロックを1回だけ送信しないのはなぜですか？
コメントからいくつかのポイントに返信：
- netcat（nc）:
netcat (nc)は、2つのシステム間でデータをパイプするための裸の透過的な暗号化されていないtcpトランスポート/トンネルを提供します（他の用途の中でも）-ssh/VPNに少し似ていますが、速度低下やベア以外の再パッケージ化TCPネットワーク上のハンドシェイク。_zfs send_/_zfs receive_に関する限り、それらは直接通信しており、わずかな遅延を超えてnetcatlinkは、送信/受信が処理できる最大速度で実行する必要があります。 - ミラーディスク速度：ミラーはディスクの中で最も遅い速度で書き込みますが、ZFSはディスクをストライプミラーとして扱います。 ）（両方のシステムの4つのvdevにまたがるデータストライプ。各vdevはミラーです）。ソースプールが55％いっぱいで、destプールが空で、CPUが追いつくことができると仮定すると、zfsは12個のディスクから同時に読み取り、4個のディスクに書き込むことができ、書き込みはほぼすべてシーケンシャルである必要があります。その他IOアクティビティ。ミラー内で最も遅いディスクは> = 125MB/sで書き込みを実行できると思います。これは、最新のエンタープライズ7200 HDDの速度をはるかに下回っており、バックアップは次のようになります。ランダムIOではなく順次入力されます。ここで、>> 500MB/sの持続的なレプリケーションレートが得られます。
- 重複排除テーブル/ RAMの妥当性：重複排除テーブルはRAM（エントリあたりのバイト数x
zdbあたりのソースプールの合計ブロック数）で約40GBです。 L2ARCを使用する前に（send/rcvで使用する場合）、両方のシステムでsysctlを設定して、重複排除テーブルおよびその他のメタデータ用に85GBのRAM、したがってキャッシュデータ用に約35GB）を予約しました。 ）。したがって、どちらのマシンでも、重複排除とメタデータをRAMから削除しないでください。
速度と進捗状況の更新：
- 5日間の実行後、進行状況の統計が更新されました。平均で約58MB /秒でデータを送信しています。完全に悲惨なわけではありませんが、それでも、それは上記の質問を支えています。ディスクセットは一度に最大12台のHDD（約2GB /秒）で読み取り、一度に最大4台のディスク（約500GB /秒）に書き込むことができるため、約10倍の速度が期待できます。データを重複排除または再重複排除する必要はありません（AFAIK）。3.5GHz4+8コアのXeonv4で実行され、両方のシステムで大量のRAM、および1GB /秒を実行します。
圧縮についておっしゃったことから、説明したすべてのストレージサイズ/速度は非圧縮サイズであると想定しています。そうでない場合は、could転送時間を平均圧縮率に等しい係数で長くします（ただし、ディスクアクセスがボトルネックの場合は、zfs sendでディスクから読み取った後、書き込む前に解凍/圧縮が行われるため、そうではありません） zfs receiveのディスクに）。
これまでに収集した情報に基づくと、ネットワーク接続ではなく、ディスク帯域幅でボトルネックになっているようです。各システムは最大500MB /秒で読み取り/書き込みが可能であるため、35TBの最適な転送時間は約20時間です（10Gb /秒ネットワークを介した転送よりも約2.5倍遅い）。しかし、ミラーリングの設定に基づいて、読み取りと書き込みで同じスループットが得られることに驚いています。それについてはよろしいですか？送信システムでは、1つのディスクから読み取るだけで済みます（3つのディスク間で読み取りを並列化できます）が、受信システムでは、3つのディスクすべてに書き込む必要があります（したがって、最も遅いディスクのスループットに制限されます。いつでも）。受信側で書き込みスループットをテストするには、dd if=/dev/urandom of=some_file_in_pool bs=1M count=1024 conv=fdatasyncを実行できます。
受信ディスクが100％ビジーであるとおっしゃっていたので、500MB /秒の書き込み帯域幅に達していないのではないかと思います。これは、実際の書き込み制限がそれよりも低いためである可能性があります（上記のddコマンドで確認する必要があります）、またはシステムが受信中にメタデータの読み取りを行う必要があり、それがあなたのニースを壊している可能性があります-ディスクシークの束をミックスに追加することによるIOサイズの書き込みワークロード。 DTraceを使用して、2番目の仮説をより深く調査し、ioプロバイダーが読み取り/書き込みサイズをどのように考えているかを確認できるはずです。