ZFS Veri Kaybı Senaryoları


27

Büyük bir ZFS Havuzu (150TB +) oluşturmak için çalışıyorum ve insanların, bazı donanımların tüm dosya sistemine göre kaybedildiği durumlar arasında ayrım yapan, özellikle de donanımın bozulmasından dolayı veri kaybı senaryoları hakkındaki deneyimleri duymak istiyorum. ZFS'de böyle bir ayrım varsa bile).

Örneğin: Diyelim ki harici bir sürücü kasası güç kaybetme ya da kontrolör kart arızası gibi bir arıza nedeniyle bir vdev kaybedilmiş. Okuduklarımdan havuz arızalı bir moda girmeli, ancak vdev geri dönerse havuz kurtarmalı mı? ya da değil? vdev kısmen hasarlıysa, tüm havuzu, bazı dosyaları vb.

Bir ZIL cihazı arıza yaparsa ne olur? Ya da birkaç ZIL'den sadece biri?

Gerçekten de tüm teknik anekdotlar veya derin teknik bilgi ile desteklenen varsayım senaryoları takdir edilmektedir!

Teşekkürler!

Güncelleştirme:

Küçük bir işletme olduğumuz için (9 kişi ya da öylesine) bunu ucuza yapıyoruz, ancak çok miktarda görüntüleme verisi üretiyoruz.

Veriler çoğunlukla ufacık dosyalardır, benim verdiğim kadarıyla TB başına yaklaşık 500 bin dosya.

Veriler önemlidir, ancak kritik değildir. ZFS havuzunu 48TB "canlı" veri dizisini (3 yıldan beri kullanımda) yansıtmak için kullanmayı ve depolamanın geri kalanını 'arşivlenmiş' veriler için kullanmayı planlıyoruz.

Havuz NFS kullanılarak paylaşılacak.

Rafın sözde bir bina yedek jeneratör hattında olduğu ve rafa tam yükte 5 dakika boyunca güç verebilecek iki APC UPS'imiz var.


2
Ne yaptığınızı zaten bilmiyorsanız, bir danışman ve / veya bazı kurslar alabilirsiniz. İhtiyacınız olan tüm özelliklerin tek bir basit cevapta ele alınabileceğinden şüpheliyim.
Lucas Kauffman

3
Yani hala ucuz tüketici 7.2 SATA'ları kullanmayı planlıyorsunuz? sigh
Chopper3

@ Chopper3 Aslında, kasten söylemedim ki ... 3 TB SATA sürücüleri yerine 2 TB SAS sürücüleri satın almaya ciddi bir önem veriyorum. Çok sayıda insan görsem de SATA sürücüleri kullandığını söylemiştim ....
Cyclone

1
ZFS için SATA diskleri gerçekten iyi bir karışım değildir. Bugünlerde bu kurulumu öneren pek çok kişi bulamazsınız. Bahsettiğiniz ölçekte (150 TB), bu pahalı ve gereksiz bir hatadır. Buna bir baksana .
ewwhite

Yanıtlar:


22

Doğru şekilde tasarlayın, ZFS'nin veri kaybını önleyin. Yine de havuzda ne sakladığını açıklamamışsın. Uygulamalarımda çoğunlukla VMWare VMDK'larına hizmet veriyor ve iSCSI üzerinden zvol ihraç ediyor. 150TB önemsiz bir miktar değil, bu yüzden ölçeklendirme konusunda profesyonel bir uzmana yaslandım.

ZFS ile hiç veri kaybetmedim.

Ben var her şeyi yaşadı:

Ancak tüm bunlar sayesinde, kayda değer bir veri kaybı yaşanmadı. Sadece kesinti. VMWare VMDK'sının bu depolamanın tepesinde oturması için, bir olay sonrasında bir fsck veya yeniden başlatma gerekliydi, ancak diğer herhangi bir sunucu çökmesinden daha kötü değildi.

Bir ZIL cihaz kaybına gelince, bu, tasarıma, ne sakladığınıza ve G / Ç'niz ve yazma düzeninize bağlıdır. Kullandığım ZIL cihazları nispeten küçük (4GB-8GB) ve yazma önbelleği gibi işlev görüyor. Bazı insanlar ZIL cihazlarını yansıtır. Üst düzey STEC SSD cihazlarının kullanılması, yansıtmayı düşük maliyetli hale getirir. Bunun yerine tek bir DDRDrive PCIe kartı kullanıyorum. Akü / ​​UPS korumasını planlayın ve süper kapasitör yedeğine sahip SSD veya PCIe kartlarını kullanın (RAID denetleyici BBWC ve FBWC uygulamalarına benzer ).

Deneyimlerimin çoğu, şeylerin Solaris / OpenSolaris ve NexentaStor tarafındaydı. İnsanların FreeBSD'de ZFS kullandığını biliyorum, ancak zpool sürümlerinin ve diğer özelliklerin ne kadar arkasında olduklarından emin değilim. Saf depolama dağıtımları için, Nexentastor rotasına gitmeyi (ve deneyimli bir iş ortağıyla konuşmayı ) amaçlı bir işletim sistemi olduğundan ve Solaris türevlerinde çalışan FreeBSD'den daha kritik dağıtımlar olduğundan tavsiye ederim .


Sorumu biraz daha fazla bilgi ile güncelledim, ancak özellikle 'asla kayda değer bir veri kaybı' ve bunun ne anlama geldiği / ne anlama geldiği hakkında daha fazla ayrıntı bilmek istiyorum. Ayrıca bu hatalı zpoollerin kurtarılması, kötü NIC'lerin kullanılması ve hatta SATA sürücülerindeki sorunlar ve SAS'a geçilmesi hakkında daha fazla bilgi edinmekle ilgileniyor (bilmekten memnun olsanız da, muhtemelen 3 TB SATA üzerinden 2 TB SAS ile gideceğim) , tavsiyen üzerine).
Cyclone

Takdir edilemez zarar == birkaç saniye işlem verisi veya çarpışma tutarlı bir durum . Kötü NIC'ler tek bir VMWare sunucusuna izole edildi ve VM düzeyinde sorunlara yol açtı. Temel ZFS depolaması değil.
ewwhite

design the right wayBağlantı artık bozuldu.
Saurabh Nanda

11

Yanlışlıkla OpenSolaris'in son sürümünde her iki ZIL'in üzerine yazdım, bu da tüm havuzun geri dönüşü olmayan bir şekilde kaybolmasına neden oldu. (Benim açımdan çok kötü bir hata! ZIL'yi kaybetmenin havuzu kaybetmek anlamına geleceğini anlamadım. Neyse ki, aksama süreleri doluydu.

151a sürümünden beri (ZPool sürümünün ne anlama geldiğini önceden bilmiyorsunuz), bu sorun çözüldü. Ve bunun işe yaradığını kanıtlayabilirim.

Bunun dışında, 20 tb'lik bir sunucuda SIFIR veri kaybettim - bunlardan başka kullanıcı hatası durumları, çoklu güç kesintileri, disk yanlış yönetimi, yanlış yapılandırmalar, çok sayıda başarısız disk, vb. Solaris'teki konfigürasyon arayüzleri versiyondan versiyona sık ve çılgınca değişir ve sürekli değişen önemli bir beceri hedefi sunar, yine de ZFS için en iyi seçenek.

Sadece ZFS ile ilgili verilerimi kaybetmedim (korkunç hatamdan sonra), ama beni sürekli koruyor. Artık veri bozulmasını deneyimlemiyorum - bu, beni son 20 yıl boyunca, yaptığım herhangi bir sunucu ve iş istasyonunda rahatsız etti. Sessiz (veya sadece "oldukça sessiz") veri bozulması, veriler yedekleme rotasyonundan çıktığında beni gerçekten defalarca öldürdü, ancak aslında diskte bozuluyordu. Veya yedeklerin bozuk sürümleri yedeklediği diğer senaryolar. Bu, bir defada büyük bir şekilde veri kaybetmekten çok daha büyük bir problemdi ve neredeyse her zaman yedeklendi. Bu nedenle, sadece ZFS'yi seviyorum ve sağlama toplamı ve otomatik iyileşmenin neden on yıl boyunca dosya sistemlerinde standart özellikler olmadığını anlamadım. (Gerçekten kabul edilir, gerçekten ölüm kalım sistemleri genellikle bütünlük sigortası yaptırmanın başka yollarını kullanır,

Kelime bilge, ACL cehenneme inmek istemiyorsanız, ZFS için yerleşik CIFS sunucusu kullanmayın. Samba'yı kullan. (Yine de NFS kullandığını söylemiştin.)

SAS ve SATA argümanına katılmıyorum, en azından ZFS için SAS'ın her zaman SATA'ya tercih edildiğine dair bir öneri. Bu yorumun plakların dönme hızına, varsayılan güvenilirliğe, arabirim hızına mı yoksa başka bir özelliğe [s] atıfta mı olduğunu bilmiyorum. (Ya da belki sadece "daha pahalıya mal olurlar ve genellikle tüketiciler tarafından kullanılmazlar, bu yüzden onlar üstündürler." Son zamanlarda yayımlanan bir endüstri araştırması (hala eminim haberi), SATA'nın aslında SAS'ı en azından Anketin önemli örneklem büyüklüğü (Şok beni kesin.) Bunun SATA'nın "işletme" versiyonları mı yoksa tüketici mi olduğunu ya da hangi hızları olduğunu hatırlayamıyorum - ama kayda değer deneyimlerime göre, işletme ve tüketici modelleri aynı şekilde başarısız oluyor istatistiksel olarak anlamlı oranlar. (Tüketici sürücülerinin başarısızlığa karşı zaman aşımına uğraması çok uzun süren bir sorun var, bu da işletme için kesinlikle önemlidir - ancak bu beni ısırmadı, ve bunun, tüm sistemi alabilen donanım denetleyicileriyle daha alakalı olduğunu düşünüyorum. Böyle durumlarda ses seviyesi kapalı, ancak bu bir SAS vs SATA sorunu değil ve ZFS bu konuda hiçbir zaman başarısız olmadı.Bu deneyim sonucunda şu anda 1/3 işletme ve 2/3 tüketici SATA disk karışımı kullanıyorum .) Ayrıca, doğru bir şekilde yapılandırıldığında (örn. Üç yollu ayna şeritleri) bu SATA karışımında önemli bir performans artışı görmedim, ancak daha sonra dükkanınızın ne kadar büyük olduğuna bağlı olarak düşük bir IOPS talebim var. tipik kullanım durumları, YMMV. Disk başına yerleşik önbellek boyutunun gecikme sorunları için kullanım durumlarımda plakanın dönüş hızından daha önemli olduğunu kesinlikle fark ettim.

Başka bir deyişle, çok parametreli bir zarf: maliyet, verimlilik, IOPS, veri türü, kullanıcı sayısı, idari bant genişliği ve genel kullanım durumları. SAS'ın her zaman doğru çözüm olduğunu söylemek, bu faktörlerin geniş permütasyon evrenini göz ardı etmektir.

Ama her iki şekilde de, ZFS kesinlikle kayalar.


3
Zaman ayırdığınız için teşekkür ederiz. ZFS ile olan deneyiminiz benimki ile uyumlu. Sürücü seçimiyle ilgili yorumlarım özellikle SATA disklerine karşı nearline SAS ile ilgiliydi. Aradaki ana fark, arayüz. Mekanik olarak eşdeğerdirler. Şu anda ZFS ülkesinde en iyi uygulama, çift bağlantı noktalı arabirimlere ihtiyaç duyulması, daha iyi hata düzeltme ve SAS tarafından sunulan yönetilebilir zaman aşımları nedeniyle SATA'yı önlemektir.
ewwhite

3TB SAS diskleri kullanmaya başlamıştım ama .... bunu yapmadan önce, aynı SAS genişletilmiş mahfazasına koyduğum 30 veya daha fazla karma diski (5 400GB SATA, 12 750GB SATS, 14 1 TB SAS) bir araya getirdim. Gerçekten de en kötü durum senaryosuna göre. Bu sürücüler ayrıca zaten ~ 2-3 yıl çalışma süresine sahipti. Daha sonra rastgele 8 iplik çalışan bir program yazdım ve havuza dosya silme ve silme. Bunu bir hafta boyunca koştum. Oku ve> 100 TB havuza yazdı ... sorun yok. AVG R / W 100-400 MB / sn. SAS üzerinden SATA uyarıları hakkında şimdi eski haberler olabileceğinden şüpheleniyorum.
Siklon
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.