Sanallaştırma teknolojileri, kurumların bilgi teknolojileri altyapılarını daha verimli, esnek ve yönetilebilir hale getirmesinde önemli bir rol üstlenmektedir. Fiziksel sunucu kaynaklarının birden fazla sanal makine arasında paylaştırılması, donanım yatırımlarından daha fazla fayda sağlanmasına yardımcı olurken, merkezi yönetim ve otomasyon olanakları da operasyonel süreçleri kolaylaştırmaktadır.
Ancak başarılı bir sanallaştırma altyapısı oluşturmak yalnızca yeterli işlemci ve bellek kaynaklarına sahip olmakla mümkün değildir. Sanal makinelerin çalışacağı depolama altyapısının doğru planlanması, sistemlerin performansı, veri güvenliği, ölçeklenebilirliği ve iş sürekliliği açısından en az hesaplama kaynakları kadar önemlidir.
Örneğin güçlü işlemcilere ve yüksek bellek kapasitesine sahip bir sanallaştırma sunucusunda, depolama altyapısının yetersiz olması nedeniyle veri tabanı sorguları yavaşlayabilir, uygulamaların yanıt süreleri uzayabilir veya aynı anda çalışan sanal makineler birbirlerinin disk performansını olumsuz etkileyebilir.
Bunun yanında yanlış tasarlanmış bir depolama mimarisi; kapasite yetersizliği, veri kaybı, yedekleme sorunları ve beklenmeyen hizmet kesintileri gibi ciddi operasyonel riskler oluşturabilir.
Açık kaynak kodlu sanallaştırma platformlarından Proxmox Virtual Environment (Proxmox VE) bu ihtiyaçlara yönelik farklı depolama teknolojilerini destekleyen esnek bir altyapı sunmaktadır.
Proxmox VE üzerinde geleneksel Linux dosya sistemlerinden gelişmiş ZFS havuzlarına, kurumsal SAN sistemlerinden dağıtık Ceph mimarisine kadar oldukça geniş bir depolama ekosistemi kullanılabilmektedir.
Bu çeşitlilik önemli avantajlar sağlamakla birlikte sistem yöneticilerinin karşısına temel bir soruyu çıkarmaktadır:
Hangi depolama teknolojisi, hangi iş yükü ve altyapı gereksinimi için daha uygundur?
Bu makalede Proxmox VE’nin depolama mimarisini temelden başlayarak inceleyecek; LVM, LVM-Thin, Directory ve ZFS teknolojilerinin çalışma prensiplerini, avantajlarını ve sınırlamalarını ele alacağız. Ardından NFS, iSCSI, SAN ve Ceph gibi paylaşımlı depolama çözümlerini değerlendirecek, gerçek kullanım senaryoları üzerinden kurumsal depolama tasarımı için öneriler sunacağız.
Proxmox VE Depolama Mimarisi Nasıl Çalışır?
Proxmox VE üzerinde depolama yönetimini doğru anlayabilmek için öncelikle platformun depolama kaynaklarını nasıl tanımladığını ve yönettiğini incelemek gerekir.
Proxmox VE, depolama işlemlerini genel olarak iki yönetim seviyesinde ele alır: fiziksel veya mantıksal depolama kaynaklarının hazırlandığı Node seviyesi ve bu kaynakların sanallaştırma platformuna tanıtılarak kullanım amaçlarının belirlendiği Datacenter seviyesi.
Bu ayrım ilk bakışta basit görünse de özellikle birden fazla fiziksel sunucunun bulunduğu cluster ortamlarında önemli hale gelmektedir.
a) Node Seviyesinde Depolama Yönetimi
Node, Proxmox VE kurulu fiziksel sunucuyu ifade eder. Node seviyesinde depolama yönetimi, sunucuya doğrudan bağlı fiziksel disklerin ve bu diskler üzerinde oluşturulan mantıksal yapıların hazırlanmasını kapsar.
Proxmox yönetim arayüzünde ilgili sunucu seçilerek Disks bölümüne erişildiğinde, sistem tarafından algılanan diskler görüntülenebilir. Bu bölümde disklerin kapasitesi, kullanılan depolama teknolojisi ve uygun durumlarda sağlık bilgileri incelenebilir.
Ayrıca LVM, LVM-Thin, Directory ve ZFS gibi depolama yapıları oluşturulabilir.
Örneğin bir fiziksel sunucuda dört adet SSD disk bulunduğunu düşünelim. Bu diskler kullanım amacına göre farklı şekillerde değerlendirilebilir.
İki disk işletim sistemi için ayrılırken diğer iki disk ZFS Mirror mimarisinde yapılandırılarak sanal makine diskleri için kullanılabilir. Alternatif olarak donanım RAID kontrolcüsü tarafından sunulan mantıksal disk üzerinde LVM-Thin havuzu oluşturulabilir.
Hangi yaklaşımın daha uygun olduğu, donanım mimarisine ve beklenen veri koruma özelliklerine bağlıdır.
Node seviyesinde gerçekleştirilen hazırlık işlemleri, depolamanın fiziksel veya mantıksal temelini oluşturur.
b) Datacenter Seviyesinde Depolama Yönetimi
Datacenter seviyesi, Proxmox VE altyapısında depolama alanlarının merkezi olarak tanımlandığı yönetim katmanıdır.
Datacenter → Storage bölümünde yerel ve harici depolama kaynakları Proxmox’a tanıtılabilir.
Burada depolama alanının hangi node’lar tarafından kullanılabileceği, hangi içerik türlerini destekleyeceği ve paylaşımlı olup olmadığı gibi özellikler belirlenir.
Örneğin aynı Proxmox cluster içerisinde üç fiziksel sunucu bulunduğunu varsayalım.
Her sunucuda kendi yerel diskleri üzerinde oluşturulmuş bir LVM-Thin depolama alanı bulunabilir. Datacenter seviyesindeki depolama tanımları sayesinde bu alanlar merkezi olarak yönetilebilir.
Bununla birlikte merkezi yönetim, depolama kaynaklarının otomatik olarak ortak kullanıma açıldığı anlamına gelmez.
Bir node üzerinde bulunan yerel LVM-Thin havuzuna diğer node’ların doğrudan erişmesi mümkün değildir. Buna karşılık NFS, Ceph veya uygun yapılandırılmış bir SAN altyapısı birden fazla node tarafından kullanılabilir.
Bu nedenle Proxmox depolama mimarisinde iki kavramın birbirinden ayrılması gerekir:
Merkezi yönetim, depolama kaynaklarının tek noktadan tanımlanmasını ve yapılandırılmasını sağlar.
Paylaşımlı depolama ise birden fazla fiziksel sunucunun aynı depolama verilerine erişebilmesini ifade eder.
Datacenter seviyesinde Shared seçeneğinin etkinleştirilmesi, fiziksel olarak yerel olan bir diski paylaşımlı depolamaya dönüştürmez. Bu seçeneğin kullanılabilmesi için alttaki depolama altyapısının gerçekten ortak erişimi desteklemesi gerekir.
Dosya Sistemi, Blok Depolama ve Storage Backend Kavramları
Depolama teknolojilerini karşılaştırırken sıkça karşılaşılan karışıklıklardan biri, dosya sistemi ile depolama türünün aynı kavram olarak değerlendirilmesidir.
Oysa bunlar depolama mimarisinin farklı katmanlarını temsil eder.
Bir fiziksel diskin üzerinde doğrudan dosya sistemi oluşturulabileceği gibi, önce bir mantıksal birim yönetim katmanı hazırlanıp ardından bu birim üzerine dosya sistemi kurulabilir.
Dosya Sistemi Nedir?
Dosya sistemi, verilerin bir depolama alanı üzerinde nasıl organize edildiğini ve erişilebilir hale getirildiğini belirleyen yapıdır.
Linux ortamlarında yaygın kullanılan dosya sistemleri arasında ext4, XFS, Btrfs ve ZFS bulunmaktadır.
ext4, olgun yapısı ve geniş kullanım alanı sayesinde Linux sistemlerinde yaygın olarak tercih edilir. Genel amaçlı iş yüklerinde sade ve öngörülebilir bir çözüm sunar.
XFS, özellikle büyük dosyalar ve yüksek aktarım hızları gerektiren bazı iş yüklerinde güçlü bir alternatif olabilir. Ancak her koşulda ext4’ten daha hızlı olduğu söylenemez.
Btrfs, copy-on-write yaklaşımı, snapshot ve checksum gibi gelişmiş özellikler sunan bir dosya sistemidir.
ZFS ise geleneksel dosya sistemi işlevlerinin ötesine geçerek veri bütünlüğü, hacim yönetimi, snapshot ve RAID benzeri veri koruma mekanizmalarını bütünleşik biçimde sağlar.
Blok Seviyesinde Depolama
Blok depolama, verilerin blok aygıtları veya mantıksal birimler üzerinden yönetilmesini sağlar.
Proxmox VE’de LVM ve LVM-Thin bunun yaygın örnekleridir.
Sanal makineye sunulan disk, bir mantıksal blok aygıtı olarak hazırlanabilir. Sanal makinenin işletim sistemi bu disk üzerinde kendi bölümleme ve dosya sistemi işlemlerini gerçekleştirir.
Blok depolama, sanal makine diskleri için uygun bir yaklaşım olmakla birlikte ISO dosyalarının veya klasik yedek arşivlerinin doğrudan saklanması amacıyla kullanılmaz.
Dosya Seviyesinde Depolama (Object)
Dosya tabanlı depolamada sanal makine diskleri, mevcut bir dosya sistemi içerisinde dosya olarak tutulabilir.
Örneğin Directory depolama kullanıldığında sanal makine diski RAW veya QCOW2 biçiminde bir dosya olabilir.
Bu yaklaşım depolama alanının ISO dosyaları, şablonlar ve yedeklemeler gibi farklı içerik türleri için de kullanılabilmesine olanak tanır.
Bununla birlikte dosya ve blok depolama ayrımının tek başına performans üstünlüğü anlamına gelmediği unutulmamalıdır.
Gerçek performans; fiziksel disk teknolojisine, dosya biçimine, önbellekleme yöntemlerine, RAID topolojisine ve uygulamanın gerçekleştirdiği giriş/çıkış işlemlerine bağlıdır.
Directory Storage: Basit ve Esnek Depolama Yaklaşımı
Directory, Proxmox VE üzerinde en kolay anlaşılabilen depolama türlerinden biridir.
Temel olarak sunucuda bağlanmış bir dosya sistemi üzerinde bulunan belirli bir dizinin, Proxmox tarafından depolama alanı olarak kullanılmasını sağlar.
Bu dizin ext4, XFS veya uygun şekilde hazırlanmış farklı bir dosya sistemi üzerinde bulunabilir.
Directory depolamanın önemli avantajı, aynı depolama alanının birden fazla içerik türüne hizmet verebilmesidir.
Örneğin ISO dosyaları, konteyner şablonları, sanal makine diskleri ve yedekleme arşivleri uygun yapılandırma ile bu alanda saklanabilir.
Directory Nasıl Çalışır?
Bir Proxmox sunucusunda ext4 olarak biçimlendirilmiş ve /mnt/pve/storage01 konumuna bağlanmış bir disk bulunduğunu düşünelim.
Bu dizin, Datacenter seviyesinde Directory depolama olarak tanımlanabilir.
Ardından sanal makineler oluşturulurken disklerin bu alan üzerinde tutulması sağlanabilir.
Sanal makine diskinin RAW biçiminde saklanması, sanal diskin dosya şeklinde temsil edilmesini sağlar. QCOW2 ise ek özellikler sunan daha esnek bir disk biçimidir.
QCOW2 ile thin provisioning ve snapshot gibi olanaklardan yararlanılabilir. Ancak bu özelliklerin kullanımı, sanal makinenin diğer disklerinin ve yapılandırmasının da uyumlu olmasına bağlıdır.
Directory Depolamanın Avantajları
Directory yapısının en önemli avantajı, kullanım ve yönetim kolaylığıdır.
Linux dosya sistemlerine aşina olan sistem yöneticileri, Directory depolamanın mantığını kolaylıkla kavrayabilir.
Ayrıca dosya tabanlı yapısı sayesinde disk imajlarının ve diğer depolama içeriklerinin yönetimi esnektir.
Bu özellikler Directory depolamayı test ortamları, ISO arşivleri, konteyner şablonları ve belirli üretim iş yükleri için kullanışlı hale getirir.
Directory Depolamanın Dezavantajları
Directory, alttaki dosya sisteminin sağlamadığı gelişmiş veri bütünlüğü veya otomatik onarım özelliklerini kendiliğinden sunmaz.
Örneğin ext4 üzerinde Directory kullanılması, ZFS’in checksum ve yedekli bloklardan otomatik onarım olanaklarını kazandırmaz.
Snapshot özellikleri de kullanılan sanal disk biçimine bağlıdır.
Bunun yanında çok sayıda sanal makinenin aynı depolama alanını kullanması durumunda fiziksel diskler üzerindeki I/O yükünün dikkatle izlenmesi gerekir.
Hangi Ortamlarda Kullanılmalı?
Directory depolama özellikle ISO dosyaları, konteyner şablonları ve dosya tabanlı arşivlerin saklanması için uygun bir tercihtir.
Sanal makine diskleri için de kullanılabilir. Ancak yüksek performans veya gelişmiş veri koruma ihtiyacı bulunan kritik sistemlerde alternatif depolama teknolojileriyle karşılaştırılması önerilir.
LVM: Geleneksel ve Olgun Blok Depolama Yönetimi
Logical Volume Manager, Linux işletim sistemlerinde uzun süredir kullanılan mantıksal birim yönetim teknolojisidir.
LVM, fiziksel diskler veya disk bölümleri üzerinden depolama kaynaklarının daha esnek yönetilmesini sağlar.
LVM mimarisinde üç temel bileşen bulunur:
- Physical Volume (PV): LVM tarafından kullanılmak üzere hazırlanmış fiziksel veya mantıksal blok aygıtıdır.
- Volume Group (VG): Bir veya daha fazla Physical Volume’un oluşturduğu kapasite havuzudur.
- Logical Volume (LV): Volume Group içerisinden ayrılan mantıksal depolama birimidir.
Bu mimari sayesinde fiziksel disk kaynakları, ihtiyaca göre mantıksal birimlere bölünerek kullanılabilir.
Proxmox VE’de LVM Kullanımı
Proxmox VE üzerinde standart LVM depolama kullanıldığında sanal makine diskleri Logical Volume olarak oluşturulur.
Örneğin 4 TB kapasiteye sahip bir Volume Group içerisinde 500 GB büyüklüğünde bir sanal makine diski oluşturulduğunda, bu kapasite mantıksal birim için ayrılır.
Sanal makinenin işletim sistemi içerisinde yalnızca 40 GB veri bulunması, standart LVM’de ayrılmış olan 500 GB kapasitenin diğer sanal makineler tarafından kullanılabilir hale geldiği anlamına gelmez.
Bu yaklaşım Thick Provisioning olarak değerlendirilir.
a) LVM’nin Avantajları
Standart LVM’nin önemli avantajlarından biri, sade ve olgun bir blok depolama modeli sunmasıdır.
Ek dosya biçimi katmanları kullanılmadığından yönetim yapısı belirli senaryolarda daha öngörülebilir olabilir.
LVM ayrıca uygun bir SAN veya iSCSI altyapısı üzerinde paylaşımlı depolama senaryolarında kullanılabilir.
Özellikle mevcut kurumsal SAN yatırımlarını Proxmox VE ile değerlendirmek isteyen kurumlar açısından önemli bir seçenektir.
b) LVM’nin Dezavantajları
Standart LVM depolamanın başlıca sınırlaması, Proxmox’un bu depolama eklentisi üzerinden snapshot desteği sunmamasıdır.
Linux LVM teknolojisinin kendi snapshot mekanizmaları bulunmasına rağmen, bunlar Proxmox’un standart LVM depolama eklentisinde VM snapshot özelliği olarak sunulmaz.
Ayrıca thick provisioning yaklaşımı kapasite kullanımında esnekliği azaltır.
Örneğin çok sayıda sanal makineye yüksek disk kapasitesi tanımlandığında, fiilen kullanılmayan alan da başlangıçta ayrılmış olur.
Bu durum özellikle sınırlı depolama kapasitesine sahip sistemlerde önemli bir dezavantaj oluşturabilir.
c) Ne Zaman Tercih Edilmeli?
Standart LVM, snapshot ihtiyacının farklı bir katmanda karşılandığı, SAN tabanlı paylaşımlı depolama altyapılarında veya kalın tahsisin bilinçli olarak tercih edildiği ortamlarda değerlendirilebilir.
Buna karşılık yerel diskler üzerinde esnek kapasite tahsisi ve snapshot ihtiyacı bulunan ortamlarda LVM-Thin daha işlevsel olabilir.
LVM-Thin: Depolama Kapasitesini Daha Verimli Kullanmak
LVM-Thin, LVM teknolojisinin thin provisioning destekleyen yapısıdır.
Bu teknolojinin temel amacı, sanal makinelere tanımlanan mantıksal kapasite ile fiziksel depolama üzerinde gerçekten tüketilen alanın birbirinden ayrılmasını sağlamaktır.
Özellikle çok sayıda sanal makinenin bulunduğu altyapılarda önemli esneklik sağlar.
Thin Provisioning Nasıl Çalışır?
Bir sunucuda 4 TB kullanılabilir fiziksel depolama kapasitesi bulunduğunu varsayalım.
Bu sunucuda her biri 500 GB sanal disk kapasitesine sahip 12 sanal makine oluşturulduğunda, toplam mantıksal kapasite 6 TB olacaktır.
Standart LVM’de bu kapasitenin tamamının önceden ayrılması gerektiğinden böyle bir tahsis mümkün olmayabilir.
LVM-Thin kullanıldığında ise sanal makineler başlangıçta yalnızca kullandıkları fiziksel alanı tüketir.
Örneğin 12 sanal makinenin her biri ortalama 100 GB fiziksel alan tüketiyorsa toplam gerçek kullanım yaklaşık 1,2 TB seviyesinde olabilir.
Ancak sanal makinelere tanımlanan kapasitenin fiziksel alanı aşabilmesi, sınırsız depolama sağlandığı anlamına gelmez.
Sanal makinelerde veri miktarı arttıkça fiziksel depolama kullanımı da artacaktır.
Gerçek kullanım havuz kapasitesine yaklaştığında yeni veri yazma işlemleri başarısız olabilir.
Bu durum özellikle veri tabanı sistemlerinde ve kritik uygulamalarda ciddi sorunlara yol açabilir.
LVM-Thin Snapshot ve Klonlama
LVM-Thin’in standart LVM’ye göre en önemli avantajlarından biri snapshot ve klonlama özellikleridir.
Sanal makine üzerinde bir güncelleme yapılmadan önce snapshot oluşturulabilir.
Güncellemenin başarısız olması durumunda uygun koşullarda önceki duruma dönülebilir.
Klonlama işlemleri ise özellikle test ortamlarında yeni sanal makinelerin hazırlanmasını kolaylaştırır.
Bununla birlikte snapshot’ların uzun süre tutulması depolama kapasitesini artıran ek veri bloklarının birikmesine neden olabilir.
Dolayısıyla snapshot mekanizmasının yedekleme yerine kullanılmaması ve düzenli bir saklama politikasıyla yönetilmesi gerekir.
Avantajları
LVM-Thin, yerel sanallaştırma ortamlarında kapasite verimliliği ve yönetim kolaylığı arasında dengeli bir çözüm sunar.
Thin provisioning sayesinde fiziksel kapasite daha verimli kullanılabilir.
Snapshot ve klonlama özellikleri, sanal makine yönetiminde esneklik sağlar.
ZFS’in gelişmiş veri koruma özelliklerine ihtiyaç duyulmayan, ancak hızlı ve pratik bir yerel depolama altyapısı aranan ortamlarda uygun bir alternatiftir.
Dezavantajları ve Riskleri
LVM-Thin havuzlarının dikkatli izlenmesi gerekir.
Özellikle veri ve metadata kullanım oranlarının yükselmesi, kritik sorunlara neden olabilir.
Ayrıca konuk işletim sistemleri içerisinde silinen verilerin fiziksel depolama alanında geri kazanılabilmesi için uygun discard/TRIM yapılandırmasına ihtiyaç duyulabilir.
Thin provisioning kapasite planlamasını ortadan kaldırmaz; aksine daha disiplinli bir kapasite yönetimi gerektirir.
LVM-Thin’in diğer önemli sınırlaması ise Proxmox üzerinde paylaşımlı cluster depolaması olarak kullanılamamasıdır.
Hangi Ortamlarda Tercih Edilmeli?
LVM-Thin, tek node’lu sistemler ve yerel depolama kullanan küçük veya orta ölçekli altyapılar için güçlü bir seçenektir.
Özellikle SSD veya NVMe tabanlı diskler üzerinde çalışan sanal makinelerde kullanım kolaylığı sağlar.
Ancak gelişmiş veri bütünlüğü mekanizmaları ve yerel replikasyon ihtiyaçları bulunuyorsa ZFS de değerlendirilmelidir.
ZFS: Veri Bütünlüğü ve Gelişmiş Depolama Yönetimi
ZFS, Proxmox VE’nin desteklediği en kapsamlı yerel depolama teknolojilerinden biridir.
Geleneksel dosya sistemlerinden farklı olarak, dosya sistemi ve mantıksal birim yönetimi işlevlerini bütünleşik biçimde sunar.
Bu sayede disk havuzları, veri kümeleri, sanal disk birimleri, snapshot ve veri koruma mekanizmaları aynı teknoloji üzerinden yönetilebilir.
ZFS’in öne çıkan özellikleri arasında copy-on-write mimarisi, checksum mekanizması, sıkıştırma, snapshot, veri çoğaltma ve disk yedekliliği bulunmaktadır.
ZFS Depolama Mimarisi
ZFS’te fiziksel depolama kaynakları öncelikle Virtual Device (vdev) yapıları içerisinde organize edilir.
Bir veya daha fazla vdev, ZFS Pool olarak adlandırılan depolama havuzunu oluşturur.
Havuz içerisinde dataset veya zvol adı verilen yapılar hazırlanabilir.
Dataset, dosyaların ve dizinlerin saklandığı ZFS veri kümesidir.
Zvol, blok aygıtı olarak kullanılabilen mantıksal ZFS birimidir.
Proxmox VE’de ZFS Pool depolama eklentisi kullanıldığında sanal makine diskleri zvol olarak yönetilebilir.
ISO veya yedekleme gibi dosya tabanlı içeriklerin saklanması için ise bir ZFS dataset’i Directory depolama olarak tanımlanabilir.
Bu nedenle aynı fiziksel ZFS altyapısı, farklı kullanım amaçları için mantıksal olarak ayrılabilir.
Copy-on-Write Teknolojisi
ZFS’in önemli özelliklerinden biri Copy-on-Write yaklaşımıdır.
Geleneksel yerinde veri güncelleme yöntemlerinden farklı olarak, değiştirilen veri blokları yeni konumlara yazılır ve ilgili metadata yapıları güncellenir.
Bu yaklaşım snapshot mekanizmasının verimli çalışmasına yardımcı olur.
Ancak Copy-on-Write, ek metadata işlemleri ve blok yerleşimi nedeniyle belirli iş yüklerinde yazma davranışını etkileyebilir.
Bu nedenle ZFS performansı değerlendirilirken yalnızca disk hızı değil, blok boyutu, iş yükü türü, havuz doluluk oranı ve kullanılan vdev topolojisi birlikte ele alınmalıdır.
Veri Bütünlüğü ve Checksum
ZFS’in kurumsal depolama sistemlerinde öne çıkmasını sağlayan başlıca özelliklerden biri veri bütünlüğünü doğrulama yeteneğidir.
ZFS, veri bloklarının checksum bilgilerini kullanarak okunan verinin beklenen içerikle uyumlu olup olmadığını kontrol edebilir.
Uygun yedekliliğin bulunduğu Mirror veya RAIDZ yapılarında, bozulmuş veri blokları sağlam kopyalardan yeniden oluşturulabilir.
Bu mekanizma geleneksel dosya sistemlerinde her zaman bulunmayan önemli bir güvenlik katmanı sağlar.
Ancak checksum mekanizması, yanlışlıkla silinen dosyaları geri getirmez veya uygulama tarafından hatalı yazılmış verileri otomatik olarak düzeltmez.
Dolayısıyla ZFS veri bütünlüğüne katkı sağlasa da yedekleme ihtiyacını ortadan kaldırmaz.
ZFS Compression
ZFS, depolama alanındaki verilerin sıkıştırılmasını destekler.
Özellikle LZ4 algoritması, düşük işlem maliyeti ve hızlı çalışma özellikleri nedeniyle yaygın olarak kullanılır.
Sıkıştırılabilir veriler içeren sanal makinelerde fiziksel kapasite tüketimi azaltılabilir.
Örneğin işletim sistemi dosyaları, günlük kayıtları veya metin tabanlı veri kümeleri sıkıştırmadan yararlanabilir.
Buna karşılık önceden sıkıştırılmış arşivler, medya dosyaları veya bazı şifrelenmiş veriler için kazanım sınırlı olabilir.
Sıkıştırmanın avantajı yalnızca kapasite tasarrufu değildir. Bazı iş yüklerinde diske daha az veri yazılması, fiziksel I/O miktarını azaltarak performansa katkıda bulunabilir.
Ancak bu kazanım her iş yükünde garanti değildir.
ZFS Snapshot ve Replication
ZFS snapshot mekanizması, veri kümelerinin veya blok birimlerinin belirli bir andaki durumunun korunmasını sağlar.
Bu özellik özellikle sistem güncellemeleri, bakım operasyonları ve geri dönüş gerektiren işlemlerde önemlidir.
ZFS ayrıca veri gönderme ve alma mekanizmalarıyla farklı sistemler arasında veri çoğaltma olanağı sunar.
Proxmox VE’nin yerel ZFS depolama tabanlı replikasyon özelliği, uygun yapılandırmalarda sanal makine disklerinin diğer node’lara zamanlanmış olarak çoğaltılmasını sağlayabilir.
Ancak replikasyon işleminin belirli aralıklarla gerçekleştirilmesi, son çoğaltma işleminden sonra oluşan verilerin arıza durumunda kaybedilebileceği anlamına gelir.
Bu nedenle replikasyon aralığı belirlenirken kurumun Recovery Point Objective (RPO) hedefi dikkate alınmalıdır.
ZFS Bellek Gereksinimi
ZFS’in geleneksel LVM yapısına göre daha fazla bellek kullanabilmesinin önemli nedenlerinden biri ARC adı verilen önbellekleme mekanizmasıdır.
ARC, sık erişilen verilerin bellekte tutulmasını sağlayarak fiziksel disk erişimlerini azaltabilir.
Bu özellik performans açısından avantaj sağlasa da sanallaştırma sunucularında belleğin aynı zamanda sanal makineler tarafından kullanıldığı unutulmamalıdır.
Bu nedenle ZFS önbellek davranışı ile sanal makine bellek gereksinimleri arasında denge kurulmalıdır.
ZFS’in her ortamda sabit ve çok yüksek miktarda RAM gerektirdiği şeklindeki genellemeler doğru değildir. Gereksinim; havuz yapısına, önbellek kullanımına, özelliklere ve iş yüküne göre değişir.
Özellikle deduplication gibi ek kaynak tüketimi oluşturabilen özellikler kullanılacaksa bellek planlaması daha ayrıntılı yapılmalıdır.
ZFS RAID Mimarileri Nasıl Seçilmelidir?
ZFS havuzunun performansı ve arıza toleransı büyük ölçüde kullanılan vdev mimarisine bağlıdır.
Bu nedenle Mirror, RAIDZ1, RAIDZ2 ve RAIDZ3 seçenekleri değerlendirilirken yalnızca kullanılabilir kapasiteye odaklanmak doğru değildir.
Disklerin sayısı, kapasitesi, teknolojisi ve beklenen I/O davranışı birlikte değerlendirilmelidir.
ZFS Mirror
Mirror yapısında aynı veri birden fazla fiziksel diskte tutulur.
İki diskli bir Mirror grubunda disklerden biri arızalandığında diğer disk veri erişimini sürdürebilir.
Mirror topolojileri özellikle rastgele okuma ve yazma işlemlerinin yoğun olduğu sanallaştırma ortamlarında avantaj sağlayabilir.
Çok sayıda sanal makinenin aynı anda küçük bloklarla veri okuduğu veya yazdığı ortamlarda birden fazla Mirror vdev kullanılması uygun bir yaklaşım olabilir.
Bunun temel dezavantajı ise kapasite verimliliğidir.
İki adet 2 TB disk Mirror yapılandırmasında kullanıldığında, yaklaşık 2 TB ham mantıksal kapasite elde edilir. Dosya sistemi ve diğer kullanım giderleri nedeniyle gerçek kullanılabilir kapasite biraz daha düşük olacaktır.
RAIDZ1
RAIDZ1, aynı RAIDZ grubu içerisinde tek disk arızasına karşı koruma sağlar.
Mirror’a göre bazı disk kombinasyonlarında daha yüksek kapasite verimliliği sunabilir.
Ancak büyük kapasiteli disklerde yeniden oluşturma süresi ve ikinci bir disk arızası riski dikkate alınmalıdır.
Bu nedenle kritik kurumsal sistemlerde özellikle büyük HDD grupları için RAIDZ1 seçimi dikkatle değerlendirilmelidir.
RAIDZ2
RAIDZ2, aynı grup içerisindeki iki disk arızasına karşı dayanıklılık sağlar.
Yüksek kapasite ihtiyacı ve veri koruması arasında denge kurmak isteyen ortamlarda tercih edilebilir.
Özellikle dosya arşivleri, yedekleme depoları ve kapasite odaklı iş yüklerinde değerlendirilebilir.
Bununla birlikte sanal makine ve veri tabanı iş yüklerinde RAIDZ2 ile Mirror arasındaki rastgele I/O performansı farkları test edilmelidir.
RAIDZ3
RAIDZ3, aynı RAIDZ grubu içerisinde üç disk arızasına karşı dayanıklılık sağlayan topolojidir.
Genellikle büyük disk grupları ve yüksek veri koruma gereksinimleri bulunan kapasite odaklı depolama sistemlerinde kullanılır.
Daha fazla parite kapasitesi gerektirdiğinden, disk sayısı ve toplam yatırım maliyeti dikkate alınmalıdır.
ZFS RAID Karşılaştırması
| Kriter | Mirror | RAIDZ1 | RAIDZ2 | RAIDZ3 |
|---|---|---|---|---|
| Arıza toleransı | Mirror grubuna bağlı | 1 disk | 2 disk | 3 disk |
| Kapasite verimliliği | Görece düşük | Görece yüksek | Orta/yüksek | Disk sayısına bağlı |
| Rastgele VM I/O | Genellikle güçlü | İş yüküne bağlı | İş yüküne bağlı | İş yüküne bağlı |
| Büyük veri havuzları | Uygun | Risk değerlendirmesi gerekir | Uygun | Uygun |
| Genel kullanım | VM ve veri tabanı | Daha az kritik kapasite havuzları | Arşiv ve depolama | Büyük ve koruma odaklı havuzlar |
Mimari değerlendirme: Çok sayıda sanal makinenin çalıştığı ve düşük gecikmenin önemli olduğu ortamlarda SSD veya NVMe tabanlı Mirror vdev mimarisi sıklıkla avantajlıdır. Buna karşılık büyük dosyaların veya yedek arşivlerinin saklanacağı sistemlerde RAIDZ2 daha verimli bir kapasite yaklaşımı sağlayabilir.
Burada önemli olan, bir topolojiyi tüm sistemler için standart kabul etmek yerine gerçek iş yüküne göre performans testi yapmaktır.
ZFS Pool ile ZFS Directory Arasındaki Fark
Proxmox VE üzerinde ZFS kullanırken sıklıkla karıştırılan konulardan biri, ZFS havuzunun farklı depolama eklentileri üzerinden kullanılabilmesidir.
Bir ZFS havuzu oluşturulduğunda, bu havuzun sanal makine diskleri için ZFS Pool olarak tanımlanması mümkündür.
Bu durumda Proxmox, sanal makine disklerini ZFS’in blok birimleri olan zvol yapıları üzerinden yönetebilir.
ZFS Pool depolama eklentisi, sanal makine diskleri için snapshot ve klonlama özelliklerinden yararlanabilir.
Buna karşılık ISO dosyaları ve klasik yedekleme arşivleri gibi dosya tabanlı içeriklerin saklanması için bir ZFS dataset’i Directory depolama olarak tanımlanabilir.
Örneğin tank adlı bir ZFS havuzu üzerinde tank/templates ve tank/backups adlı dataset’ler hazırlanabilir.
Bu alanlar uygun bağlama noktaları kullanılarak Proxmox’a Directory depolama şeklinde eklenebilir.
Böylece ZFS’in dosya sistemi özelliklerinden yararlanan, ancak Proxmox tarafından dosya tabanlı içeriklerin saklanması amacıyla kullanılan depolama alanları oluşturulmuş olur.
Önemli Bir Snapshot Ayrımı
ZFS dataset’inin Directory depolama olarak tanımlanması, Proxmox’un ZFS Pool eklentisine özgü zvol snapshot mekanizmasının kullanılacağı anlamına gelmez.
Directory üzerinde bulunan QCOW2 disklerin kendi snapshot olanakları ise farklıdır.
Dolayısıyla aynı fiziksel ZFS havuzu üzerinde bulunmalarına rağmen Proxmox depolama eklentisinin sunduğu özellikler değişebilir.
Bu ayrım özellikle üretim ortamlarında snapshot ve geri dönüş senaryoları tasarlanırken dikkate alınmalıdır.
Yerel Depolama mı, Paylaşımlı Depolama mı?
Sanallaştırma altyapılarında önemli mimari kararlardan biri, depolama kaynaklarının her fiziksel sunucuda bağımsız mı tutulacağı, yoksa merkezi bir sistem üzerinden mi sunulacağıdır.
Her iki yaklaşımın da avantajları bulunmaktadır.
Yerel Depolama
Yerel depolama mimarisinde her Proxmox node kendi fiziksel disklerini veya kendisine özel mantıksal depolama kaynaklarını kullanır.
Bu yaklaşım özellikle tek sunuculu sistemlerde sade bir yapı sağlar.
Depolama erişimi için ek bir ağ katmanına ihtiyaç duyulmaması, gecikme ve altyapı karmaşıklığı açısından avantaj sağlayabilir.
Ancak yerel depolamanın en önemli sınırlaması, diğer fiziksel sunucuların aynı verilere otomatik olarak erişememesidir.
Bir node üzerinde bulunan sanal makinenin başka bir node üzerinde çalıştırılması için disk verilerinin taşınması, çoğaltılması veya uygun başka bir mekanizmayla erişilebilir hale getirilmesi gerekir.
Paylaşımlı Depolama
Paylaşımlı depolama mimarisinde birden fazla fiziksel sunucu aynı merkezi depolama altyapısına erişebilir.
NFS, Ceph RBD ve uygun SAN yapılandırmaları bu amaçla kullanılabilir.
Paylaşımlı depolama sayesinde sanal makinelerin farklı node’lar arasında taşınması kolaylaşabilir.
Ancak merkezi depolama kullanılması, depolama sisteminin kendisinin otomatik olarak yüksek erişilebilir olduğu anlamına gelmez.
Örneğin tek kontrolcülü ve tek ağ bağlantılı bir NAS sistemi, birden fazla Proxmox node tarafından kullanılsa bile tek hata noktası oluşturmaya devam edebilir.
Bu nedenle paylaşımlı depolama tasarımında kontrolcü, güç kaynağı, ağ ve disk yedekliliği birlikte değerlendirilmelidir.
NFS, iSCSI ve SAN Depolama Teknolojileri
NFS Depolama
Network File System, dosya seviyesinde ağ depolaması sağlayan bir teknolojidir.
Proxmox VE üzerinde bir NFS paylaşımı tanımlanarak sanal makinelerin disk imajları, ISO dosyaları veya yedekleme içerikleri bu alanda saklanabilir.
NFS özellikle NAS sistemleriyle entegrasyon açısından pratik bir çözüm sunar.
Örneğin kurumda mevcut bir kurumsal NAS altyapısı varsa, uygun performans ve erişilebilirlik koşullarında Proxmox sunucuları bu depolama alanını ortak olarak kullanabilir.
Avantajları
NFS’in önemli avantajlarından biri kurulum ve yönetim kolaylığıdır.
Dosya seviyesinde çalıştığından farklı içerik türlerinin saklanması mümkündür.
Ayrıca uygun yapılandırmada birden fazla Proxmox node aynı verilere erişebilir.
Dezavantajları
NFS performansı ağ gecikmesine, NAS sunucusunun disk performansına ve eşzamanlı bağlantı sayısına bağlıdır.
Bu nedenle yoğun veri tabanı veya yüksek IOPS gerektiren iş yüklerinde altyapının dikkatle test edilmesi gerekir.
NFS sunucusunun arızalanması durumunda bu depolama alanını kullanan sanal makineler etkilenebilir.
iSCSI Depolama
iSCSI, blok seviyesinde depolama hizmetinin IP ağı üzerinden sunulmasını sağlayan bir teknolojidir.
Bu yöntemde Proxmox sunucuları, uzaktaki bir depolama sisteminin sunduğu LUN’lara erişebilir.
iSCSI yaygın olarak kurumsal SAN sistemleriyle birlikte kullanılır.
Ancak bir LUN’un birden fazla sunucu tarafından görüntülenmesi, bu sunucuların herhangi bir dosya sistemini aynı anda güvenli şekilde kullanabileceği anlamına gelmez.
Paylaşımlı erişim için uygun depolama eklentisi, kilitleme mekanizması ve işletim modeli gereklidir.
Avantajları
- Merkezi blok depolama yönetimi
- Mevcut SAN yatırımlarının değerlendirilmesi
- Uygun ağ ve donanımla yüksek performans
- Multipath ve bağlantı yedekliliği olanakları
Dezavantajları
- Ağ ve depolama yapılandırmasının daha dikkatli yapılması gerekir.
- Yanlış paylaşımlı erişim veri bozulmasına neden olabilir.
- Snapshot ve klonlama özellikleri kullanılan entegrasyona bağlıdır.
- SAN kontrolcüleri veya ağ cihazları tek hata noktası oluşturabilir.
NFS mi, iSCSI mi?
Bu iki teknolojiyi karşılaştırırken yalnızca dosya ve blok depolama ayrımına odaklanmak yeterli değildir.
NFS genellikle daha sade bir yönetim yapısı sunarken iSCSI, blok depolama ve SAN tabanlı mimarilerin özelliklerinden yararlanılmasını sağlar.
Hangi yaklaşımın daha iyi performans göstereceği, gerçek donanım ve yazılım yapılandırmasına bağlıdır.
Bazı ortamlarda yüksek performanslı bir NFS sistemi, yetersiz tasarlanmış bir iSCSI altyapısından daha iyi sonuç verebilir.
Bu nedenle seçim yapılırken IOPS, latency, yönetim karmaşıklığı ve arıza senaryoları birlikte değerlendirilmelidir.
Ceph: Dağıtık Depolama ve Hyperconverged Infrastructure
Ceph, Proxmox VE’nin desteklediği dağıtık depolama teknolojilerinden biridir.
Geleneksel SAN mimarisinden farklı olarak Ceph, birden fazla fiziksel sunucunun disk kaynaklarını ortak bir depolama havuzu şeklinde kullanabilir.
Bu yaklaşım özellikle Hyperconverged Infrastructure (HCI) tasarımlarında önem kazanmaktadır.
HCI mimarisinde işlemci, bellek ve depolama kaynakları aynı fiziksel sunucu kümesi içerisinde bütünleşik olarak sunulabilir.
Ceph sayesinde depolama verileri, yapılandırılan koruma politikasına göre birden fazla disk veya fiziksel sunucu üzerinde tutulabilir.
Ceph’in Temel Bileşenleri
OSD (Object Storage Daemon), depolama verilerini fiziksel diskler üzerinde yöneten bileşendir.
MON (Monitor), Ceph kümesinin durumunu ve üyelik bilgisini takip eder.
MGR (Manager), yönetim ve izleme işlevlerine katkı sağlar.
RBD (RADOS Block Device) ise sanal makineler için blok depolama hizmeti sunar.
Proxmox VE üzerinde sanal makine diskleri Ceph RBD üzerinden saklanabilir.
Bu sayede uygun şekilde hazırlanmış birden fazla node aynı dağıtık depolama altyapısından yararlanabilir.
Ceph Veri Koruma Yaklaşımı
Ceph, verilerin farklı depolama aygıtlarında korunmasını sağlayan replikasyon veya uygun havuzlarda erasure coding gibi yöntemler sunar.
Örneğin üç kopyalı bir replikasyon politikası kullanıldığında, veri üç farklı hata alanında tutulacak şekilde yapılandırılabilir.
Bu yaklaşım bir disk veya sunucu arızası durumunda veri erişiminin devam etmesine yardımcı olabilir.
Ancak arıza toleransı, kopya sayısı kadar CRUSH yerleşimine, minimum kopya politikasına ve kümenin genel durumuna da bağlıdır.
Ceph’in Avantajları
Ceph’in en önemli avantajı, depolama kaynaklarını fiziksel sunuculara dağıtarak merkezi bir harici SAN sistemine olan bağımlılığı azaltabilmesidir.
Uygun şekilde tasarlanmış yapılarda fiziksel disk veya node arızalarına karşı dayanıklılık sağlar.
Ayrıca yeni node veya disklerin eklenmesiyle depolama kapasitesinin büyütülmesi mümkün olabilir.
Ceph RBD’nin snapshot ve klonlama desteği, sanallaştırma yönetiminde ek esneklik sağlar.
Ceph’in Dezavantajları
Ceph’in sunduğu avantajlar, geleneksel yerel depolamaya göre daha yüksek mimari ve operasyonel karmaşıklıkla birlikte gelir.
Ceph kümesinin düzgün çalışabilmesi için ağ gecikmesi, disk performansı, CPU ve bellek kaynakları doğru planlanmalıdır.
Replikasyon politikaları depolama kapasitesini de etkiler.
Örneğin üç kopyalı bir mimaride 30 TB ham depolama kapasitesi bulunması, teorik olarak yaklaşık 10 TB veri kapasitesine karşılık gelebilir. Gerçek kullanılabilir kapasite ise operasyonel boş alan gereksinimi, dağılım ve küme ayarları nedeniyle daha düşük olacaktır.
Ayrıca bir node arızalandığında yeniden dengeleme işlemleri sistemin ağ ve disk kaynaklarında ek yük oluşturabilir.
Bu nedenle Ceph altyapısı yalnızca normal çalışma koşullarında değil, arıza ve yeniden oluşturma senaryolarında da test edilmelidir.
Ceph Ne Zaman Tercih Edilmeli?
Ceph, birden fazla fiziksel sunucunun bulunduğu, paylaşımlı depolama ve yüksek erişilebilirlik gerektiren ortamlarda güçlü bir seçenek olarak değerlendirilebilir.
Özellikle fiziksel sunucuların yerel disklerini ortak depolama altyapısına dönüştürmek isteyen kurumlar için avantaj sağlar.
Buna karşılık küçük ve sınırlı kaynaklara sahip ortamlarda Ceph’in getirdiği ek karmaşıklık ve kapasite maliyeti, sağladığı faydadan daha yüksek olabilir.
Depolama Teknolojilerinin Genel Karşılaştırması
Proxmox VE üzerinde kullanılabilecek depolama teknolojilerini değerlendirirken yalnızca desteklenen özellikleri değil, bunların gerçek kullanım koşullarını da incelemek gerekir.
| Teknoloji | Snapshot | Thin Provisioning | Paylaşımlı kullanım | Öne çıkan özellik |
|---|---|---|---|---|
| Directory | QCOW2 ile | QCOW2 ile | Altyapıya bağlı | Esnek dosya depolama |
| LVM | Hayır | Hayır | Uygun SAN ile | Sade blok yönetimi |
| LVM-Thin | Evet | Evet | Hayır | Kapasite verimliliği |
| ZFS Pool | Evet | Evet | Yerel | Veri bütünlüğü |
| NFS | QCOW2 ile | Disk biçimine bağlı | Evet | Merkezi dosya depolama |
| iSCSI + LVM | Standart LVM’de hayır | Hayır | Uygun yapılandırmayla | SAN entegrasyonu |
| Ceph RBD | Evet | Evet | Evet | Dağıtık blok depolama |
Bu tablo tek bir teknolojinin her açıdan üstün olmadığını göstermektedir.
Örneğin LVM-Thin, yerel sanal makine diskleri için sade ve esnek bir çözüm sunarken, ZFS gelişmiş veri bütünlüğü ve snapshot özellikleri nedeniyle öne çıkmaktadır.
NFS ve SAN çözümleri mevcut merkezi depolama altyapısından yararlanmak isteyen kurumlar için değerlendirilebilir.
Ceph ise depolamanın fiziksel sunuculara dağıtılması ve arıza toleransının artırılması hedeflenen ortamlarda güçlü bir alternatiftir.
Depolama Performansı: IOPS, Latency ve Throughput
Bir depolama sisteminin performansını değerlendirirken yalnızca disklerin kapasitesine veya teorik aktarım hızına bakmak yeterli değildir.
Gerçek sanallaştırma performansını belirleyen önemli faktörler arasında IOPS, latency ve throughput bulunmaktadır.
IOPS
IOPS, depolama sisteminin saniyede gerçekleştirebildiği giriş/çıkış işlemi sayısını ifade eder.
Özellikle veri tabanları, ERP sistemleri ve yoğun VDI ortamlarında önemlidir.
Çok sayıda sanal makinenin aynı anda küçük bloklarla işlem yaptığı ortamlarda yüksek IOPS kapasitesi gereklidir.
Ancak IOPS değerinin tek başına değerlendirilmesi doğru değildir. Test sırasında kullanılan blok boyutu, okuma-yazma oranı ve kuyruk derinliği sonucu doğrudan etkiler.
Latency
Latency, depolama isteğine yanıt verilmesi için geçen süreyi ifade eder.
Düşük gecikme özellikle eşzamanlı disk erişimi gerçekleştiren uygulamalarda önemlidir.
Örneğin yüksek aktarım hızına sahip bir depolama sistemi, küçük bloklu ve senkron yazma ağırlıklı veri tabanı işlemlerinde beklenen performansı göstermeyebilir.
Bu nedenle kritik sistemlerde ortalama gecikmenin yanında yüksek yüzdelik gecikme değerlerinin de izlenmesi faydalıdır.
Throughput
Throughput, birim zamanda aktarılabilen veri miktarını ifade eder.
Büyük dosya işlemleri, yedekleme, veri taşıma ve arşivleme senaryolarında öne çıkar.
Örneğin yüksek throughput kapasitesine sahip bir depolama sistemi büyük yedek dosyalarını hızlı aktarabilir. Ancak bu durum, aynı sistemin çok sayıda küçük rastgele yazma işleminde de yüksek performans göstereceği anlamına gelmez.
Donanım ve İş Yükü Birlikte Değerlendirilmeli
SATA SSD, SAS SSD ve NVMe disklerin performansı ve dayanıklılığı farklıdır.
Ancak doğru depolama mimarisi, yalnızca en hızlı diskin seçilmesiyle oluşturulamaz.
RAID topolojisi, ağ altyapısı, senkron yazma gereksinimleri, disk önbelleği ve kapasite doluluk oranı performansı önemli ölçüde etkiler.
Özellikle ZFS ve Ceph altyapılarında performans testlerinin gerçek uygulama davranışlarına benzer koşullarda yapılması önerilir.
Kapasite Planlaması ve Thin Provisioning Riskleri
Depolama kapasitesinin planlanmasında yapılan yaygın hatalardan biri, yalnızca mevcut veri miktarına bakılarak karar verilmesidir.
Oysa kurumsal sanallaştırma ortamlarında kapasite gereksinimi zamanla değişir.
Sanal makinelerin büyümesi, yeni uygulamaların devreye alınması, snapshot birikimi ve yedekleme politikaları toplam depolama ihtiyacını etkiler.
Örneğin 10 TB fiziksel depolama kapasitesine sahip bir altyapıda 7 TB mevcut veri bulunması, kalan 3 TB alanın tamamının yeni sanal makinelere güvenle tahsis edilebileceği anlamına gelmez.
İş yükünün büyüme oranı ve depolama teknolojisinin çalışma gereksinimleri değerlendirilmelidir.
Özellikle thin provisioning kullanılan yapılarda, mantıksal olarak tahsis edilmiş toplam disk kapasitesi ile fiziksel kullanım ayrı ayrı izlenmelidir.
Bir LVM-Thin havuzunda fiziksel kapasitenin dolması, bağlı sanal makinelerin yazma işlemlerini durdurabilir ve veri bütünlüğü sorunlarına yol açabilir.
ZFS ve Ceph gibi yapılarda da havuzun tamamen doldurulması performans, veri yerleşimi ve operasyonel işlemler açısından risk oluşturur.
Bu nedenle kapasite yönetimi için tek bir sabit eşikten ziyade izleme, büyüme tahmini ve önceden kapasite genişletme planı oluşturulmalıdır.
Snapshot, Backup ve Replication: Temel Farklar
Sanallaştırma altyapılarında en sık karıştırılan konulardan biri snapshot, backup ve replication işlemlerinin aynı amaçla kullanıldığı düşüncesidir.
Oysa bu teknolojiler farklı gereksinimlere hizmet eder.
Snapshot: Hızlı Geri Dönüş
Snapshot, sanal makinenin veya depolama nesnesinin belirli bir andaki durumunu korumak için kullanılır.
Özellikle sistem güncellemesi, uygulama kurulumu ve yapılandırma değişiklikleri öncesinde faydalıdır.
Ancak snapshot çoğu zaman birincil depolama altyapısına bağımlıdır.
Dolayısıyla fiziksel depolama sisteminin tamamen kaybedilmesi durumunda snapshot’lar da erişilemez hale gelebilir.
Backup: Veri Kurtarma
Backup, sistemlerin ve verilerin gerektiğinde yeniden oluşturulabilmesi amacıyla yedek kopyalarının hazırlanmasıdır.
Bağımsız depolama hedeflerinde saklanan ve düzenli olarak doğrulanan yedekler, veri kaybı ve felaket kurtarma senaryolarında kritik öneme sahiptir.
Replication: Verinin Başka Bir Ortama Çoğaltılması
Replication, verilerin başka bir sunucuya veya depolama ortamına çoğaltılmasını sağlar.
Özellikle sistem arızalarından sonra hizmetin başka bir altyapıda devam ettirilmesini kolaylaştırabilir.
Ancak yanlışlıkla silinen veya uygulama seviyesinde bozulan veriler de replike edilebilir.
Bu nedenle replication mekanizması bağımsız yedekleme yerine kullanılmamalıdır.
Hangi Amaç İçin Hangisi Kullanılmalı?
| İhtiyaç | Tercih edilen yaklaşım |
|---|---|
| Güncelleme öncesi geri dönüş | Snapshot |
| Yanlışlıkla silinen veriyi kurtarma | Backup |
| Fiziksel sunucu arızasında başka node’a geçiş | HA + uygun depolama |
| Verilerin başka node’da kopyalanması | Replication |
| Fidye yazılımına karşı kurtarma | İzole/korumalı backup |
| Uzun süreli veri saklama | Retention politikasıyla backup |
Kurumsal altyapılarda bu mekanizmaların birbirini tamamlayacak şekilde tasarlanması önerilir.
Proxmox Backup Server ile Veri Koruma
Proxmox Backup Server (PBS), Proxmox VE ortamlarında sanal makine ve konteyner yedeklerinin merkezi olarak yönetilebilmesini sağlayan bir çözümdür.
PBS, artımlı yedekleme ve veri tekilleştirme gibi özelliklerle depolama kapasitesinin daha verimli kullanılmasına yardımcı olabilir.
Ayrıca yedek bütünlüğünün doğrulanması ve farklı PBS sunucuları arasında veri senkronizasyonu için mekanizmalar sunar.
Artımlı Yedekleme
Artımlı yedekleme, önceki yedekleme işleminden sonra değişen veri bloklarının aktarılmasına dayanır.
Bu yöntem, özellikle büyük sanal makinelerde her yedekleme sırasında tüm verinin yeniden gönderilmesi ihtiyacını azaltabilir.
Deduplication
Deduplication, tekrar eden veri bloklarının tekilleştirilmesini sağlar.
Örneğin benzer işletim sistemi dosyalarını içeren çok sayıda sanal makinenin yedeklenmesi sırasında ortak veri bloklarının tekrar tekrar saklanması azaltılabilir.
Kazanım, yedeklenen verilerin benzerliğine bağlıdır.
Backup Verification
Yedekleme işleminin başarıyla tamamlanması, her zaman geri yükleme işleminin sorunsuz gerçekleşeceğini garanti etmez.
Bu nedenle PBS üzerindeki yedeklerin düzenli olarak doğrulanması önemlidir.
Bunun yanında belirli aralıklarla gerçek geri yükleme testleri yapılmalı ve uygulamaların çalışabilirliği kontrol edilmelidir.
Yedekleme Güvenliği
Yedekleme sisteminin üretim ortamından mantıksal veya fiziksel olarak ayrılması, veri güvenliği açısından önemlidir.
Yedekleme kullanıcılarının yetkileri sınırlandırılmalı, yönetim erişimleri korunmalı ve kritik yedeklerin farklı hata alanlarında saklanması planlanmalıdır.
Uygun ortamlarda değiştirilemez veya silmeye karşı korumalı yedekleme mekanizmaları da değerlendirilmelidir.
Yüksek Erişilebilirlik (HA) ve Depolama İlişkisi
Proxmox VE’nin yüksek erişilebilirlik özelliklerinden yararlanmak isteyen kurumların depolama mimarisini cluster tasarımıyla birlikte ele alması gerekir.
HA’nın amacı, belirli donanım veya node arızalarında hizmetin uygun başka bir node üzerinde yeniden başlatılabilmesini sağlamaktır.
Ancak HA’nın başarılı olabilmesi için sanal makinenin disk verilerine hedef node üzerinden erişilebilmesi veya bu verilerin uygun bir mekanizmayla önceden hazırlanmış olması gerekir.
Örneğin üç node’lu bir Proxmox cluster içerisinde sanal makine disklerinin merkezi bir NFS sistemi üzerinde bulunduğunu düşünelim.
Bir node arızalandığında, diğer node uygun koşullarda aynı sanal makine disklerine erişebilir.
Buna karşılık diskler yalnızca arızalanan node’un yerel LVM-Thin havuzunda bulunuyorsa diğer node’un bu verilere otomatik olarak erişmesi mümkün değildir.
Bu nedenle HA tasarımında depolamanın paylaşımlı olması veya yerel depolamaya dayalı desteklenen replikasyon gibi yöntemlerin doğru yapılandırılması gerekir.
Ayrıca cluster quorum, ağ erişimi ve yeterli kaynak kapasitesi de HA davranışını etkiler.
Önemli: HA, her koşulda kesintisiz çalışma anlamına gelmez. Bir node arızasından sonra sanal makinenin başka node üzerinde yeniden başlatılması belirli bir hizmet kesintisi oluşturabilir.
Dolayısıyla gerçek iş sürekliliği hedefleri değerlendirilirken uygulama katmanındaki yüksek erişilebilirlik gereksinimleri de dikkate alınmalıdır.
Kurumsal Proxmox Depolama Mimarisi Senaryoları
Depolama teknolojilerinin avantajlarını daha iyi değerlendirebilmek için farklı ölçeklerdeki sistem ihtiyaçlarını incelemek faydalıdır.
Senaryo 1: Tek Fiziksel Sunuculu Sanallaştırma
Bu senaryoda kurumun sanallaştırma ihtiyacı tek fiziksel sunucu üzerinden karşılanmaktadır.
Sanal makine sayısı sınırlıdır ve merkezi cluster altyapısına ihtiyaç duyulmamaktadır.
Bu ortamda LVM-Thin veya ZFS Mirror uygun seçenekler olabilir.
LVM-Thin, düşük yönetim karmaşıklığı ve esnek kapasite tahsisi sunar.
ZFS Mirror ise disk yedekliliği, veri bütünlüğü ve snapshot ihtiyaçlarının daha gelişmiş şekilde karşılanmasına yardımcı olabilir.
Her iki durumda da ayrı yedekleme hedefi oluşturulması önemlidir.
Senaryo 2: Üç Node’lu Orta Ölçekli Cluster
Bu senaryoda kurumun üç fiziksel Proxmox sunucusu bulunduğunu varsayalım.
Sanal makinelerin farklı node’lar arasında taşınması ve belirli arızalarda otomatik yeniden başlatılması hedeflenmektedir.
Eğer kurumda mevcut yüksek erişilebilir SAN veya NAS altyapısı bulunuyorsa, bu yatırımın Proxmox ile değerlendirilmesi ekonomik ve operasyonel açıdan mantıklı olabilir.
Alternatif olarak sunucuların yerel diskleri kullanılarak Ceph tabanlı bir HCI mimarisi tasarlanabilir.
Ancak Ceph için disk performansı, ağ yedekliliği ve operasyonel yönetim yetkinliği yeterli olmalıdır.
Senaryo 3: Yoğun ERP ve Veri Tabanı İş Yükleri
ERP ve veri tabanı uygulamalarında rastgele disk erişimleri ve düşük gecikme önemli hale gelebilir.
Bu nedenle yalnızca yüksek kapasite sağlayan bir depolama çözümü seçmek yeterli değildir.
SSD veya NVMe tabanlı uygun ZFS Mirror mimarisi ya da yüksek performanslı SAN altyapısı değerlendirilebilir.
Burada önemli olan, gerçek veri tabanı davranışını temsil eden testlerle depolama sisteminin doğrulanmasıdır.
Veri tabanının kendi yüksek erişilebilirlik özellikleri de sanallaştırma altyapısından bağımsız olarak değerlendirilmelidir.
Senaryo 4: Büyük Kapasiteli Yedekleme Ortamı
Yedekleme sistemlerinde yüksek IOPS gereksiniminden çok toplam kapasite, veri bütünlüğü ve sürdürülebilir saklama maliyeti ön plana çıkabilir.
Bu durumda RAIDZ2 veya uygun başka bir yedekli kapasite topolojisi değerlendirilebilir.
Ancak Proxmox Backup Server’ın veri tekilleştirme, doğrulama ve bakım işlemleri nedeniyle metadata erişimi ve rastgele I/O ihtiyaçları da göz ardı edilmemelidir.
Bu nedenle PBS depolama tasarımı yalnızca toplam TB kapasitesine göre yapılmamalıdır.
Proxmox VE Depolama Yapılandırması: Uygulamalı Rehber
Bu bölümde temel depolama türlerinin Proxmox web arayüzü üzerinden nasıl oluşturulabileceğini inceleyelim.
İşlemlere başlamadan önce kullanılacak fiziksel disklerin doğru şekilde tespit edilmesi ve mevcut verilerin yedeklenmesi gerekir.
Uyarı: Disk biçimlendirme, havuz oluşturma ve disk temizleme işlemleri mevcut verilerin silinmesine neden olabilir.
LVM Oluşturma
Proxmox arayüzünde ilgili node seçildikten sonra Disks → LVM bölümüne geçilir.
Create: Volume Group seçeneği kullanılarak uygun disk belirlenir.
Ardından Volume Group adı girilir.
Oluşturulan depolamanın Datacenter seviyesine otomatik eklenmesi isteniyorsa Add Storage seçeneği etkinleştirilir.
İşlem tamamlandıktan sonra ilgili Volume Group, Proxmox depolama yönetimi üzerinden kullanılabilir hale gelir.
LVM-Thin Oluşturma
İlgili node üzerinde Disks → LVM-Thin bölümüne erişilir.
Create: Thinpool seçeneği açılarak kullanılacak uygun disk ve havuz bilgileri belirlenir.
Depolama alanı tanımlandıktan sonra sanal makinelerin diskleri bu havuz üzerinde oluşturulabilir.
LVM-Thin kullanılırken veri ve metadata kapasitesinin ayrı ayrı izlenmesi önerilir.
Directory Oluşturma
Node → Disks → Directory bölümünden yeni bir Directory depolama alanı oluşturulabilir.
Kullanılacak disk seçildikten sonra ext4 veya XFS dosya sistemi belirlenir.
Depolama alanına bir isim atanır ve uygun şekilde Datacenter seviyesine eklenir.
Bu alan ISO, şablon, yedekleme veya sanal makine diskleri için yapılandırılabilir.
ZFS Pool Oluşturma
Node → Disks → ZFS bölümünden Create: ZFS seçeneği açılır.
Havuz adı, RAID topolojisi, kullanılacak diskler ve sıkıştırma seçenekleri belirlenir.
Disklerin özelliklerine uygun ashift değeri seçilerek havuz oluşturulur.
ZFS havuzunun doğrudan VM depolaması olarak kullanılabilmesi için uygun ZFS Pool tanımı yapılır.
Dosya seviyesinde içerikler saklanacaksa ayrıca bir dataset hazırlanarak Directory depolama tanımı oluşturulabilir.
Snapshot Karşılaştırma Testi
Farklı depolama teknolojilerinin davranışını görmek için laboratuvar ortamında iki test sanal makinesi oluşturulabilir.
İlk sanal makine standart LVM üzerinde hazırlanır.
İkinci sanal makine ise LVM-Thin üzerine oluşturulur.
İki makinenin snapshot özellikleri karşılaştırıldığında standart LVM’nin Proxmox VM snapshot desteği sunmadığı, LVM-Thin’in ise bu özelliği desteklediği gözlemlenebilir.
Benzer testler Directory üzerinde RAW ve QCOW2 disk biçimleri kullanılarak gerçekleştirilebilir.
Bu karşılaştırmalar, depolama teknolojilerinin yalnızca kapasite açısından değil, yönetim özellikleri açısından da farklılaştığını gösterir.
Depolama Sağlığının İzlenmesi ve Sorun Giderme
Kurumsal bir sanallaştırma ortamında depolamanın doğru kurulması kadar düzenli izlenmesi de önemlidir.
Özellikle kapasite, disk sağlığı, gecikme, fiziksel hata sayıları ve havuz bütünlüğü gibi veriler düzenli takip edilmelidir.
Proxmox VE üzerinde depolama durumunu incelemek için aşağıdaki komutlardan yararlanılabilir.
Fiziksel disklerin görüntülenmesi:
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTSDosya sistemlerinin kapasite kontrolü:
df -hLVM Volume Group bilgilerinin görüntülenmesi:
vgsLVM-Thin veri ve metadata kullanımının incelenmesi:
lvs -a -o +data_percent,metadata_percentZFS havuz durumunun kontrolü:
zpool statusZFS kapasitesinin görüntülenmesi:
zpool listZFS dataset bilgilerinin görüntülenmesi:
zfs listProxmox depolama durumunun kontrolü:
pvesm statusDepolama yapılandırma dosyasının incelenmesi:
cat /etc/pve/storage.cfgBu komutlar depolama alanlarının çalışma durumunu analiz etmek için yararlı bir başlangıç sağlar.
Ancak üretim ortamlarında yalnızca manuel kontrollerle yetinilmemelidir.
Zabbix veya uygun bir merkezi izleme sistemi üzerinden depolama kapasitesi, fiziksel disk sağlığı, ZFS pool durumu ve sistem performansı için uyarı mekanizmaları oluşturulması önerilir.
Kurumsal Ortamlarda Sık Yapılan Depolama Hataları
Depolama sorunlarının önemli bir bölümü kullanılan teknolojinin yetersizliğinden değil, yanlış yapılandırma veya eksik planlamadan kaynaklanmaktadır.
Fiziksel Kapasitenin Tamamını Kullanmak
Thin provisioning veya ZFS gibi teknolojiler kullanılırken havuz kapasitesinin tamamının tüketilmesi, beklenmedik yazma hatalarına ve performans sorunlarına neden olabilir.
Bu nedenle operasyonel boş alan planlanmalıdır.
Snapshot’ları Yedekleme Olarak Görmek
Snapshot’lar geri dönüş için yararlı araçlar olsa da bağımsız bir veri koruma stratejisinin yerini alamaz.
Yerel Depolamayı Paylaşımlı Olarak İşaretlemek
Proxmox üzerindeki Shared seçeneğinin yanlış kullanılması, node’ların gerçekte erişemediği depolama kaynaklarını ortak olarak gördüğü hatalı yapılandırmalara neden olabilir.
RAID’i Yedekleme Yerine Kullanmak
RAID veya ZFS Mirror, belirli disk arızalarına karşı dayanıklılık sağlar.
Ancak yanlışlıkla silme, fidye yazılımı veya fiziksel felaketler karşısında yeterli koruma sağlamaz.
ZFS’i Donanım Özelliklerini Değerlendirmeden Kurmak
ZFS’in diskleri doğrudan yönetebilmesi önemli avantajlar sunar.
Ancak donanım RAID kontrolcüleri veya disklerin gerçek özelliklerini gizleyen yapılandırmalar, ZFS’in beklenen şekilde çalışmasını olumsuz etkileyebilir.
Ceph’i Yetersiz Ağ Altyapısında Kullanmak
Ceph’in performansı ve kararlılığı, node’lar arasındaki ağ bağlantılarından önemli ölçüde etkilenir.
Özellikle yeniden dengeleme işlemlerinde ağ kapasitesinin yetersiz olması, çalışan sanal makinelerin performansını düşürebilir.
Yedekleme Geri Dönüşlerini Test Etmemek
Yedekleme işlemlerinin başarılı görünmesi, kritik sistemlerin gerçekten geri yüklenebileceğini kanıtlamaz.
Bu nedenle belirli aralıklarla test ortamlarında geri yükleme gerçekleştirilmesi gerekir.
Proxmox VE İçin Önerilen Depolama Tasarım Yaklaşımı
Kurumsal depolama mimarisi oluşturulurken ilk aşamada teknoloji seçmek yerine iş gereksinimlerinin belirlenmesi daha doğru bir yaklaşımdır.
Öncelikle sanal makine sayısı, uygulama türleri, mevcut veri miktarı ve beklenen büyüme değerlendirilmelidir.
Ardından IOPS, latency, yedekleme penceresi, yüksek erişilebilirlik ve kurtarma hedefleri belirlenmelidir.
Bu gereksinimler doğrultusunda uygun depolama teknolojileri karşılaştırılabilir.
Örneğin tek sunuculu, sınırlı bütçeli bir ortamda LVM-Thin yeterli olabilirken, veri bütünlüğü ve gelişmiş snapshot ihtiyacının ön plana çıktığı bir yapıda ZFS daha uygun olabilir.
Birden fazla fiziksel sunucuda yüksek erişilebilirlik hedefleniyorsa NFS, SAN veya Ceph gibi paylaşımlı depolama seçenekleri değerlendirilmelidir.
Bununla birlikte sanallaştırma altyapısının fiziksel arızalara dayanıklı olması, uygulama düzeyinde iş sürekliliğinin garanti edildiği anlamına gelmez.
Bu nedenle depolama mimarisi, yedekleme stratejisi ve uygulama sürekliliği planları birlikte tasarlanmalıdır.
Proxmox VE, farklı ölçeklerdeki işletmelerin depolama ihtiyaçlarını karşılayabilecek oldukça geniş ve esnek bir teknoloji ekosistemi sunmaktadır.
Directory, LVM, LVM-Thin, ZFS, NFS, SAN ve Ceph gibi seçenekler, farklı iş yüklerine ve operasyonel gereksinimlere yönelik çözümler sağlar.
Directory, basit yönetimi ve dosya tabanlı kullanım esnekliğiyle öne çıkar.
LVM, olgun ve sade blok depolama yaklaşımıyla özellikle belirli SAN senaryolarında değerlendirilebilir.
LVM-Thin, thin provisioning ve snapshot desteği sayesinde yerel sanallaştırma altyapılarında pratik bir çözüm sunar.
ZFS, veri bütünlüğü, snapshot, sıkıştırma ve gelişmiş depolama yönetimi özellikleriyle güçlü bir yerel depolama seçeneğidir.
NFS ve SAN, birden fazla sanallaştırma sunucusunun merkezi depolama kaynaklarına erişmesi gereken ortamlarda kullanılabilir.
Ceph ise dağıtık depolama ve HCI gereksinimleri bulunan kurumsal ortamlarda önemli avantajlar sağlayabilir.
Ancak herhangi bir depolama teknolojisinin tek başına yüksek performans, veri güvenliği ve iş sürekliliği sunacağını varsaymak doğru değildir.
Başarılı bir depolama altyapısı; doğru donanım seçimi, uygun disk topolojisi, kapasite planlaması, performans testleri, merkezi izleme ve güvenilir yedekleme stratejisinin birlikte uygulanmasıyla oluşturulur.
Sonuç olarak Proxmox VE üzerinde depolama seçimi yapılırken yalnızca hangi teknolojinin daha fazla özellik sunduğuna değil, kurumun gerçek iş yüklerine, teknik gereksinimlerine, bütçesine ve operasyonel yönetim kapasitesine odaklanılmalıdır.
Doğru tasarlanmış bir depolama mimarisi, yalnızca sanal makinelerin daha iyi çalışmasını sağlamaz; aynı zamanda beklenmeyen kesintilerin azaltılmasına, veri kaybı riskinin yönetilmesine ve altyapının sürdürülebilir şekilde büyütülmesine önemli katkı sağlar.
