Kaynak Zamanlama, NUMA ve Overcommit

Ön koşul: socket, core, hardware thread, NUMA, hypervisor, VM ve workload baseline kavramlarını açıklayabilmelisin. Bu dersin sonunda tahsis edilen vCPU ile tüketilen CPU zamanını ayıracak; scheduler beklemesini guest ve host sinyalleriyle okuyacak; vNUMA/pNUMA yerleşimini kuracak; reservation, limit ve paylaşım politikalarını gerçek garanti sınırıyla ifade edecek; memory overcommit ve noisy neighbor riskini normal, tepe, bakım ve host kaybı koşullarında sınayabileceksin. Yaklaşık 31 dakika anlatı, 16 dakika Arven uygulaması ve 10 dakika kontrollerdir. Ürüne özgü metrik adları, varsayılanlar ve oranlar güncel platform belgesiyle doğrulanmalıdır.

Bir vCPU, guest işletim sistemine sunulan çalıştırma bağlamıdır; fiziksel core için tapu değildir. Guest içindeki runnable thread önce guest scheduler tarafından bir vCPU’ya, ardından hypervisor veya host scheduler tarafından fiziksel CPU zamanına yerleştirilir. Bu iki katman yüzünden guest yüzde 100 CPU görürken alttaki hostta kaynak paylaşımı, preemption veya başka VM’lerle rekabet olabilir. Tahsis edilen vCPU sayısı, gerçekten kullanılan CPU zamanı ve talep karşılanmadığında oluşan bekleme ayrı ölçülür. CPU overcommit, toplam atanmış vCPU sayısının fiziksel yürütme kapasitesini aşmasına izin verir. Bu tek başına hata değildir; farklı workload’ların tepeleri çakışmıyorsa kullanım verimliliği sağlar. Risk, eşzamanlı runnable talebi yükseldiğinde belirginleşir. CPU kullanım yüzdesi düşük görünse bile bir vCPU runnable halde fiziksel sıra bekliyor olabilir. Platformdaki ready veya run-delay benzeri ölçüler, Linux guest’te steal time ve host PSI gibi sinyaller uygulama p95/p99, throughput ve batch süresiyle aynı zaman çizgisinde okunur. Steal time, sanal CPU’nun çalışabilir olduğu halde hypervisor tarafından fiziksel CPU üzerinde koşturulmadığı zamanı görünür kılabilir. Linux KVM arayüzü bu süreyi vCPU başına raporlayabilir; ancak bütün platformlar aynı semantik veya isimle ölçmez. Tek yüksek örnekle hüküm verilmez. Ölçüm aralığı, ortalama/tepe, hosttaki run queue, VM demand ve kullanıcı etkisi birlikte kaydedilir. Daha çok vCPU vermek her zaman daha hızlı sonuç üretmez. Büyük SMP guest’in vCPU’larını birlikte ilerletmek zorlaşabilir, cache çalışma kümesi büyüyebilir ve VM fiziksel NUMA sınırını aşabilir. Uygulamanın paralellik seviyesi yetersizse ek vCPU kullanılmaz; buna rağmen scheduling ve lisans maliyeti yaratabilir. Sağ boyutlandırma, talebi boğmak değil, iş sonucunu sağlayan en küçük desteklenen kaynağı kontrollü testle bulmaktır.

Fiziksel NUMA sisteminde CPU ve bellek kaynakları locality domain’lerine ayrılır. Bir core kendi node’undaki belleğe genellikle daha doğrudan erişir; başka node belleği interconnect üzerinden ek latency ve bandwidth rekabeti yaratabilir. Hypervisor guest’e virtual NUMA topolojisi sunabilir. Uygulama thread’leri ile guest sayfalarının vNUMA içinde, vCPU ve host belleğinin de pNUMA üzerinde nasıl yerleştiği tek zincirdir. VM’in vCPU veya bellek boyutu tek fiziksel NUMA node kapasitesini aştığında birden fazla node’a yayılması gerekebilir. Bu otomatik olarak yanlış tasarım değildir; büyük workload buna ihtiyaç duyabilir. Fakat guest’in gördüğü topology, host placement ve uygulamanın thread/memory davranışı uyuşmazsa remote erişim ile değişken latency artabilir. VM’i küçültme, uygulamayı ölçek dışı bölme, placement değiştirme ya da büyük node tasarlama seçenekleri aynı hizmet metriğiyle sınanır. Affinity ve pinning birer araçtır, performans garantisi değildir. Sabitleme cache ve yerellik kararlılığı sağlayabilir; aynı zamanda scheduler’ın dengeleme alanını daraltır, bakım/migration esnekliğini azaltır ve bir node’da kapasite baskısı doğurabilir. CPU pinning tek başına yetmez; guest memory, emulator/I/O thread, NIC/HBA yakınlığı, huge page ve device passthrough gereksinimi aynı topolojiye eklenir. libvirt gibi yönetim katmanları vCPU pinning, CPU shares/quota, memory backing ve NUMA policy’yi ayrı ayarlar olarak sunar; her ayarın platform desteği ve lifecycle etkisi doğrulanır. NUMA ölçümünde toplam sayıya güvenme. Guest vNUMA görünümü, host socket/node haritası, vCPU-pCPU ve memory-node dağılımı, local/remote erişim oranındaki değişim, migration geçmişi ve uygulama metriği gerekir. Kontrollü testte yalnız bir değişken değiştirilir. Sonuç düzelmezse locality hipotezi reddedilir; storage queue, lock, garbage collection veya network yolu incelemede kalır.

Guest’e tanımlanan bellek, hostta her an aynı miktarda fiziksel RAM’in yalnız o VM’e ayrıldığı anlamına gelmez. Platform; current memory, reservation veya minimum garanti, limit, share/priority, ballooning, page sharing, reclaim ve host swap gibi farklı mekanizmalar kullanabilir. Terimler ürünler arasında aynı davranmayabilir. Bu yüzden her politika “hangi koşulda neyi garanti eder, nerede uygulanır ve tükenmede ne olur?” sorusuyla yazılır. Reservation fiziksel kapasitenin belirli bölümünü bir workload için güvence altına alabilir; fakat cluster admission, HA ve bakım kapasitesini tüketir. Limit, VM talebi olsa bile erişebileceği üst sınırı kısabilir ve görünmez latency yaratabilir. Share veya priority çoğu zaman yalnız çekişme anında göreli önceliktir; boş kapasitede sabit oran anlamına gelmeyebilir. Kritik ve kritik olmayan sınıflar için bu semantik kabul testine çevrilmeden politika adı yeterli değildir. Memory overcommit toplam guest tahsisinin fiziksel RAM’i aşmasıdır. Çalışabilirliği sağlayan unsur bütün VM’lerin tahsislerinin tamamını aynı anda aktif kullanmaması olabilir. Fakat eşzamanlı working set büyüdüğünde platform reclaim başlatır. Ballooning guest ile koordineli biçimde sayfaları geri isteyebilir; page sharing benzer sayfaları birleştirebilir; host swap ise VM sayfasını daha yavaş katmana taşıyabilir. Mekanizmanın kullanılabilirliği, sırası ve metriği platforma göre değişir. Sık swap veya ağır reclaim p99 ve throughput’u bozabilir, OOM ise süreç ya da VM kaybına kadar gidebilir. Guest free memory tek başına yeterli değildir. Resident working set, available, page fault, reclaim/swap rate ve memory PSI; hypervisor consumed/active, balloon veya swap sinyalleri; host available/pressure ve uygulama sonucu aynı pencerede izlenir. HCI’de host belleği yalnız VM’lere ait olmayabilir: storage data path, cache, metadata ve sistem servisleri için ayrılan pay ürün mimarisinin parçasıdır. Bu pay sonraki HCI dersinde doğrulanacaktır.

Arven’in mevcut cluster’ı sekiz hosttan oluşur. Envanter 620 vCPU ve 2 TB guest memory tahsisi gösterir. Satış ekibi bu sayıları fiziksel core ve RAM’e bölerek yeni platform önermek ister. Fakat kritik pencereler, gerçek demand, VM boyutu, scheduler wait, vNUMA/pNUMA yerleşimi, working set, reservation/limit ve host kaybında kalan kapasite bilinmez. Tahsis oranı tek başına sizing veya hizmet garantisi değildir. Ekip workload’ları ERP, veri tabanı, dosya, entegrasyon ve geliştirme sınıflarına ayırır. Her sınıfta normal/tepe CPU demand, concurrency, run queue/steal, p99/throughput; active/consumed memory, reclaim/balloon/swap ve pressure; guest/host NUMA ile I/O locality; reservation, limit ve sahiplik kaydedilir. Günlük tepe, ay sonu, backup, bakım ve tek host kaybı aynı zaman ekseninde modellenir. Birinci seçenek geniş paylaşım ve ölçülü overcommit’tir; verimlidir fakat çakışan tepeler için otomasyon ve headroom ister. İkinci seçenek kritik VM’lerde reservation ve dar placement zarfıdır; tahmin edilebilirlik artabilir fakat admission, bakım ve migration alanı azalır. Üçüncü seçenek büyük VM’i yeniden boyutlandırmak veya uygulamayı bölmektir; uygulama testi ve lisans etkisi vardır. Dördüncü seçenek fiziksel kapasite eklemektir; yanlış VM boyutu veya topoloji sorununu tek başına çözmez. Koşullu karar her sınıf için sınır taşır. Örneğin ERP p99 ve batch süresi, scheduler wait ve remote memory eşiği; bellek sınıfında pressure/reclaim/swap eşiği; cluster’da bakım ve host kaybında admission ile kalan kapasite yazılır. Eşik aşılırsa placement, right-sizing veya kapasite adımı ve geri dönüş sahibi bellidir. Ürün oranı ezberlenmez; kabul edilen çalışma zarfı ölçülür.