Proxmox LVM, ZFS ve Ceph Karşılaştırması

Proxmox ortamında depolama seçimi, tüm sanallaştırma altyapınızın performansını, güvenilirliğini ve yönetilebilirliğini doğrudan etkileyen kritik bir karardır. Yanlış seçim, ileride veri kaybına, performans sorunlarına ya da yönetim karmaşıklığına yol açabilir. Bu yazıda LVM, ZFS ve Ceph’i gerçek dünya senaryoları üzerinden karşılaştırarak hangi durumda hangisini tercih etmeniz gerektiğini ele alacağız.

LVM: Sade, Güvenilir, Savaşta Test Edilmiş

LVM (Logical Volume Manager), Linux dünyasında onlarca yıldır kullanılan ve Proxmox’un varsayılan kurulum seçeneği olarak gelen depolama çözümüdür. Tek sunucu ortamları için hâlâ güçlü bir tercih olmaya devam etmektedir.

LVM Nasıl Çalışır?

LVM, fiziksel diskleri (Physical Volume – PV) mantıksal gruplara (Volume Group – VG) toplar ve buradan mantıksal birimler (Logical Volume – LV) oluşturur. Proxmox bu LV’leri doğrudan VM disk imajı olarak kullanır.

Proxmox’ta mevcut LVM yapınızı kontrol etmek için:

pvs
vgs
lvs
pvdisplay /dev/sda3
vgdisplay pve

Yeni bir fiziksel diski mevcut volume group’a eklemek oldukça basittir:

# Yeni diski PV olarak işaretle
pvcreate /dev/sdb

# Mevcut VG'ye ekle
vgextend pve /dev/sdb

# VG boyutunu kontrol et
vgdisplay pve | grep "VG Size"

LVM-Thin: Ince Provizyon ile Verimlilik

Proxmox kurulumunda önerilen mod olan LVM-Thin, disk alanını gerçekten kullanıldıkça tahsis eder. Bu sayede örneğin 1 TB’lık bir havuza 2 TB değerinde disk tanımlayabilirsiniz, tabii gerçek kullanım aşmadığı sürece.

# Thin pool oluşturma
lvcreate --thinpool pve/data -L 500G

# Thin volume oluşturma
lvcreate --thin pve/data -V 100G -n vm-100-disk-0

# Mevcut thin pool'ların durumunu görme
lvs -a -o name,size,pool_lv,data_percent,metadata_percent pve

LVM’in Gerçek Dünya Performansı

LVM, doğrudan blok cihaz erişimi sağladığı için overhead’i minimumdur. Özellikle database VM’leri, yüksek I/O gerektiren workload’lar ve latency’nin kritik olduğu senaryolarda LVM tercih edilir. Tek sunuculuk bir Proxmox ortamında, örneğin küçük bir şirketin 10-15 VM çalıştırdığı bir kurulumda LVM mükemmel iş görür.

LVM’in güçlü yanları:

Düşük CPU overhead, native performans
Tüm Linux sistemlerde standart araçlarla yönetim
Snapshot desteği (LVM-Thin ile)
Proxmox GUI’den tam destek
Tek sunucu için ideal sadelik

LVM’in zayıf yanları:

Yerleşik RAID veya replikasyon yok
Veri bütünlüğü kontrolü (checksum) yok
Birden fazla sunucuya ölçeklenemiyor
Snapshot performansı ZFS’e göre zayıf

ZFS: Akıllı Dosya Sistemi, Güçlü Veri Koruma

ZFS, Sun Microsystems tarafından geliştirilen ve “son dosya sistemi” olarak pazarlanan köklü bir teknolojidir. Proxmox, ZFS’i çekirdek seviyesinde destekler ve kurulum sırasında sistem diskini bile ZFS üzerine kurabilirsiniz.

ZFS’in Temel Kavramları

ZFS’de diskler “pool” (zpool) adı verilen yapılarda bir araya gelir. Her pool üzerinde “dataset” oluşturulur ve bu dataset’ler dosya sistemi olarak mount edilir. Copy-on-write (CoW) mimarisi sayesinde veri her zaman tutarlı bir durumda kalır.

# Yeni bir ZFS pool oluşturma (RAIDZ1 ile 3 disk)
zpool create -f tank raidz /dev/sdb /dev/sdc /dev/sdd

# Pool durumunu kontrol etme
zpool status
zpool status -v tank

# Pool istatistiklerini görme
zpool list
zfs list

ZFS ile Proxmox Entegrasyonu

Proxmox, ZFS pool’larını storage olarak tanımak için GUI veya CLI kullanabilir:

# Proxmox'a ZFS storage eklemek için (GUI'nin yaptığı)
# /etc/pve/storage.cfg dosyasına eklenir:
# zfspool: local-zfs
#       pool pve/data
#       sparse
#       content rootdir,images

# ZFS dataset üzerinde VM diski oluşturma
zfs create tank/vm-disks

# Snapshot alma - anlık, kopya gerektirmez
zfs snapshot tank/vm-100-disk-0@before-update

# Snapshot listesi
zfs list -t snapshot

# Snapshot'tan geri dönme
zfs rollback tank/vm-100-disk-0@before-update

ZFS ARC ve Önbellekleme

ZFS’in en güçlü özelliklerinden biri, RAM’i akıllıca önbellek olarak kullanmasıdır. ARC (Adaptive Replacement Cache) sayesinde sık okunan veriler bellekte tutulur ve disk okuma operasyonları dramatik şekilde azalır.

# ARC istatistiklerini görme
arc_summary
# veya
cat /proc/spl/kstat/zfs/arcstats | grep -E "hits|misses|size"

# ARC maksimum boyutunu sınırlandırma (ZFS bazen çok RAM yer)
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
# 8589934592 = 8 GB

# L2ARC için SSD ekleme (ikinci seviye önbellek)
zpool add tank cache /dev/sde

Önemli not: ZFS, RAM konusunda açgözlüdür. 32 GB RAM’li bir sunucuda ZFS pool’u büyüdükçe ARC 16-18 GB RAM tüketebilir. Bu nedenle Proxmox + ZFS kombinasyonunda en az 32 GB, tercihen 64 GB RAM önerilir. Üretim ortamında bunu göz ardı edip karşılaştığım birçok “neden sunucu yavaşladı” vakası var.

ZFS RAIDZ Seviyeleri

# RAIDZ1 - tek disk arızasına dayanır (RAID5 benzeri)
zpool create tank raidz /dev/sdb /dev/sdc /dev/sdd

# RAIDZ2 - iki disk arızasına dayanır (RAID6 benzeri)
zpool create tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Mirror (RAID1 benzeri)
zpool create tank mirror /dev/sdb /dev/sdc

# Pool'a scrub başlatma (veri bütünlüğü kontrolü)
zpool scrub tank

# Scrub durumunu izleme
zpool status tank | grep scan

ZFS’in güçlü yanları:

Yerleşik veri bütünlüğü (checksum ile her blok doğrulanır)
Hızlı ve disk alanı tüketmeyen snapshot’lar
Copy-on-write mimarisi ile güvenli yazma
Yerleşik sıkıştırma (lz4, zstd) ve tekilleştirme
RAIDZ ile tek kutu içinde yedeklilik
Proxmox ile derin entegrasyon

ZFS’in zayıf yanları:

Yüksek RAM tüketimi
RAIDZ’den genişletme karmaşık (yeni disk ekleme sınırlı)
Çok düğümlü dağıtık kullanım için tasarlanmamış
CPU kullanımı LVM’e göre yüksek (özellikle sıkıştırma/checksum açıkken)

Ceph: Dağıtık Depolama, Kurumsal Ölçek

Ceph, Proxmox Cluster ortamlarında paylaşımlı depolama sağlamak için en güçlü seçenektir. Birden fazla sunucunun aynı storage’a erişmesini ve VM’lerin sunucular arasında live migrate edilmesini sağlar. Ancak bu güç, ciddi bir kurulum ve yönetim karmaşıklığı ile gelir.

Ceph Mimarisi

Ceph’in üç temel bileşeni vardır:

MON (Monitor): Cluster haritasını ve durumunu takip eder. Quorum için en az 3 MON gerekir.

OSD (Object Storage Daemon): Her disk için bir OSD çalışır, gerçek veriyi depolar.

MGR (Manager): İzleme ve yönetim arayüzü sağlar.

Proxmox’ta Ceph Kurulumu

Proxmox, Ceph kurulumunu GUI üzerinden dramatik şekilde kolaylaştırmıştır. Ama CLI’dan da yönetebilmek önemlidir:

# Proxmox üzerinde Ceph kurulumu
pveceph install --version reef

# MON oluşturma (her node'da çalıştır)
pveceph mon create

# MGR oluşturma
pveceph mgr create

# OSD oluşturma (her node'daki her disk için)
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Ceph cluster durumu
ceph status
ceph osd tree
ceph df

Ceph Pool ve Replikasyon Ayarları

# Yeni bir pool oluşturma (3x replikasyon)
ceph osd pool create vmdata 128
ceph osd pool set vmdata size 3
ceph osd pool set vmdata min_size 2

# Pool istatistikleri
ceph osd pool stats vmdata

# Ceph cluster'ı Proxmox storage olarak eklemek için
# /etc/pve/storage.cfg içine:
# rbd: ceph-store
#       monhost 192.168.1.10 192.168.1.11 192.168.1.12
#       content images,rootdir
#       pool vmdata
#       username admin

# RBD imaj listesi
rbd ls vmdata

# RBD imaj detayları
rbd info vmdata/vm-100-disk-0

Ceph Ağ Gereksinimleri

Ceph için iki ayrı ağ kullanmak neredeyse zorunludur:

# Ceph public network (client erişimi)
# /etc/ceph/ceph.conf içinde:
# [global]
# public_network = 192.168.1.0/24
# cluster_network = 10.10.0.0/24

# Cluster ağ durumunu kontrol etme
ceph config get mon public_network
ceph config get osd cluster_network

# OSD performans istatistikleri
ceph osd perf
ceph osd df tree

Gerçek dünya notu: Ceph’i 3 node’lu bir homelab cluster’ında kurmak için her node’da en az 32 GB RAM ve 10 GbE ağ bağlantısı gereklidir. Public network ve cluster network için ayrı NIC veya VLAN kullanmayan bir Ceph kurulumu, production’da ciddi performans sorunları yaşatır. Bunu atlayarak kurduğumuz bir ortamda replication traffic’i VM ağını boğmuş ve tüm VM’ler yavaşlamıştı.

Ceph’in güçlü yanları:

Gerçek dağıtık mimari, tek nokta arızası yok
Cluster genelinde live migration desteği
Sonsuz yatay ölçeklenebilirlik
Self-healing: bozuk veriyi otomatik onarır
Proxmox cluster ile mükemmel entegrasyon
HA (High Availability) için ideal altyapı

Ceph’in zayıf yanları:

Minimum 3 sunucu gerektirir
Yüksek RAM ve ağ gereksinimleri
Kurulum ve sorun giderme karmaşıklığı
Yüksek replikasyon overhead’i (3x storage gerekir)
Single node performansı LVM/ZFS’e göre düşük olabilir

Hangi Senaryoda Hangisini Kullanmalısınız?

Senaryo 1: Küçük Şirket, Tek Sunucu

Elinizde tek bir güçlü sunucu var, 10-20 VM çalıştıracaksınız ve bütçe kısıtlı. Bu durumda en mantıklı seçenek LVM-Thin veya ZFS‘tir.

Veri bütünlüğünü ve snapshot yönetimini önemsiyorsanız ZFS, sadelik ve maksimum performans istiyorsanız LVM-Thin tercih edin. ZFS’i seçerseniz RAIDZ1 veya mirror konfigürasyonu ile disk arızasına karşı korunun.

Senaryo 2: Orta Ölçekli Şirket, 2-3 Sunucu Cluster

Live migration ve HA istiyorsunuz ama tam Ceph kapasitesine gerek yok. Bu durumda ZFS ile Proxmox replikasyonu iyi bir orta yol olabilir.

# Proxmox replikasyonu yapılandırma (ZFS gerektirir)
pvesr create-local-job 100 node2 --schedule "*/15" --rate 50

# Replikasyon durumunu izleme
pvesr status

# Manuel replikasyon tetikleme
pvesr run 100-0

ZFS replikasyonu, tam Ceph gibi gerçek zamanlı paylaşımlı storage sağlamaz ama VM’lerin periyodik olarak diğer node’a kopyalanmasını sağlar. Downtime kabul edilebilirse uygun maliyetli bir çözümdür.

Senaryo 3: Büyük Ortam, Full HA Gereksinimi

Üç veya daha fazla sunucunuz var, sıfır downtime istiyorsunuz ve VM’lerin otomatik olarak başka node’lara taşınmasını istiyorsunuz. Bu durumda Ceph kaçınılmazdır.

# HA grubu oluşturma
ha-manager groupadd ha-group-1 --nodes node1,node2,node3

# VM'i HA'ya kaydetme
ha-manager add vm:100 --group ha-group-1 --max_restart 3

# HA durumunu izleme
ha-manager status

Depolama Performansı Optimizasyon İpuçları

Her üç seçenek için de uygulayabileceğiniz pratik optimizasyonlar:

# LVM için I/O scheduler optimizasyonu (NVMe diskler için)
echo none > /sys/block/nvme0n1/queue/scheduler

# ZFS için sıkıştırmayı etkinleştirme (lz4 performans kaybı minimumdur)
zfs set compression=lz4 tank
zfs get compression tank

# ZFS atime kapatma (gereksiz yazmaları önler)
zfs set atime=off tank

# Ceph OSD journal/WAL için SSD kullanma
pveceph osd create /dev/sdb --wal-dev /dev/nvme0n1p1 --db-dev /dev/nvme0n1p2

# Ceph okuma performansını izleme
ceph osd pool stats vmdata
rados bench -p vmdata 10 write --no-cleanup
rados bench -p vmdata 10 seq

İzleme ve Bakım

Üç sistemin de düzenli bakım gerektirdiğini unutmayın:

# LVM - disk alanı kullanımını izle
lvs -o +devices,seg_count pve

# ZFS - haftalık scrub için cron job
echo "0 2 * * 0 root /sbin/zpool scrub tank" >> /etc/cron.d/zfs-scrub

# ZFS pool sağlık kontrolü
zpool status -x

# Ceph - cluster sağlık özeti
ceph health detail
ceph osd stat
watch -n 5 ceph -s

Maliyet ve Kaynak Karşılaştırması

LVM için kaynak gereksinimleri:

RAM: VM’lerin ihtiyacı kadar, ekstra overhead yok
CPU: Minimum, native block I/O
Disk: İhtiyaç duyulan kadar
Network: VM trafiği için yeterli

ZFS için kaynak gereksinimleri:

RAM: En az 1 GB her TB storage için, ARC için ekstra RAM önerilir
CPU: Orta-yüksek (checksum, sıkıştırma için)
Disk: RAIDZ1 için N+1, RAIDZ2 için N+2 disk
ECC RAM: Üretim ortamında şiddetle tavsiye edilir

Ceph için kaynak gereksinimleri:

RAM: Her OSD için 4-8 GB önerilir
CPU: Her OSD için 2 core önerilir
Disk: Veri * replikasyon sayısı (3x replikasyon = 3x storage)
Network: Her node için 10 GbE, public ve cluster ayrı

Sonuç

Proxmox ortamında depolama seçimi “en iyi” diye bir cevabı olmayan, duruma göre değişen bir karardır. Genel kural olarak şunu söyleyebilirim: başlangıçta sade tutun, ihtiyaç arttıkça ölçeklendirin.

Tek sunucuyla başlayan bir ortam için LVM-Thin mükemmel bir başlangıç noktasıdır. Veri güvenliği ve snapshot yönetimi önceliğinizse ZFS’e geçin. Birden fazla sunucuya ölçeklenip HA gereksinimi ortaya çıktığında Ceph’i devreye alın.

Ama asıl tehlikeli olan, gereksinimleri analiz etmeden Ceph’e atlamaktır. Üç node’un altındaki ortamlarda Ceph kurmanın getirdiği yönetim yükü ve kaynak maliyeti, sağladığı faydaların çok üstüne çıkabilir. Benim tavsiyem: production’a almadan önce her üç çözümü de bir test ortamında kurun, yük testleri yapın ve sistemi nasıl yöneteceğinizi öğrenin. Depolama sorunları gece saat 2’de patlarsa, hangi araçlara ihtiyacınız olduğunu o an değil önceden bilmeniz gerekir.