Sanal Makine Boyutlandırma: vCPU, Bellek ve NUMA Hataları

“Sunucu güçlü ama VM yavaş” şikâyetinin arkasında çoğu zaman donanım eksikliği değil, yanlış boyutlandırma vardır. P2V sırasında fiziksel makinedeki 16 çekirdek olduğu gibi VM’e verilir, bellek “ne olur ne olmaz” diye iki katına çıkarılır ve host bir süre sonra kendi kendisiyle yarışmaya başlar. Aşağıda Hyper-V ve VMware vSphere üzerinde vCPU, bellek ve NUMA kararlarını hipervizörün kaynakları nasıl zamanladığına göre ele alıyoruz; amaç konsolidasyonu artırırken yanıt süresini bozmamak.

Fazla vCPU neden VM’i yavaşlatır

Misafir işletim sistemi vCPU’yu fiziksel bir çekirdek gibi görür. Gerçekte o, hipervizörün mantıksal işlemciler üzerinde sırayla çalıştırdığı bir iş parçacığıdır. vCPU çalışmak istediğinde hipervizör boş bir mantıksal işlemci bulmak zorundadır; host doluysa vCPU kuyrukta bekler. Bu bekleme misafirin içinden görünmez. Uygulama sahibi yalnızca yavaşlık görür.

Fazla vCPU bu beklemeyi üç yoldan büyütür:

• Zamanlama baskısı: 8 vCPU’lu bir VM, 2 vCPU’lu bir VM’e göre aynı anda daha fazla boş mantıksal işlemciye ihtiyaç duyar. vSphere’in “relaxed co-scheduling” mekanizması vCPU’ların birbirinden aşırı uzaklaşmasını sınırlar; öne geçen vCPU’lar durdurulduğunda bu esxtop’ta %CSTP (co-stop) olarak görünür.
• Misafir içi ek yük: Boşta duran vCPU’lar da zamanlayıcı kesmeleri, işlemciler arası kesmeler (IPI) ve spinlock beklemeleri üretir. Çok iş parçacıklı olmayan bir uygulama ek vCPU’dan fayda görmez, ama bu yükü taşır.
• NUMA sınırını aşma: VM bir NUMA düğümüne sığmayacak kadar büyürse belleğin bir kısmına uzak düğüm üzerinden erişilir; gecikme artar.

vCPU sayısını uygulamanın gerçekten paralel kullandığı iş parçacığı sayısı ve ölçülen tepe yük belirler. “Fiziksel sunucuda 16 çekirdek vardı” bir ölçüm değildir. Bir gerekçe bile değildir.

vCPU:pCPU oranı ve konsolidasyon

vCPU:pCPU oranı, host üzerindeki tüm VM’lere atanan vCPU toplamının fiziksel çekirdek sayısına bölümüdür. Her sunucu ve sistem altyapısında geçerli evrensel bir “güvenli” oran yoktur, çünkü belirleyici olan atanmış vCPU değil, aynı anda çalışmak isteyen vCPU’dur. Gün boyu düşük yükte duran ofis uygulamaları yüksek orana dayanır; CPU’yu sürekli kullanan derleme sunucuları, SQL Server veya RDS oturum hostları düşük oran ister.

Oranı okurken sahada en çok şu üç noktada yanılgı görüyoruz:

• Hyper-Threading: Mantıksal işlemci sayısı fiziksel çekirdeğin iki katı görünür, ama iki iş parçacığı aynı çekirdeğin yürütme birimlerini paylaşır. Kapasite hesabını fiziksel çekirdek üzerinden yapın, HT’yi yedek pay sayın.
• Hyper-V core scheduler: Windows Server 2019’dan itibaren varsayılan olan çekirdek zamanlayıcı, aynı çekirdeğin iki SMT iş parçacığını yalnızca aynı VM’in sanal işlemcilerine verir. Bu bir güvenlik kararıdır; bu yüzden VM’e SMT topolojisini yansıtmak (Set-VMProcessor -HwThreadCountPerCore) ve çift sayıda vCPU vermek kaynakları daha verimli kullandırır.
• Arıza senaryosu: Kümede bir host düştüğünde onun VM’leri diğerlerine taşınır. Oranı normal durumda değil, N-1 durumunda değerlendirin. Küme tarafını Hyper-V failover cluster planlama yazısında ayrıca anlattık.

Kâğıt üzerinde rahat görünen oran, bir düğüm kaybında bambaşka bir tabloya döner. Hesabı N-1 ile yapın.

NUMA ve sanal NUMA

Çok soketli sunucularda her işlemcinin kendine bağlı bellek kanalları vardır; işlemci ve ona doğrudan bağlı bellek birlikte bir NUMA düğümü oluşturur. Bazı yeni işlemcilerde tek soket içinde bile birden fazla NUMA düğümü tanımlanabilir (BIOS’taki sub-NUMA clustering veya “NUMA per socket” ayarları). Yerel bellek erişimi, diğer düğümün belleğine erişimden hızlıdır.

Kural basit: Mümkünse bir VM’in vCPU’ları ve belleği tek bir NUMA düğümüne sığsın. Düğüm başına 16 çekirdek ve 256 GB bellek olan bir hostta 12 vCPU / 128 GB’lık bir VM tek düğümde çalışabilir; 24 vCPU’luk bir VM ise mutlaka iki düğüme yayılır. Host yenilerken BIOS’taki NUMA ayarının değiştiğini fark etmemek de sık rastlanan bir durumdur; yeni donanıma geçişte düğüm sayısını ilk iş kontrol edin.

Hyper-V’de sanal NUMA

VM bir fiziksel düğümden büyük olduğunda Hyper-V misafire sanal NUMA topolojisi sunar; misafir işletim sistemi ve NUMA farkındalığı olan uygulamalar (SQL Server gibi) bellek yerleşimini buna göre yapar. Kritik ayrıntı: Dinamik Bellek etkin olan VM’lerde sanal NUMA kullanılamaz; misafir tek düğüm görür. Büyük veritabanı VM’lerinde statik bellek bu yüzden tercih edilir.

# Host NUMA düğümlerini ve düğüm başına belleği görüntüle
Get-VMHostNumaNode

# Hostta NUMA spanning ayarı (varsayılan: True)
Get-VMHost | Select-Object NumaSpanningEnabled

# VM'in NUMA sınırları
Get-VMProcessor -VMName SQL01 |
  Select-Object Count, MaximumCountPerNumaNode, MaximumCountPerNumaSocket

NUMA spanning kapatılırsa tek düğüme sığmayan VM başlatılamaz. Ayarı değiştirmeden önce bütün VM’lerin düğüm boyutuna uyduğunu doğrulayın; aksi halde bir sonraki yeniden başlatmada sürprizle karşılaşırsınız.

vSphere’de vNUMA

vSphere, varsayılan olarak 8’den fazla vCPU’su olan VM’lerde vNUMA topolojisini misafire sunar. VM’de CPU hot-add etkinleştirilirse vNUMA devre dışı kalır. Büyük VM’lerde hot-add’i “belki lazım olur” diye açmak, NUMA farkındalığını bedelsiz gibi görünen bir tıkla kaybetmektir. “Cores per socket” değeri misafirdeki lisanslama ve topoloji görünümünü etkiler; vNUMA ile ilişkisi vSphere sürümüne göre değiştiği için güncel davranışı Broadcom’un ilgili sürüm dokümanından doğrulayın.

Misafir içinden doğrulama için Linux’ta numactl --hardware veya lscpu, Windows’ta Sysinternals Coreinfo -n kullanılır.

Bellek: dinamik bellek, ballooning ve aşırı ayırma

İki hipervizör bellekte farklı yol izler:

Hyper-V’de Dinamik Bellek VM’i Startup değeriyle başlatır, misafirin talebine ve Buffer ayarına göre Maximum’a kadar büyütür, baskı olduğunda Minimum’a kadar geri alır. Yeniden başlatma sırasında Startup kadar boş bellek bulunamazsa Smart Paging devreye girer ve disk kullanılır. Bu yalnızca açılışı kurtarır. Sürekli çalışma için değildir.

vSphere’de bellek aşırı ayırma mümkündür; host baskı altına girdiğinde önce ballooning, ardından sıkıştırma ve en son hipervizör swap’ı devreye girer. Hipervizör swap’ı misafirin hangi sayfaların önemli olduğunu bilmeden yapıldığı için performansı sert düşürür. İzleme panosunda “swapped” veya “compressed” bellek görüyorsanız tartışma bitmiştir: Host bellek kapasitesi yetersizdir.

Uygulama tarafındaki kısıtlar boyutlandırmayı doğrudan etkiler. Exchange Server dinamik bellekle desteklenmez. SQL Server dinamik bellekle çalışabilir; ancak max server memory ayarı yapılmamış bir SQL örneği kendisine verilen belleği tutma eğiliminde olduğundan ballooning etkisiz kalır. Büyük SQL ve uygulama sunucularında statik bellek ile gerçekçi bir max server memory değeri daha öngörülebilir sonuç verir.

# Hyper-V: dosya sunucusu için dinamik bellek örneği
Set-VMMemory -VMName FS01 -DynamicMemoryEnabled $true `
  -StartupBytes 4GB -MinimumBytes 2GB -MaximumBytes 8GB -Buffer 20

# SQL sunucusu için statik bellek (VM kapalıyken)
Set-VMMemory -VMName SQL01 -DynamicMemoryEnabled $false -StartupBytes 64GB

Hangi sayaca bakılır

Hyper-V hostunda Görev Yöneticisi’nin gösterdiği CPU kullanımı yalnızca kök bölümün, yani host işletim sisteminin görünümüdür. Host’un gerçek işlemci yükünü göstermez. “Host yüzde 20’de, sorun VM’de” teşhisi çoğu zaman buradan çıkar ve yanlıştır. Doğru kaynak hipervizör sayaçlarıdır:

vCenter performans grafiklerinde CPU Ready milisaniye toplamı olarak gösterilir. Yüzdeye çevirmek için örnek hesap: Gerçek zamanlı grafikte örnekleme aralığı 20 saniyedir; 1.000 ms ready değeri 1.000 / 20.000 = 0,05, yani o aralığın yüzde 5’i demektir. Bu değer VM’in tüm vCPU’larının toplamıdır; vCPU sayısına bölerek değerlendirin. Tek bir anlık değere değil, iş saatlerindeki eğilime bakın.

# Hyper-V hostunda 5 sn aralıkla 12 örnek topla
Get-Counter -Counter `
 '\Hyper-V Hypervisor Logical Processor(_Total)\% Total Run Time',
 '\Hyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per Dispatch' `
 -SampleInterval 5 -MaxSamples 12

Host düzeyindeki eşik ve alarm kuralları için sunucu izleme metrikleri yazısına bakabilirsiniz.

İş yükü tipine göre başlangıç değerleri

Aşağıdaki değerler, ölçüm yokken ilk dağıtım için makul varsayımlardır; standart değildir. Her VM ilk iki–dört haftalık ölçümden sonra yeniden değerlendirilir.

SQL Server gibi çekirdek bazlı lisanslanan ürünlerde vCPU sayısı doğrudan lisans maliyetini belirler. Fazla vCPU burada hem performans hem bütçe hatasıdır. Lisans tarafını sanallaştırmada Windows Server lisanslama yazısında ayrıca inceledik.

Yeniden boyutlandırma: kontrol sırası

1. Envanter çıkarın: Her VM için atanmış vCPU, bellek, dinamik bellek durumu ve host NUMA yerleşimi listelenir.
2. En az iki hafta ölçün: Ay sonu, yedekleme penceresi gibi tepe dönemleri kapsayan veriyle misafir içi CPU kullanımı, işlemci kuyruk uzunluğu ve hipervizör bekleme sayaçları toplanır.
3. Adayları ayırın: Tepe CPU kullanımı sürekli düşük kalan çok vCPU’lu VM’ler küçültme adayıdır; bekleme süresi de misafir içi kullanımı da yüksek olanlar büyütme adayıdır. Misafirde kullanım düşük ama bekleme yüksekse sorun VM’de değil, hosttadır.
4. Kademeli değiştirin: vCPU’yu tek seferde yarıya indirmek yerine bir adım küçültün. Hyper-V’de vCPU değişikliği VM kapalıyken yapılır; bakım penceresini buna göre planlayın.
5. Doğrulayın: Değişiklik öncesi ve sonrası aynı sayaçlar ve uygulama yanıt süreleri karşılaştırılır, sonuç değişiklik kaydına eklenir.

# Atanmış kaynakların hızlı envanteri
Get-VM | Select-Object Name, ProcessorCount,
  @{n='StartupGB';e={$_.MemoryStartup/1GB}},
  @{n='AssignedGB';e={[math]::Round($_.MemoryAssigned/1GB,1)}},
  DynamicMemoryEnabled | Sort-Object ProcessorCount -Descending

# vCPU azaltma (VM kapalıyken)
Stop-VM -Name APP02
Set-VMProcessor -VMName APP02 -Count 4
Start-VM -Name APP02

Sahada en sık gördüğümüz hatalar

• Fiziksel sunucudaki çekirdek ve bellek değerlerini P2V sonrası olduğu gibi VM’e taşımak.
• Host CPU kullanımını kök bölümün Görev Yöneticisi’nden okumak.
• Büyük SQL VM’inde dinamik bellek açıp sanal NUMA’yı farkında olmadan kapatmak.
• Kapasiteyi normal duruma göre planlayıp küme düğümü kaybını hesaba katmamak.
• Tek vCPU’lu VM vermek: Güncelleme veya antivirüs taraması sırasında bütün sistem tek çekirdekte sıkışır; çoğu sunucu iş yükü için en az 2 vCPU daha sağlıklıdır.

Mevcut hostların kapasite ve performans analizi için altyapı danışmanlığı ve sistem optimizasyonu sayfamıza, platform tasarımı için sanallaştırma ve veri yönetimi hizmetimize bakabilirsiniz. Microsoft’un resmi önerileri Hyper-V performans ayarlama kılavuzunda yer alır.

Sık sorulan sorular

VM’e verilen vCPU sayısı fiziksel çekirdek sayısını geçebilir mi?

Tek bir VM’e host’taki mantıksal işlemci sayısından fazla vCPU verilemez. Hyper-Threading sayesinde fiziksel çekirdek sayısını aşan bir değer verilebilir ama önerilmez; VM’in tüm vCPU’ları aynı anda çalışmak istediğinde kendi vCPU’larıyla yarışır. Host genelinde toplam vCPU’nun fiziksel çekirdekleri aşması ise normaldir; konsolidasyon zaten budur.

CPU Ready değeri yüksekse VM’e vCPU eklemek çözüm mü?

Genellikle hayır. CPU Ready, vCPU’nun çalışmaya hazır olduğu halde fiziksel işlemci bulamadığını gösterir. vCPU eklemek bekleme ihtiyacını artırır. Doğru adım fazla vCPU’lu VM’leri küçültmek, yükü başka hosta dağıtmak veya host kapasitesini artırmaktır.

Dinamik Bellek hangi sunucular için uygun değildir?

Exchange Server dinamik bellekle desteklenmez. Büyük SQL Server VM’lerinde dinamik bellek sanal NUMA’yı devre dışı bıraktığı ve SQL belleği tutma eğiliminde olduğu için statik bellek tercih edilir. Dosya sunucusu, web sunucusu ve yönetim sunucuları gibi değişken yükler dinamik bellek için iyi adaylardır.

VM’in NUMA düğümüne sığıp sığmadığını nasıl anlarım?

Hyper-V’de Get-VMHostNumaNode ile düğüm başına çekirdek ve belleği, Get-VMProcessor ile VM’in sınırlarını görürsünüz. VM’in vCPU sayısı düğümdeki fiziksel çekirdekten, belleği de düğüm belleğinden küçükse tek düğüme sığar. Misafir içinden Coreinfo -n veya numactl –hardware ile görülen düğüm sayısı ikinci doğrulamadır.