Mimari ve çalışma modeli
SLOG, L2ARC ve special vdev aynı görevi yapan üç SSD katmanı değildir. SLOG, havuzun ZFS Intent Log kaydını senkron yazma dayanıklılığı için ayrı bir aygıta taşır; yalnız senkron yazma gecikmesini etkiler ve genel yazma önbelleği değildir. Güç kaybı koruması, düşük gecikme ve uygun dayanıklılık temel seçim ölçütleridir.
L2ARC, ARC’den çıkarılacak okuma verisinin ikincil önbelleğidir. Rastgele, tekrar kullanılan veri RAM’e sığmıyorsa yardımcı olabilir; tek geçişli sıralı okuma veya düşük cache-hit iş yükünde SSD eklemek yarar sağlamayabilir. L2ARC başlıkları RAM tüketir ve soğuk başlangıç/warm-up davranışı ölçülmelidir.
Special vdev, metadata’yı ve yapılandırılırsa küçük blokları havuzun ana veri vdevlerinden ayırır. Havuzun ayrılmaz tahsis sınıfıdır: kaybı havuzu kaybettirebilir. Bu yüzden ana veri vdevleriyle uyumlu redundancy, yedekleme ve geri dönüş tasarımı olmadan tek SSD special vdev eklenmez.
- 1İş yükü ve ARC/ZIL telemetrisi
- 2Darboğazı senkron yazma, tekrar okuma veya metadata olarak ayırma
- 3Uygun sınıfı redundant tasarlama
- 4Pilot, arıza ve geri dönüş testi
Tasarım parametreleri
- Senkron yazma oranı
- fsync/O_SYNC kullanan gerçek iş yükünü ve p95/p99 gecikmesini ölçmeden SLOG boyutlandırmayın.
- ARC hit ve çalışma kümesi
- L2ARC kararı için ARC hit/miss, tekrar kullanım ve working-set boyutunu birlikte ölçün.
- Small-block eşiği
- Special vdev’e yönlendirilecek küçük bloklar kapasite ve redundancy hesabına dahil edilmelidir.
- Arıza alanı
- SLOG’un kaybı normal çalışma verisini değil bekleyen senkron işlemleri etkileyebilir; special vdev kaybı ise havuz bütünlüğünü etkiler.
Hesap ve uygulama örneği
NFS üzerinde 10.000 senkron 8 KiB IOPS hedefi yaklaşık 78 MiB/s günlük akış değil, düşük p99 gecikme ve burst dayanıklılığı gerektirir. Beş saniyelik en kötü TXG penceresi için yalnız 390 MiB veri hesaplamak yeterli değildir; aygıt gecikmesi, güç kaybı koruması, queue depth ve endurance üretim yüküyle test edilir.
ARC hit oranı %96 ve kalan miss trafiği çoğunlukla tek geçişli yedek okumasıysa L2ARC eklemek sınırlı sonuç verir. Metadata latency yüksek ve milyonlarca küçük dosya varsa mirrored special vdev pilotu daha anlamlı olabilir; önce metadata boyutu ve small-block politikasının kapasite etkisi ölçülür.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
zpool status -v
zpool iostat -v 1
arcstat 1
# Linux/OpenZFS üzerinde havuz özelliklerini inceleyin
zdb -C poolname
zfs get primarycache,secondarycache,recordsize,special_small_blocks poolname/datasetHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| SLOG eklendi ama throughput değişmedi | İş yükü asenkron olabilir veya ana vdev throughput’u sınırdır. | sync write oranını, zilstat ve iostat latency değerlerini karşılaştırın. |
| L2ARC sonrası ARC baskısı arttı | Çok büyük L2ARC başlıkları RAM tüketiyor veya iş yükü tekrar kullanım göstermiyor olabilir. | arc_summary/arcstat ile header boyutu, hit oranı ve eviction davranışını izleyin. |
| Special vdev doluluğu hızla artıyor | Small-block eşiği çok geniş veya metadata tahmini eksik olabilir. | Allocation class kapasitesini ve dataset recordsize/special_small_blocks değerlerini inceleyin. |
Kabul ve doğrulama kontrolleri
- İş yükünü senkron/asenkron yazma ve tekrar okuma olarak sınıflandırın.
- ARC hit oranı ile p95/p99 cihaz gecikmesini baseline olarak kaydedin.
- SLOG adayında güç kaybı koruması ve endurance bilgisini doğrulayın.
- Special vdev’i ana havuza uygun redundancy ile tasarlayın.
- Pilot sırasında aygıt kaybı ve import/reboot senaryosunu test edin.
- Snapshot ve RAID’i bağımsız yedek yerine koymadan geri yükleme testi yapın.
İlgili kavramlar
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 kuyruğu 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.
Yazma dayanımı ve aşınma
SSD seçimi yalnız kapasite ve ilk gün hızına göre yapılmamalıdır. TBW, DWPD, garanti süresi, güç kaybı koruması ve iş yükünün yazma davranışı birlikte değerlendirilir. DWPD hesaplarında üreticinin tanımladığı kapasite ve garanti koşulları esas alınır. Veritabanı logları, küçük rastgele yazmalar ve geçici iş dosyaları aşınmayı farklı etkiler. SMART veya üretici sağlık verisini izleyin; sıcaklık, medya hatası ve kalan dayanım sinyallerini birlikte yorumlayın. Yazma amplifikasyonu nedeniyle uygulamanın yazdığı veri miktarı, NAND üzerindeki yazma miktarıyla aynı olmayabilir.
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.
Kalıcılaştırma ve güç kaybı
Commit edilmiş verinin güç kaybından sonra korunması veritabanı, işletim sistemi, dosya sistemi, kontrolcü ve diskin yazma garantilerinin birleşimine bağlıdır. Yazma önbelleği ve flush davranışını bilmeden performans için güvenlik ayarlarını kapatmayın. Güç kaybı korumalı depolama faydalıdır fakat bütün zincirin doğru yapılandırıldığını tek başına kanıtlamaz. Üretim yerine kontrollü laboratuvarda arıza ve recovery testi yapın. Veri bütünlüğünü örnek dosya açılmasıyla değil, uygulama kayıtları ve desteklenen tutarlılık kontrolleriyle doğrulayın.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.