ZFS send / recvに最適な圧縮

ポイントツーポイントT1回線を介して増分ZFSスナップショットを送信していますが、次のバックアップが開始される前に、1日分のスナップショットをネットワーク上で作成することはできません。send / recvコマンドは次のとおりです。

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

予備のCPUサイクルがたくさんあります。より少ないデータを回線にプッシュするために使用できる、より良い圧縮アルゴリズムまたは代替方法はありますか？

最高の圧縮メカニズムをすべて試したが、回線速度の制限を受けているようです。より高速な回線を実行することは問題ではないと仮定すると、バックアップの実行時間を増やすために、バックアップの実行頻度を減らすことを検討しましたか？

それ以外に、書き込まれるデータの量を減らす方法はありますか？アプリケーションスタックを知ることなくその方法を言うのは難しいですが、新しいファイルを作成するのではなく、アプリが既存のファイルを上書きすることを確認するなどのことを行うだけで役立ちます。また、必要のないtemp / cacheファイルのバックアップを保存しないようにしてください。

以下は、あなたがやっていることとまったく同じことをして学んだことです。mbufferを使用することをお勧めします。私の環境でテストするときは、受信側でしか役に立ちませんでした。受信側で追いつくと、送信が遅くなります。

いくつかの例：http : //everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

オプションと構文のホームページ http://www.maier-komor.de/mbuffer.html

レプリケーションスクリプトのsendコマンド：

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

これにより、リモートホスト上で受信バッファーとしてmbufferが実行され、送信が可能な限り高速に実行されます。20mbitの行を実行すると、送信側にもmbufferがあるだけで役に立ちませんでした。また、メインのzfsボックスはすべてのRAMをキャッシュとして使用しているため、1gでもmbufferを使用すると、キャッシュサイズを小さくする必要があります。

また、これは私の専門分野ではありません。sshに圧縮を行わせるのが最善だと思います。あなたの例では、bzipを使用してからデフォルトで圧縮を使用するsshを使用していると思うので、SSHは圧縮ストリームを圧縮しようとしています。CPUの負荷が最も低く、それが私にとって重要だったので、私は暗号としてarcfourを使用することになりました。別の暗号でより良い結果が得られる可能性がありますが、SSHに圧縮を行わせることをお勧めします（または、サポートしていないものを本当に使用したい場合はssh圧縮をオフにします）。

本当に興味深いのは、localhostで送受信するときにmbufferを使用すると、速度も向上することです。

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

localhost転送の4gが私にとってはスイートスポットのようです。zfsの送受信は、ストリーム内のレイテンシーやその他の一時停止が実際には最適に機能しないことを示しているだけです。

ちょうど私の経験、これが役立つことを願っています。このすべてを理解するのに時間がかかりました。

これは特定の質問に対する答えです。

rzipを試すことができますが、compress / bzip / gzipとは少し異なる方法で動作します。

rzipはファイル全体を読み取ることができるため、パイプラインで実行することはできません。これにより、ローカルストレージの要件が大幅に増加し、バックアップを実行して、1本のパイプでワイヤ経由でバックアップを送信することができなくなります。とはいえ、結果のファイルは、少なくともこのテストによると、かなり小さくなっています。

リソースの制約がパイプの場合は、とにかく24時間365日バックアップを実行するので、スナップショットを絶えずコピーして、とにかく維持することを期待する必要があります。

新しいコマンドは次のとおりです。

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

より良いエラー修正を入れたいと思うでしょうし、rsyncのようなものを使って圧縮ファイルを転送することを検討したいと思うでしょう。

この質問が投稿されてから数年で事態は変わりました：

1：ZFSは圧縮レプリケーションをサポートするようになりました。zfssendコマンドに-cフラグを追加するだけで、ディスク上で圧縮されたものがパイプを介してもう一方の端に渡されるときにブロックされます。ZFSのデフォルトの圧縮はlz4であるため、さらに多くの圧縮が得られる可能性があります

2：この場合に使用するのに最適なコンプレッサーはzstd（ZStandard）であり、現在、以下に基づいて圧縮レベル（サポートされている19以上のレベルと新しい高速zstd-fastレベル）を変更する「適応」モードzfs sendとzfs recv間のリンクの速度。データのキューを最小限に抑えてパイプから出るまで待機しながら、可能な限り圧縮します。リンクが高速であれば、データをさらに圧縮するのに時間を浪費せず、リンクが低速であれば、データをさらに圧縮するように働き続け、最終的に時間を節約します。また、スレッド圧縮もサポートしているため、pigzipのような特別なバージョン以外では、gzipとbzipがサポートしない複数のコアを利用できます。

私はあなたがあなたのサイトの生の帯域幅を単に増やすことができないと仮定しています...

ホストで圧縮を使用しないことでメリットが得られる場合があります。

wanオプティマイザーのようなものを使用する場合、送信する前にファイルを圧縮しない場合、転送を最適化できます。つまり、パイプからbzip2を削除するだけで、正確に実行します。バックアップを数回実行すると、wanオプティマイザーは転送で見られるものの非常に大きな部分をキャッシュし、転送速度が大幅に改善されます。

あなたは限られたBUDGEにしている場合、あなたは可能にrsyncを使用してrsyncingで同様の改善を見ることができるように圧縮されていない、すなわち、スナップショットを：

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

rsyncは昨日のスナップショットと今日のスナップショットの差分のみを転送するため、これは高速になります。スナップショット処理の仕組みによっては、実際にはまったく同じファイルでなくても、2つの間に多くの冗長性が存在する場合があります。

wanオプティマイザーは、この問題を解決するためのはるかに可能性の高い方法です（まあ、メトロイーサネットはこの問題を解決するための最も可能性の高い方法ですが、テーブルから除外します）。rsyncは、ファイバーまたはリバーベッドインストールの大きなチェックを書き込む前に、ローカルデータをテストする価値がある（ローカルでは、rsyncがストレートコピーでどれだけの時間を節約したかを教えてくれます）

それが価値があるもののために。私は直接送信しません| 圧縮| 解凍| これを受信すると、転送ラインがスナップし、受信中にプールが長時間オフラインになる場合、受信側で問題が発生する可能性があります。ローカルファイルに送信し、スナップショットをgzipして、rsync（川床付き）を使用して転送し、ファイルから受信します。転送に問題があり、再起動する必要がある場合、河床は交通を最適化しませんが、河床は再送信を高速化します。

増分スナップショットを圧縮せず、Rsync圧縮を使用し、河床以外の圧縮を使用しないことを検討しました。どちらが最善かを言うのは困難ですが、rsync圧縮を使用してoracleからarchivelogsを転送する場合、転送速度はプレーンファイルとリバーベッド（RSyncを使用）の約2倍です。

河床がある場合、河床はrsyncを理解し、最適化を試みてデータをキャッシュに追加するため、sshではなくrsyncを使用します（上記の転送の再起動を参照）。

私の経験ではzfs send、次の圧縮ステップよりも（平均して）はるかに高速であるにもかかわらず、かなりバースト的です。私のバックアップでは、かなりのバッファリングが後に挿入されzfs sendますgzip：

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

私の場合、出力デバイスはUSB（ネットワークではなく）に接続されていますが、バッファリングは同様の理由で重要です。全体として送信するバイト数を減らすことはできませんが（要求に応じて）、より早く終了できます。バッファリングにより、CPUにバインドされた圧縮ステップがIOにバインドされなくなります。

WAN経由で送信するときは常にpbzip2（並列bzip2）を使用します。スレッド化されているため、使用するスレッドの数を-pオプションで指定できます。最初に送信ホストと受信ホストの両方にpbzip2をインストールします。インストール手順はhttp://compression.ca/pbzip2/にあります。

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
ssh offsite-backup "pbzip2 -dc | zfs recv -F tank/vm"

主なキーは、スナップショットを頻繁に（約10分）間隔で作成し、スナップショットのサイズを小さくしてから各スナップショットを送信することです。sshは壊れたスナップショットストリームから再開しないため、送信する巨大なスナップショットがある場合、pbzip2にストリームをパイプし、管理可能なサイズのチャンクに分割し、受信ホストにファイルをrsyncし、連結されたpbzip2ファイルをzfsにパイプします。

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

これにより、500MBのチャンクで名前が付けられたファイルが生成されます。

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

受信ホストへのrsyncを複数回（zfsの送信が完了する前、または500MBのチャンクが完全に表示されたらすぐにrsyncできます）、キャンセルするにはいつでもctrl + cを押します。

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs receive：

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

ユーザーfreindが言及しました。私は直接送信しません| 圧縮| 解凍| これを受信すると、転送ラインがスナップし、受信中にプールが長時間オフラインになる場合、受信側で問題が発生する可能性があります。-進行中の送信/受信がネットワークのドロップによって中断されたが、プールがオフラインになった範囲ではない場合、受信ホストで以前のzfsバージョン<28で問題が発生しました。それは面白い。「zfs recv」が受信側で終了した場合にのみ、スナップショットを再送信します。必要に応じて、手動で「zfs recv」を強制終了します。zfs send / recvは、FreeBSDまたはLinuxで大幅に改善されました。

ssh多分blowfish-cbcの高速暗号を選択できます。また、-123456789スイッチを試してください。

-1 (or --fast) to -9 (or -best)

データでテストする必要があります。ファイルに送信して、各メソッドで圧縮するだけです。

私たちにとって、gzipは大きな違いを生み、それをすべて実行しましたが、gzipとbzipまたは7zの間には1％の違いすらありませんでした。

遅いT1を使用している場合は、ファイルに保存し、rsyncする必要があります。

lstvanが言ったように、帯域幅よりもCPUによって少し制限されている（あなたではない）人のために、arcfour128のような別の暗号が物事を高速化します。物事を移動するときに内部的に使用します。

-Dを使用してzfs sendの重複除去をオンにしてみてください。もちろん、節約量は、データにどの程度の重複があるかによって異なります。

「最適な」圧縮アルゴリズムは、持っているデータのタイプに依存します。MP3コレクションをプッシュする場合、おそらくプロセスが遅くなりますが、テキスト/ログファイルはで大幅に圧縮できますgzip -9。

毎日どれくらいのデータをプッシュしていますか？

TCPバッファーとウィンドウサイズが少し大きくなるようにTCP / IPスタックを調整することを検討しましたか？nddこれにはSolarisのsysctlツールまたはLinux / BSD / Mac OSX のツールを使用できます。Solarisでは/dev/tcp tcp_max_buf、/dev/tcp tcp_cwnd_max値と値を探しており、Linux sysctl net.ipv4.tcp_memではnet.ipv4.tcp_rmem、net.ipv4.tcp.wmem値と値を探しています。

また、これらのリンクにはいくつかの追加のヘルプがあります。

Solaris TCPパフォーマンスチューニング

そのページの下部には、Linux / BSD / OSXでも同様に行う方法を説明する一連のリンクがあります。