Yeni Başlayanlar İçin ZFS

 (ikrima.dev)
2 puan yazan GN⁺ 2023-09-06 | 1 yorum | WhatsApp'ta paylaş
  • FreeNAS’te yaşanan bir ZFS arızasını vesile ederek sorun giderme, yeni volume yapılandırma ve yedekleme stratejisini kapsayan bu başlangıç rehberi, ZFS’yi ilk kez işletirken gereken yapıyı ve komutları tek bir akışta ele alıyor
  • ZFS, dosya sistemi ve mantıksal volume yöneticisini birlikte sunar; Sun Microsystems’ta başladıktan sonra Linux ve FreeBSD gibi sistemlerde ağırlıkla OpenZFS kodu kullanılır
  • Temel yapı, fiziksel diskleri bir araya getiren vdev, bunların toplandığı pool, dosya sistemi rolündeki dataset ve blok aygıt biçimindeki volume olarak ayrılır; RAIDZ-1/2/3 sırasıyla 1, 2 ve 3 disk arızasına dayanır
  • Pratikteki komutların merkezinde zpool create/status/list/import/export/destroy/scrub ve zfs create/mount/list/get/set/snapshot/diff/rollback/send/recv/destroy bulunur; aygıt adı değişikliklerinden kaynaklanan sorunlardan kaçınmak için device UUID kullanımı tercih edilir
  • Snapshot, belirli bir andaki durumu hafif şekilde korur ve zfs send/recv ile başka bir pool’a ya da sisteme çoğaltılabilir; ancak tek başına snapshot’lar yedekleme veya DR’ın yerini tutmakta zorlanır

ZFS’nin Temel Kavramları

  • ZFS, ext4, NTFS, exFAT gibi yerel bir dosya sistemi olmasının yanı sıra Linux’taki LVM benzeri bir mantıksal volume yöneticisi görevi de görür
  • Sun Microsystems tarafından geliştirildi; ZFS kaynak kodu, Oracle Sun’ı satın almadan önce açık kaynak lisansıyla yayımlanmıştı
  • Daha önce yayımlanan kod zaten çeşitli işletim sistemlerine port edildiği için sonrasında OpenZFS projesi ortaya çıktı; Linux ve FreeBSD dahil çoğu Unix benzeri sistemde bu kod kullanılır
  • Bu içerik, ZFS ile ilk kez tanışanların yapıyı ve işletim komutlarını anlayabilmesi için başlangıç seviyesindeki bakış açısıyla düzenlenmiştir

ZFS Bileşenleri

  • vdev, bir veya daha fazla fiziksel sürücüden oluşur; sabit disklerin yanı sıra dosyaları da içerebilir
    • mirror veya RAIDZ biçiminde birleştirilebilir
    • hot spare, L2ARC, ZIL gibi önemli vdev türleri dahil olmak üzere 7 vdev türü vardır
  • pool, bir veya daha fazla vdev’den oluşur; genellikle pool içinde volume veya dataset oluşturulur
    • zpool komutuyla pool oluştururken vdev de birlikte tanımlanır
    • RAIDZ seviyesini oluşturmak için birden fazla vdev türü karıştırılabilir
  • dataset, ZFS’de dosya sistemine karşılık gelen bileşendir
    • Kullanıcı erişimi, kota, sıkıştırma, snapshot gibi ayarlar yapılabilir
  • volume, dataset’e benzer ancak blok aygıt temsili sağlar
    • Dataset özelliklerinin yalnızca bir bölümünü sunar
    • ZFS üzerinde başka bir dosya sistemi çalıştırırken veya iSCSI extent dışa aktarırken kullanışlıdır

RAIDZ Türleri

  • Dynamic/Simple Stripe, yani RAID0, parity olmadan veriyi dağıtır; tek bir aygıt kaybedilirse tüm veri kaybedilir
  • MIRROR, yani RAID1, diskleri mirror’lar ve 2–4 ya da daha fazla diskle kullanılır
  • RAIDZ-1, yani RAID5, verilerle birlikte parity’yi dağıtır ve RAID arızası gerçekleşene kadar 1 fiziksel sürücünün kaybına dayanabilir
    • RAIDZ için en az 3 disk gerekir
  • RAIDZ-2, yani RAID6, en fazla 2 fiziksel sürücünün kaybına dayanabilir
    • RAIDZ-2 için en az 4 disk gerekir
  • RAIDZ-3, en fazla 3 fiziksel sürücünün kaybına dayanır
    • En az 4 disk gerekir, ancak 5’ten az diskle kullanmamak daha iyidir

Pool Oluşturma ve Durumu Kontrol Etme

  • ZFS pool’u zpool create [pool] [devices] biçiminde oluşturulur
    • Tek diskli pool örneği: zpool create tank /dev/sdb
    • 3 diskli stripe örneği: zpool create tank /dev/sdb /dev/sdc /dev/sdd
    • 2 diskli mirror örneği: zpool create tank mirror sdb sdc
    • RAIDZ pool örneği: zpool create tank raidz sdb sdc sdd
    • RAIDZ2/3, zpool create [pool name] raidz[1,2,3] [devices] biçiminde oluşturulabilir
  • Pool oluştururken -m bayrağıyla varsayılan mount point belirtilebilir
    • Örnek: zpool create tank -m /mnt/tank mirror sdb sdc
  • Örneklerde /dev/sdx biçiminde aygıt adları kullanılsa da, aygıt adı değişikliklerinden kaynaklanan önyükleme sorunlarını önlemek için device UUID kullanımı tercih edilir
  • zpool status, pool durumunu kontrol etmek için temel komuttur
    • state, pool’un çevrimiçi olup olmadığını gösterir
    • status, pool hakkında ek bilgiler gösterir
    • action, gerekli sonraki işlemleri gösterir
    • scan, scrub ilerlemesini veya son scrub durumunu gösterir
    • errors, pool’da sorun olup olmadığını belirtir
  • zpool list, pool’un boyutu, ayrılan alanı, boş alanı, fragmentation, capacity, dedup ve health gibi ayrıntıları gösterir
  • zpool history, pool oluşturulduktan sonra yapılandırma değişikliklerinde kullanılan komut geçmişini gösterir

Pool Import, Export, Silme ve Scrub

  • Pool oluşturulduktan sonra genellikle otomatik olarak import edilir ve mount edilir; ancak sorun giderme veya sistemin yeniden imajlanmasından sonra elle import gerekebilir
  • zpool import pool adı olmadan çalıştırılırsa import edilebilir pool listesini gösterir
    • Import edilebilir pool yoksa no pools available to import gösterilir
    • Pool adı belirtilirse ilgili pool import edilir; import komutu pool’u mount etmeyi de gerçekleştirir
    • zpool import -a, import edilebilir tüm pool’ları içeri alır
  • zpool import -R /mnt/tank2 tank gibi -R kullanılırsa alternate root konumuna mount edilir
    • Bu, pool’un kendi mount path’i değil, alternatif root klasörüdür
  • zpool export [pool name], import’un tersidir; pool içindeki mounted filesystem’leri unmount ettikten sonra export etmeyi dener
    • Filesystem unmount başarısız olursa -f ile zorla unmount yapılabilir
    • Kullanımda olan bir ZFS volume varsa -f kullanılsa bile export başarısız olur
  • zpool destroy, pool’u ve onun altındaki dataset veya volume’ları siler
    • Tüm veriler ve snapshot’lar da silineceği için dikkat gerekir
  • ZFS scrub, pool’daki tüm block’ları bilinen checksum’larla karşılaştırarak veri geçerliliğini kontrol eder
    • Parity bulunan vdev’lerde, sağlam disklerdeki veriyi kullanarak bozuk veriyi onarır
    • Sistem durumunu korumak için scrub belirli bir programa göre çalıştırılmalıdır
    • Başlatma: zpool scrub [pool]
    • Durum kontrolü: zpool status içindeki scan alanını kontrol etme
    • Durdurma: zpool scrub -s [pool]

Dataset Oluşturma ve Mount

  • zfs create, yeni filesystem veya volume oluşturan komuttur; burada volume’dan çok dataset odağında ele alınır
  • zfs create tank/dataset1, tank altında dataset1 oluşturur
    • tank dataset’i, zpool create sırasında otomatik oluşturulur
  • zfs create -p, mkdir -p gibi var olmayan üst dataset’leri de birlikte oluşturur
    • Üst dataset yoksa normal zfs create başarısız olur
  • zfs mount argümansız çalıştırılırsa şu anda mount edilmiş ZFS filesystem’lerini ve mount point’lerini gösterir
    • Bu çıktıya child dataset’ler dahil değildir
  • zfs mount [pool|dataset], belirtilen filesystem’i mount eder
    • zfs mount -a, tüm filesystem’leri mount eder
  • Child dataset, parent dataset olmadan da mount edilebilir
    • Bu durumda OS filesystem’inde gerekli path oluşturulur
    • Daha sonra parent dataset’i mount etmeye çalışırsanız, oluşturulan dizin nedeniyle directory is not empty hatası alınabilir
  • zfs unmount [dataset], belirtilen dataset’i unmount eder

Dataset Sorgulama ve Özellik Ayarlama

  • zfs list [dataset name], belirtilen dataset bilgilerini gösterir
    • Dataset adı yerine mount point de argüman olarak verilebilir
  • zfs list dataset adı olmadan çalıştırılırsa sistemdeki tüm dataset’leri recursive olarak gösterir
  • Dataset adı belirtilirken -r bayrağı kullanılırsa ilgili dataset’in altı recursive olarak gösterilebilir
  • ZFS property’leri filesystem, volume, snapshot ve clone davranışını kontrol eder
    • Mount option’larına benzer görünebilir
  • zfs get all [dataset], dataset’in tüm property’lerini gösterir
  • Belirli bir property değeri zfs get compression tank gibi kontrol edilir
  • Property ayarlamak için zfs set kullanılır
    • Örnek: zfs set compression=lz4 tank
    • Ayardan sonra zfs get compression tank ile compression değerinin lz4 olarak değiştiği doğrulanabilir

Snapshot’ın Çalışma Şekli ve Kullanımı

  • snapshot, filesystem’in belirli bir andaki durumunu saklar ancak dosyaları kopyalamaz
  • Snapshot mevcut veriyi read-only olarak işaretler; sonrasında filesystem’e yeni veri eklense bile snapshot’ın koruduğu mevcut data block’lar bundan etkilenmez
  • Örnek akış şöyledir
    • Mevcut Data A bulunan filesystem’de snapshot 1 oluşturulur
    • Ardından Data B eklenir ve snapshot 2 oluşturulur
    • Ardından Data C eklenir
    • Snapshot 1 Data A’yı korur; snapshot 2 Data A ve Data B’yi korur
    • Snapshot 1 silinse bile Data A, snapshot 2 tarafından korunmaya devam eder
  • Snapshot’ın kullandığı veri miktarı çok küçüktür
    • Dosyayı kopyalamak yerine, snapshot’a ait olduğunu belirten filesystem üst düzey metadata block’u kaydedildiği için
  • Snapshot, yazılım geliştirme testlerinde veya yükseltme öncesi failsafe oluşturmakta kullanışlıdır
  • Tek başına snapshot, backup veya DR çözümü olarak görülmemelidir

Snapshot Komutları

  • Snapshot oluşturma zfs snapshot [pool/dataset@snapshot_name] biçimini kullanır
    • Örnek: zfs snapshot tank/dataset1@snapshot1
  • Snapshot listesi zfs list -t snapshot ile kontrol edilir
  • Birden fazla child dataset varsa top-level dataset üzerinde snapshot oluşturulabilir veya -r bayrağıyla recursive snapshot alınabilir
    • Normal snapshot örneği: zfs snapshot tank@snapshot-master
    • Recursive snapshot örneği: zfs snapshot -r tank@recursive
  • zfs diff [older snapshot] [newer snapshot], snapshot’lar arasındaki farkı karşılaştırır
    • Çıktıda eklenen dosyalar ve değiştirilen path’ler görülebilir
  • Snapshot geri yükleme zfs rollback [pool/dataset@snapshot_name] ile yapılır
    • Rollback yapılırsa snapshot sonrasında oluşturulan dosyalar silinir
    • Daha yeni snapshot’lar da silinir; bu durumda -r seçeneğinin kullanılması istenebilir

ZFS send/recv ve Çoğaltma

  • ZFS send, snapshot’ı veri stream’i olarak gönderebilen bir özelliktir
  • Snapshot ve dataset bir dosyaya, başka bir pool’a veya SSH üzerinden başka bir sisteme çoğaltılabilir
  • Örneklerde tank ve backup adlı iki pool kullanılır
    • tank/Movies dataset’inde 1.50G veri vardır
    • Aktarımdan önce zfs snapshot tank/Movies@$(date '+%Y-%m-%d_%H-%M') ile snapshot oluşturulur
    • zfs send tank/Movies@2020-11-03_15-29 | zfs recv backup/Movies ile snapshot backup pool’una aktarılır
  • Aktarımdan sonra zfs list içinde hem backup/Movies hem de tank/Movies görünür; zfs list -t snapshot içinde de her iki taraftaki snapshot’lar kontrol edilebilir
  • zfs send, farklı seçenekleri ve kullanım senaryoları incelenmeye değer bir özelliktir; RAIDZ ve snapshot ile birlikte kullanıldığında filesystem’i daha sağlam hale getirebilir

Dataset ve Snapshot Silme

  • Dataset silme zfs destroy [pool/dataset] biçimini kullanır
    • -r bayrağı da kullanılabilir
  • Snapshot silme de zfs destroy [pool/dataset@snapshot_name] ile yapılır
    • Snapshot silerken de -r bayrağı kullanılabilir
  • ZFS daha fazla özellik sunar; ancak bu materyal temel kavramları ve komutları öğrenmek için bir başlangıç noktası niteliğindedir

Kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-06
Hacker News yorumları
  • ZFS’e daha yeni başladım; öğrenme eğrisi beklediğimden daha dik. Yaygın kullanım senaryolarını çok basitleştiren kolay bir sarmalayıcı olsa iyi olurdu.
    Örneğin havuz oluştururken ashift=12, lz4 sıkıştırma, xattr=sa, acltype=posixacl, atime=off gibi makul varsayılanlar doğrudan kullanılsa; şifreleme de birçok seçenek yerine sadece aç/kapat şeklinde olsa iyi olurdu.
    Şifreleme anahtarını oluştursa, açılışta havuzun şifresini çözen bir systemd servisi ayarlasa ve anahtar yedeklemeyi yönlendirse iyi olurdu. zfs list, veri kümesinin bağlı olup olmadığını, şifreli olup olmadığını ve anahtarın yüklenip yüklenmediğini göstermeli.
    Özyinelemeli veri kümeleri kaldırılıp {pool}/{dataset} yerine {pool}:{dataset} kullanılarak havuz ile veri kümesi net biçimde ayrıştırılsa iyi olurdu. Havuz ya da anlık görüntü adlarını da kullanıcıya yazdırmak yerine {hostname}-[A-Z], {pool name}_{datetime created} gibi kurallarla ve sayısal kısa adlarla otomatik atasa iyi olurdu.
    Havuz oluştururken disk ID’sini elle girdirmemeli; /dev/sda, /dev/sdb ile oluşturduktan sonra sürücü sırası değişse bile karışıklık olmaması için disklere metadata kaydetmeli.
    İlerleme durumu her zaman pv ile gösterilmeli; haftalık scrub ile saatlik/günlük/haftalık/aylık anlık görüntüler ve temizlik otomatik ayarlanmalı.
    Havuz olmayan bir diske aktarım yapılırsa onay aldıktan sonra gönderen havuzla aynı ayarlara sahip tek diskli bir havuz oluşturmalı; zpool ve zfs de tek bir komutta birleştirilmeli.
    Şifreli veri kümesi aktarılırken --raw otomatik kullanılmalı; aktarımın varsayılanı --replicate olmalı ve mümkünse -I kullanılmalı. Anlık görüntü dosya sistemini gizli bir dizinde saklamak yerine anlık görüntü veri kümelerini kolayca bağlayıp gezmenin de bir yolu olmalı.
    • Makul önerilerle çok güçlü kişisel tercihler birbirine karışmış. ashift=12 varsayılanı ya da {pool}:{dataset} sözdizimi anlaşılır, ama artık değiştirmek için geç kalınmış görünüyor; bazı öneriler de bilmediği kullanım senaryolarını bozabilir.
      Havuzları ana makine adına göre adlandırma yaklaşımı, birden fazla ana makineden içe aktarılabilen SAN havuzları için uygun değil.
      Haftalık scrub, periyodik anlık görüntüler ve periyodik temizlik bence işletim sistemi zamanlayıcısının işi. zpool ile zfs’i birleştirmek de mümkün olabilir, ama sonuçta zfs -pool XXXX, zfs -volume XXXX gibi bir şeye dönecek; neden gerekli olduğunu anlamıyorum.
      Özyinelemeli veri kümelerinin gerçekten yararlı olduğu durumlar var. Buna karşılık zfs list’in bağlı olma durumunu, şifreleme durumunu ve anahtarın yüklenip yüklenmediğini göstermesi gerektiğine tamamen katılıyorum.
      Disk ID’si girmeyin kısmı muğlak. ID, WWN, etiket, sdX gibi çeşitli yöntemlerle belirtilebilir ama hangi diskin kullanılacağını yine de bir şekilde söylemek gerekir.
      Sırayı değiştirseniz bile bulabilmek için diske metadata kaydetme özelliği zaten var. Birkaç sürücünün yerini değiştirip havuzu içe aktarsanız da bulur.
      Bazı öneriler varsayılan olarak fena değil; ama birkaçı kendi kullanım kalıpları ve ihtiyaçları dışındaki durumları yeterince dikkate almamış gibi. ZFS çok daha geniş bir kullanıcı kitlesini hedefliyor.
    • /dev/sda, /dev/sdb ile havuz oluşturup ZFS’in karıştırdığını söylemek, açıkçası bir ZFS sorunu olmaktan çok, çağın gereklerine uygun kullanmayan kullanıcı sorunu gibi.
      Linux’ta epeydir /dev/disk/by-id/ata-$manufactuer-$serial-$whatever gibi eksiksiz referanslar var. Havuz oluştururken bu tür yollar kullanılmalı.
    • Önerilerin çoğu güçlü biçimde tercihe dayalı; bu başlı başına kötü değil ama mevcut gelenekleri gereksiz yere sarsıyor gibi görünüyor. Örneğin neden {pool}:{dataset} olması gerektiğini anlamıyorum.
      Anlık görüntü adlarını kendin vermek istemiyorsan yazdığım küçük araç https://github.com/rollcat/zfs-autosnap işine yarayabilir.
      zfs-autosnap snap’i cron’a saatlik, zfs-autosnap gc’yi günlük koyarsan saklama politikasına göre anlık görüntü geçmişini döndürür.
      Basit bir ZFS komut sarmalayıcısı kullanmak zor değil; istersen kodumu alıp kendi aracını da yapabilirsin.
    • Demirci çırağının son görevlerinden birinin gerçek bir demircinin kullanacağı tüm araçları, yani örs, çekiç, maşa vb. bizzat yapmak olduğunu okumuştum.
      İş yerinde de o gün varsaydığımız dağıtım biçimine uygun ZFS dizileri oluşturan birkaç betik yazdım. Bunların içinde zvol’ün konacağı LUKS şifreli birim oluşturma, adlandırma kurallarını standartlaştırma, ashift=12, lz4 sıkıştırma gibi varsayılanları ayarlama vardı.
      Bu, ZFS’in kendi şifrelemesi gelmeden çok önceydi; mevcut yöntemle de sorun yaşamadığımız için betikleri ZFS şifrelemesini destekleyecek şekilde güncellemedim.
      Şu anda birçok bayrağı hatırlamıyorum ama betikler belge işlevi görüyor; ekipteki diğer kişiler de sadece make-zfs-big-mirror ya da make-big-zfs-undundant-raid0 çalıştırıyor.
      Bir gün yılda 20’den fazla sistem provizyonlama ihtiyacı doğarsa bu bile provizyonlamayla otomatikleştirilebilir.
    • Başkalarının da söylediği gibi bunlar çok güçlü kişisel tercihlere dayalı öneriler. Görüş sahibi olmak sorun değil; ama maddelerin çoğu “Linux’ta alıştığım yöntem bu değil” noktasından gerçekten sorunlu önerilere kadar uzanıyor.
      Havuzlara ad vermeyelim demek mantıksız. Havuzları o kadar sık oluşturmuyorsun; sadece bir ad ver.
      Anlık görüntü adlarını vermek istemiyorsan httm ve zfs allow kullanabilirsin. Örneğin httm -S ., rpool/ROOT/ubuntu_tiebek@snap_2022-12-14-12:31:41_httmSnapFileMount gibi bir anlık görüntü oluşturur.
      zfs ve zpool, her biri birçok alt komuta sahip mükemmel Unix komutları. ZFS tasarımcılarının daha karmaşık tek bir yönetim komutu yapmamış olmasını çok akıllıca bir karar olarak görüyorum.
      Anlık görüntü veri kümelerini açıkça bağlayıp gezmek de zfs mount ile kolayca mümkün. Ancak kararlı bir sanal arayüzün tüm dosya sürümlerini aramayı kolaylaştırdığını, bunun btrfs gibi sistemlerde çok daha zor olduğunu da kabul etmeni isterim. httm de bakmaya değer.
      [0]: https://kimono-koans.github.io/opinionated-guide/#dynamic-sn...

  • ZFS’te yararlı başka şeyler de var. zpool-attach(8) ile zpool-replace(8) arasındaki farkı bilmek iyi olur; zfs list -t all -o space ise alanın nerede kullanıldığını gösterir
    Büyük değişiklikler veya yükseltmeler öncesinde işletim sistemini korumak için ZFS Boot Environments en iyi özelliktir. Başlangıç noktası olarak https://is.gd/BECTL yararlı olabilir
    zpool history poolname, havuz yapılandırmasını ve tüm değişiklik geçmişini gösterir. Örneğin zpool create, autotrim=on, atime=off, compression=zstd, recordsize=1m gibi değişiklikler kaydedilir
    Kılavuzda eksik kalan önemli bilgiler de var. 3-yollu mirror’da 3 diskten 2’si arızalansa bile veri kalır; 4-yollu mirror’da 4 diskten 3’ü arızalansa bile kalır; N-yollu mirror’da ise N diskten N-1’i arızalansa bile veri korunur
    Veri en önemli şey olduğunda ama çok fazla slot veya disk olmadığında işe yarar

    • N-yollu mirror’ın bir başka özelliği de ZFS’nin okumaları birden fazla diske bölüştürebilmesidir. Girdi/çıktı işlem sayısının sınırlı olduğu döner disklerde bu oldukça önemliydi

  • Yıllardır büyük, çok TB’lık PostgreSQL veritabanlarını ZFS üzerinde çalıştırıyorum. ZFS sayesinde yedekleme, geçmiş snapshot’lara dayalı test ortamları oluşturma ve yerleşik sıkıştırmayla disk tasarrufu yapmak çok kolaylaştı
    İlgileniyorsanız deneyimi https://lackofimagination.org/2022/04/our-experience-with-po... adresinden okuyabilirsiniz

  • ZFS’ye başlarken en çok FreeBSD’nin ZFS Handbook’u ve Aaron Toponce’un yazıları yardımcı oldu
    [0] https://docs.freebsd.org/en/books/handbook/zfs/
    1 https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux...

    • FreeBSD belgelerini seviyorum
      Ortalıkta duran 1 GB ECC RAM’li eski bir HP Microserver’a FreeBSD kurdum; elimde eski 500 GB’lık 5 sabit disk de vardı, FreeBSD Handbook’a bakarak 5x mirror olarak yapılandırdım. FreeBSD’yi ilk kez kullanıyordum ama gayet sorunsuzdu

  • Son zamanlarda çoğu LAMP sunucularından oluşan altyapının büyük kısmını yeniden kurarken, verimli yedek kopyalama ve şifreleme için hepsini Linux’ta ZFS tabanlı yapmaya karar verdim
    Uzun zamandır yedeklerde ZFS ile rsync’i birlikte kullandığım için oldukça aşinaydım ve sonuçta iyi oldu; ancak bunu düzgün yapmaya çalışınca beklediğimden çok daha fazla zaman aldı. Özellikle veritabanları ve replikasyon konusunda web’de çok fazla hatalı tavsiye vardı
    Veritabanları için en azından blok boyutu hizalaması gibi temel tuning yapılmalı. mariadb/InnoDB konusunda Let’s Encrypt’in şu materyali açık ara en iyisiydi: https://github.com/letsencrypt/openzfs-nvme-databases. Her madde için gerekçe sunup birden çok kaynağa atıf yaptığı için çok değerli
    Web’de daha fazla arayınca, eksik ve temelsiz teorilerle birlikte çelişkili tavsiyeler, anekdotlar ve efsaneler hiç bitmiyor. Sonunda bizzat test etmek, ayarladığınız şeyleri anlamak gerekiyor; ayarlamamaya karar vermek de gayet kabul edilebilir
    Replikasyon için gerçekten man sayfalarını öneririm. ZFS sağlam replikasyon araçları sunuyor, ama o kadar genel amaçlı ki Git’in alt seviye plumbing komutları gibi hissettiriyor. SSH ile kullanılacağını varsaymadığı için kendiniz birbirine bağlamanız gerekiyor; otomatikleştirmek için uç durumları da düşünmeniz gerektiğinden başta ürkütücü geliyor
    Bu yüzden herkes syncoid gibi araçlara yöneliyor; ama syncoid türü replikasyon betiklerinde korkunç bir nokta vardı. ZFS’nin send --replication modunu kullanmayıp, daha esnek olduğu gerekçesiyle Perl’de eksik şekilde yeniden implemente ediyorlar
    İlk test sırasında yeni bir geri yükleme yaptığımda tüm şifreleme root’larının bozulduğunu ve dataset özelliklerinin tamamının otomatik senkronize edilmediğini görmek insanı çıldırtıyor. Yerleşik recursive replikasyon seçeneğini kullanırsanız ZFS bunu hallediyor
    Kafaya koyup kendi betiğinizi yazarsanız zor değil. Basit tutmak ve syncoid gibi pipeline’a gereksiz şeyleri yığmamak yeterli. Gerçek testlerde bunlar bazen hızı da düşürüyor. İlerlemeyi pv ile görüp göndermek hızlı çalışıyor
    Bir gün kendi replikasyon betiğimi yayımlayabilirim. Temelleri ele alırken replikasyonu berbat biçimde yeniden implemente etmeyen iyi referans betiklerin neredeyse hiç olmadığını hissediyorum

    • O materyal io_capacity ve io_capacity_max tuning’inden bahsediyor; ancak MySQL belgelerine tıklayıp parametrelerin gerçek rolüne bakınca ne yazık ki pek yararlı değiller
      Bu değerler, değişiklik tamponu birleştirme gibi arka plan girdi/çıktısını kontrol eder ve gerçekten iş yapması gereken ana süreçlerden girdi/çıktı kaynaklarını çalabilir
      Oldukça yoğun, 120K QPS’lik bir MySQL DB işletmiş biri olarak ikisine de dokunma ihtiyacı duymadım. Gerekli olduğunu düşünüyorsanız önce redo log’un dolma süresini ve buffer pool’daki dirty page oranını izlemelisiniz. Muhtemelen başka parametreleri ayarlamak daha iyi olacaktır
      [0] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.ht...
    • Veritabanlarında blok boyutu hizalaması gibi temel tuning yaparken şaşırtıcı biçimde kontrol edilmesi gereken bir nokta var. Genelde record size’ı eşleştirmeniz söylenir; pratikte bu, veriyi barındıran ZFS dosya sisteminin record size’ını küçültmeye götürür
      Bir seviyede daha verimli olabilir, ama deneyimlerime göre sıkıştırma oranını ciddi biçimde düşürür
      İlginç bir ikincil etki olarak, iş yüküne bağlı olsa da disk bant genişliği darboğazsa throughput tersine kötüleşebilir. Sıkıştırma sayesinde fiziksel diskin kaldırabileceğinden daha hızlı okuyup yazabilirsiniz; sıkıştırmayı bozarsanız okuma/yazma bant genişliği olumsuz etkilenebilir

  • Birkaç yıl önce Linux’ta ZFS kullanmaya başladım ve genel olarak sorunsuz ilerledi.
    Beni şaşırtan tek şey, volblocksize varsayılan değerinin çoğu RAIDZ yapılandırması için epey kötü olmasıydı. Ham disk alanının %50’sini kaybetmek istemiyorsanız değeri büyütmeniz gerekiyor.
    İlgili yazılar şöyle:
    https://jro.io/nas/#overhead
    https://openzfs.github.io/openzfs-docs/Basic%20Concepts/RAID...
    https://www.delphix.com/blog/zfs-raidz-stripe-width-or-how-i...
    Sonunda ZFS ile ilgili elektronik tablolardan birine kadar baktım:
    ZFS overhead calc.xlsx
    https://docs.google.com/spreadsheets/d/1tf4qx1aMJp8Lo_R6gpT6...
    RAID-Z parity cost
    https://docs.google.com/spreadsheets/d/1pdu_X2tR4ztF6_HLtJ-D...

    • Kişisel olarak mirror vdev’lerin %50 verimliliğini, basitliği ve performanstaki büyük artışı düşününce makul bir bedel olarak görüyorum. Artık RAIDZ pool’ları da genişletilebiliyor, ama hâlâ çok daha karmaşık ve performansı da o kadar iyi değil.

  • Daha genç ve daha aptal olduğum zamanlarda, meraklıların açık kaynak NAS işletim sisteminin —muhtemelen FreeNAS— ve ZFS’nin ne kadar harika olduğuna dair yazdıklarını çok okumuştum. eBay’den özellikleri çok düşük, ikinci el bir HP microserver aldım ve ne yaptığımı pek bilmeden işe daldım.
    Topluluk forumlarında birkaç soru sordum ama yanıtların çoğu “Belgeleri okudunuz mu?” ve “Yeterli RAM’iniz var mı?” şeklindeydi.
    Bahsedilen belgeler okunması zor bir tarzdaki PowerPoint sunumlarıydı; biraz misyonervari bir üslubu vardı, çok fazla ön bilgi varsayıyordu ve düzenli olarak güncellenmiyordu. Gerekli RAM miktarı da belirsizdi; vurgu sadece mümkün olduğunca çok RAM takmak üzerindeydi.
    Sonunda teknoloji, abartılı atmosfer ve kendi bilgi düzeyimle ilgili tüm uyarı işaretlerini görmezden geldim ve çok veri kaybettim. Çok şey öğrendim.

    • Yaklaşık ne kadar önce olduğunu hatırlıyor musunuz, merak ettim. ZFS 2000’lerin başından beri var ve FreeNAS’in 2005’te başladığını hatırlıyorum.
      Dosya sisteminin çok daha kararlı hâle geldiğini ve belgelerin de daha anlaşılır olduğunu düşünüyorum.
      Yine de ext3 gibi geleneksel journaling dosya sistemlerinden daha güçlü ve gelişmiş olduğu için, kendi ayağınıza sıkmanın da daha fazla yolu var.

  • Sonrası için birkaç not daha bırakayım: ZFS’teki tüm yedeklilik vdev katmanındadır. Bir zpool, bir veya daha fazla vdev’den oluşur ve her durumda zpool içindeki tek bir vdev’i bile kaybederseniz zpool kalıcı olarak yok olur.
    Tarihsel olarak RAIDZ, yani parity RAID, disk ekleyerek genişletilemiyordu. RAIDZ’i büyütmenin tek yolu dizideki her diski tek tek daha büyük bir diskle değiştirmek ve yeniden oluşturma sırasında bir diskin arızalanmamasını ummaktı.
    Oldukça amatörce bir değerlendirmeyle, RAIDZ’i yalnızca RAIDZ2 veya RAIDZ3 gibi disk sayısının yüksek olduğu durumlarda düşünürdüm. n<=6 ise ve bütçe izin veriyorsa birden fazla mirror vdev kullanırdım. Üretim ortamında farklı RAID seçeneklerinin okuma/yazma performans metriklerini daha fazla araştırmak gerekir.

    • Mirror pool genelde gerçekten daha güvenli yöntemdir.
      Ancak tüm sahayı kapsayan bir yedeğiniz varsa ve kendi becerinize ve izleme sisteminize epey güvenebiliyorsanız RAIDZ1’i önerebilirim.
      Benim durumumda 3x3 sürücülü bir pool’um var ve snapshot’ları rack’te birkaç U aşağıdaki yedekleme hedefine gönderiyorum. Bu yedekleme hedefi her gün uyanıyor, 3x4 sürücülü bir pool’a sahip ve o da RAIDZ1 kullanıyor.
      NAS’ta bir sürücü arızalanırsa planım hemen yedeği başlatıp snapshot’ları kabul ettirmek, ardından sürücüyü değiştirmek. Böylece resilvering sırasında ikinci bir sürücü arızasıyla verilerin uçması olasılığı en aza iner.
      Gerçekten önemli veriler elbette dışarıda da duruyor.

  • Anlamadığım bir ZFS sorunu yaşıyorum. Bir zpool’da zpool status algılanan hata listesini yazdırıyor; ancak bunlar dosyalarda değil, her zaman snapshot’larda ve muhtemelen silinmiş snapshot’lara ait gibi görünen onaltılık girdilerde çıkıyor.
    Hatalı olarak işaretlenen snapshot’ları silip zpool scrub’ı iki kez çalıştırınca hatalar kayboluyor ve scrub da hata bulmuyor. zpool status hiçbir cihazda hiç hata göstermedi.
    Dosyalarda hata yok, cihazlarda hata yok, scrub’da da hata algılanmıyor; ama çalışırken zpool status içinde günde 12 yeni “hata” beliriyor. Bunun nasıl olabildiğini bilmiyorum.

    • Gerçekten iyi soru. Şu an bizzat yinelenen bir issue aramaya vaktim yok, ama mailing list’e https://zfsonlinux.topicbox.com/groups/zfs-discuss ve GitHub issue’larına https://github.com/openzfs/zfs/issues bakabilir ya da oralarda sorabilirsiniz.
      İlki garip görünüyor ama mailing list’in normal web arayüzü.
    • Aynı sorunu yaşıyorum. Bazen dosya yalnızca snapshot’ta değil, güncel dosya sürümünde de bozulmuş gibi görünüyor.
      Taşınamıyor veya değiştirilemiyor, yalnızca silinebiliyor. Bu dosyaların neden bozulduğuna dair hiçbir ipucum yok. Neyse ki hepsi büyük Linux ISO’larıydı, bu yüzden ölümcül olmadı.