ZFS Scrub Canınızı Yakıyorsa, Havuz Tasarımınız Bozuk
ZFS scrub'ın üretim gecikmesini artırması, havuzun yetersiz IOPS ve metadata tasarımının kanıtıdır; special VDEV ile çözüm.
Aylık ZFS scrub çalıştığında uygulama gecikmesi ikiye katlanıyor, ekipler scrub'ı erteliyor ya da iptal ediyor, sonra bir disk arızasında resilver haftalarca sürüyor ve ikinci diskteki gizli bir checksum hatası basit bir değişimi yedekten kurtarma vakasına çeviriyor. Scrub, ZFS'in en düşük öncelikli, salt okunur iş yüküdür; eğer bu iş yükü üretimi bozuyorsa, sorun scrub değil, havuzun performans marjının hiç olmamasıdır. OpenZFS 0.8'den beri scrub iki fazlı çalışır: önce metadata (indirect block ve dnode ağacı) taranıp sıralı blok aralıkları çıkarılır, sonra bu aralıklar büyük sıralı okumalarla işlenir. Ancak parçalanmış, küçük bloklu havuzlarda metadata taraması hâlâ rastgele okuma fırtınasıdır ve hiçbir sıralama bunu düzeltemez.
Sorunun kökü boyutlandırmadadır: havuzlar genellikle sadece kullanılabilir TB ve fiyata göre planlanır, %85-95 doluluk normal kabul edilir, RAIDZ VDEV başına tek disk kadar rastgele IOPS sunar ve scrub/resilver/snapshot temizliği gibi bakım işleri bütçeye hiç girmez. Sonuç, uygulamayı zar zor kaldıran ama kendi bakımını finanse edemeyen bir havuzdur.
Çözüm daha fazla spindle almak zorunda kalmadan mümkün: OpenZFS allocation class özelliğiyle eklenen bir special VDEV (genellikle aynalanmış NVMe/SSD grubu) tüm metadata'yı ve isteğe bağlı olarak special_small_blocks eşiği altındaki küçük dosya bloklarını üstlenir. Böylece scrub'ın rastgele okuma yükü SSD'lere kayar, dönen diskler sadece iyi oldukları sıralı veri okumalarını yapar. zdb -bb ile mevcut metadata ayak izi ölçülebilir; tipik havuzlarda bu, tahsis edilen alanın %1'inden azdır, dolayısıyla birkaç TB'lık NVMe aynası donanım bütçesinin küçük bir yüzdesiyle bakım maliyetini düşürür. Special VDEV üst düzey bir VDEV olduğundan mutlaka aynalanmalı ve yalnızca yeni yazmalar için geçerlidir; eski metadata'yı taşımak için zfs rewrite (OpenZFS 2.4) kullanılabilir.