การบีบอัดที่ดีที่สุดสำหรับ ZFS send / recv

ฉันกำลังส่งสแน็ปช็อต ZFS ที่เพิ่มขึ้นผ่านสาย T1 จากจุดหนึ่งไปยังอีกจุดหนึ่งและเราไปยังจุดที่สแนปชอตของมูลค่ารายวันสามารถทำให้แทบไม่ทันก่อนที่การสำรองข้อมูลครั้งต่อไปจะเริ่มขึ้น คำสั่ง 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"

ฉันมีซีพียูมากมายเหลือเฟือ มีอัลกอริธึมการบีบอัดที่ดีกว่าหรือวิธีทางเลือกอื่นที่ฉันสามารถใช้เพื่อดันข้อมูลให้น้อยลงหรือไม่?

ดูเหมือนว่าคุณได้ลองใช้กลไกการบีบอัดที่ดีที่สุดแล้วและยังคงถูก จำกัด ด้วยความเร็วของสาย สมมติว่าการรันบรรทัดที่เร็วกว่านั้นเป็นปัญหาคุณคิดว่าจะเรียกใช้การสำรองข้อมูลบ่อยครั้งน้อยลงหรือไม่เพื่อที่พวกเขาจะได้มีเวลาทำงานมากขึ้น?

สรุปแล้วมีวิธีการลดปริมาณข้อมูลที่ถูกเขียนลงบ้างไหม? โดยไม่ทราบว่าแอปพลิเคชันของคุณซ้อนยากที่จะพูดอย่างไร แต่เพียงทำสิ่งต่าง ๆ เช่นทำให้แน่ใจว่าแอพเขียนทับไฟล์ที่มีอยู่แทนที่จะสร้างไฟล์ใหม่อาจช่วยได้ และทำให้แน่ใจว่าคุณไม่ได้บันทึกการสำรองข้อมูลของไฟล์ชั่วคราว / แคชที่คุณไม่ต้องการ

นี่คือสิ่งที่ฉันได้เรียนรู้การทำสิ่งเดียวกับที่คุณกำลังทำ ฉันแนะนำให้ใช้ 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 ทั้งหมดเป็นแคชดังนั้นการให้ 1b กับ mbuffer จะต้องลดขนาดแคชบางขนาด

นอกจากนี้และนี่ไม่ใช่ความเชี่ยวชาญของฉันฉันคิดว่ามันเป็นการดีที่สุดที่จะปล่อยให้ SSH ทำการบีบอัด ในตัวอย่างของคุณฉันคิดว่าคุณกำลังใช้ bzip แล้วใช้ ssh ซึ่งโดยค่าเริ่มต้นใช้การบีบอัดดังนั้น SSH จึงพยายามบีบอัดสตรีมที่บีบอัด ฉันลงเอยด้วยการใช้ arcfour เป็นตัวเลขเพราะมันเป็น CPU ที่น้อยที่สุดและนั่นสำคัญสำหรับฉัน คุณอาจได้ผลลัพธ์ที่ดีขึ้นด้วยรหัสลับอื่น แต่ฉันขอแนะนำให้ให้ SSH ทำการบีบอัด (หรือปิดการบีบอัด ssh หากคุณต้องการใช้สิ่งที่ไม่สนับสนุน)

สิ่งที่น่าสนใจจริงๆคือการใช้ mbuffer เมื่อส่งและรับบน localhost เร่งความเร็วในสิ่งต่าง ๆ เช่นกัน:

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

ฉันพบว่า 4g สำหรับการถ่ายโอน localhost ดูเหมือนจะเป็นของหวานสำหรับฉัน มันแสดงให้เห็นว่าการส่ง / รับ zfs ไม่ชอบความหน่วงหรือการหยุดในกระแสเพื่อให้ทำงานได้ดีที่สุด

เพียงแค่ประสบการณ์ของฉันหวังว่าสิ่งนี้จะช่วยได้ ฉันใช้เวลาพอสมควรในการหาข้อมูลทั้งหมดนี้

นี่คือคำตอบสำหรับคำถามเฉพาะของคุณ:

คุณสามารถลองrzipได้ แต่มันทำงานในรูปแบบที่แตกต่างจากการบีบอัด / bzip / gzip:

rzip คาดว่าจะสามารถอ่านไฟล์ทั้งหมดได้ดังนั้นจึงไม่สามารถรันในไพพ์ไลน์ได้ สิ่งนี้จะเพิ่มข้อกำหนดการจัดเก็บในตัวเครื่องของคุณอย่างมากและคุณจะไม่สามารถเรียกใช้การสำรองข้อมูลและส่งการสำรองข้อมูลผ่านสายในท่อเดียว ดังกล่าวไฟล์ผลลัพธ์อย่างน้อยตามการทดสอบนี้มีขนาดเล็กกว่าเล็กน้อย

หากข้อ จำกัด ด้านทรัพยากรของคุณคือไปป์คุณจะต้องสำรองข้อมูลทุกวันตลอด 24 ชั่วโมงดังนั้นคุณจะต้องทำการคัดลอกสแน็ปช็อตอย่างต่อเนื่องและหวังว่าคุณจะติดตามอย่างต่อเนื่อง

คำสั่งใหม่ของคุณจะเป็น:

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 สนับสนุนการเรพลิเคทที่บีบอัดเพียงแค่เพิ่มแฟล็ก -c ไปยังคำสั่ง zfs send และบล็อกสิ่งที่ถูกบีบอัดบนดิสก์จะยังคงถูกบีบอัดเมื่อผ่านไปป์ที่ปลายอีกด้านหนึ่ง อาจยังมีการบีบอัดเพิ่มเติมที่จะได้รับเนื่องจากการบีบอัดเริ่มต้นใน ZFS คือ lz4

2: คอมเพรสเซอร์ที่ดีที่สุดที่จะใช้ในกรณีนี้คือ zstd (ZStandard) ตอนนี้มีโหมด 'adaptive' ที่จะเปลี่ยนระดับการบีบอัด (ระหว่าง 19+ ระดับที่รองรับรวมถึงระดับ zstd-fast ความเร็วสูงใหม่) ตาม ความเร็วของลิงก์ระหว่าง zfs send และ zfs recv มันบีบอัดได้มากเท่าที่จะทำได้ในขณะที่คอยคิวข้อมูลรอให้ออกไปป์น้อยที่สุด หากลิงก์ของคุณเร็วคุณจะไม่ต้องเสียเวลาในการบีบอัดข้อมูลอีกต่อไปและหากลิงก์ของคุณช้าก็จะทำให้การบีบอัดข้อมูลเพิ่มมากขึ้นและประหยัดเวลาในที่สุด นอกจากนี้ยังรองรับการบีบอัดแบบเธรดดังนั้นฉันสามารถใช้ประโยชน์จากหลายแกนซึ่ง gzip และ bzip ทำไม่ได้นอกรุ่นพิเศษเช่น pigzip

ฉันสมมติว่าคุณไม่สามารถเพิ่มแบนด์วิดท์ดิบของเว็บไซต์ของคุณ ...

คุณอาจเห็นประโยชน์จากการไม่ใช้การบีบอัดข้อมูลบนโฮสต์

หากคุณใช้บางอย่างเช่น wan optimizer มันจะสามารถปรับการถ่ายโอนได้ดีกว่ามากถ้าคุณไม่บีบอัดไฟล์ก่อนที่จะส่งนั่นคือคุณทำสิ่งที่คุณกำลังทำอยู่ แต่ลบ bzip2 ออกจากไพพ์ หลังจากการสำรองข้อมูลของคุณสองสามครั้งตัวเพิ่มประสิทธิภาพวานจะเก็บสิ่งที่เห็นในการถ่ายโอนเป็นส่วนใหญ่และคุณจะเห็นการปรับปรุงอย่างมากในความเร็วในการถ่ายโอน

หากคุณอยู่ในช่วง จำกัด คุณอาจเห็นการปรับปรุงที่คล้ายกันโดยใช้ 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 จะถ่ายโอนความแตกต่างระหว่างสแน็ปช็อตเมื่อวานและวันนี้เท่านั้น ทั้งนี้ขึ้นอยู่กับวิธีการทำงานของสแนปชอตการถ่ายภาพอาจมีความซ้ำซ้อนกันระหว่างสองภาพแม้ว่าจะไม่ได้เป็นไฟล์เดียวกันเลย

เครื่องมือเพิ่มประสิทธิภาพวันนี้เป็นวิธีที่มีโอกาสมากขึ้นในการแก้ไขปัญหานี้ (เช่นกันเมโทรอีเธอร์เน็ตเป็นวิธีที่มีโอกาสมากที่สุดในการแก้ปัญหานี้ แต่เราจะปล่อยให้อยู่นอกตาราง) rsync เป็นเพียงการถ่ายภาพในที่มืดซึ่งมีค่าการทดสอบ (ในเครื่อง; rsync จะบอกคุณว่ามันประหยัดเวลามากเพียงใดในการคัดลอกแบบตรง) ในข้อมูลท้องถิ่นของคุณก่อนที่จะเขียนการตรวจสอบขนาดใหญ่สำหรับไฟเบอร์

สำหรับสิ่งที่คุ้มค่า ฉันจะไม่ส่งโดยตรง | บีบอัด | คลายการบีบอัด ได้รับสิ่งนี้สามารถนำไปสู่ปัญหาในตอนท้ายที่ได้รับถ้าสายการถ่ายโอน snaps และพูลของคุณจะออฟไลน์เป็นเวลานานในระหว่างการรับ เราส่งไปที่ไฟล์ในเครื่องแล้ว gzip สแน็ปช็อตและถ่ายโอนโดยใช้ rsync (พร้อมริเวอร์เบด) จากนั้นเราจะได้รับจากไฟล์ แม่น้ำไหลผ่านนั้นไม่ได้เพิ่มประสิทธิภาพการจราจร แต่หากมีปัญหาเกี่ยวกับการถ่ายโอนและจำเป็นต้องเริ่มต้นใหม่อีกครั้งความเร็วในการไหลของแม่น้ำจะส่งอีกครั้ง

เราได้ดูที่ไม่บีบอัดสแนปชอตที่เพิ่มขึ้นโดยใช้การบีบอัด Rsync และไม่ได้ใช้การบีบอัดใด ๆ นอกเหนือจากริเวอร์เบด เป็นการยากที่จะบอกว่าวิธีไหนดีที่สุด แต่เมื่อเราทำการถ่ายโอน archivelogs จาก oracle ด้วยการบีบอัด rsync อัตราการถ่ายโอนนั้นประมาณสองเท่าของไฟล์ธรรมดาและ riverbed (ด้วย RSync)

หากคุณมีแม่น้ำไหลผ่านให้ใช้ 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ตลอดเวลา (ขนาน bzip2) เมื่อส่งผ่าน WAN เนื่องจากเป็นเธรดคุณสามารถระบุจำนวนเธรดที่จะใช้กับตัวเลือก -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"

คีย์หลักคือการสร้างสแนปชอตเป็นระยะบ่อยครั้ง (~ 10mins) เพื่อทำให้สแนปชอตขนาดเล็กลงแล้วส่งสแน็ปช็อตแต่ละครั้ง ssh จะไม่ดำเนินการต่อจากสแน็ปช็อตสตรีมที่เสียดังนั้นหากคุณมีสแนปชอตขนาดใหญ่ที่จะส่งให้ไพพ์สตรีมไปที่ pbzip2 จากนั้นแบ่งเป็นชิ้นขนาดที่จัดการได้จากนั้น rsync แยกไฟล์

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 เพื่อรับโฮสต์หลายครั้ง (คุณอาจ rsync ได้ก่อนที่ zfs จะส่งข้อมูลให้เสร็จสมบูรณ์หรือทันทีที่คุณเห็นข้อความครบ 500MB) กด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 ที่กล่าวถึง: สำหรับสิ่งที่คุ้มค่า ฉันจะไม่ส่งโดยตรง | บีบอัด | คลายการบีบอัด ได้รับสิ่งนี้สามารถนำไปสู่ปัญหาในตอนท้ายที่ได้รับถ้าสายการถ่ายโอน snaps และพูลของคุณจะออฟไลน์เป็นเวลานานในระหว่างการรับ - ฉันพบปัญหาก่อนหน้ากับ zfs รุ่นเก่ากว่า <28 ในโฮสต์ที่รับถ้าการส่ง / recv อย่างต่อเนื่องถูกขัดจังหวะโดยเครือข่ายลดลง แต่ไม่ถึงขอบเขตที่พูลถูกออฟไลน์ นั่นดูน่าสนใจ. ส่งสแน็ปช็อตใหม่เฉพาะเมื่อ "zfs recv" ออกจากปลายรับแล้ว ฆ่า "zfs recv" ด้วยตนเองหากจำเป็น zfs send / recv ได้รับการปรับปรุงอย่างมากในขณะนี้ใน FreeBSD หรือ Linux

คุณสามารถรับรหัสได้เร็วขึ้นสำหรับ ssh บางที blowfish-cbc และลองใช้สวิตช์ -123456789

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

คุณจะต้องทดสอบกับข้อมูลของคุณ เพียงแค่ส่งไปที่ไฟล์และบีบอัดด้วยแต่ละวิธี

สำหรับเรา gzip สร้างความแตกต่างอย่างมากและเราดำเนินการทุกอย่างผ่านสิ่งนั้น แต่ไม่มีความแตกต่าง 1% ระหว่าง gzip และ bzip หรือ 7z

หากคุณใช้งานช้า T1 คุณจะต้องจัดเก็บไว้ในไฟล์และซิงค์ไปที่

สำหรับผู้ที่ไม่ใช่ซีพียูที่ จำกัด CPU มากกว่าแบนด์วิธเล็กน้อยเช่น lstvan กล่าวว่าตัวเลขที่แตกต่างกันเช่น arcfour128 เพิ่มความเร็วให้สูงขึ้น เราใช้สิ่งนั้นภายในเมื่อเคลื่อนไหวสิ่งต่าง ๆ

ทดลองเปิดการหักเงินซ้ำสำหรับ zfs ส่งด้วย -D การออมขึ้นอยู่กับจำนวนข้อมูลที่คุณมีซ้ำ

"ดีที่สุด" วิธีการบีบอัดขึ้นอยู่กับชนิดของข้อมูลที่คุณมี - ถ้าคุณกำลังผลักดันการบีบอัดคอลเลกชัน MP3 อาจจะชะลอตัวลงกระบวนการในขณะที่ข้อความ / logfiles gzip -9สามารถบีบอัดอย่างมีนัยสำคัญ

คุณกดข้อมูลมากเท่าไหร่ในแต่ละวัน?

คุณได้พิจารณาปรับ TCP / IP สแต็กของคุณเพื่อให้คุณบัฟเฟอร์ TCP และขนาดหน้าต่างที่ใหญ่กว่า? คุณสามารถใช้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 เช่นกัน