Bir ZFS veya LVM veya MD yedekli heterojen depolama teklifi


10

Çoğu insanın sahip olduğu aynı sorunu yaşıyorum: gerçeği ile güvenilir bir kişisel depolama çözümü nasıl oluşturulur:

  1. Sabit sürücüler endişe verici düzenlilikle başarısız olur. Dosyaları kaybetmek kabul edilemez.
  2. Zaman zaman yeni bir HDD alacağım. Kaçınılmaz olarak, en iyi fiyat / GB, son HDD satın alımından farklı bir boyuttur.
  3. 2 zaman içinde heterojen bir disk koleksiyonum olduğu anlamına gelir. Hepsini kullanmak istiyorum ve arızalı diskler genellikle daha büyük disklerle değiştirilecek.

  4. Veri bütünlüğü ve güvenilirliği benim için hızdan daha önemlidir.

Bu yüzden başımı bu soruna birkaç gün boyunca vurduktan sonra (ve yıllarca başımın arkasında) aşağıdaki çözümü öneriyorum. Bir Ubuntu PPA'da bulunan yerel linux ZFS'ye dayanarak test ettiğim bir çözümü anlatacağım , ancak LVM, MD ve btrfs de bunu başarmak için kullanılabilir. Bunun için RAID1 (ZFS mirror vdevs) kullanacağım.

  1. Sürücü setiniz göz önüne alındığında, her bir grubun kapasitesi diğerine olabildiğince yakın olacak şekilde iki disk grubu halinde gruplayın.
  2. Büyük diskleri, diğer grupta, daha küçük disklerden biriyle tam olarak aynı boyutta olacak şekilde bölümleyin.
  3. Her diskin aynasını başka bir diskte olacak şekilde ayna vdevleri oluşturun.

Örneğin, yeni bir 2 TB sürücünün, eski bir 750 GB sürücünün, 2 eski 400 GB sürücünün ve bir eski 500 GB sürücünün disk setini düşünün. En iyi yansıtılmış bölümleme 2 TB kullanılabilir alana sahiptir ve aşağıdaki şemada açıklanmıştır: burada ':' bölümleri ayırır ve '|' diskleri ayırır:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Zpool'unuzu şu şekilde oluşturun:

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

Bu 4 aynalı vdev oluşturur. Disklerden herhangi biri başarısız olursa, değiştirilebilir (herhangi bir boyut diskiyle) ve eksik bölümleri yeniden oluşturmak için bölümlenebilir. ZFS vdevs'lerinin bir havuza eklenmesi ancak kaldırılmaması önemlidir . Dolayısıyla, eğer mümkünse, yeni bir sürücü satın aldığınızda, mevcut vdev'leri yeniden düzenlemek istersiniz. Bir sonraki satın alma işleminin 3 TB'lık bir disk olduğunu varsayalım. Aşağıdaki yapılandırmada açıklandığı gibi en uygun yapılandırmanız 3.5 TB kullanılabilir. Bu şimdi 5 vdev çifti. Bu, sürücülerin uygun bölümlenmesi ve art arda arızalanması ve yeniden bölümlendirilmesi ile gerçekleştirilebilir.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

Yansıtılmış sürücülerin bu şekilde eşleştirilmesinin sürdürülmesi, LVM veya MD RAID ile de yapılabilir; bu, her sürücünün her zaman bir ayna sürücüsüne veya bölüme sahip olduğundan emin olmaktır. Her şey yansıtıldığından, sürücüler eklenirken veya kaldırılırken sürücüleri bozmak ve parkurları yeniden düzenlemekte özgürüz. LVM veya MD kullanarak, ZFS'de BTRFS'ye kıyasla daha az karmaşık kurtarma araçları pahasına sürücüleri kaldırmak ve diziyi küçültmek mümkün olacaktır.

Bu prosedür hakkında yorumunuz var mı? İyi bir komut dosyası sürücülerin kayıpsız tahsisini ve yeniden düzenlenmesini idare edebilir. LVM vs. MD vs. ZFS hakkında yorumlarınız mı var? Ortaya çıkan garip bölümlenmiş dizinin performansı hakkında herhangi bir yorumunuz var mı? Aynı sürücüdeki birden çok bölüm arasında veri düzenlemesi aşırı kafa arama ve erken arızaya neden olur mu?

BTRFS devs: herkes bunu istiyor ve LVM veya MD teknik olarak gerekli değil (ve bence, alt optimal). Fazladan heterojen bir dizinin korunmasını kolaylaştırmak, btrfs için katil bir özellik olacaktır. LVM / MD / ZFS'yi olduğu gibi kesmek. Resliver / resync'in en aza indirilmesi büyük ölçüde arzu edilir.

Evet, bu elbette fakir bir adamın Drobo'su. Bunun için özel bir donanıma ihtiyaç duyulmamalıdır ...

Yanıtlar:


4

Bunu ZFS ile test ettim ve yazma performansı olması gereken şeylerin yarısı kadardır, çünkü ZFS tüm vdev'leri okur ve yazar. Bu nedenle, hız en çok bölümlü diskin hızı ile sınırlıdır. Okuma hızı disk bant genişliğine eşit gibi görünüyor. İki diskteki bir çift ZFS bölümünün, tek bir diskin okuma hızını kabaca iki katına çıkardığını unutmayın, çünkü disklerden paralel olarak okuyabilir.

İki yarıyı oluşturmak için MD LINEAR dizilerini veya LVM'yi kullanmak, yukarıdaki ZFS teklifine kıyasla iki kat yazma performansı ile sonuçlanır, ancak LVM ve MD'nin verilerin nerede depolandığı hakkında hiçbir fikri olmayan dezavantajı vardır. Bir disk arızası veya yükseltmesi durumunda, dizinin bir tarafının tamamen yok edilmesi ve yeniden senkronize edilmesi / yeniden kaynaklandırılması ve ardından diğer tarafın izlenmesi gerekir. (örneğin, resync / resliver 2 * (dizi boyutu) kopyalamak zorundadır)

Bu nedenle, en uygun çözüm, diskleri eşit boyutlu "yarıya" birleştiren iki LVM veya MD LINEAR cihazında tek bir ZFS aynası vdev oluşturmaktır. Bu, herhangi bir diskin yaklaşık iki kat okuma bant genişliğine sahiptir ve yazma bant genişliği ayrı disk bant genişliklerine eşittir.

ZFS yerine BTRFS raid1 kullanımı da çalışır, ancak ZFS okumalarını bant genişliğinin iki katına dağıtır, çünkü BTRFS çalışmaz (testlerime göre). BTRFS, bölümlerin ZFS ile küçültülememesi avantajına sahiptir (bu nedenle bir başarısızlıktan sonra çok fazla boş alanınız varsa, BTRFS ile dosya sistemini küçülterek ve daha sonra diskleri yeniden düzenleyerek daha küçük bir yedek diziyi yeniden oluşturmak mümkündür).

Bu elle yapmak sıkıcı ama bazı iyi senaryolar ile kolay.

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.