PROXMOX STORAGE YAPILARI
Proxmox Virtual Environment (PVE) altyapılarında depolama mimarisinin seçimi; sanallaştırma ortamının I/O performansı, veri güvenliği, snapshot esnekliği ve operasyonel sürdürülebilirliği üzerinde doğrudan belirleyici bir etkiye sahiptir. Yanlış yapılandırılmış depolama katmanları, sistem kaynaklarının verimsiz tüketilmesine, Out-Of-Memory (OOM) kilitlenmelerine ve veri depolama havuzlarında telafisi imkânsız I/O darboğazlarına yol açar. Bu nedenle, Proxmox VE tarafından desteklenen temel yerel depolama mimarilerinin (LVM, LVM-Thin, ZFS ve Directory) teknik altyapılarını, blok tahsis mekanizmalarını ve veri yönetim disiplinlerini analitik bir yaklaşımla incelemek gerekir.
A- LVM (Klasik / Thick Provisioning) Mimarisi
Logical Volume Manager (LVM), Linux tabanlı sistemlerde fiziksel depolama birimlerini soyutlayarak mantıksal havuzlara dönüştüren klasik depolama mimarisidir. Proxmox VE ortamında ham diskler sisteme dahil edildiğinde hiyerarşik olarak şu üç ana katman üzerinden yapılandırılır:
- Physical Volume (PV): Sisteme eklenen ham blok aygıtları (/dev/sda, /dev/sdb vb.) öncelikle fiziksel hacim (PV) olarak etiketlenir. Sisteme dahil edilen her ham disk için ayrı bir PV tanımlanması zorunludur.
- Volume Group (VG): Bir veya birden fazla Physical Volume, tek bir mantıksal depolama havuzu olan Volume Group yapısı altında birleştirilir. Sistem mimarisinde birden fazla VG tanımlanabileceği gibi, yönetim karmaşıklığını ve disk katmanı risklerini azaltmak adına tek bir VG kullanımı genel kabul gören yaklaşımdır.
- Logical Volume (LV): Sanal makineler (KVM) için istemci diskleri Volume Group içerisinden mantıksal hacimler (LV) halinde tahsis edilir.
LVM mimarisi Thick Provisioning (statik alan tahsisi) prensibiyle çalışır. Bir sanal makineye 100 GB boyutunda bir LVM diski atandığında, istemci işletim sistemi bu alanın yalnızca 10 GB'ını kullansa dahi, Volume Group içerisindeki 100 GB'lık alanın tüm blok ve sektörleri eksiksiz olarak söz konusu sanal makineye rezerve edilir.
Mimari Avantajlar ve Sınırlamalar:
- Yüksek Okuma/Yazma Performansı ve IOPS: Statik blok tahsisi sayesinde dosya sistemi katman overhead'i oluşmaz. Bloklara doğrudan erişim sağlandığı için maksimum okuma/yazma hızı ve kararlı IOPS değerleri elde edilir.
- Donanımsal RAID Bağımlılığı: LVM mimarisi bünyesinde yazılımsal bir veri koruma veya RAID mekanizması barındırmaz. Veri güvenliği, yedeklilik ve hata toleransı sağlamak için donanımsal bir RAID kartına (Hardware RAID Controller) bağımlıdır.
- Snapshot ve Esneklik Sınırlamaları: Statik blok yapısı nedeniyle esnek snapshot yetenekleri bulunmaz; snapshot alma işlemleri yüksek performans kayıplarına yol açar ve dinamik genişlemeye izin vermez.
B- LVM-Thin (Dinamik Depolama) Mimarisi
LVM-Thin, klasik LVM altyapısının üzerine dinamik depolama tahsisi ( Thin Provisioning ) yeteneği eklenerek geliştirilmiş bir mimaridir. Bu yapıda, Volume Group kapasitesi içerisinden bir mantıksal Thin Pool (pve/data) tanımlanır.
LVM-Thin mimarisinde sanal makineye 100 GB sanal disk tahsis edildiğinde, istemci içerisindeki gerçek veri kullanımı 50 GB ise, Thin Pool üzerinde yalnızca 50 GB'lık fiziksel alan işgal edilir. Depolama alanı tahsisi sabit boyutlara göre değil, gerçek zamanlı yazma işlemlerine göre dinamik olarak genişler.
Teknik Özellikler ve Risk Derinliği:
- Copy-on-Write Snapshot ve Klonlama: Dinamik blok haritalaması sayesinde anlık Copy-on-Write (CoW) tabanlı snapshot alma ve hızlı klonlama imkânı sunar.
- Volume Chain Derinleşmesi ve Performans Düşüşü: LVM-Thin üzerinde alınan snapshot sayısı arttıkça arka planda mantıksal bir hacim zinciri (Volume Chain) oluşur. Her yeni yazma işleminde sistemin doğru bloğu bulmak için zincirdeki katman haritalarını sorgulaması gerekir; bu CoW blok haritalama yükü, snapshot sayısı ve derinliği arttıkça yazma performansında bariz bir düşüşe yol açar.
- Over-Provisioning ve Metadata Riski: Fiziksel kapasitenin üzerinde sanal alan tahsis edilmesine over-provisioning imkân tanır. LVM-Thin yapısı, veri bloklarının yanı sıra indeksleme için bir Metadata havuzu kullanır. Depolama havuzunun veya metadata alanının %100 doluluğa ulaşması durumunda I/O kilitlenmesi yaşanır ve tüm sanal makineler verilerini korumak amacıyla anında kilitlenerek freeze / read-only moduna geçer.
- Yerel Depolama Odağı: LVM-Thin, mimari tasarımı gereği küme genelinde paylaşımlı depolama olarak değil, yerel depolama (local storage) olarak işlev görür.
C- ZFS (Zettabyte File System) Mimarisi
ZFS, hem gelişmiş bir dosya sistemi hem de mantıksal hacim yöneticisi (Volume Manager) olarak çalışan, veri bütünlüğü ve üst düzey koruma sunan bütünleşik bir teknolojidir.
Bütünleşik Yazılımsal RAID Mimarisi: ZFS, donanımsal RAID kartlarına ihtiyaç duymadan doğrudan ham disklere erişir. Mirror, Stripe, RAIDZ-1, RAIDZ-2, RAIDZ-3 ve dRAID gibi yazılımsal RAID konfigürasyonlarını kendi bünyesinde yöneterek donanım bağımlılığını ortadan kaldırır.
Depolama Nesneleri ZVOL ve Subvolume Ayrımı: ZFS Pool içerisinde istemci mimarisine göre iki farklı depolama nesnesi oluşturulur:
- ZVOL (ZFS Volume): Sanal makineler için sürücü katmanında ham block device olarak sunulan yapılardır. Doğrudan blok seviyesinde I/O performansı sağlar ve Thin Provisioning mimarisini destekler.
- Subvolume: Linux Konteynerları (LXC) için sunulan dosya tabanlı veri kümeleridir (dataset). Doğrudan dosya sistemi seviyesinde esnek depolama sunar.
Veri Yönetimi, Sıkıştırma ve RAM Tüketim Mekanizmaları:
- Copy-on-Write (CoW) ve Dahili Sıkıştırma: Veri güncellemelerinde mevcut bloğun üzerine yazmak yerine yeni bir bloğa yazma yapılır. Varsayılan lz4 sıkıştırma algoritması sayesinde yüksek disk tasarrufu elde edilir.
- RAM Tüketim Mekanizmalarının Ayrımı (ARC vs Deduplication): ZFS ARC (Adaptive Replacement Cache) ZFS, okuma performansını artırmak amacıyla sistem RAM'ini önbellek olarak kullanır. ARC kullanımı dinamiktir ve sistem kararlılığı için konfigürasyon dosyalarından sınırlandırılmalıdır.
- Tekilleştirme (Deduplication) Hash Tablosu: ZFS, mükerrer blokları engellemek için veri bloklarının hash değerlerini hesaplar. Yüksek I/O başarımını korumak için bu hash tablosunun tamamen RAM'de tutulması gerekir. 1 TB ZFS depolama alanı için ~5 GB RAM kuralı, doğrudan bu Deduplication Hash Tablosu'nun bellek gereksiniminden kaynaklanmaktadır. Deduplication etkinleştirildiğinde yetersiz RAM bulunması durumunda ise sistemin kilitlenmesine yol açar.
- Kendi Kendini İyileştirme ve Zaman uyumsuz Ağ Çoğaltması: Self-healing özelliği, sessiz veri bozulmalarını (bit rot) veri okuması sırasında checksum doğrulamasıyla tespit edip arka planda otomatik onarır. Asynchronous replication (pvesr) yeteneği ise zfs havuzları arasında belirli aralıklarla ağ üzerinden zaman uyumsuz çoğaltma sağlar.
D- Directory (Standart Linux Dizin Yapısı)
Directory depolama türü, yerel disklerin standart Linux dosya sistemleri (ext4 veya XFS) üzerinde biçimlendirilip bir dizin yolluğu olarak sisteme eklenmesiyle oluşur (/var/lib/vz varsayılan dizindir).
Kullanım Alanları ve qcow2 Çift Tamponlama Overhead'i:
- İçerik Yelpazesi: ISO imajları, LXC konteyner şablonları, vzdump yedekleme dosyaları ve qcow2 formatındaki sanal disk imajları için kullanılır.
- qcow2 Bağımlılığı ve Katman Overheads: Directory yapısında dosya sistemi seviyesinde snapshot desteği bulunmaz. Sanal makine seviyesinde snapshot alabilmek için disk imajlarının qcow2 formatında tanımlanması zorunlu kılınmıştır. Ancak ext4/XFS dosya sistemi üzerinde çalışan bir qcow2 dosyası, hem host dosya sistemi önbelleği hem de sanal disk katmanında çift tamponlama (double buffering) oluşmasına yol açar. Bu durum I/O gecikmesini (latency) artırır.
- Ekstrem / İleri Seviye Yapılandırma (Debian mdadm Software RAID): PVE varsayılan kurulum arayüzünde Directory için yazılımsal RAID seçeneği sunmasa da, Proxmox VE Debian tabanlı bir işletim sistemi olduğu için uç senaryolarda mdadm aracı kullanılarak yazılımsal RAID dizisi (Software RAID) kurulabilir. Bu mdadm dizisi ext4/XFS olarak biçimlendirildikten sonra PVE'ye Directory depolama alanı olarak tanımlanabilir.
Dosya Sistemleri Karşılaştırma Matrisi
Proxmox VE ortamında depolama mimarisi seçimi, sistem yöneticileri üzerinde ciddi bir zihinsel yük oluşturur. Arayüzün (GUI) sunduğu "tek tıkla depolama ekleme" pratikliği, arka plandaki karmaşık Linux depolama dinamikleriyle çeliştiğinde canlı üretim ortamlarında ciddi kesintiler meydana gelmektedir.
- Sanaallaştırmaya Yeni Başlayan Kullanıcılar: Arayüzün sunduğu kolaylığa odaklanarak varsayılan Directory veya LVM depolama türlerini seçerler. Ancak kısa süre sonra snapshot alamama, disk alanının hızla tüketilmesi veya düşük I/O performansı gibi sorunlarla karşılaşırlar. ZFS tarafındaki ZVOL, Subvolume ve pool mantığı bu kullanıcı grubu için yüksek bir öğrenme eğrisi yaratır.
- Deneyimli Sistem Yöneticileri: Mimarinin getirdiği I/O overhead'lerini, donanım RAID bağımlılıklarını ve yedekleme stratejilerini dikkate alarak karar verirler. Buna karşın, ZFS önbellek (ARC) sınırlandırması yapılmadığında yaşanan bellek baskısı veya LVM-Thin over-provisioning takibinin otomatize edilmemesi bu grupta da operasyonel krizlere neden olabilmektedir.
Proxmox VE ortamında LVM (Klasik / Thick) ile LVM-Thin arasındaki performans ve mimari farkları şu şekilde özetlenebilir:
1. Yazma ve Okuma Performansı (I/O & IOPS)
LVM (Klasik / Thick Provisioning): Sanal makineye atanan disk kapasitesinin tamamını (örneğin 100 GB) fiziksel bloklarda önceden ve statik olarak ayırır
. Disk sektörlerinin tamamı ayrıldığı için doğrudan ham disk hızlarına yakın çok yüksek yazma ve okuma performansı (yüksek IOPS) sunar.
LVM-Thin (Thin Provisioning): Blokları önceden ayırmaz; veriler yazıldıkça dinamik olarak tahsis eder
. Mantıksal bir havuz (thin pool) üzerinden çalıştığı için ham yazma performansı klasik LVM'e kıyasla orta seviyededir
. Ancak okuma performansı, sadece gerçekten yazılmış veri blokları işlendiği için yüksektir.
2. Snapshot (Anlık Görüntü) Performansı
LVM-Thin: Dinamik blok yapısı sayesinde son derece hızlı ve kesintisiz snapshot alma imkanı sağlar
. Snapshot işlemi yalnızca kullanılan gerçek veri boyutundan etkilendiği için sistem performansını yormaz
LVM (Klasik): Geleneksel LVM snapshot yapısı, aktifken tüm hacim grubunda (Volume Group) ek I/O yükü oluşturur
. Bu nedenle klasik LVM'de yerel snapshot performansı düşüktür veya kısıtlıdır (Proxmox VE 9 ile katmanlı qcow2 yapısını kullanan snapshot-as-volume-chain özelliği eklenmiştir)
3. Disk Alanı Verimliliği ve Etki Faktörleri
LVM-Thin: Sanal makineye 100 GB tanımlansa bile içinde 20 GB veri varsa depolamada sadece 20 GB alan kaplar
. Bu sayede disk verimliliği çok yüksektir
, ancak havuz üzerinde çok fazla snapshot biriktirilmesi zamanla yazma performansını olumsuz etkileyebilir
.LVM (Klasik): İçindeki verinin boyutuna bakılmaksızın tüm alanı rezerve ettiği için disk verimliliği orta/düşüktür, ancak arkadaki veri havuzu doluluk oranından bağımsız olarak kararlı bir performans sergiler
Proxmox VE ortamında ZFS (Zettabyte File System), sanallaştırma mimarileri için yüksek veri güvenliği, esneklik ve performans sunan gelişmiş bir depolama teknolojisidir
Öne çıkan başlıca avantajları şunlardır:
Bütünleşik Dosya Sistemi ve Hacim Yöneticisi: ZFS, geleneksel yapılardaki gibi harici bir LVM veya ekstra mantıksal hacim yöneticisine ihtiyaç duymadan, doğrudan diskler üzerinde hem dosya sistemi hem de hacim yöneticisi olarak çalışır
Çok Hızlı Snapshot ve Klonlama: Copy-on-write (yazılırken kopyala) yapısı sayesinde sanal makineler ve konteynerler için sistem performansını düşürmeyen, anlık ve son derece hızlı snapshot (anlık görüntü) ile klonlama imkanı tanır
Canlı Sıkıştırma ve Tekilleştirme: Dosya sistemi düzeyinde lz4 gibi düşük CPU yükü getiren algoritmalarla verileri anlık sıkıştırır
. Ayrıca mükerrer verileri engelleyen tekilleştirme (deduplication) yeteneğiyle depolama alanında yüksek verimlilik sağlar
