Proxmox VE (veya saf KVM/QEMU) kurulumunu tamamlayıp ilk sanal makinelerinizi ayağa kaldırdığınızda her şey kusursuz görünür. Ancak küme üzerine yoğun транzaksiyon üreten veritabanları (PostgreSQL, Percona MySQL) veya yüksek log/indeksleme trafiği (OpenSearch/Elasticsearch) bindiğinde, varsayılan ZFS ve Ceph parametreleri hızla darboğaza girer. Yükselen CPU iowait değerleri, kilitlenen VM konsolları ve beklentinin çok altında kalan IOPS rakamları genellikle donanım yetersizliğinden değil, yazılım tanımlı depolama (SDS) katmanındaki hizalama ve önbellek uyumsuzluklarından kaynaklanır.
Bugünkü yazımızda, kurumsal Proxmox VE ve KVM kümelerinde hem ZFS hem de Ceph katmanından donanımın gerçek limitlerini nasıl alacağımızı adım adım inceliyoruz.
1. ZFS Optimizasyonu: Yazma Yükseltmesini (Write Amplification) Durdurmak
ZFS, veri bütünlüğü (Copy-on-Write) konusunda rakipsizdir ancak yanlış yapılandırıldığında 4KB’lık tek bir veritabanı yazma işlemini diske 64KB veya 128KB olarak yazarak disk ömrünü ve IOPS kapasitesini eritebilir.
A. ashift ve volblocksize Uyumu (Altın Kural)
- ashift=12 vs ashift=13: Kurumsal SSD/NVMe disklerin fiziksel sektör boyutu genellikle 4K (
2^12 = 4096 byte) veya 8K (2^13 = 8192 byte) olarak tasarlanmıştır. Havuz (zpool) oluşturulurkenashiftdeğeri yanlış seçilirse (örneğin 4K diskeashift=9yani 512B verilmesi) her I/O işlemi Read-Modify-Write cezasına çarptırılır. - volblocksize Seçimi: Proxmox VE üzerinde ZFS kullandığınızda VM diskleri
ZVOLolarak açılır ve varsayılan blok boyutu 8K (veya yeni sürümlerde 16K) gelir. Eğer bu ZVOL üzerinde MySQL (InnoDB page size = 16K) çalıştıracaksanızvolblocksize=16k, PostgreSQL (block size = 8K) çalıştıracaksanızvolblocksize=8kseçmelisiniz. Genel amaçlı işletim sistemi diskleri için ise 16K veya 64K en iyi sıkıştırma/performans dengesini sunar.
# Mevcut ZFS havuzunuzun ashift değerini doğrulayın
zdb -C rpool | grep ashift
# Yeni bir ZFS storage tanımlarken veya ZVOL oluştururken blok boyutunu ve sıkıştırmayı optimize edin
zfs set compression=lz4 rpool/data
zfs set atime=off rpool/data
zfs set sync=standard rpool/dataB. ZFS ARC (RAM Önbellek) Sınırlandırması
ZFS varsayılan olarak sunucu RAM’inin %50’sine kadarını ARC (Adaptive Replacement Cache) için kullanabilir. Sanallaştırma sunucularında bu durum, VM’ler ile ZFS’in RAM için savaşmasına (OOM Killer tetiklenmesine veya swap kullanımına) yol açar.
Sunucu açılışında ZFS ARC boyutunu sabitlemek için /etc/modprobe.d/zfs.conf dosyasını yapılandırın (Örn: 256 GB RAM’li bir sunucuda ARC’yi 32 GB ile sınırlamak):
# 32 GB = 34359738368 Byte
echo "options zfs zfs_arc_max=34359738368" | sudo tee /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_min=17179869184" | sudo tee -a /etc/modprobe.d/zfs.conf
# Değişikliği initramfs'e işleyin (veya anlık olarak /sys/module/zfs/parameters/zfs_arc_max içine yazın)
sudo update-initramfs -u -k allC. SLOG (Separate Intent Log) Gerçeği
Senkron yazma (O_SYNC – NFS paylaşımları, veritabanı commit’leri ve ESXi/Proxmox datastore trafiği) performansı düşükse, ZFS havuzuna rastgele bir tüketici SSD’sini SLOG (ZIL) olarak eklemek sistemi hızlandırmaz, aksine yavaşlatır. SLOG olarak kullanılacak NVMe diskin mutlaka PLP (Power Loss Protection – Güç Kesintisi Koruması) özelliğine ve çok düşük yazma gecikmesine (Optane veya Kurumsal NVMe Namespace) sahip olması şarttır.
2. Ceph Optimizasyonu: OSD, BlueStore ve Ağ Ayrımı
Ceph, dağıtık yapısı gereği her yazma işlemini ağ üzerinden diğer düğümlere (varsayılan size=3, yani 3 kopya) kopyaladıktan sonra sanal makineye “yazıldı (ACK)” onayı döner. Bu nedenle Ceph’te disk hızı kadar ağ gecikmesi ve CPU tek çekirdek performansı belirleyicidir.
A. Public ve Cluster Ağlarını Fiziksel/VLAN Olarak Ayırmak
Ceph mimarisinde iki farklı ağ trafiği vardır:
- Public Network (Frontend): KVM/QEMU sanal makinelerinin OSD’lerle konuştuğu ağ.
- Cluster Network (Backend): OSD’lerin kendi aralarında replikasyon, heartbeat ve recovery (disk bozulduğunda veri kopyalama) yaptığı ağ.
Eğer bu iki trafiği aynı 10GbE/25GbE arayüzden geçirirseniz, tek bir disk arızasında başlayan Backfill/Recovery trafiği sanal makinelerin I/O trafiğini boğar. /etc/pve/ceph.conf içinde bu iki ağı mutlaka ayırın ve MTU 9000 (Jumbo Frames) kullanın:
[global]
public_network = 10.100.10.0/24
cluster_network = 10.100.20.0/24
# Küçük I/O paketlerinin TCP tamponlarında bekletilmeden anında gönderilmesi için:
ms_tcp_nodelay = trueB. OSD Başına Bellek (osd_memory_target) ve NVMe Kuyrukları
Ceph BlueStore motoru, meta verileri ve blok önbelleğini doğrudan kendi yönettiği RAM alanında (bluestore_cache) tutar. Varsayılan olarak her OSD 4 GB RAM hedefler. NVMe tabanlı yüksek IOPS kümelerinde OSD başına bu değeri 8 GB ile 12 GB arasına çıkarmak okuma gecikmelerini (read latency) dramatik biçimde düşürür:
# Tüm OSD'ler için bellek hedefini 8 GB (8589934592 byte) olarak güncelle
ceph config set osd osd_memory_target 8589934592
# NVMe disklerde BlueStore'un uyku (sleep) gecikmesini sıfırlayarak maksimum IOPS almasını sağla
ceph config set osd bluestore_cache_autotune trueC. Tüketici (Consumer) SSD/NVMe Tuzağı!
Ceph üzerinde yapılan en ölümcül hata, veri merkezi sınıfı olmayan (PLP kondansatörleri bulunmayan Samsung PRO/EVO vb.) NVMe disklerle OSD kurmaktır. Ceph, veri bütünlüğü için her işlemi O_DSYNC bayrağıyla yazar. PLP olmayan diskler, önbelleği (DRAM) bypass edip doğrudan NAND hücrelerine yazmak zorunda kalır ve 500.000 IOPS kağıt üstü değeri olan bir disk Ceph altında 1.500 IOPS’a düşer.
Doğrulama Testi (fio): Bir diski Ceph OSD yapmadan önce mutlaka şu komutla gerçek senkron yazma kapasitesini test edin:
fio --filename=/dev/nvme1n1 --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=ceph-journal-testBu testte IOPS değeri 5.000 – 10.000’in altındaysa, o disk Ceph için uygun değildir.
3. KVM / QEMU Sanal Makine Katmanı İnce Ayarları
Alttaki ZFS veya Ceph ne kadar hızlı olursa olsun, sanal makine donanım profili doğru seçilmezse darboğaz VM katmanında yaşanır. Proxmox VE üzerinde yüksek performanslı VM’ler için standart profiliniz şu olmalıdır:
- SCSI Controller:
VirtIO SCSI single(Her diske özel I/O kuyruğu açılabilmesi için şart). - Disk Bus/Device:
SCSI(EskiVirtIO Blockyerine modernscsi-hdsürücüsü hem TRIM/Discard hem de çoklu kuyruk açısından daha stabildir). - IO Thread: Aktif (iothread=1). QEMU ana döngüsünü (main loop) bloklamadan her disk için ayrı bir Linux thread’i başlatır.
- Async IO: io_uring (Linux çekirdeğinin en modern, sistem çağrısı yükü en düşük asenkron I/O motoru).
- Cache Mode:
ZFS üzerinde:None(veyaDefault / No cache). ZFS zaten RAM’de ARC tuttuğu için VM seviyesindeWritebackaçmak aynı verinin RAM’de iki kez tutulmasına (Double Caching) neden olur.
Ceph (RBD) üzerinde:Writebackseçeneğilibrbdönbelleğini aktif eder ve küçük sıralı yazmaları birleştirerek (coalescing) ağ üzerindeki OSD trafiğini rahatlatır.