Doğru Bir Sanallaştırma Sistemi Nasıl Tasarlanmalıdır?
Sanallaştırma sistemleri, fiziksel donanım kaynaklarının daha verimli kullanılmasını sağlamak amacıyla geliştirilmiş altyapılardır. Temel hedefleri, kaynak israfını önlemek, servislerin yalıtımını sağlamak ve sistem sürekliliğini garanti altına almaktır. Bu bağlamda, farklı servislerin birbirini etkilemesini engellemek ve donanım sürücüleri gibi bileşenlerden doğabilecek sistemsel kararsızlıkları azaltmak mümkündür. Özellikle servislerin kesintisiz çalışması açısından sanallaştırma altyapıları önemli avantajlar sağlar.
Sanallaştırma sistemlerinin yalnızca kaynak paylaşımını sağlaması değil, aynı zamanda servis sürekliliği perspektifiyle de kurgulanması gerekir. Bu noktada yüksek erişilebilirlik kavramı öne çıkar. Cluster yapıları ile entegre çalışan sanallaştırma altyapılarında, sistemin belirli bir parçasının devre dışı kalması durumunda geri kalan bileşenlerin hizmetin kesintiye uğramadan devam etmesini sağlayacak yeterlilikte olması beklenir. Bu nedenle kaynak planlaması yapılırken, cluster yapısının node sayısı dikkate alınarak rezerv kapasite hesaplanmalıdır.
İki node’lu bir yapıda, sistemin %50’sinden fazlasının tek bir node üzerine taşınması durumunda kaynak darboğazı yaşanması olasıdır. Benzer şekilde üç node’lu bir yapıda teorik olarak iki node’un tüm sistemi çalıştırması gerekir ve bu durumda kaynak planlaması sistem yükünün maksimum %66’sını kapsayacak şekilde yapılmalıdır. Bu oran dört node için %75, beş node için %80, altı node için ise %83 olarak hesaplanabilir. Bu değerler, cluster yapılarında “N-1 toleransı” prensibiyle belirlenir ve yüksek erişilebilirlik hedeflerinin sağlanmasında temel kabul edilir.
Sanallaştırma ortamlarında kullanılan bazı hiper yöneticiler (hypervisor) kaynak kullanım verimliliğini artırmaya yönelik bazı yazılım düzeyi özellikler sunar. Bunlar arasında memory ballooning, memory deduplication, zRam, zSwap, FlasCache, FlashSwap, CPU affinity, CPU limit gibi mekanizmalar öne çıkar. Bu özellikler sayesinde kaynaklar dinamik olarak dağıtılabilir ve aşırı yüklenme durumlarında sistem performansı düşmeden servislerin ayakta kalması sağlanabilir. Örneğin iki node’lu bir yapı, teorik olarak tam yük devri için %50 kapasite kullanımıyla sınırlandırılmalı olsa da, yukarıda belirtilen özelliklerin etkin kullanımı ile bu sınır %75 seviyesine kadar esnetilebilir.
N Nodelu Cluster Mimarilerinde Yük Planlama Tablosu (N-1 Kuralı)
| Toplam Node Sayısı | Maksimum Yükleme Oranı (%) | Açıklama |
| 2 node | %50 | 1 node arızasında diğer node tüm yükü taşımalı |
| 3 node | %66 | 2 node ile sistem devam etmeli |
| 4 node | %75 | 3 node ile tüm yük taşınabilir olmalı |
| 5 node | %80 | 4 node aktif kaldığında sistem kesintisiz olmalı |
| 6 node | %83 | 5 node yeterli olmalı, kaynak kullanımı dengelenmiş |
| 7 node | %85 | Kaynak verimliliği artar, esneklik yükselir |
| 8 node | %87 | HA kapsamı genişler |
Bu oranlar, “en kötü durumda bir node kaybı” (N-1) senaryosuna göre planlanmıştır. Daha fazla node kaybı öngörülüyorsa (örneğin N-2), oranlar düşürülmelidir.
Gerçekçi Örnek: 4 Node’lu Bir Sanallaştırma Kümesinde Kaynak Planlaması
- Toplam Node: 4
- Her Node: 2 x Xeon E5-2660 v4 (14 core) = 28 fiziksel çekirdek
- Toplam Fiziksel Çekirdek (4 node): 112 core
- Hyper-threading ile Toplam vCPU: 224
- Toplam RAM (örneğin): 4 x 256 GB = 1024 GB
N-1 Kuralı Gereği Kullanılabilir Maksimum Yük:
- vCPU kapasitesi: 224 × 0.75 = 168 vCPU
- RAM kapasitesi: 1024 GB × 0.75 = 768 GB
Sistemin en fazla bu kaynak yükünü aşmayacak şekilde VM’lerle yapılandırılması, olası node kaybında sistemin ayakta kalmasını garanti eder.
🔁 Dinamik Kaynak Yönetimi Aktifse (Memory Ballooning, CPU Limit vb.)
Bazı hiper yöneticilerle birlikte bu oranlar daha esnek olabilir. Örneğin, yukarıdaki sistemde teorik %75 sınırı, gözlemlenmiş yükler ve dinamik bellek yönetimi sayesinde %85–90’a kadar çıkarılabilir. Fakat bu durumda:
- Yük profili sürekli izlenmeli
- Overcommit oranı kontrollü tutulmalı
- VM’ler kritik önceliklerine göre gruplandırılmalı
Sanallaştırma sistemlerinde başarım kadar deterministik davranış analizi de önemlidir. Özellikle aşırı yük, node kaybı, donanım arızası gibi senaryolarda sistemin nasıl tepki verdiğinin bilinmesi, ileriye dönük kapasite planlaması açısından değerlidir. Donanım uyumluluğu, ağ segmentasyonu, depolama yapılarının niteliği ve yedekleme stratejileri de bir sanallaştırma sisteminin doğru şekilde yapılandırılmasında göz önünde bulundurulması gereken diğer başlıklardır.
Sonuç olarak doğru bir sanallaştırma altyapısı, sadece misafir işletim sistemlerini çalıştırmakla kalmaz; iş yüklerinin sürekliliğini sağlayacak şekilde tasarlanmalı, olası arıza senaryolarında sistemin ayakta kalmasını garanti edecek kaynak rezervleri ve mekanizmalar barındırmalıdır. Bu bağlamda sistemin tasarımı; donanım, yazılım ve operasyonel yönetim perspektifinde bütünsel olarak ele alınmalıdır.
Sanallaştırma altyapılarında kaynak planlaması yapılırken yalnızca toplam CPU ve RAM miktarına odaklanmak yeterli değildir. Özellikle sistemin efektif çalışabilmesi için CPU-RAM oranı, depolama mimarisi ve kullanılan teknolojilerin karakteristikleri birlikte değerlendirilmelidir. Bu bağlamda, üretici firmalar tarafından önerilen bazı oranlar ve yapılandırma prensipleri, sistemin kararlılığı ve performansı açısından kritik öneme sahiptir.
Öncelikle, sanallaştırma sistemine eklenen RAM miktarının, sistem performansını doğrudan artıracağı varsayımı her zaman geçerli değildir. RAM’in efektif kullanımı, CPU kapasitesiyle doğrudan ilişkilidir. Örneğin, VMware’in teknik dökümantasyonlarında da belirtildiği üzere, fiziksel CPU başına düşen sanal CPU (vCPU) ve RAM miktarları dengeli olmalıdır. Aksi takdirde, CPU darboğazı oluşabilir ve bellek kaynakları etkin kullanılamaz hale gelir.
Depolama mimarisi de bu dengeyi doğrudan etkileyen bir diğer faktördür. Geleneksel depolama sistemlerinde (örneğin DAS veya klasik RAID yapıları), CPU ve RAM kaynaklarının disk I/O performansı üzerindeki etkisi sınırlıdır. Ancak yazılım tanımlı depolama (SDS) çözümlerinde durum farklıdır. Ceph, GlusterFS, vSAN gibi SDS sistemlerinde veri replikasyonu, hata toleransı, metadata yönetimi gibi işlemler doğrudan CPU ve RAM kaynaklarıyla gerçekleştirilir. Bu nedenle, SDS mimarilerinde disk başına CPU ve RAM gereksinimleri daha belirgindir.
Genel saha tecrübelerine ve üretici önerilerine göre:
- Disk başına 1 fiziksel CPU çekirdeği önerilir (özellikle Ceph gibi replikasyon yapan sistemlerde).
- Disk başına 1–4 GB RAM arası bellek tahsisi yapılmalıdır. Eğer veri sıkıştırma ve tekilleştirme gibi işlemler aktif değilse, bu oran genellikle 1:1 seviyesinde tutulabilir. Ancak bu tür işlemler aktifse, RAM ihtiyacı artar.
- Örneğin, 12 diskli bir SDS nodunda, minimum 12 çekirdek CPU ve 48 GB RAM yalnızca depolama servisleri için ayrılmalıdır. Bu kaynaklar, sanal makineler için kullanılacak toplam kapasitenin dışında planlanmalıdır.
Bu tür planlamalar yapılırken, sistemin yalnızca anlık performansı değil, aynı zamanda servis sürekliliği ve hata toleransı da göz önünde bulundurulmalıdır. Özellikle yüksek erişilebilirlik hedeflenen yapılarda, SDS sisteminin kendi içindeki replikasyon ve iyileştirme süreçleri, CPU ve RAM kaynaklarını yoğun şekilde kullanabilir. Bu nedenle, bu kaynakların sanal makinelerle paylaşılması önerilmez.
Sonuç olarak, sanallaştırma altyapılarında CPU, RAM ve disk kaynakları arasındaki ilişki, kullanılan depolama mimarisi ve sistemin işlevsel gereksinimlerine göre dikkatle planlanmalıdır. Üretici dokümantasyonları ve saha testleri, bu planlamanın temel referans noktaları olmalıdır. Aksi takdirde, sistemin kararlılığı ve hizmet kalitesi olumsuz etkilenebilir.
Aşağıda, önde gelen sanallaştırma ve altyapı üreticilerinin teknik dokümantasyonlarında yer alan CPU/RAM oranlarına ilişkin önerileri karşılaştırmalı olarak sunuyorum. Bu oranlar, sistemin kararlı çalışması, kaynakların dengeli kullanımı ve performans optimizasyonu açısından üretici tavsiyelerine dayanmaktadır.
Sanallaştırma Sistemlerinde Üretici Bazlı CPU/RAM Oranları
| Üretici / Platform | Önerilen CPU:RAM Oranı | Açıklama | Kaynak |
| VMware vSphere 8.0 | 1 vCPU : 4–6 GB RAM | Genel iş yükleri için önerilen başlangıç noktasıdır. Hafif yüklerde 1:2 de mümkündür. | VMware vSphere 8.0 Performance Best Practices |
| OpenStack (Nova) | 1 fiziksel CPU : 16 vCPU | CPU overcommit oranı 16:1 olarak tanımlanmıştır. RAM için önerilen overcommit oranı 1.5:1’dir. | OpenStack Architecture Design Guide |
| Microsoft Hyper-V | 1 vCPU : 4 GB RAM | Dynamic Memory ile esneklik sağlansa da başlangıç yapılandırması için bu oran önerilir. | Microsoft Hyper-V Planning Docs |
| Red Hat Virtualization / KVM | 1 vCPU : 2–6 GB RAM | NUMA uyumu ve hugepages kullanımıyla birlikte bu aralık önerilmektedir. | Red Hat Virtualization Planning Guide |
| Nokia NSP (VM ortamı) | vCPU başına 2–4 GB RAM | Sanallaştırılmış NSP bileşenleri için kaynaklar ayrılmalı, oversubscription önerilmez. | Nokia NSP Planning Guide |
| Citrix XenServer | 1 vCPU : 2–4 GB RAM | Hafif iş yükleri için 1:2, yoğun uygulamalar için 1:4 önerilir. | Citrix Virtual Apps and Desktops Best Practices |
Bu oranlar, sistemin iş yüküne, hypervisor mimarisine ve donanım altyapısına göre değişiklik gösterebilir. Özellikle SDS, VDI veya HPC gibi özel senaryolarda üretici belgeleri dikkatle incelenmeli ve kaynak planlaması bu doğrultuda yapılmalıdır.
NOT : Bu değerler üreticilerde versiyondan versiyona gelişen teknoloji ile değişiklik göstermektedir. Lütfen bu değerleri ana baz değerleriniz olarak kabul etmeyin her versiyon için ayrıca inceleyiniz. Tablodaki veriler olabildiğince üreticilerden toplamam karşın versiyonlarda farklılıklar bulunmaktadır.
Sanallaştırma altyapılarında karşılaşılan birçok performans ve erişilebilirlik sorununun temelinde, ağ (network) mimarisinin yanlış tasarlanmış olması yer almaktadır. Bu tür sistemlerde yazılımsal çözümler her ne kadar gelişmiş olsa da, fiziksel altyapının doğru planlanmaması performans düşüklüğü, beklenmeyen kesintiler ve hizmet kalitesi bozulmalarına neden olabilmektedir.
1. Yönetim Ağı (Management Network)
Sanallaştırma platformlarının kontrol ara yüzüdür. Genellikle hiper yönetici (hypervisor) platformunun web veya komut satırı erişim noktasıdır. Bu ağ üzerinden yalnızca sistem yöneticileri erişim sağlar gibi düşünülse de, birçok yedekleme çözümünün bu ağı aynı zamanda veri aktarımı için kullandığı gözden kaçmaktadır. Eğer ayrı bir yedekleme ağı tanımlanmamışsa, yedekleme sırasında oluşan trafik, yönetim trafiğini etkiler ve bu durum hem yedekleme hızını düşürür hem de sistem erişimini geciktirebilir. Yada yetersiz uplink hızları yedekleme senaryolarını başarısız kılabilir.
2. Sanal Makine Ağı (Front-End Guest Network)
Bu ağ, sanal makinelerin (guest operating systems) dış dünya ile haberleştiği temel taşıyıcıdır. Genellikle yüksek bant genişliği (10GbE, 25GbE) üzerinden yapılandırılır. Uygulamalarda yapılan hata ise, bu portların yedeğinin de benzer bant genişliğinde planlanmasıdır. Hata ihtimali düşük olan bu portlar için aynı bantta yedekleme yapmak, kaynak israfıdır. Daha ekonomik ve işlevsel çözüm, örneğin bir 10GbE bağlantıyı 1GbE bağlantı ile yedeklemektir. Arıza durumunda ilgili host üzerindeki yüksek trafiğe sahip sanal makineler, canlı göç (live migration) ile başka hostlara taşınabilir.
3. Cluster Ağı (Cluster Interconnect / Backend Network)
Kümeleme yapılarında, düğümler (nodes) arasında iletişim kurmak için kullanılır. Bu ağ, yalnızca durum bilgisi paylaşımı (heartbeat), veri çoğaltma (replication), sanal makine taşıma (migration) gibi işlevsel görevler için yapılandırılır. Bu ağda yaşanacak yoğunluk, doğrudan servis kalitesini etkiler. Bu nedenle, mümkünse bu trafik diğer ağlardan (management ve front-end) kesinlikle ayrılmalıdır.
4. Depolama Ağı (Storage Network)
Depolama sistemine erişimin IP tabanlı protokollerle sağlandığı yapılarda (örneğin iSCSI, NFS), bu ağ kritik öneme sahiptir. Özellikle yazılım tanımlı depolama (SDS) veya IP SAN mimarilerinde yüksek bant genişliğine ve düşük gecikmeye ihtiyaç vardır. Bu ağ, hem cluster trafiğinden hem de sanal makine trafiğinden ayrı olmalıdır. Aksi takdirde random/sequential I/O akışları, kullanıcı trafiğini negatif etkileyebilir.
Örnek Fiziksel Ağ Tasarımı: 2 Node’lu Küme
Aşağıda belirtilen yapı, iki node’lu bir sanallaştırma kümesinde minimum gereksinimleri karşılayacak şekilde planlanmıştır:
| Ağ Tipi | Ana Bağlantı | Yedekleme / Failover |
| Management Network | 1 × 10GbE | 1 × 1GbE |
| Front-End Guest Network | 1 × 10GbE | 1 × 1GbE |
| Cluster (Backend) Network | 2 × 10GbE (Active/Passive) | Yok (Ayrı yol tanımı önerilir) |
| Storage Network | 2 × 10GbE (Active/Passive) | Yok (Yedeklilik yapılabilir) |
Bu mimari sayesinde;
- Yedekleme ve yönetim trafiği birbirini etkilemez
- Sanal makineler ile kullanıcılar arasındaki ağ, cluster hareketlerinden izole edilir
- SDS / IP SAN trafiği diğer ağlara yük bindirmez
- Arızalar esnasında düşük hızlı bağlantılarla geçici çalışma sağlanabilir
Sanallaştırma sistemlerinde en sık karşılaşılan altyapı sorunlarından biri, depolama birimlerinin görevlerinin yanlış tanımlanmasından kaynaklanmaktadır. Özellikle Storage Area Network (SAN) cihazları, sahip oldukları donanım özellikleri nedeniyle çoğu zaman yanlış kullanım senaryolarına maruz bırakılmakta; bu da performans darboğazlarına ve yatırımın erken aşamada değer kaybetmesine yol açmaktadır.
Geleneksel olarak Fibre Channel (FC) protokolü ile bağlanan SAN sistemleri, rastgele erişim (random I/O) senaryoları için optimize edilmiştir. Ancak bu yapılar, ardışık veri yazma ve okuma işlemlerinde (sequential I/O) yeterli verim sağlayamazlar. Yüksek maliyetli FC-SAN sistemlerinin dosya sunucuları (file server) veya yedekleme platformları gibi ardışık veri işleme yoğun servislerde kullanılması, megabayt başına performans oranını ciddi anlamda düşürmekte ve sistemlerin planlanandan çok daha kısa sürede yenilenmesine neden olmaktadır.
Yaygın kanının aksine, IP SAN ile FC SAN arasında veri aktarım kapasitesi açısından belirleyici fark, aktarımın bant genişliğinde değil, veri erişim süresinde (latency) ortaya çıkar. Bu nedenle milisaniye seviyesinde hassasiyet gerektirmeyen veri akışlarında (örneğin yedekleme süreçleri, dosya paylaşımı, medya düzenleme gibi senaryolar) IP SAN veya Network Attached Storage (NAS) cihazlarının tercih edilmesi hem performans hem de maliyet açısından daha uygun çözümler sunmaktadır.
Nitekim IP tabanlı NAS sistemleri, ardışık veri işlemlerinde özelleştirilmiş ön bellekleme ve veri sıralama teknikleriyle FC-SAN çözümlerine kıyasla daha yüksek aktarım performansları sergileyebilmektedir. Örneğin video düzenleme (video editing) ya da mühendislik çizim yazılımları (CAD) gibi büyük dosyaların geçici bellekte işlenmesine dayalı uygulamalarda, IP SAN/NAS çözümleri daha verimli sonuçlar doğurabilmektedir.
Ayrıca raporlama gibi zamanlanmış veri çıktıları üreten sistemler (örneğin otomatik gün sonu raporları) için kullanılan veri tabanı bölümleri de IP tabanlı sistemlere taşınabilir. Bu yaklaşım, yüksek fiyatlı FC-SAN cihazlarının yalnızca milisaniye duyarlılığı gerektiren işlemler için ayrılmasını sağlayarak hem donanım ömrünü uzatır hem de toplam sahip olma maliyetini azaltır.
Bu bağlamda depolama mimarilerinin kullanım senaryolarına uygun olarak ayrıştırılması, sadece performans kazancı değil, aynı zamanda sistem sürdürülebilirliği açısından da kritik önem taşır. Etkin sistem mühendisliği, donanım alım gücünü değil, eldeki kaynaklarla en verimli, uzun ömürlü ve işletme maliyeti düşük çözümün üretilmesini esas almalıdır. Sistem mühendisinin temel görevi, sistemi en uygun maliyetli ve sürdürülebilir şekilde yapılandırmaktır.
