Merhabalar,
Bugün OpenShift Virtualization Platform için depolama opsiyonlarını konuşacağız. Sanallaştırma ortamının sağlıklı çalışabilmesi için depolama ihtiyaçlarını listelememiz ve bu ihtiyaçlar için nasıl bir yaklaşım benimseyeceğimizi netleştirmemiz kritik bir öneme sahiptir. Sanal makineleri konteynerler içinde çalıştırmamızı sağlayan işlem, “container-native virtualization” olarak isimlendiriliyor. Bu işlemi mümkün kılan ise “KubeVirt”. KubeVirt, bir açık kaynak projesidir. Orkestrasyon platformu olarak kullandığımız Kubernetes ile, sanal makineleri dağıtmamızı, çalıştırmamızı ve yönetmemizi sağlıyor. Yani başka bir deyişle, KubeVirt, sanal makineleri konteynerler içinde paketlememizi ve iş yüklerini yönetmemizi sağlıyor. KubeVirt sayesinde, Kubernetes üzerinde, sanal makineler, geleneksel ortamda olduğu gibi davranabiliyor. Sanal makineleri, konteyner yapıya dönüştürülen mikroservisler ve cloud-native uygulamalarla aynı ortamda çalıştırabiliyorsunuz. KubeVirt’in sponsorluğunu CNCF yürütüyor. KubeVirt aynı zamanda, Red Hat OpenShift Virtualization Platformun açık kaynak temelini de oluşturur. Red Hat OpenShift’in bir özelliğidir. Bu özellik, geleneksel sanal makinelerin, hibrit bulut uygulama platformuna migrasyonunu sağlar ve yönetir. KubeVirt bunu, Kubernetes’in API’sinin çalışma alanını genişleterek yapıyor. Böylelikle Kubernetes Kaynakları ve araçlarıyla etkileşime girildiği gibi sanal makinelerle de etkileşime girilebiliyor.
VM’ler için depolama ihtiyaçlarını konuşmadan önce, gelin OpenShift Virtualization Platform’un kalıcı depolama terminolojisini biraz hatırlayalım.
StorageClass: Disklerin hangi storage backend ve hangi parametrelerle oluşturulacağını tanımlar (hangi CSI driver, hangi pool/tier, reclaimPolicy, volumeBindingMode vb.). Gerçek volume’u oluşturmaz; CSI driver’a nasıl oluşturacağını söyler.
StorageProfile: Her StorageClass için otomatik oluşur. VM diskleri için varsayılan VolumeMode (Block / Filesystem) ve accessModes (RWO: ReadWriteOnce, RWX:ReadWriteMany, ROX: ReadOnlyMany) değerlerini tutar (CDI tarafından kullanılır). Storage backend’i değiştirmez, sadece CDI’ye varsayılan ayar sağlar. Gerçek accessModes desteği CSI driver ve storage backend tarafından belirlenir.
DataVolume: VM diskini image import, clone veya upload yoluyla oluşturmak için kullanılır. DV oluştuktan sonra, CDI otomatik PVC oluşturur.
Containerized Data Importer (CDI): DataVolume’leri izler. Image import, clone ve upload işlemlerini gerçekleştirir. Gerekirse scratch PVC oluşturur. DV’ye bağlı PVC’yi otomatik yaratır ve importer pod başlatır.
PersistentVolumeClaim (PVC): Disk talebidir (boyut, accessModes ve storageClass belirtilir).
PersistentVolume (PV): CSI driver backend’de volume oluşturur; Kubernetes bu volume için bir PV objesi oluşturur ve PVC ile bind eder.
OpenShift Virtualization ortamında sanal makine disklerinin oluşturulması ve yönetimi, Kubernetes depolama mimarisinin temel bileşenleri üzerine kuruludur. Bu süreç genellikle StorageClass ile başlar. StorageClass, kullanılacak depolama altyapısını ve bu altyapının hangi parametrelerle çalışacağını tanımlar. Örneğin hangi CSI (Container Storage Interface) driver’ının kullanılacağı, hangi depolama havuzunun seçileceği, reclaimPolicy, volumeBindingMode gibi parametreler StorageClass içinde belirlenir. StorageClass doğrudan bir depolama alanı oluşturmaz; bunun yerine arka uçtaki depolama sistemine bir volume’un hangi özelliklerle oluşturulacağını tanımlayan bir şablon görevi görür.
OpenShift Virtualization ortamında CDI (Containerized Data Importer) bileşeni, cluster’daki StorageClass nesnelerini izleyerek her biri için otomatik olarak bir StorageProfile kaynağı oluşturur ve yönetir. StorageProfile, özellikle sanal makine diskleri için varsayılan yapılandırmaları tanımlar. Bu yapılandırmalar arasında disklerin volumeMode değeri (Block veya Filesystem) ve accessModes seçenekleri (örneğin ReadWriteOnce – RWO veya ReadWriteMany – RWX) bulunur. StorageProfile doğrudan depolama altyapısını değiştirmez; bunun yerine CDI bileşenine varsayılan disk davranışlarını sağlar. Kullanıcı bir StorageClass seçtiğinde, o StorageClass ile ilişkili StorageProfile ayarları arka planda otomatik olarak devreye girer.
Sanal makine disklerinin veri ile doldurulması ve imaj tabanlı oluşturulması sürecinde Containerized Data Importer (CDI) önemli bir rol oynar. CDI, DataVolume adı verilen kaynakları izleyerek disklerin oluşturulmasını ve veri aktarımını yönetir. Bir DataVolume tanımlandığında CDI arka planda otomatik olarak bir PersistentVolumeClaim (PVC) oluşturur. PVC, kullanıcının talep ettiği depolama kapasitesini ve erişim tipini temsil eder. Eğer ortamda dynamic provisioning kullanılıyorsa, Kubernetes bu PVC talebine karşılık olarak ilgili CSI driver aracılığıyla arka uç depolama sisteminde bir volume oluşturur ve bunu PersistentVolume (PV) olarak kaydeder. Daha sonra PVC ile PV eşleştirilir (bind edilir). PV, depolama sisteminde gerçekten tahsis edilmiş olan fiziksel veya mantıksal depolama alanını temsil eder.
DataVolume kullanmanın en önemli avantajlarından biri, sanal makine disklerinin doğrudan veri ile doldurularak oluşturulabilmesidir. DataVolume aracılığıyla bir disk; mevcut bir imajdan import edilerek, başka bir diskten klonlanarak veya bir yerel kaynaktan upload edilerek oluşturulabilir. Böylece sanal makine, boş bir disk yerine işletim sistemi imajı ile önceden hazırlanmış bir diskle başlatılabilir. Bu yaklaşım özellikle hızlı VM dağıtımı, otomasyon ve imaj tabanlı sanal makine yönetimi senaryolarında önemli kolaylık sağlar.
Bununla birlikte disk oluşturma işlemleri her zaman CDI üzerinden yürütülmek zorunda değildir. Kullanıcı isterse CDI kullanmadan doğrudan bir PersistentVolumeClaim (PVC) oluşturabilir ve bu diski sanal makineye bağlayabilir. PVC oluşturulurken ilk adım, kullanılacak StorageClass’ın seçilmesidir. StorageClass seçimi, arka planda hangi depolama sisteminin ve hangi parametrelerin kullanılacağını belirler. Kullanıcı ayrıca talep ettiği kapasiteyi ve erişim modunu da bu aşamada tanımlar.
Eğer PVC boş bir disk olarak oluşturulmuşsa, bu disk daha sonra sanal makine kurulumu sırasında işletim sistemi ile doldurulabilir. OpenShift Virtualization arayüzünde bir sanal makine oluşturulurken bu boş disk seçilebilir. VM başlatılırken bir kurulum kaynağı (örneğin bir ISO dosyası) eklenir. Sanal makine bu ISO üzerinden boot eder ve işletim sistemi kurulum süreci başlatılır. Kurulum tamamlandığında işletim sistemi boş disk üzerine yazılmış olur ve disk kullanılabilir hale gelir.
VM’ler için depolama ihtiyaçları neler?
Canlı migrasyon için RWX (ReadWriteMany) volume’lere ihtiyacımız var. Yani volume’ün birden fazla node’a bağlanabilir ve birden fazla node tarafından erişilebilir olmasını ifade eder. Bu şu demek değil, tüm node’lar aynı anda güvenli şekilde yazabilir. Genelde bu iki kavram karıştırılıyor. Blok diskler için, seçeceğiniz Depolama biriminin CSI driver özelliklerine dikkat etmeniz kritik.
VM provizyonlama için disk alanı gerekir.
Volume snapshot ve volume clone ihtiyacınız varsa ki, olmalı, her CSI desteklemeyebilir. Varsayılan olarak varı kabul etmeden, kullanacağınız CSI driver’a bakın.
Containerized Data Importer (CDI) kavramını da açıklamamız iyi olur. Containerized Data Importer (CDI) projesi, DataVolume nesneleri aracılığıyla sanal makinelerde kullanılmak üzere içi doldurulmuş (populated) Persistent Volume Claim’ler (PVC) oluşturulmasını sağlar. CDI’nin üç temel kullanım senaryosu vardır: Bir disk imajını bir web sunucusundan veya container registry’den bir DataVolume’e aktarmak (import etmek), mevcut bir PVC’yi bir DataVolume’e klonlamak ve yerel bir disk imajını bir DataVolume’e yüklemek.
VM Disk büyütmek için disk alanına ihtiyaç duyarız. Pek çok CSI driver bunu sağlar, ama yine de kullanacağınız CSI’I kontrol edin.
Sanal makinelerin yedeklenmesi için Volume Snapshot ve CSI içindeki volume consistency group (VolumeGroupSnapshot) mekanizmaları kullanılır. Bu yapılar, birden fazla diske sahip bir sanal makinenin veya birden fazla sanal makineden oluşan bir grubun “crash-consistent” (ani durma anındaki duruma eşdeğer) yedeğini almayı sağlar. Ancak yedekleme işlemlerinin büyük ortamlarda verimli çalışabilmesi için Change Block Tracking (CBT) gereklidir. CBT, diskte değişen blokları takip ederek sadece değişen verinin yedeklenmesini mümkün kılar ve böylece incremental (artımlı) yedekleme yapılabilir. CBT CSI spesifikasyonunun bir parçasıdır, ancak günümüzde birçok disk birimi sağlayıcısı tarafından henüz yaygın olarak desteklenmemektedir.
Volume replication, CSI standardının bir parçası değildir. Bu nedenle bir volume’ün başka bir site’a replike edilmesini talep etmek için standart bir CSI API mekanizması yoktur. Aynı durum, replike edilen volume’ler için consistency group yönetimi için de geçerlidir. Ancak pratikte replikasyon genellikle storage katmanında, üreticiye özgü (vendor-specific) mekanizmalarla gerçekleştirilir. SAN veya NAS sistemlerinde array-level replication (senkron veya asenkron) kullanılırken, dağıtık storage çözümlerinde backend replikasyon özellikleri devreye girer. Kubernetes ortamında ise bu replikasyon süreçleri genellikle storage sağlayıcının kendi araçları veya ek operatörler aracılığıyla yönetilir; failover ve DR orkestrasyonu ise cluster yönetim araçları veya GitOps tabanlı yaklaşımlarla sağlanır.
Ölçeklenebilirlik (Scalability): Storage sisteminin binlerce volume’u destekleyebilecek ve aynı anda yüzlerce volume için attach/detach işlemlerini gerçekleştirebilecek kapasitede olması gerekir. Büyük bare metal cluster’lar binlerce sanal makine çalıştırabilir. Planlı ya da plansız bakım durumlarında, yüzlerce sanal makinenin node’lar veya cluster’lar arasında taşınması gerekebilir.
Yukarda da defalarca vurguladığım gibi, bu özelliklerin çoğu CSI’dan beklenir. Yani CSI’ın bu özlelikleri desteklemesi beklenir. Dolayısıyla Depolama Birimi seçerken CSI driver’ın özelliklerini dikkatlice incelemenizi öneririm.
VM’lere depolama alanı sağlarken üç farklı mimari yaklaşımdan söz edebiliriz. Depolama alınımızı, SAN (Storage Area Network), NAS (Network Attached Storage) veya dışarda kurulu SDS (Software-Defined Storage) seçebiliriz. Her biri için CSI’a ihtiyaç duyarız. SDS çözümü olarak internal disklerini kullanacağımız cluster node’ları (storage node) yapılandırabiliriz. Diğer bir opsiyon, shared-disk file system, birden fazla bilgisayarın disk seviyesinde (block level) doğrudan erişim sağlayabilmesi için bir depolama alanı ağı (SAN) kullanan bir dosya sistemidir. Arctera (Veritas) Infoscale Operator, IBM Fusion Access for SAN mesela örnek olarak verilebilir. Bu opsiyon, Vmware’de ki VMFS (Virtual Machine File System) yapısına benzer.
İlk yaklaşımı ele alalım. Dışarda CSI driver ile kullanacağımız bir depolama alanı var. SAN/NAS olabilir.
Böyle bir seçim, içerde zaten SAN/NAS yatırımı olduğu için sıcak karşılanabilir. Fakat böyle bir seçimde, dış bir depolama birimi olarak kullanacağımız yapının, CSI özellikleri beklentilerimizi karşılayacak olgunlukta olmalı. Özellikle live migration, snapshot, clone, backup gibi ihtiyaçları karşılıyor mu bakmak gerekiyor. Depolama birimi yöneticileri, OpenShift’in dinamik olarak volume provizyonlamasına sıcak bakmayabilir. VM başına küçük LUN’lar oluşturmak SAN Depolama mantığıyla uyuşmayabilir. Üreticinin teknik notlarına detaylı bakmak gerekir. Sektörde, Dell, HPE, Infinidat, Hitachi, NetApp, Pure Storage, IBM Storage gibi CSI driver’ı olan pek çok üretici var.
İkinci opsiyonda, SDS olarak kullanabileceğim node’ların internal diskleri var. Ortamın iş yüküne göre ayrı storage node’lar veya worker node’ları da storage node olarak kullanacağımız bir yapı oluşturabiliriz. Elbette burada yine SDS’in CSI driver’ı devrede olur. Aynı şekilde CSI driver’ın beklentilerimizi karşılayıp karşılamadığına bakmamız gerekir. IBM Fusion Storage, Portworx, Red Hat OpenShift Data Foundation gibi çözümleri araştırabilirsiniz. SDS’i OpenShift’in içinde kullandığınızda, platform ekibi Depolama biriminin sorumluluğunu da almış olur. Bu genellikle platform yöneticilerinin istemediği bir durumdur. İstememekte de haklılar, çünkü depolama ayrı bir disiplindir ve ayrı uzmanlık gerektirir.
Üçüncü durumda, SDS’i SAN üzerinden kullanabiliriz.
SDS’in SAN üzerinden kullanılmasını önermiyoruz. Çünkü, SAN’in yedekli yapısı, SDS’in yedekli mantığıyla örtüşecek ve gecikme sürelerini artıracaktır. Yani bir write işlemi belki üç kez yazılacak veya daha fazla. SAN’in lisans ve yönetim maliyetlerine ek olarak, SDS’de ayrı lisans ve yönetim maliyetleri getirecektir. Elbette yine SDS’in CSI driver yeteneklerini kontrol etmemiz gerekiyor.
Dördüncü opsiyon ise, paylaşımlı disk dosya sistemidir. Shared-disk dosya sistemleri, SAN’ları (Storage Area Network) verimli şekilde kullanmak için geliştirilmiştir. Bu yapı, cluster’daki tüm node’lar arasında paylaşılan tek ve büyük bir LUN oluşturulması ve bu LUN üzerine bir dosya sistemi kurulması mantığıyla çalışır. Böylece aynı dosya sistemi cluster’daki tüm node’lar tarafından ortak olarak kullanılabilir. OpenShift ortamında ise bu işlemi gerçekleştirme sorumluluğu CSI driver’a aittir. IBM Fusion Access for SAN ve Arctera (Veritas) Infoscale Operator bu opsiyon için uygun çözümlerdir.
CSI driver, sanal makinelerin paylaşılan disk dosya sistemi (shared-disk filesystem) içindeki doğru disk dosyasına erişmesini sağlamaktan sorumludur. Bu aşamadan sonra, sanal makine ile arkasındaki fiziksel depolama arasında ek bir yazılım katmanı kalmaz. Bu nedenle, bu yaklaşım teorik olarak doğrudan CSI driver kullanılan yöntem kadar yüksek performans sunabilir.
Shared-disk dosya sistemleri, node’lar arasındaki kilitleme (inter-node locking) mekanizmasının çalışma şekli nedeniyle bazen kullanılabilecek node sayısı açısından sınırlamalara sahip olabilir. Bu yüzden bu yaklaşım, orta ölçekli OpenShift cluster’ları (yaklaşık 40 node’a kadar) için daha uygundur. Shared-disk dosya sisteminden ötürü lisans maliyetleri yüksek çıkabilir.
Her dört opsiyon içinde avantajları ve dezavantajları aşağıdaki gibi özetleyebiliriz.
External Storage with Direct CSI (Doğrudan CSI ile Harici Storage)
Avantajlar:
Verimli çalışır.
Yatırımı korur.
Dezavantajlar:
Tüm storage üreticilerinin olgun (mature) CSI driver’ı yoktur.
Bazı SAN sistemleri çok sayıda küçük LUN’u destekleyecek şekilde tasarlanmamıştır.
Bazı kurumlar, dinamik volume oluşturma için OpenShift’e SAN erişim kimlik bilgilerini (credentials) vermek istemeyebilir.
Internal Storage with SDS (Cluster içi SDS kullanımı)
Avantajlar:
Verimli çalışır.
Kubernetes ile doğal uyumludur (cloud-native yaklaşım).
Dezavantajlar:
Operasyonel karmaşıklık (cognitive burden) platform ekibini zorlayabilir.
Storage yönetimi platform ekibinin sorumluluğuna geçer.
SDS over SAN (SAN üzerinde SDS katmanı)
Avantajlar:
Mevcut SAN yatırımını korur.
Dezavantajlar:
Daha yüksek gecikme (latency).
SDS yazılım lisansı ve toplam sahip olma maliyeti (TCO) nedeniyle daha yüksek maliyet.
Write amplification (yazma işlemlerinin katmanlar arasında çoğalması).
Operasyonel karmaşıklık artar.
Shared-Disk File Systems (Paylaşımlı Disk Dosya Sistemleri)
Avantajlar:
CSI’yi doğrudan desteklemeyen eski SAN sistemleri dahil olmak üzere her SAN ile çalışabilir.
SAN yatırımlarını koruyarak cluster-aware erişim sağlar.
VMware’deki VMFS modeline benzer yapı sunar.
Dezavantajlar:
Ölçeklenebilirlik sınırlamaları olabilir (node sayısı arttıkça kilitleme mekanizması karmaşıklaşabilir).
Paylaşımlı dosya sistemi yazılım lisansı nedeniyle daha yüksek maliyet oluşabilir.
Bu durumda aşağıdaki gibi bir karar ağacı kullanabiliriz.
Sarav Asiye Yiğit * 12 Mart 2026
Kaynakça:
https://developers.redhat.com/articles/2025/07/10/storage-considerations-openshift-virtualization
https://www.redhat.com/en/topics/virtualization/what-is-kubevirt#:~:text=KubeVirt%20is%20an%20open%20source,as%20the%20underlying%20orchestration%20platform.
https://developers.redhat.com/topics/kubernetes#kubernetesresources
https://cloud.redhat.com/learning/learn:high-level-guide-red-hat-openshift-virtualization-vmware-admin/resource/resources:navigating-storage-options-openshift-virtualization-vmware-admins
https://www.redhat.com/en/blog/high-performance-storage-openshift-virtualization-review-lightbits-labs
https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/virtualization/storage
https://docs.redhat.com/en/documentation/openshift_container_platform/4.8/html/storage/understanding-persistent-storage
https://docs.kubermatic.com/kubermatic-virtualization/main/architecture/concepts/storage/
https://www.hitachivantara.com/en-us/pdf/architecture-guide/red-hat-openshift-virtualization-with-ucp-vsp-one-block.pdf
https://kubevirt.io/user-guide/storage/containerized_data_importer/
https://en.wikipedia.org/wiki/Clustered_file_system#SHARED-DISK
https://www.ibm.com/docs/en/fusion-software/2.12.x?topic=fusion-access-san
https://access.redhat.com/sites/default/files/attachments/openshift_virtualization_architecture_guide_v1.0.0.pdf
https://www.openvirtualization.pro/openshift-virtualization/