vSphere CPU Affinity Nedir Nasıl Çalışır

Merhaba,

vSphere 6.5 ve sonrasında CPU affinity nedir? nasıl çalışır? Nasıl konfigüre edilir? ve nelere dikkat edilmelidir konularına değineceğim.
Öncelikle CPU affinity’i anlatmaya başlamadan hyperthreading’e de değinmek isterim. Bu teknoloji ilk olarak 2002 yılında Xeon Server CPU’larda görülmüş daha sonra P4 CPU’larda bu teknolojiden faydalanmıştır . HT ile tek bir fiziksel core arkada çalışan işletim sistemine 2 sanal core gibi görünmekte ve scheduling yapan işletim sistemi eş zamanlı işlemler ile aslında tek olan fiziksel core’u daha yüksek oranda utilize edebilmekte bununla birlikte bazı sistemlerde performans kazanımı sağlamaktadır.
Meraklısı için NASA tarafından yayınlanmış performans testleri içeren şu makale incelenebilir : Tıkla git.

vSphere 6.5 ile birlikte değişen CPU affinity yapısına gelecek olursak sanırım öncelikle nedir ve nasıl çalışır sorularına cevap vermeliyim;

vSphere CPU Affinity Nedir ve Nasıl Çalışır?

CPU affinity en basit anlamıyla bir VM’in çalışabileceği core’ları kısıtlamak veya belirtmektir. Yani bir affinity ile bir VM’e sen git 0-2, 6-8’de çalış diyerek VM’in sadece belirtilen core’lara iş yükü göndermesini garanti etmiş oluruz. Ancak bu yanlış anlaşılmamalıdır, yaptığımız bu işlem ilgili vCPU’ları VM’e dedicate (ayırmak) etmez. Başka VM’lerden gelen iş yükü bizim adres gösterdiğimiz vCPU’lara dağıtılmaya devam edecektir. Peki durum böyleyse ne anlamı var diyebiliriz. Burada tamamen kontrollü bir ortam hayal edin. Tüm VM’ler belirli vCPU’larda çalışmak üzere yalıtılmış gerekli affinity kuralları yazılmış. İşte ancak böyle bir ortamda bir VM’in belirli bir core’u dedicate etme şansımız olabilir. Bunun dışında kontrolsüz bir ortam için konuşacak olursak burada da yazılan affinity ile birlikte CPU reservation ve share kullanmamız ilgili VM’e belirttiğimiz vCPU’ları utilize etme önceliği verecektir ancak şu akılda tutulmalı ki %100 reservation verilse dahi CPU scheduler ortamdaki başka bir VM’in iş yükünü bizim %100 reservation olan vCPU’ya verebilir ve önceliğimiz olduğu halde bekleyebiliriz.

Ne zaman ve Nasıl kullanılmalıdır ?

Eğer L1 , L2, L3 cache bağımlısı bir uygulama koşturuyorsak kontrollü bir ortamda affinity kuralları ile uygulamanın CPU cache’den yararlanabilmesini ve performans kazanımını sağlayabiliriz. Genel olarak CPU affinity simulasyonlar ve yük testleri için kullanılır. Bunun dışındaki durumlarda kullanılmaması ve iş yükünün vmkernel’in dağıtımına bırakılması tercih edilir.

Örnek bir CPU affinity modeli için görseli incelemekte fayda var ;

Burada bir VM için üç farklı senaryo var Bad olarak belirtilen senaryoda LCPU0 ve LCPU1 aynı core’a ait (HT açık durumda) ve VM kaynak istediğinde bu iki vCPU fiziksel işlemcide kaynak için birbiriyle yarışacaktır. Bu da standart bir bekleme yaratarak istediğimiz performansı elde etmemizi engelleyecektir.

İkinci senaryoda vCPU dağıtımı iki farklı fiziksel işlemciden verilmiş, 1.CPU’dan LCPU3 ve 2.CPU’dan LCPU0. Bu senaryoda amacımız yukarıda bahsettiğim L1,L2,L3 cachelerden olabildiğince yararlanma durumudur. Ancak bu senaryoda veri yolunda harcanan zaman ve oluşan latency cache kazanımımızı düşürerek el-ele baş-başa durumu yaratabilir.

Üçüncü senaryo ise aynı CPU üzerinde iki farklı fiziksel core’dan dağıtım yapmaktır ki bu iş yükünün, Latency sensitive bir VM’de 2 farklı fiziksel core’a yönlenmesini ve sonuç olarak vCPU’ların aynı fiziksel core için yarışmamasını garanti eder.

Burada görselde çift numaralar fiziksel core’u gösterirken tek numaralar hyperthreading’den gelen LCPU’yu temsil etmektedir.

Sonuçtan anlaşılacağı üzere en uygun ve performanslı çalışacak durum üçüncü durumdur. Mümkün olduğunca bu şekilde dağıtım yapmak performans kazanımı sağlayacaktır.

Nasıl uygulanır?

1. VM’e sağ tıklayarak edit settings’e tıklayın
2. Virtual Hardware altında CPU’yu genişletin.
   
3. Scheduling Affinity altında physical processor affinity’i seçerek vCPU numaralarını belirtin.

   Aralık belirtmek için “-” , farklı aralıkları ayırmak için “, ” kullanabilirsiniz.

   Örneğin, “0, 2, 4-7” seçimi 0, 2, 4, 5, 6 ve 7 numaralı işlemcileri gösterir.

4. OK basarak işlemi tamamlayın.
   

İlgili Görsel :

Potansiyel sorunlar :

• Multi işlemcili sistemlerde ESXi yük dengelemeyi otomatik olarak yapar. Manuel yerleşimlerden kaçınarak yük dengeleyicinin dengesini bozmaktan uzak kalınması önerilir.

• Affinity rule yazılmışsa ESXi host CPU reservation’ları karşılamakta sorun yaşayabilir.

• CPU admission control mekanizması affinity kurallarını yok saydığından, affinity kurallarına sahip bir sanal makine her zaman %100 rezervasyonları elde edemeyebilir.

  –CPU affinity kuralına sahip olmayan makineler, olanlar tarafından zararlı bir şekilde etkilenmez.

• VM migrate edildiğinde affinity kuralları geçersiz kalabilir. Bu durum özellikle iki host birebir yapılandırmaya sahip değilse oluşabilir. (vMotion yapamazsınız)

• NUMA scheduler affinity kuralları yazılmış VM’leri NUMA Client olarak saymayıp exclusion list’e koyacaktır. Ancak NUMA scheduler bellek yönetimi için bir kural koymayacağından VMkernel ilgili VM’e istediği yerden bellek atayabilir. Bu durum VM’in üzerinde bulunduğu NUMA node’dan farklı bir yerde bellek sahibi olmasına, sonuç olarak gereksiz bellek gecikmesi ve daha yüksek %ready time oluşmasına sebep olacaktır. Bu senaryoda ilgili instruction bellek uzak bir node’dan yakalanana kadar beklemek durumunda kalacaktır.

vSphere 6.5 ve sonrasındaki CPU-affinity ile ilgili yazacaklarım şimdilik bu kadar. Eğer ki CPU-affinity kullanılacaksa iyi bir neden olmalı ve istenmeyen sonuçlarla karşılaşmamak için yönetim açısından getireceği ek yükü göz önünde bulundurmalısınız. Çok iyi bir nedeniniz yoksa işi VMkernel’a bırakmak ve vSphere DRS kullanmak bununla birlikte VM hardware sekmesinde reservation ve share ile ilerlemek tavsiyemdir.

İlerleyen süreçte fırsat bulursam yukarıda belirtmiş olduğum 3 senaryo için benchmark yapıp sizlerle paylaşıyor olacağım 🙂

Frank Denneman’a değerli paylaşımları için teşekkürler ; http://frankdenneman.nl

Görselimiz: