[TR] VMware Ortamlarında vCPU ve Cores per Socket Yapılandırmasının Önemi

Sanal makine performansı planlanırken çoğu zaman ilk bakılan değer vCPU sayısı olur. Bir uygulama yavaş çalışıyorsa veya daha fazla işlem gücüne ihtiyaç duyuyorsa, genellikle “VM’e biraz daha CPU verelim” yaklaşımı tercih edilir. Ancak VMware ortamlarında performansı belirleyen tek konu sanal makineye kaç adet vCPU verildiği değildir. En az bunun kadar önemli olan bir diğer konu da bu vCPU’ların sanal makineye kaç socket ve kaç core per socket yapısıyla sunulduğudur.

Özellikle çok işlemcili, çok çekirdekli fiziksel sunucularda bu tasarım daha kritik hale gelir. Çünkü modern sunucular yalnızca CPU çekirdeklerinden oluşmaz; aynı zamanda NUMA mimarisi adı verilen bellek ve işlemci yerleşimine sahiptir. VMware tarafında sanal makine CPU tasarımı yapılırken bu fiziksel NUMA yapısı dikkate alınmazsa, sanal makineye yeterli kaynak verilmiş gibi görünse bile uygulama tarafında gecikme, CPU bekleme süreleri, bellek erişim problemleri ve performans dalgalanmaları görülebilir.

NUMA Nedir?

NUMA, Non-Uniform Memory Access ifadesinin kısaltmasıdır. Türkçeye “Tek Tip Olmayan Bellek Erişimi” olarak çevrilebilir. NUMA mimarisinde fiziksel sunucuda bulunan her işlemci soketinin kendisine daha yakın olan bir bellek alanı vardır.

Örneğin görseldeki fiziksel sunucu yapısını ele alalım:

Fiziksel Sunucu Yapısı:

2 adet fiziksel işlemci soketi
Her sokette 10 fiziksel core
Toplam 20 fiziksel core
Hyper-Threading ile toplam 40 logical processor
Toplam 256 GB RAM
Her fiziksel socket başına 128 GB RAM

Bu mimaride her fiziksel CPU soketi kendi NUMA node’u gibi düşünülebilir. Yani birinci işlemcinin kendisine yakın olan 128 GB belleği, ikinci işlemcinin de kendisine yakın olan ayrı bir 128 GB belleği vardır.

Bir işlemci kendi lokal belleğine eriştiğinde gecikme daha düşüktür. Ancak başka bir işlemci soketine bağlı belleğe erişmek zorunda kalırsa bu erişim daha maliyetli olur. İşte NUMA farkı burada ortaya çıkar.

VMware’de vNUMA Kavramı

VMware ortamlarında fiziksel NUMA mimarisinin sanal makinelere yansıtılmış haline vNUMA, yani Virtual NUMA denir.

vNUMA sayesinde büyük sanal makineler, fiziksel sunucunun NUMA yapısına daha uygun şekilde çalışabilir. VMware ESXi, sanal makineye verilen vCPU ve bellek miktarına göre VM’in hangi NUMA node üzerinde daha verimli çalışacağını hesaplar.

Örneğin bir fiziksel host üzerinde her NUMA node 10 fiziksel core ve 128 GB RAM içeriyorsa, 8 vCPU ve 64 GB RAM verilen bir sanal makine tek NUMA node içinde rahatlıkla çalışabilir. Bu durumda VM’in CPU ve bellek erişimi daha lokal kalır. Ancak 16 vCPU ve 160 GB RAM verilen bir VM, tek NUMA node sınırını aşacağı için birden fazla NUMA node’a yayılmak zorunda kalabilir.

Broadcom/VMware dokümantasyonunda da vNUMA topolojisinin fiziksel NUMA mimarisiyle uyumlu olmasının özellikle büyük VM’lerde performans açısından önemli olduğu belirtilmektedir.

vCPU Sayısı Tek Başına Yeterli Bir Ölçü Değildir

Bir sanal makineye 8 vCPU vermek ile 16 vCPU vermek arasında yalnızca “iki kat CPU verdim” gibi basit bir ilişki yoktur. Çünkü vCPU sayısı arttıkça sanal makinenin fiziksel CPU kaynakları üzerinde planlanması da karmaşık hale gelir.

Küçük VM’lerde bu durum genellikle büyük bir sorun oluşturmaz. Ancak SQL Server, Exchange Server, ERP sistemleri, yoğun çalışan uygulama sunucuları, büyük veritabanları veya yüksek işlem gücü gerektiren sistemlerde CPU topolojisi ciddi fark yaratabilir.

Yanlış yapılandırılmış bir VM’de şu problemler görülebilir:

CPU Ready değerlerinde artış
Uygulama tarafında anlık yavaşlamalar
Bellek erişim gecikmelerinde artış
İş yükünün fiziksel NUMA node’lar arasında dengesiz dağılması
SQL Server gibi NUMA farkındalığı olan uygulamalarda performans kaybı
Daha fazla kaynak verilmesine rağmen beklenen performans artışının alınamaması

Bu nedenle doğru yaklaşım yalnızca “VM’e kaç vCPU verelim?” sorusunu sormak değildir. Asıl sorulması gereken soru şudur:

Bu vCPU’lar fiziksel NUMA mimarisine uygun şekilde sanal makineye nasıl sunulmalı?

Görseldeki Yapının Teknik Yorumu

Paylaşılan görselde fiziksel host şu yapıdadır:

Intel işlemci
2 fiziksel socket
Socket başına 10 core
Toplam 40 logical processor
256 GB toplam RAM
Socket başına 128 GB RAM

Bu durumda her fiziksel NUMA node yaklaşık olarak:

10 fiziksel core
128 GB RAM

kapasitesine sahiptir.

Bu host üzerinde bir sanal makine oluştururken, VM’in mümkün olduğunca tek fiziksel NUMA node içinde kalması performans açısından avantajlıdır. Örneğin:

1 vCPU / 1 core per socket
2 vCPU / 2 core per socket
4 vCPU / 4 core per socket
8 vCPU / 8 core per socket
10 vCPU / 10 core per socket

gibi yapılandırmalar, 10 core sınırını aşmadığı sürece tek NUMA node içinde kalabilir.

Ancak 10 fiziksel core sınırı aşıldığında VM artık tek NUMA node içine sığmayabilir. Bu durumda VM’in iki NUMA node’a dengeli şekilde bölünmesi gerekir.

Örneğin:

12 vCPU için 2 socket x 6 core
14 vCPU için 2 socket x 7 core
16 vCPU için 2 socket x 8 core
18 vCPU için 2 socket x 9 core
20 vCPU için 2 socket x 10 core

şeklinde yapılandırma daha dengeli kabul edilir.

Buna karşılık 11, 13, 15, 17 veya 19 gibi tek sayıdaki vCPU değerleri iki NUMA node’a eşit bölünemediği için görselde Sub-optimal olarak işaretlenmiştir. Bunun sebebi, CPU dağılımının fiziksel NUMA sınırlarıyla tam uyumlu olmamasıdır.

Cores per Socket Ayarı Ne İşe Yarar?

VMware’de Cores per Socket ayarı, sanal makinenin işletim sistemine CPU’ları nasıl göstereceğini belirler.

Örneğin 8 vCPU verilen bir VM şu şekillerde sunulabilir:

8 socket x 1 core
4 socket x 2 core
2 socket x 4 core
1 socket x 8 core

Toplam vCPU sayısı her durumda 8’dir. Ancak guest OS, yani sanal makine içindeki işletim sistemi bu CPU yapısını farklı görebilir.

Bu durum özellikle şu konularda önemlidir:

İşletim sisteminin CPU topolojisini algılama şekli
Uygulamanın NUMA farkındalığı
Yazılım lisanslama modeli
SQL Server gibi socket/core bazlı davranabilen uygulamalar
Performans analizi ve troubleshooting süreçleri

Burada önemli bir güncel not vardır: VMware/Broadcom kaynaklarına göre vSphere 6.5 ve sonrasında Cores per Socket değeri doğrudan vNUMA topolojisini belirleyen ana mekanizma değildir; daha çok guest OS’in gördüğü CPU topolojisini etkiler. Ancak bu topoloji, işletim sistemi ve uygulama davranışı üzerinden performansa dolaylı olarak etki edebilir.

Eski Yaklaşım ve Yeni Yaklaşım Arasındaki Fark

Eski VMware sürümlerinde Cores per Socket ayarı vNUMA topolojisi üzerinde daha belirleyici kabul edilirdi. Bu nedenle sanal makine tasarımında socket/core dağılımı doğrudan NUMA planlaması için kullanılırdı.

Yeni vSphere sürümlerinde ise ESXi tarafındaki otomatik CPU topolojisi ve vNUMA yerleşim mekanizmaları daha gelişmiştir. Özellikle vSphere 8 ve yeni sanal donanım sürümlerinde Assigned at Power On gibi otomatik topoloji seçenekleri, VMware’in sanal makineyi fiziksel host mimarisine göre daha uygun şekilde konumlandırmasına yardımcı olur. Broadcom dokümanlarında, yeni donanım sürümlerinde Cores per Socket değerinin otomatik atanmasının varsayılan davranış olduğu ve vNUMA topolojisinin bu otomasyonla daha esnek yönetildiği belirtilmektedir.

Bu nedenle güncel ortamlarda en sağlıklı yaklaşım, manuel olarak her VM’e rastgele socket/core değeri vermek yerine:

ESXi sürümünü,
VM hardware version bilgisini,
CPU Hot Add durumunu,
uygulama gereksinimini,
lisanslama modelini,
fiziksel NUMA yapısını

birlikte değerlendirmektir.

CPU Hot Add Kullanımına Dikkat Edilmeli

VMware ortamlarında bazı yöneticiler sanal makine çalışırken CPU ekleyebilmek için CPU Hot Add özelliğini aktif eder. Bu özellik operasyonel olarak kolaylık sağlayabilir; ancak performans açısından her zaman doğru tercih olmayabilir.

Özellikle eski vSphere sürümlerinde CPU Hot Add aktif edildiğinde vNUMA davranışı olumsuz etkilenebiliyor veya vNUMA sanal makineye doğru şekilde sunulamayabiliyordu. Broadcom kaynaklarında, yeni vSphere 8 otomatik vTopology mekanizmasının CPU Hot Add aktifken de vNUMA’yı koruyabildiği, ancak bunun önceki sürümlerde farklı davrandığı belirtilmektedir.

Bu nedenle büyük ve performans kritik VM’lerde CPU Hot Add özelliği varsayılan olarak açılmamalıdır. Gerçekten ihtiyaç varsa, ilgili vSphere sürümünün bu özelliği NUMA açısından nasıl yönettiği kontrol edilmelidir.

Bellek Miktarı da NUMA Tasarımında Kritik Rol Oynar

vCPU planlaması yapılırken yalnızca CPU çekirdeği sayısına bakmak eksik bir değerlendirme olur. Bellek miktarı da NUMA tasarımını doğrudan etkiler.

Görseldeki örnekte her fiziksel socket başına 128 GB RAM düşmektedir. Bu durumda 8 vCPU ve 96 GB RAM verilen bir VM tek NUMA node içinde kalabilir. Ancak aynı VM’e 160 GB RAM verilirse, CPU sayısı tek NUMA node içine sığsa bile bellek miktarı tek NUMA node sınırını aşacağı için VM’in bellek erişimi farklı NUMA node’lara yayılabilir.

Bu durum özellikle bellek yoğun çalışan uygulamalarda önemlidir. SQL Server, Exchange Server, büyük JVM tabanlı uygulamalar, analitik sistemler ve bellek içi işlem yapan servislerde NUMA dışı bellek erişimi performans üzerinde ciddi etki oluşturabilir.

SQL Server ve Exchange Gibi Sistemlerde Neden Daha Önemlidir?

SQL Server gibi kurumsal uygulamalar NUMA farkındalığına sahiptir. Yani işletim sisteminin sunduğu NUMA topolojisini algılayabilir ve iş parçacıklarını buna göre planlayabilir.

Eğer sanal makinenin vNUMA yapısı fiziksel NUMA mimarisiyle uyumluysa, SQL Server CPU ve bellek kaynaklarını daha verimli kullanabilir. Ancak yanlış socket/core dağılımı veya uygunsuz vNUMA sunumu, SQL Server’ın kaynakları verimsiz kullanmasına neden olabilir.

Broadcom’un SQL Server performansına yönelik VMware kaynaklarında, VM’in vNUMA topolojisinin fiziksel host NUMA topolojisiyle uyumlu olmasının ve bellek erişiminin lokal kalmasının performans açısından önemli olduğu vurgulanmaktadır.

Exchange Server, büyük uygulama sunucuları, RDS ortamları ve yüksek trafikli servisler için de benzer prensip geçerlidir. Bu tür sistemlerde kaynak vermek kadar, kaynağı doğru topolojiyle sunmak da önemlidir.

Hyper-Threading Yanıltıcı Olabilir

Görselde host üzerinde 40 logical processor olduğu belirtiliyor. Ancak bu değer Hyper-Threading ile oluşan mantıksal işlemci sayısını ifade eder.

Performans planlaması yapılırken yalnızca logical processor sayısına güvenmek doğru değildir. Çünkü Hyper-Threading, fiziksel core sayısını ikiye katlamaz. Aynı fiziksel core üzerinde iki thread çalıştırılmasına olanak sağlar.

Bu nedenle NUMA ve vCPU planlamasında öncelikli referans genellikle fiziksel core sayısı olmalıdır. Örnekte her socket üzerinde 10 fiziksel core bulunduğu için tek NUMA node sınırı 10 core olarak değerlendirilmelidir. 20 logical processor var diye tek NUMA node’a 20 vCPU sığacakmış gibi düşünmek hatalı bir yaklaşım olur.

Yanlış Yapılandırma Örneği

Diyelim ki fiziksel host üzerinde socket başına 10 core ve 128 GB RAM var.

Bir VM’e şu kaynaklar verildi:

15 vCPU
96 GB RAM

Bellek miktarı tek NUMA node içine sığabilir. Ancak 15 vCPU, 10 fiziksel core sınırını aştığı için VM’in CPU tarafında birden fazla NUMA node’a yayılması gerekir. 15 sayısı iki NUMA node’a eşit bölünemediği için yapı dengesiz olabilir.

Bu nedenle 15 vCPU yerine uygulama ihtiyacına göre şu seçenekler değerlendirilebilir:

VM gerçekten 15 vCPU’ya ihtiyaç duyuyor mu?
14 vCPU yeterli olur mu?
16 vCPU daha dengeli bir yapı sağlar mı?
Uygulama thread yapısı buna uygun mu?
CPU Ready ve CPU Usage değerleri ne durumda?
Guest OS içinde NUMA node’lar doğru görünüyor mu?

Buradaki amaç her zaman daha fazla CPU vermek değildir. Amaç, verilen CPU’nun fiziksel mimariyle uyumlu şekilde çalışmasını sağlamaktır.

Doğru Yapılandırma İçin Genel Öneriler

VMware ortamlarında vCPU ve Cores per Socket planlaması yapılırken aşağıdaki prensipler dikkate alınmalıdır:

1. Fiziksel host mimarisini bilin.
Her host üzerinde kaç socket, socket başına kaç core ve NUMA node başına ne kadar RAM olduğunu bilmeden sağlıklı VM tasarımı yapılamaz.

2. VM’i mümkünse tek NUMA node içinde tutun.
Küçük ve orta ölçekli VM’lerde mümkün olduğunca fiziksel NUMA sınırları içinde kalmak performans açısından daha sağlıklıdır.

3. Büyük VM’lerde NUMA dağılımını dengeli yapın.
VM tek NUMA node’a sığmıyorsa CPU ve bellek dağılımının NUMA node’lara dengeli yayılması gerekir.

4. Tek sayıdaki yüksek vCPU değerlerine dikkat edin.
11, 13, 15, 17, 19 gibi değerler bazı fiziksel mimarilerde dengesiz dağılıma neden olabilir.

5. Cores per Socket ayarını rastgele değiştirmeyin.
Bu ayar guest OS’in CPU topolojisini etkileyebilir. Güncel vSphere sürümlerinde doğrudan vNUMA’yı belirlemese bile uygulama ve lisanslama tarafında sonuç doğurabilir.

6. CPU Hot Add özelliğini dikkatli kullanın.
Performans kritik VM’lerde CPU Hot Add’in vNUMA davranışına etkisi mutlaka kontrol edilmelidir.

7. Performansı yalnızca verilen kaynakla ölçmeyin.
CPU Usage, CPU Ready, Co-Stop, bellek latency, NUMA locality ve uygulama içi performans sayaçları birlikte değerlendirilmelidir.

Performans Optimizasyonu Daha Fazla Kaynak Vermek Değildir

Sanal altyapılarda sık yapılan hatalardan biri, performans sorunu yaşayan VM’e doğrudan daha fazla CPU veya RAM vermektir. Oysa bazı durumlarda bu yaklaşım problemi çözmek yerine daha karmaşık hale getirebilir.

Örneğin 8 vCPU ile tek NUMA node içinde verimli çalışan bir VM, 12 veya 16 vCPU’ya çıkarıldığında birden fazla NUMA node’a yayılabilir. Eğer uygulama bu yapıyı doğru kullanamıyorsa veya VM topolojisi yanlış sunuluyorsa, daha fazla CPU verilmesine rağmen performans düşebilir.

Bu nedenle performans optimizasyonu şu sorularla yapılmalıdır:

VM gerçekten daha fazla CPU’ya ihtiyaç duyuyor mu?
Mevcut CPU’lar verimli kullanılıyor mu?
CPU Ready yüksek mi?
VM tek NUMA node içinde mi çalışıyor?
Bellek lokal mi, yoksa remote NUMA erişimi var mı?
Guest OS NUMA topolojisini doğru görüyor mu?
Uygulama NUMA farkındalığına sahip mi?
vSphere sürümü ve VM hardware version bu tasarıma uygun mu?

Doğru cevap çoğu zaman “daha fazla kaynak verelim” değil, “mevcut kaynağı doğru mimariyle sunalım” olacaktır.

VMware ortamlarında sanal makine performansını etkileyen en önemli konulardan biri vCPU ve Cores per Socket yapılandırmasıdır. Toplam vCPU sayısı önemli olsa da, bu vCPU’ların sanal makineye nasıl sunulduğu, fiziksel NUMA mimarisiyle ne kadar uyumlu olduğu ve guest OS tarafından nasıl algılandığı en az vCPU sayısı kadar kritik öneme sahiptir.

Özellikle SQL Server, Exchange Server, ERP, büyük uygulama sunucuları ve yoğun işlem gücü gerektiren sistemlerde yanlış CPU topolojisi beklenmeyen performans sorunlarına neden olabilir.

Bu nedenle VM tasarımında yalnızca kaynak miktarına değil, kaynakların mimariye uygun şekilde sunulmasına odaklanılmalıdır. Çünkü sanallaştırma ortamlarında gerçek performans artışı çoğu zaman daha fazla CPU veya RAM vermekle değil, verilen kaynakları doğru NUMA ve CPU topolojisiyle kullandırmakla elde edilir.