Ana içeriğe geç
Doz Teknoloji Logo
DozTeknoloji
TRUENAS & NAS

TrueNAS ve ZFS: Pool, Vdev, RAIDZ ve Dataset Tasarımı

Kapasiteyi disk toplamından ayırın; mirror/RAIDZ topolojisini, dataset sınırlarını, snapshot büyümesini ve genişleme planını birlikte hesaplayın.

İçerik güncellemesi:

Mimari ve çalışma modeli

ZFS’de fiziksel aygıtlar vdev’leri, üst seviye veri vdev’leri de pool’u oluşturur. Dataset dosya sistemi sınırını, zvol blok aygıtını temsil eder. Bir dataset’e quota vermek ayrı fiziksel arıza alanı oluşturmaz; aynı pool’daki veri hâlâ ortak donanım riskini paylaşır. Bir üst seviye veri vdev’inin kaybı pool’u kaybettirebilir, bu yüzden yedeklilik pool adıyla değil her vdev’in topolojisiyle değerlendirilir.

Mirror ve RAIDZ seçiminde kullanılabilir alan kadar küçük rastgele I/O, eşzamanlı istemci sayısı, yeniden oluşturma süresi ve kabul edilen disk arızası dikkate alınır. RAIDZ1/2/3 farklı parity düzeyleridir; tüm pool için sınırsız disk arızası toleransı vermez. İki diskli mirror’ların birden fazla disk arızasını tolere edip etmemesi arızaların hangi mirror’da olduğuna bağlıdır. Büyük disklerde resilver sırasında ek hata ve yoğunluk payı değerlendirilmelidir.

Kapasite hesabında TB/TiB dönüşümü, parity, metadata, tahsis davranışı, snapshot’ta tutulan eski bloklar ve boş alan payı ayrı kalemlerdir. Sık değişen veride snapshot büyümesi dosya sayısından çok değişen bloklar ve saklama süresine bağlıdır. Sıkıştırma oranını örnek gerçek veriyle ölçün; deduplication’ı kapasite garantisi gibi bütçelemeyin. Dedup ek bellek, metadata ve işletim maliyeti getirir.

Dataset sınırlarını departman, uygulama veya veri yaşam döngüsü üzerinden tasarlayın. Quota, reservation, compression, recordsize, ACL ve snapshot politikalarını workload’a göre değerlendirin. Reservation kapasiteyi tüketmeden ayırabilir; quota kullanım sınırı koyar. Recordsize değişikliği mevcut bütün blokları geriye dönük yeniden yazmaz. Rastgele bir tuning değeri yerine uygulamanın I/O ve tutarlılık ihtiyacını ölçün.

Genişleme yöntemi sürüm, OpenZFS feature desteği ve vdev tipine bağlıdır. Yeni vdev eklemek, diskleri daha büyüklerle değiştirmek ve desteklenen RAIDZ genişletmesi aynı işlem değildir; performans ve dağılım sonuçları farklıdır. Özellikle special vdev pool’un kritik veri yolunun parçası olabilir, sıradan çıkarılabilir cache gibi davranmayın. Her değişiklik için yedek, uyumluluk ve geri dönüş sınırını kaydedin.

  1. 1Veri ve değişim ölçümü
  2. 2Vdev ve dataset tasarımı
  3. 3Kapasite ve arıza hesabı
  4. 4Pilot ve büyüme planı
Kapasiteyi fiziksel topoloji ve veri yaşam döngüsüyle hesaplayın.

Tasarım parametreleri

Vdev arıza sınırı
Yedekliliği her vdev’de ve arıza dağılımında değerlendirin.
Net kapasite
Parity, snapshot, metadata ve büyüme payını ayırın.
Dataset politikası
Quota/reservation ve ACL/retention sınırlarını iş yüküne bağlayın.
Genişleme yöntemi
Sürüm ve topolojiye uygun işlemi bağımsız yedekle planlayın.

Hesap ve uygulama örneği

Örnek 6 × 8 TB diskli RAIDZ2 için basit parity yaklaşımı (6−2) × 8 = 32 TB nominal veri alanı verir; bu gerçek kullanılabilir kapasite değildir. Yaklaşık 29,1 TiB dönüşümünden metadata, tahsis etkisi ve boş alan payı düşülür. Yüzde 20 planlama payı seçilirse yaklaşık 23,3 TiB kalır; bu pay evrensel zorunluluk değil, örnek varsayımdır.

Günlük 100 GiB benzersiz blok değişimi ve 14 gün retention için kaba snapshot bütçesi 1.400 GiB olabilir. Birden fazla sürümde aynı blokların tutulması ve sıkıştırma sonucu değiştirir; gerçek dataset ölçümüyle tahmin güncellenir. Canlı veriye snapshot ve yeni veri büyümesini ekleyerek kota ve uyarı eşiklerini belirleyin.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Pool boş, dataset yazamıyorQuota, refquota veya reservation etkisi olabilir.Pool ve dataset alan sayaçlarını ayrı kontrol edin.
Snapshot silindi, alan azalmadıBloklar başka snapshot veya clone tarafından tutuluyor olabilir.Referans ilişkisini ve gerçek ayrılan alanı kontrol edin.
Disk arttı, performans değişmediVdev dağılımı veya başka darboğaz belirleyici olabilir.IOPS, latency ve queue ölçümünü topolojiyle eşleştirin.

Kabul ve doğrulama kontrolleri

  1. Kapasiteyi fiziksel topoloji ve veri yaşam döngüsüyle hesaplayın.
  2. Her vdev’in arıza sınırını kaydedin.
  3. TB ve TiB birimlerini açık belirtin.
  4. Snapshot büyümesini gerçek değişimle ölçün.
  5. Quota ile reservation farkını kontrol edin.
  6. Genişleme öncesi bağımsız yedeği doğrulayın.

İlgili kavramlar

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

Dosya sistemi ve depolama katmanları

Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.

IOPS ve blok boyutu

IOPS saniyedeki I/O işlem sayısını, MB/s ise taşınan veri miktarını anlatır. Aynı IOPS sayısı farklı blok boyutlarında çok farklı bant genişliği üretir. Örneğin 10.000 işlem/s × 4 KiB yaklaşık 39,1 MiB/s eder. Okuma/yazma oranı, rastgele veya sıralı erişim ve veri koruma mekanizması sonucu değiştirir. Bir benchmark sonucunu üretim uygulamasına doğrudan taşımak yerine gerçek blok dağılımını ve eşzamanlılığı ölçün. Diskin yüksek IOPS göstermesi, uygulama yanıtının iyi olduğu anlamına gelmez; gecikme de birlikte incelenmelidir.

Gecikme dağılımı

Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Birincil teknik dokümantasyon

Hazırlama yöntemi

Doz Teknoloji Teknik Ekibi tarafından hazırlanan bu rehberde üreticilerin resmi dokümanları temel alınır. Örnek senaryolar ve hesaplar yöntemi açıklamak içindir; tamamlanmış müşteri testleri değildir. Uygulamadan önce sürüm, lisans, istemci desteği, güvenlik koşulları ve geri dönüş planını kendi ortamınızda doğrulayın. Seçim mevcut ürünlerinize ve iş yükünüze göre yapılır.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!