Virtualization – Max performance – Sub-NUMA Clustering

A minap érkezett hozzánk egy HPE Synergy 660 Gen10-es szever, négy darab Intel Xeon 6140-es processzorral. Mi csak kétutas szervereket használunk és általában így vannak ezzel ügyfeleink is. Ez nem itthoni specifikum, mert a globális riportokban döntő részesedéssel futnak a 2 processzorral szerelt szerverek VMware vSphere ESXi alatt.

Így néz ke egy ilyen teljes magas blade belülről – a képen a jobb oldali 3-as és 4-es proesszor csak blank, más képet nem találtam.

Mivel ez egy Synergy blade, ezért nem másképp kell ezt konfigurálni, mint HPE Oneview-ből. Jelen esetben a konfiguráció egyetlen lépéséről szeretnék pár szót ejteni.

Workload profilok

Korábban már a HPE Proliant DL325 Gen10, Epyc tesztem során írtam a NUMA-ról. Frank Denneman pedig elismert tekintély az ESXi CPU scheduler lelki világának részleteiben és alapvetően a NUMA-n alapuló méretezési szabályokban.

Egy új szerver bekapcsolása után és annak felkészítése során nagyon fontos a megfelelő beállítások eszközölése, de még inkább azok konzisztens használata. Tehát nincs azzal baj, ha például kikapcsoljuk a hyperthreading-et, de akkor egy klaszterben minden hoszton tegyük meg. Ezáltal egy HA esemény vagy a DRS normál működése során – vagy manuális – vMotion mozgatások után, a futtatott virtuális gép pontosan ugyanolyan erőforrásokra számíthat – amennyiben ez lehetséges egy megosztott erőforrás során – az ESXi-től, mint az a régi helyén rendelkezésre állt. Egy ilyen beállítás kialakítása sok-sok ajánláson alapuló, rengeteg beállítás a BIOS szintjén, amiket egyesével beállítani már 4 hoszton is kihívás, nem nagyobb számosságnál. Azt már meg sem említem, ha például egy meglévő 8 hosztos környezetbe érkezik még 2 hoszt. Ekkor már az emlékezetben nem lehet bízni, hogy miképp volt beállítva, de még a dokumentáción is megkopik a tinta.

Ennek elkerülésére a HPE a Gen10-es szervereinél megjelentette az úgynevezett Workload profile alapú konfigurációt. Ez megtehető természetesen ILO szintjén is, BIOS-ban is és amennyiben Oneview-t használ – remélem igen – valaki, akkor ott is. Ez egy a HPE “Intelligent System Tuning (IST)” képességébe tartozó funkció, amivel egyetlen ilyen profil kiválasztásával beállítható sok-sok alacsonyabb szintű beállítás, amelyek a HPE szerint a pontosan azt a hatást hozzák az adott workload számára, mint azt a profil neve is sugallja.

Nem vagyok egy field mérnök, de mikor a kezem közé akad egy ilyen szerver, akkor azon általában majd ESXi fog futni, így én mindig “Virtualization – Max Performance” profilt használok és ez a Oneview felől nagyon kivonatosan ezt állítja be.

Látható a Sub-NUMA Clustering, amit egedélyezettre állít. Picit részletesebben, hogy mit állít be pontosan.

Az általam választott beállítás bekapcsolja a korábbi nevén “Cluster on Die”, ma már Sub-NUMA clustering névvel illetett opciót. Mit is jelent ez?

Ehhez meg kell ismerni, miképp néz ki egy ilyen Intel Skylake processzor belülről.

Forrás: Intel

Látható, hogy bár egy tokozást látunk, mégis két jól elkülöníthető domain van, mindkettő majdnem egyenértékű, viszont mindegyikhez tartozik 3 memória-csatorna, csatornánként két bank-kel. Na pontosan ezt a szétválasztást kapcsolja be a Sub-NUMA Cluterning. Nélküle egy NUMA node, egy teljes fizikai foglalat lenne, nem egy foglalat fele.

Picit jobban látható ez a felépítés a következő ábrán.

Miért van erre szükség?

Egészen egyszerűen azért, mert L1/L2 és L3 cache-ek és maga az adott memória modul(ok). Az érthető, hogy amennyiben egy adott mag, például a fenti képen valamilyen adattal akar dolgozni, akkor annak az adatnak az elérése, legyen az L3 cache-ben vagy bármelyik memória modulban, abban az esetben úgy a legrövidebb a késleltetés, ha az a cache vagy modul ahhoz a NUMA node-hoz tartozik, amelyen ő maga is van. Ezzel csak akkor hozható képbe egy operációs rendszer, ha eláruljuk neki a chip belső felépítését és beállítjuk a COD/Sub-NUMA clustering-et.

Hol érhető tetten?

ESXi alatt csak be kell SSH-zni a hosztra és kiadni az “esxcli hardware memory get | grep NUMA” parancsot.

Szóval a fentebb említett HPE Synergy SY660 Gen10-es szervernél az Intel Xeon 6140-es processzoroknál a Sub-NUMA clustering miatt, nem a négy socket, látszik négy NUMA node-nak, hanem elárulja az egy Xeon-on belül található specifikus felépítését is.

Nézzük meg miképpen ütemez ezen az ESXi pár VM-et, amelyeket így hoztam létre:

vCPUSocket
VM_with_18_core – 1 socket181
VM_with_18_core – 2 socket92
VM_with_9_core – 1 socket 91
VM_with_12_core – 2 socket122
VM_with_72_core – 4 socket724

Légyegében teljesen felesleges volt a Cores Per Socket-et beállítani, mivel az ESXi ütemező nem is veszi figyelembe 6.5 óta.

A “VM_with_18_core – 1 socket” virtuális gép esetén, látható hogy két NUMA node-on ütemezi a gépet, hiszen egy NUMA node csak 9 darab fizikai magot tartalmaz.

A “VM_with_18_core – 2 socket” ehhez képest így néz ki.

Ehhez képest?? Nincs különbség!

A “VM_with_9_core – 1 socket” virtuális gépnél pedig így alakítja ki. Ez teljesen világos, kilenc fizikai mag van egy ilyen processzor felében.

Végül nézzük meg a 12 vCPU-s gépet. 2 domain-re ütemezi, 6-6 fizikai magra.

És akkor a monster VM, 72 vCPU-val. Ennyi fizikai mag van összesen a 4 fizikai processzorban. Nyolc darab VPD-t és PPD-t hoz létre, azaz fizikailag is nyolc NUMA-node-ra ütemezi.

Mi az értelme ennek?

Csak annyi, hogy amennyiben a guest operációs rendszer NUMA aware – a Windows Server 2016/2019 az – akkor az ilyen wide-VM-ek esetén – ahol a vCPU-k száma meghaladja a fizikai magok számát egy foglalatban, a Sub-NUMA clustering (SNC) segítségével mind a VM számára világossá tehető, mind az ESXi szintjén is kikényszeríthető, hogy elsődlegesen a cache és RAM latency-re legyen kihegyezve a rendszer. Érdekesnek találom, hogy ezt alapból beállítja a HPE power profile.

Érdemes ezzel törődni?

Igazából nem, mivel az esetek 99,99%-ban teljesen mindegy. Az ESXi ütemezője nagyon jó munkát végez, viszont lehet olyan workload a világban, amely nagyon-nagyon érzékeny az ilyen késleltetésre, akkor pedig jól jön. Az, hogy ez alapértelmezetten be van kapcsolva, pedig gondot nem okoz.

Érdekes olvasmányok: