Daha önce SmartOS yazımda ZFS’den bahsetmiştim. ZFS, Software Defined Storage çözümü olarak da görülebilir. Özel bir donanım’a ihtiyaç duymaz.
ZFS’nin self-healing olarak bilinen veri koruma ile ilgili özelliklerinden yararlanabilmek için RAID konfigürasyonunu ZFS ile yapmak gerekir. Bu yüzden, ZFS kullandığım sistemde RAID kartı olsa bile donanım üzerinden RAID yapmamayı tercih ediyorum. Tabii ZFS’nin bozulan veriyi düzeltebilmesi için verinin sağlam kopyasının olması gerekir. Bunun için RAID 1, RAID 10 veya RAID Z gibi çözümler tercih edilmeli. Ben performansın önemli olduğu çok diskli yapılarda RAID 10 kullanıyorum. Yedekleme amaçlı kurduğum sistemlerde RAID Z veya RAID Z2 kullandım. Donanım iyi olduğu zaman ZFS sorunsuz çalışıyor. SAS disk kullandığım çözümlerden memnun kaldım. Sunucu için üretilmemiş SATA diskler daha çok sorun çıkartıyor.
Tavsiye edilmesine rağmen sisteme yük getirdiği için ben düzenli olarak scrub işlemi yapmıyorum. Bunun dezavantajı disk bozulduğu zaman ortaya çıkıyor. RAID Z kullandığım sistemlerde bir kaç defa disk bozulması sonrasında yeni diske kopyalama yaparken bozulmuş dosya tespit etti. Arızalı diskten dolayı düzeltme yapamadı. Bütün diskler sağlamken scrub yapmış olsaydım düzeltirdi. Yedek amaçlı sistemler olduğu için önemsemedim.
ZFS snapshot’ları çok kullanıyorum. Cron üzerinden çalışan scriptler ile düzenli snapshot oluşturuyorum. Scriptler eski snapshot’ları da siliyor. zfs send, zfs receive komutlarını yedek amaçlı kullanıyorum. snapshot kullanarak farkları kopyaladığı için çok hızlı oluyor. Fazla dosya olan bir alanı rsync ile kopyalayınca karşılaştırması bile ciddi zaman kaybına yol açıyor. Oysa ZFS, snapshotlar üzerinden farkları hemen gönderiyor. send, receive işlemi tekrar yapıldığında karşıdaki sistemin verisi değişti diye gönderme işlemi yapmayabilir. Bunun çok basit bir çözümü var. receive yapacağım sistemdeki ZFS’yi read only mod’a alıp en güncel snapshot için rollback işlemi yapıyorum. rollback sonrasında send, receive çalışmaya başlıyor.
rsync ile ZFS üzerine yedek aldığım da oluyor. Örneğin yedeklemek istediğim bir Linux dosya sistemini rsync ile ZFS dosya sistemine kopyalıyorum. Kopyaladıktan sonra snapshot oluşturuyorum. Yedekleme scripti düzenli olarak rsync sonrası snapshot oluşturuyor. Bu şekilde günde bir defa yedek alınca, hem her bir günün verisine ayrı ayrı ulaşabiliyorum hem de değişmeyen veriler minimum yer kaplıyor. Ayrıca ZFS compression özelliğini de açtığım için veriler sıkıştırılarak saklanıyor.
ZFS ile birlikte fsck işlemini unuttum diyebilirim. Disk üzerindeki dosya sistemi yapısı her zaman tutarlı oluyor. Sistemler bir çok defa ani olarak kapanmasına rağmen donanım arızası olmadığı sürece ZFS dosya sistemi ne bozuldu ne de fsck ihtiyacı oldu.
ZFS ile yapılan RAID konfigürasyonunda basit bir mantık var. vdev’leri birleştirerek pool yapıyoruz. vdev; disk, mirror, raidz, raidz2, raidz3 olabilir. Tek bir tane vdev olabildiği gibi birden fazla vdev birleştirilerek de pool yapılabilir. Veri yazılırken vdevlere dağıtılarak yazılır. Random I/O performansında vdev sayısının fazla olması performansı artırır. Bu yüzden tek bir top-level vdev içeren bir raidz iyi performans vermez.
Solaris zamanında pool içinden vdev çıkartılamıyordu. Sonradan openZFS içine bu özelliği eklediler. Artık pool içinden mirror yapılmış top-level vdev çıkartılabiliyor. Örneğin 6 diskten, diskleri ikişer ikişer mirrorlayıp RAID 10 yaptığımızda 3 tane top-level mirror vdev oluşturmuş oluyoruz. Pool’da yeterli boş yer varsa bir mirror vdev çıkartılıp 4 diskten RAID 10 olarak kullanılabilir. Veya 12 diskimiz var diyelim. her biri dörder diskten 3 tane RAID Z’yi birleştirip pool yaparsak 3 adet top-level raidz vdev olur. Fakat henüz raidz vdevler pool’dan çıkartılamıyor.