vSphere – CPU and NUMA – 2
Yazımın ilk bölümünde NUMA nedir, nasıl çalışır, ESXi NUMA Scheduler görevi nedir gibi konuları anlattım. Şimdi Wide VM ve virtual NUMA konularını anlatacağım.
Eğer bir VM, çalıştığı NUMA node içerisinde bulunandan daha fazla vCPU ya sahip ise, bu makineye Wide VM diyoruz. Bunun anlamı, makine bir NUMA node a sığmıyor, ve diğer NUMA node tan kaynak kullanması gerekiyor.
Wide VM terimini yukarıdaki örnek üzerinden anlatalım:
- Elimizde 2 soketli – 6 core lu = toplamda 12 cpu lu bir fiziksel sunucu var ve bu sunucu da ESXi işletim sistemi kuruldu.
- Ancak sanal makinemizi 10 vCPU lu oluşturduk.
- Kural: Her sanal makine için bir NUMA Client oluşturulur ve ESXi NUMA Scheduler, bu NUMA Client ı bir NUMA home node içerisinde konumlandırır.
- Peki ne oldu? Sanal makine bir NUMA node içerisine sığmadı. ESXi, hemen bu makineye özel diğer NUMA Home node tan da kaynak kullanabilmesi için ikinci bir NUMA client açar.
- Bu sanal sunucuya Wide VM diyoruz.
- Sonuç: Bu durumda, iki NUMA client a sahip makinemiz biraz daha yavaş çalışacaktır.
- Performans sorunun nedeni, CPU ların uzaktaki memory modüllerini kullanmasından kaynaklı olacaktır. (Memory latency)
- Peki performans sorunun önüne nasıl geçebiliriz? Bunun da cevabı vNUMA.
Wide VM lerde yaşanan performans sorunun önüne geçmek için VMware tarafından virtual NUMA (vNUMA) özelliği otomatik devreye girer. vNUMA, wide VM oluşturulduğu anda sanal makine özelinde aktif edilir ve VM içerisindeki NUMA farkındalığı olan işletim sisteminin hizmetine sunulur. vNUMA, fiziksel makinedeki NUMA özelliğinin üstünde çalışır. vNUMA, Wide VM oluşturulup, sanal makineyi açtığınız anda çalışmaya başlar, sizin özel bir şey yapmanıza gerek yok.
vNUMA topoloji hangi durumda kullanılır?
- Bir sanal makine 8 den fazla CPU ya sahipse ve
- vCPU sayısı, fiziksel NUMA home node içerisindeki cpu sayısında fazla ise devreye girer.
vNUMA topoloji hangi durumlarda çalışmaz?
- Sanal makine Wide VM olsa bile eğer CPU hot add özelliğini aktif edersiniz, vNUMA yı kapatmış olursunuz.
