Güvenilmez, yavaş WAN üzerinden ZFS Sync. ZFS çoğaltma veya rsync?


10

WAN üzerinden site dışı bir yedekleme çalışması yapmakla görevlendirildim. Her iki saklama kutusu da ZFS çalıştıran FreeBSD tabanlı NAS kutularıdır.

Haftada bir veya iki kez, 15-60 konser fotoğraf verisi ofis NAS'a dökülür. Benim işim, ÇOK YAVAŞ DSL bağlantısını (~ 700Kb / s yükleme) kullanarak bu verilerin mümkün olduğunca güvenilir bir şekilde nasıl saha dışına çıkarılacağını bulmak. Alıcı kutu 30Mb / s aşağı, 5Mb / s yukarı çok daha iyi durumda.

Biliyorum, bir sabit diski tesis dışında taşımak verileri çok daha hızlı hareket ettirir, ancak bu durumda bir seçenek değildir.

Seçeneklerim şu şekilde görünüyor:

  • Ssh üzerinden ZFS artımlı gönderme
  • Rsync

rsync zaman onurlu bir çözümdür ve bir şey kesintiye uğrarsa gönderime devam edebilmek için çok önemli bir yeteneğe sahiptir. Birçok dosya üzerinde yineleme ve yinelenenleri kaldırma hakkında bilmemek dezavantajı vardır.

ZFS anlık görüntü gönderme biraz daha az veri aktarabilir (dosya sistemi hakkında çok daha fazla şey bilir, veri tekilleştirme yapabilir, meta veri değişikliklerini rsync'den daha verimli bir şekilde paketleyebilir) ve yalnızca kopyalamak yerine dosya sistemi durumunu düzgün bir şekilde çoğaltma avantajına sahiptir. dosyaları tek tek (daha disk yoğun).

ZFS çoğaltma performansı hakkında endişeliyim [1] (bu makale bir yaşında olsa da). Ayrıca bir şey düştüğünde aktarımı yeniden başlatabilme konusunda endişeliyim - anlık görüntü yeteneği bunu içermiyor gibi görünüyor. Tüm sistemin tamamen kapalı olması gerekir.

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

Her iki seçeneği de kullanarak, trafiği belirli bir bağlantı noktasından yönlendirip ardından yönlendiricilerdeki QOS'u kullanarak öncelik sırasına koyabilmeliyim. Birkaç gün süreceğinden, her aktarım sırasında her iki sitedeki kullanıcılar üzerinde büyük olumsuz etkilerden kaçınmam gerekir.

Yani ... bu konudaki düşüncem. İyi seçenekleri kaçırdım mı? Başka biri benzer bir şey ayarladı mı?


Unison'u düşünün .
sampablokuper

Yanıtlar:


8
  1. Günde maksimum 6 GB transfer edebilirseniz (sıfır havai ve sıfır rakip trafik varsayarak) ve "15-60 konser" i "haftada bir veya iki kez" sıklıkta taşımanız gerekiyorsa, bu 15-120 Haftada GB veya günde 2-17 GB arasında herhangi bir yerde. Yoğun talep planlamak gerektiğinden ve 17 GB, teorik maksimum 6 GB'ınızı bile aştığından, çok ciddi bir bant genişliği sorununuz olması muhtemeldir. Bağlantıyı yükseltmek için ne gerekir? Bağlantının yükseltilmesi mümkün değilse, lütfen fiziksel medyayı planlı olarak (örneğin haftalık) postalama seçeneğini göz önünde bulundurun.

  2. Bant genişliği matematiğini biraz daha mantıklı hale getirebileceğinizi varsayarsak, rsync muhtemelen en iyi seçenek olacaktır. Veri tekilleştirme bilinci, çok fazla miktarda veri (örneğin, sanal makine görüntüleri) çoğaltılırken çok değerli olacaktır, ancak benzersiz dijital içerik (ses, video, fotoğraf) söz konusu olduğunda, çok az faydası olmalı veya hiç faydası olmamalıdır ... tabii ki kullanıcılar yanlışlıkla aynı dosyaların kopyalarını saklamak.


Mevcut bant genişliğini kullanabileceğimi düşünüyorum ve veri dökümlerinin çoğu aralığın daha küçük ucuna doğru yöneliyor. Pratik olarak, geçen ayki verilerden yola çıkarak günde ortalama 2-3 konser olacak. Hemen çoğaltmaya ihtiyacım yok.
Paul McMillan

Ve evet, fiziksel medyayı postalamak çok daha iyi ... Keşke bir seçenek olsaydı.
Paul McMillan

Tekilleştirme hakkında iyi bir nokta. Kopyalananların çoğu çoğaltılamaz - kullanıcılar o kadar yoğun değildir.
Paul McMillan

1
Ekleyeceğim tek şey belki de rsync kullanmamaktır. Ben de senkronizasyon işlemi değil, bir aktarım süreci olarak kullanıyordum çünkü rsync yavaşlığını yaşadı. Sonra mevcut verilerimin çoğunun değişmediğini ve sadece yeni verilerin kopyalanması gerektiğini fark ettim, benim için sadece yeni dosyalarda cp kullandım ve çok daha hızlıydı. Değişen (ya da sadece dosyaların bir kısmı) dosyaları olsaydı o zaman rsync kullanırdım. Bu yüzden yeni dosyaları ayırmanızı ve devam ettirilebilir bir aktarma yöntemi seçmenizi öneririm. Ayrıca, sıkıştırma bir CPU ve RAM / bant genişliği ödünleşimi olacaktır (her iki uçta).
Scott McClenning

Hmm ... Doğru konfigürasyon ile rsync'in nispeten hızlı bir şekilde yapılabileceğini okudum. Ne kadar optimizasyon denediniz?
Paul McMillan

13

Biraz araştırma yaptıktan sonra anlık görüntü gönderme konusunda haklı olduğuna inanıyorum. ZFS SENDve RECEIVEkomutlar bzip2'ye bağlanabilir ve daha sonra bu dosya diğer makineye yeniden senkronize edilebilir.

Kullandığım bazı kaynaklar:

Yayınlanmış çoğaltma komut dosyalarına sahip bir ileti bulamadım, ancak yedek komut dosyalarını gönderen birini buldum . Dedi ki, anlamadım, bu yüzden önemsiz olabilir.

Web sitesinin birçoğu bunu sık sık yapmak için bir cron işi kurma hakkında konuştu. Bu durumda, bant genişliği ve kullanıcılar üzerinde daha az etkisi olacak şekilde çoğaltabilir / yedekleyebilir ve tesis dışı veriler daha güncel olduğundan iyi bir olağanüstü durum kurtarma özelliği olabilirsiniz. (Yani, başlangıçta ilk veri yığınından sonra.)

Yine, anlık görüntü gönderme konusunda doğru fikre sahip olduğunuzu düşünüyorum SEND/ / kullanmanın birçok avantajı var gibi görünüyor RECEIVE.

DÜZENLEME: Sadece izledi video1 video2 may suports kullanımını yardımcı olur SEND/ RECEIVEve rsync bahsediyor (3m49s de başlar). Konuşmacı Ben Rockwood'du ve işte bloguna bir link .


1
Ben rsync kullanımı gerçek dosya farklı yerine, duraklatma / devam işlevselliği ile sınırlı olduğunu tahmin. Dosya sisteminin kendisi (ve oluşturduğu değişiklik dosyaları) neler olup bittiğini rsync'den daha iyi bildiğinden, bu mantıklıdır.
Paul McMillan

Ek bir not olarak: gzip ve bzip için modern ve daha hızlı bir yedek olan ZSTD, birden çok iş parçacığını ve 20'den fazla sıkıştırma seviyesini destekler. Ayrıca 'uyarlamalı sıkıştırma' adı verilen katkıda bulunan isteğe bağlı bir özelliğe sahiptir. Bu modda, zaman kazanmak için mümkün olduğunca fazla sıkıştırma yaparken, ağ borusunu dolu tutmak için sıkıştırma seviyesi otomatik olarak yukarı ve aşağı ayarlanır. Bu, bir darboğaz haline gelmenizi veya ağın çok yavaş olması nedeniyle yapabileceğiniz sıkıştırmayı kaçırmanızı önler.
Allan Jude

2

Yedeklemelerin amacı nedir ve bunlara nasıl erişilmeleri gerekir?

Yedeklemeleriniz esas olarak felaket kurtarma amaçlıysa, ZFS anlık görüntüleri bir dosya sistemini son artımdaki tam durumuna geri alabileceğiniz için tercih edilebilir.

Ancak, yedeklemelerinizin kullanıcılara yanlışlıkla silinmiş, bozulmuş vb. Dosyalara erişmesini sağlaması gerekiyorsa, rsync daha iyi bir seçenek olabilir. Son kullanıcılar anlık görüntü kavramını anlamayabilir veya belki de NAS'ınız son kullanıcılara önceki anlık görüntülere erişim sağlamaz. Her iki durumda da, kullanıcı tarafından dosya sistemi üzerinden kolayca erişilebilen bir yedekleme sağlamak için rsync'i kullanabilirsiniz.

Rsync ile değiştirilen dosyaların yedeklerini korumak için --backup bayrağını kullanabilir ve --suffix bayrağıyla dosyaların eski sürümlerinin nasıl yeniden adlandırılacağını kontrol edebilirsiniz. Bu, dosyaların eski tarihli sürümlerine sahip olabileceğiniz bir yedek oluşturmayı kolaylaştırır

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

Bunu, eski dosyaları gerektiği gibi temizlemek için bir find komutu içeren bir cronjob ile kolayca birleştirebilirsiniz.

Her iki çözüm de dosyalar hakkında yedek olarak çalışacak kadar metainformasyonu koruyabilmelidir (rsync --perms, --owner vb bayrakları sağlar). Veri merkezleri arasında büyük miktarda veri yedeklemek için rsync kullanıyorum ve kurulumdan çok memnunum.


2

ZFS, bu yılın Mart ayı boyunca kesilen bir çoğaltmanın devam etmesini sağlayacak 'devam edilebilir gönderme' özelliğini almalıdır. Bu özellik Matt Ahrens ve diğer bazı kişiler tarafından tamamlandı ve yakında yayınlanacak.


'Sürdürülebilir gönderme'nin bir süredir OpenZFS'de (FreeBSD, Linux, MacOS vb.) Bulunduğunu unutmayın. Ayrıca, verilerin çoğaltma akışının bir parçası olarak diskte olduğu gibi sıkıştırılmış kalacağı bir 'sıkıştırılmış gönderme' özelliği de var.
Allan Jude

0

Belki WAN sıkıştırma cihazı bir çözüm ...? Riverbed kullanıyoruz ve onlardan oldukça memnunuz (örneğin, NetApp SnapMirror% 80-90'a kadar çok iyi sıkıştırılıyor)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.