VM'lerin ZFS ana bilgisayarında çalıştırılmasının performans sonuçları nelerdir?

Linux üzerinde ZFS kullanarak Debian Linux ana bilgisayarımda veri depolama için ext3'ten ZFS'ye geçmeyi düşünüyorum . ZFS'nin gerçekten istediğim bir katil özelliği veri bütünlüğü garantisidir. Depolama ihtiyaçlarım arttıkça depolama alanını önemli ölçüde büyütme yeteneği de sabırsızlıkla bekliyorum.

Ancak, aynı ana bilgisayarda birkaç VM de çalıştırıyorum. (Normalde, benim durumumda, ana bilgisayarda aynı anda yalnızca bir VM çalışıyor.)

Zfs verilerini dikkate alındığında checksumming ve kopyalama üzerinde yazma davranışı, birlikte gerçeği ile VM Disk görüntüleri nispeten büyük dosyaları olduğunu (benim ana SM'nin disk görüntüsü dosya şu anda 31 GB oturur) böyle bir VM konuğu içindeki performans etkileri nelerdir bir göç? Olası olumsuz performans etkisini azaltmak için hangi adımları atabilirim?

Gerekirse VM disk görüntüleri üzerinde daha az veri bütünlüğü garantisi ile yaşayabilirim (VM'lerin içinde gerçekten kritik bir şey yapmıyorum) ve bunları dosya sisteminin geri kalanından kolayca ayırabilirim, ancak En çok farklı bir dosya sistemine geçmek istememi sağlayan özelliği (seçici olarak) kapatmak zorunda değilim.

Donanım, iş istasyonu sınıfı bir sistem için oldukça iyi, ancak üst düzey bir sunucuya çok fazla mum tutmuyor (nadiren> 10 GB kullanımda 32 GB RAM, 6 çekirdekli 3.3 GHz CPU, şu anda 2.6 TB kullanılabilir disk alanı dfve toplam yaklaşık 1,1 TB boş alan; ZFS'ye geçiş daha fazla boş alan ekleyecektir ) ve veri tekilleştirmeyi çalıştırmayı planlamıyorum (tekilleştirmeyi açmak durumumda fazla bir şey eklemeyeceği için). Plan, bir JBOD yapılandırmasıyla başlamaktır (açıkçası iyi yedeklemelerle), ancak koşullar gerektiğinde sonunda iki yönlü bir ayna kurulumuna geçebilirim.

ZFS bir blok düzeyinde çalıştığından dosyaların boyutu fark etmez. ZFS daha fazla bellek ve CPU gerektirir, ancak bir dosya sistemi olarak doğası gereği daha yavaş değildir. Rağmen RAIDZ hız RAID5 eşdeğer olmadığını bilmeniz gerekir. RAID10, hızın öncelikli olduğu yerlerde iyidir.

İyi (yani buff) donanımdaki ZFS muhtemelen diğer dosya sistemlerinden daha hızlı olacaktır, muhtemelen hızlı (yani SSD) bir yerde bir ZIL oluşturmak istersiniz. Bu aslında yazma önbellek bir konum (daha, ext3 / 4 bir günlük gibi). Bu, gerçek iğler veriye sahip olmadan önce kutu ack'in diske yazılmasını sağlar.

Ayrıca, okuma önbelleği için SSD üzerinde bir L2 ARC oluşturabilirsiniz. Bu, aynı anda birkaç VM'yi önyükleyerek dizlerine fiziksel diskler getirebileceğiniz bir VM ortamında harika.

Sürücüler VDEV'lere, VDEV'ler zpoollara gider (lütfen bir seferde tüm diskleri kullanın). Bu daha küçük bir sistemse, tek bir zpool'a ve (veri kaybı konusunda fazla endişe duymuyorsanız) tek bir VDEV'ye sahip olmak isteyebilirsiniz. VDEV'ler RAID seviyesini seçtiğiniz yerdir (ancak yeterli diskiniz varsa MIRROR VDEV'leri de kullanabilirsiniz). Bir VDEV'deki en yavaş disk, tüm VDEV'nin ne kadar hızlı olduğunu belirler.

ZFS tamamen veri bütünlüğü ile ilgilidir - dosya sistemi bakımı için geleneksel araçların çoğunun (fsck gibi) bulunmamasının nedeni, çözdükleri sorunun bir ZFS dosya sisteminde bulunamamasıdır.

IMO'nun ZFS'nin en büyük dezavantajı, dosya sistemlerinizin tam yaklaşması durumunda (% 75 +) ÇOK yavaşlamasıdır. Sadece oraya gitme.

31GB gerçekten büyük değil ...

Her neyse, şu anda kullandığınız dosya sistemine bağlı olarak, ZFS'nin biraz daha yavaş olduğunu, ancak donanım özellikleriniz göz önüne alındığında, önemsiz olabileceğini görebilirsiniz.

Açıkçası ZFS, önbellekleme için VM'lerinizin genel kullanımda 'daha snappier' görünmesine neden olabilecek iyi bir RAM yığını kullanacaktır (Ağır okuma veya yazma yapmadığınızda). Linux'ta ZFS'nin nasıl ayarlandığından emin değilim , ancak mümkünse tüm RAM'inizle kaçmasını durdurmak için ARC'sini sınırlamanız gerekebilir (Ana sisteminiz için iyi bir yığın bırakacağınızı ve VM).

Sıkıştırmayı etkinleştiririm (bu günlerde tavsiye etmemek için iyi bir nedeniniz yoksa açmaktır). Dosya sistemine veri koymadan önce bunun yapılması gerektiğini unutmayın . Sıkıştırma algoritmaları genellikle disk G / Ç'den daha hızlı çalışacağından çoğu insan bununla daha hızlı olduğunu görünce şaşırır. 6 çekirdekli işlemcinizde bir performans sorununa neden olacağından şüpheliyim. VM'lerin fazla sıkıştırmasını beklemiyordum, ancak varsayılan sıkıştırma ayarıyla ~ 470GB VM verisini 304GB'a çevirmeyi başardım.

Tekilleştirme ile uğraşmayın, sadece daha sonra size musallat olmak için geri dönecek ve ondan kurtulmaya çalışmak için haftaları veri karıştıracaksınız.

Performans sorunlarıyla karşılaşırsanız, açık yanıt bir SSD'yi ZIL / L2ARC veya hatta her ikisi olarak eklemektir. Her ikisi için de bir cihaz kullanmak ideal değildir, ancak büyük olasılıkla az sayıda disk / vdev içeren bir havuzdaki performansı artıracaktır.

Eklemek için: Gerçekten mümkünse (ideal olarak aynalar) gereksiz bir yapılandırma ile başlamaya çalışırım veya mümkün olan en kısa sürede bir şeritten aynalara dönüştürürüm. ZFS tüm verileri kontrol eder ve anında hataları tespit eder (veya bir fırçalama sırasında), bu konuda hiçbir şey yapamaz (kopya kullanmadan = disk kullanımını iki katına çıkaracak). Sadece bu dosyaları silmeden ve yeniden oluşturmadan çok şey yapamayacağınız dosyalarda hatalar (muhtemelen VM disk görüntüleriniz) olduğunu söyleyeceksiniz.

Kullanım durumlarınıza ve sanal makinelerinize bağlı olarak aşağıdakileri dikkate alırım. Ana Bilgisayar İşletim sisteminin ZFS Birimlerinde Sakladığınız dosyaları kullanmasına izin verin.

Mümkünse, yalnızca İşletim Sistemi ve gerekli ikili dosyaları içeren her VM için yalnızca bir LUN oluşturun. Ve Bireysel Veriler için Depolama durumunu NFS, samba veya iSCSI (veya yorumlarda belirtildiği gibi zvoller) aracılığıyla paylaşın. ZFS sağlama toplamı ve erişim süreleri vb ile her dosyayı takip edebilirsiniz. Elbette hız o kadar önemli değilse, bazı Veri Depolarında sıkıştırmayı da etkinleştirebilirsiniz. Yarar, başka bir Dosya Sisteminin eksik katmanı olacaktır. İkinci Sanal Sabit Sürücü için bir LUN oluşturursanız ve bunun üzerinde bir NTFS Dosya Sistemi oluşturursanız, ZFS'nin büyük bir İkili blob'u işlemesi gerekir ve herhangi bir içerik veya dosyayı tanımaz ve bu nedenle ZIL veya ARC önbelleğinden yararlanamaz. uçak dosyaları gibi.

ACL'lerden bahseten ZFS, ACL'leri NFSv4 veya Samba (etkinse) üzerinden kullanabilir. FreeBSD üzerinde ZFS kullandığımı ve Sambas ACL'lerinin ZFS birimlerine eşleştirilmesini nasıl sağlayacağımı garanti edemiyorum. Ama eminim ki bu çok önemli olmamalı.

Tüm VM'ler aynı blokları okumaya başladığında, biraz yerden tasarruf etmek ve büyük okumaları (Boot storm) iyileştirmek söz konusu olduğunda, Okuma önbelleği ile birlikte veri tekilleştirme büyük bir avantajdır.

VM'ler ve Veri Depoları için ZFS anlık görüntüleri için de aynı şey geçerlidir. Basit bir kabuk betiği oluşturabilir, sanal makineyi dondurmak, sanal makinenin ve veri deposunun anlık görüntüsünü alıp çalışmaya devam etmek ya da yalnızca veri deposunu klonlamak ve sanal makinenin orijinal görüntüsünü sunmak ve bazı şeyleri test etmek için VM'yi klonlayabilirsiniz.

Olanaklar ZFS ile sınırsızdır;)

EDIT: Umarım şimdi biraz daha iyi açıkladım

EDIT2: Kişisel görüş: Çift disk hatasına dayanabileceğiniz için bir RAIDZ2 (RAID6) kullanmayı düşünün! Tek bir yedek diskiniz kaldıysa, bu hiçbir zaman yanlış olmayacaktır, ancak hızlı tepki için iki disk arızası yeterli olacaktır. Sadece Disk durumunu izlemek için senaryomu postet burada