Düşük RAM ortamı fizibilitesinde optimize edilmiş ZFS?

Şu anda bir dosya sunucusu kuruyorum ve aslında veri sürücülerini kurma noktasına geldim. Sistemde 4 sürücü vardır (bir işletim sistemi diski, 3 veri diski). OS diski ext4 olarak biçimlendirilir ve ZFS havuzuna eklenmez (ZFS'yi çalıştırmayı seçersem). Asıl sorun veri bütünlüğü ve minimum veri kaybı riskidir (bios'ta sürücü önbelleğe alma devre dışı bırakılır). Çünkü bu ZFS mükemmel bir aday gibi görünüyor, çünkü Linux için kararlı bir sürümü var (doğru?) Ve sabit sürücülerin aynı boyutta olması gerekmeyen veri çoğaltma, havuzlama ve raidz'i destekliyor.

Ama işte benim sorunum. Sunucu sadece 2GB RAM'e sahip ve bu yakın bir gelecekte yükseltilemiyor ve diğer tüm hizmetleri yükledikten sonra gerçekçi olarak sadece 1.5'e ZFS tarafından erişilebilecek. Bir seferde en fazla yaklaşık 10 müşteri kullanacaktır (ortalama 4 gibi). Güvenli kabul edilemeyecek kadar düşük mü?

Anladığım kadarıyla ZFS düşük RAM durumlarında çökebilir ve havuza girebilir. Takasın bu sorunu hafifletmeye yardımcı olup olmayacağı konusunda çelişkili görüşler duydum (20 GB'lık takas adanmış bir sürücüm var). Herkes az RAM ile ZFS ile veri kaybı yaşadı mı ve bunu önlemek için hangi optimizasyonları dahil ettiniz?

Yukarıdakileri göz önünde bulundurarak, ack boyutunu küçültüp biraz da olsa ZFS'yi çalıştırmak mümkün olabilir mi yoksa bu çok riskli olacak mı?

Sistem özellikleri: 2GB RAM 20GB takas sürücü işletim sistemi, Debian 7, minimum kurulum, FTP ve XBMC, DNLA (RAM gereksinimi hakkında fikir vermek için). Depolama sunucusu ve diğer cihazlara akış yapan müzik medyası için kullanılır.

Veri bütünlüğünü ve minimum veri kaybı riskini temel kaygılar olarak belirtirsiniz. ZFS'yi yalnızca 2GiB bellekle çalıştırmak risklidir ve önerilmez. Çok az RAM performansı öldürür ve geçmişte sayısız sökülemez havuzun sebebiydi. FreeNAS proje asgari olarak RAM 8GiB belirtiyor.

Ayrıca, endişeniz veri kaybı olduğundan ECC RAM kullanmak isteyeceksiniz. Kutunuz sadece 2GiB RAM'i destekleyebildiğinden, ZFS için iyi bir seçim olmayacak gerçekten eski bir kutu olduğunu varsayıyorum.

Sorularınızı cevaplamak için:

[…] Ve veri çoğaltmayı destekler

Pratikte, en azından 32GiB'ye sahip olmadığınızda, sadece bir kural olarak, tekilleştirmeyi unutun. Havuz boyutuna bağlı olarak önemli ölçüde daha fazla RAM'e ihtiyacınız olabilir. İkincisi, veri tekilleştirme + RAM maliyetleri bir avuç ek diskten daha ucuz ise matematik yapın. Çoğu zaman, daha fazla disk daha ucuz bir alternatiftir.

Güvenli kabul edilemeyecek kadar düşük mü?

Evet, çok düşük.

Anladığım kadarıyla ZFS düşük RAM durumlarında çökebilir ve havuza girebilir.

Bu doğru ve birçok insan düşük RAM nedeniyle havuzlarını kaybetti.

Takasın bu sorunun hafifletilmesine yardımcı olup olmayacağı konusunda çelişkili görüşler duydum

Takas hakkında unutun, ZFS kutunuz asla takas kullanmamalıdır.

DÜZENLEME: Maceraperest hissediyorsanız ve zaman zaman panik veya veri kaybı riskine aldırmıyorsanız , ZFS ayarlama kılavuzunu okuyun ve belirtilen ayarları uyarlayın. Burada 768MiB bellek sistemi için örnek ayarlar.

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

Aksi takdirde bir bellek şeridine yüz dolar yatırın ve istikrarlı ve performanslı bir sistemin tadını çıkarın.

Yüksek bellek basınç sistemlerinde (linux) belleği yükseltmek gerçekten gereklidir. Değiştirmenin IO'yu (çekirdek asılı görevi) kilitlediği ve yeniden başlatılmadıkça kullanılamaz hale getirdiği hala hata ( bağlantı ) var. Vm.swappiness = X'in zfs üzerinde bir etkisi olmadığına inanıyorum, bu yüzden arkın belirli bir sayı ile sınırlanması biraz yardımcı olabilir.