ZFS gönderme / recv için en iyi sıkıştırma

Noktadan noktaya T1 hattı üzerinden artımlı ZFS anlık görüntüleri gönderiyorum ve bir günlük yedekleme anlık görüntülerinin bir sonraki yedekleme başlamadan önce tel üzerinden zar zor olabileceği bir noktaya geliyoruz. Gönder / recv komutumuz:

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

Yedeklemek için çok fazla CPU döngüm var. Hat üzerinde daha az veri iletmek için kullanabileceğim daha iyi bir sıkıştırma algoritması veya alternatif bir yöntem var mı?

En iyi sıkıştırma mekanizmalarını denediğiniz ve hat hızıyla sınırlı kaldığınız anlaşılıyor. Daha hızlı bir satır çalıştırmanın söz konusu olmadığını varsayarsak, yedeklemeleri çalıştırmak için daha fazla zamana sahip olmak için daha az sıklıkta çalıştırmayı düşündünüz mü?

Kısaca, yazılan veri miktarını azaltmanın bir yolu var mı? Uygulama yığını bilmeden nasıl olduğunu söylemek zor, ama sadece uygulamaların yenilerini oluşturmak yerine mevcut dosyaların üzerine yazdığından emin olmak gibi şeyler yapmak yardımcı olabilir. Ve ihtiyacınız olmayacak geçici / önbellek dosyalarının yedeklerini kaydetmediğinizden emin olun.

İşte aynı şeyi yaptığınızı öğrendim. Mbuffer kullanmanızı öneririm. Ortamımda test ederken, alıcı alıcı uca yardımcı olurken, alıcı alma sırasında yardımcı olmazdı.

Bazı örnekler: http://everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

Seçenekler ve sözdizimi içeren ana sayfa http://www.maier-komor.de/mbuffer.html

Çoğaltma komut dosyamdaki send komutu:

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

bu, uzak ana bilgisayarda mbuffer'ı alma arabelleği olarak çalıştırır, böylece gönderme mümkün olduğunca hızlı çalışır. Bir 20mbit hattı çalıştırın ve gönderen tarafında mbuffer olması da yardımcı olmadı, ayrıca benim ana zfs kutusu tüm bu koç önbellek olarak kullanıyor, bu yüzden mbuffer için 1g bile vermek bazı önbellek boyutlarını azaltmak için bana gerektirir.

Ayrıca, ve bu gerçekten benim uzmanlık alanım değil, sadece ssh sıkıştırma yapmak izin en iyisi olduğunu düşünüyorum. Örneğinizde bzip kullandığınızı ve sonra varsayılan olarak sıkıştırma kullanan ssh kullandığınızı düşünüyorum, bu nedenle SSH sıkıştırılmış bir akışı sıkıştırmaya çalışıyor. Arcfour'u en az CPU yoğun olduğu ve bu benim için önemli olduğu için şifre olarak kullandım. Başka bir şifre ile daha iyi sonuçlara sahip olabilirsiniz, ancak SSH'nin sıkıştırmayı yapmasına izin vermenizi kesinlikle öneririm (veya gerçekten desteklemediği bir şey kullanmak istiyorsanız ssh sıkıştırmasını kapatın).

Gerçekten ilginç olan şey, localhost'ta gönderip alırken mbuffer'ı kullanmanın işleri hızlandırmasıdır:

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

Localhost transferleri için 4g'nin benim için tatlı noktası olduğunu gördüm. Sadece zfs gönderme / alma işleminin gecikme veya akıştaki diğer duraklamaların en iyi şekilde çalışmasını gerçekten sevmediğini gösterir.

Sadece deneyimim, umarım bu yardımcı olur. Tüm bunları anlamak biraz zamanımı aldı.

Bu, özel sorunuzun bir cevabıdır:

Rzip'i deneyebilirsiniz , ancak sıkıştır / bzip / gzip'ten biraz farklı şekillerde çalışır:

rzip dosyanın tamamını okuyabilmeyi beklediğinden, bir kanalda çalıştırılamaz. Bu, yerel depolama gereksinimlerinizi büyük ölçüde artıracaktır ve bir yedek çalıştıramaz ve yedeklemeyi tek bir boruda kablo üzerinden gönderemezsiniz. Bununla birlikte, ortaya çıkan dosyalar, en azından bu teste göre , biraz daha küçüktür.

Kaynak kısıtlamanız borunuzsa, her nasılsa 7 gün 24 saat yedekler çalıştıracaksınız, bu yüzden anlık görüntüleri sürekli olarak kopyalamanız ve yine de devam etmenizi ummanız gerekir.

Yeni komutunuz:

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

Daha iyi hata düzeltmesi yapmak isteyeceksiniz ve sıkıştırılmış dosyaları aktarmak için rsync gibi bir şey kullanmayı düşüneceksiniz, böylece aktarım ortada başarısız olursa kaldığınız yerden devam edebilirsiniz.

Bu sorunun gönderilmesinden bu yana geçen yıllarda işler değişti:

1: ZFS artık sıkıştırılmış çoğaltmayı desteklemektedir, zc send komutuna -c bayrağını eklemeniz yeterlidir ve diskte sıkıştırılanları borudan diğer uca geçerken sıkıştırılmış olarak kalır. ZFS'de varsayılan sıkıştırma lz4 olduğundan, kazanılacak daha fazla sıkıştırma olabilir.

2: Bu durumda kullanılacak en iyi kompresör zstd'dir (ZStandard), şimdi sıkıştırma seviyesini (desteklenen 19+ seviye artı yeni yüksek hızlı zstd-hızlı seviyeleri arasında) değiştirecek 'uyarlanabilir' bir moda sahiptir. zfs send ve zfs recv arasındaki bağlantının hızı. Veri kuyruğunu en aza indirmeyi bekleyen veri kuyruğunu olabildiğince sıkıştırır. Bağlantınız hızlıysa, verileri daha fazla sıkıştırmak zaman kaybetmez ve bağlantınız yavaşsa, verileri daha fazla sıkıştırmak ve sonunda size zaman kazandırır. Ayrıca dişli sıkıştırmayı destekler, bu nedenle gzip ve bzip'in yapmadığı çoklu çekirdeklerden, pigzip gibi özel sürümlerin dışında yararlanabiliyorum.

Sitenizin ham bant genişliğini arttıramayacağınızı varsayıyorum ...

Ana bilgisayarda sıkıştırma kullanmamanın faydasını görebilirsiniz.

Eğer bir şey kullanmak optimizer wan, bu çok daha iyi eğer transferi optimize etmek mümkün olacak yok göndermeden önce dosyayı sıkıştırmak, yaptığınızı tam olarak ne yapmak yani ama borusundan bzip2'yi çıkarın. Yedeklemenizin birkaç çalıştırılmasından sonra, wan optimizer aktarımda gördüklerinin çok büyük bir bölümünü önbelleğe almış olacak ve aktarım hızlarında büyük gelişmeler göreceksiniz.

Sınırlı bir bütçeniz varsa , rsync'i kullanarak ve sıkıştırılmamış anlık görüntüyü yeniden senkronize ederek benzer bir gelişme görebilirsiniz , yani:

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'

Bu daha hızlı olurdu, çünkü rsync sadece dünün anlık görüntüsü ile bugünün farkı arasındaki farkı aktaracaktı. Anlık görüntü oluşturma işleminin nasıl çalıştığına bağlı olarak, ikisi arasında aynı dosya olmasa bile, ikisi arasında hala fazlalık olabilir.

Wan optimizer bu sorunu düzeltmek için çok daha olası bir yoldur (metro ethernet bu sorunu çözmenin en olası yoludur, ancak bunu masanın dışında bırakacağız). Rsync karanlıkta sadece fiber veya nehir yatağı kurulumu için büyük bir çek yazmadan önce yerel verilerinizde test etmeye değer (yerel olarak; düz bir kopya üzerinden ne kadar zaman kazandığını söyleyecektir) vahşi bir çekimdir.

Değer için. Doğrudan gönderme yapmam | sıkıştır | genişletme | aktarım hattı yapışırsa ve havuzlarınız alım sırasında uzun süre çevrimdışı kalırsa bu, alıcı sonunda sorunlara yol açabilir. Yerel bir dosyaya göndeririz, ardından anlık görüntüyü gzipler ve rsync (nehir yatağı ile) kullanarak aktarırız, sonra dosyadan alırız. Nehir yatağı trafiği optimize etmez, ancak transferle ilgili bir sorun varsa ve yeniden başlatılması gerekiyorsa nehir yatağı yeniden gönderimi hızlandırır.

Artımlı anlık görüntüyü sıkıştırmamak, Rsync sıkıştırması kullanmak ve nehir yatağı dışında herhangi bir sıkıştırma kullanmak istemedik. Hangisinin en iyisi olduğunu söylemek zor ama rsync sıkıştırmasıyla arşiv arşivlerini kâhinden aktarırken aktarım hızı, düz dosyaların ve nehir yatağının (RSync ile) kabaca iki katıdır.

Bir nehir yatağınız varsa, nehir yatağı rsync'i anladığı ve onu optimize etmeye çalışacağı ve önbelleğe veri ekleyeceği için rsync'i ssh değil kullanın (yukarıya bakın, aktarımları yeniden başlatın).

Deneyimlerim, zfs sendaşağıdaki sıkıştırma adımından çok daha hızlı (ortalama) olmasına rağmen oldukça burst. Yedeklemem sonra zfs sendve sonra önemli miktarda arabellek ekler gzip:

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

Benim durumumda çıkış cihazı USB'ye (ağa bağlı değil) bağlı, ancak arabelleğe alma işlemi benzer bir nedenden dolayı önemlidir: USB sürücü% 100 meşgul tutulduğunda toplam yedekleme süresi daha hızlıdır. Genel olarak daha az bayt gönderemezsiniz (talep ettiğiniz gibi) ancak yine de daha erken bitirebilirsiniz. Arabelleğe alma, CPU'ya bağlı sıkıştırma adımının IO'ya bağlı olmasını önler.

WAN üzerinden gönderirken her zaman pbzip2 kullanıyorum (paralel bzip2). İş parçacığı olduğundan, -p seçeneğiyle kullanılacak iş parçacığı sayısını belirleyebilirsiniz. Pbzip2'yi önce hem gönderme hem de alma ana bilgisayarlarına kurun, kurulum talimatları http://compression.ca/pbzip2/ adresindedir .

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"

Ana anahtar, anlık görüntü boyutunuzu küçültmek ve her bir anlık görüntüyü göndermek için sık aralıklarla (~ 10 dakika) anlık görüntüler oluşturmaktır. ssh bozuk bir anlık görüntü akışından devam etmeyecektir, bu nedenle gönderilecek büyük bir anlık görüntünüz varsa, akışı pbzip2'ye bağlayın, ardından yönetilebilir boyutlu parçalara bölün, ardından bölünmüş dosyaları alıcı ana bilgisayara rsync yapın, ardından zfs'ye boru, birleştirilmiş pbzip2 dosyalarını geri dönüştürür.

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--

bu, 500MB boyutunda dosyalar üretecektir:

/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'i ana makineye birden çok kez almak için (zfs gönderilmeden önce veya tam 500 MB'lık bir yığın görür görmez bile rsync yapabilirsiniz), iptal etmek için istediğiniz zaman ctrl + c tuşlarına basın :

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

zfs şunu alır:

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

Kullanıcı freind bahsetti: Değer için. Doğrudan gönderme yapmam | sıkıştır | genişletme | aktarım hattı yapışırsa ve havuzlarınız alım sırasında uzun süre çevrimdışı kalırsa bu, alıcı sonunda sorunlara yol açabilir. - Devam eden bir gönderme / recv ağ damlaları tarafından kesilir, ancak havuzların kapalı olduğu ölçüde değil, alıcı ana bilgisayardaki <28 eski zfs sürümlerinde daha önce sorunlarla karşılaştım. İlginç. Anlık görüntüyü yalnızca alıcı uçta "zfs recv" çıkmışsa yeniden gönderin. Gerekirse "zfs recv" yi manuel olarak öldürün. FreeSD veya Linux'ta zfs send / recv çok geliştirildi.

Ssh belki blowfish-cbc için daha hızlı bir şifre alabilir, ayrıca -123456789 anahtarlarını deneyin

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

Verilerinizi test etmeniz gerekecektir. Sadece bir dosyaya gönderin ve her yöntemle sıkıştırın.

Bizim için, gzip çok büyük bir fark yarattı ve her şeyi bununla yürütüyoruz, ancak gzip ve bzip veya 7z arasında% 1'lik bir fark bile yoktu.

Yavaş bir T1 kullanıyorsanız, bir dosyaya kaydetmeniz ve yeniden senkronize etmeniz gerekir.

CPU tarafından bant genişliğinden biraz daha sınırlı olanlar (siz değil), çünkü lstvan'ın arcfour128 gibi farklı bir şifre, işleri hızlandırdığını söyledi. Bir şeyi hareket ettirirken dahili olarak kullanıyoruz.

-D ile gönderilen zfs için tekilleştirmeyi açmayı deneyin. Tasarruf, elbette verilerinizde ne kadar çoğaltma olduğuna bağlıdır.

"En iyi" sıkıştırma algoritması, sahip olduğunuz veri türüne bağlıdır - bir MP3 koleksiyonu sıkıştırmasını itiyorsanız, metin / günlük dosyaları önemli ölçüde sıkıştırılabilirken, muhtemelen işlemi yavaşlatacaktır gzip -9.

Her gün ne kadar veri aktarıyorsunuz?

TCP / IP yığınınızı TCP arabellek ve pencere boyutlarınız biraz daha büyük olacak şekilde ayarlamayı düşündünüz mü? bunun nddiçin Solaris aracını veya sysctlLinux / BSD / Mac OSX aracını kullanabilirsiniz . Solaris'te /dev/tcp tcp_max_bufve /dev/tcp tcp_cwnd_maxdeğerlerini, Linux sysctl'de net.ipv4.tcp_memise net.ipv4.tcp_rmemve net.ipv4.tcp.wmemdeğerlerini arıyorsunuz .

Ayrıca, bu bağlantılar bazı ek yardımcı olabilir:

Solaris TCP Performans Ayarı

Bu sayfanın altında, Linux / BSD / OSX için de aynısını nasıl yapacağınızı açıklayan bir dizi bağlantı var.