ZFS 전송 / 복원을위한 최상의 압축

지점 간 T1 회선을 통해 증분 ZFS 스냅 샷을 전송하고 있으며 다음 백업이 시작되기 전에 하루 동안의 스냅 샷이 유선으로 거의 생성되지 않는 지점에 도달했습니다. 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주기가 있습니다. 더 적은 수의 압축 알고리즘 또는 대체 방법을 사용하여 줄에 더 적은 데이터를 푸시 할 수 있습니까?

최고의 압축 메커니즘을 모두 시도했지만 여전히 회선 속도에 의해 제한되는 것처럼 들립니다. 더 빠른 라인을 실행하는 것이 문제가 아니라고 가정하면 백업을 더 자주 실행하여 실행 시간이 더 많이 걸리는 것을 고려 했습니까?

그것의 부족으로, 작성되는 데이터의 양을 줄이는 어떤 방법이 있습니까? 응용 프로그램 스택을 알지 못하면 어떻게 말할 수는 없지만 새로운 파일을 만드는 대신 응용 프로그램이 기존 파일을 덮어 쓰는지 확인하는 것과 같은 일을하는 것이 도움이 될 수 있습니다. 또한 필요하지 않은 임시 / 캐시 파일의 백업을 저장하지 않아야합니다.

여기 당신이하고있는 것과 똑같은 일을 배운 것입니다. 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 상자는 모든 램을 캐시로 사용하므로 mbuffer에 1g조차 제공하면 일부 캐시 크기를 줄여야합니다.

또한 이것은 실제로 내 전문 영역이 아니며 ssh가 압축을 수행하는 것이 가장 좋습니다. 귀하의 예에서는 bzip을 사용하고 기본적으로 압축을 사용하는 ssh를 사용한다고 생각하므로 SSH는 압축 스트림을 압축하려고합니다. CPU 사용량이 가장 적고 나에게 중요한 것으로서 arcfour를 암호로 사용했습니다. 다른 암호로 더 나은 결과를 얻을 수는 있지만 SSH가 압축을 수행하도록 허용하십시오 (또는 지원하지 않는 것을 사용하려면 ssh 압축을 끄십시오).

정말 흥미로운 점은 로컬 호스트에서 송수신 할 때 mbuffer를 사용하면 속도가 빨라진다는 것입니다.

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

localhost 전송을위한 4g가 저에게 달콤한 곳 인 것으로 나타났습니다. zfs send / receive가 실제로 대기 시간이나 스트림의 다른 일시 중지를 좋아하지 않는다는 것을 보여줍니다.

그냥 내 경험이 도움이되기를 바랍니다. 이 모든 것을 알아내는 데 시간이 걸렸습니다.

이것은 귀하의 특정 질문에 대한 답변입니다.

rzip 을 시도 할 수 있지만 compress / bzip / gzip과 약간 다른 방식으로 작동합니다.

rzip은 전체 파일을 읽을 수 있으므로 파이프 라인에서 실행할 수 없습니다. 이는 로컬 스토리지 요구 사항을 크게 증가 시키며 하나의 단일 파이프에서 와이어를 통해 백업을 실행하고 백업을 보낼 수 없습니다. 즉, 이 테스트 에 따르면 결과 파일 은 상당히 작습니다.

리소스 제약 조건이 파이프 인 경우 어쨌든 백업을 24x7로 실행하므로 스냅 샷을 지속적으로 복사하고 어쨌든 계속 유지하기 만하면됩니다.

새로운 명령은 다음과 같습니다.

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는 이제 압축 된 복제를 지원합니다. -fs 플래그를 zfs send 명령에 추가하기 만하면 디스크에서 압축 된 내용이 파이프를 통해 다른 쪽 끝으로 전달 될 때 압축 된 상태로 유지됩니다. ZFS의 기본 압축은 lz4이므로 더 많은 압축을 얻을 수 있습니다.

2 :이 경우에 사용하기에 가장 적합한 압축기는 zstd (ZStandard)이며, 이제는 압축 수준 (지원되는 19 개 이상의 레벨과 새로운 고속 zstd-fast 레벨 사이)을 변경하는 '적응 형'모드가 있습니다. zfs send와 zfs recv 간의 링크 속도 파이프를 최소로 보내기 위해 대기중인 데이터 큐를 유지하면서 가능한 한 많이 압축합니다. 링크가 빠르면 데이터를 더 많이 압축하는 데 시간을 낭비하지 않으며 링크가 느리면 데이터를 더 많이 압축하고 결국 시간을 절약하기 위해 계속 노력합니다. 또한 스레드 압축을 지원하므로 pigzip과 같은 특수 버전 이외의 gzip 및 bzip이 아닌 여러 코어를 활용할 수 있습니다.

사이트의 원시 대역폭을 단순히 증가시킬 수 없다고 가정합니다 ...

호스트에서 압축을 사용하지 않으면 이점이있을 수 있습니다.

wan 옵티 마이저와 같은 것을 사용하는 경우 파일을 보내기 전에 압축 하지 않으면 전송을 훨씬 더 잘 최적화 할 수 있습니다. 즉, 수행중인 작업을 정확하게 수행하지만 파이프에서 bzip2를 제거합니다. 백업을 몇 번 실행 한 후 wan 옵티마이 저는 전송에서 볼 수있는 많은 부분을 캐시하고 전송 속도가 크게 향상되었습니다.

버지가 제한적인 경우 rsync를 사용하고 압축되지 않은 스냅 샷 을 rsync하여 비슷한 개선을 볼 수 있습니다 .

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가 어제의 스냅 샷과 오늘의 차이점 만 전송하기 때문에 더 빠릅니다. 스냅 샷 프로세스의 작동 방식에 따라 두 파일이 실제로 동일한 파일이 아니더라도 두 파일 사이에 많은 중복성이있을 수 있습니다.

wan 옵티마이 저는이 문제를 해결할 가능성이 훨씬 높습니다 (메트로 이더넷 이이 문제를 해결 하는 가장 가능성이 높은 방법이지만이를 제외 할 것입니다). rsync는 광섬유 또는 리버베드 설치에 대한 큰 점검을 작성하기 전에 로컬 데이터에서 테스트 할 가치가있는 로컬에서의 rshot입니다 (로컬로; rsync는 직선 사본으로 절약 한 시간을 알려줍니다).

그만한 가치가 있습니다. 직접 전송하지 않습니다 | 압축 | 압축 해제 | 전송 라인이 끊어지고 수신 중에 풀이 오랫동안 오프라인 상태 인 경우 수신 측에서 문제가 발생할 수 있습니다. 로컬 파일로 보낸 다음 스냅 샷을 압축하고 rsync (강바닥 포함)를 사용하여 전송 한 다음 파일에서받습니다. 전송에 문제가 있고 리버베드를 다시 시작해야하는 경우 리버베드는 트래픽 BUT을 최적화하지 않고 재전송 속도를 높입니다.

Rsync 압축을 사용하고 리버베드 이외의 압축을 사용하지 않고 증분 스냅 샷을 압축하지 않는 것을 살펴 보았습니다. 어느 것이 가장 좋은지 말하기는 어렵지만 rsync 압축으로 oracle에서 아카이브 로그를 전송할 때 전송 속도는 일반 파일과 리버베드 (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에 연결되어 있지만 비슷한 이유로 버퍼링이 중요합니다. USB 드라이브가 100 % 사용 중이면 전체 백업 시간이 더 빠릅니다. 요청한대로 전체적으로 더 적은 바이트를 보낼 수는 없지만 더 빨리 완료 할 수 있습니다. 버퍼링은 CPU 바운드 압축 단계가 IO 바운드가되지 않도록합니다.

내가 사용 pbzip2 WAN을 통해 보낼 때 항상 (병렬의 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는 다음을 수신합니다.

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을 사용하는 경우 파일에 저장하고 다시 동기화해야합니다.

lstvan은 arcfour128과 같은 다른 암호가 속도를 높이는 것과 같이 대역폭보다 CPU에 의해 조금 더 제한된 사람들 (당신이 아닌)을 위해. 우리는 물건을 움직일 때 내부적으로 사용합니다.

-D를 사용하여 zfs send에 대해 dedup을 설정하는 실험을하십시오. 절약은 물론 데이터에 얼마나 많은 중복이 있는지에 달려 있습니다.

"최상의"압축 알고리즘은 보유하고있는 데이터 유형에 따라 다릅니다. 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에서도 동일한 작업을 수행하는 방법을 설명하는 링크 세트가 있습니다.