Proxmox'ta ZFS Depolama Yapılandırması

Proxmox kurulumunda disk düzenini seçerken karşınıza çıkan zfs (RAID1) seçeneğine tıklayıp geçtiyseniz, aslında altyapınızın en belirleyici kararlarından birini birkaç saniyede vermişsiniz demektir. ZFS, sıradan bir dosya sistemi değil; birim yöneticisi, RAID katmanı, anlık görüntü motoru ve bütünlük denetleyicisi aynı anda. Doğru yapılandırıldığında sessiz veri bozulmasını yakalar, saniyeler içinde geri dönüş noktası verir ve diskleri şeffaf biçimde sıkıştırır. Yanlış yapılandırıldığında ise sunucunuzun RAM'ini yer, yazma performansını yerle bir eder ve sebebi anlaşılmayan yavaşlıklar üretir.

Bu rehberde Proxmox üzerinde ZFS'i üretime uygun biçimde nasıl kuracağınızı anlatacağım: havuz düzeni seçimi ve neyin ne kadar kapasite ile ne kadar dayanıklılık verdiği, kurulumda geri dönülemez olan ashift değeri, ARC bellek sınırının neden mutlaka ayarlanması gerektiği, sıkıştırma ve volblocksize kararları, anlık görüntü yönetimi ve düzenli bakım. Aralarda gerçek komutlar ve gerçek çıktılar olacak; çünkü ZFS'te en pahalı hatalar kurulum anında yapılıp aylar sonra fark edilir.

ZFS Havuz Düzenleri ve Doğru Seçim#

ZFS'te veri bir havuz (pool) içinde saklanır, havuz da bir veya birden fazla vdev'den oluşur. Kritik nokta şudur: havuzun dayanıklılığı vdev'lerin dayanıklılığına bağlıdır ve bir vdev kaybedilirse tüm havuz kaybedilir. Yani beş vdev'li bir havuzda tek bir vdev'in tüm diskleri arızalanırsa, diğer dört vdev'deki veriye de erişemezsiniz. Bu, ZFS'e yeni başlayanların en pahalıya mal olan yanlış anlamasıdır.

Düzenleri karşılaştıralım:

Buradaki en önemli satır rastgele IOPS sütunudur. Bir RAIDZ vdev'i, kaç diskten oluşursa oluşsun, rastgele okuma/yazmada yaklaşık tek bir diskin IOPS'unu verir; çünkü her okuma tüm şeridi dokundurur. Sanal makine diskleri tam olarak rastgele iş yüküdür. Bu yüzden hipervizör üzerinde VM barındıracaksanız aynalı çiftlerden oluşan bir havuz, aynı disk sayısındaki bir RAIDZ2'den kat kat daha iyi performans verir — kapasitenin yarısını kaybetseniz bile.

RAIDZ'yi yedek hedefi, medya arşivi ve ardışık erişimli büyük dosyalar için saklayın. Proxmox Backup Server datastore'u bunun tipik örneğidir; ayrıntısını Proxmox Backup Server kurulumu yazısında ele aldım.

Havuz Oluşturma ve ashift Tuzağı#

Havuz oluştururken vereceğiniz ashift değeri, ZFS'in disk üzerinde kullanacağı en küçük blok boyutunun ikinin kuvveti olarak üssüdür: ashift=12 yani 4 KiB, ashift=9 yani 512 bayt. Bu değer havuz oluşturulduktan sonra değiştirilemez; değiştirmek isterseniz havuzu silip yeniden kurmanız gerekir.

Tuzak şudur: bazı diskler geriye uyumluluk için kendini 512 baytlık sektörlere sahipmiş gibi tanıtır (512e diskler), fiziksel sektörleri ise 4 KiB'dır. ZFS otomatik algılamaya bırakılırsa ashift=9 seçer ve her 4 KiB yazma için disk okuma-değiştirme-yazma döngüsüne girer. Sonuç, yazma performansının kat kat düşmesidir ve bu düşüşün sebebini aylar sonra bulmak neredeyse imkânsızdır. Bu yüzden modern disklerde her zaman ashift=12 verin.

# Disklerin kalıcı isimlerini öğren (asla /dev/sdb kullanma, isimler açılışta değişir)
ls -l /dev/disk/by-id/ | grep -v part

# Aynalı çiftlerden oluşan havuz — VM diskleri için önerilen düzen
zpool create -f -o ashift=12 vmpool \
  mirror /dev/disk/by-id/ata-DISK1 /dev/disk/by-id/ata-DISK2 \
  mirror /dev/disk/by-id/ata-DISK3 /dev/disk/by-id/ata-DISK4

# RAIDZ2 havuz — yedek/arşiv için
zpool create -f -o ashift=12 arsivpool \
  raidz2 /dev/disk/by-id/ata-DISK5 /dev/disk/by-id/ata-DISK6 \
         /dev/disk/by-id/ata-DISK7 /dev/disk/by-id/ata-DISK8

# Kontrol et
zpool status vmpool
zpool get ashift vmpool

Diskleri her zaman /dev/disk/by-id/ altındaki kalıcı isimlerle verin. /dev/sdb gibi isimler açılıştan açılışa değişebilir; havuz açılışta diski bulamazsa DEGRADED durumuna düşer ve gereksiz yere paniğe kapılırsınız.

Havuzu oluşturduktan sonra Proxmox'a tanıtın:

# Küme genelinde ZFS depolaması olarak ekle
pvesm add zfspool vm-zfs --pool vmpool --content images,rootdir --sparse 1

# Yalnızca belirli düğümlerde varsa nodes ile sınırla
pvesm set vm-zfs --nodes pve1,pve2

pvesm status | grep vm-zfs

--sparse 1 ince tahsis (thin provisioning) açar: sanal disk oluşturduğunuzda alan hemen ayrılmaz, kullanıldıkça büyür. Kullanışlıdır ama havuzun dolmasını izlemenizi zorunlu kılar.

ARC Bellek Sınırı — Atlanmaması Gereken Ayar#

ZFS, okuma önbelleği olarak ARC (Adaptive Replacement Cache) kullanır ve varsayılan olarak sistem belleğinin önemli bir kısmını almaya eğilimlidir. Normal bir dosya sunucusunda bu iyidir; bir hipervizörde ise felakettir. Çünkü hipervizörde RAM sanal makinelere tahsis edilmiştir ve ARC'ın büyümesi ile VM'lerin bellek talebi doğrudan çakışır. ARC teoride baskı altında küçülür ama bu küçülme her zaman yeterince hızlı olmaz; sonuç, sanal makinelerin takasa düşmesi ve açıklanamayan yavaşlıklardır.

Bu yüzden Proxmox üzerinde ARC'a mutlaka açık bir tavan koyun. Pratik bir başlangıç kuralı: toplam RAM'in dörtte biri, en fazla 16 GiB civarı. Havuz büyüdükçe biraz artırabilirsiniz.

# /etc/modprobe.d/zfs.conf — değerler BAYT cinsindendir
# 8 GiB tavan, 2 GiB taban
options zfs zfs_arc_max=8589934592
options zfs zfs_arc_min=2147483648

Değişikliğin açılışta uygulanması için initramfs'i güncelleyip yeniden başlatın:

update-initramfs -u -k all
reboot

# Yeniden başlatmadan geçici olarak uygulamak için
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max

# Mevcut ARC durumunu izle
arc_summary | head -30
cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|hits|misses) '

arc_summary çıktısındaki hit oranı en değerli göstergedir. Oran yüzde 90'ların üzerindeyse ARC işini yapıyordur; yüzde 60'ların altındaysa ya ARC çok küçüktür ya da iş yükünüz önbelleğe uygun değildir. Bellek kullanımını genel olarak takip etmek için diğer araçlara da bakabilirsiniz; disk tarafı için disk kullanımı: df, du ve ncdu yazısı işinize yarar.

Sıkıştırma, volblocksize ve Diğer Özellikler#

ZFS'te sıkıştırma varsayılan olarak açılmalıdır ve bu sezgiye aykırı gelebilir. lz4 ve zstd o kadar hızlıdır ki, sıkıştırılabilir veride disk üzerinde daha az blok okumak/yazmak, sıkıştırma için harcanan CPU'dan daha fazla kazandırır. Yani sıkıştırma çoğu zaman performansı artırır.

# Havuz genelinde sıkıştırma (yeni yazılan verilere uygulanır)
zfs set compression=lz4 vmpool

# Daha iyi oran, biraz daha fazla CPU
zfs set compression=zstd vmpool

# Erişim zamanı yazmayı kapat — gereksiz yazma üretir
zfs set atime=off vmpool

# Gerçek kazancı ölç
zfs get compressratio vmpool
# Örnek çıktı: vmpool  compressratio  1.48x  -

volblocksize ayarı sanal makine diskleri (zvol) için kritiktir ve zvol oluşturulduktan sonra değiştirilemez. Çok küçük seçerseniz metadata yükü artar; çok büyük seçerseniz her küçük yazma için koca bir blok okunup yeniden yazılır (yazma büyütmesi, write amplification). Genel amaçlı iş yükleri için 16K makul bir orta yoldur; veritabanı yoğun sistemlerde veritabanının kendi sayfa boyutuna yaklaştırmak mantıklıdır.

# Proxmox depolama tanımında blok boyutu
pvesm set vm-zfs --blocksize 16k

Üzerinde dikkat edilmesi gereken bir diğer özellik sync davranışıdır. sync=disabled yazma performansını dramatik biçimde artırır ama elektrik kesintisinde son saniyelerin verisini kaybetme riskini kabul etmiş olursunuz. Üretim veritabanı barındıran bir havuzda bunu açmayın. Gerçekten senkron yazma performansına ihtiyacınız varsa doğru çözüm, güç kaybı korumalı bir SSD'yi SLOG olarak eklemektir.

dedup özelliğini açma isteğine direnin. ZFS tekilleştirmesi tüm tekilleştirme tablosunu bellekte tutar; birkaç terabaytlık bir havuzda bu onlarca gigabayt RAM demektir. Kazancı neredeyse hiçbir zaman bu maliyeti karşılamaz.

Snapshot, Klon ve Geri Dönüş#

ZFS anlık görüntüleri copy-on-write mimarisi sayesinde neredeyse anlık ve neredeyse bedavadır: oluşturma anında hiç yer kaplamazlar, yalnızca veri değiştikçe eski bloklar tutuldukça büyürler. Bu, bir güncelleme öncesi geri dönüş noktası almanın en ucuz yoludur.

# Proxmox üzerinden bir VM için anlık görüntü (VM ayarlarını da kaydeder)
qm snapshot 101 guncelleme-oncesi --description "Kernel yukseltmesi oncesi"

# Doğrudan ZFS düzeyinde
zfs snapshot vmpool/vm-101-disk-0@guncelleme-oncesi

# Listele ve ne kadar yer kapladığını gör
zfs list -t snapshot -o name,used,refer -s creation

# Geri dön (DİKKAT: snapshot'tan SONRAKİ tüm değişiklikler kaybolur)
qm rollback 101 guncelleme-oncesi

# Sil
qm delsnapshot 101 guncelleme-oncesi
zfs destroy vmpool/vm-101-disk-0@guncelleme-oncesi

Buradaki en kritik uyarı şudur: anlık görüntü yedek değildir. Havuz ölürse anlık görüntüler de ölür; disk arızası, denetleyici arızası ya da yanlışlıkla zpool destroy çalıştırmak hepsini birlikte götürür. Anlık görüntüyü "on dakika önceki hâle dönebilme" aracı olarak kullanın, felaket kurtarma planı olarak değil. Gerçek yedekleme için Proxmox yedekleme ve geri yükleme yazısındaki kurguyu uygulayın.

ZFS'in send/receive yeteneği ise gerçek bir yedekleme aracıdır: bir havuzdaki anlık görüntüyü başka bir makinedeki havuza artımlı olarak aktarabilirsiniz.

# İlk tam gönderim
zfs send vmpool/vm-101-disk-0@gun1 | ssh [email protected] zfs recv yedekpool/vm-101

# Sonraki günler yalnızca farkı gönder
zfs send -i @gun1 vmpool/vm-101-disk-0@gun2 | ssh [email protected] zfs recv yedekpool/vm-101

Bakım: Scrub, SMART ve Havuz Doluluğu#

ZFS her okuma sırasında blokların sağlama toplamını doğrular ve bozulma bulursa yedekli bir kopyadan otomatik onarır. Ancak nadiren okunan veriler için bu yeterli değildir; bu yüzden düzenli scrub çalıştırılır. Scrub, havuzdaki tüm blokları baştan sona okuyup doğrular ve bozulmayı fark edilmeden önce yakalar.

Proxmox varsayılan olarak ayın ikinci pazarı scrub çalıştıran bir cron girdisiyle gelir. Yine de durumu düzenli kontrol edin:

# Elle scrub başlat
zpool scrub vmpool

# İlerlemeyi ve sonucu gör
zpool status -v vmpool

# Örnek sağlıklı çıktı:
#   pool: vmpool
#  state: ONLINE
#   scan: scrub repaired 0B in 01:12:44 with 0 errors on Sun Aug 10 03:12:44 2026

# Hata sayaçları — hepsi 0 olmalı
zpool status | grep -E 'READ|WRITE|CKSUM' -A3

CKSUM sütununda sıfırdan farklı bir sayı görüyorsanız o diskte sessiz bozulma var demektir; disk henüz "arızalı" görünmese bile değiştirmeyi planlayın. Disk sağlığını ayrıca SMART ile izleyin — konuyu disk arızası tespiti: SMART ve RAID yazısında ayrıntılı ele aldım.

Bir diski değiştirmeniz gerekirse işlem şöyledir:

# Arızalı diski çevrimdışına al
zpool offline vmpool /dev/disk/by-id/ata-DISK2

# Fiziksel değişimden sonra yenisiyle değiştir
zpool replace vmpool /dev/disk/by-id/ata-DISK2 /dev/disk/by-id/ata-YENIDISK

# Yeniden yapılanmayı (resilver) izle
zpool status vmpool

Son olarak havuz doluluğunu izlemek ZFS'te ihmal edilemez bir iştir. Copy-on-write mimarisi yüzünden havuz doldukça yeni blok bulmak zorlaşır ve performans belirgin biçimde düşer. Havuzu kalıcı olarak yüzde 80'in altında tutmayı hedefleyin; yüzde 90'ı geçtiğinizde yavaşlama hissedilir hâle gelir.

zpool list
# NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH
# vmpool  3.62T  1.81T  1.81T        -         -    12%    50%  1.00x  ONLINE

# Hangi veri kümesi ne kadar yer kaplıyor
zfs list -o name,used,avail,refer,compressratio

FRAG sütunu parçalanma oranını gösterir; yüksek doluluk ve yüksek parçalanma birlikte görülüyorsa alan açmanın zamanı gelmiştir. Havuz doldu ve silecek yer bulamıyorsanız, çoğu zaman suçlu unutulmuş eski anlık görüntülerdir.

Sıkça Sorulan Sorular#

Proxmox için ZFS mi LVM-thin mi kullanmalıyım#

ZFS, sağlama toplamı, sıkıştırma, anlık görüntü ve yazılımsal RAID'i tek pakette verir; donanımsal RAID kartına ihtiyaç duymaz ve sessiz veri bozulmasını yakalar. LVM-thin ise daha az RAM tüketir ve daha basittir. Yeterli RAM'iniz varsa (en az 16 GB ve üzeri) ZFS'i tercih edin; RAM'i kısıtlı küçük sunucularda LVM-thin daha uygun bir seçim olur.

ZFS için ne kadar RAM gerekir#

İnternette dolaşan "her TB için 1 GB RAM" kuralı esasen tekilleştirme kullanan kurulumlar içindir ve dedup kapalıyken abartılıdır. Dedup kapalı bir hipervizörde ARC'a ayırdığınız kadar RAM yeterlidir; 8 GiB'lık bir ARC tavanı çoğu orta ölçekli kurulumu rahatça taşır. Asıl önemli olan miktar değil, ARC'a açık bir tavan koyup sanal makinelerin belleğiyle çakışmasını engellemektir.

ZFS havuzuna sonradan disk ekleyebilir miyim#

Havuza yeni bir vdev ekleyerek kapasiteyi büyütebilirsiniz; örneğin aynalı çiftlerden oluşan bir havuza yeni bir aynalı çift eklemek son derece yaygın bir genişletme yöntemidir. Mevcut bir vdev'e disk ekleyerek genişletmek ise düzene göre kısıtlıdır ve mirror ile RAIDZ'de farklı davranır. Bu yüzden havuz düzenini baştan büyüme planınıza göre seçin.

ashift değerini sonradan değiştirebilir miyim#

Hayır. ashift havuz oluşturma anında sabitlenir ve değiştirilemez; değiştirmek isterseniz veriyi başka yere taşıyıp havuzu silip yeniden oluşturmanız gerekir. Bu yüzden modern disklerde her zaman ashift=12 vererek havuz kurun. Yanlış değerle kurulmuş bir havuzu zpool get ashift ile tespit edebilirsiniz.

ZFS snapshot yedek yerine geçer mi#

Hayır. Anlık görüntüler aynı havuz üzerinde durur; disk arızası, denetleyici arızası ya da havuzun yanlışlıkla silinmesi durumunda verilerle birlikte kaybolurlar. Anlık görüntüyü kısa vadeli geri dönüş noktası olarak kullanın, felaket kurtarma için ayrıca farklı bir hedefe yedek alın. zfs send ile başka bir makineye artımlı aktarım yapmak, snapshot'ı gerçek bir yedeğe dönüştürmenin yoludur.

ZFS havuzum yavaşladı, ilk neye bakmalıyım#

Sırasıyla üç şeye bakın: havuz doluluğu (zpool list çıktısındaki CAP yüzde 80'i geçtiyse performans düşer), ARC hit oranı (arc_summary ile; düşükse ARC tavanı fazla kısıtlıdır) ve havuz düzeni (RAIDZ üzerinde rastgele VM iş yükü çalıştırıyorsanız IOPS zaten tek disk kadardır). Bu üçü çoğu yavaşlık şikayetinin kaynağıdır; dördüncü şüpheli ise unutulmuş eski anlık görüntülerin biriktirdiği alandır.

Kapanış#

ZFS, Proxmox altyapınıza bütünlük garantisi, ucuz anlık görüntüler ve donanım RAID'ine ihtiyaç duymayan bir depolama katmanı kazandırır — ama kurulum anındaki birkaç karar, sonraki yıllarda yaşayacaklarınızı belirler. Aklınızda kalması gerekenler: havuzu her zaman ashift=12 ile ve kalıcı disk isimleriyle kurun, VM iş yükü için aynalı çiftleri RAIDZ'ye tercih edin, ARC'a mutlaka açık bir tavan koyun ve havuz doluluğunu yüzde 80'in altında tutun. Düzenli scrub'ı da unutmayın; sessiz bozulmayı yakalamanın başka bir yolu yok.

Depolamayı tek bir sunucunun ötesine taşımak, birden fazla düğüm arasında paylaşımlı ve dayanıklı bir katman kurmak isterseniz bir sonraki durak Proxmox'ta Ceph ile dağıtık depolama olmalı. Kendi ZFS havuzunuzu kuracağınız donanım arıyorsanız dedicated sunucu ve colocation seçeneklerimize, hazır kaynak isterseniz VDS paketlerimize göz atabilir; depolama ve yedekleme işletimini devretmek isterseniz sunucu yönetimi ile yedekleme hizmetlerimizden yararlanabilirsiniz.